By 2013 the shared services model was twenty years old and running into its own ceiling. Organizations that had consolidated finance transactions into a regional centre in the late 1990s had taken the cost out, hit the service levels, and then found that the next wave of value was blocked by the very thing that made the first wave work: the centre only did finance. Global Business Services was the answer to that. Not a rebrand — though plenty of organizations treated it as one — but a structural change in what was consolidated, who it reported to, and how it was governed.
What Actually Changes
The distinction is worth stating precisely, because "GBS" was applied loosely enough in this period to mean almost nothing. A shared services centre consolidates one function's transactional work, typically finance, sometimes HR, in one location. It reports into that function. It is measured on cost per transaction and service levels. Each function that consolidates does so separately, usually years apart, often in different cities, with its own governance and its own technology. Global Business Services consolidates multiple functions into one organization with a single leadership structure, one governance model, one technology approach and one set of service management disciplines. It typically spans finance, HR, procurement, IT service management and increasingly customer service and master data. It reports as an organization in its own right rather than up through a single functional line. That reporting difference is the substantive one. When the finance shared service centre reports to the CFO, it optimises for what finance wants. When a GBS organization reports to a COO or to the executive committee, it can make decisions that trade off between functions — which is where most of the remaining value sits.
| Design choice | Function-led centre | GBS archetype |
|---|---|---|
| Scope | One function's transactions | Multiple functions under a common organisation |
| Decision rights | Optimise within the function | Resolve cross-functional trade-offs |
| Service discipline | Function-specific governance | Common intake, standards and ownership |
| Transition boundary | Local function scope | Explicit retained roles and sequenced transitions |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Why the Model Emerged When It Did
Labour arbitrage had been harvested. The cost gap that justified the first offshore move had narrowed through wage inflation in the established delivery locations. Another five percent was available from relocation; twenty-five percent required doing the work differently. The end-to-end processes crossed functions. Procure-to-pay is procurement and finance. Hire-to-retire is HR, finance, IT and facilities. Order-to-cash is sales, finance and customer service. Optimising the finance slice of procure-to-pay while procurement independently optimises theirs produces two locally efficient processes and a handoff that nobody owns — which is where the delays and the exceptions live. Duplicated overhead had become visible. Three separate centres in three countries, each with its own leadership, quality function, training team, technology stack, facilities and vendor relationships. The consolidation saving was real and easy to quantify, which made GBS an easy business case even where the process argument was not understood. And the technology had matured. Workflow platforms, document management and early automation could span functions in a way that earlier, function-specific systems could not.
The Value That Only GBS Can Deliver
End-to-end process ownership with actual authority. A single owner for procure-to-pay who can change the purchase order policy, the invoice submission channel, the approval matrix and the payment run — rather than four owners who each control one segment and negotiate at the boundaries. Cross-functional data. The connection between supplier onboarding quality, invoice exception rates and payment delays is only visible if one organization holds all three datasets. Most shared service models cannot see it. One service management discipline. A single service catalogue, one intake channel, consistent service levels and one continuous improvement method applied across every function, rather than five different maturity levels and five different definitions of the same metric. Leverage in technology and location decisions. One automation platform rather than four. One location strategy rather than accretion. One vendor relationship with negotiating weight rather than four small ones. A talent model that works. Careers that move across functions and between process, technology and analytics roles — which is a genuinely better proposition than a career inside a single-function transaction centre, and matters enormously for retention.
Where GBS Implementations Go Wrong
It gets announced as a name change. The centres are relabelled, an org chart is redrawn, and nothing about governance, process ownership or funding changes. Eighteen months later the model is judged to have failed, when in fact it was never implemented. Functional leaders retain real control. The CFO still directs the finance staff in the GBS organization; the CHRO still directs HR. A GBS leader with accountability and no authority cannot make the cross-functional trades that justify the model. This is the most common failure and it is a governance problem, not an execution one. Everything moves at once. A simultaneous transition of finance, HR, procurement and IT service management across multiple regions produces a volume of concurrent change that no leadership team can absorb. The organizations that succeeded sequenced: one function, stabilise, then the next. Process standardisation is skipped. Consolidating four variants of an inconsistent process into one location produces one location running four variants, with higher coordination cost and no efficiency gain. Standardisation before or during consolidation is the work; the move itself is logistics. Retained organizations are left undefined. What stays in the business unit is as important as what moves. Where that boundary is vague, work is either done twice or not at all, and the business rebuilds shadow finance and shadow HR teams within two years. And the charging model creates the wrong behaviour. Allocating GBS cost as an overhead with no link to consumption gives business units no reason to moderate demand and no interest in process improvement. Charging per transaction with no volume commitment makes the GBS organization's cost recovery unpredictable. Neither extreme works well.
Practical Guidance for GBS Design
- Settle the governance question before anything else. If the GBS leader cannot overrule a functional leader on process design, you have shared services with a new name.
- Standardise the process before you move it. Moving a bad process to a cheaper location produces a cheaper bad process and locks it in.
- Sequence the functions; do not transition in parallel. Finance first is the usual choice because the processes are best understood and the metrics are established.
- Define the retained organization explicitly, role by role. Ambiguity at this boundary is where duplication and shadow teams come from.
- Appoint end-to-end process owners with real decision rights. Name them, fund them, and give them authority over the whole chain rather than one segment.
- Design the charging model deliberately. It determines business unit behaviour more than any service level agreement you write.
- Measure outcomes, not activity. Cost per invoice falling while days payable outstanding deteriorates is not an improvement; it is a cost transfer.
- Invest in the transition, not just the target state. Knowledge transfer, parallel running and stabilisation are where transitions fail, and they are consistently underfunded.
The Regional Angle
The Gulf occupies an unusual position in GBS design, as both a location for centres and a market whose requirements complicate them. As a location, Dubai and Riyadh have grown as regional GBS hubs — not competing with India or the Philippines on cost, but serving a different purpose: regional headquarters functions, Arabic-language service delivery, time-zone coverage for Europe, Africa and Asia, and proximity to regulators and banking relationships. The typical regional model is now a tiered one, with judgement-intensive and regulator-facing work in the Gulf and high-volume processing in established offshore centres. As a market, the region imposes requirements that generic GBS designs handle badly. Payroll is not consolidatable in the usual way. UAE Wage Protection System submissions, end-of-service gratuity calculations, GOSI contributions and Saudisation quota tracking are country-specific, regulated and change with some frequency. A single global payroll process with local exceptions tends to produce compliance failures; the workable design treats these as genuinely distinct processes running on a shared platform. Entity structures multiply the work. A group with mainland and free-zone entities across several countries has statutory reporting, audit and tax obligations per entity. Consolidation reduces the effort per entity; it does not reduce the number of entities, and GBS business cases built on headcount ratios from single-entity markets routinely underestimate the workload. Bilingual delivery is a design requirement. Supplier communications, employee-facing HR services and customer correspondence frequently need Arabic and English, with both versions accurate. That affects recruitment, document templates, master data design and system configuration, and it is not something to discover during transition. Regulatory change is faster than the model assumes. VAT introduction, corporate tax, ZATCA e-invoicing phases and evolving data protection requirements have each forced process changes inside short windows. A GBS organization here needs a standing capability to absorb regulatory change, not a project each time. And data residency constrains the architecture. Where processing for a Saudi entity must remain in-country under sector rules, the single-instance, single-location assumption underlying many GBS designs does not survive contact with the requirement.
What GBS Became
The model held up better than most management structures of its era, and it has absorbed two significant shifts. Automation arrived first. RPA and then intelligent document processing removed much of the routine volume that justified consolidation on labour cost grounds. Organizations that had built GBS purely as a cost-arbitrage vehicle found the arbitrage shrinking. Those that had built it as a process ownership vehicle found they were the only part of the organization positioned to deploy automation coherently — one platform, one governance model, end-to-end process visibility. The second group did substantially better. AI is producing the same split. An organization with fragmented functional processes, inconsistent master data and no end-to-end ownership cannot deploy AI into its operations in any meaningful way; there is nothing coherent to deploy it into. A GBS organization with standardised processes, consolidated data and a single governance model has exactly the foundation these tools require. Which reframes the original argument. GBS was sold in 2013 as a cost and efficiency play. Its more durable value turned out to be structural: it is the only operating model that produces consolidated process ownership and consolidated data across functions — and those are now the prerequisites for everything else.
Common Questions
What is the difference between shared services and Global Business Services?
Shared services consolidates one function's transactional work, reporting into that function. GBS consolidates multiple functions into a single organization with one leadership structure, one governance model and one technology approach, reporting independently rather than through a functional line.
Why does the reporting line matter so much?
Because most of the remaining value comes from trade-offs between functions in end-to-end processes such as procure-to-pay and hire-to-retire. A leader who reports into one function will optimise for that function; a leader who reports independently can make the cross-functional decision.
What is the most common reason GBS implementations fail?
Governance. The organization is relabelled but functional leaders retain real control over process design and staff, leaving the GBS leader accountable for outcomes without the authority to change anything.
Should all functions transition at the same time?
No. Simultaneous transition across multiple functions and regions creates more concurrent change than any leadership team can absorb. Sequencing — typically finance first, then stabilise before the next function — has a substantially better record.
GBS Design Consultation — Outpace designs the governance, process ownership and location model that makes a multi-function service organization work rather than just renaming one.