The Elsmar Cove Business Standards Discussion Forums More Free Files Forum Discussion Thread Post Attachments Listing Elsmar Cove Discussion Forums Main Page

Welcome to the Elsmar Cove!
Business Standards Information Exchange

Originally Posted on 24 June 2004, but very little has changed ;-)

As I stated below about 3 years ago, this page is originally circa 1999. However, it remains as a good 'Food for Thought' reference. Why? Because if you hang around the forums as much as I do you can easily see that the below basic failure modes, although not re-aligned to ISO 9001:2000, are still very much the same. I suggest that you take a few minutes and read through the page and THINK about the details... If one of these sinks your registration audit, SHAME on you... These are really COMMON 'mistakes', folks! Make sure you KNOW how the requirements apply to YOU! Become a regular visitor to the Elsmar Cove Forums!

The major difference with the most recent 'interpretations' vs. what you will find below, is that auditors are being taken off 'check lists' and being put into the 'process model' audit mode. This does not mean that the below failure modes are not still relevant. The systems must exist and function as below. The focus now is on process inputs and process outputs, however in some way they have to show they looked at each system required by the standard. The bottom line? Focus: Numbers in and numbers out.

Audit Failure Modes and What to Expect Discussions

July 2001

This document is circa 1999. For all intents and purposes, however, the failure modes of a registration audit remain the same. Only the numbering has been changed with repect to ISO 9001:2000 and the (future) ISO(?) / TS 16949:2002. The point of this listing is more to the point of systems requirements than to any numbering scheme. For example, if your calibration system does not include a recall 'method', it will not be compliant. In any area or system, if folks are supposed to initial and date where they perform their operation or check in a process on a traveler (if your system is set up with travelers - but I'm only using travelers as an example - it could be approval of a purchase order) -- If folks are not initialing and dating (many of them just don't 'find the time, or whatever the excuse may be) the traveler as their system requires, then there will be a problem.

In my opinion, there are not really significant changes in audit failure modes. For this reason I see not reason to update this to the current month/year - it's July 2001 and recent registrations have me convinced the gist of this list has not changed. Please read these with the understanding that it's not the 'numbering' is not that important. Use this information for thought about YOUR systems.

Circa 1997

What is the REAL Primary Failure Mode in reaching registration?
What is the REAL Root Cause of failure to pass a registration audit?

First Time Registration Failure

In most of what you read, you will be told that the primary failure mode is Document Control, Calibration or other 'simple' related issue. In its simplicity, this evaluation is correct. There is a general failure to understand documentation and calibration requirements. How much do we document? How far? Everything? Gage R&R? Location of Use? Frequency of Calibration based upon History? But it's not all that simple.

In the case of calibration - does your company have someone knowledgeable about calibration systems setting up and/or running the calibration end, or was someone found to 'fill a system hole' who knows little or nothing about calibration? Is your design program compliant to the APQP guide (if QS) and does it provide for gage R&R plans, control plans, 'appropriate' FMEAs and other necessary 'details'?

What I am trying to highlight is the fact that you need to have people doing jobs they know more than just 'something' about. I worked with one company which put a metallurgist in charge of the calibration laboratory. He knew nothing about calibration and measurement systems. His 'territory' showed ample evidence he didn't know beans about metrology and he had no hesitation to say he wasn't about to learn a new system. Guess what kind of problems developed out of this...

The 'Official' List:

Common ISO Noncompliances
(also applies to TS 16949 to a large degree)

4.1.1 Quality Policy
- A policy statement does not exist.
- The policy statement is not implemented or not distributed to all levels of the organization.
- The policy statement contains statements that are not relevant or addresses goals that are contradictive.
- The intention and content of the statement are not understood.
- Quality Policy is not signed by the company management.
- Quality Policy does not include measureables.
- Quality Policy measureables not adequately tracked.

4.1.2.1 Responsibility and Authority
- Job descriptions, defining responsibility and authority do not exist or they are not up to date.
- Management does not follow the given descriptions. (Are they not understood?)
- Lack of communication between departments.
- Use of the word "equivalent" not defined.

4.1.2.2 Verification of Resources and Personnel
- Adequate resources are not present. Internal audits are not carried out by independent personnel.
- No formalized training or assessment of training needs.
- Lack of feedback from the field and lack of communication between departments.

4.1.2.3 Management Representative
- Quality Manager does not have the organizational authority to implement system changes.
- Quality Manager has an insufficient job description or it is not followed.
- Management Representative does not participate in the Management Review process.

4.1.3 Management Review
- The content of the management review is not understood or defined.
- Management review is not implemented.
- Management review is not documented.

- The quality system is not implemented unless evidence of management review is present.
- Management review has to contain results of corrective actions and internal audits.

4.2 Quality System
- The system does not address all applicable elements of the ISO 9000 Standard.
- The system is not properly documented.
- The ISO 9000 Standard is not fully understood.
- The quality documentation is not complete.
- Document changes are not authorized.

To be able to certify a company's quality system, the quality manual must address all the applicable elements of the standard and the manual and necessary procedures and instructions have to be implemented prior to the assessment.
In notes a) through b) (in 4.2) it is outlined different activities of which a system should consist of. These notes should give valuable information for the planning of a quality system and examples of noncompliances can be given for each of those.

