Most plants service machines on a calendar: every month, every thousand hours, every shutdown. It is simple and it works, but it means some parts are replaced too early and some fail before the date arrives. Condition-based maintenance changes the trigger. You measure something about the machine, such as vibration, temperature or motor current, and you act when the measurement drifts away from normal.
This article is for the person who runs production or operations and wants to know where to begin, and when the effort pays back. For the wider case for predicting failures, see how predictive maintenance reduces downtime. Here we stay practical: what data, which line, and how to count the break-even.
Start with the data you already have
Before buying a single sensor, collect what exists. You need three things:
- A stoppage log. For each unplanned stop: machine, start and end time, reason and who fixed it. If this lives on paper or in a spreadsheet, that is enough to begin. Our article on the manufacturing spreadsheet problem explains how to bring such records together without a large project.
- A maintenance log. What was done, when, and which parts were replaced, including planned work.
- Machine identity. A stable name or number for each machine and component, used in both logs. Mismatched names are the most common reason the first analysis fails.
If the stoppage log is incomplete, spend the first weeks improving it. No analysis can be better than the records it uses.
Choose the machines and the signal
Do not instrument everything. List the machines whose unplanned stops hurt most, using the log: stops per month and hours lost. Then, for the top few, ask the maintenance team a direct question: before this failed last time, was there anything you could hear, feel or see?
Typical early signals are:
- vibration or noise on rotating parts such as bearings, fans and motors
- temperature rise on motors, gearboxes and electrical cabinets
- motor current or pressure that creeps away from its normal level
- a count that wears out, such as cycles, starts or running hours
Pick one or two signals per machine. If nobody can name a plausible warning sign for a failure, condition monitoring will probably not help with that failure, and you should say so early.
Run a pilot on one line
A pilot has a fixed place, a fixed time and a decision rule written in advance.
- Place. One line, or a few critical machines on it, with a reasonably steady product mix so that readings are comparable.
- Time. Long enough to see several normal cycles and, ideally, at least a few events worth catching. Agree the length before you start and do not extend it silently.
- Baseline. Record normal readings first. Alerts only make sense relative to what normal looks like for that machine.
- Alert rule. Start with simple thresholds set with the maintenance team, for example "reading above the usual range for a set period". Count every alert and note what the technician found.
- Owner. One named person reads the alerts and decides on action. Without an owner the alerts become noise.
Keep a short list of each alert: what fired, what was found, whether a stop was avoided, and how long the check took. This list is the evidence for the decision at the end. The same discipline of a staged start and clear criteria appears in our guide to AI pilots that scale.
The break-even calculation
You do not need a model. You need four numbers from your own records.
- A. Unplanned stoppages per year on the machines in scope, from the stoppage log.
- B. Cost of one stoppage: lost output, labour, scrap, expedited parts and any penalties. Use the honest total, and mark it as an estimate if it is one.
- C. Share of those stoppages that give an early signal you can act on. Take it from the pilot, not from a vendor brochure.
- D. Yearly cost of the monitoring: sensors, installation, software, and the time of the person who reads the alerts. Include the cost of checks that turn out to be false alarms.
The yearly benefit is A × B × C, less the cost of the work you still have to do when an alert fires, because a planned repair is not free either. The approach pays back when that benefit is higher than D.
Worked example (invented numbers, for illustration only). On the machines in scope the log shows 12 unplanned stoppages a year. One stoppage costs about 4,000 in lost output and labour. In the pilot, 5 of the 12 events would have been preceded by a usable signal, so C is about 40%. Benefit: 12 × 4,000 × 0.4 = 19,200 per year, before the cost of planned repairs, say 4,000, which leaves 15,200. If the monitoring costs 10,000 a year including the technician's time, it pays back; if it costs 20,000, it does not, and calendar maintenance stays.
The same formula shows when it is not worth it. With few stoppages, a low cost per stoppage or a low share that gives a warning, the benefit stays small, and no technology changes that.
Decide, then scale in steps
At the end of the pilot, apply the rule you wrote at the start. There are three honest outcomes:
- Extend to similar machines, because alerts led to avoided stops at a cost below the benefit.
- Adjust thresholds, signals or the owner's routine, then run a second short pilot.
- Stop and keep calendar maintenance for these machines, perhaps with better logging.
If you extend, add machines in groups of similar type, and keep recording the four numbers. Measuring the manual effort first helps too; see how to measure the cost of a manual process in a week.
Common mistakes
- Buying sensors before the stoppage log is reliable.
- Instrumenting every machine instead of the few that cause most of the loss.
- Taking the share of predictable failures from a supplier's claim instead of your own pilot.
- Having alerts without an owner or a defined response.
- Ignoring the cost of false alarms and planned repairs in the calculation.
- Extending the pilot until it looks successful.
Where to start this week
Pull the last twelve months of unplanned stops. Rank machines by hours lost, take the top three and ask the maintenance team what warned them last time. Fill in A and B for those machines, and write down the decision rule for a pilot before any hardware is chosen. If the numbers do not look promising on paper, you have saved the cost of a pilot; if they do, you have the brief for one.
Sources
- Your own stoppage and maintenance records, and cost data, collected as described; all figures in the worked example are invented for illustration.
- Our related articles linked above.