En loggbok registrerar vem som har öppnat en fil och när. Det är användbart, men det besvarar inte den fråga som oftast ställs vid hållbarhetsdata: hur kommer denna siffra till. Vid ett kalkylblad som källa är den skillnaden större än vid ett system, eftersom ett kalkylblad inte tvingar fram en fast struktur. Vem som helst kan ändra en formel, lägga till en rad eller ändra en enhet utan att det lämnar ett spår som går längre än ett filnamn med ett datum i sig.
En loggbok berättar för er att filen "Scope1_2023_v4.xlsx" sparades en viss dag. Den berättar inte vilken cell som ändrades, med vilken anledning, och om den ändringen var en korrigering eller ett nytt antagande. Vid hållbarhetsdata är den distinktionen relevant, eftersom en siffra ofta går genom flera händer innan den hamnar i en rapport. Den som kan visa vad som hänt mellan källa och rapport, kan också visa varför en siffra är som den är. Den som inte kan det, har bara ett resultat, och ingen väg dit.
Mellan råa data i ett kalkylblad och siffran i en rapport ligger vanligtvis ett antal bearbetningar: en enhet räknas om, en period sammanförs, en avvikelse korrigeras, ett resultat från en flik läggs samman med ett resultat från en annan flik. Varje steg är ett ögonblick där ett antagande görs. Vilka bearbetningar mellan källa och rapport som exakt äger rum skiljer sig åt per datapunkt och per organisation, men stegen i sig är sällan unika. De återkommer vid nästan varje siffra som sammanställs från flera källor.
En audit trail som bara visar slutresultatet och det senaste ändringsdatumet missar dessa mellansteg helt. För att kunna redogöra för en siffra måste det registreras vilken bearbetning som tillämpats vid vilket tillfälle, med vilken indata, och av vem. Det är en annan form av dokumentation än en loggbok erbjuder: det är source-to-report mapping, där inte filen utan datapunkten är utgångspunkten.
En av de bearbetningar som förblir mest underbelyst är aggregering: sammanräkning av siffror från olika källor, avdelningar eller perioder till ett tal. Aggregering känns som ett tekniskt steg, men innehåller ofta innehållsmässiga val: vilka enheter jämnas ut, vilka perioder räknas med, vilka undantag hålls separat. Hur ni dokumenterar aggregering avgör om någon efteråt kan redogöra för varför totalen är som den är, eller om totalen förblir en svart låda som endast dess upphovsperson kan förklara, och den förklaringen håller inte längre när den personen inte längre är tillgänglig.
En audit trail utan ägarskap registrerar vad som hänt, men inte vem som är ansvarig för det. Vid kalkylblad är det en risk, eftersom en fil kan bearbetas av flera personer utan att det är tydligt vem som gjort det innehållsmässiga valet. Att registrera vem som har utfört en bearbetning är något annat än att registrera vem som äger definitionen av en datapunkt: den ena registrerar en handling, den andra fastställer vem som kan förklara varför en datapunkt är definierad som den är. Båda behövs för att göra en audit trail användbar för någon som inte var närvarande i processen.
Därutöver är distinktionen relevant mellan vem som utför en bearbetning och vem som äger den underliggande processen. En medarbetare kan vara ansvarig för att fylla i ett kalkylblad, medan en annan är ansvarig för processen där det kalkylbladet används. En audit trail som inte gör den distinktionen pekar vid en fråga mot den senaste personen som rört något, inte mot den som faktiskt kan förklara varför processen är utformad som den är.
Det är möjligt att börja med denna dokumentation utan att ett system anskaffas för det. Det börjar med att namnge de bearbetningar som tillämpas på en datapunkt, registrera vem som utför vilket steg, och beskriva anledningen bakom en korrigering vid det tillfälle den görs. Hur ni bygger upp lineage utan verktyg när källan är ett kalkylblad är främst en fråga om disciplin i dokumentationen, inte om programvara. Ett verktyg kan sedan stödja den processen, men ett verktyg ovanpå en process som inte dokumenterar något ger bara ett snyggare kalkylblad med samma osynliga antaganden kvar i sig.
Så snart stegen mellan källa och rapport är namngivna och dokumenterade, uppstår en andra fråga: vem utför dessa steg faktiskt, och vilken del av det är tillräckligt repeterbar för att överlämnas. Många av de bearbetningar som beskrivs här, som att räkna om enheter eller sammanföra uppgifter från fasta källor, är uppgifter som kan delas upp i steg. [Arbetsanalysen från FTE TO AI](https://fte-to-ai.com) räknar per uppgift ut vilken del av det arbetet som kan tas över av AI, baserat på uppgiftens karaktär snarare än ett antagande om vad automatisering i allmänhet kan.
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.