De flesta hållbarhetsdata börjar inte i ett system med granskningsspår (audit trail). De börjar i ett kalkylblad som någon på fastighetsavdelningen håller uppdaterat, i en export från en energileverantör som skrivs av för hand, eller i en flik som fylls i tre gånger per år av en annan kollega. Det är inget problem som ett verktyg löser. Det handlar om att fastställa vad som händer mellan det kalkylbladet och siffran i rapporten, med eller utan mjukvara.
Lineage är inget annat än svaret på frågan: var kommer denna siffra ifrån och vad har gjorts med den på vägen. Vid ett automatiserat system fastställer mjukvaran en del av detta. Vid ett kalkylblad gör ingen det automatiskt, så det måste ske manuellt. Det betyder inte att det är mer komplicerat, bara att det måste göras explicit. För vad source-to-report mapping exakt innebär gäller samma logik vid ett kalkylblad som vid ett ERP-system: varje steg mellan källa och rapportsiffra namnges, även om det steget består av en manuell beräkning i en cell.
Mellan det råa kalkylbladet och siffran som står i rapporten finns oftast flera bearbetningar. En rå energifaktura omvandlas till en förbrukning per period. Den förbrukningen multipliceras med en emissionsfaktor. Resultatet läggs samman med siffror från andra anläggningar. Någonstans räknas en enhet om, fylls en uppskattning i för en saknad månad, eller görs en korrigering eftersom en tidigare inmatning visade sig vara felaktig. Vart och ett av dessa steg är en bearbetning som ändrar siffran, och vilka bearbetningar som finns mellan källa och rapport är exakt vad som måste fastställas innan någon kan kontrollera siffran.
Vid ett kalkylblad är risken att dessa steg ligger dolda i formler som ingen längre granskar. En cell innehåller en beräkning som skapades för tre år sedan av någon som numera har en annan befattning. Ingen vet längre varför formeln är uppbyggd på det sättet, och ingen vågar ändra den. Det är inget lineageproblem som försvinner så snart ett verktyg köps in. Problemet ligger i avsaknaden av en fastställd beskrivning av vad den formeln gör, oberoende av vilket system den finns i.
Två bearbetningar förekommer nästan alltid och förtjänar särskild uppmärksamhet. Den första är aggregering: siffror från flera anläggningar, avdelningar eller perioder sammanförs till ett tal. Hur aggregering fastställs avgör om någon efteråt kan se vilka källor som räknats med och vilka som inte gjort det. I ett kalkylblad sker aggregering ofta med en enkel SUMMA-formel över en rad flikar, men frågan om vilka flikar som ingår och vilka som medvetet exkluderats står sällan beskriven någonstans.
Den andra är normalisering: siffror från olika källor görs jämförbara, exempelvis genom att räkna om enheter eller genom att synkronisera olika rapporteringsperioder. Hur normalisering fastställs är precis så relevant vid en manuell process som vid ett automatiserat system. Ett kalkylblad med kolumner i olika enheter, där omräkningen någonstans mitt i är inbakad i en formel, är ett normaliseringssteg som ingen känner igen som sådant förrän en fråga ställs om det.
Att fastställa stegen mellan källa och rapport har litet värde om ingen vet vem som är ansvarig för korrektheten i varje steg. Två frågor hör till detta. Den första är vem som äger definitionen av en datapunkt: vem bestämmer exakt vad som avses med en viss siffra, och vem konsulteras om den definitionen ändras. Den andra är vem som äger den underliggande processen: vem är ansvarig för kalkylbladet självt, för att hålla det uppdaterat, och för att signalera när källan ändras eller försvinner.
Utan dessa två svar förblir lineage en ögonblicksbild. Någon fastställer idag hur siffran beräknas, men sex månader senare ändras kalkylbladet, den ansvariga medarbetaren byter roll, eller en flik ersätts av en ny export med en annan kolumnordning. Om ägarskap inte har tilldelats märker ingen att lineage inte längre stämmer med verkligheten.
Ett verktyg som sätts på en oorganiserad process registrerar samma oklarheter, bara i ett snyggare gränssnitt. Om ingen vet vilka bearbetningar som finns mellan källa och rapport, vem som äger definitionen och vem som förvaltar processen därunder, då ger automatisering framför allt snabbare osäkerhet. Ordningen är: fastställ först stegen, ägarna och reglerna, titta därefter på vilken del av detta som kan automatiseras.
Så snart den fastställningen finns blir det också tydligt vilken del av det manuella arbetet — avskrivning av fakturor, uppdatering av flikar, kontrollräkning av formler — som kan understödjas med AI. Den som vill veta vilken del av det arbetet som kvalificerar för detta kan använda arbetsanalysen från FTE TO AI. Den beräknar per uppgift vilken del av arbetet som kan övertas av AI, utifrån hur uppgifterna utförs i nuläget.
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.