Richard Ordowich, a principal consultant at Knowledge Integrity, shared a story with TotalCIO blogger Linda Tucci of an insurance company he encountered where the CIO and CEO didn't quite get that whole "identifying business needs" first part of solving data problems:
I worked with a large insurance company and met with their CEO and asked him what his information needs were and his response was that his CIO told him they needed master data management! Further conversation with the CEO revealed that the company needed increased real-time data to quickly estimate their policy premiums and analyze their risks as claims were filed. The CIO sat there, dumbfounded, and began talking about how they were working on enterprise architecture!
That actually pained me the first time I read it.
This seems to be a lesson we have to relearn with every new business trend that involves technology, and mater data management is no exception. On the contrary, it's a perfect example of this weird phenomena, because MDM is considered a discipline, and yet, the discussion usually starts with a technology solution. This even though the "rule of thumb" for MDM projects is they should be a mere 20 percent technology, and 80 percent new processes, according to "Untangling Your Unruly Data," a recent ComputerWorld feature on MDM.
In its heyday, MDM could be sold for MDM's sake. It was the solution for conflicting master data, and even though the costs could run into the millions, large enterprises embraced it because their needs were clear: They needed to reconcile their various data on customers to find out who their customers really were and, among other things, where they really lived.
But as MDM has found it's way out of the Fortune 100 or Fortune 500 and off the peak of the hype cycle-not to mention since the recession became a factor - organizations are demanding more business-specific justifications and proof that their MDM investments will pay off. What's more, MDM is being applied to broader areas of data, including suppliers, products, employees and other business-critical information.
All of which means that even if MDM seems like a no-brainer, you're going to have to demonstrate a business case in terms the business can understand.
Or, as Gartner analyst Bill Swanton says in the ComputerWorld article, "There is no such thing as an MDM project-there are only business projects where MDM is part of the solution."
I love this article because it provides plenty of examples of how MDM can address common business problems and how you can translate MDM for business users. Here's a hint: Telling them it provides a "360-degree view of the customer" isn't as clear and useful as you might think. Those new to the concept of MDM will also find a useful and business-friendly explanation of it.