We are a little stuck in our work with iso 9001 concerning 4.14. All help is greatfully accepted.

What exactly are you stuck on?
do you have any kind of corrective or preventive action system?
How are problems reported and fixed? How about what you do after finding and dispositioning nonconforming product? is there a next step researching a cause? investigating/tracking how often the problem occurs or if it reoccurs, similiar problems in the same place?
Do you have a supplier corrective action system?

I'd love to help, but help me out with a few more details.

Johan,

I wrote something about a week ago in the QS9000 forum under the topic of Continuous Improvement Techniques that may help you out. I am assuming that you are having difficulty understanding the element and not having difficulty deploying CA & PA. Give that a look for greater detail and for a crude case example. Otherwise, here is a thought or two.

Corrective Action: Actions taken to eliminate the root cause of an existing nonconformance and to prevent its reoccurrence.

Preventive Action: Actions taken to eliminate a 'potential root cause' to a potential problem that has not occurred.

The element (4.14) requires that you identify areas for both within your organization. The CA portion deals with items such as customer complaints received, nonconformances uncovered as part of internal quality audits, or received incoming materials not meeting specifications for example. These problems exist in the here and now and require corrective action to prevent their reoccurrence. What do you do to correct the issues and how do you document what you did? Did it work (close the loop)? Do you review this as part of Management Review?

Preventive Action is a more difficult idea to grasp for most (maybe because we tend to put out fires rather than prevent them) and can be accomplished in various ways. I like to think of it this way. If a process or system is in a state of statistical control, does a problem exist? Sometimes but not always. There is natural variation in any process or system, but their output may not meet our desired expectations. A process not meeting our expectations may need refining, bu not necessarily correcting. We often think something 'must' be wrong when we don't get the results we hoped for. There is a significant difference in a process not meeting expectations and a process not producing to specification. This misunderstanding of system output usually leads to a landslide of issuing Corrective Action for every problem encountered. Does your organization make defective products occasionally? Mine does. Should I create a Corrective Action Report for each defective product especially if some level of defects is to be expected (the system will never produce zero defects)? No. Doing so would bog down the CA process and creates another set of problems (missing CA reports, CA reports not filled correctly, duplicate CAR for the same problem). Not all problems are Corrective Action opportunities. Some are Preventive Action opportunities. This example is more typical of a Continuous Improvement process with Preventive Action ties. Give thought to which situation you have and take actions commensurate with risks encountered. I hope this helped.

Kevin,

You have covered the aspects very well. I generally use this when describing the difference between CA and PA.

Corrective Action: Putting out a house fire after it has started.

Preventive Action: Observing conditions that may start a house fire and removing them from the system.

Regards,
Don

Don,

Better said with your few words.

I've come to explaine the difference this way:

Corrective Action: Resolving an actual cause that exists in direct relation to the problem.

Preventive Action: Resolving potential causes that exist as a symptom of the problem.

With corrective action the cause is known and addressed directly, with preventive action only the potential is known, so you address somthing that could occur rather than that which is occuring.

I would agree with what Leslie said. Taking it further, I would put it thus:

Putting out the fire in the house is action on disposal of non-conformity.

Ensuring that safety systems are installed in the house such that the house does not catch fire in future is Corrective action.

Ensuring that the barn or the car or the office does not catch fire like the house did, and taking suitable steps for that is Preventive action. Ensuring that flooding or electrocution or such hazards do not take place in the hose even though they have not occured, is Preventive action.

------------------
Ram
Bangalore, India

This is my first posting, as I just "stumbled" upon your site this week. Knowing that you probably have covered this in the past, I am looking for help in drawing the distinction between corrective action and preventive action. Our organization (engineering in the telephony industry) uses process documents and thus has flow charts within each of our process documents. We have just been advised that we need to insert a (new) Corrective & Preventive section into each of our processes.I want to take the approach that tells them to look at the flow chart. What can go wrong? What do you do to "fix" it when it does? (Corrective) Once you have "fixed" it, what measures do you take to stop it from happening again? (Preventive)
Does this make sense? Is it consistent with the ISO9000 standard? (We are registered to 9001) Is it too simple an approach?
Thanks.

------------------

John,

First of all, welcome to the Cove.

Your observations regarding the flowchart approach seem relatively straightforward and should not present a problem. Your definitions seem within the intent of 4.14.

Regards,
Don

Why do you need to insert corrective and preventive action into each of your processes? Can you document it on an as needed basis through your corrective action process?
I, too, am still confused with preventive action. I understand the concepts but have trouble deciphering between the two and don't know how I am going to have documented proof of preventive action when registration time comes. I know we do it. Maybe I need to analyze things we do for preventive actions and keep a separate file?

The thing about preventive Action is that nearly everyone does it, but 99% don't document it well.

I have difficulty seeing how you can put that into an existing process. AND I use process flow diagrams ALL the time. Seems to me, if you can predict it, then its corrective action (poka-yoke) not preventive. I see that fitting nicely into a flow diagram, but preventive is yet another animal. Preventive is many things, your process engineering group does it all the time I bet. As do task teams and all good managers. AND the best to capture is the operator level stuff.

Some registars just tell you PA is a long term fix to correct the root cause, and CA the short term to fix the problem at hand. That if you do CA correctly, then PA is the result. I disagree, but depending on the registrar I am representing, I have to adjust that a bit.

As a consultant I approach it for the prevention of potential issues...a common sense approach that leads you onto the path toward Continuous Improvement.....which now will fit nicely into the '2000' revision, even though I have been doing it for years. CA still addresses root cause of issues at hand.

Could we not say:

Corrective Action is a response to a negative event (an occurance),

while

Preventive Action is response to a predicted negative event (has not yet occurred)?

Or is this too simple a definition? I think the definition of Preventive Action has changed over the last 15 years. I learned it as 'things we do to prevent a negative event from happening again'. Now I understand it as I stated above.

Key to differences as I understand them:
Actual occurance of a negative event
-vs-
Predicted occurance of a negative event.

If I was told:
--> ...need to insert a (new) Corrective & Preventive
--> section into each of our processes.

I would point blank ask for an example of what that person has in mind. I would want to know just what their expectation was/is. C&P Section? What is that? What does (should) it contain? Will a system where FMEAs and Control Plans are utilized suffice?

I would, as I say, ask for an example to really pin down (and I personally would document) their requirement and expectations. Come to an agreement on the intent of their request (yeah, I know it's self evident, but I wouldn't let that stop me from discussing it). Then come to an understanding on issues such as implementation time, breadth of implementation (All products? Customer specific products?), and related issues. Develop a project plan and get them to approve it. Then, I guess, do it.

[This message has been edited by Marc Smith (edited 12-31-98).]

John,

I am in agreement with Dawn on the need not to place CA and PA into each flowchart. It seems to me that you would be better off creating one process to deal with any type of CA/PA issue that is referred to perhaps in each flowchart. Otherwise, redundancy will only increase the typing.

You mentioned the "what" that could go wrong and "what to do about it when it does". This sounds to me like contingency planning. As far as the differences of CA and PA, the group sums it up well. There were several postings about a month or so ago, can't remember where, but I will post where they are if I get the chance.

Welcome to the group...

Thanks, everyone, especially for the quick responses. Let me clarify something. I misled you regarding the flow charts. While we have flow charts in each of our process documents, I didn't mean to imply that we were inserting corrective and preventive INTO the flow charts. That is not the case. Rather, we have been instructed to now include a new section of the process document that deals specifically with Corrective and Preventive.

My point was that I had been suggesting to the document authors that they utilize the flow chart as a "stepping off point" for creation of this new section of the process document. Looking at the flow chart, they were to determine what could go wrong, and what they would do to rectify that situation (thus, Corrective) and then they would give some thought to what should be done to ensure that this same problem would not happen again (thus, Preventive).
Does that clarify the confusion that I caused regarding the flow charts?

Using a process flow chart is standard procedure for 8-D and other investigations. I've very 'pro' flow charts. See the 8-D pdf file in the pdf files directory.

I don't know how you'll solve this but please do keep us informed of what happens. I still think we are all at issue over preventive vs corrective. Seems to be a never ending topic subject.

John,

Marc is right, CA vs. PA is an ongoing discussion. Barb raised a good point. Some registrars consider long-term fixes as preventive action (the registrar we have viewed it that way, my organization does not). From my perspective, CA is taken to remedy an "existing" problem. PA is taken to "prevent" problems from occurring. By definition, CA is taken to eliminate cause and prevent future occurrences of a nonconformance (although prevent is used here, it is not a preventive action as it is "an existing negative event").

Flowcharting is a great tool! Keep pushing that point with your document creators. But I feel that the responses you are building in your flowcharts are contingency plans and not CA. Remember, CA totally eliminates 'causes' making contingencies unnecessary (in theory anyway). There is nothing wrong with contingency planning as it provokes a response to an undesired result, and as you will find, most processes and systems will always produce some level of nonconformance. Contingency planning will hopefully control the level of nonconformance, CA will eliminate the cause of nonconformance.

I also think that Contingency Planning points to potential Preventive and Corrective Actions. For example, "if" this occurs "then" this is what we will do. If you know the "ifs", you may decide to plan to avoid the "ifs" (preventive actions). And if the "ifs" exist, you may plan to avoid them in the future (corrective action). Quite a tough read there, but I hope you get my point.

Uh ohhhh. Contingency Planning rears its ugly head... We need a thread on Contingency Planning.

Are you going to start one? We have been kicking this around for 4 months.

I have my name on all too many 'starter' threads. I'll let someone else start it off - Let's just NOT add it to this thread. I'ld like to stay as 'on-topic' as we can.

The definition of Corrective action can be gleaned from clauses 4.14.2a and b where it refers to “nonconformities” identified from customer complaints, reports and records of investigations.

Preventive action is in 4.14.3a where ‘appropriate sources’ (shall) be used to detect...’potential’ causes of nonconformities.
This seems pretty straightforward to me but there might be some confusion regards sources of warning about potential nonconformities in 4.13.3a, eg; What sort of customer complaint indicates a “potential” nonconformity, rather than an actual one?

Well, one example would be where a customer has a problem, but it is not clear if it is our equipment that is failing. At this stage it is ‘potential’ and we would implement 4.14.3a looking for relevant evidence.

If our records gave a strong indication of potential causes, we would probably then flip over to 4.14.2b action to pin it down. (Note that in ISO 9002, corrective action includes investigation of possible causes which might, logically, be said to be only potential causes. In practise, it is better to make assumptions and act as if you know the problem is down to you, otherwise the argument as to who is at fault would go on for ever like the CO2 issue in the ecological summit in Rio, and no-one would do anything. Once again, the guys who wrote the original wording can be seen to have got the balance just right.)

In the general case, though, I believe that Corrective action is a response, just as it is laid out in the clause, but that Preventive action is an ongoing, positive and deliberate search for trouble, where you don’t have reason to suspect there is any. The only confusion in my mind about this is where do I put my ‘Continuous improvement’ process. Is it here in 4.14.3 or is it in 4.2.3 Quality planning?

Running towards the smoke with a bucket, is not ‘preventive’ action, even though I haven’t yet seen the fire. Niether is shutting the stable doors after one horse has bolted. That is correcting an existing defect to prevent the rest of them bolting.

rgds, John C

Yuppers - U R right.

Corrective Action is a Response to a problem.

Preventive Action is Predictive (a problem *may* occur).

[This message has been edited by Marc Smith (edited 02-21-99).]

I see symantics has reared its ugly head again. My experience with preventive, predictive, and corrective has seen many uses in many places in many companies. I have seen final inspection used as preventive action. Someone tried to tell me once that having an escape route in my home in case of fire was part of "Fire Prevention." To me, that's fire "contigency."

With regard to "Corrective Action," my take is that it is usually the result of a customer complaint or an internal finding. First comes "containment," not letting the finding escape. Next comes the corrective action, which "fixes" the occurrence of the issue, after containment activities. If the fire marshal inspects my house, and finds that my last escape route plan was not possible due to an addition to my house, I would "Correct" my escape route. Finally, prevention. Prevention is not allowing something to happen. This is applied to the specific occurrence, and then usually applied systemically, and involves change. Other like products or circumstances could have the same issue, change the system to not allow it to happen. Review of FMEAs, other process flows, etc is usually involved. That system may be that design development work needs enhanced, manufacturing processes need brought on better, customer input needs to be visited more frequently, whatever.

This is my 2.0 cents on this.

Batman:

For the sake of simplicity - do you agree with my last post? I think we're saying the same thing.

Not sure. I usually associate Predictive with either design facet or process development, and with things that you know are going to happen, as in predicting the future. I usually try to keep corrective and preventive together when talking about both together. Obviously there are corrections to systems that happen all the time, and prevention activities that also go on. It can get muddy, as in I PREDICT that this part will fail, this I will CORRECT the precess by installing XXX device therefore I will PREVENT that from happening. It is all in the terminology. That is why I like to speak of corrective actions with preventive actions. Both are reactions. Corrective is fixing something after it happened (which may eventually become the prevention.) Prevention is before it can happen again by not letting it happen again - usually a step beyond the corrective action. Also, in another light, corrective actions can usually be implemented by the folks close to the process, preventive actions are usually "Upper Management" responsibilities. Additional training, new equipment, etc are usually in the hands of management.
Anyway, this in part is how I handle explanations with my folks as to which is which.

Thanks for reviving the topic. We have recently been (once again) hashing this subject around, and another question arises. If you insert a corrective into a process document, does it not require the revision of that document (and its flow chart) to include the corrective? That sounds confusing, I know. Let's try again: Once you identify a corrective to a process, aren't you then going to take the necessary steps to install that corrective? But, if you do, then it will require revision of the process, and will no longer be a corrective, but will become part of the process. That means that it disappears from the corrective part of the process document. Now, you no longer have a corrective in your document.
I sound like a cat chasing its tail, don't I?

OK John, I'm off my soapbox. It appears you are trying to link a corrective action to your process docs. I have indicated on level 2 or 3 procedures in the revision page the change to the procedure due to the corrective action. You will have some record of the problem solving effort or other method of discovery that indicates the need for the corrective action, and of course you may also have the PPAP that was the result of the process change. Other than the procedure for accomplishing corrective actions, I don't put any corrective actions in the particular process instruction. I son't think you could, until you know what needs corrected.

If you are asking about normal process adjustments, that is, when a process goes out of control for example, those instructions would be in the process instructions. Note that I said "adjustment" and not "correction." Again, semantics dictates using verbage consistantly. In the past some of these "quality" words were used in different contexts by different folks, and confused many. That is why I have a dictionary in the Level 2 for these global terms. For the benefit of the auditors, I also included in the Level 3 a dictionary of terms common to our facility that could confuse someone from outside.

Hope this helps.

New to the board, but I think I like it! Thanks Kevin!

Now for my 2 cents worth.

We just had our ISO audit on 2/5 and the auditor and I had a lengthy discussion on CA vs. PA. He even brought his glossary of ISO terms. It is referenced in ISO 9002, but not directly stated.

Corrective Action prevents a RECURRANCE
Preventive Action prevents an OCCURRANCE

Get it? If it has already happened, then you must correct it. If you see that something MAY happen, but hasn't, then it you would try to prevent it from happenning.

The main problem with presenting potential preventive actions to management, is that the results are hard to verify. How do you tell if your PA worked? Did the thing you were trying to prevent not happen because of your action, or in spite of it? Most benefits of PA are intangible, and hard to quantify. Thus, hard to justify to those who are spending $$ on it. The main advantage to most PA is peace of mind. A warm fuzzy feeling, etc. etc.

There, I feel much better!!! How about y'all?

Kim

Kim,

Corrective Action prevents a RECURRANCE
Preventive Action prevents an OCCURRANCE

Yea, I usually try to put it like this:

Corrective: Putting out the house fire after it started.
Preventive: Taking action to stop the fire from occurring in the first place.

For example, Are there oily rags in the garage. Remove them and that is preventive.
For example: Do you have a fire alarm? That is corrective. Get out of the house (quick) after the fire has started.

The main problem with presenting potential preventive actions to management, is that the results are hard to verify.

Assuming that results are achievable, verifiable and that you can prove it, management (normally) still has trouble accepting it. That is called the ‘What’s in it for us,’ syndrome. Been there, done that. Really sucks.

BTW, welcome.

Regards,
Don

Oily Rags. Hmmm....

Taking out the oily rags is, in my opinion, a preventive action. Now can I assume that by not taking them out, the facility may burn down? Why not. In terms of risk or replacement being high or costly to an organization, then you may have an arguement on "potential" $$ saved, even in extreme cases. By not taking preventive action here, you leave your fate to the role of the dice. Is this how management wishes to manage, by hard dollars alone? Foolishness! So how can you quantify for the bean counters your savings, justifying your position? If you get to this position, then common sense eludes those who control.

As another point, the "what's in it for me/us" club can go pound sand! If you can't do the 'right things' when you know that they're right, you've got a problem. Challenge a decision? Of course, so long as your challenge is in the best interests of everyone involved, and the organization, or to determine if the decision is well thought out. Each in measure.

Don,

I guess I need to put Sun-Tzu on my list of reading.

Will business ever figure out that most of the costs are infact, unknowable? Everything must have a price tag on it to be valid. What hooey! Take the FMEA process. Now this is a great preventive action process (risk analysis) tool. Now when you rate severity a 9 or 10, how much $$ will be spent on legal fees and liability payouts? How about the ill will of the customer (or do you care)? Could anyone know? So why not just fix the problem? Or should you go back and rate it an 8 and avoid doing anything? When an organization begins to play this wishy-washy game, integrity is lost and renders all you have done useless and invalid. What I see, too many times, everyone is looking for the easy highway to the land of riches. For this, you need innovation and a short-term, get-in-get-out plan because in the end, you tumble and fall quick! Wouldn't want to loose all your profits, do you? Otherwise, the path is difficult, especially alone. So as one, there may be little you can do. But as an organization, the odds get better. Enough of my ramble here, time for others to unload.

Back to the group......

Everything must have a price tag on it to be valid. What hooey!

Yea, Kevin. I agree. If only most understood that most things do have a price. They just do not realize it. That particular line from Sun-Tzu I used a lot at a previous employer in Florida. I learned then that in order to ‘win’ a discussion, you must be able to choose the time and place and circumstance in which to discuss it. Sun-Tzu came in real handy for that. As it turned out, I was fighting a loosing battle from the BEGINNING. The company was running on the bottom line because the parent was trying to sell it. As it turns out, that particular company was sold and now no longer exists. Really sucks.

When an organization begins to play this wishy-washy game, integrity is lost and renders all you have done useless and invalid.

Unfortunately, honor seems lost on most modern types. In order to be effective in battle, honor, above all else, must be followed. Therefore, when ‘wishy-washy’ comes into the picture, any preconceptions of honor are lost. ‘Will business ever figure out that most of the costs are in fact, unknowable?’ Yes, they are. The problem is, many do not know how to determine these costs.

So as one, there may be little you can do. But as an organization, the odds get better.

Ain’t it the truth.

Regards,
Don

Is this how management wishes to manage, by hard dollars alone? Foolishness!

Foolishness? Agreed. Is this how? Seen it all to often, sadly.

Challenge a decision? Of course, so long as your challenge is in the best interests of everyone involved, and the organization, or to determine if the decision is well thought out.

Agreed. But also: “One who knows when he can fight, and when he cannot fight, will be victorious.” Sun-Tzu

Regards,
Don

Don,

Interesting point : " As it turned out, I was fighting a loosing battle from the BEGINNING. The company was running on the bottom line because the parent was trying to sell it. As it turns out, that particular company was sold and now no longer exists. Really sucks." Running the bottom line, or as I term it, the game of "fluff the numbers". Do nothing to improve the quality of product, the system by which it was produced, and sell no more than the year before. Can you show this to the stockholder? No. The holder already expects to make a profit, can't bare the down side. So, in come the Financier's with solutions to inflate the numbers to give the illusion of success (stop right there, why the need for smoke and mirrors?). Let's load a bunch of trucks, fill them with product, show on the books the product is sold, ship it out, take it back eventually and put it back in the books as usable inventory. Wait three months, and do it again. Bravo. What a plan. Just think, ship out a little more each quarter, and show the holder a positive yearly trend. Bottom line: no improvement! Nothing new here I know, but I mention it again anyway.

Sad, you had the ability to improve a bad situation, perhaps help save a sinking ship. But the powers that be (or had been) had other ideas. Well, I hope the organization you are with today realize your present commitment and future potential. And perhaps you have a bit of job satisfaction to go along with that? Now how did we get here.......oh yeah, CA and PA. Should end this on a good note. Let's see......how about Risk Analysis. Anyone using this process as part of their PA program (I know you are Don)?

Back to the group...

I thought we had killed this prevention/correction issue but I can see thing is back on it’s feet again. Need give it the other barrel;
Batman; You say you predict a part will fail. Are you a medium? Presumably not. Do you predict that good parts, within their MTBF, will fail? I don’t think so. So your prediction has to be formed on the basis of some observed defect. So you take corrective action and remove that defect. It is corrective, not preventive. The reason you see preventive and corrective as being so close as to be hardly distinguishable is that you are not differentiating between cause and effect. We are dealing with causes.
Don, Kim, Kevin; Removing oily rags is not preventive, it is corrective. The oily rags are the defect so you correct it.
Kim, You say that preventive action prevents an occurance. But we are not talking about putting out fires. That’s too late - the fireman will do that. We are talking about discovering and dealing with causes. Removing the cause is corrective. Always corrective.
So, if all dealing with nonconformities is corrective, you can only take preventive action before you find nonconformities. Therefore preventive action involves detection.
Don’t take my word for it. Read 4.14.3 “procedures for preventive action shall include......detect...potential causes’. The word ‘detect’ is the only uncommon factor between 4.14.2 and 4.14.3.

No arguement from me, John. I speak better than I type. One of my greatest tests in life is teaching causes v effects. Your text indicates to me you have seen the same thing, the mixing of causes and effects.

Absolutely removing causes is corrective, as in 4.14.2. However, in 4.14.3, preventive actions are to eliminate potential causes of nonconformances. I probably did not say it well, and probably won't again, but that mention of 'potential' is what I meant about predicting. It hasn't happened yet. I mentioned semantics before, and I guess I am guilty of it, too. I try to keep it simple, as we can see just from this group there is a diversity of approaches to what I think is in fact the correct end result - part of the overall continuous improvement effort with respect to 4.14.

The fact that there are obvious professionals here discussing their differences is why I try to simplify these concepts when teaching. FMEA's are a good place to get causes and effects mixed. Most of our suppliers who perform FMEA's have mixed causes and effects.

Frankly, I haven't seen much here in this post that would pose a detriment to any company. I think that doing your best to apply corrective actions and preventive actions in any fashion is better than not doing it at all, even if we differ in a precise definition.

No, I'm not a medium by profession, just an apprentice. But, I think if you look closely, you may see a couple of wizards having a good time.

Yea, this thing never seems to die.

Don, Kim, Kevin; Removing oily rags is not preventive, it is corrective.

John,

I agree in part. In the “Ideal” world, the oily rags would not have appeared in the first place. My POINT was to show that OBSERVATION is the key, not what PEOPLE think the answer is. IMHO, there is no perfect answer. Each organization must choose this.

But we are not talking about putting out fires.

Deming said that putting out fires is not improvement. Preventing fires is improvement. After all, stopping the fire after it has started is not improvement, preventing the fire BEFORE it has started is the KEY.

In other words, I agree with most of what was said.

Regards,
Don

You say you predict a part will fail. Are you a medium? Presumably not. Do you predict that good parts, within their MTBF, will fail? I don’t think so. So your prediction has to be formed on the basis of some observed defect. So you take corrective action and remove that defect. It is corrective, not preventive.Ummm, well, sorta. Situation: Current production. We are in a 'team' meeting of production staff. We review certain process data and see some patterns. We see no evidence of a 'defect', only data which we review every meeting. We decide that it is evident first shift production is not as efficient as second shift. Here, with NO DEFECT PRESENT, we PREDICT there is a difference which, if we can identify cause, may allow us to improve first shift through-put. We have acted on other issues and decide to take on this issue. We form a team, investigate, find th cause and act. We do not have to be 'mediums' to predict. In fact, we all do it every day.

4.14.3 b cites measureables and says you must look at this data and analyze it. Note that it cites "...appropriate sources of information such as processes and work operations..." which is current production. This means you must make PREDICTIONS based upon the data at hand. There does not at all have to be a specific problem (how do we define PROBLEM?) or defect to make a prediction and there is no bearing on the planning stage - we are in production and have been for a year.

The latest ISO9001:2000 draft is reworded and 8.4.2 starts out to say:
"The organization shall establish a process for eliminating the causes of potential nonconformities to prevent occurrence."

I take "...eliminating the causes of potential nonconformities to prevent occurrence." to indicate that no problem or defect has yet to occurred.
Kim, You say that preventive action prevents an occurance. But we are not talking about putting out fires.Welllll - you are mixing this up, maybe. There is no fire yet which is why it appears to be preventive (we all know about oily rags and spontaneous combustion). The problem is in part due to the example. If you spot oily rags and it is a 'problem' (safety issue), it is akin to a defect and your reaction will be corrective.

I stick with my earlier 'definition':

Corrective Action is a Response to an observed problem / defect.

Preventive Action is Predictive (a problem *may* occur based upon analysis of data).

You say: So, if all dealing with nonconformities is corrective, you can only take preventive action before you find nonconformities. Therefore preventive action involves detection.Nope - I disagree. Preventive action does not involve detection. To detect something there has to be something (a defect?) to detect. If it hasn't happened yet, you can't detect it. This is precisely why I say it is predictive in nature.

And Preventive Action is a big part of Continuous Improvement. I also see Preventive Action as a current production issue unrelated to the planning / design phase.

Last - if you want to say that in preventive action you are REACTING, it is a reaction to data. I see this data. It tells me a problem might occur (I am PREDICTING as no problem has yet actually occurred - I just believe, based upon my background and experience, that there is a 'hole in the system' so to speak). In this sense, yes - both are reactions. But you are also reacting to data and experiences in the FMEA stage. So - "How do you define the word 'reaction'?" and when do you use it?

Nuff said here - I'm in a hotel in NY and I gotta go beddy bye. Long day tomorrow.

i am with you Marc.....you are right on....

I understand the fundamental tool for corrective action is cause analysis. In order to remove causes it is necessary to change the process. The changes should prevent falures to happen again in the future. Corrective action is triggered by an event in the operation of a process, but it causes us to review process and product design.

In preventive action, we are dealing with things that didn't happen yet. The fundamental tools are PDPC (process decision program chart) and FMEA. Thus preventive action is triggered while the product and/or process are in their design phase.

Whew! What's that ol' saying about being careful what you ask for...you just might get it! The discussion thread has gotten a little deep for this poor soul, and (to my inexperienced eye) still remains murky. I guess that I was hopeful for a clear-cut distinction between Corrective & Preventive, but it seems to be very subjective, based upon the responses from the professionals.
We are still on the path of correcting what we find to be wrong, then (if we can) built that corrective into our process to act as a preventive against that happening again in the future.
I do agree with Batman's comment about doing your best with corrective and preventive being better than not doing it at all, and our group can point to efforts in this direction.

Corrective Action is a Response to an observed problem / defect.

Preventive Action is Predictive (a problem *may* occur based upon analysis of data).

Right on the money, Marc.

While in the military (many moons ago) we had preventative maintenance scheduled at various intervals during the week, to prevent problems that *may* occur based on experience from the past operation of the vehicles concerned...things such as checking the battery fluid levels (before maintenance free batteries-am I dating myself or what?)to name one.

When, during the course of this preventative maintenance we found a need for the fluid, it was added as a corrective action and annotated as such.

Well said all, on the above comments.

------------------
Dusty Rhoads
(Chief Dummy)

Not to worry, Marc...gov't just came out with a report saying it isn't addictive as they thought and it does have medicinal value...preventative or corrective??? Eee-gads, matey!

------------------
Dusty Rhoads
(Chief Dummy)

Marc, ‘Local Wizard.’ You are too kind.

Meanwhile, back at the ranch...

I guess that I was hopeful for a clear-cut distinction between Corrective & Preventive...

I have always hoped that a distinct difference would exist, but that is a vague assumption. Marc’s definitions are very good and work in the majority of applications. Predictive goes very well with preventive. For example, APQP (or whatever) could be used as objective evidence that preventive action is a part of the Quality Management System. In the medical device world, risk analysis (in whatever form) is very good objective evidence of preventive action.

To detect something there has to be something (a defect?) to detect...

Agreed. To go back to the ‘oily rags’ example. Oily rags are not a defect (disregarding the obvious safety issues). But, the potential for a fire is a ‘predictive’ effect. Therefore, removing the oily rags would be (may be?) a preventive action. I readily admit that the ‘oily rags’ is not the best example to use, but I thought it might illustrate the point. Perhaps it just muddied the water.

...the definition is definitely blurred...

Agreed. But, this thread is getting rather long, so perhaps this is better saved for another. Just a thought.

We poor, demented, fermented old men often are....

Ain’t it the truth, Ain’t it the truth. For me, particularly the old part.

Just some ramblings from an old warrior.

Regards,
Don

I think most of the 'disagreement' here is in how we interpret some words like REACTIVE. I called Corrective Action REACTIVE. One can also say that what one does in response to findings from analyzing data is REACTING to the data - and to some degree I agree. But I tend to want to use the word ACTING on data rather than REACTING to data.

I particularly liked:
I understand the fundamental tool for corrective action is cause analysis. In order to remove causes it is necessary to change the process. The changes should prevent falures to happen again in the future. Corrective action is triggered by an event in the operation of a process, but it causes us to review process and product design.

In preventive action, we are dealing with things that didn't happen yet. The fundamental tools are PDPC (process decision program chart) and FMEA. Thus preventive action is triggered while the product and/or process are in their design phase.Citing the tools provides a clarifying look at what we're dealing with.

I use the word PREDICTIVE with PREVENTATIVE as that's how I learned it. You PREDICT possible problems and their causes.

I have a problem to some degree with the relationship of Continuous Improvement and Preventive Action because they are so closely related. I guess what I mean to say is I believe these confuse folks as well. I see Preventive Action as one of a sub-set of things you to for Continuous Improvement.

