transitioning to enterprise mdm - part 1

Transitioning to Enterprise MDM – The Change Management Process, Part 1

© Intelligent Business Strategies Ltd 2

I have talked in previous articles about three kinds of MDM system you can deploy. These are

a registry based MDM system, an MDM data hub and an enterprise MDM system. The

registry based MDM system uses Global Identifiers and data federation to create a virtual

master data system of record (SOR) where no persistent master data store exists. Instead, the

master data is integrated at run time and provided to requesting applications and processes

that require it. A MDM data hub is a is a system that propagates master data changes between

disparate operational systems and can persist a complete integrated set of master data in a

master data store as a system of record (SOR). In this case the operational systems that

maintain the master data remain the systems of entry (SOEs). The most advanced type of

MDM deployment is an enterprise MDM system which has the following characteristics.

An Enterprise MDM system is both the system of entry (SOE) and the system of

record (SOR)

Supports master data integration (consolidation and federation) and master data

synchronisation

Fully integrated complete set of master data in a master data store

The Master data store supports multiple master data entities

All master data changes are logged and changes are propagated to other operational

applications and data warehouses

Can integrate operational master data, BI and related unstructured content associated

with an instance of a core entity e.g. customer

All master data entities are defined in a shared business vocabulary (SBV) i.e. a

common enterprise wide data names and data definitions

Full policing of master data integrity across the enterprise

Full data quality firewall with DQ services to validate and clean master data

Full set of enterprise data management tools for managing master data and metadata

across the enterprise

Common master data web services for access & maintenance of master data

Tracks changes and holds to master metadata over time (history of metadata changes)

Complete set of MDM business services around the master data

A diagram of Enterprise MDM is shown in Figure 1.

http://www.b-eye-network.co.uk/view-articles/3762



Enterprise Master Data Management Is A Lot More Than Building A Master Data Hub

OperationalSystems

(disparatedata definitions for master data)

C

R

U

D

prod cust

asset

CRUD = Create, Read, Update, Delete

Master dataservices

(standardise interactionswith master data)

Custom App Custom App Packaged App

Shared master data

Packaged App Packaged App BI System

Mas

ter

dat

a in

tegr

atio

n s

vcs

EDM tools for MDM

Master metadata servicesMetadata repository mappingsDisparate

definitions SBV

Business VocabularyData ModellingMetadata DiscoveryData QualityData Integration

Master DQ

Services

Enterprise

service bus

Copyright © and Intellectual Property Rights Intelligent Business Strategies 2007 Figure 1

One of the major differences with enterprise MDM is that this kind of MDM system is both a

system of entry (SOE) as well as a system of record (SOR). This means that master data is

updated centrally before changes are synchronised with other systems. Getting to enterprise

MDM is a significant effort for many companies and may take several years if you are in a

position where master data is heavily fractured and there is no single system of record. One

way to evolve towards enterprise MDM is to start with a registry based MDM system, then

progress to a data hub with a persistent system of record and then finally move on to an

enterprise MDM system.

Admittedly, this is a lot easier to say than do. However even if you have worked out how this

can be done it is not just the mechanics of trying to centralise master data that is of concern to

many organisations. One of the real challenges associated with deploying master data

management is that of change management that may result from introducing an MDM system.

In recent consulting engagements and in talking to several of my clients, it has become clear

to me that some organisations consider the integration of master data as the easy bit. What is

actually causing the caution and the slow adoption of MDM is an even bigger issue that is

much more difficult to get right and that is the change management process needed to

correctly implement full enterprise MDM. In other words working out what has to change

and in what order when introducing an MDM system is what many are struggling with.

Looking at this problem more closely it is not a surprise that people are having difficulty

considering that an MDM system may result in:

Changes to people’s roles and responsibilities

Changes to documents

Changes to user interfaces

Changes to human/document workflow and system processes

Changes to applications (operational & BI systems)



Changes to data stores in disparate line of business application

Changes to data movement and unstructured information management

The data piece is just part of the story here and so it is often the case that data professionals

may find their skills good in the mechanics of master data integration and data management

but weak in areas like changing processes, user interfaces, applications, documents and

people’s roles and responsibilities. Certainly from the above list it is changes to people’s roles

and responsibilities and changes to human/document workflow and system processes that are

often the most challenging. One thing for sure is that you will struggle to implement the

necessary change unless you know how your existing processes and applications work with

master data.

In my opinion therefore a significant contributor to success in MDM is that IT professionals

tasked with implementing MDM must start an MDM project by leaving technology aside and

taking the trouble to learn how their business works. By this I mean that it is necessary to

conduct a business analysis of existing processes to identify what process activities are

associated with master data. This means understanding the processes associated with creating

new customers for example and understanding what operational and analytical applications,

collaboration tools and documents that are used in such processes with the objective being to

