Tout savoir sur le décommissionnement des systèmes legacy dans le cadre de la migration vers S/4HANA

L’auteur : Thierry Julien, PDG de TJC Group | Co-auteur : Laura Parri Royo, directrice du marketingou chez TJC Group

La migration vers SAP S/4 HANA n’est complète que si l’on examine attentivement ce qu’il faut faire de toutes les données contenues dans la base de données du système legacy (souvent un système SAP ECC). Dans certains cas, le volume de données d’une base ECC legacy peut atteindre des dizaines de téraoctets, ce qui entraîne d’importants frais de stockage de données si l’entreprise choisit de tout transférer dans la base de données HANA. Cet article examine les arguments en faveur des arrêts de systèmes historiques dans le contexte de la migration vers SAP S/4HANA.

Données et systèmes legacy

Il existe de nombreuses raisons pour lesquelles une entreprise peut avoir besoin d’arrêter un système ou une application informatique, mais de nos jours une des principales raisons est la migration vers SAP S/4HANA. Inévitablement, les entreprises SAP ont un choix important à faire lorsqu’il s’agit de gérer l’ancien système SAP (ou tout autre système ERP utilisé), quelle que soit l’approche de migration choisie. Dans tous les cas, il est crucial de conserver l’accès aux données historiques requises pour des raisons de conformité fiscale et d’audit ou pour les besoins de l’entreprise. Mais comment ? Quel est le meilleur plan d’action pour traiter les systèmes SAP historiques ?

Le décommissionnement des systèmes legacy permet d’arrêter l’ancien système en extrayant les informations historiques (données, documents, rapports et documentation) et en les stockant ailleurs pour les préserver, ce qui élimine les dépenses liées à la maintenance du système. Il est possible d’accéder à nouveau aux données en cas de besoin à l’aide d’une application de systèmes legacy, telle qu’ELSA. TJC Group aide les clients SAP à accélérer leur migration vers SAP S/4HANA en fournissant un accès aux données historiques sur une plateforme unique avant et après la migration vers S/4. L’Application de systèmes legagy d’entreprise ELSA est une application construite sur SAP BTP qui permet d’accéder aux données, documents et rapports historiques soit à partir de l’application cloud elle-même, soit à partir de SAP S/4HANA (à travers une application UI5, UI5 étant la version open-source de FIORI).

Arrêt des systèmes SAP existants en vue de la migration vers S/4HANA

Dans la plupart des cas de migration SAP, il n’est tout simplement pas rentable de conserver toutes les données existantes. La question de savoir s’il faut procéder à une mise en œuvre de type greenfield, brownfield ou SDT (Selective Data Transition) devient donc une question-clé.

Soyons honnêtes : le SDT est probablement la meilleure option dans la plupart des cas, étant donné que SAP fournit une feuille de route pour un SDT lean SAP. SAP lean SDT lean SAP, gratuitement, avec la la solution SAP Cloud ALM (CALM).

Dans de nombreux cas, les organisations choisissent de repartir à zéro et de réaliser une implémentation « greenfield », sans que les données existantes ne soient intégrées dans la nouvelle base de données. Cette approche est rentable en matière de coûts de stockage S/4 HANA, mais elle présente d’autres inconvénients. D’autres utilisateurs opteront pour une implémentation « brownfield » et se contenteront d’intégrer un sous-ensemble de données historiques, souvent à des fins de conformité fiscale et d’audit.

Dans tous les cas, il est impératif d’arrêter l’ancien système SAP et de conserver l’accès à des données qui peuvent être précieuses. On se trompe souvent en considérant que la migration brownfield ne nécessite pas l’arrêt de l’ancien système. Pourquoi ? Une mise à jour technique ne prouve pas que les données sont complètes ou inchangées, c’est pourquoi le système S/4HANA ne pourra jamais servir d’archive fiscale pour les données.

Il existe potentiellement d’autres options, telles que le maintien du système existant, coexistant avec SAP S/4HANA. Toutefois, cette solution s’accompagne de coûts de licence et de maintenance élevés.

