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 déséconomies d’échelle du logiciel
12:50 Prenons 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 le SCO
42:49 Pourtant, les tableurs ne sont pas la solution ultime
46:51 Python n’est pas non plus la solution ultime
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

L’objectif d’une initiative de la 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 et les mises à jour de prix). L’application est envisagé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 la performance 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 conférences sur la 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, quand je parle de produit, je veux dire un produit logiciel. Pour ceux d’entre vous qui ont eu le privilège d’examiner ce qui se cache sous le capot d’une moderne application d’entreprise, cela peut être une sacrée expérience.

Pour ceux qui connaissent l’œuvre de H.P. Lovecraft, il existe quelques similitudes inquiétantes. Lovecraft a produit une série de romans, et l’un des thèmes récurrents est l’idée d’un savoir interdit. Ce n’est pas que l’univers ne peut être connu, il peut l’être. C’est simplement que la seule chose qui préserve l’humanité 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 nos esprits. Cette idée a été recyclée dans de nombreux jeux modernes, notamment 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 perdez des points de santé mentale. Le défi avec le logiciel d’entreprise est de pouvoir le créer tout en préservant votre santé mentale, ce qui est l’une des conditions requises pour ajouter de la valeur à l’entreprise. Alors, procédons.

Pourquoi un produit, et en particulier un produit logiciel ? Examinons de près comment fonctionnaient traditionnellement les supply chains. Autrefois, il y avait de nombreuses personnes sur le terrain pour déplacer les choses, trier des colis, conduire des véhicules et effectuer tout le travail manuel. Il y avait également beaucoup de personnes impliquées dans la production, ainsi qu’en magasin. Ce qui s’est progressivement produit au cours des dernières décennies, c’est que le nombre de travailleurs manuels a chuté de manière constante. 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 tout, raison pour laquelle ces industries ont déménagé 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 donc dans une situation assez étrange où, si l’on envisage l’arrivée imminente des véhicules autonomes, de nombreuses entreprises compteront davantage de cadres travaillant sur Excel via des tableurs pour gérer la supply chain que de travailleurs manuels sur le terrain pour effectuer les opérations de travail manuel. C’est à cela que je fais référence quand je parle de tâches administratives.

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 ; les supply chains 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, ils sont littéralement utilisés comme coprocesseurs humains dans une supply chain moyenne. Il existe certains types d’opérations que le CPU classique, le processeur de la machine, ne peut effectuer, et ainsi toute la tâche est déléguée à un humain. En conjonction avec des recettes numériques, telles que l’analyse ABC des stocks, la gestion min-max des stocks, et d’autres recettes similaires, les humains finissent par passer leurs journées à éteindre des incendies. Ils traitent constamment des exceptions et des situations qui ne rentrent pas dans le cadre standard.

D’un point de vue coût, tout cela représente des dépenses opérationnelles (OpEx). Il faut 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, ainsi que bien d’autres décisions routinières. Les humains prennent ces décisions et se battent contre les urgences pour pallier 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 d’une dépense opérationnelle (OpEx) à une dépense 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 l’on regarde les 100 entreprises les plus rentables au 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 investissez d’abord, pour ensuite obtenir un dispositif ou un artefact qui génère une valeur ajoutée avec un investissement marginal minimal.

Pour revenir au sujet de ma conférence précédente, nous avons besoin de robotisation pour remettre la gestion aux commandes. L’automatisation et les humains devraient travailler ensemble ; les humains ne devraient pas être là pour compenser les insuffisances de politiques de stocks stupides comme le min-max. Au contraire, ils devraient être là pour ajouter de la valeur, améliorer les recettes numériques et agir en tant que stratèges. Il existait autrefois un slogan d’IBM qui disait : “Les machines doivent travailler ; les gens doivent réfléchir.” C’est ce type de réflexion qui sous-tend 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 réellement ce produit ? Il se trouve qu’il réalise 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 telles que ce qu’il faut produire, combien d’unités acheter auprès d’un fournisseur, et combien d’unités déplacer d’un site à un autre. À première vue, on pourrait penser qu’il y a 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. Cela n’est pas écrasant, et c’est tout à fait raisonnable en termes de nombre pur de fonctionnalités. Fait intéressant, ces décisions sont en grande partie exclusives, de sorte qu’il y a des limites à ce qui peut être réalisé en utilisant une approche de division et conquête. Une fois que vous avez décidé d’acheter 100 unités auprès d’un fournisseur, vous ne pouvez pas qu’un autre sous-système décide d’acheter 200 unités à la place. À un moment donné, il faut se fixer sur le nombre d’unités à acheter et à déplacer d’un site à un autre. Ces décisions sont discrètes, limitées en portée et en grande partie exclusives. Ce que nous voulons, c’est un logiciel qui génère des ordres de décision de manière entièrement automatisée chaque jour.

Une chose qui, je crois, est 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, c’est le contraire dans le domaine des logiciels, où ajouter un quart de fonctionnalités supplémentaires peut doubler le coût. Ce concept explique pourquoi les petites startups peuvent rivaliser avec les grandes entreprises – parce qu’elles se concentrent sur une fraction plus réduite 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.

En gardant à l’esprit 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 livrer pour desservir le marché.

Alors, considérons l’achat d’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’en ai fait l’expérience directe, car lorsque j’ai lancé Lokad en 2008, j’ai commencé avec un petit produit logiciel orienté davantage vers la prévision que vers l’optimization de la supply chain. En commençant à travailler avec des clients, j’ai réalisé qu’il y avait tant de fonctionnalités et de capacités qui me manquaient, et en passant à d’autres clients, j’ai découvert encore plus de fonctionnalités absentes. Cela semblait être un processus sans fin de découverte de nouvelles exigences.

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 schémas complètement différents dans la 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 crée différents types de risques, tels que le risque de perdre un seul client qui représente une part significative du chiffre d’affaires de l’entreprise. Ensuite, il existe des modèles commerciaux plus complexes comme le B2B2C ou le B2B2B.

Considérez les différents types de sites qui doivent être couverts, tels que les magasins, les entrepôts et les sites de production. Chaque type de site présente 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 sur le rendement de production.

Les réseaux de supply chain peuvent comporter différents niveaux, ou échelons, allant de systèmes à un seul échelon à des systèmes multi-échelons. La complexité de la gestion de la supply chain augmente significativement 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 aval, 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 orientés acycliques (DAG), peuvent exister, où un magasin peut être desservi par plusieurs entrepôts.

Donc, fondamentalement, il ne s’agit pas seulement d’un arbre en termes de graphes, il peut se reconnecter, bien que cela reste uniquement en aval. Mais la même chose peut se produire avec un graphe orienté acyclique (DAG) lorsque vous avez plusieurs fournisseurs. Vous pouvez même avoir des boucles dans votre graphe de supply chain qui se produisent chaque fois qu’il y a des réparations. Par exemple, dans l’industrie minière ou dans l’industrie de l’aviation, il existe une multitude de boucles de réparation avec des équipements réparables.

Maintenant, les stocks eux-mêmes n’ont pas une seule nature ; ils varient beaucoup. Vous ne pouvez pas simplement dire : “Oh, j’ai cette idée que j’ai SKU et voilà.” Non, pas vraiment, 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 en volume. Ensuite, vous avez les unités qui sont ces unités nettes et claires, qui sont majoritairement répandues. Mais il peut également y avoir beaucoup de stocks qui se renouvellent très fréquemment, par exemple dans la pharmacie ou dans l’industrie alimentaire, où le lot est assorti de dates d’expiration spécifiques. Puis, vous pouvez même avoir des stocks complètement 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 entièrement différent lorsque l’on examine chacune de ces choses.

Ensuite, évidemment, il y a tous les problèmes des places de marché. Chez Lokad, nous avons des clients dans littéralement toutes les situations possibles. Nous avons des clients qui vendent sur une place de marché tierce, qui peuvent avoir leur propre place de marché, ou les deux. Cela peut être quelque chose de secondaire pour leur permettre de liquider ce qu’ils n’ont pas vendu. Il existe de nombreuses situations.

Maintenant, prenez un instant pour réfléchir à ce qu’est une commande. Il y a la commande au comptoir, où en gros vous achetez quelque chose immédiatement, et cela devient le vôtre. Mais vous pouvez également avoir une commande qui stipule : “Je l’achète, mais je ne veux pas que ce produit soit livré immédiatement ; je souhaite qu’il soit livré un mois plus tard.” Évidemment, d’un point de vue d’optimization de la supply chain, c’est un tout autre enjeu, 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 de la prévision, c’est donc une tout autre affaire.

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 taille du disque dur, le type de système d’exploitation, la langue qui sera installée sur votre ordinateur, ainsi que le type de clavier, entre autres choses. Vous pouvez donc avoir un configurateur massif, et cela change à nouveau la donne. Cela se produit également pour des choses comme les vélos ou les voitures et change radicalement le paysage lorsque vous avez ce type de produits, car cela vous offre des options et des manières d’aborder le problème d’optimization 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 parfaitement linéaire, mais ce n’est pas la seule option. Vous pouvez avoir des remises sur les prix, par exemple, si vous achetez dix unités, vous bénéficiez alors d’une remise. Ou bien vous pouvez avoir des programmes de fidélité où certains clients possédant une carte de fidélité peuvent obtenir une réduction, mais seulement sur certains types de produits ou uniquement selon certaines conditions. Et puis, surtout en B2B, il y a souvent des choses négociées, de sorte qu’il s’agit littéralement d’une transaction dans laquelle beaucoup de choses seront vendues, mais que vous avez un prix catalogue régulier. Toutefois, un fournisseur peut offrir un rabais à un client parce qu’il est important, et c’est simplement comme ça que cela se fait. En fin de compte, ça fait à peine quelques minutes que je parle, et je n’ai couvert que le cœur du sujet. Je n’ai même pas encore abordé les éléments indispensables. Prenez donc un moment pour réfléchir à ce à quoi pourrait ressembler un produit logiciel d’entreprise standard censé offrir l’optimization de la supply chain. Le nombre de fonctionnalités à couvrir est littéralement fou, et quand vous essayez d’imaginer comment assembler toutes ces choses en un monolithe, vous perdez littéralement la tête. Nous revenons à l’idée qu’il ne s’agit pas que l’univers ne puisse être connu, c’est juste que si vous êtes exposé à la vérité nue de l’univers, vous perdez la raison.

