Root Cause Analysis

Wat is Root Cause Analysis?

Root Cause Analysis (RCA), in het Nederlands grondoorzaakanalyse, is een gestructureerde methode om de onderliggende oorzaak van een storing, incident of afwijking te vinden en weg te nemen, zodat hetzelfde probleem niet opnieuw optreedt. Waar een monteur een kapotte pomp vervangt en de lijn weer draait, vraagt RCA waaróm de pomp kapotging en waarom het systeem dat niet op tijd zag. In de industrie wordt RCA gebruikt voor machinestoringen, kwaliteitsafwijkingen, procesveiligheidsincidenten en steeds vaker voor cyberincidenten in de besturing.

🎯 Waarom is RCA meer dan een storing verhelpen?

Een storing verhelpen pakt het symptoom aan; RCA pakt de oorzaak aan. Het verschil ziet u terug in de cijfers: zonder RCA keren dezelfde storingen terug als ongeplande stilstand, en die drukt direct de beschikbaarheid in de OEE.

• Herhaling voorkomen — een correctieve maatregel op de grondoorzaak voorkomt een hele klasse van toekomstige storingen
• Leren als organisatie — bevindingen worden vastgelegd en gedeeld, niet alleen onthouden door de monteur van dienst
• Wettelijke verplichting — Seveso-inrichtingen moeten zware ongevallen en bijna-ongevallen onderzoeken, en entiteiten onder de Cyberbeveiligingswet moeten bij een significant incident de waarschijnlijke oorzaak rapporteren
• Prioriteren — RCA laat zien welke maatregel het meeste risico wegneemt, in plaats van alles tegelijk te willen oplossen

Een vuistregel: RCA is de moeite waard bij herhalende storingen, bij hoge impact (veiligheid, milieu, grote productieverliezen) en bij elk bijna-ongeval waarin een beschermingslaag faalde.

🧠 Welke niveaus van oorzaken onderscheidt RCA?

Een goede analyse stopt niet bij de eerste oorzaak die ze tegenkomt. Gangbaar is een indeling in drie lagen:

Alleen maatregelen op het latente niveau voorkomen herhaling op andere installaties. “Menselijke fout” is daarom nooit een eindpunt van een RCA, maar een beginpunt voor de vraag waarom het systeem die fout toeliet.

🔧 Welke RCA-methoden zijn er?

Er is niet één RCA-methode. Welke u kiest, hangt af van de complexiteit en de impact van het incident.

De 6M van het Ishikawa-diagram zijn Mens, Machine, Methode, Materiaal, Meting en Milieu. Fault tree analysis staat beschreven in IEC 61025, editie 2.0 uit 2006; een derde editie is in voorbereiding. Apollo-bedenker Dean Gano benadrukt dat er zelden één grondoorzaak bestaat: meestal moeten meerdere oorzaken tegelijk aanwezig zijn.

🛠️ Hoe voert u een RCA stap voor stap uit?

1. Beveilig en verzamel bewijs — leg historian-trends, alarmlogs, PLC-diagnosebuffers, foto’s en defecte onderdelen vast voordat iemand gaat herstarten of opruimen
2. Beschrijf het probleem feitelijk — wat, waar, wanneer, hoe groot; zonder schuldvraag
3. Stel een team samen — operator, onderhoud, procestechnoloog en bij digitale oorzaken ook OT-security
4. Bouw de tijdlijn en de oorzaakketen — met 5 Whys, een visgraat of een foutenboom, afhankelijk van de complexiteit
5. Toets elke oorzaak aan bewijs — een oorzaak zonder bewijs is een hypothese
6. Bepaal correctieve maatregelen per niveau — fysiek, menselijk en organisatorisch
7. Borg en controleer de effectiviteit — leg acties vast, wijs een eigenaar aan en meet na enkele maanden of het probleem echt weg is, bijvoorbeeld volgens PDCA

Uitgewerkt voorbeeld: PLC stopt na onverwachte firmware-update

Een verpakkingslijn valt ‘s nachts stil; de PLC staat in STOP. Een 5 Whys-analyse levert op:

De fysieke oorzaak is een incompatibele firmware, de menselijke oorzaak een ongeplande handeling, de latente oorzaak een ontbrekend wijzigingsproces voor OT-leveranciers. Alleen de laatste maatregel voorkomt herhaling op de andere lijnen.

🔄 Hoe hangt RCA samen met onderhoud, procesveiligheid en OT-security?

