10 Critical Myths and Realities of Master Data Management
Prevalent myths surrounding MDM alongside an explanation of the realities.
Master data management reminds me a bit of that children's book, "If You Give a Mouse a Cookie." One issue seems to just trigger another.https://o1.qnsr.com/log/p.gif?;n=203;c=204663295;s=11915;x=7936;f=201904081034270;u=j;z=TIMESTAMP;a=20410779;e=i
Example: If you decide to do MDM, you're going to need to figure out what master data is. So you're going to have to define what is and isn't master data. And while you're on your way to doing that, you're going to notice that you have customer master data and product master data. And then you're going to have to decide which you want to tackle first or if you want to try a multidomain solution. Once you've decided that, you'll learn there are hundreds of fields you might need to define, and of course, MDM will need to know which ones matter most, so then you'll have to ... I think you get the point.
And all the while, just like our little mouse friend, MDM is racking up quite a toll in costs and time, and before you realize it, you're struggling to demonstrate any sort of return on investment. You won't be alone: Gartner says that for the next four years, 66 percent of organizations that start an MDM program will struggle to demonstrate its business value.
Winston Chen, vice president of strategy and business development for MDM vendor Kalido, suggests one way to limit the scope of master data management is to take a page from politics and use federalist principles in applying MDM.
The concept is simple enough: Instead of going broad with master data management, you need to pick a limited, but clearly defined and significant, set of data to control centrally. Local-or business units, if you prefer-rely on the central MDM system for these important master data items, but otherwise manage the rest themselves.
Suppose, he says, you have two business units: One has 30 attributes for customers while the second has 50. They only have 10 attributes in common. With a federalist approach, the central master data management system would only govern that 10 in common-not the whole 70 attributes, he explains:
The best form of governance governs only as much as needed and no more. As a rule of thumb, go for the intersection, not the union. Maybe even a subset of the intersection.
As an example, he shares how a $50 billion consumer packaged goods (CPG) company used the federalist approach on its product hierarchy to achieve both scale and agility.
Chen points out that another benefit to this approach is that it reduces push back from business units:
It's hard to get buy-in for centrally controlling every attribute. Business units with some degree of autonomy would violently object to handing over control of all their master data to a central authority. Especially when that central authority is IT. Imagine when they need to add an attribute only useful for that business unit, and having to go to corporate IT and get on a queue. It compromises local agility. If they're forced to do so, they'd create a shadow IT organization.
It's a valid point, and perhaps it might go a long way toward resolving the problems IT faces when trying to lead on MDM initiatives.
Plus, I might add, it sounds so much more manageable than a broader approach to MDM. It sounds like something you might actually finish in some knowable amount of time and with a knowable amount of money.