Master data management (MDM) is a journey, and success or failure at the first step either defines or dooms the further evolution of the project. Companies that want to deliver rapid success in their initial MDM initiative hope to start their project with the correct approach but are unsure about what that approach entails. Frequently, they look to the advice from industry analysts, who have been preaching MDM they advocate a cautious, risk-averse approach to starting the MDM initiative. The companies should start small with a single data type (such as customer), implement MDM in a simple manner by using a small footprint (such as registry style) or start easy by deploying MDM solely with a data warehouse to improve business intelligence or reporting. These technology-focused approaches are advocated to reduce project risk and to relieve the data governance burden. As a justification for these approaches, the analysts explain that MDM is still largely unproven and companies should lean toward a more risk-averse approach to their initial MDM implementation to mitigate risks. Some companies may readily adopt these approaches as perfectly reasonable starting points. However, these same approaches do not attempt to solve the most pressing and difficult business problems and may limit the scope and potential ROI from MDM.

 

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”.

 

Be Wary of Technology-Focused Starts

 

A myopic focus on only the technology aspects of MDM may ultimately lead to minimal business adoption and therefore severely limit 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 reduce its usefulness in solving difficult business problems:

 

Confining MDM to a single master data type may limit the usefulness of the MDM solution. For example, an MDM solution that is deployed to solve buy and sell-side supply chain processes, to 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 overall supply chain, and would severely constrain the usefulness of an MDM solution for supply chain performance management.

 

Restricting MDM to a registry style may hamper 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 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 curtail 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.

 

It is important to also pay heed 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 to another usage mode. Such restrictions can severely curb the usefulness of these solutions in addressing the most challenging of business problems. In addition, a technology-focused start will not fulfill the most important needs around enterprise master data governance.

 

Begin 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. The nature of the business problem defines how an MDM solution is implemented. 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 initial MDM initiative and pave the way for expansion across the organization. How to get started? A practical 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 problems that are inefficient, and among those, which ones should be addressed first. By choosing a business problem 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 touchpoints, 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.

What becomes obvious from these and other examples you may consider in your business is that MDM almost always will require a multientity 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.

 

A Right Start Is Your First Victory in Your MDM Journey

 

A business-focused approach is the most optimal strategy to your initial MDM deployment because it allows you to start small by 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. By taking a business-focused approach to MDM, you can provide a complete solution to the most challenging of business problems. 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. 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. Hence, starting with a defined business problem allows you to demonstrate success within a single business unit before expanding the MDM solution to other business units, geographies or divisions.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access