Root cause en corrective action: zo doe je het goed
31 augustus 2026
Root cause en corrective action, kort door de bocht
Een correctie stopt het probleem nu. Een corrective action zorgt dat het niet terugkomt. Dat zijn twee verschillende dingen. In de praktijk wordt het eerste geregistreerd alsof het het tweede is.
Neem een oogdouche die een paar weken over de keuringsdatum heen is. De correctie is simpel: laten keuren. Dat kost een middag. De corrective action stelt de lastigere vraag: waarom heeft wekenlang niemand het gezien, en wat zorgt ervoor dat de volgende wel op tijd wordt gezien. Doe je alleen de correctie, dan heb je tijd gekocht, meer niet. Op een Seveso-inrichting is die verlopen oogdouche een overtreding. De prijs van het overslaan van stap twee is dus niet theoretisch.
Root cause en corrective action betekent: die twee stappen doen, in die volgorde, opschrijven, er een eigenaar bij zetten en een datum. Zo simpel zit het in elkaar. Het concept is het moeilijke deel niet. De discipline wel.
Waarom corrective actions niet blijven zitten
Dezelfde patronen komen op vrijwel elke locatie terug. En het gaat zelden over mensen die het niet belangrijk vinden:
- De bevinding wordt gesloten, niet de oorzaak. In het systeem staat "afgehandeld". Wat er is afgehandeld, is het symptoom.
- De root cause is opgeschreven als een persoon. De analyse stopt bij "operator heeft de procedure niet gevolgd". Daarmee is de vervolgactie een gesprek geworden, geen verandering.
- De actie is een document. Een alinea toevoegen aan een procedure voelt als een oplossing. Op de werkvloer leest niemand hem, dus er verandert niets.
- De werklast was nooit realistisch. Een checklist van vier pagina's met twee uur om een grote installatie rond te lopen, dat kan gewoon niet. De root cause is het ontwerp van de checklist, niet de inspecteur.
- De kennis is de deur uitgelopen. Een ervaren techneut heeft het drie jaar geleden mondeling uitgelegd. Die persoon werkt er niet meer, het is nooit vastgelegd, en nu ligt er ineens een overtreding.
- De wijziging heeft de documentatie nooit bereikt. In het veld is iets aangepast. Het veiligheidsrapport en het VBS beschrijven nog de oude situatie. Er is geen MOC aangelegd.
Die laatste is de dure variant. We moeten schrijven wat we doen en we moeten doen wat we schrijven. Zodra die twee uit elkaar lopen, vindt een inspectie het gat eerder dan jij.
Vijf stappen die wel tot een echte fix leiden
1. Schrijf op wat er gebeurd is, niet wat er had moeten gebeuren
Eerst feiten, in de woorden van de mensen die erbij waren. Tijd, locatie, installatiedeel, wat er is waargenomen. Oordeel hoort hier niet thuis. Staat er in je beschrijving al "heeft nagelaten om", dan ben je naar de conclusie gesprongen.
2. Vraag door tot je bij iets komt waar je zelf over gaat
Vijf keer waarom, een visgraat, een bowtie. De techniek doet er minder toe dan het stopcriterium. Je stopt op het moment dat je bij iets uitkomt dat je organisatie kan veranderen: een frequentie, een ontwerp, een opleiding, een grenswaarde, een formulier, een eigenaarschap dat nergens belegd is. Kom je uit bij "menselijke fout", dan ben je er nog niet. Kom je uit bij "het regende", ga dan een stap terug en vraag waarom die regen uitmaakte.
3. Splits de correctie en de corrective action, op papier
Twee regels in je registratie, geen één. Correctie: oogdouche laten keuren, afdichting vervangen, barrière herstellen. Corrective action: keuringsinterval aanpassen, de checklist herontwerpen naar de tijd die er echt is, het middel opnemen in het onderhoudssysteem. Verschillende eigenaren mag. Verschillende deadlines is normaal.
4. Geef het een eigenaar, een datum en het bewijs dat je wilt zien
Geen afdeling. Een naam. En spreek vooraf af hoe bewijs van afronding eruitziet: een foto, een getekende werkorder, een herziene procedure met versienummer, een presentielijst van een toolbox. Leg je dat nu niet vast, dan wordt afsluiten later een mening. Een template voor een corrective action plan helpt vooral omdat het je dwingt die velden te hebben.
5. Toets de effectiviteit later, en bewust
Dit is de stap die bijna iedereen overslaat. Een actie sluiten is niet hetzelfde als weten dat hij gewerkt heeft. Zet een controle uit op drie of zes maanden: is dezelfde categorie bevinding teruggekomen, worden de nieuwe rondes daadwerkelijk afgerond, wordt de herziene procedure ook echt gevolgd. Is het antwoord nee, dan klopte de analyse niet en open je hem opnieuw. Dat is geen falen van het proces. Dat is het proces.
Hoe een bruikbare root cause eruitziet
Een root cause is pas bruikbaar als de corrective action er vanzelf uit volgt. Vergelijk:
- "Onvoldoende veiligheidsbewustzijn." Hier volgt geen enkele actie uit.
- "In één ronde over een grote installatie zitten twaalf ongerelateerde typen controlepunten door elkaar, waardoor onder tijdsdruk punten wegvallen." De actie volgt direct: splits die ronde.
Toezichthouders in Nederland, of dat nu de Nederlandse Arbeidsinspectie is of een omgevingsdienst als DCMR, formuleren vaak een direct oordeel in plaats van "het is onvoldoende aantoonbaar dat". Juist daarom is het de moeite waard om de discussie over feiten te voeren en niet over interpretatie. Een vastgelegde root cause met gedateerd bewijs erachter is een feitelijke positie. "Wij hebben het opgepakt" is dat niet.
Waar software helpt, en waar niet
Software is goed in de saaie helft. Hij zet een tijdstempel op de bevinding, houdt de correctie en de corrective action als twee aparte items uit elkaar, blijft achter de eigenaar aan zitten, bewaart het bewijs naast de actie, en laat de effectiviteitstoets over zes maanden op iemands lijst verschijnen in plaats van stilletjes verdwijnen. Daar is corrective and preventive action software voor, en dat is echt winst ten opzichte van een Excel sheet die door één persoon wordt bijgehouden.
Wat het niet doet, is de analyse. Het kan je niet vertellen waarom jouw checklist niet te lopen is. Het maakt je niet compliant en het neemt het eigenaarschap van jouw beheerssysteem niet over. In Capptions hangen corrective actions aan de inspectie of audit waar ze uit voortkwamen, en Clara kan signaleren dat een wijziging er uitziet als iets dat een MOC-beoordeling verdient. Niet elke wijziging is MOC-waardig, en wat Clara naar boven haalt moet nog steeds door een mens beoordeeld worden. Generieke tools lopen meestal precies daar vast waar het gereguleerde detail begint, en dat is een langer verhaal: waarom generieke safety management software tekortschiet voor Seveso III-bedrijven.
Zit je nu vooral met één concrete overtreding en niet met het systeem eromheen, dan is de kortere route corrective action bij een veiligheidsovertreding.
Een korte, eerlijke volgende stap
Pak je laatste tien gesloten bevindingen erbij. Kijk per stuk naar twee dingen: staat er een root cause die gaat over iets waar jij over gaat, en staat er een verificatiedatum ná de afsluitdatum. Tel hoeveel er beide hebben.
Wat dat getal ook is, het zegt je meer dan welke softwaredemo dan ook. Is het laag, dan zit de fix in het proces en nog niet in tooling. Is je proces op orde en is de opvolging het stuk dat blijft omvallen, dan is dat een kleiner en beter oplosbaar probleem, en daar kijken we graag met je naar.