Six Sigma and the Evolution of Quality. In Product Development

Transcription

1 Six Sigma and the Evolution of Quality In Product Development By Larry R. Smith Manager, Heritage Supplier Quality Ford Motor Company Rouge Office Building Room 3108, Mail Drop R Miller Road Dearborn, Michigan Phone: Fax: or

2 Abstract George Box had it right when he said, All models are wrong but some are useful. Nam Suh, Chairman of the Mechanical Engineering Department at MIT, developed a very useful model of Product Development as a mapping of elements between various domains (customer attributes to functional requirements to design parameters to process variables). Peter Senge, also of MIT, developed a useful model concerning ways or levels of thinking (in terms of events, patterns, or structure). When these two models are combined, a new model is created that can be used to understand the history and evolution of quality, and the role of Six Sigma and for Six Sigma in product development. Quality in product development began with attempts to inspect quality into products or services either in the process domain (scrap and rework), the design domain (verification tests and durability failures), or the customer domain (warranty costs and complaints). The evolution of quality involved a significant mindset transition from reacting to inspection events to utilizing process patterns in engineering and manufacturing to build quality into the product. Recent developments in quality engineering involve use of structural tools to lay the proper foundation for good design and enable the process-level" methods to work better. Six Sigma is used to react to or fix unwanted events in the customer, design, or process domains. for Six Sigma is used to prevent problems by building quality into the design process across domains at the pattern level of thinking. Use of new "structural" tools such as and Axiomatic provide a foundation for future enhancement of Six Sigma methodologies. Key Words Product Development, Six Sigma, for Six Sigma, Axiomatic,, Parameter A Model of Product Development The process of design involves understanding what you want to achieve, and then selecting a strategy that achieves that intent. To better understand the history of quality and the role of Six Sigma in product development, consider the domain model of product development shown in Figure 1. Nam Suh, Chairman of the Mechanical Engineering Department at MIT, created this model, applicable to the development of either products or services, in the late 1970's (Suh, 1990). Attributes Requirements Parameters Variables Figure 1: Nam Suh s Model of Product Development (from Suh, N. P., 2001, reprinted with permission)

3 Suh believes that the creation of great products or services involves selecting strategies associated with four primary activities or domains: the customer domain, the functional domain, the physical domain, and the process domain. The customer domain consists of customer attributes, a characterization of needs, wants, or delights that define a successful product or service from a customer perspective. The functional domain consists of functional requirements, a characterization of design goals or what the product or service must achieve to meet customer attributes from the viewpoint of the designer. The physical domain consists of design parameters, the collection of physical characteristics or activities that are selected to meet functional goals. The process domain consists of process variables, the collection of process characteristics or resources that create the design parameters. The development of products or services is highly iterative and involves selecting elements in each domain and mapping these elements from one domain to another. The better the mapping between these domains, the better the design. Figure 2 illustrates the generic nature of this model, which is applicable to literally any design activity. Figure 2: The Concept in Various Fields Field Manufacturing Consumer needs/wants specifications Parameters Variables Materials Desired Performance Required Properties Microstructure es Software Organization Systems Attributes Satisfaction System Attributes Output Organization Functions System Requirements Input Variables/ Algorithms Programs, Offices Components, Machines Sub-routines People, Resources Resources (from Suh, N. P., 2001, reprinted with permission) The evolution of design is correlated with the evolution of our thinking. Peter Senge, a professor at MIT s Sloan Management school, describes three levels of thinking: events, patterns, and structure (Senge, 1990). The event level of thinking is all too familiar. Something happens; we find out about it after the fact and are forced to react. Organizations typically react to significant short-term events in measures such as sales, profits, quality, etc. Pattern thinking involves understanding longer-term trends and assessing implications. For example, a graph of U.S. automotive market shares for Japanese, Korean, and German automobile companies over the past decade is an interesting pattern that should not be ignored by U.S. automakers. Structure thinking involves looking at the total system to understand how system elements relate to each other, and what in the system causes the patterns to behave the way they do. Figure 3 overlays Senge s levels of thinking onto Suh s domain model of product development. This figure provides a convenient framework for thinking about the evolution of quality and the role of Six Sigma.

4 Structure Patterns Events Figure 3: Senge s Levels of Thinking Overlayed on Suh s Model of Product Development The History and Evolution of Quality The early history of quality in Product Development was based upon event thinking in the various design domains (see Figure 4). Structure Patterns Events Warranty, Complaints Verification Tests Inspection & Scrap/ Rework Figure 4: Event Thinking in s After WWII, the primary way of assuring quality to customers was inspection after the process domain. Parts were produced, and then these parts were checked to see if they were good enough to ship. If the parts were not good, then an event occurred, resulting in rework or scrap, and problem solving. Event thinking also occurred in the physical domain. Many engineers simply threw a design together and then tested it, expecting the design to fail. The failure of a design verification test is an event that the engineers answered with a sequence of build/test/fix cycles. Build/test/fix is actually a method used today

5 by many designers to inspect quality into the product or service. Hopefully, the design gets band-aided enough so that it will function properly before the product or service gets to the customer. Otherwise, the inevitable result is consumer complaints and warranty in the customer domain. Unfortunately, many companies today depend upon event thinking to assure quality to customers. These companies learn about customers through analysis of warranty, try to assure design integrity via batteries of expensive reliability tests, and rely on checks after assembly to assure that the product is good enough to ship. At a company like GE, the cost of quality associated with event thinking in 1996 was estimated to be as high as ten billion dollars each year in scrap, reworking of parts, correction of transactional errors, inefficiencies, and lost productivity (Harry and Schroeder, 2000). Event thinking companies, who typically operate at a sigma level between 3 and 4, reap huge benefits by implementing Six Sigma. Six Sigma is an effective problem-solving methodology and companies can utilize Six Sigma to recoup a portion of their cost of quality. Black Belts, who target projects based on warranty costs, test/durability failures, and manufacturing scrap/rework/productivity issues, save, on average, $230,000 per project (Harry and Schroeder, 2000). Pattern-level thinking was seriously introduced to product development when W. Edwards Deming, Joseph M. Juran, and others were invited to Japan shortly after WWII. In 1950, Mr. Ichiro Ishikawa, president of The Union of Japanese Scientists and Engineers, arranged for Dr. Deming to meet with the twenty-one top management executives of Japanese industry and lecture about quality. Dr. Deming began by introducing some ideas he had learned from Dr. Walter Shewhart, specifically the Plan-Do- Study-Act cycle of learning and Statistical Control (SPC). SPC, a pattern-level quality method in the process domain, focuses on patterns or trends in process data, so that the process can be adjusted before an inspection event occurs. When Japanese companies began to implement SPC, quality improved dramatically. For the first time, product or design engineers knew that the parts they designed were being manufactured according to print. Companies begin to use Six Sigma at the pattern level when they target Six Sigma for variation reduction in the process domain at their own and at supplier facilities. Use of Six Sigma in this way can transition a company to sigma levels between 4 and 5. At a level of about 5 sigma, companies hit a wall and progress comes to a standstill. Further improvement requires use of pattern thinking in the customer, functional, and physical domains, as well as in the process domain. Use of pattern-level thinking in the other design domains began when Dr. Kaoru Ishikawa, known for Ishikawa diagrams and formalization of QC-Circles, noticed that even though parts were being made to print, customers were still unhappy with the products (Ishikawa, 1977). Specifications and tolerance limits were state d in the drawings. Measurements and chemical analysis were being performed. Standards existed for all these things and the standards were being met, but these standards were created without regard to what the customer wanted. Dr. Ishikawa wrote, When I ask the designer what is a good car, what is a good refrigerator, and what is a good synthetic fiber, most of them cannot answer. It is obvious that they cannot produce good products. You simply cannot design a good product or service if you do not know what "good" means to a customer. Ishikawa encouraged people to think at the pattern level in the customer domain, instead of just reacting to a warranty event. He said that if you don't know what a "good" product is, ask your customers. s will give you what Ishikawa called, the "true quality characteristics." The problem with "true quality characteristics" is that the designer cannot directly use them. For example, a customer may want the steering of an automobile to be "comfortable." An engineer cannot write on a drawing, "make the steering comfortable." The engineer must find "substitute quality characteristics," dimensions or characteristics of the design that are correlated with customer desires but have meaning to an engineer. Therefore, Ishikawa said that the designer must create a map that moves from the "world of the customer" to the "world of the designer." He used a tree diagram to create such a map and called these maps "quality tables." The Kobe Shipyard of Mitsubishi Heavy Industries created

6 the first quality table in Once the quality table was completed, Ishikawa felt the designer had a customer-driven definition of a good product or service. This definition or function of quality could then be deployed into the product development activity. Thus was Quality Function Deployment (QFD) born. In subsequent years, about 120 different quality tools and methods have been created at the pattern level for designers to manage product development process trends, making inspection "events" a non-event. Some of the most popular and powerful of these methods are shown in Figure 5 and, in addition to SPC and QFD, include: Failure Mode and Effects Analysis (FMEA) for both the product and process domains, Dr. Genichi Taguchi's methods of Parameter (for the product and process domains) and Tolerance (for the product domain), for Assembly (DFA) and for Manufacturing (DFM), which improve the mapping from the product to the process domain; and System Engineering, Value Analysis (VA), and Value Engineering (VE) in the functional domain. Structure Patterns Events QFD Warranty, Complaints VA/VE Systems Engineering FMEA Parameter & Tolerance Verification Tests DFM DFA SPC Inspection & Scrap/ Rework Figure 5: Pattern Thinking in the Various s The transition from "event" thinking to "pattern" thinking is the transition from "find and fix" to "prevent." In the words of Henry Wadsworth Longfellow, "It takes less time to do a thing right than it does to explain why you did it wrong." So then why not do it right the first time? The payoff in warranty savings, customer satisfaction, and productivity more than offset the relatively modest investment in "longer-term" thinking. The transition from event thinking to pattern thinking is also the transition from Six Sigma to for Six Sigma. Companies who rely on event thinking and utilize Six Sigma realize that about eighty percent of the problems they are fixing (and the money they are saving) are determined by design. for Six Sigma (Harry and Schroeder, 2000) is a rigorous approach to designing products and services from the very beginning to ensure that they meet customer expectations. for Six Sigma is an integration all of the prevent quality tools across the pattern-level" domains. Use of for Six Sigma results in sigma levels between 5 and 6. Further improvement requires implementation of structural thinking tools. Thinking at a level of fundamental structure offers even higher-leveraged opportunities to create products and services that not only function as intended, but also deliver unprecedented customer satisfaction. When the foundational structure of design is properly established, the methods at the pattern level are much more effective. When pattern-level methods work well, the event outcomes become world-class.

