ENGINEERINGNET.BE - Neen, de bedoeling was om elk probleem definitief van de baan te helpen door steeds verder te blijven zoeken naar de onderliggende oorzaak en deze te elimineren.
Geen weldenkend mens natuurlijk die iets tegen deze werkwijze kan hebben. De vraag is alleen een beetje, hoe doe je dat nu?
RCFA, root cause failure analysis, is wel al vaker aan bod gekomen in deze column, maar omdat we (enfin, ik toch in elk geval) momenteel weer overspoeld worden met artikels over RCA-tools, rapporten met tips & tricks en aankondigingen over opleidingen inzake RC(F)A, leek me toch dat ook hier RCA weer eens mocht genoemd worden.
Even de puntjes op de i zetten: niettegenstaande er duizend-en-één definities over RCA te vinden zijn die allemaal de nadruk net iets anders leggen, zijn er toch wel een aantal gemeenschappelijke factoren, de spreekwoordelijke uitzonderingen even buiten beschouwing gelaten.
Een eerste belangrijk punt heeft te maken met het startpunt: RCA werkt retrospectief en niet proactief, je vertrekt vanuit een incident of probleem waarvoor een oplossing gezocht wordt.
Wat betreft de uitvoering, wordt gehamerd op een liefst multidisciplinair team, geleid door een ervaren facilitator en gesteund door management.
Het proces moet gestructureerd zijn: er moet een goede voorbereiding zijn, de analyse zelf moet zorgvuldig gebeuren, de rapportering moet helder zijn en de implementatie van de aanbevelingen moet formeel opgevolgd worden.
Deze implementatie is belangrijk. Een degelijke RCA kost tijd en moeite, als de betrokkenen dan zien dat er niets gebeurt met de resultaten zal dat de toekomstige RCAs ondermijnen.
Er blijft natuurlijk het data-probleem, waar we het hier ook al dikwijls over hadden. Ongeveer elk artikel of rapport over RCA drukt op het belang van 'evidence-based' te werken, met feiten gehaald uit logs en uit databases van het maintenance-systeem.
Dat betekent niet dat luisteren naar de betrokkenen niet belangrijk is, integendeel. Maar het betekent wel dat 'hear say' en indianenverhalen (zouden) moeten ondersteund worden door cijfers.
Dat leidt vaak tot frustratie wegens het teveel tijd moeten spenderen aan het graven in een onoverzichtelijke filestructuur of aan het combineren van verschillende databases.
En ja, we moeten toegeven, soms zijn die data gewoonweg niet beschikbaar, door slordige rapportering of omdat dat stukje data nu eenmaal niet bijgehouden wordt.
Het gaat dus vaak niet over geavanceerde data mining, maar over simpelweg het capteren van de juiste data. Dat dit laatste planning en inzicht vraagt, moet niet herhaald worden.
Voor de analyse zelf zijn er heel wat tools ter beschikking gaande van eenvoudige 5WHYs, Ishikawa-diagramma’s, Pareto-watervallen tot meer geavanceerde technieken als barrier analysis, CRT (current reality trees) of FMEA (failure mode effect analysis).
Wat je best kiest, hangt af van de situatie. Hoe gebruiksvriendelijk is de tool in kwestie? Is er extra training nodig? Is het sop de kolen waard, m.a.w. is het probleem belangrijk genoeg om er een RCA-analyse voor op te zetten?
Hoe goed is de tool, kan de tool om met bv. afhankelijkheden tussen potentiële oorzaken? Wat verwacht je: enkel de oorzaak vinden (cfr 5WHYs) of ook ineens al een stap kunnen zetten naar een remedie (cfr FMEA)? Stimuleert de tool discussie?
Draagt de RCA bij tot kennisopbouw binnen de onderhoudsdienst? Is de tool voldoende flexibel? Is er voldoende ervaring om de tool verstandig toe te passen?
’t Is zo’n beetje het verhaal van de GPS. Een GPS is een fantastisch hulpmiddel, maar als je die altijd slaafs volgt, kun je wel eens proberen een niet-bestaande brug op te rijden.
Hier en daar biedt de literatuur wel wat schema’s om je te helpen in de keuze. Het is ook belangrijk voldoende open te staan voor nieuwe tools, je kent het gezegde toch: voor wie enkel een hamer kent, ziet alles er uit als een nagel.
Maar genoeg gereflecteer en gefilosofeer, waar het uiteindelijk op aankomt, is dat RCA werkt in de praktijk, in die specifieke situaties waar het voor aangewend wordt. Uiteindelijk geldt 'the proof of the pudding is in eating it' (William Camden, 1605). Je kunt pas zien of je aanpak werkt, als je er echt voor gaat. Succes!
Liliane Pintelon is professor aan de KU Leuven. Ze is auteur van o.a. het boek 'Asset management: the maintenance perspective'.
