En spreadsheet virker som en enkel kilde. En celle med et tal, en fane med et navn, en eksport fra et andet system, der er indsat. Men mellem den celle og det tal, der til sidst står i en rapport, ligger en række bearbejdninger, som som regel ikke er dokumenteret nogen steder. Source-to-report mapping er at kortlægge den række: hvert trin, et tal gennemgår fra det øjeblik, det kommer ind i spreadsheetet, til det øjeblik, det ender i en rapportlinje.
Med et system med fastlagte felter og en fast struktur kan man ofte stadig spore, hvilket felt der kommer hvorfra. En spreadsheet har ikke den struktur af sig selv. Nogen tilføjer en mellemfane for at aggregere. En anden kopierer en kolonne til en anden fil for at lave en omregning. En tredje indsætter resultatet som værdi i et rapporteringsark, hvorved formlen og dermed sporet forsvinder. Intet af dette er forkert i det øjeblik, det sker. Problemet opstår et år senere, når nogen skal forklare, hvor et tal kommer fra, og svaret ikke længere kan rekonstrueres.
Source-to-report mapping for en spreadsheetkilde består af en række genkendelige trin, som hver især kræver særskilt opmærksomhed.
Det første trin er oprindelsen af de rå data: hvilken fil, hvilken fane, hvilken celle eller celleområde, og hvem der indtaster eller leverer det. Uden dette ankerpunkt er der ingen kilde at henvise tilbage til.
Det andet trin er hvilke bearbejdninger ligger mellem kilde og rapport, når kilden er en spreadsheet. Tænk på enheder, der omregnes, filtre, der udelukker bestemte rækker, formler, der lægger værdier sammen eller omskalerer dem. Hver bearbejdning ændrer tallet, og hver bearbejdning, der ikke er dokumenteret, er et trin, der senere ikke kan verificeres.
Det tredje trin er aggregering: flere linjer, faner eller filer, der samles til ét tal. Ved en spreadsheet sker dette ofte manuelt, med et tryk på sum-funktionen over et område, som nogen selv har afgrænset. Hvordan det område er valgt, og hvad der er i det, bestemmer tallet lige så meget som de underliggende data. Det er netop derfor, det skal dokumenteres hvordan man dokumenterer aggregering, når kilden er en spreadsheet: ikke som en formalitet, men fordi selve aggregeringstrinnet er en fejlkilde, som ellers ingen ser.
Det fjerde trin er normalisering: forskellige enheder, forskellige rapporteringsperioder eller forskellige lokationer, der bringes til en fælles basis, før de er sammenlignelige. Også her gælder det, at valget af en omregningsfaktor eller referenceværdi styrer resultatet, og at dette valg skal kunne spores. Hvordan det fungerer, er beskrevet i hvordan man dokumenterer normalisering, når kilden er en spreadsheet.
Det sidste trin er det sted, hvor tallet lander: rapportlinjen, indikatoren, årstotalen. Også den overgang skal have et spor, ikke kun en henvisning til kildedokumentet.
Det er fristende at tro, at en liste over, hvem der har ændret hvad, er tilstrækkelig. Det er en log, og en log registrerer ændringer uden at vise logikken bag dem. En audit trail, der betyder noget, viser ikke kun, at en celle er blevet ændret, men også hvorfor, på grundlag af hvilken regel og med hvilket resultat, der kan spores tilbage til den oprindelige kilde. Denne forskel bliver yderligere forklaret i uddybningen af hvorfor en audit trail er mere end en log, når kilden er en spreadsheet.
De fleste organisationer, der arbejder med spreadsheets, har ikke et system, der automatisk holder styr på lineage. Det betyder ikke, at mapping er umulig, det betyder, at det skal ske manuelt, med disciplin i stedet for med software. Hvilke trin der kræves til dette, og hvordan en spreadsheetdrevet proces alligevel kan gøres sporbar, er beskrevet i hvordan man skaber lineage uden værktøj, når kilden er en spreadsheet. Et relateret spørgsmål, der ofte bliver overset, er hvem der ejer definitionen af et datapunkt: uden en udpeget ejer af definitionen ændrer betydningen af et datapunkt sig med, hvem der på et givet tidspunkt kigger på det, og så har den flotteste mapping ikke stor værdi.
Et værktøj, der gør rapporter pænere, ændrer ikke noget ved troværdigheden af de tal, der går ind i dem. Hvis vejen fra celle til rapport ikke er dokumenteret, producerer et værktøj bare pænere rapporter om de samme usikre tal. Mappingen fra kilde til rapport er derfor ikke et trin, der kommer efter værktøjet, men et, der går forud for det.
Så snart trinene mellem kilde og rapport er skrevet ned, bliver det også synligt, hvilke af disse trin der er menneskeligt arbejde, og hvilke der følger en fast, gentagelig bearbejdning. Denne forskel er grundlaget for arbejdsscanningen fra FTE TO AI, som for hver opgave beregner, hvilken del af arbejdet der kan overtages af AI, baseret på hvad der allerede er dokumenteret om bearbejdningen, reglerne og dataens oprindelse.
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.