Maximo Manage 9.2: The Data Quality Gate That Decides Whether Your AI Features Ever Work

Intro

There is a survey result that keeps circulating in Maximo circles, and it has survived long enough to be treated as background noise. Roughly forty percent of Maximo users report running predictive or reliability-centered maintenance programs on their critical assets, against roughly fifteen percent market-wide. Roughly a quarter plan to deploy multiple AI agents in 2026, against roughly fifteen percent across the broader industry. The same survey names the top barriers: data quality, integrations, and skills.

Most commentary treats that as a flattering result with a caveat attached. Maximo users are ahead, but data quality is holding them back. That framing was reasonable two years ago. In the MAS 9.2 era it is no longer accurate, because the relationship between data quality and capability has changed. Data quality used to be the thing that made your reports unreliable and your reliability engineers grumpy. Now it is the literal input to the features you have already paid for.

Maximo Manage 9.2 ships with an evolved Maximo Assistant that moved from chatbot to agentic orchestrator, capable of multi-turn operational context and natural-language queries across assets and work orders. MAS 9.2 includes an MCP Server that lets organizations connect their own AI agents to Manage APIs. Maximo Mobile 9.2 includes an AI assistant in online mode. Monitor 9.2 was re-architected with a new data ingestion path built explicitly around telemetry quality. Every one of those capabilities reads your data and produces an answer. None of them has a magic layer that compensates for an asset hierarchy with four generations of inconsistent naming conventions.

This article is about that gate. It argues that in the 9.2 era, data quality in Maximo Manage is not a reporting concern but an infrastructure concern, and it lays out a practical program for treating it that way. We will cover why the new AI surface changes the stakes, which specific data domains matter most, how to assess your own position honestly, and how to sequence remediation so that you get capability improvements along the way rather than waiting two years for a clean data set that never arrives.

If you are a Maximo Manage administrator, a maintenance manager, a reliability engineer, or a platform owner, this is the work that determines whether the AI line items in your MAS budget produce anything. The tooling is ready. The question is whether your data is.

Why the 9.2 AI Surface Changes the Stakes

The reason data quality matters more in 9.2 than it did in 7.6 is not that the new features are fragile. It is that they are confident. An AI assistant that reads your asset records and answers a natural-language question will always produce an answer, and that answer will be phrased with the same fluency whether the underlying data was clean or not.

Consider what the evolved Maximo Assistant does in 9.2. It orchestrates across multiple turns, maintaining operational context, and answers questions that span assets, work orders, and history. A question like "which of the pumps at this site are driving the most unplanned downtime this year" requires the assistant to resolve a site, identify the asset population, classify work orders as planned or unplanned, and aggregate history. Each of those steps is a join against data that a human would have sanity-checked. The assistant will not. It will return a number, and that number will be used in a meeting.

The MCP Server raises the stakes again, because it is designed to let your own agents call Manage APIs. That means the consumer of your data is no longer a person who can notice that something looks wrong. It is an automated process that will act on the result. If your agent queries asset criticality to decide what to inspect first, and half your critical assets have a null criticality field because they were loaded in 2011 and nobody revisited them, the agent will quietly deprioritize them. No error. No warning. Just a systematically wrong inspection plan that looks perfectly reasonable in a dashboard.

Mobile 9.2's AI assistant has a similar property in a different direction. Field technicians in online mode can ask questions and get answers on the device. A technician who asks about a component's maintenance history and receives an incomplete answer because the history lives under a duplicate asset record will not know the answer was incomplete. They will act on it. In the field, that means a part gets replaced that did not need replacing, or a known failure mode gets missed.

The Monitor re-architecture is the clearest case of all, because 9.2 explicitly rebuilt the data ingestion path with a file-based architecture that community contributors have been documenting. That change is an admission that telemetry quality and ingestion shape determine what condition monitoring can do. Feeding a monitoring platform inconsistent meter names, missing timestamps, and duplicate readings does not produce insight. It produces alarms.

The common thread is that the 9.2 AI surface converts data quality from a problem that produces visibly wrong reports into a problem that produces invisibly wrong decisions. Visibly wrong reports get fixed. Invisibly wrong decisions get trusted. That is the change in stakes.

The Four Data Domains That Matter Most

Not all data quality work is equal. In a Maximo Manage context, four domains account for the overwhelming majority of the AI-readiness risk, and they are worth prioritizing explicitly.

