Root Cause Analysis in de productie: 5 Whys en fishbone in de praktijk

By Mirko Peters · 2026-11-11

Root cause analysis in de productie, stap voor stap: wanneer je de 5 whys of een fishbone-diagram gebruikt, hoe je een oorzaak verifieert, en een uitgewerkt stilstandvoorbeeld met cijfers.

Automatically translated with AI from the original post. Read the English original

Root cause analysis (RCA) vindt de onderliggende oorzaak van een probleem, zodat de oplossing voorkomt dat het terugkomt. In de productie zijn de gangbare hulpmiddelen de 5 whys en het fishbone-diagram. Dit artikel is bedoeld voor productiemanagers die lijnproblemen vandaag moeten oplossen en willen dat ze opgelost blijven. Je krijgt een duidelijke werkwijze, een gids om tussen de twee hulpmiddelen te kiezen, een uitgewerkt stilstandvoorbeeld met cijfers en een lijst met veelgemaakte fouten.

Belangrijkste punten

• Root cause analysis vindt de onderliggende oorzaak van een probleem, zodat de oplossing herhaling voorkomt in plaats van een symptoom te behandelen.
• Gebruik de 5 whys bij een duidelijke keten van oorzaak en gevolg, en een fishbone-diagram eerst wanneer meerdere oorzaken elkaar kunnen beïnvloeden.
• Elk waarom moet beantwoord worden met een waargenomen feit of gemeten gegevens, geen hypothese, en de oorzaak moet geverifieerd zijn voordat je actie onderneemt.
• Begin met de grootste verliezen, met een Pareto-overzicht, en geef voorrang aan de bottleneck, waar verloren tijd de hele lijn kost.
• Een oplossing is pas bewezen wanneer de controle laat zien dat het probleem niet is teruggekeerd, dus voer dit uit als een kleine PDCA-proef.

Wat is root cause analysis in de productie?

iSixSigma beschrijft root cause analysis als een manier om de onderliggende bron van een proces- of productfout te identificeren. Het raadt aan te beginnen met een feitelijke probleemstelling: het defecte product of proces, de waarnemingen, het aantal defecte stuks en de beschrijving van de klant. Zie hun artikel over Ishikawa-diagrammen en de 5 whys.

Drie begrippen worden makkelijk met elkaar verward:

• Containment beschermt de klant of de lijn vandaag, bijvoorbeeld door verdachte onderdelen te sorteren. Het verwijdert de oorzaak niet.
• Corrigerende maatregel is de wijziging die de oorzaak wegneemt.
• Root cause is de oorzaak die, wanneer je haar wegneemt, herhaling onder vergelijkbare omstandigheden voorkomt.

Als je alleen containment toepast, komt dezelfde fout of stilstand terug. Als je meteen naar een corrigerende maatregel springt zonder geverifieerde oorzaak, los je misschien het verkeerde op. RCA zit ertussenin.

Wanneer gebruik je de 5 whys?

Het ASQ-woordenboek beschrijft de Five Whys als een techniek waarbij herhaaldelijk de vraag "waarom?" wordt gesteld. Die wordt meestal ongeveer vijf keer toegepast, maar meer of minder is acceptabel, en de techniek wordt toegeschreven aan Sakichi Toyoda. De regels zijn praktisch:

1. Schrijf een precieze probleemstelling die op gegevens is gebaseerd.
2. Vraag waarom het probleem optrad en noteer de dichtstbijzijnde waarneembare oorzaak.
3. Blijf bij elk antwoord vragen waarom, en blijf gebaseerd op feiten.
4. Stop bij een oorzaak waarop je kunt ingrijpen om herhaling te voorkomen.
5. Verifieer de root cause: leidt ze tot het probleem, en zou het oplossen ervan het probleem voorkomen?
6. Pas een tegenmaatregel toe en bevestig met een vervolgmeting dat het probleem niet terugkomt.

Dezelfde pagina merkt op dat elk antwoord "een waargenomen feit of gemeten gegevenspunt moet zijn, geen hypothese". Er staat ook dat de methode het best werkt bij lineaire oorzakelijke ketens met één root cause, en dat voor complexe problemen een fishbone-diagram wordt aanbevolen.

Wanneer is een fishbone-diagram beter?

Een visgraatdiagram, ook wel Ishikawa-diagram genoemd, is een beeld van hypothesen. Het effect, zoals "korte shots op pers 3", staat bovenaan, en de zijtakken tonen mogelijke oorzaken. Teams groeperen de takken vaak in machine, methode, materiaal, mensen, meting en omgeving. Het diagram helpt het team veel mogelijke oorzaken tegelijk te zien en af te spreken welke ze gaan testen.

iSixSigma raadt een duidelijke manier aan om de tools te combineren: schrijf eerst de probleemstelling op en verzamel data, bouw het diagram op basis van hypothesen die waarneembare effecten beschrijven, pas de 5 whys toe op de meest waarschijnlijke takken, en volg elke hypothese met een eigenaar en een deadline. Ook waarschuwt het dat brainstormdiagrammen vaak oorzaken bevatten die niet bijdragen, en dat vage categorieën zoals "verlichting" zelden een weg naar het falen laten zien.

Vuistregel: een enkele, duidelijke keten betekent dat de 5 whys voldoende is. Meerdere mogelijke bijdragende factoren, of een team dat het oneens is, betekent eerst een visgraatdiagram.

Veel productieproblemen hebben meer dan één grondoorzaak. Een korte stilstand kan tegelijk komen door een versleten onderdeel, een ontbrekende controle en een gat in de training. Vraag bij het vaststellen van de grondoorzaak daarom of je één van de grondoorzaken hebt gevonden, of alle. Een probleem goed definiëren is de helft van het antwoord: een smalle formulering, zoals "stilstand op station 3 tijdens de nachtdienst", levert minder mogelijke oorzaken op dan een brede. Om de grondoorzaak van een terugkerend defect te bepalen, vergelijk je goede en slechte runs en noteer je wat verschilt. Voer vervolgens correctieve acties uit voor elke geverifieerde oorzaak, één voor één, zodat je ziet welke werkt. Dit is gewoon probleemoplossen: eerst feiten, dan hypothesen, en pas daarna acties.

Hoe voer je RCA uit op de lijn?

1. Indammen. Bescherm eerst de klant en de lijn. Zet verdacht product in quarantaine en herstel een veilige toestand.
2. Kies het probleem. Analyseer niet alles. Gebruik een Pareto-overzicht, een rangschikking van verliezen van groot naar klein, en pak de grootste aan. Kijk eerst naar de bottleneck, de stap die de output beperkt. Een minuut verlies daar is verlies voor de hele lijn, terwijl een minuut verlies op een stap met reservecapaciteit misschien niets kost.
3. Definieer het met data. Wat, waar, wanneer, hoeveel, vergeleken met wat? Zet er een getal op.
4. Ga kijken. Bekijk het echte proces op de gemba, het Japanse woord voor "de echte plek", de productievloer. Praat met de operators die erbij waren.
5. Zoek kandidaat-oorzaken. Gebruik de 5 whys of een visgraatdiagram met een cross-functioneel team: operator, onderhoud, kwaliteit en een supervisor.
6. Verifieer. Test de waarschijnlijke oorzaak. Als ze echt is, zou het wegnemen ervan de uitkomst moeten veranderen, en het weer invoeren zou het probleem weer moeten laten terugkomen.
7. Handel en controleer. Voer de tegenmaatregel uit als kleine proef en meet het resultaat. De PDCA-cyclus geeft deze stap zijn vorm, en een A3-rapport kan het hele verhaal op één pagina vastleggen.

Voorbeeld: stilstand op één lijn

Dit voorbeeld gebruikt aangenomen getallen.

Lijn 4 draait twee diensten van 8 uur, 5 dagen per week, dus 80 geplande uren. Vorige week verloor de lijn 14 uur aan stilstand, wat 14 ÷ 80 = 17,5% is.

Pareto van de stilstanden:

• Sensorfouten: 6,3 u (45%)
• Overschrijding omstelling: 4,2 u (30%)
• Wachten op materiaal: 2,1 u (15%)
• Overig: 1,4 u (10%)

De twee grootste oorzaken maken 75% van het verlies uit. Het team begint met de sensorfouten.

Five whys.

1. Waarom stopte de lijn? De sensor las de positie van het onderdeel verkeerd.
2. Waarom? Er zat stof op de lens van de sensor.
3. Waarom zat er stof? Niemand maakt de lens schoon tijdens de dienst.
4. Waarom niet? Schoonmaken maakt geen deel uit van de standaardwerkwijze van de operator.
5. Waarom niet? De standaardwerkwijze is geschreven voordat de sensor werd geïnstalleerd.

De grondoorzaak is een gat in de standaardwerkwijze, niet een defecte sensor. De tegenmaatregel is een lenscontrole toevoegen aan de routine aan het begin van de dienst en een klein kapje monteren.

Verwacht effect. Als dit 80% van de sensorstilstanden wegneemt: 6,3 × 0,8 = 5,04 uur. De nieuwe stilstand is 14 − 5,04 = 8,96 uur, oftewel 8,96 ÷ 80 = 11,2%. De controle na twee weken laat zien of het echte resultaat overeenkomt. Zo niet, dan keert het team terug naar het diagram.

Hoe weet je zeker dat de oorzaak de juiste is?

Toets de bevinding voordat je in een oplossing investeert. Twee eenvoudige vragen helpen:

• Als de oorzaak die je hebt vastgesteld anders was geweest, zou de uitkomst dan ook anders zijn geweest?
• Als je die oorzaak wegneemt, is het dan onwaarschijnlijk dat dezelfde storing zich onder vergelijkbare omstandigheden opnieuw voordoet?

Verzamel gegevens vóór en na de aanpassing. Een goede RCA eindigt met een gemeten resultaat en een aangepaste standaard, en zo voedt die analyse continue verbetering in plaats van brandjes blussen. Schrijf ook bijdragende factoren op die je niet hebt opgelost, zoals training of tooling, zodat ze niet verloren gaan.

Wees voorzichtig met "menselijke fout". Dat is zelden een grondoorzaak. Als een operator een fout heeft gemaakt, vraag dan waarom het proces die fout toeliet: was de instructie duidelijk, was het gereedschap geschikt, was er voldoende tijd? Het antwoord zit bijna altijd in het systeem.

Veelgemaakte fouten

• Stoppen bij de eerste waarom. Het eerste antwoord is meestal het symptoom.
• Antwoorden met meningen. Elke waarom heeft een waargenomen feit of een meting nodig.
• Mensen de schuld geven. Schuld geven beëindigt het gesprek en verbergt de echte oorzaak.
• Kleine problemen als eerste analyseren. Gebruik een Pareto-overzicht en begin met het grootste verlies.
• Verificatie overslaan. Een niet-geverifieerde oorzaak leidt tot een oplossing die niet werkt.
• De standaard niet aanpassen. Als de standaardwerkwijze hetzelfde blijft, komt het probleem terug.

Hoe software kan helpen

Goede analyse heeft goede data nodig. Software kan de reden van elke stilstand vastleggen op het moment dat die zich voordoet, automatisch Pareto-grafieken opbouwen en laten zien of een probleem terugkomt na de oplossing. Dat bespaart tijd in de eerste stappen van RCA en geeft het team feiten in plaats van herinneringen. Een tool denkt niet voor je. Mensen moeten nog steeds naar de gemba gaan en vragen waarom.

Volgende stap

Neem het grootste verlies van vorige week op je lijn, schrijf een probleemomschrijving met een cijfer erin en doorloop de 5 waarom's met de operators die erbij waren. Verifieer de oorzaak daarna met een kleine proef. Zo pas je root cause analysis in de praktijk op je productie toe.