Aim for Imperfect: What Really Goes Wrong on an S/4HANA Programme

There is no such thing as a perfect transformation programme. If yours looks perfect, you are probably paying too much for it.

I was talking recently with a fellow Programme Director about what goes wrong on SAP S/4HANA programmes. We kept coming back to the same idea. You don't want perfection, and you certainly don't want chaos. You want something in between: a programme that is deliberately, manageably imperfect.

Perfection is expensive. It shows up as extra design cycles, gold-plated requirements, contingency on top of contingency and a team sized for every eventuality. Chaos is expensive in a different way: missed milestones, rework, burnt-out people and a business that stops trusting the programme.

Why programmes stall

The odds are not good. Gartner puts the share of ERP implementations that fail to deliver their expected benefits at 70% (Gartner, 2025). McKinsey's study of more than 5,400 IT projects found large ones run 45% over budget and deliver 56% less value than predicted (McKinsey, 2012).

1. Programmes that don't want to go live

The team strives for the perfect solution. Nobody wants to create technical debt. Every open point becomes a reason to wait, and people lose sight of a practical path to the bigger picture.

Every month of delay costs real money: SI run-rate, backfill, dual running and benefits pushed further out. Agree go-live criteria up front, and separate must-fix items from what hypercare can handle.

2. Unknown unknowns

These will always appear. However well you plan, once you get into the detail something surfaces that nobody thought of.

The question is not whether it happens, but whether the programme can absorb it. That means real contingency in the plan and budget, testing that reflects how people actually work, and a decision path fast enough to respond.

Three things to set up for success

1. People

Invest in the top of the pyramid. Strong functional leads, solution architects, project managers and business analysts are where the money goes furthest. They spot problems early, challenge weak designs before they get built, and make sensible calls when the plan runs out. A good architect can save months of rework; a weak one can create it.

Build a good relationship with your SI leads. When trust exists at the top, it is far easier to horse-trade the smaller items later on, rather than turning every change request into a commercial dispute.

2. Governance and decision-making

Be clear on who owns each decision. Not every small change can be agreed by a cast of thousands. Slow decisions are a common problem well beyond IT: in a McKinsey survey, 61% of managers said most of their decision-making time was used ineffectively (McKinsey, 2019). On a programme, that drag compounds, because every stalled decision holds up design, build and test.

Appoint business sponsors who can say "no". An engaged sponsor does more than turn up to steering committees. They are willing to push back.

Why do so many companies fail to implement SAP close to standard? Usually because nobody with authority says no to the next customisation request. SAP itself warns that layers of custom code make systems "difficult to maintain, expensive to upgrade, and prone to error" (SAP, What is a clean core?). A good sponsor starts from standard and asks every deviation to justify itself with a business case.

3. Data

Expect data migration to be on the critical path. It usually is, and it is usually underestimated.

On S/4HANA, the reasons are predictable. Legacy data is rarely as clean as people think. Mapping old structures to new ones, such as Business Partner replacing separate customer and vendor records, takes longer than planned. And the migration can't stabilise until the configuration it loads into is stable too.

Start cleansing on day one. Don't wait for the target design to be finished before looking at the source data. Profile it early to find duplicates, obsolete records, missing mandatory fields and inconsistent formats. Archive what you don't need to bring across. Every record you don't migrate is one you don't have to map, cleanse, load or reconcile.

Make the business own the data. IT can move data, but only the business can say whether it is right. Assign a named data owner for each key object (customers, suppliers, materials, open items, balances) who is accountable for its quality and signs off each load.

Run a mock load in every test cycle. That way you always have a handle on where you are data-wise, and you test the solution with realistic data rather than hand-keyed examples.

Mock load 1, before SIT: tests whether the mappings and load programs work end to end, and how much cleansing is still needed.
Mock load 2, before UAT: tests whether data quality is good enough for business users to test real scenarios, and whether error rates are falling.
Dress rehearsal, before cutover: tests whether the full load fits the cutover window, and whether reconciliation works under time pressure.

Track load success rates and defect volumes from one mock load to the next. If they aren't improving, go-live is at risk.

Agree up front how you'll prove the data is right. Record counts are the minimum. For finance and supply chain, reconcile the numbers that matter, such as general ledger balances, open receivables and payables and stock quantities and values. Then get them formally signed off by the data owners. Deciding what "reconciled" means during the cutover weekend is too late.

Unknown unknowns: a story from the shop floor

Even a well-run programme gets surprised. One logistics client implemented SAP to manage inventory and supply chain. They had invested heavily in getting the design right, and everyone was aligned on what needed to be done.

The programme passed SIT and UAT. Readiness scorecards were assessed. The system went live.

Then a problem appeared that no test had caught. The technical design didn't match the physical layout of the factory. In the live system, a barcode had to be scanned at two different terminals. To keep the conveyor belt moving, someone had to run from one terminal to the other.

The team fixed it quickly and pulled the programme over the line. But the lesson stuck: rigorous design and planning reduce surprises, they don't remove them. What matters is having the people, governance and data discipline in place to respond when one lands.