Q&A
Defining Master Data Management
What MDM is, why buy-in is so difficult, and how to successfully launch an MDM initiative
There are many definitions of MDM, but Jill Dyché of Baseline Consulting provides a unique perspective on the topic. From understanding why MDM is gaining traction to moving to executive buy-in, Jill explains the basics of getting started with MDM.
- By Linda L. Briggs
- February 3, 2009
Jill Dyché is a partner and co-founder of Baseline Consulting, where she serves as a combination of best-practice expert, industry gadfly, key client advisor, and all-around thought leader. She is responsible for key client strategies and market analysis in the areas of data governance, business intelligence, master data management, and customer relationship management. We asked Jill to give us her take on what MDM is, why MDM buy-in is difficult, and the biggest problems enterprises have in launching MDM initiatives.
TDWI: Everyone seems to have his or her own definition of master data management. What is yours?
Jill Dyché: Master data management means helping your systems to play nice with their data. That's my definition.
That’s straightforward enough! Why do you think the concept of MDM is gaining so much traction right now?
The first reason is that companies by and large have succeeded with their data warehouses and analytics and are now lifting their heads to look at other types of data -- specifically, at operational data. What we're finding is --- and this proved very true at TDWI’s MDM conference [in Savannah, Georgia in March 2008] -- that BI and data warehousing professionals are asking themselves, “What's next for my corporate data, and, by the way, what's next for me in my career?” As we've been saying over and over, data is bigger than just BI.
Second, I think the reason for MDM’s success is that the technology is finally ready. Until now, companies have been piecing together various software tools and writing custom code. It has involved retrofitting ETL tools, messaging technology, data quality, and matching functions, among other things. It’s been labor-intensive and expensive to implement.
So it's about maturity, about making progress in terms of what we're using data for and how we're looking at data?
Exactly right. Also, remember that the MDM technologies themselves are fairly new. Take a company like Royal Bank of Canada -- they spoke at the MDM event last year. RBC is a bona-fide early adopter of MDM. They were doing MDM before there was a name for it, so they have a very large homegrown infrastructure because the solutions weren’t out there when they needed them.
Today, in contrast, we have application vendors and specialty, purpose-built vendors all offering MDM solutions. The technology is there now for a variety of reasons. It just wasn't available 10 or arguably even five years ago, so there is a renewed interest in it: “Wow, it's a lot easier to do this. We weren’t able to do before because there weren’t packaged technologies on the market.”
I saw a recent blog comment you posted about MDM in which you said the hardest part of an MDM initiative can be getting companies to buy in. Can you expand on that?
Much is being made of getting executive sponsorship and management attention for MDM. The reason it's so challenging is because MDM is harder to explain than analytics and reporting. MDM is infrastructure. It’s processing-intensive, it’s decision-making and policy-making. In many ways it's much more complex. Ergo, the missionary work is more challenging.
Again, we heard attendees last March at the TDWI MDM conference saying things like, “My executives think we already do this. They think that we already have a big core repository of customer data, and why do we need MDM?”
TDWI: What do you say to that?
I’d say you’re not describing MDM correctly if that’s what your stakeholders are hearing. You really have to color in the business benefits. What's MDM going to do for you that you haven't been able to do up until now? Until you can really paint that use case and tell that story, it's going to be a very challenging and confusing pitch to make to executives.
There's been something of a backlash. When our clients call us about MDM, they often say, “We know we need it, we know what it does, we totally get it, we have expertise in-house -- we just don't know how to talk to the business side about it.” It’s turning out that the biggest challenge is in making the pitch.
What's the biggest mistake you see companies making as they're trying to get an MDM initiative off the ground? Is it not explaining it adequately or appropriately?
That would certainly be one of the Big Three.
Another mistake is assuming that the development and requirement process is the same for MDM as it is for other projects. The fact is that the use cases are different. The context for improvement is different. The desired outcome is different.
For example, if I want to understand all of the new customers coming out of a new merger and acquisition program, that's business intelligence. I can load customer records into my data warehouse; I can count the new total and figure out how many new customers I have.
Here’s what master data management will do: It will match all of those customers and reconcile all that data so you'll be able to tell which of those customers already exist in your systems. You can't do that with the data warehouse alone. You’re just putting more customer records in your data warehouse. With MDM, you can actually reconcile all that information before it lands. It could sound very nuanced, but MDM isn't analytics, so we have to start from a different place. You need to say, “This is going to streamline our merger and acquisition process, improve the resulting data, and here's why” instead of “This will help us understand mergers and acquisitions.”
The third mistake is going to the vendors too quickly. It's great to self-educate on MDM through vendor conversations, but we're seeing a lot of companies that say, “Hey, this vendor knows our industry. We're going to go ahead and acquire their solution because they've done work with other banks or other pharma companies.” They’re doing that without really looking at the functions and features of the tool, so they risk over-investing.
Here's another quote from that same blog posting that I referred to earlier. You said MDM's success is often directly tied to a company's specific definition of what MDM should be. Does that mean companies are defining MDM for themselves? Is that a good or a bad thing?
It's a good thing as long as they're right about it. We've seen companies that are refashioning their data warehouses to be MDM servers. If that's going to work for you, then go ahead and call it MDM. As long as it serves the purpose and adds value, go for it. Or you might have a data hub that specializes in match and link and that's all it does -- fine, call that MDM. Just know what you need it to do. You can label it however you want.
What we find is similar to what we saw a few years ago with BI. It's another boil-the-ocean issue. “My MDM hub is going to be as a dessert topping and a floor wax.” That’s where companies get into trouble. We encourage our clients to brand their MDM effort and say, “Here is what it's going to be.” If it's some sort of awkward combination of incumbent technologies but it's going to work and it's going to save you time and money, great. Just articulate the desired outcome and communicate it.
That defining process narrows the scope and focuses companies in on what they really want MDM to do.
Exactly, and that's a good thing because the MDM market is still -- credit to the vendors on this one -- very noisy. You'll hear, for example, the term “analytical MDM.” That’s very confusing to people because, in fact, it's not analytical MDM -- it's MDM for the consumption of analytic systems. That's a different thing.
The faster we can put a descriptive label on MDM that says what problems we're solving, the better we'll do -- not only at pitching it but at moving forward with implementation. We have a client who should have had their MDM solution built and in production by now, but they keep asking us to come back and present concept to another business organization. We want to say, “Hey, you had your business requirements after our first engagement together. We could have turned around an RFP for you, done a functional mapping with a couple of key vendors, and you'd be in production by now. We could be selling this on its value, not on its promise.
All else being equal, how quickly can companies see results from an MDM initiative?
Actually, very quickly. It depends on the slice of the business problem you're solving. Take that merger and acquisition scenario I described before. A company that acquires a new company every quarter can integrate that acquired company's data in a very short time frame and pay for its MDM investment after just a couple of cycles.
In fact, in many cases, we're finding that value to be almost quicker with MDM than it was for data warehousing. You have your BI tool, your data warehouse platform, your ETL and maybe a data quality tool. You put all these pieces in place and you've got the infrastructure. With MDM, you have a hub and you start bringing existing systems on board and the data starts getting reconciled ... we can launch MDM fairly quickly.
I wanted to ask you about getting started -- I believe you generally recommend doing MDM a piece at a time, such as a department or an area in the company that needs attention. Is that right?
Yes, we recommend doing MDM in small slices. Provide some value; let people look at it and then do your next slice. You'll have even more value, and over time, you'll have that single version of the truth for both operational and analytical systems.
We also recommend that IT do a bit of homework on where the pain is. We often ask our clients, “Where are you bleeding?” The answers are different according to the client and the industry, but it could be the time it takes to integrate a new acquisition, it could be the cost of returned postage, it could be federal regulatory fines. There are many different business cases, so you need to find out where the business thinks the bleeding is and solve that problem first. It can be a very narrowly scoped problem or a subset of a larger problem. Show that success and then move forward.
We're finding that MDM can be a real shot in the arm for, IT You can not only educate the business about it, but solve some problems that have up till now been very difficult to solve very quickly. If you do MDM right, there’s a halo effect.