Getting Started With MDM

Table of Contents
Intelligent
Business
Strategies
Getting Started With Master Data Management
By Mike Ferguson
Intelligent Business Strategies
March 2008
Prepared for:
Table of Contents
Introduction ...................................................................................................................................... 3
What Is Master Data Management? ................................................................................................ 4
Why Is Master Data Management Needed? .................................................................................... 5
The High Level Requirement ........................................................................................................... 8
Getting Started With An MDM Project............................................................................................ 10

Building a Business Case for MDM .......................................................................................... 10
Scoping an MDM Project ......................................................................................................... 12
Assessing the Current State of Your Master Data ................................................................... 15
MDM System Architecture ....................................................................................................... 16
Building a Project Plan ............................................................................................................. 17
MDM implementation Options – Build Vs Buy ......................................................................... 19
Conclusions.................................................................................................................................... 21
Copyright © Intelligent Business Strategies, 2008 2

INTRODUCTION
All businesses, no matter what their size, rely on data to record and analyse
business activity. It is the lifeblood of any business operation. Data enters the
enterprise during specific process activities, either through the keyboard, via
electronic messages or via electronic files. It then flows throughout the
enterprise to support every process activity from registering new customers
Two broad categories
and sales order taking to supplier procurement, product fulfilment, product
of structured data
underpin business delivery, invoicing and payment collection. Yet, when you boil down the
operations - master complexity of business operations and look at data underpinning it in simple
data and transaction terms, there are two broad categories of structured data that any business
data relies on. These are:
• Master data
• Transaction data

Master data is data Master data is simply the data associated with core business entities such as
associated with core customer, employee, supplier, product, partner, asset, etc. This data can
business entities reside in many different systems. For example, customer data may reside in a
such as customer, sales force automation system, an e‐commerce system, a marketing system, a
product, asset, etc. billing system and a distribution system. Equally, product data may reside in
product development systems, manufacturing systems, planning systems and
storage systems. A trait of master data, therefore, is that subsets of it are
Master data is often needed in multiple systems to control continuity of business operations as
present in multiple
processes progress throughout the enterprise.
systems
Transaction data, on the other hand, is very simple and straight forward. This
is the recording of business transactions such as orders in manufacturing,
mortgage, loan and credit card payments in banking, and premium payments
and claims in insurance. In retail, transaction data is product sales, either at
point‐of‐sale terminals in stores or online. In aviation it is airline ticket sales.
Master data and Looking at corporate data in this context makes it look very straightforward.

transaction data is Both types of data together describe everything associated with core business
often used together activity. For example, Mr David Jameson (Customer) paid £0.89 on 21st
to describe business January 2008 (the transaction) for a loaf of bread (Product) in the Oxford
activity Street store (Store) in central London (Location). Here the combination of
master and transaction data describes the business activity precisely.
Having understood the simple way in which master and transaction data
record business activity, this paper focuses on the former of these, namely
master data. More specifically, we will look at what it is, why it is needed, how
to get started in managing it, and methodologies for implementing master
data management. Master data management forms part of an overall
enterprise governance program that aims to establish trusted data throughout
the enterprise.

WHAT IS MASTER DATA MANAGEMENT?

A formal definition of master data management is as follows:
“Master data management (MDM) is a set of processes, policies,
services and technologies used to create, maintain and manage data
associated with a company’s core business entities as a system of
record (SOR) for the enterprise.”1

Multiple master data Core master data entities include customer, supplier, partner, employee,
entities are asset, etc. Therefore, MDM is about managing customer data, supplier data,
increasingly being employee data, asset data etc., making sure it is formally defined, high quality,
managed in an MDM integrated as a system of record, and that changes to it are synchronised
system across all systems using it. The trend here is towards multiple entity master
data management where a single MDM system can deal with the
management of multiple entities and not just one.

MDM systems should From this definition we can see that MDM is not just about data. It is about
manage data and putting processes and policies in place with respect to governing master data,
processes as well as putting services in place that provide common ways to access,
associated with that maintain and manage it. MDM is, therefore, about data and the processes
data associated with that data. This includes processes associated with business
use of master data as well as processes associated with management of it, e.g.
managing master data definitions (metadata), data modelling, master data
discovery and mapping, master data quality profiling, hierarchy management,
master data cleansing, master data integration, provisioning, and master data
synchronisation.

