Combien de personnes faut-il pour changer une ampoule de supply chain ?

Joannes Vermorel

Supply chains impliquent un patchwork de enterprise software. Ces couches logicielles ont été progressivement, et parfois de manière hasardeuse, déployées au cours des quatre dernières décennies¹. Le vénérable EDI (Electronic data interchange) peut se trouver à côté d’un prototype de blockchain. De tels systèmes gèrent principalement des aspects banals, mais essentiels, de la supply chain : production, stockage, transport, facturation, conformité, etc.

Ces systèmes n’ont pas été mis en place dans le but d’offrir un environnement de données propre à la R&D. Ce simple fait explique pourquoi la plupart des initiatives de prévision des séries temporelles, et plus généralement la plupart des initiatives de data science, échouent en supply chain. À titre d’anecdote, il est généralement plus rapide de déplacer physiquement tous les biens détenus par un warehouse vers un autre site que de migrer toute l’infrastructure IT vers un nouveau site.

En conséquence de cette complexité, le déploiement des initiatives de supply chain « modernes » implique invariablement trop de spécialistes. Pour une entreprise de taille importante, le projet typique de supply chain implique:

• Le consultant qui conduit le projet et assiste la direction générale.
• Le spécialiste de l’infrastructure IT qui évalue les risques impliqués par l’infrastructure informatique additionnelle.
• L’administrateur de base de données qui identifie les tables pertinentes dans les systèmes concernés.
• Le spécialiste ETL qui conçoit le pipeline garantissant la logistique des données.
• Le consultant IT qui apporte une aide supplémentaire pour les aspects IT capricieux.
• Le coordinateur de projet qui fait l’interface entre les équipes IT et celles de la supply chain.
• L’analyste d’affaires qui construit la majorité des rapports pour la direction.
• Le data scientist qui prendra en charge la partie modélisation prédictive.
• Le support technique du fournisseur qui gère les bugs de la technologie introduite.
• Le commercial du fournisseur qui gère les attentes et propose des ventes additionnelles en cours de route.
• Le praticien de la supply chain qui représente la « voix du client ».
• Le cadre de la supply chain qui défend l’initiative.

Cependant, faire intervenir de nombreux spécialistes engendre sa propre série de problèmes. Personne, pas même la direction générale, ne comprend vraiment ce qui se passe. Les aspects IT restent invariablement opaques pour tout le monde sauf les spécialistes IT. Inversement, l’IT est tellement débordé et sur tellement de fronts - pas seulement en supply chain - qu’il leur reste très peu de capacité pour peaufiner les détails des problèmes qu’ils tentent de résoudre. Enfin, la data science aggrave le problème avec une discipline de plus, pour le plus grand mystère des consultants, des spécialistes IT et des praticiens de la supply chain.

De plus, les tiers, les consultants, les entreprises IT et les fournisseurs de technologie ont chacun leurs propres agendas, qui ne sont pas alignés avec ceux de l’entreprise. Il y a de l’argent à gagner en instaurant un surplus de friction² à chaque étape du processus. Cela permet de démarrer avec un budget provisoire mince, qui « étonnamment » tend à croître régulièrement au fil du temps à mesure que de plus en plus de ressources doivent être injectées dans l’initiative.

Une partie de la complexité mentionnée ci-dessus est irréductible, mais une autre partie est tout à fait accidentelle. La vieille plaisanterie selon laquelle chaque PDG sait que la moitié de leur entreprise ne fait rien de valeur, sans savoir de quelle moitié il s’agit.

À cet égard, la stratégie de Lokad, en tant que fournisseur de technologie, a consisté à s’attaquer de front à cette complexité accidentelle. L’essentiel est simple : réduire de manière spectaculaire le nombre de spécialistes impliqués. Une seule personne, à savoir le supply chain scientist, prend en charge l’ensemble du pipeline IT, qui commence par les données brutes d’entrée et se termine par les supply chain decisions finalisées. Le supply chain scientist assume l’entière responsabilité de tout ce qui se passe dans le pipeline - y compris les aspects intelligents, comme le machine learning.

Les logiciels d’entreprise classiques ne sont pas compatibles avec la supply chain car un « configurateur » n’offre pas la souplesse nécessaire pour faire face à l’extraordinaire diversité des problèmes auxquels sont confrontées les supply chains. Un langage de programmation³ est requis. Malheureusement, les langages de programmation génériques, comme Python, ne sont pas compatibles avec le rôle de supply chain scientist. Le niveau de compétence requis est trop élevé, et ces rôles, au sein de l’entreprise, se transforment en ingénieurs logiciels. Il n’y a rien de mal à avoir des ingénieurs logiciels, c’est juste que l’expertise en supply chain doit être réintroduite en cours de route par le biais de spécialistes qui ne sont pas ingénieurs logiciels. Bientôt, la plupart des rôles mentionnés ci-dessus feront partie de l’initiative.

Cependant, pour que le supply chain scientist puisse endosser autant de rôles, un environnement de programmation dédié est nécessaire : un environnement qui permette au scientifique d’aborder les défis de l’optimisation prédictive d’une supply chain avec un minimum de complications⁴. La réponse technologique de Lokad à ce problème a été Envision, a domain-specific language.

Le concept d’Envision repose sur l’idée qu’il vaut mieux être approximativement correct que précisément faux. Un expert capable de cerner l’ensemble de la situation de la supply chain est de loin plus à même de proposer une solution sensée que dix experts, chacun connaissant seulement un aspect de la situation. De plus, la solution élaborée par un esprit unique - comparée à celle produite par un comité - est presque toujours plus simple et plus facile à maintenir.

Dans la plupart des domaines de l’ingénierie, l’avantage d’avoir un comité travaillant sur le problème compense la friction supplémentaire introduite par l’existence même du comité. Cependant, en supply chain, ce n’est généralement pas le cas. La cohérence end-to-end de la stratégie, obtenue grâce au travail d’un seul esprit - ou du moins, de très peu d’entre eux - l’emporte sur la plupart des optimisations « locales » qu’un comité fournit invariablement. Aligner l’offre et la demande est fondamentalement un défi à l’échelle du système⁵.

La principale valeur du supply chain scientist est d’opérer à l’échelle du système, englobant l’ensemble de la supply chain, depuis les enregistrements électroniques bruts jusqu’à la stratégie élaborée par la direction générale de l’entreprise. Cependant, loin d’être un loup solitaire, le scientifique reçoit beaucoup d’aide. L’IT facilite l’accès aux données pertinentes (sans tenter de prétraiter les données). Les opérations documentent les processus en place, les contraintes opérationnelles et les divers surcoûts. Le marketing clarifie les coûts d’opportunité qui ne peuvent être déduits des livres comptables, par exemple les coûts de stock-out. La direction cristallise la vision, en précisant ce que le scientifique doit optimiser en premier lieu, etc.

Au final, les supply chain decisions⁶ ne sont pas le produit d’un « système » où la responsabilité est diluée parmi de nombreuses personnes, souvent des dizaines. Ces décisions, toutes, sont le fruit des recettes numériques mises en œuvre par le supply chain scientist, un esprit unique, qui assume la responsabilité de leurs performances par rapport à l’entreprise dans son ensemble. Cette personne est faillible, mais elle bénéficie de beaucoup d’aide, y compris de pairs prêts à prendre le relais si nécessaire. D’après mon expérience, c’est la seule manière de commencer à optimiser une supply chain, même si tout comité de taille significative finira invariablement par noyer tous les observateurs sous un flot de KPI, de graphiques et de rapports pour tenter de prouver le contraire.