Even with the best systems, all processes experience problems at some stage. The key is establishing procedures that get to the bottom of the problem, understand the cause and eradicate it. Failing to do this effectively is most likely to result in repeating issues. The
Root Cause Analysis (RCA) process can be used to drill down into the heart of the problem getting to the actual cause.
Root Cause Analysis is best defined a process or set of tools that help with problem-solving. When following this process and unearthing the issue, applying a fix (or corrective action) can prevent reoccurrence.
Without a structured approach, we could be mistaken to think that the problem is solved. In reality, we may have just addressed part of the issue and not prevented reoccurrence. RCA helps us identify the key contributing factor(s) behind the problem once and for all.
Why is Root cause analysis important
Problems and issues generally result in cost and time. In Lean manufacturing terms, this is often described as waste. If problems are allowed to carry on then companies will be losing money and adding time on transactions. This could be in a variety of formats from reworking items to the physical scrapping of non-conforming components.
Whilst RCA is often talked about in terms of lean manufacturing it is merely a set of tools that can be deployed in any problem area.
Performing root cause analysis
There a variety of tools that can be used with RCA. It’s important to understand that whilst the term RCA implies an individual root cause there may, in fact, be several.
These are the common steps and tools that are used:
1/ Define the team that will assess the problem
It might seem obvious but at least one individual will be required to conduct the RCA. Often this ends up being a cross-functional team who in combining their knowledge can then tackle the non-conformance.
2/ Define the problem statement
Prior to any RCA being undertaken the problem needs to be understood. There is usually an array of information that is associated with the issue which will need to be collated. The problem may require data to help describe it effectively. Defining the problem statement is usually best addressed by asking the team a series of questions for example:
· What should’ve happened
· What did happen
· What is the consequence of the issue
· How important is the problem
· Are the team members equipped with the authority to fix the problem?
· Etc.
Gaining background information can help significantly in understanding the issue.
3/ Agree which tool should be used.
RCA brings with it various tools that can be used. Different tools will be suitable for different problems and it’s important to utilize the one most suitable.
Some common RCA tools are:
Failure Modes and Effects Analysis (FMEA)
This is a process that looks to identify possible process failures through a systematic review. A failure mode is used to define a particular area or areas where something might fail. An established FMEA is useful to review to check if particular problem areas have been identified. Where it hasn’t the team can use the method of reviewing the process and likely process node to evaluate and identify the likely cause of the issue.
5 Whys
The 5 Why is a methodology that simply asks “why” sufficient times to break down the problem and get to the root cause. While it’s called the 5 Why’s the question may be asked as many times as required until the RC is discovered. Each answer to Why may uncover process failures which may require addressing.
Ishikawa Diagram/Fishbone Diagram
This tool (often termed the Fishbone Diagram as it resembles a fish skeleton) utilizes the 6M method (manpower, machinery, materials, methods, measurement, and mother-nature) where each area is reviewed to understand whether it has contributed to the problem.
Ishikawa can be a highly effective brainstorming tool which can be used to build up a series of potential issues and then prioritize them in terms of their likely contribution.
4/ Understand the root cause
Once the appropriate tool has been selected the team should use it to evaluate the root cause.
5/ Fix
Once the root cause has been established the team must then go on to identify the containment actions and long-term remedy. Like the root cause, any corrective actions must be clearly defined with appropriate owners (who are empowered to deploy he agreed change).
6 Verify
It’s important that when any corrective action has been deployed the process can then be verified to confirm if the issue has been resolved and actions taken have been effective.
I hope you found this article useful. Got tips and tricks to share on Root cause Analysis? We’d love your feedback below.
Finally, be sure to check out our Problem Solving Guide, it’s full of great tools, techniques and methods.