Can not do design without a Customer?

In terms of ISO 9001 7.2.1.

  • It can go either way

    Votes: 0 0.0%

  • Total voters
    11
  • Poll closed .

Helmut Jilling

Auditor / Consultant
#61
Are we missing something???



Having said that, organizations will need to

1. Determine requirements related to the product (7.2.1)

and, if the organization is involved in design too, then,

2. Determine Inputs relating to product reqruirements (7.3.2)

which will include some/all of the customer requirements (7.2.1 a) (maybe less) and more as determined by the organization.

3. Customer requirements (7.2.1 a) may include not only product specifications but also delivery and post delivery requirements and these may not be part of the design requirements. Hence 7.3.2 and 7.2.1 can not be the same.

Why are we mixing the two clauses so clearly defined?

Please correct me if I am wrong.
I am not sure that we are "mixing" the two clauses. However, they are linked, as your own post demonstrates (bullet point #2 and 3). Products that are designed without thought to what customers will want, generally do not succeed very well, as I described in an earlier post.

It is permitted to design a product without a direct customer involved. That was the original question. We are drifting afield.
 
Elsmar Forum Sponsor

Big Jim

Super Moderator
#62
Lest we forget, this whole topic started when Randy posted that you can't have an effective 7.3 program unless you have an effective 7.2.1 contract review program and I questioned that judgement.

I only meant to point out that customer input does not always precede design as it sounded like he meant.

Had I realized that this much controversy would have ensued, I would not have raised the point.

I wonder, though, if some good has come out of all the furr that has flown.
 

Stijloor

Staff member
Super Moderator
#64
Lest we forget, this whole topic started when Randy posted that you can't have an effective 7.3 program unless you have an effective 7.2.1 contract review program and I questioned that judgement.

I only meant to point out that customer input does not always precede design as it sounded like he meant.

Had I realized that this much controversy would have ensued, I would not have raised the point.

I wonder, though, if some good has come out of all the furr that has flown.
Jim,

I agree with Brad. Glad you raised the issue and participated in the discussion.
Nothing wrong with challenging standards and their (common) interpretations. :applause:

Stijloor.
 
J

JaneB

#65
So, Jane, would you write a nonconformance if an auditee was developing a product, using element 7.3 for design and development, but not gathering customer input? Like I asked Sydney, "show me the shall". It just isn't there.
Hmm. As you say, there's no limit to stupidity, but I'd argue that anyone with certification or going for it and who was making a good attempt at trying to understand and apply 9001 (and preferably 9004 as well) and get the best out of it wouldn't be so stupid. After all, if they're certified/going for it, they've been going for a while and have developed a business!

I would also point to 7.3.2 d) and say I'd consider that including customer requirements would normally form part of those other requirements.

My opinion is that 7.2 and 7.3 are closely interlinked, and that in the early stages of 'design' (or creation), it can often be an iterative process, with parts repeated, refined, etc etc. BUT I'm not arguing this from the typical manufacturing process engineer point of view, to whom this might sound like anathema. Such isn't my field or my specialty.

Whereas I know that in many consulting/service industries, this is often the case. And then there's other approaches such as prototyping or 'iterative design' in some fields of IT, where one may 'build' or mock-up something, test it out with a tame customer or three and see how they respond to gain an idea of whether it's worth pursuing commercially or not... at which point of course you revisit 7.2.1 more closely... And it's out of this knowledge and experiences that I disagreed with you that you 'must' have a customer before you can 'do 7.2.1'.

Returning to your query: 'Would I write a nonconformance' in a case such as you cite? Hypothetical questions like this one are pretty hard to answer, as it would depend upon the particular situation.

I doubt it, because they aren't selling/delivering it yet. I'm assuming still in the design/creation/research/whatever phase. Such a phase can be pretty fluid for quite a while (as outlined above); I think that's OK and in the nature of the creation/design activity and seriously doubt there's value in taking such an approach.

You're now asking a different question: is 7.2.1 required by 9001 before you can do design? Which is not the same question as the original one is it?

BTW, I'm more than happy as are others to debate an interesting topic such as this one, and am glad you asked the question. I'd hate to see anyone refrain from stating a point or raising a question for fear of causing a fuss. furore. And I think any professional should expect to state a professional point or opinion and debate it (politely of course). Why on earth not? On such debates is the Cove based.
 

Big Jim

Super Moderator
#66
Hmm. As you say, there's no limit to stupidity, but I'd argue that anyone with certification or going for it and who was making a good attempt at trying to understand and apply 9001 (and preferably 9004 as well) and get the best out of it wouldn't be so stupid. After all, if they're certified/going for it, they've been going for a while and have developed a business!

I would also point to 7.3.2 d) and say I'd consider that including customer requirements would normally form part of those other requirements.

My opinion is that 7.2 and 7.3 are closely interlinked, and that in the early stages of 'design' (or creation), it can often be an iterative process, with parts repeated, refined, etc etc. BUT I'm not arguing this from the typical manufacturing process engineer point of view, to whom this might sound like anathema. Such isn't my field or my specialty.

Whereas I know that in many consulting/service industries, this is often the case. And then there's other approaches such as prototyping or 'iterative design' in some fields of IT, where one may 'build' or mock-up something, test it out with a tame customer or three and see how they respond to gain an idea of whether it's worth pursuing commercially or not... at which point of course you revisit 7.2.1 more closely... And it's out of this knowledge and experiences that I disagreed with you that you 'must' have a customer before you can 'do 7.2.1'.

Returning to your query: 'Would I write a nonconformance' in a case such as you cite? Hypothetical questions like this one are pretty hard to answer, as it would depend upon the particular situation.

I doubt it, because they aren't selling/delivering it yet. I'm assuming still in the design/creation/research/whatever phase. Such a phase can be pretty fluid for quite a while (as outlined above); I think that's OK and in the nature of the creation/design activity and seriously doubt there's value in taking such an approach.

You're now asking a different question: is 7.2.1 required by 9001 before you can do design? Which is not the same question as the original one is it?

BTW, I'm more than happy as are others to debate an interesting topic such as this one, and am glad you asked the question. I'd hate to see anyone refrain from stating a point or raising a question for fear of causing a fuss. furore. And I think any professional should expect to state a professional point or opinion and debate it (politely of course). Why on earth not? On such debates is the Cove based.
Jane,

As I suspected all along, we are more in agreement than not.

My question never changed. Your understanding of the comment that I posted for Randy changed.

Either way, there is simply no shall. Try as you may it just isn't there.
 

somashekar

Staff member
Super Moderator
#69
I can see people if not customers and I can conceive a design to target some of the people who in turn are the customers (potential). I can target a people group and make survey and input customer requirements. I can do a design very well without a customer. I only need an idea which can change people life for the better. Making people your customer is the next natural process.
 
D

David Hartman

#70
Many market needs are obvious based on documented needs and/or common sense. This is the "if we build it, they will come" marketing philosophy.

Other market needs are met in backdoor fashion when an inventor creates something that he or she uniquely realizes how to do, often purely because they enjoy creating things and overcoming technical challenges, and it turns out that he or she isn't the only person that wants the invention. This is the intuitive path.

Some examples:

1. A pharma company, as part of its broad mega$$$ search for biomedical action of complex natural organics, discovers a substance that achieves an improved level of effectiveness in treatment of a known disease...so it productizes it. There's no need to consult with potential users and disease sufferers, at the point of the initial productization decision, as to whether they're interested in a more effective treatment option than they currently have.

2. A teenager codes up a functionality that he would like to have exist, because it doesn't and he can. It turns out that a bunch of his buddies like it too. Then it turns out that 100 million other people want it as well. That's basically the story of DOS, Windows, Lotus 1-2-3, online "bulletin board" technology, Facebook, Twitter, Napster, etc.

3. The first personal computers were all hobby or hobby-business efforts that turned into businesses, and eventually a rather large industry. Often design was driven, not by what customers would want, but what parts the designers could afford to buy, or existed to be bought, or could finagle someone into co-developing for them.

4. Lockheed is one example of a rather large company that for decades maintained an expensive sub-operation (in their case, the so-called Skunk Works) tasked specifically with building things that they could figure out how to do, and would have neat new capabilities. No customers involved until they had something that flew and was "interesting".

None of these is the norm, of course--the pharma example is less common than it was in the '70s, say, because a lot of the world has been explored and because molecular synthesation has proceeded to the point that design now more frequently is marketing driven, i.e. model and test all the possible molecules that have these characteristics, similarities and interactions, and meet these criteria--but they've all been historically important.
In all of your examples a known or perceived need was identified and then the design effort began to meet that need. Whether I personally am the customer, or am toying with the possibility of eventually selling my product to others I have to give consideration to the needs that are to be met (customer requirements - mine/others), any applicable legalities (copyright, patent, federal/state regs, etc.), and company needs (additional knowledge, resources, licenses, etc.). In all of your examples all of these steps would have been applicable, either as inputs to the design process or considerations addressed prior to production.
 
Thread starter Similar threads Forum Replies Date
K Determining Effect of Failure without a DFMEA (Design FMEA) FMEA and Control Plans 1
N 510k without DHF (Design History File) that we bought a 3 years ago US Food and Drug Administration (FDA) 4
G AS9100 Design Contract Issue - Contractor without AS9100 Quality System AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 8
M Reducing both Detection and Occurance in a Design FMEA WITHOUT a Design Change FMEA and Control Plans 8
DuncanGibbons Section 8.3 relevant for design organisations AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 2
P DFMEA - Machinery Design Best Practices FMEA and Control Plans 0
R Is a FAIR required on parts that we design? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5
U API Spec Q1 - 5.6.1.2 C (3) - Design software Oil and Gas Industry Standards and Regulations 3
N Example for design and development planning,input,output,review,verification,validation and transfer Misc. Quality Assurance and Business Systems Related Topics 4
A 8.6 Release of products and services, 8.3 Design and development - evidence required ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
C Stress / Challenge Conditions for Design Verification Testing to Reduce Sample Size 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 11
J Significant change related to design and intended use EU Medical Device Regulations 3
S Traceability of requirements to design and risk Design and Development of Products and Processes 3
U NOC - What is considered a "design change" EU Medical Device Regulations 5
Q PPT used as Design Review ISO 13485:2016 - Medical Device Quality Management Systems 3
D Design Verification Sample Size vs Repeats Statistical Analysis Tools, Techniques and SPC 9
A Design and development procedure for API Spec Q2 Oil and Gas Industry Standards and Regulations 6
D Design controls - Inputs, outputs, V&V, DHF, DMR ISO 13485:2016 - Medical Device Quality Management Systems 10
LostLouie Manufacturer divorced from Design process, is he justified in design process deficiencies? ISO 13485:2016 - Medical Device Quality Management Systems 9
R DFA & DFM - Examples for Design for assembly and design for manufacturability Lean in Manufacturing and Service Industries 2
D Using Laboratory Notebooks in R&D and Design and Development ISO 13485:2016 - Medical Device Quality Management Systems 3
D ISO 13485 - 7.3.6 Design and development verification - Do most folks create a separate SOP? ISO 13485:2016 - Medical Device Quality Management Systems 6
K Joint approval between OEM and Manufacturer on Design Documents ISO 13485:2016 - Medical Device Quality Management Systems 4
M API 4F/7K/8C Design Package Validation Oil and Gas Industry Standards and Regulations 2
A Design History File - Not ready to share the design drawings or Bill of Material US Food and Drug Administration (FDA) 2
W Need for current design or process control FMEA and Control Plans 2
A What is the difference between Design Process, Process Design and Design Control? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
D Test summary report example for design validation wanted - ISO 13485 ISO 13485:2016 - Medical Device Quality Management Systems 1
B Why the Greek god Hephaestus should have done a design FMEA (DFMEA) on his giant robot APQP and PPAP 1
S Documenting Design Verification Test Results (ISO 9001) Design and Development of Products and Processes 1
DuncanGibbons Understanding the applicability of Design of Experiments to the IQ OQ PQ qualification approach Qualification and Validation (including 21 CFR Part 11) 5
S Requirement to Conduct New Shelf-life Testing? (re-do testing for design change) EU Medical Device Regulations 3
A Sample Agreement available for Outsourcing Medical Device Design activity? ISO 13485:2016 - Medical Device Quality Management Systems 1
DuncanGibbons How is the arrangement between Design and Production organisation envisaged? EASA and JAA Aviation Standards and Requirements 4
L Design & Development of a SERVICE Service Industry Specific Topics 13
C Documentation for items used for Design Verification 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
P Design verification driven by new equipment. How is this different than process validation? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
A AS9102B - 3.6 Design Characteristics and form 3 AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 3
P Design FMEA - Detection Rating criteria ISO 14971 - Medical Device Risk Management 3
U Medical Device Design finalization testing ISO 13485:2016 - Medical Device Quality Management Systems 2
S MDR Delay - MDD design Change? (before new MDR DOA) EU Medical Device Regulations 8
J Iterative design and production for custom made products ISO 13485:2016 - Medical Device Quality Management Systems 3
T Design Input detail & specificity ISO 13485:2016 - Medical Device Quality Management Systems 4
J Design file for pre-existing products - Inputs and Outputs ISO 13485:2016 - Medical Device Quality Management Systems 5
D Design Transfer Template capturing Customer Specific Requirements Other Medical Device Related Standards 3
T Design Control Procedures later in the Development Process ISO 13485:2016 - Medical Device Quality Management Systems 6
M Looking for a Presentation on Design for Excellence (DfX) Manufacturing and Related Processes 2
K Old medical devices -> 7.3.7. Design and development validation ISO 13485:2016 - Medical Device Quality Management Systems 1
R Design and Manufacture Guidelines for Surface Mount Technology Misc. Quality Assurance and Business Systems Related Topics 9
optomist1 Design Exclusion, but now we might have an outsourced Product Design ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 5

Similar threads

Top Bottom