Hi

I need to produce several a top level generic procedures for use within a group of business divisions. These will be part of the six mandatory ISO9001:2000 procedures. And I've let this task slip - I need to complete it tomorrow.

Please let me have comments and feedback on the one attached - generic corrective action procedure:



TIA

Brian

Hi Brian

IMHO the procedure is on the weak side. It is pretty loose in details and meeting the rquirements. There is potential that you could make arguments that it covers everything, but you would have to be real persuasive :)

Is there a form that goes along with this or are you just using the appendix for tracking corrective actions? If you are planning on just using the appendix I would suggest looking at the possibility of using a form so that you can have more detail.

You may want to look at the requirements a) through f) of 8.5.2 in the standard and make sure that your procedure can answer each of those. At this time, I don't think it does (at least not clearly), but that is my opinion. I'm sure you will get plenty of feedback from other people as well.

I would be careful with the procedure. Especially one as important as Corrective Action. Questions:
Who is responsible for the action(s)?
Who is responsible for dispostion?
Who is empowered to perform?

Even if the procedure has to cross over divisions (mine do also) there is common ground to be reached. The company as a whole should attack problems in the same manner. They don't have to use the same tools (4 why's, fishbone, etc.) but the structure should be there.
Good problem solving and corrective actions can save your Bu**. IMO I wouldn't release this, as one of the backbones of a good system it is too weak.

I agree with Richard,

Although it is called a "generic" procedure it seems too loose. Is there a real benefit in even having such a "generic" procedure?

I guess in my view a procedure will , akin to a work instruction, direct me in performing a function.

How do I do it?
How is the action recorded?
How is the action verified?
What forms do I use?
Are there a related documents or procedures?
Who performs the actions required?

ETC.....


:bigwave:

Sorry Brian

I only got as far as the introduction, and the huge misinterpretation of corrective action, and I read no more !

Corrective action is NOT action taken to return a product to how it was before it was found faulty - in fact the whole sentence is nonsensical.

Surely a products condition before it is found faulty is still faulty !!

I think you mean to return a product to specification, but even still this is a description of rework, which is just one possible disposition of non-conforming product, along with scrap, repair or concession.

What you are talking of is correction of the product, a whole different kettle of fish.

Corrective action is actions taken on the systemic root cause of a problem to stop it re-occurring.

I know arguing over these definitions is a well worn and tedious debate, but it is important to understand them !

Thanks for the comments so far - it looks like I've got a bit more to do :(

Brian

Brian,

Looking at these comments I realize it would be pretty easy to get depressed, but that's not the idea.

As has been mentioned here already, it would be a good idea to write a new procedure and be more detailed. There really hasn't been any suggestions for improvement here because the procedure is pretty basic. If you do a search on here you can find examples of procedures that can give you ideas. I can send you a copy of our procedure as well if you want.

Believe me, I know it's tough to come up with something good under pressure at the last minute. :)

OK Brian I have read the rest, and to add to your misery I agree with the others that it is very weak.

The bit on root cause analysis is very poor. I suggest you look at the 5 Why method of problem solving, akin to Ishikawa's fish bone diagrams, for a good methodical way of determining root cause. Also I would recommend you look at the 8D methodology of problem solving for perhaps the most robust system of corrective action, from notification of a problem through to delivery of systemic preventive actions.

It was good however to see some rationale behind when to raise formal corrective action. All too often we get bogged down in doing supposed corrective action on every single incident of reported problem - I would however suggest a Pareto analysis of root causes to determine the major cause of problems, and only target full blown corrective action on the major causes (unless of course your customer insists on full blown action - which many of the buggers do !).

I've seen more than 100 procedures called "Corrective and preventive actions" during my "quality" life. I can say, may be 4-5 of them were interesting. Others were useless, nobody in companies use them. IMHO these actions shall be described in various procedures like "Internal Audit", "Design and Development", "Income Inspection" and so on. And then you shall give links in 8.5.2 chapter of your QM to these procedures. It's the most smooth variant. IMHO again.

Thanks for all the comments folks - been too busy to reply until now but they are appreciated.

Brian

eee said:
I've seen more than 100 procedures called "Corrective and preventive actions" during my "quality" life. I can say, may be 4-5 of them were interesting. Others were useless, nobody in companies use them.

eee

