What ERP Failure Really Looks Like and How to Prevent It

What Does ERP Failure Really Look Like?

ERP failure is not always a dramatic, headline-making collapse. More often, it is a quiet underperformance that goes unquestioned for years. Organisations invest heavily in ERP Software, go live on schedule, and then accept the result as normal, even when the system delivers no measurable strategic value.

In this episode of the Comparesoft ERP Podcast, Dr James Robertson, ERP troubleshooter, turnaround specialist, and published author, explains why the real ERP failure rate is far higher than most reports suggest. Drawing on decades of experience fixing underperforming systems across multiple industries, James argues that up to 95% of ERP programmes fail at the strategic level and that replacement is rarely the answer.

How Is ERP Failure Defined?

Most discussions around ERP failure focus on budget overruns, missed deadlines, or abandoned implementations. James takes a different view. For him, ERP failure occurs whenever the system is not actively contributing to the business’s strategic performance.

An ERP that runs payroll, processes orders, and produces reports on time may appear successful. But if it is not improving profitability, increasing productivity, or enabling faster and better decision-making at the board level, it is falling short.

James points to his own client work as a benchmark: in one case, a well-implemented ERP helped a business secure a major new client account, delivering a 12% revenue uplift overnight. The client grew so quickly that it needed to build a larger distribution centre to keep up with demand.

That, according to James, is what a successful ERP implementation looks like. Anything less is a degree of failure.

Why the ERP Failure Rate Is Closer to 95%

Industry reports commonly cite ERP failure rates of between 70% and 75%. James argues the real figure is closer to 95% when measured against strategic outcomes rather than go-live completion.

The difference comes down to the questions being asked. If success is defined as going live on time and on budget, many ERP programmes appear to succeed. But if the measure shifts to whether the ERP is genuinely driving competitive advantage, improved profitability, and executive-level decision-making, the picture changes dramatically.

James attributes this gap to a fundamental mindset problem. Most ERP practitioners focus on the tool itself rather than on the business outcomes it should deliver. As an engineer by training, James approaches ERP from the opposite direction: identifying what causes failure and designing against it. In his words, engineering teaches you all the ways a bridge can fall down and how to prevent it. He applies that same discipline to ERP.

The Critical Factors Behind ERP Failure

In his book, The Critical Factors for IT Investment Success, James identified seven factors that cause ERP programmes to fail. He confirms that these remain largely unchanged today, because the root causes are human, not technical.

Three stand out as the most significant:

1. IT mythology accounts for an estimated 30% of failures. This is the belief that technology is inherently transformative, that software can solve problems simply by being installed. James sees this pattern repeating with AI, where organisations expect results from the technology itself without addressing the underlying business strategy or process design.
2. A lack of executive custody is the second major factor. James is specific about the language: the CEO must be the custodian of the ERP programme, not merely a sponsor. Custodianship means active, ongoing ownership of the outcome. When the CEO delegates responsibility to IT or to a programme director without retaining personal accountability, the programme becomes vulnerable to politics, siloed thinking, and indecision.
3. A lack of strategic alignment is the third. If the organisation has not clearly defined why the business exists, how it competes, and how it makes money, the ERP programme has no foundation. Without that clarity, implementation teams cannot distinguish between what matters and what does not, and the system drifts away from the needs of the business.

Accountability as the Foundation of ERP Success

James argues that accountability is the single most important factor in turning ERP failure around. It starts at the top and cascades downward.

The CEO takes ownership of the programme outcome. Each member of the C-suite takes responsibility for the modules and processes that fall within their remit. Senior managers cascade that responsibility to their teams. The entire organisation is aligned behind the programme, with clear ownership at every level.

To reinforce this, James advocates for formal accountability certificates. Before go-live, every manager and consultant responsible for a part of the ERP programme signs a document confirming that their area is fully tested, trained, and ready. The CEO then gathers the team and offers one final opportunity to raise unresolved issues. Only after that process is complete does the programme go live.

This approach directly addresses a common problem: teams silently accepting known issues because they fear raising concerns. James’s method creates a culture where surfacing problems is expected and rewarded, not punished.

The 7-Step ERP Accelerator Methodology

James has formalised his approach into what he calls the ERP Accelerator, a seven-step methodology designed to prevent ERP failure. It applies equally to new implementations and to remediating systems that are already underperforming.

Step 1: Diagnose

Before any decision is made about replacing or upgrading a system, the existing ERP is assessed. James’s position is that 95% of the time, the current system can be fixed. In one case, a client on the verge of scrapping their ERP followed his recommendations and kept the system running successfully for another eight years.

