Single source of truth? Meerdere waarheden betekent dat niemand kan beslissen

Marketing claimt dat jullie tienduizend klanten hebben. Finance telt er 8.500. Sales rapporteert twaalfduizend. Welk cijfer gebruik je in de investeerderspresentatie? Welke basis bepaalt je groeistrategie? Het antwoord zou simpel moeten zijn, maar in organisaties zonder single source of truth (afgekort tot SSOT) bestaat die zekerheid niet. Elke afdeling heeft een eigen systeem, een eigen definitie en een eigen waarheid. Die versnippering blokkeert besluitvorming, veroorzaakt klantfrustratie en ondermijnt het vertrouwen in data.

Single source of truth betekent dat elk feit één autoritatieve bron heeft. Niet drie systemen met drie verschillende klantaantallen, maar één master record dat iedereen gebruikt. Niet vijf prijslijsten verspreid over Excel, webshop, ERP en CRM, maar één productcatalogus waar alle systemen uit putten. Die eenvoud klinkt vanzelfsprekend maar is in de praktijk van vooral grote ondernemingen, verbazingwekkend zeldzaam. Organisaties groeien, systemen stapelen zich op en niemand ruimt de rommel op totdat de chaos onwerkbaar wordt.

De pijn van versnipperde waarheden

We hebben het over data, allesbehalve een sexy onderwerp. Dus laten we het direct naar de pijnlijke praktijk vertalen in drie voorbeelden:

• Een klant belt dat jullie de factuur naar het oude adres stuurden. Je checkt het CRM: adres is correct. Finance checkt het ERP: oud adres staat er nog. Webshop heeft weer een derde variant. Welk systeem heeft gelijk? Niemand weet het. De klant raakt gefrustreerd, Finance moet handmatig corrigeren en jullie hebben drie systemen die elk beweren de waarheid te bevatten.
• Sales sluit een deal voor een product dat volgens hun systeem leverbaar is. Productie checkt voorraad en ziet dat het artikel al weken uit productie is. De webshop toont het nog steeds als beschikbaar. Drie bronnen, drie antwoorden. De klant krijgt een excuus in plaats van een levering. Sales verliest commissie. Reputatie lijdt schade. Alles omdat niemand weet welk systeem leidend is.
• Management vraagt om een dashboard met klanttevredenheid. Marketing haalt NPS-scores uit hun survey-tool. Customer success haalt ratings uit het support-systeem. Product haalt app-reviews uit de stores. Elk cijfer vertelt een ander verhaal. Welke gebruik je om te sturen? Als je de verkeerde kiest, optimaliseer je voor een metric die niet representatief is. Als je alle drie gebruikt, weet je niet welke prioriteit heeft.

Die versnippering escaleert bij hypothese-testing in een Build, Measure, Learn-aanpak. Je wilt testen of klanten die meer dan drie producten kopen, hogere retentie hebben. Maar afdeling Marketing definieert een klant anders dan Finance. Sales telt prospect-accounts mee die nog niets kochten. Elke afdeling test met een andere dataset en komt tot een andere conclusie. Je kunt geen actionable metrics afleiden als de basis niet klopt.

Master Data Management: één klant, één record

Master Data Management, vaak afgekort tot MDM, is de praktische implementatie van single source of truth. Het principe is simpel: voor elk kritisch datatype definieer je één master record dat leidend is. Andere systemen mogen kopieën hebben voor performance of functionaliteit, maar synchroniseren altijd terug naar de master. Wijzigingen gebeuren daar, niet verspreid.

Neem bijvoorbeeld klantdata. Je CRM is de master voor contactgegevens en communicatiegeschiedenis. Finance heeft deze klantdata nodig voor facturatie, maar haalt die uit het CRM via synchronisatie. De webshop toont klantgegevens maar schrijft updates terug naar het CRM. Als een klant zijn adres wijzigt, gebeurt dat op één plek en propageren alle systemen die wijziging. Geen handmatige updates in vijf databases, geen discrepanties, geen verouderde informatie.

Productdata werkt precies hetzelfde. Het ERP is de master voor voorraad, prijzen en specificaties. De webshop haalt die data op maar beheert het niet zelf. Marketing gebruikt productinfo uit het ERP voor campagnes. Sales configureert offertes met actuele prijzen uit dezelfde bron. Wijzig de prijs in het ERP en alle systemen reflecteren die aanpassing. Geen Excel-sheets die maanden oud zijn, geen handmatige synchronisaties die vergeten worden.

Die architectuur vereist dus discipline. Teams moeten accepteren dat hun lokale aanpassingen niet de waarheid worden. Finance kan niet zomaar een klantrecord aanpassen in hun eigen systeem en verwachten dat iedereen dat overneemt. Ze moeten de wijziging doen in de master en daar verspreidt het zich. Die governance irriteert in het begin maar voorkomt de chaos die ontstaat als iedereen eigen wijzigingen doorvoert. Zeker wanneer je als organisatie aan de slag gaat met AI in de praktijk te brengen.

AI versterkt de chaos exponentieel

Zonder single source of truth creëren AI-systemen verwarring in plaats van helderheid. Een RAG-implementatie haalt bijvoorbeeld productinformatie op uit je kennisbank. Maar die kennisbank bevat documenten van drie jaar geleden naast actuele specificaties. Het model krijgt dan tegenstrijdige informatie: product X kost negentig euro volgens één document, 105 euro volgens een ander en 89 euro volgens de webshop-export. Welke prijs geeft het model aan de klant?

Dat is een databaseprobleem, geen AI-hallucinatie. Het combineert wat het vindt, misschien middelt het de prijzen. Misschien kiest het de meest recente bron, maar zonder metadata weet het niet welke dat is. Misschien kiest het willekeurig. In elk scenario is het antwoord onbetrouwbaar. De klant krijgt verkeerde informatie, niet omdat het model faalt maar omdat je data versnipperd is.

Fine-tuning op slechte data maakt het permanenter. Train een model op een dataset met conflicterende klantrecords en het leert die inconsistentie als normaal. Het reproduceert fouten met vertrouwen omdat het trainingsdata als waarheid accepteert. Garbage in, garbage out is geen nieuw probleem, maar AI escaleert de impact. Waar een mens twijfelt bij tegenstrijdige cijfers, genereert een LLM een confident antwoord gebaseerd op welke bron toevallig meer gewicht kreeg tijdens training.

Chatbots die klantenservice ondersteunen, falen spectaculair zonder single source of truth. Een klant vraagt naar zijn bestelling. Het systeem haalt gegevens op uit het order-management systeem, het CRM en email-logs. Elk systeem toont een andere verzendstatus. De chatbot rapporteert wat het eerst vindt of combineert fragmenten tot een onzinnig antwoord. De klant belt alsnog, gefrustreerd dat de AI niet weet wat er speelt.

Niet één systeem met alle data

Single source of truth betekent niet dat alle data letterlijk in één systeem moet staan. Die interpretatie leidt tot onwerkbare monolithische databases met vendor lock-in die niemand wil. Het leidende principe is: per datatype één master, decentraal geoptimaliseerd. Klantgegevens horen thuis in het CRM omdat dat systeem gebouwd is voor klantrelaties. Productdata hoort in het ERP omdat dat voorraad, inkoop en productie beheert. Financiële transacties horen in het boekhoudsysteem. Elk systeem is geoptimaliseerd voor zijn domein en fungeert als master voor dat specifieke datatype. Andere systemen mogen kopieën hebben voor performance, maar bij conflict wint de master. Zo bouw je een gedistribueerde architectuur waarbij elk feit één autoritatieve bron heeft zonder alles geforceerd in één database te proppen die voor niets geoptimaliseerd is.

Gebrek aan single source of truth kost centen

Dubbel werk is de meest directe kost. Medewerkers checken multiple systemen voor hetzelfde feit. Finance controleert klantgegevens in drie databases voordat ze een factuur versturen. Sales belt support om te verifiëren wat de webshop toont. Productie overloopt handmatig voorraadcijfers omdat het ERP en het magazijnsysteem niet kloppen. Die uren stapelen zich op tot FTE’s die bezig zijn met reconciliatie in plaats van waarde creëren.

