Before you choose an ERP: five questions that decide the outcome

Most post-launch ERP complaints — duplicate records, reports nobody trusts, a module everyone works around — trace back to decisions made or avoided before a single screen was configured. An ERP does not fix an unclear process; it makes the process permanent. Whatever ambiguity existed in how work actually happens gets encoded into the system and becomes much harder to change once departments are used to it.

That's why the first useful question is not which platform to buy. It's which of the organization's processes are stable and well-understood enough to be encoded at all, and which ones are still evolving and should be left flexible a little longer.

That's why the first useful question is not which platform to buy.

Before configuration begins, decide who owns each core data object — the customer record, the item master, the vendor file. When two departments both believe they own the customer record, the system will show two versions of the truth no matter how carefully it is configured, because the underlying ownership question was never actually settled.

In practice this means naming one accountable owner per object, in writing, before go-live — not a committee, one person or one role. That owner decides what counts as a valid entry and who is allowed to create or merge records, which prevents the slow drift into duplicate and conflicting data that surfaces months later as a 'reporting problem.'

In practice this means naming one accountable owner per object, in writing, before go-live — not a committee, one person or one role.

Reporting requirements shape master data far more than screens do. If finance needs cost visibility by project and by branch, that dimension has to exist in the chart of accounts and the item structure from day one — retrofitting it after transactions have already been posted is expensive and sometimes impossible without a data cleanup project of its own.

A practical approach is to write out the five or six reports leadership actually reads every month before configuring a single module, and work backward from there to the fields and dimensions that need to exist.

Plan the migration of history separately from the go-live date. Trying to clean five years of records during launch week is the single most common cause of delay, because data-quality problems are discovered under the worst possible time pressure — right when the team also needs to run training and cut over live transactions.

Migration should be treated as its own workstream with its own timeline: extract early, profile the data for duplicates and missing fields, decide what history is actually worth migrating versus archiving as read-only, and rehearse the load at least once before the real cutover.

Budget for the period after go-live as deliberately as the implementation itself. Adoption, correction of early configuration mistakes, and refinement of reports decide whether the investment turns into an operational advantage or a system people quietly work around.

A realistic post-go-live plan names who handles support requests in week one versus month three, sets a checkpoint at 30/60/90 days to review what's actually being used, and keeps a small budget reserved for the configuration changes that only become obvious once real transactions are flowing through the system.

Before signing off on scope, a useful gate is a short checklist: one named owner per core data object; the five or six reports leadership reads every month, written down; a migration plan with its own timeline separate from go-live; a support and refinement plan for the first 90 days; and at least one process that was deliberately simplified before it was configured, not just automated as-is.