Dans un groupe avec plusieurs entités, les données de durabilité sont généralement collectées par site, par pays ou par division. Quelqu'un sur le site remplit un tableau, l'envoie au siège, et là tout est regroupé en un rapport. Ce processus fonctionne, jusqu'à ce que quelque chose se passe mal. On découvre alors que personne ne sait précisément qui était responsable de l'étape intermédiaire : la conversion des relevés de compteurs bruts en facteur d'émission, le choix de l'exercice comptable auquel appartient un chiffre, la correction d'un double comptage entre deux entités.
La question « qui possède ce processus » est différente de la question « qui fournit ce chiffre ». La fourniture est visible : quelqu'un envoie un fichier. La propriété du processus est invisible, jusqu'à ce qu'elle manque. Qui décide quelle définition est valable lorsque deux entités suivent une approche différente ? Qui signale qu'une valeur se situe hors de la plage attendue avant qu'elle n'atteigne le rapport ? Qui peut être interpellé lorsqu'un auditeur demande comment un chiffre a été construit ?
Avec une seule entité, il y a généralement une personne qui a une vue d'ensemble, même si cette vue est informelle. Avec plusieurs entités, cette couverture informelle disparaît. Chaque site a sa propre façon de travailler, ses propres systèmes, ses propres personnes qui ont toujours fait ainsi. Le siège voit le résultat final, pas le processus qui le précède. Sans attribution explicite de la propriété, il se crée un groupe où chacun pense qu'un autre surveille le pont entre les données brutes et le chiffre rapporté.
Cela se joue à plusieurs niveaux simultanément. Il y a la question qui possède la définition d'un point de données : quelle entité déterminer ce que signifie exactement « consommation de scope 2 » lorsque le fournisseur d'énergie diffère selon le pays. Il y a la question qui possède le contrôle : qui vérifie qu'une valeur a été approuvée avant qu'elle ne continue son chemin. Et il y a la question sous-jacente que cet article traite : qui possède le processus lui-même, du système source à la ligne du rapport.
Sans propriétaire, le processus devient un ensemble d'habitudes. Quelqu'un ajuste une formule dans un tableau parce que cela semblait plus pratique, et personne ne vérifie si cet ajustement a été répercuté ailleurs. Un site change de système comptable et le nouvel export a un ordre de colonnes différent, ce que personne ne remarque jusqu'à ce que les chiffres ne s'additionnent plus. Un nouveau collaborateur prend en charge le reporting et suit les instructions d'un prédécesseur qui a depuis quitté l'entreprise, sans savoir pourquoi une étape donnée est organisée ainsi.
Les conséquences ne deviennent généralement visibles qu'au moment où un regard externe est porté sur le sujet : lors d'un audit, lors d'une question d'un régulateur, lors de la première fois qu'un chiffre doit être justifié. On découvre alors que personne ne peut reconstituer comment un chiffre est né, parce que personne n'avait formellement cette responsabilité. C'est précisément le sujet de ce que vous faites quand personne n'est propriétaire dans un groupe avec plusieurs entités : non pas une question de faute, mais un vide structurel né de la croissance, de fusions ou simplement du temps.
Il est tentant de résoudre ce problème avec un organigramme : un nom face à un service. Cela ne fonctionne pas, car le processus sous les données de durabilité ne se compose pas d'une seule étape. Il y a l'enregistrement de la source, la conversion en une unité ou un facteur, le contrôle des valeurs valides, l'agrégation entre les entités, et l'inscription finale dans le rapport. Chaque étape peut avoir un propriétaire différent, à condition que cela soit explicitement consigné et non simplement supposé.
Ce qui aide en la matière, ce n'est pas une répartition vague des tâches mais un registre concret : par point de données, la question de savoir qui gère la source, qui effectue la conversion, qui approuve le résultat. S'y ajoute la question de ce qu'est une valeur valide, car sans une définition partagée de ce qu'est une valeur valide, aucun propriétaire ne peut vérifier si un chiffre est correct avant qu'il ne continue son chemin. Et sans un moyen de signaler les chiffres divergents, comme décrit dans la mise en place d'un écart de signal, le contrôle reste dépendant de la personne qui, par hasard, relit encore le chiffre.
Une fois la propriété du processus attribuée, par point de données et par étape, un autre type d'aperçu se dégage : qui exécute précisément quelle action, à quelle fréquence, et sur la base de quelle source. Cette vue d'ensemble rend possible une question suivante qui va plus loin que celle de savoir qui est responsable, à savoir quelle partie de ce travail peut ensuite être reprise par l'automatisation. Le scan de travail de FTE TO AI calcule, par tâche, quelle partie du travail peut être reprise par l'IA, en partant des tâches telles qu'elles sont devenues visibles après l'attribution de la propriété. Sans cette attribution, il n'y a pas de tâche à scanner, seulement un processus que personne ne peut expliquer.
Le Data Readiness Scan, qui cartographie le registre des points de données, la lignée par point de données et la propriété, est en cours de construction. Toute personne souhaitant s'inscrire sur la liste d'attente pour un accès dès que le scan sera disponible peut s'inscrire. Il n'y a actuellement aucun outil à commander, mais bien une place pour être informé en premier lorsqu'il sera prêt.
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.