Dans la plupart des organisations comptant plusieurs unités opérationnelles, le même point de donnée existe à plusieurs reprises. Les émissions de scope 2 figurent chez l'une des implantations dans une facture d'énergie, chez une autre dans un export Excel du facility manager, et chez une troisième nulle part — on y procède par estimation. Ce n'est pas l'erreur d'un seul département. C'est la conséquence d'années durant lesquelles personne n'a défini le point de donnée de manière centralisée, et encore moins sa source.
La question « qu'est-ce que vous en faites » suppose qu'il existe une seule réponse qui convient partout. Ce n'est pas le cas. L'approche dépend de ce qui existe déjà par unité opérationnelle, et cela diffère.
Avant de décider quoi que ce soit à propos d'un point de donnée sans source, mettez côte à côte ce que chaque unité opérationnelle possède effectivement. Pour certaines unités, une source existe mais personne ne l'a consignée — un système, un fournisseur, une administration locale. Pour d'autres, cette source n'existe pas, et le chiffre est actuellement complété sur la base d'une estimation ou d'un collègue qui « le sait à peu près ». Ces deux situations demandent une approche différente. Où existe-t-il déjà un point de donnée est la question à laquelle vous répondez unité par unité, avant d'ajouter ou de modifier quoi que ce soit dans le registre.
Ce n'est qu'une fois cette vue d'ensemble établie que vous voyez où se situe réellement le problème : non pas dans le point de donnée en tant que concept, mais dans la dispersion des sources qui y sont rattachées de manière chaotique.
Un registre de points de données ne contient pas une seule ligne par point de donnée, mais autant de lignes qu'il y a de sources. Pour un point de donnée présent dans trois unités opérationnelles, il y a trois lignes : chacune avec sa propre source, son propre propriétaire et sa propre règle de qualité. Cela peut sembler fastidieux, mais cela évite quelque chose de pire — regrouper des chiffres d'origines différentes en un seul nombre dont plus personne ne peut dire d'où il vient.
Chaque ligne contient au minimum : la définition du point de donnée telle qu'elle s'applique à cette unité, le système source ou le document dont provient le chiffre, qui est responsable de la fourniture et du contrôle, et la règle permettant de vérifier si la valeur est plausible — une fourchette, une comparaison avec l'année précédente, un contrôle de l'unité de mesure. Sans cette dernière règle, vous ne remarquez une erreur que si quelqu'un regarde par hasard.
Une complication qui apparaît souvent au cours de ce processus : l'unité A et l'unité B appellent « le même » point de donnée, mais mesurent en réalité quelque chose de différent. L'une comptabilise les voitures de leasing dans le scope 1, l'autre non. Ce n'est pas un problème de source mais un problème de définition, et il doit être résolu avant qu'une source y soit rattachée. La manière de reconnaître ce type de différences est décrite dans comment reconnaître un point de donnée en double dans plusieurs unités opérationnelles. Ce n'est que lorsque la définition est identique pour toutes les unités qu'il est utile de rattacher des sources — sinon vous enregistrez trois fois quelque chose de différent sous un seul nom.
Si cette analyse révèle qu'une unité opérationnelle n'a réellement aucune source pour un point de donnée, il existe deux voies. La première : un système ou un processus existe qui pourrait fournir le chiffre, mais personne ne l'a jamais désigné comme source. Dans ce cas, vous désignez cette source et consignez qui en assure la gestion. La seconde : il n'y a réellement rien, et le chiffre est actuellement estimé ou repris d'une autre unité. Dans ce cas, vous l'enregistrez explicitement comme une estimation, avec l'hypothèse sous-jacente, plutôt que de la laisser passer pour une valeur mesurée. Les deux voies doivent figurer dans le registre — une estimation qui n'est pas étiquetée comme telle est un risque qui ne se révèle qu'au moment du contrôle.
Avant de consacrer du temps à trouver une source pour chaque point de donnée manquant, il est utile de déterminer si ce point de donnée est pertinent pour cette unité opérationnelle. Un petit bureau comptant cinq collaborateurs n'a peut-être pas besoin d'un point de donnée de scope 3 significatif qui, lui, est pertinent pour un site de production. Quels points de données vous faut-il vraiment permet d'établir cette distinction, afin que vous ne cherchiez pas une source pour quelque chose qui, au final, n'était pas nécessaire.
Il existe une tendance à continuer à chercher des sources jusqu'à ce que tout soit couvert de manière parfaite. Ce n'est pas le critère. Le registre est achevé lorsque, pour chaque point de donnée pertinent, par unité opérationnelle, il est établi s'il existe une source, qui en est le propriétaire et quel contrôle lui est appliqué — pas lorsque chaque chiffre est traçable avec une certitude absolue. Quand un registre est-il achevé dans plusieurs unités opérationnelles décrit concrètement ce point d'aboutissement, et combien de vos points de données ont une source est la question qui permet de mesurer l'avancement en cours de route.
Ce travail se fait unité par unité et non en une seule fois pour l'ensemble de l'organisation. Le temps nécessaire dépend du nombre d'unités opérationnelles, du nombre de points de données et du nombre de ceux qui disposent déjà d'une source. Une partie de ce travail — l'interrogation des propriétaires, le rassemblement des sources, le remplissage du registre — est le genre de tâche qui peut être structurée et partiellement accélérée. Le werkscan de FTE TO AI calcule, par tâche, quelle part peut être reprise par l'IA, afin que vous sachiez, avant de commencer, quelle part restera manuelle et quelle part ne le sera pas.
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.