La connaissance négative en Supply Chain - Cours 2.3

00:15 Introduction
02:28 Smart Fridge
05:28 Biais de survie
07:28 L’histoire jusqu’à présent
08:46 Sur les tabous (récapitulatif)
12:06 Heuristiques de rejet (récapitulatif)
13:34 Connaissance positive de faible qualité
15:27 Antipatterns logiciels, 1/2
20:11 Antipatterns logiciels, 2/2
25:34 Antipatterns de la Supply Chain
27:00 Prévisions nues
32:36 Le taux de service à 100%
37:06 L’initiation Jedi
44:31 L’horreur non-euclidienne
51:45 L’avocat du diable
57:35 Récapitulatif, connaissance négative pour la supply chain
01:01:04 Conclusion
01:02:45 Prochain cours et questions de l’audience

Description

Les antipatterns sont les stéréotypes de solutions qui semblent bonnes mais qui ne fonctionnent pas en pratique. L’étude systématique des antipatterns a été pionnière à la fin des années 1990 par le domaine de l’ingénierie logicielle. Lorsqu’ils sont applicables, les antipatterns sont supérieurs aux résultats négatifs bruts, car ils sont plus faciles à mémoriser et à raisonner. La perspective des antipatterns est d’une importance primordiale pour la supply chain et devrait être considérée comme l’un des piliers de sa connaissance négative.

Transcription complète

Bonjour à tous, bienvenue à cette série de cours sur la supply chain. Je suis Joannes Vermorel et aujourd’hui, je vais présenter la connaissance négative en supply chain. Pour ceux d’entre vous qui regardent le cours en direct, vous pouvez poser des questions à tout moment via le chat YouTube. Je ne lirai pas le chat pendant le cours, mais je reviendrai sur le chat à la fin du cours pour la session de questions-réponses.

Aujourd’hui, le sujet d’intérêt est ce qu’une entreprise gagne réellement lorsqu’elle embauche un directeur de la supply chain expérimenté avec peut-être deux ou trois décennies d’expérience. Ce que l’entreprise recherche, et pourrions-nous, dans une certaine mesure, reproduire l’acquisition de cette expérience en beaucoup moins de temps ? C’est exactement ce qu’est la connaissance négative.

Lorsque nous regardons une personne très expérimentée, quelqu’un qui travaille depuis deux décennies dans un domaine, cherchons-nous vraiment à ce que cette personne reproduise des solutions, des processus ou des technologies qu’elle a mises en place il y a un ou deux décennies dans d’autres entreprises ? Probablement pas. Bien que cela puisse arriver marginalement, je soupçonne que c’est généralement une raison très marginale au mieux.

Lorsque vous cherchez une personne très expérimentée, l’objectif n’est pas nécessairement de reproduire les choses telles qu’elles ont été faites dans le passé. La valeur clé que vous voulez acquérir est de prendre quelqu’un qui sait comment éviter toutes sortes d’erreurs et qui a l’expérience pour s’assurer que de nombreuses idées très naïves et mauvaises ne seront pas mises en œuvre dans votre entreprise. Il y a ce dicton selon lequel en théorie, la pratique et la théorie sont les mêmes, mais en pratique, elles ne le sont pas. C’est exactement la clé de la connaissance négative.

Ma proposition pour vous est que de mauvaises idées commerciales sont partout. Lorsque je dis mauvaises, je veux dire des idées qui, si elles étaient mises en œuvre, se révéleraient complètement non rentables pour l’entreprise. Pour illustrer cela, j’ai simplement mis la requête “réfrigérateurs intelligents” dans le moteur de recherche de brevets de Google. Google Patents est un moteur de recherche spécialisé fourni par Google, et vous pouvez rechercher une base de données de brevets. Et voilà, nous obtenons 130 000 résultats de brevets déposés sur les réfrigérateurs intelligents.

Prenez ce nombre avec un grain de sel, car il y a probablement beaucoup de doublons. Cependant, une inspection rapide des résultats indique très clairement que nous avons plusieurs centaines, voire plusieurs milliers d’entreprises qui, au cours des dernières décennies, ont fait des recherches et des développements pour déposer un brevet sur les réfrigérateurs intelligents. Lorsque vous regardez le genre d’idées trouvées dans ces brevets, vous verrez que c’est toujours une combinaison de prendre cet appareil très omniprésent, un réfrigérateur, et d’ajouter quelque chose, comme de l’électronique bon marché. Nous combinons les deux, et voilà, nous avons une solution de quelque sorte.

Pour quel genre de problème, cependant ? C’est très peu clair. Juste pour vous donner l’idée de la plupart des brevets, c’est l’idée où, si vous avez un réfrigérateur qui a des capteurs, le réfrigérateur lui-même va détecter si vous êtes à court de lait et passera automatiquement une commande pour vous. Nous sommes en 2021, et dans la mesure de mes connaissances, les réfrigérateurs intelligents n’existent pas. Ce n’est pas qu’ils ne sont pas techniquement faisables - ils le sont tout à fait. C’est juste qu’il n’y a littéralement aucun marché pour eux. Nous avons donc une quantité massive de solutions sur le marché à la recherche d’un problème. Au cours des deux dernières décennies, je crois avoir vu en moyenne deux fois par an une startup promouvoir un réfrigérateur intelligent de quelque sorte. Assez curieusement, je n’ai jamais eu de nouvelles de l’une de ces startups. Je n’ai pas vraiment suivi, mais je soupçonne fortement que chaque startup que j’ai vue promouvoir un réfrigérateur intelligent au cours des deux dernières décennies a échoué. Cependant, bien que l’idée soit très répandue et populaire, comme le démontrent ces milliers de brevets, les conséquences de ces idées, qui sont mauvaises car la plupart de ces startups ont simplement fait faillite, ne se sont pas propagées.

Ici, nous voyons quelque chose de très intéressant : grâce à l’expérience, vous pouvez accéder à une sorte de connaissance qui n’est pas facilement accessible aux observateurs du marché. Vous pouvez voir le côté sombre, c’est-à-dire les choses qui manquent, le genre de choses qui ont été promises et diffusées mais qui ne se sont pas révélées très réussies.

Il y a un exemple historique très notable de la Seconde Guerre mondiale. L’armée américaine a mené une enquête sur les avions revenant à la base pour collecter l’emplacement des impacts de balles sur l’avion. Ce que vous voyez à l’écran était essentiellement la collecte de l’emplacement des balles tel qu’observé sur les avions revenant des champs de bataille à la base. Initialement, les officiers de l’armée suivaient la ligne de pensée selon laquelle ils devaient ajouter des plaques de blindage dans les zones les plus touchées, les zones qui étaient évidemment sous le feu le plus important pendant la bataille.

