From Asset Scores to Maintenance Decisions: An Operating Model for Maximo Health and Predict
An asset health score has no operational value until someone uses it to make a better decision. The same is true for anomaly alerts, failure probabilities, and predicted failure dates. These outputs can focus attention, but they do not know the maintenance window, safety consequence, spare availability, production plan, regulatory obligation, or whether the underlying data is trustworthy.
IBM Maximo Health and Maximo Predict provide a platform for bringing those signals into the asset-management process. IBM documents unified asset and location dashboards that can show information from Health, Predict, Monitor, and Manage; hierarchical views of child assets and locations; meter history; work queues; custom scores; and predictive outputs such as failure probability or days until a failure mode. In Maximo Health 9.1, users can compare up to six meters for a selected date range and download meter data for offline analysis. Predict can combine performance data, maintenance records, inspection information, and environmental data through deployed models.
The implementation challenge is not primarily the formula or model. It is building a closed decision loop. Data must represent the physical asset correctly. Scores need transparent meaning and ownership. Predictive models need technical and operational validation. Exceptions need to reach a queue with an accountable reviewer. Approved actions need to become planned work. Completed work and observed outcomes need to feed back into score and model review.
Without that loop, dashboards become another place to look and work queues become another backlog. With it, Health and Predict can support a shift from uniform calendar maintenance toward risk-informed and condition-based decisions, while retaining human accountability. This guide lays out the data, governance, workflow, and measurement practices required to make that shift responsibly. It intentionally avoids universal thresholds because criticality, failure behavior, data quality, and maintenance economics differ by asset class and operating context.
1. Establish Asset, Failure, and Data Readiness Before Modeling
Start with a bounded asset class and a decision problem. “Improve reliability” is too broad. Better statements are: identify pumps at elevated near-term bearing risk, prioritize transformer inspections, or detect whether a critical compressor may fail before its next planned preventive-maintenance event. A bounded problem makes it possible to identify required signals, labels, review cadence, and action options.
Validate the asset registry. Each modeled asset needs a stable identity, correct location and hierarchy, installation context, status, meter association, and maintenance history. A sensor mapped to the wrong asset can produce a convincing but invalid score. Hierarchical views in Health are useful only when parent-child relationships reflect the physical system and the way consequence propagates.
Create a data-readiness table:
| Data domain | Questions to answer | Example evidence |
|---|---|---|
| Asset master | Is identity stable and hierarchy correct? | Sampled field verification |
| Meters and sensors | Are units, frequency, timestamps, and mappings valid? | Trend review and calibration records |
| Work history | Are failure, cause, remedy, and dates consistently recorded? | Coded-work audit |
| Operating context | Can load, duty cycle, starts, or environment be associated? | Context feature coverage |
| Failure labels | Is the failure event unambiguous? | Reliability-approved labeling rules |
| Missing data | Is absence random, planned, or a device fault? | Gap classification |
Do not clean data by silently deleting inconvenient periods. Planned outages, sensor replacements, maintenance interventions, and abnormal operating modes may be the most informative events. Mark them and decide how they should influence a score or training set.
Measure readiness by coverage and consistency, but set thresholds locally. One asset class may have dense time-series data and weak failure coding. Another may have excellent work history but only monthly inspections. The appropriate first use may therefore be a transparent condition score rather than a predictive model.
Assign data ownership. Reliability engineering should define failure semantics. Maintenance should own work-history quality. Operations should explain operating regimes. Instrumentation teams should own measurement quality. Data scientists should not be expected to infer every physical and procedural nuance from tables alone.
The readiness gate is reached when the team can trace every important input from source to asset, explain known gaps, and state which maintenance decision the output will inform.
2. Build Health Scores That People Can Explain and Challenge
A health score is a decision aid, not an objective property of the machine. It combines selected indicators, transformations, weights, and thresholds. The design must therefore be documented in language that a reliability engineer and planner can understand.
Separate condition, criticality, and risk. Condition describes evidence about current physical state. Criticality describes consequence or importance in the operating system. Risk generally combines likelihood and consequence over an explicit horizon. Combining all three into one number can simplify prioritization, but it can also hide why an asset ranks highly. Preserve the components so users can distinguish “poor condition on a low-consequence asset” from “moderate condition on a safety-critical asset.”
For each score, publish a score card:
Score name: Pump mechanical condition
Population: centrifugal process pumps, class CP-01
Purpose: weekly screening for engineering review
Inputs: vibration indicator, bearing temperature, seal leakage inspection
Normalization: documented asset-class limits
Missing-data rule: score incomplete if required vibration is stale
Aggregation: weighted components, version HC-PUMP-03
Owner: rotating equipment reliability lead
Review cadence: quarterly and after material sensor changes
Permitted action: review and diagnostic work request, not automatic shutdown
Use Maximo Health dashboards to expose component evidence, meter history, child-asset contribution, and related Manage data. IBM's 9.1 meter comparison of up to six meters can help engineers inspect whether a score change aligns with related signals. CSV export can support an approved offline review, but exported data should remain governed and traceable to its date range and source.
Design missing and stale data behavior explicitly. A healthy score based on stale measurements is dangerous. Consider displaying completeness or freshness alongside the score, or withholding a conclusion when required inputs are absent. Distinguish “no adverse evidence” from “no evidence.”
Version every score definition. If weights, thresholds, normalization, or required inputs change, record the effective date and rationale. Otherwise, a historical trend may appear to show asset improvement or deterioration when only the scoring method changed. Back-testing a new definition against prior periods can reveal how queue volume and prioritization would shift.
Finally, let domain experts challenge the score. Review false alarms, missed degradation, asset-class exceptions, and operating modes. A score that cannot be questioned will not earn trust, and a score that never changes despite new evidence is not being governed.
3. Validate Predictive Models as Maintenance Products, Not Data-Science Demos
Maximo Predict supports outputs such as probability of failure, predicted failure dates, and anomaly indications for groups of assets. IBM documentation describes using default or custom notebooks, with deployed models providing predictions for individual assets. The technical model is only one part of the product. The complete product includes population definition, data pipeline, deployment, interpretation, queueing, action policy, and outcome monitoring.
Define the prediction precisely. “Failure probability” needs a failure mode, population, prediction horizon, and observation point. “Days to failure” needs rules for censored assets and maintenance interventions. An anomaly needs an operating context so normal startup behavior is not treated like abnormal steady-state behavior.
Split validation in a way that reflects time and asset grouping. Randomly mixing rows from the same asset across training and test sets can leak asset-specific patterns. Use time-aware and asset-aware evaluation where appropriate. Review performance by operating regime, site, manufacturer, age band, and other relevant segments. A model can look acceptable overall while failing on the small group of highest-consequence assets.
Do not stop at a generic accuracy value. Evaluate measures relevant to the decision:
How much warning time is available before the event?
What proportion of reviewed alerts lead to useful action?
Which failures were missed, and what was their consequence?
How stable are predictions when inputs are delayed or missing?
Is probability calibration adequate for the intended ranking?
How many assets enter the queue at the proposed threshold?
Can the organization inspect that volume before signals become stale?
Choose thresholds with capacity and consequence in mind. Lowering a threshold may catch more potential failures but overwhelm reviewers. Raising it may reduce noise but miss important degradation. Use back-testing and a shadow period in which predictions are reviewed without automatically changing maintenance. Compare predictions with actual findings and planned work.
Document human authority. Predictive output can recommend inspection, diagnostic testing, work prioritization, or planning review. Safety-critical shutdowns and major maintenance deferrals generally require approved operational procedures and accountable human decisions. The model should not quietly exceed its authorized role.
Monitor drift after deployment. Changes in sensor firmware, maintenance practice, asset population, operating load, coding quality, and failure definitions can all alter model behavior. Track input distributions, missingness, queue volume, prediction stability, reviewer disposition, and observed outcomes. Set review triggers and a method to suspend or roll back a model version.
4. Convert Signals into Governed Work Queues and Maintenance Actions
A dashboard asks someone to remember to look. A work queue assigns a decision. IBM documents Maximo Health work queues, including administration of access permissions and visibility through the Operational dashboard. Maximo Predict can use queues to identify assets with high failure probability or assets predicted to fail before the next preventive-maintenance work generation. These capabilities should be configured around a clear operating process.
Every queue needs a charter:
| Element | Definition |
|---|---|
| Entry rule | Score, prediction, freshness, asset class, and threshold |
| Owner | Named role or team |
| Review cadence | Continuous, daily, weekly, or outage cycle |
| Required evidence | Trends, work history, alerts, inspection, operating context |
| Dispositions | Accept, monitor, inspect, create work, suppress with reason |
| Escalation | Consequence and aging rules |
| Exit rule | Action created, condition resolved, invalid data, or approved suppression |
Avoid sending every analytical exception directly to a work order. First establish whether the signal is technically valid and operationally relevant. A reliability engineer may inspect meter history, compare related meters, review child assets, check recent maintenance, and consult operations. The result might be a diagnostic work order, a route inspection, a planning change, a sensor correction, or no action with a documented rationale.
When work is created, preserve lineage. Link the work request or work order to the originating asset, score or prediction type, model or score version, evaluation time, and reviewer decision. Use structured fields or governed relationships where possible rather than placing all context in free-text descriptions. This allows later analysis of whether alerts produced useful work.
Manage queue aging. An unreviewed high-priority signal loses value as the horizon shrinks. Define escalation based on consequence, predicted horizon, and queue age. Also define suppression carefully. A known maintenance outage or faulty sensor may justify temporary suppression, but suppression needs an owner, reason, and expiration date.
Integrate with existing planning. Reliability recommendations still require job scope, labor, materials, permits, safety review, and an executable window. The queue process should not bypass work-management controls. Its purpose is to improve prioritization and timing using condition and predictive evidence.
Finally, measure the queue as a process. Track incoming volume, age, disposition, conversion to work, duplicate signals, invalid-data cases, and outcomes. A growing queue may indicate deteriorating assets, an overly sensitive threshold, a broken data feed, or insufficient review capacity. The number alone cannot explain which.
5. Close the Loop with Findings, Outcomes, and Lifecycle Governance
Condition-based maintenance improves only when completed work returns useful evidence. Require technicians and reliability reviewers to record what was found: confirmed defect, no fault found, measurement error, operating-condition explanation, failure mode, cause, remedy, and replaced component where applicable. Use configured domains and classifications for analysis, supplemented by concise notes.
Create a lineage chain:
Input data and timestamp
-> score/model version and output
-> queue entry
-> reviewer disposition
-> work request/order
-> inspection and repair findings
-> post-maintenance condition
-> score/model performance review
This chain supports both technical improvement and governance. If a model generated many alerts but findings were consistently unrelated, the team can examine labels, features, threshold, or workflow. If a health score improved after maintenance, engineers can check whether the input signals changed as expected rather th
