Скачать презентацию Lecture 9 Quality Function Deployment QFD a method Скачать презентацию Lecture 9 Quality Function Deployment QFD a method

1195a6cbaec74d1d67f68f0631d203ab.ppt

  • Количество слайдов: 29

Lecture 9 Quality Function Deployment (QFD) a method for structured product planning & development Lecture 9 Quality Function Deployment (QFD) a method for structured product planning & development Responding to the voice of the customer 11

Grading criteria for Objectives Trees • Well-organized presentation that is easy to read and Grading criteria for Objectives Trees • Well-organized presentation that is easy to read and not jumbled • Content provides evidence of team collaboration and substantial thought • There are many different objectives listed, more than just the few discussed in class • The objectives clearly define all elements of the opportunity statement with wording that is concise and accurate • Objectives are grouped together in a fashion that makes sense and with a hierarchy that goes from top level to component level • Objectives grouped under a heading clearly belong there • Examining the objectives tree provides a concise description and summary of the design objectives 22

QFD is built around a “House of Quality” 33 QFD is built around a “House of Quality” 33

Quality Function Deployment definitions 44 Quality Function Deployment definitions 44

Quality Function Deployment (QFD is part of a “Six Sigma Process”) The objectives The Quality Function Deployment (QFD is part of a “Six Sigma Process”) The objectives The beginning of design We need to see how our proposed design solutions address customer expectations 55

QFD is structured to have 6 design steps 1) Identify the customer(s), users, stakeholders QFD is structured to have 6 design steps 1) Identify the customer(s), users, stakeholders … 2) List customer/client requirements (needs & wants) • Things like “Works well, ” “lasts a long time, ” “looks good, ” “incorporates the latest technology” • Most of these appear in the objectives tree • Include functional requirements (change orbit), spatial constraints (operate in MEO), appearance, time requirements (responsive), cost (affordable), manufacturing and assembly, performance, product standards, codes of practice (meets ISO 3102), safety, environmental 3) Prioritize customer requirements – use pairwise comparisons • Question - To whom is the requirement important? • Question - What measurement tells us if our solutions satisfy requirements? • Which requirements are MUSTS? Which are NICE? 66

QDD overview continued 4) Benchmark the Competition • What already exists that is sort QDD overview continued 4) Benchmark the Competition • What already exists that is sort of like our design objective? • Compare these existing products with our requirements – is there a feature we can use or copy? 5) Translate customer requirements/needs into measurable engineering requirements (called design specifications) 6) Set engineering targets – like “time=12 hours” or “cost less than $250 M” • You may specify range of values, but this is dangerous • You may specify that a value should be “as large” or “as small as possible” like weight should be less than 5 lbs. Most requirements will be covered by the objectives tree, but some may be added 77

QFD output from one step becomes input for the next 88 QFD output from one step becomes input for the next 88

QFD is structured to go from beginning to the end how long you use QFD is structured to go from beginning to the end how long you use it is up to you Figure courtesy of Thiokol 99

Systems based QFD elements and value has to be determined by the team • Systems based QFD elements and value has to be determined by the team • Typical activities • Customer surveys • Brainstorming • Affinity exercises • Objectives tree diagrams • House of Quality • Benchmarking – what do our competitors do? • What is it used for? • Prioritizing activities • Improving quality and reliability • Engineering breakthrough product development • Improving communication • Reducing time to market • Benefits • Focused on customer • • • requirements Uses competitive information Prioritizes resources Identifies important issues and problems Reduced implementation time Bases decisions on consensus Documents activities and decisions – a living document 10 10

Matrix selection methods • Matrix displays always show data in two dimensions A B Matrix selection methods • Matrix displays always show data in two dimensions A B C D 1 2 3 4 5 6 7 8 11 11

Modular space example Tech response? Engineering characteristics? Your product description at a high level-Compactly Modular space example Tech response? Engineering characteristics? Your product description at a high level-Compactly packed, Easily deployable, loads on small launch vehicles launched to MEO, components easily joined together, quickly updated, maneuvering, controlled thermal environment, limited system complexity, power generation, storage Client voice Responsive Modular Collect data Refuelable Repairable Reliable Deployable in segments 12 12

Technical responses at a high level - the great words people will say about Technical responses at a high level - the great words people will say about your engineering design Compactly packaged, Easily deployable, loads on small launch vehicles launched to MEO, components easily joined together, quickly updated, maneuvering, controlled thermal environment, limited system complexity, power generation, storage • Compactly packaged • Fits into shroud with little wasted volume • Attaches easily to rocket assembly • Minimal number of separate pieces • Components easily deployable & joined • Fittings? • Latches? • Interfaces simple to use • Easy deployment • Connectors for power and cooling are easily used 13 13

Comments • Ho. Q exercises bring out questions and opinions. • A neutral facilitator Comments • Ho. Q exercises bring out questions and opinions. • A neutral facilitator is useful (if you could hire one then you’d do • • • it). Sometimes voting first speeds up the process When there is a diversity of votes, ask for clarification and opinion. Sometimes the row or column heading need to be modified (“maximize safety” becomes “safety”) Sometimes a technical response (column) is missing (“launch vehicle size” or something similar is missing and was consistently being discussed under “responsive launch”) At the end you have new ideas, better ideas and know where people stand why they stand there. 14 14

Airplane example Tech response, engineering characteristics Short take-off capability, easy ingress or egress, cabin Airplane example Tech response, engineering characteristics Short take-off capability, easy ingress or egress, cabin comfor Client wishes Operate out of small airports Contain fewer than 19 passengers Operate in commuter markets Loading and unloading of passengers in small airports 15 15

Not too much and not too little • Objectives and design functions are important Not too much and not too little • Objectives and design functions are important to know, but… • Objectives are statements of what the design must achieve or do, not how well it must do it • We need performance specifications to set limits • Performance specifications provide boundaries to the solution space • Specifications define product performance, not the product itself • Specifications can limit our design space or direct team efforts • If specs are too broad then there is not guidance about where to go • If specs are too narrow or small we may eliminate good design solutions 16 16

Start the process by …. • Look at your objectives tree at the top Start the process by …. • Look at your objectives tree at the top level systems objectives • List the high level objectives and: • Rank order the objectives using pair-wise comparison or another method of your choice • Rankings will be used for House of Quality weighting factors • Think about the engineering problem and HOW we will satisfy our objectives by creating a design • The HOW’s are technical objectives or “Engineering characteristics” – called EC’s • EC’s should affect the customer’s perceptions of your product • this is one criterion to decide if you have the right engineering characteristics • Name product features that you use every day impress you? • Which don’t impress you? 17 17

Customer needs are translated into tech requirements with numbers Systems Level Technical (engineering/system level) Customer needs are translated into tech requirements with numbers Systems Level Technical (engineering/system level) requirements (EC columns) Either 1) Ranked New, Unique & Difficult (NUD) Customer Needs or 2) customer attributes (Rows) Relationships between NUD customer needs and Systems Level Tech requirements (A matrix) NUD customer needs EC/Tech requirements are product specific How do we translate a “need” into a measurable technical requirement? Example – “time-responsive means provide within 24 hours” 18 18

Requirements comments • “HOW” is not expressed in terms of a design concept – Requirements comments • “HOW” is not expressed in terms of a design concept – “provide a sun-shield” is not a good choice for an EC • Functional analysis is important • EC’s must convey the right functional and feature performance information – “package within (or be deployed from) restricted launcher volume” – leads to prescription of volumetric size goals • Don’t have a requirement that excludes – unnecessarily – a design concept in the future • Systems level requirements should not state solutions • A correct requirement should be able to be fulfilled by several different design features or components • Tech requirements take time – not just a few minutes of effort • If you are not arguing then you are not doing it right 19 19

Requirements example • Poor requirement • Car acoustic damping materials must be able to Requirements example • Poor requirement • Car acoustic damping materials must be able to maintain internal acoustic noise level at or below 75 d. BA • This is too “prescriptive” – it is not a system level requirement, it is actually a component requirement • Better requirement • Maintain internal car acoustic noise level below 75 d. BA under any set of driving environment conditions • This is “descriptive” and suggests a measurement and a measurable objective independent of the design concept – it allows more than acoustic damping materials as a solution 20 20

Establish relationship between VOC/NUD needs and each requirement EC/Technical (engineering/system level) requirements (EC columns) Establish relationship between VOC/NUD needs and each requirement EC/Technical (engineering/system level) requirements (EC columns) X Ranked New, Unique & Difficult (NUD) Customer Needs (Rows) X X X Relationships between NUD customer needs and Systems Level Tech requirements X (A matrix) X X X Which tech requirements affect the VOC/NUD’s? Put an X in the cell 21 21

Quantify the strength of relationship between VOV/NUD needs and each X’ed requirement Technical (engineering/system Quantify the strength of relationship between VOV/NUD needs and each X’ed requirement Technical (engineering/system level) requirements (EC columns) 1 Ranked New, Unique & Difficult (NUD) Customer Needs (Rows) 3 1 1 9 3 1 Relationships between NUD customer needs and Systems Level Tech requirements 1 (A matrix) 1 3 3 9 3 w strong is the relationship between each requirement and each VOC/NUD? Put a 0, 1, 3, 9 in the cell 9=strong relationship between VOC and requirement – highly dependent – if you satisfy requirement you’ll make the customer very happy 22 22

Quantify the strength of relationship between VOV/NUD needs and each X’ed requirement Technical (engineering/system Quantify the strength of relationship between VOV/NUD needs and each X’ed requirement Technical (engineering/system level) requirements (EC columns) 1 Ranked New, Unique & Difficult (NUD) Customer Needs (Rows) 3 1 1 9 3 1 1 1 3 3 9=strong relationship between VOC need and requirement – highly dependent – if you satisfy or include this requirement you’ll make the customer very happy 3=moderate relationship between customer need and design requirement 1=weak relationship between need and requirement 0=no relationship at all EXAMPLE - VOC time-responsive “need” and requirement to launch & 23 23

How important is each tech requirement? Technical (engineering/system level) requirements (EC columns) 1 Ranked How important is each tech requirement? Technical (engineering/system level) requirements (EC columns) 1 Ranked New, Unique & Difficult (NUD) Customer Needs (Rows) 3 1 1 9 3 1 1 1 3 3 2 13 9 12 3 5 3 4 We can simply sum or do a weighted sum – more later 24 24

Which requirements are important and likely to drive the system design? • All tech Which requirements are important and likely to drive the system design? • All tech requirements must be fulfilled but a few will stand out • Requirements that are difficult to fulfill and are critical to customer satisfaction must be given high priority and team attention • Some requirements are contradictory • Low cost vs. responsive • This require a trade • Find where conflicts exist • Find where synergies exist • Make sure that you haven’t accidentally created a conflict 25 25

Identifying conflicts and support among Tech requirements Technical correlation matrix (the roof) Systems Level Identifying conflicts and support among Tech requirements Technical correlation matrix (the roof) Systems Level Technical EC requirements Ranked New, Unique & Difficult (NUD) VOC Relationships between NUD customer needs and Systems Level Tech requirements The tech correlation matrix (roof) is a set of matrix elements arranged in a triangular fashion 26 26

Relationships between tech elements How strong? The roof identifies synergies and conflicts _ + Relationships between tech elements How strong? The roof identifies synergies and conflicts _ + Tech 1 Use + or – 1, 3, 9 system 0 Tech 2 Tech 3 27 27

Do you have competitors? • Quantify and document the capability of competitors to currently Do you have competitors? • Quantify and document the capability of competitors to currently fulfill each system level VOC/NUD requirement Technical correlation matrix (the roof) Systems Level Technical EC requirements Ranked New, Unique & Difficult (NUD) VOC Relationships between NUD customer needs and Systems Level Tech requirements Planning with customer ranking 28 28

Planning and customer ranking Benchmarking • Find similar designs or designs that compete with Planning and customer ranking Benchmarking • Find similar designs or designs that compete with yours • Look at VOC features • Place yourself in the position of the customer • Rank how these current designs fulfill requirements • 1=highest fulfillment • 5=lowest fulfillment Design 1 Design 2 Design 3 Design 1 5 1 3 Planning 3 matrix 2 ranking 1 1 29 29