En stor del af bæredygtighedsdata kommer ikke fra et system med fastlagte felter og faste enheder, men fra et regneark som en medarbejder har sammensat. Energiforbrug i kWh sammen med liter brændstof, affaldstal per lokation i forskellige enheder, medarbejderantal talt på forskellige stikdatoer. Før et sådant tal kan indgå i en rapport, er det normaliseret: omregnet til en fælles enhed, korrigeret for periode, sammenlagt til et organisationsniveau. Den normalisering sker ofte i samme regneark, med en formel som ingen uden for den, der har lavet den, kender.
Problemet er ikke, at der normaliseres. Problemet er, at trinnet er usynligt. En formel i en celle viser et resultat, ikke antagelsen bag. Hvis en anden åbner filen, ser vedkommende et tal, ikke en begrundelse.
Mellem det rå regneark og det offentliggjorte tal er der som regel flere trin: omregning af enheder, estimering eller udeladelse af manglende værdier, sammenlægning af tal fra flere lokationer, anvendelse af en korrektionsfaktor for en kendt afvigelse. Hvert trin ændrer tallet, og hvert trin er et valg. Hvilken omregningsfaktor er brugt, over hvilken periode er der lagt sammen, hvorfor er en afviger medtaget eller ikke. Uden registrering findes disse valg kun i hovedet på den, der har lavet regnearket. Et overblik over hvilke bearbejdninger ligger mellem kilde og rapport viser, at normalisering sjældent er et enkelt trin, men en kæde hvor hvert led skal kunne kontrolleres separat.
At registrere normalisering er ikke det samme som at skrive en forklaring, efter rapporten er færdig. Det handler om det tidspunkt, hvor bearbejdningen finder sted: hvilken formel, med hvilke parametre, anvendt på hvilken rå værdi. Det er forskellen mellem en audit trail og en logbog. En logbog registrerer, at noget er sket; en audit trail gør klart, hvad der er sket, og hvorfor den bearbejdning var den rigtige på det tidspunkt. Den skelnen bliver uddybet i hvorfor en audit trail er mere end en logbog, når kilden er et regneark. Den, der først dokumenterer normalisering bagefter, risikerer, at det oprindelige valg ikke længere kan rekonstrueres, især hvis den, der lavede regnearket, i mellemtiden har fået en anden funktion eller har forladt organisationen.
En udbredt antagelse er, at lineage — sporingen af et tal fra kilde til rapport — kræver et system, der automatisk holder styr på det. Det er ikke nødvendigt. Også med regneark som kilde er det muligt at registrere per datapunkt, hvilken kildeværdi der er brugt, hvilken bearbejdning der er anvendt på den, og hvem der har godkendt den bearbejdning. Det kræver disciplin i stedet for software. Hvordan det ser ud i praksis, er beskrevet i hvordan skaber man lineage uden værktøj, når kilden er et regneark. Kernen er en fast struktur: per datapunkt kildetabellen, den anvendte formel, og en henvisning til, hvem der har fastlagt den formel. Det er mere et format end et system, og det kan anvendes, før man overvejer et værktøj.
En normaliseringsregel — for eksempel omregningsfaktoren fra en brændstoftype til CO2-ækvivalent — er selv et datapunkt, der har brug for en ejer. Ikke ejeren af det endelige tal, men ejeren af reglen: hvem afgør, at denne faktor er den korrekte, og hvem justerer den, når normen ændres. Uden den tildeling glider ansvaret implicit over på den, der tilfældigvis har bygget regnearket. Spørgsmålet hvem ejer definitionen af et datapunkt handler om det: en definition og en beregningsregel har brug for en ejer, der er uafhængig af, hvem der indtaster dataene. Det er en af delene af source-to-report mapping, forklaret i hvad er source-to-report mapping: ikke kun hvor et tal kommer fra, men også hvem der er ansvarlig for hvert trin derimellem.
Der findes værktøjer, som automatiserer normalisering og viser lineage. Disse værktøjer løser ingenting, hvis processen under dem ikke er indrettet: hvis ingen har registreret, hvilken regel der gælder for hvilket datapunkt, viser værktøjet blot hurtigere et tal, hvis oprindelse stadig er uklar. Først processen, så redskabet. Hvem der afgør denne indretning, er et spørgsmål, der går videre end normalisering alene; det bliver behandlet i hvem ejer processen under.
Når det først er klart, hvilke normaliseringstrin der findes, hvem der udfører dem, og efter hvilken regel, opstår et andet spørgsmål: hvilken del af det manuelle arbejde i regnearket kan overdrages til AI. Arbejdsscanningen fra FTE TO AI beregner per opgave, hvilken del af arbejdet der kan overtages, og er anvendelig, så snart normaliseringstrin er beskrevet som separate, genkendelige opgaver i stedet for gemt væk i en formel.
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.