Eight months after go-live, the item master held more than 1,700 duplicate descriptions, and pick accuracy had slid from 99.6% to 97.1%. Last year, the owner of a 3PL warehouse in Rancho Cucamonga put those numbers in front of me and asked: did we buy the wrong WMS?
We pulled the system logs together. The system was fine. The data was the problem. One SKU had been created three times: sales entered it as "Bluetooth earbuds - black," customer service re-created it as "BT earbud blk" when rushing a backorder, and the receiving lead, in a hurry, created a third code. Three people, three descriptions, one physical product. Pickers stood at the location with an RF gun, staring at three names on the screen, unsure which one to grab.
At go-live, the data had been clean. The project team spent two months scrubbing it, and the implementation consultants reviewed every SKU record. But six months later, nobody owned it anymore. IT said master data was the business's job; operations said the system was IT's job. So it became nobody's job. The data rotted a little more every week, the system got harder to use every month, and the owner started wondering whether the money had been wasted.
The money wasn't wasted. What was missing was a role.
Start With the Rules: Who Creates, Who Edits, Who Gets In
Most small and mid-size warehouses have no such thing as a master data administrator. SKU creation rights sit with a dozen people: sales creates SKUs to get orders in faster, customer service creates them to push replenishment through, the receiving lead creates them because it's quicker than asking. The wider the permissions spread, the less anyone feels responsible.
My advice is blunt: pull creation rights back to two or three people, and name one of them the data steward. The best candidate is usually the WMS super user, or the receiving supervisor wearing a second hat — he touches physical product all day, and when a description is wrong he's the first one the pickers yell at. That gives him a natural incentive to get it right.
Write down three things and pin them on the wall: who is allowed to create a new SKU; who approves changes to location attributes and lot rules; who cleans up legacy dirty data, and on what schedule. Put it on paper. Verbal agreements have a shelf life of about three months.
People ask me: we're a thirty-person shop, is a dedicated role overkill? It doesn't need to be full-time — a second hat is fine. But "second hat" can't mean "whenever I feel like it." It has to be written into the job description, with half a day a month reserved for it. Work that isn't in the job description doesn't get done.
A steward without a gate is still guessing, so you need an intake checklist too. Ours looks like this: SKU codes are generated by rule, never hand-typed as "temporary"; descriptions must include brand, spec, and unit of measure — no "the blue one" or "big box"; length, width, height, and weight are mandatory and must come from an actual scale, because supplier-provided carton dimensions are wrong nine times out of ten; barcode rules are fixed, one code per SKU, new packaging means a new code; ABC classification gets an initial call, then gets revisited after three months of velocity data; lot and expiry requirements are decided on day one, because adding them later is the most painful retrofit of all; putaway strategy is decided at intake too — full-pallet storage or each-pick — since that determines which zone it goes to.
The checklist looks fussy. In practice it adds about five minutes. But think about it: one bad SKU poisons receiving, putaway, picking, and cycle counting — four processes downstream. Fixing it later costs a hundred times what getting it right at intake costs. That's not a hard calculation.
The hardest thing to control is the "temporary SKU." Peak season hits, sales lands a rush order, the SKU doesn't exist yet, and the truck is already at the door. My rule: temporary codes are allowed, but they must be converted to real SKUs within 30 days, with a system reminder at expiry. When converting, every missing field gets filled in at once. Temporary is fine. Rotten is not.
First Line of Defense: Let the System Block It
People get lazy. So the first line of defense belongs to the system.
Lock down validation rules in the WMS: required fields can't be saved empty; description fields get a similarity check that warns on near-duplicates; barcodes are unique across the database, duplicates rejected outright; a weight or dimension of zero — or something absurd — gets blocked. These configurations look minor. They stop roughly eighty percent of low-grade errors before they exist.
One tougher move: separate SKU creation from "sellable." A newly created SKU defaults to "pending review" and only goes live after the data steward signs off. However urgent sales is, they wait those five minutes. Those five minutes are the trade-off between data quality and business speed. My verdict: the five minutes are worth it, because one rotten SKU released into the wild creates nothing but trouble downstream.
Second Line of Defense: Humans Go Spot-Check
The system can block bad formats. It can't block wrong content in the right format — a complete description with the wrong spec. That takes a human.
The method is sampling, not full audits — full audits aren't realistic. Every week, pull 20 newly created or modified SKUs, and the steward checks each against the physical product: is the description right, are the dimensions accurate, does the barcode scan? When something's wrong, trace it back to who created it and fix it on the spot.
Add a monthly location-attribute sample on top. Location attributes rot fastest: a location marked full-pallet-only gets stuffed with eaches six months later; a location flagged "no entry at peak" means nothing to a forklift driver hired last month. Sample 50 locations, fix whatever doesn't match reality, and write down why — was it set up wrong originally, or did someone misuse it later? Those are two different problems with two different fixes.
The danger with sampling is theater. My crude fix: the sampling log must record how many issues were found. Three straight months of "zero issues" means the sampling itself is broken. In a real warehouse, zero issues basically doesn't happen.
Third Line of Defense: Tie It to the Paycheck
If the first two lines are in place and the data still decays, there's exactly one reason: the people creating bad data don't feel it.
So the third line is accountability. Put master data accuracy into department KPIs — or more directly, attribute picking errors and mis-shipments caused by master data problems to the person who created the data. Not a fine. An error record that affects performance reviews. Data quality never climbs the priority list until it's tied to someone's livelihood.
The steward needs the carrot too. He spends half a day a month scrubbing data, nobody notices, and his year-end review looks the same as if he'd done nothing — next time he won't bother. I list "master data accuracy" as a separate bonus line for him: cleaner data, bigger number. The carrot doesn't have to be big. It has to exist.
Three lines together: the system blocks eighty percent, human sampling catches the leaks, accountability fixes the motivation. No single line is a silver bullet. Combined, they work.
Tomorrow morning, do two things. First, pull SKU creation rights in your WMS back from a dozen people to two or three. Second, print the intake checklist and pin it on the receiving office wall. Just those two — nothing else for now. Check your pick error rate in a month. The numbers will talk.
