...or, Sometimes Redundancies Aren't
We talk a great deal in Extension (as almost all large organizations do) about 'eliminating duplication.' We want to be as lean and efficient as possible. This isn't a bad goal; we want to do as much as we can, spread our resources as far as we can, and be as effective as possible.
The problem arises when this works better in the all-mental abstract than it does in the rubber-meets-the-road concrete. In particular, when our definition of 'duplication' is not specific enough to identify things (for example) that look the same, but aren't. Sometimes eliminating 'duplication' that isn't really duplication, when--for instance, two groups do the same thing, but serve very different audiences--eliminates the ability to serve either audience rather than making the organization as a whole more efficient.
In The Innovator's Dilemma, Clayton Christensen talks about processes:
If the acquiring company's processes and values are the real driver of its success, then the last thing the acquiring manager wants to do is to integrate the company into the new parent organization. Integration will vaporize many of the processes and values of the acquired firm as its managers are required to adopt the buyer's way of doing business and have their proposals to innovate evaluated according to the decision criteria of the acquiring company. If the acquiree's processes and values were the reason for its historical success, a better strategy is to let the business stand alone, and for the parent to infuse its resource into the acquired firm's processes and values. This strategy, in essence, truly constitutes the acquisition of new capabilities (pg. 198)
Of IBM's acquisition of Rolm:
This situation is reminiscent of IBM's 1984 acquisition of Rolm. There wasn't anything in Rolm's pool of resources that IBM didn't already have. It was Rolm's processes for developing PBX products and for finding new markets for them that was really responsible for its success. In 1987, IBM decided to fully integrate the company into its corporate structure. Trying to push Rolm's resources--its products and customers--through the same processes that were honed in its large computer business, caused the Rolm business to stumble badly. And inviting executives of a computer company whose values had been whetted on operating profit margins of 18 percent, to get excited about prioritizing products with operating margins below 10 percent was impossible. IBM's decision to integrate Rolm actually destroyed the very source of the original worth of the deal. (pg. 199)
This approach and occasional miscalculation are not just perpetrated via company acquisition. Let's look at an example in the university environment that I'm familiar with:
We often talk, at the university, about 'centralizing services.' For example, the idea that we should centralize computer support services in one shop. On the surface, this immediately looks like a way to gain efficiencies without much tradeoff. After all, support's support, right? And it's possible to make this kind of centralization work, but it's important not to over look two vital things:
In other words, computer support services are not necessarily duplicative.
All support staff are equal in the sense that they all have valuable skills and knowledge. No group--departmental, outreach, central--is a subset of another group. We often make the mistake of thinking central support staff know all about central services, as well as all the more local services, but this is almost always not so. For example, outreach support services on our campus, support a state-wide network that isn't relevant to central services. Most of the expertise to support that network resides with the outreach support group, not the central support group. The different support services, then, are neither heirarchical or duplicative. They are different. Simply merging without recognizing the different processes and value systems would likely result in loss of services to all groups and not provide the efficiencies you expect.
All support staff are not the same because the focus of a departmental support person (for example) is necessarily different than the focus of a central support person. To a central support person a deparment faculty member is 1/25,000th of users. Within the department that same faculty person might be 1/300th of users or even 1/50th. Department units often support different software, provide more hands-on service, include one-on-one training, are available more quickly, and are local.
Sometimes something has to go. Budgets get cut; resources are no longer available. But it's important to look at whether the things we want to eliminate are resource that are the same--desks and printers and offices--or whether it involves eliminating processes and knowledge that are actually not duplicated and which are vital to the system in some important ways.
Posted by dcoates at November 06, 2003 09:56 AM