ERP projects fail often, and the post-mortems read the same way every time. The failure patterns repeat with almost no variation, which is the useful part: they are visible before you sign anything.
Failure 1: treating it as a software installation
An ERP changes how people work. If nobody has mapped the current process and designed the target process, you are automating confusion at speed.
Checkpoint: before configuration begins, you should be holding a written as-is process map and a to-be process design that the department heads have signed. If your vendor did not produce one, you are not doing an ERP implementation — you are installing software.
Failure 2: dirty migrated data
If opening stock is wrong, or the customer ledger does not tie out, nobody trusts the system. And once trust is gone, people quietly maintain their old spreadsheet "just to check", which means you now have two systems and one of them is authoritative for the wrong reasons.
Checkpoint: data cleansing starts at least six weeks before go-live, has a named owner in your business, and has a reconciliation report that ties migrated balances to your old system to the rupee.
Failure 3: no parallel run
Skipping the parallel run is how a go-live becomes a crisis. One full cycle — a month for most businesses — running both systems and comparing the output is the only honest test.
It is expensive and tedious. It is also the difference between discovering a mapping error in a controlled comparison and discovering it when your auditor does.
Checkpoint: the plan includes a full parallel cycle with a named reconciliation owner and explicit sign-off criteria.
Failure 4: training cut to save budget
Training is usually the last line in the budget and the first one cut. The result is a well-configured system used at 30% of its capability by people who resent it.
Checkpoint: role-based training with materials, recorded sessions, and on-floor support in the first week after go-live — written into the contract, not promised verbally.
The pattern underneath all four
Each of these failures is a decision to save time or money in the present at the cost of trust in the system later. And trust is the whole product. An ERP that everyone believes is worth more than a technically superior one that half the business works around.
Questions to ask a vendor before signing
- Show me the as-is process map from your last implementation.
- Who on my team owns data cleansing, and what does the reconciliation report look like?
- How long is the parallel run and what are the sign-off criteria?
- What exactly does training include, and is it in the contract?
- What happened on your last implementation that went badly, and what did you change afterwards?
The fifth question is the most useful. Any vendor with a long implementation record has had one go badly. The ones who cannot name it either have less experience than they claim or are not being straight with you.