1
Definition taken from Intelligent Business Strategies master class on Enterprise Data
Governance and Master Data Management.

WHY IS MASTER DATA MANAGEMENT NEEDED?

Consistent master There are many reasons why master data management is needed in business.
data offers many New business challenges such as globalisation, mergers and acquisitions, risk,
business benefits compliance, customer loyalty, supply chain complexity and cost‐cutting would
all benefit from having master data management in place. Take mergers and
acquisitions (M&A), for example. If a company has an MDM system with
Mergers and common definitions for master data (e.g., customer data, supplier data, asset
acquisitions can data, product data, etc.) and a common place where a single view of this data
proceed rapidly if an is held, then smooth handling of mergers becomes possible. For example, the
MDM system is in customer data of an acquired company can be quickly migrated to the MDM
place system to support rapid consolidation of customers in the merged
organisation. The same applies to data on products, suppliers, employees and
assets. All of it can be merged much more rapidly if an MDM system is in
place. In that sense, the business disruption impact of a growth strategy based
around M&A would be minimal and mergers can happen smoothly and
quickly. This approach allows the new merged operation to focus on a larger
customer base, cross sales opportunities, a streamlined supplier base and
better deals on procurement to minimise costs.

Master data is often Also, enterprise master data is generally used across multiple lines of business,
fractured and and therefore it is not uncommon to find subsets of master data in multiple,
partially duplicated underlying, line‐of‐business systems. This occurs in order to support
across multiple continuity of business operations as process execution progresses across the
systems enterprise. Given that different parts of the business are supported by
different systems, master data (e.g. customer data, product data, asset data,
etc.) must flow between these systems to keep operations running as
smoothly as possible and to keep those systems synchronised. The problem
this causes is that master data is fractured and partially duplicated in many
different places. In addition, there is often no complete master data system of
record in existence within the enterprise, except perhaps in a data warehouse
where its use is restricted to analysis and reporting.
A number of Furthermore, when subsets of master data exist in multiple operational
business problems systems, it is not uncommon to see that data being independently maintained
can occur when by each of those systems. When this happens, it is obvious that multiple data
master data is not entry applications can cause problems that affect business operations,
managed centrally business performance and customer satisfaction. These problems include:
• Data conflicts
• Confusion when duplicate master data does not agree
• Process delays and process defects caused by data errors
• Inability to respond when changes to master data require prompt
business action
• Additional operational costs to solve problems caused by data
conflicts

In order to counter these problems companies have over the years put in
place various techniques to synchronise master data subsets across multiple
systems as and when this data changes. These synchronisation techniques
vary widely and include batch processing and file transfer, application
messaging (e.g. via messaging), emailing and re‐keying of data in attached
Excel spreadsheets etc. Over time, all these mechanisms between systems can
result in a ‘spaghetti architecture’ emerging much like that shown in Figure 1:
Point-to-point data
flow and data Master Data Synchronisation – The Spaghetti Architecture
management often
leads to a spaghetti
architecture
Figure 1
Also in this kind of set‐up, cross‐system verification to check if synchronisation
has been carried out correctly is often overlooked. This kind of complexity
sooner or later starts to raise a number of questions. For example:
• Where is the complete set of master data for customer or product or
asset?
• How do you get the master data you need when you need it?
• With so many definitions for master data in so many systems, what is
the meaning of these data items and are there several data items in
multiple systems that mean the same thing?
Master data that is • Can the data be trusted?
unmanaged can • How do you know if the data is complete and correct?
become erroneous • How do you get master data in the form that you need when pieces of
and untrustworthy it reside in multiple systems?
• If changes happen to master data in one system, how long is it before
these changes get to all other parts of the enterprise that need to
know about them?
• How do you know where this data goes and if it flows correctly?

• How do you control it?
And perhaps the most probing question of all is “How much does it cost the
business to operate this way?”
Spaghetti For many companies, the complexity of this kind of architecture is increasing
architectures drive faster than the business value coming from it. Spaghetti architectures, and no
up operational costs single system of record for master data, will slow any business down. It can
and can cause delays cause errors that incur additional operational costs to resolve, delays in
in business operations, delays in decision‐making and delays in overall business
operations responsiveness all of which can impact customer satisfaction.
MDM is about The solution is to reduce complexity and increase agility on a base of trusted