Ainsi, nous avons 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 côté gestion et le côté optimization. La gestion concerne la tenue des registres, le support des flux de travail et, surtout, les processus de saisie de données. Si vous voulez représenter tout ce que je viens de décrire, c’est 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 laid, mais c’est possible. Mais ne vous méprenez pas, l’ERP (qui devrait être nommé ERM, Enterprise Resource Management) ne fera pas grand-chose. Il va simplement conserver une trace de ces éléments. Ainsi, vous aurez une multitude d’entités – MOQs, cochez; des remises sur les prix, cochez; des magasins, cochez; des entrepôts, cochez – mais vous n’avez pas besoin que cela fasse preuve d’une quelconque intelligence. Il s’agit simplement d’équivalents numériques banals pour refléter les données, permettant d’entrer les données 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 double le coût.” Il y a quelque chose que je n’ai pas vraiment mentionné à ce sujet : cela fonctionne si vous maintenez vos fonctionnalités complètement séparées. Tant que les fonctionnalités n’interagissent pas entre elles, tout va bien ; vous n’êtes pas soumis à cette malédiction des déséconomies d’échelle. Du point de vue de la saisie des données, il n’y a pas de problème. Vous n’avez pas besoin de l’interface utilisateur qui vous permet de piloter les MOQs reliés à ce qui vous permet d’ajouter un magasin supplémentaire au réseau. Ces deux éléments peuvent être entièrement séparés.

Cependant, en ce qui concerne l’optimization de la supply chain, il en va autrement. Si vous avez des MOQs, ils auront des implications profondes sur la fréquence de vos commandes, sur la fréquence de vos livraisons depuis votre entrepôt vers vos magasins. Il y a de nombreuses conséquences à long terme. Vous ne pouvez pas séparer ces éléments car, en fin de compte, votre supply chain est un système unique où chaque élément influence l’ensemble. Ainsi, du point de vue de l’optimization de la supply chain, vous avez littéralement le problème que toutes ces choses doivent être branchées si vous voulez délivrer l’optimization, et c’est là que tout s’effondre.

Du côté de la gestion, vous pouvez potentiellement aboutir à un produit. Cependant, en ce qui concerne l’optimization de la supply chain, la réponse est que vous ne le 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émarré en tant qu’entreprise de supply predictive spécialisée dans l’optimization prédictive de la supply chain, mais plutôt en tant que service de prévision, les choses ne se passent pas ainsi. Si vous remontez au blog de Lokad en 2008, j’avais initialement commencé avec prévision des séries temporelles, ce qui était extrêmement mal orienté. 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 de l’ensemble du problème, c’est ingérable. Telle est ma conclusion après plus de 12 ans dans ce métier.

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 à succès produisent leurs logiciels, il y a de fortes chances que vous en sachiez très peu à ce sujet. Il s’avère que c’est un univers très spécifique avec de nombreux aspects nettement contre-intuitifs. Les entreprises traditionnelles, en particulier celles qui ont une mentalité d’ingénierie mécanique classique ou une mentalité marketing, peinent énormément à comprendre comment les logiciels fonctionnent réellement.

Nous aborderons ces aspects plus en détail dans de futures conférences, mais il y a un livre que j’affectionne particulièrement, réalisé par Joel Spolsky, un ancien employé de Microsoft qui a travaillé dans les premières équipes de Microsoft Excel. Il est également le co-fondateur 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 donne, avec humour, 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. Je vais ajouter 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 ordinaire. Généralement, lorsque vous traitez avec un produit logiciel moyen – je veux dire, oui, il peut y avoir des comportements adverses, selon le type de produit logiciel. Si vous travaillez avec un réseau social, vous pouvez avoir de nombreuses personnes publiant du contenu haineux, ce qui est un tout autre jeu. Cependant, lorsqu’il s’agit de logiciels d’entreprise classiques, comme Microsoft Word ou Excel, c’est un produit où vous souhaitez avoir le bon design, sans qu’il y ait aucune urgence. Dans le cas des produits logiciels traditionnels, il est acceptable de passer des années à peaufiner votre design et votre produit. C’est un investissement à long terme, et vous devez penser à des décennies d’avance. Il n’y a aucune raison de se précipiter en termes de développement. Cependant, l’optimization de la supply chain ne fonctionne pas ainsi. Vous n’avez pas le choix, car les événements surviennent constamment, 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 judicieuses pour tirer le meilleur parti des capacités dont vous disposez encore. Vous pouvez faire face à un immobilisme de flotte dû à des incidents tragiques, à des mouvements politiques comme des tarifs douaniers perturbant votre stratégie, ou à des catastrophes naturelles telles que des tsunamis ou des incendies et vagues de chaleur, comme ceux en Californie ou en Australie. Ces événements surviennent, et lorsqu’ils se produisent, vous devez être capable de réagir littéralement en quelques heures.

Vous avez votre produit logiciel, mais vous devez apporter du changement, et vous souhaitez apporter un changement programmatique. Rappelez-vous, si vous avez pour objectif de livrer un atout logiciel, vous disposez d’une petite équipe pilotant le logiciel qui, à son tour, gère votre supply chain. Vous n’avez pas une armée de commis qui éteignent les incendies toute la journée. Même si vous disposez d’une armée de commis, vous devez les former, et lorsque quelque chose d’entièrement inattendu se produit, vous vous retrouvez avec une armée qui n’a pas été formée pour cette situation spécifique. D’après mon expérience, plus vous avez de personnes à gérer, plus il faut de temps pour accomplir quoi que ce soit.

Il y a seulement quelques jours, un cargo a perdu plus de 1 800 conteneurs à cause de mauvaises conditions météorologiques. Ces choses arrivent simplement, et vous ne pouvez pas espérer les éliminer. La supply chain n’est pas comme la fabrication, où vous pourriez disposer d’un site de production avec tout bien contrôlé. 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 tant de forces échappant à votre contrôle qu’il faut être capable de gérer des événements surprenants. Vous savez déjà que les surprises se produiront, il faut donc être préparé. Être préparé ne signifie pas avoir tout soigneusement planifié ; 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’optimization de la supply chain ? Tout d’abord, nous avons besoin d’un stockage de données polyvalent pour représenter toutes les sources de données diverses. Il y a tant de choses que nous voulons représenter, donc nous voulons quelque chose de très polyvalent à 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 assembler toutes ces choses ? Vous ne pouvez pas acheter un produit standard qui aura tout préprogrammé pour vous ; cela ne fonctionne pas.

Ensuite, vous avez besoin d’interfaces utilisateur polyvalentes car la manière de visualiser 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 selon votre convenance ; sinon, cela constituera une grande limitation.

Vous souhaitez également disposer de capacités collaboratives car la supply chain est, par définition, un travail d’équipe. De nombreuses personnes sont impliquées, et c’est distribué, donc les capacités collaboratives 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. Cela est important pour plusieurs raisons. Premièrement, 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 recruter. 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 possédant des compétences dans les deux domaines. Il en serait de même si vous recherchiez quelqu’un à la fois programmeur et avocat, ou programmeur et médecin. Oui, vous trouverez quelques personnes avec ces compétences, mais pouvez-vous le faire à grande échelle ou embaucher de manière fiable davantage d’entre elles 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, vous devez avoir quelqu’un ayant une compétence en supply chain car il faut être capable, en quelques heures, d’appliquer les corrections de programmation à votre système sans ouvrir un ticket et le transmettre au service informatique. Si vous devez procéder de cette manière, cela prend 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 joli, et cela ne donne peut-être pas l’impression d’être le summum des logiciels modernes, mais ça fait l’affaire. Il 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 créer des graphiques en barres, des graphiques linéaires et de nombreuses manières de présenter des données. En termes d’interfaces utilisateur, il est très polyvalent. Il n’est peut-être pas le plus raffiné, mais en termes de polyvalence, il peut faire beaucoup de choses.

En ce qui concerne les capacités collaboratives, c’est un peu rudimentaire. Certaines versions d’Excel sont en ligne, ce qui est légèrement mieux, mais fondamentalement, vous pouvez partager vos feuilles de calcul. Le problème avec le manque de fonctionnalités collaboratives n’est pas qu’il s’agisse d’une application de bureau. Le problème réside dans la mentalité qui accompagne les feuilles de calcul, laquelle n’est pas adaptée à un travail collaboratif intensif. 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. Ainsi, le problème du manque de fonctionnalités collaboratives réside dans la mentalité inhérente aux feuilles de calcul, qui présente naturellement 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 des tâches plus complexes. En termes d’ingrédients, Excel coche toutes les bonnes cases, ce qui, je crois, explique en grande partie le succès opérationnel qu’il rencontre dans la plupart des supply chains.

D’après mon expérience, la majorité des supply chains mondiales, des plus petites entreprises aux plus grandes, et allant 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 compliqués pour l’optimization de la supply chain, sont pilotées par Excel. Il existe très peu d’exceptions. Parfois, des personnes 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.

Aujourd’hui, Excel est le moteur des supply chains à travers le monde, et je crois que ce n’est pas un hasard. Au fond, les feuilles de calcul répondent fondamentalement à bon nombre des problématiques pertinentes. 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 faites face à un problème majeur ou à une urgence, vous êtes dépourvu de solution. Les gens en viennent à recourir aux feuilles de calcul Excel dans des situations telles qu’un manque d’interface utilisateur polyvalente, ou lorsque qu’une solution n’est pas accessible aux non-développeurs. Si seule une équipe informatique peut apporter des résultats, les gens pourront d’abord ouvrir des tickets et attendre patiemment, mais en trois mois, tout le monde finira probablement par revenir à l’utilisation de feuilles de calcul Excel parce que c’est plus rapide. Excel n’est pas la solution finale, mais quel que soit le remplaçant supérieur que nous proposerons, il 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 évolutif. Traiter des millions de lignes devient problématique, même avec les versions modernes d’Excel capables de gérer un million de lignes. Des problèmes de performance apparaissent rapidement à 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 se retrouve dupliquée à l’infini, avec 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 sont toujours entremêlées avec l’interface. Des capacités collaboratives 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 supply chain offrent la collaboration sur les résultats, comme ajuster manuellement les prévisions et permettre à plusieurs personnes de participer. 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 quand vous souhaitez faire quelque chose d’un peu plus complexe, cela devient difficile. Dans la gestion de la supply chain, nous voulons prendre en compte tous les futurs possibles, ce qui signifie travailler avec des prévisions probabilistes, des variables aléatoires et gérer l’incertitude. Bien que cela soit possible dans Excel, c’est assez compliqué. Excel convient pour des tâches simples, mais pour des situations plus complexes, vous devez devenir un expert d’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 compliqué de créer quelque chose de vraiment précis, du moins dans le sens d’un produit logiciel.

Les mots à la mode du moment sont l’IA 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. Premièrement, il nécessite des ingénieurs logiciels. Bien que Python soit l’un des langages de programmation les plus accessibles, lorsque vous souhaitez faire quelque chose de plus complexe, il faut une équipe d’ingénierie logicielle, ce qui crée des défis lorsqu’il faut des personnes à la fois expertes en supply chain et en ingénierie logicielle.

Python possède 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 éléments de base qui offrent des capacités supplémentaires, et quand vous dites vouloir utiliser Python, ce n’est pas seulement le langage qui vous intéresse, mais aussi l’ensemble de l’écosystème de packages, 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 que cela s’améliore, les progrès sont lents. De nombreux aspects de la conception du système rendent les améliorations difficiles.

La performance est également médiocre, principalement par conception. La performance de calcul réfère à la qualité du travail effectué par Python pour exploiter la puissance de calcul brute disponible sur votre ordinateur. Étonnamment, Microsoft Excel réalise un travail bien meilleur à cet égard. Excel est hautement optimisé, tirant parti des systèmes multi-CPU et multi-core, 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 que sa performance est souvent 100 fois plus lente que ce que votre machine pourrait théoriquement offrir. 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 la sortie de la boîte.

L’idée d’utiliser une bibliothèque tierce comme NumPy pour pallier le manque de performance de Python ne fait qu’ajouter de la complexité. Vous pouvez résoudre le problème de performance, mais vous créez un nouveau souci en introduisant la complexité supplémentaire de NumPy, avec laquelle vous devez composer et que vous devez maintenir sur le long terme. Cela augmente également les exigences du côté de l’ingénierie logicielle.

Lorsque vous tentez de mettre en œuvre des solutions Python pour une véritable gestion de la supply chain, divers problèmes surviennent, tels que des exceptions de référence nulles, des exceptions de manque de mémoire et des temps de calcul prolongés. Vous pourriez vous retrouver à attendre 20 minutes que un calcul se termine, sans savoir s’il finira un jour ou s’il faut simplement tuer le processus et redémarrer. Je ne sais tout simplement pas, donc vous voulez des solutions où vous avez une très, très bonne idée du temps nécessaire à l’exécution. D’ailleurs, pour revenir à Excel, de nos jours lorsqu’une opération prend un peu de temps à se terminer, Excel vous fournira un indicateur assez fiable, une barre de progression indiquant le temps estimé. Encore une fois, vous voulez cela, et c’est en partie ce que j’appelle la préparation à la production. Vous voulez avoir quelque chose qui, encore une fois, permettra au logiciel que vous produisez de fonctionner sans surveillance, pendant la nuit ou lors du traitement par lots nocturne, par exemple. Vous voulez quelque chose qui ne nécessite pas qu’un data scientist surveille le tout.

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

Nous voulons donc avoir quelque chose qui s’améliore. D’ailleurs, la première chose que nous souhaitons améliorer est la défense en profondeur. Les ransomwares sont en hausse, et chaque fois que vous intégrez quelque chose de programmable dans votre organisation, vous vous exposez aux ransomwares. Car soudainement, quand vous avez un programme, celui-ci peut faire une multitude de choses, y compris détourner la machine même sur laquelle il s’exécute. Je sais qu’il existe des tas de moyens pour atténuer les problèmes ; vous pouvez isoler les éléments dans un bac à sable, restreindre, limiter les droits, et il y a plein de façons de limiter ces problèmes. Néanmoins, chaque fois que vous utilisez un langage de programmation générique à usage général, votre surface d’attaque – terme technique – est absolument gigantesque.

En gros, chaque fois que vous intégrez du code de cette manière, vous vous exposez massivement aux problèmes de sécurité. Et rappelez-vous, la méthode habituelle dans une entreprise d’ingénierie logicielle est que le code est relu par des pairs. Vous révisez donc le code, vous suivez un processus de revue, quelqu’un produit le code et un collègue va le vérifier pour s’assurer qu’il n’y a pas de bidouilles dedans. Mais si je reviens au fait que le logiciel doit être robuste, vous devez être en mesure de réagir en quelques heures. Du point de vue de l’optimisation de la supply chain, il ne sera tout simplement pas possible d’instaurer un processus de revue de code. Ce n’est tout simplement pas compatible avec les délais et les urgences auxquels vous serez confronté.

Vous devez donc avoir quelque chose qui vous offre une défense en profondeur par conception. Ensuite, vous voulez quelque chose avec 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 futiles, comme si vous aviez une fenêtre de deux heures pour livrer les résultats et que vous soyez en retard. Et vous savez quoi ? Les camions sont déjà partis. Il est trop tard. Vous avez donc besoin d’une solution où tout est pris en charge.

