Een klant belt boos. De factuur klopt weer niet. De medewerker die de telefoon opneemt, doet wat iedereen zou doen: excuses maken, factuur corrigeren, klant tevreden de lijn af. Probleem opgelost. Tot er volgende week weer een klant belt, over een andere factuur, met dezelfde soort fout.

Dit patroon zie je in bijna elke organisatie. Niet omdat mensen lui zijn of niet nadenken, maar omdat het oplossen van het symptoom nu eenmaal sneller voelt dan het uitzoeken van de oorzaak. Een klacht wegwerken kost tien minuten. Uitzoeken waarom de fout steeds terugkomt kost een middag, en misschien nog geen antwoord.

Root Cause Analysis is de discipline om die tien minuten te laten voor wat ze zijn, en eerst te vragen: waarom gebeurt dit steeds weer? Niet één keer, maar net zo vaak als nodig is om bij de echte oorzaak uit te komen.

Wat Root Cause Analysis eigenlijk is

Terug naar die factuur. De medewerker corrigeert het bedrag: symptoom weg. Een goede Root Cause Analysis stopt daar niet, maar vraagt door. Waarom klopte de factuur niet? Omdat de verkeerde eenheidsprijs is ingevoerd. Waarom werd die verkeerde prijs ingevoerd? Omdat het prijzenoverzicht in het systeem verouderd was. Waarom was dat overzicht verouderd? Omdat niemand eigenaar is van het bijwerken ervan.

Daar zit de oorzaak: niet de medewerker die typte, maar een proces zonder eigenaar. Los je alleen de typefout op, dan ben je over drie weken weer bezig met dezelfde klacht, in een ander jasje.

Root Cause Analysis is dus geen tool in de zin van een formulier of een training. Het is een gewoonte: bij elk terugkerend probleem minimaal drie tot vijf keer "waarom" vragen, tot je bij een oorzaak bent die je daadwerkelijk kunt wegnemen.

Waarom dit lastiger is dan het klinkt

Psycholoog en Nobelprijswinnaar Daniel Kahneman beschreef het principe WYSIATI: what you see is all there is. Ons brein neemt genoegen met de eerste plausibele verklaring die zich aandient, en stopt daar met zoeken. Niet omdat die verklaring klopt, maar omdat hij beschikbaar is en het zoeken voelt als klaar.

Voor een leidinggevende betekent dit concreet: de eerste verklaring die een team geeft voor een probleem, is bijna nooit de echte oorzaak. Het is de verklaring die het snelst bovenkwam. "De medewerker was onoplettend" is zo'n verklaring: makkelijk te accepteren, niemand hoeft het systeem aan te passen, en volgende week is het probleem er weer.

Wie hier doorheen wil breken, moet het gesprek bewust vertragen. Niet vragen "wie heeft dit gedaan", maar "wat maakte het mogelijk dat dit gebeurde". Dat is een andere vraag, en die levert een ander soort antwoord op.

Stappenplan: zo pak je een Root Cause Analysis aan

1. Beschrijf het probleem feitelijk. Geen aannames, geen schuldvraag. Wat gebeurde er precies, wanneer, en hoe vaak al eerder?

2. Verzamel het team dat er middenin zat. Niet alleen de manager, maar de mensen die het probleem in de praktijk tegenkomen. Zij zien details die op een rapportage niet staan.

3. Stel vijf keer "waarom". Bij elk antwoord vraag je opnieuw waarom dat zo is, tot je bij een oorzaak komt die binnen jullie eigen invloed ligt, bijvoorbeeld een ontbrekende check, een onduidelijke rolverdeling of een verouderd systeem.

4. Toets de laatste "waarom" op houdbaarheid. Klopt deze oorzaak logisch met wat je feitelijk hebt vastgesteld in stap 1? Zo niet, ga een laag dieper of terug een stap.

5. Koppel één concrete tegenmaatregel aan de gevonden oorzaak. Geen actielijst van tien punten, maar één aanpassing die het probleem bij de wortel aanpakt.

6. Check na vier tot zes weken of het probleem inderdaad wegblijft. Zo niet, was de gevonden oorzaak niet de echte, en begin je de vijf-keer-waarom opnieuw.

Praktijkvoorbeeld: een zorginstelling met terugkerende medicatiefouten

Een verpleegafdeling van een middelgrote zorginstelling kreeg maandelijks meldingen van bijna-fouten bij medicatietoediening. De eerste reactie was voorspelbaar: extra alertheid vragen van het personeel, een geheugensteuntje op de deur van de medicijnkamer.

De meldingen bleven komen. Pas toen het team met een Root Cause Analysis ging werken, kwam er een ander beeld naar boven. Waarom gebeurden de bijna-fouten vooral rond 15.00 uur? Omdat dat het moment van de dienstwissel was. Waarom leidde de dienstwissel tot fouten? Omdat de overdracht van medicatiegegevens mondeling gebeurde, tussen twee drukke ploegen door. Waarom was er geen vast overdrachtsmoment? Omdat dat nooit als apart proces was ingericht, het gebeurde "er even tussendoor".

De oplossing bleek niet meer alertheid, maar een vast, rustig overdrachtsmoment met een vaste checklist. Binnen twee maanden daalde het aantal meldingen met ruim zeventig procent. Niet omdat het personeel opeens beter oplette, maar omdat de oorzaak van het probleem was weggenomen in plaats van het symptoom.

Root Cause Analysis vraagt geduld en discipline: het is makkelijker om een klacht af te handelen dan om vijf keer waarom te vragen. Maar elke keer dat je stopt bij het symptoom, koop je alleen tijd tot de volgende, bijna identieke klacht.

Wil je leren hoe je dit soort analyses structureel inzet in je team? In de Lean Green Belt opleiding leer je grondig oorzaken achterhalen in plaats van symptomen bestrijden. 👉 Bekijk de opleiding