Verkeerde beslissingen kosten meer maar zijn minder zichtbaar. Management investeert in een marktsegment dat volgens Sales hard groeit, maar Finance-data toont stagnatie. Wie heeft gelijk? Zonder single source of truth gokt je. Soms win je, vaak niet. Die strategische misgrepen kosten tonnen maar worden niet direct gekoppeld aan data-chaos.

Klantfrustratie is moeilijk te kwantificeren maar reëel. Klanten die drie keer hetzelfde adres moeten opgeven, raken geïrriteerd. Klanten die een product bestellen dat niet leverbaar blijkt, switchen naar concurrenten. Klanten die tegenstrijdige informatie krijgen van verschillende afdelingen, verliezen vertrouwen. Die schade zie je terug in churn, maar de oorzaak wijst naar versnipperde systemen.

Compliance-risico’s groeien. AVG vereist dat je klanten inzicht geeft in welke data je over hen hebt en die kunt verwijderen op verzoek. Als klantdata verspreid zit over acht systemen zonder duidelijke master, kun je die eis niet waarmaken. Audits falen omdat je niet kunt bewijzen welk cijfer leidend is. Financiële rapportages worden afgekeurd omdat brondata niet te traceren is naar één autoritatieve bron.

Pragmatisch beginnen zonder alles tegelijk te willen

Single source of truth voor alle data in één keer implementeren is onhaalbaar en onnodig. Begin waar de pijn het grootst is. Meestal is dat klantdata, omdat elke afdeling ermee werkt en discrepanties direct zichtbaar worden. Of productdata, omdat verkeerde prijzen en voorraadinfo direct omzet raken. De uitdaging is om de data-silo’s te doorbreken.

Kies één domein en definieer welk systeem master wordt. Dat hoeft niet het beste systeem te zijn, maar wel het systeem dat meest compleet is en waar meeste teams op vertrouwen. Migreer data naar die master, schoon het op en maak andere systemen afhankelijk. Elke write gaat naar de master, elke read mag lokaal maar synchroniseert regelmatig.

Governance is kritischer dan technologie. Wie mag master records aanpassen? Wat is het proces voor wijzigingen? Hoe vaak synchroniseren systemen? Die regels voorkom je dat chaos terugkeert. Zonder governance past iemand lokaal een record aan, vergeet het door te geven en binnen een maand zijn systemen weer uit sync.

Meet nu de impact. Hoeveel support-tickets gingen over adres-discrepanties voor single source of truth? Hoeveel erna? Hoe vaak moest Finance handmatig corrigeren? Die cijfers tonen ROI en rechtvaardigen verdere uitrol naar andere domeinen. Start klein, bewijs waarde, schaal op.

Data is niet sexy maar wel de basis

Niemand wordt enthousiast van data-harmonisatie. Het is geen feature die klanten zien of een innovatie die pers haalt. Maar zonder single source of truth falen de zaken die wel sexy zijn. AI-chatbots geven verkeerde antwoorden. Dashboards tonen cijfers waar niemand op durft te vertrouwen. Hypotheses testen wordt giswerk omdat datasets niet kloppen.

Organisaties die groeien zonder single source of truth bouwen op zand. Elke nieuwe tool voegt een nieuwe bron van waarheid toe. Elke integratie moet met vijf systemen praten in plaats van één master. Complexiteit explodeert, kosten stijgen en betrouwbaarheid daalt. Op een gegeven moment kost het meer om bestaande chaos te managen dan het zou kosten om het op te lossen.

Single source of truth is geen projectje maar een fundament. Het maakt actionable metrics mogelijk omdat cijfers vergelijkbaar zijn. Het laat hypotheses testen omdat datasets consistent zijn. Het geeft vertrouwen in dashboards omdat iedereen naar dezelfde bron kijkt. En het voorkomt dat AI-systemen confident onzin genereren omdat brondata tegenstrijdig is. Data is niet sexy, maar betrouwbare data is de enige basis waarop je kunt bouwen.