Et il en va de même pour les mises à jour transparentes. C’est là la beauté d’Excel. Vous n’avez pas à vous soucier de la maintenance d’Excel. Microsoft a conclu, il y a des décennies, un pacte de sang : si vous avez produit une feuille de calcul Excel, quelle que soit la prochaine version d’Excel qui arrivera sur le marché, elle pourra prendre en charge vos feuilles de calcul. Et le plus incroyable, c’est que si vous regardez Excel aujourd’hui, il supporte de nombreux formats Excel concurrents 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. Ainsi, la proposition de valeur de Microsoft en termes de mises à jour transparentes est que la logique que vous avez produite fonctionnera indéfiniment, 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 vous constatez lors de la transition de Python 2 à Python 3 ; ce fut un cauchemar et cela a pris une décennie. Ainsi, Python est excellent pour de nombreuses choses, mais imaginez que ces mises à jour surviennent aux pires moments, lors de la pire pandémie, du pire tarif, de la pire urgence, et que vous ayez besoin que tout soit opérationnel et prêt. Vous ne pouvez pas vous permettre une indisponibilité de six mois simplement pour effectuer une mise à jour. Ce n’est pas quelque chose de compatible avec l’optimisation de la supply chain.

Il faut donc maintenant réfléchir à ce que serait une solution conçue réellement en pensant à la supply chain. Ce sera le sujet de la prochaine conférence.

De plus, la supply chain n’appartient pas à la division IT. Quand je parle d’une livraison orientée produit, ce n’est pas que le logiciel n’est qu’un moyen et non une fin. Vous ne vendrez pas votre logiciel sous forme de licences ou de frais, comme le fait, par exemple, Microsoft. Dans la vision que je vous expose dans cette conférence, l’IT est responsable des pratiques fondamentales, des pratiques IT de base, telles que ce que vous devez ou ne devez pas faire en termes de sécurité, de sauvegardes, d’infrastructure essentielle, de votre réseau, de la gestion et de la synchronisation de toutes les données au niveau de l’entreprise, ainsi que de fournir toute l’orientation et le coaching.

Mais l’idée est que la supply chain doit être propriétaire des décisions de la supply chain. Elle doit posséder tout l’appareil qui génère ces décisions, c’est cela qui constitue son cœur de propriété. Dans la conférence précédente, j’ai défini le Supply Chain Scientist : le Supply Chain Scientist est celui qui détient les décisions numériques produites par le code. Il ne s’agit pas d’un système qui produit des décisions ; ce sont des recettes numériques rédigées par un ou plusieurs Supply Chain Scientist, et ces Supply Chain Scientist possèdent collectivement ces décisions numériques. Ils en assument la responsabilité, et la mission de la supply chain est de s’assurer que toutes les décisions prises 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 pour être opérationnels. Vous ne voulez pas vous retrouver dans une situation catastrophique où vous lancez quelque chose alors que vous êtes déjà en situation de rupture de stock, où vous dépensez de l’argent pour une campagne marketing pour un produit que vous ne pouvez même pas vendre parce que vous n’avez pas le stock ou la capacité de le fabriquer ou de fournir le service à temps, etc.

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 ne se contente pas de traiter des tickets. Ce n’est pas ainsi que cela fonctionne. Le département IT est en charge de l’infrastructure essentielle. C’est ce type de système qui fonctionne de manière transparente en permanence. Vous n’y prêtez même pas attention, tout comme vous ne remarquez le Wi-Fi que lorsqu’il ne fonctionne pas. Un bon département IT fournit toute l’infrastructure de manière à ce que vous ne remarquiez même pas leur présence. Vous ne réalisez même pas qu’ils existent, tant tout fonctionne parfaitement, tout comme vos e-mails fonctionnent impeccablement, etc. Voilà ce qu’est une bonne IT de base. Ensuite, l’IT est le genre de service qui vient à vous pour vous aider à mettre en place toutes ces pratiques qui vous facilitent la vie. La logique programmable est un peu complexe, alors parfois, où trouver le coaching pour vous améliorer en programmation ? Eh bien, la réponse est que cela devrait relever de l’IT. Ils ne devraient pas venir pour dire “Nous allons coder cela pour vous”, mais plutôt “Nous allons vous coacher afin que vous puissiez l’implémenter vous-même. Nous vous aiderons sur quelques concepts, peut-être avec des aspects un peu plus techniques qu’ils ne devraient l’être.” Parfois, vous faites face à une complexité accidentelle, et l’IT est alors 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, veillant à ce que personne ne commette une erreur fatale qui exposerait toute l’entreprise à un risque, comme celui d’un ransomware ou à un risque systémique du point de vue IT.

À titre de test probant, si votre interaction entre l’IT et la supply chain se fait par le biais de documents énumérant spécifications ou exigences, ce n’est pas la bonne manière d’entretenir une relation saine entre ces deux divisions. Quand je parle d’une bonne relation, je veux dire quelque chose qui apportera 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 faisait peut-être de la programmation mais uniquement en périphérie avec des feuilles de calcul Excel, sans même réaliser initialement 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ée de livrer un produit qui fonctionne comme un produit logiciel, et cela représente un changement énorme. Oui, mais c’est quelque chose avec lequel vous pouvez faire face. Pourquoi ? Parce que si vous disposez des bons outils, oui, il y a de la programmation impliquée, mais ce n’est pas fondamentalement, radicalement plus difficile que dans Excel. Encore une fois, le défi ne réside pas dans la technicité de l’outil ; c’est littéralement dans la complexité même de la supply chain. Le problème n’est pas difficile parce que votre outil est compliqué à utiliser, mais parce que vous avez, dès le départ, une supply chain complexe.

Pour la partie de l’audience qui se situe peut-être davantage du côté des data scientists ou de l’informatique, ce qu’il faut surmonter, c’est la surestimation de ses capacités. J’ai vu, encore et encore, des data scientists – et je m’inclus dans cette catégorie – qui étaient trop confiants dans leur capacité à mettre un prototype en production. C’est difficile, et les supply chains ont une manière de vous exploser la figure de la façon la plus surprenante. Je ne me souviens que d’une anecdote où, il y a des années, nous avons commencé avec un leader européen du e-commerce de pièces automobiles. Nous gérions leurs réapprovisionnements de pièces grâce à notre technologie de prévision, en faisant des suggestions pour le réapprovisionnement de pièces, servant des pièces automobiles. La semaine suivante, nous avons constaté que toutes nos prévisions étaient faussées par un facteur de deux. La demande avait doublé. Ce qui s’était passé, c’est que leur concurrent numéro un avait décidé de s’étendre 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 sur toutes les chaînes de télévision nationales et de commencer à diffuser son service en ligne. Ce qui est intéressant, c’est que mon client n’était même pas au courant de cela, et ils obtenaient de bien meilleurs résultats en termes de search engine optimization (SEO). Les gens voyaient la publicité télévisée du concurrent, mais ils ne se rappelaient pas naturellement du nom de ce concurrent. Ils allaient donc sur Google et tapaient “car parts” jusqu’à atterrir sur le site de mon client. Pour démontrer à quel point Lokad était incroyable, la première semaine où nous avons commencé, nous étions faussés par un facteur de deux, et nous pensions, “Mais qu’est-ce qui se passe ?” Nous avons dû tout revoir, car lorsque la demande double, ce n’est pas que tout double ; certaines choses font x10, et beaucoup d’autres restent inchangées.

Donc, c’est ce genre de situation, et il faut être capable de réagir rapidement. Il s’agit avant tout de peur et de surestimation. Merci beaucoup pour votre temps.

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

Question: Le logiciel peut-il prendre la décision de choisir avec quel fournisseur passer une commande supplémentaire en cas de besoin de plus pour demain ? Par exemple, des barquettes de 200 grammes de fraises dans des bureaux en Australie peuvent impliquer que 10 fournisseurs livrent 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 côté gestion de la supply chain, qui consiste littéralement à avoir en place tous les data pipelines, y compris l’EDI, qui vous permet de transmettre une commande électronique à un fournisseur sans intervention humaine. Vous disposez donc d’un pont électronique de bout en bout. Mais cela signifie ensuite qu’il faut avoir, du côté de l’optimization, un logiciel qui s’exécute 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.” Ensuite, du côté de la gestion, qui est pris en charge par l’informatique, on s’assure simplement que cette commande est entièrement exécutée. Il s’agit simplement d’une question de pure transactionnalité ; il n’y a plus d’intelligence. Vous recevez une commande qui indique “cette quantité”, et c’est du côté de l’optimization qu’il incombe de vérifier que, lorsque vous générez une certaine quantité, vous respectez toutes les contraintes, comme la liste exacte des fournisseurs même éligibles à fournir ces produits, qu’ils aient du stock disponible, et comment faire le bon choix parmi tous les fournisseurs concurrents, etc. Il peut se passer beaucoup de choses. Absolument, oui, mais nous devons littéralement séparer l’exécution banale, qui relève de la partie transactionnelle de la gestion de la supply chain, de l’ingrédient d’optimization au moment où vous décidez de recommander davantage.

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 pour le 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 PDG de l’entreprise, je désapprouve fermement.

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

Eh bien, absolument. On ne peut 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 même avant que n’importe quel logiciel de gestion de la supply chain soit en place. Même si l’on remonte 60 ans en arrière, à une époque où il n’y avait pas de logiciel, les gens devaient tout de même prendre des décisions. L’optimization de la supply chain était déjà chose faite ; les gens s’en occupaient avec du papier et un crayon. 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 les logiciels. Donc oui, l’optimization de la supply chain est quelque chose qui se fait dès le premier jour, que vous disposiez ou non de logiciels dans votre organisation.

Maintenant, en effet, il faut disposer de systèmes informatiques adéquats, mais c’est un état d’esprit complètement différent. La gestion de la supply chain consiste à réaliser très bien des tâches banales, comme la saisie de données, potentiellement avec le support des codes-barres et d’autres fonctionnalités. Il s’agit de tâches très banales, se contentant de représenter les données. 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 au final, vous vous retrouvez avec un produit surcompliqué, généralement truffé de bugs, et vous devez intégrer de mauvaises fonctionnalités comme des alertes et des exceptions, ce 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 possédez 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 cela de vos décisions.

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