decoupling master data. Fundamental to making that happen is the establishment of a master
data from data management (MDM) system that consolidates master data to create a
applications so that it centralised system of record, and that manages changes to that data across all
can be managed systems. Therefore, MDM is about de‐coupling master data from individual
centrally applications and creating a centralised master data hub that can feed all
operational and analytical systems that need to make use of that data.

THE HIGH LEVEL REQUIREMENT

Integrated master The core requirement in any MDM project is to get master data under control.
data needs to be That means being able to formally define the complete set of data needed for
managed and stored each business entity (e.g. customer, product, employee, etc.) and then
centrally identifying the processes that use and maintain it, the applications that are
used in those processes and precisely where that data currently resides. Once
this is understood, a key requirement is to integrate and consolidate master
data. This is shown in Figure 2.

Integrated Commonly Defined Master Data Held in A
Central Master Data Store
Centralised
Master Data
supplier
Master data integration
Operational
customer Common
Systems
(disparate master data
data definitions asset definitions
for master (MDM‐SBV)
data) product
…….
Capture, Clean,
De‐duplicate
Integrate
Create central data stores for master data by capturing, cleaning and integrating subsets
of master data from disparate systems
Copyright ©Intelligent Business Strategies, 2008
Figure 2
Master data
managagement is However undertaking master data management in any business involves a lot
more than just more than data integration. Full MDM implementation involves:
integrating data to
store it centrally Defining master data using shared business vocabulary (MDM‐SBV ) of
common data names and definitions for use across the enterprise
Locating master data in all disparate systems and identifying
relationships across disparate master data
Mapping master data in disparate systems to common master data
definitions
Creating master data models and XML schemas using MDM‐SBV
definitions so that master data is consistently defined everywhere it is
used
Managing master data models and data integrity rules

Creating master data integration services to acquire, clean, match and
integrate (consolidate) master data to hold in a master data store (as
in Figure 2)
Creating event‐driven and on‐demand master data integration
services
Implementing an enterprise wide master data quality ‘firewall’ using
data quality services
Providing common services that maintain centralised master data to
other applications and processes
Supplying master data changes to all transactional and BI systems that
need it in order to ensure master data consistency and
synchronisation
Managing changes to master data and metadata, e.g. to reflect
product hierarchy changes, organisation unit changes and customer
detail changes, etc.
Managing change to applications and processes to move to a single
data entry system for master data

Changes to master All of this needs to be done using an integrated suite of data management
data need to be fed to tools that support the aforementioned tasks.
all operational and BI
systems that need to Once created, an MDM system should ultimately feed master data to
remain synchronised operational systems and data warehouses as shown in Figure 3.
with it
Master Data Changes Need To Be Synchronised Across
All Systems That Rely on That Master Data
Operational Systems Changes Business Intelligence Systems
sales operations R reporting CPM

finance procurement alerts OLAP/Mine
C asset
operational systems U BI system
prod cust
mart
DW mart
D
mart
operational data master data historical data
& master data services
Master SBV
Figure 3

GETTING STARTED WITH AN MDM PROJECT

Master data management is a key piece of an enterprise data governance
program. If at all possible, MDM should exploit standards, policies, procedures
already in place as part of this program. Getting started with an MDM project
involves a number of steps. These include:
• Building a business case
• Scoping the MDM project
• Assessing the current state of your master data
• Creating an MDM system architecture
• Building a project plan based on an iterative MDM implementation
methodology
• Consideration of MDM implementation options – Build vs. Buy
These are discussed in more detail below in the sub‐sections that follow.
BUILDING A BUSINESS CASE FOR MDM

When building an MDM business case there has to be demonstrable business
benefits to warrant spending the money on implementation. These business
benefits need, if possible, to be tangible — with preference given to benefits
that reduce costs, increase revenue or do both. Therefore, to build a business
case requires understanding of the driver metrics that impact on costs and
revenue. Such ‘cause and effect’ metrics are most likely to be found
documented in a business strategy document or in a performance
management system that provides business scorecards.
An MDM business A critical success factor in any MDM business case is to obtain a detailed

case should be tied understanding of the business strategy and, in particular, the ‘driver’ metrics
to business strategy that cause specific outcomes. A good business strategy should:
• Define strategic objectives
• Define key performance indicators (KPIs) to help measure if the
business is on track to achieving its objectives
• Define KPI targets representing where the business wants to get to in
terms of performance
• Define initiatives to help achieve the stated objectives, budgets and
plans
• Describe KPI relationships so that you can distinguish between driver
and outcome metrics

