Et tal i en bæredygtighedsrapport er næsten aldrig et tal direkte fra en kilde. Det er som regel resultatet af sammenlægning, gennemsnitsberegning, vejning eller omfordeling over lokationer, perioder eller enheder. Dette trin kaldes aggregering, og af alle bearbejdninger mellem kilde og rapport er dette ofte det mindst synlige. En formel i et regneark lægger tolv månedstal sammen til et årstal, eller et regneark beregner gennemsnit af emissionsfaktorer over flere leverandører. Ingen skriver ned, hvilken antagelse der ligger til grund for det.
Mellem den rå måling og det offentliggjorte tal ligger flere trin. Først indsamles data fra systemer eller regneark, derefter omregnes de til en fælles enhed, og derefter samles de til et niveau, der passer i rapporten — forretningsenhed, land eller total. Hvert trin kan indeholde et valg, der ændrer det endelige tal: tæller De en fusion med fra overtagelsesdatoen eller for hele året, beregner De gennemsnit vægtet efter omsætning eller efter antal medarbejdere, runder De af per kilde eller først på totalen. Hvilke bearbejdninger der præcis ligger mellem kilde og rapport, afhænger af indikatoren og organisationens struktur, og på hvilke bearbejdninger ligger mellem kilde og rapport, når kilden har forskellige kilder, bliver den liste længere, end de fleste organisationer forventer.
Aggregering er et valg, og valg, der ikke er registreret, bliver truffet på ny ved næste rapporteringsrunde — ofte af en anden person, med en anden antagelse. Konsekvensen er, at et tal fra sidste år ikke længere kan spores tilbage til samme logik, og at en controller eller revisor ikke kan fastslå, om en ændring i tallet er en reel ændring eller en ændring i beregningsmetoden. At registrere betyder her ikke: at beskrive en proces i generelle termer. Det betyder: for hvert rapporteringspunkt at registrere, hvilke kilder der er medtaget, med hvilken vejning, over hvilken periode, og hvem der har truffet det valg.
Aggregering forveksles ofte med normalisering, men det er to separate trin. Normalisering gør data sammenlignelige — for eksempel ved at omregne forskellige energienheder til én standard. Aggregering samler derefter disse sammenlignelige data til et højere niveau. En fejl i normaliseringen forplanter sig i hver aggregering, der følger efter, hvilket betyder, at de to trin skal kontrolleres separat. Hvordan De gør det, står på hvordan registrerer De normalisering.
De fleste organisationer har ikke kildedata, der kommer pænt ud af ét system. En del af bæredygtighedsdataene står i fakturaer, en del i et regneark, som en energileverandør har sendt per e-mail, en del i en eksport fra et ERP-system. Aggregering over disse kilder betyder, at De manuelt skal fastslå, hvilken række der hører til hvilken periode, og hvilken række der er talt dobbelt. På hvad er source-to-report mapping, når kilden er et regneark står, hvordan De kortlægger denne forbindelse mellem rå kilde og rapporteringspunkt, og på hvordan registrerer De aggregering, når kilden er et regneark står specifikt, hvordan De dokumenterer dette regnearkstrin, så aggregeringen selv bliver reproducerbar, også uden den person, der oprindeligt byggede formlen.
At registrere aggregering kræver ikke software. Det kræver disciplin: ved hvert beregningstrin at notere, hvad der gik ind, hvilken regel der blev anvendt, og hvad der kom ud. Det kan gøres i et register ved siden af de eksisterende regneark, før der overhovedet anskaffes et system. Hvordan det ser ud uden tooling, står på hvordan opretter De lineage uden værktøj. Den, der springer dette trin over og straks anskaffer en softwarepakke til rapporteringen, lægger et pænere lag over den samme uklare aggregering — rapporten ser bedre ud, men spørgsmålet om, hvorvidt tallet er korrekt, forbliver ubesvaret.
En aggregeringsregel, der ikke er registreret, er også et kontrolpunkt, der mangler. Ved en ekstern kontrol eller en intern gennemgang skal nogen kunne påvise, hvorfor et tal er sammensat, som det er sammensat, ikke bare at tallet stemmer med lommeregneren. Denne sondring — mellem et tal, der er korrekt, og et tal, der kan begrundes — er præcis, hvad en audit trail er til for, og hvorfor den indebærer mere end en simpel logbog over ændringer, som beskrevet på hvorfor en audit trail er mere end en logbog.
Når aggregeringsregler først er registreret — hvilke kilder, hvilken vejning, hvilken periode, hvem der traf valget — skabes der et grundlag for at afgøre, hvilken del af det arbejde der er gentagbart og dermed egnet til overdragelse til et system. Det er et andet spørgsmål end, om reglerne er korrekte; det er spørgsmålet om, hvor meget af anvendelsen af disse regler der stadig skal forblive menneskeligt arbejde. Arbejdsscanningen fra FTE TO AI beregner for hver opgave, hvilken del af arbejdet der kan overtages af AI, og aggregering — med sine faste trin af sammenlægning, vejning og samling — er præcis den type opgave, hvor det resultat ofte er overraskende.
Data Readiness Scan fra csrdready.net er under udvikling. Den, der allerede nu vil skabe orden i datapunktregisteret og de tilhørende aggregeringsregler, kan tilmelde sig ventelisten og bliver informeret, så snart scanningen er tilgængelig.
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.