00:00:07 Accuser les mauvaises données dans les projets de supply chain.
00:00:33 Pourquoi les mauvaises données sont une excuse facile pour l’échec d’un projet.
00:01:42 Les défis liés aux mauvaises données et les idées fausses sur leur qualité.
00:03:16 Difficultés d’accès aux données des systèmes ERP et défis avec les fournisseurs.
00:06:32 Problèmes survenant lors de la migration entre les systèmes ERP et la corruption des données.
00:08:01 Traitement des saisies de données incorrectes et leur impact sur les systèmes ERP.
00:09:48 Prévision et détection des problèmes dans les données historiques.
00:11:37 Comment l’évolution de la sémantique et les changements de définition peuvent entraîner des problèmes de données.
00:12:20 Problèmes de scalabilité et optimisation de la récupération des données à mesure que les entreprises grandissent.
00:14:45 Défis de création d’extractions quotidiennes propres et potentiel d’erreurs de données.
00:16:02 L’impact des temps de traitement plus longs sur la résolution de problèmes dans les services informatiques.
00:17:15 La question de la sémantique des données et des malentendus dans l’interprétation des données.
00:19:22 L’importance de la documentation pour chaque champ de données afin d’assurer une compréhension adéquate.
00:21:01 Rôles des praticiens de la supply chain et du service informatique dans la compréhension de la sémantique des données.
00:23:59 La gamme de problèmes relevant des mauvaises données et l’identification des causes profondes.
Résumé
Dans cette interview, Kieran Chandler et Joannes Vermorel discutent du rôle des données dans l’optimisation de la supply chain et des défis auxquels sont confrontés les vendeurs de logiciels et les praticiens. Vermorel souligne que le principal problème n’est pas les “mauvaises données”, mais plutôt leur accès et leur utilisation efficaces. Les défis comprennent les systèmes obsolètes, la documentation insuffisante et la responsabilité de l’accès aux données. Les conflits d’intérêts avec les intégrateurs, les problèmes de migration de système, la prévision et la scalabilité posent également des problèmes. Pour optimiser la gestion de la supply chain, les entreprises doivent comprendre et résoudre les problèmes de données, investir dans une documentation adéquate, clarifier la sémantique des données et maintenir des attentes réalistes, plutôt que de blâmer les données pour les échecs.
Résumé étendu
Dans cette interview, Kieran Chandler et Joannes Vermorel, fondateur de Lokad, discutent du rôle des données dans les projets d’optimisation de la supply chain et des défis auxquels sont confrontés les vendeurs de logiciels et les praticiens de la supply chain. Ils commencent par aborder l’idée que les “mauvaises données” sont souvent utilisées comme bouc émissaire pour expliquer l’échec des projets de supply chain. Vermorel souligne que blâmer les données est un moyen pratique d’éviter de rejeter la faute sur des personnes qui pourraient le prendre personnellement et réagir. Cependant, il souligne également l’importance de comprendre la cause profonde d’un problème.
Vermorel affirme que les problèmes liés aux données sont probablement la principale cause d’échec des projets d’optimisation de la supply chain, mais la perception des “mauvaises données” est souvent erronée. Il soutient que la plupart des entreprises occidentales disposent de données précises depuis des décennies, grâce à l’utilisation de codes-barres, de lecteurs de codes-barres et d’autres technologies. Selon Vermorel, le véritable problème réside non pas dans la qualité des données elles-mêmes, mais dans les défis liés à leur accès et à leur utilisation.
L’un des principaux défis pour utiliser efficacement les données est d’y avoir accès. De nombreuses entreprises utilisent depuis des années différents systèmes de planification des ressources de l’entreprise (ERP), des systèmes de gestion d’entrepôt (WMS), des systèmes de gestion des transports (TMS) et d’autres solutions logicielles, mais ces systèmes peuvent être difficiles à utiliser lorsqu’il s’agit d’exporter des données. Vermorel identifie quelques scénarios où l’accès aux données peut être particulièrement problématique :
1 Systèmes anciens : Certaines entreprises utilisent encore des systèmes vieux de 40 ans, avec des infrastructures obsolètes et propriétaires qui rendent l’extraction des données extrêmement difficile. 2 Manque de documentation : Les fournisseurs de logiciels peuvent ne pas fournir une documentation adéquate pour leurs systèmes, ce qui rend difficile la compréhension et la navigation dans les nombreuses tables et champs présents dans les bases de données. 3 Responsabilité et accès : Déterminer qui est responsable d’accorder l’accès aux données peut être un défi, car cela implique plusieurs parties prenantes au sein d’une entreprise, notamment le fournisseur de logiciels, le service informatique et les praticiens de la supply chain. L6 Les entretiens mettent en évidence l’importance de comprendre et de résoudre les défis liés aux données dans les projets d’optimisation de la supply chain. Bien que la qualité des données elles-mêmes ne soit généralement pas le problème, les difficultés d’accès et d’utilisation peuvent contribuer à l’échec de ces projets. Identifier et résoudre les causes profondes de ces défis est essentiel pour assurer le succès des initiatives d’optimisation de la supply chain. L7 Ils abordent les problèmes de données qui peuvent survenir dans les relations avec les fournisseurs, les intégrations de systèmes et la scalabilité à mesure que les entreprises se développent. L8
L9 Un problème clé qu’ils abordent est le potentiel de conflits d’intérêts avec les intégrateurs, qui peuvent être plus intéressés à vendre leurs propres solutions d’optimisation de la supply chain plutôt qu’à coopérer avec le fournisseur choisi par l’entreprise. Cela peut conduire à ce que les entreprises soient prises en otage par leurs intégrateurs, rendant difficile l’accès ou l’utilisation efficace de leurs données.
L10 Un autre défi survient lors de la migration d’un système de planification des ressources de l’entreprise (ERP) à un autre, ce qui peut entraîner une mauvaise qualité des données ou une “intégration de déchets”. Bien que les entrées de données individuelles puissent être précises, le processus de migration des données historiques entre les systèmes peut introduire des erreurs, car il n’y a souvent pas de correspondance directe un à un entre les données dans les anciens et les nouveaux systèmes. Cela peut entraîner une corruption des données, qui peut ne pas avoir un impact significatif sur les opérations quotidiennes, mais peut réapparaître comme un problème lors de projets d’optimisation de la supply chain ou de traitement des données.
Un autre défi survient lors de la migration d’un système de planification des ressources de l’entreprise (ERP) à un autre, ce qui peut entraîner une mauvaise qualité des données ou une “intégration de déchets”. Bien que les entrées de données individuelles puissent être précises, le processus de migration des données historiques entre les systèmes peut introduire des erreurs, car il n’y a souvent pas de correspondance directe un à un entre les données dans les anciens et les nouveaux systèmes. Cela peut entraîner une corruption des données, qui peut ne pas avoir un impact significatif sur les opérations quotidiennes, mais peut réapparaître comme un problème lors de projets d’optimisation de la supply chain ou de traitement des données.
L11 L’interview aborde également la prévision basée sur les données historiques, ce qui peut être difficile en raison de l’incertitude inhérente à l’avenir. Repérer les problèmes dans les données historiques est plus facile lorsque les problèmes sont visibles, tels que des lacunes ou des changements soudains dans les données. Cependant, des changements subtils dans la sémantique ou les définitions au fil du temps peuvent conduire à des problèmes plus difficiles à détecter, en particulier lors de la migration entre les systèmes.
L’interview aborde également la prévision basée sur les données historiques, ce qui peut être difficile en raison de l’incertitude inhérente à l’avenir. Repérer les problèmes dans les données historiques est plus facile lorsque les problèmes sont visibles, tels que des lacunes ou des changements soudains dans les données. Cependant, des changements subtils dans la sémantique ou les définitions au fil du temps peuvent conduire à des problèmes plus difficiles à détecter, en particulier lors de la migration entre les systèmes.
À mesure que les entreprises se développent, la scalabilité peut également introduire des problèmes de données. Pour les petites entreprises, l’ensemble des données historiques peut souvent tenir sur un smartphone, ce qui rend l’optimisation moins préoccupante. Cependant, à mesure que les entreprises grandissent, le volume de données peut devenir un problème. La discussion met l’accent sur l’importance de comprendre et de résoudre ces problèmes de données afin d’optimiser efficacement la gestion de la supply chain.
Vermorel explique que les entreprises ont souvent du mal à extraire des données de leurs systèmes de planification des ressources de l’entreprise (ERP), car ces systèmes ne sont pas conçus pour fournir des incréments de données quotidiens propres. Cela entraîne des processus complexes, qui peuvent entraîner une extraction incorrecte des données et introduire des bugs. Le débogage et la résolution de ces problèmes peuvent prendre du temps, des semaines au lieu d’heures, en raison de la quantité de données impliquées et des temps de traitement lents.
De nombreuses entreprises pensent avoir de bonnes données, mais en réalité, la sémantique des données est souvent peu claire. Cela peut entraîner des malentendus et des calculs trompeurs. Par exemple, une “date de commande” peut avoir plusieurs interprétations, comme l’heure à laquelle la commande a été passée par le client, l’heure à laquelle elle a été enregistrée dans le système ou l’heure à laquelle le paiement a été confirmé. Pour éviter les mauvaises interprétations, Vermorel suggère que les entreprises devraient disposer d’une documentation détaillée pour chaque champ et table de leurs systèmes de données, reflétant la complexité de leur supply chain.
Un problème courant dans l’optimisation de la supply chain est que les praticiens ne passent peut-être pas suffisamment de temps à qualifier leurs données, ce qui fait que les fournisseurs travaillent avec des informations incomplètes ou peu claires. Cela peut entraîner une situation de “garbage in, garbage out”, où les données ne sont pas nécessairement incorrectes mais sont mal comprises en raison d’une mauvaise documentation.
Pour résoudre ces problèmes, Vermorel souligne l’importance d’identifier la cause profonde du problème, qui implique généralement des personnes et des structures organisationnelles. Les entreprises doivent comprendre qui est responsable de l’échec et travailler à résoudre les problèmes sous-jacents, plutôt que de simplement blâmer les données. Les fournisseurs doivent également être honnêtes quant aux défis et au temps nécessaires pour clarifier la sémantique des données, au lieu d’être excessivement optimistes pour conclure des accords.
Les entreprises doivent investir dans une documentation appropriée, une sémantique claire des données et des attentes réalistes pour optimiser leur supply chain et éviter les échecs liés aux problèmes de données.
Full Transcript
Kieran Chandler: Aujourd’hui sur Lokad TV, nous allons comprendre pourquoi c’est un diagnostic si imprécis et aussi comprendre certains des défis liés aux données auxquels les fournisseurs de logiciels et les praticiens de la supply chain peuvent être confrontés. Alors Joannes, pourquoi les mauvaises données sont-elles une excuse si facile ?
Joannes Vermorel: Tout d’abord, parce que les données ne peuvent pas se plaindre. Personne ne va les défendre, donc vous blâmez quelque chose d’inerte, ce qui est mieux que de blâmer un collègue qui va le prendre personnellement et se défendre. Mais la réalité est que lorsque vous remontez à la cause profonde, ce sont toujours les personnes qui sont responsables du problème. Blâmer les données revient un peu à sauter l’étape d’identification de la cause profonde du problème.
Kieran Chandler: Il est certainement facile de s’en prendre à quelque chose qui ne va pas se défendre. Alors comment pouvons-nous être plus précis ? Quels sont certains des défis ?
Joannes Vermorel: Les problèmes liés aux données sont probablement la principale cause d’échec des projets d’optimisation de la supply chain. Mais il y a des idées fausses. Lorsque les gens parlent de “mauvaises données”, ils veulent dire des chiffres corrompus ou incorrects. Cependant, pour la plupart des entreprises occidentales, elles disposent de données très précises depuis des décennies. Presque personne ne saisit de mauvais numéros de pièces ou ne fait de fautes de frappe. Elles utilisent des codes-barres, des scanners de codes-barres et d’autres astuces comme la RFID. La quantité de données vraiment mauvaises est généralement très faible et elle n’est pas suffisante pour expliquer pourquoi la plupart des initiatives échouent en raison de problèmes liés aux données.
Kieran Chandler: Si la grande majorité des entreprises occidentales collectent des données assez bonnes, quels sont certains des défis auxquels nous pouvons être confrontés et qui nous font penser que les données ne sont pas si bonnes ?
Joannes Vermorel: Le premier problème est d’accéder aux données. Vous seriez surpris. Les entreprises utilisent depuis des décennies différentes versions de progiciels de gestion intégrée (ERP), de WMS, de TMS ou d’autres logiciels d’entreprise pour gérer et exploiter leurs activités quotidiennes. Mais la plupart de ces systèmes ne sont pas très conviviaux lorsqu’il s’agit d’exporter des données. Dans certains cas, vous avez des systèmes si anciens que vous n’avez même pas de base de données SQL relationnelle appropriée pour sauvegarder le système. Dans ce genre de situation, il est vraiment difficile d’extraire les données car l’arrière-plan est généralement complètement obsolète et propriétaire.
Kieran Chandler: Alors qui est responsable de cela ?
Joannes Vermorel: Il y a plusieurs responsabilités ici. Tout d’abord, vous pouvez avoir le fournisseur de logiciels qui n’a pas fourni de documentation significative sur le système. Dans les pires scénarios, vous ouvrez votre base de données et vous réalisez que votre ERP contient 2 000 tables, chacune avec 20 à 200 champs, et c’est un cauchemar. C’est énorme, et vous ne savez pas par où commencer. Même si vous savez où chercher, vous pouvez avoir un problème avec le fournisseur, puis vous pouvez avoir un problème avec l’intégrateur. Le problème avec l’intégrateur est qu’il peut y avoir un conflit d’intérêts. Certains intégrateurs peuvent avoir un vif intérêt à vous vendre leur propre recette d’optimisation de la supply chain, pour ce module ou cet autre module, ou quelque chose du genre. Et lorsque vous leur demandez de faire une extraction de données pour vous, pour vos équipes internes ou pour toute autre initiative que vous souhaitez mener avec un autre fournisseur, l’intégrateur peut être - cela arrive, nous l’avons vu de nombreuses fois - tout simplement peu coopératif. Parce que, encore une fois, pour eux, il est dans leur intérêt stratégique de ne pas être concurrentiel. Et ici, vous avez une situation de prise d’otages où l’entreprise est prise - de fait prise en otage par l’intégrateur. L’entreprise, la société informatique responsable de la configuration, parfois de l’hébergement, et en général, vous savez, de la maintenance de l’ERP ou de l’autre système informatique de l’entreprise. C’est donc un autre type de problème de données. Mais vous voyez, cela a très peu à voir avec les données.
Kieran Chandler: Oui, certainement. Ne pas pouvoir accéder à vos données semble être un obstacle assez important. Et qu’en est-il des autres défis qui peuvent survenir ? Un gros casse-tête pour beaucoup de nos clients est lorsqu’ils migrent d’un système ERP à un autre système ERP. Que peut-il arriver aux données dans ce cas ?
Joannes Vermorel: Cela peut causer des problèmes. C’est le genre de situation où vous pouvez avoir un autre type de mauvaises données. Mais ici, c’est vraiment lorsque vous avez une intégration incorrecte que les données deviennent mauvaises. En général, les saisies de données sont correctes, mais lorsque vous passez d’un ERP à un autre, ce que le fournisseur ou l’intégrateur, voire votre service informatique interne, va essayer de faire, c’est de migrer les données historiques du système ancien vers le nouveau système. Le problème, c’est qu’il n’y a pas de correspondance directe entre ce qui était une vente enregistrée dans l’ancien système et ce qui est une vente enregistrée dans le nouveau système. Peut-être que les choses sont simplement organisées différemment, et il n’y a donc aucun moyen clair de reporter les comptes clients de l’ancien système vers le nouveau système. Et vous vous retrouvez peut-être avec des intégrations provisoires, ce qui peut entraîner une corruption des données, c’est-à-dire que si vous réintégrez incorrectement votre historique, cela n’empêchera pas votre entreprise de fonctionner au jour le jour. Vous voyez, si les données de l’Est Oracle sont importées de manière incorrecte dans le nouveau système, cela n’aura pas d’impact sur la plupart des opérations quotidiennes. Et même s’il y a un impact, quelqu’un fera généralement rapidement une correction pour quelque chose qui est incorrect et continuera. Cela peut être une source de friction continue, mais d’abord, cela disparaît rapidement car si les gens trébuchent, par exemple, disons que vous avez des codes fournisseurs qui ont été importés de manière incorrecte. Je veux dire, il y a de fortes chances que vous n’ayez pas un million de fournisseurs, donc vos 100 fournisseurs les plus fréquents seront probablement corrigés en termes de correction des saisies de données incorrectes dans les deux semaines suivant la date de début d’utilisation du nouveau système. Et peut-être, vous savez, trois mois plus tard, vous avez pratiquement corrigé chaque saisie incorrecte de fournisseur. Mais le problème, c’est que le code historique, les gens ne vont pas revenir en arrière et corriger les données historiques. Disons que vous aviez cinq ans d’historique, peut-être trois
Kieran Chandler: À l’avenir, est-il facile de repérer ces problèmes qui ont pu se produire dans le passé ?
Joannes Vermorel: Il est facile de repérer ces problèmes lorsqu’il y a des problèmes visibles, tels que des données manquantes pendant quelques mois. Cependant, il peut y avoir des changements subtils plus difficiles à repérer, tels que des différences dans la façon dont les ventes sont comptabilisées, que la fraude ou les retours soient inclus ou non. Cela peut entraîner de nombreux problèmes difficiles à repérer dans les données historiques, car la définition même des données que vous regardez a changé au fil du temps, et cela n’est pas évident à moins qu’il y ait une augmentation ou une baisse notable.
Kieran Chandler: Un autre problème courant chez les clients avec lesquels nous discutons est la scalabilité. Lorsqu’une entreprise se développe, ses données deviennent de plus en plus complexes. Quels sont les problèmes que la scalabilité peut entraîner ?
Joannes Vermorel: Lorsque vous n’avez aucun problème de scalabilité, vous pouvez simplement copier toutes les données de l’entreprise chaque jour. Pour les petites entreprises, cela peut être gérable car leur historique complet peut être inférieur à 10 gigaoctets. Cependant, à mesure que vous vous développez pour devenir une grande entreprise, vous vous retrouvez avec beaucoup plus de données, et vous devez passer à une récupération de données incrémentielle. Cela signifie extraire une partie des données chaque jour, et certains systèmes ne sont pas conçus pour gérer cela de manière efficace ou précise. Vous devez donc effectuer des opérations complexes pour construire une extraction quotidienne propre, et dans ce processus, vous vous exposez à des problèmes potentiels.
Kieran Chandler: Ainsi, à la fin, vous vous retrouvez avec de mauvaises données simplement parce que vous voulez effectuer une extraction de données de manière incrémentielle, et c’est délicat car le système n’a peut-être pas été conçu pour cette tâche. Lorsque vous pensez au débogage, vous voulez simplement copier des données d’un endroit à un autre, et cela peut être un problème très banal. Si le processus prend une minute, quelqu’un de votre service informatique peut passer cinq minutes, déclencher le processus et être sûr que cela fonctionne. Cependant, si le processus prend six heures pour se terminer, cela devient un processus plus fastidieux. Pouvez-vous expliquer les défis dans cette situation ?
Joannes Vermorel: Bien sûr. Imaginez que vous avez un système où le processus prend six heures pour se terminer. Dans votre service informatique, quelqu’un va lancer le processus, attendre 10 minutes, se rendre compte que cela prend trop de temps et faire autre chose. Il pourrait même l’oublier. Le lendemain, il pourrait remarquer un petit bug qui a provoqué un plantage après six heures. Pour reproduire le problème, il faut encore six heures de retard. En conséquence, vous vous retrouvez avec des problèmes qui pourraient être résolus en quelques heures seulement, mais en raison de la complexité accrue et des temps de traitement plus longs, cela devient un processus très fastidieux où les retards totaux se comptent en semaines. Non pas parce que cela prend des semaines d’effort, mais parce que les gens lancent le processus, l’oublient et reviennent le lendemain. Cela entraîne des itérations très lentes.
Kieran Chandler: À quel point diriez-vous que ces problèmes sont répandus ? Y a-t-il beaucoup d’entreprises qui pensent réellement avoir de très bonnes données, mais en réalité, lorsque vous les examinez de plus près, elles ne sont pas si bonnes que ça ?
Joannes Vermorel: Oui, il y a un autre problème que nous n’avons pas abordé, qui est la sémantique elle-même. Beaucoup d’entreprises pensent avoir de bonnes données, mais en réalité, les données ont une sémantique inconnue. Ce que je veux dire par là, c’est que, par exemple, lorsque nous parlons d’une date de commande, il peut y avoir de nombreuses interprétations possibles. Cela pourrait être la date de commande du client, l’heure à laquelle la commande a été passée sur le site web, enregistrée dans le système, ou même lorsque le paiement a été confirmé comme étant valide. Il pourrait y avoir 20 interprétations différentes de ce que cette date de commande signifie.
Lorsque nous commençons à travailler avec des clients, nous rencontrons généralement des tables et des colonnes avec peu de documentation. Mais lorsque nous avons fini de préparer les données, nous avons près d’une page de documentation par champ par table. Une situation typique de supply chain compte environ 20 tables avec 20 champs, donc nous parlons de 400 pages de documentation pour clarifier ce que signifient les données. Les gens sont généralement très surpris par cela, mais c’est nécessaire pour comprendre correctement les données.
Kieran Chandler: Joannes, pouvez-vous parler de l’importance de bien comprendre les données dans l’optimisation de la supply chain ?
Joannes Vermorel: Oui, c’est la complexité de votre supply chain qui se reflète dans ces données, et si vous ne faites pas ce travail, vous vous retrouvez avec des données que vous ne comprenez pas correctement. Ainsi, c’est “garbage in, garbage out”. Ce n’est pas que les données sont mauvaises, dans le sens où les chiffres sont incorrects, mais vous ne savez pas ce que signifient les données. Donc, si vous avez une date que vous ne comprenez pas correctement, quelle que soit la calcul ou la modernisation que vous allez faire, cela va finir par quelque chose de trompeur. Ainsi, la sémantique des données est la conclusion clé, et la documentation doit être en place avant même de commencer un projet.
Kieran Chandler: Alors, qui est responsable en ce qui concerne la sémantique ?
Joannes Vermorel: Je dirais que ce sont les praticiens de la supply chain qui devraient être responsables. La plupart d’entre eux diraient que c’est un problème informatique. Mais, la façon dont vous voyez la sémantique des données dépend vraiment du processus que vous avez. Si vous avez le processus où vous scannez les produits à l’entrée de l’entrepôt parce que vous avez ce processus, cela échappe au département informatique. Ils ne sont pas sur le terrain dans l’entrepôt, donc ils ne savent pas exactement comment votre processus est configuré. Les seules personnes qui savent exactement, car ces données sont simplement le résultat d’un processus qui génère, sont en première place dans le système. Ainsi, mon point est de ne pas attendre de l’informatique, qui ne fait que gérer les machines, s’assurer que le logiciel dispose de suffisamment de mémoire de calcul, de bande passante et de disque, d’avoir les idées, les compétences et la compréhension pour comprendre ce que signifient les données. Ce que signifient les données est généralement un problème très spécifique à l’entreprise. Ce n’est pas du tout un problème informatique. Ainsi, généralement, la responsabilité incombe également fréquemment aux praticiens. Les praticiens n’ont pas passé suffisamment de temps à les qualifier correctement avec leurs propres mots et leur propre compréhension. Ainsi, lorsqu’il y a cette optimisation de la supply chain, vous vous retrouvez avec un fournisseur qui traite ces données à moitié aveugle. Cela se termine par “garbage in, garbage out”.
Kieran Chandler: Alors, le fournisseur peut-il aussi être en faute ?
Joannes Vermorel: Oui, évidemment, le fournisseur peut aussi être en faute. Des entreprises comme Coke Ad qui font de l’optimisation de la supply chain, et généralement lorsque le fournisseur est en faute, c’est parce que le fournisseur essaie d’être astucieux. Habituellement, ils essaient de minimiser leur défi parce qu’ils essaient de vendre un problème. Ils discutent de façons comme “Faites-nous confiance. Ce sera un jeu d’enfant. Nous allons le faire en quelques semaines. Boom, nous allons le faire comme ça, et ça va marcher.” La réalité est que si vous dites à un directeur de la supply chain : “Je crains que pour qualifier simplement vos données, cela va prendre six mois, et désolé, vous auriez dû le faire, mais vous ne l’avez pas fait, donc nous devrons le faire pour vous”, évidemment, il est difficile de conclure ce genre d’accord. Il est donc beaucoup plus facile d’être excessivement optimiste, mais alors c’est une recette pour l’échec. Ensuite, le fournisseur doit en prendre la responsabilité car il devrait savoir mieux que ça. Peut-être que le client ne sait pas mieux car c’est la première fois qu’il essaie de faire un projet d’optimisation de la supply chain quantitative prédictive. Mais alors le fournisseur, qui par définition, ce n’est probablement pas la première fois qu’il le fait. Il devrait savoir mieux que ça. Ainsi, si la situation de diagnostic où ce genre de données est inexistant, alors ils devraient
Kieran Chandler: Ensuite, ils devraient essentiellement avertir le client qu’ils vont peut-être passer plusieurs mois à clarifier la sémantique des données afin que les données puissent être qualifiées de bonnes. Mais ce n’était pas vraiment mauvais au départ. Donc, ici, bon n’est pas l’opposé de mauvais; c’est plutôt l’opposé de données sombres, de données non qualifiées ou de données désordonnées.
Joannes Vermorel: D’accord, et pour conclure aujourd’hui, il y a toute une série de problèmes différents qui entrent en jeu dans cette catégorie de mauvaises données. Je dirais qu’il faut essayer de trouver la cause profonde du problème, et généralement, ce sont les personnes. Quand je dis que ce sont les personnes, je ne veux évidemment pas blâmer James du service informatique pour être responsable du désordre. Mais quand je dis que le problème vient des personnes, il faut comprendre exactement qui est responsable de l’échec, et peut-être que cette personne a été mise dans une situation où elle ne pouvait rien faire d’autre que d’échouer.
Vous voyez, vous pouvez en conclure que James du service informatique a échoué, mais aussi que l’organisation elle-même a mis ce pauvre James dans une situation où il n’avait pas d’autre choix que d’échouer, en toute logique. Donc, il est intéressant de commencer à voir le problème sous un angle qui vous donne au moins des indices sur la façon dont vous allez le résoudre, plutôt que de dire que les données étaient mauvaises, trop mauvaises, de mauvaises données. Et puis, si vous deviez entreprendre une autre initiative, vous répéteriez exactement le même problème, les mêmes erreurs, et vous finiriez donc par échouer de la même manière à la fin de la journée.
Kieran Chandler: D’accord, eh bien, si le patron de James regarde, j’espère qu’il est compatissant. Quoi qu’il en soit, c’est tout pour cette semaine. Merci beaucoup de nous avoir suivi, et nous vous retrouverons la prochaine fois. Au revoir pour le moment.
