Single source of truth zonder data-scientist: een pragmatische aanpak

Een verkoper kijkt naar het CRM en ziet één klantnaam. De boekhouding heeft dezelfde klant in twee versies (B.V. en handelsnaam), met verschillende debiteurnummers. Het marketingteam kent diezelfde klant uit een Mailchimp-lijst met een ander e-mailadres dan in het CRM. Het projectteam noteert in een Excel welke uren ze hebben besteed. En de directeur vraagt aan het eind van het kwartaal: “Wat is onze omzet per klant?”. Niemand kan het antwoord geven zonder twee dagen handwerk.

Dit is geen exotisch probleem. Het is de standaardsituatie in zo’n 80% van de MKB-organisaties. Iedereen heeft “de cijfers”, maar niemand heeft hetzelfde getal. En als je een rapport maakt op basis van het ene systeem, klopt het niet met het andere.

De vakterm hiervoor is “single source of truth”. Het idee dat er voor elke kernentiteit in je organisatie (klant, factuur, product, project, medewerker) één plek is waar de waarheid leeft, en dat alle andere systemen daar naar verwijzen of mee synchroniseren. Het klinkt simpel. Het is ook simpel. Maar in de praktijk loopt het stuk op een lange reeks kleine keuzes die elk afzonderlijk redelijk leken.

Dit artikel beschrijft drie pragmatische routes naar een single source of truth, zonder dat je daarvoor een data-engineer of data-scientist hoeft in te huren. Voor MKB-organisaties met 30 tot 150 medewerkers. Met een eerlijke vergelijking van wat het kost, wanneer welke route past, en welke route je beter eerst niet kunt nemen.

Wat single source of truth concreet betekent

Een single source of truth is geen technologie. Het is een organisatorische afspraak met technische ondersteuning. De afspraak: voor elke type entiteit kiezen we één systeem als bron. De boekhouding bepaalt wat een klant is. Het CRM bepaalt wat een lead is. De urenregistratie bepaalt wat een geschreven uur is. Andere systemen mogen die informatie tonen, maar niet aanpassen.

De technische ondersteuning maakt die afspraak werkbaar: synchronisaties zodat het ene systeem weet wat het andere weet, of een rapportagelaag die data uit meerdere bronnen samenbrengt zonder ze te dupliceren.

Drie veelvoorkomende misverstanden:

• Single source of truth betekent één systeem voor alles. Niet waar. Het betekent één systeem als bron per entiteit. Een organisatie heeft meestal drie tot zeven bronnen, niet één.
• Je hebt een datawarehouse nodig. Soms wel, vaak niet. Voor de meeste MKB-vragen volstaat een rapportagelaag bovenop bestaande systemen.
• Het is een eenmalig project. Nee. Het is een continue discipline. Elke nieuwe applicatie of integratie kan de structuur verstoren als je het niet bewaakt.

Waarom MKB hier vaak op vastloopt

Grote organisaties hebben data engineers, BI-teams en governance-comités. Zij verzorgen het centrale datamodel en de bijbehorende processen. MKB-organisaties hebben dat niet, en kunnen het ook niet aanleren. Niet omdat ze het niet snappen, maar omdat het ROI-mathematisch niet uitkomt om voor 100 medewerkers een tweekoppig data-team in dienst te nemen.

Tegelijkertijd verspreidt data zich in een typisch MKB-bedrijf snel:

• Boekhouding in Exact, Twinfield of Moneybird
• CRM in HubSpot, Pipedrive, Salesforce of een module van het ERP
• Mailmarketing in Mailchimp, ActiveCampaign of HubSpot Marketing
• Urenregistratie in Toggl, Harvest, Clockify of Excel
• Projectbeheer in Asana, Notion, Monday of Trello
• Telefonie en gesprekken in HubSpot Conversations, Aircall of Voys
• Documenten in Google Drive, SharePoint of Dropbox
• Specifieke domeinsoftware (planning, voorraad, productie, branche-tools)

Elk systeem werkt op zichzelf goed. Het is de combinatie die problemen oplevert. Een klant kan in HubSpot een ID hebben van 4231, in Exact een debiteurnummer 1078, in Mailchimp een lijst-ID, en in het urenregistratiesysteem helemaal niet bestaan. Een rapport “omzet per klant per kwartaal” vereist dat je deze identiteiten aan elkaar kunt koppelen.

