Saturday, December 24, 2011

ISO 9001 Standard - ISO 9001:2008 Standards

Friday, October 9, 2009

Version Of ISO 9001 Standard

1987 version
ISO 9000:1987 had the same structure as the UK Standard BS 5750, with three ‘models’ for quality management systems, the selection of which was based on the scope of activities of the organization:
ISO 9001:1987 Model for quality assurance in design, development, production, installation, and servicing was for companies and organizations whose activities included the creation of new products.
ISO 9002:1987 Model for quality assurance in production, installation, and servicing had basically the same material as ISO 9001 but without covering the creation of new products.
ISO 9003:1987 Model for quality assurance in final inspection and test covered only the final inspection of finished product, with no concern for how the product was produced.
ISO 9000:1987
1994 version
was also influenced by existing U.S. and other Defense Standards (”MIL SPECS”), and so was well-suited to manufacturing. The emphasis tended to be placed on conformance with procedures rather than the overall process of management—which was likely the actual intent.ISO 9000:19942000 version
emphasized quality assurance via preventive actions, instead of just checking final product, and continued to require evidence of compliance with documented procedures. As with the first edition, the down-side was that companies tended to implement its requirements by creating shelf-loads of procedure manuals, and becoming burdened with an ISO bureaucracy. In some companies, adapting and improving processes could actually be impeded by the quality system.ISO 9001:2000
The ISO 9000 standard is continually being revised by standing technical committees and advisory groups, who receive feedback from those professionals who are implementing the standard.2008 version
ISO 9001:2008 only introduces clarifications to the existing requirements of ISO 9001:2000 and some changes intended to improve consistency with ISO 14001:2004. There are no new requirements. Explanation of changes in ISO 9001:2008. A Practical Guide to ISO 9001:2008 Implementation A quality management system being upgraded just needs to be checked to see if it is following the clarifications introduced in the amended version.
combines the three standards 9001, 9002, and 9003 into one, called 9001. Design and development procedures are required only if a company does in fact engage in the creation of new products. The 2000 version sought to make a radical change in thinking by actually placing the concept of process management front and center (”Process management” was the monitoring and optimizing of a company’s tasks and activities, instead of just inspecting the final product). The 2000 version also demands involvement by upper executives, in order to integrate quality into the business system and avoid delegation of quality functions to junior administrators. Another goal is to improve effectiveness via process performance metrics — numerical measurement of the effectiveness of tasks and activities. Expectations of continual process improvement and tracking customer satisfaction were made explicit.

ISO 9000 — a way of managing for conformance

Quality assurance, according to the Standard, is a way of managing that prevents non-conformance and thus “assures quality”. This is what makes ISO 9000 different from other standards: it is a management standard, not a product standard. It goes beyond product standardisation: it is standardising not what is made but how it is made. To use standards to dictate and control how organisations work was to extend the role of standards to new territory. To take such a step we might have firstly established that any such requirements worked — that they resulted in ways of working which improved performance.
Yet the plausibility of this Standard, and the fact that those who had an interest in maintaining it were (and still are) leading opinion, prevented such enquiries. In simple terms the Standard asks managers to say what they do, do what they say and prove it to a third party.
ISO 9000 (1994) paragraph 1: “The requirements specified are aimed primarily at achieving customer satisfaction by preventing non-conformity at all stages from design through servicing.”
To put it another way, the Standard asserts that preventing non-conformance achieves customer satisfaction. But does it? Of course it matters to customers that a product works. But there is no guarantee that the Standard will ensure even that. Furthermore, customers take a total view of an organisation — how easy it is to do business with — in respect of all things of importance to each and every customer.
ISO 9000 requires managers to “establish and maintain a documented quality system as a means of ensuring that product conforms to specified requirements”. Loosely translated this is “say what you do”. Management is supposed to “define and document its policy for quality . . . including its commitment to quality”.
What management would not declare its commitment to quality? But would they know what it means? Would they argue (as they should) that quality management is a different and better way to do business, or would they believe that ISO 9000 will take care of quality? The Standard encourages managers to think of “quality” and “business as usual” as separate and distinct. It helps managers avoid the revelation that quality means a wholly different view of management. Instead, the organisation “shall appoint a management representative who, irrespective of other responsibilities, shall have defined authority and responsibility” [for ISO 9000]. At a practical level this means only one executive might decide he or she had better learn a thing or two about quality. However, would being responsible for ISO 9000 lead to learning about quality or simply enforcing the ISO 9000 regime in an organisation?
Key to the regime is auditing. The Standard requires organisations to conduct internal quality audits to “verify whether quality activities comply with planned arrangements”. This can be loosely translated as “do you do as you say?” and the purpose of the audit is to see that you do. It was not until the 1994 review that the words were changed to “quality activities and related results”. It was a Standard which was rooted in the philosophy of inspection: fifteen years after its initial promulgation the promoters sought to extend the focus to results. But results or improvements assessed by what means? Inspection. By the time the Standard was adopted world-wide, quality thinking had moved a long way from the philosophy of inspection. It is now understood, at least by a few, that quality is achieved through managing the organisation as a system and using measures which enable managers to improve flow and reduce variation (which we explore in chapters 5 and 7). The defenders argue that there is nothing stopping a company having ISO 9000 and implementing methods for managing flow and reducing variation, but where are such companies? Few of the companies we researched, formally and informally, knew anything about this thinking. The Standard does not talk about it; moreover, the Standard effectively discourages managers from learning about it by representing quality in a different way.
According to ISO 8402 (quality vocabulary), quality is:
“The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs.”
Everything we have learned about ISO 9000 suggests that the people who created this definition were thinking about the things which need to be controlled, those things which “bear on its ability . . .”. The builders of the Standard assumed that customer needs would be listed in contractual agreements between the supplier and customer. ISO 9000 has a “make” logic — procedures for “how you do what you do” — and a “control” logic — check to see that it is done. It is a relic of the era when contractual agreements were perceived to be an important device for regulating the behaviour of suppliers. In these ways, ISO 9000 encouraged “planning for quality”.
Planning for quality sounds plausible, but it assumes many things: that the plan is the right plan, that it is feasible, that people will “do it”, that performance will improve. It is an approach which, paradoxically, leads to poor decisions. Planners of quality systems, guided by ISO 9000, start with a view of how the world should be as framed by the Standard. Understanding how an organisation is working, rather than how someone thinks it should, is a far better place from which to start change of any kind.

ISO 9000 — a way of managing for conformance

Quality assurance, according to the Standard, is a way of managing that prevents non-conformance and thus “assures quality”. This is what makes ISO 9000 different from other standards: it is a management standard, not a product standard. It goes beyond product standardisation: it is standardising not what is made but how it is made. To use standards to dictate and control how organisations work was to extend the role of standards to new territory. To take such a step we might have firstly established that any such requirements worked — that they resulted in ways of working which improved performance.
Yet the plausibility of this Standard, and the fact that those who had an interest in maintaining it were (and still are) leading opinion, prevented such enquiries. In simple terms the Standard asks managers to say what they do, do what they say and prove it to a third party.
ISO 9000 (1994) paragraph 1: “The requirements specified are aimed primarily at achieving customer satisfaction by preventing non-conformity at all stages from design through servicing.”
To put it another way, the Standard asserts that preventing non-conformance achieves customer satisfaction. But does it? Of course it matters to customers that a product works. But there is no guarantee that the Standard will ensure even that. Furthermore, customers take a total view of an organisation — how easy it is to do business with — in respect of all things of importance to each and every customer.
ISO 9000 requires managers to “establish and maintain a documented quality system as a means of ensuring that product conforms to specified requirements”. Loosely translated this is “say what you do”. Management is supposed to “define and document its policy for quality . . . including its commitment to quality”.
What management would not declare its commitment to quality? But would they know what it means? Would they argue (as they should) that quality management is a different and better way to do business, or would they believe that ISO 9000 will take care of quality? The Standard encourages managers to think of “quality” and “business as usual” as separate and distinct. It helps managers avoid the revelation that quality means a wholly different view of management. Instead, the organisation “shall appoint a management representative who, irrespective of other responsibilities, shall have defined authority and responsibility” [for ISO 9000]. At a practical level this means only one executive might decide he or she had better learn a thing or two about quality. However, would being responsible for ISO 9000 lead to learning about quality or simply enforcing the ISO 9000 regime in an organisation?
Key to the regime is auditing. The Standard requires organisations to conduct internal quality audits to “verify whether quality activities comply with planned arrangements”. This can be loosely translated as “do you do as you say?” and the purpose of the audit is to see that you do. It was not until the 1994 review that the words were changed to “quality activities and related results”. It was a Standard which was rooted in the philosophy of inspection: fifteen years after its initial promulgation the promoters sought to extend the focus to results. But results or improvements assessed by what means? Inspection. By the time the Standard was adopted world-wide, quality thinking had moved a long way from the philosophy of inspection. It is now understood, at least by a few, that quality is achieved through managing the organisation as a system and using measures which enable managers to improve flow and reduce variation (which we explore in chapters 5 and 7). The defenders argue that there is nothing stopping a company having ISO 9000 and implementing methods for managing flow and reducing variation, but where are such companies? Few of the companies we researched, formally and informally, knew anything about this thinking. The Standard does not talk about it; moreover, the Standard effectively discourages managers from learning about it by representing quality in a different way.
According to ISO 8402 (quality vocabulary), quality is:
“The totality of features and characteristics of a product or service that bear on its ability to satisfy stated or implied needs.”
Everything we have learned about ISO 9000 suggests that the people who created this definition were thinking about the things which need to be controlled, those things which “bear on its ability . . .”. The builders of the Standard assumed that customer needs would be listed in contractual agreements between the supplier and customer. ISO 9000 has a “make” logic — procedures for “how you do what you do” — and a “control” logic — check to see that it is done. It is a relic of the era when contractual agreements were perceived to be an important device for regulating the behaviour of suppliers. In these ways, ISO 9000 encouraged “planning for quality”.
Planning for quality sounds plausible, but it assumes many things: that the plan is the right plan, that it is feasible, that people will “do it”, that performance will improve. It is an approach which, paradoxically, leads to poor decisions. Planners of quality systems, guided by ISO 9000, start with a view of how the world should be as framed by the Standard. Understanding how an organisation is working, rather than how someone thinks it should, is a far better place from which to start change of any kind.

ISO 9000 vs Quality

ISO 9000 was conceived to bring about an improvement in product quality. It
was believed that if organizations were able to demonstrate they were
operating a quality system that met international standards, customers would
gain greater confidence in the quality of products they purchased. It was also
believed that by operating in accordance with documented procedures, errors
would be reduced and consistency of output ensured. If you find the best way
of achieving a result, put in place measures to prevent variation, document it
and train others to apply it, it follows that the results produced should be
consistently good.

The requirements of the standard were perceived to be a list of things to do
to achieve quality. The ISO co-ordinator would often draw up a plan based on
the following logic:
1. We have to identify resource requirements so I will write a procedure on
identifying resource requirements
2. We have to produce quality plans so I will write a procedure on producing
quality plans
3. We have to record contract review so I will write a procedure on recording
contract reviews
4. We have to identify design changes so I will write a procedure on identifying
design changes

The requirements in the standard were often not expressed as results to be
achieved. Requirements for a documented procedure to be established resulted
in just that. Invariably the objectives of the procedure were to define something
rather than to achieve something. This led to documentation without any clear
purpose that related to the achievement of quality. Those producing the
documentation were focusing on meeting the standard not on achieving quality.
Those producing the product were focusing on meeting the customer
requirement but the two were often out of sync. As quality assurance became
synonymous with procedures, so people perceived that they could achieve
quality by following procedures. The dominance of procedures to the exclusion
of performance is a misunderstanding of the implementers. The standard
required a documented system that ensured product met specified requirements – a
clear purpose. Once again the implementers lost sight of the objective. Or was it
that they knew the objective but in order to meet it, the culture would have to
change and if they could get the badge without doing so, why should they?

Issuing a procedure was considered to equate to task completed. Unfortu-
nately, for those on the receiving end, the procedures were filed and forgotten.
When the auditor came around, the individual was found to be totally
unaware of the ‘procedure’ and consequently found noncompliant with it.
However, the auditor would discover that the individual was doing the right
things so the corrective action was inevitably to change the procedure. The
process of issuing procedures was not questioned, the individual concerned
was blamed for not knowing the procedure and the whole episode failed to
make any positive contribution to the achievement of quality. But it left the
impression on the individual that quality was all about following procedures.
It also left the impression that quality was about consistency and providing
you did what you said you would do regardless of it being in the interests of
satisfying customers, it was OK. One is left wondering whether anyone
consulted the dictionary in which quality is defined as a degree of excellence?

Another problem was that those who were to implement requirements were
often excluded from the process. Instead of enquiring as to the best way of
meeting a requirement, those in charge of ISO 9000 implementation assumed
that issuing procedures would in fact cause compliance with requirements. It
requires a study of the way work gets done to appreciate how best to meet a
requirement. Procedures were required to be documented and the range and
detail was intended to be appropriate to the complexity of the work, the
methods used and the skills and training needed. The standard also only
required work instructions where their absence would adversely affect quality.
It is as though the people concerned did not read the requirement properly or
had no curiosity to find out for themselves what ISO had to say about
procedures – they were all too ready to be told what to do without questioning
why they should be doing it.

More often than not, the topics covered by the standard were only a sample
of all the things that need to be done to achieve the organization’s objectives.
The way the standard classified the topics was also often not appropriate to the
way work was performed. As a consequence, procedures failed to be
implemented because they mirrored the standard and not the work. ISO 9000
may have required documented procedures but it did not insist that they be
produced in separate documents, with titles or an identification convention
that was traceable to the requirements.

Critics argue (Seddon, John, 2000)3 that ISO 9000 did not enable organiza-
tions to reduce variation as a result of following the procedures. It is true that
ISO 9000 did not explain the theory of variation – it could have done, but
perhaps it was felt that this was better handled by the wealth of literature
available at the time. However, ISO 9000 did require organizations to identify
where the use of statistical techniques was necessary for establishing,
controlling and verifying process capability but this was often misunderstood.
Clause 4.14 of ISO 9001 required corrective action procedures – procedures to
identify variation and eliminate the cause so this should have resulted in a
reduction in variation. The procedures did not always focus on results – they
tended to focus on transactions – sending information or product from A to B.
The concept of corrective action was often misunderstood. It was believed to be
about fixing the problem and preventive action was believed to be about
preventing recurrence. Had users read ISO 8402 they should have been
enlightened. Had they read Deming they would have been enlightened but in
many cases the language of ISO 9000 was a deterrent to learning. Had the
auditors understood variation, they too could have assisted in clarifying these
issues but they too seemed ignorant – willing to regard clause 4.20 as not
applicable in many cases.

Clause 4.6 of the undervalued and forgotten standard ISO 9000 –1 starts with
‘The International Standards in the ISO 9000 family are founded upon the
understanding that all work is accomplished by a process.’ In clause 4.7 it starts
with ‘Every organization exists to accomplish value-adding work. The work is
accomplished through a network of processes’ In clause 4.8 it starts with ‘It is
conventional to speak of quality systems as consisting of a number of elements.
The quality system is carried out by means of processes which exist both within
and across functions’ Alas, few people read ISO 9000–1 and as a result the
baggage that had amassed was difficult to shed especially because there were
few if any certification bodies suggesting that the guidance contained in ISO
9000 –1 should be applied. Unfortunately, this message from ISO 9000 –1 was not
conveyed through the requirements of ISO 9001. ISO 9001 was not intended as
a design tool. It was produced for contractual and assessment purposes but was
used as a design tool instead of ISO 9000 –1 and ISO 9004 –1.

Quality Characteristic in ISO 9000

Any feature or characteristic of a product or service that is needed to satisfy
customer needs or achieve fitness for use is a quality characteristic. When
dealing with products the characteristics are almost always technical character-
istics, whereas service quality characteristics have a human dimension. Some
typical quality characteristics are given below.

Product characteristics
1. Accessibility Functionality Size
2. Availability Interchangeability Susceptibility
3. Appearance Maintainability Storability
4. Adaptability Odour – Strength
5. Cleanliness Operability -Taste
6. Consumption Portability – Testability
7. Durability Producibility Traceability
8. Disposability Reliability – Toxicity
9. Emittance Reparability Transportability
10. Flammability Safety – Vulnerability
11. Flexibility Security – Weight

Service quality characteristics
1. Accessibility Credibility – Honesty
2. Accuracy Dependability Promptness
3. Courtesy Efficiency – Responsiveness
4. Comfort Effectiveness Reliability
5. Competence Flexibility – Security

These are the characteristics that need to be specified and their achievement
controlled, assured, improved, managed and demonstrated. These are the
characteristics that form the subject matter of the product requirements
referred to in ISO 9000. When the value of these characteristics is quantified or
qualified they are termed product requirements. We used to use the term quality
requirements but this caused a division in thinking that resulted in people
regarding quality requirements as the domain of the quality personnel and
technical requirements being the domain of the technical personnel. All
requirements are quality requirements – they express needs or expectations that
are intended to be fulfilled by a process output that possesses inherent
characteristics. We can therefore drop the word quality. If a modifying word is
needed in front of the word requirements it should be a word that signifies the
subject of the requirements. Transportation system requirements would be
requirements for a transportation system, Audio speaker design requirements
would be requirements for the design of an audio speaker, component test
requirements would be requirements for testing components, and management
training requirements would be requirements for training managers. ISO 9000
requirements are often referred to as quality requirements as distinct from other
types of requirements but this is misleading. ISO 9000 is no more a quality
requirement than is ISO 1000 on SI units, ISO 2365 for Ammonium nitrate or
ISO 246 for Rolling Bearings. The requirements of ISO 9000 are quality
management system requirements – requirements for a quality management
system.

Tuesday, October 6, 2009

Implementing A Quality Management System

