ISO Required Measures - What and How

[JRKH]

Hello all

We are going to be audited in the 1st week of October.
Failure is not an option.

Our measurables have been questioned as to weather they meet the requirements of the standard. Therefore I would like to lay these out to you to see if we have met the standard. I am aware that these areas can and should be improved upon, but have we met the requirements.

We are a company of about 65 people.

I apologize if this is a bit disjointed. but here goes......

Our objectives are stated in our quality policy:
To exceed customer expectations for Quality, Manufacturing Reliability, Delivery and Price…..to continually improve…..

We consider customer expectations to = customer requirements.
(See ISO-9000:2000 sec 3.1.2. Requirement = “Need or expectation”)

Quality Objectives shall be measurable. (5.4.1)
I have two definitions for measure
Measure = 1) Dimensions, quantity, or capacity as ascertained by comparison to a standard.
2) To estimate by evaluation or comparison
(American Heritage dictionary)
Therefore items such as customer perceptions can be based on an evaluation rather than direct quantitative data.

Measures
Quality = Product quality. Measured as customer returns

Delivery = Measured by percent orders late through production

Manufacturing reliability = is also measured by product quality.

Price = Evaluated by senior management by business level and interaction with customers.


Customer feedback used in Management Review (5.6.2)
President reports based on his evaluation of his direct daily observations and interaction with account managers and customers.
Q mgr and Production Mgr report on levels of customer returns and delivery performance.

Customer Communication (7.2.3)
Each customer is assigned an Account Manager who is responsible for all dealings with said customer, including fielding any customer complaints.

Customer Satisfaction (8.2.1)
In addition to Management Review reports and tracking customer returns, we have sent out customer evaluation surveys. Results are being tabulated for evaluation.

Analysis of Data (8.4.a)
Analysis of data shall provide information relating to
a) customer satisfaction (evaluation)
b) conformity to product requirements (quantitative data)
c) characteristics and trends of processes……. (quantitative data)
d) suppliers (data and evaluation)

Data on customer returns, production levels, and percent orders late are analyzed along with senior management’s observations of business levels and customer feedback. These are used to evaluate the effectiveness of the quality system and needs for change to improve.
Suppliers are monitored continously for price and delivery, formal evaluation of new suppliers is required and re-evaluation of existing suppliers is based on their perfomance.

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

OK folks lets have it.

Have I covered the requirements?

James

 

[db]

JAMES!!!!!!!!

Good to hear from you again old friend! I do believe it has been a while (unless I've just overlooked your recent postings).

ISO 9K2K doesn't give many requirements for quality objectives (I'm assuming we're talking 5.4.1 here). There does seem to be one point that you are not addressing in your post. "...including those needed to meet requirements for product..." You kind of touch on them, however, I don't think those requirements (dimensions, prices, delivery, etc) are addressed in 5.4.1, but in the 7.... stuff, so I think you are okay in that area. Other than that, it seems to me to be compliant. You've tied it in to other areas, which show the objectives are real, and they seem to support the quality policy. Based just on the information provided, it appears to be conforming.

 

[Marc]

Don't forget to consider:

https://elsmar.com/elsmarqualityforum/threads/6715/

The threshold issue - what is a customer complaint - will be an issue unless account managers track customer complaints. Having spoken to several registrars, the threashold of customer complaints = customer returns will not fly. Bottom line is they all cite continuous improvement.

 

[howste]

Our objectives are stated in our quality policy:
To exceed customer expectations for Quality, Manufacturing Reliability, Delivery and Price…..to continually improve…..

We consider customer expectations to = customer requirements.
(See ISO-9000:2000 sec 3.1.2. Requirement = “Need or expectation”)..... Etc.

OK, you asked for opinions. We all know that opinions are like armpits - everybody has two of them and most of them stink...

1) I have one question: do your objectives have specific goals, or are they just measured (tracked ). ISO 9000 (several places) and ISO 9001 6.2.2 talk specifically about "achievement" of the quality objectives. I believe that to achieve them you would need to have targets.

2) I'm not a big fan of using "exceed" customer expectations. I suppose it's OK to exceed Cpk expectations, but do you also plan to exceed their DPPM expectations? Or exceed tolerances? Maybe it's a bit nitpicky, but it always bothers me.

