De 5 waarom-methode is gebaseerd op een principe van iteratieve vraagstelling dat wordt toegeschreven aan Sakichi Toyoda, de oprichter van Toyota, in de jaren 1930. Bij een storing stelt men de vraag “waarom” op opeenvolgende wijze om van een zichtbaar symptoom naar een diepere oorzaak te komen. De tool wordt gebruikt in lean processen, kwaliteitsbeheer en in tal van industriële of organisatorische contexten.
Het cijfer vijf is een convenant, geen analyzeregel
De meeste presentaties van de 5 waarom-methode stellen het aantal iteraties vast op vijf. Dit convenant biedt een referentie, maar is niets wetenschappelijks. Recente analyses raden aan om te stoppen wanneer de keten een onderbouwde en controleerbare oorzaak bereikt, in plaats van precies vijf vragen te forceren.
Sommige problemen worden opgelost in drie stappen. Andere vereisen meer. Het forceren van een vijfde vraag wanneer de worteloorzaak al is geïdentificeerd bij de derde iteratie leidt vaak tot vage of cirkelvormige antwoorden, die niets bijdragen aan het corrigerende actieplan.
Omgekeerd, te vroeg stoppen omdat men een plausibel antwoord heeft bereikt, komt neer op het behandelen van een tussenliggend symptoom. Het relevante stopcriterium is dus geen teller, maar de aard van de geïdentificeerde oorzaak: is deze observeerbaar, verifieerbaar, en vooral, heeft het team de middelen om erop te handelen? Als het antwoord ja is, kan de keten stoppen. Om de methode op Nefa Blog te ontdekken, begeleidt een gedetailleerde gids elke stap van deze iteratieve logica.
Multifactoriële problemen: de structurele limiet van de 5 waarom-methode
De tool werkt goed wanneer een storing een dominante en relatief lineaire oorzaakketen volgt. Een kwaliteitsgebrek aan een onderdeel, een terugkerende machine storing, een vertraging in de levering door een enkele leverancier: in deze gevallen vordert de opeenvolging van “waarom” natuurlijk naar een identificeerbare worteloorzaak.
De feedback uit het veld divergeert op dit punt zodra het probleem voortkomt uit meerdere gecombineerde factoren. Wanneer een incident een tekort aan training, een zwakte in de controle en een tijdsdruk mengt, is een enkele lineaire keten niet voldoende om de oorzaken in kaart te brengen.
Er zijn dan twee opties:
- Meerdere takken van vraagstelling parallel volgen, wat de oefening verandert in een oorzakenboom en de collectieve leesbaarheid bemoeilijkt.
- De methode koppelen aan een Ishikawa-diagram of een analyse via een faalboom, die de interacties tussen technische, menselijke en organisatorische factoren beter structureren.
- Accepteren dat de tool niet geschikt is voor de situatie en overschakelen naar een robuustere methode voor het analyseren van worteloorzaken, zoals de Apollo-analyse of de TapRooT-benadering.
Het gebruik van de 5 waarom op een multifactoriëel probleem zonder deze voorzichtigheid leidt vaak tot het aanwijzen van een enkele oorzaak waar meerdere voorwaarden zijn samengekomen. Het actieplan dat daaruit voortvloeit, behandelt dan slechts een fractie van het probleem.
Verificatie van antwoorden: wat de waarom-keten niet bewijst
Een keten van “waarom” produceert een causaal verhaal. Dit verhaal kan coherent lijken zonder de werkelijkheid te weerspiegelen. Elke antwoord moet worden geconfronteerd met verifieerbare gegevens: registraties, metingen, directe observaties of bevestigde interviews.
Zonder deze verificatiestap loopt de analyse het risico een plausibele hypothese om te vormen tot een door consensus van het team geaccepteerde verklaring. De bevestigingsbias speelt hier een rol: zodra een groep een eerste antwoord formuleert, hebben de volgende iteraties de neiging om de genomen richting te bevestigen in plaats van deze in twijfel te trekken.
De organisatie worteloorzaak in plaats van de individuele fout
Een veelvoorkomende valkuil bij het toepassen van probleemoplossing met de 5 waarom is om terug te gaan tot een menselijke fout en daar te stoppen. “De operator heeft de procedure niet gevolgd” lijkt een worteloorzaak te zijn. In werkelijkheid zoekt een solide analyse naar de organisatorische voorwaarde die de fout mogelijk maakte of die niet heeft toegestaan deze te detecteren.
Onduidelijke procedure, gebrek aan dubbele controle, overmatige werkdruk, ontwerpfout van een formulier, ineffectieve kwaliteitscontrole: deze elementen zijn worteloorzaken waarop een bedrijf duurzaam kan ingrijpen. Het aanwijzen van een individu lost het probleem niet op, omdat dezelfde omstandigheden dezelfde fout zullen produceren met een andere operator.
Effectiviteitsvoorwaarden in bedrijven: team, gegevens en reikwijdte
De kracht van de tool komt voort uit zijn schijnbare eenvoud. Dezezelfde eenvoud wordt een risico wanneer de oefening zonder kader wordt uitgevoerd. Drie voorwaarden bepalen de kwaliteit van het resultaat.
De samenstelling van het team is net zo belangrijk als de methode zelf. De aanwezige personen moeten het betrokken proces kennen door directe observatie, niet alleen via een organigram. Een facilitator die elk antwoord herformuleert voordat hij de volgende “waarom” stelt, beperkt logische sprongen en emotionele antwoorden.
De antwoorden moeten gebaseerd zijn op gedocumenteerde feiten, niet op indrukken. Als het team geen gegevens heeft over een stap in het proces, is dat een signaal: deze gegevens moeten worden verzameld voordat de analyse wordt voortgezet, niet improviseren met een antwoord.
De reikwijdte van het probleem moet nauwkeurig worden gedefinieerd voordat de eerste “waarom” wordt gesteld. Een vage verklaring (“de kwaliteit is gedaald”) genereert uiteenlopende en onbruikbare causaal ketens. Een precieze verklaring beschrijft het defect, de locatie en de frequentie.
Continue verbetering en actieplan na de analyse
Het identificeren van een worteloorzaak levert geen resultaat op als de analyse niet leidt tot een geformaliseerd actieplan. Elke gevalideerde oorzaak vereist een corrigerende actie met een verantwoordelijke, een termijn en een opvolgingsindicator. Zonder deze traceerbaarheid blijft de oefening een intellectuele workshop zonder impact op het proces.
In een lean of continue verbeteringsaanpak maken de 5 waarom deel uit van een bredere cyclus. De analyse voedt een PDCA (Plan-Do-Check-Act) of een 8D-rapport afhankelijk van de context. De tool is geen eindpunt, het is een toegangspunt naar duurzame oplossingen.
De beschikbare gegevens laten niet concluderen dat de methode geschikt is voor alle omgevingen. In complexe digitale systemen of organisaties met sterke onderlinge afhankelijkheid bereikt ze snel haar schaalgrenzen. Het erkennen als een tool onder anderen, geschikt voor problemen met een dominante oorzaakketen, blijft de beste manier om er daadwerkelijk voordeel uit te halen.
