Pourquoi les transformations digitales de Supply Chain échouent (Eric Kimberling) - Ep 181

00:00:00 Introduction d’Eric Kimberling et de Third Stage
00:04:31 Mettre l’accent sur les personnes plutôt que sur la technologie dans les projets
00:06:14 Encadrer correctement les transformations digitales
00:08:08 Surmonter l’incrémentalisme dans les transformations
00:10:53 Les biais des fournisseurs risquent de mal orienter les efforts
00:12:40 Les défis des migrations forcées vers le cloud computing
00:14:46 La faible valeur de la mise à niveau des systèmes ou des enregistrements
00:19:26 Les sensibilités des systèmes et les impacts des transformations
00:21:38 Les vulnérabilités des grandes entreprises dans les transformations
00:23:39 Les problèmes de leadership accroissent l’aversion au risque
00:26:22 Le manque de perspective stratégique dans les transformations
00:29:42 L’importance de la sympathie mécanique dans le leadership
00:32:42 La latence des données entrave l’informatique distribuée
00:35:42 Les coûts élevés du traitement des données en téraoctets
00:38:38 Analyse des risques liés à la transformation technologique
00:41:43 Des stratégies visionnaires pour les transformations digitales
00:44:25 Équilibrer les budgets de projet avec les rendements
00:47:42 Des attentes réalistes des coûts dans les transformations
00:50:58 La surcharge de fonctionnalités logicielles freine la productivité
00:53:29 Se concentrer sur les processus métier plutôt que sur la technologie
00:56:39 La gestion interne des transformations technologiques
00:59:45 La bureaucratie dans l’exécution de la planification stratégique
01:02:48 La gouvernance prévient le chaos dans les supply chains
01:06:27 Une refonte complète pour des transformations ambitieuses
01:09:34 Optimiser le capex pour la valeur de la supply chain
01:12:20 Les inefficacités dans les transformations actuelles
01:15:28 L’utilisation des données des fournisseurs pour un avantage compétitif
01:18:11 Les incitations financières affectant la productivité
01:21:13 Poursuivre les développements prometteurs dans la technologie logicielle
01:23:19 Éviter les échecs coûteux en reconnaissant les coûts irrécupérables

Résumé

Dans leur discussion sur les transformations digitales de Supply Chain, Eric Kimberling et Joannes Vermorel mettent en évidence des échecs fréquents dus aux pressions induites par les fournisseurs et aux priorités mal alignées. Kimberling, à la tête de Third Stage Consulting Group, préconise des stratégies agnostiques en matière de technologie, en mettant l’accent sur les besoins métiers plutôt que sur de simples mises à niveau logicielles. Il met en garde contre les décisions précipitées dictées par les fournisseurs qui souvent ne parviennent pas à offrir des résultats transformateurs. Vermorel souligne l’importance de tirer parti des systèmes existants avec des add-ons innovants plutôt que par des remplacements disruptifs. Les deux leaders insistent sur l’alignement des efforts de transformation avec des objectifs commerciaux tangibles et soulignent que la gestion du changement est essentielle pour le succès. Ils préconisent une adoption progressive et réfléchie de la technologie, en veillant à ce que les objectifs soient définis et que le risque soit maîtrisé.

Résumé étendu

Lorsqu’on examine les raisons pour lesquelles les transformations digitales de Supply Chain échouent souvent, il est essentiel de prendre en compte les perspectives partagées par des leaders de l’industrie tels qu’Eric Kimberling et Joannes Vermorel lors de leur récent dialogue, animé par Conor Doherty. Kimberling et Vermorel possèdent tous deux une vaste expérience dans l’accompagnement des entreprises à travers les eaux périlleuses des bouleversements technologiques, et leurs points de vue révèlent des vérités cruciales souvent négligées par les organisations se lançant dans de telles initiatives.

Eric Kimberling, une sommité du leadership intellectuel en technologie, dirige Third Stage Consulting Group — une entreprise dédiée à offrir des conseils indépendants et agnostiques en matière de technologie aux organisations aspirant à des transformations digitales réussies. Son entreprise fonctionne sous une mission claire : autonomiser les clients grâce à des conseils impartiaux mettant en avant les besoins métiers plutôt que de simples mises à niveau technologiques. L’approche d’Eric souligne la nécessité pour les transformations de se concentrer non seulement sur des solutions technologiques, mais également sur un changement organisationnel holistique englobant les processus et les personnes plutôt que la technologie seule.

La conversation met rapidement en lumière la notion d’« agnosticisme technologique », un principe que Kimberling soutient devoir être au cœur de tout projet de transformation réussi. Il met en garde contre les biais induits par les fournisseurs qui privilégient les mises à niveau logicielles au détriment de véritables besoins métiers, un sentiment que Vermorel partage. Les fournisseurs imposent souvent des délais accélérés pour les mises à niveau — une stratégie qui peut inadvertamment piéger les entreprises dans des décisions précipitées ne produisant que des améliorations incrémentales, plutôt que transformantes. Eric avertit que ces mises à niveau sous pression s’alignent rarement avec les objectifs organisationnels à long terme et détournent souvent la valeur que la transformation digitale est censée apporter.

Joannes Vermorel, fondateur de Lokad, délimite les domaines du enterprise software en « systèmes de records », « systèmes de reports » et « systèmes d’intelligence », soutenant que les transformations ne devraient pas se concentrer myopiquement sur les systèmes de records qui offrent une valeur additionnelle minimale. Vermorel et Kimberling reconnaissent tous deux des stratégies alternatives adoptées par des entreprises telles que Palantir et Snowflake, qui améliorent les systèmes existants sans nécessiter de remplacement disruptif, soulignant l’avantage stratégique d’adapter les infrastructures actuelles avec des add-ons innovants.

Un thème récurrent dans leur discussion émerge, révélant que les grandes entreprises sont particulièrement vulnérables aux échecs coûteux lors des transformations digitales. Kimberling note que ces échecs découlent souvent de solutions complexes associées à une forte aversion au risque et à un manque de responsabilité décisive, soulignant le besoin intrinsèque d’une curiosité mécanique — un concept incitant les dirigeants à se familiariser intimement avec les exigences digitales de leur entreprise. Sans cette curiosité, les entreprises échouent lorsqu’elles externalisent trop, traitant les fournisseurs comme des moteurs principaux plutôt que comme des sous-traitants du changement.

Les dirigeants soulignent l’importance d’aligner les stratégies de transformation digitale avec des objectifs commerciaux tangibles. Ils présentent la perspective inquiétante de budgets gonflés consacrés aux mises à niveau ERP sans retour sur investissement clair — ou pire, des projets qui négligent complètement l’analyse du ROI et des bénéfices. La discussion souligne l’importance cruciale de la gestion du changement — l’élément souvent négligé du succès des transformations. Les transformations qui omettent l’assimilation culturelle et une formation complète sont vouées à rencontrer des complications, quelle que soit la prouesse technique impliquée.

En identifiant des cas de succès, Kimberling et Vermorel soulignent l’importance de la clarté et de la concision dans les documents de planification. Plutôt que des PowerPoints encombrants, des plans textuels concis favorisent une compréhension approfondie et facilitent une communication plus claire entre les parties prenantes. Ils vantent les mérites de traiter les investissements technologiques à l’instar des dépenses d’investissement — les considérant comme des actifs durables plutôt que de simples dépenses opérationnelles.

À la fin du dialogue, le duo réitère que, bien que les transformations orientées par la technologie puissent être de puissants catalyseurs pour l’évolution des entreprises, leur succès dépend d’un équilibre soigneux entre l’adoption d’innovations logicielles et le développement du changement organisationnel. Kimberling conseille d’aborder ces transformations avec une progression réfléchie, en s’assurant que les objectifs soient rigoureusement définis avant d’accélérer les mises en œuvre. Vermorel est d’accord, prônant des engagements progressifs et une approche « fail fast » qui atténue le risque tout en laissant place à l’adaptation.

À travers leur échange, Kimberling et Vermorel éclairent la voie aux organisations envisageant des transformations digitales — incitant les dirigeants à considérer plus que l’attrait de technologies à la mode, en se concentrant plutôt sur l’alignement de ces projets avec leurs objectifs commerciaux globaux et leurs aspirations.

Transcription Complète

Conor Doherty: Bienvenue à nouveau sur Lokad. Aujourd’hui, j’ai le plaisir d’animer une conversation entre Eric Kimberling et Joannes Vermorel. Eric est le CEO et fondateur de Third Stage Consulting Group, et il se joint à nous aujourd’hui pour partager sa perspective unique sur les raisons pour lesquelles tant de transformations digitales de Supply Chain échouent. Et pendant que vous êtes là, si vous appréciez ce que nous faisons chez Lokad, pensez vraiment à vous abonner à Lokad TV ici sur YouTube. J’attends.

All right, merci. Et suivez-nous également sur LinkedIn, et sur ce, je vous présente la conversation d’aujourd’hui avec Eric Kimberling. Tout d’abord, Eric, merci beaucoup de nous avoir rejoints et bienvenue chez Lokad.

Eric Kimberling: Merci de m’avoir invité. C’est un plaisir d’être ici.

Conor Doherty: Alors Eric, avant d’entrer dans le vif du sujet de la conversation, je dois dire que tu es une voix très populaire en ligne. En fait, je t’ai découvert pour la première fois sur LinkedIn. Tu as un bel auditoire, et tu es également prolifique sur YouTube. Nous avons principalement une audience européenne, donc ils ne te connaissent peut-être pas aussi bien. Pourrais-tu donner une brève présentation à ceux de notre audience qui ne sont pas en Amérique du Nord ? Que fait exactement Third Stage Consulting Group, comment en es-tu arrivé là, etc. ?

Eric Kimberling: Oui, Third Stage Consulting Group est une entreprise américaine de conseil en transformation digitale. Et la clé de notre modèle économique est que nous sommes indépendants et agnostiques en matière de technologie. Nous aidons donc les clients tout au long du cycle de vie, depuis la stratégie digitale et l’évaluation et la sélection des logiciels, jusqu’à la planification de la mise en œuvre, en passant par la gestion de programme de mise en œuvre réelle et la gestion du changement.

Nous avons près de 100 consultants. Nous disposons en fait d’un petit bureau en Europe, basé au Royaume-Uni, qui gère la région EMEA. Vous avez donc raison de dire que nous ne sommes pas encore aussi présents en Europe, mais notre objectif est d’avoir une présence dans la région EMEA équivalente à celle de l’Amérique du Nord. En réalité, j’ai fondé l’entreprise en 2018 parce que j’avais le sentiment qu’il n’y avait pas assez de consultants vraiment agnostiques en matière de technologie, objectifs, et représentant véritablement les intérêts des clients.

« C’est donc vraiment la raison pour laquelle j’ai créé l’entreprise. C’était simplement pour offrir aux clients une alternative au modèle de conseil typique. »

Conor Doherty: Lorsque tu parles du modèle de conseil typique, je suppose que l’agnosticisme technologique en fait une grande partie, mais pourrais-tu expliquer ce que tu entends par là ? C’est une belle expression, mais que veux-tu dire par agnosticisme technologique ?

Eric Kimberling: Bien sûr, “tech atheism”, j’aime bien ce terme aussi. Non, l’agnosticisme technologique signifie que nous ne sommes pas mandatés par les fournisseurs de logiciels. En d’autres termes, nous ne gagnons pas d’argent lorsque les fournisseurs en gagnent. Nous ne gagnons de l’argent qu’uniquement de nos clients. Et c’est une nuance vraiment importante parce que la plupart des cabinets de conseil sont soit directement incités par les fournisseurs de logiciels à étendre l’empreinte logicielle autant que possible sur un marché ou une région.

Ils disposent d’une réserve de ressources focalisées sur une seule technologie, et leur objectif est d’affecter ces consultants à des projets centrés sur cette même technologie. Ce biais engendre un esprit axé sur la technologie dans la transformation, alors que, selon moi, les transformations les plus réussies, qu’il s’agisse de transformations de Supply Chain ou de mises en œuvre d’ERP, quelle que soit leur nature, sont celles qui répondent aux besoins métiers et définissent une stratégie et une feuille de route adaptées à ces besoins — et non pas en partant de la technologie pour ensuite tenter de voir comment elle pourrait s’intégrer à votre entreprise. Cela peut sembler être un détail très mineur, mais c’est en réalité une question capitale, et c’est un facteur déterminant de la réussite ou de l’échec sur le marché.

Conor Doherty: Eh bien, merci et Joannes s’adressera à toi dans un instant, mais je pense qu’il serait important de poser un peu le décor afin que nous comprenions l’agnosticisme technologique, merci ! Quand tu parles de transformation digitale, tu dis qu’elle ne se limite pas aux ERP. Pourrais-tu donner une brève présentation à ce sujet pour le reste de la conversation ? Quand nous parlons de transformation digitale, est-ce un processus de bout en bout ? Comment définis-tu l’étendue de cette notion ?

Eric Kimberling: En réalité, la façon dont nous la définissons est comme une facilitation technologique à l’échelle de l’entreprise. Il ne s’agit pas seulement de technologie ; ce qui est sans doute encore plus important, c’est l’aspect opérationnel et organisationnel, c’est-à-dire les processus et les personnes.

Lorsque nous examinons des technologies spécifiques, la plupart des gens partent d’une décision selon laquelle ils doivent remplacer leur technologie. Cela constitue généralement l’énoncé du problème : « Nous devons remplacer une certaine technologie. » Cette technologie pourrait être un système de supply chain, un système ERP, un CRM ou système de gestion de la relation client ; il pourrait s’agir d’un système RH, financier, et même, avec l’importance actuelle de l’IA, cela pourrait être l’IA, ou encore le business intelligence.

Il existe donc toutes ces différentes technologies parmi lesquelles choisir. À nos yeux, quand on pense à la transformation digitale, c’est un terme assez large et vague. Il englobe de nombreuses choses et de nombreuses technologies différentes, et ce qui est plus important à ce sujet, c’est que je pense que le terme transformation digitale prête un peu à confusion car il laisse penser qu’il s’agit uniquement de technologie. En réalité, ces projets deviennent généralement bien plus axés sur la gestion des personnes que sur la technologie.

Conor Doherty: Merci Eric, et maintenant Joannes, à toi. Eric a mentionné les énoncés de problème. Je sais qu’il est fondamental de bien comprendre l’énoncé d’un problème pour réaliser quoi que ce soit. Quelles sont donc tes impressions sur ce qu’Eric a dit et comment cela s’intègre dans ta compréhension de la transformation digitale ?

Joannes Vermorel: Je suis tout à fait d’accord, tout d’abord sur l’importance de l’agnosticisme technologique si l’on veut fournir de bons conseils. C’est absolument fondamental ; sinon, le problème sera littéralement encadré comme tout ce qui permet d’étendre l’empreinte de celui qui a déjà un pied dans la porte en tant que fournisseur. Cela conduirait alors le projet à se réduire à la question de savoir comment améliorer l’ERP de ce fournisseur, de la version N à N+1. Au final, c’est comme une recette pour un investissement massif avec très peu de résultats à montrer.

Les incitations ne sous-estiment pas la puissance de l’incitation pour encadrer correctement l’énoncé initial du problème. Cela peut paraître insignifiant, mais d’après ce que j’ai observé, ces toutes petites décisions prises généralement très tôt dans le processus peuvent ensuite déterminer complètement les millions de dollars qui seront dépensés sur plusieurs années. Je suis donc tout à fait d’accord : il est absolument fondamental de prendre le parti de l’entreprise. Qu’est-ce que nous voulons livrer, sans se poser d’abord la question du fournisseur ? Et puis il y a cette question annexe qui est vraiment – et je partage aussi pleinement votre vision – que la transformation digitale concerne principalement en quoi notre entreprise va changer si nous pouvons faire les choses mieux avec ces outils plus sophistiqués et autres.

Plutôt que de penser à une progression linéaire passant de la version N à la version N+1 – et c’est généralement une question très épineuse, car, par exemple, vous pourriez penser : “D’accord, nous avons tant de personnes qui font ci, ça et encore ceci,” – il s’est avéré que, peut-être, si nous étions mieux organisés, nous n’aurions même pas besoin de faire ces choses dès le départ. Il n’y a donc aucun intérêt à essayer d’optimiser ce qu’ils font, puisque la meilleure organisation ne devrait même pas avoir à le faire initialement. Je vois cela comme un défi pour penser véritablement en termes d’entreprise. Qu’atteignez-vous réellement ?

Et puis, vous devez avoir une bonne compréhension de la technologie, de ce qu’elle peut faire et de ce qu’elle ne peut pas faire. Mais je dirais que cela occupe une toute seconde place par rapport à une compréhension très claire de l’entreprise et de ce que vous essayez d’accomplir. Ce cadrage me plaît énormément et je crois que, pour moi, le plus grand défi de la plupart des entreprises – je pense en Europe, mais peut-être aussi dans une certaine mesure aux États-Unis – dans cette transformation digitale, c’est la malédiction de l’incrémentalisme. Elles pensent vraiment à la même chose, avec quelques petits clins d’œil en plus, ou se disent que nous aimerions avoir le même ERP, mais avec une interface web au lieu d’une interface de bureau, ou autre.

Et pour moi, oui, ce serait plutôt bien, mais fondamentalement, le retour sur investissement de ces projets très coûteux ne se justifie pas. Vous ne mettez pas à jour un ERP parce que vous en avez assez de votre interface moche. S’il fonctionne, il fonctionne, même s’il n’est pas esthétiquement plaisant. Si vous voulez effectuer une mise à niveau et y consacrer des années, il faut que le changement rende votre entreprise bien meilleure par la suite – et non pas simplement obtenir un outil plus joli – mais que l’entreprise elle-même se transforme. Voilà ce que, selon moi, signifie une transformation digitale authentique et correctement exécutée.

Eric Kimberling : Oui, c’est un excellent point, car vous soulevez de très bons arguments. L’un d’eux concerne la planification et les premières décisions prises, qui déterminent la trajectoire du projet. C’est tout à fait vrai, et de nombreuses organisations, je pense, se disent qu’elles vont simplement exécuter ces décisions à la hâte, se lancer dans le projet et régler tout au fur et à mesure. Et c’est à ce moment-là que tout devient chaotique et que la direction se fait floue.

Mais l’autre point auquel vous faites allusion, c’est qu’il est parfois acceptable de dire que nous n’allons pas mettre à jour notre technologie. Et si vous ne passiez pas au système le plus récent et le plus sophistiqué ? Et si, à la place, vous optimisiez ce que vous possédez déjà ? Et si vous vous concentriez sur la modification de vos business processes pour qu’ils soient plus optimisés ? Et si vous formiez vos équipes à mieux utiliser le logiciel ? Et si vous réalisiez toutes ces actions à faible coût qui apportent une valeur extrêmement élevée avec peu de risques pour l’organisation ? Pourquoi ne pas envisager cela comme une option ?

Maintenant, les éditeurs de logiciels ne seraient absolument pas d’accord avec moi. Si j’étais un éditeur de logiciels, je dirais que c’est une idée terrible : il faut mettre à jour toutes vos technologies, passer au cloud computing, adopter l’IA, et tout le reste, parce que j’essaie de vous vendre de la technologie. Mais si vous prenez du recul, retirez l’émotion et les partis pris de l’éditeur, de nombreuses organisations en concluront que, “Vous savez quoi ? Nous n’avons pas besoin de nous précipiter pour passer au cloud computing simplement parce que notre éditeur nous impose une date limite.”

Et je pense qu’il est vraiment important de prendre cette transformation en main et de la baser sur les besoins, les priorités et les stratégies de votre entreprise, et non sur ceux des éditeurs de logiciels.

Conor Doherty : Eric, si je puis enchaîner, je ne veux pas vous mettre de mots dans la bouche, mais cela implique-t-il que les gens sont peut-être un peu induits en erreur par des consultants ou des éditeurs, ce qui mène aux échecs de transformation digitale ? Sinon, quelles sont selon vous les raisons les plus courantes pour lesquelles ces transformations échouent ?

Eric Kimberling : Oui, c’est une excellente question. Nous pourrions passer tout l’entretien à discuter de ce point. Mais pour résumer, je dirais que, oui, les biais contribuent assurément à l’échec. Si je suis un consultant en logiciels et que j’aborde avec une vision myope en affirmant que telle est la technologie dont votre organisation a besoin, vous créez déjà un décalage, car je ne pars pas de votre entreprise, je pars de ma technologie.

Ma technologie dispose de meilleures pratiques ; elle intègre des workflows ; vous devez vous adapter à mon logiciel parce qu’il est excellent. C’est un processus particulièrement perturbateur à cause de cela. Je pense donc que le biais en fait partie, c’est un facteur important. Mais ce que je considère comme un facteur encore plus déterminant, que beaucoup ne reconnaissent pas, c’est que bon nombre de ces grands éditeurs de logiciels, comme SAP ou Microsoft, obligent essentiellement leurs clients à passer à une nouvelle technologie en déclarant : “Nous allons retirer la maintenance et le support de votre ancien système ; nous le retirerons à cette date, et vous disposez jusqu’à cette date pour migrer vers le nouveau système, sinon nous coupons le support.”

Et je trouve cela extrêmement irresponsable ; ce n’est pas une problématique centrée sur le client. C’est essentiellement transformer un problème d’éditeur en un problème client. Le problème de l’éditeur est que nous devons passer au cloud computing parce que c’est plus rentable pour nous, nos investisseurs l’exigent. Ainsi, ce problème devient celui du client, car on lui annonce : “Eh bien, je sais que vous avez peut-être implémenté une solution sur site il y a deux ans, mais devinez quoi ? Nous retirons le support pour ce même système que vous venez d’installer ; nous le ferons dans deux ou trois ans, et vous avez jusqu’à là pour migrer vers le nouveau système.”

Cela crée donc une panique précipitée au sein des organisations, et c’est le pire moment pour être lorsqu’on tente de mener cette transformation, car cela conduit à ce que vous mentionnez : “Maintenant, je vais simplement apporter ces améliorations incrémentales. Je vais investir tout ce temps, cet argent et prendre des risques juste pour obtenir peut-être quelques améliorations mineures pour mon entreprise,” et il devient difficile de justifier le ROI dans un tel processus.

Conor Doherty : Joannes, je sais que vous êtes un grand fan des éditeurs et que vous les défendez bec et ongles, mais puis-je vous demander un commentaire à ce sujet ?

Joannes Vermorel : Oui, enfin, selon moi, le secteur du logiciel – je divise, d’ailleurs, le monde du logiciel d’entreprise en trois royaumes distincts : nous avons les systems of records, les systems of reports et les systems of intelligence. Les systems of records concernent essentiellement les saisies de données et les workflows. Cela englobe tout ce qui relève de la gestion dans un system of record, qu’il s’agisse de CRM, d’ERP (qui aurait dû s’appeler ERM, enterprise resource management, puisque la planification est une préoccupation secondaire), de TMS, de systèmes de gestion de transport, etc. Tous ces systèmes de gestion sont des systems of records.

Selon moi, une fois que vous disposez d’un system of record qui convient, qui fonctionne et qui n’est pas excessivement lent, vous avez en quelque sorte terminé pour cette couche. Ce que j’appelle la transformation digitale, c’est que les gens essaient d’améliorer des éléments qui ne peuvent pas être significativement améliorés. Si, par exemple, vous êtes comptable, vous possédez déjà un grand livre, qui est bon, même s’il n’est pas étincelant ; mais ce grand livre contient-il tout ce dont vous avez besoin ? Oui, et c’est exactement ce que font ces systems of records.

Les systems of records existent, et je constate que dans ces transformations digitales, de nombreuses discussions portent sur la mise à niveau de systems of records qui capturent déjà presque tout ce dont ils ont besoin. Pour moi, la valeur ajoutée de ce type de transformation – qui absorbe typiquement plus de 80 % du budget – est quasiment nulle, car vos workflows sont déjà en place. Ils fonctionnent déjà. Votre logiciel, enfin, une nouvelle interface ne changera rien puisque l’essence même est dans les saisies de données et autres.

Et si vous disposez de cela, que cela fonctionne et que cela capture fonctionnellement tout ce dont vous avez besoin, alors vous avez terminé. Je pense que la malédiction de ces éditeurs de logiciels d’entreprise, et particulièrement des entreprises comme SAP, c’est qu’ils se rendent compte qu’ils ont atteint un point où le travail était terminé. Mission accomplie pour le system of record, il y a deux décennies.

Et maintenant, d’ailleurs, vous pouvez expliquer tout le mouvement de SAP HANA vers, “Oh, transformons cette chose,” transformant ainsi un system of record en un system of reports avec toutes sortes de couches analytiques. Mais mon analyse est la suivante : vous devriez rester fidèle à vos principes. Vous êtes un system of record. Et lorsque les entreprises adoptent ce point de vue, elles se disent alors : “Nous ne devrions pas investir dedans, car la prochaine version ne fera qu’apporter des bugs, des régressions, de nouvelles formations, à moins que les anciens systèmes ne soient devenus insupportables, parce qu’ils étaient beaucoup trop lents, truffés de bogues ou incapables de capturer les enregistrements dont nous avions besoin. Dans ce cas, il n’y a aucune valeur ajoutée.”

