Déploiement IBP, mois 18 : ce qu'on a raté

Le go-live a eu lieu un mardi d'octobre. Le directeur de programme a envoyé un e-mail au comité de pilotage. Tableau de bord vert. Tous les jalons atteints. Le système était en production dans six marchés, couvrant 78 % du chiffre d'affaires, avec 14 mois d'historique chargés et le moteur de prévision statistique tournant chaque nuit.

En mars suivant, trois des six marchés étaient revenus à des fichiers Excel parallèles, maintenus en plus du système. La demand planner du plus grand marché avait discrètement reconstruit tout son classeur de planification et exportait chaque matin du système vers celui-ci. Le processus S&OP que l'outil IBP devait permettre tournait à peu près au même niveau de maturité qu'avant l'implémentation à 4,2 millions de dollars.

Ceci est un post-mortem. Les noms sont changés. Le schéma n'a rien d'inhabituel.

---

Ce que l'IBP est censé apporter

L'Integrated Business Planning est la forme évoluée du S&OP : la même logique d'alignement transverse, étendue pour couvrir tout l'horizon de planification (typiquement 24 à 36 mois), pleinement intégrée à la planification financière, et portée par une seule plateforme plutôt que par le patchwork Excel-et-ERP qu'utilisent la plupart des entreprises.

Les éditeurs (SAP IBP, o9 Solutions, Kinaxis, OMP, Anaplan) promettent des variantes du même résultat : une version unique de la vérité, une capacité de planification par scénarios, une réconciliation offre-demande en temps réel, et l'élimination de la charge de réconciliation manuelle qui plombe la productivité de la plupart des équipes de planification.

Le Gartner Market Guide for Supply Chain Planning Solutions (2023) estime que les entreprises dotées d'une capacité IBP mature obtiennent 15 à 20 % de réduction des stocks, 10 à 15 % d'amélioration de la précision des prévisions, et 20 à 30 % de réduction du cycle de planification. Ce sont des chiffres réels, issus d'implémentations réelles. Ce sont aussi les chiffres du quartile supérieur des implémentations. L'histoire médiane est différente.

---

Ce que dit la recherche sur l'échec des implémentations IBP

Le rapport ERP/Planning 2023 de Panorama Consulting, portant sur 271 implémentations, constate que 58 % des implémentations de planification supply chain ont dépassé leur budget initial, avec un dépassement moyen de 24 %. Le dépassement moyen des délais était de 33 %. Plus significatif encore : seulement 41 % des répondants ont déclaré que leur implémentation avait livré les bénéfices métier attendus dans les trois ans suivant le go-live.

Une étude Gartner de 2022 a identifié la conduite du changement organisationnel comme première cause d'échec des implémentations de planification supply chain, citée par 67 % des répondants — devant les problèmes technologiques (31 %), la qualité des données (48 %) et les lacunes de conception des processus (44 %). À noter : la qualité des données est citée par près de la moitié des répondants, mais reste tout de même derrière la conduite du changement.

L'analyse 2023 du Boston Consulting Group sur les transformations digitales de la supply chain constate que 70 % des transformations digitales de supply chain n'ont pas atteint leurs objectifs déclarés — un chiffre cohérent avec le taux d'échec plus large des transformations digitales, que McKinsey estime à 70 % tous secteurs confondus.

Ce que les statistiques agrégées ne captent pas, c'est la texture précise de la manière dont les implémentations IBP échouent. Le système fonctionne. Les données se chargent. Les modèles statistiques tournent. L'échec est dans l'adoption — et l'échec d'adoption suit un schéma constant.

---

Mois 1–3 : la lune de miel

Les trois premiers mois après le go-live sont réellement productifs. L'équipe de planification a été fortement formée. Les consultants sont encore sur site. Le comité de pilotage reste attentif. Les problèmes de qualité des données, connus mais tolérés dans l'ancien système, sont activement traités car le nouveau système les rend visibles.

