Documentation for ISO9001-2000

[ivan99]

SOP's, Work Instructions, Training Manuals?? where is the demarcation line?? Can I build a robust QMS based on few SOP's and WI's and heavy on training manuals?? Are training manuals subject to document control??

 

[David Mullins]

As QA Manager, it's your call.
Just get everyone else to agree, and make sure it complies with whatever it needs to - EASY!?!?!

 

[noboxwine]

Here's a twist.

ivan99 said:


SOP's, Work Instructions, Training Manuals?? where is the demarcation line?? Can I build a robust QMS based on few SOP's and WI's and heavy on training manuals?? Are training manuals subject to document control??

Here's a left of center, but effective way to look at it. Put the ISO book in the bottom drawer. Build an effective QMS using the tools you need to maintain it's effectiveness. Test it over a reasonable amount time. If it works, then pull out the bottom drawer and fit the system into the standard and see if you have gaps. Fill them accordingly. KEEP IT SIMPLE PLEASE !!!!!!!!!!!!!

MORAL OF THE STORY: Fit your program into ISO. Not ISO into your program. When it comes time to read the standard, start at page 9 and read through 22. Read it as written, not between the lines. Amazingly, you'll see that you have the flexibility to run your business effectively without changing the world. And for God's sakes, don't let an auditor with "short man's disease" or anyone else put you in a corner noting a noncompliance to the standard when indeed they're simply not agreeing with your business practices. Good luck and have a day.

 

[gpainter]

Most companies over document, ISO was never meant to be a document nightmare. Although, many consultants have suggested to over document and Work Instruct everything. And many companies have. Lean, mean and train. The key word TRAIN.

 

[David Mullins]

Could I please have a dollar for every half-arsed CAR response I've received over the years that said "operator to be retrained".
I'll hand out a C note for every CAR that says they would implement a system to prevent it happening again.

Training, sure, but sometimes we have to make systems that don't rely on people - they aren't that reliable!

 

[IceZebra]

David,

I couldn't agree more.

I have started the process of rejecting every CAR that lists Operator Error as the root cause. You can train all you want (and should) but unless you make your process error proof... Murphy's Law.

And I thought our process guys were confused before.

 

[Mike S.]

Systems that don't rely on people? Operator error not possible/never acceptable? Maybe I'm just dumb, but I think I need some more explanations on these opinions because as blanket statements they do not jive with my experience and beliefs. Please, educate me.

 

[IceZebra]

Mike,

David Mullins:
...systems that don't rely on people...

I think what David was trying to say was don't rely on people to do it correctly. Make the process robust. (Correct me if I'm wrong Dave!)

The point I was making was if the process allowed the operator to make an error, then there is something wrong with the process, not the operator. It is important to point the finger at the process and not the person working on it.

For that reason alone, I reject all CAR's with Operator Error, unless they can give me a plausible explanation (which they haven't to date).

Now, let me qualify where I am coming from. I work in the automotive industry so I can only speak from my experiences there. For other industries, perhaps my statement was a bit of 'shooting from the hip'. (Maybe Marc could offer a 'foot in the mouth' smilie for just such a thing )

I hope this clarifies my thoughts...

 

[db]

Not always the process

The point I was making was if the process allowed the operator to make an error, then there is something wrong with the process, not the operator. It is important to point the finger at the process and not the person working on it.

I think there are times where we can legitimately say it was operator error. Not all processes can eliminate the human element. Sometimes the best we can do is to install checks so the error doesn’t make it very far without notice. I too reject “retraining” as the fix. Most cases, it was not a training issue, it was an execution issue. The employee knew what to do (or not to do), put performed otherwise.

Also, we can never safeguard completely from sabotage. My uncle used to work on the assembly line. After the afternoon break, the next vehicle going down the line would have a pop bottle in the passenger’s door. He did it to “drive the dealership crazy”. I’ve seen fuel tanks with hats and rags deliberately stuffed inside of them.

In many cases, the best the process can do is to detect and isolate such errors (whether they be accidental or intentional)

 

[ivan99]

I tyhink I got the pic!! but we drifted frommy original question to training as emphasis and that was definitely not my intent. All I was aking is semantics...the difference between a document called SOP or whatever and another called Training Manual...they bith contain the same info...which one do you choose...that's all I was asking about! Sorry for any confusion on my part...Please keep it going...