What Good Looks Like for Item Master Data
Everyone agrees the item master is broken. Almost no one can say what fixed would look like.
June 23, 2026
A warehouse in Texas holds the same bearing in five places. Five part numbers. Five descriptions. Five reorder points.
Nobody knows they’re the same bearing until the day all five run out at once.
Everyone agrees this is broken.
Almost no one can say what fixed would look like.
“Clean” isn’t a specification. It’s a feeling. And feelings don’t survive contact with a procurement system.
So before evaluating any platform, before scoring any vendor, before signing anything — it’s worth answering a harder question than the one most organizations ask. Not how bad is our data. They know how bad. The harder question is: what, precisely, does good look like?
Good is not clean
The word “clean” has done enormous damage to this industry.
It sounds like a standard. It functions like a mood. Two people look at the same item master and disagree about whether it’s clean, because neither has written down what clean would mean. One sees consistent capitalization and calls it clean. The other sees fifty thousand records that can’t be searched and calls it filthy. They are both looking at the same data.
A cleanup project delivers “clean” the way a tidy desk delivers productivity — visibly, briefly, and without touching the thing that mattered. The records look better on the day of handover. Whether they are good is a different question entirely, and it is not a question of appearance.
Good item master data is not data that looks clean. It is data that does its job. And the job has a definition.
The job a record has to do
An item master record exists to answer one question reliably: what is this thing, and have we already got one?
Everything good follows from that. Everything broken is a failure to answer it.
The five-bearing warehouse failed the second half. Each record was, on its own, perfectly acceptable. Spelled correctly. Filled in. Approved. The failure was not in any single record. It was that five of them described one object and none of them knew about the others. The data was clean. It was also useless, in the only way that counts.
So the first property of good is this: a thing exists once. One bearing, one record. Not because duplication is untidy, but because every duplicate is a future stockout, a fragmented purchase history, a reorder point set against a quantity that isn’t real. Uniqueness isn’t hygiene. It’s the difference between a system that can answer “have we got one” and a system that can only guess.
The second property: a record means the same thing to everyone who reads it. The person who creates it, the buyer who sources against it, the engineer who searches for it eighteen months later — all three have to arrive at the same object. That only happens when the description is built to a structure, not typed from memory. “Bearing, ball, 25mm bore, SKF” survives being read by a stranger. “SKF brng – see notes” does not. One is a record. The other is a message to whoever wrote it, and only to them.
The third property: the record is findable by someone who doesn’t already know it’s there. This is the one organizations forget, because the people testing the data are the people who built it — and they can always find what they filed. The real test is the engineer at 2 a.m. who needs a 25mm bearing and has never seen this catalog. If the only way to find the record is to already know its part number, the data has failed a person it will never meet. Good data is searchable by description, by attribute, by the language the person actually uses — not only by the key the system assigned.
What the gap actually costs
The distance between clean and good is not academic. It is paid for, continuously, by people who never see the data.
The buyer pays it first. Facing five records for one bearing, they cannot consolidate the spend, so they negotiate five times for one thing and win none of the leverage that volume should have bought. The maintenance planner pays it next, ordering against a reorder point that describes a fifth of the real demand, and discovering the shortage on the day the line is down. The new engineer pays it last and worst — searching for a part that exists, finding nothing, and creating the sixth record, because the system gave them no way to know the other five were there.
None of these people filed a complaint about data quality. They experienced it as something else entirely: a stockout, a missed discount, a duplicate they didn’t know they were creating. The data failure wore the costume of an operational failure, and the operational failure got the blame.
This is why “clean” is so dangerous as a goal. Clean data can produce every one of those failures while looking immaculate in a screenshot. Good data is defined by the absence of those failures, not by the presence of tidy fields. The difference is invisible in the catalog and brutally visible on the floor.
How to tell good from clean in ten minutes
You do not need an audit to know which kind of data you have. You need three questions, and the courage to ask them of your own system.
Search for a common item the way a new hire would — by what it is, not by its number. A bearing. A gasket. A relay. Count how many ways the same physical thing comes back, spelled and structured differently. Good data returns the thing. Broken data returns a history of everyone who ever entered it.
Pick a category and ask what makes a complete record in it. Not whether the fields are filled — whether the right fields are filled, the ones that distinguish this item from the forty similar ones beside it. A bore size that’s blank on a bearing is not a small gap. It’s the gap that creates the duplicate.
Then ask the question nobody likes: when a new item is created tomorrow, what stops it from becoming the sixth bearing? If the answer is “the person creating it will be careful,” you do not have good data. You have lucky data, and luck is not a data strategy. Good data is protected at the moment of creation, not audited after the fact — because the alternative is the cleanup you will be commissioning again in two years.
Why this is the standard, not our standard
None of this is specific to any platform. It is not a feature list. It is what good item master data is, measured by what it has to do — and any organization can hold any vendor to it, including us.
That is the point. The industry has spent years letting the tools define the scorecard — evaluating platforms by the features they happen to have, rather than by the outcomes the data has to deliver. It is backwards. The standard comes first. The thing exists once. It means the same to everyone. It’s findable by a stranger. It stays that way without heroics.
A platform either produces data with those properties or it doesn’t. Everything else is configuration.
We’ve spent fifteen years watching item masters fail, across oil and gas, utilities, mining, manufacturing — and the failures are never exotic. It is always the same bearing, in five places, discovered on the worst possible day. Organizations tell us, eventually, that they didn’t need a cleaner catalog. They needed one that couldn’t decay back into the thing they paid to fix.
That is what good looks like. Not clean. Good.
A thing exists once. It means the same to everyone. A stranger can find it. And nothing about that erodes the day after you stop looking.
Everything else is just tidy.
This is the first article in a three-part series on what good master data actually looks like — item, vendor, and asset — and how to evaluate any platform against the standard.
About the Author
Raghu Vishwanath is Managing Partner at Bluemind Solutions, a product engineering firm specializing in MRO master data governance. He writes about software engineering, AI, and building platforms that last.