CMMS vs Predictive Maintenance: What a Maintenance Management System Actually Needs to Do

A maintenance manager asks for "a CMMS." A vendor answers with sensors, machine learning and a dashboard that predicts failures three weeks out. Somewhere in that conversation the actual question — what happens the next time a machine breaks down at 2 a.m. — gets lost. CMMS and predictive maintenance are not competing purchases and they are not the same purchase either. One is the record-keeping backbone; the other is one strategy you run on top of it. Buying the second without the first is the more common and more expensive mistake.

What a CMMS is actually for

A Computerized Maintenance Management System is unglamorous by design: work orders, preventive schedules, spare-parts stock and machine history, in one place instead of a whiteboard, a spreadsheet and whichever technician remembers what happened last time. Time- and usage-based plans — monthly, yearly, or every N operating hours or production count — get generated and tracked automatically instead of depending on someone noticing a due date.

This backbone matters more than the strategy running on top of it, because every strategy depends on the same record. A prediction that a bearing will fail is worthless if there is no work order to act on it, no technician assigned, and no history of what was actually done last time that bearing was serviced. Plants that skip straight to predictive maintenance without first fixing their work-order discipline usually find the model was the easy part.

Where predictive maintenance starts, and a CMMS stops

Preventive maintenance runs on a calendar or a counter: service this gearbox every 90 days or every 50,000 cycles, whichever comes first, regardless of how the gearbox is actually doing. It is cheap to start — a CMMS with strategy-based plans is enough, no sensors required — and it over-services healthy equipment while under-servicing equipment under unusual load, because time and cycle count are a proxy for wear, not a measurement of it.

Predictive maintenance replaces the proxy with a measurement. Vibration, temperature and current data from IoT sensors or an existing PLC feed a model that flags degradation before it becomes a failure — a bearing running hotter than its own baseline, a motor drawing more current than the same motor drew a month ago for the same job. The output is still a work order in the same CMMS; only the trigger changed, from a date to a real signal.

The honest caveat: a predictive model is only as good as the failure history it learned from. A machine with no logged failures and no sensor history for the past year gives a model nothing to calibrate against. This is the practical reason predictive maintenance is usually the second thing a plant does, not the first — the CMMS has to be recording real breakdowns and real fixes before "predict the next one" means anything.

The two numbers that say whether either one is working

MTBF (mean time between failures) and MTTR (mean time to repair) are not vanity metrics; they are the only two numbers that separate "we do maintenance" from "maintenance is working." MTBF rising means whatever strategy is in place — preventive, predictive or both — is actually preventing failures rather than just documenting them after the fact. MTTR falling means that when something does break, the work order, the assigned technician and the spare part all arrive fast enough that downtime is a mechanical problem and not an admin one.

A maintenance history that only counts breakdowns without timestamps for "reported," "started" and "closed" cannot produce either number honestly. This is the specific reason machine history has to be structured data inside the CMMS — MTBF, MTTR, downtime percentage, emergency-call rate and cost per machine, line and plant, calculated from the same records the technician already filled in, not reconstructed later from memory.

Why maintenance and production fight over the same hours without integration

A maintenance plan and a production schedule are both trying to own the same machine-hours, and if they are built in two systems that do not talk to each other, one side finds out about the other by surprise. Maintenance schedules a bearing change for Tuesday afternoon; production has a rush order due Tuesday afternoon on the same line. Someone loses, and it is usually decided by whoever shouts loudest that morning rather than by whichever choice actually costs less.

Planning maintenance windows into the production schedule — rather than against it — turns that argument into a scheduling constraint instead of a standoff. The APS sees the maintenance window as an unavailable slot when it builds the plan, and maintenance sees committed orders when it proposes a window. Neither side is surprised, because neither side is working from a plan the other cannot see.

Where MES ends and a CMMS begins

The same boundary question that separates MES from ERP and SCADA applies here, and it is worth being just as precise about it. MES owns the moment a machine stops: it captures the downtime reason — category, timestamp, which operation — in real time, on the shop floor, because that is where the stoppage is visible first. A CMMS owns what happens next: a maintenance notification created automatically from that downtime reason, a technician dispatched, a part reserved, a repair logged, and the whole event folded into that machine's MTBF the moment it is closed.

Treat the two as substitutes and something breaks in both directions. Ask MES to manage the repair and it has no concept of spare-parts stock, technician skills or a preventive calendar — that is not what it is for. Ask a CMMS to detect the stoppage in the first place, without a feed from the floor, and every notification depends on someone remembering to log it by hand, which is exactly the discipline problem a CMMS was bought to remove. The integration that actually works is narrow and specific: a downtime reason logged in MES creates the maintenance notification automatically, with the machine, the time and the fault code already filled in. Nobody re-types anything, and nothing waits for someone to notice.

Spare parts: the step every CMMS rollout underestimates

A work order that tells a technician what to fix and does not tell them whether the part is on the shelf is half a system, and this is where a surprising number of CMMS rollouts quietly fail in year one. The stock check happens anyway — it just happens as a phone call to the warehouse instead of inside the software, which puts the delay back exactly where the CMMS was supposed to remove it.

Tying maintenance orders directly to spare-parts stock closes that gap: a work order reserves the part it needs, an inter-warehouse transfer with barcode confirmation moves it if it is held on another line or another site, and a purchase order is triggered automatically if the shelf is actually empty. The technician still walks to the shelf, but the software has already answered the question of whether the part will be there — which is the difference between a ten-minute walk and a two-day wait for the same repair.

What actually changes when preventive becomes predictive

Across Meta Smart Factory maintenance rollouts, the typical shift from a purely reactive or loosely preventive setup to a CMMS with predictive maintenance layered on top runs to roughly 45% fewer breakdowns, 20% longer machine lifetime and 30% lower maintenance cost, with work orders moving to fully digital from whatever mix of paper and memory preceded them. None of those four numbers come from the sensors alone — they come from the combination: a CMMS that reliably records every breakdown and every fix, preventive plans that stop guessing at intervals, predictive alerts where the failure history justifies them, and spare parts that are reserved before the technician is dispatched rather than discovered missing after.

The practical sequencing question is not "CMMS or predictive maintenance" — it is which comes first, and the answer is always the CMMS. Predictive maintenance is a strategy you point at a maintenance system that is already recording the truth about what breaks and what it costs. Point it at anything less and the model has nothing real to learn from.