csrdready Sæt mig på venteliste

Kennisbank

Lineage ved regnearkskilder: hvad De registrerer og hvorfor

De fleste bæredygtighedsdata begynder ikke i et system med audit trail. De begynder i et regneark, som en medarbejder på facility-afdelingen fører, i en eksport fra en energileverandør, der bliver tastet ind manuelt, eller i et faneblad, som en anden kollega udfylder tre gange om året. Det er ikke et problem, et værktøj løser. Det er et spørgsmål om at registrere, hvad der sker mellem det regneark og tallet i rapporten, med eller uden software.

Hvad lineage betyder uden system

Lineage er ikke andet end svaret på spørgsmålet: hvor kommer dette tal fra, og hvad er der undervejs blevet gjort med det. I et automatiseret system registrerer softwaren en del af det. Ved et regneark gør ingen det automatisk, så det skal ske manuelt. Det betyder ikke, at det er mere kompliceret, kun at det skal være explicit. For hvad source-to-report mapping præcis indebærer gælder samme logik ved et regneark som ved et ERP-system: hvert trin mellem kilde og rapporttal navngives, også hvis det trin består af en manuel beregning i en celle.

Trinene mellem kilde og rapport

Mellem det rå regneark og tallet, der står i rapporten, er der som regel flere bearbejdninger. En rå energifaktura omregnes til et forbrug pr. periode. Det forbrug multipliceres med en emissionsfaktor. Resultatet lægges sammen med tal fra andre lokationer. Et sted omregnes en enhed, et estimat indsættes for en manglende måned, eller en korrektion anvendes, fordi en tidligere indtastning viste sig at være forkert. Hver af disse trin er en bearbejdning, der ændrer tallet, og hvilke bearbejdninger der findes mellem kilde og rapport er præcis det, der skal registreres, før nogen kan kontrollere tallet.

Ved et regneark er risikoen, at disse trin gemmes i formler, som ingen længere gennemgår. En celle indeholder en beregning, der blev opstillet for tre år siden af en medarbejder, som i mellemtiden har fået en anden funktion. Ingen ved længere, hvorfor formlen er opbygget sådan, og ingen vover at ændre den. Det er ikke et lineageproblem, der forsvinder, så snart der anskaffes et værktøj. Problemet ligger i, at der ikke findes en registreret beskrivelse af, hvad formlen gør, uafhængigt af det system, den befinder sig i.

Aggregering og normalisering i et regneark

To bearbejdninger forekommer stort set altid og fortjener særlig opmærksomhed. Den første er aggregering: tal fra flere lokationer, afdelinger eller perioder samles til ét tal. Hvordan aggregering registreres afgør, om man bagefter kan se, hvilke kilder der er talt med, og hvilke der ikke er. I et regneark sker aggregering ofte med en simpel SUM-formel over en række faneblade, men spørgsmålet om, hvilke faneblade der er indeholdt i den, og hvilke der bevidst er udeladt, er sjældent beskrevet nogen steder.

Den anden er normalisering: tal fra forskellige kilder gøres sammenlignelige, for eksempel ved at omregne enheder eller ved at afstemme forskellige rapporteringsperioder med hinanden. Hvordan normalisering registreres er lige så relevant ved en manuel proces som ved et automatiseret system. Et regneark med kolonner i forskellige enheder, hvor omregningen et sted midtvejs er indbygget i en formel, er et normaliseringstrin, som ingen genkender som sådan, før der stilles et spørgsmål om det.

Hvorfor ejerskab er lige så vigtigt som trinene selv

At registrere trinene mellem kilde og rapport har ringe værdi, hvis ingen ved, hvem der er ansvarlig for rigtigheden af hvert trin. To spørgsmål hører til her. Det første er hvem der ejer definitionen af et datapunkt: hvem afgør, hvad der præcis forstås ved et bestemt tal, og hvem konsulteres, hvis den definition ændres. Det andet er hvem der ejer den underliggende proces: hvem er ansvarlig for regnearket selv, for at føre det, og for at signalere, hvis kilden ændres eller bortfalder.

Uden disse to svar forbliver lineage et øjebliksbillede. Nogen registrerer i dag, hvordan tallet beregnes, men seks måneder senere ændres regnearket, den ansvarlige medarbejder skifter funktion, eller et faneblad udskiftes med en ny eksport med en anden kolonneopstilling. Hvis ejerskab ikke er tildelt, er der ingen, der bemærker, at lineage ikke længere stemmer med virkeligheden.

Hvorfor dette først, før man overvejer et værktøj

Et værktøj, der sættes på en uorganiseret proces, registrerer de samme uklarheder, blot i en mere ordentlig brugergrænseflade. Hvis ingen ved, hvilke bearbejdninger der findes mellem kilde og rapport, hvem der ejer definitionen, og hvem der forvalter processen bagved, giver automatisering primært hurtigere usikkerhed. Rækkefølgen er: registrer først trinene, ejerne og reglerne, og se derefter, hvilken del af det kan automatiseres.

Når den registrering findes, bliver det også klart, hvilken del af det manuelle arbejde — indtastning af fakturaer, opdatering af faneblade, kontrol af formler — der kan understøttes med AI. Den, der vil vide, hvilken del af det arbejde der er egnet til det, kan bruge arbejdsscanningen fra FTE TO AI. Den beregner for hver opgave, hvilken del af arbejdet der kan overtages af AI, baseret på opgaverne, som de udføres i dag.

Marvinde assistent van de Data Readiness Scan

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.