The more an MDM Understanding business strategy is invaluable because this is where business

project impacts on priorities, strengths, weaknesses, pain points and competitive threats are
‘driver’ metrics the typically all defined. By focussing on prioritised strategic objectives, critical
greater the impact on ‘driver’ KPIs, pain points and the KPIs relating to those pain points, a business
business case can be built to rank candidate MDM projects in order of their potential
performance contribution to key performance targets (outcomes). The more MDM impacts
on ‘driver’ metrics, the greater the impact on business performance.
MDM should In Figure 4, we can see several KPIs on a chart that compares how the

contribute to company stacks up against its competitors. On some KPIs, the company is best
improving KPIs in in class, while on others, the competition is better. Taking a KPI‐like Cost of
order to help make Sales it can be seen that the performance of the company (indicated in red)
the business more for this KPI is not as good as a competitor whose cost of sales is best in class.
competitive Looking at MDM in this context means considering how MDM impacts on KPI
performance. For example, introducing customer MDM could help to reduce
cost of sales by reducing the costs of marketing and sales — and make the
company more competitive on this KPI.
MDM Business Case – How Does MDM Contribute To
Improving Business Performance Metrics
Opportunity Assessment
Customer MDM
Rev. Growth
Sales/Empl. Gross Margin

Product MDM
% Costs of
Cash-To-Cash
Sales, General
Days
& Admin
Your
Company
Days AP (Days Days AR (Day
Purchasing Sales
Outstanding) Outstanding)
BIC
Days Inventory
%…
BIC = Best in Class
Figure 4
Customer data Cost of Sales looks at the process from prospect marketing to opening an

defects can increase account for a new customer. How long does it take and how much does it cost
operational costs and your business to go from prospect marketing, to lead generation, to sales,
reduce customer credit check and creation of a new customer account so that they can trade
satisfaction with your company? If multiple systems are involved in this process, with no
central system of record for customer data, then it may take an unsatisfactory
amount of time. Many manufacturers suffer with this problem. Customer
data defects can slow this process down and require more human resources

than necessary to solve problems caused by defects, thereby driving up costs.
If a company’s competition can do this quicker and at lower cost, then it may
well be the case that the client decides to do business there instead. Loss of
business caused by fractured customer data can be considerable in situations
like this.
There are many other examples that could be given here. When building an
MDM business case, having a detailed understanding of business strategy and
the business processes associated with specific master data is a distinct
advantage. For each identified critical KPI, a business case should define how
the benefits of sharing master data across business processes and applications
would maximise improvement in that KPI. Then, by ranking candidate
business cases, the best MDM return on investment (ROI) project can be
selected from the candidate list. This kind of approach imposes immediate
business focus on an MDM project and results in direct alignment with
business strategy and business priorities with tangible business benefits.
Assess how MDM Therefore, when deciding whether or not the MDM implementation will yield

can help reduce enough ROI, some key questions worth asking include:
operating costs,
improve • How much complexity would be removed from the business if master
responsiveness and data (i.e. data on customer, product, supplier, employee or asset) was
simplify processes centralised and sharable?
• How much could the business save in reducing the cost of operating if
master data was centralised?
• How much more responsive would the business be if everyone could
see changes to master data as soon as they happen and what would
be the payback from being more responsive?
• How many duplicate processes associated with master data could be
removed from the business if master data was centralised?
In many cases, the answers to these questions come out in favour of an MDM
project that could initially be restricted to one data entity such as customer or
product — or alternatively to multiple similar entities e.g., supplier, partner,
or employee. In this latter case, all of the similar entities used in this example
are people, businesses or both. Individuals could be employees or customers
or both while businesses can be customers, suppliers and partners. Therefore,
dealing with the problems that arise in managing data about people or
businesses can be universally applied to all similar entities.
SCOPING AN MDM PROJECT

Having built a business case, the next step is to scope the project. Key
questions at this stage are:

Scoping an MDM • How does MDM fit within the company’s overall enterprise data

system includes it governance program?
being part of an • What data standards should be adopted during the MDM project?
enterprise data • Can existing data management tools such as data modelling, data
governance program quality and data integration be leveraged in the MDM project to get
more value out of existing technology investment?
• What master data entities will be managed by the MDM system, e.g.
customer, product, supplier, employee, etc.?
• What is the scope of the data for each master data entity?
• What is the expected functionality of the MDM system?
While MDM is a key initiative aimed at bringing data associated with core
business entities under control, it should be part of a wider enterprise data
governance program that also includes:
Adoption of data • Data standards, e.g. enterprise adoption of a shared business

