Você está na página 1de 6

Oracle MDM Maturity Model

An Oracle White Paper June 2011

ORACLE MDM MATURITY MODEL

Introduction

Many companies still dont have a true view of their customers, products, suppliers, and sites much less their inventory and financials. While they invest in new, sophisticated enterprise applications to handle business processes, the data they generate is not centrally managed. In fact, these systems often generate inconsistent and conflicting information. Master Data Management (MDM) is a discipline that can help organizations get a handle on all this data. The Oracle Insight team has created an MDM maturity model that can help organizations understand where they stand in their MDM journey. The model, based on Oracle Insight engagements with companies from around the world, covers maturity levels around five key areas: Profiling data sources Defining a data strategy Defining a data consolidation plan Data maintenance Data utilization

Around each of these data management areas, the Oracle MDM Maturity Model defines four maturity levels: Marginal Stable Best Practice Transformational

This paper defines each of these areas so you can begin to evaluate your companys maturity when it comes to managing your master data.
Profile data sources

Profiling data sources involves taking an inventory of all data sources from across your IT landscape. The data sources can include Customer, Product, Supplier, Site and Financial master data. Then evaluate the quality of the data in each source system. This enables the scoping of what data to collect into an MDM hub and what rules are needed to insure data harmonization across systems. Many organizations have multiple sources of master data with varying degrees of data quality in each source, e.g. customer data

Oracle MDM Maturity Model

stored in the customer relationship management system is inconsistent with customer data stored in the order management system. Some questions to ask are: How do we define a customer? What is a product? How do we define a site? Data profiling should result in the following: A documented inventory of data sources, requirements, and security controls An understanding of the magnitude of the data quality issues An understanding of scope of data entities to be mastered A consistent, global definition of all key data entities

Define data strategy

A data strategy requires an understanding of the data usage. Given data usage, various data governance requirements need to be developed. This includes data controls and security rules as well as data structure and usage policies. A well-defined data management strategy is aligned to the business strategy and helps create the governance needed to ensure that data stewardship is in place and data integrity is intact. The data strategy exercise should result in: A documented data strategy on who uses each data attribute and how the data is to be used A documented governance structure to manage data quality A source systems mapping of all key attributes to be stored for the mastered entities Documented data structures with the policies to maintain the attributes

Define data consolidation strategy

Consolidation requires defining your operational data model. How integration is to be accomplished. Cross referencing common data attributes from multiple systems is needed. Synchronization policies also need to be developed. A well-defined consolidation strategy will ensure that a central cross-reference is maintained with updates in any one application being propagated to all the other systems. The data consolidation strategy exercise should: Produce a documented security and access control mechanisms Determine the impact of MDM on integration (batch vs. real-time) Develop the cross-referencing tables between the master solution and the source systems Determine how the participating systems will synchronize the data with the master

Oracle MDM Maturity Model

Data maintenance

The desired standardization needs to be defined, including what constitutes a match once the data has been standardized. Cleansing rules are a part of this methodology. How data quality monitoring needs to be defined. Organizations need the ability to standardize data for customers, products, sites, suppliers and financial accounts and eliminate duplicates automatically. The data maintenance process should: Select tool(s) and define rules for standardization Select tool(s) and define rules for matching Select tool and define rules for cleansing and normalization Insure that data stewards are in place and documented procedures exist on how to manage the data

Utilize the data

What data gets published, and who consumes the data must be determined. How to get the right data to the right place in the right format given its intended use must be understood. Validating the data and insuring security rules are in place and enforced are crucial aspects for full no-risk data utilization. A key benefit of a master data management strategy is not only to clean the data, but to also share the data back to the source systems as well as other systems that need the information. The data utilization process should: Identify what data is published and consumed by the subscribing applications Document how the master solution is to be used in data integrations between applications Insure validation procedures exist at the point of entry, and reconciliation processes are in place to remediate That access rules for master data is defined and enforced

Maturity Levels

For each of the above data management areas, a maturity level needs to be assessed. Where your organization wants to be should also be identified using the same maturity levels. This results in a sound gap analysis your organization can use to create action plans to achieve the ultimate goals.
Marginal

This is the lowest level. It is characterized by manually maintaining trusted sources; lacking or inconsistent, silod structures with limited integration, and gaps in automation.
Stable

This is the next leg up the MDM maturity staircase. It is characterized by tactical MDM implementations that are limited in scope and target a specific division. It includes limited data stewardship capabilities as well.

Oracle MDM Maturity Model

Best Practice

This is a serious MDM maturity level characterized by process automation improvements. The scope is enterprise wide. It is a business solution that provides a single version of the truth, with closed-loop data quality capabilities. It is typically driven by an enterprise architecture group with both business and IT representation.

Transformational

This is the highest MDM maturity level. At this level, MDM is quantitatively managed. It is integrated with Business Intelligence, SOA, and BPM. MDM is leveraged in business process orchestration.
Transformational Best Practice
Stage IV MDM is quantitatively managed, and is integrated with Business Intelligence, SOA, and BPM. MDM is leveraged in business process orchestration.

Stable
Marginal
Stage I Manually maintain trusted sources; lacking or inconsistent, siloed structure with limited integration, gaps in automation Stage II Tactical MDM implementations, limited in scope and target a specific division. Limited scope and stewardship capabilities. Typically done to gain experience.

Stage III Process automation and improvement with MDM. Enterprise business solution, which provides a single version of the truth, with a closed-loop data quality capabilities. Driven by an enterprise architecture group.

CONCLUSION

It has been said that MDM is a journey. To take that journey from tactical to enterprise wide benefits requires professional grade software. MDM products from vendors like Oracle can help. But organizational issues, executive support, and cooperation between business and IT are critical to your success. Take an inventory using this MDM Maturity Model and see where you are in your journey to full MDM maturity and all the business benefits that accrue to organizations who have mastered their data for the benefit of all operational applications, business processes, and analytical systems.

Oracle MDM Maturity Model

10

Oracle MDM Maturity Model Author: David Butler, Trevor Naidoo Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 Oracle.com Copyright 2011, Oracle. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

Oracle MDM Maturity Model

11

Você também pode gostar