Vos données sont meilleures que vous ne le pensez

00:00:00 Des données meilleures que vous ne le pensez
00:03:43 Pourquoi les mauvaises données deviennent un bouc émissaire
00:07:26 Faits transactionnels versus paramètres encombrants
00:11:09 Le “cake” de la couche de reporting compromet la prise de décision
00:14:52 Une vision axée sur la décision de l’information utile
00:18:35 Automatiser les paramètres : délais d’approvisionnement, saisonnalité, nouveauté
00:22:18 La complexité des ERP n’est pas de mauvaises données
00:26:01 Les champs de date cachent plusieurs significations du monde réel
00:29:44 La sémantique prouvée par les décisions générées
00:33:27 Les valeurs aberrantes révèlent de mauvaises méthodes, pas de mauvaises données
00:37:10 Les data lakes devraient copier, et non “améliorer”
00:40:53 La qualité des données mesurée en dollars
00:44:36 Préparation à l’IA : transactions fiables, sémantique en premier lieu
00:48:19 La double exécution nécessite une exécution entièrement sans intervention
00:52:02 Jeux de blâme entre fournisseurs : le récit édifiant de Lidl-SAP
00:55:45 La qualité équivaut à l’aptitude pour la prise de décision

Résumé

“Les mauvaises données” sont souvent un bouc émissaire. Les enregistrements transactionnels de la plupart des entreprises — ce qui a été acheté, vendu, expédié, retourné — sont suffisamment bons, sinon elles ne subsisteraient pas. Le véritable désordre réside dans la montagne de paramètres gérés manuellement et dans la confusion quant à la signification réelle des champs (la sémantique), en particulier dans les vastes ERPs. Ne “nettoyez” pas la réalité pour sauver des méthodes faibles : les valeurs aberrantes sont souvent l’essence de l’activité. Jugez les données par les résultats : si les décisions améliorent la rentabilité, les données étaient suffisantes ; si les issues sont insensées, corrigez l’interprétation.

Résumé Étendu

Une plainte familière en supply chain est que les “mauvaises données” freinent le progrès. Pourtant, une grande partie de ce que l’on qualifie de mauvaises données n’est ni mauvaise ni même centrale au problème. Il s’agit souvent d’une excuse commode — parfois de la part de fournisseurs qui cherchent quelqu’un d’autre à blâmer lorsque leur logiciel échoue, et parfois d’analystes habitués à des ensembles de données impeccables en salle de classe, et qui sont stupéfaits par l’ampleur réelle des systèmes d’entreprise. Un ERP avec des milliers de tables n’est pas la preuve de mauvaises données ; c’est la preuve d’une complexité.

La discussion établit une distinction nette entre deux types de “données”. La première est la réalité transactionnelle : ce qui a été acheté, vendu, expédié, retourné, mis au rebut, payé — des événements ayant des conséquences financières. Cette information est généralement fiable, pour une raison simple : les entreprises qui ne parviennent pas à maintenir la vérité transactionnelle de base ne durent pas longtemps. Les marchés sanctionnent rapidement ce niveau de confusion. Des erreurs existent, mais généralement à de faibles taux.

La seconde correspond à une montagne de paramètres gérés manuellement — cibles de taux de service, coefficients de stock de sécurité, indicateurs de saisonnalité et délais d’approvisionnement saisis par des agents. Ces “artefacts numériques” sont régulièrement obsolètes, incohérents et coûteux à maintenir à grande échelle (des millions de SKUs multipliés par plusieurs paramètres). Mais l’important est qu’ils sont souvent inutiles. Beaucoup de ces entrées devraient être déduites de l’historique observé ou automatisées grâce à de meilleures méthodes. Les traiter comme des “données de base” crée un fardeau auto-imposé.

Un problème caché majeur est la sémantique : ce que signifie un champ. La même colonne peut changer de signification au fil du temps, selon les processus d’entreprise, ou même selon le signe (vente vs retour). La documentation est généralement maigre au début. La seule méthode fiable pour valider la sémantique n’est pas d’organiser des ateliers interminables, mais de mettre les interprétations à l’épreuve : générer de réelles décisions — quoi acheter, produire, stocker, tarifer — et observer si les résultats deviennent absurdes. Dans ce cas, vous reconstituez le processus pour identifier l’hypothèse erronée.

Cela requalifie également les “données bruyantes”. Si les clients commandent parfois 1 et parfois 100, ce ne sont pas de mauvaises données — c’est l’activité. Les méthodes qui s’effondrent face aux valeurs aberrantes sont défectueuses ; les données ne devraient pas être falsifiées pour sauver des mathématiques faibles.

Enfin, en ce qui concerne la “préparation à l’IA” : l’exigence n’est pas la pureté morale des données. Il s’agit de leur adéquation à l’usage. Si vous savez ce que vous achetez, produisez et vendez, vous pouvez commencer. Le véritable travail consiste à cartographier la sémantique, système par système, puis à itérer rapidement jusqu’à ce que les décisions soient sensées. En fin de compte, la qualité n’est pas un slogan ; elle se mesure à la performance économique des décisions.

Transcription Complète

Conor Doherty: Voici Supply Chain Breakdown, et aujourd’hui, nous allons expliquer pourquoi vos données sont, en fait, meilleures que vous ne le pensez. De nombreuses entreprises nous disent que leurs données les empêchent de lancer les projets qu’elles désirent. Eh bien, aujourd’hui, nous sommes là pour remettre en question cette idée. Nous demeurons constructifs.

Qui sommes-nous ? Eh bien, je suis Conor, Directeur Marketing ici chez Lokad. À ma gauche, comme toujours, le fondateur de Lokad, Joannes Vermorel. Maintenant, avant de commencer, faites-nous savoir ci-dessous : d’abord, de quel coin du monde nous regardez-vous ? Nous sommes à Paris. Et ensuite, êtes-vous d’accord, ou pensez-vous même, que le master data constitue en réalité un goulot d’étranglement pour les projets de transformation digitale, ceux dans lesquels les entreprises souhaitent réellement s’engager de nos jours ? Laissez vos commentaires et questions ci-dessous. Nous y reviendrons un peu plus tard.

Et sur ce, Joannes, place à la discussion. Maintenant, avant de rentrer dans le vif du sujet, un petit contexte : comment cette discussion a vu le jour. Comme vous le savez, dévoilez les coulisses : à la fin de chaque épisode, je dis, “Hé, si vous souhaitez poursuivre la conversation, contactez Joannes et moi en privé. Nous serons ravis d’échanger.” Tout cela est vrai. Enfin, certaines personnes le font. Elles veulent discuter.

Et récemment, tant collectivement qu’individuellement, nous avons eu des discussions, et un thème récurrent chez les praticiens consiste à déplorer l’état des données : par exemple, “Mes master data sont un spaghetti”, “Mon ERP est comme du gruyère”, etc. Mais voilà, c’est là le problème. C’est ce qui m’empêche de réaliser toutes les choses intéressantes que je souhaite faire. Et c’est ainsi que nous en sommes arrivés au sujet d’aujourd’hui.

Alors, Joannes, pourquoi les données ont-elles une si mauvaise réputation en supply chain ?

Joannes Vermorel: Je peux penser à plusieurs raisons, selon le public.

Pour les fournisseurs de logiciels, les mauvaises données constituent le bouc émissaire ultime. C’est une manière de reprocher poliment mais fermement aux clients tout défaut du produit logiciel. C’est donc extrêmement commode, et de bons fournisseurs, des fournisseurs talentueux, parviendront à convaincre les clients que tout leur incombe si tout s’effondre parce qu’ils avaient des pratiques de données insuffisantes, un contrôle qualité défaillant, et ainsi de suite.

Joannes Vermorel: Mais voici mon point de vue : il s’agit vraiment de trouver un bouc émissaire. Le deuxième public concerne les data scientists, en particulier ceux qui viennent de ce milieu… qui ont participé, dirais-je, à des compétitions Kaggle. Ils sont habitués, surtout à l’université, à des ensembles de données impeccables et bien ordonnés, et ils considèrent cela comme la norme. Ils pensent qu’avoir un jeu de données composé de cinq tables, chacune ayant cinq champs, avec une documentation exhaustive pour chaque champ, et que tout soit très, très clair — d’accord. Pour moi, c’est le problème d’attentes complètement irréalistes.

Dans les entreprises, je veux dire, si nous prenons les ERPs du marché intermédiaire, nous parlons de 10 000 tables. Certaines tables contiennent 50 champs. Voilà de quoi il s’agit. Nous avons donc ici un problème de data scientists ayant des attentes totalement déraisonnables quant à ce que sont réellement les données d’entreprise.

Et il y a un troisième segment, celui des praticiens. En effet, ce qu’ils examinent, c’est généralement la paramétrisation de leur système d’entreprise. Ils ne se penchent pas sur quelque chose de réel, par exemple : une unité vendue à une date donnée, à un prix donné. Ce n’est généralement pas l’enjeu. Ce n’est pas le sujet des événements transactionnels clés du passé.

Ce qu’ils observent, c’est : “Oh, mais regardez, les réglages de saisonnalité que nous avons saisis dans l’APS il y a deux ans sont totalement décalés aujourd’hui à cause de ceci, à cause de cela.” “Regardez, nous avons tant de coefficients correctifs pour la formule de stock de sécurité, et ils sont également complètement erronés”, etc. En fait, lorsque ces praticiens se plaignent de mauvaises données, ils se plaignent très spécifiquement des artefacts numériques — des éléments qui ne représentent ni le passé ni l’avenir. Ils reflètent une sorte de paramétrisation des politiques de l’entreprise.

Et mon point de vue est le suivant : si l’on revient au premier cas, celui du fournisseur de logiciels, le problème réside dans le fait que si la solution logicielle que vous utilisez dépend tellement de cette paramétrisation gérée manuellement, il est assuré que vous vous dirigez vers des ennuis. Ainsi, la seule solution est de cesser de traiter ces éléments comme s’ils étaient des données. Ils ne devraient même pas faire partie du tableau, afin que vous n’ayez pas à y faire face.

Conor Doherty: Vous pouvez me corriger si je me trompe, mais il semble que, selon vous, il existe globalement deux catégories de données. Ainsi, lorsque les gens parlent de “données”, ils pensent par essence à deux catégories. L’une correspond aux artefacts numériques — les éléments qu’ils ont définis pour eux-mêmes, certains objectifs — et l’autre aux vraies données transactionnelles brutes, que vous considérez comme étant bien, bien plus importantes.

Joannes Vermorel: Oui. Je veux dire, les vraies données de transaction correspondent à ce qui s’est passé. Encore une fois : vous avez vendu ou pas. Vous avez payé le fournisseur, vous avez passé une commande, vous avez prélevé une unité du stock, vous avez détruit une unité qui était en réalité périssable et dont la durée de vie a été dépassée, etc., etc. Ce sont des données transactionnelles, et elles sont généralement excellentes.

Joannes Vermorel: Cependant, dans de nombreuses solutions d’entreprise, vous avez également une montagne de paramètres censés être gérés par des agents — des personnes qui se contentent d’opérer le système. Et la question est : pourquoi avez-vous même besoin d’avoir ces millions de paramètres ? Parce que très souvent, il s’agit d’une quantité énorme de paramètres.

Pour vous donner une idée de l’échelle : une entreprise qui possède un million de SKUs, ce qui n’est en fait pas si énorme — si vous avez, disons, 10 paramètres par SKU, et je suis conservateur ici, cela peut être bien plus — 10 paramètres par SKU, nous parlons donc de 10 millions de paramètres à gérer plus ou moins manuellement. Et c’est de la folie.

Joannes Vermorel: Ensuite, les gens disent : “Oh, c’est nul parce que nous ne pouvons vraiment pas le maintenir.” Je dirais : oui, absolument. Mais la réalité est que vous n’en avez pas vraiment besoin. Et toutes ces choses ne transmettent pas véritablement d’information, car la manière dont ces paramètres ont été définis était de toute façon basée sur le reste des données.

Joannes Vermorel: Quand les gens définissent, par exemple, un objectif de taux de service, ils le font en se basant sur l’historique transactionnel. Vous voyez donc, cette information est en fait totalement transitoire, et elle ne devrait pas être considérée comme faisant partie de vos données de base. Voilà pourquoi je dis : les mauvaises données sont un problème bien, bien moins important que ce que les gens imaginent. C’est simplement parce qu’ils traitent comme des données une grande partie d’éléments qui ne devraient pas l’être.

Joannes Vermorel: Il y a également un second aspect, mais c’est un problème distinct. Il s’agit du cas où les gens veulent mener une analyse approfondie à partir de données prétraitées, en particulier celles issues de la couche de reporting.

Joannes Vermorel: De nouveau, je divise les logiciels d’entreprise en trois catégories : les systèmes de référence — ce qui correspond aux ERP à l’exception de la planification, car il n’y a pas de planification impliquée —, les systèmes de reporting, qui correspondent à la business intelligence et tous ces systèmes de dashboarding et de reporting, et enfin les systèmes d’intelligence, ceux qui effectuent la prise de décision.

Joannes Vermorel: La seule source de vérité pour les données se trouve dans les systèmes de référence. Mais très souvent, parce que les gens sont parfois mal orientés, occupés, ou autre, ils veulent exploiter les données telles qu’elles sont présentées par le système de reporting. Et nous sommes alors dans une situation qui, par analogie, ressemble beaucoup à celle d’un cuisinier.

Imaginez que vous avez une cuisine, vous disposez de tous les ingrédients bruts — farine, sucre, sel — et ce sont les systèmes de référence, les ingrédients bruts. Ensuite, le cuisinier, via le système de reporting, peut préparer un gâteau. Vous obtenez un gâteau, c’est agréable, vous pouvez consommer le gâteau. Il est destiné à la consommation humaine, donc cela fonctionne.

Maintenant, vous demandez au cuisinier : “Prenez simplement ce gâteau et faites-en autre chose.” Et c’est exactement ce qui se passe lorsque vous essayez d’utiliser les données provenant de votre couche de reporting pour, par exemple, orienter les processus de prise de décision. Cela se passe très, très mal. Ce n’est pas que le cuisinier soit mauvais ; c’est simplement que si vous partez du gâteau, vous ne pouvez rien y changer. C’est déjà le produit fini. Essayer de démêler le sucre, la farine, etc. — tout est perdu.

Vous devez donc retourner aux ingrédients bruts si vous voulez faire autre chose. C’est également une erreur typique que j’ai vue commettre par de nombreuses entreprises : elles se contentent d’examiner les données de la couche de reporting, destinées à la consommation humaine, et tentent d’extraire ces données pour les retraiter à d’autres fins. C’est une erreur. Vous devez revenir aux ingrédients bruts.

Conor Doherty: Eh bien, en ce qui concerne ce point — l’idée de revenir aux ingrédients bruts, de revenir à vos données fondamentales — j’ai en fait un… pensez ce que vous voulez à propos de la source. Je l’utilise simplement pour donner un peu de contexte et montrer que nous ne spéculons pas ici.

Je suis en train de consulter un rapport Gartner qui a interrogé des centaines de très grandes entreprises, et il s’avère que la plupart des entreprises ne mesurent même pas la qualité des données de manière cohérente. Ce qui se passe réellement, c’est qu’on a simplement le sentiment que nos données sont mauvaises, mais ce n’est pas nécessairement un fait mesuré.

Il y a donc deux questions ici. Premièrement : cela vous surprend-il globalement ? Et deuxièmement : comment les entreprises pourraient-elles rapidement diagnostiquer la santé de leurs données ?

Joannes Vermorel: Tout d’abord, si l’on considère les données transactionnelles, la réponse est simple : votre entreprise est-elle profitable ? Si oui, alors elle dispose de données de haute qualité. Pourquoi ? Parce que je n’ai jamais rencontré une entreprise qui, ne sachant pas ce qu’elle achetait, vendait ou produisait, parviendrait à survivre.

Si vous ne savez même pas cela, vous ferez faillite à la vitesse de la lumière. Si vous ne savez pas ce que vos fournisseurs vous ont envoyé, alors vous allez être facturé plusieurs fois. Si vous ne savez pas ce que vos clients ont réellement acheté, alors vous ne les facturez pas correctement. C’est très rapide. C’est le darwinisme en action. Les marchés éliminent sans pitié ces entreprises ; elles disparaissent.

Alors, en règle générale : si vous travaillez dans une entreprise qui n’est pas sur le point de faire faillite à cause d’une mauvaise gestion, l’historique transactionnel est très probablement de très haute qualité. Oui, une erreur de saisie peut se glisser, environ une ligne sur mille — typiquement l’ordre de grandeur que je constate dans la plupart des entreprises. Vous aurez entre, disons, 0,1 % et parfois jusqu’à 0,5 % d’erreurs de saisie, mais c’est très, très faible. De nombreuses entreprises sont même en dessous de ce seuil.

Maintenant, si nous parlons de toutes les données optionnelles — par exemple, vous disposez d’une paramétrisation dans votre système qui vous permet de décider du taux de service cible pour un SKU — qu’est-ce que cela signifie d’avoir des données de haute qualité ici ? C’est absurde.

Si j’adoptais le rôle de l’avocat du diable, je devrais examiner à quel point ce paramètre se rapproche de la maximisation du taux de retour de l’investissement en stocks de l’entreprise lorsque ce paramètre est en place. Nous n’allons jamais faire cela. C’est beaucoup trop compliqué. Si vous adoptez réellement l’idée que votre supply chain doit maximiser le taux de retour, tant mieux, mais alors vous éliminerez très, très rapidement toutes ces approches non économiques.

En résumé : dans cette paramétrisation, oui, il y a généralement beaucoup d’éléments sans intérêt. La réalité est que les entreprises peuvent s’en accommoder parce que, disons, un planificateur de stocks se contentera de regarder le reapprovisionnement recommandé, et cela n’aura pas beaucoup de sens, mais le même planificateur consultera l’historique récent, quelques éléments, et en une minute, il dira : « D’accord, commandez 50 unités », puis passera au SKU suivant.

Donc oui, si vous voulez robotiser, ou faire quoi que ce soit d’automatisé, basé sur ces données de paramétrisation, la qualité des données est très, très faible. Mais la seule solution est de considérer les systèmes logiciels comme des systèmes d’intelligence qui ne se basent pas sur cette paramétrisation, laquelle n’est qu’une fonctionnalité de support pour un processus centré sur le workflow.

Conor Doherty : Eh bien, je note juste une réflexion pour approfondir cela car, encore une fois, dans la mesure du possible, j’aime amplifier tout point de réflexion constructive.

Notre perspective, comme tout le monde le sait, est que le but des données, le but même de travailler dans une entreprise, est de prendre de meilleures décisions — des décisions meilleures qui génèrent réellement plus d’argent. Maintenant, vous avez souligné que de meilleures décisions ne résident pas dans le système de rapports ; elles se trouvent déjà dans vos données transactionnelles.

Donc, en somme, pour que les gens prennent de meilleures décisions — définissez « meilleures » comme vous le souhaitez, tel que nous le définissons en maximisant le taux de retour — mais pour tous ceux qui écoutent, si vous disposez de données transactionnelles, vous pouvez déjà commencer à prendre des décisions positives.

Joannes Vermorel : Ce que j’ai remarqué pour presque toute la clientèle de Lokad — et nous parlons d’un flux annuel de marchandises de plus de 20 milliards que Lokad pilote —, c’est que 99 % de l’information vient, et même plus en réalité, il s’agit probablement de 99,99 % de la masse d’information, provenant des systèmes transactionnels.

En plus de cela, vous aurez probablement quelques dizaines de méta-paramètres — des moteurs économiques — qui doivent être maintenus manuellement. Mais ici, il faut être très conservateur, et en pratique, il n’y en a que quelques dizaines. Donc, la qualité des données ici doit être élevée. C’est difficile, mais nous parlons d’un nombre très restreint de paramètres importants — des paramètres suffisamment cruciaux pour mériter plusieurs réunions par paramètre.

Mais au final, il doit s’agir d’un paramètre stratégique, économique, de haut niveau, et non de quelque chose s’appliquant au niveau d’un SKU. Tout cela doit être entièrement robotisé, et c’est possible.

C’est pourquoi je dis que les données sont généralement excellentes, car ce dont vous avez besoin, c’est de l’historique transactionnel. Si vous abordez correctement un problème, vous n’avez pas besoin d’avoir des millions de paramètres dans votre système, qui doivent être maintenus manuellement et qui peuvent revêtir tant de formes.

De nombreux systèmes demandent aux praticiens de saisir le délai d’approvisionnement. Mais pourquoi devez-vous saisir ce délai ? Vous observez les délais d’approvisionnement de votre fournisseur. Ainsi, les délais doivent être prévus, et non saisis par l’utilisateur.

De nombreux systèmes demandent à l’utilisateur de classer et de dire, par exemple, « Est-ce un article saisonnier ? » Pourquoi devriez-vous effectuer manuellement ce type d’opération qui devrait être entièrement automatisé, même si la seule information dont vous disposez est l’étiquette du produit ? De nos jours, avec les LLMs, il n’a jamais été aussi facile d’automatiser ce genre de détection. « J’ai un nouveau produit ; est-ce que cela présentera des schémas saisonniers ? » C’est assez simple.

