Design Inputs not Quantitative - ISO 9001 Clause 7.3.2 requirement

juliov · Mar 5, 2008

Attention quality pros, review and comment on the following question/concern:

I was auditing "Design and development" and while reviewing ISO 9k2k, requirement 7.3.2 (Design and development inputs) at the engineering function, I observed that the inputs were qualitative and not quantitative, in other words the requirements in the document stated inputs such as: market need, build a collator, build a pneumatic application tool, design, etc. I did not see any quantitative specs such as numbers and tolerances, specifications addressing with a number a certaing customer need to be met.

What can you comment about the above. Can companies doing design enter qualitative inputs, or is it up to the customer, " that's how we do things here" about compliance? my idea is that systems must improve, yet, I don't want to over react and p---off the engineering manager because of the lack of quantitative inputs.
Thanks,

Sidney Vianna · Mar 5, 2008

Irrespective of what ISO 9001 states and how one interprets the design input requirement, you know your engineering process is dysfunctional.

Reminds me of the famous cartoon:

juliov · Mar 5, 2008

can you expand a bit further on your comment please, it is of interest to me to get objective opinions based on fact and experience about my question.

But, 7.3.2 a, states: functional and performance requirements, (the req does not state that quantitative specs are to be defined) comment?

Randy · Mar 5, 2008

I'm hard pressed trying to find where "Quantitative" is a requirement.

Stijloor · Mar 5, 2008

Sidney Vianna said:
Irrespective of what ISO 9001 states and how one interprets the design input requirement, you know your engineering process is dysfunctional.

Reminds me of the famous cartoon:

I was unable to open the link. Is it still alive?

Stijloor.

Mark R. · Mar 5, 2008

I double-checked for my own sanity, but the word "quantitative" isn't in the standard.

Mark

Stijloor · Mar 5, 2008

juliov said:
Attention quality pros, review and comment on the following question/concern:

I was auditing "Design and development" and while reviewing ISO 9k2k, requirement 7.3.2 (Design and development inputs) at the engineering function, I observed that the inputs were qualitative and not quantitative, in other words the requirements in the document stated inputs such as: market need, build a collator, build a pneumatic application tool, design, etc. I did not see any quantitative specs such as numbers and tolerances, specifications addressing with a number a certaing customer need to be met.

What can you comment about the above. Can companies doing design enter qualitative inputs, or is it up to the customer, " that's how we do things here" about compliance? my idea is that systems must improve, yet, I don't want to over react and p---off the engineering manager because of the lack of quantitative inputs.
Thanks,

Juliov,

Some organizations use the Quality Function Deployment (QFD) process to convert the Voice of the Customer (VOC) which in many cases consist of qualitative data into clearly defined design goals (quantitative data).

When conducting an audit, you should look for this. The purpose of design review is to verify that the design output meets the design input requirements. Even though the ISO 9001:2000 standard does not use this (qualitative-quantitative) terminology, design and development activities are much easier to monitor and track (audit) if the data is available in a more quantitative format.

But whatever type of data is available is what we should use. Auditing is many times not what we like to see, but what the company decides to use. And if it meets the intent and purpose of the D&D process...what can we say?

Stijloor.

Helmut Jilling · Mar 5, 2008

juliov said:
Attention quality pros, review and comment on the following question/concern:

I was auditing "Design and development" and while reviewing ISO 9k2k, requirement 7.3.2 (Design and development inputs) at the engineering function, I observed that the inputs were qualitative and not quantitative, in other words the requirements in the document stated inputs such as: market need, build a collator, build a pneumatic application tool, design, etc. I did not see any quantitative specs such as numbers and tolerances, specifications addressing with a number a certaing customer need to be met.

What can you comment about the above. Can companies doing design enter qualitative inputs, or is it up to the customer, " that's how we do things here" about compliance? my idea is that systems must improve, yet, I don't want to over react and p---off the engineering manager because of the lack of quantitative inputs.
Thanks,

I'm with Sidney. While the standard does not require the inputs to specifically be quantitative, and I would be willing to accept beneficial qualitative inputs, the examples you cite are silly...The sound like something they tossed together for ISO audits. Not meaningful, useful and effective inputs.

It could be an NC, at minimum would be an audit trail leading to an OFI or NC. Does not seem like they get it. I would explore their understanding and intention.

juliov · Mar 6, 2008

Randy, I was referring that the inputs to 7.3.2 a, this company use are qualitative. I know that there is no requirement asking for "Quantitative" inputs, however, inputs in a quantitative form could be best for a design that meets customer needs.

Helmut and Stijloor comments above address this topic and it appears that while auditing 7.3.2 any form that best suits the organization should be fine and no NCs could be issued, as long as the company "says what they do, and do what they say"

It appears that some companies also don't know much about D&D, other than design by experience the correct methods are not used. Add hoc?

juliov · Mar 6, 2008

Hello Mark, see my reply to Randy addressing your same concern. Thanks.

Design Inputs not Quantitative - ISO 9001 Clause 7.3.2 requirement

juliov

Sidney Vianna

Post Responsibly

juliov

Randy

Stijloor

Mark R.

Stijloor

Helmut Jilling

Auditor / Consultant

juliov

juliov

Similar threads