Section 4. Quality Management System






Section 4. Quality Management System

The heart of the ISO 9001:2000 Standard begins with Section 4. From Section 4 through Section 8, the Quality Management System is described in detail.

In the view of the ISO, what is a quality management system? It's a series of components, logically linked, that when taken together give an organization the controls and measures it needs to manage and improve how it produces product. As you'll see with the descriptions of CMMI and Six Sigma, the Quality Management System (QMS) of ISO is a self-contained process improvement program.

Section 4 is divided into two parts and is used to establish the structural criteria for the QMS.

4.1. General

This section, as its label suggests, provides a series of general requirements that your QMS should possess. You'll see in later sections that this structure holds up throughout. All the sections are based on these criteria. Basically your QMS should support six elements:

  1. Your QMS should identify the processes that your program will use. This is an explicit requirement. Often, organizations will rely on implied processes. They may see no need to define how they conduct daily business; they might think they know it so well that habit is enough, that they need no such reference. But with ISOand this is true of most all process programsthe way of doing business needs to be documented. It needs to be externalized. If process is only implied, the organization has no choice but to leave it up to the individual to honor it; it's internalized. And if it's internalized, it becomes close to impossible to manage, measure, or improve. So the first recommendation in the standard is to explicitly identify your processes. Write them down, document them, describe them.

  2. Your QMS should describe the sequence and interaction of the processes. This is an important characteristic of any process program. In the most concrete of processessay, the gearing of a grandfather clockthe reason becomes clear. The gears, levers, and springs are arranged in a precise order. When one part is set into motion, the other parts move in harmony. And the clock keeps accurate time. The same is true with a systems or software process program. The elements are interrelated. They have the potential to affect one another. Some should occur before others, others after. So in addition to defining the individual processes, it's helpful to understandand to documenttheir logical sequences and interactions.

  3. The Standard requires that you ensure adequate resources are available to manage the system. It may seem surprising, but this is an often overlooked factor. Many times people work hard to define and create a quality management system and then forget that it takes people to run it. However well you define your program, you should realize that it will take resourcesperhaps full-time, perhaps part-timeto execute it. And these resources will need the appropriate level of support and infrastructure to successfully carry out their duties.

These first three requirements describe how to structure your program. The next three describe what to put into place so that you may gradually grow and improve your program.

  1. You must provide mechanisms to monitor and measure the performance of the processes. This is integral to all process improvement efforts. It shows up in CMMI, and it shows up in Six Sigma. In order to get better at what you do, you need to know your starting point. No beginning Quality Management System is going to perfectly solve every issue thrown its way. Processes, like people and organizations, need to mature over time. If you monitor and measure the performance of your processes, then over time, you'll begin to gather enough data to show you how well they are working. More important, they will show you where things are not working so well, and this will help you pinpoint areas for improvement.

    This may be the single most neglected aspect of process improvement. It's nice to think that once the design work is done and a process program is in place, you can just leave it alone to do its thing. But like any tool used in the organization, your QMS should be regularly monitored to ensure that it's doing its job even as the organization itself matures and evolves.

  2. The Standard requires that your QMS contain criteria used to judge how effective the process interactions are. This is really an extension of point 4. The idea is to monitor and measure not just the individual processes you have designed, but to define criteria that you can use to weigh whether or not the interactions between the processes are working. You may have a series of successful processes in placea collection of finely minted gearsbut if they don't fit together well (if the interfaces have gaps), the program as a whole may not live up to its promise. So you should define the criteria to measure the interactions. The criteria you select are up to you, and naturally depend on the types of processes you implement and the type of work your organization is engaged in.

  3. You should examine the results of points 4 and 5measuring your processes and their interactionsand then improve the Quality Management System based on these analyses. Improvement is one of the chief goals of any QMS. The idea is that you should see better quality as your QMS gets better. But changes to your QMS should be regulated. They should not be willy-nilly. You don't want the system to exist in a constant state of flux; people wouldn't be able to get used to it. You also don't want it frozen in time; it wouldn't be able to move with your organization. A better approach is to make changes to the QMS at regular intervals and based on tangible facts: the results of your measures. Gut instinct and intuition are valuable commodities, but these are best balanced by hard data when tinkering with what is basically the holding tank for your business systems.

These six elements describe the requirements for a sound Quality Management System (illustrated in Figure). Looking further now, a QMS is naturally composed of many parts. There are policies, procedures, processes, forms, artifacts, and so on. For the system to be effective, manageable, and measurable, it needs to be documented.

The Quality Management System should possess six general characteristics: processes are defined, processes are sequenced, adequate resources are appointed to manage the processes, process performance is monitored, process interactions are monitored, and processes are continuously improved.


The next part of Section 4 describes the documentation requirements for the QMS.

4.2. Documentation Requirements

