When an ERP implementation goes wrong, the post-mortem rarely blames the software. It blames the rollout: unclear processes, data that nobody trusted, and staff who were trained on a system they never helped design.
Map the process before the configuration
A configuration is only as good as the process it encodes. We spend the first two weeks with the people who run finance, purchasing and stores — not to write a specification, but to see how information actually moves between them.
- Where does data get re-entered between systems?
- Which approvals live in email instead of a workflow?
- Which numbers does leadership not trust, and why?
Migrate the data you can defend
Legacy data is rarely clean. Migrating everything faithfully just moves the mess into the new system. We profile the data first, agree what to fix, and migrate in a rehearsed dry run before anyone goes live.
They closed the month in two days and trusted the numbers. That only happened because we refused to import the parts of the old data nobody could explain.
Roll out in phases, not a big bang
A single cutover across every branch is the riskiest possible plan. Going live one site at a time surfaces issues while they are still small, and it gives the wider team proof that the system works before it touches them.