Master Data Management is About Organizational Change

Has your enterprise engaged in initiatives addressing business pains caused by conflicts in master data?

It’s likely that if you are part of a large to medium size enterprise, you have at least some experience with master data projects or programs. Many projects come to a staggering halt, or fail outright, because the project is not equipped to manage the organizational change needed.

Master data by its very nature spans the entire organization, and a program addressing master data is almost by definition disruptive to that organization. However, disruptive does not need to equal destructive. The change needs to be managed or you jeopardize the master data management effort.

In this article, I’ll outline the symptoms of not-quite-successful MDM projects, equip you with some arguments explaining why successful MDM needs to include change management techniques, and finally, provide you with a checklist to score your own MDM initiative’s ability to manage organizational change.

Getting Halfway There

I often encounter remnants of previous master data initiatives when I engage with customers. The customers tell similar stories of master data projects that, for example, promise to address the quality of customer data to help the business:

Reduce time spent consolidating sales report,
Reduce the time spent acquiring a new customer,
Improve or personalize customer support,
Reduce resources spent on fixing errors, and
Prepare for new CRM or ERP systems.

Yet at the end of the day, some benefits were realized and some were not. The entire enterprise now used the same reporting spread sheet and some technology was acquired (a master data repository or data quality tool); however, the speed of consolidation was largely unchanged, the resources spent consolidating were not likely to change much, IT and business changes made it necessary to reiterate the efforts and there was lingering doubt about whether the issues addressed were fixed. Sound familiar?

Master data evolves about as fast as business turnover. Customer master data gets updated as fast as your customers turnover, and the same goes for product master data, financial master data and so on. “Halfway projects” are characterized by the fact that the data itself was changed, but business’ management of the data was not. As the business continues to evolve, the master data degrades at the same pace.

An effective master data project needs to address the business processes that capture and update the master data, i.e., the customer, product, employee, spare parts, etc. This aspect requires changes to the daily execution of the business. If business execution is not altered it will be necessary to continuously cleanse the data, because the root causes of low quality master data will not be addressed.

The Root Cause

Consider an organization with customer data strewn across more than 20 IT systems in different formats with varying quality. The question to ask is: “Why is master data distributed like this?” You will soon discover the root causes that must be addressed in order to achieve long-term sustainability of your MDM efforts. Typically, the root cause falls into one or more of three broad categories (which I will cover individually later on):

Mergers and acquisitions,
IT governance,
Business process management.

If the enterprise does not consider M&A, IT governance and BPM, there will soon be even more systems with distributed customer master data, regardless of any MDM effort.
To avoid repeating a data cleansing effort indefinitely, it is necessary to provide a solution enabling the organization to not only fix bad data but also continuously improve how data is managed as the organization evolves. This is a tall order.

However it can be, and has been, done. In order to create such a momentous change in an enterprise, several aspects of MDM must be carefully planned, executed, measured and evaluated.
Mission perspective: Business goals and the desired end state for MDM must be aligned.

Policy perspective: The ground rules for master data in the enterprise must be defined.

Organization perspective: Capabilities, skills people and processes must be in place.

Architecture perspective: Business, technology and integration architecture must meet master data.

Technology perspective: The software and hardware facilitating the new capabilities must be fit for purpose.

It is impossible to delve into all of these in a single article, so I’ll focus why and how you must focus on the change aspects of an organization to make MDM a sustainable, continuous effort.

Master Data Management in M&A

There are numerous reasons for M&A activities that are often directly linked to master data:

To increase the customer base (customer master data),
To acquire a strategic product portfolio (product and supplier master data),
To acquire production capabilities (product and supplier master data),
To enter a new market (customer and geographical reference master data), and
To leverage economics of scale (financial, product, supplier, customer master data).

By applying IT and master data governance principles before, during and after a merger, the negative effect of a merger on master data can be mitigated. As it happens, the action plan for M&A rarely involves IT or, more specifically, IT governance of master data. A strategic merger to acquire 100,000-plus new customers will benefit immensely from a plan for integrating newly acquired customer data. After all, even if your company has all your data under control, the other company might distribute its customer’s master data across numerous systems. After a merger, you want to be able to uniquely identify a customer across systems, target new unique value propositions at the right customers at the right time and focus on high-value customers.

Looking at data integration at such an early, vital point represents a major change in the mindset of most enterprises. This requires a change management focus from the very onset of your MDM initiative.