AxonRays Technologies · Implementation resource
ERP implementation checklist
Thirty-one decisions, grouped by phase. Most of them are business decisions rather than software ones, and most of them are cheaper to make before configuration starts than after.
Use it as an audit of a plan you already have, or as an agenda for the first workshop. If more than five items in section one are unanswered, the project is not ready to start configuring — and that is a useful thing to know early.
1. Before anything is configured
The decisions that determine the rest
01 Who owns this internally? One named person with authority to decide, not a steering committee. Projects without this drift regardless of who implements them.
02 What is actually broken? Written as a process failure, not a feature request. "Month end takes eleven days" not "we need better reporting".
03 Has the current process been mapped as it runs? Including the workarounds. The undocumented spreadsheet is part of the process whether anyone admits it or not.
04 Which processes are changing, and who agreed? An implementation that changes no process delivers no benefit. Name the changes and get them signed before build.
05 What is explicitly out of scope? The list of exclusions is more useful than the list of inclusions, and far more contested later.
06 What does success look like, measurably? One or two measures with a baseline recorded now. Without a baseline you cannot demonstrate improvement afterwards.
07 Is there a hard date, and what drives it? A financial year end is a real constraint. A date chosen because it sounds reasonable will move, and everyone should know which kind it is.
08 How much of your team's time is committed? In hours per week, by name. The most common cause of overrun is the client team having no capacity to participate.
2. Data
Where most implementations quietly fail
09 Has anyone counted the duplicates? Suppliers, customers, items. The number is always higher than expected and it determines the cleanse effort.
10 Who owns each master data entity? One system of record per entity, one person accountable for its quality. Ambiguity here becomes an integration problem later.
11 Do item codes carry meaning? If the code encodes category or size, decide now whether that survives. Changing it during migration is far cheaper than after.
12 How much history are you migrating? Usually three years plus masters and balances. Everything else belongs in a queryable archive, not the live system.
13 Which valuation method, and who signed it? Standard, moving average or FIFO changes your opening balances and your reported margin. It is a finance decision with operational consequences.
14 Can you derive opening balances without one specific person? If only one person knows how, document the method before the migration, not during it.
15 Does stock currently reconcile to the ledger? If not, the gap does not disappear at go-live. It has to be explained and written down before it is carried across.
16 Who signs the final reconciliation? Finance and operations, on the same report. Without named signers the migration is never actually finished.
3. Interfaces
Design these first, not last
17 Is there a written inventory of every interface? Including the manual ones. A person exporting a file weekly is an interface with a single point of failure.
18 Does each interface have a named owner? Someone who is told when it fails and is responsible for it being fixed.
19 What happens when one fails? Retry policy, alert route and a documented manual fallback. Silent failure is the default unless designed against.
20 Can a message be safely reprocessed? If replaying a file double-posts a transaction, the interface is not finished.
21 Is the mapping documented outside someone's head? Field level, versioned, with the business rule stated beside each transformation.
4. Build and test
Keeping the people who use it involved
22 Do end users see working software every two weeks? The planner, the supervisor and the clerk. Not a project board reviewing a status report.
23 Are you testing with real data? Sample data hides every problem that matters. Test on a copy of production, at production volume.
24 Who writes the test scripts? Ideally your team, describing their own process. Scripts written by the implementer test the implementer's assumptions.
25 Is every customisation justified in writing? Each one is a permanent maintenance cost and a future upgrade risk. Configuration first, always.
26 Has anyone tested the month-end close end to end? The close is where an incomplete implementation surfaces, and it usually surfaces after go-live.
5. Cutover and after
The part that is skipped when the date slips
27 Is there a rollback plan, and can it actually be executed? The old system read-only rather than switched off, and one named person authorised to call it.
28 Are the abort criteria written down and measurable? Agreed before the window, not judged in the moment by people who have been awake since four.
29 Who is on site for the first week? Standing next to the people using it, not reachable by ticket.
30 What is the support arrangement after stabilisation? Named response times and a route for change requests, agreed before go-live rather than negotiated after it.
31 Do you hold the documentation? Configuration decisions, interface runbooks and mappings, in your possession. If you replaced your implementer tomorrow, could the next team read the work?
How to use the answers
Sections one and two are where projects are won or lost. If most of section one is unanswered, do not start configuring — run a scoping phase instead. If section two is unanswered, budget for a data cleanse as a piece of work in its own right rather than as a task inside the build.
Sections three to five are execution discipline. They are usually well understood and badly resourced.
Published by AxonRays Technologies LLP, Ahmedabad, Gujarat, India. We implement ERP, manufacturing execution, supply chain, order, warehouse and inventory systems. If you want to work through this list with someone, a scoping call is forty-five minutes with an implementation lead: cal.com/milankamboya/30min or hello@axonrays.com.
