Livraison orientée produit pour la Supply Chain - Cours 1.3

00:22 Introduction
02:40 Pourquoi un produit ? Parce que le capitalisme
08:18 Que devrait faire le produit ?
10:05 Les déséconomies d’échelle des logiciels
12:50 Achetons un produit SCO tout fait
21:58 SCM vs SCO
25:58 Interlude
28:21 SCO n’est pas un produit logiciel ordinaire
33:26 Les ingrédients logiciels pour SCO
42:49 Pourtant, les feuilles de calcul ne sont pas l’objectif final
46:51 Python n’est pas non plus l’objectif final
58:52 La SC n’est pas une division de l’informatique
01:03:19 En conclusion, deux défis à relever
01:07:04 Prochain cours et questions du public

Description

L’objectif d’une initiative de Supply Chain Quantitative 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, les mises à jour de prix). L’application est considérée comme un produit à concevoir. La théorie de la supply chain est là pour nous aider à livrer une application qui oriente l’entreprise vers des performances en matière de supply chain, tout en étant compatible avec toutes les contraintes que la production implique.

Transcription complète

Bonjour à tous, merci beaucoup de vous joindre à cette série de cours sur la supply chain. Je suis Joannes Vermorel et je vais présenter “Livraison orientée produit pour l’optimisation de la supply chain”.

Donc, tout d’abord, lorsque je parle d’un produit, je veux dire un produit logiciel. Pour ceux d’entre vous qui ont déjà eu le privilège d’explorer ce qui se cache derrière un logiciel d’entreprise moderne, cela peut être une expérience assez intéressante.

Pour ceux qui connaissent le travail de H.P. Lovecraft, il y a quelques similitudes troublantes. Lovecraft a produit une série de romans, et l’un des thèmes récurrents est l’idée de la connaissance interdite. Ce n’est pas que l’univers ne peut pas être connu, il le peut. C’est juste que la seule chose qui préserve l’humanité est l’ignorance. L’ignorance n’est pas un problème ; c’est la chose même qui nous protège d’un univers trop terrifiant pour nos esprits. 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 ont des points de santé mentale. Si vous faites certaines choses qui endommagent votre santé mentale, vous perdez des points de santé mentale. 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 exigences pour ajouter de la valeur à l’entreprise. Alors, continuons.

Pourquoi un produit, et en particulier, un produit logiciel ? Jetons un coup d’œil de près à la façon dont les supply chains fonctionnent traditionnellement. Traditionnellement, il y avait beaucoup de personnes sur le terrain qui déplaçaient des choses, manipulaient des colis, conduisaient des véhicules et effectuaient tout le travail manuel. Il y avait aussi beaucoup de personnes impliquées dans la production, ainsi que dans les magasins. Ce qui s’est progressivement passé au cours des dernières décennies, c’est que le nombre de personnes ayant des emplois ouvriers a diminué régulièrement. De nos jours, du point de vue de la production, les choses sont largement automatisées. Il y a encore quelques industries, comme le textile, où il est difficile d’automatiser tout, c’est pourquoi ces industries se sont déplacé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.

Vous vous retrouvez dans une situation assez étrange où, si vous regardez vers l’avenir avec l’arrivée imminente des véhicules autonomes, de nombreuses entreprises auront plus de travailleurs de col blanc qui traitent des feuilles de calcul Excel pour gérer la supply chain que de personnes en bleu de travail sur le terrain pour effectuer les opérations de travail manuel. C’est à cela que je fais référence lorsque je parle de travail de bureau.

Un autre aspect particulier est que les supply chains ont été numérisé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 ; les supply chains sont déjà pilotées et exploitées via des logiciels. Mais lorsque nous examinons le rôle des humains dans ces systèmes logiciels, les humains sont littéralement utilisés comme co-processeurs humains dans votre système de supply chain moyen. Il existe des types spécifiques d’opérations que le processeur régulier de la machine ne peut pas effectuer, et donc toute la tâche est déléguée à un humain. En conjonction avec des recettes numériques simplistes, telles que l’analyse ABC, l’inventaire min-max et des recettes similaires, les humains passent leur journée à éteindre des incendies. Ils sont toujours confrontés à des exceptions et à des conditions qui ne correspondent pas au cadre standard.

D’un point de vue financier, tout cela représente des dépenses opérationnelles (OpEx). Vous devez payer une armée de commis chaque jour pour gérer toutes les décisions banales 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 de nombreuses autres décisions routinières. Ce sont les humains qui prennent ces décisions et qui éteignent les incendies pour faire face aux lacunes des décisions automatiques générées naïvement par le système.

Ma proposition pour vous aujourd’hui est que nous voulons passer des dépenses opérationnelles (OpEx) aux dépenses en capital (CapEx). C’est tout l’intérêt de cette livraison axée sur le produit. Nous voulons construire un actif, et pourquoi ? Parce que c’est capitaliste. Si vous regardez les 100 entreprises les plus rentables du monde de nos jours, la moitié d’entre elles, en termes de profit, sont des entreprises de logiciels. Elles représentent l’essence des entreprises ultra-capitalistes, où vous avez un investissement initial, puis vous obtenez un dispositif ou un artefact qui génère une valeur ajoutée avec un investissement marginal minimal.

Revenons au sujet de ma précédente conférence, nous avons besoin de robotisation pour remettre la gestion sous contrôle. L’automatisation et les humains devraient travailler ensemble ; les humains ne devraient pas être là pour faire face aux lacunes des politiques d’inventaire stupides comme le min-max. Au lieu de cela, ils devraient être là pour ajouter de la valeur, améliorer les recettes numériques et agir en tant que stratèges. Il y avait un ancien slogan d’IBM qui disait : “Les machines devraient travailler ; les gens devraient penser.” C’est le genre de réflexion qui sous-tend cette présentation. Nous voulons transformer la supply chain en un actif capitaliste, et pour cela, nous devons transformer la supply chain en une machine qui livre un produit logiciel.

Que fait réellement ce produit ? Il s’avère qu’il fait quelque chose de assez simple : il prend des décisions. Pas des décisions arbitraires et ouvertes, mais des décisions banales et routinières comme quoi produire, combien d’unités acheter à un fournisseur et combien d’unités déplacer d’un endroit à un autre. À première vue, il peut sembler qu’il y ait de nombreuses décisions impliquées dans la gestion de la supply chain. Cependant, lorsque vous examinez les tâches, même les supply chains les plus complexes ne nécessitent qu’une poignée de types de décisions à prendre chaque jour. Ce n’est pas écrasant, et c’est tout à fait raisonnable en termes du nombre de fonctionnalités. De manière intéressante, ces décisions sont largement exclusives, il y a donc des limites à ce qui peut être fait en utilisant une approche de division et de conquête. Une fois que vous avez décidé d’acheter 100 unités à un fournisseur, vous ne pouvez pas avoir un autre sous-système qui décide d’acheter 200 unités à la place. À un moment donné, vous devez vous 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 dans leur portée et largement exclusives. Ce que nous voulons, c’est un logiciel qui génère des décisions de commande de manière entièrement automatisée chaque jour.

Une chose que je crois 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 des gens, il en va tout autrement dans le domaine des logiciels, où l’ajout d’un quart de fonctionnalités supplémentaires peut doubler les coûts. Ce concept explique pourquoi les petites startups peuvent rivaliser avec les grandes entreprises - parce qu’elles se concentrent sur une fraction plus petite de fonctionnalités, le coût de mise sur le marché de leur produit peut être considérablement inférieur à celui d’une grande entreprise.

Avec l’idée de déséconomies d’échelle à l’esprit, nous devons décider si nous devons construire, acheter ou adopter une autre approche pour notre produit d’optimisation 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 fournir pour servir le marché.

Alors, envisageons d’acheter un produit d’optimisation de la supply chain prêt à l’emploi. Sur 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 de cela, car lorsque j’ai créé Lokad en 2008, j’ai commencé avec un petit produit logiciel orienté davantage vers les prévisions que vers l’optimisation 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 manquantes. Cela semblait être un processus sans fin de découverte de nouveaux besoins.

Jetons un coup d’œil aux fonctionnalités de base. Tout d’abord, nous avons des entreprises qui sont B2C ou B2B, qui présentent des modèles de gestion de la supply chain complètement différents. Par exemple, les entreprises B2B ont généralement moins de clients, mais ces clients commandent des quantités beaucoup plus importantes. Cela crée différents types de risques, tels que le risque de perdre un seul client qui représente une part importante du chiffre d’affaires de l’entreprise. Ensuite, il y a des modèles d’entreprise plus complexes comme B2B2C ou B2B2B.

Prenons en compte les différents types de sites à couvrir, tels que les magasins, les entrepôts et les installations de production. Chaque type de site présente ses propres défis. Les magasins, par exemple, sont sujets aux inexactitudes des 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 exploitations minières, présentent leurs propres problèmes spécifiques et incertitudes quant au rendement de la production.

Les réseaux de la supply chain peuvent avoir différents niveaux, ou échelons, allant des systèmes à un seul échelon aux systèmes à plusieurs échelons. La complexité de la gestion de la supply chain augmente considérablement à mesure que le nombre d’échelons augmente. La topologie du réseau est un autre aspect important à prendre en compte. 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 à 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, fondamentalement, ce n’est pas seulement un arbre en termes de graphes, cela 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, ce qui se produit chaque fois que des réparations sont nécessaires. Par exemple, dans l’industrie minière ou l’industrie de l’aéronautique, il y a des tonnes de boucles de réparation avec des équipements réparables.

Maintenant, l’inventaire lui-même n’a pas qu’une seule nature ; il varie beaucoup. Vous ne pouvez pas simplement dire : “Oh, j’ai cette idée que j’ai des SKUs et c’est tout.” Non, pas tout à fait, car d’abord, vous avez des matières premières qui sont littéralement mesurées en quantités comme des grammes, des kilogrammes ou du volume. Ensuite, vous avez les unités qui sont les belles unités propres, qui sont principalement prévalentes. Mais ensuite, vous pouvez également avoir beaucoup d’inventaire qui se produit très fréquemment, par exemple, dans l’industrie pharmaceutique ou dans l’industrie alimentaire, où le lot est livré avec des dates d’expiration spécifiques. Ensuite, vous pouvez même avoir un inventaire complètement sérialisé, où chaque unité a son propre numéro de série. En termes d’optimisation de la supply chain, cela change complètement la donne, donc c’est un problème complètement différent lorsque vous regardez chacune de ces choses.

Ensuite, évidemment, vous avez tous les problèmes des places de marché. Chez Lokad, nous avons des clients dans toutes les situations possibles. Nous avons des clients qui vendent sur une place de marché tierce, ils peuvent avoir leur propre place de marché, ou ils peuvent avoir les deux. Cela peut être quelque chose de secondaire pour qu’ils puissent l’utiliser pour liquider les choses qu’ils n’ont pas vendues. Il y a de nombreuses situations.

Maintenant, juste pour donner un exemple, réfléchissez un instant à ce qu’est une commande. Vous avez la commande immédiate, où fondamentalement vous achetez quelque chose directement au comptoir, et c’est à vous. Mais vous pouvez aussi avoir une commande qui dit : “Je l’achète, mais je ne veux pas que cette chose soit livrée immédiatement ; je veux qu’elle soit livrée dans un mois.” Évidemment, d’un point de vue d’optimisation de la supply chain, c’est un jeu complètement différent car si vous savez à l’avance que vous devrez livrer une certaine quantité de choses à une date spécifique, vous ne voulez pas le prévoir, donc c’est une chose complètement différente.

Et puis vous avez une commande configurée, et c’est, par exemple, lorsque vous achetez un ordinateur en ligne et vous pouvez choisir la quantité de mémoire, la quantité de disque dur, le type de système d’exploitation, la langue qui sera configurée pour votre ordinateur, et quel sera votre clavier, entre autres choses. Donc, vous pouvez avoir un configurateur massif, et cela change à nouveau le paysage. Cela se produit également pour des choses comme les vélos ou les voitures et change complètement le paysage lorsque vous avez ce genre de choses car cela vous donne des options et des façons de regarder le problème d’optimisation de la supply chain qui sont complètement différentes.

Même pour les prix, vous pouvez avoir le prix unitaire qui est fixe, très simple et très linéaire, mais ce n’est pas la seule chose. Vous pouvez avoir des réductions de prix, par exemple, si vous achetez dix unités, alors vous obtenez une réduction. Ou vous pouvez avoir des programmes de fidélité où certains clients avec une carte de fidélité peuvent obtenir une réduction, mais seulement sur certains types de produits ou seulement en fonction de certaines conditions. Et puis, même en B2B, il y a des choses très fréquentes qui sont négociées, donc c’est littéralement une transaction où beaucoup de choses seront vendues, mais vous avez un prix catalogue régulier. Cependant, un fournisseur peut accorder une remise à un client parce qu’il est important, et c’est juste comme ça que ça se passe. En fin de compte, je n’ai à peine parlé que quelques minutes maintenant, et je n’ai même pas encore abordé les choses indispensables. Alors, faites une pause un instant et essayez de réfléchir à quoi ressemblera un logiciel d’entreprise prêt à l’emploi qui est censé fournir une optimisation de la supply chain. Le nombre de fonctionnalités à couvrir est tout simplement insensé, et lorsque vous essayez de réfléchir à la façon de rassembler toutes ces choses en un monolithe, vous perdez littéralement la raison. Nous en revenons à cette idée que ce n’est pas que l’univers ne peut pas être connu, c’est juste que si vous êtes exposé à la vérité nue de l’univers, vous perdez votre santé mentale.

Donc, nous avons un gros problème, et ici nous devons différencier la gestion de la supply chain de l’optimisation de la supply chain. C’est une distinction que j’ai déjà introduite dans l’une de mes conférences précédentes. Il y a une grande confusion entre le côté gestion et le côté optimisation. La gestion concerne la comptabilité, le soutien des flux de travail et principalement les processus de saisie de données. Si vous voulez représenter toutes les choses que je viens de décrire, il y a beaucoup de terrain à couvrir, mais c’est faisable. Un ERP “obèse” peut le faire. Oui, vous vous retrouverez avec 10 000 tables, ce sera assez moche, mais c’est possible. Mais ne vous y trompez pas, l’ERP (qui devrait s’appeler ERM, Enterprise Resource Management) ne fera pas grand-chose. Il se contentera simplement de suivre ces choses. Vous aurez donc des tonnes d’entités - MOQs, vérification ; réductions de prix, vérification ; magasins, vérification ; entrepôts, vérification - mais vous n’avez pas besoin d’avoir un quelconque degré d’intelligence. Il s’agit simplement de contreparties numériques banales pour refléter les données, rendant possible la saisie des données dans le système, et c’est tout.

C’est possible parce que, ici, nous pouvons tricher un peu avec cette règle de “un quart de fonctionnalités en plus double le coût”. Il y a quelque chose que je n’ai pas vraiment dit à ce sujet : cela fonctionne si vous gardez vos fonctionnalités complètement séparées. Tant que les fonctionnalités n’interagissent pas les unes avec les autres, c’est bon ; vous n’êtes pas soumis à cette malédiction des déséconomies d’échelle. Du point de vue de la saisie de données, il n’y a pas de problème. Vous n’avez pas besoin d’avoir l’interface utilisateur qui vous permet de gérer les MOQs connectés à ce qui vous permet d’ajouter un magasin supplémentaire au réseau. Ces deux choses peuvent être complètement séparées.

Cependant, en ce qui concerne l’optimisation de la supply chain, il en va autrement. Si vous avez des MOQs, cela aura des implications profondes sur la fréquence de vos commandes, sur la fréquence à laquelle vous livrerez des choses de votre entrepôt à vos magasins. Il y a de nombreuses conséquences importantes. Vous ne pouvez pas séparer les choses car, en fin de compte, votre supply chain n’est qu’un système où tout a une influence sur tout. Donc, d’un point de vue d’optimisation de la supply chain, vous avez littéralement le problème que toutes ces choses doivent être connectées si vous voulez obtenir une optimisation, et c’est là que les choses se dégradent.

Du côté de la gestion, vous pouvez éventuellement vous retrouver avec un produit. Cependant, pour l’optimisation de la supply chain, la réponse est que vous ne pouvez pas. Je veux dire, vous pouvez faire semblant, mais littéralement, vous ne pouvez pas. Même chez Lokad, qui a commencé non pas comme une entreprise de prévision de la supply chain spécialisée dans l’optimisation prédictive de la supply chain, mais plutôt comme une prévision en tant que service. Si vous revenez sur le blog de Lokad en 2008, j’ai commencé initialement avec la prévision des séries temporelles, ce qui était gravement erroné. Néanmoins, c’est ainsi que j’ai commencé. Même pour la prévision des séries temporelles, qui est un tout petit sous-ensemble du problème global, c’est ingérable. C’est ma conclusion après avoir travaillé dans ce domaine pendant plus de 12 ans.

Si nous devons revenir au monde spécifique de la production de logiciels, c’est quelque chose de très unique. À moins d’avoir été formé en tant qu’ingénieur logiciel vous-même et de connaître le fonctionnement des grandes entreprises de logiciels à succès, il y a de fortes chances que vous en sachiez très peu à ce sujet. Il s’avère que c’est un monde très spécifique avec de nombreux aspects totalement contre-intuitifs. Les entreprises traditionnelles, en particulier celles qui ont une mentalité d’ingénierie mécanique classique ou une mentalité marketing, ont énormément de mal à comprendre comment fonctionne le logiciel.

Nous aborderons ces aspects plus en détail dans les prochaines conférences, mais il y a un livre que j’aime beaucoup, écrit par Joel Spolsky, un ancien employé de Microsoft qui a travaillé sur les premières équipes de Microsoft Excel. Il est également le co-fondateur de Stack Overflow et de Trello. En 2004, lorsque j’étais encore étudiant, j’ai lu son livre et son blog. Le livre s’intitule “Joel on Software” et il vous donne de manière humoristique une idée de ce à quoi ressemble la gestion d’une entreprise de logiciels réussie. C’est très différent de ce à quoi la plupart des gens en dehors de cette industrie s’attendent. Je vais ajouter les détails de ce livre dans la description de la vidéo.

Mais gardons à l’esprit que l’optimisation de la supply chain n’est pas un produit logiciel ordinaire. Habituellement, lorsque vous traitez avec un produit logiciel ordinaire - je veux dire, oui, vous avez des comportements adverses, selon le type de produit logiciel. Si vous traitez avec un réseau social, vous pouvez avoir beaucoup de personnes qui publient du contenu haineux, ce qui est un tout autre jeu. Cependant, lorsqu’il s’agit de logiciels d’entreprise classiques, tels que Microsoft Word ou Excel, il s’agit d’un produit pour lequel vous souhaitez avoir la bonne conception, mais il n’y a aucune urgence. Dans le cas des produits logiciels traditionnels, il est acceptable de passer des années à peaufiner votre conception et votre produit. C’est un investissement à long terme et vous devez regarder des décennies à l’avance. Il n’y a aucune raison de se précipiter en termes de développement. Cependant, l’optimisation de la supply chain ne fonctionne pas comme ça. Vous n’avez pas le choix, car les choses se produisent tout le temps et le terrain est très accidenté.

Vous pouvez avoir 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 tirer le meilleur parti des capacités dont vous disposez encore. Vous pouvez être confronté à une immobilisation de la flotte en raison d’incidents tragiques, à des décisions politiques telles que des tarifs qui perturbent votre stratégie, ou à des catastrophes naturelles comme des tsunamis, des incendies et des vagues de chaleur, comme ceux de Californie ou d’Australie. Ces événements se produisent et lorsque cela se produit, vous devez être en mesure de réagir littéralement en quelques heures.

Vous avez votre produit logiciel, mais vous devez apporter des changements, et vous voulez apporter des changements programmables. Rappelez-vous, si vous êtes dans l’état d’esprit de livrer un actif logiciel, vous avez une petite équipe qui pilote le logiciel qui, à son tour, pilote votre supply chain. Vous n’avez pas une armée de commis qui lutte contre les incendies toute la journée. Même si vous avez une armée de commis, vous devez les former et lorsque quelque chose d’inattendu se produit, vous vous retrouvez avec une armée qui n’a pas été formée pour cette situation spécifique. Dans mon expérience, plus vous avez de personnes à gérer, plus il faut de temps pour accomplir quoi que ce soit.

Il y a quelques jours à peine, un navire cargo a perdu plus de 1 800 conteneurs en raison de mauvaises conditions météorologiques. Ces choses arrivent tout simplement et vous ne pouvez pas espérer les éliminer. La supply chain n’est pas comme la fabrication, où vous pouvez avoir un site de production avec tout sous contrôle strict. 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 échappent à votre contrôle que vous devez être capable de faire face à des événements surprenants. Vous savez déjà que des surprises vont se produire, vous devez donc être préparé. Être préparé ne consiste pas à tout planifier soigneusement ; il s’agit d’avoir un système où vous pouvez réagir en quelques heures si nécessaire. C’est l’essence de ce que vous pouvez faire pour aborder le problème de manière réaliste.

Maintenant, de quels ingrédients logiciels avons-nous besoin pour l’optimisation de la supply chain ? Tout d’abord, nous avons besoin d’un stockage de données polyvalent pour représenter tous les types divers de sources de données. Il y a tellement de choses que nous voulons représenter, nous voulons donc quelque chose de très polyvalent à cet égard, avec beaucoup de structure et de variété.

Deuxièmement, vous voulez de la logique programmable. Je reviens à cette idée : si vous n’avez pas de logique programmable, comment faites-vous face à tous ces problèmes ? Comment assemblez-vous toutes ces choses ? Vous ne pouvez pas acheter un produit tout fait qui aura tout préprogrammé pour vous ; ça ne fonctionne pas.

Ensuite, vous avez besoin d’interfaces utilisateur polyvalentes car la façon dont vous voulez examiner vos problèmes variera énormément d’une situation à l’autre. Les KPI seront complètement différents d’une entreprise à l’autre, vous avez donc besoin d’une interface utilisateur polyvalente où vous pouvez présenter les chiffres de la manière qui vous convient le mieux ; sinon, cela va être une grande limitation.

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

Enfin, et peut-être de manière plus controversée, vous voulez des capacités programmables accessibles aux personnes qui ne sont pas des ingénieurs logiciels formés. C’est important pour plusieurs raisons. Tout d’abord, il n’y a pas beaucoup d’ingénieurs logiciels formés sur le marché du travail, il est donc très compétitif de les embaucher. Deuxièmement, il faut tellement d’efforts et de dévouement pour devenir un ingénieur logiciel talentueux qu’il est difficile d’être simultanément un spécialiste de la supply chain.

Il est assez rare de trouver des personnes qui ont des compétences doubles dans les deux domaines. Il en va de même si vous recherchez quelqu’un qui est à la fois programmeur et avocat, ou programmeur et médecin. Oui, vous trouverez des personnes avec ces compétences, mais pouvez-vous le faire à grande échelle ou embaucher plus d’entre eux chaque année de manière fiable si vous êtes une grande entreprise ? D’après mon expérience de la gestion de Lokad pendant une décennie, cela ne fonctionne tout simplement pas.

Vous voulez 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, vous devez avoir quelqu’un avec des compétences en supply chain car vous devez être capable de faire face en quelques heures pour appliquer les corrections de programmation à votre système sans ouvrir un ticket et le transmettre au service informatique. Si vous devez le faire de cette manière, cela prend des semaines pour résoudre les problèmes, pas des heures. Alors, quel type de logiciel peut réellement résoudre le problème ?

Eh bien, Excel peut le faire. Ce n’est pas très esthétique et cela peut ne pas sembler être le summum du logiciel moderne, mais ça fonctionne. Ça coche toutes les cases.

Stockage de données polyvalent ? Oui, dans une certaine mesure, vous pouvez mettre beaucoup de données de toutes sortes dans Excel. Logique programmable ? Absolument, Excel est entièrement programmable. Interface utilisateur polyvalente ? Oui, vous pouvez avoir des graphiques à barres, des graphiques linéaires et de nombreuses façons de présenter les données. En termes d’interfaces utilisateur, c’est très polyvalent. Ce n’est peut-être pas le plus raffiné, mais en termes de polyvalence, il peut faire beaucoup de choses.

En termes de capacités de collaboration, c’est un peu rudimentaire. Vous avez certaines versions d’Excel en ligne, qui sont légèrement meilleures, mais fondamentalement, vous pouvez partager vos feuilles de calcul. Le problème avec le manque de fonctionnalités de collaboration n’est pas que c’est une application de bureau. Le problème est la mentalité qui accompagne les feuilles de calcul, qui n’est pas adaptée à un travail collaboratif intense. Habituellement, si vous avez un collègue qui a créé une feuille très complexe, il est plus facile de recréer la feuille plutôt que d’essayer de comprendre ce qu’il a fait. Donc, le problème avec le manque de fonctionnalités de collaboration est la mentalité qui accompagne les feuilles de calcul, qui a intrinsèquement de fortes limites pour la collaboration.

Cependant, Excel est totalement 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 bonnes cases, ce qui explique en grande partie son succès opérationnel dans la plupart des chaînes d’approvisionnement.

Dans mon expérience, la majorité des chaînes d’approvisionnement mondiales, des plus petites entreprises aux plus grandes, et de celles qui n’ont jamais investi un centime dans un logiciel d’entreprise à celles qui ont investi des millions de dollars dans des logiciels d’entreprise complexes pour l’optimisation de la chaîne d’approvisionnement, sont pilotées par Excel. Il y a très peu d’exceptions. Parfois, les gens utilisent Excel pour réviser les paramètres min-max dans d’autres logiciels, mais la maintenance de ces paramètres est déléguée à ceux qui travaillent avec Excel.

Excel est le moteur de la chaîne d’approvisionnement mondiale aujourd’hui, et je pense que ce n’est pas un hasard. Fondamentalement, les feuilles de calcul abordent de nombreux problèmes de la bonne manière. De nombreuses autres options sont présentées comme supérieures, mais échouent par défaut si vous ne savez pas programmer. Si vous ne savez pas programmer, cela signifie que lorsque vous êtes confronté à un problème majeur ou à une urgence, vous êtes malchanceux. Les gens reviendront aux feuilles de calcul Excel dans des situations où l’interface utilisateur polyvalente fait défaut, ou lorsque la solution n’est pas accessible aux non-développeurs. Si seule une équipe informatique peut apporter des résultats, les gens ouvriront peut-être initialement des tickets et attendront patiemment, mais au bout de trois mois, tout le monde reviendra probablement à l’utilisation des feuilles de calcul Excel car c’est plus rapide. Excel n’est pas la solution finale, mais tout ce que nous apporterons en remplacement devra cocher les bonnes cases.