If I start a thread on Continuous Improvement (or revive an old one...), will anyone come? (If a tree fall in a forest, does....?"

OK! OK! John, I understand your dilemma. I think the definition is changing.

When I first learned of Corrective and Preventative Actions some years ago (mid 1980's) the paradigm was that Preventative Action was a follow up within Corrective Action. Preventive Action, I was taught, was "How do you stop that defect from getting out if, despite 'fixing the cause', it actually DOES happen again." This might be what is now known as Poke-Yoke - install a sensor to catch the defect. An example might be where a machine is supposed to drill a hole and it doesn't. The corrective action would be to fix the immediate failure mode (in this case, let's say a drill bit broke) - replace the drill bit. The Preventive Action might be to put in a sensor which checks for the hole and, if the hole is not present, stops the process equipment so that it is (theoretically) impossible for a mis-processed part to pass on to the next operation. A visual inspection would also have been a Preventative Action back then - the old "There was not an inspection point so put one in" before sensors were as cheap and easy to get as now (Ah! Technology in the 1970's and 1980's as compared to now. Heck - PCs have only been around for what - 16 years? 18 years?)

Since that time Continuous Improvement has come on the scene. Preventative Action has taken on a fuzzy meaning. It used to be a Preventative Action was in response to a specific known problem or defect. It was part of what became FORD's 8-D methodology but I knew it long before as just a Corrective Action Response in the military manufacturing arena. Containment wasn't known as containment back then, either, but we did the same Nonconformance-Corrective Action system.

Ok. OK! Maybe it's me. I now think of Preventive Action as part of the Continuous Improvement system. What I used to know as Preventive Action is now (or seems to me to be) just part of the corrective action process.

Ford had Prevent Recurrence training in the 1980's and it dealt with addressing a specific problem cause but heavily addressed Root Cause. I knew of Root Cause from military manufacturing so that didn't surprise me as far as a methodology goes. A number of times I had to go before some military hulks and explain what I did about the ROOT cause when there was a nonconformance. This may have been where the drift started for me. Instead of preventing the part from passing to the next operation, the mantra was where did it start and how do we correct THE ROOT CAUSE' which was generally in planning (design) phase.

It seems to me now when you look at the ISO words they are using Preventive Actions are no longer an exclusive element (per se) of the Corrective Action reaction. To me they are reading into the Continuous Improvement aspect (looking at data and predicting places to improve). Look at the end of 4.14.3 a where it says "...eliminate potential causes of nonconformities." The word potential (to me) throws it to an open arena as opposed to a reaction to a specific event. What I used to know as preventive action is now covered in 4.14.2 d where it says: "application of controls...". The assumption seems to me to now be that the corrective action include what I used to know as preventive action - keeping that specific problem from occurring again and placing a control to ensure if it somehow does it is detected as close to the source of the cause of the problem (defect?) as possible. We should note that althought 4.14.3 a states POTENTIAL, 4.14.3 b, c and d alude to an existing problem - specifically 4.14.3 b: determination of steps needed to deal with any problems requiring preventive action." What does this tell us?

Again, let us look at 4.14.3 a where, near the end of one long sentence, it says: "...to detect, analyze and eliminate potential causes...". To me this is saying you will monitor things (data) and use the data to 'detect' (which conflicts with potential) potential (which conflicts with 'detect') causes and you will do this not in response to an event, but in as a part of every day life on the farm. This is why, with regard to ISO, I class Preventive Action as PREDICTIVE. I'll admit you can link POTENTIAL to an EXISTING problem. I also read it, all words considered, in a predictive sense. Maybe I'm way off base.

So - is Preventive Action only in response to a problem? How does the word POTENTIAL come into play? Does the phrase DETECT POTENTIAL confuse things? Could they have worded this more clearly? Where in the world is Carmen Santiego? Can you find Waldo in this picture?

There are a fair amount of professionals here and, as is evident from responses, the definition is definitely blurred. You are in good company.

How can you handle it? Just make clear (if possible) definitions in your system as to how you categorize it and describe it. Choose your words carefully!

John: You have excellent points.

Comments anyone? Tell me if I'm off base. We poor, demented, fermented old men often are.... Too much pot in the 60's probably didn't help much, either.... And then there was that big party.... Things just haven't been the same since.... Having said that, yes - I inhaled... Maybe more than once.... Maybe not. Probably maybe. But maybe not. I forget. What did you say???

[This message has been edited by Marc Smith (edited 03-17-99).]

Marc,

You say; “Nope - I disagree. Preventive action does not involve detection.”
But it does. It says it in 4.14.3a. Does anyone read the Standard? Or have I a different copy from everyone else? (I’ve got ISO 9002:1994. If that isn’t the latest rev then apologies all round.)

But I’m only pursuing this so as to develop a sound basis so that I can teach people and deal with sloppy registrars. (I feel I am going to have some difficulties) But we do agree on the important things:

Preventive action is prediction. It is detection and it is continuous improvement. You mentioned starting a new string; As I said in my original post on the subject; I don’t know where to put ‘continuous improvement’. Is it here in 4.14.3 or is it in 4.2.3 Quality Planning? That’s probably a good starting point. I would certainly like to see a discussion on Continuous Improvement because it’s my favourite subject. I’ll send an opener.

Just for interest; You mentioned you were taught corr. preventive. action differently. Well I have here BS5750 Part 1 1987 - almost certainly worded identically to the orginal ISO 9001. There is no preventive action section. Only 4.14 Corr. Action and it includes;
“4.14 b) analysing all processes, work operations, concessions, quality records, service reports and customer complaints to detect and eliminate potential causes of nonconforming product.”

That, for me, is preventive action. And it has been lifted out of Corr Action and made Preventive Action in the latest version. The latest is less clear, less precise, less sensible, but that is inevitable since the engineer’s original wording has been taken over by bureaucrats. When we start arguing about ISO 9000:2000, then we will have some Herculean task.

Hope to see you all in the ‘Continuous Improvement’ string.

rgds, John C

You say; “Nope - I disagree. Preventive action does not involve detection.” But it does.I'll agree it can.
It says it in 4.14.3a. Does anyone read the Standard?You may not have noticed, but in several messages in this thread I cite and quote verbatum ISO9000:1994 including 4.14.3a - several times.
But I’m only pursuing this so as to develop a sound basis so that I can teach people and deal with sloppy registrars. (I feel I am going to have some difficulties)You'll have to do what I do. I make sure that everyone understands that there are differing interpretations. In fact in my last 8-D course I prinred out a couple of threads from the forum on CA & PA and included them in the course notes binder. I started out the course addressing issues of conflicting definitions and have the students read thru the thread so that everyone is well aware of differences in interpretation. The best way to do this is to recount the history, discuss the verbiage and go on from there.
Just for interest; You mentioned you were taught corr. preventive. action differently.
[quote]Well I have here BS5750 Part 1 1987 - almost certainly worded identically to the orginal ISO 9001. There is no preventive action section. Only 4.14 Corr. Action and it includes;Yes - I am sure. In the 1980's in military manufacturing I learned of preventive action within corrective action. The automotive world has popularized and isolated 'preventive' in their own light - and the definition is changing. ISO does consider QS9000 in its developmen t(more now than then, but none the less)... I never did work with BS5750 and, in fact, have never seen a copy of it. Just more evidence of the 'drifting' definition of Preventive Action.
The latest is less clear, less precise, less sensible, but that is inevitable since the engineer’s original wording has been taken over by bureaucrats. I don't know how much of a part engineers played in the early development of the standards. I think it may be more of an issue of trying to address different 'sectors' (chemical, automotive, etc) with one document.

The bottom line is the definition at this point in time is blurred. If you ensure your students understand the situation and the range of definitions, I dont see a problem.

I ensure my students understand this. As far as clients for registration I could care less about the definitions. I ensure my client is addressing issues correctly and that has nothing to do with the definition of Preventive. Proper CA investigations, including Root Cause and appropriate 'controls'. An appropriate planning stage as is appropriate to their operations and whether QS (APQP) or just ISO (which allows more latitude as in not requiring FMEAs for an example). Continuous Improvement - there are a number of elements here, one of which I will include is PA. Never had a problem during a registration because no matter how you define Preventive Action, if you're doing all the things required you can put the label where ever you want to.

Marc,
You now agree that Preventive action “can” include detection. Well in 4.14.3 it says that it “shall”, which is totally different from “can”. If we were allowed to replace “shall” with “can”, wherever it occurs in the Standard, then the document would be worthless. We can’t go around making up our own “interpretations”. Even more important, we can’t go round saying that the standard says things that it clearly does not and calling it ‘interpretation’.
Interpretations are not in the interests of industry. They are the tools of self interest.
They are also a nonsense. They cannot clarify the message, only confuse it. If, as you say, there are several interpretations for this section, then there will soon be hundreds. But I don’t believe there are any. The words are simple. They mean what they say and are available, officially translated, into most people’s native language. Instead of continually going on about the need for interpretation, I would like someone to show me one case from 4.14.3 where there is any ambiguity. I doubt I’ll hear from anyone with an example. It’s only about 60 words. Try it.
I hope I don’t hear from anyone with ideas about how the clauses are met. For example; deciding what is ‘appropriate’, is not interpretation. There are many opinions as to what is appropriate, but only one meaning for the adjective ‘appropriate’.
Our first responsibility is to give engineers and managers good information, from which base they can go ahead and design their process. If we give them bad information and muddy the water for them, then we do them a disservice and take their money for doing so.
If we tell them there are three interpretations of a clause, then we leave them vulnerable to the next chancer who comes along with a fourth one.
If we tell them, there are lots of chancers out there who would like to use various interpretations as leverage for their own ends, and that they should read the standard and stick to what they see, then we have done them a service and not left them in the dark.
I’m on the side of industry. I support free trade.

Questions on oily rags: how were they created? Were they caused by a leaking valve? Or were they created by normal clean up? In one case it is a symptom of a root cause, the other, not even a nonconformance in my opinion.

Kevin, your last remarks about the oily rags is thought-provoking.
I wonder: If they were part of "a normal clean up", then shouldn't there be a procedure for discarding oily rags so that they do not become a fire hazard? And, if there is such a procedure, wouldn't that discard of the rags be preventive, that is, to prevent a possible fire from occuring?

John,

I don't know if it would be necessary to detail the Program to the Nth degree, i.e. making coffee, oily rag disposal, but that largely depends on the nature of the organization. I agree that by making it (oily rag disposal) part of your program you reasonably identify this as a preventive action. If after creating the program, a fire does result, then you would perform corrective actions to rectify the situation. It could then be argued that you did not do enough to prevent the occurrence, i.e. proper training though the program is still proactive (a point Marc made), the system was ineffective at least in this case.

Back to the group...

[This message has been edited by Kevin Mader (edited 03-19-99).]

John:

I used the word 'CAN' to denote that PREVENTIVE ACTION 'can' be used to address issues from a corrective action, however I'm trying to get across that at one time that was its provence but now it is not. Preventive Action is now expected all the time - NOT just for the tail end of a corrective action. When I 'went to school', preventive action was not an every day thing. Data acquisition was not like it is there days and such.

So - the tail end of a corrective action *shall* be preventive action, however preventive action is an every day thing, going on all the time in one way or another and not just in response to a corrective action. This is why I don't worry during an audit about preventive action. More important is root cause. If you 'cure' the root cause, that 'defect' or problem should not again occur. That said, Poke-Yoke or other 'preventative' measures will not be as important. I don't know - one might even consider finding Root Cause preventative.

This is why Bill Clinton asked the definition of the word 'IS'.

I still like this from above: I understand the fundamental tool for corrective action is cause analysis. In order to remove causes it is necessary to change the process. The changes should prevent falures to happen again in the future. Corrective action is triggered by an event in the operation of a process, but it causes us to review process and product design.

In preventive action, we are dealing with things that didn't happen yet. The fundamental tools are PDPC (process decision program chart) and FMEA. Thus preventive action is triggered while the product and/or process are in their design phase.

[This message has been edited by Marc Smith (edited 03-19-99).]

Marc,
I don’t think I’m getting my points across. Whether it is because I’m expressing them badly, I can’t say, but I’m going to have one more attempt, this time by addressing my response directly to John LeBlanc’s query;

John LeBlanc,
Hi. Sorry for not answering you sooner. But we have been teasing it out and now I think I have the right answer;
Within the context of ISO 9001, Corrective and Preventive action are quite different. Obviously if you correct a cause of existing defects, then you prevent further defects. But, this is not ISO 9001’s definition of Preventive action. Why is there a special section? What is the essential difference?
Corrective action fixes causes of existing defects. It is an obvious need, supported by the need to remove obvious costs, customer dissatisfaction, scrap and waste, etc. It is causing pain and someone knows that ‘the buck stops here’.
Preventive action is the real quality activity. The one that really works. The one mentioned as the primary purpose of the Standard in section 1, Scope, and the one in our quality policy and probably on yours.
But ‘preventive’ deals with things that might happen. There is no pain and no cost, yet we are going to take an engineer and put him/her onto searching for things that ‘might’ happen, while there are a thousand things already happening and crying out for resources. And, even if he/she finds some ‘potential’, the cost saving that justifies the investment can not be proven. You can’t prove a negative.
So, although this ‘Preventive action’ is an obvious thing to do, it needs a special section of it’s own because it an action on it’s own, it is not easy to do and it is not easy to measure but it is very easy to overlook or to push to one side and neglect. No one would notice.
So that’s the difference. And that’s why you have to submit it to Management review. Note that Corr Action does not have this stated requirement! Because, if you don’t have it, or don’t report it, it won’t be reported anywhere, won’t get much of a hearing anyway, won’t be appreciated because it doesn’t seem to change anything, yet it is the most important thing we can do.

Note that, before you insert the preventive and corrective actions, you have to decide where to put them in the process. Corrective is obvious since it comes after the process has run. Prevention is earlier, I’d say. It starts before you do something, so as to avoid doing it wrong, but it continues as long as you continue doing that thing as long as you keep in mind the requirement of 4.14.1 to ensure the degree of what you do is appropriate. Don’t keep investigating a process which is well established when you have others which are newer and less understood or where the potential for catastrophe is greater.

Before considering corr. or preventive action, examine the existing process to see that it is well designed, well implemented and effective. Then design in; corr. and preventive action from the point of view of the end purpose of the process.

Finally, go through each phrase of 4.14 and see that everything is covered. If something is not, then don’t just patch it in, look to see why it is not. Maybe it is not appropriate or covered in some other way. Don’t design processes for ISO 9000 or for your registrar.

rgds, John C


[This message has been edited by John C (edited 03-22-99).]

MY REASON OF THINKING ON CORRECTIVE OR PREVENTIVE ACTIONS IS NOT ONLY NONCONFORMING BUT CAN BE PROCESS RELATED.CORRECTIVE BASICLLY BEING PROBLEM FOUND PREVENTIVE BEING IMPLEMENTATION OF PROBLEM SO IT IS NOT BEING A REOCURING PROBLEM SOMETIMES THIS CHANGES PROCESS AND DOCUMENTATION SOMETIMES NOT DEPENDING ON WETHER THIS IS A NONCONFORMING OR WORK INSTRUCTION PROBLEM OR JUST ERROR

Hello Johan

The boys in this forum are getting better and better at explaining complex issues. I learnt the difference between PA and CA via this forum, the registrars that i worked with did not seem to be able to understand it themselves.

You are however left with the question 'what sort of activities can be classified as PA'. I think i would be right in saying that FMEA is a good example of PA. This is an excellent technique which all employees should be taught, even if they use it simply as a structured brainstorming.

In one particular company where i work they do something called a 'Preventive Action Overview' for each product. In this they define what 'general' steps are required to prevent defects. IE

Column 1 Supplier Selection - Are the suppliers certified? Do they have a history of good delivery? Do they need an Audit?
Column 2 Parts Criticallity - Do you need from the suppliers evidence of Inspection if the parts are cirtical?
Column 3 Supplier Contract - Is any special contract with the supplier needed to ensure that they follow certain manufacturing steps?
Column 4 Incoming Inspection - What incoming inspection is necessary inside the company.?
Column 5 What in process and final inspection is necessary?

The whole thing can normally be laid out on one A3 spread sheet, and really is a good quality overview, it encourages your manufacturing staff to think about the quality of the whole product, from beginning to the end, not just at the point they are concentrating on. Its pretty impressive to show to customers, it gives the impression that the whole process is under control.

I think it helps companies to be proactive to do it in this way, however i think it also pretty close to being a 'Quality Plan' but nobodies twigged yet.

Hope that helps


------------------
Andy B

Also see: Elsmar.com/ubb/Forum31/HTML/000013.html (http://Elsmar.com/ubb/Forum31/HTML/000013.html) and http://Elsmar.com/ubb/Forum2/HTML/000036.html

Also see:
Elsmar.com/ubb/Forum32/HTML/000002.html (http://Elsmar.com/ubb/Forum32/HTML/000002.html)

Edited 10 November 2001

I can't re-lookup and change every old link to posts in the old forums. Most of them *should* still be there. If you want to find the post in the New forums, if the link to the thread in the old forums works (most of them should...), look at the thread (topic) title and what forum it is in. Then back here in the New forums - go to that forum and look for the thread topic title - OR - do a Search for the key words from Title (Note - you can search entire threads or just the 'subject' or 'title' - if you look in the Forums search page you'll see the options.

Call me lazy... :rolleyes:

Thanks, Marc.

It might be of interest to know that our company is moving more into Root Cause analysis. I am now involved in facilitating a Problem Solving and Prevention System initiative. In the course of this training, we have been told that (as some of your contributors have pointed out) Corrective deals with addressing a potential recurrance; while Preventive deals with addressing a potential occurance.

Of interest to our discussion, we are told in this training that ALL actions relative to the Corrective activity are to remain Corrective, that is, any steps taken to prevent the incident from happening again are still Corrective, rather than Preventive.

Do you agree with that?

Our direction is to form Root Cause Analysis teams to address internal problems identified by management (middle level) and also to create and utilize a database tool to report the status of the Team's efforts. In doing so, we offer visibility of the RCA effort to all groups within our company. This is intended to support each other and prevent duplication of effort in problem solving.

Andy,
You're my main man! You got it in one! - As they say down here in Cork; "You're a star". Of course, you are way wide of the mark in saying; "The boys in this forum are getting better and better at explaining complex issues". Well, I'll grant that it's usually true and (on the side) I've great respect for them, but regards Preventive Action, they're right off the wall. (If you don't believe me, go back via the link that Marc put up. It's hard reading.)

Everyone is willing to argue about what Preventive Action is but no one will believe me when I quote, directly from ISO 9001, 4.14.3; "the use of appropriate sources..... to detect, analyse and eliminate potential causes". It's not me saying it - it's ISO 9001. Whose boss around here? I say that ISO 9001 is the boss and what he says goes.

Corrective action eliminates causes. It analyses them as well although the word used is 'investigate'. Inevitably, when they 'take corrective action to eliminate causes', this action is preventive.

The only thing remaining to distinguish between Corrective Action, 4.14.2 and Preventive Action, 4.14.3 is the word 'detect'.

Preventive action detects causes. It is essentially a detection excercise; 'Go out and detect (potential) causes before they bite us.' Set up a process to find them.

The word 'potential' is probably what throws people but really, it is irrelevant. You fix the ones you know about but you have to detect the ones you don't. It's that simple.

Don't listen to them Andy! Don't listen! Stick to your FMEA (whatever the hell that is) and your Preventive Action Overview, where you are establishing your 'sources..to..detect..causes', straight out of 4.14.3.
rgds,
John C




[This message has been edited by John C (edited 27 May 2000).]

I saw another discussion going on, kicked off by AJP and this got me thinking again about what Preventive Action is really about and what was in the minds of the BS 5750 guys who first wrote it in as a subset of Corrective Action. Also, what was in the minds of the guys who, between ‘87 and ‘94, promoted it to a section of its own. Note that at this time, the idea of Preventive Quality Control was taking hold. Previously, quality was all about the ‘Quality Loop’ - build, inspect, feedback defect data, fix defects, build.

The internal combustion aero/aircraft engine is a dodo. A dead duck! It’s ok for weekend fliers but not for practical purposes. From a simple and promising system in 1939, it underwent one of the most intense development programs ever and, by the end of World War 2, it was unrecognisable in appearance, complexity and performance as the progeny of its forebears. But it hadn’t grown up to be a gas turbine and no amount of development would turn it into one.

The development of the internal combustion was a Corrective Action process, focusing on product defects. Corrective Action stops and starts and stutters along, going whichever way the wind blows. It is essentially, negative, sterile and limited.

While the development of the engine was going on, Frank Whittle in England and Mr Messerschmidt in Germany were engaged in Preventive Quality and were developing the gas turbine which consigned the I.C aero motor to history. Preventive Quality focuses on the end purpose and on the process, which it breaks down to the minimal optimum. It is ongoing and it embraces all engineering aspects. As a a small but significant bonus, it eliminates defects before they occur. It is positive, potent and unlimited.

So where does this leave ISO 9001?

Well, ISO 9001 has it’s roots in the old quality loop so Corrective Action is at the heart of its being. It is totally dependant upon auditing out defects so, when the ISO guys heard the message that Preventive Quality was the future, they were in a bit of a quandry. In hotels in Geneva, Barcelona, London, Cork, LA and Hongkong, they covened to chew over the problem; How could they reconcile ISO 9001 with the new light?
Well, as you and I know, they couldn’t. Just as the engineers working on the internal combustion engine could never engineer it into a gas turbine, nor could Technical Commitee TC 176 (or whatever), change ISO 9001 from a defects based system. They compromised - doesn’t everyone? - and promoted Preventive Quality to equal status to Corrective Action. But even in that, they made a mistake. Maybe even a terrible mistake, as you will see below.

Fact is, guys. ISO 9001 is also a duck. Its not dead but maybe we’d be better off if it was.

As one who has always defended ISO 9001, you might think I too, have compromised but I always knew it was a duck. I never ordered it when I wanted sirloin with gravy and a good beaujolais.

Why is ISO 9001 a duck?

1) Because Preventive Quality is greater and maybe should have a whole standard to itself.

2) While ISO 9001 does not preclude Preventive Quality, it hasn’t the means to apply it. So it emphasises Corrective Action with the high profile drama of trouble shooting teams pulling the company back from the brink of extinction and resolving problems which they themselves caused. Corrective Action is the easy option and it appears to be cheap. Expensive and low profile Preventive Quality receives lip service from everyone but it just doesn’t get done and ISO 9001 is largely to blame, not because of its own weaknesses but because of general mistaken perception.

Note;

The BS 5750 boys, engineers who worked among the nuts and bolts, wrote in BS 5750, 1987 4.14 b); “analysing all processes, work operations, concessions, quality records, service reports and customer complaints to detect and eliminate potential causes...”

Technical Committee TC 176, in ISO 9001, 1994, 4.14.3 a) wrote; “the use of appropriate sources of information such as processes and work operations which affect product quality, concessions, audit results, quality records, service reports and customer complaints to detect, analyse and eliminate potential causes)

