getting started with mdm

Table of Contents

By Mike Ferguson

Intelligent Business Strategies

March 2008

Getting Started With Master Data Management

Prepared for:

Intelligent Business Strategies


Copyright © Intelligent Business Strategies, 2008 2

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



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 and sales order taking to supplier procurement, product fulfilment, product delivery, invoicing and payment collection. Yet, when you boil down the complexity of business operations and look at data underpinning it in simple terms, there are two broad categories of structured data that any business relies on. These are:

• Master data • Transaction data

Master data is simply the data associated with core business entities such as customer, employee, supplier, product, partner, asset, etc. This data can reside in many different systems. For example, customer data may reside in a sales force automation system, an e‐commerce system, a marketing system, a 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 needed in multiple systems to control continuity of business operations as processes progress throughout the enterprise.

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.

Looking at corporate data in this context makes it look very straightforward. Both types of data together describe everything associated with core business activity. For example, Mr David Jameson (Customer) paid £0.89 on 21st January 2008 (the transaction) for a loaf of bread (Product) in the Oxford 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.

Two broad categories of structured data underpin business operations - master data and transaction data

Master data is data associated with core business entities such as customer, product, asset, etc.

Master data is often present in multiple systems

Master data and transaction data is often used together to describe business activity



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

Core master data entities include customer, supplier, partner, employee, asset, etc. Therefore, MDM is about managing customer data, supplier data, employee data, asset data etc., making sure it is formally defined, high quality, integrated as a system of record, and that changes to it are synchronised 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. From this definition we can see that MDM is not just about data. It is about putting processes and policies in place with respect to governing master data, as well as putting services in place that provide common ways to access, maintain and manage it. MDM is, therefore, about data and the processes 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.

Multiple master data entities are increasingly being managed in an MDM system

MDM systems should manage data and processes associated with that data



WHY IS MASTER DATA MANAGEMENT NEEDED?

There are many reasons why master data management is needed in business. New business challenges such as globalisation, mergers and acquisitions, risk, 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 common definitions for master data (e.g., customer data, supplier data, asset data, product data, etc.) and a common place where a single view of this data is held, then smooth handling of mergers becomes possible. For example, the customer data of an acquired company can be quickly migrated to the MDM 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.

Also, enterprise master data is generally used across multiple lines of business, and therefore it is not uncommon to find subsets of master data in multiple, underlying, line‐of‐business systems. This occurs in order to support continuity of business operations as process execution progresses across the 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.

Furthermore, when subsets of master data exist in multiple operational systems, it is not uncommon to see that data being independently maintained by each of those systems. When this happens, it is obvious that multiple data entry applications can cause problems that affect business operations, 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

Consistent master data offers many business benefits

Mergers and acquisitions can proceed rapidly if an MDM system is in place

Master data is often fractured and partially duplicated across multiple systems

A number of business problems can occur when master data is not managed centrally



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:

Master Data Synchronisation – The 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?

• Can the data be trusted? • How do you know if the data is complete and correct? • How do you get master data in the form that you need when pieces of

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?

Point-to-point data flow and data management often leads to a spaghetti architecture

Master data that is unmanaged can become erroneous and untrustworthy



• 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?”

For many companies, the complexity of this kind of architecture is increasing faster than the business value coming from it. Spaghetti architectures, and no single system of record for master data, will slow any business down. It can cause errors that incur additional operational costs to resolve, delays in operations, delays in decision‐making and delays in overall business responsiveness all of which can impact customer satisfaction.

The solution is to reduce complexity and increase agility on a base of trusted data. Fundamental to making that happen is the establishment of a master data management (MDM) system that consolidates master data to create a centralised system of record, and that manages changes to that data across all systems. Therefore, MDM is about de‐coupling master data from individual applications and creating a centralised master data hub that can feed all operational and analytical systems that need to make use of that data.

Spaghetti architectures drive up operational costs and can cause delays in business operations

MDM is about decoupling master data from applications so that it can be managed centrally



THE HIGH LEVEL REQUIREMENT

The core requirement in any MDM project is to get master data under control. That means being able to formally define the complete set of data needed for each business entity (e.g. customer, product, employee, etc.) and then 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

supplier

product

asset

customer

…….

Master d

ata integration

Capture, Clean, De‐duplicate Integrate

OperationalSystems(disparate

data definitions for master

data)

Create central data stores for master data by capturing, cleaning and integrating subsets of master data from disparate systems

CentralisedMaster Data

Common master data definitions (MDM‐SBV)

Copyright ©Intelligent Business Strategies, 2008

Figure 2 However undertaking master data management in any business involves a lot more than data integration. Full MDM implementation involves:

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

Integrated master data needs to be managed and stored centrally

Master data managagement is more than just integrating data to store it centrally



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

All of this needs to be done using an integrated suite of data management tools that support the aforementioned tasks. Once created, an MDM system should ultimately feed master data to operational systems and data warehouses as shown in Figure 3.

master data& master data services

Master SBV

C

R

U

D

prod cust

asset

DW

mart

mart

mart

BI system

reporting

alerts OLAP/Mine

CPM

historical data

sales

procurementfinance

operations

operational systems

operational data

ChangesOperational Systems Business Intelligence Systems

Master Data Changes Need To Be Synchronised Across All Systems That Rely on That Master Data


Figure 3

Changes to master data need to be fed to all operational and BI systems that need to remain synchronised with it



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.

A critical success factor in any MDM business case is to obtain a detailed understanding of the business strategy and, in particular, the ‘driver’ metrics 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

An MDM business case should be tied to business strategy



Understanding business strategy is invaluable because this is where business priorities, strengths, weaknesses, pain points and competitive threats are typically all defined. By focussing on prioritised strategic objectives, critical ‘driver’ KPIs, pain points and the KPIs relating to those pain points, a business case can be built to rank candidate MDM projects in order of their potential contribution to key performance targets (outcomes). The more MDM impacts on ‘driver’ metrics, the greater the impact on business performance.

In Figure 4, we can see several KPIs on a chart that compares how the company stacks up against its competitors. On some KPIs, the company is best in class, while on others, the competition is better. Taking a KPI‐like Cost of Sales it can be seen that the performance of the company (indicated in red) for this KPI is not as good as a competitor whose cost of sales is best in class. 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.

Rev. Growth

Gross Margin

% Costs of Sales, General

& Admin

Days AR (Day Sales

Outstanding)Days Inventory

Days AP (Days Purchasing

Outstanding)

Cash-To-Cash Days

Sales/Empl.

Opportunity Assessment

BIC% …

BIC = Best in Class

Your Company

Product MDM

Customer MDM

MDM Business Case – How Does MDM Contribute To Improving Business Performance Metrics

Figure 4

Cost of Sales looks at the process from prospect marketing to opening an account for a new customer. How long does it take and how much does it cost your business to go from prospect marketing, to lead generation, to sales, credit check and creation of a new customer account so that they can trade 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

The more an MDM project impacts on ‘driver’ metrics the greater the impact on business performance

MDM should contribute to improving KPIs in order to help make the business more competitive

Customer data defects can increase operational costs and reduce customer satisfaction



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.

Therefore, when deciding whether or not the MDM implementation will yield enough ROI, some key questions worth asking include:

• How much complexity would be removed from the business if master data (i.e. data on customer, product, supplier, employee or asset) was 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:

Assess how MDM can help reduce operating costs, improve responsiveness and simplify processes



• How does MDM fit within the company’s overall enterprise data governance program?

• What data standards should be adopted during the MDM project? • Can existing data management tools such as data modelling, data

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:

• Data standards, e.g. enterprise adoption of a shared business vocabulary, data integrity rules and taxonomies

• Common policies, patterns and processes for enterprise data management and for data integration development e.g. policies on data quality, data integration design, data security data access and 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.

Therefore, if a shared business vocabulary of common data names and data definitions form part of the enterprise data governance framework it should be used in an MDM project. If one does not yet exist, an MDM project should contribute to an enterprise data standards initiative by adding additional data 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.

Scoping of an MDM system should also apply to the master data itself. Take customer master data, for example. The scope of customer master data could stretch beyond structured customer data in various operational systems to customer intelligence in BI systems and customer related unstructured 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 information in a content/document/records management system and in

Scoping an MDM system includes it being part of an enterprise data governance program

Adoption of data governance standards, policies and technologies are an essential part of any MDM project

Master data should be described using enterprise wide common data names and data definitions

A decision on what entities to include in an MDM project is needed as part of the scoping task

Structured and unstructured data should be considered



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

Under‐writing system

Claims system

BI system

Collaboration tools

Customer data

Customer data

Customer data

E.G Customer Master Data

Operational Systems

Documents about a customer’s insured and declined risks Customer quotations Customer risk assessment reportsCustomer claims assessment reports and images

Emails to/from customersCustomer web chatsEmails to brokers about customers Emails to assessors about customers

Content/Document/Records Managem’t

System

Content Management & CollaborationBI/DW

Related Information

ERPsystem

Customer data


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.

At a bare minimum an MDM system should manage synchronisation of master data when it changes, even if there is no consolidated system of record for that data. However, functionality could be much richer than this. For example, the MDM system could also provide:

• 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 • Master data hierarchy management and version control • Common master data services to (at a minimum, create, read, update

and delete) that data • A centralised data entry system for master data • New business processes associated with master data

An MDM system should manage master data integration and synchronisation

A centralised system of record (SOR) and hierarchy management are also important



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.

This task should not be underestimated. Doing this well involves a data discovery exercise looking at existing core operational and analytical systems as well as following core business processes associated with master data, e.g. all processes associated with customer data. Following processes is necessary 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 are storing additional master data that cannot be entered into core systems. This additional data is often housed in Excel spreadsheets and Access 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.

Once disparate master data is discovered, it can be mapped to common master data definitions (master data SBV) and its quality and completeness can be assessed.

Following business processes is an essential part of the master data discovery task

Master data is not always kept in core systems

Disparate master data needs to be mapped to common 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

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

Master DQServices

Master data

integration svcs

EDG tools for MDM

Master metadata servicesMetadata repository mappingsDisparate

definitionsSBV

Business VocabularyData ModellingMetadata DiscoveryData QualityData Integration

ESB

ESB


DQ rules

Figure 6

Figure 6 shows an example of a technical architecture of a fully implemented enterprise master data management system. It shows how a suite of enterprise data governance tools are used to describe master data in a shared business vocabulary, model master data, discover data sources of disparate master data, map these to the master data target, and assess the quality of data in the data sources. The outcome generates data quality services and data integration services to clean and integrate data into a centralised multi‐entity master data store to create a centralised system of record. Data 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

An MDM system architecture represents what you want the MDM system to be capable of

Integrate an MDM system with enterprise data governance tools

An MDM system should integrate into a modern service oriented architecture



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.

It is often seen as best practice for an MDM project plan to have implementation tasks that are associated with a repeatable methodology. One such methodology is the data governance methodology shown in Figure 7. This methodology can be applied to each master data entity, e.g. customer, product, supplier, employee, asset etc. In other words an entity such as customer needs to be defined, explored, analysed, improved and controlled.

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.

Data Governance

Define

Explore

AnalyseImprove

Control

The tasks in an MDM system project plan should be aligned with a repeatable methodology



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 run‐time processes, since people are needed to define enterprise master data using an enterprise SBV. People are also required in data modelling and need to have some involvement in data exploration, data mapping and data profiling.

Using this methodology, it is possible to create a set of executable data governance services directly associated with and dedicated to each defined master data entity. For example, for product master data we would have:

• 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 management across other systems? If only a centralised master data system of record is being implemented, then the implications for change are nowhere near as severe as the implications of deploying a centralised master data system of record that is also to be a master data single data entry system for specific master data entities. In this latter case, an MDM project that is also

Complete data governance methodology applied to EACH master data entity

Project plans should also allocate time and resources to change management

Moving to a single master data system of entry will cause significant change in existing applications and processes



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 The final step in getting started with MDM is to decide on how to implement 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:

• There is a data store already in existence within the enterprise with a high percentage of master data already integrated

• Other systems within the organisation are already using this system as a ‘de‐facto’ MDM data hub

• Data is published from this system to other operational and BI systems to keep them synchronised

It may be best to buy an MDM product when:

• Master data is heavily fractured across many different systems

• Significant numbers of process defects and customer problems arising from missing, inconsistent and erroneous master data

• Problems exist with multiple conflicting master data entry systems

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.

Referring back to the table of options discussed earlier in this paper under the section entitled Scoping an MDM Project, this gives a set of MDM system options with core MDM functionality that can be matched to solutions available on the market. When buying an MDM solution, products can be 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

MDM solutions can be built or bought

If there is a data store already in existence, with most of the master data already integrated, it may be better to build an MDM system

If master data is heavily fractured with a large number of data entry systems it may be better to buy an MDM solution

When buying an MDM solution match the MDM solution to what the business is trying to achieve



• 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

When undertaking a master data management project there is a lot to consider. Mission critical success factors include having a deep understanding of existing processes and business problems caused by fractured master data in order to create solid business cases that will attract executive sponsorship. 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 roll‐out of each core business entity under the management of an MDM system.

Data standards also need to be supported with the adoption of a shared business vocabulary for master data attributes and standardisation on master data quality, data integration and data synchronisation services. Finally, irrespective of whether an MDM solution is built or bought, the impact on existing systems and processes, in terms of potential change management, 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.

Understanding existing processes associated with master data is key to success

Data standards should be adopted in an MDM system

Do not underestimate the potential change management caused by the introduction of an MDM system



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.

Internet URL: www.intelligentbusiness.biz E-mail: [email protected]


Copyright © 2008 by Intelligent Business Strategies All rights reserved.

Intelligent Business Strategies 2nd Floor, Springfield House

Water Lane, Wilmslow Cheshire SK9 5BG

England Telephone: (+44)-1625-520700