Et pour nous en supply chain, c’est vraiment important car je vois de nombreux clients qui possèdent des systèmes de gestion des stocks vieux de 30 ans. Ce sont des écrans de console en noir et blanc, mais fonctionnellement, ils réalisent 100 % de ce dont ces entreprises ont besoin. Et la gestion des stocks, vous savez, ce n’est pas de la science-fusée. Je prends quelque chose, plus ou moins un sur l’étagère. Je mets quelque chose sur l’étagère plus un.

Ainsi, ces logiciels sont anciens et, fonctionnellement, ils accomplissent 100 % de ce dont ils ont besoin. Dépenser énormément d’argent simplement pour mettre à jour ces éléments, selon moi, n’apporte pas les résultats que les gens pensent obtenir en investissant dans ce type de démarche.

Eric Kimberling : Je suis d’accord. Et je pense que c’est pour cela que des entreprises telles que Palantir et Snowflake – certains de ces systèmes complémentaires, je ne veux pas dire qu’il s’agit de systèmes “bolt-on”, mais ce sont des systèmes conçus pour interopérer avec d’autres systems of records – existent. Vous pouvez donc dire : “Eh bien, mon system of record est peut-être obsolète, mais il fonctionne, et je ne veux pas supporter tous les risques, coûts et efforts liés à son remplacement. Mais je veux de meilleurs rapports. Je veux une intelligence accrue. Peut-être que je veux certaines capacités d’IA. Mais je veux cela sans… je n’ai pas besoin d’arracher le system of record du back office.”

C’est ainsi que des entreprises comme Palantir, Snowflake, et d’autres ont vu le jour. Elles créent une solution qui dit : “Conservez votre ancien système. Cela ne nous regarde pas. Nous allons vous fournir une solution qui n’interfère pas avec celui-ci. Au contraire, elle se base dessus et vous offre de meilleurs workflows, une meilleure IA, de meilleurs rapports, une meilleure intelligence, et tout ça.”

Je pense donc que vous avez raison. Ce sont des options que, très souvent, les organisations et les équipes ne réalisent pas. Elles ont des options parce qu’elles entendent d’autres éditeurs dire : “Non, non, non, vous devez remplacer votre system of record parce qu’il repose sur une vieille technologie. Vous avez des dettes techniques. Vous allez prendre du retard.” Vous savez, c’est de la vente basée sur la peur. Et ça fonctionne.

Heureusement pour les éditeurs, ça fonctionne. Malheureusement pour les clients, ça fonctionne. Je pense donc que la clé est simplement de vous informer, d’être objectif et d’obtenir cet avis externe et objectif sur quelles sont réellement vos options, parce qu’il se pourrait que vous laissiez votre system of record en place, tout en y ajoutant quelque chose qui vous offre plus de capacités sans tous les risques.

Joannes Vermorel : Sans aucune honte, c’est exactement le modèle économique de Lokad. Il est orienté de la même manière que Palantir ou Snowflake. Nous faisons exactement cela pour ces raisons. Mais évidemment, je ne voulais pas vous forcer à le dire. Mais oui, c’est bien mon point. Le problème avec ces systems of records, c’est que dès que vous les touchez, le niveau de disruption pour l’organisation est immense.

Vous pouvez activer ou désactiver une Snowflake qui effectue des analyses en parallèle, ce qui n’est pas un problème tant que vous n’êtes pas réellement dépendant pour vos opérations quotidiennes. Mais d’ici là, vous pouvez activer ou désactiver cet outil autant que vous le souhaitez. Contrairement au system of record où, si vous le touchez et qu’il se bloque, tout part en vrille parce que, soudainement, vous ne savez plus à qui vous devez payer, à vos fournisseurs, qui vous doivent de l’argent de la part de vos clients, etc.

Ainsi, les systems of records constituent une couche bien plus sensible et délicate. C’est pourquoi je dirais que l’avantage n’est pas si important, car si vous avez déjà quelque chose de fonctionnellement satisfaisant, la mise à niveau n’apportera pas grand-chose. Mais l’inconvénient, si vous le brisez, peut être absolument immense.

Récemment, en France, une grande entreprise, GiFi, a fait faillite, simplement à cause d’une mauvaise gestion de transformation digitale – j’ai d’ailleurs ce document ouvert sous les yeux – une entreprise de plusieurs milliards qui a sombré à cause d’une transformation digitale mal gérée.

Eric Kimberling : Disons que c’est aussi une grande entreprise bien connue en France, n’est-ce pas ?

Joannes Vermorel : Oui, c’était, disons, l’un des dix premiers réseaux de distribution nationaux.

Conor Doherty : C’est en réalité une transition parfaite, car je voulais justement aborder quelque chose que vous commentez souvent, Eric, à savoir prendre l’exemple de grandes entreprises que tout le monde connaît. En fait, j’ai une liste devant moi. Vous avez parlé, par exemple, de Lidl. Je l’ai sous les yeux : un échec de 600 millions en tentant de transformer leur système ERP. Excusez-moi. Mais il y en a aussi dans le monde entier, pas seulement en Europe.

Il y a DHL qui perd des centaines de millions, Lidl en Allemagne qui perd un demi-milliard. Asda, GE, Spar. En fait, je me souviens avoir vu une de vos vidéos sur Spar également. Encore une fois, ce sont de grandes entreprises, donc ce n’est pas localisé uniquement en Europe ou en France, par exemple, ni seulement à Washington ou ailleurs. Cela ressemble presque à un phénomène systémique.

Maintenant, je ne veux pas vous mettre de mots dans la bouche, mais si cela est en fait quelque peu systémique chez les grandes entreprises, la question devient alors : y a-t-il quelque chose d’uniquement vulnérable dans ces grandes entreprises qui conduit à cela ? Manquent-elles d’agilité ou quoi ? Pourquoi ces grandes entreprises perdent-elles autant d’argent ?

Eric Kimberling : C’est une excellente question. Tout d’abord, je ne sais pas. Je ne pourrais pas vous le dire non plus. Oui, je soupçonne qu’il existe probablement des taux d’échec légèrement plus élevés chez les grandes entreprises, bien que je dirais qu’il y a aussi plein de petites et moyennes entreprises qui échouent. La seule différence, c’est que vous n’en entendez pas parler parce que personne ne s’en soucie.

Personne n’avait entendu parler de ces entreprises auparavant, mais on a entendu parler de Lidl. On a entendu parler de Spar Group. On a entendu parler d’Asda, quel que soit le grand nom. Mais je pense que pour répondre à votre question sur pourquoi les grandes entreprises sont plus susceptibles de connaître ces échecs, je dirais que les dynamiques en jeu dans une grande entreprise se prêtent à l’échec, en partie à cause du comportement organisationnel. En partie, c’est parce qu’une grande entreprise, par exemple, est plus susceptible de mettre en œuvre une solution grande et complexe parce qu’elle est une entreprise grande et complexe et qu’elle a l’impression d’avoir besoin d’une solution encore plus grande et complexe.

Ainsi, elles sont plus susceptibles d’acheter un SAP ou un Oracle ou un autre grand système. C’est donc là un facteur de risque. Cela augmente immédiatement votre risque puisque vous essayez maintenant de mettre en œuvre un système grand et complexe.

L’autre dynamique qui se produit plus souvent dans les grandes entreprises que dans les plus petites est ce que j’appellerais le manque de responsabilité. Il y a moins de visibilité et de responsabilité au niveau exécutif. Souvent, ces dirigeants ont tellement de choses à gérer. Ils s’étendent, ils se lancent sur de nouveaux marchés et ils achètent des entreprises. Ils se concentrent sur ces aspects stratégiques et considèrent la transformation digitale comme quelque chose de non stratégique, ce qui est une erreur.

Et ils délèguent cela au sein de l’organisation. Ce manque d’appropriation, de transparence, de visibilité et d’adhésion au niveau exécutif, ce manque d’implication des dirigeants, conduit à l’échec. C’est l’une des grandes causes profondes. Ensuite, je dirais qu’une troisième dimension qui joue contre les grandes entreprises, c’est qu’elles sont plus susceptibles d’être si averses au risque qu’elles augmentent en réalité le risque, ironiquement.

Et ce que je veux dire par là, c’est qu’ils se disent : “Eh bien, si j’implémente SAP, SAP est un produit bien connu. Si j’engage Accenture, Deloitte ou KPMG, ce sont des entreprises très réputées. Ainsi, je vais couvrir toutes mes arrières et m’assurer d’engager des marques blue-chip qui me permettront de me sentir à l’aise en sachant qu’elles sont les expertes, qu’elles peuvent gérer cela.”

Et puis ce qui se passe, c’est que vous avez un chéquier ouvert et l’intégrateur de systèmes prend en charge votre projet parce que vos dirigeants ne sont pas vraiment impliqués et qu’ils font confiance aux grandes marques. Et ces grandes entreprises suivront la voie de l’implémentation de technologie et elles vont compliquer les choses à l’excès, même si cela n’a pas forcément de sens pour votre entreprise, car c’est ce qu’elles savent faire.

C’est ce qu’elles font, et je ne pense pas qu’il s’agisse en réalité d’une action malveillante intentionnelle. Mais je pense que le manque d’appropriation et de transparence conduit les individus à poursuivre leur propre intérêt, ce qui, lorsque les fournisseurs et les intégrateurs de systèmes poursuivent leur propre intérêt, les incite à vous vendre plus de logiciels. Ils veulent vous facturer plus d’heures, et le ROI n’intervient pas du tout. Peu importe que cela apporte de la valeur ou non. Ils seront payés.

Ainsi, les incitations sont mal alignées. Dans une grande entreprise, une entreprise grande et complexe, ces dimensions sont amplifiées parce qu’il s’agit d’une entreprise plus importante et qu’il y a plus en jeu. Donc, je pense que ces trois éléments sont probablement les trois principaux qui me viennent à l’esprit en ce qui concerne ce qui fonctionne davantage contre une grande entreprise que contre une plus petite. Toutefois, je dirais qu’une petite ou une entreprise de taille moyenne est également susceptible d’échouer si elle ne suit pas simplement les fondamentaux de base.

Et la bonne nouvelle, c’est qu’il n’y a ni science-fusée ni formule secrète pour réussir cela. C’est en fait assez simple, mais les organisations ne prennent pas le temps de s’arrêter, de réfléchir et de prendre les bonnes décisions dès le départ. Cela conduit à bon nombre des problèmes dont nous parlons.

Conor Doherty : Merci Eric. Joannes, vous avez commenté une ou deux fois au sujet de la bureaucratie dans les grandes entreprises. Pourriez-vous répéter ces réflexions ?

Joannes Vermorel : Oui, je veux dire, selon moi, les petites entreprises peuvent échouer car, oui, elles manquent de ressources pour engager des experts, etc. Je crois que les grandes entreprises, qui échouent fréquemment, disposent de tous les experts, mais le problème est qu’ils arrivent avec un agenda. Tous ces experts sont embauchés, et ils viennent avec toutes sortes d’agendas.

Parfois, il s’agit d’agendas un peu, je dirais, idiots, comme lorsque des personnes veulent simplement essayer une nouvelle technologie parce que cela aura bonne allure sur leur CV. Ne sous-estimez donc pas non plus le fait que les techniciens vont faire des choses techniques juste pour le plaisir d’expérimenter et de bidouiller.

Mais aussi, je pense qu’un problème est, comme vous l’avez souligné, que la transformation digitale n’est pas considérée comme stratégique. En cascade, j’ai souvent constaté que la haute direction des grandes entreprises ne possède pas de mechanical sympathy.

Alors, que veux-je dire par mechanical sympathy ? Ils n’ont aucune curiosité pour ce qui se passe sous le capot, pour la manière dont ces choses sont connectées, pour ce dont nous parlons réellement. Je ne parle pas d’être un ingénieur logiciel expert, mais parlons-nous simplement d’une application rudimentaire, vous savez, créer, lire, mettre à jour, supprimer sur une base de données qui comporte de nombreuses tables ?

Ou avons-nous besoin de temps réel ? Que signifie exactement le temps réel ? Avons-nous besoin de microsecondes, de millisecondes, de secondes ou d’heures ? Avons-nous besoin, etc., etc. ? Je veux dire, il y a plein de questions relativement basiques, mais si vous n’avez pas ce que j’appelle la mechanical sympathy, alors les objets ou objets logiciels que vous manipulez sont complètement abstraits.

