Basic Principles of Master Data Management

MDM gets hard when the systems in a company have grown into a network without a logical structure. The same customer or article sits in several places, one department keeps its copy up to date while another does not, and after a while nobody knows which version to believe. You cannot run purchasing, sales or reporting on information you do not trust, so the problem shows up in many places at once: an invoice goes to an old address, the stock does not match the article card, and two departments calculate the same KPI differently. This guide explains what MDM is, sets out four principles that make the daily work easier to see, describes the four pillars of an MDM program, and shows how MDM differs from PIM. For the acronym alone, see what MDM stands for.

What is master data management (MDM)?

Master data management (MDM) is the discipline, and the tooling, for agreeing an organization's critical records once and keeping them that way. It combines people, process and technology to create and maintain one authoritative source, often called a golden record, for data such as customers, products, suppliers and locations. In practice that means one agreed version of each customer, product or supplier that every other system can point to, instead of each system keeping and correcting its own. The goal is consistency, accuracy and access across systems.

In more formal terms, master data management is the set of processes for collecting, aggregating, matching, consolidating, quality-assuring, persisting and distributing that data, so the organization shares one understanding of it and integration can point every system at one reference. Each of those steps solves a different problem: matching finds the records that describe the same thing, consolidation decides which values survive, and distribution makes sure the result reaches the systems that need it. The mastered set can include reference data (the allowed values, such as country codes or units of measure) and the analytical data used for decisions.

An MDM tool supports the work. It removes duplicates, standardizes values in mass maintenance and blocks bad data with rules, so the result can stand as the authoritative source. It usually sits as a middleware layer between the systems that create data and the systems that use it. The tool does not decide what is correct, though. People agree the rules and the matching criteria, and the tool applies them consistently to every record that passes through.

ERP

Name

Zinc screws 20 * 30

Weight

0.012 kg

Supplier

SUP-1047

Spreadsheet

Name

zinc screw 20x30

Weight

12 g

Supplier

Supplier 1047

Supplier portal

Name

Screw, zinc, 20*30

Weight

12 gr

Supplier

1047

Match and merge

★Golden record Example

Name

Zinc screws 20 * 30One place of entry

Weight

12 gOne agreed unit

Supplier

Supplier 1047Linked record

Every system reads from it

• ERP & finance
• CRM & sales
• PIM & webshop
• WMS & logistics
• BI & reporting

Why records drift

MDM exists because critical records drift apart over time. Product, asset, customer and location data that matched on the day of a migration stop matching a year later, because each system is maintained by different people for different purposes. Companies that operate across borders run many applications, ERP, CRM and PDM among them, and after a few acquisitions often several of each. Data that crosses a department boundary is copied into the next system and then left behind, so a basic KPI such as revenue per customer turns into an argument about whose extract is current.

The usual root cause is segmentation. The same customer is served by several business units and product lines, and each one types the customer (the party in the customer role) and the account in again. A wholesaler that sells to the same installer through its webshop, its branch counter and a key-account team easily ends up with three customer records, each with a slightly different name, its own address and its own payment terms. The copies multiply from front office to back office, exactly where one authoritative source was needed.

Consistent master data pays off in decisions, in operations and in compliance. Reporting and analytics improve because they read one reliable source instead of a merged export that someone corrected by hand. Processes get simpler because they no longer have to reconcile copies, for example when an order is blocked because the customer's VAT number differs between the CRM and the ERP. Regulatory compliance rests on accurate, governed data, and an auditor will only accept that data when you can show where each value came from and who changed it.

What is master data (and what is not)?

Master data is the business objects that hold the agreed information shared across the organization. It gives context to transactions: who, what, when and how, plus the categories, groups and hierarchies you use to read those transactions. Customer, product, employee, material and supplier records are the usual contents, and it can include relatively static reference data. An order line on its own says little; it becomes meaningful once it links to a customer with a segment, a product with a category and a location with a region.

Organizations usually treat master data as non-transactional, but the boundary is fuzzy. In rare cases the information exists only inside orders and receipts, with no separate store, and the organization treats the transactional copy as master data. That can work as a stopgap. It does mean every correction has to be made in historic documents and every report has to dig the value out of transactions, which is why it should stay the exception.

Four other terms come up in the same conversations, and mixing them up makes the scope of an MDM program unclear. Each describes a different kind of data, with its own owners and its own volume:

• Transactional data describes business events such as orders, invoices and shipments. It is the largest volume in the enterprise, and it lives in CRM, ERP, SCM and similar systems.
• Log data records events or snapshots of a process state: sensor data, machine data, change-in-state data. Operations and preventive maintenance depend on it.
• Metadata is data that describes other data, such as who created a record and when. Master data, reference data and log data all have metadata of their own.
• Big data, in Doug Laney's definition from Gartner (volume, variety and velocity), mixes log data, transactional data, reference data and master data. It is not a separate kind of business object.

The distinction matters when you scope the work. Master data is the part you govern record by record, because one wrong supplier bank account or one wrong article weight causes damage in every process that uses it. Transactional and log data are governed mainly through the processes that create them, and metadata is what makes all of it traceable.

Product master data

Product master data, also called item master data or, in an ERP, the material master, is the product domain of MDM. It holds what every system needs to buy, store, sell and ship an item: identifiers, descriptions, units, dimensions, weights, classifications and supplier links.

What counts as master depends on the process. A logistics process runs on volume, dimensions and weight: the dimensions decide how much storage space an article takes, and the weight decides how it is packed and handled. You capture those properties once per article, often together with color, barcode and packaging, and make them available in the WMS or ERP, so nobody measures the same carton again at goods receipt, in the warehouse and at dispatch. Accounting needs different objects, such as cost prices and ledger accounts, and a clinical process needs others again. Name the critical fields for the process you run before you call a record "master."

The sellable version of the product is a different thing. Marketing copy, channel attributes, translations and images belong in a PIM, which reads the master record and enriches it. A typical split: the ERP holds the article number, the weight and the purchase unit, while the PIM holds the product name for the webshop, the selling points, the translations and the link to the main image. ERP migrations are often the moment product master data gets cleaned; this piece on S/4HANA programs explains why that work should not stop at the ERP.

The four principles of master data management

The pillars later in this guide describe a full program. The four principles below are smaller and more practical: they are what a data manager or a key user checks every week. They hold whichever system keeps the master record, whether that is an ERP, a dedicated MDM hub or, for the product domain, a PIM.

Principle 1: Clear origin

The same data field often has to exist in several places in the information network at once. An article's weight may sit in the ERP, the WMS, the webshop and a carrier's shipping system. When it changes in one place, the others have to follow, or they drift apart and each system starts to give a different answer.

Keep the number of copies as small as you can. You cannot always delete a field, because applications read a value from a fixed location and most fields exist for one application only, so a copy is sometimes the price of keeping that application running. What you can do is make every copy visible and give it a known source.

Good MDM starts by drawing that map: which systems and files hold which fields. Then you set the routing, meaning which field in which system or file is filled first and which fields follow from it. Preferably the routing runs on its own through an integration, so nobody copies values by hand. Check whether the central system can hold the data the other applications use, so maintenance happens in one place. If that is hard, mark the fields that came from the first file when they show up in the next application, so users know not to edit them there. Gray areas on the map usually mean the data arrived from another system, and those are the places to look at first. This is the architecture principle behind MDM: one place of entry per field, with every other system either reading from it or clearly marked as holding a copy.

Once the routing is set, name who fills the fields. That is usually a key user who knows how the fields in their domain behave: a purchasing key user knows which supplier fields must be filled before an order can go out, and a logistics key user knows what goes wrong when a pallet height is missing. Excel is a practical aid for this check. An export of the key fields and the fields that depend on them quickly shows which records are incomplete and which values look wrong.

Principle 2: Clarity

Descriptions and codes have to be consistent. A search for a word only works if the word is always written the same way: "Zinc screws 20 * 30", not also "iron screw 40". The same goes for codes and units. If one buyer enters a length in millimeters and another in centimeters, or one writes "galv." and another "galvanized", filters and reports split one group of products into several, and a customer searching the webshop finds only part of the range.

Integrations and migrations are where this breaks, because two sets of naming conventions meet and nobody is assigned to merge them. Put it back in order straight away, while the people who know both conventions are still involved. Every month the mix stays in place adds new records in both styles, and the cleanup grows with it. A short naming guide per product group, with the agreed abbreviations and units, prevents most of the problem.

