Quality Procedure Review

[dominick]

I have put together a team to review our quality system procedures. I believe a great deal of our procedures were written to satisfy an auditor but seem to be lacking in real instruction. What criteria can I present to reviewers who may not be experts in the standard so that they can determine if procedures/instructions do indeed add value or simply add bulk to our manual? This site has been a valuable resource for me (especially in recent months) and I appreciate the help.

Dom-

 

[Marc]

If you are 'reviewing' level 1 and 2 and you are wanting to consider compliance to a standard, I would suggest that you ensure someone who fully understands the spec (ISO9, QS9 or whatever) works in consenance with the team.

I would ensure the review is by people who use the procedure regularly and a process/product engineer (particularly level 3's, but level 2's as well. If they don't, it's hard to say what is needed and what is not.

I can't think of any specific criteria off hand - in part because every company is different in so far as what they believe is relevant and necessary. As an example: If company A and company B both assemble a product and the product is identical, but one company is in Bath, KY while the other is in San Jose, CA the difference in the education of the local labour pool may well determine much different documentation in each place.

I'll let the others take it from here...

 

[barb butrym]

you need to Keep it simple...the easier and user friendly the procedure, the more chance it will be used....you need to review them as if you would need to use them.....You need to put yourself in the head of the user, can you, at that level follow the requirements..Don't overstate the stuff (give the user credit), don't kill yourself with details that are common knowledge for the user (flow charts are the best).....maybe a short class for the team on auditing (as the procedures will be audited, so they look at them as an auditor would?)or even a session on writing a procedure....keep the team small, minimal...and knowledgeable of the function. As for the higher level documents, have an ISO literate person (1) do a last look when ALL comments have been implemented.

Its such a company specific, and as marc says..region specific thing that its really hard to give you a guide...ya gotta do what fits......But experience tells me a team review is a lousy approach, all you need is 1 to drag his heels or nit pick and you are hung up....forever.

Don't create procedures that are not needed.. A machinist doesn't need a procedure tell him how to machine part..he merely needs instructions for company specific details, and ties to other system elements...records etc.

[This message has been edited by barb butrym (edited 13 January 2000).]

 

[Laura M]

Have the team ask of each procedure:
- Is this what we do? (check internal audits if necessary)
-Why do we do it? (If it's to satisfy the standard, then more education is required)
- Is there a better/more efficient way?
- Does the procedure use ISO/QS words, or company lingo...use company words if possible.
I'm assuming these are Level 2. Level 3 as Marc states need to be geared to the level of training/education and how complicated the process is.
I would assign procedures to individuals to review/rewrite and bring back to the group.
I'm also partial to flowcharts.

 

[David Mullins]

Is the task of the team to review the procedures for adequacy against the standard or appropriateness for your organisation.
As Barb said, team reviews can be a disaster where they end up correcting formatting errors instead of reading the words.
My suggestions will give you tools to not only jump this hurdle, but many others.
1. Sit down with ISO 9001/2 and type out each requirement in bullet form (this can also be used for system/adequacy audits of high level documents). This will appear much like the implementation tables I gave you off-line. These are also readily available commercially for GAP ANALYSIS. The benefit of doing it yourself is you learn what is in the standard.
2. Assess each line item/bullet point for how it can be translated in your organisation, so you end up re-writing the requirements of the standard as requirements of my organisation. This exercise can be done by a team. These line items/bullet points can actually be used to write your quality manual, as you have translated the requirements of the standard into the requirements of your organisation's quality management system. I have sent you a very abridged version of this called the "state of compliance checklist".
3. Do the quality system level procedures address the bullet points you came up with? If so then the procedures comply with the standard and are meaningful to your organisation. Assess which bullets need to be stated (how and who) in the system level procedures.
4. Make sure the language you have used is easy enough for users to understand - you're not writing technical documents here.
5. Look at your organisational chart and break them down into levels and job roles.
6. Identify which system procedures apply to the various people within you organisation - this is useful for training purposes so that people readily understand which procedures apply to them.
7. Train your people in how the procedures apply to them.
8. Now get departments to write their lower level procedures/instructions. Note - these should not go over ground already covered in system procedures which provide sufficient instruction, as you risk conflict. Remember, the reviewer/approver needs to ensure that lower level documents are not in conflict with the system level procedures.
9. You've now created most of the QMs, you just have to implement it all.
10. Spoil yourself to a bottle of premium Australian red wine and some cheese and crackers - you deserve it. (Californian substitutes will not suffice).
Cheers.


------------------

 

[Andy Bassett]

This is a subject that nearly always makes me rant, so ill try and keep it simple. When creating Manuals or handbooks the dilemma is always do you write something to suit the Auditors or do you do something understandabe for the staff. I have tried all options and i do not beleive you can do a handbook that suits both parties.

My current method is to do a splurge solely for the auditors defining in flowery style how you satisfy the ISO Standard (and DONT force this on any of your staff), and another set of documents showing how the processes work within your company(and DO train your staff on the content.

Get your people to review the company procedures. I have found that it needs considerable skill to define a process becuase it is difficult to know where to start and what should be included.

To help i ask the participants to agree on the start, agree on the finish, and list the main points that should be in the process.

Here is an example i used for a Motorsport company to define the Car Build Process.

Process Start - Workshop getting the instruction to build a vehicle.
Process Finish - Car leaving the workshop.
Main Points to include
Who issues the instruction and in what format
Who checks the feasability
How is the work distributed in the Workshop
How are the sub assemblies organised
What documentation is needed from engineering
How is the vehicle checked and approved for release.

As you can imagine, if these points were defined you would have a half decent Process.

Lastly if you felt you are going up a 'detailed blind alley' classify this as a Work Instruction and show on the Process diagram the link ie 'see Work Instrcution ' Part Number Creation'

Regards


------------------
Andy B