Et pour vous, c’est une série de noms de code qui n’ont absolument aucun sens. “Oh, nous avons besoin du widget ABC20, et pour faire fonctionner ABC20, nous devons également mettre à niveau Contoso12.” Et Contoso12, oh, il a aussi besoin de la bidule numéro sept, etc., etc.

Je veux dire, c’est comme une longue liste de noms de code qui n’ont aucun sens. Ensuite, si vous avez ce genre d’environnement qui, je dirais, se prête très facilement à une forme de capture technocratique. Vous savez, la perspective business est balayée d’un coup parce qu’en fait, les hommes d’affaires ont complètement abandonné leurs revendications parce qu’ils n’ont pas de mechanical sympathy. Ainsi, ils ne se sentent même pas en capacité d’exprimer une opinion sur la direction générale que prennent les choses, et de savoir si cette direction est en adéquation avec l’entreprise ou non.

Pardon, c’est une longue réponse, mais cet ingrédient de mechanical sympathy, je l’ai vu manquer dans beaucoup, beaucoup d’entreprises. Et cela ne requiert pas autant d’expertise. Vous savez, c’est un peu comme un passionné de voitures qui prendra simplement un peu de temps pour comprendre ce qui se passe sous le capot afin que ce ne soit pas de la pure magie si la voiture avance. Il y a une certaine compréhension des principaux éléments constitutifs qui font fonctionner le tout.

Eric Kimberling : Oui, absolument. C’est un terme intéressant. Je n’avais pas entendu parler de mechanical curiosity, et je pense que cela revient à un point que je souligne souvent. Je pense qu’ils sont étroitement interconnectés, et qu’il s’agit de l’appropriation générale et de la curiosité envers le produit dans son ensemble.

Et donc je pense que cela englobe ce que vous dites, c’est-à-dire la mechanical curiosity. Mais je pense que vous touchez un point ici, à savoir que, si vous ne faites pas ce dont vous venez de parler concernant cette mechanical curiosity, il n’y a aucun moyen d’avoir l’appropriation et l’intelligence suffisante pour prendre des décisions éclairées autour de ces projets.

Et en n’ayant pas cette curiosité et cette expérience pratique, vous n’avez pas besoin d’être aussi expérimenté que les experts, mais au moins suffisamment pour pouvoir les gérer, car c’est votre travail de les diriger. Ils ne devraient pas vous diriger simplement parce qu’ils sont les experts. C’est votre entreprise. C’est vous qui devez en assumer les conséquences, alors gérez-les en conséquence.

Ça m’étonne de voir combien de grandes organisations disent : “Voilà, je ne suis pas un expert en technologie. Je ne suis pas responsable, je vais laisser les experts s’en charger.” Mais il s’agit d’une transformation business, et si vous la faites correctement, c’est véritablement une transformation business, et vous devez être impliqué, très impliqué.

Même si vous n’êtes pas impliqué dans la mechanical curiosity technique, vous devriez au moins être impliqué dans la curiosité opérationnelle. Qu’est-ce que cela va signifier pour mon organisation ? À quoi vont ressembler mes opérations ? Comment les emplois des gens vont-ils être affectés ? Est-ce que je veux cela, est-ce acceptable, ou est-ce que je souhaite autre chose ?

Et si vous n’êtes pas impliqué, l’intégrateur de systèmes finira inévitablement par créer ce qu’il juge juste, et cela ne correspondra tout simplement pas à votre vision ni à votre stratégie.

Conor Doherty : Permettez-moi également, simplement parce que je suis d’accord avec vous deux, de glisser ici un petit commentaire, car je vous ai entendu parler de mechanical sympathy à plusieurs reprises. Récemment, dans un autre podcast avec le Supply Chain Connect, salutations, j’ai évoqué exactement ce concept.

Il y avait deux très bons points, à savoir les avantages directs de la mechanical sympathy. De toute évidence, lorsque vous comprenez un peu le logiciel, vous savez comment mieux l’exploiter, ce qui augmente le ROI direct de son utilisation. Mais cela vous protège également contre les revendications fallacieuses des fournisseurs.

Et vous l’aviez déjà dit, qu’une bonne compréhension de ce qui est conçu, de ce que le logiciel est capable de faire, peut vous protéger éventuellement contre des revendications trompeuses de la part des fournisseurs.

Joannes Vermorel : Oui, je veux dire, juste un exemple, prenons par exemple les LLM. D’accord, l’IA est géniale, fantastique, donc nous avons ces large language models. Quel est le coût d’ingérer un mégaoctet de données dans un LLM, en gros ?

En gros, c’est d’un mégaoctet, même avec un modèle bon marché, on parle essentiellement de 1 $, et c’est pour le bas de gamme. Chaque fois que vous souhaitez obtenir une réponse, si vous devez traiter un mégaoctet de données en entrée avec votre LLM, cela vous coûtera 1 $, même avec le modèle le moins cher.

Si vous gardez simplement ce chiffre en tête, vous réalisez qu’il y a plein de choses qui, dès le départ, resteront invisibles pendant probablement plus d’une décennie. Car si vous pensez : d’accord, j’ai des téraoctets de données, d’accord, je ne vais pas les traiter d’abord via les LLM.

Et puis, si à chaque fois que quelqu’un clique, vous devez payer 1 $, vous effectuez simplement des mathématiques de base qui vous diraient : d’accord, cette chose ne peut pas fonctionner. Ce n’est pas économiquement viable.

Même si le prix chute d’un facteur de 100, il manquerait toujours quatre zéros par rapport à quelque chose de sensé. Juste un exemple, et j’ai vu de nombreuses situations où, en discutant avec des prospects, je disais : prenons quelques ordres de grandeur de base pour que nous sachions de quoi il s’agit.

La même chose, par exemple, pour l’informatique distribuée. L’informatique distribuée est fortement limitée par la vitesse de la lumière. Les gens se demandent : “Pourquoi ai-je besoin de connaître la vitesse de la lumière ?” Mais la réponse est que si vous disposez d’un système dans lequel votre warehouse communiquera avec votre système central et que l’information circule dans les deux sens, vous aurez une latence de 200 millisecondes.

Vous vous rendez compte qu’il vous faut mille allers-retours pour effectuer une opération. Alors, nous parlons déjà de 200 secondes rien que pour ces allers-retours. Encore une fois, ce ne sont pas des mathématiques super sophistiquées, mais c’est le genre de problème qui indique que, d’accord, nous avons un souci de conception.

Vous n’avez pas besoin d’être un ingénieur poussé, nous parlons simplement d’une multiplication élémentaire, de quelques repères de base. J’ai vu de nombreux projets échouer chez nos clients simplement parce que quelques calculs empiriques basiques n’avaient pas été réalisés.

Ainsi, les gens se rendraient compte que cela ne fonctionnerait tout simplement pas compte tenu des objectifs business. Parce que le technologue pourrait dire : “Eh bien, cela va prendre 200 secondes. Beaucoup de calculs prennent du temps, pourquoi pas 200 secondes ?”

Mais le technologue dirait : “Non, c’est quelque chose qu’un opérateur attend, donc ce n’est même pas possible.” Ou alors, l’LLM dirait : “Oh, ça coûte un mégaoctet, 1 $.” L’ingénieur dirait : “Oui, pourquoi pas ? Vous savez, ce n’est qu’un point de prix, ça m’est égal.”

Peu importe, puis l’entreprise dirait : “Mais réalisez-vous qu’une personne payée environ 20 $ de l’heure va cliquer sur cette chose 60 fois par heure ?” Ainsi, le coût de votre LLM sera environ quatre fois supérieur à ce que nous payons la personne qui l’exploite.

Encore une fois, c’est juste, mais c’est la seule façon de s’assurer que cela ait un sens. Il faut que l’entreprise adopte une approche avec une certaine mechanical sympathy, une structuration du projet et une valeur ajoutée — la valeur ajoutée prévue — qui se justifie. Ce serait, ce serait mon point de vue.

Eric Kimberling : Oui, et en comprenant ces coûts cachés et ces éléments qui, en apparence, peuvent sembler améliorer votre business. Cela pourrait améliorer votre business, mais si cela augmente de manière spectaculaire et matérielle vos coûts, alors il vous sera probablement impossible d’obtenir le ROI que vous recherchez.

Joannes Vermorel : Oui, et encore, ne sous-estimez pas, d’après mon expérience avec les ingénieurs : comment ceux-ci peuvent vous donner cinq chiffres de précision, alors que la virgule est simplement un peu décalée dans le calcul.

Voilà, c’est pourquoi je dis que les dirigeants doivent vraiment avoir cette mechanical sympathy, cet intérêt pour la transformation digitale et tout ce qui s’y passe. Sinon, vous vous retrouvez entre les mains de technologues qui sont enthousiastes à propos de la technologie — très bien, parfait — mais qui peuvent très facilement se laisser distraire et perdre de vue ces ordres de grandeur qui déterminent simplement si vous obtiendrez un ROI positif ou non.

Conor Doherty : Juste pour m’assurer d’avoir bien compris, l’impact que vous avez mentionné plus tôt : un téraoctet, c’est un million de mégaoctets, n’est-ce pas ? Donc, traiter à un dollar par mégaoctet serait juste…

Joannes Vermorel : Un téraoctet, c’est mille gigaoctets. Donc oui, cela fait un million de mégaoctets. Ainsi, un téraoctet à ce niveau de prix dont je parlais coûterait un million de dollars par téraoctet à traiter.

Conor Doherty : Juste pour m’assurer que j’ai bien compris.

Joannes Vermorel: Alors oui, je veux dire, si vous souhaitez faire ça, vous ne devriez probablement pas le faire dès le départ. Et si vous devez absolument le faire, il faudrait vraiment vous assurer de ne pas avoir à le faire plus d’une fois par an, car évidemment, même pour une grande entreprise, nous parlons de coûts IT assez extravagants.

Conor Doherty: Eh bien, oui. Enfin, en fait, Eric, si je peux revenir là-dessus, car l’esprit général de tout ça, le cadrage global, concernait des choses qui manquaient. Mais je tiens à revenir sur autre chose qui manquait. Tu sais, nous avons déjà discuté de la mechanical sympathy, mais là, vous avez tous les deux évoqué l’idée du ROI, du retour financier.

Et quelque chose que tu as dit plus tôt, Eric, lorsque tu parlais d’entreprises, comme les grandes entreprises, qui choisissent quel logiciel elles vont utiliser, “Oh, nous allons simplement prendre le grand nom ? Nous prendrons ça. Et quelle est la grande firme de conseil ? Nous prendrons ça parce que, tu sais, case cochée.” Et tu as dit que, dans ce contexte, souvent le ROI n’avait pas d’importance. Maintenant, je sais que Joannes a déjà parlé des KPI financiers et du ROI dans la supply chain, mais je me demandais, pourrais-tu développer un peu cela, comme pourquoi penses-tu que la perspective financière pourrait être moins présente dans la supply chain qu’elle ne devrait l’être peut-être ?

Eric Kimberling: Oui, je pense qu’avec la technologie qui change aussi rapidement et de manière exponentielle, c’est presque comme une course aux armements nucléaire où les gens ont le FOMO, tu sais, la peur de rater quelque chose. Et ils veulent s’assurer qu’ils ne souffrent pas de dette technique et de tous ces termes fantaisistes que les analystes et les éditeurs de logiciels inventent.

Et ainsi, ils perdent de vue. Je pense que l’industrie perd de vue pourquoi nous réalisons ces projets technologiques. Je veux dire, nous ne le faisons pas parce que nous voulons des capacités cloud. Nous ne le faisons pas parce que nous voulons de l’IA. Nous ne le faisons même pas parce que nous voulons une meilleure intelligence, des rapports plus performants ou un meilleur système d’enregistrement.

Nous avons perdu de vue tout cela. Nous ne nous sommes tout simplement pas concentrés sur la raison pour laquelle nous avons besoin de cette technologie. Pourquoi avons-nous besoin, par exemple, d’aller dans le cloud ? Je veux dire, parfois je demande cela aux clients, et je reçois des regards vides genre, euh, parce que nous sommes actuellement en local. Je dis alors, “D’accord, vous êtes en local. Alors, quel est le pire qui pourrait arriver si vous restiez en local pendant cinq années de plus ?”

Eh bien, vous savez, alors nous ne serons plus dans le cloud, ou l’éditeur du logiciel va interrompre notre maintenance. D’accord, alors, attends une minute. Parlons-en. Peut-être qu’ils interrompent votre maintenance, quel est le pire qui puisse arriver ? Eh bien, il faudra que nous assurions la maintenance nous-mêmes, et nous ne pourrons pas contacter l’éditeur pour obtenir de l’assistance. D’accord, alors il se pourrait que vous deviez embaucher quelqu’un.

