Penser et agir en termes de données : Conception de données pour une migration simplifiée des données vers SAP S/4 Hana

Le manque de visibilité sur les données et le manque de qualité des données sont des facteurs aggravants. Une conception préalable des données peut contribuer à simplifier la migration des données et à accélérer le délai de mise en œuvre. L'horloge tourne sans cesse. D'ici 2030 au plus tard, les entreprises qui le souhaitent devront avoir migré vers SAP S/4. Et une telle migration n'est pas si triviale. En effet, le remplacement des anciens systèmes et le passage à S/4 nécessitent de nombreuses étapes partielles, dont certaines nécessitent un soutien externe. Et les ressources externes sont rares, surtout maintenant que l'échéance se rapproche.

Quelle que soit l'approche de migration choisie par les entreprises concernées, qu'il s'agisse de Greenfield, Brownfield ou Bluefield, les entreprises concernées doivent se poser de nombreuses questions. Quels sont les départements impliqués ? Qui est le principal moteur et responsable de la migration ? Où ai-je besoin de quel soutien, y compris externe ? Quels processus sont concernés ? Et, et, et.

En matière de données, il y a aussi beaucoup de choses à prendre en compte. Le nouveau modèle de données de S/4 Hana donne le ton. Dans l'idéal, les entreprises migrantes doivent en effet modifier leurs données. Les données qui étaient jusqu'à présent traitées séparément en tant que client, fournisseur et autre partenaire commercial devront à l'avenir être consolidées dans le nouveau modèle de données sur la base centrale des partenaires commerciaux. Comme cette étape sera tôt ou tard nécessaire, il est conseillé de tenir compte de la consolidation des données lors de la migration. La situation est souvent compliquée par une qualité insuffisante des données, une gestion des données en silos qui s'est généralement développée au fil du temps et un Customizing souvent assez vaste.

Ce mélange presque toxique de facteurs contraignants fait de la migration des données un projet partiel tout à fait difficile. Selon l'étude 'SAP S/4 Hana 2024 - Aktuelle Cloud-ERP-Trends' réalisée par CIO, CSO et Computerwoche, environ 39% des personnes interrogées considèrent la charge de travail liée à la migration des données comme le plus grand défi lors du passage à S/4. Viennent ensuite l'effort d'adaptation de l'environnement système et de l'architecture informatique existants (37%) et le manque de ressources pour la transformation dans les départements concernés (36%).

Pour simplifier au maximum la migration des données, il est tout d'abord nécessaire de se pencher sur le sujet des données le plus tôt possible dans le projet de migration, et non pas seulement lorsque la migration globale est pratiquement terminée. La tâche consiste notamment à consolider les données existantes du ou des anciens systèmes (ERP/ECC 6.0) sur le nouveau modèle de données de S/4 Hana, la base centrale des partenaires commerciaux. La grande école consiste ici à effectuer simultanément un nettoyage et une préparation selon les normes de qualité de données courantes, notamment une validation postale ainsi qu'une élimination des doublons (Identity Resolution).

Pour une consolidation efficace sur la base centrale des partenaires commerciaux, une conception préparatoire des données est une première étape importante. La conception des données regroupe toutes les étapes partielles qui servent à saisir, décrire et finalement documenter la situation initiale et la situation cible en ce qui concerne les données des débiteurs, des créanciers et des autres partenaires commerciaux avec leurs rôles. Dans ce contexte, on obtient également à cette étape une vue d'ensemble claire de l'état des données, des processus actuels ainsi que du degré de personnalisation qui caractérise la situation actuelle. Parallèlement, on définit la manière dont les données seront transférées de l'ancien système vers le nouveau. Mais comment se déroule concrètement une telle conception des données ?

L'exploration des données, c'est-à-dire l'observation et l'examen très concrets des données, marque le début de la conception des données. Sans clarté sur la nature réelle des données issues des différentes sources de données à migrer, aucune conception de données digne de ce nom ne peut avoir lieu.

Dans l'exploration des données, on se penche d'une part sur la situation du point de vue de la qualité des données. Les données sont-elles correctes du point de vue postal ? Quelle est la proportion d'enregistrements doubles ou multiples ? Mais l'attention se porte aussi et surtout sur la nature structurelle des données. Quelle est la structure de base des enregistrements ? Quels sont les champs disponibles ? Ces champs sont-ils réellement remplis ? Et sont-ils remplis avec les bonnes données ? En d'autres termes, un champ de numéro de rue contient-il effectivement un numéro de rue et ce numéro de rue existe-t-il vraiment ? Ou existe-t-il un champ de code postal ? Et si oui, quel est son degré de remplissage ? Et s'agit-il toujours de données plausibles, comme par exemple un code postal à cinq chiffres en Allemagne ?

