La plupart des données de durabilité ne commencent pas dans un système doté d'une piste d'audit. Elles commencent dans un tableur qu'une personne du service facilitaire tient à jour, dans un export d'un fournisseur d'énergie recopié à la main, ou dans un onglet rempli trois fois par an par un autre collègue. Ce n'est pas un problème qu'un outil résout. Il s'agit d'enregistrer ce qui se passe entre ce tableur et le chiffre du rapport, avec ou sans logiciel.
La lineage n'est rien d'autre que la réponse à la question : d'où vient ce chiffre et qu'a-t-on fait en chemin. Avec un système automatisé, le logiciel enregistre une partie de cela. Avec un tableur, personne ne le fait automatiquement, donc cela doit se faire manuellement. Cela ne veut pas dire que c'est plus compliqué, seulement que cela doit être explicite. Pour ce qu'implique précisément le mapping source-to-report, la même logique s'applique à un tableur qu'à un système ERP : chaque étape entre la source et le chiffre du rapport est nommée, même si cette étape consiste en un simple calcul manuel dans une cellule.
Entre le tableur brut et le chiffre qui figure dans le rapport, il y a généralement plusieurs opérations. Une facture d'énergie brute est convertie en consommation par période. Cette consommation est multipliée par un facteur d'émission. Le résultat est additionné avec les chiffres d'autres sites. Quelque part, une unité est convertie, une estimation est saisie pour un mois manquant, ou une correction est appliquée parce qu'une saisie antérieure s'est révélée erronée. Chacune de ces étapes est une opération qui modifie le chiffre, et quelles opérations se trouvent entre la source et le rapport est précisément ce qui doit être enregistré avant que quelqu'un puisse vérifier le chiffre.
Avec un tableur, le risque est que ces étapes soient cachées dans des formules que plus personne ne relit. Une cellule contient un calcul établi il y a trois ans par une personne qui occupe désormais une autre fonction. Plus personne ne sait pourquoi la formule est construite ainsi, et personne n'ose la modifier. Ce n'est pas un problème de lineage qui disparaît dès qu'un outil est acquis. Le problème réside dans l'absence d'une description enregistrée de ce que fait cette formule, indépendamment du système dans lequel elle se trouve.
Deux opérations reviennent presque toujours et méritent une attention particulière. La première est l'agrégation : les chiffres de plusieurs sites, services ou périodes sont regroupés en un seul chiffre. La façon dont l'agrégation est enregistrée déterminera si quelqu'un peut voir après coup quelles sources ont été comptabilisées et lesquelles ne l'ont pas été. Dans un tableur, l'agrégation se fait souvent à l'aide d'une simple formule SOMME sur une série d'onglets, mais la question de savoir quels onglets sont inclus et lesquels ont été délibérément exclus est rarement décrite quelque part.
La seconde est la normalisation : les chiffres provenant de différentes sources sont rendus comparables, par exemple en convertissant les unités ou en alignant différentes périodes de reporting. La façon dont la normalisation est enregistrée est tout aussi pertinente pour un processus manuel que pour un système automatisé. Un tableur comportant des colonnes exprimées dans différentes unités, dont la conversion est intégrée quelque part au milieu d'une formule, constitue une étape de normalisation que personne ne reconnaît comme telle jusqu'à ce qu'une question soit posée à ce sujet.
Enregistrer les étapes entre la source et le rapport a peu de valeur si personne ne sait qui est responsable de l'exactitude de chaque étape. Deux questions s'imposent à cet égard. La première est qui détient la définition d'un point de donnée : qui détermine précisément ce que recouvre un chiffre donné, et qui est consulté lorsque cette définition change. La seconde est qui détient le processus sous-jacent : qui est responsable du tableur lui-même, de sa mise à jour, et de signaler tout changement ou disparition de la source.
Sans ces deux réponses, la lineage reste une photographie instantanée. Aujourd'hui, quelqu'un enregistre comment le chiffre est calculé, mais six mois plus tard, le tableur change, l'employé responsable change de poste, ou un onglet est remplacé par un nouvel export avec un ordre de colonnes différent. Si la propriété n'a pas été attribuée, personne ne remarque que la lineage ne correspond plus à la réalité.
Un outil appliqué à un processus désorganisé enregistrera les mêmes zones d'ombre, simplement dans une interface plus soignée. Si personne ne sait quelles opérations se trouvent entre la source et le rapport, qui détient la définition et qui gère le processus sous-jacent, alors l'automatisation produira surtout une incertitude plus rapide. L'ordre est le suivant : d'abord enregistrer les étapes, les propriétaires et les règles, ensuite seulement examiner quelle partie de tout cela peut être automatisée.
Dès que cet enregistrement est en place, il devient également clair quelle part du travail manuel — recopier des factures, tenir des onglets à jour, revérifier des formules — peut être soutenue par l'IA. Pour savoir quelle part de ce travail s'y prête, on peut utiliser le werkscan de FTE TO AI. Celui-ci calcule, tâche par tâche, quelle part du travail peut être reprise par l'IA, sur la base des tâches telles qu'elles sont exécutées aujourd'hui.
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.