posted 31 December 1998 10:29 AM               

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.

posted 31 December 1998 06:39 PM               

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.

posted 31 December 1998 07:35 PM               

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.

posted 04 January 1999 08:32 AM               

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.

posted 04 January 1999 03:30 PM               

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.

posted 21 February 1999 01:48 AM               

Corrective Action is a Response to a problem.

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

posted 21 February 1999 10:31 AM               

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.

posted 22 February 1999 08:47 PM               

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.

posted 09 March 1999 05:29 PM               

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

posted 09 March 1999 07:14 PM               

quote:

---

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.

quote:

---

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.

posted 10 March 1999 10:07 AM               

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.

posted 10 March 1999 12:42 PM               

quote:

---

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

---

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

quote:

---

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

posted 10 March 1999 01:31 PM               

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.

posted 10 March 1999 06:52 PM               

quote:

---

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.

quote:

---

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.

quote:

---

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

---

Ainât it the truth.

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.

---