identify all core business:

Documents

Process activities (tasks)

Applications and application functions

Application screens and on-line forms

Reports

Data integration jobs

etc, ……

that currently access and maintain disparate master data and also to identify all data stores

holding disparate master data, e.g. Files, RDBMSs, cubes, content management systems……

Figure 2 shows an example order entry, fulfilment and tracking process with activities

highlighted that are associated with master data



Copyright © and Intellectual Property Rights Intelligent Business Strategies 2007

The MDM Change Process – Identify Processes And Their Activities That Use and Maintain Master Data

Process can span multipleorganisational departments

Order Entry, Fulfilment and Tracking Process

Maintains Customer data +Access product data

Access product data

Access Customer data +Access product pricing data

Access customer data

Maintains Customer data

Figure 2

In order to do this well, a number of key questions need to be asked for each master data

entity when following a business process. These include:

Who performs each process activity?

What documents and forms contain master data attributes?

Which documents containing master data are used in which process activities?

Which process activities access master data, e.g. customer data, product data etc.?

Which process activities maintain what master data, e.g. customer data, product data,

etc.?

Where do master data changes currently flow from?

Where do master data changes currently flow to?

What applications are used to perform each process activity and to maintain master

data?

What screens in the identified applications allow users to maintain master data

What functions in what applications access and maintain master data

What ETL jobs acquire master data and from where (what systems) do they get it

from?

The objective of this kind of questioning is to create an inventory of things that may need to

be changed when implementing an MDM system. This inventory could include documents,

processes, application functions, screens, paper and on-line forms, data models etc. Once this

has been done you should be able to identify overlaps, duplication and conflicts within this

inventory and zoom in on who performs duplicate activities. The objective is to identify

duplicate, overlapping and conflicting:

• People who are currently responsible for maintaining master data

• Documents containing master data



• Process activities associated with master data

• Screens and forms used to maintain master data

• Application functionality that maintains master data

• Reports containing master data

• Data integration jobs

• Data models

• Data stores and schema

Having got this far the next stage is to create a matrix to track conflicts, duplication and

overlap so as to identify what must be changed in order to eliminate these. Then you can

determine the order of priority in which changes need to occur. Factors influencing the order

of priority on MDM change management include return on investment brought about by the

change, change complexity, cost Vs budget available, human resources required and their

availability and time to implement.

At this point you should be in a position of control over change management for MDM

because you know what has to change and in what order. You may find that the ‘to do’ list

you have created is somewhat daunting. However at least you know what it is and that you

can nevertheless make it doable. Transitioning systems to leverage centralised common

master data may involve changing line of business SOE applications to remove/disable master

data attributes from data entry screens and on-line forms. Once this is done new forms and

screens will need to be created to directly maintain the master data in central MDM data hubs.

This latter capability may be available out-of-the-box as some MDM systems ship with pre-

built standard portlets that can run in any enterprise portal server to allow users to maintain

master data directly from an enterprise portal user interface. We will talk more about this later

in the article.

The big change is the move from many systems of entry (SOEs) to one SOE. In order to

make this happen you have to understand the impact of that kind of change on existing line of

business applications. For example line of business SOE systems may update more than

master data in a specific transaction scope. Therefore transaction logic in the line of business

application may also have to change to remove master data changes from transactions. In

addition duplicate or overlapping functionality in existing systems of entry (SOEs) has to be

identified and removed/disabled to stop master data conflicts. There is no doubt that major

transition begins once an MDM system shifts from being a system of record (SOR) to a

system of entry (SOE) – See Figure 3.



Copyright © Intelligent Business Strategies 2007

Major Transition Begins Once The MDM System Shifts From Being A System of Record To A System of Entry (SOE)

Call CentreSystem

Customerdata

subset

Productdata

subset

Mortgage System

Customerdata

subset

BranchBankingSystem

Customerdata

subset

LoansSystem

Customerdata

subset

ERP System

Customerdata

subset

Credit Card

System

Customerdata

subset

CustomerSOR

Productdata

subset

Productdata

subset

Productdata

subset

Productdata

subset

ProductSOR

changes changeschanges changes

changes changes

SOR = System Of RecordSOE = System Of Entry

Customer master data changes

Product master data changes

& SOE & SOE

Figure 3

When this shift happens you need to already have a thorough understanding of the impact an

enterprise MDM system will have. It may be the case that changes may need to be made to

Data

Applications

Processes and workflows

User interfaces,

Documents

People

In part 2 of this article I will look at the potential change impact on each of these in more

detail.

Mike Ferguson is Managing Director of Intelligent Business

Strategies Limited, a leading information technology analyst

and consulting company. As an analyst and consultant he

specialises in enterprise business intelligence, enterprise

business integration, and intelligent business. He can be

contacted at +44 1625 520700 or e-mail at

[email protected]