Centralizing finance, HR, or procurement into a shared services model is usually pitched on cost — fewer redundant roles, more consistent processes, economies of scale. What actually determines whether it works is something the cost case rarely accounts for: accountability. The moment a business unit leader can no longer walk down the hall and ask their own dedicated analyst why a number looks wrong, something has to replace that direct line of ownership, or service quality erodes and business units quietly rebuild shadow teams to compensate — which defeats the entire purpose of centralizing in the first place. Shared services done well doesn’t just move work into one place. It redesigns how accountability travels between the center and the business.
Key Takeaways
- Centralization without a clear service-level and accountability model is the most common reason business units rebuild shadow teams.
- Not every activity belongs in shared services — separate what benefits from standardization from what needs to stay close to the business.
- Named relationship owners on both sides (shared services and business unit) prevent accountability from disappearing into a generic queue.
- Service level agreements need to be specific and measurable, not aspirational statements about “responsiveness.”
- Sequencing the transition function by function, starting with the most standardizable processes, reduces disruption risk significantly.
Why Business Units Rebuild What You Just Centralized
The predictable failure pattern in shared services goes like this: a function is centralized to cut cost, business units lose their dedicated support, service quality dips during the transition, and business unit leaders — frustrated and still accountable for their own results — quietly hire an analyst or coordinator to handle what shared services isn’t handling well. Within eighteen months, the organization is paying for both the shared services center and a growing layer of shadow support in the business units, which is worse than the state before centralization. This isn’t a service delivery failure so much as a design failure: nobody built the mechanism that was supposed to replace the informal accountability that used to exist when support sat inside the business unit.
Deciding What Actually Belongs in Shared Services
Not every activity benefits equally from centralization. The activities that make the strongest case are high-volume, transactional, and rule-based — accounts payable processing, payroll administration, standard reporting, routine reconciliations. These benefit from standardized process, economies of scale, and consistent controls. Activities that require deep business context, frequent judgment calls, or close day-to-day relationship with operational leaders — FP&A business partnering, complex contract negotiation support, anything requiring nuanced understanding of a specific business unit’s dynamics — tend to suffer when centralized, because the value they provide depends on proximity and context that a shared, generalized team can’t easily replicate. A practical filter:
- High volume + low judgment required = strong candidate for full centralization.
- Low volume + high judgment required = should generally stay embedded with the business.
- High volume + high judgment = candidate for a hybrid model — standardized processing centralized, judgment-heavy exceptions routed to a specialist, possibly still centrally based but with named business unit ownership.
Building Service Level Agreements That Mean Something
Vague SLAs (“we aim to respond promptly”) give shared services no real accountability and give business units no real recourse. Effective SLAs are specific, measurable, and tied to what the business unit actually cares about — not just activity metrics that are easy for the shared services team to hit. For each major service:
- Define turnaround time in concrete terms (e.g., standard invoice processed within two business days of receipt) rather than vague responsiveness language.
- Define quality metrics that matter to the business unit, not just to the shared services team’s internal process (error rates that caused a business unit issue, not just internal QA scores).
- Include an escalation path with a real response time commitment for exceptions, since exceptions are exactly where shared services models tend to break down.
- Review SLA performance jointly on a fixed cadence, with both sides — not shared services reporting one-way to the business.
Assigning Named Relationship Owners on Both Sides
A shared services model that routes every business unit request into an anonymous generic queue erodes the relationship that used to exist when support was embedded. The fix isn’t to abandon the efficiency of centralized processing — it’s to pair it with named relationship ownership. Each major business unit should have a specific point of contact within shared services who understands their context, and each business unit should have a specific person accountable for triaging and routing requests appropriately. This person doesn’t have to process every transaction personally, but they own the relationship, understand recurring pain points, and can escalate meaningfully when the standard process isn’t working for that business unit’s specific situation. This single design choice does more to prevent shadow-team rebuilding than almost anything else in the model.
Sequencing the Transition Function by Function
Attempting to centralize finance, HR, and procurement simultaneously multiplies the disruption risk across the organization at once. A more controlled approach is to sequence by function, starting with the process that’s most standardizable and least judgment-dependent — accounts payable is a common starting point. Prove the SLA model, the relationship-owner structure, and the escalation process work in practice with this first function before expanding. Each subsequent function transition benefits from lessons learned in the prior one, and the organization builds confidence in the model incrementally rather than absorbing the shock of a single big-bang centralization across everything at once.
Measuring Success Beyond Cost Savings
Cost reduction is usually the headline justification for shared services, but tracking cost alone will miss the shadow-team problem until it’s already sizable. Build a scorecard that also tracks business unit satisfaction (via structured, regular feedback, not just informal complaints), SLA adherence, and — critically — headcount growth within business units that could indicate shadow rebuilding. If a business unit’s “business partner” or “coordinator” headcount is quietly growing after a function centralizes, that’s an early signal the shared services model isn’t delivering what that unit actually needs, well before it shows up as a cost problem in aggregate.
Frequently Asked Questions
How long does a typical shared services transition take?
For a single function like accounts payable, a well-planned transition typically takes three to six months from design through stabilization. A multi-function shared services buildout, sequenced properly, often spans twelve to eighteen months in total.
Should shared services report to finance or operate as an independent function?
Either can work, but the reporting line matters less than having clear cross-functional governance and SLA accountability that isn’t solely controlled by the function it serves most. A steering group with representation from major business units helps keep the center honest.
What’s the earliest warning sign a shared services model isn’t working?
Growing informal headcount in business units doing work that overlaps with the centralized function, and a rising volume of exceptions or escalations that bypass the standard process. Both indicate the business units don’t trust the center to handle their needs.
Can shared services work for a smaller organization, or is it only for large enterprises?
Smaller organizations can benefit from a lighter version of the same principles — centralizing transactional work with clear service expectations — without needing a formal, large-scale shared services center. The accountability and relationship-ownership design principles apply regardless of scale.
Related Reading
- Budget Governance for Multi-Entity Organizations
- ERP Transitions: The Operational Groundwork That Determines Success
- Learn more about our Finance & Operational Transformation services