Master Data Management: dos & don’ts

Introduction

Every organization has to deal with master data, and seeks ways to manage the quality of this specific group of data in an effective and efficient manner. Organizations are very active with business intelligence, (re)configuring (ERP) systems, optimising business processes, creating a single view of the client, and being compliant with external rules and regulations. Adequate MDM is an important prerequisite for achieving these goals. (See also [Jonk11].) It is for this reason that MDM is so high up on the agenda of so many large and medium-sized organizations. This article describes several attention areas that are important for implementing adequate MDM. These are also areas that are perceived by many organizations as being rather complex: the governance of MDM, the foundation of MDM, and the automation of MDM.

Manage & control MDM: ‘governance’

The objective of MDM governance is to control and, where necessary, adjust activities aimed at ensuring sustainable master data quality (plan, do, check, act). A clear structure of roles, tasks and responsibilities assigned to functions within an organization is an important component of MDM governance, but it is not the only requirement.

Do not go for gold immediately

Although it may be very tempting, you should not go for the ‘ideal model’ when (re)designing the MDM organization. In many organizations there is still no clear and effective working structure of process owners, system owners and data owners to which MDM governance could easily align. Similar to process governance, MDM governance also exceeds the traditional boundaries of departments or functional areas (for example IT or Purchasing). It therefore makes little sense to already implement this ideal model for MDM governance. Quite often, people will have to initially stick to answering simple questions like: ‘Who does what?’ and ‘Who takes which decisions?’

The existing organizational structure can be used as a starting point for the allocation of various roles within the MDM operating model. This way, new roles are gradually introduced into a familiar environment, which makes role assignment and acceptance more easy. ‘Think Big, Act Small’ is an often heard slogan within MDM. It indicates that the MDM vision must be organization-wide, object-independent and future-oriented. It also indicates that the implementation of this vision should best take place, at least initially, on a relatively small scale. This also applies to governance within MDM: align to existing, good working practices and gradually grow towards the desired operating model when the rest of the organization is also ready for this.

Explicit attention to communication and change management is an important success factor for MDM which must not be underestimated. As part of an MDM initiative, existing roles are revised and new roles might be introduced. Within the ‘Treat master data as an asset’ vision, it is expected that the parties involved will feel genuinely responsible for improving and ensuring the quality of master data, and will therefore behave accordingly. And to achieve that people show precisely this attitude, it requires significant effort to clearly communicate the added value of MDM and to prepare the stakeholders for the impact this is going to have on their daily ways of working.

From theory to practice

Important core concepts within MDM are standardization, unambiguous, clarity and consistency. MDM Governance can be most effectively approached top-down.

It is obvious that all kinds of local characteristics and system-specific configurations must be taken into account, but the quality of MDM is best guaranteed by an unambiguous, clear and consistent vision. The most effective way to create and express this vision is from a central, recognizable position within the organization, preferably with explicit support and communication from senior management (board level). This way, the set-up of MDM Governance in practice will be a top-down manager activity.

It is important here to emphasize that MDM not necessarily requires centralization of master data. There is an ongoing trend towards the incorporation of MDM in shared service centers, and the efficiency, continuity and knowledge-retention of MDM certainly benefit from centralization of activities. However, MDM is not synonymous with centralization. Depending on the context of business operations, there are also reasons to keep master data maintenance closely to daily business activities.

It is not enough to just allocate roles, tasks and responsibilities. Those involved should be provided with a structure (operating model) in which they can execute their (new) tasks and responsibilities.

MDM Governance should therefore establish communication structures to structurally link stakeholders to each other to discuss current issues and share insights. (In)formal MDM communities (a group of stakeholders from various disciplines and units) are proven solutions to facilitate exchange of insights, experiences and solutions in a simple way.

Principles, guidelines, standards and practical ways of working with regard to the design and implementation of MDM must be defined and documented, preferably in a common policy document.

Finally, there are also the so-called ‘supporting’ MDM Governance processes which focus on continuous operation – and where necessary improvement – of MDM as a whole within organizations. In this context, strong parallels can be drawn with the well-known ITIL processes:

• change management (for example: we add a new field to our table [X] in system [Y]; who will approve that and which systems, processes, procedures and standards have to be subsequently adjusted?)
• incident management (for example: incidents and issues involving the quality of master data or MDM should be transparent, and a follow-up on these issues must be specified)
• service level management (for example: establish and monitor service levels with regard to the maintenance of master data)
• compliance management (for example: ensuring that MDM in general and master data in particular comply with relevant internal and external rules and regulations).

