個案總覽

This is an MIT Sloan Management Review article. Editor's Note: MIT Sloan Management Review first published "The New Practice of Global Product Development"in our Summer 2006 edition. In the article, authors Steven D. Eppinger and Anil R. Chitkara examined state-of-the-art and emerging best practices in global product development (GPD). GPD continues to evolve, and in 2009, we asked Eppinger, the General Motors Leaders for Manufacturing Professor of Management Science at the MIT Sloan School of Management, to update the article with new insights about GPD. His additions are published here along side the 2006 article, annotating the original text.

Communication may not be on managers' minds at companies that design complex, highly engineered products, but it should be. When mistakes take place, it's often because product-component teams fail to talk. The consequences can be huge: Ford and Bridgestone Firestone lost billions by not coordinating the design of the Explorer with the design of its tires. The major delays and cost overruns involved in the development of Airbus's A380 "super jumbo"--which most likely led to the CEO's exit--were a result of unforeseen design incompatibilities. To help managers mitigate such problems, the authors present a new application of the design structure matrix, a project management tool that maps the flow of information and its impact on product development. Drawing on research into how Pratt & Whitney handled the development of the PW4098 jet engine, they have developed an approach that uncovers (a) areas where communication should be occurring but is not (unattended interfaces, usually bad) and (b) areas where communication is occurring but has not been planned for (unidentified interfaces, usually good). After finding the unattended and unidentified interfaces, the next step is to figure out the causes of the critical ones. If a significant number of unattended interfaces cross organizational boundaries, executives may need to redraw organizational lines. Executives can then manage the remaining critical interfaces by extending the responsibilities of existing integration teams (those responsible for cross-system aspects, such as a jet engine's fuel economy) to include supervising the interaction, by dedicating teams to specific interfaces, or by formally charging teams already involved with the interfaces to oversee them. Finally, it's important to ensure that the teams are working with compatible design equipment; inconsistencies between CAD tools have cost Airbus dearly.

This is an MIT Sloan Management Review article. Many manufacturers already have established product development activities in different countries around the world. As a rule, the current approach includes colocation of cross-functional teams to foster close collaboration among engineering, marketing, manufacturing, and supply-chain functions. The results to date--better product designs, faster time to market, and lower-cost production--have been satisfactory. However, growth and innovation can now be much more effective if manufacturers tie their decentralized development organizations into a cohesive, unified global product development (GPD) operation. In this article, the authors introduce new empirical frameworks to guide managers toward such practices. Citing exemplars such as Hewlett-Packard, Eastman Kodak, Hyundai Motors, Haier, Alcatel, and Cummins, the authors explain why GPD has come of age and demonstrate a three-stage approach that puts product development in the context of a company's relationships with outside partners. The article draws from extensive interviews with engineering managers at more than 100 companies in 15 countries in North America, Europe, and Asia. Additional data are from a recently completed study on GPD that PTC has conducted with BusinessWeek Research Services, interviewing and surveying more than 1,100 engineering managers worldwide.

Conventional project-management tools--PERT charts and Gantt charts, for example--were created to help manage sequences of discrete tasks that make up large construction projects. Yet these tools don't capture clearly the back-and-forth of information that takes place in innovative processes, such as product development. Conventional tools are designed to answer the question, "What other tasks must be completed before I begin this one?" But product development planners, especially in high-tech businesses, need tools that answer a very different question: "What information do I need from other tasks before I can complete this one?" The author describes the Design Structure Matrix (DSM), a project management tool that focuses on representing the information flows of a project rather than its work flows. He explains how the DSM works and how to use it to make development processes more efficient. A project DSM can show which information exchanges involve design iteration and how well a process anticipates the need for rework. In addition, the author suggests four ways to improve a company's information flows: rearranging the sequence of tasks, reconsidering the organization of tasks, reducing the number of information exchanges, and managing unplannable work. By stripping away the mystery around information exchange during innovation, the DSM can give managers far more control over their most risky and expensive projects.