How do you decide what is a Process, a Procedure or Work Instruction?

G

Gary E MacLean

Re: How do you decide what is a process, procedure or work instruction?

The commitment you refer to is generally captured in the quality policy; the QM should be more than that.

Of course the QM is more than that but it is certainly much more than the Quality Policy. The QM expresses Top Management's committment in ALL areas not just the few areas required to be covered as per clause 5.3. The QM expresses TM's committment to every single clause and requrement of the standard - one by one.

Why two tiers here? What's the difference between three and four?

Slow down Jim, take it easy. I split that level up for many reasons. One of them is repeatedly expressed throughout this series of forums; that of having way too many documents. My level three consists of those work instructions (documents that provide specific HOW TO) that directly address an ISO requirement. My level four are those documents that you would like to have in your organization but are ones that ISO gives no direction for and has no guidance for. The registrar has no jurisdiction over the content of how you set up your coiling machine or how you distribute bonuses or how your safety committee meets and reports. These are not directly ISO subjects, thus they belong in a separate classification.

They don't have to be audited?? How to you do part/process audits if you don't verify that the work instructions are being followed?

I suppose I should have been more clear. The level fours I refer to do not have to be audited by your registrar and generally will not even be reviewed. They do have to be audited according to your internal requirements. Since they do not address an ISO requirement they really can't be audited by the registrar. The registrar has no criteria with which to evaluate them with anyway. All the registrar can really do is audit the presence of a required instruction. Then the auditor can follow the operator as they conduct the activity but for the most part the auditor will be busy trying to audit the processes and related level three documents. I have successfully shaved many ten, 12 and 15 three ring notebook systems down to one binder using this rationale.


I'd like to learn more about your rationale for the bifurcation.

Come on Jim, tell me you didn't use that word. Your messin' with me right? I covered the rationale for the 'bifurcation' in the previous discussion.


I understand the need to control forms (usually tier 4 in a 4-tier system), but I don't see a need for controlling "unchangeable fact." If it's immutable, why does it need to be controlled?

Actually, the presence, the legibility, identifiability and distribution are every bit as important in the world of document control as is the content Jim. Immutable (if you must use those 'big kid' words) fact is fine but how it gets presented to the organization is very important and must be controlled.


Quality manuals that are "nearly a re-hash of the standard" are mostly worthless beyond the requirement to have a quality manual; why have a potentially significant document that serves no useful purpose?

I hesitate to even admit it but I have worked with over 100 different organizations and have yet to see one of them put the QM to any use of any kind. Yes, in most cases, the QM is issued to fill a requirement. Like it or not that's what is happening in the real world. Even those organizations who do issue the facade QM will usually still pay attention to the level two and three documents though. That is where the meat of any system really is.


The best quality systems I've seen are the ones where someone has set out to build an efficacious system, one in which the satisfaction of ISO requirements is a secondary consideration.

Jim, I hope you don't take offense but I truly hope you don't write your internal documents the way you write your Elsmar posts. I did experience a registrar noncompliance for an organization using the phrase "...all employees practice good stewardship of the customer's product..." or something like that. Nobody knew what 'stewardship' meant; nope, not a single employee. The pretty word did nothing but guarantee a noncompliance for this company. Maybe 'effective' would have been every bit as effective...you think?

but if you set out with banality and needless rigor aforethought, you'll wind up with a system that's banal and needlessly rigorous.

OK, I give up. Any takers on what Jim is talking about here?

Thanks for the very challenging critique of my post Jim. I just love this site - it makes us all think and try harder to understand what it is we are doing. I have probably gained more through my brief stint here on Elsmar than I have in the last half dozen seminars I have attended.:thanx:
 

Helmut Jilling

Auditor / Consultant
OK, I have a question.... (I usually do)

I'm at my cubicle looking around and I have 7 (i just counted) three ring binders full of procedures. How do you keep the procedure writing from exploding into a huge mess where you can't find anything. I'm new at this company and I will say that they have documented everything. :D And I mean everything. But I need to turn the procedures and WI into something mangeable.

You are on the right track.
Obsolete the ones that don't really say anything.
Obsolete the ones that don't seem important or beneficial.
Combine the ones that logically belong together.

Then take a breath and live with what is left for a few months. The rest should become obvious by then.
 
G

Gary E MacLean

Re: How do you decide what is a process, procedure or work instruction?

Gary - come to ONE of mine...........:notme:

Hey Andy, I just today noticed your invitation. Whatcha got comin' up? What do you do? Where do you do it? and so on. Send me a private email. i have a lot of clients who need help.
 
P

Pazuzu - 2009

