Transformation : nouvelle et radicalement simple

La demande de projets de transformation SAP prend vraiment son envol. En théorie, oui. Mais dans la pratique, les clients SAP existants se heurtent à un obstacle majeur : l'offre trop restreinte de consultants et de spécialistes de la migration SAP - et ce dans le monde entier. Aujourd'hui déjà, de plus en plus de rapports émanant du marché indiquent que certaines entreprises de migration SAP ne pourront pas accepter de nouveaux projets de transformation avant au moins un an. Il est à craindre qu'à partir de 2025 au plus tard, chaque spécialiste de la migration SAP disponible doive travailler 24 heures sur 24 pour suivre le rythme de la demande.

Bien sûr, cela n'arrivera pas. Mais ce qui va se passer à la place est clair : les taux journaliers vont augmenter très fortement, les durées des projets vont s'allonger considérablement. Ce n'est pas une bonne situation de départ pour la transformation numérique des grands clients SAP existants dans les pays germanophones, pour lesquels le passage à la nouvelle génération de logiciels de Walldorf constitue le cœur de leur stratégie de numérisation.

Conversion S/4 : petit guide des couleurs

Outre les capacités des conseillers, la question de l'approche de la transformation doit être abordée. Au cours des dernières années, il est devenu conventionnel d'attribuer des couleurs aux différentes possibilités d'approche. Le spectre des couleurs va du brownfield au greenfield, avec de nombreuses nuances entre les deux. Le brownfield se situe à l'une des extrémités de ce spectre. Il s'agit de la reprise complète des structures de données existantes, des objets commerciaux et des adaptations individuelles ainsi que des développements propres, y compris l'ensemble des données existantes.

A l'autre bout, il y a le redémarrage sur un terrain vierge. Dans cette approche dite "greenfield", les entreprises repartent de zéro avec des structures de données, des objets commerciaux et des adaptations qu'elles jugent les mieux adaptés à leur propre avenir commercial. Dans cette approche, si les entreprises veulent reprendre les données des anciens systèmes, elles ont deux possibilités : Soit elles transforment toutes ces données au prix d'un effort considérable, soit elles ne transforment que les données de base et les postes ouverts. Mais dans les deux cas, les données originales accumulées jusqu'à présent restent dans les systèmes existants, qui doivent alors être exploités en parallèle pendant de longues périodes pour des raisons juridiques et commerciales.

Dilemme du brownfield

Les deux extrêmes sont tout à fait justifiés, mais présentent également des inconvénients considérables. Les entreprises disposant d'un environnement système homogène, c'est-à-dire sans systèmes tiers ni versions différentes, qui ne souhaitent pas modifier leur activité actuelle et qui renoncent donc délibérément aux changements et aux innovations, trouveront dans Brownfield leur méthode optimale pour la transformation vers S/4 Hana.

Chez les grands clients SAP existants, les environnements système sont en général si hétérogènes et les stocks de données si importants que leur conversion chez Brownfield semble se dérouler sans difficulté d'un point de vue technique. Mais les apparences sont trompeuses : pour cela, il faut déjà créer de nombreuses conditions préalables dans les systèmes sources, dans le cadre de projets préliminaires parfois coûteux. Il s'agit entre autres de l'épuration des développements individuels ou de l'activation d'une nouvelle logique commerciale.

Coûts exorbitants inclus

En outre, de nombreux tests sont nécessaires et les services spécialisés doivent être impliqués afin d'éviter les erreurs. De plus, la conversion des volumes de données, généralement très importants, nécessite généralement d'immenses capacités de calcul, ce qui entraîne des coûts élevés. Dans ce contexte, il n'est plus surprenant que de nombreux clients SAP aient du mal à justifier l'analyse de rentabilité d'un projet de transformation SAP.

D'un point de vue commercial, les dépendances entre les données, leurs structures et leurs systèmes d'origine, mais aussi les interfaces entre les différents systèmes, sont encore plus graves. En font d'ailleurs partie les données qui, pour la plupart, sont malheureusement reliées de manière fixe à des unités organisationnelles, des types de documents et des processus obsolètes ou qui ne sont plus pertinents. Dans de nombreux cas, ces données devraient représenter jusqu'à 90 % de l'ensemble des données. Les dépendances sont en effet si importantes qu'elles réduisent les chances 

de la direction à un nouveau départ ou à la fondation de nouveaux modèles et processus commerciaux, que la direction associe dans la plupart des cas au changement de génération.

Peu de chances de succès

Résoudre ce problème fondamental de dépendances n'a d'ailleurs qu'une chance minime de succès, que les entreprises tentent de le résoudre au niveau des systèmes sources, c'est-à-dire avant le passage à l'euro, ou après : En effet, il est pratiquement impossible de nettoyer les données de base ayant des relations avec des structures de données obsolètes, et encore moins de parvenir à une vue harmonisée, c'est-à-dire inter-systèmes, des données de base, qui sont généralement réparties sur plusieurs systèmes sources différents. La raison en est que les clients SAP existants doivent faire face à des dépendances extrêmes lors de cette procédure, comme par exemple des milliers de documents non clôturés ; dans certains cas, il ne devrait même plus être possible d'extraire les données des archives, dont la technologie date encore dans de nombreux cas des années 1990.

En bref, le lien entre les données de base, les données de mouvement et les adaptations individuelles dans les systèmes hérités empêche ou du moins complique énormément leur nettoyage. Et comme les données de base pertinentes ne se trouvent généralement pas dans un seul système, mais dans plusieurs systèmes différents, le problème se multiplie. Car ces différentes données de base issues de différents systèmes devraient d'abord être harmonisées avant la conversion, ce qui empêcherait à nouveau les dépendances. Le cercle vicieux est parfait. Mais dans l'ensemble, les efforts qui en découlent sont pratiquement injustifiables, tant pour les départements spécialisés que pour l'informatique.

Manque de ressources et de compétences

Les clients SAP existants qui, dans un scénario brownfield classique, tentent malgré tout de nettoyer au moins leurs données de base après le passage à S/4, doivent faire appel à leurs utilisateurs spécialisés pour le faire. Mais attention : si l'on part du principe qu'un utilisateur spécialisé a besoin de dix minutes pour vérifier et nettoyer un enregistrement de données de base, l'entreprise doit prévoir plus de 10 000 jours de travail pour un stock de données de base de 500 000 enregistrements individuels, en supposant une journée de huit heures. Bien sûr, cette tâche peut être répartie sur de nombreuses épaules. Néanmoins, la charge de travail est considérable. On ne sait toutefois pas si ces tentatives de nettoyage manuel des données seront couronnées de succès. En effet, le problème de la liaison de différents types de données entre elles et avec les systèmes ne se pose pas seulement dans les systèmes sources, mais aussi dans les systèmes cibles. Il n'est pas non plus possible de résoudre ce problème sur le plan technique.

La situation n'est guère meilleure pour les données de mouvement. Les environnements ERP des grands clients SAP existants dans les pays germanophones se sont développés au cours des dix à vingt dernières années. Même si l'on part du principe que les entreprises ont besoin de l'ensemble des données de l'année précédente pour les traiter dans S/4, elles convertissent donc 90 à 95 % des données pour rien dans le cadre d'une approche brownfield. De plus, cet héritage constitue un fardeau écrasant pour le nouveau système, qui mobilise d'énormes ressources de calcul et de stockage, entraîne malgré tout de mauvais temps de fonctionnement et augmente fortement les frais de maintenance et d'exploitation, notamment lors des mises à jour ou des mises à niveau. Dans l'ensemble, la base pour l'optimisation de la qualité des données d'une part et la modernisation des processus d'autre part disparaît presque entièrement.

Dilemme de Greenfield

En revanche, Greenfield présente certes des avantages indéniables. Ce sont justement les entreprises disposant d'un environnement système très hétérogène et de grandes bases de données qui en profitent, par exemple lorsqu'elles changent complètement de modèle d'entreprise et repartent presque à zéro comme une start-up. Ou si elles transforment fondamentalement leurs structures et leurs processus en passant d'une organisation centralisée à une organisation décentralisée.

Mais ici aussi, tout ce qui brille n'est pas or. Certes, les approches de bonnes pratiques qui promettent une standardisation poussée sont attrayantes. Mais de nombreux clients SAP les redoutent également, car elles menacent de dévaloriser les investissements élevés qui ont été réalisés dans les versions sur mesure des anciens systèmes, y compris les développements spécifiques aux clients et les processus optimisés qui en résultent. En fin de compte, les clients SAP existants ont fait ces investissements afin de s'assurer des avantages concurrentiels uniques. Les efforts à fournir pour les reproduire dans la nouvelle génération de logiciels sont énormes. Là encore, l'analyse de rentabilité n'est généralement pas rentable.