Dit raakt aan een breder thema, namelijk hoe je grip houdt op je data wanneer ze in meerdere SaaS-platforms vastzitten. Lees het artikel over vendor lock-in voor MKB voor de strategische kant: hoe voorkom je dat één leverancier de waarheid bezit over je organisatie?

Drie schaalbare aanpakken

Hieronder drie routes, opklimmend in complexiteit en kosten. Begin met de eenvoudigste die voor jouw situatie werkt. Doe niet de derde wanneer de eerste voldoet. Het tegenovergestelde gebeurt namelijk vaak: een MKB-organisatie laat een datawarehouse bouwen voor een vraag die een spreadsheet had kunnen beantwoorden, en zit dan met een onderhoudsverplichting waar niemand zich verantwoordelijk voor voelt.

Aanpak 1: de spreadsheet-laag

De eenvoudigste route. Je houdt je bestaande systemen, en je bouwt één centrale spreadsheet die periodiek de data uit elk systeem trekt en aan elkaar koppelt. Dat kan met Google Sheets en de juiste connectors, of met Microsoft Excel en Power Query.

Wat je nodig hebt:

• Google Sheets of Excel Pro
• Tooling voor data-import, bijvoorbeeld Coefficient.io voor Google Sheets, of Power Query voor Excel
• Een sleutel-tabel die de identiteiten tussen systemen aan elkaar koppelt (HubSpot ID 4231 = Exact debiteur 1078 = Mailchimp e-mail klant@bedrijf.nl)
• Iemand die de spreadsheet wekelijks of maandelijks ververst

Wat het kost:

• Tooling: €0 tot €600 per jaar (Sheets is gratis, Coefficient circa €50 per maand)
• Opzet: 10 tot 25 uur eenmalig, intern of via een freelancer
• Onderhoud: 1 tot 3 uur per maand

Wanneer het past:

• 30 tot 60 medewerkers
• Drie tot vijf databronnen
• De vragen die je wilt beantwoorden zijn vooral periodieke rapportages, niet realtime dashboards
• Je hebt iemand in de organisatie (de financial controller, een ondernemende administrateur) die comfortabel is met formules en pivot-tabellen

Beperkingen: niet realtime, vereist discipline om actueel te houden, schaalt slecht naar meer dan vijf bronnen of meer dan 100.000 rijen data.

Klinkt simpel? Het is het ook. Maar in de praktijk wordt het te weinig gebruikt, want het is niet sexy. “We hebben een datawarehouse” klinkt sterker dan “we hebben een goede spreadsheet”. De spreadsheet werkt echter sneller, kost minder en levert in 80% van de MKB-situaties hetzelfde resultaat.

Aanpak 2: Looker Studio met directe bronnen

Een stap verder. Je laat Looker Studio (voorheen Google Data Studio, gratis) of een vergelijkbare BI-tool (Power BI, Metabase) rechtstreeks de databronnen uitlezen. Geen tussenlaag, geen warehouse. De BI-tool zorgt voor de visualisatie, en de connectors zorgen voor de actualisatie.

Wat je nodig hebt:

• Looker Studio (gratis) of Metabase (open source, eigen hosting) of Power BI Pro (€10 per gebruiker per maand)
• Connectors of integraties tussen de BI-tool en je bronsystemen. Voor Looker Studio zijn er native connectors voor Google Analytics, Google Ads, en BigQuery. Voor Salesforce, HubSpot en Exact heb je third-party connectors nodig (Supermetrics, Funnel, Windsor.ai)
• Een dataschema dat aangeeft welke entiteiten uit welk systeem komen, en hoe ze gekoppeld zijn

Wat het kost:

• Tooling: €0 tot €2.400 per jaar (afhankelijk van connectors en gebruikersaantallen)
• Opzet: 25 tot 50 uur eenmalig (door iemand met BI-ervaring)
• Onderhoud: 2 tot 5 uur per maand

Wanneer het past:

• 50 tot 120 medewerkers
• Vier tot zes databronnen
• Behoefte aan dashboards die meerdere mensen gelijktijdig bekijken
• Vraag naar near-real-time inzicht (uurlijks of dagelijks ververst is voldoende)

Beperkingen: de bronsystemen zelf moeten de query-load aankunnen, complexe transformaties (denormalisaties, historische snapshots) zijn moeilijk, je bent kwetsbaar voor API-veranderingen bij elke leverancier. Bij meer dan zes bronnen of complexe joins wordt het rommelig.

