Where ERP Returns Are Actually Decided

The business case that released the capital is written in outcomes: days off the close, points of forecast accuracy, working capital, cost per transaction. The programme that spends it is governed in inputs: design decisions closed, objects migrated, scripts passed, cutover readiness. Both documents are competent. Nobody converts between them.

So every design trade-off is settled on the one axis the programme can measure weekly: the schedule. Each settlement removes a piece of a benefit that appears in no plan. Go-live is where you find out which pieces.

What actually happened

The business was a CPG group of roughly $2–3 billion in revenue, privately held before its listing on the TSX, growing by acquisition, with SAP as the transactional backbone and payroll running across approximately 21 countries. Polymath’s founder ran global human capital planning. Payroll was the part of it nobody wanted to open.

Twenty-one countries meant a different arrangement in almost every one: local providers, an aggregator across some regions, statutory filings outside the platform, and internal steps that had grown up around whatever each vendor would not do. Workday came under his remit in 2017, and the obvious plan was to configure what existed, country by country, and get it live.

The team did not do that first. They spent weeks mapping what actually happened in each country: who initiated a change, who approved it, where the same data was re-keyed, which calculations the company was paying a vendor to perform, and which of those the platform would perform anyway. The map was ugly. There were approval steps nobody could name an owner for, and the same headcount change was entered as many as three times.

Only then did they design. One set of initiator, reviewer and approver rules across the countries that could carry them. One change calendar, cut against the payroll cycle rather than the fiscal one, because in most months the two do not land together. One data path into payroll instead of the parallel routes each country had built.

Two things came out of that which were in nobody’s plan. The 21-country payroll solution they designed carried about $500K in identified annual savings, most of it work the company stopped doing rather than a fee it stopped paying. And because the redesign changed what the company was buying, they reopened the commercial terms and negotiated payroll and Workday arrangements worth roughly $350K a year. Neither figure could have been found afterwards: once configuration locks, the vendor scope is fixed by the process you brought with you. Nobody scopes a programme to find money that does not exist yet, which is precisely why it is only ever found before the design freezes.

What a client gets from Polymath in that window is the money still findable there, and it is found by mapping what actually happens before anyone agrees what gets configured.

Why it happens

Capital is approved in outcome units because that is the only currency a board recognizes. Days off the close. Points of forecast accuracy. Working capital released. The case has to be written that way or it is not funded.

The moment it is funded, the programme is stood up, and a programme cannot be run in those units. You cannot report weekly on days off the close eleven months before the close changes. So governance converts to inputs: decisions closed, objects migrated, scripts passed, defects burned down. That conversion is not a mistake. It is the only way to run the work.

The failure is that the conversion runs one way and is never reversed. No document maps design decisions back to the benefits they carry. Ask which configuration choices the working capital release depends on and you will be shown a process diagram, which is not an answer.

That absence has a precise consequence. Design generates hundreds of trade-offs: standardize or keep the local variant, redesign the process or lift the current one, cleanse the data or migrate it as it stands. Each needs a decision rule, and the programme has one — does this threaten the date — because that is the only consequence it can observe.

Every one of those decisions is a withdrawal from the business case. None of them is recorded as one.

The bias is not random, either. Schedule pressure falls hardest on work with no observable finish line. Configuration, migration and testing have one. Process redesign, data ownership and decision rights do not; they conclude when people change how they behave. So the programme defends what it can measure and defers what it cannot — which is the material the benefit was made of.

At go-live the outcome units reappear, because that is when somebody finally measures the close, the forecast, the cycle. It is the first time in a year anyone has looked. The design team has dispersed and the system has been declared live, so the gap between case and result has no owner. Stabilization means making the system behave as designed. It cannot recover a benefit the design removed.

The strongest objection

The strongest case against this argument: we know, and that is what phase two is for.

Phase two is real and it does sometimes happen. Concede that fully: enterprises do optimize after go-live, and staging benefit work against a stable platform can be the right sequence.

It is the funding that rarely appears. Phase two requests capital for a system the organization has already declared successful, competing against initiatives with fresh cases and no history. And the request is awkward in a specific way: asking for money to obtain benefits already taken into the plan is hard to distinguish, in that room, from conceding the first case was wrong. So it is scoped down to defect remediation and reporting fixes — the easiest items to justify, the least connected to the economics.

The better objection is different: something always has to be cut, and a programme that cuts nothing never lands. True without qualification, and cutting is the job. What we propose is not an argument against trade-offs but against making them blind. Removing scope you can name is management. Removing benefit you cannot see surfaces a year later as a variance nobody agreed to.

The method

We run six steps, in this order. One and five are the ones that get skipped, and they decide the result.

1. We convert every benefit into the operating change that produces it, before design starts. For each line of your business case we write the change in someone’s week that creates it. Not the capability — the change; we do not count a capability as a benefit. Days off the close becomes a named reconciliation that stops happening because a rule changed. The trade-off we accept: this exposes benefits with no operating change behind them, and the case shrinks before the programme begins. Skip it and you govern a number nobody can trace to a decision.
2. We give each benefit an owner outside the programme. The owner is whoever’s routine has to change — the controller, the planner, the operations lead — not the sponsor and not the programme director. We ask them to sign that the change is possible in their environment, on that date, and we take a refusal as an answer. The trade-off we accept: some will decline, which is useful information at the cheapest moment. Skip it and the benefit belongs to a programme that closes before anyone measures it.
3. We keep one register mapping open design decisions to benefits, and we put it on your steering agenda. A single page, kept by someone nobody ignores: which live design decisions touch which benefits. We do not need it to be precise; we need it to exist, so the question gets asked while the decision is open. The trade-off we accept: it puts a real argument into a meeting that would rather review a burndown chart. Skip it and the conversion stays one-directional, which is the failure itself.
4. We price every material trade-off in benefit terms before it is decided. A range is sufficient. If keeping the local variant costs a third of the standardization benefit, your sponsor hears that before choosing, not at year end. We keep a running total of benefit traded away and we report it beside the schedule. The trade-off we accept: the total will be disputed, which beats not knowing. Skip it and every trade-off resolves to the date.
5. We give process redesign a definition of done and we defend it like a test script. Decision rights, data ownership and exception handling need named completion criteria and a date, or they lose every scheduling argument to work that has them. We put them on the critical path, where cutting them takes a decision rather than a drift. Redesign that finishes after configuration freezes is a change request, and we price it accordingly. The trade-off we accept: the plan lengthens exactly when everyone wants it shorter. Skip it and you go live on the new system running the old process.
6. We measure one outcome unit before go-live, not after. We run one real cycle — a close, a reforecast, a replenishment run — on the new design during testing, with your operating team, against the clock. The trade-off we accept: it costs weeks in the tightest part of the plan and it will produce bad news, which is the purpose. Skip it and the first measurement of what you bought happens after the people who could fix it have gone.

Notice what we leave out: the software, the integrator, the methodology. Those are handled competently in most programmes. The work we take on sits between them — the conversion between your two documents, and the process redesign that has to finish before configuration freezes. Don’t automate a broken process is not a remark about quality. It is a statement about money and sequence: in Procure-to-Pay the benefit is a vendor scope and an approval path, and configuration fixes both. Redesign after go-live and you are paying to change a system rather than a process.

Evidence and measures

The same programme read three ways. The distance between columns two and three is the return:

Five measures worth tracking over ninety days. None requires a new system:

— Proportion of business-case benefits with a named owner outside the programme and an agreed date.

— Design decisions closed last month for which nobody can say which benefit they touch.

— Days between a design trade-off being proposed and someone stating its benefit consequence. If the answer is never, record never.

— Steering-committee minutes spent on schedule and defects, against minutes spent on benefit conversion. Read the agendas rather than asking. — Benefits that could be measured today, on the current process. A benefit with no baseline now has no proof later.

If those five move, the design phase is being governed on economics. If only the defect burndown moved, the programme will deliver whatever it happens to deliver.

How Polymath solves this

We start in the window a platform programme leaves open: after your business case is approved, before your design freezes. Our first weeks go on walking a Procure-to-Pay transaction end to end — requisition, approval, receipt, invoice, payment, and everything a vendor is paid to do in between — counting handoffs, re-keyed fields and approval steps with no named owner. We run this as Process Redesign, and what we hand you is a redesigned process with the configuration decision it forces attached to each step.

We do not write that redesign up and send it over. We build it in your design sessions themselves, alongside the integrator and your process owners, recording the operating change and the configuration choice in the same document — so a trade-off cannot be settled on the schedule without someone seeing what it costs. Where configuration has to change, we make the change with the team who will maintain it after we have gone, and then we hand it back to them.

What carries forward is the approval structure. Once a redesigned Procure-to-Pay path has settled thresholds, delegation and vendor master ownership, your spend control, audit evidence and supplier consolidation stop being separate initiatives with separate discovery, and the next module is configured against decision rights that already hold. That is why the second module costs less than the first, and the third costs less again.

What it costs to do nothing

The capital is the smallest part of the loss, because it is spent either way. The expensive part is that the benefit case has already been taken into the plan. Finance banked the days off the close and the effort the automation was meant to remove; when they do not arrive, the shortfall surfaces as a variance in a function that never signed for it. The second attempt costs more than the first. Changing a design on a live system means regression, retraining and a user base that has already learned the version you are replacing. Work that was cheap in a design meeting is expensive in production.

The third cost outlasts the programme. Every platform case afterwards is read by a board that remembers this one, and discounted before it is heard.

The return was never lost at go-live. It was spent, decision by decision, in rooms where nobody was counting. Those rooms are where we start.