00:00:03 Vue d’ensemble de la préparation des données en science des données.
00:00:46 Sous-estimer les 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 rapidité et à la précision 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éter la ‘date de commande’ dans les supply chains.
00:09:02 Complications dans l’interprétation des données dues aux 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 des systèmes de supply chain.
00:14:53 Nécessité de la 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 le périmètre des données dans la prise de décision automatisée.
00:18:42 Risques de compter sur des individus pour se souvenir des données.
00:19:02 Défis et attentes en matière de préparation des données.
00:20:13 La préparation des données comme effort à l’échelle de l’entreprise.
00:21:56 Évaluer la justesse de l’interprétation des données à travers l’efficacité concrète.
00:23:02 Conséquences d’une interprétation erronée 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 d’une “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 complexité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 d’importantes ressources, est vitale pour contourner le problème du “garbage in, garbage out”. Cela nécessite de transformer des données inconsistantes ou incomplètes en un format compréhensible, ce qui appelle à 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 plusieurs équipes organisationnelles, et soutient qu’une préparation efficace des données doit être accessible et faciliter une prise de décision.
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 l’essor des lois de conformité au RGPD, les données deviennent un enjeu central pour de nombreux dirigeants, et selon certaines estimations, les entreprises dépensent actuellement plus de 450 milliards de dollars uniquement pour la préparation des données. L’objectif de la préparation des données est de convertir des données brutes, souvent inconsistantes 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. Bien que les entreprises investissent d’importantes ressources dans ce domaine, de nombreux projets prennent du retard ou dépassent leur budget. Selon Vermorel, la plupart des bugs des systèmes informatiques peuvent être reliés à des problèmes au niveau de la préparation des données. Il explique que la nature multifacette des problèmes commerciaux se manifeste sous 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 des données à grande échelle peuvent prendre au moins quelques mois, s’étendant souvent jusqu’à six mois. Bien que l’on suppose qu’avec de meilleurs outils ou un logiciel plus évolutif le processus devrait être accéléré, il estime que le niveau de maturité global de l’écosystème ralentit le progrès. Pour véritablement éviter 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 à l’allongement des délais.
Interrogé sur la faisabilité d’accélérer ce processus, Vermorel explique que ce n’est pas aussi simple qu’ajouter simplement plus de ressources. Les données en question n’ont pas été initialement produites dans le but de préparer 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 inconsistantes ou erronées en raison de problèmes opérationnels pratiques, tels que des erreurs de code-barres. Ces incohérences nécessitent un travail préparatoire considérable pour une utilisation efficace dans l’optimization de la supply chain.
Vermorel évoque également 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 par une page de documentation par champ par table. Cette documentation complète est essentielle pour prévenir le problème d’une entrée de données de mauvaise qualité menant à 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 étendue.
Vermorel commence par aborder les complexités et les interprétations erronées potentielles pouvant découler d’une simple donnée : la date d’une commande historique. Il explique que le terme “date” n’est pas aussi simple qu’il n’y paraît, car il existe plusieurs interprétations possibles, comme le moment où le client a cliqué sur un produit, celui où il a validé son panier, le moment où le paiement a été traité, ou encore celui où les marchandises ont été mises à disposition dans l’entrepôt.
Il souligne que l’interprétation de ces données peut évoluer avec le temps en raison des mises à jour du système ou des changements dans les pratiques commerciales. Ainsi, il est 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 se heurter au problème du “garbage in, garbage out” où des interprétations incorrectes mènent à de mauvaises décisions.
Vermorel met en lumière 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é exacte de marchandises commandées est essentiel. Le système du client comporte une fonctionnalité selon laquelle, si la quantité livrée ne correspond pas exactement à la commande, l’intégralité de la commande est rejetée et renvoyée. Cela conduit à une situation où, s’ils reçoivent légèrement plus que commandé, ils doivent modifier la commande d’achat originale dans le système pour correspondre à la quantité livrée. Ce contournement leur permet d’accepter la livraison et
éviter les disruptions dans leurs opérations industrielles.
Cependant, ce processus est exploité par des fournisseurs astucieux qui livrent désormais légèrement plus que 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 déforment la performance de l’équipe des achats. Vermorel souligne que cette complexité doit être documentée pour éviter des interprétations erronées. Il insiste sur le fait que les problèmes ne proviennent pas d’une mauvaise performance de l’équipe d’achats, mais des limitations du système et de la manière dont les utilisateurs y font face.
Changeant d’angle, Vermorel discute de l’importance des données historiques, à part 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 finissent par disparaître avec le temps. C’est, selon lui, une forme de “darwinisme” dans le monde des affaires. Il suggère que les entreprises qui prêtent attention à leurs transactions financières au fil du temps se préoccupent 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 pleinement comprises. Il propose que la préparation des données n’est pas uniquement un problème informatique ; il s’agit de comprendre tous les aspects des données commerciales pour aborder tous les angles business. Le département informatique, note-t-il, ne peut être tenu de maîtriser tous les aspects commerciaux et ne devrait pas assumer seul la responsabilité de la préparation des données.
Vermorel propose une approche distribuée, impliquant différentes équipes dotées d’expertises spécifiques au sein de l’organisation. Les données pertinentes pour les achats, par exemple, devraient impliquer les équipes d’achats. De même, les données requises pour un tableau de bord fournisseur devraient impliquer les équipes d’approvisionnement. Cette approche permet de mobiliser les connaissances nécessaires pour une préparation efficace des données.
Pour aborder la certitude de l’interprétation des données, en particulier lorsque l’information est incomplète, Vermorel établit un parallèle avec les théories scientifiques ; il n’est pas possible de savoir si une théorie est juste, mais elle peut être validée lorsqu’elle résiste à l’examen critique. La justesse de la préparation des données est établie lorsque les décisions tirées de cette interprétation sont correctes. Si une préparation erronée des données conduit à des décisions aberrantes, la cause peut être retracée, corrigée et réévaluée.
Vermorel décrit ensuite à quoi devrait ressembler une bonne préparation des données, en particulier dans des scénarios complexes de supply chain. Il la compare à un livre bien rédigé, fournissant des éclairages et des perspectives commerciales pertinents, et non de simples détails techniques. Elle doit être accessible et diffusé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 le reflet 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 deviennent assez simples. Une bonne préparation des données est donc à la fois un guide bien rédigé et une compréhension partagée qui permet de prendre 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 fondamentaux de la science des données. Étant donné les récentes lois de conformité au RGPD, les données occupent une place importante dans l’esprit de nombreux dirigeants. C’est aussi un secteur lucratif, une récente enquête estimant que les entreprises dépensent plus de 450 milliards de dollars uniquement 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 pour qu’elles puissent être utilisées efficacement. Ce n’est pas une mince affaire quand on considère que les données proviennent de multiples sources et sont souvent inconsistantes, incomplètes et peuvent aussi 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 maîtrisions déjà.
Joannes Vermorel: Oui, absolument. La préparation des données est un domaine bien connu, et pourtant systématiquement sous-estimé en termes d’évolution. C’est intéressant car la plupart des projets de préparation des données finissent par manquer leurs échéances et entraîner des dépassements de budget. Le problème fondamental est que de nombreux bugs des systèmes informatiques, enterprise software en général, remontent à 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, la question centrale est que les complexités commerciales se manifestent sous forme d’étapes de préparation des données, faisant de ce domaine un espace sans limites. Il n’y a pas de recette définitive pour la préparation des données.
Kieran Chandler: Alors, combien de temps devrait-il falloir pour préparer une quantité importante de données ?
Joannes Vermorel: Je n’ai jamais vu un projet de préparation de données à grande échelle qui prenne moins de quelques mois. En général, c’est plutôt de l’ordre de six mois. Certains peuvent soutenir qu’avec de meilleurs outils et un logiciel plus évolutif, cela devrait aller plus vite. Cependant, la réalité est qu’il y a si peu de maturité dans l’écosystème que, pour à peu près n’importe quelle entreprise, à l’exception de quelques champions des données comme Google, les données doivent d’abord être documentées et clarifiées. Il y a tant de choses à faire avec ces données pour éviter le problème du “garbage in, garbage out”. Ainsi, il faut quelques mois, et six mois est un délai raisonnable si une supply chain complexe est impliquée.
Kieran Chandler: Six mois, cela 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 affecter plus de personnes au problème ?
Joannes Vermorel: On se retrouve avec un problème spécifique ici : peut-on avoir neuf femmes pour faire un bébé en un mois ? Le problème réside dans la compréhension du type de problèmes auxquels nous sommes confrontés. Tout d’abord, les données que vous possédez n’ont pas été produites pour être des données en premier lieu. Ce sont des sous-produits de votre système d’entreprise qui, par hasard, fait fonctionner votre entreprise. Prenons l’exemple d’un logiciel de point de vente, quelque chose où l’on peut payer dans un supermarché. Sa fonction principale est de traiter les clients qui souhaitent sortir du magasin tout en payant ce qu’ils doivent payer. Ainsi, si un code-barres ne se scanne pas pour quelque raison que ce soit, le caissier va probablement scanner un produit à prix similaire deux fois. Au final, vous paierez le bon prix, mais en termes de données, vous aurez un produit compté deux fois.
Kieran Chandler: Un produit non comptabilisé peut créer des problèmes en termes de gestion des stocks car vos dossiers électroniques deviennent décalés. 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 laisser votre entreprise fonctionner plus efficacement, ceux qui sont sur le terrain, les personnes qui doivent opérer physiquement la supply chain, favoriseront toujours une solution qui ne perturbe pas le flux des marchandises, des clients, du service et de tout le reste. Faire fonctionner l’entreprise est primordial et les données ne sont qu’un sous-produit secondaire. Elles ne sont jamais traitées comme une priorité absolue. C’est pourquoi il y a toujours tout ce travail à faire, car les données n’ont pas été collectées juste dans le but de vous permettre d’optimiser la supply chain. Est-ce de là que viennent tous ces défis ?
Joannes Vermorel: En effet, c’est de là que proviennent tous ces changements.
Kieran Chandler: Parlons de cette documentation dont tu as parlé plus tôt. Qu’attends-tu voir dans cette documentation et en quoi est-elle utile ? Juste pour comprendre, si nous revenons sur la période de six mois, quel volume de documentation attendons-nous ?
Joannes Vermorel: En règle générale, typiquement, chez Lokad, quand nous démarrons un projet, nous avons moins d’une ligne de documentation par table et par champ. Généralement, nous n’en avons même pas. Nous commençons de nombreux projets où nous n’avons même pas une seule ligne de documentation par table dans l’ERP, le MRP, le WMS, ou tout autre système utilisé pour gérer ta supply chain. Une fois terminés, nous obtenons une page de documentation par champ par table. Ainsi, si tu as 20 tables avec 20 champs, nous parlons de 400 pages de documentation. Oui, il faut six mois pour produire ces 400 pages de documentation.
Kieran Chandler: Cela ressemble à une quantité énorme de documentation. Est-ce vraiment tout nécessaire ?
Joannes Vermorel: Tout est nécessaire si tu veux éviter le principe “garbage in, garbage out”.
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 comporte une date. Mais est-ce simple ? Parlons-nous vraiment du type de date ? Est-ce la date à laquelle le client a cliqué sur un produit pour l’ajouter au panier sur le site le e-commerce ? Ou celle à laquelle le client a validé le panier et effectué le paiement ? Ou encore celle à laquelle le paiement a été validé par le processeur de cartes de crédit ? Ou celle à laquelle l’enregistrement a été inscrit dans le système ? Ou celle à laquelle la commande d’achat a été modifiée pour la dernière fois dans le système ? Il y a environ 20 interprétations différentes rien que pour ce champ “date”.
De plus, si ton entreprise a plus d’une décennie d’histoire, il est fort probable que la subtilité de l’interprétation de la “order date” ait évolué au fil des ans. Tu pourrais te retrouver dans une situation où une mise à niveau du système a modifié la sémantique de cette colonne.
Ce n’est pas non plus quelque chose de naturellement homogène sur toute ton histoire. Ensuite, tu peux rencontrer d’autres complications, comme des cas limites. Par exemple, cette date est censée être celle à laquelle le client a validé le panier, sauf si le paiement a finalement été rejeté pour fraude. Dans ce cas, c’est la date et l’heure à laquelle la commande a été rejetée pour fraude.
Encore une fois, ce n’est pas vraiment une bonne conception, mais les entreprises qui gèrent des supply chains complexes disposent de systèmes complexes et d’une longue histoire. Ainsi, l’informatique n’a pas forcément été réalisée parfaitement dès le départ, et il faut composer avec toutes ces complications historiques. Elles finissent par se refléter dans cette documentation. Si tu ne prends pas en compte toutes ces complications, tu rencontreras des problèmes chaque fois que tu voudras analyser ces données.
Kieran Chandler: Pour générer une décision optimisée pour ta supply chain, tu peux te retrouver avec un problème de “garbage in, garbage out” si tu interprètes incorrectement les données. Donc, ce que tu dis, c’est qu’il s’agit avant tout de clarifier la sémantique des données, n’est-ce pas ?
Joannes Vermorel: Exactement. Il faut 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 la manière dont les gens interagissent avec le logiciel. Ta documentation doit prendre en compte l’aspect humain de ce que font les gens.
Kieran Chandler: As-tu un bon exemple de la manière dont l’un de tes clients a rencontré ce problème par le passé et de l’impact que cela a eu sur son entreprise ?
Joannes Vermorel: Oui, je peux donner un exemple. Nous avions un client qui menait une opération très exigeante nécessitant un haut niveau de disponibilité. Ils passaient des bons de commande avec des délais très courts à leurs fournisseurs. Leur système comportait une caractéristique de conception intéressante. Si la quantité de marchandises livrées ne correspondait pas aux quantités initialement demandées, alors le bon de commande entier devait être rejeté et renvoyé au fournisseur.
Prenons, par exemple, que tu commandes 1 000 unités, mais que le fournisseur en livre 1 050, alors tu devrais la rejeter. Le problème, c’est que si tu la rejettes, 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’était que lorsque les quantités livrées ne correspondaient pas aux quantités commandées, ils modifiaient le bon de commande initial pour refléter la quantité livrée.
Kieran Chandler: Donc, ce que tu dis, c’est qu’ils modifiaient le bon de commande initial pour correspondre à ce qui était livré ?
Joannes Vermorel: Exactement. Cependant, cela a ouvert une autre problématique. Les fournisseurs se sont rendus compte de cette pratique. Ils ont compris qu’ils pouvaient livrer plus que ce qui était commandé, sachant que l’entreprise avait besoin de ces fournitures. Ils ne livreraient pas une quantité démesurée, mais une quantité que l’entreprise considérerait comme acceptable.
Dans les données, il apparaîtrait comme si la commande initiale était pour une quantité plus importante. Cela a abouti à des données étranges où les bons de commande semblaient trop élevés par rapport à ce qui était nécessaire, donnant l’impression que l’équipe achat était mauvaise pour choisir les bonnes quantités. Cependant, le problème ne venait pas de l’équipe achat, mais des limites du système et de la manière dont les gens faisaient face à ces limites.
Tous ces détails devaient être documentés pour éviter de tirer de mauvaises conclusions. L’équipe achat n’était pas incompétente dans son travail. Le problème était qu’ils disposaient d’un système avec des limites qu’ils essayaient simplement de contourner.
Kieran Chandler: Le système génère tous ces effets secondaires bizarres. Il nécessite une page d’explications si tu veux en comprendre le sens, mais il n’y a pas d’échappatoire. C’est simplement la complexité même du business qui se reflète dans ces données. Éloignons-nous de ces fournisseurs sournois. C’est définitivement un exemple divertissant. Donc, tu as mentionné l’aspect humain. Évidemment, chez Lokad nous utilisons les données historiques pour faire des prévisions probabilistes pour l’avenir. Qui, à part nous, se soucie réellement des données historiques ?
Joannes Vermorel: Typiquement, tout ce qui touchait réellement au montant d’argent que tu devais t’attendre à recevoir ou à payer attirait 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 tu n’y prêtes même pas attention, tu disparais. C’est pourquoi, il y a environ cinq siècles, la comptabilité en partie double a été inventée par des moines italiens. Si tu ne fais pas attention, ton monastère s’effondre à cause 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 par le passé et qui deviennent désormais critiques.
Pour te donner un exemple, pour comptabiliser correctement les ruptures de stock par le passé, tu prenais en compte ce que tu achetais, afin de savoir ce que tu devais payer à tes fournisseurs, et ce que tu vendais, afin de savoir ce que tes clients devaient te payer. Mais qu’en est-il du suivi des ruptures de stock historiques ? Tant que tu as un praticien de la supply chain qui décide manuellement des quantités à acheter et se souvient qu’il y a eu des périodes bizarres de ruptures de stock, il n’est pas nécessaire de disposer de ces enregistrements historiques. Ils font partie de ton système.
Le problème, c’est que dès que tu souhaites 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, disposer d’enregistrements précis sur les niveaux de stock historiques devient beaucoup plus important. Sinon, ton automatisation interprète mal ce qui relève des ventes et ce qui relève du manque de demande.
Si tu veux une automatisation plus poussée dans ta société, tu dois prêter attention à un spectre plus large de données, pas seulement aux données comptables brutes. Ton comptable ne se soucie pas de tes jours de ruptures de stock, mais ton logiciel d’optimization de la supply chain le fera. Tu dois élargir le cercle des données qui font vraiment partie de ton périmètre, qui sont documentées, et pour lesquelles tu as besoin de contrôle et d’assurance qualité.
Kieran Chandler: Donc, nous dépendons assez fortement de cette seule personne qui se souvient de ce qui s’est passé dans le passé. Ne devrions-nous pas mieux préparer les données au fur et à mesure de leur arrivée ? Le département informatique ou quelqu’un d’autre ne devrait-il pas préparer ces données et s’assurer qu’elles sont propres dès le départ ? Cela semble être une manière plus simple de faire les choses.
Joannes Vermorel: Oui, mais le problème ne réside pas dans la compétence informatique. Il n’existe pas de données propres par nature. Le fait est que les données ne sont pas comprises de manière suffisamment approfondie et que tous les angles business 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é même du business qui se révèle dans cette tâche, ce défi de préparer les données. Et dire, “oh, le département informatique devrait s’en occuper”, revient à s’attendre à ce que l’informatique gère l’entreprise et maîtrise tous les aspects du business.
Joannes Vermorel: Absolument, cela crée soudainement un problème organisationnel parce que tu t’attends à ce que l’informatique soit autant experte en ressources humaines, marketing, achats, etc. Je veux dire, tu t’attends à une maîtrise complète de tous les aspects business de la part du département informatique. Mais c’est trop demander. Le département informatique doit déjà gérer tous les changements IT, il ne devrait donc pas être attendu pour résoudre chaque problème business de l’entreprise. Autrement, tu pourrais redéfinir l’informatique comme étant l’ensemble de ton entreprise, mais cela va à l’encontre du but recherché.
Revenant au cas d’espèce, la préparation des données doit être un effort assez distribué au sein de l’entreprise car, en fin de compte, les seules personnes capables de fournir le niveau d’expertise nécessaire pour préparer les données pertinentes pour, par exemple, les achats, sont les équipes achat. De même, si tu souhaites établir un tableau de bord fournisseur et préparer les données avec une précision suffisante pour qu’elles aient vraiment du sens, il te faudra parler à tes équipes responsables de l’approvisionnement.
Chaque fois que tu abordes un problème, il faut impliquer les personnes spécialistes de ce problème au sein de ton entreprise, car ce sont elles qui te fourniront l’expertise nécessaire pour que la préparation des données ait du sens. Ce n’est pas strictement un problème informatique. Il s’agit de rassembler toute la compréhension requise afin que lorsque tu traites les données, tu ne te retrouves pas avec des données dépourvues de sens par rapport au problème business à résoudre.
Kieran Chandler: Donc, d’après ce que j’entends, nous n’y sommes pas encore tout à fait. Certaines entreprises y parviennent, mais elles sont l’exception, pas la règle. Comment peux-tu être sûr, si tu n’as pas toutes les informations et qu’il y a des lacunes dans ton interprétation, que ton 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. Tu ne sais jamais que ta théorie est correcte, tu sais juste qu’elle est suffisamment bonne et, lorsqu’elle est mise à l’épreuve dans la pratique, elle fonctionne. Tu n’as 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 tu sais que ta préparation des données est correcte lorsque, à la fin du pipeline de données, les décisions que tu génères automatiquement sur la base de cette interprétation sont correctes. Si tu as des décisions correctes, cela signifie que ta logique d’optimization est efficace, que tes couches de machine learning sont précises, et bien d’autres choses. Fondamentalement, il n’est tout simplement pas possible d’obtenir des décisions correctes générées par une interprétation incorrecte. Généralement, lorsque tu n’interprètes pas et ne prépares pas correctement tes données, cela dénature tes résultats de manière si profonde 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’en avoir confiance, puis de générer les décisions. Si les décisions sont absurdes, tu reviens sur tes pas, identifies la cause profonde du problème – souvent c’est la préparation des données – et tu corriges cela. Si, au final, les décisions qui sortent de ton système ont du sens pour un praticien qui utilise son propre jugement, alors tu sais que c’est correct.
Kieran Chandler: On pourrait dire, je pense 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 parce que cela explique des pics ou des chutes inhabituels de la demande, et que nous n’avons pas encore ces données.” Donc, ce n’est pas une situation binaire.
Joannes Vermorel: Nous avons beaucoup parlé des difficultés liées à la préparation des données et de 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é. Pensons-y comme à un livre de 400 pages avec une page par table ou vingt champs dans 20 tables. Mais il ne suffit pas que ce soit simplement un livre, il doit être bien rédigé.
Si tu rédiges quelque chose d’incroyablement ennuyeux, personne ne le lira, et cela n’aura aucun effet sur ton organisation. Il faut donc que ce soit bien écrit. Et par bien écrit, j’entends que cela doit être lisible. Il doit également être rédigé d’un point de vue business. Ce n’est pas une documentation informatique. La préparation des données n’est vraiment pas un problème informatique, c’est surtout une question de disposer de toutes les perspectives business.
La perspective valable dans le business est toujours quelque chose qui change. Si le paysage concurrentiel dans ton secteur évolue, alors la perspective valable sur un problème donné change également. Ce livre doit donc être bien écrit et maintenu à jour.
C’est un effort très distribué au sein de ton entreprise car, par exemple, seule l’équipe merchandising possède la bonne expertise et perspective pour savoir comment les tables merchandising doivent être documentées dès le départ. Cette préparation des données se présente sous la forme de documents clairs et bien rédigés, largement diffusés et accessibles dans ton entreprise.
L’aspect intéressant, c’est qu’une fois que vous avez toutes ces informations, 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 investir énormément d’effort pour comprendre les données, les documenter, les rédiger et les maintenir. Mais une fois que vous avez fait tout cela, écrire la logique devient simple. Alors, à quoi ressemble une bonne préparation de données ? C’est comme un livre bien écrit, une compréhension partagée, une sorte de bible supply chain qui est interne à votre entreprise.
Kieran Chandler: Ça sonne bien ! Alors, data shades of grey, est-ce que cela va devenir un nouveau best-seller provenant de l’organisation ?
Joannes Vermorel: Peut-être, qui sait ?
Kieran Chandler: D’accord, nous espérons que vous avez apprécié l’épisode d’aujourd’hui sur la préparation des données. Comme toujours, contactez-nous si vous avez d’autres questions et nous nous reverrons la prochaine fois sur Lokad TV. Au revoir pour l’instant.
