posted 17 May 2001 01:52 PM              

For example, I said that, for our ESD prcedure, that ground connections should be inspected to ensure that they are in good repair. Is it enough to leave it at that? Or do I need to "define" what the requirements for "good repair" are. This would seem to me to be overkill. Is it unreasonable to asume that the person making the inspection has the judgement to determine what "good repair" is?

Any thoughts you have would be appreciated.

Thanks,

posted 17 May 2001 04:48 PM               

one reason for detailed work instructions is when you need to train new staff in that position...what documentation do you use to train them. Eventually yes they will become compitant enough to do the job with out looking at the work instruction but until then, they need something to reference.

Hope this helps

posted 17 May 2001 08:17 PM               

ESD EXAMPLE:
Unfortunately this is not a good example for my point. Let's say that different areas within the org were using different inspection methods, and some didn't perform inspection at all. This is a prime candidate for establishing a standardised work practice where you want everyone to perform an inspection, but don't take it to the Nth degree of stipulating the actual inspection instructions - hance a major change for some, and no change for others.
In reality we clearly need to stipulate what the inspections consists of, which can be stated in the procedure, an annex to the procedure, or a separate work instruction. This represents major change for some, minor change for some, and no change for the others.
Why do we have to stipulate the inspection methodolgy? Because (and this utilises the basic principles of quality - every process has variation, if you don't control it you can't improve it, &, If you donât measure it you can only change it you donât know if you improved it) you will get greater variation in measurement outcomes without it, thus increasing process capability spread to the point that you can't actually calculate it because you don't control the process.

Also to take into consideration, is this degree of standardisation going to adversely impact user impressions, to the extent that it turns them off the quality system all together. In this case I don't think the impact is going to be Earth shattering - indeed this kind of things reduces or eliminates barriers that previously existed between work groups.

I could say more but I've got work to do.
Let me know if you want more dribble
David.

posted 18 May 2001 12:36 AM               

The policy defines why.

Procedures define who does what and when.

Instructions (or another document vehicle) defines how.

posted 18 May 2001 11:01 AM               

However, I will tell you how we do it. We have a general procedure manual which basically laid out on the same format as the Standard. Then I have operations manuals for Production, Toolroom and QA. In the Operations Manual are the specfics on how to do the job. I feel these are still fairly vague, and taking into account the Operators are skilled setter/operators. They also have 'Set-Up Instructions'. There is a Set-Up Instruction sheet for EVERY job that we run. This gives sort of 'tricks' for setting up that particular job.