Process defines master data, and most people get it backwards

hello@miller-forge.com (Brian Miller) — Tue, 27 Oct 2026 10:00:00 GMT

Most master data cleanups start in the wrong place. Someone pulls an export, counts the blanks and duplicates, and launches a project to fix them. The records look good on the day the project closes. Then the same fields drift back, because nothing about how the data gets created or used has changed. Process defines master data. If you can’t name the process step that reads a field and the person who owns it, cleaning that field is wasted effort.

Why cleanups decay

A cleanup treats bad data as the problem. Bad data is a symptom.

The research on data quality has said this for a long time. One foundational paper defines good data as data “fit for use by data consumers,” not data that is correct in some abstract sense.¹ A later framework for data governance goes further. Accuracy, timeliness and completeness have to be defined against how the data will be used, and someone has to hold the decision rights for those standards.²

Studies of manufacturers point the same way. A survey of 787 Danish manufacturing companies concluded that poor master data quality should be treated as an organizational problem rather than mainly an IT one.³ Interviews at eight high-tech companies found the same pattern: unclear definitions, “inadequately defined data ownership,” and no routine upkeep of data quality once the data was in.⁴

I’ve seen every one of those in practice. Fields get filled in because the system requires a value, not because anyone downstream needs it. Ownership is spread across three functions, so nobody owns it. And the cleanup team goes back to its day job.

It shows up in public filings, too

This isn’t only a problem for small plants with spreadsheets. Sometimes a public company reports a material weakness to the Securities and Exchange Commission (SEC). That’s a serious gap in the controls behind its financial statements, and master data is often in the story:

A candy manufacturer reported a material weakness while it brought a new finance and operations system live. Auditors adjusted for “incorrect units of measure in inventory pricing” and inconsistent overhead. Its remediation plan sets one definition for each unit of measure, so item records, product structures and cost valuation all count the same way.⁵
A large chemical manufacturer listed four material weaknesses. One was its controls over “vendor master data in order to prevent unauthorized cash disbursements.”⁶
A specialty refiner traced a material weakness to data conversion and data integrity in its enterprise resource planning (ERP) implementation. The remediation included controls over how changes to master data are initiated, tested and approved, plus more training for the people using the new system.⁷

Where these filings describe a fix, two themes repeat: definitions tied to the process that uses the data, and control over who changes it.

Start from the process, not the table

When I led enterprise business improvement at a global equipment manufacturer, we ran a master data cleanup as part of a broader push to fix processes with standard work. The fields that stayed clean were the ones we tied to a specific process step and an owner.

The practical starting point was to sit down with the materials teams and sort the key master data elements by the area that uses them. We built the groups and fields around Plan for Every Part (PFEP). It’s a lean practice of keeping the critical details for every part in one place. That covers how much is used, where it’s stored and used, where it comes from and how it ships.⁸ We ended up with six field groups:

Field group	Example fields	What it serves
Core	Part ID, unit of measure, material type, ABC class, demand rank	Identifying and classifying the part
Supplier sourcing	Make or buy, vendor, minimum order quantity, standard lot size, standard cost	Buying it
Supplier lead time	Order entry, material acquisition, manufacturing, transit and receiving times	Planning when to buy it
Line-side material presentation	Container type, quantity per container, kitted, replenishment strategy	Feeding the production line
Logistics	Default container, container dimensions and weights, pallet size, stackable, hazmat	Moving it
Warehouse	Safety stock, ABC/XYZ class, storage type, put-away strategy, cycle count class	Storing and counting it

Example fields only. Your groups will follow your own processes. ABC class ranks parts by usage value; XYZ class ranks them by how steady their demand is.

We also defined the standard for each field as part of the project: what it means, and which value to use when, for the business process it serves. That gave us something to test against, so a value could be judged right or wrong instead of just filled. Then we tested those fields against a random sample of in-stock parts at each site. At one site, most sampled parts were assigned to material controllers who no longer worked there. Every part had a total lead time, but none had the pieces that make it up, and lead times had been padded for risk with no recorded reason. Dimensions loaded in an earlier project were wrong often enough that some parts showed a volume larger than the box they shipped in. And the same field meant different things at different sites: some used ABC codes the others didn’t have.

We then rolled the standards out to every site, so everyone worked to the same definition of each field. We adapted them when a site found an edge case the standard didn’t cover.

Sorting fields this way gives every field a reason to exist. If a field doesn’t serve any group’s process, nobody will keep it accurate.

It also pulls compound fields apart. Total lead time is a good example. It’s really the sum of order entry, supplier acquisition, the supplier’s manufacturing time, transit, and receiving. Each piece is known best by a different person: the buyer, the supplier, the logistics team, the receiving dock. When lead time lives as one number that nobody owns, it goes stale. When it’s built from segments, each one has a natural keeper, and material requirements planning (MRP) stops scheduling against a number nobody has checked.

One owner per field group

Ownership is where most programs go vague. “The business owns the data” sounds right and changes nothing.

The fix that has worked for me is to give each field group a single owner, not each record. A part record is used by planning, purchasing, quality and costing; giving the whole record to one person makes them a gatekeeper for fields they don’t understand. Giving each field group to the function whose process consumes it puts accountability where the knowledge already is. Others can request changes. The owner makes them, against a standard everyone can see.

Make it stick: change management

Field groups and owners are the design. Change management is what keeps them working once the project is over. It starts with deciding who sets the rules and who follows them.

Global, local or business unit? Companies with several plants or business units feel this most. When every site runs its own master data, you get the drift we found: local codes and local meanings. Plants also set parts up for their own production, and aftermarket and other business units live with the gaps. When everything is centralized, a small team becomes a bottleneck far from the floor, and the people who know the parts wait in a queue to fix them.

What works best, in my experience, is center-led. A small central team defines the standards: the field groups, one definition per field, the ownership rules and the reports. The local sites or business units are responsible for executing them, because they’re closest to the parts. The center decides what “right” looks like and checks it; the sites keep it right.

Maintaining existing records is one challenge. Setting up new materials is another, and it’s often handled by different groups altogether, such as engineering, a new product team or purchasing, before the plant ever sees the part. If those groups aren’t part of the rollout, every new part starts outside the standard and the cleanup never ends. We saw parts arrive at a site with no setup or planning strategy, sitting on the dock until someone needed them. Bring the teams that create materials into the rollout and give them the same definitions.

Documentation. The center writes one definition per field: what it means, which process step reads it, who owns it, and what a correct value looks like. Every site uses the same definition. Then write standard work for the moments when data gets created or changed: a new part, a new supplier, an engineering change. That way the person who owns each field sets it when it changes.

Training. Too often people learn master data by watching the person next to them, and every workaround gets passed along with it. Train by role instead. Show the people who create and change records which downstream steps depend on each field and what breaks when it’s wrong. The center builds the training once; local owners deliver it, site by site, and refresh it when a process changes. The refiner above paired its new change controls with training, too.⁷

Reporting to monitor it. The center builds a few exception reports that run on a schedule. Each one sends problems to the local owner who can fix them:

key fields left blank
values outside sensible limits
fields that contradict each other, like an active part with no planner, or a material status that doesn’t match the sales status
changes made by someone other than the owner

Add a small sample audit that checks whether values are correct. A report that only shows how complete the fields are can look healthy while the data is wrong. Review the exceptions in a meeting you already hold, and re-test the sample on a schedule.

Easy wins

You don’t need a program office to start. None of these needs a budget:

Start small. It’s easy to get overwhelmed by trying to fix every process at once. Pick one process that hurts, such as late purchase orders or a planning run nobody trusts, and only the field groups it reads.
Map those fields to the process steps that read them. Add the next process once the first one holds.
Assign one owner per field group. Write the name down where everyone can see it.
Set a few quality checks. Track accuracy on the fields that matter and review it regularly.
Stop maintaining fields nobody uses. Research on data quality costs argues that “perfect data quality should not be the goal”; the right level is whatever your processes actually need.⁹

Where to begin on Monday

Walk that first process end to end with the people who run it. List the fields each step reads, sort them into groups, and name an owner for each group. You’ll have a short list of fields, owners and checks by the end of the week, and something you can measure the month after.

That’s where I start in cost and process improvement work: with how the work actually runs, then making the data serve it.

Richard Y. Wang and Diane M. Strong, “Beyond Accuracy: What Data Quality Means to Data Consumers,” Journal of Management Information Systems 12(4), 1996. ↩
Vijay Khatri and Carol V. Brown, “Designing Data Governance,” Communications of the ACM 53(1), January 2010. ↩
Anders Haug, Jan Stentoft Arlbjørn, Frederik Zachariassen and Jakob Schlichter, “Master data quality barriers: an empirical investigation,” Industrial Management & Data Systems 113(2), 2013. ↩
Risto Silvola, Olli Jaaskelainen, Hanna Kropsu-Vehkapera and Harri Haapasalo, “Managing one master data – challenges and preconditions,” Industrial Management & Data Systems 111(1), 2011. ↩
Rocky Mountain Chocolate Factory, Inc., Form 10-K for the fiscal year ended February 28, 2026, Item 9A. ↩
The Chemours Company, Form 10-K for fiscal 2023, filed March 27, 2024, Item 9A. ↩
Calumet Specialty Products Partners, L.P., Form 10-K for fiscal 2019, Item 9A. ↩ ↩²
Doug Bartholomew, “Why a Plan for Every Part Is Essential to Lean Transformations,” The Lean Post, Lean Enterprise Institute, April 17, 2015. ↩
Anders Haug, Frederik Zachariassen and Dennis van Liempd, “The costs of poor data quality,” Journal of Industrial Engineering and Management 4(2), 2011. ↩