Master Data Management (MDM)
Table of Contents
1 - Overview
Master Data Management (MDM) solutions are considered to hold the
master for any given entity.
In computing, master data management (MDM) comprises a set of processes and tools that consistently defines and manages the non-transactional_data (often Dimensional Modeling - Dimension of a cube and not a Dimensional Modeling - Fact Table) entities of an organization (also called reference data) :
- person or party,
- financial masters
MDM has the objective of providing processes for :
- persisting and
- distributing such data throughout an organization
to ensure :
- the Data Quality - Metrics (as consistency)
and control in the ongoing maintenance and application use of this information.
A MDM solution works basicly in two points:
- creating, maintaining and leveraging a single, trusted, shareable view of the truth
- keeping multiple source silos in synch in a BPM / real-time fashion.
However, most large enterprises have a heterogeneous application portfolio, with fragments of often inaccurate, incomplete and inconsistent data residing in various application silos. No comprehensive system contains the single view or is designed to manage the complete life cycle of the master data.
The MDM product trends to improve data Data Quality - Role (data steward) and governance facilities, including :
MDM systems are software products that:
- Support the global identification, linking and synchronization of information across heterogeneous data sources through semantic reconciliation of master data
- Create and manage a central, database-based system of record
- Enable the delivery of a single view for all stakeholders
- Support data quality compliance through monitoring and corrective-action techniques
MDM architectural styles vary in:
- Instantiation of the master data — varying from the maintenance of a physical profile to a more-virtual, metadata-based indexing structure
- The use of the master data — ranging from supporting operational requirements to the support of analytical requirements
- The latency of master data maintenance — varying from real-time, synchronous, reading and writing of the master data in a transactional context to batch, asynchronous harmonization of the master data across systems
2 - Goal
- Analytics/Datawarehouse to analyse the Business Process, MDM to implement the strategies and pilot the business process
- Contain data quality feature
- to improve reporting in a datawarehouse environment
- 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
- identify vendors, contract, and materials data as duplicates
- define the correct definition for the data
- to improve order-to-cash, reliable master data needs to be synchronized back to operational systems—such as order management—to enhance the business process.
- focus to solve difficult business problems and deliver the requisite business value, not on the technology
- 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.
- BI tools are only as good as the quality of the data they work with. Analyst Michael Schiff is still surprised at how many BI professionals still ignore this fact.
3 - Product
3.1 - Data-Modeling Capabilities
The applicability of the data model to your organization is a fundamental requirement. It must:
- Model the complex relationships within the enterprise's internal application sources and among the organization, its business and consumer customers, intermediaries and other parties, including the ability to handle complex hierarchies
- Map to the master data requirements of the entire organization, not just to selected areas
- Be configurable, customizable and extensible, as well as upgradable
- Support vertical-industry-specific requirements
- Provide a base for the required workload mix and level of performance
- Be expressed using commonly accepted logical data model conventions with associated metadata
3.2 - Information Quality Management Capabilities
A good data model has little value if it lacks accurate, up-to-date data. MDM for data products should:
- Have strong facilities, in batch and real-time mode, for cleansing, matching, identifying, linking and semantically reconciling master data in different data sources to create and maintain the “golden record.” These facilities may be provided by the MDM for data vendors or by offering tight integration with products from specialist data quality partners.
- Support a “data steward” role, enabling it to manage data throughout its life cycle and provide data governance, including the ability to:
- Set rules to determine where to source data and under what circumstances, including the ability to give preference to the most-dependable sources.
- Configure rules for comparing and reconciling semantics across data sources, matching and linking the data, and manage the merging and unmerging of customer records with full auditability and survivability.
- Ensure that business rules and associated metadata related to data cleansing are sufficiently visible to satisfy compliance requirements.
3.3 - Loading, Integration and Synchronization Capabilities
MDM products need to provide data integration facilities for loading the data in a fast, efficient and accurate manner. There will also be a need for data and application integration capabilities, including publish-and-subscribe mechanisms, to provide a communication backbone for the bidirectional flow of data between the central database (or hub) and the spoke systems. These facilities may be provided by the MDM vendor or by offering tight integration with products from specialist data and application integration partners. MDM for data products should be able to:
- Leverage a range of data and application integration products to integrate with a wide variety of data sources, including legacy data sources, and it should expose industry-standard interfaces
- Support integration with different latency characteristics and styles (for example, real time and batch)
- Support integration with downstream business intelligence (BI) and analytical requirements
3.4 - Business Services and Workflow Functionality
Many leading organizations plan to use the new master database as the basis for new operational and analytical applications. In the enterprise service-oriented architecture (SOA) world, service-oriented composite business applications may consume MDM for data business services through Web services standard interfaces.
MDM for customer data products should protect and complement the data layer with a layer of business services, at granular and more-coarse-grained levels, for accessing and manipulating the customer data that is built for an SOA environment, and exposing Web services interfaces.
In addition, there are some scenarios (such as collaborative centralized authoring or data quality improvement of customer data) in which MDM for data systems require a collaborative workflow capability and need to support their own business process modeling capabilities. In other scenarios (such as forming part of a wider, end-to-end create-customer process), they need to interact with enterprise business process management (BPM) tools. As MDM becomes core to SOA strategies, this MDM/BPM suite capability may need to be reconciled with the enterprise BPM strategy.
3.5 - Performance, Scalability and Availability Capabilities
If an MDM for data product supports operational and analytical applications and is tightly integrated with established systems and new applications, then serious demands are likely to be made on its performance, scalability and availability. MDM for data products should have:
- Proof points, preferably through live references, of different aspects of performance and scalability that match current and future requirements
- Appropriate availability characteristics regarding planned and unplanned downtime
3.6 - Manageability and Security Capabilities
This functionality involves the availability of facilities for managing the MDM for data system, such as facilities for reporting on activities within the system. In addition, these capabilities include integrating the MDM for data system with common system management and security tools. On the security and data privacy management front, this involves the ability to:
- Manage the policies and rules associated with potentially complex privacy access rights
- Configure and manage different rules of visibility, providing different views for different roles
3.7 - Measurement Capabilities
The ability of MDM for data products to support a range of analytics from the performance of the technology, the MDM-enabled business processes themselves, as well as the accuracy of the master data. The MDM for data product needs to support users' ability to flexibly define data quality based on usage and use case, and to use these definitions in a real-time manner to report up-to-date information on the performance of MDM processes. This may be achieved by tight integration with a BI solution that embeds the analytics in the MDM for customer data system, or by an inherent analytical capability. The analytics need to extend across:
- Overall performance of the MDM for data system in terms of system availability, workflow, process monitoring and performance, and data throughput
- Analytics related to MDM-enabled business processes and service execution — for example, the execution of business processes in a timely fashion to targets set by the business, as well as the effective handling of anomalies and queries related to product master data
- The overall master data quality of the business and how it's changing
3.8 - Technology and Architecture Considerations
MDM for data products should be based on up-to-date, mainstream technologies and should be capable of flexible and effective integration with a wide range of application and infrastructure platform components (from one or more vendors) within the user organizations. They should be capable of flexible configuration into a range of architectural styles in terms of instantiation, latency and use of customer master data to enable it to satisfy such use case scenarios as consolidation, registry, coexistence and transaction scenarios. The vendors are also measured on the capabilities of their architectures to support global rollouts and localized international installations.
3.9 - Implementation and Support
This service and support area includes:
- Professional services — Provide internal professional service resources or partner with external service providers (ESPs) with vertical industry expertise, MDM for customer data domain knowledge, global and localized country coverage, and a broad skill set (including project management and system configuration) to support a complete project life cycle
- Customer support — Provide satisfactory prompt service to its customers worldwide with ranges of service-level agreements to meet different requirements
- User groups — Provide support to active user groups
3.10 - MDM as supplier system
The data also needs to be made available to the supply chain and contract management systems. And 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.
A synchronization with both operational and analytical systems may also be essential to effectively address the specific business needs of your organization.
4 - MDM Fundamental
A multi-entity deployment (such as customer and product) and an architectural style that is not restricted to registry alone.
5 - ROI
The challenge in employing the concept of “return on investment” for justifying the funding of an improvement project is the ability to monitor, over time, whether the improvements implemented through the project are facilitating the promised positive impacts.
Example of goal :
- less stock by playing with the supply parameters from the product
- less cash by playing with the parameters from the suppliers
6 - How to get started?
To succeed, you should put together a balanced MDM program that creates a shared vision and strategy, addresses governance and organizational issues, leverages the appropriate technology and architecture, and creates the necessary processes and metrics.
A pragmatic place to begin is to answer these three questions:
6.1 - Which business problems need to be tackled?
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 salespeople are competing for the same customer’s business.
6.2 - What is the business use?
Next identify how business users will use the master data within their business processes to determine the most appropriate architectural style and usage modes to support the needs of the business users. For instance, 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—an architectural style analysts call coexistence or transactional.
6.3 - What are the business requirements for master data governance?
Finally, it is important to understand the business requirements for governing the master data 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 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.
7 - Rules for a MDM Customer solutions
|DQ Metric||Customer Data Quality Rule||Description or Example|
|Completeness||Attribute completeness||Discovers # and % of null values|
|Completeness||Contact Completeness||Requires all name, address, SSN, … are not null|
|Conformity||Data Type||Data type, length, & precision documented & found|
|Conformity||Data Domain||All values are within specified domain|
|Uniqueness||Restricted values||Values are not in a list of restricted values: e.g. “66666…”…|
|Uniqueness||Unique Key discovery||Discovers # and % of unique values|
|Pattern and Common Format||Name Standardization||First, Middle and Last name not null & properly capitalized|
|Pattern and Common Format||Common Pattern||Common pattern required (e.g. phone, email), % conformity|
|Pattern and Common Format||Name Capitalization||“Aaaa”, “Aaa Bbbb”, “Aa-Bbb”, …|
|Pattern and Common Format|| Extended Phone Numbers |
International Phone Numbers
|More extensive definition of allowable phone number formats. Can extend to specific country formats, etc.|
|No Access Lists|| by Name Only |
by Name or SSN
by Email List
|Restriction lists for specific records, filtered by name, SSN and/or emails|
8 - Demo / Presentation
9 - MDM Application
10 - MDM Businss Case
- Mergers / acquisition
- Multiple ERP systemen
- Service Oriented Architecture
- Management of cost and complexity