In short: A field that breaks planning usually has no owner, and the review after a service failure produces several functions each pointing at another one. Most master data errors enter at creation rather than through later corruption, which puts the highest return on validation at the point an item or supplier record is set up. Ownership belongs to fields rather than to systems, so a named person owns planning lead time wherever it is stored, instead of an ERP team owning the system that happens to hold it. Standing checks that produce a work list, such as comparing stored lead time against the last six months of receipts, turn governance into a queue somebody can clear rather than a policy document.
The review after a service failure gets to the cause reasonably quickly. The planning lead time on the item says fourteen days. The supplier has been shipping in something closer to thirty-five for the better part of a year, and every receipt in the system says so.
Then somebody asks who owns that field, and the meeting produces four answers. Procurement thinks the ERP team maintains it. The ERP team says they maintain the system and not the values. Planning says they use it. The supplier development manager, who is the only person who actually knew the lead time had moved, was not invited.
The field has been wrong for eleven months, everyone involved is competent, and nothing in the process was ever going to catch it.
The fields that do the damage
Master data is a large set. The subset that breaks planning is small enough to name, and it is the same list in most businesses.
Lead time, and its components. Supplier lead time, transit, inspection, put-away. This is the field that does the most damage because it enters both the replenishment trigger and the buffer, so an error propagates twice into the same decision. It also has the longest half-life, since nothing breaks on the day it goes stale.
Bills of material. A component substituted on the shop floor and never reflected in the planning structure means the dependent demand is being calculated against a part you no longer use, while the part you do use has no demand signal at all.
Units of measure conversions. Case to each, layer to pallet, litre to kilogram. Failures here are silent and off by a whole factor, which is why they are usually discovered by a warehouse rather than by a report.
Item status and lifecycle codes. An item discontinued in the business and active in the system continues to be forecast, replenished, bought and stored. The commercial decision was taken months ago and the data never heard about it.
Calendars. Shift patterns, receiving windows, supplier shutdowns, customer delivery days, public holidays in the countries you actually ship to. A plan built on a calendar that is wrong is arithmetically correct and undeliverable.
Sourcing rules and valid lanes. Historical lanes that no longer run and current lanes nobody recorded. This one distorts network-level decisions in particular, since a placement calculation is only as good as the topology it was given.
Minimum order quantities and order multiples sit on the boundary. They are commercial and physical facts owned outside planning, consumed as planning parameters, and they belong in the parameter discipline rather than here except in one respect: whoever owns them has to be identifiable, which is the whole subject of this post.
Most errors enter at creation
A field that is wrong when the item is created stays wrong for the item's entire life, because nothing in the normal course of business ever re-asks the question. The item gets planned, bought, sold and eventually discontinued against a value that was typed once by somebody who was in a hurry and did not have the answer.
That makes the new-item gate the control that returns the most for the least effort, and most new-item processes are a form with mandatory fields, which does not qualify as a gate.
A workable gate has a few properties.
Required fields differ by item type, and the requirement is enforced at creation rather than as a downstream exception report. An exception report is a request that somebody fix it later, and later does not arrive.
Values come from controlled lists wherever a list can exist. Free text on a field that feeds a calculation is a defect waiting for a date.
Plausibility is checked at entry, with the band shown. A lead time outside the observed range for that supplier and mode is rejected at the point of typing, with the range displayed, which turns the check into an argument the person can win with evidence rather than a refusal.
Defaults are conservative and visibly marked as defaults. A default lead time of thirty days is the same number as a real thirty and means something entirely different, and the ability to query for fields still holding their creation default is worth more than most of the rest of the gate.
Each field group has a named approving role with a response time attached. This is the part that decides whether the gate survives, because a gate that takes three days will be worked around within a month, and the workaround is a spreadsheet, a favour and an item created with placeholder values that nobody ever returns to.
Ownership belongs to fields rather than to systems
"The ERP team owns master data" is the most common answer to the ownership question and it is not ownership. The ERP team can enforce a format, a mandatory flag and a controlled list. They cannot know whether a supplier's lead time is right, because they have never spoken to the supplier.
Ownership has to sit with whoever holds the information. Procurement owns supplier lead time, minimum order quantity and the commercial terms. Engineering or technical owns the bill of material. The commercial team owns item status and lifecycle, because they take the decision that changes it. Logistics owns calendars, receiving windows and lanes. Planning owns the parameters derived from all of it, and owns none of the inputs.
The artefact that makes this real is a field-level register, and it is a spreadsheet rather than a system. Each row is a field. Each row names the owning role rather than a person, the system of record, the evidence required to change the value, the trigger that should prompt a review, and the tolerance outside which the value is considered a defect. Two hundred rows covers most planning-relevant master data in a mid-sized business, and building it takes a few weeks of arguments that are worth having on paper rather than in a post-mortem.
The data management literature has a fuller apparatus for this, and the DAMA data management body of knowledge in its 2017 edition is the standard reference for the stewardship structures around it. The register is the part that changes behaviour, and I would build it before adopting anything larger, because a governance framework with no field-level ownership underneath it produces committees.
Standing checks that produce a work list
The check set should run continuously and produce a ranked list of things to fix, ordered by what the defect is costing. A report ordered by item number is a report.
The checks that earn their place on a planning desk are mostly comparisons between a stored value and observed behaviour.
Lead time parameter against the trailing distribution of actual receipts for that item and supplier. Flag where the parameter sits outside a defined percentile band of what actually happens. This one check finds more damage than the rest combined.
Parts being purchased that appear on no active bill of material, and bill of material components with no active supply source. The two directions catch different failures and both are common.
Unit of measure conversions that fail a round trip, and conversions implying a unit weight or volume outside a plausible range for the category. The second catches errors the first does not, since a consistent conversion can still be consistently wrong.
Active items with stock on hand and no demand for a defined number of periods, alongside discontinued items with open purchase orders. These two are the item status field failing in each direction.
Fields still holding their creation default on items that have been trading for more than a quarter.
Sourcing rules pointing at lanes with no receipts in the last year, and receipts arriving on lanes with no sourcing rule.
Calendars whose configured receiving days disagree with the days on which goods have actually been received.
The ranking is the part that matters. Every defect gets an exposure figure, which can be as simple as the annual value of demand flowing through the affected item, or better, an estimate of the value at risk in the window the error affects. The list is sorted by that and worked from the top. Two thousand open defects sorted by exposure is a manageable object. The same two thousand sorted by item code is why nobody opened the last one.
Where the system allows it, show the relevant defect next to the decision it affects, so a planner reading a recommendation can see that the item's lead time has not been confirmed in three years. That changes how much they trust the number and it routes the fix to the person who noticed.
Measure the defect position rather than the activity
Governance programmes report activity, which is why they get cancelled. Records cleansed, fields reviewed, workshops held. None of it says whether the data is better.
Four measures do.
Open defects weighted by exposure. The headline number. Weighting matters because an unweighted count rewards closing the easy ones, and the easy ones are easy because they do not matter.
Defect age by owning role. This is the measure that produces movement, because it names a function rather than a total. A role with a rising age profile is a role that has not been given the capacity or the reason to fix its data.
Defects introduced per hundred new items. The only measure that evaluates the gate. Everything else measures the cleanup.
Re-open rate. Defects that were closed and reappeared. A high rate means the fix is being applied to the value rather than to whatever produced it, which is the single most common way a governance effort runs for two years and ends where it started.
Where this stops
Governance fails when the people who own the data do not experience the consequence of it being wrong, and no amount of tooling closes that gap.
The lead time example is the clearest case. A buyer is measured on price, savings and supplier coverage. The lead time they load into the system is whatever the supplier quoted, and when the supplier's real performance drifts to twice that figure, nothing in the buyer's scorecard moves. The cost lands on planning as service failures and on finance as expedite freight, both of them several steps away from the decision that caused them and both of them attributed to planning when they surface.
Partial fixes exist and are worth doing. Put measured lead time reliability on the supplier scorecard the buyer already reviews, so the field appears in a conversation they are already having. Report the cost of a defect in the owning function's own currency rather than in planning's. Publish the defects-introduced measure by originating team, which works better than most interventions because it is specific and slightly embarrassing.
None of that is a substitute for the underlying design question, which is whether the person who can prevent the error has any reason to. That is an organisational design problem and it usually needs someone senior enough to change what a function is measured on. A better ranked list handed to people with no incentive to work it produces a very well organised backlog.
There is a second limit worth naming. Some fields have no single owner because the business genuinely has not decided the answer, and a disagreement about what an item's status should be is a commercial decision wearing a data costume. Those show up as fields that keep getting changed back and forth, and the fix is a decision rather than a validation rule.
Take lead time on its own, compare the stored parameter against the last six months of actual receipts for your top hundred items by value at risk, and count how many sit outside a band you would defend. That count is the opening position, and it is usually enough to get the ownership conversation started properly.