La précision des prévisions s'améliore modestement, typiquement de 3 à 5 points, parce que les nouveaux modèles statistiques sont meilleurs que ceux sous Excel qu'ils remplacent, et parce que le nettoyage des données effectué pendant l'implémentation a retiré une partie du bruit dans l'historique.

L'équipe apprend l'outil. Chaque cycle de planification est plus lent qu'avant parce que le processus est nouveau. C'est attendu et communiqué comme tel. Les consultants expliquent qu'il y a une baisse de productivité avant que la courbe ne reparte à la hausse. Le comité de pilotage l'accepte. Le directeur de programme rapporte que les indicateurs d'adoption sont dans les clous.

---

Mois 4–6 : la première crise

Quelque chose cloche dans les données. C'est toujours quelque chose dans les données.

Dans le cas que je décris ici, c'était l'historique promotionnel. L'entreprise menait d'importantes promotions commerciales — offres BOGOF, remises volume, promotions prix coordonnées avec les comptes clés — et l'historique chargé dans le système ne signalait pas systématiquement ces périodes. La prévision statistique extrapolait donc à partir d'un historique incluant des pics promotionnels sans savoir qu'il s'agissait de pics promotionnels. Résultat : une prévision de base structurellement biaisée à la hausse pour certains SKU.

Les demand planners le savaient. Ils le savaient depuis des années. Dans l'ancien système, ils corrigeaient cela manuellement, en s'appuyant sur une connaissance institutionnelle des périodes promotionnelles et sur l'ampleur approximative de la correction à apporter à l'historique. Le nouveau système n'avait pas cette connaissance. La logique de correction était censée être construite pendant l'implémentation. Elle l'a été partiellement — assez pour passer les tests de recette (UAT) — mais pas de façon assez robuste pour couvrir toute la variété des mécaniques promotionnelles utilisées par l'entreprise.

La demand planner du marché trois, dans son poste depuis neuf ans, a soulevé le problème dès la sixième semaine. La réponse de l'équipe d'implémentation a été qu'un correctif était en cours de cadrage. Le correctif a pris onze semaines à être pleinement déployé. Pendant ces onze semaines, elle a maintenu son fichier Excel.

Elle n'a jamais vraiment arrêté.

---

Mois 7–12 : le départ des consultants

L'équipe de consultants s'est retirée au mois huit. C'est standard. Le contrat d'implémentation couvre le go-live et une période de stabilisation. Au mois huit, la stabilisation est déclarée acquise. Les consultants transfèrent les connaissances à l'équipe interne, documentent le processus, et partent.

Ce qui part avec eux : la connaissance institutionnelle des raisons derrière certains choix de conception, la capacité à escalader rapidement les problèmes de données au sein de la structure de support de l'éditeur, et l'énergie de changement qui maintenait le comité de pilotage engagé.

Ce qui reste : une équipe interne qui comprend l'outil au niveau utilisateur mais pas au niveau configuration, un ensemble de documents de processus qui décrivent ce que le processus est censé être plutôt que ce qu'il est réellement, et un contrat de support éditeur qui traite les bugs mais pas l'adoption.

Le premier cycle S&OP après le départ des consultants a pris trois jours de plus que le cycle précédent. La réunion de revue de la demande a dépassé le planning de deux heures parce qu'un problème de données dans le système n'a pas pu être diagnostiqué en séance. L'équipe commerciale, qui avait toléré des cycles plus lents par déférence pour le programme, a commencé à demander ouvertement si le nouveau système était réellement meilleur que l'ancien.

---

Mois 13–18 : le problème des fichiers parallèles

Au mois treize, les fichiers Excel parallèles étaient visibles pour qui savait où regarder.

