How to Manage Maintenance With Data: A CMMS That Works on the Floor
DBR77 Team7 min read
On this page
To manage maintenance with data, give every request a work order tied to one asset, set its priority from how critical the machine is and what the stop costs production, and plan preventive work from run hours, counts and machine condition as well as the calendar. Close each job with the cause, the time spent and the parts used. The line should feed the CMMS as work happens, so technicians are not retyping the shift at the end of the day.
Most maintenance teams know their machines. What they lack is a shared record of what is open, what comes first and what keeps coming back.
Why the whiteboard and the phone stop working
A whiteboard works for one shift and five machines. It breaks when three shifts share twenty machines and the night technician cannot ask the day technician what he changed. Small jobs vanish. Big jobs wait because nobody noted that the part was ordered.
The cost of staying reactive can be measured. NIST reports that, on average, 45.7% of machinery maintenance at US manufacturers was reactive. In the same NIST work, the establishments that relied most on reactive maintenance (the top 25%) were associated with 3.3 times more downtime than the bottom 25%.
Reactive work will never be zero. The goal is to know which failures you accepted and which surprised you.
- P1Safety risk or bottleneck down
- P2Stopped or slowed, with backup
- P3Condition warning, in spec
- P4Improvement or minor defect
When everything is urgent, the loudest line wins, so rank by criticality and impact.
Start with one asset list and one work order flow
- Keep one asset list: every machine, and the parts of it you repair (spindle, gearbox, hydraulic unit), with one ID. That ID must be the same in the CMMS, the MES and the machine data system, or nothing will join later.
- Give requests one way in. Operators, setters and shift leads raise requests in one place: a terminal, a phone or a QR code on the machine. A call is fine in an emergency, but the request still gets logged.
- Use the same work order format every time: asset, symptom, priority, owner, due time, parts, time spent, cause and fix. Keep the cause list short (15 to 25 codes) so people use it.
- Agree on the status flow: requested, planned, in progress, waiting for parts, done, verified. "Done" is the technician's word. "Verified" belongs to the operator or shift lead, after the machine has run.
Until the operator or shift lead verifies a job, nobody knows whether the repair worked. The same verification step applies to every signal on the floor, and From Signal to Task to Closure: The Execution Loop shows how it works.
How to set priorities with data
When everything is urgent, the loudest line wins. A fairer order comes from how critical the asset is and what the problem is doing to production right now. Rate criticality once per asset: is it a bottleneck, is there a backup, is there a safety or quality risk? Read production impact from live machine states and the plan.
| Priority | Condition | Response target | Typical case |
|---|---|---|---|
| P1 | Safety risk, or a bottleneck machine stopped with no backup | Start within 15 minutes | Guard switch failed on the press that feeds two lines |
| P2 | Machine stopped or slowed, but a backup exists or the order has slack | Start within the shift | Second CNC down while its twin runs the same part |
| P3 | Condition warning, machine still running in spec | Plan within 3 to 5 days | Bearing temperature rising slowly on a conveyor |
| P4 | Improvement or minor defect, no production impact | Next planned window | Loose cable tray, worn label on a control panel |
Review the targets monthly with production. If half of all work orders are P1, the scale is not working.
What should trigger preventive work and inspections
Calendar plans are a start, but a machine running one shift a day and one running three do not wear the same way. Use three kinds of trigger:
- Time-based: where wear follows the calendar, such as filter changes and statutory inspections.
- Usage-based: run hours, cycle counts or strokes. This matches the work to the load.
- Condition-based: a measured value crosses a limit, such as vibration, temperature, current draw or hydraulic pressure.
These need machine data. Our IoT article on how to reduce downtime with real-time data explains which signals are worth collecting first.
Not every stop should become a work order. Vorne describes minor stops as stops that are usually well under five minutes and do not require maintenance personnel. Log them, and let the operator clear them. Open a work order when a stop repeats, needs parts or runs past a time limit.
Illustrative example: a stamping shop runs six presses on two shifts. Each die is inspected every 40,000 strokes, read from the press counter, instead of on the first Monday of the month. The die on the busiest press comes up about every nine working days, the one on the slowest press about once a month, and nobody edits a calendar.
Which numbers show that maintenance is working
Define a few measures once. SMRP publishes more than 70 maintenance and reliability metrics and guidelines, each with a definition, objective and formula, so a plant does not have to invent its own. A useful starting set:
- Planned share of work: hours on planned jobs vs. all maintenance hours.
- PM compliance: preventive jobs done within their window.
- MTBF and MTTR per critical asset, not plant-wide averages that hide the worst machines.
- Backlog in weeks: open planned work divided by weekly crew capacity.
- Repeat failures: the same asset and the same cause within 30 days.
Repeat failures are often where maintenance meets quality: a worn tool shows up first as scrap, not as a stop. How to Link Quality Issues to Production and Maintenance explains how to connect those records.
How this works in DBR77 IRIS
IRIS CMMS is the maintenance module of DBR77 IRIS and runs on the same data model as production, warehouse and quality. The asset list holds the hierarchy, documents and history. Time-based and condition-based plans generate work orders automatically, and each work order carries technician notes, time logs and parts consumed.
When IRIS MES records an equipment failure, it opens a corrective work order, and closing the job ends the downtime record that availability and MTBF are calculated from. Alarms from machine data in DBR77 IIoT can open work orders too; this path is switched on per plant during deployment. Dashboards show MTBF, MTTR and cost per asset.
IRIS also flags assets with recurring failures, and Data & AI proposes maintenance actions as recommendations, each with the basis for its score. The job is scheduled only after a maintenance lead approves it, and the log keeps both the recommendation and the approval. The IRIS assistant can tell a technician what is open on a machine and what failed there before, but it does not create or schedule work orders.
FAQ
Do we need sensors on every machine before we start?
No. Start with the asset list, work orders and priority rules. Add machine data first on the bottleneck and on the assets that fail most often.
How do we get technicians to log their work?
Make logging faster than the alternative: a QR code on the machine, short cause lists, mobile entry. Show the repeat-failure list weekly so the team sees why it matters.
Should every alarm open a work order?
No. Only alarms that need parts, planning or a repair, or that keep repeating. Short stops stay with the operator.
Conclusion
Start with the bottleneck: give it one asset ID, route every request on it through one work order flow and agree the P1 to P4 rules with production. Close every job with a cause and a check on the machine. Review the targets monthly, track planned share of work and repeat failures, and add the next line once the first one runs this way.