Design for Six Sigma
Total Page:16
File Type:pdf, Size:1020Kb
FRONTIERS OF QUALITY Design for Six Sigma You need more than standard Six Sigma approaches to optimize your product or service development by Douglas P. Mader any organizations believe tion of traditional quantitative quali- ing at the micro level. Our technical design for Six Sigma (DFSS) ty tools. training is centered around a four- M is a design process when DFSS opportunities should be cat- step methodology that provides a really it is not. DFSS is an enhance- egorized by the size of the effort. general approach to the application ment to an existing new product Macro opportunities involve the of DFSS at the project level and sub- development (NPD) process that design and development of an tasks within a design project. provides more structure and a bet- entirely new product or service or ter way to manage the deliverables, the major redesign of an existing The ICOV approach resources and trade-offs. one. Micro opportunities are smaller The DFSS approach we use at the DFSS is the means by which we in scope and likely pertain to the micro level consists of four major employ strategies, tactics and tools to execution of a subtask within a steps, known as ICOV (see Figure 1): enhance an existing design process to macro opportunity. 1. Identify. achieve entitlement performance. It To address macro opportunities, 2. Characterize. integrates qualitative and quantita- most organizations develop their 3. Optimize. tive tools and key performance mea- own NPD process based on the 4. Validate. sures that allow progressive seven-step systems engineering Identify. This stage consists of two organizations to manage an NPD model. Modern implementations of major steps. The first is to develop a process more effectively to optimize DFSS consist of integrating DFSS clear understanding of customer several competing key drivers, such deliverables into the checkpoint cri- requirements for the micro level as cost, quality and time to market. teria for the macro level NPD design activities, in which the defini- A typical NPD process might process, training the management tion of the customer can include include several high-level develop- team on how to resource and guide internal and external customers and ment phases, such as the seven-step the effort, and using a structured other stakeholders. We also take into systems engineering model: needs approach to the application of DFSS consideration the business’s finan- assessment, concept design, prelimi- principles at the micro level. cial goals, such as development cost nary design, detail design, process At the macro level, there is no and schedule. The needs and wants design and construction, manufac- consistent standard for integrating are collectively known as CTXs or turing and end of life. Most organi- DFSS into an existing NPD process “critical to (whatever the particular zations have instituted management because NPD processes are as wide- need or want is).” These CTXs are reviews called checkpoints or toll- ly varied as the products and ser- then translated into architecture gates throughout these design phas- vices they generate. My company, requirements, specifications, perfor- es to allow the organization to SigmaPro, works with its clients to mance criteria or other objective assess risks, monitor progress and map their NPD processes and measures for the activity. ensure transitions from each phase develop a custom approach that The next step is to identify what to the succeeding phase are war- uses best practices from the organi- resources are needed to achieve the ranted. zation and incorporates DFSS deliv- requirements identified in step one. erables into the checkpoint criteria. Consider technology, manpower, Focus on risk management in the early phases Management training is ad- supplier, process and business con- Because quantitative measures of dressed before technical training straints. Then create an effective performance may not exist until the because many of the issues pertain- plan to achieve the CTXs. Common physical product is prototyped or the ing to performance of the NPD deliverables for this stage include a service is piloted in the later design process are not technical in nature. feasibility study, definition of the phases, all that exists early in the Once DFSS criteria have been inte- customer, needs analysis, financial NPD process is the risk of future grated into the NPD process, the or cost analysis, system operational problems. This is why progressive management team has been fully requirements, functional require- organizations focus on risk manage- trained and the appropriate design ments and advance product plan- ment in the early phases of an NPD projects or applications have been ning. process rather than on the applica- selected, we launch technical train- Characterize. In this stage we 82 I JULY 2002 I WWW.ASQ.ORG develop, test and validate design con- If we have several competing con- product input variables (KPIVs) cepts. Once we have identified the cepts, we need to determine the that we can control in order to opti- CTXs and determined the required measurement systems that will mize the KPOVs. level of performance, the designer or allow us to test the performance of To quantify the relationship team may have several competing the system for important design between KPOVs and their associat- solutions or concepts. Pugh concept attributes. For product design attrib- ed KPIVs, we develop transfer func- selection methods and enhanced utes, we use statistical measurement tion models. These models provide quality function deployment (EQFD) capability methodologies, such as information on how we can change matrices are often coupled with fail- gage repeatability and reproducibili- the KPIVs to optimize the perfor- ure mode and effects analyses ty, and risk analysis. A common mance of the KPOVs and, therefore, (FMEA) and cause and effect matrices mistake DFSS practitioners make, the design. to help organize the information per- however, is to assume we are only For the construction of transfer taining to concept selection. Several referring to hardware tests in this function models, we have two alter- other common tools employed in this important step. In fact, subjective natives. If we have a physics based stage include architecture block dia- testing methods such as choice mod- equation, we can use calculus based grams, functional flow diagrams, eling, focus groups and customer methods to predict the mean, vari- specification trees, functional hierar- interviews are equally as important ance and capability for a KPOV chy diagrams and process mapping. as hardware testing. based on the means, variances For services, we need and capabilities of the KPIVs. to find measurement Unfortunately, this method is FIGURE 1 Identify, Characterize, systems, such as cus- extremely difficult even for simple Optimize And Validate tomer satisfaction, rec- problems and is rarely used. Strategy ommend rates, re- The second method is to build purchase rates and per- empirical prediction equations ceptions of value, that using regression or other mathemat- Translate high level requirements (CTXs) into objective measures allow us to measure ical methods based on simulation or performance subjec- experimental results. Empirical pre- Identify tively. Tools such as diction models allow us to predict Identify resources, gaps and risks surveys and process the mean, variance and capability of mapping coupled with a KPOV based on the means, vari- FMEAs are extremely ances and capabilities of the KPIVs. Formulate concept design useful. Once we have Monte Carlo simulation is typical- determined the mea- ly used for hardware scenarios, and Validate measurement systems surement systems that discrete event simulation is used for will give us the infor- service scenarios. Engineers often Characterize mation we need have simulation engines that are Assess concept designs regarding the perfor- adept at modeling physical systems, mance of the design, and these tools have been standard we implement the con- practice for some time. Only recent- Evaluate risk to CTXs for all concepts cept testing process ly, with the development of integrat- and evaluate the risk ed process mapping and simulation with regard to the tools, have similar methods become For each CTX, identify key product/process output variables (KPOVs) CTXs. We can then available to service designers. make a decision to pro- After we develop transfer func- ceed or to revisit the tions and optimize the system, we Develop transfer functions between design concepts. need to establish realistic perfor- KPOVs and key input variables (KPIVs) Optimize. In this mance criteria for the product or Optimize stage we make sure we process. In other words, we establish Establish realistic performance criteria have optimized the the criteria that will be used to design with regard to assess whether the process or prod- customer and business uct fulfills the customer’s require- Assess risk to CTXs via KPOVs/KPIVs requirements. For each ments. Then we estimate our risks to CTX, the designer or the desired performance of the CTXs team should identify using knowledge of the KPIVs, Test and validate solution/design the key product or transfer functions and the predicted Validate process output vari- performance of the KPOVs. ables (KPOVs) that A key question to ask is how well Establish controls and action plans relate to the desired the system fulfills the customer performance. Once the wants and needs. If we can demon- Assess overall risk