Step 2: Establish Executive Custody

The CEO is confirmed as the custodian of the programme, backed by an experienced ERP advisor who can guide decision-making without introducing bias.

Step 3: Define Strategic Alignment

The organisation maps its strategic essence: why the business exists, how it differentiates, and how it generates revenue. Every subsequent decision about the ERP is tested against this foundation.

Step 4: Decide

With the diagnosis complete, the custody established, and the strategy defined, the organisation takes a sober, evidence-based decision: remediate, re-implement, or replace. James stresses that this decision must account for the full iceberg of hidden costs beneath any replacement programme, including the cost of lost talent, disrupted operations, and institutional knowledge that is difficult to recover.

Step 5: Precision Configuration

The ERP is configured with a strategically designed chart of accounts, dimensions, and item classifications. James describes this as the step that transforms an ERP from a mundane operational system into a strategic resource. When configuration is precise and hierarchical, executives can answer complex questions of the data with minimal effort, and the need for constant report changes disappears.

Step 6: Laboratory Testing

The configured system is tested in a simulated real-world environment. Users work through the most complex and demanding scenarios: the most difficult customers, the most problematic products, the full order-to-cash cycle. Training happens here, not through a brief PowerPoint presentation followed by a short session with test data. James compares conventional ERP training to teaching a lorry driver with a 45-minute slideshow and a lap around an empty car park before sending them onto a motorway with a fully loaded vehicle.

Step 7: Thrive

After go-live, the ERP becomes a permanent agenda item at executive meetings. The leadership team asks: is there anything more the organisation should be doing with the ERP? Are there any issues that need resolving before they grow? Data quality is actively curated, and the system is treated as a long-term strategic asset, not a project that ends at go-live.

Lessons from Lidl’s ERP Failure

The Lidl ERP failure is one of the most cited examples in the industry. The retailer spent seven years and approximately 500 million euros attempting to replace its bespoke system with SAP before eventually abandoning the programme.

James argues that the fundamental issue was a technology-first mindset. The decision to replace the existing system was driven by the belief that older software needed to be replaced, not by a clear business case demonstrating that the existing system was failing to support the company’s strategy.

Lidl’s bespoke system handled pricing in a way that was central to the company’s competitive model. SAP could not replicate that capability. James contends that this incompatibility could have been identified within two days: one day to define the strategic essence of the business, and one day to establish whether SAP could support it.
Instead, the organisation spent seven years attempting to modify SAP to do something it was not designed to do, while the existing system, the one that had helped Lidl grow into a global operation, sat waiting in the background.

For James, the lesson is clear. The software that got the business to where it is today should not be dismissed as obsolete without a strong strategic justification. If the existing system works, the default position should be to fix, enhance, and extend it rather than replace it.

Why System Replacement Is Rarely the Answer to ERP Failure

James challenges the widespread assumption that underperforming ERP systems need to be replaced. He argues that the drive to replace is often fuelled by a technology-focused mindset rather than a business-focused one.

When practitioners focus on the tool rather than on its role within the business, replacement appears simple: remove the old software and install a new one. But when the full scope of hidden costs is considered, including data migration, process redesign, retraining, lost productivity, and the risk of repeating the same mistakes, remediation becomes far more attractive.

James draws an analogy with infrastructure. A building or a bridge is not demolished because it is 15 or 20 years old. It is maintained, repaired, and upgraded. He applies the same logic to ERP systems: they are infrastructure, not disposable tools. A well-maintained ERP, even one running on older technology, can continue to deliver value for decades if it is properly supported.

He points to the continued global use of COBOL as evidence. Legacy code still underpins banking systems and critical infrastructure around the world. Age alone is not a reason to replace software.

What CEOs and CFOs Should Do Before Starting an ERP Programme

James offers three priorities for any leadership team preparing to embark on an ERP programme or address an underperforming system:

1. The CEO must accept personal custodianship of the programme. Not sponsorship, not oversight, but direct accountability for its success or failure. This means active involvement in key decisions, not delegation to IT or a programme office.
2. The organisation must define its strategic drivers with absolute clarity. What does the business do? How does it compete? How does it generate revenue? Every decision about the ERP, from vendor selection to configuration to training, should be tested against these fundamentals.
3. The leadership team must clearly articulate why it wants to embark on the programme. If the answer is driven by technology trends, vendor pressure, or a vague sense that the current system is outdated, that is a warning sign. The rationale should be grounded in specific, measurable business outcomes.