In some circumstances, when a system is established, it may be necessary to develop a quality plan for certain projects where it is obvious that additional requirements are applicable. Such requirements may be specific national or international requirements in addition to certification requirements and customers specifications. Normally, a quality plan would be the outcome of a contract review.

Examples of non-conformities with reference to NOTE in 4.2:
a) No quality plan for projects or products where requirements deviates from the implemented quality system.
b) Lack of identification of inspection techniques and inspection hold points. c) Lack of updated testing techniques.
d) Lack of planning and assessment of capabilities.
e) Not sufficient definition of the acceptance standards and criteria.
f) Not sufficient involvement from all applicable departments.
g) Storage of and the identification of quality records are not sufficient.

4.3 Contract Review
- Procedures are not existing or they are insufficient.
- Procedures are not implemented.
- Lack of involvement from other departments (e.g. design, sales, manufacturing).
- Not defined or incomplete records.

4.4 Design Control
Design departments are often a very complex area to control. A lot of the problems found may be routed back to improper procedures or procedures not being implemented. Some companies are presenting the reaction that to be able to comply with the ISO Standard the development of new designs may be limited. This, however, is not so but is rather a reflection to the fact that the companies do not know how to formalize their system for control.
- Design responsibilities and communication between departments are not defined.
- Records of design reviews are not kept or they are not complete.
- Design input is not properly defined or documented.
- Applicable requirements are not defined (e.g. customer specifications, safety regulations, etc.).
- Design changes are not formally approved or they are approved by unauthorized people.
- Drawings are not approved or subject to a defined document control system.
- Drawings are not readable or they are inconsistent with present manufacturing methods.
- Drawings in manufacturing have the wrong revision.
- Process, inspection and test equipment are not defined.
- Evidence of qualifying and verifying a new design is not present.

4.5 Document Control
- System not established or implemented.
- No system for formally submitting and retrieving documents.
- Not identified which documents are to be controlled.
- Changes are not authorized or authorized by other functions than the originator.
- No personnel responsible for the master lists.
- Not identified how many changes may take place prior to reissue of the document.

4.6 Purchasing
- No formal assessment of suppliers.
- Purchasers are using suppliers that are not assessed or formally approved.
- Not a system for traceability of products being purchased by a non-approved supplier in an emergency.
- No criteria for how to assess a supplier.
- Records of suppliers are not present.
- Lack of follow up of corrective actions.
- Purchasing documents with insufficient data.
- No evidence of review and approval of purchasing documents prior to release.

4.7 Purchaser Supplied Product (OFTEN NOT APPLICABLE)
- No defined area for storage of items.
- Returnable containers not addressed.

4.8 Product Identification and Traceability
- No segregation of batches where batch identification is required.
- Insufficient traceability when this is called for.

4.9 Process Control
- Insufficient work instructions.
- Procedures and work instructions not implemented.
- Unauthorized changes in work instructions.
- Insufficient training.
- Lack of proper calibration of process equipment.
- Lack of assessment of manufacturing capability.

4.10 Inspection and Testing
Receiving Inspection and Testing:
- Insufficient data for the receiving inspection .
- Lack of marking of inspected items.
- No defined storage area or marking for non-conforming items.
- Release of non-conforming parts to be used in an emergency properly authorized nor sufficient traced.
In-process inspection and testing:
- Insufficient inspection procedures.
- No evidence of inspection or testing.
- Inspections being by-passed.
Final Inspection and testing:
- Lack of segregation between approved and non-approved products.
- Inspections carried out with drawings not showing the same revision as the production drawings.
Records:
- Records are not complete
- Storage area is not defined.

4.11 Inspection, Measuring and Test Equipment (M&TE)
- Recall system not properly maintained.
- Employees are using equipment that are not calibrated or the calibration is expired.
- Calibration status is not easily understandable.

4.12 Inspection and Test Status
- Incomplete travelers, inspection sheets etc.
- No evidence of authorized release of the product.

4.13 Control of Nonconforming Product
- Authority for disposition of nonconforming products is not defined.
- Evidence of approval for disposition form the review board is lacking.
- Lack of segregation of nonconforming products.

4.14 Corrective Action
- System for corrective actions not followed.
- The initiation of a corrective action report is reserved to a limited group (i.e. system not implemented).
- Corrective action does not address the root of the problem.
- Procedures do not include preventive actions and documented follow up.

4.15 Handling, Storage, Packaging, Preservation and Delivery
- Lack of procedures.
- Procedures not implemented.
- Procedures are incomplete.
- Shelf life not defined or expiration date not followed.
- Fragile items not protected.

4.16 Quality Records
- Lack of identification of storage areas.
- Retention periods not defined or not followed.
- Records are not legible.
- Quality records not defined [Identified throughout the standard as (4.16)].

4.17 Internal Quality Audits
- System not in use or system insufficient.
- Audits based on outdated check-lists.
- Corrective action requests not responded to.
- Auditors not independent from the department they are auditing.
- Insufficient records.
- External audits regarded as part of internal audits.
- Evidence of closure.
- Complete round of internal audits not completed.

4.18 Training
- Insufficient identification of training needs
- No formal training assessment.
- Training insufficient.
- Records not kept or they are insufficient.

4.19 Servicing
- Poor communication between service department and design / manufacturing.
- No feedback from servicing towards product quality.

4.20 Statistical Techniques
- System not used where SPC could definitely improve quality.
- System addressed in the quality manual but not implemented.
- Gage R&R not sufficiently addressed.
- Element addresses ONLY SPC. Other statistical techniques not addressed.

From Early 1996 - An Old Diatribe - Revised [somewhat] on 1997-05-29 and 1998-04-18

Folks, the truth here is most failures are the direct result of a lack of direct involvement and understanding of both QS - ISO 9000 and their own systems by top management (Root Cause). This is not always apparent. It just doesn't seem to follow that a top management failure is the root cause for the failure of a system element such as Document Control (check out the 'Calibration Tidbits' on this web site for an example).

The involvement and interest of the top management is, however, only one part. The understanding of the basic requirements necessary are as important as the involvement. Knowledge base of QS - ISO 9000 compliant systems is also very important. When one needs an individual for a welding process, one does not hire a draftsman. The hard core truth of the situation is this:

QS 9000 (now TS 16949) and ISO 9001 = New PROCESS

And if you don't have someone internal who knows the process, hire someone or target someone to learn. You have to have a 'Knowledge base' at your company.

********************************************

