ERP programmes rarely fail in a way that produces a headline. Far more often the system goes live, the project is declared complete, and eighteen months later the real work is still happening in spreadsheets alongside an expensive licence. The technology functions; the organisation simply did not move onto it. The reasons repeat across companies and industries.
The first is configuring to a reference model that contradicts how the business actually operates. Every ERP arrives with an assumed process, and those assumptions encode a generic company. Where they match yours, adopting the standard is a gift - it removes argument and preserves your upgrade path. Where they contradict something that is genuinely your competitive advantage, forcing the standard destroys the thing that made you worth buying from. The work is deciding explicitly, item by item, what to standardise and what to preserve. Programmes that never make that decision consciously make it by accident and usually the wrong way.
The second is data. Go-live with opening balances nobody will sign off is go-live with a system no department trusts, and distrust is permanent - once finance has caught the ERP being wrong twice, they keep the parallel spreadsheet forever. Migration deserves treatment as a workstream of its own, with cleansing, mapping, and a reconciliation report that the people who own those numbers actually accept before cutover.
The third is that customisation goes so deep it forecloses the future. Every bespoke modification is reasonable in isolation and collectively they can make upgrading impossible, which strands you on a version that ages out of support. The discipline is to prefer configuration to code, and where code is genuinely needed, build it through supported extension points rather than modifying core behaviour.
The fourth, and the most common, is training treated as an event rather than a capability. A two-day session before go-live, delivered to whoever was available, does not create competence. What works is role-based training close to the moment people need it, a real support channel for the first two months, and someone in each department who knows the system well enough that colleagues ask them rather than reverting to the old way. That person's existence predicts adoption better than any feature comparison.
The measure worth instituting from day one is adoption itself, not delivery. Track how many transactions of each type actually flow through the system versus the estimated volume of the process. A programme reported as complete while adoption sits at forty per cent has not finished, whatever the plan says - and catching that at month two is a manageable problem, while catching it at month twelve is a write-off.