Regardons cela. Regardons cette option, car elle pourrait en réalité représenter un risque bien moindre pour vous que de passer par une transformation massive de 600 millions de dollars, dans le cas de Lidl, par exemple.

Ainsi, les entreprises ne font pas cela suffisamment car elles ont l’impression qu’elles le doivent. Elles se sentent obligées de faire une mise à niveau. Elles doivent migrer vers le cloud. Elles doivent adopter l’IA, bla, bla, bla. Je pense donc que tous ces changements technologiques, et la rapidité avec laquelle ils se produisent, font que les entreprises se perdent, se retrouvent désorientées et oublient la raison d’être de ces projets dès le départ.

Joannes Vermorel: Je pense que, enfin, les KPI financiers sont un peu trompeurs parce que je ne pense pas que ce soit la bonne approche. Votre parcours digital, appelons-le ainsi, s’étale sur environ 10 ans. Il faut penser à 10 ans d’avance — où voulez-vous être ? Ce sont des projets de longue haleine. Ce sont littéralement les entreprises que vous façonnez.

Mon point de vue est donc que se concentrer sur des KPI à court terme n’est pas vraiment pertinent pour moi lorsqu’il s’agit de déterminer si c’est la bonne chose ou non. C’est typiquement ce genre de chose qui pousserait, par exemple, Walmart en 2002 à dire, “Oh, non, le e-commerce, ça ne nous intéresse pas.”

C’est ce genre de raison qui vous amène à dire, “D’accord, le e-commerce est pertinent ; il est tellement petit, ça ne nous intéresse pas.” Non, il est en réalité très pertinent, et dans quelques années, il y aura un géant qui sera simplement plus grand que vous si vous ne faites rien. Ce fut une transformation digitale manquée. Je veux dire, la grande retail chain aurait pu devenir le géant du e-commerce ; ce n’est pas le cas parce qu’ils ont manqué la transformation digitale en quelque sorte.

Mais, pour revenir à ce point, je dirais que je suis plus enclin à penser du point de vue d’une vision business à long terme. Avons-nous une estimation sommaire qui nous indique que c’est la bonne chose à faire ? Ajustée au risque, en se demandant, tu sais, penses-tu que c’est à 90 % de risque ou 50 % de risque ou 10 % de risque, et essayer d’avoir une hypothèse simple juste pour justifier cela et aller dans cette direction.

Et maintenant, je pense que ce qui manque typiquement, c’est que, encore une fois, je parlais d’incrémentalisme. Les gens considèrent leur transformation digitale comme la même chose mais un peu améliorée. Encore une fois, si l’on revient à Walmart en 2002, l’avenir, c’est le e-commerce, donc ce n’est définitivement pas la même chose que simplement Walmart avec un meilleur point de vente doté d’un écran LCD.

Ce n’est pas, voyez-vous, ça c’est le problème. L’avenir est fondamentalement autre chose, et je pense que c’est généralement là que les entreprises n’interviennent pas assez pour remettre en question ce à quoi l’entreprise ressemblera dans 10 ans. Quels sont les types de rôles ? Il me semble qu’il y a eu un mémo très intéressant du PDG de Shopify qui circulait récemment sur LinkedIn.

Il disait littéralement à tout le monde, “Nous mettons en pause tous les recrutements pour le moment, et chaque département devra justifier que ce pour quoi ils veulent recruter ne peut pas déjà être réalisé avec les technologies d’IA, les LLM et autres choses du genre que nous avons déjà acquises, implémentées et intégrées dans notre système.” Shopify est une entreprise assez high-tech, donc ils ont déjà plusieurs années d’expérience en la matière.

Et il disait, “D’accord, nous avons un problème en termes de transformation. Clairement, l’essence du mémo, c’était que la direction générale ne se limitait pas à des perspectives très incrémentales au lieu d’être beaucoup plus ambitieuse sur le résultat final.” Et je trouve que le message était très intéressant. Ils ne disaient pas, “Nous n’investissons pas, nous n’embauchons pas.” Ils disaient, “Vous devez avoir une vision finale qui reconnaît que ces technologies existent et vous ne devriez pas essayer de suivre une trajectoire qui fait comme si elles n’existaient pas.”

C’était le cas de ce mémo, et c’était très intéressant. Je vois beaucoup de grandes entreprises qui, en ce qui concerne leur vision sur 10 ans pour l’entreprise transformée digitalement, quoi que cela signifie, se contentent de la même chose avec une interface utilisateur légèrement améliorée. Et pour moi, c’est très insuffisant.

Pensez à 10 ans d’avance, vous devez envisager quelque chose où la moitié des emplois, en particulier ceux de cols blancs, qui existent aujourd’hui, n’existeront plus. Cela ne signifie pas qu’il faut licencier des personnes ; vous pouvez les recycler, les reconvertir, etc. Mais les emplois eux-mêmes, au moins la moitié d’entre eux, devraient disparaître dans 10 ans, et ce sera le cas.

Eric Kimberling: Oui, et je pense que tu soulèves un point vraiment important, à savoir, pour les personnes qui écoutent et qui dirigent des initiatives technologiques ou de transformation dans leurs supply chains ou où qu’elles travaillent, il est important qu’elles se posent la question : Que voulons-nous que cette initiative devienne ? Est-ce une initiative visant à remplacer l’ancienne technologie et à simplement rester à jour, ce qui est peut-être plus incrémental, idéalement à moindre coût, mais potentiellement avec un ROI plus faible ? Ou cherchons-nous à transformer notre entreprise, à la transformer véritablement, et à explorer de nouveaux modèles économiques et l’innovation ? Ce sont deux chemins très différents, et aucun n’est ni juste ni faux. Il faut simplement s’assurer que vous êtes en accord et que vous prenez des décisions qui correspondent au chemin que vous empruntez. Ça ne devrait pas non plus être une solution universelle ; cela doit être basé sur qui vous êtes. La stratégie digitale de Shopify devrait être très différente de la vôtre, de la mienne ou de celle de n’importe qui d’autre.

Joannes Vermorel: Je suis tout à fait d’accord, mais le problème que je constate est que la voie numéro un, l’upgrade incrémental avec un faible ROI, est celle qui reçoit des budgets massifs.

Eric Kimberling: Oui.

Joannes Vermorel: Oui, et pour moi, c’est comme, comment peut-on avoir ce projet pour lequel, si l’on fait un calcul sommaire raisonnable, le ROI sera très modeste ? Pourquoi dépenser ? J’ai vu des entreprises, et je ne vais pas divulguer de noms, mais j’ai eu des discussions avec des entreprises qui ont des mises à niveau ERP de plus de 100 millions de dollars dans le cadre de projets sur plus de cinq ans. Lorsque je discute avec la direction générale, c’est très difficile de voir s’il y aura un quelconque retour — pas seulement un retour sur investissement, mais un retour au sens propre. Une fois la mise à niveau effectuée, l’entreprise sera-t-elle réellement meilleure ? Ce n’est même pas clair, surtout si vous devez répondre à des exigences matérielles du type SAP HANA, c’est-à-dire, je veux dire, je m’en tiens juste à SAP ; ils ne sont pas les seuls.

Conor Doherty: Allez, ça va.

Joannes Vermorel: Oui, mais si vous figez votre IT pendant cinq ans, le coût d’opportunité est tout simplement immense. Cela ne peut pas se résumer à quelque chose d’incrémental ; il faut que ce soit bien plus que cela.

Conor Doherty: Alors Eric, si je peux m’appuyer sur ça parce que littéralement, Joannes, qu’est-ce que je viens d’écrire là — le coût de premier ordre, le coût de second ordre en termes d’opportunité — littéralement, je venais juste d’écrire ces mots exacts pour te les restituer. Eric, encore une fois en tant que consultant, j’étais littéralement sur le point de te demander, comment expliques-tu exactement le concept de coûts de premier ordre et de second ordre ? Parce qu’évidemment, le coût de premier ordre : tu achètes ce logiciel, il va te coûter 50, 100, 150 millions ; tu devras embaucher des personnes pour le superviser, ce qui coûtera encore x millions, peu importe. C’est le coût de premier ordre.

Le coût de second ordre est, comme Joannes l’a justement dit, le coût d’opportunité. L’argent que vous venez de dépenser pour cela, vous ne pouvez pas le dépenser ailleurs, car un dollar dépensé ici ne peut pas être simultanément dépensé là-bas.

Joannes Vermorel: Votre équipe IT est débordée, figée dans le temps sur ce projet pendant une période donnée également.

Conor Doherty: Ceci, encore une fois, renvoie à la perspective financière dont je parlais plus tôt. Comment expliques-tu personnellement, quand tu es dans une salle en tant que technophile agnostique, pour aider les gens à comprendre — et je ne veux pas paraître condescendant, je veux dire littéralement — tu prends un dollar, tu ne peux pas acheter deux barres chocolatées si l’une coûte un dollar et l’autre un dollar ; tu ne peux pas acheter les deux avec un seul dollar. Donc, en termes de coût de premier ordre et de coût de second ordre, comment abordes-tu ces sujets de manière à ce qu’ils résonnent vraiment chez les personnes qui, comme tu l’as dit, ont le FOMO — ils ne veulent pas manquer quelque chose, ils veulent surfer sur la vague, etc.?

Eric Kimberling: Tu fais allusion à quelque chose que nous n’avons pas encore vraiment abordé en détail, à savoir des attentes réalistes et avoir des attentes réalistes quant à ces coûts de premier et de second ordre. Je pense que la cause fondamentale, ou l’une des causes fondamentales du problème, est que les organisations ne comprennent pas ce qu’est le vrai coût, et par conséquent, elles ne peuvent pas évaluer ces coûts d’opportunité parce qu’elles pensent que cela va coûter 100 millions alors qu’en réalité, cela n’aurait jamais dû coûter 100 millions ; cela aurait toujours coûté 300 millions. Mais quelqu’un vous a convaincu que cela pouvait être fait pour 100 millions de dollars, et cette personne vous a survendu, sous-estimé l’effort, sachant qu’il y a des complexités et des risques qui vont probablement augmenter le coût. Si vous y pensez, lorsqu’un éditeur de logiciels ou un fournisseur de solutions vous vend une solution, cela ne leur avantage pas, d’un point de vue intéressé, de surestimer le coût. Ce qui leur est avantageux, c’est de sous-estimer et de dire, “Non, non, c’est à faible risque, à faible coût.” Donc le problème commence là.

Donc, d’accord, si je dis que je vais évaluer les coûts d’opportunité, ces coûts de second ordre, je les évalue sur la base d’informations erronées. Même si je le fais, cela n’a pas d’importance car je ne dispose pas des informations précises pour prendre cette décision. Mais je pense que si davantage d’entreprises connaissaient le coût réel que cela allait réellement représenter, elles diraient, “Wow, wow, attends une minute, c’est beaucoup d’argent. C’est de l’argent que nous pourrions utiliser pour construire une autre usine. Nous pourrions ouvrir 10 magasins supplémentaires pour ce même coût. Est-ce ce que nous voulons ?” La plupart des organisations n’arrivent pas à ce point de décision car elles se basent sur un coût sous-estimé qui n’a jamais été réaliste.

L’autre chose, également, eh bien, il y a une autre chose à la fois — et je pensais que c’était peut-être là que vous alliez en venir avec le coût de premier et de second ordre — mais un autre coût sur lequel nous ne nous sommes pas encore penchés est la perturbation opérationnelle. Vous savez, que se passe-t-il lorsque vous adoptez une nouvelle technologie pour la première fois, peu importe la bonne gestion du projet ? Il y aura une baisse de productivité d’une certaine manière. Espérons que ce ne sera pas une chute libre totale de la productivité ; trop souvent, c’est le cas. Mais même si vous gérez cela très bien, vous allez tout de même connaître une certaine perturbation.

Alors, quel est ce coût de perturbation, et que se passerait-il, par exemple, si vous ne pouviez pas expédier vos produits pendant deux semaines, quatre semaines, trois mois ? Cela arrive aux organisations ; elles traversent ces projets, quelque chose tourne mal, elles se mettent en production, et puis elles ne peuvent pas expédier de produits. Les clients s’énervent, ils annulent leurs commandes. Ce sont là les coûts réels. Ce sont aussi les coûts que vous devez intégrer dans votre ROI, afin d’optimiser votre mise en œuvre et de vous assurer que vous la gérez bien et que vous comprenez quel est le vrai risque.