Il est recommandé de charger les données à comprendre dans un hub de données comme le Customer Data Hub d'Uniserv. Lors du travail avec les données dans le hub de données, l'expérience montre que quatre à cinq itérations sont souvent nécessaires avant que l'on ait vraiment saisi et compris ses données à cent pour cent et que l'on ait finalement documenté de manière vraiment transparente quelles sont les données dont on dispose réellement.

Réel versus théorique

La conception des données reprend les résultats de l'exploration des données et complète l'image de la situation actuelle. Pour ce faire, on saisit avant tout les processus commerciaux qui sont actuellement utilisés. Il s'agit également de comprendre quels sont les départements impliqués et où sont les données nécessaires. Un service commercial est par exemple intéressé par les chiffres d'affaires, l'historique des achats, la solvabilité. Un service financier a besoin de données de paiement et des interlocuteurs concernés.

Ces différentes visions d'un même ensemble de données, ainsi que les différents besoins en données, mettent en évidence la complexité de la saisie et de la description de la situation actuelle, d'une part, et l'importance de celle-ci, d'autre part.

Une fois que l'on a une vue complète, transparente et clairement documentée de la situation actuelle, on peut commencer à travailler sur la conception de la situation souhaitée, l'objectif. Il est intéressant de noter qu'il faut décrire quelque chose qui n'existe pas encore. Il est donc nécessaire d'y regarder de très près et de répondre aux questions les plus diverses en vue du nouveau modèle de données. Il s'agit par exemple de déterminer à quoi doivent ressembler les futurs processus commerciaux. Quels sont les flux de données existants ? Quels flux de données doivent être remplacés et lesquels doivent être créés ? Il faut déterminer quelles données sont réellement nécessaires, où et d'où elles proviennent. Il est également important d'avoir une vue d'ensemble des interfaces entre les systèmes et les services.

C'est au plus tard à ce moment-là que l'on sera content d'avoir travaillé avec précision dans les étapes précédentes. En effet, il est alors possible de déterminer, par exemple, si la qualité des données existantes est suffisante, quelles données sont encore nécessaires ou si de nouvelles données seront nécessaires à l'avenir. Il est ainsi possible de déterminer, d'abord au niveau théorique, quelles données peuvent être supprimées avant la migration et, le cas échéant, quelles données doivent être archivées. Quelles données sont nécessaires pour quels processus et quelles applications ? Cela réduit considérablement la quantité de données à migrer. Ce qui contribue à un allègement.

Pensez grand, commencez petit

De nombreuses entreprises, surtout les grands groupes, possèdent dans leurs unités organisationnelles et filiales une quantité souvent énorme de systèmes périphériques et de données. Si l'on essaie de tout saisir d'emblée, on risque d'échouer malgré une procédure planifiée. En effet, les migrations ne peuvent souvent se faire que pas à pas ; on ne peut pas se permettre de paralyser son entreprise pendant des jours.
Il est donc recommandé de se faire une idée générale de l'exploration et de la conception des données. Lors de la mise en œuvre, il est utile de traiter les données source par source ou système par système. En effet, c'est avec la grande image que l'on obtient le Big Picture en vue de la migration globale par rapport au nouveau modèle de données. En traitant continuellement les sources et les systèmes, ceux-ci peuvent être migrés en accord avec le nouveau modèle de données. Effet positif : les enseignements tirés de chaque étape partielle peuvent être réinjectés dans le Big Picture et l'affiner davantage.

Conception de solutions

Une fois la conception des données établie, on peut réfléchir concrètement à la manière de passer de son état actuel à son état cible. À quoi doit donc ressembler la transition ? La solution consiste à construire en fonction du point de données central. La solution actuelle est-elle bonne telle qu'elle est ou faut-il quelque chose d'autre en plus ?

Le Solution Design répond donc à la question de savoir comment la migration des données doit être concrètement mise en œuvre. Le Solution Design se réfère à la solution globale et à la planification stratégique. Ainsi, la solution existante est testée par rapport à une conception de solution alternative. Le choix et la mise en œuvre de l'architecture d'intégration et de l'interface de transfert de données sont abordés.

uniserv.com