Tech Transformation Costs: Beyond the Blueprint
The cost levers nobody budgets for, and the ones nobody pulls after go-live
Roger Tchalla | April 2026
Two months before phase one go-live, a Canadian government agency running a large-scale S/4HANA Selective Transformation could not answer a basic question: are we ready?
The architecture decisions had been sound. Selective Transformation with a clear scope boundary. Reasonable SI model. Solid data strategy. The program had already spent well beyond its original budget. And yet, with eight weeks to go, nobody in the room could confirm the status of individual workstreams, quantify the remaining risk, or say with confidence whether the go-live date was real. The governance structure that should have been providing that visibility for months had not kept pace with the program.
The response was the only one available at that point: an urgent, expensive onboarding of an army of external consultants to review every workstream, assess readiness, confirm go or no-go, supervise the go-live itself, and stabilize the system through the chaotic weeks that followed. The cost of that intervention dwarfed what continuous governance would have cost from the beginning. The program eventually went live. But the price of arriving there without visibility was paid several times over.
This is not an unusual story. It is the default story. And the reason it keeps happening is that the industry frames ERP cost management as a pre-project exercise. Choose the right implementation path. Set the right architecture. Pull the right levers before delivery starts. That framing is correct, but it is incomplete. It accounts for six of the ten levers that determine total transformation cost. The other four are invisible in most business cases.
The full map
Last year, I co-authored a piece with colleagues at BCG Platinion identifying six architecture levers that account for the majority of controllable ERP spend. Those levers are real and important. But they only cover decisions made before delivery starts.
The complete picture has three phases and ten levers.
| Cost Lever | Phase | Compounds | What It Governs |
|---|---|---|---|
| The Blueprint — Architecture Decisions | |||
| 1. Process transformation scope | Pre-program | Requirements | How much to redesign |
| 2. SI strategy | Pre-program | Mobilization | Who builds it and how |
| 3. Data harmonization depth | Pre-program | Design / build | How much value from data |
| 4. Integration modernization | Pre-program | Design | How systems connect |
| 5. Cloud and instance strategy | Pre-program | Infrastructure | Where it runs |
| 6. Best-of-breed scope | Pre-program | Strategy | What sits inside vs. outside ERP |
| The Build — Disciplines During Delivery | |||
| 7. Delivery governance | During delivery | Every week | Whether the build stays on plan |
| 8. Organizational readiness | During delivery | Design – hypercare | Whether the org can use what was built |
| The Operation — Levers After Go-Live | |||
| 9. Operations intelligence | Post go-live | Continuously | Whether the system remembers why it was built this way |
| 10. Support model governance | Post go-live | AMS cycle | Whether the client controls support cost |
10 levers — from architecture to maintenance and evolutions
The architecture levers are set once. The delivery levers compound every week. The operations levers run indefinitely. This article covers levers 7 and 8. The next covers 9 and 10.
Lever 7: Delivery governance
A scope decision is made in a design workshop but not formally documented. Three weeks later, a related requirement surfaces. Because the original decision is invisible, the team treats it as new scope. A change request is raised. The change request triggers integration rework. The rework delays testing. The testing delay compresses cutover preparation. Six months after a single undocumented decision, the program is four weeks late and $2M over budget.
This is the pattern. Not a technology failure or an architecture mistake. A visibility failure. The blueprint was fine. The construction management was not.
The pattern repeats everywhere: RAID logs updated reactively by the person with the least context. Steering packs assembled the night before from stale data, forcing the committee into reviewing status instead of making decisions. Change requests impact-assessed through hallway conversations. Test readiness demonstrated through spreadsheet exercises that consume days and still leave gaps. Scope decisions made verbally in workshops but never formally recorded, so when a related requirement surfaces three months later, the team treats it as new scope rather than a revisit of an existing trade-off. Each failure is small. Collectively, they account for 30 to 50% of unplanned cost. This is program governance as a discipline, not as a reporting exercise.
Why it persists: intelligence vs. judgement
Governance has been difficult to maintain because it requires two fundamentally different types of work, and until recently, both were done by the same person.
Maintaining a RAID register, tracking test coverage, monitoring data migration readiness, estimating change request impact: this is intelligence work. Verifiable, repeatable, structured. It does not require a senior practitioner. It requires consistency, every day, without gaps.
Deciding what to escalate, whether a go-live date is real or aspirational, how to frame a risk for a skeptical board, when to intervene with an underperforming SI: that is judgement work. It requires experience and pattern recognition built across dozens of programs.
The program director who should be making scope trade-off decisions spends Sunday evening assembling a status pack from three spreadsheets. The delivery lead who should be pattern-matching across workstream risks is manually reconciling test readiness evidence. The senior consultant who should be diagnosing whether the SI relationship needs intervention is updating a RAID log that nobody reads until it is too late.
Purpose-built AI can now handle the intelligence layer as a continuous, verifiable service. A RAID log maintained in real time from live program data is not a faster version of a weekly manual update. It is a structurally different tool. A steering pack generated from current data and organized around decisions is not a faster status report. It is a functional transformation of the steering committee from a reporting audience into a decision-making body.
When the intelligence layer runs continuously, senior practitioners are freed to do the work only they can do. That is where the real value of experienced practitioners lives, and it is precisely the work that gets crowded out when those same practitioners are consumed by intelligence tasks.
Lever 8: Organizational readiness
On a large S/4HANA program I was involved with, the training budget was cut by 40% in month eight to offset a scope overrun in integration testing. The go-live date held. The system worked. And in the first ninety days of production, the support desk logged more than 800 tickets, the majority of which were users unable to perform basic tasks the system was configured to handle.
The investigation cost ran to six figures. The root cause of nearly every ticket was the same: the organization was not ready to use what had been built.
Most business cases treat training and change management as a project cost to be minimized. The budget line is set as a percentage of total program spend, rarely more than 10%, and it is the first line cut when the program is over budget. The implicit assumption is that organizational readiness is a deliverable you produce near the end and hand to the business.
That assumption is wrong, and the cost of getting it wrong does not appear in the project budget. It appears in the 24 months that follow.
Lever 8 has three components. Training depth: how many users, how many hours, in what format. Under-investing here saves 2 to 5% of program cost and generates 3 to 10 times that amount in post-go-live support spend. Change management scope: stakeholder alignment, communications, resistance management, executive sponsorship. The cost of getting this wrong is measured in adoption velocity, how quickly users move from the old way of working to the new one. User enablement design: embedded help, job aids, super-user networks, ongoing reinforcement. This is the component most often entirely absent from business cases. Formal training produces short-term knowledge. Enablement infrastructure produces sustained capability.
The critical design decision is segmentation. Not every user needs the same investment. Users whose daily work changes fundamentally and who have no adjacent skills to draw on — a warehouse supervisor moving from paper-based picking to mobile RF scanning, a controller shifting from spreadsheet allocations to S/4HANA cost center hierarchies — need deep enablement that extends well past go-live: embedded support, job aids, super-user networks, and dedicated coaching for months, not days. Users whose work changes marginally need awareness, not training. Most organizations apply the same program to both populations, which means the high-impact users are underprepared and the low-impact users resent the time spent. Segmenting by change impact and skill proximity is the difference between a training budget and a readiness investment.
The intelligence/judgement split applies here too. Training needs analysis, change impact mapping, and readiness measurement are intelligence work. Designing a training approach for a resistant population, managing executive sponsors through the difficult middle months, and deciding whether the metrics mask underlying resistance: that is judgement work. The intelligence activities are increasingly automatable. The judgement activities are not.
The causal chain
Levers 7 and 8 are not isolated. There is a direct chain between them and what happens after go-live.
When lever 7 is weak, undocumented decisions produce a system that diverges from its design intent. Those divergences surface as production incidents. When lever 8 is weak, under-trained users produce a workforce that cannot operate the system as intended. Those capability gaps surface as support tickets.
In both cases, the investigation cost falls on the client. In both cases, the answers already exist in the project record. The client is paying to rediscover what was already known. The question is whether the project record survives in a form that can be queried against every production incident — or whether it sits in a SharePoint folder that nobody opens after the first month. Levers 9 and 10, the subject of the next article, address this directly.
The AI acceleration trap
A brief but important note on AI in this context. Three distinct categories of AI are now being deployed across ERP programs, and confusing them is dangerous.
Execution-layer AI accelerates the technical build: code intelligence, fit-to-standard analysis, automated code generation, and automated test script generation that compresses regression cycles from weeks to days. The shift underway is from copilots (suggesting code, flagging issues) to autonomous agents (generating configuration, running analysis overnight, producing deployment-ready artifacts). That acceleration is real — 20 to 40% faster on the technical build — and it is exactly why the other two categories matter more, not less. Governance-layer AI addresses lever 7: continuous risk visibility, automated decision traceability, steering support. It compresses the indirect cost of poor oversight. Adoption-layer AI addresses lever 8: training content generation, change impact mapping, readiness tracking. It compresses the cost of preparing the organization.
All three reduce total cost. Deploying one without the others creates a specific trap.
Execution AI without governance makes the program build faster while scope drift compounds faster. Code ships before the governance structure can verify alignment with the blueprint. The steering committee, still working from manually assembled packs, cannot keep pace. Execution AI without adoption investment delivers a modern system to an unprepared organization. The go-live date arrives with a well-built product and a user base that is not ready for it.
The organizations that will achieve the best cost outcomes deploy all three. The tools that accelerate the build are powerful. But they do not govern the build, and they do not prepare the organization. Those remain separate disciplines, and the seventh and eighth entries in the cost equation.
What happens after go-live
The six architecture levers determine what you are building. Levers 7 and 8 determine whether you build it on time, on budget, and with an organization that can use it.
But most organizations treat go-live as the finish line. It is not. The decisions made during the project will explain 80% of what breaks in the first 24 months. The workforce that was prepared, or underprepared, during delivery will determine how many of those issues require expensive external investigation.
Most organizations enter that phase with no structured mechanism to manage it. The project team has rolled off. The documentation is archived. The institutional memory that would connect today’s production incident to last year’s design decision has evaporated. The client pays consultants $250 to $1,000 per investigation to rediscover what the project already knew. And that cost runs not for weeks, but for years.
The next article in this series examines levers 9 and 10: what happens when the project team leaves and the institutional memory goes with them.
Interactive Tool
ERP Cost Estimator
Map your own transformation across all ten levers. Input your program parameters — scope, SI model, data strategy, governance maturity, organizational readiness — and see where cost is accumulating and which levers still have room to move.
This is not a pricing calculator. It is a diagnostic. The ranges are drawn from patterns across real programs, not industry averages. The point is not a number — it is seeing which levers you are managing and which ones are running unmanaged.
Levers 7 and 8 compound every week they go unmanaged.
If your program is in flight and governance has not kept pace with the build, that gap is growing. We help close it.
Let’s Talk →