When a manufacturing software rollout goes badly, the story afterwards is usually about the software. The real failure is almost always earlier and duller: the item list was wrong, the units were inconsistent, the supplier records were duplicated, and the opening stock did not match the shelf. Everything downstream inherited that, and by the time anyone noticed, it looked like the system was wrong.
This is the least glamorous part of any project and the part that decides it.
Why master data breaks rollouts specifically
Operational software is a set of calculations over your own records. Requirements planning is arithmetic on bills of materials and stock. Scheduling is arithmetic on capacity and orders. Costing is arithmetic on consumption.
Arithmetic on bad inputs produces confident, precise, wrong answers — which is worse than no answer, because people act on it. A planner who is told twice that the material is in stock when it is not stops believing the planning screen, and a planning screen nobody believes is a spreadsheet with extra steps.
The four that cause most of the damage
Item codes that encode meaning. SOAP-WHT-25KG-V2 looks helpful until the pack size changes and the code lies. Codes should identify; attributes should describe. Put the pack size in a field, not in the name.
Units that are not defined at the point of purchase. You buy palm stearin by the tonne, issue it by the kilogram, and count drums. If the conversion lives in someone's head, every stock figure is a guess. Categories and units covers the ten minutes of setup that prevents this.
Duplicate suppliers and customers. The same company as three records means three payment histories, three price lists and no usable view of what you actually spend with them.
Opening stock taken from the last count rather than a fresh one. A go-live inherits whatever variance was already there, and then every discrepancy for six months gets blamed on the new system.
The uncomfortable arithmetic
Master data work is unglamorous, invisible to management, and impossible to delegate entirely, because the only people who know whether two item codes are really the same product are the people already busiest on the floor.
It also cannot be compressed. A vendor who says implementation takes four weeks is describing configuration time, not your data cleanup. Those are different projects and only one of them is theirs.
The honest sequence is: clean the data, then configure, then go live, and the first step is usually the longest. Anyone who tells you the first step can run in parallel with the third has not done it.
What good preparation looks like
- One person owns the item list. Not a committee. Someone who can decide that these two codes are the same thing and delete one.
- Every unit conversion written down before anything is loaded, including the awkward ones — drums that vary, bags that are nominal, bulk that is weighed at the weighbridge.
- A fresh physical count immediately before cutover, not a carried-forward figure.
- A frozen scope for phase one. One site, one product family, the full order cycle. Breadth after depth. Plants that go live on everything at once go live on nothing.
Before you sign anything
Export your current item master to a spreadsheet and sort it by description. Read it.
Most plants find duplicates within the first fifty rows, items nobody has bought in three years, and at least one unit that means two different things. That list is your real project plan, it is free, and it is the same work whatever software you eventually choose.