I respectively submit that if the procedure was written exactly the way your Company deals with Corrective and Preventive Actions, then everybody is using them. Interesting is not good enough. Writing procedures because we have to is bad enough, but to write procedures that do not reflect your company's method of handling CA/PA's, even though they may be interesting, is worse. JMHO

:ko: :confused:

energy said:
I respectively submit that if the procedure was written exactly the way your Company deals with Corrective and Preventive Actions, then everybody is using them.


I don't know which companies you know in depth, energy, but they are clearly all well above average! I say that because it is - in my experience - a rare company that routinely applies causal analysis to actual problems, let alone to potential problems.

In the majority of companies, if you simply documented "what we really do about systematically eliminating causes", you'd have a generic procedure describing a nice bout of foot-shuffling, muttering and blushing.

What is a sence of generic procedures?

Tom Harris said:

I don't know which companies you know in depth, energy, but they are clearly all well above average! I say that because it is - in my experience - a rare company that routinely applies causal analysis to actual problems, let alone to potential problems.

In the majority of companies, if you simply documented "what we really do about systematically eliminating causes", you'd have a generic procedure describing a nice bout of foot-shuffling, muttering and blushing.

Tom,

Let me try again. Someone brings you a defective component that failed Final Inspection or was returned by the Customer. You immediately document it and begin the process of determining what, why and where. The road takes you various departments and find out why it happened. You all get together and decide what to do to insure that this particular thing doesn't happen again. While you are at it, you look at similar product and investigate the possibility of that defect occurring in other components. You rework the existing part or scrap it and make new. All this is documented and tracked to completion. Now, to me, that's normal. Not exceptional. If your written procedure describes these steps that you take to address CA/PA, it's a normal procedure and no problem following it. And, it's real. Anyway, that's what I was trying to say. But, I do not subscribe to the idea of forming a posse every time there is a N/C and begin a fullblown investigation. And, I also think that most companies "routinely apply causal analysis to actual problems and think about potential problems." These are not exceptional companies. These are normal companies and these minimal activities are required to remain a company. MHO
:ko: :smokin:

You immediately document it and begin the process of determining what, why and where.

I don't know if I agree with this. We use frequency in order to keep from spending time on a one-off situation. It is documented but the formal troubleshooting may not be required.

I have found that there are 2 main areas that really get messed up; disposition responsibility and empowerment. Most will say that the operator has the authority to stop the operation if non-conforming material is found. In reality he may raise the issue but is overridden by his supervisor. Then when you look at who determines the disposition of non-conforming product it is at a level that usually will cause problem solving to be missed (i.e. too busy to look into it, etc.). In the end you get an operator who no longer takes time to report it and no one to look into it.

Randy Stewart said:

I have found that there are 2 main areas that really get messed up; disposition responsibility and empowerment. Most will say that the operator has the authority to stop the operation if non-conforming material is found. In reality he may raise the issue but is overridden by his supervisor. Then when you look at who determines the disposition of non-conforming product it is at a level that usually will cause problem solving to be missed (i.e. too busy to look into it, etc.). In the end you get an operator who no longer takes time to report it and no one to look into it.

I assume that your company is quite large if you give the supervisor the latitude to make the decision whether or not to investigate. Procedures that I have worked with said that anyone can report a problem and, in concert with the Q guy, determine further courses of action. It could be as simple as removing a burr from a previous operation with a file or to scrap and re-make. Hence the case for a thorough Final Product Verification to insure no problems existed that went unreported. No? Anyway, we are talking about procedures. I maintain that all companies follow a certain method to handle CA's. If it's documented exactly that way, the procedure is valid. Now, PA is another story. Here in the Cove, we have many interpretations of what that is. I would pick one and go with it. Watch out for those that say that any action taken related to a problem, no matter how far removed, is merely an extension of CA. To that I say, sure man! I once put this question to a Registrar: If I had a problem with part A and corrected it (CA) then looked at all our other stuff for similar problems(Part B, C, D,etc.), is that considered Preventive Action? He looked at me quizzedly and replied "Absolutely". I guess he doesn't visit the Cove!
:vfunny: :ko: :smokin:

energy ....I think one of the problems getting in the way of this discussion is that your definition of CA differs from that of ISO 9000. You say "If I had a problem with part A and corrected it (CA) ...". Correction is NOT the same as Corrective Action (which involves fixing the CAUSE, not fixing the problem).

