Document how you actually work
Before evaluating products, map your real processes — including the workarounds, the spreadsheets, and the exceptions that people handle by hand. That map is what you are buying a system to support.
Skipping this means judging demonstrations against an idealised version of your business, and discovering the difference during implementation, when changes are most expensive.
Decide where you are genuinely different
Most processes in most businesses are ordinary, and the product's standard approach is fine. A small number are genuinely distinctive, and those are worth configuring around carefully.
The expensive mistake is treating every existing habit as a requirement. "We have always done it this way" is not the same as "this is how we compete", and conflating them is the main driver of ERP cost overruns.
Resist customisation
Configuration within the product's intended flexibility is safe and upgrade-friendly. Modifying core behaviour is expensive, fragile, and frequently blocks upgrades permanently — which strands you on a version that eventually loses support.
Where a gap is real, prefer an integration or a satellite application over modifying the core.
Treat data as a workstream
Master data is usually in worse condition than anyone expects: duplicates, inconsistent codes, records that reference entities that no longer exist.
- Profile the data early to find out how bad it actually is
- Decide what will be migrated and what will be archived rather than moved
- Cleanse in the source system where possible, so the problem does not recur
- Reconcile before go-live, with acceptance criteria agreed in advance
- Plan for at least one full rehearsal of the migration
Plan adoption as seriously as configuration
The most common ERP failure is a technically correct system that people work around. Role-based training, documentation written for the job rather than for the software, and visible support in the first weeks determine whether that happens.
Identify people in each area who will be the local expert, and involve them early enough that they are advocates rather than recipients.
Protect the first close
The first month-end or year-end on a new system is where problems concentrate. Plan hypercare across it specifically, with the implementation team available and the old system still accessible for reference.
Do not schedule go-live immediately before your busiest period, however tempting the fiscal alignment is.