Ils n'étaient pas secrets. Les planners ne les cachaient pas. C'étaient des adaptations pratiques à des lacunes précises du système. La demand planner du marché un avait un fichier pour gérer les introductions de nouveaux produits : le processus NPI du système était trop lent par rapport à la vitesse à laquelle le commercial lançait des produits. Le planner du marché quatre avait un fichier pour gérer les prévisions spécifiques aux clients : trois comptes clés exigeaient des soumissions de prévisions hebdomadaires qui ne correspondaient pas aux mailles de planification du système. La planner du marché trois avait son fichier de correction de l'historique promotionnel, qui n'avait jamais été pleinement remplacé.

Chaque fichier était une réponse raisonnable à une lacune réelle. Chaque fichier était aussi une fracture dans la « version unique de la vérité » que l'implémentation IBP avait vendue.

Le problème s'aggrave parce que les fichiers ne restent pas contenus. Une fois qu'une planneuse a un fichier parallèle en qui elle a plus confiance que le système pour un usage donné, la frontière de cette confiance s'élargit. Elle commence à vérifier le chiffre du système contre son fichier avant de le valider. En cas de divergence, elle utilise son chiffre. Le système devient l'entrée de son processus plutôt que la sortie.

Au mois dix-huit, le directeur de la planification ne pouvait plus affirmer avec confiance au comité de pilotage que les chiffres du système IBP étaient ceux à partir desquels les marchés planifiaient réellement.

---

Ce qui a vraiment échoué

Pas la technologie. SAP IBP est un système compétent. Le moteur de prévision fonctionne. Les outils de planification par scénarios fonctionnent. L'intégration financière fonctionne.

Pas les données. La qualité des données s'est réellement améliorée grâce à l'implémentation : les données de référence étaient plus propres, l'historique plus complet, et le problème d'historique promotionnel, bien qu'il ait pris trois mois, a fini par être résolu.

Ce qui a échoué, ce sont trois choses que la méthodologie d'implémentation n'a pas suffisamment traitées :

Le processus a été conçu pour l'organisation espérée, pas pour l'organisation réelle. Le processus cible supposait que le commercial fournirait des données structurées de volumes promotionnels selon un rythme mensuel. Dans la pratique, le commercial fournissait les informations promotionnelles au coup par coup, souvent deux semaines avant l'exécution, dans des formats variant selon le marché et le key account manager. L'écart de conception entre « le commercial saisit les pics de volume chaque mois » et « le commercial appelle la planification le jeudi précédant une promotion » n'a jamais été comblé.

