RCM is ontwikkeld tussen 1960 en 1978. Nowlan en Heap gebruikten de mogelijkheden om het storingsgedrag te beschrijven in structuren die al bestonden. Boeing had in de jaren 40 al de FMEA ontwikkeld, waar later criticality aan werd toegevoegd, zodat het FMECA werd.
In de RCM ontwikkeling is nauwkeurig geanalyseerd welk type FMEA of FMECA gebruikt zou moeten worden om onderhoudsconcepten te ontwikkelen voor hoog kritische systemen. Er was al een Object FMEA, Process FMEA, Design FMEA die ook als FMECA werden toegepast. Sommige bedrijven misbruikten de FMEA en FMECA door veel andere zaken er aan toe te voegen. Dat werd niet veel beter toen iedereen de beschikking kreeg over Excel.
De FMEA is standaard geïntegreerd in RCM stappen 1-2-3-4. In stappen 5-6-7 van RCM gebruiken we de informatie uit de FMEA om het onderhoudsconcept te ontwikkelen. Dat wordt gedaan met een beslissingsstrategie, waarin criteria zijn vermeld om de juiste onderhoudskeuzes te maken en de juiste onderhoudsintervallen te berekenen.
De FMEA is een Failure Mode Effect Analyse. Het is een structuur om het actuele storingsgedrag in vast te leggen. Dat kan oppervlakkig met een Object FMEA of zeer gedetailleerd met een Process FMEA. Beiden kunnen uitgebreid worden met Criticality, waardoor de FMECA structuur ontstaat. De Design FME(C)A wordt niet vaak gebruikt om onderhoudsconcepten te ontwikkelen.
Onderhoud beïnvloedt storingsgedrag. Andersom is storingsgedrag de basis van professionele onderhoudsprogramma’s. Iedere onderhoudstaak moet een deel van het storingsgedrag afdekken. Iedere onderhoudstaak dekt daarmee Failure Modes af. Als er een modificatie is doorgevoerd, waardoor bepaalde failure modes niet meer kunnen voorkomen, dan is de bijbehorende onderhoudstaak ook niet meer nodig. Storingsgedrag en onderhoudsconcepten/-plannen/-programma’s zijn logisch aan elkaar verknoopt. Dat is nog niet bij alle bedrijven op zijn plek gevallen. Ik zie nog vaak dat veel onderhoudsplannen alleen gekoppeld zijn aan assets en niet aan het storingsgedrag van onder andere die assets. Die bedrijven hebben nog een weg te gaan. Asset management lijkt dan redelijk op orde. Met Reliability Management tools kan dan de volgende stap worden gezet.
Het belangrijkste aan iedere FMEA is die FM (Failure Mode). Het type FMEA of FMECA dat wordt gebruikt, heeft er alleen mee te maken welke route gebruikt wordt om de lijst met Failure Modes te maken. Ongeacht welk type FMEA je gebruikt, is het doel van iedere FMEA altijd om een overzicht te creëren van de actuele Failure Modes (FM) met bijbehorende Failure Effects. Failure Modes zijn storingsvormen. Dat is wat anders dan storingen. Een storing is een verzameling storingsvormen. Een storing aan je auto kan zijn: “Band leeg”. Je hebt er meestal nog 3, maar met een lege band functioneert de auto toch niet naar behoren. De root causes van de storing “Band leeg” kunnen bijvoorbeeld zijn:
Een storing inclusief de achterliggende oorzaak (root cause of grondoorzaak) is de Failure Mode of storingsvorm. Sommigen gebruiken ook de term faalmechanisme. Iedere goede FME(C)A beschrijft Failure Modes en van iedere failure mode ook de failure effects.
De Object FMEA is populair, simpel en snel. En daarmee oppervlakkig en incompleet. Er komt zeker een werkbare lijst van Failure Modes uit, maar de lijst zal niet compleet zijn. Het niveau van 80/20 wordt niet gehaald. Als op basis daarvan onderhoudsconcepten worden gemaakt, zal dat onderhoudsconcept ook incompleet zijn. Er blijft dus een deel Failure Modes over dat niet wordt onderhouden. Die kosten geld, kwaliteit, veiligheid, milieu of blijven verborgen.
Storingsgedrag is de root cause van efficiency verliezen. Hebben we hoog kritische systemen, dan gaat de voorkeur uit naar een Process FMEA. Daar komt een veel betere en completere lijst met failure modes en failure effects uit. Hiermee worden betere en verdedigbare onderhoudsconcepten gemaakt. Meetbaar, verbeterbaar, verdedigbaar, realiseerbaar.
Iedere goede FME(C)A beschrijft het actuele storingsgedrag. De FMEA wordt voor een aantal doeleinden gebruikt:
De Object FMEA is een veel gebruikte structuur. Hij is gemakkelijk aan te leren en toe te passen en ligt dicht bij de manier waarop onze administratieve systemen zijn ingericht. Gebruik een boomstructuur van functionele locaties, assets, objecten eventueel tot op het niveau van vervangbare delen. Sommigen gaan zinloos door tot op boutje-moertje niveau. Koppel daar alle storingen aan die je kunt bedenken. Koppel er een Storingseffect aan en klaar is kees. Zo wordt de Object FMEA vaak helaas op een laagwaardige manier opgezet en toegepast. Daar is met enkele simpele slagen veel verbetering door te voeren.
De Process FMEA zit anders in elkaar. Die is juist ontwikkeld omdat de kwaliteit van de Object FMEA onvoldoende was. Waarom was die kwaliteit dan onvoldoende? De lijst met storingen in de Object FMEA is gekoppeld aan de lijst met functionele locaties, assets, objecten en vervangbare delen. Maar storingsgedrag wordt maar ten dele veroorzaakt door die functionele locaties, assets en objecten. Een groot deel van het storingsgedrag bestaat uit andere factoren. dat maakt dat de Object aanpak nooit volledig kan zijn en dat de process aanpak veel meer waarde creëert, op basis waarvan veel betere onderhoudsconcepten tot stand komen die meetbaar het storingsgedrag verbeteren.
Dan rijst nog de vraag waarom de ontwikkelaars van RCM (Nowlan en Heap) juist niet voor de FMECA kozen. FMECA heeft die C van Criticality en dat doet vermoeden dat het juist over kritische systemen gaat. Hier gaan verscheidene gedachten mank.
RPN (ook bekend als de Risico matrix) gebruikt weegfactoren voor verschillende categorieën om deze met elkaar te vermenigvuldigen en een Total RPN te berekenen. Dat is uitstekend toe te passen in een FMECA.
Je kunt simpelweg per asset de kritikaliteit beoordelen. Dat kan ook per failure mode of per combinatie failure + failure effect. Nowlan en Heap hebben daar niet voor gekozen. De achterliggende gedachte is logisch.
Voor hoog kritische systemen hoor je geen Quick en Dirty technieken te gebruiken. Het is hoog kritisch en dus is volledigheid en verdedigbaarheid van belang. In RCM wordt de kritikaliteitsanalyse gedaan als alle informatie bekend is.
Allereerst is de Process FMEA een standaard onderdeel van RCM en geïntegreerd in de eerste 4 stappen van RCM. Het storingsgedrag wordt zo compleet mogelijk vastgelegd in Failure Modes en Failure Effects. Iedere afzonderlijke failure mode / failure effect combinatie, wordt daarna in de RCM stappen 5-6-7 gebruikt om er een onderhoudstaak met interval voor te vinden. Deze super gestructureerde aanpak, leidt tot een onderhoudsconcept van zeer hoog niveau, dat het volledige storingsgedrag effectief afdekt met onderhoudstaken en intervallen die dit storingsgedrag voorkomen of minimaliseren. Pas als we weten welke failure modes en effecten er zijn en weten met welke onderhoudstaak en met welke interval we deze storing kunnen voorkomen, is hij niet kritisch meer. Terwijl als we die kritikaliteitsmeting in de FMEA hadden gedaan, was hij mogelijk wel kritisch geweest. En om nou in de FMEA een kritikaliteitsweging te doen en aan het eind nog een die de eerste hoogstwaarschijnlijk teniet doet, dan heeft een FMECA in RCM geen toegevoegde waarde.
In RCM stappen 1-2-3-4 beschrijven we het actuele storingsgedrag. In RCM stap 5 wordt de categorie storingsgevolgen geselecteerd. Er zijn 3 categorieën storingsgevolgen:
Iedere onderhoudstaak moet voldoen aan vaste criteria:
In de RCM kritikaliteitsanalyse, kan geen gebruik gemaakt worden van een standaard risico matrix. Er is aanvullende informatie nodig over kosten en risico’s en die berekeningen dienen ingeschat en uitgevoerd te worden. Hoe beter de beschikbare data, hoe beter de uitkomsten worden.
Iedere onderhoudstaak moet technisch haalbaar en de moeite waard zijn. De RCM beslissingsstrategie voorziet hier volledig in. De kritikaliteitsanalyse wordt uitgevoerd bij de “de moeite waard” analyse. Als RCM juist is toegepast, is deze informatie ook beschikbaar om aan te tonen welke criteria zijn gebruikt om de keuze voor een onderhoudstaak en interval te rechtvaardigen.
CONCLUSIES: