Demandez à cinq entités la même grandeur — par exemple le nombre d'ETP, la consommation de carburant d'un parc de véhicules, ou le matériel amorti — et vous obtiendrez cinq raisonnements qui divergent légèrement. Un établissement comptabilise les intérimaires, un autre non. Une usine calcule en litres, une autre a déjà converti cela en litres par véhicule par an et fournit donc un autre type de chiffre que celui demandé. Sur papier, cela s'appelle tout la même métrique. En réalité, il s'agit de définitions différentes qui se trouvent par hasard dans la même colonne.
Ce n'est pas une erreur de saisie. Personne n'a mal tapé quoi que ce soit. Le problème se situe une étape plus tôt : on n'a jamais établi précisément quelle est la valeur valide pour ce point de donnée, et chaque entité comble donc ce vide avec sa propre logique. Ce qui constitue une valeur valide et ce qui n'en constitue pas une est détaillé sur qu'est-ce qu'une valeur valide — la question qui doit précéder toute comparaison entre entités.
La question centrale n'est pas de savoir si des écarts se produisent — ils se produisent toujours — mais qui les voit avant que le chiffre ne figure dans un rapport. Dans de nombreuses organisations, la réponse est : personne, jusqu'à ce qu'une partie externe ou un auditeur remarque un chiffre qui ne correspond pas à celui de l'année précédente. À ce moment-là, la question est posée trop tard.
Un point de donnée sans écart de signal n'a aucun moyen de se rendre suspect lui-même. Un chiffre trois fois plus élevé que l'année précédente ne se distingue pas automatiquement s'il n'existe pas de fourchette définie dans laquelle une valeur est jugée plausible. La manière de déterminer cette fourchette — pourcentage fixe, dispersion historique, seuil par unité — est détaillée sur comment définir un écart de signal. La question n'est pas compliquée, mais elle doit être posée, pour chaque point de donnée, avant que celui-ci ne soit renseigné.
Un écart de signal capte le cas extrême : le chiffre manifestement erroné. Mais la plupart des différences de définition entre entités sont plus subtiles que cela. Un établissement qui comptabilise les intérimaires ne produit pas un chiffre absurde — il produit un chiffre qui paraît tout à fait normal, et qui, précisément pour cette raison, ne se remarque pas.
C'est pourquoi chaque point de donnée doit être associé à plus d'un contrôle : une plage dans laquelle la valeur doit s'inscrire, une unité fixée, une exigence de source indiquant quel type de document fait foi, et une description de ce qui doit ou non entrer dans le comptage. La combinaison de contrôles nécessaire varie selon le point de donnée et l'organisation — une dépense de R&D exige d'autres garanties qu'un facteur d'émission. Un aperçu des contrôles associés à chaque type de point de donnée figure sur quels contrôles s'appliquent à un point de donnée. Sans cette combinaison, une fausse précision apparaît : un chiffre avec deux décimales, construit à partir de cinq définitions qui ne coïncident pas entre elles. L'origine de cette fausse précision et la manière de la repérer sont détaillées sur comment éviter la fausse précision.
Une définition fixée sur papier n'est pas automatiquement une définition appliquée. Quelqu'un doit répondre à la question lorsqu'une entité soumet un cas limite : cette forme de collaboration compte-t-elle comme ETP ou non, ce fournisseur relève-t-il du scope 3 ou non. Sans propriétaire désigné, cette question retombe sur celui qui se trouve, par hasard, le plus proche du formulaire, et la définition se déplace alors à nouveau, silencieusement, d'une entité à l'autre.
Le Data Readiness Scan fixe, pour chaque point de donnée, quelle est la valeur valide, quel écart de signal s'applique, quels contrôles concernent ce point de donnée spécifique, et qui est propriétaire de la définition. Ce n'est pas un outil de reporting ni un questionnaire — c'est le registre qui consigne ce qui se trouve sous le rapport, afin qu'une différence entre entités devienne visible avant que le chiffre ne soit additionné.
Il existe des systèmes capables d'effectuer ces contrôles. Mais un système qui fonctionne au-dessus de cinq définitions différentes, jamais fixées, exécute ces contrôles sur la base de règles que personne n'a convenues. Le résultat est une interface soignée contenant des chiffres peu fiables. Pourquoi l'ordre des opérations — d'abord la définition, puis l'outil — importe, est expliqué sur faut-il d'abord acheter un outil ou d'abord organiser le processus. Et les exigences qu'un outil doit réellement satisfaire ne découlent pas d'une liste de fournisseurs, mais de votre propre processus — voir quelles exigences fonctionnelles découlent de votre propre processus.
Le Data Readiness Scan est en cours de développement. Ceux qui sont déjà confrontés à des définitions qui varient selon l'entité peuvent s'inscrire sur la liste d'attente et seront informés dès que l'instrument sera disponible.
Une fois établi ce qu'est une valeur valide, qui veille sur la définition et quel contrôle correspond à quel point de donnée, on voit aussi clairement quelle part de ce travail relève de la répétition : vérifier les mêmes documents sources selon la même règle, tester la même fourchette à chaque nouvelle saisie. C'est un travail qui, une fois rendu explicite, se laisse chiffrer. Le werkscan de FTE TO AI calcule, pour chaque tâche, quelle part du travail peut être reprise par l'IA — non pas pour remplacer le propriétaire qui décide de la définition, mais comme moyen de distinguer le contrôle de la répétition.
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.