Root cause analysis: pak de oorzaak, niet het symptoom

Root cause analysis is het verschil tussen een probleem dat wegblijft en een probleem dat steeds terugkomt. De verleiding is groot om het symptoom te bestrijden, maar dan dweil je met de kraan open.

In dit artikel zie je wat root cause analysis is, hoe de vijf keer waarom en het visgraatdiagram werken, en hoe je de echte oorzaak te pakken krijgt.

Het is de kern van de Analyze-fase in DMAIC.

Wat root cause analysis is

De grootste valkuil van verbeteren is het symptoom aanzien voor het probleem. Een klant klaagt dat een aanvraag lang duurt; je zet er meer mensen op; en een maand later is het weer raak, want de echte oorzaak, een omslachtige overdracht, zit er nog. Root cause analysis dwingt je door te graven tot je die oorzaak te pakken hebt.

De vijf keer waarom

De eenvoudigste techniek is de vijf keer waarom: je vraagt herhaald “waarom?” tot je voorbij het symptoom bij de oorzaak bent. Een voorbeeld:

• De aanvraag duurde te lang. Waarom? Hij bleef drie dagen liggen;
• Waarom? Hij wachtte op een document van de klant;
• Waarom? De klant wist niet dat hij het moest aanleveren;
• Waarom? Het formulier vroeg er niet duidelijk om.

Nu heb je iets om op te lossen: het formulier. Volgens ASQ is vijf een richtlijn, geen wet, soms ben je er na drie, soms na zeven. Het doel is de oorzaak, niet het aantal.

Het visgraatdiagram (Ishikawa)

Waar de vijf keer waarom een enkele lijn volgt, opent het visgraatdiagram, ook Ishikawa- of fishbone-diagram, de blik. Je tekent het probleem als de kop van een vis, en clustert mogelijke oorzaken langs de graten, per categorie: mens, methode, machine, materiaal, meting en omgeving.

Volgens ASQ voorkomt die categorie-indeling dat je je op één verdachte oorzaak blindstaart. Door systematisch elke categorie langs te lopen, ontdek je oorzaken die je anders had gemist. Het diagram is bovendien ideaal voor een werksessie: een team vult het samen, en dat maakt de analyse rijker.

Root cause analysis in de klantreis

In een klantreis koppel je root cause analysis aan een pijnpunt uit je emotiecurve. Klanten zijn gefrustreerd in de wachtfase, waarom? Met de vijf keer waarom of een visgraat graaf je van dat gevoelde probleem naar de interne oorzaak. Dit sluit direct aan op de line of visibility: de oorzaak van een zichtbaar klantprobleem zit vrijwel altijd onder de zichtbaarheidslijn, in het proces.

Valkuilen bij root cause analysis

De eerste valkuil is te vroeg stoppen en bij het symptoom blijven hangen. De tweede is bij de eerste plausibele oorzaak blijven staan zonder te toetsen of hij klopt, onderbouw je grondoorzaak met bewijs, niet met een onderbuikgevoel.

Een derde valkuil is de schuldvraag. Root cause analysis gaat over processen, niet over personen. Zodra het een zoektocht naar een zondebok wordt, stopt iedereen met eerlijk meedenken en verdwijnt de echte oorzaak uit beeld. Richt je op het systeem, niet op de mens.

Root cause analysis op een emotiedal

Root cause analysis komt het krachtigst tot leven wanneer je hem koppelt aan een concreet pijnpunt uit je journey. Stel: op je emotiecurve is de wachtfase het diepe dal. Klanten zijn daar gefrustreerd. In plaats van te gissen naar een oplossing, graaf je naar de oorzaak.

Je start met de vijf keer waarom. Waarom zijn klanten gefrustreerd in de wachtfase? Omdat ze niet weten hoe lang het duurt. Waarom weten ze dat niet? Omdat er geen statusupdate is. Waarom is die er niet? Omdat het systeem de status niet doorgeeft aan de klant. Waarom niet? Omdat die koppeling nooit is gebouwd. Nu heb je iets concreets: een ontbrekende koppeling, niet een vaag “klanten zijn ongeduldig”.

Wil je breder kijken, dan pak je het visgraatdiagram erbij en loop je de categorieën langs:

• Mens, weet de medewerker wel wat de status is?
• Methode, klopt het proces, of zitten er onnodige overdrachten in?
• Machine, geven de systemen de juiste informatie door?
• Meting, meten we überhaupt waar aanvragen blijven hangen?

Deze aanpak sluit aan op de line of visibility: het gevoelde probleem staat bóven die lijn (“het duurt lang”), maar de oorzaak zit eronder (een handmatige overdracht of een ontbrekende koppeling). Root cause analysis is precies het gereedschap dat je van boven naar onder brengt.

Voor een CJE is dit de brug van klacht naar oplossing. “Klanten zijn ontevreden” is een gevoel; “de oorzaak is een ontbrekende statuskoppeling” is een opdracht. Wie zijn squad dat tweede kan geven, geeft het team iets om te bouwen, en voorkomt dat er energie gaat naar het bestrijden van symptomen die telkens terugkomen.

Een laatste principe dat root cause analysis eerlijk houdt: het gaat over processen, niet over personen. Zodra een analyse verwordt tot een zoektocht naar een schuldige, stopt iedereen met eerlijk meedenken en verdwijnt de echte oorzaak uit beeld. Richt je dus altijd op het systeem, de stappen, de tools, de afspraken, en niet op de mens die er vastliep.

Onthoud de kern: stop pas als je bij een oorzaak komt die je daadwerkelijk kunt veranderen. “Menselijke fout” is geen eindpunt, want daar kun je niets mee; graaf door tot je iets beheersbaars raakt. Voor een Customer Journey Expert is root cause analysis het gereedschap dat een vage klacht omzet in een concreet, oplosbaar probleem. “Klanten zijn ontevreden” is een gevoel; “de oorzaak is deze ontbrekende koppeling” is een opdracht. Wie zijn squad dat tweede kan geven, voorkomt dat er energie weglekt naar symptomen die telkens terugkeren.

Wat dit betekent voor de CJE

Voor een Customer Journey Expert (CJE) is root cause analysis het gereedschap dat een klacht omzet in een oplosbaar probleem. Wie in zijn squad van “klanten zijn ontevreden” naar “de oorzaak is dit formulier” komt, geeft het team iets concreets om aan te werken. Dat doorgravende denken onderscheidt een CJE van iemand die alleen symptomen benoemt. Hoe je het inzet, lees je in Customer Journey Expert worden.