I posted this (http://elsmar.com/Forums/showthread.php?p=221578#post221578) on another thread, because I really believe the TC 176 missed the boat (again). Since the 1994 Edition of ISO 9001 when an emphasis was added to the preventive action aspect of ISO 9001, countless discussions have ensued on corrective vs. preventive actions. Here, at the Cove, we have had prolonged discussions on the subject.

I like to poll the Cove membership to see if you agree that a re-wording of clause 8.5.3 should have been part of the ISO 9001:2008 amendment, which was supposed to clarify the existing requirements of the 3rd Edition of 9001. It is too late now for the TC 176 to do anything about this aspect of the Standard for next year's release (unless we see a miracle). But is it just me or do you agree that 8.5.3, the way is presently written, is very confusing and ambiguous?

Cast your vote, please.

I posted this (http://elsmar.com/Forums/showthread.php?p=221578#post221578) on another thread, because I really believe the TC 176 missed the boat (again). Since the 1994 Edition of ISO 9001 when an emphasis was added to the preventive action aspect of ISO 9001, countless discussions have ensued on corrective vs. preventive actions. Here, at the Cove, we have had prolonged discussions on the subject.

I like to poll the Cove membership to see if you agree that a re-wording of clause 8.5.3 should have been part of the ISO 9001:2008 amendment, which was supposed to clarify the existing requirements of the 3rd Edition of 9001. It is too late now for the TC 176 to do anything about this aspect of the Standard for next year's release (unless we see a miracle). But is it just me or do you agree that 8.5.3, the way is presently written, is very confusing and ambiguous?

To me, the corrective/preventive dichotomy has always been the most glaring weakness of the standard. It causes much unnecessary confusion. Anything done to prevent problems from happening is preventive, regardless of the reason(s) for taking the action in the first place. When there's a mandate in place already for continualous improvement, there's no need to create a separate category for preventive action.

I posted this (http://elsmar.com/Forums/showthread.php?p=221578#post221578) on another thread, because I really believe the TC 176 missed the boat (again). Since the 1994 Edition of ISO 9001 when an emphasis was added to the preventive action aspect of ISO 9001, countless discussions have ensued on corrective vs. preventive actions. Here, at the Cove, we have had prolonged discussions on the subject.

I like to poll the Cove membership to see if you agree that a re-wording of clause 8.5.3 should have been part of the ISO 9001:2008 amendment, which was supposed to clarify the existing requirements of the 3rd Edition of 9001. It is too late now for the TC 176 to do anything about this aspect of the Standard for next year's release (unless we see a miracle). But is it just me or do you agree that 8.5.3, the way is presently written, is very confusing and ambiguous?

Cast your vote, please.

I don't think that changing the wording would help companies that don't give a hoot about correcting/preventing problems. Smart companies do this already; they verify that their CA/PA actions work and that they are effective. In addition, any process within a quality management system that fails to deliver the expected results is ineffective; thus a nonconformity against ISO 9001:2000.

Stijloor.

I voted for the clarification. The paradox is this. To me, the wording is crystal clear. I read it to mean exactly what is says. However, because so many smart folks here on the Cove and elsewhere, interpret it differently, obviously it is not clear enough. If it is too late to get into the new standard, perhaps they could do an interpretation to help clarify their intent. The data (and arguments) speak for themselves.

I don't know what is exactly not clear about the Corrective Action & Prevention Action clauses in ISO 9001:2000. Anyone having doubts about the exact impretation of these clauses, should post his/her questions to ISO Technical Committee. They are in a better position to clarify any doubt you may have. As long as you are very clear on the definitions of Corrective and Preventive Action, and genuinely spend time to identified root causes and confirm them with facts, including actions for those potential causes which may happen already but may happen in future, and not simply fill up the CAPA form, I don't see you are going to face any problem with auditors.

I think the ISO TC did a good in coming out with guidlines to enhance the correct interpretations of various clauses when new ISO is launched.

Eric

I don't know what is exactly not clear about the Corrective Action & Prevention Action clauses in ISO 9001:2000. Anyone having doubts about the exact impretation of these clauses, should post his/her questions to ISO Technical Committee.We already established that the TC 176 makes mistakes. You are new to the Cove. You probably have not had the time to see 5% of the discussions concerning the subject. This one (http://elsmar.com/Forums/showthread.php?t=687) for example. If you are so sure of your position, do us a favor. Post 5 examples of clear preventive actions from your organization here, and let us dissect it. Just for the fun of it. :tg:

Why do we only get those 2 choices in the vote? How about this choice, "No. Becaue no one really cares about preventive action" or something similar? Why is this an either/or proposition? This or that, A or B?

Are we saying that if 8.5.3 in ISO 9001 is re-worded, then users will acutally value preventive action?

ISO 9001 is all about certification. If I get the certification, what do I care what any section of ISO 9001 states?

Why do we only get those 2 choices in the vote? How about this choice, "No. Becaue no one really cares about preventive action" or something similar? Why is this an either/or proposition? This or that, A or B?

Are we saying that if 8.5.3 in ISO 9001 is re-worded, then users will acutally value preventive action?

ISO 9001 is all about certification. If I get the certification, what do I care what any section of ISO 9001 states?


Gee, Mr. van P, I hope you are only being facetious? ISO is all about certification? That is the last point of value. It is a program that can induce much improvement and benefit, when done right.

Why do we only get those 2 choices in the vote? How about this choice, "No. Becaue no one really cares about preventive action" or something similar? Why is this an either/or proposition? This or that, A or B?

Are we saying that if 8.5.3 in ISO 9001 is re-worded, then users will acutally value preventive action?

ISO 9001 is all about certification. If I get the certification, what do I care what any section of ISO 9001 states?


Gee, Mr. van P, I hope you are only being facetious? "ISO is all about certification?" That is the lowest point of value from ISO. The program can induce much improvement and benefit, when done right. Even ISO 14001 regularly saves my clients $30,000-50,000, based on their numbers.

[FONT="Arial"]Since the topic is about preventive actions...our ISO/TS16949 auditor was not satisfied with our FMEA process and were looking for other alternatives to implement preventive action processes. Does anyone have suggestions?:rolleyes:

[font="Arial"]Since the topic is about preventive actions...our ISO/TS16949 auditor was not satisfied with our FMEA process and were looking for other alternatives to implement preventive action processes. Does anyone have suggestions?:rolleyes:


The FMEA is discussed in cl 7.3.3.1 and 7.3.3.2. Preventive Action section is cl 8.5.3. Preventive Maintenance is cl 7.5.1.4.

While FMEAs and PMs are preventive, doesn't it seem logical that the standard is looking for something else for cl 8.5.3? Otherwise, why would they have made another section? If it wanted these same things, they had already covered it.

The definition for corrective and preventive actions is almost identical. The steps that MUST be addressed in 8.5.3 are identical to the steps for corrective action. Why can't we just accept it the way theywrote it? That a preventive action is like a corrective action, but done proactively, while problems are still potential?

In a word, a preventive action is a corrective action done ahead of time, before the failure occurs. FMEAs are like that too, but they are done before the product launch. FMEAs are superior to preventive action, because it is still in the development stage. After launch, we do corrective and preventive actions.

In a word, a preventive action is a corrective action done ahead of time, before the failure occurs. FMEAs are like that too, but they are done before the product launch. FMEAs are superior to preventive action, because it is still in the development stage. After launch, we do corrective and preventive actions.

FMEAs should be live documents, then they are effective tools for preventive action, before and after lunch:D

In a word, a preventive action is a corrective action done ahead of time, before the failure occurs. FMEAs are like that too, but they are done before the product launch. FMEAs are superior to preventive action, because it is still in the development stage. After launch, we do corrective and preventive actions.

I think this paragraph provides ample evidence that the standard needs attention in the area of CA and PA. I'm not sure how you can say, on the one hand, that "...preventive action is a corrective action..." and then say that there's a bright line between the two. While you maintain that the wording of the standard is clear, the degree of clarity of the requirement isn't necessarily in question; it's whether what's required makes sense or not that's the issue. I say that we have to always be aware of opportunities for defect prevention, and whether or not preventive action takes place before or after something bad happens is immaterial, so long as there is still evidence that reasonable efforts are made to preempt problems.

:soap: The first thing we need to do is acknowledge that the mistakes, missteps and minor disasters we all experience are not evil until they become repetitive. We'll never overcome human propensity for error, but we also need to recognize our ability to learn from our mistakes. We need to be able to show evidence of learning from nonconforming conditions, and applying the new knowledge in ways that result in continualous improvement. Something that's better today than it was yesterday is evidence of improvement, regardless of the source of the new knowledge, and all of this back-and-forth over the words we use to describe the process does not add value to anything. Every time I do something that results in defects being prevented, I don't want to have to stop and look at the standard and see which column to put a check mark in. When the standard gets in my way, it's no longer serving its purpose. If, as a result of something bad happening, I fix the process so it can't happen again, I've done preventive action and anyone who says I haven't needs to get his head out of the standard and find something useful to do, because there's actual work to be done.

FMEAs should be live documents, then they are effective tools for preventive action, before and after lunch:D

:topic:Once I received notice of a meeting, to take place midday, wherein the author of the notice made the same typo, saying that it was a "lunch" meeting rather than a "launch" meeting. As we were accustomed to lunch being provided in those instances, a lot of hungry and angry people showed up.

I have never liked the language of preventive actions. It almost reads like an afterthought of the corrective action. I have a friend who is a member of the TAG, and I was complaining to him about that. His response was for me to reword it the way I felt it should be and forward it to him for consideration.

I keep saying that someday, I will have to do that.

I think this paragraph provides ample evidence that the standard needs attention in the area of CA and PA. I'm not sure how you can say, on the one hand, that "...preventive action is a corrective action..." and then say that there's a bright line between the two. While you maintain that the wording of the standard is clear, the degree of clarity of the requirement isn't necessarily in question; it's whether what's required makes sense or not that's the issue.

I have already agreed I would like them to clarify their intent because there is so much disagreement among otherwise knowledgable people.

However, my comment was "preventive action is a corrective action done ahead of time, before the failure occurs." That is what made it a "preventive action" performed upon a potential failure. If you wait until the failure occurs, it is too late to be proactive and you are consigned to reacting and doing only a regular corrective action. Preventive actions are superior because you are being proactive. Preventive actions are generally cheaper because no failure mess has occurred.



I say that we have to always be aware of opportunities for defect prevention, and whether or not preventive action takes place before or after something bad happens is immaterial, so long as there is still evidence that reasonable efforts are made to preempt problems.


As I said...Preventive actions are superior because you are being proactive - Preventive actions are generally cheaper because no failure mess has occurred.

Interesting anecdote. I just completed an audit and had this identical discussion with the client. They went from your point of view to completely understanding the ISO definition of Preventive vs. Corrective and are eager to apply it.

I have never liked the language of preventive actions. It almost reads like an afterthought of the corrective action. I have a friend who is a member of the TAG, and I was complaining to him about that. His response was for me to reword it the way I felt it should be and forward it to him for consideration.

I keep saying that someday, I will have to do that.


By all means, do it now...:applause:

Why would it be an "afterthought of corrective action" if you do it before a corrective action is called for?

FMEAs should be live documents, then they are effective tools for preventive action, before and after lunch:D


Personally, I always liked to do them after dinner because there were less interuptions.

However, as I said, the FMEA is discussed in cl 7.3.3.1 and 7.3.3.2, Preventive Maintenance is cl 7.5.1.4, and Preventive Action section is cl 8.5.3.

While FMEAs and PMs are preventive activities, doesn't it seem logical that the standard is looking for something else for cl 8.5.3? Otherwise, why would they have made another section? And, why would they have used identical language as corrective action? If it wanted these same things, they had already covered it.

I still insist they said exactly what they meant. It seems so patently clear and obvious to me. I don't understand why so many of you resist it.

PS: Sidney, I will respond to your challenge to find 5 examples very soon.

However, my comment was "preventive action is a corrective action done ahead of time, before the failure occurs." That is what made it a "preventive action" performed upon a potential failure. If you wait until the failure occurs, it is too late to be proactive and you are consigned to reacting and doing only a regular corrective action. Preventive actions are superior because you are being proactive. Preventive actions are generally cheaper because no failure mess has occurred.

If someone is waiting until failures occur before they do anything, I agree that it's a problem. We even have a recent comment in another thread (http://elsmar.com/Forums/showpost.php?p=222511&postcount=1) where someone complains about management being completely reaction-oriented when it comes to safety issues, so I know this sort of thing goes on. But that's not the point. Of course it's best to prevent rather than react. The problem is that s*** happens even in the best prevention-oriented systems, and in those systems, people look around after failures to find similar potential problems in similar products and processes, yet that effort (at least in TS16949) is not considered preventive. That's patently ridiculous.

My thesis is simply this: if someone makes the effort to prevent something bad from happening, futzing with the language in order to claim that nothing preventive was done makes no sense, and borders on the Orwellian. If it's possible to rewrite the standard such that it's clear that heading off problems before they happen is the expected course of action, and so that we don't deny something is preventive (using the dictionary denotation) when it clearly is, why wouldn't we want to do it? Just saying that the meaning of the language in the standard is clear doesn't mean that what's expected makes sense. Using that line of reasoning, if the standard said that all production employees must wear pink tutus, the requirement would be clear, no?

As I said...Preventive actions are superior because you are being proactive - Preventive actions are generally cheaper because no failure mess has occurred.

No one is disputing this, but it has nothing to do with the issue at hand.

Interesting anecdote. I just completed an audit and had this identical discussion with the client. They went from your point of view to completely understanding the ISO definition of Preventive vs. Corrective and are eager to apply it.

This is also irrelevant, because as you say, the requirements are clear, and if the client wasn't meeting them, it's not surprising that they were eager to be in compliance. The same could be said about the supplier being eager to outfit their production people in pink tutus if that's what was required.

If someone is waiting until failures occur before they do anything, I agree that it's a problem. We even have a recent comment in another thread (http://elsmar.com/Forums/showpost.php?p=222511&postcount=1) where someone complains about management being completely reaction-oriented when it comes to safety issues, so I know this sort of thing goes on. But that's not the point. Of course it's best to prevent rather than react. The problem is that s*** happens even in the best prevention-oriented systems, and in those systems, people look around after failures to find similar potential problems in similar products and processes, yet that effort (at least in TS16949) is not considered preventive. That's patently ridiculous.

My thesis is simply this: if someone makes the effort to prevent something bad from happening, futzing with the language in order to claim that nothing preventive was done makes no sense, and borders on the Orwellian. ....

At least we pretty much agree on this part. Just remember that both corrective action and preventive action, by ISO definition, prevent something - the reoccurance, or the occurance of a root cause. So, either way, they are being preventive. No need to be concerned about Orwell.

For each action, let's just select the better fit and move on. I think too much energy is spent trying to decide what label to put on an action. Let's apply that energy to identifying areas where bad things could happen, and take action to prevent them. That is the greater part of the equation.

:2cents:

I think too much energy is spent trying to decide what label to put on an action. Let's apply that energy to identifying areas where bad things could happen, and take action to prevent them. That is the greater part of the equation.


Yup, agree. I think that was pretty much what Jim suggested several posts back :)

I voted yes on the poll because yes, I think it could be clearer.
Yes, they are two different terms, and yes, I understand that they are different things.

But in practice, I do disagree that they are always 'crystal clear' and I sure as hell spend one heck of a lot of time attempting to educate clients a/about the difference and b/about meeting the different requirements.

I'd be very interested to see all those in favour of no change list their 5 crystal clear examples of preventive actions.

Yup, agree. I think that was pretty much what Jim suggested several posts back :)

I voted yes on the poll because yes, I think it could be clearer.
Yes, they are two different terms, and yes, I understand that they are different things.

But in practice, I do disagree that they are always 'crystal clear' and I sure as hell spend one heck of a lot of time attempting to educate clients a/about the difference and b/about meeting the different requirements.

I'd be very interested to see all those in favour of no change list their 5 crystal clear examples of preventive actions.


I do plan to spend time developing 5 examples today, per Sidney's challenge. However, let's recalibrate a couple of phrases here.

First, I agreed I would like them to reclarify their INTENT, in the next revision. On this, most of us agree.

My previous comment on "crystal clear" was actually

"Of course, as a spokesperson for the camp that says it means just what it says, why can't we just accept it as written? A proactive cousin to corrective action, after launch, before failure, following the same steps as corrective action? Alas, perhaps it is just my simple mind...:cool: ...but to me it is crystal clear.


I did not suggest that preventive action, as a concept, was "crystal clear" to everyone. Quite the contrary. I, too, spend much time explaining to clients what Preventive Actions are.

What I suggested was clear to me, was, that they wrote the details of cl 8.5.3 to exactly mirror cl 8.5.2. Thus it is "crystal clear" to me they did not intend to sweep FMEAs and Preventive Maintenance and all the other examples people have given into cl 8.5.3. The reason it is clear to me is those activities are indeed preventive activities, but they are covered in other specific areas. They are not even mentioned in cl 8.5.3. Thus, it is clear to me they did not INTEND those activies to be the answer to cl 8.5.3.

What I suggested was clear, was since they wrote cl 8.5.3 to exactly mirror cl 8.5.2, and since the official ISO definitions are IDENTICAL except for the use of the words "occurance" vs. "RE-occurance," thus it is "crystal clear" to me they intended preventive actions to be just like corrective actions, on a CA form, but proactive, not reactive. BEFORE the failure occurs. Other than that, they are the same thing. Two twin problem solvng tools, one reactive, one proactive. Nothing more, nothing less. THIS is what I suggested was "crystal clear" to me.

I asked, "why can't we just accept it as they wrote it?" It is a good tool. These other things are good activities as well, but they fit better in the other clauses I have listed in earlier posts.

I do plan to spend time developing 5 examples today, per Sidney's challenge. However, let's recalibrate a couple of phrases here.


You might find this more challenging than you think. For example, if I can't use the results of a nonconforming condition as impetus for PA, then aren't you excluding everything I might have learned in the past as a result of NC conditions? Therein lies the absurdity of the dichotomy. What is the time limit? If, five years ago, something blew up in my face and resulted in some egregious nonconforming condition, and today I'm faced with a similar situation, may I claim my actions are wholly preventive? The challenge, as I see it, is not to come up with examples of PA, it's to come up with examples of PA that were not the result of experience with bad things happening in the past.

You might find this more challenging than you think. For example, if I can't use the results of a nonconforming condition as impetus for PA, then aren't you excluding everything I might have learned in the past as a result of NC conditions? Therein lies the absurdity of the dichotomy. What is the time limit? If, five years ago, something blew up in my face and resulted in some egregious nonconforming condition, and today I'm faced with a similar situation, may I claim my actions are wholly preventive? The challenge, as I see it, is not to come up with examples of PA, it's to come up with examples of PA that were not the result of experience with bad things happening in the past.


I understand your point, but I would suggest you are overthinking it. That is why I coined the following explanation:

If the CA/PA form you commence to fill out is in REACTION to a failure event, then simply class it a Corrective Action and move on.

If the CA/PA form you commence to fill out is PROACTIVE to a POTENTIAL failure event, (no one compelled you to initiate it), then simply class it a Preventive Action and move on.

I literally do not spend more than a moment or two evaluating which label I place on it. We both agree, the label does not mean much ONCE WE HAVE COMMENCED the action. That is the main point I have been trying to make. I don't make any effort whatsoever to try to correlate it to some event in the past or a book I read or anything else.

Simple, natural, spontaneous. That is why I like this approach. My clients easily understand the concept.

I understand your point, but I would suggest you are overthinking it. That is why I coined the following explanation:

If the CA/PA form you commence to fill out is in REACTION to a failure event, then simply class it a Corrective Action and move on.

If the CA/PA form you commence to fill out is PROACTIVE to a POTENTIAL failure event, (no one compelled you to initiate it), then simply class it a Preventive Action and move on.


I am not overthinking anything. Practically everything we do wrt PA is reaction to something that happened in the past. How long do we have to wait before we can call the reaction PA? Unless you can answer that question and provide examples that are not reactive to past experience, you have no case.

I am not overthinking anything. Practically everything we do wrt PA is reaction to something that happened in the past. How long do we have to wait before we can call the reaction PA? Unless you can answer that question and provide examples that are not reactive to past experience, you have no case.

Jim, I don't know what you want. If you want a debate, you're not going to get it from me. I finished with the debate-for-sport aspect of this topic months ago.

Your previous post asked what sounded like a simple question, and I explained my simple approach. It works very nice, clean and simply. If that answer does not satisfy you, then nothing else I say on the topic will either. I refuse to allow this topic to be complicated, because my read of the definitions make the intent pretty darn clear to me.

I have already explained all the reasons for that viewpoint several times in previous posts in this and other threads.

If you want a "time," I would recommend you wait four months, three days, and 16.25 hours, then it can be preventive. I think that is a silly question and posture to take. A Proactive vs. Reactive position makes a lot more sense to me and explains simply why there would be any distinction between the two in the first place. I am interested in helping clients to get the results, not debate titles.

I have chosen to follow the concept that the ISO definitions present - that Preventives intend to be proactive, and Correctives focus on reactives, and both will prevent root causes.

I will not read any more into it than that. That works perfectly for me, and all the rest is idle debate without any end in sight.

You may choose to follow this path, or whichever other suits your fancy. But there is no benefit in parsing and dissecting the words. They say what they mean.:bigwave:

Thank you guys for the very informative discussions…some maybe too deep though. Can I seek your advice on something? On our CA/PA form, we defined the corrective action as "To prevent recurrence of the problem due to the most probable cause." and preventive action as "To prevent occurrence of the problem due to other potential causes.". Is this an accurate definition? What if during the root cause analysis exercise we can't find any other potential cause that could lead to the same failure mode. Will it be acceptable to an auditor to write "implement the above corrective action and monitor effectiveness for several weeks"?

Thank you guys for the very informative discussions…some maybe too deep though. Can I seek your advice on something? On our CA/PA form, we defined the corrective action as "To prevent recurrence of the problem due to the most probable cause." and preventive action as "To prevent occurrence of the problem due to other potential causes.". Is this an accurate definition? What if during the root cause analysis exercise we can't find any other potential cause that could lead to the same failure mode. Will it be acceptable to an auditor to write "implement the above corrective action and monitor effectiveness for several weeks"?

From the point of view that I have been making, this would not work. The standard addresses preventive and corrective as two different activities. You use either one or the other. If you are observing a potential failure, then you execute a Preventive Action. If you observe an actual failure, you execute a Corrective Action. From that point, all the causes and actions stay on whichever form you began - preventive or corrective. There is little to be gained to filling out two forms.

Per Sidney's challenge on the other current thread, I wrote a white paper on Preventive Action. For those of you who are interested, it may be a worthwhile read.

Thank you guys for the very informative discussions…some maybe too deep though. Can I seek your advice on something? On our CA/PA form, we defined the corrective action as "To prevent recurrence of the problem due to the most probable cause." and preventive action as "To prevent occurrence of the problem due to other potential causes.". Is this an accurate definition? What if during the root cause analysis exercise we can't find any other potential cause that could lead to the same failure mode. Will it be acceptable to an auditor to write "implement the above corrective action and monitor effectiveness for several weeks"?

Carl,

I think you'd be better advised to stay with the ISO definitions of CA and PA. Making up your own could be unwise. I'd use the ISO 9000 (2006) definitions which I think have already been posted.

If you can't find any other potential cause - fine, stop. The Standard pushes you to consider the need and to act if you find cause. Don't go hunting about for ever. As for 'will it be acceptable to an auditor if we do x'... I just can't answer that. It's one of those 'pieces of string' questions.

Here's a sequence:
1. If a problem, correct it (if you can) - eg, rework. That's just correction (not CA)
2. If the problem could recur, then identify the cause/s and do CA to fix the causes & prevent recurrence. That is CA.
3. (Trickier) If you identify potential causes of potential NCFs, do PA to prevent them.

Sometimes CA does lead on to PA. Sometimes it doesn't. Sometimes PA comes about without CA, all by itself. Depends. Sorry - I KNOW that's not a 100% definite rule. It cannot be.

Re. 'implement the above corrective action and monitor effectiveness for several weeks" - the 'several weeks' monitoring depends on the thing at hand. How long do you need to monitor to ensure your CA has been effective? That's the real question. Might be a week, might be a month, might be several weeks. Don't just blindly pick 'several weeks'.

Thanks for clarifying these things and in much simpler perspective too...About monitoring for "several weeks", I don't actually use that instead I use an exact time frame as you pointed out.

A few observations:

1 The wording of 8.5.2 ("take action to eliminate") and 8.5.3 ("determine action to eliminate") is slightly different for no reason. 8.5.3 is a waste of paper.

2 The requirements for CA / PA are in fact identical - the only difference is that they are triggered by different events. For CA, something has happened. For PA, you realise that something might happen. In both cases, you work out how to avoid the "something" happening in the future.

3 You might therefore think that they could reasonably be described in a single procedure - but how you "recruit staff" / "provide training" / "accept a customer order" / "plan and monitor production" (even "design a process") should all be done in a way which anticipates problems (ie CA / PA). This is what "process management " is all about, ie you design and implement processes in a way which recognises the factors which may influence how well the processes will work.

Unfortunately, the wording of the standard causes folk to think that they have to do more than what a "good" manager should be doing anyway.

A few observations:

1 The wording of 8.5.2 ("take action to eliminate") and 8.5.3 ("determine action to eliminate") is slightly different for no reason. 8.5.3 is a waste of paper.

2 The requirements for CA / PA are in fact identical - the only difference is that they are triggered by different events. For CA, something has happened. For PA, you realise that something might happen. In both cases, you work out how to avoid the "something" happening in the future.

3 You might therefore think that they could reasonably be described in a single procedure - but how you "recruit staff" / "provide training" / "accept a customer order" / "plan and monitor production" (even "design a process") should all be done in a way which anticipates problems (ie CA / PA). This is what "process management " is all about, ie you design and implement processes in a way which recognises the factors which may influence how well the processes will work.

Unfortunately, the wording of the standard causes folk to think that they have to do more than what a "good" manager should be doing anyway.


I would think your point #2 would demonstrate there is a value in PA, rendering point #1 incorrect?

I would think your point #2 would demonstrate there is a value in PA, rendering point #1 incorrect?
Helmut

On the contrary, 8.5.3 repeats almost all the wording of 8.5.2. If the first part of the clause explained the two types of trigger event, the steps required are the same. Words for words sake...

I would like to offer some systems thinking ideas to the thread. Many might say that I am over thinking this.

I think that true preventive action is when the information, upon which you base your action, comes from outside of the system. Cascading corrective action to similar areas in the system (organization) to me is still corrective action. When someone brings information into the system from sources outside of the system, then you really have preventive action. Re-applying what you have learned from within the system, to me, is corrective action.

I don't think time sequence has anything to do with the definitions. I think the source of the information upon which you base your action is the more valid basis. Is something unwanted happens within your system, and you fix the unwanted thing (elimiante the cause) and then cascade that to other areas within the system, is still corrective aciton to me.

If understanding and knowledge comes from outside the system, and this understanding and knowledge allows you to eliminate the casue of a potential unwanted thing, then I say that is preventive aciton.

For those that say this is over thinking it, I say that your wrong. What would support bringing new understanding into the system if this is overthinking things?

I would like to offer some systems thinking ideas to the thread. Many might say that I am over thinking this.

I think that true preventive action is when the information, upon which you base your action, comes from outside of the system. Cascading corrective action to similar areas in the system (organization) to me is still corrective action. When someone brings information into the system from sources outside of the system, then you really have preventive action. Re-applying what you have learned from within the system, to me, is corrective action.

I don't think time sequence has anything to do with the definitions. I think the source of the information upon which you base your action is the more valid basis. Is something unwanted happens within your system, and you fix the unwanted thing (elimiante the cause) and then cascade that to other areas within the system, is still corrective aciton to me.

If understanding and knowledge comes from outside the system, and this understanding and knowledge allows you to eliminate the casue of a potential unwanted thing, then I say that is preventive aciton.

For those that say this is over thinking it, I say that your wrong. What would support bringing new understanding into the system if this is overthinking things?Like Hjiling says: crystal clear:biglaugh:.

In my mind there is no question that preventive action should be THE main target for clarification in ISO 9001. The mystery is why doesn't the TC176 realize that? Or, if they do, why don't they do something about it? Another conspiracy?

Helmut

On the contrary, 8.5.3 repeats almost all the wording of 8.5.2. If the first part of the clause explained the two types of trigger event, the steps required are the same. Words for words sake...


Precisely...and your point #2 correctly points out the subtle but important difference. THAT is what gives it value in my opinion - the fact that Preventives are intended to be a proactive search for potential failure. That is far superior than waiting for issues to arise. Thus, the value of 8.5.3. Now, if only they would emphsize that important distinction so everyone would get it...:cool:

Like Hjiling says: crystal clear:biglaugh:.

In my mind there is no question that preventive action should be THE main target for clarification in ISO 9001. The mystery is why doesn't the TC176 realize that? Or, if they do, why don't they do something about it? Another conspiracy?


...hey, it's crystal clear to ME, if the rest of you don't get it...that not my fault...:notme:

Now, I took the time to accept your challenge to write 5 examples of PA...Sooo...my friend, I expect you will at least take time to read my white paper and tell me why you don't like my 5 examples...hmmm?

... how you "recruit staff" / "provide training" / "accept a customer order" / "plan and monitor production" (even "design a process") should all be done in a way which anticipates problems (ie CA / PA). This is what "process management " is all about, ie you design and implement processes in a way which recognises the factors which may influence how well the processes will work.


Yes indeed. As well as planning. Good planning includes sound 'preventive action' and risk management - ie, anticipating things that *might* not work/go wrong etc. and planning, designing & implementing to prevent or avoid that.

...hey, it's crystal clear to ME, if the rest of you don't get it...that not my fault...:notme:

Now, I took the time to accept your challenge to write 5 examples of PA...Sooo...my friend, I expect you will at least take time to read my white paper and tell me why you don't like my 5 examples...hmmm?

Will do.

This thread has certainly stimulated some spirited and interesting debate, for which thanks to all. :applause:

Helmut,

Good paper, relatively straightforward. I've been thinking over your 'reactive vs proactive' position and think it's a good 'get it in a blink' practical way of differentiating the two.

In your paper, I found egs 3 and 4 not clear and a little theoretical. A 'concrete' type of example would have been a bit clearer - 1 and 2 were much clearer. And 5? fine.

Thanks to you and all others for taking the time to debate.

But I think the sheer volume of debate around the topic, including the strong opinions both for & against in the latest add substance to the position that it's confusing. NOT with you, Helmut, I hasten to add.

It's possible that the change in wording for 4.2.1 with the 2008 version, adding Note 2 to clarify that a single document may include the requirements for one or more procedures may help somewhat, by perhaps encouraging the combining of CA & PA into a single procedure, hence reducing confusion.

I see both sides on this one: I see why the Standard differentiates and what the intent is. But PA & CA vs PA is very, very often found confusing in practice for newbies, and sometimes not just newbies. So if we've had this debate, I can only imagine what might have occurred in the TC.

I've also occasionally had problems with a distinctly pigheaded and old-fashioned auditor type who wanted a whole specific dedicated PA procedure and associated PA form...

Overall, I could wish it were simpler, but I can live with what's there - I'll have to:).
Perhaps if we had revised the relevant clauses? :tg:

Friends,

From a cold and windy Netherlands, greetings!
I noticed that time goes fast while you're on vacation....;)

I have been following this discussion from a distance for a while and I want to thank all participants for a great dialogue on this topic that continues to stir emotions.

Helmut has provided us with great insights and examples. Yes, it is "crystal clear" to me. The distinction between the two processes is not complicated. I just wished that organizations would engage in more proactive work rather than reactive. It's cheaper too.

Keep up the good work and dialogue! :applause:

Stijloor.

Precisely...and your point #2 correctly points out the subtle but important difference. THAT is what gives it value in my opinion - the fact that Preventives are intended to be a proactive search for potential failure. That is far superior than waiting for issues to arise. Thus, the value of 8.5.3. Now, if only they would emphsize that important distinction so everyone would get it...:cool:

Helmut

I agree that it is far more important to anticipate and avoid, rather than to sort out after the event. But what I saying is that the section would be much easier to read if there were fewer words, and especially less repetition. I don't see what is wrong with (eg):

"The organization shall take action to eliminate the causes of potential and actual nonconformities in order to prevent their future occurrence..."

Then list the things to be done...

and delete 8.5.3.

There is less to read, and it doesn't run the risk of the reader thinking that (as in the previous version) they have to define separate procedures because there are separate sections. In fact, you do not even need to define a single procedure - so long as you define how you "try to avoid things going wrong" in your other process descriptions.