Puis, un autre gentleman, Abraham Wald, a dit non, c’est exactement le contraire. Le fait est que ce que vous voyez, ce sont des avions qui ont réussi à revenir à la base. Ce que vous ne voyez pas, c’est que pour toutes les zones où vous ne voyez pas d’impacts de balles, il est très probable que lorsqu’il y avait un impact de balle dans cette zone, cela s’est avéré mortel soit pour l’avion, soit pour l’équipage, voire les deux. Donc, si vous devez ajouter un blindage, vous devez le faire précisément sur toutes les zones où vous ne voyez pas d’avions revenir à la base avec des impacts de balles. Ce sont les zones qui doivent être protégées.

Ce qu’Abraham a souligné, c’est qu’il y avait un phénomène connu sous le nom de biais de survie, où ce que vous observez, ce sont essentiellement les survivants, pas tous les avions qui n’ont pas réussi à revenir à la base. L’idée de la connaissance négative est exactement comme ça : vous prenez cette image photographique et le négatif, et c’est le reste que vous devez vraiment capturer votre attention car c’est là que les choses vraiment mauvaises se produisent. C’est l’essence, je dirais, de la connaissance négative.

Ceci est la quatrième conférence de ma série de conférences, la première conférence du deuxième chapitre. Dans le premier chapitre du prologue, j’ai présenté mes points de vue sur la supply chain, à la fois en tant que domaine d’étude et en tant que pratique. Ce que nous avons vu, c’est que la supply chain est essentiellement une collection de problèmes méchants, par opposition aux problèmes dociles. Les problèmes méchants sont très difficiles à aborder car ils ne se prêtent ni à des études faciles ni à une pratique facile. Il y a fondamentalement quelque chose d’adverse en termes d’étude et de pratique avec les problèmes méchants. C’est pourquoi le deuxième chapitre est consacré aux méthodologies.

Dans cette conférence actuelle, nous adoptons une approche qualitative, tout comme ce que nous avons fait avec la persona de la supply chain, qui était la toute première conférence de ce chapitre. Nous allons développer les sortes d’approches qualitatives que nous pouvons avoir pour apporter des améliorations aux chaînes d’approvisionnement de manière contrôlée, fiable et potentiellement mesurable.

Récapitulons : Bien que cette conférence soit consacrée à la connaissance négative, ce n’est pas la première fois dans cette série de conférences que j’aborde des éléments qui pourraient être qualifiés de bribes de connaissance négative. Lors de la première conférence de ce deuxième chapitre sur les personas de la supply chain, j’ai présenté mes points de vue sur les études de cas. J’ai dit que les études de cas positives, c’est-à-dire les études de cas présentant des résultats positifs associés à une solution d’intérêt, sont accompagnées de conflits d’intérêts massifs qui sapent essentiellement toute confiance que nous pourrions avoir dans la validité des résultats. D’autre part, j’ai déclaré que les études de cas négatives sont tout à fait acceptables car ces conflits d’intérêts, bien qu’ils puissent être présents, sont beaucoup moins intenses.

Dans cette conférence sur les personas de la supply chain, j’ai présenté une fantastique étude de cas négative, “Les derniers jours de Target Canada” de Joe Castaldo, qui détaillait un échec de la chaîne d’approvisionnement à grande échelle qui a finalement conduit à la faillite de Target Canada. C’est une sorte de connaissance négative, où l’objet d’étude est littéralement des choses qui n’ont pas fonctionné, par opposition à ce que nous pouvons faire pour avoir quelque chose qui fonctionne réellement.

Maintenant, pourrions-nous utiliser des études de cas négatives comme pratique fondamentale pour notre connaissance négative de la supply chain ? Je dirais surtout non, pour deux raisons très distinctes. La première raison est simplement que les études de cas négatives sont extrêmement rares. Je supposerais, juste comme une estimation, qu’il y a en fait plus de 100 fois plus de brevets sur les réfrigérateurs intelligents, qui sont complètement inutiles, que d’études de cas négatives sur les chaînes d’approvisionnement. Nous avons donc un problème très pratique : bien que ces études de cas négatives soient d’une grande pertinence et d’un très grand intérêt scientifique, elles se trouvent être extrêmement rares. Nous en avons si peu qu’il est très difficile d’avoir ce matériel comme fondement de notre connaissance négative pour la supply chain.

Le deuxième problème est l’intelligibilité. Ces études de cas négatives, comme le fantastique article “Les derniers jours de Target Canada”, montrent qu’il y a des dizaines de problèmes qui se produisent en même temps, et tous ces problèmes sont complètement entremêlés pour finalement conduire à un échec épique. Le problème est que ces études de cas sont littéralement la vie réelle en action, et que ces événements sont très complexes. Il est difficile de communiquer et de raisonner sur ces études de cas car les détails comptent, et ils sont très denses. Il y a un problème plus banal : comment le communiquer à un public plus large ?

Dans ma dernière conférence sur l’optimisation expérimentale, nous avons également vu un autre type de connaissance négative : les heuristiques de rejet. Il s’agit essentiellement de simples astuces qui peuvent être utilisées lorsqu’une proposition en termes de solution quantitative est avancée comme candidat potentiel pour l’amélioration de votre chaîne d’approvisionnement. Vous pouvez utiliser une série d’heuristiques ou de règles simples pour écarter les solutions qui, avec un très haut degré de certitude, ne fonctionneront tout simplement pas. Cependant, nous avons ici un problème d’évolutivité. Ces heuristiques ne fonctionnent que parce qu’elles sont obscures. Si elles devenaient bien connues dans les cercles de la chaîne d’approvisionnement, à la fois les articles scientifiques et les logiciels de chaîne d’approvisionnement s’adapteraient et changeraient leur discours, rendant la situation plus confuse. Ces heuristiques sont très efficaces, mais si elles devenaient populaires, elles conserveraient toujours leur validité, mais perdraient leur efficacité en tant que filtres, simplement parce que les gens feraient attention à contourner ces heuristiques.

C’est pourquoi ces heuristiques, bien qu’elles soient très intéressantes, ne peuvent pas être utilisées comme fondements pour notre connaissance négative que nous voulons constituer pour la chaîne d’approvisionnement.

