Start master data management with one shared business entity

Effective master data management creates a governed way to identify and maintain core business entities across systems. These entities can include customers, suppliers, products, and locations. The aim is a trusted shared view, with clear rules for where important values come from and how changes reach other applications.

A company can have several accurate records that still disagree because each system uses a different identity or definition. Simply copying them into a central database does not resolve that problem.

This article explains identity matching, trusted fields, stewardship, and distribution. It also compares operating models and sets out a pilot that starts with one entity and one business outcome.

What counts as master data?

Master data describes core entities that many workflows use. A supplier record can support purchasing, payment, compliance review, and reporting.

Transactions describe events involving those entities, such as an order or payment. Reference data defines controlled values such as status codes or categories. The boundaries can vary, so agree on the terms for your program.

IBM’s master data management overview explains the role of shared core data. Use that concept to identify where inconsistent entities create real business work.

For example, duplicate supplier identities can split spend analysis and complicate payment checks. That provides a concrete reason to improve the supplier view.

Choose a business problem before a platform

Start with an outcome such as consistent customer reporting, fewer duplicate suppliers, or reliable product information across sales channels.

Then identify the systems and decisions involved. A narrow first scope makes identity rules and ownership easier to validate.

Avoid beginning with a promise to master every domain at once. Customer, supplier, and product records can require different matching evidence, approval, and change processes.

Informatica’s MDM overview provides another vendor perspective on the discipline. Product capabilities can support the work, but the organization still needs its own definitions and decision rights.

Set a measurable first goal without inventing a target. Use the current process to establish the baseline, then agree on the improvement the business needs.

Define the entity and its boundaries

A customer can mean a person, a legal organization, a billing account, or a trading location. Those entities relate, but they are not interchangeable.

For example, one legal company may have several branches and billing accounts. Merging them all into one flat row can destroy distinctions that operations need.

Write down the entity model and relationships. Include which identifiers refer to which level.

Next, review the model with business users. They should recognize the differences and explain how their workflows use them.

A shared definition does not require every application to store identical records. It requires clear mappings so the organization understands what each record represents.

Create stable shared identities

Different applications often use different local keys. MDM can maintain a shared identity and the cross-references that connect those local records.

Keep those mappings traceable. If two records merge, staff need to know which source identities now belong to the shared entity.

Avoid using mutable fields as the only permanent key. Names, email addresses, and external references can change or repeat.

Also plan splits and corrections. A mistaken merge should have a controlled repair path that preserves useful history.

Identity design is not only a technical lookup problem. The business must decide what counts as the same entity under its operating rules.

Match records with confidence and review

Exact matching works when sources share reliable identifiers. Other cases may use several attributes to suggest likely matches.

For example, supplier name, address, and registration details may provide combined evidence. However, similar names can belong to different businesses, while one business can use several names.

Set thresholds and review routes according to the consequence of a false match. Automatic merging may be suitable for strong evidence, while uncertain cases need a steward.

Keep the evidence behind each suggestion. A reviewer should see the source values and rules that led the system to propose a match.

Also evaluate missed matches. A very conservative rule can avoid false merges while leaving many duplicates unresolved. The right balance depends on business risk and review capacity.

Choose trusted values field by field

A shared record can combine values from several sources. Survivorship rules determine which values become the trusted view.

Do not assume the latest update should always win. A recent low-quality import may be less authoritative than an older verified source.

Define authority at the field level where needed. Finance may own payment terms, while a product team owns a technical description.

Next, preserve source history and uncertainty. A value awaiting verification should not look identical to one a responsible owner confirmed.

Oxen’s data quality framework guide explains how rules and evidence support fitness for use. Apply those checks to the fields that the shared record publishes.

Give stewards a workable decision process

Master data governance assigns the authority to define, approve, and resolve data decisions. Stewardship turns those responsibilities into routine work.

A steward may review uncertain matches, approve important changes, or resolve conflicting source values. The system should provide context and a clear action path.

A queue with hundreds of unexplained differences can become another backlog nobody owns. Group work by cause, business impact, and required expertise.

Also define escalation. A steward may understand the data but lack authority to decide a disputed business relationship.

Oxen’s data governance software guide covers the wider ownership model. Keep MDM responsibilities connected to that model rather than assigning them solely to the integration team.

Compare central and distributed operating models

