Insight · ERP and core systems

10 Reasons ERP Programmes Stall in the Mid-Market

They rarely fail on the software. They stall because decisions about how the business will run were made by people configuring a system, in the order the system needed rather than the order the business needed.

For finance and IT directors Manufacturing · distribution · professional services 13 min read

In brief

ERP programmes overrun, slip and underdeliver with enough regularity that most finance and IT directors expect it. The software is almost never the reason.
The ten below describe what actually goes wrong. Most of them are decisions about how the business will run, made during configuration by people who were never asked to make them.
The position worth holding is not “the implementation is on track”. It is “we decided how the business will run, then configured the system to match”. Very few mid-market programmes can say that.

ERP modernisation is the largest technology investment most mid-market firms make. It is also the one most likely to disappoint.

The pattern is familiar enough that finance and IT directors expect it. Budget over-run. Timeline slip. A productivity dip after go-live that lasts longer than anyone planned for. Benefits that arrive partially, or late, or not in the form the case described.

What is rarely the cause is the software. Modern platforms are capable. The integrators are competent. The teams work hard. Programmes stall anyway, and they stall for reasons that have almost nothing to do with the technology.

They stall because decisions about how the business will actually run were made during a configuration workshop, by people whose job was to configure a system, in a sequence dictated by the system rather than by the business. The ten below describe how that happens.

01

The processes were documented as they are, not designed as they should be

Every programme starts with current state. Workshops, process maps, documentation of how things work today. It is thorough, it takes months, and it produces a genuinely accurate picture.

What comes next is usually a decision about which current processes to keep and which to change to fit the standard system. That is a very different exercise from asking how the business ought to work, given what it is trying to achieve.

So the target state ends up as today’s processes, cleaned up, mapped onto a new platform. The inefficiencies that were structural rather than technical survive the migration intact. The board approved a transformation and bought a re-platform. The fix is to design the future state from the commercial outcome backwards, before anyone opens the configuration workbook.

02

Configuration decisions get made instead of process decisions

Configuration workshops run for months. Hundreds of decisions get made in them. Approval thresholds. Which fields are mandatory. How exceptions route. What the system will and will not permit.

Every one of those is a decision about how the business will work. They are made by a business analyst and a consultant, in a room, against a configuration deadline, because the project plan needs an answer this week.

Nobody senior reviews them as a set. Individually each is minor; collectively they define the operating model. Eighteen months later the business is running in a way nobody designed, and everyone assumes the system imposed it. The fix is to identify which configuration decisions are actually business decisions and route those to the executives who should be making them — before the workshop, not after go-live.

03

Data migration is treated as a technical task

The plan allocates data migration to the technical team. Extract, transform, load, reconcile. It is scoped as a technical exercise with a technical owner.

Most of the real work is not technical. Which customer records are duplicates. Which product data is wrong. Which historical transactions matter and which are noise. Who decides what a valid record looks like. Those are business judgements, and they need business people who know the data.

So migration slips, because the technical team is waiting on decisions nobody assigned. Then it goes ahead with assumptions, and the new system launches with the old system’s bad data reproduced faithfully. The fix is to give data ownership to the business functions from the start, with named people and time allocated. It is one of the most under-resourced parts of every ERP plan.

The system did not impose the operating model. A series of small configuration decisions did, and nobody senior saw them as a set.

04

Customisation gets refused on principle rather than on economics

Every programme adopts a standard-first principle. Sensible: customisation raises cost, complicates upgrades and creates long-term maintenance.

Applied without judgement it becomes a problem. Some of what looks like an awkward local practice is the thing the firm is actually good at — the pricing flexibility that wins work, the service arrangement customers stay for. Standardising those away removes a commercial advantage in order to simplify a system.

The right question is not whether to customise. It is which practices earn their complexity. That requires someone commercial in the room when the decision is made, and in most programmes the decision is made on a technical principle by people with no visibility of what it costs commercially.

05

The integrator is managing scope, and nobody is managing the integrator

The systems integrator has the method, the experience and the people. They run the workshops, produce the documentation, drive the plan. In most mid-market programmes they are effectively running it.

What is often missing on the client side is anyone with the capacity and standing to challenge them. Not adversarially — just someone who can tell whether a recommendation serves the business or the delivery plan, and who has time to look properly.

So scope drifts towards what is deliverable rather than what is valuable. Difficult things get deferred to phase two. Phase two does not always happen. The fix is a client-side lead with commercial authority and the time to use it. Most firms appoint a project manager, which is a different job.

Where do you sit?

Recognising which decisions have already been made for you is the first step.

A free Executive AI Opportunity Assessment. Forty-five minutes, online, with your leadership team. We arrive with a model of how firms in your sector make money and where AI has moved those numbers — and you tell us where it is wrong.

Book a free assessment

06

Training was budgeted, and getting people to work differently was not

The plan has a training line. Sessions get scheduled, materials produced, attendance recorded. People learn to use the new system.

