Chapter 5: Design for Six Sigma: The DCOV Model | Six Sigma Fundamentals: A Complete Introduction to the System, Methods, and Tools

In chapter 3, we introduced the DMAIC model. However, as we mentioned, there is another way of improving—through design for six sigma (DFSS). Preventing defects by completing projects in the design process aimed at improving functional performance over time, with a quantified reduction in product or manufacturing or service process variability. The approach is both systematic and dynamic. In its entirety, the approach or model is to define, characterize, optimize and verify. This chapter focuses on both these models and summarizes some of the key events that make the model effective.

The DCOV model

One of the most predominant ideas for design for six sigma is the notion of historical perspective and paradigm change. Our commitment to solving our problems must be based on the precept that we want to avoid problems rather than fix them. To do that we must recognize that old Einstein saying paraphrased here: You cannot solve problems with the same level of knowledge that created them. In other words, we have to look elsewhere for our answers. We cannot always depend on history. We have to look beyond our current status and capability if we are indeed committed to continual improvement.

To fix problems before they happen is an issue of planning and design. It certainly goes beyond the current knowledge and quite often beyond the current modus operandi of a given organization. It forces one to think of future designs. Design for six sigma (DFSS) is a proactive approach to preventing problems from occurring. That is a design issue. Therefore, the power of the six sigma methodology is in the design for six sigma.

As powerful as DFSS is to problem resolution and avoidance, it must also be recognized that there are some problems that do not need to be fixed. Simply stated: some problems are not worth solving. Some issues may seem like they should be problems, but are not problems at all. A problem may be an inherited part of the way you do business and you may not want to change. Or the problem may be part of everyday variability. Trying to solve it is like trying to stop the tides. Trying to fix it wastes effort, and your misguided efforts might make things worse.

Some problems are not worth solving because their consequences are too small to worry about. Your focus should instead be to attack the problems that cumulatively cause enough loss to worry about. Also, some problems are blessings in disguise—problems that, if solved, would allow an even bigger problem to cause a real disaster.

On the other hand, for problems that really need to be fixed, design for six sigma is the only way. For the problems that should be investigated, a rigorous approach is recommended, such as the design for six sigma process, using the define, characterize, optimize and verify (DCOV) model. The minimum effort required to solve problems using the DCOV model is as follows:

Completely understand what happened.
Identify the causal factors that led to the problem.
Systematically find the root causes of each causal factor.
Develop and implement solutions to eliminate the root causes.

To be sure, design for six sigma is very demanding, and yet the opportunity for true improvement and real customer satisfaction lies only with a systematic study up front (in the design). The goal is to improve customer functionality through customer satisfaction and customer loyalty. The process of improvement then is to:

Establish a functional relationship between customer satisfaction drivers (dependent variables) and specific design parameters, CTQ characteristics (independent variables). By reducing the sensitivity of the associated system to noise factors and then manufacturing the independent variables at the 6 (six standard deviations) level, the performance that drives customer satisfaction and ultimately loyalty will be more consistently achieved over time.
While the DFSS process steps are presented in a sequential flow, process execution is not necessarily sequential. For example, the capturing of the voice of the customer, system design and functional mapping are typically iterative processes. On the other hand, design for robustness and for productivity are both simultaneous and iterative.
The DFSS process may become generic and can also be applied during any of the following phases (i.e., advanced project, forward product and ongoing).

To apply these principles to a successful design, these items must be followed:

Understand the fundamental ideas underlying the notion of manufacturability.
Understand how statistically designed experiments can be used to identify leverage variables, establish sensitivities, and define tolerances.
Understand how product and process complexity impacts design performance.
Explain the concept of error propagation (both linear and nonlinear) and what role product/process complexity plays.
Describe how reverse error propagation can be employed during system design.
Explain why process shift and drift must be considered in the analysis of a design and how it can be factored into design optimization.
Describe how six sigma tools and methods can be applied to the design process in and of itself.
Discuss the pros and cons of the classical approach to product/ process design relative to that of the six sigma approach.

The following sections discuss the four stages of the DCOV model: define, characterize, optimize and verify.

The define stage

In the first phase of the DCOV model, the define stage is first explored. The purpose of this stage is to identify the critical to satisfaction (CTS) drivers, Y_i and to establish an operating window for chosen Ys for new and aged conditions. The define stage is divided into three areas:

Inputs. These are the activities that are the initiators for further evaluation. Typical activities are: researching the quality and customer satisfaction history; evaluating warranty data; benchmarking; checking functional, serviceability, corporate and regulatory requirements; evaluating the process in integrating targets; conducting surveys; auditing the current design or process; profiling the brand; performing a Kano analysis; undergoing quality function deployment (QFD); and defining design specifications.
Action. These are the activities that actually help in the selection of the Ys. Typical activities are definition of customer and/or product requirements, relating requirements to customer satisfaction, and conducting peer review.
Output. These are the results of the action. Typical results are projected targets and a preliminary model of understanding.

The characterize stage

In the second phase of the DCOV model, the characterize stage is explored. This stage is generally completed through a two-step approach. The first is the system design and the second is the functional mapping. In both cases, the goal is to characterize the robustness of the design. Therefore, the purpose of the first step is to flow CTS Ys down to lower y's (Y = f(y₁, y₂, y₃,...y_n) and to characterize robustness opportunities (Y = f(xn)). The purpose of the second step is to relate CTS ys to CTQ design parameters (xs) and to optimize the strategy to deliver this robustness.

System design. The process for exploring the first step of the characterize stage is divided into three areas:

Inputs. These are the activities that will generate the action of this step. Typical actions are creating functional boundaries and interface matrices as applicable, function trees (Y → y), a P-diagram; and robustness and/or reliability checklists.
Action. These are the activities that help the decomposition of Y into contributing elements, y_i; obtain (Y = f(y₁, y₂, y₃,…y_n) through modeling, such as DOE, using CAE or hardware (if applicable), experience or prior knowledge and peer review.
Output. This is the result of the action. Typical results are Pareto diagrams, benchmarked CTS factors and the target range of y.

Functional mapping. The process for exploring the second step of the characterize stage is divided into three areas:

Inputs. These are the activities that will generate the activity of this step. Typical activities are creating functional boundaries and interfaces of system design specification (SDS), a functional tree (y → x), P-diagrams and a robustness and/or reliability checklist.
Action. These are the activities that actually help the decomposition of y_i into contributing elements, x_i. Typical activities are: relate independent ys to xs (modeling) or relate correlated ys to xs (modeling, axiomatic design); choose robustness strategy; innovate using structured inventive thinking (SIT) or the theory of inventive problem-solving (TRIZ), understand manufacturing capability and conduct peer review.
Output. This is the result of the action. Typical results are results of screening experiments and prior engineering knowledge, a Pareto diagram, preliminary target and/or range estimates of x_i and internal and/or external benchmark of manufacturing capability of xs.

The optimize stage

In the third phase of the DCOV model, the optimize stage is explored. This stage is also generally completed through a two-step approach. The first is the design for robust performance and the second is the design for productivity. In both cases, the goal is to improve robustness. Therefore, the purpose of the first step is to characterize the present long time in service robustness for the product, and improve robustness by further minimizing product sensitivity to manufacturing and usage conditions, as required. The purpose of the second step is to characterize capability and stability of the present process. This is done simultaneously with the first step. Furthermore, in this step we are also interested in minimizing process sensitivity to product and manufacturing variations, as required.

Design for robust performance. The process for exploring the first step of the optimize stage is divided into three areas:

Inputs. These are the activities that will generate the activity of this step. Typical activities are completing a P-diagram (important y_is);, determining what to measure, control factors (xs), noise factors and error states; conducting an experimental plan (two-step optimization with confirmation run); devising a robustness and reliability checklist; perform a design FMEA (including noise factor analysis) and determining process capability.
Action. These are the activities that actually help find nominals (targets) for xs that minimize variability. In other words, specify tolerances. Typical activities are reducing sensitivity to noise (parameter design, robustness assessment, reliability and robustness), determining tolerances (tolerance design, statistical tolerance, reliability and robustness), eliminating specific failure modes using strategies such as redundancy, eliminating noise and compensating.
Output. These are the results of the action. Typical results are variability metric for CTS or related function (i.e., range, standard deviation, signal to noise (S/N) ratio improvement) and target and tolerances specified for specific characteristics.

Design for productivity. The process for exploring the second step of the optimize stage is divided into three areas:

Inputs. These are the activities that will generate the activity of this step. Typical activities are to present process capability, historical process data (model, surrogate), assembly and manufacturing process flow diagrams (process mapping), reference gauge R&R capability studies and a process FMEA, including noise factor analysis.
Action. These are the activities that actually help the optimization process to produce x_i's nominal with 6σ capability by applying robustness methods to the process (using two-step optimization: reduce variability and then shift to target); using appropriate error-proofing such as DFA, DFM, assembly sequence, poka-yoke, etc.; update the control plan; conduct peer review.
Output. This is the results of the action. Typical results are short-term capability, long-term capability and an updated control plan.

The verify stage

In the fourth phase of the DCOV model, the verify stage is explored. This stage is also typically completed through a two-step approach. The first is the overall DFSS assessment and the second is the test and verify. In both cases the goal is to verify that the capability and product integrity over time is as it was designed and as the customer is expecting it to be. Therefore, the purpose of the first step is to estimate for process capability and product function over time. The purpose of the second step is to assess actual performance, reliability and manufacturing capability, as well as to demonstrate customer correlated (real world) performance over time. If the results of design for robust performance, design for productivity, assessment and testing are not satisfactory, the model action may revert back to the previous stage, or even as far back as the functional mapping stage. Furthermore, in every one of these stages, a trade-off analysis will be performed to ensure all CTSs factors are met.

Overall DFSS assessment. The process for exploring the first step of the verify stage is divided into three areas:

Inputs. These are the activities that will generate the activity of this step. Typical activity is evaluating data from previous steps.
Action. These are the activities that actually help the DFSS overall assessment. Four predominant activities are conducted here: a) determine the CTS/CTQ characteristic/measure and conduct a comparison between the Z_estimate and Z_actual, b) conduct sub-assessments, as needed, c) perform tests and simulation as well as a comparison between the Z_estimate and Z_actual, and d) conduct a variability study over time for both product and process.
Output. This is the results of the action. Typical results are an overall review of assessments for previous steps with the champion or appropriate management.

Test and verify. The process for exploring the second step of the verify stage is divided into three areas:

Inputs. The activities that will generate the activity of this step. Typical activities are developing a reliability and/or robustness plan and designing a verification plan with key noises.
Action. These are the activities that actually help to conduct physical, analytical performance tests enhanced with appropriate noise factors. Typical activities are correlating tests to customer usage; improving ability of tests to discriminate good/bad parts, subsystems and systems; and conducting peer review.
Output. This is the results of the action. Typical results are testing results such as key life testing; accelerated tests; long-term process capabilities; product performance over time (e.g., Weibull test and survival plot); and a reliability/robustness demonstration matrix.

Typical tools/methodologies and deliverables for each stage of the DCOV model are shown in Table 5.1.

Table 5.1: Typical tools/methodologies and deliverables for the DCOV model
Stage	Tools/methodology	Deliverables
*Define*	Kano model Quality function deployment Regression Conjoint analysis	Kano diagram CTS scorecard Y relationship to customer satisfaction Benchmarked CTSs Target and ranges for CTS Ys
*Characterize*	Functional structures Axiomatic designs TRIZ P-diagram R&R checklist DOE	Function diagrams Mapping of Y→ critical function → ys P-diagram, including critical Technical metrics, ys Control factors, xs Noise factors, ns Transfer function Scorecard with target and range for ys and xs Plan for optimization and verification R&R checklist
*Optimize*	Design FMEA Process FMEA Experimental design— response surface Parameter design—two step optimization Tolerance design Simulation tools Error prevention—compensation, estimate noise, mistake-proofing Gage R&R Control plan	Transfer function Scorecard with estimate of σ_y Target nominal values identified for xs Variability metric for CTS Y or related function (e.g., range, standard deviation, S/N ratio improvement) Tolerance specified for important characteristics Short-term capability, "z" score Long-term capability Updated verification plans: robustness and reliability checklist (if available) Updated control plan
*Verify*	Reliability methods Design reviews Customer requirements, including governmental requirements	Reliability testing Specific testing based on requirements Customer functionality Product and/or service as designed

Test and verify. The process for exploring the second step of the verify stage is divided into three areas:

Inputs. The activities that will generate the activity of this step. Typical activities are developing a reliability and/or robustness plan and designing a verification plan with key noises.
Action. These are the activities that actually help to conduct physical, analytical performance tests enhanced with appropriate noise factors. Typical activities are correlating tests to customer usage; improving ability of tests to discriminate good/bad parts, subsystems and systems; and conducting peer review.
Output. This is the results of the action. Typical results are testing results such as key life testing; accelerated tests; long-term process capabilities; product performance over time (e.g., Weibull test and survival plot); and a reliability/robustness demonstration matrix.

Typical tools/methodologies and deliverables for each stage of the DCOV model are shown in Table 5.1.

Special comments on the verify stage

The verify stage for most practitioners is the most difficult to use. Because of that perceived difficulty, we present an overview of some of its key elements with the assumption that the verify stage—more than any other stage—is a team activity.

Design verification process (DVP) team roles and responsibilities:

Interface with other teams to meet requirements.
Review generic requirements.
Identify, add, or modify requirements not included with the generic requirement.
Classify requirements assigned to the DVP team.
Develop minimum feature configurations.
Record program-specific targets.
Develop design verification methods (DVMs) to verify requirements.
Plan when and how to best verify requirements-driven design.
Complete DVP for the requirements-driven designs.
Monitor progress of design.
Prepare sign-off documentation.

The application process of design verification:

Review generic requirements, either online or as paper reports.
Classify each requirement based on applicability to your program. Record and document the classification in appropriate and applicable log.
Modify or add requirements based on assumptions and targets. Record and document the classification in appropriate and applicable log.
Determine the minimum feature configurations that your DVP team will need to verify its requirements.
Establish targets for each requirement and configuration. Record the targets on the target matrix.

Tool requirements

To facilitate a DVP and be able to update and communicate the results, a good software package is recommended. Such software requirements may be met through the use of Microsoft Windows™ (Win 95 or above).

Security

To ensure security, every user should be assigned one of the following levels of access by the program administrator:

Engineer. This level allows the user to view data of all programs using the DVS. Users at this level are permitted to only manipulate data assigned to their DVP team.
Program manager. This level allows the user to have the same authority as an engineer. Users at this level can also change frozen data.
Program administrator. This level allows the user to have the same authority as an engineer. Users at this level also have access to administrative functions.
Full service supplier. This level allows the user to view and manipulate data assigned to their DVP team.

What is in it for me?
Improved test time utilization.
Consistent standardized reporting.
Improved DVP tracking and reporting.
Disciplined adherence to program quality operating system (QOS).
Multiple users allowed access to a central database.
Effort reduced to create and report on DVP.
Connectivity to other systems and databases.
Ensures that you get a verifiable full-product understanding of the requirements (in both functionality and performance).

Defining program requirements

Any design verification must begin with the definition of the requirements. This is to make sure that the design meets the expected requirements. This review should follow a very structured approach. Some of the issues, concerns, questions and discussions should focus in the following items:

Are all requirements accounted for? Requirements come from a variety of sources (customer requirements, corporate requirements, government requirements, system design specifications, safety regulations, and so on).
Is there a possibility of adapting surrogate requirements? Generic requirements can be a source of information that can then be adapted.
Are all requirements have been accounted? The DVS should treat all requirements the same, regardless of level or priority; within DVS, each requirement has an owning DVP team.
Do all requirements have a level of specificity? Requirements capture program-specific targets.
Are appropriate releases defined? Released requirements are available for all programs to use.
Are requirements sufficient for a prototype? Requirements are needed by anyone who needs to schedule a prototype.
Is the design on time? Requirements are frozen according to the timing of your program.