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 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:
1) 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 needs to manage
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
2) 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.
3) 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
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 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 and deployed for the
correct business use 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.
About the Author
Ravi Shankar is Senior Director of Product Marketing at Siperian, Inc., an innovative provider of the most flexible master data management platform. For more information, contact the author at firstname.lastname@example.org or visit www.siperian.com.