← Alle artikelen
Maintenance

CMMS vs voorspellend onderhoud: wat een onderhoudsbeheersysteem werkelijk moet kunnen

📅 · 4 min leestijd · Meta Smart Factory Team

De twee worden als één aankoop verkocht, en dat zijn ze niet. Wat een CMMS bijhoudt, wat voorspellend onderhoud daar bovenop toevoegt, en de grens die bepaalt of sensordata een werkorder wordt of gewoon een grafiek waar niemand naar handelt.

Een onderhoudsmanager vraagt om “een CMMS.” Een leverancier antwoordt met sensoren, machine learning en een dashboard dat storingen drie weken vooruit voorspelt. Ergens in dat gesprek raakt de eigenlijke vraag — wat er gebeurt de volgende keer dat een machine om twee uur ’s nachts uitvalt — zoek. CMMS en voorspellend onderhoud zijn geen concurrerende aankopen, en ze zijn ook geen dezelfde aankoop. Het ene is de registratiebasis; het andere is één strategie die je daar bovenop draait. De tweede kopen zonder de eerste is de vaker gemaakte en duurdere fout.

Waar een CMMS werkelijk voor dient

Een CMMS is met opzet onglamoureus: werkorders, preventieve schema’s, reserveonderdelenvoorraad en machinehistorie, op één plek in plaats van een whiteboard, een spreadsheet en welke monteur er nog het beste van herinnert wat er de vorige keer gebeurde. Tijd- en gebruiksgebaseerde plannen — maandelijks, jaarlijks, of elke N bedrijfsuren of productieaantal — worden automatisch gegenereerd en bijgehouden in plaats van af te hangen van iemand die een vervaldatum opmerkt.

Deze basis telt zwaarder dan de strategie die erbovenop draait, want elke strategie hangt af van hetzelfde register. Een voorspelling dat een lager gaat storen is waardeloos als er geen werkorder is om ernaar te handelen, geen monteur is toegewezen en er geen historie is van wat er de vorige keer daadwerkelijk aan dat lager is gedaan. Fabrieken die rechtstreeks naar voorspellend onderhoud springen zonder eerst hun werkorderdiscipline op orde te brengen, merken meestal dat het model het makkelijke deel was.

Waar voorspellend onderhoud begint, en een CMMS ophoudt

Preventief onderhoud draait op een kalender of een teller: onderhoud deze tandwielkast elke 90 dagen of elke 50.000 cycli, wat het eerst komt, ongeacht hoe de tandwielkast er werkelijk aan toe is. Het is goedkoop om mee te beginnen — een CMMS met strategiegebaseerde plannen volstaat, geen sensoren nodig — en het onderhoudt gezonde apparatuur te vaak terwijl apparatuur onder ongebruikelijke belasting te weinig onderhoud krijgt, omdat tijd en cyclustelling een indicator zijn voor slijtage, geen meting ervan.

Voorspellend onderhoud vervangt de indicator door een meting. Trillings-, temperatuur- en stroomdata van IoT-sensoren of een bestaande PLC voeden een model dat degradatie signaleert voordat die een storing wordt — een lager dat warmer draait dan zijn eigen basislijn, een motor die meer stroom trekt dan diezelfde motor een maand geleden voor dezelfde klus deed. De uitkomst is nog steeds een werkorder in hetzelfde CMMS; alleen de trigger is veranderd, van een datum naar een echt signaal.

De eerlijke kanttekening: een voorspellend model is nooit beter dan de storingshistorie waarvan het heeft geleerd. Een machine zonder gelogde storingen en zonder sensorhistorie over het afgelopen jaar geeft een model niets om tegen te kalibreren. Dit is de praktische reden waarom voorspellend onderhoud meestal het tweede is wat een fabriek doet, niet het eerste — het CMMS moet al echte storingen en echte reparaties registreren voordat “voorspel de volgende” iets betekent.

De twee cijfers die zeggen of een van beide werkt

MTBF (mean time between failures) en MTTR (mean time to repair) zijn geen prestige-cijfers; het zijn de enige twee getallen die “we doen aan onderhoud” scheiden van “onderhoud werkt.” Een stijgende MTBF betekent dat welke strategie er ook loopt — preventief, voorspellend of beide — daadwerkelijk storingen voorkomt in plaats van ze achteraf alleen te documenteren. Een dalende MTTR betekent dat wanneer er dan toch iets uitvalt, de werkorder, de toegewezen monteur en het reserveonderdeel snel genoeg aankomen dat de stilstand een mechanisch probleem is en geen administratief probleem.

