MA Stammdatenmanagement Wiki

University of St.
Gallen
Graduate School of Business, Economics, Law and Social Sciences
Master Thesis
Applying Semantic Wiki Technology

to Corporate Metadata Management
An Implementation Project at Bayer CropScience
Referee: Prof. Dr. Hubert Österle
Submitted by
Mark Takeshi Egloff

Feldstrasse 10
8400 Winterthur
St. Gallen, November 17th, 2008

ii
Abstract
The effective and efficient management of data is a fundamental requirement for any com-
pany to successfully operate in the business environment. Concepts of metadata manage-
ment can be applied to improve the usage and maintenance of corporate data. This research
aims to address corporate metadata management by drawing upon concepts from semantic
wiki technology. This approach has so far been insufficiently investigated in scientific and
practical literature.
This thesis employs the Design Research paradigm as a methodological framework to struc-
ture the process of developing and evaluating an IT-artifact. The IT-artifact is realized as a
prototype of a semantic wiki, based on the MediaWiki software and enhanced through the
Semantic MediaWiki extension. It serves the purpose of a business data dictionary that con-
tains semantically precise definitions and descriptions about master data. The prototype is
intended to be implemented at Bayer CropScience (BCS) – an international agrochemical
company and partner of the collaborative research program out of which this thesis
emerged.
Data is collected from employees of BCS, who are the prospective users of the prototype.
For the development of the prototype, expert interviews are conducted to identify the
needs of the users, based on which requirements and specifications are determined. Subse-
quently, the same users test the completed prototype by solving various tasks with it. The
results from this test are then used to evaluate the prototype in different aspects.
This thesis demonstrates the feasibility of implementing semantic wiki technology in a work-
ing system for the purpose of corporate metadata management. The contribution of the
research relies on the detailed documentation of the development and evaluation process of
the prototype. It offers valuable insights into a structured method of developing IT-artifacts
and inspires further research in similar domains.
Keywords:
Metadata Management, Semantic MediaWiki, MediaWiki, Semantic Wiki, Design Research

iii
Kurzfassung
Effektives und effizientes Datenmanagement ist eine erfolgskritische Voraussetzung für Un-
ternehmen, um erfolgreich am Markt zu agieren. Konzepte des Metadatenmanagements
können dazu beitragen, die Datennutzung und Datenpflege im Unternehmen zu verbessern.
Das Ziel der vorliegenden Arbeit ist die Anwendung von semantischer Wiki-Technologie in
Verbindung mit dem Metadatenmanagement eines Unternehmens. Ein solcher Ansatz ist bis
heute zu wenig in der akademischen und praxisbezogenen Literatur abgehandelt worden.
In dieser Arbeit dient das „Design Research“-Paradigma als methodologischer Rahmen zur
strukturierten Entwicklung und Evaluation eines IT-Artefakts. Das IT-Artefakt wird durch ei-
nen Software-Prototypen eines semantischen Wikis realisiert, welches auf der „MediaWiki“-
Software basiert und durch die „Semantic MediaWiki“-Erweiterung ergänzt wurde. Es erfüllt
den Zweck eines Unternehmensdaten-Handbuchs (engl.: business data dictionary), das se-
mantisch präzise Definitionen und Beschreibungen von Stammdaten enthält und welches bei
Bayer CropScience (BCS) implementiert werden soll. BCS ist ein international agierendes Un-
ternehmen im Bereich der Agrochemie und Partner des Forschungsprojektes, das den Rah-
men dieser Arbeit bildet.
Für die Datenerhebung wurden Mitarbeiter von BCS befragt, welche die zukünftigen Benut-
zer des Prototyps repräsentieren. In Experteninterviews erarbeiteten sie relevante Inputs,
die zur Identifikation von Benutzer-Bedürfnissen und zur Definition der Anforderungen und
Spezifikationen des Software-Prototyps genutzt wurden. Dieselben Mitarbeiter testeten im
Anschluss an die Interviews den fertiggestellten Prototyp auf seine Praxistauglichkeit, indem
sie damit unterschiedliche Aufgaben lösten. Eine Evaluation des Prototyps erfolgte auf Basis
dieser Testergebnisse.
Die vorliegende Arbeit demonstriert die Realisierbarkeit eines funktionierenden Metada-

tenmanagement-Systems, welches auf semantischer Wiki-Technologie basiert. Der Beitrag
der Arbeit liegt einer detaillierten Dokumentation des durchgeführten Entwicklungs- und
Evaluationsprozesses des Prototyps. Die Dokumentation erlaubt einen wertvollen Einblick in
eine strukturierte Vorgehensweise zur Realisierung eines IT-Artefaktes und kann als Grund-
lage für Untersuchungen in angrenzenden Forschungsgebieten dienen.
Stichworte:
Metadatenmanagement, Semantic MediaWiki, MediaWiki, Semantisches Wiki, Design Re-

search
iv
Table of Content
1 Introduction ..................................................................................................... 1
1.1 Initial problem statement ............................................................................................ 1
1.2 Research objectives and target audience.................................................................... 2
1.3 Research methodology ................................................................................................ 3
1.4 Outline of the thesis .................................................................................................... 6
2 Definition and description of key concepts ....................................................... 8
2.1 Corporate metadata management.............................................................................. 8
2.1.1 Metadata in the corporate context...................................................................... 8
2.1.2 Management of corporate metadata ................................................................ 12
2.2 Wikis in the corporate context .................................................................................. 14
2.2.1 The concept of wikis ........................................................................................... 14
2.2.2 Fields of application for corporate wikis ............................................................ 16
2.3 Semantic wikis in the corporate context ................................................................... 18
2.3.1 The concept of the Semantic Web ..................................................................... 18
2.3.2 The concept of semantic wikis ........................................................................... 19
2.3.3 Semantic wikis for corporate metadata management ...................................... 26
3 Designing a corporate semantic wiki at Bayer CropScience ............................. 28
3.1 Introduction ............................................................................................................... 28
3.1.1 General information about BCS ......................................................................... 28
3.1.2 Project background ............................................................................................ 28
3.1.3 Design approach ................................................................................................. 30
3.2 As-Is-Analysis of the MDM Handbook 2.0 ................................................................. 31
3.2.1 Formal description ............................................................................................. 31
3.2.2 Shortcomings and missing functionalities.......................................................... 34
3.3 Definition of requirements and specifications .......................................................... 37
3.3.1 Requirements ..................................................................................................... 37
3.3.2 Specifications...................................................................................................... 39
3.4 Description of the Proof of Concept.......................................................................... 42
3.4.1 Application architecture ..................................................................................... 42
3.4.2 User interface ..................................................................................................... 43
3.4.3 Content structure ............................................................................................... 46
v
4 Evaluation of the IT-artifact ............................................................................ 47

4.1 Evaluation approach .................................................................................................. 47
4.2 Testing against initial specifications .......................................................................... 49
4.2.1 Sufficiently implemented specifications ............................................................ 49
4.2.2 Partially implemented specifications ................................................................. 51
4.2.3 Insufficiently implemented specifications ......................................................... 52
4.3 Testing against initial requirements .......................................................................... 53
4.3.1 Sufficiently addressed requirements ................................................................. 53
4.3.2 Partially addressed requirements ...................................................................... 54
4.3.3 Insufficiently addressed requirements .............................................................. 55
4.4 Scenario testing ......................................................................................................... 55
4.4.1 Scenario A: Retrieving MD field information in SAP .......................................... 59
4.4.1.1 Scenario profile ........................................................................................... 59
4.4.1.2 Scenario diagram ........................................................................................ 59
4.4.1.3 Scenario test results and evaluation........................................................... 61
4.4.2 Scenario B: Searching for MD metadata outside the SAP system ..................... 62
4.4.3 Scenario C: Creating semantically annotated MD pages ................................... 65
4.4.4 Scenario D: MD maintenance............................................................................. 68
5 Discussion and Conclusion .............................................................................. 71
5.1 Summary .................................................................................................................... 71
5.2 Evaluation of the research design and research process .......................................... 72
5.3 Contribution to the research community.................................................................. 74
5.4 Implications for further research .............................................................................. 74
vi
5.5 Managerial implications ............................................................................................ 75

6 References...................................................................................................... 77
6.1 Literature ................................................................................................................... 77
6.2 Internet ...................................................................................................................... 81
6.3 Corporate and institutional websites ........................................................................ 82
7 Appendices ..................................................................................................... 83
Appendix I: Summary of applied CommonKADS models ............................................... 83
Appendix II: List of interviews and correspondence ....................................................... 84
Appendix III: Interview guideline ..................................................................................... 85
Appendix IV: Interview reports ........................................................................................ 87
i. Deborah Harms (BCS, maintainer) ............................................................................... 87
ii. Holger Hinzen (BCS, business user) .............................................................................. 91
iii. Dirk Krüger (BCS, maintainer) ...................................................................................... 94
iv. Harald Sagner(BCS, business user) ............................................................................... 97
v. Bernd Wantke (BCS, maintainer) ............................................................................... 100
Appendix V: Documents of the PoC user evaluation .................................................... 103
i. Task Sheet (business user version) ............................................................................ 103
ii. Task Sheet (maintainer version)................................................................................. 107
iii. Online survey questions and results .......................................................................... 112
vii
List of Figures
Figure 1-1: Design Research framework .................................................................................... 3
Figure 1-2: Structure of the thesis ............................................................................................. 7
Figure 2-1: Examples of technical vs. business / structured vs. unstructured metadata ........ 10
Figure 2-2: Categorization of metadata ................................................................................... 11
Figure 2-3: Comparing traditional links with typed links and attributes ................................. 21
Figure 2-4: Example of information visualization .................................................................... 25
Figure 3-1: Notes client database version of the current MDM Handbook ............................ 31
Figure 3-2: Web-based version of the current MDM Handbook ............................................. 31
Figure 3-3: Navigation and search functionalities ................................................................... 32
Figure 3-4: Results table for navigation and search ................................................................. 32
Figure 3-5: Detailed information page for each MD field ........................................................ 33
Figure 3-6: Application architecture of the PoC ....................................................................... 42
Figure 3-7: User interface elements of the PoC ....................................................................... 43
Figure 3-8: Wiki page for an MD field ...................................................................................... 46
Figure 4-1: Evaluation approach in the context of the build-evaluate cycle ........................... 48
Figure 4-2: Section of the "Add field with form" function ....................................................... 50
Figure 4-3: “Validate” function to set timestamps .................................................................. 50
Figure 4-4: List of outdated pages on each user page ............................................................. 51
Figure 4-5: Partial support for different interface languages .................................................. 52
Figure 4-6: Main elements of EPC ............................................................................................ 57
Figure 4-7: Additional elements to specify EPC-functions ....................................................... 57
Figure 5-1: Design Research framework in the context of this thesis ..................................... 73
List of Tables
Table 1-1: Design Research guidelines realized within this thesis ............................................. 5
Table 2-1: Fields of application for metadata (examples) ......................................................... 8
Table 2-2: Source of an article on Apple Inc. presented in different forms ............................ 23
Table 3-1: General shortcomings of the MDM HB 2.0 ............................................................. 34
Table 3-2: Navigation deficits of the MDM HB 2.0 .................................................................. 35
Table 3-3: Search deficits of the MDM HB 2.0 ......................................................................... 35
Table 3-4: Suggestions for additional features and functionalities ......................................... 36
Table 3-5: Deduction of general requirements ........................................................................ 37
Table 3-6: Deduction of navigation and search requirements ................................................ 38
Table 3-7: Suggested requirements (no deduction necessary) ............................................... 38
Table 3-8: Matrix for the deduction of general specifications................................................. 39
Table 3-9: Matrix for the deduction of navigation and search specifications ......................... 40
Table 3-10: Matrix for the deduction of additional specifications .......................................... 41
Table 4-1: Number of participants for the user evaluation ..................................................... 49
Table 4-2: Structured approach to scenario testing ................................................................ 56
viii
Table 4-3: Scenario A profile (retrieving MD field information in SAP) ................................... 59

Table 4-4: Scenario B profile (searching for MD metadata outside the SAP system) ............. 62
Table 4-5: Scenario C profile (creating semantically annotated MD pages)............................ 65
Table 4-6: Scenario D profile (MD maintenance)..................................................................... 68
List of Diagrams
Diagram 4-1: Scenario A (retrieving MD field information in SAP) .......................................... 60
Diagram 4-2: Scenario B (searching for MD metadata outside the SAP system) .................... 63
Diagram 4-3: Scenario C (creating semantically annotated MD pages) .................................. 66
Diagram 4-4: Scenario D (MD maintenance) ........................................................................... 69
Abbreviations
ARIS Architecture of Integrated Information Systems
BCS Bayer CropScience
BE Business Engineering
CC Competence Center
CDQ Corporate Data Quality
DBMS Database Management System
EBIT Earnings before Interest and Taxes
EPC Event-driven Process Chain
FZI Research Center for Information Technology
GHS Globally Harmonized System of Classification and Labeling of Chemicals
HB Handbook
HQ Headquarter
HSG University of St.Gallen
HTML HyperText Markup Language
IS Information Systems
IWI Institute of Information Management
MD Master Data
MDM Master Data Management
OWL Web Ontology Language
PoC Proof of Concept
RDF Resource Description Framework
RDFS Resource Description Framework Schema
SD Sales and Distribution
SMW Semantic MediaWiki
SQL Structured Query Language
URI Uniform Resource Identifier
URL Uniform Resource Locator
W3C World Wide Web Consortium
WYSIWYG What-You-See-Is-What-You-Get
XML Extensible Markup Language
ARIS Architecture of Integrated Information Systems
Chapter 1: Introduction 1
1 Introduction
1.1 Initial problem statement
Through the last several decades, companies faced a rapidly increasing availability and com-
plexity of data (Tozer, 1999, p. XX). Data is generated and used in nearly every part of a
company, ranging from transactional data of daily business to analytical data for the support
of strategic decision making. Therefore, poor data quality may negatively influence corpo-
rate performance on an operational, tactical and strategic level and may lead to “customer
dissatisfaction, increased cost, ineffective decision making, and the reduced ability to make
and execute strategy” (Redman, 1998, p. 82). Consequently, a deep understanding of data
and the implementation of effective and efficient data management concepts are crucial for
the success of a company’s commercial activities (see Tozer, 1999, p. 4). However, there are
many factors that pose an additional challenge to the management of corporate data, e.g.:
• Isolated data islands. Most companies heavily rely on information systems to handle the
large amount of data used in their daily business. These systems, however, are often
dedicated to handle a single purpose, are maintained by a small group of users (Rosen-
thal, Renner, Seligman, & Manola, 2001), and cannot be easily adapted to the conti-
nuously changing business needs (Marco, 2000, p. 4). The results are islands of data
mostly unusable by other employees or information systems.
• Inter-corporate data integration. More and more, companies begin to integrate suppli-
ers, customers or partners into their business processes. In order realize efficient opera-
tions along their interfaces, the exchange of information between business users and in-
formation systems has to be seamlessly integrated (see, e.g., Accenture, 2006). In this
regard, not only the physical exchange of data has to be managed, but there is also a
need to establish a shared understanding about the meaning of the exchanged data
(Cheng Hian, Stéphane, Stuart, & Michael, 1999, pp. 271-272).
• Mergers and Acquisitions. From a data management perspective, mergers and acquisi-
tions are a great challenge, because data from information systems of both companies
has to be made accessible to all business users in an integrated and consistent way (Mar-
co, 2000, p. 17). Therefore, the challenges a newly expanded company faces are twofold:
In the short term, measures have to be applied that allow running daily operations along
the different disparate information systems and heterogeneous databases. In the long
term, the company has to establish a single point of truth that provides the same set of
data to all information systems and users.
This thesis is based on the assumption that challenges to data management as depicted
above can be addressed by the application of concepts and ideas from metadata manage-
ment (see, e.g., Cheng & Laurie, 1993; Marco, 2000; Tozer, 1999; Vaduva & Dittrich, 2001).
Semantic wiki technology as an innovative IS concept for corporate metadata management
is applied and evaluated in this research by working closely together with industry and aca-
demic partners.
1.2 Research objectives and target audience
Research objectives
Although concepts of metadata have been applied in practice since several decades (see Sen,
2004, pp. 151-153), there is in general a large gap regarding academic research about meta-
data and its management (Shankaranarayanan & Even, 2006, p. 88). The objective of this
research is therefore to contribute to the emerging body of knowledge in the context of me-
tadata management. To achieve this goal, the following core results will be developed:
• An analysis of the state-of-the-art in corporate metadata management provides an over-
view about important ideas, concepts and (technical) solutions that have been recently
developed and implemented. This thesis focuses particularly on the application of se-
mantic wiki technology as an emerging solution to corporate metadata management.
• An in-depth analysis and documentation of an existing metadata management solution
are developed through expert interviews. The results illustrate potential shortcomings of
current metadata management solutions and are needed to derive the requirements and
specifications for the building of the IT-artifact.
• A prototype of a semantic wiki severs as a proof-of-concept (PoC) to demonstrate the
effects of applying semantic wiki technology to corporate metadata management. Fur-
thermore, a detailed documentation of the prototype’s development process should
serve as a reference for the building and implementation of similar solutions by other re-
searchers or practitioners.
Questions regarding a successful roll-out of the prototype, including change management
and communication aspects, are beyond the scope of this thesis and will not be investigated.
Target audience
This thesis emerged out of research on data quality management conducted at the Institute
of Information Management of St.Gallen University, Switzerland (IWI-HSG). The aim of the
IWI-HSG is to develop methods and tools that help to improve the efficiency and effectivity
in the management of information systems. Solutions are developed in collaborative re-
search programs (see 1.3) with established industry partners in order to bridge the gap be-
tween development of theoretical foundations and their application in practice. Therefore,
this thesis equally addresses both researchers and practitioners who deal with the question
of how corporate metadata can be improved and managed through the application of new
and innovative concepts from information systems (IS) research.
The contribution to the academic community is to provide a formerly unexplored case of

application of semantic wiki technology to corporate metadata management. Knowledge
gained during the development of commercial solutions to metadata management is seldom
fed back to the academic body of knowledge. The expected outcome of this thesis is there-
fore of great benefit with regard to academic research, because insights won from the appli-
cation of theoretical foundations on real-life business problems are transformed back into a
scientific form and added to the existing knowledge base.
In practice, this thesis addresses all employees who are responsible for the maintenance of
high corporate data quality and/or who are involved in the development of IS-based solu-
tions for corporate metadata management. The well-documented design and structure of
the implemented corporate semantic wiki may serve as a template to design similar solu-
tions in their organizations. Furthermore, the tools and methods used during the design
process are not solely restricted to the development of metadata management systems, but
can be also applied for the construction of other information systems. Therefore, even prac-
titioners who are not directly interested in this research’s field of application can benefit
from this work and gain insights that can be adapted for their own purposes.
1.3 Research methodology
Research Framework
As the initial problem statement implies (see 1.1), this thesis cannot be conducted solely
from a technical point of view, but needs to analyze the interplay and dependencies be-
tween business strategy, IT strategy, organizational infrastructure, and IS infrastructure.
These interdependencies between organizational and technical perspectives are addressed
by Information Systems Research (see Lee, 1999, p. v). Since the objective of this research
(see 1.2) is to create and evaluate an IT artifact in order to solve a problem within an organi-
zational context, the Design Research paradigm is followed as a research framework (Hevner,
March, Park, & Ram, 2004, p. 77). Figure 1-1 illustrates the Design Research framework
(Hevner et al., 2004, pp. 78-81):
Environment Design Research Knowledge Base
People: Build Artifacts: Foundations:

• Roles • Constructs • Theories
• Capabilities • Models • Frameworks
• Characteristics • Methods • Instruments
• Instantiations • Constructs
• Models
• Methods
Organizations: Assess • Instantiations
• Strategies Business Applicable
• Structure & Culture Needs Knowledge
• Processes Refine
Methodologies:
Evaluation:
Technology: • Data Analysis Techniques
• Observational
• Infrastructure • Formalisms
• Analytical
• Applications • Measures
• Experimental
• Communictions Architecture • Validation Criteria
• Testing
• Development Capabilities • Descriptive
Relevance Rigor
Application in the Additions to the
Appropriate Environment Knowledge Base
Figure 1-1: Design Research framework

The environment delimits the boundaries of the research question and unit of analysis. It is
composed of organizations, as well as people working and technologies applied in them.
These three elements define the business needs which research needs to address in order to
legitimate its relevance for business practice (Hevner et al., 2004, p. 79).
The knowledge base, consisting of foundations and methodologies, provides the main build-
ing blocks Design Research builds upon. Foundations represent the existing body of know-
ledge from prior research and related disciplines. Methodologies ensure that research is
conducted with sufficient rigor to meet scientific standards. Examples of such methodologies
are data analysis techniques, formalisms, measures, and validation criteria (Hevner et al.,
2004, p. 80).
Finally, the aim of the Design Research approach is to build an IT artifact by applying founda-
tions of the knowledge base in order to meet the business needs that have been defined by
the environment. Design research is conducted in an iterative build-evaluate-cycle (see Si-
mon, 1996). During the building-phase, the IT-artifact is constructed drawing upon founda-
tions from the existing knowledge base. In the evaluation-phase, the IT-artifact is tested for
its quality, as well as its efficiency and effectiveness in solving the identified business prob-
lems. Methodologies from the existing knowledge base are applied during this phase to
achieve sufficient research rigor (Hevner et al., 2004, p. 80).
Collaborative Research Program

As already highlighted, the ultimate aim of Design Research is to create utility by contribut-
ing to the solution of a hitherto unsolved business problem (Hevner et al., 2004). Identifying
and analyzing the needs and problems of the business environment is therefore an impor-
tant part of Design Research, because it creates the very basis for the legitimation of re-
search.
This research has been conducted in the context of the Competence Center for Corporate
Data Quality (CC CDQ)1, which represents a collaborative research program (germ.: Konsor-
tialforschungsprogramm) initiated by the IWI-HSG. The CC CDQ is part of the research pro-
gram “Business Engineering HSG” of the IWI-HSG2.The main idea of this program is to enable
close collaboration between academics and business by organizing a consortium consisting
of application-oriented research institutions, business partners and other organizations. Re-
garding this research, the relevant actors within the consortium are:
• IWI-HSG: initiator and coordinator of the CC CDQ

• Bayer CropScience (BCS): business partner and program sponsor
1
See http://cdq.iwi.unisg.ch (accessed on July 23, 2008).
2
For up-to-date information on the research program “Business Engineering HSG” visit:
http://web.iwi.unisg.ch/org/iwi/IWI_Web_2.nsf/wwwPubInhalteEng/Research?opendocument (accessed on
July 23, 2008).
• Research Center for Information Technology in Karlsruhe (FZI): supplier of technical

know-how
Furthermore, collaborative research draws upon a pool of methods and tools to support the
research process in all of its phases. The set of methods and tools employed in a given pro-
gram are selected based on the needs and specific circumstances of the research setting. In
the context of this thesis, the following methods have mainly been applied:
• Requirements analysis has been employed to analyze the current business problem
at BCS that triggered the initiation of this thesis and to identify the relevant needs of
all concerned stakeholders. Semi-structured, individual expert interviews have been
the main source of information for the requirement analysis (see Cavana, Delahaye,
& Sekeran, 2001).
• CommonKADS is a methodology developed by several industry-university consortia
aiming at supporting knowledge management and knowledge engineering in small
and large organizations. Although the initial purpose of CommonKADS was to provide
practical tools for the development of knowledge-intensive systems, the same ideas,
concepts and techniques can also be employed in a much broader context (Schreiber,
2000, p. ix).
• Event-driven process chain (EPC) is used to formally describe and illustrate business
processes and has been developed by the Institute of Information Management (IWi)
of the University of Saarlandes in collaboration with the company SAP AG (see Keller,
Scheer, & Nüttgens, 1992). In this thesis, the EPC is applied to formally model differ-
ent testing scenarios used during the evaluation of the IT-artifact. The EPC-syntax and
semantics adopted in this thesis will be introduced at the end of chapter 4.4.
Applied research guidelines

To satisfy the rigorous requirements of Design Research – i.e. meeting both academic and
practical standards – seven guidelines proposed by Hevner et al. (2004, pp. 82-90) have been
taken into consideration throughout the whole research process as illustrated in.
Whether all guidelines have actually been sufficiently implemented and followed will be eva-
luated at the end this thesis (see 5.2).
Table 1-1: Design Research guidelines realized within this thesis3
Guideline Description Chapter

A core result of this research is the design of a prototype of a cor-
Design as
porate semantic wiki. A prototype is considered an instantiation
1 an Arti- 3
which represents a viable IT-artifact type in Design Research
fact
(Hevner et al., 2004, p. 77).
3
Following Hevner et al. (2004, pp. 82-90).
This thesis is part of a collaborative research program aiming at

Problem
the application of foundations in information systems research to 3.1.2 &
2 Relev-
address current business problems. The IT-artifact is expected to 3.2
ance
be used in a real-life context by one of the collaborating partners.
The prototype is evaluated for its utility, quality and efficacy
(Hevner et al., 2004, p. 85). This includes the application of rigor-
ous evaluation methods on a technical level, as well as testing the
Design
IT artifact against initially defined requirements and scenarios.
3 Evalua- 4
Since Design Research has a highly iterative nature, the evalua-
tion
tion of the prototype is only the beginning of several refine-
/reevaluation-cycles within the context of the collaborative re-
search program.
The contribution of this research is represented by the actual IT-
Research artifact, its evaluation and documentation. Moreover, the imple-
3&4
4 Contri- mentation of the IT artifact in the actual business environment
bution creates valuable insights for the research community (Hevner et
al., 2004, p. 87)
Established methods have been applied for both the construction
Research (e.g., expert interviews, CommonKADS) and evaluation (e.g., sce- 3.1.3 &
5
Rigor nario testing) of the IT-artifact in order to guarantee sufficient 4.1
research rigor.
As stated above, this research is embedded in a larger context of
Design as
a collaborative research program. The results and insights gained
6 a Search 3.1.2
from this thesis will be further used and refined in subsequent
Process
iteration cycles within this research program setting.
Commu- The knowledge gained from the conduction of Design Research
nication needs to be presented in the right form to both the research 5.3, 5.4
7
of Re- community as well as practitioners (Hevner et al., 2004, p. 90). & 5.5
search This thesis addresses the needs of both groups.
1.4 Outline of the thesis

This thesis is structured as follows:
Chapter 1 introduces the topic of the thesis to the reader by delineating the underlying busi-
ness problem and the purpose of the study. It explains the Design Research paradigm which
has been chosen as the research framework, and depicts the methodology and outline of the
thesis.
Chapter 2 provides the necessary foundations this research is based on. First, basics about
metadata, its application and management in organizations are depicted. Second, the con-
cept of wikis is highlighted from both a general and corporate perspective. Finally, semantic
wikis are introduced as an innovative solution to corporate metadata management.
Chapter 3 deals with the design of the IT-artifact, i.e. the corporate semantic wiki. After a
short introduction about the project partner and project background, an as-is-analysis of the
current solution implemented at BCS is conducted, based on results from expert interviews.
Thereafter, requirements and specifications for the development of the SMW are defined.
This chapter concludes with the description of the structure and functionalities of the IT-
Artifact.
Chapter 4 evaluates the IT-artifact by its contribution to the solution of the underlying busi-
ness problem, i.e. by the “utility, quality and efficacy” of the IT-artifact (Hevner et al., 2004, p.
85). Different testing methods are employed to ensure reliability and accuracy of the evalua-
tion process. Data for the testing is gathered from the same user group that had already
been chosen for the expert interviews.
Chapter 5 concludes the thesis. It provides a brief summary, reflects upon the research
process, and discusses the implications of the results from an academic as well as from a
business point of view.
Chapter 1 Introduction
Chapter 2 Basics
Corporate Metadata Semantic Wikis in the
Corporate Wikis
Management Corporate Context
Main Part
Chapter 3 Chapter 4
Building the IT-Artifact Evalutating the IT-Artifact

Company and Project
Evaluation Methods
Background
As-Is-Analysis of the current Requirements and

Solution Specifications Testings
Definition of requirements and

Scenario Testing
specifications
Description of the IT-artifact Results Interpretation
Chapter 5
Discussion and Conclusion
Figure 1-2: Structure of the thesis

Chapter 2: Definition and description of key concepts 8
2 Definition and description of key concepts

2.1 Corporate metadata management
2.1.1 Metadata in the corporate context
Definition
Generally speaking, metadata can be defined as data about data (see, e.g., Marco, 2000, p.
4). More precisely, metadata enables, facilitates and/or enhances the use of data objects by
providing additional information about the characteristics of the data. Examples of such in-
formation would be the name and location of a book needed for searching and retrieving it;
descriptions of organizational structures, rules, and business processes that help improving
the employees’ workflow; or information about the format of an electronic document enabl-
ing interoperability and exchange between different systems. As these rather heterogeneous
examples imply, the types and purposes of metadata depend highly on the context in which
they are applied.
Table 2-1 illustrates this context dependence:
Table 2-1: Fields of application for metadata (examples)
Context Types (examples) Purposes (examples)

• Content (title, subject, language, etc.) To find, identify, select, and obtain “information-
Bibliographic
bearing entities” (e.g., books and printed mate-

Control4
• Intellectual Property (creator, publisher,

rials)
rights, etc.)
• Instantiation (date, format, identifier, etc.)
• Identification information (title, geographic • Context specific presentation and querying

graphic Information
Cartography & Geo-
area, data set, etc.)

• Supporting the preparation of scientific re-
• Data quality information (accuracy, com- ports
Science5
pleteness, consistency, sources, etc.)

• Exchanging geospatial data between different
• Spatial data organization information (me- organizations and systems
chanisms used to represent spatial informa-
• Cataloguing in directory systems
tion in a data set)
4
See Burnett, Ng, & Park (1999); Milstead & Feldman (1999).
5
See ANZLIC (2001); Miller & Shaw (2001).
• Representation of media types (format, • Storing, organizing and retrieving distributed

coding, compression, etc.) multimedia resources
Multimedia Resource
• Content description (title, subject, etc.) • Managing algorithms for information

Management6
processing
• Content classification (subject, etc.)
• Adding semantic annotations
• Document composition (logical components
of multimedia documents) • Accessing, protecting and/or sharing informa-
tion.
• Document history (creation, approval, re-
view, etc.)
• Customer metadata (name, address, etc.) • Business forecasting

Management Deci-
sion Support7
• Product metadata (category, id, etc.) • Business performance measurement

• Operations metadata (production capacity, • Real-time analysis
lead time, rate of failures, etc.)
• Answering ad-hoc queries
• Sales metadata (growth in sales, regional
• Business activity monitoring
sales distribution, age distribution, etc.)
Because of the various possible fields of application, there exists a plethora of definitions
concerning metadata (Burnett et al., 1999, p. 1212). In this research, we are interested in the
application of metadata management from a corporate perspective. Therefore, we follow
Marco’s (2000) business-oriented and comprehensive definition of metadata, which is:
“Meta data is all physical data […] and knowledge […] from inside and outside an or-
ganization, including information about the physical data, technical and business
processes, rules and constraints of the data, and structures of the data used by a cor-
poration” (p. 5).
Aspects of corporate metadata

As previously stated, the understanding and definition of the term “metadata” depends
highly on the context it is applied in. Even if we narrow our perspective to metadata gener-
ated and used in organizations, there exist various ways to classify and describe it. In the
following, we will depict several aspects of corporate metadata which are of high impor-
tance in the light of this thesis8:
• Technical vs. business metadata (following Marco, 2000, pp. 49-54). One possible classi-
fication of corporate metadata and its users is to follow the classical distinction between
the technical and business perspective of an organization.
6
See Asirelli, Little, Martinelli, & Salvetti (2006); Vipul, Kshitij, & Amit (1996).
7
See Negash & Gray (2008); Tozer (1999).
8
Several cited references are discussing metadata in the narrow context of data warehousing. Aspects taken
from such sources have been adapted to a more general focus on corporate metadata (including, e.g., master
data, operational systems and other non-technical aspects) and indicated by the prefix “following” at the be-
ginning of the citation.
Technical metadata includes information about operational and analytical systems

and helps technical users to manage their IT infrastructure and system operations.
Business metadata, on the other hand, supports business users on an operational,
tactical and strategic level by presenting information about data objects in terms un-
derstandable to non-technicians.
• Structured vs. unstructured metadata (Inmon, O'Neil, & Fryman, 2007, pp. 219-234).
Another qualitative differentiation of corporate metadata is the distinction between
structured and unstructured metadata:
Structured Metadata is all metadata generated by using models and rules that have
been company-wide developed and agreed upon. Documentation about those rules
and models can be regarded as “metadata about metadata” because it describes a
shared common format for a group of structured metadata. Most structured metada-
ta is administered by information systems and stored in so-called metadata reposito-
ries accessible to all authorized users and systems of an organization.
Unstructured Metadata represents all metadata that has been created without the
application of any models or rules as described above. Unstructured metadata is
mainly created by employees and often only accessible to a small group of users. It
can be in an electronic form (e.g., emails, Word documents, Excel sheets, etc.), but
also exists often in a non-electronic form (e.g., notes, knowledge in the employees’
brains, etc.). However, unstructured metadata may carry great business value and
should be therefore considered to be captured, formalized and made accessible to
the whole organization (see Marco, 2000, p. 60).
Figure 2-1 summarizes the classification of technical/business and structured/unstructured

metadata by giving one illustrative examples for each combination:
technical business
structured
Logical data model of an

Database that provides business
operational database system
definitions for all table names in
designed with an appropriate
a uniform way.
modeling tool.
unstructured
E-Mail from technical support

Outline on a sketchpad
to an individual business user
indicating how some parts of a
explaining what a specific table
relational database are logically
name (e.g., „CUST“) means in
connected to each other.
business terms.
Figure 2-1: Examples of technical vs. business / structured vs. unstructured metadata
• Types of metadata (following Shankaranarayanan & Even, 2004, pp. 251-257, 2006, p.
90). There are several ways to categorize metadata into different types. We follow the
categorization along the functionality of metadata leading to six different types of meta-
data:
(1) Infrastructure metadata: Describes and supports the maintenance of IT systems and
other infrastructure of the organization (e.g., list of network addresses for different
IT-systems).
(2) Model metadata: Provides a data dictionary about characteristics of different con-
ceptual, logical and physical data elements (e.g., model of the corporate structure
indicating hierarchies, functional units, their relationships, etc.).
(3) Process metadata: Documents the generation, modification and transformation of
data within different systems (e.g., business rules to handle specific fields within an
SAP system).
(4) Quality metadata: Supports the evaluation data quality along different dimensions
such as accuracy, completeness, timeliness, and consistency (e.g., date of the last up-
date of a specific data element).
(5) Reporting metadata: Information about how data has to be delivered and presented
to different users (e.g., template for sales reporting including format, content ele-
ments, timing, target audience, etc.).
(6) Administration metadata: Manages security and access privileges of data elements
(e.g., rules about the length, validity, character types, and change procedure for
passwords).
Types of Metadata
Infrastructure Model Process Quality Reporting Administration

Metadata Metadata Metadata Metadata Metadata Metadata
List of network Model of the Business rules to Date of the last Template for sales Rules about the
addresses for corporate structure handle specific update of a specific reporting including length, validity,
Example
different IT-systems indicating fields within an SAP data element format, content character types,
hierarchies, system elements, timing, and change
functional units, target audience, procedure for
their relationships, etc. passwords
etc.
Figure 2-2: Categorization of metadata

• Functions of Metadata. An important way to categorize corporate metadata is to diffe-

rentiate it by its purpose or function for the organization. However, since there is again a
plethora of purposes metadata can be used for, only those relevant for this research will
be listed:
Supporting business processes by delivering additional information (Marco, 2000, pp.
49-54).
Information location, identification, retrieval, presentation and manipulation (see
Burnett et al., 1999, p. 1210).
Supporting the development, maintenance and expansion IT-systems (see Marco,
2000, pp. 15-16).
Enabling and facilitating interoperability and exchange of data between different sys-
tems (see Burnett et al., 1999, p. 1213).
Evaluation and improvement of data quality (see Shankaranarayanan & Even, 2004, p.
260).
2.1.2 Management of corporate metadata
Discussion and definition

In order to define corporate metadata management, we first have to delineate what ele-
ments the term “management” consists of and how they are applied in the context of corpo-
rate metadata. According to Fayol (1949), there are basically five classical management func-
tions, i.e.: planning, organizing, leading9, coordinating, and controlling. In the following, the
discussion of corporate metadata management will be structured along those functions:
Planning implies anticipating the long-term needs of an organization regarding corporate

metadata, setting the respective goals, and devising a strategy and framework how to
achieve these goals in an efficient and effective way. This implies that the organization and
usage of metadata has to be continuously adapted to market and technological changes.
Shortsighted or insufficient planning of corporate metadata can have disastrous impacts in
the long-term, such as increased costs or the inability to adapt the information systems to
the changing business needs (see Marco, 2000, pp. 17, 19).
Organizing represents the actual implementation of the strategy and framework developed
during the planning phase. From a business perspective, this means to define roles and re-
sponsibilities for different organizational aspects of metadata, and appointing the right
people with appropriate skills and experience to those roles (see Marco, 2000, pp. 121-141).
From a technical perspective, organizing involves designing the architecture of the metadata
repository, metadata modeling, the evaluation and selection of appropriate technologies etc.
(see Marco, 2000, pp. 115-121).
Leading and coordinating basically involves putting the planning and organizing into action
by giving orders, delegating tasks, guiding and supporting the different employees in the
9
The term originally used in the English translation (Fayol, 1949) was “commanding”.
organization and making them work together in a logical and structured way. These two
management functions are rather generic and are implemented similarly also in other orga-
nizational contexts.
Finally, controlling assures that long-term and short-term goals can be reached by setting
appropriate objectives, defining metrics that can accurately measure those objectives, and
setting target values that have to be reached for those metrics. If the actual values deviate
from the target values, initiatives have to be taken to investigate the root cause of the devia-
tions and appropriate solutions need to be developed (see, e.g., Kaplan & Norton, 1992, pp.
71-79). Controlling corporate metadata addresses basically two major issues: one is to as-
sure the quality of corporate metadata – e.g. accuracy, timeliness, consistency, transparency,
and availability (Tozer, 1999, pp. 5-7); the other is to guarantee that corporate metadata
sufficiently supports business and decision making processes (Tozer, 1999, pp. 103-104, 123-
131).
Based on the discussion above, we can now define corporate metadata management as:
Planning, organizing, leading, coordinating and controlling corporate metadata from

a business as well as technical perspective with the ultimate goal to efficiently and ef-
fectively support business processes and decision making processes on all hierarchical
levels of an organization.
Information systems for integrated metadata management

Nowadays, most companies rely heavily on commercial or self-developed solutions to han-
dle the vast amount of information generated and used by the organization. However, using
information systems to systematically manage corporate metadata is not a recent trend, but
has already been realized by so-called data dictionaries in the early 1970s (Marco, 2000, p.
6). Since then, the evolution of technological concepts and commercial solutions has dramat-
ically advanced, and almost every aspect of corporate metadata can today be managed by
information systems.
Besides general requirements posed to enterprise IS, there are several specific needs infor-
mation systems have to meet in the context of metadata management (Hüner, Otto, &
Österle, 2008, p. 36):
• Import and export functions for metadata

• Multi-language support
• Search and navigation functionalities
• Document versioning and history maintenance
• Application of metadata in operational systems
• Mechanisms to avoid metadata inconsistency
With current IS solutions and sufficient implementation efforts, it is already possible to meet
the above listed requirements. However, the increasing financial and performance pressure
on IT departments fosters the demand for IS that delivers high functionality and usability at
low costs (Tozer, 1999, pp. 3-4). In this research, we investigate the application of semantic
wiki technology as a potential answer to these needs. The following chapters 2.2 and 2.3 will
therefore introduce the wiki concept and explain how semantic wiki technology can be suc-
cessfully applied to corporate metadata management.
2.2 Wikis in the corporate context
2.2.1 The concept of wikis

A wiki can be regarded as an information and knowledge repository where users are encour-
aged to populate new contents and make changes to existing ones (Hasan, Meloche, Pfaff, &
Willis, 2007, p. 35). The first wiki was developed by Ward Cunningham in 1994 intended as a
web collaboration tool that allowed for easy and quick editing by its users (Cunningham &
Leuf, 2001, pp. 14-23). This idea of allowing users to quickly create new content and apply
changes is also reflected in the term “wiki”, which originates from the Hawaiian term “wiki-
wiki” meaning “fast” or “quick”10. From a technical point of view, a wiki is a set of interlinked
web pages each describing a specific information object and accessible from any web
browser (Hasan et al., 2007, p. 35).
One of the most popular wikis nowadays is Wikipedia11, a free online encyclopedia where
knowledge is collected and shared in a collaborative process among its users. In April 2008,
Wikipedia counted over 10 million articles in 253 languages12. The software Wikipedia is
based on MediaWiki13, an open source software that can be freely downloaded and adapted.
More than 3,000 public wikis are based on MediaWiki14 and many more are implemented
privately and in corporations. Besides MediaWiki software, there are hundreds of so called
“wiki clones” – such as MoinMoin, PhpWiki, OddMuseWiki, UseModWiki etc.15.
The predestination of wikis to serve as a platform for knowledge creation and sharing, has
led to the fact that research about wikis is often conducted in the context of knowledge
management (see, e.g., Hester, 2008; Raman, Ryan, & Olfman, 2005; Schaffert, 2006; Wagn-
er, 2004). This thesis does not explicitly address research in knowledge management, but
focuses only on metadata management. In fact, there is no common understanding how
those two fields of research are related to each other, given that even the terms “data”, “in-
formation” and “knowledge” are used in many different ways and often interchangeably
(Stenmark, 2002).
10
See http://en.wiktionary.org/wiki/wiki (accessed on 25. July 2008).
11
See http://www.wikipedia.org/ (accessed on 25. July 2008).
12
See http://en.wikipedia.org/wiki/Wikipedia (accessed on 25. July 2008).
13
See http://www.mediawiki.org/wiki/MediaWiki (accessed on 25. July 2008).
14
See, e.g., http://www.wikindex.com/ (accessed on 28. July 2008).
15
See, e.g., http://c2.com/cgi/wiki?TopTenWikiEngines (accessed on 28. July 2008).
The wiki concept is characterized by a set of distinctive elements realized in most public and
private wikis (see also Cunningham & Leuf, 2001; Ebersbach & Glaser, 2005; Hester, 2008):
• Quick and easy content creation and editing. A major feature of wikis is to offer intuitive
and simple functionalities to create and edit pages. In most cases, wiki pages can be
created by a simple button click or by entering the respective URL into the browser. En-
tering content is achieved by wiki specific markup languages which are much simpler and
more intuitive than traditional HTML code16. Wikis do not impose strict content structure
on the writer as compared to other content management systems. As a consequence,
the high usability encourages even non-technical users to participate in the collaborative
process of content contribution.
• Internal linking. Being able to create links between different pages is another major cha-
racteristic of a wiki. As a result, all pages within a wiki are interconnected. This creates
the serendipitous effect that users can “travel” from one page to another without a spe-
cific aim, following topics they spontaneously get interested in. To foster this effect, the
wiki concept discourages the creation of pages that have no inbound links - so called
“orphan pages” – because they can only be found through direct search or if the name of
the pages is known. To support the simplicity of content creation, creating a link to
another wiki page is easily done by putting the respective term into double square
brackets (e.g. “Bern is the capital of [[Switzerland]]”)17 instead of having to create a
hyperlink as in HTML.
• History management. Although history management is implemented in most content
management systems, it particularly plays an essential role in the quality maintenance
and administration of wiki pages. Due to the openness of the wiki concept, basically any-
one can manipulate the content of a page. Thus, a mechanism is needed to prevent in-
tentional and unintentional manipulation and deletion of content which would lead to a
deterioration of the informational quality of a wiki. History management allows tracking
changes and comparing different versions of a page. A simple “rollback” function can re-
turn a page to a previously saved state with a few simple clicks. This discourages vandal-
ism and malicious manipulation without curtailing anybody’s right to contribute to the
wiki.
• Discussion. Wikis usually offer to all users the possibility to discuss content-specific and
administrative issues with other participants which fosters the collaborative and demo-
cratic nature of the wiki concept. This function is especially important regarding contro-
versial topics for which divergent opinions have to be brought to a consensus.
16
Some wiki engines even support a WYSIWYG-editor (What-You-See-Is-What-You-Get), i.e. the user sees al-
ready during the editing process how the content will finally appear on the site.
17
Referring to the wiki syntax of the MediaWiki Software also used by Wikipedia. Some other wikis may use
different syntax to create internal links to other wiki pages.
2.2.2 Fields of application for corporate wikis

The wiki concept has become widely accepted in a corporate context and many companies
are engaging in the use of wikis in various ways (see Majchrzak, Wagner, & Yates, 2006, p.
99). Gartner predicts that until 2011, wikis will be commonly used in more than half of all
enterprises worldwide (Tan, 2007). The simplicity of wikis differentiates them from other
traditional solutions (Stephens, 2007, p. 36), and since they do not stipulate a predefined
content structure, wikis can be used very flexibly for various purposes within a company
(Klobas & Beesley, 2006, p. 100). In the following, several potential fields of application for
corporate wikis are discussed:
• Project management and collaboration. The design of wikis fosters the collection and
sharing of information in a simple but organized way, which makes them suitable to be
used as a project management and collaboration tool. Users can concentrate on their
projects and have to deal less with software, business rules or authorization issues. Since
teamwork happens more and more in a decentralized way, wikis can serve as a platform
where all types of information – e.g., meeting minutes, notes, project documents, dis-
cussions etc. – can be centrally stored and accessed by any web browser from any place
over the world. Although information stored in a wiki’s content repository may be much
less structured and organized than it would be in other IS solutions, strong linkages, ca-
tegorization and tags, as well as basic search and navigation functions allow that infor-
mation can still be easily found and retrieved (Lerouge, 2007). An illustrative example
where a wiki is implemented as a project management and collaboration tool is the case
of Stata Labs18, a software development company. The company is using the wiki to sup-
port its different software development projects leading to shorter development cycles
and productivity gains (Socialtext, no date-b).
• Email reduction. A rather simple but important field of application for wikis is to help
reducing the amount of emails employees use to communicate and inform each other. In
fact, a recent online survey revealed that 36% out of 269 polled companies that have im-
plemented a wiki are aiming at reducing the use of emails within their organization (Bar-
tel, 2006). There are several advantages wikis have over traditional email, especially in
the case of one-to-many communication (Muse, 2007): First, topics that are discussed in
a wiki are stored and edited centrally which helps maintaining a single source of truth,
whereas discussions by email may easily lead to multiple and conflicting versions. Second,
wikis can be easily and quickly edited to correct mistakes or add missing attachments.
Once sent emails, on the other hand, cannot be changed anymore, but have to be cor-
rected by a subsequent email causing for both the sender and recipient unnecessary con-
fusion and effort. Finally, introducing new users to a topic can be easily achieved by indi-
cating the URL to the respective wiki site, instead of having to collect and forward the
whole history of all relevant emails that contain the necessary information. For instance,
18
See www.statalabs.com (accessed on 30. August 2008).
1UP.com19 - Ziff Davis Media’s20 gaming division – reduced their volume of email com-
munication from 100 mails per day to less than one per week after the implementation
of a corporate wiki (Klobas & Beesley, 2006, pp. 102-103).
• Platform for informal communication. Given that business operations are getting more
and more global and decentralized, traditional public spaces within a company (e.g., ca-
feterias, toilets, copy rooms, etc.) become less utilized as a platform for informal infor-
mation exchange (see Allen, 2007). Wikis may serve as an alternative to such physical
spaces because they support informal communication (Klobas & Beesley, 2006, p. 100).
The same survey mentioned above also shows that about 74% of all polled companies
used wikis for informal information exchange (Bartel, 2006). Moreover, using a wiki as an
informal communication tool may help to overcome initial inertia when introducing it to
a new group of users. For example, one team at the investment bank Dresdner Kleinwort
Wasserstein21 used their wiki in the beginning to organize their coffee rota before it be-
came a productive project and collaboration tool in the later course of business (Klobas
& Beesley, 2006, pp. 104-106).
• Knowledge management. The same characteristics of wikis that make them suitable for
project management and collaboration also apply to knowledge management. As know-
ledge is becoming the most important asset for sustained competitive advantage, col-
lecting and making it available to the company’s employees is crucial for business success
(Grant, 1996). A main challenge for the management of corporate knowledge is there-
fore the process of externalization – i.e., transforming tacit knowledge that exists in the
heads of employees into an articulated form such as text, diagrams or concepts, so that
it can be stored and accessed by others (see Kogut & Zander, 1992). Wikis support this
externalization process through low barriers to participation due to their intuitiveness,
simplicity and availability to all employees (Müller & Dibbern, 2006). In the case of In-
formative Inc.22, the barrier to participation was lowered so drastically that the time
needed to post new information decreased from approximately 30 days to a few minutes
(Socialtext, no date-a).
• Metadata Management. As already stated before, wikis can also be implemented as a
metadata management system for corporations. A very simple application would be a
glossary about company-specific information, which employees can look up if they have
work-related questions. Search and navigation functions, as well as strong interlinkage
between pages allow finding information quickly and easily even if the content of the wi-
ki is not structured so well as traditional metadata management systems. However, the
lack of a formal content structure of a wiki that has been mentioned above as an advan-
tage prevents it to be useful for the management of complex metadata, such as model
and process metadata (see 2.1.1). This is because information which is distributed across
19
http://www.1up.com/ (accessed on 30. August 2008).
20
http://www.ziffdavis.com/ (accessed on 30. August 2008).
21
www.dresdnerkleinwort.com (accessed on 30. August 2008).
22
Acquired by Satmetrix (www.satmetrix.com) in September 2007.
multiple sites cannot automatically be gathered and processed (see Krötzsch, Vrandecic,
& Völkel, 2005, p. 2; Völkel, Krötzsch, Vrandecic, Haller, & Studer, 2006, p. 585).
The following chapter investigates how enhancing traditional wikis through ideas from the
Semantic Web may decrease the negative impact from the unstructured nature of wiki con-
tent.
2.3 Semantic wikis in the corporate context
2.3.1 The concept of the Semantic Web

The concept of the Semantic Web was introduced by Tim Berners-Lee at the first World
Wide Web Conference in 1994 (Shadbolt, Berners-Lee, & Hall, 2006, p. 96) and published in
2001 in the Scientific American journal (see Berners-Lee, Hendler, & Lassila, 2001). His idea
emerged out of the realization that information available in the Web is mainly produced for
human consumption and most of it cannot be interpreted and automatically processed by
machines (Berners-Lee et al., 2001, p. 36). His vision is that the Semantic Web serves as “an
extension of the current [Web], in which information is given well-defined meaning, better
enabling computers and people to work in cooperation” (Berners-Lee et al., 2001, p. 35).
Humans are able to grasp the meaning and resolve the ambiguity of words and phrases con-
tained on a website by interpreting them within the overall context of the page. They are
able to associate different meanings to the word “hot” depending whether they are reading
an online weather report, a car review or an article about a famous actress. However, at the
current state of the Web, machines can hardly achieve the same results. Today’s search en-
gines may have very powerful search algorithms, but they are restricted to full-text queries
for single words or strings of texts, instead of offering semantic search functionalities (Hitzler,
Krötzsch, Rudolph, & Sure, 2007, p. 10). For instance, a search engine cannot distinguish be-
tween the different meanings of the word “apple” and will display a large variety of search
results for that specific term including information about apples as a type of fruit, companies,
people, places named “Apple” and much more.
The main problem is that machines cannot process most of the information on the Web,
because its content is highly unstructured and does not provide inference rules about how
to conduct automated reasoning (Berners-Lee et al., 2001, p. 36). Although some sources
may offer collections of information in a structured form, the underlying principles used to
structure information are often too heterogeneous to allow interoperability among the dif-
ferent sources (see Hitzler et al., 2007, p. 10). To overcome these shortcomings, the current
Web has to be extended in a way that enables machines to make better use of information.
The major technologies of the Semantic Web that help achieving this goal are XML, RDF and
OWL – three standards specified by the World Wide Web Consortium (W3C)23. These stan-
dards play also an important role to realize semantic wikis:
• eXtensible Markup Language (XML).24 XML is a formal recommendation of the W3C

used to share various types of data among different information systems. XML allows
annotating data with so-called “tags”, which are a type of metadata describing the anno-
tated data (Hitzler et al., 2007, pp. 17-18). These tags can be used to help machines
processing and sharing data in more sophisticated ways. For instance, if different online
vendors of similar products would annotate all of their products in the same way – in-
cluding name, price, availability, quantity etc. – a program could extract all this informa-
tion and display it on a single page for easy comparison. However, since these tags are
not self explaining, the writer of the program has to know exactly what each tag means
and what it is used for.
• Resource Description Framework (RDF).25 RDF is a framework to describe and represent
electronic information. It allows applications exchanging and processing data by provid-
ing additional “meaning”. The meaning is expressed in RDF through a graph of nodes and
arcs. RDF makes statements about resources in form of triples consisting of a subject,
predicate and object which can be expressed in XML. On top of RDS, RDF Schema (RDFS)
can be used to enable an even more structured description of knowledge by introducing
classes and properties. (Krötzsch et al., 2005, p. 3). Since RDF(S) represent also main
elements implemented in semantic wikis, a more detailed description and examples will
follow in chapter 2.3.2.
• Web Ontology Language (OWL).26 Similar to RDF, OWL is intended at making informa-
tion contained in electronic documents interpretable and processable by machines.
However, whereas RDF is used to make rather simple statements about electronic re-
sources, OWL can express much more complex meanings and semantics. It is therefore
used when machines need to perform sophisticated reasoning and inference tasks. OWL
even enables to make logical inferences about information not explicitly expressed but
implicitly contained in a document (Hitzler et al., 2007, p. 125).
2.3.2 The concept of semantic wikis
Overview
Semantic wikis are an enhanced version of traditional wikis extended by elements of seman-
tic web technology. The major characteristics of wikis are strong interlinkages between piec-
es of information and simplicity. However, due to the lack of strict structural requirements
wiki content is mostly only interpretable by humans, whereas machines can hardly process it.
23
Only a brief description on a conceptual level will be provided for these standards. For more detailed and
rather technical information, please refer to the official specifications of the W3C: XML (www.w3.org/XML/);
RDF(S) (www.w3.org/RDF/); OWL (www.w3.org/TR/owl-features/) (accessed on 2. September 2008).
24
Following Berners-Lee et al. (2001) if not stated otherwise.
25
Following W3C (10. February, 2004b) if not stated otherwise.
26
Following W3C (10. February, 2004a) if not stated otherwise.
By extending traditional wikis with semantic web technologies, information becomes more
useful to machines while maintaining the major benefits of traditional wikis. This opens up a
variety of new and powerful functionalities hardly achievable by traditional wikis.
There are several projects aiming at enhancing the traditional wiki concept by borrowing
elements from the Semantic Web. All of them use similar approaches to add semantic fea-
tures to collaborative editing of knowledge bases (Völkel et al., 2006, p. 593). Some exam-
ples are:
• Semantic MediaWiki (SMW) (Völkel et al., 2006) is an extension to the MediaWiki soft-
ware. The project aims at enabling the semantic annotation of Wikipedia’s existing con-
tent base. The development has already advanced to a mature stage and current
achievements can be tried at “semanticweb.org”. The corporate semantic wiki devel-
oped in this research also builds upon the SMW extension.
• Platypus Wiki (Bao & Honavar, 2004) is one of the first semantic wikis implemented as a
stand-alone java web application. The main goal of this project is to create a platform for
collaborative editing of vocabularies and ontologies based on RDF and OWL, although
other fields of applications, such as the usage as a personal knowledge management sys-
tem, are also taken into consideration.
• IkeWiki (Schaffert, 2006) is a prototype developed at Salzburg Research27 which uses the
same syntax applied in Wikipedia. This allows a direct import of content from Wikipedia
so that only semantic annotations have to be added. As Semantic MediaWiki and Platy-
pus Wiki, it also uses RDF and OWL as a knowledge representation format. Although the
wiki has been primarily developed as a tool for ontology engineering, other application
scenarios such as knowledge management or applications in an educational context are
proposed too.
• Other approaches such as SHAWN Wiki (Aumueller, 2005), SemperWiki (Oren, 2005),
WikSAR (Aumueller & Auer, 2005), MaknaWiki (Nixon & Simperl, 2006) etc.
In the following, some essential elements of semantic wikis are discussed. Despite the simi-
larities of the above listed examples, every approach exhibits some unique features which
distinguish it from other approaches. Since the IT-artifact built in the context of this research
is based on the SMW extension, the delineation of semantic wikis in the next section will be
based on the approach proposed by Krötzsch et al. (2005) and Völkel et al. (2006).
27
http://www.salzburgresearch.at/ (accessed on 2. September 2008).
Essential elements of semantic wikis28

Reading Wikipedia’s article about the Apple Company “Apple Inc. is a multinational corpora-
tion headquartered in the United States. It focuses on designing and manufacturing consum-
er electronics and software products and was established in 1976”29, we automatically make
inferences about the relationships between the different pieces of information contained in
this article. However, if we would only be given the two terms “Apple” and “1976” and had
to make inferences about how they are related to each other, we would encounter two chal-
lenges: First, the two terms by themselves are ambiguous. Without context we don’t know
whether the meaning of “Apple” is a fruit, the name of a person or company nor do we know
if “1976” indicates a year, a ZIP code or something else. Second, even if the meanings of
both terms are given, we still cannot know how the two terms are related. The Apple Com-
pany could have been founded, sold, sued, or gone bankrupt in 1976. In other words, these
two terms without any further context cannot be usefully processed by humans. In a similar
way, information in current wikis cannot by usefully processed by machines because the
semantic context in the form of additional metadata is missing. The semantic wiki extension
introduces two new elements that allow the creation of such semantic context: typed links
and attributes.
In order to avoid confusion, it is important to note that since the release of Version 1.0 of
the semantic wiki extension, those two elements are summarized under the term “Proper-
ties”30 for the sake of simplicity. However, for the rest of chapter 2, we remain with the dif-
ferentiation between those two elements in order to explain the concepts of semantic wikis
more comprehensively. From the beginning of chapter 3, only the term “Properties” will be
used to describe and discuss the IT-artifact.
Traditional Links Typed Links and Attributes

Multinational corporation (or Multinational corporation (or
The United States of America, usually The United States of America, usually
referred to as the United States, the USA,
transnational corporation) (MNC/TNC) is United States
referred to as the United States, the USA,
Multinational
transnational corporation) (MNC/TNC) is
a corporation or enterprise that manages a corporation or enterprise that manages
the U.S. or America, is a constitutional
production establishments or delivers
oforAmerica
the U.S. America, is a constitutional Corporation
production establishments or delivers
federal republic comprising fifty states federal republic comprising fifty states
services in at least two countries. Very services in at least two countries. Very
and a federal district. The country … and a federal district. The country …
large multinationals … large multinationals …
Is a
headquartered in
Apple Inc. is a multinational corporation Year 1976 (MCMLXXVI)

was a leap year starting dominatesApple Inc. is an American multinational
headquartered in the United States with a
on Thursday (link will market corporation with a focus on designing and 1976
manufacturingApple Inc.
focus on designing and manufacturing founded in
display full calendar) of consumer electronics and
consumer electronics and software the Gregorian software products established in 1976”
products established in 1976” calendar…
produces
produces
Computer software, or just software is a Computer software, or just software is a
Consumer electronics include electronic Consumer electronics include electronic
general term used to describe a collection general term used to describe a collection
equipment intended for everyday use. equipment intended for everyday use.
of computer programs, procedures and of computer programs, procedures and
Consumer electronics are most often Computer Consumer electronicsConsumer
are most often
documentation that perform some tasks documentation that perform some tasks
used in entertainment, communications used in entertainment, communications
on a computer system. The term includes on a computer system. The term includes
Software Eletronics
and office productivity. Some products … and office productivity. Some products …
… …
Figure 2-3: Comparing traditional links with typed links and attributes
28
Following Krötzsch et al. (2005); Völkel et al. (2006) if not stated otherwise.
29
Adapted from http://en.wikipedia.org/wiki/Apple_inc (accessed on 10. September 2008).
30
See http://semantic-mediawiki.org/wiki/Property (accessed on 10. September 2008).
Typed links (aka “relations”31) are classified hyperlinks between the subjects of different wiki
pages indicating the relation between those subjects. Whereas normal links just point to
another wiki page, typed links also indicate in a machine interpretable form how the two
pages are semantically related to each other (see Figure 2-3). In technical terms, SMW struc-
tures information based on RDF(S) data models. Each typed link represents a statement ex-
pressed in so-called “RDF triples” consisting of a subject (“Apple Inc.”), predicate (“head-
quartered in”) and object (“United States”). All three elements of the triple are associated
with a Uniform Resource Identifier (URI) in order to allow an unambiguous representation of
their concepts. Although creating typed links seems to be a rather complicated procedure
for non-technical users, in fact, the SMW extension provides a simple syntax that only
slightly increases the complexity compared to making normal links in Wikipedia. To create a
normal link in classical MediaWiki markup, double square brackets have to be put around a
term: [[United States]]. For typed links, the meaning of the relation just has to be add-
ed in front of the term followed by double colons: [[headquartered in::United
States]]. If the article is saved, the software will automatically parse the typed links and
saves them in a separate RDF database called “triplestore”. The differences between the two
markups are illustrated in Table 2-2.
Attributes are very similar to typed links in how they are created and function in SMW, but
they focus on incorporating data values instead of describing the semantic relation between
two subjects. Apparently, it is very unpractical to represent values such as numbers, coordi-
nates or dates as typed links, because this would require creating pages that have simple
value as titles. It is to note that some values might be represented in Wikipedia as separate
wiki pages, as it is the case with “1976” in our example. In traditional Wikipedia, the page
holding the title “1976” lists all important events that happened in that specific year. How-
ever, in the article about Apple Inc. it is also stated that the company employs about 28’000
people worldwide. Obviously, it would not make sense to have a separate page with the title
“28’000” or “28’000 employees”.32 Instead, attributes should be assigned to each value indi-
cating the relationship to the subject of the wiki page. In our example, the fact that Apple Inc.
was founded in 1976 can be written as follows in SMW markup: [[foundation
year:=1976]]. Instead of a double colon, attributes are expressed by using the combina-
tion of a colon following an equals sign (see also Table 2-2). Finally, attributes can be asso-
ciated with predefined data types (e.g. “integer” or “date”) to make those values even better
processable by machines. For instance, the system could compare or sum up two integers, or
calculate the difference between two dates.
31
See http://semantic-mediawiki.org/wiki/Relation (accessed on 10. September 2008).
32
Moreover, we will also show further in our discussion that the SMW extension also offers better solutions
than manually listing all events that happened in 1976.
Table 2-2: Source of an article on Apple Inc. presented in different forms
Presented Text
Apple Inc. is a multinational corporation headquartered in the United States. It focuses on
designing and manufacturing consumer electronics and software products and was estab-
lished in 1976.
Classical MediaWiki Markup
'''Apple Inc.''' is a [[multinational corporation]] headquartered in
the [[United States]]. It focuses on designing and manufacturing [[con-
sumer electronics]] and [[software]] products and was established in
[[1976]].
SMW Markup
'''Apple Inc.''' is a [[is a::multinational corporation]] headquartered
in the [[headquartered in::United States]]. It focuses on designing and
manufacturing [[produces::consumer electronics]] and [[produc-
es::software]] products and was established in [[foundation
year:=1976]].
Potential applications in SMW

Through the introduction of typed links and attributes, the content stored in wikis becomes
more structured and machine interpretable, which creates a potential to build powerful
functionalities and tools. In the following, some of the most basic and obvious applications
of the SMW extension will be discussed.
• Semantic Queries (following Völkel et al., 2006, p. 588). The current MediaWiki software
features only a very simple and restricted search functionality based on full-text search.
In order to get the answer to the question about the founding year of Apple Inc., the user
has to read through the whole wiki page of “Apple Inc.”. Since the SMW extension makes
information interpretable for machines, much more sophisticated search functionalities
– i.e., semantic queries – can be realized. Direct queries enable users to directly search
for a specific piece of information contained in a wiki page33. For example, a user could
directly query for the country where Apple Inc. is headquartered. As a result, the single
word “America” would be displayed instead of the whole text from Apple’s wiki page.
Furthermore, SMW also allows for aggregated queries. A user may want to make a list of
all companies that are headquartered in America. This task would be almost impossible
within the classical Wikipedia, because it would basically require the user to search for all
wiki pages describing companies and then scan those pages for locational information. In
SMW, the user could directly input such an aggregated query and the system would re-
turn a list of all companies headquartered in America. The user could even narrow the
list by querying only for American companies founded between 1970-1980, since the
foundation years are stored as attributes and can be processed by the SMW.
33
Provided that this specific piece of information has been semantically annotated.
• Logical inferences (following Krötzsch et al., 2005, pp. 7-8). For semantic wikis, it is not
only possible to query for information that is explicitly stated in typed links and
attributes. Based on RDF and OWL, even logical inferences about knowledge that is only
implicitly stated can be realized. For instance, a semantic wiki could infer that the Apple
Company was founded in a leap year although this information is not explicitly men-
tioned anywhere in Wikipedia. It can generate this information by combining the two
statements “Apple was founded in 1976” and “1976 is a leap year” and processing them
with predefined logical inference rules.
• Customizable information presentation and visualization (following Völkel et al., 2006,
p. 589). Since information can be automatically processed by the SMW, it is also possible
to create new ways to present and even visualize information. A simple example would
be including an automatically generated infobox in a wiki page which summarizes the
most important information about the subject of the page. In combination with aggre-
gated queries, an even broader application spectrum could be realized. For instance,
SMW could compare the “founding year”, “current number of employees” and “global
market share for computer hardware” between Apple Inc., Microsoft and IBM and visual-
ize the results for a better understanding (see Figure 2-4).
• Interoperability with external systems (following Völkel et al., 2006, pp. 589, 592-593).
Semantic web technology not only aims at enabling machines to interpret information,
but also has the goal to allow the automated exchange of information between different
IS systems. Typed links and attributes help external systems to directly access a semantic
wiki and retrieve information in a structured format. For instance, an online map service
could take the geographical coordinates of Apple Inc. and display its location on an on-
line map. Furthermore, it is also possible that SMW imports external information from
other databases and services to include it in its own database. In the case of our example,
SMW could dynamically update the current stock price of Apple Inc. from a financial data
service such as Bloomberg34. On the one hand, this would save the effort of manually
updating the share price in short intervals. On the other hand, it would also improve data
quality because information is always up-to-date.
34
See http://www.bloomberg.com/ (accessed on 10. September 2008)
Founding Year (Timeline)

Present
Apple Inc. (1976) (2008)
IBM (1989) Microsoft (1957)
1850
1900
1950
1960
1970
1980
1990
2000
2010
Current Number of Employees Global Market Share:
(Bar Chart) Computer Hardware (Pie Chart)
400'000 5%
8%
300'000
Apple Inc.
200'000
100'000 15% Microsoft
0 IBM
72% Others
Figure 2-4: Example of information visualization
Potential challenges and solutions

In the previous parts of this thesis, mainly advantages and potential applications of SMW
have been discussed. However, it is also important to consider possible challenges that may
arise through the introduction of the SMW extension. There are two particular aspects that
may decrease the performance and usability of a SMW.
First, the concepts and elements of a SMW are more difficult to understand, especially for
non-technical users, compared to the simplicity of traditional wikis (see Krötzsch et al., 2005,
p. 3). Even if we assume that most of the non-technical users are able to learn how to create
typed links and attributes, it is unlikely that they can perform sophisticated semantic queries
based on the current query language of SMW35. As a consequence, non-technical users may
not engage in the creation of typed links or attributes, because they do not see a direct ben-
efit of spending additional effort to create semantic annotations.
Second, the additional effort of creating typed links and attributes may raise the barrier to
participation and lower the usability of the SMW. As already mentioned, the reason for Wi-
kipedia’s success is partially due to its simplicity and intuitiveness. The question is whether
the benefit of extending traditional wikis with semantic web technologies will make up for
the additional effort spent on implementing the SMW extension, including learning its con-
cepts and usage, and annotating wiki content.
Some solutions in response to these challenges have already been realized or are currently
under development:
35
See the user manual about the SMW query language: http://semantic-
.mediawiki.org/wiki/Help:Inline_queries (accessed on 10. September 2008).
• The semantic forms extension in combination with semantic templates provides an input
mask for editing and displaying semantically annotated content without having to use
any markup language. This solution is especially useful when a wiki has to be populated
with pages that share the same content structure. The user just has to fill in all fields of
the input mask and the system will automatically add the predefined semantic annota-
tions. Regarding our example, the input mask could be a company profile including name,
foundation year, number of employees, revenue etc.36 An additional advantage of this
approach is that annotation are made in a consistent way.
• Concepts are predefined queries that create a dynamically updated wiki page. The above
mentioned aggregated query for a list of all companies headquartered in America could
be realized as a concept. Whenever a new wiki page about an American company is
created and semantically annotated, the list is automatically updated.37
• Predefined search forms are an even more flexible way for non-technical users to per-
form semantic searches without having to know much about query languages. A very
simple search form is realized by the “Search by Property” form, where the user can
search for all sites containing a specific property with a specific value. 38 For instance, the
user could enter “foundation year” (property) and “1976” (value), and then would re-
ceive a list with all organizations that have been founded in 1976. Note that predefined
search forms may not exactly match the user’s specific needs. In our example, the results
would not only include all companies but all type of organizations founded in 1976.
• Import of structured data is a viable alternative to having users manually annotate wiki
content. The idea is to use import tools and templates to transform the structured data
into annotated wiki pages with a predefined format. This feature is still under develop-
ment but can already be tested.39
2.3.3 Semantic wikis for corporate metadata management

At the end of chapter 2.2.2, corporate metadata management was proposed as a potential
field of application for corporate wikis. However, it was also noted that there is a tradeoff
between the simplicity of a wiki, which lowers the barriers for participation, and the lack of
enforced formal structures, which may prevent the wiki to be useful for the management of
complex metadata. In chapter 2.3.2, it was discussed that by extending traditional wikis with
concepts from semantic web technologies, the above mentioned tradeoff could be circum-
vented. Typed links and attributes can serve as structuring elements to the unstructured
information while keeping the simple nature of wikis that makes them so useful. As a result,
36
For detailed information refer to: http://www.mediawiki.org/wiki/Extension:Semantic_Forms (accessed on
10. September 2008).
37
For detailed information refer to: http://semantic-mediawiki.org/wiki/Help:Concepts (accessed on 10. Sep-
tember 2008).
38
See http://semantic-mediawiki.org/wiki/Special:SearchByProperty (accessed on 10. September 2008)
39
For detailed information refer to: http://semantic-mediawiki.org/wiki/Help:Ontology_import (accessed on 10.
September 2008).
we conclude that semantic wikis may also be successfully employed for the management of
complex metadata.
As showed in chapter 2.1.1, corporate metadata management itself is a very complex and
broad topic, including various aspects on both technical and non-technical levels. Apparently,
a corporate semantic wiki cannot be applied to address all those aspects. Instead, it would
make more sense to focus only on those fields of application where the advantages of a se-
mantic wiki can be fully exploited. The simplicity of wikis particularly addresses the needs of
business users who may only have very limited technical proficiency. Therefore, we can nar-
row down the useful application of corporate semantic wikis to the management of business
metadata.
The main purpose of business metadata is to support business users in their operative
workflow and decision-making processes (Marco, 2000, p. 51). In this context, metadata de-
livers standard descriptions of business data in textual or other forms. This information can
be accessed in a centralized metadata repository which, in our case, is a corporate semantic
wiki (see Dyché, Levy, Peppers, & Rogers, 2006, p. 165). Business metadata can describe four
categories business data depending on its function and transformability (see Hansen &
Neumann, 2005, p. 8; Lassmann & Schwarzer, 2006, p. 218):
• Master data represents data that is not subject to change over a longer period of time,
such as customer, supplier, product, materials and employee data.
• Inventory data contains all information that describes quantitative business information
such as warehouse stock, production assets or account balances. The amount of invento-
ry data may not change significantly over a longer period of time, whereas the data itself
changes much more frequently through the course of business.
• Transaction data is transaction-oriented data describing business activities such as or-
ders, payments, delivery records etc. It is subject to frequent changes triggered by vari-
ous business activities and accumulates in the course of business.
• Change data is data that triggers changes of master data, such as changes of customer
data (e.g., address changes), adding new suppliers or products etc.
A corporate semantic wiki can serve as a business metadata repository containing all infor-
mation to enable an efficient and effective use of those four categories of business data. Due
to its ease of use, the semantic wiki is expected to reduce the time for retrieving information,
and therefore, enables the business users to quickly return to its main business activity.
The following chapter 3 and 4 describe a case where a semantic wiki based on the Semantic
MediaWiki extension has been implemented in a corporate context for master data man-
agement.
Chapter 3: Designing a corporate semantic wiki at Bayer CropScience 28
3 Designing a corporate semantic wiki at Bayer CropScience

3.1 Introduction
3.1.1 General information about BCS40

With its headquarter located in Monheim, Germany, Bayer CropScience (BCS) is a global
leader in the areas of crop protection, pest control, seeds and plant biotechnology and
represents one of the three subgroups of Bayer AG (i.e., Bayer HealthCare, Bayer MaterialS-
cience, and Bayer CropScience). BCS was established in 2002 through the acquisition of
Aventis CropScience by Bayer, although Bayer’s history in providing agrochemical solutions
can be dated back to the late 1960s. As a subgroup of Bayer AG, BCS runs its operations in-
dependently, led and supported by the management holding company of the Bayer Group.
BCS currently employs about 17.800 people in more than 120 countries. In 2007, the com-
pany generated around EUR 5.826 billion in sales and reached revenues of EUR 656 million
(EBIT). BCS runs three business operation units:
• Crop Protection provides products and services for chemical plant protection in the field
of agriculture. The four major focus areas are herbicides, insecticides, fungicides and
seed treatment. In 2007, the Crop Protection business unit contributed 82.1% of total
sales which makes it by far the largest and most important part of BCS.
• Environmental Science focuses on non-agricultural markets by offering solutions to con-
trol pest and weeds for household use (e.g., gardening) and professional use (e.g., golf
courses). The Environmental Science unit generated in 2007 11.4% of the overall turno-
ver.
• BioScience operates in the field of biotechnology and applies state-of-the-art breeding
technologies to improve the quality of vegetable and agricultural seeds. Besides sales of
the actual seeds, the BioScience unit is also marketing its proprietary technology to other
partners. The unit’s share of total sales reached 6.6% in 2007.
3.1.2 Project background
Triggering factors
In general, many large and globally active enterprises have to rely on disparate and redun-
dant information systems for their daily business. BCS is also facing the problem of having
three different SAP systems, each operating independently in the US, European or Asian Pa-
cific region. One major factor that contributes to the heterogeneity of BCS’ system landscape
is the large number of mergers and acquisitions that happened across the whole history of
the company – for instance the merger of AgrEvo and Rhône-Poulenc Agro that formed
Aventis CropScience in 2000 and the subsequent acquisition by Bayer that formed Bayer
CropScience in 2002.
40
Information taken from the official BCS homepage (www.bayercropscience.com) and Bayer homepage
(www.bayer.com).
On the one hand, having autonomous SAP systems dedicated to a specific region has its ad-
vantages, because these systems can be more easily and quickly adapted to local business
practices and regulatory requirements. On the other hand, the separation of systems also
causes several internal and external challenges that are become a growing concern for BCS:
• New compliance regulations – such as the Globally Harmonized System of Classification

