Master data management that governs your shared data

The customer record in the business system has the right company registration number. In the CRM, the same company appears under a name nobody has corrected since the last reorganisation. In the customer portal, there is a contact person who left long ago.

Each record is correct in its own system. Together they give three different answers to the same question, and you only notice when a quote goes out with the wrong price or an invoice lands at an address that is no longer used.

What you need is a decision per piece of data: which system may change the value, who approves the change and when it may be passed on to the website, portal and analytics. This post is about how to make that decision, and when you can skip it.

Master data management is governance of shared data

Master data is the data that several systems have to use in the same way. Customers, products, suppliers and your own organisation belong here, because the business system, website, portal and analytics base their answers on it.

Master data management is the governance model around that data. It consists of shared definitions, a designated source per piece of data, a named owner per attribute and rules for when a change may be passed on. Think of a shared address book where every row has a responsible person and a rule for how it may be changed.

Many registers do not automatically create shared data. That explains why two departments can give different answers about the customer's name, which segment it belongs to and what price it has. Each department maintains its own copy, and the copies drift apart as the business changes.

This is how the spread looks when three systems describe the same customer.

MDM is a governance model first and a system choice second. The next question is which system owns which data, and that question has a concrete answer.

Three systems that often get mixed up in the same project

The business system is the source for item numbers, core data, pricing logic, stock and orders, because transactions depend on them. That applies whether you run Business Central, Monitor or Jeeves. Move the pricing logic somewhere else, and invoices and pick lists start living lives of their own.

PIM is where copy, attributes, images and datasheets are enriched once and then published to websites, portals and reseller channels. This is editorial work that no finance department should have to redo for every channel.

MDM covers the broader set of master data across systems and sets the rules the other two follow. That layer decides who may make changes, what counts as the approved version and how a change may spread.

The confusion arises because all three hold product data, but for different purposes. The same item can therefore have three descriptions without anyone having made a mistake. A common case: a product has its dimension registered in millimetres in the business system and in centimetres in the webshop. Neither value is wrong in itself. The combination becomes wrong as soon as a customer compares a drawing with the product page.

Walk through a change from start to finish. Finance changes the item number and pricing logic in the business system. The product team enriches copy, dimensions, images and datasheets in PIM and publishes only the approved version. The product website, customer portal or reseller portal reads item number and price from the business system and copy and images from PIM. If the dimension differs between channels, a source per attribute is missing, and the error sits in the organisation. We have written more about how the product information data model connects with item data from the business system.

A company does not need one system that owns everything. It needs a name per attribute group and a source the other systems accept.

Who owns each attribute decides whether the data holds up

The item number is changed in the business system by the finance or item manager. It is unique and only changes with approval. Technical properties such as dimensions, material and compatibility are changed in PIM by the product team, with the value taken from an approved source such as a drawing or datasheet. Commercial terms and pricing logic are owned by finance and sales in the business system and are published to the website only after approval there.

The customer's contact details are changed in the customer register or CRM by the account manager, and every change is logged with date and user. Legal and the data protection officer are responsible for personal data in the customer register, with storage and deletion according to contract and law. Published product images and documents are owned by the marketing department in PIM, and only the approved version with a validity date is published. Duplicate rules for customers sit in the MDM layer with the data steward, and a merge requires approval from the record's owner.

This split is an example that needs to be checked against your own organisation. What matters is that every attribute has a system, a role and a rule, and that together they cover what the channel actually shows.

Ownership per attribute is harder than ownership per system. A business system can be the source for one field while PIM is the source for another, and both appear in the same product view. Without a designated owner per field, every change becomes a negotiation, and whoever negotiates hardest wins.

The requirements grow as data sources multiply. Among Swedish companies in 2025, concern about breaches of data protection and privacy was the most common obstacle to AI use, at 49.1 percent, compared with 41.8 percent in 2024, according to Statistics Sweden's figures on IT use in enterprises. More sources raise the demands on provenance, change logs, access rules and responsibility between system owners.

The mechanics are easy to build and easy to forget. When pricing logic changes in one system and not in the others, the change log shows who changed what and when. After a faulty integration run, you need to be able to restore a record to its previous version without rerunning the whole import, and to stop or recall incorrect data before it reaches the channels. For Nordic groups with decentralised companies and several business systems, the problem usually shows up first as duplicate customers and products.

Start with a one-page ownership sheet per data domain. It lists the attributes, the system that may make changes, the role that approves them and the rule that applies. Then every decision about a value has a named person behind it. We have written about how customer data is kept together between the business system and CRM if you want to see how the chain usually works in practice.

Quality is built in at the source and follows the whole data lifecycle

A product has three different dimensions in the company's systems: 10 × 20 cm in the business system, 12 × 22 cm in the webshop and the old dimension still in a third system. The error arose when a change was made in one place but not passed on. Nobody had to do anything on purpose for the data to drift apart.

The result can be returns, incorrect quotes and support cases that could have been avoided. Data quality therefore takes more than a shared database. For every attribute, it needs to be clear where the value is created, who may change it and how the change is tracked through the systems.

Statistics Sweden describes data quality as a prerequisite for secure access to data. Statistics Sweden's operational plan for 2024 to 2026 shows that the agency works with data owners, shared standards and routines to ensure quality at the source.

The checks need to follow the data from entry to publishing and follow-up.

At entry, mandatory fields and format rules control how the dimension is given, for example always in millimetres. At change, the attribute's owner approves the new value. In the integration, field mapping and units are checked before the data is passed on. Before publishing, a check confirms that enough mandatory fields are filled in. At follow-up, you measure the share of records that have a named owner.

The threshold for publishing is something you agree on. Adapt it to the needs of the business and make sure you can trace who decided it. Cleaning up afterwards can find errors, but it does not stop them from coming back if ownership and checks are missing at the source.

Start with three measures: the share of records with a named owner, the share of mandatory fields that are filled in and the number of known duplicates. You can track them without a new platform, and they show whether the rules improve data quality over time.

When MDM is too heavy and what it requires of you

MDM work takes time from the business, an owner per data domain, decisions on definitions and a place where changes are approved. The requirement is organisational, and that is where most implementations lose momentum.

A smaller company with one business system, one website and a few hundred items usually manages without a separate MDM platform. Clear rules, a PIM flow for product data and a list of which system is the source for what are enough.

MDM becomes worthwhile when several business systems or companies share the same customer and product data, when several channels read the same data, when product data is reused across brands or when audits require traceable changes. Traceability then becomes cheaper than sorting out errors afterwards.

Be honest with yourselves about the cost. Ownership and processes take longer than the technology, and an implementation that only swaps tools rarely solves the problem. Governance needs a budget over time, and ongoing management is a cost line of its own long after go-live. Costs like these rarely show up in the project calculation. Glanser Care is a contracted responsibility at a fixed monthly cost that covers version tracking, compatibility through upgrades, maintenance of the integrations with the business system and bug fixing.

Does a lighter approach fit? If management cannot yet name an owner per domain, the answer is yes. Then start with one product group and one owner, and expand once the decisions hold.

AI turns weak product data into a business requirement

In 2025, 35 percent of the companies in Statistics Sweden's survey used AI, an increase of 10 percentage points from 2024. The same survey shows that 44.3 percent cited a lack of access to, or quality of, the data they needed as an obstacle, compared with 37.7 percent in 2024, according to Statistics Sweden's figures on artificial intelligence in Sweden.

For a company that wants to use AI in customer service or sales, the work starts by choosing one concrete flow and the attributes it needs. That can include product ID, units, compatibility, language, customer segment, price terms and which system is the source for each piece of data.

Start with one flow, for example spare parts search in the customer portal. A self-service assistant needs the right compatibility and units for the machine the customer has. A wrong link between a spare part and a model can give the customer an incorrect answer and lead to a return.

Write a data contract for the attributes in the flow: define each piece of data, state the unit and decide what has to be in place before the information is published. Name the source that supplies each attribute and who is responsible for its accuracy. Track discrepancies before publishing, so gaps are found before they reach the customer.

Once the data works in a limited flow, you can try more use cases, such as agent-based flows in commerce. Expand only when the data the flow needs can be traced back to a clear source.

Questions that show how the supplier handles ownership and changes

Ask the supplier to show which attributes in your master data are owned by which system, and who approves a change that affects several systems at once. An answer that only points to a tool shows that the governance has not been built yet.

Then ask how a change is traced from the source system to the channel, and whether an incorrect record can be restored without rerunning the whole import. The answer reveals whether the supplier thinks in terms of the lifecycle or only in terms of syncing.

The third question is about ongoing management: what is included when the business system or a channel is upgraded to a new version, and which checks run before publishing? This shows whether product ownership extends beyond go-live.

The questions work just as well with your own IT department as with an external party. Ask for the answers using a real example record, where you follow an item number from the business system to the product page. A supplier that can show the owner, the log and the restore in one example has built the governance. One that describes it in meeting-room phrases probably has not.

Start with one product group and one owner

If several systems share product data, start with a product group where an improvement clearly matters to the business. Decide who is responsible for each attribute and document the rules for changes. You can then test the way of working on a small scale before more product areas are connected.

A product website can be introduced one product family or market at a time. First, the attribute model for filtering and variants is defined. Then the data sources are connected and the catalogue is expanded step by step. PIM and the business system handle different parts of the product flow, following the split of responsibility above.

The Function Library has three levels. Standard has a fixed scope and a fixed price. Adapted starts from the same foundation with agreed changes, and Customer-unique is isolated so the rest can be upgraded without being affected.

Clear ownership per attribute makes it easier to find the cause when information differs between channels. Start by describing one concrete product record: which data it includes, who approves changes and where the information will be used. That gives you a practical basis for judging whether you need PIM and which functions can wait.

In a 72-hour analysis, you set aside two hours, and within 72 hours you get an inventory of functions and integrations, a functional specification, a prototype and a complete cost picture with a timeline, free of charge.