Ask anyone who has lived through a failed ERP implementation what went wrong and you will usually hear about the software. It did not fit. It was too rigid. The vendor over-promised.
Occasionally that is true. Far more often, the project drowned in master data.
What bad master data looks like
It is never dramatic. It is:
- The same supplier entered four times, with four different spellings, three of which have open purchase orders against them.
- Stock items with no unit of measure, or with a unit of measure that means something different in the warehouse than in purchasing.
- Customers who are also suppliers, recorded twice with no link between the records.
- Opening balances that nobody can tie back to a trial balance.
- Bills of material that have not been updated since the product specification changed eighteen months ago.
None of that is visible in a demo. All of it surfaces the week before go-live.
Why it gets left to the end
Because it is nobody's job, and because it is unpleasant.
Data cleanup requires someone who knows the business well enough to decide which of four supplier records is the real one. That person is always busy, and the task has no obvious deadline until the migration date arrives.
So it slides. Then a fortnight before go-live somebody runs a real import, discovers 3,000 validation errors, and the project either delays or launches on data everyone knows is wrong.
Launching on wrong data is the worse outcome, because it destroys user trust in the system permanently. People who do not trust the stock figure will keep their own spreadsheet, and then you are paying for an ERP and running a shadow system.
What to do instead
Pull the data in week one. Not to migrate it. To measure it. Row counts, duplicate rates, missing mandatory fields, orphaned references. A one-page report with real numbers.
Put a name against each data domain. Customers to the sales manager, suppliers to procurement, items to operations, balances to finance. Not "the project team". A person.
Make the cleanup visible. A weekly number that goes down. It is remarkable how much faster this moves when the duplicate count is on a slide the managing director sees.
Run the import at least twice before the real one. The first run finds structural problems. The second finds the ones the first run's fixes introduced.
Decide what you will not migrate. Ten years of closed transactions do not need to come across. Agree an archive strategy early, because "migrate everything" is how a four-week data task becomes a four-month one.
The uncomfortable part
Sometimes the cleanup reveals that a business process is broken, not just the data recording it. A stock discrepancy that cannot be explained is often a process that never recorded a real movement.
Finding that is valuable. It is also politically difficult, and it is the reason data work needs sponsorship from someone senior enough to say "yes, that has been wrong for years, let us fix it" without it becoming a blame exercise.
What we do
Data cleanup is a line item in every ERP proposal we write, with its own budget and its own named owners on the client side. Timelines look longer on paper because of it.
They are shorter in practice, and go-live is not the week everyone dreads.
