posted 04 January 2001 06:28 PM               

There has been considerable discussion on this point, one example being:
http://https://elsmar.com/ubb/Forum15/HTML/000120.html

My offering in that thread was:
ãIt's intersting that these relate back directly to those areas that typically the "Quality Section" of a company is responsible for. This kind of suggests that it is the bare bones approach, and that if you do anything that adds value, beyond the QA stuff mentioned, then you'd better be able to back them up with something as well.ä

This bare-bones SIX approach is crap, you could roll them all into one procedure if you wanted to, but you wouldnât, because it doesnât make for concise, compartmentalized reading, comprehension and adherence/compliance (or even auditing).

Martin, please tell us what your IQA tutor said about what should be in a quality manual - I canât wait to hear that one! No wonder consultants have such a bad rep when they sprout garbage.

As you can tell this is an emotive subject for me. Why? Because quality systems (and quality managers) have been losing their credibility thanks to inexperienced low IQ consultants who flog generic management systems to unsuspecting companies and the companies are in turn registered/certified by corrupt registrars.

My new employer is ISO9001:1994 certified, and a great case in point. They have next to no objective evidence, a very thin collection of system procedures (4 of which cover the same topic under different headings) and next to no control over anything. They want to expand the certification to a global one for all their offices (my job). Iâll be busy righting past wrongs ö and with a different third party auditor ö AND IâLL BE USING MORE THAN SIX PROCEDURES.

ISO should come up with a scheme to reinforce the validity of a certificate/registration - oh, that's right, they're the third party auditors, D'oh, click, bang .......

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

posted 09 January 2001 05:54 AM               

I understand from the discussions in this forum that I have to refer/address every clause of the standard(s) in the manual and procedures. I found somme comments that the new standards (will) allow us to have less documents, but as far as I read, I feel the bunch of procedures needed grows and I don't quite know where to stop and how to start.

If you, please, have any sugestions, help me.

posted 09 January 2001 06:09 AM               

Nope - I do not see a change from the 1994 standard. It has always been that the minimum 'required' procedures were not enough for 98% (my guesstimate) of companies. Probably, really, 100%. Now, as before, you have to be ready to explain what you document and why and what you do not document and why. You do thius with consideration to training, etc.

How far you go in documenting has been a question since the standard first came out. It has been discussed in the old forums here as well as these forums in numerous threads - although I don't recall a recent thread. There is no way to do this except to say you end up with an evaluation of what documentation you have and why. What documentation is necessary for each person to do his/her job? Why?

If there is 1 thing I really think is beneficial about implementations, it is the 'opening of the eyes' which has to occur. If there is 1 big problem, it is how many companies over document.

posted 09 January 2001 06:24 AM               

This is why I preach (!) the approach of taking the standard and making it your quality manual. It is here that you address every line item in the spec.

You may 'address' a line item by saying you don't do it. If there is a reason (there should be) you briefly state why. This mostly applies (not doing something) to the 'concept' introduced - exclusions (as opposed to the old ISO 9001 vs ISO 9002 vs ISO 9003).

Where you do do something, you cite your reference in the quality systems manual or matrix.

So - when I say you have to address every line item of the standard, I mean you either say you do it (and cite reference[s] to your documentation) or say you don't do it and why.

There's more common sense here than meets the eye.

You say you're maritime - so you're probably want to integrate requirements. See Elsmar.com/obsolete/requirements.html for a simple requirements integration matrix. For an expanded version, as well as the integration of your company documentation, see QS-Req.pdf in the pdf_files directory.

posted 09 January 2001 06:42 AM               

And still i am kind of locked with the procedures. I decided we shall have a "quality and safety policy manual" and a "quality and safety procedures manual". For the first one I'll use this approach ... of using the standard (its structure, with a touch of personalised input) (thanks again for re-confirming the idea that this approach can be used) and our management policies and also I'll state the exclusions and reasons for them. And in the second one, I'll use the procedures we allready have, trying to re-organise them if needed and to re-phrase some of the terms used.

posted 09 January 2001 08:01 AM               

Thank you very much!
I am happy that I discovered this discussion forum. I find it extremely useful and I admire you for reserving the time to maintain it (them) and for your prompt replies. It realyy is an excellent idea and a very useful resource of information, hints and solutions.

posted 09 January 2001 11:23 PM               

If we take 8.2.2 a & b as examples, I personally would not state these in my manual or procedures. It is the object of internal audits to determine the status of compliance. What I'd typically say in the internal quality audit procedure "purpose" is:
"The purpose of this procedure is to describe the requirements for internal quality auditing undertaken within Company X to determine the extent which the management system has been implemented and the degree to which work practices comply with the documented management system"

As far as I can tell I don't need to put all this stuff in the manual.

If I choose to state how we do each requirement in my procedure (and you HAVE TO HAVE a procedure for internal audits, why would I add verbiage to my quality manual by going over the same ground twice?

Your thoughts?

posted 10 January 2001 07:17 AM               

I don't recommend being redundant - I do believe it's easier for many folks to use the q manual as the base where one can ensure each line item is addressed. Most of the good folks I work with are not as versed in procedure writing and manual writing as I am. I try to make things as simple as possible. In addition, many times procedures are revised well after the audit and someone throws out that 'stupid' phrase not knowing or remembering that it was put in there to satisfy the auditor. Since revision of the q manual is more typically done by the q manager or q rep, it is less likely (my opinion) that it will be revised in a way where 'some stupid statement' is revised out.

If you want to take it to the extreme, there is no need for a q manual to consist of anything more than a scope statement and a cross-reference matrix. Ultimately I see this as most sensible as q manuals are typically little more than sales devices. But I don't see this as a good idea for most clients as the requirements are confusing enough. And I want them exposed to the standard as much as possible so they learn it and understand it.

posted 11 January 2001 07:27 AM               

In addition that really should have been picked up at initial doc review and sited as part of all that nit picky stuff typically so the client can justify that it is/is not needed....by audit time ...ie make sure they are legible so that auditor dosen't find it !!!! or if not, then add it somewhere. See it most during 'new hire training' or OJT where the record originates..... but that is from my Military clients...certainly can be overkill for some small companies...i say base it on the end user of the product...if legal or liability issues can occur it may be beneficial to add it...not that it will change anything (cause it won't !!!) but it "smoozes" pretty good. A pretty good rule of thumb I suppose (consultant/company view)