7 In the evolution of quality, two very powerful design methods have emerged at the structural level: Axiomatic and (see Figure 6). Structure Directed Evolution Axiomatic Axiomatic Patterns Events QFD Warranty, Complaints VA/VE Systems Engineering FMEA Parameter & Tolerance Verification Tests DFM DFA SPC Inspection & Scrap/ Rework Figure 6: Quality Evolution in the Various s Axiomatic is the result of work by Nam Suh. In the late 1970 s, he asked himself the question, Can the field of design be scientific? Suh wanted to establish a theoretical foundation for design by identifying the underlying principles or axioms that every great design must have in common. He knew that he could never prove that these principles were true, but could he find a set of principles for which no one could find a counterexample? After a decade of work, two principles emerged. From these two principles, theorems and corollaries could be derived that, together, form a scientific basis for the structure of great design. The first principle that Suh discovered was the principle of independence. Consider Suh s domain model shown in Figure 1. Mapping between domains represents a mapping of whats to hows. The principle of independence states that in great designs, the hows are chosen in such a way that the whats maintain independence. For example, design parameters must be chosen in such a way that functional requirements maintain independence. Consider the water faucet designs shown in Figure 7. The functional requirements for a water faucet are two: control the flow rate and control the water temperature. The faucet on the left of Figure 7 has two design parameters: a hot water knob and a cold water knob. What is the relationship between these design parameters and the functional requirements? When the hot water knob is turned, temperature is affected and so is flow. Turning of the cold water knob also affects temperature and flow. Therefore this design is coupled and the functional requirements are not independent. If a consumer has optimized flow rate, then turns one of the knobs to optimize temperature, the flow rate is changed and is no longer optimal. s of this type eventually satisfy customers by iterating between the two design parameters. Consider the design on the right of Figure 7. This faucet has one handle and the design parameters are: lift the handle to adjust flow, and move the handle from side-to-side to adjust temperature. In this design, adjusting temperature does not affect flow, and adjusting flow does not affect temperature. From an Axiomatic point of view, this design is superior because the functional requirements maintain independence. Imagine what happens when a designer is working in a situation with a dozen or more functional requirements. If the design is coupled, then optimization of one function may adversely impact

8 several other functions. When these functions are fixed, the original function no longer works well. The designer is always tuning and band-aiding such a design and the customer will never be completely happy. However, if the design is created in such a way that each of the functional requirements is handled independently by the design parameters, then each function of the design can easily be optimized with pattern-level tools. Functions for water faucet: FR1=Control flow rate FR2=Control temperature 1: DP1=Hot water knob DP2=Cold water knob 2: DP1=Handle Lifting DP2=Handle Moving side-to-side Figure 7: Water Faucet Example The principle of independence can be used to evaluate how good a design will be when the design is still on paper! But suppose you have two design alternatives that both follow the independence axiom. Now which one is better? The second principle states that the better design will minimize the information content necessary for implementation (see Suh, 2001 for examples). s that have a solid axiomatic foundation simply work better than designs that do not. Suppose the designer cannot find a set of design parameters that keep all the functional requirements independent. In this situation, improving one function typically degrades another. An example in automotive steering is steering road feel and parking efforts. When the steering efforts are high, the customer experiences good road feel. However, high efforts can make it difficult for customers to park. Adjusting efforts to make the vehicle easy to park will result in degraded road feel. A typical approach to resolve this situation is compromise trade off customer functionality and hope for the best. This is where is most helpful., a Russian acronym for Theory of Inventive Problem Solving, is the result of over forty-five years of research by Genrich Altshuller and colleagues (Altshuller, 1998). Altshuller hated compromise. He called the situation where functions oppose each other contradictions and developed a methodology where design teams could systematically innovate and find design parameters that resolved contradictions, creating win-win functional situations. The methodology began by identifying all possible contradictions that existed in patent databases, and identifying how these contradictions were resolved. Altshuller found that only a few particular principles of resolution have been used in the history of mankind to resolve certain pairs of functional

9 contradictions. For example, suppose the functions of weight and reliability contradict. When the design is changed to improve reliability, weight increases. When weight is decreased, reliability degrades. Altshuller found that there are only four principles that are essentially used to resolve this contradiction (see Altshuller, 1998). He created a matrix of contradictions and resolution principles and used this information to guide design teams so that they could brainstorm in areas that are likely to lead to winwin solutions. Altshuller also believed in minimizing information content; this he called the principle of ideality. Later, was expanded to include an entire algorithm of innovation techniques, including the study of system evolution. Altshuller found that systems tend to evolve along specific laws and lines of evolution. By studying system evolution for the past and present (for the super-system, system, and sub-system), a designer can identify the current stage of system evolution. By applying laws and lines of evolution, design teams can predict what the next developments of the system will be. This is a huge competitive advantage. Companies that operate at the event level obtain information about the customer through warranty data. Companies at the pattern level interact with customers and find out what customers believe is important today. No customer can tell the designer what will be important tomorrow. At the structural level, directed evolution predicts what will be important to customers tomorrow! So if works at the structural foundation of design, why does the name imply problem solving? The answer is simply that higher-level thinking can always be used as a methodology to solve lower-level problems. The fact that problems exist in the event realm means that the original process of design had serious flaws -- pattern or structural work that should have been done is either missing or incomplete. The designer can always go back and complete this work at any time. This is why completing work associated with pattern or structural tools can quickly lead to problem resolution. A good example of this is Six Sigma. Six Sigma addresses problems created by event-level" thinking, but the methodology of Six Sigma utilizes pattern-level" tools such as FMEA. The Roles of Six Sigma and for Six Sigma The product development model in Figure 6 is useful to illustrate the roles of Six Sigma and for Six Sigma, and also provides implications for next steps. The role of Six Sigma is to solve problems at the event level in the customer domain (customer complaints or warranty), the product domain (design or service does not pass tests), or the process domain (internal scrap, rework, or capability issues). An effective Six Sigma program, even though this program saves lots of money, is still an attempt to inspect-in quality by addressing events after the fact. A company that operates only at this level will never be competitive with a company that prevents problems in the first place using for Six Sigma. The role of for Six Sigma is to build quality into the design by implementing prevent thinking and tools in the product development process. for Six Sigma is, in fact, an integration of prevent methods at the pattern level across all four domains. The relative roles of Six Sigma and for Six Sigma in product development are shown in Figure 8. An effective for Six Sigma program must utilize tools that make a difference in each design domain. For example, a for Six Sigma program that does not interface with customers or does not utilize powerful methods like Taguchi s parameter design (to hit the design with noise or uncontrolled variation, and adjust controllable factors in the design to make the design robust against noise ) is a program that is guaranteed to leave significant portions of the work of design incomplete. This will virtually guarantee that the Six Sigma program will have plenty of issues to work on in the future.

10 Structure Directed Evolution Axiomatic Axiomatic Patterns Events QFD Warranty, Complaints VA/VE Systems Engineering FMEA Parameter & Tolerance Verification Tests DFM DFA SPC Inspection & Scrap/ Rework for Six Sigma Six Sigma Both Six Sigma and for Six Sigma can be made more effective by incorporating structural tools such as Axiomatic and into the methodology. Because these tools address design foundation flaws, they will enhance every aspect of Six Sigma and for Six Sigma, making the process of problem solving and problem prevention much more insightful, productive, and efficient than programs that do not utilize these methods. Conclusion Quality tools and methods have evolved utilizing three stages of thinking (event, pattern, and structure) across various domains associated with product development. The evolution of Six Sigma parallels the evolution of quality methods. Six Sigma addresses event-level concerns that occur in product development after the fact. for Six Sigma represents a higher evolution of the methodology, utilizing pattern-level" thinking and tools to build quality into the product or service. The future of Six Sigma and for Six Sigma involve incorporation of structural thinking methods such as Axiomatic and. Use of these methods will make Six Sigma and for Six Sigma more effective and more productive with less effort. Companies who wish to accelerate development of their own quality programs can utilize the evolutionary trends explained in this paper to understand their current level of evolution and to implement focused actions that can quickly move them past their competition. References Figure 8: Focus of Six Sigma and for Six Sigma Altshuller, G. 40 Principles: Keys to Technical Innovation, Worchester, MA: Technical Innovation Center, Harry, M. and Schroeder, R., Six Sigma, New York: Doubleday, Ishikawa, K. Quality Analysis, 1977 ASQC Conference Transactions Philadelphia, pg Senge, Peter M. The Fifth Discipline, New York: Doubleday, Suh, Nam P. The Principles of, New York: Oxford University Press, Suh, Nam P. Axiomatic : Advances and Applications, New York: Oxford University Press, 2001.