and Labeling of Chemicals (GHS)41 – require BCS to make specific sets of data available to
regulatory bodies and other entities in an integrated and transparent form. Since these
sets of data are generated and treated differently within the three disparate systems,
there is a risk for BCS failing to meet these regulatory requirements.
• The Bayer AG controls and maintains parts of the materials master data for all its sub-
units, including BCS, in its own group-wide SAP system (E44). Every subunit has to inte-
grate the materials master data in its own system(s). Since BCS operates three SAP sys-
tems, the integration effort is also threefold, which causes redundancies, unnecessary
costs and decreasing data quality.
• All of BCS’ business processes highly depend on the support of the underlying IS infra-
structure. Therefore, heterogeneous systems and inconsistent data impede BCS from
realizing an optimal level of process standardization and increase the time and cost to
carry out those processes (see also Mertens, 2007, p. 5; von Maur, Schelp, & Winter,
2003, pp. 11-12).
• Having three disparate systems also leads to the inability to interact with global custom-
ers and suppliers as a single entity. Customer and supplier data is redundantly and incon-
sistently stored in all three SAP systems. As a result, BCS is losing negotiation power over
its customers and suppliers, because it is unable to coordinate its purchases and sales of-
fers on a global scale.
Facing these growing business problems, BCS decided to launch a global harmonization
project that aims at integrating all three SAP systems into a single company-wide system and
creating a single point of truth for all master data in order to enable consistent reporting and
global processes.
The need for an integrated master data management handbook

Besides the actual integration of the systems, the global harmonization project also involved
several small technical and non-technical side-projects. One of those side-projects con-
cerned the complete overhaul of the existing Master Data Management Handbook 2.0
(MDM HB 2.0). The handbook supports users of BCS’ SAP systems on their daily workflow.
Although the SAP systems already offer a built-in help that displays general information
about master data fields and transactions, the MDM HB 2.0 provides additional BCS-specific
metadata needed by technical and non-technical users.42 However, the existing handbook
41
See http://www.unece.org/trans/danger/publi/ghs/ghs_welcome_e.html (accessed on 20. September 2008).
42
A detailed description of the handbook follows in chapter 3.2.
does not provide the expected performance in many ways – e.g., functionality, usability,
content quality. As a consequence, the handbook is only consulted on rare occasions and is
not considered an essential support-tool for daily business.
Regarding the global harmonization project, BCS recognized that the existing handbook had
to be improved in order to meet the needs of current and future users. In particular, the
master data team responsible for the MDM HB 2.0 considered that the consolidation of the
SAP systems would pose a major change to the working routines of many users, and there-
fore improving the performance of the handbook was regarded as vital for the successful
management of the change process to the new system.
Building a PoC for a corporate semantic wiki

The underlying concepts of semantic wikis were introduced to BCS in former workshops of
the CC CDQ research program (see 1.3) and were regarded as a potential alternative to the
Lotus Notes database solution of the existing handbook. The expected features of the se-
mantic wiki to support corporate metadata management (see 2.3.2) have particularly drawn
the attention of BSC, since their handbook represents basically a large business data dictio-
nary which is particular type of metadata repository. However, the application of semantic
wiki technology to corporate metadata management is an emerging concept, and thus there
are no well-documented cases in which a semantic wiki had been implemented for that very
purpose. It was decided to build first a PoC that should demonstrate the functionality and
performance of the semantic wiki for only a part of the handbook. If the PoC meets the re-
quirements and expectations, the whole handbook will be ported to the semantic wiki solu-
tion.
3.1.3 Design approach

The approach adopted to design the PoC for BCS can be divided into three parts:
The first step represents the as-is-analysis of the current MDM Handbook used at Bayer (see
3.2). The main focus was to identify the shortcomings and missing functionalities of the cur-
rent solution as perceived by the actual users. Empirical data was gathered through six semi-
structured, individual expert interviews (see Appendix II). The interview guideline has been
designed based on the organization, task and agent model of the CommonKADS method
(see Appendix III). These three models focus on different important aspects of the organiza-
tional context that should be considered when developing information systems. A short in-
troduction to the CommonKADS method and the three models can be found in Appendix I.
After each expert interview, an interview report was written and sent to the interviewee for
review, in order to assure accuracy of empirical data (see Appendix IV).
In the second step, a list of requirements has been developed summarizing the shortcomings
and missing functionalities identified in the expert interviews (see 3.3.1). Based on these
requirements, concrete specifications have been deducted intended to be implemented in
the PoC (3.3.2).
In the final step, the actual PoC has been built by the FZI based on the above mentioned spe-
cifications and the imported data sets from the MDM Handbook 2.0. An extensive descrip-
tion of the PoC is provided in chapter 3.4.
3.2 As-Is-Analysis of the MDM Handbook 2.0
3.2.1 Formal description

The current solution implemented at BCS represents the second generation of the business
data dictionary and runs under the name “MDM Handbook 2.0”. It is realized as a Notes
client database offering all functionalities provided by IBM‘s Lotus Notes application (see
Figure 3-1).
Figure 3-1: Notes client database version of the current MDM Handbook
In addition, an online version of the handbook can be accesses through any standard web
browser and provides almost the same functionality as its Notes based counterpart (see Fig-
ure 3-2).
Figure 3-2: Web-based version of the current MDM Handbook

The handbook divides BCS master data into three different categories: materials, vendor and
customer master data. For all three categories, similar content structures and functionalities
are provided. In the following, we will focus only on the materials master data category the
PoC has been built for.
Looking up information
The handbook offers both navigation and search functionalities to look up information (see
Figure 3-3):
• Navigation: The user can navigate along different categories of which “by Fieldname”
and “by Process” are used by more than half of all interviewees (see Appendix IV).
• Search: The user can perform a simple full-text search by entering a word or a string of
text into the search field. Lotus Notes also offers advanced search functionalities which,
however, have almost never been used by any of the interviewees (see Appendix IV:).
Figure 3-3: Navigation and search functionalities
The results for both navigation and search are displayed as tables including information such
as “Fieldname” (name of the corresponding field in the SAP database), “Description” (textual
description of the field), etc. (see Figure 3-4). Colored dots on the left side of each row indi-
cate the quality of the metadata regarding its timeliness. The results can be further sorted by
clicking on a tab displayed on the top of each column.
Figure 3-4: Results table for navigation and search

Content and structure of each MD field

By double clicking on any row in the result table, a new Lotus Notes windows opens display-
ing detailed information about that particular MD field (see Figure 3-5). The user can access
the information in a structured way by browsing through different tabs which are accessible
below the general information box on the top of the page. The tabs most relevant to the
majority of users are:
• “Main Infos”: Contains technical and administrative metadata about the MD field, such
as information already displayed in the results table (see Figure 3-4).
• “Field Description”: Provides a BCS-specific definition and usage description of the par-
ticular MD field. Depending on the MD field, additional data such as country specific in-
formation, pictures or documents are included in this tab.
• „Field Maintenance“: Offers information regarding the maintenance of the particular
MD field, such as rules, instructions, country specific regulations etc.
• “Business Rules“: Holds a list of predefined procedures that have to be followed in the
case that the SAP-system encounters a specific error regarding a specific field.
• „Extras“: This tab does not have a specific function assigned, but rather serves as a con-
tainer for relevant information that does not fit into the other tabs. In most cases, this
tab contains the German version of the “Field Description” tab to circumvent the lack of
multi-language support of the handbook.
Figure 3-5: Detailed information page for each MD field

3.2.2 Shortcomings and missing functionalities

Based on the expert interviews, major shortcomings and missing functionalities of the cur-
rent solution have been identified as indicated below:
General shortcomings
Several negative points about the MD HB 2.0 have been mentioned by the interviewees that
are not directly related to the technical features and the design of the handbook, but were
caused by deficits during the roll-out and subsequent phases of the MDM HB 2.0 implemen-
tation (e.g., no training). Nevertheless, we tried to address those general shortcomings dur-
ing the development of the PoC:
Table 3-1: General shortcomings of the MDM HB 2.0
General Shortcomings
Lack of formal intro- No interviewee has received any formal introduction and training
duction and training for the handbook. Instead, they all were introduced to it by a simple
email containing the Lotus Notes database link. Although this did
not significantly impede the usage of the handbook, the interview
results reveal that, due to the lack of formal training, the handbook
is used sub-optimally.
Lack of documenta- No user manual documenting the proper usage of the handbook
tion was distributed to any of the interviewees.
Quality of content Some interviewees criticized the large proportion of missing, incom-
plete or out-of-date information. It was also mentioned that anoth-
er reason for the low popularity of the handbook is because many
fields are only minimally documented.
Language limitations Although BCS’ corporate language is English, some issues arise if the
information of the handbook is not available in other languages.
Deborah Harms, responsible for the Asian Pacific Region and one of
the interviewees, highlights an important fact: 50% or less of the
employees in the Asian Pacific Region speaks English well enough to
understand the English version of the MDM Handbook 2.0. Moreo-
ver, it was mentioned by another interviewee that German users
(especially business users) would also appreciate if highly technical
information would be available in German.
Deficits of the navigation function

Three interviewees mentioned that they are using the navigation function. Navigation “by
Fieldname” and “by Process” is frequently used. The navigation’s overall usability is suffi-
cient, but there are a few minor issues that hamper its use (see Figure 3-3):
Table 3-2: Navigation deficits of the MDM HB 2.0
Deficits of the navigation function

“by Process” The navigation category “by Process” does not correspond to the
actual business processes of BCS. Instead, the handbook sorts the
results along different SAP modules.
“Different Usage” and To most interviewees, the meaning of both navigation categories
“Used System & IDocs” is unclear, and therefore, they are never used.
Deficits of the search function

Two interviewees mentioned that they are using mainly the search function to look up in-
formation. An interesting finding is that no interviewee does actually use or even know
about the advanced search functions. The shortcomings that decrease the usability of the
search function are as follows:
Table 3-3: Search deficits of the MDM HB 2.0
Deficits of the search function

Too many results When searching by the textual description of a fieldname, the handbook
comes up with too many irrelevant hits. E.g., querying for “base unit of
measure” through simple search yields almost 40 different hits.
Double fields When searching for a fieldname of a MD field that exists in two different
tables of the SAP database, the handbook shows two entries with the
same fieldname (e.g., “VOLUM” or “VOLEH”). Technical users may be
able to handle this problem because they understand table structures,
but for business users this might cause some confusion, especially if the
descriptions of those two fields do not contain the same information.
Sorting results Sorting the results twice – i.e. “sort-within-sort” – is not possible. E.g.,
sorting first by “System” and then sorting the results again by “Process”
is not possible.
Suggestions for additional features and functionalities

As a result of the above mentioned shortcomings and general deficits in the usability of the
MDM HB 2.0, the interviewees suggested several features and functionalities which they
would like to see in the new version of the handbook:
Table 3-4: Suggestions for additional features and functionalities
Suggestions for additional features and functionalities

Integration with SAP If a user is working in SAP and wants further information about
how a specific MD field is used, it would be of great benefit if
he/she could directly access the relevant descriptions within the
handbook (by using something similar to the current F1-help
function) without having to manually open the handbook and
search for that specific field.
Indication of relations Information for a specific MD field does currently not indicate
and dependencies be- dependencies to other fields. For example, the handbook does
tween fields not indicate if maintaining data in one field automatically re-
quires maintaining data in another field.
Individual configurations The user should be able to have all relevant information on a
single page and should not have to collect pieces of information
from different tabs.
Multi-language support Both the interface and the actual content should be available in
(interface & content) the user’s preferred language.
Documentation accessi- The new handbook should provide a user guide and similar help
ble directly within the functions.
Handbook
Links within the hand- Each description should have links to all other relevant and de-
book pendent fields.
Feedback- /comment- Users should be able to post feedback / comments (e.g., missing
functionality or out-of-date information).
3.3 Definition of requirements and specifications
3.3.1 Requirements
In the following, the identified shortcomings and missing functionalities of chapter 3.2.2 are
translated into requirements for the development of the PoC.
General requirements
As previously mentioned, the general shortcomings are not directly related to functional
deficits of the MDM HB 2.0. Nevertheless we tried to deduct general requirements for the
development of the PoC, which may somehow address these issues.
Table 3-5: Deduction of general requirements
General shortcomings Æ General requirements

Lack of formal G.1: An intuitive design of the user interface and content struc-
introduction and training ture should be able to compensate for the lack of introduc-
tion / training
G.2: Tutorials should be directly accessible within the PoC
Lack of documentation G.3: Manuals should be directly accessible within the PoC
Quality of content G.4: Users should be able to report missing, incomplete or out-
of-date data to the responsible maintainer
G.5: PoC should provide a tool to populate the content data-
base in a simple but structured way
G.6: PoC should allow an automated search for outdated data
Language limitations G.7: The user interface should support different languages
G.8: The content should be available in different languages
Navigation and search requirements

The navigation and search requirements are deducted from the navigation and search defi-
cits.
Table 3-6: Deduction of navigation and search requirements
Navigation deficits Æ Navigation requirements

“by Process” N.1: Change navigation category “by Process” into “by Module”
“Different Usage” & N.2: Do not include these categories in the PoC since they are
“Used System & IDocs” anyway not used and would only cause confusion
Search deficits Æ Search requirements
Too many results All three deficits may be due to the lack of training about how to
Double fields use the search functionality. Therefore:
Sorting results S.1: The search function should be intuitive to understand and to
use
S.2: The search function should be sufficiently documented with-
in the PoC
Suggested requirements
The suggested features and functionalities already represent requirements, and thus no fur-
ther deduction is needed.
Table 3-7: Suggested requirements (no deduction necessary)
Suggested features and functionalities = Suggested requirements

F.1: Integration with SAP
F.2: Indication of relations and dependencies between fields
F.3: Individual configurations
F.4: Multi-language support (interface & content)
F.5: Documentation accessible directly within the Handbook
F.6: Links within the handbook
F.7: Feedback- /comment-functionality
3.3.2 Specifications
In a final step, the requirements of chapter 3.3.1 are translated further into concrete specifi-
cations, which are intended to be directly implemented in the PoC. Given that the PoC is
built upon the MediaWiki software and several extensions including the SMW extension, at
least one of those elements should address the discussed requirements. In order to conduct
the deduction of the specifications in a structured manner, three matrices are used that
align the requirements from Table 3-5, Table 3-6 and Table 3-7 on the vertical axis and the
different elements of the PoC on the horizontal axis (see Table 3-8, Table 3-9 and Table 3-10):
General specifications
Table 3-8: Matrix for the deduction of general specifications
General Elements of the PoC

Requirements
(cf. Table 3-5) MediaWiki Semantic MediaWiki Other
G.1:
Realized in MediaWiki
Intuitive design
G.2: Tutorials can be imple-
Tutorials mented as wiki pages in a
separate namespace
G.3: Context specific
Manual can be imple-
Manual help can be pro-
mented as a wiki page in
vided by tooltip
a separate namespace
function
G.4: Every MD page
Feedback should contain a
Comments can be posted
property that allows
on the discussion page
retrieving the re-
for each MD field
sponsible maintain-
ers email
G.5: Realized through
Content popu- the semantic forms
lation tool extensions (see
2.3.2)
G.6: Every MD page can
Search be associated with a
outdated data timestamp. A list of
outdated pages can
be automatically
retrieved
G.7:
Multi-language Realized in MediaWiki
interface
G.8: Realized through Me-
Multi-language diaWiki software. Con-
content tent must be delivered by
BCS
Navigation and search specifications
Table 3-9: Matrix for the deduction of navigation and search specifications
Navigation and Elements of the PoC

Search Requirements
(cf. Table 3-6) MediaWiki Semantic MediaWiki Other
N.1: Realized in
“by Module” MediaWiki
N.2:
Realized in
Excluding two
MediaWiki
categories
S.1: SMW offers prede-
Performing search
Intuitive search fined search forms
Realized in can be supported by
function such as “Search by
MediaWiki an autocomplete
Properties” (see
function.
2.3.2)
S.2: Manuals and tuto-
Search function rials can be imple-
documentation mented as wiki pag-
es in a separate na-
mespace
Additional specifications
Table 3-10: Matrix for the deduction of additional specifications
Suggested Re- Elements of the PoC

quirements Semantic Me-
MediaWiki Other
(cf. Table 3-7) diaWiki
F.1: MD fields’ corresponding URL can
SAP Integration be exported as a table into SAP,
from which they can be accessed
over the F1-Help.
F.2:
Realized through
Relations &
SMW properties
Dependencies
F.3:
Individual configu- Realized as configurable user pages
rations
F.4:
Realized in MediaWiki. Content
Multi-language
must be delivered by BCS
support
F.5: A manual and tutorial can be im-
Documentation plemented as a wiki page in a sepa-
rate namespace
F.6: Realized through
Realized in MediaWiki
Links SMW properties
F.7: Comments can be posted on the
Feedback discussion page for each MD field
3.4 Description of the Proof of Concept
3.4.1 Application architecture

In the following, a brief overview about the PoC’s application architecture will be provided.
As illustrated in Figure 3-6, the PoC builds upon three basic elements:
• Wiki Engine: The core of the application architecture builds upon the wiki engine “Me-
diaWiki” (version 1.12.0) written in PHP scripting language. The MediaWiki software pro-
vides the basic functionalities as known from Wikipedia (see 2.2.1). In addition, the wiki
engine is enhanced by several extensions in order to gear it towards the particular re-
quirements of BCS (see 3.3). In this regard, “Semantic MediaWiki” (version 1.3) is the
most relevant extension, because it enables the semantic functionalities of the wiki en-
gine.
• Database Management System: The Database Management System (DBMS) is based on
the relational database software “MySQL” (version 5.0.45). On the one hand, the data-
base stores general MediaWiki tables that consist mainly of article content for MD fields,
user account information and administrative data. On the other hand, it also holds SMW
specific tables used by the SMW extensions.
• Web Server: The web server provides the functionality of the wiki engine to the user. It is
based on the “Apache HTTP Sever” software and uses a PHP engine (PHP 5.1.x) to trans-
late the PHP scripting language of the wiki engine into HTML and Java Script.
Web Server
http://mdpedia.de
(Apache HTTP Server)

Web
User
Browser PHP Engine (PHP 5.1.x)
DBMS (MySQL) Wiki Engine (MediaWiki)

SMW Other
Extensions Extensions
Semantic StringFunctions
MediaWiki MediaWiki
Tables ParserFunctions
SMW Semantic
Tables Forms …
Figure 3-6: Application architecture of the PoC

3.4.2 User interface

Since the PoC builds upon the MediaWiki software, its user interface shares many similarities
with the well-know Wikipedia. Therefore, the majority of users are expected to require a
comparably short training period to master the basic usage of the PoC.
The user interface of the PoC can be segmented into four elements (see Figure 3-7):
Figure 3-7: User interface elements of the PoC
Sidebar for navigation and interaction

The sidebar can be found on the left-hand side of the browser. Depending on the status of
the user and the content of the page, the sidebar offers different navigation and interaction
functions grouped thematically into different boxes:
• Navigation Box
Main Page: A direct link to the starting page of the PoC.
By field/module/transaction/table: Allows navigating along different properties
which are contained in all of the MD fields.
• Status Box: Divides the MD fields into three lists – “Up to date”, “To revise” and “Out of
date” – depending on the last validation date of a page.
• Administration Box
Add new field: Opens a form in which the user can edit the content of the page
without having to know anything about wiki markup language (see “Semantic
Forms” in 2.3.2).
Missing responsibility: Shows a list of all MD fields for which no business respon-
sible has been assigned.
Recent changes: Displays a list that tracks all recent changes made to the content
database.
• Search Box: Provides the PoC’s basic search functionality. If the page name (i.e. the
technical MD fieldname) is known, the user can directly access that page by entering the
fieldname into the search field and pressing the “Go”-button. Clicking on the “Search”-
button triggers a standard full-text search for all MD field pages, which can subsequently
be extended to other contents of the database (i.e., search in page discussion, help con-
tent, property descriptions, etc.).
• Toolbox
What links here: Lists all pages that have a link to the page currently opened.
Related changes: Lists all recent changes that have been made in pages to which
the current page links.
Upload file: Opens an interface to upload files to the PoC.
Special pages: Opens a page that lists all special functions and administration op-
tions of the PoC.
Printable version: Shows only the content of the page and hides the navigation
elements to make the page more suitable for printing.
Permanent link: MediaWiki software stores all changes made to the content sep-
arately in its database instead of overwriting it. This function offers a permanent
link to the specific version of the page currently opened even after changes have
been made to it.
Browse properties: Summarizes all properties and their values for the page cur-
rently opened. The browse page displays both outgoing properties that link to
other pages, as well as incoming properties that link to the current page. This
page is very useful to browse among pages that have been semantically linked to
each other by simply clicking on the browsing icon [ ].
Top tabs
The top tabs provide several functions that are directly related to the content of the current-
ly opened page:
• Page: Activated by default, this tab shows the content of the page.
• Discussion: Opens the associated discussion for the current page.
• Edit with form: Opens a form in which the user can edit the content of the page without
having to know anything about wiki markup language (see “Semantic Forms” in 2.3.2).
• Edit: Opens the standard editor of MediaWiki and displays the page content in wiki mar-
kup language.
• History: Shows the history of changes made to the page and allows comparing different
versions, undoing changes and restoring previous versions.
• Move: Under this tab, the user can move all content of the current page, including its
history, to a new page. A redirecting link will then be attached to the old page.
• Watch: Adds the current page to the user’s watchlist.
User Options
This navigation element provides the most relevant functions associated with the user’s ac-
count:
• User page: The user can click on his/her name located next to the user icon [ ] in order
to access the individual user page. Depending on the user’s needs, this page can be free-
ly filled with any kind of content without having to follow a predefined format.
• My preferences: Allows editing various aspects of the user preferences such as interface
language, password changes, skins, time and date formats, etc.
• My watchlist: Shows a list of all pages for which the user has activated the watch func-
tion in the top tabs.
• My contributions: Shows a list of all pages to which the user has contributed.
• Log out: Logs the current user out.
Page Content
The page content will be described in detail in the next chapter (3.4.3).
3.4.3 Content structure

Every MD page begins with a title (technical fieldname) and a short description (see Figure
3-8).
Thereafter follows the actual content of the page. In contrast to the MDM HB 2.0, the PoC
summarizes the content of a MD field on a single page, instead of dispersing it into several
tabs (cf. Figure 3-5). As a consequence, each tab and its content are displayed as a separate
section. It is to note that only the most relevant tabs have been migrated into the PoC (see
3.2.1).
Finally, located on the right-hand side of the page is the “Main Info-Box” which summarizes
the content that was formerly contained in the “Main Infos” tab of the MDM HB 2.0. The
idea of this box is to make the most relevant information for the specific MD field easily and
quickly identifiable for the user without having to scan through the whole page.
Figure 3-8: Wiki page for an MD field

Chapter 4: Evaluation of the IT-artifact 47
4 Evaluation of the IT-artifact

4.1 Evaluation approach
Design Research puts as much emphasis on the evaluation of the IT-Artifact as on its con-
struction. Design cannot be accomplished in a single step, but has to go through several in-
cremental iterations of build-evaluate-cycles. The main goal of the evaluation is to analyze
the IT-artifact’s ability to address the identified problems in an effective and efficient way.
Further, the results gained from the evaluation represent a valuable input for the subse-
quent build-evaluate-cycle (Hevner et al., 2004, p. 85).
For the design of the IT-artifact in chapter 3, we analyzed the design problem on three levels:
First, based on BCS’s initial business needs that served as the background of this research
project, we analyzed the structure and usage of the MDM HB 2.0 and its shortcomings to
address those needs (see 3.2). Second, we deducted all essential requirements the IT-artifact
needs to fulfill (see 3.3.1). Finally, we translated those requirements into concrete specifica-
tions which are directly implemented into the PoC (see 3.3.2). The basic idea of the evalua-
tion approach is thus to test, in a reversed order, how well the IT-artifact addresses the de-
sign problem on those three levels. Since an IT-artifact is only a means to an end and should
thus be centered around the actual users, the same people who participated in the expert
interviews have also been asked to provide feedback for the evaluation of the IT-artifact (see
Figure 4-1).
The first two steps of the evaluation aim at testing the PoC against the initial specifications
and initial requirements (4.2 and 4.3). These tests are rather simple and straightforward be-
cause they mainly require checking whether all deducted points of Table 3-5 to Table 3-10
are sufficiently implemented into the PoC.
By contrast, conducting the scenario tests for the PoC is more complex (4.4). It requires the
selection and development of usage scenarios in which the target users most likely interact
with the IT-artifact. The goal is not to test the PoC’s functionalities from an isolated view-
point, but to assess the utility it creates by supporting the actual users in their daily business
processes. In other words, the scenario test focuses on the alignment between the technical
capabilities of the IT-artifact and the actual needs of business users.
Build Phase Evaluation Phase

Usage and shortcomings
Scenario testing
of MDM HB 2.0
Expert User
Interviews Evaluation
Conceptual requirements for User Testing against
the PoC initial requirements
Concrete technical Testing against

