A group creates a central procurement-support team, but every business entity keeps its own forms, urgency labels, and informal escalation contacts. Work has moved to one location without becoming a coherent service. The central team inherits variation while local teams assume that centralization has removed their responsibilities.
Scalable shared services require a defined relationship between the provider and the participating entities. The service needs a repeatable core, explicit local responsibilities, controlled variation, and a funding and capacity model that reflects the work. A common platform can support that design; it cannot establish the agreement by itself.
The group operations leader should begin with a service contract in operational language: what work is accepted, what result is returned, which decisions remain local, and what happens when a request falls outside scope. The hypothetical procurement-support center below illustrates those boundaries without assuming that centralization is always the right answer.
Describe the output, not merely the department being moved. “Centralize procurement administration” can conceal supplier selection, budget approval, request preparation, order release, and dispute resolution. Those activities carry different authority and information needs.
A bounded shared service might check a requisition for required information, retrieve approved catalog details, prepare a draft order, route it to the authorized entity approver, and provide status. Local budget and commercial decisions can remain with the responsible entity under the group’s approved model.
State what makes a request eligible. Required identifiers, approval evidence, scope, and supporting information should be understandable to the submitting team. Define an owned clarification route for incomplete work rather than simply rejecting it and making the central queue look efficient.
Specify the acceptance signal and result. The entity should know when the service has received, accepted, completed, or returned a request for action. Shared services become difficult to manage when each participant interprets those states differently.
Imagine a hypothetical industrial group with three operating entities. Each retains responsibility for its own budgets and commercial commitments. The group proposes a central team for routine requisition preparation and status administration, while authorized purchasing decisions remain where the approved delegation places them.
The initial pilot finds that Entity A supplies a budget reference at intake, Entity B sends it later by email, and Entity C uses the same field to mean a project code. A shared screen does not make those inputs equivalent. The service and entity owners must agree the meaning and required timing before broad rollout.
The design establishes a common core: entity identity, request owner, item or service description, required delivery information, and the evidence needed for the applicable approval route. Additional local requirements are recorded as controlled variants with a responsible owner.
The central team prepares the draft under the correct entity context. It cannot treat approval from one entity as authority for another or change protected supplier information merely to complete the request. Requests involving sensitive payment-detail changes follow the organization’s separately controlled process.
When a fourth business joins the group, the center does not promise immediate onboarding because the existing software has spare user licenses. It assesses demand, data meaning, permissions, approval routes, local obligations, support, and transition capacity. The new entity enters a bounded pilot only when those conditions are understood.
The shared service can then grow through reuse of a defined operating core rather than through an expanding collection of undocumented exceptions. Any benefit remains to be demonstrated across both the center and participating entities, including the work they retain.
Maintain the relevant entity identity throughout the request, records, permissions, and returned result. Shared staff may support several businesses without gaining interchangeable authority across them. Access should follow the approved role and purpose.
Determine which information can be shared and which must remain separated. The correct design depends on ownership, contracts, privacy, regulation, and the organization’s policies. Obtain qualified advice for the actual obligations rather than assuming that common group ownership permits every use.
Keep local accountability clear. Entities may retain responsibility for budget decisions, business justification, supplier relationships, or acceptance of goods and services. Moving administrative activity should not leave those responsibilities unassigned.
Document how cross-entity errors are corrected. A request prepared under the wrong entity needs an owned recovery path and an assessment of any effect already created. A simple reassignment in a queue may not resolve a downstream commercial or financial consequence.
Classify variation by its reason. Some differences reflect a real obligation or operating need; others are preferences or historical habits. Ask the entity owner to explain the consequence of removing the variation and the evidence supporting it.
Use a maintained variant register for differences that remain. Record the scope, owner, rule, supporting rationale, and review condition. This is an operating aid, not a certification framework. Its value is in keeping variation visible and changeable.
Avoid building a separate process for every entity unless the work genuinely requires it. Excessive customization can reduce the reuse that justified the shared service. Equally, forcing incompatible work into one template can shift cost into clarification and error recovery.
The National Audit Office’s 2016 shared-service-centers review identified weaknesses in program design, an integrated business case, and customer commitment in a specific government program. Those findings are a useful caution about the surrounding operating agreement, not a universal estimate of shared-services savings. NAO, Shared service centres, 2016
Model the total work across the center and entities. Local teams still supply information, make decisions, handle some exceptions, and manage the service relationship. Removing local capacity before understanding that retained work can create a bottleneck outside the central team’s measures.
Separate common service cost from the cost of material variants. The funding model should be understandable enough that entities see the consequences of additional requirements. It should not encourage hiding demand or refusing legitimate complexity simply to improve a chargeback metric.
Choose allocation drivers that reflect the service. Raw transaction count may be reasonable for homogeneous work but misleading when some requests require much more effort. Use the simplest defensible model and review it against actual demand and quality.
Plan for peaks and specialist cover. Several entities may share the same month-end or purchasing deadline, limiting the smoothing benefit of consolidation. Shared services need an actual capacity plan rather than an assumption that pooled work is automatically easier to staff.
The center needs authority to maintain the common service, while entities need a legitimate route to raise requirements and challenge performance. Define which decisions the service owner can make and which require group or entity approval.
Use a joint review focused on evidence and decisions. Examine demand, accepted outcomes, exceptions, aging work, quality, and changes requested by entities. Avoid turning the forum into a negotiation over every individual ticket.
Agree how priorities are set when demand exceeds capacity. Labels such as urgent should have a shared meaning tied to business consequence. An entity’s ability to reach a senior contact should not be the hidden rule for queue order.
Make change ownership explicit. A new local rule may require updates to training, data validation, permissions, and support. The requesting entity and central owner should understand the work and authorize the change through the agreed process.
Assess the incoming entity’s actual work before migration. Compare definitions, request types, approval boundaries, volumes, peaks, and exception patterns. A sample of ordinary and difficult cases can reveal differences that a questionnaire misses.
Pilot the whole service, including the retained local responsibilities. Test whether the entity can supply usable requests, whether the center can process them correctly, and whether local approvers and receivers can complete their part. A successful import of records is only one piece of readiness.
Define temporary arrangements and their exit conditions. An acquired business may need a limited bridge while data or policy is aligned. Give that bridge an owner, a known cost, and a review point so it does not become invisible permanent customization.
Maintain continuity during the transition. Preserve an authorized way to handle essential work and reconcile any cases processed outside the new route. Do not retire the prior capability before the receiving service can account for the relevant workload.
Measure accepted outcomes, end-to-end elapsed time, correction, unresolved work, and total effort across the group. A lower central cost can be misleading if entities spend more time preparing requests or recovering mistakes.
Review the cost of adding the next entity. If each addition requires a largely bespoke implementation and extensive permanent support, the service may not have the reusable core its business case assumed. Investigate the reasons before expanding further.
The group should start with one well-bounded service and an explicit division of provider and entity responsibilities. Prove the common core, maintain justified variants, and evaluate the complete operating cost. Shared services scale when new participants can join a dependable agreement, not merely when more work is sent to the same team.