Conor Doherty: Tu as soulevé un très bon point là, Eric, et Joannes, je veux revenir vers toi encore une fois en prenant l’exemple qu’Eric vient de donner. Comme si vous preniez quelqu’un — et je ne vise personne en particulier — mais si vous preniez le niveau moyen issu, disons, de l’industrie automobile ou aérospatiale ou pétrolière, et que vous demandiez, “Combien coûte une heure d’arrêt en perte de productivité ?” Ils pourraient te donner une estimation approximative, mais les types d’arrêts que vient de décrire Eric, ils pourraient ne pas être en mesure de les quantifier.

Joannes Vermorel: Oui, et je pense aussi que pour le coût opérationnel, c’est tout à fait pertinent. Une chose que les gens ne réalisent pas, c’est que la productivité diminue lorsque la complexité de votre environnement augmente. Vous voyez, vous avez un logiciel ; il est ancien, il fait très peu de choses, mais il fait ce dont vous avez besoin. Cela signifie que, en ce qui concerne mon environnement informatique, mon interface utilisateur n’a pas autant de boutons, pas autant d’options, pas autant de fioritures et autres fonctionnalités. Maintenant, je passe à quelque chose de bien plus puissant. Pourquoi ? Parce que le fournisseur, il y avait tellement de cases à cocher dans l’AFP. Nous avons demandé au fournisseur, “Il devrait être capable de faire ceci, cela, ceci, cela, ceci, et encore cela, d’accord, 100 cases plus tard.” Maintenant, nous avons le système mis à jour qui peut faire en plus une tonne de choses.

Mais cela signifie que pour la personne qui utilise le logiciel, il y a beaucoup plus de menus. Et j’ai vu cela maintes fois dans les logiciels d’entreprise, où l’on me montre le logiciel et je dis, “C’est horrible.” C’est comme si vous aviez 30 menus, et puis je clique sur n’importe lequel, et chaque menu comporte environ 30 sous-menus, et peut-être que chaque sous-menu en a environ cinq. Et ensuite, vous avez un écran mural avec 20 options différentes.

Ainsi, ce que j’ai très souvent constaté, c’est que les gens mettent à niveau un logiciel, surtout ces systèmes d’archives, vers un nouveau, meilleur. Oui, l’interface est plus agréable, mais elle offre tellement plus de fonctionnalités que la productivité est en réalité plus faible, simplement parce que les utilisateurs se perdent dans un labyrinthe de fonctionnalités. Et donc, ce qui est intéressant, c’est que dans les logiciels d’entreprise, plus n’est pas nécessairement mieux, surtout lorsqu’il s’agit de fonctionnalités supplémentaires, celles que vous n’utilisez pas.

Chaque fonctionnalité dans un système que vous n’utilisez pas n’est qu’un poids mort. Cela signifie qu’elle va embrouiller chaque nouvel arrivant qui commencera à l’utiliser. Ils diront, “Pourquoi ça ne marche pas ?” Ah, parce qu’il y a environ cinq écrans différents pour réaliser des bons de commande, alors que nous n’utilisons qu’un seul des cinq. Les quatre autres, non, ne sont que des impasses. Si vous y saisissez vos données, elles ne seront pas traitées ; elles seront simplement perdues et ignorées. Ce sont le genre de choses que l’on peut rencontrer.

Eric Kimberling: Oui, absolument. Je veux dire, c’est un très bon point, et cela ramène vraiment à définir ce dont vous avez besoin. Je veux dire, avez-vous besoin de toute cette technologie ? Bien souvent, les entreprises s’engagent dans plus que ce qu’elles peuvent gérer, et elles surinvestissent dans la technologie. Cela crée ensuite tellement de complexité du côté technique que vous n’avez plus le temps ni les ressources.

Pour revenir à votre remarque sur le coût d’opportunité, vous n’avez plus le temps ni les ressources pour investir dans ce qui compte vraiment. Et ce qui compte vraiment, c’est : optimiser nos processus métier, s’assurer que les personnes sont bien formées, veiller à une bonne adoption, et redéfinir les rôles et responsabilités afin qu’ils s’adaptent à la nouvelle technologie et au nouveau modèle opérationnel.

Ces éléments sont ce qui détermine le succès ou l’échec d’un système ou d’une transformation. Pourtant, les entreprises surinvestissent dans la technologie. Je préférerais de loin voir une entreprise qui achète un peu de technologie mais qui l’implémente vraiment bien, car cette entreprise aura plus de succès. Elle diminuera les risques et obtiendra probablement un meilleur retour sur investissement.

Et puis, une fois que vous avez fait cela — d’ailleurs, une fois que vous avez réalisé ce petit investissement dans la technologie et que vous l’avez très bien implémenté — vous gagnez en confiance, en compétences et en maturité dans votre organisation au point où vous pouvez désormais dire, “D’accord, je vais entreprendre un projet plus important. Maintenant, je suis sûr que nous avons suffisamment appris pour investir dans un peu plus de technologie.”

Et au lieu d’acheter simplement un grand système massif, de dépenser tout cet argent, et ensuite de ressentir la pression de tout implémenter parce que nous avons payé pour cela — ce qui crée toute cette complexité — nous n’investissons pas dans l’adoption et l’amélioration des processus, toutes les choses importantes. Et c’est là que beaucoup de ces projets dérapent.

Conor Doherty: En fait, et encore, tout comme Joannes l’a évoqué plus tôt, vous avez posé exactement ce que je venais d’écrire comme prochaine question ou comme suivi. Nous avons longuement discuté des problèmes et des pièges à éviter. Mais cela soulève vraiment le concept même de l’implémentation et de la gestion du changement.

Alors, Eric, d’abord, sur une note plus positive, y a-t-il des éléments que vous avez observés dans des transformations digitales réussies, notamment dans le cadre de la gestion du changement, de la culture, des attentes, etc. ? Qu’est-ce qui aide réellement dans ce domaine ?

Eric Kimberling: Ouais, je veux dire, je vais revenir sur le terme que vous avez utilisé — honnêteté — vous avez dit : “mechanical sympathy, sympathy ?” Je pensais plutôt à la “mechanical curiosity” dans mon esprit. Les deux fonctionnent, pour être honnête. C’est à peu près la même chose. “Mechanical sympathy” — je savais que j’avais fait une erreur plus tôt. Mais la “mechanical sympathy” est vraiment importante.

Parce que les projets les plus réussis que nous avons vus sont ceux où les dirigeants de l’organisation s’impliquent concrètement. Ils comprennent la technologie ; ils ne sont peut-être pas des experts en configuration et en codage, ce n’est pas nécessaire, mais ils comprennent comment la technologie fonctionne. Et ils comprennent définitivement comment leur entreprise fonctionne et comment ils souhaitent qu’elle fonctionne.

Cette mechanical empathy conduira à une plus grande appropriation et à des résultats orientés business plutôt qu’à des résultats pilotés par la technologie. C’est donc un point que nous voyons souvent : l’appropriation du projet, l’implication concrète des dirigeants de l’organisation.

L’autre point, qui est en quelque sorte lié à cela, c’est qu’ils ne sous-traitent pas la transformation. Ils ne se contentent pas de dire, “Nous allons faire appel à de grands fournisseurs et les laisser tout gérer.” Ils disent, “Nous allons faire venir des experts, mais nous allons les gérer.” Tout comme vous géreriez un sous-traitant ou un entrepreneur général si vous engagiez quelqu’un pour construire une nouvelle usine.

Ils ne vont probablement pas se contenter de dire, “Ça nous est égal, allez construire l’usine, utilisez les meilleures pratiques, faites ce qu’il faut pour construire l’usine.” Non, ils vont s’impliquer fortement, en veillant à ce que l’usine réponde aux spécifications, etc. Mais avec les projets technologiques, beaucoup d’entreprises ne font pas cela. Ainsi, les entreprises qui réussissent traitent les investissements et transformations technologiques comme n’importe quel autre investissement en capital.

Ils ne les traitent pas différemment ; ils attendent un ROI, ils vont limiter le budget, ils vont s’impliquer fortement, et ils auront leur mot à dire sur la manière dont les choses se passent. Tout cela se passe en amont, et c’est un facteur de réussite important.

Un autre point revient à une remarque que l’un d’entre vous a faite plus tôt, à savoir les décisions prises dès le début. Je ne veux pas dire que l’exécution n’a pas d’importance, car elle en a, mais ce qui est encore plus important, ce sont les éléments qui précèdent l’exécution effective — les décisions prises, les priorités établies, l’alignement.

Obtenir l’alignement au sein de l’équipe, car souvent, lorsque nous entrons dans une salle avec, disons, sept cadres et que vous avez ici notre comité de pilotage, et si je leur demande, “Que signifie cette transformation pour l’organisation ?”, vous obtenez généralement sept réponses différentes. Et aucune d’elles n’est forcément juste ou fausse, mais chacun dit quelque chose de différent, et vous ne pouvez pas réussir.

Vous ne réussirez tout simplement pas, peu importe qui vous embauchez, peu importe dans quelle technologie vous investissez, vous ne réussirez pas si vous n’êtes pas tous sur la même longueur d’onde. C’est un processus chaotique, et en théorie, cela pourrait ralentir le projet à court terme, car maintenant vous dites, “Attendez, arrêtons la technologie, ne faisons pas cela pour l’instant, alignons-nous d’abord.”

Les gens pensent, “Eh bien, mais nous devons commencer aujourd’hui.” Vous savez, nous sommes déjà en retard, nous devons avancer, et nous dirons, “Eh bien, ralentissez, car si vous vous précipitez, vous allez simplement dévaler une falaise. Alors assurons-nous que vous ne le fassiez pas ; prenez le temps nécessaire pour vous assurer d’avoir un chemin clair, puis mettez-vous d’accord.”

Ainsi, cet alignement et le fait de prendre le temps de fixer des objectifs stratégiques, des paramètres, des priorités, le business case, les attentes, la gouvernance, de définir nos processus métier futurs — que voulons-nous que nos processus deviennent ? Quel avenir souhaitons-nous pour l’organisation ? Tout cela doit être défini en amont avant de commencer à déployer la technologie, et c’est un facteur de réussite très important.

Et enfin, le dernier point que je mentionnerai est l’investissement dans la gestion du changement. Les entreprises qui investissent massivement — et quand je dis investissent massivement, je ne veux pas nécessairement dire beaucoup d’argent. Je veux dire qu’elles investissent du temps et de l’attention dans le changement organisationnel, la communication, l’adoption, et la clarté pour l’organisation. Tout cela augmente considérablement le taux de réussite.

Joannes Vermorel: Je suis d’accord avec votre anecdote. En fait, dans le logiciel, vous savez, je suis moi-même ingénieur logiciel. Il y a un dicton qui dit, “Oh, j’ai passé trois heures à réfléchir au problème que je voulais implémenter. J’ai passé trois heures, et ça m’a coûté trois semaines d’implémentation supplémentaires.”

Mais pour revenir au cas initial, je vois beaucoup d’entreprises, vous savez, les grandes entreprises reprennent cette idée, “Oh, oui, nous devons planifier soigneusement.” Elles ont entendu ce conseil ; nous ne sommes pas les premiers à le dire. Elles le font donc, mais je constate une perversion de ce type de pensée, ce avec quoi je suis entièrement d’accord quant au fait que c’est la bonne manière. Vous devez réfléchir très clairement et prendre un peu de temps, probablement, dans cette phase qui est super critique.

Mais ce que j’ai constaté, c’est que de nombreuses grandes entreprises corrompent cette idée au sein de leur organisation en la transformant en un exercice de case à cocher ou en un exercice bureaucratique du genre, “Oh, nous sommes en phase de planification, donc j’ai besoin de ce rapport et de ce rapport et de cette validation et de cet audit et de cette mission de diagnostic et de ceci et de cela et de ceci.” Et ce à quoi vous aboutissez, ce n’est pas de la clarté ; c’est un dossier qui peut faire des milliers de pages et n’apporter aucune clarté. C’est ce que j’appelle la technocratie.

C’est cette phase de planification où vous finissez par rassembler des éléments provenant de l’organisation, et tout le monde se conforme excessivement aux demandes. Alors imaginez que vous êtes le conseil d’administration, et qu’en un mois, vos équipes ont rassemblé plusieurs milliers de pages d’évaluations, de diagnostics, etc. Et que personne n’a la moindre idée du contenu. C’est un peu comme le projet de loi omnibus sur les dépenses du Congrès aux États-Unis. C’est un document massif, de plusieurs milliers de pages, et personne ne sait vraiment ce qu’il contient.

Selon moi, il faut aussi réaliser pendant cette phase de planification que les gens ne devraient pas procéder ainsi comme à un exercice technocratique. Vous devez être capable de maintenir la clarté dans un document qui fait probablement, je dirais, entre cinq et 20 pages max. Si vous ne pouvez pas avoir quelque chose d’exprimé clairement en 20 pages maximum, idéalement moins, alors vous êtes probablement perdu dans un labyrinthe technocratique.

Votre parcours sera alors grandement dévoyé. Et je parle de pages rédigées en texte, et non de PowerPoints, car avec les PowerPoints, vous pouvez tricher avec les puces — il n’y a aucune connexion logique, ce qui rend le tout super ambigu. Si vous rédigez en anglais avec une signalisation et une connexion appropriées, alors vous ne pouvez pas tricher ; vous devez avoir quelque chose qui a du sens et un document que vous pouvez lire à haute voix. C’est en quelque sorte ma vision de ce mode de pensée.

Eric Kimberling: C’est un excellent point. Et l’équipe qui exécute le projet doit également avoir cette clarté. Vous savez, si vous pensez à une transformation de supply chain, disons que vous êtes une organisation cherchant à déployer une technologie de supply chain complète. Il est facile de se perdre dans de nombreuses complexités et détails.

Si vous le traitez comme une sorte de démocratie où chacun a un poids égal en termes de priorités, de demandes et d’attentes vis-à-vis du système, le projet va déraper. Il faut mettre en place une gouvernance pour dire, “Vous savez quoi ? Oui, nous réalisons la transformation de la supply chain, mais les achats ne sont pas notre priorité pour le moment. Au lieu de cela, c’est la gestion des fournisseurs.”

Parce que devinez quoi ? Le gouvernement des États-Unis impose tous ces tarifs maintenant, ou il y a toutes ces questions géopolitiques que nous devons gérer, donc nous avons besoin d’une meilleure gestion des fournisseurs, et c’est notre priorité. Il faut établir des priorités et dire, “Nous faisons cela parce que nous voulons revoir totalement nos processus de gestion des fournisseurs” et gérer le tout en conséquence.

Si vous n’avez pas cette clarté dans ce document de 5 à 20 pages et que vous ne parvenez pas à mettre tout le monde d’accord, alors cela va se transformer en un libre-échange où chacun demande ce qu’il pense vouloir.

Joannes Vermorel: Pour information, j’ai vu de nombreuses entreprises, et je n’ai jamais vu de documents de haute qualité, sauf des documents divulgués provenant d’entreprises tech américaines comme Amazon, Shopify, Apple — des notes de service divulguées qui sont super claires, rédigées en cinq pages, magnifiquement écrites. On peut voir que la direction comprend vraiment parfaitement où elle se trouve, où elle veut aller, etc., et qu’elle rédige de manière très claire et concise.

Lorsque vous allez dans des entreprises non technologiques, c’est extrêmement rare de voir cela. Extrêmement rare. Je ne peux en penser qu’à une dizaine d’entreprises. Berkshire Hathaway, par exemple, leurs notes de service sont absolument brillantes ; c’est d’une clarté cristalline ce qu’ils font, pourquoi, etc. Mais typiquement, pour les entreprises dont nous parlions, comme Lidl ou autres, je suis sûr à 100% que personne ne disposait d’une note simple expliquant ce que nous essayons même d’accomplir ici. Pourquoi sommes-nous convaincus que cette initiative a une quelconque chance raisonnable de réussir ?

La plupart de ces grands projets que je constate — Lokad en fait parfois partie —, vous savez, ils mettent à niveau leur ERP, ils améliorent leur supply chain analytics avec nous. C’est tout simplement si rare ; c’est pourquoi je le mentionne. Je ne vois presque jamais le moindre degré de clarté lorsqu’il s’agit de transformation digitale. C’est juste des couches sur des couches de technocratie.

Encore une fois, vous mentionniez l’externalisation — également des parties complètement extérieures à l’entreprise. Ainsi, ces documents, de milliers de pages, la moitié d’entre eux seraient fournis par des fournisseurs tiers.

Eric Kimberling: Je me demande si ce que vous dites à propos des entreprises technologiques n’est pas vraiment intéressant. Je n’en étais pas conscient, ou je n’avais pas fait cette connexion auparavant. Vous savez, peut-être que les entreprises technologiques sont plus capables et plus matures dans leur capacité à fournir cette clarté.

Mais je me demande, parfois je me demande si, vous savez, les dirigeants aujourd’hui—ça vous fait penser aux dirigeants qui ont grandi dans le domaine de la tech depuis peut-être les années 90, d’accord, peut-être qu’ils ont à peu près mon âge ou un peu plus âgés. Je me souviens que Windows 98 est sorti, et c’était un événement majeur lorsque Windows 98 a été déployé.

Cela constituait en quelque sorte une perturbation pour de nombreuses entreprises car elles devaient subir ces importantes mises à jour de Windows. Mais au final, il s’agissait d’une mise à jour de Windows ; ce n’était pas une transformation. C’était, “Nous avons besoin de nouveaux systèmes d’exploitation pour nos PC, nos postes de travail et nos ordinateurs portables.”

Je me demande si les dirigeants qui ont grandi dans le domaine de l’informatique à cette époque considèrent encore les projets technologiques comme une mise à jour de Windows 98, et s’ils ne réalisent pas qu’il ne s’agit pas d’une mise à jour de Windows 98. Il s’agit d’une refonte massive non seulement de vos systèmes back-office et de vos bases de données, mais aussi de vos processus, de votre organisation, et de tout ce qui va avec.

Ce n’est qu’une hypothèse pure. Je ne sais pas si c’est vrai ou non, mais j’essaie d’identifier la cause profonde de ce dont nous parlons ici afin de comprendre pourquoi c’est ainsi.

Joannes Vermorel: À mon avis, lorsque je regarde les plans de transformation numérique pour la plupart des entreprises non technologiques, en tant que technologue moi-même—Lokad est une entreprise de logiciels qui réalise essentiellement de la robotisation d’aide à la décision pour la supply chain—ce que je constate, c’est que ces transformations numériques me semblent extrêmement modestes.

Lorsque je pense à la transformation numérique pour ma propre entreprise, parce que ces technologies, comme vous l’avez mentionné, évoluent et que beaucoup de choses changent chez Lokad, je vois un futur dans 10 ans où peut-être plus de la moitié des emplois que nous avons disparaîtront en termes de tâches. Les personnes seront toujours là, aucun problème, mais elles feront des choses différentes.

Lorsque je regarde les entreprises non technologiques classiques—pensez à une entreprise d’aviation, une entreprise manufacturière, une entreprise de distribution, une entreprise de mode—vous savez, des entreprises pour qui la technologie n’est qu’un complément, leur transformation numérique est très, très modeste.

Il n’y a presque aucun emploi supprimé, aucune tâche éliminée d’emblée. Quand on pense à ce que des outils comme, par exemple, ChatGPT peuvent faire, on constate qu’il existe des catégories entières de tâches qui peuvent manifestement être automatisées.

Bref, à mon avis, les transformations numériques manquent très souvent d’ambition ; elles sont extrêmement modestes. La seule chose qui ne soit pas modeste est le budget dont ils disposent pour effectuer la mise à niveau.

Conor Doherty: Intervenez et construisez à partir de cela car je pense qu’en arrière-plan, c’est un peu comme ouvrir des boucles. Si l’on revient à la toute première boucle, à la pensée fondamentale en termes de mentalité et de la manière dont nous encadrons même le problème pour revenir à la réalité, le problème que nous essayons de résoudre. Joannes, je m’adresse d’abord à toi puis à Eric pour un commentaire.

Joannes, j’ai effectivement évoqué en arrière-plan quelque chose qu’Eric a mentionné plus tôt à propos du capex contre l’opex, ce qui m’a rappelé une conférence que tu avais donnée sur la livraison orientée produit pour la supply chain dans laquelle tu argumentais que la supply chain n’est pas une supply chain opex. Elle devrait être reclassée en tant que capex traitée comme un actif, et il me semble que le simple fait d’envisager ce problème, c’est-à-dire de ne pas le considérer comme une supply chain et tous ses coûts associés comme, eh bien, comme des biscuits ou des stylos, des choses dont j’ai juste besoin pour passer la journée, et de le traiter davantage comme un actif pouvant croître et prendre de la valeur, pourrait être une manière plus utile de lancer la discussion dès le départ, que ce soit pour embaucher des personnes ou pour trouver des logiciels. Peux-tu peut-être développer un peu cette distinction ?

Joannes Vermorel: Oui, enfin, c’est mon point de vue personnel. Quand je regarde les emplois de cols blancs, à moins qu’il n’y ait quelque chose de vraiment spécial à leur sujet, je pense qu’il s’agit simplement de ce que l’entreprise doit payer pour obtenir un certain résultat en termes de transformation de l’information. Un salarié de bureau prend fondamentalement de l’information en entrée et produit de l’information en sortie qui peut prendre diverses formes. Mais beaucoup de personnes, surtout en back office, font exactement cela dans les grandes entreprises. Dans la supply chain, par exemple, vous avez des personnes qui récupèrent les niveaux de stocks pour leur ERP ainsi que de nombreux indicateurs des ventes récentes, et que décident-elles ? Pour chaque SKU, unité de gestion de stock, elles se disent : “Dois-je repasser commande, oui ou non ?” J’ai mille SKUs à gérer. L’organisation est répartie de telle sorte qu’un supply and demand planner gère, disons, 1 000 SKUs. Nous avons 80 000 SKUs au total, donc cela représente 80 supply and demand planners, et chacun d’eux passe en revue 1 000 SKUs chaque jour et émet l’ordre de réapprovisionnement du jour. Beaucoup d’entreprises sont organisées exactement de cette façon.

Donc, à mon avis, quand on considère sa pratique supply chain de cette manière, les personnes que vous avez représentent du pur opex. Vous devez payer ces salaires chaque jour afin que votre entreprise ne cesse pas de fonctionner. Si vous arrêtiez de payer ces personnes, l’entreprise s’arrêterait, le flux de marchandises serait interrompu. Si l’approche de Lokad consiste à dire, “Non, nous devrions considérer la pratique supply chain comme quelque chose de capex. Nous avons des personnes qui conçoivent des logiciels, d’une manière ou d’une autre. Il y a plein de méthodes ; low code, il n’est pas nécessaire de coder, mais vous concevez des logiciels qui génèrent automatiquement ces décisions de réapprovisionnement.”

Et puis, si vous devez payer une personne de plus, c’est pour améliorer le système. Dans ce cas, votre investissement est en capex. Vous disposez de ce logiciel qui fonctionne automatiquement, et vous avez de l’opex, mais c’est uniquement pour le logiciel, donc les dépenses sont très faibles. Et lorsque vous dépensez de l’argent pour les personnes, c’est pour améliorer le système, et ainsi c’est très capitalistique. C’est cumulatif ; c’est comme un actif devrait l’être. Oui, il devient un actif. Ainsi, votre investissement dans les personnes devient un actif ; le travail de ces personnes constitue un actif tangible pour votre entreprise, matérialisé par ce système d’aide à la décision.

Ce que je constate en ce qui concerne ces transformations numériques modernes, c’est qu’elles semblent extrêmement modestes dans le sens où il existe des tonnes d’emplois de cols blancs, purement opex, qui devraient devenir capex. Quand les gens travaillent une heure, ils produisent quelque chose de cumulatif, quelque chose qui crée un actif d’une certaine sorte, probablement un logiciel, mais cela peut être autre chose ayant de la valeur pour l’entreprise, indépendamment du travail continu des personnes. Cela peut paraître un peu étrange, mais c’est comme si ces personnes concevaient la machine, et ensuite, on pouvait faire fonctionner la machine indéfiniment. Je simplifie, évidemment ; ces machines nécessitent de la maintenance et autres, mais la plupart des transformations numériques que je vois sont extrêmement modestes parce qu’elles ne tiennent compte que de ces personnes utilisées comme opex, purement consommables. J’ai besoin de faire appel à ces personnes encore et encore.

Je parle ici de tâches purement informationnelles, et non de retourner des burgers dans un restaurant. Pour cela, il faut des mains. Nous n’avons pas encore de robots capables de retourner des burgers. Mais je parle de tout ce qui relève d’un emploi de cols blancs en back office. Pour moi, la plupart des transformations numériques abordent à peine le fait que ces tâches devraient être, pour la plupart, entièrement robotisées en back office, de sorte que nous ne soyons même pas en contact avec les clients. Il s’agit d’un simple travail administratif interne et, pourtant, pour de grandes entreprises, cela peut représenter facilement les deux tiers de la main-d’œuvre de cols blancs affectés au back office. Très fréquemment, je constate que ces transformations numériques ne font même pas effleurer la surface lorsqu’il s’agit de transformer cet énorme montant d’opex en capex, mais c’est là mon point de vue personnel.

