La supply chain en tant que service
En termes d’optimisation prédictive, la plupart des supply chains sont bloquées au début des années 19901. Les grandes entreprises ont déjà mené toute une série d’initiatives « prédictives » au cours des deux dernières décennies. Cependant, peu de ces mises à niveau ont eu un impact significatif sur la supply chain.

Il y a une décennie, chez Lokad, alors que nous commencions à aborder les causes profondes de ces échecs, la supply chain en tant que service (SCaaS) est apparue comme notre modèle d’affaires, remplaçant le modèle Software as a Service (SaaS). Nous avons commencé à vendre des abonnements « logiciel+expert ». L’expert, à savoir un Supply Chain Scientist, met en œuvre les recettes numériques qui génèrent les décisions, tandis que le logiciel, à savoir la plateforme Lokad, fournit à l’expert l’infrastructure dont il a besoin pour opérer rapidement et de manière fiable.
Pendant cette décennie, notre pratique de la supply chain en tant que service a été un facteur dominant, sinon le plus important, dans l’augmentation du taux de succès de nos initiatives supply chain. Pourtant, des objections sont fréquemment soulevées contre l’idée même de la supply chain en tant que service.
Nous n’externaliserons pas notre compétence supply chain. Cette objection implique qu’il existe des compétences supply chain stratégiques en interne à préserver. Cela peut être le cas, mais le plus souvent, cette compétence ne qualifie pas comme « stratégique ». La plupart des entreprises, grandes incluses, n’atteignent même pas un score de 10 à notre test de performance supply chain de 5min. Pire encore, des initiatives lourdes comme le S&OP, tendent à diminuer régulièrement la véritable compétence supply chain en fragmentant davantage les processus décisionnels.
Au contraire, la supply chain en tant que service ouvre la voie à l’émergence d’une véritable compétence supply chain stratégique au sein de l’entreprise. Cela commence par la robotisation des processus décisionnels. En effet, sans automatisation, les équipes supply chain peinent à penser de manière stratégique. Toute l’énergie de l’équipe est consacrée à gérer les cas particuliers de la supply chain. En revanche, avec la mise en place de la supply chain en tant que service, plusieurs clients nous ont confié que c’était la première fois dans leur histoire qu’ils pouvaient prendre le temps de travailler sur des problèmes complexes tels que les cannibalisations ou l’optimisation du MOQ.
Nous y parviendrons grâce à des outils simples. Cette objection considère le manque de compétences en programmation des équipes supply chain comme un axiome, et ainsi, exclut des catégories entières d’outils. En matière de supply chain, il existe trois grands types d’outils « simples » : les applications classiques, les applications low code et les tableurs.
Les applications classiques offrent de nombreuses options et fonctionnalités pour faire face aux variations de la supply chain. L’application semble facile au début : son utilisation n’est qu’une question de configuration avant que le workflow ne prenne le relais. Aucune programmation n’est requise. Cependant, en pratique, les situations de supply chain dépassent invariablement les capacités de l’application. Les praticiens, confrontés à une « app », se rabattent sur les tableurs pour accomplir le travail.
Les applications low code promettent la puissance de la programmation sans pour autant nécessiter de maîtriser un langage de programmation. Elles disposent généralement d’un éditeur visuel. Malheureusement, l’approche low code ne parvient pas à gérer la complexité rencontrée même dans des supply chains banales. Sur un exemple simplifié comportant 2 tables et 10 champs, le low code semble excellent. Sur un exemple réel comportant 20 tables et 500 champs, le low code est affreux. Lorsqu’on donne accès à une application low code, les praticiens se rabattent également sur les tableurs pour accomplir le travail.
Les tableurs sont, de loin, l’outil utilisé par les praticiens de la supply chain. Bien qu’ils fassent le travail, il existe des nuances qui ne s’inscrivent tout simplement pas dans le paradigme des tableurs, que ce soit avec Microsoft Excel ou une alternative web. Les prévisions probabilistes et l’optimisation stochastique n’appartiennent tout simplement pas au domaine des tableurs. Tant que les tableurs seront impliqués, la pratique du SCM restera bloquée dans l’ère des années 1990.
La supply chain en tant que service est l’étincelle nécessaire pour faire évoluer la supply chain. Contester des pratiques établies depuis deux ou trois décennies relève déjà d’un combat ardu. La supply chain en tant que service est l’occasion de mener ce combat aux côtés de vétérans qui y ont déjà fait face dans d’autres entreprises.
Nous le ferons avec notre propre équipe de data science. Au début des années 2000, l’objection était formulée comme nous le ferons avec notre propre équipe de data mining. Le data mining est mort, vive la data science. Cependant, la plupart des entreprises oublient les leçons de leurs initiatives de data mining ratées il y a 20 ans : la technologie n’était presque jamais la cause racine de l’échec, c’était une tour d’ivoire le problème.
En ce qui concerne la supply chain, engager des data scientists équivaut presque invariablement à préparer l’initiative à un échec lent et coûteux. Les data scientists sont généralement de jeunes ingénieurs ayant suivi une formation sur une série de frameworks et/ou langages open source. En conséquence, le data scientist type, tout comme son prédécesseur le data miner, observe le monde à travers des prismes techniques. Une équipe de data science générera un flux continu de « solutions en quête de problèmes ». Des conférences seront données, des démonstrations seront réalisées. Les praticiens de la supply chain féliciteront poliment l’équipe de data science, et veilleront à ce qu’aucune de ses « solutions » ne s’approche de près de la production effective. À cet égard, les praticiens prennent la bonne décision.
Les fournisseurs de la supply chain en tant que service ne peuvent se permettre d’être purement décoratifs. La plupart des entreprises peinent à se séparer de leurs talents, comme les data scientists, même si ces personnes ne contribuent pas réellement à l’entreprise. Cependant, la plupart n’hésitent pas à mettre fin aux services d’un prestataire tiers qui ne fournit pas assez. Les fournisseurs de la supply chain en tant que service sont des survivants qui parviennent à démontrer leur valeur constante encore et encore.
En tant que fournisseur de la supply chain en tant que service, Lokad recrute rarement des profils de pure data science pour ses rôles de « Supply Chain Scientist ». À la place, nous privilégions des ingénieurs prêts à devenir avant tout des experts supply chain. Les modèles statistiques sont un moyen, et non une fin. Les data scientists ont trop souvent tendance à pousser les modèles numériques à leurs limites. Les Supply Chain Scientists n’essaient pas de faire publier un article, ils veulent accomplir le travail avec un minimum de tracas. En pratique, cela fait toute la différence entre une solution de niveau production et un prototype sophistiqué qui n’atteint jamais la production.
-
Les logiciels supply chain des débuts des années 1990 se caractérisent par des prévisions ponctuelles des séries temporelles, des stocks de sécurité et une insistance sur les revues manuelles routinières de tous les chiffres générés par le logiciel, généralement avec le soutien d’exceptions et d’alertes. Le degré de sophistication derrière les prévisions varie, mais il est pour la plupart insignifiant en ce qui concerne la performance de la supply chain. Les cas particuliers sont nombreux et invariablement traités via des tableurs. ↩︎