On pourrait faire valoir qu’un freeze du système dans une machine virtuelle permet de faire le travail à un coût bien moindre. Mais ce n’est pas le cas. Tout d’abord, démarrer le système chaque fois qu’un utilisateur a besoin d’y accéder prend du temps et s’accompagne de risques élevés pour la sécurité. Plus important encore, au bout de quelques années, le système sera obsolète, non patché et exposé à des risques. Nous avons écrit sur les les avantages et les inconvénients de l’utilisation de machines virtuelles pour l’arrêt des systèmes historiques.

En résumé, l’arrêt des systèmes SAP ECC ou R3 simplifiera le paysage informatique global et réduira les coûts d’administration et de maintenance à long terme.

Nous vous recommandons vivement de regarder la rediffusion du webinaire ^SAP® S/4HANA Update : ^SAP®ECCLegacy System Decommissioning pour découvrir une approche rentable concernant l’arrêt des systèmes historiques.

Pourquoi arrêter les systèmes SAP existants ?

Éviter les vulnérabilités du système

Les partenaires implémentant SAP suggèrent souvent une solution de contournement facile : l’utilisateur « gèle » son système existant sur une machine virtuelle. Ils peuvent également conseiller de laisser fonctionner le système existant et de ne rien faire. Toutefois, ces deux « options » ne sont ni conformes ni viables à long terme, bien qu’elles puissent être très attractives à court terme lorsque les coûts sont un facteur important.

En fin de compte, aucun des deux n’est efficace car dans chaque cas vous devrez faire face à des coûts de maintenance importants pour maintenir l’ancien système en fonctionnement ou, si vous décidez de ne pas vous en préoccuper, vous serez vulnérable aux attaques de pirates informatiques, ce qui pourrait déclencher une demande de ransomware et entraîner des coûts encore plus élevés.

Nous avons rédigé un article qui explique pourquoi les systèmes historiques non contrôlés sont plus susceptibles de subir des cyberattaques et explique comment l’arrêt des systèmes historiques élimine ce risque.

Réduisez les coûts, conservez les données en or

L’arrêt des anciens systèmes SAP permet de libérer des budgets de maintenance, de réduire les coûts de matériel et les besoins en ressources. Cela permettra :

• De réduire vos coûts et d’optimiser votre investissement informatique. Le maintien en vie d’anciens systèmes peut s’avérer très coûteux : coûts de maintenance élevés, coûts des licences SAP, infrastructure et personnel nécessaire pour maintenir ces systèmes à jour. En arrêtant les anciens systèmes, les frais de maintenance et de ressources seront considérablement réduits.
• D’économiser sur les coûts de licence HANA. La mémoire HANA suit un modèle de tarification au format T-shirt [LP1] [LP2] qui est très complexe et coûteux. Toute entreprise à la recherche d’une solution rentable doit réfléchir soigneusement aux données à migrer dans HANA et estimer les besoins en mémoire.
• D’aider à gérer les besoins en mémoire de HANA. L’évolutivité de la mémoire HANA est limitée, ce qui signifie qu’il n’est pas si simple de passer au niveau suivant. Nous traitons fréquemment des systèmes S/4HANA avec des problèmes de performance ACDOCA.

Un programme de décommissionning utilisant une application cloud certifiée SAP telle qu’ELSA est une formidable opportunité pour réduire les coûts de licence et d’infrastructure, d’énergie et de maintenance, ce qui a un impact positif sur la facture de migration vers S/4HANA.

Impératif de conformité : répondre aux exigences en matière de fiscalité et d’audit

Au fil du temps, la plupart des organisations vont inévitablement accumuler d’importants volumes de données dispersées dans des systèmes existants obsolètes. Les managers supposent souvent que ces systèmes sont rarement utilisés : ils contiennent pourtant des référentiels de données importants, essentiels pour les besoins de l’entreprise et la conformité avec les réglementations fiscales et d’audit. Par conséquent, les données des systèmes en cours d’arrêt doivent souvent être archivées et conservées à la fois pour des raisons d’audit et de conformité et pour réduire la quantité de données transférées vers SAP S/4HANA.

Figure 2. L’iceberg de la conformité fiscale et de la confidentialité des données. Source : TJC Group

Enfin, les données doivent être conservées en tant qu’archives fiscales, extraites et stockées sous forme de fichiers plats, afin de prouver qu’elles n’ont pas été modifiées. Par exemple, ELSA extrait un rapport d’audit détaillé de toutes les données qui comprend la preuve de leur exhaustivité et de leur non-modification. Une solution d’arrêt de systèmes qui ne fournit pas ce niveau de détail ne répondra pas aux exigences fiscales et d’audit.

