MDM Best Practices Final Report 31012010 Public

See discussions, stats, and author profiles for this publication at: https://www.researchgate.
net/publication/267508624
Master Data Management "Best Practices" Benchmarking Study 2010 –

Publicly Available Report
Data · March 2010

DOI: 10.13140/2.1.4201.9849
CITATION READS
1 3,391
1 author:
Tomi Dahlberg
Turku School of Economics / Board professional: Finance & IT Ltd.s
114 PUBLICATIONS 1,077 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Maritime Digital Supply Space View project
Inter-organizational governance of IT and IT cooperation View project
All content following this page was uploaded by Tomi Dahlberg on 29 October 2014.
The user has requested enhancement of the downloaded file.

Master Data Management “Best Practices”
Benchmarking Study – Publicly Available Part
How to Develop Master Data (Critical Business

Data) Management to provide better support to
business planning, execution and reporting
Tomi Dahlberg
Final Report 1
tomi.dahlberg@hse.fi, 050 550 5718 © Tomi Dahlberg, 15.03.2010
Note to the Reader
Helsinki School of Economics merged with two

other Universities and became Aalto School of
Economics from January 1st, 2010
In this presentation the HSE presentation layout

is, however, still used to provide consistency to
those interim reports of the study, which were
published in 2009.
Final Report 2
© Tomi Dahlberg, 15.03.2010
Contents
1. Management Summary
2. Introduction
3. Key Findings and Conclusions of the Research (Summary)
4. Master Data Challenge: Why Are Master Data Projects Started?
5. Master Data Management Building Blocks Model Applied in this Study
6. Master Data Management Good Practices and Comments
1. MDM Vision
2. MDM Strategy
3. MDM Governance
4. MDM Organization
5. MDM Processes
6. MDM Information Infrastructure
7. MDM Metrics
7. Conclusion: Researcher’s Three Step Development Program
Final Report 3
1. Management Summary: Current Status
The management and coding of business critical and other master data is
fragmented and inconsistent. Consequently data content quality is poor.
This has very serious adverse business impacts such as lack of transparency to
business operations, lost revenues, unnecessary costs, operational
inefficiencies, and erroneous management reporting
This also lowers possibilities to receive benefits from business process

improvement and other IT related / enabled development initiatives
Senior managers who do not understand the business criticality of critical

business data tolerate this situation and regard it normal, which is not true
A few enterprises improve systematically the management of master data by

harmonizing and consolidating the coding and processing of master data
aligned to their strategy, business and operational models. As the maturity of
Critical and other Master Data Management increases in these enterprises they
experience all the time stronger positive business impacts leading to
competitive advantages
Final Report 4
Management Summary: Reasons for the
Status and Way Forward
The root cause of the fragmentation in master data is in lack of
management. The strategy, business and operational models of an
enterprise are not taken down to into master data management
objectives, development plans and governance, nor are the
consequences of (poor) master data quality monitored
The technological flavor of the master data concept as well as the

typical practice to develop master data in fragments with the focus
of an ERP, CRM, PDM etc. project adds to fragmentation
The improvement of critical business data coding and data content

quality is significantly easier than for example the improvement of
a business process enabled by an ERP system. Significant
improvements can be achieved without any investments by
managing better the coding of master data as well as data handling
processes. The most important decision is to start.
Final Report 5
Management Summary: Three Step

Development Program
1. Senior management understanding and buy-in
2. Analyze current and desired status and define

development plan to close the gaps
3. Development projects to fix Critical Business

and Master Data
Note! Master data is not a project but continuous

process that needs to be improved continuously.
Projects are used to speed up development
Final Report 6
2. Introduction: Research Project in Brief
Research and research support
Aalto University / HSE Business technology – researcher and interviewer
(Tomi Dahlberg)
Solteq – facilitator and research support as well as CxO Mentor Oy
Participants in alphabetical order:

Elisa
Fennia
Kone Oyj
Onninen
Outokumpu
Outotec
Puolustusvoimat
Rautakesko
Rautaruukki Oyj
Wärsilä
Final Report 7
Introduction: Timeline of the Project
Project timeline
Scope definition and project organizing from May 2009 to
September 2009 with participant recruiting (limitation to 10)
Kick-off in October 2009
Preliminary Report in November 2009
Preliminary Final report for comments and Final report in January
2010, Final Report in February, Participant specific reports
thereafter (these are confidential)
Data Collection and Other Methods

Interviews in participating organizations from executive,
managerial and operative levels as applicable and available
Qualitative data analysis, framework modeling and literature study
Final Report 8
Introduction: What is Master Data and
Critical Business Data?
Master Data means coded non-transactional data used by an organization
to conduct its business. Master Data is used in transaction data, typically to
identify and classify transactions.
Critical Business Data is that Part of Master Data which contains the most
used data objects of master data, for example customer data. Critical
Business Data is used by various stakeholders in an enterprise, from local
units to enterprise headquarter and in different process and function tasks.
Problems and errors in Critical Business Data coding as well as in data

content have serious adverse business consequences such as
Lost revenues
Higher and unnecessary costs
Lower productivity and efficiency
Misleading control and business reporting data, planning and monitoring difficulties
Anecdotes are provided on the next slide. Their abundance tells a story
Final Report 9
Introduction: Anecdotes
“Two sellers from the same company for the same product had a car collision at the parking place of our
company. We never bought anything from them.”
“After my appointment three sales managers from Vendor X called me within the two first weeks and told
me that they are the key contact person for my enterprise in vendor X. I preferred other vendors since I
had no interest to waste my time in discussions with them about their organization.”
“We got the two first places in an expensive sales and RFP process for an X million contract. We learned
only afterwards that we competed against ourselves. We lost time and more than 500.000 Euros.”
“Customers expect us to know the designs of machines which we have installed and which we have
maintained. We hardly have any up-to-date documents on what the designs are, what repairs we have
carried out and what spare parts we have delivered. My estimate is, that because of this situation, we
loose millions of euros annually due to extra work, costs and unnecessary replacements not to mention
lost business opportunities.”
“In our warehouse we have two boxes of the same item next to each other. They, however, have
different identification codes. The other box is seldom used and is always full whereas the other is
almost all the time short which causes assembly delays from time to time. Unnecessary waiting time
probably has a price tag of X hundreds of thousands every year for this product alone.”
”Our HR had searched three weeks for me based on my maiden name before they found me from the
same building as the person who had requested my search. We had to redo the entire internal search for
my maternity leave replacement. Due to lost time I had too little time to train my replacement.”
”When the data content of two integrated information systems were compared less than 10 % of the data
matched correctly. The other information system is our customer billing system. What a mess!”
Final Report 10
Introduction: Critical Business Data
Objects and Other Names for Master Data
Typical Critical Business Data objects – usually 5-10 data object groups
Customers
Vendors
Sold products* and services*
Manufactured products* and services*
Purchased products* and services*
Personnel
Accounting keys (managerial accounting)
Installed base**, service base**
Other – enterprise specific objects, for example model/design library, functional
location
Typically there are all in all 60 – 200 master data objects in an organization
Other names for master data

Basic data – does not describe the business criticality of this data
Parameter data - even more technical term than master data
Static data – bad name as Critical Business Data changes all the time
•May consist of materials, components, items, products, services, their combinations and includes data structures
Final Report 11
** Contains also transactional data – stored part of data transforms into critical business data © Tomi Dahlberg, 15.03.2010
Introduction: Best Practice Concept
Best practice means such

Organizational structures (for example master data governance roles and
responsibilities, master data organization) and/or,
Processes (for example master data development, maintenance and reporting
processes) and
Relationship mechanisms (such as arrangements which produce alignment,
cooperation and co-development between relevant master data stakeholders, typically
between head-quarter, business unit and IT functions and between local and global
users of master data)
Which lead to more effective (business value created with and from master data) and
efficient (cost-efficient processing and management of master data ) master data
management in an organization
Proven with measurable evidence (metrics) agreed by relevant master data
stakeholders
At the moment it is premature to use the term best practice in the context of
master data processing and master data management
Available practical knowledge is too limited, fragmented and controversial
Theoretical insight backed by empirical findings is not available, research is only
beginning
”Good Practices related to key issues” is a better term and is used in this report
Final Report 12
Introduction: Best Practice Concept

processes) and
stakeholders
beginning
Final Report 13
Introduction: Definition of Best Practice

Concept
processes) and
stakeholders
beginning
Final Report 14
3. Key Findings: Partial Solutions Prevail and
Cause Inefficiency
1. Project participants are among the forerunners of master data
management in Finland and probably also globally – still each
participant has major challenges when compared to good practices
2. Partial solutions prevail and cause serious inefficiencies
1. Focus on operational master data governance and organization (roles and
responsibilities) and master data processes (development and maintenance)
2. At the same time, there are typically several conflicting role and responsibility
structures as well multiple differently organized processes within an organization
3. Ownership of master data is unclear
1. Even when ownership, other roles and responsibilities are defined and agreed the
meaning and consequences may not be understood by role owners
4. Stakeholders’ interests regarding master data makes it difficult to
achieve progress – especially if this issue is not managed
5. Master data management vision (business targets), strategy (road-map
to achieve targets) and reporting (efficiency and business impact) are
areas which have received clearly too little attention
1. Master Data development typically starts from the operational middle, that is from
daily governance, organization and process issues – and too often stops there
2. Reporting on the use of master data in business and on the impacts of master
data or its absence is almost entirely non-existing
Final Report 15
Five Most Surprising Findings to the

