Visite nuestro sitio en Español: Confiabilidad.net    RSS | Contact

Improving on the Fishbone Effective Cause-and-Effect Analysis

by Mark Galley, ThinkReliability.com

In 1950s Japan, Kaurou Ishikawa became one of the first to visually lay out the causes of a problem. His fishbone, or “Ishikawa Fishbone,” helped visually capture a problem’s possible causes and,ltimately, has become a standard in corporate-quality and Six-Sigma programs. It begins with a problem, then identifies possible causes by separate categories that branch off like the bones of a fish. Its categories-typically including materials, methods, machines, measurement, environment and people-can be modified to better match a particular issue.

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.

fishbone-1

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.

fishbone-2

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-3

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.

fishbone-4

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.

fisbone-5

Conclusion

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 www.thinkreliability.com to view free examples, templates, articles and videos.

 

Comments (2)

  • Referring to par. 4, it is possible and sometimes necessary to enrich a cause map with possible causes (when you don't have a clear evidence, but a clear path to their potential inclusion in the the cause-effect chain).
    This method is commonly used for failure analysis. The only requirement is to test this potential cause as an hypotesis before converting it from possible cause to probable cause and preferrably to the most probable cause.
    If the test in the cause-effect analysis explains the logical sequence, you can leave the most probable cause in your cause map with a note to review it when you finish with your analysis.

    1) Posted 1:19 pm, 27 March 2012 by Javier M. Davila

  • Referring to par. 4, there are situations when it is convenient to include a possible cause. The condition is to consider it as an hypotesis and test it to conert it to probable and/or most probable cause.
    Lack of evidence is sustituted with logics and logic test to fill your cause- effect chain with failure analysis methods.

    2) Posted 1:27 pm, 27 March 2012 by Javier M. Davila

Have your say

Comments are moderated prior to publication.
Please fill out the fields below.
Email addresses will never be published.

Comment guidelines

You can use basic HTML (a, strong, em, blockquote).
Links automatically use the nofollow attribute.
Off-topic or inappropriate comments will be edited or deleted.

Knowledge Base Articles
Related Publication
Advertisement