La première chose est que vous devez réaliser, dès le départ, qu’il y a deux problèmes, et qu’une même pièce de logiciel ne pourra jamais aborder les deux volets. Je pense que c’est la grande illusion, et les fournisseurs de logiciels ont été incroyablement déroutants dans ce domaine. Si vous regardez les plus grands fournisseurs d’ERP, leur message porte sur l’optimization de la supply chain, mais tout ce qu’ils livrent réellement et tout ce que fait leur produit se situe du côté de la gestion de la supply chain, ce qui est beaucoup moins sexy car il n’y a ni IA ni véritable intelligence. Dans le monde du logiciel, on parle d’applications CRUD (Create, Read, Update, Delete). Les ERP ne sont que d’immenses 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 fondamentalement, en simplifiant un peu, une collection de milliers de tables pour différentes entités. Pour chaque entité pouvant être regroupée logiquement, vous disposez d’un ou deux écrans, et c’est tout. Donc, pour revenir à votre question sur la gestion, le problème est que si vous êtes manager, vous lisez la brochure du fournisseur d’ERP, et celui-ci vous affirme que son produit va optimiser votre supply chain. La réponse est : non, absolument pas. Ce qu’il fera, c’est améliorer la productivité et assurer une comptabilité précise de votre supply chain. Cela représente déjà beaucoup, car cela peut réduire considérablement le vol, la détérioration, les marchandises égarées, et améliorer la productivité grâce aux codes-barres dans un entrepôt. Ces produits offrent 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 par conception quelque chose qui se soucie de l’entrepôt ; il ne se préoccupe pas de l’ensemble de la supply chain qui inclut clients et fournisseurs. Il est par conception axé sur des emplacements spécifiques, et non sur l’ensemble de 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 par le passé. Pour le public, Envision est un langage de programmation spécifique à un domaine, conçu par Lokad, qui a été développé uniquement pour le predictive optimization des supply chains. Dans la conférence suivante, je vais démontrer Envision afin que chacun puisse mieux comprendre de quoi je parle, avec de véritables extraits de code.

Historiquement, nous avons utilisé Python et Envision ensemble car, lorsque nous avons commencé, Envision avait des capacités très limitées, de sorte qu’il manquait de nombreuses fonctionnalités, et nous avions alors recours par défaut à Python dans de nombreuses situations. Au fil des ans, nous avons progressivement élargi les capacités d’Envision, ce qui nous a permis d’éliminer progressivement la nécessité de composants Python. Il ne s’agit pas seulement de composants Python ; c’est 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 conçue pour être en phase avec celle de Python à bien des égards. J’ai fait le choix conscient de concevoir la syntaxe d’Envision de manière à ne pas être antagoniste envers les programmeurs Python, afin que, si vous êtes familier avec Python, vous puissiez apprendre Envision en une semaine. Elle diffère de façon subtile et profonde, mais au niveau de la syntaxe, de nombreux aspects sont identiques. Python possède de nombreux mérites, tels que la simplicité et la pureté de son design. Même si je dis que Python ne coche pas toutes les cases et crée de graves problèmes en production qui ne peuvent être résolus, cela ne veut pas dire que Python est sans 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, la pire situation, c’est lorsqu’un prospect vient me voir et dit : “Notre ERP, un ERP hérité, ne fournit 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 volet 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, notamment pour ces produits AS/400 dotés d’un terminal en ligne de commande sur d’anciens mainframes IBM. Du côté de la gestion, ils font généralement un travail très correct. 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 ? J’en doute. Les lignes de commande avec des terminaux en mode texte peuvent être incroyablement réactives et productives, sans aucune distraction.

C’est donc assez difficile, car 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 quelque chose comme l’IA ou la blockchain, mais simplement 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, car il faut des heures pour aller au fond du problème et expliquer pourquoi nous devons le voir comme je le vois.

Question: Quelle est votre recommandation pour une plateforme afin 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 qu’étant le PDG de Lokad et le principal propriétaire de l’entreprise, j’ai, à mon sens, un conflit d’intérêts. Je suis profondément convaincu que Lokad est la plateforme qu’il vous faut, 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.

D’ailleurs, Lokad a été littéralement conçu pour traiter la distribution de demande probabiliste, et il ne s’agit pas seulement de la distribution de demande probabiliste. Il prend également en charge la distribution stochastique des délais d’approvisionnement, la distribution stochastique des retours, et bien plus encore. Nous devons envisager tous les futurs possibles avec des probabilités, en tenant compte de tous les types d’incertitudes. La demande est un aspect très important, généralement le plus important, mais ce n’est pas le seul.

Je pense avoir répondu à toutes les questions. Je vérifie rapidement si j’ai manqué quelque chose… Plus aucune question. 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 : Et sur divers sujets, occasionnellement liés, qui s’avéreront d’intérêt pour les développeurs de logiciels, les designers et les managers, ainsi que pour ceux qui, par bonne ou mauvaise fortune, collaborent avec eux d’une certaine manière - Par Joel Spolsky, 2004