The first is the asset hierarchy and asset registry. This is the spine of everything else. Questions about maintenance history, cost, criticality, and condition all resolve through the asset record. The characteristic failures are duplicate assets created by different teams at different times, assets with no parent relationship so they float outside the hierarchy, inconsistent naming conventions that make similar assets unsearchable as a group, and location records that do not align with the asset hierarchy so that spatial and logical views of the same equipment disagree. Every one of these failures degrades every downstream AI answer, and none of them produces an error message.

The second is work order history integrity. Predictive maintenance depends on failure history, and failure history depends on work orders being classified correctly. The characteristic failures here are work order types that are technically populated but semantically meaningless because technicians choose from a list of forty options and pick the first one, failure codes that are captured inconsistently or not at all, and a large population of work orders with no problem code, which means the failure mode is recorded in free text that no analytics layer can reliably parse. If your failure coding discipline is weak, your predictive models are being trained on noise, and the assistant answering questions about failure patterns is reading a partially blank book.

The third is item and inventory alignment. Maintenance decisions involve parts, and parts live in the inventory module with their own identifiers. When asset records and item records do not align, the answer to "what does this asset cost to maintain" becomes unreliable, and spare parts planning becomes guesswork. The characteristic failure is a stock item catalog that grew organically across sites, with the same physical part represented by multiple item numbers, so consumption history is fragmented across records that nobody realizes refer to the same thing.

The fourth is the meter and condition data feeding Monitor. This is where the 9.2 re-architecture bites. Meter names, units, frequency, and association to assets must be consistent for condition monitoring to produce anything useful. The characteristic failure is a set of meters that were configured by hand over years, with inconsistent naming, mixed units, and irregular reading frequency, producing a telemetry stream that a new ingestion architecture can carry but cannot interpret.

These four domains are ordered by leverage. Asset hierarchy work improves every other domain's returns, so start there. Work order classification discipline is the highest-value behavioral change because it is cheap and it compounds. Item alignment is the least glamorous and frequently the highest financial return. Meter hygiene is what makes Monitor worth deploying.

Assessing Your Position Honestly

Most organizations believe their data quality is better than it is, for a straightforward reason: the people who know the data best are the ones who have learned to work around its problems. They know that the "PUMP-04" record is the real one and the "Pump 4 - rebuilt" record is a duplicate. Their workarounds are invisible to them because they are habits, not processes.

An honest assessment therefore requires measurement rather than opinion, and the measurements that matter are specific. For the asset registry, measure duplicate rate by matching on location plus asset type plus installation date, measure orphan rate as the share of assets with no parent in the hierarchy, and measure criticality completeness as the share of assets with a populated criticality value. For work order history, measure failure code population rate, measure the share of work orders whose problem description is free text with no structured code, and measure the distribution of work order types to see whether the classification is being used meaningfully or just uniformly. For items, measure duplicate item rate by matching on description plus manufacturer plus model, and measure the share of assets whose required parts have no associated stock item. For meters, measure unit consistency within a meter group, and measure reading regularity to find meters that are nominally live but practically abandoned.

The value of measuring rather than opining is that it converts an argument into a number. "Our data quality is fine" is a position. "Thirty-eight percent of our critical assets have no criticality value, and twenty-two percent of our asset records have a probable duplicate" is a finding, and findings get funded. If you are trying to get budget for data remediation, the measurement exercise is the business case.

Two cautions on assessment. First, do not measure everything. Pick a bounded scope, ideally your critical asset population at a single site or a single business unit, and measure it thoroughly. A complete picture of a small scope persuades executives far better than a vague picture of everything. Second, do not let the assessment become the deliverable. The most common failure mode for data quality programs is a beautiful assessment that sits on a shelf because nobody was assigned the next step.

Sequencing Remediation So You Get Value Along the Way

The classic mistake in data quality programs is the assumption that you must clean everything before you can use anything. That assumption is wrong and it is fatal, because a full remediation of a mature Maximo environment takes years and no sponsor will fund years of invisible work.

The correct approach is to sequence remediation around capability. Pick a bounded asset population, clean it to a defined standard, and then deploy the AI capability against that population. The critical asset population at one site is usually the right first scope. It is small enough to remediate in a quarter, and it is the population where predictive maintenance and condition monitoring produce the most value anyway.

