Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo Especially for content not in the forum
Such as files in the Cove "Members" Directory

New CAPA Work Flow with Revised 8D Approach

greenlantern

Starting to get Involved
#1
As much as I like the 8D process the lack of effectivity check when applying it to CAPA needed a workaround. Typically there is just a verification check after implementation of corrective action during the 8D process.

However, coming from medical device background, I started panicking when I didn't see effectivity check after preventive action. I guess repeated FDA audits focusing on ineffective CAPAs will drill it into you. So I added an additional step 7b for verifying the preventive action actually worked. In my experience, the CAPA plan includes a specified period of time after the preventive action is implemented to revisit the CAPA and gather quantified evidence of it's effectiveness.

This is for a CAPA SOP at a start up I work at. Please let me know if you have any feedback. Thanks!
 

Attachments

John Predmore

Quite Involved in Discussions
#2
I moved from medical device to aerospace manufacturing. I also noticed the traditional 8-D sequence did not include an effectiveness check, and I considered that a weakness. So I modified the traditional 8-D template to include an effectiveness plan (which is created by the project leader before the conclusion of the correction phase). The effectiveness plan includes who, what, when, and how many should be reviewed at a future point in time. After the effectiveness verification is complete, the wording of the plan segment is reworded to past tense to state what was actually done, and the 8-D is then formally closed.
 

Marc

Captain Nice
Staff member
Admin
#3
Last edited:

Jim Wynne

Staff member
Admin
#4
As much as I like the 8D process the lack of effectivity check when applying it to CAPA needed a workaround. Typically there is just a verification check after implementation of corrective action during the 8D process.
In my experience 8D is a clumsy and ill-fitting strategy that should be used only when required by a customer, and then it should be used to report your internal activities rather than guide them. It's far too easy to conflate the container (the 8D form) with the thing contained (the actual remedial activities). The tail wags the dog. I see a number of issues with your flowchart that indicate that you might have fallen victim to the format.

  • If a flowchart is to be useful, it should depict an ordered sequence of events, and especially a mandatory sequence. In real life, a CA process has actions and events that happen concurrently rather than in stepwise fashion. Your D3, "Containment actions," should normally be done as soon as you become aware of the problem, for example, and certainly not after a team is assembled.
  • I see no distinction being made between correction and corrective action.
  • In the ISO 9001 world, actions taken to prevent a recurrence of a problem shouldn't be described as "preventive." That term is normally reserved for instances where prevention is done before a nonconformity has a chance to occur. Addition of a step to the traditional 8D format for this purpose seems superfluous; preventing the NC from happening again is a normal part of the CA process, not a separate step.
  • The CA process should, by definition, include verification of effectiveness of the actions taken, thus you are adding a redundant step to the process.
 
Last edited:

Bev D

Heretical Statistician
Staff member
Super Moderator
#5
Jim and I mostly agree - although the way we've implemented internally it isn't so clumsy. his comment regarding the container vs. the contained is spot on.

regarding assessing the effectiveness: there should never be a prescribed time frame for ensuring effectiveness. Two critical factors that influence the proper time to assess effectiveness are: the natural time to failure and the reporting frequency and level of detail of field performance. My organization is lucky enough to have comprehensive data of product performance directly via internet reporting from our products. No tall products have this but the great majority do. So to check effectiveness it's a simple matter of watching the control chart for that failure mode. We stipulate that this monitoring must be actively done for at least a year after the solution is implemented. Of course ineffective solutions can be seen as soon as they would naturally occur. There are some products that and failures that must rely on Customer self reporting (we are the final product supplier so the user is our customer). This is notoriously difficult to deal with, so we usually have to be more mindful on how and how often we monitor performance. each situation will be different and arbitrary 'one size fits all' time frames and methods are counterproductive.

attached for those who might be curious is our 8D framework. As Jim stated the steps are only in rough sequential order but there is a lot of fluidity and flexibility on the order of the steps depending on the nature of the Problem
 

Attachments

greenlantern

Starting to get Involved
#6
In my experience 8D is a clumsy and ill-fitting strategy that should be used only when required by a customer, and then it should be used to report your internal activities rather than guide them. It's far too easy to conflate the container (the 8D form) with the thing contained (the actual remedial activities). The tail wags the dog. I see a number of issues with your flowchart that indicate that you might have fallen victim to the format.

  • If a flowchart is to be useful, it should depict an ordered sequence of events, and especially a mandatory sequence. In real life, a CA process has actions and events that happen concurrently rather than in stepwise fashion. Your D3, "Containment actions," should normally be done as soon as you become aware of the problem, for example, and certainly not after a team is assembled.
  • I see no distinction being made between correction and corrective action.
  • In the ISO 9001 world, actions taken to prevent a recurrence of a problem shouldn't be described as "preventive." That term is normally reserved for instances where prevention is done before a nonconformity has a chance to occur. Addition of a step to the traditional 8D format for this purpose seems superfluous; preventing the NC from happening again is a normal part of the CA process, not a separate step.
  • The CA process should, by definition, include verification of effectiveness of the actions taken, thus you are adding a redundant step to the process.
Thanks for your feedback Jim.

To your first point, I agree that a lot of these things should happen concurrently however in our current org structure and ERP system it isn't possible to perform any containment actions without involving quality assurance and supply chain at the minimum to meet and discuss the issue and perform an appropriate containment action so I consider this forming the team even if it is not formalized immediately.

Good point regarding correction vs corrective action.

As far as the term preventive being used in ISO, I'd argue it's used in both contexts. 0.3.3 states, "...carrying out preventive action to eliminate potential nonconformities, analysing any nonconformities that do occur, and taking action to prevent recurrence that is appropriate for the effects of the nonconformity."

For your last point, the extra step was only to emphasize that there is a verification step after PA. The point is that 8D explicitly states there is verification after CA but there is no mention of verification after PA. While it definitely should be a part of the PA process in practice, the traditional 8D outline doesn't include it explicitly so I wanted it to be blatantly obvious to people outside of QA. It's more of an elaboration than any change to the actual process.
 
Last edited:

greenlantern

Starting to get Involved
#7
Jim and I mostly agree - although the way we've implemented internally it isn't so clumsy. his comment regarding the container vs. the contained is spot on.

regarding assessing the effectiveness: there should never be a prescribed time frame for ensuring effectiveness. Two critical factors that influence the proper time to assess effectiveness are: the natural time to failure and the reporting frequency and level of detail of field performance. My organization is lucky enough to have comprehensive data of product performance directly via internet reporting from our products. No tall products have this but the great majority do. So to check effectiveness it's a simple matter of watching the control chart for that failure mode. We stipulate that this monitoring must be actively done for at least a year after the solution is implemented. Of course ineffective solutions can be seen as soon as they would naturally occur. There are some products that and failures that must rely on Customer self reporting (we are the final product supplier so the user is our customer). This is notoriously difficult to deal with, so we usually have to be more mindful on how and how often we monitor performance. each situation will be different and arbitrary 'one size fits all' time frames and methods are counterproductive.

attached for those who might be curious is our 8D framework. As Jim stated the steps are only in rough sequential order but there is a lot of fluidity and flexibility on the order of the steps depending on the nature of the Problem
Hi Bev,

Thanks for you thoughts on this.

In one of my past jobs they had the 'one-size-fits-all' so I must have learned bad habits on that.

So given those two factors, what is their relationship to the effectivity check period? I'm assuming the higher frequency reporting and shorter time to failure correlate to a shorter time frame for the effectivity check, right?

Is there any way to come up with an objective time frame?
 

Bev D

Heretical Statistician
Staff member
Super Moderator
#8
So given those two factors, what is their relationship to the effectivity check period? I'm assuming the higher frequency reporting and shorter time to failure correlate to a shorter time frame for the effectivity check, right?

Is there any way to come up with an objective time frame?
yes the reporting frequency and time to failure correlate to how long you need to monitor the success of the solution after implementation.
the 'objective time frame is a result of understanding the reporting frequency (what is possible) and the time to failure. It is also guided by adverse consequences that might occur (hence why we actively monitor for at least a year). There is no formula - it is dependent on each situation...you must think about it.

I would also bring you back to thinking about the the CA and PA thing. While the term prevent and preventive are used in ISO - they are used with very different meaning. Corrective Action is not the same thing as Preventive action (this is why the term CAPA is so irritating because there is no such thing). true preventive action is for a problem that has not yet occurred. the tools for this are very different than those used for Corrective Action on an occurring problem. 8D is not appropriate for true preventive action. FMEA and the like is used for true preventive action.
 

Jim Wynne

Staff member
Admin
#9
Thanks for your feedback Jim.

To your first point, I agree that a lot of these things should happen concurrently however in our current org structure and ERP system it isn't possible to perform any containment actions without involving quality assurance and supply chain at the minimum to meet and discuss the issue and perform an appropriate containment action so I consider this forming the team even if it is not formalized immediately.
Here we have a classic example of the tail wagging the dog. This is not a criticism of you or your ideas, it's a general observation on one of the reasons that things get too complicated and take too long to accomplish. When smart people are forced into dumb systems, nothing good can come of it. I've been in this position, and I know that trying to use simple logic and sound reasoning when "the system" mitigates strongly against it can be very frustrating.
 
#10
I think very highly of 8D and the related Effective Problem Solving, CQI-20, from AIAG. It is difficult to envision any problem that cannot be attacked with either process, and this includes all forms of waste or muda as opposed to just poor quality. My perception is that they are easier to understand than Six Sigma DMAIC and can be used on a much wider range of problems. Chris Visser's book on 8D is very good (I can recommend it from personal experience) as is CQI-20. I would recommend adding the following to the flowsheet in terms of initiating CAPA:

Stakeholder-initiated CAPA regarding:
(1) potential poor quality (error cause removal per Halpin, Zero Defects (1966))
(2) waste or muda
(3) occupational health and safety, which supports ISO 45001's clauses on employee involvement

That is, any stakeholder can initiate CAPA for a potential source of poor quality, any waste or muda, or a safety near miss issue (hiyari hatto = experience of almost accident situation).

My perception of correction vs. prevention is simply that correction removes a root cause after it has caused trouble, and prevention removes it before it causes trouble (so there is no need to consider both preventive and corrective action--if the action is in response to poor quality, an audit finding, or a safety incident, it's correction, and if it is proactive, it is prevention). Example; a worker is injured by machinery, and a guard is installed to make this accident impossible in the future = corrective action. A worker sees how he or she could have put a hand into the machinery and files a near miss report, and a guard is installed to make it impossible = preventive action.

What is important is that the action taken suppresses, disables, or removes the root cause, and this needs to be ensured because inadequate CAPA is responsible for the greatest portion of ISO 9001 and IATF 16949 audit findings. In addition, the lessons learned must be deployed to related processes (read across/replicate process or, as stated by Henry Ford, "the benefit of our experience cannot be thrown away.") In the example cited above, we would then look for other machines with exposed moving parts to ensure that guards are installed for them as well.
 
Top Bottom