But then there are several other parts of the standard which could be easier to read, and therefore clearer, as well...

Friends,

From a cold and windy Netherlands, greetings!
I noticed that time goes fast while you're on vacation....;)

I have been following this discussion from a distance for a while and I want to thank all participants for a great dialogue on this topic that continues to stir emotions.

Helmut has provided us with great insights and examples. Yes, it is "crystal clear" to me. The distinction between the two processes is not complicated. I just wished that organizations would engage in more proactive work rather than reactive. It's cheaper too.

Keep up the good work and dialogue! :applause:

Stijloor.

Enjoy your Holiday.

Per Sidney's challenge on the other current thread, I wrote a white paper on Preventive Action. For those of you who are interested, it may be a worthwhile read.

I've just now had the time to read your paper, and want to thank you for going to the trouble to write and post it. I'm sure it'll be helpful to many here.

The problem is that it explains how to deal with PA as ISO 9001 is currently composed, and doesn't address the issues at hand. No one is disputing that there's a difference between anticipation of defects and reaction to them, or that the former, when possible, is better than the latter.

When word came down that 9000-1994 was going to be revised, I took the opportunity to offer the committee a suggestion for dealing with this subject. While I no longer have the correspondence involved, suffice it to say that I received in response a form letter thanking me for my suggestions, and that was the extent of it. I mention this only because there may be those who wonder why I'm complaining about this here rather than trying to do something about it. At any rate, I've reproduced my suggested changes as I remember them and have attached them here. Note that I've added a separate category, remedial action, for dealing with rework, repair, etc.

