Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo Especially for content not in the forum
Such as files in the Cove "Members" Directory
Social Distancing - It's not just YOUR life - It's ALL of OUR lives!
Me <——————— 6 Feet ———————-> You

Is Level 2 Documentation required or necessary?

K

Karen

#1
Level 2 Documentation

If the Quality Manual adequately defines an element of the standard, is a Level 2 document requried/necessary? Element 4.15 is very generic in our process and I feel that a Level 2 document would only be a restatement of what is in the Quality Manual.

I wanted to add, that I really enjoy this forum. I am an avid viewer and have learned so much. Thanks to all of you who contribute!
 

Marc

Captain Nice
Staff member
Admin
#2
Technically, if you can 'say what you need to say' in your quality manual, there is no requirement for a level 2. I have some clients which are small companies which have done just that in several cases.
 

barb butrym

Quite Involved in Discussions
#3
Yup I agree with marc..... there are no requirements for "level 2" anywhere in the standard.... A pet peeve of mine, writing words that don't add value to the system...Say it clear, say it once, communicate it well.
 

Kevin Mader

One of THE Original Covers!
Staff member
Admin
#4
As I understand it, it is the difference between a Structured documentation system (using the documentation levels, pyramid) and an Unstructured documentation system (basically, levels are combined in a single document). Which works best for your organization? Use that. There isn't a specific ISO requirement driving one over the other.
 

Kevin Mader

One of THE Original Covers!
Staff member
Admin
#5
Marc,

Good point. I guess when I presented the types I should have included choice three, a combination.

Regards,

Kevin
 

Marc

Captain Nice
Staff member
Admin
#6
I threw that in there because I have had I don't know how many people come to me with a dazed look asking how to tell the difference and what if there are some details in a level 2 that may belong in a level 3 and such. I try to tell folks there are very few 'pure' documents. In most level 2's you can find some details which might be better classified as level 3 content and vice versa. Structured documentation is nice, but its not a Black&White issue.
 
D

Don Winton

#7
Good coverage all around. Nothing to add except to say that the clauses of ISO 900x that do not require procedures are normally best covered in the level 1 document, at least in my limited experience.

Regards,
<A HREF="http://www.ficom.net/members/donwinton/home.html">Don</A>
 

Marc

Captain Nice
Staff member
Admin
#8
Kevin: Most of my clients use a combination to some degree. I don't know 1 client which has a 'pure' document structure throughout.
 
A

Andy Bassett

#9
Im trying to think how to throw in my twopennorth here without becoming a thread killer. I have battled long and hard with this post, and if there has been a wrong way to do it, I HAVE DONE IT.
Here goes; (I hope none of my auditors are watching)

I struggle to apply the concept of document levels (1,2 and 3) to the companies that I work with because they all have different requirements. This is what I do;
DO start by defining the processes in the company that are critical for the companies success, even if this has no relation to ISO requirements. Make sure the processes cut across dept boundaries. With this single act you will obtain more benefit than any ISO programme (IMHO of course).
DO use flowcharts for processes.
DO NOT overdo this (I once heard that Mercedes have only 9 main processes).
DO start to define Policy Guidelines, items that are not a true process but are important to aid and assist the main processes ie How you control the documentation, what is your Purchasing Gifts Policy etc.
DO use simple text for guidelines.
DO define the detailed work instructions, if possible by department. You will find that people like the idea of Guidelines and Main Processes, but cannot relate to them because it is not their day-to-day business. So encourage departments to define activities in their own areas, even if its not relevant to ISO ie How to process an invoice. From this you will get self-analysis, improvement and transparency.
DO use simple text for this, in a format that can be easily changed by the department.

By now you probably have a streamlined, transparent and efficient company, that your auditor will not understand and will do his best to kill. You now have two options.
A. Produce a detailed handbook/blurb/speel that shows the auditor how you satisfy the standard. Do not let anybody else in the company see this.
B. Produce an equivalence table that points the auditor in the direction of the relevant process/guideline/work instruction. Be prepared for hassle here because the auditor will have problems to find what he want

To be honest, the truth is that with a little experience you are able to implement a system that is practical, useful, and realistic for the company, AND satisfy the auditor. The gap between the two get narrower. However I still tend to favour the idea of producing a useful system for the company, and a great blurb of a handbook for the auditor, naturally with links between the two. I think maybe this is because I have never worked in any bomb making environments.

PS

Do you want to give ISO a slow death. Set-up your documentation so that only one person (ie you) can change it, and watch it all die before your eyes.
Do you want to kill ISO in your company. If so produce a detailed Handbook laying out exactly how you satisfy ISO in great detail and ram it down everyones throat.
 
Top Bottom