Hello All,
Does anyone know of a book or article I can use as a reference for the reduction of documentation of an ISO 9001:2000 QMS? My employers QMS is heavily overdocumented, and I'm looking for ways to reduce the amount of documentation without compromising compliance.
Thanks.

Hello All,
Does anyone know of a book or article I can use as a reference for the reduction of documentation of an ISO 9001:2000 QMS? My employers QMS is heavily overdocumented, and I'm looking for ways to reduce the amount of documentation without compromising compliance.
Thanks.

There is no book that would give you the answers (that I am aware of). ISO9001:2000 requires only six (6) procedures minimum but don't only rely on the 6. Review your processes to determine which are critical and document them as well.

Check out ISO 9001:2000 A Practical Quality Manual Explained by Kevin Grimes.

It gives a pretty minimalist approach to the manual/procdures.
I don't necessarily agree with doing it his way in my current company, but if it works for others that's great.
I use it as a reference for developing core procedures.

There may also be some articles in quality mags such as Quality Progress (ASQ) on going to a paperless system, streamlining the document control process, etc.

Coury's correct :yes: - a thorough review of your processes may yield opportunities for reducing the current documentation volume.

Good luck!

You are wading across the stream to fetch water, my friends. :cool: We have been discussing this in nauseating detail here in the Cove, so look no further (Oh, of course you should look further, but there is a lot of info right here).Does anyone know of a book or article I can use as a reference for the reduction of documentation of an ISO 9001:2000 QMS?.

My employers QMS is heavily overdocumented, and I'm looking for ways to reduce the amount of documentation without compromising compliance.Good call. Been there, done that and still doing it. The following links should be useful in that quest:

