Een logboek registreert wie een bestand heeft geopend en wanneer. Dat is nuttig, maar het beantwoordt niet de vraag die bij duurzaamheidsdata het meest wordt gesteld: hoe komt dit cijfer tot stand. Bij een spreadsheet als bron is dat verschil groter dan bij een systeem, omdat een spreadsheet geen vaste structuur afdwingt. Iedereen kan een formule aanpassen, een rij toevoegen of een eenheid wijzigen zonder dat er een spoor achterblijft dat verder gaat dan een bestandsnaam met een datum erin.
Een logboek vertelt u dat het bestand "Scope1_2023_v4.xlsx" op een bepaalde dag is opgeslagen. Het vertelt u niet welke cel is veranderd, met welke reden, en of die verandering een correctie was of een nieuwe aanname. Bij duurzaamheidsdata is dat onderscheid relevant, omdat een cijfer vaak door meerdere handen gaat voordat het in een rapport terechtkomt. Wie kan aantonen wat er tussen bron en rapport is gebeurd, kan ook aantonen waarom een cijfer is zoals het is. Wie dat niet kan, heeft alleen een uitkomst, en geen weg ernaartoe.
Tussen de ruwe data in een spreadsheet en het cijfer in een rapport liggen meestal een aantal bewerkingen: een eenheid wordt omgerekend, een periode wordt samengevoegd, een uitschieter wordt gecorrigeerd, een resultaat van de ene tab wordt opgeteld bij een resultaat van een andere tab. Elke stap is een moment waarop een aanname wordt gemaakt. Welke bewerkingen tussen bron en rapport precies plaatsvinden, verschilt per datapunt en per organisatie, maar de stappen zelf zijn zelden uniek. Ze komen terug bij vrijwel elk cijfer dat uit meerdere bronnen wordt samengesteld.
Een audit trail die alleen het eindresultaat en de laatste wijzigingsdatum toont, mist deze tussenstappen volledig. Om een cijfer te kunnen navertellen, moet vastgelegd zijn welke bewerking op welk moment is toegepast, met welke invoer, en door wie. Dat is een andere vorm van vastleggen dan een logboek biedt: het is source-to-report mapping, waarbij niet het bestand maar het datapunt het uitgangspunt is.
Een van de bewerkingen die het meest onderbelicht blijft, is aggregatie: het optellen van cijfers uit verschillende bronnen, afdelingen of periodes tot één getal. Aggregatie voelt als een technische stap, maar bevat vaak inhoudelijke keuzes: welke eenheden worden gelijkgetrokken, welke periodes tellen mee, welke uitzonderingen worden apart gehouden. Hoe u aggregatie vastlegt bepaalt of iemand achteraf kan navertellen waarom het totaal is zoals het is, of dat het totaal een zwarte doos blijft die alleen de maker ervan kan verklaren, en die verklaring is niet houdbaar zodra die persoon niet meer beschikbaar is.
Een audit trail zonder eigenaarschap legt vast wat er is gebeurd, maar niet wie daarvoor verantwoordelijk is. Bij spreadsheets is dat een risico, omdat een bestand door meerdere mensen bewerkt kan worden zonder dat duidelijk is wie de inhoudelijke keuze heeft gemaakt. Vastleggen wie een bewerking heeft uitgevoerd is iets anders dan vastleggen wie de definitie van een datapunt bezit: de een registreert een handeling, de ander legt vast wie kan uitleggen waarom een datapunt is gedefinieerd zoals het is. Beide zijn nodig om een audit trail bruikbaar te maken voor iemand die niet bij het proces aanwezig was.
Daarnaast is het onderscheid relevant tussen wie een bewerking uitvoert en wie het onderliggende proces bezit. Een medewerker kan verantwoordelijk zijn voor het invullen van een spreadsheet, terwijl een ander verantwoordelijk is voor het proces waarin die spreadsheet wordt gebruikt. Een audit trail die dat onderscheid niet maakt, wijst bij een vraag naar de laatste persoon die iets heeft aangeraakt, niet naar wie daadwerkelijk kan verklaren waarom het proces zo is ingericht.
Het is mogelijk om deze vastlegging te beginnen zonder dat daar een systeem voor wordt aangeschaft. Dat begint met het benoemen van de bewerkingen die op een datapunt worden toegepast, het vastleggen van wie welke stap uitvoert, en het beschrijven van de reden achter een correctie op het moment dat die wordt gemaakt. Hoe u lineage opbouwt zonder tool als de bron een spreadsheet is, is vooral een kwestie van discipline in vastleggen, niet van software. Een tool kan dat proces daarna ondersteunen, maar een tool boven een proces dat niets vastlegt, levert alleen een nettere spreadsheet op met dezelfde onzichtbare aannames erin.
Zodra de stappen tussen bron en rapport zijn benoemd en vastgelegd, ontstaat een tweede vraag: wie voert die stappen daadwerkelijk uit, en welk deel daarvan is herhaalbaar genoeg om over te dragen. Veel van de bewerkingen die hier worden beschreven, zoals eenheden omrekenen of gegevens samenvoegen uit vaste bronnen, zijn taken die zich laten ontleden in stappen. De [werkscan van FTE TO AI](https://fte-to-ai.com) rekent per taak uit welk deel van dat werk door AI is over te nemen, op basis van de aard van de taak in plaats van een aanname over wat automatisering in het algemeen kan.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Antwoorden komen uit de kennisbank van deze site. Geen advies op maat, en geen scan van uw bedrijf.