Il n’est pas nécessaire qu’un humain intervienne pour dire, « Oh oui, une combinaison de ski, oh oui, cela va être saisonnier. D’accord, merci. » C’est la réalité : ce sont des questions très basiques, et tous les systèmes demandaient aux praticiens de continuer à saisir tant d’informations qui sont complètement évidentes et qui peuvent être automatisées.

Même des choses qui sont parfois extrêmement déroutantes : les praticiens doivent saisir manuellement si c’est un nouveau produit. Pourquoi faut-il que quelqu’un informe le système qu’il s’agit d’un nouveau produit ? Vous pouvez constater dans l’historique qu’il n’y avait aucune transaction. Le produit a été créé récemment dans le système, il n’y a aucune transaction — pourquoi doit-on le définir manuellement comme nouveau produit ? C’est un sacré non-sens.

Mais encore une fois, mon point de vue est que toutes ces inepties dans ce domaine, dans cette paramétrisation pour toutes ces politiques, reflètent une manière obsolète de concevoir la supply chain. Ainsi, quelles que soient les mauvaises données dont vous disposez à cet égard, elles sont sans importance. Ce qui compte, ce sont les données transactionnelles, et ces données sont bonnes, parce que votre entreprise est en vie.

Conor Doherty : Eh bien, à ce sujet — et encore, c’est pour approfondir un peu plus les causes de cette perception — car il est inutile de simplement dire « J’ai un problème. » C’est plutôt, « D’accord, quelles en sont les causes ? Quelle est la racine du problème ? »

Donc, en vous écoutant, il semblerait qu’il y ait… d’accord, je vais donner un exemple concret et ensuite vous pourrez rebondir dessus. J’ai entendu, et je sais que vous avez entendu, une version de ceci : « Mon ERP est un désordre. » Et il s’agit du système d’enregistrement dont ils parlent, le registre des données transactionnelles : « J’ai des tables dupliquées, j’ai des colonnes mal étiquetées, c’est un désordre. »

Techniquement, toutes les données transactionnelles, les données brutes, sont présentes. Le problème — s’il y en a un, et nous pouvons en discuter — est le suivant : la migration ERP que vous avez effectuée a produit un désordre. Et laissez-moi préciser : nous ne vendons pas d’ERP, nous pouvons travailler avec n’importe quoi, donc nous n’avons aucun intérêt direct dans ce domaine.

Mais ma question pour vous est la suivante : quel rôle important joue le choix du logiciel dans la production de cette épidémie de mauvaises données ?

Joannes Vermorel : Là encore, je dirais que c’est dû à des attentes erronées. C’est exactement ce qui s’est passé lorsque j’ai mentionné le second public : les data scientists, les compétitions Kaggle. Je n’ai jamais prétendu que l’ERP, ces systèmes d’enregistrement, allaient être propres et bien organisés. La complexité sera démesurée, et c’est tout à fait normal.

Cela ne constitue pas de mauvaises données. Ce sont simplement des données très complexes et très opaques — des problèmes différents. Maintenant oui, lorsqu’on a 10 000 tables, il est très difficile de localiser où se trouve le niveau de stocks. C’est difficile, et cela peut prendre des semaines pour retrouver où une donnée réside réellement dans le système. Mais encore, ce ne sont pas de mauvaises données.

Ensuite, il y a un autre problème : la sémantique pour une colonne donnée peut être hétérogène. Que veux-je dire ? Je veux dire que la signification que peut revêtir une colonne de données peut varier selon la ligne. C’est une complication.

Juste un exemple : certains fournisseurs ERP mal avisés, il y a des années, ont décidé, par exemple, que dans la table des commandes, si la quantité était positive, il s’agissait d’une vente, donc vous vendez à un client, et la date correspond à la date de transaction de la vente. Mais si la quantité est négative, il s’agit d’un retour, donc c’est la date de retour de l’article. Cela signifie que j’ai une colonne appelée “order date”, sauf que ce n’est pas une date de commande lorsque la quantité est négative : c’est en réalité une date de retour.

C’est ce que je veux dire : sémantique hétérogène — que dans la même colonne, selon la ligne et selon certaines conditions, parfois c’est comme si l’ERP avait été mis à jour et qu’à partir du 1er janvier 2020, la “order date” signifiait autre chose. Cela est dû à une mise à niveau du système, la sémantique a évolué au fil du temps.

Parfois, ce peut même être les équipes de l’entreprise qui décident, à un moment donné, de changer le processus, redéfinissant ainsi la sémantique d’un champ donné, qui obtient alors une nouvelle signification. C’est donc très complexe, oui, et il faut le déceler — oui.

Mais encore, est-ce que cela constitue de mauvaises données ? Si vous connaissez votre fournisseur ERP, peut-être parce qu’il était un peu incompétent en matière de conception logicielle, et qu’il a décidé que “order date” pouvait être soit la date de vente, soit la date de retour — oui, c’est malavisé, mais est-ce mauvais ? Je soutiens que les données sont simplement bonnes. C’est juste une question de sémantique confuse.

Nous revenons au fait qu’il faut beaucoup de travail pour rétablir correctement cette sémantique, et j’en conviens. Mais lorsque les gens me disent “mauvaises données”, je réponds très fréquemment : non, vos données sont tout à fait correctes. Il faut simplement entreprendre le travail sérieux de réétablir la véritable sémantique de vos données, et cela représente énormément de travail.

En règle générale, lorsque nous commençons avec des clients, nous n’avons généralement même pas une ligne de documentation par champ, par table. Une fois notre travail terminé, nous disposons généralement d’une page de documentation par champ, par table, pour les champs réellement pertinents pour l’initiative Lokad, qui est l’optimization de la supply chain.

Néanmoins, 20 tables, 20 champs — nous parlons de 400 pages de documentation. Pas de documentation informatique : de la documentation supply chain, car nous devons expliquer la signification et les implications de chaque champ d’un point de vue supply chain. Donc oui, c’est beaucoup de travail.

Je pense que, encore une fois, sous le prétexte des mauvaises données, il s’avère très fréquemment que beaucoup de gens n’ont pas réalisé l’ampleur de l’effort nécessaire à cette qualification sémantique. De surcroît, nous avons des fournisseurs de logiciels incompétents qui utilisent cela pour rejeter la faute sur les données, une façon polie de dire au client : “C’est de votre faute.”

Conor Doherty : Eh bien, à ce sujet, en fait… vous ne saviez pas que j’allais faire cela, mais évidemment, votre nouveau livre est disponible, et pour me préparer à ceci, je suis en réalité retourné à votre ancien livre.

Et pour les OGs qui ont déjà lu les deux livres de Joannes, vous pouvez sortir votre exemplaire dès maintenant. Évidemment, le code dans les dernières centaines de pages de ce livre pourrait ne pas être aussi pertinent aujourd’hui, mais les premières… je dirai que les cent premières pages sont encore très, très pertinentes.

