Continue in 2 seconds

Master Data: The Linkage between Business Functions and Business Processes

Published
  • August 01 2005, 1:00am EDT

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.

This is a trivial example when compared to understanding a customer's organization. In order to understand a customer's organization, information about its locations and organizational structure must be obtained. The business units, office locations and departments are not identified in the Knightsbridge example, yet that information is needed in order to have a comprehensive view of the organization. It can be extremely challenging for vendors to understand their customers' organizations because third parties offer only partial solutions, and keeping that information up to date is difficult because of constant changes that are occurring in most organizations.

Validation Lists

Additional challenges exist with master data when validation lists cannot be purchased. Instead, they need to be created for categories such as inventory, products and suppliers, which are unique to each organization. The amount of effort required to manage these and other master data categories grows exponentially unless there is a methodical approach and process in place. Several factors should be addressed in the approach:

  • Identify master data categories and which information systems contain this information.
  • Determine the approach to assess the quality of the data.
  • Obtain or define validation lists.
  • Define the business rules to be applied during translation and validation.
  • Integrate the master data back into the source information systems and into the data warehouse.

Define the Workflow

In addition, the workflow should be defined for the process of creating and managing master data as well as the stewardship, review and approval stages. Software vendors such as Kalido and Silver Creek Systems have developed products that assist in the management of master data, thereby facilitating workflow, processes and standards while enabling efficiencies for their customers. Appreciation for these technologies has been gaining momentum over the last few years as organizations attempt to address master data management. We see the trend of adopting master data management programs continuing into the foreseeable future because of the vast amounts of data that are being collected and needed for monitoring, analysis, reporting and decision-making purposes.

Beginning a Master Data Management Program

Before undertaking a master data management initiative, there are several important items to consider. First and foremost, master data management is a program and not a one-time project. It requires an iterative approach that continuously monitors, evaluates, validates and creates master data from reference data because your organization is constantly collecting and processing data. While a master data management program may appear to be an IT initiative because of the technology involved, it is not. It must be business-led because the master data values must be "owned" by individuals who have extensive understanding of the operations of the business, business terminology, and the context and hierarchy of the data. Given these aspects, people and project management must be emphasized over technology within the master data management program. This is not to say that technology is not important - it helps to automate manual processes - however, there is significant reliance upon people and processes in order to have an effective program. Another important item is that productive change management must occur if your organization is going to be successful with this initiative and solve the master/reference data problem. The last item to consider is that true or pure master data is never achieved because business and data views are constantly changing; a final state of perfection is impossible. However, those organizations that have effective master data management programs continuously seek improvement.

As management teams pursue their strategies while challenging their business models and practices with the objective of improving revenue while reducing costs, information will be needed to answer questions about business processes and activities. These analyses are difficult, if not impossible, to conduct unless master data management has been implemented as a program throughout the organization. Otherwise, how will you go about linking reference data from one information system to another in an efficient and continuous manner? 

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