Eating the Elephant One Bite at a Time - MDM and Data Quality

By Jon Asprey, Director, Strategic Consulting EMEA, Harte-Hanks Trillium Software

How do you eat an elephant? One bite at a time of course. It’s a well known phrase and a philosophy often cited in management. Defining and implementing an MDM solution can be a risky and complex programme which is only partly dependent on technology to be successful.

From my experiences of engaging with our customers, those implementing MDM one bite at a time are riding the smoother path to success. Now this may sound an obvious way to proceed but some organisations are suffering by failing to adhere to the basic principle of understanding and meeting the (data) users’ needs.

I have seen many cases where a data “master” has been defined with little consideration for the quality of data held or the intended downstream uses of that data. To create a true “master” source that can serve a multitude of business needs and stakeholders, business analysis must be done first. This requires focusing on a defined set (or subset) of master data for the initial project and includes making a clear business case based on the improvements to be realised. By targeting efforts in this way, uncovering the true needs of the business becomes more manageable and a robust business case can be built.

Initially the focus of MDM is defined by data domain, with many organisations targeting customer data in their first project, although supplier, asset and product are also common. At this point it is often sensible to sub-divide data into smaller data sets. For example “customer” may be broken down into residential and commercial customers with one sub-set “mastered” in a pilot MDM project. The rationale for the break can vary, relating to a number of points that favour one sub-set over another:
•    Higher business priority/value
•    Smaller data volume (more manageable)
•    Less complex business process, therefore less stakeholders and less complex requirements

One point to note here is that residential customer data may have very different standards, matching (duplication) rules and business processes compared to a commercial customer. Therefore “customer” data must be subdivided to enable the business to have a sensible discussion on what standards and requirements the customer master must satisfy.

Geography can also prove to be an effective way to sub-divide data for a pilot, for example a business in the United Kingdom may have a customer base in the Republic of Ireland which is representative but much more manageable (in size) as a proof point. Of course there may be some regional differences in the customer data but the high level principles remain the same.

Breaking up the MDM elephant into manageable bites allows the implementation to gain momentum. A success in one domain, proven with return on investment figures and managerial commendations, does a great deal to win interest from leaders of other domains.

Of course, there’s no one route to success. It depends on your company and your people and culture. Perhaps you’d like to share what you’ve experienced? Have you already embarked on and MDM project? How did you approach it and what worked/didn’t work?