Une usine pèse le poids des déchets sur le pont-bascule. Une autre usine l'estime sur la base du volume des conteneurs. Les deux fournissent un chiffre pour la même ligne du rapport. Personne n'a menti, personne n'a commis d'erreur. Simplement, la définition exacte de ce point de données n'a jamais été consignée, et chaque entité a donc choisi l'interprétation la plus logique dont elle disposait.
Ce n'est pas une exception. C'est l'état normal d'une organisation où la même métrique est fournie par différentes équipes, avec des systèmes sources différents et un historique différent. La question n'est pas de savoir comment vous supprimez cette différence avant qu'elle n'apparaisse. La question est de savoir ce que vous en faites dès que vous la constatez.
L'étape le plus souvent négligée est que la définition elle-même soit consignée quelque part. Pas dans la tête du contrôleur qui procède ainsi depuis des années, mais dans un registre : ce point de données signifie ceci, se mesure ainsi, et ces unités comptent ou ne comptent pas. Ce qui constitue une valeur valide dans ce cadre, et qui le remarque lorsqu'une donnée fournie s'en écarte, est décrit sur la page consacrée à ce qu'est une valeur valide et qui le remarque quand ce n'est pas le cas. Sans cette consignation, toute addition entre entités est une addition d'éléments qui ne sont pas tout à fait identiques, emballés dans un seul chiffre qui, lui, paraît parfaitement univoque.
Cette consignation est précisément le travail du Data Readiness Scan : non pas réécrire le rapport, mais construire le registre des points de données dans lequel figure, pour chacun, ce qu'il est, d'où il provient et qui en est responsable. Ce registre est l'endroit où la différence entre les entités devient visible, plutôt que de ne le devenir qu'après l'addition du chiffre.
Une fois que vous constatez que l'entité A et l'entité B entendent quelque chose de différent par le même point de données, il existe globalement trois voies.
La première est l'harmonisation : imposer une seule définition pour toute l'organisation, avec toutes les adaptations de systèmes que cela implique. C'est souvent la bonne voie à long terme, mais ce n'est pas quelque chose qui se règle du jour au lendemain.
La deuxième est la documentation et la correction : laisser l'écart là où il se trouve, mais consigner son ampleur et, grâce à une conversion fixe, veiller à ce que le total soit néanmoins correct. Cela fonctionne lorsque l'écart est stable et connu — par exemple lorsqu'un site utilise structurellement une autre méthode de mesure qui peut être retracée.
La troisième est la signalisation : ne pas corriger, mais placer un signal dès qu'une donnée fournie s'écarte du schéma habituel de cette entité. La manière de paramétrer un tel écart de signalisation et qui en reçoit une notification est détaillée sur la page consacrée à comment paramétrer un écart de signalisation et qui le remarque lorsque cela se produit. Cette voie n'a pas pour objectif de résoudre le problème, mais d'éviter qu'il ne passe inaperçu pendant que vous travaillez à une solution structurelle.
La voie appropriée dépend du nombre d'entités concernées par l'écart, de la stabilité de cet écart et du temps disponible avant que le chiffre n'entre dans une période de reporting. C'est un arbitrage qui varie selon l'organisation et que ce registre ne fait pas à votre place — il rend toutefois visible le fait que cet arbitrage doit être fait.
La différence de définition est l'une des erreurs les plus silencieuses qui existent, car chaque entité a raison, prise isolément. Le site qui estime sur la base du volume des conteneurs ne fait rien de mal dans son propre processus. Le problème n'apparaît qu'au niveau où les chiffres se rejoignent, et c'est précisément à ce niveau que, souvent, personne n'est désigné pour vérifier si les définitions sous-jacentes sont même comparables.
C'est la raison pour laquelle la responsabilité par point de données est tout aussi importante que la définition elle-même. Les contrôles qui accompagnent un point de données et qui remarque lorsqu'un de ces contrôles est omis sont décrits sur la page consacrée à quels contrôles accompagnent un point de données et qui le remarque lorsqu'il en manque un. Sans propriétaire désigné, la question « mais qui voit vraiment cela » reste sans réponse, même si la définition est consignée sur papier.
Il est tentant de vouloir résoudre ce problème avec un système qui normalise automatiquement les données fournies. Mais un outil placé au-dessus d'un ensemble de points de données non définis ne normalise rien — il emballe les mêmes différences dans une interface plus soignée. L'ordre qui tient est de consigner d'abord la définition et la responsabilité, et de ne regarder qu'ensuite quel système convient. Les raisons pour lesquelles cet ordre n'est pas fortuit sont détaillées sur la page consacrée à faut-il d'abord acheter un outil ou d'abord organiser le processus.
Dès que, pour chaque point de données, la définition, le responsable et les écarts signalés sont établis, une autre question se pose : qui effectuera ensuite le travail lié à ces contrôles — le recalcul, la vérification auprès de l'entité qui présente un écart, la tenue du registre lui-même. Une partie de ce travail est suffisamment répétitive pour être confiée à une étape automatique, une autre partie exige un jugement qui reste du ressort d'une personne. Le scan de travail de FTE TO AI calcule, par tâche, quelle part peut être reprise par l'IA, sur la base du même type de précision que ce registre : non pas la question de savoir si l'automatisation est possible, mais quelle part de quelle tâche en relève.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.