Revenue data architecture voor B2B

Een revenue data architecture is de manier waarop de omzetgegevens van je bedrijf over systemen verdeeld zijn en aan elkaar hangen: welke systemen welke stap vastleggen, welke sleutels ze verbinden, welk systeem per gegeven leidend is en waar je ze samenbrengt om te vergelijken. Voor een B2B-bedrijf met EUR 2 miljoen of meer omzet is het doel niet één groot systeem, maar een keten van bronnen die van lead tot betaalde factuur te herleiden is. Een goede architectuur maakt zichtbaar waar omzet verdwijnt. Een slechte maakt vooral mooie dashboards.

Waarom je hier als directeur over na moet denken

"Architectuur" klinkt als iets voor de IT-afdeling. Maar de vragen die het beantwoordt, zijn bestuurlijke vragen. Welke omzet mogen we verwachten? Welke hebben we gefactureerd? Waarom verschillen die? Welke klanten nemen minder af dan afgesproken? Als je daar geen antwoord op krijgt zonder dat iemand drie dagen in Excel zit, is je architectuur het probleem, niet je mensen.

De meeste B2B-bedrijven hebben geen architectuur die ooit ontworpen is. Ze hebben een verzameling systemen die in de loop van jaren is ontstaan: een boekhoudpakket uit de begintijd, een CRM dat sales ooit koos, een planningstool van operations, een urenregistratie, en daartussen Excel. Dat is normaal. Het wordt een probleem als niemand weet hoe het samenhangt.

De vijf lagen

Een bruikbare revenue data architecture voor B2B bestaat uit vijf lagen. Je hebt ze waarschijnlijk allemaal al, alleen niet expliciet.

Laag 1: bronsystemen

De systemen waar een stap van de omzetketen wordt vastgelegd. Voor een typisch B2B-bedrijf:

Het eerste werk is deze tabel voor je eigen bedrijf invullen. Inclusief de Excel-bestanden die in werkelijkheid een bronsysteem zijn. Een prijsafsprakenlijst in Excel die de verkoopbinnendienst gebruikt, is een bron, of je dat nu wilt of niet.

Laag 2: sleutels

De velden die een record in het ene systeem verbinden met een record in het andere. Klantnummer, dealnummer, contractnummer, ordernummer, artikelnummer. Zonder sleutels zijn je bronsystemen eilanden. Dit is in bijna elk bedrijf de zwakste laag, en de goedkoopste om te verbeteren. Het artikel hoe verbind je salesdata met financiële data werkt uit hoe je ze vastlegt.

Laag 3: eigenaarschap per gegeven

Per gegeven één leidend systeem. Contractwaarde: het contract. Geleverd: het ERP. Gefactureerd: de boekhouding. Verwacht: het CRM. Zonder deze afspraak wordt elk verschil een discussie over wie gelijk heeft in plaats van een vraag over wat er misging. Zie welke databron is leidend voor omzet.

Laag 4: een gedeeld omzetmodel

Een plek waar de bronnen samenkomen in één model met gedeelde definities. Wat is een klant? Wat is terugkerende omzet? Wanneer is een deal gewonnen? Hoe tel je een meerjarig contract? Dit model kan in een datawarehouse leven, in een BI-omgeving of in een platform dat de bronnen leest. Het belangrijkste is niet waar het leeft, maar dat de definities op papier staan en dat iedereen dezelfde gebruikt.

Laag 5: controles en signalen

Regels die over het omzetmodel draaien en afwijkingen melden. Gewonnen deal zonder order. Order zonder factuur. Contract zonder indexatie. Klant met dalende afname. Dit is de laag die geld oplevert. De eerste vier lagen zijn er om deze mogelijk te maken.

Veel bedrijven stoppen bij laag 4: ze bouwen een datawarehouse en dashboards, en dan kijkt iemand elke maand naar grafieken. Een dashboard laat een totaal zien. Een controle laat een uitzondering zien, met een eigenaar. Voor omzetlekkage heb je het tweede nodig.

Drie architectuurkeuzes

Er zijn drie gangbare manieren om laag 4 en 5 in te richten.

Alles in het ERP. Sommige bedrijven kiezen ervoor om zo veel mogelijk in één ERP te doen, met CRM, projecten en facturatie als modules. Dat vermindert het aantal koppelingen. Het lost niet op dat een afspraak in de CRM-module niet automatisch in de facturatiemodule terechtkomt. Ook binnen één pakket heb je sleutels en controles nodig.

Een datawarehouse met BI. Bronnen worden dagelijks naar een centrale database gekopieerd, bijvoorbeeld Snowflake, en daarop bouw je rapporten in Power BI of een vergelijkbaar pakket. Dit geeft veel vrijheid. Het vraagt ook mensen die het bouwen en onderhouden, en het blijft vaak hangen bij rapporteren in plaats van controleren. Het verschil staat uitgewerkt in revenue intelligence vs data warehouse.

