A checklist for selecting an ERP system

An ERP is a model of how a company works: how an order becomes revenue, how a purchase becomes a payable, how stock moves between a warehouse and a production line. Before any vendor is invited, write that model down. Describe ten to fifteen end-to-end scenarios (quote to cash, procure to pay, plan to produce, hire to retire) in your own words, including the exceptions that distinguish your business. A distributor with consignment stock, a manufacturer with by-products and a services firm with milestone billing are typical cases in which a generic system fails without warning.

Use those scenarios to run the demonstrations instead of the vendor’s script. Ask each team to show the whole flow, including the difficult parts: a credit note against a partially paid invoice, a stock count that disagrees with the system, a month-end close with a late supplier invoice. The quality of the answers is more informative than the length of the feature list.

Fit also covers the scope of the platform. A platform that covers finance, sales, inventory, manufacturing, HR and procurement in one data model saves integration work later; a best-of-breed set of specialist tools gives each department its preferred screens. Neither approach is wrong, but the choice should be deliberate, because it determines how much integration the organization will own.

No ERP runs alone. It exchanges data with banks, e-commerce storefronts, point-of-sale systems, a warehouse or production system, a CRM, the tax authority’s services and often a parent company’s consolidation tool. Draw the integration map before the selection is made. For each connection, decide whether it is batch or real time, which system owns the data, and what happens when the other side is unavailable.

Then examine how each candidate exposes its data. A documented REST API with authentication the organization can govern, webhooks for events, and bulk import and export that can be automated are the minimum. If the only route to the data is a vendor consultant writing a stored procedure, every future change becomes a purchase order. Ask to see the API documentation and ask which other customers have integrated with it.

Finally, decide where the integration logic will live. Point-to-point connectors are fast to build and slow to maintain; a small integration layer owned by the organization requires more work at the start and costs considerably less by the third year.

Treat migration as its own workstream with its own owner. Begin with a data inventory: which master data (customers, suppliers, items, chart of accounts, employees) and which open transactions (open invoices, open purchase orders, stock balances, fixed-asset registers) must move, and how far back history has to be queryable in the new system rather than kept in an archive.

Cleanse the data before loading it. Duplicate customers, items with three units of measure and no conversion factors, and suppliers with expired tax IDs each become a reconciliation problem on the go-live weekend. Build the load scripts early and run them repeatedly against a copy of production, reconciling control totals (trial balance, AR and AP aging, stock valuation) each time. The final load should be uneventful because it has already been performed several times.

Agree the cut-over approach with finance. A clean start at a period boundary with opening balances is simpler than migrating transaction history; if history is required, agree exactly which reports must reproduce before sign-off.

The systems that fail in the first year are rarely the ones with the wrong feature set. They are the ones in which the people who use them every day were informed of the change rather than involved in it. Put process owners from finance, sales and operations on the selection team with real authority. Let them run the scenario demonstrations, and have them sign off on the to-be processes alongside the IT director.

Plan training by role and by scenario, close to go-live, with the data people will see in production. Identify super-users in each department before training starts and give them time in the sandbox. Keep the old system read-only for a period after cut-over so that people can check figures, then switch it off on a date announced in advance.

Finally, avoid rebuilding every existing report and screen in the new system. Some of them existed because the old system could not do something the new one does natively. Give the new processes a quarter before deciding what is genuinely missing.