See the difference? In the first, Engineers “Analyse all processes”, ie; they go out and look to see what is going on and, in doing so, they think about the purpose and about new ways to do it. Quality bureaucrats send inspectors to collect defect data and then use that data to ‘analyse potential causes’.

It’s a small difference on paper but a world of difference in practise. A camel of quite a different colour.

Now the crunch time; You were right and I was wrong and anyone who is confused about 4.14.2 and 4.14.3 is dead right to be confused. Also, the guys who describe both sections in terms of corrective action and fail to see the Preventive Quality in the latter, are justified in doing so. The wording of 4.14.3 is an error and it should read ‘Analyse all processes’ because, as it stands, it is nonsense. It should read as I interpreted.

One thing more; The exception that proves the rule; I “interpreted”. Even though I have shouted from the rooftops that we must not interpret ISO 9001, but should read it carefully to see what it says. I didn’t read this carefully but assumed that it said what it used to say back in 1987.

Well, on the subject of ISO 9001, I have been proved to be fallible but, as I say, it was the exception that proves the rule and I will be more careful in future. The Standard, version ‘94, has also been shown to be seriously fallible. I wonder how version 2000 will stand up, now that the bureaucrats have really had a go at it?

rgds, John C

[This message has been edited by John C (edited 29 May 2000).]

"...Of interest to our discussion, we are told in this training that ALL actions relative to the Corrective activity are to remain Corrective, that is, any steps taken to prevent the incident from happening again are still Corrective, rather than Preventive..."

I think we do reach a point where one cannot clearly define an action as all corrective or all preventive.

I think we should stop and go back to basics. The biggest problem with ISO9001 is that it is only a model, being read as a standard or a specification.

The intent behind the words is the issue here. Reading through all the responses, I believe everyone understands the intent, although implementation may differ.

Regardless of the order or the methodology, 4.14 wants the user to follow through after identifying and dealing with non conformance, to not only putting in action to remove the root cause, but learn from the non conformance and also analyse various sources of information (in place of an actual non conformance) to do the same with potential problems.

The ca/pa system can be as complex or as simple as you want to make it, although it is one requirement where I have found even the simplest systems can be very effective in a large organisation.

------------------
Mark G.

See the following related thread: http://Elsmar.com/Forums/showthread.php?t=3179

Hello, All!

One can look at the concept of continuous improvement in practice as a system of two elements: corrective actions and ppreventive actions, can't one? If so, it looks all simple.
A corrective action is meant to eliminate the reason for a non-conformity, which has already occured. It naturally results in an improvement.
A preventive action is a little more sophisticated matter - it is meant to eliminate the reason of a potential non-conformity. The crux of the matter lies in the concept of POTENTIAL non-conformity. What does it mean? Obviously it is a situation when one can forecast a non-conformity:
- if a bad trend remains unchanged;
- if the environment (internal orr external) changes;
...in case no preventive actions are taken.
This above is very broad and liberal concept. It allows describing prcatically anything through this word - 'potential non-conformity'.
- The company needs more equipment (or it lacks production capacities if the tren in sales volume remains);
- The company needs to control some more parameters of a production processes, as the outbound testing shows unstable results, thoughh within the accepted allowance.
- The company needs to educate its employees better (otherwise, with time passing it loses its competitiveness against companies with better educated labor)
- et cetera.
This kind of example list can be endless and endlessly diverse.

So, potential non-conformities can be non-conformities at all - just improvement suggestions.

Isn't it meant so in the ISO 9000 standard, which contains separate paragraphs for Continuous Imporovement, Corrective Actions and Preventive Actions?
Can someone give me an example of an improvement, which is not a preventive action aimed at eliminating a reason for potential non-conformity?

Anton

Your question is somewhat of a conundrum, why would someone try to prevent something unless there was a potential downside?

I think you have answered your own question, not just for quality systems, but for life in general.

Why do I cut the grass every week? Because if I don't, it will grow long and make it more difficult to mow the next time.

Yes, this is a very simplistic example but I think it fits.

Good Post!

Anton, Great question!

And let me take Jim's example a little further.
Upgrading software...the old system may work fine and be error free, but a new version may operate faster, be easier to use. So there is no preventative action here, but an improvement in efficiency. Same idea can be applied to machinery, the old one may work error free, but a newer model may save time in set-up or operation.

Just my nickels worth...
Have a good one,
CarolX

Thanks for your comments, Al, Jim, Carol,

My post, probably was not really "a shot" as Jim says. I was probably validating my own experience. Consulting people not very aware of the quality and even management theory, you always have to find good formulas helping them be motivated to do "the right thing".
In my humble experience I have been using the presented idea to motivate people in client companies to build up efficient continuous-improvement-systems, involving all of their staff as far as it is possible.
One has to know why he has to improve. It sounds banally, however is still a burning question for numerous enterpreneurs and managers, especially in SME's. It is not always persuasive enough to say that simply improving they just do not let their competitors go ahead of them (rather then going ahead themselves). They tell you that they understand it fully, but shall continue sustaining their favorite "status quo".

So, in some cases it is really striking to insist on the fact that any improvemnent is on the other had a way to avoid future non-conformities - or simply - problems.
This makes people think of improvements considering that these improvements have to solve some problems now or in the future. This also can be a base for ranking improvement activities according to their significance and benefits.


Yours sincerely,
Anton

I agree Al a very good post indeed. But for the sake of discussion - I would like to "take a shot" so to speak on this part of it.Can someone give me an example of an improvement, which is not a preventive action aimed at eliminating a reason for potential non-conformity?

AntonHow about:

Upgrade MRP database to include (insert your favorite data here) information not currently available.

a) can we agree its an improvement?
b) And at "face value at least" has nothing to do with eliminating a potential nonconformity

