Editor | On 01, May 1999

First presented at the Altshuller Institute Conference “TRIZCON99” March 7-8, 1999

This article includes the following two attachments:
Attachment1
Attachment2
Larry R. Smith, Ford Motor Company
Boris Zlotin, Ideation International, Inc.
Alla Zusman, Ideation International, Inc.

Abstract
Winning companies improve at a rate faster than that of their competitors. What can be done to overcome system inhibitors and accelerate change associated with quality improvement? The authors, with a team at Ford, studied this problem using TRIZ. Generic system models containing inhibitors and enablers for quality improvement were created. From these models, contradictions were formulated. Solution ideas were then generated using selected TRIZ tools. Specific insights obtained by looking at this problem with TRIZ will be discussed.

Introduction
Dr. Deming used to say, “The best thing you could do at Ford is to make your customers so happy that they begin to brag about your product to others. When it comes time to buy a new one, not only do they come back to buy yours …. they bring their neighbors with them.” This is the problem we choose to work on: “How do we design the product right the first time?” “How do we introduce into an organization like engineering, the necessary skills and methods so that changes are not needed after the drawings are released?”

The problem is generic. “How do you introduce methodology ‘XXXXX’ in an organization?”, where “XXXXX” might be Taguchi methods, TQM, QFD, or even TRIZ. “How do you accelerate the process of implementation of new, more powerful methods?” The company that implements effectively and learns the fastest will eventually win, no matter the starting competitive position.

The objectives of this study are to:

• Share an important, generic problem with others, get more people thinking
• Demonstrate how TRIZ may be utilized in a non-technical situation
• Provide an example of working with a Problem Formulator and Operators
• Provide an example of a situation related to the introduction of new engineering technology

Process
Our process steps were as follows:

1. TEAM: The first step in working with any problem is to form an effective team. Ours was one of the best and consisted of: Don Brock, Vince Hagedorn, Joseph Hughlett, Radha Krishnan, Larry Smith, Dmitry Tananko, Bill Tinney, Boris Zlotin, and Alla Zusman.

2. CREATE PROBLEM FORMULATORS: Because our problem was generic, the system, enablers, and issues we wanted to explore were well documented in literature. In particular the article, “The Barriers to Total Quality Mangement,” (Tamimi and Sebastianelli, 1998), contained comments from a sample of 188 quality professionals. We used input from this source and others (for example, Jones, 1982) to construct models of the problem. Each model mapped causal relationships (both reinforcing and balancing) between the system elements (Senge, 1991). George Box, from the University of Wisconsin, states, “All models are wrong, but some are useful.” These models are not perfect, nor do they need to be. They are, however, useful in providing a context for idea generation. The models created, shown in Attachment 1, are titled: Fire-fighting, Quality Inhibitors, Main Inhibitors, Operational Management, Developmental Management, Strategic Management, Quality System, Poor Quality Reinforcement, Short Term Drivers, Ideal Engineering I, and Ideal Engineering II.

3. CREATE PROBLEM STATEMENTS: Problem statements were generated from the problem formulator models. These statements define high leverage areas of the system, where change could redefine the system archetypes and modify system performance. These high leverage areas are contradictions, system nodes where reinforcing and balancing loops come together. Our system models and problem statements were generated with software (Ideation, 1998). Our team worked by using the software as a facilitation tool. We projected the software image onto a screen, then used the software to record our ideas and thoughts, which we could later print for everyone’s use.

4. GENERATE SUGGESTIONS: The team used the problem statements and associated Operators and examples to brainstorm ideas. The Operators we used were built into the software (Ideation, 1998), and are part of the original TRIZ methodology (Altshuller and Shulyak, 1997) that has been further enhanced with the research of Boris Zlotin and Alla Zusman. The software we used was programmed to provide the appropriate Operators for the types of contradiction in our system model. The software also provided examples of how others used these Operators. Even though the examples were technical in nature, we were able to find many parallels for a non-technical system. For example, consider the physical principle of resonance. Is it possible to “resonate” an organization with a new idea or a new way of doing things? Systematically introduce the idea at the appropriate time using a variety of inputs, to literally get the whole organization “percolating” in a metaphor of “resonance”? The Operators and examples helped to “stretch our minds” and generate “out of the box” ideas. We also used Lines of System Evolution to stimulate ideas (Ideation, 1998).

In a typical brainstorming session, the idea flow is similar to the process of popping popcorn. The ideas are slow to start, then proceed rapidly for a time, and then slowly stop. When this happens, then another example of an Operator, or a different Operator is presented for team consideration. The idea generating process then proceeds again. By using this aspect of TRIZ, we were able to develop a much richer idea stream, with a much greater number of ideas than we could have obtained by simple brainstorming. Our team continued this way until the ideas we were generating were repeats of previous ideas, and we had exhausted all the ideas that our particular group could contribute at the time.

5. INTEGRATING IDEAS INTO CONCEPTS: Our team selected approximately fifty ideas for further consideration. These ideas and some thoughts with regard to them are shown in Attachment 2. A few of these ideas were developed into a strategy proposal for presentation to Ford senior management.

Insights
Some of our team members have been thinking about this particular problem for over fifteen years. The process we used helped to better understand the situation and generated some new insights as to why it is so difficult to introduce new technology that improves the ability to “design it right the first time”:

• Fire-fighting: Reacting to events, “putting out fires” with an all-out effort at the last minute, is fun. No wonder engineers and management like to do it. In such a situation all constraints that are normal to the system disappear. The team can literally, spend whatever they want, obtain whatever resources they need, over-run budgets, take any action they like to resolve the situation. Often team members find themselves “empowered” in such a way that they display leadership qualities to senior management and later get promoted. It is a very different situation when the engineers are asked early in a program to “design it right” and “prevent problems”. In the normal system, budget constraints make it difficult to get things accomplished – it is a struggle and not fun. Is there a way to make the process of preventing problems as much fun, and as rewarding, as “putting out fires”?

• The Effort of Designing It Right: Dr. Deming used to say that, “It costs just as much to manufacture a defective part as it does to manufacture a good part.” Understanding the truth of this, and that manufacturing “bad” products is waste, drives quality improvement in the manufacturing environment. The situation is different in design. For the engineer, it is much easier to develop a poor design, and not use the new and innovative tools necessary to develop an ideal design. No one knows whether a design is good or bad until it is tested, something which happens very late in the design process (perhaps years after the design work is initially done). In addition, testing only
  identifies gross problems. The real quality of a design is not determined until real customers provide feedback, often five or ten years after the design work is completed. Is there a way to make it more difficult for an engineer to do a poor design than to do a great design?

• The Problem of Measures: In the Product Development Process, engineers and management have immediate measures relating to cost, weight, and timing. Quality and customer satisfaction estimates are just that, opinions. Since teams which present a negative opinion of their quality will receive a great deal of management attention, only good opinions are ever reported. The actual results, reported years later, never reflect the optimistic opinions of the original design team. Is there a way to make measurements relating that strongly correlate with customer quality visable to engineers and management
  real time in the Product Development Process?

Summary and Conclusions
Assisting an organization to implement new and exciting methods that produce results years later is a very difficult challenge. Use of TRIZ methodology to study this problem produced several useful insights, which help to explain why the problem is so difficult. By sharing the problem, insights, and ideas with others, we can all work together to overcome a difficult generic problem.