Maximo APM in 2026: Health, Predict, Monitor, and the Reliability Workflow That Connects Them

Maximo APM in 2026: Health, Predict, Monitor, and the Reliability Workflow That Connects ThemAsset performance management used to mean buying a separate platform, integrating it with your EAM, and reconciling two sets of asset data. Maximo Application Suite changed that. The acquisition and integration of the APM capabilities into the suite alongside Manage produced a single platform that holds the asset, the work, and the performance data in one place. The integration is not seamless, but it is the closest thing to a unified asset lifecycle platform the industry has produced.

In 2026, Maximo APM is a credible platform for reliability programs. The four applications that make up the story (Maximo Health, Maximo Predict, Maximo Monitor, and Maximo Reliability Strategies) are not independent. They are layers in a single asset lifecycle workflow. Reliability Strategies defines the failure modes and monitoring points. Monitor ingests the sensor data. Predict forecasts failures. Health combines everything into a score. The score drives a work queue. The planner turns the queue into work. The work feeds back into Health. This is the workflow that connects asset data, work data, and performance data in a way no other Maximo-era platform has done before.

This article walks through the four applications from the perspective of reliability engineers and APM architects who actually deploy them. We will cover what each application does, how the scoring and forecasting work, how to integrate the four into a single workflow, and the field-tested patterns that make the difference between an APM deployment that produces real reliability improvement and one that produces dashboards nobody trusts.

Maximo Health: The Scoring Layer

Maximo Health is the entry point for most APM programs. It provides asset health scoring, asset criticality scoring, and risk scoring, all driven by 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 against the asset, 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.

The health score formula in the default model looks roughly like this:

Health = (Open Work Orders × 0.30) +
         (Open Service Requests × 0.10) +
         ((100 - Remaining Useful Life %) × 0.25) +
         (Chronological Age / Expected Life × 100 × 0.15) +
         (Risk Score × 0.20)

The weights are configurable. The typical pattern is to start with the defaults, validate the scores against known asset conditions, and then adjust the weights based on what matters in your operation. A plant with chronic reliability issues will weight open work orders more heavily. A plant with strong preventive maintenance will weight remaining useful life more heavily.

The New Asset and Location Dashboard

MAS 9.1 introduced a new Asset and Location Dashboard that consolidates the scattered health, work history, sensor data, and inspection data into a single view. The dashboard includes matrix views, automated analysis, and drill-down into the underlying data. For reliability engineers who have been piecing together this view from multiple applications, the consolidation is a real productivity gain.

The matrix view is particularly useful for portfolio reviews. A reliability engineer can see all assets in a site, sorted by health score, with the worst performers at the top. The drill-down shows the open work orders, the recent failures, the sensor trends, and the inspection history. The pattern that has emerged is weekly portfolio reviews against this dashboard, with action items for the worst performers.

Criticality and Risk Scoring

Criticality scoring is independent of health scoring. Criticality answers the question "how much does this asset matter to the operation?" Risk scoring combines health and criticality to answer "what should we work on first?"

The default criticality model considers safety impact, environmental impact, production impact, and repair cost. The weights are tunable. The risk formula is:

Risk = ((100 - Health) / 100) × Criticality

An asset with poor health and high criticality has the highest risk. The risk score drives the work queue in Health, which is the input to the planner's weekly review.

Condition-Based Maintenance with Meters

MAS 9.1 strengthened the condition-based maintenance (CBM) story with out-of-the-box integration between Manage, Monitor, and Health. The integration shares actionable time-series data across MAS applications through Meters. This means an asset can have a meter reading from a sensor, the reading can flow through Monitor, the meter value can drive a condition in Health, and the health score can update automatically.

The pattern is to configure meters on the assets that have condition monitoring points, configure the thresholds in Health, and let the system alert when the thresholds are breached. The alerts become input to the work queue, which becomes input to the planner.

Maximo Predict: The AI Forecasting Layer

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 switchgear. 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 for a useful Predict model is roughly 18 months of failure history with consistent failure codes. Less than that, and the model produces forecasts that are not reliable. More than that, and the model becomes more accurate. The pattern is to start with the assets that have the best historical data (typically the most critical assets that have been maintained with Maximo for years) and expand from there.

Building a Predict Model

The Predict model building process is largely automated but requires careful setup. The reliability engineer defines the asset class, identifies the failure modes to predict, selects the input features (sensor data from Monitor, work order history from Manage, asset specifications), and triggers the model training.

# Predict model configuration (conceptual)
predictModel:
  assetClass: PUMP_CENTRIFUGAL
  failureModes:
    - BEARING_FAILURE
    - SEAL_FAILURE
    - IMPELLER_DAMAGE
  inputFeatures:
    - source: monitor
      metric: VIBRATION_RMS
      aggregation: daily_max
    - source: monitor
      metric: TEMPERATURE_BEARING
      aggregation: daily_avg
    - source: manage
      field: WORKORDER_COUNT_LAST_90D
    - source: manage
      field: LAST_FAILURE_DAYS
  trainingDataMonths: 24
  forecastHorizonDays: 90
  confidenceThreshold: 0.75

The forecast horizon (how far ahead Predict forecasts) is configurable. The typical pattern is 30 to 90 days for operational planning and 180 to 365 days for capital planning. The confidence threshold (the probability at which the forecast triggers an alert) should be tuned per asset class based on the cost of false positives and the cost of missed failures.

Common Predict Pitfalls

The teams that have the worst Predict results share several patterns. Pitfall one is not enough failure history. If the asset class has fewer than ten failure events in the historical window, the model has nothing to learn from. The forecast is essentially random.

Pitfall two is inconsistent failure codes. If the failure codes for the same failure mode change over time (different technicians recording different codes), the model cannot learn the pattern. The reliability engineer needs to standardize the failure codes before building the model.

Pitfall three is ignoring sensor quality. If the Monitor sensor data has gaps, drift, or calibration issues, the model trains on bad data. The reliability engineer needs to validate the sensor data quality before training the model.

Pitfall four is over-trusting the forecast. Predict is a forecasting tool, not a crystal ball. The forecast gives a probability and a confidence interval. A 70% probability of failure in 30 days means there is a 70% chance of failure, not a certainty. Use the forecast as one input among many, not as the sole driver of work.

Maximo Monitor: The Sensor Ingestion Layer

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).

Monitor supports 1,600+ pre-configured device partners, which covers most industrial sensor vendors. For sensors that are not in the partner catalog, Monitor supports custom agent configuration. The typical deployment starts with a few asset classes and expands over time.

Monitor Architecture in Practice

Monitor ingests data through agents (small services that run on or near the sensor), processes the data through a streaming analytics engine, stores the data in a time-series database, and exposes the data through APIs. The agents can be deployed on edge gateways, on industrial PCs, or on the sensor itself for smart sensors.

The architecture pattern for most deployments is:

• Edge gateway near the asset class, running the agent.
• Streaming analytics on the OpenShift cluster, processing the data in near real time.
• Time-series storage in the Monitor database.
• API endpoints for Predict, Health, and the Alerts application.

For operations with poor connectivity between the edge and the OpenShift cluster, Monitor supports local buffering. The agent buffers data locally and uploads when connectivity is available. This is critical for remote sites (mines, offshore platforms, pipelines) where continuous connectivity cannot be assumed.

Monitor and the Asset and Location Dashboard

The Asset and Location Dashboard in Health pulls sensor data from Monitor in near real time. The reliability engineer can see the current sensor values, the historical trend, the threshold breaches, and the correlated work order history for any asset. The integration is automatic once the asset is registered in both Monitor and Health.

The pattern that has emerged is to configure the dashboard for the assets that have sensors, and to use the dashboard as the primary investigation tool for condition-related work orders. When a work order is generated from a sensor breach, the dashboard is the first place the planner goes to understand what is happening.

Maximo Reliability Strategies: The Methodology Layer

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 Reliability Strategies library ships with pre-built RCM (Reliability-Centered Maintenance) strategies for common asset classes (pumps, motors, valves, switchgear, transformers). The library covers the common failure modes, the recommended condition monitoring points, and the recommended maintenance strategies for each asset class.

How Reliability Strategies Fits In

The reliability engineer uses Reliability Strategies to define the maintenance strategy for an asset class. The strategy includes the failure modes to monitor, the condition monitoring points to instrument, the preventive maintenance tasks to schedule, and the run-to-failure allowances to accept.

Once the strategy is defined for an asset class, it propagates to the assets in that class. The preventive maintenance tasks become PMs in Manage. The condition monitoring points become meters and sensor configurations in Monitor. The failure modes become the target for Predict models. The strategy becomes the foundation for the health and risk scoring in Health.

This is the integration that makes the four applications work together. Without Reliability Strategies, the four applications are independent tools. With Reliability Strategies, they are layers in a single workflow.

The RCM Methodology in Practice

The RCM methodology in Reliability Strategies follows the standard RCM process. The reliability engineer asks seven questions for each asset class:

• What are the functions and associated performance standards of the asset?
• In what ways can the asset fail to fulfill its functions?
• What are the causes of each functional failure?
• What happens when each failure occurs?
• In what way does each failure matter?
• What can be done to prevent or predict each failure?
• What should be done if a preventive task cannot be found?

The answers populate the Reliability Strategies database. The database then drives the PMs in Manage, the meters in Monitor, the models in Predict, and the scores in Health.

The Four Applications as a Single Workflow

The four applications are not independent. They are layers in a single asset lifecycle workflow. The pattern that has emerged in successful deployments 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.

This is the loop. The reliability engineer is the person who closes it.

The Reliability Engineer as the Center

In a successful Maximo APM deployment, the reliability engineer is the central role. They define the strategy, validate the sensor data, build the Predict models, review the health scores, and turn the worst performers into work. They are the bridge between the data and the work.

The reliability engineer's weekly rhythm looks like this. Monday, review the Asset and Location Dashboard for the worst performers. Tuesday, investigate the worst performers in detail. Wednesday, meet with the planner to review the work queue. Thursday, validate the work orders generated from the queue. Friday, update the Reliability Strategies library based on what was learned.

The rhythm is consistent, but the content varies. Some weeks the focus is on bearing failures in pumps. Other weeks the focus is on switchgear anomalies. The reliability engineer adapts to the data.

Measuring APM Success

The teams that succeed with Maximo APM measure outcomes, not outputs. The output metrics (number of models built, number of sensors deployed, number of health scores calculated) are easy to track but do not predict reliability improvement. The outcome metrics (reduction in unplanned downtime, increase in mean time between failures, reduction in maintenance cost per asset) are harder to track but actually measure reliability improvement.

The recommended outcome metrics are:

• Unplanned downtime as a percentage of total operating time.
• Mean time between failures (MTBF) for critical assets.
• Maintenance cost per asset per year.
• Percentage of work orders generated from condition monitoring (versus calendar-based PMs).
• Percentage of work orders closed on first visit.

Track these quarterly. Compare year over year. The reliability improvement should be visible within 12 to 18 months of a well-executed APM deployment.

Common Pitfalls in Maximo APM Deployments

The teams that have published the worst Maximo APM post-mortems share several patterns.

Pitfall one is treating the four applications as independent. The Health deployment that is not connected to Monitor produces stale scores. The Predict model that is not connected to Manage produces forecasts that cannot be acted on. The Reliability Strategies library that is not connected to the other three is documentation, not a workflow. The four must be integrated.

Pitfall two is not investing in data quality. The models are only as good as the data. Failure codes that are inconsistent, sensor data that has gaps, work orders that are missing failure codes, asset hierarchies that are not maintained. The reliability engineer needs to invest in data quality before the models can produce useful output.

Pitfall three is over-trusting the AI. Predict is a forecasting tool. Health is a scoring tool. Neither is a replacement for engineering judgment. The reliability engineer uses the tools as inputs, not as decisions.

Pitfall four is not closing the loop. The work that comes out of the APM workflow must be tracked, completed, and fed back into the data. If the planner generates a work order from a health score and nobody tracks whether the work actually happened, the loop is broken. The reliability engineer needs to close the loop.

Pitfall five is ignoring the organizational change. APM is not just a technology deployment. It is an organizational change. The maintenance organization, the operations organization, and the reliability organization all need to align on the new workflow. The technology is the easy part. The change management is the hard part.

Field-Tested Patterns

The teams that succeed with Maximo APM share several patterns that are worth replicating.

Pattern one is starting with the highest-criticality assets. The first Predict models should be built for the assets that matter most to the operation. The first Monitor sensors should be deployed on the assets that have the biggest reliability impact. Starting small and high-value produces results that justify continued investment.

Pattern two is investing in the data before the models. The reliability engineer should spend time cleaning failure codes, validating sensor data, and standardizing asset hierarchies before building any models. The investment in data quality pays off many times over in model accuracy.

Pattern three is the weekly portfolio review. The reliability engineer reviews the worst performers every week. The review is structured, with consistent criteria, and produces action items. The review is the rhythm that keeps the loop closing.

Pattern four is the metrics dashboard. The team tracks the outcome metrics (unplanned downtime, MTBF, cost per asset) on a dashboard that is visible to leadership. The dashboard is the communication tool that keeps the program funded.

Pattern five is the cross-functional team. APM is not just a reliability engineering program. It is a reliability engineering, maintenance, and operations program. The cross-functional team meets regularly, aligns on priorities, and executes together.

Practical Implications

For reliability engineers, the practical implication is that Maximo APM is a real platform for asset performance management, and the four applications work together when they are configured together. The investment is in the workflow design, the data quality, and the organizational alignment, not just in the technology.

For maintenance planners, the implication is that the work queue from Health is a real input to planning. The work generated from health scores and Predict forecasts is different from the work generated from calendar-based PMs. Both are valuable. Both need to be planned and executed.

For operations leaders, the implication is that APM is a multi-year investment. The reliability improvement is visible within 12 to 18 months of a well-executed deployment. The first six months are about data quality and model building. The second six months are about workflow integration. The second year is about optimization.

For IT and platform teams, the implication is that Monitor, Predict, and Health are real workloads on the OpenShift cluster. They consume CPU, memory, and storage. The cluster sizing needs to account for them. The IBM performance best practices for Manage apply to APM with modifications.

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 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 the models depend on, and that measure outcomes rather than outputs. The teams that fail are the ones that treat the four as independent tools, that over-trust the AI, and that do not close the loop between the data and the work.

If you are starting an APM deployment, start with the highest-criticality assets. Invest in the data before the models. Build the workflow before the dashboards. Track the outcome metrics. The reliability improvement will follow.