Préparation des données en Supply Chain

00:00:03 Aperçu de la préparation des données en science des données.
00:00:46 Sous-estimation des complexités de la préparation des données.
00:02:01 Durée typique d’un projet de préparation des données.
00:03:19 Défis liés à la vitesse et à l’exactitude de la préparation des données.
00:06:07 Importance de la documentation de la préparation des données.
00:08:00 Interprétation de la “date de commande” dans les supply chains.
00:09:02 Complications dans l’interprétation des données suite à des mises à jour du système.
00:10:07 Comprendre la sémantique des données pour éviter les erreurs.
00:10:15 Étude de cas : particularités du système de supply chain.
00:14:53 Besoin de documentation des données dans les opérations commerciales.
00:16:01 Importance du suivi des données dans les supply chains.
00:17:24 Élargir la portée des données dans la prise de décision automatisée.
00:18:42 Risques liés à la dépendance vis-à-vis des individus pour la récupération des données.
00:19:02 Défis et attentes dans la préparation des données.
00:20:13 La préparation des données en tant qu’effort de l’ensemble de l’entreprise.
00:21:56 Juger de la justesse de l’interprétation des données via l’efficacité réelle.
00:23:02 Conséquences d’une interprétation incorrecte des données et importance de la traçabilité.
00:24:37 Difficultés et résultats d’une mauvaise préparation des données.
00:24:49 Le concept de “bonne” préparation des données.

Résumé

Dans cet épisode de Lokad TV, l’animateur Kieran Chandler et le fondateur de Lokad, Joannes Vermorel, discutent des subtilités de la préparation des données en science des données, un processus souvent sous-estimé mais actuellement priorisé en raison de la conformité au RGPD. Vermorel souligne que la préparation des données, qui consomme fréquemment plusieurs mois et des ressources considérables, est essentielle pour contourner le problème du “garbage in, garbage out”. Cela nécessite de transformer des données incohérentes ou incomplètes en un format compréhensible, ce qui nécessite une documentation approfondie. Le processus est complexe, façonné par la nature multifacette des problèmes commerciaux et le contexte historique des données. Vermorel préconise une approche distribuée, impliquant diverses équipes organisationnelles, et soutient que la préparation efficace des données doit être accessible et faciliter une prise de décision claire.

Résumé étendu

Dans cet épisode de Lokad TV animé par Kieran Chandler, lui et Joannes Vermorel, le fondateur de Lokad, discutent du rôle complexe mais essentiel de la préparation des données dans le domaine de la science des données. Avec la montée en puissance des lois sur la conformité au RGPD, les données deviennent un point central pour de nombreux dirigeants, avec une estimation selon laquelle les entreprises dépensent actuellement plus de 450 milliards de dollars rien que pour la préparation des données. L’objectif de la préparation des données est de convertir des données brutes, souvent incohérentes ou incomplètes, en un format facile à interpréter et à appliquer.

Vermorel aborde la sous-estimation fréquente de la complexité de la préparation des données. Malgré les ressources importantes investies par les entreprises, de nombreux projets accusent du retard ou dépassent leur budget. Selon Vermorel, la plupart des bugs des systèmes informatiques peuvent être liés à des problèmes lors de l’étape de préparation des données. Il explique que la nature multifacette des problèmes commerciaux se manifeste sous la forme d’étapes de préparation des données, ce qui ajoute à la complexité de la tâche.

En ce qui concerne les délais, Vermorel suggère que les projets de préparation de données à grande échelle peuvent prendre au moins quelques mois, s’étendant souvent jusqu’à six mois. Bien que l’on puisse supposer que des outils améliorés ou des logiciels plus évolutifs devraient accélérer le processus, il suggère que le niveau de maturité global de l’écosystème ralentit les progrès. Pour éviter véritablement le problème du “garbage in, garbage out”, les données doivent d’abord être documentées et clarifiées. Ce processus, selon lui, contribue à allonger le délai.

Lorsqu’on lui demande la faisabilité d’accélérer ce processus, Vermorel explique que ce n’est pas aussi simple que d’ajouter simplement plus de ressources. Les données traitées n’ont pas été initialement produites à des fins de préparation des données, mais sont plutôt un sous-produit des systèmes d’entreprise. Par exemple, il décrit comment la fonction principale d’un système de point de vente est de traiter les paiements des clients, et non de collecter des données. Cependant, même ces systèmes produisent des données qui peuvent être incohérentes ou erronées en raison de raisons opérationnelles pratiques, telles que des erreurs de code-barres. Ces incohérences nécessitent un travail préparatoire approfondi pour une utilisation efficace dans l’optimisation de la supply chain.

Vermorel parle également de l’importance de la documentation dans la préparation des données. Chez Lokad, un projet de préparation des données commence généralement avec moins d’une ligne de documentation par champ par table et se termine avec une page de documentation par champ par table. Cette documentation complète est essentielle pour éviter que des données d’entrée de mauvaise qualité ne conduisent à une sortie de mauvaise qualité, ou “garbage in, garbage out”. Le délai de six mois pour la préparation des données inclut donc le processus de création de cette documentation détaillée.

Vermorel commence par aborder les complexités et les interprétations potentielles qui peuvent découler d’une simple donnée : la date d’une commande historique. Il explique que la “date” n’est pas aussi simple qu’elle n’y paraît, car il existe plusieurs interprétations possibles, comme lorsque le client a cliqué sur un produit, quand il a validé son panier, quand le paiement a été traité ou quand les marchandises ont été mises à disposition dans l’entrepôt.

Il souligne que l’interprétation de telles données peut changer au fil du temps en raison de mises à niveau du système ou de changements dans les pratiques commerciales. Il est donc crucial de comprendre non seulement les données elles-mêmes, mais aussi le contexte historique dans lequel elles ont été produites. Si ces complexités ne sont pas prises en compte, les entreprises peuvent être confrontées à un problème de “garbage in, garbage out” où des interprétations incorrectes conduisent à de mauvaises prises de décision.

Vermorel met en évidence une étude de cas avec l’un des clients de Lokad pour illustrer son propos. Ce client exploite une installation industrielle exigeante avec de courts délais d’approvisionnement, où recevoir la quantité précise de marchandises commandées est essentiel. Le système du client dispose d’une fonctionnalité où si la quantité livrée ne correspond pas exactement à la commande, la commande entière est rejetée et renvoyée. Cela conduit à une situation où s’ils reçoivent légèrement plus que ce qui a été commandé, ils doivent modifier la commande d’achat initiale dans le système pour correspondre à la quantité livrée. Cette solution de contournement leur permet d’accepter la livraison et

d’éviter des perturbations dans leurs opérations industrielles.

Cependant, ce processus est exploité par des fournisseurs astucieux qui livrent maintenant légèrement plus que ce qui a été commandé, sachant que cela sera accepté. Cela se traduit par des commandes d’achat qui semblent gonflées par rapport aux besoins réels, créant des artefacts de données qui faussent les performances de l’équipe d’achat. Vermorel souligne que cette complexité doit être documentée pour éviter des interprétations incorrectes. Il insiste sur le fait que les problèmes ne sont pas dus à une mauvaise performance de l’équipe d’achat, mais aux limitations du système et à la manière dont les utilisateurs ont fait face à ces limitations.

Changeant de sujet, Vermorel parle de ceux qui se soucient des données historiques, en dehors de Lokad, une entreprise qui les utilise pour des prévisions probabilistes. Il souligne que les entreprises surveillent de près l’argent qu’elles s’attendent à recevoir ou à payer, et que celles qui ne le font pas disparaissent avec le temps. C’est, selon lui, une forme de “darwinisme” des affaires. Il suggère que les entreprises qui prêtent attention à leurs transactions financières au fil du temps se soucient naturellement de leurs données historiques.

