Failure Modes and Causes: How to Build a Data Taxonomy for Enterprise Reliability

In the world of industrial maintenance, data is often abundant but insight is scarce. You likely have a Computerized Maintenance Management System (CMMS) filled with thousands of closed work orders. Yet, when you ask the fundamental question—"Why are our centrifugal pumps failing most often?"—the answer is buried in free-text notes like "fixed broken pump" or "replaced seal."

This is the "garbage in, garbage out" paradox of reliability engineering.

The solution isn't just "better maintenance"; it is better data architecture. Specifically, it requires a rigorous distinction between Failure Modes and Failure Causes.

If you are a Reliability Engineer or Operations Director, you aren't just looking for definitions. You are looking for a system to standardize failure data so you can move from reactive firefighting to prescriptive precision.

Here is the core insight upfront: A Failure Mode is what happens (the observable symptom), while the Failure Cause is why it happened (the underlying mechanism).

To solve chronic reliability issues, you must stop treating these two concepts as interchangeable. You need to build a hierarchical taxonomy—ideally based on ISO 14224—that forces technicians to select the specific mode and cause upon closing a work order. Without this structured data, your transition to AI-driven predictive maintenance is impossible.

Below, we will dismantle the complexity of failure coding, moving from basic definitions to advanced taxonomy construction and the integration of AI in 2026.

The Anatomy of Failure: Mode vs. Cause vs. Effect

The first step in cleaning up your reliability data is establishing a strict vocabulary. In many facilities, these terms are used loosely, leading to confusion during Root Cause Analysis (RCA).

What is a Failure Mode?

A Failure Mode is the manner in which a failure is observed. It is the "loss of function" or the symptom that triggers the maintenance request. It is what the operator sees, hears, or smells.

• The Key Test: Can you see it happening?
• Examples: "Pump fails to start," "Low discharge pressure," "External leakage," "High vibration," "Seized shaft."

In the context of asset management, the failure mode describes the gap between the asset's required performance and its actual performance.

What is a Failure Cause?

A Failure Cause is the physical or chemical process, design defect, quality issue, or human error that initiated the failure mode. This is the root (or at least the physical root) of the problem.

• The Key Test: Why did the mode occur?
• Examples: "Fatigue," "Corrosion," "Misalignment," "Lubrication breakdown," "Operator error," "Normal wear and tear."

What is a Failure Effect?

The Failure Effect is the consequence of the failure mode on the operation, safety, or environment. This is crucial for determining criticality (FMECA).

• The Key Test: What happens to the plant?
• Examples: "Production line stop," "Safety hazard (fire)," "Environmental spill," "Reduced capacity."

The "Chain of Causality" Example

Let’s look at a practical scenario involving a conveyor motor.

1. Failure Cause: The bearing lubrication was contaminated with dust (Contamination).
2. Failure Mechanism: This caused increased friction and heat (Wear).
3. Failure Mode: The motor shaft seized (Seized).
4. Failure Effect: The conveyor belt stopped, halting the packaging line for 4 hours (Downtime).

If your work order simply says "Conveyor Stopped," you have recorded the Effect. If it says "Motor Broke," you have recorded nothing of value. If it says "Bearing Seized due to Contamination," you have captured both Mode and Cause, allowing you to implement a solution (better seals or preventive maintenance procedures for cleaning).

Designing a Failure Code Taxonomy (ISO 14224 Approach)

Now that the definitions are clear, the next logical question is: "How do I structure this in my CMMS so my data is actually usable?"

If you allow technicians to type free text, you will never be able to aggregate data. You need a hierarchy. The gold standard for this is ISO 14224 (Petroleum, petrochemical and natural gas industries — Collection and exchange of reliability and maintenance data). While originally for oil and gas, its structure is the benchmark for all heavy industries.

Level 1: Asset Class & Equipment Unit

You cannot have a universal list of failure modes for the entire plant. A "Leaking Seal" mode applies to a pump but not a circuit breaker.

• Structure: Define the Equipment Class (e.g., PUMP, MOTOR, COMPRESSOR).
• Best Practice: Map your assets to standard classes.

Level 2: The Maintainable Item (Component)

Failures rarely happen to the "Pump" as a whole; they happen to a specific part.

• Examples: Mechanical Seal, Impeller, Bearing, Casing, Coupling.
• Strategy: Don't go too deep. You don't need to track every bolt. Track the "maintainable items"—parts you would replace or repair as a unit.

Level 3: Failure Mode (The Drop-Down Menu)

When a technician closes a work order, they should select the component, and then the Mode.

• The Rule of 80/20: For any given asset class, 20% of the modes account for 80% of the failures.
• Standard Modes for Rotating Equipment:
  • Leakage (External/Internal)
  • Vibration (High)
  • Overheating
  • Noise (Abnormal)
  • Output (Low/High/None)
  • Structural Deficiency (Crack/Loose)

Level 4: Failure Cause (The Root)

This is often the hardest for technicians to identify immediately, but it is vital for preventive maintenance optimization.

• Cause Categories:
  • Design: (Undersized, Wrong Material)
  • Manufacturing/Installation: (Misalignment, Loose Assembly)
  • Operation: (Overload, Impact)
  • Maintenance: (Lack of Lube, Wrong Part)
  • Wear/Aging: (Corrosion, Erosion, Fatigue)

The "Other" Trap

Warning: Do not include a generic "Other" code at the top of your list. If you do, 40% of your data will be categorized as "Other" because it is the path of least resistance for a busy technician. If you must have "Other," require a mandatory text field explanation.

From Taxonomy to FMEA: Calculating Risk

Once you have a taxonomy, how do you use it? You use it to feed your Failure Mode and Effects Analysis (FMEA).

FMEA is a systematic method for evaluating processes to identify where and how they might fail and to assess the relative impact of different failures.

The RPN Calculation

The core of FMEA is the Risk Priority Number (RPN). $$RPN = Severity (S) \times Occurrence (O) \times Detection (D)$$

1. Severity (1-10): If this Failure Mode happens, how bad is it? (1 = No effect, 10 = Hazardous/Safety Risk).
2. Occurrence (1-10): How often does this Failure Cause lead to this Mode? (1 = Remote, 10 = Inevitable).
3. Detection (1-10): If the Cause occurs, how likely are we to catch it before the asset fails? (1 = Certain detection, 10 = Impossible to detect).

Using Your Data to Refine RPN

Most organizations guess at these numbers. However, if you have been collecting structured Failure Mode and Cause data for six months, you don't have to guess.

• Occurrence Data: Look at your CMMS. How many times did "Code 5.1: Bearing Seizure" occur in the last year? That is your real-world Occurrence score.
• Detection Data: Did your predictive maintenance sensors catch the vibration spike before the seizure? If yes, your Detection score improves (lowers).

By feeding real failure data back into your FMEA, you turn a static document into a living reliability strategy. This is the foundation of Reliability Centered Maintenance (RCM).

The Role of AI and Predictive Maintenance in 2026

You might be asking, "In 2026, why are we still talking about manual failure codes? Shouldn't AI do this?"

This is a critical follow-up. The answer is yes, but AI needs a teacher.

Supervised Learning Requires Labels

AI predictive maintenance models work by recognizing patterns in sensor data (vibration, temperature, amperage) that precede a failure. However, the AI doesn't inherently know that a specific vibration signature equals "Misalignment."

It learns this by looking at historical data. It looks at the sensor logs from January 12th and sees a spike. Then it looks at the Work Order from January 13th.

• Scenario A: The Work Order says "Fixed pump." The AI learns nothing.
• Scenario B: The Work Order says "Failure Mode: High Vibration; Cause: Misalignment." The AI now learns: "This vibration pattern = Misalignment."

Automated Failure Coding

