Ett tal i en hållbarhetsrapport har nästan alltid en resa bakom sig. Det börjar som en rad på en energifaktura, en mätare i ett produktionssystem, ett inmatningsfält i ett HR-verktyg. När talet står i rapporten är det räknat, omräknat, sammanslaget och ibland korrigerat. Dessa mellansteg är sällan synliga i slutresultatet. Den som bara tittar på rapporten ser en siffra. Den som tittar på vägen dit ser en rad val.
Mellan källa och rapport finns vanligtvis en fast ordning av bearbetningar, även om ingen någonsin har skrivit ner den.
Först samlas data in: exporterad från ett system, avskriven från en faktura, kopierad från ett kalkylblad. Därefter normaliseras den: liter blir kubikmeter, kilowattimmar blir gigajoule, lokal valuta blir en fast beräkningsenhet. Sedan tilldelas den en kategori eller ett scope, vilket är ett val och inte en automatik. Därefter följer aggregering: siffror från verksamheter, månader eller avdelningar slås samman till en årstotal. Längs vägen sker korrigeringar, för dubbelräkningar, för saknade månader, för en felaktig enhet som någon upptäckte för ett år sedan och rättade manuellt.
Varje steg är en plats där ett antagande görs. En emissionsfaktor väljs. En uppskattning ersätter en saknad mätning. En avrundning tillämpas. I sig är inget av detta ett problem. Problemet uppstår när ingen längre vet vilket antagande som gjorts, av vem, och varför.
En rapportsiffra som inte kan spåras till sin källa är en påstådd siffra. Så snart en controller, revisor eller tillsynsmyndighet frågar hur ett tal är uppbyggt, måste svaret vara mer än "det står i systemet". Svaret måste kunna visa vägen: denna källa, denna omräkning, denna aggregering, denna korrigering.
Att dokumentera denna väg har tre direkta konsekvenser. För det första blir felsökning ett arbete på minuter i stället för dagar, eftersom det är tydligt var en omräkning har tillämpats och var inte. För det andra blir överlämning möjlig: om den som förvaltar kalkylbladet slutar, försvinner inte kunskapen om bearbetningarna med henne. För det tredje uppstår en grund för granskning, eftersom en extern part kan följa stegen utan att först behöva rekonstruera dem.
Utan denna dokumentation blir varje rapporteringscykel en upprepning av detektivarbete. Någon ringer den föregående förvaltaren, söker i gamla e-postmeddelanden, gissar sig till anledningen bakom en avrundning. Det arbetet är osynligt i själva rapporten, men det avgör hur mycket förtroende rapporten förtjänar.
Inte varje bearbetning kräver samma tillvägagångssätt. Aggregering, där siffror från flera källor slås samman till en total, kräver en annan dokumentation än normalisering, där enheter och definitioner samordnas. Den som vill veta exakt hur aggregering ska dokumenteras hittar det i en förklaring om att dokumentera aggregeringssteg, och den som undrar hur man ska hantera normalisering kan läsa om det i en beskrivning av att dokumentera normalisering. Båda är delar av samma kedja, men frågorna de väcker är olika: aggregering väcker frågor om fullständighet, normalisering om konsekvens.
Situationen förändras också när källan i sig inte är ett system utan ett kalkylblad. Då finns ingen automatisk export, ingen systemlogg, ingen fast struktur, och dokumentationen måste byggas upp på ett annat sätt. Den som hanterar denna situation hittar utgångspunkter i en genomgång av source-to-report mapping när källan är ett kalkylblad och i en översikt av bearbetningarna mellan källa och rapport specifikt vid kalkylbladskällor. För den som inte har budget för ett verktyg och måste bygga upp lineage med de medel som redan finns, finns ett arbetssätt för att skapa lineage utan specialiserad programvara.
Dokumentation av bearbetningar förväxlas ofta med en loggbok: en lista över vem som ändrat vad och när. Det är en del av historien, men inte hela den. En audit trail som bara registrerar ändringar berättar inte varför ett val gjordes eller vilken regel som tillämpades. Skillnaden mellan en loggbok och en riktig ansvarsstruktur beskrivs i en genomgång av varför en audit trail måste vara mer än en loggbok.
Data Readiness Scan kartlägger denna väg: vilken källa som förser vilken datapunkt, vilka bearbetningar som finns däremellan, vem som äger varje steg och vilken kvalitetsregel som hör dit. Det är ingen rapport och ingen frågelista, utan den underliggande strukturen som gör båda tillförlitliga.
Så snart bearbetningarna mellan källa och rapport är beskrivna blir det synligt vilka steg som är fast manuellt arbete: att skriva av en faktura, att tillämpa en fast omräkningsfaktor, att slå samman månadssiffror enligt en fast regel. Det är precis det slags arbete där man kan räkna ut vilken del som kan tas över av AI, utan att dokumentationen från källa till rapport förlorar sin funktion. FTE TO AI räknar per uppgift ut vilken del av den som är överförbar, baserat på den arbetsscan som synliggör den skillnaden per uppgift.
Data Readiness Scan är under utveckling. Den som vill få bearbetningarna mellan källa och rapport dokumenterade så snart scanen finns tillgänglig kan anmäla sig till väntelistan.
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.