Various techniques of analyzing the problem/issues and finding the correct solution

1. Ankur Chaturvedi
Root Cause Analysis

2. 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……………

3. Index
■ What is Root 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 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.

6. 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.

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

8. 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

9.  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.

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

13. 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

14. 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.

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