Pour Greenfield, l'alternative serait de ne reprendre que les postes ouverts et les données de base. Mais cela pose souvent un énorme problème d'acceptation au sein de l'entreprise. En effet, les utilisateurs à tous les niveaux, jusqu'au directeur financier, veulent, pour des raisons commerciales, accéder facilement à toutes les informations héritées, et ce à deux conditions : Ils veulent y accéder à partir de "leur" interface et ne veulent pas sauter d'une solution à l'autre. En outre, les données patrimoniales doivent être
les informations ont la même apparence que si elles avaient été créées dans le nouveau système. Ces deux conditions plaident en fait à nouveau pour une approche brownfield, que les DSI et leurs collègues du management préfèrent éviter au profit du changement et de l'innovation.

Transition sélective des données

Entre le brun et le vert, les nuances de couleurs les plus diverses se sont établies en matière de transformation. Toutes ont cependant en commun le fait que seule une partie des données existantes est transformée et transférée dans le nouveau monde. En principe, cette approche est la bonne pour réduire les coûts de la transformation et de la migration. En outre, elle offre en principe la flexibilité nécessaire pour optimiser le futur système indépendamment des données de base et des données de mouvement, dans une sorte de combinaison de brownfield et de greenfield. La reprise sélective des données est certainement la bonne solution pour les clients SAP existants disposant d'un grand environnement système, qui misent largement sur la continuité malgré les adaptations et souhaitent construire le nouvel environnement en grande partie sur les systèmes précédents.

Mais : les départements spécialisés veulent aussi voir toutes les données historiques dans le nouveau système et pouvoir y accéder. Et ils ont raison de le faire ! Les entreprises n'ont jamais eu autant besoin qu'aujourd'hui d'accéder à leurs informations historiques, parfois depuis des décennies. Avec la numérisation, les offres se composent de plus en plus de produits, de services complémentaires et de prestations de maintenance. De telles offres complexes ont des cycles de vie allant de dix à cinquante ans. Les informations historiques, même si elles remontent déjà à de nombreuses années et ne sont plus modifiées dans les activités quotidiennes, acquièrent ainsi la même pertinence que les informations opérationnelles pour le développement de produits et l'optimisation continue des offres et de leur qualité sur la base d'analyses de données.

Migration vs. Transformation

Mais du point de vue des responsables de projet chargés de la transformation SAP, ce souhait - la migration - des départements spécialisés est irréalisable. Il n'est pas possible de faire plus que de reprendre les données des deux ou trois dernières années pour conserver la flexibilité nécessaire à l'adaptation et à l'optimisation, au moins partielle, du nouveau système.

Mais même lorsque l'informatique l'emporte sur l'entreprise, la reprise sélective des données s'avère sous-optimale dans de nombreux cas : premièrement, cette approche fonctionne surtout lorsque les systèmes source et cible sont très similaires, c'est-à-dire lorsqu'elle est appliquée par exemple entre la dernière version d'ECC (Business Suite 7) et S/4. Deuxièmement, les outils de transformation sélective des données qui travaillent au niveau des tables peuvent entraîner un risque d'incohérence. Qui peut garantir que le chargement, entre autres, directement orienté table, des enregistrements de données dans 100 000 tables et plus, dans le cas d'environnements SAP de grande taille, se déroulera sans erreur ?

Certes, ce risque peut être limité par un effort de test très important. Mais cela ne contribue généralement que de manière limitée au nettoyage des données afin d'optimiser leur qualité pour le nouvel environnement système. En conséquence, les clients SAP existants n'ont que peu de possibilités de veiller à une base de données harmonisée, qui se nourrit aussi bien de données provenant des systèmes SAP hérités que de systèmes tiers.

Pas d'harmonisation

Or, cette possibilité d'harmonisation est une condition essentielle pour réaliser l'objectif d'une entreprise pilotée par les données - sans parler du fait que, dans l'approche de la reprise sélective des données, analogue à Brownfield, le passage au cloud public ou même le passage (partiel) à un système d'un fabricant tiers n'est possible que de manière très limitée. Le fait que les données et leurs dépendances constituent le défi fondamental du changement de génération SAP est une prise de conscience qui est en train de se répandre au sein de la communauté SAP. Que peuvent donc faire les clients existants de SAP ? Peuvent-ils vraiment choisir uniquement entre les inconvénients des différentes approches ? L'idéal serait bien sûr une voie de transformation aussi simple techniquement que l'approche Brownfield, mais aussi flexible que l'approche Greenfield.
Méthode qui permet aux entreprises de se débarrasser de leurs vieilles habitudes, d'implémenter de nouveaux processus et modèles commerciaux et de ne transférer dans le nouveau système que des données de base de la meilleure qualité possible. Mais est-ce vraiment possible ?

Transformation en un clic

Oui, il existe une solution durable qui non seulement résout les anciens problèmes, mais ouvre aussi de nouvelles voies. La condition préalable est toutefois que la transformation au niveau des applications se fasse indépendamment du niveau des données. Pour ce faire, il faut que toutes les informations patrimoniales et leur contexte commercial puissent être extraits intégralement, sans modification et surtout de manière efficace et rapide, et transférés sur une plateforme propre. Les clients SAP existants ont ensuite le libre choix de transférer leur environnement applicatif actuel, avec tous les objets commerciaux, les adaptations et les développements propres existants, dans le nouveau monde S/4 via l'outil de conversion, ou de repartir à zéro, à la manière d'un greenfield.

Mais que se passe-t-il avec les données ? Tout d'abord, il serait préférable de parler de données historiques plutôt que de données patrimoniales, car ce dernier terme pourrait résonner dans la plupart des oreilles comme si on pouvait les ranger quelque part dans des archives et les laisser prendre lentement la poussière. Mais c'est le contraire qui est vrai : bienvenue dans le monde du big data et de l'analytique, dont l'entreprise pilotée par les données est quasiment tributaire !

Tout est basé sur les données

Pour ce faire, la partie des informations des systèmes existants qui sont également nécessaires dans S/4 Hana doit pouvoir être filtrée sur une plateforme séparée selon des critères commerciaux, nettoyée, enrichie de données provenant de systèmes tiers et optimisée. Alors qu'après l'optimisation, seuls cinq à dix pour cent des données de mouvement doivent encore être transformés et migrés vers S/4, la quantité de données de base se réduit à environ vingt pour cent, qui sont alors également reprises dans une qualité optimale via des outils standard comme le Migration Cockpit de SAP. Par nature, tout cela doit être largement automatisé.

Parallèlement, cette plateforme doit être en mesure d'afficher les données historiques dans le monde S/4 via SAP GUI ou Fiori, comme si elles y avaient été créées. Cette transformation à la volée via le procédé de Technical Structure Mapping - sans bien sûr modifier la structure originale des données historiques sur la plateforme elle-même - doit également être automatique. Ce degré d'automatisation, de l'extraction des données à leur affichage dans le nouvel environnement, est l'essence même d'une transformation en un clic.

Cartographie de la structure technique

Bien que l'approche de la reprise sélective des données ne soit pas différente, la transformation en un clic présente des avantages supplémentaires décisifs : toutes les informations - historiques et opérationnelles - peuvent être nettoyées, enrichies facilement avec des données provenant de sources tierces et préparées de manière optimale pour des scénarios de big data et d'analyse. Cela ne vaut d'ailleurs pas seulement pour les données de mouvement, mais aussi pour toutes les données de base, y compris les bases de données clients, fournisseurs et articles, si importantes pour la transformation numérique.

En outre, la décision concernant les informations à transformer et à migrer vers S/4 Hana à partir de l'ensemble des données existantes est prise de manière flexible en fonction des critères commerciaux pertinents des clients. Ainsi, au lieu de reprendre par exemple toutes les données des trois dernières années, les clients SAP existants peuvent délibérément décider de transformer et de migrer uniquement les commandes en cours et les données de base des clients et des fournisseurs avec lesquels ils entretiennent des relations commerciales continues.

Dans ce scénario, le CFO peut également être apaisé. En effet, lorsque les directeurs financiers et les départements spécialisés argumentent et agacent parfois leurs collègues IT en leur disant qu'ils ont besoin de toutes les données existantes dans le nouveau système, il y a ici un malentendu : En réalité, ils n'ont pas besoin des données historiques dans le nouveau système, mais "seulement" d'y accéder depuis l'interface de SAP S/4. Avec l'approche de transformation en un clic, cela ne pose aucun problème. Lorsqu'ils accèdent aux données historiques, les utilisateurs ne remarquent même pas que celles-ci ne sont pas conservées dans la base de données Hana.

Une base de données propre et transparente pour la concurrence dans l'économie numérique, une réduction massive des données à transformer et à migrer et leur reprise avec les outils standard de SAP ne sont que quelques-uns des avantages de cette approche. À cela s'ajoute : Après le transfert des informations historiques sur la plateforme séparée, les systèmes et applications patrimoniaux peuvent être complètement mis hors service. Cela permet en général de supprimer 80 % des coûts d'exploitation. Le temps et les coûts nécessaires au filtrage, à la transformation et à la migration des données proprement dits sont réduits de moitié. Le noyau de la plate-forme logicielle nécessaire à cet effet a déjà été utilisé dans plus de 2000 projets dans le monde entier.

