Een spreadsheet met energieverbruik, reisdata of inkoopgegevens is zelden het eindpunt. Voordat een cijfer in een duurzaamheidsrapport staat, is het overgetypt, opgeteld, omgerekend, gefilterd en soms handmatig gecorrigeerd. Elke stap is een plek waar iets kan verschuiven ten opzichte van de bron, en elke stap die niet is vastgelegd, is een stap die niemand achteraf kan navertellen.
De gangbare route van bron naar rapport bestaat uit een aantal herkenbare bewerkingen. Data wordt overgenomen uit een brondocument, vaak met een handmatige kopieerslag. Vervolgens wordt genormaliseerd: eenheden worden gelijkgetrokken, notaties aangepast, ontbrekende waarden ingevuld of geschat. Daarna volgt aggregatie, waarbij cijfers van verschillende locaties, periodes of afdelingen worden samengevoegd tot één getal. Tussendoor vinden correcties plaats: een foutieve rij wordt aangepast, een uitschieter wordt eruit gehaald, een aanname wordt losgelaten op een leeg vak. Aan het einde van die keten staat het cijfer dat in het rapport verschijnt.
Het probleem is niet dat deze bewerkingen plaatsvinden. Normaliseren en aggregeren zijn nodig om spreadsheetdata bruikbaar te maken. Het probleem is dat deze stappen doorgaans in het hoofd van één medewerker zitten, of hooguit in een e-mailwisseling die niemand meer terugvindt.
Als een cijfer in een rapport ter discussie staat, moet te herleiden zijn waar het vandaan komt en wat ermee is gebeurd. Zonder die herleidbaarheid is elke vraag over een getal een zoektocht: wie heeft deze rij aangepast, op basis waarvan, en is dezelfde bewerking het jaar daarvoor ook toegepast. Bij normalisatie gaat het bijvoorbeeld om vragen als: welke omrekenfactor is gebruikt, en is die factor sindsdien gewijzigd. Bij aggregatie gaat het om: welke bronnen zijn opgeteld, en is een locatie per ongeluk dubbel geteld of juist overgeslagen.
Een spreadsheet zonder vastgelegde bewerkingen kan het jaar erop een ander cijfer opleveren bij dezelfde brondata, simpelweg omdat iemand anders de normalisatie doet of een correctie anders interpreteert. Dat is geen fraude, het is het ontbreken van een vastgelegd proces. Het gevolg is hetzelfde: het cijfer is niet reproduceerbaar.
Sommige organisaties denken dat een wijzigingenlogboek in de spreadsheet voldoende is. Een logboek registreert dat er iets is veranderd, maar niet waarom, door wie in welke rol, en op basis van welke regel. Het verschil tussen een logboek en een audit trail zit in die context: een audit trail maakt een bewerking navertelbaar, een logboek registreert alleen dat er iets is gebeurd.
Het ontbreken van een tool is geen excuus om lineage over te slaan. Ook zonder gespecialiseerde software is het mogelijk om per datapunt vast te leggen uit welke bron het komt, welke bewerkingen erop zijn toegepast en wie die bewerkingen heeft uitgevoerd. Dat kan met een vaste structuur naast de spreadsheet zelf: een register waarin bron, bewerking en verantwoordelijke bij elkaar staan. Hoe dat eruitziet zonder dat er een tool aan te pas komt, staat beschreven op de pagina over lineage opzetten zonder tool.
Bij elke bewerkingsstap hoort een eigenaar. Niet alleen van het uiteindelijke datapunt, maar van de bewerking zelf: wie heeft bepaald dat deze normalisatieregel wordt toegepast, en wie mag die regel wijzigen. Dat eigenaarschap ligt vaak niet vast. Twee vragen zijn daarbij te onderscheiden: wie de definitie van een datapunt bezit, dus wat het getal precies betekent, en wie het proces eronder bezit, dus wie verantwoordelijk is voor de weg waarlangs het tot stand komt. Zonder die twee vastgelegd te hebben, blijft een bewerking een individuele gewoonte in plaats van een organisatieproces.
De Data Readiness Scan brengt deze bewerkingen in kaart: welke stappen tussen bron en rapport plaatsvinden, wie ze uitvoert en welke regels erachter zitten. Dat is geen rapportagetool en geen vragenlijst, maar een registratie van het proces dat aan het cijfer voorafgaat.
Als eenmaal helder is welke bewerkingen tussen spreadsheet en rapport plaatsvinden, ontstaat ook zicht op welke van die stappen repeterend en regelgestuurd zijn, en dus in aanmerking komen om anders te worden ingericht. De werkscan van FTE TO AI rekent per taak uit welk deel van het werk door AI over te nemen is, en sluit daarmee aan op precies de bewerkingen die hier zijn beschreven: normaliseren, aggregeren en corrigeren zijn stappen die zich, mits eerst vastgelegd, laten beoordelen op die vraag.
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.