Master Data Management - A Systematic Approach

Information Management Magazine, October 2006

Matthew Beyer

Problems with master data are nothing new; companies have battled them for ages. However, users are only now recognizing the need for a systematic approach to data management just as the Sarbanes-Oxley Act spotlighted the need for a sustained approach to compliance with government regulations, instead of implementing one-off tactics whenever necessary.

Users also know they have a problem with master data with respect to their transaction systems. Unfortunately, most lack a comprehensive plan to deal with it. Additionally, cost and scope make top-down solutions impractical, especially for manufacturing and retail companies that rely on packaged software. For many organizations, the best idea is to make master data management (MDM) improvement projects an element of every significant business initiative, with each one featuring a specific roadmap indicating how to piece together a complete solution over several years.

MDM is no cure-all, especially for companies lacking solid data environments. It requires significant legwork and preparation, including determining which data elements ought to be considered master data. To date, there are no universal standards, so companies must develop their own to define what makes a data element part of their master data. Additionally, when these parameters are established and master data can be defined, subject areas (e.g., item, customer, vendor, etc.) need to be prioritized. Which should be included? In what order?

Designing the tactical solution to address the MDM initiative (or the MDM portion of a corresponding initiative) is another step. Identifying the need for an MDM program is a strategic endeavor; it does not call for the tactical details required to design the actual solution. Instead, the actual solution requires an in-depth understanding of the data and the techniques and processes involved in deploying an MDM initiative.

Achieving data quality is another challenge. Companies must maintain a clean master data environment, just as they do with ordinary data quality programs. Unfortunately, even clean master data decays eventually - duplication and incorrect values inevitably creep in, and simply centralizing it is not a complete solution by itself. Data quality needs to be everyone's responsibility; effort should be distributed among various individuals, departments and geographies. Moreover, upholding data quality must be an ongoing program or the MDM initiative will be disappointing.

Defining and Deploying an Appropriate Solution

To reach their MDM objectives, data professionals should think strategically but act tactically. The best approaches consider the entire problem holistically and then solve it in business-focused, identifiable segments. A structured approach delivers early, frequent successes, creating project momentum and sustaining morale. Additionally, each completed phase adds business value. Consequently, if business priorities shift, the entire project does not fail, as it would with a big-bang approach.

Tactical Steps to Follow

1. Understand the current environmental complexities. The organization needs to look at its application environment pragmatically and dispassionately. Objectivity enables a focus on information that must be known to complete the program effectively.

Understanding environmental complexities includes taking inventory of systems and processes. Large companies often feature hundreds of systems that are prime candidates for MDM analysis. By assessing their capabilities, use and performance, the organization can determine which qualify and which do not. However, that is slow and tedious work. Sorting applications into tiers is more effective.

Classifying applications by the degree to which they use and/or manipulate master data eliminates significant unnecessary work. By assigning each application to one of three tiers for each subject area, many applications can be eliminated very quickly, leading to substantial savings in time and effort. A system featuring item and customer data can be assigned to a tier indicating its duality and value. The tiers are described here:

• Tier-one systems involve reference data maintenance. They change master data somehow; they insert, update or delete information. An order management system which calls for customer data entry falls in this category.
• Tier-two systems receive reference data. They do not change master data but use it heavily for processing. A pricing application, for example, requires vendor, location and item data but creates none of that information. It only creates a pricing model.
• Tier-three systems (not discussed in this article) leverage no reference data.

Identifying and understanding a company's business processes are other challenges. When business processes are not well documented (i.e., most of the time), documentation must be performed from scratch. The application identification model is helpful here. Each business process, like each application, can be assigned a tier.

Actually, managing master data requires several business processes itself, such as adding a new product, hiring a new employee or removing a redundant supplier. Within a grocery organization, for example, a division might add an item, such as a kind of produce. Another group might add an item such as soap. The grocer may also have a direct vendor feed. Consequently, complexity mounts quickly. Business processes such as these, which affect process flows when an activity is changed, deleted or added, can be identified as tier one.

Tier-two business processes concern data users, such as consumers. They are less likely to have a dramatic impact. Still, integrating the business processes involved in an MDM initiative can be just as complex as integrating the systems and just as worthy of assigning specific processes to tiers.

2. Build the approach and prioritize systems. A sound way to begin building an approach for an MDM initiative is to create a "straw man" logical data model for the subject area(s) involved. Before executing interviews, the model can provide context for detailed discussions. As systems are reviewed, the logical model is updated with additional attributes and discovered entities, and the system is mapped to the logical model at an attribute group level. Be sure to leverage existing data models when developing the logical data model.

Page 1 of 2.