In short
ERP programmes fail when they are run as IT projects, though they change how the whole business works. The software is rarely the cause: scope, data, change management and executive attention decide the result.
Every ERP post-mortem reads the same way. The vendor blames the client, the client blames the integrator, and the integrator blames scope. Somewhere inside a programme that cost millions, the steering committee quietly stops meeting.
ERP implementations fail because organisations run them as IT projects, and they are business change. The system gets built around processes nobody wants to change, by teams nobody listens to, under leaders who step away after kickoff.
Every major ERP vendor sells the same promise: adopt standard processes and inherit decades of industry practice. In the sales cycle it sounds like maturity. In the implementation it meets a business that does not want to change how it books revenue, closes the month or manages stock unless someone senior insists.
Business units then ask for customisation to keep the workflows they know. The integrator agrees, because change orders pay. Soon the standard implementation has been bent into something that looks like the legacy system it replaced, only more expensive to maintain. Customisation is the symptom. The cause is that nobody decided which processes truly set the company apart.
Most ERP programmes rest on three parties: the software vendor, the systems integrator and the client. The vendor books licence revenue on signature. The integrator earns on hours. The client, usually a CIO or CFO, has been told the business case works at a fixed budget.
This arrangement rewards optimism in scoping. Requirements workshops surface modules, integrations and edge cases that were never in the statement of work. The integrator welcomes them, the vendor sells more licences, and the client approves because stopping would mean admitting the plan was wrong. Gartner predicts that by 2027 more than 70% of recently implemented ERP initiatives will fail to fully meet their original business goals.
Every ERP plan has a line called data migration. It usually sits near the end, gets a small share of the budget and goes to the team with the least political cover. The project starts to fail here, long before anyone notices.
Master data is almost always worse than anyone admits. Customer records are duplicated across systems, material codes mean different things in different plants, and charts of accounts map inconsistently across legal entities. When that data flows into a new system, the new system repeats its errors, and users stop trusting it within the first reporting cycle. Neither SAP, Oracle nor 1C can fix master data nobody has cleaned in years.
When an ERP programme runs over budget, the cuts follow a pattern. Licences are signed, integrator hours are hard to touch and infrastructure is fixed. So the cut falls on the line with no contract behind it: change management. Training shrinks and adoption coaching disappears.
Prosci's benchmarking finds that 88% of projects with excellent change management met or exceeded their objectives, against 13% of those with poor change management, about seven times as many. An ERP is a set of instructions for how thousands of people will work differently tomorrow. Cutting the work that teaches them turns go-live into the start of a productivity slump.
The pattern is familiar. The CEO opens the programme, and the steering committee meets weekly for the first quarter. Then attention moves to the next priority, and the meetings go monthly, then quarterly, then "as needed".
Decisions that need an executive, such as refusing a customisation, overruling a business-unit head or replacing a weak workstream lead, pile up with nobody able to clear them. The programme drifts into IT ownership. The software works, the business has not changed, and the outcome gets described as a successful technical implementation with adoption challenges.
The usual objection is that failure comes down to vendor choice: SAP where Oracle was needed, cloud where on-premises was needed.
The pattern argues otherwise. Organisations that implement well tend to succeed on several platforms, and those that struggle tend to struggle on each of them. Implementation discipline, data readiness, executive governance and the capacity to change explain more of the outcome than the platform. Blaming the vendor explains last year's failure and sets up the next one.
Fund change management as a core workstream, because licence and integrator invoices will absorb whatever share of the budget you allow them. Keep a steering committee that meets for the whole programme, with named decision rights and escalation paths that do not depend on the CEO's calendar.
Start cleaning data well before the first migration script runs. Refuse customisation on processes that do not set you apart; order-to-cash, procure-to-pay and record-to-report rarely do. In Kazakhstan the pattern is the same on 1C, SAP and Oracle: customisation to keep legacy workflows, an underfunded data migration and sponsors who step away when strategy turns into execution.
An executive sponsor who steps away is the most consistent predictor. Technical problems can be recovered; a programme that loses its leadership after kickoff rarely recovers. Data readiness and change management follow close behind.
Treat it as a core workstream with its own budget line, covering training, process redesign, super-users and adoption support after go-live. Prosci's benchmarking finds that 88% of projects with excellent change management meet or exceed their objectives, against 13% with poor change management. Size it from the number of people whose work changes.
Less than the selection process suggests. Organisations that implement well tend to succeed across platforms, and those that struggle tend to repeat it. Implementation discipline, governance, data readiness and the capacity to change decide most of the outcome.
Well before the first migration script runs in a test environment. Cleanup, deduplication, codes aligned across entities and data governance all need to be in place before cutover.
No. Keep it for processes that truly set you apart; order-to-cash, procure-to-pay and record-to-report almost never qualify. Decide which processes are distinctive before requests start arriving, and give governance the authority to refuse the rest.
An ERP go-live is a date. A system the business runs on depends on decided processes, clean master data, trained people and a sponsor who stays. opengate checks governance, data readiness and change capacity before the first licence is signed, then designs and builds the integrations and software around the ERP. Start with one process, and we measure what it gives back.
