Transformation S/4 : les données sont le principal risque

Date limite de conversion 2027/2030

Ce qui a longtemps été refoulé se fraye peu à peu un chemin dans la conscience des responsables SAP : la question de savoir comment migrer et transformer rapidement et en toute sécurité juridique vers SAP S/4 Hana les stocks parfois massifs d'anciennes données provenant de systèmes SAP, mais aussi de systèmes non SAP et d'archives ADK.

Les données existantes : Les risques plutôt que la bonanza

Lors de la transformation vers SAP S/4 Hana, il est important de conserver les données existantes avec leur contexte et de les mettre à disposition pour des analyses et des connaissances. Cependant, les interdépendances entre les données, leurs structures et les systèmes et applications dans lesquels elles ont été créées constituent un obstacle, qui est pratiquement impénétrable comme les parois d'un silo.

À cela s'ajoute la question de la qualité des données. De nombreux pots de données différents avec des structures différentes, d'innombrables enregistrements de données de base redondants et erronés pour un seul et même client ou fournisseur réduisent la qualité des données et rendent ainsi les fondements des modèles et processus commerciaux numériques plus que fragiles.

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. Or, c'est précisément le cas lorsque les anciennes données sont reprises dans SAP S/4 Hana. En outre, le règlement général européen sur la protection des données (RGPD), notamment, oblige 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 questions de la valeur et de la qualité des données s'ajoute donc celle de la sécurité juridique.

Tout cela fait que les clients SAP existants migrent trop souvent vers SAP S/4 Hana beaucoup trop de données et de surcroît de qualité insuffisante - et perdent ainsi le contexte commercial. C'est aussi pour cette raison qu'ils continuent à exploiter leurs anciens systèmes et archives à grands frais jusqu'à ce que les délais de conservation des informations patrimoniales qui y sont conservées expirent, parfois après des décennies.

Il n'est donc pas étonnant que tant de clients SAP existants continuent d'hésiter à se transformer en SAP S/4 Hana. Et pas étonnant non plus 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.

Les sept règles d'or de la transformation S/4

Les clients SAP existants et les experts ont longtemps débattu de la question de savoir s'il était plus judicieux de convertir toutes les données existantes et les objets commerciaux dans le nouveau monde lors de la transformation S/4 (approche classique brownfield) ou d'y renoncer complètement et de repartir à zéro sur un terrain vierge (greenfield). L'approche de la reprise et de la transformation sélectives des données, dans laquelle les entreprises ne transforment que certaines données opérationnelles en plus des données de base, s'est rapidement imposée comme un compromis applicable dans la pratique et est proposée sur le marché en différentes nuances de couleurs.

Mais ce compromis comporte également de grands risques s'il a lieu au niveau du tableau. En effet, à ce niveau, il s'apparente à une opération à cœur ouvert risquée. Sans parler du fait que la reprise des données ne peut alors pas se faire via les outils prévus par SAP, comme le Migration Cockpit.

Que peuvent donc faire les clients existants de SAP ? Ils devraient respecter les sept règles d'or de la transformation S/4. Ils pourront alors limiter, voire éliminer les risques mentionnés.

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 en raison des conflits entre l'informatique et les départements spécialisés. Après la transformation, les départements spécialisés veulent continuer à avoir accès à toutes les données existantes ainsi qu'à leur contexte commercial. Afin d'éviter que cette exigence ne se transforme en un projet long et exubérant, le service informatique insiste pour ne transformer que quelques années. Pour éviter ce problème, 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. En même temps, 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 SAP 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. accéder aux données plutôt que de les transformer

En séparant le niveau des applications de celui des données existantes, 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 existantes opérationnelles datant par exemple de plus de trois mois. Cela minimise énormément les efforts de migration et de transformation, généralement de 50 pour cent et plus. Par exemple, le groupe international Bühler, leader dans la fabrication de machines et d'installations pour l'industrie alimentaire et la construction automobile, a pu, à l'aide d'une plateforme séparée, réduire son stock de données de deux tiers lors du passage à la base de données Hana et à S/4, le faisant passer de 6 To à moins de 2 To.

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 les coûts d'exploitation totaux du nouvel environnement S/4 Hana peuvent ainsi être réduits de 25 %. De plus, étant donné qu'il est indépendant des systèmes SAP, il est également 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 vers un environnement système harmonisé, mais ouvre également la voie à d'autres scénarios commerciaux agiles. Il s'agit notamment de la reprise et de l'intégration de bases de données et d'environnements système hérités dans le cadre de fusions et d'acquisitions. Mais cette approche et la plateforme séparée nécessaire à cet effet 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, ainsi que leur contexte commercial, sans perte et sans risque via la couche d'application. Les clients existants de SAP peuvent ainsi utiliser les outils prévus à cet effet par SAP, notamment le SAP Migration Cockpit.

Par ailleurs, la plateforme supporte également une approche brownfield - adaptée. Dans un premier temps, les entreprises reprennent toutes les configurations et tous les développements individuels de leur système SAP actuel dans le nouveau S/4, sans toutefois convertir et importer les données de base et les données de mouvement. L'avantage est qu'ils peuvent ainsi adapter toutes les configurations et tous les développements individuels dans le nouveau système, indépendamment des données, de manière flexible et selon leurs souhaits et exigences. 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.

3) Prévenir la qualité des données au lieu de l'améliorer

Résoudre le problème des dépendances pendant la transformation, évoqué dans les risques, n'a que peu de chances de succès. En revanche, si les clients existants de SAP 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. En même temps, le service informatique a la possibilité de nettoyer les données existantes qu'il souhaite transférer vers S/4 Hana, 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 proviennent de SAP ou de tiers, et les archives ADK peuvent non seulement être démantelés, mais aussi complètement déclassés et éliminés - une approche qui en vaut la peine, même dans le scénario greenfield d'une transformation S/4 : Par rapport à la poursuite de l'exploitation, les clients SAP existants économisent ainsi en général 80% ou plus sur les coûts d'exploitation.

C'est exactement ce qui s'est passé pour le groupe Bühler déjà mentionné. Dès 2003, l'entreprise a transféré tous les systèmes ERP spécifiques à chaque pays, la plupart de SAP, vers un seul système SAP central.
Les données des clients ont été consolidées et complètement arrêtées à l'aide d'une approche de plateforme séparée. Depuis lors, le groupe Bühler a réduit les coûts d'exploitation SAP de 80%.

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 plate-forme doit transférer et conserver les informations patrimoniales sans les modifier. Parallèlement, la 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 de suppression du RGPD européen, et ce jusqu'au niveau des enregistrements individuels. Cela garantit la sécurité juridique, même si les systèmes existants ne sont pas maintenus en service.

Le transfert des données sur une plateforme séparée et moderne contribue par ailleurs à 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 ce qui peut l'être

Compte tenu de l'énorme volume de données auquel sont confrontés les clients SAP existants, en particulier dans le segment des entreprises, il est essentiel d'atteindre le plus haut degré d'automatisation possible. Cela vaut en particulier pour la première étape, l'extraction des données et de leur contexte commercial. Il doit être possible, en appuyant sur un bouton, d'extraire en quelques heures ou jours, au lieu de mois ou même d'années, des quantités d'informations allant de 10 à 100 téraoctets, de manière totalement automatisée, à partir de systèmes existants et d'archives ADK, de les transférer sur la plateforme et de les y conserver en toute sécurité juridique jusqu'à leur suppression.

Mais l'automatisation joue également un rôle important en ce qui concerne l'affichage des informations patrimoniales dans l'univers SAP S/4 Hana via SAP GUI ou SAP 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 Hana dans la structure de l'objet commercial "partenaire", comme si elles avaient été créées dans cette structure.

Ce degré d'automatisation, de l'extraction des données à leur affichage dans le nouvel environnement, est l'essence même de l'approche de plateforme séparée pour la transformation sélective des données via la couche d'application, que l'on peut qualifier à juste titre de transformation en un clic.

7. utiliser la transformation en un clic comme un 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 de systèmes et d'applications existant, 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 plateforme utilisée pour l'extraction, l'analyse, l'optimisation, la transformation et la conservation des données. Le service utilise 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.

Police d'assurance contre les risques 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 plate-forme 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'à un procédé en instance de brevet pour l'extraction turbo de données anciennes.

Avec l'aide de JiVS IMP, Hawle Armaturen AG, une entreprise de production et de commerce leader en Suisse dans les domaines de l'eau, du gaz et des eaux usées, a pu par exemple mener à bien son projet de transformation et de migration des données dans le cadre du passage à SAP S/4 Hana en l'espace de trois mois seulement.

Depuis l'année dernière, Data Migration International propose en complément de sa plateforme le One-Click-Transformation-Cockpit, une solution SaaS, et fait ainsi de la préparation des projets de transformation un service. D'ailleurs, la plateforme elle-même est disponible en tant que service cloud.

JiVS IMP et le One-Click-Transformation-Cockpit sont la police d'assurance contre les risques liés aux données. En tant qu'élément central d'une Data Fabric à l'échelle de l'entreprise, ils soutiennent les projets de transformation de toutes sortes et ouvrent la voie à une entreprise pilotée par les données.

PDF (en anglais)