Et pour quiconque a son exemplaire sous la main : à la page 60, sur le thème de la sémantique — et encore, c’est juste pour démontrer que ce n’est pas de la philosophie abstraite — je vais donner un exemple très concret et poser une question très concrète, mais je vais simplement en lire un extrait parce que je le trouve très éclairant.

Donc ici, page 60 : lorsque nous parlons de quantité par jour relative à une date précise, la date à elle seule comporte son lot d’ambiguïtés. Il pourrait s’agir de la date à laquelle le client a passé une commande. Du moment où le client a confirmé une précommande. Du moment où le produit a été expédié au client. Du moment où la saisie de la commande est finalement arrivée dans l’ERP. Du moment où la saisie a été modifiée pour la dernière fois dans l’ERP. Du moment où le paiement du client a finalement été réceptionné. Vous l’avez évoqué, etc. Mais on pourrait aussi dire qu’il s’agit du moment où la garantie ou le délai de retour a expiré.

Maintenant, ce sont toutes des significations sémantiques concrètes pour une simple date.

Joannes Vermorel : Oui. Pour une simple date.

Conor Doherty : Exactement. Mais mon propos est le suivant : quel est le préjudice, par exemple, si je choisis l’une de ces interprétations ? Est-ce comme un arbre de décision où, soudainement, les décisions que je peux prendre divergent radicalement ? Est-ce là l’ampleur du dommage ? Expliquez pourquoi, afin qu’ils comprennent.

Joannes Vermorel : Oui. La difficulté avec la sémantique, c’est que lorsque vous vous trompez, la seule manière fiable de vous en rendre compte, c’est qu’à la fin du pipeline, vous générerez des décisions absurdes.

Jusqu’à ce que vous disposiez d’un pipeline complètement robotisé qui génère des décisions finales — allocation de ressources pour la supply chain : ce que vous achetez, ce que vous produisez, où vous stockez les choses, vos niveaux de prix pour chaque article que vous vendez — tant que vous n’avez pas un pipeline d’extraction de données entièrement autonome, une recette numérique qui génère ces décisions, il vous manque l’instrument essentiel pour évaluer et remettre en question votre sémantique.

Si, dans votre documentation, vous vous trompez — vous pensez que cette “order date” correspondait au moment où le paiement était validé ; en réalité, ce n’est pas le cas. C’est le moment où vous étiez prêt à expédier l’article au client — la documentation est erronée. Vous ne pourrez pas vous en apercevoir. Personne ne s’en apercevra.

Peut-être qu’en réalisant une analyse approfondie de ce champ après deux jours de travail, vous serez en mesure de le corriger. Mais il faut d’abord savoir qu’il y a eu une erreur. Nous parlons ici, même pour une petite initiative, de centaines de champs. Allez-vous organiser des ateliers s’étalant sur plusieurs jours pour chaque champ afin de vous assurer que votre sémantique est correcte ? Ce n’est pas raisonnable.

Ainsi, l’approche raisonnable est de faire de notre mieux, une estimation éclairée, puis de laisser la décision être générée à partir de cette interprétation. Eh bien, de temps en temps, des décisions seront totalement absurdes. Lorsque nous démarrons des initiatives, nous générons bon nombre de décisions carrément insensées.

Ensuite, nous examinons, et les gens disent : « Oh, ce nombre est absurde. » D’accord. Analysez rétroactivement ce qui nous a conduits à cette décision insensée, et en remontant la chaîne, nous procédons à une ingénierie inverse. Vous devez disposer de l’instrumentation nécessaire pour cela.

Vous finirez par dire : « Ah, cette date — oh, nous avons mal compris. » En fait, le délai applicable dans cette situation est complètement différent parce que nous avons mal interprété la date. D’accord, très bien. Re-générons la décision avec une interprétation corrigée pour cette date. Oh, cela paraît bien plus raisonnable maintenant. Bien. Suivant.

Fondamentalement, la seule manière d’évaluer si votre sémantique est correcte est finalement de la mettre à l’épreuve du monde réel : générer une décision, et laisser les praticiens dire, “Est-ce que cela a du sens ?” Sinon, vous devez revenir en arrière.

L’erreur que font de nombreux outils alternatifs, c’est que lorsque les données générées sont dénuées de sens, ils disent, “Oh, vous devez ajuster les paramètres.” Je dis : absolument pas. Vous ne devez ajuster les paramètres que si ceux-ci sont considérés comme la cause profonde du problème que vous observez. Sinon, ce n’est pas la solution.

Très, très fréquemment, le problème… Je ne saurais trop insister sur l’importance de la sémantique. C’est extrêmement délicat. La seule manière de procéder est d’examiner les décisions générées, ce qui pose encore plus de problèmes puisque de nombreux outils dans le domaine de la planification ne génèrent jamais de décisions finales, se privant ainsi — les éditeurs de logiciels qui font cela — de l’instrument permettant d’évaluer s’ils disposent de la bonne sémantique.

Conor Doherty: D’accord. Encore une fois, pour rebondir sur ce que vous venez de souligner : l’idée des données — nous utilisons les données pour prendre des décisions, que vous utilisiez ou non prévision probabiliste — c’est ce qu’une approche Lokad préconiserait. Mais fondamentalement, les données servent à faciliter au moins une étape : la prévision, puis la prise de décision.

Mais l’une des remarques les plus fréquentes des praticiens est : “Il y a beaucoup de bruit dans les données.” Dans le contexte de la prévision, des données bruitées représentent-elles un problème ?

Joannes Vermorel: Absolument pas. Si, par exemple, votre activité est erratique — vous avez des clients qui commandent parfois un, parfois 100 — c’est la réalité de votre entreprise.

De nombreuses méthodes supply chain, méthodes numériques, sont extrêmement défectueuses. Lorsqu’elles rencontrent quelque chose qui pourrait être qualifié d’outlier statistique, la recette numérique se comporte mal. Vous avez donc un outlier et la méthode déraille pour donner un non-sens complet.

Ensuite, les gens disent, “Oh, nous devons revenir en arrière et modifier cet historique, éliminer les outliers.” Ils disent, “Ces outliers sont mauvais, ce sont des symptômes de mauvais…” Ici, je ne suis absolument pas d’accord. Si vos clients ont réellement commandé 100 unités dans le passé, cela peut constituer un outlier, mais c’est la réalité. Cela s’est produit.

Évidemment, si vous avez un enregistrement dans votre système indiquant qu’un million d’unités a été commandé alors qu’aucune commande de ce type n’a jamais été créée, d’accord, ce sont de mauvaises données. Nous revenons aux données transactionnelles : les données transactionnelles sont précises.

Mais si vous avez une méthode numérique qui vous fournit des résultats aberrants parce qu’elle est confrontée à un outlier dans les données historiques, le problème ne vient pas des données. Le problème vient de la méthode numérique qui est tout simplement pourrie. Vous êtes face à une méthode défectueuse. Vous devriez abandonner cette méthode et opter pour quelque chose de numériquement plus fiable. C’est l’essence même du problème.

C’est typiquement une situation où les données sont parfaitement correctes, et où les fournisseurs qui proposent des méthodes hautement défectueuses parviennent en fait à convaincre leurs propres clients qu’ils doivent corriger manuellement leurs mauvaises données, alors qu’en réalité, les données sont absolument correctes et que le défaut réside dans la recette numérique elle-même.