Comment pouvons-nous améliorer quelque chose ? En termes de stockage polyvalent des données, Excel est bon mais pas très évolutif. Le traitement de millions de lignes devient un problème, même avec les versions modernes d’Excel qui peuvent gérer un million de lignes. Les problèmes de performance se posent rapidement lorsqu’on opère à grande échelle. La logique programmable dans Excel est possible, mais elle est très fragile et cassante. Si vous introduisez involontairement une erreur ou un bogue dans votre feuille de calcul, le débogage et l’identification de la source du problème deviennent un cauchemar. La logique est sans cesse dupliquée, ce qui entraîne 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 basée sur le web et les données sont toujours entremêlées avec l’interface. Les capacités de collaboration existent, mais elles sont désordonnées. La collaboration devrait se faire au niveau de la logique programmable. De nombreux fournisseurs d’optimisation de la chaîne d’approvisionnement proposent une collaboration sur les résultats, tels que l’ajustement 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, au niveau de la logique programmable. Excel est très accessible aux non-développeurs, mais lorsque vous voulez faire quelque chose de légèrement plus compliqué, cela devient difficile. Dans la gestion de la chaîne d’approvisionnement, nous voulons traiter tous les futurs possibles, ce qui signifie travailler avec des prévisions probabilistes, des variables aléatoires et aborder l’incertitude. Bien que cela soit possible dans Excel, c’est assez compliqué. Excel est facile pour les tâches simples, mais pour des situations plus complexes, vous devez devenir un expert en Excel.

La maintenabilité est importante, car vous voulez construire un actif de valeur croissante au fil du temps. Avec les feuilles de calcul, il est difficile d’atteindre cet objectif, et il est difficile de créer quelque chose de vraiment précis, du moins dans le sens d’un produit logiciel.

Les mots à la mode du jour sont l’IA et Python, avec toutes les tendances et l’engouement entourant la science des données. Cependant, pour la gestion de la chaîne d’approvisionnement, 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 chaîne d’approvisionnement. Tout d’abord, cela nécessite 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, vous avez besoin d’une équipe d’ingénierie logicielle, ce qui pose des défis lorsque vous avez besoin de personnes qui sont à la fois des experts en chaîne d’approvisionnement et des ingénieurs logiciels.

Python a de bonnes fonctionnalités, mais la gestion des dépendances est assez complexe et la gestion des packages est médiocre. Les packages sont des blocs de construction qui fournissent des fonctionnalités supplémentaires, et lorsque vous dites que vous voulez utiliser Python, ce n’est pas seulement le langage mais aussi tout l’écosystème de packages qui vous intéresse, tels que NumPy, Pandas, TensorFlow et SciPy - toutes des dépendances tierces ou des bibliothèques logicielles. La gestion des packages est médiocre depuis plus d’une décennie, et bien qu’elle s’améliore, les progrès sont lents. Il y a de nombreux aspects de la conception du système qui le rendent difficile à améliorer.

Les performances sont également médiocres, principalement par conception. Les performances de calcul font référence à la qualité du travail effectué 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é, exploitant les systèmes multi-CPU, multi-cœurs et exécutant une logique compilée nativement. Microsoft a investi beaucoup pour rendre Excel extrêmement rapide.

En revanche, Python présente des problèmes inhérents qui se traduisent souvent par des performances 100 fois plus lentes 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 dont les volumes de transactions dépassent 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 performances de Python ne fait qu’ajouter de la complexité. Vous résolvez peut-être le problème de performance, mais vous créez un nouveau problème en introduisant la complexité supplémentaire de NumPy, avec laquelle vous devez composer et maintenir dans le temps. Cela élève également le niveau d’exigence du côté de l’ingénierie logicielle.

Lorsque vous essayez de mettre en œuvre des solutions Python pour la gestion réelle de la chaîne d’approvisionnement, divers problèmes se posent, tels que des exceptions de référence nulle, des exceptions de mémoire insuffisante et des temps de calcul prolongés. Vous pouvez vous retrouver à attendre 20 minutes pour qu’un calcul se termine, sans savoir s’il finira un jour ou si vous devez simplement arrêter le processus et le redémarrer. Je ne sais tout simplement pas, donc vous voulez des choses où vous avez une très, très bonne idée du temps que cela va prendre pour se terminer. En passant, si je reviens à Excel, de nos jours, lorsqu’une opération prend un peu de temps à se terminer, Excel vous donne une indication assez fiable, une barre de progression sur le temps que cela va prendre. Donc, encore une fois, vous voulez, et c’est une partie de ce que j’appelle la préparation à la production. Vous voulez avoir quelque chose qui est parce que, encore une fois, le logiciel que vous produisez va très probablement s’exécuter sans surveillance, pendant la nuit ou pendant le traitement nocturne, par exemple. Vous voulez quelque chose qui ne nécessite pas qu’un data scientist surveille le tout.

Et encore une fois, si vous avez un problème avec les data scientists, alors vous avez besoin de la troisième compétence : un expert en supply chain, un expert en ingénierie logicielle et maintenant un expert en data science. Il est possible d’avoir ces trois qualités en une seule personne, mais bonne chance pour embaucher plus d’une personne par an, même si vous êtes une grande entreprise qui possède toutes ces compétences. C’est extrêmement rare.

Donc nous voulons avoir quelque chose qui va s’améliorer. D’ailleurs, la première chose que nous voulons améliorer est la défense en profondeur. Les ransomwares sont en hausse, et chaque fois que vous mettez quelque chose de programmable dans votre organisation, vous vous exposez aux ransomwares. Parce que soudainement, lorsque vous avez un programme, le programme sur la machine peut faire beaucoup de choses, y compris prendre le contrôle de la machine même sur laquelle il s’exécute. Je sais qu’il y a beaucoup de façons d’atténuer les problèmes ; vous pouvez mettre en place des environnements isolés, vous pouvez restreindre les droits, et il y a beaucoup de façons de limiter les problèmes. Néanmoins, chaque fois que vous avez quelque chose comme un langage de programmation générique, votre surface d’attaque, c’est un terme technique, est absolument gigantesque.

