Coût de la migration SAP S/4HANA : les facteurs clés à comprendre

Le coût de la migration SAP S/4HANA ne se limite pas à la licence logicielle. Le coût réel provient de l’effort de mise en œuvre, du code personnalisé, de la migration des données, des tests, des temps d’arrêt et de la gestion des systèmes legacy. Voici un aperçu approfondi des principaux facteurs de coût et de la manière dont une meilleure gestion des données peut réduire l’effort de migration.

Introduction

De nombreuses organisations commencent leur planification de migration SAP S/4HANA avec une question majeure : combien cela coûtera-t-il ? Au premier abord, la réponse peut sembler tourner autour des licences, de l’infrastructure, des partenaires d’implémentation et des délais de projet. Ceux-ci sont certainement importants. Cependant, le coût réel d’une migration S/4HANA va généralement beaucoup plus loin.

Le coût est déterminé par le paysage SAP ECC actuel. Des années de code personnalisé, de rapports inutilisés, de codes d’entreprise inactifs, d’anciennes données transactionnelles, de grandes tables, d’interfaces obsolètes et de propriété des données peu claire peuvent tous augmenter l’effort de migration. Dans de nombreux cas, le projet de migration révèle une complexité qui s’est accumulée au fil des ans.

C’est pourquoi les efforts de migration S/4HANA ne peuvent pas être compris uniquement comme un coût de conversion logicielle ou technique. Il s’agit aussi de données, de processus métier, de conformité et de transformation numérique.

Plus une organisation intègre de complexité dans le projet, plus il faut de temps et d’efforts pour préparer, convertir, tester et stabiliser le nouvel environnement. Une base de données volumineuse augmente les besoins en mémoire HANA. Le code personnalisé augmente l’effort de remédiation. Des données mal gérées augmentent les tests et la réconciliation. Les systèmes legacy augmentent les coûts post-migration s’ils ne sont pas pris en compte dès le début.

Un plan de migration pratique commence donc par un principe simple : réduire la complexité inutile avant qu’elle n’atteigne SAP S/4HANA.

Le coût de la migration SAP S/4HANA ne se limite pas à la licence

La licence est généralement le coût le plus visible dans une migration S/4HANA. Elle est facile à identifier, à budgétiser et à discuter en interne. Cependant, elle ne représente qu’une partie du coût total.

Le coût total comprend le projet d’implémentation, la conversion technique, le support conseil, la préparation des données, la remédiation du code personnalisé, la refonte des processus, les tests, la formation, la planification des temps d’arrêt, l’infrastructure et le support après la mise en service. De plus, la plupart des organisations doivent continuer à exploiter les systèmes legacy SAP ECC, les systèmes de test, les environnements sandbox et les plateformes legacy pendant la transition.

Dans l’ensemble, cela signifie que le budget final peut être beaucoup plus élevé que prévu si le projet est planifié de manière trop étroite.

Par exemple, une entreprise peut planifier la conversion technique mais sous-estimer l’impact des données historiques. Si d’anciennes données transactionnelles, des données de base obsolètes et des unités organisationnelles inactives sont reportées, la base de données devient plus volumineuse que nécessaire. Cela peut augmenter les besoins en mémoire HANA, l’effort de sauvegarde, le temps d’exécution de la migration et les dépenses d’exploitation continues.

De même, si le code personnalisé n’est pas évalué tôt, les équipes peuvent découvrir tard dans le projet que des rapports, des intégrations ou des améliorations clés doivent être adaptés pour S/4HANA. Cela peut retarder les tests et créer un effort de conseil supplémentaire.

Le coût de la migration ne concerne donc pas seulement le passage à un nouveau système. Il s’agit de bien préparer l’ancien système afin que le nouveau système n’hérite pas de coûts inutiles.

Frais d’implémentation et de conseil

Les frais d’implémentation et de conseil sont souvent l’une des plus grandes parties du budget d’une migration S/4HANA. Ces frais couvrent les ateliers fonctionnels, la conversion technique, la gestion de projet, la configuration du système, la migration des données, les tests, la gestion du changement et le support de mise en service. Plus le système source est complexe, plus l’effort de conseil est important.

L’approche de migration affecte également le coût.

Une migration brownfield, ou conversion de système, est souvent considérée comme la voie la plus rapide car elle convertit le système ECC existant en S/4HANA. Cependant, elle peut également reporter la complexité existante dans le nouveau système si les données, le code personnalisé et les processus ne sont pas examinés avant le projet.

Une migration greenfield donne aux organisations la possibilité de repartir à zéro, mais elle nécessite généralement plus de conception, de tests et de gestion du changement car le système est reconstruit à partir de la base.

La transition de données sélective se situe entre ces deux approches. Elle permet aux organisations de conserver l’historique sélectionné, de laisser de côté les données inutiles et d’apporter des modifications ciblées pendant la migration. Cependant, elle nécessite également une planification minutieuse et une expertise spécialisée.

C’est pourquoi choisir le chemin de migration trop tôt peut être risqué. Une évaluation axée sur les données avant le projet aide à déterminer si l’entreprise a besoin de rapidité, de transformation, de réduction des données, d’accès historique ou d’une combinaison de ces résultats.

Remédiation du code personnalisé

La plupart des environnements SAP ECC de longue date contiennent du code personnalisé.

Cela peut inclure des rapports Z, des améliorations, des flux de travail, des interfaces, des formulaires, des tables personnalisées et une logique métier sur mesure. Une partie de ce code personnalisé peut encore être critique. Une partie peut être obsolète. Une partie peut ne plus être utilisée du tout.

Pendant la migration S/4HANA, le code personnalisé doit être évalué pour déterminer s’il est compatible avec le nouvel environnement. Le code qui dépend d’anciennes structures de données, de transactions obsolètes ou de processus métier modifiés peut devoir être adapté, remplacé ou retiré.

Cet effort de remédiation peut devenir coûteux pour plusieurs raisons.

Premièrement, l’organisation doit identifier le code personnalisé existant. Deuxièmement, elle doit déterminer quels objets sont encore utilisés. Troisièmement, les équipes techniques doivent évaluer l’impact des éléments de simplification S/4HANA. Quatrièmement, tout code modifié ou redéveloppé doit être testé.

Si ce travail commence tard, il peut retarder le calendrier de migration.

Les tables personnalisées ajoutent également de la complexité. Elles peuvent contenir des données historiques, des champs spécifiques à l’entreprise ou des intégrations avec des systèmes externes. Si l’organisation ne comprend pas quelles données personnalisées sont utiles, redondantes ou légalement requises, l’étendue de la migration devient plus difficile à contrôler.

C’est là que la découverte précoce des données devient importante. Avant le début de la migration, les organisations doivent évaluer non seulement les tables SAP standard, mais aussi les tables personnalisées et les développements personnalisés. Cela aide à réduire la dette technique et empêche le report d’objets inutiles.

Complexité de la migration des données

Les données sont l’un des plus grands facteurs de coût dans toute migration S/4HANA.

Chaque organisation doit décider quelles données doivent être transférées dans le nouveau système, quelles données doivent être archivées, quelles données doivent être supprimées et quelles données doivent rester accessibles en dehors de l’environnement opérationnel S/4HANA.

La difficulté est que toutes les données n’ont pas la même valeur.

Certaines données sont nécessaires pour les opérations quotidiennes. Certaines sont requises pour les rapports. Certaines doivent être conservées à des fins légales, fiscales ou d’audit. Certaines ne sont plus utiles mais consomment toujours de l’espace de base de données. Certaines peuvent devoir être supprimées pour se conformer aux exigences de confidentialité des données.

Sans une stratégie claire de gestion du volume de données, les entreprises peuvent transférer trop de données dans S/4HANA. Cela augmente la taille de la base de données, l’effort de projet, l’étendue des tests et les besoins en mémoire HANA.