Principle 3: Completeness

Every field that should be filled, is filled. That sounds obvious, but in most article files the gaps stay invisible until something goes wrong: an order cannot ship because the weight is empty, or a product is missing from a webshop filter because one attribute was never entered. Which fields are required depends on the record type and the process, so define completeness per product group or customer type. A single list of required fields for the whole file is either too strict for simple items or too loose for complex ones. Then make it obvious, and quick to see, where data still needs to be added or corrected, for example with a completeness score per record or a weekly exception list for the key user responsible.

Principle 4: Regular maintenance

Master data goes stale. Suppliers change their packaging, customers move, articles are replaced by successors, and a record that was correct last year quietly becomes wrong. That is why maintenance needs a fixed rhythm instead of a cleanup project every few years. Set up a workgroup that does maintenance every week, led by a logistics manager or a financial manager, because those are the people who feel the consequences of bad data first. The data manager receives or issues the work through that group, which keeps priorities clear and stops the data team from fixing records nobody asked about.

The four pillars of an MDM strategy

The principles describe the daily work. An MDM strategy, the program that keeps them in place, rests on four pillars: data governance, data quality management, data integration and master data lifecycle management. Each pillar takes more time and people than teams expect, so assess your current systems and data before you commit. That assessment also shows where to start, because most organizations are much further along on one pillar than on the others.

Pillar 1: Data governance

Governance is the structure for overseeing data management: who owns which data, which rules apply, and how compliance is kept. It matters most with several data domains and complex regulation, and organizations often overestimate their readiness for it.

Governance starts with ownership. Appoint data stewards from the business units rather than from IT alone, because they know the nuances of their own domain: marketing might own the accuracy of customer data, finance the integrity of transactional data and purchasing the supplier records. Stewards who meet regularly to discuss what audits found turn findings into corrections. A steward who is named but never takes part has little effect.

Ownership needs written policies and standards to work against. Document how data is collected, stored, accessed and shared, set data quality metrics so you can check whether the policies are followed, and align access controls with your security protocols. The people who may change a supplier's bank details, for example, should be a small, known group.

Compliance is the third part. Know how regulations such as GDPR or CCPA affect the way you handle master data, for example how long you may keep the record of a customer who has left, and audit regularly against checklists for your industry. Build compliance into the framework from day one, because adding it later means revisiting every process you have already set up.

More on why this matters in top 5 reasons for data governance.

Pillar 2: Data quality management

Data quality management keeps master data accurate, consistent and reliable across domains. Organizations often underestimate the time and expertise that validation and cleansing take.

The daily work is validation and cleansing: automated profiling to find patterns and outliers, deduplication, and enrichment of incomplete records. An e-commerce company can check incoming customer data against existing records to catch duplicates and incomplete entries before a second account is created. Built-in validation stops bad entries before they reach the database, which costs far less than finding them in a report months later. AI is increasingly used for pattern recognition and anomaly detection, for example to flag an article weight that is far out of line with similar articles.

To know whether quality improves, you need metrics. Accuracy is the share of correct entries compared to a trusted source. Completeness is the share of required fields that are filled. Consistency is how far data matches across systems. Review the metrics on a schedule, because the business changes: a field that was optional last year may be required this year by a new marketplace or a new regulation.

Quality also needs a way back. Feedback loops let end users report discrepancies into the system, so a sales rep who sees a wrong address or a warehouse employee who measures a different carton size can flag it where the steward will see it. New tools alone do not fix unclear processes or missing training, so plan time for both.

See also what data quality is.

Pillar 3: Data integration

Integration gives one view of the data across systems. It gets complex when legacy platforms are involved, and underestimating it leads to longer timelines and budget overruns.

Most programs start with consolidation. ETL (extract, transform, load) processes bring separate sources together, for example sales data from several point-of-sale systems into one central database, and this is usually where the duplicates and conflicting values first become visible. Batch consolidation is not enough when processes depend on current data. Tools such as Apache Kafka or MuleSoft keep platforms in step in real time, so a transaction shows up in the CRM straight away and a changed customer address reaches the ERP before the next invoice goes out.

