Predictive maintenance that starts from the records you already have, delivers into the work order you already raise, and states honestly what each asset can and cannot be predicted for.
The value of predictive maintenance is not a failure probability. It is the maintenance action that can be taken early enough to prevent the disruption.
These six get grouped under one label and sold as one capability. They need different data, cost different amounts and answer different questions. Knowing which one you are buying is the whole conversation.
Unplanned equipment downtime
The cost everyone quotes and almost nobody measures by asset. The first useful exercise is attributing last year’s unplanned downtime to specific assets and specific failure modes, which usually reveals that a small number of modes account for most of it.
Reactive and calendar-based maintenance
Calendar maintenance is not a failure of thinking. For many assets it is correct and cheaper than predicting. The problem is applying it uniformly, so critical assets are under-maintained and trivial ones consume the trades’ week.
Limited equipment condition visibility
Most plants have far more data than they think on their critical assets, inside the control system, and far less than they think on the ancillary equipment that actually stops production.
Fragmented maintenance and asset data
The CMMS has work orders, the ERP has costs, the historian has signals and a spreadsheet has the real asset list. The asset identifier differs in each, which is the first thing to fix and the least interesting to fund.
Inconsistent failure and downtime records
This is the central problem on this page. Without a failure mode taxonomy and a usable failure date, the only honest options are threshold monitoring and anomaly detection.
High maintenance costs and resource constraints
The trades’ time is the real constraint, not the budget line. A programme that generates more work than the plant can execute makes things worse by adding an unactionable backlog.
Spare parts availability challenges
A prediction with a six-week lead time on a part you do not hold is an advance notice of downtime. Parts holding and prediction lead time have to be designed together.
Difficulty prioritising maintenance activities
Prioritisation needs criticality, and criticality is not asset cost. It is the consequence of the failure, which is usually downstream of the asset and sometimes nowhere near it.
Limited visibility into asset health and lifecycle performance
Repeat failures are the clearest signal in any maintenance dataset and the least examined, because each one is closed as an individual work order and nobody looks across them.
That order is deliberate and it is the opposite of how most of these programmes run. Instrumenting first produces data about assets whose failure does not matter, which is the most common way the budget is spent before the value is found.
Step 1
Asset criticality and reliability assessment
Rank by consequence of failure, not by asset value. The consequence is usually downstream: a cheap compressor that stops four lines outranks an expensive machine with a parallel route around it.
Rank by consequence of failure, not by asset value. The consequence is usually downstream: a cheap compressor that stops four lines outranks an expensive machine with a parallel route around it.
Step 2
Maintenance process and data maturity evaluation
How work is raised, planned, executed and closed, and what share of closed work orders carry a usable description. This number determines which of the six capabilities in section 2 is available to you.
How work is raised, planned, executed and closed, and what share of closed work orders carry a usable description. This number determines which of the six capabilities in section 2 is available to you.
Step 3
Equipment failure mode identification
For the critical assets, which modes actually occur, how they present, and how fast each one develops. This comes from the trades and the reliability engineers, not from the data.
For the critical assets, which modes actually occur, how they present, and how fast each one develops. This comes from the trades and the reliability engineers, not from the data.
Step 4
Sensor and maintenance data assessment
What the controls already expose, what the historian retains and at what rate, and what would need adding. Often less needs adding than expected, and what needs adding is on the ancillary equipment.
What the controls already expose, what the historian retains and at what rate, and what would need adding. Often less needs adding than expected, and what needs adding is on the ancillary equipment.
Step 5
Asset health model development
Built per failure mode and per asset class rather than per asset, so one model covers a fleet and a new asset of the same class inherits it.
Built per failure mode and per asset class rather than per asset, so one model covers a fleet and a new asset of the same class inherits it.
Step 6
Predictive maintenance analytics implementation
Scoring, thresholds, alerting and the explanation that travels with the alert. A technician who cannot see why will not act on it twice.
Scoring, thresholds, alerting and the explanation that travels with the alert. A technician who cannot see why will not act on it twice.
Step 7
CMMS and maintenance workflow integration
The prediction becomes a work order with a trade, an estimated duration, a parts list and a target window. This stage is where most programmes fail, and it is usually scoped as an afterthought.
The prediction becomes a work order with a trade, an estimated duration, a parts list and a target window. This stage is where most programmes fail, and it is usually scoped as an afterthought.
Step 8
Pilot validation and maintenance team adoption
Validated on the trades’ terms: did the finding match what was found on the machine. Their feedback is also the only label source you will ever get, so capturing it is part of the design.
Validated on the trades’ terms: did the finding match what was found on the machine. Their feedback is also the only label source you will ever get, so capturing it is part of the design.
Step 9
Continuous model and reliability optimisation
Recalibration after each confirmed or missed failure, and a periodic review that moves assets between predictive, preventive and run-to-failure as the evidence changes.
Recalibration after each confirmed or missed failure, and a periodic review that moves assets between predictive, preventive and run-to-failure as the evidence changes.
Each item below states what it produces and where the output lands, because output that lands nowhere is the standard failure mode in this category.
Equipment condition monitoring
Continuous assessment of signals against the machine state they were recorded in. Produces a current condition with a trend. Lands on the maintenance planner’s screen and in the asset record.
Asset health scoring
A composite score per asset, with the contributing factors visible. A score with no breakdown is unusable, because the planner needs to know what to inspect.
Failure risk prediction
Elevated risk of a specific mode within a stated window. Produces a risk and a confidence, and the window is set by the P-F interval rather than chosen for convenience.
Predictive maintenance alerts
Routed to the trade that would act, carrying the evidence, the recommended inspection and the history of similar findings on that asset class.
Remaining useful life estimation where feasible
Built only where one dominant degradation mode exists and is measurable. Reported as a range with an interval, never as a date, and the page says so because the number will otherwise be read as a date.
Maintenance prioritisation and planning
Ranking the open and predicted work by consequence and by window, against the trades and parts actually available. A priority list that ignores capacity is a wish list.
Asset reliability analytics
Fleet-level reliability: where availability is actually being lost, which modes dominate, and whether a design or duty change would beat any maintenance strategy.
Maintenance history and failure analysis
The structured history that everything else depends on: failure modes coded, failure dates separated from reporting dates, and planned work distinguished from breakdowns.
Spare parts and maintenance resource intelligence
Holding and positioning decisions from usage, criticality and lead time. Often the fastest financial return on this page, and it is an inventory decision rather than a modelling one.
Asset lifecycle performance analytics
Repeat failure patterns, cost trajectory and the replacement case. The asset that fails the same way four times a year is a capital decision being handled as a maintenance one.
These are the standard applications. The difficulty is stated for each, because in this category the difficulty is almost never the algorithm.
Rotating equipment condition monitoring
Continuous assessment of the assets that spin, which is where the established methods are strongest.
Motor, pump, compressor and gearbox health monitoring
The ancillary fleet, which rarely gets instrumented and frequently stops production.
Bearing wear and vibration anomaly detection
Detecting developing bearing faults from vibration signatures.
Equipment failure risk identification
Flagging assets at elevated risk across a fleet, to direct inspection effort.
Maintenance work order prioritisation
Ordering the open and predicted work by consequence, window and available capacity.
Maintenance schedule optimisation
Grouping work into production windows to reduce the number of interventions.
Critical spare parts planning
What to hold, how much and where, from usage, criticality and lead time.
Repeat failure and root cause analysis
Finding assets and modes that recur, and distinguishing a maintenance problem from a design or duty problem.
Asset replacement and lifecycle planning
Building the capital case from failure cost trajectory and reliability trend.
The architecture is unremarkable and the two ends are what matter. Most of the engineering difficulty is at the signal end, and most of the delivery risk is at the work order end.
Industrial sensor and historian integration
Reading from the historian and the control system where the data already exists, adding instrumentation only where a named failure mode requires a signal that is not currently captured.
Equipment condition monitoring architecture
Collection, machine state alignment, feature extraction and scoring, with the machine state treated as a required input rather than an optional one.
Time-series data processing
Resampling, gap handling and feature extraction at the rate each mode requires. The rate is set by the physics of the mode, and where it exceeds what the historian retains, the processing happens near the asset.
Anomaly detection and machine learning
Anomaly methods where failures are few, classification where they are not. The choice follows from the failure count established in section 3, not from preference.
Reliability and failure analysis models
Established reliability methods on the coded history: failure distributions, time between failures by mode, and the comparison between a maintenance strategy and a design change.
Asset health analytics platforms
Selected against the estate and the existing platform commitments. The integration into the maintenance system matters more than the analytics features, and is usually assessed less.
CMMS, EAM, ERP and MES integration
Work order creation, asset and cost synchronisation, and production schedule awareness so a recommended window is a window that exists. Each interface specified as a contract with a stated system of record.
Edge and cloud analytics
High-rate processing near the asset, aggregation and model training centrally. The split is decided by data rate and by whether the function must survive a lost link.
Maintenance dashboards and alerting
A planner view and a technician view, which are different products. The planner needs the queue and the capacity. The technician needs one asset, the evidence and what to check.
MLOps and predictive model lifecycle management
Versioning, monitoring for drift, retraining triggers and a record of which model version produced which recommendation. Required for any audit of a maintenance decision after an incident.
Maintenance decisions have safety consequences and the asset sits inside somebody’s safety case. The controls below exist so that the analytics can inform a maintenance decision without becoming one.
Asset data quality and validation
The sensor is validated before the analytic. A drifting, failed or wrongly scaled sensor produces a confident wrong answer, and the most common false alarm in this category is a sensor fault rather than an asset fault.
Maintenance decision ownership
Every recommendation has a named role that decides. The model produces evidence and a suggestion. It does not approve, schedule or close work.
Model confidence and uncertainty management
Confidence reported with every output, and a stated position on what happens below the confidence floor: the finding is held for inspection rather than raised as a prediction.
False-positive and missed-failure controls
Both tracked and reported, and the tolerable rate for each agreed with maintenance before go-live. The two trade against each other, so the threshold is a maintenance decision rather than a modelling one.
Human review of maintenance recommendations
A planner reviews before work is scheduled. For critical assets and for any recommendation that would change a maintenance strategy, reliability engineering reviews as well.
Equipment safety and operational restrictions
Any asset where a maintenance decision has a safety consequence is identified, and its recommendations carry an explicit engineering review requirement. The analytics does not override an engineering restriction.
Maintenance history and decision traceability
What was recommended, on what evidence, by which model version, who decided and what was found. Reconstructable after an incident, which is the condition that makes it worth building properly.
Model validation and change management
Validated against held-out periods and against the trades’ findings, revalidated on a trigger rather than on a calendar. Triggers include a change to the asset, to its duty, to the instrumentation or to the maintenance strategy.
Industrial cyber security and data access
Read-only from the control network, through a controlled conduit, with named individual accounts. No write path to a controller from the analytics layer under any circumstances.
The two are warning lead time and false alarm rate. Everything else can look acceptable while those two quietly end the programme, because they decide whether the trades act on the next alert.
Unplanned downtime trends
By asset and by failure mode, against the baseline measured before the programme started. Measured in production impact as well as in hours, since the hours are not equal.
Mean time between failures
Per asset class and per mode, from the coded history. Meaningless as a single plant-level figure and useful as a per-class trend.
Mean time to repair
Separated into waiting for the trade, waiting for the part and actually working. The split is where the improvement usually is, and it is rarely in the third component.
Asset availability and reliability
Availability for the assets in scope, with planned and unplanned stoppage separated so that a shift from unplanned to planned is visible as the gain it is.
Maintenance cost and resource utilisation
Cost by asset and the trades’ time by activity type. The target is usually a shift in where the time goes rather than a reduction in the total.
Prediction accuracy and warning lead time
Reported together and never separately. A highly accurate prediction with four hours of lead time on a part with a two-week lead time has no operational value, and reporting the accuracy alone conceals that.
Alert effectiveness and intervention outcomes
False alarm rate, the share of alerts attended, and what was found when they were. This is the trades’ experience of the system expressed as a number, and it predicts adoption better than anything else here.
Repeat failure rates
By asset and mode. A persistent repeat after intervention indicates a design or duty problem that maintenance cannot fix, which is a valuable finding rather than a failure of the programme.
Predictive model drift and recalibration
Monitored against input distribution and outcome, with recalibration triggered by a change to the asset, its duty or its instrumentation rather than by a schedule.
Maintenance return and continuous improvement
Against the measured baseline, with the avoided failures stated as what they are: an estimate built on an assumption about what would have happened. Honest framing here protects the programme when the assumption is challenged.
Reduced unplanned downtime risk on the assets where the failure mode develops slowly enough to be caught. On the rest, a better strategy rather than a prediction
Improved equipment reliability, most of it from repeat failure analysis rather than from prediction, which is the part clients consistently underestimate
Better maintenance prioritisation, with the work ordered by consequence and against the capacity that actually exists
Longer useful asset life where the dominant failure mode is addressable by maintenance. Where it is not, a clearer replacement case
Improved maintenance resource planning, including the parts holding decision, which is frequently the fastest financial return here
Better asset lifecycle decisions, because the asset that fails the same way four times a year becomes visible as a capital question
If a previous predictive maintenance programme produced alerts nobody acted on, the cause is almost always one of two things: the lead time was shorter than the response, or the alert never became a work order. Both are fixable and neither is a modelling problem.
CaliberFocus builds predictive maintenance on the maintenance record rather than the sensor alone. We rank assets by the consequence of failure, turn free-text work order history into a failure mode taxonomy, bound lead time honestly by the P-F interval, and deliver every prediction as a work order with a feedback field the trades will actually complete.
- Criticality ranked by consequence of failure, not asset value
- A failure mode taxonomy built from your work order history
- Lead time bounded honestly by the P-F interval
- Predictions delivered as work orders, with findings captured
Security & Compliance
