| QUESTION & ANSWER |
Selling master data management internally? Think like a CEO, Gartner advises |
 |
By Hannah Smalltree, Site Editor
05 Oct 2007 | SearchDataManagement.com |
|
|
Master data management (MDM) is not an easy concept to sell to business people. Attendees at industry events such as the recent Gartner MDM Summit reported that while they understand the benefits of MDM, it's often difficult to sell the concept to business people and executives. That is a problem, because executive support and organization-wide cooperation are critical for successful MDM projects, according to experts.
At the Gartner Inc.'s MDM Summit, SearchDataManagement.com sat down with John Radcliffe, research vice president with the Stamford, Conn.-based analyst firm and asked him about this issue.SearchDataManagement.com: How do you describe MDM in layman's terms?
John Radcliffe: It's basically the governance, the authorship, the custodianship, the sharing and publishing of the core data that runs your business -- or potentially runs not just your business but your partners' business, as well. The way in which you do that might be very workflow oriented or, in other circumstances, very transaction oriented. There would be different dynamics of how your organization might need and want to manage that core data, depending on the data that's most important to you. Technology is just an enabler for MDM.
How should people explain MDM to executives or others in an organization?
Radcliffe: I think MDM as a term might have some problems. In one way, it's unifying. Historically we've had customer data integration and product information management. They've grown up in silos for good reasons. But now we're trying to think of a more umbrella term and more holistic strategy and we're calling that MDM. So, MDM is good in that it's starting to bring people onto the same page.
But, think about it this way. If you were a CEO and you looked in an airline magazine and it said, 'everybody is creating a 'single view of the customer,' so they can be customer-centric' – you, the CEO, would think, 'I can see the need for that to help me be more customer-centric and provide all that growth I promised shareholders.'
'Master data management' is probably never going to get into that airline magazine. So, if an IT person comes to a CEO and says, 'We need to do master data management, it's going to transform the company.' You'd think, 'MDM? It sounds like plumbing. It sounds like IT. I have more important business objectives to worry about. Go away.'
There is a risk with this MDM term that on one side it's unifying, but on the other side it's too nerdy. More IT people are getting interested in MDM, owning these projects and trying to get the initiative going in the organization. But there's potentially a disconnect. Businesspeople might just not be getting it because of terminology.
So, how can IT professionals more effectively explain MDM to business people? Are there questions they can ask or things they can say to help business people understand how MDM could help them?
Radcliffe: Find out what the business drivers are for the business people. Effectively, you need to start at the very top of the organization. Think about what the company is trying to do. What is the CEO and board's vision for the organization? Is it operational excellence, product differentiation or customer intimacy -- or what combination of these factors is it?
After understanding that, go down to stakeholders and line of business managers and say, 'You play a role in that goal, so what does that mean to you? What are your goals and what are your pain points?' And, then see how you can help in that. But, by the nature of it, MDM needs to be enterprise-wide. So you need to try to work at a level above the line of business people, because they could be just interested in their silo. But you should be able to work with them and help them articulate what MDM could mean for them. Ask not only, 'What are your pain points and priorities?' but also, crucially, 'What would be the business benefit to you?'
Part of it is transferal of ownership of the MDM challenge. Instead of someone in IT trying to quantify the potential business gain of MDM and effectively being the owner of the quantification, get the business leader to quantify it. Once [that business leader] buys into it and gets enthusiastic about it, he becomes the person spreading that MDM gospel around the organization.
It's also important to note that the MDM program that is fit for one organization may not be fit for another organization. There are different domains [customer, product, etc.], of course, but you need to think in terms of the structure of an organization. Is it a centrally-controlled organization where they have standard processes across every department and every operating company? Is it a holding company where there's an IT group trying to pull together the common threads from all of these lines of business or potentially even different companies? Or is there a lot of local autonomy in regions or countries? You have to look at how the company is organized and consider, 'Where is the control? How coherent is that control? How much distribution is there of that of control?'
Think all that through before you decide how you can help the organization, because you could come to a conference or read something and think MDM is all about central control. But, you could be horribly wrong because that version of MDM is totally inconsistent with how your company actually operates. You could choose a product which is very fit for that purpose, but it's actually the wrong product for your organization. And then, the project could grind to a halt because the nature of the organization, and its politics, are totally against you.
You shouldn't be starting with the technology. You should be starting with understanding the nature of the organization and the business vision. Think: Where are the pain points and how can we help with that? Gather that and synthesize it. Then you can say, 'This is the macro picture' and move to 'How do we prioritize these different things?'
|
|
|
|
