RCA

Root Cause Analysis

Introduction to Root Cause Analysis (RCA)

RCA – Eventually, all manufacturing processes will experience problems with non-conforming parts, equipment failure resulting in lost productivity or rework expenses, and possible increased scrap. Even with the best quality systems, training, and Statistical Process Control (SPC), problems can happen. What must be prevented are the repeat problems. The problems you thought were resolved only to reoccur. Repeat problems can be experienced in everyday life. If you compare a manufacturing process to a garden, the process problem would be the weeds in the garden. If you pull up a dandelion and don’t get the entire root it will just keep popping back up. It is much the same with manufacturing problems – if you don’t get to the root cause of the problem, it is eventually (if not frequently) going to re-occur. The goal of a Root Cause Analysis (RCA) is to get down to the true cause of the problem, the root cause.

What is Root Cause Analysis (RCA)

Root Cause Analysis (RCA) is a comprehensive term encompassing a collection of problem solving methods used to identify the real cause of a non-conformance or quality problem.  Root Cause Analysis is the process of defining, understanding and solving a problem. The root cause has also been described as an underlying or fundamental cause of a non-conformance, defect or failure. Furthermore, the term “root cause” can also be referred to as the precise point in the causal chain where applying a corrective action or intervention would prevent the non-conformance from occurring.

Why Perform Root Cause Analysis (RCA)

Repeat problems are a source of waste in manufacturing. Waste in the form of machine downtime, product rework, increased scrap and the time and resources spent “fixing” the problem. Many times we may believe that the problem is resolved but in reality we have just addressed a symptom of the problem and not the actual root cause. Correctly performed, a Root Cause Analysis can identify breakdowns in your processes or systems that contributed to the non-conformance and determine how to prevent it from happening again. An RCA is performed to identify what happened, why it happened and then determine what improvements or changes are required. Through the proper application of RCA, repeat problems can be eliminated.

RCA methods and tools are not limited to manufacturing process problems only. Many industries are applying RCA methodology in various situations and are using this structured approach to problem solving. Some examples of where RCA is being used include, but are not limited to:

• Office Processes and Procedures
• Quality Control Problems
• Healthcare Incident Analysis
• Safety-based Situations or Accident Analysis
• Failure Analysis in Engineering and Maintenance
• Change Management or Continuous Improvement Activities
• Computer Systems or Software Analysis

The point is that RCA can be applied to almost any type of problem that companies face every day. Another example where RCA could be used is for a company that is experiencing a high level of incorrect customer orders and shipments. The process can be mapped, analyzed and the root cause (s) of the problems can be identified and resolved. The end result is a happy, loyal customer-base and lower overall cost to the company.

How to Perform Root Cause Analysis (RCA)

Root Cause Analysis (RCA) is usually a step in a larger problem solving exercise. There are multiple tools that may be used during a Root Cause Analysis. Some of them can sometimes be completed by one person, but in most cases a Cross Functional Team (CFT) approach will reap the greatest benefits and increase chances of reaching the true “root cause”.

There are also several problem-solving methods that use Root Cause Analysis within their problem-solving process, such as Eight Disciplines of Problem Solving (8D), Six Sigma / DMAIC, or Kaizen. The RCA is a critical step in each of these examples.

The Problem

Before RCA can be performed, the problem must be well defined. The following information must be determined and documented:

• Who discovered the problem?
• What exactly happened?
• Where in the process was the problem discovered?
• When was the problem discovered?
• How many / How often does it happen?
• How was the problem detected?

Next, the team may want to collect data or other additional information. It may also be necessary to initiate interim containment or corrective actions. The team should review all gathered information and further define the problem. The problem should be defined based on facts and data. Once the problem is fully described the team can then begin the Root Cause Analysis phase.

The Team

The Team should be comprised of personnel that have direct knowledge of the process being examined and responsibility for implementing any permanent corrective actions. In addition, the team should include representatives from Quality, Process Engineering and, when appropriate, team members from the next step in the process or from other shifts.  Each member of the CFT will bring their own knowledge and view of the process and the non-conformance.

The Tools

There are multiple tools that could be utilized during a Root Cause Analysis. This section will cover some of the tools including how and when they could be of value to the analysis. The first step is to determine what is included and what is not included in the problem investigation using the Is/Is Not analysis.

Is / Is Not

The “Is/Is Not” analysis may be used at different points in the RCA. It can be used while defining the problem to determine what is in scope and will be considered during the analysis and what is out of scope and will not be considered. It can also be used when planning a solution, to help the team decide what to include and what to exclude. The Is-Is Not analysis allows the team to think about the problem and the boundaries of what it is or is not.  The tool helps the team maintain their focus. If the boundary of the problem is not clearly defined the team may stray off the initial path and work on solving inconsequential problems.

