Closing the Loop: From Maximo Predict Insights to Field Work Order Execution

# Closing the Loop: From Maximo Predict Insights to Field Work Order Execution

The promise of Asset Performance Management is not that the software will predict failures. The promise is that the prediction will trigger the right action, that the action will be executed, and that the result will feed back into the model. The closed loop, in other words.

IBM Maximo's APM stack, Monitor, Health, and Predict, plus Reliability Strategies, has the components needed to close that loop. The challenge for most organizations is not a missing feature. It is the discipline to wire the components together and to keep the loop running for years, not weeks. This article is a playbook for reliability engineers who want to build that loop and keep it healthy.

The Components: What Each Piece Does

Maximo APM is a stack of three primary applications, each of which addresses a different question about an asset.

Maximo Monitor

Monitor is the OT data ingestion layer. It pulls time-series data from sensors, SCADA systems, and other IoT sources, and it makes the data available to the rest of the suite. Monitor also supports threshold-based alerts that can trigger workflows directly.

In the broader APM architecture, Monitor plays the role of "what is happening now?" The data flow is unidirectional, from the asset to the platform, and the typical use case is condition monitoring and rule-based alerting.

Monitor was originally part of the IoT Platform, and the merger of Health and Predict Utilities into Health and Predict in MAS 8.11 brought Monitor more clearly into the APM stack. In MAS 9.1, Monitor is the OT foundation that the other APM applications build on.

Maximo Health

Health answers "how is the asset doing overall?" It takes data from Manage (asset master, work history, failure records) and from Monitor (current operating conditions) and produces a composite health score, a criticality score, and a risk score for each asset.

The scoring model is configurable, and tuning the model is the first major project for any new Health implementation. The default model works for many organizations, but high-stakes environments, nuclear plants, transmission grids, life-safety systems, usually need to tune the model against their own asset portfolio.

Health also includes the Asset Investment Optimizer (AIO), which lets you model different investment strategies against a budget. The AIO is a powerful tool for capital planning, but it requires the input data to be in good shape. If the asset failure history is incomplete or the risk curves are estimated, the AIO will produce numbers that look precise but rest on shaky foundations.

In MAS 8.11, Health inherited the Asset Investment Optimization capability from the legacy Health and Predict Utilities product. The consolidation simplified the APM stack and made the AIO available without an additional license.

Maximo Predict

Predict answers "what will happen next?" It uses machine learning models trained on historical data from Manage and time-series data from Monitor to forecast days to failure, probability of failure, and other key indicators.

The standard Predict models address five predictive questions:

1. Days to failure. When is this asset most likely to fail?
2. Probability of failure. What is the chance of failure in a given window?
3. Failure mode prediction. What kind of failure is most likely?
4. Anomaly detection. Is current behavior outside the expected range?
5. Asset life curve. How does the probability of failure evolve over the asset's life?

Each question is backed by a model that has been trained on industry-standard failure patterns. The model output is not a guess. It is a probability distribution, and the reliability engineer can use the distribution to make better decisions.

The most important thing to understand about Predict is that it depends on Health and Monitor. The models use the Health scores as features, and they use the Monitor time series as the primary input. An implementation that stands up Predict without Health and Monitor is an implementation that has skipped the foundations.

Reliability Strategies

Reliability Strategies is the newest of the four components, and it provides a Reliability Centered Maintenance (RCM) capability. The application includes a library of failure modes, preventive maintenance tasks, and intervals for over 800 asset types, distilled from industry studies.

The library is the most valuable asset in Reliability Strategies. Most organizations have neither the time nor the expertise to build an RCM library from scratch, and the Reliability Strategies library gives them a defensible starting point. The library is configurable, and the most effective implementations customize the recommendations to match local operating conditions.

Reliability Strategies is the result of IBM's acquisition of the Asset Strategy Library from Uptake Technologies Software in early 2023. The library contains over 58,000 failure mechanisms and 5,000 preventive maintenance tasks across the 800+ asset types. The breadth of the library is what makes it useful: a reliability engineer can find a recommended PM strategy for almost any common asset type without starting from scratch.

The Closed-Loop Workflow

The closed loop is a sequence of seven steps. Each step has inputs from the previous step and outputs to the next. The loop only works if all seven steps are running.

Step 1: Ingest Operational Data