governance vocabulary, data integrity rules and taxonomies
standards, policies • Common policies, patterns and processes for enterprise data
and technologies are management and for data integration development e.g. policies on
an essential part of data quality, data integration design, data security data access and
any MDM project data maintenance etc.
• An enterprise data governance technology platform, i.e. a suite of
integrated tools for enterprise data management
• Investment in an enterprise data model
• Enterprise data quality
If any standards, technologies or services have been deployed as part of a data
governance program it should be possible for an MDM project to exploit
these.
Master data should Therefore, if a shared business vocabulary of common data names and data

be described using definitions form part of the enterprise data governance framework it should
enterprise wide be used in an MDM project. If one does not yet exist, an MDM project should
common data names contribute to an enterprise data standards initiative by adding additional data
and data definitions names and data definitions for master data to a shared business vocabulary.
Equally, if a suite of tools have already been purchased for enterprise data
governance (e.g. business vocabulary, data modelling, data discovery, data
profiling, data cleansing and data integration tools) then ideally these tools
should also be used in the development of the MDM system or integrated
with any purchased MDM system.
A decision on what Scoping of an MDM system should also apply to the master data itself. Take

entities to include in customer master data, for example. The scope of customer master data could
an MDM project is stretch beyond structured customer data in various operational systems to
needed as part of the customer intelligence in BI systems and customer related unstructured
scoping task content. Figure 5, shows an insurance example where customer data can
reside in operational systems like an underwriting system, a claims system and
an ERP system as well as in BI systems. However, it also shows related
Structured and information in a content/document/records management system and in
unstructured data
should be©considered
Copyright Intelligent Business Strategies, 2008 13
collaboration tools such as emails to/from customers. For most companies,
the scope of the data tends to remain restricted to structured data rather than
encompassing unstructured data as well. In that sense, many companies look
to strive towards both structured and unstructured.
Master Data Is Required In Many Kinds of Systems And Other Related
Information Can Be Associated With It – E.g. Insurance
E.G Customer Master Data Related Information
Operational Systems BI/DW Content Management & Collaboration

Emails to/from customers
Customer web chats
Emails to brokers about customers
Emails to assessors about customers
Under‐ Content/Document/
Claims ERP BI Collaboration
writing Records Managem’t
system system system tools
system System
Customer Customer Customer Customer

data data data data
Documents about a customer’s insured and declined risks
Customer quotations
Customer risk assessment reports
Customer claims assessment reports and images
Figure 5
When scoping an MDM project, restrictions can be applied to more than the
master data to be managed. Scope can also be applied to the functionality of
the MDM system. By functionality we refer to the capabilities of the MDM
system with respect to its management of data associated with specific
master data entities like customer, product, asset, etc.
An MDM system At a bare minimum an MDM system should manage synchronisation of master

should manage data when it changes, even if there is no consolidated system of record for
master data that data. However, functionality could be much richer than this. For example,
integration and the MDM system could also provide:
synchronisation
• A shared business vocabulary of common data names and data
definitions for the master data entity or entities being managed
• Master data integration – either on demand or to consolidate and
store that data centrally
• A consolidated master data system of record
A centralised system • Master data hierarchy management and version control
of record (SOR) and • Common master data services to (at a minimum, create, read, update
hierarchy and delete) that data
management are also • A centralised data entry system for master data
important
• New business processes associated with master data

The following table shows functionality options that could be provided,
starting with the least functionality and finishing with the most
comprehensive functionality.
Option MDM Functional Scope
1 Master data synchronisation
2 Option 1 + Master data integration + Master data vocabulary
3 Option 2 + A consolidated master data system of record (SOR)
4 Option 3 + Master data hierarchy management
5 Option 4 + Master data CRUD services
6 Option 5 + Single Master data entry system (MDES)
7 Option 6 + New master data business processes

Obviously, the cost and time to implement increases as you move towards
richer functionality options. Nevertheless, many organisations strive to at least
get to option 4.
ASSESSING THE CURRENT STATE OF YOUR MASTER DATA

