The short answer
A shared services centre consolidates work. It does not automatically consolidate processes.
The usual sequence is that several business units transfer a function to a central team. The transfer works: headcount consolidates, cost per transaction falls, service levels stabilize. The efficiency case is delivered.
What frequently does not happen is standardization. Each business unit brought its own version of the process, and the central team absorbed all of them. Six months later one team is running four variants of accounts payable, and the variation is invisible because it is inside a function that reports as one.
That produces a specific pattern when the automation conversation starts. The centre knows its cost per transaction and its service levels. It usually cannot say which processes carry the most recoverable hours, because the measurement was built around throughput rather than around where the effort goes.
The recoverable hours are almost always larger than expected and distributed differently than assumed.
Key takeaways
- Consolidation delivers cost reduction. Standardization is a separate programme that often does not follow.
- Shared services metrics measure throughput, which does not reveal where effort concentrates.
- Manual validation and reconciliation between systems is the dominant hidden cost in most centres.
- Variants inherited from business units persist for years because nobody is accountable for reconciling them.
- Automation potential varies widely by process, and the ranking is rarely what leadership expects.
- Quantifying hours per process per area is the input the automation roadmap requires and the one most centres lack.
Why shared services accumulate variants
The transfer preserved the process
When a business unit hands over a function, it hands over its version. Absorbing it as-is is the fastest path to a working transfer, and standardizing during migration adds risk to a project that already has plenty.
The intention is usually to standardize afterward. Afterward arrives with a new migration wave, a system upgrade, or a volume increase, and the variants remain.
Local requirements are real
Some variation exists for legitimate reasons. Tax treatment differs by country. Regulatory reporting differs by entity. A particular customer contract has terms the standard flow cannot handle.
The problem is that legitimate variation and inherited variation look identical from the centre. Both appear as "that business unit does it differently," and distinguishing them requires knowing why, which is not recorded anywhere.
Nobody owns the reconciliation
A shared services leader owns service levels and cost. Business unit leaders own their outcomes. Reconciling four variants into one requires a decision that affects all of them and benefits the centre, which is a difficult sponsorship position.
Variants therefore persist by default rather than by decision.
Where the hours actually go
Shared services centres are well instrumented for volume and poorly instrumented for effort. The distinction matters because the two are not proportional across processes.
| Area | Typical hidden effort | Why it does not appear in reporting |
|---|---|---|
| Procurement | Manual supplier validation, non-standard request handling, chasing approvals | Recorded as cycle time, not as touch time |
| Accounts payable | Exception handling, invoice matching failures, duplicate checks | Absorbed into per-invoice cost |
| Treasury | Manual reconciliation across banks and entities, cash position assembly | Treated as a specialist task rather than a process |
| Credit and collections | Building customer status views by hand across systems | Attributed to relationship management |
| Commercial support | Pricing verification, order corrections, local exception handling | Sits between shared services and the business unit |
| Planning and costing | Spreadsheet consolidation for reporting cycles | Periodic, so it disappears from weekly measures |
The pattern across these is consistent. The effort concentrates in validation, reconciliation and exception handling, none of which is what the process is nominally about, and all of which scale with volume.
Why the automation roadmap is usually built on the wrong ranking
Most shared services automation programmes rank candidates by transaction volume, because volume is the number that exists.
Volume is a poor proxy for recoverable effort. A high-volume process running cleanly through a system consumes little manual time per transaction. A lower-volume process with a high exception rate and manual validation between systems can consume considerably more in aggregate.
Three consequences follow.
The wrong processes get automated first. The visible ones, which are frequently the ones already working.
Automation potential gets estimated rather than measured. In the absence of hours per process, potential is inferred from process type, which produces confident numbers with no basis.
The business case is unverifiable afterward. Without a baseline in hours, nobody can demonstrate that the automation improved anything beyond a throughput figure that was already acceptable.
Hours before tools
What a shared services roadmap needs, in order
| Step | Question | Output |
|---|---|---|
| 1 | Where do the hours go, per process, per area? | An effort baseline in hours per week |
| 2 | Which of those hours are validation, reconciliation or exception handling? | The recoverable portion |
| 3 | Which variants exist and why? | Legitimate variation separated from inherited |
| 4 | What is the disposition for each? | Remove, standardize, integrate, or automate |
| 5 | Which tool builds the subset that should be automated? | A scoped platform decision |
Most programmes begin at step 5. Steps 1 through 3 determine whether step 5 produces value.
Separating legitimate variation from inherited variation
This is the highest-return analysis in a shared services improvement programme and the one most frequently skipped.
For each variant, three questions:
What requirement produces this? A tax rule, a regulatory obligation, a contractual term, or a system limitation are real. "That is how the business unit always did it" is inherited.
Does the requirement still exist? Variants frequently outlive their causes. A step added for a regulation that changed, a check added after an incident that was resolved, a workaround for a system that was replaced.
Who would have to agree to remove it? A variant with a named owner who can approve its removal is actionable. One with no identifiable owner will persist regardless of the analysis.
Centres that run this analysis typically find that a meaningful share of variants are inherited rather than required, and that consolidating them removes more effort than automating them would have.
What good measurement looks like
The target is hours per week, per process, per area, with the composition of those hours identified.
That is a different measurement from cost per transaction, and it cannot be derived from it. It requires knowing what the people in each area actually spend their time on, which is not in any system because validation and reconciliation produce no transaction records of their own.
Two properties make the measurement useful:
Granularity by area. An aggregate figure for the centre hides the distribution, and the distribution is the finding.
Composition. Knowing that accounts payable consumes 34 hours per week is useful. Knowing which portion of that is exception handling versus standard processing is what determines the disposition.
Where Horizon fits
Horizon is an AI-powered continuous discovery platform. In a shared services context it produces the effort baseline that steps 1 through 3 require.
Discovery Cycles run AI-led interviews across the areas inside a centre, asynchronously and without blocking calendars, which matters when the teams being asked are the ones carrying the backlog. The Insights Dashboard quantifies the time impact per area and ranks findings by impact and effort. The Process Library structures the resulting documentation, which is what makes variant comparison across business units possible, and the Initiatives Dashboard converts priorities into business cases with owners.
Grupo HZ, a multi-company industrial holding with more than 65 years in packaging and paperboard, operating across Argentina, Brazil and Chile with a shared services centre covering Administration, Finance, Procurement and Treasury across business units including two named operating companies, is a direct example.
Before the engagement, spreadsheets, email and manual validations were the backbone of critical processes, with no integrated workflows. There was no visibility into where time was being lost or which processes had the highest automation potential. Pricing errors in the ERP went undetected without cross-checks, creating downstream issues in billing and auditing.
Horizon ran 55 structured interviews across six departments asynchronously. It identified 33 actionable findings and quantified the time impact of each inefficiency down to the hour, per area: Procurement at 48.3 hours per week, Accounts Payable at 34, Treasury at 21.55, Credit and Collections at 10.5, Sales and Commercial in Chile at 6.5, and Planning and Costing at 2.9. Roughly 123 hours per week in total, with 50 to 90% automation potential identified across all areas and specific solution types mapped to specific processes.
The distribution is the point. Procurement carried nearly four times the recoverable effort of Credit and Collections, which is the kind of ranking that a volume-based prioritization would not have produced.
The engagement saved 159 discovery hours against the manual approach, reallocated three FTEs to strategic work without adding headcount, and returned 182% ROI. The stated shift was from a framing of needing more people to a framing of needing better processes, with executive-ready evidence to align business unit leaders around a shared automation agenda.
That last element matters in a shared services context specifically. Variant consolidation requires business unit agreement, and evidence quantified per area is what makes that conversation possible.
That is one engagement under specific conditions rather than a projection for any organization.
Shared services improvement checklist
- Do you know hours per week per process, per area, rather than cost per transaction?
- Do you know what proportion of those hours is validation, reconciliation and exception handling?
- Have you catalogued the variants inherited from each business unit?
- For each variant, do you know which requirement produces it and whether that requirement still exists?
- Does each variant have a named owner who could approve its removal?
- Is your automation ranking based on measured effort or on transaction volume?
- Have you separated processes that should be standardized from processes that should be automated?
- Do business unit leaders have evidence at their own level, not only the centre aggregate?
- Is there a baseline that would let you demonstrate improvement afterward?
FAQ
What is shared services process improvement?
The programme of standardizing, simplifying and automating processes inside a shared services or global business services centre after consolidation. It is distinct from the consolidation itself, which delivers cost reduction through centralization without necessarily changing how the work is performed.
Why do shared services centres end up with multiple process variants?
Because each business unit transfers its own version during migration, and absorbing them as-is is the fastest path to a working transfer. Standardization is usually deferred, and the deferral persists through subsequent migration waves, system changes and volume growth. Reconciling variants also requires business unit agreement, which is a difficult sponsorship position for a centre leader.
How do you find automation opportunities in shared services?
Measure hours per week per process per area, and identify what portion of those hours is validation, reconciliation and exception handling. Transaction volume is a poor proxy for recoverable effort, because a high-volume process running cleanly through a system consumes little manual time while a lower-volume process with heavy exception handling can consume considerably more.
What is the difference between standardizing and automating a shared services process?
Standardizing reduces the number of variants performing the same function, which removes effort without building anything. Automating reduces the manual work inside a variant. Automating before standardizing produces multiple automations of the same function, which multiplies maintenance cost.
Should shared services standardize before automating?
Generally yes, for the reason above. Building automation for four variants of a process costs roughly four times as much to build and maintain as building it once for a standardized version. The exception is when a variant exists for a legitimate regulatory or contractual reason that will persist.
How do you get business unit agreement to remove a variant?
With evidence quantified at their level rather than at the centre aggregate. A business unit leader asked to give up their version of a process needs to see what it costs and what the standard version would deliver for them specifically. Centre-level totals do not answer that question.
Consolidation was the first half
Moving the work into one place delivers a cost reduction that is real and measurable. It also makes the next opportunity harder to see, because the variation that came with the work is now inside a function that reports as one number.
Finding where the hours actually go, per process and per area, is what turns a consolidated centre into an improving one.
See it. Fix it. Scale it.