Master Data Management Basics

What counts as master data

Businesses handle several kinds of data. Transaction data records events: an order placed, a payment received. Reference data lists agreed values, such as country codes or order statuses. Master data describes the core entities those events involve, the things the business keeps coming back to: customers, products, suppliers, employees, locations, accounts.

Master data changes slowly compared with transactions, but it is used everywhere. An error in a product description or a supplier’s bank details is repeated in every order, invoice and report that touches it. That reach is the reason it deserves its own discipline.

Why duplicates arise

If master data were held in one place and used by everything, there would be little to write about. In practice it grows in several systems at once. The sales system, the billing system and the support desk each have their own customer table, created at different times for different purposes. Duplicates and conflicts appear for ordinary reasons:

• Each system has its own identifier, and none matches the others.
• Staff create a new record when a quick search does not find the existing one, perhaps because the name was spelled differently.
• A merger or acquisition brings in a second set of records for the same customers.
• Data is typed in by hand, with variations in spelling, abbreviations and address style.
• A person or company changes name or address, and only some systems are updated.
• Records are imported from spreadsheets or partners with no check against what already exists.

The result is that “how many customers do we have?” has several answers, a customer receives duplicate mailings, and a supplier is paid twice under slightly different names. These are the kind of data quality issues that master data work is meant to reduce.

What master data management does

Master data management, usually shortened to MDM, is the set of processes, rules and tools used to create and maintain one agreed version of each core entity. Its main activities are:

1. Identify the entities and their attributes. Decide which things count as master data and which fields describe them.
2. Match. Work out which records in different systems refer to the same real-world entity. Matching may use exact identifiers where they exist, and scoring rules or fuzzy comparison on names, addresses and dates where they do not.
3. Merge or link. Combine matched records into a shared record, sometimes called a golden record, or keep the originals and link them under a common identifier.
4. Set survivorship rules. When sources disagree, decide which value wins, for example “the billing address comes from the finance system, the email from the support system”.
5. Distribute. Make the shared record available to the systems and reports that need it.
6. Maintain. Handle new records, changes and corrections through an agreed workflow rather than ad hoc edits.

Common implementation styles

Approaches differ in how much they change existing systems:

• Registry style. The original records stay where they are. A central index links records that refer to the same entity. This is the least disruptive, though each system still holds its own data.
• Consolidation style. Records are copied into a central hub, cleaned and matched, then used mainly for reporting and analysis. Source systems are not necessarily updated.
• Coexistence style. The central record and the sources both change, and updates are synchronized between them.
• Centralized, or transactional, style. The central hub is where master records are created and edited, and other systems read from it. This gives the strongest consistency and requires the most change to processes and systems.

The choice usually depends on how many systems are involved, how willing teams are to change how they enter data, and how much disruption the organization can tolerate.

The human and process side

Technology matches and merges records, but people decide what the rules should be. Questions that tend to need human attention include who may create a new customer, what to do when two sales teams claim the same account, and who approves a change to a product’s classification. This is where data stewardship and clear definitions become essential, since without them the tool simply encodes disagreement.

A simple workflow often includes a request, a check for existing records, an approval step for sensitive fields such as bank details, and a record of who changed what. These steps can feel slow compared with creating a record directly, so the workflow should be as light as the risk allows.

Costs, risks and limits

MDM is not a quick fix. Matching rules are never perfect: too strict and duplicates survive, too loose and different entities get merged, which can be harder to undo than the original duplication. Existing data usually needs cleaning first, and that effort is easy to underestimate. Integrating many source systems takes time, and the master record becomes a dependency, so errors or outages affect every system that relies on it.

There is also a question of scale. A small business with a single main system and a few hundred customers may need only a careful process for searching before adding a record and a periodic duplicate check. Formal MDM tooling tends to pay off, if it does, where the same entities are spread across many systems and the cost of inconsistency is high. Whether that is the case should be judged from your own situation, not assumed.

Personal data and privacy

Customer and employee master data often contains personal information. Combining records from several systems into one profile can raise questions about purpose, access and how long data is kept. Involve privacy and legal professionals when designing a shared record, and apply access limits so people see only the fields they need.

A sensible starting point

Pick one entity, usually customers or products, where inconsistency causes visible pain. Count the systems that hold it, estimate how many duplicates exist with a basic check, agree who owns it, and define the minimum set of fields that make a record valid. Fixing one entity well gives you evidence about effort and benefit before committing to a wider programme.