The pilot went well. On one press line, a predictive maintenance model picked up a rising bearing temperature twelve days before the bearing would have failed. The maintenance team replaced it during a planned stop, the line kept running, and the plant manager presented the result at the next operations review. Everyone agreed it should be rolled out to the other lines and the other plants.
A year and a half later, the model still runs on one line. The rollout simply never happened, because every next step turned out to need something the pilot did not: a work order in the maintenance system, a slot in the production plan, a spare part on the shelf, an engineer who trusts the alert enough to act on it. This pattern is so common that many operations leaders now treat predictive maintenance AI with quiet scepticism.
The MetroMinds Library helps explain why. It suggests that the model is rarely the weak point. The weak point is everything that has to happen between the alert and the repair.
The data looks ready, which is exactly the trap
The Library holds 317 use cases for maintenance coordination and asset reliability, spread across energy and utilities (91), construction and real estate (67), communications (41), manufacturing (33) and transport (30). Each one is scored on the conditions that make an AI use case work in practice.
On data, these use cases look better than average. Data access and trust scores 4.42 out of 5, against 4.26 for the Library as a whole. Integration readiness is also higher, at 4.17 against 3.96. Sensor data, maintenance histories and asset registers tend to exist, and they are usually reachable. That is why pilots get off the ground so easily.
The picture changes when you look at the work itself. Context volatility is higher (4.48 against 4.25), because conditions on a line change by the hour. Orchestration complexity is higher too (3.65 against 3.39), because a maintenance decision touches planning, stores, production and sometimes quality. The result shows in the feasibility score: 2.82 for maintenance use cases, against 3.30 for the Library.
Almost half of maintenance ideas are hard to deliver
The averages hide how uneven the distribution is. In the Library as a whole, 27 percent of use cases score 1 or 2 on feasibility. For maintenance and asset reliability, that share rises to 49 percent. Almost one in two ideas in this area is genuinely hard to deliver at scale, even though the business value is in line with the rest of the Library (3.75 against 3.82).
This is useful information before you approve a rollout. A pilot on one line usually avoids the hard parts: an enthusiastic engineer reads the alerts, a supportive planner finds a slot, and the data team fixes issues by hand. Scaling means those hard parts arrive all at once, on every line, without the people who made the pilot work.
What actually stops the rollout
When you read the practical context of the maintenance use cases in the Library, the same four dependencies come back again and again.
The alert has to become a work order
A prediction that lives on a dashboard does not change anything. It has to turn into a work order in the maintenance system, with the right asset, the right priority and the right job plan. If an engineer has to retype the alert, the time saving disappears and adoption drops within weeks.
The repair has to fit the production plan
Knowing that a bearing will fail in twelve days is only valuable if you can stop the line in the next eleven. That needs an agreement with production planning about who decides when a maintenance window is opened, and on what evidence. In many plants that agreement does not exist, so every alert becomes a negotiation.
The engineer has to trust the ranking
Maintenance engineers are rightly cautious. If the system cannot explain why it recommends one action over another, they will check everything themselves, and the AI adds work instead of removing it. Trust grows when every recommendation shows its evidence and every override is recorded with a reason.
Each plant is a little different
Asset names, sensor setups and maintenance practices differ between sites. A model trained on one line often needs adjustment before it is useful on the next. Deloitte's work on predictive maintenance makes the same point from the data side: "Data is the fuel of any predictive maintenance engine," and data quality and coverage are a major challenge in getting it running [1].
Where the value of predictive maintenance AI really comes from
Predictive maintenance is often sold on avoided breakdowns. Those benefits are real, but they are also the hardest to prove, because you have to show that a failure would have happened. The Library takes a more cautious route. Across the 317 maintenance and asset reliability use cases, the most common benchmark metrics are error and rework reduction, handling time reduction and review time reduction. Throughput metrics appear far less often.
The , then, mostly price the work of the maintenance engineer: less time assembling evidence, fewer wrong actions, less rework. Avoided downtime can come on top, but only when you have your own baseline of failures, repair costs and lost production to compare against.
That is a sensible way to build a business case, and it matches older evidence on maintenance strategy. A guide written for the US Department of Energy estimated that a functional predictive maintenance programme can deliver "savings of 8% to 12% over a program utilizing preventive maintenance alone" [2]. Those savings depend on a working programme, which brings you back to the work orders, the planning agreements and the trust described above.
How to plan a rollout that survives the second plant
The plants that do scale predictive maintenance usually treat the rollout as a change to how maintenance work is planned, with the model as one part of it. The scenario below shows what that can look like.
Deloitte reports that predictive maintenance can reduce maintenance planning time by 20 to 50 percent [1]. That gain only appears in the later gates, when the prediction flows into planning without manual steps. A pilot that stops at the dashboard never gets there.
Questions to ask before you scale
- How many alerts did engineers accept during the pilot, and what were the main reasons for rejecting the rest?
- Does an accepted recommendation create a work order automatically, or does someone retype it?
- Who decides when a predicted failure justifies stopping a line, and is that written down?
- Are the critical spare parts for the covered assets in stock, or does the alert only move the waiting time?
- Which differences between your plants (asset names, sensors, practices) need to be solved before the second site starts?
- Is the business case built on engineer time and rework first, with avoided downtime as a separate, evidenced stream?
If several of these questions have no clear answer, the next step is probably not another line. It is fixing the dependency that will stop every line after it. Our article on why four in ten manufacturing AI ideas are harder to deliver than they look goes deeper into how to spot those dependencies early.
Spotting the hard part before the pilot starts
MetroMinds scores every use case on , and , so you can see before a pilot starts whether the hard part sits in the data, the integration or the work around it. The value and feasibility matrix shows which maintenance ideas belong in and which are Strategic bets that need preparation first.
The AI Readiness Scan adds the organisational view. It compares what your portfolio of use cases demands with what your organisation can currently deliver, which is exactly the gap that stops predictive maintenance between the first and the second plant.
How ready is your organisation to scale AI beyond the pilot line? Take the AI Readiness Snapshot
Sources
- Deloitte Analytics Institute, "Predictive Maintenance", position paper, issue 7/2017.
- Pacific Northwest National Laboratory for the US Department of Energy, Federal Energy Management Program, "O&M Best Practices: A Guide to Achieving Operational Efficiency", Release 2.0, July 2004.
- MetroMinds Library, 4,980 AI use cases with benchmark ranges based on real-world implementations, August 2026.
