Maximo APM in 2026: Health, Predict, Monitor, and the Reliability Strategies That Tie Them Together
A practitioner's guide to Maximo Asset Performance Management in 2026 covering Health scoring, Predict models, Monitor ingestion, and how Reliability Strategies connects them into a coherent asset lifecycle workflow.
Introduction
For most of Maximo's history, the platform was a work order system. It was a very good work order system, with deep capabilities in inventory, purchasing, and asset master data, but its primary job was to help maintenance teams plan, schedule, and execute work. Asset performance management was something that lived in a different system, often a different vendor, and the integration between the two was a constant source of friction.
Maximo Application Suite changed that. The acquisition of Maximo's APM capabilities, and their integration into the suite alongside Manage, has produced a single platform that can hold the asset, the work, and the performance data in one place. The result is not perfect, and the integration is not seamless, but it is the closest thing to a unified asset lifecycle platform that the industry has produced.
This article is a practitioner's guide to Maximo APM as it stands in mid-2026. We are going to walk through the four applications that make up the APM story: Maximo Health for asset scoring, Maximo Predict for AI-driven failure forecasting, Maximo Monitor for sensor ingestion, and Maximo Reliability Strategies for the RCM methodology. We will cover how they fit together, how they differ, and the field-tested patterns that make them work in practice.
The intended audience is the reliability engineer, the maintenance planner, and the asset manager. You are the one who has to turn a vendor's claim of "47 percent reduction in unplanned downtime" into a real, defensible program. We are going to assume you have some Maximo experience, and we are going to assume that you have been asked, at least once, to justify an investment in predictive maintenance.
The goal is for you to walk away with a working mental model of the current APM architecture, plus three or four patterns you can apply in your own environment this quarter.
Maximo Health: Asset Scoring That Surfaces What Matters
Maximo Health is the entry point for most APM programs. It provides asset health scoring, asset criticality scoring, and risk scoring, all driven by the data that already lives in Manage. The scoring is configurable, but the default scoring models that ship with the product are a reasonable starting point for most environments.
The default health score is a weighted combination of several factors: the number of open corrective work orders, the number of open service requests, the remaining useful life (if a Predict model exists), the chronological age as a proportion of expected life, and the asset's criticality. The weights are tunable, and the formula is visible in the Health application, which means you can defend the score in a meeting with the operations team. That matters more than it sounds. A black-box score gets challenged; a transparent score gets used.
The default criticality score is a function of the asset hierarchy and the consequence of failure. An asset at the top of a critical process has a higher criticality than an asset at the edge. The score is used as a multiplier in the health formula, so a high-criticality asset with a moderate health score is a higher risk than a low-criticality asset with a similar health score. The risk score is the most actionable output: it is what you should be sorting your work queues by.
A practical pattern: start with the default scoring models and tune them based on what you learn from the first 90 days of use. The temptation is to spend weeks building a custom scoring model before you turn the feature on. That is a mistake. The default models are good enough to start, and you will learn more from real usage than you will from a whiteboard session. Tune in increments, and document each change.
# Example: a Health score configuration for rotating equipment
apiVersion: mas.ibm.com/v1
kind: HealthScoreProfile
metadata:
name: rotating-equipment-v1
spec:
appliesTo:
assetClass: ROTATING
factors:
- name: openCorrectiveWO
weight: 0.25
maxValue: 10
- name: openServiceRequests
weight: 0.15
maxValue: 5
- name: remainingUsefulLife
weight: 0.30
maxValue: 1.0
- name: chronologicalAge
weight: 0.10
maxValue: 1.0
- name: criticality
weight: 0.20
maxValue: 100
riskFormula: "((100 - health) / 100) * criticality"
alertThresholds:
- level: urgent
riskAbove: 75
- level: high
riskAbove: 50
- level: medium
riskAbove: 25
- level: low
riskAbove: 0
The example above is a simplified Health score profile. The weights sum to 1.0, the risk formula combines health and criticality, and the alert thresholds define the four priority categories. In production you would version this profile, review changes with the reliability team, and roll it out through the standard Health administration flow.
A field-tested pattern is to create a Health Work Queue in the Work Queue Manager. The queue surfaces the assets that exceed the risk threshold, and the planner can act on them. The queue is a living artifact: as work orders are created and closed, the assets move in and out of the queue automatically. The planner does not have to remember to refresh; the system does it for them.
Maximo Predict: AI That Forecasts Failure
Maximo Predict is the AI-driven failure forecasting capability in the suite. It takes historical failure data from Manage and time-series data from Monitor, builds a model for each asset (or asset class), and forecasts the probability of failure, the days to failure, and the most likely failure mode. The output is a numeric score that can be consumed by Health, by a work queue, or by a custom dashboard.
The most important thing to understand about Predict is that it is a per-asset (or per-asset-class) model. There is no single "Predict model" that works for everything. The model that predicts failure on a pump is different from the model that predicts failure on a switchgear cabinet. The training data comes from your environment, which means the model is only as good as the historical data you have.
The minimum data requirement is roughly 18 months of failure history with consistent failure codes. If your failure codes are inconsistent (the same defect logged under three different codes by three different crews), the model will treat three failures as one. The fix is the same as for Work Order Intelligence: clean up the failure code hierarchy before you turn the model on.
A practical deployment pattern: pick a single asset class with a clean failure history, build a model, and validate it against the most recent 12 months. The validation step is where you learn whether the model is useful. A model that predicts failure 30 days in advance with 80 percent accuracy is a useful model. A model that predicts failure 30 days in advance with 50 percent accuracy is a model you should not put into production.
The 9.x releases have made the validation step easier. The Predict administration application includes a holdout test feature that lets you train on a subset of the history and validate against the rest, without exposing the model to production. Use it. A model that has not been validated is a model you do not understand yet.
Maximo Monitor: Sensor Ingestion at Scale
Maximo Monitor is the sensor ingestion and processing application in the suite. It takes data from PLCs, SCADA systems, IoT sensors, and other operational data sources, normalizes it, and exposes it through time-series storage and analytics. The output is consumed by Predict (for model training), by Health (for real-time condition visibility), and by the Alerts application (for threshold-based notifications).
The 9.2 release simplified the architecture significantly. Monitor can now run standalone, without the IoT application and without Kafka. For pilots and smaller deployments, this is a meaningful reduction in operational cost. For larger deployments, the full IoT-to-Monitor stack is still the right choice, and the hierarchical analytics that roll child metrics up to the parent level are a meaningful capability.
The practical question is always the same: how do I get the data in? The answer depends on the source. For modern PLCs, there is typically a direct connector. For legacy SCADA systems, an OPC-UA bridge is the common pattern. For remote sensors, the new Edge Data Collector allows processing at the edge with summary data forwarded to Monitor. For one-off pilots, the CSV upload is the fastest path to a working model.
A field-tested pattern is to start with one asset class, one sensor type, and one model. Prove the data flow, prove the model, prove the alert. Then expand. The teams that fail at APM are the teams that try to instrument 500 assets in the first quarter. The teams that succeed are the teams that instrument 20 assets in the first quarter and 200 in the first year.
Maximo Reliability Strategies: The RCM Methodology That Makes It All Make Sense
Maximo Reliability Strategies is the application that ties Health, Predict, and Monitor together into a coherent reliability program. It is a database of failure modes, mitigation strategies, condition monitoring points, and maintenance strategies, organized by asset type. The library is built by reliability engineers for reliability engineers, and it short-circuits the months of work that a traditional RCM program requires.
The way to use Reliability Strategies is to map the assets in your environment to the asset types in the library, and then adopt the strategies that apply. A centrifugal pump in your plant, for example, will have a set of failure modes (bearing failure, seal failure, impeller wear, etc.), a set of monitoring points (vibration, temperature, flow), and a set of maintenance strategies (PM tasks, condition-based tasks, run-to-failure tasks). The library provides the structure; you provide the local knowledge.
The integration with Health is the most important part. The strategies in the library drive the scoring factors in Health. An asset that has been mapped to a strategy with five monitoring points will have a different health profile than an asset that has not been mapped. The integration with Predict is also significant: the failure modes in the library become the labels that Predict learns to forecast.
A practical pattern: pick a small set of critical assets and run the RCM mapping exercise on them. The output is a list of maintenance strategies, condition monitoring points, and failure modes. Then turn on Predict for those assets and let it learn from the data. The combination of human-driven RCM and machine-learned prediction is where the real value is.
The 9.0 release introduced the Reliability Strategies library as an add-on, and the 9.x releases have expanded the asset type coverage. The library is not free, and it is not trivial to deploy, but for an organization that is serious about reliability, it is the cheapest way to get a defensible RCM program in place.
How They Fit Together
The four applications are not independent. They are layers in a single asset lifecycle workflow. The pattern looks like this. Reliability Strategies defines the failure modes, the monitoring points, and the maintenance strategies for an asset class. Monitor ingests the sensor data and surfaces anomalies. Predict uses the sensor data and the failure history to forecast failures. Health combines the Predict output, the asset's criticality, and the work order history into a single score. The score drives a work queue. The planner turns the queue into work. The work feeds back into Health. The asset's failure history feeds back into Predict. The reliability engineer uses the feedback to refine the strategy.
The cycle is what makes the platform useful. A single application is a tool. The four applications together are a workflow. The teams that succeed with APM are the ones that recognize the workflow and build the muscle to operate it. The teams that struggle are the ones that treat each application as a separate product and try to integrate them later.
A practical takeaway: do not buy all four applications at once. Buy Health first, get the scoring working, and prove the value. Then add Monitor for the asset classes that need real-time data. Then add Predict for the asset classes that have the failure history. Then add Reliability Strategies for the asset classes that need a formal RCM approach. The platform supports a staged rollout, and the staged rollout is the right way to build the muscle.
Practical Implications
The APM capabilities in MAS are real, but they require real work to deploy. The team that owns the platform needs reliability engineering skills, data engineering skills, and operational skills. None of these are optional, and none of them are free.
A practical takeaway: build a small team, not a large one. A team of three people with the right skills (a reliability engineer, a data engineer, and an operator) can run a meaningful APM program. A team of 30 people with the wrong skills (administrators who have been reassigned) will produce noise. Quality matters more than quantity.
The second takeaway is to budget for data work. The models are only as good as the data, and the data work is the part that nobody puts in a vendor brochure. Budget for failure code cleanup, asset hierarchy cleanup, and meter data validation. The team that skips this work will spend the first six months fighting the data, and the team that does the work will spend the first six months building the program.
The third takeaway is to measure outcomes, not outputs. The number of sensors deployed is an output. The number of unplanned downtime hours avoided is an outcome. The number of work orders generated by the program is an output. The cost per avoided downtime hour is an outcome. The executive team cares about outcomes. The reliability team should report outcomes, and the program should be funded on outcomes.
Bottom Line
Maximo APM in 2026 is a credible platform for asset performance management. Health provides the scoring. Predict provides the forecasting. Monitor provides the data. Reliability Strategies provides the methodology. The four together form a workflow that connects the asset, the work, and the performance data in a way that no other Maximo-era platform has done before. The teams that succeed with APM are the ones that treat the four applications as a single workflow, that invest in the data work that the models depend on, and that measure outcomes rather than outputs.
Field-Tested Patterns and Common Pitfalls
A field-tested pattern for Health is to publish the scoring formula to the operations team. The scoring is a multiplier on trust: when the operations team understands how the score is calculated, they trust it. When the score is a black box, they ignore it. A 30-minute review of the formula with the planners is worth more than a week of score tuning.
A common pitfall is to deploy Predict before the failure history is clean. A model trained on inconsistent data will produce inconsistent predictions, and the operations team will lose confidence in the platform. The fix is to spend the time on the data before you turn the model on. Three months of data cleanup will save you a year of model rework.
A field-tested pattern for Monitor is to start with a single sensor type and a single asset class. Vibration on rotating equipment is a popular choice because the data is clean, the failure modes are well understood, and the alerting is straightforward. Build the data flow, build the alert, and prove the value. Then expand.
A common pitfall is to use the Reliability Strategies library as a substitute for local knowledge. The library is a starting point, not a finished program. Your environment has constraints, failure modes, and operating practices that the library cannot anticipate. Use the library to shortcut the structure, then add the local knowledge on top.
A field-tested pattern for the overall APM program is to publish a monthly scorecard. The scorecard should show the health distribution of the asset portfolio, the number of work orders generated by the program, the number of unplanned downtime hours, and the cost per avoided downtime hour. The scorecard is the artifact that keeps the program funded and the team focused.