Insights / Perspective / Operating model design
PerspectiveShared services: when centralising helps and when it hurts
Centralising common work such as finance or procurement can save cost and improve control, if done with discipline. Three conditions separate shared services that help from those that hurt.
Shared services have a simple appeal. Instead of every division or site running its own finance, payroll, procurement, IT support and HR administration, bring that work together in one team. Economies of scale reduce cost, common processes improve control, and specialists can be developed properly rather than spread thinly.
Centralising common work such as finance or procurement can save cost and improve control, if done with discipline. Without discipline, it produces a distant, slow team that the business works around, and the savings disappear into shadow teams rebuilt locally. The difference rarely lies in the idea. It lies in how the move is made and how the shared team behaves afterwards.
When centralising helps
Shared services work best for work that is high in volume, follows clear rules and does not depend on deep local knowledge. Paying suppliers, processing payroll, managing expense claims, maintaining employee records, handling routine IT requests and consolidating management accounts all fit this description.
For this kind of work, the benefits are real. A single team using one process and one system makes fewer errors than several teams each doing it their own way. Specialists can focus on what they do best. Management information becomes consistent across the business. And the cost of each transaction usually falls as volumes grow.
Centralising tends to hurt when the work depends on judgement, relationships or context that only exists locally. A plant’s maintenance buyer who knows which supplier can deliver a critical part overnight, or an HR business partner who understands a site’s history with its workforce, adds value precisely because they are close to the operation. Pulling that work into a central team strips out the knowledge that made it effective.
Many organisations find a middle path. Transactional work moves to the shared team, while a small number of advisers stay embedded in each business unit. A divisional finance business partner, for example, interprets the numbers and supports decisions, while the shared team produces them. The split keeps scale where it pays and judgement where it matters.
Standardise first
Centralising a messy process spreads the mess. Agree the standard before moving work.
The most common mistake is to move work first and fix it later. Each division arrives in the shared team with its own way of doing things, its own exceptions and its own spreadsheets. The shared team ends up running several versions of every process, with none of the promised efficiency. Worse, the move disrupts the people who understood the old processes, so quality often falls.
The better sequence is to agree a single standard process, with the divisions involved, before any work moves. Decide which local variations are genuinely necessary, perhaps for legal reasons in different countries, and which are simply habit. Simplify the process, document it and test it. Then move the work in waves, starting with the parts that fit the standard most easily.
Exceptions are the real cost
Most of the effort in a shared service goes into exceptions: the invoice without a purchase order, the employee on a special contract, the cost centre that does not fit the chart of accounts. Reducing exceptions before centralising delivers more savings than the move itself.
Define service levels
Internal customers need clear promises on speed and quality, and a way to raise issues.
When a site ran its own payroll, the site manager could walk down the corridor if something went wrong. After centralisation, that direct line disappears. Without a clear replacement, frustration builds quickly. Every delay is blamed on the shared team, whether or not it was at fault.
Service levels replace the corridor conversation. They state what the shared team will deliver, how quickly and to what standard: supplier invoices paid within agreed terms, new starters set up before their first day, routine IT requests resolved within a set time. They also state what the business must provide in return, such as correct purchase orders or timely starter information.
- Keep the number of service measures small, focused on what internal customers notice most.
- Publish performance monthly, including where targets were missed and why.
- Provide a simple route for raising issues, with a named contact for each business unit.
- Review service levels with internal customers at least twice a year and adjust them as needs change.
Keep the connection
Shared teams that lose touch with the business slowly lose its trust.
Over time, a shared service can become inward-looking. It optimises its own efficiency, measures its own processes and talks in its own language. The business it serves starts to see it as a bureaucracy rather than a partner. Divisions quietly hire their own analysts or administrators to work around it, and the cost savings erode.
Preventing this takes deliberate effort. Assign relationship managers who spend time in the business and understand its priorities. Invite internal customers to help design process changes. Rotate staff between the shared team and operational roles where possible. And measure the shared team partly on internal customer satisfaction, not only on cost and throughput.
Our shared finance team started attending the divisions’ monthly reviews. Within a quarter, the complaints dropped, and the divisions began asking for more support rather than less.
Group finance director, manufacturing client
A practical test
Before centralising any activity, ask three questions. Is the work high in volume and rule-based? Can we agree a single standard process before moving it? And can we commit to clear service levels and a strong connection with the business? If the answer to all three is yes, a shared service is likely to help. If any answer is no, fix that first, or keep the work where it is.
Source: Intelliversal analysis.
