Een getal in een duurzaamheidsrapport heeft bijna altijd een reis achter de rug. Het begint als een regel in een energiefactuur, een teller in een productiesysteem, een invoerveld in een HR-tool. Tegen de tijd dat het getal in het rapport staat, is het geteld, omgerekend, samengevoegd en soms gecorrigeerd. Die tussenstappen zijn zelden zichtbaar in het eindresultaat. Wie alleen naar het rapport kijkt, ziet een cijfer. Wie naar de weg ertussen kijkt, ziet een reeks keuzes.
Tussen bron en rapport zit doorgaans een vaste volgorde van bewerkingen, ook als niemand die ooit heeft opgeschreven.
Eerst wordt data verzameld: uit een systeem geëxporteerd, uit een factuur overgetypt, uit een spreadsheet gekopieerd. Daarna wordt ze genormaliseerd: liters worden kuub, kilowattuur wordt gigajoule, lokale valuta wordt een vaste rekeneenheid. Vervolgens wordt ze toegewezen aan een categorie of scope, wat een keuze is en geen automatisme. Dan volgt aggregatie: cijfers van vestigingen, maanden of afdelingen worden samengevoegd tot een jaartotaal. Onderweg gebeuren correcties, voor dubbeltellingen, voor ontbrekende maanden, voor een foutieve eenheid die iemand een jaar geleden heeft opgemerkt en handmatig heeft rechtgezet.
Elke stap is een plek waar een aanname wordt gemaakt. Een emissiefactor wordt gekozen. Een schatting vervangt een ontbrekende meting. Een afronding wordt toegepast. Op zichzelf is niets daarvan een probleem. Het probleem ontstaat wanneer niemand meer weet welke aanname is gemaakt, door wie, en waarom.
Een rapportcijfer dat niet te herleiden is naar zijn bron, is een beweerd cijfer. Zodra een controller, accountant of toezichthouder vraagt hoe een getal is opgebouwd, moet het antwoord meer zijn dan "dat staat in het systeem". Het antwoord moet de route kunnen laten zien: deze bron, deze omrekening, deze aggregatie, deze correctie.
Die route vastleggen heeft drie directe gevolgen. Ten eerste wordt fouten opsporen werk van minuten in plaats van dagen, omdat duidelijk is waar een omrekening is toegepast en waar niet. Ten tweede wordt overdracht mogelijk: als degene die de spreadsheet beheert vertrekt, gaat de kennis over de bewerkingen niet met haar mee. Ten derde ontstaat een basis voor toetsing, omdat een externe partij de stappen kan volgen zonder ze eerst te moeten reconstrueren.
Zonder die vastlegging is elke rapportagecyclus een herhaling van speurwerk. Iemand belt de vorige beheerder, zoekt in oude e-mails, gokt naar de reden achter een afronding. Dat werk is onzichtbaar in het rapport zelf, maar het bepaalt wel hoeveel vertrouwen dat rapport verdient.
Niet elke bewerking vraagt om dezelfde aanpak. Aggregatie, waarbij cijfers van meerdere bronnen worden samengevoegd tot één totaal, vraagt om een andere vastlegging dan normalisatie, waarbij eenheden en definities worden gelijkgetrokken. Wie wil weten hoe aggregatie precies te documenteren is, vindt dat in een uitleg over het vastleggen van aggregatiestappen, en wie zich afvraagt hoe om te gaan met normalisatie leest dat in een beschrijving van het vastleggen van normalisatie. Beide zijn onderdeel van dezelfde keten, maar de vragen die ze oproepen zijn anders: aggregatie roept vragen op over volledigheid, normalisatie over consistentie.
De situatie verandert ook als de bron zelf geen systeem is maar een spreadsheet. Dan is er geen automatische export, geen systeemlog, geen vaste structuur, en moet de vastlegging anders worden opgebouwd. Wie met die situatie te maken heeft, vindt aanknopingspunten in een toelichting op source-to-report mapping bij een spreadsheet als bron en in een overzicht van de bewerkingen tussen bron en rapport specifiek bij spreadsheetbronnen. Voor wie geen budget heeft voor een tool en de lineage met de middelen die er al zijn moet opbouwen, is er een werkwijze om lineage te maken zonder gespecialiseerde software.
Vastlegging van bewerkingen wordt vaak verward met een logboek: een lijst van wie wat wanneer heeft aangepast. Dat is een deel van het verhaal, maar niet het geheel. Een audit trail die alleen wijzigingen registreert, vertelt niet waarom een keuze is gemaakt of welke regel is toegepast. Het verschil tussen een logboek en een echte verantwoordingsstructuur wordt uitgewerkt in een uiteenzetting over waarom een audit trail meer moet zijn dan een logboek.
De Data Readiness Scan brengt deze route in kaart: welke bron voedt welk datapunt, welke bewerkingen zitten daartussen, wie is eigenaar van elke stap en welke kwaliteitsregel daarbij hoort. Dat is geen rapport en geen vragenlijst, maar de onderliggende structuur die beide pas betrouwbaar maakt.
Zodra de bewerkingen tussen bron en rapport zijn beschreven, wordt zichtbaar welke stappen vast handmatig werk zijn: het overtypen van een factuur, het toepassen van een vaste omrekenfactor, het samenvoegen van maandcijfers volgens een vaste regel. Dat is precies het soort werk waarvan te berekenen is welk deel door AI is over te nemen, zonder dat de vastlegging van bron tot rapport haar functie verliest. FTE TO AI rekent per taak uit welk deel daarvan overdraagbaar is, op basis van de werkscan die dat verschil per taak inzichtelijk maakt.
De Data Readiness Scan is in ontwikkeling. Wie de bewerkingen tussen bron en rapport wil laten vastleggen zodra de scan beschikbaar is, kan zich aanmelden voor de wachtlijst.
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.