Les chiffres sont corrects sur papier. Il y a un tableau bien présenté, avec un total par composante et une somme au niveau du groupe. Mais quiconque approfondit — d'où vient ce chiffre, qui l'a fourni, quelle définition a été utilisée — obtient trois réponses différentes de trois personnes différentes. Un site compte le scope 2 différemment d'un autre. Le tableur utilisé l'année dernière est introuvable. Personne ne sait avec certitude si ce chiffre a été construit comme le partenaire d'assurance voudra le voir plus tard. Ce n'est pas une erreur de calcul, c'est une fondation qui n'a jamais été posée.
Le cœur est le Data Readiness Scan avec un registre de points de données comme colonne vertébrale. Ce registre met côte à côte ce qui est nécessaire pour les sujets choisis et ce qui est déjà présent dans l'organisation — pas une estimation, mais une liste qui découle des sujets matériels désignés.
Autour de ce registre se trouve le source-to-report-mapper : un outil de lineage à remplir selon une structure fixe input-processus-output. Pour chaque point de données, on consigne d'où il vient, quels traitements il subit avant d'atterrir dans le rapport, et qui est responsable de quoi via une matrice RACI. S'y ajoutent des règles de qualité — valeurs valides, écarts signalants — qui rendent visible quand un chiffre sort de la ligne avant de disparaître dans la consolidation.
De ce processus conçu découle un générateur d'exigences fonctionnelles. C'est l'inversion qui manque souvent dans le processus : ne pas d'abord acheter un outil et plier le processus en fonction de celui-ci, mais d'abord consigner le processus et ensuite seulement regarder quelles exigences en découlent pour un éventuel logiciel.
Qui préfère travailler avec un accompagnement peut suivre le bootcamp de données de trois jours — généralement autour du CO2 comme premier sujet. C'est un produit route 2/3 du partenaire. Le modèle de conception sous-jacent se trouve aussi dans l'outil, afin que celui qui préfère piloter lui-même puisse parcourir le même schéma de manière autonome.
Tout ce que le registre et le mapper produisent peut être retracé jusqu'à ce qui a été renseigné : quelle source, quel traitement, quel responsable, quelle règle. Rien n'est estimé en plus et rien n'est arrondi en un chiffre de performance. Ce qui en sort est une structure — pas un jugement sur la qualité bonne ou mauvaise des données, mais une indication précise de l'endroit où les fondations manquent et de l'endroit où elles sont déjà posées. La manière exacte dont ces étapes s'articulent, du choix des sujets à la nouvelle mesure, est détaillée sur Comment ça marche ; ce qui est concrètement sur la table après chaque étape se trouve sur Résultats.
Choisir les sujets. Les sujets matériels sont sélectionnés, au besoin comme point de départ à partir d'esgia.
Construire le registre. Le générateur de registre aligne les points de données correspondant à ces sujets.
Renseigner le lineage et la RACI. Pour chaque point de données, on consigne la source, les traitements, les responsabilités et les règles de qualité.
Rapport de readiness et nouvelle mesure. Il en résulte une indication de l'ordre et du délai par sujet, et l'ensemble est destiné à être mesuré à nouveau périodiquement — la qualité des données n'est pas un instantané.
Ce n'est pas un outil de reporting. Le rapport lui-même, sous VSME ou CSRD, reste le domaine d'esgia ; ici, on ne fait pas de reporting, on en pose la fondation.
Ce n'est pas un outil de questionnaire. Qui doit répondre à un questionnaire d'un client ou d'un partenaire de la chaîne s'adresse à supplia ou esgreply.
Ce n'est pas un bilan éprouvé. Il n'y a pas de projets réalisés à citer en référence — cela correspond à un outil encore en phase de liste d'attente. L'outil structure le processus et rend visible où se trouvent les fils qui pendent ; il ne prouve rien sur le résultat et ne garantit rien vis-à-vis de l'assurance.
Voie 1 — faire soi-même. Le modèle de bootcamp par sujet, un export du registre et une checklist de contrôles en préparation de l'assurance, tout cela à parcourir soi-même.
Voie 2 — partiellement accompagné. Le partenaire mène les bootcamps ; l'outil reste l'endroit où le registre et le lineage sont consignés.
Voie 3 — externaliser. Mise en place complète par le partenaire, sur la propre machine de FTE TO AI.
Qui souhaite plus d'exemples de ce à quoi ressemble un registre ou une carte de lineage en pratique trouvera du contexte dans la base de connaissances.
Un registre et une carte de lineage ne changent quelque chose qu'à partir du moment où ils atterrissent dans qui fait quelle tâche, combien de temps cela prend et dans quel système cela se déroule. C'est précisément là que commence le scan de travail de FTE TO AI : pas au niveau des données, mais au niveau du travail nécessaire pour rendre ces données correctes.
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.