De meeste duurzaamheidsdata begint niet in een systeem met audit trail. Ze begint in een spreadsheet die iemand op de facilitaire afdeling bijhoudt, in een export uit een energieleverancier die met de hand wordt overgetikt, of in een tabblad dat drie keer per jaar door een andere collega wordt ingevuld. Dat is geen probleem dat een tool oplost. Het is een kwestie van vastleggen wat er tussen die spreadsheet en het cijfer in het rapport gebeurt, met of zonder software.
Lineage is niets anders dan het antwoord op de vraag: waar komt dit getal vandaan en wat is er onderweg mee gedaan. Bij een geautomatiseerd systeem legt de software een deel daarvan vast. Bij een spreadsheet doet niemand dat automatisch, dus moet het handmatig gebeuren. Dat betekent niet dat het ingewikkelder is, alleen dat het expliciet moet. Voor wat source-to-report mapping precies inhoudt geldt dezelfde logica bij een spreadsheet als bij een ERP-systeem: elke stap tussen bron en rapportcijfer wordt benoemd, ook als die stap uit een handmatige rekensom in een cel bestaat.
Tussen de ruwe spreadsheet en het cijfer dat in het rapport staat, zitten meestal meerdere bewerkingen. Een ruwe energiefactuur wordt omgezet naar een verbruik per periode. Dat verbruik wordt vermenigvuldigd met een emissiefactor. De uitkomst wordt opgeteld met cijfers van andere vestigingen. Ergens wordt een eenheid omgerekend, een schatting ingevuld voor een ontbrekende maand, of een correctie toegepast omdat een eerdere invoer fout bleek. Elk van die stappen is een bewerking die het cijfer verandert, en welke bewerkingen er tussen bron en rapport zitten is precies wat vastgelegd moet worden voordat iemand het cijfer kan controleren.
Bij een spreadsheet is het risico dat deze stappen in formules verstopt zitten die niemand meer naleest. Een cel bevat een berekening die drie jaar geleden is opgesteld door iemand die inmiddels een andere functie heeft. Niemand weet meer waarom de formule zo is opgebouwd, en niemand durft hem te wijzigen. Dat is geen lineageprobleem dat verdwijnt zodra er een tool wordt aangeschaft. Het probleem zit in het ontbreken van een vastgelegde beschrijving van wat die formule doet, los van het systeem waarin hij staat.
Twee bewerkingen komen vrijwel altijd voor en verdienen apart aandacht. De eerste is aggregatie: cijfers van meerdere vestigingen, afdelingen of periodes worden samengevoegd tot één getal. Hoe aggregatie wordt vastgelegd bepaalt of iemand achteraf kan zien welke bronnen zijn meegeteld en welke niet. In een spreadsheet gebeurt aggregatie vaak met een simpele SOM-formule over een reeks tabbladen, maar de vraag welke tabbladen daarin zitten en welke bewust zijn uitgesloten, staat zelden ergens beschreven.
De tweede is normalisatie: cijfers uit verschillende bronnen worden vergelijkbaar gemaakt, bijvoorbeeld door eenheden om te rekenen of door verschillende rapportageperiodes op elkaar aan te sluiten. Hoe normalisatie wordt vastgelegd is net zo relevant bij een handmatig proces als bij een geautomatiseerd systeem. Een spreadsheet met kolommen in verschillende eenheden, waarbij de omrekening ergens halverwege in een formule is verwerkt, is een normalisatiestap die niemand als zodanig herkent totdat er een vraag over wordt gesteld.
Het vastleggen van de stappen tussen bron en rapport heeft weinig waarde als niemand weet wie verantwoordelijk is voor de juistheid van elke stap. Twee vragen horen daarbij thuis. De eerste is wie de definitie van een datapunt bezit: wie bepaalt wat er precies onder een bepaald cijfer wordt verstaan, en wie wordt geraadpleegd als die definitie verandert. De tweede is wie het onderliggende proces bezit: wie is verantwoordelijk voor de spreadsheet zelf, voor het bijhouden ervan, en voor het signaleren als de bron verandert of wegvalt.
Zonder die twee antwoorden blijft lineage een momentopname. Iemand legt vandaag vast hoe het cijfer wordt berekend, maar zes maanden later verandert de spreadsheet, verhuist de verantwoordelijke medewerker, of wordt een tabblad vervangen door een nieuwe export met een andere kolomvolgorde. Als eigenaarschap niet is toegewezen, valt niemand op dat de lineage niet meer klopt met de werkelijkheid.
Een tool die op een ongeorganiseerd proces wordt gezet, registreert dezelfde onduidelijkheden, alleen in een nettere interface. Als niemand weet welke bewerkingen tussen bron en rapport zitten, wie de definitie bezit en wie het proces eronder beheert, dan levert automatisering vooral snellere onzekerheid op. De volgorde is: eerst de stappen, de eigenaren en de regels vastleggen, dan pas kijken welk deel daarvan geautomatiseerd kan worden.
Zodra die vastlegging er is, wordt ook duidelijk welk deel van het handmatige werk — het overtikken van facturen, het bijhouden van tabbladen, het narekenen van formules — met AI is te ondersteunen. Wie wil weten welk deel van dat werk daarvoor in aanmerking komt, kan de werkscan van FTE TO AI gebruiken. Die rekent per taak uit welk deel van het werk door AI over te nemen is, op basis van de taken zoals ze nu worden uitgevoerd.
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.