Maximo Failure Codes That Produce Reports Worth Reading

A reliability engineer opens the failure history for a critical pump family and finds three years of work orders where the top problem code is “Other”, the top cause is blank, and the remedy is a single free-text word. That library is not producing reports; it is producing a shrug. Maximo failure codes are the least glamorous corner of the work management chain and one of the most consequential. When they are configured against a real taxonomy and adopted at the work order, the history compounds into something a reliability team can actually use. When they are not, every reliability review starts from a fresh spreadsheet.

This piece covers the configuration and adoption patterns that make Maximo failure codes worth capturing, focused on IBM Maximo Manage, including under MAS. The mechanics are long established and apply equally to Maximo 7.6.1 estates that have not yet upgraded.

What Maximo Failure Codes Actually Are

In Maximo Manage, failure reporting is built from four related records. A failure class is a top-level category of failure behaviour, typically aligned to an equipment type. A problem is the observed symptom on the asset. A cause is the underlying reason the problem occurred. A remedy is the action that resolved it. Problems, causes and remedies are all held as failure codes and arranged into a hierarchy under the class.

The Failure Codes application is where the hierarchy is built and maintained. Failure classes are associated with assets, operating locations and, where relevant, item records, so that a work order raised against an asset inherits the appropriate class and offers only the problem, cause and remedy codes that make sense for that class. On the work order itself, the Failure Reporting tab is where the technician or supervisor records what was observed, why it happened, and what was done about it.

Two points get missed routinely. The first is that the failure class on the asset drives which codes appear on the work order; if the class is wrong, the technician is choosing from the wrong menu. The second is that the four records are separate objects with separate lifecycles. Adding a new remedy to the hierarchy does not retroactively tag old work orders. The history is what the field entered at the time, and no amount of later curation can rewrite it.

The Hierarchy That Earns Its Keep

The most common failure of a failure library is that it was built by copying a supplier’s catalogue or an old CMMS export, without a decision about the level of detail the operation can actually sustain. Ten problem codes per class is defensible. Two hundred is a category chosen by a committee that will never look at the data again.

The pattern that holds up:

One failure class per genuinely distinct failure behaviour. A centrifugal pump and a positive displacement pump are different classes; two sizes of the same centrifugal pump are not.
Problem codes at the level a technician can actually observe from the field. “Bearing noise”, “seal leakage”, “vibration above trip”, “no start”. Not “bearing wear stage 2 per API 610”, which nobody diagnoses without a specialist.
Cause codes short enough to hold in mind while closing a work order. Fifteen to twenty per class is usually enough. If the library has fifty causes for a valve, most of them will be “Other” in practice.
Remedy codes that describe the intervention, not the paperwork. “Replaced seal”, “adjusted alignment”, “tightened bolting”. Not “work order closed” or “maintenance completed”, which encode nothing.
Failure hierarchies aligned to the way the equipment is actually maintained, not to the plant P&ID. The reliability engineer needs to compare like with like across the fleet; the P&ID does not.

A failure library that shrinks after the first year is usually a library that is being used. One that only grows is usually one that nobody is curating.

The Adoption Problem at the Work Order

Configuration decides whether the codes are available. Adoption decides whether they are recorded. Estates with a technically clean hierarchy and an empty Failure Reporting tab are common enough that it deserves its own diagnosis.

Three things drive adoption at the point of close:

Making failure reporting mandatory at work order close for the work types where reliability data actually matters, and not for the ones where it does not. A statutory inspection with no defect does not need a problem code. A corrective work order on a critical asset does.
Keeping the code menus short enough to choose in the field without a supervisor’s help. If the technician has to page through three screens on a mobile device to find the right cause, they will pick the first plausible one.
Feeding the codes back into something the field can see. A monthly bad actor list by asset, generated from the failure history, is a visible sign that the entries matter. If the codes disappear into a database nobody reads, the discipline erodes within a quarter.

Programmes that pair a small, curated library with mandatory close-out on the right work types and a visible feedback loop routinely lift usable failure reporting from single digits to well above eighty per cent. The technology has not changed; the operating discipline around it has.

Aligning to ISO 14224 Without Copying It Wholesale

For asset-intensive operators, the natural reference is ISO 14224, the international standard for collection and exchange of reliability and maintenance data in the petroleum, petrochemical and natural gas industries. It is widely used well beyond that sector because its taxonomy for equipment classes, failure modes and failure causes is one of the few reliable common languages available. Applied in practice, ISO 14224 is a discipline, not a form, and the same restraint applies when mapping it into Maximo.

The pragmatic approach is to align the Maximo failure class hierarchy to ISO 14224 at the class and problem level, so that fleet reporting rolls up cleanly, and to leave cause and remedy codes at the level the operation can sustain. A wholesale import of the standard’s cause taxonomy produces a menu the field will never navigate. A thoughtful subset, with the ISO code held as an attribute where an external report needs it, produces both a report that reads consistently and a work order screen that is used.

The link into a reliability programme is where the value shows up. Failure codes are the raw material for root cause analysis run as a standing programme and for the bad actor lists that drive PM strategy changes. Without them, the reliability engineer works from memory and a small sample of recent incidents.

Reporting That Reflects Reality

The purpose of the library is a set of reports that make decisions easier. The reports that repay the effort are usually simple:

Failure frequency by class and problem, over a rolling window, for a defined asset population.
Top causes on the highest cost or highest downtime assets, refreshed monthly.
Remedy patterns that suggest a job plan or PM strategy needs revising, feeding back into the job plan library that runs the recurring work.
A compliance view showing failure reporting completion rates for the work types where it is mandatory, so that the operating discipline is visible to a supervisor.

None of these depend on advanced analytics. They depend on the failure codes at the bottom of the stack being defensible, being captured, and being reviewed by someone who can act on them.

Closing Position

Maximo failure codes are a small configuration decision that decides how much of the estate’s failure history is worth reading in year three. A short, curated hierarchy aligned to a real taxonomy, mandatory reporting on the work types that matter, a visible feedback loop into reliability decisions, and a named owner for the library, are what turn the Failure Reporting tab from decoration into a working record. Reliability programmes that skip this quietly rebuild their evidence base from scratch every time; the ones that invest in it find that the reports start writing themselves.