Overall if the measurements you've chosen are suitable for your business, and you have data showing that you are headed in the right direction, you're probably in the ballpark.

BTW, here's my driving policy: "To exceed the requirements of the law pertaining to the speed limit whenever possible."

 

[Randy]

Where have you been? Hopefully I haven't been ignoring you.

They're your objectives, so you define how you meet and measure them. Is your method effective? Best guess based on objective evidence.

Have you adequately defined what the "customer expectations" are? Can you measure these expectations? Are you measuring these expectations? If you rely solely on customer complaints and you have none, have you actually met (exceeded) expectations? Lots of folks do this, and lots of folks still believe in the Easter Bunny too.

Develop your data, verify it, show its worth, show its validity.

Easy for me to say, right?

 

[htanaka]

I have two definitions for measure
Measure = 1) Dimensions, quantity, or capacity as ascertained by comparison to a standard.
2) To estimate by evaluation or comparison

No need to use dictionaries, JRKH, because ISO/TC176 has an official definition of 'measure' in the ISO 9000 Introduction and Support Package. It is

- ascertain or determine the spatial magnitude or quantity of (something)
- ascertain or determine (a spatial magnitude or quantity) by the application of some object of known size or capacity or by comparison with some fixed unit

 

[edward.gibbs]

This is a favorite bugaboo of mine.

Coming from a training background, when I read the requirement for measurable quality objectives I something most people don't.

In the training business we have a precise meaning for a measurable objective - you need to describe what is being done, under what conditions, and to what standard. A measurable training objective reads something like "Given a widget and widget operating manual, in an installed environment, the student will apply power and initialize the widget to operating state 1 in accordance with published procedures with no safety violations."

When I read the 9001:2000 standard, I can't help but think that the authors were modeling the Quality Objectives requirement on the type of objectives used in training.

So a good Quality Objective in my mind should describe what is being measured, under what conditions, and to what standard.

Sounds simple - unfortunately it is not. Quality Objectives need to support the Quality Policy, and the Quality Policy ideally should be related to customer satisfaction. Measuring customer satisfaction is not a science, it is an art.

The BSI Training on Customer Satisfaction measurement spends a lot of time talking about what is NOT a good measure of customer satisfaction, and has precious few examples of what is a good measure. The bottom line is that you need a mix of qualitative and quantitative measures. On-time delivery is a good thing to track, but be prepared to explain how you know it is important to your customers. So are customer returns and complaints, but the conventional wisdom is that 80% or more of customers who are unhappy or have a problem never bother to complain, they just go elsewhere next time. You also need to conduct surveys, though surveys alone are not enough. Cost, features, etc. can all be measures as well.

Once you define (and can justify) what it takes to satisfy YOUR customers, you then need to somehow plug all of those inputs into an algorithm that gives you a number that represents Customer Satisfaction.

Our registrar pretty much beat us about the head and shoulders with observations for two surveillance audits until we were finally able to show him a single number that tracked Customer Satisfaction.

The number is based on our definition of Customer Satisfaction, as defined by the things we choose to track and the algorithm we use to derive the number - but until we could show him a number that we were tracking he kept telling us that we were measuring but not tracking Customer Satisfaction.

Once you define what measures you will use to track Customer Satisfaction, writing the objectives becomes easy. We will keep customer returns below X%. We will acheive X% total satisfaction on customer surveys. We will achieve X% on-time delivery. When you plug all those percentages into your algorithm they should produce an overall customer satisfaction number that supports a number in your Quality Policy. Once you have that, you truly have a measurable set of objectives and policy.

Your mileage may, of course, vary. As I said I come from a background where measurable objectives are nothing new and I have a particular preference for really clearly stated objectives and measures. And your registrar may have an entirely different take than ours did.

Determine what is important to your customers, decide how to measure those characteristics, and set measurable goals for them. Track your achievement of those goals, and continuously improve (raise the bar). If you do that you will have happy customers and a happy registrar.

Ed Gibbs

 

[howste]

Before someone jumps in here and says "but the standard doesn't require..." I want to say thanks for a well thought-out post. It's focuses on the spirit of the requirements, not just meeting the bare minimums that are required.

 

[db]

but the standard doesn't require...

Sorry, just had to do that!