Mauvaises données dans la Supply Chain

00:00:07 Bouc émissaire des mauvaises données dans les projets de la 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 posés par les mauvaises données et les idées reçues sur leur qualité.
00:03:16 Les difficultés d’accès aux données depuis les systèmes ERP et les défis avec les fournisseurs.
00:06:32 Les problèmes survenant lors de la migration entre systèmes ERP et la corruption des données.
00:08:01 Traiter les erreurs de saisie des données et leur impact sur les systèmes ERP.
00:09:48 La prévision et la 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 Les problèmes de scalabilité et l’optimisation de la récupération des données à mesure que les entreprises se développent.
00:14:45 Les défis pour créer des extractions quotidiennes propres et le potentiel d’erreurs de données.
00:16:02 L’impact des temps de traitement plus longs sur la résolution des problèmes dans les départements IT.
00:17:15 Le problème de la sémantique des données et les malentendus dans son interprétation.
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 Le rôle des praticiens de la Supply Chain et du département IT dans la compréhension de la sémantique des données.
00:23:59 La gamme de problèmes relevant du mauvais usage des données et l’identification des causes profondes.

Summary

Dans cette interview, Kieran Chandler et Joannes Vermorel abordent le rôle des données dans l’optimisation de la Supply Chain et les défis rencontrés par les fournisseurs de logiciels et les praticiens. Vermorel souligne que le problème principal n’est pas les “mauvaises données”, mais plutôt l’accès à celles-ci et leur utilisation efficace. Les défis incluent des systèmes obsolètes, une documentation inadéquate et la responsabilité de l’accès aux données. Des conflits d’intérêts avec les intégrateurs, des problèmes de migration de systèmes, la prévision et la scalabilité posent également problème. Pour optimiser la gestion de la Supply Chain, les entreprises doivent comprendre et traiter les problèmes de données, investir dans une documentation appropriée, clarifier la sémantique des données, et maintenir des attentes réalistes, plutôt que de blâmer les données.

Extended Summary

Dans cette interview, Kieran Chandler et Joannes Vermorel, le fondateur de Lokad, discutent du rôle des données dans les projets d’optimisation de la Supply Chain et des défis rencontrés par les fournisseurs de logiciels et les praticiens de la Supply Chain. Ils commencent par aborder la notion que les “mauvaises données” sont souvent utilisées comme bouc émissaire pour l’échec des projets de Supply Chain. Vermorel souligne que blâmer les données est une manière commode d’éviter de pointer du doigt les personnes qui pourraient le prendre personnellement et riposter. Cependant, il insiste également sur 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 première cause d’échec des projets d’optimisation de la Supply Chain, mais que 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. Le véritable problème, selon Vermorel, n’est pas la qualité des données en elle-même, mais plutôt les difficultés d’accès et d’utilisation de celles-ci.

Un des défis clés pour utiliser les données efficacement est d’y accéder. De nombreuses entreprises utilisent depuis des années diverses solutions logicielles telles que les systèmes enterprise resource planning (ERP), les systèmes de gestion d’entrepôt warehouse (WMS), les systèmes de gestion de transport (TMS) et d’autres. Cependant, ces systèmes peuvent s’avérer difficiles à exploiter lorsqu’il s’agit d’exporter les 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 datant de 40 ans, avec des backends 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 suffisante pour leurs systèmes, ce qui rend difficile la compréhension et la navigation à travers les nombreuses tables et champs présents dans les bases de données. 3 Responsabilité et accès : Déterminer qui est responsable de l’accès aux données peut être un défi, car cela implique plusieurs parties prenantes au sein de l’entreprise, y compris le fournisseur de logiciels, le département IT et les praticiens de la Supply Chain.

L’interview souligne l’importance de comprendre et de traiter les problèmes 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 traiter les causes profondes de ces défis est essentiel pour assurer le succès des initiatives d’optimisation de la Supply Chain.

Ils approfondissent les problèmes de données pouvant survenir lors des relations avec les fournisseurs, des intégrations de systèmes et de la scalabilité à mesure que les entreprises se développent.

Un problème majeur 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 se retrouvent prises en otage par leurs intégrateurs, rendant l’accès et l’utilisation de leurs données difficiles.

Un autre défi survient lors de la migration d’un système ERP à un autre, pouvant entraîner une mauvaise qualité des données ou une “intégration de rebut”. Bien que les entrées de données individuelles puissent être exactes, le processus de migration des données historiques entre les systèmes peut introduire des erreurs, car il n’existe souvent pas de correspondance directe entre les données de l’ancien et du nouveau système. Cela peut conduire à une corruption des données, qui pourrait ne pas avoir un impact significatif sur les opérations quotidiennes mais réapparaître comme un problème lors de projets d’optimisation de la Supply Chain ou d’analyse de données.

