Et tal i en bæredygtighedsrapport er næsten aldrig det samme tal som tallet i kildesystemet. Mellem det øjeblik, hvor en medarbejder indtaster en energifaktura eller en sensor registrerer en måleraflæsning, og det øjeblik, hvor det tal står i en rapporttabel, sker der noget. Der omregnes, lægges sammen, korrigeres, sammenføjes med andre kilder. Source-to-report mapping er registreringen af dette forløb: hvert trin, som dataene gennemgår mellem kilde og rapport, i den rækkefølge det finder sted.
Resultatet af en beregning siger ikke noget om dets pålidelighed, hvis ingen kan rekonstruere, hvordan det resultat er kommet til. Et udslipstal kan være korrekt, fordi de underliggende trin var rigtige, eller det kan se korrekt ud, fordi en fejl i det ene trin tilfældigvis kompenserede for en fejl i det andet. Uden mapping er den forskel ikke til at se. Med mapping kan man se den: hvert trin står for sig selv, med sin egen kilde, sin egen bearbejdning og sit eget resultat, som kan kontrolleres.
Dette forløb består normalt af flere trin, end folk forventer. Mellem de rå kildedata og rapporttallet findes ofte flere bearbejdninger efter hinanden: enheder der omregnes, værdier der sammenføjes, undtagelser der rettes manuelt. Hvilke bearbejdninger befinder sig mellem kilde og rapport varierer fra datapunkt til datapunkt, men opbygningen er altid den samme: en række trin, der hver tilføjer eller ændrer noget ved dataene, og som hver skal registreres separat, for at man kan følge helheden.
To typer bearbejdninger fortjener særlig opmærksomhed, fordi de forekommer oftest og lettest introducerer fejl ubemærket.
Den første er aggregering: sammenføjningen af tal fra flere kilder eller flere perioder til ét tal. Den, der registrerer, hvordan denne sammentælling præcist foregår, hvilke poster der er medtaget og hvilke ikke, forhindrer, at et rapporttal bliver en black box. Hvordan De registrerer aggregering afgør, om nogen bagefter stadig kan gennemskue hvordan De registrerer aggregering på en måde, der forbliver sporbar tilbage til de underliggende poster.
Den anden er normalisering: tilbageførelsen af forskelligartede kildedata til en fælles enhed eller definition, så tal fra forskellige systemer bliver sammenlignelige. En liter diesel og en kilowatttime elektricitet bliver kun sammenlignelige efter en omregning, og den omregning indeholder forudsætninger. At registrere hvordan De registrerer normalisering betyder at registrere, hvilke forudsætninger det er, så en anden part kan følge samme forudsætning eller stille den til diskussion.
Det er fristende at forveksle mapping med en aktivitetslogbog: en liste over, hvem der har ændret hvad og hvornår. Det er en del af det, men ikke helheden. En audit trail, der kun registrerer ændringer, fortæller ikke, hvorfor en bearbejdning er anvendt, eller hvilken regel der lå bag den. Hvorfor en audit trail er mere end en logbog har at gøre med det spørgsmål, som enhver kontrollør i sidste ende stiller: ikke kun hvad der er ændret, men på grundlag af hvilken logik og hvilken kilde.
Source-to-report mapping forveksles ofte med software. Der findes værktøjer, der automatisk viser lineage, men disse værktøjer registrerer kun det, der allerede er leveret struktureret. En organisation, der stadig arbejder med regneark og manuelle overdragelser, kan registrere forløbet lige så godt, blot med andre midler: et fast dokumentationsformat pr. trin, et fast sted hvor kildefiler opbevares, en fast måde at notere ændringer på. Hvordan De organiserer dette uden værktøj, er beskrevet under hvordan De skaber lineage uden værktøj. Disciplinen ligger ikke i softwaren, men i registreringens gentagelighed.
Denne disciplin er ekstra vigtig, når kilden selv allerede er et regneark. En celle i et arbejdsblad har ikke en indbygget oprindelse: ingen kan automatisk se, hvem der har indtastet en værdi, eller på grundlag af hvilket dokument. Hvad source-to-report mapping betyder når kilden er et regneark, er, at denne oprindelse skal organiseres manuelt, med samme nøjagtighed som ved et automatiseret system.
I praksis kommer mapping ned til et spørgsmål, der gentages for hvert datapunkt: hvor kommer denne værdi fra, hvad er der gjort med den, før den kom med i rapporten, og hvem har udført eller godkendt dette trin. At stille dette spørgsmål for hundredvis af datapunkter er arbejdskrævende, og netop det gør det fristende at springe over. Men en rapport, der bygger på et ikke-sporbart grundlag, forbliver sårbar for spørgsmål, som ingen kan besvare i det øjeblik de stilles.
At kortlægge disse trin, pr. datapunkt og over flere kilder, er repetitivt arbejde med en fast struktur: identificere kilde, beskrive bearbejdning, fastslå ejer, gentage for det næste datapunkt. Arbejde med en fast struktur er præcis den type arbejde, hvoraf en del kan overtages af AI. Arbejdsscanen fra FTE TO AI beregner for hver opgave, hvilken del af dette arbejde der er egnet til det, så det bliver tydeligt, hvor mennesker stadig er nødvendige til vurdering, og hvor gentagelse kan automatiseres.
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.