Planification et contrôle de projet SAP : gardez le cap

La plupart des programmes SAP ont un plan. Bien moins ont un vrai contrôle. La planification fixe le périmètre, le calendrier, le budget et les risques. Le contrôle, c'est le travail hebdomadaire qui consiste à suivre l'avancement par rapport à ce plan, à gérer les dépendances, à escalader tôt et à évaluer chaque changement avant de l'approuver. Ce guide s'adresse aux directeurs de programme, aux PMO et aux sponsors dont le programme SAP dérive, ou qui veulent l'empêcher de dériver. Il décrit à quoi ressemble le contrôle, trois échecs publics qui montrent ce qui se passe sans lui, et une cadence de contrôle hebdomadaire, avec ses responsables, que vous pouvez adopter dès cette semaine.

À mes débuts, j'ai travaillé sur un programme SAP qui avait fière allure sur le papier. Calendriers, registres des risques, journaux des changements, tout ce qu'on peut attendre. Personne ne le suivait. Le comité de pilotage se réunissait rarement. La finance attendait la migration des données. La DSI n'avait pas démarré. Personne ne suivait les dépendances. Chacun supposait qu'un autre gardait le projet dans les clous.

Au sixième mois, la moitié du projet était en retard et nous courions après nos propres erreurs. Le pire, c'est que personne ne l'avait vu venir.

Ce n'était pas un problème de planification. C'était un problème de contrôle. Pas de véritable allocation des ressources, pas de réelle réduction des risques, pas de circuit d'escalade. Le plan avait été produit une fois, puis abandonné au profit de réunions.

La planification couvre le périmètre, le calendrier, le budget, les ressources, le registre des risques et les engagements de jalons. La plupart des équipes produisent tout cela. La question est de savoir si quelqu'un s'en sert d'une semaine à l'autre.

Le contrôle consiste à suivre l'avancement réel par rapport au plan, à faire remonter les écarts tôt, à gérer les dépendances, à escalader quand ça glisse et à réétablir la référence quand le périmètre ou le calendrier change officiellement. La plupart des équipes le font mal.

1. 01Suivre l'avancementRéel par rapport au plan, par lot de travaux
2. 02Faire remonter les écartsToute tâche en retard de trois jours
3. 03Vérifier les dépendancesQui est bloqué si cela glisse
4. 04EscaladerSelon un circuit convenu à l'avance
5. 05Évaluer les changementsD'abord délais, coûts et ressources
6. 06Réétablir la référenceSeulement après un changement formel

Chaque semaine, avec des responsables nommés

Voici ce qui casse quand le contrôle manque :

Ce qui casse sans contrôle	Pourquoi cela arrive
Les échéances glissent en silence	Personne ne vérifie entre deux revues de jalons
Les hypothèses ne sont pas vérifiées	Chaque équipe suppose qu'une autre gère la dépendance
Le périmètre s'étend de façon informelle	Des changements approuvés en réunion, sans analyse d'impact
Les risques sont ignorés jusqu'à ce qu'ils se matérialisent	Registre des risques mis à jour chaque trimestre au lieu de chaque semaine
Les coûts dépassent le budget	L'effort figure dans les feuilles de temps mais n'est pas rattaché aux lots de travaux
Les équipes cessent de communiquer	Les points d'avancement deviennent des tours de table sans actions

Ce sont des cas publics, pas des histoires de clients. Leurs causes profondes sont celles que je retrouve sans cesse en mission de conseil.

Lidl : environ sept ans et un coût estimé à 500 millions d'euros, puis l'arrêt

Lidl a lancé son projet eLWIS sur SAP Retail en 2011. Sa méthode de valorisation des stocks différait du modèle standard de SAP, et Lidl a choisi d'adapter le logiciel plutôt que sa pratique. En 2018, le système était en production en Autriche, en Irlande du Nord et aux États-Unis, mais la direction a conclu que les objectifs initiaux n'étaient pas atteignables à un coût raisonnable. Lidl a arrêté le projet et est revenu au développement de son système interne. La presse spécialisée a estimé la dépense à environ 500 millions d'euros, et le membre du directoire chargé de l'informatique était parti en 2017. Heise a rapporté la décision en juillet 2018. La leçon : des années de personnalisation pour protéger une pratique héritée du passé sont un échec de contrôle, pas un échec logiciel.

Hershey : environ 100 millions de dollars de commandes d'Halloween non livrées

Le nouveau système SAP, Siebel et Manugistics de Hershey devait entrer en production en avril 1999, un mois calme pour la confiserie. Il a glissé de trois mois et a démarré en juillet, au moment où les commandes d'Halloween commençaient à arriver. Les commandes ne parvenaient pas du système jusqu'aux entrepôts. Le PDG a déclaré aux analystes que ces problèmes empêcheraient Hershey de livrer environ 100 millions de dollars de produits pour Halloween, et les ventes du troisième trimestre ont reculé de 12,4 %. Le récit de CIO magazine attribue le véritable échec au calendrier. Un contrôle du planning protégeant la haute saison aurait imposé une autre date de go-live.

Revlon : une usine perturbée et une faiblesse significative des contrôles

Revlon a mis SAP en service dans son usine d'Oxford, en Caroline du Nord, son plus grand site de production, en février 2018. Des perturbations de service ont touché la production et les expéditions vers les grands distributeurs américains. En mars 2019, Revlon a révélé une faiblesse significative du contrôle interne liée au déploiement, en citant l'absence d'évaluation continue et efficace des risques et un nombre insuffisant de personnes formées dans les opérations concernées. Des investisseurs ont porté plainte ; TechTarget a couvert la plainte, qui affirmait qu'environ 64 millions de dollars d'expéditions n'avaient pas été honorés.

Aucun de ces projets n'a échoué parce que SAP était le mauvais choix. Ils ont échoué sur des fondamentaux de planification et de contrôle qui existent depuis des décennies.

Structure de découpage du projet

Une structure de découpage du projet (WBS, pour work breakdown structure) décompose le périmètre total en livrables avec des responsables clairs. Sans elle, le travail reste invisible jusqu'à ce qu'il soit en retard. Pour un programme SAP, elle couvre la conception des processus, le paramétrage, la migration des données, l'intégration, les tests, la formation et la bascule, chacun décomposé en tâches avec un responsable et une date d'échéance.

La valeur n'est pas dans le document. Il force la conversation sur ce qui doit être fait, par qui et de quoi cela dépend. Les dépendances sont ce qui tue les projets. Un retard de migration des données bloque les tests d'intégration, qui bloquent la recette utilisateur (UAT), qui comprime la fenêtre de bascule. Une WBS rend cette chaîne visible.

Gestion du calendrier

Les calendriers échouent pour des raisons prévisibles. Des personnes sont réaffectées. Les estimations étaient fausses. Les décisions prennent plus de temps que prévu. Prévoyez une marge dès le premier jour, sous forme de tampon explicite à côté des tâches les plus susceptibles d'en avoir besoin, et non de marge diffuse partout.

Suivez le calendrier chaque semaine. Un retard d'une semaine en semaine quatre, c'est une conversation. Un retard de quatre semaines en semaine seize, c'est une crise. Même problème, coût de correction très différent.

Traitez la date de go-live comme une décision à part. Ne basculez jamais en pleine période de pointe de l'activité. La leçon de Hershey vaut pour toutes les entreprises.

Maîtrise du budget

Les budgets dérapent pour trois raisons : des changements de périmètre non maîtrisés, une migration des données sous-estimée et des coûts d'hypercare supérieurs aux premières estimations. Suivez les dépenses réelles par rapport au plan dès la première semaine. Quand un écart arrive devant le comité de pilotage, il est généralement trop tard pour le corriger sans perturbation.

Le contrôle des changements est la principale protection du budget. Chaque changement de périmètre fait l'objet d'une analyse d'impact sur les délais, les coûts et les ressources avant approbation. Si l'analyse vient après l'approbation, le changement a contourné le budget. Mon guide sur comment éviter la dérive du périmètre dans une mise en œuvre SAP va plus loin sur le comité des changements.

Gestion des risques

Un registre des risques tenu chaque trimestre, c'est du théâtre. Les risques demandent une revue hebdomadaire, des responsables nommés et des plans de réponse. Nommez ceux-ci sur chaque programme SAP : qualité des données découverte trop tard, retards d'intégration, manques dans la disponibilité des ressources, compression de la fenêtre de bascule et faible adoption par les utilisateurs.

Un client a perdu trois mois parce que son prestataire de migration des données ratait échéance après échéance. Nous entendions sans cesse « encore deux semaines », jusqu'à ce qu'il soit trop tard pour changer de prestataire sans faire exploser le budget. Un risque avec un responsable et une date de déclenchement aurait forcé cette décision des mois plus tôt. Ma matrice d'évaluation des risques SAP propose un modèle pour noter ces risques et les confier à des responsables.

Communication et escalade

Les dirigeants ont besoin des grandes lignes. Les équipes de réalisation ont besoin du détail. Les chefs de projet ont besoin des données d'écart. Un seul compte rendu pour tout le monde n'aide personne.