How do you decide what is a process, procedure or work instruction? I am in charge of moving my company from QS 9000 to TS 16949 and I am having trouble knowing where to start, as far as the Manual (can that be just a restatement of the standard with my organization's name in it), Procedures (I know there are 7 required), Processes and Work Instructions. I am feeling the pressure and would appreciate all the help I can get. Also, can I use most of our QS procedures since I feel they still apply.

Thanks,
P

1. Do NOT restate the manual! Your manual is YOUR manual and should dictate what YOUR company does. The worst thing companies used to do was regurgitate the manual because the CEOs then felt that ISO was controlling their business. Now a lot of top management are anti-ISO because of this.

2. Processes are any activity that takes an input and changes it to an output. Try to keep them fairly broad...it's far to simple to dig down to the smallest of processes and then you'll get caught up in a ton of useless paperwork. Procedures should reflect, at a high level, what goes on in your facility. In essence procedures and processes are synonymous. Work instructions are just lower level detailed descriptions of how things are done.

One of our processes is printing.

The procedure is to take stock, screens, and ink, set up the press, print, and take down (of course that's with a bunch of inspections and testing etc...).

Throughout this there could be dozens of work instructions from "Mixing Ink" to "Registering the Screen" to "Filling out the control record".
The important thing is deciding which instructions are actually needed. Will the lack of instructions be either a detriment to the company or a risk to the customer? If "no", leave them out. If (potentially) "yes", keep them in.

Hope this is a decent guideline. Good luck and happy writing!
 

Jim Wynne

Leader
Admin
1. Do NOT restate the manual! Your manual is YOUR manual and should dictate what YOUR company does. The worst thing companies used to do was regurgitate the manual because the CEOs then felt that ISO was controlling their business. Now a lot of top management are anti-ISO because of this.

2. Processes are any activity that takes an input and changes it to an output. Try to keep them fairly broad...it's far to simple to dig down to the smallest of processes and then you'll get caught up in a ton of useless paperwork. Procedures should reflect, at a high level, what goes on in your facility. In essence procedures and processes are synonymous. Work instructions are just lower level detailed descriptions of how things are done.

One of our processes is printing.

The procedure is to take stock, screens, and ink, set up the press, print, and take down (of course that's with a bunch of inspections and testing etc...).

Throughout this there could be dozens of work instructions from "Mixing Ink" to "Registering the Screen" to "Filling out the control record".
The important thing is deciding which instructions are actually needed. Will the lack of instructions be either a detriment to the company or a risk to the customer? If "no", leave them out. If (potentially) "yes", keep them in.

Hope this is a decent guideline. Good luck and happy writing!

This is very good advice. :agree1: I would only add that process documentation, and in particular work instructions, serves a purpose beyond providing instructions for operators. Work instructions are still functional and important even if operators never look at them, because they (should) serve as a record of process design, and documentation of the way the process must be operated in order to produce conforming output.
 

Helmut Jilling

Auditor / Consultant
1. Do NOT restate the manual! Your manual is YOUR manual and should dictate what YOUR company does. The worst thing companies used to do was regurgitate the manual ...

Throughout this there could be dozens of work instructions from "Mixing Ink" to "Registering the Screen" to "Filling out the control record".
The important thing is deciding which instructions are actually needed. Will the lack of instructions be either a detriment to the company or a risk to the customer? If "no", leave them out. If (potentially) "yes", keep them in.....


There are many opionions how to do this. I will present a couple different opinion than this. You will see many different opinions here at Elsmar. Maybe some good training would help, too.

1. I suggest you should develop your processes, first, before you worry about procedures or anything else. In QS, procedures were the focus. In TS, the system begins with your processes.

Processes are the functions your company does. Manufacturing, Engineering, Design, Purchasing, Training, Calibration, etc. Unlike QS, TS wants you to define these activities using the terms you are familiar with. Make a list. When you are finished, your list of processes must cover all the activities that your organization does, whether manufacturing related, or administrative. Some companies like to divide their processes into the main ones that relate directly to the product, and those that indirectly support those functions.

You should not proceed to writing a manual, procedures or instructions until you have done that exercise, and the management team buys off on the list. Because that list of processes drives the rest of the system. See clause 4.1 for more on this.

In QS, the system was defined by 20 elements. In TS, your system is defined by the processes you defined.

2. Once you have your processes defined, you need to consider what kind of stuff do you need to write down to make sure these processes operate the way you want. This will help you decide what documents you will need. If a process will work just fine without any documented stuff, then you don't need any for that process. Of course, we know that most processes are just not that robust. But, the point is, you get to decide what YOU need to control your processes. The TS standard mentions a few docs as a starting point in cl 4.2.1, and 4.2.2. They say at a minimum, you need a policy, a manual, at least the seven procedures, PLUS whatever else you need to control what you all do.

You can write the manual summarizing what the standard says, or write your own. That is your choice. What will help you manage your processes the best. You can write procedures, instructions, or combine them into one. After all, is there really that big a difference between a procedure and a work instruction? Can't an instruction be a procedure? If I call it an SOP, is it an instruction or a procedure? The point is, don't worry about these things. Draft a manual, and the documents you think will help the company manage the processes and activities.

3. Gradually develop this over time until you have a relatively mature system. Get 12 months of data.

4. Get certified by a good registrar that understands the true purpose of all this is betterment, not just a certificate.

5. Continually improve.

Plain and simple Definitions:
Process - an activity or function that you do. Most departments will be performing processes. They will take something from a previous process, do something with it, and hand it to the next process. When you are done, you have a product to sell to a customer.

Procedure - A method for doing something. A method for performing a process.

Documented Procedure - Taking the method above, and writing it down.

Instruction - Typically a more detailed document describing the methods in more detail as to what needs to be done.

Good luck with this. Let me know if we can help more. I and others on this Cove also do private training in these matters.
 
P

plastic

Hi - thanks for your post on the difference between WI and procedures . . . I have a question for you.
This is the way I would like to set up our Manual - could you let me know if it flows right and if i am meeting the standard with this format.
I want our manual to first consist of and introduction to our company including our scope and any exclusions, our Quality Policy and Quality Objectives. i don't feel that restating the standard after this is beneficial and at the same time i don't want to restate the standard with references to our processes/procedures/work instructions/documents. i really don't have the time for this, i am unfortunately under some time constraints. What i would like to do is have a matrix of all shall statements and reference where we meet these within our processes/procedures/work instructions/documentation. After this matrix i would follow with our Customer oriented processes and support processes for each - i would also include procedures and work instructions that are pertinent to each process. At the end or maybe before the COP's i would include all Managment Processes and any procedures/work instructions that are pertinent to each of these processes.
The biggest question i have is the Matrix idea.

Thanks in advance for your help.

Plastic
 
P

Pazuzu - 2009

Hi - thanks for your post on the difference between WI and procedures . . . I have a question for you.
This is the way I would like to set up our Manual - could you let me know if it flows right and if i am meeting the standard with this format.
I want our manual to first consist of and introduction to our company including our scope and any exclusions, our Quality Policy and Quality Objectives. i don't feel that restating the standard after this is beneficial and at the same time i don't want to restate the standard with references to our processes/procedures/work instructions/documents. i really don't have the time for this, i am unfortunately under some time constraints. What i would like to do is have a matrix of all shall statements and reference where we meet these within our processes/procedures/work instructions/documentation. After this matrix i would follow with our Customer oriented processes and support processes for each - i would also include procedures and work instructions that are pertinent to each process. At the end or maybe before the COP's i would include all Managment Processes and any procedures/work instructions that are pertinent to each of these processes.
The biggest question i have is the Matrix idea.

Thanks in advance for your help.

Plastic

From an auditor standpoint it's a great idea...no need to dig around and all the info is readily available. However, that being said, you shouldn't be building any documentation systems to primarily satisfy ISO or your auditors. It should first satisfy your company and business directives, then it must conform to ISO requirements. There are ALOT of "shall" statements and this would create additional documentation that doesnt need to be there. As well, it would still remain a very "ISO-driven" manual as oppossed to your company's business plan (which in essence the QM is).

I'm very interested to hear other opinions of the matrix however!! This could be interesting.
 

Helmut Jilling

Auditor / Consultant
Hi - thanks for your post on the difference between WI and procedures . . . I have a question for you.
This is the way I would like to set up our Manual - could you let me know if it flows right and if i am meeting the standard with this format.
I want our manual to first consist of and introduction to our company including our scope and any exclusions, our Quality Policy and Quality Objectives. i don't feel that restating the standard after this is beneficial and at the same time i don't want to restate the standard with references to our processes/procedures/work instructions/documents. i really don't have the time for this, i am unfortunately under some time constraints. What i would like to do is have a matrix of all shall statements and reference where we meet these within our processes/procedures/work instructions/documentation. After this matrix i would follow with our Customer oriented processes and support processes for each - i would also include procedures and work instructions that are pertinent to each process. At the end or maybe before the COP's i would include all Managment Processes and any procedures/work instructions that are pertinent to each of these processes.
The biggest question i have is the Matrix idea.

Thanks in advance for your help.

Plastic


I can't say for sure without actually auditing it, but it sounds like it could work.
 
Top Bottom