Aussi, nous ne devrions pas confondre la connaissance négative avec une connaissance positive de faible qualité. La différence est vraiment une question d’intention. Par exemple, l’intention des stocks de sécurité est de donner aux entreprises un moyen contrôlé de conduire la qualité de service qu’elles obtiendront. L’intention est positive ; c’est une solution pour quelque chose qui devrait fonctionner. Maintenant, la réalité est que le modèle de stock de sécurité est basé sur des hypothèses complètement abusives : la demande future et les délais de livraison sont supposés être normalement distribués, bien que ces hypothèses soient factuellement fausses. Je n’ai jamais observé de jeux de données de chaîne d’approvisionnement où la demande ou les délais de livraison étaient normalement distribués. Les distributions d’intérêt sont en fait distribuées selon la loi de Zipf, comme je l’ai abordé dans mes conférences précédentes sur les principes quantitatifs pour la chaîne d’approvisionnement. D’un point de vue approprié, le stock de sécurité est falsifié, mais néanmoins, le stock de sécurité est définitivement ancré dans le domaine de la connaissance positive, bien qu’il puisse être considéré comme une connaissance positive de très faible qualité.

Au cours de cette conférence, nous n’aurons pas le temps d’approfondir tous les éléments qui, de mon point de vue, se qualifient comme une connaissance positive de très faible qualité, mais je serais heureux de répondre si certaines personnes veulent me poser des questions sur l’un de ces éléments lors de la session de questions-réponses.

En ce qui concerne la connaissance négative réelle d’intérêt pratique, il existe un livre intitulé “Anti-Patterns: Refactoring Software, Architectures, and Projects in Crisis” qui est un jalon dans l’histoire de l’ingénierie logicielle. Publié en 1998, ce livre commence par une observation occasionnelle selon laquelle, dans l’industrie du logiciel, lorsque des bonnes idées et des projets tirent parti de ces bonnes idées, les fournisseurs de logiciels voient les bonnes idées être consommées par le succès du projet. Les auteurs se demandent si une bonne idée reste une bonne pratique après la mise en œuvre du produit, et la réponse est essentiellement non. Il y a un avantage du premier arrivé qui est très spécifique à l’industrie du logiciel, et par conséquent, nous avons un problème. À peu près n’importe quel ensemble de règles que vous utiliseriez pour prédire le succès de quoi que ce soit dans l’industrie du logiciel est auto-destructeur, en raison du fait que les meilleures approches ont tendance à être consommées par le succès qu’elles génèrent. Les auteurs d’“Anti-Patterns” ont remarqué qu’il est presque impossible, selon eux, de garantir le succès d’une initiative logicielle. Cependant, ils ont également remarqué que la situation est très asymétrique en ce qui concerne les échecs. Ils ont remarqué qu’il est possible de prédire, avec un très haut degré de confiance (parfois proche de la certitude), qu’un projet donné est sur le point d’échouer. C’est très intéressant car vous ne pouvez pas garantir le succès, mais vous pouvez avoir quelque chose comme une science qui garantit l’échec. Mieux encore, cette connaissance des éléments qui garantissent l’échec semble être extrêmement stable dans le temps et très indépendante des aspects techniques de l’entreprise ou de la verticalité considérée.

Si nous revenons à l’idée initiale de réfrigérateur intelligent, nous pouvons voir que tous ces brevets de réfrigérateur intelligent sont incroyablement divers dans les solutions qu’ils présentent. Mais il s’avère que tous ces brevets de réfrigérateur intelligent conduisent à des échecs commerciaux car ils tombent tous sous le même parapluie : une solution cherchant un problème. La combinaison d’un appareil omniprésent avec de l’électronique bon marché crée une solution, mais est-ce quelque chose qui a réellement du sens ? Dans ce cas, presque jamais.

Les auteurs d’“Anti-Patterns” ont commencé leur voyage en étudiant les causes profondes des échecs logiciels et ont identifié les sept péchés capitaux de l’ingénierie logicielle, qui sont la hâte, l’apathie, l’étroitesse d’esprit, l’avarice, l’ignorance, l’orgueil et l’envie. Ces problèmes vont être indépendants du contexte et des technologies impliquées car ce sont des invariants de la nature humaine elle-même. Lorsque vous cherchez un directeur de la chaîne d’approvisionnement avec deux décennies d’expérience, vous cherchez quelqu’un qui a simplement vécu plus longtemps et qui a intériorisé la plupart des problèmes qui surviennent lorsque des êtres humains réels sont impliqués, avec toutes sortes de défauts.

L’idée des auteurs est qu’il est bon de formaliser cette connaissance pour la rendre plus digeste et intelligible afin qu’il soit plus facile de communiquer et de raisonner sur ces problèmes. C’est l’essence des anti-patterns - un format pour capturer des bribes de connaissance négative.

Dans leur livre, les auteurs présentent un modèle pour un anti-pattern, qui commence par un nom accrocheur facile à mémoriser. Vous devez caractériser l’échelle, qu’il s’agisse du niveau du code source, du niveau de l’architecture logicielle, du niveau de l’entreprise ou du niveau de l’industrie. Vous voulez identifier les causes profondes réelles et les conséquences qui y sont généralement associées. Vous voulez caractériser les forces en jeu, les symptômes et les conséquences involontaires que les gens n’attendent pas, qui vont complètement miner les avantages attendus de la solution initiale.

Les auteurs soutiennent que vous devez présenter des preuves anecdotiques, et c’est pourquoi ils utilisent des entreprises fictives dans leurs anti-patterns. Cela est fait pour éviter les tabous liés à la discussion de vraies entreprises et de vraies personnes, ce qui pourrait empêcher l’établissement d’une communication honnête. Le modèle anti-pattern doit se conclure par une solution refactorisée, qui est un chemin pour transformer ce qui est essentiellement une solution mal orientée en une variante de cette solution qui fonctionne réellement dans le monde réel, où les conséquences involontaires sont atténuées et idéalement éliminées.

Cette conférence ne concerne pas les anti-patterns de la chaîne d’approvisionnement, mais juste pour donner deux exemples d’anti-patterns logiciels que vous avez peut-être entendus, le premier est le Marteau d’Or. Le Marteau d’Or est l’idée que lorsque vous avez un marteau d’or dans votre main, tout le reste est un clou. Cet anti-pattern déclare essentiellement que si vous demandez à un programmeur Java comment il aborderait un nouveau problème, il suggérera probablement d’écrire un programme en Java pour résoudre ce problème. Si vous présentez un autre problème à cette même personne, cette même personne dirait que cet autre problème pourrait également être résolu avec un programme Java. Si vous présentez 20 problèmes différents, à chaque fois la réponse sera : “Je crois qu’un programme Java ferait très bien l’affaire.” C’est un énorme biais où les personnes ayant de l’expérience dans une technologie donnée ont tendance à recycler leurs connaissances techniques pour résoudre de nouveaux problèmes, au lieu de prendre le temps d’évaluer si leurs connaissances sont vraiment pertinentes techniquement pour aborder le nouveau problème. Il est beaucoup plus facile intellectuellement de se contenter de ce que vous connaissez réellement.

