E-Book "Lean Manufacturing Basics" Free Download

Enter Your Name and Email Below And Hit the Download Now Button
Name:
Email:

SECURE & CONFIDENTIAL
Your email address will NEVER be rented, traded or sold.
WE GUARANTEE YOUR CONFIDENTIALITY.
We hate spam as much as you do

 

Monday, October 05, 2009

Cause and effect diagram (Ishikawa Diagram)

A company has a problem that they need solving. For sake of example, it is a quality issue. So the company gathers a team together to figure out what is happening to truly cause this problem. They have all heard of a “root cause analysis”, and would like to find the true root cause that is causing this problem. They gather together in a room and start to brainstorm what the possible causes are. But they quickly realize that their brainstorming session isn’t focused at all, but they keep going.


They come up with what they think is the true root cause, and find a corrective action for it. They implement the corrective action, only to find out later that while they have helped the problem, they haven’t actually found or fixed the root cause. This is the hazard of not using the cause and effect diagram during a root cause analysis.

A cause and effect diagram, simply put, provides a way for the average manager or office worker to be able to effectively come up with a true root cause of a problem. It is a process that can be repeated by anyone with a basic level of understanding of the system or the processes involved. It also allows the team to be able to approach extremely complex problems and situations by breaking it down into the fundamental components of what usually goes wrong in most situations.

The first cause and effect diagram was created in 1943 at the Kawasaki Steel Works to depict the work factors involved with a process. Because of this, they are sometimes called Ishikawa diagrams, after the original presenter, Kaoru Ishikawa. They are also called fishbone diagrams in some circles because of their resemblance to fish bones.

It is very uncommon for a quality problem, or any problem in today’s high tech world, to be simple. Often, they contain many different factors and interactions that are hard to conceptualize when sitting in a meeting room. A cause and effect diagram breaks these complex problems down into easier, more simplified components, so they can each be individually addressed for determining their root cause.

A good diagram will break down the issue into major causes and sub causes, leading to the eventual discovery of root causes, which is the end goal of all six sigma processes. It will also provide a visual understanding of the problem for all parties involved, leading to a better understanding of the problem, and provides a way to focus on the correct issues to discuss and analyze.
Cause and effect diagram (Ishikawa Diagram)
Figure (1)


There are very few instances of brainstorming sessions that should not include a fishbone diagram. An example of a fishbone is contained in Figure (1). The cause and effect diagram should always start with the effect that you wish to change on the right side of the paper, in the case of the above example, the “Leaking Pump”. You should then draw the backbone of the fish, a horizontal line from left to right. Include the primary causes, or even just a general category of cause on diagonal lines that are alternating between above and below the backbone of the fish. This can be seen in Figure (1) by the categories of “Leaking Seal”, “Leaking O-Ring”, “Misaligned Leakage”, “Improperly assembled seal kit”, “Environmental”, and “Ruptured Seal”.

From those lines, you should branch off into additional diagonal lines that indicate the secondary causes, or the causes of the primary causes. For example, in Figure (1), the “Static vs. Dynamic” and “Cold Weather” causes are the root causes. From there, you can branch off a third time from each secondary cause, which will indicate the root cause that should be addresses. Not every secondary cause is going to have a root cause, as the secondary cause is sometimes the root cause of the problem. Figure (1) doesn’t have any third level causes, as the second level each contain the true root causes.

Once you have done this, you should have a good, thorough, cause and effect diagram. From here, you should mark the causes that you plan on correcting, and then brainstorm a corrective action, or many corrective actions, that will address the root cause. Theoretically, if the root causes of a problem are eliminated, the problem will either disappear, or be dramatically reduced. In reality, what happens in many situations, is that the problem changes into a new problem with the same symptoms, making it look like the root cause was not the true root cause. What actually happens is that the root cause changes, but causes the same problem. Many times, the reason for this is that the new root cause was being masked by the bigger, original root cause.

Many companies require all of their employees, from the hourly worker to the CEO, to be able to correctly make a fishbone diagram and participate in the root cause analysis. It is a simple process that can be understood by all, yet can lead to dramatic changes for the better. It is in a company’s best interests to be able to fix a lot of their problems by using the cause and effect diagram by any and all personnel.

If a company is interested in a process that is simple, straightforward, and more often than not attacks the root cause of the problem, all employees should be well versed in creation and execution of a fishbone, or cause and effect, diagram.

2 comments:

proactguy said...

I understand the basic concept of the Fishbone Diagram, but how are "major causes", "sub-causes" and "root causes" validated? Is it good enough that someone suggested its place on the Fishbone Diagram or is hard evidence required to validate (as opposed to hearsay)?

What is the definition of a "root cause"? Is it based on the content of the identified cause or the level in the Fishbone diagram? How will you know when you have reached a "root cause"?

Using a Fishbone Diagram how do I uncover the systems related contributions to the failure? For instance in the diagram in the post, some levels bottom out with "lack of training" or "inadequate training".

From a systems perspective, wouldn't we want to understand why our training systems were deficient? Is it content, delivery, media, etc.? Where was the oversight in place that would have prevented us from putting people in the field who were not trained properly or qualified?

I also noticed on the Fishbone Diagram provided a category bottomed out with "parts". How do I write a recommendation for parts?

A Fishbone Diagram, like any other RCA tool, is only as good (and valid) as the skill of the person facilitating the team. In my experience most people abuse this tool and use hearsay as their primary source of verification and have little evidence to back up their conclusions. It is not all their fault as someone or some group also has to accept it if it does have deficiencies.

Also I find that people tend to further abuse this tool by not drilling down deep enough to uncover the systems related issues that contribute to poor decisions. They tend to focus on the physical aspects of the failure and not the systems aspects.

Regards

Robert J. (Bob) Latino

CEO

Reliability Center, Inc.

www.Reliability.com

www.Proactforhealthcare.com

804.458.0645 Tel

804.452.2119 Fax

Cory Boisoneau said...

While I would agree that a Fishbone diagram can be an effective tool for brainstorming, I do not believe it should still be considered true RCA for the following reasons:

1) Fishbone/Ishikawa does not show how causes relate to one another, making it tough to understand exactly how the problem occurred.
2) It does not account for all causes, it usually looks only at action causes, and does not consider the conditional environment (there are ALWAYS multiple causes for each effect).
3) It does not require evidence to support causes. It is hard to support a corrective action for a cause that is not backed with evidence.
4) Fishbone has a tendency to stop short of understanding the full scope of a given problem. Once the team has decided on a "root cause" or causes, they typically stop and move on to solutions before digging deep enough to explore the underlying causes.
5) Using categories tends to restrict thinking to categories, instead of digging into each effect more deeply to figure out it's causes, which could come from a variety of sources.

In closing, I would say that Fishbone is a useful tool and a good start to an analysis, but it is not capable of providing a complete enough analysis to convince most managers to invest in the corrective actions. A more robust RCA method is required to truly understand complex problems.

Regards,

Cory Boisoneau

Post a Comment

Anything to say. Please feel free to leave your comment below.