Le Supply Chain Scientist - Cours 7.3

00:00 Introduction
02:52 Contexte et avertissement
07:39 Rationalisme naïf
13:14 L’histoire jusqu’à présent
16:37 Scientifiques, nous avons besoin de vous !
18:25 Humain + Machine (le problème 1/4)
23:16 La configuration (le problème 2/4)
26:44 La maintenance (le problème 3/4)
30:02 Le retard informatique (le problème 4/4)
32:56 La mission (le travail du scientifique 1/6)
35:58 Terminologie (le travail du scientifique 2/6)
37:54 Livrables (le travail du scientifique 3/6)
41:11 La portée (le travail du scientifique 4/6)
44:59 Routine quotidienne (le travail du scientifique 5/6)
46:58 Propriété (le travail du scientifique 6/6)
49:25 Un poste dans la supply chain (RH 1/6)
51:13 Recruter un scientifique (RH 2/6)
53:58 Former le scientifique (RH 3/6)
55:43 Évaluer le scientifique (RH 4/6)
57:24 Fidéliser le scientifique (RH 5/6)
59:37 D’un scientifique à l’autre (RH 6/6)
01:01:17 Sur l’informatique (dynamique de l’entreprise 1/3)
01:03:50 Sur la finance (dynamique de l’entreprise 2/3)
01:05:42 Sur le leadership (dynamique de l’entreprise 3/3)
01:09:18 Planification à l’ancienne (modernisation 1/5)
01:11:56 Fin de la S&OP (modernisation 2/5)
01:13:31 Business Intelligence à l’ancienne (modernisation 3/5)
01:15:24 Sortie de la Data Science (modernisation 4/5)
01:17:28 Un nouveau contrat pour l’informatique (modernisation 5/5)
01:19:28 Conclusion
01:22:05 7.3 Le Supply Chain Scientist - Des questions ?

Description

Au cœur d’une initiative de Supply Chain Quantitative, il y a le Supply Chain Scientist (SCS) qui exécute la préparation des données, la modélisation économique et le reporting des KPI. L’automatisation intelligente des décisions de la supply chain est le produit final du travail réalisé par le SCS. Le SCS prend en charge les décisions générées. Le SCS offre une intelligence humaine amplifiée par la puissance de traitement des machines.

Transcription complète

Bienvenue dans cette série de conférences sur la supply chain. Je suis Joannes Vermorel et aujourd’hui je vais présenter le supply chain scientist du point de vue de la supply chain quantifiée. Le supply chain scientist est la personne, ou éventuellement le petit groupe de personnes, chargé de diriger l’initiative de la supply chain. Cette personne supervise la création et la maintenance des recettes numériques qui génèrent les décisions d’intérêt. Cette personne est également responsable de fournir toutes les preuves nécessaires au reste de l’entreprise pour prouver que les décisions générées sont solides.

La devise de la supply chain quantifiée est de tirer le meilleur parti de ce que le matériel moderne et les logiciels modernes ont à offrir aux supply chains. Cependant, la saveur incarnée de cette perspective est naïve. L’intelligence humaine est toujours un pilier de l’ensemble de l’entreprise et, pour diverses raisons, ne peut pas encore être parfaitement intégrée en ce qui concerne la supply chain. L’objectif de cette conférence est de comprendre pourquoi et comment le rôle du supply chain scientist est devenu, au cours de la dernière décennie, une solution éprouvée pour tirer le meilleur parti des logiciels modernes à des fins de supply chain.

Pour atteindre cet objectif, il faut d’abord comprendre les grands obstacles auxquels les logiciels modernes sont encore confrontés lorsqu’ils tentent d’automatiser les décisions de la supply chain. Sur la base de cette nouvelle compréhension, nous présenterons le rôle du supply chain scientist, qui est, en tous points, une réponse à ces obstacles. Enfin, nous verrons comment ce rôle façonne, de manière petite et grande, l’entreprise dans son ensemble. En effet, le supply chain scientist ne peut pas fonctionner en silo au sein de l’entreprise. Tout comme le scientifique doit coopérer avec le reste de l’entreprise pour accomplir quelque chose, le reste de l’entreprise doit également coopérer avec le scientifique pour que cela se produise.

Avant d’aller plus loin, je tiens à réitérer une mise en garde que j’ai faite lors de la toute première conférence de cette série. La présente conférence est presque entièrement basée sur une expérience unique d’une décennie menée chez Lokad, un fournisseur de logiciels d’entreprise spécialisé dans l’optimisation de la supply chain. Toutes ces conférences ont été façonnées par le parcours de Lokad, mais en ce qui concerne le rôle du supply chain scientist, le lien est encore plus fort. Dans une large mesure, le parcours de Lokad lui-même peut être lu à travers le prisme de notre découverte progressive du rôle du supply chain scientist.

Ce processus est encore en cours. Par exemple, il y a seulement cinq ans, nous avons abandonné la perspective classique du data scientist avec l’introduction de paradigmes de programmation pour l’apprentissage et l’optimisation. Lokad emploie actuellement trois douzaines de supply chain scientists. Nos scientifiques les plus compétents, grâce à leurs antécédents, se sont vu confier des décisions à grande échelle. Certains d’entre eux sont individuellement responsables de paramètres d’une valeur supérieure à un demi-milliard de dollars en stocks. Cette confiance s’étend à une grande variété de décisions, telles que les commandes d’achat, les commandes de production, les commandes d’allocation de stocks ou la tarification.

Comme vous pouvez l’imaginer, cette confiance a dû être méritée. En effet, très peu d’entreprises feraient confiance à leurs propres employés avec de tels pouvoirs, encore moins à un fournisseur tiers comme Lokad. Gagner ce degré de confiance est un processus qui prend généralement des années, indépendamment des moyens technologiques. Pourtant, une décennie plus tard, Lokad connaît une croissance plus rapide que jamais auparavant, et une part importante de cette croissance provient de nos clients existants qui élargissent le champ des décisions confiées à Lokad.

Cela me ramène à mon point de départ : cette conférence est presque certainement entachée de tous types de biais. J’ai essayé d’élargir cette perspective grâce à des expériences similaires en dehors de Lokad ; cependant, il n’y a pas grand-chose à raconter à ce sujet. À ma connaissance, il existe quelques géants de la technologie, plus précisément quelques géants du e-commerce, qui parviennent à automatiser les décisions de manière comparable à ce que Lokad réalise.

Cependant, ces géants allouent généralement deux ordres de grandeur de ressources de plus que ce que les grandes entreprises ordinaires peuvent se permettre, avec des effectifs en ingénierie de l’ordre de centaines. La faisabilité de ces approches me semble encore incertaine, car elles ne fonctionnent peut-être que dans des entreprises extrêmement rentables. Sinon, les coûts de la masse salariale pourraient bien dépasser les avantages apportés par une meilleure exécution de la supply chain.

De plus, attirer des talents en ingénierie à une telle échelle devient un défi en soi. Il est déjà difficile d’embaucher un ingénieur logiciel talentueux ; en embaucher 100 nécessite une marque employeur assez remarquable. Heureusement, la perspective présentée aujourd’hui est beaucoup plus légère. De nombreuses initiatives de la supply chain menées par Lokad sont réalisées avec un seul supply chain scientist, un deuxième agissant en tant que remplaçant. Au-delà des économies de masse salariale, notre expérience indique qu’il existe des avantages substantiels pour la supply chain associés à un effectif réduit.

La perspective dominante de la supply chain adopte une approche mathématique appliquée. Les méthodes et les algorithmes sont présentés de manière à exclure complètement l’opérateur humain. Par exemple, la formule du stock de sécurité et la formule de la quantité économique de commande sont présentées comme une question purement mathématique appliquée. L’identité de la personne utilisant ces formules, ses compétences ou son expérience, par exemple, est non seulement sans importance, mais n’est même pas mentionnée dans la présentation.

Plus généralement, cette approche est largement adoptée dans les manuels de la supply chain et donc dans les logiciels de la supply chain. Il semble certainement plus objectif d’exclure la composante humaine de l’équation. Après tout, la validité d’un théorème ne dépend pas de la personne qui ennonce la preuve, et de même, les performances d’un algorithme ne dépendent pas de la personne qui appuie sur la dernière touche de sa mise en œuvre. Cette approche vise à atteindre une forme supérieure de rationalité.