The loop starts with data. Monitor pulls sensor data from the asset into the platform, and the data is normalized and stored as time series. Reliability engineers should monitor the data quality: missing data, stale data, and outliers all degrade the model output.

A useful first diagnostic is the data freshness dashboard, which is available in the Monitor application. If the data is more than a few minutes old for critical assets, the loop is not going to close in time to prevent failures.

The data quality issue that most often goes unnoticed is sensor drift. A sensor that gradually drifts out of calibration will produce data that is technically valid but systematically wrong. The model will learn from the wrong data, and the predictions will be biased. Schedule periodic sensor calibration as part of the asset maintenance program, and the predictions will improve.

Step 2: Score Asset Health

Health consumes the Monitor data and combines it with the asset master and work history from Manage to produce the composite health score. The score is the input to the next stage of the loop.

The scoring model is where most implementations first run into trouble. The default model assumes a particular distribution of asset types, failure modes, and operating conditions, and most real-world asset populations do not match the default. Tune the model against your own data before trusting the scores.

A useful approach is to start with a small asset class, tune the model against the known failure history, and validate the scores against subject matter experts. Once the model is tuned for the small asset class, expand to larger classes one at a time. The incremental approach gives the team time to learn the model and to build confidence in the scores.

Step 3: Run Predictive Models

Predict takes the Health scores, the Monitor data, and the failure history from Manage, and it produces the predictions. The model output is more accurate when the failure history is complete and accurate, which is another argument for investing in failure coding discipline.

The most common operational issue at this stage is model staleness. Models that are trained once and never retrained will drift as the asset population changes. Retraining on a quarterly cadence is a reasonable starting point for most environments.

A useful diagnostic is to compare the predicted failure dates against the actual failure dates. If the predictions are systematically late, the model needs to be retrained. If the predictions are systematically early, the model may be overfitting to the training data. The reliability engineer should review the prediction accuracy on a regular cadence.

Step 4: Surface Insights to the Reliability Engineer

The predictions are surfaced through the Health and Predict applications. The reliability engineer is the human in the loop, and their job is to convert the model output into an action.

A useful pattern is a daily review of the top N predicted failures. The reliability engineer triages each prediction, decides whether to take action, and assigns the action to a work order. The review is the most important operational habit in the closed loop.

The size of N depends on the asset portfolio. For a small portfolio, N might be 10. For a large portfolio with thousands of assets, N might be 50 or 100. The principle is the same: focus attention on the highest-priority predictions, and triage the rest.

Step 5: Generate a Work Order

When the reliability engineer decides to act, the work order is created in Manage. The work order references the asset, the predicted failure, and the recommended action. The recommended action often comes from Reliability Strategies, which provides a defensible starting point for the job plan.

The work order is the handoff between the reliability engineer and the field technician. The handoff is a weak point in many implementations, and the most common failure is that the prediction context does not make it into the work order. If the technician does not know why the work order was created, they may not execute it with the urgency the prediction implies.

A practical pattern is to include the prediction summary in the work order description. A line like "Predict confidence: 78% failure within 15 days, primary factor: bearing temperature" gives the technician context that a generic "corrective maintenance" description does not.

The work order should also reference the source prediction. A custom field on the work order, populated automatically when the work order is created from a prediction, creates an audit trail from the prediction to the action. The audit trail is invaluable when you want to measure the effectiveness of the APM program.

Step 6: Execute the Work in the Field

The work order is dispatched to the technician through the standard Maximo Mobile workflow. The technician executes the work, records the actuals, and the work order is closed. The execution data flows back to Manage, where it updates the asset's work history.

The field execution step is where the closed loop either works or it does not. If the technician records incomplete actuals, the model does not learn from the intervention, and the next prediction will be less accurate. The most common failure mode is missing failure codes on closed work orders.

The fix is operational discipline, not software. Build the failure code into the work order template, train the technicians to use it, and audit the closed work orders for failure code completeness. The failure code is the most important field on the closed work order, and it is the field that the next round of model training depends on.

Step 7: Feed the Results Back to the Models

The execution data, especially the failure codes and the actual failure dates, is the input to the next round of model training. If the data is clean, the model improves with every cycle. If the data is dirty, the model degrades.

This is the step that most implementations skip, which is why so many "predictive maintenance" projects fail to deliver sus

...