Volume 2 • Number 1
Transform Your Organization Into One ThatS World Class.
By Maurice L. Berryman, Berryman & Associates
Traditional Six Sigma is well understood and somewhat consistently deployed throughout industry, but that is not the case with design for Six Sigma (DFSS). No prior quality initiative seems to be more misunderstood, poorly communicated or inconsistently deployed in industry.
A growing base of companies benefiting from advanced DFSS programs, however, have significant commonality in overall approach. The end result of this highly refined and successful approach to DFSS has been twofold: significantly improved quality levels when products are launched into manufacturing and superior customer satisfaction with the end products.
Further complicating the understanding of DFSS is its many characterizations, starting with the pure engineering, research and design DFSS and extending to the softer forms that apply to business processes and other nonengineering design disciplines.
Some argue the major differences in characterizations lie in the nature of the predictive models and resultant simulation strategies, not in the basic approach to DFSS. The softer forms of DFSS can also be very challenging since there is significant lack of predictive ability for the more qualitative critical to quality requirements (CTQs).
The need for predictive ability is an integral part of any DFSS approach, but if understood from the perspective of the research and design of products, the application to business processes and other forms of DFSS will become obvious and intuitive.
Therefore, I will present DFSS as applied to the pure engineering of products because I believe it is the most comprehensive and complicated of the DFSS processes.
Differences Between Traditional Six Sigma and DFSS
One major emphasis of traditional Six Sigma is on improving manufacturing efficiency and removing the product and process defects prevalent in manufacturing.
There has, of course, been a broadening of Six Sigma applications in recent years into other areas, but eliminating existing defects is still a major area of emphasis. This is well accepted in industry since existing defects can be characterized in terms of their cost, and Six Sigma projects can save significant money due to the cost of poor quality.
This approach of Six Sigma, as efficient as it is, could be fundamentally characterized as a reactive quality strategy based on efficient statistical methods for defect removal and optimization.
Even with all the benefits of removing existing defects, companies realize that these easier improvement efforts in manufacturing and other areas are eventually accomplished. Or, they find the cost to correct potential design problems contributing to the remaining defect levels is greater than the projected cost savings of that improvement effort. In such cases, as companies run out of the easy ways to find and fix defects, they often run into what some have characterized as the 4-sigma wall and must use DFSS to avoid the more difficult defects.
The reactive strategy is in contrast to a proactive, up-front, design defect avoidance approach that says you can never get to Six Sigma levels without addressing the design of the product. With that in mind, one way to characterize the difference between traditional Six Sigma and DFSS is to determine where the Six Sigma activity occurs in the life cycle of a product.
It is a recognized fact that the later in the product life cycle problems are discovered, the higher the cost to correct the problems (see Figure 1). The challenge facing industry is to realize the majority of the producibility, defect levels and quality issues are established during the design phase of a product and become locked in early.
Previous design engineering paradigms view problems that manifest themselves in manufacturing as downstream activities, with design engineerings emphasis on merely producing a functional prototype that is then turned over to manufacturing for production.
Later in manufacturing, the defects may be very easy to identify, but they can be costly to correct. Conversely, in the early design phases, the potential defects are more difficult to identify because of the need for predictive ability. But once defects are identified, they can be fairly easy to avoid.
Obviously, there must be a balance. Not everything can be predicted through engineering analysis, but engineering must always work toward the goal of better product understanding during the design phases. DFSS then becomes a journey where engineering models are created over time, and the predictability of product performance and defect avoidance continually improves.
Since DFSS is not well-documented or understood, misconceptions tend to prevail in the absence of clear definitions. Table 1 shows these misconceptions and how an advanced DFSS process addresses them. An awareness of these principles is necessary prior to understanding any detailed description of DFSS.
The core principles of DFSS have their roots in long established engineering practices, with popular voice of the customer and statistical analysis included to enhance the engineering product development process. To be successful, DFSS must be integrated into existing design processes, with specific expectations during design reviews and design phase exit criteria.
DFSS is a complicated process that can be simplistically characterized as an evolution from reactive design quality to one of predictive design quality, as illustrated in Table 2. The transition to predictive design ability is not an overnight trip, but a multiyear journey into better engineering modeling and a strong coupling of manufacturing capability to design requirements.
DFSS in its simplest form is a systematic methodology consisting of engineering design methods integrated with statistical methods to allow prediction and improvement in quality prior to building prototypes.
There have been many attempts to characterize DFSS as a simple four-step process. Unfortunately, the engineering of products is not that simple. Usually any four- or five-step process may apply to a single requirement (or CTQ), such as in traditional Six Sigma, but not to the overall development of a product.
To best understand the basic principles of DFSS, three factors must be understood:
1. Customer Linkages to Product Requirements
Obviously, the product requirements must be strongly linked to what satisfies the customer. The definition of the system technical requirements must include allowable variation and hard specification limits. In many cases, this may require front-end studies and experimentation to establish the specification limits that satisfy the customer.
Without a strong definition of the quantitative system technical requirements, the development of the product becomes risky and is typically characterized by evolving and changing requirements and resultant areas of ambiguity that make the design of products more difficult.
Quality function deployment has been one accepted technique for linking fuzzy customer requirements to detailed technical system requirements.1
A fuzzy requirement may be one that is more qualitative in nature, such as the comfort of a seat in a passenger car. This requirement must be quantitatively defined in terms of displacements under certain loads or load patterns, dimensional contours and other measures.
DFSS is a multidisciplinary process that does not solely reside in engineering. This example would require the inputs of marketing, customer studies, engineering and manufacturing.
2. Development and Analysis of Internal Requirements
Once the system technical requirements or CTQs are defined for the system, the optimal system architecture that best satisfies the system CTQs must be established. Detailed discussions of systems engineering and its tools of use are available elsewhere,2 but it is safe to say system engineering and system architectural trade-offs are a core part of DFSS and represent a system view rather than a simple component view of products (see Figure 2).
A component view of products is limited in its ability to optimize system performance. Design philosophies that simply rely on producing the best possible parts without consideration of the system context are fundamentally flawed and will usually result in suboptimized systems.
All CTQs must be considered within a systems engineering context, with the CTQs linked together by a systems requirements tree. A systems oriented DFFS process must also include requirements traceability and modeling ability to flow down, optimize and develop internal subsystem and eventually component level requirements.
This is where the real difficulty of the DFSS process comes into play. An advanced DFSS strategy requires the development of a CTQ flow-down tree as shown in Figure 3.
This CTQ flow-down tree, combined with the system architecture, becomes the backbone of working the DFSS process. Linking these CTQs together through engineering modelssometimes called transfer functions, Y = f(x) is the mechanism for developing subsystem level requirements that eventually flow down into component level requirements and tolerances.
These requirements must also consider the propagation of variation and parameter sensitivities as well as nominal values in the development and optimization of lower level requirements. In addition, the capability of meeting those requirements is eventually flowed back up the CTQ flow-down tree and reallocated if necessary for optimal system performance.
All requirements then become need based rather than based upon previous tolerances, capability or nominal values of lower level requirements.
Variance reduction on requirements (CTQs) without an understanding of their sensitivities and influence on higher level requirements in the CTQ flow-down tree is not a value added activity. For example, there is no need for tightly constrained CTQs that have low sensitivities in their influence on higher level requirements; it just adds unnecessary cost to the product.
The actual development of the requirements and their respective analysis strategies and optimization of the CTQ flow-down tree can be somewhat discipline specific. For instance, the CTQ may be linked through a finite element model in mechanical engineering, circuit simulation in electrical engineering or process simulation in chemical engineering or designing of business processes. Or the CTQ may be a product specific system simulation tool. In any case, how those models are created and specifically analyzed and optimized is an important part of DFSS.
Some of the considerations for analysis and optimization are:
These different strategies quickly become overwhelming to engineering. Therefore, a first-class mentoring strategy with DFSS and design engineering experts is necessary to guide engineers through this difficult process and focus them on value added strategies to enhance the quality of their designs.
3. Manufacturings Influence on Product Performance
Technical system requirements usually link down to a component or manufacturing process capability through various transfer functions. Probabilistic design methods can take advantage of the probability distributions of the individual parts and corresponding process capabilities to provide relief in the requirements development process.
Good examples of this are in the area of mechanical tolerancing and how piece parts go together to affect overall assembly tolerances.6 This allows assessment of changes in system level performance and reliability CTQs as tolerances and capabilities are changed for lower level parts and processes. For example, if you change the tolerance or capability by some percentage, what is the effect on the linked top system performance or reliability parameters?
The DFSS process ties together all the complexity of system, subsystem, lower level requirements, manufacturability and supplier issues through a first-rate requirements management strategy using requirements management tools and design margin trade-off visibility on CTQs (sometimes referred to as scorecards in DFSS).
This approach significantly simplifies the design process and lays everything out on the table to allow the entire design team and leadership to discuss strategies and form directions for design and manufacturing activities. DFSS eventually becomes the language of all design discussions, trade-offs and activities, from product conception through product launch and support.
Program Deployment Concerns
Deploying DFSS at a large company requires full support from the company CEO and presidents, full embracement by engineering and strong expectations from the chief technical officer, engineering vice presidents and engineering leaders. Any deployment strategy that does not include expectations from those individuals will not succeed.
If engineering leadership is not 100% behind the deployment, most engineers will immediately sense managements reluctance to engage and will subsequently view DFSS in the same noncommitted manner. This is a major reason DFSS deployment from inside the quality department or organization will not usually work. It must be owned by engineering.
In addition, DFSS deployment must include integration of expectations into current design processes, with strong applications to product design. DFSS projects cannot be viewed as traditional Six Sigma projects because they require participation from the entire design team and usually take significant time to complete (for example, gas turbines are not designed in a month).
Some companies make an individual assigned to a development project responsible for DFSS on that program. This is convenient for engineering because everyone else can continue work as usual. But the person responsible for DFSS on the program is responsible for application successan obvious recipe for failure.
DFSS requires engineering to fundamentally change how it views and approaches the design of a product. Following the DFSS process will quickly show engineerings knowledge or lack of knowledge about the products it is designing with regard to predictability of performance, design margins and manufacturing capability influences on product performance.
Understandably, this can lead to some resistance among the engineering staff because it is challenged to completely disclose to the entire design team how much engineers really know about their designs. This is usually a real eyeopener for the design team: Working together closely is required to produce a high quality product. The development of products truly becomes a cross functional approach to design, with strong interfaces between engineering, manufacturing, product planning, marketing and management.
DFSS is so much more than mere training. Training is a start of the journey, but DFSS requires engineers to do things differently with regard to their designs. Training must be followed with strong project mentoring and assistance with requirements development, CTQ flow down, model creation, analysis techniques, optimization of design margins and assessment of general progress throughout the product development process.
DFSS must be immediately applied to product development to understand where the gaps are in an organizations ability to engineer products. Every engineer should be engaged and doing his or her part of the design from a DFSS perspective.
Mentoring is extremely important, and engineers with a good understanding of DFSS principles and a strong design engineering background must provide any training and mentoring to engineers, who will not respect being mentored by experts in statistics with no knowledge of their design engineering tasks.
Finally, DFSS will require improvements to engineerings infrastructure in terms of modeling capability, simulation tools, systems engineering capability, requirements management approach and tools, access to relevant data and common methods to review product designs.
One of the many hidden benefits of DFSS is that applications to product design will quickly identify weaknesses in engineerings infrastructure. It becomes very easy to assess an organizations ability to succeed in DFSS and suggest what infrastructure improvements are necessary to plug the gaps to take advantage of the DFSS process.
Prior to engaging in a DFSS program, a company and its engineering staff must understand DFSS is a journey that requires many skills and tools to be successful and may require significant changes to engineerings overall capability to design products. Correcting engineering weaknesses identified through the DFSS process can transform a companys engineering department or organization into a highly efficient and leading one.
With the proper commitment and the correct systems engineering approach, DFSS will pay off significantly in terms of reduced development cycle times, higher product quality, reduced life cycle cost and improved customer satisfaction. The only question becomes, does a company have the dedication over the long term to challenge its engineers, openly view and address its weaknesses, understand its limitations and eventually transform itself into a well-respected, world-class organization?
If you liked this article, subscribe now.
(1) Member Reviews