Donc fondamentalement, chaque fois que vous insérez du code comme ça, vous vous exposez massivement en termes de problèmes de sécurité. Et rappelez-vous, la façon dont cela se fait généralement dans une entreprise d’ingénierie logicielle classique, c’est que le code est examiné par les pairs. Vous examinez le code, vous avez un processus d’examen du code, quelqu’un produit le code, et un collègue va examiner le code pour s’assurer qu’il n’y a pas de manigances dans le code. Mais si je reviens au fait que le logiciel doit être robuste, vous devez être capable de réagir en quelques heures. Vous ne serez pas en mesure, d’un point de vue d’optimisation de la supply chain, d’avoir un processus d’examen du code en place. Ce n’est tout simplement pas compatible avec les délais et les urgences auxquels vous serez confrontés.

Donc, vous devez avoir quelque chose qui vous offre une défense en profondeur dès la conception. Ensuite, vous voulez avoir quelque chose avec des performances transparentes, où oui, les choses peuvent prendre du temps, mais vous devez être en contrôle. Vous devez savoir à l’avance combien de temps cela va prendre. Si vous n’avez pas cela, alors vous vous exposez à de nombreux problèmes très stupides, comme avoir 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. Donc vous devez avoir quelque chose où cela est pris en charge.

Et la même chose vaut pour les mises à jour transparentes. C’est la beauté d’Excel. Vous n’avez pas à vous soucier de la maintenance d’Excel. Microsoft a signé un pacte il y a des décennies, qui était le suivant : si vous avez produit une feuille de calcul Excel, quelle que soit la prochaine version d’Excel qui arrivera sur le marché, elle sera en mesure de prendre en charge vos feuilles de calcul. Et la chose la plus incroyable, c’est que si vous regardez Excel de nos jours, il prend en charge de nombreux formats Excel concurrents de concurrents qui n’existent même plus. Vous pouvez toujours lire des feuilles de calcul qui ont été produites avec Lotus Notes et ce genre de choses. Donc la proposition de valeur de Microsoft en termes de mises à jour transparentes est que la logique que vous avez produite fonctionnera toujours, et oui, ils continueront à améliorer Excel pendant des décennies, mais vous savez quoi ? C’est pris en charge. Ce n’est pas quelque chose que vous voyez lorsque vous regardez la transition de Python 2 à Python 3 ; c’était un cauchemar, et cela a pris une décennie. Donc, Python est génial pour beaucoup de choses, mais imaginez simplement que ces mises à jour se produiront aux pires moments, lorsque vous avez la pire pandémie, les pires tarifs, la pire urgence, et vous avez besoin que les choses soient opérationnelles et prêtes. Vous ne pouvez pas vous permettre d’avoir une indisponibilité de six mois simplement parce que vous devez vous occuper d’une mise à jour. Ce n’est pas compatible avec l’optimisation de la supply chain.

Donc maintenant, nous devons réfléchir à ce que nous pourrions envisager si nous devions réellement concevoir quelque chose en ayant la supply chain à l’esprit. Cela sera le sujet de la prochaine conférence.

Maintenant, la supply chain n’est pas la division informatique. Lorsque je parle d’une livraison orientée produit, encore une fois, ce n’est pas que le logiciel est juste un moyen, pas une fin en soi. Vous ne vendrez pas votre logiciel sous licence ou moyennant des frais, comme le fait, par exemple, Microsoft. Dans cette vision que je vous présente dans cette conférence, l’informatique est responsable des pratiques de base, des pratiques informatiques de base, comme ce que vous devriez faire ou ne pas faire en termes de sécurité, de sauvegardes, d’infrastructure de base, de réseau, de gestion et de synchronisation de tout en termes de données au niveau de l’entreprise, et de fournir toutes les orientations et le coaching nécessaires.

Mais l’idée est que la supply chain doit être responsable des décisions de la supply chain. Ils doivent être propriétaires de tout l’appareil qui génère ces décisions de la supply chain, c’est donc leur propriété principale. Dans la conférence précédente, j’ai dit ce qui définit le Supply Chain Scientist : le Supply Chain Scientist est quelqu’un qui est propriétaire des décisions numériques produites par le code. Ce n’est pas un système qui produit des décisions ; ce sont des recettes numériques qui ont été écrites par un ou plusieurs Supply Chain Scientists, et ces Supply Chain Scientists sont collectivement propriétaires de ces décisions numériques. Ils en prennent la responsabilité, et la responsabilité de la supply chain est de s’assurer que toutes les décisions de l’entreprise sont cohérentes. S’il y a une promotion en cours ou une grande campagne marketing, les choses doivent être produites à temps pour être prêtes à être servies. Vous ne voulez pas vous retrouver dans une situation catastrophique où vous poussez quelque chose alors que vous êtes déjà dans une situation de quasi-rupture de stock, où vous dépensez de l’argent pour une campagne marketing pour quelque chose que vous ne pouvez même pas vendre parce que vous n’avez pas le stock ou la capacité de les fabriquer ou de fournir le service à temps, etc.

Donc, nous avons deux divisions qui ont des objectifs très différents. Dans ma vision idéale de ce que devrait être le service informatique, le service informatique n’est pas une division où vous transmettez des tickets. Ce n’est pas comme ça que ça marche. Le service informatique est responsable de l’infrastructure de base. C’est le genre de chose qui fonctionne parfaitement tout le temps. Vous n’y prêtez même pas attention, tout comme le Wi-Fi fonctionne. Vous ne faites pas attention au Wi-Fi ; vous ne faites attention au Wi-Fi que lorsque cela ne fonctionne pas. Un bon service informatique fournit toute l’infrastructure pour que vous n’y prêtiez même pas attention. Vous ne réalisez même pas qu’ils existent parce que ça marche, tout comme vos e-mails fonctionnent parfaitement, etc. C’est ce qu’est un bon service informatique de base. Et puis, l’informatique est le genre de personnes qui viennent à vous et vous aident à établir toutes ces pratiques qui vous donnent un coup de main. La logique programmable est un peu difficile, donc parfois, où allez-vous obtenir le coaching pour vous améliorer un peu en programmation ? Eh bien, la réponse, c’est que ça devrait être l’informatique. Ils ne devraient pas venir dire : “Nous allons le coder pour vous”, mais plutôt : “Nous allons vous coacher pour que vous puissiez le mettre en œuvre vous-même. Nous vous aiderons avec quelques concepts, peut-être vous aiderons-nous avec des choses un peu plus techniques qu’elles ne devraient l’être.” Parfois, vous avez une complexité accidentelle, donc l’informatique est là pour vous soutenir. Mais fondamentalement, ils ne sont pas là pour faire le travail à votre place. Ils devraient être des mentors et des coaches, s’assurant que personne ne commet d’erreur fatale qui exposerait toute l’entreprise à un risque de rançongiciel ou à quelque chose qui pourrait être un risque systémique, du point de vue informatique, pour l’entreprise.

Comme test décisif, si votre interaction entre l’informatique et la supply chain passe par des documents où vous énumérez des spécifications ou des exigences, ce n’est pas la bonne façon d’avoir une bonne relation entre ces deux divisions. Quand je dis une bonne relation, je veux dire quelque chose qui ajoutera réellement de la valeur à l’entreprise.