Document what “Is” and “Is Not” part of or a characteristic of the problem. The process works by asking the team various questions such as:

• Who is impacted by this problem?
• Does the team have the authority to resolve this issue?
• What do we already know about the problem?
• Is this something that will impact the customer?
• Will we actually do something about this?

Ask the team enough questions until there is a clear definition of the problem / scope of the problem solving process.

Ishikawa Diagram

The Ishikawa or Fishbone Diagram is a useful tool in determining the most likely causes (MLCs) of a quality problem. The diagram is sometimes referred to as a Fishbone Diagram because it looks much like a skeleton of a fish with the effect or problem being listed in a box at the end. The main sections of the diagram are used to address the 6Ms (Man, Material, Method, Machine, Measurement and Mother Nature (Environment). The diagrams are usually worked right to left, with each large “bone” of the fish branching out to include smaller bones with additional details. It is important not to limit the teams brainstorming ideas here. If an idea is in a different section of the diagram, simply list it in the appropriate section and then go back to it later. Once the team has brainstormed all the possible causes of the problem, the team should rate the potential causes according to their level of importance and likelihood of contributing to the failure and develop a hierarchy. From the hierarchy the team should select which causes to further investigate.

5 Whys

The 5 Why method is simply asking the question “Why” enough times until you get through all the symptoms of a problem and down to the root cause. The 5 Whys is often used during the problem solving activities. It is also used in coordination with other analysis tools, such as the Cause and Effect Diagram, but can also be used as a standalone tool. The 5 Whys is most effective when the answers come from people who have hands-on experience of the issue being examined. To discover the root cause of a problem, keep asking “why”. By repeating “why”, you can drive down to the root cause of the problem. A general rule of thumb is that you should reach the 3rd to 5th “why”, or you may just address a symptom of the problem and not the actual root cause. The 5 Why Form can sometimes have three separate areas (or “legs”) to address the 5 Whys: Why it occurred, Why it was not detected, and Why our systems failed. Each area should be explored and you may have more than one causal progression for each area.

FMEA

Failure Modes and Effects Analysis (FMEA) is a well-defined tool that can identify various modes of failure within a system or process. In many companies, if a major problem is detected in the process or product, the team is required to review any existing FMEAs about the problem. The team should determine if the problem or effect of the failure was identified in the FMEA and if it was, how accurately the team evaluated the risk. If the problem is not included in the FMEA, the team should add any known information and then complete the following steps:

• List the current problem as a failure mode of the design or process
• Identify the impact of the failure by defining the severity of the problem or effect of failure
• List all probable causes and how many times they occur
• When reviewing a process FMEA, review the process flow or process diagram to help locate the root cause
• Next identify the Escape Point, which is the closest point in the process where the root cause could have been detected but was not
• Document any controls in place designed to prevent or detect the problem
• List any additional actions that could be implemented to prevent this problem from occurring again and assign an owner and a due date for each recommended action
• Carry any identified actions over to the counter-measure activity of the RCA

Action Plan

Once the team has determined the root cause using any combination of the tools listed above then they must develop the appropriate counter-measures or corrective actions. In addition, the team should develop an action plan for implementation of the counter-measures.

The counter-measures are usually divided into two categories:

1. Short-term or immediate counter-measures – generally accomplishable in less than 1 week. If not it should be designated as a “Long-term” counter-measure.
2. Long-term or permanent counter-measures – usually more complex and may require additional resources to complete. All “Long-term” counter-measures should be able to complete in less than 1 month. If not, they should be forwarded to the Continuous Improvement (CI) team for evaluation as part of a Kaizen or Black Belt project.

The corrective action must be clearly defined and achievable by the team member assigned to complete the task. The action plan should also contain expected due dates for each of the corrective actions. It is often discovered that corrective actions without an owner or an expected due date seldom get completed. Occasionally the counter-measures require tasks to be completed by more than one of the team members simultaneously or in a certain order. The action plan should be used to track progress of individual action items required to complete implementation of the countermeasures.

Verification Plan

The team should also determine a Verification (or Validation) Plan. This is used to provide a documented performance appraisal of the counter-measures effectiveness. This could entail recording data or auditing any special controls developed and implemented during the RCA exercise. Evidence should be collected to verify the effectiveness of the counter-measures or corrective actions.  In addition, it is good practice to re-assemble the team approximately 30 days after the permanent counter-measures are in place. The team should review the effectiveness of the counter-measures and determine if the problem has occurred since implementation of the counter-measures. The team should also review the process (if applicable) to assure all counter-measures are being followed.

The development of a robust, well-planned Root Cause Analysis (RCA) process can be very valuable to the company by determining the root cause and taking action to prevent it from re-occurring. The lessons learned during an effective RCA can often be carried over to similar designs or processes. This should initiate a problem-solving continuous improvement mindset to spread throughout the company.