I have carried out close to 1500
days of third party certification audits. One of the shortcomings I have
noticed on the part of almost all auditees is their poor understanding about the
Corrective Actions for the Non Conformances raised. There has been many articles
about Root Cause Analysis (RCA) and Corrective Action (CA). But
there is hardly one which addresses on effective
corrective action.
The need for corrective action can arise from many different sources including internal audits, external audits, customer complaints and feed backs, employee complaints and suggestions, and the requirements of regulatory bodies. All these inputs to the corrective action process should be dealt with in a timely and effective manner.
Effective corrective action is that action which eliminates the actual/root cause of the problem, thereby eliminating the recurrence of the Non Conformity or Problem. All too often people responsible for providing corrective action responses focus on the incident itself, rather than the larger issue of what caused the incident to happen.
The first step in getting to an effective corrective action solution is to clearly understand what the problem is (or is not). Sometimes the statement of a nonconformity can be so vague or poorly stated, that it will quickly lose its meaning and perhaps lead to no meaningful action at all. A example of this would be “Documents are not controlled.” What documents? Where did you find these documents? Why do they need to be controlled? Is it in all areas, by all persons and all the time? This type of nonconformity statement will not result in any useful type of action being taken to correct the problem. Therefore the NCR must first be properly documented.
For a nonconformity report to be proper, effective and useful, it must have the following 3 parts:
Finding
– System Level deficiency.
Requirement
– Exactly requirement that is not fulfilled.
Evidence - Evidence that goes to prove that the requirement
is not fulfilled.
Finding, here,
is that part or element of the System that is found to be not in conformity
with the requirement.
Requirement is
the statement of actually repeating the exact requirement against or based on which audit is carried out - could
be a clause of a Standard, Policy or Procedural requirement of the organization,
a legal/customer or any other interested parties’ requirement and so on that
was not met. When the requirement is not directly attributable to the standard
then it is important to link the cited requirement to the standard.
Evidence is
actual incident/problem or the fact that was obtained during the audit, which
is the main activity of the audit. It should be factual giving reference to
what exactly happened, where it was noticed etc. The problem has to be at
System level ie. one off incidences, mistakes, miss outs that are normally
expected are not to be considered but
those that are happening all or most of the time or entire planning/determining/implementation
or area under audit is not meeting the requirement. This will take the
emphasis off of the incident, and focus on the System but at the same time provide
the auditee with an actual incident to investigate while performing RCA.
The following is a well-documented
nonconformity:
Finding:
Planning for product realization is not effective.
Requirement: Clause 7.1 of ISO 9001 requires “in planning product realization, the
organization shall determine …………………… c) required verification, validation, ……… activities specific to the product
and the criteria for product acceptance.”
Evidence: Acceptance criteria/ tolerance for PCB thickness of
1.6 mm is not specified in PD 1376 R01 for ETL Adaptor 7.2 V PCB.
Most organizations give CA
as PD 1376 will be revised by including tolerance for the thickness. This is
only containment of the particular incident of the system level problem. It is
just a correction and not CA. Correction must definitely be
done as part of the corrective action process. But, without finding out why this happened in the first place,
the problem is likely to be repeated. Addressing the nonconformity at the
system (or process) level will force the organization to investigate
further to determine how widespread the problem is and then address the larger
contributing factors to the problem. This is where good RCA is vital.
A number of tools are
available for carrying out RCA like Ishikawa Diagrams (Fishbone, Cause and
Effect), Pareto Analysis, 5 Why, Fault Tree Analysis (FTA), Interrelation
Diagrams, and many others. Perhaps
one of the easiest to implement is the ‘5 Why’ Method. Starting with the
incident, keep asking “Why did this happen?” until you arrive at the root
cause. Generally asking WHY 5 times takes one to the root of the cause. But it
is not mandatory. It is possible that the root cause is reached in just 3 WHYs
or sometimes it takes more than 5 times. I had come across a problem which took
16 WHYs to arrive at the root!! The following example may provide good clarity.
Tolerance for
PCB thickness is not included in PD 1376
Why? It is not documented by the Design.
Why? Design Review is not effective.
Why? Approver/Reviewer is careless
Scenario 1
Correction: PD 1376 will be reviewed and revised.
CA: Reviewer will be counseled. A system of random check of
drawings by HOD after approval of the drawing but before release will be
introduced. All documents will be reviewed for completeness in next 30 days.
Scenario 2
Tolerance for
PCB thickness is not included in PD 1376
Why? It is not documented by the Design.
Why? Review is not effective.
Why? Reviewer simply relied on the
person who prepared the drawing and approved without actually verifying the
drawing.
Correction: PD 1376 will be reviewed and revised.
CA: Reviewer will be counseled. A system of random check of
drawings by HOD after approval of the drawing but before release will be
introduced. All documents will be reviewed for completeness in next 30 days.
Competence of various personnel will be reviewed and revised if necessary.
Scenario 3
Tolerance for
PCB thickness is not included in PD 1376
Why? It is not documented by the Design.
Why? Review is not effective.
Why? Reviewer is not clear of his roles
& responsibilitiy
Correction: PD 1376 will be reviewed and revised.
CA: Reviewer will be given requisite awareness and made aware of
his roles & responsibilities. A system of random check of drawings by HOD
after approval of the drawing but before release will be introduced.
Scenario 4
Tolerance for
PCB thickness is not included in PD 1376
Why? It is not documented by the Design.
Why? Procedure for documenting
specification is not clear
Why? Rolls of persons Preparing and
person Reviewing are not clearly defined.
Correction: PD 1376 will be reviewed and revised.
CA: Procedure for Communication of Roles & responsibilities will
be reviewed and improved.
Scenario 5
Tolerance for
PCB thickness is not included in PD 1376
Why? It is not documented by the Design.
Why? It is from our sister org. Review
of documents from Sister companies are not carried out.
Why? Procedure for review of documents
do not cover documents from sister org.
Correction: PD 1376 will be got revised from sister
org.
CA: Procedure for Control of documents will be revised to
include review of ALL documents incl. that received from sister org. and others
outside the org.
The RCA has unearthed some
underlying issues that allowed the system to fail. Now we have some good
candidates for corrective actions to be taken. In this case the problem was not
merely product specification per se, but other processes that acts as an input determining
product specification. Pl note that there could be more than one possible root
cause and correspondingly different CA. One needs to choose one of the CA
depending on which of the causes is most likely to be the cause. Taking
action on the root/actual cause of the problem is likely to eliminate the
possibility of this problem reoccurring.
Now coming to the question of verification of effectiveness of CA taken, it would make sense to evaluate the results say by an audit. In some situations it might possibly take a quite a few months before a verification audit would be suitable to evaluate the effectiveness of the actions taken. For example, in the first case, one need wait for one month or till another new Product Specification is received/documented to see whether the Reviewer is being careful. If the problem has not recurred since the implementation of the corrective actions, then we can assume that the root cause has been correctly identified and eliminated. If however, there are similar problems found on verification audits, then there would be a need to go back to RCA and initiate CA based on the next most likely root cause.
In the second case Commitment
on the part of the reviewer rather than just the knowledge/awareness is
important. 3 rd Scenario, however, demands creating right awareness on the part
of the person about his role in reviewing while it is going back to a procedure(s)
and improving by bringing in clarity in the 4 th (communication procedure)
& 5 th cases (document review procedure)
For example in the above
case suppose there is repetition of this NC. It is then necessary to go back to
the RCA and select the second most likely cause RCA 2 and the corresponding CA
and so on. Or sometimes RCA has to be carried out all over again based
on the results.
A common problem with RCA
during the corrective action process is that many organizations will stop at
“Operator Error” if that is one of
the causes of a given problem. While in many cases the human factor may well
have contributed to the incident, there is likely that a system element has failed,
or was not in place, to avoid the problem. “Operator Error” as root cause usually
results in a brief meeting with the subject operator to remind him about how to
do the job. While this might work for some people for some of the time, it is
not likely to result in any sort of lasting protection from recurrence.
For example, an operator is producing left-hand and right-hand knobs on the same piece of equipment. The left-hand and right-hand knobs are to be placed in different shipping bins. The potential exists for the operator to mix parts, as there is no system to prevent it. In the event of a customer complaint about mixed parts, it is likely that the cause of the nonconformity would focus on “Operator Error,” leading to ineffective corrective actions that do not prevent recurrence. This situation lends itself to potential customer dissatisfaction and repeat problems with the same parts. The risk to the customer may be high and the cost of containment (on-site sorting, 100% or 200% inspection) would definitely make a strong argument for investing in some good RCA and effective corrective actions.
For example, an operator is producing left-hand and right-hand knobs on the same piece of equipment. The left-hand and right-hand knobs are to be placed in different shipping bins. The potential exists for the operator to mix parts, as there is no system to prevent it. In the event of a customer complaint about mixed parts, it is likely that the cause of the nonconformity would focus on “Operator Error,” leading to ineffective corrective actions that do not prevent recurrence. This situation lends itself to potential customer dissatisfaction and repeat problems with the same parts. The risk to the customer may be high and the cost of containment (on-site sorting, 100% or 200% inspection) would definitely make a strong argument for investing in some good RCA and effective corrective actions.
In the same example, 5 Why?
RCA might uncover that the Production Planning Group failed to implement any
sort of mistake-proofing to prevent mixed parts. A system for mistake-proofing
the operator’s process could probably be developed and implemented in timely
and cost-effective manner, thereby eliminating the root cause and providing the
operator with tools to perform the job correctly. Auditing of the planning and
production processes after implementation will determine the overall effectiveness
of the corrective actions taken. Is the mistake-proofing installed? Is the
operator using the mistake-proofing equipment correctly? Has subsequent
inspection revealed any escapes? Have customers had repeat complaints about
mixed parts? Are mistake-proofing concepts being applied to similar processes?
These and other such questions need to be verified for determining the
effectiveness of the CA taken.
The examples given above are
rather simplistic in nature. In actual practice some of the NCs may be quite
complex and require application of elaborate statistical techniques like FMEA,
Control Charts etc. in addition to the ones mentioned already.
In one instance the FMEA carried out for a manufacturer had over
13,800 process inputs - identified over 5,600 failure modes that came from just
20 root causes! For an Asset Management company the inputs were 9800 -
identified over 3,450 failure modes and 8 root causes. A root cause
investigation for a service failure using SPCO-FMEA tool revealed 400 process inputs
and identified 89 failure modes that came from just 2 root causes!!
The end result of utilizing sound root cause analysis practices should be effective corrective action. The end result of effective corrective action should be improved processes, and ultimately improved organisational performance/customer satisfaction. Regardless of the nonconformity’s source, organizations that only take action on the incidents are bound to repeat the same ineffective corrective actions over and over again. The purpose of this article was to present a common sense approach to implementing RCA and effective corrective action. All organizations will experience different problems with varying degrees of severity. But, by applying some good investigative tools and taking appropriate action of the causes of problems, repeat issues can become a thing of the past.
