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:

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:

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

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, Yi and to establish an operating window for chosen Ys for new and aged conditions. The define stage is divided into three areas:

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(y1, y2, y3,...yn) 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:

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

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:

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

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:

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

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:

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:

The application process of design verification:

  1. Review generic requirements, either online or as paper reports.

  2. Classify each requirement based on applicability to your program. Record and document the classification in appropriate and applicable log.

  3. Modify or add requirements based on assumptions and targets. Record and document the classification in appropriate and applicable log.

  4. Determine the minimum feature configurations that your DVP team will need to verify its requirements.

  5. 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:

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:

Категории