Using the 8 QM Principles in the QMS

[Greg B]

More often than not, I am in agreement with you, Wes. Not this time. I view the Quality (Policy) Manual much the same as I do my home's insurance policy. When it is first drawn up we go over it with a fine toothed comb to make sure it reflects everything needed (or with the QPM, ensures that all management expectations are addressed - including if applicable, the ISO requirements). After that, it is pretty much a static document that is there for reference only, like when you submit a claim (or with the QPM, when major system changes are made that may affect policies).

I would expect work instructions, and some procedures to be well used, but not the quality manual (unless, of course, the quality manual is combined with procedures).

IMHBOIO (boi = but often irrelevant)

Rob,

I think you have nailed it exactly. I could not have hoped to answer it any better. Well Done. I hate Quality Manuals. I sometimes feel they are just an easy way for a registrar to get out of walking around the plant during an audit.

Greg B

 

[Gary L. Phillips - 2007]

I feel that for most organizations, there is a feeling that the QM and most if not all level II documents are static systems that do not need to be read more than once. This is one of the problems as I see it. Auditors have always discovered the most findings in issues related to document and data control, now titled control of documents. This is accross the board: all registrar assessors, both in the initial audit and during the continual assessments, and also during the internal audits. Folks just fail to revise their documents to reflect the actual process that the document is designed to help control. The writers of the 9K:2K standard, IMHO, wanted to ensure that the organization keeps their documents (including the QM) updated on a regularily scheduled basis, so the requirement under 4.2.3 b) "to review and update as necessary and re-approve documents,".

Auditors just get tired of preparing to audit an organization only to arrive on site finding a lot of their documents are way behind the curve and do not agree with their current operations. UUUGGGHHHH ! ! The QM should be written such it can be robust as needed, yet has to be reviewed, per 4.2.3 b), to make sure that it is effectively defining and describes an organization's operations. This is hard to do when it is 97% a copy of the standard, itself.

Although this isn't about the Baldrige Criteria, one comment is justified. In the Baldrige Criteria, an organization can not just parriot their responses, the criteria asks HOW and WHAT questions and the organization must give explainations to those questions. Hopefully, we will do this for the next system we develop. :thedeal:

 

[Gary L. Phillips - 2007]

Thanks, everyone for your comments and votes on my first poll. I think back to the early 70's (and probably beyond) looking for differences in the structure of organizational management and one thing is readily apparent to me. In those days (for those of us who are a little older) many operating systems (manuals, SOPs, etc.) were very roughly developed, poorly deployed and lacked sufficient upper management committment. A good number of organizations just didn't cut the mustard and were ultimately left behind. This probably could have happened for a number of reasons, not just a documented system, or lack therof. However, there were some organizations in various industries that had very well developed and deployed systems that allowed for quite a robust operation in which to conduct their business, touching on things like: strategic planning, calibration, customer satisfaction, inspection plans, defect reduction, and employee development. Many of these organization have not only stayed in business, but have seen growth even during times that were somewhat discouraging, to say the least, to others within the same industry sector.

We all know the purpose of a well defined system. It is NOT because the standard requires it, but WE NEED one. Well defined systems allow for knowledge retention and sharing (training vehicle) guideance for new management personnel, and declaring the organizational intent for the enterprize. Defining our operations, processes, structure, plans and planning concepts, measurements and analysis of needed data, and a well developed system that ties everything together through a self determination (internal audit) followed by senior management taking a careful review of the entire business operation promotes the process of improvement throughout the organization.

These are some of the tools for organizational success. What organization chooses to purchase a major piece of equipment and then just let it sit in the box for years, collecting dust. Not many that I know of... Yet many organizations spend a lot of hard earned $$ developing a management system that basically just "sits in the box" except twice a year when their registrar comes around. What a waste of resourses, in both personnel and dollars (or pounds, for our friends across the ocean). Its no wonder that a lot of companies feel they have not recieved a good ROI for all their registration efforts. Many quality professionals who are tasked with developing and deploying (sorry Baldrige creeping in again) systems that are only used as a trophy feel disheartned, maybe even abused.

The problem, IMmostHO should be laid at the door (or in the chair) of the executive management, due to lack of committment. We still seem to be in the Nike age -- Swoosh ! JUST DO IT !!! I've still got difficulties with management understanding that we do not have an ISO system, we have a business system with all that that entails. We do not conduct business just twice a year, but everyday, 24-7. Sometimes I wonder how many others have had a senior executive reply to make sure it (ISO?) happens, keep it going, or (in a panic) look at our system because ISO (?) will be here next week and we haven't done anything for a year ! Where oh where has my management committment gone ?

Management still doesn't seem to get it, for a lot of organizations. It isn't a surprise to me that so many registrations have been left in the dust this past year. I only hope those who have decided to remain registered are doing so out of a desire to be in the elite group of their respective industry and fully embrace the intent of the new standard and use it as a tool for improvement to their business management system. :thedeal:

 

[Rob Nix]

Very well put, Gary! I too have been doing this since the 70's and truly, the difference between a QMS (more precisely, BMS) that is window-dressing and one that is dynamic and functioning effectively is whether those highest up are also its biggest proponents.

 

[Peter Fraser]

I feel that for most organizations, there is a feeling that the QM and most if not all level II documents are static systems that do not need to be read more than once. This is one of the problems as I see it

So why don't we encourage folk to get away from the idea of a "QM and level II documents etc", and "just" describe how they run the business? No one has ever explained to me why the standard requires you to have a QM. I have no problem with the things which it should include (but lots of problems with the way folk address them!), but I see no need for the (implied) requirement to create a separate "manual".

Rather than start with the standard and develop a system around it, surely it's better to:-
i) define your processes - ie how you meet the objectives of the business. This will include processes to manage the resources needed for your processes to work.
ii) define the documents and other sources of information you need to implement and control the processes.
iii) then have a look at the standard and make sure that you haven't missed anything.

We find that most assessors are happy with this approach, especially when they see that staff actually use it - which makes it more likely to be improved.

Be radical!

 

[Cari Spears]

...Rather than start with the standard and develop a system around it, surely it's better to:-
i) define your processes - ie how you meet the objectives of the business. This will include processes to manage the resources needed for your processes to work.
ii) define the documents and other sources of information you need to implement and control the processes.
iii) then have a look at the standard and make sure that you haven't missed anything...

I took this advice a while back (thanks again Claes) and removed the ISO'94 blinders. I did find it a much better approach. Everything kinda fell into place.