En stor del av hållbarhetsdata kommer inte från ett system med fasta fält och fasta enheter, utan från ett kalkylblad som en medarbetare har sammanställt. Energiförbrukning i kWh bredvid liter bränsle, avfallssiffror per anläggning i olika enheter, medarbetarantal som räknats vid olika avstämningsdatum. Innan en sådan siffra passar in i en rapport har den normaliserats: omräknad till en gemensam enhet, korrigerad för period, sammanslagen till en organisationsnivå. Den normaliseringen sker ofta i samma kalkylblad, med en formel som ingen utanför den som skapade den känner till.
Problemet är inte att normalisering sker. Problemet är att steget är osynligt. En formel i en cell visar ett resultat, inte antagandet bakom det. Om någon annan öppnar filen ser han eller hon ett tal, inte ett resonemang.
Mellan det råa kalkylbladet och den publicerade siffran finns oftast flera steg: enheter räknas om, saknade värden uppskattas eller hoppas över, siffror från flera anläggningar summeras, en korrigeringsfaktor tillämpas för en känd avvikelse. Varje steg förändrar talet, och varje steg är ett val. Vilken omräkningsfaktor har använts, över vilken period har summering skett, varför har en avvikande observation tagits med eller inte. Utan dokumentation existerar dessa val bara i huvudet på den som skapade kalkylbladet. En översikt över vilka bearbetningar ligger mellan källa och rapport visar att normalisering sällan är ett enda steg, utan en kedja där varje länk måste kunna kontrolleras separat.
Att dokumentera normalisering är inte samma sak som att skriva en förklaring efter att rapporten är klar. Det handlar om det ögonblick då bearbetningen sker: vilken formel, med vilka parametrar, tillämpad på vilket råvärde. Det är skillnaden mellan ett audit trail och en logg. En logg registrerar att något har hänt; ett audit trail gör tydligt vad som hänt och varför den bearbetningen var den rätta vid det tillfället. Den distinktionen utvecklas i varför ett audit trail är mer än en logg när källan är ett kalkylblad. Den som dokumenterar normalisering först i efterhand riskerar att det ursprungliga valet inte längre kan rekonstrueras, särskilt om personen som skapade kalkylbladet numera har en annan roll eller har lämnat organisationen.
Ett vanligt antagande är att lineage — att spåra en siffra från källa till rapport — kräver ett system som automatiskt håller reda på det. Det är inte nödvändigt. Även med kalkylblad som källa är det möjligt att per datapunkt dokumentera vilket källvärde som använts, vilken bearbetning som tillämpats på det och vem som godkänt den bearbetningen. Det kräver disciplin snarare än programvara. Hur det ser ut i praktiken beskrivs i hur skapar ni lineage utan verktyg när källan är ett kalkylblad. Kärnan är en fast struktur: per datapunkt källtabellen, den tillämpade formeln, och en hänvisning till vem som fastställt formeln. Det är mer ett format än ett system, och det kan tillämpas innan man ens funderar på ett verktyg.
En normaliseringsregel — till exempel omräkningsfaktorn från en bränsletyp till CO2-ekvivalent — är i sig en datapunkt som behöver en ägare. Inte ägaren av slutsiffran, utan ägaren av regeln: vem beslutar att den här faktorn är den rätta, och vem justerar den när normen ändras. Utan den tilldelningen förskjuts ansvaret implicit till den som råkade bygga kalkylbladet. Frågan vem äger definitionen av en datapunkt handlar om just detta: en definition och en beräkningsregel behöver en ägare som är skild från den som matar in data. Det är en av delarna i source-to-report mapping, förklarat i vad är source-to-report mapping: inte bara varifrån en siffra kommer, utan även vem som är ansvarig för varje steg däremellan.
Det finns verktyg som automatiserar normalisering och visar lineage. De verktygen löser ingenting om processen därunder inte är ordnad: om ingen har dokumenterat vilken regel som gäller för vilken datapunkt, visar verktyget bara snabbare en siffra vars ursprung fortfarande är oklart. Först processen, sedan verktyget. Vem som beslutar om den ordningen är en fråga som går längre än normalisering i sig; den behandlas i vem äger processen därunder.
När det en gång är klart vilka normaliseringssteg som finns, vem som utför dem och enligt vilken regel, uppstår en andra fråga: vilken del av det manuella arbetet i kalkylbladet som kan överföras till AI. Arbetsanalysen från FTE TO AI räknar per uppgift ut vilken del av arbetet som kan tas över, och är användbar så snart normaliseringssteg beskrivits som separata, identifierbara uppgifter i stället för dolda 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.