Advanced platforms now use Natural Language Processing (NLP) to assist technicians. When a tech dictates notes into a mobile CMMS, the AI can suggest the correct Failure Mode and Cause codes.

• Tech says: "Found the impeller was chewed up by cavitation."
• AI Suggests: Mode: Physical Damage; Cause: Cavitation; Component: Impeller.

This hybrid approach reduces the administrative burden on technicians while ensuring the database remains clean and standardized.

Troubleshooting Implementation: Why Data Collection Fails

Even with the best taxonomy, implementation often fails on the shop floor. Why?

1. The "List of 100" Problem

If a technician opens a drop-down menu on a tablet and sees 100 failure codes, they will pick the first one just to close the screen.

• Solution: Use "Smart Filtering." If the asset is a "Motor," only show the 10 motor-related failure modes. Do not show "Leaking Seal" if the motor doesn't have a fluid seal. Keep the list to <10 options per category.

2. The "Human Error" Blame Game

It is tempting to list "Human Error" or "Operator Error" as a Failure Cause.

• The Problem: This stops the investigation. It blames a person rather than a system.
• The Fix: Dig deeper. Was it "Human Error" because the labels were missing? Then the cause is "Inadequate Labeling." Was it because they were untrained? Then the cause is "Training Gap." Reserve "Human Error" for willful negligence, which is rare.

3. Lack of Feedback Loops

Technicians hate entering data into a "black hole."

• The Fix: Show them the result. "Hey team, because you accurately coded the 'Belt Slippage' failures last month, we identified a bad batch of tensioners and got the vendor to replace them for free." When they see the value, compliance skyrockets.

Advanced Analytics: MTBF and Root Cause Analysis

Once you have clean Mode and Cause data, you can unlock the metrics that actually drive business decisions.

True Mean Time Between Failures (MTBF)

Generic MTBF calculates the time between any work order. But that’s misleading. You want to know the MTBF for specific failure modes.

• Generic: "This pump fails every 3 months."
• Specific: "The mechanical seal fails every 6 months, but the bearings fail every 2 years." This insight tells you that you don't need a new pump; you need a better seal support system.

Pareto Analysis for RCA

Use your data to build a Pareto Chart (80/20 rule).

1. Group failures by Mode. (e.g., 60% of pump failures are "Seal Leaks").
2. Drill down into that Mode by Cause. (e.g., Of those seal leaks, 70% are "Chemical Attack").
3. Action: Change the seal face material from Carbon/Ceramic to Silicon Carbide.

This is prescriptive maintenance in action. You aren't fixing a pump; you are engineering out a specific defect based on data.

The Financial Impact: ROI of Failure Coding

Finally, how do you justify the time investment to set this up?

According to NIST (National Institute of Standards and Technology), ineffective maintenance costs the U.S. manufacturing industry billions annually.

The Cost of Ambiguity

If you don't know the Failure Cause, you default to "Replace Component."

• Scenario: A $5,000 motor trips.
• Without Data: You replace the motor. ($5,000 cost).
• With Data: History shows "Cause: Loose Connection" is 90% probable for this symptom. You tighten the terminal. ($0 parts cost, 15 mins labor).

Inventory Optimization

Failure Mode data directly impacts inventory management. If your data shows that "Bearing Failure" is rare but "Seal Failure" is frequent, you can adjust your stock levels—reducing capital tied up in bearings and increasing seal availability to reduce Mean Time To Repair (MTTR).

Conclusion: Start Small, But Start Standardized

You do not need to map every failure mode for every asset in your plant by next week. Start with your Criticality A assets—the ones that stop production if they fail.

1. Adopt the ISO 14224 hierarchy structure.
2. Configure your CMMS to require Mode and Cause fields for these assets.
3. Train your technicians on why this matters (it saves them from fixing the same thing twice).
4. Review the data in 90 days and look for the patterns.

Failure is inevitable in mechanical systems. But repeated, unexplained failure is a choice. By mastering failure modes and causes, you choose reliability.