En conclusion, nous avons ici deux défis du côté de la gestion traditionnelle de la supply chain, qui peut avoir fait de la programmation mais seulement en périphérie 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 penser que le monde de demain, votre division, sera chargé de livrer un produit qui fonctionne comme un produit logiciel, et cela représente un énorme changement. Oui, mais c’est quelque chose avec lequel vous pouvez composer. Pourquoi ? Parce que si vous avez les bons outils, oui, il y a 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 réside 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 en premier lieu.

Pour la partie de l’audience qui est peut-être plus du côté des data scientists ou du côté informatique, ce que vous devez surmonter, c’est la confiance excessive. J’ai vu, encore et encore, des data scientists, et je m’inclus dans cette catégorie, qui étaient trop confiants dans leur capacité à passer d’un prototype à la production. C’est difficile, et les supply chains ont un moyen de vous exploser au visage de la manière la plus surprenante. Je ne peux me rappeler qu’une anecdote où, il y a des années, nous avons commencé avec une entreprise européenne de commerce électronique de pièces automobiles de premier plan. Nous gérons leurs réapprovisionnements en pièces avec notre technologie de prévision, en faisant des suggestions de réapprovisionnement en pièces, en servant des pièces automobiles. La semaine suivante, nous avons constaté que toutes nos prévisions étaient erronées d’un facteur de deux. La demande avait doublé. Ce qui s’était passé, c’est que leur principal concurrent avait décidé de se lancer dans plusieurs pays en même temps, littéralement au moment où nous commencions notre prévision, l’un des concurrents avait décidé de passer à la télévision nationale et de commencer à diffuser son service en ligne. La chose intéressante, c’est que mon client n’en était même pas conscient, et ils avaient de meilleurs résultats d’optimisation des moteurs de recherche. Ils étaient plus optimisés en termes de référencement naturel, donc fondamentalement, les gens voyaient la publicité télévisée du concurrent, mais ils ne se souvenaient pas naturellement du nom du concurrent. Donc, ils allaient sur Google et tapaient “pièces automobiles” jusqu’à ce qu’ils arrivent sur le site web de mon client. Pour démontrer à quel point Lokad était génial, la première semaine où nous avons commencé, nous étions erronés d’un facteur de deux, et nous nous demandions, “Qu’est-ce qui se passe même ?” Nous avons dû tout revoir parce que lorsque vous voyez que la demande double, ce n’est pas que tout double ; certaines choses font 10 fois plus, et beaucoup de choses restent inchangées.

C’est donc ce genre de chose, et vous devez être capable de réagir rapidement. C’est de cela qu’il s’agit : la peur et la confiance excessive. Merci beaucoup pour le temps accordé.

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

Question : Le logiciel peut-il prendre la décision de quel fournisseur passer une commande supplémentaire en cas de besoin pour demain ? Par exemple, des barquettes de fraises de 200 grammes 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 aspects de la gestion de la chaîne d’approvisionnement et de l’optimisation de la chaîne d’approvisionnement. Il y a le côté gestion de la chaîne d’approvisionnement, qui consiste littéralement à avoir toutes les pipelines de données en place, y compris l’EDI, où vous pouvez envoyer une commande électronique à un fournisseur sans aucune intervention humaine. Vous avez donc un pont électronique de bout en bout. Mais ensuite, cela signifie que vous devez avoir, du côté de l’optimisation, un logiciel qui s’exécute en continu tout au long de la journée et, à un moment donné, peut notifier le côté gestion, en disant : “Veuillez exécuter cette commande”. Et ensuite, du côté de la gestion, qui sera géré par l’informatique, ils s’assurent simplement que cette commande est complètement exécutée. C’est simplement une question de transaction pure ; il n’y a plus d’intelligence. Vous avez reçu une commande qui dit “cette quantité”, et c’est le côté optimisation qui est responsable de s’assurer que lorsque vous générez une certaine quantité, vous êtes conforme à toutes les contraintes, telles que la liste exacte des fournisseurs qui sont même éligibles pour servir ces produits, s’ils ont encore du stock, et comment faire le bon choix entre tous les fournisseurs concurrents, etc. Il peut y avoir beaucoup de choses en jeu. Absolument, oui, mais nous devons littéralement séparer l’exécution banale, qui est la partie transactionnelle qui se trouve du côté de la gestion de la chaîne d’approvisionnement, du fait d’avoir l’ingrédient d’optimisation au moment où vous décidez que vous avez besoin de commander plus.

Question : Savez-vous que vous êtes en concurrence avec les championnats du monde d’eSports 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 direction joue aussi. Certains de nos employés veulent jouer à League of Legends, mais en tant que PDG de l’entreprise, je désapprouve fermement.

Question : J’ai remarqué que de nombreuses entreprises n’ont pas de ERP ou de WMS en premier lieu, et que la direction travaille sur l’optimisation de la chaîne d’approvisionnement.

Eh bien, absolument. Vous ne pouvez pas éviter l’optimisation de la chaîne d’approvisionnement dès le premier jour ; vous devez prendre ces décisions. L’optimisation de la chaîne d’approvisionnement était là même avant la mise en place de tout logiciel de gestion de la chaîne d’approvisionnement. Même si nous remontons il y a 60 ans, lorsque les logiciels n’existaient pas, les gens devaient quand même prendre des décisions. Donc l’optimisation de la chaîne d’approvisionnement existait déjà ; les gens le faisaient avec un stylo et du papier. Si vous regardez les premiers travaux sur la chaîne d’approvisionnement, tels que la formule de Wilson, également connue sous le nom de formule EOQ, elle a un siècle. Elle précède clairement les logiciels. Donc oui, l’optimisation de la chaîne d’approvisionnement est quelque chose qui se produit dès le premier jour, que vous ayez ou non un logiciel dans votre organisation.

Maintenant, en effet, vous devez disposer de systèmes informatiques appropriés, mais c’est une mentalité complètement différente. La gestion de la chaîne d’approvisionnement consiste à bien faire des tâches banales, telles que la saisie de données, éventuellement avec le support de codes-barres et d’autres éléments. Mais il s’agit de tâches très banales, simplement de représenter les données. Le problème est que les gens veulent quelque chose qui combine à la fois la gestion de la chaîne d’approvisionnement et l’optimisation de la chaîne d’approvisionnement, et en conséquence, vous vous retrouvez avec un produit qui est surchargé, généralement très bogué, et vous avez besoin de fonctionnalités médiocres comme des alertes et des exceptions, que vous devriez éviter. J’y reviendrai dans un prochain cours.

Fondamentalement, de nos jours, déployer un WMS ou un ERP, si vous n’en avez pas déjà un, est une question de semaines. Si vous en avez déjà un, cela peut prendre quelques mois si vous démêlez cette chose de vos décisions.

Question : Quand la direction de l’entreprise peut-elle réaliser qu’il est temps de passer du suivi des informations à l’optimisation des décisions de la chaîne d’approvisionnement et finalement se concentrer sur l’optimisation de la chaîne d’approvisionnement ?

La première chose est de réaliser en premier lieu qu’il y a deux problèmes, et qu’un même logiciel ne résoudra jamais les deux aspects. 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 concerne l’optimisation de la chaîne d’approvisionnement, mais tout ce qu’ils fournissent réellement et tout ce que leur produit fait réellement concerne la gestion de la chaîne d’approvisionnement, ce qui est beaucoup moins attrayant car il n’y a pas d’IA ou d’intelligence réelle. Dans le monde des logiciels, on les appelle des applications CRUD (Create, Read, Update, Delete). Les ERP sont simplement de gigantesques collections d’écrans CRUD où chaque écran peut créer, lire, mettre à jour ou supprimer des lignes d’une base de données relationnelle, et c’est tout. Un ERP est essentiellement, pour simplifier un peu, une collection de milliers de tables pour différentes entités. Pour chaque entité qui peut être regroupée logiquement, vous avez un ou deux écrans, et c’est tout. Donc, si je reviens à 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 les éditeurs d’ERP vous disent que cette chose va optimiser votre chaîne d’approvisionnement. La réponse est : non, absolument pas. Ce qu’il va faire, c’est améliorer la productivité et garantir une comptabilité précise de votre chaîne d’approvisionnement. C’est déjà beaucoup, car cela peut réduire considérablement le vol, la perte, les marchandises mal placées et améliorer la productivité avec des codes-barres pour un entrepôt. Il y a beaucoup de valeur ajoutée dans ces produits. Je ne nie pas la valeur qu’un ERP ou un WMS apporte ; elle est énorme, mais il ne s’agit pas d’optimisation de la chaîne d’approvisionnement. Un WMS, par exemple, est par conception quelque chose qui se soucie de l’entrepôt ; il ne se soucie pas de toute la chaîne d’approvisionnement qui inclut les clients et les fournisseurs. Il est conçu pour se concentrer sur des emplacements spécifiques, pas sur toute la chaîne.

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

Nous les avons fait fonctionner ensemble dans quelques situations historiquement. Pour le public, Envision est un langage de programmation spécifique au domaine conçu par Lokad qui a été développé uniquement pour l’optimisation prédictive des chaînes d’approvisionnement. Dans la prochaine conférence, je vais démontrer Envision afin que les gens puissent mieux comprendre de quoi je parle, avec de vrais morceaux de code.

Historiquement, nous avons utilisé Python et Envision ensemble car, lorsque nous avons commencé, Envision avait des capacités très limitées, il manquait donc beaucoup de choses et nous utilisions Python par défaut dans de nombreuses situations. Au fil des années, nous avons progressivement étendu les capacités d’Envision, de sorte que nous avons progressivement éliminé la nécessité d’avoir des composants Python. Ce ne sont pas seulement des composants Python ; ce sont aussi une série d’outils qui doivent être connectés ensemble, comme Airflow.

Au fait, la syntaxe d’Envision a été délibérément alignée sur de nombreux aspects de Python. J’ai fait le choix conscient de concevoir la syntaxe d’Envision de manière à ne pas antagoniser les programmeurs Python, de sorte que si vous êtes familier avec Python, vous pouvez apprendre Envision en une semaine. Il y a des différences subtiles et profondes, mais au niveau de la syntaxe, il y a de nombreux aspects qui sont les mêmes. Python a de nombreux mérites, comme sa simplicité et sa pureté de conception. Même si je dis que Python ne coche pas toutes les cases et crée des problèmes graves en production qui ne peuvent pas être résolus, cela ne signifie pas que Python n’a pas de mérites. Ce n’est pas ce que je dis. Je crois que Python a de nombreux mérites. Encore une fois, nous parlons spécifiquement de la façon d’exécuter des chaînes d’approvisionnement en production, ce qui est un problème très spécifique.

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

C’est très difficile car, franchement, la pire situation est lorsque qu’un prospect vient me voir et dit : “Notre ERP, un ERP hérité, ne fournit aucune valeur, et maintenant nous voulons passer à un nouvel ERP qui offre une optimisation de la chaîne d’approvisionnement.” C’est une situation terrible pour moi car je dois dire au client que ce qu’il recherche n’est pas un produit mais deux : un qui remplacera leur ERP et gérera mieux le côté gestion, et un qui fera l’optimisation.

Lorsque vous pensez à ces ERP hérités, j’ai beaucoup de respect pour eux, en particulier pour ces produits AS/400 avec un terminal en ligne de commande sur de vieux mainframes IBM. Du côté gestion du problème, ils font généralement un très bon travail. Ce que les clients recherchent vraiment, 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 remets cela en question. Les lignes de commande avec des terminaux texte peuvent être incroyablement rapides et productives, sans aucune distraction.

Donc, c’est assez difficile car nous devons démêler toutes les absurdités propagées par nos concurrents. En plus de cela, nous devons expliquer que l’ERP ne va pas optimiser la chaîne d’approvisionnement et qu’il n’y a pas de véritable intelligence artificielle ou de blockchain, seulement des classes de modèles statistiques. Malheureusement, nous perdons la plupart de nos prospects à ce stade. C’est l’une des raisons pour lesquelles je donne ces conférences en premier lieu, car il faut des heures pour arriver au fond des choses et expliquer pourquoi nous devons voir le problème de la manière dont je le vois.

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

Eh bien, Lokad, bien sûr. Mais gardez à l’esprit que, en tant que PDG de Lokad et propriétaire majoritaire de l’entreprise, j’ai un conflit d’intérêts dans mon opinion. Je suis profondément convaincu que Lokad est la plateforme dont vous avez besoin, mais veuillez comprendre que c’est aussi l’entreprise que je possède et dirige. Je ferai de mon mieux pour rester objectif à ce sujet.

Au fait, Lokad a été littéralement conçu pour gérer la distribution de demande probabiliste, et ce n’est pas seulement la distribution de demande probabiliste. Il traite également la distribution stochastique des délais d’approvisionnement, la distribution stochastique des retours, et bien plus encore. Nous devons examiner tous les futurs possibles avec des probabilités, en tenant compte de tous les types d’incertitudes. La demande est très importante, généralement la plus importante, mais ce n’est pas la seule.

Je pense avoir répondu à toutes les questions. Je vérifie juste si j’ai oublié quelque chose… Pas d’autres questions. Donc, 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: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity - Par Joel Spolsky, 2004