QMS (Quality Management System) Manual - The Boss Wants a 4 Page Manual - What to Do? (http://elsmar.com/Forums/showthread.php?t=4866)
Keeping Procedures Simple (http://elsmar.com/Forums/showthread.php?t=6599)
Am I doing to much documentation? (http://elsmar.com/Forums/showthread.php?t=6083)
ISO 9001: Avoiding Over Documentation (http://elsmar.com/Forums/showthread.php?t=8020)
Simple Quality Systems Manual - Do we really need bloated Quality Manuals (http://elsmar.com/Forums/showthread.php?t=17005)
Amount of Documentation dependent on staff competency (http://elsmar.com/Forums/showthread.php?t=11642)
Size of QMS / Size of company - What advantages do small, simple organizations have? (http://elsmar.com/Forums/showthread.php?t=8311)
Help needed - We have one of these so called "canned systems" (http://elsmar.com/Forums/showthread.php?t=9559)

/Claes

I can really relate and if your company is like the one I am in now you have a lot of documentation, but many of the most critcal documents have not even been started or if they are they are inadequatly defined. At least I know I have a job. Just aquestion to further this discussion. When it comes to putting together a QMS can we treat it as a product and use lean techniques? I do not know if this has been discussed before i have not had time to look at everything.
Read the threads Claes posted many of them are very good discussions. Thanks Claes.

Mark

Mark, you're question is probably a thread unto itself, but let me ask you this...why wouldn't you implement a management system (be it quality, environment, safety, financial or integrated) using the principles of lean? Does it not make sound business sense to implement a system that is effective and efficient (i.e., minimizes waste)?

The best part is that if developed properly, a management system can be implemented with the principles of lean without actually using the term "lean". If tools and methodologies are introduced properly, then they should be used as a lean environment intends.

If not, however, we find ourselves introducing the concept of lean within our organization and everyone panicks as they think "job cuts" and "reduced hours".

Just aquestion to further this discussion. When it comes to putting together a QMS can we treat it as a product and use lean techniques? I do not know if this has been discussed before iI know that we have, at some point, but I think it's been in connection with the subject of this thread, not as a specific subject.

Anyway, I want to suggest yet another at least slightly related thread: Seeking Tips: Office Improvement - Best Practices (http://elsmar.com/Forums/showthread.php?t=6428)

/Claes

We had over 1,500 regulated documents (written within the company) encompassing Safety, Env, Qa , Hr etc etc. I went on a one man mission to reduce the paperwork. 1st step was to have every document reviewed with the following action in mind:

Do we need the document or is it a skill that is learnt
Does their competencies (see above) cover this
Is it written down just for the sake of writing it
Does it have too much information (or not enough)
Is it duplicated in a procedure or form
can it be replaced by a flowchart, form or checklist

After all of this was done, we then started by removing all of those documents that were no longer required. We revamped the document layout and removed all manner of information that was purely there for the sake of the old ISO. Normative references, Scopes etc...We concentrated just on the processes.

We reduced all of our documentation to a more manageable level. Some documents went from 16 pages to 3 or 4. We then placed everything on an electronic document system and this also save dall the hassle of hardcopies. It was the most efficient thing we have done in the QA system.

We just applied the KISS principle and everyone followed.

We reduced all of our documentation to a more manageable level. Some documents went from 16 pages to 3 or 4.We made similar reductions in text mass. The bureaucratese quota decreased dramatically, and suddenly people started finding what they were actually looking for.

We just applied the KISS principle and everyone followed.Exactly :agree1:

/Claes

I completely agree with Coury Ferguson and Greg B.

Apart from 6 mandatory procedures as stated in the standard, one must review the processes to determine the need and the critical ones should be documented, specially for those that have been delegated downline.

Remember documentation also brings in consistency and are a medium of instruction and information transfer.

Remember documentation also brings in consistency and are a medium of instruction and information transfer.

Documentation might facilitate consistency, but it doesn't create it, or "bring it in." Conscientious process design, training and discipline are the primary components of consistency. (And I'm not referring to this kind of discipline: :whip: )

My site is doing things rather backwards...but let's just blame "corporate" shall we? ;)

We are required to assess all key tasks/processes and ensure that they are standardized (including documented).

Fortunately, or unfortunately, we've been registered to ISO 9001 since mid-1998 so we've had documentation in existence for some time. We listed all processes, sub-processes and tasks. And then ranked them against our "6 Dimensions of Quality" as well as importance and performance in the ability to meet the requirements of the stakeholder(s).

Anything that scored above a designated trigger point was deemed "key" (we will not use the word 'critical') and thus documentation was required. We already have the documentation in place.

Additionally...but somewhat off topic...

The matrix is reviewed and updated on an annual basis - rather a 'makes work' project, but I undersand what the objective is so I won't complain too loudly. ;) Assessing the standard to those who perform the process/task is done on a scheduled basis and the standard may be updated as a result of that assessment...this is a wonderful communication method between the supervisor and the operator...and reduces the amount of "document review" done during an internal audit.

Thanks Jim,

I stand corrected. The wording of the sentence should've been "Documentation helps in maintaining (or bringing in) consistency..." This would apply particularly in a company where similar operations are spread through different units (also maybe geographically distant) or involve different people in the same process where these documents maybe used for training / retraining and reference material.

Regards

Additionally...but somewhat off topic...
The matrix is reviewed and updated on an annual basis - rather a 'makes work' project, but I undersand what the objective is so I won't complain too loudly. ;) Assessing the standard to those who perform the process/task is done on a scheduled basis and the standard may be updated as a result of that assessment...this is a wonderful communication method between the supervisor and the operator...and reduces the amount of "document review" done during an internal audit.
I totally agree that the "review" should be taken out of the AUDIT!! In the early days I seemed to be doing more reviewing than auditing. I think I could run the plant due to the fact that i have read and reviewed every doucment and procedure:D

Thanks Jim,

I stand corrected. The wording of the sentence should've been "Documentation helps in maintaining (or bringing in) consistency..." This would apply particularly in a company where similar operations are spread through different units (also maybe geographically distant) or involve different people in the same process where these documents maybe used for training / retraining and reference material.

Regards

Absolutely:agree1:

There several threads that go over this issue. KISS, I used a simple system that has passed audits. Over documentation is essentially a waste. Train, train, train.... We had some instances where things were not being done properly causing some extra work, so it was decided that we needed a WI on this and as you would guess it did not help.

There several threads that go over this issue. KISS, I used a simple system that has passed audits. Over documentation is essentially a waste. Train, train, train.... We had some instances where things were not being done properly causing some extra work, so it was decided that we needed a WI on this and as you would guess it did not help.

Okay, please keep in mind as you read my response to this...I fully recognize that every organization is difficult and what works for one company will not always work for another....

First off, deciding that it was the lack of a WI was a root cause analysis that didn't dig deep enough. But please don't blame the WI for not solving the problem. ;)

Secondly, training is all well and good - I'm a firm believer in the benefits of On-The-Job training - however, what happens when people start to retire? How do you help to continue a consistently performed process?

Somewhere on the Cove is the story about the monkeys in a cage with a bunch of bananas hanging down. As people leave, there should be some form of media for retaining the technical knowledge of the process. A documented process helps in this area.

A documented process is also great for companies who have activities such as standards/process auditing and job/task observations (i.e., safety focus). It provides a clear checklist to the auditor to ensure that all is performed as documented or, even better, the operator has a clear way of showing how a document should be modified to match the current process.

I'm not saying document everything. Far from it. But those processes which are key to your system and the organization's ability to consistent (and continually) meet Stakeholders' requirements, a documented process will greatly assist in the ability to retain knowledge about the process.

If you are really serious about reducing the size of your documentation, firstly ensure two aspects -

Your management supports you fully in the task.

You have sufficient time on hand. (Define sufficient)

If both stand true, start defining your system on a process model from scratch. Involve the system users in the task. You may use portions of the existing system that you find useful.

When you are ready, SCRAP the existing the system and intoduce the new system. Modification is a waste.

Your management supports you fully in the task.

This is true for any project.

You have sufficient time on hand. (Define sufficient)

To determine this, one needs to plan ahead.

start defining your system on a process model from scratch. Involve the system users in the task.[/B] You may use portions of the existing system that you find useful.

When you are ready, SCRAP the existing the system and intoduce the new system. Modification is a waste.

Pardon me? Modification is hardly a waste! Even your paragraph before this states "...existing system...useful." Not to mention, how much support will be given from the users if they happen to like the system (or portions of it)? People don't like change...implementing something brand new can be very scary for the users. Toss in the resource requirements to implement something brand new...money, people, training, supplies.

Be very careful if this option is taken.

Scrapping a system is hardly effective option. I admit, for some situations, it may be necessary, but hardly for a case of over-documentation.

Scrapping a system is hardly effective option. I admit, for some situations, it may be necessary, but hardly for a case of over-documentation.

Let me make an educated guess why UV's QMS is overdocumented.

- It carries a lot of now unnecessary documentation from the older 1994 version QMS. OR

- It was defined in the early days of 2000 version when people were still under the impression that ISO means "say everything that you do and do everything that you say".

Roxanne I believe you are writing this using a laptop, or even better. Not using a 5150 and giving commands to it on DOS any more. None of your machines on the shopfloor work with a punched tape... Why did you scrap them? And how did you and your staff adapt?

Introduce a cellphone. People will hesitate. And then they will take in big way to it. Come to India or China and take a look.

Simplify your QMS, same thing will happen.

Roxanne I believe you are writing this using a laptop, or even better. Not using a 5150 and giving commands to it on DOS any more. None of your machines on the shopfloor work with a punched tape... Why did you scrap them? And how did you and your staff adapt?I don't think the analogy is valid here. Roxane is correct. In VERY few instances a revolutionary approach to revamp the QMS will be successful. Much wiser to follow an evolutionary path. The pace of evolution/change dependent on the organizational culture and available resources.

- It carries a lot of now unnecessary documentation from the older 1994 version QMS.

Define "unnecessary". I guess it comes down to this...does the Original Poster's organization want a piece of paper on the wall or do they want a system that works for them?

There are the 6 required documents (plus the little statement alluding to "anything else where the absence could adversely impact the ability to meet customer requriements").

People come and go. How does your organization effectively retain technical knowledge? Training - on its own - will not last...it's like the game we played as children. Where one person whispers to another that "I have pink Mercedes in New York." By the time it is whispered to the last person down the line it has become "You have blue wagon in Singapore."

Documenting a system - on its own - will not last...especially if people do not recognize that a documented process must be dynamic, being modified as the processes change, as technology improves.

- It was defined in the early days of 2000 version when people were still under the impression that ISO means "say everything that you do and do everything that you say".

Has this changed? Doesn't ISO 9001 still, in simplistic terms, mean that? And I say simplistic to keep it user-friendly for the people doing the jobs making the product for our customers. Yes, those of us in management systems can probably give much more complex definitions as to what ISO 9001 means...but lets keep in mind who the real Stakeholders of a management system are. Customers who use our product and Employees who have a standardardized process to follow which consistently makes product that meets requirements.


Roxanne I believe you are writing this using a laptop, or even better. Not using a 5150 and giving commands to it on DOS any more. None of your machines on the shopfloor work with a punched tape... Why did you scrap them? And how did you and your staff adapt?

Introduce a cellphone. People will hesitate. And then they will take in big way to it. Come to India or China and take a look.

But the overall process of communication is still there. The technology evolved...but we did not scrap the ideal of communication.

Simplify your QMS, same thing will happen.

Simplifying a system is comletely different than scrapping it.

To scrap a management system is to send the message of "We are going to things 100% differently now." That will scare many people and your system will be back at the beginnign stages.

Instead, look at your existing system...look for what works...and what doesn't work. Improve what does work. Stablilize what doesn't - this could entail revising some processes. But the core concepts remain there...you are not scrapping the system.

Maybe we're just arguing semantics here...but I've learned that how you word things when revising an existing system can spark some pretty emotional debates.

Maybe we're just arguing semantics here...but I've learned that how you word things when revising an existing system can spark some pretty emotional debates.


I agree. Its only semantics. I am suggesting that we rewrite the documentation. Not change the system. You are suggesting that we make slow updations in the existing documentation, rather than making a revolutionary change. You also dont propose changing the system.

We all rewrote when changing over from 1994 to 2000 and QS to TS. Its nothing new. And I think that was revolutionary. Successful? Let everybody be his own judge.

The system needs to continually change, but thats a separate discussion. Only, a simpler documentation is easier to update when such changes do take place. Thats the only clinching argument in its favour. If anyone prefers to keep thing in detail, its always their choice.

The discussion had started with our friend wanting to reduce the volume of his documents and asking 'HOW?' rather than 'Whether he should?'