Now that scope has been discussed, it is important to understand the current
state of your master data so that you can gauge the challenge you face in
bringing it under control. In order to do this you have to identify where in the
enterprise (i.e., in what systems and data stores) disparate master data
currently resides. Disparate master data in this context refers to subsets of
master data that are scattered around the enterprise in the absence of any
centralised managed system of record.
Following business This task should not be underestimated. Doing this well involves a data

processes is an discovery exercise looking at existing core operational and analytical systems
essential part of the as well as following core business processes associated with master data, e.g.
master data all processes associated with customer data. Following processes is necessary
discovery task because understanding how the business uses master data is mission‐critical
and also because additional master data not held in core systems can also be
identified. In an MDM project, it is not uncommon to find that business users
Master data is not are storing additional master data that cannot be entered into core systems.
always kept in core This additional data is often housed in Excel spreadsheets and Access
systems databases.
Also, process overlap and duplication (if any) may also surface, bringing to
light inefficiencies as well as activities where master data defects can result.
All of this strengthens knowledge of business operation, highlights
opportunity to strengthen business cases, and provides a more thorough
assessment and understanding of the challenge ahead.
Disparate master Once disparate master data is discovered, it can be mapped to common

data needs to be master data definitions (master data SBV) and its quality and completeness
mapped to common can be assessed.
definitions

By the end of this exercise, the extent of the challenge that needs to be
undertaken should be well understood and a project plan can be built based
on a thorough understanding of what work needs to be done to bring the data
under control.
MDM SYSTEM ARCHITECTURE

Having scoped the MDM system and assessed the current state of master data
within the enterprise, some kind of target architecture needs to be defined for
what the MDM system should ultimately do. Even if this is not the architecture
of the initial phases of the project, there should still be something to aim at in
terms of what ultimately needs to be built.
Master Data Management Is A Lot More Than

Building A Master Data Hub
An MDM system Business Vocabulary
architecture Data Modelling
Metadata Discovery
represents what you Data Quality Custom App Custom App Packaged App
EDG tools
want the MDM system Data Integration
for MDM
to be capable of ESB
Metadata Master metadata services
repository Disparate DQ rules mappings SBV
definitions R
Master DQ
Services asset
C U
Operational
integration svcs
prod cust
Master data
Systems Master data
(disparate services
data Shared master D (standardise interactions
definitions data with master data)
for master
data) ESB
Packaged App Packaged App BI System

CRUD =
Create, Read, Up
date, Delete Copyright ©Intelligent Business Strategies, 2008
Figure 6
Integrate an MDM Figure 6 shows an example of a technical architecture of a fully implemented

system with enterprise master data management system. It shows how a suite of
enterprise data enterprise data governance tools are used to describe master data in a shared
governance tools business vocabulary, model master data, discover data sources of disparate
master data, map these to the master data target, and assess the quality of
An MDM system data in the data sources. The outcome generates data quality services and
should integrate into data integration services to clean and integrate data into a centralised multi‐
a modern service entity master data store to create a centralised system of record. Data
oriented architecture integration services can also be used to synchronise changes with operational
and BI systems that rely on that data and that need to know about changes.
Finally common master data services surround the data in the centralised
system of record and are available to applications and processed to access and
maintain master data in a standard way. All of this is available on‐demand in a

modern service oriented architecture (SOA) as services on an enterprise
service bus (ESB).
While this may not be exactly the architecture needed in the early phases of
MDM implementation, some kind of equivalent is needed.
BUILDING A PROJECT PLAN

At this stage, it should be possible to build a project plan that defines the tasks
and resources needed for an iterative build of a master data management
system.
The tasks in an MDM It is often seen as best practice for an MDM project plan to have

system project plan implementation tasks that are associated with a repeatable methodology. One
should be aligned such methodology is the data governance methodology shown in Figure 7.
with a repeatable This methodology can be applied to each master data entity, e.g. customer,
methodology product, supplier, employee, asset etc. In other words an entity such as
customer needs to be defined, explored, analysed, improved and controlled.
Define
Control Explore
Data
Governance
Improve Analyse

Figure 7
Drilling into each step in this methodology, it can be seen from the table
below that each step is associated with one or more data governance
processes that need to be applied to each master data entity.

Category/Step Data Governance Processes

