Ett kalkylblad verkar en enkel källa. En cell med ett tal, en flik med ett namn, en export från ett annat system som är inklistrad. Men mellan den cellen och siffran som till slut hamnar i en rapport ligger en rad bearbetningar som oftast inte finns dokumenterade någonstans. Source-to-report mapping är att kartlägga den raden: varje steg som ett tal genomgår från det ögonblick det kommer in i kalkylbladet till det ögonblick det hamnar i en rapportrad.
Med ett system med fasta fält och en fast struktur går det ofta fortfarande att härleda vilket fält som kommer varifrån. Ett kalkylblad har inte den strukturen av sig själv. Någon lägger till en mellanflik för att aggregera. Någon annan kopierar en kolumn till en annan fil för att göra en omräkning. En tredje klistrar in resultatet som värde i ett rapportblad, varmed formeln och därmed spåret försvinner. Inget av detta är fel i det ögonblick det sker. Problemet uppstår ett år senare, när någon måste förklara var en siffra kommer ifrån och svaret inte längre går att rekonstruera.
Source-to-report mapping för en kalkylbladskälla består av ett antal igenkännbara steg, som var och en behöver egen uppmärksamhet.
Det första steget är ursprunget till rådatan: vilken fil, vilken flik, vilken cell eller cellintervall, och vem som matar in eller levererar det. Utan denna ankarpunkt finns ingen källa att peka tillbaka på.
Det andra steget är vilka bearbetningar som ligger mellan källa och rapport när källan är ett kalkylblad. Tänk på enheter som räknas om, filter som utesluter vissa rader, formler som summerar eller omskalar värden. Varje bearbetning förändrar talet, och varje bearbetning som inte är dokumenterad är ett steg som senare inte längre kan verifieras.
Det tredje steget är aggregering: flera rader, flikar eller filer som slås samman till en siffra. I ett kalkylblad sker detta ofta manuellt, med ett tryck på summafunktionen över ett intervall som någon själv har avgränsat. Hur det intervallet har valts och vad som ingår i det avgör siffran precis lika mycket som den underliggande datan. Det är just därför det måste dokumenteras hur ni dokumenterar aggregering när källan är ett kalkylblad: inte som en formalitet, utan eftersom själva aggregeringssteget är en felkälla som ingen annan ser.
Det fjärde steget är normalisering: olika enheter, olika rapportperioder eller olika platser som förs till en gemensam bas innan de blir jämförbara. Även här gäller att valet av en omräkningsfaktor eller referensvärde styr resultatet, och att det valet måste vara spårbart. Hur det fungerar beskrivs i hur ni dokumenterar normalisering när källan är ett kalkylblad.
Det sista steget är platsen där talet landar: rapportraden, indikatorn, årstotalen. Även den övergången måste ha ett spår, inte bara en hänvisning till källdokumentet.
Det är lockande att tro att en lista över vem som ändrat vad räcker. Det är en loggbok, och en loggbok registrerar ändringar utan att visa logiken bakom dem. Ett granskningsspår (audit trail) som betyder något visar inte bara att en cell har ändrats, utan även varför, utifrån vilken regel och med vilket resultat spårbart till den ursprungliga källan. Den distinktionen förklaras vidare i genomgången om varför ett granskningsspår är mer än en loggbok när källan är ett kalkylblad.
De flesta organisationer som arbetar med kalkylblad har inget system som automatiskt håller reda på lineage. Det betyder inte att mapping är omöjlig, det betyder att den måste göras manuellt, med disciplin i stället för med mjukvara. Vilka steg som krävs för det och hur en kalkylbladsdriven process trots allt blir spårbar beskrivs i hur ni skapar lineage utan verktyg när källan är ett kalkylblad. En relaterad fråga som ofta hoppas över är vem som äger definitionen av en datapunkt: utan en utsedd ägare av definitionen förändras betydelsen av en datapunkt beroende på vem som vid ett givet tillfälle tittar på den, och då har den finaste mapping föga värde.
Ett verktyg som gör rapporter snyggare förändrar inget i tillförlitligheten hos siffrorna som går in i dem. Om vägen från cell till rapport inte är dokumenterad producerar ett verktyg bara snyggare rapporter om samma osäkra siffror. Mapping av källa till rapport är därför inte ett steg som kommer efter verktyget, utan ett som kommer före det.
Så snart stegen mellan källa och rapport är utskrivna blir det också synligt vilka av dessa steg som är mänskligt arbete och vilka som följer en fast, repeterbar bearbetning. Den distinktionen är grunden för arbetsscanen från FTE TO AI, som per uppgift räknar ut vilken del av arbetet som kan tas över av AI, utifrån vad som redan är dokumenterat om bearbetningen, reglerna och datans ursprung.
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.