How not to overspend and under-deliver your ERP

Spend a lot on your ERP, but not too much.

For many organisations, replacing their ‘Enterprise Resource Planning’ (ERP) is a multi-million pound investment that typically runs over budget, delivers late and/or fails to achieve its business case. We believe that all of these pitfalls can be avoided by using three simple ideas that create a transparent link between technology spend and the customer-value it creates. In this way, an organisation’s ERP will be no more complex and costly than is needed for it to succeed.

An organisation’s ERP is the core technology that enables its operating model – a collection of modules that together support almost every facet of operations. Consequently, it constitutes a significant proportion of any organisation’s technology expenditure – up-front investment could range from ~£500k for a medium-sized entity to multiple £millions for a large multinational, with through-life costs almost doubling that initial investment.

Done well, an ERP provides the technology within an operating model that has a meaningful impact on the top line as well as the profit margin. However, not all ERPs are equal. ‘ERP’ does not mean the same thing to everyone within the organisation it serves. Such unspoken disagreement becomes a problem when the time comes to replace or upgrade the ERP. Functional and personal agendas bubble up, causing a degradation of scope that increases the total cost and time of implementation.

The end result of this expense and confusion is that ERP replacements create significant delivery risk. The replacement gradually becomes ‘a technology project’ that avoids the necessary change management activities and process automation. Functionality (e.g. automation) bought at great expense is switched-off or never used, in order to avoid naturally occurring, predictable, human resistance to change.

Additionally, or alternatively, the ERP project becomes distracted by internally focussed priorities, and bloated by non-core capabilities whose benefit is low and that add unnecessary complexity and cost. In our experience, organisations who use their existing operating model (e.g. current capabilities and processes) and who use a waterfall approach are particularly at risk of this scope degradation… losing sight of the intended customer and employee experience over time.

All of these risks are manageable, using three fundamental ideas that will avoid these pitfalls:

Focus on the customer – so you buy what is valuable and not necessarily what satisfies every stakeholder
Build incrementally from firm foundations – microservice architectures are helpful (although not a necessary condition to successfully apply this idea)
Deliver the change iteratively and test often – in order to prove the value of your investment and manage delivery risk

Each of these ideas has its own merit, but their power is more than the sum of their parts…

Focus on the customer –

Starting with the customer aligns the operating model to the business model and subsequently the ERP to the operating model. In this way, the final implementation of the new ERP delivers the benefits for customers and the organisation as originally intended. Customer centricity has a further benefit – it creates a meaningful, tangible vision of the potential benefits which acts as a ‘true north’ throughout the replacement (this often takes between 6 months to 2 years to complete); and it engenders support for the change… purpose is a big motivator (just ask Daniel Pink).

Build incrementally from firm foundations –

Building incrementally from firm foundations locks in value that has been delivered. Concomitantly, these ‘building blocks’ make it possible to close out the ERP replacement once the anticipated incremental benefits of adding one more block is outweighed by the cost or risks associated with delivering it. A microservice architecture can enable this approach, but it can still be achieved using a more traditional unified platform.

Deliver the change iteratively and test often –

Delivering and testing the change, iteratively, matters for ERP replacement because its duration can span multiple years. An iterative cycle of ‘change, test, and feedback’ means that the replacement keeps pace with a world that will inevitably evolve over such a long period of time. Traditional waterfall delivery won’t keep pace; and so we recommend an Agile approach that mitigates this risk while delivering improved benefits tracking, governance and cost control.

Conclusion

We’ll be discussing each of the ideas above in future blog posts over the coming month. Keep an eye out for them, or alternatively subscribe below, and we’ll email you when they’re published.

Other blogs in this series

The value of focussing your ERP transformation on your customers

Don’t overlook the importance of ERP discovery

This post was originally written by Philip Richardson