CAPA Chapter III – Root Cause Analysis of the CAPA System

Rami.Azulay October 1st, 2019 Posted by Rami Azulay( ) Requirements Management Tool

Introduction

Root Cause Analysis (RCA) is the heart and soul of the CAPA system. Without defining the root causes or cause of a problem, it would be nearly impossible to prevent from recurring. According to Wikipedia, root causes are the result of a causer chain where a sequence of events leads to problems. 

Also, there is a possibility that someone is responsible for introducing the error. Furthermore, there is the puzzle of why the error was not detected.

Root Cause Analysis

One of the easiest ways to carry out a root cause analysis is to reiterate that the problem is the root cause. Although, this is a terrible approach and will often not lead to the discovery of the root cause. For example, it is easy to simply blame documentation for a process gap. 

Likewise, one could easily blame specification for an error in an equipment part, while there is a possibility that other parts could have problems too. The truth is that there is never just one root cause, there are several.

Hence, the process of discovering the root cause or cause is both a science and an art. A lot of creative thinking goes into the process of identifying all likely possibilities for a root cause. Data plays a vital role in ensuring that you reach the right conclusions. When conducting RCA, it is a great idea to consider various perspectives.

The hardware team mostly believes that all problems stem from software and the software team thinks that the problem stems from hardware. Similarly, R&D and manufacturing trade blame. As a result, it is important that the management team take control of the situation and stick to the facts when investigating problems.

It is worth mentioning that one could argue that all problems are management problems. A good management team will avoid blame shaming and remove emotions from their decision making. By sticking to the facts, the management team will be able to get to the root cause.

The Toolbox for Root Cause Analysis

There are several toolboxes available to help determine root cause and there are several factors that would help decide on what toolbox is right for a specific problem. For example, a fault tree analysis will suit a technical problem issue, while a 5 why approach will work for a quality system problem.

A tool is only as useful as the person using it. A great tool can be misused in the wrong hands and vice versa. Therefore, when it comes to resolving issues in the CAPA system, it is best to go for skilled and experienced personnel rather than a recent hire. 

A quick search for an example of root cause analysis will often return the Jefferson Memorial Example. The park service investigates the root cause of why the memorial building was deteriorating.

The Jefferson Memorial Example

Similar to the time when Jefferson and his trumps had to defend American from British invasion, the park service is defending the building from destructive invaders. Apparently, the stones in the building were falling due to frequent washing.

The frequent washing was the result of excess bird dropping, and excess birds were attracted to the spider food source in the building. The spiders came to feed on the thousands of tiny insects in the vicinity. The tiny insects were drawn to the evening spotlight at the monument that coincides with the time the insect goes into a mating frenzy. 

As a solution, the parking service opted to delay the time of that they switch on the light to one hour after sunset. The result is the reduction in the number of insects by 90%, which in turns breaks the food chain that results in the frequent washing of the building.

The example above is a great example of ensuring that you have all the information relating to the problem before taking any action. In so doing, you will get to the root cause of a problem and then solve it.

The 5 Why Analysis Example for Root Cause Analysis

The “5 Why” model can be used to explain the building’s deterioration. Without further asking why the park service could have spotted at reducing the amount of washing after discovering that the washing is the cause of the deterioration. However, by reducing just the amount of washing, the memorial building will remain unsanitary due to the bird’s poo. 

The investigation going by asking why could have stopped at bird poo without further questions. But by continually asking why, the parking service was able to discover that the root cause was the light. By discovering the root cause, they were able to implement effective corrective action at a much lower cost.

The Result

After arriving at the root cause, it becomes obvious that implementing a solution at this point will yield the best result. For instance, by delaying the switching on of the light by one hour, what will be the result? There would be fewer insects, then less food, then fewer birds, and reduced washing. The example shows the chain effect of both the problem and the effect of the solution.

While the example above seems a bit straightforward, that is not always going to be the case. The “5 Why” analysis will require the skill and experience of a veteran in the CAPA system to help plot the path to the right conclusions. Having an electronic system such as Orcanos that includes the e-CAPA system is exactly that way to pass knowledge on to the next generation of people as well to collaborate the information across departments.

The Major Tripping Point of the CAPA system.

The RCA is often the point that problems in the CAPA system begin. It is easy to think that the problem is the cause or to assign blame to someone. While a person might be the reason for causing a problem, unless there is a maliciously intent, then you need to find the root cause. The practice of going for the easy solution or blame shaming isn’t acceptable.

In the Jefferson example, it is easy to find several points where the investigation could end before reaching the root cause. Also, always document the Root Cause Analysis process, else one can assume that there was never a problem. It is important to document your RCA process as it would help reviewers and auditors understand the steps that led to your conclusions.

Conclusion

Never reaching the root cause of a problem is the same as plugging a hole in a dam, when there are several linking points. Blaming people especially when there is no proof of malicious intent is frowned upon. Likewise, simply relying on tools to solve the problem is not enough. Tools just make the process of finding a solution easier, as the tool will require the skill and experience of a veteran to be effective.

Accept all inputs and opinions as it would enable you to gather all the facts and discover the root cause without bias. Lastly, don’t just settle on one cause keep investigating until you discover all root causes.


About the author, Rami Azulay

Rami has over 24 years of experience in various software development and QA roles. Using his extensive knowledge of operations and quality, Rami was a main architect of the Orcanos software back in 2005 and later became Orcanos VP sales & marketing. Rami holds an MSC degree in Computer Sciences.

Orcanos

Contact

8 Tozeret Ha'aretz Street
Tel Aviv, Israel
+972-3-5372561
info@orcanos.com

Copyright © Orcanos, All rights reserved. | Privacy policy | Terms of use