00:00:00 Introduction de l’interview
00:01:41 La carrière précoce d’Ian Wright et la fondation de Logistics Sciences
00:05:33 La notion d’optimalité dans la supply chain
00:10:06 Optimisation, incertitude et perturbations du monde réel
00:18:18 Les limites de l’optimisation traditionnelle et l’impact de la pandémie
00:25:27 La réponse de Lokad et l’adaptation des supply chains
00:32:45 Les défis des modèles déterministes et des compromis
00:41:09 Les taux de service, les modèles financiers et les vérifications de cohérence
00:50:48 L’expertise humaine, les heuristiques et la modélisation itérative
00:58:39 Le coût de l’intervention humaine dans les supply chains
01:06:24 La stratégie en tant qu’ingénierie et automatisation de la décision
01:14:06 Le modèle décentralisé de Walmart et la rupture des silos
01:21:39 Boucles de rétroaction et amélioration continue de la supply chain
01:29:18 Atteindre l’optimalité et naviguer dans l’engouement des fournisseurs
01:35:42 Réflexions finales sur les tendances technologiques dans la supply chain
Résumé
Lors d’une récente interview sur LokadTV, Conor Doherty a accueilli Ian Wright, fondateur de Logistics Sciences, et Joannes Vermorel, PDG de Lokad, pour discuter de l’idée qu’il n’existe pas de décisions optimales dans la gestion de la supply chain. Ils ont remis en question les vues traditionnelles sur l’efficacité, mettant en évidence les complexités et les incertitudes qui défient les idéaux théoriques. Ian et Joannes ont souligné que différents acteurs avaient des définitions variées de l’optimalité et que les solutions pratiques devaient s’aligner sur les réalités commerciales. Ils ont discuté des limites des méthodes d’optimisation traditionnelles et de l’importance du jugement humain dans la prise de décision stratégique. La conversation a souligné la nécessité de modèles capables de gérer l’incertitude et de se concentrer sur de véritables résultats économiques.
Résumé Étendu
Dans un récent épisode de LokadTV, Conor Doherty, Directeur de la Communication chez Lokad, a animé une discussion approfondie avec Ian Wright, fondateur de Logistics Sciences, et Joannes Vermorel, PDG et fondateur de Lokad. La conversation tournait autour de l’idée provocante qu’il n’existe pas de décisions optimales dans la gestion de la supply chain, un concept qui remet en question les vues traditionnelles sur l’efficacité et la prise de décision.
Conor Doherty a ouvert la discussion en soulignant la croyance commune selon laquelle les décisions optimales représentent le summum de l’efficacité, une situation dans laquelle les ressources sont parfaitement allouées, les coûts réduits et les profits maximisés. Cependant, il a noté que ces idéaux théoriques s’effondrent souvent face aux complexités du monde réel. Ian Wright, fort de plus de 40 ans d’expérience dans la supply chain et la logistique, a partagé son parcours allant du milieu académique à l’industrie pétrolière, puis à la fondation de Logistics Sciences. Sa carrière a été marquée par une focalisation sur la résolution de problèmes en logistique et en recherche opérationnelle, mettant en lumière l’application pratique de la planification et de l’exécution.
Joannes Vermorel a rejoint les propos d’Ian, soulignant que si les intentions de la recherche opérationnelle après la Seconde Guerre mondiale étaient justes, le domaine a rencontré des défis similaires à ceux connus de l’intelligence artificielle, avec des périodes d’attentes gonflées suivies de déceptions. Il a noté que de nombreuses méthodes issues de la recherche opérationnelle n’ont pas réussi à offrir des avantages exploitables aux entreprises.
La conversation s’est ensuite penchée sur l’article d’Ian, “Why There Is No Such Thing as an Optimal Solution in Supply Chain Planning and Logistics Network Optimization.” Ian a expliqué que différents acteurs avaient des définitions diverses de l’optimalité, ce qui conduisait souvent à des idées conflictuelles. Les praticiens se concentraient sur les aspects mathématiques, tandis que les dirigeants d’entreprise privilégiaient des solutions pratiques et réalisables. Il a souligné que les modèles et les outils n’étaient qu’un volet d’une solution plus globale qui devait avoir du sens pour l’entreprise.
Joannes a approfondi ce point en évoquant les limites des méthodes d’optimisation traditionnelles, qui peinent souvent à intégrer la dimension temporelle et à gérer l’incertitude. Il a souligné l’importance des améliorations quantitatives dans l’optimisation commerciale, en contraste avec la vision plus statique et mathématique de la recherche opérationnelle traditionnelle.
La discussion a également abordé le rôle de l’incertitude dans la prise de décision en supply chain. Ian a décrit diverses sources d’incertitude, allant des variations prévisibles aux événements de type cygne noir et aux inconnues. Il a insisté sur la nécessité de disposer de modèles capables de gérer ces incertitudes et de fournir des solutions de rechange.
Joannes a partagé l’approche de Lokad pendant les confinements liés à la COVID-19, période durant laquelle ils géraient les décisions de supply chain pour des clients dont les employés de bureau étaient en congé. En injectant une dose massive d’incertitude dans leurs modèles, Lokad a pu prendre des décisions plus prudentes, démontrant ainsi l’efficacité de leurs systèmes d’optimisation.
La conversation s’est ensuite tournée vers le rôle des compromis dans la prise de décision. Ian a souligné que les compromis se résumaient souvent à des considérations financières, en équilibrant les coûts par rapport aux taux de service et à d’autres facteurs. Joannes a soutenu que de nombreuses entreprises se concentraient sur l’optimisation des pourcentages plutôt que sur de véritables résultats économiques, menant à des décisions sous-optimales.
Ian et Joannes ont tous deux convenu de l’importance de l’intervention humaine dans la prise de décision stratégique. Bien que l’automatisation et les outils d’optimisation puissent prendre en charge de nombreuses tâches, l’intuition et le jugement humain restent essentiels, notamment dans les domaines où une contribution mécaniste se révèle insuffisante.
En conclusion, l’interview a mis en lumière les complexités et les défis de l’optimisation de la supply chain, soulignant la nécessité de solutions pratiques et applicables qui tiennent compte de l’incertitude et intègrent le jugement humain. Ian et Joannes ont apporté des perspectives précieuses sur la manière dont les entreprises peuvent relever ces défis, insistant sur l’importance d’aligner les modèles sur les opérations réelles et de se concentrer sur de véritables résultats économiques.
Transcription Complète
Conor Doherty: Bon retour sur LokadTV. Une décision optimale est souvent considérée comme le summum de l’efficacité, une situation où les ressources sont parfaitement allouées, les coûts réduits et les profits maximisés. Cela semble idéal dans un manuel ou en salle de classe, mais ces idées s’effondrent souvent dès leur confrontation avec la réalité. L’invité d’aujourd’hui, Ian Wright, va nous parler de cette quête de l’optimalité. Ian est le fondateur de Logistics Sciences et possède plus de 40 ans d’expérience dans la supply chain.
Comme toujours, si vous appréciez ce que vous entendez, veuillez vous abonner à la chaîne YouTube et nous suivre sur LinkedIn. Sur ce, je vous présente la conversation d’aujourd’hui avec Ian Wright.
Très bien, super. Ian, merci beaucoup de nous avoir rejoints. Pour ceux qui ne vous connaissent pas encore – je vous ai présenté plus tôt – pourriez-vous donner une brève introduction, s’il vous plaît ?
Ian Wright: Eh bien, je pense que vous avez mentionné que je suis dans le métier depuis 40 ans. En réalité, je suis présent depuis bien plus longtemps, mais ma carrière s’étend sur 40 ans. Sur le plan académique, mon parcours a débuté par un intérêt pour l’économie et la géographie, que j’ai rassemblés en étudiant ce que l’on appelait alors simplement le transport, ou la logistique dans mon domaine. Cela englobait essentiellement l’économie, la géographie, le commerce, et cela a suscité un grand intérêt pour la résolution de problèmes, en particulier dans ce que l’on appelle aujourd’hui la logistique et la recherche opérationnelle. J’ai donc poursuivi dans la recherche opérationnelle tout en me concentrant fortement sur les problèmes de transport, de logistique, et sur ce que nous connaissons tous sous le nom de supply chain. Cela remonte à plus de 40 ans.
Et ensuite, pour gagner ma vie, j’ai intégré l’industrie pétrolière en tant que management scientist pour Castrol. J’ai été presque lancé à l’eau froide, car je me suis retrouvé immédiatement impliqué dans des projets de planification stratégique de très haut niveau. J’ai rédigé un certain nombre de systèmes de maintenance préventive pour la distribution de l’entreprise, et j’ai découvert des logiciels de planification d’un point de vue réseau ainsi que pour la gestion de flotte. Ensuite, j’ai rejoint la société qui fournissait ces systèmes – à l’époque, cette entreprise ne comptait qu’une seule personne, donc nous étions deux – et j’ai aidé à les développer. Par la suite, je suis parti aux États-Unis avec un client de l’entreprise et je me suis impliqué dans les SIG ainsi que dans leur utilisation pour visualiser ce que nous faisions en matière de planification. Ce fut une première introduction à ce qui est aujourd’hui courant avec les SIG et la visualisation, dès le début des années 80.
Par la suite, je me suis tourné vers la logistique tierce, initialement à travers un projet de développement logiciel. J’ai toujours été au fait du 3PL au Royaume-Uni tout au long de ma carrière, mais ce n’est qu’au début des années 90 qu’il était assez nouveau aux États-Unis, et ils venaient à peine de développer l’idée de regrouper des solutions à vendre aux clients. Ces solutions consistaient à déterminer où implanter votre entrepôt et comment gérer vos actifs de transport. Ce fut une excellente application de mon expérience, mais surtout pour moi, ce fut une leçon majeure en matière de planification pour l’implémentation et l’exécution, et de rester impliqué dans l’exploitation de la solution mise en place, ce qui me semble être une bonne leçon pour tous ceux qui œuvrent dans notre domaine.
Finalement, j’ai quitté le domaine de la planification proprement dite. J’ai constitué quelques équipes de solutions et les ai dirigées. Puis, j’ai progressivement assumé davantage de responsabilités dans les organisations pour lesquelles je travaillais. Mais finalement, après une période dans le conseil – que je n’ai pas vraiment appréciée – j’ai décidé de créer ma propre société de conseil, Logistic Sciences. Et si vous voulez savoir ce qu’est Logistic Sciences, c’est essentiellement moi qui tente de revenir à ce que j’aime faire, c’est-à-dire la résolution de problèmes, en me concentrant particulièrement sur les questions de supply chain et de logistique, et en utilisant les connaissances et les outils limités dont je dispose pour aider concrètement les gens à résoudre des problèmes dans ce domaine. Je ne sais pas si cela vous aide à comprendre d’où je viens. Je n’ai aucune idée de la direction que je prendrai, mais…
Conor Doherty: Eh bien, merci, Ian. Et en fait, Joannes, je suis sûr que beaucoup de cela vous parle. L’idée de résoudre des problèmes et de revoir la problématique de la prise de décision en supply chain résonne fortement en vous, n’est-ce pas ?
Joannes Vermorel: Oui, je veux dire que, en termes d’intentions, celles mises en place par la recherche opérationnelle après la Seconde Guerre mondiale étaient très bonnes, dans le sens où l’on tentait d’ingénier ces méthodes de gestion en quelque chose de numériquement fiable et améliorable. C’était, je pense, l’une des intentions justes et qui reste très pertinente aujourd’hui. Le défi, c’est que c’est très intéressant. Les gens évoquent très souvent les divers hivers que l’IA, l’intelligence artificielle, a traversés avec des espoirs surdimensionnés avant d’être déçus par son inefficacité. Je crois que la recherche opérationnelle a connu des phases similaires, et que certaines vagues de méthodes connues à l’époque n’ont tout simplement pas réussi à se traduire par de véritables avantages exploitables pour les entreprises.
Conor Doherty: Eh bien, en réalité, cela nous amène au sujet de la conversation d’aujourd’hui, pour lequel Ian s’est quelque peu inspiré en voyant votre travail sur LinkedIn. Vous publiez, en fait, de nombreux articles. J’en ai d’ailleurs un ici devant moi sur lequel j’ai pris des notes. J’espère que la caméra pourra le capter. Je l’ai lu, nous l’avons tous lu. Mais cet article – et je le lis, je suis le gars, je suis le gars. Oui, c’était gratuit, merci – qui a suscité l’intérêt de cette conversation s’intitule “Why There Is No Such Thing as an Optimal Solution in Supply Chain Planning and Logistics Network Optimization.” Il fait environ 13 pages. Pour ceux qui ne l’ont pas lu, pourriez-vous en faire un résumé exécutif, s’il vous plaît ?
Ian Wright: Il s’agit essentiellement de faire passer l’idée que différentes personnes ont des conceptions différentes de ce qu’est l’optimalité. Généralement, ce que je constate, c’est qu’il ne s’agit pas tant d’idées opposées que d’idées conflictuelles, dans le sens où la conception de l’optimalité chez le praticien est souvent beaucoup plus axée sur ce qu’il réalise avec l’outil ou la technique employée. Et cela revient fréquemment, comme Joannes le mentionnait, à une focalisation sur les mathématiques, alors que la personne qui subit ou bénéficie de l’optimisation est le chef d’entreprise.
Je pars du principe que nous pouvons nous concentrer sur le secteur privé et les entreprises, bien qu’il y ait évidemment beaucoup plus à faire en matière de supply chain. Mais le chef d’entreprise ne se préoccupe pas – ou ne devrait pas se préoccuper – des mathématiques, de la méthodologie, de l’outil ou du modèle. Et lorsque je travaille avec mes propres clients et sur divers projets, je m’efforce de leur faire comprendre que les outils que nous utilisons, les modèles que nous construisons, ne représentent qu’un petit aspect permettant d’aboutir à une solution qu’ils pourront employer pour prendre une décision et mettre en œuvre quelque chose. Ainsi, la prémisse fondamentale de l’article était de faire passer l’idée que le modèle n’est pas l’élément essentiel, c’est la solution. Et il existe de bien d’autres composants, de bien d’autres facettes d’une solution qui a du sens pour l’entreprise.
Conor Doherty: Juste à ce sujet, et Joannes, je reviendrai vers toi dans une minute, mais la manière dont tu as présenté cela, encore une fois, quand tu l’expliques à tes propres clients, tu cherches — et j’ai noté — à t’assurer que les gens comprennent. Et sur ce point, je pense qu’un mot-clé à clarifier immédiatement est quand tu parles d’optimalité, encore une fois, tu as fait la distinction entre le praticien et le mathématicien. Souvent, certains termes peuvent signifier des choses légèrement différentes selon le contexte. Joannes et moi avons récemment mené une discussion sur les heuristiques, et encore une fois, une heuristique dans un sens mathématique versus un sens économique peut être légèrement différente. Alors, quand tu parles de poursuivre une décision optimale ou de présenter l’optimalité, que veux-tu dire exactement, s’il te plaît?
Ian Wright: En général, je considère l’optimalité non pas dans le sens d’un mathématicien, car à mon avis, c’est une notion merveilleuse à aborder si vous vivez dans le monde des mathématiques. Mais ce sur quoi nous devons nous appuyer, c’est sur ce qui constitue la meilleure solution dans les circonstances présentes. Alors, que se passe-t-il réellement ? Il faut d’abord comprendre ce qu’il se passe dans le monde, puis présenter une solution qui représente le meilleur résultat possible dans ces conditions et qui atténuera, ou du moins mitiguera, la plupart des problèmes rencontrés. C’est la solution que nous recherchons, celle que nous voulons présenter.
Conor Doherty: Joannes ? Oh, oui, merci, Ian. Encore une fois, l’idée d’être le meilleur disponible ne signifie pas être parfait en termes absolus. As-tu quelque chose à ajouter ou en es-tu d’accord ?
Joannes Vermorel: Oui, je veux dire, pour rebondir sur la caractérisation de la perspective d’optimisation en mathématiques comme étant belle, je suis d’accord. C’est quelque chose d’extrêmement simple. Je peux le résumer pour le public. Il s’agit de prendre une fonction qui va évaluer ce que vous souhaitez, et une partie des entrées de cette fonction sont vos variables, ce que vous pouvez décider, ce qui peut varier selon votre volonté. Voilà l’entrée, et ensuite la fonction vous donne le score. Fondamentalement, l’optimisation consiste à rechercher cette unique combinaison d’entrées qui formalise votre décision en extrémisant le résultat, c’est-à-dire en minimisant si vous cherchez à réduire vos coûts ou en maximisant si vous voulez augmenter vos rendements, quelque chose dans ce goût-là. And the interesting thing is that this simple problem comes with a nice clean mathematical characterization. Then you can say all sorts of interesting things about your inputs, you can say all sorts of interesting things about your output, how it behaves, and what classes of algorithms exist to seek a solution, and whether you will be able to, in mathematical terms, say that under those assumptions, whether your method is the best that it can be or not, etc. And by the way, this field of research is now pretty named OR. It used to stand for operational research, but nowadays it’s just mathematical optimization. And they’re not even concerned anymore about whether they are talking about a business problem or not. Their concern is the development of solvers, which is a class of software that is designed to perform those optimizations in a mathematical sense. Et ce qui est intéressant, c’est que ce problème simple s’accompagne d’une caractérisation mathématique claire et nette. Ensuite, vous pouvez dire toutes sortes de choses intéressantes sur vos entrées, sur votre sortie, sur leur comportement, et quelles classes d’algorithmes existent pour rechercher une solution, et, en termes mathématiques, déterminer si, sous ces hypothèses, votre méthode est la meilleure possible ou non, etc. Et d’ailleurs, ce domaine de recherche est désormais largement désigné par OR. Avant, cela signifiait « operational research », mais de nos jours, c’est simplement l’optimisation mathématique. Et ils ne se préoccupent même plus de savoir s’il s’agit d’un problème d’entreprise ou non. Leur préoccupation est le développement de solveurs, c’est-à-dire une catégorie de logiciels conçus pour réaliser ces optimisations dans un sens mathématique. When we think in terms of optimization in the math, I think it is the sort of most, I would say, crystal-clear understanding of what optimization is. It doesn’t mean that by being, you know, crystal clear, it doesn’t mean that it’s the most relevant. It just means that it’s the sort of purest, as in, you know, crystal purity. It doesn’t mean that it’s the applicable tool for all situations. And when we think in terms of optimization in a business context, what we mean is we want to improve things but with a quantitative edge. You see, that’s the difference. Quand nous pensons à l’optimisation dans le domaine mathématique, je trouve qu’il s’agit de la compréhension la plus limpide de ce qu’est l’optimisation. Cela ne veut pas dire qu’en étant limpide, c’est le plus pertinent. Cela signifie simplement que c’est la forme la plus pure, à l’image de la pureté cristalline. Cela ne veut pas dire que c’est l’outil applicable à toutes les situations. Et quand nous parlons d’optimisation dans un contexte business, nous voulons dire que nous souhaitons améliorer les choses, mais avec une approche quantitative. Vous voyez, c’est là la différence. Because I can also improve a business by, for example, having a better culture where people are more dedicated, but it’s almost impossible to quantify anything about that. So when we say optimization, what we mean is that we mean to improve with quantitative instruments and ideally quantitative results as well. That would be, you know, sort of, and that’s when we, I go back to your, I would say, optimization as you understand it, I would describe it as mostly a process of quantitative improvements. That would be, you know, and that is completely, that would say the, the business perspective of optimization. Parce que je peux aussi améliorer une entreprise, par exemple en développant une meilleure culture dans laquelle les gens sont plus investis, mais il est presque impossible de quantifier quoi que ce soit à ce sujet. Donc, quand nous parlons d’optimisation, nous voulons dire l’amélioration grâce à des instruments quantitatifs, avec idéalement des résultats quantitatifs également. Ce serait, en quelque sorte, et c’est là que, je me réfère à ce que tu entends par optimisation, je la décrirais principalement comme un processus d’améliorations quantitatives. Cela exprime complètement la perspective business de l’optimisation. Ian Wright: Je pense que, non, je suis entièrement d’accord avec Joannes. C’est l’une des choses que nous devons comprendre : en ce qui concerne l’optimal, il y a des dimensions impliquées dans les problèmes que nous examinons, et bien souvent, ces dimensions sont ignorées ou omises. Parmi les plus fondamentales, en réalité, la dimension la plus basique est celle du temps. That has a massive bearing on what you can do with the model or the technique and or the technology, and what you have to do in operation in the real world and what you’re able to do in those circumstances. And it changes, it changes the nature of what you can consider as optimal. Cela a une influence considérable sur ce que vous pouvez faire avec le modèle, la technique ou la technologie, ainsi que sur ce que vous devez réaliser en opération dans le monde réel et sur ce dont vous êtes capable dans ces circonstances. Et cela change, cela change la nature de ce que vous pouvez considérer comme optimal. Conor Doherty: Eh bien, en fait, et encore une fois, c’est une formulation parfaite de ce que vous êtes capables de faire. Et cela nous amène à une discussion sur ce que je pense être — et je sais que pour Joannes c’est assurément un élément clé de toute discussion sur l’optimalité, ou plus généralement, sur la prise de décision — à savoir la nature de l’incertitude lorsqu’on tente de prendre ces décisions. So in your paper, you talk about uncertainty and the real complexity that exists in supply chain. So could you comment a bit further on the sources of uncertainty that actually influence one’s pursuit of optimality in whichever way one wants to optimize? Dans ton article, tu parles de l’incertitude et de la réelle complexité qui existe dans la supply chain. Pourrais-tu développer un peu plus sur les sources d’incertitude qui influencent réellement la quête de l’optimalité, quelle que soit la manière dont on souhaite optimiser ? Conor Doherty: Eh bien, en fait, pour rebondir sur la citation non inspirée par Donald Rumsfeld, d’autres sources d’incertitude que certains considèrent comme des known knowns seraient, comme tu l’as dit dans l’article, dans une demande stable et des supply chains prévisibles. Joannes, s’agit-il de known knowns, de known unknowns ou d’inconnus inconnus ? Ian Wright: Je pense que, non, je suis entièrement d’accord avec Joannes. C’est l’une des choses que nous devons comprendre : concernant l’optimal, les problèmes que nous analysons comportent diverses dimensions, et très souvent, ces dimensions sont ignorées ou omises. Parmi elles, la plus basique est celle du temps.
Joannes Vermorel: Oui, je trouve que cette typologie est intéressante, mais encore une fois, si nous revenons à l’outil de base que nous utilisons pour ces analyses quantitatives — si je reviens aux méthodes développées dans le cadre de l’OR — la dimension temporelle était absente. La première raison, de manière très banale, est qu’ajouter cette dimension augmente la dimensionalité de vos problèmes et ces méthodes se comportent très mal quand on essaie d’aborder des méthodes plus complexes. Elles ne sont pas très scalables, du moins pas dans le sens dans lequel nous parlons aujourd’hui de solutions scalables, surtout si l’on considère le développement récent sur le front du deep learning.
So the first problem is that we had this super basic problem of dealing with scalability, no time dimension. And then once we start considering the time dimension, the future is not perfectly known, thus we have to deal with a variability of some kind. And here that would be just known unknowns. You know, it is a very mild case of uncertainty. It is very much expected that lead times will vary, it is very much expected that demand will vary, etc. So those cases are relatively easy. Donc, le premier problème était que nous avions ce problème très basique de gestion de la scalabilité, sans dimension temporelle. Et une fois que nous commençons à considérer la dimension du temps, l’avenir n’étant pas parfaitement connu, nous devons gérer une certaine variabilité. Ici, il s’agit simplement de known unknowns. Il est en effet très prévisible que les lead times varient, que la demande varie, etc. Ces cas-là sont relativement faciles. And then we are entering the territory of what is called stochastic optimization because suddenly your decision might reveal itself as good or bad depending on future circumstances that you do not control. So, there are alternative futures where this decision looks good, but there are certainly possible futures where it will reveal itself in time as being a poor decision. So, that’s, I would say, the sort of very mundane problems that we have before jumping into the unknown unknowns and all those wild varieties of uncertainties we have more basic problems still, and that’s where I think this idea of facets is very interesting. Ensuite, nous entrons dans le domaine de ce que l’on appelle l’optimisation stochastique, car soudainement, votre décision pourrait se révéler bonne ou mauvaise en fonction des circonstances futures que vous ne contrôlez pas. Il existe donc des futurs alternatifs où cette décision paraît judicieuse, mais il y a certainement des futurs possibles où, avec le temps, elle s’avérera être une mauvaise décision. Voilà, je dirais, le genre de problèmes très banals auxquels nous sommes confrontés avant de passer aux inconnus inconnus et à toutes ces variétés sauvages d’incertitudes, car nous avons encore des problèmes plus fondamentaux. C’est là que l’idée de facettes est très intéressante. We just do not really know how we should score anything. It’s not obvious. When we say we want to optimize profits, there is an indefinite number of ways to count profits. Should we include the second-order effects, the third-order effects? What do I mean by second-order effects? You give a discount of 10% now, the customer expects the next time they walk into the store to get a similar discount again. This is a second-order effect. You just gave a discount, but it cost you more because you inspired the expectation. So, again, that should be scored. Nous ne savons tout simplement pas comment nous devrions évaluer quoi que ce soit. Cela n’est pas évident. Quand nous disons que nous voulons optimiser les profits, il existe un nombre infini de manières de les calculer. Devons-nous inclure les effets de second ordre, de troisième ordre ? Que veux-je dire par effets de second ordre ? Vous accordez une remise de 10 % maintenant, et le client s’attend à obtenir une remise similaire lors de sa prochaine visite en magasin. C’est un effet de second ordre. Vous venez d’accorder une remise, mais cela vous a coûté plus cher parce que vous avez suscité une attente. Encore une fois, cela doit être pris en compte. And then if you do that, your competitor might aggressively decide to compete even more on price, or they might eventually completely give up on competing altogether, leaving you alone or at least with fewer competitors. So, you see, all of that is very mundane aspects of what am I quantifying exactly. These are difficult. I think another facet that is not really addressed in the classic optimization literature is that they think as if the problems were well understood right from the start. Et ensuite, si vous faites cela, votre concurrent pourrait décider de concurrencer encore plus agressivement sur les prix, ou bien il pourrait finalement renoncer complètement à la concurrence, vous laissant seul ou du moins avec moins de concurrents. Vous voyez, tous ces aspects très banals illustrent combien il est difficile de quantifier précisément ce que l’on cherche à mesurer. Une autre facette, qui n’est pas vraiment abordée dans la littérature classique sur l’optimisation, est qu’on part du principe que les problèmes sont parfaitement compris dès le départ. Conor Doherty: Eh bien, en fait, pour rebondir sur la citation non inspirée par Donald Rumsfeld, d’autres sources d’incertitude que certains considèrent comme des known knowns seraient, comme tu l’as dit dans l’article, dans une demande stable et des supply chains prévisibles. Joannes, s’agit-il de known knowns, de known unknowns ou d’inconnus inconnus ? Ian Wright: Je pense que, non, je suis entièrement d’accord avec Joannes. C’est l’une des choses que nous devons comprendre : les problèmes que nous analysons comportent diverses dimensions, et très souvent, ces dimensions sont ignorées ou omises. Parmi elles, la plus fondamentale est celle du temps. Joannes Vermorel: Oui, je trouve cette typologie intéressante, mais encore une fois, si nous revenons à l’outil de base utilisé pour ces analyses quantitatives — si je reviens aux méthodes développées dans le cadre de l’OR — la dimension temporelle était absente. La première raison, de manière très banale, est qu’en l’ajoutant, on augmente la dimensionalité de vos problèmes et ces méthodes se comportent très mal quand il s’agit de traiter des méthodes plus complexes. Elles ne sont pas très scalables, du moins pas dans le sens dont nous parlons aujourd’hui de solutions scalables, surtout si l’on considère le récent développement sur le front du deep learning. So the first problem is that we had this super basic problem of dealing with scalability, no time dimension. And then once we start considering the time dimension, the future is not perfectly known, thus we have to deal with a variability of some kind. And here that would be just known unknowns. You know, it is a very mild case of uncertainty. It is very much expected that lead times will vary, it is very much expected that demand will vary, etc. So those cases are relatively easy. Donc, le premier problème était ce très basique souci de scalabilité, sans dimension temporelle. Une fois que l’on commence à intégrer la dimension du temps, l’avenir n’étant pas parfaitement connu, il faut faire face à une certaine variabilité. Ici, il s’agit simplement de known unknowns. Il est en effet fort attendu que les lead times varient, que la demande fluctue, etc. Ces cas sont relativement simples. And then we are entering the territory of what is called stochastic optimization because suddenly your decision might reveal itself as good or bad depending on future circumstances that you do not control. So, there are alternative futures where this decision looks good, but there are certainly possible futures where it will reveal itself in time as being a poor decision. So, that’s, I would say, the sort of very mundane problems that we have before jumping into the unknown unknowns and all those wild varieties of uncertainties we have more basic problems still, and that’s where I think this idea of facets is very interesting. Ensuite, nous entrons dans le domaine de ce que l’on appelle l’optimisation stochastique, car soudainement, votre décision pourrait se révéler bonne ou mauvaise en fonction des circonstances futures que vous ne contrôlez pas. Il existe des futurs alternatifs où cette décision semble judicieuse, mais il y a certainement des futurs possibles où, avec le temps, elle s’avérera être une mauvaise décision. Voilà, je dirais, le genre de problèmes très banals que nous rencontrons avant de passer aux inconnus inconnus et à toutes ces variétés sauvages d’incertitudes, alors même que nous avons encore des problèmes plus fondamentaux. C’est là que l’idée de facettes devient vraiment intéressante. We just do not really know how we should score anything. It’s not obvious. When we say we want to optimize profits, there is an indefinite number of ways to count profits. Should we include the second-order effects, the third-order effects? What do I mean by second-order effects? You give a discount of 10% now, the customer expects the next time they walk into the store to get a similar discount again. This is a second-order effect. You just gave a discount, but it cost you more because you inspired the expectation. So, again, that should be scored. Nous ne savons tout simplement pas comment évaluer quoi que ce soit, ce qui n’est pas évident. Quand nous affirmons vouloir optimiser les profits, il existe une infinité de façons de les calculer. Devons-nous inclure les effets de second ordre, de troisième ordre ? Que veux-je dire par effets de second ordre ? Si vous accordez une réduction de 10 % maintenant, le client s’attendra à obtenir une réduction similaire lors de sa prochaine visite en magasin. C’est un effet de second ordre. Vous venez d’accorder une réduction, mais cela vous a coûté plus cher parce que vous avez suscité une attente. Encore une fois, cela doit être pris en compte. And then if you do that, your competitor might aggressively decide to compete even more on price, or they might eventually completely give up on competing altogether, leaving you alone or at least with fewer competitors. So, you see, all of that is very mundane aspects of what am I quantifying exactly. These are difficult. I think another facet that is not really addressed in the classic optimization literature is that they think as if the problems were well understood right from the start. Et ensuite, si vous agissez ainsi, votre concurrent pourrait décider de rivaliser encore plus agressivement sur les prix, ou bien il pourrait finalement renoncer complètement à la concurrence, vous laissant seul ou du moins avec moins de concurrents. Vous voyez, tous ces aspects très banals relèvent de la difficile question de ce que nous cherchons précisément à quantifier. Une autre facette, qui n’est pas vraiment abordée dans la littérature classique sur l’optimisation, est l’hypothèse que les problèmes sont parfaitement compris dès le départ. Conor Doherty: Ian, dans ton article, tu as mentionné de nombreux exemples concrets d’entreprises ayant réussi ou échoué à aborder les types d’incertitude dont nous venons de parler — qu’il s’agisse des lead times, de la demande erratique, ou autre. Pourrais-tu partager plus de détails sur ces études de cas, s’il te plaît ? Ian Wright: Oui, beaucoup des projets sur lesquels je travaille sont de nature plus stratégique. Certains sont tactiques. Je ne travaille plus vraiment dans le domaine de la planification pour l’exécution. Ainsi, la plupart des exemples auxquels je pense à ce sujet concernent des entreprises qui échouent à planifier de manière tactique ou stratégique en ne s’attaquant pas à ces problématiques de prévisibilité ou de son absence. Just recently, in the last three years, there was an event a year before that I think nobody would say they had predicted. Certainly, I believe no systems for planning in any company could have conceived of and incorporated elements of planning that would account for the impact of the pandemic and what happened to stocks and the implications of inventory drawdown, the sudden decrease in demand, and so forth. So many different widely spread implications. The classic example is around semiconductors. Récemment, au cours des trois dernières années, il y a eu un événement, survenu l’année précédente, que personne n’aurait prétendu avoir prédit. Certainement, je pense qu’aucun système de planification dans aucune entreprise n’aurait pu concevoir et intégrer des éléments permettant de prendre en compte l’impact de la pandémie, ce qui est arrivé aux stocks et les implications de la diminution des stocks, de la chute soudaine de la demande, etc. Tant d’implications largement répandues. L’exemple classique concerne les semi-conducteurs. My experience was twofold in that so many companies coming out of the pandemic in food manufacturing and not just pharmaceuticals but in medical appliances, in the healthcare logistics sector as a whole, suddenly realized that they had to plan for something they hadn’t anticipated. They were working against their intrinsic in-house systems that manage the business, that manage their supply chain, because those systems no longer provided them with data that was capable of building the basis of models to understand what they should do next. Mon expérience a été double dans la mesure où tant d’entreprises, issues de la pandémie — que ce soit dans la fabrication alimentaire, non seulement dans les produits pharmaceutiques, mais aussi dans les dispositifs médicaux et dans le secteur global de la logistique en santé — se sont soudainement rendu compte qu’elles devaient planifier pour quelque chose qu’elles n’avaient pas anticipé. Elles travaillaient avec leurs systèmes internes intrinsèques qui géraient l’entreprise, qui géraient leur supply chain, car ces systèmes ne leur fournissaient plus de données capables de servir de base à des modèles permettant de déterminer ce qu’elles devaient faire ensuite. So, I worked on a lot of projects for food manufacturers who were trying to catch up with the immense explosion in demand in places that they didn’t have capacity, and they needed to understand very quickly where that capacity should be placed and why it should be placed there. There were so many fundamental problems with trying to work out how you go about doing that because it was very akin to saying, how do you build a supply chain for a product that doesn’t exist today? How do you plan for that? And then the whole notion of how you then go on to execute is the next stage. J’ai donc travaillé sur de nombreux projets pour des fabricants alimentaires qui tentaient de rattraper l’immense explosion de la demande dans des zones où ils n’avaient pas de capacité, et ils devaient comprendre très rapidement où placer cette capacité et pourquoi elle devait s’y trouver. Il y avait tant de problèmes fondamentaux à résoudre pour y parvenir, car c’était très similaire à se demander : comment construire une supply chain pour un produit qui n’existe pas encore aujourd’hui ? Comment planifier cela ? Et ensuite, la manière d’exécuter constitue l’étape suivante. Conor Doherty: Ian, c’est une belle transition vers Joannes. Je veux dire, c’est véritablement ton métier, celui d’exécuter des solutions dans des situations pleines d’incertitudes. As-tu des exemples de réussites ou d’échecs d’entreprises face aux types d’incertitude dont nous discutons ? Joannes Vermorel: Oui, je pense que, vous savez, si nous revenons aux années de confinements, 2020, 2021, l’élément intéressant est que Lokad a connu, je dirais, de très beaux succès opérationnels, mais je pense précisément que c’est parce que nous faisions de l’optimisation.
Permettez-moi de décrire ce que font la plupart des entreprises de nos jours à travers essentiellement un océan de tableurs. Elles n’optimisent rien, ni au sens mathématique ni de la manière que nous venons de décrire. Ce qu’elles font essentiellement, c’est reproduire en grande partie ce qui a déjà été fait. Elles se contentent de reproduire les mêmes schémas que leurs décisions antérieures. Elles ne suivent même pas vraiment la demande ou quoi que ce soit ; elles se contentent de reproduire ce qu’elles ont fait auparavant, ce qui signifie que le budget est découpé de pratiquement la même manière que l’année dernière, que stocks de sécurité sont à nouveau ajustés de manière minimale par rapport à ce qui a été fait l’année dernière, etc. Ainsi, tout est réalisé de façon incrémentale par rapport au statu quo. Il n’y a aucune optimisation en cours. Nous ne faisons que refléter le statu quo, en le dirigeant légèrement mais pas de façon quantitative, un peu dans la direction qui semble appropriée.
Ça fonctionne plus ou moins, mais voilà le problème : aucun processus d’optimisation n’est en place, ce qui signifie que si vous modifiez radicalement vos conditions d’exploitation, vous ne disposez d’aucun mécanisme pour refléter ces nouvelles conditions. Permettez-moi de répéter : tous vos tableurs, tous vos processus existants sont conçus pour répliquer ce que vous avez fait auparavant. En revanche, chez Lokad, nous disposions de systèmes d’optimisation. Que se passait-il lorsque nous étions confrontés à des situations sans précédent ? Nous injections pratiquement manuellement une dose massive d’incertitude dans nos modèles.
Nous ne savions pas ce qui allait se passer. Nous disions simplement : “D’accord, la demande correspond normalement à ce que nous appelons l’effet fusil à pompe.” Vous voyez, l’avenir de la demande se présente comme une simple possibilité. Eh bien, si vous êtes confronté à une situation comme un confinement, vous augmentez simplement l’angle du fusil à pompe pour que l’avenir devienne très flou. Il en va de même pour vos délais, il en va de même pour vos prix. Vous partez du principe que, soudainement, vous en savez beaucoup moins sur l’avenir. Mais vous pouvez faire cela, et si vous supposez que vous en savez nettement moins, vous pouvez relancer votre logique d’optimisation – c’est l’optimisation stochastique – afin d’obtenir des décisions plus prudentes face au risque que vous encourez.
Vous prenez en compte, de manière assez sommaire, le pire des scénarios en termes de délais, de prix, de demande, etc., et vous prenez des décisions bien plus conservatrices quant aux risques qui ont explosé quantitativement. Ce que j’en retire, c’est que cela fonctionne. Ça marche très bien, mais le problème, c’est d’avoir plus d’optimisation, pas moins. Même si ce n’est pas le genre de perspective statique de la recherche opérationnelle – une optimisation statique où rien ne bouge.
La deuxième chose, c’est une facette supplémentaire qui, je pense, a été presque jamais abordée à l’époque de la recherche opérationnelle, probablement de 1950 à 1980, pendant ces 30 ans, à savoir la qualité de votre instrumentation. À quelle vitesse pouvez-vous passer d’une instance de votre modélisation à la suivante ? C’est un aspect opérationnel vraiment pratique.
Ian Wright : Je pense qu’il y avait également des problèmes pratiques liés à cela, car la technologie n’était pas suffisante. Il y avait un manque de données parce que la technologie relative à cela n’était pas suffisante. Mais assurément, la technologie permettant une exécution plus rapide de la planification n’existait tout simplement pas. Je peux vous l’affirmer d’après avoir vu des modèles d’optimisation tourner pendant 24 heures, contrairement à aujourd’hui où, quand je travaille avec des collaborateurs, je me dis, “Eh bien, ce n’est pas terminé, cela fait déjà cinq minutes, que dois-je faire ?” Je ne veux pas t’interrompre, Joannes, mais je pense qu’une grande partie de cela s’explique par le fait que nous disposons aujourd’hui d’une technologie bien meilleure.
Joannes Vermorel : Je suis tout à fait d’accord, et c’est pour le compte à part, mais ce sont vraiment des préoccupations pratiques. Si vous disposez d’une technologie d’optimisation mais que son relancement prend 24 heures et que vous avez besoin de 20 itérations pour converger vers quelque chose de relativement satisfaisant par rapport au nouvel état de votre supply chain, cela n’arrivera jamais. Les gens se rabattent tout simplement sur les tableurs. Il n’y a tout simplement pas de temps pour franchir toutes ces étapes. Vous revenez à vos tableurs qui ne vous offrent peut-être pas ce type d’optimisation, mais qui vous fournissent au moins une réponse dans un délai raisonnable.
Je pense que c’était aussi ce genre de domaine dans lequel Lokad excellait à cette période. Nous avions l’optimisation, mais nous disposions d’outils d’optimisation suffisamment agiles pour être testés à plusieurs reprises, des dizaines de fois par jour, jusqu’à ce que nous ayons quelque chose qui fonctionnait réellement. Sinon, nos clients auraient tout simplement abandonné le type de services que Lokad offrait à l’époque.
Ian Wright : C’est intéressant, car j’ai toujours eu des difficultés avec ce que j’appelle l’optimisation instantanée. Particulièrement, la planification de la supply chain et les modèles de réseau ont toujours reposé sur une programmation en nombres entiers instantanée. Les solveurs sont tous instantanés, et tout ce problème de timing, j’ai toujours peiné à comprendre comment nous pourrions tirer profit des approches de type simulation, qui nous permettent d’incorporer la dimension temporelle un peu mieux, et comment nous pourrions en quelque sorte combiner une approche.
Par exemple, il existe une entreprise en Russie, une entreprise de simulation, qui a proposé de combiner l’optimisation. J’ai trouvé cela génial à l’époque. Malheureusement, je ne suis pas très familier avec leur implémentation de la partie optimisation, car c’est une entreprise de simulation. La question du temps est une chose. L’autre problème, je pense, dans la détermination d’une solution avec une certaine probabilité, implique également un enjeu technologique que nous sommes aujourd’hui mieux en mesure d’affronter. Il s’agit de la quantité de données, de l’étendue des données que l’on peut intégrer pour élaborer la solution.
Beaucoup de choses échappent au cadre de la société, de l’entreprise ou de la division pour laquelle vous optimisez, et ne sont pas prises en compte lorsque vous lancez un nouveau produit ou lorsque vous entrez dans un monde entièrement nouveau après une pandémie. La seule chose sur laquelle vous pouvez souvent compter, ce sont des données qui n’ont rien à voir avec l’historique de vos opérations précédentes. Vous devez examiner un périmètre de données beaucoup plus large afin que, lorsque vous établissez des probabilités, par exemple, vous puissiez intégrer des variables exogènes en plus de toutes les variables traditionnelles liées à l’activité que vous tentez de poursuivre.
Joannes Vermorel : Conceptuellement, oui, bien que je ne sois pas entièrement d’accord sur ce point. Le fait est que les données au-delà des données transactionnelles sont très coûteuses pour les entreprises. Se procurer des données sur l’intelligence concurrentielle, c’est plutôt acceptable, ce n’est pas trop coûteux, mais si l’on va au-delà, par exemple en se contentant de récupérer les prix de vos concurrents, cela devient très rapidement très compliqué.
Notre approche est la suivante :, généralement, il faut d’abord avoir des modèles permettant d’examiner vos données de manière plus informative. Un exemple serait le lancement d’un nouveau produit, pour lequel vous ne disposez d’aucun historique de ventes, donc la perspective traditionnelle des séries temporelles vous indique que vous n’avez rien. Mais si vous renoncez à la perspective des séries temporelles et adoptez une vision alternative, vous pourriez constater que vos lancements de produits suivent un schéma du type réussite ou échec et que les succès que vous pouvez attendre se comportent selon une certaine distribution, tout comme les échecs. Ainsi, oui, vous pouvez utiliser vos données historiques pour tirer des conclusions sur le produit.
Encore une fois, lorsqu’un studio méconnu lance un film, les chances que ce studio produise un film qui engrangera 1 milliard dans les salles de cinéma sont extrêmement faibles. Mais s’il s’agit de Disney ou de Warner Brothers, alors les chances sont peut-être d’environ 5 %.
Ainsi, d’abord, en utilisant les données transactionnelles dont disposent les entreprises, vous pouvez généralement en déduire bien plus que ce que l’on pense, car elles sont ancrées dans la perspective des séries temporelles. Il existe d’autres approches.
La deuxième chose, c’est que si vous admettez que vous ne savez tout simplement pas, rappelons que les personnes qui prendront ces décisions, en tant qu’humains, ne disposent pas non plus d’une source secrète d’information. Il n’existe pas de boule de cristal dans le cerveau humain qui vous permette de jeter un coup d’œil dans l’avenir, surtout lorsqu’on parle de supply chain où nous avons des dizaines de milliers de produits dont vous ne connaissez l’existence que de nom. Beaucoup de personnes occupant le poste de demand planner ne sauraient même pas exactement ce que leur entreprise vend ou produit.
Pour revenir à cela, je dirais que, d’abord, nous disposons de données transactionnelles qui peuvent être exploitées de bien des manières dès que vous abandonnez la perspective des séries temporelles. Mais il faut aussi tenir compte du fait que ces informations supplémentaires sont très difficiles à obtenir. Peut-être devrions-nous donc accepter d’avoir un fort degré d’incertitude.
Les outils traditionnels n’acceptent même pas de traiter l’incertitude. Quand je parle d’outils traditionnels, je fais référence à tous les solveurs qui offrent l’optimisation mathématique sur le marché. Tous les solveurs établis que je connais sont simplement des solveurs déterministes ; ils ne peuvent pas gérer l’incertitude. Nous avons récemment accueilli sur cette chaîne un pionnier qui tente d’établir son prototype d’optimiseur stochastique InsightOpt, Meinolf Sellmann, qui utilisait ses instruments Seeker. Mais c’est vraiment unique en son genre, et c’est à peu près le seul que je connaisse qui essaie de poursuivre cette voie d’un point de vue commercial.
Pour revenir au cas présent, mon opinion est que si vous ne disposez d’aucun outil pour gérer l’incertitude, sous quelque forme que ce soit, l’idée de traiter cette situation en gonflant simplement l’incertitude et en la laissant ainsi n’est même pas envisageable. Mais si vous possédez ces outils, alors cela devient tout à fait naturel. Vous essayez quelque chose d’inédit, l’incertitude atteint des sommets, et votre optimiseur vous permet tout simplement d’agir en conséquence.
Ian Wright : Je pense que notre désalignement provient du fait qu’il y a une différence de focalisation entre la planification stratégique et la planification, notamment lorsque l’on se rapproche de l’exécution, où les options se réduisent de manière spectaculaire. Je viens d’un univers principalement orienté vers la planification stratégique. Lorsque vous dites, par exemple, qu’une grande partie de ces données supplémentaires pour un nouveau produit est coûteuse, cela peut être vrai, mais il existe une multitude de types de données que vous pouvez exploiter dans la modélisation avant d’en arriver à l’optimisation.
Vous pouvez modéliser la corrélation entre de nombreux aspects exogènes des données économiques et des données démographiques liées au type de produit et au marché auquel vous souhaitez proposer ce produit. C’est de là que je viens, Joannes, quand je parle d’ajouter davantage d’éléments de données. Je parle d’observer la corrélation avec ce qui constitue des données raisonnablement accessibles, généralement liées à la démographie et à la pénétration du marché.
Un autre aspect, et je pense que c’est finalement ce à quoi nous devrions toujours penser en tant que fournisseurs de technologie et praticiens dans ce domaine, c’est que, fondamentalement, les entreprises tournent autour de la finance. Un élément majeur de ce que nous devons faire en planification est de réduire le tout au coût et à la minimisation des coûts, selon les circonstances. À mon avis, les données sur les coûts ont été insuffisamment exploitées dans, par exemple, les modèles de réseau pour l’optimisation de la supply chain. Les gens se contentaient d’accepter des hypothèses sur les coûts en les intégrant aux modèles, plutôt que de rechercher de manière concrète des attentes bien plus précises en matière de coûts, ce qui est tout à fait faisable. Je pense que c’est simplement quelque chose qui, avec la technologie dont nous disposons aujourd’hui, est bien plus mûr pour être exploité et mieux compris quant à ce que nous pouvons faire pour intégrer des données et appréhender l’ensemble du contexte dans lequel nous évoluons.
Conor Doherty : C’est un point parfait à développer un peu, car une fois que vous disposez de toutes les données, il faut finalement prendre une décision. Un autre aspect dont vous parlez dans l’article est le rôle des compromis dans la prise de décisions. Même une fois muni de votre modèle et de toutes les données, vous vous retrouvez néanmoins face à un certain nombre de décisions, souvent sous forme d’options. Comment les compromis s’intègrent-ils dans la recherche de la décision optimale ?
Ian Wright : Je vais faire un point rapidement. Vous n’avez jamais l’ensemble complet des données. Vous disposez bien évidemment des données que vous avez, mais elles sont toujours imparfaites. Il faut donc travailler avec ce que vous avez. Je suis cynique dans l’âme, comme vous pouvez le constater, n’est-ce pas ? En ce qui concerne les compromis, il y a les compromis évidents dans la supply chain. Votre compromis est fondamentalement financier. Est-ce que je souhaite dépenser de l’argent pour fournir le service et le produit que mon client désire ? Je veux fournir le produit de la manière dont le client souhaite que je le fournisse, et cela signifie que je dois dépenser de l’argent pour le faire. Jusqu’où suis-je prêt à aller dans cette voie ?
Le compromis, par exemple, se situe entre les stocks et le coût de transport. Mais il existe aussi des compromis quant au nombre de mesures de contingence que je mets en place pour atténuer le risque. Combien de voies opérationnelles potentielles dois-je créer pour mon entreprise afin de pouvoir exécuter un plan probabiliste qui dévie de mon mode d’exécution habituel ? Un compromis consiste à se demander si je considère les implications à court terme des modèles que je poursuis et des plans que je mets en place, ou si j’intègre le long terme, ce qui signifie très souvent un compromis financier puisque j’investis dès maintenant pour quelque chose qui ne se produira que plus tard.
Pour moi, les compromis sont en quelque sorte un euphémisme pour dire qu’il faut que je mette les finances en ordre. Comment puis-je équilibrer tous ces aspects ? Je ne sais pas si je réponds exactement à votre question, Conor, mais tout se résume à ce que je suis prêt à ajuster dans mon modèle, sachant que je suis limité dans la manière dont je peux en définir la portée. Qu’est-ce que je suis prêt à ajuster pour obtenir le bon emplacement du symbole dollar ou euro ?
Conor Doherty : Merci, Ian. Et Joannes, je m’adresse désormais à vous car, encore une fois, je vous prépare à aborder un sujet que je sais que vous aimez traiter. J’ai fait remarquer qu’à la base, ce que les gens cherchent à optimiser explicitement – corrigez-moi si je me trompe – c’est en fait le coût ou les finances. Mais le fait est que, bien souvent, lorsqu’il s’agit de prise de décision dans la supply chain, les personnes ou les entreprises cherchent à optimiser des éléments tels que les taux de service. Je pense que vous avez déjà souligné que ce que les gens pensent optimiser, c’est le coût, mais qu’en réalité ce n’est qu’un artefact numérique. La question, si vous pouvez en parler, est la suivante : lorsque les gens se concentrent sur ces objectifs traditionnels dans la supply chain, optimisent-ils réellement le coût ou se trompent-ils de direction ?
Joannes Vermorel : Si l’on considère les pratiques dominantes de la supply chain de nos jours, dans les PowerPoints, on affirme se concentrer sur ce qui est économiquement viable. En pratique, ce n’est pas le cas. C’est une question de pourcentages en termes de taux de service, de retours sur stocks, etc. Ces éléments sont faiblement corrélés à votre résultat net, mais seulement faiblement.
Penser que votre rentabilité est corrélée de quelque manière que ce soit à vos taux de service est tout simplement insensé. Ça ne fonctionne pas. C’est une approche très simpliste. La première chose serait d’affirmer que les pratiques dominantes reposent, en fait, sur le fait que les gens savent intuitivement qu’ils ne peuvent convaincre personne en disant qu’ils veulent optimiser des pourcentages. Ainsi, dans les présentations, ils diront que nous optimisons ces dollars, mais en pratique, dans leurs systèmes logiciels, ils ont des règles qui ne sont absolument en accord d’aucune manière avec ces modélisations en dollars. Je dirais que ceux que j’ai vus sur le terrain, en mettant Lokad de côté, étaient strictement des perspectives non financières et non économiques.
Maintenant, si nous abordons une perspective économique où l’on commence à prendre en compte ces dollars, je suis entièrement d’accord sur le fait qu’il est très difficile de bien faire les choses. C’est difficile, et en fait, on a de nombreuses histoires d’horreur, souvent racontées dans les films hollywoodiens, où le financier est le méchant qui adopte une pensée à court terme incroyablement stupide au détriment de quelque chose qui serait un peu plus éloigné dans le futur.
La perspective financière a mauvaise réputation, et en effet, le genre de perspective que la recherche opérationnelle mettait en avant il y a 40 ans était une approche très simpliste. Ils se concentraient vraiment sur un très petit nombre de variables de base : coûts — coût des stocks, coût de ceci, coût de cela — et bam, c’est fini, le travail est fait, la magie opère avec la solution optimale qui émerge du modèle.
Chez Lokad, nous avons remarqué cela et réalisé que nous avions un véritable problème, à savoir comment savoir si notre fonction d’évaluation, notre fonction d’évaluation économique – celle qui compte les dollars – délivre une version approximative de la vérité suffisamment fiable. C’est une question très difficile, et ce que nous avons découvert, c’est une méthodologie documentée dans ma série de conférences sur la supply chain, appelée optimisation expérimentale.
La façon de savoir que votre modèle économique est correct, c’est lorsqu’il génère des décisions sensées. C’est très étrange. Au final, on pensait qu’il fallait disposer de la bonne métrique d’évaluation pour obtenir des décisions optimales. Nous faisons exactement le contraire. Nous générons des décisions, puis, parmi ces décisions générées qui ont été poussées à l’extrême selon cette métrique, nous vérifions si elles sont sensées ou non.
Lorsque nous voyons des décisions manifestement dysfonctionnelles et carrément insensées, nous revenons très souvent à la modélisation économique en réalisant que quelque chose ne va pas, quelque chose nous a échappé. Nous avons donc ce processus très itératif où nous choisissons nos dollars, nous optimisons, nous obtenons des décisions, dont certaines sont insensées, nous révisons la manière dont nous comptons les dollars, et ainsi de suite.
Après de nombreuses itérations, nous finissons par converger vers un résultat sur lequel plus personne n’a de doutes. C’est ce que nous appelons le principe du zéro insanité. Nous voulons aboutir à une configuration où le système ne génère aucune ligne manifestement insensée dès le départ. C’est en réalité le point que nous, chez Lokad, considérons comme nécessaire avant de passer en production.
Mais voyez-vous, l’essentiel est que nous inversions complètement le type de perspective de la recherche opérationnelle. Au lieu d’affirmer que la fonction d’évaluation est acquise, c’est quelque chose que nous allons découvrir par un processus incrémental. C’est très étrange, car cela va à l’encontre, du moins pour les Français, de cette perspective cartésienne de pensée ascendante qui consiste à appliquer des principes et simplement les dérouler. Il s’agit d’un processus beaucoup plus empirique.
Ian Wright: Je dois avouer, et je m’en excuse, que j’ignore relativement bien Lokad. Mais je suis très intrigué par votre définition de la senséité dans le contexte dont vous parlez. Qu’est-ce qui constitue une décision sensée ?
Joannes Vermorel: Ian, pour donner un exemple que j’ai cité dans ma série de conférences, je vais commencer par une analogie, puis nous reviendrons à la supply chain. Il existe des catégories de problèmes où, si vous voulez résoudre le problème général, c’est d’une difficulté inimaginable, mais les cas particuliers sont très faciles.
Un exemple de cela serait, disons, que je vous donne un film à regarder en vous indiquant qu’il s’agit d’un gladiateur romain ou autre, et je vous demande de repérer s’il y a des éléments complètement hors contexte par rapport à la période historique, comme un avion en arrière-plan. Il existe un film célèbre dans lequel ils se battent dans une arène et où un avion apparaît dans le ciel en arrière-plan.
Si je vous demandais de trouver un algorithme général pour me dire toutes les choses qui pourraient mal tourner dans un film et qui ne reflètent pas l’époque, ce serait une tâche tout à fait décourageante. Il vous faudrait une encyclopédie de tout ce qui n’avait pas encore été inventé – y compris les termes, l’ambiance, l’attitude, le type de pensée. C’est un problème d’une complexité incroyable. Mais en pratique, si vous confiez le visionnage à un stagiaire, il vous dira : “Oh, il y a un avion ici, c’est mauvais.” Je ne peux pas vous fournir la liste de toutes les choses mauvaises, mais je peux repérer ce morceau d’insanité.
Les systèmes de supply chain sont très similaires. Il est très difficile de vous donner une règle générale pour établir exactement ce qui compte comme insensé ou non. C’est un problème d’intelligence générale, pas quelque chose que l’on peut simplement condenser dans un algorithme simple. Mais il s’avère que les gens sont en réalité plutôt doués pour repérer ces problèmes.
Un exemple serait que vous avez une série de ruptures de stock dans vos données historiques, qui ne sont pas correctement intégrées, et soudainement, votre estimation de la demande future tombe à zéro parce que vous avez eu des ruptures de stock, donc vous n’avez pas vendu, et votre modèle prévoit bêtement zéro. Ensuite, vous finissez par proposer zéro reapprovisionnement comme bonne politique. Il dit : “Quel est votre niveau de stock cible ? Zéro, parce que nous avons observé très peu de demande, alors maintenons-le à zéro.”
Si vous commencez à y réfléchir, oui, ma prévision sera 100 % précise parce que je prévois zéro, je réapprovisionne zéro, et tout va bien. Mais non, tout n’est pas en ordre. Ce problème est appelé un gel de stocks. C’est un exemple d’insanité, et vous avez de nombreuses situations de ce genre où, en regardant les décisions, vous pouvez identifier des éléments dysfonctionnels, où les chiffres sont implausiblement élevés ou bas, ou simplement des choses qui n’ont aucun sens.
Un exemple que nous avons eu historiquement chez Lokad, pour l’un de nos premiers clients en aéronautique, fut le réapprovisionnement en stocks : nous avons suggéré d’acheter certaines pièces. Le client nous a répondu : “Oh non, nous n’allons pas acheter ces pièces. Ces pièces iront sur un Boeing 747, et dans dix ans, il n’y aura plus de Boeing 747 volant au-dessus de l’Europe. Ces pièces ont une espérance de vie de quatre décennies, donc si nous les achetons maintenant, nous ne les utiliserons que pendant dix ans, puis ces avions auront disparu.”
C’était quelque chose d’évident, car nous avions oublié de prendre en compte le fait que l’utilité d’une pièce ne peut dépasser la durée de vie de l’avion qu’elle sert. Ce genre de situation, selon les secteurs, vous offrira un flux infini d’éléments qui se présentent comme des manifestations de ces insanités. Bien que je ne puisse pas vous fournir une règle générale ou un algorithme pour détecter cela, en pratique, cela fonctionne très bien car les gens parviennent à repérer ces éléments.
Ian Wright: Nous sommes maintenant carrément sur la même longueur d’onde, curieusement, car je sais que nous voulons aborder certains sujets à venir. Ma prémisse principale dans ma carrière, en ayant travaillé avec toute cette technologie et en ayant injecté la technologie dans l’entreprise de la victime, a toujours été que l’on ne peut pas exclure l’humain. Il faut prendre en compte l’humain et l’utiliser dans le processus de déploiement et d’utilisation de la technologie.
Parce qu’en ce moment, et pour mon avenir prévisible, nous n’avons pas de technologie capable de remplacer nombre des aspects de l’humain dont vous parlez, en termes de reconnaissance de l’absurde, par exemple, ou de reconnaissance de l’insensé. Cela n’existe tout simplement pas encore. La seule manière de le voir se réaliser serait d’incorporer, d’une manière ou d’une autre, des aspects de l’humain dans le processus. Aujourd’hui, ce n’est tout simplement pas faisable.
Joannes Vermorel: Oui, je suis d’accord avec vous. Il y a deux points auxquels j’aimerais répondre dans vos commentaires. Premièrement, parfois, les décisions insensées ne peuvent être identifiées comme telles qu’après coup. Il faut faire l’erreur pour se rendre compte que quelque chose d’inattendu s’est produit et que c’était mauvais. Mais au-delà de l’humain, l’information doit revenir du monde réel. Vous avez besoin d’un retour concret pour obtenir ces informations. Autrement dit, c’est une question d’intelligence de haut niveau. Même si nous disposions d’une intelligence artificielle aussi intelligente qu’un humain, il y a des limites. Dans une certaine mesure, la seule façon de connaître le monde est de se donner une marge de manœuvre pour expérimenter. Ce serait le premier point.
Le second point concerne le rôle des personnes. La manière dont mes pairs ont conçu les systèmes est qu’ils utilisent les humains comme coprocesseurs. Votre système génère des décisions, des chiffres, des allocations de ressources, etc. Ensuite, il y a toutes ces lignes qui sont insensées, et vous vous attendez à disposer d’une armée de commis pour intervenir manuellement et corriger tout cela. Pour le public, tous les systèmes comportant des alertes et des exceptions font exactement cela. Les alertes et les exceptions ne sont qu’une autre façon de dire que nous avons des coprocesseurs humains qui vont traiter ce que mon système ne traite pas.
Mon problème avec cela, c’est que les gens sont assez chers. C’est le coût. Ainsi, à mon avis, ce n’est pas la meilleure utilisation de leur temps, car vous allez voir ces coprocesseurs humains tourner sans cesse en boucle sur le même non-sens, le même cycle d’alertes et d’exceptions.
C’est pourquoi, chez Lokad, nous abordons cela d’une manière complètement différente. Nous disons que dès qu’un non-sens est détecté, comme une alerte ou une exception, quelqu’un chez Lokad, le Supply Chain Scientist, doit intervenir et ajuster l’implémentation de ce qui effectue l’optimisation prédictive, afin de corriger le problème pour qu’il ne se reproduise plus. Aucune exception. Chaque non-sens relevé est évalué. Est-ce réellement du non-sens ou bien une optimisation très astucieuse ? S’il s’agit effectivement de non-sens, alors la logique d’optimisation elle-même doit être corrigée. Vous ne voulez pas que le même employé signale le même problème le lendemain.
Ian Wright: Je pense que nous sommes toujours sur la même longueur d’onde, certainement dans le même chapitre. Je viens plutôt d’un point de vue stratégique et tactique, où je ne suis pas inquiet de devoir aller observer une salle pleine de Big Brother sur des écrans d’ordinateurs corrigeant des anomalies. Je parle de ce qui est nécessaire pour le déploiement des opérations, au sens stratégique ou tactique. Cela signifie impliquer les parties prenantes expérimentées pour maintenir le sens dans la direction que vous prenez et dans les solutions que vous déployez.
En ce qui concerne l’idée globale de la manière dont je pense que vous encadrez votre argument, Joannes, à mesure que nous avançons avec le type de technologie que vous développez et avez développé, et avec l’évolution générale vers une plus grande capacité en termes d’IA, la capacité pour un système de s’auto-corriger dans un contexte de gestion d’événements va devenir plus réalisable. Nous nous éloignerons de la coûteuse salle d’opérateurs informatiques humains. Mais ce n’est pas le cas aujourd’hui, donc vous devez travailler dans les limites des capacités dont vous disposez à ce moment-là.
Conor Doherty: Si je puis me permettre, c’est simplement parce qu’il semble, Ian, que vous commentiez davantage sur le rôle de l’humain dans le sens stratégique, et, Joannes, que vous sembliez aborder la prise de décision dans la routine quotidienne. S’agit-il de magistères non chevauchants ?
Joannes Vermorel: C’est parce que, vous voyez, ma perspective – et peut-être est-elle un peu étrange – est que, si nous entrons dans le domaine de la considération stratégique, alors votre attention sur l’exploitation d’une supply chain devrait se focaliser sur la manière de concevoir la machinerie qui génère les décisions appropriées. On pense qu’il existe des décisions stratégiques, des décisions tactiques, et cetera. Pour moi, il y a des décisions qui se répètent. Certaines se répètent chaque jour, d’autres chaque heure, d’autres chaque mois, et d’autres une fois par an. Lorsqu’il s’agit de mécanisation, vous voulez mécaniser tout ce qui se répète de manière suffisamment fréquente. Vous vous occupez des autres de façon complètement ad hoc.
La stratégie, si vous commencez à penser selon cette approche, ne consiste pas tant à décider quelque chose à un certain niveau, puis à laisser les autres strates de votre organisation intervenir à d’autres niveaux. Il s’agit plutôt d’une vision stratégique qui détermine ce que je fais pour que la culture d’ingénierie de mon entreprise fasse émerger, de cette culture, des processus de prise de décision mécanisés qui améliorent véritablement mon résultat net. C’est une façon complètement différente de concevoir la stratégie.
Ian Wright: Je suis complètement d’accord avec vous. La manière dont j’ai toujours vu les choses est que le rôle de l’architecte est de concevoir le concept d’un bâtiment, puis il est remis à l’ingénieur qui détermine comment il sera assemblé, ensuite à ceux de la construction qui l’érigent effectivement, et finalement aux personnes qui y travaillent et qui l’entretennent. À tous ces niveaux, l’architecte ne devrait pas proposer quelque chose qui ne puisse être conçu, construit ou entretenu. C’est mon analogie de haut niveau du processus dans lequel nous sommes impliqués.
Dans la supply chain, cependant, c’est un peu différent, car vous pouvez créer une stratégie aujourd’hui, mais vous devez refaire la même chose l’année suivante. Le problème avec la supply chain, c’est qu’elle est dynamique et adaptative. Nous devons répondre à un monde en constante évolution et à ses besoins. Vous répétez votre processus stratégique, mais vous devez le faire de manière faisable, pragmatique, et qui vous permettra de mettre en place une solution opérationnelle.
Joannes Vermorel: Pour vous donner un peu de perspective, pendant les confinements de 2020 et 2021, nous avons eu pas mal de clients – plus d’une douzaine – dont les employés de bureau sont partis pendant 14 mois. Lokad s’est retrouvé seul à prendre toutes les décisions de supply chain pour des entreprises où la main-d’œuvre ouvrière était encore opérationnelle. Les employés de bureau étaient en congés imposés par le gouvernement, subventionnés. Ils étaient payés, mais les gouvernements européens obligeaient également à ne pas travailler de chez soi, sinon ils ne percevaient pas les subventions. Ils étaient donc effectivement en congé.
Nous gérons, pour une douzaine de clients, plus d’un milliard d’euros de stocks exploités intégralement pendant 14 mois. Cela représentait plus d’un millier d’employés au total. Et cela soulève vraiment la question de ce que ces processus de supply chain supposément stratégiques apportent réellement.
Lorsque je regarde la plupart des réunions S&OP, il y aura de longues discussions pour décider du budget que nous allouons aux achats pour divers départements. Tout cela peut être remplacé par une formule. Si nous ne sommes pas d’accord avec une formule parce qu’elle donne des résultats insensés, alors nous corrigeons la formule. Mais nous n’avons pas besoin de rencontrer 12 directeurs et de passer par toutes les dépenses pour arriver à ce calcul budgétaire. Cela peut être automatisé.
En termes de stratégie, la question serait la suivante : comment puis-je m’assurer que l’ingénierie intégrée à cette formule qui alloue mes ressources de haut niveau est réalisée de manière à être en phase avec les intérêts de mon entreprise ? C’est un problème très intéressant et oui, cela devrait capter l’attention de la direction qui souhaite penser stratégiquement. L’idée de choisir quelques décisions au pif en disant, “I am going to be involved in that,” n’apporte pas vraiment beaucoup de valeur.
Dans de nombreuses entreprises, ce qui se passe dans ces réunions soi-disant stratégiques, c’est qu’on perd énormément de temps. Oui, elles génèrent des décisions, mais avec une productivité absolument déplorable. Je crois qu’un invité précédent évoquait le sujet du S&OP et m’a dit qu’ils finissaient généralement par prendre environ quatre décisions par heure.
Conor Doherty: C’était Eric Wilson, oui, dans un processus de S&OP.
Joannes Vermorel: Oui, et je pensais, d’accord, nous avons tout simplement des centaines de milliers de décisions à prendre, et maintenant nous n’en prenons qu’environ quatre par heure. Il est évident que dans une telle situation, les opérations seront toujours bien en avance sur vos plans.
Au moment où vous prenez vos décisions, elles sont complètement obsolètes, et les gens ont déjà fait autre chose parce qu’ils ne pouvaient pas attendre aussi longtemps ces décisions. Nous nous retrouvons dans une situation où c’est plus une mascarade. Les gens prennent des décisions stratégiques concernant des choses qui se sont déjà produites il y a environ deux ans.
Conor Doherty: Eh bien, cela m’intéresse. Juste pour vous préparer à la suite, car je sais que dans l’article vous avez parlé d’une prise de décision supply chain plus décentralisée, et vous avez donné l’exemple de Walmart.
Vous pouvez le décrire mieux que je ne le peux.
Ian Wright: Faire cela correctement et de manière efficace signifie que vous décentralisez la décision, mais que cette décentralisation et cette prise de décision se font toujours dans un contexte conçu de manière efficace et appropriée. Ainsi, vous ne vous éloignez pas trop de la stratégie centrale de l’entreprise.
Dans ce cas, nous parlons de la décentralisation de ce que j’appellerais des décisions plus tactiques. Mais tout revient à Joannes. Je ne suis absolument pas en désaccord avec toi. Ce dont nous parlons, c’est que les gens ne travaillent pas seulement en silos au sein des organisations, mais qu’ils planifient et fonctionnent également en silos. Les gars de la supply chain se lancent et élaborent leur plan stratégique supply chain, puis ils réfléchissent au plan de transport, et ensuite au plan d’entrepôt.
Tous ces plans sont interdépendants et, malheureusement, très souvent exécutés de manière indépendante. Nous ne pouvons fondamentalement pas élaborer une solution supply chain stratégique optimale à moins d’incorporer un plan de réseau, un plan de transport et un plan de stocks dans un modèle opérationnel.
Tout le cas de figure de Lokad opérant sans les cadres dans le bâtiment est pour moi un excellent exemple d’un modèle opérationnel qui vous permet de soutenir les opérations sans vous éloigner trop du plan que vous pensiez nécessaire il y a six mois, malgré les disruptions. Vous avez réuni les bonnes personnes, les bons processus, et vous disposez de la technologie et des programmes en place pour faciliter cette exécution.
Je soutiens vraiment, bien plus que l’idée de parvenir à l’optimalité pure, qu’il ne suffit pas d’avoir un plan optimal : il faut être capable de l’exécuter et de le maintenir aussi fidèlement que possible. Sans ce modèle opérationnel – et j’irai au-delà des traditionnels aspects personnes, processus et technologie – il vous faut cela. C’est véritablement votre plan stratégique d’entreprise, et tous ces autres plans stratégiques autour de la supply chain doivent s’inscrire dans ce cadre. Si vous ne faites pas correspondre le modèle opérationnel dont vous disposez aux plans que vous élaborez, alors c’est la recette du désastre.
Conor Doherty: Ian, si je peux résumer cela en une citation, vous avez dit plus tôt que vous ne pouviez pas exclure les humains. Alors, Joannes, êtes-vous d’accord pour dire qu’on ne peut pas se passer de l’humain, particulièrement dans la prise de décision stratégique dont parle Ian ? Est-ce quelque chose qui pourrait être intégré dans un cadre automatisé que vous avez déjà appliqué à la gestion banale du quotidien de l’entreprise ?
Joannes Vermorel: Sur la question de savoir si nous possédons une intelligence artificielle générale, nous n’en avons pas. Nous nous en rapprochons, certes. Les LLMs exhibent des étincelles d’intelligence générale, mais seulement des étincelles. Donc, je dirais que, chez Lokad, à l’heure actuelle, nous ne pouvons certainement pas prétendre disposer d’un logiciel si sophistiqué qu’il pourrait contourner le besoin du cerveau humain. En fait, au cœur de notre pratique, nous avons ce que nous appelons des Supply Chain Scientist qui sont des ingénieurs programmant les recettes numériques. C’est une affaire très humaine que nous ne déléguons pas encore aux machines.
Bien qu’avec l’autocomplétion et autres, les algorithmes puissent aider à coder plus rapidement, la véritable question est la suivante : lorsque vous disposez d’intelligences humaines, leur confie-t-on une tâche qui apporte réellement de la valeur grâce à leur intelligence générale, plutôt que de se limiter à de la simple reconnaissance de motifs ou quelque chose qui peut être mécanisé ?
Mon contre-argument serait que de nombreuses entreprises, en particulier celles qui opèrent des supply chains, n’exploitent pas au mieux le potentiel des employés de bureau dont elles disposent. Elles restent encore dans l’état d’esprit d’avoir des hordes de fonctionnaires d’entreprise qui se contentent de suivre un processus, et l’adhésion à ce processus est leur objectif.
Je constate que beaucoup de ces entreprises opérant des supply chains traitent l’essentiel de leurs employés de bureau exactement comme ils traitent leurs ouvriers. Il y a un processus, et le respect de ce processus est défini comme l’excellence.
Pour les ouvriers, c’est clair, c’est ce que vous voulez. Mais si nous abordons le domaine des employés de bureau, cela devient très étrange car l’information est de plusieurs ordres de grandeur plus facile à mécaniser que le monde réel.
Traiter avec des choses physiques, par exemple, si vous voulez avoir un robot capable de souder dans toutes les situations, c’est extrêmement difficile. Simplement bouger une main, tenir un outil, supporter quelque chose de lourd et être dans un environnement avec de la poussière ou des contaminants, nous parlons ici d’une robotique extrêmement avancée juste pour pouvoir faire quelque chose que quelqu’un pourrait accomplir avec quelques mois de formation.
Maintenant, si nous entrons dans ce monde de l’information, vous savez, sur le papier, les contraintes ne sont pas aussi exigeantes. Nous pouvons déplacer des gigaoctets de données sans aucun problème. Les personnes qui occupent ces emplois de bureau travaillent déjà avec des systèmes informatiques. Toutes les informations qu’elles reçoivent transitent par un ordinateur, et toutes les informations qu’elles produisent y sont déjà saisies. Nous disposons donc d’un cadre entièrement numérique.
Ce que je dis, c’est que les entreprises utilisent la majorité de leurs employés de bureau comme co-processeurs. Ils disposent de ce que le processeur de l’ordinateur peut faire avec le logiciel que nous avons, et ensuite il y a quelqu’un pour combler les lacunes. Mais utilisons-nous réellement l’intelligence de ces personnes ? Mon argument est non. S’il s’agit d’une question d’importance stratégique, il faut s’assurer que tous les employés de bureau contribuent à des tâches pour lesquelles seule une intelligence générale peut apporter une réelle valeur. Si c’est une tâche ne nécessitant pas d’intelligence générale, alors cela devrait être mécanisé.
Ian Wright: Je suis d’accord. Votre insistance sur l’approche mécaniste définit ce qu’est l’automatisation et pour quoi l’humain est nécessaire. Le moment où l’humain apporte réellement de la valeur – et comme vous le dites, Joannes, cela n’est probablement pas déployé correctement – se situe dans les domaines intuitifs où il est impossible d’apporter une contribution de manière mécaniste. Par exemple, en considérant qu’un avion sera obsolète dans 10 ans, pourquoi le ferait-on ? C’est quelque chose que l’on ne peut pas construire de manière mécaniste.
Là où l’humain est indispensable, c’est lorsqu’il doit apporter une contribution organique à un problème ou à une situation, que ce soit en gestion d’événements ou en gestion opérationnelle supply chain. Vous pouvez mettre en place des mécanismes de diagnostic relativement facilement. Un domaine qui reste encore fertile pour le travail est l’utilisation de boucles de rétroaction qui aident à générer des solutions proactives dans un contexte mécaniste. Cela inclut l’accumulation d’informations issues d’une plus grande variété d’origines de données dans cette gestion opérationnelle mécaniste proactive. Mais on ne peut pas surpasser l’aspect intuitif des choses. Il y a un aspect émergent dans ce que l’humain apporte lorsqu’il essaie de regarder un problème ou, plus important encore, d’anticiper un problème.
Joannes Vermorel: Je suis tout à fait d’accord. Ici, j’en veux aux séries temporelles. La pratique dominante des supply chains de nos jours tourne entièrement autour des séries temporelles. Mais si vous regardez les entreprises qui excellent dans leur domaine, elles savent tirer intelligemment parti des retours qu’elles reçoivent, comme Amazon. Amazon utilise très intelligemment les retours de ses clients pour résoudre de manière systématique la plupart de ses problèmes de supply chain et de logistique.
Si un livreur est régulièrement signalé pour avoir perdu des colis, Amazon cessera d’utiliser ce prestataire et passera à un autre. Si un fournisseur cause des problèmes, ils le renvoient. Ils font un usage raisonnable des données de retour qu’ils collectent. Ils ont besoin d’humains pour imaginer quel type de retours ils peuvent recueillir, et d’ingénieurs pour élaborer les recettes numériques qui déterminent quand renvoyer un fournisseur ou notifier un prestataire logistique.
Ils procèdent probablement à une optimisation intelligente, par exemple en remarquant qu’un transporteur est fiable dans certaines conditions mais pas dans d’autres, et en n’utilisant ce transporteur que dans ces configurations. Cela nécessite une vision de ce que sont des données pertinentes, et pas seulement des séries temporelles concernant la demande. Il faut un état d’esprit d’ingénieur pour apporter des corrections profondes aux problèmes, et non simplement pour éteindre des incendies. La plupart des entreprises passent d’une urgence à une autre, consommant toute leur capacité et empêchant ainsi toute amélioration. Amazon, en revanche, conçoit des solutions profondes pour chaque situation rencontrée, éliminant des catégories de problèmes et passant à la suivante.
Ian Wright: Malheureusement, tout cela revient aux finances. Si vous avez les poches profondes pour adopter ce type de réflexion auquel vous faites allusion, c’est une chose. Mais la plupart des managers supply chain ne travaillent pas dans un environnement où ils disposent de liquidités suffisantes pour traiter les problèmes de cette manière. Ils jouent à rattraper le temps perdu, éteignent des feux, et se retrouvent dans un cercle vicieux.
Si, en tant que praticien, vous avez l’occasion de travailler sur un projet stratégique, ne placez pas le modèle en premier. Comprenez le monde du manager supply chain tel qu’il existe aujourd’hui, puis réfléchissez comme si vous étiez Amazon pour imaginer comment ce monde pourrait fonctionner afin qu’il n’ait pas à courir après le temps perdu. Malheureusement, la plupart des managers supply chain abordent les projets stratégiques de la même manière que leur travail quotidien, qui n’est qu’un autre incendie à éteindre. Les personnes des deux camps n’y parviennent pas correctement, mais cela pourrait être abordé différemment en repensant le rôle.
Conor Doherty: Messieurs, je suis conscient du temps, donc je reviens vers vous, Ian, pour vous interroger sur l’optimalité pratique. Pour nous guider vers une conclusion, quelles sont les étapes pratiques que les gens peuvent suivre dans la quête de l’optimalité ?
Ian Wright: Encore une fois, j’aborde cela d’un point de vue stratégique, et non en étant la personne sur le terrain qui tente de mettre le produit entre les mains du client. Ce que vous devez faire en envisageant l’optimalité, c’est y réfléchir en considération de la manière dont cette exécution aura réellement lieu. Assurez-vous de vous concentrer sur la proposition d’une solution réalisable et opérationnelle, qui correspond à la manière dont l’entreprise fonctionne aujourd’hui.
Si vous en avez la capacité et la liberté, proposez une solution qui atteigne l’optimalité dans un contexte où elle peut être exécutée de manière optimale. Comprenez les véritables objectifs des parties prenantes, des sponsors et de l’entreprise, et pas seulement leurs objectifs observés ou déclarés. Dans la mesure où ils sont disposés à écouter, essayez de produire une solution dans cette optique. En tout temps, assurez-vous de travailler avec des humains et non seulement avec le modèle.
Conor Doherty: Merci. Joannes, quelque chose à ajouter à cela ?
Joannes Vermorel: Non, je pense que c’est un bon point. Du point de vue d’un fournisseur de logiciels, je dirais qu’en matière d’optimalité, il ne faut pas trop faire confiance aux software vendors. Oui, évidemment, sauf nous. En particulier, prenez en compte qu’il existe des catégories de logiciels telles que les systems of records et les systems of reports qui ne traitent pas des décisions et ne peuvent donc pas optimiser du tout.
Les systems of records, tels que ERP, CRM, WMS, et les systems of reports, tels que business intelligence, sont fréquemment présentés comme apportant des décisions optimisées. De par leur conception, ces catégories de logiciels ne touchent même pas au problème. Ils n’optimisent pas en premier lieu. Donc, mon message serait : n’essayez pas de trouver votre chemin vers l’optimalité lors de votre prochaine mise à niveau ERP. Par définition, un ERP est un system of records. Il ne traite pas des décisions et se soucie encore moins de savoir si ces décisions peuvent être optimales sous quelque forme que ce soit.
Conor Doherty: Je m’assurerai de placer ce très bel article—enfin, un court article, comme ce que je voulais dire—dans la foulée. Dans celui-ci, vous parlez des systems of record, des systems of report et des systems of intelligence. Mais ici, il est d’usage de donner la parole finale à l’invité. Donc, s’il y a autre chose que vous souhaitez mentionner ou quelque chose que nous n’avons pas dit, vous pouvez conclure sans interruption.
Ian Wright: Ouais, j’aime bien cela. Du point de vue d’un fournisseur de logiciels, ne faites pas confiance aux software vendors. J’apprécie vraiment cette remarque, car depuis plus de 40 ans, l’une des choses qui m’a le plus dérangé, c’est l’ampleur de l’engouement que j’ai pu observer autour de la technologie. L’engouement autour de l’idée de la supply chain, pendant longtemps, à mon sens, est un type d’engouement. Et j’ai d’ailleurs écrit à ce sujet, Conor, ce qui ne te surprendra pas. Mais je pense que ce que nous devons faire, c’est apprendre à vivre dans un monde où l’on sait comment naviguer à travers cet engouement, se frayer un chemin parmi les complexités, et comprendre ce qui fonctionne réellement. C’est la clé—ce qui est réel.
Conor Doherty: Eh bien, sur ce point, je dirai que je n’ai plus de questions. Joannes, merci pour ton temps. Ian, merci beaucoup de nous avoir rejoints.
Ian Wright: Merci, les gars. Ce fut un privilège que vous m’ayez invité, et j’ai vraiment hâte d’en apprendre davantage sur Lokad et de découvrir si je suis fou ou non. C’est la clé.
Joannes Vermorel: Oui, l’une des clés. Nous vous enverrons un diagnostic.
Conor Doherty: Merci, et merci de nous avoir regardés. Nous nous retrouvons la prochaine fois.
