Ask most reliability engineers what their CMMS tells them about failure patterns on a specific asset class and you will get one of two answers: either a shrug, or a Pareto chart built from work order descriptions that read "pump leaking," "broke down again," and "fixed." Free-text failure notes are not data. They are a diary. And a diary cannot tell you which failure mode is costing you the most downtime, which cause is recurring across multiple assets, or which maintenance task would have prevented the last three emergency callouts. That gap starts with the failure code taxonomy.
Configure a Structured Failure Code Taxonomy in OxMaint — and Start Getting Analysable Reliability Data From Your Next Work Order
OxMaint enforces separate Mode, Cause, and Effect fields at work order closure — no free text, no inconsistent entries, no data that cannot be Pareto-analysed. Sign up free or book a demo to see the failure code configuration live.
Why Most Plant CMMS Data Is Useless for Reliability Analysis
The problem is almost never the CMMS. It is what technicians are allowed to type into it. When work order closure fields accept any free text, the same physical event gets recorded as "bearing noise," "vibration on pump 4," "overheating — bearing side," and "shut down — hot bearing" by four different technicians across two shifts. Those are the same failure mode. A Pareto analysis will treat them as four separate, low-frequency events — each one below the threshold for investigation. The real pattern stays invisible.
The Three Pillars: Mode, Cause, and Effect
ISO 14224 and the OREDA handbook both organise failure data around three distinct concepts. Conflating any two of them produces data that looks complete but cannot be analysed. Each one answers a different question — and each one drives a different type of action.
These three fields together produce a record that is Pareto-analysable, RCM-traceable, and comparable across plants. Missing any one of them degrades the whole dataset — because you cannot answer "which failure cause is driving the most production-loss events on our pump fleet" without all three captured consistently on every work order. Sign up free on OxMaint to configure separate Mode, Cause, and Effect fields as mandatory work order closure requirements.
The ISO 14224 Equipment Hierarchy: Where Taxonomy Starts
Before failure codes can be meaningful, the equipment hierarchy they attach to must be structured. ISO 14224 organises assets in a nine-level hierarchy from industry segment down to maintainable item. For most manufacturing plants, the practical working levels are four:
The critical discipline: failure codes are attached at the equipment unit level, not the system or site level. A failure record that says "Cooling Water System — Leaking" is unsearchable. A failure record that says "P-101 — Mechanical Seal — Reduced Flow — Dry Running — Deferred to Next Planned Stop" is analysable, comparable to P-102 through P-108, and directly traceable to a PM action.
A Working Failure Code Set for Common Plant Equipment
The table below is not exhaustive — it is a starting point. The codes are drawn from ISO 14224 Annex tables and the OREDA handbook, adapted for plant application. Each equipment class needs its own controlled vocabulary; the principle is the same across all of them.
| Failure Mode | Failure Cause | Effect Class |
|---|---|---|
| Reduced flow output | Impeller wear / Cavitation / Clogged suction | Reduced throughput |
| Leaking — mechanical seal | Dry running / Bearing-induced shaft movement / Contamination | Environmental release / Full loss |
| Excessive vibration | Shaft misalignment / Bearing wear / Impeller imbalance | Deferred repair / Immediate repair |
| Fails to start | Electrical supply fault / Seized bearing / Control signal fault | Full production loss |
| Overheating — bearing housing | Lubrication starvation / Bearing contamination / Overload | Immediate repair required |
| Failure Mode | Failure Cause | Effect Class |
|---|---|---|
| Belt tracking off | Roller misalignment / Belt splice failure / Load asymmetry | Reduced throughput |
| Drive shaft seized | Bearing failure / Overload / Lubrication failure | Full production loss |
| Belt tear / splice failure | Foreign object damage / Fatigue at splice / Overloading | Full production loss |
| Reduced speed under load | Drive belt slipping / Motor fault / Gearbox wear | Quality degradation / Reduced throughput |
| Abnormal noise — drive end | Gearbox wear / Bearing deterioration / Coupling fault | Monitored and continued |
| Failure Mode | Failure Cause | Effect Class |
|---|---|---|
| Fails to start | Winding fault / Supply phase loss / Control circuit fault | Full production loss |
| Overheating — winding | Overload / Insulation degradation / Inadequate ventilation | Immediate repair / Full loss |
| Excessive vibration | Bearing wear / Rotor imbalance / Shaft misalignment | Deferred repair |
| High bearing temperature | Lubrication failure / Contamination / Excessive radial load | Immediate repair required |
| Trips on overcurrent | Driven equipment overload / Phase imbalance / Winding degradation | Full production loss |
These are starting codes, not finished taxonomies. Each plant's controlled vocabulary should be built with technicians and reliability engineers together — the technicians who know what they observe, and the engineers who know what they need to analyse. A code set built without technician input will not be used correctly at closure.
The Five Rules of a CMMS Taxonomy That Works
What Analysable Failure Data Makes Possible
Structured failure codes are not an admin exercise. They are the foundation for every reliability analysis that moves a maintenance programme from reactive to proactive. Here is what becomes possible once Mode, Cause, and Effect are captured consistently. Book a demo to see how OxMaint's failure code configuration enables all four from day one.
The Most Common Implementation Mistakes
Replace Free-Text Failure Notes With Structured, Analysable Data
OxMaint enforces separate Mode, Cause, and Effect dropdowns at work order closure — configured per equipment class, mandatory before closure, and immediately available for Pareto analysis and root cause reporting. Sign up free to configure your failure code taxonomy, or book a demo to see the configuration workflow.
Frequently Asked Questions
What is the difference between a failure mode and a failure cause in ISO 14224?
A failure mode is the observable state the asset entered when it failed — what changed at the functional boundary. "Leaking from mechanical seal" is a mode. A failure cause is the physical or operational mechanism that produced the mode — why it happened at the component level. "Dry running" or "shaft movement due to bearing wear" are causes of a mechanical seal failure. ISO 14224 requires both to be captured separately because they drive different actions: modes drive maintenance task selection, causes drive design or procedure review. Conflating them is the single most common failure code mistake in plant CMMS implementations.
What is OREDA and how does it relate to failure code taxonomy?
OREDA — Offshore Reliability Data — is a multi-industry consortium that has published equipment failure rate databases since 1984, built directly on ISO 14224 taxonomy. The OREDA handbook provides failure mode and cause vocabulary, failure rate data, and equipment subdivision guidance for major equipment classes. Its significance for plant taxonomy is twofold: it validates which failure modes are worth including in your controlled vocabulary (those with material frequency in the data), and it provides the cross-industry consistency basis that makes your plant data comparable to published benchmarks — but only if your taxonomy aligns with its classification structure.
How many failure mode codes should each equipment class have?
Ten to fifteen modes per equipment class is the practical ceiling for consistent application by technicians. Beyond that, technicians face decision fatigue at work order closure and begin defaulting to the most familiar code rather than the most accurate one. The initial list can be longer, but it should be pruned after the first six months of use: any code that appears fewer than five times in 12 months either represents a genuinely rare event or a code that nobody knows how to classify — both require investigation. Start with the ten most common observable states for the equipment class and add from field experience.
Why does coding at equipment unit level matter more than coding at system level?
MTBF, repeat failure analysis, and PM optimisation all depend on failure records being linkable to a specific asset with a known operating history. A failure record attached to "Cooling Water System" cannot contribute to MTBF calculation for any specific pump, cannot be compared to other pumps of the same class, and cannot trigger a PM review for the specific asset that is failing repeatedly. ISO 14224 is explicit that failure records must be attached at the equipment unit level — the specific item that was repaired — not the parent system or functional location. This is the most common structural error in plant asset hierarchies.
How does OxMaint enforce failure code discipline at work order closure?
OxMaint configures separate Failure Mode, Failure Cause, and Failure Effect dropdown fields at the equipment-class level — so a technician closing a pump work order sees only pump-relevant mode options, not a generic plant-wide list. All three fields are set as mandatory before a work order can be marked complete, preventing free-text entries and incomplete records. Administrators can update the taxonomy centrally — adding, merging, or retiring codes — and changes propagate immediately to all mobile users without requiring app updates. Sign up free to configure your first equipment class taxonomy today.