Een platform dat de bronnen gekoppeld leest. Een revenue intelligence-platform koppelt aan de bestaande systemen, bouwt zelf het gedeelde model en draait de controles. Je bronsystemen blijven leidend en je hoeft minder zelf te bouwen. Je bent wel afhankelijk van welke systemen het platform kan lezen.

Deze keuzes sluiten elkaar niet uit. Een bedrijf met een datawarehouse kan er een controlelaag bovenop zetten. Wat niet werkt, is geen keuze maken: dan wordt Excel je architectuur.

Principes die in elke keuze gelden

1. Bronsystemen blijven leidend. Het omzetmodel is een kopie en een vergelijking, geen nieuwe bron. Correcties gebeuren in de bron, niet in het model.
2. Lezen voordat je schrijft. Begin met alleen leestoegang tot de bronnen. Terugschrijven, zoals een record aanpassen of een taak aanmaken, pas als de vergelijking betrouwbaar is en iemand het goedkeurt.
3. Historie bewaren. Een CRM overschrijft velden. Als een contractwaarde verandert, wil je weten wat hij was. Bewaar momentopnames, zodat je kunt zien wanneer een afwijking ontstond.
4. Definities vastleggen voordat je bouwt. Een dashboard zonder afgesproken definities levert een nieuwe discussie op, geen antwoord.
5. Klein beginnen, op de duurste naad. Niet alle bronnen tegelijk. Begin waar het meeste geld tussen twee systemen zit.

Waar het misgaat

Beginnen bij de techniek. Een traject dat start met de vraag welk datawarehouse je kiest, eindigt vaak met een datawarehouse en weinig antwoorden. Begin bij de vragen die je wilt beantwoorden en de sleutels die je nodig hebt.

Geen onderhoud plannen. Bronsystemen veranderen. Velden worden hernoemd, producten toegevoegd, pakketten vervangen. Een architectuur zonder eigenaar valt binnen een jaar stil, en niemand merkt het tot een rapport een verdacht mooi getal toont.

Persoonsgegevens vergeten. Een omzetmodel bevat contactpersonen, e-mailadressen en soms meer. Bepaal vooraf welke gegevens je echt nodig hebt, waar ze staan en wie erbij kan. Voor de meeste controles heb je geen namen van contactpersonen nodig, alleen klant- en contractgegevens.

Rekenvoorbeeld

Rekenvoorbeeld: stel, een zakelijke dienstverlener met EUR 15 miljoen omzet overweegt twee routes. Route A is een eigen datawarehouse met dashboards, gebouwd en onderhouden door een externe partij. Route B is eerst sleutels vastleggen en vijf controles op de duurste naden. Welke route beter is, hangt niet af van de kosten van de techniek, maar van wat hij oplevert. Als de controles in route B in het eerste jaar EUR 90.000 aan gemiste facturatie vinden, en route A in datzelfde jaar vooral mooiere maandrapporten oplevert, is de keuze duidelijk. Als het datawarehouse al staat, is de goedkoopste stap vaak de controlelaag erbovenop.

De bedragen in dit voorbeeld zijn illustratief. De les is dat je architectuur beoordeelt op wat hij vindt, niet op wat hij toont.

Checklist: hoe staat jouw architectuur ervoor?

• Is er een overzicht van alle systemen, inclusief Excel-bestanden, die een stap in de omzetketen vastleggen?
• Staat bij elke klant in het CRM het debiteurnummer uit de boekhouding?
• Is een gewonnen deal te herleiden naar de order of het contract dat eruit voortkwam?
• Is per gegeven afgesproken welk systeem leidend is?
• Zijn de definities van omzet, klant en terugkerende omzet opgeschreven?
• Draait er minstens één automatische controle op een naad tussen twee systemen?
• Is er een eigenaar die de koppelingen en controles onderhoudt?

Minder dan vier keer ja betekent dat de architectuur vooral uit gewoonte bestaat. De pillar hoe krijg je één waarheid over omzet beschrijft hoe je van daaruit verder bouwt.

Veelgestelde vragen

Heb ik een datawarehouse nodig?

Niet per se. Een datawarehouse is een manier om laag 4 in te richten. Voor veel bedrijven van EUR 2 tot 20 miljoen omzet is het een zware investering voor wat je eigenlijk nodig hebt: sleutels, definities en een paar controles.

Wie is eigenaar van de revenue data architecture?

Idealiter de financieel verantwoordelijke, met een duidelijke rol voor sales operations of IT voor het onderhoud. Het belangrijkste is dat het één persoon is die over afdelingen heen mag beslissen over definities.

Moeten we eerst onze data opschonen?

Alleen de data die je nodig hebt voor je eerste controles. Een volledig opschoonproject vooraf duurt lang en levert niets zichtbaars op. Controles laten zien welke data er echt toe doet.

Hoe past AI in deze architectuur?

AI is nuttig in laag 2 en laag 5: bij het matchen van records zonder sleutel, bij het lezen van afspraken uit contracten en bij het herkennen van afwijkend gedrag. Het vervangt geen sleutels en geen definities. Een AI-analyse op een architectuur zonder afspraken geeft snelle antwoorden op verkeerde vragen.