00:00:00 Deployment chapter and practitioner framing
00:04:35 La simplicité surpasse la complexité traditionnelle de la supply chain
00:09:10 Unattended decisions avoid workflow detours
00:13:45 Change management mostly removes needless work
00:18:20 Les décisions finalisées raccourcissent considérablement la mise en œuvre informatique
00:22:55 Les données d’entreprise désordonnées relèvent de la responsabilité du fournisseur
00:27:30 Survival proves data is already sufficient
00:32:05 Les Supply Chain Scientists sont responsables des décisions rentables
00:36:40 One mind prevents fragmented numerical recipes
00:41:15 Explainability needs ownership and white-boxing
00:45:50 Explanations start when decisions actually appear
00:50:25 Insane decisions reveal missing constraints and fields
00:55:00 Profitable decisions may break old habits
00:59:35 Post-deployment means maintenance against structural drift
01:04:10 Continuous improvement expands decision scope over time
01:08:45 Aucune valeur sans décisions finales
01:13:20 Dix semaines devraient montrer de réels progrès
01:17:55 La confiance prend des mois ; testez d’abord les problèmes les plus difficiles
Résumé
Joannes Vermorel and Conor Doherty continue their chapter-by-chapter discussion of Introduction to Supply Chain. Le chapitre dix se tourne vers le déploiement : le travail pratique consistant à mettre en production les décisions automatisées de la supply chain, à les rendre fiables et à garantir qu’elles remodèlent les opérations quotidiennes plutôt que de rester un prototype.
Résumé détaillé
This discussion of deployment cuts through a great deal of fashionable nonsense in enterprise software. Le point central n’est pas compliqué : le but d’une initiative de supply chain n’est pas de produire des tableaux de bord, des flux de travail, des cartes de pointage ou d’autres artefacts décoratifs de gestion. Son objectif est de produire de meilleures décisions. Si un soi-disant déploiement ne se termine pas par des décisions inattendues, vérifiables et économiquement rationnelles, alors une grande partie de ce qui le précède n’est, au mieux, qu’une cérémonie.
A recurring error in the industry is the confusion of complexity with sophistication. De nombreuses entreprises adoptent des couches de segmentation, de remplacement, d’alertes et de workflows d’approbation, car ces éléments semblent prudents. En pratique, ils créent souvent plus de code, plus d’exceptions, plus d’ambiguïté et plus de possibilités d’échec. Ce qui semble « plus sûr » devient plus difficile à maintenir, plus lent à améliorer et plus facile à rejeter sur tout le monde et sur personne. En revanche, un système conçu dès le départ pour générer des décisions définitives est plus difficile en principe mais plus simple en pratique.
Un autre point important concerne les données. On dit souvent aux entreprises que leurs données sont trop compliquées pour permettre l’automatisation. Cette excuse perdure car elle est utile aux fournisseurs dont les systèmes tombent en panne. Mais toute entreprise encore en activité à grande échelle possède déjà des données suffisamment bonnes pour faire fonctionner sa supply chain, sinon elle aurait fait faillite depuis longtemps. Le problème n’est pas de savoir si les données sont ordonnées. Les vrais systèmes d’entreprise ne le sont jamais. La question est de savoir si les personnes qui élaborent la solution sont suffisamment compétentes pour faire face à la réalité plutôt que d’exiger un ensemble de données imaginaire.
The role of the supply chain scientist, as described here, is therefore not narrow. Il ne s’agit pas simplement de préparation de données, ni de modélisation, ni d’optimisation isolément. C’est la propriété de la recette numérique complète, des données brutes jusqu’à la décision finale. Répartir cette responsabilité entre spécialistes peut sembler efficace, mais cela entraîne généralement des échecs. Ce qu’il faut, c’est un esprit qui comprend suffisamment bien toute la chaîne pour la rendre cohérente et l’expliquer.
L’explicabilité elle-même est traitée ici de manière pratique plutôt que théâtrale. Vous n’expliquez pas les abstractions pour elles-mêmes. Vous expliquez les décisions. Et l’explication doit finalement se payer en économie : pourquoi cet ordre, pourquoi ce prix, pourquoi maintenant, pourquoi pas plus tard ? Si la réponse ne peut pas être formulée en termes de gains, de pertes, de risques et de compromis, alors l’explication est probablement ornementale.
La leçon plus large est que le déploiement doit être jugé en fonction de son ambition et de sa rapidité. Visez d’abord le problème réel le plus difficile, et non un problème de jouet facile. Exigez des résultats utiles en quelques semaines, et non de vagues promesses en années. Si un fournisseur ne peut pas démontrer rapidement sa capacité à prendre des décisions, tout retard ne guérira pas son incompétence.
Transcription complète
Conor Doherty: Bienvenue à nouveau. Il s’agit de l’épisode 10 d’une série très spéciale dans laquelle Joannes et moi prenons son nouveau livre, Introduction to Supply Chain, et discutons des idées chapitre par chapitre. Maintenant, pour cette série spécifique, j’assume une posture bien particulière. Comme vous le savez, je prétends ne pas être quelqu’un qui travaille chez Lokad. Je n’ai jamais entendu parler de Supply Chain Quantitative. Je ne connais certainement pas Joannes et je n’ai pas travaillé avec lui depuis près de quatre ans.
Je fais semblant d’être l’un des quelque 10 millions de pratiquants dans le monde qui pourraient voir ce livre, être curieux, commencer à lire, puis avoir des questions. Aujourd’hui, c’est le chapitre 10. Cela signifie, bien sûr, qu’il y en avait neuf avant cela. Je vous recommande fortement de les regarder en premier, car les sujets dont nous avons discuté aujourd’hui seront très certainement construits sur le matériel couvert dans les épisodes précédents.
Et sur ce, Joannes, commençons. Chapitre 10, déploiement. Maintenant, je vais immédiatement violer la posture que je viens de promettre à tout le monde, et je dirai que, vous savez, Conor, qui travaille ici, les chapitres quatre, c’est l’économie, et le chapitre huit, c’est les décisions, ce sont probablement mes favoris personnels. Eight est probablement celui sur lequel je reçois le plus de retours, excusez-moi, de la part de personnes qui connaissent Lokad.
Mais si j’y pense vraiment du point de vue d’un praticien, comme quelqu’un qui lit le livre et qui lit les premiers chapitres et pense : « J’aime vraiment cette approche. J’aime vraiment l’idée d’un classement financier quantitatif des décisions. Je réfléchis vraiment à la demi-vie d’une décision. Genre, je suis tout à fait d’accord pour ça. Ils auront une question très simple : « À quoi ça ressemble ? » Par exemple, que se passe-t-il si mon patron me dit : « C’est une excellente idée, mais à quoi cela ressemblera-t-il ? Quels sont les rôles ?
Le chapitre 10 est l’endroit où vous abordez réellement ce sujet. Nous allons donc parler des tenants et des aboutissants de tout cela, mais à un niveau élevé, pour commencer, à votre avis, qu’est-ce qui fait qu’un déploiement fonctionne réellement, et qu’est-ce qui fait qu’il échoue de manière catastrophique ?
Joannes Vermorel: Pour Lokad, les entreprises dans lesquelles nous réussissons sont essentiellement celles qui nous permettent de poursuivre nos efforts. Et cela peut paraître idiot, mais fondamentalement, cela n’a rien à voir avec la maturité. Ainsi, vous en voyez certains discuter avec de nombreux directeurs de la supply chain et dire : « Oh, nous avons besoin d’un certain degré de maturité », et là, je ne suis pas d’accord, car de quelle maturité parlons-nous ?
Si par maturité vous entendez l’adhésion à des théories erronées de la supply chain, alors aller plus loin dans cette voie ne vous aidera pas à réellement réussir avec Lokad, mais aussi simplement à réussir au niveau de la supply chain. Vous voyez, la position que j’adopte dans ce livre, je veux dire, ce livre est présenté comme une nouvelle introduction à la supply chain. Je ne parle donc pas longuement de tout ce qui ne fonctionne pas, mais vous pouvez le lire comme essentiellement ce qui fonctionne, par opposition à la théorie traditionnelle de la supply chain qui est essentiellement une longue liste ou un ensemble de choses qui ne fonctionnent pas dans la pratique.
Et donc il y a toutes ces choses, comme les prévisions ponctuelles, la microgestion du taux de service, avoir une approche dans laquelle vous gérerez votre supply chain via des alertes et des exceptions, tout basé sur des règles, des remplacements manuels pour tout, etc., etc. En fin de compte, lorsque Lokad réussit, ce sont essentiellement des endroits qui nous donnent simplement une solide chance d’essayer quelque chose qui est généralement d’un ordre de grandeur plus simple que ce qu’implique la supply chain classique.
Parce que le problème est que, parce que la théorie dominante de la supply chain est complètement brisée, elle finit par être un cauchemar de complications dans la pratique. Vous voyez, dès que vous avez réellement une théorie correcte, alors tout est plus simple. Le logiciel est plus simple, les mathématiques sont plus simples, la logique est plus simple et le type de livrable atterrit beaucoup plus proprement, ce qui est comme les décisions, les décisions optimisées et ajustées au risque, atterrissent beaucoup plus proprement à la fin de l’initiative.
Donc, je dirais, peut-être que s’il y avait une chose à retenir, c’est de ne pas poursuivre une théorie qui finira par échouer, peu importe qui est chargé de la mettre en œuvre. Chez Lokad, nous essayons d’inciter nos prospects et clients à s’en tenir réellement à ce qui fonctionnera. Mais finalement, s’ils nous donnent des ordres directs, il devient très difficile de réussir contre la volonté du client.
Conor Doherty: Vous savez, pour enchaîner sur cela, juste pour clarifier, excusez-moi, quand vous dites “un ordre de grandeur”, vous ne faites que donner des chiffres, mais disons un ordre de grandeur plus simple, voulez-vous dire qu’en termes de déploiement, c’est un ordre de grandeur plus simple ? Ou voulez-vous dire qu’en termes de livrable, c’est un ordre de grandeur plus simple à gérer ?
Plus simple en termes de calendrier, combien de jours faut-il pour qu’un système soit opérationnel ? Combien d’heures de travail devez-vous investir ? Quelle perturbation est nécessaire ? Je veux dire, par exemple, un exemple s’il vous plaît.
Joannes Vermorel: Si vous commencez par, disons, quelque chose comme l’analyse ABC, que vous aimez, ou tout type de segmentation inventée, alors vous voyez que vous n’en aviez pas besoin. C’est comme une solution pseudo-évidente à un problème inexistant. Alors les gens pensent : « Oh oui, nous devons aborder cela en faisant varier la qualité de service ou quelque chose comme ça, à travers une segmentation ». La réponse courte est non, vous n’avez pas besoin de cette segmentation.
Et si nous sommes contraints à une segmentation, alors nous finissons par avoir tellement de lignes de code qui vont être : si catégorie A, alors ceci et ceci et cela ; si catégorie B, alors ceci et ceci et cela. Si nous avons un produit qui est passé du B au A récemment, nous avons besoin de ceci et de cela et de cela. Si c’est passé d’un point A à un point B récemment, alors nous avons besoin de quelque chose. Donc, vous voyez, c’est juste une idée qui semble que la théorie dominante adopterait et aimerait absolument une segmentation.
Et cette chose, au niveau du code, se transformera en un labyrinthe de cas extrêmes, ce qui signifie plus de lignes de code, plus de bugs, plus, je dirais, de décisions insensées qui sortiront du pipeline de données à la fin de la journée. Il faut donc plus de temps pour que les gens examinent réellement les chiffres. Vous avez besoin de plus de rapports pour donner un sens aux chiffres, etc., etc. Vous voyez, ces choses se superposent les unes aux autres.
Et le genre de choses que fait Lokad, cela peut paraître compliqué, comme la prévision probabiliste, mais ce n’est pas le cas, car c’est un moyen d’éliminer littéralement des classes entières de problèmes et d’exprimer, en quelques lignes de code seulement, des choses qui autrement nécessiteraient des milliers de lignes de code. C’est l’essentiel. Je dirais que nous devons poursuivre ce qui est en réalité simple, et non ce qui semble simple, qui est en fait simpliste et qui se traduit donc par des tonnes de règles et de cas extrêmes et, je dirais, par des complications en aval.
Conor Doherty: Donc, pour poursuivre sur ce sujet, et je veux être très attentif à ne pas fusionner trop d’idées, donc juste pour le cadrer un peu plus concrètement, une des choses que vous argumentez au chapitre 10, encore une fois je paraphrase, mais c’est très fidèle, vous soutenez que dans le contexte d’un déploiement, concrètement en termes de livrable, vous ne recherchez pas une meilleure visibilité. Vous ne recherchez pas de meilleurs tableaux de bord. Vous ne recherchez pas de meilleures prévisions.
L’intérêt d’un déploiement, certainement dans une perspective d’optimisation de la supply chain, est de produire des décisions spontanées et auditables, celles-ci étant par exemple des bons de commande, des transferts, des plannings ou des modifications de prix qui sont ensuite réécrites dans vos systèmes opérationnels. Oui. C’est plus simple. C’est ce que vous faites valoir.
Joannes Vermorel: Encore une fois, et l’important est sans surveillance. Ainsi, par exemple, si vous décidez cela, si vous dites : « Oh, la barre est si haute, sans surveillance. Vous voulez vraiment être capable de bien faire les choses comme ça, sans étape intermédiaire, directement vers les bonnes choses. Et je dis oui, car quelle est l’alternative ?
L’alternative consiste à concevoir un flux de travail très complexe dans lequel les utilisateurs peuvent intervenir, effectuer toutes sortes de remplacements et, à la fin, nous générons les allocations de ressources, les décisions réelles. Combien dois-je acheter ? Combien je produis ? Où dois-je mettre le stock ? Dois-je augmenter ou baisser le prix ? Donc, si vous décidez que nous allons directement prendre des décisions sans surveillance, ce que vous voulez évidemment, c’est dire : « D’accord, je n’accepterais pas de décisions sans surveillance qui sont tout sauf excellentes ». Ils doivent être généralement bien meilleurs que ce que les gens pourraient produire manuellement.
Je dis, très bien, pas de problème. C’est tout à fait un critère juste. Et ce que je dis, c’est que c’est ce que nous devrions viser dès le premier jour. Et vous voyez, si vous essayez, vous dites : « D’accord, nous voulons le faire de manière surveillée, avec un flux de travail en plusieurs étapes », et etc., alors votre processus, qui était censé être l’optimisation de la supply chain, se transforme en la conception d’un flux de travail, et alors, comme vous le voyez, ce n’est tout simplement plus le même objet.
Et fondamentalement, au lieu de consacrer du temps à la question : “Est-ce que je conçois un système qui maximise réellement le taux de rendement de chaque ressource allouée que j’alloue tout au long de ma supply chain ?” qui est le jeu auquel nous jouons, il se dissout dans quelque chose où vous devez sonder les opinions de chaque personne, puis vous devez optimiser la productivité parce que le flux de travail consiste à « laisser les gens intervenir », donc cela prend du temps.
Il y a donc toutes sortes de compromis en jeu. Si vous donnez plus de flexibilité, les gens peuvent dire : « Oh, alors j’ai plus de leviers », mais cela crée alors des complications, car vos employés risquent alors de consacrer trop de temps au flux de travail. Et puis si les décisions finales s’avèrent fausses, à qui la faute ? Cela brouille complètement la responsabilité.
Surtout si le flux de travail implique une demi-douzaine de personnes effectuant de petits rebondissements, progressivement, il devient alors extrêmement difficile d’identifier qui est à blâmer. Vous devez donc faire une analyse de causalité sur tous ces départements. Et vous voyez, c’est comme ça que nous avons commencé avec quelque chose qui était : « Passons directement aux décisions les plus rentables », vers quelque chose où nous avons été complètement distraits, où nous commençons à concevoir un flux de travail et des interfaces utilisateur et à surveiller ce que font les gens et à optimiser la productivité, etc.
Vous voyez, c’est ainsi que vous pouvez vous retrouver avec quelque chose qui est d’un ordre de grandeur plus lent, plus compliqué, simplement parce que vous avez réellement fait quelques choses qui semblaient plus simples au départ. Non, non, ce n’est pas le cas. Encore une fois, c’est, pour nous, un véritable critère de réussite, c’est d’être capable d’aller droit au but en maximisant la rentabilité, sans détour par les workflows, sans détour par des artefacts numériques inventés comme les segmentations et ainsi de suite.
En fin de compte, vous ne vous souciez pas d’ABC. Ce qui vous importe, c’est si je maximise réellement le retour sur investissement ? Que je tranche et découpe mes SKU à travers les cours, à travers ceci, à travers cela ou à travers quoi que ce soit, n’a pas d’importance. Je veux dire, si ce que vous voulez, c’est maximiser, encore une fois, le taux de rendement dans une perspective à long terme, ce qui signifie que vous n’adoptez pas une perspective à court terme, je dirais, destructrice, vous voulez valoriser la qualité du service car elle compte tout en protégeant vos intérêts à long terme, et tout cela sera dans le taux de rendement. Sinon, c’est simplement que vous avez un critère simpliste qu’il faut ajuster.
Conor Doherty: Oui. Et quelque chose que vous avez dit là en particulier, encore une fois, l’idée de parler aux praticiens, que ce soit simplement lors d’une conférence, en faisant des podcasts comme celui-ci, qu’il s’agisse d’un appel professionnel, peu importe, l’une des choses qui revient est la gestion du changement. Et quelque chose que vous avez dit là-bas, je vous ai demandé, par exemple, ce qui différenciait un succès d’un échec, et vous avez répondu, vous savez, les entreprises vous permettent en quelque sorte de faire votre truc.
Et j’ajouterais à cela, c’est-à-dire accepter que dans la gestion du changement, cela signifie que dans le titre, il y aura au moins quelques changements. Et le changement sera que vous vous éloignerez de ce que vous venez de décrire, la segmentation, la commande manuelle, la supervision. Vous devez accepter que vous allez dans le sens de l’automatisation, des décisions sans surveillance.
Joannes Vermorel: Et encore une fois, je pense qu’une partie du problème réside également dans le fait que le changement apporté par Lokad est extrêmement limité et principalement soustractif. Vous voyez, c’est là que les gens sont très, parfois très, très confus. Lokad n’exige pas de réingénierie des entreprises de nos clients. Le changement que nous apportons est presque entièrement soustractif, supprimant des choses, et c’est tout.
Vous n’avez donc pas besoin de repenser les descriptions de poste de beaucoup de personnes, ni de vous recycler. C’est essentiellement parce que, encore une fois, nous visons des processus de prise de décision sans surveillance, oui, ils sont conceptuellement plus simples à tous les niveaux. C’est plus simple pour l’informatique. C’est plus simple pour les praticiens de la supply chain. C’est plus simple pour le top management. C’est en fait plus simple pour tout le monde.
Il ne s’agit donc pas tant de « Oh, nous avons tellement de changements, nous aurons tellement besoin d’apprendre », plutôt que de désapprendre tout ce qui n’est tout simplement plus pertinent. Vous voyez, pensez-y comme à ces vieilles machines à écrire, les mécaniques. Il fallait les huiler. Il fallait pouvoir changer le ruban encreur. Parfois, il fallait prendre…
J’en avais un quand j’étais jeune. Je veux dire, si vous vouliez utiliser une machine à écrire mécanique à titre professionnel, cette chose nécessitait beaucoup de petits entretiens. C’est littéralement un petit truc d’horlogerie. Et si vous allez sur un ordinateur, tout à coup, il disparaît. Votre clavier fonctionne, et si votre clavier est mort, vous achetez simplement un nouveau clavier et c’est tout.
La quantité de connaissances dont vous avez besoin pour utiliser un clavier moderne, par rapport à une machine à écrire à l’ancienne, est bien moindre. Vous voyez donc, la gestion du changement est très soustractive. Des tonnes de choses ont disparu. Et c’est peut-être vraiment la partie qui pourrait être la plus déroutante pour les prospects lorsque nous discutons avec eux. Ils s’attendent, en fait, à beaucoup de changements dans le sens : « Oh, nous devrons recycler les gens, nous devons ajouter ceci et ajouter cela », et il y en a très peu. C’est très très peu.
Pour l’informatique, Lokad ne représente, je dirais, qu’une infime fraction de l’effort requis par un système classique. Donc pour l’informatique, c’est beaucoup moins. Certes, pour un pilote, le frottement est généralement très faible. Il s’agit essentiellement d’envoyer des fichiers bruts, des fichiers plats en ligne extraits du système, sans aucun prétraitement, du copier-coller, simplement du dump et du transfert.
Conor Doherty: Ce qui est un point clé. Désolé, c’est en fait un point clé que nous venons de passer sous silence, à savoir le faible impact que cela représente par rapport à “Nous avons besoin d’un processus de mise en œuvre de deux ans juste pour le préparer”. Ne dépassez pas ce point à nouveau.
Joannes Vermorel: Oui. La raison en est, encore une fois, de par sa conception, la façon dont Lokad fonctionne est que nous voulons que ce moteur de prise de décision fonctionne sans flux de travail. Donc, je veux dire, le flux de travail est super minimaliste : données entrantes, décision retirée, et nous avons terminé.
Et donc il y a tellement de choses qui ne sont tout simplement pas nécessaires. Nous n’avons pas besoin de nous resynchroniser avec l’ERP, des tonnes de choses compliquées, voyez-vous, car au final, ce que nous produisons, ce ne sont que des décisions finalisées qui sont très simples à réimporter ensuite dans l’ERP. Si vous souhaitez générer, disons, un bon de commande, seuls le produit, la quantité et le fournisseur sont concernés, et c’est tout. La structure des données, bon de commande finalisé, est très, très simple.
Contrairement à si nous voulons, disons, gérer beaucoup de segmentations, les resynchroniser avec l’ERP, donner aux gens la possibilité de faire toutes sortes de choses dans Lokad puis les resynchroniser dans l’ERP, c’est le genre de chose que la plupart de mes pairs proposeraient. Et c’est pourquoi la mise en œuvre prend une éternité, car encore une fois, il y a tellement de couches d’artefacts numériques, des choses qui ne sont que, je dirais, des choses qui ne sont pas réelles, qui sont comme des instruments pour arriver au produit final, qui est une décision.
Et parfois même le logiciel de supply chain classique ne va même pas jusqu’à la décision finalisée, celle qui prend réellement en compte toutes les contraintes telles que la quantité minimale de commande vérifiée, la capacité maximale du conteneur vérifiée, le chargement complet du camion vérifié, etc. Très souvent, vous vous retrouvez également avec beaucoup de complexité qui émerge du fait qu’au lieu de viser une décision complètement finalisée, ce que vous obtenez du logiciel de planification avancée typique, l’APS classique, est quelque chose qui est, encore une fois, un résultat non final, et vous avez donc besoin de beaucoup de plomberie par la suite pour finaliser les décisions.
Conor Doherty: C’est un terrain très fertile sur lequel continuer à marcher, je pense, car lorsque nous parlons d’implication informatique, et c’est quelque chose que nous savons tous deux pour avoir discuté avec de très nombreux praticiens à ce stade, l’une des choses qui les préoccupera est : “Eh bien, mes données de base ne sont pas assez bonnes. La santé de mes données est terrible. Joannes, vous devriez voir mes données. C’est un gâchis. C’est indécent. Impraticable. Vous ne pouvez même pas les utiliser.”
Vous, au chapitre 10, dites très clairement que c’est de la foutaise totale.
Joannes Vermorel: Oh oui. Oh oui. Ce qui est intéressant, c’est que, encore une fois, le marché des fournisseurs de logiciels d’entreprise de supply chain, je veux dire, ce marché est absolument terrible, et la plupart des fournisseurs ont des taux d’échec bien supérieurs à 90 %. Non, cela semble littéralement insensé. Ils sont grands. Sur le papier, ils sont censés avoir des centaines de mises en œuvre réussies. En pratique, ils présentent tous des degrés d’échec différents.
Et chaque fois que cela échoue, et cela échoue presque toujours, ils blâmeront les données parce qu’elles sont un parfait bouc émissaire. Un bouc émissaire si parfait, vous savez. C’est comme blâmer le dieu de la météo ou quelque chose du genre. Vous blâmez simplement une force externe comme si les données appartenaient à l’univers et que nous devions vivre avec. Non, non, non.
Mon point de vue est donc le suivant : les données sont presque invariablement excellentes pour toute entreprise dépassant, disons, 50 millions de dollars. Presque toujours excellent. Pourquoi? Parce que les entreprises qui ne disposaient pas d’excellentes données ont fait faillite depuis longtemps. C’est juste du darwinisme d’entreprise. Si vous ne savez pas ce que vous achetez, alors vous ne savez pas comment payer vos fournisseurs, et vous paierez certains fournisseurs deux fois ou pas du tout, et alors ils cesseront d’être des fournisseurs, ou quelque chose comme ça.
Alors, vous ne savez pas ce que vous achetez ? Non. Pouvez-vous ne pas savoir ce que vous vendez ? Non, parce que si vous ne savez pas ce que vous vendez, vous ne poursuivrez pas les clients qui ont oublié de payer, et ce genre de choses. Ainsi, les seules entreprises qui ont survécu sont celles qui savent essentiellement ce qu’elles achètent, ce qu’elles produisent et ce qu’elles vendent.
Conor Doherty: Oui. Oui. Règle de base.
Joannes Vermorel: Oui. Et encore une fois, le darwinisme en action. Les entreprises qui ne peuvent pas le faire ont fait faillite il y a longtemps, plus probablement il y a vingt ans. Les entreprises qui ont survécu sont donc celles pour lesquelles ces données de base sont correctes. Corrects dans le sens où ils reflètent la réalité et sont utilisables.
Conor Doherty: Vous rejetez donc l’argument du désordre ?
Joannes Vermorel: Non. Oh ouais, exactement. Je veux dire, alors il y a ce qui se passe lorsque des fournisseurs incompétents, oui, seront confrontés à ces données, et ce qu’ils attendent, ce sont des données parfaitement organisées d’une manière, disons, une compétition Kaggle est organisée. Vous disposez de données très ordonnées avec juste les bonnes tables, avec juste les bons champs, et tout est très bien documenté. Mais encore une fois, un concours Kaggle.
Oui, eh bien, si vous vous attendez à cela en tant que fournisseur, vous allez être déçu. Oui. La réalité est que, oui, le paysage applicatif est désordonné. Vous serez confronté à un paysage composé d’une demi-douzaine de systèmes métier complexes, chaque système métier comportant de 1 000 à 10 000 tables, chaque table comportant de 10 à 500 champs. Et chaque donnée, comme les ventes, est au moins triplée. C’est donc présenté de trois manières différentes dans différents tableaux pour différentes raisons, et c’est exactement ainsi.
Alors maintenant, en ce qui concerne Lokad, c’est notre travail, et je dirais que je considère que c’est la responsabilité de Lokad, de simplement régler le problème. Ce n’est qu’une attente fondamentale. Et donc pour nous, nous n’attendons rien d’autre qu’un paysage applicatif extrêmement désordonné avec des décennies de choses qui ont sédimenté. Vous avez donc quatre ERP différents, dont un qui était… parce que les ERP ne meurent jamais vraiment, ils passent juste en arrière-plan, et vous avez toujours ce qui fonctionne sur un mainframe, sur un AS/400 ou quelque chose comme ça, qui fonctionne toujours, et il n’a jamais vraiment été arrêté.
Et oui, il faut gérer ça comme le reste, et c’est tout à fait normal. Alors vous voyez, quand les gens blâment les données, pour moi, ce sont vraiment les fournisseurs qui blâment. C’est, pour moi, presque invariablement une démonstration d’incompétence de la part des vendeurs. Si un fournisseur vous dit : « Oh oui, nous avons échoué parce que les données sont mauvaises », je veux dire, fuyez. Ce vendeur est complètement incompétent. Ils ne savent même pas qu’ils sont incompétents et ils accusent les dieux de la météo ou quelque chose du genre. C’est juste… blâmer les données semble bien plus du 21ème siècle que de dire : « Oui, les dieux n’étaient pas avec nous là-dessus, et donc nous avons perdu cette bataille », mais c’est vraiment la même chose.
Conor Doherty: C’est un point clé, et je veux vraiment l’approfondir, car là, je dois séparer deux points que vous avez soulevés, mais je veux juste y faire écho parce qu’ils sont importants. Premièrement, la déclaration « Mes données sont désordonnées » est ici. Et l’autre : « Mes données sont trop compliquées pour que je puisse faire quoi que ce soit de manière industrieuse. » Ce sont deux affirmations distinctes que vous faites.
Et en fait, juste au-dessus de votre épaule, je ne sais pas si c’est visible sur la caméra, se trouve votre premier livre, le manifeste, le rouge. Et en cela, vous donnez l’exemple de, je pense sincèrement que c’est dans les années 90, peut-être à la page 98 ou quelque chose comme ça, vous donnez l’exemple de, que signifie la date de vente ? Et vous citez environ six à dix exemples différents. Par exemple, si vous ouvrez vos données transactionnelles, cela peut signifier le jour où il est entré dans le panier, le jour où il a été vendu, le jour où la période de retour a pris fin, le jour où la garantie a pris fin, peu importe. Il existe de nombreuses interprétations différentes de ce que cela signifie. Cela rend les choses compliquées.
Mais comme vous l’avez dit tout à l’heure, il est de la responsabilité du fournisseur de vous débarrasser de ce désordre et d’en faire quelque chose de industrieux et de productif.
Joannes Vermorel: Oui. Oui. Et la clé, et cela convient au déploiement du chapitre, est que vous voulez aboutir au résultat d’une initiative, de quelque chose qui donne des décisions très fondées, ajustées en fonction des risques et très rentables, basées sur les données dont vous disposez. Parce que la réalité est que vos collaborateurs au sein de votre entreprise n’ont pas accès à plus de données.
Le responsable de production ou le responsable des stocks ou le responsable des achats, ils ne se rendent pas physiquement dans l’entrepôt pour acquérir plus d’informations avant de saisir les bons de commande ou l’ordre de fabrication ou autre. Ils font tout depuis leur bureau et ils n’ont pour la plupart aucun accès privilégié à aucune sorte d’informations privilégiées, à l’exception de ce qui se trouve réellement dans les systèmes de l’entreprise.
Donc, ce que je prétends, c’est que Lokad… parce que vos collaborateurs, vos employés, sont déjà capables de gérer votre supply chain, sinon, encore une fois, le darwinisme en action, vous seriez en faillite. Ainsi, si vous n’êtes pas en faillite, certaines personnes parviennent à faire fonctionner votre entreprise, ce qui prouve que les données sont en quelque sorte suffisantes. Le simple fait que votre entreprise ne soit pas encore en faillite prouve à lui seul que les données sont suffisamment bonnes.
Maintenant, la question se pose : le fournisseur est-il suffisamment compétent pour utiliser les données telles quelles, par opposition à un vœu pieux ? Si le fournisseur vient et dit : « Oui, nous réussirons si vos données sont à la hauteur de mes normes », les normes du fournisseur, vous, en tant qu’entreprise qui gère une supply chain, n’avez aucun contrôle sur les normes du fournisseur. Évidemment, cela n’a aucun sens.
Imaginez simplement que vous souhaitiez réparer la plomberie de votre maison et que le gars qui se présente vous dit : “Oh non, vous savez, je n’aime pas vraiment le style de la façon dont votre plomberie a été aménagée. Cela semble un peu compliqué. Les tubes ne sont pas complètement droits. Non, je pense que je vais attendre que votre plomberie soit vraiment à la hauteur de mes standards avant de commencer à y jeter un œil.” Et les gens disaient : “Non, vous êtes le plombier. Traitez simplement la façon dont la plomberie a été réalisée. Et oui, s’il y a des tuyaux qui ne sont pas complètement droits, je veux dire, faites-le. C’est ce que nous attendons de vous.”
Vous voyez, ce genre de blâme sur les données est vraiment insensé. Et pour moi, ce qui en dit long sur la folie de ce marché, c’est que certains fournisseurs parviennent régulièrement à blâmer le client pour l’échec sous prétexte qu’il ne s’agissait que de données. Et le plus fou, c’est qu’ils arriveront très souvent à convaincre eux-mêmes les clients que c’est de leur faute.
Conor Doherty: Tu sais, c’est, pour moi, c’est comme, whoa. Non seulement le vendeur a échoué, mais ils ont réussi à convaincre… ils m’ont fait croire que c’était moi.
Joannes Vermorel: D’accord. Ils ont réussi à convaincre leur client que c’était de leur faute. Je dirais, oui, c’est un talent. C’est un art d’une certaine manière, mais ce n’est pas exactement ce que l’on attend de personnes qui prétendent être des spécialistes de la supply chain au lieu d’être des spécialistes de la manipulation.
Conor Doherty: Eh bien, cela pose en fait le point suivant, qui est, encore une fois, lorsque nous disons que Lokad prendra les données, ou celui que vous sélectionnez, mais dans notre cas, nous sommes évidemment Lokad, nous prendrons vos données et travaillerons avec cela, ce que nous entendons en fait par le Supply Chain Scientist. Et cela nous amène en fait à un point central ici, à savoir le rôle du Supply Chain Scientist dans un déploiement et dans l’amélioration continue.
Mais certainement dans la phase de déploiement, le rôle du Supply Chain Scientist se limite-t-il simplement à analyser et à trier les données, comme vous venez de le dire, ou est-il plus global ?
Joannes Vermorel: Non, car le fait est que vous ne pouvez pas savoir si la façon dont vous traitez les données est correcte ou non sans le prisme des décisions finales. En fin de compte, le seul critère pour savoir si ce que vous faites avec les données est correct ou non est : vos décisions sont-elles rentables ou non ? C’est le…
Conor Doherty: Dans un sens, si vous comprenez mal les données, mais que les décisions sont bonnes…
Joannes Vermorel: Alors votre malentendu est sans conséquence.
Conor Doherty: Ouais.
Joannes Vermorel: Et donc les gens seraient peut-être surpris, disons, comment peut-on faire une erreur et cela n’a pas d’importance ? Encore une fois, c’est un jeu d’échelle. Vous avez des milliers de tables. Vous disposez, au total, de dizaines de milliers de champs. Oui, il y aura des malentendus. Il y aura des problèmes. Il y aura plein de choses. Mais ce qui compte, c’est qu’en fin de compte, les gens font aussi des erreurs. Vous pouvez avoir des gens qui lisent un domaine ; ils devraient lire un autre domaine.
C’est vraiment : générez-vous des décisions qui ont zéro pour cent de folie ? Il n’y a donc pas une seule décision qui soit immédiatement fausse.
Conor Doherty: Mhm.
Joannes Vermorel: Et puis ils sont tous au moins assez bons, vous savez. Et puis, lorsque vous mesurez la performance économique en moyenne, est-ce qu’ils surpassent vraiment le statu quo précédent ? C’est le critère.
Ensuite, le fait que vous puissiez travailler sans fin, je dirais, pour continuer à améliorer la recette numérique pour la rendre très, très bonne au fil du temps est agréable, et c’est une continuation des efforts du Supply Chain Scientist. Mais en fin de compte, voyez-vous, la contribution du Supply Chain Scientist doit être interprétée comme suit : parvenons-nous à générer quotidiennement, sans surveillance, ces décisions hautement rentables ? Et c’est un déploiement. C’est une initiative qui en arrive au point où chaque jour vous prenez vos décisions.
C’est la contribution du Supply Chain Scientist. Et mécaniquement, ou désolé, pas mécaniquement, mécanistiquement parlant, le Supply Chain Scientist est essentiellement l’expert.
Conor Doherty: Je pense que c’est l’analogie que vous avez donnée auparavant. C’est comme l’équipe des stands tout en un. C’est l’ingénieur, le data scientist, l’expert supply chain qui va gérer votre compte spécifique. Par exemple, vous interagissez avec cette personne, la personne qui gère votre compte.
Joannes Vermorel: Ouais. Et cela va un peu plus loin. Ce que je dis, c’est que cela ne dépend même pas de Lokad. Si vous fragmentez la responsabilité de la recette numérique… Quelqu’un doit donc concevoir le logiciel qui prend vos données brutes et génère des décisions. C’est pourquoi, lorsque j’utilise le terme recette numérique, il s’agit d’un logiciel partant des données telles qu’elles peuvent être trouvées dans les systèmes d’affaires, ce qui existe brut, et génère en fin de compte les décisions concrètes finalisées.
Et quand je dis finalisé, cela signifie que personne n’a besoin d’ouvrir une feuille de calcul pour augmenter ou diminuer les chiffres simplement parce qu’il y a un MOQ qui n’a pas été géré ou quoi que ce soit. C’est donc vraiment, vraiment définitif. Bien. Le bon de commande est exactement prêt à être envoyé, par exemple, au fournisseur. D’accord.
Donc, ce que je dis, et c’est ainsi que les Supply Chain Scientists doivent être compris, il doit y avoir un seul esprit qui couvre tout cela. Un esprit humain. Et cet esprit humain est ce qui est très important, car en fin de compte, vous voulez avoir quelque chose qui soit complètement cohérent du début à la fin.
Et voyez-vous, si vous fragmentez la responsabilité, c’est ce que Lokad a appris il y a 15 ans. Si vous fragmentez cette tâche entre : “Oh, il y aura une personne chargée, disons, de préparer les données, puis une autre sera chargée de faire, disons, la modélisation probabiliste, et puis une autre sera chargée de faire l’optimisation pour le processus de prise de décision finale”, ce genre de choses, vous vous retrouverez avec des tonnes de bugs aux limites de votre système.
Vous voyez, en ayant plusieurs personnes, elles établiront naturellement des limites à l’intérieur de cette recette numérique, et presque tous les bugs seront concentrés sur ces limites. Il vous suffit donc de trouver un moyen de supprimer toutes ces frontières afin qu’elles ne soient pas fragmentées.
Et une autre façon de comprendre cela est simplement de considérer cela comme un processus dans lequel vous diviseriez le jeu d’échecs en plusieurs étapes. Par exemple, la première personne décide d’une courte liste de pièces éligibles au mouvement, puis une autre décide autre chose. Si vous organisez le processus, obtiendrez-vous un meilleur coup d’échecs à la fin de la journée ? Non, je veux dire, il est presque garanti que si vous essayez de fragmenter votre façon de jouer aux échecs, vous vous retrouverez avec de mauvais coups d’échecs, où, si vous jouez contre quelqu’un qui est vraiment bon, cette personne aura simplement un énorme avantage sur vous simplement parce que c’est un seul esprit qui peut jeter un œil à l’ensemble du tableau au lieu d’essayer de fragmenter l’analyse.
Conor Doherty: Bien sûr. Juste pour souligner un point, ou clarifier et, espérons-le, souligner ce point, lorsque vous dites qu’il s’agit d’un seul esprit humain, vous parlez du côté de Lokad. Il s’agit d’un esprit humain car, évidemment, vous devez toujours interagir avec le client.
Joannes Vermorel: Cette relation ne concerne pas Lokad. Vous savez, cette Introduction à la Supply Chain ne concerne pas Lokad. Il s’agit de savoir ce qui fonctionne et ce qui ne fonctionne pas dans la supply chain. Lokad est à peine mentionné dans les notes de bas de page à plusieurs reprises dans l’autre livre.
Ce que je dis, et c’est la leçon importante, c’est que si vous voulez qu’une initiative de supply chain fonctionne réellement, peu importe que Lokad soit impliqué. Je dis qu’il doit y avoir un logiciel pour générer vos décisions. Nous sommes passés par là. Si vous ne disposez pas d’un logiciel, vos efforts, vos investissements, ne sont pas rentables. Vous ne pouvez pas l’améliorer car cela devient très flou. Si quelqu’un part, encore une fois, il est extrêmement difficile d’améliorer systématiquement quelque chose qui est fait entièrement manuellement.
C’est pourquoi je dis, d’accord, nous devons aborder cela comme un artefact logiciel, cette recette numérique. D’accord. Maintenant, ce que je dis, c’est qu’il y aura quelqu’un qui sera impliqué dans la conception et la maintenance de cet artefact numérique. Si Lokad est impliqué, cela pourrait être quelqu’un de Lokad. Si Lokad n’est pas impliqué, ce sera quelqu’un d’autre. Peu importe où.
Et tant que nous n’aurons pas, vous savez, des niveaux d’IA Skynet aussi autonomes et capables que les humains, ce sera un esprit humain. Car même si ces agents sont incroyables, ils ne sont pas encore capables de réaliser seuls une entreprise aussi complexe. Donc pour l’instant ça veut dire qu’il y aura une personne.
Et ce que je dis, c’est que, et c’est un critère, peu importe la taille de votre entreprise, il faut qu’elle soit une seule personne. Cela ne veut pas dire qu’on ne peut pas avoir trois personnes, mais voyez-vous, c’est très différent. Pensez-y : vous voulez jouer aux échecs avec trois personnes, et potentiellement avoir trois experts. Tous les experts ont des capacités équivalentes, ils sont tous capables de jouer au jeu par eux-mêmes et ils peuvent voir l’ensemble du problème. Ce n’est pas fragmenté. Ce n’est pas une mise en scène.
Donc, dans un sens, si vous avez trois experts pour décider du déménagement, ils sont complètement redondants. Et c’est très bien. Donc, vous voyez, ce que je dis, c’est qu’il devrait y avoir un seul esprit. En pratique, pour une grande entreprise, on souhaite un licenciement parce qu’on ne veut pas, si cette personne est malade, n’avoir aucun recours. Je comprends cela. Ce que je dis, c’est que si vous avez plusieurs personnes, elles procéderont essentiellement à des licenciements. Il ne s’agit pas d’une division du travail où l’on trancherait le problème en dés, les gens ignorant certains aspects du processus.
Fondamentalement, pour que cela fonctionne, la recette numérique doit être réalisée par quelqu’un qui comprend parfaitement le processus du début à la fin. C’est ce que je dis. Et si vous ne disposez pas de cela, vous vous retrouverez face à des problèmes extrêmement prévisibles qui entraîneront presque systématiquement l’annulation de ce type d’initiative.
Conor Doherty: Eh bien, en termes de problèmes prévisibles qui annulent l’initiative même que vous essayez d’accomplir, l’un des plus importants est l’explicabilité. Et encore une fois, nous avons tous deux entendu personnellement à maintes reprises : « Cela semble génial. Comment puis-je expliquer cela à mon équipe, qui doit interagir avec ce système de renseignement qui prend désormais des décisions automatisées sans surveillance ?
Joannes Vermorel: Alors d’abord, revenons à cette personne, à cet esprit. Vous voyez, qui est en charge de l’explicabilité ? La réponse est la personne qui a élaboré la recette numérique. Ce n’est pas une IA. Ce n’est pas un système. C’est une personne. Il y a donc une personne qui peut expliquer ce qu’elle a fait. Donc si cette personne n’est pas disponible pour une explication, là encore vous avez un problème.
Donc, ce que je dis, c’est que nous revenons à un déploiement réussi. Vous devez avoir quelqu’un qui s’approprie la recette numérique. C’est la première étape. L’explicabilité commence donc par avoir quelqu’un pour expliquer. Vous voyez, c’est le rôle.
Et puis, cette personne est-elle capable de faire l’explication ? Eh bien, si cette personne a une compréhension globale du début à la fin, même si en pratique il peut s’agir d’une équipe, donc certaines parties du travail peuvent avoir été effectuées par d’autres personnes, si cette personne possède toute la recette numérique, alors oui, cette personne peut expliquer.
Maintenant, ce que vous voulez, c’est que cette personne crée également l’instrumentation. Cela fait partie de ce que nous appelons la boxe blanche. Ainsi, la personne qui élabore la recette numérique créera également tous les instruments de boxe blanche. Il s’agit essentiellement de toutes sortes de tableaux de bord…
Conor Doherty: Ouais, ouais, ouais.
Joannes Vermorel: …qui instrumente la recette numérique. L’intention derrière cette instrumentation est d’abord de permettre à la personne qui élabore la recette numérique de se convaincre que la recette fonctionne. Vous voyez, je veux dire, j’écris une recette numérique qui génère, disons, des bons de commande. Comment puis-je me convaincre que ce que je viens de faire est correct ? Vous voyez, je viens de mettre des formules.
Conor Doherty: C’est littéralement la question que je vous pose.
Joannes Vermorel: Oui. Et la première réponse est : je dois élaborer une série d’indicateurs, oui, en euros ou en dollars, qui décomposent ce que je vais faire et me disent simplement si ce que j’obtiens… Et il y aura, encore une fois, beaucoup d’heuristiques dans ce que je veux examiner.
Je vais donc chercher… probablement encore une fois, la boxe blanche est un peu un art. Vous ne voulez pas seulement regarder les moyennes. Vous voudrez peut-être zoomer sur des produits très irréguliers, certains très stables, d’autres en croissance, d’autres qui ont connu de longues périodes de rupture de stock, etc. Je veux dire, tout cela est le genre d’instruments que vous superposez à la recette numérique pour vous convaincre, en tant que Supply Chain Scientist, que cela fonctionne réellement comme prévu.
Et puis cette instrumentation est généralement un peu écrasante car elle contient littéralement des milliers de nombres. Et vous souhaiterez généralement, en tant que Supply Chain Scientist, produire un résumé beaucoup plus concis, qui sera présenté à des collègues, ou encore aux clients, ou à d’autres personnes, pour transmettre un message convaincant, mais d’une manière beaucoup plus concise. Et c’est encore une fois la responsabilité de la même personne, encore une fois, la personne chargée d’élaborer la recette numérique.
Conor Doherty: Eh bien, dans cette réponse, vous avez abordé le qui, le quoi et le comment. Alors, qui explique, ce qu’ils expliquent, comment ils expliquent. Ce qui n’a pas été abordé, c’est quand cette explication commence. Et si j’ai bien compris au chapitre 10, c’est pendant la phase de double passage. C’est là que vous commencez à voir pour la première fois, voici à quoi ressemble le nouveau système de renseignement par rapport à votre système actuel. Alors, s’il vous plaît, développez.
Joannes Vermorel: Le problème c’est que dans la recette numérique, vous avez potentiellement des centaines d’étapes de calcul intermédiaires, mais tous les artefacts numériques, ces choses, ne sont que des moyens pour parvenir à une fin. La seule chose qui compte c’est la fin, car c’est pour ça que tu es là. C’est encore une fois comme lorsque, si vous jouez aux échecs, la seule chose qui compte est le mouvement que vous faites. Toutes sortes d’étapes intermédiaires que vous aviez en tête pour prendre cette décision sont du genre, oui, d’accord. En fin de compte, ils sont sans conséquence pour les observateurs. La seule chose qui compte vraiment, c’est ce à quoi vous jouez réellement. Cela déterminera l’issue du jeu.
Oui. Donc voilà, ce que je dis, et nous disons un peu la même chose pour la recette numérique, nous disons que l’explicabilité commence une fois que vous avez des décisions à expliquer. Parce qu’avant cela, tout est plutôt discutable. Vous pouvez expliquer pourquoi vous avez effectué toutes sortes de prétraitements, pourquoi vous appliquez cette heuristique ici et là, pourquoi vous choisissez ce modèle probabiliste pour le délai plutôt qu’un autre. Tout cela ne sont que des détails techniques sans fin.
Fondamentalement, la seule chose qui mérite vraiment une explication, c’est la fin du jeu, les décisions que vous proposez. Et c’est pourquoi l’explication, la mise en boîte blanche, ne commencera généralement qu’à la fin du deuxième mois, au début du troisième mois. Une fois, dans le cadre d’une initiative de supply chain, le Supply Chain Scientist commence réellement à prendre des décisions quotidiennes.
Jusque-là, il s’agit simplement d’un travail essentiellement interne à ce que fait le Supply Chain Scientist, juste pour prendre ces décisions. Je veux dire, le délai est essentiellement de deux mois pour mettre en place un pipeline de données et permettre au Supply Chain Scientist de gérer ce gâchis de données, de lui donner un sens, puis d’écrire très rapidement la première recette numérique.
Les deux prochains mois seront consacrés à des itérations rapides pour se débarrasser de toutes les décisions insensées et vraiment ajuster, avec les retours des praticiens, tous les moteurs économiques. Parce que beaucoup de choses nécessitent d’être peaufinées, et c’est parce que ce que vous voulez, c’est vous assurer que vos moteurs économiques reflètent l’intention stratégique de la supply chain, de l’entreprise.
Alors, par exemple, que signifie réellement la qualité de service ? Encore une fois, un Supply Chain Scientist peut avoir fait quelques conjectures et émis des hypothèses, mais en fin de compte, il faudra discuter avec de vrais praticiens pour s’assurer que le cadre économique reflète réellement les intérêts à long terme de l’entreprise. Et ce sont des décisions très banales sur ce que signifie réellement la qualité de service, comment fonctionnent exactement les structures, à cause de la pression sur le fonds de roulement, etc., etc.
Donc beaucoup de choses, des itérations rapides pendant deux mois, et puis à la fin du quatrième mois, vous êtes prêt à laisser la recette numérique s’exécuter sans surveillance pendant deux mois en effectuant une double exécution.
Conor Doherty: Ouais.
Joannes Vermorel: Pour que les gens puissent vraiment… pour que la recette numérique puisse gagner la confiance nécessaire pour que les gens puissent ensuite décider qu’ils s’appuieront réellement en production sur ce logiciel pour piloter le flux.
Conor Doherty: Eh bien, vous avez parlé de folie, et vous avez déjà mentionné que ce que vous recherchez, ce sont des décisions zéro folie. Au cours de cette phase de double exécution, et pendant, disons, les six premiers mois d’un déploiement, d’une mise en œuvre, il y aura probablement des moments, que ce soit avec Lokad, peu importe avec qui il est, lorsque vous déployez un système de renseignement, il y aura probablement des moments où les gens qui observent, essayent d’instaurer la confiance dans ce système, pourraient observer une décision et il pourrait être impossible pour eux de la distinguer d’un défaut ou, “Oh non, c’est juste une nouvelle façon de faire les choses. »
Comment voulez-vous exactement, si c’est si radicalement différent du système précédent, comment voulez-vous que les gens fassent la différence entre « C’est une décision insensée » et « Non, cela semble tout simplement insensé, c’est en fait la meilleure décision financière que vous puissiez prendre » ?
Joannes Vermorel: Non, je veux dire, premièrement, le premier lot de choses que vous devez corriger sont vraiment des choses vraiment insensées. D’accord? C’est presque invariablement parce qu’il y a un champ qui est mal interprété, car, encore une fois, nous parlons de milliers de tables. Il y a quelque chose pour lequel vous pensez avoir des unités, mais en fait ce ne sont pas des unités, ce sont des kilogrammes, ou autre. Vous avez des choses, c’est complètement faux.
Et très souvent, par exemple, le premier lot sera juste pour vérifier auprès d’un directeur financier que l’on constate la même marge brute, la même valeur de stock. Et il n’est pas rare qu’au premier essai, vous obteniez un écart d’un facteur deux pour quelque raison que ce soit. Voilà, c’est comme la première couche de folie.
Et puis vous découvrez aussi tout le shadow IT. Par exemple, vous proposez une quantité de 110, et puis quelqu’un vous dit : « Oh non, non, non. Je ne vous l’ai pas dit, mais il n’y a que des palettes de 100 unités. D’accord, il y a donc beaucoup de multiplicateur. Cela n’a pas été documenté. Oui. D’accord, nous devons en tenir compte. Et puis, etc. Et puis vous avez des gens qui lèvent la main et disent : « Oh, mais non, nous avons bénéficié de réductions de prix de la part de ce fournisseur.
Conor Doherty: Oui.
Joannes Vermorel: Ce n’est pas enregistré dans le système. Habituellement, j’ajustais simplement manuellement dans une feuille de calcul. D’accord, nous devons résoudre ce problème, etc., etc. Donc, pour moi, la majeure partie des premières séries d’itérations sont vraiment toutes ces choses qui sont, je dirais, de la folie facile. C’est quelque chose où il y a un malentendu sur les données, il y a une contrainte qui n’est pas correctement modélisée, etc, etc.
Et parce que vous vous fixez un objectif, à savoir que nous voulons avoir une prise de décision sans surveillance, c’est plus exigeant. Parce qu’habituellement, historiquement, les praticiens disaient : « Oh, ce nombre, oui, c’est bien, 110, nous allons juste l’arrondir manuellement à 100. Pour moi, c’est bien. Et Lokad va beaucoup plus loin et dit : “Non, non, non. S’il y a beaucoup de multiplicateurs impliqués, alors la recette numérique doit, elle n’est pas facultative, doit tout faire pour que nous n’ayons pas besoin d’une étape corrective manuelle à la fin.” Ce n’est pas satisfaisant.
Donc, se débarrasser de la folie, c’est supprimer tous ces trucs. Et puis, oui, plus tard, nous aurons des décisions qui ne reflètent pas la pratique historique. Et ici nous aurons le reflet des forces économiques. Et généralement, s’il y a un désaccord, ce sera : « Êtes-vous d’accord sur les dollars que nous voyons ? Lokad suggère cela parce que lorsque nous examinons les dollars impliqués en termes de coût de rupture de stock par rapport au coût de surstock, c’est l’équilibre que nous constatons.
Et ici, nous aurons une itération sur ces moteurs économiques pour parvenir à un accord partagé. Et ce sera la deuxième série de choses où nous devrons corriger les décisions insensées, c’est-à-dire qu’en fait, les moteurs économiques qui sont beaucoup de conjectures se révèlent initialement incorrects, et nous devons itérer rapidement pour les amener dans la fourchette approximative de ce qui semble bon pour l’entreprise.
Et puis enfin, oui, à la fin nous aurons des décisions qui surprennent parfois les praticiens, mais cela arrive assez tard car à ce stade ici, ce que nous constatons, et c’est typiquement ce qui arrive avec un système qui fonctionne bien, c’est qu’il va briser les anciens schémas. Par exemple, disons que les commandes d’un fournisseur donné étaient toujours passées le lundi, mais ce n’est pas une véritable contrainte.
Conor Doherty: Ouais.
Joannes Vermorel: Le fournisseur peut prendre les commandes quand nous le souhaitons. Et parfois, il est logique de passer une commande le jeudi et de ne pas attendre le lundi suivant, simplement parce que le plus tôt sera le mieux si nous constatons une hausse inattendue de la demande. Pourquoi devriez-vous commencer par attendre quelques jours alors que vous savez déjà que vous devez passer une commande ? Cela brisera donc certaines habitudes.
Mais ici, la question sera, encore une fois, de savoir si c’est la bonne décision du point de vue du taux de rendement ? Cette décision est-elle plus rentable ou non ? Et là sera l’étendue de la conduite du changement, c’est-à-dire, eh bien, si c’est évidemment quelque chose de plus rentable, même si cela ne correspond pas à l’ancien modèle manuel, alors telle devrait être la décision, et c’est tout, et ne pas essayer d’ajouter des contraintes fictives pour l’adapter.
D’ailleurs, c’est quelque chose qui arrivait souvent, je dirais il y a plus de dix ans, chez Lokad, c’est que nous avions moins d’expérience qu’aujourd’hui. Et le genre de problèmes que nous avons eu est que souvent certains de nos prospects finissaient par dire : « Oh, nous voulons… ces décisions changent un peu trop par rapport à ce que nous avions avant. Nous allons donc introduire des contraintes souples, des contraintes qui ne sont pas réelles. »
Par exemple, une équipe peut simplement être habituée à avoir des MOQ souples par opposition à des MOQ durs, donc des quantités de commande minimes qui sont irréelles. Le fournisseur ne les a pas. L’entrepôt s’en fiche. Aucun avantage économique n’y est associé. Mais pour l’équipe des achats, c’était simplement un moyen de passer moins de commandes, de les rendre moins fréquentes car elles avaient une très faible productivité, et donc de gagner du temps.
Mais encore une fois, une fois que vous entrez dans le territoire des processus décisionnels sans surveillance, à moins qu’il n’y ait un gain économique lié au regroupement de vos bons de commande, auquel cas cela doit être reflété dans la recette numérique, alors il ne sert à rien d’essayer de modéliser ces MOQ souples qui sont entièrement inventés et sortent de nulle part.
Conor Doherty: En écoutant ça, ça m’a rappelé une anecdote. C’était vous, il y a de nombreuses années, je pense que c’était lors d’un événement en direct il y a quelques années, vous l’avez mentionné, et encore une fois, je ne vais pas dire qui, encore une fois, c’était un client, et dans l’aérospatiale, c’est ce que nous dirons, mais cela démontre l’idée qu’une fois que vous installez un système d’intelligence et que vous commencez à vous adapter, vous devez instaurer la confiance, il y aura des décisions opportunistes et capitalistes qui surgiront qui sont en dehors des limites de ce que vous pensiez possible auparavant.
Et de ce point de vue, cela peut paraître insensé, mais une fois que vous avez réellement étudié les aspects économiques, cela a du sens. Et l’exemple que je crois que vous avez donné était, je vais le massacrer, mais très, très simplement, une société MRO avait un bon de commande recommandé et cela incluait, par exemple, l’achat d’un moteur complet. Disons simplement, achetez un moteur. Achetez le moteur d’un A380. Et cela a été signalé comme : « C’est fou. Pourquoi me dites-vous d’acheter un moteur complet ?
Et la justification était que le système de renseignement avait découvert, et bien en fait, ces avions dans la zone venaient d’être démolis. Ce moteur est désormais vendu avec une remise de 50 %. Achetez-le, asseyez-vous dessus, vous pouvez le vendre avec profit en six mois. La recommandation n’était donc pas d’acheter pour utiliser, mais d’acheter pour vendre, ce qui est encore une fois très, très différent de la méthode précédente, du genre « J’achète ce dont j’ai besoin pour satisfaire cet objectif ». Alors qu’il s’agit d’une perspective économique beaucoup plus globale. Il ne s’agit donc pas simplement de dire : « Oh, j’avais l’habitude de cocher cette case dans ce but ». Il existe plusieurs façons d’écorcher un chat et de gagner plus d’argent.
Joannes Vermorel: Oui, exactement. Et cela arrive encore dans l’aviation, par exemple. Les avions sont démontés.
Conor Doherty: Exactement.
Joannes Vermorel: Et donc vous avez des opportunités d’achat, oui, une partie est… encore une fois, cela dépend de votre situation, mais si vous savez que vous êtes une entreprise qui n’est pas à court de liquidités, riche en liquidités, et c’est quelque chose, et que vous ne manquez pas d’espace de stockage, et cette chose sera nécessaire dans peut-être un an, et très probablement, lorsque vous en aurez besoin, vous paierez un prix qui sera presque garanti beaucoup plus élevé qu’aujourd’hui, oui, vous devriez voir cela.
Ou il peut s’agir d’un détaillant où vous bénéficiez d’une promotion d’un fournisseur et le produit ne perdra pas sa valeur trop rapidement, et vous aurez simplement la possibilité de le vendre avec une marge brute bien plus intéressante. Alors oui, c’est le genre de chose où… mais encore une fois, c’est pourquoi la justification économique et l’explicabilité, la façon dont nous fondons l’explicabilité se trouvent dans l’économie.
Vous savez, c’est “Pourquoi fais-tu ça ?” La réponse est : eh bien, regardez les finances. Et si la modélisation indique que c’est très rentable et que cela a du sens d’un point de vue économique, alors c’est la bonne décision, même si ce n’était pas une habitude historique dans l’entreprise.
Conor Doherty: Très bien. Eh bien, la seule chose que nous n’avons pas encore abordée, c’est ce qui se passe après le déploiement. Alors disons que vous êtes une entreprise, vous avez entendu tout cela, c’est génial, vous voulez vous acheter un système d’intelligence. Après le déploiement, qu’est-ce qui reste sous le contrôle d’un fournisseur et que dois-je conserver en tant que client en interne ? Par exemple, quelles parties de ce processus sont totalement sous mon contrôle et qu’est-ce qui est extérieur à vous ?
Joannes Vermorel: Je pense que, premièrement, la grande leçon du déploiement est de savoir quelle devrait être la fin du jeu. Vous savez, si vous voulez réussir, vous devriez viser une prise de décision sans surveillance.
Conor Doherty: Mhm.
Joannes Vermorel: Si vous ne le faites pas, cela vous coûtera 10 fois plus cher. Ce sera 10 fois plus lent, et ce ne sera ni relutif, ni capitaliste. Vous n’aurez pas quelque chose qui amènera réellement votre entreprise à la prochaine étape de rentabilité en ce qui concerne votre supply chain. C’est donc vraiment une leçon concise.
Et peu importe qu’un fournisseur soit impliqué ou non, si vous souhaitez le faire en interne ou non, etc. Encore une fois, ce livre ne concerne pas vraiment Lokad. C’est : que signifie déployer ? Parce que vous voyez, le genre d’anti-modèle que je vois dans cette industrie est que beaucoup de gens diraient : « Oh, nous avons mené cette initiative de supply chain, et celle-ci, et celle-ci, et celle-là », et aucun d’entre eux n’a réellement atteint cette sorte d’étape de prise de décision sans surveillance.
Vous vous retrouvez donc avec des tableaux de bord là-bas qui sont ignorés, un gadget ici qui est ignoré, un logiciel là-bas qui n’est qu’un gouffre de productivité. Cela n’apporte littéralement pas grand-chose compte tenu du temps que vous devez y consacrer, etc. Je pense donc que l’idée clé du déploiement est que vous devez avoir un objectif clair, indépendamment de qui est en charge de quoi. Il devrait s’agir de parvenir à quelque chose en qui vous pouvez avoir confiance, qui génère quotidiennement ces décisions sans surveillance.
Et puis ce que je dis, c’est que c’est un logiciel et qu’il doit être maintenu. Encore une fois, personne n’évite la dérive.
Conor Doherty: Ouais, exactement.
Joannes Vermorel: Juste parce que nous n’avons pas Skynet AI, ne vous attendez pas à ce qu’un logiciel, quel que soit le génie que vous y mettez, etc., s’adapte en quelque sorte aux changements structurels de votre marché.
Conor Doherty: Ce qui est tout le temps, pour être parfaitement honnête.
Joannes Vermorel: Ouais, pas tout le temps. Mais voyez-vous, car il existe des classes de changements qui ne sont pas structurels. S’il s’agit simplement d’une hausse ou d’une baisse du marché, alors le modèle de prévision, les modèles d’apprentissage automatique, s’en occuperont. Le problème est ce qui se passe lorsque votre entreprise devient différente, non seulement plus ou moins pareil parce que vous avez une croissance ou un déclin, mais lorsque vous devenez une bête complètement différente.
Pensez simplement, par exemple, à un MRO qui vendait des pièces et qui vend maintenant du temps de disponibilité pour les heures de vol.
Conor Doherty: Oui. C’est un modèle économique complètement différent.
Joannes Vermorel: Vous ne vendez même pas la même chose.
Conor Doherty: Oui. Il y aura des pièces d’avion. Il y aura des mécanismes qui se chevaucheront.
Joannes Vermorel: Mais votre modèle économique est complètement différent et vos incitations sont complètement différentes. La modélisation économique de votre entreprise est complètement différente. Et la même chose s’est produite, par exemple, il y a dix ans, lorsque de nombreux détaillants traditionnels se sont tournés vers le e-commerce. Alors évidemment, si vous étiez majoritairement physique et que maintenant vous vous consacrez principalement au e-commerce, encore une fois, toutes les incitations, le type de stratégie, tout change. Et il ne s’agit pas simplement de plus ou moins de ventes. C’est une transformation. La nature même de votre entreprise change.
Encore une fois, ce que je dis, c’est que pour toutes les variations banales, un fournisseur ayant un problème et les délais de livraison devenant plus lents, toute la variabilité banale doit être gérée sans aucun changement par votre recette numérique. Ce que je dis, c’est que votre recette numérique ne pourra pas, à elle seule, s’adapter au fait que, par exemple, vous introduisez un nouvel ERP.
Conor Doherty: Oui. Ou que vous changez, ou que vous fermez des centres de distribution, ou toutes ces choses.
Joannes Vermorel: Oui, exactement. Je veux dire, des choses qui sont très structurelles. C’est pourquoi il faut l’entretenir. C’est parce que vous avez besoin de quelqu’un qui soit attentif et qui s’assure que ce logiciel est aligné sur la réalité de votre marché, la réalité de votre entreprise et la réalité de son paysage applicatif.
Et c’est pourquoi celui qui est en charge, chez Lokad, nous l’appelons Supply Chain Scientist, mais celui qui est en charge de l’élaboration de la recette numérique doit ensuite être en charge de maintenir la recette numérique. Et la réalité est que vous pouvez aussi avoir cette personne en charge de l’amélioration continue de la recette numérique, car généralement lorsque vous entrez en production, le travail vient à peine de commencer.
Vous avez atteint un certain degré de performance économique qui représente généralement un progrès considérable par rapport à l’ancien statu quo, qui était un processus manuel, mais cela ne signifie pas que vous êtes proche de quelque chose qui serait considéré comme optimal. Cela signifie simplement que vous êtes bien meilleur, mais vous pouvez continuer à investir dans cet actif pour l’améliorer au fil du temps.
Conor Doherty: Eh bien, encore une fois, je ne veux pas y aller, ce n’est pas dans le chapitre 10, mais cela vaut la peine de rassembler cela, car c’est le point central du traitement de la supply chain, dans ce cas votre logiciel de supply chain, la différence entre les dépenses d’investissement et les dépenses d’exploitation. Parce que lorsque vous investissez dans un système d’intelligence, il n’y a pas, comme vous venez de le dire, de limite supérieure à ce qu’une décision peut réellement devenir meilleure, plus performante, plus gratifiante financièrement. Je veux dire, je suis sûr qu’il n’y a qu’une certaine quantité d’argent dans le monde, mais en réalité, il n’y a pas de plafond à la qualité de ce que cela pourrait être. Donc, si vous investissez correctement dans ce domaine, vous êtes au moins orienté dans la direction où vous devriez vraiment aller financièrement.
Joannes Vermorel: Oui. Oui. Et encore une fois, cela devient, dans une certaine mesure, une entreprise entrepreneuriale. Vous devez décider si vous souhaitez élargir la gamme d’options. Devriez-vous, par exemple, prendre des décisions selon lesquelles vous pouvez commencer à dire que les MOQ sont une évidence, mais que l’étape suivante serait : les MOQ devraient peut-être être renégociés ? Y a-t-il un cas ? Y a-t-il de l’argent à gagner en renégociant les MOQ avec les fournisseurs ?
Sur quoi devrait porter la négociation ? À quoi devrait-il ressembler ? Sommes-nous d’accord pour opter pour un prix unitaire légèrement plus élevé si nous pouvons réduire considérablement le MOQ, ou devrions-nous procéder dans l’autre sens, etc., etc. ? Vous voyez donc que nous commençons par… une initiative de supply chain commence avec une portée spécifique en termes de décisions, mais au fil du temps, elle peut s’étendre pour inclure de plus en plus de décisions.
Habituellement, vous commencez par, je dirais, les décisions fondamentales de base régissant le flux, mais vous pouvez ensuite y superposer des décisions qui façonnent également le flux, bien qu’elles soient généralement considérées comme acquises au départ, juste pour maintenir l’initiative ancrée et finir par fournir, encore une fois, une prise de décision sans surveillance rapidement avant de s’étendre à de plus en plus de portées.
Conor Doherty: Eh bien, c’est en fait ma pensée finale, mais elle suit ce que vous venez de dire. De toute évidence, l’objectif final est une prise de décision automatisée et sans surveillance, orientée vers l’amélioration financière de l’entreprise. Super. C’est le produit final d’un déploiement, et encore une fois, il est continuellement amélioré, etc. Génial.
Dont vous pouvez juger du ROI, ou que vous pouvez au moins observer. Cela signifie-t-il donc qu’au cours des deux premiers mois, lorsque vous en êtes uniquement aux étapes de validation et de tri des données, cela n’a aucune réelle valeur financière ? Donc, fondamentalement, sans le produit final, les premières étapes n’ont aucune valeur ? Ou y a-t-il de la valeur tout au long de cette chaîne ?
Joannes Vermorel: Non. Je veux dire, encore une fois, tant que vous ne générez pas les décisions finales, vous n’avez aucune idée, pas la moindre, si vous êtes sur la bonne voie ou non. Vous voyez, c’est pourquoi je dis que si vous commencez à rechercher des artefacts numériques, vous ne le savez pas. Cela peut paraître très bien, mais la réalité est que vous n’en avez pas la moindre idée.
Vous voyez, encore une fois, pensez-y comme si je vous parlais des échecs. Sans suggérer le coup final. Si je dis… imaginez que vous faites une partie d’échecs et que je fais une centaine de déclarations sur ce à quoi cela ressemble, le genre de choses qui sont une position forte, une position faible, etc., et à la fin, je ne dis pas quel genre de mouvement nous devrions faire ensuite. Je veux dire, quelle est la valeur de tous ces conseils ? Vous voyez, c’est…
Et il y a le problème, c’est que pour moi, de nombreux éditeurs de logiciels d’entreprise utilisent cette ambiguïté pour vendre des produits depuis des décennies. Ils auront toutes sortes d’artefacts numériques. “Je vais vous donner un tableau de bord pour vos fournisseurs, un tableau de bord pour les produits, des indicateurs pour ceci, pour cela, un jumeau numérique qui simule ceci et cela et cela et cela”, des trucs sans fin. Et puis pas un seul engagement sur une décision finale sur lequel nous pourrions nous mettre d’accord sur : « Est-ce que cette chose générera des profits ou des pertes ?
Et ce que je dis, c’est que ce n’est pas le cas… et c’est une différence d’appréciation. Ce n’est pas un objectif lointain. C’est quelque chose que vous pouvez atteindre en huit à dix semaines, encore une fois selon l’expérience de Lokad. Et encore une fois, huit à dix semaines avec une équipe généralement assez limitée. Il ne s’agit pas d’une entreprise de grande envergure. C’est…
Et pour moi, c’est le début de tout. Le déploiement n’est pas… pour nous, nous disons que la clôture du déploiement se produit lorsque l’entreprise fait vraiment confiance au processus de prise de décision sans surveillance, ce qui ressemble aux deux derniers mois du processus. Et je pense que l’erreur, et c’est pourquoi je dis que beaucoup d’entreprises finissent par être distraites, c’est qu’au lieu de prendre directement des décisions sans surveillance, qu’elles pensent être comme un objectif très mature et très éloigné, elles commenceront à poursuivre d’autres objectifs.
Et ils disent : “Oh non, nous ne pouvons pas avoir un système entièrement robotisé en 10 semaines. Je pense que nous devons d’abord établir un flux de travail, et cela prendra 20 semaines.” Vous voyez, vous établissez donc une étape intermédiaire qui est déjà deux fois plus grande et deux fois plus complexe que votre fin de partie. Et c’est pourquoi je dis que ces artefacts numériques, ces idées issues de la théorie dominante de la supply chain, finissent par créer autant de complexité.
C’est ainsi qu’on se retrouve avec des projets qui prennent plusieurs années. Et après plusieurs années, vous n’avez toujours pas quelque chose qui se rapproche d’un processus sans surveillance, ou qui se rapproche de quelque chose qui serait des dépenses d’investissement, avec un actif productif et dans lequel vos investissements deviennent relutifs. C’est pourquoi je dis que cela doit être inscrit à l’ordre du jour, car c’est l’objectif numéro un. C’est par là que nous devrions commencer, puis améliorer cela.
Conor Doherty: Je suis d’accord. Et bien, la seule chose que je veux ajouter à cela, c’est que je veux en fait utiliser l’analogie, la comparaison, que vous avez utilisée plusieurs fois, c’est-à-dire les échecs. Et puis je vais juste dire quelque chose, donnez-moi vos dernières réflexions.
Mais si le résultat final d’un déploiement est de faire les meilleurs mouvements avec les pièces de l’échiquier afin de pouvoir gagner la partie, c’est l’objectif final, c’est le système d’intelligence, les décisions automatisées. Les premiers mois, le tri et la validation des données, où vous construisez le schéma, vous analysez, vous comprenez les connexions, c’est-à-dire effectivement construire l’échiquier, ou vous montrer, à tout le moins, “Voici votre échiquier, voici la couleur des carrés, voici à quoi ressemblent les pièces. Voici les mouvements que vous pouvez réellement faire. Voici comment se déplace un cheval. Voici ce que fait une tour.”
Je ne vous donne pas les décisions car je n’y suis pas encore. Mais il y a, pour moi, une valeur manifeste à savoir : « Oh, c’est à ça que ressemble un échiquier. C’est à cela que font ces pièces. »
Joannes Vermorel: Oui. Oui. Évidemment. Donc, si nous parlons de réduire les risques liés à l’initiative, oui, vous pouvez avoir une idée de la progression. Ouais. Mais soyons réalistes : la plupart des initiatives logicielles de supply chain sont généralement déployées sur plusieurs années. La plupart des éditeurs de logiciels vendent des licences pour lesquelles vous devez avoir un engagement minimum d’un an, et très souvent un engagement de quatre ans. Encore une fois, c’est complètement faux.
Ce que je dis, c’est que vous devriez viser quelque chose de beaucoup, beaucoup plus court. Oui. Et 10 semaines, ce n’est pas grand-chose, vous savez. Et encore une fois, si vous voulez avoir une idée, est-ce que cette entité, même s’il s’agit d’une solution interne, progresse vers la solution, à la quatrième semaine, vous pouvez simplement demander à la personne responsable, encore une fois, je dis un seul esprit, oui, que faites-vous ? Que construisez-vous ? Est-ce que cela a du sens pour vous ? L’explication donnée est-elle : « Est-ce que cette chose me permettra d’accéder à la recette complète dans six semaines seulement ?
Je ne pense pas qu’il y ait beaucoup de travail de préparation, mais dans le grand schéma des logiciels d’entreprise, pouvoir atteindre un point où vous livrez le produit final en 10 semaines environ, en termes d’effet tunnel, ce n’est vraiment pas grand-chose. Ce n’est vraiment pas grand-chose. Peut-être qu’à l’avenir, avec les agents de codage, nous réduirons cela à la moitié du temps, mais cela reste, je pense, très rapide.
Oui, le problème, voyez-vous, je ne vois pas beaucoup de potentiel… nous pouvons avoir un potentiel pour amener cela, disons, 10 semaines d’effet tunnel à cinq avec beaucoup d’agents de codage, pour vraiment accélérer cette partie, mais ce n’est pas vraiment là où est le défi. Le défi est que, par rapport au statu quo, il faut opter pour quelque chose pour lequel vous obtiendrez un résultat normalement en 10 semaines, au lieu de viser littéralement un processus dans lequel, de par sa conception, vous optez pour quelque chose qui prendra 100 semaines.
Vous voyez, très fréquemment lorsqu’il s’agit de déploiement, par exemple, une chose que j’entends très fréquemment, c’est que les gens disent : « Oh oui, oh non, nous ne pouvons pas nous permettre de faire ça, avoir des résultats en 10 semaines. Nous devons commencer par faire un appel d’offres », et bam, 18 mois. D’accord, vous avez transformé… vous aviez quelque chose qui vous permettait d’obtenir des résultats en 10 semaines, et maintenant vous avez un an et demi de sélection de fournisseurs, et cette sélection de fournisseurs vous coûte beaucoup plus cher que de faire le travail réellement.
Et puis vous vous retrouvez avec un fournisseur qui demande littéralement s’il veut un engagement d’un an, si ce n’est pas quatre ans. D’accord, c’est faux. C’est aussi la leçon du déploiement : quelles sont les échelles de temps pertinentes.
Ce que je dis, c’est que vous pouvez accéder à un processus décisionnel sans surveillance en 10 semaines. Il vous faudra environ six mois pour faire entièrement confiance à cette chose, car la majeure partie de ce temps est en réalité le temps qu’il faut aux humains pour faire confiance à un logiciel. Cela n’a pas grand chose à voir avec la technologie. C’est pourquoi même si demain nous avons des agents de codage qui peuvent amener ce délai de, disons, 10 semaines pour vraiment arriver à une recette numérique qui fonctionne et qui n’est pas complètement insensée, nous pourrons probablement demain compresser cela en cinq, soyons fous, trois semaines.
Il faudra encore quelques mois aux praticiens, au top management, pour faire confiance à ce logiciel et le laisser prendre le contrôle d’un élément majeur de l’entreprise. Donc vous voyez, en fin de compte, je dirais que ce n’est pas là la vraie bataille. La vraie bataille est… Je veux dire, tu peux passer quelques semaines ici. Lokad y travaille, mais cela nécessite beaucoup de technologies sophistiquées, beaucoup de pratiques très raffinées, car chaque jour compte. Vous voulez être vraiment très rapide.
Mais très souvent, voyez-vous, Lokad, nous travaillons au développement des technologies pour pouvoir passer quelques jours ici et là. Mais ce que je vois, c’est que je vois de très nombreuses entreprises avec lesquelles nous sommes en discussion, et elles commencent par perdre des années entières à se lancer dans des choses comme, oui, de par leur conception, où elles vont pour une demande d’information, boum, huit mois, puis 12 mois, puis elles choisissent un premier fournisseur qui a dit qu’il livrerait quelque chose dans huit mois, mais en fait, un an et demi plus tard, ils n’ont toujours presque rien à montrer, et ce n’est certainement pas automatisé, etc.
Je veux dire, voyez-vous, imaginez ce genre de situation super frustrante où Lokad… nous sommes en discussion avec une entreprise, puis ils passent par un processus, et il nous faut cinq ans pour enfin démarrer le projet pilote, qui se fait ensuite en 10 semaines.
Conor Doherty: Ouais.
Joannes Vermorel: Vous voyez, c’est très souvent le genre de… et donc ce serait peut-être une leçon pour le déploiement. Ce que je décris, c’est que pour déployer une initiative de supply chain, les entreprises doivent avoir des ambitions beaucoup plus élevées, dans un sens. Encore une fois, une prise de décision sans surveillance.
Et vous ne voulez pas commencer par une petite chose. Vous voulez commencer par le problème le plus difficile. Encore une fois, pourquoi ? Parce que vous voulez éliminer les personnes incompétentes, qu’il s’agisse d’une solution interne ou d’un fournisseur externe. Vous voulez vraiment commencer par quelque chose de vraiment difficile pour évaluer la compétence réelle de la personne que vous attendez pour résoudre le problème.
Ne commencez pas par un problème facile, car alors vous pouvez vous retrouver avec une entité incompétente, qu’il s’agisse encore d’une solution interne ou d’un fournisseur externe, qui fait juste un travail passable, mais vous ne réalisez pas que c’est une impasse parce que vous avez choisi quelque chose de facile, de français, traitant d’un petit ensemble de données, etc. Non, non. Une fois que vous vous engagez dans une supply chain moderne, vous choisissez le problème le plus difficile, le plus grand ensemble de données dont vous disposez, et vous voulez, dans 10 semaines, vous assurer vraiment que l’entité qui, selon vous, sera votre solution à long terme est examinée sur cette chose, que vous savez que cela fonctionne.
Si vous commencez par vérifier cette entité sur quelque chose de facile, vous ne savez pas si cette personne ou cette entité sera capable de faire les choses difficiles par la suite. Encore une fois, si le problème difficile prenait environ trois ans, vous diriez non, nous devons faire quelque chose de petit. Mais ce que je dis ici, et cela fait aussi partie du déploiement, c’est qu’il n’y a, à ma connaissance, aucun problème dans les supply chains où, en 10 semaines, vous ne pouvez pas avoir un processus décisionnel sans surveillance qui démontre soit le fait que vous êtes capable de le faire, soit qui démontrera le fait que vous êtes incompétent. C’est ça.
Et le fait est que si le fournisseur ne peut pas le faire en 10 semaines, il ne pourra pas le faire en 100 semaines. Il est donc inutile de continuer à investir. Il faut admettre que ça n’a pas marché. Il faut changer de fournisseur, changer de méthode, changer quelque chose de plus fondamental. Lui donner du temps ne suffira pas.
Conor Doherty: Très bien. Eh bien, Joannes, je n’ai plus de questions. Nous avons duré environ une heure et demie, je pense, mais je pense que nous couvrirons beaucoup d’informations très pratiques, qui, encore une fois, je recommande fortement aux gens de revenir en arrière, de lire le chapitre 10. Il y a beaucoup de choses très utiles. Mais merci beaucoup pour votre temps et merci beaucoup d’avoir regardé.
Et oui, si vous avez des questions ou si vous souhaitez parler personnellement à Joannes et moi, vous pouvez nous contacter sur LinkedIn ou nous envoyer un e-mail à contact@lokad.com. Vous connaissez le principe. Et sur ce, on se retrouve la semaine prochaine. Retourner au travail.