• Onderhoud — RCA is reactief, FMEA proactief: FMEA (IEC 60812, editie 2018) voorspelt faalwijzen vooraf, RCA analyseert wat er werkelijk misging en voedt de FMEA weer. Reliability Centered Maintenance volgens SAE JA1011 (1999) en predictive maintenance gebruiken die terugkoppeling om onderhoudsstrategieën bij te stellen. Ook een afwijkende meting kan de oorzaak zijn; controleer daarom de kalibratie van de betrokken instrumenten.
• Procesveiligheid — de Seveso III-richtlijn eist in bijlage III dat zware ongevallen en bijna-ongevallen, vooral als beschermende maatregelen faalden, worden onderzocht en dat lessen worden opgevolgd. Die eis gold in Nederland via het Brzo 2015 en staat sinds 2024 in de Omgevingswet; zie Brzo en cybersecurity. Het CCPS-handboek Guidelines for Investigating Process Safety Incidents (derde editie, 2019) is hiervoor het standaardwerk. Een falend SIS of een gemist HAZOP-scenario is een typische latente oorzaak.
• OT-security — bij incidentrespons is de post-incident review of lessons learned de RCA. Onder de meldplicht van de Cyberbeveiligingswet moet het eindrapport binnen een maand na de incidentmelding de soort dreiging of de waarschijnlijke grondoorzaak noemen. Forensisch onderzoek levert daarvoor het bewijs.

⚠️ Welke valkuilen komen vaak voor?

• Schuldcultuur — als RCA leidt tot het aanwijzen van een schuldige, verzwijgen mensen voortaan informatie en zijn toekomstige analyses waardeloos
• Stoppen bij “menselijke fout” — de vraag is waarom de fout mogelijk was en niet werd opgemerkt
• Te vroeg één oorzaak kiezen — de eerste plausibele verklaring wordt vaak niet meer getoetst
• Geen bewijs — logs worden overschreven en onderdelen weggegooid voordat de analyse begint
• Acties zonder opvolging — maatregelen blijven in een rapport staan zonder eigenaar of effectiviteitscontrole
• Overanalyseren — een volledige TapRooT-analyse voor een losgetrilde sensor kost meer dan de storing

RCA is ingebed in verbeteraanpakken als Lean en Six Sigma (de Analyze-fase van DMAIC). Software ondersteunt het werk: RealityCharting, TapRooT-software en RCA-modules in een CMMS of kwaliteitssysteem.

❓ Veelgestelde vragen

Wat is het verschil tussen RCA en FMEA?

Root Cause Analysis is reactief: RCA onderzoekt na een storing of incident waarom het misging. FMEA is proactief en analyseert vooraf welke faalwijzen kunnen optreden en hoe ernstig die zijn. Beide versterken elkaar, omdat de uitkomsten van een RCA ontbrekende faalwijzen in de FMEA aan het licht brengen.

Is 5 Whys genoeg voor een Root Cause Analysis?

De 5 Whys-methode is genoeg voor eenvoudige problemen met één duidelijke oorzaakketen. Bij complexe incidenten met meerdere samenwerkende oorzaken mist 5 Whys vaak zijtakken, en dan zijn een foutenboom, Apollo of TapRooT geschikter. Het getal vijf is een richtlijn: u stopt pas als u bij een beïnvloedbare systeemoorzaak bent.

Hoe lang duurt een Root Cause Analysis?

Een eenvoudige RCA met 5 Whys duurt vaak een uur tot een dag. Een volledige incidentanalyse na een procesveiligheidsincident of cyberaanval kan weken duren, omdat bewijs verzameld, mensen geïnterviewd en hypotheses getoetst moeten worden. Onder de Cyberbeveiligingswet moet het eindrapport binnen een maand na de incidentmelding de soort dreiging of de waarschijnlijke grondoorzaak van een significant incident noemen.

Wanneer moet u een Root Cause Analysis uitvoeren?

Een Root Cause Analysis is zinvol bij herhalende storingen, bij incidenten met veiligheids- of milieu-impact, bij grote productieverliezen en bij bijna-ongevallen waarin een beschermingslaag faalde. Veel bedrijven leggen drempels vast, bijvoorbeeld een RCA bij elke stilstand langer dan een vastgestelde duur.

Waarom is menselijke fout geen grondoorzaak?

Menselijke fouten zijn voorspelbaar en treden op binnen een systeem van procedures, training, ontwerp en werkdruk. Een Root Cause Analysis die eindigt bij menselijke fout, leidt alleen tot “opnieuw instrueren”, terwijl dezelfde fout bij een collega weer kan gebeuren. De RCA moet daarom vragen welke organisatorische of ontwerpfactor de fout mogelijk maakte.

Hoe gebruikt u RCA bij een OT-cyberincident?

Bij een OT-cyberincident is de Root Cause Analysis de post-incident review: hoe kwam de aanvaller of de ongeautoriseerde wijziging binnen, waarom werd het niet eerder gedetecteerd en welke maatregel faalde. Forensisch bewijs uit logs, netwerkverkeer en PLC-projecten vormt de basis. De uitkomst gaat in het eindrapport aan het CSIRT en de toezichthouder en in verbeteringen van segmentatie, toegangsbeheer en wijzigingsbeheer.

📌 Samengevat

Root Cause Analysis zoekt voorbij het symptoom naar de fysieke, menselijke en organisatorische oorzaak van een storing of incident, zodat het niet opnieuw gebeurt. Kies de methode op basis van complexiteit, van 5 Whys tot foutenboom en TapRooT, onderbouw elke oorzaak met bewijs en behandel menselijke fout als beginpunt, niet als eindpunt. Voor Seveso-inrichtingen en entiteiten onder de Cyberbeveiligingswet is incidentonderzoek naar de oorzaak bovendien een wettelijke verplichting.