posted 11 March 1999 08:58 AM               

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)?

posted 16 March 1999 08:09 PM               

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.

posted 16 March 1999 08:10 PM               

quote:

---

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.

quote:

---

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.

posted 17 March 1999 12:38 AM               

quote:

---

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.

---

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.

quote:

---

Kim, You say that preventive action prevents an occurance. But we are not talking about putting out fires.

---

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:

quote:

---

So, if all dealing with nonconformities is corrective, you can only take preventive action before you find nonconformities. Therefore preventive action involves detection.

---

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?

posted 17 March 1999 08:05 AM               

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)

posted 17 March 1999 12:48 PM               

I particularly liked:

quote:

---

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.

---

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.

posted 17 March 1999 12:48 PM               

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??

posted 17 March 1999 08:24 PM               

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

posted 17 March 1999 09:40 PM               

Meanwhile, back at the ranch...

quote:

---

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.

quote:

---

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.

quote:

---

...the definition is definitely blurred...

---

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

quote:

---

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.

posted 18 March 1999 07:13 AM               

quote:

---

You say; ćNope - I disagree. Preventive action does not involve detection.ä But it does.

---

quote:

---

It says it in 4.14.3a. Does anyone read the Standard?

---

quote:

---

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)

---

quote:

---

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;

---

quote:

---

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.

---

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.

posted 19 March 1999 04:44 PM               

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...

posted 19 March 1999 09:48 PM               

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:

quote:

---

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.

---

posted 22 March 1999 09:35 AM               

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