Predictive Maintenance in Manufacturing

Predictive maintenance in manufacturing is a different proposition from predictive maintenance in a commercial building or a utility network, and the difference is almost entirely about how easy the business case is to write. In a production plant, finance can already tell you what an hour of line stoppage costs, operations can already tell you which machine is the bottleneck, and somewhere in the control system there is a historian holding years of tag data that a building operator would envy. That combination makes manufacturing the most tractable environment for predictive maintenance of any sector I work in. It also makes the failures harder to excuse.

The message up front: in manufacturing, predictive maintenance succeeds or fails on two questions that have nothing to do with algorithms. Is the asset on the constraint, so that its failure actually costs production? And does a named person own the response to an alert, with the authority to raise a work order and take a machine down? Get both right on a handful of bottleneck assets and the payback is usually obvious within a year. Get either wrong and you will have a very expensive dashboard.

1. What makes manufacturing different

Most predictive maintenance advice is written generically, as if an air handling unit in an office tower and a servo axis on a packaging line present the same problem. They do not. Four things about a production environment change the calculation, and all four work in your favour.

Downtime has a directly calculable cost per hour. In a facility, the cost of a failure is diffuse: occupant discomfort, reputational risk, an SLA penalty somewhere. In a plant, the cost of a stopped line is throughput multiplied by contribution margin, and the finance team can produce that number in an afternoon. Sometimes there is a late-delivery penalty on top, or a scrapped batch, or a start-up sequence that wastes material after every restart. The denominator of your ROI calculation is not a guess, which is a luxury reliability engineers in other sectors rarely have.

Bottleneck assets dominate the value case. A production line has a constraint, and the throughput of the whole line is set by it. If the constraint machine stops, the plant loses output. If a non-constraint machine stops with buffer stock either side and spare capacity to catch up, the plant may lose nothing at all. Same failure, same repair cost, radically different consequence. So the first step in any manufacturing scoping exercise is not an asset criticality workshop in the abstract, it is a walk of the line with the production manager identifying the constraint and the buffers. Criticality in a plant is a function of position in the process, not just of replacement value.

OEE gives you an existing measurement frame. Overall Equipment Effectiveness (availability multiplied by performance multiplied by quality) is already tracked in most serious manufacturing operations, already broken down into loss categories. You do not have to invent a way to measure whether the programme worked. Unplanned downtime sits in availability, usually with reason codes attached. Micro-stops and slow running show up in performance. Defects from a degrading tool or a drifting axis show up in quality. A programme that cannot move a specific OEE loss category after twelve months is not working, and OEE will tell you that without any special instrumentation.

The data often already exists. A plant with a modern control system is already generating and storing large quantities of condition-adjacent data. Motor current from the drives. Cycle times from the PLC. Temperatures, pressures and flows from the process instrumentation. Torque from the servo controllers. Reject counts from the vision system. All of that is condition data wearing a production-data costume. In a facility you usually have to buy and install the sensor layer. In a plant you frequently just have to ask for read access to a historian, and that difference can cut the entry cost of a pilot by an order of magnitude.

2. Bottleneck thinking: where the value actually concentrates

The constraint point deserves a little more space because it is the most commonly skipped step and the most expensive to skip. The conventional approach imported from other sectors is to rank assets by criticality using a scoring matrix: safety consequence, environmental consequence, cost of failure, redundancy. That approach is sound and the asset criticality classification method is the right foundation. But in a manufacturing setting it needs a production-flow overlay, because the matrix on its own will happily rank an expensive machine as critical when the line does not actually depend on it.

The practical method: walk the process from raw material to finished goods with someone who runs the line. At each station ask the rated capacity, the actual output, and what buffer exists upstream and downstream. The constraint usually becomes obvious within twenty minutes, and it is often not the machine people assume. Then ask how long the line can keep running on buffer if this station stops. A machine with four hours of downstream accumulation has a very different failure consequence from one feeding directly into a continuous process. Three categories tend to emerge:

• Constraint assets with no buffer. Every minute of downtime is a minute of lost output that cannot be recovered. These are the assets where predictive maintenance pays for itself fastest and where the monitoring spend is trivially justified.
• Constraint assets with buffer, or shared-load assets. Failure hurts but there is some tolerance. Worth monitoring where the failure modes are detectable, but the business case has to be argued rather than assumed.
• Non-constraint assets with spare capacity and redundancy. A failure here may cost nothing but the repair. These belong on a sound preventive regime or, for cheap and easily replaced items, on run to failure. Instrumenting them is a waste of budget that would have earned a return on the constraint.

There is a subtlety worth flagging. Constraints move. Introduce a new product mix, debottleneck one station, change the shift pattern, and the constraint shifts elsewhere. A predictive programme scoped once and never revisited will find itself monitoring last year's bottleneck. I would build a review of the constraint map into the annual maintenance planning cycle rather than treating it as a one-off scoping artefact.

3. The asset classes that pay back

Not every machine is a good predictive candidate, and the difference comes down to whether the dominant failure modes give detectable warning over a useful interval. Rotating equipment is the classic sweet spot, because bearing and alignment degradation announces itself in vibration weeks ahead. Electronics and control boards are the classic poor candidate, because they fail suddenly. The table below is the triage I would use as a starting point on a general manufacturing site.

The technique column lists what I would deploy first, not everything possible. Piling four techniques onto one asset class before proving one of them is a reliable way to burn a pilot budget. Start with the single technique that matches the dominant failure mode in that asset's own history, which brings us to the data.

4. The data you already have: PLC, SCADA, historian, MES

The least glamorous finding in most manufacturing assessments is that a meaningful pilot can be run on existing data. Not always, and not for every failure mode, but often enough that buying sensors before auditing the historian is a mistake. The realistic map of the options:

The pattern I would recommend: take the constraint asset, pull three years of historian data and three years of CMMS history for it, and check whether any stored tag moved in the weeks before each recorded failure. That costs a few days of analyst time, needs no procurement, and gives a defensible answer on whether existing data carries the signal. If it does, you have a cheap pilot. If it does not, you now know exactly which sensor you need and why, which is a far stronger purchase justification than a vendor brochure.

5. Crossing the OT/IT boundary without breaking anything

Here is where manufacturing gets genuinely harder than facilities. A plant control network is not an IT network and should not be treated as one. It runs deterministic traffic, it may be safety-related, it carries devices that cannot be patched, and the people who own it are accountable for production continuity in a way that a corporate IT team is not. Turning up and asking to point a cloud analytics platform at the historian will, correctly, get you refused. The architecture that plant engineers will accept follows one principle: one-way data flow out of the control zone, with no path back in. In practice that means a layered arrangement.

The reference model behind that layering is the Purdue enterprise reference architecture, and it underpins the ISA/IEC 62443 series on industrial automation and control system security . You do not need to become a security specialist, but you do need to be able to describe your predictive maintenance data flow in those terms, because that is the language the people guarding the control network use. An integration proposal that shows a read-only collector in the operations zone publishing through a DMZ, with no inbound path to the PLCs, gets a hearing. One that shows a cloud service with direct historian credentials does not.

Edge versus cloud is not an ideological choice, it is a bandwidth question with a clear answer per signal type. High-frequency vibration waveforms belong at the edge, because shipping raw spectra continuously to a cloud platform is expensive and pointless when what you need downstream is a handful of extracted features and an alarm state. Slow process trends, fleet comparisons and any cross-site model training belong centrally. The workable default: feature extraction at the edge, trending and modelling in the centre, raw waveforms stored locally and pulled on demand when an engineer investigates an alarm.

6. From prediction to work order: closing the loop in the CMMS

This is the question I would ask any vendor before signing anything. What happens, concretely, when the model raises a warning? If the answer is "it appears on the dashboard" or "an email goes to the reliability team", the programme will decay. Alerts arrive, nobody is formally accountable, the first few are investigated out of curiosity, one turns out to be a false alarm, enthusiasm drops, and within three months the dashboard is a browser tab nobody opens. What works instead is unglamorous and procedural: the prediction becomes a record in the system where maintenance work actually lives, following the same lifecycle as any other work.

• The alert creates a condition-based work request automatically, against the correct asset record, carrying the evidence: which tag, what threshold or model output, the trend window, the recommended inspection.
• It routes to a named role, not a team inbox. A planner or reliability engineer accountable for triaging within a defined period. Without a named owner, nothing else here matters.
• Triage produces one of three outcomes: raise a work order, monitor with a review date, or dismiss as a false positive with a reason recorded. Log all three, because the dismissals are how you tune the thresholds.
• Priority derives from production consequence, not from the model's confidence score. A moderate-confidence alert on the constraint outranks a high-confidence alert on a redundant fan.
• Scheduling negotiates with production. The whole point of prediction is to convert an unplanned stop into a slot in an existing changeover or shutdown.
• Closure feeds back: what was found, whether the prediction was correct, what was replaced. That is the label set for the next model iteration and the evidence for the ROI review.

Most platforms support this in principle. IBM Maximo, SAP PM, Hexagon EAM and Infor EAM all have condition-monitoring or meter-based work generation constructs that accept an external condition event and spawn work; mid-market systems such as Fiix, Limble, MaintainX, UpKeep and eMaint expose an API that can create a work request from an external trigger. The technical capability is rarely the obstacle. The obstacle is that nobody defined the triage process or assigned the owner. For the broader integration mechanics, the predictive maintenance practitioner's guide is the pillar this article sits under, and the failure prediction and RUL guide goes deeper on the modelling side.

7. Using OEE as the scorecard

One of the genuine advantages of a manufacturing setting is that you do not have to invent a measurement framework to prove the programme worked. OEE already decomposes losses into availability, performance and quality, and most plants already record downtime reason codes against those buckets. Tying the predictive programme to specific OEE loss categories is the cleanest way to make it accountable.

The mapping I would set up before the pilot starts:

• Availability losses: unplanned breakdown hours on the pilot assets, and the ratio of planned to unplanned intervention on those assets. This is the primary target. If breakdown hours on the monitored assets do not fall, nothing else redeems the programme.
• Performance losses: minor stops and reduced-speed running. Degrading equipment often shows up here before it shows up as a breakdown, as operators nurse a machine along at reduced rate. A predictive programme should pull this down too.
• Quality losses: scrap and rework attributable to equipment condition, which is the dimension people forget. Tool wear, spindle runout, axis backlash and drifting process control all produce defects long before they produce a stoppage.
• Maintenance-side measures: mean time between failures on the monitored assets, schedule compliance, and the proportion of work that was planned rather than reactive. These are leading indicators that move before the OEE numbers do.

Two cautions. Record the baseline before you start, per asset, over a period long enough to cover normal variation: twelve months is better than three, and retrospective baselines are always disputed. And remember that OEE moves for many reasons unrelated to maintenance, including product mix, labour, material quality and demand. Attributing an OEE improvement entirely to the predictive programme will get you challenged, fairly. Measure asset-level breakdown hours as your primary evidence and treat OEE movement as supporting context. The wider measurement discipline is covered in the KPI framework article, and the strategy comparison in preventive versus predictive versus reactive maintenance.

8. Industry 4.0 framing, without the hype

Predictive maintenance is the use case most often wheeled out to justify an Industry 4.0 or smart factory programme. That is reasonable, because it is one of the few digital manufacturing use cases with a calculable return, and dangerous, because it then gets bundled into a transformation programme with a platform-first sequence. Platform-first is how predictive maintenance pilots die. Stripped of the marketing, three Industry 4.0 concepts actually matter to a maintenance practitioner:

• Connectivity to the machine. Standards-based access to equipment data rather than proprietary per-machine integration. OPC UA is the pragmatic answer, and the OPC Foundation specifications determine how painful your next machine integration will be. Specifying OPC UA availability in new equipment purchase agreements is one of the highest-value, lowest-cost things a maintenance function can influence.
• A usable data layer. Somewhere time-series equipment data lands, is retained at adequate resolution, and can be queried by people who are not control engineers. Usually the historian. Without it, every analysis is a bespoke extraction exercise.
• Models and digital twins where they earn their place. A digital twin integrated with the CMMS is genuinely useful for complex assets where a physics model can be compared against live behaviour. It is overkill for a conveyor gearmotor.

On analytics, the honest position is that most achievable value in a plant comes from simple methods: threshold alarms on well-chosen tags, trend extrapolation, and comparing a machine against itself last month or against its siblings. Anomaly detection is the realistic first machine learning step because it learns from normal operation and needs no failure labels. Deep learning has a real place on high-value assets with large labelled datasets, particularly vibration spectral classification, but it is the last step and not the first.

9. Why manufacturing PdM pilots stall

I want to be blunt about this, because the pattern is so consistent that it is close to predictable. Manufacturing predictive maintenance pilots rarely fail on the technology. They fail on two things.

