Livraison orientée produit pour Supply Chain - Lecture 1.3

00:22 Introduction
02:40 Pourquoi un produit ? Parce que le capitalisme
08:18 Que doit faire le produit ?
10:05 Les diseconomies d’échelle des logiciels
12:50 Achetons un produit SCO prêt à l’emploi
21:58 SCM vs SCO
25:58 Intermède
28:21 Le SCO n’est pas un produit logiciel ordinaire
33:26 Ingrédients logiciels pour SCO
42:49 Pourtant, les feuilles de calcul ne sont pas la finalité
46:51 Python n’est pas non plus la finalité
58:52 La supply chain n’est pas une division de l’IT
01:03:19 En conclusion, deux défis à relever
01:07:04 Prochaine conférence et questions du public

Description

Le but d’une la Supply Chain Quantitative initiative est soit de livrer, soit d’améliorer une application logicielle qui robotise un ensemble de décisions routinières (par exemple, les réapprovisionnements de stocks et les mises à jour des prix). L’application est considérée comme un produit à concevoir. La supply chain theory est là pour nous aider à livrer une application qui oriente l’entreprise vers supply chain performance, tout en étant compatible avec toutes les contraintes qu’implique la production.

Transcription complète

Salut tout le monde, merci beaucoup de vous joindre à cette série de conférences supply chain. Je suis Joannes Vermorel, et je vais présenter « Livraison orientée produit pour l’optimization de la supply chain. »

Tout d’abord, lorsque je parle d’un produit, je fais référence à un produit logiciel. Pour ceux d’entre vous qui ont déjà eu le privilège d’examiner les rouages d’une application d’entreprise, cela peut être une sacrée expérience.

Pour ceux qui connaissent le travail de H.P. Lovecraft, il existe des similitudes troublantes. Lovecraft a produit une série de romans, et l’un des thèmes récurrents est l’idée de connaissance interdite. Ce n’est pas que l’univers ne puisse être connu, il le peut. C’est simplement que la seule chose qui préserve l’humanité, c’est l’ignorance. L’ignorance n’est pas un problème ; c’est précisément ce qui nous protège d’un univers trop terrifiant pour que notre esprit puisse le supporter. Cette idée a été recyclée dans de nombreux jeux modernes, en particulier les jeux de rôle, où, en plus des points de vie traditionnels, les personnages disposent de points de santé mentale. Si vous faites certaines choses qui nuisent à votre santé mentale, vous en perdez. Le défi avec les logiciels d’entreprise est de pouvoir les créer tout en préservant votre santé mentale, ce qui est l’une des conditions pour apporter de la valeur à l’entreprise. Allons-y.

Pourquoi un produit, et en particulier, un produit logiciel ? Jetons un coup d’œil de plus près sur le fonctionnement traditionnel des supply chains. Autrefois, il y avait de nombreuses personnes sur le terrain pour déplacer des choses, trier des colis, conduire des véhicules et effectuer tous les travaux manuels. Il y avait également beaucoup de personnes impliquées dans la production, ainsi que dans les magasins. Ce qui s’est progressivement produit au cours des deux dernières décennies, c’est que le nombre de travailleurs manuels a régulièrement diminué. De nos jours, en termes de production, tout est largement automatisé. Il existe encore quelques industries, comme le textile, où il est difficile d’automatiser entièrement, raison pour laquelle ces industries se sont installées là où la main-d’œuvre est la moins chère. La réalité est que les besoins en main-d’œuvre brute ont été considérablement réduits.

On se retrouve dans une situation assez étrange où, en envisageant l’avènement des véhicules autonomes, de nombreuses entreprises auront plus de cadres traitant des feuilles de calcul Excel pour gérer la supply chain qu’elles n’auront d’ouvriers sur le terrain pour effectuer les tâches manuelles. C’est à cela que je fais référence quand je parle de travail de bureau.

Un autre aspect particulier est que les supply chains ont été digitalisées pour de nombreuses entreprises depuis au moins deux décennies. Ce n’est pas comme si nous allions introduire des logiciels dans les supply chains ; celles-ci sont déjà pilotées et exploitées via des logiciels. Mais lorsqu’on examine le rôle des humains dans ces systèmes logiciels, on constate qu’ils sont littéralement utilisés comme co-processeurs humains dans une supply chain moyenne. Il existe des types d’opérations spécifiques que le CPU classique, le processeur de la machine, ne peut pas effectuer, et ainsi l’ensemble de la tâche est délégué à un humain. En conjonction avec des recettes numériques, telles que l’analyse ABC stocks, le min-max des stocks (ou min-max) et d’autres recettes similaires, les humains finissent par passer leurs journées à éteindre des incendies. Ils font constamment face à des exceptions et à des conditions qui ne correspondent pas au cadre standard.

D’un point de vue coût, tout cela relève des dépenses d’exploitation (OpEx). Il faut payer une armée de commis chaque jour pour gérer toutes les décisions routinières que votre entreprise doit prendre quotidiennement. Cela inclut ce qu’il faut acheter, où placer les stocks, s’il faut déplacer une unité d’un entrepôt vers un magasin, et bien d’autres décisions de routine. Les humains prennent ces décisions et passent leur temps à éteindre des incendies pour compenser les insuffisances des décisions automatiques générées naïvement par le système.

Ma proposition pour vous aujourd’hui est de passer des dépenses d’exploitation (OpEx) aux dépenses d’investissement (CapEx). C’est tout l’intérêt de cette livraison orientée produit. Nous voulons construire un actif, et pourquoi ? Parce que c’est capitaliste. Si vous regardez les 100 entreprises les plus rentables au monde de nos jours, la moitié d’entre elles, en termes de bénéfices, sont des entreprises de logiciels. Elles représentent l’essence même des entreprises ultra-capitalistes, où vous effectuez un investissement initial, et vous vous retrouvez ensuite avec un dispositif ou un artefact qui génère de la valeur ajoutée avec un investissement marginal minimal.

Pour revenir au sujet de ma précédente conférence, nous avons besoin de robotisation pour remettre le management aux commandes. L’automatisation et les humains doivent travailler ensemble ; les humains ne devraient pas être là pour pallier les insuffisances de politiques de stocks stupides comme le min-max. Au contraire, ils devraient être là pour apporter de la valeur, améliorer les recettes numériques et agir en tant que stratèges. Il existait autrefois un slogan IBM qui disait : “Les machines doivent travailler ; les gens doivent réfléchir.” C’est ce genre de réflexion qui anime cette présentation. Nous voulons transformer la supply chain en un actif capitaliste, et pour ce faire, nous devons transformer la supply chain en une machine qui délivre un produit logiciel.

Que fait exactement ce produit ? Il s’avère qu’il accomplit quelque chose de très simple : il prend des décisions. Pas des décisions arbitraires et ouvertes, mais des décisions routinières, telles que ce qu’il faut produire, combien d’unités acheter chez un fournisseur et combien d’unités déplacer d’un endroit à un autre. À première vue, il pourrait sembler qu’il y ait de nombreuses décisions impliquées dans la gestion de la supply chain. Cependant, lorsqu’on examine les tâches, même les supply chains les plus complexes ne nécessitent que quelques dizaines de types de décisions à prendre chaque jour. Ceci n’est pas accablant, et c’est tout à fait raisonnable en termes de nombre de fonctionnalités. Fait intéressant, ces décisions sont pour la plupart exclusives, si bien qu’il y a des limites à ce que l’on peut faire en adoptant une approche de division et conquête. Une fois que vous avez décidé d’acheter 100 unités chez un fournisseur, un autre sous-système ne peut pas décider d’en acheter 200 à la place. À un moment donné, il faut se décider sur le nombre d’unités à acheter et à déplacer d’un endroit à un autre. Ces décisions sont discrètes, limitées en portée et essentiellement exclusives. Ce que nous voulons, c’est un logiciel qui génère des décisions de commande de façon entièrement automatisée chaque jour.

Une chose que je pense souvent mal comprise à propos des logiciels est la notion de déséconomies d’échelle. Alors que les économies d’échelle sont familières à la plupart, l’inverse est vrai dans le domaine des logiciels, où l’ajout d’un quart de fonctionnalités supplémentaires peut doubler le coût. Ce concept explique pourquoi de petites startups peuvent rivaliser avec de grandes entreprises – parce qu’elles se concentrent sur une fraction plus réduite des fonctionnalités, le coût de mise sur le marché de leur produit peut être considérablement inférieur à celui d’une grande entreprise.

En gardant en tête l’idée des déséconomies d’échelle, nous devons décider s’il faut construire, acheter ou adopter une autre approche pour notre produit d’optimization de la supply chain. Si nous choisissons d’acheter le produit auprès d’un fournisseur, nous devons prendre en compte les fonctionnalités que le fournisseur de logiciels devra offrir pour répondre au marché.

Alors, envisageons d’acheter un produit d’optimization de la supply chain prêt à l’emploi. Dans ces diapositives, je présente un aperçu d’une infime fraction de toutes les choses que nous devons aborder. J’ai une expérience de première main à ce sujet, car lorsque j’ai commencé Lokad en 2008, j’ai débuté avec un petit produit logiciel orienté davantage vers la prévision que vers l’optimization de la supply chain. En travaillant avec des clients, j’ai réalisé qu’il y avait tellement de fonctionnalités et de capacités qui me manquaient, et en passant à d’autres clients, j’ai découvert encore plus de capacités absentes. Cela semblait être un processus sans fin de découverte de nouvelles exigences.

Examinons maintenant les fonctionnalités de base. Tout d’abord, il y a des entreprises B2C ou B2B, qui présentent des schémas complètement différents en matière de gestion de la supply chain. Par exemple, les entreprises B2B ont généralement moins de clients, mais ces clients commandent des quantités bien plus importantes. Cela engendre différents types de risques, comme celui de perdre un client unique qui représente une part significative du chiffre d’affaires de l’entreprise. Ensuite, il existe des modèles commerciaux plus complexes tels que B2B2C ou B2B2B.

Considérez les différents types de sites à couvrir, comme les magasins, les entrepôts et les sites de production. Chaque type de site comporte son propre ensemble de défis. Les magasins, par exemple, sont sujets à des inexactitudes de stocks, même avec la technologie RFID, simplement parce que les clients peuvent déplacer les produits. Les entrepôts et les sites de production, tels que les fermes ou les opérations minières, présentent leurs propres problèmes spécifiques et des incertitudes quant au rendement de la production.

Les réseaux de supply chain peuvent avoir différents niveaux, ou échelons, allant des systèmes à un seul échelon aux systèmes multi-échelons. La complexité de la gestion de la supply chain augmente considérablement avec le nombre d’échelons. La topologie du réseau est un autre aspect important à considérer. Une topologie en arbre est le chemin classique de la supply chain en avant, où quelques sites de production expédient vers plusieurs entrepôts, qui à leur tour distribuent vers de nombreux magasins. Cependant, d’autres topologies, telles que les graphes acycliques dirigés (DAG), peuvent exister, où un magasin peut être desservi par plusieurs entrepôts.

Donc, en gros, ce n’est pas simplement un arbre en termes de graphes, il peut se reconnecter, bien que ce soit toujours en avant. Mais la même chose peut se produire avec un Graphe Acyclique Dirigé (DAG) lorsque vous avez plusieurs fournisseurs. Vous pouvez même avoir des boucles dans votre graphe de supply chain qui se produisent chaque fois que des réparations sont impliquées. Par exemple, dans l’industrie minière ou dans l’industrie aviation, il existe une multitude de boucles de réparation avec du matériel réparable.

Maintenant, les stocks eux-mêmes n’ont pas une seule nature ; ils varient énormément. On ne peut pas simplement dire : “Oh, j’ai cette idée que je dispose de SKUs et c’est tout.” Non, pas vraiment, car d’abord, vous avez des matières premières qui sont littéralement mesurées en quantités telles que grammes, kilogrammes ou volume. Ensuite, vous avez des unités qui sont les unités nettes et claires, majoritairement répandues. Mais vous pouvez également avoir beaucoup de stocks qui se renouvellent très fréquemment, par exemple dans le secteur pharmaceutique ou dans l’alimentaire, où le lot est assorti de dates d’expiration spécifiques. Ensuite, vous pouvez même avoir des stocks entièrement sérialisés, où chaque unité possède son propre numéro de série. En termes d’optimization de la supply chain, cela change complètement la donne, c’est donc un problème tout à fait différent quand vous considérez chacun de ces aspects.

Ensuite, évidemment, il y a tous les problèmes des marketplaces. Chez Lokad, nous avons des clients dans pratiquement toutes les situations possibles. Nous avons des clients qui vendent sur une marketplace tierce, qui peuvent avoir leur propre marketplace, ou les deux. Cela peut être quelque chose de secondaire leur permettant de liquider les invendus. Il existe de nombreuses situations.

Maintenant, par exemple, réfléchissez un instant à ce qu’est une commande. Il y a la commande spot, où, fondamentalement, vous achetez quelque chose directement, et cela devient le vôtre. Mais vous pouvez également avoir une commande qui stipule : “Je l’achète, mais je ne veux pas qu’elle soit livrée immédiatement ; je souhaite qu’elle soit livrée dans un mois.” Évidemment, du point de vue de l’optimization de la supply chain, c’est un tout autre jeu, car si vous savez à l’avance que vous devrez livrer une certaine quantité de produits à une date précise, vous ne voulez pas en faire la prévision, donc c’est une chose complètement différente.

Et puis, il y a la commande configurée, qui correspond, par exemple, à l’achat d’un ordinateur en ligne où vous pouvez choisir la quantité de mémoire, la capacité du disque dur, le type de système d’exploitation, la langue qui sera configurée sur votre ordinateur, ainsi que le type de clavier, entre autres. Vous pouvez ainsi avoir un configurateur massif, ce qui modifie à nouveau le paysage. Cela se produit également pour des produits comme des vélos ou des voitures et change complètement la donne, car cela vous offre des options et des manières d’aborder le problème de l’optimization de la supply chain qui sont complètement différentes.

Pour les prix, vous pouvez avoir un prix à l’unité fixe, super simple et parfaitement linéaire, mais ce n’est pas tout. Vous pouvez avoir des remises par palier, par exemple, si vous achetez dix unités, vous obtenez alors une remise. Ou vous pouvez disposer de programmes de fidélité où certains clients munis d’une carte de fidélité peuvent bénéficier d’une réduction, mais seulement sur certains types de produits ou sous certaines conditions. Et puis, en B2B, il arrive même très fréquemment que des éléments soient négociés, de sorte qu’il s’agit littéralement d’une transaction où beaucoup de choses sont vendues, tout en conservant un prix catalogue régulier. Cependant, un fournisseur peut octroyer un rabais à un client parce qu’il est important, et c’est ainsi que ça se fait. En fin de compte, je parle à peine depuis quelques minutes et je n’ai couvert que l’essentiel. Je n’ai même pas commencé à aborder les éléments indispensables. Prenez donc un moment pour imaginer à quoi pourrait ressembler un produit logiciel d’entreprise prêt à l’emploi censé fournir l’optimization de la supply chain. Le nombre de fonctionnalités à couvrir est littéralement fou, et quand vous essayez d’assembler toutes ces choses en un monolithe, vous perdez littéralement la tête. Nous revenons à cette idée que ce n’est pas que l’univers ne puisse être connu, c’est juste que, face à la vérité nue de l’univers, on perd la raison.

Nous avons donc un problème majeur, et ici nous devons différencier la gestion de la supply chain de l’optimization de la supply chain. C’est une distinction que j’avais déjà introduite dans l’une de mes conférences précédentes. Il y a une grande confusion entre le volet gestion et le volet optimization. La gestion consiste en la tenue de livres, le support des workflows et principalement les processus de saisie de données. Si vous voulez représenter tout ce dont je viens de parler, cela représente énormément de terrain à couvrir, mais c’est faisable. Un ERP « obèse » peut faire cela. Oui, vous vous retrouverez avec 10 000 tables, ce sera assez moche, mais c’est possible. Mais ne vous méprenez pas, l’ERP (qui devrait s’appeler ERM, Enterprise Resource Management) ne va pas faire grand-chose. Il se contentera simplement de suivre ces éléments. Vous aurez donc des tonnes d’entités – MOQs, vérifiez ; des remises, vérifiez ; des magasins, vérifiez ; des entrepôts, vérifiez – mais vous n’avez pas besoin d’intelligence. Il s’agit simplement de reproduire numériquement des informations afin de rendre possible leur saisie dans le système, et c’est tout.

C’est possible car, ici, nous pouvons contourner un peu cette règle selon laquelle « un quart de fonctionnalités supplémentaires doublent le coût ». Il y a quelque chose que je n’ai pas vraiment mentionné à ce sujet : cela fonctionne si vous gardez vos fonctionnalités complètement séparées. Tant que ces fonctionnalités n’interagissent pas entre elles, tout va bien ; vous n’êtes pas soumis à cette malédiction des dyséconomies d’échelle. Du point de vue de la saisie de données, tout est en ordre. Vous n’avez pas besoin d’une interface utilisateur qui vous permette de piloter les MOQs en lien avec ce qui vous permet d’ajouter un magasin supplémentaire au réseau. Ces deux éléments peuvent être entièrement dissociés.

Cependant, en ce qui concerne l’optimization de la supply chain, ce n’est pas le cas. Si vous avez des MOQs, ils auront des implications profondes sur la fréquence de vos commandes et sur la régularité avec laquelle vous livrez des marchandises de votre entrepôt vers vos magasins. Les conséquences sont nombreuses et étendues. Vous ne pouvez pas dissocier ces éléments parce que, en fin de compte, votre supply chain est un système unique où tout influence tout. Ainsi, d’un point de vue de l’optimization de la supply chain, le problème est littéralement que tous ces éléments doivent être interconnectés pour offrir de l’optimization, et c’est là que tout se complique.

Du côté de la gestion, il est potentiellement possible d’aboutir à un produit. Cependant, pour l’optimization de la supply chain, la réponse est que vous ne pouvez pas. Je veux dire, vous pouvez faire semblant, mais littéralement, ce n’est pas possible. Même chez Lokad, qui n’a pas débuté en tant qu’entreprise prédictive spécialisée dans l’optimization prédictive de la supply chain, mais plutôt dans la prévision en mode service, cela se voit. Si vous remontez au blog de Lokad en 2008, j’avais initialement commencé avec la prévision des séries temporelles, ce qui était fortement erroné. Néanmoins, c’est ainsi que j’ai débuté. Même pour la prévision des séries temporelles, qui n’est qu’un infime sous-ensemble du problème global, c’est ingérable. Telle est ma conclusion après plus de 12 ans dans ce secteur.

Si nous devons revenir au monde spécifique de la production de logiciels, c’est quelque chose de très particulier. À moins d’avoir été formé en tant qu’ingénieur logiciel et d’être familier avec la manière dont les grandes entreprises de logiciels performantes produisent leurs applications, il y a de fortes chances que vous n’en sachiez que très peu à ce sujet. Il s’avère que c’est un univers très spécifique avec de nombreux aspects profondément contre-intuitifs. Les entreprises traditionnelles, surtout celles qui ont une mentalité d’ingénierie mécanique classique ou une approche marketing, peinent énormément à comprendre comment fonctionnent les logiciels.

Nous aborderons ces aspects plus en détail dans de futures conférences, mais il y a un livre que j’apprécie particulièrement, écrit par Joel Spolsky, un ancien employé de Microsoft qui a travaillé dans les premières équipes de Microsoft Excel. Il est également le cofondateur de Stack Overflow et de Trello. En 2004, alors que je n’étais qu’un étudiant, j’ai lu son livre et son blog. Le livre s’intitule “Joel on Software,” et il vous offre, de manière humoristique, une idée de ce à quoi ressemble la gestion d’une entreprise de logiciels prospère. C’est très différent de ce à quoi la plupart des personnes en dehors de ce secteur s’attendent. J’ajouterai les détails de ce livre dans la description de la vidéo.

Mais gardons à l’esprit que l’optimization de la supply chain n’est pas un produit logiciel moyen. Habituellement, lorsqu’on parle d’un produit logiciel moyen – je veux dire, oui, il existe certains comportements adverses, selon le type de logiciel – si vous traitez d’un réseau social, vous pouvez avoir de nombreuses personnes postant du contenu haineux, ce qui est une toute autre affaire. Cependant, lorsqu’il s’agit de logiciels d’entreprise classiques, comme Microsoft Word ou Excel, c’est un produit pour lequel l’enjeu est d’avoir le design adéquat, sans qu’il y ait une quelconque urgence. Dans le cas des produits logiciels traditionnels, il est acceptable de passer des années à peaufiner le design et le produit. C’est un investissement à long terme, et il faut penser sur plusieurs décennies. Il n’y a aucune raison de précipiter quoi que ce soit en termes de développement. Cependant, l’optimization de la supply chain ne fonctionne pas ainsi. Vous n’avez pas le choix, car les choses se produisent en permanence, et le terrain est très accidenté.

Vous pouvez être confronté à des situations extrêmes comme la pandémie ou à d’autres problèmes tels que les ransomwares, qui peuvent paralyser la moitié de votre réseau. Vous devez prendre des décisions intelligentes pour exploiter au mieux les capacités dont vous disposez encore. Vous pouvez être confronté à l’immobilisation de flottes à la suite d’incidents tragiques, à des mesures politiques telles que des tarifs douaniers qui perturbent votre stratégie, ou à des catastrophes naturelles comme des tsunamis ou des incendies et vagues de chaleur, telles que celles en Californie ou en Australie. Ces événements surviennent, et quand ils se produisent, vous devez être capable de réagir littéralement en quelques heures.