specifications for the PoC intitial specifications
Figure 4-1: Evaluation approach in the context of the build-evaluate cycle
In order to collect data for the scenario tests and for some qualitative aspects of the initial
requirements and specifications, an evaluation with potential users of the MDM HB 3.0 has
been conducted (see Appendix V). The evaluation group consisted of people who have al-
ready participated in the expert interviews to identify the shortcomings of the MDM HB 2.0,
as well as additional participants who showed interest in the new handbook. The evaluation
was designed as a set of tasks which the participants were required to solve by using the PoC.
After each task, the participants answered several questions in an online survey regarding
their experience of using the handbook. In addition, the participants were required to give
feedback about their overall impression of the PoC. Besides using the evaluation results as
testing data in this thesis, the feedback provided by the participants was also used to finalize
the PoC before officially presenting it to BCS.
The user evaluation was divided into three parts. The first part consisted of short and simple
tasks helping the participants to familiarize themselves with the new handbook. The second
part tested the handbook’s performance for specific scenarios. Two versions have been pre-
pared for this part: scenarios for business users and scenarios for maintainers. The last part
asked the participants about their overall impression of the PoC and did not involve solving
any tasks. Because part 2 was split into two different versions and because one participant
skipped part 3, the number of collected answers differs for each part of the user evaluation:
Table 4-1: Number of participants for the user evaluation
Part 1: Introduction 7 participants

Part 2a: Scenarios for business users 2 participants
Part 2b: Scenarios for maintainers 5 participants
Part 3: Overall Evaluation 6 participants
The discussions in chapter 4.3 and 4.4 include many references to specific questions and
results of the user evaluation in Appendix V. In order to avoid confusion with references to
the chapters of the thesis, references to the user evaluation are put in square brackets. For
example, [2a.2] refers to “Reporting a mistake by email” of the user evaluation in Appendix
V.
4.2 Testing against initial specifications

Testing the PoC against the initially developed specifications is conducted by checking
whether each of the specifications in Table 3-8, Table 3-9 and Table 3-10 have been suffi-
ciently implemented in the new handbook. In the following, the results of this test are struc-
tured into three parts. First, we list all specifications which are sufficiently realized in the PoC
(4.2.1). Second, we discuss those specifications which are only partially implemented, be-
cause they are either beyond the scope of this project or because they require specific in-
puts from BCS’s side (4.2.2). Finally, specifications are highlighted which are not or only in-
sufficiently implemented (4.2.3). All specifications are listed as they were described in the
specification matrices. In addition, the corresponding requirements from which they have
been deducted are indicated in round brackets. For instance, “(cf. G.2)” is indicated when
the specification is deducted from requirement “G.2”.
4.2.1 Sufficiently implemented specifications

• Comments can be posted on the discussion page for each MD field (cf. G.4, F.7)
• Every MD page should contain a property that allows retrieving the responsible main-
tainer’s email (cf. G.4)
• Content population tool realized through the semantic forms extension (cf. G.5). This
specification is implemented by using the “add page with form” 43 function of the seman-
tic forms extension (see 2.3.2). A section of this form is illustrated in Figure 4-2.
43
See http://www.mediawiki.org/wiki/Extension:Semantic_Forms (accessed on 21. September 2008).
Figure 4-2: Section of the "Add field with form" function
• Every MD page can be associated with a timestamp. A list of outdated pages can be
automatically retrieved (cf. G.6). Users with maintainer status have access to an addi-
tional “validate” tab on top of every wiki page they are responsible for and which can be
used to set timestamps (see Figure 4-3). Each user can retrieve a list of all pages he/she is
responsible for on the individual user page (see Figure 4-4).
Figure 4-3: “Validate” function to set timestamps

Figure 4-4: List of outdated pages on each user page
• Changing navigation “by Process” to “by module” and excluding two unused categories
(cf. N1 and N2).
• SMW’s predefined search form “Search by Properties” (cf. S.1).
• Individual configurations realized as configurable user pages (cf. F.3).
• Links realized in MediaWiki and through SMW properties (cf. F.6).
4.2.2 Partially implemented specifications

• Tutorials can be implemented as wiki pages in a separate namespace (cf. G.2, F.5). De-
veloping tutorials for the future users of the MDM HB 3.0 is beyond the scope of the PoC
project and has to be developed by BCS. However, the MediaWiki software offers the
possibility to create new namespaces easily and quickly as soon as the tutorials are pro-
vided by BCS.
• Manual can be implemented as wiki pages in a separate namespace (cf. G.3, S.2, F.5).
Same explanation as for the previous specification (tutorials).
• Multi-language interface realized in MediaWiki (cf. G.7, F.4). Developing support for
different interface languages is beyond the scope of the PoC project. The MediaWiki
software already allows switching the interface into different languages. However, only
those elements which are embedded in the MediaWiki software by default can currently
be switched to other languages, whereas elements that have been customized for the
PoC remain in English (see Figure 4-5).
Figure 4-5: Partial support for different interface languages
• Multi-language content realized through MediaWiki software (cf. G.8, F.4). Similar to
the multi-language interface support, the MediaWiki supports multi-language content,
but the implementation is beyond the scope of the PoC project and the task to translate
wiki pages into different languages remains at BCS.
• MD fields’ corresponding URL can be exported as a table into SAP, from which they can
be accessed over the F1-Help (cf. F.1). See the test results of scenario A for a detailed
explanation (4.4.1.3).
• Indication of relations and dependencies realized through SMW properties (cf. F.2). The
PoC offers the functionalities of SMW properties, but relations and dependencies have to
be defined and annotated by BCS since this task is beyond the scope of this project.
4.2.3 Insufficiently implemented specifications

• Context specific help can be provided by tooltip function (G.3). The tooltip function has
not been implemented into the PoC.
• Performing search can be supported by an autocomplete function (cf. S.1). Currently,

the search function does not provide any autocomplete functionality. However, the au-
tocomplete functionality is realized in the “add page with form” page, to autocomplete
the names of business and maintenance responsibles.
4.3 Testing against initial requirements

The PoC is tested against the initial requirements by checking whether all elements from
Table 3-5, Table 3-6 and Table 3-7 are sufficiently addressed by the new handbook. The
presentation of the test results will be structured in the same way as for the testing against
initial specifications (see 4.2). Those requirements which are of qualitative nature (e.g., G.1
“intuitive design”) are tested based on the results from the PoC online survey (see Appendix
V). As already mentioned in the introduction of the evaluation approach (4.1), references to
specific questions and results of the PoC online survey are indicated by square brackets “[ ]”.
4.3.1 Sufficiently addressed requirements

• G.1: An intuitive design of the user interface and content structure should be able to
compensate for the lack of introduction/training. The intuitiveness of the PoC was ex-
plicitly evaluated by the participants of the user evaluation in Section [3.3] (“Ease of use
of the new handbook”): All six participants indicated that the design of the handbook
was intuitive [3.3a]. All participants were able to understand the basic functions of the
handbook in a short or very short period of time [3.3b]. Only one participant mentioned
a counter-intuitive element [3.3c]. The design of the handbook considerably encouraged
four participants to explore new functions [3.3f].
• G.4: User should be able to report missing, incomplete or out-of-date data to the re-
sponsible maintainer. This requirement was tested by two business users in section
[2a.2] and [2a.3] of the user evaluation (“Reporting a mistake by email” and “comment-
ing a potential mistake”). Both participants did not experience any problems [2a.2a,b and
2a.3a,b]44 and the handbook supported them well in both tasks [2a.2c and 2a.3c].
• G.5. The PoC should provide a tool to populate the content database in a simple but
structured way. The data population tool is realized in the PoC through the function
“add page with form” and has been tested by five maintainers in section [2b.1] of the us-
er evaluation (“Creating a new handbook entry”). None of the participants experienced
any serious problems with this task [2b.1a,b]. Four participants indicated that the hand-
book supported them either well or very well in this task [2b.1c]. Three participants
rated the data entry function of the MDM HB 3.0 better or much better than the pre-
vious version, while the other two participants have never created entries in MDM HB
2.0 and were therefore indifferent [2b.1d].
• G.6: The PoC should allow an automated search for outdated data. This requirement is
realized through the individual user pages where each user can access a list of all fields
he/her is responsible for (including the date of the last validation). Section [2b.3] shows
the test results for this requirement (“Periodical maintenance”). A minor issue was men-
tioned by one of the participants [2b.3a]: The list in the individual user pages is not dy-
namically updated after a field has been validated. Currently, the list has to be updated
44
One participant experienced minor issues with missing preference settings for his user account. However,
this issue was caused by a flaw in the test design and did not related to the usability of the PoC.
through the “refresh” tab on top of each page. Section [2b.3] will be further discussed in
detail in Scenario D of the scenario tests (see 4.4.4.3).
• N.1: Change navigation category “by Process” into “by Module”.
• N.2: Do not include the categories “Different Usage” and “Used Systems & IDocs” in
the PoC, since they are anyway not used and would only cause confusion.
• S.1: The search function should be intuitive to understand and to use. The usability and
intuitiveness of the search function has been explicitly evaluated in section [1.2] of the
user evaluation (“basic search and navigation in the sidebar”). All seven participants
completed the two search tasks without problems [1.2a,b]. Five participants rated the
search function of the new handbook as better or much better designed than the old
version; two remained indifferent because they have never used the MDM HB 2.0 [1.2e].
• F.3: Individual configurations. This requirement is realized through the individual user
pages and the preferences settings of the PoC. None of the tasks in the user evaluation
tested explicitly for the functionality of individual configurations. However, several tasks
involved the use of the individual user page and no configuration issues have been en-
countered during these tasks.
• F.6: Links within the handbook. The principle of MediaWiki’s navigation is based on links
between pages. Using link was tested in section [1.4] of the user evaluation and none of
the seven participants experienced any problems [1.4a]. The user evaluation further
showed that maintainers did not have any problems with understanding and creating
links (see section [2a.1] “Creating a new handbook entry” and [2a.3] “Periodical main-
tenance”).
• F.7: Feedback- /comment-functionality. See G.4
4.3.2 Partially addressed requirements

• G.2: Tutorials should be directly accessible within the PoC. As already mentioned for the
testing of initial specifications, the PoC allows creating new pages and namespaces that
can be used to make tutorials directly accessible within the wiki. Four out of six partici-
pants mentioned that there is a general need for instructions (manuals, training sessions)
and one participant mentioned that the tutorials could be designed similarly to the user
evaluation [3.3d,e]. However, the development of tutorials is beyond the scope of the
PoC.
• G.3: A manual should be directly accessible within the PoC. See G.2
• G.7: The user interface should support different languages. As stated during the testing
of initial specifications, the PoC already provides multi-language support for its user in-
terface, but the PoC and BCS-specific elements have to be translated first, which is
beyond the scope of the PoC.
• G.8: The content should be available in different languages: See G.7
• S.2: The search function should be sufficiently documented within the PoC: See G.2 and
G.3
• F.1: Integration with SAP: The PoC and the SAP system can be integrated by creating a
table of URLs into SAP that refer to the different pages in the handbook. Although the
system integration is beyond the scope of the PoC, certain efforts have already been tak-
en to realize the integration for the roll-out of the PoC.
• F.2: Indication of relationships and dependencies between fields: The PoC supports this
requirement through links and semantic annotations. However, since the relationships
and dependencies have not been included in the MDM HB 2.0, they first have to be de-
fined by BCS.
• F. 4: Multi-language Support: See G.7 and G.8.
• F.5: Documentation accessible directly within the handbook. See G.2 and G.3.
4.3.3 Insufficiently addressed requirements

There are no insufficiently addressed requirements
4.4 Scenario testing

Testing the SMW-PoC against the initial requirements and specifications guarantees that the
IT-artifact’s functions show the expected behavior and performance in an isolated test set-
ting. However, these tests evaluate the IT-artifact mainly on a technical and conceptual level,
while addressing the actual needs of the users only partially. Applying scenario testing is
therefore an important method to evaluate the IT-artifact on a human-level by assessing its
performance in a real-life setting (see Harris & Candy, 1999). Since scenarios combine differ-
ent system mechanisms used in a specific situation, the tests reveal technical errors that
could occur at the interfaces of those mechanisms.
In the context of system testing methods, a scenario can be defined as:
“An ordered set of interactions between partners, usually between a system and a set
of actors external to the system. May comprise a concrete sequence of interaction
steps (instance scenario) or a set of possible interaction steps (type scenario).”(Ryser
& Glinz, 1999, p. 2)
Scenario testing exposes the system to various situations expected to be encountered in

practice (Kossiakoff & Sweet, 2003, p. 296). In order to guarantee practical and scientific
significance of the test results and interpretations, scenarios should be developed in a struc-
tured and logical manner (Kossiakoff & Sweet, 2003, p. 134).
Table 4-2 describes the approach that has been taken to design the scenarios and to conduct
the testing on the PoC (following Ryser & Glinz, 1999; Schreiber, 2000; Weidenhaupt, Pohl,
Jarke, & Haumer, 1998):
Table 4-2: Structured approach to scenario testing45
# Step Result
1 Definition Based on the information from the expert interviews conducted during
of the the build-phase, scenarios are selected to cover situations where the PoC
scenarios is expected to be used frequently. For each scenario, a scenario profile is
presented including the following elements:
• Description
• Actors46
• Triggering events
• Expected result
• Priority47
2 Scenario For each scenario, a detailed description of all occurring events and ac-
Diagram tions is developed and formalized into a diagram using the event-driven
process chain (EPC) method.
3 Conducting Each scenario is tested on the IT-artifact through a user evaluation (Ap-
Scenario pendix V). A set of tasks is developed that requires the participants of
Testing the evaluation to pass through the different steps of the scenario dia-
grams. A report summarizes all deviations from the expected behavior of
the system and issues that occurred during the scenario tests.
4 Evaluating Based on the test reports, each scenario test is evaluated. The results for
Results each scenario are interpreted and summarized.
Adopted EPC-semantics and -syntax

The event-driven process chain (EPC) has been developed by the Institute of Information
Management (IWi) of the University of Saarlandes in collaboration with the company SAP AG.
EPC aims at describing business processes in a formalized and structured way, but unders-
tandable to non-technical users (see Keller et al., 1992). EPC can also be applied to support
45
Following Ryser & Glinz (1999); Schreiber (2000); Weidenhaupt et al. (1998).
46
An actor is a “role played by a user or an external system interacting with the system to be specified” (Ryser
& Glinz, 1999, p. 2).
47
The scenarios are prioritized by differentiating between business critical and non-business critical scenarios.
In the context of this research, a scenario is regarded as business critical if the normal business workflow de-
pends on the successful completion of the scenario and a failure to complete the scenario would lead to an
interruption or severe impediment of the workflow.
the development of software (see, e.g., Rittgen, 2002; Szallies, 1998). Therefore, this thesis
adopts EPC to model the different scenarios for the evaluation of the PoC.
An event-driven process chain is a directed graph consisting basically of three main elements
which are logically connected by control flow arcs (see also Figure 4-6):
• Functions are “technical task[s] or action[s] performed on an object to support one or

more company objectives” (IDS, 2006, p.4-1).
• Events represent “the fact that an information object has taken on a business-relevant
state which is controlling or influencing the further procedure of the business process”
(IDS, 2006, p.4-98).
• Logical operators serve as logical links between functions and events (IDS, 2006, p.4-99).
We distinguish between three different types of logical links, i.e. conjunctive (AND), ad-
junctive (OR), and disjunctive (XOR) (Scheer & Thomas, 2005, p. 6).
Figure 4-6: Main elements of EPC
Functions can be further specified by indicating application systems that support the partic-
ular function, organizational units that are responsible to carry out the function, and data
clusters that represent important inputs or outputs of the function (IDS, 2006, p. 3-3). The
application system and organization unit elements are put on the right-hand side of their
corresponding function (without connecting them by arcs). Data clusters are connected to
functions by arcs indicating the flow of information (see Figure 4-7).
Figure 4-7: Additional elements to specify EPC-functions

The modeling of the test scenarios was conducted using the ARIS Business Architect48 tool
developed by the company IDS Scheer AG49. The adopted syntax is based on the ARIS Me-
thod Handbook (IDS, 2006) and the following basic syntax rules have been developed by
Scheer and Thomas (2005, pp. 6-7):
(1) An EPC-model is a directed and consistent graph.

(2) An EPC-model forbids reflexive arcs (arcs with same starting- and ending-nodes) and
multiple arcs (more than one arc between two nodes).
(3) Functions have exactly one incoming and outgoing control flow arc.
(4) Events have exactly one incoming and outgoing control flow arc, except for starting-
and ending-events which only have either of them.
(5) (Not being used)
(6) Logical operators have either exactly one incoming arc and multiple outgoing arcs
(split-operator) or multiple incoming arcs and exactly one outgoing arc (join-operator).
(7) A directed circle consisting only of logical operators is not allowed.
(8) Events are only connected to functions (possibly with logical operators in between).
(9) Adapted (see below).
(10) XOR- or OR-split-operators following an event are not allowed.
(11) There is at least one starting- and one ending-event.
Syntax-rule (9) has been adapted for the sake of clarity. The original rule states that func-
tions can only be connected to events (possibly with logical operators in between). This rule
has been extended to allow functions to be directly connected to other functions given that
the event that should be stated between two functions is implicitly clear50, and thus does
not need to be mentioned explicitly (see Wölfle, 2004, p. 6).
48
See http://www.ids-scheer.com/en/ARIS/ARIS_Software/ARIS_Business_Architect/3731.html (accessed on
25. September 2008).
49
See http://www.ids-scheer.com/international/en (accessed on 25. September 2008).
50
For instance, given the function “user opens browser” the subsequent event „browser is open” does not
need to be explicitly stated, because it can be assumed by the reader and stating it does not provide additional
useful information.
4.4.1 Scenario A: Retrieving MD field information in SAP
4.4.1.1 Scenario profile

Scenario A represents the most common case of interaction between users and the PoC. It
describes the situation when a user is working in the SAP system and he/she encounters a
MD field for which more information is needed in order to continue the workflow. The main
purpose of this scenario is to test the seamless integration between SAP and the PoC. The
expected result is that the user can click on a designated button in SAP and then the PoC
automatically opens in a web browser displaying the searched information in the right form.
Four out of five participants of the expert interviews mentioned the need for such integra-
tion (see Appendix IV).
Table 4-3: Scenario A profile (retrieving MD field information in SAP)
Actors Business users; SAP system

Main trigger A user is working in the SAP system and he/she encounters a MD field
event for which more information is needed in order to continue the workflow.
Expected Result All necessary information is presented to the user in an understandable
form. No media break is expected, meaning that the only task a user has
to accomplish is to click on a designated button in SAP to open the cor-
responding page in the handbook.
Priority Business critical, since the user’s workflow is most likely to be impeded
or cannot even be continued if the needed information is not available.
4.4.1.2 Scenario diagram

The focus of this scenario test lies upon the automated interaction between the SAP and PoC.
The idea is to integrate a periodically updated table (“Handbook URL”) into SAP’s database,
which is used to associate every fieldname in SAP with the URL of the corresponding MD
page in the handbook.
If a user wants to look up information for a specific MD field, he/she first opens the SAP-
specific help window by setting the mouse cursor on the MD field and pressing F1. Within
that window, the user can directly access the corresponding page in the PoC by pressing the
“MDM Handbook 3.0” button. SAP retrieves the associated URL from the “Handbook URL”-
table and opens it in a standard web browser. The PoC then retrieves the information for the
MD field from the content database and displays it.
SAP’s database can hold different “Handbook URL” tables for different languages and SAP
will always refer to the table that corresponds to the user’s preferred language. Since lan-
guage preferences are contained in the URL (e.g., “[…]/en/mdpedia/volum” and
“[…]/de/mdpedia/volum” for the MD field’s English and German version, respectively), SAP
does not need to additionally submit information about the user’s preferred language to the
handbook.
Master data
object is unclear
to the user in
SAP
SAP user sets

mouse cursor on
MD field and SAP user
presses F1
SAP-help window
has opened
User clicks on
"MDM Handbook SAP user
3.0" button
SAP retrieves
SAP Table URL for the
SAP
"Handbook URL" PoC's corres-
ponding MD page
SAP opens URL

in standard web SAP
browser
PoC Content PoC retrieves MD

PoC
Database field information
PoC displays MD
PoC
field information
MD object is clear
to the user in SAP
Diagram 4-1: Scenario A (retrieving MD field information in SAP)

4.4.1.3 Scenario test results and evaluation

The test for scenario A could only be conducted in a hypothetical and simulated way. The
reasons for that are twofold: First, the scope of the project does not include the actual inte-
gration of the PoC with the SAP system, but only requires providing an interface for potential
interaction, which is given by the nature of the MediaWiki engine (i.e., pages can be directly
accessed through the respective URL). Second, since the content database of the MDM HB
2.0 is only available in English, multi-language content support is currently not activated in
the PoC. However, the language of the user interface can be changed (cf. 4.3.2).
Despite these limitations, we conclude that scenario A can be realized without problems in
the final version of the handbook, based on the following reasoning:
• BCS provided documents showing that SAP already supports very similar functionalities
for the web-based version of the MDM HB 2.0. BCS only has to make slight adjustments
to the SAP system (i.e., adding a “MDM HB 3.0”-button) and to integrate the URL tables
into the SAP database. Therefore, we can assume that scenario A can be successfully run
through up to the EPC-function “SAP opens URL in standard web browser” (see Diagram
4-1).
• We simulated the EPC-function “SAP opens URL in standard web browser” (see Diagram
4-1). We manually opened a standard browser and entered the URLs for a predefined set
of MD pages. For all used URLs, the PoC displayed the expected MD pages. This proofs
that the second part of scenario A can be realized without any problems.
• A hypothetical test for multi-language support has been run using Wikipedia as our test
subject, since it is also based on the MediaWiki software. On the English version of Wiki-
pedia (http://en.wikipedia.org/wiki/Main_Page) a random article was opened by using
the “random article” function. Subsequently, the language-prefix “en.” was altered in the
address bar of the browser into “de.” (German), “fr.” (French) and “ja.”, successively. As
expected, Wikipedia displayed either the same article in another language or indicated
that the article does not exist in the particular language.
• A minor limitation for this scenario emerges out of the fact that users need to be logged-
in to access the handbook’s content. Given the current approach, the SAP system does
not provide any user data to the handbook. Therefore, users will not be directed to the
requested page directly, but instead, they have to enter first their username and pass-
word.
4.4.2 Scenario B: Searching for MD metadata outside the SAP system

Besides working in SAP, there are many occasions where technical and non-technical users
need to look up additional information about BCS-specific MD. For instance, if a company
gets acquired by BCS, the master data from the acquired company has to be migrated into
the MD system of BCS. The transformation and mapping of data needs to be supported by
additional MD metadata, such as migration rules, dependencies between different data ob-
jects, etc.
In contrast to scenario A (4.4.1), searching metadata outside the SAP system is much less
automated, and thus requires users to search or navigate manually to find the requested
information.
Table 4-4: Scenario B profile (searching for MD metadata outside the SAP system)
Actors Business users and maintainers

Main trigger Main trigger events are all occasions where a user needs more informa-
event tion about a specific MD object while not working with SAP.
Expected Result All necessary information is presented to the user in an understandable
form. The PoC’s search and navigation functions should enable the user
to quickly find and retrieve the requested information.
Priority Depending on the context, the scenario can be business critical or non-
business critical.

The main purpose of this scenario test is to evaluate several potential methods by which a
user might search and retrieve information from the handbook. Similar to scenario A (4.4.1),
scenario B gets triggered by the need of the user to find additional information about an
unclear MD object. However, because the scenario is triggered while working outside the
SAP system, the user has to manually open the handbook and choose between several ways
to look up the requested information. Moreover, if the user is not already logged-in yet,
he/she has to provide first all necessary authentication information (i.e., username and
password).
For this scenario, four basic ways to look up information in the handbook have been speci-
fied: navigating by the technical MD field names, navigating by SAP modules, searching by
technical MD field names, and searching by MD field descriptions. Searching and navigating
by technical MD field names – which correspond to the table names of the SAP system – are
expected to be mainly used by technical users, whereas the other ways to look up informa-
tion are expected to be used by both technical and non-technical users.
MD object is
unclear to the
user outside SAP
User manually
User data User
opens PoC
Section 1
PoC displays log-in
page
User enters name

User
and password
PoC displays main PoC displays main

page page
User decides how

to search for the User
MD field
User has
User has decided
decided to use
to use search
navigation
function
function
User chooses
between different User enters
User
navigation search term
dimensions
Section 2
User has
User has User has entered User has entered
navigated by
navigated by SAP technical MD field MD field
technical MD
modules name description
fieldname
PoC displays
PoC
potential matches
User selects
User
matching MD field
PoC displays MD
PoC
field information
MD object is clear
to the user
outside SAP
Diagram 4-2: Scenario B (searching for MD metadata outside the SAP system)

Section 1 of Scenario B has been tested in [1.1] (“Login”) of the user evaluation. Six partici-
pants did not encounter any issues during the login procedure. One participant mentioned
to have faced some problems, but did not specify them further [1.1a].
Section 2 of Scenario B has been covered by [1.2] (“Basic search and navigation in the side-
bar”) and by [2a.1] (“Navigating and sorting”) of the user evaluation.
• Evaluation results for [1.2]: All seven participants did not experience any problems while
searching and navigating except one participant, who had minor problems to find the
second half of the alphabetically ordered list of fieldnames [1.2a,b,c,d]. Five participants
found that the new search and navigation functions were better or much better com-
pared to the MDM HB 2.0. The other two participants were indifferent because they
have never used the MDM HB 2.0 [1.2e,f].
• Evaluation results for [2a.1]: This test was only dedicated to business users and exten-
sively tested the navigation functions of the PoC. Although both participants did not ex-
perience any major problems [2a.1c,d], one participant provided only half-correct an-
swers to the two questions posed in this task [2a.1a,b]. Furthermore, both participants
indicated that the new handbook supported them well for this specific task [2a.1e].
4.4.3 Scenario C: Creating semantically annotated MD pages

This scenario tests the MDM handbook for its effectiveness to handle the basic processes of
data population by a maintainer. Although most content is already migrated from the MDM
HB 2.0, various occasions – such as the expansion of BCS’ business scope - may create the
need to add new pages to the handbook in the future.
Table 4-5: Scenario C profile (creating semantically annotated MD pages)
Actors Maintainers
Main trigger The main trigger for this scenario is the event where a maintainer rece-
event ives new content to be populated into the MDM HB 3.0.
Expected Result The new MD content has been successfully populated into the handbook
including automatically and manually created semantic annotations and
links.
Priority Depending on the context, but mainly non business critical.

This scenario follows a rather straight flow of events and functions that can be basically di-
vided into three sections.
Section 1 represents the initial population of new contents into the handbook by using a
particular function of SMW, i.e. “add page with form”. The maintainer simply inputs the
name of the MD page he/she wants to create and chooses from a given list of standard
forms. An input mask opens where the maintainer fills the new contents into different pre-
defined fields (see Figure 4-2). These fields are associated to a template that also includes
semantic annotation information. After all contents have been filled in, the PoC automatical-
ly creates a new MD page, formats and semantically annotates the contents according to the
information given in the template.
In section 2, semantic annotations that are not automatically created through the “add page
with form” function, have to be manually added by the maintainer. Compared to the pre-
vious phase, the maintainer has to use the SMW-specific markup language to create typed
links and attributes.
In section 3, the maintainer reviews both the newly added contents and the semantic anno-
tations by scanning through the MD page and checking the main infobox on the right-hand
side of the page (see Figure 3-8).
Maintainer has recieved

New MD content new MD content to be
populated into SMW
Maintainer opens
Maintainer
PoC
Maintainer
triggers the
Maintainer
function "add
page with form"
Special page
"add page with
form" has
opened
Maintainer enters
Maintainer selects
Section 1
name of the page Maintainer
form to be used
to be created
Input mask has

opened with the
selected form and
pagename
Maintainer fills
new MD content Maintainer
into the form
PoC creates
PoC creates page
semantic an-
MediaWiki tables with new MD PoC
notations defined
content
by the form
SMW tables
New seman-
tically annotated
MD page has
been created
Section 2
Maintainer Maintainer
manually adds manually adds Maintainer
typed links attributes
Additional
semantic
annotations have
been created
Maintainer
Section 3
Maintainer
controls main
controls content Maintainer
infobox of the new
of the new page
page
PoC has been

populated with
new MD content
Diagram 4-3: Scenario C (creating semantically annotated MD pages)


Section [2b.1] (“Creating a new handbook entry”) was fully dedicated to the evaluation of
Scenario C and was tested by five maintainers:
• None of the five participants experienced any problems while populating the handbook
with new MD contents for the first time [2b.1a].
• Only one participant mentioned that it was not easy to understand how the MD content
should be entered into the different fields of the form [2b.1b]. However, this is a minor
problem and is expected to occur only for the first few times a maintainer uses the “add
page with form” function to populate the handbook.
• Four participants found that the PoC supported them well or very well for this task
[2b.1c].
• Three participants rated the new handbook better or much better than the old version,
while two participants were indifferent because they did not have any experience with
the MDM HB 2.0 [2b.1d].
• In addition, one participant explicitly commented the population tool as a “good im-
provement” [2b.1e].
For the user evaluation, the participants did not have to create semantic annotations as de-
scribed in section 2 of scenario C (see Diagram 4-3). Instead, they were given the task to
create normal links.
4.4.4 Scenario D: MD maintenance

This scenario tests the different maintenance mechanisms for the SMW to ensure high con-
tent quality. Although this scenario has not been classified as business critical, data mainten-
ance plays a pivotal role for the long-term success of the prospective handbook. As the as-is-
analysis of the current MDM handbook revealed (see 3.2), poor data quality was one of the
major factors that caused lack of interest and confidence in the existing handbook.
Table 4-6: Scenario D profile (MD maintenance)
Actors Business users, maintainers

Main trigger There are basically two events that may trigger scenario D. On the one
event hand, the periodically scheduled maintenance; on the other hand, every
occasion when a business user encounters a MD page in the handbook
that needs to be updated.
Expected Result All MD pages are updated, which have been identified by business users
or maintainers as pages that need to be maintained.
Priority Depending on the context, but mainly non business critical.

Scenario D can be divided into two parts: a business user section and a maintainer section
(see Diagram 4-4).
The business user section illustrates two ways to report quality issues about the handbook’s
content. The first mechanism depicts a rather time-consuming and non-automated process:
A business user encounters an MD page which needs to be maintained. He/she sends an
email51 to the responsible for this particular MD page, indicating the page name and the in-
formation that is missing, outdated or wrong. If the quality issue is insignificant or does not
have to be fixed urgently, the second mechanism may take place: Instead of directly contact-
ing the responsible maintainer, the business user might just leave a comment in the discus-
sion section of the MD page, on which he/she encountered content quality issues.
The maintainer section describes the periodical maintenance session a maintainer is sup-
posed to conduct from time to time in order to assure the essential quality standards of the
handbook. From the personal user page, the maintainer retrieves a list of all outdated MD
pages he/she is responsible for (see Figure 4-4). The maintainer checks the content and the
discussion section for each page and makes updates wherever necessary. Finally, he/she
uses the “validate” function (see Figure 4-3) to update the list on the personal user page.
Outside the periodical maintenance session, the maintainer may also receive a request di-
rectly from a business user (e.g., by email) to update a MD page he/she is responsible for.
51
Instead of email, the user may also directly call the maintainer as it has been often the case with the MDM
HB 2.0.
Business user section Maintainer section
User has The perdiodical

identified MD maintenance
page that needs session has been
to be maintained triggered
User decides how

to report need for User
maintenance
Maintainer opens
MD maintainer
personal user Maintainer
data
page
User has User has Maintainer

decided sending decided to leave accesses list of
Maintainer
an E-Mail to the a comment on outdated MD
MD maintainer the MD page pages
User retrieves e-
User leaves a
mail address of
comment on the User
the MD
MD page
maintainer
User sends
MD page has been
MD page name E-Mail to User
commented
MD maintainer
Maintainer
accesses
Maintainer
respective MD
pages in the PoC
Maintainer checks
MD page
comments of MD Maintainer
comments
pages
Maintainer
updates MD Maintainer
pages
Maintainer
List of outdated
validates MD Maintainer
MD pages
pages
MD pages have
been maintained
Diagram 4-4: Scenario D (MD maintenance)


Given that Scenario D is composed of a business user section and a maintainer section, the
user evaluation was also split into two different parts: Two business users were required to
report a mistake by email [2a.2] and to comment a potential mistake in the discussion sec-
tion of one MD page [2a.3]. The corresponding tasks for four maintainers were correcting
errors on a MD page after having received an email from a business user [2b.2] and updating
MD pages during the periodical maintenance session, while considering comments about
quality issues proposed by some business users [2b.3].
• Evaluation results for [2a.2]: One of the two participants experienced a minor problem
while reporting a mistake by email. However, this problem was caused by a flaw in the
task design and did not relate to the actual performance of the handbook [2a.2a,b]. Both
participants found that the handbook supported them well for this task [2a.2c]. One par-
ticipant rated the new handbook’s procedure to report data quality issues better than
the previous version; the other participant was indifferent [2a.2d].
• Evaluation results for [2a.3]: One participant experienced a minor problem while com-
menting a potential mistake in the discussion section due to the same reasons as men-
tioned above [2a.3a,b]. Both participants indicated that the handbook supported them
well for this task [2a.3c].
• Evaluation results for [2b.2]: None of the five participants encountered any problems
while correcting an error that was reported to them by email [2b.2a,b]. All participants
found that the handbook supported them well or very well for this specific task [2b.2c].
Three participants rated the new handbook’s process to update/correct data better or
much better than the MDM HB 2.0, while two participants stated indifference due to the
lack of experience with the old handbook [2b.2d]. One participant explicitly commented
on the handbooks support for this task as “very easy, well done” [2b.2e].
• Evaluation results for [2b.3]: Two out of five participants experienced problems while
conducting the periodical maintenance session [2b.3a,b]. One problem was caused by a
lapse in the preparation of the user evaluation, i.e. comments have not been added for
that particular participant. The other problem was caused by the fact that the lists on the
individual user pages were not dynamically updated, but had to be refreshed manually.
Despite those problems, all participants found that the new handbook supported them
well or very well for this specific task [2b.3c].
Chapter 5: Discussion and Conclusion 71
5 Discussion and Conclusion

5.1 Summary
The effective and efficient management of data is a fundamental requirement for any com-
pany to successfully operate in the business environment. Concepts and ideas of metadata
management are able to address specific challenges to data management such as creating a
shared understanding about the meaning of data or enabling intra-corporate data integra-
tion. This research aimed to address corporate metadata management in a novel and inno-
vative way by drawing upon concepts from semantic wiki technology. As the overview about
the state-of-the-art in metadata management and semantic wikis showed (chapter 2), this
approach has so far been insufficiently investigated in scientific and practical literature.
The thesis employed the Design Research paradigm as a methodological framework to struc-
ture the process of developing and evaluating the IT-artifact (Hevner et al., 2004). Founded
in the discipline of IS research, this approach emphasizes the importance of creating new
and innovative IT-artifacts that address hitherto unsolved business problems in an efficient
and effective way. The nature of Design Research is regarded as an iterative cycle between
building and evaluating IT-artifacts. These characteristics are reflected in chapter 3 (Building)
and chapter 4 (Evaluation), which represent together one complete build-evaluate cycle. The
building of the IT-artifact was achieved by identifying the user needs through expert inter-
views and by deriving the corresponding requirements and specifications. The evaluation
was accomplished by engaging the same user group to test the IT-artifact for its ability to
meet the initially defined needs.
The type of IT-artifact developed in this thesis is an instantiation which takes the form of a
fully functional prototype, based on the MediaWiki software and enhanced through the Se-
mantic MediaWiki extension. The prototype is intended to be implemented in a real-life
business context at BCS and is expected to support technical and non-technical users in their
daily work by providing semantically precise definitions and descriptions about the master
data used and maintained at BCS.
The application of the prototype in practice demonstrates the feasibility and consistency of
the theoretical concepts upon which this research is based, i.e. applying semantic wiki tech-
nology to corporate metadata management in a working system. The contribution of the
thesis relies on the detailed documentation of the development and evaluation process of
the prototype. It offers valuable insights into how to build IT-artifacts in a structured way
and inspires further research in similar domains.
5.2 Evaluation of the research design and research process

In this section, we reflect upon the research design and research process that have been
followed throughout this thesis. To evaluate how rigorously this research has been con-
ducted, we fall back upon the initial guidelines for Design Research that have been intro-
duced at the beginning of this work (see Table 1-1; Hevner et al., 2004, pp. 82-90):
1. Research Design as an Artifact. This research developed a prototype of a corporate se-

mantic wiki. A prototype is an instantiation representing one possible type of IT-artifacts.
The artifact addressed an important organizational problem, i.e. the effective manage-
ment of a specific type of corporate metadata at BCS. Furthermore, the artifact had
reached the stage of a fully working prototype, and thus provided proof for the concept
of applying semantic wiki technology to corporate metadata management (see Hevner et
al., 2004, pp. 82-83).
2. Problem Relevance. The interviews conducted with business users and maintainers from
BCS assured that the results of the research effectively addressed existing problems of
the target user group of the IT-artifact. Moreover, the evaluation of the completed PoC
constituted a second mechanism to guarantee, that the problems the IT-artifact was in-
tended to solve were relevant to the user group. However, a comprehensive proof of
problem relevance can only be established after the MDM HB 3.0 being fully imple-
mented and extensively used at BCS.
3. Design Evaluation. Chapter 4 is completely devoted to the evaluation of the IT-artifact.
The evaluation has been conducted on three levels – specifications, requirements and
scenarios – to assure that the IT-artifact provided the expected utility, quality and effica-
cy (see Hevner et al., 2004, p. 85). In addition, different methods have been used to
structure and conduct the collection of data.
4. Research Contribution. This research described a novel and innovative way of using se-
mantic wiki technology for the management of corporate metadata which has hitherto
not been addressed by the research community. By building a prototype, it demonstrat-
ed the feasibility of this approach to be realized in a working system. Moreover, since the
IT-artifact is expected to be used in a real-life context by BCS as a collaborating partner,
this research also demonstrated a clear contribution to business practice (see Hevner et
al., 2004, p. 87).
5. Research Rigor. In this thesis, research rigor has been considered from two perspectives.
First, the design of the research approach followed the Design Research framework as
described by Hevner et al. (2004) and sufficiently considered all guidelines as demon-
strated in this chapter. Second, established methods have been applied for both the de-
velopment (e.g., expert interviews, CommonKADS) and the evaluation (e.g., scenario
tests, EPC) of the IT-artifact.
6. Design as a Search Process. As already mentioned in the beginning of this thesis, the
search process was given through the context of the collaborative research program, out
of which this thesis emerged.
7. Communication of Research. This thesis is expected to be published through the HSG-
internal database EDOK52 which, however, is only accessible to members of the Universi-
ty of St.Gallen. In order to communicate to the broader audience of the research com-
munity, the research results may be published as a scientific journal article. Regarding
the communication to the management-oriented audience, valuable insights gained dur-
ing the conduction of this research are presented to BCS in form of reports and presenta-
tions.
Finally, Figure 5-1 illustrates how the Design Research Framework has been concretely rea-
lized throughout the course of this research (cf. Figure 1-1):
Environment Design Research Knowledge Base
Organizations & People:

• Bayer CropScience (BCS) Building the Prototype: Foundations:
•Institute of Information • Artifact Type: Instantiation • Metadata Management
Management (IWI-HSG) • Proof of Concept (PoC) of a • Wiki Concepts
• Research Center for Corporate Semantic Wiki • Semantic Wiki Technology
Information Technology (FZI)
Business Assess Applicable

Needs Knowledge
Refine
Evaluation: Methodologies:
Technology:
• Specification Tests • CommonKADS
• SAP System
• Requirement Tests • Requirement Analysis
• MDM HB 2.0
• Scenario Tests • EPC
MDM HB 3.0 • Description of the IT-Artifact

• Documentation of the Research Process
• Summary of the State-of-the-Art
Figure 5-1: Design Research framework in the context of this thesis
52
See http://www.biblio.unisg.ch/org/biblio/web.nsf/wwwPubInhalteEng/HSG-Databases?opendocument
(accessed on 25. September 2008).
5.3 Contribution to the research community

Design Research highlights the importance of feeding the insights from the research process
back to the knowledge base (Hevner et al., 2004, pp. 79-81). In this regard, the contributions
of this thesis to the research community are the followings:
• IT-artifact: The PoC developed in this research demonstrates the feasibility of creating a
working system that manages corporate metadata based on concepts from semantic wiki
technology. The detailed description of the completed PoC (see 3.4) may serve as a start-
ing point to further elaborate on the approach of using semantic wikis for corporate me-
tadata management and to investigate other practical fields of applications within a
company.
• Research process: This thesis not only provides a description about the completed PoC,
but also offers a detailed documentation about the development and evaluation process
of the prototype (see chapter 3 and 4 respectively). The insights gained during this
process may provide practical guidance to other researchers in the field of Design Re-
search.
• Summary of the state-of-the-art: By summarizing the key concepts upon which this re-
search is based (see chapter 2), the thesis offers a structured overview about the state-
of-the-art in metadata management and about recent achievements in the construction
of semantic wikis. The summary helps to identify the interrelationship between the two
fields of research and creates a new perspective on the existing knowledge base.
5.4 Implications for further research

Given the well-defined scope of this thesis and the general nature of Design Research as an
iterative cycle between development and evaluation, several issues have not yet been tho-
roughly addressed in this work. However, these issues may serve as potential starting points
for further research:
• Performance gain vs. additional effort. By introducing concepts of the Semantic Web to
corporate wikis, a tradeoff is created between the benefits of having improved search
and navigation functions, and the additional effort needed to semantically annotate the
content of the wiki. Therefore, it would be of great interest to investigate whether there
is actually a net performance gain by using a corporate semantic wiki instead of a) a tra-
ditional corporate wiki and b) the former MDM HB 2.0. Since corporate semantic wikis
are only suited for the management of some specific types of metadata, the insights
gained from this investigation can be helpful to develop and conduct a cost-benefit anal-
ysis for future applications of semantic wiki technology in the corporate context.
• Collaboration vs. authorization restrictions. One reason for Wikipedia’s success is its
principle of unrestricted participation for everyone who wants to contribute to the wiki.
This also implies that everybody can access and change almost any contents in the wiki,
and disputes around controversial topics are solved in a democratic process. However,
companies may need to restrict the authorization of its employees to access or manipu-
late their corporate data. Therefore, further research could analyze whether such autho-
rization restrictions would impede or undermine the collaborative processes fostered by
the wiki concept. Furthermore, possible mechanisms may be investigated that help to
maintain the collaborative nature of wikis, while enforcing some authorization restric-
tions for different user groups.
• Introducing further semantic functionalities. The PoC currently offers only a small part
of all potential semantic functionalities as discussed in chapter 2.3.2. Given the purpose
and nature of a business data dictionary for corporate master data, it would obviously
make no sense to incorporate all possible semantic functionalities into the PoC. However,
there are several functionalities which may improve the performance and usability of the
handbook, but they have not yet been integrated in the PoC because they are beyond
the scope of this research. Therefore, further research may investigate what kind of ad-
ditional semantic functionalities would be of benefit for the performance and usability of
business data dictionary.
5.5 Managerial implications
Benefits from the research for BCS

Obviously, the major benefit of this research for BCS is the IT-artifact itself. Since the hand-
book builds upon the free MediaWiki engine and extensions, BCS does not have to make
substantial investments in software compared to the alternative of buying a commercially
available solution. Moreover, the architecture of the wiki engine allowed customizing the
handbook to the needs of BCS’s business users and maintainers, which have been identified
through interviews conducted in this thesis.
Recommendations for the rollout of the MDM HB 3.0

Although the actual implementation of the new handbook at BCS is beyond the scope of this
thesis, some critical issues that should be taken into consideration during and after the rol-
lout of the MDM HB 3.0 will be briefly discussed in the following:
• Official introduction, training and documentation. As the initial interviews with business
users and maintainers of BCS clearly revealed (see Appendix IV), the lack of formal intro-
duction, training and documentation was a major reason why the MDM HB 2.0 was sel-
dom used by both business users and maintainers. Moreover, participants of the PoC
testing (see Appendix V) also mentioned the need for a formal introduction, training
sessions as well as user guides within the handbook, despite the fact that the MDM HB
3.0 was evaluated as much more intuitive to understand and use. We therefore recom-
mend that all business users and maintainers should be properly introduced to the new
handbook during the rollout phase. A formalized instruction manual should be devel-
oped, which can also be used for training purposes not only during the rollout phase, but
whenever a new employee joins BCS and needs to be trained on all relevant systems.
• Reaching and maintaining a critical mass of active users. In contrast to operational sys-
tems such as SAP, the MDM HB 3.0 represents merely a supporting tool which is theoret-
ically not required by users to fulfill their daily business tasks (as it was basically the situ-
ation with the MDM HB 2.0). Therefore, it is essential to promote and foster the usage of
the handbook in order to reach and maintain a critical mass of active users. As soon as a
critical mass is reached, we assume that several self-enforcing factors will contribute to
the increasing attractiveness of the handbook: First, reaching a critical mass helps broa-
dening the acceptance of the handbook among the user base, and consequently boosts
the promotion of the handbook through word-of-mouth. Second, the more people are
using the handbook, the more feedback about outdated or missing data will be reported
to the business responsibles. This will lead to an increase in the overall data quality of
the handbook which, in turn, fosters its acceptance and increases the user base. Finally,
having a large user base also helps to legitimate further spending in improving and ex-
panding the functionalities of the handbook, because these investments will have a
greater impact on total productivity compared to having a relatively small user base.
Every successful improvement of the handbook will attract more users and help to main-
tain a critical mass.
• Monitoring and re-evaluation. Having the PoC developed and implemented at BCS only
represents the first step in creating a powerful tool to support business users and main-
tainers in their daily business processes. Having acquired a certain proficiency in using
the handbook, both business users and maintainers may develop demands for additional
functionalities, which may further improve their working effectiveness. Also, changes in
the business processes and the organizational structure may require adjusting the hand-
book to new circumstances. Therefore, it is essential to continuously monitor the usage
of the handbook and to conduct periodical re-evaluations in order to react quickly to
emerging needs and other changes. Since the MDM HB 3.0 is realized as a web-based so-
lution, simple web-analytics tools such as “Google Analytics”53 could be used as a moni-
toring solution. Moreover, given the flexibility of the MediaWiki engine, the evaluation
could be directly designed within the handbook.
53
See http://www.google.com/analytics/ (accessed on 25. September 2008).
Chapter 6: References 77
6 References
6.1 Literature
Accenture. (2006). Synchronization - The Next Generation of Business Partnering. Grocery
Manufacturers Association (GMA), Food Marketing Institute (FMI), Wegmans Food Mar-
kets, Accenture LLP and 1SYNCo.
Allen, T. J. (2007). Architecture and Communication among Product Development Engineers.

California Management Review, 49(2), 23-41.
ANZLIC. (2001). ANZLIC metadata guidelines: core metadata elements for geographic data in
Australia. Australian & New Zealand Land Information Council.
Asirelli, P., Little, S., Martinelli, M., & Salvetti, O. (2006). MultiMedia Metadata Management:
a Proposal for an Infrastructure. Paper presented at the Workshop on Semantic Web
Applications and Perspectives (SWAP06), Pisa, Italy.
Aumueller, D. (2005). Semantic authoring and retrieval within a wiki. Proceedings of the Eu-
ropean Semantic Web Conference (ESWC).
Aumueller, D., & Auer, S. (2005). Towards a Semantic Wiki Experience–Desktop Integration
and Interactivity in WikSAR. Semantic Desktop Workshop.
Bao, J., & Honavar, V. (2004). Platypus Wiki: a Semantic Wiki Wiki Web. 3rd International
Workshop on Evaluation of Ontology-based Tools (EON2004).
Bartel, T. (2006, 25.-26. October, 2006). Nutzung von Wikis in Unternehmen. Kollaboratives
Arbeiten mit Wikis im Unternehmensumfeld. Paper presented at the 8. KnowTech „Mit
WM besser im Wettbewerb!“.
Berners-Lee, T., Hendler, J., & Lassila, O. (2001). The semantic Web. Scientific American,
284(5), 28-37.
Burnett, K., Ng, K. B., & Park, S. (1999). A comparison of the two traditions of metadata de-
velopment. Journal of the American Society for Information Science, 50(13), 1209-1217.
Cavana, R., Delahaye, B. L., & Sekeran, U. (2001). Applied Business research: Qualitative and
Quantitative Methods. Australia, Milton: John Wiley & Sons.
Cheng, H., & Laurie, R. (1993). Metadatabase solutions for enterprise information integration
problems. SIGMIS Database, 24(1), 23-35.
Cheng Hian, G., Stéphane, B., Stuart, M., & Michael, S. (1999). Context interchange: new fea-
tures and formalisms for the intelligent integration of information. ACM Transactions on
Information Systems, 17(3), 270-293.
Cunningham, W., & Leuf, B. (2001). The Wiki Way. Quick Collaboration on the Web. NY: Ad-
dison-Wesley.
Dyché, J., Levy, E., Peppers, D., & Rogers, M. (2006). Customer Data Integration: Reaching a
Single Version of the Truth (SAS Institute Inc.). New York: Wiley & Sons.
Ebersbach, A., & Glaser, M. (2005). Wiki. Informatik-Spektrum, 28(2), 131-135.
Fayol, H. (1949). General and Industrial Management. London: Pitman.
Grant, R. M. (1996). Toward a knowledge-based theory of the firm. Strategic Management

Journal, 17(10), 109-122.
Hansen, H. R., & Neumann, G. (2005). Wirtschaftsinformatik I. Grundlagen und Anwendun-

gen (9. ed.). Stuttgart: Lucius & Lucius.
Harris, D., & Candy, L. (1999). Evaluation in the SEDRES Project: Measuring the Effectiveness
of Model Data Exchange between System Engineering Tools. Proceedings of the Annual
Symposium of the International Council on Systems Engineering, INCOSE, 99.
Hasan, H., Meloche, J. A., Pfaff, C. C., & Willis, D. (2007). Beyond Ubiquity: Co-creating Corpo-
rate Knowledge with a Wiki. Paper presented at the International Conference on Mobile
Ubiquitous Computing, Systems, Services and Technologies, 2007.
Hester, A. (2008). Innovating with organizational wikis: factors facilitating adoption and dif-
fusion of an effective collaborative knowledge management system. Proceedings of the
2008 ACM SIGMIS CPR conference on Computer personnel doctoral consortium and re-
search, 161-163.
Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004). Design Science in Information Systems
Research. MIS Quarterly, 28(1), 75-105.
Hitzler, P., Krötzsch, M., Rudolph, S., & Sure, Y. (2007). Semantic Web: Grundlagen. New York:
Springer-Verlag.
Hüner, K. M., Otto, B., & Österle, H. (2008). Metadatenmanagement mit einem Semanti-
schen Wiki. Information Management & Consulting, 23(2), 34-40.
IDS (2006). Methods ARIS 7.0. Saarbruecken: IDS Scheer AG.
Inmon, W. H., O'Neil, B. K., & Fryman, L. (2007). Business Metadata: Capturing Enterprise
Knowledge. Morgan Kaufmann.
Kaplan, R. S., & Norton, D. P. (1992). The balanced scorecard - measures that drive perfor-
mance. Harvard Business Review, 70(1), 71-79.
Keller, G., Scheer, A. W., & Nüttgens, M. (1992). Semantische Prozeßmodellierung auf der
Grundlage Ereignisgesteuerter Prozeßketten (EPK). Research Report 89, Institut für
Wirtschaftsinformatik, Universität des Saarlandes.
Klobas, J., & Beesley, A. (2006). Wikis: tools for information work and collaboration. Oxford:
Chandos.
Kogut, B., & Zander, U. (1992). Knowledge of the firm, combinative capabilities, and the rep-
lication of technology. Organization Science, 3(3), 383-397.
Kossiakoff, A., & Sweet, W. N. (2003). Systems engineering: principles and practices. New
York: Wiley & Sons
Krötzsch, M., Vrandecic, D., & Völkel, M. (2005). Wikipedia and the Semantic Web - The Miss-
ing Links. Paper presented at the WikiMania 2005: The first International Wikimedia
Conference.
Lassmann, W., & Schwarzer, J. (2006). Wirtschaftsinformatik Nachschlagewerk für Studium

und Praxis. Wiesbaden: Gabler.
Lee, A. S. (1999). Inaugural Editor's Comments. MIS Quarterly, 23(1).
Majchrzak, A., Wagner, C., & Yates, D. (2006). Corporate wiki users: results of a survey. Pro-
ceedings of the 2006 international symposium on Wikis, 99-104.
Marco, D. (2000). Building and managing the meta data repository a full-life circle guide.
New York: Wiley Computer Publishing.
Mertens, P. (2007). Integrierte Informationsverarbeitung 1. Operative Systeme in der Indust-

rie (16th ed.). Wiesbaden: Gabler.
Miller, H. J., & Shaw, S. L. (2001). Geographic Information Systems for Transportation: Prin-
ciples and Applications. Oxford University Press, USA.
Milstead, J., & Feldman, S. (1999). Metadata: Projects & Standards. Online, 23(1), 32-41.
Müller, C., & Dibbern, P. (2006). Selbstorganisiertes Wissensmanagement in Unternehmen

auf Basis der Wiki-Technologie: Ein Anwendungsfall. HMD - Praxis der Wirtschaftsinfor-
matik 12(6), 45-54.
Negash, S., & Gray, P. (2008). Business Intelligence. Berlin, Heidelberg: Springer.
Nixon, L. J. B., & Simperl, E. P. B. (2006). Makna and MultiMakna: towards semantic and mul-
timedia capability in wikis for the emerging web. In Schaffert, S., Sure, Y. (Eds.), Proceed-
ings of the Semantics 2006. Österreichische Computer Gesellschaft.
Oren, E. (2005). SemperWiki: a semantic personal Wiki. Semantic Desktop (ISWC).

Raman, M., Ryan, T., & Olfman, L. (2005). Designing Knowledge Management Systems for
Teaching and Learning with Wiki Technology. Journal of Information Systems Education,
16(3), 311.
Redman, T. C. (1998). The impact of poor data quality on the typical enterprise. Communica-
tions of the ACM, 41(2), 79-82.
Rittgen, P. (2002). EMC-A Modeling Method for Developing Web-based Applications. In v. K.

van Slooten (Ed.), Optimal Information Modeling Techniques. Idea Group Inc.
Rosenthal, A., Renner, S., Seligman, L., & Manola, F. (2001). Data Integration Needs an Indus-
trial Revolution. Proceedings of the Workshop on Foundations of Data Integration.
Ryser, J., & Glinz, M. (1999). A Scenario-Based Approach to Validating and Testing Software
Systems Using Statecharts. Paper presented at the Proc. 12th International Conference
on Software and Systems Engineering and their Applications.
Schaffert, S. (2006). IkeWiki: A Semantic Wiki for Collaborative Knowledge Management. 1st
international workshop on Semantic Technologies in Collaborative Applications, STICA06.
Scheer, A. W., & Thomas, O. (2005). Geschäftsprozessmodellierung mit der ereignisgesteuer-

ten Prozesskette. Das Wirtschaftsstudium, 34, 8–9.
Schreiber, G. (2000). Knowledge engineering and management the CommonKADS methodol-

ogy. Cambridge Mass.: MIT Press.
Sen, A. (2004). Metadata management: past, present and future. Decision Support Systems,
37(1), 151.
Shadbolt, N., Berners-Lee, T., & Hall, W. (2006). The Semantic Web Revisited. IEEE Intelligent
Systems, 96-101.
Shankaranarayanan, G., & Even, A. (2004). Managing Metadata in Data Warehouses: Pitfalls
and Possibilities. Communications of AIS, 2004(14), 247-274.
Shankaranarayanan, G., & Even, A. (2006). The Metadata Enigma. Communications of the
ACM, 49(2), 88-94.
Simon, H. A. (1996). The sciences of the artificial (3rd ed.). Cambridge, Mass.: MIT Press.
Stenmark, D. (2002). Information vs. knowledge: the role of intranets in knowledge man-
agement. Paper presented at the Proceedings of the 35th Annual Hawaii International
Conference on System Sciences, Hawaii.
Stephens, R. T. (2007). Integrating a Data Management Wiki. DM Review, 17(9), 36-36.
Szallies, C. (1998). Software-Spezifikation mit ereignisgesteuerten Prozeßketten (EPK). Soft-

waretechnik Trends, 5, 1998.
Tozer, G. (1999). Metadata Management for information control and business success. Bos-
ton. Artech House.
Vaduva, A., & Dittrich, K. R. (2001). Metadata Management for Data Warehousing: Between
Vision and Reality. Paper presented at the Proceedings of the International Database
Engineering & Applications Symposium.
Vipul, K., Kshitij, S., & Amit, S. (1996). Metadata for building the multimedia patch quilt. In
Multimedia Database Systems: Issues and Research Directions (pp. 297-319). New York:
Springer-Verlag.
Völkel, M., Krötzsch, M., Vrandecic, D., Haller, H., & Studer, R. (2006). Semantic Wikipedia.
Proceedings of the 15th international conference on World Wide Web, 585-594.
von, E., Schelp, J., & Winter, R. (2003). Integrierte Informationslogistik - Stand und Entwick-
lungstendenzen. In von, E., & Winter, R. (Eds.), Data Warehouse Management. Berlin:
Springer.
Wagner, C. (2004). Wiki: A Technology for Conversational Knowledge Management and

Group Collaboration. Communications of the AIS, 13(19). pp. 256-289.
Weidenhaupt, K., Pohl, K., Jarke, M., & Haumer, P. (1998). Scenario Usage in System Devel-
opment: A Report on Current Practice. IEEE Software, 15(2), 34-45.
6.2 Internet
Lerouge, G. (2007, 15. August, 2008). Wikis & Project Management. Retrieved 2008-08-15,
from http://wikibc.blogspot.com/2007/10/wikis-project-management.html
Muse, A. (2007, 21. August). Wiki as alternative to document management and email. Re-
trieved 2008-08-16, from http://architel.com/2007/08/21/wiki-as-alternative-to-
document-management-and-email/
Socialtext. (no date-a). An Informative Intranet and People's Portal. Retrieved 2008-08-15,
from http://www.socialtext.com/customers/case-studies/informative/
Socialtext. (no date-b). Stata Labs: Managing at a Distance, For Less. Retrieved 2008-08-15,
from http://www.socialtext.com/customers/case-studies/stata/
Tan, A. (2007, June). Embrace collaboration tools or fall behind, says expert. Retrieved 2008-
08-16, from http://www.zdnetasia.com/news/software/0,39044164,39234930,00.htm
W3C. (10. February, 2004a). OWL Web Ontology Language Overview. Retrieved 2008-08-19,
from http://www.w3.org/TR/owl-features/
W3C. (10. February, 2004b). RDF Primer. Retrieved 2008-08-19, from

http://www.w3.org/TR/rdf-primer/
Wölfle, R. (2004). ProZoom. Anleitung zur Erstellung von Prozessabbildungen nach der ver-
einfachten erweiterten Ereignisgesteuerten Prozesskette. Retrieved 2008-09-04, from
http://www.prozoom.ch/apps/prozoom.nsf/img/Anleitung-
Modellierung_12/$file/Anleitung-Modellierung_12.pdf
6.3 Corporate and institutional websites
1UP.com www.1up.com
Architel Holdings LLC www.architel.com
Bayer AG www.bayer.com
Bayer CropScience www.bayercropscience.com
Bloomberg L.P. www.bloomberg.com
Dresdner Kleinwort www.dresdnerkleinwort.com
Google Inc. www.google.com
IDS Scheer AG www.ids-scheer.com
Institut für Wirtschaftsinformatik, www.iwi.unisg.ch
University of St. Gallen
Satmetrix Systems, Inc. www.satmetrix.com
Statalabs, Inc. www.statalabs.com
UN Economic Commission for Europe www.unece.org
University of St. Gallen www.unisg.ch
World Wide Web Consortium www.w3.org
Ziff Davis Publishing Holdings Inc. www.ziffdavis.com
IBM www.ibm.com
Chapter 7: Appendices 83
7 Appendices
Appendix I: Summary of applied CommonKADS models
CommonKADS is a methodology developed by several industry-university consortia aiming at
supporting knowledge management and knowledge engineering in small and large organiza-
tions. Although the initial purpose of CommonKADS was to provide practical tools for the
development of knowledge-intensive systems, the ideas, concepts and techniques can nev-
ertheless be successfully applied in a much broader context (Schreiber, 2000, p. ix).
The CommonKADS methodology has several advantages compared to other frameworks for
IS development and engineering. It approaches the initial problem statement and develop-
ment of an IT-artifact not only from a technical side, but also from an organizational and
human perspective. The actual design of the artifact – i.e. programming the software – takes
only a secondary role. Instead, the solution is firstly developed on a highly conceptual level
“independent of specific computational constructs and software implementations” (Schreiber,
2000, pp. 14-17).
Moreover, CommonKADS does not provide a rigid, predefined development concept, but
consists of different modules that can be configured and adjusted to the individual needs
and characteristics of a development project. Therefore, it preserves a reasonable balance
between flexibility on the one hand, and structure on the other hand. The modules can be
categorized into three groups of models: contextual, conceptual and artifact models (Schrei-
ber, 2000, pp. 17-18). To analyze the needs of maintainers and business users at BCS in the
research at hand, three models from the contextual level have been used which will be brief-
ly described in the following (Schreiber, 2000, pp. 18-19):
• Organization Model: The organization model supports the analysis of the major features
of an organization, in order to discover problems and opportunities for knowledge sys-
tems, establish their feasibility, and assess the impacts on the organization of intended
knowledge actions.
• Task Model: Tasks are the relevant subparts of a business process. The task model ana-
lyzes the global task layout, its inputs and outputs, preconditions and performance crite-
ria, as well as needed resources and competences.
• Agent Model: Agents are executors of a task. An agent can be human, an information
system, or any other entity capable of carrying out a task. The agent model describes the
characteristics of agents, in particular their competences, authority to act, and con-
straints in this respect. Furthermore, it lists the communication links between agents in
carrying out a task.
Appendix II: List of interviews and correspondence
Date, Type Purpose Contact Person

21st May, 2008, Expert Interview: Deborah Harms (BCS, Maintainer)
phone interview Evaluation of the MDM HB 2.0
21st May, 2008, Expert Interview: Holger Hinzen (BCS, Business User)
26th May, 2008, Expert Interview: Dirk Krüger (BCS, Maintainer)
30th May, 2008, Expert Interview: Harald Sagner(BCS, Business User)
4th June, 2008, Expert Interview: Bernd Wantke (BCS, Maintainer)
11th July, 2008, Discussion of interview results; Kai Hüner (IWI-HSG);
phone conference coordination for the develop- Heiko Haller (FZI);
ment of the PoC Felix Kugel (FZI)
10th October, 2008, Invitation to participate in the Deborah Harms (BCS, Maintainer);
Email evaluation of the PoC Holger Hinzen (BCS, Business User);
Dirk Krüger (BCS, Maintainer);
Harald Sagner(BCS, Business User);
Bernd Wantke (BCS, Maintainer);
Sabine Neunzig (BCS, Maintainer);
Thomas Derichs (BCS, Maintainer);
Karl-Heinz Weber (BCS, Maintainer);
21st October, 2008, Additional invitations to partici- Greg Castle (BCS, Maintainer);
Email pate in the evaluation of the Frank Jordans (BCS, Maintainer);
PoC Marc Westphal (BCS, Business User)
Appendix III: Interview guideline

The interview guideline is designed based on the three contextual models (organization, task
and agent model) of the CommonKADS framework (see Appendix I). The interview follows
the form of a Semi-structured, individual expert interview. The structure of the interview
consists of three parts:
1. Introductory part. The first part consists of general questions about the interviewee and
his/her interaction with the MDM HB 2.0. The last question in this part identifies all po-
tential tasks and their trigger events that may cause the interviewee to make use of the
handbook.
2. Task-specific part. This part analyzes in detail the whole interaction process of the inter-
viewee with the handbook for each specific task that has been identified in the introduc-
tory part.
3. Materials-specific part. The final part takes a closer look at the functionalities, the user
interface and other elements of the MDM HB 2.0 in the context of the “Materials” data
category the PoC should be built for.
General Questions
G.1 What is your function and what are your responsibilities at BCS?
- Department?
- In what business processes are you involved?
G.2 How have you been introduced to the MDM Handbook?
- Instruction / Training?
- Documentation?
- Informal introduction?
G.3 What did/do you normally do if you don’t know how to use specific parts of the
handbook?
G.4 When or in what situations do you make use of the handbook?
- Specific examples?
- Triggering Events?
- What kind of information are you looking for?
Task-specific Questions (used for each task identified in G.4)

T.1 Regarding TASK 1, can you describe step-by-step how you exactly interact with the
handbook:
- Triggering event
- Search or Navigation
- Usage of the information
- Returning to the normal workflow
T.2 Can you describe the type of knowledge you are looking for in this situations:
- Information about an Object, Process and/or Structure
- Guidelines
- Rules / Restrictions
T.3 What do you think about the quality of the searched information:
- Up-to-date?
- Quality of content?
- Presentation & Form?
T.4 How often do you need to consult the Handbook?
T.5 How often are your searches successful / not successful? What may be the reasons?
T.6 Can you continue with your task / work if the handbook does not deliver the ex-
pected information? What are alternative actions?
T.7 What are the shortcomings of the current handbook that decreases its usability?
- Representation
- Missing information
- Performance
T.8 What should the handbook be able to do, to make you using it more often?
Task-specific Questions (used for each task identified in G.4)

M.1 Is the overall structure clear and self-explaining? Is all the necessary information
displayed?
M.2 Which part of the navigation (left-hand side) do you normally use?
- How often used?
- How used?
- What are you looking for?
- Possible improvements?
M.3 Which elements of the search function do you use?
- How often used?
- How used?
- What are you looking for?
- Possible improvements?
M.4 Let’s go through the different tabs within one field-function element:
- How often used?
- How used?
- For what tasks
- Quality / Shortcomings?
Tabs: “Main Infos”, “Field Description”, “Field Maintenance”, “Harmonization Guide-

lines”, “Business Rules”, “Used for”, “Extras”, “System”, “Update History”
Appendix IV: Interview reports
i. Deborah Harms (BCS, maintainer)

Interview Report, 21st May 2008
Deborah Harms (Maintainer)
Bayer CropScience Pty Ltd
SAP Consultant, SAP Group Region Asia Pacific
391-393 Tooronga Road, East Hawthorn, Vic, 3123, Australia
Phone: +61 3 9248 6886
Mobile: + 61 407 871 249
Deborah.Harms@bayercropscience.com
A. General Information
Deborah Harms is a Key User (SAP Consultant), member of a small team responsible for the
implementation of SAP throughout Bayer CropScience (BCS) companies in Asia Pacific. She
also performs support and training to SAP Users (end-users) who are / will also be using the
Handbook, so her comments covered both the Key User’s and the SAP User’s perspective.
She was introduced to the handbook by email requesting her to fill in content into the hand-
book, but neither received any formal training nor documentation. The lack of formal train-
ing is partially due to the fact, that the handbook is currently used as a tool in the global
harmonization project to enter information and compare the use of the different fields with
the European and American system. Additionally, the locational remoteness (Asian Pacific)
from the HQ may be another reason for the lack of training. If some aspects of the handbook
were not clear, she usually would have directly asked somebody in Germany during her next
business trip, since calling Mr. Gripp was normally not possible due to the time difference.
B. Interaction with the current MDM Handbook

Currently:
She – as a Key User – is using the handbook to enter information for the Asian Pacific Region
and to compare the field use with European and American systems in the context of the
global harmonization project.
SAP Users are not using the handbook.
Future:
Key Users will use the handbook as a link to the DRS Database to ensure global compliance.
It may also be used for training purposes of SAP Users.
SAP Users will use the handbook as a Bayer-specific help guide on the definition of each field
and how it is used, together with limitations on values allowed.
Potential Triggering-Events to interact with the handbook (in the future):

Key User: Configuration of and adding entries into SAP Æ Checking global compliance re-
quirements within the MDM Handbook
SAP User:
• Looking for information about an existing field (e.g., whether he can manually add in-
formation to that field or if it is controlled by global standards)
• During SAP training
• Looking up further usage of a specific field when viewing data in the material master
itself
C. Evaluation of the current MDM Handbook
Quality of Information:
• Information is sometimes only available in German
• Information sometimes not up-to-date or missing
Shortcomings & missing functionalities

• Poor Sort-Function: “Sort-within-sort” is not possible which is very frustrating. E.g., sort-
ing first by “System” and then sorting the results again by “Process” is not possible.
• Poor Search-Function (1): When searching by description, the Handbook comes up with
too many hits without really giving the specific information needed. For Key Users this is
not a big issue, since they know the specific field names, but for normal SAP Users this
might be a problem. E.g., querying for “base unit of measure” in the standard search
field yields almost 40 different hits. The search function should allow quotes like in
Google-search to indicate whether single words or a whole string is searched for.
• Poor Search-Function (2): Searching for a fieldname of a field that has two different
tables, the search yields two entries (e.g., “VOLUM” or “VOLEH”). Key Users may be able
to handle this problem because they understand table structures, but for SAP Users this
might cause some confusion, especially if the two field descriptions do not display the
same information.
Suggestions for additional features / functionalities

• The user should be able to have all relevant information on the first screen and should
not have to collect pieces of information from different tabs. Possible solutions may be
different user interfaces for Key and End Users, or even an individualized and customiza-
ble start page (Drag’n’Drop Æ iGoogle). Regarding the Key Users the relevant informa-
tion would be: “Field Name”, “Description”, “Table”, whether or not DRS controlled.
• Multi-Language support (interface & content). Some information in the handbook is
only available in German which makes it impossible to use for all Asian Pacific (and Amer-
ican) users; and even if the information is available in English there will still be about 50%
of the SAP Users who cannot speak English well enough to make use of the information
(regarding Key Users, they generally speak all English). (Note: Currently, when facing the
problem of only having information for a specific field only available in German, the in-
terviewee uses some internet translation tools and tries to figure out what the meaning
of the German text could be). Since the information for each field is expected to be ra-
ther static, inconsistency between different language versions is not seen as a major is-
sue (as long as the translation is done correctly). The documentation of the handbook it-
self should also be available in different languages. The language of the handbook should
be automatically adjusted to the language used in the SAP system. Currently, the missing
multi-language support is sometimes circumvented by putting translations into the “Ex-
tras”-Tab (see, e.g., “ALTSL”)
• Integration with other Systems (SAP & DRS). Regarding SAP: If the end-user is in SAP
and wants further information about how a specific field is used, it would be of great
benefit if they could not access the standard SAP documentation but could directly
access the relevant descriptions within the MDM Handbook (by using something similar
to the current F1-Help-Function), without having to manually open the handbook and
search for that specific field. Regarding DRS: There should be a direct link to the corres-
ponding information within DRS Database. (E.g. the field name “BKLAS”, there is a docu-
ment link to the DRS. However, it only opens the DRS database and the Key User has to
search again for the corresponding field.).
• Proper documentation of the handbook and its functions. This is especially important
for the Asian Pacific Users, since the time difference makes it almost impossible to call
Gerhard Gripp (as indicated when hitting the “?”-Button”).
D. “Material”-specific Information
Result Field
• The colored dots (traffic lights) are not intuitive and there is no explanation what they
stand for.
Navigation Field
• Generally not used
• The navigation by “Process” is not very useful, since it is not clear what “Process” actual-
ly represents (i.e., it does not correspond with the business processes of the Asian Pacific
region).
Search Field
• Only normal search (no advanced search).
• Further search by sorting the columns by clicking their headers
Within a specific fieldname
Tab Content
Main Infos Used Not used:
- “Field Use” - “Status of document”
- “Description” (important)
- “System”
- “Field Name” (important)- “Transaction” (same for all fieldnames)
- “Table” - “Process”
- “DRS” (important) - „Business Responsible“
- “Check Table” (too technical)
-“Comments for Customizing Settings”
Field Description Important for Key and SAP Users
Field Maintenance Normally used only by Key Users. A direct link to the global guidelines should
be available.
Harmonization Guide- ?
lines
Business Rules ?
Used For Not often used (because often in German)
Extras Not used (circumvention of missing multi-language support)
Systems Not used
Update History Not used
ii. Holger Hinzen (BCS, business user)

Interview Report, 21st May 2008
Holger Hinzen
Bayer CropScience Aktiengesellschaft
BCS AG-IOP-TISS MSS
Monheim, 6230
Phone: +49 2173 38 5858
Mobil: +49 175 3015858
FAX: +49 2173 38 4926
Email: holger.hinzen@bayercropscience.com
Holger Hinzen was formerly a Key User (Maintainer) involved in projects that aimed at filling
in and maintaining content of the MDM Handbook. Currently, he is a SAP User (Business Us-
er) within the “Industrial Operation”-Process responsible for and process owner of the global
engineering system.
He was introduced to the current version of the handbook by a simple link, but did neither
receive any formal training nor documentation. Regarding adding and maintaining data with-
in the handbook, the lack of training/documentation is not a big issue; however, in order to
get a general understanding about the handbook and its functionalities / benefits, training
and documentation should be provided. Currently, asking colleagues or calling Mr. Gripp is
the only way to get missing information about the use of the handbook.

Currently, Holger Hinzen does not use the handbook as a SAP User. During the time as a Key
User, he consulted the handbook in order to get help for the data maintenance of the SAP
system.
The standard procedure to find the searched information was: 1. Opening manually the
handbook in Lotus Notes; 2. Searching by fieldname or navigating by processes (however, he
notes that the “Process”-column of the handbook does not correspond with the actual busi-
ness processes at BCS; they rather represent specific SAP Modules, which can be very con-
fusing especially for SAP Users).
If the search is not successful, missing information is either retrieved from the standard SAP
documentation (by hitting F1 in the SAP System) or informally by team members.
• Information is often not up-to-date or even missing

• The quality of the content varies for different fields
• The information in the “Field Maintenance”-Tab is well documented and useful
• Form & Representation of the information is good

• Poor search function: no full-text queries of the whole database
• The design and structure is too technical for SAP Users. The structure of the handbook
should be aligned with the actual processes of the users.

