In many companies, the management of master data is not on the agenda of senior management. Their focus is mostly on strategic or tactical challenges, and the identified issues around MDM seem to be operational.

Such operational issues  usually require deep knowledge of the topic, and top management does not (and should not) work on this level of detail; they very often do not understand the nuances of the problems nor the strategic impact (for example, that poorly managed master data will hinder the development of the business). This leads them to conclude that they do not need to give this topic any strategic or tactical attention, and they trust the middle and operational management to solve the issues.

On the other hand, business units and their managers focus daily on operational problems and how to fix them. They have learned to look into business processes and eliminate process waste. Problems need to be fixed immediately, and this includes master data issues. In many cases, these managers do not have a holistic view of these problems, because they are driven by the individual goals of their department or business unit.

A lot of MDM initiatives get started by IT departments. Sometimes they are following the external trends and realize that competitors have already or are just about to implement master data hubs. The benefits of such initiatives, like improved data quality and sophisticated applications, seem to be obvious. This is often the justification for adding the implementation of a master data hub to the IT strategy. However, when IT initiates the project and completes the tool selection process and technical implementation of one of the appropriated applications, often the business often does not understand it and won’t use it (or won’t use it correctly).

The involvement of all of these groups is essential to navigate the change management process and develop a successful MDM project.

Support is Needed

Support from top management is crucial for any kind of change initiative. This requires first that the related pain points or challenges become visible on top management’s tactical or strategic radar screen, which can be very difficult. They need to understand why they should invest some of their own limited time and part of the company’s budget in this type of project.

Business unit managers need to understand impact to their areas and how a resolution of the problem would make it easier for them to achieve the business unit goals.

This means that in order to get the support of top management and business unit managers, it is necessary to convey why it is important to run such an initiative.

Understanding Why is Important

The need for an MDM initiative must be described in clear language that top management and the business understands, but is it just about the question of how to translate issues with an operational impact into tactical or strategic challenges?

In the ‘70s, ‘80s  and beginning of the ‘90s, IT introduced tools without business involvement or collection of requirements or needs. Somebody within the organization then investigated the possibilities of how these tools would support the business, and they were then deployed to business users. Business was sometimes not even aware that they had a problem to solve, but any new tool presumably created benefits and therefore was rolled out and used.

Today, IT systems are integrated and support all business processes. Changes to this arrangement are complex and usually require the involvement of huge parts of the organization, which is a risk and an investment. You have to start the other way around. All organizational initiatives need to be prioritized appropriately, as resources and budget are limited, but even more importantly, each initiative needs to support the overall strategic goal of the company. The need for change in modern companies gets identified and accepted as part of the strategy process. You can find challenges and goals in the strategy documents of all companies, such as these examples:

  • Companies are aiming for a single source of data.
  • They would like to be the market leader.
  • They would like to consolidate purchased volumes to a fewer number of strategic suppliers.
  • They would like to grow through acquisitions.
  • They would like to increase efficiency.

Goals like these (and the related challenges) are easily understood by top management, as they address a business problem or goal and will, therefore, get the needed attention and focus. The reasons do not sound technical, but an MDM project could be an important step for each goal to be achieved. The objectives of these projects might look like:

  • Harmonizing the data across the company, supporting the one company goal.
  • Optimizing the new product introduction process or increasing data quality in order to become a market leader.
  • Enabling corporate reporting on purchased volumes per supplier and product type and increasing the quality of data supporting a supplier consolidation initiative.
  • Improving merger and acquisition processes by harmonizing customers, suppliers and products and enabling corporate reporting in order to harvest the savings faster than implementing the entire ERP platform.
  • Increasing process efficiency by eliminating process stops due to master data quality.

Being specific about why and linking it back to the overall strategy locks commitment from top management and ensures that middle and operational management begin executing on it, as it is now part of business unit or departmental goals.

Get the Organization Ready to Start Moving