Nobody owns the response to an alert. The pilot is sponsored by engineering, IT or a corporate digital function, while the response depends on maintenance and production, who were not in the room when it was scoped. Alerts arrive with no defined recipient, no service level for triage, and no authority to take a machine down. The first genuinely urgent alert collides with a production schedule, production wins because production always wins in the absence of an agreed process, the machine runs to failure anyway, and the credibility of the programme is spent. The fix is entirely organisational: before the first sensor goes on, agree who triages, within what period, with what authority, and how intervention gets negotiated against a live production plan. Write it down, and get the production manager to sign it.

The model was built on data with no labelled failures. A supervised model that predicts failure needs examples of failure to learn from, findable in the data: a timestamp for when the machine broke, a record of what broke, and enough operating data around that timestamp to see the degradation. In most plants that does not exist in usable form. Downtime is recorded against a reason code chosen from a dropdown by an operator under time pressure. The work order says "replaced bearing" with no failure mode and a completion date days after the event. The historian has tag data but nothing to correlate it against. Teams typically discover this three months into a six-month pilot, after the analytics effort has been contracted.

Two secondary patterns worth naming: pilots scoped on an asset that never fails produce no evidence either way and quietly expire, and pilots on assets whose failures are genuinely sudden produce alerts too late to act on, which reads as model failure when it is actually a candidate-selection failure.

10. A pilot plan you can lift

If I were asked to stand up a manufacturing predictive maintenance pilot with a modest budget and a twelve-month horizon, this is the sequence I would run. Note how much of it happens before any procurement.

The discipline that matters most in that plan is the advisory-mode period. Going live with automatic work order generation on untuned thresholds floods the planners with noise and burns the goodwill you will need later. Run advisory, tune, then automate.

11. Building the business case honestly

Because the downtime cost is calculable, manufacturing business cases can be built properly rather than rhetorically. The structure I would use:

• Benefit side, asset by asset. Historical unplanned downtime hours for that asset, multiplied by the cost per hour of lost output on that line, multiplied by a conservative estimate of the proportion you expect to convert from unplanned to planned. Add avoided secondary damage where the failure history shows cascade damage actually happened, and energy savings where the technique produces them, as with compressed air leak surveys.
• Cost side, in full. Sensors and installation, including production access to fit them. Gateway and network. Annual platform licensing. The OT/IT integration and security work. CMMS configuration. The reliability engineering time to interpret results, which is ongoing and the item most often omitted. Battery replacement, sensor maintenance, and threshold retuning.
• The counterfactual. What would a better preventive regime, a spare holding, or a redundant unit cost instead? A good finance reviewer will ask, and sometimes the honest answer is that a spare motor on the shelf beats a monitoring programme. Saying so builds the credibility you need for the cases where monitoring genuinely wins.

On expected magnitudes, avoid quoting an industry percentage. Published figures vary enormously by sector, asset mix and starting maturity, and importing someone else's number is how you end up defending a target you never believed in. Your own downtime history and your own cost per hour give you a figure you can stand behind.

The idea to walk away with

Manufacturing is the friendliest environment predictive maintenance has. The cost of failure is countable, the constraint tells you where to point the effort, OEE gives you a scorecard you did not have to build, and the data layer is often already installed and paid for. Almost every structural obstacle that makes predictive maintenance hard in a commercial building is softer in a plant.

Which is why the failures are so instructive. When a manufacturing pilot stalls, it is rarely because the physics was unavailable or the analytics inadequate. It is because the programme was aimed at a machine whose failure did not cost anything, or built on a history with no usable record of what broke and when, or handed to an organisation where nobody had the authority to act on the warning. Fix the targeting, fix the labels, name the owner. The technology is the straightforward part.

Final thoughts

If you take one action from this, make it the free one. Before any procurement conversation, pull the last three years of downtime and work order history for your constraint assets and ask what actually broke, how often, and whether anything in the historian moved beforehand. That needs no budget approval, and it will tell you more about whether predictive maintenance will pay on your plant than any vendor assessment.

And spend as much energy on the response process as on the detection technology. A mediocre threshold alarm that reliably produces a triaged work order and a negotiated downtime slot will deliver more reliability improvement than a sophisticated model whose output lands in an inbox nobody owns. Not a comfortable conclusion for anyone selling analytics platforms, but it matches what I see on plant floors.

Related reading: Predictive maintenance: a practitioner's guide, Failure prediction and remaining useful life, SCADA historian integration, IoT integration with CMMS, Asset criticality classification, Preventive vs predictive vs reactive.