Legacy systems are the hardest part. Outdated technology and differing data formats need proper middleware and a data mapping plan that states which field in the old system corresponds to which field in the new one, and how values are converted on the way. Without them, integrations stay incomplete and the master data loses its integrity, because some systems keep receiving old or partial values.

Automated tools still need human oversight, and integration needs clear communication between IT and the business. IT can build the connection, but only the business can say which of two conflicting values is correct.

Pillar 4: Master data lifecycle management

Master data moves through creation, maintenance and retirement. A financial institution creates a customer profile at account opening, updates it with transaction history, and archives or deletes the profiles of inactive customers. When a stage is skipped, the dataset fills up with records that are outdated or wrong: profiles of customers who left long ago, or articles that are no longer sold but still appear in searches and reports.

Metadata records each record's origin, structure and usage, so you can track how it changes; teams that leave it out of their MDM architecture lose that visibility. Validate at every stage, not only at creation. A retailer can review its product information every quarter to find outdated details, such as a reference to a successor that has itself been discontinued, or a packaging change the supplier never reported.

How to start an MDM program

A one-off cleanse makes the data look good for a few months, after which the old habits bring the problems back. MDM works as an ongoing commitment, with a sponsor in top management who can settle disputes between departments, information stewards in IT or the CDO office who look after the systems and rules, and data stewards in the business who own the content. The steps below give a practical order for starting.

1. Map where each field originates

   Draw the systems and files that hold your critical records, and mark which one fills each field first. Include the spreadsheets and local databases, because they often hold the fields nobody else maintains.

2. Name owners and stewards

   Appoint the sponsor and the stewards, and name the key user who fills each field. Make sure each of them has time set aside for the role.

3. Set standards and quality metrics

   Agree descriptions, codes and required fields, then measure accuracy, completeness and consistency, so you have a baseline to measure progress against.

4. Start with new sources and applications

   You do not have to repair every old system first. Apply MDM to new sources and applications, then extend it to the records you already hold.

5. Maintain and audit

   Maintain every week, and audit regularly for completeness, accuracy, relevance and timeliness.

The tool comes after this groundwork. How to choose the right MDM solution covers selection from business requirements.

PIM vs MDM

Many people use PIM and MDM as names for the same system, partly because vendors in both categories handle product data. They overlap on the product, but they do a different job. MDM keeps the organization's critical records consistent on the inside, across domains such as customer, supplier and product. PIM gets product information out to customers, in the same form on every channel.

MDM, PIM, ERP and DAM: what each system owns

System	What it owns	Who works in it	The question it answers
MDMMaster data managementYou are here	Golden records across domains: customers, suppliers, locations and products, matched and governed.	Data governance, data stewards and IT.	Which version of this record is the true one, in every system?
PIMProduct information managementPIM guide	Sellable product content: attributes, descriptions, asset links, translations and channel versions.	E-commerce, marketing, category and product content teams.	Is this product complete and ready to sell on this channel?
ERPEnterprise resource planningERP guide	Transactions and operations: orders, stock, purchasing, pricing and finance.	Finance, supply chain, purchasing and sales operations.	What did we buy, make, sell, ship and invoice?
DAMDigital asset managementDAM guide	Files and media: images, video, documents, renditions and usage rights.	Brand, creative and marketing teams.	Where is the approved file, and where may we use it?

What MDM does

MDM covers the critical records of an organization across domains: customer, product, supplier, employee, location and financial data. Its users are internal: IT, data-governance teams, and business units that need one operational picture. Much of the value is in the links between kinds of data. Join customer and product data and you see behavior, preferences and purchasing patterns, instead of two lists that contradict each other. MDM spends its effort on those links and on hierarchies, such as which subsidiaries belong to which parent company.

What PIM does

Product information management stays on the product domain, and it faces outward. The job is to communicate product information to the customer consistently on every channel: the webshop, marketplaces such as Amazon or eBay, and print. The users are marketing, sales and commerce teams.

For marketing that includes photos and video, often from a DAM (digital asset management) beside the PIM. Variants are a core case: in fashion, one product (one description, one price) is sold in several colors and sizes. Relations are the other: alternatives, accessories and replacement parts. A PIM can also generate category templates that follow industry classifications held by a central authority such as GS1, so a product is delivered in the structure a retailer or data pool expects.