Define SBV data definition and data modelling
Explore Data exploration and data mapping
Analyse Data profiling and analysis
Improve Data quality, data integration, data enrichment and
data provisioning
Control Data monitoring
Note that the define and explore steps are not associated with automated
Complete data
governance run‐time processes, since people are needed to define enterprise master data
methodology applied using an enterprise SBV. People are also required in data modelling and need
to EACH master data to have some involvement in data exploration, data mapping and data
entity profiling.
Using this methodology, it is possible to create a set of executable data
Project plans should governance services directly associated with and dedicated to each defined
also allocate time
master data entity. For example, for product master data we would have:
and resources to
change management • Product data definition (SBV)
• Product data modelling (using SBV data definitions)
• Product data exploration and data mapping services (disparate
product data to product SBV‐defined key and attributes)
• Product data profiling and analysis services (on disparate product
data)
• Product data cleansing service (quality)
• Product data integration services
• Product data enrichment services
• Product data provisioning services
• Product data monitoring services
In addition to the implementation of MDM, plans also need to take into
account the impact of an MDM system on existing processes and systems. In
other words is there a ‘knock‐on’ impact that would trigger change
Moving to a single
management across other systems? If only a centralised master data system
master data system
of entry will cause of record is being implemented, then the implications for change are nowhere
significant change in near as severe as the implications of deploying a centralised master data
existing applications system of record that is also to be a master data single data entry system for
and processes specific master data entities. In this latter case, an MDM project that is also

intent on introducing only one central way to maintain master data will cause
considerable change across existing screens, processes, applications, data
stores and even business documents such as forms. In this case, project plans
have to include tasks and allocate time and resources to this additional change
management program once an MDM system is deployed.
MDM IMPLEMENTATION OPTIONS – BUILD VS BUY

MDM solutions can The final step in getting started with MDM is to decide on how to implement
be built or bought the MDM system for the master data entity or entities that need to be
managed. There are two options for implementation – build your own MDM
system or buy an MDM product that can be deployed to manage master data
for your organisation. A number of things may influence this choice but there
are only guidelines to help in making this decision. Broadly speaking it may be
best to build your own MDM system when:

If there is a data store • There is a data store already in existence within the enterprise with a
already in existence, high percentage of master data already integrated
with most of the
• Other systems within the organisation are already using this system as
master data already
integrated, it may be a ‘de‐facto’ MDM data hub
better to build an • Data is published from this system to other operational and BI systems
MDM system to keep them synchronised
It may be best to buy an MDM product when:
If master data is
• Master data is heavily fractured across many different systems
heavily fractured with
a large number of • Significant numbers of process defects and customer problems arising
data entry systems it from missing, inconsistent and erroneous master data
may be better to buy • Problems exist with multiple conflicting master data entry systems
an MDM solution
There are many other factors that will influence the choice to build or buy
including cost to build versus cost to buy and skills needed versus skills
available within the enterprise.
When buying an MDM solution, it is important to understand the business
problem(s) that an MDM solution needs to address, and that an MDM solution
is selected that matches what the business is trying to achieve.
When buying an Referring back to the table of options discussed earlier in this paper under the

MDM solution match section entitled Scoping an MDM Project, this gives a set of MDM system
the MDM solution to options with core MDM functionality that can be matched to solutions
what the business is available on the market. When buying an MDM solution, products can be
trying to achieve evaluated to see what core MDM functionality they support plus how these
solutions stack up in terms of their support for:
• Data governance tools
• Master data quality

• Master data integration services
• A centralised master data store serving as a system of record
• Master data entry
• Master data services
• Master data synchronisation services
• Hierarchy management
• Role‐based security
• Workflow
• Version management
• Scalability
• Integration with other infrastructure technologies e.g. portals, ESB etc.

CONCLUSIONS
Understanding When undertaking a master data management project there is a lot to
existing processes consider. Mission critical success factors include having a deep understanding
associated with of existing processes and business problems caused by fractured master data
master data is key to in order to create solid business cases that will attract executive sponsorship.
success It is also important that MDM is part of a wider enterprise data governance
program and that there is an iterative methodology to support incremental
Data standards roll‐out of each core business entity under the management of an MDM
should be adopted in system.
an MDM system
Data standards also need to be supported with the adoption of a shared
Do not underestimate business vocabulary for master data attributes and standardisation on master
the potential change data quality, data integration and data synchronisation services. Finally,
management caused irrespective of whether an MDM solution is built or bought, the impact on
by the introduction of existing systems and processes, in terms of potential change management,
an MDM system should not be underestimated especially if the MDM system is to become a
single data entry system as well as a centralised system of record.

About Intelligent Business Strategies

