What Happens When You Outsource Too Much?

We live in an era in which business disaggregation is the norm. In industry after industry, managers have taken deliberate steps to separate their value chains and shift important activities and functions to outside suppliers. The outsourcing trend became increasingly visible during the 1990s, when companies such as IBM began to outsource not just manufacturing but also design activities. The trend reached its peak within the past decade, when even companies such as Boeing started outsourcing innovation activities. But what happens when companies become too dependent on outside suppliers and cede them too much control if they lack the same degree of understanding and awareness about how important product or service elements fit together and what’s necessary? Once management lets go of critical internal levers, how does it go about reestablishing them?

These questions arose during a multiyear research project examining supply strategy relating to new product development at a major European automotive company (see “About the Research”). In the late 1980s, the company — which we call Alpha — had direct supply relationships with more than 3,000 suppliers, most of them small companies. The suppliers were mostly involved in the production of components, and only to a limited extent in the design of components. In the early 1990s, however, management began shifting increasing amounts of design and engineering work to suppliers. That trend was hastened by the proliferation of electronics in cars, which was beyond the traditional competence base of automotive manufacturers. Although all companies shift activities to outside suppliers, Alpha pushed outsourcing even further. By the mid-1990s, Alpha began to outsource the design of complete systems, such as dashboards, seats and safety systems, to suppliers that had the ability to provide entire systems. (See “The Anatomy of an Auto.”)

To senior management, outsourcing entire systems — including the design of those systems — seemed like the right direction. Similar supply arrangements were already common in other industries such as computers. By becoming less integrated, Alpha management hoped to increase flexibility (by being able to switch suppliers and technologies), reduce lead times (by taking advantage of concurrent engineering) and cut development costs while improving product quality (by utilizing suppliers’ specialized expertise). With its new networked innovation strategy, Alpha expected to build close relationships with 350 first-tier suppliers, mostly suppliers of systems, thereby significantly reducing the number of direct supply chain relationships. With independent suppliers, outsourcing coordination would become easier.

Between 1996 and 2001, Alpha underwent structural changes to support the new strategy. As it outsourced design work, experienced engineers who had worked inside Alpha’s functional units designing suspensions, dashboards and electric systems went to work for suppliers. Alpha was still involved with establishing overall targets, specifications and overseeing costs; it set the technical performance targets of the components, provided the physical constraints and benchmarked the technology and cost in order to get state-of-the-art technology at the right price. But as the internal engineering teams got smaller and less up to date on the specific design and technical issues, more and more responsibility shifted to outsiders.

Although internal engineers still managed key functions (development schedules, technical coordination, performance and costs), increasingly suppliers were the ones putting together the “black box” components that defined the overall product. The most influential suppliers went so far as to integrate entire chunks of the car.

Consider how a vehicle’s safety system was designed, managed and integrated. In the 1980s, Alpha designed safety systems in-house and outsourced components such as the seat belts and brakes to suppliers, providing them with the technical specifications. During this period, it continued to maintain responsibility for integrating all of the purchased components. But in the 1990s the company’s responsibilities and those of its suppliers changed (see “How Alpha’s Supply Chain Changed”). Rather than dealing directly with dozens of smaller suppliers providing components for the system, Alpha asked larger suppliers to provide entire systems, thereby shifting responsibility for managing and integrating the safety system from the inside to the outside.

It wasn’t long before management identified problems with this approach. By moving so much new-product design work to outside companies (in the space of 10 years, the percentage of design work being performed externally rose from between 25% and 35% to 85% of the value of a car, more than most competitors), the company lost its grip on many of the elements that shaped design decisions and outcomes. The pre-development phase was when the concept of the vehicle was worked out and when decisions on performance trade-offs were made. But without any direct involvement in the component design and engineering process, key decisions — for example, how the suspension felt or where the ventilation control knobs were located — were now in the hands of suppliers that didn’t know the customers or what customers expected as well as Alpha did.

In the new design regime, Alpha didn’t become involved in integrating the main components until many of the most important decisions impacting performance were baked into the product (and at which point, undoing them was difficult and costly). However, making changes late in the process was not only complicated; redesigns also were expensive and led to delays in product launches. Moreover, it meant that products could not be fully tested, which often led to assembly problems or product recalls.

By 2005, top management realized that pushing outsourcing deep into the product development process had seriously altered the technical heart of the company. As Alpha’s director of vehicle concept and integration explained, there was a “substantial lack of technological competence in key areas and in the way [we] interpreted system integration.” With this realization, management began to rethink its approach to outsourcing and to decrease the amount of design work it moved outside.

Defining the Problem

How did management define the problem? Did managers see an inherent problem in the way lean development undermined the company’s competencies and knowledge base? Or did they see it more as a case of poor implementation of the company’s product design strategy? As we interviewed managers, we learned of several key issues they saw impinging on Alpha’s ability to manage new product development effectively.

• Managers noted that it was difficult to integrate systems without having in-depth knowledge about the technologies underlying each system.
• Navigating and balancing the various technical, cost and performance objectives presented major trade-offs that were hard to sort out simultaneously. Engineers realized that these trade-offs were difficult to resolve without in-depth knowledge about the technologies underlying the systems that make up a car.
• Because of internal staff reductions and engineers’ weakened abilities to remain up to speed on specific technical issues, managers said Alpha had no choice but to lean more heavily on outside suppliers during the pre-development phase. This sowed the seeds for problems during later phases of the product development process.

There is an important difference between integrating physical systems and integrating the performance of such systems. Moreover, component-specific knowledge is crucial to the ability to integrate systems and performance; and learning by doing holds the key to maintaining component-specific knowledge.

To understand how to build effective network innovation strategies, we explored the balance between having sufficient architectural and component-specific knowledge internally to design new models, and outsourcing such knowledge by leveraging external sources of innovation. The ability to strike this balance — knowing what kinds of activities and competencies companies can delegate to suppliers and what they need to keep — has significant strategic implications for companies that design and manufacture complex products.

Physical Systems Versus Systems Performance

Cars are designed to deliver certain levels of performance in areas such as safety, handling, fuel consumption and noise. Different systems are made up of multiple parts and components, but assessments about performance are focused on how the systems interact with one another. For example, the vehicle safety system includes brakes, seat belts and air bags. However, in the event of a collision, many other elements, including the design and position of the engine or the configuration of the chassis, can influence what happens. Another problem with decomposing performance is that many factors such as speed, noise and vibration are interdependent. As a result, there are limits to how fully one can specify how much an individual component or system contributes to vehicle-level performance.

Managing the technical interdependencies between individual components presents challenges for overall product performance. Engineers need to make trade-offs (for instance, between a component’s technical performance and its cost), but the exact nature of the interdependencies is not always known or predictable. To be able to make such performance-based trade-offs competently, it’s not enough for engineers to have systems-level knowledge. They also need to have an understanding of components, something that many Alpha engineers lost as the number of opportunities for learning by doing diminished. That raised important questions about the prerequisites for making performance trade-offs and how companies should be organized. We found that there are several contributing factors to success.

Developing Component-Specific Knowledge In making performance trade-offs, it’s not enough to be informed in a general way about the key technological trade-offs involved in designing components and subsystems. Managers need to have detailed knowledge and understanding of how subsystems interact within the products to achieve different outcomes. Such knowledge is sometimes called “architectural knowledge.” One of the main issues Alpha encountered was the difficulty of setting the cross-system functional requirements, which stemmed from its insufficient knowledge of the underlying components. Prior research has shown that knowledge of underlying components is essential for identifying the consequences of different trade-offs and making the best decisions regarding overall product performance.1

Component-specific knowledge is key to architectural knowledge, and it plays an essential role in determining the performance of complex products. Researchers have studied the extent to which organizations can achieve a necessary level of understanding of the components that make up systems by using indirect means such as listening posts, shadow engineering, co-location or careful monitoring of technological advances (through scientific conferences, journals, industry meetings, etc.). Although such methods may be informative, they are not sufficient for providing the elevated level of understanding that allows managers to make detailed performance trade-offs.2

Our research supports the view that component-specific knowledge is an essential building block that complements and strengthens a company’s architectural knowledge.3 Without it, Alpha failed to develop systems integration capabilities that allowed it to work successfully with outside suppliers. When all is said and done, this knowledge is best acquired by being immersed in the details of component development work, providing opportunities for learning by doing.

Practicing “Learning by Doing” The problems with performance integration do not always manifest themselves right away. At the point when Alpha began implementing its outsourcing strategy, engineers still had deep and extensive knowledge of the underlying systems, and they were able to guide suppliers’ engineering work. However, without new learning opportunities, their competencies related to systems and components design eroded sharply over the next few years. The company tried to compensate for the loss of learning opportunities, primarily through co-location. For example, during the pre-development phase, suppliers of key systems such as safety systems, dashboards and seating systems were invited to co-locate their engineers in Alpha’s design and engineering facilities. The goal was to encourage communication and collaboration and to promote as much knowledge transfer as possible early in the development cycle.4 Despite these efforts, the engineers’ ability to remain on top of the design process deteriorated. Rather than working “hands-on” alongside suppliers on design and engineering problems, they acted more as supervisors — detailing the specifications and managing the schedules. Separating Alpha’s engineers from both the underlying design of components and new opportunities to learn by doing weakened their ability to make sound decisions that ultimately affected vehicle performance.

This experience supports the argument that operational details and strategy are tightly integrated. In particular, it underlines the importance of learning by doing as a key lever for acquiring and maintaining the detailed knowledge that’s needed for determining performance trade-offs. Other approaches such as co-location are not a substitute.

Adopting Mechanisms for Technological Renewal To the extent that component-specific knowledge is essential and that the best way to acquire this knowledge and remain up to date is through learning by doing, companies need to find ways to identify which knowledge and development work should remain in-house. Our automotive industry research indicated two criteria companies should apply in determining what they need to keep: (1) things that have a direct impact on key product performance and (2) things that have a high degree of reciprocal interdependency with technologies that help determine overall product performance. The first criterion refers to how relevant a component or subsystem is to a key performance of the product. For example, a critical performance element for a sports car is “handling.” Given the first criterion, an auto company will want to develop and maintain deep in-house knowledge about the components and systems that significantly influence handling. Without this knowledge, developing an attractive product would be difficult, if not impossible. This suggests that the automaker should focus on all subsystems that have a significant impact on handling (the steering system, suspension and so on).

The second criterion suggests paying attention to a different matter: whether the component-specific knowledge that’s key to achieving a given performance is associated with a component or subsystem that is highly interdependent with the rest of the vehicle. Consider our earlier example of the safety system. In a frontal collision, the performance of the safety system in protecting the passengers depends on the design of the different subsystems of the safety system (including seat belts, brake systems and the anti-lock brake system), and how they interact. Other factors include how the engine absorbs the shock, the layout of the front end of the car, and the material and design of the dashboard — elements that are not part of the safety system per se. In cases where interdependency is high and where performance affected by the component or system is key for customers (i.e., the first criterion is respected), the company may want to reacquire as much knowledge as possible from suppliers quickly; in cases where it’s low, components can be easily outsourced and later integrated.5

Organizing for Learning

So how can a company organize itself to maintain component-specific knowledge and learning opportunities to deliver innovative products that perform the way customers expect? Our research at Alpha indicated some important organizational guidelines. First, companies need to organize so they can develop, maintain and reestablish the competencies identified above. Second, it is not enough to reestablish component-specific knowledge and to invest resources in pulling together physical systems and components. In order to meet high performance standards for the overall product, companies also need to have the ability to experiment, test and use trial and error across the entire product.6 Without this ability, there are no guarantees that reciprocal interdependencies between the individual performance of systems and components will be adequately addressed. However, experimentation and testing can’t be conducted casually — it needs to be well organized.7 One of Alpha’s responses was to increase the number of inside people with skills such as virtual simulation that were considered important for pre-development. These skills enhanced efficiency by allowing engineers to represent performance without having to build expensive prototypes.

Performance integration has to be recognized as a critical organizational task that’s built into the structure of the company. As other researchers have noted, it requires resources and holding someone responsible for making it happen.8 But there is still another important strategic element that has to do with timing: when the design interventions occur. For example, in the automotive industry, the number of interdependencies increased as the design process moved along and specifications were frozen. The earlier that interventions can be made, the less disruptive and costly design changes will be.9 The ideal, of course, is to design products that are right the first time. However, to the extent that this is not realistic, having the ability to manage experimentation will permit better and more efficient performance integration.

Interestingly, Alpha’s experience also shows that managing outsourcing by relying on the modularization of the product can have fundamental flaws. Modular product architecture may make good sense for dealing with physical integration, but it is not adequate for resolving issues of performance.

Focusing on product-level performance pushes companies to build and maintain enough competence to resolve the important performance trade-offs. That means organizations need to manage and maintain the right component-specific knowledge. The economic argument — that design and engineering outsourcing provides cost savings and increased efficiencies — can be offset by taking into account other strategic considerations. Decisions about which design tasks to outsource to suppliers and which ones to keep need to be made by looking at the whole picture rather than only short-term cost and efficiency. Once the critical competencies are identified, an essential task of managing innovation is developing and maintaining them properly.