It would be hard to find someone in the manufacturing world who doesn’t know what the initials “TPS” stands for. The Toyota Production System is synonymous with the philosophy and practice of lean manufacturing, and is the source of most of what goes under the heading of “lean” in the automotive sector today. But how many people would know what the acronym “TPDS” stands for? Despite its obscurity, there are those who would argue that the Toyota Product Development System is more important to Toyota’s success (and therefore a more essential element of the lean philosophy) than its manufacturing system. In fact, at its deepest level, it can be argued that Toyota’s lean manufacturing system is more an extension of their product development philosophy than visa versa. And yet its core tenets are understood by only a tiny segment of the manufacturing community. Recently, several authors have begun to write on the subject, and a small number of companies have begun implementing the TPDS in conjunction with TPS.1

In order to appreciate the underlying logic of the Toyota Product Development System it is important to remember that both TPS and TPDS are reflections of Toyota’s commitment to being a learning organization. As Steven Spears and Kent Bowen noted in their path-breaking 1999 Harvard Business Review article, “Decoding the DNA of the Toyota Production System,” the essence of TPS is in a disciplined application of the scientific method to everything that happens in the manufacturing plant. What TPS does is create a “community of scientists” that is continuously conducting experiments on the production process. (“If we make the following specific changes, we expect to achieve this specific outcome.”) Any method is treated as a countermeasure, not a solution. The purpose of standardization in this context is not to enforce discipline, but to enable experimentation: you can’t accurately test a hypothesis for improvement if you don’t have stability in the system you are experimenting on. The core rules of this scientific community are tacit, not explicit. They are learned through a version of Socratic dialogue wherein supervisors and managers ask questions that allow the workers to discover rules as a result of solving problems.

Toyota takes a similar approach to its product development process, with appropriate adaptations. The product development process is substantially different than a manufacturing process, in that the core “material” is not physical objects, but knowledge and information that are often difficult to see and touch. The cycle times in product development are measured in weeks and months, not seconds and minutes; the flows are non-linear and multi-directional; and the “workers” are a large group of diverse technical specialists rather than manufacturing workers. The opportunities for waste in the system are, however, quite similar to a manufacturing operation, and include: excessive transactions (hand-offs); waiting (for data, decisions, inputs from other processes); rework (especially re-invention—the solving of the same problem multiple times because existing solutions are not utilized); set-up inefficiency (each time an engineer has to reorient himself or herself to a task because of “stop and go” processes); and lack of system discipline, including missed timelines (what Morgan refers to as “arrival variation.”)

TPDS creates a “community of scientists” among the engineering staff that is continuously experimenting with new ideas in a largely self-managed system that is driven by “pull” as opposed to “push” signals to control the flow of work. Michael Kennedy refers to Toyota’s approach as “knowledge-based” product development (in which knowledge and technical expertise drive decision-making), in contrast to “structure-based” development that is more typical at American manufacturers, where process structures, procedures and controls drive decision-making. Key feature of the TPDS include:

• FUNCTIONAL MANAGERS AS TEACHERS. Functional engineering managers are primarily teachers in the Toyota system. The managers are the most technically competent engineers, with the highest levels of experience. The “biggest teacher” is the chief engineer, who has ultimate responsibility for all aspects of the product, and teaches and manages by continuously asking “why.”
• A CLEAR EMPHASIS ON AND REWARD FOR TECHNICAL COMPETENCE. Authority derives from knowledge, especially technical knowledge. Engineers are judged on their knowledge and use of technical information, such as tradeoff curves. To quote James Morgan: “Toyota is run by an upper management group who were engineers and technical excellence is revered. It is comprised of a technical hierarchy created by rewarding technical excellence. At Toyota, your boss can almost always do your job better than you. This is what enables the teaching or mentoring as leadership principle.”2
• “PULL” SCHEDULING OF DISTRIBUTIVE PLANNING AND CONTROL. Instead of an elaborate set of detailed sub-schedules, the chief engineer is responsible for establishing a set of “key integrating events” (e.g. styling approval; tooling release; etc.) with very specific target dates. These dates are never missed. The chief engineer establishes exactly what needs to be done by those key dates. These requirements are the equivalent of a “product development kanban card” that signals to the various parts of the system that a set of work needs to be completed by a specific date. It is the responsibility of the individuals involved to figure out their own schedules to meet those dates. Just as TPS doesn’t need an MRP scheduling system, in TPDS there is no need for a top-down driven detailed timeline for program management. Instead, the requirements set by the chief engineer “pull” work along.
• SET-BASED CONCURRENT ENGINEERING. At the sub-system level, engineers create multiple alternative solutions for each component, instead of designing one component variation to match a master “solution.” Over time, each alternative is evaluated against performance tradeoffs. Weak ones are eliminated and new ones are created, often from combining components in new ways. Redundancy is built into the system, radically reducing risk. Instead of being designed from the top down, the actual system configuration “emerges” (you also might say “evolves”) from creative combinations of multiple solution sets.
• KNOWLEDGE-CAPTURE AND REUSE. Knowledge about the various solutions (“sets”) that have been created, and their performance tradeoffs, is stored in a way that is easily accessible by all engineering team members. This knowledge management system dramatically reduces the waste of “reinvention.” It also encourages reuse of components on multiple platforms. The key technical data associated with each design variation in the set system is “tradeoff curves”—data that shows how the set variations perform against paired performance variables (e.g. weight vs. size). All of the set solutions that were not used on one vehicle are now available for potential reuse on the next project.
• STANDARDIZATION AROUND CHECKLISTS AND DESIGN STANDARDS. The equivalent of “standardized work” on the manufacturing floor (which is what creates the basis for experimentation and improvement) is the use of detailed engineering checklists and design standards at each sub-system and component level. Quality matrices (think of a “mini house of quality” from a Quality Function Deployment matrix) are developed for each part, showing the detailed steps in the manufacturing process, and all of the quality or productivity issues that can be affected by that step. These and other standardization tools are used to retain a relentless focus on product performance, and to allow communication of learning easily across all players in the project team.
• VISUAL MANAGEMENT OF THE DEVELOPMENT PROCESS. The same kind of emphasis on visual control boards that is placed on the manufacturing process is also emphasized in the development process. Team rooms with color-coded graphics make it easy to immediately grasp where a project is and is not meeting its goals.

The results of the increased productivity of the TPDS are impressive. Toyota engineers and managers normally achieve an 80% level of value-added productivity, about four times that of the typical American operation; Toyota uses one quarter the number of engineers on a vehicle project than their North American competitors use; they rarely miss their milestone dates; their development times are half their American counterparts; and their end product has one of the highest quality records and best resale values in the industry.

Thousands of American manufacturing managers have spent the better part of the last two decades learning a totally new way of making things. Now it looks like their engineering counterparts are about to have an equivalent set of “significant emotional events” as they learn a totally new way of designing and developing things. Since the rewards to the company will be probably be even greater, our advice is to start the learning process now.

1 Michael Kennedy’s book Product Development for the Lean Enterprise is an excellent introduction to the subject, and is based on a project by the National Center for Manufacturing Sciences. In addition, Jeffrey Liker (author of The Toyota Way) and James Morgan are scheduled to publish a book on the subject this spring. Morgan’s 2002 University of Michigan dissertation, “High Performance Product Development: A Systems Approach to a Lean Product Development Process” is also an excellent and detailed overview of the subject. The author of this article is also familiar with a number of automotive suppliers who have implemented the TPDS.

2 James Morgan 2002 University of Michigan dissertation, “High Performance Product Development: A Systems Approach to a Lean Product Development Process”, p. 270. 

Channel Partners:

The event for tool & moldmaking, additive manufacturing

Metalworking's
premier magazine