Master Data: The Linkage between Business Functions and Business Processes

Information Management Magazine, August 2005

Jonathan Wu

Organizations that have created effective master data management programs have achieved a wide range of benefits that include: improved and accurate reporting; the ability to monitor and analyze activities throughout business processes; a single and comprehensive view of customers, products and supplies; and reduced errors and expenses. Effective master data management programs contain process and technology discipline to define, manage and share master data across the enterprise. This article addresses how and why it is important to link reference data between information systems to achieve a higher level of information quality and the ability to analyze activities across business functions.

The ability to analyze data across business functions and business processes is dependent upon linking data from disparate systems, applications and external sources. This ability to effectively link data from disparate sources is dependent upon master data. Master data is the controlling set of data values for reference data, which is a category of data that describes and defines transactions. Five primary data categories (each of these categories corresponds to a particular set of data) are part of most information systems environments (see Figure 1):

• Meta data,
• Systems/application data,
• Transactional data,
• Reference data and
• master data.

Figure 1: Five Categories of Data

Reference data contains the values that describe a transaction: who, what, when, where and so forth. The data type that is commonly used for reference data is a text field that can contain alpha and sometimes numeric values. For practical purposes, there is a finite set of values associated with reference data. For example, the number of customers is limited to the population of individuals or organizations: there are only so many in this world. In addition, the format and structure of the data values are dependent upon the individuals who created them.

A few common reference data categories are: customers, employees, inventory, materials, products, suppliers and vendors. The ability to describe a transaction is dependent upon reference data. For example, the data value of 10000.00 does not have much meaning by itself. However, if you add reference data to the transaction, it has greater meaning and context: customer Knightsbridge purchased product X123 on July 31 for 10000.00. The reference data categories that describe this transaction are customer, product and period.

Customer Reference Data

Let's examine customer as a reference data category in the following example. Within a large product company that sells to other businesses, there are typically several information systems that are used to identify potential customers, capture sales transactions and manage customer relationships. The larger the organization, the more complex their information environment becomes. In addition to internally collected or derived data, external sources of data are incorporated into this information environment. Each business function collects and processes information about potential or current customers as follows:

Marketing Department: The marketing department collects information about potential customers from leads identified at conferences and trade shows, responses to their marketing campaigns and purchased lists. This information is then loaded into a legacy system that was developed internally many years ago.

Direct Sales Group: Sales executives enter potential customer information into the sales force automation (SFA) application from their own contact lists that they have developed. In addition, potential customer information is periodically loaded into the SFA system from marketing's legacy system.

Channel Sales through Distributors and Value-Added Resellers (VARs): Distributors and value-added resellers are intermediaries that sell your products to potential customers not on the direct sales group target list. These groups have their own systems for collecting customer information, which is then passed to your company periodically via ANSI flat file.

Accounting Department: As orders are entered into the enterprise resource planning (ERP) application, customer information is processed for purposes of shipping products, invoicing and collections.

Customer Support and Warranty Departments: Customer information is loaded into the customer relationship management (CRM) application from the ERP application and from ANSI flat files received from the company's distributors and VARs. In addition, customer information is continuously updated and monitored as part of the customer support function.

To find out how many new potential customers marketing identified this quarter versus last quarter, you could execute a simple query in marketing's legacy system. To ascertain how many customers the organization had this quarter versus last quarter, you would query the data from the ERP application. Within a business function, these questions can be simply answered by querying the appropriate information system. In most cases, there is one primary information system to access. However, if you asked a question about customers that spanned different business functions (such as, "From the point of identification of a potential customer to closing a deal, how many days on average did it take this quarter as compared to the prior quarter?"), you would need to somehow link customer information from each of the information systems that needed to be accessed. This seems like a straightforward question; however, answering it can be challenging and time-consuming because it requires linking the data from one information system to another.

Undoubtedly, differences in customer names arise because each business function obtains information about potential customers or current customers either by entering that information or by having it uploaded into their information systems from various sources. Figure 2 provides an example of those differences.

Figure 2: Example - Differences in Customer Name

Given the example provided in Figure 2, using the customer name to link across the various information systems will not work because there are four unique names for the same customer; not one customer name is exactly the same as another, so there is no match. To address this challenge, customer name must be translated into a standard format - which then would be compared to a validation list that contained legal entity and fictitious names to consolidate associated names and then assign a master name for the customer. The processed values for customer name become master data, which then can be used to synchronize systems and provide linkage of data across information systems. While this process appears uncomplicated because the validation list can be purchased from third-party vendors, added complexities exist when the validation list is not periodically updated or the translation rules do not account for exceptions.

Page 1 of 2.