Master data management: ownership, rules and quality

Management challenge

Counterparties, materials, responsibility centres, cost items, projects, contracts and equipment need owners plus rules for creation, validation and change.

When the problem becomes visible

• Duplicate master records
• Different codes for the same object
• Reports require manual cleaning
• Planning relies on incomplete standards

How to design the solution

This approach keeps the discussion focused on management control rather than only on system functions.

• Identify master objects
• Assign master-data owners
• Introduce quality rules
• Run recurring audit and cleansing

Common mistakes

The most common mistakes appear when a team trades architecture quality for launch speed.

These mistakes may be hidden during a demonstration but become visible in production operation.

• Treat master data as a technical task
• Leave an object's lifecycle undefined
• Stop controlling changes after go-live

Key takeaways

• Master data is a management asset.
• Every master object needs an owner.
• Quality rules are needed before implementation.
• AI and BI depend on reliable master data.

The core decision

For “Master data management: ownership, rules and quality”, define the outcome as a change in management practice. The central object is measures and thresholds; it needs an agreed source, decision owner and observable state after the action “align identifiers and master data”.

The first evidence is not a solution presentation but a reproducible example of “a dashboard does not lead to action”. It allows the team to set the process boundary, inspect baseline data and select the fact that will confirm completion.

What belongs in an MDM environment

MDM governs the lifecycle of master objects such as counterparties, materials, business units, projects, contracts, equipment and classifications. Each object needs an identifier, attributes, system of record, semantic owner and rules for creation, approval, duplicate merging and retirement.

MDM does not improve quality by itself. The operating environment includes change requests, validation, a decision log, publication of the golden record and monitoring of distribution to ERP, BI, APS and other dependent systems.

Objects under management

The subject model starts with two reference objects: data marts and semantic models and measures and thresholds. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “maintain lineage and versions”.

The primary boundary is data marts and semantic models. Its system of record, semantic owner, quality owner, refresh cycle and permitted transformations are documented. An error is also defined explicitly: who corrects it and how the change reaches dependent reports, plans or documents.

• Object 1: Master data and classifications. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: One measure has multiple values.
• Subject area 2: Sources and transformations. Verification basis: system of record, owner authority and the signal “users cannot see where a number came from”.
• Record 3. Object: Data marts and semantic models. Required details: identifier, lineage, quality rule and update event. Signal: Master data changes without an owner.

Integration contract

An integration design begins not with arrows between applications but with events and accountability. It defines who creates a record, where it becomes authoritative, which checks run before transfer, how duplicates are handled and which action is blocked when records disagree. The reference object here is measures and thresholds.

Every exchange has a business owner, technical owner and observable control point. API, messaging, file transfer or another technology is selected after frequency, volume, resilience and error behaviour are known. For the signal “a dashboard does not lead to action”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Boundary 5. Object: Errors, corrections and the quality log. Define the source, frequency, permitted transformations and response to “errors are corrected only manually”.
• Control record 4. Object: Measures and thresholds. Observable signal: A dashboard does not lead to action. Accountability: semantic owner and quality owner.
• Record 3. Object: Data marts and semantic models. Required details: identifier, lineage, quality rule and update event. Signal: Master data changes without an owner.

From signal to decision

The article addresses “Master data management: ownership, rules and quality”. The adjacent management issue is ownership, rules and quality. The two may share data or participants while differing in decision horizon, role authority and architecture boundary, so they are documented as separate entries in the decision map.

A signal–risk–action chain defines the subject-specific focus. Here the signal is “one measure has multiple values”, the material risk is “a data owner without authority”, and the testable action is “maintain lineage and versions”. This chain turns a broad term into a concrete decision.

• Decision 1: object — master data and classifications; signal — master data changes without an owner; action — align identifiers and master data.
• Decision 2: object — sources and transformations; signal — a dashboard does not lead to action; action — define checks and corrections.
• Decision 3: object — data marts and semantic models; signal — errors are corrected only manually; action — maintain lineage and versions.

Quality and correction rules

For measures and thresholds, the sequence begins with “align identifiers and master data”. The owner of the next step reviews its output; an incomplete result is returned with a specific issue concerning data, a rule, authority or an architecture dependency.