Conor Doherty: Eh bien, c’est en fait une opportunité parfaite pour passer à autre chose… il y en avait quelques-unes… d’accord, deux m’ont été transmises en privé. Je vous prie de m’excuser, donnez-moi juste une seconde, que je m’organise et que je le formule sous forme de question.

Sur ce, un commentaire venant des praticiens : “Nous avons déjà construit un data lake et nous disposons évidemment de notre catalogue, pourtant nos utilisateurs, nos utilisateurs finaux, disent que les données sont incorrectes. À votre avis, le goulot d’étranglement vient-il de la technologie ou de la sémantique ? Et comment Joannes, ou comment Lokad, évite-t-il un réétiquetage sans fin ?”

Parce qu’encore une fois, vous avez beaucoup parlé de la sémantique et de son importance. Cela dépend de la manière dont vous construisez votre data lake. Votre data lake est-il une copie à l’identique de vos enregistrements dans le système de référence ? Aucun prétraitement, aucune amélioration, aucune jointure, aucun filtrage d’aucune sorte. C’est littéralement un à un. Il se peut qu’il y ait un léger délai parce que les données ne sont peut-être pas copiées en temps réel depuis l’ERP, mais en mettant de côté ce délai, c’est exactement une copie des données telles qu’elles existent.

Joannes Vermorel: Lorsque les gens s’en plaignent, nous revenons au second problème des data scientists : “Oh, les données ne sont pas nettes et rangées. Ce n’est pas comme les expériences sur Kaggle. Nous sommes confus.” Je dis : malheureusement, c’est le monde dans lequel vous vivez. Vous vivez dans un monde où l’information contenue dans vos systèmes d’entreprise est très complexe. Il n’y a pas d’échappatoire. Il n’y a pas d’alternative.

Vous pouvez donc vous en plaindre, mais c’est comme se plaindre de la gravité. C’est simplement un fait de l’univers. Vous devez l’accepter.

Très fréquemment, ce qui se produit n’est pas le scénario idéal que j’ai décrit pour le data lake, une réplique pure et simple des divers systèmes d’entreprise. Et vous pourriez vous demander : pourquoi avoir un data lake s’il ne s’agit que d’une copie ? La réponse courte est que vous ne voulez pas alourdir votre système ERP, votre système transactionnel. Ce dernier doit rester ultrarapide.

Si des personnes effectuent des requêtes en se disant, “Je veux toutes les commandes des cinq dernières années, déversez-moi tout cela,” cela ralentira le système. Cela signifie que quelqu’un qui tente d’effectuer une opération devra attendre plusieurs secondes car les ressources seront épuisées en raison de cette extraction massive de données. C’est pourquoi il est préférable de créer une réplique et de laisser ces requêtes massives s’exécuter sur la réplique, et non sur l’instance principale du système de référence.

Pour revenir au point initial : ce que j’observe dans de nombreux data lakes, c’est que l’équipe IT commet une erreur très grave. Elle retraitre les données originales. Elle souhaite les améliorer.

Où est le piège ? Le piège, c’est qu’ils ne génèrent pas les décisions. Ainsi, ils ne connaissent pas la sémantique. Par conséquent, le type de transformation qu’ils appliquent aux données est voué à être erroné, et, par conséquent, vous vous retrouvez avec des données qui ne sont pas ce que vous attendiez, pas ce dont vous avez besoin, et il n’existe aucune solution.

Aussi compétents et dévoués soient-ils, il leur manque l’instrument essentiel, qui est l’ingénierie inverse des décisions insensées. Par définition, ce n’est pas le rôle de l’IT de générer ces décisions d’entreprise. Par conséquent, l’IT ne peut s’occuper que de la plomberie : mettre en place les bases de données, s’assurer que les instances sont sécurisées, vérifier que les instances disposent de suffisamment de RAM, de bande passante disque, d’infrastructure—oui.

Mais si vous voulez de la sémantique, l’IT ne peut s’en charger. La sémantique est bien trop spécifique à chaque métier. On ne peut pas s’attendre à ce que l’IT soit à la fois spécialiste de la comptabilité, du marketing, de la supply chain, du juridique, etc. C’est pourquoi la sémantique ne peut être entre les mains que des praticiens. Par définition, cela submergerait l’IT si vous essayiez de lui faire porter ce fardeau.

Conor Doherty: Eh bien, encore une fois, j’ai reçu deux commentaires précédents, tant lors d’appels personnels qu’en réunions, et je choisis celui qui fera le meilleur suivi.

Je vais m’appuyer sur l’idée du conflit entre IT et les opérations. Littéralement, le commentaire était : “L’IT dit que nos données sont terribles, pourtant mes opérations, les praticiens qui les utilisent, disent qu’elles vont bien”, car comme vous l’avez souligné plus tôt, si vous prenez des décisions et que vous gagnez de l’argent, alors c’est bon pour l’entreprise.

La question est donc : comment vous, nous, évaluez-vous objectivement la qualité et choisissez-vous ce qui doit être corrigé maintenant, plus tard, ou simplement déployé tel quel ?

Joannes Vermorel: Le taux de retour sur les décisions générées. Si vous disposez de données supposément médiocres, mais que les décisions que vous générez s’avèrent correctes, sont-elles vraiment médiocres ? Peut-être pas. Peut-être sont-elles complètement insignifiantes. Nous nous en moquons complètement.

Si vous avez une donnée qui est fondamentalement sans conséquence, le fait qu’elle soit correcte ou non importe peu. Nous nous en fichons. C’est pourquoi, pour nous chez Lokad, nous évaluons la qualité des données en termes financiers : quel est le retour sur investissement d’améliorer—quoi que cela signifie, et cela varie selon les cas—cette donnée ?

Si l’amélioration de ces données se traduit par des millions de dollars par an grâce à de meilleures décisions, incroyable. Cela devrait être une priorité. Probablement devrions-nous investir. Si ces données pouvaient être encore pires sans que cela ne change rien, alors nous nous en fichons.

C’est pourquoi je dis : la seule façon d’évaluer la qualité des données… c’est également pour cela que l’IT ne peut pas réaliser cette évaluation, car elle repose sur les décisions que votre entreprise génère finalement. Est-ce médiocre ou pas ? Eh bien, cela dépend.

Par exemple, vous pouvez avoir un champ qui, dans l’aéronautique, — nous avons de nombreux champs — est incomplet pour 99 % des articles, et très souvent, on y trouve une note indiquant quelque chose comme, “Le numéro C se trouve à cet endroit sur le composant.” Est-ce de bonnes ou de mauvaises données ?

La réalité est que pour la quasi-totalité des pièces d’avion, localiser le numéro C est super évident. Vous n’avez pas besoin d’une note vous indiquant où se trouve le numéro C. Vous le repérez tout simplement, c’est évident, vous le lisez. Mais dans de rares cas, c’est délicat et il se trouve à un endroit difficile d’accès, souvent pour des raisons mécaniques. Dans ce cas, une petite note vous indique où chercher.

