00:00:00 Les échecs de SAP déclenchent cette plongée profonde
00:02:15 Des milliards perdus sur les ERP, juste la pointe de l’iceberg
00:06:15 Les erreurs de conception héritées hantent les systèmes modernes
00:10:20 La logique de l’accaparement des terres derrière l’expansion des ERP
00:12:26 Applications CRUD et marchandisation des ERP
00:16:30 HANA était le pivot stratégique de SAP vers l’analytique
00:20:38 Pourquoi les bases de données tabulaires échouent en matière de reporting
00:26:23 Bases de données en colonnes : avantages et coûts cachés
00:30:21 Parier sur la RAM est le pari qui a échoué
00:34:31 Collisions de performances dans les bases de données hybrides
00:40:41 Les logiciels hybrides échouent sur tous les plans
00:42:33 Système d’intelligence : un troisième paradigme
00:46:59 Les premiers ERP faussement commercialisés comme intelligents
00:52:33 Pourquoi S/4HANA ne peut pas être tout à la fois
00:58:43 L’échec de Google avec CRUD montre un décalage culturel
01:05:02 La programmabilité est essentielle pour les systèmes de décision
01:10:38 L’échec économique de l’approche tout-en-un
01:16:30 Pourquoi la modernisation des ERP est si lente et coûteuse
01:22:06 Optimiser les décisions, pas seulement les processus
01:27:24 Conseils pour construire votre propre couche d’enregistrements
01:34:13 Open source et le véritable coût de la technologie de commodité
Résumé
Dans une discussion perspicace entre Conor Doherty de Lokad et le PDG Joannes Vermorel, ils explorent les revers financiers associés aux implémentations logicielles de SAP. Vermorel élucide les problèmes fondamentaux de fusion des systèmes d’enregistrement, des systèmes de rapports et des systèmes d’intelligence dans une solution ERP unique, ce qui entraîne des inefficacités et des conflits. Ils mettent en lumière les échecs coûteux vécus par des entreprises comme DHL et Lidl en raison des stratégies défectueuses de SAP, en particulier l’intégration de HANA. Vermorel préconise des systèmes spécialisés et des solutions open source comme PostgreSQL, offrant des fonctionnalités robustes à moindre coût, éloignant les entreprises des amalgames logiciels complexes et inefficaces.
Résumé étendu
À la lumière des récentes révélations montrant de nombreuses pertes financières liées à la mise en œuvre des logiciels SAP par de grandes entreprises, Conor Doherty, Directeur de la Communication chez Lokad, s’est entretenu avec Joannes Vermorel, PDG et Fondateur de Lokad, pour une discussion approfondie. Leur conversation, abordant les défis de la conception de logiciels d’entreprise et les écueils des stratégies ambitieuses mais défectueuses de SAP, offre une analyse riche et éclairante.
Vermorel explique les distinctions nuancées des systèmes logiciels utilisés par les entreprises : systèmes d’enregistrement, systèmes de rapports et systèmes d’intelligence. Le problème fondamental survient lorsque les entreprises tentent d’amalgamer ces trois systèmes distincts au sein d’un seul package logiciel, entraînant inévitablement des conflits et des inefficacités. Ce scénario est illustré par l’incorporation par SAP d’éléments fondamentalement incompatibles dans ses solutions ERP, tels que HANA, entraînant des revers stratégiques et opérationnels significatifs au fil du temps.
Les exemples d’échecs liés à SAP sont stupéfiants. Comme l’a rappelé Conor, des entreprises comme DHL, Lidl, Spar et Asda ont signalé des pertes totalisant des centaines de millions de dollars en raison de leurs implémentations ERP SAP. Ces pertes ne sont qu’une fraction de la stagnation économique plus large vécue par ces organisations lors des périodes prolongées consacrées aux mises à niveau des systèmes. Vermorel souligne que de telles entreprises freinent les efforts de modernisation et étouffent d’autres avancées numériques, gonflant considérablement les coûts réels de ces projets.
Au cœur du problème, Vermorel soutient, se trouvent des décisions essentielles prises par SAP il y a des décennies. SAP s’est initialement concentré sur les systèmes d’enregistrement - essentiellement des registres électroniques sophistiqués visant à couvrir tous les aspects des opérations de l’entreprise. Cette stratégie de “land-grab” a conduit à des périmètres étendus mais a également entraîné une banalisation des opérations de CRUD (Create, Read, Update, Delete). Au début des années 2000, un virage vers les systèmes de rapports a commencé, conduisant à des outils analytiques sophistiqués mais encombrants.
L’une des décisions cruciales prises par SAP a été d’intégrer HANA, une base de données en colonnes et en mémoire conçue pour améliorer les capacités analytiques mais inadaptée en tant que base de données fondamentale pour les opérations transactionnelles. Vermorel détaille comment cette erreur stratégique a eu des répercussions généralisées, ralentissant les processus de base et créant des problèmes de performance qui ont nécessité une sur-ingénierie extensive et coûteuse pour être gérés.
L’interview aborde le conflit inhérent entre les besoins de conception des différents systèmes logiciels. Les systèmes d’enregistrement nécessitent un traitement transactionnel rapide et de haute intégrité, tandis que les systèmes de rapports demandent des capacités étendues d’analyse de données. La combinaison de ceux-ci avec des systèmes d’intelligence, qui visent à automatiser la prise de décision grâce à la programmabilité, complique encore l’architecture logicielle. Ce dilemme est comparé à essayer de construire un véhicule qui soit à la fois un excellent avion et un fantastique bateau - une entreprise condamnée à aboutir à un hybride médiocre.
Conor évoque le rôle de la sympathie mécanique dans le choix des solutions logicielles - comprenant essentiellement les caractéristiques et contraintes inhérentes des logiciels, comme les différences entre les bases de données tabulaires et en colonnes. Une telle connaissance de base pourrait aider les entreprises à éviter des décisions coûteuses.
La note optimiste de Vermorel met en avant la promesse de solutions open source comme PostgreSQL. Il préconise l’utilisation de ces systèmes accessibles et robustes, suggérant que leur coût modeste et leur haute fonctionnalité offrent une voie viable pour contourner les écueils illustrés par les erreurs de SAP.
En conclusion, la discussion de Vermorel et Doherty souligne une mise en garde essentielle : alors que des solutions logicielles ambitieuses promettent d’unifier des fonctionnalités diverses sous un même toit, la réalité est que de telles intégrations conduisent souvent à une complexité excessive et à des problèmes de performance. Les entreprises devraient plutôt envisager des systèmes spécialisés adaptés à leurs besoins spécifiques, bénéficiant du riche paysage des offres open source qui offrent une excellence en ingénierie sans les coûts exorbitants associés. La conversation sert de cadre directeur aux entreprises pour naviguer dans leur transformation numérique tout en évitant les erreurs historiques qui se sont avérées économiquement préjudiciables.
Transcription complète
Conor Doherty : Bienvenue chez Lokad. À la lumière des récentes nouvelles selon lesquelles certaines très grandes entreprises ont perdu des sommes très importantes dans le cadre de leurs implémentations SAP, Joannes et moi avons décidé de nous asseoir et de discuter, eh bien, de ce qui s’est exactement mal passé. Joannes décrit les défis liés à la conception de logiciels d’entreprise ainsi que sa perspective sur les différences entre les systèmes d’enregistrement, les systèmes de rapports et les systèmes d’intelligence. Comme le soutient Joannes, lorsque les entreprises essaient de produire les trois en un seul logiciel, des problèmes commencent à apparaître.
Comme toujours, si vous aimez ce que vous entendez, abonnez-vous à la chaîne YouTube et suivez-nous sur LinkedIn. Et avec cela, je vous présente la conversation d’aujourd’hui. Alors Joannes, merci de m’avoir rejoint dans le Black Lodge. Je devrais un peu vous mettre dans le bain.
Dans l’introduction, j’ai reconnu qu’une des raisons pour lesquelles nous sommes ici est de discuter du fait que certaines très grandes entreprises ont perdu des sommes très importantes. Maintenant, c’est une déclaration très large. Comment nous en sommes vraiment arrivés à avoir cette conversation, c’était à la suite d’une publication qui est devenue quelque peu virale sur LinkedIn de la part d’Anthony Miller, un ami de la chaîne, où il a rassemblé un grand nombre de chiffres assez accablants liés, dans de nombreux cas, à des entreprises de plusieurs milliards de dollars rapportant des centaines de millions de dollars de pertes qu’elles ont attribuées à leur implémentation SAP.
Ainsi, pour citer ou paraphraser, je devrais dire, DHL aurait apparemment perdu plus de 370 millions de dollars en essayant de mettre en œuvre une solution SAP et IBM. Lidl en Allemagne - avant que quelqu’un ne me corrige dans les commentaires, c’est Lidl en Irlande, c’est Lidl sur le continent mais c’est Lidl en Irlande - a réduit ses pertes après avoir dépensé un demi-milliard d’euros. Donc, ils ont arrêté l’implémentation après avoir dépensé un demi-milliard d’euros.
SPAR, la chaîne néerlandaise, a affirmé avoir perdu 109 millions de dollars de ventes en raison de leur implémentation SAP. Donc, une conséquence de l’implémentation. Et ASDA a signalé 25,5 millions de dollars d’incohérences de stocks entre leur ERP SAP et leur WMS. Encore une fois, il y en a d’autres, mais le point ici est de dire que c’est plus d’un milliard de dollars ou d’euros de pertes. Donc, nous ne parlons pas de petites sommes ici.
Donc, je pose la question : Joannes, qu’est-ce qui ne va pas exactement avec ces énormes entreprises et leurs implémentations SAP ?
Joannes Vermorel : Et évidemment, le dénominateur commun à tous ces problèmes est le choix du mauvais fournisseur, SAP. Mais, euh, mais aussi, je pense malheureusement que ces chiffres ne sont que la partie émergée de l’iceberg. En fait, mon observation occasionnelle est que les pertes sont de l’ordre de grandeur supérieur et ce ne sont que celles que les gens reconnaissent. Je veux dire, et ils ne reconnaissent pas vraiment les coûts réels.
Ils reconnaissent juste, euh, par exemple, qu’ils ont payé pour quelque chose qui n’a pas fonctionné. Ce qu’ils ne reconnaissent pas, c’est que généralement le processus a pris de nombreuses années pour bon nombre de ces projets. En fait, l’entreprise était figée dans le temps pendant une demi-décennie, parfois une décennie, où ils ne pouvaient rien faire d’autre que se concentrer sur la mise à niveau de l’ERP.
Donc, vous voyez cela signifie que non seulement vous avez gaspillé des centaines de millions, mais en fait, ce n’est qu’une petite chose car ce que vous avez effectivement fait était de mettre en pause toute la modernisation, toute la numérisation, toute la transformation en cours que vous auriez pu réaliser autrement car vous deviez vous occuper de vos mises à niveau ERP. Et j’ai vu cela de nombreuses, nombreuses fois où les entreprises s’engagent dans un processus de plusieurs années où elles mettent tout en pause pour que cela se produise. Le coût est absolument gigantesque.
Je veux dire, c’est évidemment un témoignage de la qualité de ces entreprises qu’elles survivent même à ce processus car, soyons réalistes, par exemple, dans l’industrie du logiciel, quiconque met en pause son propre développement pendant une demi-décennie serait tout simplement mort. Je veux dire, ils seraient remplacés par des choses qui sont trois générations de technologies au-delà d’eux. Donc, bravo à ces entreprises de survivre. Cela signifie qu’elles maîtrisent parfaitement leur jeu pour pouvoir survivre aussi longtemps avec un processus aussi dysfonctionnel.
La réalité est que les perspectives sont absolument terribles. Et si nous allons au-delà de ce dénominateur commun et que nous voulons examiner la cause profonde, car blâmer SAP n’éclaire pas le cas, je pense que la cause profonde est une série d’erreurs qui ont été commises il y a longtemps, littéralement il y a des décennies.
Conor Doherty : Décisions commerciales ou voulez-vous dire des erreurs logicielles ? Quand vous parlez d’erreurs, que voulez-vous dire ?
Joannes Vermorel : Je veux dire, des erreurs de conception stratégique commises par des personnes chez SAP il y a des décennies. Ces échecs peuvent être attribués à des erreurs commises il y a des décennies. Et c’est intéressant car lorsque vous analysez ces échecs, ce sera le jeu des reproches : “L’intégrateur n’était pas bon” ou “La gestion du changement n’a pas été faite correctement dans l’entreprise” ou “Le service informatique de l’entreprise n’était pas à la hauteur qu’il aurait dû être” ou ceci ou cela ou cela ou cela. Vous savez, des excuses, des excuses, des excuses.
Et en effet, chaque échec semble être unique car c’est un désordre très spécifique à chaque fois. Mais encore une fois, ce ne sont pas des explications satisfaisantes. Je pense que si vous voulez vraiment comprendre pourquoi tous ces problèmes surviennent, c’est quelque chose de très spécifique à ces grands éditeurs de logiciels d’entreprise. Il y a des causes profondes claires qui remontent à des décisions prises il y a des décennies. Maintenant, nous voyons simplement les conséquences se dérouler.
Le public pourrait ne pas réaliser mais lorsque vous dirigez une entreprise de logiciels, vous devez vivre avec vos péchés, avec vos erreurs passées pendant très longtemps, voire éternellement. Et c’est très étrange car vous penseriez que le logiciel est complètement mutable, vous pouvez changer tout ce que vous avez fait. La réalité est différente.
Revenons à la différence, généralement en ce qui concerne les décisions architecturales, lorsque vous faites des erreurs, vous pouvez en rester bloqué indéfiniment. Et ces erreurs viennent simplement vous hanter pour toujours, et empoisonnent tout ce que vous faites. Les gens voient les symptômes, tous les problèmes, mais ne les relient pas nécessairement à la cause profonde, qui est souvent si ancienne que les gens ne la voient pas.
Conor Doherty : Eh bien, SAP, pour mémoire, est une énorme entreprise qui remonte à plus de 50 ans. Donc, lorsque vous parlez de causes profondes et de choix de conception stratégique datant de plusieurs décennies, vivre avec ces erreurs en 2025, ce sont des affirmations assez extrêmes qui nécessitent des preuves extraordinaires. Pouvez-vous me donner un exemple de ce qu’un choix de conception stratégique des années 1970 pourrait être qui hante un ERP SAP en 2025 ?
Joannes Vermorel : Donc, SAP a commencé à la fin des années 70 et ce que je décris comme des systèmes d’enregistrement. C’est ce que les gens appellent ERP, CRM, WMS, toutes ces pièces logicielles, qui sont fondamentalement le pendant électronique de quelque chose qui se passe dans l’entreprise. Ces systèmes d’enregistrement, il n’y a pas d’intelligence ; ce sont, je dirais, des registres sophistiqués. Si nous revenons dans le passé, les fournisseurs qui ont réussi étaient ceux qui ont le plus étendu leur emprise.
Que veux-je dire par emprise ? Si vous commencez à gérer les stocks, vous devez gérer les employés, puis les commandes, les paiements, les achats, les clients, les fournisseurs, les partenaires, etc. L’idée est que vous devez aller et conquérir le terrain d’une couverture complète - une couverture aussi étendue que possible pour vos enregistrements. En revenant dans le temps, disons les années 80, cette compétition pour la conquête de territoires avait lieu. La réalité était que pour toute entreprise qui commençait à adopter un fournisseur dominant (à l’époque, il pouvait s’agir de SAP, Oracle ou IBM), il y avait un effet de “le gagnant rafle tout” au sein de l’entreprise.
Vous êtes une entreprise cliente, vous utilisez un logiciel d’un fournisseur, dès que vous commencez à traiter avec ce fournisseur, vous allez pratiquement orienter l’ensemble de votre activité vers ce fournisseur. Pourquoi ? Parce qu’à l’époque, l’ingénierie des logiciels distribués était absolue. Cela signifiait que si tout ce qui concernait les logiciels n’était pas sur le même ordinateur central, vous étiez fichu. En théorie, vous pouviez faire du réseau (nous sommes dans les années 80) et certaines banques le faisaient à l’époque, mais c’était juste extrêmement compliqué, extrêmement coûteux.
En réalité, la seule solution économiquement viable pour gérer les stocks et les fournisseurs et connecter les points était de mettre tout cela dans le même système. Ainsi, un fournisseur pour gagner devait tout couvrir. C’est ce qui ferait finalement le succès des fournisseurs - les personnes qui développeraient ce qu’on appelle ERP et CRM. Ces grands méga-systèmes étaient ceux qui ont réussi, ayant une couverture massive. Qu’est-ce que cela implique ? Cela signifie que vous devez couvrir autant de terrain que possible et vous finissez par toucher à tout.
Maintenant, cela ne crée pas vraiment d’incitation à avoir une hyper-consistance, une hyper-intégrité. Il s’agit vraiment de conquérir autant de terrain que possible le plus rapidement possible. Dans le processus, ce que les grandes entités ont réalisé, c’est que les applications CRUD (Create, Read, Update, Delete) sont des produits totalement banals. Dans le processus de réalisation de cela, l’industrie du logiciel a réalisé que ce processus est un produit totalement banal. Si vous voulez avoir un système d’enregistrement, une application CRUD, c’est très simple.
Vous avez besoin d’une base de données relationnelle et d’un cadre pour fournir une série de vues pour chaque entité, offrant une interface utilisateur pour exécuter des opérations CRUD pour toutes les entités. Vous pouvez créer un client, mettre à jour un client, supprimer un client, etc. Vous pouvez le faire pour les clients, les fournisseurs, les factures, etc. Très rapidement, ces fournisseurs ont réalisé que cette chose est juste un produit totalement banal. La phase de conquête de territoires s’est pratiquement terminée dans les années 2000. En 2000, tout n’était pas couvert - de nouveaux domaines émergeaient, par exemple, le e-commerce.
À l’époque, ce n’était pas là ; vous devez ajouter cela. Il y a constamment de nouvelles choses, mais la plupart des territoires ont été couverts, ce qui pose problème. Des fournisseurs comme SAP ont vu que la marchandisation arrivait très fort. Ces systèmes d’enregistrement sont faciles et devraient être bon marché - bon marché. Alors, comment allez-vous maintenir vos profits et marges si vous vendez une technologie qui est un produit totalement banal ?
C’est là qu’ils ont vu une lueur d’espoir : les systèmes de rapports. Au milieu des années 90, une entreprise appelée Business Objects a émergé, créant le premier grand succès en vendant la technologie OLAP (traitement analytique en ligne) - un système de rapports. Ce fut un succès fou. Business Objects a été acquis en 2006 ou 2007 par SAP. Les gens ont réalisé que la valeur était peut-être plus dans les systèmes de rapports. À l’époque, cela semblait fantaisiste.
De toute évidence, contrairement aux enregistrements électroniques où une fois que vous avez toutes les informations dans la base de données sur vos clients, votre valeur est un peu limitée. Vous êtes censé fournir des équivalents électroniques à l’entreprise. Une fois que vous avez une représentation électronique satisfaisante de l’entreprise, il n’y a pas grand-chose à ajouter. Il y a seulement tant de choses que vous pouvez ajouter pour décrire un produit dans votre base de données, un client, etc. En fin de compte, il y a cette tendance vers l’analytique. SAP a réalisé cela et a décidé de se lancer pleinement dans cette deuxième phase à partir de 2010 avec HANA.
Ce serait, pour moi, la clé de la plupart des problèmes aujourd’hui. Je pense que cela découle de cette décision d’opter pour HANA. En revenant à cette décision à l’époque, SAP avait encore un problème stratégique : sa dépendance aux bases de données tierces. Dans les années 2000, ils s’appuyaient principalement sur les bases de données Oracle, un peu sur Microsoft et IBM DB2, mais principalement Oracle. Cela signifiait que l’ERP à l’époque, SAP ECC et toutes leurs suites (avec de nombreux produits et acquisitions), dépendaient d’une base de données tierce.
C’était un problème car une grande partie de la valeur allait à une autre société de logiciels. En raison de la marchandisation, la concurrence pour un marché en réduction posait problème. SAP a décidé de déployer sa propre couche de base de données, codée HANA. Voyant clairement qu’ils voulaient s’orienter fortement dans cette direction analytique, ils ont visé un système qui est en colonnes et en mémoire. Cette décision seule, en 2010, a déclenché l’erreur.
L’ERP S4 n’est sorti qu’en 2015. Une fois qu’ils ont leur nouveau système de base de données, ils ont besoin de quelques années pour reconstruire leur propre technologie ERP sur cette nouvelle base de données. Mais si nous revenons en arrière, je pense que la clé de l’erreur qui se déroule actuellement peut être retracée jusqu’à HANA. Maintenant, nous devons comprendre un peu plus. C’est un peu plus compliqué, donc je vais peut-être prendre un peu de temps pour expliquer ce qui se passe ici.
Pour un système d’enregistrement, ce dont vous avez besoin est une base de données tabulaire - c’est-à-dire une base de données traditionnelle. Alors, qu’est-ce qu’une base de données tabulaire ? C’est une base de données qui a des tables où les données sont organisées ligne par ligne. C’est une chose à garder à l’esprit avec les systèmes informatiques : la localité de référence est extrêmement importante pour les performances. Cela signifie que lorsque vous voulez accéder à une collection de données, si vous voulez avoir des performances, toutes ces données doivent être situées au même endroit dans le système, au même endroit.
Donc, disons que vous voulez mettre à jour un fournisseur. Le fournisseur a de nombreuses informations - son nom, son emplacement, sa certification, ceci, cela. Je veux dire, vous pouvez penser à tous les attributs de l’entité fournisseur à l’intérieur de votre système. Ce sera une table. Il y aura peut-être une table appelée “Fournisseurs”, et cette table aura des dizaines, voire une centaine, de colonnes. Donc, si vous organisez votre base de données de manière tabulaire, cela signifie que lorsque vous choisissez un fournisseur, il affichera le fournisseur.
Toutes les informations d’un fournisseur donné sont en quelque sorte situées au même endroit à l’intérieur de votre système. Et si vous voulez mettre à jour, même chose. Et si vous avez une représentation tabulaire de vos données, il est très simple d’ajouter une ligne, d’enlever une ligne. Encore une fois, ces choses sont joliment situées au même endroit. Cela fonctionne très bien. Donc, pour les bases de données tabulaires, pour les systèmes d’enregistrement, elles sont tout simplement parfaites.
Mais elles sont complètement nulles en ce qui concerne l’analyse. C’est un problème. C’est la nullité de ces bases de données tabulaires. C’est la principale raison pour laquelle les objets métier, vous savez, celui et tous ces outils de BI, ont réussi en premier lieu. C’est parce que dans les années 90, ils ont commencé à fournir ce qu’on appelle OLAP, qui sont des cubes, des hypercubes, qui vivent à côté de la base de données et qui sont beaucoup plus pratiques pour fournir des analyses.
Et pourquoi cela ? Je veux dire, réfléchissez-y. Si vous voulez regarder, disons que vous avez une table qui est des commandes, et la table des commandes a, disons, une colonne qui est le montant exprimé, disons pour simplifier, en dollars. Mais la table des commandes a par ailleurs comme 100 colonnes. Maintenant, vous voulez calculer combien de ventes en dollars avez-vous eu l’année dernière. La réalité est que si vous voulez calculer ce chiffre d’affaires de l’année dernière, qui est juste une somme de la colonne, vous pourrez, si vous avez une base de données tabulaire, parcourir à peu près toute la table. Votre système passera par chaque ligne, mais en fin de compte, il ne pourra pas isoler la colonne du montant car elle est complètement au milieu de tout le reste.
Donc, pour calculer cette addition de cette seule colonne, vous finissez par regarder toute la table, ce qui pourrait être des centaines de fois plus d’informations que la seule donnée que vous voulez pour chaque ligne, ce qui ralentit énormément le système. Maintenant, il y a une solution, et c’est d’organiser la base de données selon une configuration en colonnes. Alors, qu’est-ce que cela signifie ? Au lieu de regrouper ou d’emballer les données ligne par ligne, vous les regroupez par colonne.
Soudain, si vous voulez choisir une colonne et effectuer une opération comme “je veux additionner tout ce qui est dans cette colonne”, cela devient super rapide car vous avez accès à cette colonne isolément. Vous n’avez pas besoin de l’ID de commande, de l’ID client, de l’ID produit, et de toutes les autres colonnes que vous trouveriez dans la table des commandes. Vous isolerez la seule colonne que vous voulez. Même chose si vous voulez faire une sélection pour la date, vous pourrez choisir la colonne de date et simplement appliquer votre filtre.
Cela va être des ordres de grandeur plus efficace. C’est très cool. Donc, et d’ailleurs, cette configuration en colonnes est historiquement, vous savez, lorsque les gens ont commencé à faire de l’analyse d’entreprise, ils ont commencé avec des hypercubes, ces technologies OLAP. Mais très rapidement, vers la fin des années 2000, les gens ont réalisé que les bases de données en colonnes étaient tout simplement meilleures. Il y a donc eu une phase en termes de technologie où les objets métier travaillaient avec des hypercubes, et la technologie a très rapidement évolué vers une version supérieure, qui était les bases de données en colonnes.
Bon, maintenant les bases de données en colonnes sont bien meilleures pour l’analyse. Donc pour tous ces systèmes de rapports, c’est une excellente nouvelle. Nous avons quelque chose de bien meilleur pour le public. En passant, une base de données en colonnes serait, par exemple, Spark, une implémentation open-source qui fournit une base de données en colonnes.
C’est incroyablement scalable à gérer, et c’est très, très efficace en termes de performance. Maintenant, cela ne signifie pas que cette chose ne vient pas avec un compromis. Le compromis est qu’une base de données en colonnes est complètement nulle pour un système d’enregistrement. C’est-à-dire, par conception, cela va être sur deux fronts. Premièrement, si vous organisez vos données en colonnes, alors chaque fois que vous voulez mettre à jour une ligne, vous finissez par toucher de nombreuses colonnes. Vous devez identifier la position correcte dans chaque colonne, et si vous avez 100 colonnes, cela signifie que vous aurez 100 endroits distincts dans votre système à mettre à jour.
Alors qu’auparavant, avec votre base de données tabulaire, vous pouviez simplement faire une mise à jour ; ce serait juste local. Mais ici, vos données sont organisées en colonnes. Donc si vous voulez mettre à jour un enregistrement, cela sera réparti sur de nombreuses colonnes. Cela va être des ordres de grandeur moins efficace. Encore une fois, il n’y a pas de repas gratuit ici. Soit vous organisez vos données comme un système tabulaire, et c’est génial pour les systèmes d’enregistrement, soit vous faites en colonnes, et c’est génial pour les systèmes de rapports. Vous ne pouvez pas avoir les deux à la fois.
SAP a décidé de miser entièrement sur HANA, qui était une base de données en colonnes. Je pense que c’était la décision seule qui a scellé le destin de tout ce qu’ils faisaient en tant que couche fondamentale, qui était les systèmes d’enregistrement.
Conor Doherty : D’accord, juste pour intervenir car il y a eu beaucoup de choses abordées, c’était bien, merci. Mais juste au cas où, pour me situer en tant que personne qui pourrait écouter cela maintenant, ils pourraient dire, “Affirmez-vous sérieusement que DHL et Spar et Asda ont perdu, au total, un milliard de dollars de stocks ou simplement d’argent en essayant de mettre en œuvre juste à cause d’erreurs analytiques colonnaires par rapport à tabulaires ? C’est la cause profonde du problème. Est-ce une affirmation qui est faite ?”
Joannes Vermorel : Dans une large mesure, oui. Je veux dire…
Conor Doherty : Appuie cela pour moi.
Joannes Vermorel : Oui, le fait est que lorsque vous avez des erreurs architecturales critiques, elles ont tendance à se propager et à causer des milliers d’effets secondaires. Ce n’est pas parce que quelque chose est super chaotique et complexe que la cause profonde est elle-même quelque chose de très compliqué et chaotique. Un exemple serait la rotation de la Terre. La Terre par rapport au Soleil a une inclinaison sur son axe, ce qui provoque un système super compliqué de saisons avec des périodes chaudes et froides, des vents, et plein de choses qui ne sont que la conséquence de cette simple inclinaison.
Ainsi, vous pouvez avoir une cause profonde qui est extrêmement simple, mais lorsque vous regardez les conséquences, elles sont incroyablement complexes et variées, et pourtant elles peuvent être retracées à quelque chose de très simple.
Conor Doherty : Je suis d’accord, et c’est un bel exemple astronomique.
Joannes Vermorel : Ici, cela signifie que en prenant une décision qui est positive pour leurs analyses mais préjudiciable pour leurs systèmes d’enregistrement, ils ont créé un système incroyablement lent. Ici, nous pouvons également voir le genre de pari que SAP a pris en 2010. Ils n’ont pas seulement fait en colonnes ; ils l’ont également fait en mémoire. C’était une autre erreur. L’idée de le mettre en mémoire signifie qu’ils ont dit que toutes les données allaient vivre dans la DRAM, essentiellement le type de RAM que vous avez pour les serveurs.
La pensée de l’époque était que la DRAM deviendrait incroyablement bon marché et tellement plus rapide à l’avenir que ce serait bien. Les entreprises de logiciels ont tendance à dire, “Nous avons un problème de performance maintenant, mais si nous prenons les bonnes décisions, le progrès de l’industrie matérielle annulera ce problème pour nous à l’avenir.” Ils croient que si le matériel informatique devient cent fois plus rapide ou meilleur dans la bonne direction, alors quel que soit le problème de performance qu’ils ont maintenant pourrait disparaître dans quelques années.
Microsoft était tristement célèbre pour le faire depuis longtemps. Ils sortaient des logiciels qui fonctionnaient à peine sur n’importe quelle machine, puis quelques années plus tard tout était plus rapide, et le logiciel fonctionnait très bien. Le problème est que depuis 2010, la RAM n’a pas progressé autant sur une décennie et demie. Elle a progressé, mais juste un peu par rapport à tout le reste, surtout par rapport à d’autres formes de stockage de données comme les SSD.
La RAM a à peine bougé en termes de coût, de vitesse, de latence, et tout le reste, mais les disques SSD ont progressé d’un facteur de plus de mille pendant la même période. Ainsi, ils ont misé sur l’espoir que cette technologie s’améliorerait de manière exponentielle, mais ce n’est pas le cas, et très probablement cela ne se produira pas pour de nombreuses raisons. D’autres choses progressent comme des fous en informatique.
Ces cartes graphiques utilisées - les GPU utilisés pour l’IA - progressent énormément. Je veux dire, il y a plein d’autres domaines qui se trouvent à progresser énormément, mais celui-ci n’a pas. Et le problème était que le sacrifice que vous faites si vous utilisez votre base de données en la rendant colonnaire pour exécuter un système d’enregistrement est que votre latence va juste être horrible.
Les choses vont être lentes pratiquement par conception. Et c’était déjà un problème avec le goulot d’étranglement de la conception tabulaire. C’était déjà un problème, mais ici vous le rendez beaucoup, beaucoup pire. Ce qui signifie qu’en conséquence, vous passerez tout votre temps à lutter contre tous les problèmes causés en premier lieu par votre architecture incorrecte.
Conor Doherty: Eh bien, cela présente la transition parfaite car j’étais sur le point de dire exactement la même chose. Si vous appliquez simplement ce que vous venez de décrire - le système d’enregistrement et le système de rapports - le système d’enregistrement, votre ERP, dans un cas d’utilisation concret, vous scannez des codes-barres et le système est mis à jour pour que vous sachiez combien de choses vous avez dans votre entrepôt à tout moment ou combien vous avez en magasin. D’accord, cool. Cela nécessite une latence assez faible, je présume ?
Joannes Vermorel: Absolument.
Conor Doherty: D’accord, cool. Maintenant, qu’en est-il de la structure de conception de ce système d’enregistrement qui signifie que cela se fait au détriment d’un bon système de rapports, qui est essentiellement destiné à des fins de reporting commercial. Où est la lutte ? Parce que vous me dites qu’il y a une lutte, mais je ne comprends pas en termes… Vous voulez que le système, vous voulez que votre noyau rationnel soit hyper réactif lorsqu’il s’agit de scanner le code-barres. Donc vous scannez le code-barres et il bip, la chose est reconnue, tout va bien. Le code-barres existe dans votre système. Tout. C’est le bip que vous obtenez - le système reconnaît que tout est enregistré. Nous sommes bons. Avançons. Parfait.
Joannes Vermorel: Maintenant, le problème est, tout d’abord, si vous optez pour une configuration colonnaire, cette seule opération, qui consiste simplement à reconnaître que vous venez de scanner quelque chose, sera beaucoup plus lente par définition car il y aura des dizaines d’informations qui devront relier les points avec de nombreuses colonnes disjointes dans votre système.
Vous avez donc comme premier obstacle qui rend beaucoup plus difficile d’avoir un système aussi réactif par conception, car, encore une fois, les bases de données colonnaire sont excellentes pour l’analyse à grande échelle. Elles ne sont pas réactives. Il n’y a rien dans ces bases de données qui soit vraiment conçu pour de faibles latences. Ce n’est pas pour cela qu’elles ont été conçues. La conception même est un peu antagoniste à cela.
Maintenant, le problème est aggravé par une autre chose, à savoir que vous déclarez que votre couche de base de données sera utilisée exactement de la même manière que celle que vous utilisez pour votre système d’enregistrement. Donc les choses qui gèrent votre inventaire, les horaires des employés, tout où vous voulez une précision absolue exactement. Et vous voulez également une réactivité extrême lorsque quelqu’un pointe et badger.
Vous ne voulez pas que le système dise “Donnez-moi 20 secondes pendant que je vérifie si vous êtes un employé réel et si vous pouvez effectivement badger aujourd’hui.” Non ! Vous voulez que cela soit super réactif. Badger, bip, immédiatement ! Sinon tout ralentit un peu.
Maintenant, le problème est que le même système, parce que vous l’avez conçu comme une base de données en colonnes dans le but explicite de faire de l’analyse. Ensuite, vous - le système d’enregistrement pour le système de rapports - oui. Ce qui va se passer, c’est que les gens vont faire des rapports. Vous dites : “D’accord, nous avons ce système littéralement conçu pour que nous puissions faire des analyses sophistiquées. Faisons des analyses sophistiquées !”
Mais quelle est la conséquence des analyses sophistiquées ? La conséquence est que vous effectuez des opérations où vous devez analyser - où vous devez traiter de très grandes quantités de données. Et cela est complètement antithétique à la faible latence. Vous avez ce cœur de base de données partagé entre tous les processus. Il doit être partagé car sinon vous n’avez pas d’intégrité. Les gens n’ont pas la même vision de ce qu’est le niveau de stock actuel.
Si vous n’avez pas la même vision de ce qu’est le niveau de stock, cela signifie que quelqu’un sur le site Web peut commander une unité que vous n’avez pas car quelqu’un d’autre a déjà choisi cette unité et il y a eu des retards dans la propagation de cette information. Le e-commerce croit qu’il reste encore une unité alors qu’il n’y en a pas. C’est un gros problème !
Vous devez donc avoir cette intégrité pour ne pas vous retrouver avec plein de problèmes stupides. Maintenant, vos ressources de base de données relationnelle sont partagées entre des choses très légères qui doivent être très rapides et des choses très lourdes - vos rapports où vous dites “Analysez tous les clients qui ont fait plus de trois achats l’année dernière par catégorie” et tout ce qui s’ensuit.
Vous avez donc des demandes qui sont intensives en calcul, passant par une partie importante de l’ensemble des données que vous avez. C’est l’antagonisme. C’est tout l’intérêt de faire de l’analyse. L’analyse ne consiste pas à récupérer ce SKU ou ce client. L’analyse consiste à scanner chaque client pour avoir des statistiques sur ceci et cela.
Je vais scanner tout mon historique des ventes au cours des dernières années pour analyser une question de tendances. Vous avez donc les mêmes systèmes où vous avez beaucoup d’opérations très gourmandes. Et encore une fois, comment atténuer le fait que cela endommage complètement votre latence ?
Je veux dire, la réponse est de jeter du matériel sur le problème. Quel genre de matériel devez-vous jeter sur le problème ? Eh bien, vous devez jeter de la mémoire car vous avez décidé en 2010 que ce serait un système en mémoire en colonnes. Pas de chance !
Si le monde avait pris une direction différente, si la DRAM était devenue mille fois moins chère et plus rapide, ce serait le choix parfait. Mais cela ne s’est pas produit et il est très probable que cela ne se produira pas. Je veux dire, cette technologie - la DRAM - progresse toujours mais nulle part aussi rapidement que la plupart des autres technologies en matière de matériel informatique.
C’est l’une des technologies qui progresse le plus lentement, surtout en ce qui concerne la latence où elle n’a presque pas bougé depuis près de deux décennies. Il y a même des catégories de choses, surtout en termes de latence, où vous ne devriez pas vous attendre à une amélioration de sitôt.
Il y aura beaucoup d’améliorations mais pas sur ce front. Donc les personnes qui ont misé gros - comme au poker et qui ont tout misé - mais leurs cartes ne sont pas bonnes du tout. C’est à peu près ce qui s’est passé en 2010. Et nous voyons les conséquences se dérouler de manière très diverse aujourd’hui.
Conor Doherty : Encore une fois, je veux essayer de résumer autant que possible. Corrigez-moi si je me trompe. Les choix de conception que l’on fait pour exceller dans la première classe de logiciels - les logiciels d’entreprise que vous décrivez comme des systèmes d’enregistrement - sont antithétiques aux choix de conception que vous feriez si vous vouliez exceller dans un logiciel analytique tel qu’un système de rapports.
Et essayer de faire les deux - hybrider, comme vous l’avez dit - essayer de faire les deux simultanément aboutit essentiellement à une lutte où vous pourriez faire les deux choses, mais vous les ferez moins bien que si vous les aviez faites individuellement.
Joannes Vermorel : Plus ou moins, oui. Exactement. Je veux dire, c’est le problème : vous ne pouvez pas avoir quelque chose qui soit à la fois un très bon bateau et un très bon avion. C’est l’un ou l’autre. Si vous essayez de faire les deux, c’est possible, mais ce sera un mauvais bateau et un mauvais avion.
Conor Doherty : Eh bien, parce que je suis à nouveau familier avec le blog où vous avez introduit ce concept - cela va devenir un peu plus compliqué dans un instant. Mais avant cela, couvrons le terrain ou résumons le terrain que nous avons couvert. Vous utilisez l’analogie de la course et de l’haltérophilie. Les choses qui vous rendent très bon - et j’aime ça parce que l’analyse consiste à tout prendre. J’ai aimé l’idée de l’haltérophilie comme analogie.
Vous pouvez être un très, très bon haltérophile. Si vous voulez soulever 200, 300 ou 400 kilos du sol, vous devez être costaud pour le faire. C’est un mouvement basé sur la puissance. Courir 100 mètres en moins de 10 secondes ? Vous ne le ferez pas si vous pesez 150 kilos ; cela n’arrivera tout simplement pas. Donc vous pouvez être très bon en course à pied, ou vous pouvez exceller et être de classe mondiale dans les exercices d’haltérophilie anaérobique. Vous ne pouvez pas être les deux, et si vous essayez d’être les deux, vous n’excellez vraiment dans aucun des deux.
Joannes Vermorel : Oui, c’est exactement ça. Oui, eh bien, la chose est encore une fois, parce que je suis familier avec l’endroit où vous avez introduit cette perspective, il y a en fait une troisième catégorie parmi les classes de logiciels d’entreprise. Parce que nous avons de nouveau abordé les systèmes d’enregistrement - ERP, enregistrement de listes de données, unités de stock en main - vous avez vos systèmes de rapports - essentiellement des outils BI pour des fins analytiques et de présentation. Il y a une troisième classe de logiciels que nous n’avons pas encore abordée.
Conor Doherty : Qu’est-ce que c’est ?
Joannes Vermorel : Le troisième est les systèmes d’intelligence. La chose intéressante est qu’un système d’intelligence, contrairement aux deux premières classes, vise à prendre directement des décisions. C’est ça. La chose intéressante est que si vous regardez l’histoire des logiciels d’entreprise depuis le tout début à la fin des années 70, tous les logiciels d’entreprise ont toujours, peu importe ce qu’ils faisaient effectivement, été commercialisés comme des systèmes d’intelligence, ce qui est assez déconcertant.
Peu importe si ce que vous vendez est un système d’intelligence ou non. Tant que vous ciblez les entreprises, cela sera commercialisé comme un système d’intelligence - de meilleures décisions pour vous.
Conor Doherty : Oui, et c’est très déconcertant. Regardons, par exemple, les logiciels de gestion des stocks. En réalité, cette chose n’est qu’un grand livre. Il se contente de compter combien vous avez en stock. Lorsque vous prenez quelque chose, il décrémente votre stock. Lorsque vous mettez quelque chose, il incrémente le stock. C’est tout. Il ne fait rien d’autre que d’être une réflexion électronique de votre stock.
Joannes Vermorel : Ces produits étaient invariablement commercialisés comme “Vous aurez moins de ruptures de stock et moins de surstocks”, ce qui n’a rien à voir avec le grand livre lui-même.
Conor Doherty : Non, je veux dire, vous pourriez dire que vous serez plus efficace en tenant vos stocks à jour. Vous pourriez avoir moins d’erreurs de saisie, mais dire que vous allez prendre de meilleures décisions en matière de stocks - pourquoi le penseriez-vous ? Le logiciel ne le fait pas. Il vous dit juste ce que vous avez. Il vous permet juste de prendre vos décisions, peut-être de manière légèrement meilleure.
Mais c’est comme si vous pouviez jouer aux échecs sur un vrai échiquier ou sur un échiquier électronique. Bien sûr, si vous voulez suivre tous vos anciens jeux, la version électronique est plus pratique, mais le fait qu’elle soit sur un ordinateur ne fera pas de vous un meilleur joueur d’échecs. Il est même probable que cela soit une distraction qui vous rende en fait moins bon joueur d’échecs.
Ce n’est pas acquis que les décisions que vous prenez avec un ordinateur sont automatiquement meilleures simplement parce que vous interagissez avec un ordinateur au lieu de le faire avec un stylo sur du papier. Cela peut arriver, mais ce n’est pas conçu pour cela logiquement. Je dirais même que d’après mon expérience personnelle décontractée, lorsque vous demandez aux gens de vraiment réfléchir à quelque chose, un écran d’ordinateur est un peu une distraction en règle générale.
Je dirais que si vous voulez vraiment prendre de bonnes décisions, je ne suis pas sûr qu’un écran avec beaucoup de désordre aiderait à se concentrer et à vraiment réfléchir.
Joannes Vermorel : C’est une affirmation très audacieuse. Juste pour être clair, nous ne rejetons pas la valeur d’un système d’enregistrement. Le point, tel que je le comprends, est de ne pas confondre votre système d’enregistrement et ses capacités avec les capacités d’un logiciel explicitement conçu pour produire des décisions.
Pour défendre ces premiers fournisseurs de logiciels d’entreprise, c’était extrêmement flou. Ce qui nous est maintenant très clair - ces systèmes d’enregistrement, applications rudimentaires, systèmes de rapports avec tous les outils de business intelligence et les analyses modernes, puis les systèmes d’intelligence où vous avez des capacités de prédiction, des capacités d’optimisation, avec l’idée d’automatiser littéralement les processus de prise de décision - cette sorte de classification était tout simplement très floue à l’époque.
Ils essayaient de faire les trois à la fois, et dans les années 70, les tout premiers systèmes de gestion des stocks étaient commercialisés comme “Nous automatiserons directement toutes les décisions en matière de stocks.” Ils étaient commercialisés comme tels. La communauté a réalisé qu’il était très facile de gérer les stocks. Gérer dans le sens où il y a même une nuance dans le terme gestion.
Lorsque les gens parlaient de gestion des stocks dans les années 70, ils entendaient toutes sortes de choses qu’un gestionnaire ferait, et un gestionnaire ne se contenterait pas de faire de la comptabilité. Il prendrait également des décisions en matière de stocks. Ainsi, les gens disaient que lorsqu’ils pensaient à la gestion des stocks, ils pensaient à quelque chose qui ferait l’ensemble du package - suivre les stocks et prendre toutes les décisions pertinentes. Il s’est avéré que ce n’était pas le cas.
Nous avons donc subdivisé le domaine en gestion des stocks, optimisation des stocks - l’optimisation appartenant au système d’intelligence. Mais à l’époque, c’était très flou. De même avec l’analyse - vous pouviez afficher des choses, mais les gens n’avaient pas réalisé à quel point les bases de données allaient croître et tous les défis que vous auriez pour produire des statistiques à partir d’elles.
Avoir des statistiques était déjà possible dès le départ. Ces systèmes tournaient généralement la nuit, passant une fois par la base de données entière pour collecter des statistiques. Donc c’était un peu possible, même avec une base de données tabulaire, vous pouviez avoir des lots nocturnes qui collecteraient les statistiques que vous recherchiez, mais c’était très gênant car c’était très lent.
Vous deviez préparer votre logique à l’avance, et une fois que vous aviez votre logique, vous deviez attendre le lot nocturne pour qu’il soit exécuté. Vous vous rendiez compte que vous aviez une faute de frappe dans votre code le lendemain. Opérationnellement, c’était un cauchemar. C’était possible, mais le niveau de friction était tout simplement exagéré.
C’est pourquoi ces outils comme Business Objects ont essentiellement développé des technologies OLAP avec des hypercubes, où vous pouviez avoir en quelques secondes des analyses. Cela a complètement changé la donne car soudainement vous n’aviez pas à passer par, disons, implémenter quelque chose et attendre jusqu’au lendemain pour voir si vous aviez fait une erreur. Vous pouviez le faire à une vitesse 100 fois supérieure à ce que vous pouviez faire avant.
Conor Doherty : Plus tôt, vous avez mentionné S4/HANA, qui a été lancé en 2015. Au moment de l’enregistrement de cette conversation, il a presque dix ans - je pense que c’était il y a dix ans jour pour jour, il y a deux jours. Après avoir examiné le matériel marketing à ce sujet, en particulier en utilisant votre classification, il était présenté comme ayant toutes les capacités d’un système d’enregistrement, d’un système de rapports, et grâce à sa prise de décision pilotée par l’IA, un système d’intelligence. Vous avez donc couvert les problèmes créés en essayant de combiner des systèmes d’enregistrement et des systèmes de…
Joannes Vermorel : Certaines analyses ont été, je dirais, un changement de jeu complet car soudainement vous n’aviez pas à passer par, vous savez, implémenter quelque chose et attendre jusqu’au lendemain pour voir si nous avions tort. Juste pour répéter, vous pouviez le faire à une vitesse 100 fois supérieure à ce que vous pouviez faire avant.
Conor Doherty : Eh bien, encore une fois, vous avez en fait mentionné SAP S/4HANA, qui a été lancé en 2015. En fait, au moment de l’enregistrement de cette conversation, il a presque 10 ans - je pense que c’était il y a 10 ans jour pour jour, il y a deux jours. Après avoir examiné le matériel marketing à ce sujet, en particulier en utilisant votre classification, il était essentiellement présenté comme ayant toutes les capacités d’un système d’enregistrement, d’un système de rapports, et grâce à sa prise de décision pilotée par l’IA - un système d’intelligence. Vous avez déjà abordé les problèmes lorsque vous essayez de combiner des systèmes d’enregistrement et des systèmes de rapports simultanément. Que se passe-t-il lorsque vous essayez de faire fonctionner ces trois systèmes sous un même toit ?
Joannes Vermorel : Oui, je veux dire, ici nous essayons d’être un train, un bateau et un avion en même temps, donc c’est encore pire. Vous savez, c’est comme entrer dans le territoire de Frankenstein où cela va être vraiment laid. La réalité est que tout est un peu contre vous en tant que fournisseur de logiciels si vous essayez de faire les trois. Juste une pause pour réaliser exactement ce que cela implique.
Un système d’enregistrement, vous factureriez généralement par opérateur, par siège, par utilisateur. C’est la façon dont vous vendez ce genre de choses aujourd’hui ; ce sera une métrique très typique. Si vous faites un système d’intelligence, cela n’a pas de sens car vous éliminez en quelque sorte les utilisateurs. Oh oui, donc c’est votre intention - vous voulez prendre de bonnes décisions. Donc évidemment, plus vous êtes bon, moins vous avez d’utilisateurs. En fin de compte, vous auriez juste une poignée d’utilisateurs dans l’entreprise cliente juste pour superviser vos décisions et en rester là. Donc, si vous facturez par utilisateur, cela ne fonctionnera pas ; vous avez un tel antagonisme en termes d’incitation. Mais évidemment, ce n’est qu’un détail ; il y a plein d’autres problèmes.
Le problème est que le type d’ingénieurs logiciels dont vous avez besoin n’est tout simplement pas le même. En passant, je pense qu’une entreprise, cette entreprise de logiciels, qui a rencontré un énorme problème à cause du problème opposé, était Google. Google a été pionnier dans des choses qui étaient très liées aux systèmes d’intelligence. Quelle était la décision intelligente prise par Google à l’époque ? C’était la recherche ; voici ma requête, identifiez ce qui est le plus pertinent parmi un milliard de sites web. C’est une décision qui est prise, et elle doit être faite de manière très astucieuse. Google a fait fortune en prenant ces décisions de manière extrêmement efficace - du moins mieux que leur concurrence. Ils ont construit tout un effectif sur l’idée qu’ils auraient des ingénieurs très intelligents s’attaquant à des problèmes très difficiles car la prise de décision, la caractéristique est qu’elles sont presque très difficiles.
C’est pourquoi vous voulez les déléguer à un ordinateur. Si elles n’étaient pas difficiles, cela ne qualifierait même pas de décision. Si quelque chose relève simplement d’une simple arithmétique, vous diriez “D’accord, c’est juste un calcul de base, rien à voir ici, passez à autre chose.” Google a embauché des tonnes d’ingénieurs capables pour réaliser ces systèmes sophistiqués. Quand il s’est agi de développer des systèmes d’enregistrement, qui sont banals, ennuyeux et répétitifs, eh bien, ils ont échoué.
Si vous regardez l’histoire de Google, tout ce qui était banal a été jeté par la fenêtre. Ils avaient Google Reader, un lecteur de blog, qui a été largement adopté. C’était simple, une application rudimentaire, mais une application rudimentaire n’était pas suffisante pour Google, alors ils l’ont abandonnée. Ils avaient des dizaines de produits similaires où s’il s’agissait d’une application rudimentaire - rudimentaire dans le sens de Créer, Lire, Mettre à jour, Supprimer - ils la publiaient mais ne pouvaient pas la maintenir car c’était en dessous d’eux.
C’est un vrai problème lorsque toute votre entreprise est axée sur le développement de systèmes d’intelligence : votre force de travail en ingénierie n’est pas enthousiaste à l’idée de faire un travail fastidieux et répétitif. En revanche, si vous avez passé des décennies à créer des systèmes d’enregistrement, votre force de travail est simplement habituée à concevoir des milliers d’écrans, reconnaissant “D’accord, ce logiciel aura besoin de 5 000 ou 20 000 fonctionnalités distinctes, toutes individuellement très faciles sans aucun défi, mais elles doivent quand même être réalisées.
En termes de force de travail en ingénierie et de culture, c’est complètement différent. Ma perception est que SAP s’est retrouvé avec une main-d’œuvre orientée vers cette mentalité de conquête de territoire - ayons un million d’ingénieurs qui peuvent créer un million d’écrans et un million de fonctionnalités, toutes super simples individuellement. Ensuite, ils essaient de passer aux systèmes d’intelligence, et cela échoue très mal.
Un domaine où l’on peut voir des personnes douées pour les systèmes d’intelligence est qu’elles réalisent des percées technologiques, et cela se manifeste sous la forme de projets open source. Google, par exemple, a peut-être échoué à maintenir des applications rudimentaires, mais a réussi à publier des morceaux de technologies open source précieux, très complexes et difficiles à concevoir en raison de leur personnel talentueux. Si l’on regarde SAP, je ne suis pas sûr de pouvoir mentionner ne serait-ce qu’un seul projet open source d’intérêt qui soit issu de SAP pour comparaison.
Conor Doherty : Eh bien, il me semble que nous avons passé pas mal de temps à délimiter la structure des systèmes d’enregistrement et des systèmes de rapports, mais nous n’avons pas réellement abordé les choix de conception architecturale stratégiques - les choix de conception architecturale stratégiques - pour un système d’intelligence et pourquoi cela serait incompatible avec les deux autres architectures. Par exemple, Lokad est un système de décisions, un système d’intelligence ; qu’est-ce qui, dans sa composition, signifie que tenter de concilier cela avec un système d’enregistrement serait problématique, pour le dire légèrement ?
Joannes Vermorel : Je dirais qu’un système d’intelligence a, pour ses fondements, certaines similitudes avec un système de rapports. Vous voulez cette représentation en colonnes ; cela a beaucoup de sens pour l’analyse. Mais ensuite, ce que vous voulez d’un système d’intelligence, c’est une programmabilité très rapide. Si vous voulez la flexibilité pour concevoir un processus de prise de décision, vous avez besoin de quelque chose d’extrêmement expressif. D’ailleurs, c’est pourquoi les feuilles de calcul Excel sont fréquemment utilisées pour soutenir les processus de prise de décision ; avec Excel, vous disposez d’un langage de programmation, ce qui est très important.
Les formules Excel peuvent être arbitrairement complexes, et si vous êtes sophistiqué, vous pouvez même programmer en VBA ou en Python. Excel est programmable, et c’est pourquoi il est fréquemment utilisé comme outil pour soutenir les systèmes d’intelligence. Vous avez besoin de programmabilité, ce qui est un jeu complètement différent par rapport aux systèmes de rapports où cela devrait être accessible à tout le monde. Vous êtes dans le territoire du WYSIWYG (What You See Is What You Get) ; vous avez des interfaces sophistiquées, qui est le monde des systèmes de rapports.
Conor Doherty : Il me semble également qu’il y a ici une perspective économique que nous n’avons pas encore abordée. Et encore une fois, vous êtes un homme d’économie, un homme de Thomas Sowell.
Il me semble que, que ce soit en termes de logiciel, c’est une décision intelligente d’essayer d’acheter une solution tout-en-un où vous avez votre système d’enregistrements, de rapports et d’intelligence tous ensemble. Nous pouvons laisser cela de côté. N’y a-t-il pas un argument économique qui dirait que, en termes de compromis, il pourrait être moins cher d’acheter essentiellement un seul logiciel qui prétend au moins pouvoir faire ces trois choses plutôt que trois abonnements séparés à trois logiciels distincts, trois problèmes distincts, de devoir former tout le monde à utiliser trois choses distinctes ?
Joannes Vermorel : Oui, je veux dire, c’est littéralement l’histoire du F-35. Vous parlez de ce chasseur américain qui sera l’avion le plus cher de tous les temps. Le problème est que ces choses ne sont pas linéaires.
Si vous dites, “Je veux que mon avion soit super performant en combat rapproché, super performant en opération à longue portée, et furtif, et qu’il puisse décoller verticalement”, vous vous retrouvez avec quelque chose où chaque fois que vous ajoutez une fonctionnalité, vous doublez le prix de l’ensemble.
Donc, au final, vous vous retrouvez avec un avion qui coûte le prix typique de peut-être dix autres avions - un pour l’opération à longue portée, un pour le combat tactique avec un autre avion, un pour être furtif, un pour le décollage vertical. Vous n’avez pas nécessairement besoin de tout cela, etc. etc. Donc, vous voyez, ce n’est pas linéaire. Vous ne pouvez pas simplement avoir toutes ces choses dans une seule configuration.
Maintenant, vous pourriez dire que si SAP avait décidé d’avoir trois systèmes complètement indépendants - l’un traitant du système d’enregistrements, l’autre traitant du système de rapports, le troisième traitant du système d’intelligence - et que vous mettiez des murs chinois entre toutes ces divisions et qu’elles fonctionnaient de manière indépendante, cela aurait pu fonctionner. Mais ce n’est pas ce qui a été fait.
La tentation était beaucoup trop forte de tout regrouper, y compris des solutions tierces acquises. Le mélange est tout simplement toxique. Vous prenez des produits qui se mélangent très mal, et vous obtenez quelque chose de dysfonctionnel. Je pense que c’est ce que nous voyons actuellement.
Revenons à la chronologie, nous avions HANA en 2010. Il leur a fallu cinq ans pour déployer S/4 par-dessus. La plupart de ces échecs étaient littéralement une décennie en préparation. Nous regardons des choses qui ont pris une décennie pour se dérouler.
Nous regardons des échecs de HANA qui ne font que devenir publiquement visibles. Ce n’est que la partie émergée de l’iceberg. Les coûts d’opportunité de nombreuses entreprises sont tout simplement fous car il faut tant d’années pour effectuer une mise à niveau. Nous parlons de mises à niveau de cinq ans ou plus, ce qui est tout simplement aberrant.
C’est insensé. Regardez le fait que ChatGPT et l’IA générative n’existaient pas il y a cinq ans. Vous allez être tellement en retard dans la bataille. En plus de cela, de très mauvaises décisions ont été prises, comme le fait d’être entièrement basé sur des systèmes en mémoire, ce qui signifie des dépenses excessives en infrastructure.
Si vous avez des tonnes de matériel, bien plus que nécessaire, cela signifie que vous avez besoin de plus d’administrateurs système, de plus de personnes en informatique pour gérer tout cela. Tout devient incroyablement complexe. Ce n’est pas seulement plus complexe mais aussi plus lent. Ces choses se cumulent. C’est beaucoup plus coûteux, plus lent, vous avez besoin de plus de personnes, et cela fait croître encore davantage le coût d’opportunité.
Ensuite, les gens deviennent effrayés au niveau de la direction car il y a tellement en jeu. Cela ralentit encore davantage le processus. C’est comme un cercle vicieux. Les problèmes ne font que devenir visibles. Les entreprises font tout leur possible pour s’assurer que les erreurs internes ne sont jamais rendues publiques car ce n’est pas une bonne presse. Vous ne voulez pas faire de publicité pour votre propre incompétence. Si vous pouvez gérer cela à huis clos, c’est bien mieux.
Pensez à quel point le problème doit être extrême pour finir par divulguer tout cela au public. Presque toutes les situations, sauf si l’entreprise est cotée en bourse et qu’elle est dos au mur et doit divulguer des choses car sinon cela serait considéré comme de la fraude, ne seront pas divulguées.
Conor Doherty : Eh bien, vous avez mentionné le coût d’opportunité à plusieurs reprises. Vous avez mentionné le coût d’opportunité d’être aspiré dans une mise en œuvre. Soudain, vous êtes coincé dans ce processus, vous empêchant de pivoter vers autre chose. Cela a également un coût croissant associé aux personnes qui le maintiennent.
Il y a en fait une autre dimension à cela, et j’ai écrit ici “perfectibilité”. En termes de coût d’opportunité, si vous preniez chacune de ces classes de logiciels individuellement, et théoriquement ils sont au mieux lorsqu’ils sont séparés car vous avez un système d’enregistrement séparé, un système de rapports séparé et un système d’intelligence séparé.
Vous essayez de perfectionner chacun. Il y a une limite supérieure à la perfection qu’un système d’enregistrement peut atteindre. Une fois que vous avez 100% précision, c’est tout. Par exemple, combien de bouteilles sont sur la table ? Il y en a deux. C’est tout. Vous ne pouvez pas faire mieux que ça.
Une fois que vous avez une latence de 50 millisecondes, c’est négligeable ; les gens ne le remarquent plus. Un système de rapports - à quoi peut ressembler un tableau de bord ? Nous pouvons débattre de l’esthétique, mais il y a une limite supérieure sur le temps et l’argent que vous voulez investir avant de commencer à avoir des rendements décroissants.
Un système d’intelligence, comme vous l’avez dit, implique des décisions. Dans la philosophie de Lokad, cela signifie considérer le retour sur investissement pour chaque décision prise. Théoriquement, il me semble qu’il n’y a pas de point de perfection où vous pouvez dire : “C’est la meilleure décision que je pourrais jamais prendre.”
Ce n’est pas nécessairement perfectible. Vous pouvez continuellement améliorer un algorithme pour prendre de meilleures décisions. Ai-je tort ?
Joannes Vermorel : Donc, non, mais nous devons également dissiper une idée fausse. Les mathématiciens diraient : “Oh, mais une fois que vous atteignez l’optimal, vous êtes le meilleur.” Vous savez, par définition, une fois que vous avez l’optimal, cela ne peut pas être amélioré. Et pour tout, je dirais, puzzle mathématique donné, si vous prenez un puzzle mathématique et dites : “C’est ça, c’est un puzzle,” alors vous pouvez avoir la solution optimale pour ce puzzle.
Mais là où il est incorrect de penser ainsi en affaires, c’est que le choix du puzzle est très arbitraire. Vous savez, vous pouvez décider : “D’accord, j’ai peut-être ce qui est optimal pour ce cadre, mais je peux peut-être réinventer mon propre business et alors j’aurai un nouveau cadre qui me donne encore des rendements plus élevés.” Ainsi, les options que vous avez ne sont pas statiques. Vous décidez de ce que vous êtes prêt à faire, et parmi les choses que vous êtes prêt à faire, il peut y avoir un optimal, mais fondamentalement, vos possibilités sont infinies.
Il n’y a pas - la seule limite supérieure, telle que je la vois, c’est l’ingéniosité humaine elle-même. Ainsi, vous dites : “Mon optimal est sans signification car l’optimal est dans des limites formelles.” Là où je dis : “Je ne peux décider que dans, vous savez, je trace une ligne dans le sable, je dis que je ne peux regarder que cette zone et dire, d’accord, dans cette zone que j’ai délimitée dans le sable, oui, mon optimal pourrait être cela, peut-être que je peux même le prouver mathématiquement.”
Mais la réalité est que ce n’est qu’une ligne tracée dans le sable. Vous pouvez aller où vous voulez. Ainsi, oui, en fin de compte, lorsque vous pensez en termes de décisions commerciales, il n’y a pas de limite en dehors de l’intelligence et de l’ingéniosité des personnes qui vont travailler sur le cas.
Maintenant, je crois que l’industrie du logiciel a réalisé cela très tôt. Vous savez, c’est pourquoi, dès les années 70, tous les fournisseurs poussaient pour des avantages exprimés en termes de meilleure prise de décision. Ils faisaient littéralement de la publicité pour un système d’intelligence car ils réalisaient que le problème d’avoir une représentation électronique de votre inventaire était fini. Une fois que c’était bien fait, que feriez-vous ?
Il s’est avéré que les gens ont traversé des étapes. D’abord, vous aviez des interfaces textuelles, puis des interfaces graphiques comme avec les ordinateurs de bureau - la génération de clients lourds des années 90. De nos jours, vous avez des applications web et maintenant des applications mobiles. Ainsi, il s’est avéré qu’au niveau de l’interface utilisateur, il y a eu une série de transitions.
Même si le défi était fini, il s’est avéré que les entreprises de logiciels étaient toujours occupées à passer simplement du terminal texte à l’interface graphique à l’application web pour maintenant l’application mobile. Mais la chose est qu’il était très clair pour tout le monde que cette chose se terminerait d’une manière ou d’une autre, dans le sens où elle ne croîtrait pas indéfiniment pour devenir quelque chose d’extrêmement grand.
C’est pourquoi, très tôt, beaucoup de fournisseurs, y compris SAP, se sont lancés dans le branding par rapport à ces décisions, même si leur logiciel n’avait rien à voir en pratique avec la prise de meilleures décisions.
Conor Doherty: Eh bien, il me semble que nous avons beaucoup parlé de théorie, et c’est bien. Eh bien, la théorie mélangée à un peu de pratique ici, mais certainement, je veux essayer de rendre les choses un peu plus pratiques. Je veux vous poser la question de cette manière : Au début de l’épisode, j’ai mentionné DHL, Asda, Spar. Il y avait d’autres exemples dans le post d’Anthony Miller.
Si vous étiez dans une pièce aujourd’hui, si vous étiez dans la salle de réunion avec les décideurs, les gros bonnets, les grands acteurs, et qu’ils disaient : “D’accord Joannes, que devrions-nous faire ensuite ? Nous avons essayé ceci, cela n’a pas fonctionné. Quel serait votre conseil ?
Joannes Vermorel: Mon conseil est très simple. Les systèmes d’enregistrement ont été complètement banalisés il y a plus d’une décennie, en fait, il y a plus d’une décennie. Alors, prenons les choses étape par étape. Votre base de données va être, disons, PostgreSQL. C’est open source, c’est excellent.
C’était la chose à faire en 2010 quand SAP a dit : “Nous avons eu tellement de problèmes, nous voyons Oracle comme une menace stratégique.” Ce qu’ils n’ont pas réalisé, c’est qu’Oracle était insignifiant. Le véritable challenger était en fait open source.
Ainsi, la base de données relationnelle qui a gagné aujourd’hui est effectivement les bases de données open source. Les bases de données relationnelles sont maintenant une commodité complète au point que les tout meilleurs produits sont des projets open source, et PostgreSQL est bien loin devant Oracle et les bases de données privées.
Ainsi, nous nous retrouvons dans une situation où un grand fournisseur, SAP, qui voulait contenir un autre fournisseur, Oracle, a fini par développer une technologie qui se révèle être inférieure à un produit open source - qui est simplement PostgreSQL.
Et comment je sais que c’est inférieur ? Je veux dire, il suffit de regarder sur Hacker News ou de discuter de ce que font les startups de nos jours. J’ai audité un nombre à trois chiffres de startups. Je n’ai jamais vu une startup utiliser une base de données relationnelle non open source au cours de la dernière décennie. Jamais.
Elles n’utiliseraient que des bases de données open source. Je n’ai jamais vu une startup utiliser, par exemple, Oracle Database. Jamais. Donc, cela vous donne le sentiment que les personnes qui connaissent la technologie, qui travaillent dans la technologie, ne font pas ce choix. Tout d’abord, je dirais à cette salle de dirigeants : “Pour la couche de base de données, vous devez choisir l’une des excellentes options open source qui sont sur le marché.”
Cela peut être PostgreSQL. Ces solutions sont excellentes, et si vous ne le faites pas, la perte d’opportunité est énorme car ce que vous obtenez si vous choisissez l’une de ces bases de données, c’est qu’en plus de cela, vous avez littéralement plus d’un million d’ingénieurs logiciels qui sont déjà compétents sur ces technologies par rapport aux technologies privées, obscures et beaucoup plus difficiles à opérer. C’était le premier problème.
Ensuite, de quoi avez-vous besoin par-dessus ? Vous avez essentiellement besoin d’un framework pour déployer une application rudimentaire par-dessus la base de données. Il existe des tonnes de ces frameworks, et encore une fois, ils sont disponibles en open source. Ce serait Django si vous êtes en Python, ce serait le framework MVC en ASP.NET pour Microsoft, qui est également open source. La liste est longue. Ces frameworks existent pour toutes les principales piles technologiques - Python, Java, .NET.
Parce que c’est complètement banalisé, soit vous choisissez pour votre système d’enregistrement un fournisseur qui est déjà open source - ceux-ci existent - soit vous créez le vôtre, et ce n’est même pas si cher. Le truc, c’est que lorsque vous vous retrouvez avec un projet de cinq ans pour mettre à niveau un ERP, vous seriez bien mieux loti en déployant simplement votre propre remplacement morceau par morceau.
En six mois, vous pourriez avoir une série de modules qui sont déjà en cours de mise à niveau et de remplacement si vous le faites en interne ou avec l’aide d’une entreprise informatique. Encore une fois, la bonne chose à propos de ces systèmes d’enregistrement étant complètement banalisés, c’est qu’il est super facile de trouver des personnes qui peuvent le faire. Il est super facile d’externaliser ces choses - il est également super facile de le faire en interne si vous le souhaitez.
La barre est très basse ; c’est très bon marché. Lorsque vous regardez toutes les entreprises technologiques de ce monde - les Zalando de ce monde - elles ont développé leur propre ERP ; elles s’en sortent très bien avec. Si vous regardez Amazon, ils font la même chose ; JD.com fait la même chose. Toutes les personnes qui sont nées dans le numérique ont vu cela comme une solution évidente pour le système d’enregistrement.
Les enregistrements sont complètement banalisés. En fin de compte, ce n’est pas difficile de, je veux dire, ces produits ne devraient certainement pas être chers. S’ils sont chers, alors votre plan B devrait être : “D’accord, vous savez, je vais le faire moi-même.” Si vous demandez à un peintre de faire une peinture pour un mur de votre maison et qu’il dit que cela va coûter 2 millions d’euros.
Vous savez, c’est quatre mètres carrés, mais vous savez, si je ne peux pas faire mieux, vous diriez : “D’accord, je vais le faire moi-même.” Vous savez, si c’est la seule option, je le ferais moi-même. Oui, je préférerais ne pas faire la peinture, mais vous savez, nous ne parlons pas d’envoyer des fusées dans l’espace. Nous parlons de quelque chose de assez simple de toute façon.
Conor Doherty : Eh bien, encore une fois, parce que je prends des notes copieuses, comme vous pouvez le voir. Mais la question suivante que je voulais poser était, après avoir délimité les trois classes et encore une fois vous êtes de retour dans cette salle avec les dirigeants, et notre biais potentiel est clair, comme vous le savez. Lokad est un fournisseur en soi. En termes de coûts pour chacune de ces classes, car encore une fois, vous avez commenté plusieurs fois au cours des deux ou trois dernières minutes sur le fait que, “Regardez, je veux dire, vous pourriez essentiellement le faire vous-même.”
Je veux dire, si vous êtes technologiquement compétent, vous pourriez et vous êtes numériquement - le terme utilisé était “natif numérique”, vous pourriez concevoir votre propre système d’enregistrement. D’accord, eh bien, cela devrait probablement coûter moins cher qu’un système de rapports et un système d’intelligence ou comment allouez-vous le budget à cet égard ?
Joannes Vermorel : Je veux dire, clairement, les systèmes d’enregistrement sont beaucoup plus simples que le reste. Vous savez, encore une fois, ce sont ceux qui sont venus en premier. La technologie est complètement banalisée. L’open source fournit toutes les pièces dont vous avez besoin. Développer une application rudimentaire est l’exemple type de ce pour quoi les environnements de développement intégrés sont faits.
Donc, l’outillage est excellent, le cadre est excellent, et l’outillage est excellent. Vous avez des tonnes d’ingénieurs qui ont une productivité massive, et encore mieux avec les LLM de nos jours. C’est le genre de chose où l’IA générative est excellente pour écrire des tonnes de code non intelligent. Ces outils sont super efficaces pour cela.
Conor Doherty : Donc 20 milliards de dollars, c’est ce que nous devrions facturer.
Joannes Vermorel : Oui, donc cela devrait être relativement, je veux dire, cela devrait être assez bon marché à nouveau pour les entreprises comme base. Si vous finissez par payer plus d’un dixième de ce que vous avez payé pour des systèmes similaires il y a 10 ans, c’est une arnaque. Vous savez, c’est ce que vous devriez considérer comme base. Donc vous devriez chercher, “Nous allons le refaire, mais à un dixième du budget.” Et ce n’est même pas exagéré.
Je pense qu’au vu de l’évolution de la technologie, c’est un point de départ. Je suis assez sûr que si vous deviez aller dans le fou, l’agressif - disons qu’Elon Musk prend le cas en main - ce serait, “Je vais le faire pour 100 fois moins cher.” Mais je dirais que votre prochain projet ERP devrait coûter un dixième du coût de ce que vous avez dépensé il y a 10 ans. Je pense que c’est une base raisonnable, du moins pour les systèmes d’enregistrement.
Pour le système de rapports, la technologie est assez emballée. Le problème est qu’il finit généralement par être très coûteux parce que l’entreprise veut simplement une quantité astronomique de rapports. Le coût est la mise en œuvre, sur mesure, d’un nombre illimité de rapports - un nombre incroyablement élevé de rapports.
Donc, lorsque vous avez un système de rapports, à un moment donné les gens diraient, “Oh, mais j’aimerais avoir quelques rapports prêts à l’emploi, des modèles tout faits.” Et ensuite le fournisseur dirait, “Oui, pas de problème, combien en voulez-vous ?” Et ensuite ils énumèrent, et vous vous retrouvez avec des milliers de rapports. Si vous faites cela, cela devient incroyablement coûteux simplement parce que vous en demandez tellement.
Donc ici, cela devrait être assez bon marché car la technologie est assez emballée, mais plus que les systèmes d’enregistrement. C’est plus difficile, donc c’est le genre de chose où je ne conseillerais pas de le faire soi-même. Mais encore une fois, avec des technologies open source comme Spark, ce n’est pas si difficile. Bien que ce soit plus difficile que les systèmes d’enregistrement.
Ici, je pense que si vous voulez garder le budget serré, vous devez garder vos exigences sous contrôle. Il y a cette tentation, surtout dans les grandes entreprises, de demander une liste interminable de rapports que personne ne va jamais consulter. Cela s’avère être très coûteux car toutes ces personnes doivent regarder ces chiffres de temps en temps, et cela n’a pas vraiment de sens.
Donc, gardez-le court et concentré, et le coût ne sera pas très élevé. En fait, il devrait être beaucoup plus petit que le coût de votre ERP de base d’il y a 10 ans. J’ai dit que le nouveau ERP devrait être presque un dixième de cela. Le système de rapports devrait être une fraction de ce coût, pas plus de 20% du coût de cet ERP de nouvelle génération.
C’est de cela dont nous parlons, quelque chose de très petit. En fin de compte, les rapports ne devraient pas coûter des millions ou des dizaines de millions pour rapporter des statistiques descriptives de base sur votre entreprise. Il n’y a pas de sens à cela. La technologie a suffisamment progressé pour que cela devrait être très bon marché.
Conor Doherty : Lorsque vous avez d’abord proposé la catégorisation des trois classes ou classification des trois types de logiciels d’entreprise - Vous - je ne me souviens pas du ratio exact, mais c’était quelque chose comme 90% de votre budget informatique devrait aller aux systèmes d’intelligence.
Joannes Vermorel : La division que j’ai proposée était de 20% pour l’ERP, 5% pour les systèmes d’enregistrement et 75% pour - désolé, 20% pour les systèmes de rapports, 5% pour les systèmes d’intelligence et 75% pour les systèmes d’intelligence. C’est ce que je suggère comme une heuristique pour la quasi-totalité des entreprises.
En revanche, ce qui se passe aujourd’hui, c’est 75% pour l’ERP, 20% pour la business intelligence ou les systèmes de rapports, et seulement 5% pour les systèmes d’intelligence. Je dis que ces chiffres sont faux. Nous devons les échanger. Pourquoi devriez-vous dépenser la majeure partie de votre argent dans les systèmes d’intelligence ?
De toute évidence, Lokad est un système d’intelligence, donc le public devrait dépenser beaucoup d’argent. Mais la réalité est qu’il y a un retour sur investissement exactement. C’est là que vous pouvez avoir un retour sur investissement important si les décisions sont prises correctement. Les systèmes de rapports sont principalement là pour s’assurer que vous n’êtes pas en feu.
C’est regarder en arrière pour voir si vous êtes conforme à vos propres processus, si vous êtes sur la bonne voie. Mais fondamentalement, aucune entreprise n’a jamais connu un succès massif en regardant simplement en arrière. C’est le problème des systèmes de rapports. Vous regardez dans le rétroviseur.
Si vous voulez gagner une course, vous ne gagnez pas une course en ayant les yeux rivés sur le rétroviseur. À un moment donné, vous devez regarder devant vous.
Conor Doherty : Il me vient à l’esprit que j’ai effectivement un ordinateur portable devant moi, et celui-ci a le Wi-Fi. Le blog auquel je faisais référence s’appelle en réalité “Les Trois Classes de Logiciels d’Entreprise”. C’était en juin de l’année dernière.
Juste pour clarifier les chiffres, vous avez rappelé correctement comment les entreprises, la quasi-totalité des entreprises, divisent généralement leurs dépenses - leur budget informatique est de 75 % pour les systèmes de données, et vous avez mis “faux” entre parenthèses après cela. 20 % pour les systèmes de rapports, également “faux”, et 5 % pour les systèmes d’intelligence, avec “complètement faux” à la fin.
Inversé 75 % pour les systèmes d’intelligence, cinq pour les systèmes de rapports, et 20 pour les systèmes de données. Maintenant, euh, je recommande vivement la lecture du blog. Il est très bon.
Maintenant, euh, dernière question avant de commencer à conclure, mais c’est une question qui me vient à l’esprit. Euh, c’est un point que vous avez déjà mentionné dans vos conférences, et que j’ai mentionné quelques fois dans nos conversations ici : le rôle de la sympathie mécanique. Et nous n’avons pas besoin d’en parler très longtemps, mais il me semble qu’une familiarité de base avec, disons, quels sont les paramètres requis ou les choix de conception architecturale nécessaires pour exceller avec l’outil que vous envisagez d’acheter ?
Si vous êtes quelque peu familier avec cela, vous pouvez au moins avoir une idée du genre de chose qui pourrait ne pas vous convenir. Donc, encore une fois, même simplement la différence entre les bases de données en colonnes et tabulaires - si vous comprenez bien ce que ce système utilise et ce que je veux de ce système ? Cela pourrait vous amener à reconsidérer immédiatement un choix potentiellement coûteux.
Joannes Vermorel : Oui. Et encore une fois, si nous revenons sur les sortes d’erreurs que SAP a commises en, euh, en 2010… Je veux dire, HANA a été lancé en 2010, donc ils étaient probablement déjà en train de travailler sur cela depuis quelques années. Et à l’époque, je suppose que cela semblait être une bonne idée, vous savez, cela semblait dire, “D’accord, supposons que ces latences que nous avons à l’intérieur des systèmes informatiques vont simplement s’améliorer, continuer à s’améliorer, que la mémoire va continuer à devenir beaucoup moins chère.”
Parce que, encore une fois, si nous regardons quelle est la grande différence entre 2010 et, disons, euh, l’année, euh, 15 ans plus tôt, vous savez, 1995. Pendant ces 15 ans, la mémoire était devenue radicalement moins chère et radicalement plus abondante. Je me souviens à l’époque, en 1995, je me souviens du premier ordinateur que j’ai utilisé, Windows 95, avait quelque chose comme 8 mégaoctets de mémoire.
Et puis, à l’époque de 2010, c’était, je pense à l’époque, Windows 7 ou quelque chose comme ça. Je suppose qu’à l’époque j’avais 8 gigaoctets, vous savez, donc cela avait augmenté d’un millier sur cette période. Et la latence avait été divisée par quelque chose comme un facteur 50 ou quelque chose comme ça.
Donc, si cela avait continué sur cette voie, cela aurait été incroyable. Cela voudrait dire que, vous savez, j’avais 8 Go sur mon ordinateur en 2010. Si 15 ans plus tard cela s’était amélioré de la même manière, j’aurais eu 8 téraoctets sur mon ordinateur aujourd’hui. Ce n’est pas ce que j’ai, bien sûr, sur mon ordinateur. Personne n’a 8 téraoctets sur son ordinateur.
Mais vous voyez que si la technologie avait progressé comme elle l’avait fait les 15 années précédentes, c’est ce que les gens auraient eu. Et si nous avions également une réduction similaire de la latence, le problème est que la vitesse de la lumière est un tel obstacle, vous savez. La physique ne vous facilite pas la tâche. Vous avez cette vitesse de la lumière qui est un peu sur votre chemin.
Néanmoins, je pense que c’était, je pense, qu’ils ont commis cette erreur tragique. Et à partir de là, tant de choses ont dû être surconçues par-dessus parce que c’est comme le péché originel. À cause de cela, vous avez tellement de camouflage que vous devez faire juste pour… Quand vous avez un énorme problème de conception comme ça, vous pouvez essayer de vous en sortir avec du ruban adhésif. Vous le pouvez, mais tout sera maladroit.
Et donc, lorsque vous êtes confronté à des problèmes de performance, vous pouvez les résoudre en ajoutant du matériel par-dessus. Oui, vous pouvez évidemment commencer à acheter du matériel super cher, ce serait la première étape. Mais ensuite, vous pouvez surconcevoir comme des fous certaines choses pour que ce ne soit pas trop dysfonctionnel. Parce fondamentalement, avec suffisamment d’ingénierie, vous pouvez atténuer certains de ces problèmes.
Mais quand même, SAP veut tout couvrir, avec l’ambition que je décrivais. Vous voulez être le système de référence pour une chose, mais ils veulent être le système de référence pour tout. Ce qui signifie que la surface où vous pouvez avoir des problèmes de performance juste à cause de ce choix est absolument gigantesque.
Et je crois que ce que nous voyons, c’est juste, vous savez, au ralenti, les choses imploser au ralenti. C’est ce que nous voyons. Cela prend beaucoup de temps. Il a fallu cinq ans pour sortir un ERP sur HANA, c’est S/4. Et puis il a fallu des années pour vendre un ERP à leur première entreprise.
Parce que, encore une fois, lorsque vous voulez vendre des logiciels d’entreprise, vous ne concluez pas l’affaire en six mois ; cela prend fréquemment plusieurs années. Donc, il faut environ un cycle de demi-décennie pour mettre en œuvre. Et peut-être une fois que vous avez pris une demi-décennie, c’est votre plan pour la mise à niveau.
C’est fou. Mais la réalité est que vous commencez à échouer parce que cela ne prend pas une demi-décennie, cela prend une décennie entière. Nous assistons donc à des échecs causés par de mauvaises décisions prises il y a longtemps. Et nous remontons dans les décennies passées. Je pense que nous verrons ces problèmes continuer à surgir, mais ce n’est pas nouveau. Cela reflète simplement des erreurs qui ont été commises il y a longtemps.
Et maintenant, la seule chose que nous pouvons vraiment suggérer, c’est de ne pas répéter les erreurs anciennes. Mais la chose folle, c’est que ces erreurs ont été commises il y a si longtemps que les gens de SAP… Je veux dire les erreurs de SAP, et les gens qui les ont adoptées en pensant que ce serait juste.
Et la chose intéressante, c’est que ces erreurs ont été commises il y a si longtemps que les gens pourraient penser : “Oh, mais de nos jours, ça devrait être juste.” Ils ont rassemblé leurs affaires. Ils ont rassemblé leurs esprits. C’est résolu. Parce que évidemment, en tant que fournisseur, si je devais présenter un tel produit, je dirais : “Cher prospect, soyez assuré que nous avons appris de nos erreurs. Ces choses ont été corrigées. Ces erreurs, nous en avons tellement appris. Elles ne se reproduiront pas.”
Je dirais, pas tout à fait, car le problème est toujours au cœur même de votre technologie. HANA est toujours au premier plan de toutes les offres de SAP. Tant que c’est… Oui, vous êtes fichu. Vous devez défaire tout cela pour commencer à entrer éventuellement dans des territoires plus sains.
De nos jours, à moins de changer de cap et de simplement supprimer HANA, opter pour PostgreSQL ou tout ce qui est open source, puis découper leur offre de manière à avoir des applications légères et étroitement découplées. L’intégration des choses sur Internet est assez facile de nos jours, donc ils pourraient avoir une conception super modulaire.
À moins de commencer à faire cela, les péchés originels sont toujours là ; l’ambition d’être le système de tout plus le mauvais moteur au cœur du système.
Conor Doherty : Eh bien, pour essayer de finir sur une note positive, avez-vous des conseils constructifs à partager avec les gens afin qu’ils puissent peut-être contourner, entre guillemets, les pièges que certaines de ces énormes entreprises ont commis ?
Joannes Vermorel : Je veux dire, le véritable point positif, et c’est là que cela me rend très triste quand je vois ces erreurs, c’est que la communauté open source a livré quelque chose d’incroyable. PostgreSQL est une merveille d’ingénierie. C’est open source. C’est magique.
Nous vivons à une époque où, littéralement pour le prix, ce n’est pas exactement gratuit - vous devez bien sûr payer pour votre connexion Internet - mais pour un prix incroyablement bas, vous pouvez avoir des systèmes incroyablement bien conçus ou des morceaux d’ingénierie qui représentent des centaines d’années de certains des ingénieurs les plus brillants de notre siècle. C’est incroyable, et vous pouvez obtenir cela gratuitement. C’est mon point de vue.