(The use of the new information may lead to future disovery of an area for potential nonconformity, but may also simply be a trend measurable to re-enforce what we allready know -- without involving nonconformity potential.

Regards
Jim

Originally posted by Kevin Mader

I wrote something about a week ago in the QS9000 forum under the topic of Continuous Improvement Techniques that may help you out.That thread is Continuous Improvement Techniques (http://Elsmar.com/Forums/showthread.php?t=346)

A Blast from the Past! Has anything changed?

Let's load a bunch of trucks, fill them with product, show on the books the product is sold, ship it out, take it back eventually and put it back in the books as usable inventory. Wait three months, and do it again. Bravo. What a plan. Just think, ship out a little more each quarter, and show the holder a positive yearly trend. Bottom line: no improvement! Nothing new here I know, but I mention it again anyway.


Happy New Year, Kev. :bigwave: Notwithstanding the lack of scruples, did this work? Does it work over and over? Not bad.......if the loss of the company was the other option.

Sad, you had the ability to improve a bad situation, perhaps help save a sinking ship. But the powers that be (or had been) had other ideas.
Did you or (anybody else) really have the ability? Or do you assume you have the ability to juggle finances. Was time a factor? Maybe the powers to be made the decision to behave that way with the plan to study why they have to do this, from time to time. If the bottom line was, as you said, only "no improvement", in this case maybe it was the right choice. I don't condone it. I would have to accept it as it involves moving assets which are out of my domain. Just throwing coals onto the fire. :agree:

I guess I will add my two cents.

I am trying to get this straight in my mind as well. Here is where I am at. Problem solving for a defective part or process is corrective action. For example, 6 defective parts were replaced under warranty because of paint adhesion loss on a "A" class surface (i.e., paint bubbled and blistered after 6,000 miles of service). Root cause was found to be an operator who left the propane torch flame (used to deflash the molded part) inadvertently "parked" over the class "A" surface for a second causing olefins from the TPO (i.e., plastic) material to rise to the surface making a surface prone to adhesion loss as manifested by paint blistering and peeling after several months of use.

Whereas something such as a potential DFMEA or PFMEA are examples of preventive actions such as when the part or process is modified to eliminate a process step that could cause problems. For example, when the next plastic injection molded part was in the design and pre-launch phase the mold was redesigned to eliminate the need for deflashing with a propane torch. Here is the logic tree: with no flash to remove, no propane torch is required to deflash and, therefore, the operator cannot overheat the part. Hence, no paint peeling blisters caused by olefins being raised to the surface due to overheating the TPO.

Whereas something such as a potential DFMEA or PFMEA are examples of preventive actions such as when the part or process is modified to eliminate a process step that could cause problems. For example, when the next plastic injection molded part was in the design and pre-launch phase the mold was redesigned to eliminate the need for deflashing with a propane torch. Here is the logic tree: with no flash to remove, no propane torch is required to deflash and, therefore, the operator cannot overheat the part. Hence, no paint peeling blisters caused by olefins being raised to the surface due to overheating the TPO.

FWIW...I would consider it Preventive. Could it not also be considered Continuous Improvement of your product/process? I posted this before...I questioned a potential Registrar about the difference in the two. Using your blistered paint example for example Part A, I was told that applying what we learned about the blistering on Part A to other parts was Preventive. Go figure. :ko:

One of our major customers that we do OEM work for has on their "Corrective and Preventive Action Request":

Root Cause of Nonconformance: __________________

Corrective Action Taken: (How will you correct the problem?) _____________

Preventive Action Taken: (How will you prevent the problem from occurring again?) ___________

Go figure indeed. :rolleyes:

One of our major customers that we do OEM work for has on their "Corrective and Preventive Action Request":

Root Cause of Nonconformance: __________________

Corrective Action Taken: (How will you correct the problem?) _____________

Preventive Action Taken: (How will you prevent the problem from occurring again?) ___________

Go figure indeed. :rolleyes:

After three years in the Cove, I’ve read lots of posts dealing with the differences between Corrective and Preventive Actions, as interpreted by others. This thread and several others contain many examples of each. Some consider Product Realization (Contract Review), Internal Audits and a few other things as “Preventive” Actions. The “purists” amongst us think we should look around and imagine the worst case scenarios involving product/processes and act on them. You know, like, let’s see what I can dream up today and call it Preventive Action. My feeling is that the real answer proves to be as elusive as that link-correlation between Customer Satisfaction and Profitability. :vfunny: :smokin:

One of our major customers that we do OEM work for has on their "Corrective and Preventive Action Request":

Root Cause of Nonconformance: __________________

Corrective Action Taken: (How will you correct the problem?) _____________

Preventive Action Taken: (How will you prevent the problem from occurring again?) ___________

Go figure indeed. :rolleyes:

Absolutely, definitely wrong! You will need to put them right!

"Correction": (How will you correct the problem?) _____________

"Corrective Action" Taken: (How will you prevent the problem from occurring again?) ___________

"Preventive action" would have avoided it happening in the first place (or at least reduced the risk), because you anticipated what might go wrong and did something to avoid it. If you want, it is addressing the "Root Cause of A POTENTIAL Nonconformance".

After three years in the Cove, I’ve read lots of posts dealing with the differences between Corrective and Preventive Actions, as interpreted by others. This thread and several others contain many examples of each. Some consider Product Realization (Contract Review), Internal Audits and a few other things as “Preventive” Actions. The “purists” amongst us think we should look around and imagine the worst case scenarios involving product/processes and act on them. You know, like, let’s see what I can dream up today and call it Preventive Action. My feeling is that the real answer proves to be as elusive as that link-correlation between Customer Satisfaction and Profitability. :vfunny: :smokin:

Energy,

I could not have said it better myself. Who really cares as long as the problem is fixed. It is the same as "Is the horse Pulling or Pushing the cart?" or "What came first the chicken or the Egg?" (I don't care as long as I can have an omelett).

I really think the ISO guys are sitting around their club house with a snifter of brandy each and a few havanas laughing their heads off. I can imagine them dreaming up the next ambiguity just so us poor old QA types will have something to argue about. LOL ;)

Greg B

Absolutely, definitely wrong! You will need to put them right!
"Preventive action" would have avoided it happening in the first place (or at least reduced the risk), because you anticipated what might go wrong and did something to avoid it. If you want, it is addressing the "Root Cause of A POTENTIAL Nonconformance".
Nobody is wrong in the Cove, Peter! That's your view!
Preventive Action would have prevented it from happening in the first place? Is there a crystal ball, tea leaves, or Cleo to help you determining where this potential pitfall lays? Hindsight and platitudes are great. They have nothing to do with "real" situations. MO :bonk: :smokin:

Nobody is wrong in the Cove, Peter! That's your view!
Preventive Action would have prevented it from happening in the first place? Is there a crystal ball, tea leaves, or Cleo to help you determining where this potential pitfall lays? Hindsight and platitudes are great. They have nothing to do with "real" situations. MO :bonk: :smokin:

Energy

Of course you are right - it was the VAR in question who wasn't!

And I should have said "effective" preventive action. The potential problem might not have been seen at all (ie no action) or it might have been seen but all that happened was that someone crossed their fingers. The standard makes folk think that there are 2 processes (CA and PA) - the only thing that is different is what triggers the action in the first place. But what is more important is that folk define and manage their processes to take risks into account.

...You will need to put them right!...

LOL - I'm not gonna put them right. They are 20% of our annual sales.

It's not Preventive Action as I understand it, but it's what they call it. We've only rec'd three requests in the three years I've been here - every single one my response in their "Preventive Action Taken" spot was: "The corrective action above will prevent the problem from occurring again." They've accepted this response every time. :rolleyes:

Peter,

At one time I used to use terms like "absolutely not" instead of "IMO", and I've got the scars to prove it. When it comes to corrective and preventive actions, and correction vs. corrective action, there are no absolutes.

Consider, when the 8 step discipline for problem solving was first used (I went to Ford's TOPS training in the late 80's), step 7 was "prevent recurrence" and back then the definitions were just as Cari wrote:

Corrective Action Taken: (How will you correct the problem?) _____________

Preventive Action Taken: (How will you prevent the problem from occurring again?) ___________

Juran's Quality Handbook states that "Corrective Action" is for "eliminating nonconformance", which could mean simply "Correction".

There are varying degrees of corrective action. And when you prevent recurrence of an existing problem, the solution may apply to other processes that have never had the problem (so it is also "preventive action" how you define it).

The ISO standard on the matter is as muddy as it gets. Daniel, Merrriam, and the rest of the Webster family would go bonkers in this field. :bonk:

So the best thing to do is join, as Greg suggests, the Brandy snifting ISO guys and have some light hearted fun with it. And while we're at it, find a system of corrective and preventive actions that suits our business an go with it. :truce: :rolleyes:

I may be misunderstanding some of the references to my post - but just in case, I'd like to clarify that that is exactly what their form looks like. I didn't insert the stuff in parenthesis, it's on the form.

Not to muddy the waters more than they are - but what about this silly "Corrective Action Impact" that in my opinion makes the definition of Preventive Actions even harder? Any comments on the difference between CAI and PA? :ko: :bonk: :frust:

Not to muddy the waters more than they are - but what about this silly "Corrective Action Impact" that in my opinion makes the definition of Preventive Actions even harder? Any comments on the difference between CAI and PA? :ko: :bonk: :frust:

Before I can step in the silt, is CAI particular to a certain industry's requirements? This is the first time I've seen it. Of course, I am out of the loop.:cool:

Yeah, energy. QS-9000, 3rd ed., 4.14.2.2 "Corrective Action Impact: Where applicable the supplier shall apply the corrective action taken, and controls implemented, to eliminate the cause of a nonconformity to other similar processes and products." Sounds like "preventive action" to me, but then, what do any of us really know, anyhow? :rolleyes:

Yeah, energy. QS-9000, 3rd ed., 4.14.2.2 "Corrective Action Impact: Where applicable the supplier shall apply the corrective action taken, and controls implemented, to eliminate the cause of a nonconformity to other similar processes and products." Sounds like "preventive action" to me, but then, what do any of us really know, anyhow? :rolleyes:
That rules out Corrective Actions for one process/product being applied to other processes/product as Preventive. They must have gotten tired of hearing that answer. Very muddy, indeed! :thanx:

Peter,

At one time I used to use terms like "absolutely not" instead of "IMO", and I've got the scars to prove it. When it comes to corrective and preventive actions, and correction vs. corrective action, there are no absolutes.

The ISO standard on the matter is as muddy as it gets. Daniel, Merrriam, and the rest of the Webster family would go bonkers in this field. :bonk:

So the best thing to do is join, as Greg suggests, the Brandy snifting ISO guys and have some light hearted fun with it. And while we're at it, find a system of corrective and preventive actions that suits our business an go with it. :truce: :rolleyes:

Rob

Don't worry, it is fun! I was really having a go at the new ISO9K and how it has made a meal of the subject by making definitions which just serve to confuse. To me, PA is built into planning, tendering, recruitment, process design ...

We had the same problem during our implementation phase. The best way I can explain it to you is a corrective action is the result of a nonconformance. When you have a nonconformance the way to "fix" it is to write a corrective action, implement it, and see if the corrective action worked. On the other hand a preventive action is being proactive. You see that a process may have a weakpoint. Therefore you write a preventive action to make others aware be a breakdown in your system appears via an audit.

Due to a recent article I am resurrecting this issue.

It is no wonder that people outside the Quality field consider us nuts. We often use vernacular that is strange to the outsider. The use of “correction”, “corrective action” and “preventive action is a good example.

The March 2004 Quality Digest magazine has an article entitled “Correct Me if I’m Wrong” (pg. 56) by Dan Nelson (which I will because he is). A couple of quotes are as follows:

“You might correct the error [but you are not] taking corrective action… preventing a known problem from recurring is part of corrective action… [AND] preventive actions…don’t prevent existing problems from recurring”.

So correcting something is not corrective action, and preventing something is not preventive action. That’s enough to drive anyone mad.

Webster’s 10th ed. defines things this way: Correct = “To make or set right”, and Prevent = “To meet or satisfy in advance… to keep from happening or existing”.

Prevent me if I’m wrong, but would not correcting an error, say reworking a part, be a CORRECTIVE action, albeit interim or short term? And is not preventing a recurrence, say adding a mistake-proofing mechanism, a PREVENTIVE action, even though it is a long term solution to an existing concern?

I would suppose normal people would think so. But not us Quality Professionals! :bonk:

The way we do it here follows the 8D thinking of years ago. We have short term and long term corrective actions. The long term is generally preventive in nature and we may even state it as such. We save the ISO required/defined “preventive actions” for process improvements, suggestions, and FMEAs.

Notice too that the word is “preventive”, not “preventative” (some people like that extra syllable, “ta”). So anyway, ta ta for now. I won’t try to correct you from replying – or is that, prevent you – I always get that mixed up. :rolleyes:

Due to a recent article I am resurrecting this issue.

It is no wonder that people outside the Quality field consider us nuts. We often use vernacular that is strange to the outsider. The use of “correction”, “corrective action” and “preventive action is a good example.

The March 2004 Quality Digest magazine has an article entitled “Correct Me if I’m Wrong” (pg. 56) by Dan Nelson (which I will because he is). A couple of quotes are as follows:



So correcting something is not corrective action, and preventing something is not preventive action. That’s enough to drive anyone mad.

Webster’s 10th ed. defines things this way: Correct = “To make or set right”, and Prevent = “To meet or satisfy in advance… to keep from happening or existing”.

Prevent me if I’m wrong, but would not correcting an error, say reworking a part, be a CORRECTIVE action, albeit interim or short term? And is not preventing a recurrence, say adding a mistake-proofing mechanism, a PREVENTIVE action, even though it is a long term solution to an existing concern?

I would suppose normal people would think so. But not us Quality Professionals! :bonk:

The way we do it here follows the 8D thinking of years ago. We have short term and long term corrective actions. The long term is generally preventive in nature and we may even state it as such. We save the ISO required/defined “preventive actions” for process improvements, suggestions, and FMEAs.

Notice too that the word is “preventive”, not “preventative” (some people like that extra syllable, “ta”). So anyway, ta ta for now. I won’t try to correct you from replying – or is that, prevent you – I always get that mixed up. :rolleyes:

I agree, but this is one time I'm not going to take the bait on this discussion. A quick search of the Cove will show that we have discussed this several times previously, and the end result always appears to be an understanding that the solution is possibly beyond reach (no common interpretation has been reached).

In-fact let me take the opportunity to say that this is a good illustration of C.I. Lewis' discussions on "Common Concepts" or the lack thereof. I am rapidly coming to the conclusion that there really is a lack of common concept when it comes to discussions related to corrective -Vs- preventive, in that we all seemingly have our own definitions.

So anyway, ta ta for now. I won’t try to correct you from replying – or is that, prevent you – I always get that mixed up. :rolleyes:
Great writing Rob... You made my day :D .

First of all we have to prevent bad things from happening.

When they nevertheless do happen, we have to stop them from happening again.

We also have to fix the stuff that turned out bad as a result from our failure to stop things from happening in the first place and/or happening again...

To top it all off we then have to take care of it when it happens again

Small wonder most of us are mentally deranged...:biglaugh:

/Claes

The ISO standard on the matter is as muddy as it gets. Daniel, Merrriam, and the rest of the Webster family would go bonkers in this field.

It is no wonder that people outside the Quality field consider us nuts. We often use vernacular that is strange to the outsider. The use of “correction”, “corrective action” and “preventive action is a good example.


Rob,

What's wrong with the ISO 9000-2000 definitions? They seem reasonably clear to me -- especially relative to some of the stuff ISO defines.

In-fact let me take the opportunity to say that this is a good illustration of C.I. Lewis' discussions on "Common Concepts" or the lack thereof. I am rapidly coming to the conclusion that there really is a lack of common concept when it comes to discussions related to corrective -Vs- preventive, in that we all seemingly have our own definitions.I recall, Dave, through a vaguely alcoholic and smoke filled haze, my days in the University when the Philosophy majors used to destroy us poor Science and Engineering types by shouting
"Define your terms!"
whenever we had the audacity to venture an opinion on ANY topic in the saloon across the street from our campus.

We would take the challenge literally and spend twenty or thirty minutes trying to give gilt-edged (if slightly slurred) definitions only to be interrupted and shouted down again to define something like "war."

Except he is too young to have been there, Slick Willy's statement of
"it depends on the meaning of what 'is' is."
sounds almost exactly like those Philosophy majors about the Viet Nam "activity" during the early 1960's.

Now here we are again, trying to put definitive labels on processes which are fluid and changing in every organization.

One of the saving graces of ISO Standards is the "escape" concept of "as it applies to the organization and to satisfying its customer's requirements."

Perhaps we'll reach that day when we get a bunch of Cliff's Notes for each Standard to help us get through them the same way we got through Shakespeare and C.S. Lewis (is it really cheating?)

I recall, Dave, through a vaguely alcoholic and smoke filled haze, my days in the University when the Philosophy majors used to destroy us poor Science and Engineering types by shouting
"Define your terms!"

Perhaps we'll reach that day when we get a bunch of Cliff's Notes for each Standard to help us get through them the same way we got through Shakespeare and C.S. Lewis (is it really cheating?)

Wes,

In this particular case, did ISO not "define [their] terms"? In this case, isn't ISO 9000-2000 your "Cliff's Notes"? What is wrong with the ISO definitions in this case? -- I think they are pretty clear. Maybe I only think I understand it but I really don't.

Mike,

Twice you've mentioned the 'clarity of the ISO terms'. Please define them here along with where you got them from. It might help get us all "on the same page".

Mike,

Twice you've mentioned the 'clarity of the ISO terms'. Please define them here along with where you got them from. It might help get us all "on the same page".

Sorry, I assumed you guys had a copy of ISO 9000-2000, and I shouldn't oughta done that. :nope:

I hope this is not copyright violation - if it is a moderator can delete it:

3.6.4
preventive action
action to eliminate the cause of a potential nonconformity (3.6.2) or other undesirable potential situation
NOTE 1 There can be more than one cause for a potential nonconformity.
NOTE 2 Preventive action is taken to prevent occurrence whereas corrective action (3.6.5) is taken to prevent recurrence.

3.6.5
corrective action
action to eliminate the cause of a detected nonconformity (3.6.2) or other undesirable situation
NOTE 1 There can be more than one cause for a nonconformity.
NOTE 2 Corrective action is taken to prevent recurrence whereas preventive action (3.6.4) is taken to prevent occurrence.
NOTE 3 There is a distinction between correction (3.6.6) and corrective action.

3.6.6
correction
action to eliminate a detected nonconformity (3.6.2)
NOTE 1 A correction can be made in conjunction with a corrective action (3.6.5).
NOTE 2 A correction can be, for example, rework (3.6.7) or regrade (3.6.8).

Now, I can see where there might be some debate in some circumstances about when an action is corrective or preventive. For example, let's say you make red wagons. Your customer, who buys only large size red wagons, complains that the wheels are falling off. You investigate and find that the cotter pins you were using are defective -- too soft.

IMO...

If you replace the defective cotter pins (with new and better ones) on the customer's large wagons, that is correction.

If you use only the new cotter pins on all future large red wagons you produce, that is corrective action.

If you decide to also use only the new cotter pins on the little and medium size red wagons as well, even though there has never yet been a case of a wheel falling off of them, that is preventive action, IMO. Some could argue, I suppose, that it is CA since the issues are so similar, but IMO it is PA.

Comments?

Mike,

Your original assumption was correct. In fact I've got too many standards: ISO-9000:2000, 9001, 9004, TS16949, QS, TE Supplement, AIAG manuals, and all the other reference manuals.

Also, your (red wagons) analogy is a good one. And I believe it is also the point Dan Nelson tries to make in the article that caused me to resurrect this issue. My problem is that Mr. Nelson's article epitomizes the myopia we Quality professional's develop when hair-splitting definitions. His article's subtitle is "Don't confuse the preventive aspects of corrective actions". WHY? will we lose our contracts? develop a rare disease? cause our registrar to choke on his doughnut?

It's just not that important!!! Although it has run a rather lengthy thread here.

Sometimes I feel like we're all 'Monk' (from the TV series) and everyone else is the Police Chief.

If you decide to also use only the new cotter pins on the little and medium size red wagons as well, even though there has never yet been a case of a wheel falling off of them, that is preventive action, IMO. Some could argue, I suppose, that it is CA since the issues are so similar, but IMO it is PA.

Comments?

Mike,

This is exactly the type of scenario that I have seen brought up time and again here as well as in other forums, where common understanding breaks down. Is it preventive to pass the fix on to similar products, or is it a continuation of the corrective action?

I believe that just as Rob and Wes have pointed out, it's just not that important for us to quibble over. After all if within our organizations we can develop a common understanding that's really all that matters (and even then if there are questionable situations that arise, what difference does it make what we call the action). The important factor is did we do anything to take care of the identified weakness/nonconformance. We can pidgeon-hole the action for our internal reports however we feel like on that particular day.

Really I'm not going to loose my certification or (more importantly) my customers just because I called an action preventive that they felt was corrective, or vise versa.

Maybe we should just refer to both as "Continual Improvement" actions - the subcategory that ISO 9001 puts them both in.
:agree:

Rob said "My problem is that Mr. Nelson's article epitomizes the myopia we Quality professional's develop when hair-splitting definitions. His article's subtitle is "Don't confuse the preventive aspects of corrective actions". WHY? will we lose our contracts? develop a rare disease? cause our registrar to choke on his doughnut? It's just not that important!!!"

:lol: :agree1: Had I been eating a doughnut when I read this I may have choked on it, though!

DD said "Is it preventive to pass the fix on to similar products, or is it a continuation of the corrective action? I believe that just as Rob and Wes have pointed out, it's just not that important for us to quibble over. After all if