Download as PDF
by Stephanie Owen – Principal Consultant, Strategy2Life
A large bank with multiple lines of business established a shared service function some years ago. The operating model was designed so that the central shared services function provided human resources (HR) services to the various business units, such as recruitment, training and international mobility management. The HR function within each business unit would mainly consist of HR managers or “business partners” who work closely with business managers day-to-day, and brokered business requirements and oversaw service delivery by the shared services function. The operating model was designed to reduce cost by standardising service, and it succeeded in this objective – up to a point.
Cracks began appearing in the operating model when it became obvious that the HR business partners/managers within the wholesale banking business unit were spending more and more time tweaking the services provided by the shared services function. Coveted corporate banking talent became lost to competitors who completed recruitment processes more quickly and who were more flexible with remuneration packaging. Productivity was lost to the need to manage around international mobility arrangements that catered for once-in-a-career relocations and repatriations, not the relatively frequent, multi-country moves that were becoming commonplace in the wholesale bank. Within the shared services function itself, workload increased as exception processing and expedited requests rose, and the harder work did not seem to translate to higher customer satisfaction. Blame among different parts of HR threatened working relationships and morale.
This scenario is, alas, not uncommon among organisations that change their operating models. Often, it is because the operating model was designed in isolation from customers’ needs, and to optimise one outcome (typically cost) at the expense of others.
A key solution to this problem is to start with your customers’ needs when designing an operating model. This principle applies similarly whether we are talking about core operations (that is, serving paying customers) or support function operations (that is, serving internal customers). For now, I will continue to use the example of support function operations that serve internal customers.
When designing an operating model, we need to start with the desired results, or performance objectives. There are five main performance objectives to consider in operations (for example, from the textbook by Slack, Chambers and Johnston: Operations Management):
- Quality – getting it right
- Speed – doing things fast
- Dependability – meeting expectations
- Flexibility – ability to adapt activities to meet varying requirements
- Cost – ability to deliver services cheaply
In the case of the bank with multiple business units, the shared service operating model design sought to optimise the cost objective and, to some extent, quality and dependability. It did not consider speed as highly important and, for the sake of standardisation, sought to discourage flexibility. These performance objectives were designed into the operating model, and can be mapped graphically, as below (5=very important, 1=not important):
The largest group of internal customers, the retail banking business unit, has a high number of relatively homogenous and lower-paid employees (mainly customer service, bank tellers). It has an HR service needs graph resembling the following (5=very important, 1=not important):
Although there is rarely perfect alignment in any organisation, the shared service operating model was meeting the retail bank’s business needs, by and large. However, the wholesale bank business unit, with its smaller, highly-paid heterogeneous workforce, higher profit margins, and tougher competition for talent, was found to have an HR service needs graph resembling the following:
When graphically represented in this way, it becomes obvious that the shared service operating model design is not an optimal match for the HR service needs of the wholesale banking business. Most importantly, the graph takes emotion out of the discussion. The wholesale bank’s HR service needs have arisen out of the nature of its business and its strategy, not because its people are somehow being unreasonably demanding. A constructive discussion about genuine business needs for each customer segment of the support function (eg, business units or in some cases, departments within it) would enable the operating model to be redesigned to align with the most critical needs of the entire business, not one business unit at the expense of others. It may be that some parts of the operating model needs to be adapted to meet specific business unit requirements. If this is the case, it is surely more cost effective for the shared services function to design a “process option B” than to address differences on a case-by-case basis. At the same time, the business unit requiring “process option B” needs to carry its fair share of operating costs, with the knowledge that an operating model that meets its needs more closely would reduce costs that are otherwise hidden, such as supplementary work (“tweaking”), visible and invisible rework, and going outside the system.
As mentioned previously, I have chosen to focus on support function operating model design, but the principle of starting with customers’ needs applies just as much, if not more, to designing the core operating model for a whole business. In this instance, you would not only start with the needs of your customer segments, but it is also critical to compare your operating model with your competitors’, so that your operating model can support the overall value proposition of the business and to sustain its competitive advantage.
© 2013 Copyright reserved by Stephanie Owen and Strategy2Life – http://strategty2life.com Unauthorised use and/or duplication of this material without express and written permission from Strategy2Life is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given, with appropriate and specific direction to the original content.
Strategy2Life: Strategy Execution and Change 
[…] here to read Stephanie’s article – “Operating model design: start with […]
Hi Steph, I think having cost reduction as a primary objective is part of the problem for shared services. I must admit that I have not yet come across any shared service that have achieved what they set out to do – improve the service, at a lower cost. There are some that claim to have achieved it but the claim has always been refuted by their customers.
As soon as you start to manage cost – costs will go up. For many shared services the measure of success is in transaction cost and whilst unit cost may go down, total costs increase due to an increase of failure demand.
I think you are absolutely correct in saying that the design should be driven from the customers’ perspective. Focusing on value creation is critical for all business, it is always cheaper to provide a service correctly the first time. Due to the inherent variety of demand for a shared service unit, a standardised system is likely to fail.
In addition, there are other ways of developing specialists than a shared service function. And best practice is only valuable if you are operating in the simple domain, not useful in the complicated or complex domains (see Cynefin).
Anyway, that’s my 2 cents.
Hi Stefan, thanks for your input.
I found your comment “I must admit that I have not yet come across any shared service that have achieved what they set out to do – improve the service, at a lower cost” particularly interesting… and disturbing.
On the one hand, I was thinking to myself that “Yes, I have implemented shared service functions that irrefutably improved service, at a lower cost”. One example involved customer queries which used to come through multiple channels and not fairly prioritised, there were duplicate requests (because customers did not hear back on one channel, so they tried another), and the queries used to get “lost” on a regular basis. The establishment of shared services absolutely improved the service delivery of that function dramatically, because the move to shared services was accompanied by the implementation of a robust workflow management system. Yes, it was the work management system which made the difference, not the org structure. That said, without the efficiencies from centralising, you would not have the savings nor the critical mass to implement that work management system.
On the other hand, the truth in your comment lies in the fact that “improved service at lower cost” really depends on how you define service, and how you define cost. And it is often the case that the aspects of service that are measurable are not always the things that matter most to customers. Ditto cost – as you pointed out, transactional/unit cost vs total cost.
Shared services’ suitability for a simple domain vs complex one is not something I’ve used the Cynefin framework for. However, a similar concept in classic operations management literature exists, viz., there is a distinction between batch, flow, job shop, and professional services based on the level of customisation and complexity. You would not take your car repair job to a massive production line, just as it would be overkill (for most people) to buy a custom, hand-crafted, one-of-a-kind car. Yet it is true that services are often shoehorned into shared services organisations whether they are suited or not.
Thanks again for illuminating the discussion.
-Stephanie.
Hi again Stephanie, firstly I did not mean to offend by suggesting that ALL shared services are failures, it’s just that I have not heard of any successes that have been backed up by its customers.
Secondly, building on your car service analogy. An issue I have seen in many transitions to shared services operations is the support function starting to dictate to the primary activities of organisations what kind of car they can drive. The support centre will now only provide services for customers with Fords because that is cheapest and easiest for the shared services. So if you want support you have to swap from whatever car you might have now. For some it makes no difference but for others Ford does not have a suitable vehicle. Whilst there might be some perceived benefits from economies of scale this is the tail wagging the dog with supporting functions telling the primary activities what they can and cannot do. Cost in services is in flow, not scale but this concept is terribly difficult for accountants to understand and unfortunately many business decisions are from a short term financial perspective, not a long term value creating one.
Another question to consider before deciding to move to a shared service provider is how much waste could be removed by “simply” understanding and redesigning the current service system – it is that level of service and cost any shared service initiative should be assessed against.
Much of the evidence to support shared service success is from providers of shared services, particularly providers of IT systems or providers of services to implement big IT systems. The phenomenal failures of shared services in the public sector in recent years provides some insight into into this. Take the QLD health payroll debacle which is a perfect example of Ashby’s law of Requisite Variety in play – the variation of the regulator (i.e. the IT system) did not match the variety of incoming demand. There are some additional examples here of failures http://wp.me/p2EQHd-aH
If you have some examples of successful shared services I would love to hear more about them to understand in greater detail what made them successful. In all my shared service work part of the solution has always been to remove much of the standardisation and build systems with capability to better respond to the inherent variety of demand that comes from serving multiple customers with different needs.
Cheers, Stefan
Hi Stefan.
Definitely no offence taken, as I’ve also seen many more failures than successes in shared services. I suspect the reasons are one or more of these: shared services is the “right answer to the wrong problem” or the “wrong answer to the right problem”; the objectives are set too narrowly (eg, headcount cost); the wrong services are chosen and/or designed poorly (eg, “you can have any car as long as it’s a Ford” phenomenon you described, and the Law of Requisite Variety not met – essentially the scenario that I described in the original article where 1 type of service can’t fit 2 different variations of customers); the implementation including transition/change management is poorly handled; the ongoing management is not robust; there is no continuous improvement based on ongoing customer satisfaction feedback… In other words, all the same reasons why any operating model may fail: poor design, poor implementation, poor ongoing management (including lack of continuous improvement, where a model that once worked well no longer does). I agree with you that building systems with capability to better respond to the inherent variety of demand of the customer set is part of good design; perhaps, more to the point, deciding what parts of a service to standardise and what part to customise.
Thanks.
-Stephanie.
[…] here to read Stephanie’s article – “Operating model design: start with […]
Hi Jase,
Couldn’t agree more. The thing is, as I’m sure you know, that shared services per se are not a bad thing. There are certainly benefits to consolidation, eg, development of specialist skills and adoption of best practices take place more easily when specialists are grouped together, and there are efficiencies to be gained. The problem is when the design criteria are incorrectly set, eg, as you said, with cost reduction being the only goal.
Thanks for commenting and I hope you’re going well!
Great article, Steph. As an enterprise and business architect, I can see that this has been one of the core failures of IT as a shared service. It is almost always executed for the benefits of consolidation and cost-reduction, with next to no consideration of the “cost” of lost agility and responsiveness.