L’interview aborde également la prévision basée sur les données historiques, qui peut être difficile en raison de l’incertitude inhérente du futur. Identifier les problèmes dans les données historiques est plus aisé lorsque ceux-ci sont visibles, par exemple sous la forme de lacunes ou de changements brusques dans les données. Toutefois, des changements subtils dans la sémantique ou les définitions au fil du temps peuvent entraîner des problèmes plus difficiles à détecter, en particulier lors de migrations entre systèmes.

Au fur et à mesure que les entreprises se développent, la scalabilité peut également engendrer des problèmes de données. Pour les plus petites entreprises, l’ensemble des données historiques peut souvent tenir dans un smartphone, rendant l’optimisation moins préoccupante. Cependant, à mesure que les entreprises s’agrandissent, la quantité de données peut poser problème. La discussion souligne l’importance de comprendre et de traiter ces problèmes de données afin d’optimiser efficacement la gestion de la Supply Chain.

Vermorel explique que les entreprises rencontrent souvent des difficultés pour extraire les données de leurs systèmes ERP, car ces systèmes ne sont pas conçus pour fournir des incréments quotidiens de données propres. Cela entraîne des processus complexes, pouvant conduire à une extraction incorrecte des données et à l’introduction de bugs. Le débogage et la correction de ces problèmes peuvent prendre beaucoup de temps, des semaines plutôt que des heures, en raison de la quantité de données impliquées et des temps de traitement lents.

De nombreuses entreprises pensent disposer de bonnes données, mais en réalité, la sémantique des données est souvent floue. Cela peut entraîner des malentendus et des calculs trompeurs. Par exemple, une “date de commande” peut avoir plusieurs interprétations, comme le moment où le client a passé la commande, le moment où elle a été enregistrée dans le système, ou le moment où le paiement a été confirmé. Pour éviter les interprétations erronées, Vermorel suggère que les entreprises devraient disposer d’une documentation détaillée pour chaque champ et chaque 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 pas suffisamment de temps à qualifier leurs données, ce qui conduit les fournisseurs à travailler avec des informations incomplètes ou peu claires. Cela peut aboutir à un cas de “garbage in, garbage out”, où les données ne sont pas nécessairement incorrectes mais sont mal interprétées en raison d’une documentation insuffisante.

Pour résoudre ces problèmes, Vermorel insiste sur l’importance d’identifier la cause profonde du problème, qui implique généralement les personnes et les structures organisationnelles. Les entreprises devraient comprendre à qui revient la responsabilité de l’échec et s’efforcer de corriger les problèmes sous-jacents, plutôt que de simplement blâmer les données. Les fournisseurs devraient également être honnêtes sur les défis et le temps nécessaire pour clarifier la sémantique des données, au lieu d’être trop optimistes pour conclure des affaires.

Les entreprises doivent investir dans une documentation appropriée, une sémantique des données claire et des attentes réalistes pour optimiser leur Supply Chain et prévenir les échecs liés aux problèmes de données.

Full Transcript

Kieran Chandler: Aujourd’hui sur Lokad TV, nous allons comprendre pourquoi ce diagnostic est si imprécis et également examiner certains des défis liés aux données auxquels peuvent être confrontés à la fois les fournisseurs de logiciels et les praticiens de la Supply Chain. Alors Joannes, pourquoi les mauvaises données constituent-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 enlevez la responsabilité à quelque chose d’inerte, ce qui est mieux que de blâmer un collègue qui pourrait le prendre personnellement et réagir. Mais la vérité est que, lorsqu’on recherche la cause profonde, ce sont toujours les personnes qui sont responsables du problème. Blâmer les données revient à passer l’étape d’identification de la cause principale du problème.

Kieran Chandler: Il est sans aucun doute plus facile de s’en prendre à quelque chose qui ne riposte pas. Alors, comment peut-on être plus précis ? Quels sont certains des défis ?

Joannes Vermorel: Les problèmes liés aux données sont probablement la première cause d’échec des projets d’optimisation de la Supply Chain. Mais il existe quelques idées reçues. Lorsque l’on parle de “mauvaises données”, on fait référence à 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 n’entre de numéros de pièce incorrects ou ne commet de fautes de frappe. Elles utilisent des codes-barres, des lecteurs de codes-barres et d’autres astuces comme la RFID. Ainsi, la quantité de véritables mauvaises données représente généralement une très faible fraction, et cela n’explique pas à lui seul pourquoi la plupart des initiatives échouant à cause de problèmes liés aux données échouent réellement.

Kieran Chandler: Si la grande majorité des entreprises occidentales recueillent de bonnes données, quels sont les 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 l’accès aux données. Vous seriez surpris. Les entreprises utilisent depuis des décennies diverses variantes d’ERP, WMS, TMS ou d’autres logiciels d’entreprise pour gérer leurs activités au quotidien. Mais la plupart de ces systèmes ne sont pas très conviviaux pour l’exportation des données. Dans certains cas, vous disposez de systèmes si anciens que vous n’avez même pas une base de données relationnelle SQL adéquate soutenant le système. Dans ce genre de situation, il est vraiment difficile d’extraire les données parce que le backend est généralement complètement obsolète et propriétaire.

Kieran Chandler: Alors, qui est chargé de faire cela ?

Joannes Vermorel: Il y a plusieurs responsabilités ici. D’abord, il y a 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 constatez que votre ERP contient 2 000 tables, chacune avec 20 à 200 champs, ce qui est cauchemardesque. C’est complètement énorme, et vous ne savez pas par où commencer. Même si l’endroit où chercher peut poser problème avec le fournisseur, vous pouvez également avoir un problème avec l’intégrateur. Le problème avec l’intégrateur est que celui-ci peut 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 pour un autre, ou quelque chose du genre. Et lorsque vous leur demandez essentiellement de réaliser 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 – cela arrive, nous l’avons souvent vu – être tout simplement non coopératif. Car, encore une fois, pour eux, c’est dans leur intérêt stratégique d’être non compétitifs. Et ici, vous vous retrouvez dans une situation d’otage où l’entreprise est, en quelque sorte, prise en otage par l’intégrateur. L’entreprise, l’entreprise IT responsable de la configuration, parfois de l’hébergement, et, globalement, 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, définitivement. Ne pas être capable d’accéder à vos données semble être un obstacle considérable. Et qu’en est-il d’autres défis qui peuvent survenir ? Un gros casse-tête que rencontrent bon nombre de nos clients est la migration d’un système ERP à un autre. Qu’est-ce que cela peut faire aux données ?

Joannes Vermorel: Cela ne peut pas être clos, cela cause des problèmes. C’est le genre de situation où vous pouvez avoir un autre type de données erronées. Mais ici, ce qui est vraiment problématique, c’est l’intégration bâclée. Je dis donc que, généralement, les entrées de données sont correctes, mais quand vous passez d’un ERP à un autre – que ce soit le fournisseur, l’intégrateur ou même votre service informatique interne – ce qu’ils vont essayer de faire, c’est essentiellement migrer les données historiques de l’ancien système vers le nouveau. Le problème est que vous n’avez pas d’appariement un-à-un entre, vous voyez, ce qui était, par exemple, des ventes enregistrées dans l’ancien système et ce qui est des ventes enregistrées dans le nouveau système. Peut-être que les choses sont simplement organisées différemment, et il n’existe donc aucun moyen clair de reporter les AR de l’ancien système vers le nouveau. Puis, vous vous retrouvez avec des intégrations provisoires qui peuvent conduire à la corruption des données, parce que si, je dirais, vous faites une réintégration incorrecte de votre historique, cela n’empêchera pas votre entreprise de fonctionner au quotidien. Vous voyez, si le East Oracle est mal importé dans le nouveau système, pour la majorité des opérations quotidiennes, cela n’aura aucun impact. Et même si cela en a un, généralement quelqu’un fera une correction rapide pour rectifier l’inexactitude et continuera. Cela peut donc devenir une source de friction continue, mais cela disparaît rapidement car, par exemple, si vous avez des codes fournisseurs qui ont été importés de manière incorrecte – et il y a de fortes chances que vous n’ayez pas un million de fournisseurs – vos fournisseurs les plus fréquents, disons vos 100 principaux, seront probablement corrigés quant aux erreurs d’entrées de données dans les deux semaines suivant le démarrage du nouveau système. Et peut-être, trois mois plus tard, aurez-vous pratiquement corrigé chaque entrée fournisseur erronée. Mais le problème avec l’historique, c’est que les gens ne vont pas revenir corriger les données historiques. Supposons donc que vous avez cinq ans d’historique, peut-être trois

Kieran Chandler: À l’avenir, à quel point 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’ils sont évidents, comme l’absence de données pendant quelques mois. Cependant, il peut y avoir des changements subtils qui sont plus difficiles à détecter, comme des différences dans la manière dont les ventes sont comptabilisées, ou si la fraude ou les retours sont inclus. Cela peut entraîner de nombreux problèmes difficiles à identifier dans les données historiques, parce que la définition même des données observées a changé au fil du temps, et ce n’est pas évident à moins qu’un pic ou un rebond notable ne se produise.

Kieran Chandler: Un autre problème fréquent chez les clients à qui nous parlons est l’évolutivité. À mesure qu’une entreprise grandit, leurs données commencent à devenir plus désordonnées. Quels sont les problèmes que l’évolutivité peut engendrer ?

Joannes Vermorel: Quand il n’y a pas de problème d’évolutivité, vous pouvez simplement copier toutes les données de l’entreprise chaque jour. Pour les petites entreprises, cela peut être gérable puisque leur historique complet pourrait être inférieur à 10 gigaoctets. Cependant, à mesure que vous passez à de plus grandes entreprises, vous vous retrouvez avec bien plus de données, et vous devez opter pour une extraction incrémentale. Cela signifie extraire une portion 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 mettre en place des procédures complexes pour établir une extraction quotidienne propre, et ce faisant, vous vous exposez à des problèmes potentiels.

Kieran Chandler: Au final, vous vous retrouvez avec des données erronées simplement parce que vous voulez réaliser une extraction de données de manière incrémentale, et c’est délicat parce que le système n’a peut-être pas été conçu pour cette tâche. Quand on parle de débogage, on veut juste 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 certain que ça fonctionne. Cependant, si le processus prend six heures à se compléter, cela devient un processus bien plus fastidieux. Pouvez-vous expliquer les défis dans cette situation ?

Joannes Vermorel: Bien. Imaginez que vous disposez d’un système où le processus prend six heures à se compléter. Dans votre service informatique, quelqu’un va lancer le processus, attendre 10 minutes, se rendre compte que ça prend trop de temps et passer à autre chose. Il se peut même qu’il l’oublie. Le lendemain, il remarquera peut-être un petit bug qui a provoqué un crash après six heures. Pour reproduire le problème, il faudra attendre six heures supplémentaires. En conséquence, vous vous retrouvez avec des problèmes qui devraient être réparables en quelques heures, mais à cause de la complexité accrue et des temps de traitement plus longs, cela se transforme en un processus vraiment fastidieux où les délais totaux se transforment en semaines. Pas parce qu’il y a 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 disposer de très bonnes données, alors qu’en réalité, lorsqu’on regarde de plus près, ce n’est pas génial ?

Joannes Vermorel: Oui, il y a un autre problème que nous n’avons pas abordé, à savoir la sémantique elle-même. De nombreuses entreprises pensent disposer 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, lorsqu’il s’agit d’une date de commande, il existe de nombreuses interprétations possibles. Cela peut être la date de commande du client, le moment où la commande a été passée sur le site web, son enregistrement dans le système, ou même le moment où le paiement a été confirmé comme valide. Il pourrait y avoir une vingtaine d’interprétations différentes de ce que signifie cette date de commande.

Lorsque nous commençons à travailler avec des clients, nous rencontrons généralement des tableaux et des colonnes avec peu de documentation. Mais une fois la préparation des données terminée, nous avons près d’une page de documentation par champ et par tableau. Une situation typique de supply chain comporte environ 20 tableaux avec 20 champs, ce qui représente environ 400 pages de documentation rien que 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 bien comprendre les données.

Kieran Chandler: Joannes, pouvez-vous parler de l’importance de bien comprendre les données dans l’optimization de la supply chain ?

Joannes Vermorel: Oui, c’est simplement 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 le principe du garbage in, garbage out. Ce n’est pas que les données sont pourries, dans le sens où les chiffres sont faux, mais vous ne savez pas ce que signifient les données. Donc, si vous avez une date que vous ne comprenez pas correctement, quel que soit le calcul ou la modernisation que vous effectuez, cela aboutira à quelque chose d’inducteur d’erreurs. Ainsi, la sémantique des données est la clé, et la documentation doit être en place avant même de pouvoir démarrer un projet.

Kieran Chandler: Alors, qui est responsable quand il s’agit de la sémantique ?