L’approche de migration de TJC Group et d’Xmateria recommande d’examiner les données sous un angle pratique : quels processus sont en mouvement, quelle quantité de données historiques est nécessaire, quelles unités organisationnelles sont actives et quelles données personnalisées doivent être reportées. Cela aide les organisations à décider ce qui est vraiment nécessaire pour le nouveau système. Regardez la rediffusion du webinaire « Comment choisir le bon chemin vers S/4HANA pour votre entreprise » pour en savoir plus sur la gestion des données pour la migration S/4HANA.

Par exemple, une entreprise peut avoir de nombreux codes d’entreprise dans SAP ECC, mais seuls certains peuvent encore être actifs. Les codes d’entreprise inactifs peuvent devenir de solides candidats à l’archivage au lieu d’être migrés vers le système opérationnel S/4HANA.

C’est pourquoi l’archivage des données SAP n’est pas seulement un exercice de nettoyage. C’est une mesure de contrôle des coûts de migration.

Opérations doubles SAP ECC et SAP S/4HANA pendant la transition

Pendant la migration, les organisations doivent souvent exploiter plusieurs environnements simultanément.

Le système ECC existant continue de soutenir l’entreprise. Le futur environnement S/4HANA est en cours de construction, de test ou de conversion. Des systèmes sandbox, de développement, de qualité et de formation peuvent également être nécessaires. Dans certains projets, les applications legacy et les systèmes satellites doivent rester disponibles jusqu’à la fin de la migration.

Cette période de double opération augmente les coûts.

Il peut y avoir des exigences d’infrastructure supplémentaires, des coûts de support, des efforts d’administration, la gestion des accès utilisateurs, la synchronisation des données et des responsabilités de sécurité. Les équipes métier peuvent également avoir besoin de soutenir les tests de migration tout en poursuivant leurs rôles opérationnels normaux.

Le coût devient encore plus élevé si les systèmes legacy restent actifs après la mise en service de S/4HANA, uniquement parce que les données historiques sont toujours nécessaires.

Maintenir les anciens systèmes en fonctionnement pour un accès occasionnel peut générer des coûts continus de licence, d’infrastructure, de maintenance, de sécurité et de conformité. C’est pourquoi le décommissionnement des systèmes doit être planifié tôt, et non traité comme une activité de nettoyage distincte après la migration. TJC Group a exploré ce sujet en détail à travers sa série de webinaires ELSA sur la migration S/4HANA et le décommissionnement des systèmes, qui couvre les décisions de migration, la préparation des données, le contrôle des coûts HANA, la conformité, l’accès à long terme et les cas d’utilisation du décommissionnement après la mise en service.

Une migration bien planifiée prend en compte à la fois les données transférées vers S/4HANA et les données laissées de côté.

Coûts d’infrastructure

Les coûts d’infrastructure peuvent représenter une part importante des dépenses de migration SAP S/4HANA, souvent en fonction du modèle de licence sélectionné, de l’architecture de déploiement, du volume de données et des attentes de croissance du système à long terme.

Pour de nombreuses organisations, la décision d’infrastructure ne se limite pas au choix entre l’hébergement cloud et sur site. Elle implique également de décider d’utiliser un environnement hyperscaler tel qu’AWS, Microsoft Azure ou Google Cloud, un cloud privé géré par SAP, ou une autre architecture alignée sur les exigences de sécurité, de conformité, de performance et d’évolutivité de l’organisation.

Chaque option a ses propres implications en termes de coûts. Un environnement cloud entièrement géré peut réduire certaines responsabilités internes en matière d’infrastructure, mais il peut toujours introduire des coûts liés au calcul, au stockage, à la sécurité, à la configuration réseau, à la surveillance et à l’administration continue. De même, les environnements de cloud privé gérés par SAP peuvent simplifier certaines parties du modèle d’exploitation, mais la taille du système requise dépend toujours fortement du volume de données migré et conservé.

C’est là que les données deviennent un facteur direct de coût d’infrastructure. SAP S/4HANA fonctionne sur la base de données in-memory SAP HANA, ce qui signifie que des volumes de données plus importants peuvent augmenter les exigences de mémoire et de stockage. Si les organisations migrent des données historiques ou inactives inutiles vers S/4HANA, elles peuvent démarrer leur nouvel environnement avec une empreinte d’infrastructure plus importante que nécessaire.

L’archivage des données SAP aide à réduire ce fardeau en diminuant l’empreinte des données actives avant la migration. En archivant les données qui n’ont pas besoin de rester dans la base de données active, les organisations peuvent réduire la quantité de données qui doivent être migrées, stockées, sauvegardées et gérées dans le nouvel environnement S/4HANA. Cela peut aider à dimensionner correctement les besoins en mémoire HANA, à réduire la pression sur l’infrastructure et à maîtriser la croissance de la base de données HANA après la mise en service.

Formation et perturbation de l’activité

La migration S/4HANA affecte autant les personnes que les systèmes.

Les utilisateurs peuvent avoir besoin d’apprendre de nouveaux processus, interfaces, structures de reporting et flux d’approbation. Les équipes peuvent avoir besoin de s’adapter aux applications Fiori, aux nouveaux rôles, aux structures de données de base modifiées ou aux flux de travail repensés.

La formation prend du temps. Elle entraîne également une perte temporaire de productivité lorsque les utilisateurs passent des processus ECC familiers au nouvel environnement S/4HANA.

La perturbation de l’activité peut également survenir pendant les tests. Les utilisateurs clés peuvent avoir besoin de participer à des ateliers, de valider les données migrées, d’exécuter des scripts de test, d’examiner les changements de processus et de soutenir la résolution des problèmes. Ces activités sont essentielles, mais elles éloignent les équipes métier de leurs responsabilités habituelles.

Ce coût est souvent sous-estimé car il n’apparaît pas toujours comme une simple ligne budgétaire dans le budget du projet. Cependant, il affecte directement l’entreprise.

Une portée de migration plus propre peut aider à réduire les perturbations. Si le système contient moins de données inutiles et moins de processus redondants, les tests et la formation peuvent se concentrer sur ce dont l’entreprise a réellement besoin après la mise en service.

Temps d’arrêt et risque de basculement

Le temps d’arrêt est un autre facteur de coût majeur.

Pendant la phase finale de migration et de basculement, les systèmes peuvent être indisponibles ou restreints. Pour les organisations mondiales, même une courte perturbation peut affecter le traitement des commandes, les opérations financières, la logistique, le reporting ou le service client.

La taille et la complexité de la base de données influencent ce risque. Des bases de données plus volumineuses peuvent augmenter le temps d’exécution de la conversion, l’effort de réconciliation et le temps de traitement technique. Plus de code personnalisé et plus d’interfaces peuvent également augmenter le nombre de dépendances qui doivent être vérifiées avant la mise en service.

C’est pourquoi la réduction du volume de données avant la migration est précieuse.

L’archivage des données inutiles avant la migration S/4HANA peut réduire la quantité de données à traiter pendant la conversion. Cela peut aider à réduire le temps d’exécution, à soutenir une fenêtre de temps d’arrêt plus courte et à améliorer la prévisibilité pendant le basculement.

Cela réduit également la charge sur les équipes de test et de validation. Au lieu de réconcilier de grands volumes d’anciennes données qui peuvent ne plus être opérationnellement utiles, les équipes peuvent se concentrer sur les données qui comptent le plus pour l’activité commerciale actuelle.

Les temps d’arrêt ne peuvent pas être complètement éliminés, mais ils peuvent être mieux contrôlés lorsque l’empreinte des données est plus petite et mieux comprise.

Coûts des systèmes legacy post-migration

Le coût de la migration ne s’arrête pas à la mise en service.

Après la mise en service de S/4HANA, les organisations sont souvent confrontées à une nouvelle question : qu’advient-il de l’ancien système ECC et des autres applications legacy ?

Si les données historiques restent dans ces systèmes, ils peuvent devoir rester disponibles pour des raisons légales, fiscales, d’audit ou commerciales. Cependant, les maintenir opérationnels peut être coûteux. Les anciens systèmes nécessitent toujours une infrastructure, des licences, une surveillance de la sécurité, un contrôle d’accès, un support et une maintenance technique. Ils peuvent également créer une exposition à la conformité si les plateformes obsolètes ne sont plus correctement gouvernées.

C’est pourquoi le décommissionnement des systèmes legacy doit faire partie du plan de migration dès le début. Les organisations doivent décider quelles données sont transférées vers S/4HANA, quelles données sont archivées et comment les données historiques seront accessibles après le décommissionnement de l’ancien système.

Avec la bonne approche, les entreprises peuvent préserver l’accès aux informations historiques sans maintenir le système legacy complet en fonctionnement indéfiniment.

Comment une meilleure gestion des données réduit-elle le coût de la migration ?

Une meilleure gestion des données réduit le coût de la migration S/4HANA en réduisant le travail évitable.

Si les données inutiles sont archivées ou supprimées avant la migration, l’organisation a moins de données à évaluer, convertir, transférer, tester, réconcilier, sauvegarder et exploiter après la mise en service. Cela peut réduire la complexité de la migration et aider à contrôler les besoins en mémoire HANA.

Une approche structurée de la gestion des données devrait inclure :

• Découverte précoce des données
• Identification des tables à volume élevé et des objets d’archivage
• Examen des unités organisationnelles actives et inactives
• Évaluation des tables personnalisées et de la dette technique
• Archivage des données transactionnelles terminées ou rarement consultées
• Suppression des données personnelles lorsque requis par les règles ILM
• Planification du décommissionnement des systèmes legacy
• Accès contrôlé aux données historiques après la migration

Ce travail devrait commencer avant la finalisation de l’approche de migration. Sinon, les organisations pourraient choisir une voie sans comprendre pleinement la complexité des données sous-jacentes.

Les besoins en mémoire HANA sont particulièrement importants car S/4HANA fonctionne sur un environnement de base de données premium. Une base de données plus volumineuse peut pousser les organisations vers un niveau de mémoire supérieur, augmentant les coûts à long terme. La réduction du volume de données avant la migration aide à dimensionner correctement le futur environnement et à contrôler la croissance future.

Comment TJC Group peut soutenir l’archivage des données SAP avant la migration

TJC Group aide les organisations à réduire la complexité de la migration grâce à la gestion du volume de données, l’archivage des données SAP, la suppression des données, le décommissionnement des systèmes legacy et le support de la conformité fiscale tout au long du cycle de vie de la migration.

Le processus peut commencer avant la migration par une évaluation de la gestion du volume de données. Cela aide à identifier la taille de la base de données, la croissance des tables, les objets d’archivage et les économies potentielles avant le début du projet. Cela donne également à l’organisation une vision plus claire des données qui devraient être transférées vers SAP S/4HANA, des données qui peuvent être archivées et des données qui peuvent devoir être supprimées pour des raisons de conformité.

TJC Group fournit également des services d’archivage de données SAP pour les environnements SAP ECC et S/4HANA. L’archivage avant la migration aide à réduire la quantité de données à déplacer et diminue la charge opérationnelle après la mise en service. Pour les organisations qui ont besoin d’automatisation, le Cockpit des sessions d’archivage peut automatiser les processus d’archivage et de suppression des données. Ceci est particulièrement utile pour les paysages SAP complexes où l’archivage manuel est chronophage et difficile à mettre à l’échelle.

Cependant, le support ne devrait pas s’arrêter une fois la migration commencée. Pendant la transition de SAP ECC vers SAP S/4HANA, les organisations doivent également planifier la manière dont les données historiques, les données archivées et les obligations de reporting fiscal seront gérées sur les deux systèmes.

Ceci est particulièrement important car le décommissionnement de SAP ECC devrait idéalement être planifié en même temps que le projet de migration, et non traité comme une activité distincte après la mise en service. Si le système ECC legacy reste actif uniquement parce que les données historiques sont toujours requises, l’organisation peut continuer à payer pour l’infrastructure, les licences, la maintenance, la sécurité et la gestion de la conformité. Une meilleure approche consiste à planifier le décommissionnement tôt tout en s’assurant que les informations historiques restent accessibles à des fins légales, fiscales, d’audit et commerciales.

