In today's world where many businesses and organisations are truly global and strategic moves need to be thought of on a global scale, the need to view business information at an enterprise level is becoming even more critical.

A deeper look at the need to have an enterprise view highlights that master data is one of the pivotal elements to address in order to ensure business processes integrate in a seamless manner. Krishnan Raman identifies seven critical roadblocks in the path towards a successful MDM implementation and provides some useful tips to thwart them and set the stage for a successful MDM implementation.

Treating master data as a trivial technical issue is perhaps the biggest mistake an architect can make, with the impact often only recognised when business users shun solutions as untrustworthy and discover how those insignificant identifiers and attributes have rendered multi-million dollar solutions ineffective.

Master data management is finally getting the attention it deserves. Until recently, master data, which forms the foundation of any enterprise business or IT initiative, was never discussed holistically when organisations initiated multi-million dollar initiatives, be it CRM, supply chain integration / optimisation, data warehousing / business intelligence (DW/BI) or other integration-related programmes.

Yet, one of the prime reasons why many of these initiatives were not delivering the expected value was because the foundation master data was improper and incomplete. Quick-fix solutions were sometimes being applied as a 'band aid' to go live with but these temporary mechanisms simply introduce additional complexity into the overall architecture. And, while a lot of MDM initiatives did indeed take off, many are unfortunately driven by the IT team and with a technology-focused approach.

While a few organisations have progressed through setting up information governance processes, very few have actually managed to integrate these data governance programmes into their core business processes (with business ownership). I believe this to be the cornerstone for solving data governance issues and that success of the integration can be ensured by assisting change management and ensuring adoption by business.

Seven MDM hurdles

Figure 1. Seven MDM hurdles

The seven critical roadblocks we see in the path towards a successful MDM implementation have been highlighted in Figure 1 and each one of them is detailed below.

1. Absent business vision

When you analyse various failed MDM initiatives, one of the often-repeated elements is the lack of a clear-cut business vision. While quantifying the business benefits you can see they accrue indirectly through multiple other business initiatives (like Customer 360, supplier analytics etc.) as well as through technology initiatives (like SOA, interfaces consolidation etc.). It is, therefore, imperative to have a clear business vision (even if it is non-quantitative) for the overall initiative.

Experience suggests that rather than focusing on potential cost reduction, customers should focus on true business enhancement drivers (like the ability to cross-sell, up-sell, do product portfolio analysis, targeted promotions, spend analytics, customer service etc) that ultimately get enhanced by the MDM programme.

2. Relegating master data management to the IT department

In many enterprises we find that master data is treated as a technical need to run the various applications and, hence, the IT department gets entrusted with the job of maintaining master data. This is wrong as there is no way an IT department can take a call on what attribute definition should be used in the master data. This erroneous mindset is derived from many of the earlier applications, which did not have a structured data entry screen for managing master data.

Now, with the usability of applications changing, the business itself has to take responsibility of managing master data. For example, a tax code that needs to be utilised for a product to ensure appropriate legal reporting is a decision that can and should be taken by the finance department and in no way can it be delegated to the IT department.

It is also important that the business takes ownership for the data governance, stewardship and responsibility for the completeness and accuracy of the master data, leaving some aspects, like consistency of data, once entered in to the system, to the responsibility of the IT department.

3. Underrated data rectification effort

Existing data quality needs to be studied closely when taking up a master data management project. The effort required for this is reasonably high (for example, in some cases we even found dummy data used to test applications present in the MDM repository).

An extensive data profiling exercise (which includes surfacing hidden correlations, integrity violations and definition mismatches) should be carried out as part of the study to ensure that a dimension is sufficiently understood and appropriate effort is estimated for setting this right as a part of the MDM project.

A compromise on this would lead to the MDM initiative going live with inappropriate data, which in turn will cast a negative impression on the solution quality and push it down into a negative spiral, ultimately causing the initiative to fail.

4. Underestimating organisation change management challenges

In any organisation there are typical visible, or in certain cases, invisible political frontiers that exist. Master data that introduces transparency hits at the very foundation of these powerful political lobbies and unsettles many power centres. As a result of this it faces extremely strong resistance from multiple sources. This needs to be recognised at the beginning and should be addressed tactfully as well as forcefully by the senior management leading the MDM program.

5. Biting off more than you can chew

Once the MDM programme is underway, the team involved tends to take a lighter view of the challenges and become over-ambitious while setting goals. This can lead to disillusionment when targets are not immediately met. Pragmatic planning, after appreciating the various limitations, becomes one of the cornerstones for success.

There are many decisions that need to be taken along the way, such as whether to have the MDM from an analytical perspective without affecting the operational aspects, or to have an intrusive implementation model, like a registry model, or a non-intrusive one, like co-existence. What seems to work best are those approaches that do not over-complicate the situation and help the programme take off with the right trajectory.

6. Flexibility and scalability of the architecture

There are many reasons for MDM solutions to be built and continuously refined on an ongoing basis, which place immense demands on flexibility in the architecture. In many cases we find that while master data hubs start off as simple repositories for master data, over time, with mature services-oriented principles getting incorporated and a holistic view of the enterprise architecture being taken, the master data applications start to become mission-critical.

The scalability of the architecture becomes important and they become the heart of the entire technical architecture. One of the interesting ways in which organisations have attacked this need is by consciously planning for solution abandonment. There are many cases where organisations decide on implementing inexpensive solutions that take care of the immediate pain area, with a clear vision, while not losing track of the fact that these solutions would be phased out when more appropriate solutions roll in.

7. Ensuring efficient ongoing operations support effort

MDM is a continuous programme and it requires ongoing efforts to maintain it, to ensure that it continues to deliver value. Often customers either underrate or overlook this less flamboyant work and the investment required to keep the master data in good shape. It is important to plan for ongoing 'lights-on' processes and teams that would maintain the master data.

Equally important is to plan for structured audits of master data on a periodic basis. The timescale of these audits should depend on the velocity of change expected in the master data. For example, a channel master would have a low velocity of change, whereas a customer master will have a very high velocity of change, which needs reviewing far more often.

Being aware of these seven critical roadblocks in MDM implementations will certainly help organisations negotiate through an MDM implementation with minimum delays and a reduced chance of an expensive accident.

Krishnan Raman is a general manager with the business intelligence practice at MindTree, and currently heads the master data management practice.