What almost never gets budgeted is the work of getting people to actually operate differently. New decision rights. Different measures. Jobs that change shape. Workarounds that have to be given up. Managers who need coaching on running a team that works another way.

Training teaches the buttons. It does nothing about whether anyone wants to press them. That is why the productivity dip after go-live lasts longer than planned, and why some of it never fully recovers. The fix is to size this against the number of people whose jobs change, and to fund it as its own line rather than as a subheading under training.

Where ERP programmes tend to land — a pattern, not a measurement

Over

The budget

Materially, in most cases. The over-run is rarely in the software licence — it is in the work nobody scoped.

Late

The timeline

Slippage concentrated in data migration and in decisions that had no owner.

Longer

The dip after go-live

Productivity recovery takes more time than planned, and part of it sometimes never returns.

Partial

The benefits

Some arrive. Others depend on process changes that never happened, so they cannot.

This describes a pattern rather than a measured dataset, and your own programme’s numbers are the ones worth putting against it. The useful exercise is not comparing yourself to an industry average — it is asking, for each of the four, whether the cause was the software or something that was decided before anyone touched it.

07

Reporting gets designed last, and often gets designed twice

Reporting requirements get gathered late, once the transactional design is settled. That is the natural sequence: you cannot report on a structure that does not exist yet.

The consequence is that the transactional design was made without reference to what the business needs to see. Cost centres structured for accounting rather than for management insight. Product hierarchies that do not match how the commercial team thinks. Customer records that cannot produce the segmentation the board asks for.

So reporting gets built on top, then rebuilt, then supplemented by spreadsheets. The firm ends up with a modern system and the same manual reporting it had before. The fix is to specify the handful of management views the business genuinely needs early, and to let those constrain the transactional design.

For the finance and IT directors

Three questions worth asking mid-programme

Name three configuration decisions taken in the last month. Were any of them actually decisions about how the business will run — and did an executive see them?
Who owns the design of how the business will work afterwards? If the answer is the integrator, the programme board or nobody in particular, that is the finding.
What is in the plan for getting people to work differently, separate from training? If the answer is a communications workstream, it is under-resourced by a wide margin.

08

Phase two carries the benefits, and phase two keeps moving

Scope gets managed by deferring. Difficult integrations, the analytics layer, the process changes that need real organisational effort — all of it moves to phase two so phase one can land.

Phase one goes live. The team is exhausted. The budget is spent. The organisation needs stability. Phase two gets scheduled for next year, then the year after, then quietly stops being discussed.

The trouble is that most of the benefits in the original case depended on it. The firm now has the cost base of a modern system and the benefits of a partial one. The fix is to protect the benefits-bearing scope in phase one even if something else has to give — and to be honest with the board at approval about which parts of the case are actually being deferred.

09

Go-live becomes the goal, and the goal was supposed to be the benefits

Once a date is set, everything organises around it. Steering meetings track readiness. Testing tracks defects. The board asks whether the date will hold. The whole programme is measured on getting there.

It is a real achievement and it is not the objective. The objective was a set of commercial outcomes the system was supposed to enable. Those arrive months later, if the process changes happened and if people adopted them.

But the programme team disperses at go-live, the budget closes, and nobody is accountable for the benefits any more. The fix is to keep a named owner and a small budget alive for twelve months afterwards, measuring the benefits against the case. Most firms declare success at go-live and never check.

10

Nobody owns how the business will run

The most structural of the ten, and the one the other nine come from. There is a programme sponsor, a technical architect, workstream leads and an integrator engagement lead. Every role is filled.

What does not exist in most mid-market ERP programmes is a named executive who owns the design of how the business will actually operate afterwards — the processes, the decision rights, the roles, the measures — with authority across functions and the standing to overrule a configuration decision that suits delivery but not the business.

Without that role, the operating model gets designed by accumulation. Hundreds of small decisions, each locally sensible, none reviewed as a whole. The system goes live and the business discovers how it now works. The fix is to appoint that person before the configuration workshops start, not after go-live when the finding lands in a review.

What this means

None of these ten are software problems. The platform is capable, the integrator is competent, the team works hard. Programmes stall because how the business would run was never designed, so it got decided by default during configuration.

That is the whole pattern. A configuration workshop is where operating model decisions actually get made in most mid-market ERP programmes — by people who were never asked to make them, against a delivery deadline, one at a time. Nobody sees them as a set until the business is living inside the result.

The economics of getting the order right are not close. Designing how the business will run before configuration costs design time. Discovering it afterwards costs rework, a longer productivity dip, and benefits that were never structurally possible.

Which is exactly the argument. Change the work before you change the technology. And it applies with more force to AI than it ever did to ERP — because AI speeds up whatever process it finds, which makes it worth being certain about the process first.

The next step

Did you design how the business would run, or configure a system and find out?

Forty-five minutes with your leadership team, online, at no cost. We bring a working model of how firms in your sector make money and where AI has moved those numbers. You tell us where it is wrong. Then we tell you what we think — including “don’t invest”, if that is the honest answer.