Should every Management System include Design?

[Jim Wynne]

Not changing our management systems to include service design processes until explicitly required by the system standards will put many of us 15 years behind the leaders and perhaps even more companies out of business.

John

BTW, I still see no response to my repeated reminder that our systems' supplier selection criteria invariably emphasize the importance of service quality.

The ISO 9001 requirements for design are intended to address design of products, which is why exclusion is allowed for companies such as manufacturing job shops that don't design the products they manufacture.

It's true, but trivially so, that some form of design is inherent in all business enterprises, but I think that your suggestion that companies that rationally exclude the design requirements of the standard are deficient and "behind the leaders" assumes that these companies don't conscientiously design processes. ISO 9001, as it stands, requires it. It requires it in a different sense than the requirements for the design of products, so to add the design requirements of the standard is specious and redundant.

 

[John Broomfield]

John,

I noticed that you are also a certified Lead Assessor. As an Auditor, how hard do you "push" your audit clients with respect to Clause 7.3 Design and Development? A bias toward "design" can impact the audit.

Stijloor.

Stijloor,

As I have observed here, many auditors feel that have to wait for the standards to catch up. Management systems should not wait for the standards to explicitly specify design of the whole product.

Third party auditors accept exclusions of clause 7.3 when the evidence shows that the main part of the product, as stated in the certification's scope, is designed by the customer.

QA professionals call this the intended product (as if the service part of the product is unintended) and this tends to limit interpretation of the standard to the main product (instead of simply not addressing unintended by-products as we have ISO 14001 for those).

I am not a third party auditor. This frees me to simply ask clients "what other parts of the product are essential for your success?". Often I am told "the standard of our service" I then ask "who is responsible for service design?". I am seeking the subject matter expert as process owner.

These two questions alone may get my clients to think and act differently about design. This part of their product would then be mentioned in the scope of their system. It may not be mentioned in the certification scope.

I suppose third party auditors could do something similar after examining the auditee's supplier selection criteria. They could say "I see that you consider service quality to be a key determinant in selecting your suppliers, how do you measure this?" Then the third party auditor could ask "do you suppose that your customers also consider service to be an important part of your product?".

Or the third party auditor could ask "Even though you deliver widgets, customer complaints seem to center around service issues. What are you doing to improve the design or execution of your services as this seems to be an important part of your product?".

Getting client's to think about continually improving the parts of their product that differentiate them from their competitors is all that we are talking about.

John

 

[howste]

I am not a third party auditor. This frees me to simply ask clients "what other parts of the product are essential for your success?". Often I am told "the standard of our service"...

What percentage of the time do they come up with this on their own vs. being suggested by you?

 

[JaneB]

The ISO 9001 requirements for design are intended to address design of products, which is why exclusion is allowed for companies such as manufacturing job shops that don't design the products they manufacture.

I assume (or hope?) that in emphasising products you are taking it to mean the 'product and/or service' to be delivered? Because service businesses deliver services, some of which may, some of which may not, have something 'physical' delivered.

It's true, but trivially so, that some form of design is inherent in all business enterprises, but I think that your suggestion that companies that rationally exclude the design requirements of the standard are deficient and "behind the leaders" assumes that these companies don't conscientiously design processes. ISO 9001, as it stands, requires it. It requires it in a different sense than the requirements for the design of products, so to add the design requirements of the standard is specious and redundant.

Agree with you here.

 

[John Broomfield]

What percentage of the time do they come up with this on their own vs. being suggested by you?

Howste,

It depends. If the client is in the transaction business then it is low. If they are in the business of building customer loyalty it is much higher.

I must admit that I sometimes have to clarify my question by explaining that their product invariably includes some amount of service.

It leads to some interesting discussions. Businesses that realize they need to build customer loyalty get serious about their service specifications.

John

 

[somashekar]

Howste,

It depends. If the client is in the transaction business then it is low. If they are in the business of building customer loyalty it is much higher.

I must admit that I sometimes have to clarify my question by explaining that their product invariably includes some amount of service.

It leads to some interesting discussions. Businesses that realize they need to build customer loyalty get serious about their service specifications.

John

I must admit that I sometimes have to clarify my question by explaining that their product invariably includes some amount of service.

I am sure that comes added though not necessarly with the design and development inputs.

7.2.1 Determination of requirements related to the product
The organization shall determine
a) requirements specified by the customer, (primary and gets into design input) including the requirements for delivery and post-delivery activities, (secondary and need not be a design input. Serviceability and maintainability gets into the design input, however servicing and maintenance activities can be out sourced or handled as a seperate department and process)
b) requirements not stated by the customer but necessary for specified or intended use, where known, (Primary and gets into the desing input)
c) statutory and regulatory requirements applicable to the product, (Primary and gets into the design input) and
d) any additional requirements considered necessary by the organization. (May be a design input OR may not be ... )
NOTE Post-delivery activities include, for example, actions under warranty provisions, contractual obligations such as maintenance services, and supplementary services such as recycling or final disposal.

(The supplementry here perhaps some falls into design input like marking on product and some falls into planning and providing other services of disposal based on country specific regulations. Again these are secondary and fall into a seperate process establishment, and are directly about products which can be touched and felt).

Lot many service related aspects do come along as we go about the customer satisfaction process seriously, and these are post design events, though some of them can be into design inputs based upon lessons learnt.

 

[John Broomfield]

I am sure that comes added though not necessarly with the design and development inputs.
(The supplementry here perhaps some falls into design input like marking on product and some falls into planning and providing other services of disposal based on country specific regulations. Again these are secondary and fall into a seperate process establishment, and are directly about products which can be touched and felt).

Lot many service related aspects do come along as we go about the customer satisfaction process seriously, and these are post design events, though some of them can be into design inputs based upon lessons learnt.

Somashekar,

Your quote addresses customer requirements. With design I am talking about customer needs (as yet undefined requirements).

Product design translates customer needs into requirements (essential characteristics) for the product.

Therefore, an organization concerned about building customer loyalty will maintain and tailor its service specifications.

We cannot rely on customers to inform us of all of their requirements. Design can fill the gap between hidden needs and stated requirements.

The selling process, for example, often learns of needs that are not specified as requirements by the customer. Understanding those needs and translating them into requirements along with (or instead of) the requirements specified by the customer can add real value for customers and the organizations that serve them. Competitors that fail to consider the hidden needs do not win the sale when up against such standards of service.

My earlier example was the O&M contractor proposing more predictive maintenance (with service specifications) when the customer had specified preventive maintenance.

Here I am referring to clauses 4.1 and 7.3. 7.2.1 and 7.2.2 are both too late.

John

 

[howste]

Here I am referring to clauses 4.1 and 7.3. 7.2.1 and 7.2.2 are both too late.

John

Are you suggesting that product design takes place before determining what customers need? How can this possibly make sense? How can you say 7.2.1 is too late? It must occur before 7.3!

We cannot rely on customers to inform us of all of their requirements. Design can fill the gap between hidden needs and stated requirements.

If there are additional customer needs, then they are already addressed in 7.2.1b. The gap of "hidden needs" is already filled in 7.2, and doesn't need to be rewritten into clause 7.3:

The organization shall determine... b) requirements not stated by the customer but necessary for specified or intended use, where known

 

[John Broomfield]

All,

Requirements are defined needs. I am referring to undefined needs.

Undefined needs are not yet requirements.

Customer needs and customer requirements are essential design inputs (hence 7.3.2).

The design process turns customer needs in product requirements.

Hence 7.3 (which handles customer needs) precedes 7.2.1 and 7.2.1 (which handle customer requirements which may include the requirement for design but unlikely if the customer supplies the design).

Differentiating between needs and requirements is essential otherwise company's just do what is in the contract whether it is right or worng.

This also helps explain why companies that conform to the contract requirements completely can still end up with dissatisfied customers.

John

 

[Jim Wynne]

Requirements are defined needs. I am referring to undefined needs.

Undefined needs are not yet requirements.

How can anyone recognize a "need" that's not defined? What does one of those look like? You're trying to differentiate between two terms that essentially mean the same thing. A customer might express, in general terms, what she needs (requires) and a designer translates those requirements into technical specifications--explicit terms that describe how to achieve what the customer requires.

Customer needs and customer requirements are essential design inputs (hence 7.3.2).

The design process turns customer needs in product requirements.

No, as I said above, the design process turns customer needs/requirements into specifications, which may also be described as product requirements. There are customer requirements and product requirements.

Hence 7.3 (which handles customer needs) precedes 7.2.1 and 7.2.1 (which handle customer requirements which may include the requirement for design but unlikely if the customer supplies the design).

Differentiating between needs and requirements is essential otherwise company's just do what is in the contract whether it is right or worng.

Differentiating between "needs" and "requirements" only confuses what should be a simple concept.

This also helps explain why companies that conform to the contract requirements completely can still end up with dissatisfied customers.

This can happen only if the customer does an inadequate job of explaining his requirements. This happens sometimes despite the best efforts of people to understand the requirements. There's an old saying that describes a customer who finds himself in possession of a product that wasn't what he thought he was going to get: "Don't give me what I asked for--give me what I need!"

I'm not sure what any of this has to do with the topic at hand, which is whether an organization that doesn't do product design should exclude product design requirements from its QMS scope. Note that I said product design, because that's what the standard is referring to. I can't exclude process design (and control) because if I do, there's no way that I can comply with the standard. The contention that exclusion of product design requirements means that process design requirements will be neglected fails on a very basic level.