Master Data Management (MDM) is becoming a key component within day-to-day performance management. The initial aim of MDM is to provide in a consistent, adequate and accurate data view of the company’s core business entities. This view may affect reference data that is scattered across a wide range of critical operational applications. The MDM allows unrelated applications to share a set of common synchronized reference data. Data may vary from situation to situation but most common are the types of products, customers, finances, and suppliers. Furthermore MDM is the collection of applications, processes and technologies that provide a company with the capability to define and provide reference data directly linked to its core business. This collection is typically generated by using data integration tools like ETL.

Given the above, it makes limited sense to further amplify the importance of MDM. It represents the sole and single version of the truth for operational data. Business analytics and planning will become quite fuzzy when a certain product is pointed as “consumer good” in Sweden, where it is indicated and referenced as “industrial key market” in Mexico. The room for error is even bigger in financial reporting: ask different people for the definition of “Operational Margin” and you will be amazed by the fact you will have more than one definition.

The need for MDM in your organization is quite easily recognized. Typical symptoms of lacking a proper MDM are: no clarity on who is accountable for data quality, margin calculations differ from department to department, reconciling numbers takes longer than analyzing them or certain business rules can only be obtained from the Cobol programmer in the ICT department. From another order are topics like compliancy and Sarbanes Oxley (SOX). If your organization lacks proper traceability of data manipulations, you might end up with SOX issues. A key component of MDM is full traceability.

Essence of Metadata and data quality

The MDM is the ultimate place to store all kind of metadata (definition of field lengths, formats, data types etc.) in a structured way. Metadata however is only a small piece of what is needed for an MDM solution. It is now widely recognized that implementing performance management starts with improving the quality of master data on which operational applications and processes rely. Customer indexes, product books and their respective history, definitions or reference tables; they should all find a place in the MDM. The MDM is the preferred way of defining, storing and archiving reference data and metadata. By agreeing a set of standards, it is determined how information will be defined, stored and formatted.

However, when extracting, transforming and loading data in to the MDM, one will easily discover that the interconnectivity between operational applications contains numerous synchronization scripts, ETL processes, triggers, queuing and programs. While deploying applications, piece by piece logic is added to them as part of application-evolution during time. It is here where we will find huge amounts of business rules, logic and intelligence crucial to the interpretation of the core business.

In this context there’s already been spoken in the media about the Enterprise Data Bus (EDB). The EDB’s responsibility is to ensure timely and accurate availability of data for all applications, and in the same time guarantee the rules, logic and intelligence are embedded into the MDM. The EDB is an essential and integral part of the MDM. It’s not sufficient to only provide data as reference data via MDM, even important is to define how reference data is generated. Therefore an MDM without an integrated EDB will have limited chance be successful.

Another reason for an integrated EDB are the Service Oriented Architectures (SOA). If your organization is about to start with SOA – or already implementing -, you will recognize the importance MDM. Data commonality and data consistency are core essentials for web services approach and heavily relay on effective master data management.

MDM in a wider perspective; relation to Performance Management

The key to better performance management and improved business insight lies in improving the quality of the master data on which operational applications and processes rely. The lack of quality master data slows down the launch of new products and exposes a company to significant regulatory and compliance risks.

The data warehouse – a crucial component in any performance management architecture – plays a key role here. Master data that is not being adequately maintained causes data warehouses to deliver questionable results. It is therefore that a MDM requires a process – not a project or program – for ongoing maintenance. The positive side effect of such a process is of course that not only the data warehouse benefits, but also all other operational applications using reference data. The MDM maintenance process should encourage data stewards to continuously work on the quality of the data in their respective applications, and thus improving consistency and reducing operational failures.

I have seen many data warehouses where the idea of MDM is more or less embedded in the ETL-programs populating the warehouse. To a certain extent – especially in smaller and less complex environments – this might work. Here the data warehouse repository “represents” the MDM. However, in more complex situations a separate and dedicated MDM is a necessity in order to benefit from the full potential of a data warehouse and performance management environment. From a historical perspective, data warehouses never try to fix business processes that cause inconsistent master data, nor do they try to correct master data back into the operational applications. A MDM allows master data to synchronize back into the applications and data warehouse.

Investing in MDM will allow organizations to fully leverage investments in Business Intelligence, ERP and Performance Management.

Essentials for driving MDM in your organization

Given the complexity and dynamics of the business environments an MDM acts in, it is not easy to list a simple list of success factors for deploying a MDM. However case studies help us to create and overview of MDM essentials:

• The MDM process is best driven by business people rather than by IT people. Business needs should drive the MDM, otherwise the result will be yet another database. Company wide sponsorship is essential for the long-run success of MDM.
• Master data should always be time stamped to ensure audit ability. For example, it is required to understand which data was used to drive performance reports and analytics.
• The principle of CRUD (Create, Read, Update or Delete) needs to be obeyed in order facilitate a master data lifecycle. Again from an audit trail perspective it is important to have traceable results on for example data ownership.
• Think and define big, but act in manageable small pieces. It is important to set the wider MDM objective in an early stage, while in the meantime respecting this objective in smaller piece by piece steps.
• Run a proof of value with real data to allow for proper planning of the MDM process. MDM is complex and requires thorough understanding of challenges, buy in, expected complexity and return.
• Use the Enterprise Data Bus to ensure business rules and logic become part of MDM.

Summary

Unfortunately MDM is not yet in a mature state, being poorly understood, defined and recognized. To many times MDM is simply understood as “shared data” whereas it is definitely much more. On the other hand companies more and more recognize the need of a MDM. A recent study of The Data Warehousing Institute (TDWI) showed 50% of the leading companies will have MDM initiatives within the next 2 years.