Pour les informations historiques qui doivent rester accessibles après la migration, l’Enterprise Legacy System Application de TJC Group prend en charge le décommissionnement des systèmes tout en préservant un accès contrôlé aux données legacy SAP et non-SAP. Cela aide les organisations à réduire le coût de maintenance des anciens systèmes après la mise en service de S/4HANA, tout en garantissant que les utilisateurs peuvent accéder aux informations dont ils ont besoin.

TJC Group peut également aider les organisations avec l’archivage des données SAP dans le nouvel environnement S/4HANA. Une fois la migration terminée, la croissance des données ne s’arrête pas. Sans archivage et nettoyage continus, la nouvelle base de données HANA peut continuer à croître, augmentant les besoins en mémoire et les coûts d’exploitation à long terme. Une stratégie d’archivage post-migration aide à maintenir le système S/4HANA léger, efficace et plus facile à gérer.

Il y a aussi un aspect de conformité lié à la migration d’un système à un autre. Les organisations doivent continuer à respecter les exigences légales et fiscales, même lorsque les données sont réparties entre SAP ECC et SAP S/4HANA pendant la transition. Cela peut inclure des exigences liées à DART, SAF-T, l’archivage fiscal et le reporting FEC.

Par exemple, les entreprises françaises sont tenues de générer le rapport FEC chaque année. Si la migration a lieu au cours d’un exercice financier, une partie des données peut se trouver dans SAP ECC et le reste dans SAP S/4HANA. Dans de tels cas, les entreprises doivent s’assurer que le rapport peut toujours être généré correctement et que les données sous-jacentes restent complètes, accessibles et conformes. TJC Group a également publié un article dédié sur les meilleures pratiques pour générer le fichier FEC lors de la migration vers SAP S/4HANA, qui explique ce défi plus en détail.

TJC Group peut aider les organisations à gérer cette continuité en soutenant l’accès aux données, l’extraction fiscale, l’archivage et les exigences de reporting pendant et après la migration. Cela réduit le risque de lacunes en matière de conformité tout en aidant l’organisation à passer à S/4HANA avec un paysage de données plus propre et mieux contrôlé.

Les entreprises qui planifient une migration peuvent également utiliser le calculateur d’archivage SAP pour estimer les économies potentielles liées à la réduction du volume de données avant le début du projet.

Conclusion

La migration SAP S/4HANA coûte si cher parce que le projet est rarement une simple mise à niveau technique.

Elle rassemble les licences, l’implémentation, le conseil, le code personnalisé, la migration des données, les tests, les temps d’arrêt, la formation, la perturbation de l’activité et la gestion des systèmes legacy. Plus une organisation porte de complexité dans son paysage ECC, plus la migration peut devenir coûteuse.

Les données sont l’une des parties les plus importantes de cette équation de coût.

Une base de données volumineuse et non gérée augmente les besoins en mémoire HANA, le temps d’exécution de la migration, l’effort de test, les exigences de sauvegarde et les coûts d’exploitation après la mise en service. Elle peut également rendre le basculement plus difficile et augmenter la charge sur les utilisateurs métier.

L’archivage des données SAP aide à réduire cette pression avant le début de la migration. En archivant les données inutiles, en supprimant ce qui ne devrait plus être conservé et en planifiant l’accès aux données legacy tôt, les organisations peuvent passer à S/4HANA avec un paysage plus propre et plus gérable.

L’objectif n’est pas simplement de réduire les données. L’objectif est de déplacer les bonnes données, de conserver le bon historique et d’éviter de payer pour migrer et exploiter des informations qui n’ont plus leur place dans le système actif.

Les services d’archivage de données SAP de TJC Group avant la migration réduisent la quantité de données à déplacer. TJC Group peut également aider à automatiser l’archivage via le Cockpit des sessions d’archivage et à estimer les économies potentielles grâce à une évaluation de la gestion du volume de données.