Some programs maintain an index or registry that links source records without moving every field into a central editing process. Others consolidate values into a shared view for analysis.

A more centralized model may let users create and approve master records through one system, then distribute them. A coexistence model can allow controlled updates in several places.

The right choice depends on authority, latency, and the existing applications. Central entry can improve control while requiring changes to established workflows.

Distributed editing can preserve local convenience while making conflict rules more important. The program needs to explain how changes reconcile.

Do not select the model solely because a vendor’s demo uses it. Compare the organizational changes and integration work alongside software features.

Distribute changes without creating loops

A trusted record helps only if consuming systems receive and use it correctly. Define which fields each destination accepts and which local values remain under local ownership.

Use stable identifiers and version information where appropriate. A destination needs to recognize whether an update is new, repeated, or older than its current state.

Also prevent update loops. A value published to a source system should not return as a fresh competing change merely because the connector sees it again.

Oxen’s data synchronization guide explains related questions about ownership, timing, and conflicts. Those decisions remain important even when an MDM platform supplies the connectors.

Test deletions, deactivations, and merges separately. They have different effects, and each destination may need a deliberate mapping.

Preserve history and lineage

Lineage explains where values came from and how rules transformed them. History explains how the shared entity changed over time.

Both help when a user asks why a report changed or why two source records now map to one entity.

Keep enough evidence to support the business use and approved retention requirements. This does not mean copying all source content into every audit record.

Next, version matching and survivorship rules. A later rule change can alter the shared view even when the source records remain the same.

For time-based reporting, decide whether users need the current master view or the view that applied at the transaction time. Those questions can produce different legitimate results.

A worked example: supplier identity

Imagine a business that uses separate purchasing and accounting systems. Each has supplier records with different local IDs.

The pilot defines a supplier entity and preserves branch relationships. It uses strong identifiers for automatic links and sends uncertain name-and-address cases for review.

Finance owns approved payment attributes, while purchasing owns procurement classifications. The shared view records the source and review state of each important value.

Changes flow to destinations under defined field rules. A mistaken match has a split process, and exceptions remain visible until resolution.

This illustrative example shows why MDM needs business authority as well as matching software. A central table alone would not decide which values to trust.

Run a pilot that includes correction

1. Select one entity and a bounded business use.
2. Profile the source records and identifiers.
3. Agree on matching and field-authority rules.
4. Build a shared view and a review queue.
5. Distribute changes to one destination.
6. Test a duplicate, conflict, mistaken merge, and later split.
7. Measure review effort and the effect on the business task.

Include normal updates after the initial load. A pilot that proves only first-time consolidation does not establish that the shared view will remain current.

Ask users to complete the intended task with the result. If they still need private spreadsheets to resolve identities, identify which evidence or workflow remains missing.

Evaluate tools against your data

Compare source connectivity, entity modeling, match explanations, review workflows, and change distribution. Use the same difficult examples for every vendor.

Also assess access control. Master records can combine sensitive fields from several systems, so the central view needs deliberate permissions.

Review export and exit options. Preserve identifiers, mappings, rule definitions, and useful history rather than only a flat list of current names.

Include data stewardship effort, integration maintenance, and rule review in the total cost. A platform can automate parts of the process while leaving important decisions with people.

Measure trust and operational usefulness

Track unresolved identity conflicts, review age, duplicate patterns, and destination update failures. Connect these measures to the chosen business outcome.

Do not treat the count of master records as the main success metric. Fewer records can reflect a mistaken merge just as easily as better deduplication.

Review samples and important exceptions over time. Confidence comes from explainable identities and useful values, not only a high automated match rate.

Finally, expand to another domain only when the first operating model is sustainable. Reuse lessons while respecting the different meaning and authority of the next entity type.

Do not confuse a trusted view with a final truth

A master record reflects approved rules and available evidence. Some fields can remain uncertain or disputed, especially when sources describe different business contexts.

Show that uncertainty rather than forcing every field into a confident value. A review state can be more honest and useful than an unsupported default.

Also give users a route to challenge a shared value with evidence. The program should improve its records over time without letting every consumer edit the authoritative view freely.

Start with one entity people need to trust

Good master data management connects shared identity with field authority, stewardship, and reliable distribution. Prove one useful domain, including corrections and ongoing updates. Then expand from an operating process the business can explain and maintain.