:bigwave: Hello,
I desperatly need some help on how to write quality procedures and work instructions. Examples of each would be fantastic. I am a student doing a six week project to help improve a medical manufacturers Quality System, they have 35 employees, so any help would be greatly appreciated. I have only three weeks left so what do you suggest I can do?

The current system has a quality manual and all other documents are basically lumped together. Have spoken to several people in the company who say its just gotten out of control. Would like to be able to show them how they could write there documents in a clearer way and how they could be structured in a pyramid way.

Steve :frust:

P.S My project has now changed direction after the advice which has been given on this forum. The aim now is to flowchart the design and development procedure and then to write documentation based on this.
Any tips on flowcharting or the process approach and any useful links would be greatly appreciated.
Also what are the differences between flowcharting a procedure and the "process approach" ?

Here is an example of a Standard procedure, and a work instruction we have here. Hope this helps

:bigwave: Hello,
I desperatly need some help on how to write quality procedures and work instructions. Examples of each would be fantastic. I am a student doing a six week project to help improve a medical manufacturers Quality System, they have 35 employees, so any help would be greatly appreciated. I have only three weeks left so what do you suggest I can do?

The current system has a quality manual and all other documents are basically lumped together. Have spoken to several people in the company who say its just gotten out of control. Would like to be able to show them how they could write there documents in a clearer way and how they could be structured in a pyramid way.

Steve :frust:
Hi, Steve
not understand your question clearly. do you mean this company has a ISO9001:2000 certificate but with poor performance on system running? your role is to help them for improvement?
It's too short time for 3 weeks to improve system performance. You know for some bad system, most cause was not against system self, mainly from people's problem, they do not have good awareness.
sometimes, it's problem on establishing quality system. If system was not designed for practical operations,a big problem,lots of waste.
My suggestions, talked with related person in that company, what they feeled on current documented system? then read/understand ISO9001:2000 standards, find the gap with current document.
basing on employee's competence. documented system could be simple. make sure you could link procedures in quality manual,link work instruction in procedures, link related forms in procedures/work instructions.
hope helpful.

Hello Steve and welcome to the Cove.:bigwave:

I do believe we can give you a hand, but I'm not able to provide much in the way of examples, since all my stuff is in Swedish !!:eek:.

First of all I suggest that you ask questions about the separate procedures / instructions you have in mind in separate posts (rather than lumping them all together - which as you already noticed is not the best way to do it ;)). I'm certain you'll get help that way.

Secondly, it's usually a good idea to keep things as simple as possible and minimize the use of text by using graphics whenever you can.

All our procedures begin with the following three things: Scope, Purpouse & Responsibility. When you have them sorted out it's usually a lot easier to write the rest.

And hey: Good luck.

/Claes

Steve,

The "pyramid" structure you mention can be used, but there are other ways if it works better. The pyramid is basically

