ERP Selection Risks: What Goes Wrong and How to Avoid It

ERP implementations are among the most consequential and complex technology programmes an organisation can undertake. They affect almost every operational process, require extensive data migration, demand significant organisational change, and typically span multiple years. The risks that materialise most often during ERP programmes are not technical failures of the ERP product itself; they are failures in how the selection, scoping, and implementation were managed. Most of these failures have their roots in decisions made before the contract was signed.

Scope ambiguity is the most reliable predictor of ERP cost overrun. Vendor proposals that use terms like 'standard implementation', 'based on requirements to be confirmed', or 'subject to workshop findings' are transferring scope risk to the customer. A standard ERP implementation does not exist; every implementation requires configuration, and most require some degree of process change or customisation to fit the organisation's actual operating model. The gap between what the vendor's fixed-price proposal covers and what the organisation needs is where cost overruns are born.

Customisation decisions made during implementation carry long-term consequences that are not visible at selection time. Customisations that modify core ERP functionality to match existing business processes, rather than adapting processes to fit the ERP, accumulate as technical debt. Each customisation must be managed through ERP version upgrades and creates a layer of complexity that makes future changes more expensive. Organisations that have run heavily customised ERP systems for ten or fifteen years typically find that the total cost of maintaining those customisations exceeds the original implementation cost many times over.

Data migration is routinely underestimated in ERP programmes. The data required to operate an ERP system is often distributed across multiple legacy systems in inconsistent formats, with quality problems that are not visible until migration is attempted. Cleansing, transforming, and validating the data required for an ERP go-live is a project-within-a-project that requires significant time and specialist capability. Programmes that allocate insufficient time and resource to data migration either go live with poor-quality data or defer the go-live, both of which have significant operational and cost consequences.

Change management failure is the leading cause of ERP programmes that technically go live but fail to deliver their intended benefits. ERP implementations fundamentally change how people do their jobs. If the people affected by those changes do not understand why the change is happening, are not trained adequately, or do not have effective support in the period immediately after go-live, adoption is low and the organisation does not achieve the process improvements that justified the investment. Change management that is treated as a communications activity rather than a structured programme of capability building and transition support is insufficient for a programme of this scale.

The implementation partner is a risk factor that deserves more weight than it typically receives in ERP selection. The ERP product is only part of what the organisation is buying; it is also buying the partner's ability to deliver. Partners present their best consultants during the sales process, and those consultants may not be the team that actually delivers the programme. Reference checks should focus specifically on the implementation experience, not the product's capabilities, and should seek references from organisations of comparable size and complexity that used the same partner for a similar scope.