Het gesprek gaat over welk model je gaat gebruiken. Over of het self-hosted moet. Over welke koppeling je nodig hebt. Zes weken later blijkt het probleem te zijn dat dezelfde klant in je systeem vier keer voorkomt.
Dit is verreweg het meest voorkomende patroon in gestrande automatiseringsprojecten, en het is ook het minst besproken — omdat het saai is. Datakwaliteit verkoopt geen demo. Er is geen leverancier die er een aantrekkelijk verhaal van kan maken.
Toch is dit de laag waar de meeste projecten werkelijk sneuvelen. Niet spectaculair, maar geleidelijk: het werkt in de test, het werkt bij de eerste tien gevallen, en dan begint het aantal uitzonderingen te groeien tot iemand voorstelt om het maar weer handmatig te doen.
Wat het onderzoek werkelijk zegt
Drie cijfers die vaak in één adem worden genoemd
95%
van de zakelijke GenAI-pilots levert geen meetbaar rendement op de winst-en-verliesrekening. De onderzoekers wijzen op een learning gap: de tools worden niet in de werkprocessen geïntegreerd.
40%+
van de agentic AI-projecten wordt vóór eind 2027 geannuleerd — door oplopende kosten, onduidelijke bedrijfswaarde of ontoereikende risicobeheersing.
1 op 6
Nederlandse bedrijven gebruikt AI, een verdubbeling in twee jaar. Het probleem raakt dus steeds meer organisaties.
Bron: MIT NANDA, The GenAI Divide: State of AI in Business 2025, augustus 2025 — 300 implementaties, 150 leidinggevenden. Gartner, persbericht 25 juni 2025. CBS, 2025.
Waarom ik deze cijfers met tegenzin noem
Die 95 procent is het meest misbruikte getal in dit vakgebied. Het wordt gebruikt als bewijs dat AI niet werkt, en dat staat er niet.
- Het meet geen aantoonbaar rendement, niet ‘mislukt’. Veel pilots werden nooit gemeten — dan kún je geen rendement aantonen.
- Het gaat over generatieve AI-pilots, niet over workflow-automatisering. Een flow die facturen inboekt is iets anders dan een chatbot-experiment.
- Het is geen Gartner-cijfer, hoewel het meestal in één zin met de 40-procentvoorspelling wordt genoemd. Twee onderzoeken, twee onderwerpen, twee methodes.
Wie deze cijfers aan je presenteert zonder dat onderscheid, heeft ze niet gelezen. Ik noem ze omdat de verklaring deugt, niet het percentage: het probleem zit onder de technologie, niet erin.
De vier vormen van rommel
Datakwaliteit klinkt abstract. In de praktijk is het vier concrete dingen, in volgorde van hoe vaak ik ze tegenkom.
1 — Dezelfde entiteit, meerdere keren
De klassieker. Jansen Techniek BV, Jansen Techniek, Jansen techniek b.v. en Jansen T. zijn hetzelfde bedrijf en vier records. Een mens ziet dat meteen. Software ziet vier klanten, verdeelt de omzet over vier regels en stuurt vier herinneringen.
Dit ontstaat vrijwel altijd op dezelfde manier: iemand kon een bestaand record niet vinden en maakte een nieuw aan. Het is geen slordigheid, het is een zoekfunctie die niet goed genoeg was.
2 — Lege velden die het proces nodig heeft
Je flow heeft het KvK-nummer nodig om de factuur te routeren. In 60 procent van je records staat het. Bij de overige 40 procent stopt de flow — of erger, gaat hij door met een aanname.
De vraag die je vooraf moet stellen is niet hebben we dit veld? maar hoe vaak is het gevuld, en klopt wat erin staat? Dat verschil kost een half uur om te controleren en voorkomt weken vertraging.
3 — Velden die verkeerd gebruikt worden
Dit is de gemeenste, omdat je hem niet ziet aankomen. Het veld opmerkingen bevat bij sommige klanten de leveringsvoorwaarden, bij andere de naam van de contactpersoon, en bij weer andere een notitie uit 2019.
Zoiets ontstaat wanneer een noodzakelijk veld ontbrak en iemand een praktische oplossing zocht. Dat werkt jarenlang prima, want mensen begrijpen context. Software niet. Elke automatisering die op zo’n veld leunt, is een automatisering die soms iets heel anders doet dan bedoeld.
4 — Gegevens die niet meer kloppen
Adressen van verhuisde klanten, contactpersonen die er niet meer werken, prijsafspraken die zijn verlopen. Verouderde data is gevaarlijker dan ontbrekende data, want ontbrekende data merk je — verouderde data levert een keurig, volledig en verkeerd resultaat op.
Voorbeeld: de flow die op 40 procent bleef steken
VOORBEELD 1
De situatie. Een groothandel wilde inkoopfacturen automatisch laten matchen met inkooporders. Ongeveer 400 facturen per maand, twee systemen, een proces met vaste stappen. Op papier een ideale eerste flow.
De aanpak. De flow werd gebouwd en getest op een set van vijftig recente facturen. Daarvan matchten er achtenveertig — 96 procent. Groen licht voor productie.
Het resultaat. In de eerste volle maand matchte 61 procent. De oorzaak lag niet in de flow maar in de testselectie: die bestond uit recente facturen van vaste leveranciers, waar de gegevens goed onderhouden waren. De werkelijke stroom bevatte ook kleine en incidentele leveranciers, en juist daar ontbrak het inkoopordernummer of stond de leveranciersnaam anders geschreven dan in het inkoopsysteem.
Wat er tegenvalt. Er is drie weken verloren gegaan aan het zoeken naar een technische oorzaak die er niet was. De oplossing was uiteindelijk saai: 180 leveranciersnamen eenmalig normaliseren en een regel inbouwen die facturen zonder ordernummer meteen naar een mens stuurt in plaats van te proberen te matchen. Daarna liep het naar 89 procent.
Rekenvoorbeeld op basis van gangbare MKB-volumes, geen klantcase. In de scan rekenen we jouw cijfers door.
De les uit dat voorbeeld
Test nooit op je nette data. Neem een willekeurige greep uit een volle maand, inclusief de rommelige gevallen, de kleine leveranciers en de uitzonderingen. Een testset die 96 procent scoort en een productie die 61 procent haalt, is geen technisch probleem — het is een steekproef die niet representatief was.
Vuistregel: als je testresultaat mooier is dan je verwachting, heb je waarschijnlijk de verkeerde gevallen getest.
Wat je doet zonder eerst alles op te ruimen
Het advies ‘zorg eerst dat je data op orde is’ is technisch juist en praktisch onbruikbaar. Geen enkel MKB-bedrijf heeft zijn hele administratie op orde, en wachten daarop betekent nooit beginnen.
De werkbare aanpak keert het om: ruim alleen op wat dit ene proces nodig heeft.
- Bepaal welke velden de flow werkelijk gebruikt. Meestal zijn dat er vijf tot tien, niet vijftig. Alle andere velden mogen rommelig blijven.
- Meet de vulgraad van die velden. Eén query per veld. Onder de 90 procent gevuld wordt het een aandachtspunt; onder de 70 procent wordt het je eerste taak.
- Zoek dubbelingen in de sleutelvelden. Klantnaam, leveranciersnaam, artikelnummer. Dit is het werk dat het meeste oplevert per bestede uur.
- Ruim alleen die velden op. Eenmalig, met de hand of half geautomatiseerd. Voor een paar honderd records is dit een dag werk.
- Voorkom herhaling bij de bron. Een verplicht veld in het invoerscherm is effectiever dan elk opruimproject achteraf.
Stap vijf is de enige die blijvend werkt. De eerste vier zijn onderhoud; die vijfde is de reparatie.
FLOW 1
Meten voordat je bouwt
Voor wie: Elke organisatie die een automatisering overweegt op bestaande gegevens.
Wat het oplevert: Binnen een dag weet je of je fundament draagt. Dat is de goedkoopste dag van het hele project.
Let op: Willekeurig betekent écht willekeurig. Niet de laatste 200, niet die van je grootste klant — dat zijn precies de records die er het best uitzien.
Wanneer datakwaliteit niet je probleem is
- De flow werkt met gegevens die binnenkomen, niet met bestaande. Een flow die inkomende e-mail sorteert, heeft je klantbestand niet nodig.
- Je werkt met één systeem dat de gegevens zelf valideert. Dan is de kwaliteit al afgedwongen bij de invoer.
- Het proces is nieuw. Bouw je iets wat er nog niet was, dan is er geen historie om over te struikelen — richt het dan meteen goed in.
In alle andere gevallen: besteed die ene dag aan meten. Ik doe dat standaard vóór de prijsopgave, omdat de uitkomst de prijs bepaalt.
Wie is de eigenaar?
Eén vraag die zelden wordt gesteld en die bepaalt of het beklijft: wie is verantwoordelijk voor de kwaliteit van dit gegeven?
Niet ‘de organisatie’ en niet ‘iedereen’. Eén naam per gegevenssoort. Wie is er verantwoordelijk voor dat leveranciersgegevens kloppen? Wie voor artikelnummers?
Zonder aangewezen eigenaar verslechtert elke opgeschoonde dataset binnen een jaar weer tot het oude niveau. Dat is geen gebrek aan discipline, dat is hoe gedeelde verantwoordelijkheid nu eenmaal werkt: wat van iedereen is, is van niemand.
Kort samengevat
- Projecten stranden zelden op de techniek. Ze stranden op het fundament eronder.
- De 95 procent uit het MIT-onderzoek meet geen mislukking maar het ontbreken van aantoonbaar rendement — en wijst naar integratie, niet naar modellen.
- Ruim niet alles op. Ruim op wat dit ene proces nodig heeft.
- Test op een willekeurige greep uit een volle maand, niet op je nette data.
- Wijs per gegevenssoort één eigenaar aan, anders verslechtert het weer.