Les incitations n'ont pas changé. Les demand planners étaient évalués sur la précision des prévisions. La prévision statistique du système IBP servait de base — mais leur bonus était calculé sur la précision de la prévision consensuelle, dont ils avaient la responsabilité d'ajuster à partir de cette base statistique. Quand la base statistique du système se trompait (comme dans le cas de l'historique promotionnel), l'ajuster correctement améliorait la précision. Mais l'ajustement prenait du temps et exigeait de défendre l'écart auprès du commercial. Le chemin de moindre résistance consistait à maintenir le fichier Excel, à l'utiliser pour produire le bon chiffre, puis à saisir ce chiffre dans le système. Le système enregistrait le résultat. Le fichier Excel contenait le raisonnement.

Le programme de conduite du changement s'est arrêté au go-live. Le volet conduite du changement de l'implémentation (communication, formation, gestion des parties prenantes) était structuré autour de l'adoption de l'outil, pas de l'adoption du processus. Il mesurait si les utilisateurs savaient faire fonctionner le système, pas s'ils lui faisaient assez confiance pour cesser d'utiliser des alternatives. Après le go-live, le budget de conduite du changement était épuisé et l'attention est passée à autre chose. La résistance de l'organisation au processus, qui avait été contenue pendant l'implémentation par l'énergie du programme, a resurgi une fois cette énergie retirée.

---

Ce qu'exige une vraie transformation IBP, et que personne ne budgète

Sur la base de ce post-mortem, et de ce que j'ai observé dans d'autres implémentations :

L'année 2 est la vraie implémentation. La première année, c'est le déploiement du système. La deuxième année, c'est le processus qui prend réellement racine, ce qui exige des ressources internes dédiées, une attention exécutive continue, et un budget pour les correctifs qui émergent de l'usage réel. La plupart des contrats d'implémentation budgètent l'année 1. L'année 2 est une pensée après coup.

Un architecte de processus qui n'est pas employé de l'éditeur. Les consultants d'implémentation des éditeurs sont experts pour déployer l'outil dans l'architecture de référence de l'éditeur. Ils ne sont pas incités à vous dire que le processus commercial de votre organisation est structurellement incompatible avec des cycles de planification mensuels. Ce jugement exige quelqu'un qui répond des résultats de votre entreprise, pas du projet d'implémentation.

L'alignement des incitations avant la refonte des processus. Si la structure de bonus de l'équipe commerciale récompense le chiffre d'affaires de l'année en cours sans égard pour la précision des prévisions, aucun processus IBP ne produira de signaux de demande honnêtes. Le processus découle des incitations. Corriger le processus sans corriger l'incitation produit des chiffres qui ont l'air justes mais ne reflètent pas la réalité commerciale.

Une évaluation honnête des fichiers parallèles. Au mois dix-huit, la bonne réponse au problème des fichiers parallèles n'était pas d'exiger que les planners cessent de les utiliser. C'était de comprendre pourquoi chaque fichier existait, de combler les lacunes qui les avaient créés, et de gagner la confiance qui rendrait les planners disposés à y renoncer. Nous ne l'avons pas fait assez vite.

---

Le chiffre qui compte

Dans les dix-huit mois entre le go-live et le moment où ce post-mortem a été commandité, l'implémentation IBP avait coûté les 4,2 millions de dollars de frais d'implémentation initiaux, plus environ 1,1 million de dollars de stabilisation et de correctifs, plus environ 2 400 heures-personnes internes de planification passées à gérer l'écart entre le système et les fichiers parallèles.

La précision des prévisions, l'indicateur phare, s'était améliorée de 4 points par rapport à la base. Les stocks avaient reculé de 8 % dans deux marchés et augmenté de 3 % dans un marché où le problème d'historique promotionnel avait provoqué du sur-approvisionnement avant le déploiement du correctif. L'intégration financière fonctionnait proprement dans quatre marchés sur six.

Le directeur de programme a qualifié cela de succès partiel. Il avait probablement raison. Ce n'était pas non plus ce qui avait été promis, ni ce qui avait été acheté, ni ce que justifiaient les 5,3 millions de dollars de coût total.

La leçon n'est pas que l'IBP ne fonctionne pas. La leçon est que le contrat d'implémentation tarife la technologie et le go-live. La transformation se tarife séparément, en temps exécutif, en ressources internes, en refonte de processus et en ajustement des incitations, et ce prix est rarement annoncé à l'avance.

---

Sources

• Panorama Consulting Group. (2023). 2023 ERP Report. Panorama Consulting.
• Gartner. (2023). Market Guide for Supply Chain Planning Solutions. Gartner Research.
• Gartner. (2022). "Top Reasons Supply Chain Planning Implementations Fail." Gartner Research Note.
• Boston Consulting Group. (2023). "Digital Supply Chain Transformation: Why Most Fail and How to Succeed." BCG.
• McKinsey & Company. (2018). "Unlocking success in digital transformations." McKinsey Digital.
• Oliver Wight International. (2023). IBP Maturity Assessment Framework. Oliver Wight.
• ASCM. (2022). Supply Chain Resilience and Digital Readiness Report. ASCM.
• Wallace, T. F. (2004). Sales & Operations Planning: The Executive's Guide. T.F. Wallace & Company.
• Cecere, L. (2022). Supply Chain Metrics That Matter. Supply Chain Insights LLC.
• Lapide, L. (2011). "IBP: Not your father's S&OP." The Journal of Business Forecasting. 30(3).