Amélioration continue

Étant donné que les données nouvellement ajoutées dans l'univers S/4 peuvent être transférées en continu sur la plateforme, le nouvel environnement et en particulier la base de données de calcul en mémoire Hana restent durablement légers. Le potentiel d'économie qui peut être atteint grâce à ce rightsizing continu devrait être de 25% ou plus sur l'ensemble du cycle de vie du nouvel environnement.

Autre point décisif : la transformation en un clic peut également aider les clients qui ont opté pour les approches classiques Brownfield, Greenfield et Selective Data Transition et qui ont déjà pris les premières mesures. En effet, elle complète ces méthodes par leurs avantages spécifiques, à commencer par l'identification et la conception de règles de filtrage, l'historisation, la préparation et l'harmonisation des données, jusqu'à leur intégration dans SAP S/4. Elle permet en outre le déclassement complet des systèmes existants, avec les économies de coûts d'exploitation correspondantes.

Sûr pour la révision, y compris l'héritage

Tout cela ne doit pas faire oublier la sécurité juridique. Toutes les données et tous les documents historiques sont stockés sur la plateforme de manière à ce qu'ils puissent être révisés. De plus, une plateforme qui adopte l'approche One-Click-
Transformation, il est possible de gérer les informations stockées jusqu'au niveau de l'enregistrement ou du document individuel, tout au long de leur cycle de vie, jusqu'à leur suppression légale à l'expiration des délais de conservation en vigueur. Cela permet également de répondre aux exigences légales accrues, comme par exemple les prescriptions de suppression ciblées du règlement général européen sur la protection des données (RGPD).

L'approche de la transformation en un clic se caractérise notamment par la séparation systématique et continue des données historiques et des données opérationnelles. La séparation systématique entre les données et les algorithmes n'a pas non plus d'équivalent sur le marché. Cela permet de résoudre le problème fondamental des interdépendances décrites. Mais les économies massives réalisées sur les coûts de transformation et d'exploitation ainsi que sur les dépenses liées au nettoyage et à l'harmonisation des données ne font pas tout, loin s'en faut. Car en plus, la plateforme qui soutient cette approche conserve pour ainsi dire les connaissances de transformation et les met à disposition durablement : pour l'accès aux données historiques à partir de SAP S/4, pour l'accès aux données historiques à partir de systèmes non SAP et pour la mise à disposition de ces données pour des applications tierces comme par exemple des solutions d'analyse.

Le transfert des données sur une plateforme séparée et moderne contribue par ailleurs à une meilleure sécurité, car cette plateforme peut être patchée à l'avenir, contrairement à certains systèmes hérités. En effet, de nombreux systèmes hérités doivent être exploités sur d'anciennes versions de logiciels et ont donc généralement besoin de systèmes d'exploitation et de bases de données obsolètes. Or, dans de nombreux cas, les fabricants ne mettent plus de correctifs de sécurité à disposition pour ces systèmes. 

En outre, une telle plateforme peut servir de mémoire numérique pour les données pertinentes pour l'entreprise et leur contexte, qui sont créées dans des solutions SaaS et autres solutions en nuage, mais pour lesquelles les droits sur ces données ne sont pas détenus par les entreprises, mais par les fournisseurs de ces solutions - afin que l'accès à ces données soit maintenu même après la résiliation des abonnements. Enfin, une telle plateforme jette les bases de scénarios IoT ou de jumeaux numériques de produits, de machines et d'installations, de bâtiments, etc. qui, enrichis de données d'exploitation, peuvent améliorer de manière décisive leur fabrication, leur fonctionnement, leur entretien et leur gestion.

Un seul clic pour accéder à la Data Fabric

Tout cela est possible parce qu'une telle plate-forme conserve les informations historiques avec leur contexte commercial, mais indépendamment de leurs systèmes d'origine. Le grand nombre d'échecs de projets de data lakes, dans lesquels le contexte commercial est absent, montre que cette approche de plateforme aide bien mieux à maîtriser les exigences futures en matière de gestion des données à l'échelle de l'entreprise. Les clients existants de SAP se rapprochent ainsi de l'objectif d'une Data Fabric recommandé par les analystes. Une plate-forme juridiquement sûre pour la gestion du cycle de vie des informations d'entreprise provenant de systèmes SAP et non SAP constitue la base de la transformation en un clic vers SAP S/4 Hana et l'entreprise pilotée par les données, pour laquelle une demande de brevet a été déposée. La plateforme utilisée à cet effet s'appelle JiVS IMP et provient du fournisseur suisse Data Migration International.

Article à télécharger en PDF