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

Joannes Vermorel

Les supply chains impliquent un patchwork de logiciels d’entreprise. Ces couches logicielles ont été déployées progressivement, et parfois de manière chaotique, au cours des quatre dernières décennies¹. Le vénérable EDI (échange de données informatisé) peut côtoyer un prototype de blockchain. Ces systèmes opèrent principalement des aspects banals mais essentiels de la supply chain tels que la production, le stockage, le transport, la facturation, la conformité, etc.

Ces systèmes n’ont pas été mis en place dans le but d’offrir un environnement de données propre à des fins de R&D. Ce simple fait explique pourquoi la plupart des initiatives de prévision, et plus généralement la plupart des initiatives de data science, échouent dans la supply chain. À titre d’exemple anecdotique, il est généralement plus rapide de déplacer physiquement tous les biens détenus par un entrepôt vers un autre site que de migrer toute la plomberie informatique 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 de supply chain typique implique :

• Le consultant qui pilote le projet et assiste la direction générale.
• Le spécialiste de l’infrastructure informatique qui évalue les risques liés à la plomberie informatique supplémentaire.
• L’administrateur de base de données qui identifie les tables pertinentes dans les systèmes pertinents.
• Le spécialiste ETL qui conçoit le pipeline qui assure la logistique des données.
• Le consultant informatique qui apporte une paire de mains supplémentaire pour les parties informatiques délicates.
• Le coordinateur de projet qui fait le lien entre les informaticiens et les professionnels de la supply chain.
• L’analyste métier qui construit la plupart des rapports pour la direction.
• Le data scientist qui s’occupe de la modélisation prédictive.
• Le support technique du fournisseur qui navigue dans les problèmes de la technologie introduite.
• Le commercial du fournisseur qui gère les attentes et vend des “choses” en cours de route.
• Le praticien de la supply chain qui représente la “voix du client”.
• Le cadre de la supply chain qui est le champion de l’initiative.

Cependant, avoir de nombreux spécialistes sur le cas crée ses propres problèmes. Personne, pas même la direction générale, ne comprend vraiment ce qui se passe. Les parties informatiques sont invariablement opaques pour tout le monde sauf les informaticiens. À l’inverse, l’informatique lutte tellement et sur tant de fronts - pas seulement la supply chain - qu’elle a très peu de bande passante pour résoudre les détails des problèmes qu’elle tente de résoudre. Enfin, la data science aggrave le problème avec une autre discipline qui est principalement opaque aux consultants, aux informaticiens et aux praticiens de la supply chain.

De plus, les tiers, les consultants, les entreprises informatiques et les fournisseurs de technologies ont tous leurs propres agendas, qui ne sont pas alignés sur ceux de l’entreprise. Il y a de l’argent à gagner en introduisant des frictions supplémentaires² à chaque étape du processus. Cela permet de commencer avec un budget provisoire mince, qui “étonnamment” a tendance à augmenter régulièrement au fil du temps, car de plus en plus de ressources doivent être investies dans l’initiative.

Une partie de la complexité énumérée ci-dessus est irréductible, mais une autre partie est assez accidentelle. Le vieil adage selon lequel chaque PDG sait que la moitié de son entreprise ne fait rien de valeur, mais il ne sait pas laquelle.

À cet égard, la stratégie de Lokad, en tant que fournisseur de technologies, a été de s’attaquer frontalement à cette complexité accidentelle. L’idée principale est simple : réduire de manière drastique le nombre de spécialistes impliqués. Une seule personne, à savoir le Supply Chain Scientist, s’occupe de l’ensemble du pipeline informatique, qui commence par les données brutes en entrée et se termine par les décisions de la supply chain finalisées. Le Supply Chain Scientist est entièrement responsable de tout ce qui se passe le long du pipeline - y compris les aspects intelligents, comme l’apprentissage automatique (machine learning).

Les logiciels d’entreprise classiques ne sont pas compatibles avec la supply chain car un “configurateur” n’est pas assez expressif pour faire face à la diversité des problèmes auxquels sont confrontées les supply chains. Un langage de programmation³ est nécessaire. Malheureusement, les langages de programmation génériques, comme Python, ne sont pas compatibles avec le rôle de Supply Chain Scientist. La barre des compétences est trop élevée 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, mais l’expertise en supply chain doit être réintroduite en cours de route grâce à des spécialistes qui ne sont pas des ingénieurs logiciels. Très rapidement, la plupart des rôles énumérés ci-dessus font 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 permet au scientifique de relever les défis de l’optimisation prédictive d’une supply chain avec le moins de tracas possible⁴. La réponse technologique de Lokad à ce problème a été Envision, un langage spécifique au domaine.

Le concept d’Envision repose sur l’idée qu’il vaut mieux être approximativement correct que complètement faux. Un expert qui peut avoir une vision globale de la situation de la supply chain a beaucoup plus de chances de produire une solution sensée que 10 experts, chacun étant seulement familier avec une facette de la situation. De plus, la solution produite par une seule personne - 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, les avantages d’un comité travaillant sur un problème atténuent les frictions supplémentaires introduites par l’existence même du comité. Cependant, dans la supply chain, ce n’est que rarement le cas. La cohérence de bout en bout de la stratégie, obtenue comme le produit d’une seule personne - ou du moins de quelques-unes - tend à surpasser la plupart des optimisations “locales” qu’un comité livre invariablement. L’alignement de l’offre et de la demande est fondamentalement un défi au niveau du système⁵.

La valeur principale du Supply Chain Scientist est d’opérer au niveau du système, englobant l’ensemble de la supply chain, des enregistrements électroniques bruts à la stratégie élaborée par la direction de l’entreprise. Cependant, loin d’être un solitaire, le scientifique reçoit beaucoup d’aide. L’informatique facilite l’accès aux données pertinentes (sans essayer de prétraiter les données). Les opérations documentent les processus en place, les contraintes opérationnelles et les différents frais généraux. Le marketing clarifie les coûts d’opportunité qui ne peuvent pas être lus dans les livres de comptabilité, par exemple les coûts de rupture de stock[^stock-out]. La direction cristallise la vision, en précisant ce que le scientifique devrait optimiser en premier lieu, etc.

En fin de compte, les décisions de la supply chain⁶ ne sont pas le produit d’un “système” où la responsabilité est diluée entre de nombreuses personnes, souvent des dizaines. Ces décisions, toutes sans exception, sont le produit des recettes numériques mises en œuvre par le Supply Chain Scientist, une seule personne, qui assume la responsabilité de leurs performances par rapport à l’entreprise dans son ensemble. Cette personne est faillible, mais elle reçoit beaucoup d’aide, y compris des collègues prêts à prendre le relais si nécessaire. À mon avis, c’est la seule façon de commencer à optimiser une supply chain, même si un comité de taille importante finira invariablement par submerger tous les observateurs sous des KPI, des graphiques et des rapports pour tenter de prouver le contraire.