Pourquoi l'ERP ne gérera jamais votre Supply Chain
Les fournisseurs de logiciels d’entreprise aiment qualifier leurs plateformes de « colonne vertébrale numérique » de l’entreprise. Dans le monde de la supply chain, cette colonne vertébrale signifie généralement l’ERP, avec un ensemble de systèmes complémentaires tels que MRP, WMS, TMS, CRM et autres. Pour de nombreuses organisations, la prochaine étape naturelle semble évidente : si l’ERP gère déjà les transactions, pourquoi ne pas le laisser également gérer les décisions ? Ajoutez quelques modules de planification, un moteur de prévision et quelques fonctionnalités d’IA, et la supply chain devrait plus ou moins se gérer toute seule.
Après près de deux décennies passées à construire des logiciels qui font exactement le contraire, j’en suis arrivé à une conclusion assez impolie : les fournisseurs transactionnels habituels sont structurellement inadaptés à livrer des systèmes de décision supply chain satisfaisants. Ce n’est pas une critique de leur compétence. Il s’agit de la catégorie de logiciels qu’ils vendent, des incitations économiques auxquelles ils sont confrontés, et des attentes que le marché leur a imposées.
J’explore cet argument en détail dans mon livre Introduction to Supply Chain, mais je souhaite en extraire une piste ici : pourquoi « où se trouve le cerveau » dans votre paysage logiciel compte plus que ce que la plupart de la littérature est prête à admettre.
Ce que nous demandons vraiment aux logiciels de faire
Les supply chains modernes ne consistent pas seulement à déplacer des boîtes efficacement. Il s’agit de prendre des paris en situation d’incertitude, chaque jour.
Devons-nous acheter un conteneur ou trois ? Retarder une promotion ou l’avancer ? Expédier des stocks rares vers l’Europe ou les États-Unis ? Accepter la quantité minimum de commande de ce fournisseur, ou repousser et risquer une rupture ? Chaque décision est un petit pari aux conséquences asymétriques. Certaines erreurs coûtent peu ; d’autres coûtent cher et continuent de faire des ravages pendant des mois.
Il y a cinquante ans, les êtres humains pouvaient raisonnablement garder la plupart de ces paris en mémoire, aidés par des registres et des feuilles de calcul. Aujourd’hui, même les entreprises de taille moyenne gèrent des dizaines de milliers de SKUs, des centaines de sites, des délais de livraison volatils et des schémas de demande qui réagissent aux prix, à la météo, au marketing, aux concurrents et aux perturbations d’approvisionnement. Les combinatoires dépassent tout simplement le jugement humain non assisté.
Nous demandons donc aux logiciels d’aider. Mais « logiciel » n’est pas une seule chose. Dans une entreprise typique, trois types de systèmes très différents coexistent :
Premièrement, il y a les systèmes transactionnels : ERP, MRP, WMS, TMS, OMS. Leur rôle est de capturer tout ce qui se passe : commandes, réceptions, expéditions, factures, mouvements entrants et sortants des sites. Ce sont des registres glorifiés auxquels s’ajoutent des flux de travail. Leurs principales vertus sont la fiabilité, la traçabilité, les autorisations et l’auditabilité. Si une expédition est envoyée deux fois ou si un paiement disparaît, tout le reste devient sans objet.
Deuxièmement, il y a les systèmes de reporting et d’analyse : outils BI, tableaux de bord, portails KPI, feuilles de calcul alimentées par des data warehouses. Leur rôle est de résumer et de visualiser ce qui s’est passé, et parfois ce qui pourrait se passer. Ils sont conçus pour être inspectés par des humains : graphiques, tableaux, listes d’exceptions, rapports d’écarts.
Enfin, il manque en pratique quelque chose : un véritable moteur de décision. Par là, j’entends un logiciel dont le rôle principal est de prendre tous ces faits bruts, d’en comprendre les schémas, d’évaluer les options, puis de produire des décisions concrètes et auditées : bons de commande, mouvements d’allocation, plannings de production, changements de prix, modifications d’assortiment. Ces décisions devraient être produites de manière routinière et autonome, puis réintégrées dans les systèmes transactionnels comme si un planificateur très cohérent et très rapide avait effectué le travail.
La vision dominante tend à brouiller ces trois rôles. Si la « colonne vertébrale » de l’ERP intègre déjà les données et gère les processus, il peut certainement planifier et optimiser. Sinon, une autre plateforme polyvalente le fera : un « digital core », un « control tower » ou une « unified planning suite ». Dans la littérature, on décrit régulièrement l’ERP comme le cœur du traitement de l’information d’entreprise et la colonne vertébrale de l’entreprise, la planification et l’exécution supply chain étant présentées comme des extensions naturelles de cette même plateforme.
Sur le papier, cela semble attrayant. En pratique, c’est précisément là que les choses commencent à mal tourner.
Pourquoi les fournisseurs transactionnels sont dans le mauvais secteur pour construire le cerveau
Pour comprendre ce décalage, il est utile de se détacher du branding et de regarder ce qu’est réellement l’ERP et ses semblables.
Au fond, ces systèmes sont de grandes bases de données multi-utilisateurs avec des règles strictes sur qui peut changer quoi, et dans quel ordre. Ils sont optimisés pour de nombreuses opérations petites, simples et bien structurées se produisant simultanément : enregistrer cette commande, comptabiliser cette facture, confirmer cette réception. Lorsque les manuels ERP les qualifient de « colonne vertébrale » de l’entreprise, ils le signifient littéralement : ils assurent les nerfs et les vaisseaux sanguins des opérations quotidiennes.
Un véritable moteur de décision, en revanche, n’est pas optimisé pour des milliers de clics légers. Il est optimisé pour une réflexion approfondie.
Il doit ingérer de grandes quantités de données, souvent issues de plusieurs systèmes. Il doit explorer de nombreux futurs possibles, et pas seulement extrapoler une seule prévision. Il doit évaluer les options selon des critères économiques, pas seulement des taux de service ou des objectifs de délais de livraison. Il doit effectuer des calculs qui sont parfois coûteux : modèles probabilistes, simulations, optimisations combinatoires. Et il doit faire tout cela d’une manière qui pourra être auditée plus tard : pourquoi avons-nous acheté vingt palettes de cet article ce jour-là, au lieu de quinze ou aucune ?
Ce n’est pas une question de langage de programmation ou d’optimisation astucieuse. Il s’agit d’un profil d’exécution différent, de compromis d’ingénierie différents, et de différentes formes de responsabilité. Placer ce type de moteur dans le même environnement qui gère vos factures quotidiennes et les écrans d’entrepôt revient à monter un moteur à réaction dans un bus urbain. Ce n’est pas simplement de l’excès de moyens ; cela interfère activement avec la bonne exécution de la tâche du bus.
À partir de là, plusieurs problèmes structurels surgissent.
Le premier est opérationnel. Si vous essayez d’exécuter des analyses lourdes et de gros travaux d’optimisation directement sur votre plateforme transactionnelle, vous soit limitez le travail analytique pour éviter de ralentir les opérations, soit vous risquez de compromettre les temps de réponse lorsque les humains essaient de travailler. Plus vous parvenez à intégrer « l’intelligence », plus vous dégradez la mission principale du système : ne jamais perdre une transaction et ne jamais bloquer un utilisateur.
Le second est sémantique. Les entreprises modernes fonctionnent rarement sur un monolithe unique. Elles utilisent l’ERP pour la finance et les opérations principales, le WMS pour les entrepôts, le TMS pour le transport, le CRM pour les interactions clients, les plateformes de le e-commerce, et parfois des systèmes spécialisés pour la fabrication ou le commerce de détail. Chacun de ces systèmes possède son propre vocabulaire et sa propre version de la vérité. Pourtant, un moteur de décision utile doit avoir une vue d’ensemble sur tous ces systèmes. La tendance naturelle des fournisseurs d’ERP, cependant, est de traiter leur propre schéma comme le centre de l’univers. Tout le reste est soit mappé dessus de manière approximative, soit ignoré.
Le troisième est économique. Les gros fournisseurs transactionnels sont principalement rémunérés par des licences, des sièges, des modules et du stockage ; à l’ère du cloud, ajoutez des niveaux d’abonnement et la consommation. Ils ne sont pas payés en fonction du nombre de décisions qu’ils peuvent automatiser en toute sécurité ou du montant de liquidités qu’ils réinjectent dans votre compte de résultat. Si tant est que, un moteur de décision véritablement efficace réduirait le nombre de sièges de « planificateur » et simplifierait de nombreux flux de travail. Ce n’est pas ce que leur modèle de tarification est conçu pour récompenser.
Superposez cela avec l’écosystème de certification et le tableau devient encore plus clair. Le programme APICS/ASCM CPIM, par exemple, est présenté explicitement comme la norme mondiale pour la planification et la gestion des stocks, et le matériel de formation indique ouvertement que les systèmes ERP intègrent les règles d’affaires dérivées de ce corpus de connaissances.
En d’autres termes : on suppose que la logique de planification standard réside à l’intérieur de l’ERP. Les fournisseurs sont censés l’encoder ; les praticiens sont censés la configurer et la suivre. La mission est d’aligner la pratique avec le canon, et non de repenser l’architecture logicielle ou l’économie des décisions.
Enfin, il y a la culture. La construction de systèmes d’archivage a tendance à attirer, récompenser et promouvoir une mentalité d’ingénierie particulière : celle qui valorise la stabilité, la rétrocompatibilité et la prise en compte des cas limites. Au fil des décennies, ces systèmes accumulent des couches de fonctionnalités, des modules, des personnalisations et des intégrations. Ils deviennent extrêmement performants, mais aussi extrêmement complexes. Ajouter encore un module de planification ou une fonctionnalité d’IA est culturellement plus facile que de tout supprimer. Le résultat est une masse toujours croissante d’écrans de configuration et de paramètres, intégrés dans des flux de travail déjà fragiles.
Demander à cette machine de se réinventer en un moteur de décision vif et tranché relève, au mieux, d’un optimisme.
Le récit dominant, selon ses propres mots
Si vous lisez le matériel des fournisseurs, les livres blancs, et une grande partie de la littérature académique et professionnelle, vous verrez la même histoire se répéter avec de légères variations.
L’ERP est présenté comme une plateforme unificatrice qui intègre toutes les données et processus, « harmonisant » les achats, les stocks, le traitement des commandes et la distribution tout en intégrant des outils d’analytique et de planification. Il est décrit comme la fondation logicielle de l’entreprise, le « digital core » qui sous-tend tout, de la finance à la fabrication en passant par la Supply Chain. Au sommet de ce core, l’on nous promet des fonctionnalités de plus en plus avancées : la prévision de la demande alimentée par l’analytique prédictive, la modélisation de scénarios, l’intégration de la business planning, et plus encore.
En parallèle, le canon de la gestion des opérations fournit les modèles mentaux : le corpus CPIM, les cadres S&OP, les formules de stock de sécurité, la logique MRP. Ceux-ci sont codifiés en tant que meilleures pratiques, programmes d’examen et modèles de maturité. La promesse implicite est simple : si vous implémentez le bon ERP, le configurez selon ces normes et formez vos planificateurs en conséquence, votre Supply Chain se comportera.
Si la réalité ne correspond pas à la promesse, les explications habituelles sont bien connues : qualité des données, gestion du changement, périmètre du projet, manque de soutien de la direction, formation insuffisante. Le remède consiste toujours en la même chose : des implémentations plus soignées, des processus plus disciplinés, une adoption plus complète du corpus standard de connaissances.
Remarquez ce qui est rarement remis en question : l’hypothèse selon laquelle le « cerveau » de la Supply Chain devrait résider à l’intérieur des mêmes systèmes qui enregistrent les commandes et impriment les factures.
Ce qui se passe réellement sur le terrain
Sur le terrain, la plupart des organisations se retrouvent avec un schéma déprimant de cohérence à travers les industries et les géographies.
Les systèmes transactionnels font leur travail de manière raisonnable. Les commandes circulent, les stocks se déplacent, les factures sont envoyées, et les clôtures financières ont lieu. Il y a toujours des bizarreries et des frustrations, mais dans l’ensemble, les registres tiennent.
Autour de ce cœur, le reporting prolifère. Les outils BI se connectent aux data warehouses, qui extraient des données de l’ERP et de ses satellites. Les équipes créent des tableaux de bord, des scorecards, des cockpits et des control towers. Les planificateurs passent une fraction croissante de leur temps à naviguer sur ces écrans, à concilier les divergences entre eux, à exporter des données vers des feuilles de calcul, et à réimporter des chiffres « ajustés ».
Des modules de planification et d’optimisation existent dans bon nombre de ces systèmes. Ils génèrent des prévisions, proposent des quantités de réapprovisionnement et déclenchent des alertes. Pourtant, la plupart du travail lourd reste manuel. Les prévisions sont annulées. Les commandes suggérées sont « examinées » une par une. Les listes d’exceptions s’allongent au point qu’on ne peut raisonnablement les résoudre en une journée de travail, si bien que les gens développent des heuristiques locales : se fier à ces indicateurs, ignorer ceux-là, toujours favoriser ce fournisseur, ne jamais toucher à ces articles.
L’automatisation prend principalement la forme d’une logique conditionnelle à l’intérieur des systèmes transactionnels : si la disponibilité est supérieure à un certain niveau, validez cette commande ; si elle est inférieure, mettez-la en attente dans une file d’exceptions. De loin, cela peut ressembler à un comportement intelligent. De près, ce sont des règles fragiles accompagnées de stratégies d’adaptation humaines.
J’appelle parfois cette situation « automatisation comme paperasserie » : les systèmes sont élaborés, occupés, voire impressionnants, mais ils n’assument que rarement l’entière responsabilité d’une décision ayant un réel poids financier. Il y a toujours un humain attendu pour cliquer sur « OK » quelque part, même si ce clic est devenu un rituel.
Ce n’est pas de cela qu’a l’apparence d’un moteur de décision mature.
Une séparation des préoccupations différente
Si nous prenons au sérieux l’idée que la supply chain est une pratique quotidienne de prise de décision économique en situation d’incertitude, alors nous devrions concevoir le paysage logiciel pour le refléter.
Dans ce paysage, les systèmes transactionnels continuent de faire ce qu’ils font de mieux : ils restent le registre faisant foi de ce qui s’est passé et de ce qui est actuellement engagé. Leurs schémas et flux de travail continueront d’évoluer, et ils resteront critiques. Mais nous leur cessons d’exiger d’être intelligents.
Les systèmes de reporting continuent de faire ce qu’ils font de mieux : aider les humains à voir, comprendre et discuter de ce qui se passe. De bons tableaux de bord et systèmes d’analytique resteront inestimables. Mais nous cesserons de confondre visualisation avec optimisation.
Puis, séparément, nous introduisons un moteur de décision dédié.
Ce moteur reçoit des flux réguliers de données brutes de tous les systèmes transactionnels pertinents : commandes, positions de stocks, capacités, délais, prix, contraintes. Il se moque de savoir si ces données proviennent de l’ERP, du WMS, du TMS ou d’autre chose. Il reconstruit une vue cohérente du monde à partir de ces faits, reconnaît explicitement l’incertitude dans la demande et l’offre, et évalue les actions alternatives en fonction de leurs conséquences financières : marge attendue, risque de rupture de stocks, coût d’obsolescence, coûts d’opportunité en cas de ressources contraintes.
La sortie de ce moteur n’est pas un tableau de bord. C’est un flux d’actions proposées : acheter telle quantité de cette référence chez ce fournisseur à cette date ; expédier ces palettes de cet entrepôt vers celui-ci ce soir ; augmenter le prix de cet article de deux pour cent ; éliminer progressivement cette variante au cours du mois prochain. Chaque action est accompagnée d’assez de contexte pour qu’un humain puisse l’auditer si nécessaire : quelles données ont été utilisées, quels schémas ont été déduits, quels compromis ont été effectués.
Crucialement, ces actions sont réintégrées dans les systèmes transactionnels via des interfaces bien définies. La commande d’achat est créée dans l’ERP comme si un planificateur l’avait tapée. Le transfert de stocks apparaît dans le WMS comme si un responsable d’entrepôt l’avait initié. Le changement de prix atterrit dans le système de tarification avec une date de validité claire.
Les humains ne disparaissent pas de la boucle. Leur rôle évolue. Ils deviennent les administrateurs de la recette numérique : ils décident quels coûts inclure, comment évaluer le risque, quelles contraintes sont réelles et quels scénarios sont acceptables. Ils examinent et affinent le comportement du moteur, plutôt que de microgérer chaque ligne qu’il produit.
Cette architecture semble exotique seulement si vous avez passé trop de temps dans le récit centré sur l’ERP. Du point de vue de l’ingénierie logicielle et de l’économie, il s’agit simplement d’une séparation nette des préoccupations : des registres pour les faits, des tableaux de bord pour la compréhension, des moteurs pour les décisions.
Comment cela confronte la vision dominante
Vu sous cet angle, le récit dominant n’est pas “erroné” autant qu’il soit incomplet.
Il est parfaitement raisonnable de vouloir une colonne vertébrale transactionnelle intégrée. Les entreprises ont énormément bénéficié du passage de systèmes fragmentés de comptabilité, de stocks et de fabrication à un ERP intégré. Il est également raisonnable de vouloir de bons rapports et de standardiser la terminologie ainsi que les processus au sein de la profession. Des initiatives comme CPIM ont joué un rôle important en fournissant aux gens un langage commun et une boîte à outils de base.
Là où je diverge du courant dominant, c’est dans l’hypothèse implicite que, si nous continuons d’enrichir la colonne vertébrale transactionnelle avec plus de modules de planification, plus de fonctionnalités de prévision, plus d’analyses et davantage d’options de configuration, nous finirons par parvenir à des décisions supply chain efficaces et automatisées.
Je ne crois pas que cette convergence aura lieu.
Tant que le “cerveau” sera censé vivre au sein de systèmes dont la mission principale et le modèle économique reposent sur la tenue de registres, des flux de travail basés sur les rôles et des meilleures pratiques génériques, nous resterons coincés dans un schéma d’interfaces impressionnantes et d’automatisation timide. Nous continuerons à voir des organisations où les planificateurs passent leurs journées à manipuler des listes d’alertes plutôt qu’à façonner la logique économique qui génère ces alertes.
L’alternative n’est pas de jeter l’ERP ou d’ignorer les méthodes établies. Il s’agit de les considérer pour ce qu’elles sont : une infrastructure nécessaire et un héritage professionnel précieux, mais pas l’endroit où les vraies décisions devraient être prises.
Une fois que nous acceptons cette distinction, une conversation plus honnête devient possible. Nous pouvons demander à nos fournisseurs transactionnels d’offrir d’excellents registres et des interfaces claires, plutôt que “l’optimization pilotée par l’IA”. Nous pouvons demander à nos équipes BI des vues simples et véridiques de la réalité, plutôt que des tableaux de bord animés qui prétendent être des salles de contrôle. Et nous pouvons exiger de nos moteurs de décision—et des personnes qui les conçoivent et les exploitent—un niveau supérieur : des décisions nocturnes et non supervisées, responsables en termes financiers, continuellement améliorées.
C’est la direction que nous avons poursuivie chez Lokad pendant de nombreuses années. Ce n’est pas le seul chemin, mais c’est celui qui part d’une observation simple : lorsque votre supply chain est effectivement délimitée par le logiciel, alors l’endroit où vous placez le cerveau de ce logiciel fait toute la différence.
