Een spreadsheet lijkt een eenvoudige bron. Een cel met een getal, een tab met een naam, een export uit een ander systeem die is ingeplakt. Maar tussen die cel en het cijfer dat uiteindelijk in een rapport staat, ligt een reeks bewerkingen die meestal nergens is vastgelegd. Source-to-report mapping is het in kaart brengen van die reeks: elke stap die een getal doorloopt vanaf het moment dat het de spreadsheet binnenkomt tot het moment dat het in een rapportregel belandt.
Bij een systeem met vaste velden en een vaste structuur is vaak nog te herleiden welk veld waar vandaan komt. Een spreadsheet heeft die structuur niet vanzelf. Iemand voegt een tussentab toe om te aggregeren. Iemand anders kopieert een kolom naar een ander bestand om een omrekening te doen. Een derde plakt het resultaat als waarde in een rapportagesheet, waarmee de formule en daarmee het spoor verdwijnt. Niets daarvan is fout op het moment dat het gebeurt. Het probleem ontstaat een jaar later, wanneer iemand moet uitleggen waar een cijfer vandaan komt en het antwoord niet meer te reconstrueren is.
Source-to-report mapping voor een spreadsheetbron bestaat uit een aantal herkenbare stappen, die elk apart aandacht nodig hebben.
De eerste stap is de herkomst van de ruwe data: welk bestand, welke tab, welke cel of celbereik, en wie dat invoert of aanlevert. Zonder dit ankerpunt is er geen bron om naar terug te wijzen.
De tweede stap is welke bewerkingen zitten tussen bron en rapport als de bron een spreadsheet is. Denk aan eenheden die worden omgerekend, aan filters die bepaalde rijen uitsluiten, aan formules die waarden optellen of herschalen. Elke bewerking verandert het getal, en elke bewerking die niet is vastgelegd is een stap die later niet meer te verifiëren is.
De derde stap is aggregatie: meerdere regels, tabs of bestanden die worden samengevoegd tot één cijfer. Bij een spreadsheet gebeurt dit vaak handmatig, met een druk op de som-functie over een bereik dat iemand zelf heeft afgebakend. Hoe dat bereik is gekozen en wat erin zit, bepaalt het cijfer net zo veel als de onderliggende data. Dat is precies waarom vastgelegd moet worden hoe u aggregatie vastlegt als de bron een spreadsheet is: niet als formaliteit, maar omdat de aggregatiestap zelf een bron van fouten is die verder niemand ziet.
De vierde stap is normalisatie: verschillende eenheden, verschillende rapportageperiodes of verschillende locaties die naar een gemeenschappelijke basis worden gebracht voordat ze vergelijkbaar zijn. Ook hier geldt dat de keuze voor een omrekenfactor of referentiewaarde het resultaat stuurt, en dat die keuze traceerbaar moet zijn. Hoe dat werkt is uitgewerkt in hoe u normalisatie vastlegt als de bron een spreadsheet is.
De laatste stap is de plek waar het getal landt: de rapportregel, de indicator, het jaartotaal. Ook die overgang moet een spoor hebben, niet alleen een verwijzing naar het brondocument.
Het is verleidelijk om te denken dat een lijst van wie wat heeft aangepast voldoende is. Dat is een logboek, en een logboek registreert wijzigingen zonder de logica erachter te tonen. Een audit trail die iets betekent, laat niet alleen zien dat een cel is veranderd, maar ook waarom, op basis van welke regel en met welk resultaat te herleiden naar de oorspronkelijke bron. Dat onderscheid wordt verder toegelicht in de uitleg over waarom een audit trail meer is dan een logboek als de bron een spreadsheet is.
De meeste organisaties die met spreadsheets werken, hebben geen systeem dat automatisch lineage bijhoudt. Dat betekent niet dat mapping onmogelijk is, het betekent dat het handmatig moet gebeuren, met discipline in plaats van met software. Welke stappen daarvoor nodig zijn en hoe een spreadsheetgedreven proces toch herleidbaar wordt, staat beschreven in hoe u lineage maakt zonder tool als de bron een spreadsheet is. Een aanverwante vraag die vaak wordt overgeslagen is wie de definitie van een datapunt bezit: zonder een aangewezen eigenaar van de definitie verandert de betekenis van een datapunt mee met wie er op een gegeven moment naar kijkt, en dan heeft de mooiste mapping weinig waarde.
Een tool die rapporten mooier maakt, verandert niets aan de betrouwbaarheid van de cijfers die erin gaan. Als de weg van cel naar rapport niet is vastgelegd, produceert een tool nettere rapporten over dezelfde onzekere cijfers. De mapping van bron naar rapport is daarom niet een stap die na de tool komt, maar een die ervoor gaat.
Zodra de stappen tussen bron en rapport zijn uitgeschreven, wordt ook zichtbaar welke van die stappen mensenwerk zijn en welke een vaste, herhaalbare bewerking volgen. Dat onderscheid is de basis voor de werkscan van FTE TO AI, die per taak uitrekent welk deel van het werk over te nemen is door AI, op basis van wat er al is vastgelegd over de bewerking, de regels en de herkomst van de data.
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.