Hoe gegevenskwaliteit te meten

Uw automatisering is live, uw AI-model is getraind, uw integratie is verbonden — en de resultaten kloppen niet. Leads worden doorgestuurd naar de verkeerde salesmedewerker, facturen gaan de deur uit zonder btw-nummers, en de AI-aanbevelingsengine stelt vol overtuiging producten voor die u al twee jaar niet meer verkoopt. De schuldige is bijna nooit de software. Het zijn de gegevens die het systeem voeden. Dit artikel laat u precies zien hoe u datakwaliteit meet langs vijf kritieke dimensies, zodat u weet waarmee u werkelijk te maken heeft — voordat u automatiseert, integreert, of beslissingen overdraagt aan een algoritme.

Waarom is het meten van datakwaliteit belangrijk voordat u iets automatiseert?

De meeste organisaties ontdekken datakwaliteitsproblemen op de harde manier — nadat ze de automatisering al hebben gebouwd. Een warehouse management systeem gaat live en genereert meteen verkeerde picklijsten, omdat productcodes in het ERP niet overeenkomen met productcodes in het WMS. Een AI-model voor klantverloop wordt uitgerold en markeert de verkeerde klanten, omdat de helft van de velden 'laatste aankoopdatum' al 14 maanden niet is bijgewerkt. Dit zijn geen uitzonderingen. Het is de norm.

De oplossing is niet om data reactief op te schonen na elke mislukte uitvoer. Het is om eerst te meten, de omvang van het probleem te begrijpen en daarna gericht te reinigen. Meten geeft u een basislijn — een getal dat u kunt bijhouden, verbeteren en rapporteren. Zonder meting blijft 'datakwaliteit' een gevoel, geen feit.

Wat zijn de vijf dimensies van datakwaliteit die u moet meten?

Elk serieus datakwaliteitsraamwerk — van de DAMA-DMBOK tot ISO 8000 — organiseert kwaliteit rondom een beperkt aantal dimensies. Deze vijf zijn de meest relevante in de praktijk:

1. Volledigheid — Zijn alle verplichte velden ingevuld?
2. Nauwkeurigheid — Weerspiegelt de data de werkelijkheid?
3. Consistentie — Betekent dezelfde data overal hetzelfde?
4. Tijdigheid — Is de data actueel genoeg om bruikbaar te zijn?
5. Uniciteit — Wordt elke entiteit uit de werkelijkheid precies één keer vastgelegd?

Elke dimensie heeft zijn eigen meetmethode. Laten we ze één voor één doornemen.

Hoe meet u volledigheid?

Volledigheid meet het percentage verplichte velden dat daadwerkelijk een waarde bevat. Het klinkt eenvoudig — en de berekening is dat ook — maar het lastige deel is overeenstemming bereiken over wat 'verplicht' betekent in uw context.

Formule:

Volledigheid (%) = (Velden met een waarde ÷ Totaal verwachte velden) × 100

Praktisch voorbeeld: U exporteert uw CRM-contactrecords. Van de 4.200 contacten hebben 1.890 geen telefoonnummer, 640 geen bedrijfsnaam en 210 geen e-mailadres. Als telefoon, bedrijfsnaam en e-mail allemaal verplicht zijn voor uw uitgaande salesautomatisering, is uw volledigheidscore voor die workflow niet 100% — het is dichter bij 55%, en uw automatisering slaat stilzwijgend bijna de helft van uw records over of verwerkt ze foutief.

Hoe u het meet:

1. Definieer een veldniveau volledigheidseis voor elke tabel of object (bijv. "voor de tabel Contacten zijn deze 6 velden verplicht voor salesautomatisering").
2. Voer een query uit of maak een export die NULL-, lege of plaatshouderwaarden telt ("TBD", "onbekend", "0") per veld.
3. Bereken een volledigheidscore per veld en een overall score op recordniveau (welk percentage records is volledig ingevuld voor alle verplichte velden).
4. Markeer records die onder uw drempelwaarde vallen als 'niet klaar voor automatisering'.

Let op: Velden die er gevuld uitzien maar onzin bevatten — een telefoonnummerveld vol "000-000-0000" haalt een volledigheidscheck, maar zakt voor een nauwkeurigheidscheck. Combineer volledigheid altijd met validatieregels.

Hoe meet u nauwkeurigheid?

Nauwkeurigheid is de moeilijkste dimensie om programmatisch te meten, omdat het vereist dat u uw data vergelijkt met een externe bron van waarheid. Uit de data zelf kunt u niet afleiden of het adres van een klant echt is, of een productgewicht klopt, of een contracteinddatum correct is ingevoerd.

Praktische benaderingen:

• Adresvalidatie: Voer postadressen door een validatie-API (bijv. de adres-API van PostNL voor Nederlandse data, of de Google Maps API) en markeer records waarbij de straat, stad of postcode niet overeenkomt met een bestaande locatie. In een dataset van 3.000 klantrecords is het niet ongebruikelijk om 8–12% niet-afleverbare adressen te vinden.
• Vergelijking tussen systemen: Als zowel uw ERP als uw CRM de bedrijfsnaam van een klant opslaan, vergelijk ze dan. Afwijkingen wijzen op minimaal één onjuistheid — ook al kunt u niet altijd bepalen welk systeem fout zit.
• Steekproefgerichte handmatige audit: Voor velden waarvoor geen API-validatie mogelijk is (bijv. namen van contactpersonen, productomschrijvingen), trekt u een willekeurige steekproef van 100–200 records en verifieert u deze handmatig aan de hand van het brondocument, het klantenportaal of een telefoongesprek. Vervolgens extrapoleert u het foutpercentage naar de volledige dataset.
• Schendingen van bedrijfsregels: Definieer regels die altijd waar moeten zijn (bijv. "factuurdatum kan niet na de leverdatum liggen", "een klant met status 'actief' moet een contracteinddatum in de toekomst hebben") en tel de schendingen.

Formule:

Nauwkeurigheid (%) = (Records zonder gedetecteerde fouten ÷ Totaal geauditeerde records) × 100

Hoe meet u consistentie?

Consistentie meet of dezelfde data, opgeslagen op meerdere plaatsen, hetzelfde zegt — en of waarden hetzelfde formaat, dezelfde codering of hetzelfde vocabulaire volgen in al uw systemen.

Dit is de dimensie waarop integraties stranden. Een order wordt ingevoerd in FileMaker met landcode "NL", maar de logistieke API verwacht "Netherlands". Elke order, elke dag, mislukt stilzwijgend of wordt verkeerd gekoppeld. Niemand merkt het totdat pakketten naar het verkeerde land gaan — of totdat een dashboard dat orders per land aggregeert NL en Netherlands als twee afzonderlijke markten toont.

Wat u moet meten:

• Formaatconsistentie: Datumvelden opgeslagen als DD-MM-JJJJ in het ene systeem en JJJJ-MM-DD in het andere. Bedragen inclusief en exclusief btw door elkaar in hetzelfde veld. Telefoonnummers met en zonder landnummer, met en zonder spaties.
• Waardelijstconsistentie: "Actief", "actief", "ACTIEF" en "Active" betekenen allemaal dezelfde status — maar worden anders opgeslagen. Meet het aantal afzonderlijke varianten per veld met een gecontroleerde woordenlijst.
• Veldkoppeling tussen systemen: Voor elk veld dat in meer dan één systeem voorkomt, meet u het percentage records waarbij de waarde exact overeenkomt in alle systemen.

Formule:

Consistentie (%) = (Records waarbij alle waarden tussen systemen overeenkomen ÷ Totaal vergeleken records) × 100

Stap voor stap meten:

1. Breng elk veld in kaart dat in meer dan één systeem voorkomt (een 'veldinventaris' of datadictionary).
2. Exporteer voor elk gedeeld veld de waarden uit beide/alle systemen en koppel ze op een gemeenschappelijke sleutel.
3. Markeer afwijkingen en bereken een consistentiescore per veld.
4. Controleer voor formaatconsistentie binnen één systeem elk veld met reguliere expressies of patrooncontroles en tel de schendingen.

Hoe meet u tijdigheid?

Tijdigheid meet of uw data actueel genoeg is om bruikbaar te zijn voor de beslissing of het proces waarvoor het bedoeld is. Verouderde data is een van de meest onderschatte kwaliteitsproblemen — zeker voor AI-modellen, die slechts zo goed zijn als de actualiteit van hun trainings- en inferentiedata.

Praktisch voorbeeld: Een voorspellingsmodel voor klantverloop wordt getraind op klantactiviteitsdata. Het veld 'laatste inlogdatum' voor 34% van de gebruikers is al 18 maanden niet bijgewerkt sinds de CRM-migratie. Het model beschouwt die gebruikers als zeer betrokken (dat waren ze, 18 maanden geleden) en kent hen een laag verlooprisico toe. Uw customer success team negeert hen. Drie maanden later vertrekt 40% van hen.

Wat u moet meten:

• Dataversheid: Bereken voor tijdgevoelige velden (laatste contactdatum, voorraadniveau, contractstatus) de gemiddelde en maximale tijd sinds de laatste update. Definieer een aanvaardbare versheidsdrempel per veld (bijv. voorraadniveaus moeten binnen 24 uur worden bijgewerkt; contactrecords moeten minimaal jaarlijks worden beoordeeld).
• Updatefrequentie versus verwachte frequentie: Als uw integratie elk uur moet synchroniseren maar records laten hiaten zien van 6–8 uur, haalt uw tijdigheidsscore de norm niet — ook al zijn de gegevens zelf nauwkeurig.
• Beschikbaarheidstijd: Hoelang duurt het vanaf het moment dat een gebeurtenis plaatsvindt in de werkelijkheid tot het moment dat dit in uw systeem zichtbaar is? Voor realtime automatisering kan zelfs een vertraging van 4 uur een kritieke fout zijn.

Formule:

Tijdigheidsscore = % van tijdgevoelige records die zijn bijgewerkt binnen de gedefinieerde versheidsdrempel

Hoe meet u uniciteit (en detecteert u dubbele records)?

Uniciteit meet of elke entiteit uit de werkelijkheid — een klant, een product, een leverancier — precies één keer in uw dataset voorkomt. Dubbele records zijn een van de schadelijkste datakwaliteitsproblemen in de praktijk, met name voor automatisering en AI, omdat ze leiden tot dubbeltelling, gesplitste historieën en conflicterende updates.

Waarom duplicaten zo destructief zijn: Stel dat een klant twee records heeft in uw CRM — één van een import van beurslead en één van een handmatige invoer door sales. De automatisering stuurt hen twee keer een welkomstmail. Het AI-model verdeelt hun aankoophistorie over twee profielen en classificeert beide ten onrechte als klanten met lage waarde. De accountmanager weet niet welk record hij moet bijwerken, waardoor beide onvolledig blijven.

Hoe u duplicaten detecteert en meet:

1. Exacte overeenkomst: Tel records met identieke waarden in een sleutelveld (e-mailadres, btw-nummer, IBAN). Elk duplicaat in een theoretisch uniek veld is een duidelijke datakwaliteitsschending.
2. Fuzzy matching: Gebruik algoritmen voor tekenreeksgelijkenis (Levenshtein-afstand, Jaro-Winkler) om bijna-duplicaten te vinden: "Acme B.V." en "ACME BV" zijn vrijwel zeker hetzelfde bedrijf. Tools zoals OpenRefine, de Python-bibliotheek recordlinkage of ingebouwde fuzzy matching in FileMaker-scripts kunnen dit automatiseren.
3. Samengestelde sleutelkoppeling: Vergelijk combinaties van velden (voornaam + achternaam + postcode, of bedrijfsnaam + stad + telefoonnummer) om duplicaten te vinden die geen enkel afzonderlijk uniek veld delen.

Formule:

Uniciteit (%) = (1 − Dubbele records ÷ Totaal records) × 100

Benchmark voor deduplicatiesnelheid: In de meeste B2B CRM- en ERP-datasets die niet actief zijn gededupliceerd, komen duplicaatpercentages van 10–25% voor. Alles boven de 5% moet worden behandeld als een blokkade voor automatisering.

Hoe ziet een praktisch meetproces voor datakwaliteit eruit?

Hier volgt een stap-voor-stap aanpak die u daadwerkelijk kunt uitvoeren:

1. Definieer de scope: Kies de specifieke dataset en de specifieke use case (bijv. "klantrecords gebruikt voor de orderbevestigingsautomatisering"). Probeer niet alles tegelijk te meten.
2. Bouw een veldinventaris: Maak een lijst van elk veld binnen de scope. Definieer per veld: Is het verplicht? Wat is het verwachte formaat? Wat is het aanvaardbare waardebereik of de toegestane lijst? Wat is de versheidsdrempel?
3. Exporteer een representatieve steekproef (minimaal 500–1.000 records, of de volledige dataset als die minder dan 10.000 rijen bevat).
4. Voer geautomatiseerde controles uit op volledigheid (null-tellingen), consistentie (formaatschendingen, afwijkingen tussen systemen), uniciteit (exacte en fuzzy duplicaatdetectie) en tijdigheid (tijdstempels van laatste update versus drempelwaarden).
5. Voer een handmatige nauwkeurigheidsaudit uit op een willekeurige steekproef van 100–200 records.
6. Scoor elke dimensie met behulp van de bovenstaande formules. Combineer ze tot één enkele datakwaliteitsscore als u één getal nodig heeft om te rapporteren — een eenvoudig gemiddelde over de dimensies werkt, of weeg naar zakelijke impact.
7. Documenteer bevindingen in een datakwaliteitsrapport: scores per veld, grootste knelpunten, geschatte zakelijke impact (bijv. "14% van de orders zal de integratie niet doorstaan vanwege ontbrekende btw-nummers").
8. Stel verbeterdoelstellingen in en een datum voor hermeting. Meten zonder feedbackloop is slechts een momentopname.

Checklist voor datakwaliteitsmeting

Gebruik deze lijst vóór elk automatiserings-, integratie- of AI-project:

• Veldinventaris voltooid voor alle tabellen binnen de scope
• Verplichte velden gedefinieerd per use case
• Volledigheidscore berekend per veld en per record
• Nauwkeurigheid gevalideerd via API, vergelijking tussen systemen of handmatige audit
• Formaatconsistentie gecontroleerd (datums, telefoonnummers, landcodes, statuswaarden)
• Waardevergelijking tussen systemen uitgevoerd voor alle gedeelde velden
• Tijdigheidsdrempelwaarden gedefinieerd en versheid gecontroleerd per tijdgevoelig veld
• Duplicaatdetectie uitgevoerd (exacte + fuzzy matching)
• Scores per dimensie gedocumenteerd
• Minimale kwaliteitsdrempels vastgesteld vóór livegang
• Hermeting ingepland na opschoning

FAQ

Wat is een 'goede' datakwaliteitsscore? Er is geen universeel antwoord — het hangt af van de use case. Een medewerker die door een CRM bladert, kan leven met 80% volledigheid; een geautomatiseerd facturatieproces niet. Als vuistregel geldt: streef voor automatisering en AI naar 95%+ volledigheid en uniciteit, 90%+ consistentie, en definieer tijdigheidsdrempels per veld. Een nauwkeurigheid onder de 95% moet de livegang blokkeren voor elk financieel of compliance-gerelateerd proces.

Hoe vaak moet u datakwaliteit meten? Minimaal: vóór elk nieuw automatiserings- of integratieproject, en na elke grote datamigrratie. Bij voorkeur: continu, met geautomatiseerde monitoring die u waarschuwt wanneer scores onder de drempelwaarde zakken. Voor live productiesystemen die automatisering voeden, zijn maandelijkse steekproefcontroles het absolute minimum.

Kunt u AI gebruiken om datakwaliteit te meten? Ja — en dit wordt in toenemende mate praktisch toepasbaar. Large language models kunnen worden ingezet om semantische inconsistenties te detecteren (bijv. herkennen dat "Managing Director" en "CEO" waarschijnlijk naar dezelfde rol verwijzen), afwijkende waarden te markeren en validatieregels te genereren op basis van voorbeelden. Maar door AI ondersteunde kwaliteitsmeting vereist nog steeds een mens om te definiëren wat 'correct' betekent voor uw specifieke data en zakelijke context.

Wat is het verschil tussen datakwaliteit en data governance? Datakwaliteit is de meetbare staat van uw data op een bepaald moment. Data governance is het geheel van beleid, rollen en processen dat voorkomt dat kwaliteit in de loop van de tijd verslechtert. U heeft meting nodig om uw kwaliteitsniveau te kennen; u heeft governance nodig om het te handhaven. Dit artikel behandelt meting — governance is de volgende stap.

Heb ik speciale tools nodig om datakwaliteit te meten? Niet per se. Een goed gestructureerde SQL-query of een FileMaker-script kan de meeste volledigheids-, consistentie- en uniciteitsproblemen opsporen. Python (pandas, recordlinkage) is nuttig voor fuzzy matching en grootschalige analyses. Dedicated datakwaliteitstools (Talend, Great Expectations, Monte Carlo) voegen monitoring en waarschuwingen toe, maar zijn meestal overdreven totdat u meerdere productie-pipelines beheert. Begin met wat u heeft.

---

Datakwaliteit meten is altijd stap één — maar uw scores kennen is alleen nuttig als u er vervolgens op handelt. Als uw meting wijdverspreide ontbrekende velden, formaatafwijkingen of een duplicaatpercentage boven de 5% aan het licht brengt, beschrijft de praktische gids over hoe u datakwaliteit verbetert vóór automatisering of AI de opschoning- en governancestappen die daarop volgen. Als u te maken heeft met een specifiek integratie-, automatiserings- of AI-project waarbij datakwaliteit de bottleneck is, kan Loggix u helpen uw data te meten, op te schonen en te verbinden — of dat nu betekent het bouwen van een maatweroplossing in FileMaker, het ontwikkelen van API-integraties tussen uw systemen, of het uitstippelen van de juiste data-architectuur voordat u iets bouwt.