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.

3. Determine what qualifies as master data. Many definitions describe MDM, but none define master data itself. In fact, determining what qualifies as master data is often problematic, but it is fundamental to success. It can be used properly only when it is identified, and the organization has a uniform description.

Fortunately, there are relatively easy ways to identify master data. If a certain data attribute is used in eight of a company's 10 systems, it is probably master data. If it is used in just two, it is probably not. Often, it is worth noting that companies might consider a piece of information to be master data in one scenario but not in another. Three widely accepted parameters to determine specific criteria that constitute master data are:

  • Referencing transaction data as master data. Some systems reference transaction data from another system to support internal business processes. They use it in a manner similar to master or reference data.
  • Understanding master data associations created by transaction data. Common outputs of business transactions include assignment of ownership, responsibilities or commitments that link two master data entities. When this occurs, the results are usually disparate, manually maintained copies of the same information.
  • Leveraging status information. Status information usually tracks a master data entity's progress or performance within the context of a given business process (planning or transactional). It may or may not be classified as master data, depending on its functional dependence on transactional data entities.

Without a clear definition of master data, companies are exposed to numerous problems when gray areas arise, as they invariably do (usually very quickly). As such, attempting to implement a data foundation before defining master data is asking for trouble.

Understanding the Opportunity

Keep an MDM initiative's business purpose top of mind. By understanding the problem that the initiative is designed to solve and focusing on it, success becomes more likely. Data consolidation is costly and time-consuming; it must help solve a business problem to be worthwhile. For instance, a multichain conglomerate looking to optimize supplier purchasing should focus on vendor and item data so it can recognize when use of a common supplier can leverage economies of scale and eliminate risk.

Additionally, when considering the opportunities an MDM initiative provides, the company must scrutinize internal prospects. Establishment of a global standard data pool can help a large organization use master data to significant advantage.

Stay with It

MDM enables companies to become more competitive and profitable, and to expand strategically and with integration. Consequently, the pressure to implement successful MDM initiatives grows all the time. However, MDM is not a magic potion, and like most important projects, it requires lasting commitment from the entire organization.

Additionally, MDM initiatives provide numerous quick wins, but the long-term benefits are more substantial. If dedication becomes lax, MDM's effectiveness will be curtailed, if not eliminated. Vigilant, consistent governance will keep an MDM initiative working for years. The team members must be disciplined and stay involved for the duration. A clear organizational structure, one that empowers members to do their jobs, dramatically increases the likelihood of success.

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