00:00:04 Introduction à la Frankensteinisation logicielle.
00:00:35 Impact de la Frankensteinisation logicielle sur les logiciels B2B.
00:01:31 Comment les demandes des clients influencent la Frankensteinisation logicielle.
00:02:32 Les ‘cicatrices’ sur les logiciels et leurs implications.
00:05:33 Coûts de maintenance de la Frankensteinisation logicielle.
00:08:00 Défis et coûts des nouvelles fonctionnalités logicielles.
00:08:57 Fonctionnalités sans complexité : aperçu B2C.
00:10:36 Problèmes avec l’approche B2B des solutions logicielles.
00:13:18 L’expérience de Lokad : bien vs rapide et dette technique.
00:15:14 Envision : la solution de Lokad à la complexité.
00:16:30 Scripting spécifique au domaine : éviter les limitations et les conflits.
00:17:43 S’attaquer aux logiciels encombrants dans les chaînes d’approvisionnement.
00:18:01 Stratégies pour simplifier les logiciels complexes.
00:20:54 Gestion de la ‘masse technologique’ dans les systèmes logiciels.
00:22:00 Synergie IT, chaîne d’approvisionnement, marketing dans les changements de système.
00:22:43 Problèmes liés à la personnalisation excessive des logiciels.
00:23:48 Tester l’intégrité du fournisseur de logiciels via la personnalisation.
00:24:00 Gagner de l’influence sur la stratégie de développement du produit.
00:26:08 Choisir un logiciel léger et ciblé pour éviter la personnalisation.
Résumé
Sur Lokad TV, Joannes Vermorel présente le concept de Frankensteinisation logicielle, faisant référence à la manière dont les logiciels B2B évoluent à travers des modifications hasardeuses qui ne correspondent pas à leur conception initiale. Il compare ces changements à des ‘cicatrices’, contribuant à la création d’un système logiciel composite et évolué. Les ERP sont présentés comme un exemple, mettant l’accent sur le dilemme entre la maintenance de l’architecture logicielle et la satisfaction des nouvelles demandes. Vermorel met en garde contre les décisions hâtives, qui entraînent souvent des cicatrices logicielles et une augmentation des coûts de maintenance. Tout en reconnaissant la complexité inévitable de la gestion des logiciels, Vermorel souligne l’importance de s’inspirer des modèles B2C pour contrôler les interactions entre les fonctionnalités. La réponse de Lokad à ce problème est “Envision”, un langage de programmation spécifique au domaine qui sépare les problèmes infrastructurels des problèmes spécifiques au domaine.
Résumé étendu
Dans le dernier épisode de Lokad TV, la conversation tourne autour du concept de Frankensteinisation logicielle, un terme introduit par Joannes Vermorel, fondateur de Lokad. Il utilise ce terme pour décrire la transformation des logiciels B2B au fil du temps, en particulier les logiciels à longue durée de vie et les logiciels de chaîne d’approvisionnement, car ils évoluent grâce à des négociations continues et de gros contrats entre les fournisseurs de logiciels et leurs clients.
Vermorel explique que la Frankensteinisation logicielle se produit lorsque des ajustements sont apportés au logiciel en réponse aux demandes des clients. Ces modifications sont souvent incompatibles avec l’architecture, la philosophie et la conception d’origine du logiciel. Par conséquent, le logiciel accumule ces altérations, ou “cicatrices”, au fil du temps, le transformant en ce que Vermorel décrit comme un “monstre de Frankenstein” - un système logiciel composite et étrangement évolutif.
Il souligne en outre que ce phénomène est particulièrement prononcé dans les logiciels de chaîne d’approvisionnement, mais il est également courant dans de nombreux types de logiciels B2B. Néanmoins, il précise que le terme “cicatrice” ne doit pas être mal interprété comme étant intrinsèquement négatif. Ces modifications peuvent améliorer le logiciel en ajoutant de nouvelles fonctionnalités, améliorant ainsi sa fonctionnalité.
Vermorel donne l’exemple des logiciels de planification des ressources de l’entreprise (ERP), qui supposent que la saisonnalité peut être capturée à l’aide de profils fixes de 52 semaines. Cette conception fonctionne bien jusqu’à ce qu’une demande se présente qui ne correspond pas à ce cadre, comme la modélisation du Nouvel An chinois, du Ramadan ou de Pâques, qui suivent des calendriers différents et changent de dates chaque année.
Dans de tels cas, le fournisseur de logiciels est confronté à un compromis. Il peut répondre à la nouvelle demande en intégrant une solution “bricolée”, qui ne s’intègre pas parfaitement à l’architecture du logiciel mais fournit la fonctionnalité requise. Cependant, cette approche conduit souvent à davantage de “cicatrices”, contribuant à la Frankensteinisation du logiciel.
Soulignant le rythme rapide des négociations avec les clients clés dans le secteur des logiciels, Vermorel met en garde contre le risque de “cicatrices logicielles”. Il définit cela comme un processus où les fonctionnalités mises en œuvre à la hâte augmentent la complexité et le coût de maintenance du logiciel au fil du temps.
Expliquant les subtilités de l’architecture logicielle, Vermorel note que chaque ligne de code ou fonctionnalité nécessite une maintenance. À mesure que de nouvelles fonctionnalités sont ajoutées, les interconnexions deviennent plus complexes, entraînant un “problème de complexité quadratique”. Essentiellement, les interactions potentielles augmentent de manière exponentielle à mesure que le nombre de composants augmente, entraînant divers problèmes potentiels tels que des bugs, des plantages et des menaces de sécurité.
Vermorel souligne l’importance d’une architecture logicielle méticuleuse pour contrôler le nombre d’interactions entre les fonctionnalités. Il explique que l’objectif devrait être de doubler seulement la quantité de maintenance requise si le nombre de fonctionnalités est doublé, au lieu de quadrupler ou plus, ce qui se produit souvent lorsque le développement est précipité.
Lorsqu’on lui demande comment les entreprises de logiciels peuvent introduire de nouvelles fonctionnalités sans ajouter une complexité excessive, Vermorel suggère de s’inspirer des entreprises de logiciels B2C comme Google et Netflix. Ils prennent le temps de comprendre les problèmes spécifiques qu’ils essaient de résoudre et conçoivent des solutions qui traitent une large catégorie de problèmes similaires. Il oppose cette approche au monde B2B, où les clients viennent souvent non seulement avec des problèmes, mais aussi avec leurs propres solutions proposées.
En ce qui concerne la manière dont Lokad gère ces problèmes, Vermorel révèle leur lutte initiale pour trouver un équilibre entre faire les choses correctement et satisfaire rapidement les demandes des clients. Ils ont constaté une dette technologique croissante au cours des premières années, que Vermorel reconnaît comme étant préjudiciable. Ils ont réalisé que l’ajout de fonctionnalités pour satisfaire les clients individuels peut sembler bénéfique à court terme, mais cela conduit à un produit complexe, incohérent et difficile à gérer à long terme.
En réaction à cette prise de conscience, Lokad a élaboré une solution unique : un langage de programmation spécifique au domaine appelé “Envision”. L’objectif d’Envision est de séparer les problèmes d’infrastructure des problèmes spécifiques au domaine, permettant à Lokad de gérer plus efficacement l’ajout et la maintenance de nouvelles fonctionnalités sans ajouter une complexité excessive.
Vermorel continue à expliquer comment les produits logiciels, en particulier dans l’industrie de la gestion de la chaîne d’approvisionnement, traitent fréquemment d’un problème de gonflement en raison de la personnalisation extensive pour chaque client. Bien que la personnalisation vise à fournir des solutions sur mesure, elle aboutit souvent à un système complexe et difficile à gérer, nécessitant des efforts importants pour le maintenir et le mettre à niveau. Pour éviter cela, Vermorel explique comment Lokad utilise un script spécifique au domaine, Envision, pour créer des solutions hautement personnalisées, mais gérables, pour leurs clients.
Abordant le sujet de la complexité des logiciels, Chandler demande ce que les entreprises de logiciels peuvent faire pour éviter les logiciels surchargés. Vermorel répond que le scénario dépend de la possibilité pour une entreprise d’accéder à son logiciel. Si ce n’est pas le cas, l’entreprise doit faire face à la complexité du logiciel acquis. Cependant, si l’accès est disponible, le logiciel peut être simplifié en identifiant et en supprimant les éléments inutilisés, ce qui réduit considérablement la complexité.
En se concentrant sur les responsabilités des professionnels de l’informatique et des scientifiques de la chaîne d’approvisionnement, Vermorel observe que si le personnel informatique a généralement les connaissances techniques, il manque souvent de compréhension de la valeur commerciale de certaines fonctionnalités. Cela crée un décalage entre les fonctionnalités nécessaires et inutiles. Par conséquent, les décideurs commerciaux doivent collaborer étroitement avec les professionnels de l’informatique pour orienter la priorisation et la simplification du système.
Vermorel donne des conseils aux responsables de la chaîne d’approvisionnement qui envisagent d’investir dans un nouveau logiciel. Il met en garde contre la demande de personnalisation excessive, car cela peut entraîner davantage de problèmes. Au lieu de cela, les responsables devraient maintenir un contact régulier avec les responsables produits ou les directeurs techniques du fournisseur pour communiquer directement leurs besoins. Plutôt que d’imposer des fonctionnalités spécifiques dans un contrat, l’objectif devrait être de présenter des problèmes à ceux qui sont capables de trouver des solutions techniques.
Enfin, Vermorel conseille aux entreprises de choisir un logiciel qui excelle dans un domaine spécifique, plutôt que d’opter pour des solutions complètes. Cette approche ciblée facilite les améliorations et réduit la complexité causée par une multitude de fonctionnalités interconnectées. En restant proche de ceux qui contrôlent la feuille de route et en choisissant un logiciel clairement axé, les entreprises peuvent mieux gérer la complexité et améliorer leur productivité.
Transcription complète
Kieran Chandler : Aujourd’hui, nous allons aborder le sujet de la Frankensteinisation des logiciels. Alors, Joannes, c’est un sujet assez difficile à prononcer, donc je vais probablement te laisser le soin de le faire. Je suppose que nous ne parlons pas d’un gros monstre vert aujourd’hui. De quoi parlons-nous exactement ?
Joannes Vermorel : Nous parlons d’un processus qui conduit à l’évolution des logiciels, en particulier des logiciels B2B, et plus spécifiquement des logiciels de chaîne d’approvisionnement. Cela s’applique principalement aux logiciels B2B à longue durée de vie. Ce processus, que j’appelle “Frankensteinisation”, fait évoluer le logiciel au fil des années avec un flux continu de gros contrats négociés entre les éditeurs de logiciels et leurs clients. Ce qui est intéressant, c’est que chaque gros contrat négocié entre le fournisseur et l’un de ses grands clients est susceptible de laisser une cicatrice dans le logiciel.
C’est un processus progressif où un fournisseur négocie avec une grande entreprise. La grande entreprise a des exigences, et pour répondre à ces exigences, des ajustements sont apportés au logiciel qui ne correspondent pas à l’architecture globale, à la philosophie ou à la conception originale. La fonctionnalité est ajoutée, mais de manière quelque peu bricolée. C’est une cicatrice. Le problème, c’est que si vous répétez ce processus pendant des années, ce que vous obtenez en termes de logiciel est, d’une certaine manière, un monstre de Frankenstein. C’est une bête faite de nombreuses cicatrices qui semblent quelque peu hideuses et superposées. Il évolue de manière étrange, et c’est ainsi que vous vous retrouvez avec ces monstres de logiciels Frankenstein. C’est quelque chose qui se produit dans la plupart des bases de données, mais dans les logiciels de chaîne d’approvisionnement, c’est comme si c’était sous stéroïdes.
Kieran Chandler : Parlons de ces cicatrices, comme vous les appelez. À quoi ressemblent-elles ? Je veux dire, elles améliorent le logiciel, n’est-ce pas ? Elles ajoutent des fonctionnalités supplémentaires. Est-ce vraiment une mauvaise chose ?
Joannes Vermorel : Oui, évidemment, c’est le compromis. Vous voulez améliorer votre logiciel, mais un logiciel est un objet très complexe. Ce n’est pas comme un bâtiment où vous pouvez simplement ajouter un étage ou agrandir joliment. Les logiciels sont accompagnés de nombreuses hypothèses de conception inviolables faites très tôt, ce qui confère au logiciel une certaine intégrité - une intégrité architecturale.
Prenons de nombreux ERP par exemple, qui ont été construits autour de l’idée de capturer la saisonnalité avec des profils qui représentent exactement 52 semaines, soit une année donnée. Ainsi, vous avez littéralement une table avec 52 colonnes, une colonne par semaine, et vous avez tous ces profils de saisonnalité que vous pouvez appliquer à n’importe quel article que vous produisez ou vendez. Mais que se passe-t-il si vous voulez modéliser quelque chose comme le Nouvel An chinois ? Cela ne rentre pas dans cette grille de 52 semaines car il va se déplacer d’une année à l’autre selon le calendrier chinois traditionnel, et non le calendrier grégorien. Vous rencontrerez des problèmes similaires avec le Ramadan ou même Pâques.
Vous avez cette très belle hypothèse qui peut s’effondrer lorsque vous êtes confronté à une demande qui ne correspond pas à votre cadre. Et cela peut prendre de nombreuses formes. Le problème, c’est que en tant qu’éditeur de logiciels, vous n’avez pas réellement le temps de réécrire l’ensemble de votre pile logicielle pour que ces nouvelles fonctionnalités s’intègrent de manière complètement native à votre architecture. En fin de compte, c’est un peu bricolé.
Kieran Chandler: Vous négociez avec un client important, donc vous n’avez pas des années pour conclure l’accord. Et puis, vous n’avez pas des années pour livrer le futur non plus. Donc, les choses doivent être faites en urgence relative à chaque fois, simplement parce que c’est en réalité une négociation plus importante que d’habitude pour conclure une vente. Les choses sont précipitées presque par conception. Mais quand est-ce que quelque chose devient une cicatrice et quand est-ce que quelque chose devient une bonne fonctionnalité ? Parce que tous ces logiciels doivent évoluer, ils doivent changer, ils doivent fonctionner pour leurs clients. Alors qu’est-ce qui différencie les deux ? Comment savez-vous que quelque chose que vous développez ne va pas devenir une cicatrice ?
Joannes Vermorel: La question est de savoir combien cela coûtera en termes de maintenance ? Chaque ligne de code qui existe dans votre grand logiciel d’entreprise est quelque chose que vous devrez maintenir. Une chose que les gens ne réalisent pas toujours, même les professionnels du logiciel, c’est que le logiciel est comme une machinerie complexe où chaque partie doit interagir d’une manière ou d’une autre avec toutes les autres parties. Vous avez un problème de complexité quadratique.
Qu’est-ce que cela signifie ? Cela signifie que si j’ai dix parties, j’ai essentiellement environ 100 interactions potentielles, vous savez, 10 x 10. Si j’ai mille parties et qu’elles interagissent toutes, alors j’ai 1 000 par 1 000 interactions. Chaque interaction potentielle est une recette pour toutes sortes de problèmes : des problèmes de sécurité, des bugs, des plantages, des résultats incorrects ou simplement des ralentissements massifs dans le logiciel.
Lorsque vous ajoutez plus de parties, vous augmentez le nombre d’interactions potentielles entre les parties de votre logiciel, et cela augmente beaucoup plus rapidement que le nombre de parties. Et lorsque je dis parties, vous pouvez penser à des fonctionnalités, des capacités, des écrans, des options de données ou des entrées.
Si vous êtes très prudent avec votre architecture logicielle, vous pouvez préserver le nombre d’interactions entre vos fonctionnalités pour le maintenir sous contrôle. Si vous doublez le nombre de fonctionnalités dans votre logiciel, vous ne voulez pas multiplier le nombre d’interactions par 4, car cela signifie que lorsque vous doublez le nombre de fonctionnalités, vous quadruplez en réalité la quantité de maintenance que vous devez effectuer.
Mais c’est très difficile. Lorsque vous êtes pressé, lorsque vous doublez le nombre de fonctionnalités, vous multipliez en réalité par 4, voire plus, la quantité d’efforts que vous devez investir dans la maintenance. Au fil du temps, le coût de la maintenance explose, votre capacité à déployer de nouvelles choses diminue de plus en plus. Chaque fois que vous introduisez une nouvelle fonctionnalité, cela déclenche une vague entière d’incompatibilités et d’interactions inattendues bizarres entre différentes parties, car cela n’a pas été complètement réfléchi. La douleur augmente avec le temps.
Kieran Chandler: D’accord, donc réfléchissons du point de vue de cette entreprise de logiciels. Comment peuvent-ils introduire ces nouvelles fonctionnalités ? Comment peuvent-ils mettre en œuvre ces fonctionnalités pour satisfaire leurs clients, sans introduire cette couche supplémentaire de complexité ? Que peuvent-ils faire ?
Joannes Vermorel: Je pense que la leçon vient du monde des logiciels B2C. Google ne déploie pas de nouvelles fonctionnalités pour Google Search, ou Netflix ne déploie pas de nouvelles fonctionnalités pour Netflix simplement parce qu’ils signent un nouveau client. Ils ne prennent pas de nouveaux clients et commencent à discuter avec eux en disant : “Oh, si nous n’avons pas ces fonctionnalités, vous ne vous inscrirez pas avec nous, donc nous devons le faire maintenant.”
Ils ne fonctionnent pas comme ça. Ils réfléchissent à quel est le domaine, quel est le problème spécifique qu’ils essaient de résoudre. Ils essaient d’avoir une perspective très élevée sur ce problème, puis de réfléchir.
Kieran Chandler: Vous proposez une approche qui vise à générer des solutions pour toute une catégorie de problèmes, plutôt que pour un seul micro-problème. Cela nécessite de réarchitecturer le logiciel pour résoudre un large éventail de problèmes similaires. Et cela se produit tout le temps. Lorsque vous interagissez avec des clients, vous écoutez leurs problèmes, pas leurs solutions proposées. En comparaison, dans le monde B2B, les clients ont tendance à présenter non seulement leur problème, mais aussi une solution. Cette solution peut ou non s’intégrer à votre pile logicielle existante ou à l’évolution de ce problème. Donc, est-ce une question de ne pas vraiment écouter ?
Joannes Vermorel: Exactement, il s’agit plutôt de comprendre réellement le problème central au lieu de se fixer sur une solution particulière. Les grandes entreprises comme Google et Netflix sont d’excellents exemples de cela.
Kieran Chandler: Donc, vous dites que les entreprises n’écoutent pas vraiment. Mais qu’en est-il de ces pop-ups ennuyeuses qui demandent des commentaires ? Est-ce que quelqu’un les regarde réellement ?
Joannes Vermorel: Les pop-ups auxquelles vous faites référence sont généralement des fonctionnalités indésirables. Mais il faut reconnaître le mérite des entreprises comme Google. Ces pop-ups, où vous devez accepter les conditions, n’étaient pas leur choix. Ils ont été contraints de les mettre en œuvre en raison de contraintes réglementaires. Donc, même si cela peut sembler être une fonctionnalité bizarre, ce n’était pas de leur fait. De plus, si vous regardez qui a remporté le web, ce ne sont pas les entreprises avec des publicités super ennuyeuses. Ce sont celles comme Google qui avaient des publicités propres et discrètes. Ils pensaient à leurs clients au lieu de dévaloriser leur produit avec quelque chose d’aussi ennuyeux. Ils prennent le temps de réfléchir à leurs fonctionnalités.
Kieran Chandler: Dans les entreprises de logiciels B2B, en particulier dans la supply chain, il y a beaucoup de diversité. Il peut y avoir des centaines de scénarios, et souvent à la dernière minute, les gens négocient de nombreuses fonctionnalités qui se révèlent presque toujours être de mauvaises idées six mois plus tard. Donc, seriez-vous d’accord pour dire que la Frankensteinisation des logiciels est une mauvaise chose ? Et si oui, qu’avez-vous fait différemment chez Lokad pour éviter ce problème ?
Joannes Vermorel: Absolument, la Frankensteinisation des logiciels est un problème. Au cours des premières années chez Lokad, nous avons été confrontés à ce problème. C’était un compromis difficile. Si vous voulez le faire correctement, cela peut prendre un ou deux ans, ce qui est trop lent. Si vous ne le faites pas correctement, vous pouvez le faire en quelques semaines ou mois, mais alors vous vous retrouvez avec une grosse cicatrice, un hack moche. Vous finissez par accumuler une dette technique. Donc, pendant les premières années de Lokad, nous n’avions pas de solution, mais nous prenions de plus en plus conscience du problème. Même en tant que startup, la dette technologique s’accumulait, ce qui était une situation préoccupante. C’est à ce moment-là que j’ai réalisé que la tendance était défavorable. En regardant quelques décennies plus tard, je pouvais voir comment les concurrents, avec leurs logiciels surchargés pour l’optimisation de la supply chain, ajoutaient simplement de plus en plus de fonctionnalités sans aucune cohérence.
Kieran Chandler: Il semble que les entreprises de logiciels ajoutent toujours de nouvelles fonctionnalités, et le résultat final peut être un produit confus et surchargé. Pouvez-vous parler de votre approche de ce problème chez Lokad ?
Joannes Vermorel: Absolument. La façon dont les logiciels ont tendance à devenir surchargés est d’ajouter une mauvaise fonctionnalité à la fois. Si vous continuez sur cette voie pendant 20 ans, vous vous retrouvez avec un produit monstrueux. Ce n’est pas que les développeurs sont incompétents ou stupides, ils font simplement un travail décent de manière progressive, en essayant de gagner un client à la fois. Cependant, cette approche érode le logiciel un client à la fois, et le résultat final est généralement très, très mauvais.
Nous avons donc décidé de prendre un angle complètement différent chez Lokad, ce qui a conduit à la création d’Envision, notre langage de programmation spécifique au domaine. Avec Envision, nous avons effectivement divisé tous les problèmes. Nous avons séparé l’infrastructure, l’infrastructure de données et l’infrastructure de machine learning. Ce sont des produits à longue durée de vie que nous voulons maintenir et mettre à niveau, et c’est un effort de plusieurs années à chaque fois que nous décidons de les changer et de les mettre à niveau.
Ensuite, séparément, pour chaque client, nous créons une implémentation complètement sur mesure écrite en scripts dans Envision. Comme Envision est spécifiquement conçu pour l’optimisation de la supply chain, nous pouvions écrire quelque chose de complètement personnalisé pour chaque client, avec une grande productivité, tout en le rendant complètement sur mesure.
Donc, nous commençons avec une feuille blanche, la personnalisons complètement, et ensuite nous n’avons pas à faire face à une situation où le client nous demande quelque chose que nous ne prenons pas en charge. Grâce aux capacités programmatiques d’Envision, si nous devons faire quelque chose de spécial pour un client, le pire des cas est que le script que nous écrivons ne sera pas aussi compact que d’habitude. Cependant, nous pouvons toujours bénéficier d’une infrastructure conçue pour faciliter la résolution de certains types de problèmes.
Si vous introduisez des capacités avancées de programmation spécifiques au domaine dans votre plateforme, alors soudainement vous n’avez pas à précipiter une négociation qui marquera votre produit. Vous pouvez faire la personnalisation dans votre environnement programmatique qui est sur mesure pour chaque client, puis déployer des mises à jour pour votre plateforme selon votre propre calendrier, qui ne correspondra très probablement pas au calendrier de vos clients.
Kieran Chandler: Vous avez identifié ce problème assez tôt. Quels conseils donneriez-vous aux autres entreprises de logiciels qui rencontrent ce genre de logiciel surchargé ? Peuvent-elles faire quelque chose à ce sujet ? Devraient-elles commencer à supprimer certaines de ces fonctionnalités pour simplifier les choses ?
Joannes Vermorel: La situation dépend de plusieurs facteurs. Si vous êtes une grande entreprise qui possède le logiciel, comme un WMS, ERP, MRP, etc., vous n’avez peut-être même pas accès au logiciel lui-même, cela pourrait simplement être un produit de fournisseur. Si vous n’avez pas accès au produit, alors vous êtes coincé avec la complexité du logiciel que vous avez acquis.
Si vous avez accès au logiciel et que vous souhaitez le simplifier, alors oui, vous devriez commencer par examiner toutes les choses que vous n’utilisez pas et les supprimer de manière agressive. Beaucoup de gens sont généralement préoccupés par la suppression de parties d’un logiciel existant parce qu’ils craignent de perdre certaines fonctionnalités. Il est vrai que si vous supprimez des fonctionnalités, vous perdez ces fonctionnalités. Cependant, si vous supprimez quelque chose qui est presque jamais utilisé, vous pouvez également éliminer des classes entières de problèmes qui ont été causés par la simple présence de cette petite fonctionnalité.
Nous voyons souvent des mises en œuvre ERP chez Lokad avec littéralement des milliers de tables. Vous pouvez avoir un ERP avec, disons, cinq mille tables. Chaque table peut avoir de 10 à 200 champs, ce qui entraîne une complexité massive. Même la sauvegarde de l’ERP peut être incroyablement compliquée.
Kieran Chandler: Parce que vous avez autant de tables, vous avez besoin d’une table pour stocker la liste des tables, et ainsi de suite. C’est le genre de situation où si vous pouvez identifier des tonnes de tables qui ne sont même plus utilisées, ou des écrans qui ne sont plus utilisés, en les supprimant simplement, vous simplifiez tout.
Joannes Vermorel: Exactement, par exemple, si vous devez passer à une version supérieure de votre base de données, l’un des problèmes que vous pouvez rencontrer est que vous devez mettre à niveau des parties de la logique qui ne sont même plus utilisées par personne. Chaque ligne de code qui existe, que ce soit en Java, C Sharp, SQL ou autre, est quelque chose que vous devez maintenir tant que la ligne de code existe. Si vous supprimez cela, cela signifie que lors de votre prochaine intégration ou migration, les gens n’auront pas à se poser la question de comment migrer cette chose vers la prochaine version du système ou vers le prochain système en général.
Et c’est quelque chose à laquelle les dirigeants de la supply chain doivent réfléchir. Lors de l’achat de logiciels, ils devraient vraiment adhérer au principe de parcimonie - si vous n’en avez vraiment pas besoin, il vaut mieux ne pas avoir cette partie du système. Ce sera juste un fardeau. Il est essentiel de prêter constamment attention à la masse technologique de la solution que vous acquérez et exploitez.
Cette masse technologique n’est pas gratuite. Si vous avez plus d’écrans, vous avez besoin de plus de personnes pour les former. Si vous pouvez supprimer quelques écrans, cela signifierait moins de formation, moins de bugs signalés, moins de conflits avec l’informatique, etc. Il s’agit de gérer la complexité de l’informatique, mais la partie délicate est que généralement, l’informatique n’en a aucune idée car elle n’a pas accès à la valeur commerciale. Elle ne peut pas faire la différence entre les fonctionnalités qui sont vraiment nécessaires et celles qui ne le sont pas absolument. Elle ne peut pas traduire les tables, les champs, les écrans ou les fonctionnalités en euros ou en dollars. C’est quelque chose que seules les personnes de la supply chain ou du marketing, si vous regardez un autre système, peuvent faire. C’est pourquoi l’informatique a besoin du soutien de ces personnes, les décideurs de l’entreprise, pour orienter la priorisation et le changement dans la simplification du système.
Kieran Chandler: Et donc, pour conclure, vous avez mentionné que si je suis un dirigeant de la supply chain qui souhaite investir dans un nouveau logiciel pour mon entreprise, il semble que je ne devrais pas vraiment demander autant de personnalisation car cela introduit des problèmes. Alors, que devrais-je rechercher ?
Joannes Vermorel: Oui, demander de la personnalisation ou des fonctionnalités spéciales est comme une recette pour générer des problèmes. Si votre fournisseur de logiciels n’avait pas assez de problèmes par lui-même, vous en créez simplement de nouveaux qui ne feront qu’aggraver les choses. Donc vraiment, vous ne devriez pas le faire. Si vous pouvez réellement demander de la personnalisation, juste pour tester, car si le fournisseur accepte volontiers de discuter avec vous de la personnalisation, cela signifie que le fournisseur n’a aucune intégrité. Cela signifie que le fournisseur le fait avec chaque autre client, ce qui signifie que même si le produit est bon aujourd’hui, dans cinq ans, ce sera un cauchemar.
Tout d’abord, si vous demandez de la personnalisation, il est bon de demander et vous devriez vraiment vous attendre à ce que cette demande soit refusée. Sinon, c’est un problème.
Kieran Chandler: Une chose que les gens devraient demander, ce sont des fonctionnalités spéciales, n’est-ce pas ? Je veux dire, s’il y a une chose à demander, ce pourrait être l’accès au CTO ou au responsable produit du côté du fournisseur. L’inclure dans le contrat, peut-être ? Comme vouloir avoir une réunion avec cette personne deux heures une fois par mois. Pourquoi ?
Joannes Vermorel: Si vous négociez pour avoir un accès direct aux personnes qui élaborent la feuille de route du fournisseur, vous pouvez simplement présenter vos changements. Vous n’avez pas besoin d’imposer votre solution ; présentez simplement votre problème. Parce que, en tant qu’ingénieurs, que font-ils lorsqu’on leur présente un problème ? Ils commencent à travailler sur une solution. Si vous avez une réunion régulière où vous présentez vos problèmes, vous n’avez pas besoin de négocier des fonctionnalités spécifiques dans le contrat. Dans quelques années, des fonctionnalités commenceront à apparaître dans le produit qui semblent correspondre exactement au problème que vous avez exposé.
Kieran Chandler: Pouvez-vous expliquer un peu plus cela ?
Joannes Vermorel: Si vous faites le calcul, considérez le CTO d’une entreprise de logiciels. Combien de réunions cette personne peut-elle avoir avec des clients dans un mois donné ? Disons qu’elle en a un maximum de 20. Si vous avez une réunion par mois, vous obtenez essentiellement environ cinq pour cent de la bande passante mentale du CTO, qui est responsable du développement technologique du fournisseur avec lequel vous travaillez. Cela signifie que vos problèmes reçoivent une attention significative.
Kieran Chandler: Alors, quelle est votre suggestion ?
Joannes Vermorel: Ma suggestion, si vous voulez jouer intelligemment, est de vous rapprocher des personnes qui ont le contrôle sur la feuille de route. C’est plus intelligent que de négocier hâtivement des fonctionnalités défectueuses que vous allez probablement abandonner dans six mois parce que votre solution n’était pas bonne ou que votre problème a changé. De plus, une autre catégorie de conseils serait d’éviter les logiciels qui font trop de choses. Vous voulez penser à un logiciel qui fait une chose et la fait bien, plutôt qu’un logiciel avec des capacités étendues qui finit par mal faire tout.
Kieran Chandler: Pouvez-vous développer davantage ce point ?
Joannes Vermorel: Il est plus facile d’améliorer un logiciel étroitement ciblé que d’améliorer un cadre gigantesque qui fait tout. Chaque fois que vous allez ajuster quelque chose, pensez-y comme le nombre quadratique d’interactions. Si vous avez mille fonctionnalités et que vous en ajoutez une, vous devez penser à toutes les interactions avec les 1 000 fonctionnalités préexistantes. Donc, si vous introduisez une fonctionnalité, vous examinez toutes les 1 000 interactions. Cependant, si vous n’avez que dix fonctionnalités et que vous en ajoutez une onzième, il n’y a que dix interactions à examiner. Donc, encore une fois, concentrez-vous sur quelque chose de léger et axé sur le problème spécifique que vous essayez de résoudre.
Kieran Chandler: Super ! Je crains que nous devions en rester là pour aujourd’hui, mais je suppose qu’il y a quelques PDG là-bas qui ne vous remercieront pas trop pour cela, et qui recevront probablement quelques appels téléphoniques de plus. Eh bien, c’est tout pour cette semaine. Nous serons de retour la semaine prochaine avec un nouvel épisode. D’ici là, prenez soin de vous.
Joannes Vermorel: Merci.
