Master Data Management (MDM) or data referential stores, manages and distributes reference data (third parties, products, organisation structure, nomenclature, employees, etc.) within an organisation.
MDM centralises key data for a given scope in a single master location (commonly referred to as the point of truth) to facilitate sharing, guarantee quality, ensure secure access and govern data, etc.
Our need for information urbanisation has accelerated their expansion. In fact, you daily benefit from their usefulness without even knowing it. To better understand this strange concept, I will draw on examples and feedback from my work experience. Secondly, I will discuss the recurring difficulties that occur when you implement referential within a company and how to overcome these pitfalls.
Some examples of data managed through reference systems
We can distinguish between two main categories: Master Data (business data) and Reference Data, which is often named as Nomenclature or static table to indicate that updating is rare (ISO country code, currency code, etc.).
On an international scale: the name of a country varies from one language to another and sometimes over time. Using codes saves time and avoids errors, as a code consisting of letters and/or numbers is understandable and translatable worldwide. Airlines, travel agencies and charter companies all share the same unique codes that you see on your plane tickets: BOB, CDG, JFK, etc. For your information, the extended IATA database has recorded more than 750 changes in the last 12 months, some more significant than others depending on the data consumer and its use.
A simple scan of a GS1 GTIN barcode followed by a computer query gives you key information about a product: serial number, storage instructions, type of packaging (individual, batch, pack), country of origin, weight or volume, etc.
At the national level
In France, Google Maps cross-references national data (BAN), municipal data (BAL), IGN data and data from its valued users to pinpoint addresses on a map as accurately as possible. For each country, Google is obliged to draw this data from national repositories if they exist, are shared and are not difficult to find...
In France, the SIREN (company) and SIRET (establishment) identifiers, which must appear on administrative documents such as payslips and invoices, facilitate administrative control and traceability.
At the company level
Feedback 1: Within an industrial group operating in 40 countries, a multi-domain MDM linked projects, third parties (customers/suppliers/others), sites, ships, entities, etc. In addition, the third-party MDM was connected to an external data service*,* Duns&Bradstreet (a global business information database), adding strategic financial information*.*
Example of possible searches: List of ongoing projects with Petrobras or one of its subsidiaries (equity participation) as a customer. In addition, for each project identified, obtain the production sites, ships and legal entities involved.
Feedback 2: An NGO of doctors manages a catalogue based on a MDM. It contains 37,000 items used in the field, including medical and non-medical items in 12 main categories: nutrition, kits, medicines, transport, etc. Each item sheet has structured and formatted sections (description, usage advice, storage, etc.) to facilitate searches, updates, translations, etc. The online catalogue is consulted by other NGOs and records more than 3 million views annually.
Feedback 3: Freight forwarding company: List of all ship names and key characteristics, list of public holidays for every country in the world, list of IATA data, etc. Usage: thousands of views per month, dozens of API connections with business applications that guarantee a single, reliable data source that is available 24/7 and up to date.
Feedback 4: International pharmaceutical company. This company has moved away from dozens of Excel files scattered across all its departments (regulatory, supply chain, finance, purchasing, etc.) to adopt an extensive multi-domain MDM. Here is an example of an impact analysis made possible in two seconds: compiling a list of all suppliers based in Japan and their contribution (manufacturing, packaging, quality control, etc.) to the supply chain of each product affected by the marketing authorisation in question.
Feedback 5: City of Paris: in 2008, an auditors' report criticised the City for its inadequate management of its real estate assets. The architecture dept launched four parallel projects (asset inventory/MDM application/target processes/change to 1,200 employees) to address this shortcoming. Possible search: list in 2 seconds, by district, all the buildings with more than 2,000 m² of floor space, subject to a long-term lease or a public service delegation with public access building status and available inspection reports (PDF). One of the results: the Palais Brongniart operated by GL Events.
Implementation is generally considered when:
Data referentials address other challenges such as significantly reducing data search time and improving the urbanisation of the IS and flows. In fact, the number of flows consuming a referential is one of the most relevant ROI indicators to track.
Unsurprisingly, the first MDM most often installed in European and American companies is typically the customer referential (Customer MDM) or a product referential (Product MDM). These areas are considered a priority because they meet critical business needs, to obtain a single, reliable and shared view of customers and products. Next comes the third-party one (partners, suppliers) for purchasing optimisation.
These repositories can be initially installed in a segmented manner by domain (customers, products, suppliers) before evolving into so-called multi-domain MDM platforms offering a 360° view.
For a CRM to become a data referential, it must contain all the necessary customer reference data, not just data related to the commercial relationship, and be integrated into a robust data governance system with clear rules on data quality and access. CRM systems are often not designed to handle all this complexity, such as unification, standardisation, deduplication, etc., which sometimes requires a specific Master Data Management (MDM) tool
A PIM (Product Information Management) and an MDM (Master Data Management) have different objectives and scopes, although they are complementary.
PIM focuses exclusively on managing product information. It centralises, enriches and distributes all the data needed to market and promote products, including descriptions, technical specifications, images and marketing content. It is mainly used by marketing and sales teams to ensure the quality and consistency of product data across all sales channels. MDM, on the other hand, is a more comprehensive approach to managing reference data that is essential to the entire company.
| Attributes/Features | Present in PIM | Present in MDM |
|---|---|---|
| Product marketing descriptions |
Yes Product sheet enrichment |
No or limited |
| Multilingual content |
Yes Translation management |
Depending on the context |
| Images, videos, marketing materials |
Yes Often integration with DAM (Digital Asset Management) |
Rarely or via external integration |
| Adaptation to sales channels |
Yes Customisation according to channel (web, paper, marketplace) |
No |
| Product contextual information |
Yes Promotional data, seasonality, specific usage |
No |
| Product variant management |
Yes Variants, detailed options |
Often limited |
| Marketing collaboration |
Yes Collaborative enrichment workflows |
Depending on context |
| Variable data granularity |
Yes Highly detailed data depending on target |
Generally "cleaned" and homogeneous data |
| Export media for specific channels |
Yes Specific formats: catalogues, e-commerce |
No |
This distinction is not always so clear-cut, as in some contexts, data dedicated to PIMs is managed in MDM using an ergonomic input interface.
It would be risky to claim that in all contexts it is generally more efficient (results/cost + effort) to integrate MDM software such as TIBCO (EBX), Stibo, Semarchy or Informatica rather than developing an in-house tool. There are many criteria to consider:
These solutions offer a centralised, mature platform with robust data management, governance, enrichment and quality features that are often difficult to replicate in-house. Some publishers offer modules for data 'recovery', data deduplication, mass data integration simulation, configurable auditing, etc. Competition between MDM editors regularly leads to the emergence of new and innovative features.
Feedback 1: A European insurance broker decided to migrate its customer database hosted in Salesforce to an application developed and hosted in-house. The primary motivations were customer data sovereignty and in-house control of minor changes with few interfaces to other applications. In this context, this choice proved to be a wise one, and the benefits of the migration were real.
Feedback 2: A company specialising in water treatment and distribution commissioned a study to assess the costs, advantages and disadvantages of two alternatives: in-house development of a referential or integration of MDM packaged solution. Context: the IT department's master plan aimed to extend to four domains with workflows and automated integration of external sources—in short, an ambitious roadmap. Result after study and projection of the master plan: from the integration of the second domain into the MDM, the cumulative costs of development and MCO became significantly less advantageous through internal development than through MDM editor platform.
The implementation and maintenance of reference frameworks require the co-construction and monitoring of six essential building blocks (scope, processes, CRUD matrix, governance, etc.) aligned with the organisation's strategy. When these building blocks are properly aligned and solid, the benefits quickly become apparent, and the reference systems are perceived as a source and facilitator of urbanisation. If one of the six building blocks is wobbly, the consolidation efforts and risks of abandonment are significant.
The implementation of a referential data (MDM) shares many similarities with that of a multi-domain ERP:
It is not uncommon for the implementation of master data models to become a prerequisite for ERP integration.
Data governance requires new roles (data steward, data owner, etc.) and new bodies which, depending on the context, translate into either new jobs or additional tasks to be assigned to existing members of the organisation. Support (using the Prosci method, for example) for all stakeholders is essential. This must include a phase of diagnosing the organisation's level of maturity in relation to DATA, followed by an action plan for awareness-raising and training tailored to each stakeholder profile.
One of the most delicate phases involves jointly developing target processes that guarantee data enrichment without increasing the complexity, time, number of tasks, etc. of business processes. To ensure the fluidity and acceptance of the target processes, the method is just as important as the use of technical and ergonomic devices: auto-completion, post-entry verification and correction, intuitive UX, etc.
Another equally delicate phase is the retrieval and preparation of existing data sets to be injected into the MDM. In some contexts, this phase constitutes one dedicated project.
Feedback: A few years ago, I was involved in a scoping mission for a natural gas transmission network operator that was considering implementing a referential for their facilities' equipment (sectioning and pressure reduction stations). After an initial scope study and an assessment of the organisation's maturity level, I thought it would be a good idea to organise a meeting between the project team and the City of Paris team, which had successfully implemented a property asset MDM. This meeting, during which many questions were raised between insiders and beginners, enabled the project team to identify and fully assess the key elements to be considered at each phase of the project, in a similar public service context.
Let's look at two examples to understand the importance of event traceability and anticipating their inclusion from the scoping phase onwards.
Example 1: a sports holiday association
Context: An association offering courses to teenagers and young adults. Documents such as travel logs, commercial emails, invoices, etc. must be sent to course participants and/or their legal representatives before the course start date.
In the UK, the annual rate of change of address among 18-25 year olds is around 28-30%.
Points to consider: A third party may potentially have been, be or become a prospect, member, parent, guardian, volunteer or even an employee of the association.
The active periods (defined by a start date and end date) of volunteer, prospect, intern, minor/adult status must be recorded for targeting mailing and email campaigns or for statistical purposes.
Example 2: in the management of tangible assets (products, real estate, items) and intangible assets (patents, skills, etc.)
It is a good idea to record changes in the values of key data, the author and date of update, etc. This makes the generation of targeted reports and reconstruction of history possible. Examples: average time between renovations of premises, number of updates made in the meantime.
These two examples illustrate the importance of establishing a CRUD (create, read, update, delete) rights matrix, enhanced with archiving and historical access rights.
It is generally defined according to at least six criteria: completeness, precision, consistency, uniqueness, timeliness, and accuracy (true to reality).
Data quality can be measured in a MDM or in other sources used by your organisation (SharePoint, Excel, CRM, ERP, external databases, etc.).
Tools are available on the market, such as Talend, Soda, IBM Infosphere and Datagalaxy, to create dashboards, monitoring and alerts regarding data quality. MDM software packages on the market also provide reports that facilitate quality monitoring, usage by user profile, data consumption, etc.
This information should be shared as part of the implementation of a DATA policy. It demonstrates the value, importance and benefits that MDM continuously provides.
Generally, the usefulness of a MDM is proportional to the quality of the data and its ease of interaction: search, filtering, export, updating, customisation and interfacing i.e. interoperability. In large international organisations, a MDM can be used by dozens of other applications and thus constitutes a crucial foundation for scalable urbanisation. Moreover, the names and nicknames given to repositories are evocative: golden records, Point of Truth, SSOT: Single Source of Truth, Root, Moira, Argos.
If the quality is not up to scratch, users will turn to other sources and inevitably rebuild their own shadow reference systems. It is not uncommon to find 'key' data duplicated in a dozen or so scattered databases within an organisation.
Example 1: The National Payroll Operator
The major failure of the National Payroll Operator (ONP) project in 2014 illustrates the difficulties in implementing a unified data referential. Launched with great ambition, this project aimed to centralise the payroll of 2.7 million French civil servants via a single information system synchronised with eight different referentials. Among the main causes of this failure, the of Auditors highlights the ignorance or serious underestimation of technical risks, particularly the automated management of common referentials, which had not been anticipated before the contract was signed. In addition, fragmented governance between ministries and the ONP complicated the coordination necessary for the project's success, leading to the programme's abandonment after a significant financial loss: €346 million!
The scoping phase, which did not have any AI tools at its disposal, did not sufficiently measure and anticipate:
Example 2: A good MDM = An exhaustive inventory is sufficient!
One common pitfall is to put all your efforts into the inventory phase without worrying about maintaining its quality. Remember the inventories of supermarkets that closed their doors annually to take stock of all their products on the shelves and in their warehouses. However, if there is no formalised management of incoming and outgoing flows, an inventory remains accurate for only one day and ceases to be accurate the moment a customer, supplier or employee interacts with the products.
For example, a national operator undertook an exhaustive inventory of technical assets located throughout the country to create a single national reference point, spending months on costly referencing work. Unfortunately, strong convictions compensated for weak change management. As a result, the target update processes had not been tested before this meticulous and costly inventory was carried out. After the inventory, knowledgeable stakeholders rejected the application of the target processes and retained their habits and their own regional databases. Inevitably, the reliability and usefulness of the referential deteriorated day by day...
Find sources and additional information related to this article: