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 .
A

ab001

#71
IMHO, even if you don't have an actual customer when you begin to design something for sell, you are envisioning one and trying to foresee what all that customer would want to see in your product. So, no, you don't have to have a "contract" in hand when designing a product but to some extent you have already got a "customer" in mind and figured out what those requirements will be, through market research as stated earlier. To further clarify, don't confuse contract with customer.:2cents:
Does someone who acts as the "Voice of the customer" count as a customer?
 
Elsmar Forum Sponsor
J

JaneB

#72
My question never changed. Your understanding of the comment that I posted for Randy changed.
Really? :confused: I think you're shifting ground. I'm OK with someone changing their mind in the course of a debate or with a debate bringing up a new avenue of discussion. But your 'question never changed'? :nope:

For the sake of accuracy, then.

Andy asked you very early on (in response to your post to Randy):
Are you suggesting that these requirements, 7.2 et al, only apply when there's a customer RFQ/PO, Jim?
Your reply:
Given the title of 7.2, "Customer-related processes", can you come to another conclusion?
I'll take that as a yes.
You went on to say:
Also consider that 7.3.2, "Design and development inputs", covers gathering requirements for design and development.
Why would you also need to use 7.2.1 to gather requirements for design and development when there is no customer yet?
And in response to considering whether 7.2.1 applies when gathering requirements for design and development when there is no customer yet:
That makes no sense.
7.2 is "customer related processes". How can you gather customer requirements when there is no customer? You can't!

7.3.1 covers the same ground. That is where you belong when there is no customer.
And yet again:
What I'm trying to get across is that if there is no customer involvement yet (and if it is wisdom for that to be the case is not the point) 7.2.1 does not apply.

In other words, 7.2.1 is not always a precursor to design. Trying to make it so goes beyond the scope of the standard.

Besides, as I said before, 7.3.2 covers the same ground. Actually it coves more, since it is not limited to customer input.
I think that was the first time when you started talking about 7.2.1 being a 'precursor' to design which you then mentioned again:
I'll not take this further so if you are still in disagreement, take your best shots.

I believe you are going beyond the requirements of the standard when you try to apply 7.2.1 as a precursor to design when there is not yet any customer involvement.
Obviously you feel differently, but I fail to see the "shall" to hang that thinking on.
Then you firmed up that position:
It is agreed that frequently or even most of the time that information gathered from 7.2.1 feeds 7.3.2. It is obvious, as they are even phrased similarly.

That does not establish, however, a REQUIREMENT to seek customer input before undertaking design.
I cannot resiist quoting Sidney's pithy response:
Really? A requirement from what source? ISO 9001? ISO 9004? Better business practices? Business 101?

An organization that would engage in a costly New Product Development process "in the vacuum", devoided of any input from potential customers, users and consumers should be awarded the Darwin award, in the corporate category.
'Show me the shall' is not the be-all and end-all of the position. (That's just very blinkered thinking, I believe.)

When I started this separate thread, I summarised my understanding of the question at hand. Now, if that was wrong, why didn't you say so? It was an excellent opportunity for you to clarify the question if you disagreed with my summary. To make this quite clear as I could, I explicitly invited this correction!
Zilch.
You didn't.

Given all that, I find it hard to accept your saying that your position never changed, and pointing toward my understanding (or lack thereof) instead. Presumably you also include in this supposed lack of understanding Andy, Sidney et al? Sorry, it won't wash. Nope and nope again. :nope:
 

atitheya

Quite Involved in Discussions
#75
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.
Agreed, I stand corrected.
 
Q

qualitydevil - 2010

#76
i think a design can be based on inputs... like..
1. A market data (customer survey)
2.Customer custom requirement
3. A dream project...(inhouse engineering to realease a new product -- ex Iphone)

The standard tells that we need to have a process,verfication,validation etc.thats what is necesary...
if ur developing for yourself then you are itself a customer..
with out a customer we can develop a product ...but maintain the relavent documents,process flow etc.
 
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