Un autre est l’Analyse Paralysante. Dans le monde du logiciel, il y a de nombreuses situations où les possibilités sont infinies, et il est tentant de dire : “Au lieu de tester 20 approches différentes qui vont échouer, réfléchissons très fort à la conception, et une fois que nous sommes absolument certains que nous avons la bonne solution en tête, alors nous déploierons la mise en œuvre.” Malheureusement, cela est très difficile à exécuter, et conduit généralement à une analyse paralysante, où plus de temps et d’efforts sont consacrés à considérer des tonnes d’options potentielles au lieu d’essayer simplement une solution et de voir si elle fonctionne ou non.

Maintenant, évidemment, nous avons discuté que ce livre était sur les anti-patterns logiciels, et je crois que l’ingénierie logicielle a de nombreuses similitudes avec les problèmes auxquels nous sommes confrontés dans la chaîne d’approvisionnement, en particulier l’optimisation de la chaîne d’approvisionnement. Les deux domaines sont essentiellement des collections de problèmes complexes, et la chaîne d’approvisionnement moderne est très axée sur la livraison d’un produit logiciel. Il y a donc un certain degré de chevauchement entre les problèmes de la chaîne d’approvisionnement et les problèmes d’ingénierie logicielle, mais ces deux domaines ne sont pas complètement à des années-lumière l’un de l’autre.

Ici, je présenterai cinq anti-patterns de la chaîne d’approvisionnement, qui peuvent être trouvés sous forme écrite sur le site web de Lokad, avec une présentation plus détaillée disponible pour ceux qui sont intéressés.

Le premier est le “Naked Forecast”. Inspiré de la nouvelle “Les Habits neufs de l’empereur” de Hans Christian Andersen, le contexte est une entreprise avec une initiative en cours pour améliorer la précision des prévisions. Certains symptômes comprennent des prévisions de longue date que tout le monde critique - production, marketing, ventes, achats et même chaîne d’approvisionnement, la division de prévision étant généralement partie intégrante de la chaîne d’approvisionnement. Des tentatives ont été faites pour améliorer la précision de la prévision au cours des dernières décennies, mais il semble que quel que soit l’effort déployé, il y a une série interminable d’excuses de la part des personnes responsables de la prévision pour justifier sa mauvaise précision.

Le problème est qu’il y a cette prochaine initiative où l’intention est de rendre la précision de la prévision droite, de résoudre ce problème de prévision inexacte une fois pour toutes. C’est l’anti-pattern “Naked Forecast” en jeu. Les conséquences involontaires de cela sont, premièrement, cela ne va pas fournir des prévisions significativement plus précises. Deuxièmement, passer par une autre initiative ne fera que créer une organisation encore plus byzantine où ce qui a commencé comme une petite pratique pour fournir la prévision devient de plus en plus complexe, avec plus de personnes impliquées dans la production de ces prévisions. À long terme, vous vous retrouvez avec quelque chose qui est toujours aussi inexact mais qui est passé d’une chose modeste et inexacte à une grande bureaucratie qui est toujours aussi inexacte qu’avant.

Je crois que la cause profonde ici est ce que j’appelle le rationalisme naïf ou l’illusion de la science. Lorsque cette initiative commence, le problème se présente comme s’il était parfaitement objectif : “Nous allons produire des prévisions plus précises selon une métrique, disons l’erreur absolue moyenne.” Le tout semble très simple, avec un problème bien défini. Cependant, le problème est que tout cela est très naïf car il n’y a pas de corrélation directe entre la précision de la prévision et la rentabilité de l’entreprise. Ce que vous devriez chercher, ce sont des moyens d’améliorer la rentabilité de l’entreprise, donc vous devriez penser en termes de dollars ou d’euros d’erreur, pas en pourcentage d’erreur.

Fondamentalement, la cause profonde est que ces prévisions sont autonomes et ne reçoivent aucun retour d’information de l’entreprise réelle. La précision de la prévision n’est qu’un artefact numérique ; ce n’est pas un retour sur investissement réel et tangible pour l’entreprise. Comme anecdote, si j’avais reçu un chèque de mille dollars à chaque fois que j’avais eu une discussion au téléphone avec un directeur de la chaîne d’approvisionnement qui m’avait dit qu’il commençait une nouvelle initiative pour améliorer la précision de la prévision, je serais encore plus riche.

En fin de compte, en termes de solution refactorisée, tant que les prévisions sont nues, cela ne fonctionnera pas. Vous devez les habiller, et ces vêtements sont des décisions. Comme nous l’avons exploré dans la conférence précédente avec l’optimisation expérimentale, si les prévisions ne sont pas directement connectées à des décisions tangibles de la vie réelle, telles que la quantité à acheter, la quantité à produire ou la décision de faire varier les prix à la hausse ou à la baisse, vous n’obtenez jamais le retour d’information réel qui compte. Le retour d’information réel qui compte n’est pas le KPI de test en arrière-plan sur la mesure ; ce qui compte, ce sont ces décisions. Ainsi, en termes de solution refactorisée pour résoudre le problème anti-pattern Naked Forecast, c’est essentiellement de décider que les mêmes personnes qui génèrent la prévision doivent vivre avec les conséquences de ces prévisions lorsqu’il s’agit des décisions de la chaîne d’approvisionnement réelle qui sont mises en œuvre par-dessus.

Le deuxième serait le mythe du taux de service de 100 %. La situation commence généralement comme suit : le conseil d’administration se réunit et, quelque part dans la presse ou sur les réseaux sociaux, certaines personnes se plaignent bruyamment de la qualité du service. Cela ne donne pas une bonne image de l’entreprise, car il semble que l’entreprise ne tient pas ses promesses. Le conseil exerce une énorme pression sur le PDG pour qu’il fasse quelque chose à propos de ce problème de qualité de service, qui a un impact négatif sur la marque, l’image et potentiellement la croissance de l’entreprise. Le PDG dit : “Nous devons vraiment mettre fin à ces interminables problèmes de qualité de service.” Ainsi, le PDG se tourne vers le vice-président de la chaîne d’approvisionnement et lui demande de mettre fin à ces problèmes de qualité de service. Le vice-président de la chaîne d’approvisionnement, à son tour, demande au directeur de la chaîne d’approvisionnement de faire de même, et le directeur de la chaîne d’approvisionnement demande au responsable de la chaîne d’approvisionnement de résoudre le problème. Le responsable de la chaîne d’approvisionnement augmente alors le taux de service à quelque chose de très élevé, proche de 100 %.

Et voilà, même si à court terme vous obtenez des niveaux de service légèrement plus élevés, très bientôt les problèmes de qualité de service reviennent. Ces niveaux de service plus élevés ne sont pas durables, et vous vous retrouvez avec des fluctuations de stocks, des stocks gaspillés, et bien que l’intention était d’augmenter le taux de service, vous obtenez fréquemment des taux de service plus bas six ou douze mois plus tard.