The sequence looks like this. First, define the target data standard explicitly for the scope: what fields must be populated, what the naming convention is, what the hierarchy structure must look like, what constitutes a valid failure code. Write it down, because a standard that lives in someone's head is not a standard. Second, remediate the asset registry in scope, resolving duplicates and rebuilding the hierarchy relationship. Third, establish work order classification discipline going forward, which is a training and enforcement exercise rather than a data cleanup, and which prevents the problem from regenerating. Fourth, align the item records for the assets in scope. Fifth, validate meter and condition configuration for the assets being monitored. Sixth, deploy the capability and measure the outcome.

Two things make this sequence work where broad cleanup programs fail. The first is that each step produces a usable improvement rather than a prerequisite. After step two, your asset hierarchy is trustworthy for that population, and that alone improves reporting and planning. After step three, your failure history starts accumulating structured data that will be valuable in six months. The second is that the scope is small enough that a single owner can drive it, which matters more than any methodology. Data quality programs fail for organizational reasons, not technical ones.

There is one more discipline worth building: prevent regeneration. Every remediation program in a mature environment fights the tendency of the system to accumulate new duplicates, new orphans, and new inconsistent codes. The defenses are unglamorous and effective. Enforce duplicate checking at asset creation. Require a parent asset on creation where the hierarchy model demands it. Restrict the work order type list to a small number of meaningful options and train on it. Add a data quality dashboard that reports the four domains monthly so that drift is visible before it becomes structural. A monthly report that nobody reads is still useful, because the act of producing it keeps the measurements alive.

Finally, connect the data work to the AI work in your communications. The reason data quality programs lose funding is that they are framed as hygiene. They should be framed as the enabling condition for capabilities the organization has already licensed and announced. "We cannot deploy the assistant reliably until criticality is populated" is a funding argument. "We need to clean our data" is not.

Practical Implications

The practical implication for most Maximo Manage organizations is a reprioritization. Data quality work that has been deferred for years as low-urgency hygiene is now on the critical path for capabilities that are already in the budget. That means it needs an owner, a scope, a standard, and a schedule, which it probably does not have today.

Start with a measurement on a bounded scope, not a program. Measure the four domains against your critical asset population at one site, and turn the result into a one-page finding with numbers. That document is your funding request and your baseline. Then define the target standard for that scope in writing, and assign a single owner who is accountable for reaching it. Do not create a committee. Data quality programs with committees produce assessments; programs with owners produce results.

Then sequence the work around a capability deployment, not around cleanliness. Pick the capability you most want to enable, whether that is the Maximo Assistant answering operational questions, an MCP-based agent acting on maintenance priorities, or Monitor producing useful condition alarms. Remediate the scope, deploy the capability, measure the outcome, and expand the scope. Each cycle produces a visible win, which is what keeps the program funded for the second and third scope.

Two things are worth starting immediately even before the assessment finishes, because they are behavioral rather than technical and they take time to take hold. The first is work order classification discipline, since every day of weak coding is a day of history that will never be usable for predictive work. The second is duplicate prevention at asset creation, because it is a configuration change that stops new damage from accumulating. Neither requires a budget. Both require someone to decide.

Finally, if you are on the MAS 9.2 upgrade path, sequence your data work to land before your AI deployment rather than after. Deploying the assistant or an agent against a dirty data set produces a bad first impression that is very hard to recover from, because the business concludes the AI does not work rather than concluding the data needs fixing. The order matters enormously. Clean the bounded scope, then deploy, then expand.

The Bottom Line

The Verdantix finding that Maximo users lead the market on maintenance maturity while naming data quality as the top barrier is not a contradiction. It is a description of the next problem. Maximo organizations have the process maturity and now have the platform capability in MAS 9.2 to do genuinely advanced maintenance work. What sits between them and that outcome is the quality of the data their systems will read.

In the 7.6 era, poor data quality produced visibly wrong reports, and visibly wrong reports get noticed and fixed. In the 9.2 era, poor data quality produces confidently wrong answers from assistants and agents, and confidently wrong answers get trusted. That is a materially different risk profile, and it justifies treating data quality as infrastructure rather than hygiene.

The good news is that the fix is not mysterious and does not require a multi-year program. It requires a bounded scope, an explicit standard, a single owner, a capability to deploy, and a monthly measurement to prevent regeneration. Do that on your critical asset population at one site, prove the value, and expand. The organizations that do this will be the ones whose AI line items produce actual results rather than demonstrations. The ones that skip it will have excellent tooling reading unreliable data, which is the most expensive way to be wrong.