Documentez et répétez les circuits d'escalade avant la crise. Sur une mise en œuvre SAP, la DSI pensait que la finance relisait le paramétrage, et la finance pensait que c'était la DSI. Personne n'a soulevé le sujet avant que le go-live soit à trois mois, avec des validations critiques manquantes ; la correction a été une course de dernière minute, un surcoût et un déploiement retardé. Une autre entreprise a fait les choses correctement : le reporting était structuré et relié à des actions, de sorte que lorsqu'un problème surgissait, chacun savait qui en était responsable, quel était l'impact et comment il serait résolu.

Le périmètre est l'endroit où l'escalade prouve son utilité. J'ai travaillé avec une compagnie aérienne qui avait commencé par une simple amélioration de son système de réservation. Six mois plus tard, elle y avait ajouté des évolutions du programme de fidélité, la planification des équipages et des modules financiers. Aucune n'était urgente. Personne n'a dit non. Le calendrier a doublé et les coûts ont augmenté de 70 %.

Les méthodes du on-premise ne survivent pas telles quelles à RISE with SAP. Trois choses changent.

RISE change vers qui vous escaladez

Avec RISE with SAP, SAP exploite l'infrastructure et les opérations techniques, et fournit une équipe Customer Success qui suit l'adoption. Votre structure de contrôle doit l'inclure. Pour les problèmes de plateforme (performances du système, région de l'hyperscaler, niveaux de service SAP), le directeur de programme a besoin d'un circuit d'escalade documenté vers SAP qui ne passe pas par l'intégrateur. Écrivez-le avant d'en avoir besoin.

Le Clean Core offre un garde-fou technique au contrôle du périmètre

Chaque écart appelle désormais une décision : le paramétrer, l'étendre via des API publiées (on-stack avec ABAP Cloud ou side-by-side sur SAP BTP), ou le rejeter. Sur S/4HANA Cloud Public Edition, modifier le noyau n'est pas possible. En Private Edition et en on-premise, c'est possible, mais les recommandations Clean Core de SAP en font le dernier recours, car chaque modification ajoute du travail lors des mises à niveau.

Cela aide le contrôle du périmètre. Une demande du type « il suffit d'ajuster le processus order-to-cash standard » cesse d'être une discussion de paramétrage informelle et devient une extension, avec un effort de conception, de développement et de test. Placez un petit forum de revue des extensions sous le comité de pilotage, avec un architecte ayant le pouvoir d'approuver ou de rejeter. Sans lui, chaque débat sur la personnalisation finit en comité de pilotage.

L'IA rédige les rapports, les humains prennent les décisions

L'IA aide désormais pour la paperasse du contrôle. SAP Cloud ALM, l'outil de gestion du cycle de vie des applications de SAP, contient les tâches, les exigences et l'état des tests du projet, et peut générer des ébauches d'exigences à partir des transcriptions d'ateliers. Microsoft Copilot rédige des synthèses d'écarts pour les dossiers de comité de pilotage à partir des tableaux de bord et des rapports d'état. La détection d'anomalies dans Power BI ou SAP Analytics Cloud signale les indicateurs qui s'écartent de leur comportement habituel. C'est utile pour l'utilisation des ressources, le volume de demandes de changement et les tickets de support, moins pour des indicateurs qui oscillent naturellement.

Ce que l'IA ne fait pas, c'est agir. Un tableau de bord peut afficher en rouge le glissement du calendrier pendant six semaines. Si le comité de pilotage ne fait rien, le glissement continue.

C'est le rythme minimal pour un programme en phase de réalisation active. S'il manque une ligne, ajoutez-la avant toute autre chose.

Contrôle	Pratique minimale	Responsable	Fréquence
Structure de découpage du projet	Chaque tâche a un responsable, une échéance et ses dépendances	Responsable PMO	Mise à jour chaque semaine
Revue du calendrier	Signaler toute tâche en retard de plus de trois jours ; vérifier le chemin critique	Directeur de programme	Chaque semaine
Suivi budgétaire	Réel par rapport au plan, par lot de travaux	Responsable financier du programme	Chaque semaine, reporté chaque mois
Revue des risques	Chaque risque actif a un responsable, un déclencheur et une réponse	Responsables de chantier	Chaque semaine
Contrôle des changements	Analyse d'impact sur les délais, les coûts et les ressources avant approbation	Président du comité des changements	Chaque semaine ou à l'arrivée des demandes
Revue des extensions (RISE et GROW)	Décision paramétrer, étendre ou rejeter pour chaque écart	Architecte de solution	Tous les quinze jours
Comité de pilotage	Des décisions, pas un simple état d'avancement ; documents envoyés à l'avance	Sponsor exécutif	Tous les quinze jours ; chaque semaine pendant la bascule et l'hypercare

