Why ERP projects fail

An ERP rarely fails because someone chose the wrong software. It fails later, and almost always for a small set of reasons that repeat from project to project. Read a post mortem — rarely written, because nobody wants to sign one — and it seldom says the product could not do the job. It lists decisions taken at the start, when they looked like savings, and paid for at go-live, when it was too late to reverse them.

That is the good news inside the bad. If the causes are few and known, each can be recognised before it arrives. This piece names six ways a project fails — core customisation that locks the version, a cutover with no way back, an underestimated data migration, no owner from senior management, scope that grows without a decision, and training that arrives after go-live — and for each it describes the cheapest countermeasure.

Deliberately without percentages. Figures for how many ERP projects fail circulate widely, but they are measured against different definitions of failure and are rarely verifiable, so this piece will not lean on them. The argument needs no statistic: it is enough that anyone who has run a rollout recognises at least three of these six.

Technical debt taken on day one

Core customisation that locks the version

Every ERP lets you touch its core somewhere — change the posting logic, the document form or the approval flow by editing the source rather than configuring above it. The first such change solves a real problem and feels like a win. The bill arrives at the next upgrade: a forked core means the vendor's update no longer applies without a manual merge, so you either pay for that merge every time or skip the upgrade. A skipped upgrade locks the version. In this market that is not an abstract cost. When SEF changes the e-invoice schema, when the VAT ledger format shifts, or when e-fiscalisation gains a new rule, that change ships as a product update — and a company that locked its version by editing the core cannot take it in time. Compliance with the law then hangs on whether someone finishes re-merging the fork before the deadline. A customisation that saved a week at the start becomes a standing tax on every regulatory change.

Data migration, underestimated as a rule

Migration almost always appears in the plan as a single late line item, as if it were copying. It is not. The data in the old system has settled over years of decisions, mistakes and workarounds, and only migration reveals how much of it there is: duplicate customers under two tax IDs, open items with no payment reference, stock that does not agree with the last count, an archive of documents the law requires you to keep. Migration is not a transfer of data — it is the first honest inventory of the company's state, and it almost always finds more disorder than anyone admitted to.

• Open items with balances that agree to the dinar — statement matching by model 97 reference continues on them, and a wrong balance surfaces only on the first payment.
• Opening balances by account, by partner and by dimension, reconciled to the old system's closing trial balance — not a total that is close.
• Stock by quantity and by value, reconciled to the last physical count, with the costing method (FIFO or average) unchanged in transit.
• VAT ledger continuity: the PP PDV and POPDV records must resume with no gap in the period, so migrating mid-period requires both systems to agree on the cut-off date.
• The document archive the law requires you to retain — e-invoices, statements, payroll runs — reachable after the old system is switched off, because the retention duty does not end with migration.

De-risking migration is one move: a trial migration on the full data volume, months before go-live, reconciled to the last dinar and run by the same people who will work in the new system. The first trial migration always fails — that is the point. It fails while there is time to fix it, not on cut-over day. A company that ran its first trial a month early enters the switch with known errors; a company that migrates live for the first time enters it with unknown ones.

A big-bang cutover with no way back

A big-bang cutover — every module, every user, one day, the old system switched off — is attractive because it is cheap on paper and ends the uncertainty. Its only flaw is the absence of a plan B. If on day three statement matching does not hold up against real traffic, or the VAT ledger is not filling correctly, there is nowhere to retreat: the old system is dead and the new one does not work, so the company invoices by force or does not invoice at all.

Organisational debt that is not in the contract

No owner from senior management

An ERP project changes how a company works, not just which software it runs. That change cuts across departments: finance, purchasing, the warehouse and sales must agree on whose data is authoritative and who changes a process when two departments disagree. Neither the project team nor the vendor can make that call — they have no authority. If there is no single person from senior management who owns the project and settles disputes, every cross-department conflict stalls the work and waits for a meeting that never gets scheduled. Projects without that owner do not fail loudly; they quietly stop. The countermeasure is to name the owner before signing, not after the first deadlock — someone with the authority to decide, time reserved for the project, and a clear mandate that process decisions bind every department. A vendor who does not ask who that person is before starting either misreads the risk or is keeping quiet about it.

Scope that grows without a decision

Scope rarely explodes at once. It grows one request at a time — just this one report, just make it cover this too — each reasonable on its own. The sum of those reasonable requests moves go-live by a quarter, and nobody can point to the decision that moved it, because there was none. Scope that grows without a decision is not a problem of ambition but of record: the change happened, but nowhere does it show what it cost. De-risking is not to freeze scope — it is to make every change visible. Each request beyond the agreed scope gets a time estimate and an explicit decision: it goes in now and moves the date, or it goes to a phase after go-live. A declined request is not lost; it is logged for later. What sinks a project is not the word yes but yes said with no price beside it.

Training after go-live

Training is the first line item dropped when the plan slips, because it looks like something that can wait. The logic is backwards: if users first see the system on the day they must work in it, they spend the first week learning on live data, make mistakes that enter the books, and form the verdict that the new system is worse — a verdict that is hard to reverse afterwards. Training after go-live is not training; it is firefighting under the name of training. The countermeasure is to make training a condition of the switch, not an activity after it. The people who will work in the system should have already worked in it — on the trial migration, on their own real documents, on scenarios they recognise — before the old system disappears. A go-live entered with a team that has already posted a hundred trial documents is a cutover; a go-live with a team posting its first document live is an experiment.

The order in which risk comes off

How NG One approaches it

NG One is early and has no live customers to cite, so this section is not a list of results but a description of how the product is set against these six risks. The customisation line is built in: business logic is shaped through configuration, rules and dimensions above the core, so a company can take an upgrade when SEF, the VAT ledgers or e-fiscalisation change without re-merging its own fork. Statutory parameters are time-valid data, not code, so a change in the law does not require a new version of the core.

Migration and cutover are designed as trials, not as an event: a full-volume import, opening balances and open items reconciled to the dinar, and the team working on that data before the old system is switched off. The model is multi-tenant with hard isolation, so the demo tenant the team rehearses in is not the same data as production — they practise on their own, not on someone else's. Ownership, scope and training are not things software decides for a company; NG One can make them visible — every scope change leaves a trace, every trial posting is counted — but the company makes the call.

The conclusion is not that a rollout is dangerous and should be delayed. It is that the ways it fails are few, known and visible long before go-live — and that almost every one comes off with a decision taken in time, not a tool bought at expense. A project that knows where its six risks are, and who owns each, enters delivery with a map. A project that trusts this time will be easier enters without one, and learns which cause was waiting only when it comes to choose the next system.