Toyota’s Principles of Set-Based Concurrent Engineering
How Toyota’s product design and development process helps find the best solutions and develop successful products.
Topics
Toyota Motor Corporation is an industry leader in product development lead time while using fewer engineers than its U.S. competitors. It has also shown remarkable consistency in market share growth and profit per vehicle, which led to cash reserves of $21 billion, exceeding those of the “Big Three” automakers combined.1 The Toyota Production System (TPS), dubbed “lean manufacturing,” has been critical in these accomplishments,2 but we believe that Toyota’s product design and development system is also an important contributor.3
While Taiichi Ohno and others have meticulously described the TPS, the Toyota development system has not been well documented.4 Indeed, Toyota does not use many of the practices often considered critical to successful concurrent engineering and associated with Japanese manufacturers. Its development teams are not colocated. Personnel, with the exception of the chief engineer and his staff, are not dedicated to one vehicle program. Cross-functional job rotation is unusual for the first ten to twenty years of an engineer’s career. Engineering and test functions rarely use quality function deployment (QFD) and Taguchi methods. Toyota excels at value engineering (VE) and value analysis (VA), yet Toyota engineers say they do not use any of the text-book tools and matrices for VE or VA. And there is nothing remarkable about Toyota’s CAD or CAE systems. These practices, then, do not explain Toyota’s effectiveness in developing new vehicles.
In a previous article, we called Toyota’s product development system the “second Toyota paradox.”5 TPS was the first; its features seem wasteful but result in a more efficient overall system, such as changing over manufacturing processes more frequently (presumably inefficient) in order to create short manufacturing lead times. The second paradox can be summarized in this way: Toyota considers a broader range of possible designs and delays certain decisions longer than other automotive companies do, yet has what may be the fastest and most efficient vehicle development cycles in the industry.
Traditional design practice, whether concurrent or not, tends to quickly converge on a solution, a point in the solution space, and then modify that solution until it meets the design objectives. This seems an effective approach unless one picks the wrong starting point; subsequent iterations to refine that solution can be very time consuming and lead to a suboptimal design.
References
1. A. Taylor III, “How Toyota Defies Gravity,” Fortune, volume 136, 18 December 1997, pp. 100–108.
2. J.P. Womack, D.T. Jones, and D. Roos, The Machine That Changed the World (New York: HarperPerennial, 1990).
3. Taylor (1997).
4. T. Ohno, Toyota Production System: Beyond Large-Scale Production (Portland, Oregon: Productivity Press, 1988); and S. Shingo, A Study of the Toyota Production System from an Industrial Engineering Viewpoint (Cambridge, Massachusetts: Productivity Press, 1989).
5. A.Ward, J. Liker, J. Cristiano, and D. Sobek, “The Second Toyota Paradox,” Sloan Management Review, volume 36, Spring 1995, pp. 43–61.
6. M. Iansiti, “Shooting the Rapids: Managing Product Development in Turbulent Environments,” California Management Review, volume 38, Fall 1995, pp. 37–58; and G. Kalyanaram and V. Krishnan, “Deliberate Product Definition: Customizing the Product Definition Process,” Journal of Marketing Research, volume 34, May 1997, pp. 276–285.
7. The first phase of automotive development is usually the design of the vehicle styling by industrial designers.
8. R.P. Smith and S.D. Eppinger (a), “A Predictive Model of Sequential Iteration in Engineering Design,” Management Science, volume 43, August 1997, pp. 1104–1120.
9. M.A. Cusumano, “How Microsoft Makes Large Teams Work like Small Teams,” Sloan Management Review, volume 39, Fall 1997, pp. 9–20; and M.A. Cusumano and R.W. Selby, “How Microsoft Builds Software,” Communications of the ACM, volume 40, June 1997, pp. 53–61.
10. C. Terwiesch, C.H. Loch, and A. DeMeyer, “A Framework for Exchanging Preliminary Information in Concurrent Development Processes” (San Diego, California: University of California, working paper, 1997).
11. K.M. Eisenhardt and B.N. Tabrizi, “Accelerating Adaptive Processes: Product Innovation in the Global Computer Industry,” Administrative Science Quarterly, volume 40, March 1995, pp. 84-10.
12. J.K. Liker, D.K. Sobek II, A.C. Ward, and J.J. Cristiano, “Involving Suppliers in Product Development in the United States and Japan: Evidence for Set-Based Concurrent Engineering,” IEEE Transactions on Engineering Management, volume 43, May 1996, pp. 165–178; and Ward et al. (1995).
13. H.R. Buhl, Creative Engineering Design (Ames, Iowa: Iowa State University Press, 1960); and D.H. Edel, ed., Introduction to Creative Design (Englewood Cliffs, New Jersey: Prentice-Hall, 1967).
14. S. Pugh, Total Design (Reading, Massachusetts: Addison-Wesley, 1991).
15. K. Ulrich and S. Eppinger, Product Design and Development (New York: McGraw-Hill, 1995); S.C. Wheelwright and K.B. Clark, Revolutionizing Product Development (New York: Free Press, 1992); and F.A. Dubinskas, “Modeling Cultures of Project Management,” Journal of Engineering and Technology Management, volume 10, June 1993, pp. 129–160.
16. S. Bhattacharya, V. Krishnan, and V. Mahajan, “Managing New Product Definition in Highly Dynamic Environments” (Austin, Texas, University of Texas, working paper, 1997); Eisenhardt and Tabrizi (1995); Iansiti (1995); and Kalyanaram and Krishnan (1997).
17. S.H. Thomke, “The Role of Flexibility in the Development of New Products: An Empirical Study,” Research Policy, volume 26, March 1997, pp. 105–119.
18. Iansiti (1995).
19. Ibid; and Bhattacharya et al. (1997).
20. K.B. Clark and T. Fujimoto, Product Development Performance (Boston: Harvard Business School Press, 1991). See also: R.L. Daft and R.H. Lengel, “Organizational Information Requirements, Media Richness and Structural Design,” Management Science, volume 32, May 1986, pp. 554–571.
21. J.K. Liker, R.R. Kamath, S.N. Wasti, and M. Nagamachi, “Integrating Suppliers into Fast-Cycle Product Development,” in J.K. Liker, J.E. Ettlie, and J.C. Campbell, eds., Engineered in Japan: Japanese Technology-Management Practices (New York: Oxford University Press, 1995), pp. 152–191.
22. K.N. Otto and E.K. Antonsson, “Tradeoff strategies in Engineering Design,” Research in Engineering Design, volume 3, number 2, 1991, pp. 87–103; A. Ward, T. Lozano-Perez, and W. Seering, “Extending the Constraint Propagation of Intervals,” Artificial Intelligence in Engineering Design, Analysis, and Manufacturing, volume 4, January 1990, pp. 47–54; W.W. Finch, “Predicate Logic Representations for Design Constraints on Uncertainty Supporting the Set-Based Design Paradigm” (Ann Arbor, Michigan: University of Michigan, Ph.D. dissertation, 1997); A.C. Ward, “A Formal System for Quantitative Inferences of Sets of Artifacts” (Colorado Springs, California: Proceedings of the First International Workshop on Formal Methods in Engineering Design, Manufacturing, and Assembly, 1990); and K.L. Wood, K.N. Otto, and E.K. Antonsson, “Engineering Design Calculation with Fuzzy Parameters, Fuzzy Sets and Systems,” Fuzzy Sets and Systems, volume 52, November 1992, pp. 1–20.
23. R.P. Smith and S.D. Eppinger (b), “Identifying Controlling Features of Engineering Design Iteration,” Management Science, volume 43, March 1997, pp. 276–293.
24. M. Tushman and R. Nelson, “Technology, Organizations and Innovation: An Introduction,” Administrative Science Quarterly, volume 35, March 1990, pp. 1–8; and P. Anderson and M. Tushman, “Technological Discontinuities and Dominant Designs: A Cyclical Model of Technological Change,” Administrative Science Quarterly, volume 35, December 1990, pp. 1–8.
25. Anderson and Tushman (1990).
26. R. Nelson and S. Winter, An Evolutionary Theory of Economic Change (Cambridge, Massachusetts: Harvard University Press, 1982).
27. Ibid.
28. For an in-depth look at the Toyota system, see: D.K. Sobek II, “Principles That Shape Product Development Systems: A Toyota-Chrysler Comparison” (Ann Arbor, Michigan: University of Michigan, Ph.D. dissertation, 1997); and D.K. Sobek II, J.K. Liker, and A.C. Ward, “Another Look at How Toyota Integrates Product Development,” Harvard Business Review, volume 76, July–August 1998, pp. 36–49.
29. R.R. Kamath and J.K. Liker, “A Second Look at Japanese Product Development,” Harvard Business Review, volume 72, November–December 1994, pp. 154–173.
30. Clark and Fujimoto (1991).
31. Sobek et al. (1998).
32. Ward et al. (1995).
33. This Toyota practice is remarkably consistent with Funk’s finding that a key learning tool in Japanese product development organizations is decentralized groups studying, standardizing, and documenting processes and designs, then making the documentation publicly available to development team members. Engineering checklists are also consistent with observations of numerous researchers on organizational learning in Japanese companies. See: J.L. Funk, “Japanese Product Development Strategies: A Summary and Propositions about Their Implementation,” IEEE Transactions on Engineering Management, volume 40, August 1993, pp. 224–236; K. Imai, I. Nonaka, and H. Takeuchi, “Managing the New Product Development Process: How Japanese Companies Learn and Unlearn,” in K.B. Clark, R.H. Hayes, and C. Lorenz, eds., The Uneasy Alliance (Boston: Harvard Business School Press, 1985), pp. 337–375; K. Nobeoka and M.A. Cusumano, “Multiproject Strategy, Design Transfer, and Project Performance: A Survey of Automobile Development Projects in the U.S. and Japan,” IEEE Transactions on Engineering Management, volume 42, November 1995, pp. 397–409; and I. Nonaka and H. Takeuchi, The Knowledge Creating Company: How Japanese Companies Create the Dynamics of Innovation (New York: Oxford University Press, 1995).
34. Our emphasis on subsystem exploration is crucial. Toyota engineers explore the implications of a proposed system design by designing alternatives of the subsystems that make up the larger system. Only in this way can engineers truly understand the ramifications of making certain system-level decisions.
35. Some authors call this the “system design” phase of development, which is virtually nonexistent in the development systems of many U.S. companies. See: Ulrich and Eppinger (1995).
36. This based on a study by Sobek. The Chrysler development process is still undergoing significant change in how CAD technology is being used, so the process today may be more set-based. See: Sobek (1997).
37. Delphi engineers, incidentally, report considerable difficulty working with Toyota’s more set-based approach of broad guidelines and late assignment of prices.
38. Nonaka and Takeuchi (1995).
39. Finch (1997).
40. Pugh (1991); and Ulrich and Eppinger (1995).
41. S.J. Black and M. Mendenhall, “Resolving Conflict with the Japanese: Mission Impossible?,” Sloan Management Review, volume 34, Spring 1993, pp. 49–58.
42. Of course, in reality, finding this intersection may require several iterations that gradually converge on the final solution.
43. The term “styling” in the automotive industry refers to the design of the exterior and interior “look” of the vehicle. Stylists are typically industrial designers, not engineers, by training.
44. Bhattacharya et al. (1997); and Kalyanaram and Krishnan (1997).
45. Ward et al. (1995).
46. P.C. Hammett, W.M. Hancock, and J.S. Baron, “Producing a World-Class Automotive Body,” in Liker et al. (1995), pp. 237–262.
47. Clark and Fujimoto (1991); and Liker et al. (1995).
48. G. Taguchi, “The Development of Quality Engineering,” ASI Journal, volume 1, Fall 1988, pp. 5–29.
49. Iansiti (1995); and Eisenhardt and Tabrizi (1995).
50. Bhattacharya et al. (1997).
51. T.S. Chang, A. Ward, J. Lee, and E.H. Jacox, “Conceptual Robustness in Simultaneous Engineering: An Extension of Taguchi’s Parameter Design,” Research in Engineering Design, volume 6, November 1994, pp. 211–222.
52. Iansiti (1995).
53. Ibid.
54. Modularity involves breaking the product into semiautonomous chunks with standard interfaces which allow different “modules” to be replaced. A good example is the personal computer. Most computers have a modular architecture that allows customers to swap out memory, monitors, hard drives, and so on without loss of functionality. See: K. Ulrich, “The Role of Product Architecture in the Manufacturing Firm,” Research Policy, volume 24, May 1995, pp. 419–440.
55. For examples, see: Smith and Eppinger (1997a) (1997b).
56. Eisenhardt and Tabrizi (1995).
57. For evidence in support of our hypothesis, see: Iansiti (1995); and Eisenhardt and Tabrizi (1995).
58. See Sobek et al. (1998).