Tuesday, January 04, 2011

Executives who outsource too much

#entarch @Cybersal found a useful article in MIT Sloan Management Review What Happens When You Outsource Too Much? by Francesco Zirpoli and Markus C. Becker (December 2010).

In my view, the title of the article doesn't do justice to the content. There has been endless discussion on how-much outsourcing. Here is a small selection.

"Globalization has led corporations to outsource too much of their work and, more important, their intellectual capital. This has created a worldwide level of interdependency that increasingly threatens to disrupt supply lines and markets at times of earthquakes, explosions, terrorist acts, and other disasters in one part of the world." Has Globalization Reached Its Peak? (James Heskett, HBR, April 2006)

"Outsourcing is one of the quickest, easiest, and most inexpensive ways to hire help and get things done faster." Coaching Women - How to Outsource Tasks Without Losing Control (Zenobia Garrison, Oct 2010)

"You don’t want to outsource too much." Why Outsourcing Can Work (Cormac Foster, Dell, October 2010).

According to most of these accounts, the trick is to outsource only those activities that have certain properties.

  • "primarily non-strategic activities"
  • "the tasks that you despise or take up too much of your time"
  • "don’t fix what isn’t broken"
To my mind, this is a programme management approach to outsourcing - classifying each business activity separately, and deciding its fate accordingly. In contrast, a truly architectural approach to outsourcing would look at the effect of outsourcing on the relationships between activities, not just on the activities in isolation. This is what I find new and interesting about the Sloan paper; here are some key quotes from it, which may help me to reinforce Sally's recommendation.

"By 2005, top management realized that pushing outsourcing deep into the product development process had seriously altered the technical heart of the company."

"There is an important difference between integrating physical systems and integrating the performance of such systems."

"Managers need to have detailed knowledge and understanding of how subsystems interact within the products to achieve different outcomes. ... Knowledge of underlying components is essential for identifying the consequences of different trade-offs and making the best decisions regarding overall product performance. Component-specific knowledge is key to architectural knowledge."

"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." (We might say the same about the modularization of the business process.)

"Combining knowledge requires a deep understanding of knowledge, rather than just information scanning or exposure."

No comments: