Reliability

From RCM to Health to Predict: How Maximo APM Became One Continuous Loop in 2026

Kevin Arhagba

Kevin Arhagba

— 8 min read
Share

A workshop participant put it well in a recent IBM Community post: "MAS is no longer positioning Manage, Monitor, Health, Predict, and Reliability Strategies as separate products. They are increasingly presented as connected operational capabilities."

That sentence captures a shift that has been building for two years and is now, in mid-2026, the dominant narrative from IBM's reliability engineering organization. The APM stack is not a collection of dashboards. It is a single loop, and the loop is the asset lifecycle.

This article walks through the loop as it actually works in the field right now, with the May 2026 releases of Predict 9.1.8, Health 9.1.x, Monitor 9.1.x, and the steady drumbeat of improvements to the Reliability Strategies library.

The loop, end to end

The reliability loop, as IBM is now teaching it, looks like this:

Failure analysis (FMEA / RCM)
        ↓
Maintenance strategy (PMs, job plans, condition tasks)
        ↓
Sensors & meters (Monitor)
        ↓
Monitoring (alerts, thresholds, anomaly detection)
        ↓
Health scoring (Health)
        ↓
Alerts → work execution (Manage)
        ↓
Feedback into reliability improvement

The interesting thing about this loop, in 2026, is that every transition between stages is now either (a) configured in a single suite, (b) automated through the AI Service, or (c) bridged by an object structure that runs without manual intervention. The "sync layer" that used to sit between Monitor and Manage — the awkward bit where IoT data and EAM data lived in different systems with a fragile integration — is largely gone.

Failure analysis: Reliability Strategies is no longer a side module

The Reliability Strategies library is the part of MAS where FMEA, RCM analysis, and reliability-centered maintenance strategy decisions live. It used to feel like a separate product. It no longer is.

The 9.1 line added AI-assisted FMEA generation (the sfmea template in the AI Service). The pattern is:

  1. Pull the historical failure and work order data for an asset class.
  2. Pull the existing FMEA records (if any) and any associated condition-monitoring tasks.
  3. The AI Service suggests failure modes, effects, and recommended condition-monitoring tasks based on the asset class and the historical pattern.
  4. A reliability engineer reviews the suggestions, accepts or rejects, and the result becomes a living FMEA in the asset's record.

This is not a research demo. The sfmea template is in the AI Service 9.1.15 release (May 2026) and is documented in the watsonx.ai integration guide. The output is an actual FMEA record, with failure modes, effects, recommended tasks, and a link back to the work order history that informed the suggestion.

The honest limitation: the AI suggestion is a draft, not a replacement for a reliability engineer. But the work it eliminates is the worst part of FMEA maintenance — the "I have 1,200 assets of this class and I need to find every failure mode that has ever shown up." That is now a 30-second query, not a 3-week research project.

Maintenance strategy: PMs, job plans, and condition tasks, all linked

Once the FMEA is alive, the maintenance strategy flows from it. In 2026, the loop is:

  • FMEA recommends a condition task (e.g., "vibration analysis on bearing housing every 30 days"). The condition task is created in Manage as a PM with a frequency and a measurement point.
  • The condition task references a measurement on the asset. The measurement is associated with a sensor or a manual inspection form.
  • When the condition task is due, Manage generates a work order. The work order references the FMEA entry, so the technician executing it can see why the task exists.

The 9.1 line improved the PM generation and FMEA linkage in two ways. First, the asset record now shows a "Reliability" tab that aggregates the FMEA entries, the condition tasks, and the predicted failure modes. Second, when a work order is generated from a condition task, the long description is auto-populated with the FMEA context — what failure mode this task is designed to detect, what the recommended action is if the measurement is out of range.

That second point is the one that changes technician behavior. A work order that says "inspect bearing housing" gets rubber-stamped. A work order that says "this is a vibration check to detect outer race spalling on the drive-end bearing; if RMS velocity exceeds X, escalate to Y" gets attention.

Sensors & meters: Monitor is the data plane

Maximo Monitor is the data plane. It accepts data from three classes of source:

  • IoT devices (vibration sensors, temperature probes, pressure transmitters) via MQTT, HTTP, or one of the 175+ pre-built device connectors IBM has shipped in 8.11+ and continues to extend.
  • Operational systems (SCADA, EMS, BMS, historians) via file-based exchange, REST, or Kafka.
  • Manual entry (a meter reading entered by a technician) via the Mobile app or the Manage UI.

In 2026, the data flows directly into the asset's meters. There is no longer a separate "Monitor asset" and "Manage asset." The asset in Manage is the asset in Monitor. The meters in Manage are the meters in Monitor. The condition tasks in Manage fire on the meters in Monitor.

This is the change that makes the loop feel continuous. Historically, dispatchers and reliability engineers had to mentally translate between two systems. Now there is one asset, one set of meters, one source of truth.

Monitoring: alerts, thresholds, anomaly detection

Monitor handles the near-real-time evaluation. Three patterns are in production today:

  • Threshold-based alerts. A simple rule: if meter X exceeds value Y for duration Z, raise an alert. This is the workhorse — easy to configure, easy for dispatchers to understand.
  • Rate-of-change alerts. A more sophisticated rule: if meter X changes by more than Y% over the last N readings, raise an alert. Catches failures that don't exceed an absolute threshold but are deteriorating fast.
  • Anomaly detection. A statistical model that learns the normal range for a meter and flags readings that are statistically unusual. Requires some training data but is the right tool for assets where you don't know the threshold.

The May 2026 Predict 9.1.8 release improved model runtime and accuracy across all three of these patterns, with particular attention to anomaly detection on slow-changing assets (e.g., transformer dissolved gas analysis, where the signal is buried in noise).

Health scoring: from "is the asset OK?" to "what is the asset's risk of failure?"

Maximo Health takes the monitor output and computes a health score. The score is a weighted combination of:

  • Asset condition (based on the latest measurements)
  • Asset criticality (based on the asset's role in production)
  • Failure history (based on past work orders and reliability records)
  • Operating context (based on environmental and usage factors)

The 9.1 line made two changes that matter in practice. First, the Asset Investment Optimization (AIO) module, introduced in 8.11 and refined in 9.0 and 9.1, is now the standard way to turn health scores into capex recommendations. A planner can look at the top 50 assets by risk and see, for each one, the cost of repair versus the cost of replacement versus the risk of doing nothing. Second, the health score now flows into Manage's Asset record as a first-class field. A work order generated for a low-health-score asset carries that score into the work order, so the dispatcher sees the risk context when they assign the work.

Predictions: Predict closes the loop

Maximo Predict runs the five model types that have been the bedrock of the product:

  • Probability of Failure — given the historical data and current condition, what is the probability of failure in the next N days?
  • Predicted Failure Date — when is the next failure most likely?
  • Factors that contribute to failure — what asset attributes are most predictive?
  • Anomaly Detection — for assets without enough failure history, is the current behavior anomalous?
  • Asset Life Curve — given age and operating context, what is the expected probability of failure at each future age?

The 9.1 line made two practical changes. First, the prediction groups concept (a way to group similar assets for model training and comparison) is now exposed in the UI, so reliability engineers can see "this asset is in group X, and 12% of group X assets have failed in the last 24 months." Second, the prediction output is published to the FMEA automatically — when Predict produces a high probability of failure, the corresponding failure mode in the FMEA is flagged for review.

Work execution: Manage closes the loop, then it starts again

The work order generated by the loop carries the full context: the FMEA entry, the condition that triggered it, the predicted probability of failure, the health score, the asset criticality. When the work is executed, the result feeds back into the loop:

  • A failure found updates the failure history, which Predict uses to retrain.
  • A condition found within range is a data point that the threshold is correct.
  • A condition found out of range updates the health score and may trigger a new prediction.

This feedback is what makes the loop a loop, not a chain. In 2026, the integration between the work execution side and the prediction side is direct — no custom code, no fragile nightly batch. The reliability engineer sees, in one place, "we executed this work, here is what we found, here is the updated prediction."

What changed in 2026 that is genuinely new

Three things, in order of practical impact:

  1. The Health → Manage integration is direct. Health scores are first-class fields on the asset and the work order. This was technically possible before 9.1, but required integration work. It is now default.
  2. The AI-assisted FMEA generation works. The sfmea template in the AI Service 9.1.15 (May 2026) is a real, documented, ship-it feature. Reliability engineers who have been maintaining FMEAs in spreadsheets for years can now move them into the system without losing their minds.
  3. The narrative is unified. IBM's own materials — workshops, product documentation, the SWMUG product update from March 2026 — now talk about the loop as one thing. That makes the implementation conversation with executives much easier.

A practical read for a reliability engineering team in 2026

If you are starting a reliability program in 2026, the recommended sequence is:

  1. Start with the FMEA library. Use the AI Service to bootstrap it from your historical work order data. Do not try to write the FMEA from scratch — that is the path to a stalled initiative.
  2. Pick one asset class. Substation transformers, centrifugal pumps, large motors — pick the class that has the worst failure history and the best data. Prove the loop on that class.
  3. Stand up Monitor for that asset class. If you have IoT sensors, use them. If you don't, start with manual meter readings and add sensors as you prove the value.
  4. Build the health score. Keep it simple. Two or three factors. Don't over-engineer the weighting in v1.
  5. Run Predict on the same asset class. Use the historical failures to train. Don't expect miracles in the first 90 days — the model needs data.
  6. Wire the loop into Manage. This is the part that requires the most configuration work. FMEA entries → condition tasks → PMs → work orders. The work order carries the FMEA context. The work order result feeds back.
  7. Expand to the next asset class. Use what you learned. Each new class takes less time than the last.

The honest limitations

The loop is real, but it is not magic. Three things to be honest about:

  • The AI suggestions are drafts. Reliability engineers still own the FMEA. The AI accelerates the research; it does not replace the judgment.
  • Health scores are only as good as the data. If the meter readings are sparse or the failure codes are inconsistent, the health score will be noisy. Data quality is a prerequisite.
  • The loop requires organizational alignment. The reliability team, the maintenance team, the planning team, and the operations team all need to be looking at the same loop. If they are looking at different dashboards, the loop is not closed.

The 2026 Maximo APM stack is the best version of this story yet. The tools are real, the integration is direct, and the AI is a useful accelerator. The remaining work is the work that has always been the work: data quality, organizational alignment, and the discipline to actually use the loop after you build it.

Read more