La cause profonde ici n’est pas seulement l’ignorance, mais aussi le souhait de penser. Mathématiquement parlant, si vous voulez un taux de service de 100 %, cela signifie une quantité infinie de stocks, ce qui n’est techniquement pas possible. Vous avez cette puissante pensée magique selon laquelle vous pouvez résoudre complètement ce problème, bien que ce ne soit pas possible. Au mieux, vous pouvez atténuer les problèmes de qualité de service ; vous ne pouvez jamais les éliminer complètement.

En termes de preuve anecdotique, j’ai constaté que de nombreuses entreprises ont le plus de difficultés parce qu’elles ont cette mentalité du taux de service mythique de 100 %. Si votre entreprise n’est pas prête à accepter que, pour certains produits (pas tous ou les plus importants), les taux de service seront effectivement réduits délibérément, alors vous vous dirigez vers de graves problèmes. Le seul moyen d’améliorer réellement la qualité de service est d’abord d’accepter que si l’accent est mis sur tout, cela revient à dire que l’accent est mis sur rien. Tant que vous n’êtes pas prêt à accepter que, pour certains SKUs, vous aurez un taux de service inférieur délibérément comme résultat acceptable, vous ne pourrez pas améliorer votre qualité de service globale.

En termes de solutions refactorisées, la solution de refactoring est les drivers économiques. C’est un point que j’ai présenté dans la deuxième conférence du tout premier chapitre, la vision de la supply chain quantitative. Les drivers économiques montrent que vous avez le coût des ruptures de stock et le coût de possession, et qu’il y a un équilibre à trouver. Vous ne pouvez pas simplement pousser pour un taux de service de 100 % car c’est complètement déséquilibré d’un point de vue économique ; ce n’est pas durable. Essayer de pousser dans cette direction est très malavisé car cela ne fera que nuire à l’entreprise. La solution est d’injecter une dose saine de drivers économiques dans votre pratique de la supply chain.

Maintenant, le troisième anti-pattern, l’Initiation Jedi, peut être observé lorsque la direction des grandes entreprises est sous pression constante des médias en raison du flux constant de buzzwords qui leur parviennent. Ces buzzwords incluent l’intelligence artificielle, la blockchain, le cloud computing, le big data, l’IoT, etc. Les influenceurs leur disent que si leur entreprise ne s’adapte pas à ces tendances, elle deviendra obsolète. Il y a une peur constante de manquer quelque chose, qui agit comme une force puissante, exerçant une pression constante sur la direction de la plupart des grandes entreprises qui opèrent de grandes chaînes d’approvisionnement.

Les symptômes de l’Initiation Jedi peuvent être observés si votre entreprise a une division avec des ingénieurs jeunes et enthousiastes qui ont des buzzwords dans leurs titres de poste, tels que des chercheurs en intelligence artificielle, des ingénieurs blockchain ou des data scientists. La devise est de “maîtriser la force”, la force étant le buzzword d’intérêt à ce moment-là. La direction prend des personnes jeunes ou inexpérimentées et leur demande de faire quelque chose de grand pour l’entreprise, mais sans être impliquée ou familière avec les aspects techniques de ces concepts.

Ce qui se passe, c’est que ces équipes créent des prototypes intéressants qui finissent par ne pas fournir de valeur réelle dans le monde réel pour l’entreprise. En conséquence, bien que cela ait commencé avec l’idée que l’entreprise serait révolutionnée selon le buzzword du jour, les pratiques et technologies héritées restent prédominantes, non modifiées par le buzzword ou l’équipe supplémentaire construite autour de celui-ci.

En termes de preuve anecdotique, de nos jours, en 2021, la grande majorité des entreprises ayant une équipe de data science n’obtiennent exactement aucun retour sur leur investissement. L’équipe de data science crée des prototypes Python fantaisistes à l’aide de bibliothèques open-source très cool, mais en termes de retour sur investissement pratique pour la grande majorité du marché, c’est exactement zéro. C’est exactement le genre d’Initiation Jedi dans lequel la direction tombe : elle lit dans la presse que la data science est la nouvelle tendance, alors elle embauche une équipe de data science. Comme anecdote, je constate que ces équipes sont non seulement assez jeunes et inexpérimentées, mais elles le restent également au fil du temps. C’est parce que le taux de rotation est très élevé. Vous pouvez avoir une entreprise très solide et robuste, où le taux de rotation moyen est généralement de cinq à dix ans, sauf pour l’équipe de data science, où les gens restent en moyenne 18 mois. L’une des raisons pour lesquelles rien de valeur ne sort de ces équipes est que les gens entrent, font quelques prototypes, puis partent. Pour l’entreprise, il n’y a pas de capitalisation, et elle ne parvient jamais vraiment à transformer l’entreprise.

En ce qui concerne la refonte de cette solution, tout d’abord, il n’y a pas d’autre choix que de montrer l’exemple. Si vous voulez réellement faire de la science des données, la direction doit être très compétente en matière de science des données. Par exemple, Jeff Bezos a montré sa familiarité avec les techniques de pointe d’apprentissage automatique de son époque. Amazon peut être très performant en matière d’apprentissage automatique, mais cela se produit parce que la direction est très familière avec les détails. Montrer l’exemple est essentiel.

Deuxièmement, vous devez vous assurer que lorsque vous embauchez ces jeunes ingénieurs enthousiastes et potentiellement talentueux, vous les confrontez à de vrais problèmes, pas à des problèmes métaphysiques. Il doit être connecté à la réalité. Cela renvoie à ma précédente conférence sur l’optimisation empirique et expérimentale. Si vous embauchez un scientifique des données pour effectuer une segmentation de la clientèle ou une meilleure analyse ABC pour votre entreprise, ce ne sont pas de vrais problèmes. Ce ne sont que des chiffres inventés. Si vous embauchez ces personnes et les mettez à la charge du réapprovisionnement réel, et les rendez responsables des quantités exactes à réapprovisionner auprès d’une série de fournisseurs, c’est très réel. C’est la raison pour laquelle, il y a une décennie, Lokad est passé en interne de scientifiques des données à des scientifiques de la chaîne d’approvisionnement. Le but était d’avoir un engagement complètement différent et de se débarrasser de ce modèle anti-pattern Jedi Initiation.