Researcher
1. High tolerance for inefficiencies and conflicting solutions
Results probably from limited executive level understanding and from the technical nature of
the concept. Critical Business Data is introduced to underline the business criticality of MD
Results also from perceptions that organizations have survived so far with poor master data
Individuals working with master data experience additional challenges
2. Complexity of master data objects
Customer and product data structures are examples of data complexity
3. Difficulty of master data identification
Especially installed base, design library and functional location master data objects are both
complex and long-living (15, 50, 100 years). Yet, even long-living master data is maintained
4. Progress in master data management seems to require exceptionally strong co-
development at all main levels of an organization
Strong and concrete support from senior management (“We need to fix this bit by bit for these
business reasons without giving up”), and
Good understanding of the key issues and implementation ability in managerial level (“We are
committed to define, agree and implement good practices bit by bit”)
Commitment to work with master data according to defined processes at operational level (“We
understand why master data needs to be in good shape and for that reason we do our share”)
Corporate/headquarter/global – business division/unit/process – local/sub-process level issues
5. Lack of understanding regarding the need to manage information
As an example, CIO stands for Chief Information Officer and IT is about information
processing. Yet CIOs and IT departments do not manage information. Master Data and
especially the content of this data may not be owned by anybody in an organization
Final Report 16
How to Interpret these Findings?
Root cause: poor executive level management with no links to strategy,

business and operational model
In participating organizations, persons working with master data management
issues are
Very committed to improving master data management
Strive hard to achieve improvements often under heavy pressures caused largely by partial
solutions and related internal politics
Often insightful and inventive in master data management
Sometimes very skillful in social networking and in persuading people to improve master data
management within their organizations
Have very often worked for long times with master data and have therefore good insight to the
key issues of master data management – yet their role is seldom organization wide and not
always even business unit wide
Organizations are not “doomed” to have fragmented poor quality Master Data
When an organization knows what to do and follows that plan most of Critical Business Data is
good shape within one fiscal year, since each new master data item either improves or
worsens the situation
The improvement of Master Data Management is a business issue – only business is able to
know the content of master data - which also requires good information management and IT
skills
Final Report 17
Conclusion 1 – From Master Data Management to

Critical Business Data Management
Even that part of Master Data which is Critical Business Data is poorly
managed with significant business value potential
Critical Business Data, such as customer, vendor, product data etc., is typically
fragmented and non-harmonized and consequently the quality is poor
Some parts may be excellently managed at the same time as other parts are practically
not at all managed
Improvements in Critical Business Data and Master Data management
as a whole have strong business cases
Planning, execution and steering of daily business becomes more efficient
Only harmonized Master Data facilitates transformation toward harmonized
processes and operations. Unnecessary costs as well as other inefficiencies can
also be made redundant.
Management with information and management reporting improve and offer the
ability to achieve fact based business insight
Lost business opportunities are turned into additional business opportunities.
Improvements in master data are achievable
For example, the combination of an organization wide plan and bit by bit
implementation makes improvement possible within a reasonable time with
organizational buy-in and learning effects.
Final Report 18
Conclusion 2 – Shift Focus from Operational to
Strategic Master Data Management Issues
Currently main focus areas are operational master data process,
governance and organization as well as IT infrastructure issues
Operational issues have to be taken care of but lead seldom to good
organization wide business motivated solutions
Clearly more emphasis needs to be placed on the business

targets of master data development, maintenance and usage, on
organization wide master data management issues and on the
business impact management of master data usage
What are our Critical Business Data and Master Data objects?
What are the business reasons, targets and uses of such data objects
when various stakeholder interests are considered?
How do we best achieve organization wide Master Data management
targets?
Involvement required from senior executives, managers and specialist
The interests of various stakeholders from local units, processes and
functions to corporate unit, process and functions need to be considered and
balanced
Final Report 19
Evidence Supporting the Two Conclusions and the

Base-Line for Strong Business Cases
How can the value of master data be determined?
Asset value (the value of master data as a whole):
Imagine that your organization would accidentally loose Critical Business Data (Master Data),
for example customer names, addresses and other customer master data fields
– By calculating the cost of rework and losses from not having access to master data during
the rework period it is possible to estimate the direct financial value of master data.
– The indirect financial costs and losses resulting from poor customer experience, brand
damages, lost business opportunities etc. may also be estimated
– Compare this to a situation where an organization has fragmented poor quality customer
master data. On business transaction level the outcome is almost similar to that of having
lost master data, but may remain invisible since one transaction at a time is impacted
Transaction value (the value of master data in new transactions)
Master data stores knowledge of persons working in an organization in coded form and makes
that available to other persons (for example product data is made available to those who use
that information where then ever they are)
– If master data is correct it is automatically used correctly in all transactions linked to that
data (e.g. production, logistics, billing, payments, accounting etc.). This is sometimes
called “master data inheritance”
– Compare this to a situation where an organization has fragmented poor quality master
data with some automated and some manual links between information systems.
Transactions must to checked and/or complemented in many ways including manual work
to verify data. If Master Data is perceived as unreliable persons typically take actions to be
able to perform their jobs, for example by purchasing additional products just in case.
Final Report 20
4. Master Data Challenge
Why Is Master Data Fragmented?
Key reasons to start a master data project are:
Implementation of a new major system; ERP, PDM, SCM, CRM, BI/DW, …
Master Data is a concept originally coined by SAP
Implementation of a new system by migrating bad quality data without master
data harmonization seriously jeopardizes the achievement of business benefits
Migration to new IT platform or technology base; for example from
mainframe based systems to modern software architecture based systems
Increased use of electronic commerce and electronic transacting
Part of databases are opened for two way communication
Since these reasons to improve master data and its management

seldom aim at organization wide solutions master data solutions
resulting from these projects lead to partial solutions
Limited to specific process(es), geographical/functional unit(s), information
system(s) and/or information system module(s) (=the scope of the project)
Project are typically started at different times with different priorities. Each
master data implementation/migration typically results in a different solution
Final Report 21
Master Data Challenge

One Enterprise Motivated Master Data Projects
“One enterprise”, “one business unit”, “one contact point to a customer”, …
objectives with the target to have globally, regionally and/or within business units
similarly operating units, processes and/or strong cross-selling between units
Harmonized and standardized master data management with well organized master data
processes is one of the required steps to reach this objective.
More efficient and manageable enterprise and IT architectures through

consolidation, standardization and harmonization of information systems and IT
services – IT equivalent to the above
Cost reduction by removing obsolete, redundant and overlapping information systems and/or by
reducing the number instances
Increased simplicity and maintainability of IT at lower cost level
Managed architecture to increase agility both globally and locally
Since these reasons have an organization wide focus also resulting solutions are
more likely organization wide and help to fix the root cause
Impacts the funding of organization wide master data management development positively
Lack of concrete understanding and slowness of progress may lead to frustration, the
combination of organization wide plan and bit by bit implementation is advisable
Need to conduct activities on all organizational levels and in all units to include multiple
stakeholder perspectives may lead to reduced scope. The combination of organization wide plan
and bit by bit implementation starting from critical business data is again advisable
Final Report 22
Enterprise and IT Architectures versus Flexibility -
The Road from Business Silos to Agility Takes Time
Architecture maturity
Business Standardized Optimized Business

Silos systems core modularity
Global flexibility
+
High
overall
agility
and
inno-
vative- Local flexibility
ness
Source: Weill & Ross: Architecture as a strategy

MIT Sloan Center for Information System Research, Harvard Business Books
Master Data harmonization follows a similar path -> make optimized core period short Final Report 23

BI and Reporting Motivated Master Data Projects
Business Intelligence and Reporting projects, for example a Data Warehouse &
reporting project, address issues which can be solved only with better master data
Examples of typical questions reflecting business requirements
How much have we sold products and services to various customers, customer segments, etc.?
What are our contacts and channels to customers? How profitable are customers? How loyal are our
customers, do we have churn risk? Could we increase sales with customer profile based selling, cross-
selling or other means?
How much have we purchased from various vendors?
What are our contacts and channels to vendors? What materials, spare parts, components, products have
we purchased? Are our vendors reliable and responsive?
What materials, spare parts, components, products do we have in our warehouses? What should we have
in our warehouses to facilitate production planning and production, maintenance of assets, asset
management, deliveries, after-sales services, maintenance services? How profitable are various products,
services and operations?
What persons with specific skills have we available for positions, roles, projects, etc ?
These projects may have a partial or organization wide / business unit wide focus
with strong information management emphasis
Master Data and Critical Business Data object definition skills usually available
The connection between reporting possibilities and master data may still not be fully understood
due to high reporting granularity and business issues may also be perceived as IT issues
Need to address the reporting needs of daily operational activities, business/regional units and
organization level may be hard to solve
The ETL approach (extract, transact, load) is often used to ”clean” the basic transactional data by
regrouping or complementing fragmented master data to provide sensible reports which are
reliable enough. Report users should understand the consequences of this ”cleaning”.
Final Report 24
Integrated Processes Motivated Master Data Projects
Initiatives to establish highly integrated processes with process
and information system integration across information systems
Enterprises who have ERP, PDM, SCM, CRM and ebusiness systems with
layered IT architectures may start initiatives where so called second wave
process integration is carried out
Information systems are used to support more integrated processes preferably
through unified platforms.
Examples of possible second wave processes
– Order to cash or contact to cash
– Manufacture to inventory, manufacture to project or manufacture to
customer
– Purchase to pay or procure to pay
Harmonized and standardized master data across systems is required
The Master Data databases of legacy systems could be too inflexible for these
purposes, however, few better tools are available at the moment.
A separate global master data database which is linked to relevant information
systems and which includes the history of master data appears as one useful
solution
Final Report 25
Two Specific Issues in Master Data Challenge
The use of ”installed base”, “functional location” and “design library” in