Eric Kimberling: Vous touchez là un point vraiment intéressant et un défi plus grand, je pense, dans l’industrie technologique, et plus généralement dans le secteur des technologies d’entreprise. Vous avez beaucoup parlé de capex et d’opex et du fait de traiter l’IT comme un actif, mais si l’on observe la direction prise par les fournisseurs de technologie, ils tendent vers un modèle dans lequel ce n’est plus un actif pour leurs clients ; c’est un actif pour le fournisseur. Et cela a toujours été le cas, évidemment ; c’est leur produit, c’est leur propriété intellectuelle. Mais ce qui se passe, c’est que nous passons de l’on-premise, où, vous savez, vous investissez, vous réalisez cet investissement en capital, vous adaptez le logiciel à vos processus et ce genre de choses, et cela devient un actif que vous amortissez, à une réalité différente de celle vers laquelle nous nous dirigeons maintenant, c’est-à-dire que nous allons tout migrer vers le cloud. Toutes nos données sont dans le cloud. Désormais, on passe du capex à l’opex, et ce n’est pas simplement une décision comptable de savoir s’il s’agit de capex ou d’opex.

C’est un changement de mentalité car ce qui se passe maintenant, comme avec l’IA par exemple, c’est que ces grands fournisseurs de technologie disent, “Hé, nous avons cette technologie d’IA qui peut apporter une valeur magnifique à votre organisation.” Et cela peut être vrai, mais ce qui se passe dans le processus, c’est que nous prenons nos données, notre propriété intellectuelle au sein de l’entreprise, et nous les utilisons pour entraîner ces modèles d’IA utilisés par d’autres concurrents et d’autres entreprises. Désormais, le centre de pouvoir se déplace des clients vers les fournisseurs, car maintenant les fournisseurs ne possèdent plus les données, mais ils possèdent l’IA et la technologie qui utilise vos données pour l’entraîner afin d’en faire un meilleur outil d’IA à vendre à d’autres entreprises.

C’est donc important. C’est une question vraiment cruciale à considérer, de se demander : qu’est-ce que l’IT pour nous ? Est-ce une commodité que nous voulons simplement sortir du bilan, retirer de nos opérations parce que nous ne voulons tout simplement pas nous en occuper ? Peut-être. Cela pourrait convenir à certaines organisations. Mais vous avez mentionné Amazon et Spotify. Je suis certain qu’Amazon et Spotify ne considèrent pas l’IT comme une simple commodité que quelqu’un d’autre pourrait gérer. C’est un avantage concurrentiel important, et nous ne devons pas tous aspirer à être Amazon ou Spotify, mais nous pouvons aspirer à dire, “Par exemple, si notre force concurrentielle est que nous avons une supply chain vraiment efficace, nous pouvons livrer des produits aux clients plus rapidement que quiconque, et nous pouvons personnaliser nos produits rapidement pour les acheminer à nos clients. D’accord, c’est votre avantage concurrentiel. Maintenant, construisons une technologie qui vous est unique afin de rendre cet avantage difficile à reproduire. Si je me contente d’une solution cloud standard que n’importe qui peut acheter, alors j’ai perdu mon avantage.”

Ainsi, l’ensemble de ce mouvement vers la standardisation des processus dans le cloud, en utilisant les données pour entraîner des modèles d’IA au bénéfice des autres, est en train d’évoluer. Je pense qu’il s’agit d’une tendance très dangereuse qui va causer beaucoup de regrets aux organisations pendant des années à venir. Il me semble donc important de s’arrêter et de réfléchir. Si nous voulons que l’IT soit un actif stratégique qui nous différencie, traitons le projet comme tel. Cela signifie probablement que nous n’adoptons pas une technologie standardisée prête à l’emploi dans le cloud. Peut-être opterons-nous pour une solution sur mesure plus adaptée, même si c’est un terme tabou et qu’on ne devrait pas parler de personnalisation, qu’on ne devrait pas parler de développement sur mesure. Cela pourrait être la bonne solution pour vous si vous considérez l’IT comme un avantage stratégique.

Joannes Vermorel: Avantage, oui, et je tiens également à souligner que de nombreux fournisseurs ont des incitations absolument déplorables. Encore une fois, la grande majorité des fournisseurs de logiciels d’entreprise facturent par siège. Donc, lorsque vous facturez par siège, vous ne cherchez définitivement pas à améliorer la productivité. Si vous pouvez rendre votre logiciel moins efficace ou moins productif, alors vous aurez plus de sièges.

Vous voyez, c’est—je veux dire, évidemment, les fournisseurs de logiciels d’entreprise ne sont pas, vous savez, malveillants. La plupart des employés sont simplement de bonnes personnes, comme 90 % de la population. Ils n’essaient pas d’aggraver leur produit simplement pour obtenir plus de sièges, mais malgré tout, la puissance des incitations est extrêmement importante.

Cela signifie que, par exemple, s’il existe un modèle pour le fournisseur de logiciels nécessitant que des tonnes de personnes fassent fonctionner le logiciel, cela se traduira ainsi… Lorsque le PDG de la société de logiciels examine ses propres ventes, il se dit, “Oh, regardez, il y a tellement d’adhésion ici.” Oui, oui, car dans ce domaine, nous avons besoin de tant de personnes interagissant avec le logiciel, et cela génère le chiffre d’affaires.

Et soudainement, cela devient très compliqué. Voulez-vous vraiment vous lancer le défi en tant que fournisseur de logiciels si vous facturez par siège dans un contexte où votre prochaine mise à niveau pourrait éliminer 90 % de vos sièges ? C’est—c’est une question très, très difficile. C’est une question très difficile. Soit dit en passant, historiquement, cela est déjà arrivé à IBM. IBM facturait par MIPS, des millions d’instructions par seconde—c’est ce qu’ils faisaient dans les années 80 et 90. Et devinez quoi ? Lorsque IBM facturait par MIPS, leur logiciel devenait de plus en plus lent à chaque génération, évidemment.

Eric Kimberling: Oui, je veux dire, vous soulevez vraiment—un autre sujet sur lequel nous pourrions consacrer un épisode entier, à savoir les attentes mal alignées ou les incitations mal alignées. Vous savez, si votre fournisseur de logiciels et votre intégrateur système, et, vous savez, il y a trois parties, trois parties principales, si les trois ont des incitations très différentes et conflictuelles, alors il est difficile de surmonter cela.

Conor Doherty: Désolé d’interrompre, mais je suis conscient du temps d’Eric. Vous avez été très aimable de rester avec nous, alors je vais—du moins, nous pourrons y revenir et parler de l’éthique des actions de chacun. Mais pour aujourd’hui, je vais passer à une réflexion finale. Je commence avec vous, Joannes, sur une note positive à nouveau. Quel conseil donneriez-vous aux organisations malgré tout ce dont nous avons parlé ou en tenant compte de tout ce que nous avons dit ? Quel conseil donneriez-vous aux organisations qui s’apprêtent à débuter leur transformation numérique ?

Joannes Vermorel: En tant que passionné de logiciels depuis quatre décennies—j’étais même passionné, vous savez, il y a quelque temps pour les logiciels, même si c’était surtout des jeux vidéo quand j’étais très jeune—en tant que passionné de logiciels à vie, je dirais qu’il n’y a jamais eu de période où les technologies logicielles promettaient autant. C’est tout simplement incroyable pour moi—la révolution du deep learning, son descendant avec les LLM et tout le reste. C’est presque magique, vous savez, l’idée de pouvoir disposer de quelque chose capable de traiter le langage naturel pour accomplir de nombreuses choses.

C’est absolument incroyable, et ces technologies sont facilement accessibles. Elles ne sont pas nécessairement bon marché, mais elles sont facilement accessibles. Je dirais donc qu’il n’y a jamais eu de période où vous pouviez attendre plus d’une transformation digitale. Je pense qu’actuellement, si vous pensez à cette transformation digitale, elle promet de vraiment transformer votre entreprise en une bête complètement différente qui offre tellement plus à vos clients sous bien des aspects. Elle peut offrir un meilleur service à vos clients, une opération plus intelligente. Vous l’appelez comme vous voulez; son potentiel est absolument immense.

Donc, je dirais, rêvez grand, puis dépensez de façon réfléchie et progressive sur des éléments qui ne ressemblent pas à des méga-projets à cause du risque — tel serait mon message pour la transformation digitale. Vous devez vous mettre dans une position où vous pouvez échouer rapidement, car, en tant que fournisseur de logiciels, je peux vous dire que si vous demandez à un client, “Pouvez-vous me donner une estimation vraiment catastrophique de ce qui se passera au cours des six prochains mois ?” Six mois, je peux peut-être faire cela. Oui, un an commence à se compliquer; deux ans, c’est vraiment compliqué, compliqué, car j’ai la possibilité de voir des rotations de personnel. Cela pourrait être aussi perturbant qu’un projet de deux ans à gérer, c’est très difficile.

Cinq ans — oh mon Dieu, c’est comme si nous essayions de concevoir l’Étoile de la Mort. Donc, selon moi, oui, la transformation digitale a un potentiel énorme. C’est excellent, ce n’est pas si onéreux, alors vous devriez essayer au lieu de penser que nous devons nous assurer que cela fonctionne. Je dirais faites le contraire : commencez par des projets de petite envergure, réalisez-les rapidement et échouez rapidement, afin que, si cela échoue, vous puissiez reconnaître sans équivoque que c’est un coût irrécupérable et passer à autre chose, au lieu de doubler, tripler l’investissement, ce qui est exactement la recette des fournisseurs de logiciels d’entreprise qui finissent par faire dépenser à leurs clients dix fois plus que ce qui avait été initialement prévu.

Vous devez être capable de dire, “Non, nous arrêtons. Nous avons essayé, nous avons vu, c’est fini. Nous allons essayer autre chose parce que le monde est vaste. Nous avons tellement de potentiel ; nous n’avons absolument pas besoin de nous en tenir au plan initial. Il est acceptable d’échouer sur une initiative après trois mois. Il ne l’est tout simplement pas après trois ans.”

Eric Kimberling: Après avoir déjà dépensé des milliards ou des centaines de millions de dollars.

Joannes Vermorel: Oui, oui.

Conor Doherty: Eh bien, Eric, il est de coutume ici de laisser le dernier mot aux invités, alors encore une fois, même question : avez-vous un conseil à partager pour les personnes ou les entreprises qui s’apprêtent à commencer leur parcours ?

Eric Kimberling: Eh bien, je veux dire, c’était un excellent conseil que vous venez de donner. J’ajouterais peut-être qu’investissez dans—investissez dans la gestion du changement. Assurez-vous de consacrer du temps à la gestion du changement pour réduire la probabilité que vous ayez même besoin d’échouer rapidement. Mais je suis d’accord, vous voulez échouer rapidement, et c’est pourquoi je pense que commencer petit, commencer lentement, puis accélérer est bien plus efficace que de démarrer trop vite et trop grand pour ensuite devoir ralentir. Cela crée tout simplement beaucoup de problèmes de moral, beaucoup d’incertitude et de doute dans l’organisation.

Alors, oui, échouez rapidement, mais investissez également dans le changement organisationnel. Et l’autre chose que je dirais est de prendre votre temps dès le départ, car ces premiers mois d’un projet, avant même de commencer à implémenter la technologie, déterminent la trajectoire. Je veux dire, vous établissez la vision, les paramètres, la direction du projet. Assurez-vous donc de bien réussir cette étape. Sinon, si vous doutez de posséder cette clarté, prenez le temps de bien la définir.

Car plus vous consacrez de temps dès le départ à bien préparer cette étape, plus le projet avancera rapidement dans l’ensemble. En fait, vous allez implémenter beaucoup plus vite et économiser beaucoup de temps et d’argent si vous ralentissez dès le début. Vous pourrez toujours accélérer plus tard, mais commencez lentement. Voilà mon dernier conseil de clôture.

Conor Doherty: Je n’ai pas d’autres questions. Merci beaucoup pour votre temps, Eric, c’est très apprécié.

Eric Kimberling: Excellente conversation, beaucoup de plaisir aussi, j’ai vraiment apprécié.

Conor Doherty: Alors, Joannes, je n’ai rien d’autre à dire à part un grand merci pour votre temps, Eric, encore une fois. Merci beaucoup pour le vôtre, et merci à tous de nous avoir suivis. On se voit la prochaine fois.