Thursday, June 2, 2011

Shared Services

Since I really enjoy technology, I can endure a lot of organizational pain. But lately I have been starting to clearly notice some of the negative side effects that a shared service organization can have. I cannot remember ever having to deal with such a large number of forms, requests and hand-offs (business users, business user representatives, BSA's, QA, architects, developers, support ...). All would be fine if there was not such an insane amount of time required for completing all these interactions: meetings to plan resources across these services, meetings with the service providers on outstanding issues, KT (knowledge transfer, ... don't even get me started on that one, brain transplants are the only quick solution to that one ...), waiting for service requests to be completed, coordinating amongst different service providers ... Insanity is only one more shared service away. What once was a task that took maybe 2% of your time, is now a shared service that takes 20% of your time. So the advantage would be that we are capturing all this knowledge ... Yep, but a lot of it is not captured or only captured in small fragments scattered across all the service providers.

I am not specialized in organizational structures, so I assumed it was just me. Luckily, there is at least one other person with similar observations:
https://www.qualitydigest.com/inside/quality-insider-article/shared-services-paradox-it-increases-costs.html#

To quote:

John Seddon of Vanguard Consulting discovered that variety of demand is a key leverage point for services. All the simplification, standardization, and centralization that support cost reduction and improvement projects lead to failure demand (i.e., demand caused by a failure to do something or do something right for a customer). It’s an inside-out, top-down way of thinking that makes service management oblivious to the impact and total costs.

When services are shared, demands are often found to be different, even though the function may be the same. Combining like functions (e.g., contact centers, HR, finance, and IT) that have different customer demands does not decrease demand. Failure demand, which typically runs between 25 percent and 75 percent, and the variety of demands are still present: They are “shared” but not reduced.

In industrialized design, back offices are ever-present. This functional design is rooted in the scale thinking that accompanies industrialized thinking. To free up customer-facing front offices, work is passed to back offices. The front office too often can’t actually help a customer and so the waste begins. This waste comes in the form of hand-offs, rework, duplication, and loss of continuity, which increases the time to get service. The act of sharing services increases the scale of this design and, in turn, increases the waste. More failure demand results from customers who don’t receive service quickly, accurately, or sometimes at all. Costs rise as a result.

This doesn’t mean that all sharing of services is bad. However, when we:
• Accept back offices or other industrialized designs
• Ignore the variety of demand in services
• Assume economies-of-scale thinking
• Merge functions in the name of simplification, standardization, and centralization

We run the risk of making a costly mistake.


An other person is suffering under the same illusion ... I am not alone! :). The little nugget I found in the above article was that the argument for a shared service is often reducing cost through scale. As the article points out however, cost is not in scale, but in flow.

Service organizations see the visible cost savings that can be achieved through shared services. What they don’t see are the hidden costs of poor design, and the poor flow that results. The problem is that costs are not in scale, but in flow.

This is the truth given to us by Taiichi Ohno, mastermind of the Toyota Production System. Economies of flow are superior to economies of scale. Whereas scale focuses on reducing transaction costs, an economy of flow focuses on end-to-end value as defined by the customer.

No comments:

Post a Comment