Du point de vue de l’IT, on pourrait dire, “Oh, vos saisies de données sont tellement incohérentes. Regardez ce champ : seulement environ 0,5 % des articles ont cet attribut défini.” Mais la réalité est : oui, mais ce sont les seuls articles pour lesquels cela compte réellement.

Ainsi, encore une fois, je dis : la seule façon d’évaluer si des données sont bonnes ou mauvaises est de les mettre à l’épreuve du processus de prise de décision.

Conor Doherty: Eh bien, cela peut en fait répondre au tout prochain commentaire. Encore une fois, c’est très, très spécifique, mais cela touche à un sujet qui, je pense, est l’éléphant dans la pièce : de nos jours, les gens veulent utiliser leurs données pour l’IA. Ils veulent des projets d’IA, etc.

Voici ce qu’un ami de la chaîne a dit : “Nous opérons dans plus de 40 pays. Nous utilisons plusieurs ERP et WMS pour gérer les stocks dans 40 pays. À quel moment nos données sont-elles suffisamment bonnes pour lancer l’IA, et que faites-vous réellement au cours des 90 premiers jours, disons essentiellement le premier trimestre ?”

Joannes Vermorel: Si vous avez un pays dans lequel vous savez ce que vous achetez, ce que vous produisez, ce que vous vendez, vous êtes prêt pour l’IA. C’est tout. Pour nous, cela a toujours été ainsi. Donc, les exigences ne sont pas élevées. Voilà ce qui est intéressant.

Les exigences pour robotiser le processus de prise de décision — avec quelque chose que vous appelez IA ou non, le terme que vous voulez lui attribuer — sont suffisantes. C’est ce que nous faisons. C’est pourquoi, très fréquemment, le maintien des paramètres qui régulent tous les subtils aspects du workflow pour que les gens effectuent le travail manuellement — ces éléments sont sans importance, car nous n’allons pas les utiliser.

Fondamentalement, l’IA remet complètement en cause la division du travail. L’ensemble du workflow, où l’on trouve des prévisionnistes suivis de planificateurs, suivis de responsables budgétaires, suivis de responsables des stocks, suivis de bla bla bla — vous voyez — dans un workflow, cela n’a plus de sens à l’ère de l’IA.

L’IA traitera simplement, en tant que monolithe, les données brutes issues du système de référence et produira directement les décisions, avec toute l’instrumentation pour les soutenir. Ce seront les moteurs économiques pour expliquer pourquoi cette décision a été prise. Parfait.

Votre système d’IA — ce que j’appelle les systèmes d’intelligence — est fondamentalement quelque chose comme un monolithe qui prend des enregistrements en entrée et génère des décisions en sortie avec une instrumentation de soutien, et c’est tout.

Quand les gens me disent, “Nous avons 40 ERP”, je répondrais : je ne pense pas que quelqu’un en ait 40. Cela serait… J’ai vu des entreprises… J’ai vu une entreprise qui avait 17 ERP dans le même pays. C’est le détenteur du record. Je ne nommerai pas cette entreprise. C’est une entreprise très, très grande. Même entreprise, même pays. Là, les choses étaient vraiment dingues.

En fin de compte : vous devrez fournir cet effort pour rétablir la sémantique ERP par ERP. Ça va être pénible. Évidemment.

Il demandait pour les 90 premiers jours. En général, il nous faut deux mois pour établir la sémantique. C’est ce que nous faisons pour un ensemble de systèmes d’entreprise qui opèrent, par exemple, dans un pays. Mais les véritables limites ne sont pas nécessairement le pays. Elles sont bien plus liées aux systèmes IT que nous devons inclure dans le périmètre : ERP, WMS, le e-commerce, etc.

Notre périmètre est largement défini par les limites des systèmes IT, très souvent précisément parce que l’effort consiste à établir la sémantique. Ensuite, une fois que nous avons défini la sémantique, le premier pipeline de données, nous commençons à itérer sur les décisions, et cela prend typiquement environ deux mois.

Donc : deux mois pour établir le pipeline de données, pour obtenir une première opinion éclairée sur la sémantique de chaque champ. Mais ensuite, il faut deux mois d’itérations supplémentaires pour éliminer toutes les incohérences, très souvent en identifiant la sémantique que vous aviez mal appréhendée lors de la première itération.

Donc, en 90… typiquement, ce ne sera pas 90 jours ; ce sera, disons, 120 jours. Vous pouvez obtenir, sans aucune incohérence, des décisions de niveau production. C’est une initiative typique de Lokad.

Mais l’essentiel est : vous devez être capable d’itérer très rapidement, typiquement plusieurs fois par jour, sur ces décisions incohérentes, car vous identifierez tant de problèmes liés à la sémantique des données.

Conor Doherty: Eh bien, encore une fois, et je ne le fais que parce que vous avez évoqué ce point : vous donnez l’exemple explicite de la manière dont nous pourrions procéder. Un point central est que ces éléments, ce que vous décrivez, l’implémentation, fonctionneraient en parallèle avec ce que nous appelons un dual run. Cela s’exécute en parallèle avec ce que vous faites actuellement, afin que vous puissiez constater par vous-même la différence.

Joannes Vermorel: Oui. C’est là qu’il est absolument crucial de disposer de quelque chose de complètement automatique. Pourquoi ? Parce que si votre processus parallèle, votre dual run, si le second nécessite beaucoup de main-d’œuvre, d’où provient cette main-d’œuvre ?

La société, disons qu’elle compte 15 planificateurs, et qu’ils sont tous occupés à 100 % du temps. S’ils n’étaient pas occupés à près de 100 %, la société n’en aurait que 12 ou 10. Par définition, les entreprises n’ont pas d’employés de réserve, sauf circonstances exceptionnelles. En règle générale, pour la plupart des postes, il n’y a pas d’employés inutilisés servant de secours pour tester le système supplémentaire.

Ces personnes consacrent déjà les huit heures de travail nécessaires pour accomplir leur tâche dans la journée. Elles peuvent peut-être dégager une demi-heure par jour pour jeter un rapide coup d’œil à un autre système, simplement pour identifier les cas atypiques, les mauvaises décisions, les décisions insensées, mais elles ne peuvent pas passer huit heures sur leur système, puis huit heures sur un autre système où elles doivent suivre le même flux de travail.

C’est pourquoi je dis qu’il est absolument crucial que ce nouveau système de prise de décision soit complètement autonome ; sinon, d’un point de vue opérationnel, vous ne pourrez pas le déployer. C’est quelque chose que Lokad a appris il y a une décennie.

Conor Doherty : Très bien. Encore une fois, j’ai épuisé la liste des commentaires qui ont été posés, ou on m’a explicitement demandé, “Veuillez poser votre question à l’antenne.”

Pour conclure sur une note constructive : nous avons couvert beaucoup de choses. Que voyez-vous pour la semaine prochaine — ou choisissez n’importe quel horizon, mais ne dites pas un an —, par exemple dans les 30 prochains jours, des changements faciles à mettre en œuvre que les gens peuvent effectivement réaliser, sinon pour améliorer la qualité, du moins pour améliorer la perception interne de la puissance de l’état actuel de leurs données ?

