Conducting Internal Audits

Internal audits are a requirement of ISO 9001.   They are a critical component of any quality management system (QMS).  They let management know whether or not the QMS is compliant with ISO 9001, and will indicate any significant non-conformances to the QMS or the standard.

There should be an audit schedule.  The QMS must be in compliance with the schedule.  The external auditor will review random audits for completeness and for the quality of the audit performed.  A typical audit schedule might look like:

Process	Audit Frequency	Audit Month
Purchasing	annual	May
Design	annual	June

 An internal audit is compliant if it has a list of the questions asked and whether or not the QMS was in compliance with the question.  However, meeting these basic requirements does not necessarily mean that a quality audit was performed.

When creating an audit checklist, first study the process or document.  Form questions designed to understand whether the process is in compliance.  When forming the questions, consider requirements that go beyond the basic process requirements of the process.  For example when auditing a manufacturing process, it is natural to ask questions that determine whether or not the process is being followed.  In addition though, other questions such as ‘Are the technicians trained to perform these tasks?’ or ‘Are production records stored in the supervisors office?’ addresses other questions related to ISO 9001 that go beyond the basic process steps.

Collect objective evidence that the response is or is not in compliance with the process.  Since audits will be reviewed later, it’s important to show how the answer to an audit question was achieved.   This is especially important if the process is not in compliance with a question because a corrective action is required when noncompliance is uncovered.  The process owner will want to see the objective evidence to know how noncompliance was determined and to respond to the CA.

Objective evidence may take many forms.  An employee interview indicating who was spoken to and what questions were asked is one form of evidence.  Copies of records, or the record type examined and the record’s document number is another.  The number of records examined need not be large.  Five records of a record type are enough in most cases.  More records might be required if a significant noncompliance is uncovered.  In this case the auditor should be able to show whether the noncompliance is an isolated incident or a systemic problem.

In larger structured companies it is important to schedule audits with the audited organization in advance.  I like to audit without providing advanced notice, but this is not always possible.

Some people get uncomfortable when an audit is being conducted.  It is important to make those

audited comfortable with the audit.  I like to start an interview by explaining that I’m conducting a process audit, what process I’m auditing and that the audit is just a routine audit.  I point out that there are no wrong answers to the questions I’m going to ask.

Finally, keep in mind that the output of an audit is a record, and as such must meet the requirement of 4.2.4 Records.  I bring this up only to remind readers that audits must be legible and retrievable.

Design Verification and Validation

I’ve often been asked what the difference is between design verification and validation.  The terms design verification and design validations seem to mean the same thing, and in some standards the terms verification and validation are used interchangeably.  In ISO 9001, they are used to mean different things.

When and engineer starts a design, he starts with design inputs – the requirements he’s designing to.  When the design is complete, there are design outputs: specifications, drawings, etc. that describe the design.  Design verification then is the step of verifying that all the design input requirements have been addressed in the design.

A technique I like to use to do design verification is a compliance matrix.  Each row of the matrix is an input requirement, and each column of the matrix is a design output specification section or paragraph.  In a cell where the input was addressed in a particular specification I place an ‘X’ to indicate that the input requirement is addressed there.

To imagine the compliance matrix, consider an Excel spreadsheet where the requirements are the numbered rows, and the design output that addresses the requirement is one of the lettered columns.  In most cases one input requirement is addressed in one place in the output specifications, but this is not necessarily the case.   I’ve used this technique when assisting customers in the design of a quality management system based on ISO 9001.

Design validation is the process of determining whether or not the design functions to the input specifications.  This means manufacturing the product to the specifications and testing it against the input and output requirements to see if it works as intended.  Prototype testing falls into this category.  A test plan is created based on the input and design requirements (there might be additional requirements required by the design that were not included by the customer), and the product is tested to determine conformance.

 

Corrective Action

Corrective action is a critical component of ISO 9000.  The standard specifically requires a documented procedure that describes the corrective action process.

Quality can be free, but it can also be very expensive.  Consider the following example.

A company I was working with was having a problem with a supplier part.  A pneumatic valve appeared to fail at the customer’s assembly plant.  We couldn’t tell if the product was defective from the supplier, we were making it defective, or if the customer was handling the product improperly.  But it was clear that the product coming back from the end customer was defective.  The valve just didn’t work.

Not knowing the source of the problem, we began adding fixes:

•             100% inspection of the incoming valves
•             Added a test fixture to test the valves in a final assembly
•             Reduced the voltage to the valve to weed out any borderline valves
•             A neophyte decided that more is better so the valves were tested 10 times instead of once (as if you can inspect quality into the product)

Still the customer reported defects.  We proposed that the customer test in a piece of test equipment like ours so we could determine if the product was acceptable on arrival, and before it was installed into the customer’s product.  The customer balked.
Finally, a year after the problem initially arose, the customer realized that the wattage of the solenoid should be a quarter watt, but they had specified a 1 watt coil.  Low and behold – problem solved.

If you were to watch the manufacture of the subassembly today you will see an operator testing the valve 10 times.

