Master Data Management (MDM) comprises a set of processes, governance, policies, standards and tools that consistently defines and manages the master data (i.e. non-transactional data entities) of an organization (which may include reference data).

An MDM tool can be used to support Master Data Management by removing duplicates, standardizing data (Mass Maintaining), incorporating rules to eliminate incorrect data from entering the system in order to create an authoritative source of master data. Master data are the products, accounts and parties for which the business transactions are completed. The root cause problem stems from business unit and product line segmentation, in which the same customer will be serviced by different product lines, with redundant data being entered about the customer (aka party in the role of customer) and account in order to process the transaction. The redundancy of party and account data is compounded in the front to back office life cycle, where the authoritative single source for the party, account and product data is needed but is often once again redundantly entered or augmented.

MDM has the objective of providing processes for collecting, aggregating, matching, consolidating, quality-assuring, persisting and distributing such data throughout an organization to ensure consistency and control in the ongoing maintenance and application use of this information.

Processes commonly seen in MDM solutions include source identification, data collection, data transformation, normalization, rule administration, error detection and correction, data consolidation, data storage, data distribution, data classification, taxonomy services, item master creation, schema mapping, product codification, data enrichment and data governance

The tools include data networks, file systems, a data warehouse, data marts, an operational data store, data mining, data analysis, data virtualization, data federation and data visualization. One of the newest tools, virtual master data management (also called virtual mdm) utilizes data virtualization and a persistent metadata server to implement a multi-level automated MDM hierarchy.

The selection of entities considered for MDM depends somewhat on the nature of an organization. In the common case of commercial enterprises, MDM may apply to such entities as customer (Customer Data Integration), product (Product Information Management), employee, and vendor. MDM processes identify the sources from which to collect descriptions of these entities. In the course of transformation and normalization, administrators adapt descriptions to conform to standard formats and data domains, making it possible to remove duplicate instances of any entity. Such processes generally result in an organizational MDM repository, from which all requests for a certain entity instance produce the same description, irrespective of the originating sources and the requesting destination.

Naturally, where there's a big IT problem, there's a host of vendors lining up with sophisticated technology that provide an "out-of-the-box solution." The rationale is that by plugging an MDM technology into existing applications (CRM, ERP, logistics, billing, etc.) you can build that one "true view" that will then feed consistent, accurate and reliable data back into these systems.

But, as early adopters are finding, MDM isn't just a technology effort. Although MDM technologies can have a dramatic effect on a company's performance, no software is going to magically solve your enterprise's data problems overnight. And at the root of this problem is poor-quality data—and how bad data is created.

Consider a recent report from The Data Warehousing Institute that found 83 percent of organizations suffer from bad data for reasons that have nothing to do with technology. Among the causes of poor-quality data were inaccurate reporting, internal disagreements over which data is appropriate and incorrect definitions rendering the data unusable.

Organizations must understand that improving their data—and building the foundation for MDM—requires them to address internal disagreements and broken processes. Staff must agree on exactly what constitutes a "customer" or a "partner," and how to resolve any disagreements across business units. Departments and divisions need to agree on hierarchies of customers and products and how to resolve duplicate records across sources. Rather than a technology-focused effort, the project becomes one of political strategy and consensus building.