Praktisch advies: kies bewust welke BI-tool past bij je ecosysteem. Werk je veel met Google? Looker Studio is een logische keuze. Microsoft 365? Power BI. Open-source voorkeur of zorgen om kostencontrole bij groei? Metabase. Een verkeerde keuze hier is moeilijk terug te draaien, want na een paar maanden zit je werk vast in die BI-tool zijn templates.

Aanpak 3: een klein, eigen datawarehouse

De zwaarste route. Je bouwt een centrale opslag (BigQuery, PostgreSQL, MotherDuck) waar data uit alle bronnen regelmatig naartoe wordt gesynchroniseerd. Vanuit dat warehouse bouwt je BI-tool de rapportages. Je hebt nu een vrij volwaardige data-infrastructuur, alleen kleiner en simpeler dan wat enterprise-organisaties doen.

Wat je nodig hebt:

• Een warehouse: BigQuery (gebruiksgebaseerde pricing, vaak €50 tot €300 per maand voor MKB-volumes), of een gewone PostgreSQL-database op een Europese cloudprovider
• ETL-tooling: Airbyte (open source, of cloud variant vanaf €0), Fivetran (vanaf €120 per maand), of een lichte custom Python-script die periodiek draait
• Een BI-tool bovenop het warehouse (Metabase, Looker Studio, Power BI)
• Iemand die de data-pipelines opzet en monitoort. Dit kan een externe specialist zijn, hoeft geen interne hire te zijn

Wat het kost:

• Tooling: €1.500 tot €6.000 per jaar (warehouse + ETL + BI)
• Opzet: 50 tot 100 uur eenmalig door een ervaren data-engineer of full-stack ontwikkelaar met data-affiniteit
• Onderhoud: 4 tot 10 uur per maand

Wanneer het past:

• 100 tot 250 medewerkers
• Zes of meer databronnen
• Historische analyse belangrijk (jaar-over-jaar cohorten, trends over kwartalen)
• Meerdere afdelingen die elk hun eigen dashboards bouwen op gemeenschappelijke data
• Beginnende AI- of machine-learning-toepassingen (klantsegmentatie, voorspellingen, automatisering)

Beperkingen: onderhoudsplicht. Elke broninstellingen die verandert, elke API-update, elke nieuwe entiteit vereist aandacht. Zonder iemand die hier verantwoordelijkheid voor neemt, vergroeit het in een paar maanden tot een onbetrouwbare datalaag waar niemand meer in gelooft. En dat is erger dan geen single source of truth hebben, want het is dure onbetrouwbaarheid.

Beslismatrix: welke aanpak kies je?

Criterium	Spreadsheet-laag	Looker Studio + sources	Eigen warehouse
Organisatiegrootte	30-60 medewerkers	50-120 medewerkers	100-250 medewerkers
Aantal bronnen	3-5	4-6	6+
Doorlooptijd opzet	1-2 weken	2-4 weken	6-12 weken
Eenmalige kosten	€800-2.500	€2.500-5.000	€6.000-15.000
Jaarlijkse kosten	€300-1.000	€1.500-5.000	€5.000-15.000
Realtime mogelijk?	Nee	Near-real-time	Ja (afhankelijk van sync-frequentie)
Onderhoudsbelasting intern	Laag	Gemiddeld	Hoog
Vendor lock-in	Laag	Gemiddeld	Laag tot gemiddeld

Belangrijke opmerking bij die tabel: ga niet op organisatiegrootte alleen kiezen. Een gespecialiseerd bureau met 40 medewerkers en zes databronnen kan beter een warehouse hebben dan een handelsbedrijf met 110 medewerkers dat alles in twee systemen ziet. Het echte criterium is de complexiteit van je dataomgeving, niet je headcount.

Praktische volgorde voor wie nu start

Voor een organisatie die nog niets heeft op dit gebied, een werkbare opbouw:

• Week 1: bronnen inventariseren. Maak een lijst van alle systemen die data over klanten, projecten, omzet of voorraad bevatten. Per bron: wie is verantwoordelijk, hoeveel data zit erin, is er een API of export-functie?
• Week 2: koppelsleutels bepalen. Welke ID is de “echte” klant-ID? Meestal de boekhouding, niet het CRM. Per andere bron: hoe leg je de relatie?
• Week 3-4: prototype in spreadsheet. Bouw één tabel die klanten uit twee of drie systemen samenbrengt. Test of de koppelingen kloppen. Vaak ontdek je nu dat 15% van de data niet matcht. Dat is normaal en moet je eerst oplossen op organisatieniveau (data-opschoning) voordat je verder bouwt.
• Maand 2-3: rapportages bouwen. Begin met de drie tot vijf rapporten die management daadwerkelijk gebruikt. Niet 30 dashboards waarvan niemand er ooit naar kijkt.
• Maand 4 en verder: groeien op basis van vraag. Pas wanneer de spreadsheet zijn grenzen bereikt (te traag, te veel handwerk, te veel gebruikers), upgrade je naar aanpak 2. En pas wanneer aanpak 2 zijn grenzen bereikt, naar aanpak 3.

Vermijd de val van “we doen het meteen goed”. Bij data-infrastructuur is “goed” een functie van wat je daadwerkelijk gebruikt. Een vroege overinvestering levert geen waarde maar wel onderhoudslast.

Wat in de praktijk misgaat

Drie patronen die bij MKB-organisaties terugkomen, en die je beter kunt voorkomen.

Het BI-tool gevecht. Iemand op marketing introduceert Power BI, iemand op finance werkt met Looker Studio, een externe consultant levert een Tableau-dashboard. Nu is er geen single source of truth maar drie partial sources of truth, met conflicterende cijfers. Kies één BI-tool als organisatie en houd daar aan vast, ook als de eerste keuze niet perfect was.

De ETL-spaghetti. Een handige medewerker maakt een Python-script dat data ophaalt uit HubSpot en in een Google Sheet zet. Een ander script doet hetzelfde voor Exact. Een derde voor Mailchimp. Geen documentatie, geen versiebeheer, geen monitoring. Wanneer die ene medewerker vertrekt, weet niemand meer hoe de scripts werken, en gaan rapporten zonder waarschuwing kapot. Bouw vanaf het begin met tooling die documenteert en monitoort, zelfs als dat duurder lijkt dan een snel script.

Data-opschoning uitstellen. Slechte data in, slechte data uit. Een centrale dashboard die laat zien dat je 1.847 klanten hebt terwijl de werkelijkheid 1.230 is (de rest zijn duplicaten), is geen single source of truth maar een single source of confusion. Reserveer tijd voor opschoning. Het is saai werk maar het bepaalt of je infrastructuur waarde levert.

Wat dit oplevert

Een werkende single source of truth, op welk niveau dan ook, geeft de directie en het management een paar concrete dingen:

• Eén versie van de waarheid in management-rapportages. Geen discussies meer over wiens cijfer klopt.
• Snellere besluitvorming, omdat data sneller beschikbaar is en betrouwbaarder voelt.
• Minder dubbele invoer, omdat systemen via integraties data delen in plaats van dat mensen het in twee plekken bijhouden.
• Een basis voor toekomstige automatisering en AI-toepassingen. Modellen voor klantsegmentatie of demand forecasting hebben centrale data nodig, anders kan een AI-team niet eens beginnen.
• Verminderde lock-in op individuele leveranciers, omdat de centrale rapportagelaag los staat van het bron-CRM of de bron-boekhouding. Zie ook het artikel over vendor lock-in voor MKB: een centrale datalaag is een van de beste hedges tegen leveranciersafhankelijkheid.

En de keerzijde, eerlijk gesteld: het kost discipline en aandacht. Een single source of truth is een organisme dat onderhouden moet worden, niet een product dat je eenmaal installeert. Wie geen capaciteit heeft om die discipline te dragen, is beter af met goede spreadsheets dan met een onbetrouwbaar warehouse.

Tot slot

Single source of truth zonder data-scientist is haalbaar voor het MKB. De technologie is goedkoper dan ooit, de tooling is volwassen, en AI-versnelling maakt het opzetten van rapportages en integraties sneller dan in elk eerder decennium. Wat ontbreekt is meestal niet techniek, maar de organisatorische keuze om één plek te kiezen als bron en daar consequent aan vast te houden.

Begin klein. Eerst de spreadsheet, dan het dashboard, dan eventueel het warehouse. Maak elke stap pas wanneer de vorige zijn grenzen heeft bereikt, niet eerder. En als je het ingewikkelder maakt dan nodig, betaal je daar de eerste jaren voor zonder enige extra waarde te krijgen.

Wil je met me sparren over de specifieke situatie in jouw organisatie? Welke bronnen, welke vragen, welke aanpak past? Neem contact op voor een vrijblijvend gesprek.