En logbog siger, at der er sket noget: en fil åbnet, en celle ændret, en eksport foretaget. Det er nyttigt, men det besvarer ikke det spørgsmål, der tæller, når nogen sætter spørgsmålstegn ved et tal i rapporten om bæredygtighed: hvordan er dette tal helt præcist blevet til fra kilden, og holder den vej stadig.
En systemlog registrerer handlinger. En audit trail for et datapunkt står til ansvar for et resultat. Det handler ikke om, hvem der på hvilket tidspunkt trykkede på hvilken knap, men om hvilke bearbejdninger der har omdannet en rå værdi til det tal, der nu står i rapporten. Uden den ansvarsforklaring er hvert tal en påstand, som ingen hurtigt kan underbygge, heller ikke den person, der har leveret det.
Mellem kilden og rapporten er der som regel ikke en lige linje, men en række bearbejdninger, og hver bearbejdning er et sted, hvor noget kan forskyde sig, uden at nogen bemærker det. Tænk på omregning af enheder, sammenlægning af lokationer til et koncernniveau, korrektion af en afviger, anvendelse af en emissionsfaktor. Hvilke bearbejdninger det præcist er, varierer fra datapunkt til datapunkt og er beskrevet i hvilke bearbejdninger findes der mellem kilde og rapport. Den, der ikke registrerer disse trin, ser kun startpunktet og endepunktet, og skal ved et spørgsmål om tallet rekonstruere hele vejen igen, ofte baseret på nogens hukommelse.
To bearbejdninger fortjener opmærksomhed, fordi de oftest fører til afvigelser. Aggregering summerer værdier fra forskellige kilder til en totalsum, og ved hver summering skal det stå fast, hvilke poster der er medtaget, og hvilke der ikke er. Hvordan denne dokumentation ser ud, når kilden er et regneark, er beskrevet i hvordan man dokumenterer aggregering, når kilden er et regneark. Normalisering omskalerer værdier til en fælles enhed eller periode, og en lille fejl i denne omskalering forplanter sig i hvert tal, der senere bygger på den. Dokumentationen af denne proces findes i hvordan man dokumenterer normalisering, når kilden er et regneark. Begge bearbejdninger er ubemærkede i et regneark og uundgåelige i ansvarsdokumentationen.
Meget bæredygtighedsdata begynder ikke i et system med fastlagte felter og faste regler, men i et regneark, som nogen har bygget op efter eget forgodtbefindende. En formel kan være overskrevet, en kolonne kan være flyttet, et mellemtrin kan kun have eksisteret i hovedet på den, der udarbejdede det. Hvad source-to-report mapping betyder, når kilden er et regneark, er uddybet i hvad source-to-report mapping er, når kilden er et regneark. Kernen er, at mappingen ikke må afhænge af tilfældigheden af en celle eller et faneblad, men skal dokumenteres separat og gentageligt, uafhængigt af selve regnearksfilen.
Uden dokumenterede trin eksisterer vejen fra kilde til rapport kun, så længe de personer, der har gået den, stadig er der og stadig kan huske den. Ændres der noget i processen, kommer der en ny kollega, eller stilles der et spørgsmål efter afslutningen af rapporteringsåret, er den eneste mulighed at undersøge det igen. Det er ikke en audit trail, men improvisation i bagklogskabens lys. Et værktøj kan ikke løse dette problem, hvis den underliggende proces ikke er dokumenteret; det giver da kun en pænere log over en rekonstruktion, der er lige så usikker som før.
Dokumentationen af oprindelse og bearbejdninger behøver ikke at vente på software. Hvordan man opbygger lineage uden et værktøj, med de midler, der allerede findes, er beskrevet i hvordan man opbygger lineage uden værktøj. For regneark som kilde gælder de samme principper som for audit trailen generelt: dokumentationen omfatter de samme trin, anvendt på en kilde uden fast struktur, som uddybet i hvorfor en audit trail er mere end en logbog, når kilden er et regneark. Den, der én gang har foretaget denne dokumentation for et datapunkt, kan gentage den for det næste, og opbygger derved et register, der ikke afhænger af et værktøj, men af en proces.
Så snart det er dokumenteret, hvilke trin et tal har gennemgået, og hvem der udfører hvilken bearbejdning, opstår en anden type spørgsmål: hvilken del af det arbejde er repetitivt nok til at automatisere. At aggregere efter en fast regel, normalisere værdier til en fast enhed, kontrollere en bearbejdning mod en dokumenteret kvalitetsregel - det er opgaver, der først kan vurderes for automatiseringspotentiale, når de findes som separate trin. Arbejdsscanningen fra FTE TO AI beregner for hver opgave, hvor stor en del af arbejdet der kan overtages af AI, og har netop brug for det opgaveniveau, som en audit trail giver.
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.