Een onderhoudshistorie die alleen storingen telt zonder tijdstempels voor “gemeld,” “gestart” en “afgesloten” kan geen van beide cijfers eerlijk opleveren. Dit is de specifieke reden waarom machinehistorie gestructureerde data moet zijn binnen het CMMS — MTBF, MTTR, stilstandpercentage, spoedmeldingsratio en kosten per machine, lijn en fabriek, berekend uit dezelfde gegevens die de monteur al heeft ingevuld, niet later uit het geheugen gereconstrueerd.

Waarom onderhoud en productie zonder integratie om dezelfde uren vechten

Een onderhoudsplan en een productieplanning proberen allebei dezelfde machine-uren te claimen, en als ze in twee systemen worden opgebouwd die niet met elkaar praten, komt de ene kant er via een verrassing achter dat de andere er ook aanspraak op maakt. Onderhoud plant een lagerwissel voor dinsdagmiddag; productie heeft op diezelfde lijn een spoedorder die dinsdagmiddag af moet. Iemand verliest, en meestal wordt dat die ochtend beslist door wie het hardst roept, niet door welke keuze werkelijk het minste kost.

Onderhoudsvensters ín de productieplanning inplannen — in plaats van ertegenin — maakt van die discussie een planningsbeperking in plaats van een patstelling. Het APS ziet het onderhoudsvenster als een niet-beschikbaar tijdslot wanneer het het plan opbouwt, en onderhoud ziet toegezegde orders wanneer het een venster voorstelt. Geen van beide kanten wordt nog verrast, omdat geen van beide werkt vanuit een plan dat de ander niet kan zien.

Waar MES ophoudt en een CMMS begint

Dezelfde grensvraag die MES van ERP en SCADA scheidt, geldt hier ook, en het loont om er even precies over te zijn. MES bezit het moment waarop een machine stopt: het legt de stilstandreden vast — categorie, tijdstempel, welke bewerking — in realtime, op de werkvloer, omdat de stilstand daar het eerst zichtbaar is. Een CMMS bezit wat daarna gebeurt: een onderhoudsmelding die automatisch uit die stilstandreden wordt aangemaakt, een monteur die wordt ingezet, een onderdeel dat wordt gereserveerd, een reparatie die wordt gelogd, en het hele voorval dat op het moment van afsluiten wordt verwerkt in de MTBF van die machine.

Behandel de twee als vervangers van elkaar en er breekt iets in beide richtingen. Vraag MES om de reparatie te beheren en het heeft geen begrip van reserveonderdelenvoorraad, monteurvaardigheden of een preventieve kalender — daar is het niet voor gebouwd. Vraag een CMMS om de stilstand als eerste te detecteren, zonder voeding vanaf de vloer, en elke melding hangt af van iemand die eraan denkt het handmatig te loggen — precies het disciplineprobleem waarvoor een CMMS werd gekocht om weg te nemen. De integratie die werkelijk werkt is smal en specifiek: een in MES gelogde stilstandreden maakt automatisch de onderhoudsmelding aan, met de machine, de tijd en de storingscode al ingevuld. Niemand typt iets opnieuw over, en niets wacht tot iemand het opmerkt.

Reserveonderdelen: de stap die elke CMMS-uitrol onderschat

Een werkorder die een monteur vertelt wat er gerepareerd moet worden maar niet vertelt of het onderdeel op de plank ligt, is een half systeem, en dit is waar een verrassend aantal CMMS-uitrollen in het eerste jaar geruisloos faalt. De voorraadcontrole gebeurt toch — alleen als telefoontje naar het magazijn in plaats van in de software, waardoor de vertraging precies terugkomt op de plek waar het CMMS die had moeten wegnemen.

Onderhoudswerkorders rechtstreeks koppelen aan de reserveonderdelenvoorraad dicht dat gat: een werkorder reserveert het onderdeel dat het nodig heeft, een overdracht tussen magazijnen met barcodebevestiging verplaatst het als het op een andere lijn of andere locatie ligt, en een inkooporder wordt automatisch getriggerd als de plank daadwerkelijk leeg is. De monteur loopt nog steeds naar de plank, maar de software heeft de vraag of het onderdeel er zal liggen al beantwoord — en dat is het verschil tussen een wandeling van tien minuten en twee dagen wachten op dezelfde reparatie.

Wat er werkelijk verandert wanneer preventief voorspellend wordt

Over de onderhoudsuitrollen van Meta Smart Factory heen komt de typische verschuiving van een puur reactieve of losjes preventieve opzet naar een CMMS met voorspellend onderhoud daarbovenop neer op ongeveer 45% minder storingen, 20% langere machinelevensduur en 30% lagere onderhoudskosten, waarbij werkorders volledig digitaal worden vanuit welke mix van papier en geheugen er ook aan voorafging. Geen van deze vier cijfers komt alleen uit de sensoren — ze komen uit de combinatie: een CMMS dat betrouwbaar elke storing en elke reparatie registreert, preventieve plannen die stoppen met gokken naar intervallen, voorspellende meldingen waar de storingshistorie ze rechtvaardigt, en reserveonderdelen die worden gereserveerd voordat de monteur wordt ingezet in plaats van pas achteraf ontdekt te worden als ontbrekend.

