ServicesPost-implementation recovery
We implemented Workday, SAP or Oracle. Why aren’t we seeing the return?
Because the return was never in the platform. It was in the process changes the platform was supposed to carry, and most programmes freeze those decisions in design and discover the consequence at go-live. Recovery means redesigning the handoffs between functions that the implementation left as they were.
What it looks like
- Teams still re-key the same facts between systems after go-live
- Approvals stop at functional boundaries and wait for someone to chase them
- Finance rebuilds the number in a spreadsheet because the report cannot be defended
- The same exception is explained again at every step that touches it
- Reports disagree between functions, and each one is correct on its own terms
- The benefits case has no owner outside the programme that wrote it
- Headcount that the business case released is still doing the work
Why it happens
The return was traded away in design
Each design decision that preserved an existing way of working removed part of the benefit, and the trade was made in a room that was not tracking benefits. By stabilization you are negotiating with choices made a year earlier.
Nobody owns the space between the functions
Each function configured its own steps well. The work that crosses them was left to people, carried out of institutional knowledge rather than structure, and a platform inherits that rather than resolving it.
The same definition is maintained in several places
Job architecture, org structure, reporting lines and cost centres are rebuilt independently by each system that needs them, so no downstream number can be defended without reconciliation first.
How we approach it
We start with one workflow: a process that crosses three or more functions, mapped end to end with the people who own its steps.
- Trace one hire and one termination end to end, before anything is designed.
- Inventory the decisions, not the datasets, and name an accountable executive for each number.
- Convert every remaining benefit into the operating change that produces it, and give each one an owner outside the programme.
- Name one author for each field, and say so in writing.
- Classify every variation request as statutory, collectively agreed, or habitual — by reading the role, not the request.
What you get
- A map of one end-to-end process, with every point the same fact is re-established marked on it
- A named author for each field, and a named executive for each number an executive decides on
- A benefits register that maps open design decisions to the benefits they affect
- The number of systems into which one hire’s name, start date, manager and cost centre are typed by a person
- The share of last month’s variance attributable to named records within five working days of close
Related perspectives
Paper 02
Where ERP Returns Are Actually Decided
The return is traded away in design meetings, long before anyone measures it
Paper 01
From Data Lake to Decision Layer
Why finance keeps rebuilding the number in Excel — and what it takes to stop
Paper 06
The 98% Problem
How a workforce forecast gets to 98% accuracy — by fixing the records, not the model
Paper 15
Hire to Retire Runs on One Event
The hire happened once. Whether it is entered once is an architecture decision, not an HR one.
Paper 08
Global HRIS Modernization Done Right
Local variation arrives as a configuration request. It is never a configuration question.
Questions we are asked
- What should we do after a Workday implementation?
- Start with one process that crosses three or more functions, and trace a single employment event through every system that touches it. That shows where the same fact is being re-entered and where approvals stop at a boundary. Those two findings are usually enough to decide what is worth redesigning first.
- How do we get more ROI from SAP without replacing it?
- Most of what a horizontal operating model needs is already licensed and partly configured. It tends to be defined inconsistently across platforms rather than missing. We define it once, name the authoritative source for each element, and set how it flows downstream, so the platforms you own do more rather than being replaced.
- Can you work alongside our systems integrator?
- Yes. We sit on the business side of the programme: deciding what the process should be, who owns which decision and what each role may approve, while the integrator builds against those decisions. The two roles are complementary, and the integrator gets answers rather than assumptions.
- Where do you start?
- One workflow. Choose a process that crosses three or more functions, and we map it end to end with the people who own its steps, marking every place the same problem gets solved twice.
Value. Realized.
Start with one workflow.
Choose one process that crosses three or more functions. We map it end to end with you, and mark every place the same problem gets solved twice.