Generic Corrective Action procedure - Comments please

[Brian Hunt]

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

 

[Jimmy Olson]

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.

 

[Randy Stewart]

I think you're asking for trouble

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.

 

[Al Dyer]

CA Proc

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

 

[M Greenaway]

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 !

 

[Brian Hunt]

back to the drawing board

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

Brian

 

[Jimmy Olson]

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.

 

[M Greenaway]

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

 

[eee]

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.

 

[Brian Hunt]

Thanks for comments

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

Brian