Top 5 Mistakes in Master Data, part 1

Master Data Management (MDM) is not a new concept or practice within the context of IT, it has been around in one form or another since the late 1990's. Despite a very compelling value proposition and a wide variety of sophisticated tools and practitioners, MDM never achieved the market penetration or levels of success associated with other similar IT practice areas.

There are a number of reasons why MDM never really took off, including but not limited to:

• The relative complexity of most Master Data projects and products
• Lack of clear relationship between better master data solutions and return on investment
• A lack of understanding across industry in regards to master data best practices

However, to understand why Master Data Management is on the periphery of most organizations' priority lists, it is perhaps instructive to take a deeper dive into why many MDM projects run into trouble. Based on more than a decade of working in or along with major MDM initiatives, we can easily identify the top 5 mistakes or challenges associated with typical MDM projects:

• Lack of recognition that the project is actually Master Data focused
• Limiting or skipping the initial assessment phase, which in all instances requires a data profiling exercise
• Lack of recognition of or focus on MDM integration impacts across the larger data stack, including performance considerations
• Incomplete or unaligned Governance paradigm
• Non-contextual application of business rules

1 - Lack of MDM Awareness

Fully more than half of the projects organizations engage in that involve Master Data fail to actually recognize that they are in fact Master Data projects. In many cases, the focus or premise of these types of projects is considered to be Data Warehouses, Marts, or ETL and even Big Data. Yet within each of these types of efforts there is often a good deal of Master Data - sometimes it is acknowledged as such even though it isn't considered an MDM project per se. Other times the fact that master data is involved appears quite irrelevant to the initiative. While it may seem intuitive that working with Master Data without considering that the project requires some form of Master Data Management is highly problematic, this is actually a fairly common situation. This also tends to beg an important question - what exactly does the term Master Data or the practice of Master Data Management actually represent?

The official Wikipedia definitions are as follows:

• Master Data represents the business objects which are agreed on and shared across the enterprise. It can cover relatively static reference data, transactional, unstructured, analytical, hierarchical and meta data.
• Master Data Management (MDM) comprises the processes, governance, policies, standards and tools that consistently define and manage the critical data of an organization to provide a single point of reference. Master data management has the objective of providing processes for collecting, aggregating, matching, consolidating, quality-assuring, persisting and distributing such data throughout an organization to ensure consistency and control in the ongoing maintenance and application use of this information.

So, what happens if an organization doesn't acknowledge that it is actually working with Master Data? And perhaps more importantly, how do you deal with a project that isn't only focused on Master Data yet has a critical Master Data Component embedded within? We will delve further into those questions in part 2 of this article.

Copyright 2017, Semantech Inc.