Il y a généralement une seule personne qui sait d'où vient le chiffre de CO2. Quel tableur, quel onglet, quelle hypothèse sur le facteur de conversion de l'année dernière. Cette personne ne l'a jamais écrit, car cela se trouvait dans sa tête et cela fonctionnait. Jusqu'à ce qu'elle parte en vacances, change de fonction, ou quitte l'organisation. On découvre alors que le registre de points de données qui existait bel et bien n'était lisible que par son créateur.
Ce n'est pas un accident. C'est la conséquence d'un registre construit comme un aide-mémoire plutôt que comme un document. Une cellule avec un chiffre, une colonne avec une référence de source qui ne signifie quelque chose que pour celui qui connaît déjà le contexte. Pour le créateur, cela suffit. Pour un successeur, un auditeur, ou le directeur financier qui doit défendre le chiffre devant le conseil de surveillance, c'est une énigme.
Le droit de propriété d'un point de données est souvent confondu avec la responsabilité de fournir un chiffre. Ce n'est pas la même chose. Le droit de propriété signifie qu'il existe quelqu'un capable d'expliquer d'où vient le chiffre, quels choix il comporte, et ce qui change si la source change. C'est un rôle différent de celui de simplement remplir. C'est le rôle de quelqu'un qui peut répondre à la question sans devoir retourner à un e-mail vieux de deux ans.
Dans la pratique, ce rôle n'est souvent pas attribué, ou attribué à quelqu'un qui occupe désormais une autre fonction. Le registre mentionne un nom qui n'est plus exact, ou aucun nom. Celui qui pose alors une question sur un point de données ne reçoit pas de réponse mais doit se lancer dans une recherche. C'est à ce moment-là que l'on découvre si le droit de propriété a jamais été réellement établi, ou seulement supposé.
Un registre de points de données qu'une autre personne peut reprendre établit trois éléments qui vont au-delà du chiffre lui-même. Premièrement, la source : le système, le tableur, ou le collègue qui fournit le chiffre, et non pas comme une note isolée mais comme partie intégrante de l'enregistrement lui-même. Deuxièmement, la ligne allant de la source au rapport : quelles transformations le chiffre a subies avant d'apparaître dans le rapport, de sorte qu'un contrôleur n'ait pas à deviner pourquoi le chiffre dans le rapport diffère de celui dans le système source. Troisièmement, le propriétaire : pas un nom qui a été renseigné un jour, mais quelqu'un qui peut actuellement être contacté avec une question sur ce point de données spécifique.
Ce n'est pas compliqué à décrire, mais c'est un travail de le consigner. Pour chaque point de données séparément, et non comme un exercice ponctuel mais comme quelque chose qui est mis à jour lorsque les sources ou les propriétaires changent. La question de savoir où un point de données existe déjà doit précéder cette étape : un registre n'a de valeur que s'il renvoie à une source qui existe réellement, et non à une hypothèse sur l'origine supposée du chiffre.
Un registre lisible permet la transmission. Il ne rend pas les chiffres automatiquement exacts. Si la source sous-jacente elle-même est peu fiable — un compteur qui affiche une valeur erronée depuis des années, un tableur avec une erreur de formule que personne n'a remarquée — le registre ne fait que consigner cette erreur avec plus de précision. C'est une autre question, à laquelle on répond plutôt en examinant combien de vos points de données ont une source démontrable et vérifiable.
Le registre ne résout pas non plus quel point de données est réellement nécessaire. Certaines organisations consignent des dizaines de points de données pour un sujet pour lequel une poignée suffirait, et consacrent ensuite de l'entretien à des informations que personne ne consulte. Cet arbitrage relève de la question de savoir quels points de données vous sont réellement nécessaires, et précède la question de qui doit pouvoir lire le registre. Un registre complet pour le mauvais sujet reste le mauvais registre.
Et le registre ne résout pas combien de temps il faut pour mettre un sujet en ordre. Cela dépend du nombre de sources existantes, de leur dispersion, et du nombre d'entre elles qui ont déjà un propriétaire joignable. Celui qui souhaite s'en faire une idée trouvera dans combien de temps il faut pour mettre un sujet en ordre une description de ce qui déterminera cette durée, et non un chiffre identique pour chaque organisation.
Construire un registre de points de données prend du temps, et ce temps est rarement libéré d'un coup pour tous les sujets à la fois. La plupart des organisations commencent par le sujet où les données sont déjà les plus dispersées et où la pression de pouvoir fournir des explications est la plus forte. Les raisons pour lesquelles c'est souvent le CO2 sont décrites sur la page consacrée à pourquoi le CO2 est généralement le premier sujet. Celui qui commence par là s'exerce à la méthode de consignation sur un sujet qui s'y prête bien, avant d'appliquer cette méthode au reste.
Le Data Readiness Scan qui établit cela — registre de points de données, provenance par point de données, droit de propriété et règles de qualité — est encore en développement. Il n'existe pour l'instant aucun outil que vous puissiez acquérir ; celui qui y voit un intérêt peut s'inscrire sur la liste d'attente et sera informé dès que le scan sera disponible.
Une partie du travail qui repose actuellement sur cette unique personne indispensable — rechercher les sources, reconstituer les lignes vers le rapport, retrouver les propriétaires — est répétitive et donc adaptée à un soutien par l'IA. Quelle est exactement cette partie diffère selon la tâche et selon l'organisation. FTE TO AI calcule cela par tâche à l'aide d'un scan de travail, qui montre quelle part du travail peut être reprise par l'IA et quelle part reste dépendante de quelqu'un qui connaît le contexte.
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.