THE LEDGER
MKM-R-2026-014New edition: The State of Mid-Market Transformation 2026
01 / 04
MARKHAMConsultation
← EngagementsCase file — Manufacturing · 2025MKM-E-2025-108 · Client-approved · Anonymised

ERP re-platforming under independent oversight

ClientIndustrial manufacturer
Duration14 months
CapabilitiesTechnology · Oversight
Systems deliveryHolisticAutomation
0Days of unplanned downtime at cutover
+2%Final cost against the contracted budget
14 moSelection to stabilised operation
3Scope-change requests approved, of 41 raised

Cutover readiness and post-stabilisation outcomes verified under the Markham Verification Standard at month 14.

01

The situation

An industrial manufacturer was running its third attempt at retiring a 19-year-old ERP. The first attempt had been abandoned at selection. The second reached month 16, consumed $6M, and was stopped by the board. By the time we arrived the system constrained almost everything the operating model wanted to do, and the organisation had learned to distrust any plan that said otherwise, which meant the third attempt had to be credible to people who had twice been told the previous one was going well.

The board’s condition for a third attempt was structural: whoever built the system would not be the party telling the board how the build was going.

02

What the diagnostic found

The forensic review of attempt two found no villain, only architecture. Requirements had been gathered as a wish list rather than derived from an operating model, scope had grown 40% without a single contested change request, and the integrator had been left to report on its own progress. That progress was green until the week it was red.

The enterprise blueprint drawn in the first four weeks exposed the real scope: of 212 requirements carried over from attempt two, 79 traced to no operating decision and were removed before selection began.

03

How Markham helped

Selection ran against the blueprint rather than a feature matrix. Three vendors were tested on their own reference operations, and the contracts were written against outcomes with the exit terms priced before signature. HolisticAutomation was contracted separately for build and integration. Our oversight was contracted to the board rather than to the programme, which bought the board weekly readouts of readiness against baseline and a change forum that could say no without asking the programme director first. Thirty-eight of forty-one requests were declined.

Cutover happened when the written readiness criteria passed. It took one planned weekend and produced zero days of unplanned downtime. What the manufacturer had to supply was the reference operations for testing and the people who ran them, for longer than anyone had budgeted. No contract can shift that part of a re-platforming onto somebody else. The stabilisation period ended with verification rather than a party.

04

Impact in detail

MeasureMonth 0Month 14Change
Unplanned downtime at cutover— (target: 0)0 daysMet
Cost against contracted budget$0 variance+2%Held
Requirements carried212133−79
Order-entry cycle time11 min4 min−64%

Readiness criteria written and agreed before build began; outcomes verified under MKM-F-003 after stabilisation.

05

What we took from it

a

The blueprint deleted more risk than the contract did. Seventy-nine requirements that served no operating decision would have been built, tested and maintained.

b

Separating oversight from delivery changed the reporting physics: the board heard about problems while they were cheap.

c

A contested change forum is the cheapest insurance a programme of this size can buy. Thirty-eight declined requests are why the budget held, and the three that were approved are why the forum was a filter rather than a wall.

Discuss a similar situationThe operating model used