A Reference Process Model for Master Data Management

Andreas Reichert, PD Dr.-Ing. Boris Otto, Prof. Dr. Hubert Österle
Leipzig
February 28, 2013
A Reference Process Model for Master Data Management

© IWI-HSG – Leipzig, February 28, 2013, Reichert, Otto, Österle / 2
Agenda
1. Introduction
2. Related Work
3. Research Methodology
4. Results Presentation
5. Conclusion and Outlook

1.1 Business Requirements for Master Data
 Master data describes key business objects in an enterprise (e.g. Stahlknecht &
Hasenkamp 1997; Mertens 1997)
 Examples are product, material, customer, supplier, employee master data
 Master data of high quality is important for meeting various business requirements (e.g.
Knolmayer & Röthlin 2006; Kokemüller 2010; Pula et al. 2003)
 Compliance with legal provisions
 Integrated customer management
 Automated business processes
 Effective and efficient reporting

Legend: Data quality pitfalls (e. g. migrations, process touch points, poor corporate reporting.
Master Data Quality
Time
Project 1 Project 2 Project 3
1.2 Difficulties in practice when it comes to managing master data quality
Case of Bayer CropScience (cf. Brauer 2006)

1.3 Master Data Management must be organized
 Master data management is an application-independent function (Smith & McKeen
2008)
 The organizational structure of master data management has been research to some
extent
 Empirical analysis regarding the positioning of master data management within an organization
(Otto & Reichert 2009)
 Master data governance design (Otto 2011)
How to design master data management processes?

1.4 Enterprises are in need of support in this matter
* Source: Workshop presentations at the CC CDQ Workshops by companies
Company Main Challenges
 Establishing a central master data Shared Service Center for
governance and operational tasks
 Support of high quality master data for online sales channels
 Central governance for new data processes
 Set up of a central master data organization for material, customer,
and vendor master data due to changing business model, and hence,
processes
 New organization of medical and safety division
 Design of data governance processes for material master data

Model Focus Assessment
(Dyché & Levy 2006) Customer data integration
No focus on activities
(English 1999): Total Quality data Management (TQdM)
(Loshin 2007) Data governance
(Weber 2009) Data governance reference model
2.1 Related Work in Research and Practice
Process models related to master data management
Role models related to master data management
Model Focus Assessment
ITIL IT service management
No integrated process focus
(Batini & Scannapieco
2006)
Data quality management activities
Otto et al. (2012) Software functionality

3.1 Research Methodology and Process
2009 2010 2011 2012
1. Identify problem & motivate
1.1 Identification of challenges within practitioners community
2. Define objectives of a solution
2.1 Focus group A (2009-12-01)
2.2 Principles of orderly reference modeling
A
6. Communication
6.1 Scientific paper at hand
4.1 Three participative case studies
3.1 Literature review
3.2 Principles of orderly reference modelling
3.3 Process map techniques
3.4 Focus groups B (2010-11-26), C (2011-11-24)
B C
5.1 Focus group C (2011-11-24)
5.2 Three participative case studies
5.3 Multi-perspective evaluation of reference models
C
3. Design &
development
4. Demonstration
5. Evaluation

4.1 Overview of the Reference Process Model for Master Data Management
Data Life
Cycle
Data Support
Data
Architecture
Data Model
Data Quality
Assurance
Standards &
Guidelines
Strategic
Functions
1.1
2.1
2.2
2.3
Governance
Strategy
2.4
3.2
3.1
Operations
Develop
and adapt
vision
Align w/
business &
IT strategy
Define
strategic
targets
Set up
responsibi-
lities
Define
roadmap
Develop
communic.
and change
Adapt
nomencla-
ture
Adapt data
life cylce
Adapt
standards &
guidelines
Adapt
authori-
zation
concept
Adapt
support
processes
Adapt
measure-
ment
metrics
Adapt
reporting
structures
Define
quality
targets
Monitor &
report data
quality
Initiate
quality
improve-
ments
Identify
data
require-
ments
Model data
Analyze
implications
Test &
implement
changes
Roll out
data model
changes
Identify
business
issues
Identify
require-
ments
Model data
architecture
Model
workflows /
UIs
Analyze
implications
on change
Roll out
data
architecture
Test &
implement
Manage
requests
Create data
Update
data
Release
data
Use data
Archive /
delete data
Adapt user
trainings
Provide
trainings
Provide
user
support
Provide
project
support
Process Area Main Process Process
1
2
3
1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6
2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.1.6
2.2.1 2.2.2 2.2.3 2.2.4 2.2.5
2.3.1 2.3.2 2.3.3 2.3.4 2.3.5
2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.4.6
3.1.1 3.1.2 3.1.3 3.1.4 3.1.5 3.1.6
3.2.1 3.2.2 3.2.3 3.2.4

4.2 Iterative Design and Evaluation in Three Case Studies
Case A B C
Industry High Tech Engineering Retail
Headquarter Germany Germany Germany
Revenue 2011 [bn €] 3.2 2.2 42.0
Staff 2011 11,000 11,000 170,000
Role of main contact person for
the case study
Head of Enterprise
MDM
Head of Material
MDM
Project Manager
MDM Strategy
Initial situation Specification of existing
data management
organization
Merger of two
internal data
management
organizations
Design of new data
management
organization within
project

4.3 Design Decisions
Design Decision Justification A B C
Process “Define strategic
targets” removed (1.1.3)
 Activities integrated in process “Align with business/IT strategy”
 No explicit MDM strategic targets required as they should be
integrated in existing target systems
X
Process “Model
Workflows/UIs (User
Interfaces) moved from
main process “Architecture”
to “Standards & Guidelines”
(2.4.3)
 Focus for activity is set on conceptual design rather than technical
implementation aspects
 Technical implementation needs to be covered by IT-processes.
Case A only covers the conceptual part of the workflow design. The
implementation process will be described outside of this process
X
Process “Monitor & report”
(in context of Quality
Assurance) moved from
main process “Support” to
“Quality Assurance” (3.2.4)
 Mix of governance and operational activities in main process
“Governance”
 However, focus is set on end-to-end process including both aspects
X
Process “Test & Implement”
(in context Architecture)
removed (2.4.5)
 Testing activities defined within IT-processes and do not need to be
covered by data management processes
 Removal will eliminate double definitions within company
X X
Processes of main process
“Life Cycle” renamed (3.1)
 Naming of processes aligned with company specific naming
conventions as processes were already defined
X X X
Process “Mass data
changes” added to
“Support” (new 3.2.5)
 New process added as activity is performed on continuous base
and should be covered by data management processes
X X

4.3 Design Decisions (continued)
Design Decision Justification A B C
Process “Develop and adapt
vision” removed (1.1.1)
 Company strategies not defined by visions but by strategic targets X
Processes “Adapt data life
cycle”, “Adapt standards and
guidelines”, “User trainings”,
and “Support Processes”
merged to “Standards for
operational processes”
(2.1.2 - 2.1.6)
 Activities of all processes remain existing
 Goal is simplification of process model
 Description of all activities, which have been merged to the new
process, will be created on the work description level, which will
underlay the process model for execution of processes (including
process flows, responsibilities, etc)
X
Processes “Test and
implement (data model)”
and “Roll out data model
changes” removed (2.3.4 -
2.3.5)
 Activities defined within IT service portfolio outside of this process
model
 As activities are already defined, they do not need to be covered
within this structure
X
Main process “Data
Architecture” removed (2.4)
 Activities defined within IT service portfolio
 Clear separation between business requirements and modeling of
data and IT realization (integration architecture etc.)
X
Process “Data analysis” in
main process “Support”
added (new 3.2.6)
 Requests for one-time analysis of master data as service offering
defined which are not covered by standard reports
X

5.1 Conclusion and Outlook
 Results
 The reference model supports the design process of master data managements organizations
as well as the specification of existing structures
 The reference model was evaluated from an economic, deployment, engineering and
epistemological perspective (cf. Frank 2006) by researchers and practitioners
 Contribution
 Innovative artifact in a relevant field of research
 Explication of the design process
 Engaged scholarship case
 Limitations
 Qualitative justification of design decisions
 Further design/test cycles necessary
 Applicable for large enterprises mainly

PD Dr.-Ing. Boris Otto
University of St. Gallen
Institute of Information Management
Boris.Otto@unisg.ch
+41 71 224 3220
Your Speaker
This research was supported by the Competence Center Corporate Data Quality (CC CDQ) at the
University of St. Gallen.

References
BRAUER, B. 2009. Master Data Quality Cockpit at Bayer CropScience. 4. Workshop des Kompetenzzentrums Corporate Data
Quality 2 (CC CDQ2). Luzern: Universität St. Gallen.
DYCHÉ, J. & LEVY, E. 2006. Customer Data Integration, Hoboken (USA), John Wiley.
ENGLISH, L. P. 1999. Improving Data Warehouse and Business Information Quality, New York et al., Wiley.
FRANK, U. 2006. Evaluation of Reference Models. In: FETTKE, P. & LOOS, P. (eds.) Reference Modeling for Business Systems
Analysis. Hershey, PA: IGI Publishing.
KNOLMAYER, G. F. & RÖTHLIN, M. 2006. Quality of Material Master Data and Its Effect on the Usefulness of Distributed ERP
Systems. In: RODDICK, J. F. (ed.) Advances in Conceptual Modeling - Theory and Practice. Berlin: Springer.
KOKEMÜLLER, J. 2010. Master Data Compliance: The Case of Sanction Lists. 16th Americas Conference on Information Systems.
Lima, Peru: Universidad ESAN.
MERTENS, P. 1997. Integrierte Informationsverarbeitung, Wiesbaden, Gabler.
OTTO, B. 2011. A Morphology of the Organisation of Data Governance. 19th European Conference on Information Systems.
Helsinki, Finland.
OTTO, B., HÜNER, K. & ÖSTERLE, H. 2012. Toward a functional reference model for master data quality management. Information
Systems and e-Business Management, 10, 395-425.
OTTO, B. & REICHERT, A. 2010. Organizing Master Data Management: Findings from an Expert Survey. In: BRYANT, B. R.,
HADDAD, H. M. & WAINWRIGHT, R. L. (eds.) 25th ACM Symposium on Applied Computing. Sierre, Switzerland.
PULA, E. N., STONE, M. & FOSS, B. 2003. Customer data management in practice: An insurance case study. J. of Database Mark.,
10, 327-341.
SMITH, H. A. & MCKEEN, J. D. 2008. Developments in Practice XXX: Master Data Management: Salvation Or Snake Oil?
Communications of the AIS, 23, 63-72.
STAHLKNECHT, P. & HASENKAMP, U. 1997. Einführung in die Wirtschaftsinformatik, Berlin, Springer.

A Reference Process Model for Master Data Management

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (14)

Similar to A Reference Process Model for Master Data Management

Similar to A Reference Process Model for Master Data Management (20)

More from Boris Otto

More from Boris Otto (20)

Recently uploaded

Recently uploaded (20)

A Reference Process Model for Master Data Management