Een cijfer in een duurzaamheidsrapport is bijna nooit hetzelfde cijfer als het cijfer in het bronsysteem. Tussen het moment waarop een medewerker een energiefactuur invoert of een sensor een meterstand registreert, en het moment waarop dat getal in een rapporttabel staat, gebeurt er iets. Er wordt omgerekend, opgeteld, gecorrigeerd, samengevoegd met andere bronnen. Source-to-report mapping is het vastleggen van dat traject: elke stap die de data doorloopt tussen bron en rapport, in de volgorde waarin die plaatsvindt.
De uitkomst van een berekening zegt niets over de betrouwbaarheid ervan als niemand kan reconstrueren hoe die uitkomst is ontstaan. Een uitstootcijfer kan correct zijn omdat de onderliggende stappen klopten, of correct lijken omdat een fout in de ene stap een fout in de andere toevallig compenseerde. Zonder mapping is dat verschil niet te zien. Met mapping wel: elke stap staat op zichzelf, met een eigen bron, een eigen bewerking en een eigen uitkomst die te controleren is.
Dat traject bestaat meestal uit meer stappen dan mensen verwachten. Tussen de ruwe brondata en het rapportcijfer zitten vaak meerdere bewerkingen na elkaar: eenheden die worden omgerekend, waarden die worden samengevoegd, uitzonderingen die handmatig worden gecorrigeerd. Welke bewerkingen zitten tussen bron en rapport verschilt per datapunt, maar de opbouw is telkens hetzelfde: een reeks stappen die elk iets aan de data toevoegen of veranderen, en die elk apart vastgelegd moeten worden om het geheel te kunnen volgen.
Twee soorten bewerkingen verdienen aparte aandacht, omdat ze het meest voorkomen en het makkelijkst ongemerkt fouten introduceren.
De eerste is aggregatie: het samenvoegen van cijfers uit meerdere bronnen of meerdere periodes tot één getal. Wie legt vast hoe die optelling precies verloopt, welke posten wel en niet meegenomen zijn, voorkomt dat een rapportcijfer een black box wordt. Hoe u aggregatie vastlegt, bepaalt of iemand achteraf nog kan navertellen hoe u aggregatie vastlegt op een manier die herleidbaar blijft naar de onderliggende posten.
De tweede is normalisatie: het herleiden van uiteenlopende brondata naar een gemeenschappelijke eenheid of definitie, zodat cijfers uit verschillende systemen vergelijkbaar worden. Een liter diesel en een kilowattuur elektriciteit worden pas vergelijkbaar na een omrekening, en die omrekening bevat aannames. Vastleggen hoe u normalisatie vastlegt betekent vastleggen welke aannames dat zijn, zodat een andere partij dezelfde aanname kan navolgen of ter discussie kan stellen.
Het is verleidelijk om mapping te verwarren met een activiteitenlogboek: een lijst van wie wat wanneer heeft aangepast. Dat is een onderdeel, maar niet het geheel. Een audit trail die alleen wijzigingen registreert, vertelt niet waarom een bewerking is toegepast of welke regel erachter zat. Waarom een audit trail meer is dan een logboek heeft te maken met de vraag die iedere controleur uiteindelijk stelt: niet alleen wat er is veranderd, maar op basis van welke logica en welke bron.
Source-to-report mapping wordt vaak verward met software. Er bestaan tools die lineage automatisch tonen, maar die tools registreren alleen wat er al gestructureerd is aangeleverd. Een organisatie die nog met spreadsheets en handmatige overdrachten werkt, kan het traject net zo goed vastleggen, alleen met andere middelen: een vast documentatieformaat per stap, een vaste plek waar bronbestanden bewaard blijven, een vaste manier om wijzigingen te noteren. Hoe u dat organiseert zonder tool, staat beschreven onder hoe u lineage maakt zonder tool. De discipline zit niet in de software, maar in de herhaalbaarheid van de vastlegging.
Die discipline is extra belangrijk wanneer de bron zelf al een spreadsheet is. Een cel in een werkblad heeft geen ingebouwde herkomst: niemand ziet automatisch wie een waarde heeft ingevoerd of op basis van welk document. Wat source-to-report mapping betekent als de bron een spreadsheet is, is dat die herkomst er handmatig bij georganiseerd moet worden, met dezelfde nauwkeurigheid als bij een geautomatiseerd systeem.
In de praktijk komt mapping neer op een vraag die bij elk datapunt herhaald wordt: waar komt deze waarde vandaan, wat is er mee gedaan voordat ze in het rapport terechtkwam, en wie heeft die stap uitgevoerd of goedgekeurd. Die vraag stellen bij honderden datapunten is arbeidsintensief, en juist dat maakt het aantrekkelijk om over te slaan. Maar een rapport dat op een niet-herleidbare basis staat, blijft kwetsbaar voor vragen die niemand kan beantwoorden op het moment dat ze gesteld worden.
Het in kaart brengen van deze stappen, per datapunt en over meerdere bronnen, is repetitief werk met een vaste structuur: bron identificeren, bewerking beschrijven, eigenaar vaststellen, herhalen voor het volgende datapunt. Werk met een vaste structuur is precies het soort werk waarvan een deel door AI over te nemen is. De werkscan van FTE TO AI rekent per taak uit welk deel van dat werk zich daarvoor leent, zodat duidelijk wordt waar mensen nodig blijven voor beoordeling en waar herhaling geautomatiseerd kan worden.
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.