Who Owns Data Quality in Your ERP? Assign responsibility for rules, checks and corrections.
A data standard becomes useful when someone can apply it during ordinary work, recognize an exception, and get the exception resolved. Publishing a definition and naming a department does not establish that operating chain.
For every critical ERP data rule, assign an owner who can decide what the rule means and how it should change. Then connect that accountability to the people who create, approve, monitor, and correct the data. The result should be a small operating card that explains the rule, its business consequence, its checkpoints, and its exception route.
This approach starts with a practical question: if this value is wrong tomorrow, who will notice, who can decide the right answer, and who will repair the consequences? Where those answers are unclear, the rule is not yet fully operational.
Begin with a few data elements that materially affect decisions or transactions. Ask process owners which incorrect values can cause an order to be mishandled, a replenishment decision to be wrong, an approval to be bypassed, or a report to mislead its reader.
Follow the consequence beyond the original screen. An item attribute may influence procurement, receiving, planning, and reporting. A local change can therefore require more than a local correction. The accountable owner needs enough authority to coordinate the affected uses, even if several teams maintain the underlying records.
Distinguish criticality from visibility. A frequently displayed description may matter less than a rarely edited conversion factor or status. Conversely, an apparently cosmetic name can be important if people use it to distinguish similar products. Base the decision on actual use, supported by representative examples.
Keep the initial rule set manageable. A catalog containing hundreds of unowned standards can create an illusion of coverage. A smaller group of operational rules, with clear evidence and functioning exception handling, gives the team a working model it can extend.
A useful rule identifies the data population, expected condition, point at which it must hold, evidence used to check it, and consequence of an exception. “Supplier data must be accurate” contains none of those boundaries.
A more useful statement might say that a purchasing lead time used by planning must have a documented definition, an approved value, an effective date, and a named owner before it becomes active. The precise definition must fit the organization's process, including how it treats calendars and internal receiving time.
Separate different quality questions. A value can be present, correctly formatted, and within an allowed range while still being wrong. A positive number in a lead-time field proves little if one team means dispatch time and another means time until stock can be used.
Likewise, consistency does not prove correctness. Two systems can hold the same mistaken value. Choose checks that match the business assertion: format validation for structure, approved reference evidence for meaning, and operational review where the value depends on changing real-world conditions.
Assign one accountable operating owner for the rule. This person approves its meaning, resolves material conflicts, accepts residual issues within their authority, and sponsors changes to the process. The owner need not perform every maintenance task.
Define the supporting responsibilities explicitly:
One person may hold several responsibilities when appropriate, but the assignment must respect the organization's control requirements and available capacity. Where separation is necessary, the workflow should reflect it. Where it is unnecessary, adding approval layers can create delay without improving the decision.
Document cover for absence and a route for cross-functional disagreement. A rule that waits for a single unavailable person can encourage informal workarounds. Deputies need the authority and context to act, not just a name in a governance chart.
Place validation at a point where the required evidence exists and the result can still influence the transaction. Blocking record creation too early may be inappropriate if information arrives later. Allowing unrestricted use before critical checks occur may expose the business to avoidable errors.
A staged record lifecycle can help: draft, under review, approved for specified uses, and inactive. These are illustrative business states; the actual application behavior must be designed and verified. Define which activities each state permits and who can move the record between states.
Choose among a hard stop, a warning, and a monitored exception based on the consequence and the ability to correct it. A hard stop protects the rule but may interrupt legitimate work if its evidence is not available. A warning preserves flexibility but needs a deliberate response and monitoring. A monitored exception needs an owner, an expiry or review point, and a clear operating limit.
Do not assume that a configured field check covers every entry route. Records may arrive through imports, integrations, bulk updates, or administrative tools. Technical owners should identify and test how the rule applies across the actual paths in use.
Imagine a manufacturer using purchasing lead times to plan replenishment. In this hypothetical example, buyers maintain a number called “lead time,” but its meaning varies. Some values represent supplier production time; others include transit and receiving. The field accepts all of them because each value is a valid positive number.
The procurement process owner and planning owner agree on the business definition for this use. They specify the start and end events, the calendar basis, and how internal receiving time is represented. The rule card records that definition and the evidence needed before a new value is activated.
A buyer receives revised information indicating that a component's lead time should change from five working days to twelve. These numbers are illustrative. The buyer attaches the supporting evidence and proposes an effective date. The approver checks that the information matches the agreed definition and considers orders already in progress.
The steward checks for records missing approval evidence and for values due for review. The planning owner separately reviews significant mismatches between the maintained assumption and observed operating behavior. This distinction matters: the first check tests adherence to the maintenance process, while the second can reveal that an approved value has become unsuitable.
An urgent purchase creates an exception. The buyer cannot obtain the required supporting evidence before the planning deadline. Rather than inventing a value to satisfy the field, the exception route assigns a decision-maker, identifies the affected planning use, and records a temporary assumption with a review date. The owner determines whether that assumption is acceptable for the specific consequence.
If the old value has already influenced replenishment proposals, correcting the master record is only part of closure. The planning owner identifies and reassesses the affected proposals. The exception remains open until the necessary downstream action is documented.
Every exception should identify the rule, affected record, detection time, business consequence, current owner, next action, evidence needed, and permitted interim use. Include enough context for the resolver to act without asking the creator to reconstruct the entire history.
Prioritize by consequence and timing. A record blocking today's shipment may need attention before a low-impact completeness issue. A quiet exception affecting a large population may deserve escalation even when no single user is waiting. The priority rules should be agreed with the process owners and reviewed when business conditions change.
Use clear closure states. “Value changed” is different from “downstream impact checked” or “exception accepted under a documented limit.” The queue should show what remains unresolved rather than allowing a technical correction to close an operating problem prematurely.
Avoid filling the queue with duplicate reports of the same cause. Where one rule defect affects many records, link them to a common issue while preserving the affected population. That supports coordinated repair and a defensible assessment of the remaining exposure.
A recurring error may come from unclear instructions, contradictory incentives, unavailable evidence, poor defaults, or a workflow that does not match how the work occurs. Individual mistakes can also happen. Investigate the pattern before selecting the response.
If users repeatedly bypass a rule to meet an operational deadline, ask whether the deadline and rule can both be satisfied with the information and staffing provided. More training may help when the process is misunderstood. It will not solve an approval queue that has no available decision-maker.
Track measures that reveal the operating condition: unresolved exceptions by consequence, time spent awaiting a decision, repeat errors after correction, and downstream events affected. Interpret counts against the population and changes in detection. A rise in reported exceptions can reflect improved visibility rather than deteriorating behavior.
The owner should review whether the rule still serves its purpose. Remove checks that create work without protecting a meaningful outcome, and strengthen those whose consequences are being underestimated. Changes need testing and communication across all affected uses, not merely an update to the policy document.
Choose a critical data element and write its operating card: business consequence, observable rule, population, creator, approver, steward, exception resolver, checkpoint, evidence, and escalation route. Walk one valid record and one exception through the proposed process with the people who will do the work.
Ask each person to show what they receive, what they decide, and what proves their part is complete. Include an absence, an urgent request, and a downstream correction. Where the chain stops, improve the operating design before expanding the rule catalog. Reliable data becomes more achievable when the organization makes correct handling possible and gives exceptions a practical route to resolution.