after-sales and maintenance business especially in project manufacturing
type industries
Original constructions or parts of them may be in use for decades
Need to access original designs, for example CAD or other design drawings, in after-sales,
repair and maintenance businesses
Need to follow the replacement history of items, for example what the new item identification
for the item which replaces the original item or the previous item identification
Does the history of customer relations create similar opportunities in service

industries such as banking, insurance or telecom? I claims it does
The costs and ownership of master data

Master data has several stakeholders and is used for multiple purposes.
Consequently who should absorb the costs of master data process development and
maintenance? Senior management input is required to achieve organization wide
solutions
If the ownership of master data is given to a major stakeholder how are the interests
of other stakeholders fulfilled? Senior management input is required. One possible
solution is organize the ownership of master data under a neutral owner such as
centralized master data team. Relationship mechanisms are needed
Final Report 26
Final Comments about the Master Data Challenge
Analogy: Master data is the DNA of an organization

DNA is unique for each organization although it has an identifiable structure
DNA impacts the development of the organization and establishes also the
coded history of non-transactional data within an organization.
If DNA is poor the organization is vulnerable to inefficiencies and in the worst
case to failure
Master data requirements are different at corporate/headquarter,
business unit and local levels – balancing of requirements is needed
The structures and processes of organizations chance continuously
due to mergers and acquisitions, reorganizations, key person
changes and market needs
All these impact master data and increase the probabilities of inefficiencies
The heritance/transformation history of master data is an important part of
master data management especially for installed base, functional location and
design libraries
Unified globally standardized codes for organizations, products,
constructions etc are rare and unlikely to appear in the near future
Rather, according to Metcalf’s law the amount of data doubles every 12 months
Final Report 27
5. Master Data Management Building Blocks

Model; Gartner Group’s MDM Model Was Used to
Structure Interviews and Good Practices
The Seven Building Blocks of Master Data Management
Final Report 28
Remarks on Master Data Management Building
Blocks
1. The framework is a useful and practical model of key master data
management issues
Is consistent with generic development models such as PDCA: Plan (MDM
vision, strategy, governance), Do/Deliver (MDM organization, process,
information infrastructure), Compare/Control (MDM metrics), Act (return to
planning)
Includes structures, processes and relationship mechanisms
Is business oriented
2. The benefits of using a holistic framework are profound
A holistic organization wide approach to master data offers the
Possibility to implement effective and efficient practices and to get rid off the
current situation with different master data processes and fragmented solutions
Possibility to bring clarity to master data concept owner, process owner, other role
and responsibility definitions and to get rid off the current unclear practices
Supports the inclusion of all key aspects
From vision and strategy to metrics and reporting
In the development of Master Data management progress is needed
simultaneously in several building blocks
A holistic framework makes business objectives driven development possible with
the combination of a organization wide plan and bit by bit implementation
Final Report 29
Pre-requisites for Master Data Management

Development
Organization culture which promotes Master Data management
development
Executive level understanding and firm support so that master data development
is driven firmly and decisively
Managerial and expert level drive with relationship mechanisms
Funding – enterprise or at minimum business unit level funding available
Proper understanding regarding the meaning of roles and

responsibilities
Too often the meaning of roles and responsibilities is understood only formally
(roles may also be accepted by or be forced on persons who have no intentions
or skills to act according to the role definition)
With proper understanding the logic for allocating and agreeing ownership, other
roles, decision making rights and tasks becomes possible in a way, which
implements Master Data vision and strategy
Experts of software vendors are often used to configure master data file
structures due to the technical complexity of this task. It is imperative that
business knowledge is involved
Final Report 30
Best Practice Scales:
Capability Maturity Matrix Applied (levels 0 to 5)
Item Status of Scale/width within Continuous

activity, process or an organization improvement,
Maturity mechanism and time applied benchmarking
level
Level: 0 None (not recognized)
Level: 1 Ad-hoc Project scope None to ad-hoc
Repeated, but not Scope is the sum Ad-hoc
Level: 2 defined of several projects
Repeated and defined Partially harmonized Internally systematic
Level: 3 (same approach) use, early phase benchmarking started
Level: 4 Guided with clear Mostly used, 1-2 benchmarking
metrics several years evaluations
Level: 5 Optimized, metrics Organization wide, Several bench-
show high performance several years marking evaluations
Agreed best practices do not exist at the moment and best organizations have
reached or are approaching good practices. Therefore a scale for good practice is
presented and used instead of this scale
Final Report 31
Good Practice Scales:

Capability Maturity Matrix Applied (levels 0 to 3)
Item Status of Scale/width within Continuous

activity, process or an organization improvement,
Maturity mechanism and time applied benchmarking
level
Level: 0 None (not recognized)
Level: 1 Ad-hoc Project scope None to ad-hoc
Several competing Project scopes, Ad-hoc with project
Level: 1 ½ ad-hoc approaches little cooperation scope
Repeated, not defined Scope is the sum Ad-hoc
Level: 2 (different approach) of several projects
Level: 2 ½ Repeated, main Scope harmonization Internally systematic,
approach identified started still partial
Level: 3 Repeated and defined Partially harmonized Internally systematic
(same approach) use, early phase benchmarking started
Final Report 32
6. Master Data Management Good Practices:
6.1. MDM Vision
1. Organization’s business objectives and drivers for
master data management and related master data
processes have been defined (effectiveness)
2. Key Master Data objects (Critical Business Data) have

been identified, defined and agreed by the main
stakeholders of the organization
3. Objectives for unified and harmonized master data

processes and master data management have been
defined (efficiency; costs and productivity)
4. Effectiveness and efficiency objectives are transformed

into concrete measurable metrics which are used to
measure the achievement of these objectives
Final Report 33
Findings
Even most advanced organizations have fragmented

vision documents for master data management
Vision is typically not organization wide
Very often written by person(s) who are responsible for operative
master data management activities and since their mandate is
not organization wide the document is not either organization
wide although offers good starting point
Improvements needed in business and strategy related issues as
well as in including the input of some relevant stakeholders
Vision document may have been shown to and discussed with
senior executives, usually with limited buy-in
This MDM building block has received too little attention
Final Report 34
Master Data Management Good Practices:
6.2.MDM Strategy (Development Plan)
1. Key stakeholders of master data have been identified for most
important Master Data objects (Critical Business Data) so that their
interests as well as the most typical uses of master data have been
documented (for example in a master data architecture document).
This makes is possible to define concrete benefits and targets for
development efforts as a whole and for each key stakeholder
2. Funding, organizational-cultural and other prerequisites for master

data management development have been established
3. On overall strategic action plan / road-map for Master Data

management has been defined with development responsibilities.
This plan guides the implementation of master data management
toward the achievement of MDM vision
4. This overall plan is transformed into concrete measurable road-map

metrics which are used to measure the achievement of objectives
stated in master data management vision and strategy
Final Report 35
Findings
Even most advanced organizations have fragmented

development plans for master data management
Development plans are mainly focused on
How to improve operational master data processes with related
organizations and governance,
How to expand the scope of managed master data, for example by
rolling out managed master data processes into new sites, units
and/or geographical areas for an ERP, PDM. SCM or CRM system
How to improve the quality of managed master data with
harmonization and rule handling
Development plans are mostly written by person(s) who are
responsible for operative master data management activities
This MDM building block has received too little attention.

Significant rapid improvements can be achieved by
focusing more on MDM vision and strategy with senior
executive involvement and buy-in
Final Report 36
6.3-6.4 MDM Governance and Organization (1)
6.3 Governance
1. Roles, decision-making rights and responsibilities have been defined for key
master data development and maintenance tasks (concept ownership, process
ownership, data content ownership, typically as a RACI chart) so that those who
are given roles and responsibilities understand what their roles and responsibilities
mean and behave accordingly
2. Organizational structures, processes and relationships mechanisms have been

defined and established for master data management. These structures,
processes and relationship mechanisms have started to operate and shown that
they are able to balance differences in interests and make decisions
3. Governance model (RACI chart) includes the input of key stakeholders at least
corporate headquarter, business units and IT unit as well as local and global
perspectives
4. Governance model is aligned with other governance models. This means that
master data governance model is consistent with Corporate and IT governance
models
Final Report 37

6.3-6.4 MDM Governance and Organization (2)
6.4 Organization
1. Roles defined in master data governance model have been allocated. In

addition to that master data development and maintenance teams are
organized with sufficient resources evaluated from time to time so that
each role and person has measurable performance objectives
2. Master data teams and persons having master data related roles have
received sufficient education and training on the basis of role, team
and task related skill and knowledge definitions
3. Links to key stakeholders are defined and regular contacts with them
are executed to understand changes in their needs (user satisfaction)
4. Organization and its performance is improved systematically based on

performance metrics
Final Report 38
Findings
1. Participating organizations do not have unified processes and/or some master

data processes are not managed (at all). This is reflected also in governance and
organization which are also partial
Partial solutions in governance, organization and processes lead to variance in master data
quality
2. Consequently Master Data governance structures and organizations are

fragmented and usually even partly missing
Role, responsibility and other governance definitions cover only well managed processes and
units
Internal difficulties even conflicts due to dissimilar governance and organizational
arrangements
Data ownership, especially data content ownership as a whole least developed
3. Alternative placements of master data teams within organizations

In a business unit – major stakeholder (risk that the needs of other stakeholders receive less
attention)
In a business unit - neutral unit selected to avoid overly dominance of major stakeholder(s)
In an IT unit – business understanding is a challenge, requires strong data content ownership
within business units. Note ! Master Data management is more a business than IT issue.
Between business and IT – appears ideal if good mastery of both business and IT is achieved.
Job rotation may be needed from time to time to maintain this type of understanding
Final Report 39

6.5 MDM Processes
1. Master data development and maintenance processes are defined and
implemented for key Master Data (Critical Business Data) objects in a
unified way or if processes differ such differences are based on
decisions with strong business motivation. Master Data processes
have effectiveness and efficiency targets
2. It is possible to follow the status of Master Data processes from task

to task at Master Data transaction level as well as the heritance of
master data to business transactions
3. The processes balance the needs of various stakeholders typically

local - global needs, site - business unit – head quarter needs
4. Process performance is improved constantly on the basis of

effectiveness (business impact) and efficiency (process performance)
metrics
Final Report 40
Findings
Two types of processes appear to work well – corrections immediately at the

source of data
1. Centralized process divided into global and global master data domains with centralized input of global data
Opening or modification of global data is requested by a local user e.g. with an electronic form
Master Data is opened or modified centrally based on local request
Automatic rule based controls on master data
Request is returned to the local user with correction demand if data is missing or incorrect
Inform the local user about new or modified data record(s) upon successful input e.g. by stamping the
electronic form
Opening, maintenance and removal locally for local data
Workflow management and timeline targets for centrally opened global data
2. Centralized process divided into global and global master data domains with local input
Centralized team performs automatic rule based controls for global data immediately for all new or
changed data records with the authority to requires corrections for incorrect global data
Centralized team is responsible concepts, development, training and provides support to local users
Inflexibility caused by excessive automatic rule based controls is a risk after some time
Why do other types of processes not work properly?

Fully centralized, for example into accounting
This may lead to local, unofficial registers due to the perceived inflexibility of a fully centralized process
Decentralized/local without strong centralized power for global data
Leads typically to massive master data quality problems with expensive periodic clean-ups. Still, master
data is seldom in good condition even after clean-ups
Clearly worst process is the one where master data record is opened blank with minimal data and filled
gradually afterwards without any rule based controls
Almost all participating organizations have master data processes which work
well but also processes which are far from working well
Final Report 41

6.6 MDM Information Infrastructure (Tentative)
1. Master Data information infrastructure is consistent with overall IT

architecture at infrastructure, applications, information, process and
enterprise levels
2. There are flexible data access, integration and reporting tools by which
the transfer of transaction data between integrated information systems
can be monitored to check that master data records match between
integrated systems
3. Master Data information infrastructure elements work reliably according

to defined service and operational level agreements (SLA/OLA)
4. Reporting tools provide information on how master data management

vision and strategy objectives as well as process performance targets
are met. Reporting also show the quality of master data inheritance
(proportion of correct automatic master data creation in business
transactions)
Final Report 42
Findings
1. Typically master data databases reside within some major information system
(for example ERP, PDM, SCM, CRM, HR)
Use of master data is usually perceived inflexible especially in other information systems
The data bases of these information systems have not been designed to handle master data of
multiple information systems
2. Separate tools and/or Master Data databases/data warehouse tools (for example
Arch for HR, SAP “MDM module”, Ineo, Microsoft SQL server add-ons, IBM MDM,
Oracle MDM), development going on in this area
3. Opening tools -> unified electronic forms within a platform with single input, use
of email, workflow management
4. Checking against separate registers for example for addresses, some data items
5. Fragmentation and poor quality of master data seen in most organizations

cannot be fixed with an additional information system or tool. Other MDM
building blocks have to be fixed first
Final Report 43

6.7 MDM Metrics
1. Reports on metrics make it possible to evaluate progress in the achievement

of master data management objectives (vision and strategy)
2. Reports produce information on the use of master data in business with

benefit impact or losses if master data is not correct (effectiveness metrics),
for example based on inheritance analysis
3. Reports produce information on the performance of master data processes

and organization (efficiency in terms of costs and time to open / modify data)
4. Reports delivered to key stakeholders are used and actions to improve

master data management are started
Findings
This MDM development block is least developed. Organizations typically have
reports which show how many records have been processes and how many
duplicates have been found
Final Report 44
7. Conclusion: Researcher’s Three Step
Development Program
1. Get senior level understanding and buy-in

Critical Business Data is the most important part of Master Data
Organizations can achieve improvements fairly rapidly by doing right
things
2. Analyze current and desired status and define development plan
Benchmarking (unless you have done it already) which reveals
immediate improvement potentials
Domain specific data status check and evaluation to understand the
quality of master data. This provides additional improvement
suggestions
Strategy and road-map development plan to create organization
wide targets for MDM building blocks and to establish a bit by bit
implementation plan. This reveals both quick wins and long term
benefits
3. Development projects to fix Critical Business and Master Data
Bit by bit implementation of development plan
Final Report 45
Three tips for quick fixes
1. Check identification coding of critical business

data objects
Inconsistent descriptive coding has significant negative
effects and blocks development
2. Check errors immediately in new master data
items with a control process and make those
who input the data to also fix errors
Errors are easier and cheaper to correct when information
is fresh
3. Create awareness for the business importance
of critical business data (master data) to
support the two above.
Final Report 46
View publication stats

MDM Best Practices Final Report 31012010 Public

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

MDM Best Practices Final Report 31012010 Public

Transféré par

Droits d'auteur :

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

Master Data Management "Best Practices" Benchmarking Study 2010 –

Data · March 2010

Maritime Digital Supply Space View project

Inter-organizational governance of IT and IT cooperation View project

The user has requested enhancement of the downloaded file.

How to Develop Master Data (Critical Business

Note to the Reader

Helsinki School of Economics merged with two

In this presentation the HSE presentation layout

3. Key Findings and Conclusions of the Research (Summary)

4. Master Data Challenge: Why Are Master Data Projects Started?

5. Master Data Management Building Blocks Model Applied in this Study

6. Master Data Management Good Practices and Comments

7. Conclusion: Researcher’s Three Step Development Program

1. Management Summary: Current Status

This also lowers possibilities to receive benefits from business process

Senior managers who do not understand the business criticality of critical

A few enterprises improve systematically the management of master data by

The technological flavor of the master data concept as well as the

The improvement of critical business data coding and data content

Management Summary: Three Step

1. Senior management understanding and buy-in

2. Analyze current and desired status and define

3. Development projects to fix Critical Business

Note! Master data is not a project but continuous

Participants in alphabetical order:

Introduction: Timeline of the Project

Data Collection and Other Methods

Problems and errors in Critical Business Data coding as well as in data

Other names for master data

Introduction: Best Practice Concept

Best practice means such

Best practice means such

Introduction: Definition of Best Practice

Five Most Surprising Findings to the

Root cause: poor executive level management with no links to strategy,

Conclusion 1 – From Master Data Management to

Clearly more emphasis needs to be placed on the business

Evidence Supporting the Two Conclusions and the

Since these reasons to improve master data and its management

Master Data Challenge

More efficient and manageable enterprise and IT architectures through

Business Standardized Optimized Business

Source: Weill & Ross: Architecture as a strategy

Master Data Challenge

Two Specific Issues in Master Data Challenge

The use of ”installed base”, “functional location” and “design library” in

Does the history of customer relations create similar opportunities in service

The costs and ownership of master data

Analogy: Master data is the DNA of an organization

5. Master Data Management Building Blocks

The Seven Building Blocks of Master Data Management

Pre-requisites for Master Data Management

Proper understanding regarding the meaning of roles and

Item Status of Scale/width within Continuous

Good Practice Scales:

Item Status of Scale/width within Continuous

2. Key Master Data objects (Critical Business Data) have

3. Objectives for unified and harmonized master data

4. Effectiveness and efficiency objectives are transformed

Even most advanced organizations have fragmented

This MDM building block has received too little attention

2. Funding, organizational-cultural and other prerequisites for master

3. On overall strategic action plan / road-map for Master Data

4. This overall plan is transformed into concrete measurable road-map