Hi, my name is Bryan and this is my first time posting here at the Cove. My company is currently undergoing the implementation of ISO 9001:2000 and I've been assigned as the point man directly underneath the MR.

My first objective to tackle our Action Items is to work on our Work Instructions. I've been searching the Internet for sample Work Instructions and came across a few decent ones. However, hardly any work instruction is similar to the next.

The WIs I am currently working with contain four sections; Purpose, Scope, Responsibilities, and Procedure. Those are the meat and potatoes of the WIs as I see it. Am I required to have any more sections included? I don't recall seeing anything within the standards that say so. Please correct me if I'm wrong.

Also, as the person working on the Work Instructions, I need to go around to every department to observe and compile various WIs. Such departments include: Shipping, Receiving, Production, Purchasing, Inventory Control, Customer Service, Engineering, IT, Accounting and Administrative Assistance. My question is, is there a list available that may mention what kind of WIs should be available in each department?

For example, in Purchasing there will need to be WIs on the following:
1. Add new vendor
2. Add new purchase order
3. Faxing orders
4. Printing purchase orders
5. etc..

Some of these departments seem like they would have quite an extensive list of work instructions; however, I'm not sure of any of them.

Does anyone have some kind of list that would help me?

Thanks,
Bryan

Hi Bryan - welcome to the cove.

The are more ways to do work instructions than there are stars in the sky.
In the system I'm building I am very open as to format. My instruction to the people who are creating the work instructions is:

Write them so that the users will understand them.

So each department may use a different format for the instruction itself - some might do a traditional outline numbered format, some might do a step by step table with photos, some might use a flow chart.

what is constant is the page header and footer and the following sections: purpose and scope, responsibility and authority, body, references, revision history.

I note you say that you're supposed to observe and document...
Be careful. If you are not the process owner, you might not get the real story by just observing. Workers may do things differently if they know they're being observed. You MUST have particiaption from the process owner when creating a procedure or work instruction. I strongly suggest you review the document with at least one person that does the job before you try to get it published.

as far as a list... It's really up to your organization on what is worthy of a work instruction. By nature work instructions are detailed. You can bog yourself down quickly. You need to evaluate, for example, if the shipping guy needs a written instruction on how to pack a carton. My company sure doesn't - it would be tying his hands to no real purpose.

good luck.

I thought work instructions were meant to be written for those who have no idea on what to do. Packing a carton may be a no brainer for the shipping supervisor, but what about a new guy who comes in? Should the shipping supervisor have to train each and every single person to do a certain shipping activity? Or should there be a work instruction for those activities to alleviate extensive training?

Of course I will work with each department head rather than just observe them. I'd just like a list of what I should look for prior to spending time each head.

Thanks for the quick reply

Bryan

I thought work instructions were meant to be written for those who have no idea on what to do. Packing a carton may be a no brainer for the shipping supervisor, but what about a new guy who comes in? Should the shipping supervisor have to train each and every single person to do a certain shipping activity? Or should there be a work instruction for those activities to alleviate extensive training?

Of course I will work with each department head rather than just observe them. I'd just like a list of what I should look for prior to spending time each head.

Thanks for the quick reply

Bryan


It's really up to you. The thing is if you document a certain way you darn well better do it that way every single time. So you can really tie your hands by overdocumenting. In theory you get ISO registration without a single work instruction.

In my philosophy training is paramount. So to answer your question - yes, the supervisor should train all his staff. Even if there is a work instruction he needs to traing his staff. You can't just plunk someone down with a document and say "get to work". Work instructions do not take the place of training. They are for reference for people who are already trained and a tool for use during training.

In my company (machining and assembly) we're only really doing work instructions for assembly of finished goods and for certain tests. And even then the assembly work instructions are based on product family, not every individual product.

Oh I understand completely. Our supervisors will train, but after they trained their employees, we didn't want the new hires to have to ask them questions over and over again. Thats when they can reference the work instructions.

As for writing the instructions, I'm going to be as vague as possible without setting directions in stone.

Thanks for the response, it's becoming more clear to me now.

Oh I understand completely. Our supervisors will train, but after they trained their employees, we didn't want the new hires to have to ask them questions over and over again. Thats when they can reference the work instructions.

As for writing the instructions, I'm going to be as vague as possible without setting directions in stone.

Thanks for the response, it's becoming more clear to me now.

here's a thought you may want to approach your MR with....

Job descriptions and job orientation. A robust job description and orientation program can help eliminate the perceived need to document routine tasks.

another suggestion - if you're about to document a work instruction and you have doubts if it's necessary - come back to this thread and ask for an opinion.
I wish I had a resource like this when I was on my first ISO implementation team in '95. :cool:

Welcome to the Cove, Bryan :D

My company is currently undergoing the implementation of ISO 9001:2000 and I've been assigned as the point man directly underneath the MR.

If you're going to be spending a lot of time directly underneath the MR, I hope you have (and use) an umbrella. :lol:

Also, as the person working on the Work Instructions, I need to go around to every department to observe and compile various WIs.

I think that you should, for the moment, be less concerned about format than about actual content. This is a stage where many opportunities for improvement are missed. Rather than just accepting whatever's presently written down, you should be talking to the people who are involved in operating the processes on a daily basis, and find out what's working and what isn't, with a view toward codifying the former and eliminating the latter. Make sure that processes actually work before doing any formal documentation.

Hi Bryan and welcome to the Cove -

I have to agree with Jim and Discordian - they have some great points.

It is nice to have a "standard" format - but always remeber that you need to set your format to the "lowest" requirement. What I mean, is be cautious not to fill your work instruction with info that means nothing to the user, or can't be understood by the user.

You state that you need "Purpose, Scope, Responsibilities, and Procedure" - why do you say that. Take your example of the new guy coming in to pack parts. All he needs to know is what work instruction to use, and how to do it. Purpose and Responsbility mean nothing to him.

Here is an example

Scope: use this instruction to pack part 123.

Procedure:

Use a 12 x 12 x 12 box

Place 50 pieces in box

Fill open space with paper.

Tape box closed.

Affix shipping label.

There you go - it is done and very simple.

JMHO and hope this helps a bit.

You guys and gals are very helpful here. Thanks :)

Besides 'observing', per se, I'm also asking questions on their tasks. Such as what they do, how they do it, why they do it, and tell me without using shortcuts. I went through the Shipping Department yesterday and compiled about 8 pages worth of notes. Today I'm going through the Receiving Department and Service/Repairs Department to do the same thing.

My MR seems satisfied with the information I compiled with Shipping so I think we're on the right path. Making these instructions as cut and dry as possible seems to be the more complicated portion of this task.

Whenever I take my notes and turn them into work instructions, I will post one up for opinions and criticisms.

Thanks again,
Bryan

The WIs I am currently working with contain four sections; Purpose, Scope, Responsibilities, and Procedure. Those are the meat and potatoes of the WIs as I see it. Am I required to have any more sections included? I don't recall seeing anything within the standards that say so. Please correct me if I'm wrong.

Also, as the person working on the Work Instructions, I need to go around to every department to observe and compile various WIs. Such departments include: Shipping, Receiving, Production, Purchasing, Inventory Control, Customer Service, Engineering, IT, Accounting and Administrative Assistance. My question is, is there a list available that may mention what kind of WIs should be available in each department?

For example, in Purchasing there will need to be WIs on the following:
1. Add new vendor
2. Add new purchase order
3. Faxing orders
4. Printing purchase orders
5. etc..

Some of these departments seem like they would have quite an extensive list of work instructions; however, I'm not sure of any of them.

Does anyone have some kind of list that would help me?

Thanks,
Bryan

Bryan:

So good that you got some help here, first. You were heading for oblivion and one big head ache in the future. As stated above, don't use this bureacracy of 'scope', 'purpose' etc. It delays getting to the important stuff. Also, as Jim says, get the folks who know the job to help write down what's important. A checklist is better than some long winded description, written for a 16yr old, who's never going to work there, anyway.

I'll poke around my files and see if I can't give you an effective format for a WI - ther are some already posted here somewhere, but they may have that 'old school' format:mg:

Andy

Andy,

That would be great. Well like I said I searched around for work instructions and the majority of the ones I found included a Scope and Purpose. I basically just wanted to know if there were anything in the Standards that required such topics?

Thanks,
Bryan

No, nothing in the standards and all that 'formality' just gets in the way of getting to 'the good stuff', as it were. FYI - it originated in many cases from the old military documentation and has been a carry over since. The focus wasn't on the clarity or efficiency of the document, only that anyone could pick it up, read it and get an idea of what it said - a bit like an auditor does (!).

Well, 'modern' WI's don't have to include that low value text. I have some files which are based on 'standard work' which many people here will be familiar with at their organizations - not my invention. Very graphical/visual in nature and can be adapted for use in office settings too.

It'll be a couple of hours before I track down where I've got them recorded (since I've changed my computer and backed everything up).......:rolleyes:

Andy

I believe the following statement says more about the environment and things to work on than any need for wriiten instructions:

"we didn't want the new hires to have to ask them questions over and over again."

If you have environment where employees are expected to only ask so many questions, you've got problems with the culture that cannot be fixed with any written work instruction or procedure.

Also, different documents have different purposes. A work instruction on how to pack a box maybe written much differently than a document that describes the basic shipping process. In certain applicaitons, I would highly suggest flowcharts over written text.

Regards,

Dirk

I wouldn't say there's anything wrong with our work culture environment. Perhaps I worded that wrong. We encourage the asking of questions, but if certain questions are asked repetitively, then I think its appropriate to hand them a work instruction. We perform training in every department, but we also somewhat encourage new hires to learn by doing instead of observing.

I never thought of using flowcharts in our work instructions. I'll definitely take a look into those. I've put together a few WIs for the shipping department and I'll have to put them up to receive feedback when I get back to the office. So far so good, but there's so much more to accomplish.

Thanks everyone,
Bryan

The simpler the better... Work Instructions should serve its primary Purpose... To give direction to the worker on what should be done in proper order and should also be user friendly that a new intake could easily understood and follow....

Just my 2 cents............:D

Here's a standard work (a.k.a. Work Instruction) I created as a flow-chart to cover document creation & updating.:cool:

For example, in Purchasing there will need to be WIs on the following:
1. Add new vendor
2. Add new purchase order
3. Faxing orders
4. Printing purchase orders
5. etc..

Some of these departments seem like they would have quite an extensive list of work instructions; however, I'm not sure of any of them.

Does anyone have some kind of list that would help me?

Thanks,
Bryan

Bryan, I have a couple of thoughts.

Document as WI's only those processes that need them.

I doubt that a WI to fax a PO is value added, although a WI on how to operate the fax machine may be.

A WI for printing PO's? Probably not but a procedure on who/why creates PO's maybe.

I think WI's serve two purposes: training of new people and a refresher for those tasks that are not inherently obvious. For instance there probably is not a WI for checking your e-mail, but there could be one for archiving e-mails.

Just my thought on this, you should have the pople that do the job write the procedures, that way it is written in words that they use and understand. Being an outsider to the process you might place word in the procedure that you understand but they will not. Just my thought.

Glen

Just my thought on this, you should have the pople that do the job write the procedures, that way it is written in words that they use and understand. Being an outsider to the process you might place word in the procedure that you understand but they will not. Just my thought.

Glen

This is a good idea only rarely. The sad fact is that there are many people who can't write worth a hoot, and and many of them write procedures and instructions. The actual writing of the documentation should be left to those who know how to write.

Just to add on this thought, I never ment them to write the procedures themselves but to give you the information to do so. I found that if someone that is not envolved with their work writes the procedures without imput from them they will generaly not follow them. Something I learned the hardway. All you need is to have explain what they do and you write it the procedure for it.

I understand where you're coming from and that is what we are doing. I am sitting down with each individual asking them how things are done. I'm not necessarily observing their procedures, but I am writing down the instructions and procedures that they follow. (Hope that made sense)

And you're right, there needs to be a set person to write and document everything. If every department head wrote their own procedures and instructions, there would be no single format or standard.

Tomorrow I will post a Work Instruction that I need to ask questions on and hope to receive further feedback.

Thanks again everyone,
Bryan

All you need is to have explain what they do and you write it the procedure for it.

I'm not necessarily observing their procedures, but I am writing down the instructions and procedures that they follow. (Hope that made sense)Certainly, you want to involve the process owners to understand the processes at hand, instead of creating WI's and procedures "from the vacuum" in the conference room. However be CAREFUL not to institutionalize dysfunctional processes, by capturing them into command media. A step of the document development process should be a critiquing mechanism so other stakeholders of those internal processes being documented might be able to improve it. Failure to do so just promote the deployment of ineffective, inefficient and dysfunctional processes.

Contrary to popular belief, ISO 9001 is NOT "do what you say, say what you do...."

I have a question about WI too that maybe I could get an opinion on.
During the beginning stages of our ISO journey, the people who performed the work were asked to make WI to satisfy (what was thought to be) an ISO requirement. They were told to make them simple and not to refer to part #'s in the builds as these #'s change frequently and they don't refer to any drawings etc. All those references were basically taken away. (This means they have them hidden in draws and filing cabinets.) So what we have now is 100's of WI that are either not required. (The process is repetitive or simple) or inefficient work instructions that are of no help.
We have just been recommended for registration. The assessment really didn't get too much into the WI area but I believe future Audits will reveal problems, maybe not CARs, but might address the need for WI improvement. If it was up to me, I would write up that the WI's that we have are ineffective, but then again, I have hindsight. I see people working in an area when someone suddenly is away and they're trying to use these "work instruction" and they're failing miserable, production is stopping/slowing or who knows what is being shipped out. It really is a mess. Our assemblers are assembling some pretty complicated things, and variations etc. I really think some good detailed instructions would be a good way to capture the knowledge of these workers before they all start to retire, or worse, before they all win lottery pool!
I've talked to the people on the floor and the authors of the original WI agree that the WI would not be useful to someone who would need them in the future but how do I convince management that they need to be redone? The Lead Auditor, who is also the person responsible for updating revisions doesn't want me to pursue this because of the extra work in controlling document changes. I don't want to overstep anyone but I KNOW what is going wrong on the floor.

I need some possible scenarios that might occur before I talked to the coordinator. I don't want to center any of the workers out, and possibly make them feel they're in trouble or anything.
Can the external Auditors say these instructions are not effective?
What if an employee says they don't use their WI because it is not helpful?
That would mean they're not being reviewed for their effectiveness?
I am ready to role up my sleeves and get busy if that helps.

Good morning everyone,

Attached is a little work instruction I put together and I have a few questions on it:

1. Dates: Does there need to be an Issued date? If so, what exactly is an issue date; the date its printed off or the date its physically given to the department to use?

2. Dates: In the footer, we have a Created By, Verified By, and Approved By with dates. I created these three sections for traceability; is it required/recommended or could I do away with them? Also, after each signature block is a date block; do we really need to know when each person signed the work instruction?

Simply because I may sign it one day and then a couple months later it may be approved. Is the date when it was approved the issue date as well?

Thanks,
Bryan

Good morning everyone,

Attached is a little work instruction I put together and I have a few questions on it:

1. Dates: Does there need to be an Issued date? If so, what exactly is an issue date; the date its printed off or the date its physically given to the department to use?

2. Dates: In the footer, we have a Created By, Verified By, and Approved By with dates. I created these three sections for traceability; is it required/recommended or could I do away with them? Also, after each signature block is a date block; do we really need to know when each person signed the work instruction?

Simply because I may sign it one day and then a couple months later it may be approved. Is the date when it was approved the issue date as well?

Thanks,
Bryan

Bryan,

We do our docs electronically, but we have an origination date (date doc was first created), review dates when it was reviewed before it is approved as final, approved as final dates, date doc is effective and a review by date (typically 1-2 years after the effective date).

Looking at the document I would simplify it by not having a third numbering (e.g. 2.3.1) - it looks like they would all fit under 2.3. Just my :2cents:

During the beginning stages of our ISO journey, the people who performed the work were asked to make WI to satisfy (what was thought to be) an ISO requirement.It is not. So what we have now is 100's of WI that are either not required. (The process is repetitive or simple) or inefficient work instructions that are of no help.Get rid of the ones that are not required and ensure that the required ones reflect the tasks and activities at hand.I see people working in an area when someone suddenly is away and they're trying to use these "work instruction" and they're failing miserable, production is stopping/slowing or who knows what is being shipped out. It really is a mess. Our assemblers are assembling some pretty complicated things, and variations etc. I really think some good detailed instructions would be a good way to capture the knowledge of these workers before they all start to retire, or worse, before they all win lottery pool!
I've talked to the people on the floor and the authors of the original WI agree that the WI would not be useful to someone who would need them in the future but how do I convince management that they need to be redone?Can you provide data to management about non-conforming products, customer returns, productivity drops which can be traced to substandard assembly as a result of ineffective WI's? If you can, those would be powerful arguments added to the knowledge management piece.

In addition to Sid's excellent advice, I think there's a utility for work instructions that's almost always overlooked. Before instructions are written, the design of the process should be verified--it should be confirmed that if the process operates in accordance with the instructions, nothing bad is likely to happen. When it comes time to actually document the operation of the process, the written instructions also become a record of those efforts, and a reference for how the process must be operated. Work instructions are all about standardization, and the people who operate the process must understand that there is one way and only one way, to do it properly. If you can't do that, you need to go back to the process design phase.

Bryan - first off - well done!!
:applause: :applause:


1. Dates: Does there need to be an Issued date? If so, what exactly is an issue date; the date its printed off or the date its physically given to the department to use?

I have approval date on mine - that is the day it is approved and issued for use.
KIS (keep it simple)


2. Dates: In the footer, we have a Created By, Verified By, and Approved By with dates. I created these three sections for traceability; is it required/recommended or could I do away with them? Also, after each signature block is a date block; do we really need to know when each person signed the work instruction?

Do you really need all that info? Created, verified and approved by - you only need to know who approved it and when.

Simply because I may sign it one day and then a couple months later it may be approved. Is the date when it was approved the issue date as well?


Why would you sign it one day and not issue it immediately? Why the extra steps?

Thanks Syd, Thanks Jim.
I know you're both right.

I think I was looking for an easy fix, namely a sure external finding that will occure if there isn't something done, to scare up action. I wouldn't really do that, but it's nice to know I can. :)

But what I did not know is that the WI could be used as proof/records of a process. That's very good to know for when the bridge comes.

I am new to this forum as well. I agree with the other fine folks do not get caught up in a specific format, ISO doesn't require a specific format you determine what works for your company then define it.

[B]When To Document:
When activities:
> Are very complex or difficult to remember
> Have critical sequencing
> Have important measurements and proportions
> Are not common or are rarely performed
> Are subject to a high rate of employee turnover or performed by temporary help.

Risk of losing the body of knowledge.
Customer, government or standard required.
Training alone is not adequate.

Hope this helps.