Joannes Vermorel: Je dirais que ce sont les praticiens de la supply chain qui devraient être aux commandes. La plupart d’entre eux diraient que c’est un problème informatique. Mais la manière dont vous appréhendez la sémantique des données dépend vraiment du processus que vous suivez. Si vous avez un processus où vous scannez les produits à l’entrée de l’entrepôt – et dans ce cas, le service informatique ne fait qu’extraire des données – 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 le savent vraiment sont celles qui, en premier lieu, se trouvent sur le terrain, car ces données ne sont que le résultat d’un processus qui se déroule. Mon point est donc de ne pas attendre du service informatique, qui se contente de gérer les machines et de veiller à ce que le logiciel dispose de suffisamment de bande passante mémoire et de disque, qu’il ait les connaissances, les compétences et la compréhension nécessaires pour saisir ce que signifient vraiment les données. Ce que signifient les données est typiquement un problème très spécifique au métier. Ce n’est absolument pas un problème informatique. Ainsi, la responsabilité incombe souvent aussi aux praticiens eux-mêmes. Ceux-ci n’ont pas consacré assez de temps à qualifier correctement les données avec leurs propres mots et leur propre compréhension. Par conséquent, lorsqu’il s’agit de cette optimization de la supply chain, vous vous retrouvez avec un fournisseur qui traite ces données de manière à moitié aveugle, ce qui aboutit au fameux garbage in, garbage out.

Kieran Chandler: Alors, le fournisseur peut-il également être fautif ?

Joannes Vermorel: Oui, évidemment, le fournisseur peut également être fautif. Des entreprises comme Coke Ad, qui réalisent l’optimization de la supply chain, et généralement, quand c’est le fournisseur qui est en tort, c’est parce qu’il cherche à se montrer élégant. Habituellement, il essaie de minimiser la difficulté parce qu’il tente de vendre un problème. On entend des propositions du genre « Faites-nous confiance. Ce sera du gâteau. Nous allons le faire en quelques semaines. Boom, nous allons le faire de cette manière, et ça fonctionnera. » La réalité est que si vous dites à un directeur de la supply chain « J’ai peur que le simple fait de qualifier vos données prenne six mois, et désolé, vous auriez dû le faire, mais vous ne l’avez pas fait, donc nous devrons le faire pour vous », il est évidemment difficile de conclure ce genre d’accord. Il est donc beaucoup plus facile d’être excessivement optimiste, mais cela constitue une recette pour l’échec. Ensuite, le fournisseur doit assumer la responsabilité, car il devrait mieux savoir. Peut-être que le client ne sait pas mieux parce que c’est la première fois qu’il tente un projet d’optimization de la supply chain quantitative prédictive. Mais le fournisseur, qui par définition, ne fait probablement pas cela pour la première fois, devrait mieux savoir. Ainsi, si le diagnostic montre que ce type de données est inexistant, alors ils devraient

Kieran Chandler: Alors, ils devraient en gros avertir le client qu’il pourrait y avoir, peut-être, plusieurs mois d’effort rien que pour clarifier la sémantique des données, afin que celles-ci puissent être qualifiées de bonnes. Mais ce n’était pas que c’était vraiment mauvais au départ. Ainsi, « bon » n’est pas l’opposé de « mauvais » dans cette situation ; c’est juste que « bon » correspond davantage à l’opposé des dark data ou des données non qualifiées ou désordonnées.

Joannes Vermorel: D’accord, et pour conclure aujourd’hui, il existe une multitude de problèmes qui relèvent en réalité de ce que l’on peut appeler de mauvaises données. Je dirais qu’il faut s’assurer d’identifier la cause profonde du problème, et généralement, c’est à cause des personnes. Je veux dire, évidemment, quand je dis que c’est à cause des personnes, on ne veut pas accabler James du service informatique pour le désordre. Mais quand je dis que le problème vient des personnes, il faut comprendre précisément qui porte la responsabilité de l’échec, et peut-être que cette personne s’est retrouvée dans une situation où elle n’avait d’autre choix que d’échouer.

Vous voyez, on peut conclure que James du service informatique a échoué, mais aussi que l’organisation elle-même a placé ce pauvre James dans une situation où il n’avait pas d’autre option que d’échouer, en réalité. Il est donc intéressant de voir le problème sous un angle qui, au moins, offre des indices sur la manière de le résoudre, plutôt que de simplement dire que les données étaient mauvaises, trop mauvaises, de mauvaises données. Et ensuite, si vous deviez lancer une nouvelle initiative, vous répéteriez exactement le même problème, les mêmes erreurs, et finiriez par aboutir au même échec à la fin de la journée.

Kieran Chandler: D’accord, eh bien, si le patron de James regarde, j’espère qu’il est compréhensif. Quoi qu’il en soit, c’est tout pour cette semaine. Merci beaucoup de nous avoir suivis, et nous nous retrouverons la prochaine fois. Au revoir pour l’instant.