A fishbone diagram is a tool that can help you perform a cause and effect analysis for a problem you are trying to solve. This type of analysis enables you to discover the root cause of a problem.
This tool is also called a cause and effect diagram or an Ishikawa diagram. These names can be used interchangeably.
Dr Kaoru Ishikawa made many contributions to quality, the most noteworthy being his total quality viewpoint, company wide quality control, his emphasis on the human side of quality, the Ishikawa diagram and the assembly and use of the “seven basic tools of quality”:
• Pareto analysis which are the big problems?
• Cause and effect diagrams what causes the problems?
• Stratification how is the data made up?
• Check sheets how often it occurs or is done?
• Histograms what do overall variations look like?
• Scatter charts what are the relationships between factors?
• Process control charts which variations to control and how?
The right side of the diagram lists the effect. The effect is written as the problem statement for which you are trying to identify the causes.
Ishikawa FishBone Cause Effect diagram
Ishikawa diagrams were popularized by Kaoru Ishikawa[3] in the 1960s, who pioneered quality management processes in the Kawasaki shipyards, and in the process became one of the founding fathers of modern management.
The basic concept was first used in the 1920s, and is considered one of the seven basic tools of quality control.[4] It is known as a fishbone diagram because of its shape, similar to the side view of a fish skeleton.
Mazda Motors famously used an Ishikawa diagram in the development of the Miata sports car, where the required result was "Jinba Ittai" (Horse and Rider as One — jap. 人馬一体). The main causes included such aspects as "touch" and "braking" with the lesser causes including highly granular factors such as "50/50 weight distribution" and "able to rest elbow on top of driver's door". Every factor identified in the diagram was included in the final design.
The 5 Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem.[1] The primary goal of the technique is to determine the root cause of a defect or problem. (The "5" in the name derives from an empirical observation on the number of iterations typically required to resolve the problem.)
Example
The vehicle will not start. (the problem)
Why? - The battery is dead. (first why)
Why? - The alternator is not functioning. (second why)
Why? - The alternator belt has broken. (third why)
Why? - The alternator belt was well beyond its useful service life and not replaced. (fourth why)
Why? - The vehicle was not maintained according to the recommended service schedule. (fifth why, a root cause)
Start maintaining the vehicle according to the recommended service schedule. (possible 5th Why solution)
The questioning for this example could be taken further to a sixth, seventh, or higher level, but five iterations of asking why is generally sufficient to get to a root cause. The key is to encourage the trouble-shooter to avoid assumptions and logic traps and instead trace the chain of causality in direct increments from the effect through any layers of abstraction to a root cause that still has some connection to the original problem. Note that, in this example, the fifth why suggests a broken process or an alterable behaviour, which is indicative of reaching the root-cause level.
It is interesting to note that the last answer points to a process. This is one of the most important aspects in the 5 Why approach - the real root cause should point toward a process that is not working well or does not exist.
Untrained facilitators will often observe that answers seem to point towards classical answers such as not enough time, not enough investments, or not enough manpower. These answers may be true, but they are out of our control.
Therefore, instead of asking the question why?, ask why did the process fail? A key phrase to keep in mind in any 5 Why exercise is "people do not fail, processes do".
This tool is also called a cause and effect diagram or an Ishikawa diagram. These names can be used interchangeably.
Dr Kaoru Ishikawa made many contributions to quality, the most noteworthy being his total quality viewpoint, company wide quality control, his emphasis on the human side of quality, the Ishikawa diagram and the assembly and use of the “seven basic tools of quality”:
• Pareto analysis which are the big problems?
• Cause and effect diagrams what causes the problems?
• Stratification how is the data made up?
• Check sheets how often it occurs or is done?
• Histograms what do overall variations look like?
• Scatter charts what are the relationships between factors?
• Process control charts which variations to control and how?
Ishikawa Diagram Structure
The left side of the diagram is where the causes are listed. The causes are broken out into major cause categories. The causes you identify will be placed in the appropriate cause categories as you build the diagram.The right side of the diagram lists the effect. The effect is written as the problem statement for which you are trying to identify the causes.
Ishikawa FishBone Cause Effect
Ishikawa diagrams were popularized by Kaoru Ishikawa[3] in the 1960s, who pioneered quality management processes in the Kawasaki shipyards, and in the process became one of the founding fathers of modern management.
The basic concept was first used in the 1920s, and is considered one of the seven basic tools of quality control.[4] It is known as a fishbone diagram because of its shape, similar to the side view of a fish skeleton.
Mazda Motors famously used an Ishikawa diagram in the development of the Miata sports car, where the required result was "Jinba Ittai" (Horse and Rider as One — jap. 人馬一体). The main causes included such aspects as "touch" and "braking" with the lesser causes including highly granular factors such as "50/50 weight distribution" and "able to rest elbow on top of driver's door". Every factor identified in the diagram was included in the final design.
Causes
Causes in the diagram are often categorized, such as to the 6 M's, described below. Cause-and-effect diagrams can reveal key relationships among various variables, and the possible causes provide additional insight into process behavior. Causes can be derived from brainstorming sessions. Causes can be traced back to root causes with the 5 Whys technique.The 5 Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem.[1] The primary goal of the technique is to determine the root cause of a defect or problem. (The "5" in the name derives from an empirical observation on the number of iterations typically required to resolve the problem.)
Example
The vehicle will not start. (the problem)
Why? - The battery is dead. (first why)
Why? - The alternator is not functioning. (second why)
Why? - The alternator belt has broken. (third why)
Why? - The alternator belt was well beyond its useful service life and not replaced. (fourth why)
Why? - The vehicle was not maintained according to the recommended service schedule. (fifth why, a root cause)
Start maintaining the vehicle according to the recommended service schedule. (possible 5th Why solution)
The questioning for this example could be taken further to a sixth, seventh, or higher level, but five iterations of asking why is generally sufficient to get to a root cause. The key is to encourage the trouble-shooter to avoid assumptions and logic traps and instead trace the chain of causality in direct increments from the effect through any layers of abstraction to a root cause that still has some connection to the original problem. Note that, in this example, the fifth why suggests a broken process or an alterable behaviour, which is indicative of reaching the root-cause level.
It is interesting to note that the last answer points to a process. This is one of the most important aspects in the 5 Why approach - the real root cause should point toward a process that is not working well or does not exist.
Untrained facilitators will often observe that answers seem to point towards classical answers such as not enough time, not enough investments, or not enough manpower. These answers may be true, but they are out of our control.
Therefore, instead of asking the question why?, ask why did the process fail? A key phrase to keep in mind in any 5 Why exercise is "people do not fail, processes do".