L’horreur non-euclidienne. Dans ce contexte, vous avez une entreprise qui exploite une grande chaîne d’approvisionnement, et le paysage informatique est très complexe. Il existe plusieurs logiciels d’entreprise, tels que ERP, WMS et EDI, qui sont complexes en eux-mêmes. Ensuite, vous avez toute la colle qui relie ces choses ensemble, et l’ensemble est incroyablement complexe. Alors, comment savez-vous que vous êtes réellement dans une entreprise qui fait face à une solution non-acclimatée? Quels sont les symptômes? Les symptômes sont que tout le monde dans l’entreprise a l’impression qu’il y a une incompétence rampante dans la division informatique. Les gens de l’informatique semblent dépassés et semblent ne pas comprendre ce qui se passe dans le système qu’ils sont censés gérer et exécuter. Un autre symptôme est que vous voyez des problèmes informatiques qui ont un impact sur la production quotidiennement. Ce sont les symptômes clés de la solution non-acclimatée.

La conséquence d’avoir un paysage informatique non-acclimaté est que les changements qui doivent être apportés à l’entreprise, et généralement, lorsqu’il y a un changement à apporter à l’entreprise, il y a également un changement à apporter aux systèmes informatiques. Les chaînes d’approvisionnement modernes sont très axées sur leurs composants logiciels. Tous ces changements se produisent très lentement, et c’est toujours un processus fastidieux où même de petits changements prennent une éternité. Chaque fois qu’il y a un certain degré de changement, il y a généralement des tonnes de régressions. Comme on dit, vous faites deux pas en avant et trois pas en arrière, puis deux pas en avant et un pas en arrière. Le changement est non seulement lent mais aussi accompagné d’un flux constant de régression. La situation ne s’améliore pas vraiment avec le temps; au mieux, elle stagne.

En termes de causes profondes, la direction ne se soucie pas vraiment des détails, et la direction non-informatique ne se soucie pas vraiment de tous ces systèmes informatiques. Cela donne lieu à une approche que j’appelle l’incrémentalisme, où tout changement qu’ils veulent apporter au système informatique de l’entreprise sera demandé par les chaînes d’approvisionnement, par exemple. Chaque fois qu’il y a un changement qui doit se produire, la direction dira toujours: “Veuillez prendre le chemin le plus facile, le chemin qui nécessite le moins d’efforts et de temps afin que nous puissions voir cela mis en œuvre le plus rapidement possible.” C’est de cela qu’il s’agit l’incrémentalisme.

Je crois que l’incrémentalisme est une cause profonde très dangereuse. Le problème avec l’incrémentalisme, c’est que c’est littéralement une mort par mille coupures. Chaque changement qui est apporté au système le rend un peu plus complexe, un peu plus difficile à gérer et un peu plus difficile à tester. Bien que chaque changement individuellement soit insignifiant, lorsque vous accumulez une décennie de dizaines de changements apportés aux systèmes informatiques quotidiennement, vous vous retrouvez avec un océan de complexité. Chaque changement a rendu le système plus complexe et l’image d’ensemble est complètement perdue. Avance rapide d’une décennie et vous vous retrouvez avec un système massif et compliqué qui semble insensé.

À titre d’anecdote, vous pouvez constater qu’il existe encore de très grandes entreprises de commerce électronique où, en tant que consommateur, vous pouvez régulièrement constater qu’elles ont des temps d’arrêt. Ces sortes de choses ne devraient jamais arriver. En tant qu’entreprise de commerce électronique en 2021, votre temps de disponibilité devrait être quelque chose comme permettant 10 minutes d’arrêt par an. Chaque seconde d’arrêt est une opportunité gaspillée. Concevoir un logiciel de panier d’achat en 2021 n’est plus de la science-fiction; c’est en fait un logiciel très banal en ce qui concerne les logiciels d’entreprise. Il n’y a aucune raison de ne pas avoir quelque chose qui est toujours en marche. Cependant, la réalité est que lorsque vous voyez le commerce électronique tomber en panne, ce n’est généralement pas le panier d’achat qui échoue; c’est une solution non-acclimatée qui se trouve juste derrière le commerce électronique. Le commerce électronique en panne n’est qu’un reflet d’un problème qui s’est produit quelque part dans le paysage informatique.

Si nous voulons refondre la solution non-acclimatée, nous devons cesser de chercher la solution la plus facile pour apporter des changements. Nous devons penser non pas à une solution facile, mais à une solution simple. Une solution simple diffère de la solution facile d’une manière cruciale: elle rend l’ensemble du paysage un peu plus ordonné et plus sain, ce qui facilite l’apport de changements ultérieurs. Vous pourriez dire: “Mais c’est juste une question purement technique, donc c’est le travail de l’informatique.” Je dirais que non, absolument pas. C’est très largement un problème de chaîne d’approvisionnement. Adopter une solution simple ne consiste pas à avoir une solution simple d’un point de vue informatique; c’est avoir une solution simple d’un point de vue de la chaîne d’approvisionnement.

La simplicité de la solution, et sa conséquence intentionnelle de rendre les changements ultérieurs plus faciles à mettre en œuvre, dépend de votre feuille de route. Quels types de changements futurs voulez-vous apporter à votre paysage informatique? L’informatique, en tant que division, n’a pas le temps d’être des experts en chaîne d’approvisionnement et de savoir exactement où vous voulez diriger l’entreprise dans une décennie en termes d’exécution de la chaîne d’approvisionnement. C’est la gestion de la chaîne d’approvisionnement qui doit avoir cette vision et doit diriger le développement, potentiellement avec le soutien de l’informatique, dans une direction où les changements deviennent de plus en plus faciles à mettre en œuvre au fil du temps.

Enfin, le dernier anti-pattern pour aujourd’hui, l’avocat du diable. Le contexte est généralement une grande entreprise qui a connu d’importants problèmes de chaîne d’approvisionnement et a décidé de faire appel à un grand fournisseur, en mettant beaucoup d’argent sur la table. L’initiative est lancée, et quelques mois plus tard, généralement six mois environ, le fournisseur a très peu à montrer. Beaucoup d’argent a été versé au fournisseur, et il y a très peu à montrer. Au fait, en 2021, six mois, c’est beaucoup de temps. Si vous avez une initiative logicielle qui ne fournit pas de résultats tangibles et de qualité de production en six mois, vous devriez être très inquiet car, selon mon expérience, si vous ne pouvez pas fournir de résultats tangibles en six mois, il y a de fortes chances que l’initiative soit vouée à l’échec et que vous n’ayez jamais un retour sur investissement positif pour l’entreprise.

Ce qui se passe, c’est que la direction voit le projet prendre du retard, et il y a très peu à montrer. La direction, au lieu de devenir de plus en plus agressive à l’égard du fournisseur de technologie et d’être à l’avant-garde du fournisseur de technologie, change soudainement de camp et devient très défensive du fournisseur. C’est très déconcertant. Vous lancez une grande initiative, donnez beaucoup d’argent à une autre entreprise, et l’initiative avance mais mal et a peu à montrer. Au lieu de clarifier que l’initiative est en train d’échouer, la direction double la mise et commence à défendre le fournisseur, ce qui est très étrange. C’est comme s’il y avait une sorte de syndrome de Stockholm en jeu, où quelqu’un vous fait du mal, mais si cette personne vous fait suffisamment de mal, à un moment donné, vous commencez à aimer ces gens.

La direction et l’initiative elle-même deviennent trop grandes pour échouer, et par conséquent, il y a des tonnes d’argent gaspillé et une énorme quantité d’opportunités perdues, surtout en termes de temps. Au fur et à mesure que l’initiative avance, de l’argent est perdu, mais plus important encore, du temps est perdu - six mois, un an, deux ans. Le coût réel est le temps. À titre d’exemple anecdotique de ce genre de chose, on peut lire très régulièrement dans la presse qu’il y a des échecs à grande échelle dans la mise en œuvre des ERP pour des projets qui durent presque une décennie ou parfois cinq à dix ans. Vous pensez, comment pouvez-vous avoir un projet de cinq ans? La réponse est que les gens continuent de doubler la mise sur ce projet, et il faut littéralement des années et des années pour finalement admettre que c’était un échec complet et que cela ne fonctionnerait jamais.

Une autre anecdote est que, ayant été témoin de mises en œuvre d’ERP à grande échelle et de plusieurs années qui ont échoué, il arrive fréquemment que le projet cesse non pas parce que les gens conviennent que le fournisseur a réellement échoué. La façon dont cela se joue est qu’à un moment donné, la direction supérieure impliquée dans la décision de faire appel au fournisseur en premier lieu passe simplement à d’autres entreprises. Lorsque pratiquement toutes les personnes qui faisaient initialement partie de la décision d’amener le grand fournisseur ont quitté l’entreprise, les autres personnes qui ne se sentent pas aussi engagées envers ce fournisseur particulier conviennent simplement de l’arrêter et d’appeler cela une journée.

En ce qui concerne une solution refactorisée, je crois que les entreprises doivent être plus tolérantes envers l’échec. Vous devez être dur envers les problèmes mais doux envers les gens. Si vous cultivez une culture où vous dites des choses comme “Nous devons le faire correctement la première fois”, cela est très nuisible car cela signifie que vous n’aurez pas moins d’échecs. C’est une incompréhension de l’esprit humain et de la nature humaine de penser que si vous avez une culture qui tolère l’échec, vous obtenez en réalité plus d’échecs. Oui, vous obtenez marginalement plus de petits échecs, mais ce que vous obtenez, ce sont des personnes enclines à reconnaître les erreurs et à avancer. Si, au contraire, vous avez une culture de “le faire correctement la première fois”, alors fondamentalement, personne ne peut perdre la face. Donc, même lorsqu’il y a quelque chose de complètement dysfonctionnel, l’instinct de survie des personnes impliquées consiste à s’engager encore plus dans cette chose qui ne fonctionne pas simplement pour préserver leur visage et éventuellement passer à une autre entreprise afin de ne pas avoir à affronter les conséquences de leurs erreurs.

Pour récapituler, nous avons la connaissance positive par rapport à la connaissance négative. La connaissance positive consiste essentiellement à résoudre des problèmes ; c’est une sorte d’intelligence de doctorat, une intelligence de résolution de problèmes où nous avons des énigmes et pouvons progresser d’une solution à une meilleure solution. Il est possible d’évaluer qu’une solution est meilleure que l’autre, et le summum de ce type de réflexion est d’atteindre une solution optimale. Cependant, ce que les gens pensent chercher - des solutions optimales parfaitement valides et immortelles - ce qu’ils obtiennent ce sont des solutions très éphémères.

Par exemple, tout au long de la vie de Lokad, ma société, nous avons traversé six générations de moteurs de prévision. La connaissance positive est éphémère dans le sens où cette connaissance, cette solution, est en danger lorsque quelque chose de mieux arrive, et vous jetterez simplement cette connaissance. Chez Lokad, nous avons traversé l’exercice fastidieux de réécrire notre propre technologie de prévision à partir de zéro six fois depuis le tout début en 2008. C’est pourquoi je dis que la connaissance positive est très éphémère car elle devient obsolète rapidement lorsque de nouvelles solutions meilleures arrivent.

Au contraire, si vous regardez la connaissance négative, c’est une perspective complètement différente. Vous pensez en termes d’erreurs graves, et le genre d’intelligence que vous voulez capturer est l’intelligence de la rue, celle qui vous aide à survivre dans une mauvaise rue la nuit. L’accent n’est pas tellement mis sur les énigmes ou les choses très compliquées à comprendre et qui impliquent un transfert ; il s’agit plutôt de ce que vous ne savez pas ou des tabous. Ce n’est pas ce que vous ne savez pas ; c’est ce que les gens ne vous diront pas, ou le genre de choses où les gens vous mentiront même simplement parce qu’ils veulent sauver la face. La connaissance négative consiste à lutter contre tous ces tabous qui vous empêchent de voir la réalité telle qu’elle est.

Avec la connaissance négative, la mentalité n’est pas celle du progrès ; c’est une mentalité de survie. Vous voulez juste survivre pour pouvoir vous battre un autre jour. C’est une perspective très différente, et c’est exactement le genre de chose que les entreprises cherchent instinctivement lorsqu’elles recherchent un directeur de la chaîne d’approvisionnement très expérimenté. Ils veulent s’assurer qu’à travers cette personne, l’entreprise vivra un autre jour. Ce qui peut être surprenant, c’est que la connaissance négative tend à être beaucoup plus durable. Ce sont à peu près les défauts de la nature humaine qui sont impliqués, et ils ne changent pas avec le temps simplement parce qu’il y a une nouvelle technologie, une nouvelle approche ou une nouvelle méthode. Ces choses sont là pour rester.

En conclusion, je dirais que la connaissance négative est d’une importance primordiale pour tous les problèmes complexes, la chaîne d’approvisionnement étant simplement le centre d’intérêt de cette conférence, mais ce n’est pas le seul domaine où la connaissance négative peut être appliquée.

Les anti-patterns de la chaîne d’approvisionnement ne sont que quelques exemples, mais je suis sûr que des dizaines d’autres pourraient être identifiés pour capturer les problèmes qui continuent de se produire dans les chaînes d’approvisionnement du monde réel. Nous ne pouvons pas espérer tout capturer à travers les anti-patterns, mais je crois que nous pouvons en capturer une bonne partie. Après avoir lu un livre sur les anti-patterns logiciels, mon opinion subjective était que j’avais acquis l’équivalent de cinq ans d’expérience en génie logiciel en seulement 200 pages. Mon espoir est que pour une collection d’anti-patterns de la chaîne d’approvisionnement, nous pourrions également reproduire cet effet, où quelqu’un pourrait acquérir quelque chose comme cinq ans d’expérience en beaucoup moins de temps, peut-être seulement quelques semaines.