After linking operational issues to strategic goals, it is important to ensure that the impact of doing nothing is apparent. The change management task is to communicate the issue, not the solution. This makes it clear that something needs to be done about the identified problem and begin the change journey. This has probably already been accomplished for the overall objective, and the task is to continue this story line and make everybody in relevant parts of the organization understand what happens if they do not harmonize the data across the organization.

What Needs to be Done

Finally, you can start analyzing the problem and thinking about possible resolutions. As it turns out, implementing a new tool is often only a minor part of these projects. Besides the problems of decentralized applications, malfunctioning or existing interfaces, and manual workflows for data maintenance, questions arise that may be even more important to address and answer as part of an MDM project include:

  • Why should we harmonize the information across the company? We are still operating locally and we have specific demands from the local market.
  • Who makes the decisions? Master data is supporting the daily operation, and if there is a demand, we would like to change the data. We can fix new problems related to this change afterward.
  • Who is maintaining the information today? As a salesperson, I need to be on top of my customer accounts, but maintaining the data is not part of my job description. If I remember, I will later tell someone in the organization to maintain the data.
  • Are prospects also customers? Or which suppliers are strategic suppliers?

It often turns out that the workload related to answering these types of questions and changing the related mindset (company culture) is usually higher than the workload of setting up a technical tool. Terms like data governance and questions about how to organize the data maintenance are now more important and need to be addressed even before requirements for a technical implementation can be collected. Implementing processes, rules and guidelines within these new organizationscan be done without any changes to the IT applications.

Get the Organization to Move

After discovering the problem and drilling down into the root causes, it is important to be able to give the organization a direction. The project should have a set of goals in order to be able to measure the project results, supported by a vision statement for communication purpose. The vision should guide the organization in the right direction throughout the project.

Getting the organization to move and keeping it moving is now the main task from a change management point of view. Recall the reasons to move and communicate where to move in order to best support this process.


Some MDM projects do begin in connection with an ERP implementation or upgrade project. The data quality of the existing system landscape may not be sufficient to support the new business processes. A huge effort is usually put into these types of projects, including data cleansing and data enrichment. But there are many examples of these type of projects where the data quality drops even after a successful implementation and reaches the same poor quality after the system is in use for a couple of months.

Intentions were good, and these projects had a good start and succeeded in getting the right attention in the beginning. The project objective was aiming for “one” company, but they failed in anchoring the change. These organizations have not learned that successful MDM is about continuously improving or keeping an accepted level of good quality. Ownership, responsibility and accountability need to continue even after the project’s lifetime, which requires an organization being responsible for these tasks and very often supported by a change in company culture. Master data is not something somebody else is fixing.

MDM projects are not just technical exercises. Most of the MDM initiatives driven like technical exercises failed, which resulted in organizations not harvesting any savings and, in the worst cases, the IT system landscape became even more complex with an additional tool.

MDM projects need to be driven through business needs or pain points and have to support the overall company strategy. Most of the activities related to these projects will be performed within business, like discussions about definition of customers or harmonization of products across the company. The MDM project (and later on the maintenance organization) must be anchored in the business, ideally on the CxO level.

MDM projects are change projects and, like any other change initiative, require skills like managing resistance, organizational design and process design. Anchoring the change and harvest business benefits is crucial and requires specific management skills. It is therefore recommended that these projects follow change management steps, starting with creating an awareness for the need of change  or unfreezing an organization through a change management model.

In many cases, people working on these types of projects need to be able to work on the strategic and also the operational level. Having good communication skills for both levels is essential. Solid business understanding from multiple business areas, and being able to work with both strategic goals and operational business processes combined with analytical skills in order to be able to investigate the impact of any change for either the strategy or the operation, are needed. People with these skills can often be found within the organization and very often have titles of controller, supply chain coordinator, etc.

Anchoring the change is maybe the most important but also the most difficult step of any change journey. The project focus needs to be on how to anchor the change right from the beginning, and the best way of doing this is getting top management attention and focus on the topic.