CRL 1-hr: 9/26 Introduction to Uptime Elements Reliability Framework and Asset Management System

As an enhanced tool that captures problems and solutions visually, Cause Mapping expands on some of the basic ideas of the fishbone diagram for a clearer, more accurate and more specific causeand-effect analysis. Cause Mapping uses a systems-thinking approach to root-cause analysis andcident investigation that improves the way people analyze, document, communicate and solve problems.


Five distinctions distinguish Cause Mapping from the standard fishbone diagram, and each help make Cause Mapping's investigation process and solutions more effective.

1. Cause Maps Read Left to Right

Since the traditional Japanese language reads right to left across a page, the fishbone starts with a problem on the right and builds across the page moving left. A Cause map starts on the left and reads right. At every point in both on the fishbone and Cause Map, investigators ask "why" questions that move backward through time, studying effects and finding their causes. This distinguishes the Cause Map from the process map, which moves forward through time with arrows pointing left to right (the process involves performing step one, then step two, etc.)

2. Cause Maps Tie Problems to an Organization's Overall Goals

The fishbone defines one problem and finds causes. The Cause Mapping solution, however,recognizes that problems aren't always that simple.

First, just try defining one problem by asking "What's the problem?" That question can create significant disagreement in any organization, with answers varying widely depending on a person's perspective. What some see as a problem, others may see as just a symptom of a larger, more significant issue. Starting an investigation with a single problem does not necessarily reflect the nature of an incident.

Cause Mapping defines problems within the context of an organization's overall goals, for which everyone within the group shares the same perspective. For instance, one company may have a problem that involves a risk to safety, a production loss and additional labor costs-and every employee, from the machine operator to the CEO, knows the need to minimize all three. These represent the organization's overall goals, and they involve multiple people, departments and processes. Yet defining a single problem doesn't reflect how the incident affected these goals. On the other hand, defining an incident by how it deviates from these goals provides common ground for the start to any investigation.


3. Cause Maps Focus on Cause-and-Effect, not Categories

An analysis breaks something down into its parts; analyzing an incident involves breaking it down into specific cause-and-effect relationships.


Fishbone diagrams group similar causes into categories: methods, machines, materials,etc. Categorization, however, creates generalizations-and represents a polar opposite of analysis. Grouping an incident's possible causes by category does not show the cause-and effectrelationships. In effect, a fishbone's categories simply create a "Yellow Pages" directory of causes-not a map that details how causes and effects relate. For instance, a training issue grouped under "people" can cause a person to make an error that results in an equipment failure, grouped under "machinery."

Specific details form the bedrock of any investigation, from the crime scene to machine maintenance issues on a plant floor, and a thorough analysis helps uncover those details. The Cause Map organizes these details visually into "effect" boxes on the left followed by a cause to its right; that cause, in turn, represents an effect of another cause, again placed to the right. (For this reason, everybox in a Cause Map can be viewed as both an effect and a cause at the same time.)

The fuel that drives the Cause-Map analysis involves "why" questions, which link together a chain of events. An investigator asks why an event occurred, and the answer will identify at least one cause of that effect; asking "why" that cause occurred turns that cause into an effect, and identifies further causes back up the chain of events.

The relationship between causes is more important than the category that the causes fit within. Just as a topographical map should reflect the actual terrain, a Cause Map should reflect the actual incident.

4. Cause Mapping Focuses on Evidence-Based Causes

The fishbone method regularly identifies possible causes, which encourages speculation. Cause Mapping, on the other hand, focuses its analysis on causes supported by evidence. Causes produce effects; anything required to produce an effect is, by definition, a cause of that effect. Heat, fuel and oxygen, all interacting, "cause" fire.

Causes are supported by evidence while possible causes lack that evidence. During analysis of a past event, investigators may develop possible causes, identifying them throughout the Cause Map. But they are identified and treated as such, clearly distinguishable from the Cause Map's principal focus: causes supported by evidence. This makes sense, since any past incident only has actual causes, not possible ones.

5. Cause Maps Focus on Systems Thinking

Which part of a car is required for the car to function: the engine, the transmission, the battery, the driver, the steering wheel, the tires, the brakes, or the fuel? They all are, of course, because all of these elements work as a system; remove one element, and the system doesn't operate the way it should. Considering how these systems relate to causes and effects requires systems thinking. It doesn't look for one answer, or the cause, but analyzes how elements and systems work together to create an incident. It also helps explain why there are so many disagreements when people try to identify "the cause" of an incident. In fact, most organizations only focus on a single cause and fail to see the incident as a system.

To illustrate systems thinking, consider one of the most devastating and technically complex incidents of the early 20th Century-the sinking of the Titanic. If you ask a group of people why the ship sank, you will likely receive various responses: the ship hit an iceberg; the ship filled with water; the steel was weak;or the ship was going too fast. Which one of the causes was required for the Titanic to sink? All of them were. Why? It is because the Titanic disaster occurred as a system.


A system requires all of its parts, just as an incident requires all of its causes. While many think of root cause as a single element in Cause Mapping, the actual root is, in fact, a system of causes. This systems approach shows that every effect has causes (plural), and it also allows any incident to be viewed more accurately at multiple levels of detail.

The more people focus on a single element that caused an incident, the more unnecessary disagreement, debate and argument can ensue. Unlike the fishbone diagram, Cause Mapping puts systems thinking front-and-center by clearly showing how systems of causes work together to create the problems that deviate from the organization's goals.



The Cause Mapping approach builds upon and refines some of the fishbone diagram's original concepts. The concepts, examples and exercises involved with Cause Mapping improve the way people analyze, document, communicate and solve problems. The purpose of an investigation is to find the best solutions to prevent an incident from occurring, and a Cause Map helps reach this ideal by efficiently laying out-on one map- the organization's goals, problems and the systems of evidence-supported causes.

For more information on Cause Mapping visit to view free examples, templates, articles and videos.

Mark Galley

Upcoming Events

August 8 - August 10, 2023

Maximo World 2023

View all Events
80% of newsletter subscribers report finding something used to improve their jobs on a regular basis.
Subscribers get exclusive content. Just released...MRO Best Practices Special Report - a $399 value!
Uptime Elements Root Cause Analysis

Root Cause Analysis is a problem solving method. Professionals who are competent in Root Cause Analysis for problem solving are in high demand.

Reliability Risk Meter

The asset is not concerned with the management decision. The asset responds to physics

Why Reliability Leadership?

If you do not manage reliability culture, it manages you, and you may not even be aware of the extent to which this is happening!

Asset Condition Management versus Asset Health Index

Confusion abounds in language. Have you thought through the constraints of using the language of Asset Health?

Seven Chakras of Asset Management by Terrence O'Hanlon

The seven major asset management chakras run cross-functionally from the specification and design of assets through the asset lifecycle to the decommissioning and disposal of the asset connected through technology

Reliability Leader Fluid Cleanliness Pledge

Fluid Cleanliness is a Reliability Achievement Strategy as well as an asset life extension strategy

MaximoWorld 2022 Conference Austin Texas

Connect with leading maintenance professionals, reliability leaders and asset managers from the world's best-run companies who are driving digital reinvention.

“Steel-ing” Reliability in Alabama

A joint venture between two of the world’s largest steel companies inspired innovative approaches to maintenance reliability that incorporate the tools, technology and techniques of today. This article takes you on their journey.

Three Things You Need to Know About Capital Project Prioritization

“Why do you think these two projects rank so much higher in this method than the first method?” the facilitator asked the director of reliability.

What Is Industrial Maintenance as a Service?

Industrial maintenance as a service (#imaas) transfers the digital and/or manual management of maintenance and industrial operations from machine users to machine manufacturers (OEMs), while improving it considerably.