Master Data Management Myth Busters

Recently, I’ve observed a wave of articles, product releases and even analyst reports that describe solutions for companies looking to “get into” master data management (MDM) or “try out” an MDM project. Other reports claim that companies have been successful at MDM without having an MDM infrastructure in place.

As someone who has been actively involved in the data quality, integration and management market for more than 20 years, there are several myths about MDM that have become commonly accepted. Here are the three biggest myths about MDM that are currently being pushed as reality.

An Imprecise Definition

Myth: Master data management is the way to get your data in shape.

Fact: This assertion is dangerously simplistic and analogous to rebuilding a motor to repair a spark plug.

It’s no surprise that people are confused as to the real meaning of MDM when so many definitions have been bandied about for several years. Some sources define MDM as a way to manage enterprise data about a company’s products, customers and other information assets; this is, at best, imprecise.

Master data management is defined exactly as it is written: the management of master data. Master data provides that single, unified view of the data, encompassing information from multiple sources in the organization. To achieve this, you have to have a number of components in place — universal agreement on data definitions, data governance policies to guide the collection and management of data, a data stewardship group to enforce these standards, and technology to reconcile and standardize data from dozens or hundreds of applications.

Data management (without the “master”) is a continual, more achievable process that helps a company maintain an accurate customer count, verify addresses, generate precise inventory numbers and perform other data-oriented tasks. It is a prerequisite for any successful MDM initiative. All companies who have achieved their MDM goals have had sophisticated data management practices already in place. To say that MDM can improve your data is not practical. It is, instead, the culmination of many different data management and data improvement efforts.

It’ll Take Years

Myth: Companies who want to implement an MDM initiative can do it tomorrow.

Fact: The concept of “entry-level” MDM is the equivalent of trying to run an “entry-level” marathon or do “entry-level” open-heart surgery.

As the point above suggests, MDM simply isn’t something you can start doing right away. This idea exists to leverage the MDM hype cycle, just like late-night infomercials that promise to make you a millionaire in five days if you buy a book. MDM is the zenith of what will likely be years of successful information quality assurance.

By the time a company is ready to seriously consider implementing an MDM project, it needs full support of its executive team and employees, have proactive data quality and integration programs in place, and also have full sets of business rules that can monitor data and flag any inconsistencies. Data de-duplication — the process by which redundant, incomplete data is eradicated — must be a core component and run like clockwork.

In other words, companies may not be doing MDM on Day 1. However, you can take significant steps to make yourself MDM-ready. Invest in data quality and data governance programs to start treating data as a valuable asset. Train employees in the proper methods to manage data within existing applications. Also, more importantly, do some initial data profiling or data analysis to determine the relative strengths and weaknesses of corporate data to help build a blueprint for future MDM efforts.

A People and Process Project

Myth: MDM is a software package we can simply install and start to use.

Fact: MDM involves people, processes and technology — and the first two are probably the most critical.

Ask anyone who has undertaken an MDM effort, and you will hear stories of political infighting. (“My data is good, your data is bad.”) You will hear long, emotional dissertations about the hundreds or thousands of business processes that have to be documented within an MDM system. You will hear about the months — or years — of services consulting required to get the project off the ground.

This is not the picture that most IT and business executives normally get from the market, however. As soon as the large software vendors started rolling out MDM technologies, the argument about doing MDM versus not doing MDM often boiled down to a simple question for many companies: Do we install a software package to make it work? This should come as no surprise to those who lived through the customer relationship management and enterprise resource planning initiatives of a decade ago. Those projects often underperformed and went over-budget due to the massive services required to make them work.

A good estimate is that an MDM project is four parts services, one part technology. To illustrate why, think about something as simple as the definition of a “customer.” Sales and marketing will view them as entities who have purchased a product. Finance may view customers as those who have paid a bill. Support will see customers as anyone with an active account. MDM is saying that you will have a single, unified view of the customer, but what happens when nobody agrees on what the term means?

Now, just imagine what happens when these groups have to agree on complex processes for managing data across its life cycle. This becomes a huge “people and process” project. The technology is most likely ready to go, but the organization is usually not — leaving MDM as the mirage in the distance.