Vous avez votre produit logiciel, mais vous devez provoquer le changement, et vous souhaitez opérer un changement programmatique. Rappelez-vous, si vous avez l’état d’esprit de livrer un actif logiciel, vous disposez d’une petite équipe qui pilote le logiciel et, par ricochet, votre supply chain. Vous n’avez pas une armée d’employés de bureau à éteindre des feux toute la journée. Même si vous en avez une, il faut les former, et quand quelque chose d’inattendu se produit, vous vous retrouvez avec une armée non préparée pour cette situation précise. D’après mon expérience, plus vous avez de personnes à gérer, plus il faut de temps pour obtenir des résultats.

Il y a seulement quelques jours, un cargo a perdu plus de 1 800 conteneurs à cause de mauvaises conditions météorologiques. Ces événements arrivent tout simplement, et vous ne pouvez espérer les éliminer. La supply chain n’est pas comme la fabrication, où vous pourriez avoir un site de production avec tout sous contrôle. Par définition, les supply chains se déroulent dans un monde vaste, où, la plupart du temps, vous n’avez aucun contrôle sur les éléments. Il y a tellement de forces qui vous échappent qu’il faut être capable de gérer les événements surprenants. Vous savez déjà que des surprises se produiront, alors vous devez être préparé. Être préparé ne signifie pas avoir tout minutieusement planifié ; il s’agit d’avoir un système qui vous permette de réagir en quelques heures si nécessaire. Voilà l’essence même de ce que vous pouvez faire pour aborder le problème de manière réaliste.

Maintenant, quels sont les ingrédients logiciels dont nous avons besoin pour l’optimization de la supply chain ? Tout d’abord, il nous faut un stockage de données polyvalent pour représenter la diversité des sources de données. Il y a tellement de choses à représenter que nous avons besoin de quelque chose de très flexible à cet égard, avec beaucoup de structure et de variété.

Deuxièmement, vous voulez une logique programmable. Je reviens sur cette idée : si vous n’avez pas de logique programmable, comment faire face à tous ces problèmes ? Comment coller tous ces éléments ensemble ? Vous ne pouvez pas acheter un produit prêt à l’emploi qui aurait tout préprogrammé pour vous ; cela ne fonctionne pas.

Ensuite, il vous faut des interfaces utilisateur polyvalentes, car la manière d’aborder vos problèmes variera énormément d’une situation à l’autre. Les KPI seront complètement différents d’une entreprise à l’autre, donc il vous faut une interface utilisateur flexible qui vous permette de présenter les chiffres comme bon vous semble ; sinon, cela constitue une grande limitation.

Vous souhaitez également des capacités collaboratives, car la supply chain est, par définition, un travail d’équipe. Il y a de nombreuses personnes impliquées et c’est distribué, ainsi les fonctionnalités collaboratives doivent être au cœur du système.

Enfin, et peut-être de manière plus controversée, vous souhaitez des capacités programmables accessibles aux personnes qui ne sont pas des ingénieurs logiciels formés. Cela est important pour plusieurs raisons. Premièrement, il y a peu d’ingénieurs logiciels qualifiés sur le marché, rendant leur embauche très compétitive. Deuxièmement, il faut énormément d’efforts et de dévouement pour devenir un ingénieur logiciel talentueux, ce qui rend difficile d’être simultanément un Supply Chain Scientist.

Il n’est pas très courant de trouver des personnes disposant d’une double compétence dans ces deux domaines. Il en serait de même si vous recherchiez quelqu’un qui soit à la fois programmeur et avocat, ou programmeur et médecin. Oui, vous trouverez quelques personnes possédant ces compétences, mais pouvez-vous le faire à grande échelle ou embaucher de manière fiable davantage de personnes chaque année si vous êtes une grande entreprise ? D’après mon expérience à la tête de Lokad pendant une décennie, cela ne fonctionne tout simplement pas.

Vous souhaitez quelque chose de programmable, mais vous n’avez pas besoin d’être un ingénieur logiciel professionnellement formé pour gérer la programmation. Rappelez-vous qu’il faut quelqu’un possédant une compétence en supply chain, car vous devez pouvoir, en quelques heures, appliquer des corrections programmatiques à votre système sans avoir à ouvrir un ticket et à le transmettre au service informatique. Si vous devez procéder ainsi, il faudra alors des semaines pour résoudre les problèmes, et non des heures. Alors, quel type de logiciel peut réellement résoudre le problème ?

Eh bien, Excel le peut. Ce n’est pas beau, et cela ne représente peut-être pas le summum des logiciels modernes, mais ça fait l’affaire. Il coche toutes les cases.

Un stockage de données polyvalent ? Oui, dans une certaine mesure, vous pouvez intégrer énormément de données de tous types dans Excel. Une logique programmable ? Absolument, Excel est entièrement programmable. Une interface utilisateur polyvalente ? Oui, vous pouvez créer des graphiques à barres, des graphiques linéaires et bien d’autres moyens de présenter des données. En termes d’interfaces, il est très flexible. Il n’est peut-être pas le plus abouti, mais en termes de polyvalence, il peut faire beaucoup.

En ce qui concerne les capacités collaboratives, c’est un peu rudimentaire. Certaines versions d’Excel sont disponibles en ligne, ce qui est légèrement mieux, mais fondamentalement, vous pouvez partager vos feuilles de calcul. Le problème du manque de fonctionnalités collaboratives n’est pas que ce soit une application de bureau. Le souci réside dans l’état d’esprit qui accompagne les feuilles de calcul, et qui n’est pas adapté à un travail collaboratif intensif. Habituellement, si un collègue a créé un fichier très complexe, il est plus simple de recréer la feuille que d’essayer de comprendre ce qu’il a fait. Donc, le manque de fonctionnalités collaboratives tient à cet état d’esprit inhérent aux tableurs, qui présente de fortes limites en matière de collaboration.

Cependant, Excel est entièrement accessible aux non-développeurs, et il existe même Visual Basic for Applications pour les tâches plus complexes. En termes d’ingrédients, Excel coche toutes les cases, ce qui, je pense, explique en grande partie le succès opérationnel qu’il connaît dans la plupart des supply chains.

D’après mon expérience, la majorité des supply chains dans le monde, des plus petites entreprises aux plus grandes, et allant de celles qui n’ont jamais investi un centime dans des logiciels d’entreprise à celles qui ont mis des millions de dollars dans des logiciels d’entreprise complexes pour l’optimization de la supply chain, sont pilotées par Excel. Il y a très peu d’exceptions. Parfois, certains utilisent Excel pour revoir les réglages min-max dans d’autres logiciels, mais la maintenance de ces réglages est confiée à ceux qui travaillent avec Excel.

Excel fait tourner le monde de la supply chain aujourd’hui, et je crois que ce n’est pas un hasard. Au fond, les feuilles de calcul répondent fondamentalement à bon nombre des problématiques essentielles. Beaucoup d’autres options se présentent comme supérieures, mais échouent par défaut si vous ne savez pas programmer. Si vous ne savez pas programmer, cela signifie que, lorsqu’un problème majeur ou une urgence survient, vous êtes mal barré. Les gens se rabattent sur Excel dans des situations où l’interface utilisateur polyvalente manque ou lorsque la solution n’est pas accessible aux non-développeurs. Si seuls une équipe IT peut apporter des résultats, les gens peuvent d’abord ouvrir des tickets et attendre patiemment, mais au bout de trois mois, tout le monde finira probablement par utiliser à nouveau Excel, car c’est plus rapide. Excel n’est pas le but ultime, mais quelle que soit la solution de remplacement supérieure que nous proposerons, elle devra cocher les bonnes cases.