ISO 9001 takes documentation seriously. (You'll find that CMMI and Six Sigma take it seriously, too.) Section 4.2 describes the physical manner in which Section 4.1 can be realized. It's organized into four parts: a general description of the kinds of documentation you should have, a requirement for the management of your program's Quality Manual, requirements to control your various quality documents, and requirements for controlling the records that emerge from using the quality system. Let's take a brief look at each section.

4.2.1. General

This section provides general requirements for the kinds of documentation needed to support your program. Basically you'll need to create four categories of documents.

The first is a document that defines your organization's quality objectives.[*] This is a critical component of your quality program. It may be the single most critical element.[dagger]

[*] I describe each of these documents as if they are standalone units. You can create them in that way if you'd like, but you can also combine these into consolidated documents. Select whatever approach you think is best and easiest to maintain for your organization.

[dagger] For more information on the importance of quality objectives, see Chapter 3.

Your quality objectives will shape the focus and structure of your full program. The objectives should be carefully thought out. Because they are of strategic importance, they are usually developed by senior management. The objectives represent the quality goals you are aiming for. They can be expected to change over time, but to create the initial program, some of the main ones need to be understood and defined in advance. Naturally these will be defined based on the type of technology business you are in, the current structure of your organization, its market imperatives, and the internal characteristics of your production processes. This document need not be extensive; it need not establish a mission to solve every issue you might be facing. But it does need to be focused on key goals, and it needs to spell your objectives out in concrete terms, terms that can be tangibly targeted and implemented.

The second requirement is to document a Quality Policy. This is a logical extension of the documented quality objectives. In fact, the policy is a document that will normally contain the objectives. It is an executive tool that sets the tone for the organization's quality program. It demonstrates executive commitment to the quality program. Again, this document is typically authored by executive management. A policy might, for example, be created to focus energies on on-time delivery, on schedule management, and on customer communications. These are all good objectives around which one can build a quality program. Once it is in final form, ready for approval, the policy should be signed: this is a sign of visible backing by management. And once signed, you should ensure that it is made readily available to all members of the organization. From time to time, as your program grows or your organization evolves, it is a good idea to revisit the policy to keep it current.

The third requirement is to create your organization's Quality Manual. This is the document everyone usually thinks of as the ISO 9001:2000 program. It contains the full set of processes and procedures and interactions you build to satisfy the ISO requirements described in Section 5, 6, 7 and 8 of the Standard. This may be one manual or it may be a collection. One group may own it, or it may be shared across many groups. However you structure it, it represents the heart of your Quality Management System. Most of the rest of this chapter describes what components should go into this manual.

The fourth requirement is to document the records required by the Standard. In ISO 9001, you are required to keep 21 types of records. These records become the artifacts you'll collect for three purposes: to provide evidence that the program is being implemented, to help move processes and procedures along their integrated paths, and to provide material for measuring the effectiveness of your program. You should probably consider creating these records as blank forms or templates that can be used across the program and across different groups. These records are described in their respective sections later in this chapter.

4.2.2. Quality Manual

The previous section described what types of documents you'll need to support your QMS. Section 4.2.2 is specific to the Quality Manual.

The requirement here is to establish and maintain the Quality Manual.

The phrase establish and maintain is important to understand. It is a common process improvement term that implies three things. The first is clear: the system needs to be documented. By being documented, the program it contains can be made available to everyone in the organization who needs it. In addition to this, it needs to be maintained. This requires two other things. The manual needs an owner: someone or some group in the organization charged with maintaining its integrity. And maintaining the integrity means that it needs to be updated as your quality program changes over time. The two need to be kept in sync.

4.2.3. Control of documents

This section is related to Section 4.2.2. Your Quality Manual may include a number of documents, or it may reference other documents. To ensure the ongoing integrity of all the documents that impact your QMS, you should set into place proper versioning and access controls.

As mentioned above, the Quality Manual should be under the care of an owning group in your organization. This ownership carries with it certain access privileges. With any evolving quality program, change is to be expected. However, change needs to be controlled. You will not want just anyone in the organization to have the ability to make modifications to your QMS or to the Quality Manual. And so you will want to govern the ability to make changes to the manual or to any documents related to the manual. In addition to this, the owning group should have some form of version control in place, a system to mark or number releases of documents so people can reference the latest, most current versions. By implementing this requirement, the organization adds a protective layer of quality control over its Quality Management System.

4.2.4. Control of records

Just as you need to protect the integrity of the components of your quality program, you also need to protect the records that emerge from the regular use of the program. These records are important to the organization. They help demonstrate compliance with the Standard. They help move processes through their defined stages. And they provide useful measurement material. For these reasons, it's important to gather and store the records in a place that is secured and safe from accidental loss or corruption. As an example, for paper records, this may mean making copies and storing them in a fire safe or an off-site storage warehouse. For electronic records, this may mean making regular backups, archiving data to a safe media, and then storing this media in a safe place.

Required Records

To ensure that you have met the requirements of Section 4 of ISO 9001, one record is required: the Quality Manual. If you choose at some time to be officially audited, the ISO auditor will look for this manual as confirmation of Section 4 compliance. As noted earlier, this manual may be one large document, or it may be a collection of documents.

The required records for Section 4 include the Quality Manual.



 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows