dcsimg

MDM's Value? It's the Customer, Stupid

SHARE
Share it on Twitter  
Share it on Facebook  
Share it on Linked in  
Email  

Remember "It's the economy, stupid," from the 1990s? For those youngsters out there, it was a blunt message, coined by the ever-entertaining Democratic political strategist James Carville, during Bill Clinton's 1992 presidential bid against incumbent President George Bush.

 

I couldn't help but think of that phrase, with a minor variation, while reading a dense Information Management article about how to find the business value when you're pursuing a master data management program.

 

The author, Edwin D'Cruz, is a principal at Princeton Data Solutions, and this is the third in a series of pieces looking at managing data in the enterprise. He suggests examining "the key functions and processes that such a program would have a positive impact on," and goes through several questions you should contemplate before suggesting the following:

The sales and marketing functions revolving around the customer are critical to the business, and any enhancement to this capability can be of great value to the organization. Any MDM program will need to focus on providing greater insight into customer behavior, enhancing the customer experience, the ability to identify patterns around the customer, and opportunities to identify new customers and grow the customer base. Most importantly, the program needs to provide a consistent and reliable source of customer information across the enterprise.

Or, to put it briefly: It's the customer, stupid.

 

If you want to trace down the value of MDM-and possibly most initiatives-you're going to have to focus on help with the customer. And when it comes to MDM, there's actually quite a case to be made around identifying, cleansing and governing customer data. That's probably why many MDM solutions actually evolved from solutions developed just for customer data integration.

 

One thing D'Cruz doesn't cover is just how hard it can be to even define "customer" during MDM. For instance, sales tends to view "customer" very differently than marketing or even billing. He spends much of the article discussing this, but he also hits on two often-overlooked stumbling blocks for MDM: data governance and metadata. If you're going to succeed with MDM, you'd do well to heed his advice and include these in the project.

 

 

He suggests bringing in the data steward or stewardship team to oversee data governance. Honestly, I think that if you've gotten as far as MDM it's definitely time to move beyond data stewardship and consider an Integration Competency Center (ICC). I base this not on my own opinion-which is useless-but on the many conversations I've had with experts about the value of ICCs and the complications of MDM.

That may seem odd if you don't understand how much integration work MDM entails. As analyst Robin Bloor-who's a sort of "Carville" for the integration set-recently said:

What I don't subscribe to is the idea that a large MDM project will deliver anything more maintainable than a pragmatic series of data integration projects that are aimed at specific targets. Indeed, from what I've seen, it is likely to deliver far less.

An ICC will bring together all your data stewards, as well as lessons learned from your other integration projects, for a nice conversation about best practices that you can then apply to MDM.

It's also tempting to confuse MDM programs with an MDM technology solution. Don't. As D'Cruz warns:

While packaged products are a viable means of quickly implementing a solution, it is worth noting that some products are more customizable than others. This can sometimes limit the optimal implementation of an MDM solution. Most products offer a set of entities related to the customer function, but there needs to be a certain amount of extensibility to the schema. Some products allow for this. Others require numerous configuration changes and limit the ease of use, which is important. These are reasons why some organizations build homegrown solutions to suit their needs.

As for the metadata, if you'd like to read more about how that works with MDM, I think Evan Levy of Baseline Consulting did a great job of explaining that during an interview earlier this year:

The reason metadata is important is, if I have two files, how do I link them? Metadata is going to tell you which columns mean which things. Without metadata, it's like looking in a medicine cabinet with a bunch of unlabeled bottles. Unfortunately, with databases we feel that somehow people are supposed to be able to figure that out. That's what's so ridiculous.

You can read my interviews with Levy regarding , as well as its role in integration and MDM, for more information.

NewsletterITBUSINESSEDGE DAILY NEWSLETTER

SUBSCRIBE TO OUR DAILY EDGE NEWSLETTERS