La conversation se tourne vers la préparation des données. Vermorel souligne que les données ne sont pas intrinsèquement “propres” ou entièrement comprises. Il propose que la préparation des données ne soit pas seulement un problème informatique ; il s’agit de comprendre tous les aspects des données commerciales pour aborder tous les angles commerciaux. Le service informatique, note-t-il, ne peut pas être censé maîtriser tous les aspects commerciaux et ne doit pas être le seul responsable de la préparation des données.

Vermorel suggère une approche distribuée, impliquant différentes équipes avec des expertises distinctes au sein de l’organisation. Les données pertinentes pour les achats, par exemple, devraient impliquer les équipes d’achat. De même, les données requises pour une fiche de score fournisseur devraient impliquer les équipes d’approvisionnement. Cette approche peut exploiter les connaissances nécessaires pour une préparation efficace des données.

Pour ce qui est de savoir comment être sûr de l’interprétation des données, surtout lorsque l’information est incomplète, Vermorel le compare aux théories scientifiques ; il n’est pas possible de savoir si une théorie est correcte, mais elle peut être validée lorsqu’elle résiste à l’examen. La justesse de la préparation des données est établie lorsque les décisions découlant de l’interprétation sont correctes. Si une préparation incorrecte des données conduit à des décisions absurdes, la cause peut être identifiée, corrigée et réévaluée.

Vermorel décrit ensuite à quoi devrait ressembler une bonne préparation des données, notamment dans des scénarios complexes de supply chain. Il la compare à un livre bien écrit, fournissant des informations et des perspectives commerciales pertinentes, et pas seulement des détails techniques. Elle devrait être accessible et distribuée dans toute l’organisation, favorisant une compréhension partagée. Elle nécessite un effort continu pour documenter, maintenir et comprendre les données.

Enfin, Vermorel insiste sur le fait que la préparation des données devrait être une interprétation d’une compréhension valide des données elles-mêmes. Une fois cette compréhension établie et maintenue, les opérations logiques sur les données sont assez simples. Une bonne préparation des données est donc à la fois un guide bien écrit et une compréhension partagée qui permet des décisions claires et efficaces dans la supply chain.

Transcription complète

Kieran Chandler : Dans l’épisode d’aujourd’hui, nous allons parler de la préparation des données, l’un des fondements de la science des données. Étant donné les récentes lois de conformité au RGPD, les données sont très présentes dans l’esprit de nombreux dirigeants. C’est aussi un gros enjeu, avec une récente enquête estimant que les entreprises dépensent plus de 450 milliards de dollars rien que pour la préparation des données. La préparation des données consiste à prendre des données brutes et à les transformer en un format facile à comprendre afin de pouvoir les utiliser de manière utile. Cela n’est pas une mince affaire lorsque l’on considère que les données proviennent de nombreuses sources différentes et peuvent souvent être incohérentes, incomplètes et contenir des erreurs. Alors Joannes, pourquoi parlons-nous de la préparation des données aujourd’hui ? Je veux dire, si ces entreprises investissent plus de 450 milliards de dollars, cela devrait être quelque chose que nous comprenons maintenant.

Joannes Vermorel : Oui, absolument. La préparation des données est un domaine assez bien connu, mais systématiquement sous-estimé en termes de changements. C’est intéressant car la plupart des projets de préparation des données finissent par ne pas respecter leurs délais et entraînent des dépassements de budget. Le problème principal est que de nombreux bugs réels que l’on voit dans les systèmes informatiques, les logiciels d’entreprise en général, sont liés à des problèmes au niveau de la préparation des données. C’est extrêmement complexe. Bien que ce soit un problème bien connu, le problème principal est que les complexités commerciales réapparaissent sous forme d’étapes de préparation des données, ce qui en fait un domaine illimité. Il n’y a pas de recette finale pour la préparation des données.

Kieran Chandler : Combien de temps faut-il donc pour préparer une quantité importante de données ?

