Back to news & views

Why ERP projects fail

Over the last few years we’ve been parachuted in to perform an increasing number of ‘project rescues’ for failing (and failed!) ERP deliveries.  This is a worrying trend and is irrespective of the technology being deployed.  So why do large ERP projects fail?  Here are the top five reasons we’ve encountered and our golden rules:

Insufficient senior engagement.  It seems obvious, but surprisingly lacking in many deliveries.  ERP systems often span the entire back office and multiple other departments in your organisation.  Senior engagement is required across the entire gamut of your company to resolve conflict, drive change and improve adoption.  A lack of conviction in any one area will cause delays, expense and affect the quality of the solution.

We’re different.  Your businesses is different, right?  Wrong – well at least in the routine processing of back office transactions.  ERP applications have highly configurable, out-of-the-box, integrated processes that are tried and tested in thousands of multi-nationals.  Changing these will often require changes to the data model, upstream and downstream changes to other integrated processes as well as re-writing the standard reports. If the process is not a business differentiator and part of your unique selling point, adopt the proven process you’ve purchased with the software.

Lack of standardisation.  Large businesses evolve and different parts of the organisation will no doubt be doing the same thing but in a different way.  Standardisation of business process will reduce system configuration and maintenance, reduce training overhead, minimise the amount of technical development and enable centralisation.  Most ERP deliveries run on a single instance to get a single version of the truth and enterprise-wide reporting.  If your processes are different, your data will be too.

Poorly designed customisation.  Customisation is a bad word for ERP deliveries.  It implies change to the core vendor code which can lead to support issues, will cause costly and lengthy upgrades and should be avoided at all costs.  Extensions are more palatable – custom code that sits alongside the vendor application that is designed to be minimally impacted by upgrades and still provides flexibility of configuration change in the future.  Getting these right is tricky and they need clever design to integrate seamlessly without affecting core functionality and still allow for business change in the future.

Inexperienced resource.  ERP projects incorporate large scale business process change with large scale system delivery.  They are not simple and require significant expertise in key areas.  Your business will need to be challenged, processes re-designed from the ground up, super-users brought on a journey, complex environments managed, outside-of-the-box thinking to resolve key gaps and strong change management.  Get these wrong and your business will suffer from inefficient processing, potentially to the point of affecting your ability to pay employees, purchase from suppliers and deliver goods and services to your customers.  Don’t scrimp on the key roles of project management, functional and technical design, test and training; commodity resource can be used elsewhere.


Golden rules

1. Get senior buy-in. Everywhere.
2. Adopt out-of-the-box processes. Change these only where they affect your USP.
3. Standardise your processes – work hard at this.
4. Do not customise. Extend only where necessary and be clever about how.
5. Buy-in expertise for key roles, use commodity elsewhere.