Today, successful companies are those that can absorb new information technologies and use them
effectively in their businesses. But faced with so many new technology developments how can IT and
business users possibly keep up? Intelligent Business Strategies is a research and consulting company
whose goal is to help companies understand and exploit new developments in business intelligence,
analytical processing and enterprise business integration. Together, these technologies help an
organisation become an intelligent business.
Intelligent Business Strategies

2nd Floor, Springfield House
Water Lane, Wilmslow
Cheshire SK9 5BG
England
Telephone: (+44)-1625-520700
Internet URL: www.intelligentbusiness.biz

E-mail: ukinfo@intelligentbusiness.biz
Copyright © 2008 by Intelligent Business Strategies

All rights reserved.

Getting Started With MDM

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Getting Started With MDM

Uploaded by

Copyright:

Available Formats

Table of Contents

Getting Started With Master Data Management

What Is Master Data Management? ................................................................................................ 4

Why Is Master Data Management Needed? .................................................................................... 5

The High Level Requirement ........................................................................................................... 8

Getting Started With An MDM Project............................................................................................ 10

Copyright © Intelligent Business Strategies, 2008 2

Master data and Looking at corporate data in this context makes it look very straightforward.

Copyright © Intelligent Business Strategies, 2008 3

WHAT IS MASTER DATA MANAGEMENT?

Copyright © Intelligent Business Strategies, 2008 4

WHY IS MASTER DATA MANAGEMENT NEEDED?

Copyright © Intelligent Business Strategies, 2008 5

Copyright © Intelligent Business Strategies, 2008 6

MDM is about The solution is to reduce complexity and increase agility on a base of trusted

Copyright © Intelligent Business Strategies, 2008 7

THE HIGH LEVEL REQUIREMENT

Copyright © Intelligent Business Strategies, 2008 8

Operational Systems Changes Business Intelligence Systems

sales operations R reporting CPM

Copyright © Intelligent Business Strategies, 2008 9

GETTING STARTED WITH AN MDM PROJECT

BUILDING A BUSINESS CASE FOR MDM

An MDM business A critical success factor in any MDM business case is to obtain a detailed

Copyright © Intelligent Business Strategies, 2008 10

The more an MDM Understanding business strategy is invaluable because this is where business

MDM should In Figure 4, we can see several KPIs on a chart that compares how the

Sales/Empl. Gross Margin

Customer data Cost of Sales looks at the process from prospect marketing to opening an

Copyright © Intelligent Business Strategies, 2008 11

Assess how MDM Therefore, when deciding whether or not the MDM implementation will yield

SCOPING AN MDM PROJECT

Copyright © Intelligent Business Strategies, 2008 12

Scoping an MDM • How does MDM fit within the company’s overall enterprise data

Adoption of data • Data standards, e.g. enterprise adoption of a shared business

Master data should Therefore, if a shared business vocabulary of common data names and data

A decision on what Scoping of an MDM system should also apply to the master data itself. Take

Operational Systems BI/DW Content Management & Collaboration

Customer Customer Customer Customer

An MDM system At a bare minimum an MDM system should manage synchronisation of master

Copyright © Intelligent Business Strategies, 2008 14

ASSESSING THE CURRENT STATE OF YOUR MASTER DATA

Following business This task should not be underestimated. Doing this well involves a data

Disparate master Once disparate master data is discovered, it can be mapped to common

Copyright © Intelligent Business Strategies, 2008 15

MDM SYSTEM ARCHITECTURE

Master Data Management Is A Lot More Than

Packaged App Packaged App BI System

Integrate an MDM Figure 6 shows an example of a technical architecture of a fully implemented

Copyright © Intelligent Business Strategies, 2008 16

BUILDING A PROJECT PLAN

The tasks in an MDM It is often seen as best practice for an MDM project plan to have

Copyright © Intelligent Business Strategies, 2008 17

Category/Step Data Governance Processes

Copyright © Intelligent Business Strategies, 2008 18

MDM IMPLEMENTATION OPTIONS – BUILD VS BUY

When buying an Referring back to the table of options discussed earlier in this paper under the

Copyright © Intelligent Business Strategies, 2008 19

Copyright © Intelligent Business Strategies, 2008 20

Copyright © Intelligent Business Strategies, 2008 21

About Intelligent Business Strategies

Intelligent Business Strategies

Internet URL: www.intelligentbusiness.biz