Companies wishing to start a master data management (MDM) project may be unsure where and how to begin. After all, MDM is a journey and success or failure at the first step either defines or dooms the further evolution of the project. Recently, industry analysts have been recommending a cautious approach to starting with MDM – suggesting that companies start with a single data type (such as customer), implement MDM using a small footprint (such as registry style) or deploy MDM solely with a data warehouse to improve reporting. Inherently these technology focused approaches reduce project risk and relieve the data governance burden. Companies may readily adopt these approaches as perfectly reasonable starting points and lean to a more risk-averse approach to their initial MDM implementation in hopes of mitigating risks. However, these same approaches may limit the scope and potential return on investment (ROI) from MDM since they do not attempt to solve the most pressing and difficult business problems.
Beware of Technology Focused Starts
A nearsighted focus only on the technology aspects of MDM may ultimately lead to minimal business adoption and therefore severely constrain the business ROI. The following business case scenarios illustrate how restricting MDM to a single master data type, registry style or to analytical usage will curb its usefulness in solving difficult business problems:
Restricting MDM to a single master data type may constrain the usefulness of the MDM solution: For example, an MDM solution that is deployed to solve buy and sell-side supply chain processes and more effectively manage the procurement of direct and indirect materials and the distribution of products necessarily needs to involve managing vendor, customer, material and product master data. Starting with only one of these master data types will not effectively improve the systemic supply chain, and would severely constrain the usefulness of an MDM solution for supply chain performance management.
Confining MDM to a registry approach may impede solving hard business problems: An MDM solution implemented to improve credit risk management and capital requirements for compliance with Basel II regulations will need to reconcile conflicting counterparty master data and legal hierarchies and store them centrally for immediate access. In this case, a registry approach would only identify counterparties as duplicates without determining a system of record or the correct definition for the counterparty. As a result, credit risk managers would be unable to determine which counterparty definition is current and accurate. In addition, a registry approach cannot determine the legal hierarchies required to calculate the aggregated risk exposure. Consequently, the credit risk managers would need to go through a process to determine the correct entry and combine information from different systems to arrive at that a single definition and legal hierarchy representation. From that point forward, the information would act as the single best source of information for all credit risk calculations. A small footprint using the registry approach would not effectively solve this difficult business problem.
Limiting MDM to analytical usage may limit the business value: In the case of using MDM to improve order-to-cash, reliable master data needs to be synchronized back to operational systems, such as order management, in order to enhance the business process. Where the master data is only synchronized to a data warehouse, the efficacy of the order-to-cash business process cannot be improved since this process is inherently operational in nature. Measurable hard dollar benefits derived from MDM are only achievable with business process improvements.
Taking a technology focused approach may enable your organization to get started with MDM quickly, but it may not effectively solve the difficult business problems or deliver the requisite business value. In fact, the resulting solution more readily runs the risk of being perceived by business users as yet another IT initiative unable to address their business needs. And this will make it increasingly difficult to further evolve or extend the solution– boding a premature death for the enterprise MDM initiative or even worse “getting stuck at the gate”.
It is important to also take notice that some MDM vendor solutions only support a single architecture style such as registry or can only be deployed for a single usage – either operational or analytical. These solutions simply cannot be extended to other architectural styles or another usage mode which can severely limit their usefulness in addressing the most challenging of business problems. In addition, a technology-centric start will not fulfill the most important needs around enterprise master data governance.
Start With the Business in Mind
MDM is more precisely about solving business problems by efficiently managing master data that is critical to a company’s business operations. Consequently, how an MDM solution is implemented depends foremost on which business problems are being tackled. Only a business focused approach can provide a complete MDM solution that addresses the specific business problem, provides tangible business value and significant ROI in a short-term timeframe. By taking this approach, you can ensure the success of your MDM initiative and pave the way for expansion across the organization. How to get started? A pragmatic place to begin is to answer these three questions:
1. Which business problems need to be tackled? Organizations should start by first identifying the business processes that are inefficient, and among those, which ones should be addressed first. By choosing a business process to start with, the master data types that need to be managed will become evident. For example, two business processes within a company’s supply chain are experiencing problems– different divisions within the company are procuring direct materials from the same vendor at different contracted rates, and sales people are competing for the same customer’s business. The master data integral to improving these business processes are vendor, contract, customer, materials and product information.
2. What is the business use? Next identify how business users will use the master data within their business processes in order to determine the most appropriate architectural style and usage modes to support the needs of the business users. As an example, in order to ensure that the same contracted rates for procuring different direct materials from a supplier are made available at different touch points, the MDM system needs to reconcile conflicting vendor, contract and direct materials data and then centrally store it – analysts refer to this architectural style as coexistence or transactional. The data also needs to be made available to the supply chain and contract management systems. In order to ensure sales alignment, the MDM system needs to make customer and product information available to the data warehousing system for accurate and timely analysis and reporting.
3. What are the business requirements for master data governance? Finally, it is important to understand the business requirements for governing the master data in order to determine the requirements for master data availability, usability, integrity and security. For instance, the procurement department will require a high degree of integrity for vendor and contract data, and will need to be able to make this data available to procurement agents in real-time. The contract negotiation team, on the other hand, may require the same degree of data integrity, yet not in real-time. Similarly, the sales team would have a requirement that only sales managers are able to perform sales force alignment, while sales representatives only have access to information for their assigned territory.
The Right Start Ensures an Initial MDM Win
What becomes obvious from these and other examples you may consider in your business is that MDM will almost always will require a multi-entity deployment (such as customer and product) and an architectural style that is not restricted to registry alone. In most instances, synchronization with both operational and analytical systems may also be essential to effectively address the specific business needs of your organization.
By taking a business focused approach to MDM, you can provide a complete solution to the most challenging of business problems – using only the required master data, implemented with the correct solution architecture, deployed for the correct business use and with the correct data governance structure. When a pressing business problem is successfully solved by an MDM solution, adoption of the solution dramatically increases among business users because it eliminates inefficiencies and improves productivity resulting in measurable cost savings and higher ROI. Starting with a defined business problem allows you to start small so that success can be demonstrated before expanding the solution to other business units, geographies or divisions. Once business users experience the benefits of an MDM solution they will more readily support its use in other areas – paving the way for an enterprise MDM solution.
