Crossing the ERP Trust Chasm

The 4 “anti-patterns” that work against trust in platform renewal – and how to deal with them**

Summary

Platform modernisation programs are a “must do” even in an environment where AI is emerging as a key support. Yet these large scale programs often fail. This creates significant risk for Boards and CXO’s launching invetments of this nature. We see 4 major anti-patterns that are often built into initial business case logic, but do not help deal with these blockers. We provide some suggestions based on our experience, as to how to respond to these challenges.

Platform modernisation has moved from a strategic choice to an operational imperative

Although taking on any new technology program is risky, it is difficult for organisations to avoid working on ERP, workflow, or other forms of platform modernisation. Legacy systems cannot cope with the speed, accuracy, and reliability required for modern decision making. Expectations of customers and other key stakeholders are high. Although AI-based solutions are evolving at a rapid pace, they have not yet supplanted the security, robustness, and ongoing management requirements that still demand the provision of a modern platform.

Yet these are “scary” programs that carry risk

Despite the need for institutional grade solutions, Boards and CXO’s stall on taking steps forward due to the risk of these programs failing. Doing nothing becomes the typical response, and a patchwork quilt of fixes and work-arounds remains in place.

The high cost of failure draws a risk-based response

Risks associated with these transformation programs are often then dealt with, but applying detailed risk-matrices, operating model designs and detailed project and change planning.

These are all useful elements in their own right, but do not remedy the key anti-patterns that we see “getting in the way”. So what are those anti-patterns?

The 4 anti-patterns – and how to deal with them

Four anti-patterns or blockers drive an inability to move forward.

1. Platforms are gold plated – optionality is low

The platform is implemented in a single, monolithic, enterprise-wise rollout, with high disruption costs, high complexity, and limits to iterative learning, all leading to a substantial likelihood of failure.

This persists because underlying business problems are often not fully understood prior to a race to platform selection. As a result, platforms are treated as a ‘cure-all’, rather than being deployed in targeted, incremental, and functionally-specific phases to address specific issues.

2. Nobody looks under the process hood

Capturing the true impact of modernisation requires detailed, activity and process-level analysis. This is often bypassed in favour of speed, with decisions built around benchmarks or vendor estimates, leading to solutions that do not deliver expected outcomes.

This persists because in time-poor, cost-conscious organisations, an upfront investment is often labelled as unjustifiable, particularly where it is seeking to prove benefits for a program that currently has a low confidence level.

3. Change management is a shallow checklist

More than a third of failures trace to weak change management and sponsorship. A new platform exists, but the full benefit is not captured as staff stay “stuck” in old ways of working OR confused due to poor training and transition.

This persists because organisations are good at looking at the logic behind investment decisions. What they are poor at, is assessing the human reality of change. Change management is also often reduced to a compliance checklist, rather than a genuine investment in shifting how people think and work.

4. Links to AI are not clarified

Platform modernisation often promises automation and efficiency gains, but these benefits are frequently constrained by poor integration between AI-driven process intelligence and the platform’s underlying data.

This persists because AI and platform modernisation are treated as competing priorities. They are not. The value comes from understanding how one enables the other.

A rigorous business case builds a bridge across the chasm

1. Build optionality into the design

Be clear on the core outcome before selecting a solution. An overcommitted scope is often a symptom of unclear objectives. Having clarity about the core business problem, and the priority of any sub-problems, enables a solution design targeting specific problems one at a time.

Design options packages around a number of dimensions. Considering packaging options around (a) a process or activity view, (b) a team or user-segment view, (c) a business functional view.  Try to keep staging as a separate overlay to functional differences.  There is no right or wrong answer and this is business-specific.

Give decision-makers the ability to choose. Decision makers need to work their way through a “real options” analysis. This means mapping, scoring and presenting alternatives against a clear set of criteria, and bringing that journey to the front of the case.

2. Go “under the hood” to identify value

Recognise the value of investing in process clarity. Validate benefits and organisational impacts at a team, activity, and process level. This work needs to be seen as an investment, a fraction of the total transformation cost, providing insurance against a program built to fail.

Apply the 80/20 rule in activity analysis. Go deep on a few high-value areas rather than thinly across all.  Pick the areas where the platform is intended to have the biggest impact and go deep there.  Use team knowledge to get a sense of time saved.

Use a “before and after” mindset Show how specific changes (particularly activity and resource usage) will change based on before and after scenarios.  Be crystal clear as to how that results in any time and cost savings.

3. Invest in the human element

Use empathy to walk in the shoes of those most affected. Map the day-in-the-life of the roles most impacted by the change. Identify specifically what they do today, what the platform changes for them, and where resistance is likely to emerge. This grounds the change plan in real experience rather than a theoretical risk.

Engage change managers in building the case, not just the rollout. Change managers should pressure-test the case, identify adoption risks, and shape how the program is staged and communicated. Their involvement at this stage converts resistance into buy-in before implementation begins.

Treat adoption as a measurable outcome. Tie success of the modernisation program to clear indicators of organisational buy-in, such as training attendance, staff satisfaction and process compliance. This ensures the organisation remains cognizant of the often-overlooked behavioural change required for successful transformation.

4. Ensure connectivity with AI

Build a clear, platform-linked AI plan. A conceptual statement on AI integration is not enough. The case needs to define specific AI use-cases tied to the platform, outlining where AI is applied, what it will do and what the steps are to integrate it with broader business systems.

Be clear on where AI helps drive greater efficiency. Utilise use cases and the existing process work to highlight how AI will enhance productivity even further than the existing systems change.

Don’t undercook the AI investment needed. Include additional AI platform build and operate costs as part of your plan.

Start with a strategic workshop

A workshop can help identify and unpack potential solutions to these issues and get your organisation off to the right start. The list of agenda items below is worth considering. SPP can provide independent facilitation to support these efforts.

1. Test for clarity of program objectives

2. Clarify the investment case using capability-based benchmarks for this type of investment

3. Review status vs the 4 success patterns: scoping models/optionality, “under the hood” activity analysis, empathy models for change, AI readiness

4. Confirm the logical – status check on risk management, change management, program management, financials

5. Summarise and agree next steps

Notes and References

*Source: SPP Experience (2026), Boston Consulting Group; Most Large-Scale Tech Programs Fail—Here’s How to Succeed (2024); Gartner; Enterprise Resource Planning to Optimize Operations; Gartner; (2025 CIO Survey, 3,186 CIOs across 88 countries)

**With thanks to Geoffrey Moore the original author of “Crossing the Chasm”.