Now, I took the time to accept your challenge to write 5 examples of PA...Sooo...my friend, I expect you will at least take time to read my white paper and tell me why you don't like my 5 examples...hmmm?
Like Jim, I say, thanks for taking on the challenge and having the courage to post it.

When I dissect your examples, I see that scenario 1 and 4 have nothing to do with quality issues, thus beyond ISO 9001.

Scenario 2 is the classical example of an outsider doing a cursory review of a job task and asking the “what if”. Most knowledgeable people will always be able to ask some pointed “what if” questions, like an informal PFMEA and, most of the time, identify a failure mode which is not likely. Cost effectiveness assessments would be hard to reach due to the subjectivity of the likelihood of failure. Also, it was unclear your role in the scenario. Were you an auditor or the process owner, or just an interested party?

Scenario 3 is an academic, general scenario.

Scenario 5. What can I say? I could dream of preventive actions for the Iraqi invasion, JFK’s assassination, Global Warming, etc... Monday morning quarterbacking.

To be honest, I am just tired of this never ending discussion. The basic problem is that you have a standard which 92.3% requirements are aimed at preventing problems, as it should, since we all know that prevention is much better than correction. However, on top of that, they have a specific requirement for preventive actions. If a specific paragraph creates so much discussion and dissent, it should be flagged for clarification. Why doesn’t the TC 176 see that? Beats me.

ISO has issued a book called ISO 9001 for small businesses.
http://www.standards.org.sg/files/Vol9No4Art1_files/iso9001fsb.jpg
The book is supposed to provide advice on implementing ISO 9001. When it comes to preventive actions, there should not be much difference if you are a small, medium or large business. From that book, they state the following examples for sources of information to be considered for PA:

SPC
Manufacturer’s recommended machinery service limits
Monitoring capacity usage of computer servers
Monitoring machine usage of capacity
Increase queue lengths
Lateness and absentee rates amongst staff
Service reports
Customer or market survey results
Sales trendsExamples of application of PA include:

Planned preventive maintenance
Alarms, indicators and
Mistake-proofing techniquesDo you consider this to be what 8.5.3 refers to? If it is crystal clear to you, excellent. Keep up the great work you do.

I voted for change and I think this debate is sufficient evidence of the need for it.

I guess it's okay to refer to people who don't know the argot as "newbies," but I prefer to think of them as successful business people who are innocent of the corrupting influence of Quality Assurance professionals.:tg:

I believe if you were to poll these innocents, you would find 95 out of 100 define CA and PA as follows:Corrective action is the stuff we do to correct problems, such as replacing the wrong product with the right product or reworking the widgets so they match the print.

Preventive action is the stuff we do to keep problems from happening again.

