Et tal i en bæredygtighedsrapport har næsten altid en rejse bag sig. Det begynder som en linje i en energiregning, en tæller i et produktionssystem, et indtastningsfelt i et HR-værktøj. Når tallet står i rapporten, er det talt, omregnet, sammenlagt og nogle gange korrigeret. De mellemliggende trin er sjældent synlige i slutresultatet. Den, der kun ser på rapporten, ser et tal. Den, der ser på vejen derimellem, ser en række valg.
Mellem kilde og rapport findes der som regel en fast rækkefølge af bearbejdninger, også selvom ingen nogensinde har skrevet den ned.
Først indsamles data: eksporteret fra et system, afskrevet fra en faktura, kopieret fra et regneark. Derefter normaliseres de: liter bliver til kubikmeter, kilowatttimer bliver til gigajoule, lokal valuta bliver en fast regneenhed. Derefter tildeles de en kategori eller scope, hvilket er et valg og ikke en automatik. Så følger aggregering: tal fra afdelinger, måneder eller enheder samles til et årstotal. Undervejs sker der korrektioner, for dobbelttællinger, for manglende måneder, for en forkert enhed, som nogen for et år siden opdagede og rettede manuelt.
Hvert trin er et sted, hvor der foretages en antagelse. En emissionsfaktor vælges. Et skøn erstatter en manglende måling. En afrunding anvendes. I sig selv er intet af dette et problem. Problemet opstår, når ingen længere ved, hvilken antagelse der er foretaget, af hvem, og hvorfor.
Et rapporttal, der ikke kan spores tilbage til sin kilde, er et påstået tal. Så snart en controller, revisor eller tilsynsmyndighed spørger, hvordan et tal er opbygget, skal svaret være mere end "det står i systemet". Svaret skal kunne vise ruten: denne kilde, denne omregning, denne aggregering, denne korrektion.
At dokumentere den rute har tre direkte konsekvenser. For det første bliver fejlfinding et spørgsmål om minutter i stedet for dage, fordi det er klart, hvor en omregning er anvendt, og hvor den ikke er. For det andet bliver overdragelse mulig: hvis den person, der administrerer regnearket, forlader virksomheden, forsvinder viden om bearbejdningerne ikke med hende. For det tredje skabes et grundlag for kontrol, fordi en ekstern part kan følge trinene uden først at skulle rekonstruere dem.
Uden denne dokumentation er hver rapporteringscyklus en gentagelse af detektivarbejde. Nogen ringer til den tidligere ansvarlige, søger i gamle e-mails, gætter på årsagen bag en afrunding. Det arbejde er usynligt i selve rapporten, men det afgør, hvor meget tillid den rapport fortjener.
Ikke alle bearbejdninger kræver samme tilgang. Aggregering, hvor tal fra flere kilder samles til ét totaltal, kræver en anden dokumentation end normalisering, hvor enheder og definitioner bringes i overensstemmelse. Den, der vil vide, hvordan aggregering nøjagtigt skal dokumenteres, finder det i en forklaring om dokumentation af aggregeringstrin, og den, der spørger sig selv, hvordan man håndterer normalisering, kan læse det i en beskrivelse af dokumentation af normalisering. Begge er en del af den samme kæde, men de spørgsmål, de rejser, er forskellige: aggregering rejser spørgsmål om fuldstændighed, normalisering om konsistens.
Situationen ændrer sig også, når kilden selv ikke er et system, men et regneark. Så er der ingen automatisk eksport, ingen systemlog, ingen fast struktur, og dokumentationen skal opbygges anderledes. Den, der har med denne situation at gøre, finder holdepunkter i en gennemgang af source-to-report mapping når kilden er et regneark og i et overblik over bearbejdningerne mellem kilde og rapport specifikt ved regnearkskilder. For den, der ikke har budget til et værktøj og skal opbygge lineage med de midler, der allerede findes, er der en fremgangsmåde til at skabe lineage uden specialiseret software.
Dokumentation af bearbejdninger forveksles ofte med en logbog: en liste over hvem der har ændret hvad hvornår. Det er en del af historien, men ikke det hele. En audit trail, der kun registrerer ændringer, fortæller ikke, hvorfor et valg er truffet, eller hvilken regel der er anvendt. Forskellen mellem en logbog og en reel ansvarlighedsstruktur uddybes i en gennemgang af hvorfor en audit trail skal være mere end en logbog.
Data Readiness Scan kortlægger denne rute: hvilken kilde fodrer hvilket datapunkt, hvilke bearbejdninger ligger imellem, hvem er ejer af hvert trin, og hvilken kvalitetsregel hører til det. Det er hverken en rapport eller et spørgeskema, men den underliggende struktur, der først gør begge dele pålidelige.
Så snart bearbejdningerne mellem kilde og rapport er beskrevet, bliver det synligt, hvilke trin der er fast manuelt arbejde: afskrivning af en faktura, anvendelse af en fast omregningsfaktor, sammenlægning af månedstal efter en fast regel. Det er præcis den type arbejde, hvor det kan beregnes, hvilken del der kan overtages af AI, uden at dokumentationen fra kilde til rapport mister sin funktion. FTE TO AI beregner pr. opgave, hvilken del af den der kan overdrages, baseret på den arbejdsscanning, der synliggør denne forskel pr. opgave.
Data Readiness Scan er under udvikling. Den, der ønsker at få bearbejdningerne mellem kilde og rapport dokumenteret, så snart scanningen er tilgængelig, kan tilmelde sig ventelisten.
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.