Tom Haughey

Master Data and Master Data Management

By Tom Haughey on April 22, 2010
View Full Bio →

A customer has a trading account and credit card with the same company. The customer moves to a new address and calls the company to have her address changed. They only change her trading account address, not her credit card address. Her credit card bills are sent to her old address, and she does not receive them. She also doesn’t pay them. They send her dunning notices. She tries to use her card but cannot because it is suspended. A month later her credit card gets turned over to a collection agency, who “ding” her credit score. She sues but it takes months to resolve the problem. This is essentially a master data (MD) problem. Unfortunately, though not always this extreme, it is all too common. As you can see, because MD is highly shared, problems in MD will be propagated to all the other business areas that use it.

Definition of Master Data

MD is the consistent and uniform set of objects, identifiers, attributes and rules that describe the core (and relatively stable) entities of the enterprise and that is used across multiple business processes. The concept of MD excludes transactions and transactional summaries. Some people define MD as all data that is shared. It is true that MD is highly shared. However as a definition of MD this is too generic.

MD itself is relatively stable. It can change frequently but instances of MD change are not as frequent as instances of transactional data. A day trader may change indicative data at any time. This would still be MD. However, a day trader could make dozens, even hundreds, of trades a day. These trades are transactional and not MD. The trades, however, will utilize MD for its core data for customer, financial instrument, etc.

The need for master data management is anything but new. It was prominent even in punch card days when the MD was kept in “tub files”. In fact, early projects with data modeling in the 1980’s were often dedicated to MD.

Master Data Management

Master Data Management (MDM) is the set of disciplines, technologies, and solutions used to create and maintain consistent, complete, contextual and accurate primary entity data for all stakeholders. It focuses on the concept of core (or master) data objects which represent the key business entities that an organization interacts with to run the business. Core data objects include products, organizations, locations, trading partners, employees, customers, consumers, citizens, assets, accounts, policies, etc.

MDM is a business capability, not just a technical capability. It enables an organization to identify trusted core entity data. It supplies the most trusted and unique “version” of core enterprise data (e.g., customer, product, employee, asset, material, location, etc.). Usually, this enterprise data is captured, maintained, and used across disparate systems and business processes for operational and analytical uses. MDM leverages MD to improve business processes and decisions. It then incorporate this master version of the data within functional business processes (sales, marketing, finance, support, etc.) that will provide direct benefit to employees, customers, partners, or other relevant stakeholders within an organization.

 Use and analysis of MD alone is of some but limited value. How the data will be consumed by other applications or systems within the context of a business process provides the greatest value for MD.

MDM had common roots in two different parts of the business: a single view of product and customer. “Single view” doesn’t mean one place to look. It means that even if there are multiple sources, one consistent image is presented to the consumer. This could even imply multiple views synthesized from one or more sources.

Vendors often relate MDM to customer data integration (CDI) only. Some, but fewer, relate MDM to Product Information Management (PIM) only. The reality is both (and even more) are part of MDM’s scope and history. MDM includes the whole space of customer, product, and more such as employee, supplier and organization. MDM is not just a Data Warehousing or Data Integration or Migration or Data Quality project. Nor is it just about cost reduction. It includes all these things. In the final analysis, it is about business efficacy.

In the next blog we will discuss the processes of MDM, the layers of data, the patterns of MDM architectures and the methods of MD use.

Follow all Expert Blog updates by subscribing to the RSS RSS feed.

About the Author

Tom Haughey is considered one of the four founding fathers of Information Engineering in America. He is currently President of InfoModel, LLC, training and consulting company. His courses on data management, data warehousing, and software development have been delivered to Fortune 100 companies around the world.

There have been no comments yet.

Name:

Email:

Comment:

An … a day keeps the doctor away. What word is missing?

Notify me of follow-up comments?