Ankur Chaturvedi
Root Cause Analysis
In medicine, it's easy to understand the difference between treating the symptoms and curing the condition. A broken
wrist, for example, really hurts! But painkillers will only take away the symptoms; you'll need a different treatment to
help your bones heal properly.
But what do you do when you have a problem at
work? Do you jump straight in and treat the
symptoms, or do you stop to consider whether there's
actually a deeper problem that needs your attention?
If you only fix the symptoms – what you see on the
surface – the problem will almost certainly return,
and need fixing over, and over again.
However, if you look deeper to figure out what's
causing the problem, you can fix the underlying
systems and processes so that it goes away for good.
To Start With……………
Index
■ What is Root Cause Analysis(RCA)
■ Key Points to Take Care of
■ Approach
■ Root Cause Analysis Techniques
■ RCA Process in MM
■ Case Study
Root Cause Analysis (RCA)
Root Cause Analysis (RCA) is a popular and often-used technique that helps people
answer the question of why the problem occurred in the first place. It seeks to identify
the origin of a problem using a specific set of steps, with associated tools, to find the
primary cause of the problem, so that you can:
 Determine what happened.
 Determine why it happened.
 Figure out what to do to reduce the likelihood that it will happen again.
An action in one area triggers an action in another, and another, and so on. By tracing back these
actions, you can discover where the problem started and how it grew into the symptom you're now
facing.
Key Points to Take Care of :
Most organizations mistakenly use the term “root cause” to identify one main cause.
Focusing on a single cause can limit the solutions set, resulting in the exclusion of viable solutions.
The root is the system of causes that reveals all of the different options for solutions.The result …
multiple opportunities to mitigate risk and prevent problems.
The root cause is “the evil at the bottom” that sets in motion the entire cause-and-effect chain causing the problem(s)
An IT department determines a root cause for all significant
IT incidents. When the root cause is a process, system or
training issue a problem record is created. Problem records
drive a robust problem management process that
investigates, prioritizes and fixes problems. In this way, all
fixable root causes are addressed in an ongoing process of
improvement.
Too many companies use generic buckets like human error and procedure not followed
to classify an entire incident.
These are low-resolution investigations that result in weak solutions
A grocery store orders accidentally orders 1,000 bags of
apples when they only require 100. The order was entered
incorrectly and the supplier won't take them back. The store
needs to aggressively discount and advertise to sell the
apples at a loss. The issue is initially considered human
error. A root cause analysis process discovers latent human
error in ordering systems. For example, there is no validation
or warning for usually large orders. Also, fonts on the system
are abnormally small and difficult for some employees to
read clearly.
The root causes identified will depend on the way in which the problem or event is defined.
Effective problem statements and event descriptions (as failures, for example) are helpful and usually required to
ensure the execution of appropriate analyses.
Approach
Root Cause is not a “rocket science” – anyone can do it.You probably do it on a day to day basis.
RCA is simply the application of a series of well known, common sense techniques which can produce a
systematic, quantified and documented approach to the identification, understanding and resolution of
underlying causes.
RCA gives the confidence that the problem can be solved by taking a structured approach -
making sure that the problem never happens again.
Practical guide to carrying out an RCA
Tips for executing RCA :
 It is important to select the right team for
carrying out an RCA; members should have
knowledge of the process and be able to help
explore the why, what and how.
 Don't jump in with solutions: the problem and
solution may not be obvious.
 Suggest improvements that you can implement
and that are owned and signed up to by your
team .
 Having a facilitator with experience in the
process will make things easier; this includes
someone who knows about process, tools and
facilitation.
 Only take responsibility for actions over which
you have control: you should not agree an action
plan for something you can't implement.
Root cause analysis can help transform a reactive culture (one that reacts to problems) into a forward-looking culture (one that solves
problems before they occur or escalate). More importantly, RCA reduces the frequency of problems occurring over time within the
environment where the process is used.
Root Cause Analysis Techniques
 Five Whys Analysis
 Fishbone (Ishikawa) diagram
 Pareto chart
 Failure Mode and Effects Analysis (FMEA)
These techniques will be
covered in the coming
slides
 Five Whys Analysis
By repeatedly asking the question “Why” (five is a good rule of thumb), you can peel away
the layers of symptoms which can lead to the root cause of a problem.
A why-why is conducted to identify solutions to a problem that address it’s root
cause(s).Rather than taking actions that are merely band-aids, a why-why helps you
identify how to really prevent the issue from happening again.
The Five Whys approach to root cause analysis is often used
for investigations into equipment failure events and
workplace safety incidents. The apparent simplicity of the 5-
Whys leads people to use it, but its simplicity hides the
complexity in the methodology and people can
unintentionally apply it wrongly. They end up fixing
problems that did not cause the failure incident and miss the
problems that led to it. They work on the wrong things,
thinking that because they used the 5-Whys and the
questions were answered, they must have found the real root
cause.
You start with a statement of the situation and ask why it occurred. You then turn the answer to
the first question into a second Why question. The next answer becomes the third Why
question and so on. By refusing to be satisfied with each answer you increase the odds of
finding the underlying root cause of the event.
 Fishbone (Ishikawa) diagram
A fishbone diagram, also called a cause and effect diagram or Ishikawa diagram, is a visualization
tool for categorizing the potential causes of a problem in order to identify its root causes.
1. Create a head, which lists the problem or issue to be studied.
2. Create a backbone for the fish (straight line which leads to the head).
3. Identify at least four “causes” that contribute to the problem. Connect these causes with arrows
to the spine. These will create the first bones of the fish.
If this is difficult use generic headings:
 Methods
 Machines (equipment)
 People (manpower)
 Materials
 Measurement
 Environment
4. Brainstorm around each “cause” to document those things that contributed to the cause.
5. Continue breaking down each cause until the root causes have been identified.
Creating this diagram with a cross functional team will build not only trust between departments but will cultivate new found knowledge
and understanding for the key players in the process. When using the Fishbone as a discussion topic meetings can be better focused on
process improvement and defect reduction
 Pareto chart
When to Use a Pareto Chart.
 When analyzing data about the frequency of problems or causes
in a process.
 When there are many problems or causes and you want to focus
on the most significant.
 When analyzing broad causes by looking at their specific
components.
The Pareto chart provides a graphic depiction of the Pareto principle, a theory
maintaining that 80% of the output/effects in a given situation or system is produced
by 20% of the input/causes.
It is a vertical bar graph in which values are plotted in
decreasing order of relative frequency from left to right.
When to Use FMEA
 Failure Mode and Effects Analysis (FMEA)
It is a step-by-step approach for identifying all possible failures in a design, a manufacturing or
assembly process, or a product or service.
Failures are prioritized according to :
 how serious their consequences are
 how frequently they occur
 how easily they can be detected
The purpose of the FMEA is to take actions to
eliminate or reduce failures, starting with the
highest-priority ones.
If effectively used throughout the product life cycle, FMEA will result in significant improvements to
reliability, safety, quality, delivery, and cost.
 When a process, product or service is being designed or redesigned.
 When an existing process, product or service is being applied in a new way.
 Before developing control plans for a new or modified process.
 When improvement goals are planned for an existing process, product or service.
 When analyzing failures of an existing process, product or service.
 Periodically throughout the life of the process, product or service
FMEA
Process
FMEA
System
FMEA
Design
FMEA
Three Most Common Types of FMEAs
Process FMEA : The Focus is on
manufacturing related
deficiencies, with emphasis on :
Improving the manufacturing
process
 ensuring the product is built
to design requirements in a
safe manner, with minimal
downtime, scrap and rework.
manufacturing and assembly
operations, shipping,
incoming parts, transporting
of materials, storage,
conveyors, tool maintenance,
and labeling.
Design FMEA : The Focus is on
product design-related
deficiencies, with emphasis on :
improving the design
ensuring product operation is
safe and reliable during the
useful life of the equipment.
interfaces between adjacent
components.
System FMEA : The focus is on
system-related deficiencies,
including :
system safety and system
integration
interfaces between subsystems
or with other systems
interactions between
subsystems or with the
surrounding environment
single-point failures (where a
single component failure can
result in complete failure of
the entire system)
FMEA Procedure
The FMEA process results
in the assignment of risk
priority numbers (RPNs)
(to each potential failure).
Target failures with the
highest RPNs for
improvement.
FMEA LIMITATIONS
• Identifying failure modes is a team brainstorming activity. If the team forgets to list it, an important failure
mode could be left alone, waiting to occur.
• Time Consuming : It takes time to get into the details.
• Taking on an entire process may be a daunting task . Break a large process down into manageable chunks.
• Many FMEAs focus only on the customer requirements (specifications). Sometimes internal productivity losses,
equipment damage, scrap, and rework have very severe effects on the company
• Teams often have root causes as failure modes. A failure mode is the failure to perform the intended function.
RPN = Severity rating X Occurrence
rating X Detection rating
The RPN can range from a low of 1 to a
high of 1,000

Root Cause Analysis

  • 1.
  • 2.
    In medicine, it'seasy to understand the difference between treating the symptoms and curing the condition. A broken wrist, for example, really hurts! But painkillers will only take away the symptoms; you'll need a different treatment to help your bones heal properly. But what do you do when you have a problem at work? Do you jump straight in and treat the symptoms, or do you stop to consider whether there's actually a deeper problem that needs your attention? If you only fix the symptoms – what you see on the surface – the problem will almost certainly return, and need fixing over, and over again. However, if you look deeper to figure out what's causing the problem, you can fix the underlying systems and processes so that it goes away for good. To Start With……………
  • 3.
    Index ■ What isRoot Cause Analysis(RCA) ■ Key Points to Take Care of ■ Approach ■ Root Cause Analysis Techniques ■ RCA Process in MM ■ Case Study
  • 4.
    Root Cause Analysis(RCA) Root Cause Analysis (RCA) is a popular and often-used technique that helps people answer the question of why the problem occurred in the first place. It seeks to identify the origin of a problem using a specific set of steps, with associated tools, to find the primary cause of the problem, so that you can:  Determine what happened.  Determine why it happened.  Figure out what to do to reduce the likelihood that it will happen again. An action in one area triggers an action in another, and another, and so on. By tracing back these actions, you can discover where the problem started and how it grew into the symptom you're now facing.
  • 5.
    Key Points toTake Care of : Most organizations mistakenly use the term “root cause” to identify one main cause. Focusing on a single cause can limit the solutions set, resulting in the exclusion of viable solutions. The root is the system of causes that reveals all of the different options for solutions.The result … multiple opportunities to mitigate risk and prevent problems. The root cause is “the evil at the bottom” that sets in motion the entire cause-and-effect chain causing the problem(s) An IT department determines a root cause for all significant IT incidents. When the root cause is a process, system or training issue a problem record is created. Problem records drive a robust problem management process that investigates, prioritizes and fixes problems. In this way, all fixable root causes are addressed in an ongoing process of improvement.
  • 6.
    Too many companiesuse generic buckets like human error and procedure not followed to classify an entire incident. These are low-resolution investigations that result in weak solutions A grocery store orders accidentally orders 1,000 bags of apples when they only require 100. The order was entered incorrectly and the supplier won't take them back. The store needs to aggressively discount and advertise to sell the apples at a loss. The issue is initially considered human error. A root cause analysis process discovers latent human error in ordering systems. For example, there is no validation or warning for usually large orders. Also, fonts on the system are abnormally small and difficult for some employees to read clearly. The root causes identified will depend on the way in which the problem or event is defined. Effective problem statements and event descriptions (as failures, for example) are helpful and usually required to ensure the execution of appropriate analyses.
  • 7.
    Approach Root Cause isnot a “rocket science” – anyone can do it.You probably do it on a day to day basis. RCA is simply the application of a series of well known, common sense techniques which can produce a systematic, quantified and documented approach to the identification, understanding and resolution of underlying causes. RCA gives the confidence that the problem can be solved by taking a structured approach - making sure that the problem never happens again. Practical guide to carrying out an RCA Tips for executing RCA :  It is important to select the right team for carrying out an RCA; members should have knowledge of the process and be able to help explore the why, what and how.  Don't jump in with solutions: the problem and solution may not be obvious.  Suggest improvements that you can implement and that are owned and signed up to by your team .  Having a facilitator with experience in the process will make things easier; this includes someone who knows about process, tools and facilitation.  Only take responsibility for actions over which you have control: you should not agree an action plan for something you can't implement.
  • 8.
    Root cause analysiscan help transform a reactive culture (one that reacts to problems) into a forward-looking culture (one that solves problems before they occur or escalate). More importantly, RCA reduces the frequency of problems occurring over time within the environment where the process is used. Root Cause Analysis Techniques  Five Whys Analysis  Fishbone (Ishikawa) diagram  Pareto chart  Failure Mode and Effects Analysis (FMEA) These techniques will be covered in the coming slides
  • 9.
     Five WhysAnalysis By repeatedly asking the question “Why” (five is a good rule of thumb), you can peel away the layers of symptoms which can lead to the root cause of a problem. A why-why is conducted to identify solutions to a problem that address it’s root cause(s).Rather than taking actions that are merely band-aids, a why-why helps you identify how to really prevent the issue from happening again. The Five Whys approach to root cause analysis is often used for investigations into equipment failure events and workplace safety incidents. The apparent simplicity of the 5- Whys leads people to use it, but its simplicity hides the complexity in the methodology and people can unintentionally apply it wrongly. They end up fixing problems that did not cause the failure incident and miss the problems that led to it. They work on the wrong things, thinking that because they used the 5-Whys and the questions were answered, they must have found the real root cause. You start with a statement of the situation and ask why it occurred. You then turn the answer to the first question into a second Why question. The next answer becomes the third Why question and so on. By refusing to be satisfied with each answer you increase the odds of finding the underlying root cause of the event.
  • 10.
     Fishbone (Ishikawa)diagram A fishbone diagram, also called a cause and effect diagram or Ishikawa diagram, is a visualization tool for categorizing the potential causes of a problem in order to identify its root causes. 1. Create a head, which lists the problem or issue to be studied. 2. Create a backbone for the fish (straight line which leads to the head). 3. Identify at least four “causes” that contribute to the problem. Connect these causes with arrows to the spine. These will create the first bones of the fish. If this is difficult use generic headings:  Methods  Machines (equipment)  People (manpower)  Materials  Measurement  Environment 4. Brainstorm around each “cause” to document those things that contributed to the cause. 5. Continue breaking down each cause until the root causes have been identified. Creating this diagram with a cross functional team will build not only trust between departments but will cultivate new found knowledge and understanding for the key players in the process. When using the Fishbone as a discussion topic meetings can be better focused on process improvement and defect reduction
  • 12.
     Pareto chart Whento Use a Pareto Chart.  When analyzing data about the frequency of problems or causes in a process.  When there are many problems or causes and you want to focus on the most significant.  When analyzing broad causes by looking at their specific components. The Pareto chart provides a graphic depiction of the Pareto principle, a theory maintaining that 80% of the output/effects in a given situation or system is produced by 20% of the input/causes. It is a vertical bar graph in which values are plotted in decreasing order of relative frequency from left to right.
  • 13.
    When to UseFMEA  Failure Mode and Effects Analysis (FMEA) It is a step-by-step approach for identifying all possible failures in a design, a manufacturing or assembly process, or a product or service. Failures are prioritized according to :  how serious their consequences are  how frequently they occur  how easily they can be detected The purpose of the FMEA is to take actions to eliminate or reduce failures, starting with the highest-priority ones. If effectively used throughout the product life cycle, FMEA will result in significant improvements to reliability, safety, quality, delivery, and cost.  When a process, product or service is being designed or redesigned.  When an existing process, product or service is being applied in a new way.  Before developing control plans for a new or modified process.  When improvement goals are planned for an existing process, product or service.  When analyzing failures of an existing process, product or service.  Periodically throughout the life of the process, product or service
  • 14.
    FMEA Process FMEA System FMEA Design FMEA Three Most CommonTypes of FMEAs Process FMEA : The Focus is on manufacturing related deficiencies, with emphasis on : Improving the manufacturing process  ensuring the product is built to design requirements in a safe manner, with minimal downtime, scrap and rework. manufacturing and assembly operations, shipping, incoming parts, transporting of materials, storage, conveyors, tool maintenance, and labeling.
  • 15.
    Design FMEA :The Focus is on product design-related deficiencies, with emphasis on : improving the design ensuring product operation is safe and reliable during the useful life of the equipment. interfaces between adjacent components. System FMEA : The focus is on system-related deficiencies, including : system safety and system integration interfaces between subsystems or with other systems interactions between subsystems or with the surrounding environment single-point failures (where a single component failure can result in complete failure of the entire system)
  • 16.
    FMEA Procedure The FMEAprocess results in the assignment of risk priority numbers (RPNs) (to each potential failure). Target failures with the highest RPNs for improvement. FMEA LIMITATIONS • Identifying failure modes is a team brainstorming activity. If the team forgets to list it, an important failure mode could be left alone, waiting to occur. • Time Consuming : It takes time to get into the details. • Taking on an entire process may be a daunting task . Break a large process down into manageable chunks. • Many FMEAs focus only on the customer requirements (specifications). Sometimes internal productivity losses, equipment damage, scrap, and rework have very severe effects on the company • Teams often have root causes as failure modes. A failure mode is the failure to perform the intended function. RPN = Severity rating X Occurrence rating X Detection rating The RPN can range from a low of 1 to a high of 1,000

Editor's Notes

  • #5 >But what do you do when you have a problem at work? Do you jump straight in and treat the symptoms, or do you stop to consider whether there's actually a deeper problem that needs your attention? If you only fix the symptoms – what you see on the surface – the problem will almost certainly return, and need fixing over, and over again. However, if you look deeper to figure out what's causing the problem, you can fix the underlying systems and processes so that it goes away for good. >You can apply RCA to almost any situation. Determining how far to go in your investigation requires good judgment and common sense. Theoretically, you could continue to trace root causes back to the Stone Age, but the effort would serve no useful purpose. Be careful to understand when you've found a significant cause that can, in fact, be changed.
  • #9 Search abt all the methods written in the slides
  • #11 Service Industries (The 4 Ps) Policies Procedures People Plant/Technology Manufacturing Industries (The 6 Ms) Machines Methods Materials Measurements Environment Manpower (People)
  • #13 The Pareto Principle is known by many different names, including: The Pareto Law, Pareto's Law, Pareto Theory, The 80-20 Rule (or 80/20 Rule, or 80:20 Rule, or 80 20 Rule), The 80-20 Principle, (or 80/20 Principle, or 80:20 Principle, or 80 20 Principle) Pareto's 80-20 Rule (and variations of this) The Principle of Imbalance, The Principle of Least Effort (a term coined by George Zipf in 1949 based on Pareto's theory), The Rule of the Vital Few (an interpretation developed by Joseph Juran in the field of quality management), and many other variations/combinations of these expressions.
  • #14 Failures are any errors or defects, especially ones that affect the customer, and can be potential or actual.