Can YOU help? --> Unanswered questions <-- (Other than Marcelo's Informational posts)

Documentation Reduction - Over Documented ISO 9001:2000 QMS

P

potdar

#21
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.
 

Sidney Vianna

Post Responsibly
Staff member
Admin
#22
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.
 

RoxaneB

Super Moderator
Super Moderator
#23
- 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.

potdar said:
- 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.


potdar said:
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.

potdar said:
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.
 
Last edited:
P

potdar

#24
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?'
 

Top Bottom