Un exemple typique de solution non conforme d’arrêt de systèmes serait fondé sur une solution ELT (Extract Load and Transform) ou ETL (Extract Transform and Load) toutes deux basées sur le transfert de base de données à base de données (y compris les solutions les plus récentes mises sur le marché). Ces solutions peuvent ne pas fournir de preuve de non-modification et, la plupart du temps, ne pas garantir l’exhaustivité.

N’oubliez pas les exigences en matière de confidentialité des données

Les exigences en matière de confidentialité des données sont assez strictes dans l’EMEA, mais de nouvelles lois sur la confidentialité des données continuent d’entrer en vigueur dans le monde entier. Par exemple, la loi indienne sur la protection des données, la loi DPDP, est entrée en vigueur l’année dernière en août 2023, et la loi californienne sur la protection de la vie privée des consommateurs (CCPA) est entrée en vigueur en janvier 2020. Aux États-Unis, les données financières doivent généralement être conservées pendant sept ans, et ce délai passe à dix ans au Canada et en Europe. À l’échelle mondiale, la durée de conservation des données relatives aux ressources humaines est plus longue. Dans certains pays et secteurs d’activité, les données relatives aux ressources humaines doivent être conservées pendant plus de trente ans !

Dans un environnement SAP, le respect des lois sur la confidentialité des données peut inclure l’obligation de supprimer et d’anonymiser les données sur demande. Par exemple, cela peut impliquer la suppression de toutes les transactions liées à un client avant que celui-ci ne puisse être supprimé, afin de préserver l’intégrité de la base de données.

La simple suppression des données historiques n’est pas une option. Des règles de conformité strictes doivent être respectées, avec des durées de conservation variables d’un pays à l’autre.

Il est difficile de s’assurer que les systèmes SAP historiques respectent les lois sur la confidentialité des données, car ces systèmes n’ont pas été conçus à l’origine pour cela. Cependant, les organisations sont toujours tenues de respecter ces exigences.

N’oubliez pas les exigences en matière de confidentialité des données

De nombreux clients SAP ont investi dans SAP RISE with SAP afin d’accélérer leur migration vers S/4 HANA. Si vous envisagez d’utiliser RISE, outre les économies de coûts de maintenance réalisables, SAP inclut le rachat de la licence perpétuelle SAP ECC. Attention, dans ce cas, le système existant ne sera plus accessible après un certain délai (généralement 12 mois). Par conséquent, l’arrêt du système SAP existant est indispensable.

Simulation des coûts de mémoire dans un scénario RISE avec SAP

Le coût de la mémoire dans RISE avec SAP augmente de manière géométrique et non linéaire. Supposons que dans SAP S/4HANA la taille de la base de données augmente de 1 To la première année et que le coût grimpe à 150 k$ par an et par To.

La croissance de la mémoire est linéaire

Année 1 2 3

Volume 1 2 3

Coût total = n*(n+1)/2

Coût total 1 3 6

Avec une croissance de 1 To par an, une organisation paiera 6 To sur une période de 3 ans au lieu de 3 To. C’est pourquoi vous finirez par payer plus cher pour la mémoire.

Exemple et étude de cas – les avantages d’arrêter les systèmes existants

• Énoncé du problème

TJC Group a récemment été chargé de l’arrêt des systèmes historiques d’une entreprise manufacturière américaine d’envergure mondiale qui souhaitait arrêter son système SAP ECC legacy avant de migrer vers SAP S/4 HANA. Cette entreprise a également choisi de migrer les données vers l’application Enterprise Legacy System Application (ELSA) de TJC. L’essentiel de ce projet a été réalisé par TJC Group en six mois, et il a apporté à l’utilisateur de nombreux avantages, notamment d’importantes économies pour 250 000 dollars.

L’entreprise a élaboré un scénario d’arrêt qui proposait une implémentation « brownfield » S/4 HANA des données financières excluant les sociétés cédées. Alors qu’à l’origine les données RH de l’entreprise étaient stockées dans HCM, elles avaient été précédemment migrées vers SAP Success Factors.

• Solution adoptée

La maintenance de l’ancien système ECC en plus de l’exécution de S/4 HANA et de Success Factors avait un coût prohibitif et la seule solution pour contenir les coûts et assurer la conformité réglementaire était de décommissionner le système SAP ECC et de mettre en œuvre la solution ELSA de TJC à des fins de reporting pour les utilisateurs futurs.

Le calendrier du projet était relativement serré, car le client souhaitait achever le processus d’arrêt de système avant le renouvellement de la prochaine licence SAP afin de réduire les coûts. En outre, Oracle a exigé une preuve de l’arrêt de la base de données afin que le système ne puisse pas être gelé (les détails et exigences exacts peuvent dépendre des conditions négociées entre Oracle et le client).

• Mise en œuvre du projet

TJC a commencé le projet en extrayant les tables SAP qui avaient été séparées en fonction du code de l’entreprise et des informations sur l’année fiscale lorsque cela était possible, afin de réduire la quantité de données détenues. Les extractions de données ont été réalisées à l’aide du logiciel Audit Extraction Cockpit (AEC) de TJC. Audit Extraction Cockpit (AEC) de TJC. AEC est un logiciel d’extraction de données certifié par SAP qui a déjà été utilisé avec succès pour préserver les données fiscales et financières. Ces informations historiques ont été téléchargées sur Microsoft Azure Blob, puis sur MySQL, l’une des options de base de données disponibles chez ELSA, choisie pour minimiser les coûts et préserver les données dans le cloud. Ce choix a permis de minimiser les coûts et de conserver les données dans le cloud, afin qu’elles soient facilement accessibles à long terme via ELSA et qu’elles soient peu coûteuses à stocker. Il est important de noter que seules les données nécessaires à la conformité ont été conservées dans MySQL, afin de minimiser la taille de la base de données et les coûts.

• Résultats obtenus

Au cours d’un processus de mise en œuvre en quatre phases, les consultants de TJC ont travaillé en collaboration avec le client pour simplifier les protocoles de conservation des données et fournir des simulations de transactions supplémentaires. Ils ont notamment utilisé ELSA pour construire des requêtes dynamiques afin de simuler une visualisation de données de type SAP. Une fois l’opération terminée, il a été possible d’arrêter définitivement SAP ECC avant la date de renouvellement et de transférer l’accès futur aux données existantes aux utilisateurs.

Désormais, les utilisateurs finaux peuvent consulter toutes les données historiques arrêtées à partir d’ELSA et peuvent exécuter des rapports dynamiques et statiques, ainsi que consulter la documentation d’origine.

Dans l’ensemble, le client a calculé que l’arrêt des systèmes existants avec TJC lui a permis d’économiser plus de 250 000 dollars par an sur une base continue, ce qui correspond chaque année aux coûts de maintenance et de stockage. Si vous souhaitez en savoir plus sur cette réussite, contactez-nous.

Les enseignements de l’arrêt des systèmes historiques

La gestion d’un système SAP qui n’est plus utilisé ne doit pas être sous-estimée. Elle peut s’avérer très coûteuse et une machine virtuelle gelée constitue un risque sérieux pour la sécurité. Il n’est pas possible de patcher une machine virtuelle pour toujours et, à un moment donné, il ne sera plus possible de trouver un hébergement pour les données historiques. Lorsque vous envisagez une migration vers SAP S/4 HANA, le fait de traiter de manière proactive la question des données historiques est toujours payant à long terme. En outre, il est important de ne pas sous-estimer le besoin de l’utilisateur d’accéder aux données historiques, que ce soit pour des audits internes ou externes ou pour enquêter sur des réclamations de garantie sur des produits.

Conclusion

• De nombreux clients SAP sont encore très conservateurs dans leur passage à S/4HANA ; la question de savoir ce qu’il faut faire de leurs systèmes existants reste un obstacle majeur.
• L’arrêt des systèmes informatiques historiques est souvent la dernière chose envisagée, mais elle peut avoir un impact non négligeable sur le coût global de votre paysage informatique.
• TJC Group aide les clients SAP à accélérer leur migration vers S/4HANA en fournissant un accès aux données historiques sur une plateforme unique avant et après la migration vers S/4.
• ELSA apporte de la valeur aux clients en garantissant que les données existantes peuvent être ré-accédées à tout moment avant et après la migration S/4HANA.