C’est tout pour cette conférence. La prochaine conférence portera sur l’évaluation des fournisseurs, qui est un problème très intéressant. Les chaînes d’approvisionnement modernes vivent ou meurent par les produits logiciels qui les soutiennent, et la question est de savoir comment nous raisonnons sur ces produits logiciels et comment nous choisissons les bons et les bons fournisseurs. Malgré mes nombreux conflits d’intérêts, c’est un problème intéressant, et la question est de savoir comment nous pouvons avoir une méthodologie où même si toutes les personnes ont des biais, nous pouvons obtenir des résultats impartiaux à partir de la méthode.

Maintenant, je vais répondre aux questions.

Question : Qu’est-ce qui constitue une bonne prévision dans un cadre d’optimisation probabiliste, et comment mesurer la qualité ? Y a-t-il un rôle pour les enrichissements manuels ?

Une bonne prévision probabiliste a des métriques pour les précisions probabilistes, mais ce n’est probablement pas ce que vous recherchez. Dans le cadre d’une initiative d’optimisation expérimentale, vous voudrez optimiser. Des métriques telles que l’entropie croisée ou la vraisemblance s’appliquent aux prévisions probabilistes. Plus important encore, il y aura des choses que vous découvrirez progressivement en identifiant des décisions insensées. La prévision n’est qu’un moyen pour atteindre une fin, qui est la décision. Vous devez prêter attention aux décisions. Nous avons brièvement abordé cela dans la conférence précédente sur l’optimisation expérimentale. Le processus est le même pour les prévisions classiques ou probabilistes. Si vous voulez avoir des exemples concrets de prévisions probabilistes, cela sera traité de manière exhaustive dans les conférences suivantes. Je suis désolé de m’écarter un peu en répondant à cette question.

Question : Que pensez-vous de l’utilisation de l’IA (Appreciative Inquiry) pour soutenir votre IA (Intelligence Artificielle) ? Quelles techniques utiliserez-vous pour trouver logiquement de grands ensembles de données, et pourquoi les taux de conversion diminuent-ils malgré de bonnes performances globales ? Quelle est la cause de l’activité ?

L’IA, en tant qu’ensemble d’algorithmes, est principalement basée sur le deep learning. Le deep learning est un ensemble de techniques très capables de traiter des données très peu structurées. La question que vous devriez vraiment vous poser est comment connecter cela à la réalité. Dans la chaîne d’approvisionnement, les données ont tendance à être très rares. La plupart des produits dans n’importe quel magasin sont vendus à moins d’une unité par jour. Les grands ensembles de données ne sont grands qu’en agrégat lorsque vous regardez une très grande entreprise avec des tonnes de transactions. Si vous regardez les granularités qui importent vraiment, vous n’avez pas autant de données.

L’Appreciative Inquiry, en termes de méthodologies, concerne vraiment l’optimisation expérimentale discutée dans la conférence précédente.

Question : Beaucoup de managers ne comprennent pas la puissance de la science des données, et leur donner des problèmes fictifs est un chemin sûr. Si ils ne veulent pas se plonger dans l’apprentissage de la science des données, quelle est une alternative pour les faire croire en la science des données et aux approches axées sur la décision ? Comment commencer petit et déployer grand ?

Tout d’abord, si vous avez des personnes qui ne croient pas en une technologie, c’est parfaitement normal. Prenez Warren Buffett, par exemple. C’est un investisseur très riche qui a passé sa vie à investir dans des entreprises qu’il comprend. Il investit dans des entreprises avec des modèles d’affaires simplistes, comme les entreprises de transport ferroviaire ou de location de meubles. Warren Buffett a déclaré : “Je ne suis pas intéressé à comprendre toutes ces technologies”. Par exemple, lorsque les gens lui ont demandé pourquoi il n’avait pas investi dans Google, Buffett a répondu : “Je ne comprends rien à ce que fait Google, donc même si c’est un bon investissement, je ne suis pas assez intelligent pour ça. Je vais simplement investir dans des entreprises que je comprends”.

Mon point est que, pour la direction, je pense que c’est une illusion complète de s’aventurer dans des domaines que vous ne comprenez pas. À un moment donné, si vous n’êtes pas prêt à faire l’effort, cela ne fonctionnera tout simplement pas. C’est le contre-exemple Jedi en action - la direction n’est pas prête à faire le moindre effort, et elle pense que le simple fait d’embaucher des ingénieurs intelligents, jeunes et intelligents fera l’affaire. Si c’était le cas, Amazon n’aurait pas eu le succès qu’il a eu. Si une entreprise de vente au détail traditionnelle pouvait simplement embaucher quelques ingénieurs pour créer un site de commerce électronique et concurrencer Amazon, elles l’auraient toutes fait. Jusqu’en 2005 environ, ces entreprises disposaient de ressources et de capacités d’ingénierie beaucoup plus importantes qu’Amazon lui-même.

Le problème, c’est que c’est une illusion, et c’est de cela que parle la connaissance négative - mettre en lumière les problèmes qui sont omniprésents. C’est pourquoi vous avez besoin d’un titre accrocheur pour communiquer le problème aux managers. Vous ne devriez pas non plus avoir peur d’apprendre de nouvelles choses. Lorsque vous prenez vraiment la bonne partie de la nouvelle technologie, ce n’est généralement pas si compliqué. Tout n’est pas super technique ; de nombreuses parties pourraient être expliquées. Par exemple, même quelque chose comme les blockchains - la moitié de ces technologies de blockchain soi-disant super avancées pourraient être expliquées à des enfants de 10 ans. Beaucoup des idées derrière ces technologies sont en fait assez simples. Il y a des tonnes de technicalités mathématiques accidentelles qui sont très difficiles, mais ce n’est pas l’essence du problème.

Donc, ma réponse à vous serait que si la direction veut croire aux contes de fées, il n’y a pas grand-chose à faire dans cette situation. Si la direction est prête à investir dans la science des données, elle devrait également être prête à investir un peu de temps pour comprendre ce qu’est la science des données. Sinon, c’est juste une illusion.

C’est tout pour aujourd’hui. Merci beaucoup, et la prochaine conférence aura lieu le même jour, mercredi, dans deux semaines, à la même heure. À bientôt.

Références

• ‘‘AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis’’. par William J. Brown, Raphael C. Malveau, Hays W. “Skip” McCormick, Thomas J. Mowbray, 1998