Cependant, je soutiens que cette approche est naïve et représente une autre forme de rationalisme naïf. Ma proposition est subtile mais importante : je ne soutiens pas que le résultat d’une recette numérique dépend de la personne qui l’exécute, ni que le caractère d’un mathématicien ait quoi que ce soit à voir avec la validité de ses théorèmes. Au contraire, ma proposition est que la posture intellectuelle associée à cette perspective est inappropriée pour aborder les supply chains.

Une recette de supply chain du monde réel est un travail complexe et l’auteur de la recette n’est pas aussi neutre ou insignifiant qu’il n’y paraît. Illustrons ce point en considérant deux recettes numériques identiques qui ne diffèrent que par le nom de leurs variables. Au niveau numérique, les deux recettes produisent des résultats identiques. Cependant, la première recette a des noms de variables bien choisis et significatifs, tandis que la deuxième recette a des noms cryptiques et incohérents. En production, la deuxième recette (celle avec des noms de variables cryptiques et incohérents) est un désastre en attente de se produire. Chaque évolution ou correction de bogue appliquée à la deuxième recette coûtera des efforts beaucoup plus importants par rapport à la même tâche accomplie sur la première recette. En fait, les problèmes de nommage des variables sont si fréquents et graves que de nombreux manuels d’ingénierie logicielle consacrent un chapitre entier à cette seule question.

Ni les mathématiques, ni l’algorithmique, ni les statistiques ne disent quoi que ce soit sur l’adéquation des noms de variables. L’adéquation de ces noms réside évidemment dans l’œil de celui qui les regarde. Bien que nous ayons deux recettes numériquement identiques, l’une est considérée comme nettement supérieure à l’autre pour des raisons apparemment subjectives. La proposition que je défends ici est qu’il y a une rationalité à trouver dans ces préoccupations subjectives également. Ces préoccupations ne doivent pas être rejetées en bloc parce qu’elles dépendent d’un sujet ou d’une personne. Au contraire, l’expérience de Lokad indique que, avec les mêmes outils logiciels, instruments mathématiques et bibliothèque d’algorithmes, certains supply chain scientists obtiennent des résultats supérieurs. En fait, l’identité du scientifique responsable est l’un des meilleurs prédicteurs de la réussite de l’initiative.

En supposant que le talent inné ne peut pas expliquer entièrement les écarts de réussite en supply chain, nous devrions embrasser les éléments qui contribuent aux initiatives réussies, qu’ils soient objectifs ou subjectifs. C’est pourquoi, chez Lokad, nous avons beaucoup travaillé au cours des dernières décennies pour affiner notre approche du rôle du supply chain scientist, qui est précisément le sujet de cette conférence. Les nuances associées à la position d’un supply chain scientist ne doivent pas être sous-estimées. L’ampleur des améliorations apportées par ces éléments subjectifs est comparable à nos réalisations technologiques les plus remarquables.

Cette série de conférences est destinée à former les supply chain scientists de Lokad. Cependant, j’espère également que ces conférences pourront intéresser un public plus large de praticiens de la supply chain ou même d’étudiants en supply chain. Il est préférable de regarder ces conférences dans l’ordre pour une compréhension approfondie de ce à quoi les supply chain scientists sont confrontés.

Dans le premier chapitre, nous avons vu pourquoi les supply chains doivent devenir programmatiques et pourquoi il est très souhaitable de pouvoir mettre une recette numérique en production. La complexité croissante des supply chains rend l’automatisation plus pressante que jamais. De plus, il y a une impératif financier à rendre les pratiques de la supply chain capitalistes.

Le deuxième chapitre est consacré aux méthodologies. Les supply chains sont des systèmes concurrentiels, et cette combinaison défait les méthodologies naïves. Le rôle des scientifiques peut être considéré comme un antidote à la méthodologie naïve des mathématiques appliquées.

Le troisième chapitre passe en revue les problèmes auxquels sont confrontés les personnels de la supply chain. Ce chapitre tente de caractériser les classes de défis de prise de décision qui doivent être abordés. Il montre que des perspectives simplistes comme choisir la bonne quantité de stock pour chaque SKU ne correspondent pas aux situations réelles ; il y a invariablement une profondeur sous la forme de prise de décision.

Le quatrième chapitre passe en revue les éléments nécessaires pour appréhender une pratique moderne de la supply chain, où les éléments logiciels sont omniprésents. Ces éléments sont fondamentaux pour comprendre le contexte plus large dans lequel la supply chain numérique opère.

Les chapitres 5 et 6 sont consacrés à la modélisation prédictive et à la prise de décision, respectivement. Ces chapitres couvrent les parties “intelligentes” de la recette numérique, mettant en avant l’apprentissage automatique et l’optimisation mathématique. Notamment, ces chapitres rassemblent des techniques qui se sont révélées efficaces entre les mains des supply chain scientists.

Enfin, le septième et dernier chapitre est consacré à l’exécution d’une initiative de supply chain quantitative. Nous avons vu ce qu’il faut pour lancer une initiative en posant les bases appropriées. Nous avons vu comment franchir la ligne d’arrivée et mettre la recette numérique en production.

Aujourd’hui, nous verrons quel genre de personne il faut pour que tout cela se réalise.

Le rôle du scientifique vise à résoudre les problèmes que l’on trouve dans la littérature académique. Nous passerons en revue le travail du supply chain scientist, y compris sa mission, son champ d’action, sa routine quotidienne et ses domaines d’intérêt. Cette description de poste reflète la pratique actuelle chez Lokad.

La création d’un nouveau poste au sein de l’entreprise soulève une série de préoccupations, il est donc nécessaire d’embaucher, de former, d’évaluer et de fidéliser des scientifiques. Nous aborderons ces préoccupations d’un point de vue des ressources humaines. Le scientifique est censé collaborer avec d’autres départements de l’entreprise au-delà de son département de supply chain. Nous verrons quelles sortes d’interactions sont attendues entre les scientifiques et les départements informatique, finance, voire la direction de l’entreprise.

Le scientifique représente également une opportunité pour l’entreprise de moderniser son personnel et ses opérations. Cette modernisation est la partie la plus difficile du parcours, car il est bien plus difficile de supprimer un poste devenu obsolète que d’en introduire un nouveau.

Le défi que nous nous sommes fixé dans cette série de conférences est l’amélioration systématique des supply chains grâce à des méthodes quantitatives. L’idée générale de cette approche est de tirer le meilleur parti de ce que l’informatique moderne et les logiciels ont à offrir aux supply chains. Cependant, nous devons clarifier ce qui relève encore du domaine de l’intelligence humaine et ce qui peut être automatisé avec succès.

La frontière entre l’intelligence humaine et l’automatisation dépend encore beaucoup de la technologie. On s’attend à ce que la technologie supérieure mécanise un spectre plus large de décisions et produise de meilleurs résultats. Du point de vue de la supply chain, cela signifie prendre des décisions plus diverses, telles que des décisions de tarification en plus des décisions de réapprovisionnement des stocks, et produire de meilleures décisions qui améliorent encore la rentabilité de l’entreprise.

Le rôle du scientifique incarne cette frontière entre l’intelligence humaine et l’automatisation. Bien que les annonces routinières sur l’intelligence artificielle puissent donner l’impression que l’intelligence humaine est sur le point d’être automatisée, ma compréhension de l’état de l’art indique que l’intelligence artificielle générale reste lointaine. En effet, les idées humaines sont encore très nécessaires lorsqu’il s’agit de concevoir des méthodes quantitatives pertinentes pour la supply chain. Établir même une stratégie de supply chain de base relève largement de ce que les logiciels peuvent offrir.

Plus généralement, nous n’avons pas encore de technologies capables de résoudre les problèmes mal formulés ou non identifiés, qui sont monnaie courante dans la supply chain. Cependant, une fois qu’un problème étroit et bien spécifié a été isolé, il est concevable d’avoir un processus automatisé qui apprend sa résolution et même qui automatise cette résolution avec peu ou pas de supervision humaine.

Cette perspective n’est pas nouvelle. Par exemple, les filtres anti-spam sont devenus largement adoptés. Ces filtres accomplissent une tâche difficile : trier le pertinent de l’irrelevant. Cependant, la conception de la prochaine génération de filtres est encore largement laissée aux humains, même si de nouvelles données peuvent être utilisées pour mettre à jour ces filtres. En effet, les spammeurs qui veulent contourner les filtres anti-spam continuent d’inventer de nouvelles méthodes qui contournent les mises à jour basées uniquement sur les données de ces filtres.

Ainsi, bien que des idées humaines soient encore nécessaires pour concevoir l’automatisation, il n’est pas clair pourquoi un éditeur de logiciels comme Lokad, par exemple, ne pourrait pas concevoir un grand moteur de supply chain qui résoudrait tous ces défis. Certes, l’économie du logiciel est très favorable à la conception d’un tel moteur de supply chain. Même si l’investissement initial est élevé, car le logiciel peut être reproduit à un coût négligeable, l’éditeur fera fortune en droits de licence en revendant ce grand moteur à un grand nombre d’entreprises.

Lokad, en 2008, s’est lancé dans un tel projet de création d’un grand moteur qui aurait pu être déployé en tant que produit logiciel emballé. Plus précisément, Lokad se concentrait à l’époque sur un grand moteur de prévision plutôt que sur un grand moteur de supply chain. Pourtant, malgré ces ambitions comparativement plus modestes, étant donné que la prévision n’est qu’une petite partie du défi global de la supply chain, Lokad a échoué dans la création d’un tel grand moteur de prévision. La perspective de la supply chain quantitative présentée dans cette série de conférences est née des cendres de cette ambition de grand moteur.

En ce qui concerne la supply chain, il s’est avéré qu’il y a trois grands goulots d’étranglement à résoudre. Nous verrons pourquoi ce grand moteur était condamné dès le premier jour et pourquoi nous sommes encore très probablement à des décennies d’un tel exploit d’ingénierie.

Le paysage applicatif de la supply chain typique est une jungle qui a poussé de manière désordonnée au cours des deux ou trois dernières décennies. Ce paysage n’est pas un jardin à la française avec des lignes géométriques soignées et des buis bien taillés ; c’est une jungle, à la fois vibrante mais aussi pleine d’épines et d’une faune hostile. Plus sérieusement, les supply chains sont le produit de leur histoire numérique. Il peut y avoir plusieurs ERP semi-redondants, des personnalisations internes à moitié finalisées, des intégrations par lots, notamment avec des systèmes provenant d’entreprises acquises, et des plates-formes logicielles superposées qui se disputent les mêmes domaines fonctionnels.

L’idée qu’un grand moteur puisse simplement être branché est illusoire, compte tenu de l’état actuel des technologies logicielles. Réunir tous les systèmes qui opèrent la supply chain est une entreprise considérable entièrement dépendante des efforts d’ingénierie humaine.

L’analyse des dépenses collectives indique que la manipulation des données représente au moins les trois quarts de l’effort technique global associé à une initiative de supply chain. En revanche, la création des aspects intelligents de la recette numérique, tels que la prévision et l’optimisation, ne représente pas plus de quelques pour cent des efforts globaux. Ainsi, la disponibilité d’un moteur grandiose emballé est largement sans conséquence en termes de coûts ou de délais. Il faudrait une intelligence de niveau humain intégrée à ce moteur pour qu’il s’intègre automatiquement dans le paysage informatique souvent désordonné que l’on trouve couramment dans les supply chains.

De plus, tout grand moteur rend cette entreprise encore plus difficile du fait de son existence. Au lieu de traiter un système complexe, le paysage applicatif, nous avons maintenant deux systèmes complexes : le paysage applicatif et le grand moteur. La complexité de l’intégration de ces deux systèmes n’est pas la somme de leurs complexités respectives, mais plutôt le produit de ces complexités.

L’impact de cette complexité sur le coût de l’ingénierie est très non linéaire, un point qui a déjà été abordé dans le premier chapitre de cette série de conférences. Le premier grand goulot d’étranglement pour l’optimisation de la supply chain est la configuration de la recette numérique, qui nécessite un effort d’ingénierie dédié. Ce goulot d’étranglement élimine largement les avantages qui pourraient être associés à tout type de grand moteur emballé de supply chain.

Bien que la configuration nécessite un effort d’ingénierie substantiel, cela pourrait être un investissement ponctuel, similaire à l’achat d’un billet d’entrée. Malheureusement, les supply chains sont des entités vivantes en constante évolution. Le jour où une supply chain cesse de changer est le jour où l’entreprise fait faillite. Les changements sont à la fois internes et externes.

En interne, le paysage applicatif change constamment. Les entreprises ne peuvent pas figer leur paysage applicatif même si elles le voulaient, car de nombreuses mises à jour sont imposées par les fournisseurs de logiciels d’entreprise. Ignorer ces obligations libérerait les fournisseurs de leurs obligations contractuelles, ce qui n’est pas un résultat acceptable. Au-delà des mises à jour purement techniques, toute supply chain d’une certaine taille est amenée à intégrer et à éliminer des éléments logiciels à mesure que l’entreprise elle-même évolue.

À l’extérieur, les marchés changent en permanence également. De nouveaux concurrents, canaux de vente et fournisseurs potentiels émergent tout le temps, tandis que certains disparaissent. Les réglementations changent constamment. Bien que les algorithmes puissent automatiquement capturer certains des changements simples, comme la croissance de la demande pour une catégorie de produits, nous n’avons pas encore d’algorithmes pour faire face aux changements de marché en nature, plutôt qu’en magnitude. Les problèmes mêmes auxquels l’optimisation de la supply chain tente de répondre changent également.

Si le logiciel chargé d’optimiser la supply chain ne parvient pas à gérer ces changements, les employés se rabattent sur des feuilles de calcul. Les feuilles de calcul peuvent être rudimentaires, mais au moins les employés peuvent les adapter à la tâche à accomplir. De manière anecdotique, la grande majorité des supply chains fonctionnent encore avec des feuilles de calcul au niveau de la prise de décision, et non au niveau transactionnel. C’est la preuve vivante que la maintenance logicielle a échoué.

Depuis les années 1980, les fournisseurs de logiciels d’entreprise proposent des produits logiciels pour automatiser les décisions de la supply chain. La plupart des entreprises qui exploitent de grandes supply chains ont déjà déployé plusieurs de ces solutions au cours des dernières décennies. Cependant, les employés finissent invariablement par revenir à leurs feuilles de calcul, prouvant que même si la configuration était initialement considérée comme un succès, quelque chose s’est mal passé avec la maintenance.

La maintenance est le deuxième grand goulot d’étranglement de l’optimisation de la supply chain. La recette nécessite une maintenance active, même si l’exécution peut être largement laissée sans surveillance.

À ce stade, nous avons montré que l’optimisation de la supply chain nécessite non seulement des ressources initiales d’ingénierie logicielle, mais aussi des ressources d’ingénierie logicielle continues. Comme cela a déjà été souligné dans cette série de conférences, rien de moins que des capacités programmatiques ne peut aborder de manière réaliste la diversité des problèmes auxquels sont confrontées les supply chains du monde réel. Les feuilles de calcul comptent comme des outils programmables, et leur expressivité, par opposition aux boutons et aux menus, est ce qui les rend si attrayantes pour les praticiens de la supply chain.

Comme les ressources d’ingénierie logicielle doivent être sécurisées dans la plupart des entreprises, il est naturel de faire appel au service informatique. Malheureusement, la supply chain n’est pas le seul service à penser de cette façon. Chaque service, y compris les ventes, le marketing et la finance, finit par réaliser que l’automatisation de leurs processus de prise de décision respectifs nécessite des ressources d’ingénierie logicielle. De plus, ils doivent également gérer la couche transactionnelle et toute son infrastructure sous-jacente.

En conséquence, la plupart des entreprises qui exploitent de grandes supply chains ont aujourd’hui leurs services informatiques submergés par des années de retard. Ainsi, attendre du service informatique qu’il alloue davantage de ressources continues à la supply chain ne fait qu’aggraver le retard. L’option d’allouer plus de ressources au service informatique a déjà été explorée et n’est généralement plus viable. Ces entreprises sont déjà confrontées à de graves déséconomies d’échelle en ce qui concerne le service informatique. Le retard informatique représente le troisième grand goulot d’étranglement pour l’optimisation de la supply chain.

Des ressources d’ingénierie continues sont nécessaires, mais la majeure partie de ces ressources ne peut pas provenir du service informatique. Un certain soutien du service informatique peut être envisagé, mais il doit être discret.

Ces trois grands goulets d’étranglement définissent pourquoi un rôle spécifique est nécessaire : le supply chain scientist est le nom que nous donnons à ces ressources d’ingénierie logicielle continues nécessaires pour automatiser les décisions banales de la supply chain et les processus de prise de décision exigeants.

Poursuivons avec une définition plus précise basée sur la pratique de Lokad. La mission du supply chain scientist est de concevoir des recettes numériques qui génèrent les décisions banales nécessaires au fonctionnement quotidien de la supply chain. Le travail du scientifique commence par les extraits de base de données collectés dans tout le paysage applicatif. Le scientifique est censé coder la recette qui analyse ces extraits de base de données et mettre ces recettes en production. Le scientifique est entièrement responsable de la qualité des décisions générées par la recette. Les décisions ne sont pas générées par une sorte de système ambiant ; elles sont l’expression directe des idées du scientifique transmises par une recette.

Cet aspect unique est un écart critique par rapport à ce qui est généralement compris comme le rôle d’un data scientist. Cependant, la mission ne s’arrête pas là. On attend du supply chain scientist qu’il soit capable de présenter des preuves étayant chaque décision générée par la recette. Ce n’est pas un système opaque qui est responsable des décisions ; c’est la personne, le scientifique. Le scientifique devrait être en mesure de rencontrer le responsable de la supply chain ou même le PDG et de fournir une justification convaincante pour toute décision générée par la recette.

Si le scientifique n’est pas en mesure de potentiellement causer beaucoup de dommages à l’entreprise, alors quelque chose ne va pas. Je ne préconise pas d’accorder à quiconque, et certainement pas au scientifique, de grands pouvoirs sans supervision ni responsabilité. Je souligne simplement l’évidence : si vous n’avez pas le pouvoir d’avoir un impact négatif sur votre entreprise, peu importe votre mauvaise performance, vous n’avez pas non plus le pouvoir d’avoir un impact positif sur votre entreprise, peu importe votre bonne performance.

Les grandes entreprises sont malheureusement réticentes au risque par nature. Ainsi, il est très tentant de remplacer le scientifique par un analyste. Contrairement au scientifique chargé des décisions elles-mêmes, l’analyste est seulement responsable d’apporter un éclairage ici et là. L’analyste est principalement inoffensif et ne peut pas faire grand-chose à part gaspiller son propre temps et quelques ressources informatiques. Cependant, être inoffensif n’est pas ce que le rôle du supply chain scientist est censé être.

Discutons du terme “scientifique de la supply chain” pendant une seconde. Cette terminologie est malheureusement imparfaite. J’ai initialement inventé cette expression comme une variation de “data scientist” il y a une dizaine d’années, avec l’idée de positionner ce rôle comme une variation du data scientist mais avec une spécialisation forte en supply chain. L’insight sur la spécialisation était correct, mais celui sur la science des données ne l’était pas. Je reviendrai sur ce point à la fin de la conférence.

Un “ingénieur de la supply chain” aurait peut-être été une meilleure formulation, car cela met l’accent sur le désir de maîtriser et de contrôler le domaine, par opposition à une simple compréhension. Cependant, les ingénieurs, tels qu’ils sont communément compris, ne sont pas censés être à l’avant-garde de l’action. Le terme approprié aurait probablement été “supply chain quant”, comme dans les praticiens de la supply chain quantitative.

En finance, un quant ou trader quantitatif est un spécialiste qui utilise des algorithmes et des méthodes quantitatives pour prendre des décisions de trading. Les quants peuvent rendre une banque très rentable ou, au contraire, très non rentable. L’intelligence humaine est amplifiée par les machines, aussi bien le bon que le mauvais.

Dans tous les cas, il reviendra à la communauté dans son ensemble de décider de la terminologie appropriée : analyste, scientifique, ingénieur, opérationnel ou quant. Pour des raisons de cohérence, je continuerai à utiliser le terme “scientifique” pour le reste de cette conférence.

Le principal livrable pour le scientifique est un logiciel, plus précisément, la recette numérique responsable de la génération des décisions de la supply chain quotidienne. Cette recette est une collection de tous les scripts impliqués, depuis les premières étapes de préparation des données jusqu’aux dernières étapes de validation des décisions par l’entreprise elle-même. Cette recette doit être de qualité de production, c’est-à-dire qu’elle peut s’exécuter sans surveillance et que les décisions qu’elle génère sont par défaut fiables. Naturellement, cette confiance doit être méritée au préalable, et une supervision continue doit garantir que ce niveau de confiance reste justifié dans le temps.

Livrer une recette de qualité de production est fondamental pour transformer la pratique de la supply chain en un actif productif. Cet angle a déjà été abordé dans la conférence précédente sur la livraison orientée produit.

Au-delà de cette recette, il existe de nombreux livrables secondaires. Certains d’entre eux sont également des logiciels, même s’ils ne contribuent pas directement à la génération des décisions. Cela inclut, par exemple, tous les instruments que le scientifique doit introduire pour concevoir et maintenir la recette elle-même. D’autres éléments sont destinés aux collègues au sein de l’entreprise, y compris toute la documentation de l’initiative elle-même et de la recette.

Le code source de la recette répond au “comment” - comment est-ce fait ? Cependant, le code source ne répond pas au “pourquoi” - pourquoi est-ce fait ? Le “pourquoi” doit être documenté. Fréquemment, la justesse de la recette repose sur une compréhension subtile de l’intention. La documentation livrée doit faciliter autant que possible la transition en douceur d’un scientifique à l’autre, même si l’ancien scientifique n’est pas disponible pour soutenir le processus.

Chez Lokad, notre procédure standard consiste à produire et à maintenir un grand livre de l’initiative, appelé Manuel de Procédure Conjointe (MPC). Ce manuel n’est pas seulement un manuel d’utilisation complet de la recette, mais aussi une collection de toutes les idées stratégiques qui sous-tendent les choix de modélisation faits par les scientifiques.

Au niveau technique, le travail du scientifique commence à partir de l’extraction des données brutes et se termine par la génération des décisions finales de la chaîne d’approvisionnement. Le scientifique doit travailler à partir des données brutes extraites des systèmes informatiques existants. Comme chaque système informatique a sa propre pile technologique, l’extraction elle-même est généralement confiée à des spécialistes en informatique. Il n’est pas raisonnable de s’attendre à ce que le scientifique maîtrise une demi-douzaine de dialectes SQL ou une demi-douzaine de technologies API uniquement pour accéder aux données commerciales. D’autre part, on ne doit rien attendre des spécialistes en informatique, sauf des extraits de données brutes, ni de transformation de données ni de préparation de données. Les données extraites mises à la disposition du scientifique doivent être aussi proches que possible des données telles qu’elles se présentent dans les systèmes commerciaux.

À l’autre extrémité du pipeline, la recette élaborée par le scientifique doit générer les décisions finales. Les éléments associés au déploiement des décisions ne relèvent pas du domaine du scientifique. Ils sont importants mais sont également largement indépendants de la décision elle-même. Par exemple, lorsqu’il s’agit de bons de commande, l’établissement des quantités finales relève du domaine du scientifique, mais la génération du fichier PDF - le document de commande attendu par le fournisseur - ne relève pas de son domaine. Malgré ces limites, le champ d’application est assez large. Par conséquent, il est tentant mais erroné de fragmenter le champ d’application en une série de sous-champs. Dans les grandes entreprises, cette tentation devient très forte et doit être résistée. Fragmenter le champ d’application est le moyen le plus sûr de créer de nombreux problèmes.

En amont, si quelqu’un essaie d’aider les scientifiques en manipulant les données d’entrée, cette tentative se termine invariablement par des problèmes de “garbage in, garbage out”. Les systèmes commerciaux sont suffisamment complexes ; transformer les données au préalable ne fait qu’ajouter une couche accidentelle de complexité supplémentaire. En cours de route, si quelqu’un essaie d’aider les scientifiques en prenant en charge une partie difficile de la recette, comme la prévision, alors les scientifiques se retrouvent face à une boîte noire au milieu de leur propre recette. Une telle boîte noire compromet les efforts de transparence des scientifiques. Et en aval, si quelqu’un essaie d’aider le scientifique en réoptimisant encore davantage les décisions, cette tentative crée inévitablement de la confusion, et les logiques d’optimisation à deux niveaux peuvent même fonctionner à contre-courant.

Cela n’implique pas que le scientifique doive travailler seul. Une équipe de scientifiques peut être formée, mais le champ d’application reste le même. Si une équipe est formée, il doit y avoir une propriété collective de la recette. Cela implique, par exemple, que si un défaut de la recette est identifié, n’importe quel membre de l’équipe devrait être en mesure d’intervenir et de le corriger.

L’expérience de Lokad indique qu’un bon équilibre pour un Supply Chain Scientist consiste à consacrer 40% de son temps à la programmation, 30% à dialoguer avec le reste de l’entreprise et 30% à rédiger des documents, des supports de formation et à échanger avec d’autres praticiens ou scientifiques de la supply chain.

La programmation est évidemment nécessaire pour mettre en œuvre la recette elle-même. Cependant, une fois que la recette est en production, la plupart des efforts de programmation sont dirigés non pas vers la recette elle-même, mais plutôt vers son instrumentation. Pour améliorer la recette, le scientifique a besoin de nouvelles informations, et à son tour, ces informations nécessitent une instrumentation dédiée qui doit être mise en œuvre.

Dialoguer avec le reste de l’entreprise est fondamental. Contrairement à la S&OP, l’objectif de ces discussions n’est pas d’orienter les prévisions à la hausse ou à la baisse. Il s’agit de s’assurer que les choix de modélisation intégrés dans la recette reflètent toujours fidèlement la stratégie de l’entreprise et toutes ses contraintes opérationnelles.

Enfin, nourrir les connaissances institutionnelles que l’entreprise possède sur l’optimisation de la supply chain, que ce soit par la formation directe des scientifiques eux-mêmes ou par la production de documents destinés aux collègues, est essentiel. La performance de la recette est, dans une large mesure, le reflet de la compétence du scientifique. Avoir accès à des pairs et rechercher des commentaires est sans surprise l’un des moyens les plus efficaces d’améliorer la compétence des scientifiques.

La plus grande différence entre un Supply Chain Scientist, tel que conçu par Lokad, et un data scientist classique réside dans l’engagement personnel envers les résultats concrets. Cela peut sembler être une petite chose insignifiante, mais l’expérience prouve le contraire. Il y a une décennie, Lokad a appris à ses dépens que l’engagement envers la livraison d’une recette de qualité de production n’était pas acquis. Au contraire, l’attitude par défaut des personnes formées en tant que data scientists semble être de considérer la production comme une préoccupation secondaire. Le data scientist classique s’attend à gérer les aspects intelligents, tels que l’apprentissage automatique et l’optimisation mathématique, tandis que traiter avec toutes les trivialités aléatoires qui accompagnent la supply chain du monde réel est trop souvent perçu comme en dessous d’eux.

Pourtant, l’engagement envers une recette de qualité de production implique de traiter les choses les plus aléatoires. Par exemple, en juillet 2021, de nombreux pays européens ont subi des inondations catastrophiques. Un client de Lokad basé en Allemagne a vu la moitié de ses entrepôts inondés. Le Supply Chain Scientist responsable de ce compte a dû réinventer la recette presque du jour au lendemain pour tirer le meilleur parti de cette situation gravement dégradée. La solution n’était pas une sorte de grand algorithme d’apprentissage automatique, mais plutôt un ensemble d’heuristiques décodées. À l’inverse, si le Supply Chain Scientist ne prend pas la décision, cette personne ne pourra pas élaborer une recette de qualité de production. C’est une question de psychologie. Livrer une recette de qualité de production nécessite un immense effort intellectuel, et les enjeux doivent être réels pour atteindre le niveau de concentration nécessaire de la part d’un employé.

Après avoir clarifié le travail d’un Supply Chain Scientist, discutons de son fonctionnement du point de vue des ressources humaines. Tout d’abord, parmi les préoccupations de l’entreprise, le scientifique doit rendre compte au responsable de la supply chain ou du moins à quelqu’un qui est qualifié en tant que cadre supérieur de la supply chain. Peu importe que le scientifique soit interne ou externe, comme c’est souvent le cas chez Lokad. L’essentiel est que le scientifique soit placé sous la supervision directe de quelqu’un qui détient le pouvoir d’un cadre exécutif de la supply chain.

Une erreur courante est de faire en sorte que le scientifique rende compte au responsable des technologies de l’information ou au responsable de l’analyse des données. Comme l’élaboration d’une recette est un exercice de codage, les responsables de la supply chain peuvent ne pas se sentir entièrement à l’aise pour superviser une telle entreprise. Cependant, cela est incorrect. Le scientifique a besoin d’une supervision de la part de quelqu’un qui peut approuver si les décisions générées sont acceptables ou non, ou qui peut au moins faire en sorte que cette approbation se produise. Placer le scientifique n’importe où, sauf sous la supervision directe de la direction de la supply chain, est une recette pour opérer sans fin à travers des prototypes qui ne parviennent jamais à la production. Dans cette situation, le rôle revient inévitablement à celui d’un analyste, et les ambitions initiales de l’initiative de la supply chain quantitative sont abandonnées.

Les meilleurs scientifiques de la supply chain génèrent des rendements disproportionnés par rapport à ceux de la moyenne. C’est l’expérience de Lokad et cela reflète le schéma identifié il y a des décennies dans l’industrie du logiciel. Les entreprises de logiciels ont depuis longtemps observé que les meilleurs ingénieurs en logiciel ont une productivité d’au moins 10 fois supérieure à celle des ingénieurs moyens, et que les ingénieurs médiocres peuvent même avoir une productivité négative, rendant le logiciel pire pour chaque heure passée sur la base de code.

Dans le cas des scientifiques de la supply chain, une compétence supérieure améliore non seulement la productivité, mais surtout, elle améliore le résultat final performance de la supply chain. Avec les mêmes outils logiciels et instruments mathématiques, deux scientifiques n’obtiennent pas le même résultat. Ainsi, embaucher quelqu’un ayant le potentiel de devenir l’un des meilleurs scientifiques est d’une importance primordiale.

L’expérience de Lokad, basée sur l’embauche de plus de 50 scientifiques, indique que les profils d’ingénierie non spécialisés sont généralement très bons. Bien que contre-intuitif, les personnes ayant une formation formelle en science des données, en statistiques ou en informatique ne sont généralement pas les mieux adaptées aux postes de scientifiques de la supply chain. Ces individus compliquent trop souvent la recette et ne prêtent pas suffisamment attention aux aspects banals mais critiques de la supply chain. La capacité à prêter attention à une multitude de détails et la capacité à persévérer sans fin tout en poursuivant des artefacts numériques marginaux semblent être les qualités principales des meilleurs scientifiques.

De manière anecdotique, chez Lokad, il y a eu de bons résultats avec de jeunes ingénieurs qui ont passé quelques années en tant qu’auditeurs. En plus de la familiarité avec la finance d’entreprise, il semble que les auditeurs talentueux développent une capacité à naviguer à travers un océan de documents d’entreprise, ce qui correspond à la réalité quotidienne d’un scientifique de la supply chain.

Bien que l’embauche garantisse que les recrues ont le bon potentiel, l’étape suivante consiste à s’assurer qu’elles sont correctement formées. La position par défaut de Lokad est qu’ils n’attendent pas des personnes qu’elles connaissent quoi que ce soit sur la supply chain au préalable. Avoir des connaissances en supply chain est un plus, mais l’université reste quelque peu déficiente à cet égard. La plupart des diplômes en supply chain se concentrent sur la gestion et le leadership, mais pour les jeunes diplômés, il est essentiel d’avoir une connaissance fondamentale appropriée des sujets abordés dans les deuxième, troisième ou quatrième chapitres de cette série de conférences. Malheureusement, cela n’est souvent pas le cas, et les parties quantitatives de ces diplômes peuvent être décevantes. Par conséquent, les scientifiques de la supply chain doivent être formés par leur employeur. Cette série de conférences reflète le type de supports de formation utilisés chez Lokad.

Les évaluations de performance des scientifiques de la supply chain sont importantes pour diverses raisons, telles que s’assurer que l’argent de l’entreprise est bien dépensé et déterminer les promotions. Les critères habituels s’appliquent : attitude, diligence, compétence, etc. Cependant, il y a un aspect contre-intuitif : les meilleurs scientifiques obtiennent des résultats qui rendent les défis de la supply chain presque invisibles, avec un minimum de drame.

Former un scientifique pour maintenir les recettes existantes tout en conservant le niveau de performance de la supply chain précédent prend environ six mois, tandis que former un scientifique pour mettre en œuvre une recette de qualité prédictive à partir de zéro prend environ deux ans. La rétention des talents est essentielle, d’autant plus que l’embauche de scientifiques de la supply chain expérimentés n’est pas encore une option.

Dans de nombreux pays, la durée médiane de séjour des ingénieurs de moins de 30 ans dans le domaine des logiciels et des domaines connexes est assez faible. Lokad atteint une durée médiane plus élevée en se concentrant sur le bien-être des employés. Les entreprises ne peuvent pas apporter le bonheur à leurs employés, mais elles peuvent éviter de rendre leurs employés malheureux grâce à des processus insensés. La santé mentale contribue grandement à la rétention des employés.

On ne peut pas s’attendre à ce qu’un scientifique compétent et expérimenté prenne rapidement en charge une recette existante, car la recette reflète la stratégie unique de l’entreprise et les particularités de la supply chain. La transition d’une supply chain à une autre peut prendre environ un mois dans les meilleures conditions. Il n’est pas raisonnable pour une entreprise de taille importante de dépendre d’un seul scientifique ; Lokad veille à ce que deux scientifiques soient compétents pour toutes les recettes utilisées en production à tout moment. La continuité est essentielle, et l’une des façons d’y parvenir est de créer conjointement avec les clients un manuel qui peut faciliter les transitions imprévues entre les scientifiques.

Le rôle du scientifique de la supply chain nécessite un niveau inhabituel de coopération avec plusieurs départements, en particulier l’informatique. L’exécution correcte de la recette dépend du pipeline d’extraction des données, qui relève de la responsabilité de l’informatique.

Il y a une phase relativement intense d’interaction entre l’informatique et le scientifique au début de la première initiative quantitative de la supply chain, qui dure environ deux à trois mois. Ensuite, une fois que le pipeline d’extraction des données est en place, l’interaction devient moins fréquente. Ce dialogue permet au scientifique de rester informé de la feuille de route informatique et de toute mise à niveau ou modification logicielle pouvant avoir un impact sur la supply chain.

Dans la phase initiale d’une initiative quantitative de la supply chain, il y a une interaction relativement intense entre l’informatique et les scientifiques. Pendant les deux ou trois premiers mois, le scientifique doit interagir avec l’informatique plusieurs fois par semaine. Ensuite, une fois que le pipeline d’extraction des données est en place, l’interaction devient beaucoup moins fréquente, environ une fois par mois ou moins. Outre la résolution des problèmes occasionnels dans le pipeline, ce dialogue permet au scientifique de rester informé de la feuille de route informatique. Toute mise à niveau ou remplacement logiciel peut nécessiter des jours, voire des semaines de travail pour le scientifique. Pour éviter les temps d’arrêt, la recette doit être modifiée pour s’adapter aux changements dans le paysage applicatif.

La recette, telle qu’elle est mise en œuvre par le scientifique, optimise les dollars ou les euros de rendement. Nous avons abordé cet aspect dans les toutes premières conférences de cette série. Cependant, on ne doit pas attendre du scientifique qu’il décide comment modéliser les coûts et les profits. Bien qu’il doive proposer des modèles pour refléter les moteurs économiques, il revient finalement à la finance de décider si ces moteurs sont jugés corrects ou non. De nombreuses pratiques de la supply chain évitent le problème en se concentrant sur des pourcentages, tels que les taux de service et les précisions des prévisions. Cependant, ces pourcentages ont presque aucune corrélation avec la santé financière de l’entreprise. Ainsi, le scientifique doit régulièrement collaborer avec la finance et les amener à remettre en question les choix de modélisation et les hypothèses formulées dans la recette numérique.

Les choix de modélisation financière sont transitoires, car ils reflètent la stratégie changeante de l’entreprise. On attend également du scientifique qu’il élabore une instrumentation liée à la recette pour le département financier, telle que le montant maximal projeté du fonds de roulement associé aux stocks pour l’année à venir. Pour une entreprise de taille moyenne ou grande, il est raisonnable d’avoir une revue trimestrielle par un cadre financier du travail effectué par le scientifique de la supply chain.

L’une des plus grandes menaces pour la validité de la recette est de trahir accidentellement l’intention stratégique de l’entreprise. Trop de pratiques de la supply chain évitent la stratégie en se cachant derrière des pourcentages utilisés comme indicateurs de performance. Gonfler ou dégonfler les prévisions par le biais de la planification des ventes et des opérations (S&OP) ne remplace pas la clarification de l’intention stratégique. Le scientifique n’est pas responsable de la stratégie de l’entreprise, mais la recette sera incorrecte s’il ne la comprend pas. L’alignement de la recette sur la stratégie doit être planifié.

La manière la plus directe d’évaluer si le scientifique comprend la stratégie est de lui demander de l’expliquer à nouveau à la direction. Cela permet de détecter plus facilement les malentendus. En théorie, cette compréhension est déjà documentée par le scientifique dans le manuel de l’initiative. Cependant, l’expérience indique que les cadres ont rarement le temps de passer en revue en détail la documentation opérationnelle. Une simple conversation accélère le processus pour les deux parties.

Cette réunion n’a pas pour but de permettre au scientifique d’expliquer tout sur les modèles de la supply chain ou les résultats financiers. Le seul objectif est de garantir une bonne compréhension de la personne qui tient le stylo numérique. Même dans une grande entreprise, il est raisonnable que le scientifique rencontre le PDG ou un cadre pertinent au moins une fois par an. Les avantages d’une recette plus en phase avec l’intention de la direction sont vastes et souvent sous-estimés.

Les améliorations de la supply chain font partie de la modernisation numérique continue. Cela nécessite une certaine réorganisation de l’entreprise elle-même. Bien que les changements ne soient pas forcément drastiques, éliminer les pratiques obsolètes est un combat difficile. Lorsqu’elle est correctement exécutée, la productivité d’un scientifique de la supply chain est nettement supérieure à celle d’un planificateur traditionnel. Il n’est pas rare qu’un seul scientifique soit responsable de plus d’un demi-milliard de dollars ou d’euros de stocks.

Une réduction drastique des effectifs de la supply chain est possible. Certaines entreprises clientes de Lokad, qui étaient historiquement soumises à une pression concurrentielle immense, ont adopté cette approche et ont survécu en partie grâce à ces économies. La plupart de nos clients, cependant, optent pour une réduction plus progressive des effectifs à mesure que les planificateurs se tournent naturellement vers d’autres postes.

Les planificateurs qui restent réorientent leurs efforts vers les clients et les fournisseurs. Les retours d’information qu’ils collectent s’avèrent très utiles pour les scientifiques de la supply chain. En effet, le travail du scientifique est tourné vers l’intérieur de l’entreprise. Ils opèrent sur les données de l’entreprise, et il est difficile de voir ce qui est simplement absent.

De nombreuses voix du monde des affaires préconisent depuis longtemps de renforcer les liens avec les clients et les fournisseurs. Cependant, c’est plus facile à dire qu’à faire, surtout si les efforts sont régulièrement neutralisés en raison de luttes contre les incendies, de la réassurance des clients et de la pression exercée sur les fournisseurs. Les scientifiques de la supply chain peuvent apporter un soulagement bien nécessaire sur ces deux fronts.

Le S&OP (Sales and Operations Planning) est une pratique répandue visant à favoriser l’alignement de l’ensemble de l’entreprise grâce à une prévision de la demande partagée. Cependant, quelle que soit l’ambition initiale, les processus S&OP auxquels j’ai assisté se caractérisaient principalement par une série interminable de réunions improductives. Mis à part les mises en œuvre ERP et la conformité, je ne vois aucune pratique d’entreprise aussi néfaste pour l’âme que le S&OP. L’Union soviétique a peut-être disparu, mais l’esprit du Gosplan survit à travers le S&OP.

Une critique approfondie du S&OP mériterait une conférence à elle seule. Cependant, pour des raisons de concision, je dirai simplement qu’un scientifique de la supply chain est une alternative supérieure au S&OP dans toutes les dimensions qui comptent. Contrairement au S&OP, le scientifique de la supply chain est ancré dans des décisions réelles. La seule chose qui empêche un scientifique de devenir un agent de plus d’une bureaucratie d’entreprise enflée n’est pas son caractère ou sa compétence ; c’est d’avoir un enjeu dans le jeu grâce à ces décisions réelles.

Les planificateurs, les responsables des stocks et les responsables de la production sont souvent de grands consommateurs de toutes sortes de rapports d’entreprise. Ces rapports sont généralement produits par des produits logiciels d’entreprise communément appelés outils de business intelligence. La pratique typique de la supply chain consiste à exporter une série de rapports dans des feuilles de calcul, puis à utiliser une collection de formules de feuille de calcul pour fusionner toutes ces informations afin de générer semi-manuellement les décisions d’intérêt. Cependant, comme nous l’avons vu, la recette du scientifique remplace cette combinaison de business intelligence et de feuilles de calcul.

De plus, ni la business intelligence ni les feuilles de calcul ne conviennent pour soutenir la mise en œuvre d’une recette. La business intelligence manque d’expressivité, car les calculs pertinents ne peuvent pas être exprimés à travers cette classe d’outils. Les feuilles de calcul manquent de maintenabilité et parfois de scalabilité, mais surtout de maintenabilité. La conception des feuilles de calcul est largement incompatible avec tout type de correction par conception, ce qui est très nécessaire à des fins de supply chain.

En pratique, l’instrumentation d’une recette telle qu’elle est mise en œuvre par le scientifique inclut de nombreux rapports d’entreprise. Ces rapports remplacent ceux qui ont été générés jusqu’à présent par la business intelligence. Cette évolution n’implique pas nécessairement la fin de la business intelligence, car d’autres départements peuvent encore bénéficier de cette classe d’outils. Cependant, en ce qui concerne la supply chain, l’introduction du supply chain scientist marque la fin de l’ère de la business intelligence.

Si l’on met de côté quelques géants de la technologie qui peuvent se permettre de mobiliser des centaines, voire des milliers, d’ingénieurs pour résoudre chaque problème logiciel, le résultat typique des équipes de data science dans les entreprises ordinaires est désastreux. En général, ces équipes n’accomplissent jamais rien de concret. Cependant, la data science, en tant que pratique d’entreprise, n’est que la dernière itération d’une série de modes d’entreprise.

Dans les années 1970, la recherche opérationnelle était très en vogue. Dans les années 1980, les moteurs de règles et les experts en connaissances étaient populaires. Au tournant du siècle, l’exploration de données et les explorateurs de données étaient recherchés. Depuis les années 2010, la data science et les data scientists sont considérés comme la prochaine grande chose. Toutes ces tendances d’entreprise suivent le même schéma : une véritable innovation logicielle se produit, les gens s’en enthousiasment excessivement et décident de forcer l’intégration de cette innovation dans l’entreprise en créant un nouveau département dédié. C’est parce qu’il est toujours beaucoup plus facile d’ajouter des divisions à une organisation que de modifier ou de supprimer celles qui existent déjà.

Cependant, la data science en tant que pratique d’entreprise échoue car elle n’est pas fermement ancrée dans l’action. C’est là toute la différence entre un supply chain scientist, qui s’engage dès le premier jour à être responsable de la prise de décisions concrètes, et le département informatique.

Si nous pouvons mettre de côté les ego et les fiefs, le supply chain scientist représente une bien meilleure solution que l’ancien statu quo. Le département informatique typique est submergé par des années de retard, et demander plus de ressources n’est pas une proposition raisonnable, car cela se retourne contre les attentes des autres départements et augmente encore le retard.

Au contraire, le supply chain scientist ouvre la voie à une diminution des attentes. Le scientifique ne s’attend qu’à ce que des extraits de données brutes soient mis à disposition, et leurs batailles de traitement sont de leur responsabilité. Ils n’attendent rien du département informatique à cet égard. Le supply chain scientist ne doit pas être considéré comme une version d’entreprise de l’IT shadow. Il s’agit de rendre le département de la supply chain responsable et responsable de sa propre compétence de base. Le département informatique gère l’infrastructure de bas niveau et la couche transactionnelle, tandis que la couche de décision de la supply chain devrait relever entièrement du département de la supply chain.

Le département informatique doit être un facilitateur, pas un décideur, sauf pour les parties véritablement centrées sur l’informatique de l’entreprise. De nombreux départements informatiques sont conscients de leur retard et acceptent cette nouvelle approche. Cependant, si l’instinct de protéger ce qui est perçu comme leur territoire est trop fort, ils peuvent refuser de lâcher prise sur la couche de décision de la supply chain. Ces situations sont douloureuses et ne peuvent être résolues que par l’intervention directe du PDG.

De loin, notre conclusion pourrait être que le rôle du supply chain scientist peut être considéré comme une variation plus spécialisée du data scientist. Historiquement, c’est ainsi que Lokad a tenté de résoudre les problèmes liés à la pratique de la science des données en entreprise. Cependant, nous avons réalisé il y a une décennie que cela était insuffisant. Il nous a fallu des années pour découvrir progressivement tous les éléments qui ont été présentés aujourd’hui.

Le supply chain scientist n’est pas un ajout à la supply chain de l’entreprise ; il s’agit d’une clarification sur la propriété des décisions quotidiennes banales de la supply chain. Pour tirer le meilleur parti de cette approche, la supply chain, ou du moins sa composante de planification, doit être remodelée. Les départements adjacents tels que la finance et les opérations doivent également s’adapter à certains changements, bien que dans une moindre mesure.

Nourrir une équipe de supply chain scientists est un engagement considérable pour une entreprise, mais lorsqu’il est bien fait, la productivité est élevée. En pratique, chaque scientifique finit par remplacer 10 à 100 planificateurs, prévisionnistes ou gestionnaires de stocks, ce qui permet de réaliser d’énormes économies de salaires même si les scientifiques perçoivent des salaires plus élevés. Le supply chain scientist illustre un nouveau partenariat avec l’informatique, repositionnant l’informatique en tant que facilitateur plutôt qu’en tant que fournisseur de solutions, éliminant de nombreux, voire la plupart, des goulots d’étranglement liés à l’informatique.

Plus généralement, cette approche peut être reproduite dans tous les autres départements non informatiques de l’entreprise, tels que le marketing, les ventes et la finance. Chaque département a ses propres décisions quotidiennes banales à prendre, qui bénéficieraient également largement du même type d’automatisation. Cependant, tout comme le supply chain scientist est avant tout un expert en supply chain

Cependant, tout comme un supply chain scientist est avant tout un expert en supply chain, un marketing scientist ou un marketing quant devrait être un expert en marketing. La perspective du scientifique ouvre la voie pour tirer le meilleur parti de la combinaison de l’intelligence artificielle et de l’intelligence humaine en ce début du XXIe siècle.

La prochaine conférence aura lieu le 10 mai, un mercredi, à la même heure, à 15h heure de Paris. La conférence d’aujourd’hui était non technique, mais la prochaine sera largement technique. Je présenterai des techniques d’optimisation des prix. Les manuels de supply chain grand public ne traitent généralement pas des prix en tant qu’élément de la supply chain ; cependant, les prix contribuent de manière substantielle à l’équilibre de l’offre et de la demande. De plus, les prix ont tendance à être très spécifiques à un domaine, car il est très facile de mal aborder le défi dans son ensemble en pensant de manière abstraite. Ainsi, nous limiterons nos investigations au marché de l’après-vente automobile. Ce sera l’occasion de revisiter les éléments mis en avant avec Stuttgart, l’un des personnages de la supply chain que j’ai présentés dans le troisième chapitre de cette série de conférences.

Et maintenant, je vais passer aux questions.

Question : Il a fallu près d’une décennie à l’université pour comprendre que le domaine de la science des données avait émergé et qu’il fallait l’enseigner au lycée. Voyez-vous déjà la même chose se produire dans les cercles universitaires de la supply chain avec l’adoption de la perspective des sciences de la supply chain ?

Tout d’abord, je ne suis pas au courant de l’enseignement de la science des données dans les lycées en France. On n’enseigne pratiquement rien qui soit lié à l’informatique au lycée, encore moins la science des données. Je ne suis pas sûr de savoir où ils trouveraient même les professeurs ou les enseignants pour le faire. Mais je peux comprendre que vous vouliez que les lycéens aient une certaine compétence numérique. Je pense que se familiariser avec la programmation est une très bonne chose, et vous pouvez le faire même plus tôt, d’après mon expérience personnelle, à partir de l’âge de sept ou huit ans, selon la maturité de l’enfant. Vous pouvez le faire même à l’école primaire, mais nous parlons simplement de concepts de programmation de base : variables, listes d’instructions, et ce genre de choses. Je pense que la science des données dépasse largement les choses qui devraient être enseignées au lycée, à moins d’avoir des prodiges ou quelque chose du genre. C’est, pour moi, clairement quelque chose qui est destiné aux personnes de niveau universitaire, que ce soit au premier cycle ou aux cycles supérieurs.

En effet, il a fallu une décennie à l’université pour mettre en avant la science des données, mais arrêtons-nous un instant. J’ai décrit la science des données comme une pratique en entreprise, qui est à peu près la version miroir de ce que fait l’université lorsqu’elle enseigne la science des données. Donc, nous devons réfléchir au problème, et ici, je pense que l’un des problèmes est qu’il est incroyablement difficile d’enseigner quelque chose que l’on ne pratique pas. Du moins au niveau universitaire, sinon en dessous. Ce que je constate, c’est que nous avons déjà un problème avec la science des données, car les personnes qui enseignent la science des données ne sont pas celles qui pratiquent réellement la science des données dans des endroits qui comptent, comme Microsoft, Google, Facebook, OpenAI, et autres.

Pour la supply chain, nous avons un problème similaire, et il est extrêmement difficile d’avoir accès à des personnes ayant la bonne expérience. J’espère, et c’est une publicité éhontée de ma part, que Lokad commencera, dans les prochaines semaines, à fournir du matériel destiné aux diplômes en supply chain. Nous commencerons à diffuser du matériel emballé de manière à être approprié pour les professeurs dans le milieu universitaire, afin qu’ils puissent diffuser ces connaissances. Évidemment, ils devront utiliser leur propre jugement pour évaluer si les matériaux que Lokad propose valent réellement la peine d’être enseignés aux étudiants.

Question : Le langage spécifique à un domaine de Lokad n’est-il pas utilisé ailleurs ? Au-delà de Lokad, comment motivez-vous les nouveaux employés potentiels à apprendre quelque chose qu’ils ne sont probablement jamais amenés à utiliser dans leur prochain emploi ?

C’est exactement le point que je soulève concernant le problème que j’ai rencontré avec les data scientists. Les gens postulaient littéralement en disant : “Je veux faire du TensorFlow, je suis un spécialiste de TensorFlow” ou “Je suis un spécialiste de PyTorch”. Ce n’est pas la bonne attitude. Si vous confondez votre identité avec un ensemble d’outils techniques, vous passez à côté du sujet. Le défi consiste à comprendre les problèmes de la supply chain et comment les aborder de manière quantitative pour générer des décisions de qualité industrielle.

Dans cette conférence, j’ai mentionné qu’il faut six mois à un scientifique de la supply chain pour acquérir les compétences nécessaires pour maintenir une recette et deux ans pour concevoir une recette à partir de zéro. Combien de temps faut-il pour maîtriser complètement Envision, notre langage de programmation propriétaire ? D’après notre expérience, cela prend trois semaines. Envision est un détail mineur par rapport au défi global, mais c’est un détail important. Si vos outils sont médiocres, vous rencontrerez d’énormes problèmes accidentels. Cependant, soyons réalistes : c’est une petite pièce du puzzle global.

Les personnes qui passent du temps chez Lokad en apprennent énormément sur les problèmes de la supply chain. Le langage de programmation pourrait être réécrit dans d’autres langages, mais cela pourrait nécessiter plus de lignes de code. Ce que les gens, en particulier les jeunes ingénieurs, ne réalisent souvent pas, c’est à quel point de nombreuses technologies sont éphémères. Elles ne durent pas longtemps, généralement seulement quelques années avant d’être remplacées par autre chose.

Nous avons vu une série infinie de technologies venir et partir. Si un candidat dit : “Je me soucie vraiment des détails techniques”, il n’est probablement pas un bon candidat. C’était mon problème avec les data scientists - ils voulaient des choses à la pointe de la technologie. Les supply chains sont des systèmes extrêmement complexes, et quand vous faites une erreur, cela peut coûter des millions. Vous avez besoin d’outils de qualité industrielle, pas du dernier package non testé.

Les meilleurs candidats ont un véritable intérêt pour devenir des professionnels de la supply chain. La partie importante, c’est la supply chain, pas les détails du langage de programmation.

Question : Je suis en train de suivre une licence en supply chain, transport et gestion logistique. Comment puis-je devenir un scientifique de la supply chain ?

Tout d’abord, je vous encourage à postuler chez Lokad. Nous avons des postes ouverts tout le temps. Mais plus sérieusement, la clé pour devenir un scientifique de la supply chain est d’avoir une opportunité dans une entreprise qui est prête à automatiser ses décisions de supply chain. L’aspect le plus important est la prise de décision. Si vous pouvez trouver une entreprise qui est prête à essayer cela, cela vous aidera beaucoup à devenir un scientifique.

En affrontant les défis de la prise de décision à l’échelle industrielle, vous réaliserez l’importance des sujets que je discute dans cette série de conférences. Lorsque vous traitez de prévisions qui vont générer des millions de dollars de stocks, de commandes et de mouvements de stocks, vous comprendrez l’immense responsabilité et la nécessité de la précision dès la conception. Je suis sûr que d’autres entreprises vont se développer et acquérir de nombreuses opportunités. Mais même dans mes rêves les plus fous, je ne pense pas pouvoir espérer que chaque entreprise sur Terre utilisera Lokad. Il y aura beaucoup d’entreprises qui décideront toujours de faire les choses à leur manière, et elles s’en sortiront très bien.

Question : Étant donné que 40 % de la routine quotidienne d’un scientifique de la supply chain consiste à coder, quel langage de programmation recommanderiez-vous aux étudiants de premier cycle, en particulier ceux qui étudient la gestion ?

Je dirais que tout ce qui est facilement accessible. Python est un bon début. Ma suggestion est d’essayer plusieurs langages de programmation. Ce que vous attendez d’un ingénieur de la supply chain est pratiquement l’opposé de ce que vous attendez des ingénieurs logiciels. Pour les ingénieurs logiciels, mon conseil par défaut est de choisir un langage et d’approfondir, en comprenant vraiment toutes les subtilités. Mais pour les personnes qui sont finalement des généralistes, je dirais de faire l’inverse. Essayez un peu de SQL, un peu de Python, un peu de R. Faites attention à la syntaxe d’Excel et jetez un coup d’œil à des langages comme Rust, juste pour voir à quoi ils ressemblent. Donc, choisissez ce que vous avez à disposition. Au fait, Lokad a prévu de rendre Envision facilement accessible aux étudiants gratuitement, alors restez à l’écoute.

Question : Pensez-vous que les bases de données graphes auront un impact significatif sur les prévisions de la supply chain ?

Absolument pas. Les bases de données graphes existent depuis plus de deux décennies et, bien qu’elles soient intéressantes, elles ne sont pas aussi puissantes que les bases de données relationnelles comme PostgreSQL et MariaDB. Pour les prévisions de la supply chain, avoir des opérateurs de type graphe n’est pas ce qu’il faut. Dans les compétitions de prévision, aucun des 100 premiers participants n’a utilisé une base de données graphe. Cependant, il y a des choses qui peuvent être faites avec l’apprentissage profond appliqué aux graphes, ce que j’illustrerai dans ma prochaine conférence sur la tarification.

En ce qui concerne la question de savoir si les scientifiques de la supply chain devraient être impliqués dans la définition des objectifs des projets de data science client, je pense qu’il y a un problème avec l’hypothèse sous-jacente qui consiste à se concentrer sur la data science avant de comprendre le problème que nous essayons de résoudre. Cependant, en reformulant la question, les scientifiques de la supply chain devraient-ils être impliqués dans la définition des objectifs de l’optimisation de la supply chain ? Oui, absolument. Il est difficile pour le scientifique de découvrir ce que nous voulons vraiment, et cela nécessite une collaboration étroite avec les parties prenantes pour s’assurer que les bons objectifs sont poursuivis. Donc, les scientifiques devraient-ils être à bord pour cela ? Absolument, c’est essentiel.

Cependant, clarifions que ce n’est pas une initiative de data science ; c’est une initiative de supply chain qui se trouve pouvoir utiliser les données comme ingrédient approprié. Nous devons vraiment partir des problèmes et des ambitions de la supply chain, et ensuite, comme nous voulons tirer le meilleur parti des logiciels modernes, nous avons besoin de ces scientifiques. Ils vous aideront à affiner votre compréhension du problème, car la ligne de démarcation entre ce qui est faisable en logiciel et ce qui relève strictement du domaine de l’intelligence humaine est un peu floue. Vous avez besoin des scientifiques pour naviguer sur cette ligne de démarcation.

J’espère vous voir dans deux mois, le 10 mai, pour la prochaine conférence où nous discuterons de la tarification. À bientôt.