Een groot deel van duurzaamheidsdata komt niet uit een systeem met vaste velden en vaste eenheden, maar uit een spreadsheet die een medewerker heeft samengesteld. Energieverbruik in kWh naast liters brandstof, afvalcijfers per vestiging in verschillende eenheden, medewerkersaantallen die op verschillende peildata zijn geteld. Voordat zo'n cijfer in een rapport past, is het genormaliseerd: omgerekend naar een gemeenschappelijke eenheid, gecorrigeerd voor periode, samengevoegd tot een organisatieniveau. Die normalisatie gebeurt vaak in dezelfde spreadsheet, met een formule die niemand buiten de opsteller kent.
Het probleem is niet dat er genormaliseerd wordt. Het probleem is dat de stap onzichtbaar is. Een formule in een cel toont een uitkomst, niet de aanname erachter. Als iemand anders het bestand opent, ziet hij een getal, geen redenering.
Tussen de ruwe spreadsheet en het gepubliceerde cijfer zitten meestal meerdere stappen: eenheden omrekenen, ontbrekende waarden schatten of overslaan, cijfers van meerdere vestigingen optellen, een correctiefactor toepassen voor een bekende afwijking. Elke stap verandert het getal, en elke stap is een keuze. Welke omrekenfactor is gebruikt, over welke periode is opgeteld, waarom is een uitschieter wel of niet meegenomen. Zonder vastlegging bestaan die keuzes alleen in het hoofd van wie de spreadsheet heeft gemaakt. Een overzicht van welke bewerkingen zitten tussen bron en rapport laat zien dat normalisatie zelden een enkele stap is, maar een keten waarin elke schakel apart te controleren moet zijn.
Het vastleggen van normalisatie is niet hetzelfde als een toelichting schrijven nadat het rapport af is. Het gaat om het moment waarop de bewerking plaatsvindt: welke formule, met welke parameters, op welke ruwe waarde toegepast. Dat is het verschil tussen een audit trail en een logboek. Een logboek registreert dat er iets is gebeurd; een audit trail maakt duidelijk wat er is gebeurd en waarom die bewerking op dat moment de juiste was. Dat onderscheid wordt uitgewerkt in waarom een audit trail meer is dan een logboek als de bron een spreadsheet is. Wie normalisatie pas achteraf documenteert, loopt het risico dat de oorspronkelijke keuze niet meer te reconstrueren is, zeker als de opsteller van de spreadsheet inmiddels een andere functie heeft of de organisatie heeft verlaten.
Een veelgehoorde aanname is dat lineage — het traceren van een cijfer van bron naar rapport — een systeem vereist dat dat automatisch bijhoudt. Dat is niet noodzakelijk. Ook met spreadsheets als bron is het mogelijk om per datapunt vast te leggen welke bronwaarde is gebruikt, welke bewerking daarop is toegepast en wie die bewerking heeft goedgekeurd. Dat vraagt discipline in plaats van software. Hoe dat er in de praktijk uitziet, staat beschreven in hoe maakt u lineage zonder tool als de bron een spreadsheet is. De kern is een vaste structuur: per datapunt de brontabel, de toegepaste formule, en een verwijzing naar wie die formule heeft vastgesteld. Dat is meer een format dan een systeem, en het is toepasbaar voordat er over een tool wordt nagedacht.
Een normalisatieregel — bijvoorbeeld de omrekenfactor van een brandstofsoort naar CO2-equivalent — is zelf een datapunt dat een eigenaar nodig heeft. Niet de eigenaar van het eindcijfer, maar de eigenaar van de regel: wie beslist dat deze factor de juiste is, en wie past hem aan als de norm wijzigt. Zonder die toewijzing verschuift de verantwoordelijkheid impliciet naar wie toevallig de spreadsheet heeft gebouwd. De vraag wie bezit de definitie van een datapunt gaat daarover: een definitie en een berekeningsregel hebben een eigenaar nodig die losstaat van wie de data invoert. Dat is een van de onderdelen van source-to-report mapping, uitgelegd in wat is source-to-report mapping: niet alleen waar een cijfer vandaan komt, maar ook wie verantwoordelijk is voor elke stap ertussen.
Er bestaan tools die normalisatie automatiseren en lineage tonen. Die tools lossen niets op als het proces eronder niet is ingericht: als niemand heeft vastgelegd welke regel voor welk datapunt geldt, toont de tool alleen sneller een cijfer waarvan de herkomst nog steeds onduidelijk is. Eerst het proces, dan het gereedschap. Wie beslist over die inrichting, is een vraag die verder gaat dan normalisatie alleen; die komt aan bod bij wie bezit het proces eronder.
Als eenmaal helder is welke normalisatiestappen er zijn, wie ze uitvoert en op basis van welke regel, ontstaat een tweede vraag: welk deel van dat handmatige werk in de spreadsheet zich laat overdragen aan AI. De werkscan van FTE TO AI rekent per taak uit welk deel van het werk over te nemen is, en is bruikbaar zodra normalisatiestappen als afzonderlijke, herkenbare taken zijn beschreven in plaats van verscholen in een formule.
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.