Insight: The Toyota Product Development System’s Implementation Challenges

For conducting business in the U.S. market, Toyota has historically had several separate business entities: a sales and distribution company headquartered in California (Toyota Motor Sales, USA); manufacturing operations (Toyota Motor Manufacturing North America); a racing subsidiary (Toyota Racing Development, USA); the Toyota Technical Center for R&D in Ann Arbor; and a design facility in California (Calty Design Research, Inc.). On April 1, 2006, Toyota merged its R&D operations and its manufacturing operations into a single company. While this might be perceived as an efficiency move primarily designed to reduce administrative overhead, the reality, however, is that it was motivated by Toyota’s intention to do more vehicle development in the U.S. Under the Toyota Product Development System (TPDS), extremely close collaboration between R&D and manufacturing is the norm. Toyota’s move is designed to assure that the two functions are under common leadership as Toyota moves to implement an integrated version of its product development system in the North American market.

In the January, 2006, issue, we took a quick look at the Toyota Product Development System (TPDS) and the extraordinary levels of efficiency it achieves in the development process—approximately four times that of the typical North American auto company. Let’s dig a bit deeper into this system and look at the challenges that implementation presents to automotive suppliers.

Suppliers that are more advanced in their implementation of the Toyota Production System (aka “lean manufacturing”) will generally have an easier time implementing the TPDS than other suppliers. In advanced lean facilities you will typically find some of the key cultural infrastructure in place that is critical to the “learning organization” orientation that is the underpinning of the TPDS. Nevertheless, there are still substantial challenges most suppliers, even those with more advanced lean systems, will face when they move to implement the Toyota Product Development System. Some of these key challenges involve:

• A new approach to engineering leadership—A rethinking of engineering management roles and skill sets.
• A new approach to knowledge management—New systems for storing, accessing and using engineering data.
• A new approach to design variations—Implementation of set-based concurrent engineering.
• A new approach to the development process—Less focus on process standards and more focus on product standards and design results.
• A new organizational design—Creation of the “Big Room” and use of visual mana-gement for the development process.

ALIGNING AUTHORITY WITH KNOWLEDGE, AND MANAGEMENT WITH “TEACHING.” In the Toyota system, authority derives from knowledge, especially technical knowledge. The product development managers are those who are the most technically competent in engineering. Their function as managers is to “teach”—to educate by asking the “Five Whys.” This set of expectations conflicts with the culture in many North American supplier organizations, where authority often derives from organizational politics and is perceived as the power to “tell people what to do.” It is rare in the American engineering culture to find a combination of technical competence, humility and operational discipline in the same individual. It takes time to cultivate this kind of talent, and requires a reworking of human resources, organizational development and compensation systems. 

GETTING SERIOUS ABOUT KNOWLEDGE MANAGEMENT. TPDS utilizes a highly disciplined knowledge management system that: (1) standardizes the way engineering data on design options is stored; (2) makes the data available to everyone working on development; and (3) sets the expectation that each engineer is familiar with the data on related development work done by others in the organization. Key technical data is stored in the form of “tradeoff curves” that show the relationship between paired performance variables for a particular design option. This level of discipline on engineering knowledge management is absent in most North American suppliers. There are enormous levels of waste incurred because engineers “reinvent” a product each time they reengineer it. Simply finding data on previous versions is often an impossible task. (This is made more difficult by the often rapid turnover of engineers on the development team.)

Implementation of a knowledge manage-ment system requires:

• Development of standardized formats for data collection.
• Creation of an electronic system for storing and organizing the data in a way that is easily accessible by other engi-neers and development team members.1
• Setting the disciplined expectation that engineers use the database in their development work.
• Rewarding the “reuse” of prior engineer-ing work. This means eliminating the “culture of reinvention” where a “Not Invented Here” mentality drives engi-neers to want to do everything de novo.

IMPLEMENTATION OF “SET-BASED CONCUR-RENT ENGINEERING.” The use of tradeoff data and the availability of a sophisticated knowledge management system supports Toyota’s different approach to managing design variations. Instead of locking in early in the design process to a single design variation, multiple alternatives are created for each sub-component, with the choices between the alternatives made based on their performance against the tradeoff variables.2

A system like this can only be implemented with a sophisticated knowledge management system in place. Without it, there is no way to manage the complexity of the information needed to make the choices between the multiple combinations of options. Like all knowledge management systems, this requires several years to put in place. Domestic suppliers will need to make a long-term commitment to putting the necessary systems in place before they can reap the productivity benefits of such a system.

FROM PROCESS STANDARDS TO PRODUCT STANDARDS. It is surprising to many observers that Toyota has relatively low levels of detail in its product development process standards. Instead, the focus is on product, not process, documentation. The process is managed by a “pull” system of “key integrating events” established by the chief engineer. The focus of the integrating events is on the product performance standards. The teams responsible for those standards set their own schedules for delivering “on time.” After many years of being driven to implement more detailed and disciplined development processes (enabled, in part, by systems such as the APQP and PPAP standards), it is somewhat counterintuitive for auto suppliers to back away from detailed process procedures. The process discipline is replaced in the Toyota system by a product discipline based on its knowledge management system and set-based engineering.

OUT OF OUR “RABBIT HOLES” AND INTO THE “BIG ROOM.” The last significant cultural shift that suppliers need to make in the implementation of the TPDS is to break down the barriers between the functions involved in the product development process. The symbol for this in the Toyota system is the “Big Room.” In the tradition of “glass wall management” the typical closed offices for bosses and cubicles for other workers is converted into a large open space (the “Big Room”). The organizational leader has a desk with no walls near the center of the room; teams organized by product family are clustered around the center; and the walls are used for visual management of the development process.3 The visuals on the walls are not for decoration—they are used for day-to-day management of the development process, and all of the information is absolutely expected to be up to date. If an engineer wants to know the status of any sub-stage of a process, they simply wander over and look at the graphics on the wall. No time-consuming emails or phone calls are required.

THE SYSTEMS APPROACH
You cannot implement “pieces” of TPDS and expect to get significant performance improvements. Like all serious management innovations, it is a system that depends on the mutual interaction between its different components. You can’t implement set-based engineering without a serious knowledge management system; integrated development processes are hard to make happen if you haven’t broken down compartmentalization through the implemen-tation of the “Big Room”; and none of this can happen effectively without a new culture of engineering management. This, of course, means that if you want to implement it in your company, you need to be com-mitted to it for the long haul, and ready to make substantial cultural and operational changes in your business. But then a 300% improvement in product development efficiency is probably worth that kind of effort, don’t you think?