Implementing A Quality Management System
An ISO 9000:2008 quality management system can be implemented by following the steps detailed as follows:
1. Evaluate the organization’s need/goals for implementing a QMS Need may arise from repeated customer complaints; frequent warranty returns; delayed deliveries; high inventories; frequent production hold-ups; and high level of rework or rejection of products or services.
At this stage, identify the goals which you would like to achieve through a QMS, such as customer satisfaction, increased market share, improved communications and morale in the organization, greater efficiency and profitability, etc. Another objective in implementing a QMS may be a demonstration of compliance through third party certification, which may be requested by an important client or required for enlisting as a supplier to large companies, e.g., original equipment manufacturers (OEMs).
2. Obtain information about the ISO 9000 family
The persons identified for initiating the development of an ISO 9000 QMS need tounderstand the requirements of ISO 9001:2008 as read with ISO 9000:2000 and ISO 9001:2008.
Supporting information such as quality management principles, frequently asked questions (FAQs), guidance on clause 1.2 (application) of ISO 9001:2008, guidance on documentation requirements of ISO 9001:2008 and other brochures are available free of charge on the ISO web site;
3. Appoint a consultant, if necessary
If, within the organization, you do not have adequate competence to develop a QMS, you may appoint a consultant. Before doing so, it is good to check his/her background; knowledge about the product realization processes of your organization; and experience in helping other organizations to achieve their stated goals, including certification.
Carry out a cost-benefit analysis of hiring a consultant and agree the scope of his/her work in writing. It is also possible to appoint a consultant only for the training of key staff; the latter can then carry out further training and development of the system.
4. Awareness and training
Raise awareness about QMS requirements amongst all personnel performing activities that affect quality. Plan for and provide specific training on how to develop Quality Manuals; on procedures; on QMS planning; on how to identify and implement improvement processes; and on how to audit compliance with the QMS, etc.
The Institute of Quality Assurance (IQA), the American Society for Quality (ASQ)and the International Auditor and Training Certification Association (IATCA) can provide lists of training organizations.
5. Gap analysis
Evaluate gaps between your existing quality management system and the QMS requirements of ISO 9001. Prepare how to bridge these gaps, including by planning for any additional resources required. Gap analysis may be carried out through selfassessment or by the external consultant.
6. Product realization processes
Review clause 7 of ISO 9001:2008 relating to “Product realization” to determine how the requirements apply or do not apply to your company’s QMS.
The processes covered by this clause include:
• Customer-related processes
• Design and development
• Purchasing
• Production and service provision
• Control of measuring and monitoring devices
Note that if your company is not responsible for preparing the design of your product, you can exclude the requirement for “design and development” from your QMS and explain the reasons for doing so in your Quality Manual.
7. Staffing
Decide on the responsibilities of the persons who will be involved in developing and documenting the QMS, including the appointment of a management representative who will oversee the implementation of the QMS. Establishing a project Steering Committee may also prove useful to oversee progress and provide resources wherever required.
8. Planning a time frame
Prepare a complete plan to close the gaps identified in Step 5 to develop the QMS processes. In the plan, include activities to be performed, resources required, responsibilities and an estimated completion time for each activity. Clauses 4.1 and
7.1 of ISO 9001:2008 provide information that should be used when developing the plan. The total time required for each phase (planning, documentation, implementation and evaluation) depends on the extent of the gaps in your existing QMS.
9. Draft a Quality Manual
In your Quality Manual;
• Include how the QMS applies to the products, processes, locations and departments of the organization;
• Exclude any requirement with justification for doing so as decided in step 6
above;
• Refer to or include documented procedures for QMS;
• Describe the interaction between the processes of the QMS, e.g., the interaction between product realization processes and other management, measurement and improvement processes; and
• Draft the quality policy and quality objectives for the organization.
The staff concerned in the organization should review the Quality Manual and the documented procedures so that their comments and suggestions can be taken into account before the Quality Manual and procedures are approved for issue and use.
The effective date of implementation should also be decided.
10. Carry out internal audits
During the phase of implementation of some three to six months after the documentation has been written, the trained auditors should carry out one or two internal audits covering all activities for the QMS, and concerned management should take corrective action on the audit findings without delay. Wherever required, revise the manuals, procedures and objectives. After each internal audit, the top management should review the effectiveness of the system and provide necessary resources for corrective actions and improvements.
11. Apply for certification
On satisfactory completion of Step 10, and if your company decides to obtain third party certification, you can make an application for certification to an accredited certification body. The certification audit process is explained section VII.
12. Conduct periodic evaluations
After certification, the organization should periodically conduct internal audits to review the effectiveness of the QMS and see how it can be “continually improved”. The organization should evaluate periodically if the purpose and goals (see Step 1) for which the QMS was developed are being achieved, including its continual improvement.