Common sense is realizing that we ought to store the rice in rat-proof containers rather than the paper bags we were going to use.

Improvement is finding a way to do the job at less cost.

But spending money to prevent something that might happen and claiming we were effective because something that has never happened before didn't happen again is BS.
Think back; isn't this how most of your co-workers, clients, or both, thought about these matters before you explained the "correct" usage?

The usage in ISO 9001:2000 is so counter-intuitive that I usually apologize to people before explaining it.

"The organization shall take action to eliminate the causes of potential and actual nonconformities in order to prevent their future occurrence..."

Then list the things to be done...

and delete 8.5.3.

...


That would be rather elegant...I'd support it.:applause:

I


...But spending money to prevent something that might happen and claiming we were effective because something that has never happened before didn't happen again is BS.....




It is interesting what points we can make when we change the words...Well, I agreed with most of your comments...

I've just now had the time to read your paper, and want to thank you for going to the trouble to write and post it. I'm sure it'll be helpful to many here.

The problem is that it explains how to deal with PA as ISO 9001 is currently composed, and doesn't address the issues at hand. No one is disputing that there's a difference between anticipation of defects and reaction to them, or that the former, when possible, is better than the latter.

When word came down that 9000-1994 was going to be revised, I took the opportunity to offer the committee a suggestion for dealing with this subject. While I no longer have the correspondence involved, suffice it to say that I received in response a form letter thanking me for my suggestions, and that was the extent of it. I mention this only because there may be those who wonder why I'm complaining about this here rather than trying to do something about it. At any rate, I've reproduced my suggested changes as I remember them and have attached them here. Note that I've added a separate category, remedial action, for dealing with rework, repair, etc.


I agree it would be an improvement over what is currently there.

Like Jim, I say, thanks for taking on the challenge and having the courage to post it.

When I dissect your examples, I see that scenario 1 and 4 have nothing to do with quality issues, thus beyond ISO 9001.




Thanks for your reply. Not sure why 2 and 3 would "have nothing to do with quality issues" as they deal with product quality. But, that's OK. This thread has run it's course. I think we can all lay it to rest.

Those who can get value from the white paper are welcome to use it. I will probably trun it into a PowerPoint at some point.




To be honest, I am just tired of this never ending discussion. ...If a specific paragraph creates so much discussion and dissent, it should be flagged for clarification. Why doesn’t the TC 176 see that? Beats me.




No argument there.




The book is supposed to provide advice on implementing ISO 9001. Do you consider this to be what 8.5.3 refers to? If it is crystal clear to you, excellent. Keep up the great work you do.

Not sure that I would be buying the book, but at least they tried.


OK, gang, let's be proactive, for that is what is important. What we call it is far less critical. And, maybe, someday they will word it better.

signing off on this one...folks...

"Lost in translation should be the culprit of confusion…"

…for me, the definition of corrective action (8.5.2) & preventive action (8.5.3) in ISO9001:2000 is clearly defined…

…I don’t know, but I guess most of those who are “lost in translation” confused not really on the definition itself but on the implementation aspect…

:2cents:

"Lost in translation should be the culprit of confusion…"

…for me, the definition of corrective action (8.5.2) & preventive action (8.5.3) in ISO9001:2000 is clearly defined…



Excellant, except now it's ISO 9000:2005;)

This post has re vitalized my interest in ISO 9001:2000 ;):truce:

"Lost in translation should be the culprit of confusion…"

…for me, the definition of corrective action (8.5.2) & preventive action (8.5.3) in ISO9001:2000 is clearly defined…

…I don’t know, but I guess most of those who are “lost in translation” confused not really on the definition itself but on the implementation aspect…

:2cents:

Well said, :bigwave::agree1:

Just for those who still may be confused, I would like to give you my version.

Production line 1 - Produces reject parts. You implement a fix. This is Corrective Action

Production Line 2 - Has the same parts and process with no reject, you implement the same fix as line 1. This is preventive action. You are preventing line 2 from producing the same rejects as line 1.

Continual Improvement, Review the entire process, implement additional improvements, this is also preventive action, the additional improvements is to eliminate any other potentially errors before they occur.

:)

Well said, :bigwave::agree1:

Just for those who still may be confused, I would like to give you my version.

Production line 1 - Produces reject parts. You implement a fix. This is Corrective Action

Production Line 2 - Has the same parts and process with no reject, you implement the same fix as line 1. This is preventive action. You are preventing line 2 from producing the same rejects as line 1.

Continual Improvement, Review the entire process, implement additional improvements, this is also preventive action, the additional improvements is to eliminate any other potentially errors before they occur.

:)

I agree with your general intent, but not your specific examples.

Unfortunately, if you follow the model you outlined, you will do 3 different pieces of paper, and 3 different projects, for the same set of actions. That is not very efficient.

What if we looked at it the way automotive would. (I think they get this right.)

