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.


Master Data Management and IT Governance

On the face of it, IT governance and master data governance would appear to go hand in hand. After all, master data is almost exclusively stored in IT systems and, more often than not, IT governance is performed locally in divisions and subdivisions of large enterprises. Many enterprises are still silo-oriented when it comes to IT acquisitions.

More often than not, it is up to each VP to specify IT requirements for division events, even though the value chain and supporting master data spans the divisions. Usually the responsibility is delegated to department managers who operate under budget and deadline constraints that leave little or no room to focus on the requirements of other divisions. The common denominator is often the IT department, which is left with the task of integrating the IT systems.

However, without an IT and data governance model backed and signed off by an executive more senior than a VP, it takes more than the average CIO to face down a business VP. It is not for the faint of heart to tell the VP of product development that you will not sanction his new ERP upgrade because the format of product master data definition must first be laid down with the VPs of inbound logistics and production (and his ERP system). In order for the CIO to take that position, he needs to be backed by enterprise data governance policies.

Again, this requires a change in the way an enterprise executes its business. It also requires the capability to define business terms unambiguously across the organization. Most organizations are struggling with this, which is why MDM is about organizational change.

Master Data and Business Process Management

At the end of the day, data is generated during the execution of business processes. If you track low quality data you will ultimately find a more or less defunct business process. If this business process is not adjusted, all your MDM efforts can is clean up low-quality data after the fact, which is costly and ineffective. The largest single impact on data quality can be obtained by changes to the business processes.

Different business units can carry radically different views of their roles in the business processes and the data needed to support the processes. Usually issues arise when a common understanding of the process is missing. The process facts that any MDM project must keep taps on are:

  • Identify the processes impacted and the process owner,
  • Identify the cross-organizational issues,
  • Model the process (and get signoff from all stakeholders), and
  • Identify and prioritize changes needed (and get signoff).

There are numerous process enablers or facilitators that can have a positive or negative impact on the quality of data being collected or updated by the process:

  • The design of the workflow (duplicated or useless steps, number of actors),
  • The IT systems (fitness for purpose and ease of use),
  • The information management (governance of information and data),
  • Motivation and measurements (incentives, culture and KPIs),
  • Human resources (empowerment, education, competencies and availability),
  • Policies and rules (excessive reviews, restrictive contracts, missing rules), and
  • Facilities and infrastructure (lack of tools, office space).

Any of these enablers may turn into a disabling feature if not applied correctly, and in order to address any one of them, change management skills are needed.

Change Management in Master Data Management

The success of any project ultimately lies in successfully getting each employee to do his or her work differently, multiplied across all employees impacted by the change. Effective change management requires an understanding and appreciation for how one person makes a change successfully. Without motivating each individual, they are left with process activities but no idea of the altered goal or outcome trying to be achieved.
In order to facilitate change, the most common tools are communication and training, yet there are a lot of other levers that can be pulled to make changes stick. Communication is great for building awareness and desire for a MDM solution, and education can impart knowledge. However, the change aspects that need to be managed are far greater still.

Use the checklist below to benchmark your MDM initiative’s change maturity, and hence, it’s chance of success:


  • Are the MDM efforts collective, or one department’s sideways thrust into the organization?
  • Does top management sponsor the initiative?
  • Do the sponsors (senior leadership) believe, support, finance and live the MDM strategy?

Stakeholder Management and Communication

  • Does the MDM project approach different stakeholders with tailored communication packs?
  • Are the senior stakeholders willing to allocate business resources?
  • Does senior management attend meetings or send substitutes?
  • Do you actively seek out and communicate with employees whose daily routines are impacted?

Resistance Management

  • Is resistance brushed off as disloyal/valueless/avoidable, or is it used as a gift of information that is embraced and turned into an asset for the MDM initiative?

Education and Coaching

  • Is education and coaching of employees delegated to experts, or is it a relation building exercise between an employee and the direct supervisor?

Measures and Control

  • Is the MDM initiative benchmarked?
  • Does the MDM program specify KPIs for data quality as part of the deliverables?
  • Are the promised results and measures backed by on-going monitoring?

Incentive Structures

  • Are the new initiatives measured for more than show?
  • Are employee and management incentives dependent upon the success of the MDM initiatives and the subsequent rise in data quality?
  • Are the statuses of departments and individuals tied to (master) data quality?

Business Process Design

  • Is low data quality seen as an IT issue?
  • Is the business willing to alter the way data is captured, updated, used, archived and ultimately deleted?
  • Is business process change backed by specific business change initiatives tied to identified and documented business processes, such as “develop product” or “acquire customer”?

Organizational Structure and Reporting Relationships

  • Does the MDM program establish an organization that manages master data?
  • Does the MDM program leave capabilities, skills and structures in its wake?
  • Are there qualified data quality technicians, data modelers, ETL developers and integration experts to carry the effort forward?
  • Is data ownership and data stewardship established in the business?

IT Governance

  • Does your IT governance ensure that projects do not manage master data individually?
  • Is a common enterprise information model used in all projects?
  • Is system integration following an enterprise plan and not added as an afterthought?
  • Is re-usability and loose coupling between systems seen as an investment and not a cost to the project?

All scores below three are a potential liability requiring attention to reduce the risk of failure.Implementing MDM is not trivial. If you wish to avoid launching the same master data project over and over, some basic ground rules must be observed. The business needs to take ownership of the transformation, and IT must be willing to focus beyond technology and deliver analytical expertise. To realize the full benefit of MDM, you have to (re)design both business and IT governance processes that interface with the ongoing day to day operations of the company. Once the business is ready to accept the process, policy and organizational changes, it is time to start looking for the technology to support your efforts.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access