Adieu aux avant-projets !

Les clients existants de SAP n'ont plus que quatre ans pour transformer leur environnement de systèmes et d'applications SAP actuel vers la nouvelle génération S/4 sans frais de maintenance supplémentaires. Et pourtant, ils hésitent. L'une des raisons principales - comme le montrent régulièrement les entretiens avec les utilisateurs SAP - n'est pas seulement la transformation elle-même, mais aussi la charge de travail supplémentaire redoutée pour les projets préparatoires. Il s'agit notamment de

Archivage : de nombreux clients SAP existants sont assis sur des montagnes de données anciennes. Comme la base de données Hana s'exécute dans une mémoire vive toujours coûteuse, ils souhaitent réduire le plus possible le stock de données avant la transformation.

New GL : De nombreuses entreprises pensent qu'elles gagneront du temps en introduisant d'abord le nouveau ledger général (GL). Après tout, le nouveau grand livre SAP existe déjà depuis ECC 6.0. D'un autre côté, c'est un must dans le monde S/4.

Hana : d'autres encore mettent en œuvre SAP Hana avant de se consacrer aux applications. En scindant la transformation en un projet de données et un projet d'applications, ils espèrent obtenir un projet global moins complexe, mais ne se font pas d'illusions sur le fait qu'il s'agit là d'un projet purement technique qui, en soi, n'a que peu ou pas d'utilité commerciale.

Nouvel objet commercial, GP : La base de données Hana nécessite en général une autre structure de données. De plus, le nouvel objet de gestion (BO) partenaire commercial (GP) réunit les anciens BO client et fournisseur. De nombreux clients SAP existants considèrent donc qu'il est nécessaire d'adapter la structure de leurs données clients et fournisseurs actuelles à GP avant même leur migration.

Le nettoyage des données : De nombreux clients SAP existants veulent, à juste titre, profiter de la transformation pour nettoyer leur stock de données des erreurs et des doublons. Après tout, le passage à S/4 est un élément central de leur stratégie d'avenir, pour laquelle la règle est : sans qualité des données, pas de numérisation.

Point aveugle : les données existantes

Pour éviter tout malentendu, les réflexions qui sous-tendent les différents avant-projets sont tout à fait justifiées. Et pourtant, elles ne parviennent pas à résoudre un problème central : celui de savoir ce qu'il adviendra des données et des systèmes existants une fois la transformation achevée. C'est le point aveugle, qui est trop rarement perçu, notamment parce que les équipes de projet chargées de la transformation ne s'y intéressent pas (ou ne doivent pas s'y intéresser).

Il semble presque que de nombreux clients SAP existants se soient résignés à continuer d'exploiter leurs anciens systèmes après le passage au monde S/4 et à stocker dans des archives leurs anciennes données, dont la structure ne peut parfois pas être modifiée pendant des décennies pour des raisons légales. Ce dernier point signifie toutefois que les systèmes patrimoniaux doivent eux aussi continuer à fonctionner aussi longtemps, car les données archivées ne peuvent être appelées et affichées qu'avec eux.

Outre le surcroît de travail à long terme, cette approche comporte des risques considérables en termes de sécurité informatique et juridique. Les anciens systèmes qui continuent à fonctionner ne sont généralement plus entretenus, les correctifs de sécurité importants ne sont plus appliqués et les cybercriminels s'en réjouissent. À cela s'ajoutent constamment de nouvelles exigences du législateur.

Les prescriptions du règlement européen sur la protection des données ou de la nouvelle loi suisse sur la protection des données, comme par exemple la possibilité de supprimer de manière ciblée au niveau de l'enregistrement individuel, ne peuvent plus du tout être implémentées dans de nombreux anciens systèmes ou seulement au prix d'efforts considérables.

En outre, dans ce scénario, les utilisateurs SAP se voient refuser en grande partie, voire totalement, l'accès direct aux données héritées. Cela représente un risque non négligeable pour la productivité et l'assurance qualité dans les entreprises. Mais transformer toutes les données existantes et les migrer vers S/4 pour cette raison n'a aucun sens sur le plan économique.

Transformation sans héritage

Tous les avant-projets ont en commun un important point aveugle et les risques économiques, sécuritaires et juridiques qui y sont liés. Les clients SAP existants devraient donc envisager d'adopter une approche radicalement nouvelle qui non seulement résout les problèmes, mais rend également superflus les projets supposés nécessaires et élimine leurs risques.

Cette approche consiste à gérer le cycle de vie complet des données patrimoniales jusqu'à leur suppression définitive et légale séparément, c'est-à-dire détachées des systèmes et applications patrimoniales, et à les synchroniser avec la gestion du cycle de vie des applications et systèmes cibles d'un paysage S/4 Hana.

Pour cela, il faut une plateforme qui permette de conserver et de supprimer toutes les données héritées des systèmes SAP et non-SAP en toute sécurité juridique, mais qui offre en même temps toutes les possibilités de traitement ultérieur de ces données, comme leur réduction, leur sélection, leur optimisation et leur transformation via le Migration Cockpit et l'Application Layer. Cette plateforme est intégrée à S/4 pour adapter à la volée et automatiquement les données héritées aux nouvelles structures de données, comme celles de l'objet de gestion GP, et les afficher dans SAP Fiori. Cela se fait comme si elles avaient été créées dans S/4. Cette fonctionnalité est rendue possible par le fait que toutes les métadonnées relatives à l'environnement SAP et non-SAP à remplacer sont saisies et enregistrées dans un cockpit de transformation en un clic.

De plus, chaque étape du projet est documentée et la plate-forme sait quel système hérité les entreprises peuvent mettre hors service et éliminer. En appuyant sur un bouton et en utilisant un procédé turbo, il est possible d'extraire toutes les données patrimoniales des archives ADK via la couche d'application et de mettre ainsi leurs informations sur le cycle de vie des données et des systèmes à disposition d'autres solutions dans le domaine de la gestion du cycle de vie des applications (ALM).

Une plate-forme pour tout

Les clients existants de SAP ne doivent pas craindre les avant-projets, les problèmes d'héritage et la confusion des outils. Une telle plateforme permet aux clients SAP existants de faire d'une pierre trois coups : premièrement, la plateforme analyse et gère le cycle de vie complet de toutes les données héritées et, deuxièmement, elle offre toutes les fonctionnalités nécessaires à la conservation et à l'analyse juridiquement sûres ainsi qu'à la transformation et à la migration sélectives de ces données et, troisièmement, elle résout une fois pour toutes le problème des applications et systèmes hérités lors de la transformation et transforme chaque projet Brownfield en projet Greenfield.

Le client SAP existant ne remplace pas le Readiness-Check de SAP, qui porte sur les processus et les normes, mais le complète en tant que noyau d'une Data Fabric intelligente à l'échelle de l'entreprise. De ce fait, la solution DMI, en tant que "plateforme unique pour tout", élimine la complexité de l'enchevêtrement d'outils autrement typique de la couche de données. La plateforme qui peut éclairer le point aveugle de la transformation S/4 en appuyant sur un bouton et rendre superflus les avant-projets en cours de route a un nom : JiVS IMP.

jivs.com