ERP implementation mistakes to avoid before they cost you a year

Why ERP projects go wrong

An ERP replaces the habits of the whole company: how stock is counted, how orders are approved, who may change a price, when a payment is recorded. Software is the easy part of that change. The hard part is getting departments that have worked around each other for years to agree on one version of events.

Projects typically fail quietly. There is no dramatic crash. The system goes live, staff keep their spreadsheets, reports disagree with reality and the owner concludes the software was wrong. In practice the cause was usually visible months earlier: unclear scope, no decision maker, rushed data migration or too little training.

The mistakes below, which are really about people and process, are grouped roughly in the order they appear in a project. If you are still choosing a platform, our comparison of Odoo, ERPNext and custom ERP is a better starting point.

Scope: the document that protects you

A good scope document is boring and specific. It lists the legal entities and branches, the modules in the first release, the reports management needs, the integrations with banks, couriers or your website, and the items left out on purpose. It names who approves changes and how an extra request is priced and scheduled.

Without it, every meeting adds a wish, the vendor absorbs or resents the extra work, and the go-live date moves. With it, both sides can say yes, later or no without an argument. Review the scope with each department head, not only the person who signed the contract.

Data, the quiet killer

Dirty data does more damage than any missing feature. If your item list has three spellings of the same product, if customer balances do not match the ledger or if stock counts are months old, the ERP will faithfully report wrong numbers, only now with more authority. Staff stop trusting the system and revert to private spreadsheets.

Spend real time on item codes, units of measure, supplier and customer records, opening balances and bills of material. Do a physical stock count close to go-live. Reconcile balances with your accountant and have a named person sign off the opening position. It is slow work that nobody finds exciting, which is why it is skipped, and why projects fail later.

Inventory-heavy firms should also read our guide to inventory management software features to decide what data structure they need up front.

Customisation: how much is too much

A useful rule is to customise reports, forms and one or two key workflows, and leave the core accounting, stock and approval logic alone. Every deep change creates a debt that comes due at the next version upgrade, when someone has to retest and rewrite it. Companies that stay on old versions for years usually did so because upgrading became too risky.

Before approving any custom feature, ask four questions. Does it affect cash, stock or compliance? Could a process change achieve the same result? Who will maintain it? What happens if the vendor changes the underlying screen? If the answers are weak, defer the feature until after go-live, when you will know whether staff actually want it.

Pakistan-specific traps

Local compliance is often discovered late. Sales tax invoices, withholding records and reporting formats vary by sector, and requirements for retailers and distributors can differ. Test invoice formats and reports in a sample company early, and confirm current rules with your tax adviser instead of assuming the software is automatically correct.

Multi-branch businesses face connectivity and power issues. Decide how point of sale works when the internet drops, where the server or cloud sits, and how often you back up. Hosting that cannot survive a day of load-shedding is not hosting for a business system.

Cash on delivery, courier reconciliation and agent commissions are common operating realities that standard templates may not cover. If you need them, plan the custom piece deliberately, perhaps through ERP module customization, rather than patching it in a week before launch.

Training that people remember

One lecture on a Friday is not training. Build short sessions around daily jobs: raising a purchase order, receiving goods, issuing an invoice, closing the month. Give each person a test company where mistakes cost nothing, and let them practise with last month's real documents.

Pick a few champions in each department who learn first and help colleagues in the first weeks. Keep a simple log of questions, since repeated questions show where screens or processes confuse people. Plan for refresher sessions after a month, when real problems have appeared.