Master Data Management

A customer changes its address in the sales system, but the billing system still sends invoices to the old location, and neither team sees the mismatch. MDM sets rules for matching, correcting and sharing such core information.

IBM and Informatica describe MDM around consistent master records and governance, but both sell data products, so their approaches are examples rather than a mandate to buy a particular hub. Identify the important entities first, such as customers, products, suppliers, assets or sites, and do not attempt to harmonise everything at once.

Define a unique business meaning for each entity, because one customer may be an individual, a legal company or a billing account. Agree on key fields, quality rules and permitted values too, since names, addresses and identifiers have different reliability by source and different meanings of "active customer" can distort reports even when names match.

Matching finds records that may represent the same entity, but similar names are a clue, not conclusive proof. Merging two different people can cause privacy and service failures, so set thresholds and human review for uncertain matches.

A trusted or golden record combines selected attributes using clear survivorship rules, for example one source may be best for shipping address while another owns tax details, and recording provenance (where a value came from, when it changed and who approved it) helps resolve disputes later. Assign data owners to business decisions and stewards to operational checks, because technology alone cannot settle conflicting definitions.

Set rules for creating, changing and retiring records, since duplicate prevention starts at entry, not only with later cleanup, and use validation where it improves quality while allowing for real-world exceptions, because overly strict forms can make staff enter false values just to proceed. Decide which systems receive updates and how quickly, since batch feeds and real-time interfaces create different timing risks, and handle conflicts when two systems update the same record, because silent overwriting can erase a verified correction.

Protect access to personal and commercially sensitive fields, because a shared customer view is not permission for every employee to see it, and plan for deletions, retention and legal restrictions, since some data cannot simply be copied or erased everywhere under one blanket rule. MDM is distinct from a data warehouse, which may analyse history while MDM manages definitions and current trusted records.

A customer relationship platform may be a source of master data but is not automatically the master for every attribute, and a centralised hub is only one architecture, as federated or registry approaches may fit other organisations depending on control and workflow needs. Measure duplicate rate, completeness, disputed matches and time to correct errors, so a dashboard leads to clear action, and check downstream effects when a product code changes, since pricing, inventory and reports may all depend on it.

Start with a narrow, valuable use case such as invoice delivery or stock availability, clean old data before broad synchronisation because sending bad records faster only spreads the problem, and review integration failures and reconciliation, because a hub marked updated does not prove each connected system received the change. Budget for vendor and operating costs including stewardship labour, train frontline staff to report questionable records, and revisit the model when the business buys another company or adds new products; MDM succeeds when trustworthy records, ownership and correction paths make real business processes more reliable.