Joannes Vermorel : Je ne suis pas sûr qu’il y ait quelque chose à faire à court terme. Pour moi, il s’agit vraiment de prendre conscience de ce qu’il faut traiter comme une source d’information primaire réelle plutôt que comme un artefact numérique. Ce n’est pas la même chose.

Une fois que vous aurez effectué cette séparation et que vous examinerez froidement vos données réelles, basées sur des événements — les données qui représentent les véritables événements ayant une implication financière pour l’entreprise —, vous remarquerez très probablement que ces données sont excellentes. Oui, elles seront désordonnées, mais elles sont excellentes. Ce n’est donc pas le problème.

Tel serait mon message : des données de mauvaise qualité dans des entreprises digitalisées depuis une décennie ou plus ne sont jamais le problème. Lokad a réalisé plus d’une centaine d’implémentations au cours de la dernière décennie et demie.

Parfois, nous rencontrions des problèmes avec des systèmes trop lents pour extraire les données. Cela posait parfois problème. D’ailleurs, c’est pourquoi vous souhaitez ajouter un data lake, car parfois nous exécutions, par exemple, “SELECT * FROM table X”, et le système déclenchait une exception de dépassement de mémoire lorsqu’on procédait ainsi.

Donc, d’accord, nous avions des problèmes où parfois l’extraction des données était extrêmement compliquée, car le système s’effondrait lorsque nous tentions de récupérer les données. C’est une préoccupation réelle. J’espère vraiment que vous n’êtes pas dans une telle situation, mais cela pourrait arriver. C’est la raison pour laquelle vous voulez disposer d’un data lake.

Mais en dehors de ces problèmes très techniques liés à une infrastructure ancienne, nous n’avons jamais eu de mauvaises données au sens strict. Ce que nous avions en abondance, c’était des données extrêmement opaques et obscures, mais fondamentalement, c’était quelque chose à résoudre du côté de Lokad.

Donc oui, c’était un gros problème pour nous, mais fondamentalement, ce n’était pas un problème du client. Le client utilisait simplement son système comme il se doit. Le résultat fut le suivant : pour quelqu’un qui souhaite mettre en place un système de prise de décision automatisé par-dessus cela, c’est un défi. Mais encore une fois, le défi réside dans l’interprétation correcte des données, et non dans le fait de blâmer le client pour avoir collecté ces données en premier lieu.

Conor Doherty : Encore une fois, cela fait une heure que nous parlons, donc je pense être justifié pour faire un léger commentaire en termes de marketing, mais c’est un point essentiel à faire passer.

L’une des choses que j’ai personnellement apprises de nombreuses conversations récentes, c’est qu’il n’est pas toujours évident pour les gens de comprendre que lorsque nous disons, “Hé, regardez, vos données sont suffisamment bonnes telles qu’elles sont”, ils ne se rendent pas compte que si vous travailliez avec Lokad, ou un autre fournisseur compétent, ce fardeau serait pris en charge.

Donc : vous leur donnez les données, vous nous donnez les données. Ce n’est pas à vous de les traiter. Et ils devraient… encore une fois, si le fournisseur…

Joannes Vermorel : Si le fournisseur ne prend pas ce fardeau sur ses propres épaules, c’est une recette pour la recherche de boucs émissaires.

Conor Doherty : Exactement.

Joannes Vermorel : Le fournisseur vous reprochera tout, et vous vous retrouverez dans une situation où l’entreprise gaspille un demi-milliard sur sept ans. En fin de compte, le rapport conclut que c’est entièrement la faute de… et le fournisseur se contente de dire : “Non, il n’y a rien à voir ici. Ce n’est pas de ma faute. Allez.”

D’ailleurs, dans le cas de Lidl, c’est très intéressant, car ils ont reproché que les données étaient mauvaises sur un point précis. SAP a déclaré, “Oh, Lidl, ils mènent leur analyse sur le prix d’achat, et nous menons toute notre analyse sur le prix de vente, et c’était la cause.”

Pour moi, je dis : les gars, c’est du niveau 101 en sémantique. D’abord, c’est un problème trivial : s’agit-il du prix de vente ou du prix d’achat ? Oui, il y a un défi sémantique ici : de quel prix parle-t-on ? Mais soyons clairs : il ne s’agit pas d’une distinction nuancée très subtile. En ce qui concerne la distinction sémantique, c’est une distinction très, très facile à aborder.

Ensuite, ce qui est encore plus déconcertant, c’est qu’évidemment, pour moi, il vous faut les deux. Vous avez besoin à la fois du prix d’achat et du prix de vente pour pouvoir connaître la marge.

Donc l’idée que le fournisseur parviendrait, après sept ans, à rejeter la faute sur le client en disant, “Oh, vous savez quoi, ils organisent toute leur supply chain autour du prix d’achat, c’est une telle complication pour nous parce que nous attendons le prix de vente”, c’est exactement le genre de magouilles que l’on observe si le fournisseur n’est pas engagé à fournir des décisions économiquement performantes.

Cela devrait être le point de départ ; sinon, dans le domaine de la supply chain, vous allez vous retrouver avec beaucoup d’inepties. Au final, après avoir dépensé beaucoup d’argent, le fournisseur parviendra à rejeter la faute sur vous en trouvant de mauvaises données.

Encore une fois : si nous n’acceptons pas que seules les décisions comptent, il y a tant de données qui sont complètement insignifiantes. Évidemment, ces données insignifiantes vont être de très basse qualité, et cela est tout à fait acceptable.

Un ERP compte 10 000 tables. Chaque table comporte des dizaines de champs. Toutes ces données doivent-elles être impeccables ? C’est insensé. Pourquoi voudriez-vous cela ? C’est bien trop coûteux.

Donc, si vous jouez à ce jeu des mauvaises données avec le fournisseur, c’est lui qui en sortira gagnant, car il y aura toujours de nombreuses tables et de nombreux champs où, objectivement, elles sont médiocres et insignifiantes. C’est la clé : insignifiantes.

Conor Doherty : D’accord. En conclusion : choisissez votre fournisseur avec soin, si vous devez tout condenser.

Joannes Vermorel : Ouais. Et comprenez bien : quand vous parlez de la qualité de l’ERP, quel est le véritable objectif ? Quel est l’objectif ? Il n’existe pas de pureté de l’ERP dans un sens moral pour une entreprise. Il a une utilité.

La qualité, c’est l’adéquation à l’usage, et c’est tout.

Conor Doherty : C’est tout. Merci beaucoup. Je n’ai plus de questions. Cela fait une heure que nous parlons, donc je pense que nous sommes à court de temps.

Comme toujours, merci pour vos éclairages, et merci à tous pour votre participation et pour vos messages privés. Comme je l’ai dit dès le début, et d’où est venu ce sujet, si vous souhaitez poursuivre la conversation, contactez Joannes et moi en privé. Nous sommes toujours heureux de discuter.

Comme je l’ai dit la semaine dernière, et je le dirai chaque semaine, nous sommes des personnes adorables. Regardez-nous. Sur ce, rendez-vous la semaine prochaine. J’ai un sujet spécial pour la semaine prochaine, nous l’annoncerons donc lundi. Mais sur ce, retournez au travail.