Transitioning to Enterprise MDM: The Change Management Process
In this article by Mike Ferguson of Intelligent Business Strategies we learn one of the most overlooked disciplines that is pivotal to MDM success - effective change management.
As an analyst and consultant, Mike specialises in business intelligence and enterprise business integration.
With over 28 years of IT experience, Mike has consulted for dozens of companies on business intelligence strategy, technology selection, enterprise architecture, and data management.
How do you transition to Enterprise MDM? The key is effective change management
There are typically three kinds of MDM system you can deploy:
Registry Based MDM System
MDM Data Hub
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.
An MDM Data Hub 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 below:
Diagram of a typical Enterprise Master Data Management implementation
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 is 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. It is often the case that data professionals may find they possess good skills for the mechanics of master data integration and data management but weaker skills 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 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. It is necessary to conduct a business analysis of existing processes to identify what process activities are associated with master data.
For example, this means understanding the processes associated with creating new customers. It may also mean we need to understand what operational and analytical applications, collaboration tools and documents are used in such processes.
The objective here is 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, RDBMS's, cubes, content management systems etc.
The figure below shows an example order entry, fulfilment and tracking process with activities highlighted that are associated with master data.
The MDM Change Process
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 (SOE’s) 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) as shown in the figure below.
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
Copyright © Intelligent Business Strategies, 2010 – All Rights Reserved
About the Author: Mike Ferguson of Intelligent Business Strategies Limited.
As an analyst and consultant Mike Ferguson specialises in business intelligence and enterprise business integration. With over 28 years of IT experience, Mike has consulted for dozens of companies on business intelligence strategy, technology selection, enterprise architecture, and data management.
Mike presents all over the world and has written numerous articles.
Formerly he was a principal and co-founder of Codd and Date Europe Limited – the inventors of the Relational Model, a Chief Architect at Teradata on the Teradata DBMS and European Managing Director of Database Associates.
Mike teaches popular Enterprise 2.0 master classes in Operational Business Intelligence and Performance Management, Complex Event processing (CEP), Master Data Management, Information Integration and Service Oriented Architecture (SOA).