00:00:03 Introduction à la modularisation dans les systèmes informatiques et les supply chains.
00:00:26 Modularité de la chaîne d’approvisionnement physique.
00:02:31 Structures monolithiques des premiers systèmes informatiques.
00:04:08 Contexte informatique des systèmes monolithiques.
00:05:31 Impact d’Internet sur la conception modulaire des logiciels.
00:08:02 Problèmes des systèmes logiciels monolithiques.
00:08:48 Inefficacités des systèmes monolithiques.
00:11:16 Passage à des systèmes modulaires : exemples.
00:13:34 Défaillances du système dans les applications modulaires.
00:14:34 Redondance, disponibilité dans les systèmes modulaires.
00:16:00 Fiabilité des grands systèmes, échecs de projets logiciels.
00:16:50 Exemple de transition logicielle ratée chez Lidl.
00:18:09 Concept de “fail fast” dans les projets logiciels.
00:19:30 Gestion des chevauchements, importance des logiciels “colle”.
00:22:46 Éviter les catastrophes logicielles.
Résumé
Dans l’épisode de Lokad TV, Joannes Vermorel, le fondateur de Lokad, discute de l’importance de la modularisation dans l’infrastructure informatique des entreprises, en faisant une comparaison avec l’adaptabilité des chaînes d’approvisionnement. Il fait référence aux systèmes informatiques monolithiques des années 70 et 80, caractérisés par leur inflexibilité due aux limitations technologiques. Même avec le passage à des systèmes en réseau suite à l’émergence d’Internet, il souligne le défi permanent pour les entreprises de modulariser leurs systèmes informatiques. Vermorel propose l’architecture orientée services (SOA) comme solution potentielle, en insistant sur la nécessité de services plus petits et bien définis. Il met en garde contre la réalisation de projets à grande échelle et préconise une approche “fail fast”, en soulignant l’importance de la gestion des risques et de la récupération rapide en cas de défaillances.
Résumé étendu
Dans l’épisode actuel de Lokad TV, l’animateur Kieran Chandler engage Joannes Vermorel, le fondateur de Lokad, dans une discussion sur la modularisation de l’infrastructure informatique des entreprises. Vermorel expose le concept de modularisation, en établissant principalement des parallèles avec les chaînes d’approvisionnement dans le monde physique, qu’il considère comme les créations les plus modulaires de l’humanité.
Il utilise les exemples des camions, des palettes et des conteneurs pour clarifier ses points sur la modularité. Vermorel met l’accent sur la modularité inhérente des chaînes d’approvisionnement physiques en soulignant l’applicabilité universelle des codes-barres, qui peuvent être attachés à pratiquement n’importe quoi.
Bien que les chaînes d’approvisionnement physiques présentent une modularité claire, Vermorel observe que les infrastructures informatiques des entreprises manquent souvent de flexibilité similaire. Il attribue ce manque de modularité aux premières étapes du développement informatique au sein des entreprises dans les années 1970 et 1980, lorsque les premières mises en œuvre informatiques et les systèmes ERP ont été conçus comme des structures autonomes et monolithiques en raison des limitations technologiques de l’époque.
Vermorel identifie un “monolithe” dans les termes informatiques comme une application unifiée qui ne peut pas être décomposée en parties plus petites. Il explique comment cette approche monolithique contraste avec la modularité observée dans les chaînes d’approvisionnement physiques, où divers composants peuvent être combinés ou séparés selon les besoins.
Malgré leur complexité, Vermorel explique que les premiers mainframes étaient intrinsèquement cohérents car ils fonctionnaient comme une unité unique avec toutes les opérations centralisées. Il note comment cette forme de conception de système semble dépassée pour la génération actuelle habituée aux systèmes distribués et aux applications basées sur le réseau, marquant un changement significatif dans le développement de l’infrastructure informatique au fil des ans.
Vermorel souligne que le paysage a commencé à changer avec l’avènement d’Internet à la fin des années 90, ce qui a conduit à la conception de logiciels avec des parties isolées connectées par un réseau. Cependant, il remarque que de nombreuses entreprises ont encore du mal avec la modularisation, malgré la valeur des systèmes informatiques modulaires étant bien comprise en théorie.
Il explique comment de nombreux fournisseurs ont adapté ces anciennes architectures monolithiques aux modèles de cloud et de Software as a Service (SaaS), ce qui donne des systèmes offrant une maintenance améliorée mais n’améliorant pas la modularité. Il affirme que ce manque de modularité empêche les entreprises d’isoler et de modifier des fonctionnalités spécifiques.
Pour surmonter ce problème, Vermorel propose une architecture orientée services (SOA), une approche qui décompose les capacités en “morceaux” plus petits et bien définis. Il cite Amazon comme exemple d’une entreprise qui a adopté avec succès cette approche modulaire dès le début.
Il plaide en faveur d’une architecture orientée services avec des API qui permettent d’exporter et d’exploiter des données dans différentes divisions d’une entreprise. Tout en reconnaissant qu’une approche décentralisée présente un potentiel de plus de points de défaillance par rapport à un système monolithique, Vermorel soutient que ces défis peuvent être atténués grâce à la redondance et à l’ingénierie de haute qualité.
Vermorel estime qu’entre un tiers et la moitié de tous les projets informatiques de chaîne d’approvisionnement échouent. Il fait référence au cas de Lidl en Allemagne, qui a perdu un demi-milliard d’euros lors d’une transition SAP ratée. Il soutient que passer de petits fournisseurs à de grands fournisseurs réduit légèrement les taux d’échec, mais ne les élimine pas.
En ce qui concerne la gestion de plusieurs applications, Vermorel suggère de choisir des applications ayant un champ d’application étroit pour minimiser les chevauchements et déconseille d’acheter de grands frameworks auprès des fournisseurs. Pour gérer efficacement plusieurs applications, il déclare que les entreprises devraient développer une “colle” interne qui lie ces applications ensemble, facilitée par une architecture orientée services.
Enfin, Vermorel donne des conseils sur la façon de prévenir les catastrophes telles que la transition SAP ratée de Lidl. Il insiste sur la réflexion en termes de gestion des risques et l’adoption d’une approche “échouer rapidement”. Il déconseille de penser de manière utopique dans la gestion de projet et souligne l’importance de planifier les éventuelles défaillances et de trouver des moyens de récupérer rapidement.
Transcription complète
Kieran Chandler: Bonjour et bienvenue dans un nouvel épisode de Lokad TV. Cette semaine, nous allons discuter de la modularisation, c’est-à-dire du processus de subdivision des processus informatiques de notre entreprise à partir d’un système autonome vers un certain nombre de sous-programmes ou même d’applications. Comme toujours, je suis accompagné de Joannes Vermorel. Alors, Joannes, de quels processus de l’entreprise parlons-nous aujourd’hui pour les rendre plus modulaires ?
Joannes Vermorel: Aujourd’hui, nous nous concentrons particulièrement sur l’infrastructure informatique et le paysage applicatif de votre entreprise. La modularisation est intéressante. Lorsque vous pensez au monde physique, il est évident que les chaînes d’approvisionnement sont incroyablement modulaires. Ce sont probablement les choses les plus modulaires jamais inventées par l’humanité. Par modulaire, je veux dire que si vous voulez transporter des marchandises par la route, vous pouvez utiliser des camions. Les camions sont incroyablement modulaires car vous pouvez y mettre à peu près n’importe quoi qui ne dépasse pas la capacité d’un camion, et un camion peut circuler sur n’importe quelle route, allant de n’importe où à n’importe où ailleurs. Si vous avez besoin de camions supplémentaires, vous pouvez utiliser à peu près n’importe quel type de camion, presque, et ils peuvent ajouter de la capacité de transport à votre chaîne d’approvisionnement.
La même chose s’applique aux palettes et aux conteneurs. Vous pouvez mettre presque n’importe quoi sur une palette ou dans un conteneur tant que cela ne dépasse pas la capacité. Un conteneur est extrêmement modulaire. Vous pouvez le déplacer d’un navire cargo à un camion. Toutes ces pièces sont incroyablement modulaires. Vous pouvez mettre un code-barres sur à peu près n’importe quoi qui n’est pas trop petit. C’est une invention incroyablement moderne. Si vous avez quelque chose comme un diamant, vous le mettriez probablement dans une boîte, puis vous mettriez le code-barres sur le dessus de la boîte. Vous pouvez combiner tous ces éléments simples à volonté, de manière presque infinie. C’est très semblable à Lego ; des pièces simples que vous pouvez combiner de manière incroyablement variée. C’est la chaîne d’approvisionnement physique, qui est incroyablement modulaire.
Cependant, ce qui est intéressant, c’est que lorsque vous passez au monde informatique, nous entrons dans une perspective complètement différente et où la modularisation est souvent perdue. Je pense que l’origine de cela remonte au début des années 70 ou 80, lorsque les entreprises ont commencé à avoir leurs premiers systèmes informatiques et leurs premières mises en œuvre ERP.
Kieran Chandler: Donc, ce que vous dites, c’est que ces premières mises en œuvre, ces premiers systèmes informatiques, parce qu’ils étaient très orientés vers une approche unique, c’est encore ce que nous utilisons aujourd’hui. C’est bien ça que vous voulez dire ?
Joannes Vermorel: Oui, en effet. Lorsque vous pensez à l’informatique ou aux logiciels des années 70, 80 ou même du début des années 90, faire quoi que ce soit sur le réseau était comme une science-fiction. C’était possible, mais c’était un cauchemar d’ingénierie. Il était beaucoup plus facile de dire que nous prenons une grosse machine, idéalement un mainframe IBM de l’époque, et de mettre toute votre logique sur cette machine. Ensuite, tout le monde utilise un terminal connecté à cette machine, et toute la logique s’exécute dans un monolithe sur cette machine.
Kieran Chandler: Donc, que voulez-vous dire par monolithe ?
Joannes Vermorel: Par monolithe, je veux dire qu’il s’agit d’une application qui est un tout. Elle ne peut pas être démontée. Elle doit être ensemble ou ce n’est rien.
Kieran Chandler: J’ai bien peur d’être un peu un millénaire, donc cette idée pourrait me précéder un peu. Mais en gros, ce que nous disons, c’est que tout est connecté à une seule machine, c’est ça ? Et ensuite, nous sommes tous connectés et nous travaillons tous à partir de là ?
Joannes Vermorel: Exactement. Les mainframes étaient des choses relativement complexes sur le plan matériel, même s’il ne s’agissait que d’une seule machine.
Kieran Chandler: Nous parlons principalement des ERP, c’est-à-dire des systèmes de gestion des ressources de l’entreprise. Ces systèmes sont généralement conçus pour être extensibles, permettant l’ajout de fonctionnalités supplémentaires. Cependant, ils ne sont pas modulaires, ce qui signifie que vous ne pouvez pas séparer ces fonctionnalités pour les maintenir complètement isolées.
Joannes Vermorel: Ce qui est intéressant, c’est ce qui a vraiment changé, c’est probablement Internet. Je ne parle pas de l’invention d’Internet, mais du fait qu’à la fin des années 90, avec l’Internet devenant très populaire, les gens ont commencé à réfléchir à la manière de concevoir des logiciels de sorte que vous preniez les parties de manière isolée, avec le réseau au milieu. De cette façon, le flux de travail n’est pas un cauchemar d’ingénierie. Avant cela, si vous ne saviez pas comment construire un système logiciel complexe composé de nombreuses parties, avoir un réseau au milieu était un cauchemar d’ingénierie. Ce savoir-faire, cette culture et ces outils ont principalement émergé en tant que sous-produit de l’adoption d’Internet par le grand public.
Kieran Chandler: Internet existe depuis longtemps maintenant, alors pourquoi parlons-nous encore de modularisation ? Pourquoi ces logiciels continuent-ils d’agir de cette manière unique ?
Joannes Vermorel: À l’heure actuelle, mon diagnostic est que lorsque vous prenez une entreprise moyenne qui exploite une chaîne d’approvisionnement complexe ou une multinationale avec de nombreux sites, tout ce qui est physique est incroyablement modulaire. Cependant, lorsque nous commençons à regarder l’informatique, c’est complètement monolithique. Je crois que les entreprises et le marché en général ont encore du mal à apprécier la valeur d’avoir quelque chose d’extrêmement modulaire en termes d’informatique. Physiquement, c’est assez évident, et les chaînes d’approvisionnement continuent d’améliorer leur modularité. Cependant, en termes de paysage applicatif, c’est plus abstrait, plus difficile de percevoir la modularité en tant que telle.
De nombreux fournisseurs ont pris d’anciennes architectures monolithiques, les ont légèrement améliorées vers le SaaS et le cloud, mais les ont simplement copiées et collées. C’est fondamentalement le même type d’architecture que vous aviez dans un mainframe IBM dans les années 90, où vous avez simplement décidé que au lieu d’avoir une machine au siège de votre entreprise qui exécute le système, vous le déléguez à un fournisseur de logiciels qui fonctionne en tant que SaaS. Mais si le fournisseur de SaaS n’a qu’un monolithe qu’il exécute sur une machine qui est loin de votre siège, avec juste un peu de mise en réseau et une interface utilisateur web au milieu, cela n’apporte rien en termes de modernisation. Cela rend simplement la maintenance plus facile. Mais lorsque vous voulez séparer les fonctionnalités, vous êtes toujours confronté à un monolithe où ce genre de capacités ne peut pas se produire.
Kieran Chandler: Quel est le problème avec cette approche monolithique ? Comment cela affecte-t-il les entreprises dans le monde réel ?
Joannes Vermorel: Imaginez l’équivalent physique du manque de modularité. Imaginez que dans votre chaîne d’approvisionnement, chaque fois que vous voulez changer un camion, vous devez tous les changer. Par exemple, si vous passez d’un camion à un autre, vous avez besoin d’un type de carburant différent. Donc, toutes vos stations-service devraient être changées, ce qui signifie que vous avez des réservoirs contenant du carburant où vous avez besoin d’un deuxième type de carburant. Ce serait immense.
La douleur, vous voyez, est comparable à la situation dans les logiciels. Lorsque vous manquez de modernisation, c’est comme si vous changez une partie, vous devez tout changer. Si vous changez un camion, vous devez changer toute votre flotte. Imaginez si vous changez les étagères d’un entrepôt et que vous devez changer toutes les étagères de tous les autres entrepôts, sinon ce n’est pas compatible. Ensuite, vous réalisez, d’accord, peut-être que je peux décider de mettre à niveau ma flotte de camions vers des camions électriques, mais cela va être un mouvement stratégique massif et c’est très compliqué. Vous préféreriez toujours avoir quelque chose de relativement modulaire où vous pouvez avoir des camions électriques et des camions à combustion coexistant harmonieusement pendant une longue période. Lorsque vous manquez de modernisation, cela signifie que vous ne pouvez pas avoir ce genre de coexistence. Vous ne pouvez pas changer certaines parties de votre chaîne d’approvisionnement sans tout changer.
La preuve anecdotique la plus fréquente de ce manque de modernisation est que pour les entreprises qui déménagent d’un entrepôt à un autre physiquement, cela pourrait être fait en une journée où vous déplacez simplement les articles qui se trouvent dans un entrepôt des étagères de l’entrepôt A aux étagères de l’entrepôt B. Mais pour migrer le logiciel qui était connecté à l’entrepôt A afin que tout le monde sache que tous les articles se trouvent dans le système qui pilote l’entrepôt B, cela prendrait environ six mois.
Kieran Chandler: C’est intéressant. Comment les grandes entreprises font-elles cela si elles fonctionnent sur ce genre de système monolithique ? Comment migrent-elles vers un système plus modulaire ?
Joannes Vermorel: Je pense que nous allons revenir à l’une des entreprises que nous avons mentionnées dans presque tous les épisodes, comme Amazon. Ils ne sont pas les seuls à avoir adopté une approche extrêmement modulaire. En Allemagne, Zalando, vous pouvez suivre sur les blogs, ont également pleinement adopté une approche très modulaire et le mot-clé en informatique pour cela lorsque vous voulez avoir cette modularité est probablement l’architecture orientée services, SOA.
L’architecture orientée services signifie essentiellement que vous voulez isoler les fonctionnalités en morceaux qui sont eux-mêmes comme de petits monolithes, mais beaucoup plus petits, et qu’ils sont très bien délimités pour faire une chose et la faire bien. Et vous connectez toutes ces choses ensemble grâce à votre architecture orientée services, ce qui signifie que chaque service individuel, dans le sens où c’est une application qui fait une chose et la fait bien, expose des API afin qu’il puisse être facilement intégré dans votre paysage d’applications. Il est conçu pour être facilement intégrable de manière programmatique dans n’importe quel paysage d’applications arbitraire sans faire presque aucune hypothèse sur les autres parties du paysage d’applications.
Jeff Bezos d’Amazon a publié une note très célèbre, je crois en 2002, où il a dit à toutes ses équipes que chaque division doit avoir une architecture orientée services avec des API, de sorte que les données que vous avez dans votre silo puissent être exportées pour être exploitées dans n’importe quelle autre division de l’entreprise et nous pouvons interagir de manière programmatique avec ce que vous construisez.
Kieran Chandler: Le problème que je vois avec cela, c’est que vous devenez dépendant de beaucoup plus petites applications, de programmes plus petits, de sociétés plus petites en fin de compte. Cela n’introduit-il pas beaucoup plus de points de défaillance ? Alors que si vous adoptez une approche plus monolithique, vous avez une grande entreprise solide, un grand système ERP qui fonctionnera toujours et vous avez plus confiance en lui.
Joannes Vermorel: C’est vrai, et dans une certaine mesure, c’est l’un des défis d’un système distribué. Si votre matériel tombe en panne 1% du temps, cela signifie que si vous avez un ordinateur central.
Kieran Chandler: Vous avez mentionné que le logiciel peut tomber en panne trois fois par an. Si vous avez 10 applications, chacune ayant une chance de 1% d’être en panne un jour donné, cela signifie qu’environ tous les 10 jours quelque chose est en panne dans votre réseau. C’est en effet un défi. Quelles solutions suggérez-vous pour cette situation ?
Joannes Vermorel: La redondance est la première chose qui me vient à l’esprit, mais j’aimerais discuter des implications en termes d’informatique distribuée, et peut-être ensuite nous pourrons parler des petites et grandes entreprises et de la disparité entre les fournisseurs. Du point de vue de l’informatique distribuée, l’objectif est de s’assurer que chaque bloc est hautement redondant. C’est l’essence même du cloud computing. Vous voulez avoir un logiciel fortement redondant pour que votre temps de disponibilité soit très élevé.
La bonne nouvelle, c’est que parce que vos applications sont plus petites et plus simples, il est beaucoup plus facile d’obtenir un temps de disponibilité très élevé avec une petite application simple qu’avec une application très complexe. Il existe de nombreux services composants sur Internet qui sont littéralement toujours en ligne. Par exemple, Google Mail est littéralement toujours en ligne. Le site web de Yahoo est pratiquement toujours en ligne. Facebook est également toujours en ligne. Il est donc possible de concevoir ces propriétés “toujours en ligne” pour vos applications, ce qui garantit la fiabilité de votre système dans son ensemble.
Kieran Chandler: Et qu’en est-il de la transition d’un grand fournisseur à de nombreux petits fournisseurs ?
Joannes Vermorel: La réalité est que les taux d’échec des logiciels sont élevés. Les gens ne réalisent pas que peut-être la moitié du temps, les initiatives logicielles échouent. Je dirais que entre un tiers et la moitié de tous les projets informatiques de la chaîne d’approvisionnement échouent pour des entreprises de presque toutes tailles. Il y a quelques semaines, Lidl en Allemagne a dépensé près d’un demi-milliard d’euros pour une transition SAP qui a échoué. C’était un projet de sept ans qui s’est soldé par un échec, et ils ont finalement abandonné. Mais ce n’est pas le seul exemple ; cela arrive assez fréquemment.
Les grands fournisseurs ont probablement un meilleur taux de réussite, mais si nous parlons de chiffres approximatifs, nous passons d’un petit fournisseur avec un taux d’échec de 50%, ce qui est assez mauvais, à un grand fournisseur avec un taux d’échec de 30%. Donc, lorsque vous passez d’une petite à une grande entreprise, votre risque diminue légèrement, mais seulement un peu.
Si vous optez pour une approche hautement modulaire, oui, vous aurez beaucoup de choses qui échoueront, mais vous aurez l’opportunité de réessayer et de répéter jusqu’à ce que vous réussissiez. Chaque composant a une chance d’échouer, mais parce que la portée est plus simple, l’application elle-même est plus petite, vous pouvez échouer rapidement et réessayer.
Ce qui est problématique avec l’approche de Lidl, c’est que je suis presque sûr qu’ils n’avaient pas initialement prévu une migration de sept ans. C’était probablement une migration de deux ans qui s’est transformée en trois, puis quatre, et ainsi de suite, parce qu’ils échouaient, itéraient et rééchouaient. Sept ans plus tard, ils ont finalement décidé d’abandonner, probablement parce que tout le monde avait perdu tout espoir de voir le projet réussir.
Kieran Chandler: Donc, si nous convenons que ces applications, une fois que vous avez trouvé la bonne et peut-être itéré un peu, peuvent être fiables… Elles semblent fonctionner et semblent faire le même travail qu’un système plus important. Qu’en est-il du chevauchement entre ces applications ? Parce que la plupart du temps, une application fera autre chose de bien et il peut y avoir un peu de chevauchement et de conflit au sein de ce système. Comment gérez-vous cela ?
Joannes Vermorel: Tout d’abord, lorsque vous choisissez la composition de votre paysage applicatif, vous voulez vraiment choisir des applications qui ont un champ d’application étroit. Cette approche va complètement à l’encontre de ce que font la plupart des demandes de propositions (RFP). Lorsque les entreprises cherchent à acquérir un logiciel, elles font souvent une demande de proposition et veulent tout - toutes les fonctionnalités, toutes les options. Mais c’est l’opposé de ce que vous devriez rechercher. Vous voulez quelque chose de très spécifique, de manière à minimiser vos chevauchements dès la conception.
Si vous achetez de grands frameworks, c’est une recette pour avoir des chevauchements. Les fournisseurs d’entreprise sont intéressés à vous vendre de grands frameworks car ils peuvent les étendre avec de nombreuses fonctionnalités. Ils vous vendent quelque chose, puis ils vous vendront les compléments par-dessus. Donc, je dirais aux personnes qui gèrent de grandes chaînes d’approvisionnement, soyez très prudents lorsque l’on vous vend une plateforme.
Une plateforme, c’est bien, mais deux plateformes peuvent être un cauchemar. Dès que vous avez plusieurs fournisseurs qui vous vendent des plateformes, vous vous retrouverez avec une multitude de chevauchements. La solution consiste à choisir soigneusement la composition de vos éléments.
En ce qui concerne la “colle”, l’approche est que c’est généralement quelque chose que vous voulez développer en interne. Cela peut aller à l’encontre de l’intuition de pourquoi vous voudriez développer n’importe quel type de logiciel en interne. La réponse est que si vous êtes une entreprise d’une certaine taille, votre paysage applicatif est complètement unique à vous.
Même si vous utilisez toutes les applications standard, vous aurez besoin de plusieurs applications. Il n’y a aucun moyen d’avoir un ERP de nos jours qui peut gérer les e-mails, la visioconférence, etc. Vous ne pouvez pas intégrer chaque fonctionnalité logicielle dont vous avez besoin dans une seule application. Vous utiliserez probablement Microsoft Excel comme tout le monde, donc vous aurez besoin d’un endroit pour stocker des fichiers, etc.
Il n’est pas réaliste de dire que nous avons un seul logiciel. Toute entreprise d’une certaine taille sera de toute façon une collection de logiciels. La recette exacte, c’est-à-dire la liste des logiciels qui font littéralement fonctionner votre entreprise, sera complètement unique à vous. Aucune autre entreprise n’est organisée exactement comme vous.
Kieran Chandler: C’est complètement unique, c’est votre ADN. Vous pouvez avoir cette “colle” que vous mettez en place en interne. C’est tout l’intérêt de l’architecture orientée services, pour rendre cette “colle” aussi simple et légère à mettre en place, de sorte que vous puissiez avoir une équipe informatique très légère qui fait des efforts minimaux. Pour créer ce logiciel personnalisé qui assemble les choses. Donc, pour résumer, si je suis PDG, comment éviter un autre désastre de type Lidl ?
Joannes Vermorel: Tout d’abord, je pense qu’il est essentiel de penser en termes de risque plutôt que de minimiser le risque. Le désastre de type Lidl était dû à des personnes disant : “Nous ne voulons prendre aucun risque”, et donc elles choisissent le plus grand fournisseur disponible et essaient d’avoir le produit qui fait tout. Essentiellement, c’est l’approche où nous disons que nous voulons quelque chose qui est correct dès la conception, et nous voulons déployer quelque chose qui met à niveau toute l’entreprise en une seule fois. C’est la pire approche en termes de gestion des risques.
Il faut penser complètement à l’opposé, c’est-à-dire “Comment puis-je avoir quelque chose qui échouera rapidement s’il doit échouer ?” Voyez-vous, le problème avec le risque, c’est que lorsque vous avez ce projet massif, vous ne savez pas pendant longtemps si vous avez échoué ou non. Ce que vous voulez, c’est avoir quelque chose qui échoue rapidement, où vous savez si vous avez échoué, et l’échec est à petite échelle. Et si vous avez besoin d’un remplacement, vous avez un périmètre gérable, et vous le faites avec de nombreux petits morceaux.
Donc, pensez-y plutôt que de prévenir le risque. Je dis que passer d’un grand fournisseur à un petit fournisseur pourrait augmenter le risque de 50% de chances d’échec à 50%. En fin de compte, si une chance de 30% d’échec signifie que votre entreprise fait faillite ou que la chaîne d’approvisionnement s’arrête, ce n’est pas un risque que vous pouvez prendre. Vous devez donc prévoir l’échec de toute façon.
Je pense que parce qu’un degré élevé de risque est inévitable, allez directement vers un plan d’échec. Essayez d’avoir des échecs petits, rapides et bien définis afin de pouvoir itérer, plutôt que de dire que nous allons tout faire correctement la première fois, ce qui relève de la pensée utopique. Ensuite, embarquez-vous dans un voyage qui peut durer probablement sept ans, pour finalement perdre un demi-milliard d’euros dans le processus. C’est le genre de pensée utopique en matière de gestion de projet.
Kieran Chandler: Super, j’aime ça. Le conseil Lokad du jour : Si vous allez échouer, échouez rapidement. Brillant. C’est tout pour cette semaine. Nous serons de retour la semaine prochaine avec un nouvel épisode. D’ici là, merci de nous avoir regardés.
