From Failure Analysis to Work Execution: How Maximo Health, Reliability Strategies, and APM Form a Closed-Loop Reliability Layer in MAS

For most of the Maximo era, Reliability-Centered Maintenance (RCM) was a one-time engineering exercise. A team would spend six to twelve months building a failure mode library, defining criticality, and writing maintenance strategies. Then the output would be exported as a static document, the strategies would be turned into PM records in Maximo, and the connection between the reliability analysis and the day-to-day work would slowly decay. By the time the next RCM review came around three to five years later, the strategy library would be out of date, the failure data would be inconsistent, and the team would start over.

MAS 9.x changes that. Reliability Strategies is no longer a separate product you integrate with Manage; it is a first-class capability inside the suite, and it is wired into Health, Predict, Monitor, and the work execution path. The same platform that runs the work order runs the reliability analysis, and the loop between them is closed. That change is the most strategically important thing happening in Maximo APM right now, and it is the reason that the typical RCM exercise in a MAS 9.x environment is not a one-time project but a continuous capability.

This article is a practitioner's deep dive into how that closed loop works, what the moving parts are, and what the operational pattern looks like for a team that wants to use Reliability Strategies as an operational capability rather than a one-time exercise. It covers the strategy model, the Health scoring layer, the Predict forecasting layer, the Monitor ingestion layer, the closed loop itself, the Weibull probability-of-failure analysis that the platform now supports natively, and the common pitfalls that show up in early deployments.

The Reliability Strategies Model: Failure Modes, Criticality, and Mitigations

Reliability Strategies in MAS 9.x models a reliability analysis as a set of connected entities. The asset is the thing being analyzed. The asset has a criticality, which is a numeric or categorical value that expresses the consequence of failure. The asset has failure modes, which are the ways the asset can fail (bearing wear, seal degradation, cavitation, fouling, and so on, depending on the asset class). Each failure mode has a criticality (often inherited or computed from the asset criticality), a failure cause, and an effect.

Each failure mode is then associated with one or more mitigations. A mitigation is a maintenance strategy that reduces the probability of the failure mode or reduces its consequence. Mitigations come in a few standard types: preventive maintenance tasks (with a frequency), condition monitoring tasks (with a sensor or inspection trigger), redesign tasks, and run-to-failure tasks. Each mitigation is linked back to a job plan in Manage, and the job plan is what actually gets executed when the work is scheduled.

The asset, the failure modes, the criticality, and the mitigations together form the reliability strategy for that asset. The strategy is a living object in MAS, not a document. When the asset's criticality changes, the failure modes can be recomputed. When a new failure mode is identified (from an incident, a near-miss, or a monitoring alert), it can be added to the strategy and the mitigations updated. When a mitigation is changed (frequency adjusted, job plan revised), the change is recorded and the strategy version is updated.

The practical implication is that the reliability analysis is no longer a static artifact. It is a configuration that the reliability engineering team can update as conditions change, and the maintenance team can consume in real time. The loop that was previously a six-to-twelve-month project is now a continuous operational practice.

Health Scoring: The Bridge from Data to Decision

Maximo Health is the bridge between the raw asset data and the reliability strategy. Health ingests operational data from Maximo Manage (work order history, failure history, age, specifications) and from Maximo Monitor and IoT devices (sensor data, meter readings, alarms), and it computes a set of scores that describe the asset's condition.

The default scores that ship out of the box with Health activation are the ones that cover the most common decisions. There is a health score, which is a 0 to 100 number that represents the asset's current condition. There is a criticality score, which represents the consequence of failure. There is a risk score, which is the product of the inverse of health and the criticality, and which is the most operationally useful score for prioritizing work. There is a chronological age score, which is the asset's age as a proportion of its expected life, and there is a remaining useful life score, which is the estimated time until the asset reaches an unacceptable health threshold. There are also operational scores: number of open service requests, number of open corrective work orders, and a normalized priority score.

The out-of-the-box scores are not the only scores. Health also supports custom scores, which is the feature that turns a generic health calculation into a domain-specific one. A team that operates transformers, for example, can build a custom score that combines oil temperature, dissolved gas analysis, load factor, and age. A team that operates pumps can build a custom score that combines vibration, bearing temperature, and flow deviation. The custom score is configured in the Health Settings application, which requires a Base-tier user to access.

The scores are the input to two downstream consumers. The first is the operational dashboard, which shows health, criticality, and risk at the asset, location, and asset class level. The second is the work queue manager, which can generate work orders, work lists, or alerts based on a threshold on a score. The right operational pattern is to use the work queue manager to surface the assets that need attention, not to wait for someone to look at the dashboard.

Predict: The Forecasting Layer

Maximo Predict is the forecasting layer. Where Health tells you the current condition, Predict tells you the future condition. Predict ingests time-series data from Maximo Monitor and failure data from Maximo Manage, and it builds models that forecast days to failure, probability of failure, and other forward-looking indicators. The models can be supervised (trained on labeled failure data) or unsupervised (anomaly detection on the time-series data).

The supervised models are the most operationally valuable but also the most demanding. They require a labeled failure history, which most organizations have in their work order data, but they also require a curated training set, which most organizations do not have. The training set needs to be representative of the failure modes the team is trying to predict, and it needs to be free of the data quality issues that quietly degrade every machine learning model. The pattern that works is to start with a single asset class, a single failure mode, and a small training set, and to validate the model against a holdout set before deploying it.

The unsupervised models are easier to deploy and are the right starting point for most teams. Anomaly detection on a single sensor stream is a well-understood problem, and Maximo Predict ships with the standard algorithms. The output is a probability of failure over a forward time window, and the threshold for action is configurable. The pattern is to start with the top ten sensors on the most critical assets, validate the anomaly detection against known events, and then expand.

The output of Predict feeds into the same work queue manager that Health uses. When a forecast crosses a threshold, the system generates a work order or an alert. The work order is the same work order that would be generated for any other trigger, which means the maintenance team can act on it through the standard process.

Monitor: The Sensor and Data Ingestion Layer

Maximo Monitor is the data ingestion layer. It ingests data from PLCs, SCADA systems, IoT devices, and other operational technology sources, normalizes the data into a time-series store, and exposes the data to Health, Predict, and the operational dashboards. The MAS 9.2 release of Monitor and IoT Platform includes a re-architected IoT platform that can run Monitor standalone without IoT or Kafka, fast CSV-based onboarding for low-cost pilots, an Edge Data Collector for offline or edge processing, new SNMP connectivity, hierarchical analytics that roll child metrics up to the parent level, and RBAC for granular governance.

The standalone Monitor mode is the most important of these for teams that are not ready to operate a full IoT platform. It lets you start with a single asset, a single sensor, and a CSV file, and to validate the end-to-end flow from sensor to health score to work order. Once that works, you can grow the deployment by adding more assets and more sensors, and you can move to the full IoT platform when the volume justifies it.

The Edge Data Collector is the right answer for sites with poor connectivity. It buffers sensor data at the edge, syncs to the central Monitor when connectivity is available, and survives network outages that would otherwise lose data. For remote sites, the Edge Data Collector is the difference between a working APM deployment and one that quietly loses a third of its data.

The hierarchical analytics capability lets you define a rollup structure (for example, asset, substation, region, division) and to compute metrics at each level of the hierarchy. The pattern is to use the rollup to surface the worst-performing assets at each level, and to use the drilldown to investigate the specific asset. The combination is what makes Monitor useful at scale, because it lets a regional manager see the worst five percent of their assets without having to look at every individual sensor.

Probability of Failure and Weibull Analysis: Native Reliability Math

One of the more important additions in recent MAS releases is native Weibull analysis for probability of failure. Weibull is a statistical distribution that is widely used in reliability engineering to model the time to failure of mechanical and electronic components. The platform now ships the ability to fit Weibull parameters from historical work order data directly in Manage, with out-of-the-box functionality that lets you visualize failure curves alongside actual failure data, and to define the curves by scoring group.

The practical value is that the team no longer needs a separate statistical tool to do the analysis. The probability-of-failure tab in the Score Settings application is where the reliability engineer configures the Weibull fit: which scoring group to use, which failure history to include, what the time window is, and how to display the resulting curve. Once configured, the curve is exposed in the asset detail, in the operational dashboard, and as an input to the work queue manager.

The operational pattern is to fit a Weibull curve per scoring group, validate the fit against the actual failure history, and to use the curve to set the inspection and PM frequencies for the assets in that group. The right frequency is the one that gives the lowest total cost (maintenance cost plus expected failure cost) across the curve. The Weibull fit gives the team the probability of failure at any point in time, and the cost optimization gives the team the right intervention point.

The Dissolved Gas Analysis (DGA) for transformers, with Duval triangle visualization, is a related capability that ships with the industry accelerators. The Duval triangle is a standard diagnostic in transformer reliability: a point in the triangle indicates which type of fault is present (thermal, electrical, or both, with subcategories). The platform now visualizes the DGA results in the same operational dashboard, and the DGA data feeds into the Health score for the transformer.

The Reliability Strategies extension to AI capabilities is the broader pattern. The platform now supports failure and remediation descriptions that are generated or augmented by AI, which means a team that has a reliable failure history can use the AI to draft the initial failure mode library and the remediation descriptions, and then the reliability engineer reviews and curates the output. The result is a faster initial RCM exercise and a more consistent library.

The Closed Loop: From Failure Analysis to Work Execution

The closed loop in MAS 9.x looks like this. The reliability analysis identifies the failure modes and the mitigations. The mitigations are translated into PM records and inspection records. Monitor ingests sensor data. Health computes the health, criticality, and risk scores. Predict forecasts the probability of failure. The work queue manager generates work orders when scores cross thresholds or when predictions exceed a probability. The work orders are executed by the maintenance team. The work order history feeds back into the reliability analysis.

Each step in the loop is a configuration in the platform, not a separate product. The reliability analysis is a Reliability Strategies object. The mitigations are job plans in Manage. The PM records are PM records in Manage. The inspection records are inspections in Manage. The sensor data is in Monitor. The scores are in Health. The forecasts are in Predict. The work orders are in Manage. The work order history is in Manage. The failure history is in Manage.

The implication is that the loop is auditable, governable, and operable from a single platform. There is no ETL between reliability and maintenance, because they are the same data. There is no integration between RCM and work execution, because they are the same configuration. There is no separate RCM tool that drifts out of sync with the live system, because the RCM is the live system.

The pattern that works for a team adopting this loop is to start with a single asset class that is operationally important, build the reliability analysis, deploy Monitor on the most critical assets in that class, enable Health, configure the work queue manager, and validate that the work orders generated by the system match the work orders the team would have generated manually. Once that loop is closed for one asset class, expand to the next.

Common Pitfalls and Field-Tested Patterns

Three pitfalls show up repeatedly in early reliability and APM deployments. The first is treating the reliability analysis as a one-time project rather than a continuous capability. Teams that deliver an initial RCM library, declare victory, and move on end up with a library that drifts out of date within 12 to 18 months. The pattern is to assign a named owner to the reliability library, schedule a quarterly review, and to require that any new failure mode identified in operations be added to the library within 30 days.

The second is the data quality of the failure history. The reliability analysis depends on the work order failure codes (class, problem, cause, remedy), and inconsistent failure coding breaks the analysis. Teams that have not invested in failure coding discipline will produce a reliability analysis that is technically correct but operationally useless. The pattern is to enforce a closed set of failure codes, to require the technician to record a failure code on every corrective work order, and to audit the failure coding monthly.

The third is the scope of the initial deployment. Teams that try to do everything at once (reliability analysis for every asset class, Monitor on every asset, Predict on every sensor) end up with a deployment that takes 18 months to deliver value and that is fragile in production. The pattern is to start with one asset class, prove the loop, and expand. The value of a closed loop on a single asset class is much greater than the value of a partially open loop on every asset class.

Practical Implications

For a reliability engineer or asset manager, the practical implications of the MAS 9.x reliability loop are concrete. First, the reliability analysis is no longer a one-time project; it is an operational capability that needs to be staffed, governed, and updated. The team needs a reliability engineer who owns the failure mode library, the criticality assignments, and the mitigation strategy. Without an owner, the library drifts.

Second, the data quality of the work order history, the failure history, and the asset specifications is now load-bearing. A reliability analysis built on incomplete or inconsistent work order data will produce unreliable mitigations. The pattern is to invest in the data quality of the source systems before investing in the reliability analysis. That investment is a one-time cost with a long payback.

Third, the scoring models are not a one-time configuration; they need to be calibrated as the asset base, the failure modes, and the operational context change. The Health Settings application should be revisited at least annually, and the custom scores should be validated against the actual asset performance. Without calibration, the scores drift and the work queue manager generates noise instead of signal.

Fourth, the loop depends on the work order history being accurate, which means the maintenance team needs to record failures, causes, and remedies in a structured way. The failure coding hierarchy (class, problem, cause, remedy) is the input to the reliability analysis, and the team needs to use it consistently. Without consistent failure coding, the reliability analysis cannot distinguish between a one-off failure and a recurring failure mode.

Bottom Line

The reliability loop in MAS 9.x is not a feature; it is an operational capability. It combines Reliability Strategies, Health, Predict, Monitor, the work execution layer of Manage, and the new Weibull probability-of-failure analysis into a single, auditable, governable flow that turns reliability analysis into day-to-day maintenance practice. The patterns that make it work are the same patterns that make any continuous improvement program work: a clear owner, disciplined data quality, calibrated models, a Weibull fit that is reviewed as the asset base evolves, and a feedback loop that is actually used. Teams that follow those patterns get a reliability program that improves with every work order executed. Teams that treat the reliability analysis as a project deliverable get a static document that drifts out of date. The platform is ready. The question is whether the operating model is ready too.