Build ERP upgrade costs into the business change programme - not the IT budget

In terms of business processes and employees, the reach of enterprise resource planning systems in large companies covers a...

In terms of business processes and employees, the reach of enterprise resource planning systems in large companies covers a footprint of employees unprecedented compared to earlier applications.

Like all assets, ERP must be maintained, but its scope has made upgrades expensive and risky to the business.

Any upgrade of a large ERP system is a significant investment that must deliver business value, requiring careful co-ordination of upgrades with business change and expansion to avoid projects that deliver little or no return on investment.

AMR Research recently updated a survey on ERP upgrades first done in 2002. The results are described in the report Minimising ERP Upgrade Costs Requires Synchronising With Business Improvement Projects. Since the first survey, the ERP user base has gained experience with upgrades, but it is divided on the best strategy for balancing the costs and benefits of upgrades.

Upgrades are still expensive

As much as suppliers would love their customers to keep up with the latest versions of their software, the cost of upgrades is still too high, averaging £1,038 per business user. Put in perspective, this is:

  • 50% of the original software licence fee and 20% of the original implementation cost per user - £5.2m for a 5,000-user system.
  • One person-week of internal or consulting labour per business user.
  • Eight to nine months of effort with a team the equivalent of one full-time employee per 35 business users.

Even so, companies were found to be much more likely to finish ERP projects on time and on budget today than in AMR's earlier survey.

Even minor point release upgrades cost only 33% less than a major functional upgrade. One reason for this is testing, which consumes 24% of the effort in an upgrade.

A lot of small steps are more expensive than a few big ones. Nearly 50% of the upgrades are forced by technology changes and the ending of support.

Of the companies that responded, 45% said they wait until they are backed into a corner to do an upgrade. Consider the following:

  • Only 15% of upgrades in the study were forced by de-support of the running version of software. Do not feel bad for these users. Given the liberalisation of supplier support polices in the past few years, the installations probably had not been upgraded for four years or more.
  • Another 6% were triggered by bug fixes or statutory changes. Companies often found it was just as much work to take a new version of software as to try to selectively patch the old one.
  • 24% were triggered by technology stack changes. Often companies find they cannot expand their current hardware and newer larger machines have new versions of operating systems and databases, triggering an upgrade cycle.
  • 55% of upgrades were voluntary business improvements triggered by the need for new functionality, expansion or consolidation of systems. Even if an upgrade is not required, most of the planning, testing and training costs are the same. The result is that most companies build an upgrade into their expansion plans.

Control the upgrade schedule

IT organisations trying to set a policy for how often to upgrade enterprise applications are either wasting their organisation's money or will be frustrated by an inability to get projects funded.

To avoid a lack of return on investment because of de-support of your current release, build upgrades into other business expansion or improvement processes that require similar change management, testing and training efforts.

Bill Swanton is a vice-president at AMR Research

Read more on Business applications