Joannes Vermorel : Je n’ai jamais vu de projet de préparation de données à grande échelle qui prenne moins de quelques mois. En général, c’est plutôt six mois. Certaines personnes pourraient argumenter que avec de meilleurs outils et des logiciels plus évolutifs, cela devrait être plus rapide. Cependant, la réalité est que l’écosystème manque tellement de maturité que, pour pratiquement toutes les entreprises, sauf quelques champions des données comme Google, les données doivent d’abord être documentées et clarifiées. Il y a tellement de choses à faire avec ces données pour éviter le problème de “garbage in, garbage out”. Donc cela prend quelques mois, et six mois est un objectif raisonnable si vous avez une chaîne d’approvisionnement complexe impliquée.

Kieran Chandler : Six mois semble être une période assez longue. Y a-t-il un moyen d’accélérer ce processus ? Si je suis une grande organisation, ne puis-je pas simplement ajouter plus de personnes au problème ?

Joannes Vermorel : Vous vous retrouvez avec un problème spécifique ici : pouvez-vous avoir neuf femmes pour faire un bébé en un mois ? La question est de comprendre le type de problèmes auxquels nous sommes confrontés. Tout d’abord, les données que vous avez n’ont pas été produites pour être des données en premier lieu. Elles sont un sous-produit de votre système d’entreprise qui se contente de faire fonctionner votre entreprise. Prenons un exemple d’un logiciel de point de vente, quelque chose où vous pouvez payer dans un supermarché. Sa fonction principale est de traiter les clients qui veulent sortir du magasin tout en payant ce qu’ils doivent payer. Donc, si un code-barres ne scanne pas pour une raison quelconque, le caissier va probablement scanner deux fois un produit de prix similaire. Au final, vous allez payer le bon prix, mais en termes de données, vous allez avoir un produit compté deux fois.

Kieran Chandler : Un produit compté zéro fois peut créer des problèmes en termes de gestion des stocks car vos enregistrements électroniques deviennent incorrects. Ce n’est pas une bonne solution et il est conseillé de l’éviter. Mais la réalité est que si vous avez le choix entre résoudre un problème de données et permettre à votre entreprise de fonctionner plus facilement, ceux sur le terrain, les personnes qui ont besoin de gérer physiquement les chaînes d’approvisionnement, favoriseront toujours une solution qui ne perturbe pas le flux de marchandises, de clients, de services et tout le reste. Le fonctionnement de l’entreprise est primordial et les données ne sont qu’un sous-produit de second ordre. Elles ne sont jamais traitées comme un citoyen de première classe. C’est pourquoi il y a toujours tout ce travail à faire car les données n’ont pas été collectées uniquement dans le but de vous permettre d’optimiser la chaîne d’approvisionnement. Est-ce là que viennent tous ces défis ?

Joannes Vermorel : En effet, c’est pourquoi tous ces changements viennent de là.

Kieran Chandler : Parlons de cette documentation dont vous avez parlé plus tôt. Qu’attendez-vous de voir dans cette documentation et en quoi cela aide-t-il ? Juste pour comprendre, si nous revenons à la période de six mois, quel volume de documentation attendons-nous ?

Joannes Vermorel : Une règle empirique serait, en général, lorsque nous commençons un projet chez Lokad, nous avons moins d’une ligne de documentation par table par champ. Habituellement, nous n’en avons même pas. Nous commençons de nombreux projets où nous n’avons même pas une ligne de documentation par table dans le ERP, MRP, WMS, ou tout autre système utilisé pour gérer votre supply chain. Lorsque nous avons terminé, nous nous retrouvons avec une page de documentation par champ par table. Donc, si vous avez 20 tables avec 20 champs, nous parlons de 400 pages de documentation. Oui, cela prend six mois pour produire ces 400 pages de documentation.

Kieran Chandler : Cela semble être une énorme quantité de documentation. Est-ce vraiment nécessaire ?