Your example #1 is correct. That is corrective action. However, if you have 4 similar lines, and the corrective action made sense and was effective on line 1, then it must be applied to the others as well. TS-16949 calls that Corrective Action Impact and files it under 8.5.2.3. The premise is it does not make sense to apply the corrective action only to one machine, and wait for the failure to reoccur on the others.

A better example for a preventive action in example #2 would be, you are observing that line running, and see a potential for this failure to occur. You decide to take "proactive preventive action" to ensure it does not occur. You apply it to line 1, verify it was effective and worthwhile, and apply it to the others. That whole process was a preventive Action.

Continual Improvement projects should not "also be preventive actions." That just muddies the water again. If it is a preventive action, then call it a preventive action. In automotive, if it is already good, and you make it better, that would fit the Continual Improvement project paradigm.

All three make the company better, and they are similar, but the starting intent comes from 3 different angles. And that is why it was justified to identify them as 3 different tools. There are many similar tools in my toolbox at home, but each wrench and tool is similar but different, and has a different specific purpose.

Well said, :bigwave::agree1:

Just for those who still may be confused, I would like to give you my version.

Production line 1 - Produces reject parts. You implement a fix....This is Corrective Action


I guess it goes without saying that "fix" includes removing the cause.

Right?

Without getting the details for the foregoing discussion, I can add this: The revision of ISO 9001 with a target of 2015 has started. As the Design Specification is developed, user imput will be sought. I would highly recomend that you provide your points of view to the US TAG. Better yet, join the TAG. Industry representatives are needed.

Without getting the details for the foregoing discussion, I can add this: The revision of ISO 9001 with a target of 2015 has started. As the Design Specification is developed, user input will be sought. I would highly recommend that you provide your points of view to the US TAG. Better yet, join the TAG. Industry representatives are needed.Yes, joining the US TAG could be a start, even though some people, including myself feel the process is too "political". See the General Info on ISO 9000 and Technical Committee 176 - Getting Involved (http://elsmar.com/Forums/showthread.php?t=12588&highlight=176) where Marc was even considering sponsoring someone's participation there.
But I stand by my previous post where I expressed my concern that, since 1994 when ISO 9001 highly emphasized preventive action and explicitly separated the requirement from corrective action, quality system professionals endure countless, protracted, frustrating discussions on the APPLICATION of preventive action. Here at the Cove, we have some of the longest threads dealing with preventive action deployment. Based on that body of evidence, I can attest that the PRATICAL IMPLEMENTATION of preventive action is weak, around the World.

It miffs me to realize that the forthcoming revision of ISO 9001, designed and intended to CLARIFY the requirements of the standard, proposes NOT a SINGLE clarification other than e) reviewing the effectiveness of the preventive action taken. Why in the World the TC 176 fails to realize that preventive action needs clarification leads me to believe that, as I said before, they are out of touch with "ordinary people and systems" or realized they are powerless to come up with a better text.

Yes, joining the US TAG could be a start, even though some people, including myself feel the process is too "political". See the General Info on ISO 9000 and Technical Committee 176 - Getting Involved (http://elsmar.com/Forums/showthread.php?t=12588&highlight=176) where Marc was even considering sponsoring someone's participation there.
But I stand by my previous post where I expressed my concern that, since 1994 when ISO 9001 highly emphasized preventive action and explicitly separated the requirement from corrective action, quality system professionals endure countless, protracted, frustrating discussions on the APPLICATION of preventive action. Here at the Cove, we have some of the longest threads dealing with preventive action deployment. Based on that body of evidence, I can attest that the PRATICAL IMPLEMENTATION of preventive action is weak, around the World.

It miffs me to realize that the forthcoming revision of ISO 9001, designed and intended to CLARIFY the requirements of the standard, proposes NOT a SINGLE clarification other than Why in the World the TC 176 fails to realize that preventive action needs clarification leads me to believe that, as I said before, they are out of touch with "ordinary people and systems" or realized they are powerless to come up with a better text.

As most here know, there is much about the ISO view of corrective and preventive action that doesn't make much sense to me. I won't rehash my misgivings again in this thread, but it seems to me that when there's such a perception of widespread misunderstanding, something's wrong with the standard, and not the implementation of it.

In this post (http://elsmar.com/Forums/showthread.php?p=267310#post267310) you can see evidence of the unnecessary complications suppliers are faced with when it comes to CA reporting. Cover World Quality, who has been very generous in posting attachments here, recommends the latest thing: a five page CA reporting form that requires the ridiculous "5 whys," a fishbone diagram, and other time-wasting form-filling activities that are not likely to be helpful or make anything better. The fact that customers often ask for all of this busy-work when the defect in question is an obvious outlier, or doesn't disturb the supplier's mandated PPM levels, is further evidence that no one understands what they're doing.

Then there's this recent thread (http://elsmar.com/Forums/showthread.php?p=266601) wherein the OP isn't sure about how to measure CAPA effectiveness. As I've often said, if you don't know what to measure, you haven't even defined the process, or even know why there's a process to begin with.

Even the idea of "continuous improvement" makes no sense on close examination. Surely some sort of a state of equilibrium will be reached sooner or later if a company practices process control efficaciously, a state where the economics of the situation moves "the organization" into a maintenance mode and additional significant improvement is no longer a reasonable goal.

We need to concentrate on process control:


Do the best you can to understand variation and reduce it as much as possible, and then monitor.
Make sure that everyone understands the requirements and is expected to meet them consistently.
Know the difference between a bad process and a bad operator, and take decisive action on one of them.
When something goes wrong, find out why, and fix it so that the chance of recurrence is acceptably small.
Don't make promises to customers that you know you can't keep, and then blame the workforce when the chickens come home to roost.
Never guess when the requirements are ambiguous, and make an honest effort to remove ambiguity before something bad happens.

Achieving acceptable quality levels is a function of leadership and determination and force of will, and can't be encapsulated in a clause of the standard. Filling out a five-page form never helped anyone to understand anything worth knowing, and haggling over the difference between CA and PA is equivalent to arguing about whether a carnivorous reptile is an alligator or a crocodile while it's eating you.

...haggling over the difference between CA and PA is equivalent to arguing about whether a carnivorous reptile is an alligator or a crocodile while it's eating you.

...or it potentially might eat you. :notme: