What Are QFD and Six Sigma?
- 1.1 Brief Capsule Description
- 1.2 What Is Six Sigma?
- 1.3 History of QFD and Six Sigma
- 1.4 What Is QFD Being Used for Today?
- 1.5 Discussion Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Current best practices have evolved in the Six Sigma community to include Lean Manufacturing Methods and tools, and therefore is sometimes called Lean Six Sigma or Lean Sigma. For the sake of avoiding certain definition issues, the term Six Sigma will be used for a broad description of the Six Sigma methodologies described herein.
1.1 Brief Capsule Description
1.1.1 Quality Function Deployment Defined
Just what is Quality? In English, as an adjective it means "excellent." The original Japanese term for QFD has meanings of features or attributes too. Quality is determined by customer expectations, so you cannot have a quality product or a quality service without identifying your customers and discovering their expectations. The second word, Function, means how you will meet customer expectations, or how your products or services will function to meet them. The third word, Deployment, defines how you will manage the flow of development efforts to make certain that customer expectations drive the development of your new products and services.
This book provides both formal and informal examples of QFD. In many ways, successful businesses large and small are applying QFD in formal and informal ways. No business can have continued success in the 21st Century without listening and responding to customers. Enabling the reader to learn how to do this better is the fundamental purpose of this book. In the words of W. Edwards Deming: "Learning is not compulsory, but neither is survival."
QFD is a method for structured product or service planning and development that enables a development team to specify clearly the customer's wants and needs, and then evaluate each proposed product or service capability systematically in terms of its impact on meeting those needs. QFD is fundamentally a quality planning and management process to drive to the best possible product and service solutions. A key benefit of QFD is that it helps product-introduction teams communicate to management what they intend to do, and to show their strategy in the planned steps forward. Management can then review these plans and allocate budget and other resources. QFD helps enable management to evaluate whether the product plans are worth the investment. Working through the QFD process together provides the important benefit of alignment—within the project team, and to management desires.
The QFD process tends to vary from practitioner to practitioner. In all cases, however, successful QFD work requires accurate assessment of customer needs. This begins with gathering the Voices of Customers (VOC), and ends with validating their needs. Some variant of the VOC process is included in most definitions of QFD, Six Sigma, Design for Six Sigma (DFSS), Marketing for Six Sigma (MFSS), Six Sigma Process Design (SSPD), and Technology for Six Sigma (TFSS). An illustration of this front-end work is provided in Figure 1-1.
)
Figure 1-1 Front End of the QFD Process
Clearly, several steps must be followed to determine customer needs before beginning the matrix work that is often associated with the QFD process. QFD is a flawed exercise if it does not acquire well-defined and validated customer voices.
As mentioned above, the QFD process includes constructing one or more matrices (sometimes called Quality Tables). The first of these matrices is called the House of Quality (HOQ), shown in Figure 1-2. It displays the customer's wants and needs (the VOC) along the left, and the development team's technical response for meeting those wants and needs along the top. The matrix consists of several sections or sub-matrices joined together in various ways, each containing information that is related to the others (see Figure 1-3). As I have often said when teaching various Six Sigma tools, "Some tools flag the gaps, and others fill them." QFD is a method that flags gaps in knowledge, capability, and understanding as the design team works through the various QFD elements. It also keeps track of how key product and process design decisions relate to customer needs.
)
Figure 1-2 The House of Quality
)
Figure 1-3 Interrelated Matrices
Each of the labeled sections (1 through 8) is a structured, systematic expression of a product- or process-development team's perspective on an aspect of the overall planning process for a new product, service, or process. The numbering suggests one logical sequence for filling in the matrix.
Section 1 contains a structured list of customer wants and needs. The structure is usually determined through qualitative market research. The data is presented in the form of a tree diagram (defined and explained in Chapter 3).
Section 2 contains relative-importance ratings as determined by sampling customers for their priorities.
Section 3 contains two main types of information:
- Quantitative market data, including the customer's satisfaction levels with the organization's and its competition's current offerings
- Strategic goals for the new product or service
Section 4 contains, in the organization's technical language, a high-level description of the product or service it plans to develop. Normally, this technical description is generated from the customer's wants and needs in Section 1.
Section 5 contains the development team's judgments of the strength of the relationship between each element of its technical response and each customer want or need.
Section 6, Technical Correlations, is half of a square matrix, split along its diagonal and rotated 45°. Its resemblance to the roof of a house led to the term House of Quality becoming the standard designation for the entire matrix structure. Section 6 contains the development team's assessments of the implementation interrelationships between elements of the technical characteristics.
Section 7 contains a comparison of product or service metrics between your current offerings and that of competitors.
Section 8 contains relative weighting of customer needs versus how well you are performing on the relevant product and service metrics.
Section 8 contains three types of information:
- The computed rank ordering of the technical responses, based on the rank ordering of customer wants and needs from Section 2 and the relationships in Section 5
- Comparative information on the competition's technical performance
- Technical-performance targets
QFD authorities differ in the terminology they associate with the various parts of the House of Quality. I have tried to be consistent throughout this book, but in day-to-day usage, most people use various terms for sections of the HOQ. I have tried to indicate common alternate terminology whenever I have introduced a new term. There is no reason to be concerned about the lack of standardization; it rarely causes confusion.
Beyond the House of Quality, QFD optionally involves constructing additional matrices to further plan and manage the detailed decisions that must be made throughout the product or service development process. In practice, many development teams don't use these additional matrices. They are missing a lot. The benefits that the House of Quality provides can be just as significant to the development process after the initial planning phase. I urge you to use Part V of this book to become familiar with the later stages of QFD, and then, with that knowledge available to you, to make an informed decision about how much of QFD your development project needs.
Figure 1-3 illustrates one possible configuration of a collection of interrelated matrices. It also illustrates a standard QFD technique for carrying information from one matrix into another. In Figure 1-3 we start with the HOQ, in this instance labeled 1: Product Planning. We place the Whats on the left of the matrix. Whats is a term often used to denote benefits or objectives we want to achieve. Most commonly, the Whats are the customer needs, the VOC data, but the development team's own objectives could also be represented as Whats. As part of the QFD process, the development team prioritizes the Whats by making a series of judgments based in part on market-research data. Many different techniques for determining these priorities are described later in this book.
Next, the development team generates the Hows and places them along the top of Matrix 1. The Hows are any set of potential responses aimed at achieving the Whats. Most commonly, the Hows are technical measures of performance of the proposed product or service. The relating of the Whats to the Hows is critical, because assumptions can sneak in that are unwarranted. This is why the VOC work preceding the definition of Whats is so crucial!
Based on the weights assigned to the Whats and the amount of impact each How has on achieving each What, the Hows are given priorities or weights, written at the bottom of the HOQ diagram. These weights are a principal result of the HOQ process.
In this simplified view, the second matrix is labeled 2: Product Design. This second matrix could as easily be labeled Service Design; or, if you are developing a complex Product System, it could comprise a sequence of matrices for System Design, Subsystem Design, and finally Component Design. To link the HOQ to Matrix 2, the development team places all, or the most important, of the HOQ Hows on the left of Matrix 2, and the priorities of those Hows on the right. These HOQ Hows now become the Whats of Matrix 2, their relative importance to the development team having been determined in the HOQ process.
To achieve the Matrix 2 Whats, the development team needs a new, more technical or more detailed set of Hows, which are put at the top of Matrix 2. As before, the team uses the weights of the Matrix 2 Whats, and estimates the degree of relationship between the Matrix 2 Hows and the Matrix 2 Whats, to arrive at weights or priorities for the Matrix 2 Hows.
To link Matrix 2 to Matrix 3, the Matrix 2 Hows are transferred to the left of Matrix 3, becoming the Matrix 3 Whats. The weights of the Matrix 2 Hows are transferred to the right side of Matrix 3, and new Matrix 3 Hows are generated.
Each matrix in the chain represents a more-specific or more-technical expression of the product or service. In the classical model for QFD,1 which was designed for the development of hardware products, the relationship of Whats to Hows in each matrix is as shown in Figure 1-3.
While this model mirrors the process of designing and manufacturing a physical product, similar models exist for developing services, for designing processes, and for developing software products. They are all covered in other parts of this book.
Other multiple-matrix QFD schemes are considerably more elaborate than the three-matrix scheme illustrated in Figure 1-3.2 Some QFD schemes involve as many as thirty matrices that use the VOC's priorities to plan multiple levels of Design Detail, Quality Improvement Plans, Process Planning, Manufacturing Equipment Planning, and various Value Engineering plans. Some QFD experts believe that the use of additional matrices is not optional, and that the process should not be called QFD unless a series of matrices is constructed. In this book, however, we take a more liberal view; each team must make decisions on how far to go, considering the costs of function deployment versus the value delivered. We take the position that QFD delivers many possible benefits at many levels, and should be implemented at a level of detail appropriate to the task at hand.
Depending on the benefits a development team needs or is willing to work for, it will construct just the initial House of Quality, a large collection of interrelated matrices, or something in between. Teams will further customize their matrices to solve the problems they need to solve. From our point of view, it's all QFD. Adapting the old adage "science is what scientists do," we believe that "QFD is what QFD practitioners do."
As we see in Figure 1-4, QFD is a tool that enables us to develop project priorities at various levels in the development process, given a set of priorities at the highest level (customer needs). QFD is not only a prioritization tool; it is also a deployment tool. What we mean by "deployment" is that QFD helps us to start with the highest level of Whats, generally the Voice of the Customer, and to deploy, or translate, that voice into a new language that opens the way for appropriate action. Every developer is familiar with this translation process and probably performs the translation informally all the time. QFD helps make the translation process explicit and systematic.
Figure 1-4. Classical Model for QFD Matrices
|
Matrix |
What |
How |
|
House of Quality |
Voice of the Customer |
Technical Performance Measures |
|
Subsystem Design Matrix |
Technical Performance Measures |
Piece-Part Characteristics |
|
Piece-Part Design Matrix |
Piece-Part Characteristics |
Process Parameters |
|
Process Design Matrix |
Process Parameters |
Production Operations |
Finally, QFD provides a repository for product planning information. The repository is based on the structure of the QFD matrices. The matrices allow for entering the Voice of the Customer (and, in subsequent matrices, other deployed What and How information) and all related quantitative information, the Voice of the Developer and all related quantitative information, and the relationships between these voices. This information represents a succinct summary of the key product planning data. To be sure, very detailed elaboration of this information cannot fit in the QFD matrices and must be stored elsewhere. Documenting the matrices provides a golden thread throughout the design process, tracing the design decisions and tradeoffs and potential alternatives for enhanced offerings. The matrices can be viewed as a top-level view or directory to all the rest of the information. In fact, QFD has sometimes been described as a "visible memory of the corporation."3
There are many other views of QFD, and many will be explored elsewhere in this book. For now, it will be useful to keep in mind these main ideas: QFD provides a formal linkage between objectives (What) and response (How); it assists developers in developing or deploying the Hows based on the Whats; it provides a systematic method of setting priorities; and it provides a convenient repository of the information.