Skill Hub — DAMA / Data

Master Data Management Working Skill

Map master data domains, identify duplication and fragmentation, define golden record logic, and design replication governance.

What this skill is for

This skill helps you bring order to master data chaos. It provides a method to map which systems create, own, and consume master data; find duplication and fragmentation; decide what a "single version of the truth" means for each domain; and design governance that keeps master data consistent across the landscape. The output is a master data governance plan that a project or operations team can execute.

When to use this skill

Customer, vendor, material, or employee records exist in multiple systems with no clear source of truth.
Business processes fail because different systems show different values for the same master data object.
A merger or acquisition requires harmonizing two code sets, two customer bases, or two org structures.
Master data replication fails frequently and the failure pattern is not understood.
A new system is being introduced and needs to consume or contribute master data.
An MDG (Master Data Governance) implementation is being planned or reviewed.

Real work situations

Example 1: Customer fragmentation after acquisition

Company A acquires Company B. Both have customer databases. The integration team maps customers by name and address, but 30% are duplicates with slight variations. Sales uses the CRM. Finance uses SAP. Service uses a third portal. No system has the complete customer view. The skill produces a customer master data map, a deduplication strategy, a golden record definition, and a replication governance model.

Example 2: Material master divergence

Materials are created in PLM, enriched in SAP, and consumed in BW and EDI. Descriptions, units of measure, and classification differ across systems. Procurement orders the wrong unit because the EDI system shows "EA" while SAP shows "KG." The skill maps the material lifecycle, identifies the authoritative source for each attribute, and defines a synchronization rule.

Example 3: Business partner replication chaos

SAP Business Partners are replicated to CRM, a data warehouse, and an external tax system. Changes in SAP sometimes do not arrive. When they do, they overwrite manual corrections in CRM. No one knows which system wins. The skill produces a replication ownership matrix, a conflict resolution rule, and a monitoring checklist.

Example 4: Vendor master duplication

Procurement creates vendors in SAP. Finance maintains payment details. A separate supplier portal registers new vendors. The same supplier exists three times with different codes. Payment runs are split. Negotiation leverage is lost. The skill maps vendor creation channels, defines a deduplication rule, and designs a single entry point.

Inputs required

List of master data domains in scope: customer, vendor, material, employee, chart of accounts, etc.
System landscape showing which systems create, modify, and consume each domain.
Sample records from each system for the same domain (to find duplication and divergence).
Integration documentation: IDoc types, APIs, replication flows, and middleware.
Business process descriptions that depend on the master data.
Existing MDM or MDG setup documentation (if any).
Stakeholders: business owners, data stewards, integration architects, and application owners.

Questions to ask

Which system creates the master data record first, and who approves the creation?
For each attribute, which system is the authoritative source: creation system, enrichment system, or a dedicated MDM hub?
How do you know if two records are the same entity: exact match, fuzzy match, or manual review?
What happens when the same attribute is updated in two systems at the same time?
Which business process breaks when master data is inconsistent between systems?
Who is accountable for the quality of each master data domain?
How are master data changes monitored, and who is alerted when replication fails?

Working method

Define the master data domains. List the domains in scope. For each, identify the key entities (e.g., customer account, business partner, vendor) and the key attributes (e.g., name, tax number, classification).
Map the system landscape. For each domain, create a system map showing: creation systems, enrichment systems, consuming systems, and the integration paths between them.
Identify duplication. Compare sample records across systems. Use exact match on key fields (tax number, email, material number) and fuzzy match on names and addresses. Document duplication rate and patterns.
Identify fragmentation. For each entity, check whether all key attributes exist in one system or are spread across many. Document which system holds which attributes.
Define golden record logic. For each domain and attribute, decide: which system is the source of truth, how conflicts are resolved (last-write-wins, hub-wins, manual review), and how the golden record is composed from multiple sources.
Design replication governance. For each integration path, define: what data flows, in which direction, how often, what triggers it, who owns it, and how failures are handled.
Define deduplication rules. Specify matching criteria, survivorship rules (which value wins when sources conflict), and the approval workflow for merges.
Assign ownership. For each domain, name: business owner, data steward, technical owner, and integration owner. Confirm they accept the role.
Produce the master data governance plan. Combine domain maps, duplication analysis, golden record logic, replication governance, deduplication rules, and ownership into a single document.
Validate with a pilot. Test the golden record logic and replication governance on a small subset of data. Adjust before scaling.

Decision rules

If a master data attribute is created in one system and never changed elsewhere, that system is the source of truth for that attribute.
If an attribute is updated in multiple systems, designate a hub or a winning system; do not allow ambiguous conflict resolution.
If duplication rate exceeds 10%, prioritize deduplication before any new integration or migration.
If a system consumes master data but also modifies it, the consumption path must include write-back governance or the system must be reclassified as a contributor.
If replication failures are frequent, fix the monitoring and error handling before optimizing the data model.
If no one accepts ownership of a master data domain, do not proceed with tooling; resolve ownership first.
If a merger requires code harmonization, decide on the target code set before mapping; mapping without a target is wasted effort.

Deliverables

Master Data Domain Map — domains, systems, attributes, and ownership.
Duplication and Fragmentation Analysis — rates, patterns, and business impact.
Golden Record Definition — source of truth per attribute, conflict resolution, and composition logic.
Replication Governance Model — flows, triggers, frequencies, failure handling, and monitoring.
Master Data Governance Plan — combined document with priorities and actions.

Templates

Master Data Domain Map (compact)

| Domain | Entity | Creation System | Enrichment System | Consumers | Key Attributes | Source of Truth |
|--------|--------|-----------------|-------------------|-----------|----------------|-----------------|
| Customer | Business Partner | CRM | SAP MDG | S/4, BW, EDI | Name, Tax, Address, Status | MDG for core; CRM for sales attributes |
| Material | Material Master | PLM | SAP S/4 | BW, EDI, WMS | Description, UoM, Group, Price | S/4 for operational; PLM for technical |

Golden Record Attribute Logic

| Domain | Attribute | Source System | Conflict Rule | Fallback | Approval Needed |
|--------|-----------|---------------|---------------|----------|-----------------|
| Customer | TaxNumber1 | MDG | MDG always wins | None | No |
| Customer | CreditLimit | CRM | CRM wins if newer than MDG | MDG | Yes, if increase > 20% |
| Material | Description | PLM | PLM wins | S/4 | No |

Quality checklist

Every master data domain in scope has a named business owner and data steward.
Every key attribute has a defined source of truth and a conflict resolution rule.
Duplication rate has been measured and documented.
Replication paths are documented with direction, frequency, trigger, and owner.
Failure handling and monitoring are defined for every replication path.
Deduplication rules include matching criteria, survivorship logic, and approval workflow.
The governance plan has been validated with at least one pilot subset.

Common mistakes

Mistake: Buying an MDM tool before defining golden record logic. Consequence: The tool enforces an undefined model; conflicts are resolved arbitrarily; users lose trust.
Mistake: Treating all attributes as if they have the same source of truth. Consequence: Overwrites in one system destroy valuable enrichments made in another.
Mistake: Deduplicating without survivorship rules. Consequence: Merged records contain conflicting values; downstream systems break.
Mistake: Ignoring manual corrections in downstream systems. Consequence: Replication overwrites local knowledge; users disable the integration.
Mistake: Mapping codes during a merger without deciding the target standard. Consequence: Mapping tables grow indefinitely; reporting remains inconsistent.

Agent instructions

When using this skill, an AI agent must:

Start with domains, not tools. Ask the user to name the master data domains and systems before discussing MDM, MDG, or any software.
Map before judging. Produce a system landscape map and a duplication analysis before proposing golden record logic. Do not guess sources of truth.
Define attribute-level logic. The source of truth may differ per attribute. Do not assume one system owns the entire record.
Surface conflict scenarios. Ask: what happens when two systems update the same attribute? If the answer is unclear, flag it as a governance gap.
Produce artifacts, not advice. Output a Master Data Domain Map and a Golden Record Definition in the templates provided. Do not write a generic MDM strategy document.
Link to Atlas diagnostics. If replication failures are involved, link to SAP Business Partner Replication Diagnostics, SAP Customer Master Replication Diagnostics, or SAP CVI Synchronization Diagnostics.
Handle missing information. If system documentation or record samples are unavailable, produce a data collection checklist and ask the user to gather them.

Related skills

Data Governance — when MDM reveals ownership or rule gaps.
Data Quality Root Cause — when master data defects need tracing.
Data Lineage — when master data flows need tracing.
Reference Data Management — when code lists and status values are part of the master data scope.

Related Atlas pages

SAP Master Data Quality — diagnostic patterns for SAP master data.
SAP MDG Governance Patterns — governance structures for SAP MDG.
SAP Master Data Replication Patterns — replication models and failure modes.
SAP Master Data Duplicate Diagnostics — finding and resolving duplicates.

Verification status and limitations

This skill is a public working interpretation of master data management practice. It is not official DAMA-DMBOK or SAP MDG documentation. It has been applied in SAP-centric enterprise contexts but may need adaptation for cloud-native CRM, HR, or custom applications.

Limitations: This skill does not cover advanced probabilistic matching, entity resolution algorithms, or MDM platform selection. It focuses on governance, ownership, and replication logic suitable for project and operations contexts.