Depending on who you talk to, there are 4 or 5 or 8 steps to corrective.  Here are my five:

1. Problem Statement
1. State the requirement
2. State the non-conformance
3. State the objective evidence of the non-conformance
2. Containment Plan
1. When did the problem start
2. What are we doing to control the bleeding while we are looking for a solution (short term fix)
3. Root cause analysis
1. There are a myriad of techniques, such as fishbone analysis, control system model, etc.
2. Expect there to be more than one root cause.
4. Corrective Action Plan
1. What will be done to eliminate the root causes?
2. When will it be implemented?
5. Follow Up
1. Was the implemented corrective action effective (did it eliminate the root causes)?
2. Was the short term fix removed?

Corrective action is not rocket science, but root cause analysis can be difficult.  In many cases we see that once the fix has eliminated the pain, it tends to stay in place, and no root cause analysis is performed, or if it is performed, the short term fix is not removed.  Adding inspection and testing which would otherwise not be necessary increases quality cost (and product cost) while not eliminating the source(s) of the problem.

For more information go to www.rosehillsystems.com

Management Review

One of the requirements of ISO 9001 is 5.6 Management Review.  The idea is that periodically, management reviews the effectiveness of the quality management system (QMS) and determines what changes are necessary to improve it.  It is the responsibility of the Management Representative to prepare these reviews.

ISO 9001 has very specific requirements for the inputs and outputs of the management review process.  The required inputs are:

·         Results of audits

·         Customer feedback

·         Process performance and product conformity

·         Status of preventive and corrective actions

·         Follow-up from previous management reviews

·         Changes that could affect the QMS

·         Recommendations for improvement

To these, I like to add data analysis results.  It’s not required, but it makes a lot of sense.  The standard expects data analysis from various processes to be used as inputs to the preventive action process.  Why not share these analyses with management? This allows them to be involved in selecting those actions to work on.  It also documents the data analysis, which is evidence that we are complying with section 8.4 Analysis of data.

An example of data analysis is on time delivery to customers.  We might study late deliveries by product, and do a simple Pareto analysis to identify the worst offenders.  A recommendation for improvement might be to study the top five late delivered products to identify the root causes.

One of the outputs of the management review should be action items:

·         What are we going to do?

·         Who’s responsible for getting it done?

·         When will it be done?

These action items will become inputs to the next management review.

Attendance

Attendance should include all senior management, all middle managers, and any other employees on the implementation team.  Senior management must be involved and aware; middle managers are the ones who will agree to get things done.  If it is important enough to be ISO 9001 certified it’s important enough for these people to attend.

Frequency of Meetings

The standard is moot on frequency except to say that these reviews should be at ‘planned intervals.’  The external auditor will frown on reviews held less frequently than annually.  Some companies have these meetings annually.  In my last company we held them quarterly. 

There’s a lot of work in putting on an annual management review.  The meetings can take a couple of hours or more.  It’s hard to schedule required attendees into a long meeting.  It’s better to spread the work out.

Personally I don’t believe in separate QMS reviews.  Rather, I believe that management should meet at least monthly to review the entire business, and one component of this review should be a review of the QMS.  Review some parts of the QMS every month, and some less frequently.

For example, consider reviewing product quality, on time delivery to customers, and action items monthly, audits and preventive actions quarterly, customer feedback and external audit results annually, etc.  This approach assures that:

·         all requirements in the review process are met,

·         the work is spread out over time and there is less preparation for any one meeting,

·         the QMS is kept in focus by middle and senior management because they hear about it every month,

·         the review of the QMS is integrated into the business instead of being a separate activity

Management Review is one of the key components of ISO 9000.  Periodic review of the QMS is important.  After all, installing and supporting a QMS costs money.  It's important for management to assure that the QMS is effective.  What better way to assure that we're not wasting our money than to take a look at what we're getting for what we're spending.

For more information on ISO 9001 implementation see www.rosehillsystems.com
 

Gap Analysis

As your ISO 9001 implementation team gets under way, it is important to periodically lock back at your accomplishments to date, and look ahead to what remains to be accomplished.  Gap analysis fills this need. 

A gap analysis, as the title suggests, highlights the gaps between what is required and what has been accomplished.  Focusing on the gaps allows the team to focus on the remaining work and close the gaps.

In the early stages the gap analysis should be pretty high level.  Avoid losing sight of the forest for the trees.  I have created a short ten question gap analysis which will provide a 10,000 foot view of where the implementation stands.  You can find my simple gap analysis here  The questions are pretty high level, and not all inclusive.  Oh, and by the way, all the correct answers are yes.

At some point, as the team delves into the details of each element of the standard, a more comprehensive gap analysis will be needed.  You can create your own, use my Detailed Gap Analysis, or do something else.   Keep a record of these analyses.  They will later become evidence of audits of your system, and can be used to feed your corrective action system.

The detailed gap analysis is not all inclusive.  For that I suggest you hire a quality management consult prior to certification.  A consultant will do a detailed audit of your quality system which will show any gaps remaining.