Maintain an assumptions log for measures and thresholds. Each entry states its basis, owner, review date and the event after which it must be confirmed, changed or closed.

• Stage gate 1 connects the action “identify key objects” with the result “master data and classifications”.
• 2. Action: assign systems of record; verifiable result: sources and transformations.
• Decision 3: align identifiers and master data. The basis for the next step is data marts and semantic models.
• Step 4. Define checks and corrections. Output: measures and thresholds.

Diagnosis before solution selection

Diagnosis examines a concrete episode involving data marts and semantic models. Its record states the time, participants, data used, decision made and consequence; recurrence is checked against a second sample.

Review the signal “one measure has multiple values” with the process owner. If its cause lies outside the selected boundary, record the dependency separately and do not expand scope without a new decision on timing, resources and acceptance.

• Event to test: one measure has multiple values. Evidence shows timing, frequency and consequence for master data and classifications.
• Indicator: Users cannot see where a number came from. Analysis needs an actual example and the resulting change in sources and transformations.
• Diagnostic signal 3: Master data changes without an owner. Its record contains an example and impact on data marts and semantic models.

Authority and escalation

Build the authority matrix around decisions concerning errors, corrections and the quality log. Assign the right to change a rule, duty to prepare data, authority to approve an exception and accountability for confirming the outcome separately.

Define the escalation path for “align identifiers and master data” concerning errors, corrections and the quality log in advance. The business owner is accountable for decision meaning, the data owner for evidence fitness, the architect for dependency integrity and the project manager for the agreed work sequence.

• For master data and classifications, the assigned role is Business owner; its control duty is to assign systems of record.
• Architect: authority is linked to sources and transformations, and participation is tied to “align identifiers and master data”.
• In the decision matrix, data owner connects data marts and semantic models with the action “define checks and corrections”.
• Project manager: decision area — measures and thresholds; control action — maintain lineage and versions.

End-to-end outcome test

The acceptance criterion for errors, corrections and the quality log includes a baseline sample, calculation rule, expected change and source of the actual outcome. The interpretation owner confirms that comparison conditions have not changed.

The end-to-end test starts with “one measure has multiple values”, passes through an authorised decision and “maintain lineage and versions”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Evidence item 1 describes master data and classifications, comparable test conditions and the person accountable for interpretation. Signal: Master data changes without an owner.
• Test 2 concerns sources and transformations. The method, interpretation owner and outcome source are documented. Signal: A dashboard does not lead to action.
• Control record 3: Data marts and semantic models; data version, calculation rule, expected change and actual outcome. Signal: Errors are corrected only manually.
• Criterion 4 uses measures and thresholds; the result is compared with the baseline using one method. Signal: One measure has multiple values.

Constraints and risk control

For the risk “a data owner without authority”, define an observable condition and control decision. The record also includes the owner, response time, execution evidence and rollback rule if the control fails.

An assumption concerning measures and thresholds remains valid only until its review event. If the source, scope or accountable role changes, update the decision boundary and repeat the affected test.

• Risk condition 1: One data mart without shared meaning. Response: Identify key objects. Testable evidence: Data marts and semantic models.
• The risk scenario “measuring quality without a correction process” is addressed through “assign systems of record” and confirmed using measures and thresholds.
• Controlled constraint: self-service without a metric catalogue. The owner performs “align identifiers and master data” and provides errors, corrections and the quality log.
• For the risk “treating an anomaly as a proven fact”, assign the action “define checks and corrections” and evidence “master data and classifications” in advance.

First working session

The first session examines one real case involving data marts and semantic models. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “a dashboard does not lead to action”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “align identifiers and master data”; assign an additional test or stop condition to the risk “measuring quality without a correction process”.

• Stage gate 1 connects the action “identify key objects” with the result “master data and classifications”.
• 2. Action: assign systems of record; verifiable result: sources and transformations.
• Criterion 4 uses measures and thresholds; the result is compared with the baseline using one method. Signal: One measure has multiple values.
• Criterion 5: Errors, corrections and the quality log; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: Users cannot see where a number came from.