Oops! The input is malformed!
Originally published 15 September 2008
There are two kinds of organizations: those that have implemented a master data management (MDM) solution and those which haven’t but undoubtedly will in the near future. Despite where each organization may be in their MDM effort, what both have in common are questions about achieving better business processes. Companies planning an MDM implementation tend to have important questions regarding vendors, strategies and creating road maps to ensure success and a healthy return on investment. Fortunately, these companies can learn and benefit from the experiences of organizations that have pioneered MDM and organize their efforts around a common set of principles. For those organizations whose initial MDM efforts brought early success, the question is how can the lessons learned be leveraged to drive more effective data governance across other lines of business and more elements of the system’s infrastructure?
Some first-generation MDM adopters have been able to build on their initial implementations to address other important business problems. Observing these efforts, certain IT analysts and industry observers are beginning to publish articles laying out models for taking MDM implementations from the early planning stages through to mature, second or third generation stages. Many of these observers 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 such as a registry style1 and then building on that implementation to address other styles, such as collaborative, transaction or hybrid.
The reasoning behind this type of approach follows a conservative “technology maturity curve” as a way to keep data governance requirements in check and the overall risk of failure as low as possible. These are legitimate concerns, and many organizations have been able to realize modest gains in solving their master data problems by following these precepts. However, limiting the scope of your initial MDM implementation is also likely to constrict the potential for greater success and return on investment down the road. The true promise of MDM is that it enables the organization to create a single, clean and correct version of its most important reference data and eliminate the business process inefficiencies that arise from conflicts in various data sources. This is why it is far more effective to organize MDM implementations around specific business problems such as compliance objectives, business process optimization, customer on-boarding, financial risk management and so forth.
In fact, MDM implementations targeted to specific business problems rather than around 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. It is still an incremental approach – where the focus is aimed at solving a circumscribed business problem – but one in which you are putting in place the complete set of tools needed to solve larger master data issues. Another benefit to this approach is it enables your data stewards and other stakeholders to gain crucial knowledge and experience with solution tools and MDM best-practices. As with an incremental technology-based approach, success and return on investment can still be shown and documented before the solution is broadened to other lines of business. At the same time, the stage is being set to realize larger benefits made possible with a true enterprise-level MDM solution.
Let’s consider in more detail why technology focused MDM strategies aren’t the best way to go. The conventional wisdom is that you start small with a technology focus – single entity, registry style, and analytical usage – and then grow the MDM solution along a technology maturity curve by adding the next entity; migrating to other architectural styles such as hybrid, collaborative, or transactional; and/or integrating with operational systems. This kind of approach will pay dividends in a short time frame. However, if the next business problem requires that you develop better visibility into a single view of entities such as clinical protocols, compounds, or reference data (code lookup), then the point-solution MDM implementation you built earlier may not support the new complex requirements.
In fact, the limitations of a technology focused approach would require the deployment of an entirely different MDM technology alongside the original one to solve this new business problem. This ultimately leads to MDM silos which, ironically enough, compounds the very problem for which the MDM initiative was created for in the first place. In effect, you’d have two MDM distinct solutions in place and two distinct versions of the truth. Not good. More to the point, IT executives advocating such a technology-based approach run the risk of being perceived by line of business owners and other internal clients as ineffective –advocates of yet another IT program that ended up over-promising and under-delivering.
Taking a step back, the larger argument against technology-oriented MDM strategies is that messy data nearly always foments multiple business problems across the organization. When an MDM initiative is launched to first solve one of the critical business problems within the company, it becomes far easier to turn the solution toward addressing the next critical business problem. For instance, a pharmaceutical company that used 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 solving master data issues within a single data warehouse, this ability to quickly change focus would depend entirely on the compatibility of the underlying technological resources.
Moreover, with a business-centric approach, the next business problem to be solved could be handled within the same line of business or in a different one – and how the company expands its initial MDM solution to solve subsequent business problems within or across multiple lines of business depends upon the centralized or decentralized operational culture of the organization. If they have centralized operations, such as shared IT resources, they could also decide to broaden the same MDM system to address the next business problem. If the business entities are completely different – where one is a pharmaceutical division and another is a medical devices manufacturer (but both belonging to the same company) – then they may decide to implement two separate MDM systems. The data governance for such an approach requires that cross-functional data owners agree on common data definitions and local data stewards manage data authenticity for their respective organizations.
As more business problems are solved using MDM, more business processes are streamlined, yielding even more benefits for the organization. How a company leverages its present MDM solution for the entire enterprise depends on the path they have taken. If a company has standardized on a single MDM system in its MDM journey, then it might continue to evolve the same system as an enterprise standard. In the case where a company has taken the approach of multiple MDM systems to solve different business problems across multiple business entities, then they may opt to use a global, enterprise-level MDM system to synchronize the master data across all of the MDM systems.
This latter approach is often referred to as a federated MDM approach. Companies may choose to follow such an approach so that local organizations can benefit from the independence of dealing with their own master data, while the enterprise aggregates all sources for corporate regulatory compliance mandates and reporting. The data governance in the federated MDM approach calls for stakeholders (business data owners, data custodians and data stewards) representing all organizations to form an enterprise data governance council to manage cross-functional master data issues. However, this enterprise-level MDM approach is not for everyone. Companies need to be organizationally prepared with solid backing from senior executives such as the CEO for this kind of approach to succeed since it will require a serious commitment of resources.
Companies that are now exploring MDM strategies or looking to expand their MDM success can benefit from the experiences of early MDM adopters. As part of a complete due diligence process, it is recommended that you speak with some of the MDM pioneers and ask the following questions:
Questions to determine a successful evolution of the MDM technology:
When evaluating the answers to these questions one thing will become immediately apparent – no two MDM journeys are the same. Companies within the same industry might approach MDM strategy quite differently – some may use a single, enterprise-wide MDM system to solve all of their business problems while others may use local MDM solutions for each of their organizations and roll them up to a global enterprise-level MDM system. An approach that might work for one company might not necessarily work for another.
Whatever the approach may be, or even if you do not plan to evolve the solution beyond the initial deployment for now, the best insurance is to have a flexible MDM technology capable of supporting the company’s current and future requirements. Achieving a successful MDM journey will reap many rewards provided they are well though-out and due diligence is performed right from the start.