The market for master data management (MDM) is maturing. Conversations with clients and prospects have shifted from “What is MDM?” to “We have some problems, and MDM can solve them. Where do we start?” That’s clear progress. So what are those problems? They cross lines of business, span subject areas and transcend operational and strategic challenges. Here are a few recent quotes from some executives who pinpointed MDM as a business solution.
- Director of e-business marketing at a brokerage firm: “I never thought I’d say it, but in the seven years I’ve been here, we’ve gone from having no data to having too much! The same customer exists in different ways in different systems. The data warehouse just represents one of many versions of customer.”
- A media company executive: “We’re constantly acquiring new companies, which means we’re constantly absorbing new systems. It’s a nightmare.”
- Director of regional sales at a medical device company: “We don’t have a hierarchy of products categorized by preferred vendor, and there are huge variations of product descriptions. We can’t keep our product catalog - never mind our Web site - accurate and current.”
- Data steward (external consultant) for a mortgage company: “I can’t even begin to quantify the amount of manual work they’ve had to do to maintain their data. Everything there is a fire drill. If I were to guess, this has cost millions. No wonder the industry is in trouble!”
- CIO at a health care provider: “It’s not just about all of our systems sharing authoritative data. It’s about synchronizing and syndicating that data across businesses and geographies. This is critical to our quality of care. That’s what keeps me up at night.”
We define MDM as the set of disciplines and methods to ensure the currency, meaning and quality of a company’s reference data within and across subject areas and systems. This lofty definition colors in the depth and complexity of MDM initiatives. Put more simply, MDM ensures that your systems leverage and reuse common, accurate business data.
The Need for an MDM Taxonomy
The companies we’ve worked with have taught us an important lesson: how master data is used has little or no bearing on MDM maturity. Terms like “collaborative” or “analytical” MDM only serve to muddy the waters when it comes to MDM functionality. How the master data is stored, accessed and propagated to the enterprise indicates MDM’s evolution in an enterprise. While data usage adds complexity to the MDM debate - and may even enrich the requisite MDM “marketecture” diagrams of some vendors - it is ancillary to how the company manages, integrates and deploys its master data.
Many MDM newcomers continue to discuss the topic in terms closer to relational databases, but most robust MDM solutions aren’t designed as reporting databases (many businesspeople would argue that there are enough of those already!). MDM systems contain more detail than a simple subject area reference list; they can contain all of the necessary details to support item identification, relationship details, security and access as well as administration and management of a company’s reference data.
MDM is more than a single image of data. Successful MDM implementations enable business data to contain rigorous and standardized content that reflects business-based logic and rules processing. In addition to offering a solution for the widespread “single version of the truth” goal, MDM offers automated tracking and reconciliation of data from different sources.
The goal of most MDM solutions is to ensure that master data includes reference details that reflect the current state of the business. As with most complex business-enabling technologies, this does not happen in one development iteration. Consequently, we’ve identified five stages of MDM maturity, shown in Figure 1, which can help you gauge your company’s MDM evolution and offer a structured and deliberate pathway forward.
The MDM maturity taxonomy reflects degrees of complexity and sophistication. It seeks not to be prescriptive so much as to elucidate the various functions that MDM provides and what’s involved in making them work. Our purpose is to help crystallize the various functions you need from MDM and map them to your company’s capabilities. The MDM model is independent of the current crop of tools and technologies; most of today’s vendor solutions will work within all levels of the taxonomy. Each MDM level supports and builds upon the capabilities of the prior level. Consider the taxonomy less a recommendation of steps - your company may or may not need to go all the way to MDM level 5 - and more of a progression of states.
MDM at Level 0
There is such a thing as no MDM (level 0). For instance, your company might have a list of assets, such as products. At level 0, each system that processes product data has its own list of products. There is no data sharing between applications. No enterprise definition of data elements exists.
At level 0, each application is responsible for managing and identifying its own product list and orchestrating change. This situation is common, particularly in companies that sell custom-packaged or specially priced products. Such products are frequently created individually within the different systems (sales, contracts, billing, fulfillment, etc.) because there isn’t an automated method of sharing this information. Each system contains its own product. As Figure 2 illustrates, data is disconnected and independently managed.
From a business standpoint, MDM level 0 means that different organizations access the same data from different places. For instance, the finance group calculates costs using the item purchase price from the purchasing system. Conversely, sales uses the company’s pricing details contained in the sales system. Unfortunately, the organizations employ different data and different logic to calculate their respective costs. When each department produces its margin and profit calculations at the end of every quarter, the numbers are different. The creation of this information is specific to an application’s need or purpose, with little sensitivity to the data’s origin or how it might be used by other systems.
MDM Level 1: List Provisioning
List management is common in companies large and small. Disparate systems and users across those systems need updated lists of customers, products, salespeople or other business entities. Yet many companies still manage and provision their lists manually. Data additions, deletions and conflicts are all handled as a series of discussions or meetings by staff members. While rules reflecting value conformance, change criteria and the like exist, this highly manual process is error prone and often dependent on who participates during the change management process. List generation isn’t repeatable; it’s not reconciled or audited, nor is it automated.
At MDM level 1, decisions to change and modify the data are people based and thus only as valid as the people making the decisions. The process itself might be well-defined, yet it’s immature due to the lack of centralized, rules-based data management. While this may be a realistic approach when there are a small number of customers or products, scaling the process becomes impractical as the product catalog or customer list grows and becomes more volatile.
MDM level 1 relies on human collaboration. If a product manager needs a list of updated product prices, she’ll call the enterprise resource planning (ERP) system owner, who will email it. The likelihood that the customer or product list is enterprise-wide is only as solid as the relationship between people in different departments. If there are hierarchies and groupings among customers and products, list provisioning becomes even more difficult and is usually too complex to manage at level 1.
MDM Level 2: Peer-Based Access
MDM level 2 introduces data management rigor to support the using and sharing of data between systems. This rigor includes establishing data standards, defining access and sharing of details contained in a central repository, what we’ll call a master data “host.” The repository may be a database or an application system that supports the access and sharing of data in an online manner.
Create, read, update and delete (CRUD) is a classic programming term for basic processing functions. In the case of MDM, CRUD processing is foundational. But just because your database can support CRUD processing doesn’t mean you’re doing MDM. MDM level 2 involves peer-based access, meaning that one application can “call” another application to update or retrieve the necessary data. While rules for CRUD processing are defined, MDM level 2 requires that the consumer or “peer” application format its requests (and data) to conform to the rigor of the MDM repository, which effectively hosts the master data. The MDM repository provides centralized data storage and provisioning. At this stage, rules management, data quality and change management must be add-on functions custom built for the environment.
An example of MDM level 2 would be a database or packaged application (such as a sales force automation system) providing data access to external applications. When an external application (such as a call center application) needs to add a customer, the external application would submit a transaction requesting the data owner to add a customer entry. The master data host would add the data and acknowledge the activity to the external application, as illustrated in Figure 4. This is a fairly common approach to implementing MDM within a packaged (or distributed) application environment.
CRUD processing is an improvement over paper- and conversation-based data administration. At MDM level 1, data changes are manual. At MDM level 2, they’re automated - there is a standard process that’s enabled by technology, allowing modification of the data by multiple applications. MDM level 2 can support different applications using and changing a single, shared repository of data.
MDM level 2 requires that every peer application understand basic business rules in order to access and interact with the master list. Thus, every peer application must create, add, update and delete the data accurately and correctly. The authorized applications are responsible for adhering to data management principles and rigor. Level 2 represents an effective launch pad for more complex MDM capabilities. We’ll discuss this evolving complexity in part 2 of this article.
Evan Levy is a partner and co-founder of Baseline Consulting Group, a multivendor systems integration and consulting firm. As the partner in charge of Baseline’s largest practice, Levy leads both executives and practitioners in delivering technology solutions that help business users make better decisions. He has led strategic technology implementations at commercial and public sector organizations and advises vendors on their product development and delivery strategies. Levy has been published in a wide array of industry magazines and has lectured on a range of technology delivery experiences at leading conferences and vendor events. He has been a featured speaker at the Marcus Evans Analytical CRM symposium, DCI’s Data Warehousing conference, the CRM Association, DAMA International, the AMA and the Data Warehousing Institute. His current work involves delivering and lecturing extensively on the topic of data integration. You can contact him at email@example.com.
For more information on related topics, visit the following channels:
Jill Dyche is a partner and co-founder of Baseline Consulting (www.baseline-consulting.com), a data integration and business analytics delivery firm. Her first book, e-Data (Addison Wesley, 2000) introduced managers to the concept of enterprise data integration. Her second book, The CRM Handbook (Addison Wesley, 2002) is the CRM best-seller. You can reach her at firstname.lastname@example.org.