LEVEL 1 - QUALITY MANUAL (tip of the pyramid_
LEVEL 2 - PROCEDURES (WHO, WHAT, WHERE, WHEN)
LEVEL 3 - WORK INSTRUCTIONS (HOW)
LEVEL 4 - RECORDS (base of the pyramid)

What you can accomplish in 3 weeks is a good question, and will depend on exactly what is there already. Maybe you can start something and hand it off to someone else when you leave. I'd ask the people there what they feel is most in need of fixing to help them in their daily work. Get their buy-in. For example, maybe if they feel their work instructions are written wrong (what is written is not that they do), or are too confusing, etc. you can make a project of going over the existing WI with the folks that do the work or are in charge of the process, seeing where the docs. are wrong, and then correcting them and making them simpler via flowcharts, etc. But much will depend on what is there already. You can't perform miracles in 3 weeks.

Steve,

The "pyramid" structure you mention can be used, but there are other ways if it works better. The pyramid is basically

LEVEL 1 - QUALITY MANUAL (tip of the pyramid_
LEVEL 2 - PROCEDURES (WHO, WHAT, WHERE, WHEN)
LEVEL 3 - WORK INSTRUCTIONS (HOW)
LEVEL 4 - RECORDS (base of the pyramid)

What you can accomplish in 3 weeks is a good question, and will depend on exactly what is there already. Maybe you can start something and hand it off to someone else when you leave. I'd ask the people there what they feel is most in need of fixing to help them in their daily work. Get their buy-in. For example, maybe if they feel their work instructions are written wrong (what is written is not that they do), or are too confusing, etc. you can make a project of going over the existing WI with the folks that do the work or are in charge of the process, seeing where the docs. are wrong, and then correcting them and making them simpler via flowcharts, etc. But much will depend on what is there already. You can't perform miracles in 3 weeks.


Mike:

Yes, but I would like to add the quality policy in there, too. Some people make that a part of the Q Manual (level 1), some don't. I tend to see the Q policy as being at the "top", but it could be seen as being "even" with the Q Manual, as well, I guess.

Craig

Just a thought,
We do not use a Quality Manual - it is our Operations Manual.
We show how the Company Goal aligns with the Company Mission Statement which aligns with the Quality Policy Statement, etc. etc..
IMO it is easier to see how the procedures, work instruction, etc. help support the chain going up.
It has also assisted in the integration process by combining not only the ISO-14000 and TS but it addresses the internal controls, hoshin, 5-S and other initiatives we have been assigned.

Steve

I guess that as a student you have been given quite a direct instruction to 'sort out the companies procedures', with little else to tell you whats wrong with them, and why they need change.

The very directive to 'sort out procedures' is steeped in the ISO9001:1994 (and predecessors) mindset.

There is actually far more to quality than writing procedures.

The revised ISO9001:2000 standard has shifted fundementally from its predecessors. I imagine that you are in a 1994 certified company overrun with documentation.

ISO9001:2000 is based on the 'process approach' to management. The old requirements to maintain vast amounts of instructional documents is gone, primarily you have to identify and manage your processes effectively.

I suggest you identify the companies processes and how they interact (via process mapping), identify the process owners, have the management team decide on key performance indicators, and then set up some decent data capture and reporting systems to monitor process performance against these objectives.

You will find that process mapping to a reasonable depth (say 3 to 5 levels) will give you good graphical representation of your traditional text based procedures, and you may well find that they become naturally redundant.

So you will have purged the system of the onerous documentation, and set up a good system of real performance measures - the company will forever be in your debt !!

Steve

I guess that as a student you have been given quite a direct instruction to 'sort out the companies procedures', with little else to tell you whats wrong with them, and why they need change.

The very directive to 'sort out procedures' is steeped in the ISO9001:1994 (and predecessors) mindset.

There is actually far more to quality than writing procedures.

The revised ISO9001:2000 standard has shifted fundementally from its predecessors. I imagine that you are in a 1994 certified company overrun with documentation.

ISO9001:2000 is based on the 'process approach' to management. The old requirements to maintain vast amounts of instructional documents is gone, primarily you have to identify and manage your processes effectively.

I suggest you identify the companies processes and how they interact (via process mapping), identify the process owners, have the management team decide on key performance indicators, and then set up some decent data capture and reporting systems to monitor process performance against these objectives.

You will find that process mapping to a reasonable depth (say 3 to 5 levels) will give you good graphical representation of your traditional text based procedures, and you may well find that they become naturally redundant.

So you will have purged the system of the onerous documentation, and set up a good system of real performance measures - the company will forever be in your debt !!


Ah, Martin, how right you are.

If Steve does not know what is needed (and what belongs in the trash) he will never be able to fully and effectively "sort out" the system. At this point, it might seem to be a waste of valuable time, but planning now will save headaches later.

Good post.

:bigwave:

Craig

Hi, thankyou everyone for your messages

Could please give some useful tips on the "process approach".
I have looked into how to use the "process approach" but only understand that it is an important idea behind ISO 9001:2000. I will do some research into how to apply process mapping to the company, but would be interested to know what Martin meant by "key performance indicators".

Also how much process mapping could be reasonably achieved in three weeks? I know management want me to concentrate on design and development of their medical products.

Thanks for everybody's help

Steve

In a small company I reckon you could have reasonable process maps within a week, however it may take you a little while to understand the technique of process mapping - time is very tight for you im afraid.

You could start by trying to map the current design process at your company, then do a gap analysis between what you have seen and the design requirements in ISO9001:2000 (clause 7.4 at a guess).

Important things to consider are how the company tackles the main sub clauses, such as design planning, design review, design verification and design validation.

Key performance indicators for the design process may well be things like project completion to planned date, expense to budget, engineering changes required.

Here is an example of a Standard procedure, and a work instruction we have here. Hope this helps
ralphsulser,
Are all your procedures that long? It almost seems like a work instruction to me, given the detail. IMHO it's way too long for most people to use, but then maybe it suits your business.

:I am a student doing a six week project to help improve a medical manufacturers Quality System, they have 35 employees, so any help would be greatly appreciated. I have only three weeks left so what do you suggest I can do?

Hi Steve -

I'm curious, what is the class you are taking? And I was wondering what the main objective of the assignment is, given that you only have 6 weeks.

Try a search of the forums using the words "process mapping". There are alot of samples of manuals and maps all over.

Keep us posted how you're doing. :)

HI CARI
:bigwave:
The initial aim of the project was to "computerise" the quality system, this meant placing all relevant documents on to a web-based programme so that employees could use a computer to find the relevant work instruction for their job. A lot of the work is repetitive and requires alot of quality checking since they make implantable medical devices. Management felt that staff weren't using the documentation since it was inaccessible(physically) however it seems to me that the work instructions have been written in a very confusing fashion and this was the reason why they didn't bother to look at it.

The project has changed its objectives and the aim now is to come up with a "plan of action" to improve their quality management system. Hopefully when I will leave in a few weeks the directors will be clearer about what they want and how to go about doing it. The problem I faced at the beginning of the project was that management didn't know what they wanted from me and what they were aiming towards.

I am currently studying Mathematics and the project was meant to be purely IT, so I have had to learn quickly about ISO and FDA standards etc...
I'm getting interested in it, but have no experience of this type of work at all!!!

Hopefully will do some process mapping for them on design and development because this is an area where they would like to improve efficiency.

Thanks for your help
Steve :)

Steve,

I would seem that you are moving in the right direction. It is utterly useless to computerize a poor system. Realizing that and moving the focus to improvement of the system must clearly be the correct path.

The advice to map the processes is spot on too: I think it's a fair bet that the written procedures won't match the processes you come up with. Then you'll know what to scrap and what to improve. Three weeks though... At least you will have time to get started.

Good luck, and do tell us what happens...:agree:

/Claes

We add another layer to the standard document pyramid which Mike mentions above. Craig has part of it in his reply... For my organization, the Top layer of our pyramid is composed of the Quality Policy and our Goals and Objectives. Also, as my site is just one manufacturing uint of a larger whole, our headquarters has another series of documents which also fall into the top layer = we have a corporate Quality Policy with supporting principles as well as a corporate ethics policy (which is also part of the top level documentation).

As for the original topic regarding procedures, we believe in setting some common outline requirements and then suggest optional additions to be included as necessary. Also, it's helpful to have the individuals who own the process either write the procedures themselves, or at least serve as a reviewer of the documents.

Our common procedure requirements are to have a unique Title and Identification #, a Department who owns the document, the Area(s) to which the document applies, the type of document (training, calibration, preventive maintenance, test method, process control, etc.), and the following:
(1) a Purpose
(2) a Scope or Application
(3) Safety (for safety concerns specific to the document, sometimes this is N/A)
(4) Procedure
Some of our optional categories (to be used when appropriate):
(5) Definitions specific to the procedure or unique to our organization
(6) Associated Documents (when one document refers to another)
(7) Roles and Responsibilities (when not specified in the body of the Procedure, a separate section may be used... sometimes, this would also be where employee competency requirements are discussed)
(8) Distribution and Notifications List (who needs to know about the document?)
(9) Equipment
(10) References (Journals, books, regulations, etc.)
Flowchart when you can. This can help describe the process and help keep the document to a reasonable size. I typically try to use at least one flowchart, two at most to provide guidance in the process. If more than two flowcharts are needed to describe the process, then perhaps the procedure may be trying to cover too much ground?

In my organization, we have been through the extreme ends of the spectrum when it comes to documenting our system (from overdocumenting our systems [the old 40 to 50 page procedures] to not enough documentation to understand the process [the one page procedure that does not tell you much]). Over the years, we have fluctuated back and forth a little, gradually finding ourselves somewhere near the equilibrium state between the extremes. Procedure sizes now run around a 4 to 5 page average size. We do have one or two documents which exceed 40 pages, but they are justified in our eyes(vendor safety manuals and such).

Hope this helps? E :rolleyes:

ralphsulser,
Are all your procedures that long? It almost seems like a work instruction to me, given the detail. IMHO it's way too long for most people to use, but then maybe it suits your business.

Not all are that long. I picked one of the longest "Non-Conforming Material Control" because it covers incoming, in-process, finished materials, plus customer issues. We actuall have a work instruction for this subject too.
So far has worked for our operations.

Steve

This is my design and development process.


if you have any questions let me know

Rosana

Steve,
Here is a sample of what we are doing. This is a typical process flow, each box has 3 parts, top - responsibility, middle - function, bottom - link to forms, etc.
It has made process mapping a lot easier and process auditing a lot easier.
We are trying to eleminate all "procedures" and operate on process maps alone. Can't always do it but we are trying.

Again we appear, in my opinion, to be confusing the requirements to define sequence and interaction of processes with simply converting text based procedures into flowcharted procedures.

Flowcharting a procedure, as shown in the previous example, does not define a process, and its sequence and interaction.

In my opinion there must be a top level process map which shows all the major processes of the business. These processes can then be broken down into lower level sub-processes if required. You must show the processes, i.e. the things that convert inputs to outputs, you must show what the inputs and outputs actually are, and you must show where they come from and where they go to.

The example in the previous post is a procedure.

In my opinion there must be a top level process map which shows all the major processes of the business. These processes can then be broken down into lower level sub-processes if required. You must show the processes, i.e. the things that convert inputs to outputs, you must show what the inputs and outputs actually are, and you must show where they come from and where they go to.

I agree with the high level process maps approach. We put these into our QM...

The example in the previous post is a procedure.
Isn't that what was requested? I thought the name of this thread was "Examples of Quality Procedures".
BTW Martin, I called it a process flow. This is a typical process flow,
We are getting away from the typical written "procedure" that are difficult to follow and can fragment responsibility. :rolleyes:

Hello, :bigwave:
Sorry if there has been confusion between people leaving examples of both written procedures and process flowcharts.

This is my fault since I was going to begin the project by writing new quality procedures for product design and development. However I am now looking at the process approach of ISO 9001:2000 and am trying to draw the company a process flowchart for product design and development.

The two examples that were lrecently left have proved really helpfull in what it is required in a process flowchart. More examples like these would be great!!

The pdf file for design and development was really impressive but am confused by whether it is a process flowchart or if its a flowchart of a procedure or can it be both???

Beginning to draw my first process flowchart after a meeting with the product development manager. Will let you know how its going or ask for advice.

Posts 10 and 14 will explain more about what I am trying to achieve.

Once again thanks for all your help
Steve :agree:

Steve,
This is a discussion we have had a few times over the years. You did not cause the confusion. :agree:

In my opinion there must be a top level process map which shows all the major processes of the business. These processes can then be broken down into lower level sub-processes if required. You must show the processes, i.e. the things that convert inputs to outputs, you must show what the inputs and outputs actually are, and you must show where they come from and where they go to.



I know we've hashed this out before, but there is NO requirement for a "MAP".

If a procedure is nothing more than the steps to a process, then why couldn't you simply add the necessary inputs and outputs to the procedure? I am enclosing an example of what I mean. What do you think?

Hello Dave B,

Thanks for leaving an example.
I really liked it because it clearly explained
the pupose of the process, the scope of the process, the suppliers/customers, the inputs/outputs and the process itself.

I also liked the flowchart on the second page which clarified the process.


Just to clarify matters, does a quality procedure describe a process, with the process being quite a high level process for example, Internal Audit Procedure, and a work instruction is a clear list of instructions to complete a "low level" task, for example, calibrating a measuring device?

Regards
Steve

Just to clarify matters, does a quality procedure describe a process, with the process being quite a high level process for example, Internal Audit Procedure, and a work instruction is a clear list of instructions to complete a "low level" task, for example, calibrating a measuring device?



Here is the way I usually describe the differences. A process is an activity. The procedure is the way you enact the activity. Procedures are usually multiple tasks, and often perofrmed by multiple people. Work instructions are typically oriented towards a single task, and are performed by a single person.

I have worked with organizations (typically aerospace) that call their work instructions "procedures". In reality, the name is not important. What is important is that your people:

a) have the competence to do the job
b) have the proper information for the job.

Hope that helps

I agree with Dave, what's in a name. in our update to TS2002 we are now working on processdescription, without tossing all procedures out.

A Proces describes the way we handle the subject (f.e. continuous improvement) and the procedure clarifies the agreements between different departmens to forfill the process description (kind of multiresponseablity workinstruction)

Marcel

Hi, all;

I am setting ordering proceudres and I posted here this morning, but no reply.The first day I registerred and dont' know why no reply.

Thanks,

Lucy

Welcome to the Cove Lucy.
Choose your forum of choice.
Post your questions, issues, process problems, theories and thoughts. It's really that easy.
Enjoy the Cove.
Wallace

Hey Steve !

For Process Approach you dont have to sweat a lot. Just remember that as a process owner your own the responsibility for complete care of the process to make it profit oriented. This is the basic. Other steps to meet the requirements of Clause 4.1 of the standard are as follows;

1. First of all sit down coolly and call the heads of the processes and brainstorm on what are the processes we are managing to deliver or meet the requirements of our customers. These processes shall fall under three separate heads ::;;
(A) Management Processes : These could be Quality Policy, Quality Planning, Management Review, Internal Auditing etc.

(B) Customer Oriented Processes : Under this category those process will fall where customer has something to give and something to get back after some value addition. In this category, processes like Marketing, Order Acceptance, New Product Development, Contract Review, Customer Complaints, Quality etc..

