Ongeplande stilstand is een van de duurste dingen die een operatie kan overkomen. Een pomp die op dinsdagochtend uitvalt kost meer dan de pomp: de lijn staat stil, monteurs worden van ander werk gehaald en klanten wachten. Vaste onderhoudsschema's waren decennialang het antwoord, maar die vervangen onderdelen op de ene machine te vroeg en op de volgende te laat.
Predictive maintenance belooft iets beters: onderhoud wanneer de data zegt dat het nodig is, niet wanneer de kalender dat zegt. Toch lopen veel pilots vast na het eerste dashboard. Meestal ligt dat niet aan het model, maar aan de keuzes ervoor en erna.
Begin bij de storing, niet bij de sensor
De meest gemaakte fout is beginnen bij de data die toevallig beschikbaar is en daar patronen in zoeken. Begin liever bij één storing die pijn doet. Kies één type asset waar uitval duur is en vaak genoeg voorkomt om van te leren, en beantwoord twee vragen voordat er iets gebouwd wordt:
- Wat telt precies als storing? Een trip, uitval, een onderdeel dat buiten het schema is vervangen? De definitie bepaalt je labels.
- Hoeveel waarschuwingstijd is nuttig? Een waarschuwing twee uur vooraf vraagt andere data en een ander model dan een waarschuwing drie weken vooraf, als een planner nog onderdelen kan bestellen en een ploeg kan inplannen.
De data is er meestal al
De meeste organisaties verzamelen al wat een eerste model nodig heeft. Het staat alleen verspreid over systemen die nooit bedoeld waren om te combineren:
- Sensordata uit SCADA, PLC's of IoT-gateways: trilling, temperatuur, druk, stroom, draaiuren.
- Onderhoudshistorie uit het CMMS of ERP: werkorders, vervangen onderdelen, stilstandregistraties.
- Operationele context: belasting, ploegen, producttype, weer bij assets buiten.
Het echte werk zit in het koppelen van die bronnen: tijdstempels uitlijnen en jaren aan werkorders omzetten in gelabelde storingen. Werkorders zijn rommelige vrije tekst ("lagergeluid, vervangen, zie vorige"), en daar verdienen taalmodellen zich terug. Ze classificeren duizenden onderhoudsnotities in uren in storingsmodi, werk waar een reliability engineer anders weken mee bezig is.
Kies de aanpak die past bij je storingshistorie
Er bestaat niet één predictive-maintenance-model. De juiste aanpak hangt vooral af van hoeveel storingen je hebt vastgelegd:
- Weinig vastgelegde storingen: gebruik anomaliedetectie. Het model leert hoe normaal gedrag eruitziet per asset en signaleert afwijkingen, zonder storingslabels nodig te hebben. Het is hetzelfde principe waarmee we een ongelabeld medisch beeldarchief doorzoekbaar maakten: laat het model de structuur uit de data zelf leren.
- Een stevige storingshistorie: train een gesuperviseerd model dat de kans op uitval binnen een tijdvenster voorspelt, of de resterende levensduur van een component. Gradient-boosted modellen op goed ontworpen features zijn hier vaak lastig te verslaan; sequentiemodellen helpen als het verloop van het signaal over tijd ertoe doet.
Welke aanpak ook: vergelijk altijd met een simpele baseline, het huidige schema of een vaste drempelwaarde. Als het model die niet duidelijk verslaat, hoort het niet live te gaan.
Meet wat de planner belangrijk vindt
Nauwkeurigheid is het verkeerde kerngetal. Storingen zijn zeldzaam, dus een model dat nooit alarm slaat scoort een hoge nauwkeurigheid en is waardeloos. De getallen die op de vloer tellen zijn:
- Precisie van alerts: hoeveel meldingen echt blijken te kloppen. Valse alarmen breken vertrouwen sneller dan wat dan ook.
- Waarschuwingstijd: hoe ver voor de storing de waarschuwing komt.
- Gemiste storingen: wat er nog steeds doorheen glipt.
Evalueer in de tijd: train op het verleden en test op een latere periode, nooit op een willekeurige split, anders leert het model ongemerkt van de toekomst. En blijf monitoren na livegang: sensoren worden vervangen, opnieuw gekalibreerd of verplaatst, en de bedrijfsvoering verandert. Een model waar niemand naar kijkt, drijft af.
Zet de voorspelling waar het werk gebeurt
Een alert op een dashboard dat niemand opent, verandert niets. De voorspelling moet landen in het proces dat er al is. In de praktijk betekent dat een voorgestelde werkorder in het CMMS, met het bewijs erbij: welk signaal afwijkt, hoeveel, en welke eerdere storingen erop leken. De planner beslist; het systeem bereidt voor.
Hier komen voorspellende modellen en agent-workflows samen. Het model voorspelt, een agent bereidt de werkorder voor en checkt de beschikbaarheid van onderdelen, en een mens keurt goed. Elke beslissing blijft herleidbaar.
Een realistische eerste stap
Begin met één type asset en de historie daarvan. Bewijs met een backtest of de waarschuwingen vroeg en precies genoeg komen om op te handelen. Draai het model daarna in schaduwmodus naast het huidige onderhoudsschema, zodat het team ziet wat het gesignaleerd zou hebben voordat iemand erop handelt. Pas als de voorspellingen in schaduwmodus overeind blijven, is het zinvol om de onderhoudsplanning aan te passen.
Die route is trager dan een flitsende pilot, maar eindigt met een model dat het onderhoudsteam echt vertrouwt, en alleen zo'n model verlaagt stilstand.