Logistics Decision Analysis Methods

1. Logistics Decision Analysis Methods Quality Function Deployment – Part III Presented by Tsan-hwan Lin E-mail: percy@ccms.nkfust.edu.tw

2. Construction of the HOQ • The first section of the HOQ to be constructed will almost always be the Customer Needs/Benefits section. • Sections are also referred to as “rooms.” • The Planning Matrix(also, Preplanning Matrix) is often the second section to e constructed. • The third section of the HOQ to complete is the Technical Response(also, Corporate Expectations) section. • The fourth step is to complete the “Relationship” section of the HOQ. • The fifth and sixth steps in completing the HOQ are Competitive Benchmarking and Target Setting. • The seventh and usually final step in completing the HOQ is to fill in the Technical Correlations Matrix. • This part is also referred to as “roof.”

3. Q & A

4. Technical Response - 1 • Just as the Voice of the Customer had a qualitative and quantitative component (entered into the Customer Needs/Benefits section and the Planning Matrix section), so does the translation of the VOC into the Voice of the Developer. • The translation (SQCs) will be placed in qualitative form on the top and in quantitative form at the bottom. • In QFD parlance, we use the term Quality Characteristics to denote the customer’s needs (the VOC). • The translation into technical term is called Substitute Quality Characteristics because it represents a translation from the customer’s language into the organization’s technical language. • Most commonly, developers call this language the Product Requirements（產品需求） or the Design Requirements（設計需求）.

5. Technical Response - 2 • The nature of Product Requirements varies widely. • Many organizations describe products and services in more than one language, or more than one set of terms (such as, Customer Requirements, Market Requirements, Top-Level Specifications, Detailed Specifications, or Technical Specifications, to name but a few). • There is often much confusion about the boundaries between various product description languages, and there is little or no standardization of the vocabulary of each language. • The ideal relationship between various product or service description languages is one in which the languages are defined and ordered according to how abstract, or solution-independent,each language is. • If one product description allows for many possible implementation, it is more abstract than another which clearly describes or implies one and only one implementation.

6. Technical Response - 3 • One way that QFD practitioners describe various levels of abstraction is with “Whats/Hows” metaphor. • The language that appears on the left side of a QFD matrix represents “What” is desired. The language at the top of the matrix describes “How” the developers will respond to the “What.” • To get the most out of QFD, the language of the “Whats” should be distinctly more abstract than the language of the “Hows.” • Given a term that describes some aspect of a product, it is not always easy to decide what language it belongs to. • Examples: VOC “tinted glass” in an automobile => Needs “privacy” (“tinted glass” => “What”? “How”?) • A practical method for dealing with the problem of placing product requirements in the right place in QFD is to use the Voice of the Customer Table (VOCT).

7. Technical Response - 4 • Some generic formulation of SQC exist, notably one by Stuart Pugh. • Such formulations can be used as “starter kits” to get a set of SQCs established rapidly, and to aid teams in arriving at a complete set. • The generic formulations must of course be modified to meet the needs of the team’s specific project. How How How deploying (more detailed) What What What

8. Technical Response - 5 • Main categories of VOCT Part 2: (Review) • Customer Needs （顧客實際需求） • Substitute Quality Characteristics （替代性品質特性；技術回應） • Functions （功能） • Reliability Requirements （可靠度需求） • Target Values（目標值） • Languages for Substitute Quality Characteristics: • (Top-Level)Performance Measurement（績效衡量方法） • Product Function（產品功能） • Product Subsystem （產品子系統） • Process Steps （流程步驟）

9. Relationships • The Relationships section provides a mapping between Substitute Quality Characteristics on the one hand, and Customer Wants and Needs on the other. • Each Relationship cell represents a judgment, made by the development team, of the strength of the linkage between one SQC and one Customer Need. • The strength of linkage is called the impact of the SQC on the Customer Need. • There are four types of impacts. • Judging impact of performance measures • Judging impact of other SQCs • Meaning and choice of impact values

10. Determination of Priorities of SQCs • Once the development team has determined all the impacts or linkages, some simple arithmetic provides one the key results of QFD: the relative contributionsof the SQCs to overall customer satisfaction (the priorities of the SQCs). • Relationship of technical response X to customer satisfaction performance on need A = Impact (value) of technical response X to need A * Normalized raw weight for need A • Contribution of the SQC to overall customer satisfaction = Sum of Relationships over all needs • The larger the contribution, the more influence the SQC has on customer satisfaction performance, and therefore the more important it is for the product or service to do well in the implementation of that SQC. • If the SQCs and their contributions are to be transferred to the left side of another matrix, it is useful to convert the contributions to normalized contributions.

11. Negative Impacts - 1 • It happens occasionally that a SQC is found to have a negative impact on customer satisfaction performance for a certain attribute. • Such negative relationships can happen when an SQC has been selected for its positive impact on one or more attributes, but the attribute with which it is negatively linked has not yet been considered. • Example: SQC (wider range of services) vs. Needs (transactions processed from a single source <positive>; simple of use <negative>) • Negative impacts complicate QFD computations. • One way to solve this is to take “negative” value in computation. • Compute two sums: algebraic (signed) sum of relationships and sum of the absolute values of the relationships • If the difference between the two is small, disregard the negative impact. If the difference is large, the team is being challenged to define one or more Technical Responses that provide positive impacts only to replace the one that contains negative impacts.

12. Negative Impacts - 2 • An alternative way is, • Express all impacts on customer satisfaction performance as positive. • Study the negative impacts as they are reflected in the Technical Relationships (the roof) section of the HOQ.

13. Q & A

14. Performance Measurements • Probably the most valuable language for SQC is the language of Performance Measurements. • These are measurements that the development team derives directly from customer needs. • They should be general enough to be applied to a product or service regardless of the specific implementation. • They may provide ideal measurements (1) for benchmarking competitive products or services and (2) for providing a solution-independent starting point for developing new concepts. • The standard method for developing Performance Measurements is to begin with the customer attributes (i.e., customer needs). For each customer attribute, • Define measures • Define measurements

15. Define Measures - 1 • Defining measures is the process by which the development team establishes the relevance and the relationship between its measurements and customers’ perception. • In a nutshell, the team translates (or deploys) each customer need into a technical performance measure. • For each customer attribute, define one or a few technical performance measurements. Write these along the top of the HOQ. For each measurement, be sure that, • It can be measured while the product or service is being developed, and before it is shipped or deployed (i.e. it can be used as a predictor rather than a lagging indicator of customer satisfaction performance). • It can be controlled by the development team (i.e. the team should be able to make decisions that would effectively adjust the measurement up or down to meet expected customer satisfaction).

16. Define Measures - 2 • To be properly defined, each performance measurement should be characterized in a few ways. • First, the units of the measurement（度量單位）should be defined. • Examples: voltage (in volts); time (in minutes); process complexity (number of steps); accuracy (defects per thousands of transactions) • Second, the direction of goodness（良性發展方向）should be defined.

17. Performance measure Performance measure Customer attribute Define Measures - 3 BACK

18. Direction of Goodness - 1 • The More the Better • The implied target is infinity. • Examples: reliability (mean time between failure; MTBF); fuel efficiency (miles traveled per gallon); bonding strength (pounds supported per square inch of adhesive area) • Development teams need both the aggressive objective (infinity) and an acceptable value for the measure. • If we view targets as infinity (instead of an acceptable value or tolerance（容差）for the metric), we may see possibilities for increasing performance that we have not seen before. • Examples: secondary storage capacity (1.4Mb floppy => 125Mb USB => 40Gb USB HD) • On the other hand, arbitrarily high numerical objectives are usually impossible or very impractical to achieve.

19. Direction of Goodness - 2 • The Less the Better • The implied target is nominally zero. • Examples: service quality (number of defects per thousands of transactions); process simplicity (number of steps); startup speed (time to launch a software application) • Sometimes in a case where the target is minus infinity, the measurement can be shifted so that zero become the lowest possible value. • Example: refrigeration (absolute zero; Celsius –273o)

20. Direction of Goodness - 3 • Target Is Best • The target is as close as possible to a nominal value with no variation around that value. • Examples: exactness of fit (diameter of a steel rod); constancy of ideal temperature of a food freezer container is 4oF (-16oC). • The majority of top-level performance measurements in service applications will be one of the “More the Better” and “Less the Better” types.

21. Define Measurements • In this step, describe how each measurement will be performed. • Also, document all assumptions and comments about each measurement. • The omission of this step leads to much time lost during planning and later on during development. • This step operationalizes the definition of the measurement. • Measures without measurement cause confusion, because one person will inevitably have in mind a different measurement process than another. • Examples: how to measure the startup time of a software (existing application, operating system, and RAM configuration assumptions may be different) • The detailed description of the measurement may guide developers about what to optimize. It also makes all discussion involving the measurement clearer and more efficient. BACK

22. Product Functions - 1 • It can be appropriate to use (product or process) functions (instead of performance measures) under the following circumstances: • The product or service concept has already been established. • Especially, breakthrough ideas, at least at the strategic level, are not needed or are already incorporated into the concept. • In such a case there may be a list of possible extensions – already expressed as features（特色）– that need to be prioritized.

23. Product Functions - 2 • The development team lacks either the time or the interest to develop and prioritize performance measures. • Since prioritization of performance measures does not define a product’s or service’s features, the QFD process must be used at least once more to translate prioritized performance measures into prioritized features. This extra step is time-consuming and may not always be worth the effort. • Some development teams, especially software development teams, are unaccustomed to using performance measures in their product definition process. • While translating customer needs directly into functions lowers the chances for breakthrough ideas, teams that don’t normally use performance measures may be better doing just such a translation.

24. Product Functions - 3 • Many products and services have large numbers of capabilities or functions. • Depending on the level of detail the developers use to describe the functions, the OQ could be correspondingly small or large. • The developers can use the Affinity Diagram process to decide what level of functional details they want to work at. • The affinity diagram hierarchy of product or process function will have several levels. • Analyzing at the higher levels will present the advantage of quicker analysis and disadvantage of less depth in the analysis. • The HOQ at the strategic analysis level (i.e., higher level) will indicate which few critical functional areas require more detailed planning. These areas can then be singled out, and the development team can analyze only those areas in a subsequent HOQ.

25. Product Functions – Function Tree • As is true of all Affinity Diagrams, functions are organized from the bottom up. • Another approach, the Function Tree method (by Don Clausing), uses the Tree Diagram method and organizes the functions from the top down. • In this approach, the primary functions of the product or service are identified first. Each primary function is then broken down into subfunctions. Each subfunction is elaborated into finer detail until the development team has reached the level of detail it needs. • This top-down approach creates a function tree that helps the development team to focus on the most important functions of their product or service. • A Function Tree may be indistinguishable from an Affinity Diagram of functions, once it has been completed. However, the method creating it and the associated points of view are different. • To get the best of both methods, the team may consider first brainstorming functions and affinitizing them, then completing the structure with the Tree Diagram method by working from the top down.

26. Product Subsystems • Most commonly the QFD process translates from • the Voice of the Customer, to • Performance Measures, to • Functions, to • Product design. • Each successive pairs of topics (1 to 2, 2 to 3, 3 to 4) represents the left and top, respectively, of a new matrix. • While the design elements of a product are not normally chosen to be the Substitute Quality Characteristics, there are occasions where the choice is appropriate. • Development team have also created Voice of the Customer to Product Design Matrices (1 to 4). • Such a matrix shows the development team how various components of the product design influence various customer satisfaction attributes.

27. Product Subsystems – Tree Diagram • The most common method for representing the design is by use of the Tree Diagram. • First, identify the primary subsystems of the product. • Each of these subsystems and components can then be described at several levels of additional details, thus providing the development team with the multiple-level Tree Diagram it needs for QFD analysis. • Examples: camera => imaging, film management, viewfinding, and exposure time management subsystems => lens, film plane, and lightproof compartment between lens and film (components) (for imaging subsystem)

28. Process Steps - 1 • For teams developing new processes or services, the following choices for SQC are as applicable as for products: performance measures and process steps. • Performance measures for services are much the same as for physical product. • Their values are generally under the control of the team that designs or lays out the processes underlying the service. • Each process will have one or more clearly defined inputs and outputs. Development teams can define performance measures of these processes, based on time, cost, or quality of result (i.e., inputs or outputs). • In QFD, the service development team can evaluate different process performance measures to determine which ones drive customer satisfaction performance most strongly.

29. Process Steps - 2 • Services are delivered by processes. These processes may be conceived of at various levels of abstraction (just like a product). • While product subsystem analysis may not apply to services, a closely related method of analyzing services and processes (i.e., process steps) does apply. • Example: telephone customer support • Anyone who has analyzed the telephone customer support will know that beneath the simple (high-level view) process lies an enormously complex structure for handling customer requests. • This structure includes many decision points and subprocesses at each of the three main steps. It also includes tools and technology to support these decision points and steps.

30. Process Steps vs. Performance Measures

31. Telephone Customer Support - 1 High-level view of the Process Route incoming calls to Customer Service Associate Classify customer request Respond to customer request

32. Related decisions Tools & Technology Route incoming calls to Customer Service Associate Managing the flow of incoming calls and balancing the volume of these calls against the available Service Associates Elaborate telephone equipment to queue and route incoming calls Identifying the customer, the customer account, and the type of customer request Classify customer request Computers and associated databases to provide up-to-the-minute information about each customer to the Service Associates Respond to customer request Deciding on the appropriate response and acting accordingly Update this information based on the nature of the customer call Telephone Customer Support - 2

33. Technical Correlations Planning Matrix Technical Response Customer Needs Relationships Importance to customer Customer satisfaction performance Competitive satisfaction performance Goal Improvement ratio Sales Point Raw weight Normalized raw weight Cumulative Normalized Raw weight Priorities Competitive Benchmarks Technical Matrix Targets Relationships

34. Types of Impacts - 1 • For most QFD activities, the linkage is considered to be positive, that is, if the SQC is moved in the direction of goodness, customer satisfaction is assumed to increased. • Customer satisfaction performance with respect to the need is not linked to the SQC. • For changes of any sort (, large or small, in the amount or degree) of the SQC, no noticeable change in the customer satisfaction performance of that need is predicted (by the development team). • Customer satisfaction performance with respect to the need is possibly linked to the SQC. • For relatively large changes in the amount of the SQC, little or no change in customer satisfaction performance of that need is predicted.

35. Types of Impacts - 2 • Customer satisfaction performance with respect to the need is moderately linked to the SQC. • For relatively large changes in the amount of the SQC, noticeable but not major changes in customer satisfaction performance of that need are predicted. • Customer satisfaction performance with respect to the need is strongly linked to the SQC. • For relatively small changes in the amount of the SQC, significant changes in customer satisfaction performance of that need are predicted.

36. Types of Impacts - 3

37. Judging Impact of Performance Measures • The Performance Measure is the ideal SQC for making impact judgment. • The impact can be represented as the mathematical relationship between the two variables: Customer Satisfaction A = f (Performance Measure X) • The Performance Measure can be thought of as a independent continuous variable, whereas customer satisfaction performance of any need is a dependent continuous variable. • This assumes a monotonic relationship between the two variables. • It often, also assumes that the relationship is linear. • The disproportionate, nonlinear behavior (SQC) type cannot be easily modeled in QFD. The way to handle it is to treat such SQCs as if they were linear (until setting Target Values in section F).

38. Monotonic and Linear Relationship • Monotonic: As the performance Measure moves in the direction of goodness, customer satisfaction performance continues to improve. • It’s a good idea to try to define Performance Measures that do provide a monotonic relationship with customer satisfaction performance. • Linear: As the Performance Measure moves in the direction of goodness, customer satisfaction performance continues to improve as the same rate. • With Kano model, the relationships for Delighters and Dissatisfiers are not linear.

39. Judging Impact of Other SQCs • It is generally more difficult for development teams to judge impacts when the SQCs are not measurable. • Typically development teams think of nonmeasurable SQCs as either “present” or “absent.” • That is, try to judge whether customer satisfaction performance will be high if the SCQ is present, and low if the SQC is absent. • In fact, it is generally unrealistic and counterproductive to think of product features or service elements in this binary fashion. • Example: SQC (File OPEN command) vs. Need (Can mix material from many documents) => refined SQCs (stripped down OPEN command; deluxe OPEN command)

40. Impact Values • Over time, QFD facilitators felt the need to create a stronger contrast between “strong” and the other impacts, so that strong impacts would have more influence on the final prioritizations. • Some early QFD applications in the U.S. used 5, 3, 1, 0 for the impacts from “strong” to “none.” • The greater the ratio between the values assigned to “strong” and “moderate,” the less likely it is that an SQC with only “moderates” assigned to it will have a technical importance greater than an SQC with at least one “high.” (i.e., 9, 3, 1, 0) • There is no specific basis for any of the choices. • The impact values simply provide a way for the development team to express its judgment on the relative impacts of SQCs on customer needs. • The SQCs can then be differentiated in terms of their overall contribution to customer satisfaction performance.

41. Technical Correlations Planning Matrix Technical Response Customer Needs Relationships Importance to customer Customer satisfaction performance Competitive satisfaction performance Goal Improvement ratio Sales Point Raw weight Normalized raw weight Cumulative Normalized Raw weight Priorities Competitive Benchmarks Technical Matrix Targets Priorities (Contributions)

42. Contribution Calculation  3.9 0.4    1.7 0   Raw Weight Total Contributions Total 