Comment éviter la dérive du périmètre dans une mise en œuvre SAP

On évite la dérive du périmètre dans une mise en œuvre SAP en rendant chaque changement visible et coûteux à approuver. Écrivez ce qui est hors périmètre aussi soigneusement que ce qui en fait partie. Faites passer chaque demande par le contrôle des changements, avec une évaluation d'impact sur les délais, les coûts et la qualité. Exigez un arbitrage pour chaque ajout. Fixez une date de gel du périmètre avec le soutien de la direction, et mettez la même discipline dans le contrat de l'intégrateur. Ce guide s'adresse aux directeurs de programme, aux sponsors et aux PMO des programmes S/4HANA. Reprenez le tableau du coût du changement et les clauses de contrat ci-dessous dans votre prochain dossier de comité de pilotage.

La plupart des projets SAP dépassent leur budget et leurs délais, et la dérive du périmètre en est la cause la plus courante. J'ai travaillé avec des dizaines d'entreprises dont les projets SAP ont échappé à tout contrôle, et trois signaux apparaissent avant que le dépassement n'atteigne le rapport de pilotage. De petits changements s'accumulent sans évaluation d'impact. Le contrôle des changements repose sur des relations personnelles plutôt que sur une autorité documentée. Et le sponsor approuve autour d'un café des choses que l'équipe projet apprend une semaine plus tard.

Un client pharmaceutique avait démarré avec un calendrier clair de 18 mois. Trois ans plus tard, il était toujours en cours de mise en œuvre et les coûts avaient doublé. Le directeur informatique d'un industriel m'a raconté que son équipe avait abandonné des modules entiers qu'elle avait mis des mois à configurer, parce que les exigences ne cessaient de changer. Le périmètre avait tellement grossi que personne ne reconnaissait plus le plan d'origine.

Ce ne sont pas des cas isolés. C'est la façon la plus courante dont échouent les programmes SAP.

Ça commence innocemment. Un responsable métier demande « juste une petite modification ». Puis une autre. La formule « tant qu'on y est, juste... » a fait dérailler plus de mises en œuvre SAP que n'importe quel défi technique.

J'ai travaillé avec un client de la distribution où nous étions partis sur des bases saines : le cœur de la Finance et la gestion des matières (MM) de base. Six mois plus tard, le directeur marketing (CMO) voulait de l'analytique client. Puis le directeur des opérations (COO) a eu besoin de fonctions d'entrepôt avancées. Le calendrier initial de neuf mois était menacé. J'ai résisté et rejeté les deux demandes. Cette discipline, c'est le métier.

Tout changement n'est pas une dérive du périmètre. Parfois, on découvre dans la conception des écarts critiques que personne n'avait anticipés. Parfois, la réglementation change en cours de projet. Ces changements sont légitimes et suivent un processus avec ajustement du calendrier et du budget. La dérive du périmètre, elle, surgit d'elle-même, le plus souvent après une conversation dans un couloir.

Un client industriel avait démarré avec 10 rapports spécifiques et en a fini avec 47, chacun ajoutant du temps de conception, de développement et de test. Le chantier de reporting à lui seul a dépassé son budget de 200 %.

200 %

dépassement du budget du chantier de reporting après que la dérive du périmètre a fait passer les rapports spécifiques de 10 à 47

Source: Programme d'un client industriel

Signes avant-coureurs

Voici les signes que je surveille, et la réponse à chacun :

Signe avant-coureur	Cause sous-jacente	Réponse
« Juste encore une chose » devient le langage quotidien	Limites du périmètre floues	Refaire la référence avec les responsables métier ; appliquer un contrôle des changements formel
Des responsables métier ajoutent des fonctions de façon informelle	Aucune compréhension de l'impact en aval	Faire passer chaque demande par une évaluation d'impact ; montrer le coût
Le calendrier s'allonge sans replanification formelle	Extension silencieuse du périmètre	Tenir des points de contrôle du périmètre ; replanifier avec la validation du comité des changements
La documentation ne correspond plus à ce qui est construit	Gestion informelle du périmètre, pas de gestion de versions	Mettre à jour les spécifications et les plans à chaque changement approuvé
La consommation du budget dépasse l'avancement	Effort caché dû à des changements non documentés	Suivre l'effort par lot de travaux ; analyser les écarts
L'équipe travaille nuits et week-ends pour rattraper son retard	Le périmètre dépasse la capacité	Escalader au comité des changements ; forcer une décision sur le périmètre
Les reproches se multiplient entre le métier, l'IT et le partenaire	Le périmètre a déjà dérivé hors de contrôle	Geler le périmètre, mener une revue des causes racines, réinitialiser la référence

Tout est lié

SAP relie tout. La finance influe sur la supply chain. Les RH touchent la paie. Les ventes se connectent aux stocks. Un seul changement peut casser dix choses.

Un client a ajouté un seul champ à son processus de commande d'achat. Cela semblait trivial. Cela a cassé trois interfaces et imposé de réécrire des rapports dans plusieurs services. Un autre client a demandé une « toute petite modification » de son schéma de calcul des prix, qui s'est avérée exiger de reconfigurer toute la structure de prix : trois semaines de travail et 40 000 $ d'honoraires de conseil, pour une toute petite modification.

Une chance tous les dix ans

La plupart des entreprises mettent en œuvre SAP une fois tous les 10 à 15 ans. Chaque service sait qu'il n'aura pas d'autre chance avant dix ans. Personne ne veut entendre parler de « phase 2 », ce qui, dans la plupart des organisations, veut dire jamais. Alors tout est poussé dans le projet en cours, et la liste du périmètre devient une liste de souhaits.

Ce que change le Clean Core

Le Clean Core pose un frein technique à la personnalisation. Sur S/4HANA Cloud Public Edition, modifier le cœur n'est pas possible : les extensions passent par des API publiées, en on-stack ou en side-by-side sur SAP BTP. Sur Private Edition et en on-premise, la modification reste possible, mais les recommandations de SAP la traitent comme un dernier recours, car chacune ajoute du travail lors des mises à niveau.

L'effet secondaire utile, c'est la discipline sur le périmètre. Une demande du type « ajoutons simplement cette étape d'approbation au order-to-cash standard » cesse d'être une discussion informelle sur la configuration et devient une extension avec son propre coût de conception, de développement et de test. Placez un forum de revue des extensions sous le comité de pilotage, avec un architecte capable d'approuver ou de rejeter, et beaucoup de ces demandes s'arrêtent avant d'entrer dans la référence. Les programmes on-premise sans ce forum retombent dans les anciens travers. Mon guide du Clean Core explique comment en mettre un en place.

1. Définir le périmètre avec des exclusions explicites. Documentez ce qui est hors périmètre aussi soigneusement que ce qui en fait partie, et faites valider les deux. L'ambiguïté est le point de départ des disputes.
2. Appliquer un contrôle des changements formel, avec des conséquences. Chaque changement exige une évaluation d'impact sur les coûts, les délais et la qualité, visible de celui qui l'approuve.
3. Rappeler les limites du périmètre à chaque comité de pilotage. Montrez l'état du périmètre dans une vue simple rouge, orange, vert. Une grande part de la dérive vient d'un malentendu.
4. Rédiger un plan de gestion du périmètre. Décrivez comment les changements sont évalués, approuvés, escaladés et suivis, pour que chaque chantier les traite de la même façon. Mon modèle de périmètre de projet SAP fournit une structure de départ.
5. Prioriser avec MoSCoW. Indispensable (Must have), important (Should have), souhaitable (Could have), exclu cette fois (Won't have). Tenez bon pour que la liste des indispensables reste courte.
6. Gérer chaque décision en versions. Chaque changement approuvé met à jour la référence. Chaque changement rejeté est consigné avec sa raison.
7. Exiger des arbitrages. Si une nouvelle exigence arrive, autre chose sort. Les indispensables deviennent vite optionnels quand ils coûtent quelque chose.

Trois techniques que j'ai utilisées font tenir tout cela.

La discipline de la signature. Faites signer les exigences approuvées par les responsables métier. Sur un programme, un responsable métier jurait n'avoir jamais approuvé un flux de processus précis. Nous avons sorti le document portant sa signature, et la discussion s'est arrêtée là. La signature n'est pas de la bureaucratie. Elle empêche la même dispute de repartir six mois plus tard.

Montrer les effets en cascade. J'ai construit pour un client une démonstration montrant comment la modification d'un seul champ d'une commande client toucherait 14 domaines, du reporting aux interfaces en passant par les rôles de sécurité. Les comportements ont changé. Expliquer coûte des heures. Ne pas comprendre les effets en cascade coûte des mois.

Montrer le coût du changement. Un changement pendant la conception peut coûter 5 000 $. Le même changement pendant les tests peut coûter 50 000 $. Mettez un graphique simple de cela sous les yeux des gens et les demandes faites à la légère ralentissent.

Ce sont des fourchettes indicatives de coût du changement pour des programmes S/4HANA sur le marché américain. Elles varient selon la complexité et le partenaire. Servez-vous-en comme repères, pas comme devis.

Phase	Coût typique d'un petit changement	Coût typique d'un changement moyen
Explore (conception)	2 à 10 k$	10 à 30 k$
Début de Realize	5 à 20 k$	20 à 80 k$
Milieu de Realize (développement)	15 à 50 k$	50 à 200 k$
Fin de Realize (tests)	30 à 100 k$	100 à 400 k$
Deploy et bascule	80 à 300 k$	300 k$ à plus de 1 M$
Hypercare (après le go-live)	150 à 500 k$	500 k$ à plus de 2 M$

Cette courbe correspond à ce que la recherche constate depuis des décennies. Une étude de la NASA sur l'escalade du coût des erreurs a montré qu'une erreur d'exigence détectée en intégration et test coûtait 21 à 78 fois plus cher à corriger qu'une erreur détectée pendant la phase d'exigences, et bien davantage une fois le système en exploitation. La gouvernance du périmètre existe pour garder les changements du côté bon marché de cette courbe.

Les clauses de contrat qui comptent

Les contrats vagues créent des problèmes coûteux. J'ai vu un client signer un contrat qui disait seulement « mettre en œuvre S/4HANA ». Le partenaire a ensuite soutenu que certains processus étaient des options soumises à des frais supplémentaires, et le client a fini par payer le double. Ces clauses l'évitent :

Clause	Objectif
Périmètre avec exclusions explicites	Limite ce que couvre le prix forfaitaire et lève l'ambiguïté sur les options
Tarifs convenus à l'avance pour les changements courants	Fige les prix des rapports, des interfaces et des modifications de configuration avant que la pression n'arrive
Continuité des consultants	Empêche les nouveaux consultants de rouvrir des décisions closes et d'élargir le périmètre
Pouvoir d'approbation des deux côtés	Empêche les consultants juniors de promettre des fonctions que personne n'a autorisées
Facturation par jalons	Lie le paiement à des livrables validés, pas au temps écoulé
Critères d'acceptation par livrable	Définit ce que « terminé » veut dire avant que quiconque en discute
Clause d'extension Clean Core	Impose que les extensions utilisent des API publiées ou SAP BTP ; évite des reprises à la première mise à niveau majeure

Mes notes sur la négociation de contrats ERP expliquent comment faire accepter ces clauses.

Comité de contrôle des changements

Un comité des changements fonctionne quand il réunit les bonnes personnes. Je compose le mien avec trois rôles : un décideur métier qui se soucie de la fonction, un chef de projet qui se soucie du calendrier et un responsable financier qui se soucie du budget. Cet équilibre empêche qu'une seule priorité domine.

1. 01Demande formuléePar écrit, pas autour d'un café
2. 02Évaluation d'impactDélais, coûts et qualité, avant toute approbation
3. 03Arbitrage nomméAutre chose sort pour faire de la place
4. 04Le comité des changements décideMétier, projet et finance autour de la table
5. 05Référence mise à jourChangements rejetés consignés avec la raison

Le périmètre ne bouge que par le comité

Le comité doit avoir une autorité réelle. Sur un programme, aucun changement de périmètre n'a eu lieu sans son approbation. Pas un seul. Les accords de couloir ont cessé. Quand le vice-président des ventes a tenté de glisser de nouvelles exigences, l'équipe avait une matrice d'approbation documentée à lui opposer.

La plupart des décisions doivent rester au niveau du comité. Seuls les vrais litiges remontent au sponsor, ce qui le garde impliqué sans le submerger. Tenez une revue du périmètre avec les responsables de chantier toutes les deux semaines et rendez compte des demandes soumises, approuvées et rejetées. Quand les gens lisent « 15 % de croissance du périmètre ce mois-ci » dans un rapport d'avancement, les comportements changent.

Certains changements sont nécessaires. Un de mes clients pharmaceutiques a été rattrapé par de nouvelles réglementations de la FDA en pleine mise en œuvre. Elles devaient être intégrées. Ce n'est pas de la dérive du périmètre. C'est la réalité.

Quand un changement légitime arrive, posez deux questions. Quelle est la plus petite correction qui fonctionnera ? Et, à celui qui demande : qu'êtes-vous prêt à retirer pour faire de la place ? L'urgence retombe vite quand une demande coûte quelque chose.

Les options sont d'allonger le calendrier, d'ajouter du budget, de supprimer d'autres exigences, d'ajouter des personnes, ou un mélange de ces leviers. Quel que soit votre choix, documentez-le et mettez à jour tous les documents de référence en même temps. Des documents obsolètes créent la prochaine vague de problèmes de périmètre.

L'IA aide désormais pour la paperasse. Des assistants comme Microsoft Copilot résument de longs fils de demandes de changement en une note prête à la décision pour le comité, et SAP Cloud ALM garde les exigences, les changements et les tests reliés pour qu'il soit plus facile de tracer l'impact d'un changement. L'IA peut montrer qu'un changement touche 14 domaines. Elle ne peut pas dire au COO que sa demande signifie que celle du directeur financier n'aboutira pas. Cette conversation reste la vôtre.

Un industriel avec lequel j'ai travaillé a terminé son projet SAP dans les délais, ce qui est plus rare que cela ne devrait. Il avait fixé tôt une date de gel du périmètre, et tout changement postérieur exigeait l'approbation personnelle du directeur général. Le projet s'est clos avec du budget restant, et personne ne travaillait le week-end au go-live.

Un autre client a utilisé un système de jetons : chaque service recevait trois jetons de changement pour toute la durée du projet. Envie d'un changement ? Dépensez un jeton. Les gens ont réfléchi sérieusement à ce qui comptait, et les « indispensables » ont été reconsidérés dès lors qu'ils coûtaient une monnaie limitée.

Aucune des deux approches n'est compliquée. Toutes deux demandent de la discipline et le soutien de la direction. Le test de tout processus de périmètre, c'est le jour où le COO entre dans la salle de projet avec « juste une petite modification ». Construisez-le pour ce jour-là.

Qu'est-ce que la dérive du périmètre dans un projet SAP ?

La croissance progressive et non maîtrisée des exigences, sans ajustement correspondant du calendrier, du budget ou des ressources. Dans SAP, elle commence généralement par de petits ajouts : des rapports supplémentaires, des champs supplémentaires, « juste une petite modification de workflow ». Chacun semble anodin. Ensemble, ils ajoutent des mois.

Les changements de périmètre légitimes suivent un processus et s'accompagnent d'ajustements du calendrier et du budget. La dérive du périmètre arrive de façon informelle et contourne le contrôle des changements.

Quelles sont les causes les plus courantes de dérive du périmètre dans les projets SAP ?

Trois reviennent systématiquement : des exigences initiales floues, de sorte que tout peut être défendu comme faisant partie du périmètre ; l'absence de contrôle des changements formel, de sorte que des changements s'infiltrent à tous les niveaux ; et l'état d'esprit « une fois par décennie », où chaque service essaie de régler des années de problèmes dans ce projet.

L'interconnexion de SAP amplifie ces trois causes. Un seul changement peut casser dix processus connectés, et si les responsables métier ne voient pas ces liens, l'impact apparaît pendant les tests, quand il coûte plusieurs fois plus cher.

Comment le Clean Core change-t-il le risque de dérive du périmètre ?

Il ajoute un frein technique. Sur S/4HANA Cloud Public Edition, le cœur ne peut pas être modifié, si bien que chaque écart devient une extension avec son propre coût de conception, de développement et de test. Sur Private Edition et en on-premise, la modification est possible mais ajoute du travail de mise à niveau, c'est pourquoi les recommandations de SAP la déconseillent.

Un forum de revue des extensions, avec un architecte qui a le pouvoir de trancher, arrête beaucoup de demandes avant qu'elles n'entrent dans la référence. Sans ce forum, les programmes on-premise retombent dans leurs anciennes habitudes.

Quelle différence entre dérive du périmètre et gold-plating ?

La dérive du périmètre vient du métier : des demandes au-delà de ce qui a été convenu. Le gold-plating vient de l'équipe de livraison : une complexité que personne n'a demandée.

Dans le monde SAP, le gold-plating, c'est un consultant qui construit une logique de workflow élaborée là où un simple routage suffirait. La dérive du périmètre, c'est le COO qui réclame des fonctions d'entrepôt avancées six mois après le début d'un projet cadré pour du MM de base. Les deux gonflent les coûts et les délais, et les deux exigent la même discipline.

Comment structurer un processus de contrôle des changements qui fonctionne vraiment ?

Trois éléments. Chaque demande s'accompagne d'une évaluation d'impact sur le calendrier, le budget et les ressources. Le comité d'approbation comprend quelqu'un qui se soucie de chacun de ces trois sujets, et pas seulement des responsables métier, qui approuveront tout. Et chaque ajout exige un arbitrage : autre chose sort.

Cette dernière règle suffit à elle seule à écarter les demandes qui ne sont pas vraiment critiques.

Peut-on éviter totalement la dérive du périmètre ?

Non. Sur tout programme de plus de quelques mois, les conditions de l'entreprise évoluent, la réglementation change et la conception révèle des écarts.

L'objectif est la maîtrise, pas l'élimination. Un changement maîtrisé suit un processus documenté, fait l'objet d'une évaluation d'impact et met à jour la référence. Un changement non maîtrisé contourne le processus et ressurgit pendant les tests ou après le go-live sous la forme d'un coût que personne n'avait prévu.

Quelle est la meilleure façon de gérer un gel du périmètre sur un long programme SAP ?

Lui donner une conséquence et un soutien visible de la direction. La version la plus efficace que j'ai utilisée : la date de gel figure dans la charte du projet dès le premier jour, le processus de changement définit ce que « gel » veut dire en pratique, et le sponsor le réaffirme publiquement en comité de pilotage avant l'arrivée de la date.

Quand le directeur général doit approuver personnellement chaque changement après le gel, la liste reste très courte.