Migration de SAP ECC vers S/4HANA : étude de cas d'un distributeur du Moyen-Orient

C'est mon étude de cas préférée. Un distributeur bien connu du Moyen-Orient, dans la mode et les biens de consommation, est passé de SAP ECC 6.0 à S/4HANA. Il comptait environ 18 000 collaborateurs, plus de 1 200 points de vente répartis dans sept pays et un canal e-commerce en croissance. Il utilisait ECC depuis des années, et 44 % de ses objets système étaient personnalisés. Nous avons choisi une conversion brownfield avec refonte sélective. La clôture mensuelle, qui débordait sur les week-ends, se termine désormais avant le déjeuner, et le code spécifique a baissé de près de moitié.

Si vous exploitez un système ECC très personnalisé et que vous vous demandez quelle part en reprendre, voici comment un programme a répondu à cette question.

La personnalisation s'était accumulée lentement, une correction urgente après l'autre. Quand nous avons commencé, même les petites mises à jour comportaient un risque. Les intégrations étaient fragiles : une petite modification côté finance pouvait casser quelque chose dans les opérations de vente. Le métier voulait de la souplesse et de la rapidité. L'IT était absorbée par les urgences. Les deux camps reconnaissaient qu'ils tiraient dans des directions opposées.

Je me souviens d'une séance où l'équipe supply chain a ri un peu en reconnaissant que des dizaines de leurs rapports « critiques » n'étaient presque plus consultés. Les supprimer était à la fois pratique et étrangement libérateur.

L'échéance de la maintenance standard d'ECC a été le déclencheur. SAP ERP 6.0 sur les packages d'amélioration 6 à 8 quitte la maintenance standard fin 2027 (SAP News). Les vraies raisons étaient plus profondes. La finance faisait des extractions manuelles à chaque clôture mensuelle. Les magasins avaient besoin d'une visibilité sur les stocks que les traitements batch de nuit ne pouvaient pas offrir. L'essentiel des efforts de l'IT servait à maintenir en vie le code spécifique.

Le SAP Readiness Check a confirmé ce que nous soupçonnions : un système très personnalisé, avec d'importants travaux de remédiation à venir. La Simplification Item List a montré où le standard S/4HANA faisait déjà ce que le code spécifique d'ECC faisait jusque-là. La finance a découvert que certains rapports spécifiques maintenus de longue date étaient désormais redondants. Le soulagement dans cette réunion était évident.

Une simple conversion technique n'aurait fait que repousser les problèmes. Une reconstruction greenfield complète aurait jeté dix ans de configuration qui fonctionnait. Le brownfield avec refonte sélective était le bon équilibre : garder ce qui était solide, nettoyer ce qui devait l'être, ne reconstruire que ce qui était cassé. Mon guide de migration d'ECC vers S/4HANA explique comment peser ces options.

Conversion simpleBrownfield avec refonte sélectiveReconstruction greenfield complète

Configuration conservéeConversion simpleToute, problèmes comprisBrownfield avec refonte sélectiveCe qui était solideReconstruction greenfield complèteAucune, dix ans de travail jetés

44 % d'objets spécifiquesConversion simpleRepris tels quelsBrownfield avec refonte sélectiveChacun étiqueté : retirer, remplacer ou adapterReconstruction greenfield complèteNon repris

Ce que cela signifieConversion simpleLes problèmes passent dans S/4HANABrownfield avec refonte sélectiveNettoyer ce qui doit l'être, ne reconstruire que ce qui est casséReconstruction greenfield complèteChaque processus qui fonctionnait est reconstruit de zéro

Défi	Ce que nous avons fait
44 % d'objets personnalisés	Le métier et l'IT ont étiqueté ensemble chaque objet : retirer, remplacer ou adapter ; jalons qualité par phase
Intégrations fragiles	Plan de non-régression couvrant le POS, le WMS, la finance, les RH et les portails fournisseurs ; liaisons point à point migrées vers des modèles SAP Integration Suite
Qualité des données	Data stewards par fonction avec des SLA ; suivi quotidien des anomalies ; nettoyage terminé avant la QA
Adoption dans tous les pays	Guides de poste par rôle, tournées sur le terrain à l'approche du go-live, formation liée aux tâches réelles

Le code spécifique à grande échelle

Les résultats du Readiness Check ont joué le rôle de filtre. Le métier et l'IT se sont assis ensemble pour étiqueter chaque objet. Certains étaient clairement redondants, comme des rapports que personne ne se souvenait d'avoir lancés. D'autres soutenaient des processus de distribution réellement uniques et demandaient une refonte soignée. Cela a obligé les équipes à trancher plutôt qu'à reporter. SAP Signavio a aidé à définir les nouveaux processus par rapport aux bonnes pratiques, et smartShift a pris en charge les analyses de code automatisées et les corrections à faible valeur, ce qui a permis de garder le temps des profils seniors pour la refonte. Mon guide du Clean Core explique comment je classe aujourd'hui le code spécifique.

Intégrations

ECC était connecté aux systèmes de point de vente (POS), au système de gestion d'entrepôt (WMS), à la finance, aux RH et à plusieurs portails fournisseurs. Nous avons bâti un plan de non-régression couvrant tous ces éléments et testé après chaque modification importante de la configuration, pas seulement à la fin. Les traitements batch de nuit devaient se terminer plus vite dans S/4HANA, faute de quoi les rapports du matin de l'entrepôt ne seraient pas prêts.

Qualité des données

Les doublons de fournisseurs et des données de base obsolètes ont fait traîner les tests. La solution était structurelle : un data steward dans chaque fonction, avec des SLA de résolution. Si les données n'étaient pas propres au début de la QA, elles retournaient chez le steward. À l'approche de la bascule, nous avons répété les chargements de bout en bout et suivi les anomalies chaque jour. Cette routine toute simple a mieux fonctionné que n'importe quel tableau de bord sophistiqué, ce qui me surprend encore. Mon article sur les raisons de l'échec des migrations de données SAP décrit ce schéma.

Adoption

La formation a touché 26 000 collaborateurs. La finance et les opérations de vente avaient des priorités différentes, ce qui est apparu dès un atelier initial et a modifié la conception de la formation. Quand la pression est montée à l'approche du go-live, nous avons utilisé des guides de poste par rôle et des tournées sur le terrain. Une responsable de magasin a dit plus tard que le guide de deux pages avait compté davantage que n'importe quelle réunion générale. Je l'ai crue.

Livraison par phases avec SAP Activate. Le cœur de la finance et la supply chain ont basculé en premier, les RH et les portails fournisseurs ensuite, de sorte que les équipes de support n'ont jamais été submergées. Chaque environnement avait une seule mission. Le sandbox a validé la trajectoire et verrouillé le périmètre. Le développement a fiabilisé les ordres de transport. La QA a fait tourner de vrais volumes métier et réglé les jobs. La préproduction était une véritable répétition générale. Les dates de déploiement ont été alignées sur les périodes de pic et de creux de la distribution.

Des tests avec le métier. Les responsables finance et supply chain ont testé sur de vrais cycles de clôture de période et de promotions, avec des scénarios écrits à partir de la réalité métier plutôt que de la logique du système. Les exécutions de nuit ont fait apparaître des problèmes de timing. Je me souviens d'un responsable d'entrepôt qui souriait quand la deuxième exécution s'est déroulée sans accroc après des semaines de frustration.

Répétitions de la bascule. Chaque tâche a été chronométrée, resserrée ou fusionnée. La seule répétition à blanc a fait gagner des heures qu'aucun tableur n'avait révélées. Les plans de reprise tenaient sur des fiches d'une page, et les gens disaient que cette simple liste réduisait davantage le stress que n'importe quel tableau de bord. Un magasin pilote a prouvé la stabilité du POS et du WMS avant le déploiement élargi.

Hypercare. Une war room partagée entre l'IT et le métier, des SLA clairs et des journaux d'actions quotidiens. Les permanences du week-end tournaient et les passations de support étaient minutées. On retient en général les chiffres. Moi, c'est la première nuit calme dont je me souviens le plus.

Clôture financière. Les équipes ont dit que la clôture mensuelle se terminait désormais avant le déjeuner, alors qu'elle débordait autrefois sur les week-ends. Le directeur financier était surtout ravi d'obtenir ses rapports bien plus vite. Un responsable financier a plaisanté en disant que le système fonctionnait enfin « plus vite que la machine à café ». Ce genre de moment crée plus de confiance que n'importe quelle présentation.

Code spécifique. En baisse de près de moitié, ce qui a allégé la charge de support à long terme et le risque de régression à chaque future mise à niveau.

Reporting et expérience utilisateur. Les directeurs de magasin sont passés des anciens écrans de transaction aux applications SAP Fiori. Le temps de formation a diminué parce que les applications fonctionnaient comme les gens s'y attendaient. Un directeur l'a qualifié de « rafraîchissant ».

Intégrations. Les connexions entre le POS, le WMS et la finance sont devenues plus stables, et les traitements de nuit se terminaient plus tôt.

Tout ne s'est pas passé de façon uniforme. Certaines équipes se sont accrochées à d'anciens rapports alors que de meilleurs existaient. D'autres ont trouvé les ateliers trop longs et les répétitions répétitives. Avec le recul, ces étapes étaient le filet de sécurité.

Leçon	Ce qui s'est passé	Ce que je ferais la prochaine fois
Aligner tôt	Lors d'un atelier, les directeurs de magasin ont dit que leurs besoins de reporting étaient très différents de ceux de la finance. Le sujet est apparu tôt et nous nous sommes adaptés ; plus tard, il aurait explosé au moment de la bascule	Planifier des séances d'alignement structurées avant le début de la conception
Lancer la revue du code dès le premier jour	Plusieurs objets ont été retravaillés sous pression à l'approche du go-live	Prendre les décisions retirer, remplacer ou adapter dès le lancement
Faire de la donnée un sujet métier	Les doublons de fournisseurs ont ralenti les tests	Nommer dès la première semaine des data stewards par fonction, avec des SLA
Répéter plus qu'il ne semble nécessaire	Une répétition à blanc a révélé des conflits d'enchaînement entre le POS et le WMS que personne n'avait prévus	Prévoir des répétitions supplémentaires ; la dernière avant le go-live doit sembler ennuyeuse

Si le même programme démarrait aujourd'hui, trois choses changeraient. La plupart des entreprises dans cette situation regarderaient désormais S/4HANA Cloud Private Edition dans le cadre de RISE with SAP plutôt que de rester on-premise. Les décisions retirer, remplacer ou adapter seraient cadrées par les niveaux Clean Core de SAP, de A à D. Le suivi des changements et des déploiements se ferait dans SAP Cloud ALM, car Solution Manager 7.2 quitte la maintenance standard fin 2027. Les data stewards, les répétitions, la war room commune et les guides de deux pages resteraient exactement tels quels. Pour le volet humain, consultez mon guide sur les stratégies de formation SAP.

Pourquoi les entreprises passent-elles de SAP ECC à S/4HANA ?

La fin de la maintenance standard d'ECC en 2027 est le déclencheur. Les raisons les plus fortes sont opérationnelles : un reporting en temps réel, une clôture plus rapide et moins d'efforts consacrés à maintenir en vie du code spécifique et des intégrations fragiles. Dans ce cas, l'entreprise voulait des analyses de vente en direct et une clôture mensuelle plus courte.

Qu'a montré le SAP Readiness Check dans ce cas ?

Il a confirmé que 44 % des objets étaient personnalisés et que beaucoup n'avaient pas servi depuis des années. Cela a changé la structure du travail sur le code spécifique : retirer d'abord, remplacer par du standard quand c'est possible et n'adapter que ce qui avait une vraie valeur métier. La Simplification Item List a aussi fait apparaître des rapports que le standard S/4HANA rendait redondants.

Pourquoi choisir un brownfield avec refonte sélective ?

Une simple conversion technique aurait reporté tous les problèmes, et une reconstruction greenfield complète aurait écarté dix ans de configuration qui fonctionnait. La refonte sélective a conservé ce qui était solide, utilisé SAP Signavio pour définir de nouveaux processus là où le standard pouvait remplacer une logique spécifique, et reconstruit uniquement ce qui était cassé.

Que se passe-t-il si le nettoyage des données est fait trop tard ?

Les tests traînent, les répétitions échouent et le go-live glisse. Ici, les doublons de fournisseurs et des données de base obsolètes ont causé des semaines de frictions pendant les tests. La solution a été de nommer des data stewards dans chaque fonction, avec des SLA, et de suivre le nettoyage comme un indicateur de santé du programme.

Comment les intégrations ont-elles été gérées pendant la migration ?

En cartographiant d'abord chaque connexion : POS, WMS, finance, RH et portails fournisseurs. Un plan de non-régression les couvrait toutes, des tests ont été exécutés après chaque modification importante de la configuration, et un magasin pilote a prouvé la stabilité du POS et du WMS avant le déploiement élargi. Une répétition à blanc a tout de même révélé un conflit d'enchaînement entre le POS et le WMS que personne n'avait prévu.

À quoi ressemble une bonne hypercare après un go-live S/4HANA ?

Une war room partagée entre l'IT et le métier, avec des SLA clairs, des journaux d'actions quotidiens et des problèmes clos rapidement au lieu d'être laissés dans un backlog. Les guides par rôle et les tournées sur le terrain réduisent les appels au support plus vite qu'une formation formelle. Organisez les permanences du week-end en rotation et minutez les passations pour que l'équipe ne s'épuise pas.