Your definition. it has to be said. is a very common one. But, if we believe what ISO 9000 tells us. it is incorrect, despite what a registrar once told you.

Tom Harris said:

Correction is NOT the same as Corrective Action (which involves fixing the CAUSE, not fixing the problem).

Your definition. it has to be said. is a very common one. But, if we believe what ISO 9000 tells us. it is incorrect, despite what a registrar once told you.

Sure Man! ;) I would be comfortable with that Registrar and our interpretation of CA if it resulted in a Certificate. I mean, that's the meat. All the rest is the potatoes. I expect flak, but that's my take. Like the defunct War thread, we don't have to agree to get the job done. Whether your certificate holds more weight than mine or your company is any better than mine is also arguable. That is, if I had a Company! :vfunny: :agree: :smokin:

I assume that your company is quite large if you give the supervisor the latitude to make the decision
That is what tends to happen, it's swept under the rug or hidden. Remember, I'm in prototype body stampings so there's a large amount of try-out. We may go through 20% of our total stampings as try-out/prove-out. Once buy-off to run is given the Supervisors will sneak NC product into the "try-out" pieces. That's what I was getting at.

If I had a problem with part A and corrected it (CA) then looked at all our other stuff for similar problems(Part B, C, D,etc.), is that considered Preventive Action? He looked at me quizzedly and replied "Absolutely".
Let me get this right, if I am proactive and don't allow a problem to occur based on lessons learned that it is not prevention??? I can see that if I'm just correcting the "SAME" problem over and over. So it really was a systemic problem and you're just treating the symptoms and not getting to the root cause.
Anyway, It's a fine line. I believe it is in the application as to where it fits in as CA or PA.

Tom Harris stated, "Correction is NOT the same as Corrective Action (which involves fixing the CAUSE, not fixing the problem). "

Tom, Actually the standard uses a little bit of double-talk to allow for correction without correcting the cause. "The organization shall take action to eliminate the cause of nonconformities in order to prevent recurrence. Corrective action shall be appropriate to the effects of the nonconformities encountered.

A documented procedure shall be established to define requirements for

c) evaluating the need for action to ensure that nonconformites do not recur,"

What the two seeming contradictory statements [in blue] are allowing for is one-offs or nonconformities where "root cause" corrective action would not be cost effective or prudent. As an example: In a production environment, an operator that faithfully follows her process (a process that has been proven time-and-time again to be very consistent and effective), but for some undeterminable reason makes a simple human error in one of the assembly steps on one piece part out of the last 5000 parts she has assembled.

Even after going through the 5-whys we still come to a conclusion that the error was simply a singular mistake.

Is root-cause corrective action (action to eliminate recurrence) required? According to 8.5.2.c, no it's not. You simply implement the correction (repair/rework) and close out the issue.

I'm sure that we have all run into these types of scenerios, and have in-fact handled them in a similar fashion (the standard not only recognizes this, but allows for it as well).

Randy Stewart said:
That is what tends to happen, it's swept under the rug or hidden. Remember, I'm in prototype body stampings so there's a large amount of try-out. We may go through 20% of our total stampings as try-out/prove-out. Once buy-off to run is given the Supervisors will sneak NC product into the "try-out" pieces. That's what I was getting at.

Randy,

That's deceipt. An exception to the rule, I hope. This thread is about a CA/PA procedure and what makes up an acceptable one. I'm being told that Corrective Action is different than Correction Action. Okay. There are several threads on that and I stand corrected, or corrective or correction. I don't really care.

Are you addressing me or Tom with this next part? I don't think its me because that is what the Registrar called PA. I'm not quite sure how we got to Corrective vs. Correction Action and the difference, but my accent was on Preventive Action or was it Preventative?:vfunny:

This part I totally agree with. As I said before, this road has been heavily travelled before in the Cove and the "Purists" don't buy it.

Randy Stewart said:
Let me get this right, if I am proactive and don't allow a problem to occur based on lessons learned that it is not prevention??? I can see that if I'm just correcting the "SAME" problem over and over. So it really was a systemic problem and you're just treating the symptoms and not getting to the root cause.
Anyway, It's a fine line. I believe it is in the application as to where it fits in as CA or PA.