• Integration with SAP System: Direct access from a specific field within the SAP system to
the relevant information in the handbook should be possible without having to manually
open the handbook and search for the specific information.
• Multi-Language Support: Information should be available in German (not only English).
Suggestion: regional adaptation should be conducted and managed by the respective re-
gional persons in charge (and not centrally).
• Links within the handbook: Regarding e.g. the “Quality Management”-Process, there
should be links to all relevant master data fields allowing drilling up and down within the
book.
• Feedback- /Comment-Functionality: SAP Users should be able to add feedback / com-
ments (e.g., missing or out-of-date information) for the business responsible person.
• User-friendly interface
Starting Page
• “Fieldname” not useful for SAP Users, because it’s too technical
• “Description” & “Process” are useful
Navigation
• Key Users (Maintainer) navigate by “Fieldname”
• SAP Users navigate by “Process”
• All other navigation elements are not relevant (especially “different usage” & “used sys-
tem & iDocs”
Search
• Simple search used
• Advanced search not used (missing training/documentation?)
Within a specific field

Tab Content
Main Infos Used by Key Users Used by SAP Users Not used:
- “Field Use” - “Field Use” - “Status of document”
- “Description” - “Description” - “System”
- “Field Name” - “Field Name” - “Transaction”
- “Process” (Should be - “Process” (Should be - “Check Table”
more described more more described more -“Comments for Custo-
detailed including sub- detailed including mizing Settings”
processes) subprocesses) - “DRS”
- “Table” - “Business Responsi- - Business Responsible:
- “Business Responsible” ble” (should have di- gut (mit direktem link für
(should have direct link) rect link) email)
Field Description Used (Key & SAP User)
Field Maintenance Used (Key User)
Harmonization Used (Key User)
Guidelines
Business Rules Not used
Used For Not used
Extras Not used
Systems Not used
iii. Dirk Krüger (BCS, maintainer)

Interview Report, 26th May 2008
Dirk Krueger
BayerCropScience AG
Alfred-Nobel-Str. 50
Geb.: 5907; R. 1.11; D - 40789 Monheim
Phone: +49 2173 38 5339
Mobile: +49 172 2301462
Dirk.Krueger@bayercropscience.com
Dirk Krueger is involved in Roll-in Projects, i.e. mapping master data from legacy systems to
the current SAP-System. His responsibility is to evaluate together with Key Users the differ-
ent fields within those legacy systems, in order to develop Mapping-Rules for the Master
Data Team.
He was informally introduced to the handbook by a simple link. He neither received formal
training nor documentation, but learned how to use the handbook by “Klicken im Kreis”
(“Clicking-in-the-circle”), i.e. clicking on different elements of the handbook and seeing what
is happening.

Currently, Dirk Krueger is not using the Handbook. However, he mentions that possible trig-
gering events to interact with the handbook could be during a master data mapping-project,
if he (or a Key User) wants to know who maintains and is responsible for a specific field with-
in the SAP-System.
The interaction process could then be described as follows:
1. Open the MDM Handbook in Lotus Notes

2. Navigate / Search by “Fieldname”
3. Check which “System” and Function (i.e. “Process”) the field belongs to
4. Check who is responsible for that field
If the searched information could not be found, he would consult other team members.

• No comments (since he does not use the handbook)

• Dependencies between fields are not displayed: Information for a field does not indicate
whether there are dependencies to other fields. For example, the handbook does not in-
dicate if maintaining data in one field automatically requires maintaining data in another
field.
• Redundant Data Management: All Mapping-Rules which are used in Roll-in Project can
also be found in another database
• Missing documentation about the handbook itself
• Unclear purpose of traffic lights
• Fieldnames are not understandable to many Key Users

• Indication of relations and dependencies between fields: (see above)
• Possibility for individual configurations: Most Key Users have a defined set of fields which
they use very frequently. There should be a possibility to quickly access these fields with
a few clicks.
• Integration with SAP: When using SAP, it should be possible to directly access informa-
tion for a specific field in the handbook – e.g., by clicking on a qualified link –without hav-
ing to search manually for it.
• Integration with DRS: Some main fields may require an application process to be main-
tained. In this case, a direct link to the application form in the DRS Database should be
available. Currently, many fields have a link to the DRS Database, but it only opens the
Database without leading directly to the required application form.
Result Field
• The colored dots (traffic lights) are not intuitive and there is no explanation what they
stand for.
Navigation Field
• By fieldname
• By System
Search Field
• Only normal search
• The existence of an advanced search function was not know (Æ missing documentation)

Tab Content
Main Info Important Not important:
- “Field Use” - “Status”
- “Description” - “Business Responsible” (because there is
- “Field Name” often no one)
- “System” - “Check Table”
- “Transactions”
- “Process”
- “DRS”
- “Comments for Customiz-
ing Settings”
Field Description Important (especially for new Key Users)
Field Maintenance Not important (it is not clear what “field maintenance” means)
Harmonization Guide- important
lines
Business Rules important
Used For Not important (should be included in “Business Rules”)
Extras not important (links should places in the “Main Infos”-Tab
Systems Currently not important , but maybe important in the future
Update History important
iv. Harald Sagner(BCS, business user)

Interview Report, 30th May 2008
Harald Sagner
Bayer CropScience Aktiengesellschaft
Phone: +49 2173 38 5786
Email: harold.sagner@bayercropscience.com
Harald Sagner is business user in the order management department which handles all or-
ders at BCS Monheim. He is responsible for new entries and changes of customer master
data. The customer master data is located on the PMD (Produktivsystem Master Data), whe-
reas the actual data used in operative business is located on another system (PBC: Produk-
tivsystem Bayer CropScience). Therefore, customer master data entries and changes are
made in the PMD and are then transferred to the PBC. However, there are cases where the
PBC is missing some fields and consequently, some master data cannot be transferred from
the PMD.
The MDM Handbook was introduced to Harald Sagner by a newsletter, but he neither re-
ceived formal training nor documentation. However, he says that the lack of training / do-
cumentation was never a real problem. If there really would be an issue with the use of the
handbook, he would contact directly Mr. Gripp or Mr. Brauer.

Currently, Harald Sagner is using the MDM Handbook 2-3 times a month.
The main trigger events to use the handbook are:
• Checking if all fields of the PMD do also exist in the PBC, in order to avoid data loss dur-
ing the master data transfer to the operative system.
• Retrieving information about specific fields if their meaning is unclear.
The interaction process has been described as follows:
1. Opening the Handbook in Lotus Notes

2. Choosing the “Customer”-Section
3. Navigating “by process”
4. Choosing “SD” (Sales & Distribution)
5. Going through all fields until the searched one has been found
• Up-to-date
• Sufficient Form & Representation of information
• Sometimes the fields “Field Maintenance”, “Harmonization Guidelines” and “Business
Rules” are empty. However, this does not represent any problem, because he is not us-
ing these fields.

• Missing documentation
• Unclear purpose of “traffic lights”
• Ambiguous / unclear meaning of some Tab names (e.g. “business rules”)
Æ missing documentation
• Unclear purpose / meaning of some Navigation-elements (e.g. “used systems & IDocs”)

• Formal Introduction / training in a small setting
• Interface & content available in German (nice-to-have feature)
• (The integration with SAP System (direct links) is not necessary)

Result Field
• Clear and useful
Navigation Field
• “Process” should be renamed to “Modules”.
• A reorganization of the fields along the actual business processes is not useful, since
business processes may differ in different countries, which would cause high mainten-
ance efforts and complexity.
Search Field
• Not used

Tab Content
- “Description” - “Field Use”
- “Field Name” - “Status of the Document”
- “Table” - “System”
- “Transactions”
- “Process”
- “Business Responsible” (because there is
often no one)
- “Check Table”
- “DRS”
- “Comments for Customizing Settings”
Field Description used
Field Maintenance Not used
Harmonization Guide- Not used
lines
Business Rules Not used
Used For Not used
Extras used (to check for German translations)
Systems Used (in the context of the harmonization project). May not be used in the
future
v. Bernd Wantke (BCS, maintainer)

Interview Report, 4th June 2008
Bernd Wantke
IT Business Services
PSD-SDfLS
Bayer Business Services GmbH
Gebäude 2975 (Seilerei)
51368 Leverkusen, Deutschland
Tel: +49 214 30 33550
Mobil: +49 175 30 33550
Email: bernd.wantke@bayerbbs.com
Bernd Wantke is Business Consultant at BCS and responsible for Roll-in-Projects, i.e. devel-
oping migration rules in order to migrate data from local systems of different BCS companies
into the global SAP systems. He is also responsible that all fields newly created during the
migration process are documented and described in the MDM Handbook.
He was informally introduced to the handbook by a Lotus Notes document link along the
way during a Roll-in-Project, but has neither received any formal training nor documenta-
tion. He learnt to use the handbook partly by learning-by-doing, partly during occasional
meetings / workshops with the Team of Gerhard Gripp. Despite the lack of formal training /
documentation, he never had problems using the handbook for his purposes.

Bernd Wantke is currently using the handbook once a month, but will use it once a week in
the future (if the usability and functionalities improves as expected). He interacts with the
handbook mainly for three reasons:
1. Checking whether a field needs to be approved by the DRS
2. Applying for a DRS-required field
3. Providing documentation & descriptions for a newly created or changed field
About DRS: DRS stands for “Data & Repository Standards” and is the Handbook of the central
Master Data Server. Whenever a field is created / changed in a local SAP system, one has to
check first, whether that field exists in the central Master Data Server. If it is the case, the
creation / change has to be approved by the DRS responsible person in advance.
The step-by-step interaction process – in the case of a DRS-required field – can be described
as follows:
1. Open MDM handbook

2. Search / Navigate for the specific field
3. Check under “Main Info”>> “DRS” if the Field needs to be approved
4. Check under “Extras” if there is a link to the DRS Handbook, or open it manually (in
either case, the user will start at the main page of the DRS Handbook)
5. Search for the matching field
6. Get email address of the responsible person and application form
7. Fill in the application form and send to the responsible person
8. Receive approval and copy-paste the approved field data into the local SAP system.
• No comment
Shortcomings & missing functionalities:

• Missing introduction / training / documentation

• Integration with SAP System. Documentation about a specific field should be directly
accessible from the SAP System without having to open the Handbook and search for
that specific field manually. Moreover, it would be of great benefit if the creation of a
new field within SAP would trigger a request for the responsible person to provide the
corresponding documentation in the MDM Handbook. In the case a field gets completely
deleted from the SAP system, the corresponding documentation in the MDM Handbook
should also be automatically deleted or archived. As an alternative to the integration
with the operational SAP system, the MDM handbook could also be integrated with the
BW (Business Warehouse) of BCS in order to decrease the load on the operational sys-
tem.
• Integration with DRS (Important!). As mentioned above, some fields require to be ap-
proved by the DRS before they can be created / changed. There should be a direct link
from such a field from the MDM Handbook to the DRS Handbook (same as SAPÆMDM
HB). Most importantly, it should be possible to trigger the application process within the
MDM Handbook by just filling in an application form. The more this whole application
process can be automated (on both sides) the better, since there might be even more
than 30 applications for just a single project. This would decrease errors, speed up and
simplify the workflow and relieve the workload of the Master Data responsible.
• Links between related Fields. Fields occurring within one SAP transaction (e.g. Sales Or-
der) should be linked within the MDM Handbook.
Result Field
• ok
Navigation Field
• “By fieldname”
Search Field
• Simple Search (by fieldnames)

Tab Content
- “Status” - “Business Responsible” (because there is
- “Field Use” often no one)
- “Description” - “System”
- “Field Name” - “Transactions”
- “Table” - “Process”
- “Check Table” - “Comments for Customizing Settings”
- “DRS”
Field Description important
Field Maintenance Important
Harmonization Guide- Not important
lines
Business Rules Not important
Used For Not important
Extras not important
Systems Not important in the future
Update History important
Appendix V: Documents of the PoC user evaluation
i. Task Sheet (business user version)
Page 1
Page 2
Page 3
Page 4
ii. Task Sheet (maintainer version)
Page 1
Page 2
Page 3
Page 4
Page 5
iii. Online survey questions and results
Part 1: Introduction (Maintainer & Business Users: 7 Participants)
1.1 Login
a) Have you experienced any problems with this task?

No: 6
Yes: 1
Experienced Problem: “see below”
1.2 Basic search and navigation in the sidebar
Have you experienced any problems with these tasks?

a) Searching for fieldname “VOLUM”
No: 7
Yes: 0
b) Searching for the field description “base unit of measure”

No: 7
Yes: 0
c) Navigating "by Module"

No: 7
Yes: 0
d) Navigating "by Fieldname"

No: 6
Yes: 1
Experienced Problem: “not easy to find that the second half of the alphabet“
e) How do you rate the search function of the new handbook compared to the MDM HB 2.0?
much better: 1
better: 4
same: 2
worse: 0
much worse: 0
f) How do you rate the navigation function of the new handbook compared to the MDM HB
2.0?
much better: 2
better: 3
same: 2
worse: 0
much worse: 0
1.3 Tab functions

No: 6
Yes: 1
Experienced Problem: “I did not find it quickly, I have to search."
1.4 Following links

No: 7
Yes: 0
1.5 Evaluation of part 1
a) How difficult have been the introductory tasks in part 1 in general?

Very easy: 4
Easy: 3
Normal: 0
Difficult: 0
Very difficult: 0
b) How efficiently did the new handbook support you in solving the tasks of part 1?
Very efficiently: 3
Efficiently: 4
Normal: 0
Inefficiently: 0
Very inefficiently: 0
Part 2a: Scenarios for business users (2 Participants)

2a.1 Navigating and sorting
a) Which fields belong to the SAP module “SD” and are stored in table “MARM”?
• “MEINH, EAN11, BRGEW”
• “brgew,ean11,gewei,meabm,meinh,umren,umrez,voleh“
b) Which field is also used in another SAP module? Indicate the fieldname and the other
module
• “MEINH,BRGEW”
• “brgew,gewei,meinh”
c) Have you experienced any problems with this task?

No: 2
Yes: 0
d) Which of the steps were rather difficult to understand?

Step 1: -
Step 2: -
Step 3: “It tooks a few minutes to understand how to navigate.”
e) How well did the handbook support you for this specific task?
Very poorly: 0
Poorly: 0
Satisfyingly: 0
Well: 2
Very well: 0
f) Other comments
-
2a.2 Reporting a mistake by email

No: 1
Yes: 1
Experienced Problem: “I did not maintain before my preferences.”
b) Which of the steps were rather difficult to understand?

Step 1: -
Step 2: -
Step 3: -
Step 4: -
Step 5: -
c) How well did the handbook support you for this specific task?
Very poorly: 0
Poorly: 0
Satisfyingly: 0
Well: 2
Very well: 0
d) How do you rate the new handbook's procedure to report data quality issues (i.e. mistakes)
compared to the MDM HB 2.0?
much better: 0
better: 1
same: 1
worse: 0
much worse: 0
e) Other comments
• “Will it be possible to see your own "postings" via email to other users? -> monitoring of
"correction tasks", ...”
2a.3 Commenting a potential mistake

No: 1
Yes: 1
Experienced Problem:
“In you user description it was not mentioned that my preferences has to be filled out and
that a return email confirmation is required before executing the sending of emails.”

Step 1: -
Step 2: -
Step 3: -
Step 4: -
Very poorly: 0
Poorly: 0
Satisfyingly: 0
Well: 2
Very well: 0
d) Other comments
• “May I see the "conversation" to my or other entries in this "discussion board"?”
2a.4 End of part 2

Very easy: 0
Easy: 2
Normal: 0
Difficult: 0
Very difficult: 0
Very efficiently: 0
Efficiently: 2
Normal: 0
Inefficiently: 0
Part 2b: Scenarios for maintainers (5 Participants)

2b.1 Creating a new handbook entry

No: 5
Yes: 0

Step 1: -
Step 2: -
Step 3: “how to understand which information which field”
Step 4: -
Step 5: -
Step 6: -
Very poorly: 0
Poorly: 0
Satisfyingly: 1
Well: 2
Very well: 2
d) How do you rate the data entry function of the new handbook compared to the MDM HB
2.0?
much better: 2
better: 1
same: 2
worse: 0
much worse: 0
Comments:
• “I never used MDM HB 2.0 so I can't compare.”
• “never created entries in 2.0”
e) Other comments
• “good improvement”
2b.2 Correcting an error

No: 5
Yes: 0

Step 1: -
Step 2: -
Step 3: -
Very poorly: 0
Poorly: 0
Satisfyingly: 0
Well: 2
Very well: 3
d) How do you rate the new handbook's process to update/correct data compared to the
MDM HB 2.0?
Much better: 1
Better: 2
Same: 2
Worse: 0
Much worse: 0
Comments:
• “I never used MDM HB 2.0 so I can't compare.”
• “never created entries in 2.0”
e) Other comments
• “very easy, well done”
2b.3 Periodical maintenance

No: 3
Yes: 2
Experienced Problem:
• “Neither of the fields that were edited and validated ("DUNETO" and "DVHART") re-
ceived an updated validation date in the "Business Responsible for" section of my user
page, even though I clicked the "Validate" link for both after saving the changes that I
made to them.”
• “I couldn´t find a discussion!”

Step 1: -
Step 2: -
Step 3: -
Step 4: “that I have at first to delete all brackets”
Step 5: -
Very poorly: 0
Poorly: 0
Satisfyingly: 0
Well: 4
Very well: 1
d) Other comments
-
2b.4 End of part 2

Very easy: 0
Easy: 4
Normal: 1
Difficult: 0
Very difficult: 0
Very efficiently: 0
Efficiently: 5
Normal: 0
Inefficiently: 0
Part 3: Overall Evaluation (Maintainer & Business Users: 6 Participants)

3.1 Working with the handbook
a) How efficiently may the handbook support you in your daily business processes?
Very efficiently: 1
Efficiently: 3
Normal: 1
Inefficiently: 0
Comments:
• “I do not currently use a Master Data handbook in my daily business processes, so having
to maintain a Master Data handbook in addition to my current workload would be a loss
in terms of daily business efficiencies.”
• “If we will be able to set the content for FM specific, as discussed with Gerhard Gripp!”
b) Are there some functions missing which you would need for your daily business processes?
No: 5
Yes: 1, “graphical process flow with connections to master data”
c) How often do you expect to use the new handbook?

Never: 1
Very seldom: 0
In some occasions: 3
Often: 2
Very often: 0
Comments:
• “It will be a good possibility for the users to get relevant information to their daily work
for specific data fields and other things related to the MDM things. - The FM-content is
still missing and has to be set specific (see also 3.1a).”
• “every time fro new projects and therefore for mapping rules”
3.2 Usability of the new handbook
a) How difficult is the usage of the new handbook?

Very easy: 1
Easy: 5
Normal: 0
Difficult: 0
Very difficult: 0
Comments:
• “users have to be trained in "WIKI" related things. They should also be animated to post
"corrections" and additional information. I case of the new format (you can see addition-
al information directly!), I think they will do it more often than in the past (MDM 2.0).”
b) How efficiently does the handbook support repetitive tasks?

Very efficiently: 0
Efficiently: 6
Normal: 0
Inefficiently: 0
Comments:
• “tasks regarding data fields and the coherence of these fields by module, by table, ...”
c) How well does the handbook avoid unnecessary input-steps for the user?
Very poorly: 0
Poorly: 0
Ok: 5
Well: 1
Very well: 0
Comments:
• The default" input will come from MDM 2.0. - By this we do have the content of the "old"
way of working. The time line will show, which things are really necessary an which not.
3.3 Ease of use of the new handbook
a) How intuitive is the design of the handbook?

Very intuitive: 0
Intuitive: 6
Ok: 0
Confusing: 0
Very confusing: 0
Comment:
• “in case you like Wikipedia-technic, ... and I do”
b) How long did it take to understand the basic functions of the handbook?
Very short: 1
Short: 5
Normal: 0
Long: 0
Very long: 0
Comments:
• “For users, which are well trained in using "WEB-based" Tools!”
c) Is there an element of the handbook that is counter-intuitive / hard to understand?

No: 5
Yes: 1
Please specify:
• “Which things should I really "select" on my preferences, ... (own profile) [as a must!] to
work well with the Wiki. - Is a signature necessary or not?!”
d) Is there a need for a formal training session?

No: 2
Yes: 4
Please specify:
• “Only if the use of the handbook is mandatory.”
• “for MD people”
• “I see a training as a general need”
• “Depending on the user, we will give authorization to! -> Users at BCS for FM for exam-
ple, have to be trained how to use Wiki!”
e) Is there a need for a manual?

No: 2
Yes: 4
Please specify:
• “"first steps" -> how to maintain "my profile" and a language specific information as your
"4 pages" for this survey (how to run with WIKI?) -> perhaps you may offer the users the
same survey without the "valuation", but a control of success, if they "fill up" some in-
formation as like in step 2.1”
• “I feel yes, new countries will join the central master data server in the next 2,3 years.
The manual should be concentrate on certain information.”
• “basic's would be good”
• “user’s guide”
f) How much did the handbook encourage you to explore new functions?
Very much: 0
Considerably: 4
Ok: 1
Not much: 0
Not at all: 1
3.4 General impressions
a) How do you like the functions of the new handbook compared to the previous version?
Much better: 2
Better: 3
Same: 1
Worse: 0
Much worse: 0
Comments:
• “I never used the previous version so I can't compare.”
• “in former times we have to search in different tools”
• “If we "will" find the content of FM inside ... :-)”
b) How do you like the user interface of the new handbook compared to the previous version?
Much better: 1
Better: 4
Same: 1
Worse: 0
Much worse: 0
Comments:
• “I never used the previous version so I can't compare.”
c) What did you like most about the new handbook?

• “WIKI-Format > linkable to other information (processes!)”
• “The navigation with links.”
• “Informative for newcomers to Master Data.”
• “Keeps it simple”
• “already known screen from Wiki”
• “graphical part”
d) What didn’t you like at all?

• “Simply the task of having to maintain a handbook at all.”
• “at the moment screens are not translated”
• “at the moment "none"”
e) Do you have any suggestions how to further improve the handbook?

• “information for the user, what will happen with comments, emails to business own-
ers, ...”
• “The master data server is renamed since this year from E44 to PMD. It would be great
to have the handbook also in other languages, e.g. ES, PT and DE, as In the next year a
few new countries will roll-in the PMD, where the users are not familiar with English lan-
guage.”
• “No. It is potentially very useful for a large community of key users sharing the same sys-
tem. I am yet to experience this environment so I am unable to comment constructively
on the usefulness of this tool. We don't have anything like this in Australia and Master
Data maintenance is the responsibility of only a few people who are trained for their
specific fields of responsibility.”
• “not yet, maybe after more intensive use”
Declaration of authorship
I hereby declare
• that I have written this thesis without any help from others and without the
use of documents and aids other than those stated above,
• that I have mentioned all used sources and that I have cited them correctly
according to established academic citation rules.
• that I shall not pass on any copies of this thesis to any third parties without
the President's consent, with the exception of fellow students or persons who
have provided me with essential information for this thesis, to whom I may
pass on copies of this thesis after the procedure has been concluded.
Mark Takeshi Egloff

Shanghai, November 11, 2008

MA Stammdatenmanagement Wiki

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MA Stammdatenmanagement Wiki

Uploaded by

Copyright:

Available Formats

University of St.

Applying Semantic Wiki Technology

Referee: Prof. Dr. Hubert Österle

Mark Takeshi Egloff

St. Gallen, November 17th, 2008

Metadata Management, Semantic MediaWiki, MediaWiki, Semantic Wiki, Design Research

Die vorliegende Arbeit demonstriert die Realisierbarkeit eines funktionierenden Metada-

Metadatenmanagement, Semantic MediaWiki, MediaWiki, Semantisches Wiki, Design Re-

4 Evaluation of the IT-artifact ............................................................................ 47

5.5 Managerial implications ............................................................................................ 75

Table 4-3: Scenario A profile (retrieving MD field information in SAP) ................................... 59

1.2 Research objectives and target audience

The contribution to the academic community is to provide a formerly unexplored case of

1.3 Research methodology

Environment Design Research Knowledge Base

People: Build Artifacts: Foundations:

Figure 1-1: Design Research framework

Collaborative Research Program

• IWI-HSG: initiator and coordinator of the CC CDQ

• Research Center for Information Technology in Karlsruhe (FZI): supplier of technical

Applied research guidelines

Table 1-1: Design Research guidelines realized within this thesis3

Guideline Description Chapter

This thesis is part of a collaborative research program aiming at

1.4 Outline of the thesis

Building the IT-Artifact Evalutating the IT-Artifact

As-Is-Analysis of the current Requirements and

Definition of requirements and

Description of the IT-artifact Results Interpretation

Figure 1-2: Structure of the thesis

2 Definition and description of key concepts

2.1.1 Metadata in the corporate context

Table 2-1 illustrates this context dependence:

Table 2-1: Fields of application for metadata (examples)

Context Types (examples) Purposes (examples)

bearing entities” (e.g., books and printed mate-

• Intellectual Property (creator, publisher,

• Identification information (title, geographic • Context specific presentation and querying

area, data set, etc.)

pleteness, consistency, sources, etc.)

• Representation of media types (format, • Storing, organizing and retrieving distributed

• Content description (title, subject, etc.) • Managing algorithms for information

• Customer metadata (name, address, etc.) • Business forecasting

• Product metadata (category, id, etc.) • Business performance measurement

Aspects of corporate metadata

 Technical metadata includes information about operational and analytical systems

Figure 2-1 summarizes the classification of technical/business and structured/unstructured

Logical data model of an

E-Mail from technical support

Infrastructure Model Process Quality Reporting Administration

Figure 2-2: Categorization of metadata

• Functions of Metadata. An important way to categorize corporate metadata is to diffe-

2.1.2 Management of corporate metadata

Discussion and definition

Planning implies anticipating the long-term needs of an organization regarding corporate

Planning, organizing, leading, coordinating and controlling corporate metadata from

Information systems for integrated metadata management

• Import and export functions for metadata

2.2 Wikis in the corporate context

2.2.1 The concept of wikis

2.2.2 Fields of application for corporate wikis

2.3 Semantic wikis in the corporate context

2.3.1 The concept of the Semantic Web

Technical metadata includes information about operational and analytical systems