La plupart des échecs de planification et de contrôle ne viennent pas d'une mauvaise méthode, mais d'une discipline abandonnée au quatrième mois. Gardez une cadence assez légère pour que l'équipe la tienne encore au quatorzième mois. Pour le comité de pilotage lui-même, voir mon guide sur la création d'un comité de pilotage SAP efficace.

Quelle est la différence entre la planification et le contrôle de projet ?

La planification produit la feuille de route : périmètre, calendrier, budget, ressources et risques. Elle donne la direction au départ.

Le contrôle est le travail continu qui consiste à suivre l'avancement par rapport à ce plan, à faire remonter les écarts, à gérer les dépendances et à réétablir la référence quand des changements formels interviennent. Il a lieu chaque semaine pendant toute la vie du programme.

La plupart des programmes SAP investissent beaucoup dans la planification et trop peu dans le contrôle. Quand l'écart apparaît devant le comité de pilotage, des semaines ou des mois de coût de rattrapage se sont déjà accumulés.

Pourquoi les projets SAP échouent-ils malgré un plan de projet ?

Parce que personne ne travaille avec le plan. Les dépendances ne sont pas suivies, si bien que le retard d'un chantier en bloque un autre en silence. Les registres des risques sont mis à jour chaque trimestre. Les changements de périmètre sont approuvés de façon informelle. Le comité de pilotage se réunit une fois par mois et voit des synthèses de jalons qui masquent ce qui se passe sur le terrain.

Lidl, Hershey et Revlon avaient tous des plans. Ce qui leur a manqué, c'est un contrôle actif : un suivi honnête, une escalade précoce et une vraie réaction quand les signaux d'alerte sont apparus.

Comment gérer la dérive du périmètre sur un long programme SAP ?

Donnez à chaque changement de périmètre une analyse d'impact écrite avant approbation : délais, coûts et ressources. Sans elle, approuver un changement revient à approuver une inconnue.

La règle la plus efficace : tout ajout doit en évincer un autre. Cette seule contrainte oblige les responsables métier à établir leurs priorités honnêtement.

Les dirigeants doivent la soutenir. Quand un DAF ou un directeur des opérations soutient publiquement le contrôle des changements, les demandes informelles reculent vite. Sur les programmes RISE et GROW, la décision d'extension pour chaque écart ajoute un contrôle technique supplémentaire.

Qu'est-ce qu'une structure de découpage du projet et pourquoi compte-t-elle pour SAP ?

Une WBS décompose le périmètre total en livrables, chacun avec un responsable et une date d'échéance. Sur un programme SAP, cela signifie la conception des processus, le paramétrage, la migration des données, l'intégration, les tests, la formation et la bascule, le tout décomposé en tâches.

Sa valeur pratique, c'est la cartographie des dépendances. La migration des données alimente les tests d'intégration, qui alimentent la recette utilisateur, qui alimente la bascule. Quand l'un glisse, l'impact en aval est visible immédiatement.

Comment RISE with SAP change-t-il la planification et le contrôle de projet ?

SAP devient un acteur de la réalisation. Il exploite l'infrastructure et les opérations techniques, et son équipe Customer Success déroule sa propre cadence sur l'adoption et la valeur.

Trois changements en découlent. Il vous faut un circuit d'escalade documenté vers SAP pour les problèmes de plateforme, qui ne passe pas par le partenaire. Il vous faut un forum de revue des extensions sous le comité de pilotage pour décider du traitement de chaque écart dans le cadre du Clean Core. Et vous devriez intégrer la cadence Customer Success de SAP à votre gouvernance plutôt que de la mener en parallèle.

Que doit faire un comité de pilotage sur un programme SAP ?

Décider. Son rôle est de trancher ce que l'équipe de programme ne peut pas : conflits de ressources, litiges de périmètre, changements de budget et tout ce qui demande une autorité transverse. Un comité de pilotage qui se termine sans décision n'était qu'un point d'avancement.

Un comité mensuel sur un grand programme laisse des sujets en attente jusqu'à quatre semaines. Tous les quinze jours est le minimum en phase de réalisation, chaque semaine pendant la bascule et l'hypercare. Envoyez les rapports d'avancement à l'avance et réservez la réunion aux décisions qu'ils soulèvent.