I can say with certainty that both ISO and QS will be around for a while and should be looked at (initially) as a new cost of doing business. Those who believe this 'new quality' will in any way save them significant money in the short term may be bound for disappointment junction. I say this with some hesitiation as I see many companies now which really do embrace the requirements and there is some measurable evidence that in the short *and* long run a company will save money. I believe this is where a company achieves a higher level of organization and attention to the significance of details. I also see that the design efforts become better structured producing more 'robust' product design. My problem with this in the past is that I hold it to be that most of what is in the specs is common sense for a company. Better design reduces costs. This is nothing new. Now it comes to pass that ISO and QS are forcing companies to do a better, more consistent job at design - which they should have been doing in the first place...

I also see companies where the process documentation is terrible where going through the process brings the issue to light and it is corrected.

It is generally the failure to provide the proper knowledge base - someone who knows and understands documentation systems (as well as multiple processes and systems - including how they interact) - which painfully extends the time to registration and exponentially increases the cost of registration. Coupled with a lack of management involvement and understanding, registration is a long, seemingly unending 'sentence'. Chinese water torture before the inquisition. More appropriately, like Alphonse "McCarthy" D'Amato's WhiteWater Committee Inquisition. Like the Energizer Bunny - it keeps going, and going, and going, and..... Never seems to get anywhere.

Some companies hire consultants to come in and do the documentation and such. While I have seen this work, it is generally in smaller, less complex organizations. We all know when you do an implementation this way the employees don't 'own' the systems and documents. More typically, efforts like these are targeted for failure. One effort I was involved in illustrated this well. A large corporation was broken up into 'departments' or 'organizations'. The effort was disjointed in many ways, but it was interesting to watch. Each organization had a 'consultant'. Each organization had it's own personality. Some organization managers balked. some were gung-ho. A couple of consultants actually wrote the organization documentation - both process relarted and systems related. Others forced all to be written, etc. by the folks in the organization. AFTER the audit, within 3 months those organizations which had their documentation written for them were practically dead in the water - no continuous improvement. When the consultants which wrote their documentation left, the process stopped. Yes - plenty of production was going on. But - no one knew the systems, etc., so they were stuck. Those forced to do their own were right on track. Corrective actions were addressed and the areas were progressing.

What about Management Review? It is easy to flow chart out and document a system which provides management review meetings and related documentation. Basing decisions on meeting content and other QS requirements is another matter. A check list should be utilized to ensure each element is addressed.

Another major failure mode is failure to act on internal corrective actions in response to deficiencies. Auditors take a dim view of Corrective Action Requests languishing for months on end. Even a minor can become a major if not acted upon. This, of course is a direct function of the top management and their involvement. I continually get e-mail from folks with follow-up problems. Typically its something like "I'm trying to get managers to act on corrective action requests but I don't get much action - and none of them can supply me with proof of effectiveness". Elevation should take care of this problem but typically it does not actually function that way. Either it is not elevated as the system requires or management doesn't act when it is elavated.

The truth is, the company president and his/her 'aides' (read directors, managers, etc.) generally are the last to know what's going on. This is not to say that there are none that get involved. Indeed, wonderful stories exist which cite CEOs and company owners who were positively, actively involved in their company's registration effort. Sadly, this is seldom the case. One more often finds upper management who expect things to happen with borderline involvement - "Hey Phred - what's the status of the ISO thing?" Some don't ask THAT many questions! And they have no idea how much it is costing, and will continue to cost, the company. The reason is the authority link. Only they have the real authority to make things happen.

If and when you decide to 'go for' ISO 9000 (or QS 9000, for that matter - even more so..), it is extremely important to have set meetings where top management is present and leads at least every two weeks (or more frequently) to review the status of the project - because Folks, implementation is just that - a major project. It is Extremely important that at these meetings decisions are made.

Another failure mode is the failure of decisions to be made promptly and acted on promptly. In larger companies this becomes more and more difficult. As the size of the company increases, the more insulated top management tends to become. Meetings become bogged down in details and a year later decisions are yet to be made. The costs of implementation are sky rocketing and the whole project is moving slower than a sloth. Decisions must be made and acted upon.

Post-Registration Audit Failure