Facts are required to effectively govern master data

Effective governance also implies the possibility to recalibrate the design and execution of MDM, where and when required. This requires the ability to report on master data quality and quality of MDM, using predefined performance indicators and quality criteria per master data object and MDM as a whole.

Table 1. Examples of typical performance indicators for MDM.

The foundation of MDM: master data definitions and master data quality

Master data definitions and master data quality are two important topics that set the core of MDM: what master data should fall under the regime of MDM (based on which characteristics) and what actually determines the quality of our master data?

Figure 1. The creation process of quality regulations within the scope of MDM. [Click on the image for a larger image]

Universal master data definitions do not exist

There is no such thing as a universal definition of master data or even a generic standard list of master data objects. Everyone will agree that ‘customers’ and ‘suppliers’ fall within this category, but for some data objects (such as contracts or organizational units) it might prove more difficult to get consensus. Often, definitions and data models of company specific IT systems are leading in this. However, it is possible to reach consensus on the characteristics of master data. When defining master data within your company, the discussion should focus on the question: ‘Which data objects do we want to be governed by MDM?’ (derived from the master data characteristics, see also [Jonk11]). This pragmatic approach has a much greater chance of success than a persistent focus on theoretical discussions about the all-embracing definition of master data.

After making up a system-independent inventory of the relevant master data objects, an analysis should be made how data objects exist within all (IT) systems. The way in which a master data object is configured within a specific (IT) system influences the design of master data maintenance processes. For example, a master data object maintained within the configuration module of an application (which is often maintained within an IT department) will use a different maintenance process than an object maintained by an end user via the application’s regular functional menus.

The abovementioned steps lead to a clear and common overview of master data objects, including their characteristics, classification, definition, and relations between objects. The objective is to create a common understanding and also to ensure uniform usage and application. This results in a so-called ‘(master) data dictionary’ and data model.

Quality is a vague concept

In day to day use quality is commonly used and is an obvious concept. However, quality also knows many, sometimes ambiguous definitions. Within the context of this article, we use the following definition:

Quality of master data is determined by the degree to which master data complies to the defined quality rules (which are derived from current business requirements). These quality rules exist in two forms, the ‘technical rules’ and the ‘business rules’.

• Technical rules are rules that are directly related to master data objects and their attributes (mandatory/optional attributes, attribute lengths, format conventions, etc.).
• Business rules are rules which arise directly from business processes and scenarios (for example, when creating a customer in the EU, you choose the subsequent ‘tax classification’). These rules frequently overarch master data attributes and master data objects.

Adequate definition of quality rules and ensuring compliancy to these rules will ensure that the business requirements are met.

So you must make quality tangible

For many organizations, the definition of quality rules is no straightforward and co-ordinated activity. The technical rules are usually recorded only in technical system documentation while data standards (if any) and business rules are often only in the minds of people and have not been explicitly described, evaluated and validated. In addition, there are also external standards and quality requirements that master data (and sometimes also MDM) must comply to (such as FDA/GMP, ISO for example). In determining the quality rules, you come to the essence of business processes, business requirements and the use of master data. Organizations tend to perceive the translation of business requirements to master data rules as a complex matter. This may be due to various reasons:

• Master data is not clear. The definitions of master data itself are absent, unclear and/or inconsistent.
• Business needs are not clear. Business processes and the corresponding requirements are unclear, are not understood, or are very heterogeneous.
• The rule structure is not clear. People have difficulty with linking business requirements to master data and extracting the resulting rules from these.
• System architecture is complex. A complex system landscape (for example , the presence of many translation tables to enable data models between applications to link up) makes it more difficult to define uniform and consistent rules.

To ensure a proper definition of quality rules, the set-up of master data ownership on one hand, and the gathering of the relevant knowledge holders from various disciplines on the other, are of major importance. It is also an iterative process, in which the rules can be constantly refined. After defining the quality regulations, one can draw the conclusion that a rule may not be sufficiently concrete, or that a specific business scenario has been overlooked. The set-up of ownership is important for facilitating the necessary decisions.

The numbers tell the tale

Compliance with these quality rules should ensure that business requirements are met. Often, organizations take (some form of) measures to ensure compliance with these regulations (such as mandatory fields in applications, or quality rules embedded in working instructions). These regulations are often fragmented and are enriched over the years. There should be a good mix of preventive measures (policies, working instructions, workflow, application control, SLAs, etc.), detective measures (defect reports, monitoring, KPIs, dashboards, etc.) and corrective measures (such as rectification procedures).

