L’auteur : Thierry Julien, PDG du groupe TJC | 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 (probablement 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 généraux 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 de la mise hors service des systèmes informatiques legacy dans le contexte de la migration vers SAP S/4HANA.
Table des matières
- Données et systèmes legacy
- Décommissionnement des systèmes SAP legacy en vue de la migration vers S/4HANA
- Pourquoi retirer les systèmes SAP existants ?
- Éviter les vulnérabilités du système
- Réduisez les coûts, conservez les données en or
- Impératif de conformité : répondre aux exigences en matière de fiscalité et d’audit
- N’oubliez pas les exigences en matière de confidentialité des données
- N’oubliez pas les exigences en matière de confidentialité des données
- Exemple d’étude de cas – avantages du décommissionnement des systèmes legacy
- Les leçons tirées du démantèlement des systèmes legacy
- Conclusion
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 la première à laquelle nous pouvons penser aujourd’hui 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 hérités ?
Le décommissionnement des systèmes legacy permet de retirer 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 conservation du système. Les données peuvent être ré-accédées en cas de besoin à l’aide d’une application de système patrimonial, 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 patrimoniales sur une plateforme unique avant et après la migration vers S/4. Application de système patrimonial d’entrepriseELSA est une application construite sur SAP BTP qui permet d’accéder aux données, documents et rapports hérités 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).
Mise hors service 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 un facteur important.
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 un nombre croissant de scénarios, 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 termes 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 patrimoniales, souvent à des fins de conformité fiscale et d’audit.
Dans tous les cas, il est impératif de retirer l’ancien système SAP et de conserver l’accès aux données en or. Il s’agit d’un malentendu classique selon lequel la migration brownfield ne nécessite pas la mise hors service de l’ancien système. Pourquoi? Une mise à jour technique ne prouve pas que les données sont complètes ou inchangées, de sorte que le système S/4HANA ne pourra jamais servir d’archive fiscale pour les données créées dans le système existant.
Il existe potentiellement d’autres options, telles que le maintien en vie 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 que la congélation d’un 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 professionnel 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 corrigé et exposé à des risques. Nous avons écrit sur les les avantages et les inconvénients de l’utilisation de machines virtuelles pour le démantèlement de systèmes existants.
En résumé, le retrait 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 de la mise hors service de votre paysage de systèmes hérités.
Pourquoi retirer les systèmes SAP existants ?
Éviter les vulnérabilités du système
Les partenaires de mise en œuvre de 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 attrayantes à 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 des 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 qui explique pourquoi les systèmes patrimoniaux non contrôlés sont plus susceptibles de subir des cyberattaques et explique comment la mise hors service des systèmes patrimoniaux élimine ce risque.
Réduisez les coûts, conservez les données en or
La mise hors service 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 :
- Réduisez vos coûts et optimisez 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 retirant les anciens systèmes, les frais généraux de maintenance et de ressources seront considérablement réduits.
- Économisez 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 à charger dans HANA et estimer les besoins en mémoire.
- Aidez à 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émantèlement utilisant une application cloud certifiée SAP comme ELSA est une formidable opportunité de 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, il est inévitable que la plupart des organisations accumulent d’importants volumes de données dispersées dans des systèmes existants obsolètes. Les responsables 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 de retrait 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 : TJC Group
Enfin, les données doivent être conservées en tant qu’archives fiscales, extraites et stockées sous forme de fichier plat, 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 de déclassement 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 pour le déclassement est celui de toutes les solutions ELT (Extract Load and Transform) et ETL (Extract Transform and Load) 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 hérités 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, la mise hors service 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 d’étude de cas – avantages du démantèlement des systèmes existants
- Énoncé du problème
Le groupe TJC a récemment été chargé de la mise hors service des systèmes patrimoniaux d’une entreprise manufacturière américaine d’envergure mondiale qui souhaitait mettre hors service son système SAP ECC patrimonial avant de passer à 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 le groupe TJC en six mois, et il a apporté à l’utilisateur de nombreux avantages, notamment une énorme économie financière de 250 000 dollars.
L’entreprise a élaboré un dossier solide pour le déclassement qui proposait une implémentation S/4 HANA des données financières qui excluait 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 était d’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 du groupe TJC à des fins de reporting pour les utilisateurs futurs.
Le calendrier du projet était relativement serré, car le client souhaitait achever le processus de déclassement 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
Le groupe 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 patrimoniales 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 nuage. Ce choix a permis de minimiser les coûts et de conserver les données dans le nuage, 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 d’essayer de simuler une récupération 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 professionnels.
Désormais, les utilisateurs finaux peuvent consulter toutes les données historiques déclassé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 le déclassement des systèmes existants avec le groupe TJC lui a permis d’économiser plus de 250 000 dollars par an sur une base continue, ce qui aurait été encouru chaque année pour payer les coûts de maintenance et de stockage. Si vous souhaitez en savoir plus sur cette réussite, contactez-nous.
Les enseignementsacquis du démantèlement des systèmes hérités du passé
La gestion d’un système SAP éteint 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 héritées. Lorsque vous envisagez une migration vers SAP S/4 HANA, le fait de traiter de manière proactive la question du déclassement des données patrimoniales 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 à S4HANA ; la question de savoir ce qu’il faut faire de leurs systèmes existants reste un obstacle majeur.
- La mise hors service des systèmes informatiques existants est souvent la dernière chose à envisager, mais elle peut faire la plus grande différence 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 existantes sur une plateforme unique avant et après la migration vers S/4.
- ELSA by TJC 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.