The differences that matter

The two systems differ on more points than the direction they face. The list below works as a checklist when a vendor or a colleague treats them as the same thing:

• Scope. MDM covers master data across domains: customer, supplier, product, employee, location, financial. PIM covers product information: attributes, descriptions, specifications, images, prices.
• Direction. MDM looks at internal sources and how they relate. PIM looks at external channels and catalogs.
• Goal. MDM keeps one source of truth for the organization's critical records. PIM keeps one reliable version of the product for the customer.
• Data model. MDM usually has a stricter model, built for consistency across entities. PIM usually has a flexible entity-attribute-value (EAV) model, built for many product types and changing attributes.
• Governance. MDM brings quality management, standards, stewardship and policy across the organization. PIM brings governance features that serve product attributes and distribution.
• Users. MDM: IT, data-governance teams, business units. PIM: marketing, sales, e-commerce.
• Time to go live. MDM often takes longer, because of cleansing and governance work. PIM is usually shorter, depending on catalog size and integrations.

The data model is a real trade-off. EAV lets a PIM handle a wide range of product types whose attributes change often, which suits e-commerce with diverse catalogs: a retailer that adds a product category with its own attributes can usually do that by configuration. MDM's stricter model limits that flexibility, and the same change may need a data-model change and a test cycle, but in return it protects data integrity across entities.

Which one you need

The simplest test is to look at the problem you are trying to solve. If internal records disagree, so that finance, purchasing and sales each work with a different version of the customer or the supplier, that is an MDM problem. If the product story on the channels is incomplete, inconsistent or slow to update, that is a PIM problem. Many companies have both problems and therefore need both systems. They meet on the product domain, where the MDM or the ERP holds the operational product record and the PIM builds the sellable version on top of it, but that shared domain does not make one a substitute for the other.

A common misconception is that a PIM alone covers all data management needs. A PIM covers product content well, but it does not replace MDM for customer, supplier or regulatory master data, and leaving that gap open fragments data across departments. The reverse also happens: MDM alone does not solve every data problem, and integrating it with existing systems is more complex than teams expect.

Company size and industry shift the answer. Small businesses usually start with PIM, because it goes live quickly and handles flexible product data: a small online retailer can load a seasonal collection and send it to its webshop and marketplaces in a short time. That covers the immediate need, but PIM does not cover long-term governance of customer and supplier data, which becomes an issue as the business grows.

Medium-sized enterprises under regulatory pressure often need MDM, for example a manufacturer that has to keep product specifications in sync with supplier details while meeting industry regulations. Large enterprises with diverse product lines usually need both. A global electronics manufacturer launching a smartphone keeps the specifications, the marketing material and the pricing per market in the PIM, and the customer profiles and supplier contracts in MDM. Regulated industries such as pharmaceuticals and finance tend to put MDM first, while retail and e-commerce more often start with PIM, because their first pressure comes from the sales channels.

Running both takes planning. Data synchronization, governance policies and user training are where projects stall, and without a plan you create new silos between the two systems. PIM usually has the lower initial cost and goes live sooner. MDM carries licensing, integration and maintenance costs that teams often leave out of the total cost of ownership, so put both on the same multi-year view before you compare them.

For the boundary with the ERP, see where ERP stops and PIM starts.

Keep it simple

Do not make master data management more complicated than the file requires. R.A. Jonker, F.T. Kooistra, D. Cepariu, J. van Etten and S. Swartjes set out the main MDM do's and don'ts in Compact.

Most master data problems do not need a large program before they start to improve. They need someone who owns the file and a fixed moment each week to work on it. The four principles are the working set: a straightforward file in which the origin of every field is known, unambiguous text and codes you can search, no empty fields left waiting, and weekly maintenance with the functional specialists who know the fields. Add tooling and a formal program when the scale of the data calls for it, and keep both as simple as the data allows.

Where to go from here

Both tools are free and independent of any vendor.

Not sure you need a PIM yet?

A short check that shows whether a dedicated PIM helps your catalog, or whether spreadsheets and ERP still do the job.

Check if a PIM fits

Ready to compare vendors?

Answer questions about your scale, sector and must-haves and get a ranked shortlist.

Build my vendor shortlist