Master data management (MDM) has risen to the top of many IT agendas, and it's hardly surprising, given that it creates an underpinning for data initiatives, ensuring uniformity and accuracy of data, and providing a foundation for the enduring problem of data quality and consistency.
MDM also ensures that CRM initiatives achieve the desired outcome, and that the right John Smith receives a marketing communication, and that if he already has a Platinum card he is not offered a Gold one.
But the market is still awash with misconceptions regarding MDM, despite Gartner's elegant definition of MDM as “a technology-enabled discipline that ensures the uniformity, accuracy, stewardship and semantic consistency of an enterprise's official, shared master data assets”.
It is worth working through each element of this definition, as it tells the full story, but many companies might still go down the wrong route if they don't consider the following five issues:
1. MDM is a business, not an IT initiative. There are many initiatives that arise from IT that in fact belong in the boardroom. Ownership, sponsorship and governance around these initiatives have executive consequences, so they should arise from, be driven by and ultimately championed by the boardroom. Think of enterprise architecture and corporate governance, and it is clear that these are boardroom issues, and so is MDM. As data arises from business processes, and business process ownership resides in the boardroom, data ownership must also reside in the boardroom. To ensure that ownership flows from the boardroom to IT, it is necessary to create, project and fulfil a business case.
2. MDM is not a once-off technology project. Again MDM bears comparison with enterprise architecture. Both are lifelong initiatives, once begun, never stopped. They are journeys, rather than destinations, and they yield long-term, rather than short-term benefits. MDM permanently changes the way organisations gather, categorise, sort, store and manipulate data. In addition, anyone approaching MDM as a technology rather than business process issue is going to fail to maximise business value. It is worth noting that MDM per se is not one massive project, but many individual, discrete projects.
3. An operational data store or ERP system do not obviate the need for MDM. In fact, if anything, an ERP system is such a driver of corporate data that it should be a driver of MDM. Data quality, data integrity and data profiling are not subsumed within either an operational data store of an ERP implementation, but they form critical components of MDM, either as a foundation, or an outflow of MDM. And anyone who thinks a data store, or enterprise-wide data warehouse removes the need for MDM, hasn't understood what MDM is about.
4. MDM is for all organisations. As with enterprise architecture or corporate governance, MDM is not necessarily only for very large companies, such as financial services giants, even if they are typically sold to such organisations. In fact, these disciplines apply equally to all companies, and when they are applied early in the process, the benefits flow from day one, and less corrective action is required. MDM is a vital discipline, best introduced early on, when a company is small or being founded, or its data requirements can easily be defined and controlled.
5. MDM does not have to be an omnibus, rip-and-replace exercise or process. It can be done by department, subject area or domain as per pressing business need. Pain points are always where one begins a major exercise, process or long-term initiative, so the area of the greatest pain or need should be where such an exercise begins.
MDM is not an option. It is one of those exercises that should have been conducted by companies a long time ago, but it's never too late. Begin now, operate strategically, ensure buy-in and ownership from the boardroom, and never stop the process once it has begun. These are the keys to long-term MDM success.
Share