Joannes Vermorel : C’est tout nécessaire si vous voulez éviter les données erronées.

Kieran Chandler : Pourquoi cela ?

Joannes Vermorel : Prenons un cas pratique : disons que j’ai une table nommée ‘orders’. Elle contient mes commandes historiques et a une date. Mais est-ce simple ? Parlons-nous vraiment du type de date dont il s’agit ? Est-ce la date à laquelle le client a cliqué sur un produit pour le mettre dans le panier sur le site de commerce électronique ? Ou quand le client a validé le panier et effectué le paiement ? Ou quand le paiement a été validé par le processeur de carte de crédit ? Ou quand l’entrée a été enregistrée dans le système ? Ou quand le bon de commande a été modifié pour la dernière fois dans le système ? Il y a environ 20 interprétations différentes pour ce seul champ ‘date’.

De plus, si votre entreprise a plus d’une décennie d’histoire, il est probable que la fine ligne de l’interprétation de la ‘date de commande’ ait changé au fil des ans. Vous pourriez vous retrouver dans une situation où vous avez effectué une mise à niveau d’un système et la sémantique de cette colonne a changé.

Ce n’est pas non plus quelque chose qui est naturellement complètement homogène pour toute votre histoire. Ensuite, vous pouvez avoir d’autres complications, telles que des cas particuliers. Par exemple, cette date est censée être la date à laquelle le client a validé le panier, sauf si le paiement a finalement été rejeté en tant que fraude. Dans ce cas, c’est la date et l’heure à laquelle la commande a été rejetée en tant que fraude.

Encore une fois, ce n’est pas vraiment une très bonne conception, mais les entreprises qui gèrent des chaînes d’approvisionnement complexes ont des systèmes complexes et beaucoup d’histoire. Donc, l’informatique n’a pas nécessairement été parfaitement réalisée dès le premier jour, et vous devez faire face à toutes ces complications historiques. Elles se retrouvent dans cette documentation. Si vous ne tenez pas compte de toutes ces complications, vous rencontrerez des problèmes chaque fois que vous voudrez analyser ces données.

Kieran Chandler : Pour générer une décision optimisée pour votre supply chain, vous pouvez vous retrouver avec un problème de ‘garbage in, garbage out’ si vous interprétez incorrectement les données. Donc, ce que vous dites, c’est qu’il s’agit de clarifier la sémantique des données, n’est-ce pas ?

Joannes Vermorel : Exactement. Vous devez comprendre que les données sont plus que de simples chiffres. Elles représentent divers facteurs qui peuvent être combinés dans une seule cellule. Il ne s’agit pas seulement de comprendre le logiciel qui produit les données, mais aussi de comprendre comment les personnes interagissent avec le logiciel. Votre documentation doit prendre en compte l’aspect humain de ce que les gens font.

Kieran Chandler : Avez-vous un bon exemple de la façon dont l’un de vos clients a rencontré ce problème dans le passé et de la façon dont cela a affecté leur entreprise ?

Joannes Vermorel : Oui, je peux donner un exemple. Nous avions un client qui exploitait une opération très exigeante nécessitant un niveau élevé de disponibilité. Ils passaient des commandes d’achat avec des délais très courts à leurs fournisseurs. Leur système avait une fonctionnalité de conception intéressante. Si la quantité de marchandises livrées ne correspondait pas aux quantités initialement demandées, alors toute la commande d’achat devait être rejetée et renvoyée au fournisseur.

Disons, par exemple, que vous commandez 1 000 unités, mais que le fournisseur en livre 1 050, alors vous devriez le rejeter. Le problème avec cela est que si vous le rejetez, cela pourrait entraîner de graves problèmes opérationnels. Le système ne leur permettait pas de modifier la quantité, donc ce qui se passait, c’est que lorsque les quantités livrées ne correspondaient pas aux quantités commandées, ils modifiaient la commande d’achat initiale pour refléter la quantité livrée.

Kieran Chandler : Donc, ce que vous dites, c’est qu’ils modifiaient la commande d’achat initiale pour correspondre à ce qui était livré ?

Joannes Vermorel : Exactement. Cependant, cela a ouvert un autre problème. Les fournisseurs ont découvert cette pratique. Ils ont réalisé qu’ils pouvaient livrer plus que ce qui était commandé, sachant que l’entreprise avait besoin de ces fournitures. Ils ne livraient pas une quantité extravagante, mais quelque chose que l’entreprise considérerait acceptable.

Dans les données, il semblait que la commande initiale était pour une plus grande quantité. Cela a entraîné des données étranges où les commandes d’achat semblaient trop importantes par rapport à ce qui était nécessaire, ce qui donnait l’impression que l’équipe d’achat était mauvaise dans le choix des bonnes quantités. Cependant, le problème ne résidait pas dans l’équipe d’achat, mais dans les limitations du système et dans la manière dont les personnes faisaient face à ces limitations.

Tous ces détails devaient être documentés pour éviter d’arriver à une conclusion erronée. L’équipe d’achat n’était pas mauvaise dans son travail. Le problème était qu’ils avaient un système avec des limitations qu’ils essayaient simplement de contourner.

Kieran Chandler : Le système génère tous ces effets secondaires bizarres. Il a besoin d’une page d’explication si vous voulez lui donner un sens, mais il n’y a pas d’échappatoire. C’est simplement la complexité de l’entreprise elle-même qui se reflète dans ces données. Éloignons-nous de ces fournisseurs sournois. C’est certainement un exemple divertissant. Donc, vous avez mentionné le genre de personne concernée. Évidemment, chez Lokad, nous utilisons des données historiques pour faire des prévisions probabilistes pour l’avenir. Qui d’autre se soucie réellement des données historiques, à part nous ?

Joannes Vermorel : En général, tout ce qui touchait vraiment au montant d’argent que vous deviez vous attendre à recevoir ou à payer suscitait beaucoup d’attention. Ce n’est pas que les gens ne faisaient pas attention, mais les entreprises qui ne surveillaient pas de près l’argent qu’elles devaient recevoir avaient tendance à disparaître avec le temps. C’est comme le darwinisme en action. Si vous ne faites même pas attention à cela, vous disparaissez simplement. C’est pourquoi, il y a environ cinq siècles, la comptabilité en partie double a été inventée par des moines italiens. Si vous ne faites pas attention, votre monastère s’effondre simplement en raison de mauvaises pratiques comptables. Ce n’est pas exactement un problème nouveau, mais il y a beaucoup de données que nous ne considérions pas comme critiques dans le passé et qui deviennent maintenant critiques.

Pour vous donner un exemple, pour prendre en compte correctement les ruptures de stock dans le passé, vous preniez en compte ce que vous achetiez, afin de savoir ce que vous deviez payer à vos fournisseurs, et ce que vous vendiez, afin de savoir ce que vos clients devaient vous payer. Mais qu’en est-il du suivi des ruptures de stock historiques ? Tant que vous avez un praticien de la chaîne d’approvisionnement qui décide des quantités à acheter à la main et se souvient qu’il y a eu des périodes bizarres avec des ruptures de stock, alors vous n’avez pas besoin d’avoir ces enregistrements historiques. Ils font partie de votre système.

Le problème est que dès que vous voulez passer à quelque chose de plus quantitatif, comme ce que nous faisons chez Lokad avec des décisions automatisées pour toutes ces tâches banales telles que décider combien commander, avoir des enregistrements précis sur les niveaux de stock historiques devient beaucoup plus important. Sinon, votre automatisation interprète mal ce qui est la vente et ce qui était le manque de demande.

Si vous voulez automatiser davantage votre entreprise, alors vous devez prêter attention à un spectre plus large de données, pas seulement à la comptabilité brute. Votre comptable ne se soucie pas de vos jours de rupture de stock, mais votre logiciel d’optimisation de la chaîne d’approvisionnement le fera. Vous devez élargir les cercles de données qui font vraiment partie de votre champ d’application, qui sont documentés et où vous avez besoin d’un contrôle et d’une assurance qualité.

Kieran Chandler : Donc, nous dépendons beaucoup de cette personne qui se souvient de ce qui s’est passé dans le passé. Ne devrions-nous pas être mieux préparés pour les données au fur et à mesure de leur arrivée ? Ne devrait-ce pas être le service informatique ou quelqu’un d’autre qui prépare ces données et s’assure qu’elles sont propres dès le départ ? Cela semble plus facile à faire.

Joannes Vermorel : Oui, mais le problème ne réside pas dans les compétences informatiques. Il n’y a pas de données propres. Le point, c’est que les données ne sont pas naturellement comprises avec suffisamment de profondeur et que tous les angles commerciaux ne sont pas correctement couverts.

Kieran Chandler : On dit souvent que les entreprises investissent des milliards dans l’IA, mais la réalité est que c’est la complexité de l’entreprise elle-même qui émerge dans cette tâche, ce défi de préparer les données. Et dire “oh, le service informatique devrait s’en occuper”, revient à s’attendre à ce que le service informatique dirige l’entreprise et soit compétent dans chaque angle commercial.

Joannes Vermorel : Absolument, cela crée soudainement un problème organisationnel car on s’attend à ce que le service informatique soit autant un expert en ressources humaines, en marketing, en achats, etc. Je veux dire, on s’attend à une maîtrise complète de tous les angles commerciaux de la part du service informatique. Mais c’est demander trop. Le service informatique doit déjà gérer tous les changements informatiques, il ne devrait donc pas être tenu de résoudre tous les problèmes commerciaux de l’entreprise. Sinon, vous pourriez redéfinir le service informatique comme étant votre entreprise entière, mais cela va à l’encontre de l’objectif.

Revenons au cas qui nous intéresse, la préparation des données doit être un effort assez réparti au sein de l’entreprise car, en fin de compte, les seules personnes capables de fournir le niveau de compréhension nécessaire pour préparer les données pertinentes pour, disons, les achats, sont les équipes d’achat. De même, si vous souhaitez établir un tableau de bord des fournisseurs et préparer les données avec suffisamment de précision pour que cela ait vraiment du sens, vous devrez parler à vos équipes responsables des approvisionnements.

Chaque fois que vous abordez un problème, vous devez impliquer les personnes spécialisées dans ce problème au sein de votre entreprise, car ce sont elles qui vous donneront les informations nécessaires pour que la préparation des données ait du sens. Ce n’est pas strictement un problème informatique. Il s’agit de recueillir toutes les connaissances requises afin que, lorsque vous traitez les données, vous n’obteniez pas des données qui n’ont aucun sens par rapport au problème commercial à résoudre.

Kieran Chandler : Donc, nous n’en sommes pas encore là d’après ce que j’entends. Certaines entreprises y sont parvenues, mais ce sont des exceptions, pas la règle. Comment pouvez-vous être sûr, si vous n’avez pas toutes les informations et qu’il y a des lacunes que vous interprétez, que votre interprétation est la bonne ? Il pourrait y avoir de nombreuses possibilités.

Joannes Vermorel : Absolument, et c’est un point intéressant car c’est similaire aux théories scientifiques. Vous ne savez jamais si votre théorie est correcte, vous savez simplement qu’elle est suffisamment bonne et que lorsqu’elle est mise à l’épreuve dans la réalité, elle fonctionne. Vous n’avez rien de mieux pour la faire fonctionner encore mieux.

Alors, qu’est-ce que cela signifie pour la préparation des données ? Cela signifie que vous savez que votre préparation des données est correcte lorsque, à la fin du pipeline de données, les décisions que vous générez automatiquement en fonction de cette interprétation sont correctes. Si vous avez des décisions correctes, cela signifie que votre logique d’optimisation est efficace, vos couches d’apprentissage automatique sont précises, et bien d’autres choses encore. Fondamentalement, il est tout simplement impossible d’obtenir des décisions correctes générées par une interprétation incorrecte. Habituellement, lorsque vous n’interprétez pas correctement et ne préparez pas vos données correctement, cela fausse tellement vos résultats qu’il n’y a aucune chance que cela fonctionne.

En fin de compte, il n’y a pas d’autre solution que de faire la préparation, d’avoir confiance en celle-ci, puis de générer les décisions. Si les décisions n’ont aucun sens, vous revenez en arrière, vous remontez le problème à sa cause première - souvent la préparation des données - et vous le corrigez. Si, à la fin de la journée, les décisions qui sortent de votre système ont du sens pour un praticien qui utilise son propre esprit humain pour les évaluer, alors vous savez que vous avez raison.

Kieran Chandler : On pourrait dire que je crois qu’elles sont correctement préparées, mais généralement, tout est une question de nuances. Le praticien de la supply chain pourrait dire : “C’est une bonne décision, mais elle pourrait être encore améliorée. Par exemple, si nous prenions en compte le prix de nos concurrents car cela explique les pics ou les baisses inhabituels de la demande, et nous n’avons pas encore ces données.” Donc, ce n’est pas une situation en noir et blanc.

Joannes Vermorel : Nous avons beaucoup parlé des difficultés liées à la préparation des données et à ce à quoi ressemble une mauvaise préparation des données. Mais pour résumer, à quoi ressemble une bonne préparation des données ? Dans une situation de supply chain modérément complexe, une bonne préparation des données ressemblerait à un livre bien structuré. Pensez-y comme à un livre de 400 pages avec une page par table ou vingt champs dans 20 tables. Mais ce n’est pas suffisant pour que ce soit juste un livre, il doit être bien écrit.

Si vous écrivez quelque chose d’incroyablement ennuyeux, personne ne le lira et cela n’aura aucun effet sur votre organisation. Donc, il doit être bien écrit. Et par bien écrit, je veux dire qu’il doit être lisible. Il doit également être rédigé du point de vue de l’entreprise. Ce n’est pas une documentation informatique. La préparation des données n’est vraiment pas un problème informatique, il s’agit plutôt d’avoir toutes les connaissances métier.

La perspective valide en affaires est toujours quelque chose qui change. Si le paysage concurrentiel de votre industrie change, alors la perspective valide sur un problème donné change également. Donc, ce livre doit être bien écrit et maintenu.

Il s’agit d’un effort très distribué au sein de votre entreprise car, par exemple, seule l’équipe de merchandising a l’aperçu et la perspective appropriés pour savoir comment les tables de merchandising doivent être documentées en premier lieu. Cette préparation des données ressemble à des documents propres et bien écrits, largement distribués et accessibles dans votre entreprise.

La chose intéressante est que, une fois que vous avez toutes ces connaissances, la transformation des données, qui est logique, devient une interprétation simple de la compréhension valide des données elles-mêmes. Vous devez fournir un énorme effort pour comprendre les données, les documenter, les écrire et les maintenir. Mais une fois que vous avez fait tout cela, l’écriture de la logique devient simple. Alors, à quoi ressemble une bonne préparation des données ? C’est comme un livre bien écrit, une compréhension partagée, une sorte de bible de la supply chain interne à votre entreprise.

Kieran Chandler : Ça a l’air bien ! Donc, les nuances de gris des données, est-ce que cela va être un nouveau best-seller de l’organisation ?

Joannes Vermorel : Possiblement, qui sait ?

Kieran Chandler : D’accord, eh bien, nous espérons que vous avez apprécié l’épisode d’aujourd’hui sur la préparation des données. Comme toujours, n’hésitez pas à nous contacter si vous avez d’autres questions et nous vous retrouverons la prochaine fois sur Lokad TV. Au revoir pour le moment.