The MDM Journey
Enthusiastic proponents of master data management (MDM) like to assert that implementing a master data management (MDM) solution can quickly eliminate discrepancies between siloed customer and product data in very short order. Organizations undertaking MDM initiatives quickly find, that while timelines vary based on the project, MDM aren't simple technology exercises. Master data management is an ongoing process that requires the realignment of people and process to ensure that data, once cleaned and standardized, stays that way permanently. Which is why it's so important to create a plan for rolling out the MDM initiative throughout the entire organization in advance.
The fact is a technology-centric approach to MDM is not workable primarily because messy data nearly always induces multiple business problems that cascade across the organization. When an organization initiates an MDM project to solve one or two well-defined business problems, it is then far easier to turn the solution -- and apply lessons learned -- toward addressing the next business problem. For example, a financial services company that uses MDM initially to improve compliance reporting could easily refocus on solving issues in optimizing the allocation and alignment of marketing and sales resources. Had the same company initially focused on resolving master data issues within a single data warehouse, the ability to quickly change focus would depend entirely on the compatibility of the underlying technological resources.
For organizations that have already enjoyed success with their initial MDM efforts, the question becomes how can the lessons learned be leveraged to drive more effective data governance across other lines of business. Recently, many IT analysts and industry observers have authored articles setting forth roadmaps for taking MDM implementations from the early planning stages through to mature, second or third generation stages. Many of them advocate an incremental approach, usually based on a particular data type or within a single system, such as a data warehouse. Others advocate targeting a single architectural style then building on that implementation to address other styles, such as collaborative, transaction or hybrid. The reasoning behind this type of architecture-centric approach follows a conservative "technology maturity curve" as a way to keep data governance requirements in check and risk of failure as low as possible.
It's certainly a legitimate approach, and many organizations have used it to realize modest gains in solving their master data problems. Purposely limiting the scope of your initial MDM implementation, however, is also likely to constrict the potential for greater success and greater return on investment down the road. The ultimate promise of MDM is that it produces a single, clean and correct version of its most important reference data within the enterprise, and eliminates the business process inefficiencies that arise from conflicts in various data sources. By organizing MDM implementations around specific business problems -- such as compliance, business process optimization, customer on-boarding, risk management and so forth -- reaching the ultimate "single, clean and correct" stage is a far more straightforward exercise.
MDM implementations organized around specific business problems rather than narrow technological concerns put the organization in a far better position to expand and build on its early successes. With a business-focused approach to MDM, the organization can deploy a complete solution rather than an incremental one. The approach itself is still incremental -- aimed at solving a circumscribed business problem -- but you are also putting in place the complete set of tools needed to solve larger master data issues. Additionally, your data stewards and other stakeholders gain crucial knowledge and experience with solution tools and MDM best practices. As with an incremental technology-based approach, success and ROI can still be shown and documented before the solution is broadened to other lines of business. But the stage is also being set for the organization to realize larger benefits made possible with a true enterprise-level MDM solution.
Lean on Lessons Learned
For those companies contemplating an MDM initiative or exploring MDM strategies, a beneficial exercise is to speak with early adopters and tap their knowledge of what works and what doesn't. Keep in mind that no two MDM journeys are the same and what works for one company -- even one similar to your own -- might not be best for you.
Here's a list of questions to get you going:
- Were you able to extend your initial MDM solution to solve other business problems within the organization?
- Was the MDM technology investment you initially made extensible across multiple systems?
- How did you leverage the learning, technology and integration processes from the initial deployment to help accelerate the implementation of subsequent solutions?
- How long was your initial implementation and what was the ROI of the subsequent deployments?
- If you are planning subsequent deployments, are you confident that your current technology will support the architecture required to solve other business problems?
About the author
Ravi Shankar is senior director of product marketing at Siperian, an award-winning provider of the most flexible master data management platform. For more information, contact the author at email@example.com or visit www.siperian.com.
Please note that the Viewpoints listed in CRM magazine and appearing on destinationCRM.com represent the perspective of the authors, and not necessarily those of the magazine or its editors. If you would like to submit a Viewpoint for consideration on a topic related to customer relationship management, please email viewpoints@destinationCRM.com.
Siperian's Last Dance: A Customer-Driven Module for Financial Services
With its Extended Customer View for financial services firms, the MDM vendor — acquired today by Informatica for $130 million — puts the emphasis on relationship-based insights.