De praktische volgordevraag is niet “CMMS of voorspellend onderhoud” — het is wat er eerst komt, en het antwoord is altijd het CMMS. Voorspellend onderhoud is een strategie die je richt op een onderhoudssysteem dat al de waarheid registreert over wat er kapotgaat en wat het kost. Richt het op iets minder dan dat, en het model heeft niets echts om van te leren.

Bespreek dit met onze experts

Veelgestelde vragen

Wat is het verschil tussen een CMMS en voorspellend onderhoud?

Een CMMS is het registratiesysteem — werkorders, preventieve schema’s, reserveonderdelen en machinehistorie. Voorspellend onderhoud is één strategie die daarbovenop draait: sensordata (trilling, temperatuur, stroom) gebruiken om een werkorder te triggeren vanuit een echt signaal in plaats van een kalenderdatum. Een fabriek kan een CMMS draaien met puur preventieve (kalender-/gebruiksgebaseerde) plannen en helemaal geen sensoren; voorspellend onderhoud heeft altijd het CMMS eronder nodig om te handelen naar wat het voorspelt.

Welke data heeft voorspellend onderhoud werkelijk nodig?

Sensordata — trilling, temperatuur en stroom zijn de gebruikelijke inputs, van IoT-apparaten of een bestaande PLC — plus genoeg gelogde storingshistorie zodat een model kan leren hoe “afwijkend” eruitziet voor die specifieke machine. Een machine zonder onderhoudshistorie geeft een voorspellend model niets om tegen te kalibreren, en dat is waarom voorspellend onderhoud meestal wordt ingevoerd nadat het CMMS al een tijdje echte storingen heeft geregistreerd, niet ervoor.

Vervangt een CMMS het MES voor stilstandregistratie, of andersom?

Geen van beide. MES legt de stilstandreden in realtime vast op de werkvloer — wat stopte, wanneer en waarom. Een CMMS neemt het vanaf daar over: de onderhoudsmelding, de toegewezen monteur, het gereserveerde reserveonderdeel, de afgesloten werkorder en de resulterende MTBF/MTTR. De integratie die werkt, is dat een stilstandreden in MES automatisch de onderhoudsmelding aanmaakt, zodat niemand hetzelfde voorval opnieuw in twee systemen hoeft in te typen.

Hoe worden MTBF en MTTR berekend, en wat vertellen ze werkelijk?

MTBF (mean time between failures) is de totale bedrijfstijd gedeeld door het aantal storingen; MTTR (mean time to repair) is de totale reparatietijd gedeeld door het aantal reparaties. Een stijgende MTBF betekent dat de onderhoudsstrategie storingen voorkomt in plaats van ze alleen te registreren; een dalende MTTR betekent dat wanneer er dan toch iets uitvalt, de werkorder, de monteur en het reserveonderdeel snel genoeg aankomen dat de stilstand een mechanisch probleem is, geen administratief probleem. Beide vereisen tijdgestempelde “gemeld / gestart / afgesloten”-data op elke werkorder — een onderhoudslog dat alleen registreert dát er iets kapotging, kan geen van beide cijfers eerlijk opleveren.

Kunnen onderhoudswerkorders integreren met de productieplanning?

Ja, en zonder die integratie plannen onderhoud en productie onafhankelijk van elkaar dezelfde machine-uren in en komen ze op de harde manier achter het conflict. Een onderhoudsvenster in het APS inplannen betekent dat de planning het als een niet-beschikbaar tijdslot behandelt bij het opbouwen van het plan, in plaats van dat onderhoud en productie zich allebei vastleggen op dezelfde dinsdagmiddag in twee systemen die nooit met elkaar hebben afgestemd.

Hebben we IoT-sensoren nodig om te beginnen, of kunnen we starten met alleen preventief onderhoud?

Alleen preventief is een legitiem, sensorvrij startpunt: een CMMS met tijd- en gebruiksgebaseerde plannen neemt het probleem van kalenderbewaking op het geheugen al weg, en dat is het grootste deel van wat een eerste uitrol moet oplossen. Voorspellend onderhoud is de moeite waard om toe te voegen zodra er genoeg gelogde storingshistorie is om een model op te trainen, en zodra de apparatuur in kwestie duur of verstorend genoeg is om te falen dat vroeg ingrijpen de sensorkosten waard is — niet elke machine op de vloer hoeft vanaf dag één voorspellend te zijn.