Mastering Data Management

More in Business Process Management

• New ebook: Understanding Big Data
• 37 Definitions of “Employee ID”
• Defining Terms: Agree, or Doom your Project
• Establishing a Valid Business “Need to Know” for Sensitive Data

More in MDM

• Best Practices in Test Data Management: Discovering and Subsetting
• TDWI Chicago Preview: Data Warehousing, Analytics & More
• Who’s Afraid of the Big Bad Data?
• MDM for Chief Privacy Officers: A healthcare provider example

More from Lawrence Dubov

• MDM Vs Data Governance: History and 8 Predictions
• What’s Harder: Starting or Sustaining MDM?
• Conclusion: Quantifying Assets
• 3 Essential Questions for Data Quality: Benchmarks, Penalties & Latency

Share this Post

Recent Comments

• ICMCC News Page » Where East Meets West: ehealth in China and the US on Where East Meets West: ehealth in China and the US
• Kim’s Training Podcast on Training as a Safety Net: Kim May
• TDWI Chicago Preview: Data Warehousing, Analytics & More | Mastering Data Management on New ebook: Understanding Big Data

Our first stop on our MDM Roadmap trip is at the business benefits domain

In previous posts, we’ve examined the whys of building an MDM roadmap, as well as the costs of MDM. Beginning this week, we’ll dig into each of the 20 domains of MDM, exploring their relative merits.

Let’s begin with business benefits and systems and applications.

1. Business Benefits

The business benefits domain tops the list of the roadmap domains. Just as a profound business case cannot be considered complete without a sound roadmap that determines the primary cost parameters, the reverse statement is also valid.

An MDM roadmap should consider business benefits by release or implementation phase. MDM stakeholders want to know what groups will benefit from the program, how and when.

Some groups may be enthusiastic about the coming change promised by MDM. Some others can be cautious and even reluctant to accept the coming changes and the new business processes enabled by MDM.

The reluctance to adopt MDM represents a risk for the initiative and the motivations of this reluctance need to be understood. Business benefits, their priorities and timing can indirectly impact the costs.

For instance, if the initial phase of the initiative is focused on marketing, this focus is an indication that an analytical MDM solution will be implemented. The cost and implementation risks of an analytical MDM are typically lower than those for an operational MDM.

We will focus on this aspect later in the discussion of the Data Hub Usage Style roadmap domain.

2. Systems and Applications

It is not unusual to have 20-40 systems - and even more- in the scope of a long-term integration. Significant cost savings can be achieved by standardizing on-boarding procedures among these systems.

Defining a finite number of standard systems on-boarding procedures that the enterprise will leverage for MDM integration is helpful for overcoming several challenges, including:

• Latency requirements
• Data exchange attributes
• Merge and split requirements
• Other solution

Once these standard procedures are established during the first MDM implementation phase, they can be re-used to greatly contain the cost of the consequent phases. The enterprise cannot afford a scenario when every additional system is integrated with the data hub as an independent project that does not leverage previously developed systems’ on-boarding procedures, standards and techniques.

Next post, we’ll cover one of the biggest aspects of your MDM roadmap: Data Domains, Entities and High-Level Data Models.

This is part of a series, Building an MDM Roadmap. For other posts and a complete index, view the Table of Contents.