QS 9000 (now TS 16949) and ISO 9000 are forcing upon industry a system of audits. Most people fail to recognize that ISO is the vehicle to address national and international liability issues. As proof I offer the fact that more and more courts are hearing plaintiffs lawyers ask for Internal Audit reports and other ISO/TS related documentation. Folks, this is just like the system where by banks are monitored by third party and federal audits. And it is not going away. ISO will continue to grow. More and more lawsuits will require ISO required documentation. Post-registration failures are almost always caused by a company who takes the effort as a one-time project.

Most post-registration audit failures are a result of what I call the Q101 Syndrome (also known as the TFE Syndrome and as several others, as well). What are these 'syndromes'? Why are they so dangerous and damaging?

In the past, Ford [as an example, however the TFE Syndrome would work just as well ;) ] came around and made you go through the Q1 or Q101 hoop (audit) in order to 'win the prize', whether that be sales or whatever. When the auditors were out the door, it was over. Period. In fact, many audits were more meals and golfing than an actual audit. There was little (if any) interest in maintaining systems which were not going to be continuously monitored. Coupled with the fact that, as we all know is the reality, customer-supplier audits are not always quite level, and a good dinner, golf and some entertainment could go a long way. Folks, this is the way automotive was. A paradigm shift is necessary for most companies.

But let's not get lost in an automotive haze (we want to address both ISO 9000 AND TS 16949, lets look at the failure mode - the system implemented is (or soon becomes) static. And when a system is static, it is quite probable that established procedures have limited value as people tend to 'forget' they are there. So after spending boo coo bucks to produce and implement documented systems, ya gotta do it again!

I have gone into a company and designed excellent (my opinion) systems - and 6 to 9 months later the systems still exist on paper but for all intents and purposes, 'the audit was over months ago'.

I hear about consultants getting calls and hearing, "Hey, you know that blankety-blank system you set up? Well, it's not working". First of all, the system is generally already there and is documented during the project - we seldom pull systems out of the air and say "Hey - you'll do this". But more importantly, the failure mode is ALMOST ALWAYS where someone is simply not following the system as documented. It never ceases to amaze me when I hear (and I do on a regular basis) "Well, I know what the procedure says, but it works better for me if I...do it my own way..." No mention of changing the documentation to reflect this 'better' method. It really is a case of "I'll do it however the hell I want when I can get away with it." Does this person fill out expense reports however he/she wants? What ELSE does this individual do 'the way he/she wants'? If something is supposed to be tested at a certain temperature, will that person test it however, and at whatever temperature, he/she wants because it's 'easier' for him/her? These individuals you had best educate and watch closely - or reposition where they can do no harm. This is, by the way and from experience, why I now warn companies which want me to write their systems documentation. If you force them to do it - they will own it. There is less of a problem of failure to follow-through.

All procedures (written or unwritten) must be followed by everyone without exception. This cannot be an 'option' for anyone. It should be made clear at each hiring. They are the law until changed. If you have someone painting a product and the spec calls for blue paint, how long will you employ that person if he/she decides to use red paint?

Going into a project I explain to management they should have a specific someone to work with me so that when I am done, there is a person in their employ who is 'fully trained' to take over and maintain the established documentation and such. And - this provides a person who can EXPLAIN the systems, how they interact and explain all the roadmaps. I'm gonna tell you straight - they almost never do - that takes manpower. They generally pay down the road when someone has to come in and straighten things out when the next audit is due. If there is one thing in all of this to consider, consider a dedicated person to monitor and run the show until you are sure the system can run 'on it's own'.

Control of, and verification of, system life and vitality is a robust Internal Audit System supported by upper management through management review. There is no alternative that I know of. The registrar audit(s) will expose this - if you don't do yours and react, they will find it. It's that simple. Whether you are looking at QS 9000 or ISO 9001 - There is an auditor in your future - about every six months.

 

It is my personal opinion, based upon observation and upon evaluation of the observations of others, that even hot points like Documentation failures are a direct result of a failure of management to be fully involved and informed through regular implementation team - management meetings at least every other week. Secondarily management fails to exert leadership in requiring it to be known that procedures are law - not discretionary.

The Elsmar Cove - 2017