← All insights

Most failed ERP projects were decided before the software was chosen

5 min readSystem Development

An overhead view of a warehouse aisle with a red floor marking

We get asked to compare ERP products. It is almost always the wrong question, and answering it politely wastes the client's money.

The failure mode is not the software

An ERP rollout that goes badly usually went badly for one of three reasons, none of which appear on a feature comparison:

  • The documented process and the real process were different, and the system automated the documented one. Staff kept running the real one in a spreadsheet beside it.
  • Nobody decided which system owns a customer record, so two systems both own it and neither is trusted.
  • The data migration was scoped as a task at the end rather than as the project's main risk, and the historical data turned out to be worse than anyone had looked closely enough to know.

Start by writing down what actually happens

Before evaluating anything, follow one order end to end, from the enquiry to the payment clearing, and write down every system and every person it touches, including the informal steps. The ones people do not mention because “that's just what we do” are the ones that break the implementation.

This takes a few days and it is the cheapest part of the project. It also routinely changes the answer: a meaningful share of the ERP enquiries we take turn out to need an integration between two systems the client already owns, not a new platform.

Questions that separate vendors

  • What happens to our data if we leave? Ask for the export format, not a reassurance.
  • Does it handle LHDN e-Invoice submission natively, through a partner, or not at all? The three answers have very different costs.
  • Who implements it: the vendor, a reseller, or us? A good product with an absent implementer is worse than a mediocre product with a present one.
  • What does the second year cost? First-year pricing frequently excludes the modules that made it attractive.

Buy small, prove it, then extend

The pattern that works is unglamorous: pick the one process causing the most pain, implement that properly, run it in production for a quarter, then extend. Big-bang cutovers concentrate every risk into one weekend, and the recovery plan is usually a sentence rather than a rehearsal.