La lineage n'est rien d'autre que le chemin parcouru par un chiffre : depuis l'endroit où il naît jusqu'à l'endroit où il figure dans le rapport. Ce chemin existe aussi sans outil. Chaque fois que quelqu'un reprend un chiffre d'un tableur, l'additionne à un autre chiffre, le divise par un nombre d'ETP ou le convertit dans une autre unité, cette personne parcourt un morceau de lineage — qu'il soit documenté ou non. La question n'est pas de savoir si cette lineage existe, mais si quelqu'un peut la raconter sans devoir faire appel à son créateur d'origine.
Un point de données dans un rapport de durabilité a presque toujours plusieurs étapes derrière lui. D'abord il y a la source : un tableur avec la consommation d'énergie par site, un export d'un système RH, une facture d'un fournisseur. Ensuite vient un traitement : addition, moyenne, conversion en équivalent CO2, association à un facteur d'émission. Suit souvent une agrégation : des chiffres par site deviennent des chiffres par pays, des chiffres par mois deviennent des chiffres par an. Enfin, le chiffre aboutit dans le rapport, souvent via encore une dernière couche manuelle de recopie ou de collage.
Pour comprendre ce que signifie le mapping source-vers-rapport lorsque la source est un tableur, il est utile de ne pas considérer ces étapes comme un tout, mais comme une série d'actions distinctes, chacune avec son propre risque d'erreur. Qui ne connaît que le début et la fin du trajet ne peut pas voir où, entre les deux, quelque chose s'est mal passé.
Sans documentation, la lineage n'existe que dans la tête de celui qui a créé le tableur. Dès que cette personne est en vacances, change de fonction ou quitte l'organisation, la connaissance de ce qui s'est passé entre la source et le rapport disparaît. Un contrôleur qui veut vérifier un chiffre doit alors deviner ou se renseigner. Une partie externe qui évalue le rapport doit se fier à la confiance plutôt qu'à la documentation.
Les traitements qui se situent entre la source et le rapport sont souvent devenus invisibles parce qu'ils sont cachés dans des formules de cellules, des macros ou la mémoire d'un collaborateur. Pour déterminer quels traitements se situent entre la source et le rapport lorsque la source est un tableur, il est nécessaire de nommer séparément chaque formule, chaque étape manuelle et chaque lien — non pas comme une boîte noire mais comme une série d'actions distinctes.
Il en va de même pour les deux traitements les plus fréquents dans les données de durabilité : l'agrégation et la normalisation. L'agrégation — l'addition de chiffres provenant de plusieurs sources en un seul total — exige de documenter quelles sources ont été prises en compte et lesquelles ne l'ont pas été, et pourquoi. Qui souhaite savoir comment l'agrégation est documentée lorsque la source est un tableur se heurte à la nécessité de documenter, pour chaque calcul d'addition, quelles cellules ont été incluses. La normalisation — la conversion de chiffres bruts vers une unité comparable — connaît un problème similaire : quel facteur de conversion a été utilisé, de quelle source provient ce facteur, et ce facteur est-il resté identique toute l'année. Pour qui souhaite documenter cela, une approche est décrite dans comment la normalisation est documentée lorsque la source est un tableur.
Une erreur fréquente consiste à penser qu'un journal des modifications suffit à produire une lineage. Un journal montre quand une cellule a été modifiée et par qui, mais pas pourquoi cette modification était nécessaire ou quelle règle se trouvait derrière. Une piste d'audit qui enregistre uniquement ce qui s'est passé, sans la logique sous-jacente, laisse les mêmes questions sans réponse qu'en l'absence de journal. La raison pour laquelle une piste d'audit doit être davantage qu'un journal lorsque la source est un tableur réside dans la différence entre l'enregistrement d'une action et la documentation de la raison qui la sous-tend.
Sans outil, cela signifie en pratique : pour chaque point de données, un document fixe ou une section fixe indiquant quelle source a été utilisée, quels traitements ont été appliqués dans quel ordre, qui a effectué le traitement et sur la base de quelle règle. Cela peut se faire dans un registre séparé, dans des champs de commentaires du tableur lui-même, ou dans un aperçu distinct tenu à jour parallèlement au processus de reporting. C'est plus de travail que de ne rien documenter, et moins de travail que de mettre en place un outil au-dessus d'un processus qui ne connaît pas encore ces étapes. C'est précisément la raison de parcourir d'abord ces étapes : un outil placé sur un processus désorganisé produit un résultat plus soigné à partir des mêmes chiffres impossibles à retracer. Pour le détail de cette approche, y compris le format dans lequel la lineage peut être tenue à jour par point de données, une élaboration est disponible dans comment la lineage se construit sans outil lorsque la source est un tableur.
Documenter manuellement chaque étape entre la source et le rapport est réalisable pour un nombre limité de points de données et de tableurs. Avec un plus grand nombre de sites, de sources ou de cycles de reporting, suivre chaque traitement devient une tâche qui demande beaucoup de temps et qui est sensible aux mêmes erreurs que la lineage est justement censée révéler. Au moment où cette limite se profile, il est utile de savoir quelle partie de ce travail de documentation peut se répéter selon une règle fixe et donc être reprise par l'IA, et quelle partie continue d'exiger une évaluation. Le scan de travail de FTE TO AI calcule cela par tâche, afin de clarifier où le travail manuel a encore sa place et où la répétition appelle autre chose.
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.