Une grande partie des données de durabilité ne provient pas d'un système avec des champs et des unités fixes, mais d'une feuille de calcul qu'un collaborateur a assemblée. Consommation d'énergie en kWh à côté de litres de carburant, chiffres de déchets par site dans des unités différentes, effectifs comptés à des dates de référence différentes. Avant qu'un tel chiffre ne trouve sa place dans un rapport, il est normalisé : converti vers une unité commune, corrigé pour la période, agrégé au niveau de l'organisation. Cette normalisation se fait souvent dans la même feuille de calcul, avec une formule que personne d'autre que son auteur ne connaît.
Le problème n'est pas que la normalisation ait lieu. Le problème est que cette étape est invisible. Une formule dans une cellule affiche un résultat, pas l'hypothèse qui le sous-tend. Si quelqu'un d'autre ouvre le fichier, il voit un chiffre, pas un raisonnement.
Entre la feuille de calcul brute et le chiffre publié se trouvent généralement plusieurs étapes : convertir des unités, estimer ou ignorer des valeurs manquantes, additionner des chiffres provenant de plusieurs sites, appliquer un facteur de correction pour un écart connu. Chaque étape modifie le chiffre, et chaque étape est un choix. Quel facteur de conversion a été utilisé, sur quelle période l'addition a-t-elle été faite, pourquoi une valeur aberrante a-t-elle été prise en compte ou non. Sans documentation, ces choix n'existent que dans la tête de celui qui a créé la feuille de calcul. Un aperçu des opérations entre la source et le rapport montre que la normalisation est rarement une étape unique, mais une chaîne dont chaque maillon doit pouvoir être vérifié séparément.
Consigner la normalisation n'est pas la même chose qu'écrire une explication après la finalisation du rapport. Il s'agit du moment où l'opération a lieu : quelle formule, avec quels paramètres, appliquée à quelle valeur brute. C'est la différence entre une piste d'audit et un journal. Un journal enregistre qu'il s'est passé quelque chose ; une piste d'audit précise ce qui s'est passé et pourquoi cette opération était la bonne à ce moment-là. Cette distinction est développée dans pourquoi une piste d'audit est plus qu'un journal lorsque la source est une feuille de calcul. Celui qui ne documente la normalisation qu'après coup risque de ne plus pouvoir reconstituer le choix initial, surtout si l'auteur de la feuille de calcul occupe désormais une autre fonction ou a quitté l'organisation.
Une hypothèse fréquente est que la lignée — la traçabilité d'un chiffre de la source jusqu'au rapport — nécessite un système qui l'enregistre automatiquement. Ce n'est pas nécessairement le cas. Même avec des feuilles de calcul comme source, il est possible de consigner, pour chaque point de données, quelle valeur source a été utilisée, quelle opération lui a été appliquée et qui a approuvé cette opération. Cela demande de la discipline plutôt qu'un logiciel. La manière dont cela se présente en pratique est décrite dans comment créer une lignée sans outil lorsque la source est une feuille de calcul. L'essentiel est une structure fixe : pour chaque point de données, le tableau source, la formule appliquée, et une référence à qui a établi cette formule. C'est davantage un format qu'un système, et il est applicable avant même d'envisager un outil.
Une règle de normalisation — par exemple le facteur de conversion d'un type de carburant en équivalent CO2 — est elle-même un point de données qui a besoin d'un propriétaire. Pas le propriétaire du chiffre final, mais le propriétaire de la règle : qui décide que ce facteur est le bon, et qui l'adapte si la norme change. Sans cette attribution, la responsabilité se déplace implicitement vers celui qui, par hasard, a construit la feuille de calcul. La question qui possède la définition d'un point de données porte sur cela : une définition et une règle de calcul ont besoin d'un propriétaire distinct de celui qui saisit les données. C'est l'un des éléments du mapping source-to-report, expliqué dans qu'est-ce que le source-to-report mapping : non seulement d'où vient un chiffre, mais aussi qui est responsable de chaque étape intermédiaire.
Il existe des outils qui automatisent la normalisation et affichent la lignée. Ces outils ne résolvent rien si le processus sous-jacent n'est pas organisé : si personne n'a consigné quelle règle s'applique à quel point de données, l'outil ne fait qu'afficher plus rapidement un chiffre dont l'origine reste floue. D'abord le processus, ensuite l'outil. Qui décide de cette organisation est une question qui va au-delà de la seule normalisation ; elle est abordée dans qui possède le processus sous-jacent.
Une fois qu'il est clair quelles étapes de normalisation existent, qui les exécute et sur la base de quelle règle, une deuxième question se pose : quelle part de ce travail manuel dans la feuille de calcul peut être transférée à l'IA. Le scan de travail de FTE TO AI calcule, par tâche, quelle part du travail peut être reprise, et il devient utilisable dès que les étapes de normalisation sont décrites comme des tâches distinctes et identifiables plutôt que dissimulées dans une formule.
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.