Een energiefactuur vermeldt kilowattuur, een tankbon liters, een vrachtbrief tonkilometers. Voordat deze cijfers in een duurzaamheidsrapport bij elkaar kunnen staan, moet iemand ze omrekenen naar een gemeenschappelijke eenheid en vaak naar een gemeenschappelijke emissiefactor. Die omrekening heet normalisatie. Ze gebeurt vaak in een spreadsheet, met een formule die niemand meer terugvindt zodra de vraag komt waar een getal vandaan komt.
Normalisatie is niet één handeling maar een reeks keuzes. Welke bron levert de ruwe waarde. Welke eenheid geldt als standaard. Welke emissiefactor of conversiefactor wordt toegepast, en van welke bron of welk jaar komt die factor. Wordt er gecorrigeerd voor calorische waarde, voor temperatuur, voor een ander boekjaar. Elke keuze is een aanname, en elke aanname bepaalt het resultaat. Twee organisaties die dezelfde ruwe data normaliseren met een andere factor of een ander uitgangsjaar komen op een ander cijfer, zonder dat een van beide iets verkeerd doet.
Het probleem ontstaat niet bij de eerste berekening. Het ontstaat een jaar later, wanneer iemand vraagt waarom het cijfer over 2023 net anders is dan het cijfer over 2024, of wanneer een controller wil weten welke emissiefactor is gebruikt voor een specifieke energiestroom. Zonder vastlegging is het antwoord: dat weten we niet meer, of: dat zoeken we uit. Met vastlegging is het antwoord een verwijzing naar de regel die de omrekening beschrijft. Het verschil tussen die twee situaties is precies waar waarom een audit trail meer is dan een logboek over gaat: een audit trail is niet een verslag achteraf, het is de vastlegging van de keuze op het moment dat die gemaakt wordt.
Normalisatie is een van de bewerkingen die tussen bron en rapport plaatsvinden, naast optellen, filteren en herverdelen. Welke bewerkingen dat precies zijn en in welke volgorde ze de data raken, staat beschreven in welke bewerkingen zitten tussen bron en rapport als de bron een spreadsheet is. Voor elke bewerking geldt dezelfde vraag: is vast te stellen wat er is gebeurd, door wie, op basis van welke regel. Bij normalisatie komt daar een extra laag bij, omdat de regel zelf een externe bron kan hebben — een emissiefactorendatabase die jaarlijks wordt bijgewerkt. Als die database wijzigt en niemand heeft vastgelegd welke versie voor welk rapportagejaar is gebruikt, is de vergelijkbaarheid van cijfers over jaren heen niet meer te onderbouwen.
Voor elk datapunt dat een normalisatieslag doormaakt, is een aantal gegevens nodig om die stap navolgbaar te maken. De ruwe waarde en de bron ervan. De doeleenheid en de gebruikte conversie- of emissiefactor, inclusief de herkomst en versie van die factor. De datum of periode waarop de factor van toepassing is. De persoon of het systeem dat de omrekening heeft uitgevoerd. En de plek in het rapport waar het genormaliseerde cijfer terechtkomt. Dit is in feite een specifieke vorm van source-to-report mapping, waarbij niet alleen de herkomst van een cijfer wordt vastgelegd maar ook de rekenregel die het onderweg heeft veranderd. Hoe die mapping eruit ziet wanneer de bron een spreadsheet is, staat uitgewerkt in wat is source-to-report mapping als de bron een spreadsheet is.
In de praktijk zit de kennis over normalisatiefactoren vaak bij één medewerker die weet welk tabblad welke factor gebruikt en waarom. Zodra die persoon met vakantie is, ziek wordt of van functie verandert, is die kennis niet meer op te vragen, alleen te reconstrueren — met het risico dat de reconstructie een andere uitkomst geeft dan het origineel. Vastlegging los van de persoon betekent dat de regel navolgbaar is in een register, niet in een hoofd. Dat register hoeft geen ingewikkeld systeem te zijn; het kan een vast format zijn dat bij elke spreadsheet wordt bijgehouden. Hoe dat eruitziet zonder dat er een tool voor wordt aangeschaft, staat beschreven in hoe maakt u lineage zonder tool, en de aanpak specifiek voor normalisatie in spreadsheets in hoe legt u normalisatie vast als de bron een spreadsheet is.
Er bestaan tools die normalisatie automatiseren en de gebruikte factoren tonen in een overzicht. Dat is nuttig zodra de regels bekend zijn en de aannames vastliggen. Een tool die normaliseert op basis van een factor die niemand heeft gecontroleerd, of die een oude versie van een emissiefactorendatabase gebruikt zonder dat iemand dat heeft opgemerkt, geeft een nette uitkomst over een onjuiste berekening. De volgorde is: eerst vastleggen welke regel wordt toegepast en waarom, dan pas een systeem inrichten dat die regel consequent uitvoert.
Het vastleggen van normalisatieregels is zelf een taak die tijd kost: factoren opzoeken, versies noteren, koppelingen tussen ruwe waarde en omgerekend cijfer documenteren. Een deel van dat werk is herhaalbaar en regelgebonden, wat het een kandidaat maakt voor ondersteuning door AI. FTE TO AI rekent in de werkscan per taak uit welk deel van het werk op die manier is over te nemen, zodat duidelijk wordt waar mensen nodig blijven om keuzes te maken en waar een systeem de uitvoering kan overnemen.
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.