Master data is the least glamorous item on any warehouse programme and the one most likely to be the reason the first week live goes badly. On a greenfield site it is worse, because there is no legacy system to export from, no history of what moves and what does not, and no floor to walk with a tape measure until quite late in the build. Everything has to be created from drawings and assumptions, and then verified against steel and product once they arrive.
What has to exist before go-live.
The list is longer than most sponsors expect, and each item on it is a decision as much as a data entry.
The warehouse structure.
Storage types, storage sections, bin types and the bins themselves. This is the system's picture of the physical layout: which aisles are pallet racking, which are shelving, which are floor bulk, which bins take a full pallet and which take a carton. It is built from the racking drawings, and it is wrong wherever the drawings and the installed racking differ, which is more often than anyone likes.
Product master.
For every product, the dimensions and weight of each unit of measure, the packaging hierarchy, the storage conditions, the handling rules. Get the pallet quantity wrong and putaway will send a pallet to a bin it does not fit. Get the weight wrong and the system will build a load that overloads a truck.
Packaging specifications.
How product is packed for storage and for dispatch: cartons per layer, layers per pallet, which pallet type, which customer wants what. On a first WMS these are usually in someone's head, and that person is about to be very busy.
Resources, work centres and queues.
The forklifts, the pickers, the packing benches, the queues that route work to them. This is where the process design becomes data, and it has to match the design the operators were shown.
Business partners and routes.
Carriers, customers, ship-to addresses, the route determination that decides which dock a delivery goes to. Usually inherited from the ERP, usually incomplete for a site the ERP has never shipped from.
The mistake that costs most.
It is not a data error. It is an ownership gap. The integrator builds the structures, because that is configuration and configuration is their job. The business is asked to provide the product data, because it is their product. And nobody is named as the person who signs off that a pallet of this product physically fits a bin of that type, that the weight is measured rather than copied from a supplier spreadsheet, that the carton quantity on the system is the carton quantity on the floor.
The gap does not show up in build. It shows up in test, if the test uses real product, or in the first week live if it does not. By then the racking is in, the labels are printed, and every fix is a physical fix as well as a data fix.
Doing it in the right order.
Name the owners first, before any object is created. One person per data domain, with the authority to sign it off and the time to do it. Build the warehouse structure from the racking drawings early, then verify it bay by bay when the racking is installed, before a single label goes on. Measure product, do not import it: a day with a tape measure and a scale on the top hundred movers is worth more than a thousand rows from the supplier. Test the data against the physical floor as early as the floor exists, and treat every mismatch as a defect with a name against it.
On a greenfield site every data mistake is original. Nobody made it before you, and nobody will fix it after go-live without touching the steel.
How Luminar approaches master data.
We set the ownership before the build starts, in writing, with a name against every domain. We walk the racking drawings with the operations team so the structure the system will hold matches what they expect to see on the floor, and we walk the installed racking again before labelling. And we insist that testing uses real product on real bins, because a UAT on sample data proves nothing about whether the plasterboard fits.