Should the TC 176 Re-word the Requirements for Preventive Action?

[CarlDaniel]

Thanks for clarifying these things and in much simpler perspective too...About monitoring for "several weeks", I don't actually use that instead I use an exact time frame as you pointed out.

 

[Peter Fraser]

A few observations:

1 The wording of 8.5.2 ("take action to eliminate") and 8.5.3 ("determine action to eliminate") is slightly different for no reason. 8.5.3 is a waste of paper.

2 The requirements for CA / PA are in fact identical - the only difference is that they are triggered by different events. For CA, something has happened. For PA, you realise that something might happen. In both cases, you work out how to avoid the "something" happening in the future.

3 You might therefore think that they could reasonably be described in a single procedure - but how you "recruit staff" / "provide training" / "accept a customer order" / "plan and monitor production" (even "design a process") should all be done in a way which anticipates problems (ie CA / PA). This is what "process management " is all about, ie you design and implement processes in a way which recognises the factors which may influence how well the processes will work.

Unfortunately, the wording of the standard causes folk to think that they have to do more than what a "good" manager should be doing anyway.

 

[Helmut Jilling]

A few observations:

1 The wording of 8.5.2 ("take action to eliminate") and 8.5.3 ("determine action to eliminate") is slightly different for no reason. 8.5.3 is a waste of paper.

2 The requirements for CA / PA are in fact identical - the only difference is that they are triggered by different events. For CA, something has happened. For PA, you realise that something might happen. In both cases, you work out how to avoid the "something" happening in the future.

3 You might therefore think that they could reasonably be described in a single procedure - but how you "recruit staff" / "provide training" / "accept a customer order" / "plan and monitor production" (even "design a process") should all be done in a way which anticipates problems (ie CA / PA). This is what "process management " is all about, ie you design and implement processes in a way which recognises the factors which may influence how well the processes will work.

Unfortunately, the wording of the standard causes folk to think that they have to do more than what a "good" manager should be doing anyway.

I would think your point #2 would demonstrate there is a value in PA, rendering point #1 incorrect?

 

[Peter Fraser]

I would think your point #2 would demonstrate there is a value in PA, rendering point #1 incorrect?

Helmut

On the contrary, 8.5.3 repeats almost all the wording of 8.5.2. If the first part of the clause explained the two types of trigger event, the steps required are the same. Words for words sake...

 

[vanputten]

I would like to offer some systems thinking ideas to the thread. Many might say that I am over thinking this.

I think that true preventive action is when the information, upon which you base your action, comes from outside of the system. Cascading corrective action to similar areas in the system (organization) to me is still corrective action. When someone brings information into the system from sources outside of the system, then you really have preventive action. Re-applying what you have learned from within the system, to me, is corrective action.

I don't think time sequence has anything to do with the definitions. I think the source of the information upon which you base your action is the more valid basis. Is something unwanted happens within your system, and you fix the unwanted thing (elimiante the cause) and then cascade that to other areas within the system, is still corrective aciton to me.

If understanding and knowledge comes from outside the system, and this understanding and knowledge allows you to eliminate the casue of a potential unwanted thing, then I say that is preventive aciton.

For those that say this is over thinking it, I say that your wrong. What would support bringing new understanding into the system if this is overthinking things?

 

[Sidney Vianna]

I would like to offer some systems thinking ideas to the thread. Many might say that I am over thinking this.

I think that true preventive action is when the information, upon which you base your action, comes from outside of the system. Cascading corrective action to similar areas in the system (organization) to me is still corrective action. When someone brings information into the system from sources outside of the system, then you really have preventive action. Re-applying what you have learned from within the system, to me, is corrective action.

I don't think time sequence has anything to do with the definitions. I think the source of the information upon which you base your action is the more valid basis. Is something unwanted happens within your system, and you fix the unwanted thing (elimiante the cause) and then cascade that to other areas within the system, is still corrective aciton to me.

If understanding and knowledge comes from outside the system, and this understanding and knowledge allows you to eliminate the casue of a potential unwanted thing, then I say that is preventive aciton.

For those that say this is over thinking it, I say that your wrong. What would support bringing new understanding into the system if this is overthinking things?

Like Hjiling says: crystal clear.

In my mind there is no question that preventive action should be THE main target for clarification in ISO 9001. The mystery is why doesn't the TC176 realize that? Or, if they do, why don't they do something about it? Another conspiracy?

 

[Helmut Jilling]

Helmut

On the contrary, 8.5.3 repeats almost all the wording of 8.5.2. If the first part of the clause explained the two types of trigger event, the steps required are the same. Words for words sake...

Precisely...and your point #2 correctly points out the subtle but important difference. THAT is what gives it value in my opinion - the fact that Preventives are intended to be a proactive search for potential failure. That is far superior than waiting for issues to arise. Thus, the value of 8.5.3. Now, if only they would emphsize that important distinction so everyone would get it...

 

[Helmut Jilling]

Like Hjiling says: crystal clear.

In my mind there is no question that preventive action should be THE main target for clarification in ISO 9001. The mystery is why doesn't the TC176 realize that? Or, if they do, why don't they do something about it? Another conspiracy?

...hey, it's crystal clear to ME, if the rest of you don't get it...that not my fault...

Now, I took the time to accept your challenge to write 5 examples of PA...Sooo...my friend, I expect you will at least take time to read my white paper and tell me why you don't like my 5 examples...hmmm?

 

[JaneB]

... how you "recruit staff" / "provide training" / "accept a customer order" / "plan and monitor production" (even "design a process") should all be done in a way which anticipates problems (ie CA / PA). This is what "process management " is all about, ie you design and implement processes in a way which recognises the factors which may influence how well the processes will work.

Yes indeed. As well as planning. Good planning includes sound 'preventive action' and risk management - ie, anticipating things that *might* not work/go wrong etc. and planning, designing & implementing to prevent or avoid that.

 

[JaneB]

...hey, it's crystal clear to ME, if the rest of you don't get it...that not my fault...

Now, I took the time to accept your challenge to write 5 examples of PA...Sooo...my friend, I expect you will at least take time to read my white paper and tell me why you don't like my 5 examples...hmmm?

Will do.

This thread has certainly stimulated some spirited and interesting debate, for which thanks to all.