Comment pouvons-nous améliorer quelque chose ? En termes de stockage de données polyvalent, Excel est bon mais pas très scalable. Le traitement de millions de lignes devient un problème, même avec les versions modernes d’Excel capables de gérer un million de lignes. Des problèmes de performance surgissent rapidement lorsqu’on opère à grande échelle. La logique programmable dans Excel est possible, mais elle est très fragile et délicate. Si vous introduisez involontairement une erreur ou un bug dans votre feuille de calcul, le débogage et l’identification de la source du problème deviennent un cauchemar. La logique est dupliquée sans cesse, ce qui se traduit par des milliers de copies de la même logique, rendant difficile l’identification et la correction des erreurs.

L’interface utilisateur n’est pas idéale, car elle n’est pas entièrement web et les données restent toujours imbriquées avec l’interface. Des capacités collaboratives existent, mais elles sont confuses. La collaboration devrait se faire au niveau de la logique programmable. De nombreux fournisseurs d’optimisation de la supply chain offrent une collaboration sur les résultats, comme le réglage manuel des prévisions et la participation de plusieurs personnes. Cependant, c’est la mauvaise approche. Les collaborations doivent avoir lieu, mais elles doivent se produire au niveau logique, c’est-à-dire au niveau de la logique programmable. Excel est très accessible aux non-développeurs, mais dès que vous voulez faire quelque chose d’un peu plus compliqué, cela devient difficile. En gestion de la supply chain, nous voulons aborder tous les futurs possibles, ce qui signifie travailler avec des prévisions probabilistes, des variables aléatoires et prendre en compte l’incertitude. Bien que cela soit possible dans Excel, c’est assez compliqué. Excel est facile pour des tâches simples, mais pour des situations plus complexes, il faut devenir un expert Excel.

La maintenabilité est importante, car vous souhaitez construire un actif dont la valeur augmente avec le temps. Avec les feuilles de calcul, il est difficile d’y parvenir, et il est ardu de créer quelque chose de véritablement précis, du moins dans le sens d’un produit logiciel.

Les mots à la mode du moment sont AI et Python, avec toutes les tendances et le battage médiatique entourant la data science. Cependant, pour la gestion de la supply chain, je pense que Python est inférieur à Excel.

Ne vous méprenez pas ; j’adore Python, et je pense que c’est un langage brillant. Je l’enseigne même à ma fille de 10 ans. Cependant, il y a plusieurs raisons pour lesquelles Python n’est pas le meilleur choix pour la gestion de la supply chain. Tout d’abord, il requiert des ingénieurs logiciels. Bien que Python soit l’un des langages de programmation les plus accessibles, lorsque vous voulez faire quelque chose de plus complexe, il vous faut une équipe d’ingénierie logicielle, ce qui crée des difficultés quand il s’agit de trouver des personnes à la fois expertes en supply chain et en ingénierie logicielle.

Python offre de belles fonctionnalités, mais la gestion des dépendances est assez complexe et la gestion des packages est médiocre. Les packages sont des éléments constitutifs qui apportent des capacités supplémentaires, et lorsque vous affirmez vouloir utiliser Python, il ne s’agit pas seulement du langage, mais aussi de l’ensemble de l’écosystème des packages qui vous intéresse, tels que NumPy, Pandas, TensorFlow et SciPy – toutes des dépendances tierces ou bibliothèques logicielles. La gestion des packages est médiocre depuis plus d’une décennie, et bien que cela s’améliore, les progrès sont lents. De nombreux aspects de la conception du système rendent son amélioration difficile.

La performance est également médiocre, principalement par conception. La performance de calcul fait référence à la qualité du travail réalisé par Python pour exploiter la puissance de calcul brute disponible sur votre ordinateur. Étonnamment, Microsoft Excel fait un bien meilleur travail à cet égard. Excel est hautement optimisé, tirant parti des systèmes multi-CPU et multi-cœurs, et exécutant une logique compilée nativement. Microsoft a investi massivement pour rendre Excel extrêmement rapide.

En revanche, Python présente des problèmes inhérents qui font souvent en sorte que sa performance soit 100 fois plus lente que ce que votre machine pourrait théoriquement fournir. Bien que cela puisse sembler acceptable pour certains, compte tenu de la puissance des ordinateurs modernes, ce n’est pas idéal pour les entreprises avec des volumes de transactions dépassant 50 millions de dollars. Vous voulez quelque chose qui offre de bonnes performances dès le départ.

L’idée d’utiliser une bibliothèque tierce comme NumPy pour pallier le manque de performance de Python n’ajoute qu’une complexité supplémentaire. Vous pouvez résoudre le problème de performance, mais vous créez une nouvelle problématique en introduisant la complexité additionnelle de NumPy, avec laquelle vous devez composer et que vous devez maintenir dans le temps. Cela augmente également les exigences du côté de l’ingénierie logicielle.

Lorsqu’on tente de mettre en œuvre des solutions Python pour une gestion réelle de la supply chain, divers problèmes surgissent, tels que des exceptions de référence nulle, des exceptions de mémoire insuffisante et des temps de calcul très longs. Il se peut que vous vous retrouviez à attendre 20 minutes la fin d’un calcul, sans savoir s’il se terminera un jour ou s’il faut simplement tuer le processus et le redémarrer. Je n’en ai tout simplement aucune idée, donc vous voulez des systèmes pour lesquels vous avez une très, très bonne idée du temps nécessaire pour terminer. D’ailleurs, si je reviens à Excel, de nos jours, lorsqu’une opération prend un certain temps pour s’exécuter, Excel vous fournit un indicateur assez fiable, une barre de progression qui vous indique le temps restant. Encore une fois, vous voulez, et c’est une partie de ce que j’appelle la préparation à la production, disposer de quelque chose de fiable, car, encore une fois, le logiciel que vous produisez fonctionnera très probablement en mode autonome, pendant la nuit ou lors d’un traitement batch nocturne, par exemple. Vous voulez quelque chose qui ne nécessite pas qu’un data scientist garde constamment un œil dessus.

Et encore, si vous avez le problème avec les data scientists, alors vous avez besoin d’une troisième compétence : expert en supply chain, expert en ingénierie logicielle, et maintenant expert data scientist. Il est possible de réunir ces trois qualités en une seule personne, mais bonne chance pour en recruter plus d’une par an, même si vous êtes une grande entreprise disposant de toutes ces compétences. C’est tout simplement extrêmement rare.

Nous voulons donc quelque chose qui va s’améliorer. D’ailleurs, la première chose à améliorer est la défense en profondeur. Les ransomwares sont en augmentation, et chaque fois que vous intégrez quelque chose de programmable dans votre organisation, vous vous exposez au ransomware. Car soudainement, lorsqu’un programme est présent, il peut réaliser une multitude d’actions, y compris détourner la machine sur laquelle il s’exécute. Je sais qu’il existe de nombreuses façons d’atténuer ces problèmes – vous pouvez utiliser des sandbox, restreindre, limiter les droits, et il y a plein de moyens de réduire les risques. Néanmoins, dès que vous utilisez un langage de programmation généraliste, votre surface d’attaque – un terme technique – devient absolument gigantesque.

En gros, chaque fois que vous introduisez ce type de code, vous vous exposez massivement à des problèmes de sécurité. Et souvenez-vous, la méthode usuelle dans une entreprise d’ingénierie logicielle est que le code est revu par les pairs. Ainsi, vous effectuez une revue de code : quelqu’un produit le code et un collègue le vérifie pour s’assurer qu’il n’y a aucune anomalie. Mais si je reviens au fait que le logiciel doit être robuste, vous devez pouvoir réagir en quelques heures. Du point de vue de l’optimisation de la supply chain, vous ne pourrez pas mettre en place un processus de revue de code. Cela n’est tout simplement pas compatible avec les délais et les situations d’urgence auxquels vous serez confronté.

Donc, vous devez disposer de quelque chose qui vous offre une défense en profondeur dès la conception. Ensuite, vous souhaitez avoir une performance transparente, où oui, les opérations peuvent prendre du temps, mais vous devez garder le contrôle. Vous devez savoir à l’avance combien de temps cela va prendre. Sans cela, vous vous exposez à une multitude de problèmes très stupides, comme disposer d’une fenêtre de deux heures pour livrer des résultats et être en retard. Et vous savez quoi ? Les camions sont déjà partis. Il est trop tard. Il faut donc avoir un système où tout est pris en charge.

Et il en va de même pour les mises à niveau transparentes. C’est là toute la beauté d’Excel. Vous n’avez pas à vous soucier de la maintenance d’Excel. Microsoft a signé un pacte de sang il y a des décennies, stipulant que, si vous avez produit une feuille de calcul Excel, quelle que soit la prochaine version d’Excel qui arrivera sur le marché, elle sera capable de supporter vos feuilles de calcul. Et le plus incroyable, c’est qu’aujourd’hui, Excel supporte de nombreux formats concurrents issus de fournisseurs qui n’existent même plus. Vous pouvez encore lire des feuilles de calcul produites avec Lotus Notes et ce genre de choses. La proposition de valeur de Microsoft en termes de mises à niveau transparentes est que la logique que vous avez produite fonctionnera toujours, et oui, ils continueront d’améliorer Excel pendant des décennies, mais vous savez quoi ? C’est pris en charge. Ce n’est pas ce que l’on observe avec la transition de Python 2 à Python 3 ; ce fut un cauchemar qui a duré une décennie. Ainsi, Python est excellent pour de nombreuses choses, mais imaginez simplement que ces mises à niveau surviennent aux pires moments, lors de la pire pandémie, du pire tarif, de la pire urgence, et que vous devez avoir tout opérationnel. Vous ne pouvez pas vous permettre une indisponibilité de six mois simplement parce que vous devez gérer une mise à niveau. Ce n’est pas compatible avec l’optimisation de la supply chain.

Il faut donc se demander ce qu’il se passerait si nous envisagions une solution réellement conçue pour la supply chain. Ce sera le sujet de la prochaine conférence.

De plus, la supply chain n’est pas la division informatique. Lorsque je parle d’une livraison orientée produit, ce n’est pas que le logiciel est simplement un moyen et non une fin. Vous ne vendrez pas votre logiciel sous licence ou contre rémunération, comme le fait, par exemple, Microsoft. Dans cette vision que je vous présente dans cette conférence, l’IT est responsable des pratiques fondamentales, des pratiques IT de base, telles que ce qu’il faut faire ou ne pas faire en matière de sécurité, de sauvegardes, d’infrastructure centrale, de réseau, de gestion et de synchronisation de toutes les données à l’échelle de l’entreprise, ainsi que de fournir conseils et coaching.

Mais l’idée est que la supply chain doit être responsable des décisions de la supply chain. Elle doit posséder l’ensemble du dispositif qui génère ces décisions supply chain, car c’est son cœur de compétence. Dans la conférence précédente, j’ai défini ce qui caractérise le Supply Chain Scientist : le Supply Chain Scientist est celui qui détient les décisions numériques produites par le code. Ce n’est pas un système qui génère des décisions ; ce sont des recettes numériques rédigées par un ou plusieurs Supply Chain Scientists, et ces Supply Chain Scientists détiennent collectivement ces décisions numériques. Ils en assument la responsabilité, et il incombe à la supply chain de s’assurer que toutes les décisions dans l’entreprise soient cohérentes. S’il y a une promotion en cours ou une grande campagne marketing, les éléments doivent être produits à temps afin d’être prêts à être servis. Vous ne voulez pas vous retrouver dans une situation catastrophique où vous lancez une promotion alors que vous êtes déjà proche d’une rupture de stock, où vous dépensez de l’argent pour une campagne marketing sur un produit que vous ne pouvez même pas vendre faute de stocks ou de capacité de fabrication, ou d’un service fourni dans les délais.

Nous avons donc deux divisions aux objectifs très différents. Dans ma vision idéale de ce que devrait être le département IT, le département IT n’est pas une division où l’on passe des tickets. Ce n’est pas ainsi que cela fonctionne. Le département IT est chargé de l’infrastructure centrale. C’est le genre de chose qui fonctionne de manière fluide en permanence. Vous n’y prêtez même pas attention, tout comme le Wi-Fi qui fonctionne. On ne remarque le Wi-Fi que lorsqu’il ne fonctionne pas. Un bon département IT fournit toute l’infrastructure de sorte que vous n’y pensiez même pas. Vous ne réalisez même pas qu’il existe, car cela fonctionne tout simplement, tout comme vos e-mails qui fonctionnent sans accroc, etc. C’est cela, une bonne informatique de base. Ensuite, l’IT est constitué de personnes qui viennent vous aider à instaurer toutes ces pratiques de soutien. La logique programmable est un peu compliquée, alors parfois, où trouver le coaching pour s’améliorer un peu en programmation ? Eh bien, la réponse est que cela devrait relever de l’IT. Ils ne devraient pas venir pour dire : “Nous allons programmer cela pour vous”, mais plutôt : “Nous allons vous coacher afin que vous puissiez l’implémenter vous-même. Nous vous aiderons avec quelques concepts, et peut-être avec certains aspects techniques un peu plus avancés.” Parfois, vous êtes confronté à une complexité accidentelle, donc l’IT est là pour vous soutenir. Mais fondamentalement, ils ne sont pas là pour faire le travail à votre place. Ils se doivent d’être des mentors et des coachs, veillant à ce que personne ne commette une erreur fatale pouvant exposer l’ensemble de l’entreprise à un risque de ransomware ou à un risque systémique du point de vue IT.

À titre de test révélateur, si vos interactions entre l’IT et la supply chain se font par le biais de documents listant spécifications ou exigences, ce n’est pas la manière adéquate d’entretenir une bonne relation entre ces deux divisions. Quand je parle d’une bonne relation, j’entends quelque chose qui apportera réellement de la valeur à l’entreprise.

En conclusion, nous avons deux défis du côté de la gestion traditionnelle de la supply chain, qui se contentait peut-être de programmer avec des feuilles de calcul Excel, sans même réaliser au départ que c’était déjà une forme de programmation. Vous devez surmonter vos peurs. Vous devez concevoir que le monde de demain, votre division, sera chargée de livrer un produit fonctionnant tel un produit logiciel, et cela représente un changement énorme. Oui, mais c’est quelque chose dont vous pouvez vous occuper. Pourquoi ? Parce que si vous disposez des bons outils, il y a certes de la programmation impliquée, mais ce n’est pas fondamentalement, radicalement plus difficile qu’Excel. Encore une fois, le défi ne réside pas dans la technicité de l’outil ; il se trouve littéralement dans la complexité de la supply chain elle-même. Le problème est difficile non pas parce que votre outil est difficile à manipuler, mais parce que vous avez une supply chain compliquée dès le départ.

Pour la partie de l’audience qui est peut-être plus du côté des data scientists ou du côté IT, ce que vous devez surmonter, c’est l’excès de confiance. J’ai vu, maintes et maintes fois, des data scientists – et je m’inclus dans cette catégorie – qui étaient trop confiants quant à leur capacité à faire passer un prototype en production. C’est difficile, et les supply chain ont une façon de vous exploser à la figure de la manière la plus surprenante. Je ne me rappelle qu’une anecdote où, il y a quelques années, nous avons commencé avec un leader européen du le e-commerce de pièces détachées automobiles. Nous gérions leurs réapprovisionnements de pièces grâce à notre technologie de prévision des séries temporelles, en faisant des suggestions pour le réapprovisionnement, en servant des pièces automobiles. La semaine suivante, nous avons constaté que toutes nos prévisions étaient faussées par un facteur deux. La demande avait doublé. Ce qui s’était passé, c’est que leur concurrent numéro un avait décidé de s’implanter dans plusieurs pays en même temps, littéralement au moment où nous lancions notre prévision, et qu’au même instant, l’un des concurrents avait décidé d’apparaître sur toutes les télévisions nationales pour commencer à diffuser leur service en ligne. Ce qui est intéressant, c’est que mon client n’était même pas au courant, et qu’ils bénéficiaient de meilleurs résultats en SEO. Ils étaient plus optimisés en termes de SEO, donc en gros, les gens voyaient la publicité télévisée du concurrent, mais ils ne se souvenaient pas naturellement du nom du concurrent. Alors, ils allaient sur Google et tapaient “pièces automobiles” jusqu’à se retrouver sur le site web de mon client. Pour démontrer à quel point Lokad était génial, la première semaine où nous avons démarré, nous étions à côté d’un facteur deux, et nous nous demandions : “Mais qu’est-ce qui se passe ?”. Nous avons dû tout revoir, car lorsque vous constatez que la demande double, ce n’est pas que tout double ; certaines choses font 10 fois plus, et beaucoup d’autres restent inchangées.

Voilà ce genre de situation, et vous devez être capable de réagir rapidement. C’est une question de peur et d’excès de confiance. Merci beaucoup pour votre temps.

Maintenant, je vais jeter un coup d’œil aux questions dans le chat.

Question: Le logiciel peut-il prendre la décision concernant quel fournisseur choisir pour passer une commande supplémentaire en cas de besoin pour demain ? Par exemple, des barquettes de 200 grammes de fraises dans des bureaux en Australie peuvent avoir 10 fournisseurs livrant les mêmes produits au centre de distribution le même jour.

Absolument, et ici nous devons différencier les deux volets de la gestion de la supply chain et de l’optimization de la supply chain. Il y a le volet de gestion de la supply chain, qui consiste littéralement à disposer de tous les data pipelines en place, y compris EDI, où vous pouvez transmettre une commande électronique à un fournisseur sans aucune intervention humaine. Ainsi, vous disposez d’un pont électronique de bout en bout. Mais cela signifie ensuite que vous devez avoir, du côté de l’optimization, un logiciel qui fonctionne en continu tout au long de la journée et qui, à un moment donné, peut notifier le côté gestion en disant : “Veuillez exécuter cette commande.” Puis, du côté gestion, qui sera pris en charge par le département IT, on s’assure simplement que cette commande est complètement exécutée. Il s’agit uniquement d’une question de pure transactionnalité ; il n’y a plus d’intelligence. Vous avez reçu une commande indiquant “cette quantité”, et c’est le côté d’optimization qui est responsable de s’assurer qu’en générant une certaine quantité, vous respectez toutes les contraintes, telles que la liste exacte des fournisseurs même éligibles à servir ces produits, s’ils ont encore des stocks, et comment faire le bon choix parmi tous les fournisseurs concurrents, etc. Il peut se passer de très nombreuses choses. Absolument, oui, mais nous devons littéralement séparer l’exécution banale, qui est la partie transactionnelle relevant de la gestion de la supply chain, de l’ingrédient d’optimization au moment où vous décidez qu’il faut réapprovisionner davantage.

Question: Savez-vous que vous êtes en concurrence avec les eSports World Championships en ce moment ?

Non, je ne suis pas en concurrence avec ces championnats d’eSports en ce moment, mais c’est très cool. D’ailleurs, chez Lokad, nous jouons fréquemment à Dota 2, donc l’équipe de gestion y participe également. Certains de nos employés veulent jouer à League of Legends, mais en tant que CEO de l’entreprise, je désapprouve fermement.

Question: J’ai constaté que de nombreuses entreprises n’ont pas de ERP ou de WMS au départ, et que la gestion travaille sur l’optimization de la supply chain.

Eh bien, absolument. Vous ne pouvez pas éviter l’optimization de la supply chain dès le premier jour ; il faut prendre ces décisions. L’optimization de la supply chain existait déjà avant que tout type de logiciel de gestion de la supply chain ne soit mis en place. Même en remontant 60 ans en arrière, à une époque où il n’y avait pas de logiciel, les gens devaient quand même prendre des décisions. Ainsi, l’optimization de la supply chain était déjà une réalité ; les gens s’en occupaient avec du papier et un stylo. Si vous regardez les premiers travaux sur la supply chain, tels que la formule de Wilson, également connue sous le nom de formule EOQ, elle a un siècle d’existence. Elle précède clairement le logiciel. Donc oui, l’optimization de la supply chain est quelque chose qui existe dès le premier jour, que vous ayez un logiciel dans votre organisation ou non.

Maintenant, en effet, vous devez disposer de systèmes IT appropriés, mais c’est un état d’esprit complètement différent. La gestion de la supply chain consiste à réaliser très efficacement des tâches banales, telles que la saisie de données, éventuellement avec le support de codes-barres et d’autres éléments. Il s’agit simplement de représenter les données de façon routinière. Le problème, c’est que les gens veulent quelque chose qui fasse à la fois la gestion de la supply chain et l’optimization de la supply chain, et par conséquent, vous vous retrouvez avec un produit trop compliqué, généralement bourré de bugs, et vous devez intégrer de mauvaises fonctionnalités comme des alertes et des exceptions, que vous devriez éviter. Je reviendrai sur ce point dans une conférence ultérieure.

Fondamentalement, de nos jours, déployer un WMS ou un ERP – si vous n’en avez pas déjà un – se fait en quelques semaines. Si vous en avez déjà un, cela peut prendre quelques mois si vous devez démêler cette affaire de vos décisions.

Question: Quand la direction de l’entreprise se rend-elle compte qu’il est temps de passer du suivi de l’information à l’optimisation des décisions supply chain et, éventuellement, de commencer à se concentrer sur l’optimization de la supply chain ?

La première chose, c’est qu’il faut d’abord se rendre compte qu’il y a deux problèmes, et qu’un même logiciel ne pourra jamais adresser ces deux volets. Je pense que c’est la grande illusion, et les éditeurs de logiciels ont été incroyablement confus dans ce domaine. Si vous regardez les plus grands éditeurs d’ERP, leur message porte sur l’optimization de la supply chain, mais tout ce qu’ils livrent réellement et toutes les fonctionnalités de leur produit se situent du côté de la gestion de la supply chain, qui est beaucoup moins sexy car il n’y a ni IA ni intelligence réelle. Dans le monde du logiciel, on parle d’applications CRUD (Créer, Lire, Mettre à jour, Supprimer). Les ERP sont simplement d’énormes collections d’écrans CRUD où chaque écran permet de créer, lire, mettre à jour ou supprimer des lignes d’une base de données relationnelle, et c’est tout. Un ERP est, pour simplifier un peu, une collection de milliers de tables pour diverses entités. Pour chaque entité pouvant être regroupée logiquement, vous avez un ou deux écrans, et c’est tout. Donc, pour revenir à votre question sur la direction, le problème est que, si vous êtes un manager, vous lisez la brochure de l’éditeur d’ERP, et celui-ci vous affirme que ce produit va optimiser votre supply chain. La réponse est : non, absolument pas. Ce qu’il va faire, c’est améliorer la productivité et assurer une comptabilité exacte de votre supply chain. C’est déjà beaucoup, car cela peut réduire considérablement le vol, les pertes, les marchandises égarées, et améliorer la productivité grâce aux codes-barres pour un entrepôt. Ces produits apportent une valeur ajoutée importante. Je ne minimise pas la valeur qu’un ERP ou un WMS apporte, elle est énorme, mais il ne s’agit pas d’optimization de la supply chain. Un WMS, par exemple, est conçu pour se concentrer sur l’entrepôt ; il ne se préoccupe pas de la supply chain dans son ensemble qui inclut clients et fournisseurs. Il est par nature focalisé sur des emplacements spécifiques, et non sur l’ensemble de la chaîne.

Question: Comment peut-on passer en douceur de Python à Envision ou les faire fonctionner ensemble ?

Historiquement, nous les avons fait fonctionner ensemble dans quelques situations. Pour le public, Envision est un langage de programmation spécifique à un domaine, conçu par Lokad, qui a été développé uniquement pour la predictive optimization des supply chains. Lors de la prochaine conférence, je ferai une démonstration d’Envision afin que chacun puisse mieux comprendre de quoi je parle, avec de vrais extraits de code.

Historiquement, nous avons utilisé Python et Envision ensemble parce qu’au début, Envision avait des capacités très limitées, si bien qu’il manquait de nombreuses fonctionnalités, et que, dans de nombreuses situations, nous revenions par défaut à Python. Au fil des ans, nous avons progressivement étendu les capacités d’Envision, ce qui nous a permis d’éliminer graduellement le besoin d’avoir des composants Python. Il ne s’agit pas seulement de composants Python ; c’est aussi une série d’outils qui doivent être interconnectés, comme Airflow.

D’ailleurs, la syntaxe d’Envision a été volontairement alignée sur celle de Python à bien des égards. J’ai fait le choix conscient de concevoir la syntaxe d’Envision de manière à ne pas être en opposition avec les programmeurs Python, pour que, si vous connaissez Python, vous puissiez apprendre Envision en une semaine. Elle diffère de manière subtile et profonde, mais au niveau syntaxique, de nombreux aspects sont identiques. Python a de nombreux mérites, comme sa simplicité et la pureté de son design. Même si je dis que Python ne coche pas toutes les cases et qu’il crée des problèmes graves en production qui ne peuvent être surmontés, cela ne signifie pas que Python est dépourvu de mérites. Ce n’est pas ce que je veux dire. Je crois que Python a de nombreux atouts. Encore une fois, nous parlons spécifiquement de la manière de faire fonctionner des supply chains en production, ce qui est un problème très particulier.

Question: Comment feriez-vous comprendre à un client que son ERP n’optimise rien ?

C’est très difficile car, franchement, le pire des cas, c’est lorsqu’un prospect vient à moi en disant : “Notre ERP, un ERP hérité, ne délivre aucune valeur, et maintenant nous voulons passer au prochain ERP qui offre l’optimization de la supply chain.” C’est une situation terrible pour moi, car je dois expliquer au client que ce qu’il recherche n’est pas un seul produit, mais deux : l’un qui remplacera son ERP et gérera mieux le côté gestion, et l’autre qui se chargera de l’optimization.

Quand on pense à ces ERP hérités, j’ai beaucoup de respect pour eux, en particulier ces produits AS/400 dotés d’un terminal en ligne de commande sur de vieux mainframes IBM. Du côté gestion, ils font généralement un travail très correct. Ce que les clients recherchent réellement, c’est peut-être une interface web plutôt qu’une ligne de commande, mais est-ce que cela rendra leurs équipes sur le terrain plus productives ? Je le conteste. Les lignes de commande avec des terminaux textuels peuvent être incroyablement réactives et productives, sans aucune distraction.

C’est donc assez difficile parce que nous devons démêler toutes les inepties propagées par nos concurrents. De plus, nous devons expliquer que l’ERP ne va pas optimiser la supply chain et qu’il n’existe pas de véritable IA ni de blockchain, seulement des catégories de modèles statistiques. Malheureusement, nous perdons la majorité de nos prospects à ce stade. C’est l’une des raisons pour lesquelles je donne ces conférences, car il faut des heures pour aller au fond du problème et expliquer pourquoi nous devons voir la situation telle que je la conçois.

Question: Quelle est votre recommandation pour une plateforme permettant de gérer la complexité de la planification de plusieurs produits avec une distribution probabiliste de la demande ?

Eh bien, Lokad, bien sûr. Mais gardez à l’esprit qu’étant le CEO de Lokad et le principal actionnaire de l’entreprise, j’ai un conflit d’intérêts, à mon avis. Je suis profondément convaincu que Lokad est la plateforme qu’il vous faut, mais comprenez bien que c’est aussi l’entreprise que je possède et dirige. Je ferai de mon mieux pour rester objectif à ce sujet.

D’ailleurs, Lokad a été littéralement conçu pour gérer la distribution probabiliste de la demande, et ce n’est pas seulement cette distribution. Il prend également en compte la distribution stochastique des lead time, la distribution stochastique des retours, et bien plus encore. Nous devons envisager tous les futurs possibles avec des probabilités, en considérant tous les types d’incertitudes. La demande est un élément très important, généralement le plus important, mais ce n’est pas le seul.

Je pense avoir traité toutes les questions. Je vérifie juste si j’ai manqué quelque chose… Aucune question supplémentaire. Alors, merci à tous d’avoir regardé cette conférence, et à la semaine prochaine, même jour, même heure. À bientôt. Au revoir.

Références

• Joel on Software : Et sur divers sujets occasionnellement liés qui pourraient intéresser les développeurs de logiciels, les designers et les managers, ainsi que ceux qui, que ce soit par chance ou par malchance, travaillent avec eux d’une manière ou d’une autre - Par Joel Spolsky, 2004