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

Loraine Lawson

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.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


Add Comment      Leave a comment on this blog post
Sep 27, 2011 6:15 PM Clive Clive  says:

Note the statement:

One thing D'Cruz doesn't cover is just how hard it can be to even define "customer"...

That is because "customers'" do not exist in the core business processes, since the core business processes deal with specific relationships or roles - "customer" is a derived term that can mean many different things and it is up to marketing to decide what relevance the information has. Example - A 'person/customer' can but an airline ticket and the name of the purchaser must match the name on the credit card and the name on the boarding pass must match the passport - two entirely different processes and measurements. Also the two processes may relate to two different addresses - one for the flight details to be sent and the other for the receipt. You don't actually know for certain whether the two people with very similar names are one and the same person and you cannot make assumptions.

The entire concept of a 'customer' for core processes is completely bogus and the habit of imposing this term on business (data) analysis from the outset is one of the main reasons that people foul up business analysis and system design. This happens because people are happier to deal with what they like to call "the real world" rather than paying attention to what is really happening IE the actual business rules.

Own a bank account as a 'customer'? No you don't - the bank owns the account and you sign a contract that makes you liable for monies taken from the account - still the term "customer" is much friendlier than being called the liable party isn't it?

Systems are analysed and developed from the top down and I believe this approach is what causes most of the issues with poorly designed systems. They should be analysed from the bottom up (after a scoping exercise) and you can derive whatever you like from the REAL meaning of the data in question. This problem has dogged IT for years and one failure after another of large systems doesn't seem to have any affect on those that can't see the trees for the forest (yes, I really did say that!).

A lot of this misunderstanding is caused by the comfort factor of being able to talk with business users through a commonly held view of the world. Try looking instead at the contracts that people sign rather than a wooly chat about abstractions and then you will see what the business relationship with the "customer" really is.

All of this has been known for years but it doesn't seem to stop people writing books of complete rubbish on the subject. Rather than IT staff analysing businesses, it's about time someone started to analyse the psychology of the IT staff that blunder from one failed project to another without ever grasping the basics of what they are dealing with.


Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.