Monitoring is one of the most important measures for ensuring the quality of master data (‘the numbers tell the tale’). Predefined key performance indicators and the corresponding quality levels (what are the targets of each KPI?) are means to keep a grip on the quality of master data. However, defining these KPIs and the quality metrics is a process of continual refinement in order to ultimately achieve an optimal set of quality rules.

Automation of MDM: tooling

There is specific MDM tooling by means of which the quality of master data can be efficiently and effectively guaranteed. Nowadays, the functionalities of MDM tooling are oriented towards a broad spectrum of components within MDM, but their origin often comes from focus on data quality and data integration.

The MDM tooling functionalities mentioned in Figure 2 can be grouped into three different MDM tooling categories, namely:

• Data Quality Tooling: this tooling is specifically directed towards managing and monitoring of data quality.
• Data Integration Tooling: extracting, transforming and loading (ETL) are key elements of this tooling.
• Data Governance Tooling: the control of ownership and of the master data maintenance process is the central aspect of this tooling.

Figure 2. Various MDM tooling functionalities.

Think before you act

There is a growing interest in MDM tooling. MDM tooling is used and misused as a solution for effective MDM. It is important, first of all, to define the needs, specific requirements and scope of MDM tooling, since this is not the solution, but rather the means to arrive to a solution.

Within many organizations, the following issues can be identified:

• MDM tooling does not meet actual requirements, and is therefore seldom used.
• MDM tooling is applied without a number of preconditions being defined and implemented, such as clear master data definitions and quality standards for data quality monitoring, and an adequately defined workflow maintenance process.

For these reasons, an organization best at least have clarity on the following topics before taking decisions relating to the acquisition and implementation of MDM tooling:

• A business case should be prepared before the acquisition of MDM tooling. Is the purchase of MDM tooling truly necessary? Is there a real business need? Isn’t it enough to have a good design of the MDM process, access rights in the systems and the use of working instructions? Also take into consideration the usage of cheaper (temporary) alternatives, such as the use of spreadsheet applications with built-in validations for the creation of request forms.
• Which functionalities does MDM tooling need to have? It is important to know whether the tooling is needed in the back end (to monitor data quality, data integration) or in the front end (workflow, maintenance processes).
• The organization may already be using the ‘best practices’ regarding MDM tooling. Therefore, an inventory of such practices would be appropriate, since it may well be the case that MDM tooling is already being used within other business units for similar purposes.

Suitable master data tooling

It is important that the choice of IT tooling fits in with the IT architecture of the organization. The MDM tooling must fit in with the currently existing IT-architecture principles, which should take into account the complexity of implementing in particular data integration tooling.

Within the general IT architecture, MDM tooling can be deployed to support either wholly or partly one of the following architecture types (or a combination of them). It is important to find out which MDM architecture fits in best with the MDM goals of the organization and which existing technique is capable of realizing the features of the MDM architecture. For this purpose, it is not always necessary to buy and implement a new ‘MDM package’. A distinction can be made into three types of MDM tooling:

• Consolidation. Identification and consolidation of similar or identical objects across a heterogeneous landscape in a centralized master data database, and the supply of relevant key mapping information to be used by the business for reporting purposes.
• Harmonization. The consolidated master data is also distributed to the target system. The relevant attributes are synchronized throughout the entire IT landscape.
• Centralization. There is only one place for data entry and data is automatically distributed to the target systems. In the target systems, the data can be enriched with local attributes.

Figure 3. Representation of three types of MDM architectures.

Conclusion

This article describes three points of concern that organizations experience as being complex when configuring adequate MDM. This summarizes three important conclusions:

• ‘The numbers tell the tale.’ An objective insight into the quality of master data and MDM is of the utmost importance to be able to manage, improve and determine whether or not the business requirements are being met. If used properly, it can serve as the engine behind MDM.
• The field of master data is a multidisciplinary one (business and IT), which means on one hand, that you must establish governance (such as ownership), and also that you must encourage experts from the business and IT worlds to collaborate to ensure the quality of master data.
• The MDM pillars (governance, processes, content & quality, systems & tooling) should receive joint attention in order to realize effective MDM. Before proceeding to the implementation phase (tooling or processes, for example), it is important to consider the steps that need to be taken, the consistency, priority and sequence (‘roadmapping’).