On this page
Share of unplanned downtime attributable to equipment failure (Siemens, True Cost of Downtime, vendor-reported).
Pilot on one asset class: baseline, shadow, enforce, readout.
Deployed inside the plant boundary, with machine data never leaving it.
Challenge
Machine-health tools now write work orders directly into SAP PM, Maximo or MaintainX. Some of those jobs are wrong: duplicates that burn technician hours, parts pulled against a fault that was never there, and occasionally a job that sends a crew to the wrong asset.
- Equipment failure drives most unplanned downtime. Roughly 42% of incidents (Siemens, True Cost of Downtime, vendor-reported).
- A wrong work order costs twice. Once in technician hours, again in parts pulled against a fault that did not exist.
- The signal may be stale before it is acted on. A reading that is out of range or out of date can trigger a confident dispatch.
What is checked before a crew is pulled
- Is one already open?Matching work already dispatched or scheduled is stopped here.
- Is the asset in that state?In service, in changeover, already down, or with a contractor.
A proposed work order
Confident, specific, and possibly against a fault that is not there.
- Is the reading current?Freshness and range checked before the fault is treated as real.
- Who is being asked?A named owner, not a shared queue, with the reason attached.
Solution
A predictive tool can be right about a machine and wrong about the moment. The work order is checked against what the asset is actually doing before a crew is pulled.
- Validated before the order is written. Machine state, sensor freshness and open-order history are checked first.
- Duplicates caught against open jobs. An order matching work already dispatched is stopped rather than queued.
- Critical assets need a person. Hard limits keep high-consequence equipment behind a human decision regardless of what any tool concludes.
- Reasoning attached to the dispatch. The technician receives why the job was raised, not just that it was.
What the Check Runs Before a Crew Is Pulled
The order is not reviewed after it lands in SAP PM, Maximo or MaintainX. It is checked on the way there, at the only moment when stopping it still costs nothing.
- Is there already an open order on this asset. A proposal matching work already dispatched or already scheduled is stopped rather than queued behind it. Duplicates are the highest-volume failure and the cheapest to remove.
- Is the asset in the state the tool assumes. In service, in changeover, already down, or handed to a contractor. A correct diagnosis against the wrong machine state is still a wrong dispatch.
- Is the reading current and in range. Freshness and range are checked before the fault is treated as real. A dead or drifting sensor produces a clean-looking signal, and that is the one that sends a crew out for nothing.
- Do the parts and the skills exist. A job dispatched against a part that is not in the store, or a skill not on shift, becomes a wasted trip and a reservation against inventory that was never needed.
- Does the priority match your criticality matrix. Priority comes from the plant's own matrix, per asset class and per site, not from the tool that raised the job.
What the Technician Sees, and What the Plant Keeps
A dispatch that arrives without its reasoning is an instruction. A dispatch that arrives with it is a decision the technician can disagree with on the walk to the asset, before a panel is opened.
- The reason travels with the job. Which reading moved, what it was compared against, and what the check found. The person nearest the machine gets the evidence rather than a work-order number.
- A rejection is data, not noise. When a technician closes a job as no fault found, that outcome is recorded against the signal that raised it. The pattern becomes visible instead of becoming crew folklore.
- Critical assets stay behind a person. Hard limits keep high-consequence equipment out of automatic dispatch regardless of what any tool concludes, and the limits are set per asset class before go-live.
- The record outlives the tool. It sits in the plant's own environment. If the machine-health vendor is replaced next year, the history of why jobs were raised does not leave with them.
The tool is good at finding faults. That is not the half that pulls your crews.
The acting half of the loop is the part the plant needs to own.
Outcome Derived
This is a 60 to 90 day pilot on a single line, cell, category or product family. The figures below are what the pilot measures against a baseline captured in its first two weeks. They are targets and instrumentation, not results already delivered.
- Duplicate and false-fault orders stopped. Counted against the baseline of orders raised in weeks 1-2.
- Technician hours returned. Measured as hours not spent on jobs the check prevented, on the one asset class chosen.
- Parts consumption against real faults. Designed to end withdrawals made against faults that were never confirmed.
Highlights
- One checkpoint sits between the machine-health tool and SAP PM, Maximo or MaintainX. The tool keeps finding faults; what reaches a crew is governed by the plant.
- Open-order history, asset status, sensor freshness, parts and skills availability and the criticality matrix are checked before the order is written.
- Routine lubrication and inspection flow through untouched. Anything that could stop a critical asset waits for a reliability engineer.
- A vendor update cannot quietly change what lands in the work-order system, because the rules that decide sit outside the vendor's software.
- The trail runs from the reading to the diagnosis to the job to the check to the sign-off, so a warranty dispute is a lookup.
Frequently asked questions
Do we have to replace our predictive-maintenance tool?
No. It keeps doing the part it is genuinely good at, which is spotting faults. The checkpoint sits between it and SAP PM, Maximo or MaintainX so the plant decides which of those jobs reaches a crew. The tool's diagnosis is not overwritten and nothing is ripped out.
Will this slow the crews down?
Routine lubrication and inspection orders pass straight through. Only jobs that could stop a critical asset wait for a reliability engineer, and they arrive with the evidence attached for a single approve or reject. The check adds a moment to a small share of orders, not a queue in front of all of them.
What stops a duplicate work order?
Open-order history is read before the order is written. A proposal matching work already dispatched or already scheduled on the same asset is held with the matching order named, rather than joining the queue behind it and consuming a second crew visit.
Is there risk to the line while we try it?
The first weeks are watch-only. Every order the tool would open is checked and scored inside your own environment and nothing is blocked, so the plant sees what would have been caught before anything changes on the floor. Machine data stays inside the plant boundary throughout.