How about those generic procedures? :vfunny: :ko: :smokin:

ddhartma said:
What the two seeming contradictory statements [in blue] are allowing for is one-offs or nonconformities where "root cause" corrective action would not be cost effective or prudent. As an example: In a production environment, an operator that faithfully follows her process (a process that has been proven time-and-time again to be very consistent and effective), but for some undeterminable reason makes a simple human error in one of the assembly steps on one piece part out of the last 5000 parts she has assembled.

Even after going through the 5-whys we still come to a conclusion that the error was simply a singular mistake.

Is root-cause corrective action (action to eliminate recurrence) required? According to 8.5.2.c, no it's not. You simply implement the correction (repair/rework) and close out the issue.

I'm sure that we have all run into these types of scenerios, and have in-fact handled them in a similar fashion (the standard not only recognizes this, but allows for it as well).
David,

Good post. This is an important point. If memory serves, we've been thru this argument before on the Cove and I argued the same point -- sometimes it's just operator error pure and simple and no "corrective action" is required or prudent, only a "correction" required to get good parts to the customer if applicable. Those who believe this doesn't happen or shouldn't happen do not live in the real world, IMO.

Tom Harris,

Show me where in the standard it says that Energy's stated example of a PA is wrong. I don't see it. :confused:

David: you’re right – evaluating the cause of EVERY problem is neither required (by ISO 9001) nor necessary (in good practice).

Mike: you asked me to show you "where in the standard it says that Energy's stated example of a PA is wrong". There’s some misunderstanding (or a typo?) here - I never mentioned PA.

My point about CA is that energy said that ‘correcting a problem with part A’ is corrective action. In plain English, of course, he is right; but, according to ISO 9000, what he describes is correction (an action to eliminate a detected nonconformity - ref 9000/3.6.6), not corrective action, which has the significant difference that it deals with eliminating THE CAUSE of a detected nonconformity (ref 9000/3.6.5).

Preventive action, of course, also deals with eliminating causes, specifically causes of a potential (as opposed to a detected) nonconformity.

Hey – I don’t write this stuff. I just read it – and try to convince myself that I understand what it says.

But who knows which way is up in ISO 9001 la-la land? ‘ISO nine thousand one’ is – after all – an anagram of "O no! The asinine sound!"

Just to throw something else into the pot !

I would say that you do have to investigate to establish the root cause of EVERY problem.

Then you can establish if the cause is either common cause, or special cause.

If it is common cause, and your process is operating within stated objectives then do no 'corrective action'. If it is common cause, but the process has shifted such that it is no longer operating within the required objectives then take corrective action on the system - managements responsibility. If it is special cause then stop and fix the problem - line team responsibility.

JMO

M Greenaway said:

Just to throw something else into the pot !

I would say that you do have to investigate to establish the root cause of EVERY problem.

Then you can establish if the cause is either common cause, or special cause.



Martin,

That's what I meant when I posted this:

energy said:

Procedures that I have worked with said that anyone can report a problem and, in concert with the Q guy, determine further courses of action. It could be as simple as removing a burr from a previous operation with a file or to scrap and re-make.

Of course that only mentions the physical disposition of the part. That may be where the confusion came in. But for me, I always asked "What happened?" From there we decide how much farther we want to go with the problem. The primary action was to get the product to the Customer on time, then we can hunt down the "perp".

:ko: :smokin:

Tom H.

Okay, I misunderstood. I thought you were taking exception to Energy's example of PA, which I think is a valid example of PA.:truce: :agree:

I agree with Nosmo, the "Corrective Action Handbook" from Patton Press is a very good book to use for corrective action. We fashioned a training program around it for all our management & supervisors. We're making progress but have a ways to go. A lot of good info in that book.

I agree with with M. the intro is talking about disposition. The "Corrective Action Handbook" is a good intro to CA. Also need IMO a "Responsibilities" section in all procedures.

I think that we have given a good example of why "generic" procedures can be dangerous. What is "correction " to one is an Immediate action to another.
Whatever words or titles your system uses is not important. Application, standardization and evaluation are the keys. As long as people understand how the system works, they know how to use it and they apply it, you have 75% of the issue complete. It is up to the ISO guy, QS Coordinator, etc. to ensure the system meets the requirements of the appropriate standard. :agree: