Processes, procedures and requirements

Yes, Plan-Do-Check-Act... That I agree with, however, how do you distinguish between "Correction" and "Corrective action"?

If I do some planned process and a defined parameter isn’t met, I can correct it. If I do a process and a parameter is not met and the output results and causes failure (I’m speaking in very broad terms here), I might elect to take corrective action (determine cause) based on the degree of risk (impact to $$, timing and/or customer/reg requirement).

 

Thanks for sharing! I'm not sure how this comment fits in to adult discussion.

If you'd care to take a look at at ISO 9001, non-conformance correction has always been an option - specifically for non-conforming product. Corrective action is clearly and distinctly different. Anyone who conflates correcting non-conformance with corrective action is making a big mistake, IMHO.

 

I know we all get excited about CAPA discussions and such.

Let's remain civil here and not get to much on the personal attack mode. Eh?

 

Sometimes I wonder if we talk more about Correction, Corrective Action, Preventive Action that actually doing it.

My definitions:

Correction- something is wrong, incorrect, out of tolerance. That wrong thing needs to be fixed.

Corrective Action: Enacting activity to prevent the same failure that had to be corrected.

Preventive Action: Action to avoid similar failures in the future.

I think my suggestion would be for each organization to define what the terms means. Then (and much more important) the company dedicate its time and effort into actually studying failures to really understand what failed and why. Once that is done, the actions to correct and prevent become much more apparent.

 

I'd disagree - as a dog owner, of a 90 lb Golden Retriever who liked to run (after deer mainly).

Preventive action is: I know (because when he saw deer in the back yard he got really, really excited) he's going to run after them if I open the door and am not paying attention, hence I am going to need to do something to restrain him or remove his seeing the deer. I can't control the deer coming in the yard, I may not be able to restrain him if he's seen them and committed to running after them (even if he wears a collar, a 90 lb dog takes some stopping) so, I installed a way to stop him seeing the deer out of the one window (at his eye line. (Potential) problem avoided...

 

In my previous manufacturing world, we did define (and document to the best of our ability) the difference between a correction and corrective action.

To your point of short-term versus long-term actions, our corrective action process included taking action to contain/mitigate the situation before delving into root cause determination and action planning. For example (and by now means an all-encompassing situation):

Situation: During the loading of product onto a flat-bed trailer, the stacked product spilled off of the flat-bed and onto the live warehouse laneway.
Correction: Immediately stopped all loading activities and blocked truck traffic into the warehouse.
Corrective Action - Root Cause: [insert root cause(s) here]
Corrective Action - Action Plan: [insert activities here]
etc.

However, we also had a matrix - which we reviewed and updated on an annual basis - that outlined many (I will not say 'all') scenarios where a correction was sufficient (i.e., corrective action not required). We recognized that non-conforming product and process was worthy of being a data point in our analysis, however, it was not feasible, practical, or sustainable to analyze every non-conformance.

While it has been a while since I was involved in this process, so I may not have all the details you would appreciate, yet hopefully the gist is here:

Customer complaints
Correction only - (1) Complaint value < $x, (2) Complaint frequency < x complaints with same customer+product combination within a certain timeframe
Corrective action - (2) Complaint value > $y, (3) Complaint frequency > x complaints with same customer+product combination within a certain timeframe

Unscheduled downtime
Correction only - (1) Unscheduled downtime < x minutes for all product except Product A
Corrective action - (1) Any unscheduled downtime, regardless of duration, if Product A is being manufactured, (2) Unscheduled downtime > x minutes for all product

Internal audits
Correction only - (1) Low risk internal audit findings including, but not limited to, typos, grammar mistakes, formatting
Corrective action - (1) A finding that directly relates to a requirement documented within the audit scope (i.e., standard or business management system), (2) A recurring/systemic situation adversely impacting the ability to meet requirements

On an annual (at a minimum) basis, we would review data points to determine if our correction/corrective action trigger points needed to be shifted ensuring effective use of our resources while keeping our focus on higher risk/impact scenarios.

 

Andy... the problem is.... I agree with your take too. That's the challenge we face with standards throwing out these terms as a requirement, without clear definitions.

I personally think your definition and mine are equally valid. That's why we need to spell out what we're calling Preventive Action in our organizations.

If your dog happens to catch a deer (which is close to impossible) I'll split processing costs with you for chili, sausage, backstrap, and some jerky.

 

Yeah he tried a few times! Don't let the demur, handsome good looks fool you! This boy had killer instincts!

 

Exactly so...

 

Amen, brother Fraser...

 

Ground hog’s day.
Words have meaning, context matters and the standard has been as clear as possible as to the operational definitions.
People who try to debate it are just contract lawyers who want to pick fights about anything and everything.

 

Well that’s why ISO eliminated Preventive Actions and went to Risk based thinking in the latest version

 

Hopefully it was also based on a) common sense and b) an overwhelming amount of feedback which stated (in basic terms) "Whatchoo talkin' 'bout, Willis?"

Preventive actions aren't "procedure" related, they are part of planning to mitigate issues. I believe that part of the problem is that we've become so used to being told (especially by regulatory agencies and major customers) that when corrective action is required to "make sure it can't also happen to other products/processes/suppliers/activities etc. that people have trouble differentiating. We know that in some industries, "CAPA" is commonly referenced. For those of us in the quality profession we need to be come advocates for effective PLANNING = preventive actions...