(C) Product Realisation Processes : Here all those processes (Manufacturing Processes will be dealth one by one with a view that an accountability is generated with each of them and these meet the requirements in 100% manner. In fact this segment could be combined with (B) above.

(D) Support Processes : These are the processes which provide all the support to Management, Customer Oriented Processes and Product Realisation Processes. These are HRD, Safety, EMS, Purchase, etc

So in this you list all the processes.

Next draw a matrix of establishing the Process interaction for all the above processes. While doing so, please do take care to mention these vertically top to bottom on the left hand side of the xl sheet and repeat in the same sequence on the top of xl sheet horizontally. Now having done this, establish the interaction. This document will serve as a Ready-Recknor when each process will be dealth separately in the TURTLE Sheet.

Draw TURTLE for each of the processes and fill in the columns. This turtle has boxes for the following :

(a) Supplier input, Supplier, Parameter, Acceptance Criteria
(b) Flow chart for the activities that take place within the process
(c) Customer to the Process
(d) Customer Requirement, Parameter and Acceptance Criteria. Here the next process will be the customer Process.
(e) Control Points, saying How Much
(f) Interacting processes and their acceptance criteria. If there is only one process interacting, this line could be ignored.
(g) Parameter for Continual Improvement
(h) Responsibility : WHO with Competence Criteria
(g) With What : Here mention The machines and other support service equipment that will be used in this process
(g) Feedback : Type of feedback and to whom the feedback to be provided.

I will send a copy of Turtle separately to you. It is self explanatory document.

When handling the Quality Planning clause 5.4.2, please read the standard where it says, Quality plans including those of 4.1. From the turtles we shall pick up those processes only where Acceptance criteria is not being met.

In this way one by one all the processes will be handled and monitored by individual process owners. If all the processes are singing well, you will appreciate that your QMS will singe equally better.

Should you need more information, please feel free to ask. Now cheer up :D

HS Anand
MD
Quality Growth Professionals
Mohali (Pb) - India
anandqgp@rediffmail.com

I will send a copy of Turtle separately to you. It is self explanatory document.


Should you need more information, please feel free to ask. Now cheer up :D

HS Anand
MD
Quality Growth Professionals
Mohali (Pb) - India
anandqgp@rediffmail.com

Hello, Anand!
Would it be possible to send the turtle to me, please?
Thanks in advance!
:thanx:

I joined the cove a few weeks ago and have referred to the site several times as a reference for TS. Everyone within the threads have great advise, examples and are very helpful. My Quality Manual which is only 5 pages, will be sent in for review sometime this week. I am anxious to hear the response form the auditor.

I look forward to joining in on more threads in the future!

Tball

I joined the cove a few weeks ago and have referred to the site several times as a reference for TS. Everyone within the threads have great advise, examples and are very helpful. My Quality Manual which is only 5 pages, will be sent in for review sometime this week. I am anxious to hear the response form the auditor.

I look forward to joining in on more threads in the future!

Tball

Welcome to the Cove:agree1: . I'm sure that folks here will be happy to have a look at your QM, and we'll look forward to your contributions in the forums.

I look forward to joining in on more threads in the future!

We're looking forward to that. Welcome among the posters :bigwave: , and good luck with your manual, system et all...

/Claes

Welcome from me as well.
It would be interesting to compare our reactions to the QM to those of the auditor.

:read: This is an sample process map for Design/Development Activities. It reflects requirements of ISO 9001:2000 & ISO 13485:2003. Hope it's helpful...

Hi - i am new to ISO 9001 and having difficulties organizing what I need to do - there is so much info out there, it's a bit overwhelming. I do not have a background in this and we are a small company of about 7 employees, but find that ISO is a growing condition of doing business with many manufacturers. So far I have found this website to be invaluable.

What I am currently beginning with is analyzing the current procedures we have in place and then transforming them into easy-to-understand flow charts. Do I also need to "write" the procedure in terms of purpose, scope, reference, etc as the precursor to the flowchart? or is the flowchart enough?

Also, my understanding is I do not have to document my entire company's way of doing business, but only areas that affect quality - we are supply chain solution providers for manufacturers;in the process of that, we resell semiconductors to them - so my quality focus is on supplier verification, purchasing, inspecting, inventory holds, ESD, shipping, invoicing, etc. I am assuming I do not need to layout processes and procedures for landing accounts or contract signing, etc.

Please help!