At the Las Vegas Grand Prix last November, McLaren finished second and fourth. By the time the trucks were loaded, they had finished nowhere.
Both cars were disqualified in post-race inspection for excessive wear on the skid blocks under the floor. They’re the wooden planks the FIA uses to check teams aren’t running too low to the ground. The cause, McLaren said, was unexpected porpoising at race conditions. That’s the violent bouncing that happens when a Formula One car’s aerodynamics stall and re-engage at high speed, slamming the floor against the track. The simulators hadn’t shown it. The race did.
McLaren had not been reckless.
“What happened in Vegas was due to an anomaly in the behaviour of the car, rather than the outcome of an excessive or unreasonable setup,” said team principal Andrea Stella afterwards. They had every test a Formula One team is supposed to run. The model didn’t show them what would happen when the real race, on the real circuit, at real speed, met the real car.
Lando Norris and Oscar Piastri lost a combined 33 points in Vegas. Two weeks later in Abu Dhabi, Norris won the championship by two. The gap that didn’t show in the model nearly cost McLaren the title.
That’s the gap that ends SAP transformations.
The Numbers
Less than one in ten S/4HANA programmes finish on schedule. Sixty-five per cent miss budget. Sixty-five per cent miss the quality bar the business set for them.
The figures come from Horváth’s Business Transformation Unlocked study. They surveyed 200 companies across six countries, all running SAP, all with revenues above €200 million. Not a small sample.
And the causes are not technical. Seventy-eight per cent of executives said too many topics had been integrated into the transformation. Only twenty-one per cent had brought change consultants in at all.
Scope expansion. Blueprint revisions. Governance gaps. Failures the model never saw.
Tech Works. It’s The Context That Kills You
The Horváth numbers don’t say SAP is broken. By the time most programmes go live, the system works. It posts the transactions. It runs the reports. It enforces the controls.
The system isn’t the problem. Everything around the system is the problem.
The volume of orders that arrives on the last Friday of the quarter. The interface to the warehouse that drops for 40 minutes a day. The 15 years of local workarounds that disappear overnight when standardisation hits. The approver in São Paulo who’s on holiday during cutover weekend.
None of that is in the test script. The test script asks: can the system process a sales order? Yes. Tick. Then go-live arrives, the system meets the business, and the gap opens.
Test scripts prove the system works. They do not prove the business will.
That’s the gap McLaren found in Vegas. The car was legal. The technology hadn’t failed. The context had broken it.
This is why “we’ve done extensive testing” is not a defence. The question isn’t whether the system works. The question is whether the business will still work when the system changes.
A Bar Of Dairy Milk
A bar of Dairy Milk looks simple. Purple wrapper. Familiar shape. Milk chocolate. Delicious.
Behind it sits one of the most complex operating machines in global business. Operations in around 80 countries. 91,000 employees. An ERP estate shaped by years of acquisition. (Cadbury joined the group in 2010.) It all sits on top of 15 years of local customisations and workarounds nobody calls workarounds anymore.
That’s the business.
Mondelēz, which owns Dairy Milk along with Oreo and Toblerone, is moving from SAP ECC to S/4HANA. Almost everyone running SAP has to before mainstream support ends in 2027. What’s interesting is what Mondelēz decided it needed to do first.
The company picked Celonis as the platform for understanding how its business runs.
“Our ambition is to create a digital twin of the enterprise, which enables us to mirror all of our processes and capabilities in a digital way,” Rossana Rizzotto, who runs the office of Mondelēz’s CIDO, told The Register in February.
Process mining is the starting point. Where orders wait, where approvals stall, where exceptions pile up, where the happy-path process in the workshop bears little resemblance to the work being done in the business.
That is valuable. But it is not the same as knowing what will happen when the process changes.
For that, you need simulation.
Mondelēz is pointing in the right direction. Most companies talking about digital twins are still at the first step.
How To Do It
This doesn’t need a grand digital twin programme. That’s exactly how good ideas get bloated into governance committees and two-year roadmaps.
Start smaller. Pick five business moments where failure would hurt most. Consider month-end close, order-to-cash, purchase-to-pay, plan-to-produce, cutover weekend itself.
For each, build a working model. Not a process diagram, a model that runs. Then feed it the real business.
Real volumes. Not averages. The 4,000 invoices that arrive on the last working day of the quarter because that’s when customers pay.
Real exceptions. The credit blocks released manually because the rule was set up wrong in 2018 and nobody’s gone back to fix it.
Real interfaces. The bank file that lands at 6:03 instead of 6:00 and pushes the morning treasury run by 10 minutes. That’s fine in test, ruinous at month-end.
Real calendars. The truth that statutory close, payroll cut-off and a regulatory filing deadline land on the same day.
Then change something. Alter the cutover sequence. Take the new design, the one the SI has signed off and the steering committee has approved, and run it through the model with real inputs.
Then watch what breaks.
Maybe month-end close stretches from three days to six. Maybe cutover weekend depends on a warehouse count that takes 36 hours and you’ve allowed 18.
The point isn’t to predict the future. The point is to make the failure happen in the model instead of in the business.
The CTO’s Question
In steering committees, the question on the agenda is are we on track?
That’s the programme manager’s question. The CTO’s should be different.
Where have we proved the business can absorb this change?
The answer cannot be “the test scripts passed.” Test scripts prove the system works. They don’t prove the business will.
The answer needs to be a list of business scenarios that have been modelled. With real volumes, real exceptions, real master data and real calendars. With decisions changed because the model exposed risk the design hadn’t.
If that list is short, the programme isn’t ready. The RAG status doesn’t matter.
Before your next steering committee, ask one question. What have we simulated? Run the cutover in the model first. Find out what breaks before it breaks the business.
McLaren had built a hundred-point cushion early in the season. A single weekend of unexpected behaviour burned a third of it.
SAP programmes don’t get to find out what their margin is until it’s gone.
