Les risques plutôt que Bonanza

Lors de la transformation vers SAP S/4 Hana, il est essentiel de conserver les données existantes héritées, ainsi que leur contexte, afin de les rendre disponibles pour des analyses et des connaissances pertinentes. C'est le trésor que les entreprises veulent récupérer et faire fructifier dans le cadre de leur transformation numérique. Mais c'est précisément ce contexte qui est perdu lors de la transformation, car le monde S/4 exige des structures de données différentes de celles de la génération précédente. Au lieu de pouvoir espérer une bonanza, les entreprises se voient confrontées à un risque de perte.

À cela s'ajoute la question de la qualité des données. De nombreux pots de données différents avec des structures différentes et d'innombrables enregistrements de données de base redondants ou erronés pour un seul et même client et fournisseur réduisent la qualité des données jusqu'à ce que les fondements des modèles et processus commerciaux numériques se brisent. On ne peut pas gagner de l'argent avec de l'or de chat.

Et puis, il y a le législateur. Diverses obligations et délais de conservation empêchent les entreprises de modifier les données et leurs structures. En outre, le règlement général européen sur la protection des données (RGPD) en particulier et, depuis peu, la nouvelle loi suisse sur la protection des données obligent les entreprises à pouvoir supprimer des informations au niveau de l'enregistrement individuel. Or, il n'est soit plus possible techniquement de mettre à jour cette capacité dans les anciens systèmes, soit cela ne peut se faire qu'à grands frais. Aux risques de perte de valeur et de qualité s'ajoute donc le manque de sécurité juridique. Au lieu d'une augmentation des bénéfices et de bonus, ce sont des pénalités et la responsabilité personnelle des conseils d'administration et des directions qui menacent.

Transformation S/4 : sept règles d'or

Il n'est donc pas étonnant que tant de clients SAP existants hésitent encore à passer à SAP S/4 et continuent d'exploiter leurs anciens systèmes et archives à grands frais jusqu'à ce que les délais de conservation des informations patrimoniales qu'ils contiennent aient expiré, parfois après des décennies. Que peuvent donc faire les clients SAP existants pour échapper à ces risques et utiliser à leur avantage le passage à la nouvelle génération de logiciels de Walldorf ? La réponse se trouve dans les sept règles d'or de la transformation S/4 :

1. séparer au lieu de migrer

La plupart des projets de transformation durent plus longtemps que nécessaire, non seulement en raison des obstacles techniques, mais aussi et surtout en raison des conflits entre l'informatique et les départements spécialisés. Ces derniers veulent continuer à avoir accès à toutes les données existantes ainsi qu'à leur contexte commercial après la transformation. Pour éviter que cette exigence ne se transforme en un projet long et exubérant, le service informatique insiste pour ne transformer que quelques millésimes.

Comme l'entreprise a généralement la priorité sur l'informatique, ce sont souvent les départements spécialisés qui imposent leurs intérêts. Il en résulte que la plupart des projets de transformation durent beaucoup plus longtemps que nécessaire - dans le cas des grandes et très grandes entreprises, cinq ans et plus au lieu de quelques mois.

Pour éviter que ce problème ne se pose, les clients SAP existants devraient appliquer la première règle d'or : séparer plutôt que migrer. Cela signifie extraire l'ensemble des données existantes, y compris les données des archives ADK et leur contexte commercial, des systèmes patrimoniaux et les conserver telles quelles sur une plateforme moderne qui leur est propre.

Cela présente l'avantage décisif que toutes les données sont disponibles indépendamment des anciens systèmes et peuvent donc être mises à tout moment à la disposition des départements spécialisés. Le risque de perdre le contexte commercial est ainsi éliminé. Parallèlement, le service informatique peut répondre de manière autonome à la question de savoir quelle partie des données héritées doit ensuite être reprise et transformée dans S/4 Hana. La transformation S/4 devient ainsi un projet technique, mais qui tient compte en même temps des souhaits des départements spécialisés.

2. saisir au lieu de transformer

En séparant le niveau des applications de celui des données, les entreprises peuvent déterminer, sur la base de considérations purement commerciales, de quelles données de base elles ont encore besoin dans S/4 et si elles veulent vraiment transformer des données opérationnelles datant par exemple de plus de trois mois. Cela minimise énormément l'effort de migration et de transformation, généralement de 50 % ou plus.

En outre, cette approche permet d'alléger durablement la base de données Hana. En effet, le processus consistant à transférer les données de mouvement obsolètes de manière générale sur la plateforme séparée peut être répété indéfiniment. Il est réaliste d'estimer que cela permet de réduire le coût total de possession du nouvel environnement S/4 de 25 %.

De plus, comme elle est indépendante des systèmes SAP, il est possible de conserver les anciennes données des systèmes non SAP sur une plateforme séparée. Cela permet non seulement de consolider des systèmes hétérogènes en un environnement informatique harmonisé, mais ouvre également la voie à d'autres scénarios commerciaux agiles. En font notamment partie la reprise et l'intégration de bases de données et d'environnements système hérités dans le cadre de rachats et de fusions (Mergers and Acquisitions). Mais cette approche et la plateforme séparée nécessaire jouent également leurs atouts à l'avantage des entreprises dans le cas inverse de la vente d'un secteur d'activité ou d'une filiale, ce que l'on appelle les carve-outs.

Mais l'avantage peut-être décisif réside dans le fait qu'une telle plate-forme séparée offre la possibilité de transformer et de migrer les données de base et les données de mouvement sélectionnées via la couche d'application, sans perte et sans risque. Les clients existants de SAP peuvent ainsi utiliser les outils prévus à cet effet par SAP, à savoir le SAP Migration Cockpit.

En fin de compte, cette approche de plateforme transforme même chaque projet brownfield en projet greenfield pour un nouveau départ avec un système S/4 adapté de manière optimale aux défis de l'avenir. Dans un premier temps, les entreprises convertissent tous les paramètres et développements individuels de leur système SAP actuel dans le nouveau S/4, mais sans les données de base et les données de mouvement. Elles peuvent ainsi concevoir leurs objets commerciaux, mais aussi toutes les adaptations des configurations et des développements individuels dans le nouveau système, indépendamment des données, de manière flexible et selon leurs souhaits et exigences pour l'avenir. Ce n'est que dans un deuxième temps qu'ils remplissent cette enveloppe "vide" mais personnalisée, mais uniquement avec les données de base et les données de mouvement qu'ils ont préalablement sélectionnées sur la plateforme. En règle générale, le résultat permet de réduire de moitié le nombre d'objets commerciaux et de diminuer de 80 % la quantité de données de base nécessaires, voire de 90 % ou plus celle des données de mouvement.

3) Prévenir plutôt que réparer

Entre les données héritées, leurs structures et les systèmes et applications dans lesquels elles ont été créées, il existe de grandes interdépendances qui, comme les parois d'un silo, sont pratiquement impénétrables. Briser ces murs lors de la transformation n'a que peu de chances de succès. En revanche, si les clients SAP existants transfèrent l'ensemble de leurs données existantes ainsi que leur contexte commercial sur une plateforme séparée avant la transformation, le problème des dépendances ne se pose même plus.

Parallèlement, le service informatique a la possibilité de nettoyer les données existantes qu'il souhaite transférer vers S/4, indépendamment des systèmes sources, sur la plateforme séparée avant la transformation et d'éliminer ainsi les doublons et les erreurs. En outre, elle peut enrichir ces jeux de données avec ceux provenant de sources tierces. Cela est particulièrement important dans les scénarios d'analyse et s'applique d'ailleurs non seulement aux données de mouvement, mais aussi à toutes les données de base, y compris les bases de données clients, fournisseurs et articles, si importantes pour la transformation numérique.

4. éteindre et économiser

Une fois que les données héritées des systèmes SAP et non SAP, y compris le contexte commercial, ont été transférées sur la plateforme séparée, les systèmes hérités, qu'ils soient de SAP ou de fournisseurs tiers, y compris les archives ADK, peuvent non seulement être démantelés, mais aussi complètement mis hors service et éliminés. Par rapport à la poursuite de l'exploitation, les clients SAP existants économisent ainsi en général 80 pour cent ou plus de frais d'exploitation.

5. assurer la sécurité (juridique)

Pour que les obligations et les délais de conservation prescrits par la loi ne fassent pas obstacle à la mise hors service du système, une telle plateforme doit transférer les informations patrimoniales dans leur état d'origine et les conserver de manière à ce qu'elles puissent être révisées. Parallèlement, cette conservation des informations à l'épreuve des révisions doit être certifiée par des commissaires aux comptes. En outre, la plateforme doit être en mesure de remplir sans faille les obligations d'effacement du RGPD de l'UE et de la loi suisse sur la protection des données ainsi que des dispositions internationales les plus diverses en matière de protection des données. Cela garantit la sécurité juridique même sans la poursuite de l'exploitation des systèmes existants.

De plus, le transfert des données sur une plateforme séparée et moderne contribue à une meilleure sécurité informatique et donc des données, car une plateforme moderne peut être patchée à l'avenir, contrairement à certains systèmes hérités.

6. automatiser, automatiser, automatiser

Compte tenu des énormes quantités de données auxquelles sont confrontés en particulier les clients SAP existants du segment des entreprises, il est essentiel d'atteindre le plus haut degré d'automatisation possible. Cela vaut en particulier pour la première étape, à savoir l'extraction des données et de leur contexte commercial via la couche d'application. Il doit être possible, en appuyant sur un bouton, d'extraire même des quantités de 10, 100 et plus téraoctets d'informations en quelques heures et jours au lieu de mois ou même d'années, de manière entièrement automatisée, des systèmes existants et des archives ADK et de les transférer sur la plateforme.

Mais l'automatisation joue également un rôle important en ce qui concerne l'affichage des informations patrimoniales dans le monde SAP S/4 via SAP GUI ou Fiori. Pour cela, il faut utiliser le procédé du "Technical Structure Mapping". Les anciennes données sont transformées à la volée, sans modifier la structure originale des données historiques sur la plateforme elle-même. Ainsi, les données relatives aux objets commerciaux SAP ECC "client" ou "fournisseur" peuvent être représentées dans S/4 via l'objet commercial "partenaire", comme si elles avaient été créées dans cette structure. L'automatisation de l'extraction des données jusqu'à leur affichage dans le nouvel environnement constitue, en tant que "transformation en un clic", l'essence même d'une approche de plateforme séparée pour la transformation sélective des données via la couche d'application.

7. utiliser Transformation-as-a-Service

Tous les scénarios de transformation impliquent des tâches similaires et récurrentes. Il s'agit par exemple de l'inventaire du paysage des systèmes et des applications existants, y compris les versions, ou de l'analyse du potentiel de réduction des données existantes (appelée Data Potential Reduction Analysis ou DPRA) et des données exactes (mais pas plus !) qui doivent être transférées lors d'un carve-out, ainsi que de la définition des règles de filtrage et de transformation.

Pour pouvoir envisager ces scénarios et les avantages, les synergies et les travaux préparatoires qui y sont liés sans aucun risque, les entreprises ont besoin d'une solution de service qui permette de le faire indépendamment de la plate-forme elle-même. Le service travaille avec des métadonnées telles que des informations sur les systèmes, les applications et les bases de données qui sont pertinentes pour la transformation S/4 ou le secteur d'activité à vendre. Les connaissances que cette solution SaaS apporte aux projets de transformation fournissent aux clients SAP existants une base de décision réaliste et fiable pour leurs projets de transformation.

Tant la plate-forme que le service de transformation existent déjà. JiVS IMP, la plateforme de gestion de l'information indépendante du système du fournisseur suisse Data Migration International, a déjà prouvé son utilité dans plus de 2000 projets dans le monde entier. La plate-forme assure une séparation nette entre la couche de données et la couche d'application, ce qui permet d'accélérer radicalement l'extraction, la transformation et la migration des données existantes via la couche d'application et les outils standard de SAP. La plateforme rend cela possible grâce à la prise en charge de plus de 3000 objets commerciaux issus de systèmes SAP et non SAP de différentes versions ainsi qu'à une procédure de turbo-extraction des bases de données existantes.

PDF en anglais