Master data management can be difficult to deliver. Successful implementations avoid these mistakes

Mistake 1. Overanalyzing the Requirements

Successful MDM implementations provide value by helping identify opportunities or addressing challenges. There is evidence that MDM implementations have always delivered much more value than expected once the business analysis and requirements are done responsibly by a requirements analyst. As MDM implementations take on more of a business initiative role rather than a technical one, there is a high probablity that the requirements-gathering activities reach the overanalysis or process-perfection mode. This situation should be well identified and addressed by a requirements analyst. One way of achieving this is to present the findings from the requirements-gathering workshops to senior executives to ensure that common understanding is maintained. Also, this will help reach a common consensus about an overall roadmap and establish next-step priorities based on business value and feasibility.

Successful MDM implementations have a niche role even today, though there is a strong wave of companies are getting serious about its adoption. However, there are few best practices and end-to-end success stories being circulated. People are still skeptical about MDM’s returns. This should explain why the requirements-gathering initiative for MDM needs careful handling.

While owners and stakeholders have every right to seek perfection in their projects, the downside is that it is not a realistic or practical approach for accomplishing "successful" projects. Owners and stakeholders need to understand the ramifications of their decisions when they do so.

Mistake 2. Starting the Project Without the Big Picture in Mind

Starting MDM projects and initiatives without the big picture in mind might lead to unsatisfied stakeholders, an inefficiently built system and of the large amount of rework required to make it efficient.

The best way to approach the MDM implementation would be to do it phase by phase. Once the big picture is visualized and agreed upon at the enterprise level, different phases and its goals can be easily defined and achieved. Ideally: Phase one can bring key selected interfaces and or applications into the MDM data store. It could also address propagation of this master data between legacy applications, ERP and/or business partner systems. Phase two might extend the scope of phase one by increasing the number of target systems and master data applications.

Once the success and utility of the phase one and two are clearly visible and measurable, the third phase could add more supplier systems, adding and deploying people as well. This would take shape as the true enterprise master data store.

Mistake 3. Ignoring the MDM Data Modeling Approach to Be Object-Oriented

Choosing the right data modeling approach for the MDM is a very important design decision. The basic data modeling question is  “How flat or how hierarchical should the model be?” Based on the answer, which should be obtained from business, various modeling options can be explored. For instance, the model may be relational if the focus is on nonanalytic data. The model could be multidimensional if the focus is on analytic data. The model might be hierarchical for financial data or entities, which require rollups and aggregations, and the model could be flat if it’s more for operational data to get lists. The style of modeling should be selected based on the business driver.

Master data collection is the collection of data from identified and potential sources or front-office systems like customer relationship management. It brings this data into the master data store and allows the designated users to modify and maintain this master record when required with governance around it. Because modifying and maintaining the master data is critical, the data modeling should be more object-oriented and not purely relational-model driven. The main reason is because common protocols like XML have strongly incorporated hierarchical models that objects can represent easily. Because the business entities have mostly hierarchical and multidimensional relationships, MDM is best served with the object-oriented data modeling. Data modeling should be more user-interface driven than database driven.

Mistake 4. Restricting the MDM Implementation to Be Only Analytical and Not Operational

MDM and its supporting technologies usually involve some form of data consolidation where data from multiple sources ends up in a single place. The propagation of data that facilitates movement and the federation of data that enables one view of all the information that an enterprise needs to either integrate and/or analyze is the core principle of MDM. Because serious CRM capabilities are enabled with MDM. The overall implementation message should be to pursue a holistic data/analysis strategy that begins with strategic and operational objectives that enable specific customer planning, servicing and optimizations. It should never be assumed that Master data stores should behave like data warehouses. The purpose of both systems is very different. The MDM is always a combination of operational and historical data. Analytics should be carefully planned on these systems, leveraging the versioning and audit trail capabilities. The strategy of analytics performed on data warehouses and the BI domain is quite different from the nature of analytics one would do with MDM systems.

Mistake 5. Underestimating the “Political” Dimension in MDM Delivery

In the triangle of people, process and technology, I would imagine the technology part is the easiest to handle. MDM success revolves around business taking ownership of MDM and IT facilitating it. Hence, at every given point there will be the ingredient called “politics.” This aspect should not be underestimated or ignored. The program managers in particular, who are responsible for delivering the scope, should have strong leadership skills to handle internal and external politics. Different people have different priorities, but they all need to be viewed through a common lens and evaluated by what is practically possible and what tangible business value it will bring in from an enterprise perspective rather than a silo perspective.

This lens should be considered when making decisions and handling everyday activities. For example, a situation where the delivery of the particular phase is divided between multiple vendors, one is forced to get involved in the politics even if no one wants to. This is a simple fact and has nothing to do with MDM or any other implementation for that matter. This is likely when implementing MDM because of the higher stakes and extensive scope and metrics of the project. It is worthwhile to keep decisions straightforward and contain the political aspect as much as possible.

The fact is, MDM deliveries, when done with proper people, process and technology, have always brought in much more value then expected. This is the beauty of MDM.

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