Bedarfsanalyse fachlicher Metadaten - Universität St.Gallen

Bedarfsanalyse fachlicher Metadaten
DISSERTATION
der Universität St. Gallen,
Hochschule für Wirtschafts-,
Rechts- und Sozialwissenschaften
sowie Internationale Beziehungen (HSG)
zur Erlangung der Würde eines
Doktors der Wirtschaftswissenschaften
vorgelegt von
Daniel Stock
aus
Deutschland
Genehmigt auf Antrag der Herren
Prof. Dr. Robert Winter
und
PD Dr. Joachim Schelp
Dissertation Nr. 3939
Difo-Druck GmbH, Bamberg 2011

Die Universität St. Gallen, Hochschule für Wirtschafts-, Rechts- und Sozialwissenschaften
sowie Internationale Beziehungen (HSG), gestattet hiermit die Drucklegung
der vorliegenden Dissertation, ohne damit zu den darin ausgesprochenen Anschauungen
Stellung zu nehmen.
St. Gallen, den 13. Mai 2011
Der Rektor:
Prof. Dr. Thomas Bieger

Vorwort
i
Vorwort
Eine Promotion ist oft nur ein schmaler Grat zwischen Frust und Glückseligkeit. Daher
bin ich sehr froh um jeden wohlgesinnten Kollegen, jeden langjährigen Freund und
den bedingungslosen Rückhalt aus meiner Familie, die mich auf diesem Wege begleitet
haben. Ohne Eure gesammelte Unterstützung wäre dies so nicht möglich gewesen.
Ich möchte daher diese Möglichkeit ergreifen, mich bei Euch allen zu bedanken und
jedem von Euch, der diesen Tag noch vor sich hat, viel Erfolg zu wünschen.
Von meinen Kollegen am Institut für Wirtschaftsinformatik habe ich das notwendige
Handwerk gelernt und in allen Lebenslagen freundschaftliche Unterstützung erfahren.
Besonderer Dank gilt dabei meinem Doktorvater, Prof. Dr. Robert Winter, der meine
Arbeit über die gesamte Entstehungszeit mit Rat und Tat begleitet hat. Herzlichen
Dank gilt dabei auch PD Dr. Joachim Schelp für die Übernahme des Korreferats und
die wertvollen Hinweise gerade in den frühen Phasen meines Dissertationsprojekts.
Darüber hinaus möchte ich zwei weitere Kollegen herausstellen, die für meine Dissertation
von besonderer Bedeutung waren: Frederik Marx, der neben dem Arbeitsplatz
die Hürden des Alltags mit mir geteilt und gemeistert hat, und Dr. Felix Wortmann,
der aus rein persönlichen Engagement und nicht immer zu seinem Vorteil eine offene
Stelle im Forscherteam geschlossen hat. Beide waren mir über die Zeit erste Anlaufpunkte,
Mentoren und Freunde.
Allen anderen Kollegen und Freunden aus St. Gallen danke ich für eine besondere Zeit
an und neben der Universität: Prof. Dr. Stephan Aier, Dr. Antonia Albani, Dr. Lars
Baake, Dr. Oliver Baecker, Alain Benz, Andre Blondiau, Dr. Tobias Bucher, Anne
Cleven, Dr. Barbara Dinter, Marion Fässler, Clarissa Falge, Dr. Martin Fengler, Christian
Fischer, Rebecca Fitterer, Dr. Rene Fitterer, Dr. Wojciech Ganczarksi, Sandro
Georgi, Dr. Anke Gerike, Bettina Gleichauf, Philipp Gubler, Andreas Györy, Kai Hüner,
Dr. Till Janner, Gerrit Lahrmann, Linda Lower, Bernadette Mayer, Dr. Tobias
Mettler, Dr. Jochen Müller, Martin Ofner, Felix Peter (stellvertretend für Brühlhof,
Downtown, Trischli und Elektrokeller), David Raber, Andreas Reichert, Dr. Felix
Reinshagen, Dr. Christian Riege, Dr. Peter Rohner, Dr. Jan Saat, Ernst Sassen, Dr.
Moritz Schmaltz, Dr. Christoph Schroth und Inga Zilles.
Bei meinen Freunden aus Karlsruhe möchte ich mich für die gelegentliche Ablenkung
abseits des akademischen Alltags bedanken. Stellvertretend seien hierbei zu nennen:

ii
Vorwort
Serif Erol, Michael Hammermeister, Klaas Koolman, Alexander Schult und die Burschenschaft
Hoheneberstein.
Mein grösster persönlicher Dank gilt meinen Eltern Angelika und Dr. Udo Stock, meiner
Schwester Nina Stock und meiner Freundin Mara Wetzel. Sie haben mich seit jeher
uneingeschränkt unterstützt und jegliche erdenkliche Hilfe zukommen lassen. Ihnen
sei diese Arbeit daher von ganzem Herzen gewidmet.
Berlin, 4. Juni 2011
Daniel Stock

Beiträge der Arbeit
iii
Beiträge der Arbeit
Beitrag A.1: Stock, Daniel; Wortmann, Felix; Mayer, Jörg H.: Use Cases for Business
Metadata – A Viewpoint-Based Approach to Structuring and Prioritizing Business
Needs. In: Winter, Robert; Zhao, J. Leon; Aier, Stephan (Hrsg.): Proceedings of 5th
International Conference on Design Science Research in Information Systems and
Technology, St. Gallen 2010, S. 546-549.
Beitrag A.2: Stock, Daniel; Wortmann, Felix; Mayer, Jörg H.: Use Cases for Business
Metadata – A Viewpoint-Based Approach to Structuring and Prioritizing Business
Needs. In: Abramowicz, W.; Tolksdorf, R.; Węcel, K. (Hrsg.): Proceedings of International
Conference on Business Information Systems, Berlin 2010, S. 226-237.
Beitrag B: Stock, Daniel; Gubler, Philipp: A Data Model for Terminology Management
of Analytical Information. In: Albano, Valentina; Mola, Lapo; D’Atri, Alessandro
(Hrsg.): Proceedings of European Students Workshop on Information Systems
2009, Verona 2009, S. 1-14.
Beitrag C.1: Stock, Daniel; Mayer, Jörg H.; Wortmann, Felix: Fachliche Metadaten:
Kosten-Nutzen-Analyse. In: BI-Spektrum 5 (2010) 2, S. 20-24.
Beitrag C.2: Stock, Daniel; Winter, Robert: The Value of Business Metadata – Structuring
the Benefits in a Business Intelligence Context. In: D’Atri, A. et al. (Hrsg.):
Proceedings of VII Conference of the Italian Chapter of AIS, Neapel 2010, S. 1-8.
Beitrag D: Stock, Daniel: Functional Map for Business Metadata Tools. Arbeitsbericht,
Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen 2010.
Beitrag E 1 : Stock, Daniel; Winter, Robert; Mayer, Jörg H.: User Preferences in MSS
Design – State of the Art and Proposal of a Research Agenda. Arbeitsbericht, Institut
für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen 2010.
Beitrag F: Mayer, Jörg H.; Stock, Daniel: Nutzertypen für die situative FIS-
Gestaltung: Ergebnisse einer empirischen Untersuchung. Zu erscheinen in: Proceedings
of 10th International Conference on Wirtschaftsinformatik, Zurich 2011, S. 1-10.
1 Die Forschungsergebnisse aus Beitrag E sind Gegenstand weiterer Publikationsprojekte.

iv
Beiträge der Arbeit
Beitrag G 2 : Stock, Daniel; Mayer, Jörg H.; Winter, Robert: End-user Device Selection
for Executives – Adapting Executive Information Systems to Different Working
Styles. Arbeitsbericht, Institut für Wirtschaftsinformatik, Universität St. Gallen,
St. Gallen 2010.
2 Eingereicht bei der 19th International Conference on Information Systems (ECIS 2011), Helsinki.

Inhaltsverzeichnis
v
Inhaltsverzeichnis
Vorwort ........................................................................................................................... i
Beiträge der Arbeit ...................................................................................................... iii
Inhaltsverzeichnis .......................................................................................................... v
Abkürzungsverzeichnis ............................................................................................... xi
Abbildungsverzeichnis .............................................................................................. xiii
Tabellenverzeichnis ..................................................................................................... xv
Kurzfassung .............................................................................................................. xvii
Abstract .................................................................................................................... xviii
1 Einleitung ................................................................................................................. 1
1.1 Motivation ...................................................................................................... 1
1.2 Gegenstand der Arbeit .................................................................................... 4
1.3 Forschungsmethodik ...................................................................................... 6
1.4 Aufbau der Dissertation .................................................................................. 7
2 Grundlagen .............................................................................................................. 9
2.1 Fachliche Metadaten ....................................................................................... 9
2.2 Metadatenmanagementsysteme .................................................................... 11
2.3 Bedarfsanalyse in der IS-Entwicklung ......................................................... 12
2.4 Anforderungen im IS-Design ....................................................................... 16
2.4.1 Anforderungsmanagement ....................................................................... 16
2.4.2 Enterprise Engineering ............................................................................. 18
3 Bestehende Ansätze ............................................................................................... 20
3.1 Auswahl verwandter Ansätze ....................................................................... 20
3.2 Analyse der Literatur zu fachlichen Metadaten ........................................... 20
3.3 Analyse der Literatur zu Metadaten im Allgemeinen .................................. 22
3.4 Analyse der Literatur zu Bedarfsanalyse im Allgemeinen ........................... 25
3.5 Implikationen und Bezugsrahmen für die Dissertation ................................ 26

vi
Inhaltsverzeichnis
4 Beiträge der Arbeit ............................................................................................... 30
4.1 Überblick und Einordnung im Informationsmodell ..................................... 30
4.2 Einordnung im Vorgehensmodell ................................................................ 35
4.3 Einordnung im Rollenmodell ....................................................................... 38
4.4 Formale Anmerkungen ................................................................................. 40
5 Zusammenfassung, Diskussion und weiterer Forschungsbedarf ..................... 42
5.1 Zusammenfassung der Dissertation ............................................................. 42
5.2 Diskussion der Forschungsergebnisse ......................................................... 43
5.3 Weiterer Forschungsbedarf .......................................................................... 45
6 Beitrag A.1: Use Cases for Business Metadata – A Viewpoint-Based
Approach to Structuring and Prioritizing Business Needs ............................... 48
6.1 Motivation .................................................................................................... 48
6.2 Conceptual Foundations ............................................................................... 49
6.2.1 Business Metadata .................................................................................... 49
6.2.2 Viewpoint-Oriented Requirements Analysis ........................................... 49
6.3 Derivation of Use Cases for Business Metadata .......................................... 50
6.4 Demonstration and Evaluation ..................................................................... 51
6.5 Concluding Remarks .................................................................................... 52
7 Beitrag A.2: Use Cases for Business Metadata – A Viewpoint-Based
Approach to Structuring and Prioritizing Business Needs ............................... 53
7.1 Introduction .................................................................................................. 53
7.1.1 Motivation and Objectives ....................................................................... 53
7.1.2 Research Methodology and Article Structure .......................................... 55
7.2 Conceptual Foundations ............................................................................... 56
7.2.1 Business Metadata .................................................................................... 56
7.2.2 Viewpoint-Oriented Requirements Analysis ........................................... 57
7.3 Derivation of Use Cases for Business Metadata .......................................... 58
7.3.1 Use Cases in the Data Consumer Domain ............................................... 59

Inhaltsverzeichnis
vii
7.3.2 Use Cases in the Data Manager Domain .................................................. 59
7.3.3 Use Cases in the Data Producer Domain ................................................. 60
7.4 Demonstration and Evaluation ..................................................................... 61
7.4.1 Initial situation .......................................................................................... 61
7.4.2 Use Case Approach to Business Metadata Systems Design .................... 62
7.4.3 Evaluation of Design and Utility .............................................................. 64
7.5 Concluding Remarks .................................................................................... 65
8 Beitrag B: A Data Model for Terminology Management of Analytical
Information ............................................................................................................ 66
8.1 Introduction .................................................................................................. 66
8.1.1 Motivation ................................................................................................ 66
8.1.2 Research Methodology ............................................................................. 67
8.2 Theoretical Foundations ............................................................................... 68
8.2.1 Data Consistency ...................................................................................... 68
8.2.2 Terminological Defects and Terminology Management ......................... 69
8.3 Development of an Extension of a Terminological Data Model ................. 70
8.3.1 Existing Terminological Data Models ..................................................... 70
8.3.2 Proposed Adaptation within AIS Context ................................................ 73
8.4 Discussion and Further Research ................................................................. 75
9 Beitrag C.1: Fachliche Metadaten – Kosten-Nutzen-Analyse .......................... 77
9.1 Einleitung ..................................................................................................... 77
9.2 Stand in Wissenschaft und Praxis ................................................................ 78
9.3 Systematische Beurteilung ........................................................................... 78
9.3.1 Datenkonsumenten ................................................................................... 80
9.3.2 Datenmanager ........................................................................................... 80
9.3.3 Datenproduzenten ..................................................................................... 81
9.4 Beispiel: Umsetzung im Kreditrisikomanagement ...................................... 81
9.5 Zusammenfassung ........................................................................................ 83

viii
Inhaltsverzeichnis
10 Beitrag C.2: The Value of Business Metadata – Structuring the Benefits in a
Business Intelligence Context .............................................................................. 84
10.1 Introduction .................................................................................................. 84
10.1.1 Motivation and Objectives ....................................................................... 84
10.1.2 Research Methodology ............................................................................. 85
10.2 Business Metadata ........................................................................................ 85
10.3 Derivation of Benefit Dimensions ............................................................... 86
10.3.1 Development and Administration of BI-Systems .................................... 87
10.3.2 Extraction of Information from BI-Systems ............................................ 88
10.4 Application within Credit Risk Management .............................................. 89
10.4.1 Initial Situation ......................................................................................... 89
10.4.2 Business Case for Central Business Glossary .......................................... 90
10.5 Discussion and Conclusion .......................................................................... 91
11 Beitrag D: Functional Map for Business Metadata Tools ................................ 92
11.1 Introduction .................................................................................................. 92
11.1.1 Motivation and Objectives ....................................................................... 92
11.1.2 Research Methodology ............................................................................. 93
11.2 Business Metadata ........................................................................................ 94
11.3 Functional Map ............................................................................................ 96
11.3.1 Definition/Sourcing Functionality ........................................................... 96
11.3.2 Integration Functionality .......................................................................... 97
11.3.3 Presentation Functionality ........................................................................ 98
11.4 Demonstration in Practice ............................................................................ 99
11.4.1 Initial situation ......................................................................................... 99
11.4.2 Functional Map in Business/IT Alignment .............................................. 99
11.4.3 Takeaways from Single-Case Evaluation .............................................. 100
11.5 Concluding Remarks .................................................................................. 101

Inhaltsverzeichnis
ix
12 Beitrag E: User Preferences in MSS Design – State of the Art and Proposal of
a Research Agenda .............................................................................................. 102
12.1 Introduction ................................................................................................ 102
12.2 Structuring Requirements for Management Support Systems Design ....... 104
12.2.1 Requirements Engineering ..................................................................... 104
12.2.2 Enterprise Engineering ........................................................................... 105
12.2.3 Classification Scheme ............................................................................ 107
12.3 Literature Analysis ..................................................................................... 109
12.3.1 Source Selection ..................................................................................... 109
12.3.2 Literature Systemization ......................................................................... 112
12.3.3 Discussion .............................................................................................. 119
12.4 Summary of Findings ................................................................................. 120
13 Beitrag F: Nutzertypen für die situative FIS-Gestaltung: Ergebnisse einer
empirischen Untersuchung ................................................................................ 121
13.1 Einführung .................................................................................................. 121
13.2 Grundlagen ................................................................................................. 124
13.2.1 Situative IS-Gestaltung ........................................................................... 124
13.2.2 Bestehende Ansätze in der FIS-Gestaltung ............................................ 124
13.3 Empirische Untersuchung .......................................................................... 127
13.4 Auswertung ................................................................................................ 128
13.4.1 Einstiegsniveau ....................................................................................... 129
13.4.2 Nutzungsbereitschaft .............................................................................. 130
13.4.3 Geschäftsorientierung ............................................................................. 130
13.4.4 Analyseorientierung ............................................................................... 131
13.5 Nutzertypen ................................................................................................ 131
13.5.1 Analyseorientierte Vielnutzer ................................................................ 131
13.5.2 Indifferente Wenignutzer ....................................................................... 133
13.6 Implikationen .............................................................................................. 135

x
Inhaltsverzeichnis
13.6.1 Situative Gestaltungsempfehlungen ....................................................... 135
13.6.2 Reflexion des Forschungsprozesses ....................................................... 140
13.7 Zusammenfassung und Ausblick ............................................................... 141
13.8 Anhang ....................................................................................................... 141
13.8.1 Elemente des Fragebogens ..................................................................... 141
13.8.2 Eignung für die Faktorenanalyse ........................................................... 142
13.8.3 Bestimmung der Faktorenanzahl ........................................................... 143
13.8.4 Dendogramm .......................................................................................... 144
14 Beitrag G: End-User Device Selection for Executives – Adapting Executive
Information Systems to Different Working Styles .......................................... 145
14.1 Motivation .................................................................................................. 146
14.2 Related Work ............................................................................................. 148
14.3 End-user devices ........................................................................................ 149
14.4 Configuration Model .................................................................................. 150
14.4.1 Hypothesis-driven Design ...................................................................... 151
14.4.2 Model Justification ................................................................................. 153
14.5 Application in Practice ............................................................................... 157
14.6 Summary and Final Remarks ..................................................................... 159
Literatur ..................................................................................................................... 161
Lebenslauf des Autors ............................................................................................... 182
Publikationsverzeichnis des Autors ......................................................................... 183
Hinweis zur Verwendung geschlechtsneutraler Formulierungen ........................ 185

Abkürzungsverzeichnis
xi
Abkürzungsverzeichnis
AIS
AM
API
BI
BIS
BM
CC
CORE
COTS
DAMA
Desrist
DMBOK
DSS
ECIS
EE
EIS
ESWIS
ETL
FTE
HICSS
HSG
IFPUG
ILOG
IS
ISO
Analytische Informationssysteme
Anforderungsmanagement
Application Programming Interface
Business Intelligence
Business Information Systems (Konferenz)
Business Metadata
Competence Center
Controlled Requirements Expression
Commercial Off-the-Shelf
Data Management Association
Design Science Research in Information Systems and Technology
(Konferenz)
Data Management Book of Knowledge
Decision Support Systems
European Conference on Information Systems
Enterprise Engineering
Executive Information Systems
European Students Workshop on Information Systems
Extract-Transform-Load
Full-Time Equivalence
Hawaii International Conference on Systems Sciences
Hochschule St. Gallen
International Function Point User Group
Informationslogistik (Konferenz)
Informationssystem
International Organization for Standardization

xii
Abkürzungsverzeichnis
ISR
IT
itAIS
IWI
KMS
KOFRAH
KPI
LSE
MBTI
MDM
MDMS
MIS
MSS
PMBOK
PMI
RE
ROI
SAC
SME
SQL
USS
VAT
VORD
WI
Information Systems Research
Information Technology
The Italian Association for Information Systems (Konferenz)
Institut für Wirtschaftsinformatik
Knowledge Management Systems
Konferenz der Gleichstellungs- und Frauenbeauftragten an
Schweizer Universitäten und Hochschulen
Key Performance Indicator
London School of Economics
Myers-Briggs Type Indicator
Metadatenmanagement
Metadatenmanagementsystem
Management Information Systems
Management Support Systems
Project Management Book of Knowledge
Project Management Institute
Requirements Engineering
Return on Investment
Situational Artifact Construction
Situational Method Engineering
Standard Query Language
Unternehmenssteuerungssysteme
Value Added Tax
Viewpoint-Oriented Requirements Definition
Wirtschaftsinformatik

Abbildungsverzeichnis
xiii
Abbildungsverzeichnis
Abb. 1: Metadatentaxonomie ...................................................................................... 10
Abb. 2: Vorgehensmodell für die Bedarfsanalyse fachlicher Metadaten .................... 16
Abb. 3: Taxonomie für Anforderungen ....................................................................... 18
Abb. 4: Informationsmodell der Bedarfsanalyse ......................................................... 27
Abb. 5: Informationsmodell der Bedarfsanalyse – Spezialisierung auf Systemnutzer
........................................................................................................................ 28
Abb. 6: Einordnung der inhaltlichen Bausteine im Bezugsrahmen ............................ 32
Abb. 7: Zuordnung der Beiträge zu den inhaltlichen Bausteinen und dem zugrunde
liegenden Forschungsprozess ......................................................................... 33
Abb. 8: Vorgehensmodell Bedarfsanalyse unter Einbindung der Ergebnisse der
Beiträge ........................................................................................................... 37
Abb. 9: Generische RACI-Matrix in der Bedarfsanalyse ............................................ 39
Abb. 10: Ressourcenüberblick für die Bedarfsanalyse .................................................. 40
Abb. 11: Viewpoint-oriented requirements definition approach [Kotonya, Sommerville
1998] ............................................................................................................... 49
Abb. 12: Framework of use cases for business metadata .............................................. 51
Abb. 13: Viewpoint-oriented requirements definition approach [Kotonya, Sommerville
1998] ............................................................................................................... 58
Abb. 14: Classification of use cases for business metadata .......................................... 61
Abb. 15: EUB’s prioritization of use cases for business metadata ................................ 62
Abb. 16: Swiss Re data model in UML [Wegener, Auth 2002] .................................... 72
Abb. 17: Adapted data model in UML .......................................................................... 74
Abb. 18: Qualitative und quantitative Nutzendimensionen .......................................... 79
Abb. 19: Auszug Nutzwertanalyse im Kreditrisikomanagement .................................. 82
Abb. 20: Quantifizierung der Nutzenpotenziale eines zentralen Glossars (Zahlen
verfremdet) ..................................................................................................... 83
Abb. 21: Qualitative and quantitative benefits of BM .................................................. 89

xiv
Abbildungsverzeichnis
Abb. 22: Pre-assessment of improvement potential by introducing a business glossary
........................................................................................................................ 90
Abb. 23: Business case for introducing a business glossary at EUFSP ........................ 91
Abb. 24: Overview of business metadata tool functionalities ....................................... 99
Abb. 25: Screen shots for usage dashboard, quality dashboard, encyclopedia, and
process map .................................................................................................. 100
Abb. 26: Requirements taxonomy ............................................................................... 106
Abb. 27: Classification scheme ................................................................................... 108
Abb. 28: Results of literature analysis ......................................................................... 118
Abb. 29: Entwicklungsstand der situativen Artefaktgestaltung von
Unternehmenssteuerungssystemen ............................................................... 125
Abb. 30: Einordnung von Nutzertypen im Spannungsfeld idealtypischer
Ausprägungen ............................................................................................... 134
Abb. 31: Screeplot ....................................................................................................... 144
Abb. 32: Dendogramm ................................................................................................ 144
Abb. 33: Results of literature analysis ......................................................................... 148
Abb. 34: End-user devices taxonomy .......................................................................... 150
Abb. 35: Preferred end-user devices by user type, use case, and access mode........... 153
Abb. 36: Aggregated results from questionnaire......................................................... 155
Abb. 37: Final model design ....................................................................................... 156

Tabellenverzeichnis
xv
Tabellenverzeichnis
Tab. 1: Forschungsprozess ............................................................................................ 7
Tab. 2: Übersicht Bestandteile einer Projektvereinbarung ......................................... 14
Tab. 3: Übersicht Literaturanalyse zu fachlichen Metadaten ..................................... 21
Tab. 4: Übersicht Literaturanalyse zu Metadaten im Allgemeinen ............................ 23
Tab. 5: Übersicht Forschungsrichtungen zu Bedarfsanalyse im Allgemeinen ........... 25
Tab. 6: Zusammenfassung Beiträge der Dissertation ................................................. 42
Tab. 7: Bibliografische Angaben zu Beitrag A.1 ........................................................ 48
Tab. 8: Requirements per activity in use case “data development” (excerpt) ............ 51
Tab. 9: Bibliografische Angaben zu Beitrag A.2 ........................................................ 53
Tab. 10: DAMA DMBOK business responsibilities [DAMA 2009] ........................... 60
Tab. 11: Business metadata requirements per activity in use case “data development”
........................................................................................................................ 63
Tab. 12: Statements of focus group on design and utility ............................................ 64
Tab. 13: Bibliografische Angaben zu Beitrag B ........................................................... 66
Tab. 14: Attributes of a term in the Swiss Re data model ............................................ 71
Tab. 15: User view of a defined term (example) .......................................................... 75
Tab. 16: Bibliografische Angaben zu Beitrag C.1 ........................................................ 77
Tab. 17: Taxonomie ...................................................................................................... 78
Tab. 18: Bibliografische Angaben zu Beitrag C.2 ........................................................ 84
Tab. 19: Bibliografische Angaben zu Beitrag D ........................................................... 92
Tab. 20: Bibliografische Angaben zu Beitrag E ......................................................... 102
Tab. 21: Relevant articles for literature analysis ........................................................ 110
Tab. 22: Bibliografische Angaben zu Beitrag F ......................................................... 121
Tab. 23: Rotierte Komponentenmatrix ....................................................................... 129
Tab. 24: Zwei-Cluster- und Vier-Cluster-Modell von Nutzertypen für
Unternehmenssteuerungssysteme ................................................................. 132

xvi
Tabellenverzeichnis
Tab. 25: Komponenten situativer Artefaktgestaltung ................................................. 138
Tab. 26: KMO- und Bartlett-Test ............................................................................... 142
Tab. 27: Anti-Image-Kovarianz-Matrix (Absolutwerte) ............................................ 143
Tab. 28: Bibliografische Angaben zu Beitrag G ........................................................ 145
Tab. 29: Mode and median responses from hypotheses testing ................................. 154

Kurzfassung
xvii
Kurzfassung
Mit Blick auf den immer stärker werdenden Wettbewerb ist es für Firmen essenziell,
Informationen im Unternehmen zu generieren und bereitzustellen. Mit dem Einzug
von Informationstechnologie (IT) ist inzwischen eine regelrechte Informationsflut zu
beobachten, die es dem Einzelnen immer schwerer macht die für ihn relevanten Informationen
zu identifizieren und zu bewerten. Hier setzen fachliche Metadaten als „Daten
über Daten“ an, um als Zusatzinformationen die Datenqualität aus Anwendersicht
zu erhöhen.
Auch wenn in der Praxis die Bedeutung fachlicher Metadaten zunehmend anerkannt
wird, liegt die tatsächliche Umsetzung in den Unternehmen aufgrund der fehlenden
Unterstützung auf der Fachseite teilweise noch weit zurück. Diese Problematik ist
zwar nicht neu, dennoch hält die Literatur hier wenig konkrete Lösungsansätze parat,
um diesem Umstand entgegenzuwirken. An dieser Stelle setzt die vorliegende Dissertation
an. In einem gestaltungsorientierten Ansatz entstehen generische Modelle, die
Empfehlungen zu den Ergebnissen einer Bedarfsanalyse formulieren. Diese Dissertation
ist dabei kumulativ angelegt, sodass in der Regel jeder der hierin vorgestellten Einzelbeiträge
einen gestaltungsorientierten Zyklus (insb. Design und Evaluation) durchläuft.
Die dabei entwickelten Modelle ergänzen damit die in der Literatur vorwiegend diskutierte
Aktivitätensicht auf eine Bedarfsanalyse, die ausschließlich das Vorgehen bei
der Identifikation, Validierung und Spezifikation des Handlungsbedarfs beschreibt. Im
Einzelnen werden daher eine Übersicht auf die elf Anwendungsgebiete von fachlichen
Metadaten, eine Zusammenstellung von qualitativen und quantitativen Nutzendimensionen
sowie eine implementierungsunabhängige Funktionssicht der am Markt zur
Verfügung stehenden (fachlichen) Metadaten-Tools vorgestellt. Daneben werden vier
Nutzertypen und ein Modell zur situativen Auswahl von Endgeräten vorgestellt, um
bei der Definition von Anforderungen an eine Metadatenmanagementlösung (MDM-
Lösung) Präferenzen der Systemnutzer zu berücksichtigen, die für den Erfolg bei der
Einführung von fachlichen Metadaten entscheidend seien können.
Stichwörter: Business Intelligence, fachliche Metadaten, Bedarfsanalyse

xviii
Abstract
Abstract
In respect of the increasing competition, it becomes more and more essential for companies
to generate and share information internally. Today, in the course of advancements
in information technology (IT), an information overflow is overservable, which
makes it harder for the individual to identify the relevant information. Therefore, it
becomes more and more important to supply purposeful and high-quality information.
At this point, business metadata as “data about data” increases the data quality from a
user perspective in terms of transparency.
Despite its increasing relevance to practitioners, the implementation of business metadata
in companies still lacks behind its predicted utility because the required support
from the business side is missing. Although these challenges are well known and correspond
to the experiences in other fields, concrete solutions in literature remain rare.
This constitutes the problem statement for the dissertation at hand. In a design science
approach, generic models are developed, which constitute recommendations on the
results of a demand analysis. Since this dissertation is designed in a cumulative fashion,
each of the herein presented articles generally pass through a design science
cycle (esp. design and evaluation).
The developed models complement an activity based view of demand analysis, which
is primarily discussed in literature. This activity based view solely describes the procedure
for identifying, validating, and specifying business need. Therefore, an overview
over the eleven application domains for business metadata, a framework of qualitative
and quantitative benefit dimensions, as well as an implementation independent
functional map for commercial off-the-shelf (COTS) business metadata solutions are
presented. In addition to this, this dissertation introduces four user types and a model
for end-user device selection in order to account for the preferences of users, which
can be crucial for the success of rolling out business metadata.
Keywords: business intelligence, business metadata, demand analysis

Einleitung 1
1 Einleitung
In diesem Kapitel wird die vorliegende Dissertation hinsichtlich ihrer Zielsetzung
skizziert. Abschnitt 1.1 legt die Motivation für die hierin präsentierte Forschungsarbeit
dar. Anschließend wird der Gegenstand der Arbeit in Abschnitt 1.2 vorgestellt und in
Abschnitt 1.3 die Forschungsmethodik erläutert. Das Kapitel schließt mit Abschnitt
1.4, der den Aufbau der Dissertation darlegt.
1.1 Motivation
In der Ressourcentheorie gilt firmeninternes Wissen als ein wesentlicher Faktor, um
sich gegenüber anderen Teilnehmern am Markt zu differenzieren [Pfeffer, Salancik
2003: 258-262; Ulrich, Barney 1984: 472; Wernerfelt 1984: 172-175]. Dabei wird
Wissen von verschiedenen Wissenschaftlern sogar als das zentrale Element bei der
Erlangung von Wettbewerbsvorteilen postuliert [z. B. Grant 1996; Spender 1996].
Wissen entsteht dabei durch die kognitive Verarbeitung von Informationen. Wissen
wird seinerseits wieder zu Informationen, wenn es in vermittelbarer Form (z. B. als
Text, Grafik oder Tabelle) ausformuliert wird [Alavi, Leidner 2001: 3]. 3 Diese Beziehung
impliziert, dass es für Firmen essenziell ist, Informationen zu generieren und bereitzustellen.
Einerseits, um Wissen im Unternehmen zu vermitteln, und andererseits,
um die Entwicklung neuen Wissens voranzutreiben.
Mit dem Einzug von Informationstechnologie (IT), ist in den Unternehmen der Zugang
zu Informationen immer leichter geworden. Es ist sogar eine Informationsflut zu beobachten,
die es dem Einzelnen immer schwerer macht, die für ihn relevanten Informationen
zu identifizieren [Edmunds, Morris 2000: 18-19]. Auch wenn diese Problematik
bereits seit Längerem bekannt ist, hat die Herausforderung „making better use of information“
erst in den letzten Jahren deutlich an Bedeutung gewonnen. Aktuell stellt
sie eine der Top-5-Prioritäten von IT-Führungskräften dar [Luftman, Kempaiah, Rigoni
2009: 151-152]. Diese Entwicklung zeigt sich auch in der zunehmenden Verlagerung
von Business Intelligence (BI) als rein technologische Lösung hin zu strategischen
und fachlichen Konzepten [Gluchowski, Kemper 2006: 14; Kemper, Pedell
3 Diese Darstellung nimmt Abstand von einer rein hierarchischen Abgrenzung der Begriffe Daten, Informationen
und Wissen [z. B. Ackoff 1989]. Es wird der Entstehungsprozess des Wissens betont. So hat Tuomi [1999: 111-
112] gezeigt, dass die oft zitierte Hierarchie in der Praxis eher invers zu beobachten ist, da es zunächst Wissen
benötigt, um relevante Informationen zu formulieren beziehungsweise Daten zu definieren, die sich zu Informationen
zusammensetzen lassen.

2 Einleitung
2008: 8; Pettey, Stevens 2010: 1-2; Raskino, Lopez 2008: 6-8]. Somit steht zunehmend
die zielgerichtete und angemessene Bereitstellung von Informationen im Vordergrund.
In diesem Zusammenhang spielt das Thema Datenqualität 4 eine herausragende Rolle
[Capgemini 2008: 30-31; Kemper, Pedell 2008: 7; Luftman, Kempaiah, Rigoni 2009:
155], da sie sich im besonderen Maße auf den wahrgenommen Nutzen von BI-
Systemen durch den Anwender auswirkt [Sabherwal, Jeyaraj, Chowa 2006: 1857-
1859; Schmaltz 2009: 102-110; Wixom, Watson 2001: 34]. Beurteilt ein Anwender
die Qualität der Datenbasis eines BI-Systems als ungenügend, wird sich dies daher
unmittelbar auf seine Bereitschaft auswirken, diese Systeme einzusetzen.
Bei der Beurteilung der Datenqualität spielen allerdings nicht allein objektiv messbare
Dimensionen wie Genauigkeit oder Vollständigkeit von Informationen eine Rolle.
Gleichermaßen stehen subjektiv wahrgenommene Dimensionen wie Glaubwürdigkeit,
Verständlichkeit und Auffindbarkeit von Informationen im Vordergrund [Jarke et al.
2000: 139; Wang 1998: 60; Wang, Strong 1996: 18-21]. Die Wahrnehmung ist dabei
wesentlich schwieriger zu bewerten und kontrollieren. Insbesondere hier setzen fachliche
Metadaten als „Daten über Daten“ an, um als Zusatzinformationen die Datenqualität
aus Anwendersicht zu erhöhen [Bucher, Wlk 2008: 75-78; Foshay 2005: 17-19;
Foshay, Mukherjee, Taylor 2007: 74-76].
Auch wenn in der Praxis die Bedeutung fachlicher Metadaten zunehmend anerkannt
wird, so liegt die tatsächliche Umsetzung in den Unternehmen teilweise noch weit zurück
[Schulze et al. 2009: 57-58, 68-69]. Dies liegt häufig daran, dass Metadatenprojekte
im Allgemeinen sehr stark auf bestimmte Technologien abzielen und ihnen
eine klare Ausrichtung am Bedarf auf der Fachseite fehlt [Koegler 2010; Marco 2000:
115-121; Melchert 2006: 66-70; Triano 2002: 1-4]. In Folge übersteigen die Kosten
schnell den erwarteten Nutzen, sodass diese Projekte letztendlich eingestellt werden
[Melchert 2006: 57-58]. Diese Problematik verschärft sich speziell für fachliche Metadaten
[Dinter 2002: 180-181; Inmon, O'Neil, Fryman 2008: 275]. Zum einen werden
fachliche Metadaten im Gegensatz zu technischen Metadaten noch nicht hinreichend
mit Blick auf ihren Nutzen und dessen Realisierung verstanden. Zum anderen sind
Metadatenprojekte häufig in der IT-Organisation verankert, die sich vor allem für
technische Metadaten interessiert. Dementsprechend richten sich auch die Tool-
4 Entgegen der Unterscheidung von Daten und Informationen in der Systemtheorie werden in dieser Arbeit die
Begriffe Daten- und Informationsqualität synonym verwendet, da sich der Begriff der Datenqualität landläufig
etabliert hat und anschlussfähig ist.

Einleitung 3
Vendoren hierauf aus. Deshalb werden Konzepte benötigt, die eine bedarfsgerechte
Bereitstellung von fachlichen Metadaten in den Unternehmen unterstützen.
Die Literatur adressiert diese Problematik nur unzureichend. Die wenigen veröffentlichten
Methoden zur Entwicklung und Einführung von Metadatenmanagementsystemen
(MDMS) [Marco 2000: 83-322; Melchert 2006: 135-305; Tannenbaum
2002: 257-347] setzen zu spät an, da sie bereits von angenommenen Projektanträgen
ausgehen. Eine Annahme, die – wie bereits dargestellt – bei vielen Problemen in der
Praxis zu kurz greift. Obwohl in der Regel die Finanzierungsproblematik von MDMS
angesprochen und die Wichtigkeit eines zielgerichteten Ansatzes für den Projekterfolg
hervorgehoben wird, fehlt es hier an konkreter Hilfestellung (Abschnitt 3.3).
Ähnlich verhält es sich mit Beiträgen, die den Nutzen von fachlichen Metadaten diskutieren.
Sie beschränken sich hauptsächlich auf den Nachweis einzelner, abstrakter Ursache-Wirkungs-Beziehungen.
5 Diese sind für sich allein jedoch ungeeignet, um die
Durchführung eines Projekts zu rechtfertigen. Es fehlen eine umfassende Betrachtung
der Nutzenpotenziale von fachlichen Metadaten und eine entsprechende Systematik
für deren Bewertung, um diese in der Praxis im Rahmen einer Kosten-Nutzen-Analyse
zur Anwendung zu bringen (Abschnitt 3.2).
Zusammenfassend lässt sich feststellen, dass viele Metadateninitiativen als IT-
Innovationen starten und ihnen die notwendige Unterstützung auf der Fachseite (insb.
durch Sponsoren) fehlt, um ein entsprechendes Projekt aufzusetzen bzw. dieses zum
Erfolg zu führen. In vielen Fällen fehlt der Leidensdruck im Tagesgeschäft oder die
Aussicht auf kurzfristig messbaren Projekterfolg. Auch wenn diese Problematik nicht
neu ist und sich mit den Erfahrungen aus anderen Bereichen deckt, 6 hält die Literatur
hier wenig konkrete Lösungsansätze parat, um diesem Umstand entgegenzuwirken. An
dieser Stelle setzt die vorliegende Dissertation an. Auf Basis von Einzelbeiträgen entstehen
Modelle, welche kumulativ die Bedarfsanalyse für die Bereitstellung fachlicher
Metadaten in Unternehmen unterstützten. Im Fokus stehen dabei die Identifikation,
Validierung und Priorisierung des Handlungsbedarfs in der Vorbereitungsphase eines
Projekts zur Entwicklung und Weiterentwicklung eines MDMS.
5 Z. B. darauf dass Qualitätsinformationen Entscheidungen beeinflussen können [Chengalur-Smith, Ballou, Pazer
1999: 177-181; Fisher, Chengalur-Smith, Ballou 2003: 860-864].
6 Z. B. für die Rechtfertigung von BI-Projekten vgl. Winter und Jung [2002] und McKnight [1999].

4 Einleitung
1.2 Gegenstand der Arbeit
Wie im vorherigen Abschnitt kurz dargestellt und es in Kapitel 3 noch ausführlich diskutiert
wird, adressieren die existierenden Ansätze zur Entwicklung und Weiterentwicklung
von MDMS nur Teilaspekte einer umfassenden Bedarfsanalyse und bleiben
in ihren Ausführungen sehr generisch und abstrakt. Aus dieser Problemstellung lässt
sich die Notwendigkeit nach Forschungsbedarf für die Bedarfsanalyse fachlicher Metadaten
ableiten, welche den Gegenstand der Dissertation darstellt.
Im Allgemeinen betrachtet eine Bedarfsanalyse Bedürfnisse und die zu ihrer Befriedigung
zur Verfügung stehenden, knappen finanziellen Ressourcen. Auch wenn dieser
Begriff in der Wirtschaftsinformatik kaum verbreitet ist und zum Teil synonym zum
Anforderungsmanagement (AM) verwendet wird, ist er hiervon klar abzugrenzen (Abschnitt
2.3). Im Gegensatz zum AM findet die Bedarfsanalyse im Vorfeld eines Projekts
statt und trägt zur Projektentscheidung bei. Während Anforderungen hier nur auf
einem sehr abstrakten Niveau diskutiert werden, steht die ökomische Sinnhaftigkeit
des Projekts im Vordergrund.
Eine Unterstützung der Bedarfsanalyse in der Praxis lässt sich aus Forscherperspektive
vor allem über generische Methoden und Modelle erreichen, da diese im Gegensatz zu
spezifischen Lösungen auf mehrere Problemklassen anwendbar sind [Winter, Gericke,
Bucher 2009: 8]. Während Methoden in erster Linie Aktivitäten zur Zielerreichung
beschreiben, stellen Modelle Empfehlungen zu den Ergebnissen auf. Sie stellen damit
unterschiedliche Sichtweisen auf eine Problemstellung dar, die sich im Kern ergänzen
[Winter, Gericke, Bucher 2009: 9]. In der Literatur ist insbesondere die Aktivitätensicht
auf die Bedarfsanalyse beleuchtet worden, während es weiterhin an Modellen
fehlt, um die Praxis bei der Durchführung zu unterstützen (Kapitel 3). Daher steht in
der vorliegenden Dissertation die Ergebnissicht im Vordergrund.
Sofern sich ein Projekt im Zuge der Bedarfsanalyse als ökomisch sinnvoll erweist,
setzt die Bedarfsanalyse damit den Rahmen für das anschließende Projekt. Die Ergebnisse
der Bedarfsanalyse fachlicher Metadaten werden dabei in Form einer Projektvereinbarung
festgehalten, die folgende Elemente aufweist (Abschnitt 2.3):
• Problemstellung/Handlungsbedarf: Wer sind die potenziellen Stakeholder im
Unternehmen und welche ihrer Probleme lassen sich mit fachlichen Metadaten
lösen

Einleitung 5
• (Ökonomische) Rechtfertigung des Projekts: Welche Nutzenpotenziale können
den Kosten im Rahmen einer Kosten-Nutzen-Analyse gegenübergestellt werden
• Sponsoren: Wer aus dem Kreise der Stakeholder stellt das Budget für ein Projekt
zur Einführung fachlicher Metadaten bereit
• Projektumfang/Zielsetzung: Welche Anforderungen muss ein MDMS-Tool zur
Pflege und Bereitstellung fachlicher Metadaten erfüllen
Neben diesen allgemeinen Fragestellungen wird in der vorliegenden Dissertation der
Systemnutzer gesondert betrachtet. Wie in Abschnitt 1.1 dargelegt, scheitern fachliche
Metadateninitiativen häufig an der Unterstützung durch die Fachseite. Dem Systemnutzer
kommt hierbei eine besondere Rolle zu, da sich erst durch seine Anwendung
entscheidet, ob sich der erwartete Nutzen aus dem MDMS realisiert oder nicht. Dies
ist vor allem hier der Fall, da der Einsatz des MDMS unverbindlich ist und nicht organisatorisch
gewährleistet werden kann. Aus diesem Grund und nach dem Vorbild der
Akzeptanzforschung [z. B. Davis 1989; Schmaltz 2009; Venkatesh, Davis 2000; Venkatesh
et al. 2003] werden der Systemnutzer und dessen Präferenzen im Rahmen der
Bedarfsanalyse gesondert betrachtet.
Zusammenfassend lässt sich die Zielsetzung der Dissertation folgendermaßen formulieren:
Ziel ist die Entwicklung von Modellen, die die Bedarfsanalyse fachlicher Metadaten
hinsichtlich der Identifikation, Validierung und Spezifikation des Handlungsbedarfs
unterstützen. Hinsichtlich der Spezifikation des Handlungsbedarfs sind die Präferenzen
des Systemnutzers zu berücksichtigen. Hieraus lassen sich folgende Forschungsfragen
ableiten, die kumulativ im Rahmen des Forschungsschwerpunkts Unternehmenssteuerungssysteme
(USS) am IWI-HSG adressiert wurden:
FI: In welchen Domänen/Arbeitsbereichen finden sich die potenziellen Stakeholder
und Sponsoren für fachliche Metadaten
FII: Welche direkten und indirekten Nutzenpotenziale haben fachliche Metadaten
bei Betrieb und Nutzung von BI
FIII: Welche Funktionen stellen COTS-Produkte 7 am Markt zur Bereitstellung
fachlicher Metadaten zur Verfügung
7 „Commercial off-the-shelf“-Produkte (COTS-Produkte) bezeichnen kommerzielle Standardsoftware, die nur
bedingt an die individuellen Bedürfnisse der Kunden angepasst werden kann. Lösungen, die primär auf Individualprogrammierung
basieren, sind daher hiervon ausgeschlossen.

6 Einleitung
FIV: Welchen Einfluss haben die Präferenzen der MDMS-Nutzenden auf die Systementwicklung
und -weiterentwicklung
Um diese Teilziele zu erfüllen, wurden primär beschreibende, aber dennoch strukturierende
Modelle als Lösungsbausteine gestaltet. Diese ermöglichen eine systematische
Beantwortung der Forschungsfragen (z. B. ein Ordnungsrahmen für direkte und indirekte
Nutzenpotenziale von fachlichen Metadaten). Diese Lösungsbausteine werden
im Detail in Abschnitt 4.1 vorgestellt. In den Abschnitten 4.2 und 4.3 werden die einzelnen
Lösungsbausteine integriert, um die aktivitätenorientierte Sicht mit der ergebnisorientierten
Sicht auf die Bedarfsanalyse zu vereinen.
1.3 Forschungsmethodik
In der Wirtschaftsinformatik bzw. in ihrem anglo-amerikanischen Pendant „Information
Systems Research (ISR)“ werden zwei fundamentale Forschungsparadigmen unterschieden
[Peffers et al. 2007: 46-47; Winter 2008: 470]: die verhaltensorientierte Forschung
(Behavioral Research), welche auf Wahrheit durch Exploration und Validierung
von generischen Ursache-Wirkung-Beziehungen abzielt, und die gestaltungsorientierte
Forschung (Design Research), die auf Nützlichkeit durch Konstruktion und
Evaluation von generischen Mittel-Zweck-Beziehungen abzielt, das heißt Gestaltung
von generischen Artefakten (z. B. Modelle, Methoden, Konstrukte, Instanzen) zur Lösung
relevanter Probleme [Hevner, Chatterjee 2010; Hevner et al. 2004; March, Smith
1995; Peffers et al. 2007]. Das Dissertationsvorhaben ist primär dem gestaltungsorientierten
Paradigma zuzuordnen, da es die Gestaltung und Evaluation von Modellen zur
Unterstützung der Bedarfsanalyse fachlicher Metadaten verfolgt.
Im Lichte der anhaltenden Diskussion um Stringenz (rigor vs. relevance) in der gestaltungsorientierten
Wirtschaftsinformatik [Winter et al. 2007: 403] wurde eine Vielzahl
von Forschungsprozessmodellen vorgeschlagen [March, Smith 1995: 254, 258; Peffers
et al. 2007: 52-56; Vaishnavi, Kuechler 2007: 46-50]. Die Dissertation folgt dabei den
Empfehlungen in Peffers et al. [2007: 54], welches die aktuellste Arbeit zu dieser
Thematik darstellt und sieben bestehende Modelle zusammenführt.
Der Prozess gliedert sich hiernach in sechs Phasen, die im Kern das Zwei-Phasen-
Modell von March and Smith [1995: 254, 258] umschließen (siehe Tab. 1). Als wesentlicher
Unterschied zwischen den beiden Modellen lässt sich festhalten, dass Peffers
et al. [2007: 54] die Problemidentifikation und die damit verbundene Zielsetzung
explizit adressieren. March and Smith [1995: 253] adressieren diese Punkte nur impli-

Einleitung 7
zit, indem sie in der Phase „Build“ von nützlichen Problemstellungen ausgehen, die
einer menschlichen Zielsetzung dienen.
Da es sich in der vorliegenden Arbeit um eine kumulative Dissertation handelt, folgt in
der Regel jeder einzelne Beitrag dem angesprochenen Strukturierungsansatz von Peffers
et al. [2007: 54]. In Ausnahmefällen wurde aufgrund des Zielpublikums (Praktikerpublikationen)
oder des Umfangs des Beitrags auf die Explizierung der Forschungsmethode
verzichtet bzw. dem einfacheren Modell von March und Smith
[1995: 254, 258] den Vorzug gegeben.
Phase Inhalt [Peffers et al. 2007: 54] [March, Smith 1995:
254, 258]
1 Identifikation einer Forschungslücke
2 Zielsetzung für Lösung
ableiten
Problem identification
and motivation
Objectives of a solution
Implizit adressiert
3 Lösungskonstruktion Design and development Build
4 Demonstration der Wirksamkeit
des Artefakts
Demonstration
Evaluate
5 Evaluation Evaluation
6 Veröffentlichung der
Ergebnisse
Communication -
1.4 Aufbau der Dissertation
Tab. 1: Forschungsprozess
Die vorliegende Dissertation ist wie folgt aufgebaut: Zunächst werden in Kapitel 2
begriffliche Grundlagen zu fachlichen Metadaten, Anforderungsmanagement und Bedarfsanalyse
gelegt. Ziel hierbei ist es, ein einheitliches Verständnis der zentralen Begriffe
in der Dissertation zu schaffen. Kapitel 3 stellt verwandte Ansätze zur Bedarfsanalyse
fachlicher Metadaten vor. Die dort identifizierten Lücken in der Bedarfsanalyse
bilden die Grundlage für die vorliegende Dissertation. Die Dissertation setzt sich
aus verschiedenen Beiträgen zusammen, die in Kapitel 4 überblicksartig vorgestellt
und in Beziehung zueinander gesetzt werden. Kapitel 5 fasst die Dissertation zusammen,
diskutiert die Forschungsergebnisse und stellt Anknüpfungspunkte für die zu-

8 Einleitung
künftige Forschung dar. Im Anschluss folgen in den Kapiteln 6 bis 14 Abdrucke der
Beiträge, die im Rahmen der kumulativen Dissertation einbezogen wurden.

Grundlagen 9
2 Grundlagen
In diesem Kapitel werden die begrifflichen und konzeptionellen Grundlagen für das
Dissertationsvorhaben eingeführt. Fachliche Metadaten und MDMS bilden den grundlegenden
Untersuchungsgegenstand dieser Arbeit und werden in den Abschnitten 2.1
und 2.2 diskutiert. Im Anschluss wird der Fokus auf Bedarfsanalyse und Anforderungen
in der Entwicklung von IS gelegt. Dies erfolgt in den Abschnitten 2.3 und 2.4.
2.1 Fachliche Metadaten
Auch wenn die Literatur eine Vielzahl an Definitionen für Metadaten bereitstellt [z. B.
Dempsey, Heery 1998: 149; Even, Shankaranarayanan, Watts 2006: 1; National Information
Standards Organization 2004: 1; Tannenbaum 2002: 90-91], hat sich das
generelle Verständnis von Metadaten als „Daten über Daten“ landläufig durchgesetzt.
Da diese Definition die Bandbreite von Metadaten nur sehr unscharf abgrenzt, folgt
die vorliegende Arbeit der Definition von Dempsey und Heery [1998: 149]: „Metadata
is data associated with objects which relieves their potential users of having full advance
knowledge of their existence or characteristics“. Diese Definition umfasst alle
Daten, die (abhängig vom jeweiligen Kontext) dazu dienen, materielle oder immaterielle
Objekte zu erfassen und zu beschreiben (z. B. die Kartei in einer Bücherei oder
die logische Datenstruktur einer Datenbank). Im Rahmen der BI beziehen sich Metadaten
insbesondere auf einzelne Daten, Reports und BI-Systeme. Dabei unterscheiden
sie sich von abgeleiteten und aggregierten Daten, wie deskriptiven Statistiken (z. B.
Mittelwert oder Varianz) und KPIs (z. B. Umsatzerlöse oder Ergebnis vor Steuern),
die wiederum in sich abgeschlossene Daten darstellen und nicht darauf abzielen, die
originären Daten zu strukturieren und zu beschreiben.
In der Literatur wird in der Regel zwischen technischen und fachlichen Metadaten unterschieden,
je nachdem, ob sie durch die IT- oder die Fachseite genutzt werden [Marco
2000: 4-5; Shankaranarayanan, Even 2006; Stedman 1999: 74; Vaduva, Vetterli
2001: 276-277]. Hierbei ist zu beachten, dass diese Differenzierung nicht notwendigerweise
trennscharf ist, da bestimmte Metadaten durchaus die Informationsbedarfe
beider Zielgruppen adressieren können (z. B. Definitionen oder Indexe). Dies gilt auch
für einen weiteren Differenzierungsansatz, der informatorische und operative Metadaten
unterscheidet [Shankaranarayanan, Even 2004: 251-252; Tozer 1999: 9-10; Vaduva,
Vetterli 2001: 277-278]. Erstere fördern das Verständnis und den Zugriff auf die
Daten, während Letztere als Input für die Entwicklung und den Betrieb der BI-

10 Grundlagen
Systeme dienen. Abb. 1 fasst diese Taxonomie für Metadaten zusammen und gibt für
die verschiedenen Klassen typische Beispiele aus der Praxis.
Abb. 1: Metadatentaxonomie
Der Fokus dieser Arbeit liegt auf den fachlichen Metadaten, die sich in der englischsprachigen
Literatur unter den Synonymen „business metadata“ [z. B. Marco
2000: 4-5; Shankaranarayanan, Even 2004: 251-252], „end-user metadata“ [z. B. Foshay
2005: 2-3; Foshay, Mukherjee, Taylor 2007: 72-73] und „semantic metadata“ [z.
B. Benander et al. 2000: 77-78; Müller, Stöhr, Rahm 1999: 2] finden lassen. Entlang
des adressierten Informationsbedarfs lassen sich aus der Literatur und Praxis sieben
Kategorien von Metadaten identifizieren [Foshay 2005: 2-3; Foshay, Mukherjee, Taylor
2007: 72-73; Müller, Stöhr, Rahm 1999: 2-4; National Information Standards Organization
2004: 1; Niland, Rouse, Stahl 2006: 410; Shankaranarayanan, Even 2004:
252-254; Shankaranarayanan, Even 2006: 90; Vaduva, Vetterli 2001: 277-278; Xie et
al. 2008: 4-8]:
1. Definitorische Metadaten – Welche Daten habe ich und was bedeuten diese
2. Datenqualitätsmetadaten – Haben die Daten eine ausreichende Datenqualität für
ihre angedachte Verwendung
3. Navigatorische Metadaten – Wo finde ich die Daten, die ich suche, und existieren
weitere Daten, die für mich nützlich sein könnten

Grundlagen 11
4. Prozessmetadaten – Aus welchen Quellsystemen kommen diese Daten und
welche Transformationsschritte haben diese durchlaufen
5. Nutzungsmetadaten – Welche Daten und Reports werden regelmäßig abgerufen
und welche Nutzerprofile lassen sich ableiten
6. Auditmetadaten – Wer ist für die Daten und Reports verantwortlich und wer hat
Zugriffsrechte auf diese
7. Annotationen (Kommentare und Dateiverknüpfungen) – Welche zusätzlichen
Informationen müssen für eine bestimmte Daten- oder Reportinstanz berücksichtigt
werden
Es sollte darauf hingewiesen werden, dass die siebte Kategorie „Annotationen“ in der
Literatur bisher keine explizite Erwähnung findet. Jedoch existieren am Markt und in
den Unternehmen zunehmend BI-Tools, die es ermöglichen, Reports mit Kommentaren
und Dateien zu verknüpfen. 8 Da auch diese vorwiegend qualitativen Informationen
als erklärende Zusatzinformationen zu den Daten und Reports in den BI-Systemen
gewertet werden dürfen, müssen sie entsprechend berücksichtigt werden.
2.2 Metadatenmanagementsysteme
Metadatenmanagement (MDM) umfasst alle Prozesse, welche in geeigneter Form die
Erfassung, Speicherung, Integration und Kontrolle der Metadaten mit Blick auf ihre
Nutzung sicherstellen [DAMA 2009: 259]. MDM übernimmt damit die Rolle eines
Bindeglieds zwischen den Prozessen der Metadatenentstehung und den Prozessen der
Metadatennutzung [Melchert 2006: 40]. Als zentrales Element des MDM wird dabei in
der Literatur das Metadaten-Repository gesehen [Marco 2000: 47; Shankaranarayanan,
Even 2004: 250; Vaduva, Vetterli 2001: 278]. Das Metadaten-Repository ist im engeren
Sinne eine zentrale Datenbank, in welcher die Metadaten abgelegt sind [Melchert
2006: 41; Shankaranarayanan, Even 2004: 250]. Neben einer zentralen Datenbank sind
aber auch weitere Funktionen und Softwarekomponenten notwendig, um beispielsweise
Metadaten automatisch und manuell zu erfassen, in ein konsolidiertes Datenmodell
zu integrieren, zu verwalten und über entsprechende Schnittstellen zur Nutzung bereitzustellen.
Für die Gesamtheit aller Funktionen und Softwarekomponenten, die das
MDM unterstützen, hat sich in der Literatur bisher keine allgemein akzeptierte Bezeichnung
etabliert. Während einige Autoren neue Begrifflichkeiten einführen, wie
beispielsweise Managed Metadata Environment [Marco, Jennings 2004: 3-5] oder Metadata
Solution [Tannenbaum 2002: 157-158], verwenden andere den Begriff des Me-
8 Hier ist als COTS-Produkt z. B. SAP Streamworks zu nennen.

12 Grundlagen
tadaten-Repository in einer erweiterten Form [Sen 2004: 153-155; Vaduva, Vetterli
2001: 278-281].
Diese Arbeit folgt dem Vorschlag und Begriffsverständnis von Melchert [2006: 41-42]
und spricht im Weiteren von MDMS – zum einen, um damit die Trennung zwischen
Funktionalitäten und realisierenden Tools zu erreichen, und zum anderen, um zwischen
dem Informationssystem und den aufsetzenden Prozessen zu unterscheiden.
Ein MDMS dient der informationstechnischen Unterstützung der Prozesse des Metadatenmanagements.
Es umfasst alle Datenstrukturen und Softwarekomponenten, die
erforderlich sind, um Metadaten zu integrieren, zu verwalten, zu pflegen, für Zwecke
der Metadatennutzung aufzubereiten und adressatengerecht bereitzustellen sowie um
die Aktivitäten des Metadatenmanagements zu überwachen und zu koordinieren. Zusammen
mit den unterstützten MDM-Prozessen bildet das MDMS eine MDM-Lösung.
2.3 Bedarfsanalyse in der IS-Entwicklung
In den Wirtschaftswissenschaften ist Bedarf definiert als ein tatsächlicher oder wahrgenommener
Mangel, dem durch den Einsatz finanzieller Mittel begegnet wird [Gabler
2010: 342; Pollert, Kirchner, Polzin 2001: 12; Schubert, Klein 2006: 36]. Damit ist
Bedarf von Bedürfnissen, die nicht durch finanzielle Ressourcen beschränkt sind
[Maslow 1999], und von Nachfrage, die die marktwirksame Kaufentscheidung zu einem
Bedarf voraussetzt, zu unterscheiden [Gabler 2010; Pollert, Kirchner, Polzin
2001; Schubert, Klein 2006].
Allgemein beschäftigt sich die Bedarfsanalyse (aus Sicht eines potenziell Kaufenden)
gesamthaft mit den vorhandenen Bedürfnissen und den zur ihrer Befriedigung zur Verfügung
stehenden, knappen finanziellen Resourcen. In der Wirtschaftsinformatik ist
der Begriff der Bedarfsanalyse kaum verbreitet und wird wenn eher als Teil des oder
synonym zum AM (Abschnitt 2.4.1) verwendet [z. B. Frie, Strauch 2001; Kuhlen,
Seeger, Strauch 2004; Robertson, Robertson 2006; Winter, Strauch 2004]. Auch wenn
hier Parallelen existieren, lassen sich klare Unterschiede feststellen. Einerseits finden
Bedarfsanalyse und AM zu unterschiedlichen Zeitpunkten statt. Die Bedarfsanalyse
erfolgt im Vorfeld der eigentlichen Investitionsentscheidung, während die Erhebung,
Prüfung und Dokumentation der Anforderungen eine Projektphase in der Realisierung
(nach der Investitionsentscheidung) beschreibt [Project Management Institute 2004].
Andererseits unterscheidet sich der inhaltliche Fokus. Die Bedarfsanalyse hat, den Erkenntnissen
aus dem Projektmanagement nach, zum Ziel, eine Investitionsentscheidung
vorzubereiten, die insbesondere den Projektumfang auf Basis einer Kosten-

Grundlagen 13
Nutzen-Betrachtung vorsieht und im Rahmen einer Projektvereinbarung (Project Charter)
festgeschrieben wird [Hayes 2000: 17-22; Koroknay 1993: 546; Project Management
Institute 2004: 81-82]. Hier werden zwar auch Anforderungen definiert, diese
haben jedoch mehr den Charakter von strategischen Zielen. Das AM dokumentiert –
ähnlich dem Bereich Enterprise Ontology aus dem Enterprise Engineering (EE) – wesentlich
detaillierter und widerspruchsfrei Funktionen, die durch ein System realisiert
werden sollen (Abschnitt 2.4.1). Eine Kosten-Nutzen-Analyse kann zwar auch hier
noch erfolgen, spielt aber im Vergleich eine nachgelagerte Rolle, da die eigentliche
Investitionsentscheidung bereits erfolgt ist.
Aus diesen Gründen wird in dieser Arbeit die strikte Trennung von Bedarfsanalyse
und AM propagiert. Als Ergebnis gibt die Bedarfsanalyse (bei einer positiven Investitionsentscheidung)
die wesentlichen Eckpunkte eines entsprechenden Projekts in Form
einer Projektvereinbarung (Project Charter) vor [Hayes 2000: 17-22; Koroknay 1993:
546; Project Management Institute 2004: 81-82]: Problemstellung/Handlungsbedarf,
(ökonomische) Rechtfertigung des Projekts (auf Basis einer Kosten-Nutzen-Analyse),
Sponsoren und Projektumfang/Zielsetzung (Tab. 2).
Der Vollständigkeit halber sei erwähnt, dass eine umfassende Projektvereinbarung
auch einen Grobentwurf zur Projektplanung beinhaltet, welcher unter anderem das
Projektteam und Meilensteine im Vorgehen spezifiziert (Punkt 5, Tab. 2). Dieser Aspekt
bleibt jedoch unter dem Fokus auf die Bedarfsanalyse unberücksichtigt. Zum einen
erklärt die Projektplanung nicht, warum und mit welcher Zielsetzung ein Projekt
durchgeführt werden soll. Sie ist damit weniger Teil der Bedarfsanalyse und kann bereits
zur operativen Projektdurchführung gezählt werden. Zum anderen kann ein Projekt
zwar auch an der Projektplanung (fehlende Ressourcen, Abhängigkeiten zu anderen
Projekten etc.) scheitern, dies ist dann aber nicht Ausdruck für fehlenden Bedarf.
Daher werden die Elemente der Projektplanung in den folgenden Ausführungen nicht
weiter betrachtet.
Ein Vorgehensmodell zur Bedarfsanalyse fachlicher Metadaten muss daher – wie eben
ausgeführt – den Handlungsbedarf identifizieren, die Projektdurchführung in Form
einer Kosten-Nutzen-Analyse ökonomisch rechtfertigen, einen Sponsor bereitstellen
und schlussendlich den Projektumfang definieren. Diese vier Elemente können als
aufeinander aufbauende Phasen interpretiert werden und werden im Folgenden näher
spezifiziert.

14 Grundlagen
# Inhalt [Hayes 2000: 17-
22]
[Koroknay 1993:
546]
[Project Management
Institute
2004: 81-82]
1 Problemstellung/
Opportunity
Business problem
Business need
Handlungsbedarf
statement
Stakeholder
2 (Ökonomische)
Project justification
Cost/benefit
Project purpose or
Rechtfertigung des
analysis
justification
Projekts
Business case
(including ROI)
3 Sponsor Project charter
acceptance
- Sponsor
4 Projektumfang/
Zielsetzung
Project scope User needs Requirements
Project objectives -
Constraints and assumptions
Fit with the IT
strategic plan
Assumptions
Constraints
5 Initiale Projektplanung
Project approach - Summary milestone
schedule
Project organization
Assigned project
manager and authority
level
Impact statement -
Tab. 2: Übersicht Bestandteile einer Projektvereinbarung
Für die Identifikation von Handlungsbedarf ist es notwendig, die relevanten Stakeholder
eines MDMS im Unternehmen zu identifizieren und ihre besonderen Interessen
(Concerns) [Bayer 2004: 35; IEEE 2000: 3-4] zu verstehen, aus denen sich Informationsbedarfe
an fachlichen Metadaten ableiten. Diese Concerns implizieren Informationsbedarfe,
die in Form von modularen Viewpoints modelliert werden [Finkelstein et
al. 1992: 6-10; Kotonya, Sommerville 1992: 376; Kotonya, Sommerville 1998: 150-

Grundlagen 15
151]. Damit untergliedert sich die Identifikation des Handlungsbedarfs in drei Teile:
Identifikation potenzieller Stakeholder (mit Problemstellungen hinsichtlich der Informationsversorgung
im Unternehmen), Analyse des Handlungsbedarfs (zur Identifikation
von Concerns, die fachliche Metadaten erfordern) und Skizzierung des Bedarfs an
fachlichen Metadaten (in Form von Viewpoints).
Für die Rechtfertigung der Projektdurchführung in Form einer Kosten-Nutzen-Analyse
müssen Nutzenpotenziale und Kosten gegenübergestellt werden [Boardman et al.
2008]. Die Berechnung des Return on Investment (ROI) setzt dabei eine Quantifizierung
dieser beiden Teile voraus. Während dies für die einmaligen und laufenden Kosten
in der Regel einfach möglich ist, können Nutzenpotenziale aus Zusatzinformationen
oft nur schwer in Kosteneinsparungen oder Ertragssteigerungen ausgedrückt werden.
Für die Bewertung des Nutzwerts ist daher ein zweistufiges Vorgehen sinnvoll,
das zunächst mit einer qualitativen Bewertung [vgl. Zangemeister 1976] einsteigt und
nur noch vielversprechende Nutzwertpotenziale in die Quantifizierung einbezieht (vertiefend
in den Abschnitten 9.2 und 10.4.2 diskutiert).
Die Identifikation des Sponsors (oder mehrerer Sponsoren) erfolgt auf Basis der relevanten
Stakeholder und der identifizierten Nutzenpotenziale. Auf Basis einer Entscheidungsvorlage
können die Ergebnisse der Kosten-Nutzen-Analyse dem Kreis der
relevanten Stakeholder präsentiert werden, die in der Lage sind, entsprechende Mittel
zu bewilligen. Der Sponsor beziehungsweise die Sponsoren treffen dann die Investitionsentscheidung,
welche die umzusetzenden Viewpoints spezifiziert.
Die Definition des Projektumfangs erfolgt dann auf Basis der relevanten Viewpoints,
indem diese genutzt werden, um benötigte MDMS-Funktionalitäten zu spezifizieren.
Diese dienen als Anforderungskatalog für die weitere Projektumsetzung. Hierbei sind
auch Annahmen und Einschränkungen zu dokumentieren, welche für die Projektdurchführung
(insbesondere auch die Auswahl des MDMS-Tools) eine Rolle spielen.
Das sich hieraus ergebende Vorgehensmodell ist mit seinen Aktivitäten und Ergebnissen
in Abb. 2 dargestellt.

16 Grundlagen
Abb. 2: Vorgehensmodell für die Bedarfsanalyse fachlicher Metadaten
Setzt man die Ergebnisse der einzelnen Aktivitäten in Beziehung zueinander, erhält
man das Informationsmodell (bzw. Metamodell) des Vorgehensmodells aus Abb. 2
[Gutzwiller 1994: 12-14]. Dieses Informationsmodell dient als Bezugsrahmen für die
vorliegende Dissertation und wird in Abschnitt 3.5 näher betrachtet.
2.4 Anforderungen im IS-Design
In diesem Abschnitt werden Anforderungen aus Sicht des AM und des EE diskutiert.
Die Beschränkung dieser Diskussion auf diese beiden Disziplinen erfolgt hinsichtlich
ihrer Bedeutung für die Bedarfsanalyse, die im Fokus dieser Dissertation steht. Beide
Disziplinen stellen Techniken zur Identifikation und Dokumentation von Anforderungen
bereit, die in der Bedarfsanalyse während der Phase „Identifikation Handlungsbedarf“
Anwendung finden können (im Detail Abschnitt 3.4).
Zunächst werden Anforderungen aus der Perspektive des AM in Abschnitt 2.4.1 und
danach aus der Perspektive des EE in Abschnitt 2.4.2 erörtert. Abschließend wird ein
konsolidiertes Begriffsverständnis vorgestellt.
2.4.1 Anforderungsmanagement
Das AM ist eine Subdisziplin im Systems und Software Engineering, das sich damit
auseinandersetzt, die Ziele, Funktionen und Einschränkungen für das Design von
Hardware- und Softwaresystemen zu bestimmen [Laplante 2009]. In diesem Zusammenhang
ist eine Anforderung eine „condition or capability needed by a user to solve a
problem or achieve an objective“ [IEEE 1990: 62]. Hierbei schlagen einige Autoren/Autorinnen
vor, dass Anforderungen alleine das „Was“ eines Systems beschreiben
sollen und weniger das „Wie“ [Kotonya, Sommerville 1998: 4], um strikt IT-Bedarf

Grundlagen 17
(Fachseite) vom IT-Angebot (IT) zu trennen. Die Praxis zeigt jedoch, dass diese Sicht
zu simplifizierend ist. Schließlich muss ein System kompatibel mit seiner Umgebung
sein, was die Freiheiten beim Design und der Implementierung einschränkt [Dietz
2007: 39-43; Kotonya, Sommerville 1998: 3-4]. Daher sind Anforderungen im Allgemeinen
eine Mischung aus „problem information, statements of systems behavior and
properties and design/manufacturing constraints“ [Kotonya, Sommerville 1998: 4].
In der Regel werden im AM funktionale und nichtfunktionale Anforderungen unterschieden
[z. B. IFPUG 2010: 1-7; Landes, Studer 1995: 1-2; Paech, Kerkow 2004: 27;
van Lamsweerde 2001: 3]. Während bei der Auslegung des Begriffs „funktionale Anforderung“
Einigkeit herrscht, findet sich für „nichtfunktionale Anforderungen“ eine
ganze Bandbreite an Definitionen [Glinz 2007: 1-2]. Funktionale Anforderungen definieren,
„was“ ein System können sollte oder müsste [Paech, Kerkow 2004: 28; Robertson,
Robertson 2006: 9; Sommerville 2010: 110-111]. Präziser formuliert beschreibt
eine Funktion Eingaben (Stimuli), Ausgaben (Antworten) und die funktionale Beziehung
zwischen diesen beiden [Davis 1993; Dietz 2007: 41; IFPUG 2010: 1-7]. Beispiele
für funktionale Anforderungen sind eine Kommentierungsfunktion und das bedarfsgerechte
Einblenden von Hintergrundinformationen.
Nichtfunktionale Anforderungen hingegeben beschreiben, „wie gut“ ein System in
einer bestimmten Umgebung seine Funktionen erfüllt [Paech, Kerkow 2004: 28; Robertson,
Robertson 2006: 10; van Lamsweerde 2001: 3]. Diese Anforderungen beschreiben
damit die Eigenschaften und Bedingungen, unter denen ein System operiert.
Hierbei ist man sich in der Literatur uneinig, ob diese Charakteristika Einschränkungen
beinhalten, die durch die Systembenutzenden wahrnehmbar sind [Glinz 2007: 1-
4]. In dieser Arbeit wird die Auffassung vertreten, dass auch durch den Nutzenden
wahrnehmbare Eigenschaften und Bedingungen einen Teil der nichtfunktionalen Anforderungen
darstellen. Eine andere Auffassung würde nahelegen, dass z. B. die Anforderung
„geringe Antwortzeit“ entweder funktional wäre oder in keine der beiden
Anforderungskategorien fallen würde. Dies ist nicht eingängig, da auf der einen Seite
die Namensgebung der beiden Kategorien Vollständigkeit suggeriert und auf der anderen
Seite eine Funktion das „Was“ und nicht das „Wie“ beschreibt. Nichtfunktionale
Anforderungen sind neben „geringe Antwortzeit“ typischerweise „hohe Verlässlichkeit“
und „hohe Datenqualität“ [vgl. Boehm 1978: 595; Chung, Sampaio de Prado Leite
2009: 364-397; Grady, Caswell 1987: 159, 210].

18 Grundlagen
2.4.2 Enterprise Engineering
Das EE ist eine Disziplin im Systems Engineering, das sich auf die zielgerichtete,
theoriebasierte Entwicklung von Unternehmensorganisationen aus einer Ingenieurssicht
fokussiert [Dietz 2006; Hoogervorst 2009; Saenz et al. 2009]. Daher ist der zentrale
Aspekt im EE die Übersetzung von Anforderungen in ein Design. Hier liegt der
fundamentale Unterschied zum AM. Während das AM nach der Sammlung, Validierung
und Bewilligung der Anforderungen aufhört, erstreckt sich das EE über die anschließende
Designphase hinweg [Dietz 2007].
Abb. 3: Taxonomie für Anforderungen
Das ist auch der Grund, warum das AM Anforderungen nur aus einer Systemnutzerperspektive
begreift und EE darüber hinaus Einschränkungen (Anforderungen im weiteren
Sinne) aus Sicht des Bereitstellers berücksichtigt. Diese „Einschränkungen“ resultieren
aus der zugrunde liegenden Architektur des Bereitstellers und werden „(Design-)Prinzipien“
genannt [Dietz 2007: 62; IEEE 2000: 3; Stelzer 2009: 24-25]. In An-

Grundlagen 19
lehnung an das AM können funktionale und nichtfunktionale Prinzipien unterschieden
werden. „Standardisierte Dialoge“ und „mehrsprachige Interfaces“ sind typische Beispiele
für funktionale Prinzipien, während „Serviceorientierte Architektur“ und
„Client-Server-Architektur mit ‚Thin Clients‘“ Beispiele für nichtfunktionale Prinzipien
sind. Abb. 3 bringt die Perspektiven aus dem AM und dem EE überein.

20 Bestehende Ansätze
3 Bestehende Ansätze
In diesem Kapitel werden bestehende Ansätze zur Entwicklung und Weiterentwicklung
von MDMS vorgestellt. In Abschnitt 3.1 wird die Auswahl relevanter Ansätze
begründet. In den Abschnitten 3.2 bis 3.4 werden die jeweiligen Ansätze mit Fokus auf
die Anforderungen an eine Bedarfsanalyse diskutiert.
3.1 Auswahl verwandter Ansätze
Im Fokus der Dissertation steht die Bedarfsanalyse fachlicher Metadaten. Für die Identifikation
verwandter Ansätze kann eine Literaturanalyse daher drei verschiedene Bereiche
betrachten: Zunächst werden Arbeiten betrachtet, die sich im Detail mit fachlichen
Metadaten auseinandersetzen (Abschnitt 3.2). Danach liegt der Fokus auf Arbeiten,
die sich allgemein mit Metadaten (inkl. technischer Metadaten) befassen (Abschnitt
3.3). Abschließend werden Arbeiten diskutiert, die sich losgelöst von einem
Metadatenkontext mit der Bedarfsanalyse auseinandersetzen (Abschnitt 3.4). Hierbei
wird sukzessive der Blickwinkel auf die vorhandene Literatur erweitert, was sich dabei
auf die Spezifität der zu erwartenden Ergebnisse auswirken wird. Grundsätzlich stellt
sich für alle drei Perspektiven die Frage, inwiefern sie die Forschungsfragen der Dissertation
bereits adressieren und zur Entwicklung fehlender Bausteine beitragen können.
Bei der Analyse der Literatur zu fachlichen Metadaten und Metadaten im Allgemeinen
werden im Folgenden nur Arbeiten betrachtet, die sich an die Anwendung im BI richten.
Bei der Durchführung der Analyse hat sich gezeigt, dass viele Arbeiten Metadaten
mit Blick auf die Beschreibung digitaler Medien und das Bibliothekswesen betrachten.
Obwohl hier grundsätzlich verwandte Ziele verfolgt werden, unterscheidet sich mit
dem jeweiligen Objekt, das durch Metadaten beschrieben wird, doch sehr stark der
eigentliche Informationsbedarf. So stehen im BI Daten und Datenflüsse im Vordergrund,
die vor allem Fragen nach Datenformaten, Definitionen und Transformationsschritten
in der Datenverarbeitung aufwerfen.
3.2 Analyse der Literatur zu fachlichen Metadaten
Grundsätzlich existieren vergleichsweise wenige Beiträge in der Literatur, die sich mit
fachlichen Metadaten im Detail auseinandersetzen. Eine Volltextsuche auf Schlüssel-

Bestehende Ansätze 21
wörter in vier Literaturdatenbanken 9 ergab 41 Treffer, von denen lediglich drei Beiträge
im Rahmen dieser Disseration relevant sind. Unter Einbezug der Referenzen und
weiterer Veröffentlichungen der Autoren konnte die Liste relevanter Beiträge auf zehn
erhöht werden. Diese Beiträge sind in Tab. 3 mit Blick auf die zugrunde liegenden
Forschungsfragen (Abschnitt 1.2) dargestellt.
No. Beitrag
FI: Anwendungsgebiete/
Domänen
FII: Nutzenpotenziale
FIII: Funktionalitäten von
COTS-Produkten
FIV: Implikationen von
Nutzerpräferenzen
1 [Chengalur-Smith, Ballou, Pazer 1999] 0 2 0 0
2 [Dhaliwal, Benbasat 1996] 0 1 0 2
3 [Even, Shankaranarayanan, Watts 2006] 0 2 0 0
4 [Fisher, Chengalur-Smith, Ballou 2003] 0 2 0 2
5 [Foshay 2005; Foshay, Mukherjee, Taylor 2007] 1 2 0 0
6 [Mao, Benbasat 2000] 0 1 0 2
7 [Shankaranarayanan, Even 2006] 1 1 1 0
8 [Shankaranarayanan, Even, Watts 2006] 0 2 0 2
9 [Shankaranarayanan, Even 2004] 1 1 2 0
10 [Shankaranarayanan, Watts 2003] 0 2 0 0
0
Nicht adressiert
2
Teilaspekte diskutiert
4 Vollumfänglich
1
Angesprochen
3
Wenige Lücken
adressiert
Tab. 3: Übersicht Literaturanalyse zu fachlichen Metadaten
Betrachtet man die Ergebnisse der Literaturanalyse, beschäftigen sich die Beiträge
vorwiegend mit der Diskussion der Nutzenpotenziale von fachlichen Metadaten. Die
9 Es wurde in den Literaturdatenbanken von EbscoHost, ISI Web of Knowledge, SpringerLink (LNCS Proceedings)
und ScienceDirect gesucht. Die gesuchten Schlüsselwörter umfassten den Begriff „fachliche Metadaten“
sowie seine englischsprachigen Synonyme.

22 Bestehende Ansätze
Diskussionen beschränken sich dabei in der Regel auf abstrakte Ursache-Wirkungs-
Beziehungen, die für sich alleine nicht geeignet sind, den Bedarf unter ökonomischen
Aspekten zu bewerten. Foshay [2005: 17-19] und Foshay et al. [2007: 74-76] beispielsweise
belegen emprisch, dass fachliche Metadaten einen positiven Effekt auf die
Nutzung von BI-Systemen haben. Chengalur-Smith et al. [1999: 177-181] und Fisher
et al. [2003: 860-864] hingegen weisen nach, dass Qualitätsinformationen Entscheidungen
beeinflussen können. Shankaranarayanan und Watts [2003] und Even et al.
[2006: 7-8] untersuchen die Auswirkungen von Verarbeitungsinformationen auf die
Glaubwürdigkeit von Informationsquellen.
Einige Arbeiten berücksichtigen hierbei Nutzerpräferenzen. So betrachten beispielsweise
Dhaliwal und Benbasat [1996] und Mao und Benbasat [2000], wie sich die Seniorität
von Nutzenden auf die Anwenung von Erklärungen bei der Entscheidungsfindung
auswirkt. Ähnliches untersuchen auch Fisher et al. [2003], die den Effekt von
Seniorität auf den Einsatz von Datenqualitätsinformationen betrachten. Zuletzt sind
noch Shankaranarayanan et al. [2006] zu nennen, die den Effekt von Prozessmetadaten
auf Nutzer mit einer Präferenz für analytisch geprägte Entscheidungsfindung diskutieren.
Grundsätzlich werden hierbei jedoch nur bestimmte Metadaten und bestimmte
Präferenzen betrachtet.
Zusammenfassend lässt sich festhalten, dass fachliche Metadaten nicht umfassend diskutiert
werden, um die Ergebnisse im Rahmen einer Bedarfsanalyse nutzbar zu machen.
Sehr deutlich zeigt sich das mit Blick auf die Nutzenpotenziale von fachlichen
Metadaten. Es bedarf hier einer vollständigen Betrachtung der relevanten Dimensionen
und einer Systematik, welche diese für eine Kosten-Nutzen-Analyse bewertbar macht.
3.3 Analyse der Literatur zu Metadaten im Allgemeinen
Betrachtet man die Literaturanalyse von Melchert [2006: 72-73], finden sich Arbeiten,
die sich mit der Entwicklung und Konzeption von MDMS befassen, vornehmlich in
Praktikerpublikationen. Erweitert man diese Literaturanalyse 10 , lassen sich insgesamt
fünf Beiträge identifizieren, die im Rahmen der Dissertation relevant sind. Diese Arbeiten
sind in Tab. 4 mit Blick auf die zugrunde liegenden Forschungsfragen (Abschnitt
1.2) dargestellt.
10 Diese wurde in der Literaturdatenbank von Google Books für den Zeitraum zwischen 2006 und 2010 durchgeführt
und erzielte 49 Treffer. Gesucht wurde nach dem Schlüsselwort „Metadata“ im Titel und zusätzlich nach
der Erwähnung der Schlüsselwörter „Business Intelligence“ oder „Data Warehouse“. Schlüsselwörter, die zur
Abgrenzung relevanter Beiträge genutzt wurden, beinhalteten: „Library“, „Web 2.0“ und „Media“.

Bestehende Ansätze 23
No. Beitrag
FI: Anwendungsgebiete/
Domänen
FII: Nutzenpotenziale
FIII: Funktionalitäten von
COTS-Produkten
FIV: Implikationen von
Nutzerpräferenzen
1 [Inmon, O'Neil, Fryman 2008] 2 2 1 0
2 [Marco 2000] 1 2 0 0
3 [Melchert 2006] 2 1 0 0
4 [Tannenbaum 2002] 1 1 0 0
5 [Wegener 2007] 2 2 0 0
0
Nicht adressiert
2
Teilaspekte diskutiert
4 Vollumfänglich
1
Angesprochen
3
Wenige Lücken
adressiert
Tab. 4: Übersicht Literaturanalyse zu Metadaten im Allgemeinen
Im Folgenden sollen die einzelnen Beiträge näher beleuchtet werden. Inmon, O’Neil
und Fryman [2008] diskutieren eine Bedarfsanalyse nicht gesamthaft, adressieren jedoch
Teilaspekte, die sich den einzelnen Forschungsfragen zuordnen lassen. Die Ausführungen
zum Wertbeitrag von Metadaten (insbesondere fachliche Metadaten) fokussieren
sich jedoch ausschließlich auf die Gruppe der Datenkonsumierenden [2008: 25-
34]. Dass auch Datenproduzierende und Datenmanager von den Metadaten profitieren,
bleibt hierbei unberücksichtigt. Dieser Fokus zieht sich auch durch die Diskussion der
Anwendungsgebiete durch [Inmon, O'Neil, Fryman 2008: 55-78]. Darüber hinaus
werden einige notwendige Funktionalitäten eines MDMS im Rahmen der Entscheidungsfrage,
ob eine MDMS-Lösung extern zugekauft oder intern entwickelt werden
soll umrissen, aber nicht näher vertieft [Inmon, O'Neil, Fryman 2008: 170-171].
Vergleichbar mit dem vorherigen Beitrag erwähnt auch Wegener [2007] die Bedarfsanalyse
nicht explizit. Vielmehr werden anhand von Beispielen für Finanzdienstleister
Anwendungsgebiete von Metadaten diskutiert und entsprechende Nutzenpotenziale
aufgezeigt [Wegener 2007: 71-178]. Insgesamt adressiert diese Arbeit jedoch sehr
spezielle Problemstellungen, die sich nicht leicht übertragen lassen.

24 Bestehende Ansätze
Marco [2000: 83-322] stellt ein Vorgehensmodell zur Einführung von Metadatensystemen
vor. Dabei stellt er der eigentlichen Entwicklungsarbeit eine optionale Orientierungsphase
und eine Machbarkeitsstudie voran. Gemeinsames Ziel dieser Phasen ist
es, einerseits die wichtigsten Stakeholder (potenzieller Sponsoren) von der Notwendigkeit
von Metadaten zu überzeugen und andererseits den Projektumfang unter Kosten-Nutzen-Erwägungen
abzugrenzen. Dies deckt sich im Umfang mit den Zielen einer
Bedarfsanalyse, allerdings fehlt es diesen Ausführungen an umfassenden Orientierungshilfen
für die Identifikation potenzieller Sponsoren und die Erfassung des Nutzwertes.
Tannenbaum [2002: 257-347] hingegen diskutiert sehr ausführlich die einzelnen
Schritte im AM, um in einer konsistenten Form Anforderungen zu dokumentieren, zu
strukturieren und in ein integriertes Metamodell zusammenzuführen. Die Bedarfsanalyse
und die damit einhergehende Finanzierungsproblematik eines MDMS findet hierbei
keinerlei Berücksichtigung. Der Ansatz von Tannenbaum setzt somit eine positive
Investitionsentscheidung und das Vorhandensein eines Sponsors bereits voraus.
Melchert [2006: 135-305] stellt den einzigen wissenschaftlich verorteten Beitrag zur
Entwicklung von MDMS dar und adressiert hierbei vor allem identifizierte Schwachpunkte
der praxisorientierten Beiträge von Marco und Tannenbaum. Hierfür wird auf
Fallstudien mit Partnerunternehmen aufgebaut und die Erfahrungen werden in einem
„Best-of-Breed“-Ansatz in ein Gesamtmodell überführt. Zwar betont Melchert in den
Anforderungen an sein Vorgehensmodell die Lösung der Finanzierungsproblematik,
lässt diese im Weiteren jedoch weitgehend unberücksichtigt. In der ersten Phase „Strategieplanung“
werden zwar Stakeholderinteressen analysiert und in eine gemeinsame
Strategie zusammengeführt, jedoch stellt dies nur einen Teil einer umfassenden Bedarfsanalyse
dar. Eine objektive Validierung des Handlungsbedarfs unter Kosten-
Nutzen-Erwägungen und eine damit einhergehende Identifikation von Sponsoren findet
nicht statt.
Abschließend lassen sich aus der Analyse der bestehenden Beiträge zur Entwicklung
von MDMS insbesondere zwei Erkenntnisse festhalten: Zum einen betonen die meisten
Werke mehr oder weniger ausführlich die Notwendigkeit einer Bedarfsanalyse. In
diesem Zusammenhang wird besonders die Finanzierungsproblematik aufgeführt, welche
sich vor allem aus den Schwierigkeiten der Nutzenbewertung und der Identifikation
entsprechender Sponsoren ergibt. Zum anderen adressieren alle Werke die Herausforderungen
einer Bedarfsanalyse nur unzureichend. In der Regel werden Teilaspekte

Bestehende Ansätze 25
wie beispielsweise die Entwicklung einer Strategie zur Abgrenzung des Projektumfangs
diskutiert, dennoch fehlen hierbei Modelle, welche die Praxis dabei unterstützen.
3.4 Analyse der Literatur zu Bedarfsanalyse im Allgemeinen
Anders als in den vorherigen Abschnitten kann die Diskussion zur Bedarfsanalyse im
Allgemeinen nur sehr schwer auf der Basis einzelner Beiträge geführt werden, da ohne
Einschränkung auf eine bestimmte Forschungsrichtung die Anzahl der Beiträge den
Rahmen der Dissertation sprengen würde. Stattdessen werden Forschungsrichtungen
identifiziert und vorgestellt, die für die Dissertation relevant sind. Relevant ist eine
Forschungsrichtung, wenn sie die Bedarfsanalyse als Ganzes oder in Teilen adressiert.
Die identifizierten Forschungsrichtungen sind in Tab. 5 dargestellt.
No. Forschungsrichtung
FI: Anwendungsgebiete/
Domänen
FII: Nutzenpotenziale
FIII: Funktionalitäten von
COTS-Produkten
FIV: Implikationen von
Nutzerpräferenzen
1 Projektmanagement 1 1 1 0
2 Anforderungsmanagement 1 0 0 0
3 Enterprise Engineering 1 0 0 0
4 Kosten-Nutzen-Analyse 0 1 0 0
5 Serviceorientierung 0 0 1 0
6 Situatives MSS-Design 0 0 0 2
0
Nicht adressiert
2
Teilaspekte diskutiert
4 Vollumfänglich
1
Angesprochen
3
Wenige Lücken
adressiert
Tab. 5: Übersicht Forschungsrichtungen zu Bedarfsanalyse im Allgemeinen
Im Folgenden werden die Forschungsrichtungen mit ihren relevanten Elementen kurz
vorgestellt. Wie bereits in Abschnitt 2.3 dargelegt, skizzieren Arbeiten aus dem Projektmanagement
die notwendigen Elemente und Schritte der Bedarfsanalyse und geben
damit den groben Rahmen für das Vorgehensmodell zur Bedarfsanalyse vor.

26 Bestehende Ansätze
Techniken aus dem Anforderungsmanagement können in der Phase „Identifikation
Handlungsbedarf“ eingesetzt werden, um die Viewpoints der relevanten Stakeholder
von fachlichen Metadaten zu definieren (z. B. „Controlled Requirements Expression
(CORE)“ und „Viewpoint-Oriented Requirements Definition (VORD)“) [Darke,
Shanks 1996; Kotonya, Sommerville 1998; Leité, Freeman 1991]. Im selben Zuge
kann der Bereich Enterprise Ontology aus dem Enterprise Engineering genannt werden
[Dietz 2006]. Mit Hilfe dieses Vorgehens können in sich abgeschlossene und wiederverwendbare
Funktionalitäten identifiziert werden, die von den relevanten Stakeholdern
benötigt werden. Techniken der Kosten-Nutzen-Analyse können in der gleichnamigen
Phase genutzt werden, um die Nutzenanalyse entlang der identifizierten Nutzendimensionen
von fachlichen Metadaten durchzuführen [Kingston 2001: 478-479].
Neben rein quantitativen Bewertungsmodellen gibt es hier auch qualitative Konzepte,
die Projektalternativen in Form eines Scoringmodells bewerten [Zangemeister 1976].
Erkenntnisse aus der Serviceorientierung zu Designprinzipien (insbesondere Bedarfsorientierung
und Modularität) können in der Phase „Definition Projektumfang“ eingesetzt
werden, um die notwendigen Funktionalitäten aus einer reinen Anwendersicht
und gezielt auf die eigentliche Problemstellung zu definieren [Heutschi 2007: 34-35].
In der situativen MSS-Forschung gibt es einige Artikel, die sich mit den Implikationen
von Präferenzen auf fachliche Metadaten auseinandersetzen (bereits in Abschnitt 3.2
aufgeführt). Darüber hinaus werden hier Modelle zur Klassifikation von Nutzertypen
und zur Beschreibung ihrer Präferenzen dargestellt, auf denen die Dissertation aufbauen
kann [z. B. Myers 1976; Rowe, Boulgarides 1983; Witkin et al. 1977].
Betrachtet man die Ergebnisse der Analyse, lässt sich schnell erkennen, dass die einzelnen
Forschungsrichtungen nicht spezifisch genug sind, um die Fragestellungen der
Dissertation umfänglich oder in Teilen zu adressieren. Dies liegt auch daran, dass die
vorliegende Dissertation Modelle (Ergebnissicht) entwickelt und diese Forschungsrichtungen
primär eine aktivitätenorientierte Hilfestellung leisten (Ausnahme: Situatives
MSS-Design). Dennoch sind diese Forschungsrichtungen relevant, um die einzelnen
Modelle im Vorgehensmodell zur Bedarfsanalyse zu verankern.
3.5 Implikationen und Bezugsrahmen für die Dissertation
Die Diskussion der vorhandenen Literatur in den vorherigen Abschnitten zeigt, dass es
noch an Unterstützung für die Bedarfsanalyse fachlicher Metadaten in der Praxis mangelt.
Auf der einen Seite ist die Diskussion von fachlichen Metadaten noch nicht umfassend
für diese Zwecke geführt worden und auf der anderen Seite sind Arbeiten zur

Bestehende Ansätze 27
Entwicklung und Konzeption von MDMS im Allgemeinen zu sehr auf die Definition
von Aktivitäten und Abläufen fokussiert. In Analogie zu der Diskussion in Winter et
al. [2009: 8-9] werden für die Unterstützung bei der Bedarfsanalyse jedoch auch Modelle
benötigt, die sich schwerpunktmäßig mit den Ergebnissen der einzelnen Phasen
auseinandersetzen. An dieser Stelle setzt die Dissertation an.
Nach Gutzwiller [1994: 12-14] setzt ein Informationsmodell (bzw. Metamodell) die
Ergebnisse aus den Aktivitäten einer Methode in Beziehung zueinander. Da hier die
Ergebnissicht in den Vordergrund gestellt werden soll, stellt das Informationsmodell
der Bedarfsanalyse den Bezugsrahmen der Dissertation dar. Aufgabe des Bezugsrahmens
ist es, die relevanten Forschungsobjekte und Beiträge in der kumulativen Ausarbeitung
nachvollziehbar und systematisch zu ordnen. In der Erstellung der Dissertation
diente dieser Bezugsrahmen darüber hinaus dazu, die Sicherheit und das Ausmaß der
Zielerreichung im Forschungsprozess zu erhöhen [Grochla 1976: 631-637; Kubicek
1977: 15-17; Wolf 2005: 30-36].
Abb. 4: Informationsmodell der Bedarfsanalyse
Die Ableitung des Informationsmodells baut auf den Ausführungen in Abschnitt 2.3
auf. Im Mittelpunkt stehen hier (relevante) Stakeholder, die Concerns haben. Die entsprechenden
Informationsbedarfe, die sich aus den Concerns ergeben, werden mit Hilfe
von Viewpoints modelliert. Aus diesen Viewpoints ergeben sich Anforderungen an
fachliche Metadaten und MDMS-Funktionalitäten. Die fachlichen Metadaten werden
dabei durch MDMS-Tools bereitgestellt, die die MDMS-Funktionalitäten umfassen.
Durch die Bereitstellung der fachlichen Metadaten (über MDMS-Funktionalitäten)
werden letztendlich die Nutzenpotenziale realisiert, welche die initialen Concerns der

28 Bestehende Ansätze
Stakeholder adressieren. Die Kosten der Bereitstellung sind hier nicht gesondert aufgeführt,
da nur ökonomisch sinnvolle Concerns betrachtet werden sollen. Die Kosten
werden hierdurch implizit berücksichtigt. Die hierin beschriebenen Entitäten und Beziehungen
sind in Abb. 4 dargestellt. Dabei sei erwähnt, dass die hier spezifizierten
Beziehungen entgegen einem (statischen) Strukturmodell nicht ungerichtete Referenzen
darstellen, sondern den inhaltlichen Ausführungen zur Ableitung folgen. Die Entitäten
sind in Analogie zu den Strukturierungsansätzen in der Unternehmensarchitektur
in vereinfachter Form den Ebenen Business, Alignment und IT zugeordnet [Winter,
Fischer 2007: 2].
Abb. 5: Informationsmodell der Bedarfsanalyse –
Spezialisierung auf Systemnutzer
Wie in Abschnitt 1.2 ausgeführt, wird in dieser Dissertation der Systemnutzer aufgrund
seiner Bedeutung für den Projekterfolg gesondert betrachtet. Das allgemein gehaltene
Informationsmodell in Abb. 4 wird daher aus dessen Sicht spezialisiert. Betrachtet
man den Systemnutzer näher, dann sind es vor allem dessen Präferenzen, die
über Umfang und Form des Einsatzes von IS im Allgemeinen entscheiden [McCoy,
Galletta, King 2007: 88-89; Zmud 1979: 4-10]. Da es aus Gründen der Komplexität
sicherlich keinen Sinn macht, jeden Systemnutzer individuell zu adressieren, werden
diese analog zu den situativen Ansätzen in der Referenzmodellierung [Becker, Delfmann,
Knackstedt 2007: 32-38; Gregor, Jones 2007: 325] und im Methoden-
Engineering [Harmsen 1997: 21-39; Kumar, Welke 1992: 263-264; van Slooten, Hodes
1996: 31-33] durch wenige Nutzerprofile zu homogenen Gruppen zusammenge-

Bestehende Ansätze 29
fasst. Diese für die Systemnutzer spezialisierte Sicht auf das beschriebene Informationsmodell
ist in Abb. 5 dargestellt.

30 Beiträge der Arbeit
4 Beiträge der Arbeit
In diesem Kapitel werden die Veröffentlichungen im Rahmen der kumulativen Dissertation
vorgestellt. Ziel ist dabei insbesondere die Kohärenz der Einzelbeiträge darzulegen.
Hierfür werden die Ergebnisse der Dissertation entlang der verschiedenen Elemente
einer Methode verortet, um die Ergebnissicht (Fokus dieser Diskussion) und die
Aktivitätensicht zusammenzubringen (Abschnitt 1.2). Nach Gutzwiller [1994: 12-14]
beinhaltet eine Methode fünf Elemente: Aktivitäten, Techniken, Rollen, Ergebnisse
und das Informationsmodell (bzw. Metamodell), welches die Ergebnisse in Beziehung
setzt.
In den Einzelbeiträgen wurden Empfehlungen für die Ergebnisse einer Bedarfsanalyse
entwickelt. In Abschnitt 4.1 wird daher zunächst ein Überblick über die Beiträge der
Arbeit gegeben und diese im Informationsmodell, das gleichzeitig den Bezugsrahmen
der Dissertation darstellt (Abschnitt 3.5), zusammengeführt. In Abschnitt 4.2 werden
die Artefakte der Beträge dann entlang der Aktivitäten in der Bedarfsanalyse zur Anwendung
gebracht. Hierbei wird ebenfalls auf mögliche Techniken zur Unterstützung
der Aktivitäten aus verwandten Forschungsdisziplinen verwiesen (Abschnitt 3.4). Darauf
folgend werden in Abschnitt 4.3 die Artefakte bei der Identifikation der benötigten
Rollen im Unternehmen für die Durchführung der Bedarfsanalyse dargestellt. Dieses
Kapitel schließt mit wenigen formalen Anmerkungen in Abschnitt 4.4 zur Darstellung
und zum Abdruck der einzelnen Beiträge in den nachgelagerten Kapiteln 6 bis 14.
4.1 Überblick und Einordnung im Informationsmodell
Die kumulative Dissertation ist entsprechend den Forschungsfragen FI-FIV (Abschnitt
1.2) in vier inhaltliche Bausteine untergliedert:
B1. Anwendungsgebiete/Domänen für die Nutzung fachlicher Metadaten
Der Baustein erarbeitet ein konzeptionelles Modell zur Klassifizierung der Anwendungsgebiete/Domänen
für fachliche Metadaten und der hierin beteiligten Stakeholder.
Dieses Modell dient als Orientierungshilfe zur Identifikation des Handlungsbedarfs in
Bezug auf fachliche Metadaten. Des Weiteren dient der Kreis der relevanten Stakeholder
zur Identifikation potenzieller Sponsoren.

Beiträge der Arbeit 31
B2. Qualitative und quantitative Nutzendimensionen in der Anwendung von fachlichen
Metadaten
Der Baustein entwickelt ein konzeptionelles Modell an qualitativen und entsprechenden
quantitativen Nutzendimensionen für fachliche Metadaten. Dieses Modell dient
einem pragmatischen, zweistufigen Vorgehen im Zuge einer Kosten-Nutzen-Analyse
für fachliche Metadaten. Zunächst wird entlang der qualitativen Nutzendimensionen
eine pragmatische Nutzwertanalyse (Einstufung von Ist- und Soll-Zustand entlang einer
Ratingskala) durchgeführt, um im zweiten Schritt vielversprechende Nutzendimensionen
hinsichtlich ihrer quantifizierbaren Auswirkungen zu detaillieren.
B3. Funktionalitäten in MDMS-Tools zum Management von fachlichen Metadaten
Der Baustein entwickelt ein konzeptionelles Modell zur Systematisierung und Klassifizierung
der Funktionalitäten von COTS-Produkten für das Management von fachlichen
Metadaten. Dieses Modell kann für die Definition des Projektumfangs genutzt
werden, um hersteller- und implementierungsunabhängig Anforderungen an die zu
entwickelnde MDMS-Lösung zu spezifizieren.
B4. Auswirkungen von Präferenzen unterschiedlicher Nutzergruppen auf das Design
von Management-Support-Systemen (inkl. fachlicher Metadaten)
Der Baustein identifiziert unterschiedliche Nutzergruppen und ihre entsprechenden
Präferenzen für den Einsatz von Management-Support-Systemen (MSS) und leitet aus
diesen situationsspezifische Anforderungen an das funktionale und nichtfunktionale
Design von MSS ab. Die Untersuchung fachlicher Metadaten als eigentlicher Bestandteil
der vorliegenden Dissertation erfolgt dabei im Kontext ihrer Präsentationsumgebung.
Die Präferenzen und daraus resultierende Implikationen lassen sich in zweierlei
Hinsicht anwenden: Einerseits dienen die hier erlangten Kenntnisse der Überprüfung,
ob die tatsächliche Anwendung fachlicher Metadaten durch die Zielgruppe an Systemnutzern
wahrscheinlich ist. Andererseits werden durch die Implikationen auf das Design
Annahmen und Einschränkungen für die Definition des Projektumfangs aufgestellt.
Die Verankerung der einzelnen Bausteine im Bezugsrahmen aus Abschnitt 1.2 (Abb. 4
und Abb. 5) ist in Abb. 6 dargestellt.

32 Beiträge der Arbeit
Abb. 6: Einordnung der inhaltlichen Bausteine im Bezugsrahmen
Die Zuordnung der publizierten und eingereichten Beiträge nach Baustein und Abdeckung
der Phasen im Forschungsprozess 11 (Abschnitt 1.3) ist in Abb. 7 dargestellt.
Beitrag A.1 identifiziert elf Anwendungebiete/Domänen für fachliche Metadaten und
ihre entsprechenden Stakeholder (Abb. 12). Diese elf Anwendungsgebiete sind dabei
den drei Stakeholder-Klassen Datenkonsumierende, Datenmanager und Datenproduzierende
zugeordnet. Der Beitrag bedient sich hierbei der Techniken der Modellkonfiguration
und -aggregation, um die Anwendungsgebiete/Domänen für fachliche Metadaten
und der hieran beteiligten Stakeholder in einem konzeptionellen Modell zusammenzuführen.
Dieses Modell wurde im Rahmen eines Projekts für die Identifikation
des Handlungsbedarfs angewendet und evaluiert. Beitrag A.2 stellt eine Weiterentwicklung
des beschriebenen Modells hinsichtlich der Verständlichkeit dar (Abb. 14).
Darüber hinaus handelt es sich hierbei im Gegensatz zum Beitrag A.1 (veröffentlicht
als Short Paper) um eine vollumfängliche Veröffentlichung, welche den gesamten Design-
und Evaluationsprozess offenlegt.
Beitrag B entwickelt ein Datenmodell für das Terminologiemanagement (Abb. 17).
Der Beitrag verwendet dabei die Technik der Modellkonfiguration für das Design des
Datenmodells und evaluiert dessen Nutzen hinsichtlich der Auflösung von terminologischen
Defekten auf Basis analytischer Argumentation. Dieser Beitrag stellt damit
einen konkreten Lösungsansatz für verschiedene Anwendungsgebiete (insb. im Bereich
des Datenkonsumenten) dar und knüpft damit inhaltlich an die Beiträge A.1 und
A.2 an.
Beitrag C.1 identifiziert qualitative und quantitative Nutzendimensionen von fachlichen
Metadaten (Abb. 18). Der Beitrag bedient sich hierbei der Technik der Triangulation,
um aus der Literatur und Praxis eine vollständige Übersicht abzuleiten. Dieses
11 Die Phase „Communicate“ ist hier nicht näher berücksichtigt, da jede Veröffentlichung diese Anforderung per
definitione erfüllt.

Beiträge der Arbeit 33
Modell wurde im Rahmen mehrerer Projekte in Form einer zweistufigen Kosten-
Nutzen-Analyse eingesetzt. Beitrag C.2 ist die wissenschaftlich fundierte und anschlussfähige
Weiterentwicklung von Beitrag C.1 (Abb. 21), welcher aufgrund seiner
Praxisorientierung wesentliche Elemente des Forschungsprozesses ausblendet.
Abb. 7: Zuordnung der Beiträge zu den inhaltlichen Bausteinen und dem zugrunde
liegenden Forschungsprozess
Beitrag D entwickelt eine hersteller- und implementierungsunabhängige Funktionssicht
der am Markt zur Verfügung stehenden MDMS-Tools (Abb. 24). Der Beitrag
bedient sich hierbei der Technik des Desk Research (nur frei verfügbare Produktinformationen)
zur Identifikation, Systematisierung und Klassifizierung der Funktionalitäten
von COTS-Produkten für das Management von fachlichen Metadaten. Dieses
Modell wurde in einem Projekt in zweierlei Hinsicht angewendet: Zunächst wurde es
eingesetzt, um die Fachseite losgelöst von technischen Details mit der Thematik fachliche
Metadaten vertraut zu machen. Darüber hinaus wurde der Funktionskatalog verwendet,
um die notwendigen Komponenten für den Aufbau eines Glossars für Fachbegriffe
zu spezifizieren.
Beitrag E identifiziert Potenziale hinsichtlich der aktuellen Berücksichtigung von Nutzerpräferenzen
in der MSS-Forschung: Berücksichtigung weiterer Aspekte bei der
Identifikation von Nutzergruppen zusätzlich zu kognitiven Stilen, Betrachtung der Implikationen
von Nutzerpräferenzen auf nichtfunktionale Aspekte im MSS-Design und
verstärkter Fokus auf Designrichtlinien statt reiner Anforderungsdefinition (Abb. 28,
Abschnitt 12.3.3). Hierfür bedient sich der Beitrag der Technik des Literatur-Reviews,
um die bestehende wissenschaftliche Literatur zu Nutzerprofilen und ihre Implikationen
für das Design von MSS zu systematisieren.

34 Beiträge der Arbeit
Beitrag F identifiziert vier Nutzerprofile von Vorständen: „Analytische Poweruser“,
„Opportunistische Analysten“, „Generalistische Basisnutzer“ und „Faktische Nichtnutzer“
(Abb. 30, Abschnitt 13.5). Der Beitrag bedient sich hierfür der Technik der
Cluster- und Faktoranalyse, um auf Basis einer empirischen Umfrage Nutzerprofile für
die Anwendung von MSS zu identifizieren. Im Ausblick werden nutzerspezifische Designempfehlungen
für MSS zur Diskussion gestellt. Der Beitrag setzt dabei an einer
der identifizierten Forschungslücken in Beitrag E an. Durch das explorative Vorgehen
werden implizit alle relevanten Präferenzen der MSS-Nutzer (auch kognitiver Stil)
berücksichtigt.
Beitrag G entwickelt situative Empfehlungen bei der Auswahl der richtigen Endgeräte
zur Nutzung von MSS (Abb. 37). Der Beitrag bedient sich zunächst der Technik des
induktiven Designs, um auf Basis von Präferenzen für Nutzungsumfang, Nutzungsszenarien
und Arbeitsstile passende Endgeräte für MSS zu ermitteln. Das Modelldesign
wird im Rahmen einer Fokusgruppe validiert und mit sieben Vorständen hinsichtlich
seiner Nützlichkeit evaluiert. Der Beitrag baut zum einen auf den identifizierten
Nutzungsfaktoren aus Beitrag F auf und adressiert zum anderen eine identifizierte Forschungslücke
aus Beitrag E. Mit der Auswahl der Endgeräte stehen nichtfunktionale
Aspekte des MSS-Designs im Vordergrund.
Es sollte hierbei beachtet werden, dass die hier aufgeführten Beiträge zum Teil im
Rahmen unterschiedlicher Domänen (BI, MSS und Unternehmenssteuerungssysteme)
diskutiert, unter Anwendung verschiedener Techniken der Artefaktkonstruktion (Modellkonfiguartion,
Modellaggregation, Desk Research, Cluster-Faktor-Analyse und
Triangulation) entwickelt und dabei unterschiedliche Forschungsbereiche (AM, EE,
Kosten-Nutzen-Analyse und situatives MSS-Design) einbezogen werden.
Die unterschiedliche Auswahl der Domänen wurde in erster Linie an dem Zielpublikum
des jeweiligen Publikationsorgans ausgerichtet. Da im Rahmen der Dissertation
die Diskussion fachlicher Metadaten auf die Beschreibung von analytischen Informationen
zur Entscheidungsunterstützung begrenzt ist (Abschnitt 3.1), ist eine Beeinträchtigung
der Kohärenz der Beiträge durch die Auswahl der spezifischen Domänen
generell nicht zu erwarten. Darüber hinaus sind die hier verwendeten Begrifflichkeiten
MSS und BI als nahezu synonym zu betrachten [Clark Jr, Jones, Armstrong Curtis
2007]. Unternehmenssteuerungssysteme nehmen lediglich eine Einschränkung auf
eine bestimmte Nutzergruppe von MSS vor, welche für die Ergebnisse von Beitrag F
im Rahmen dieser Dissertation unerheblich ist (vgl. hierzu die detaillierte Diskussion
in Abschnitt 5.2).

Beiträge der Arbeit 35
Die unterschiedliche Auswahl der Techniken zur Artefaktkonstruktion erfolgte auf
Basis der relevanten Vorarbeiten in der Literatur. Sofern in den Beiträgen auf bestehenden
Modellen aufgebaut werden konnte, wurden Techniken der Referenzmodellierung
(z. B. Konfiguration und Aggregation) angewendet [vom Brocke 2007]. In den
anderen Fällen wurden Techniken des induktiven Designs (z. B. Cluster-Faktor-
Analyse und Triangulation) angewendet um auf Basis empirischer Daten theoretische
Modelle abzuleiten.
Die unterschiedliche Auswahl an Forschungsbereichen auf denen die Beiträge aufbauen
erfolgte auf Basis der Zielsetzung des jeweiligen Beitrags. Ausgangsbasis hierfür
waren die für die Themenstellung der Dissertation identifizierte relevante Literatur zur
Bedarfsanalyse aus Abschnitt 3.4.
4.2 Einordnung im Vorgehensmodell
Ziel dieses Abschnitts ist es, die Artefakte der einzelnen Beiträge in ein Vorgehensmodell
zur Bedarfsanalyse zusammenzuführen. Dies stellt keine Gestaltungsarbeit im
wissenschaftlichen Sinne dar und folgt damit auch nicht dem zugrunde liegenden Forschungsprozess.
Das folgende Vorgehensmodell ist damit nicht Gegenstand einer sorgfältigen
Evaluation und erfüllt in erster Linie den Sinn und Zweck, die Kohärenz der
Einzelbeiträge zu verdeutlichen.
Die weiteren Ausführungen gliedern sich nach den vier Phasen der Bedarfsanalyse,
welche in Abschnitt 2.3 eingeführt wurden (Abb. 2). Identifikation Handlungsbedarf:
Ausgangslage für die Identifikation des Handlungsbedarfs ist das Modell, das in Beitrag
A.1 (Kapitel 6) vorgestellt und in Beitrag A.2 (Kapitel 7) weiterentwickelt wurde.
Die Übersicht der Anwendungsgebiete/Domänen für fachliche Metadaten dient als
Ausgangsbasis für ein problemorientiertes Vorgehen. In der Diskussion mit einer
Auswahl an Unternehmensvertretern, welche gemeinsam die gesamte Informationswertschöpfungskette
abdecken, lassen sich hieran die größten Herausforderungen im
Unternehmen strukturieren und gezielt angehen.
Das Vorgehen entlang dieser Strukturierungshilfe bietet den Vorteil, dass alle möglichen
Bereiche berücksichtigt werden und man die vertiefenden Diskussionen auf die
größten Herausforderungen im Unternehmen mit den Stakeholdern in den entsprechenden
Bereichen fokussiert. Mit den Stakeholdern werden dann die benötigten fachlichen
Metadaten skizziert (Beispiel Kapitel 8). So gelangt man effektiv und effizient
an die notwendigen Ergebnisse in dieser Phase: relevante Stakeholder, relevante He-

36 Beiträge der Arbeit
rausforderungen (Concerns) und die benötigten fachlichen Metadaten (Viewpoints).
Das hier skizzierte Vorgehen ist im Detail in Abschnitt 7.4.2 dargestellt.
Kosten-Nutzen-Analyse: Ausgangslage für die ökonomische Bewertung ist das Modell,
das in Beitrag C.1 (Kapitel 9) vorgestellt und in Beitrag C.2 (Kapitel 10) weiterentwickelt
wurde. Die Übersicht von qualitativen und quantitativen Nutzendimensionen
kann für ein pragmatisches, zweistufiges Vorgehen herangezogen werden, welches die
Herausforderungen und ersten Lösungskonzepte aus der vorherigen Phase hinsichtlich
ihrer ökonomischen Sinnhaftigkeit bewertet. Im ersten Schritt wird entlang der quantitativen
Nutzendimensionen der Ist- und Soll-Zustand (nach Umsetzung des Lösungskonzepts)
auf einer Rating-Skala erfasst. Danach werden nur noch die vielversprechenden
Nutzendimensionen durch die entsprechenden quantitativen Nutzendimensionen
detailliert und den zu erwartenden Kosten gegenübergestellt.
Der Vorteil bei diesem zweistufigen Vorgehen ist die schnelle Konzentration auf die
vielversprechenden Nutzendimensionen. Dies kommt der Qualität der Ergebnisse in
dieser Phase zugute, da eine Quantifizierung des Nutzens fachlicher Metadaten in der
Regel nur schwierig zu bewerkstelligen ist und ein hohes Maß an Abstimmung erfordert.
Bei knappen Ressourcen bleibt so die Zeit für die wesentlichen, vielversprechenden
Fragestellungen bei der Gegenüberstellung von Nutzen und Kosten. Das hier skizzierte
Vorgehen ist im Detail in Abschnitt 9.4 beschrieben.
Identifikation Sponsor: Die Identifikation des Sponsors ist nicht Gegenstand eines eigenständigen
Beitrags, sondern erfolgt auf Basis der Ergebnisse der ersten beiden Phasen.
Der Sponsor bzw. die Sponsoren sind im Kreise der relevanten Stakeholder zu
suchen und anhand der Ergebnisse der Kosten-Nutzen-Analyse von der Sinnhaftigkeit
einer MDMS-Lösung zu überzeugen. Ist die Suche erfolgreich, erfolgt im selben Zuge
eine Eingrenzung des Projektumfangs. Unter Kosten-Nutzen-Aspekten mag nur eine
Teillösung sinnvoll sein bzw. unter strategischen Erwägungen ein aussichtsreicher,
schnell sichtbarer Teil ausgewählt werden, der bei Erfolg als Leuchtturmprojekt für die
übrigen Teile der anzustrebenden Gesamtlösung dient.
Definition Projektumfang: Die Anforderungen an die angestrebte MDMS-Lösung erfolgt
primär über das Modell, das in Beitrag D (Kapitel 11) vorgestellt wurde. Entlang
des Funktionskatalogs wird die Projektentscheidung aus der vorherigen Phase detailliert.
Der Vorteil bei der Verwendung des Funktionskatalogs liegt darin, dass er hersteller-
und implementierungsabhängig die Trennung von IT Demand (Fachseite) und
IT Supply (IT) ermöglicht. Dies stellt eine objektive Evaluation potenzieller MDMS-
Tools in der Umsetzungsphase sicher.

Beiträge der Arbeit 37
Zusätzlich zu den funktionalen Anforderungen können anhand der Ergebnisse aus den
Beiträgen F (Kapitel 13) und G (Kapitel 14) Annahmen und Einschränkungen für die
Lösungskonzeption erfolgen. Insbesondere aus dem Nutzenfaktor Analyseorientierung
(Abschnitt 13.4.4) lässt sich annehmen, dass nur Nutzende mit einer analytischen Präferenz
(„Analytische Poweruser“ und „Opportunistische Analysten“) auf fachliche
Metadaten zurückgreifen werden. Nutzende, die Konsumierende („Generalistische
Basisnutzer“ und „Faktische Nichtnutzer“) darstellen, werden in der Regel ihre Daten
aus den Standardreports in ausreichendem Umfang kennen, um auf fachliche Metadaten
verzichten zu können (vgl. Diskussion zu Nutzertypen in Abschnitt 14.4.1). Einschränkungen
für die Umsetzung erfolgen durch die situative Auswahl der passenden
Endgeräte für die Zielgruppe der fachlichen Metadaten. Je nach zur unterstützenden
Endgeräteklasse sind aufgrund von Platzrestriktionen und der jeweiligen Bedienung
unterschiedliche Konzepte notwendig. Der Vorteil bei Berücksichtigung der Nutzerpräferenzen
in den Annahmen und Einschränkungen ist, dass es die Transparenz über
den Erfolgsfaktor Nutzerakzeptanz ermöglicht. Der Erfolg des Projekts wird hierdurch
wahrscheinlicher. Die Einbindung der Ergebnisse aus den Beiträgen in das Vorgehensmodell
zur Bedarfsanalyse ist in Abb. 8 dargestellt.
Abb. 8: Vorgehensmodell Bedarfsanalyse unter Einbindung
der Ergebnisse der Beiträge
Zusammenfassend lässt sich feststellen, dass die Artefakte aus den Einzelbeiträgen
ausnahmslos in dem vorgestellten Vorgehensmodell Berücksichtigung und Anwendung
finden. Sie bilden die zentralen Elemente zur Erarbeitung der notwendigen Ergebnisse
in den einzelnen Phasen der Bedarfsanalyse. Limitationen und Risiken der
hier präsentierten Forschungsergebnisse werden in Abschnitt 5.2 diskutiert.

38 Beiträge der Arbeit
4.3 Einordnung im Rollenmodell
Ziel dieses Abschnitts ist es, die Artefakte der einzelnen Beiträge im Rahmen eines
Rollenmodells zur Bedarfsanalyse zusammenzuführen. Entsprechend dem vorherigen
Abschnitt stellt dies keine Gestaltungsarbeit im wissenschaftlichen Sinne dar und folgt
damit auch nicht dem zugrunde liegenden Forschungsprozess. Die folgenden Ausführungen
sind daher nicht Gegenstand einer sorgfältigen Evaluation und erfüllen in erster
Linie den Sinn und Zweck, die Kohärenz der Einzelbeiträge zu verdeutlichen.
In der Bedarfsanalyse lassen sich mindestens drei Rollen unterscheiden: Sponsor, Projektteam
und Anwender. Diese Rollen sind durch Ressourcen im Unternehmen zu detaillieren,
wobei die in dieser Dissertation entwickelten Artefakte unterstützen können.
Zunächst werden die einzelnen Rollen mit Blick auf die Durchführung der Bedarfsanalyse
näher beleuchtet, um anschließend die Identifikation der entsprechenden Ressourcen
im Unternehmen entlang der inhaltlichen Bausteine der vorliegenden Dissertation
zu demonstrieren.
Der Sponsor trifft letztendlich die Investitionsentscheidung und stellt gegebenenfalls
die notwendigen finanziellen und personellen Ressourcen für die Durchführung, die
sich bei einer positiven Entscheidung an die Bedarfsanalyse anschließt, bereit. Der
Sponsor oder die Sponsoren werden im Laufe der Bedarfsanalyse identifiziert und
übernehmen spätestens mit der Definition des Projektumfangs die Gesamtverantwortung
für das Vorhaben.
Das Projektteam ist Initiator der Bedarfsanalyse und für die operative Durchführung
der Bedarfsanalyse verantwortlich. In Abwesenheit eines Sponsors übernimmt es auch
die Gesamtverantwortung für die Bedarfsanalyse in den frühen Phasen. Grundsätzlich
kann das Projektteam (im Gegensatz zum Sponsor und den Anwendern) auch aus externen
Mitarbeitern bestehen. Das Projektteam für die Bedarfsanalyse bleibt in der Regel
auch in das gegebenenfalls anschließende Projekt involviert, wird jedoch insbesondere
durch Ressourcen ergänzt, welche die Implementierung des MDMS vornehmen.
Die Anwender tragen zwar keine operative Verantwortung in der Bedarfsanalyse, sind
aber aufgrund ihrer engen Verbindung zum angestrebten Projekterfolg bereits in der
Projektvorbereitung beratend einzubeziehen. Sie liefern nicht nur wichtige Indikatoren
für die Eingrenzung des Handlungsbedarfs und die Durchführung der Kosten-Nutzen-
Analyse, sondern grenzen mit ihren Nutzerprofilen auch den Lösungsraum für die Ein-

Beiträge der Arbeit 39
führung von fachlichen Metadaten ein. Abb. 9 fasst diese Ausführungen in Form einer
RACI-Matrix [Project Management Institute 2004: 205-207] zusammen.
Aktivitäten
Sponsor
Projektteam
Anwender
(Auftraggeber)
(Auftragnehmer)
Identifikation Handlungsbedarf - A, R C, I
Kosten-Nutzen-Analyse - A, R C, I
Identifikation Sponsor - A, R C, I
Definition Projektumfang A R C, I
R:
A:
C:
I:
Operativ verantwortlich („Responsible“)
Gesamtverantwortlich („Accountable“)
Beratend hinzugezogen („Consulted“)
Informiert („Informed“)
Abb. 9: Generische RACI-Matrix in der Bedarfsanalyse
Die Identifikation der entsprechenden Ressourcen im Unternehmen, welche die Rollen
in der Bedarfsanalyse ausfüllen, kann entlang der inhaltlichen Bausteine der Dissertation
erfolgen. Die Anwendungsgebiete (Baustein B1, Abschnitt 4.1) für fachliche Metadaten
im Unternehmen determinieren insbesondere den Ressourcenpool für die Rolle
der Anwender. Für die Identifikation des Handlungsbedarfs werden Vertreter aus alle
diesen Bereichen benötigt, um den Handlungsbedarf einzugrenzen. Dies kann in der
Regel in Personalunion erfolgen, um den Ressourcenbedarf in dieser frühen Phase
niedrig zu halten.
Die Nutzendimensionen (Baustein B2, Abschnitt 4.1) bilden dann die Ausgangsbasis,
um mit Hilfe der Kosten-Nutzen-Analyse den Bedarf an Anwendern für die weiteren
Phasen auf in der Regel wenige vielversprechende Anwendungsgebiete zu beschränken.
Diese übriggebliebenen Arbeitsbereiche stellen dann auch den Sponsor oder die
Sponsoren. Für die Definition des Handlungsbedarfs werden dann aus dem Kreise der
Anwender noch einmal Vertreter mit entsprechenden Nutzerprofilen (Baustein B4,
Abschnitt 4.1) benötigt, um Einschränkungen an die Lösungskonzeption zu definieren.
Auf Seiten des Projektteams sind in der Bedarfsanalyse in erster Linie Managementbeziehungsweise
Analystenfähigkeiten gefragt. Erst mit Blick Richtung der anschließenden
Projektphase werden zusätzlich IT-Kenntnisse hinsichtlich der Lösungskonzeption
benötigt. Auf Basis der benötigten MDMS-Funktionalitäten (Baustein B3,

40 Beiträge der Arbeit
Abschnitt 4.1) können entsprechende Ressourcen identifiziert und in den weiteren Projektverlauf
eingebunden werden. Abb. 10 fasst den hier beschriebenen Ressourcenbedarf
für die Durchführung der Bedarfsanalyse fachlicher Metadaten zusammen.
Aktivitäten
Sponsor
Projektteam
Anwender
(Auftraggeber)
(Auftragnehmer)
Identifikation
Handlungsbedarf
Kosten-Nutzen-
Analyse
Identifikation
Sponsor
- Projektmanager (ggf.
mit Unterstützung von
Business Analysten)
- Projektmanager (ggf.
mit Unterstützung von
Business Analysten)
- Projektmanager (ggf.
mit Unterstützung von
Business Analysten)
Vertreter aus den elf
Anwendungsgebieten
Vertreter aus den Anwendungsgebieten
mit
Handlungsbedarf
Vertreter aus den Anwendungsgebieten
mit
positivem Kosten-
Nutzen-Verhältnis
Definition Pro-
Entscheidungsträger
Projektmanager (ggf.
Vertreter der jeweili-
jektumfang
für die Anwendungs-
unterstützt von Busi-
gen Nutzenprofile aus
gebiete mit positivem
ness Analysten) plus
den Anwendungsge-
Kosten-Nutzen-
Spezialisten für die
bieten mit positivem
Verhältnis
benötigten MDMS-
Kosten-Nutzen-
Funktionalitäten
Verhältnis
Abb. 10: Ressourcenüberblick für die Bedarfsanalyse
4.4 Formale Anmerkungen
Den Hauptbestandteil der vorliegenden kumulativen Arbeit bilden Forschungsbeiträge,
die bereits in Tagungsbänden von Konferenzen oder wissenschaftlichen Zeitschriften
publiziert bzw. zur Publikation angenommen wurden. Beitrag G wurde zur Begutachtung
eingereicht. Dies hat zur Folge, dass die Forschungsbeiträge in der Originalform
unterschiedlich, also entsprechend den Richtlinien der jeweiligen Publikationsorgane,
formatiert sind. Für ein einheitliches Erscheinungsbild innerhalb der vorliegenden Arbeit
werden die Beiträge einheitlich umformatiert.
Der Arbeit ist ein einheitlicher Zitationsstil zugrunde gelegt und die Referenzen aller
Beiträge werden in einem gemeinsamen Literaturverzeichnis aufgeführt. Die Abbildungen
und Tabellen werden fortlaufend nummeriert. Weiterhin wird jeweils ein ge-

Beiträge der Arbeit 41
meinsames Abkürzungs-, Abbildungs- und Tabellenverzeichnis erstellt. Den Forschungsbeiträgen
selbst werden jeweils eine Zusammenfassung sowie Stichwörter
vorangestellt. Ferner wird am Anfang eines jedes Beitrags eine Tabelle aufgeführt, die
bibliografische Angaben, das heißt Informationen über die Autoren, den Titel und das
Publikationsorgan, enthält.
Die Schreibweise der einzelnen Beiträge wird vereinheitlicht. Für deutschsprachige
Forschungsbeiträge erfolgt die konsequente Anwendung der deutsch-deutschen
Schreibweise. Englischsprachige Beiträge werden durchgängig in amerikanischem
Englisch präsentiert. Daneben wurden noch vorhandene Rechtschreib- und Grammatikfehler
in den Originalbeiträgen korrigiert. Dabei wurden keine Anpassungen vorgenommen,
die den Inhalt des jeweiligen Beitrags betreffen.

42 Zusammenfassung, Diskussion und weiterer Forschungsbedarf
5 Zusammenfassung, Diskussion und weiterer Forschungsbedarf
In diesem Abschnitt werden zunächst die Forschungsergebnisse der Arbeit zusammengefasst
(Abschnitt 5.1) und kritisch reflektiert (Abschnitt 5.2). Anschließend wird
weiterer Forschungsbedarf zur Unterstützung der Bedarfsanalyse fachlicher Metadaten
in der Praxis vorgestellt (Abschnitt 5.3).
5.1 Zusammenfassung der Dissertation
Gegenstand der vorliegenden Dissertation ist die Bedarfsanalyse für fachliche Metadaten
in Unternehmen. Motiviert durch Herausforderungen in der Praxis bei der Durchführung
entsprechender Projekte und fehlender Unterstützung in der Literatur, werden
kumulativ Modelle erarbeitet, die sich in ein Vorgehensmodell zusammenführen lassen.
Tab. 6 gibt einen Überblick über die neun Beiträge, in welchen Phasen der Bedarfsanalyse
sie Anwendung finden und wo diese in der Dissertation zu finden sind.
Beitrag
Inhalt
Anwendung in der Bedarfsanalyse
Referenz
A.1 Elf Anwendungsgebiete/Domänen
Identifikation Handlungsbe-
Kapitel 6, S. 48
für fachliche Metadadarf
und Identifikation Spon-
A.2 ten
sor
Kapitel 7, S. 53
B
Datenmodell für das Terminologiemanagement
Anwendungsbeispiel bei Skizzierung
der Informationsbedürfnisse
(Phase: Identifikation
Handlungsbedarf)
Kapitel 8, S. 66
C.1 Qualitative und quantitative Kosten-Nutzen-Analyse und Kapitel 9, S. 77
Nutzendimensionen von fachlichen
Identifikation Sponsor
C.2 Metadaten
Kapitel 10, S.
84
D
Hersteller- und implementierungsunabhängiger
Funktionskatalog
für MDMS-Tools
Definition Anforderungen
(Phase: Definition Projektumfang)
Kapitel 11, S. 92
Tab. 6: Zusammenfassung Beiträge der Dissertation

Zusammenfassung, Diskussion und weiterer Forschungsbedarf 43
Bei-
Inhalt
Anwendung in der Bedarfs-
Referenz
trag
analyse
E
Potenziale hinsichtlich der
Keine direkte Anwendung, da
Kapitel 12, S. 102
Nutzerpräferenzen in der
der Beitrag Vorarbeiten für
MSS-Forschung
die Beiträge F und G leistet
F Vier Nutzertypen für MSS Definition Annahmen und
Einschränkungen (Phase: Definition
Projektumfang)
G Situative Auswahl von Endgeräten
für die Nutzung von
MSS
Kapitel 13, S. 121
Kapitel 14, S. 145
Tab. 6: Zusammenfassung Beiträge der Dissertation (fortgesetzt)
5.2 Diskussion der Forschungsergebnisse
Im Folgenden werden die Forschungsergebnisse der Dissertation kritisch reflektiert.
Limitationen und Risiken der einzelnen Beiträge werden dabei nach dem zugrunde
liegenden Forschungsprozess (Abschnitt 1.3) diskutiert.
Phase 1: Problem identification and motivation
Die vorliegende Dissertation zieht in erster Linie empirische Untersuchungen zur Motivation
heran. Dabei wird vorwiegend auf Sekundärliteratur zurückgegriffen und inhaltliche
Lücken durch eigene Untersuchungen ergänzt. In wenigen Fällen sind die
referenzierten Forschungsergebnisse zu einem anderen Zeitpunkt entstanden als die
hier dargestellte Arbeit bzw. setzen einen anderen inhaltlichen Schwerpunkt. Damit
besteht das Risiko, dass der tatsächliche und aktuelle Bedarf in der Praxis nach Unterstützung
bei der Bedarfsanalyse fachlicher Metadaten in Umfang und Form verändert
hat. Um diesem Risiko zu entgegnen, wurden bewußt aktuelle und empirische Untersuchungen
zur Motivation herangezogen, die inhaltlich eine vergleichbare Zielsetzung
verfolgen.
Phase 2: Objectives of a solution
Für die besondere Berücksichtigung von Nutzerpräferenzen wurde in den Beiträgen F
und G, im Gegensatz zur eigentlichen Zielsetzung, fachliche Metadaten zu untersuchen,
der Fokus auf MSS erweitert. Zwar sind in MSS fachliche Metadaten als Teil
implizit berücksichtigt, dennoch besteht das Risiko, dass die identifizierten Nutzertypen
und Präferenzen entweder gar nicht oder zumindest zum Teil nicht auf fachliche

44 Zusammenfassung, Diskussion und weiterer Forschungsbedarf
Metadaten übertragen werden können. Die Forschungsstrategie wurde – wie die folgenden
Ausführungen zeigen werden – entsprechend angepaßt.
Grundsätzlich darf davon ausgegangen werden, dass sich die Nutzergruppen von MSS
zu den Nutzergruppen von fachlichen Metadaten konsistent verhalten. Diese Annahme
liegt in dem Umstand begründet, wie diese Nutzergruppen ermittelt werden. Entweder
werden sie explorativ aus Anforderungen an ein MSS abgeleitet (vgl. Beitrag F, Walstrom
und Wilson [1997] und Seeley und Targett [1999]), dann sind fachliche Metadaten
implizit in der Untersuchung berücksichtigt. Wäre dies nicht der Fall, müsste man
davon ausgehen, dass die Untersuchung nicht alle Anforderungen berücksichtigt und
damit nicht vollständig ist. Oder die Nutzergruppen werden ex ante auf Basis von Modellen
in der Psychologie (z. B. kognitive Stile) beschrieben und hieraus Implikationen
für das MSS abgeleitet. Dann stellt sich die Konsistenzfrage nicht, da dieselben Modelle
für die Untersuchung auf Implikationen für fachliche Metadaten unterstellt werden
dürfen. In der Literatur finden sich einige Beispiele, die genau dies tun, und Nutzergruppen,
die in der MSS-Forschung angewendet wurden, auch für fachliche Metadaten
einsetzen [z. B. Dhaliwal, Benbasat 1996; Fisher, Chengalur-Smith, Ballou
2003; Mao, Benbasat 2000; Shankaranarayanan, Even, Watts 2006].
Beitrag F verfährt bei der Ableitung der Nutzergruppen explorativ auf Basis von vollständigen
Anforderungsprofilen an MSS (Abschnitt 13.3). Die hieraus abgeleiteten
Nutzergruppen erfüllen damit die oben genannte Bedingung und können ebenfalls für
fachliche Metadaten unterstellt werden. Darüber hinaus kann ein weiteres Spezifikum
der Untersuchung ins Feld geführt werden, welches die Annahme der Übertragbarkeit
der Ergebnisse untermauert: Die Umfrage in Beitrag F wurde unter Vorständen durchgeführt.
Dabei ist davon auszugehen, dass oberste Führungskräfte nicht entgegen ihrem
Willen zur Nutzung von MSS bewegt werden können. Dies gilt in vergleichbarer
Form für alle potenziellen Nutzenden von fachlichen Metadaten. Sie können sich hier
organisatorischen Zwängen leicht entziehen, da fachliche Metadaten nicht direkt in
ihre operative Tätigkeit einfließen.
Allerdings sind durch den weiteren Fokus nicht notwendigerweise alle Erkenntnisse
aus den Nutzergruppen auf fachliche Metadaten übertragbar. Von den vier Nutzungsfaktoren,
die in Beitrag F identifiziert wurden, ist voraussichtlich nur der Nutzungsfaktor
Analyseorientierung auf fachliche Metadaten übertragbar. Hingegen sollten die
Erkenntnisse aus Beitrag G zur situativen Wahl von Endgeräten für MSS (und damit
auch den fachlichen Metadaten) voll übertragbar sein, da die Restriktionen hinsichtlich

Zusammenfassung, Diskussion und weiterer Forschungsbedarf 45
Darstellung und Bedienung die Aufbereitung der fachlichen Metadaten gleichermaßen
betreffen.
Phase 3: Design and development
Grundsätzlich wurde das Design der Artefakte in den Einzelbeiträgen mit Personen
aus der Praxis validiert und entsprechend weiterentwickelt. Allein die Validierung des
Designs in Beitrag F wirft eine kritische Frage auf, welche im Rahmen dieser Dissertation
nicht adressiert wurde. So hat sich bei der Umfrage zur Identifizierung von Nutzergruppen
eine überproportionale Anzahl an Vorständen als Analytische Poweruser 12
klassifiziert. Dieses Ergebnis ist im Vergleich zu verwandten Forschungsarbeiten äußerst
überraschend. Zwar lässt es sich mit einen Generationenwechsel in den Führungsetagen
erklären, allerdings steht eine empirische Überprüfung aus.
Phasen 4 und 5: Demonstration and evaluation
Grundsätzlich erfolgt die Demonstration bzw. Evaluation in den gestaltungsorientierten
Beiträgen mit Ausnahmen in Form von Fallbeispielen. Dieses Vorgehen erhöht die
Detailtiefe der gewonnenen Erkenntnisse, die sich in der Regel direkt in Anpassungen
am Design übertragen lassen, geht aber zulasten der Repräsentativität. Damit besteht
das Risiko, dass die entwickelten Modelle nicht in jedem Kontext denselben Nutzen
stiften.
Phase 6: Communication
Zum Zeitpunkt der Entstehung der vorliegenden Dissertation sind einige Beiträge noch
im Begutachtungsprozess und daher noch nicht veröffentlicht worden. Dies betrifft die
Beiträge E und G. Damit besteht das Risiko, dass diese Beiträge ohne Zusatzaufwand,
der den Rahmen der Dissertation sprengen würde, nicht veröffentlicht werden können.
Zum Zwecke der Qualitätssicherung im Vorfeld wurden die einzelnen Beiträge daher
in Ko-Autorenschaft mit erfahrenen Wissenschaftlern entwickelt.
5.3 Weiterer Forschungsbedarf
Der weitere Forschungsbedarf ergibt sich zum einen aus den Risiken und Limitationen,
die ausführlich im vorherigen Abschnitt diskutiert wurden, sowie den möglichen
Anknüpfungspunkten und Ergänzungen zu den vorgestellten Forschungsergebnissen.
Das betrifft zum einen die Beiträge im Einzelnen und zum anderen die Verankerung
der verschiedenen Artefakte in eine Methode zur Bedarfsanalyse fachlicher Metadaten.
12 Diese Gruppe zeichnet sich insbesondere dadurch aus, dass sie auch weiterführende Funktionen von MSS wie
Simulationen und Prognosen selbstständig durchführt.

46 Zusammenfassung, Diskussion und weiterer Forschungsbedarf
Da Letzteres im Rahmen dieser Dissertation keine Gestaltungsarbeit an sich darstellt,
bestehen hier Potenziale in der Demonstration der Anwendbarkeit und der Evaluation
der Nützlichkeit der skizzierten Methode.
Im Hinblick auf die einzelnen Beiträge existieren folgende Potenziale für weitere Forschung.
Beiträge A.1 und A.2: Zunächst könnten die elf Anwendungsgebiete/Domänen
dafür genutzt werden, um Muster in den Informationsbedarfen der Unternehmen zu
erkennen. Mit diesen empirisch erarbeiteten Mustern (Situationen) könnte die Entwicklung
von MDMS situativ gestaltet werden. Darüber hinaus könnte jedes Anwendungsgebiet
für sich bezüglich der Anforderungen an fachliche Metadaten (Viewpoints)
detailliert werden, um eine gesamthafte Lösungskonzeption zu erarbeiten, die
in Projekten nach Bedarf konfiguriert werden könnte.
Beitrag B: Hinsichtlich des Terminologiemanagements gibt es viele Fragen in Bezug
auf die effektive Umsetzung. Wie können diese Metadaten möglichst flexibel in verschiedene
BI-Umgebungen integriert werden Wie sehen entsprechende Rollen und
Berechtigungskonzepte aus, um alle Mitarbeiter in die Pflege des Terminologiebestands
einzubeziehen Mit welchen Mitteln lässt sich die Explosion an neu definierten
Begriffen verhindern, sodass eine Vereinheitlichung der Sprache im Unternehmen erfolgt
Diese und weitere Fragen müssen adressiert werden, um ein entsprechendes Engagement
zum Erfolg zu führen.
Beiträge C.1 und C.2: Mit Blick auf die Kosten-Nutzen-Analyse von fachlichen Metadaten
fehlt es vor allem an der Veröffentlichung detaillierter Fallbeispiele. Zwar bieten
die Nutzendimensionen eine gute Ausgangsbasis, allerdings ist bei der Identifizierung
entsprechender Ertrags- und Kostenhebel immer noch viel Kreativität gefragt. Nach
dem Vorbild des Kreditrisikomanagements könnte man die hieraus gewonnenen Erkenntnisse
bereichsspezifisch systematisieren, um die Aufstellung entsprechender
Analysen weiter zu unterstützen.
Beitrag D: Auf Basis des Funktionskatalogs sollten die Abhängigkeiten zwischen den
einzelnen Komponenten untersucht werden. So könnten mit einem Produktfokus typische
Konfigurationen identifiziert werden (z. B. Funktionen, die für ein Glossar benötigt
werden). Dies würde sowohl die Arbeit in den Unternehmen bei der Definition des
Projektumfangs erleichtern, könnte aber auch bei den entsprechenden Vendoren genutzt
werden, um mit gezielten Lösungen und nicht mit einer generischen Plattform
am Markt aufzutreten.

Zusammenfassung, Diskussion und weiterer Forschungsbedarf 47
Beitrag E: Der Literature Review nennt vier explizite Forschungslücken mit Blick auf
die Berücksichtigung von Nutzerpräferenzen in der Entwicklung von MSS. Erstens die
Untersuchung von Implikationen auf nichtfunktionale Anforderungen und Prinzipien.
Zweitens einen stärkeren Fokus auf konkrete Prinzipien statt reiner Definition von Anforderungen.
Drittens die Bereitstellung eines akzeptierten Modells zur Differenzierung
von Nutzergruppen, wobei weitere Faktoren neben kognitiven Stilen berücksichtigt
werden müssen. Viertens und letztens das gesamthafte Design von MSS für eine
bestimmte Nutzergruppe statt der Untersuchung von einzelnen Systemkomponenten.
Neben diesen Forschungslücken kann der Literature Review ausgeweitet werden, indem
neben wissenschaftlichen Journals auch Konferenzbeiträge und Praktikerjournals
berücksichtigt werden. Besonders mit Blick auf die Forderung nach mehr konkreten
Designempfehlungen sind hierbei neue Erkenntnisse zu erwarten.
Beitrag F: In dieser Arbeit wurden erste Implikationen von Nutzerpräferenzen für die
Nutzerschnittstelle sowie das Auswertungs- und Datenmodell von MSS skizziert.
Durch Prototypen ist die Gestaltungsarbeit weiter auszubauen und die Nützlichkeit
dieses situativen Ansatzes zu evaluieren. Neue Erkenntnisse sind insbesondere im
Hinblick auf geeignete Prognose- und Simulationsfunktionen zu detaillieren.
Beitrag G: Auf Basis der situativen Empfehlung für Endgeräte sollten entsprechende
situative Designempfehlungen für MSS entwickelt werden. So ist es beispielsweise
denkbar, Funktionalitäten im MSS für die Nutzung über ein interaktives Whiteboard
oder ein Mobiltelefon zu optimieren, indem Darstellungsrestriktionen und die jeweilige
Bedienung berücksichtigt werden. Darüber hinaus ist davon auszugehen, dass sich
mit den Endgeräten auch die Anforderungen an den Informationsumfang verändern.
Somit bleibt die Frage offen, welche Auswahl an verfügbaren Informationen in einem
mobilen Kontext eine Rolle spielen und auf welchem Aggregationsgrad diese benötigt
werden. Zuletzt sollte der zu erwartende Anstieg an Endgeräten pro Mitarbeiter auf
den administrativen Aufwand seitens der IT-Organisation untersucht werden. Hier bedarf
es entsprechender Konzepte hinsichtlich der Architektur von MSS, um dieser
Entwicklung effizient zu begegnen.

48 Beitrag A.1
6 Beitrag A.1: Use Cases for Business Metadata – A
Viewpoint-Based Approach to Structuring and Prioritizing
Business Needs
Titel
Autoren
Use Cases for Business Metadata – A Viewpoint-Based Approach to
Structuring and Prioritizing Business Needs
Daniel Stock, Felix Wortmann, Jörg Mayer
Universität St. Gallen, Institut für Wirtschaftsinformatik
Müller-Friedberg-Straße 8, 9000 St. Gallen, Schweiz
{daniel.stock | felix.wortmann | joerg.mayer}@unisg.ch
Publikationsorgan In: Proceedings of Desrist 2010 (2010), S. 546-549
Tab. 7: Bibliografische Angaben zu Beitrag A.1
Business metadata plays a crucial role in increasing the data quality of information
systems. Despite its importance, business metadata is primarily discussed from a technical
perspective, while its business value is scarcely addressed. Therefore, this article
aims at contributing to the further development of existing design approaches by explicitly
accounting for the use cases of business metadata.
Keywords: business metadata, requirements engineering, user acceptance
6.1 Motivation
In recent years, “making better use of information” has gained importance and now
ranks among the top five priorities of IT executives [Luftman, Kempaiah, Rigoni
2009]. This trend is linked to the prevailing significance of Business Intelligence (BI)
where data quality is a crucial factor for the perceived net benefits to the end user
[Wixom, Watson 2001]. In this context business metadata plays an important role in
increasing data quality and, therefore, the acceptance of BI-Systems [Foshay, Mukherjee,
Taylor 2007].
Despite its increasing relevance to practitioners [Schulze et al. 2009], explicit discussions
of the benefits of business metadata and the challenges of implementing respective
solutions remain rare in academic literature [Shankaranarayanan, Even 2004].
This article thus contributes to a structured analysis of business metadata requirements

Beitrag A.1 49
by proposing a framework of potential use cases for business metadata. This framework
can be utilized applying all the advantages inherent in a viewpoint-oriented requirements
engineering approach [Kotonya, Sommerville 1998] to the design of business
metadata systems.
6.2 Conceptual Foundations
6.2.1 Business Metadata
“Metadata is data associated with objects which relieves their potential users of having
full advance knowledge of their existence or characteristics” [Dempsey, Heery 1998].
While business metadata is a sub-category of metadata that is used by the business
side, technical metadata, in contrast, is used by IT. In literature, seven categories of
business metadata can be distinguished [3]: (1) definitional, (2) data quality, (3) navigational,
(4) process, (5) audit, (6) usage, and (7) annotations.
6.2.2 Viewpoint-Oriented Requirements Analysis
A viewpoint is a stakeholder and his or her task-related concerns (requirements) [Kotonya,
Sommerville 1998]. The idea of viewpoint-oriented requirements analysis is to
singling out the concerns to better address the diversity of issues. The Viewpoint-
Oriented Requirements Definition (VORD) approach is illustrated in Abb. 11.
Abstract viewpoint
classes (= use cases)
Document
Process
Identify viewpoint
Document
viewpoint
Analyze
requirements
Specify
requirements
Viewpoints
Documented
viewpoints
Negotiated
requirements
Requirements
specification
Abb. 11: Viewpoint-oriented requirements definition approach [Kotonya, Sommerville
1998]
The definition of a viewpoint is intricately linked to the term “use case”. The greatest
difference is the level of granularity. While a viewpoint describes one stakeholder only,
a use case can describe the interaction of several stakeholders. Therefore, we will

50 Beitrag A.1
use the term “use case” to refer to abstract viewpoint classes (see Abb. 11) which subsume
stakeholders and their respective concerns.
6.3 Derivation of Use Cases for Business Metadata
In practice, three groups of business stakeholders can be made out: data consumers,
data managers, and data producers.
Data consumer: Each data consumer satisfies his data requirements through two general
types of reports: standard and ad-hoc reports. While standard reports anticipate
data requirements upfront and are tailored to a specific role, ad-hoc reports rather address
spontaneous, role independent data requirements.
Therefore, the use cases for standard reports can be categorized according to three different
management levels in a business organization: corporate management (by the
senior management), corporate performance management (by the middle management),
and operational analytics (by the operational management).
Ad-hoc information needs can be either satisfied by each data consumer himself or
through the help of dedicated knowledge workers. Therefore, two additional use cases
can be distinguished: ad-hoc information retrieval (by a data consumer himself) and
advanced analytics (by a knowledge worker).
Data manager: The Data Management Body of Knowledge (DMBOK) names ten
functions of data management in its functional reference model. Since this framework
is a comprehensive list of data management activities within an organization, not all of
them lay in the responsibilities of the business side. Therefore, we list all relevant activities
that name a business role as operational responsible: data governance, data development,
data security management, reference & master data management, and data
quality management.
Data producer: Independently of a specific role, a data producer is responsible for
data entry and maintenance. This comprises all activities that lead to the creation, update,
or deletion of data. In total, eleven use cases could be identified (see Abb. 12).

Beitrag A.1 51
Abb. 12: Framework of use cases for business metadata
6.4 Demonstration and Evaluation
European Universal Bank’s (EUB) first initiative on business metadata was confronted
with much resistance from the business side as no obvious business need could be
seen. In order to make the next advance of business metadata a success, EUB was
seeking for a more business-driven approach. Therefore, we applied our proposed use
case framework in accordance with the presented VORD approach. First, EUB prioritized
the use cases. Second, we exemplary defined and documented the viewpoints.
The surveyed employees of EUB named “data development” as the most relevant for
EUB and, therefore, prime candidate for exemplary viewpoint documentation. In a
collaborative workshop of business and IT, the group identified five relevant stakeholders
and seven activities, which benefit from business metadata.
Activities per stakeholder
Business units
Definitional
Data quality
Navigational
Process
Audit
Usage
Annotations
• Specifying change request √ √ √ √
• Monitoring implementation √
…
Tab. 8: Requirements per activity in use case “data development” (excerpt)

52 Beitrag A.1
For each activity the workshop participants were asked to assess the usefulness of the
seven business metadata categories listed in section 6.2.1 (see Tab. 8).
Subsequently we evaluated the demonstrated approach with the participants of the
workshop. In a focus group we examined design and utility of the proposed model.
Design: The participants challenged the features “completeness” and “level of detail”
of the model. In order to complement the framework they suggested including a use
case “risk management”. Since risk management is a function which holds special significance
in financial institutions, including it as an additional use case would compromise
on the frameworks generality. Concerning the second point, further investigation
is necessary as to whether the use case “advanced analytics” is too abstract because
it subsumes too many distinct functions or whether the notation is not clear
enough.
Utility: The participants were generally very satisfied with the utility of the framework
and the associated viewpoint-oriented approach. They particularly appreciated that the
discussions are concentrated on a business perspective rather than exploring technical
details. Even though this is all in all a very positive evaluation result, it does lack representativeness.
The participants of the focus group were all from the same company
and thus this framework needs further evaluation in different contexts.
6.5 Concluding Remarks
This article has derived a conceptual framework for business metadata use cases. Its
applicability was demonstrated in a banking case and subsequently evaluated within a
focus group. The evaluation is as yet not representative and must be subjected to future
research. Especially the use case “advanced analytics” needs further investigation in
order to comply with the design requirement “level of detail”.

Beitrag A.2 53
7 Beitrag A.2: Use Cases for Business Metadata – A
Viewpoint-Based Approach to Structuring and Prioritizing
Business Needs
Titel
Autoren
Use Cases for Business Metadata – A Viewpoint-Based Approach to
Structuring and Prioritizing Business Needs
Daniel Stock, Felix Wortmann, Jörg Mayer
Universität St. Gallen, Institut für Wirtschaftsinformatik
Müller-Friedberg-Straße 8, 9000 St. Gallen, Schweiz
{daniel.stock | felix.wortmann | joerg.mayer}@unisg.ch
Publikationsorgan In: BIS 2010 Workshops (2010), S. 226-237
Tab. 9: Bibliografische Angaben zu Beitrag A.2
Business metadata plays a crucial role in increasing the data quality of information
systems. Despite its importance, business metadata is primarily discussed from a technical
perspective, while its business value is scarcely addressed. Therefore, this article
aims at contributing to the further development of existing design approaches by explicitly
accounting for the use cases of business metadata. In the course of this article,
a classification of use cases will be developed, which can be utilized when identifying
the respective informational requirements a business metadata system needs to satisfy.
A banking case is presented that demonstrates how this conceptual model has successfully
been applied in practice.
Keywords: business metadata, requirements engineering, user acceptance
7.1 Introduction
7.1.1 Motivation and Objectives
In recent years, the challenge of “making better use of information” has gained importance
and now ranks among the top five priorities of IT executives [Luftman, Kempaiah,
Rigoni 2009: 151-152]. This trend is linked to the prevailing significance of
Business Intelligence (BI), where data quality is a crucial factor for the perceived net
benefits to the end user [Luftman, Kempaiah, Rigoni 2009; Sabherwal, Jeyaraj, Chowa
2006: 1857-1859; Wixom, Watson 2001: 34]. In this context, the scope of data quality

54 Beitrag A.2
is not limited to factual dimensions like data accuracy, completeness, and objectivity,
but also includes individual-related dimensions such as data believability, ease of understanding,
and accessibility [Jarke et al. 2000; Wang 1998; Wang, Strong 1996].
Especially concerning the individual-related dimensions, business metadata plays a
vital role in increasing data quality and, therefore, the acceptance of BI-Systems
[Bucher, Wlk 2008; Foshay 2005; Foshay, Mukherjee, Taylor 2007].
Despite its increasing relevance to practitioners [Schulze et al. 2009], explicit discussions
of the benefits and the challenges of implementing respective solutions remain
rare [Shankaranarayanan, Even 2004; Shankaranarayanan, Even 2006]. Especially the
discussion of benefits of business metadata is generally led on a rather abstract level
[Chengalur-Smith, Ballou, Pazer 1999; Even, Shankaranarayanan, Watts 2006; Fisher,
Chengalur-Smith, Ballou 2003; Foshay, Mukherjee, Taylor 2007; Shankaranarayanan,
Watts 2003]. Foshay et al. [2007], for example, base the positive effect of business
metadata on the overall usage of BI-Systems.
Furthermore, business metadata is, in many cases, treated solely from a technical solution
perspective [Hüner, Otto 2009; Nevo, Wand 2005; Shankaranarayanan, Even
2006]. Shankaranarayanan and Even [2006], for instance, explore the drawbacks of
commercial off-the-shelf products for managing metadata and designing and implementing
metadata solutions. A comprehensive approach, which combines business
requirements on the one hand with the respective design and implementation scenarios
on the other, is missing so far. Existing approaches to metadata systems design lack
specificity since they provide only insufficient guidance to the identification of (business)
metadata requirements and the respective implications for their implementation
[Marco 2000; Melchert 2006; Tannenbaum 2002].
This article thus contributes to a structured analysis of business metadata requirements
by proposing a classification of potential use cases for business metadata. This classification
can be utilized applying all the advantages inherent in a viewpoint-oriented
requirements engineering approach [Darke, Shanks 1996; Kotonya, Sommerville
1998; Leité, Freeman 1991] to the design of business metadata systems. By singling
out the business metadata requirements of the respective stakeholders, each use case
can be examined individually for its business benefits and associated costs of provisioning.
Nevertheless, this approach helps maintaining a business perspective by focusing
on the application of business metadata rather than developing technical solutions
detached from actual business needs.

Beitrag A.2 55
7.1.2 Research Methodology and Article Structure
This article applies the design research paradigm in order to accomplish utility. According
to Hevner et al. [2004] and March and Smith [1995], the outcomes of a construction
process under the design research paradigm can be classified as constructs,
models, methods, and instantiations. Several reference models for the construction
process have been proposed. The most recent, consolidated process model by Peffers
et al. [2006] specifies six phases (ignoring the phase “communication”):
Identify the problem and motivate: We used a full-text keyword literature research
[vom Brocke et al. 2009] to find the relevant literature on business metadata [Benander
et al. 2000; Chengalur-Smith, Ballou, Pazer 1999; Dempsey, Heery 1998; Even, Shankaranarayanan,
Watts 2006; Fisher, Chengalur-Smith, Ballou 2003; Foshay 2005; Foshay,
Mukherjee, Taylor 2007; Hüner, Otto 2009; Jarke et al. 2000; Levine, Siegel
2001; Marco 2000; Müller, Stöhr, Rahm 1999; Niland, Rouse, Stahl 2006; O'Neil
2007; Pipe 1997; Shankaranarayanan, Even 2004; Shankaranarayanan, Even 2006;
Shankaranarayanan, Watts 2003; Shankaranarayanan, Ziad, Wang 2003; Vaduva, Vetterli
2001; West, Hess 2002; Xie et al. 2008] and business metadata systems design
[Hüner, Otto 2009; Marco 2000; Melchert 2006; Nevo, Wand 2005; Shankaranarayanan,
Even 2006; Tannenbaum 2002] to substantiate the missing perspective on the actual
business value in business metadata systems design.
Define objectives of solution: The solution was to be designed to match the guidelines
for model design in March and Smith [March, Smith 1995].
Design and development: We used aggregation in order to develop a classification of
business metadata use cases. We consulted a literature review on widespread concepts
in data processing in a BI environment [Ariyachandra, Watson 2005; Inmon, Strauss,
Neushloss 2008; Kimball, Ross 2002], as well as data consumption [Horváth 2006;
Laudon, Laudon 2006; Mintzberg 1994a], data management [DAMA 2009; Mosley
2008], and data production processes [Ariyachandra, Watson 2005; Inmon, Strauss,
Neushloss 2008; Kimball, Ross 2002] in order to identify the single use cases. It
should be noted that the documentation of the respective use cases is out of scope of
this contribution.
Demonstration: We applied the conceptual model based on the viewpoint-oriented
requirements engineering approach to a specific case so that the applicability of the
model could be demonstrated.

56 Beitrag A.2
Evaluation: Finally, the design and the utility of the proposed classification were evaluated,
first by us through analytical argumentation and then by focus groups in which
interviews were led.
The article is structured as follows. Section 7.2 provides the conceptual foundations.
Section 7.3 will then proceed with the development of a classification for use cases of
business metadata by exploring the distinct stages in data processing. Section 7.4 demonstrates
how this artifact was applied in a banking case and offers an evaluation of
the artifact’s design and utility. Section 7.5 concludes with final remarks.
7.2 Conceptual Foundations
7.2.1 Business Metadata
Even though the literature offers several definitions that are more precise [e.g., Dempsey,
Heery 1998; Even, Shankaranarayanan, Watts 2006; Tannenbaum 2002], “data
about data” has evolved as the most widespread definition of metadata. In order to be
more specific, we will adapt the following definition of Dempsey and Heery [1998]:
“Metadata is data associated with objects which relieves their potential users of having
full advance knowledge of their existence or characteristics” (e.g., a definition, an index,
or a manual). This definition highlights two crucial aspects of metadata. First,
metadata is associated with a certain object, which means it has no meaning by its
own. Therefore derived or aggregated data like descriptive statistics (e.g., mean and
variance) or KPIs (e.g., turnover and earnings) cannot be regarded as metadata.
Second, metadata does not necessarily have to be associated with a single data element,
but can also be associated with a whole set of data (e.g., a report) or a physical
object (e.g., an IT system).
While business metadata is a sub-category of metadata that is used by the business
side, technical metadata in contrast is used by IT [Even, Shankaranarayanan, Watts
2006; Foshay, Mukherjee, Taylor 2007; Schulze et al. 2009; Shankaranarayanan, Even
2004; Tannenbaum 2002]. It should be noted that the two sets are not disjoint. This
means there is metadata that can be regarded business as well as technical relevant
(e.g., descriptions). Seven distinct categories of business metadata can be gleaned from
the literature:
Definitional metadata [Foshay 2005; Foshay, Mukherjee, Taylor 2007; Müller, Stöhr,
Rahm 1999; Niland, Rouse, Stahl 2006; Shankaranarayanan, Even 2004; Shankarana-

Beitrag A.2 57
rayanan, Even 2006; Vaduva, Vetterli 2001; Xie et al. 2008] – addressing the questions:
What do I have and what does it mean
Data quality [Foshay 2005; Foshay, Mukherjee, Taylor 2007; Niland, Rouse, Stahl
2006; Shankaranarayanan, Even 2004; Shankaranarayanan, Even 2006] – addressing
the question: Is the quality of data appropriate for its intended use
Navigational metadata [Foshay 2005; Foshay, Mukherjee, Taylor 2007; Müller, Stöhr,
Rahm 1999; Shankaranarayanan, Even 2004; Shankaranarayanan, Even 2006; Vaduva,
Vetterli 2001; Xie et al. 2008] – addressing the question: Where can I find the data I
need
Process metadata [Foshay 2005; Foshay, Mukherjee, Taylor 2007; Shankaranarayanan,
Even 2004; Shankaranarayanan, Even 2006] – addressing the questions: Where
did this data originate from and what has been done to it
Audit metadata [Foshay 2005; Niland, Rouse, Stahl 2006; Shankaranarayanan, Even
2004; Shankaranarayanan, Even 2006] – addressing the questions: Who owns the data
and who is granted access
Usage metadata [Niland, Rouse, Stahl 2006; Shankaranarayanan, Even 2004; Shankaranarayanan,
Even 2006; Vaduva, Vetterli 2001] – addressing the questions: How frequently
is a specific data set/report requested and what user profiles can be derived
Annotations (semi-structured comments) – Which additional circumstances or information
do I need to consider when reading this data
Even though the category “Annotations” is not mentioned in the examined literature,
many BI and metadata tools provide a functionality to add comments or upload additional
information, for example in the context of a deviation analysis.
7.2.2 Viewpoint-Oriented Requirements Analysis
A requirement is a “condition or capability needed by a user to solve a problem or
achieve an objective” [IEEE 1990]. Requirements engineering involves capturing, analyzing
and decomposing of many ideas, perspectives, and relationships at varying levels
of detail [Kotonya, Sommerville 1998]. Methods based on rigid global schemes
do not adequately deal with the diversity of issues presented by requirements engineering
problems. To remedy this problem, methods based on the notion of viewpoints
have evolved (e.g. Controlled Requirements Expression “CORE” and Viewpoint-
Oriented Requirements Definition “VORD”) [Darke, Shanks 1996; Kotonya, Som-

58 Beitrag A.2
merville 1998; Leité, Freeman 1991]. The general steps in a VORD approach are illustrated
in Abb. 13.
Abstract viewpoint
classes (= use cases)
Document
Process
Identify viewpoint
Document
viewpoint
Analyze
requirements
Specify
requirements
Viewpoints
Documented
viewpoints
Negotiated
requirements
Requirements
specification
Abb. 13: Viewpoint-oriented requirements definition approach [Kotonya, Sommerville
1998]
A viewpoint is a stakeholder and his or her task-related concerns (requirements)
[Darke, Shanks 1996; Kotonya, Sommerville 1998; Leité, Freeman 1991]. The definition
of a viewpoint is thus intricately linked to the term “use case”, which describes
functional requirements from a specific scenario perspective [Eriksson, Penker 2000].
The biggest difference is the level of granularity. While a viewpoint is associated to
one stakeholder only, a use case can describe the interaction of several stakeholders.
Therefore, we will use the term “use case” to refer to abstract viewpoint classes (see
Abb. 13), which subsume stakeholders and their respective concerns regarding a specific
operational scenario. So, the proposed classification can be conceived of as an
overview of abstract viewpoint classes on a business metadata system, which can be
used to identify a company’s relevant viewpoints.
7.3 Derivation of Use Cases for Business Metadata
Regardless of the specific architecture, three phases in data processing within a BI
context can be distinguished: data consumption, data staging, and data production
[Ariyachandra, Watson 2005: 11-13; Inmon, Strauss, Neushloss 2008: 14-21; Kimball,
Ross 2002: 7]. Consequently, on the basis of this threefold categorization, three groups
of business stakeholders can be made out: data consumers, data managers (e.g. data
stewards, business analysts), which ensure that data processing (incl. data staging) runs
efficiently, and data producers. In the following, the three business stakeholder groups
will serve as the fundamental use case categories. In sections 7.3.1-7.3.3, the relevant
use cases in each of these three domains will be derived. It should be noted that the

Beitrag A.2 59
naming of the herein listed use cases does not adhere to common UML practices (e.g.,
containing an active verb) in favor of consistency with the functional areas of a company,
where they typically originate from.
7.3.1 Use Cases in the Data Consumer Domain
Business organizations can be conceptualized as consisting of three different levels:
senior management, middle management, and operational management [Anthony
1965; Laudon, Laudon 2006: 17; Mintzberg 1994a]. While the senior management is
responsible for corporate management (strategic/operational planning and forecasting),
the middle management controls corporate performance management (increasing organizational
performance in order to achieve the goals set by the senior management),
and the operational management monitors the daily activities. These three fields of
duty strongly depend on analytical information and, therefore, constitute use cases,
which can benefit from business metadata.
Each of these groups of data consumers satisfies their data requirements through two
general types of reports: standard and ad-hoc reports [Horváth 2006: 607-608]. Whereas
standard reports anticipate data requirements in advance and are tailored to a specific
role, ad-hoc reports meet spontaneous data requirements. However, data consumers
may not be as familiar with data provided by ad-hoc reports and might thus need
more information to assess its information value. We are, therefore, adding two extra
use cases. First, “ad-hoc information retrieval”, which comprises activities by all data
consumers to satisfy their spontaneous data needs. Second, in case of more sophisticated
ad-hoc analysis, which requires the assistance of a “knowledge worker” [DAMA
2009; Mosley 2008], we will speak of “advanced analytics.”
In total, five data consumer use cases can be distinguished: corporate management
[Laudon, Laudon 2006: 17], corporate performance management [Laudon, Laudon
2006: 17; Nord, Nord 1995], operational management [Laudon, Laudon 2006: 17], adhoc
information retrieval [Horváth 2006: 607-608], and advanced analytics [DAMA
2009; Mosley 2008].
7.3.2 Use Cases in the Data Manager Domain
The Data Management Body of Knowledge (DMBOK) of the Data Management Association
(DAMA) names ten functions of data management in its functional reference
model [DAMA 2009; Mosley 2008]. Since this model provides a comprehensive list
of data management activities within any kind of organization, not all of them fall un-

60 Beitrag A.2
der the responsibility of the business side. Therefore, we only include all the relevant
activities, which state a business role (data steward, knowledge worker, data quality
analyst, and business process analyst) as operationally responsible. Tab. 10 lists the
respective activities per relevant data management function.
Functions
Data governance
Data development
Data security management
Reference & master data
management
Data quality management
DMBOK business responsibilities
Manage and resolve data-related issues
Monitor and ensure regulatory compliance
Communicate, monitor, and enforce conformance with data
policies, standards, procedures, and architecture
Validate information requirements
Prepare for data deployment
Understand data security needs & regulatory requirements
Define data security policy
Define data security standards
Indentify reference data sources and contributors
Define and maintain matching rules
Establish golden records
Define and maintain hierarchies and affiliations
Manage changes to reference and master data
All activities concerning data quality management fall under
the responsibility of the business side
Tab. 10: DAMA DMBOK business responsibilities [DAMA 2009]
7.3.3 Use Cases in the Data Producer Domain
Independently of the specific function, a data producer is responsible for data entry
and maintenance [Ariyachandra, Watson 2005: 11-13; Inmon, Strauss, Neushloss
2008: 14-21; Kimball, Ross 2002: 7]. This includes all activities that lead to the creation,
update, or deletion of a data set. Since the data production process is the source of
several data quality issues (e.g., inconsistencies), business metadata can be a means of
proactive data quality management by providing support and increasing transparency.
The use case “data entry and maintenance” is the only one in the data producer domain.
In total, eleven use cases could be identified, which are listed in Abb. 14.

Beitrag A.2 61
Abb. 14: Classification of use cases for business metadata
7.4 Demonstration and Evaluation
In this section, we will demonstrate the applicability of our conceptual model by
means of a case study at “European Universal Bank” (EUB). Section 7.4.1 will introduce
the initial situation at EUB and section 7.4.2 will give details of how the proposed
classification was applied. Eventually, we will evaluate the design and utility of
our conceptual model according to the criteria of March and Smith [1995] in section
7.4.3.
7.4.1 Initial situation
EUB offers its 15 million customers all the services of a universal bank and considers
Central and Eastern Europe as their home market. EUB started its initiative on business
metadata in early 2008. Primarily driven by the IT department, the focus was laid
on introducing a corporate wiki as a means of encouraging a common and unambiguous
terminology. This effort was confronted with much resistance from the business
side as no obvious business need could be seen.
In order to make the next advance to business metadata a success, EUB was seeking
for a more business-driven approach. Rather than starting again from a certain implementation
scenario, this time the overarching concept of business metadata and its
benefits for the business should be explored.

62 Beitrag A.2
7.4.2 Use Case Approach to Business Metadata Systems Design
As described in the previous section, the IT department of EUB decided to revise their
current approach to business metadata. Therefore, we applied our proposed use case
classification following the presented VORD approach presented above (see Abb. 13).
As a first step, EUB prioritized the use cases in order to focus the analysis on the most
relevant ones (section 7.4.2.1). We then documented in an exemplary fashion the requirements
for the top priority use case in a collaborative workshop (section 7.4.2.2).
7.4.2.1 Use Case Prioritization
The EUB chose two employees of business and two of IT to identify the use cases with
the biggest relevance for EUB. All of them were asked to study a comprehensive set of
use case assessment templates and to provide their personal perspectives on the business
potential and associated costs/burdens of their implementation per use case.
Data consumer Data manager (business side) Data producer
Corporate management
Corporate performance
management
Operational management
Data governance (issue and
compliance management)
Data development
(requirements engineering)
Data security management
Data entry and maintenance
Zero nominations
Four nominations
Ad-hoc information retrieval
Reference & master data
management
Advanced analytics
Data quality management
Abb. 15: EUB’s prioritization of use cases for business metadata
Each template included a high level description of the use case, typical challenges, and
likely business metadata needs to address these challenges. Subsequently, the employees
were asked to name their top three to five use cases and explain the underlying
rationales. Abb. 15 illustrates the collective results. From the given use cases, the EUB
employees identified “data development” as the most relevant for EUB and, therefore,
the prime candidate for exemplary viewpoint documentation.

Beitrag A.2 63
7.4.2.2 Viewpoint Documentation
The use case “data development” was further assessed in a workshop with 13 employees
from EUB’s IT and risk department. Within this group, the use case was broken
down into viewpoints. The group identified five relevant stakeholders and seven
activities which benefit from business metadata.
Activities per stakeholder
Business units
Definitional
Data quality
Navigational
Process
Audit
Usage
Annotations
• Specifying change request √ √ √ √
• Monitoring implementation √
Legal authority
• Monitoring compliance √ √ √
Project manager
• Estimating effort √ √ √ √
IT
• Analyzing impact to the IS landscape √ √ √ √ √ √
Sponsor
• Approving change request √ √ √ √
• Monitoring change request √
Tab. 11: Business metadata requirements per activity in use case “data development”
For each activity, the workshop participants were asked to assess the usefulness of the
seven business metadata categories listed in section 7.2.1 (see Tab. 11). Further discussions
revealed that the workshop participants would value “definitional”,
“process”, and “usage” business metadata the most across all activities. “Definitional”
since almost everybody benefits from it, “lineage” due to unsolved challenges in effort
estimation, and “usage” in order to install a report life cycle management that identifies
unused reports that can be abandoned.

64 Beitrag A.2
7.4.3 Evaluation of Design and Utility
Two aspects of the presented classification of use cases for business metadata is up for
evaluation: its design and its utility. With respect to its design, the classification needs
to fulfill the following requirements: “completeness”, “fidelity with real world phenomena”,
“internal consistency”, “level of detail”, and “robustness” [March, Smith
1995].
Regarding its utility, it needs to demonstrate that it contributes to either effectiveness
and/or efficiency in the design of business metadata systems. Starting with its design,
we argue that our conceptual model is likely to satisfy the requirements “completeness”,
“fidelity with real world phenomena”, “internal consistency” and “robustness”
due to our analytical-deductive approach of aggregating existent and widespread models.
Only for the dimension “level of detail” we cannot argue with our analyticaldeductive
approach, since granularity is a subjective measure and, therefore, has to be
assessed in a specific context.
Statements regarding design (focus on the level of detail)
• Very clearly structured framework
• Missing a use case “risk management”
• Complete list of topics to address/cover
• Use case “advanced analytics” too abstract
Statements regarding utility
• Helps in identifying the business value of business metadata
• Facilitates step-by-step approach instead of rushing too early into technical discussions
• Thrives the identification of business value
• Better understanding of benefits by linking it to roles and activities
• Good to maintain a business perspective
• It will be hard to come up with a quantifiable business case (just not feasible)
Tab. 12: Statements of focus group on design and utility
Furthermore, we evaluated the classification’s design and utility by means of a focus
group with seven employees of EUB, which had participated in the use case prioritization
and viewpoint documentation workshop discussed before (see Tab. 12).
Regarding the design, the participants challenged the features “completeness” and
“level of detail.” In order to complement the classification, they suggested including a
use case “risk management.” Since risk management is a function which holds special

Beitrag A.2 65
significance in financial institutions, including it as an extra use case would compromise
the classification’s generality. Concerning the second point, further investigation
is necessary as to whether the use case “advanced analytics” is too abstract because it
subsumes too many distinct functions or whether the notation is not clear enough.
Concerning the utility, the participants were generally very satisfied with the utility of
the conceptual model and the associated viewpoint-oriented approach. They particularly
appreciated that it focused the discussions are concentrated on a business perspective
rather than exploring technical details. Even though this is all in all a very positive
evaluation result, it does lack representativeness. The participants of the focus group
were all from the same company and thus this conceptual model needs further evaluation
in different contexts to reliably prove its applicability and utility.
7.5 Concluding Remarks
This article has derived a classification for business metadata use cases. The classification
comprises use cases in the data consumer, data management, and data producer
domain. Its applicability was demonstrated in a banking case and subsequently evaluated
within a focus group. The evaluation is not representative and must be subjected
to further research. Especially the use case “advanced analytics” needs further investigation
in order to comply with the design requirement “level of detail.”
In addition, there is potential for future research that builds on the newly developed
classification presented above. First, this conceptual model could be used to derive
information requirement patterns for business metadata to apply situational method
engineering to business metadata systems design. Second, the typical business metadata
requirements per use case could be extended via a representative evaluation which
would pave the way to a stronger alliance between business value and technical implications.

66 Beitrag B
8 Beitrag B: A Data Model for Terminology Management
of Analytical Information
Titel
Autoren
A Data Model for Terminology Management of Analytical Information
Daniel Stock, Philipp Gubler
Universität St. Gallen, Institut für Wirtschaftsinformatik
Müller-Friedberg-Straße 8, 9000 St. Gallen, Schweiz
{daniel.stock | philipp.gubler}@unisg.ch
Publikationsorgan In: Proceedings of European Students Workshop on Information Systems
(2009), S. 1-14
Tab. 13: Bibliografische Angaben zu Beitrag B
Analytical Information Systems (AIS) comprise a widespread set of tools and concepts
to support management in decision making. Despite the high level of technological
and conceptual sophistication, AIS often struggle in practice with data quality challenges.
In particular, ambiguous and inconsistent information contributes to a decrease
in perceived usefulness. This article analyses how these challenges can be overcome
by terminology management and proposes a data model for terminology management
that is tailored to the specifics of analytical information.
Keywords: data quality, terminology management, analytical information systems
8.1 Introduction
8.1.1 Motivation
Data quality is a crucial factor for the success of analytical information systems (AIS)
in terms of perceived net benefits to the user [Sabherwal, Jeyaraj, Chowa 2006: 1857-
1859; Wixom, Watson 2001: 34]. Even though the dimensions that contribute to high
data quality are manifold, unambiguousness and consistency are central elements
[Berson, Dubov 2007; Wand, Wang 1996: 92; Wang, Strong 1996: 14]. Ambiguity
and inconsistencies often arise from vague terminology within and across information
systems leading to misinterpretation and wrongly perceived comparability of data

Beitrag B 67
[Berson, Dubov 2007; Wand, Wang 1996: 92]. The company-wide alignment of terminology
is, therefore, key to the success of AIS [Lehmann 2001: 123].
Cases from practice, which demonstrate the impact of vague terminology management,
are manifold [Auth 2003; Dale 2001; Felber, Budin 1989]. One specific example
comes from the authors’ daily work, where recently a large German bank spent several
weeks on identifying the right measure “full time equivalence” (FTE) detailing of its
organizational structure. Several alignment meetings with the functional units were
needed until the project team discovered that their data was sourced from a different
information system which provided figures excluding exemptions and maternity leave.
This ambiguity of the term “number of FTEs” caused serious delay on a task lying on
the critical paths of a transformation project. This case is in line with a survey conducted
by Forshay et al. [2007]. Even though the importance of accurate definitions
was predominant, the satisfaction level with the provided definitions in their AIS was
rather neutral. A way to address this quality issue is through terminology management
which comprises the planning, steering, maintenance, and organization of terminology
[Auth 2003: 188-189; Lehmann 2001: 123].
Although literature and practice ask for concepts on terminology management, there
are only very few contributions that address this issue. That is why the goal of this article
is twofold: first it provides an overview how terminology management can be
used to identify and solve terminological defects and second it adapts an existing data
model to the characteristics of analytical information. Therefore the article is structured
as follows: section 8.2 sets the theoretical foundations for main terms used
throughout this article. Section 8.3 derives a solution for integrated terminology management
in AIS. Section 8.4 concludes with a critical acclaim of the presented solution
and suggestions for further research.
8.1.2 Research Methodology
Information Systems research is mainly characterized by two paradigms, namely behavioral
science and design science. While behavioral science concentrates on the development
and verification of theories, design science focuses on the development of
solutions for practical problems and, thereby, on accomplishing utility [Hevner et al.
2004: 76; March, Smith 1995: 256]. According to Hevner et al. [2004: 257] and March
and Smith [1995], the outcomes of a construction process under the design science
paradigm are constructs, models, methods, and instantiations. The goal of this article is
to construct a model.

68 Beitrag B
In order to develop the artifacts mentioned before several construction processes are
proposed in literature [Hevner et al. 2004; March, Smith 1995; Peffers et al. 2006;
Rossi, Sein 2003]. The process of March and Smith [1995], that specifies two activities
build and evaluate, is predominant in literature [Hevner et al. 2004]. This article
focuses on the building part. The evaluation is subject to further research.
8.2 Theoretical Foundations
8.2.1 Data Consistency
Within systems theory, information is defined as data within a certain context whereas
data itself has no meaning beyond pure existence [Ackoff 1989; Jung 2006; Price,
Shanks 2005; Wang et al. 1998]. In contrast to this definition, the term data quality has
emerged as measure for design and value of information [Batini, Scannapieco 2006;
Cykana, Paul, Stern 1996; Lee et al. 2006; Wand, Wang 1996; Wang, Strong 1996].
The definition of data quality usually comprises several dimensions of which one of
the most cited is consistency [Wand, Wang 1996: 92]. Even though the definitions of
consistency that can be found in literature vary in scope, consistency primarily focuses
on the semantic correctness of (sets of) information [Batini, Scannapieco 2006: 30-32;
Brüggemann 2008: 101; English 1999: 24].
Within AIS, inconsistencies typically arise during the sourcing and the consumption of
information. Distributed heterogeneous systems, which often dispose of inconsistent
definitions, account for the first [Batini, Scannapieco 2006: 133; Cykana, Paul, Stern
1996: 162; Lee et al. 2006: 80-90], ambiguous and inconsistent terminology for the
latter [Berson, Dubov 2007; Wand, Wang 1996: 92]. Herein terminology comprises a
structured set of terms, where each term is a mapping of an actual data context into
natural language. In general a term is, if not completely specified, subject to subjectivity
of the data receiver. Since this article focuses on inconsistencies due to terminological
defects, in this course data will be considered consistent if the terminology used is
unambiguously associated with the data context.
Within AIS, the context of data can be specified by a measure (e.g., turnover, margin),
which can be aggregated, and one to several aggregation dimensions (e.g., time, customer,
product, and business unit), and an aggregation function (e.g., sum, mean, and
min/max) [Kemper, Mehanna, Unger 2006].

Beitrag B 69
8.2.2 Terminological Defects and Terminology Management
Root causes for difficulties in communication between subjects (but in the broader
sense also between systems and subjects) are specified as terminological defects
[Lehmann 2001: 126]. In general, five categories of terminological defects can be differentiated:
synonyms, homonyms, equipollence, vagueness, and outdated terms
[Lehmann 2001: 2-5; Lehmann, Jaszewski 1999: 127; Ortner 1997; Schwarz, Strauch,
Rowohl 2000: 24-26]:
• Synonyms are two terms that reference the same context. Across or within AIS, this
means that you use different terms to reference the same data. Examples could be:
“turnover” vs. “sales”, “return” vs. “profit.”
• Homonyms are two complete separate contexts that are referenced by the same
term. Across or within AIS, this means that the (perceived) same analysis results
two different values. For the data “annual sales of private customers 2009” two
people would interpret the context differently: fiscal year vs. calendar year, including
or excluding VAT, including or excluding cross-sales.
• Equipollence is a measure for comparability of information value. This means that
information of two terms is interrelated due to overlapping contexts. Basically,
synonyms are extreme values of equipollence, since their contexts are completely
disjoint. Across or within AIS this means that two similar types of analysis result
data with comparable information value. An example would be “return on investment”
and “return on assets.”
• Vagueness is a measure for how unambiguous a term references a certain context.
Homonyms are extreme cases of vagueness, since one single term references to
separate contexts. Across of within AIS, this means that an analysis would result
different results due to a single or several misinterpretations of the measure, aggregation
dimension(s), or aggregation. One example of a typical misleading measure
would be “contribution to profit” since this can include several combinations of fix
and variable costs.
• An outdated term is a term that references different contexts over time. It is rather
similar to a vague term whereas here the influence of time is emphasized. Within
AIS, this would mean that a specific analysis would produce incomparable data
due to varying contexts over time. This is often the case when the aggregation dimensions
change in scope, e.g., the investment banking division subsumed private

70 Beitrag B
wealth management until year 2000 while since 2000 private wealth management
became a separate business unit.
One concept to address these issues is terminology management. Terminology management
comprises the planning, steering, maintenance, and organization of terminology
[Auth 2003: 188-189; Kremer, Kolbe, Brenner 2003: 2-3; Lehmann 2001: 123].
“The resulting tools of terminology management are glossaries and taxonomies (classification
schemes) that serve as the foundation for search, navigation, storage, and
communication services between persons and/or systems” [Kremer, Kolbe, Brenner
2003: 3]. Core element of terminology management is the underlying data model to
specify terms in a consistent way [Auth 2003: 85-87; ISO 1999; Wegener, Auth 2002:
198-200].
8.3 Development of an Extension of a Terminological Data
Model
8.3.1 Existing Terminological Data Models
In literature only very few contributions to terminological data models exist. Our literature
review identified two, the data model of Swiss Re and the data model of the International
Organization of Standardization (ISO) [Auth 2003; ISO 1999; Wegener,
Auth 2002]. While the Swiss Re data model is a focused approach to align companywide
terminology, the latter represents a comprehensive collocation of more than 200
attributes that needs use-case-specific adaptation. Even it is possible to start from both
models to develop a specific data model for terminology management of analytical
information, this article will start from the Swiss Re data model due to the comparable
problem complexity and scope.
As detailed in section 8.2, the inherent quality of terminology management is directly
associated with the power of the underlying data model to solve the listed terminological
defects that lead to data inconsistencies that harm interpretability and comparability
of information. The Swiss Re data model has been designed with this target and has
been successfully tested within practice [Auth 2003; Wegener, Auth 2002]. Within the
Swiss Re data model a term is characterized by its name and its attributes as detailed in
Tab. 14.

Beitrag B 71
Attribute
Code
Definition
Description
owner,
co_owner
valid_from,
valid_to
Content
Presents an automatic generated alphanumeric code
Specifies the meaning in a concise, clear, and comprehensive
way
Details the meaning
References responsible employee(s) for naming and specification
of term
Specifies the validity period
Tab. 14: Attributes of a term in the Swiss Re data model
A term can be categorized in three types: entity (e.g., contract), attribute (e.g., account
number), and attribute value (e.g., active or on hold). Relationships between terms can
be specified as follows:
• Relationship type “composed of”: A term T1 is derived from two terms T2 and T3
(or more). E.g., contribution to profit is composed of the term turnover and the
term variable costs.
• Relationship type “associated with”: A term T1 is always used in association with
term T2. E.g., street is always used in association with address.
• Relationship type “is alias for”: A term T2 is an alias (synonym) for T1. E.g., sales
is a synonym for turnover.
• Relationship types “aggregation”: A term T1 (entity) has the terms T2, T3 as
attributes, the term T3 has T4 to T10 as attribute values.
The entire formal structure of the data model is illustrated in Abb. 16.

72 Beitrag B
associated_with
0..1 0..1
composed_of
0..n
(Business) term
0..n
0..n
code
definition
description
owner, co_owner
valid_from, valid_to
Is_alias_for
0..1
Entity
Attribute
0..1 0..1
Attribute value
0..n
0..n
Abb. 16: Swiss Re data model in UML [Wegener, Auth 2002]
Generally speaking, the Swiss Re data model could be considered complete since it
directly or indirectly addresses all the terminological defects listed in the previous section.
Synonyms are dissolved through an explicit relationship type, homonyms are
identifiable for elimination, and out-dated terms are flagged through time stamps. Less
easy it becomes with vague and equipollent terms. While the model provides some
indications to identify the latter (e.g., terms that are derived from the same set of terms
and at the same time valid for the same period), the prevention of vague terms solely
depends on the information quality of the attribute “description”. Here the data model
provides only very generic guidance which is a tribute to the wide scope of the data
model. Since it is basically developed to document an intra-organizational business
language in its entirety, it consequently fails in further detailing attributes that apply to
all thinkable types of terms.
The Swiss Re addresses this issue by involving the entire staff in the development and
maintenance of an enterprise-wide uniform terminology [Auth 2003; Wegener, Auth
2002]. Therefore, at Swiss Re every employee is entitled to postulate new terms or

Beitrag B 73
submit change requests to existing terms in order to foster a consensus-driven approach.
8.3.2 Proposed Adaptation within AIS Context
In the following section the article will use Swiss Re’s generic data model and provide
adaptations to tailor it for the use of analytical information. In accordance with user
acceptance research, the organizational challenge that goes in hand with a (terminology)
information system is perceived usefulness to achieve adoption [Venkatesh et al.
2003]. Thereby, the perceived usefulness depends to a large extent on the information
quality provided by the terminology database. In line with the discussion of the previous
section, this article will use specialization to increase the information quality.
Therefore, further attributes and relationship types will be defined in order to fully
grasp the characteristics of analytical information. In a second step unnecessary elements
of the data model are eliminated to balance the trade-off between information
content and the consequent model complexity.
According to section 8.2, analytical information is a measure, which can be aggregated
along several dimensions. Therefore, analytical information in general comprises the
following characteristics:
• Measures are embedded into a logical hierarchy where a measure is calculated
from subordinate measures and/or input to superior measures. For example, the
measure “operating income” is the sum of the subordinate measures “interest income”,
“fees”, and “commissions.” In turn it is one determinant to the calculation
of the superior measure “income.” The calculation logic might vary with a certain
use context (e.g., guidelines of the IFRS vs. guidelines of the US GAAP vs. internal
steering logic).
• Analytical information is time dependent and updated on a frequent basis to allow
for comparisons over time. For example, the measure “operating income” is updated
at the end of every quarter of a calendar year.
• Analytical information is often redundant and distributed across an organization.
While it would be desirable to have a “single-point-of-truth” typically a whole set
of AIS that are tailored to specific user groups are in use. For example, in a typical
multinational company each regional unit has its own AIS in use that provides information
that is also provided by a central AIS in a consolidated and aggregated
form.

74 Beitrag B
To acknowledge the characteristics listed above, the data model needs the following
adjustments:
• In addition to the attribute “description” that describes the general meaning (e.g.,
informative value, use cases) the attributes “calculation”, “unit of measure”, and
“update frequency” are introduced to provide more guidance in the specification of
clear terms.
• To specify the source system(s) that provide the measure, a separate entity “AIS” is
introduced. Each AIS comprises at least one measure while each measure in turn
can be part of several AIS.
• In addition to the attribute "valid from, valid to" the relationship type "update" is
introduced to allow for proper version tracking along with the time series of analytical
information stored in the AIS. A new attribute “change” specifies the attributes
or structure that changed to the pre-version.
• In the context of analytical information, the differentiation of the entity “term” into
three categories as proposed by the Swiss Re data model (“entity”, “attribute”, and
“attribute value”) is not necessary and can be disregarded. Each term falls due to
limited scope in the category “attribute.”
• The relationship type “association” can also be disregarded since a measure is typically
self-contained and not limited to the use in association with other measures.
The formal structure of the resulting data model is illustrated in Abb. 17.
0..1
composed_of
Analytical Information System
Measure/Attribute
0..n
1..n
0..n
1..n
code
definition
description
calculation
unit_of_measure
update_frequency
owner, co_owner
valid_from, valid_to, change
0..1
is_alias_for
0..1
0..1
updates
Abb. 17: Adapted data model in UML

Beitrag B 75
Table 2 gives an example of how the information held in this data model could be presented
to the user. Hereby, each referenced term is highlighted in quotes to allow for
browsing functionality (hyperlink). Due to user centricity, some names of the above
detailed attributes and relationship types have been altered to become better understandable,
e.g., the relationship type “is alias for” is represented by “synonyms”.
Operating income (status: active)
Code (Id)
Definition (short description)
Description
Calculation
Unit of measure
Update frequency
Owner
AB31CF1249CAF123
Income from normal business activity
Income from normal business activity, which can be subdivided
for a bank into income from interests, income from fees, and income
from commissions. Other, e.g., income from trade for own
account …
Interest income + fees + commissions
USD millions
Quarterly
Jane Doe (Jane.Doe@somebank.com)
Validity period 8/1/2007 till ---
Changes to preversion
Is based on
Is used in
Synonyms
Source systems
Calculation update to “operating income” (status: deprecated) due
to new requirements of US GAAP
“interest income”, “fees”, and “commissions”
“income”, “result of operations”, …
“operating return”
AIS “xy”, AIS “wz”
Tab. 15: User view of a defined term (example)
8.4 Discussion and Further Research
Within this article two results were presented. First, it was demonstrated how terminological
defects within intra-organizational terminology can be effectively addressed
through terminology management. Second, the underlying data model in the Swiss Re
approach to terminology management has been tailored to the needs within the context
of AIS.
Since this article only covers the first phase “build” of a design science research approach,
evaluation will be needed to testify the usefulness of the derived data model.

76 Beitrag B
Further research could be conducted in the various ways how to integrate terminology
management into AIS to provide better user support. Use cases could include an integrated
glossary function, integrated consistency checks of definitions in analyzing time
series and predefined analysis paths derived from the taxonomy within the terminology.

Beitrag C.1 77
9 Beitrag C.1: Fachliche Metadaten – Kosten-Nutzen-
Analyse
Titel
Autoren
Fachliche Metadaten – Kosten-Nutzen-Analyse
Daniel Stock, Jörg Mayer, Felix Wortmann
Universität St. Gallen, Institut für Wirtschaftsinformatik
Müller-Friedberg-Straße 8, 9000 St. Gallen, Schweiz
{daniel.stock | joerg.mayer | felix.wortmann}@unisg.ch
Publikationsorgan In: BI-Spektrum (2010), Vol. 5, Nr. 2, S. 20-24
Tab. 16: Bibliografische Angaben zu Beitrag C.1
Fachliche Metadaten charakterisieren das Informationsangebot von BI-Systemen. Sie
fördern insbesondere den zielgerichteten Einsatz der bereitgestellten Informationen
und deren bedarfsgerechte Weiterentwicklung. Da der Nutzen fachlicher Metadaten
monetär nur schwer zu quantifizieren ist, wird in diesem Artikel ein pragmatischer
Ansatz für die Kosten-Nutzen-Analyse vorgestellt. Abschließend wird dieses Vorgehen
an einem Beispiel aus der betrieblichen Praxis demonstriert.
Schlüsselwörter: Fachliche Metadaten, Akzeptanz von BI-Systemen, Kosten-Nutzen-
Analyse
9.1 Einleitung
Business Intelligence (BI) ist ein Wachstumsmarkt, der sich mit immer leistungsfähigeren
Systemen an den wachsenden unternehmerischen Anforderungen orientiert.
Technikzentrierte Lösungen führen dabei oft zu mangelnder Akzeptanz von BI-
Systemen bei Führungskräften, sodass sie hinter ihrem erwarteten Potenzial zurückbleiben
[Gluchowski, Kemper 2006]. Neben intuitiven Benutzeroberflächen können
fachliche Metadaten deren Akzeptanz steigern. Als Zusatzinformationen erhöhen sie
die Transparenz über bereitgestellte Informationen und tragen so zu einer besseren
Datenqualität bei [Foshay, Mukherjee, Taylor 2007].
Der vorliegende Beitrag analysiert das Nutzenpotenzial fachlicher Metadaten und
erarbeitet ein Vorgehen für eine pragmatische Kosten-Nutzen-Analyse. Ihre Anwendung
wird anhand eines Fallbeispiels bei einem deutschen Finanzdienstleister demonstriert.

78 Beitrag C.1
9.2 Stand in Wissenschaft und Praxis
Metadaten werden oft als „Daten über Daten“ bezeichnet [Bauer, Günzel 2004]. Im
Rahmen von BI-Systemen beschreiben sie das Angebot und die Eigenschaften der bereitgestellten
Informationen. In Abhängigkeit der Nutzergruppe lassen sich technische
und fachliche Metadaten unterscheiden. Erstere beinhalten typischerweise technischorientierte
Modelle (z.B. APIs, SQL-Befehle oder physische Datenstrukturen), während
Letztere aus einer Anwendersicht das Informationsangebot spezifizieren. Das
können fachliche Definitionen von Kennzahlen im Rahmen eines Glossars sein oder
ein Verzeichnis, das die im Unternehmen verfügbaren Reports themenorientiert strukturiert.
Fachliche Metadaten lassen sich in sieben Kategorien unterteilen, die dem Anwender
auf der Fachseite unterschiedliche Fragen beantworten [Foshay, Mukherjee, Taylor
2007]: Definitionen, Navigation, Aufbereitung, Annotationen, Qualität, Audit und Nutzung.
Tab. 17 fasst diese Kategorien und deren Nutzen für den Anwender zusammen.
Metadaten-Kategorie
Definitionen
Navigation
Aufbereitung
(Processing/Lineage)
Annotationen
Qualität
Audit
Nutzung
Adressierte Fragestellungen und Beispiele
Was sind dies für Daten und was bedeuten sie
Beispiel: Fachliche Definitionen von Kennzahlen im Rahmen eines (zentralen) Business
Glossaries oder (dezentral) in Reporting-Lösungen
Wo lassen sich diese Daten finden In welcher Beziehung stehen die Daten zueinander
Beispiel: Inhaltsverzeichnis im Rahmen eines Reporting-Portals oder semantische
Verlinkung im Rahmen eine Business Glossaries auf verwandte oder verwendete Begriffe
Wo kommen die Daten ursprünglich her Wie sind sie verarbeitet worden
Beispiel: Fachliche Darstellung der ETL-Prozesse oder fachliche Beschreibung von
Transformationen in SQL-Abfragen
Welche Hintergrundinformationen müssen bei der Interpretation einer spezifischen
Dateninstanz berücksichtigt werden
Beispiel: Kommentarfunktion und Datei-Uploads in Reporting-Lösungen
Ist die (derzeitige) Datenqualität für die angedachte Nutzung der Daten ausreichend
Beispiel: Data Quality Management Dashboard oder Qualitätsindikatoren über den
Ladestatus von Kennzahlen in Reporting-Lösungen
Wer ist für die Daten verantwortlich und wer hat Zugriff darauf
Beispiel: Fachliche Rollenbeschreibung in der Zugriffsrechteverwaltung oder Governance-
Framework für Data Stewardship
Wo werden diese Daten gebraucht und wie regelmäßig werden diese Daten (bzw. Reports)
nachgefragt
Beispiel: Nutzerprofile des Reporting-Inventars oder Nachfragestatistik einzelner Reports
9.3 Systematische Beurteilung
Tab. 17: Taxonomie
Die Bereitstellung fachlicher Metadaten ist mit Aufwand (Kosten und Zeit) verbunden
und muss sich nach dem Prinzip der Wirtschaftlichkeit [Zangemeister 1976] durch den

Beitrag C.1 79
erzielten Nutzen rechtfertigen. Damit steht nicht im Fokus, ob die Bereitstellung technisch
machbar ist, sondern ob sie auch wirtschaftlich sinnvoll ist.
Während sich der Aufwand der Bereitstellung recht gut schätzen lässt, ist der Nutzen
oft nur schwer monetär zu quantifizieren. Das liegt darin begründet, dass fachliche
Metadaten ein sehr weitgefasstes Anwendungsgebiet beschreiben und sich nur indirekt
auf Ertrags- und Aufwandhebel im Unternehmen auswirken. Ein pragmatischer Ansatz
sollte daher mit wenig Aufwand die relevanten Nutzendimensionen identifizieren, um
so eine fokussierte Bewertung zu ermöglichen.
Für die Identifikation der relevanten Nutzendimensionen eignet sich eine Nutzwertanalyse
[Zangemeister 1976], die entlang qualitativer Beurteilungskriterien den Handlungsbedarf
in Form eines Soll-Ist-Vergleichs bewertet. Dies dient dann als Ausgangsbasis
für eine monetäre Bewertung entlang quantitativer Beurteilungskriterien. Sollte
sich also aus der Nutzwertanalyse ergeben, dass die Auffindbarkeit der Informationen
von der (weiteren) Bereitstellung fachlicher Metadaten profitieren würde, dann lässt
sich die Investitionsrechnung auf die Quantifizierung der eingesparten Suchkosten einschränken.
Die Herleitung qualitativer und quantitativer Nutzendimensionen erfolgt entlang der
Datenverarbeitung mit ihren drei Stakeholder-Gruppen: Datenproduzenten, Datenmanager
und Datenkonsumenten. Das Ergebnis ist in Abb. 18 zusammengefasst.
Datenproduzent
Daten eingeben
Datenmanager
Daten transformieren
Datenkonsument
Daten nutzen
Qualitative
Nutzendimensionen
• Verständlichkeit
• Nachvollziehbarkeit
• Flexibilität
• Verständlichkeit
• Auffindbarkeit
• Nachvollziehbarkeit
• Qualitätstransparenz
• Compliance-Transparenz
• Nutzungstransparenz
• Auffindbarkeit
• Verständlichkeit
• Interpretierbarkeit
• Glaubwürdigkeit
Quantitative
Nutzendimensionen
(indirekt durch fachliche
Metadaten beeinflusst)
• Weniger Abstimmungsaufwand
(mit Datenkonsument)
• Geringerer Supportaufwand
(Hilfe zur Selbsthilfe)
• Höhere Datenqualität (insb.
Konsistenz und Vollständigkeit)
• Plan: Geringerer Planungsaufwand
durch Wirkungsanalyse und
gezieltere Portfolioentwicklung
• Build: Geringerer Entwicklungsaufwand
durch Wiederverwendung
• Run: Geringerer Betriebsaufwand
durch Outphasing nicht genutzter
Daten/Reports und gezielte
Ursachenanalyse
• Geringere Suchkosten
• Weniger Abstimmungsaufwand
(mit Datenproduzenten)
• Geringerer Supportaufwand
(Hilfe zur Selbsthilfe)
• Bessere Entscheidungen
Abb. 18: Qualitative und quantitative Nutzendimensionen

80 Beitrag C.1
9.3.1 Datenkonsumenten
Metadaten erhöhen die Transparenz über Daten. Aus Konsumentensicht tragen sie
damit zu verschiedenen Aspekten der Datenqualität bei. Die Ergebnisse verschiedener
Studien [Foshay, Mukherjee, Taylor 2007; Shankaranarayanan, Even, Watts 2006]
lassen sich wie folgt zusammenfassen:
• Auffindbarkeit: Navigations-Metadaten vereinfachen das Auffinden von Daten, da
sie das Angebot in einer logischen, transparenten Struktur anordnen. Damit reduzieren
sich für den Endnutzer etwaige Suchkosten.
• Verständlichkeit: Definitionen reduzieren den Effekt terminologischer Defekte
(z.B. Synonyme und Homonyme) und erleichtern so das Verstehen von Daten und
in welchem Kontext sie wie eingesetzt werden. Das reduziert Rückfragen beim Datenproduzenten
und den daraus erwachsenden Abstimmungsaufwand oder den Bedarf
an Support.
• Interpretierbarkeit: Qualitäts-Metadaten können die Interpretierbarkeit von Daten
erhöhen, wenn sie für den jeweiligen Anwendungskontext bewertbar werden. Das
ermöglicht den gezielten Einsatz von Daten und reduziert die Kosten aus den Folgen
von Fehlentscheidungen.
• Glaubwürdigkeit: Aufbereitungs-Metadaten können weiterhin die Glaubwürdigkeit
bereitgestellter Informationen erhöhen, wenn sie dem Endnutzer die Möglichkeit
bieten, die Daten entlang ihrer Verarbeitungskette zurückzuverfolgen. Das gestärkte
Vertrauen in die Daten reduziert Rückfragen beim Datenproduzenten und den
daraus erwachsenden Abstimmungsaufwand.
Neben den oben dargestellten Ursache-Wirkungsbeziehungen lassen sich zusätzlich
noch weitere argumentieren. So können auch Annotationen zur besseren Interpretierbarkeit
und Nutzungs-Metadaten zur Ableitung von Nutzerprofilen für individuelle
Report-Vorschläge beitragen (in Analogie zu Amazon: „Personen, die diesen Report
gelesen haben, haben auch folgende Reports angesehen.“).
9.3.2 Datenmanager
Da Datenmanager fachlich für die BI-Systeme und somit die Bereitstellung bedarfsgerechter
Informationen verantwortlich sind [DAMA 2009], erfahren sie aus fachlichen
Metadaten zunächst denselben Nutzen wie die Datenkonsumenten. Allerdings spielt
die Interpretierbarkeit und Glaubwürdigkeit eine untergeordnete Rolle, da sie die Da-

Beitrag C.1 81
ten selbst nicht einsetzen. Letzteres kann man mit Blick auf Aufbereitungs-Metadaten
eher im Sinne von Nachvollziehbarkeit in Form von Ursache- oder Wirkungsanalysen
verstehen. Zusätzlich erfahren sie aus den Kategorien Qualität, Compliance und Nutzung
direkten Input für den effizienten Betrieb von BI-Systemen:
• Effizientere Planung: Aufbereitungs-Metadaten können die Abhängigkeiten der
Datenflüsse von den Quellsystemen bis hin zum zentralen BI-System darstellen
und ermöglichen damit eine umfassende Impact-Analyse neuer Anforderungen.
• Geringere Entwicklungskosten: Definitionen und Navigations-Metadaten sind eine
Voraussetzung für die Wiederverwendung existierender Daten. Sie ermöglichen
die Identifikation und Bewertung bestehender Daten bei neuen Anforderungen.
• Geringere Supportkosten: Transparenz über die Compliance, Qualität und Nutzung
der Daten in den BI-Systemen ermöglicht eine proaktive Problemidentifikation und
-behebung. Darüber hinaus können über Nutzungs-Metadaten wenig oder gar nicht
genutzte Reports eingestellt oder frühzeitig angepasst werden. Dies trägt zu einem
bedarfsgerechteren Angebot an Daten bei.
9.3.3 Datenproduzenten
Es lässt sich analog zu den Datenkonsumenten argumentieren, dass die Datenproduzenten
von fachlichen Metadaten im Sinne der Verständlichkeit und Nachvollziehbarkeit
profitieren. Zusätzlich geben ihnen Annotationen die Möglichkeit, weitere Informationen
bereitzustellen, um Dateneingaben zu erklären und zu belegen. Das erhöht
für die Datenproduzenten die Flexibilität, ohne dabei die in der Regel beabsichtigte
Standardisierung über vorgegebene Eingabelisten und Menüs aufzuweichen. Dies trägt
dazu bei, dass die Datenproduzenten eine höhere Datenqualität (insbesondere Vollständigkeit
und Konsistenz) erreichen, da sie die Anforderungen besser verstehen und
nachvollziehen können.
9.4 Beispiel: Umsetzung im Kreditrisikomanagement
Das Beispiel beschreibt den Fall eines deutschen Finanzdienstleisters. Hier wurde das
skizzierte Vorgehen für die Kosten-Nutzen-Analyse im Kreditrisikomanagement angewendet.
Die Nutzwertanalyse hat ergeben, dass der Fokus des Projektes auf den Datenkonsumenten
liegen sollte. Vor allem in den Dimensionen Auffindbarkeit und Verständlichkeit
wurde der stärkste Handlungsbedarf identifiziert (siehe Abb. 19), der sich
insbesondere auf Inkonsistenzen in der verwendeten Terminologie zurückführen lässt.

82 Beitrag C.1
Dies beschreibt ein typisches Anwendungsbeispiel für Glossare, die sich eignen, um
definitorische und navigatorische Metadaten zu verwalten und bereitzustellen.
Abb. 19: Auszug Nutzwertanalyse im Kreditrisikomanagement
Auf Basis der Ergebnisse der Nutzwertanalyse wurde der Nutzen eines Glossars mittels
der Stellhebel ‚geringere Suchkosten‘ und ‚bessere Entscheidungen‘ (siehe Abb.
18) quantifiziert. Während ‚geringere Suchkosten‘ direkt bewertbar sind, wurden ‚bessere
Entscheidungen‘ im Rahmen des Kreditrisikomanagements mit ihren Auswirkungen
auf die Ausfallkosten spezifiziert. Diesen Einsparpotenzialen wurden die Kosten
für die Pflege des Glossars gegenüber gestellt. Die Investitionsrechnung ist in Abb. 20
dargestellt.
Da sich dieses Projekt in der Umsetzung befindet, kann noch nicht gesagt werden, ob
sich der erwartete Nutzen wie avisiert einstellen wird. Darüber hinaus wird es schwer
sein, den Effekt auf bessere Entscheidungen in der Kreditvergabe nachzuweisen. Allerdings
zeigen vergleichbare Projekte, dass sich mit dem Einsatz eines Glossars eine
wachsende Standardisierung der Geschäftsterminologie einstellt. Während zu Beginn
die Anzahl der Begriffe im Glossar stetig wächst, stellt sich später eine Reifephase ein,
in der die Begriffe und Definitionen konsolidiert werden.

Beitrag C.1 83
Bessere Entscheidungen in der Kreditvergabe durch einheitliches Begriffsverständnis
Nutzen
Kredite neu (€), p. a.
5.750.000.000
Zeitersparnis bei der Suche nach Informationen
Zahlungsausfälle (%) Reduktion Ausfälle (%)
x x =
0,2
0,5
Ersparnis (€), p. a.
57.500
Betroffene Personen (#)
2% von 1.750
Zeitersparnis (h/#), p. a.
Gehalt (€/h)
x x =
16
50
Ersparnis (€), p. a.
28.000
Datenqualitätsmanager für die Pflege des Glossars (Laufende Kosten)
Kosten
Ressourcenbedarf (FTE)
25%
Gehalt (€/FTE)
x =
60.000
Kosten (€), p. a.
15.000
Ergebnis
Total (€), p.a.
70.500
Abb. 20: Quantifizierung der Nutzenpotenziale eines zentralen Glossars
(Zahlen verfremdet)
Im nächsten Schritt erfolgt die Evaluation möglicher Tools (z.B. ASG-metaGlossary,
SAP metapedia oder IBM InfoSphere Business Glossary) für die Realisierung des
Glossars. Neben der Pflege der fachlichen Metadaten (z.B. durch eine rollenbasierte
Workflow-Unterstützung) steht hierbei vor allem ihre Einbettung in die bestehenden
BI-Systeme im Vordergrund. Für den Endanwender werden die Einträge aus dem
Glossar typischerweise direkt in die Frontend-Systeme integriert und stehen mittels
eines Wizards, einer Mouse-Over-Funktion oder eines abfrage- bzw. reportspezifischen
Verzeichnisses zur Verfügung.
9.5 Zusammenfassung
In diesem Beitrag wurde ein pragmatischer Ansatz für die Kosten-Nutzen-Analyse
fachlicher Metadaten vorgestellt. Mittels einer Nutzwertanalyse entlang qualitativer
Nutzendimensionen wird der Handlungsbedarf im Unternehmen identifiziert und die
Investitionsrechnung auf vielversprechende Stellhebel eingegrenzt. Die Nutzwertanalyse
verhindert damit den unverhältnismäßigen Aufwand einer Quantifizierung
aller möglichen Nutzenpotenziale im Unternehmen. Die Anwendbarkeit dieses Ansatzes
wurde im Rahmen eines Fallbeispiels demonstriert.

84 Beitrag C.2
10 Beitrag C.2: The Value of Business Metadata –
Structuring the Benefits in a Business Intelligence
Context
Titel
Autoren
The Value of Business Metadata – Structuring the Benefits in a Business
Intelligence Context
Daniel Stock, Robert Winter
Universität St. Gallen, Institut für Wirtschaftsinformatik
Müller-Friedberg-Straße 8, 9000 St. Gallen, Schweiz
{daniel.stock | robert.winter}@unisg.ch
Publikationsorgan In: Proceedings of itAIS 2010 (2010), S. 1-8
Tab. 18: Bibliografische Angaben zu Beitrag C.2
Business metadata (BM) plays a crucial role in increasing data quality of information
systems (IS), especially in terms of data believability, ease of understanding, and accessibility.
Despite its importance, BM is primarily discussed from a technical perspective,
while its business value is scarcely addressed. Therefore, this article aims to
contribute to the further development of existing research by providing a conceptual
framework of qualitative and quantitative benefits. A financial service provider case is
presented that demonstrates how this conceptual framework has successfully been applied
in a two-stage cost-benefit analysis.
Keywords: business intelligence, data / information management, business metadata,
cost-benefit analysis
10.1 Introduction
10.1.1 Motivation and Objectives
Over the last years, “making better use of information” gained importance and now
ranks among the top five priorities of IT executives [Luftman, Kempaiah, Rigoni
2009]. This trend is linked to the prevailing significance of Business Intelligence (BI),
where data quality is a crucial factor for the perceived net benefits to the end user
[Luftman, Kempaiah, Rigoni 2009; Sabherwal, Jeyaraj, Chowa 2006: 1857-1859;
Wixom, Watson 2001: 34]. In this context, the scope of data quality is not limited to

Beitrag C.2 85
factual dimensions like data accuracy and completeness, but also addresses individualrelated
dimensions like data believability, ease of understanding, and accessibility
[Jarke et al. 2000; Wang, Strong 1996]. In particular for the individual-related dimensions,
business metadata (BM) plays an important role in increasing data quality and
therefore the acceptance of BI-Systems [Foshay 2005; Foshay, Mukherjee, Taylor
2007].
Despite its increasing relevance for practitioners [Schulze et al. 2009], academic literature
lacks an explicit discussion regarding the benefits of BM [Shankaranarayanan,
Even 2004; Shankaranarayanan, Even 2006]. In general, the discussions of benefits of
BM remain rather abstract. For example, Foshay et al. [2007] substantiate the positive
effect of BM on the overall usage of BI-Systems, Fisher et al. [2003] show that BM
does influence decision outcomes, and Even et al. [2006] examine the impact of BM
on the believability of information sources. Therefore, this article contributes to a
structured analysis of the benefits of BM by proposing a framework of qualitative and
quantitative benefit dimensions. This framework can be applied in a pragmatic costbenefit
analysis of respective BM solutions.
10.1.2 Research Methodology
This article applies the design research paradigm in order to accomplish utility. According
to Hevner et al. [2004] and March and Smith [1995], the outcomes of a construction
process under the design research paradigm can be classified as constructs,
models, methods, and instantiations. Several reference models for this process have
been proposed [e.g., Hevner et al. 2004; March, Smith 1995; Peffers et al. 2006]. The
most recent process of Peffers et al. [2006] specifies six phases: “Identify problem and
motivate”, “define objectives of a solution”, “design and development”, “demonstration”,
“evaluation”, and “communication.” In this article, the “design and development
centered approach” is applied to introduce a conceptual framework (model) of BM
benefits. Therefore, we will demonstrate the applicability and utility of our artifact in a
single case and postpone a comprehensive evaluation to future research.
10.2 Business Metadata
“Data about data” has evolved as the most widespread definition of metadata. Since
this definition is utterly imprecise, we will adopt the definition in Dempsey and Heery
[1998]: “Metadata is data associated with objects which relieves their potential users
of having full advance knowledge of their existence or characteristics.” This definition

86 Beitrag C.2
highlights that the scope of metadata is a matter of perspective, particularly concerning
the “objects” in focus. In the case of a library, any electronic data on books (e.g., title
and publisher) is considered metadata. In the case of BI, the focus lays on data and the
associated systems. Therefore, metadata comprises definitions (e.g., column or row
headers), detailed descriptions, quality indicators (e.g., completeness of data), and
many more.
BM is a subcategory of metadata that is used primarily by the business side, whereas
technical metadata is used by IT [Foshay, Mukherjee, Taylor 2007; Marco 2000; Tannenbaum
2002]. It should be noted, that although the two sets are collectively exhaustive,
they are not disjoint. This means that metadata can imply both business and technical
relevance (e.g., functional descriptions of information services for better business-IT
alignment). In literature seven categories of BM can be distinguished [Foshay,
Mukherjee, Taylor 2007; Müller, Stöhr, Rahm 1999; Shankaranarayanan, Even 2004]:
1. Definitional metadata – What do I have and what does it mean
2. Data quality – Is the quality of data appropriate for its intended use
3. Navigational metadata – Where can I find the data I need
4. Process metadata (also lineage metadata) – Where did this data originate from and
what has been done to it
5. Usage metadata – How frequently is a specific data set/report requested and what
user profiles can be derived
6. Audit metadata – Who owns the data and who is granted access
7. Annotations (semi-structured comments) – Which additional circumstances or information
do I need to consider when reading this data
10.3 Derivation of Benefit Dimensions
The derivation consisted of three successive steps for identifying qualitative and quantitative
benefits of business metadata. First, we screened the body of knowledge to collect
empirically proven or mentioned cause-effect relations. Second, the definitions
and examples for business metadata were used to analytically derive additional benefits.
Finally, the qualitative benefits were explored in specific use cases to identify
quantifiable measures.
In general, the generation and management of metadata serve two purposes. First, metadata
is necessary to minimize the efforts for development and administration of BI-
Systems. Second, it is used to improve the extraction of information from BI-Systems

Beitrag C.2 87
[Bauer, Günzel 2004; Dempsey, Heery 1998; Marco 2000; Vaduva, Vetterli 2001]. In
order to identify the benefit potential of BM, we will examine these two aspects separately.
10.3.1 Development and Administration of BI-Systems
Since the article focuses on BM, we will only include business related aspects of the
development and administration of BI-Systems. The Data Management Association
(DAMA), which published a comprehensive framework for data management in practice,
names three activities the business side is operationally responsible for [DAMA
2009]: requirements engineering, data quality management, and data security management.
Requirements engineering comprises activities to identify, analyze, and define requirements
[DAMA 2009; Darke, Shanks 1996; Leité, Freeman 1991]. Usage metadata
increases the transparency on data usage through access statistics and user profiles
[Shankaranarayanan, Even 2004; Shankaranarayanan, Even 2006; Vaduva, Vetterli
2001]. Definitional, quality, and navigational metadata can be used to increase the level
of data reuse by analyzing the current data inventory for reusable elements [Vaduva,
Vetterli 2001]. Overall, higher transparency on data usage and increased data reuse
results in lower maintenance and development costs by phasing out unused reports and
avoiding redundancy.
Going beyond mere reactive action, data quality management works as a proactive and
preventive concept. This concept is characterized by a continuous cycle consisting of
activities to define, measure, analyze, and improve data quality [DAMA 2009]. Hereby
data quality metadata can be beneficial. On the one hand, the transparency on data
quality is increased through quality indicators. On the other hand, the level of automation
for measuring and improving data quality by defining business rules for data validation
and/or cleansing [Foshay 2005; Foshay, Mukherjee, Taylor 2007; Shankaranarayanan,
Even 2004; Shankaranarayanan, Even 2006; Vaduva, Vetterli 2001]. Additionally,
process metadata can be used to improve the traceability of data issues
through a root cause and impact analysis along the data transformation process [Foshay
2005; Foshay, Mukherjee, Taylor 2007; Shankaranarayanan, Even 2004; Shankaranarayanan,
Even 2006]. Overall, transparency, automation, and traceability contributes
to lower data cleansing costs and better decision making by proactively and efficiently
managing data quality.

88 Beitrag C.2
Data security management comprises activities to develop and execute security policies
in order to meet internal and regulatory requirements [DAMA 2009; Whitman,
Mattord 2007]. Thereby audit metadata increases the transparency on compliance and
ensures the traceability of compliance issues through audit logs [Shankaranarayanan,
Even 2004; Shankaranarayanan, Even 2006]. Overall, transparency and traceability on
compliance reduces regulatory fines by proactively managing privacy protection and
confidentiality.
10.3.2 Extraction of Information from BI-Systems
Within systems theory information is defined as data within a certain context, whereas
data itself has no meaning beyond pure existence [Ackoff 1989]. BM describes the
context of data by providing additional information (e.g., definitions and applied transformation
rules). Therefore, the benefits of BM in the context of information extraction
are closely related to the usage dimensions of data quality: ease of understanding,
interpretability, believability, and accessibility [Wand, Wang 1996; Wang, Strong
1996].
Ease of understanding evaluates to which extend information is clear, readable, and
easily understood. Hereby, definitional metadata can be used to enforce a unique terminology
and communication language within the enterprise by eliminating terminological
defects [Hüner, Otto 2009; Stock, Gubler 2009; Vaduva, Vetterli 2001]. Ease
of understanding, therefore, increases the acceptance and usage of BI-Systems [Foshay
2005; Foshay, Mukherjee, Taylor 2007] and/or results in less need for first-level support.
From an information producer perspective, a unique terminology also increases
the data quality by fostering a consistent data entry.
Interpretability evaluates to which extend information is interpretable in the light of
individual belief, judgment, and circumstances. Especially definitional and quality metadata
is necessary to assess the information’s fit for use [Chengalur-Smith, Ballou,
Pazer 1999; Fisher, Chengalur-Smith, Ballou 2003]. In addition, annotations are a
means of pointing out recent events through structured comments. From an information
producer perspective, annotations also increase the flexibility during information
entry. Better interpretability results in better decision making [Chengalur-Smith, Ballou,
Pazer 1999; Fisher, Chengalur-Smith, Ballou 2003].
Believability evaluates to which degree the information is trustworthy. Since BI-
Systems are often regarded as black boxes, process and quality metadata helps to increase
transparency on the information value chain [Even, Shankaranarayanan, Watts

Beitrag C.2 89
2006; Shankaranarayanan, Watts 2003] by specifying source systems, applied transformation
rules, and quality restrictions. Higher believability not only increases the
acceptance and usage of BI-Systems [Foshay 2005; Foshay, Mukherjee, Taylor 2007],
but also contributes to better decision making [Even, Shankaranarayanan, Watts 2006;
Shankaranarayanan, Watts 2003].
Accessibility evaluates if the information in the BI-System is retrievable and available.
Regarding retrievability, definitional and navigational metadata facilitates the locating
of existent information by providing an index or ontology for the available information
within the BI-Systems [Hüner, Otto 2009]. Additionally, usage metadata can be employed
to derive “related reading” proposals from user profiles. Regarding availability,
usage metadata can be evaluated in order to adapt the availability of information to
consumer demand. Better accessibility results in lower search costs [Hüner, Otto
2009] and/or less need for first-level support. Abb. 21 summarizes the identified qualitative
and quantitative benefits of BM.
Abb. 21: Qualitative and quantitative benefits of BM
10.4 Application within Credit Risk Management
10.4.1 Initial Situation
EUFSP is a European financial services provider, who offers leasing and structured
finance products in Central and Eastern Europe. Lately, EUFSP suffered from several

90 Beitrag C.2
data quality issues due to inconsistencies in definitions of internal and regulatory performance
indicators. This led to bad decisions at management level, high process costs
for information retrieval, and compliance risk. This situation required immediate action,
since the level of inconsistency was likely to increase. Therefore, the implementation
of a central business glossary for fostering a unique company-wide terminology
was evaluated.
10.4.2 Business Case for Central Business Glossary
In order to assess the benefits of a central business glossary, the herein proposed conceptual
framework was applied in a two-stage approach. Since the quantification of
business benefits is difficult in general, we pre-validated the use of a central business
glossary by evaluating it against the qualitative benefit dimensions in the “information
extraction” domain. A Likert-scale was used to assess and compare the as-is situation
along the qualitative benefit dimensions to the expected development after the implementation
of a central business glossary (see Abb. 22).
Abb. 22: Pre-assessment of improvement potential by introducing a business glossary
In step two, EUFSP quantified the benefit dimensions with biggest improvement potential:
“ease of understanding” and “accessibility”. In particular, they estimated cost
savings in information retrieval and better decision making. Since EUFSP’s core business
is evaluating credit risk, better decision making was examined in terms of credit
loss savings. The associated running costs for maintaining a central business glossary
were approximated by the personal costs for a responsible data quality manager. In
total, the cost-benefit analysis identified a potential of EUR 70,500 per year. Abb. 23
summarizes the business case.

Beitrag C.2 91
Abb. 23: Business case for introducing a business glossary at EUFSP
At the end, the introduction of a business glossary at EUFSP was assessed to be beneficial.
The next stage of the project will be the evaluation of tools (e.g., “ASGmetaGlossary”
and “SAP metapedia”) for the implementation. In addition to the maintenance
of the BM (e.g., providing a role-based workflow support) the focus will lay
on the integration into the BI-frontends. Typically, the user will access the metadata
through dedicated wizard functions, a mouse-over function, or report-specific catalogs.
10.5 Discussion and Conclusion
In this article we derived a conceptual framework of qualitative and quantitative benefits
for BM. This framework was applied in a two-stage cost-benefit analysis at a European
financial service provider. The first application of the conceptual framework of
qualitative and quantitative business benefits has proven itself successful. First of all,
the framework structured the discussion of possible benefits of BM in general and of a
central business glossary in particular. And second, the pre-assessment along the qualitative
dimensions focused the quantification of the expected benefits which saved
time in coming up with a recommendation during the economic feasibility study.
Nevertheless, a single case is not enough to prove applicability and usefulness in every
possible situation. Therefore, we will seek for further opportunities to apply the
framework in the herein introduced two-stage approach and discuss our findings with
experts. A promising alliance with a vendor for metadata solutions will assist us in
achieving this.

92 Beitrag D
11 Beitrag D: Functional Map for Business Metadata
Tools
Titel
Autoren
Functional Map for Business Metadata Tools
Daniel Stock
Universität St. Gallen, Institut für Wirtschaftsinformatik
Müller-Friedberg-Straße 8, 9000 St. Gallen, Schweiz
daniel.stock@unisg.ch
Publikationsorgan Arbeitsbericht, Universität St. Gallen, St. Gallen, S. 1-11
Tab. 19: Bibliografische Angaben zu Beitrag D
Business metadata plays a crucial role in increasing the data quality of information
systems. Despite its importance, business metadata projects are predominantly started
as an IT initiative. This usually results in tool-centric solutions without discussing
needed functionality with the business side first. Therefore, this article aims at contributing
to a more issue-driven approach for business metadata by designing a functional
map for business metadata tools. This map abstracts from supplier-specific characteristics
and technical details in order to involve the business side in a fact-based discussion
on business value. A banking case is presented that demonstrates how this conceptual
model has successfully been applied in practice.
Keywords: business metadata, business metadata tools, functional map
11.1 Introduction
11.1.1 Motivation and Objectives
In recent years, the challenge of “making better use of information” has gained importance
and now ranks among the top five priorities of IT executives [Luftman, Kempaiah,
Rigoni 2009: 151-152]. This trend is linked to the prevailing significance of
Business Intelligence (BI), where data quality is a crucial factor for the perceived net
benefits to the end user [Luftman, Kempaiah, Rigoni 2009; Sabherwal, Jeyaraj, Chowa
2006: 1857-1859; Wixom, Watson 2001: 34]. In this context, the scope of data quality
is not limited to factual dimensions like data accuracy, completeness, and objectivity,
but also includes individual-related dimensions such as data believability, ease of un-

Beitrag D 93
derstanding, and accessibility [Jarke et al. 2000; Wang 1998; Wang, Strong 1996].
Especially concerning the individual-related dimensions, business metadata plays a
vital role in increasing data quality and therefore the acceptance of BI-Systems [Bucher,
Wlk 2008; Foshay 2005; Foshay, Mukherjee, Taylor 2007].
Despite its increasing relevance to practitioners, the implementation of business metadata
solutions still lacks behind [Schulze et al. 2009]. The reason for this is that metadata
projects in general tend to end up in technology-centric solutions instead of focusing
actual business demand [Koegler 2010; Marco 2000; Melchert 2006; Triano 2002].
In these cases, the associated costs can easily exceed the expected benefits and the
project is discontinued. This scenario even worsens for business metadata [Dinter
2002; Inmon, O'Neil, Fryman 2008]. On the one hand, the potential of business metadata
and its realization is not fully understood so far [Shankaranarayanan, Even 2004;
Shankaranarayanan, Even 2006] and on the other, hand most business metadata
projects start as IT initiatives without the necessary support and buy-in from the business
side.
This article thus contributes to an issue-driven approach to business metadata by designing
a functional map for business metadata tools. By abstracting from supplierspecific
characteristics and technical details this map provides the basis for aligning
business demand (solution independent) and IT supply upfront.
11.1.2 Research Methodology
This article applies the design research paradigm in order to accomplish utility. According
to Hevner et al. [2004] and March and Smith [1995], the outcomes of a construction
process under the design research paradigm can be classified as constructs,
models, methods, and instantiations. Several reference models for the construction
process have been proposed. This contribution is structured according to the most recent,
consolidated process model by Peffers et al. [2006]:
Identify the problem and motivate: We used a full-text keyword literature research
[vom Brocke et al. 2009] to find the relevant literature on business metadata [Benander
et al. 2000; Chengalur-Smith, Ballou, Pazer 1999; Dempsey, Heery 1998; Even, Shankaranarayanan,
Watts 2006; Fisher, Chengalur-Smith, Ballou 2003; Foshay 2005; Foshay,
Mukherjee, Taylor 2007; Hüner, Otto 2009; Inmon, O'Neil, Fryman 2008; Jarke
et al. 2000; Koegler 2010; Levine, Siegel 2001; Marco 2000; Müller, Stöhr, Rahm
1999; Niland, Rouse, Stahl 2006; O'Neil 2007; Pipe 1997; Shankaranarayanan, Even
2004; Shankaranarayanan, Even 2006; Shankaranarayanan, Watts 2003; Shankarana-

94 Beitrag D
rayanan, Ziad, Wang 2003; Triano 2002; Vaduva, Vetterli 2001; West, Hess 2002; Xie
et al. 2008] and business metadata systems design [Hüner, Otto 2009; Marco 2000;
Melchert 2006; Nevo, Wand 2005; Shankaranarayanan, Even 2006; Tannenbaum
2002] to substantiate the missing alignment of business demand on the one hand and
IT supply on the other hand.
Define objectives of solution: The solution is designed to match the general guidelines
for model design in March and Smith [1995] and in particular to abstract from
supplier-specific characteristics and technical details (comparable to the discussion on
enterprise services design in service-oriented architectures).
Design and development: This article applies a desk research to include all public
available information into the model design. The websites of the most important business
metadata tool vendors form the basis of this effort. The selection of the appropriate
vendors follows the magic quadrant of Gartner on metadata repositories [Blechar
2005]. It should be noted that the holistic documentation of the respective elements in
the functional map is out of scope of this contribution.
Demonstration and Evaluation: We applied the conceptual model in a banking case
so that the applicability of the model could be demonstrated. In the follow-up, we discussed
the model design and utility within a focus group of business metadata experts.
11.2 Business Metadata
Even though the literature offers several definitions that are more precise [e.g., Dempsey,
Heery 1998; Even, Shankaranarayanan, Watts 2006; Tannenbaum 2002], “data
about data” has evolved as the most widespread definition of metadata. In order to be
more specific, we will adapt the following definition of Dempsey and Heery [1998]:
“Metadata is data associated with objects which relieves their potential users of having
full advance knowledge of their existence or characteristics” (e.g., a definition, an index,
or a manual). This definition highlights two crucial aspects of metadata. First,
metadata is associated with a certain object, which means it has no meaning by its
own. Therefore, derived or aggregated data like descriptive statistics (e.g., mean and
variance) or KPIs (e.g., turnover and earnings) cannot be regarded as metadata.
Second, metadata does not necessarily have to be associated with a single data element,
but can also be associated with a whole set of data (e.g., a report) or a physical
object (e.g., an IT system).
While business metadata is a sub-category of metadata that is used by the business
side, technical metadata in contrast is used by IT [Even, Shankaranarayanan, Watts

Beitrag D 95
2006; Foshay, Mukherjee, Taylor 2007; Schulze et al. 2009; Shankaranarayanan, Even
2004; Tannenbaum 2002]. It should be noted that the two sets are not disjoint. This
means there is metadata that can be regarded business as well as technical relevant
(e.g., descriptions). Seven distinct categories of business metadata can be gleaned from
the literature:
1. Definitional metadata [Foshay 2005; Foshay, Mukherjee, Taylor 2007; Müller,
Stöhr, Rahm 1999; Niland, Rouse, Stahl 2006; Shankaranarayanan, Even 2004;
Shankaranarayanan, Even 2006; Vaduva, Vetterli 2001; Xie et al. 2008] – addressing
the questions: What do I have and what does it mean
2. Data quality [Foshay 2005; Foshay, Mukherjee, Taylor 2007; Niland, Rouse, Stahl
2006; Shankaranarayanan, Even 2004; Shankaranarayanan, Even 2006] – addressing
the question: Is the quality of data appropriate for its intended use
3. Navigational metadata [Foshay 2005; Foshay, Mukherjee, Taylor 2007; Müller,
Stöhr, Rahm 1999; Shankaranarayanan, Even 2004; Shankaranarayanan, Even
2006; Vaduva, Vetterli 2001; Xie et al. 2008] – addressing the question: Where
can I find the data I need
4. Process metadata [Foshay 2005; Foshay, Mukherjee, Taylor 2007; Shankaranarayanan,
Even 2004; Shankaranarayanan, Even 2006] – addressing the questions:
Where did this data originate from and what has been done to it
5. Audit metadata [Foshay 2005; Niland, Rouse, Stahl 2006; Shankaranarayanan,
Even 2004; Shankaranarayanan, Even 2006] – addressing the questions: Who
owns the data and who is granted access
6. Usage metadata [Niland, Rouse, Stahl 2006; Shankaranarayanan, Even 2004;
Shankaranarayanan, Even 2006; Vaduva, Vetterli 2001] – addressing the questions:
How frequently is a specific data set/report requested and what user profiles
can be derived
7. Annotations (semi-structured comments) – addressing the questions: Which additional
circumstances or information do I need to consider when reading this data
Even though the category ‘Annotations’ is not mentioned in the examined literature,
many BI and metadata tools provide a functionality to add comments or upload additional
information, for example in the context of a deviation analysis.

96 Beitrag D
11.3 Functional Map
For the desk research, we picked the five best-ranked metadata repository vendors according
to Gartner’s magic quadrant [Blechar 2005]: Allen Systems Group 13 (ASG),
Logic Library 14 , Flashline, Computer Associates 15 (CA), and MetaMatrix 16 . Since
Flashline has been acquired since the issue of the Gartner report, SAP BusinessObjects
17 has been included instead. The basis for the design of the functional map
formed publicly available product information and presentations for the respective
products: ASG-Rochade [Lux 2010] and ASG-metaGlossary [ASG 2009], Repository
Manager (formerly Logidex) [SOA 2009], CA Repository [CA 2008; CA 2009], MetaMatrix
Repository (as part of MetaMatrix Enterprise Data Services Platform) [JBoss
2008], and SAP BusinessObjects Metadata Management [SAP 2008].
To classify the different functionality in these products, the article differentiates three
basic domains: definition/sourcing, integration, and presentation. The first constitutes
the ability to define and/or source metadata (e.g., lineage data from ETL tools). The
second integrates different types of metadata to a new class (e.g., technical lineage
data plus elements of terminology, compliance, and quality management results in
process metadata). The third and last domain groups different techniques in presenting
the business metadata to the user (e.g., within a stand-alone information portal).
11.3.1 Definition/Sourcing Functionality
Definition and sourcing (from other tools) of business metadata is the core ability of a
metadata repository. In this domain, the functionality falls in three different buckets:
syntax, semantic, and administrative. This depends on whether it reveals the formal
relationships of data and/or systems (syntax, e.g., defining the data elements of a term
to be unambiguously described), or maintains the actual content (semantic, e.g., the set
of business terms), or supports the maintenance of the actual content (administrative,
e.g., a workflow management functionality to regularly update and sign off new business
terms).
The group “syntax” comprises two functionalities: data modeling and (technical lineage).
Data modeling is used to describe data in a formal way (on a conceptual, logi-
13 www.asg.com
14 www.logiclibrary.com
15 www.ca.com
16 www.redhat.com/metamatrix
17 www.sap.com

Beitrag D 97
cal, or physical level). For example, a conceptual data model may describe the necessary
entities and relationships within the domain terminology management. Technical
lineage describes the staging and aggregation paths of data from origination to consumption.
Usually, this information can be sourced to some degree automatically from
ETL-Tools. However, it should be noted that technical lineage information is not
suited for the business side. It needs to be integrated with further information (e.g.,
definitions) to be applicable in a business context (section 11.3.2).
The group “semantic” comprises five functionalities: content management, terminology
management, quality management, and compliance management. It should be noted
that some of these terms are usually used in a way broader sense, but these terms here
only refer to metadata-related activities. Within content management especially usage
metadata is defined and applied in order to maintain information assets (e.g., outphase
unused reports). Terminology management on the other hand results in definitional
metadata (e.g., definitions and descriptions in an application context) in order to align
a common business terminology. Quality management especially defines indicators to
assess the value of aggregated information (e.g., in terms of consistency, currency, or
completeness). Compliance management defines business rules to implement and survey
regulatory or internal policies (e.g., data privacy rules). The herein produced metadata
is usually subject to frequent audits.
The last group “administrative” comprises two functionalities: access rights management
and workflow management. Both support the maintenance of the metadata in the
tool. They define on the one hand access right or on the other hand responsibilities.
Both usually produce certain metadata themselves that can be used to audit the business
metadata maintenance processes.
11.3.2 Integration Functionality
Basically, metadata repositories integrate metadata from several sources either in a
single source of truth or a federal manner. But this kind of integration functionality is
not meant in this domain. This domain rather comprises metadata modeling (an abstraction
level above data modeling) functionality which stages existing metadata to
derive new metadata. Business Lineage integrates technical lineage with at least definitional
metadata to address the information needs of the business side for impact and
root cause analyses (process metadata). Ontology defines relations between several
data models and can be used to reveal synonyms, homonyms and other terminological
defects.

98 Beitrag D
11.3.3 Presentation Functionality
In presenting business metadata to the user, basically two different groups of techniques
can be differentiated: stand-alone and front-end integration. While the first constitutes
self-contained solutions that are developed for this sole purpose (e.g., a wikibased
glossary solution), the second subsumes techniques to integrate business metadata
from the repository into reporting tools (e.g. a search functionality to browse definitions
of KPIs). Front-end integration techniques can be further differentiated
whether the business metadata is integrated via dedicated interfaces (hard) or via
background processes that scan the user interface of the reporting tool in order to offer
probably relevant metadata (soft).
Stand-alone techniques subsume glossaries, encyclopedias, dashboards, and (information)
maps. Glossaries and encyclopedias are both used for presenting predominantly
definitional metadata. The difference between the two is that an encyclopedia exceeds
the scope of a glossary. While a glossary provides only a short definition and description
of a term, an encyclopedia reflects a term in differing business contexts. An encyclopedia
thus is much more detailed as a glossary and can even fulfill the requirements
of a manual if maintained respectively. Dashboards are often used to monitor
quality, usage, and compliance metadata on an aggregated level. Especially usage
dashboards are gaining importance these days for lifecycle management of information
assets. Information maps are used to present process metadata (sometimes also referred
to as business lineage). These can also include quality and audit metadata and
form the basis for impact and/or root cause analysis.
Soft front-end integration builds upon GUI-based text recognition. For example, a
background process can scan the text in a SAP user interface and offer definitions for
identified terms in the glossary inventory. This soft integration might be a good and
sustainable workaround for integrating business metadata in proprietary tools which
would require quite some individualistic programming (and respective vendor support)
to implement the needed interfaces instead.
On the contrary, hard front-end integration offers some more sophisticated techniques
to present business metadata direct in a reporting tool: search, wizard, mouse-over,
appendix, and commentary/upload functionality. All of this functionality, which is also
known from web-based solution and MS Office applications, provide business metadata
proactively (e.g., mouse-over) or on request (e.g., search). Typical business metadata
that is integrated that way is definitional metadata, but of course quality, audit,
usage, and process metadata is also thinkable in a more advanced approach.

Beitrag D 99
Abb. 24 summarizes the functionality of business metadata tools across all three domains.
Abb. 24: Overview of business metadata tool functionalities
11.4 Demonstration in Practice
In this section, we will demonstrate the applicability of our conceptual model by
means of a case study at “European Universal Bank” (EUB). Section 11.4.1 will introduce
the initial situation at EUB and section 11.4.2 will give details of how the functional
map was applied. Eventually, we will evaluate the design and utility of our conceptual
model according to the criteria of March and Smith [March, Smith 1995].
11.4.1 Initial situation
EUB offers its 15 million customers all the services of a universal bank and considers
Central and Eastern Europe as their home market. EUB started its initiative on business
metadata in early 2008. Primarily driven by the IT department, the focus was laid
on introducing a corporate wiki as a means of encouraging a common and unambiguous
terminology. This effort was confronted with much resistance from the business
side as the “big picture” and a clear strategy was missing.
In order to make the next advance to business metadata a success, EUB was seeking
for a more business-driven approach. Rather than starting again from a certain implementation
scenario, this time the overarching concept of business metadata and its potential
should be explored with the business side upfront.
11.4.2 Functional Map in Business/IT Alignment
As described in the previous section, the IT department of EUB decided to revise their
current approach to business metadata. The target was to involve the business side upfront
in exploring the potential of business metadata (during demand analysis). There-

100 Beitrag D
fore, we applied our functional map in two ways. At first, we gave an introduction to
the business side what functionalities (or services) business metadata tools are capable
of. For each item of the function map we presented in a black box approach showcases
from a pure user perspective (Abb. 25, abstracting from any implementation and technical
details).
Abb. 25: Screen shots for usage dashboard, quality dashboard, encyclopedia, and
process map
At second (after a cost-benefit analysis, which is out of scope for this contribution), we
used the functional map as a catalog to specify the required functionality. The costbenefit
analysis revealed that EUB would benefit significantly from providing an encyclopedia
within their credit-risk department. This would require business tools
which would provide the functionality “terminology management” to define and maintain
respective business terms, “workflow management” to involve the entire creditrisk
department in the maintenance of the terminology base, and an “encyclopedia” to
access the metadata from a user perspective. While front-end integration (soft or hard)
is certainly desired over time, a stand-alone approach is a no-regret move in order to
pilot the metadata solution.
11.4.3 Takeaways from Single-Case Evaluation
After the application of the functional map at EUB, we discussed the utility of our
conceptual model within a focus group of people that participated in the business me-

Beitrag D 101
tadata initiative. The focus group comprised a balanced selection of people from the
business and the IT side in order to embrace both perspectives.
In terms of alignment, the functional map helped the business side to get an overview
on the topic of business metadata in a way they could relate it to their own business
concerns. By abstracting from product characteristics and technical details, it was easy
for them to follow without needing to worry how a possible solution might be implemented.
The technical representatives on the other hand valued the structure of the
functional map the most, because it helped them to present their ideas from a business
perspective without tying themselves up in technical discussions. After narrowing
down the scope of a business metadata solution to the required functionality, they were
better prepared for entering discussions on vendor selection and technical implementation
and integration issues. All in all, the functional map contributed to conjoint approach
that will save time and result in agreement.
Even though this is all in all a very positive evaluation result, it does lack representativeness.
The participants of the focus group were all from the same company and thus
this conceptual model needs further evaluation in different contexts to reliably prove
its applicability and utility.
11.5 Concluding Remarks
This article has designed a functional map for business metadata tools. This map comprises
functionality to define/source, integrate, and present business metadata. Its applicability
was demonstrated in a banking case and subsequently evaluated within a
focus group of people that participated in the business metadata initiative. While the
first evaluation results are promising, they lack representativeness and must be subjected
to further research. Therefore, this functional map needs to be applied in further
cases with differing contexts.
In addition, there is potential for future research that builds upon the herein presented
conceptual map. Firstly, one could survey the interrelations of the items in the map to
reveal typical configurations (e.g., the implementation of a business glossary). Secondly,
the functional map needs to be integrated into a holistic approach for a business
metadata demand analysis (including issue identification and cost-benefit analysis).
The latter is part of our research agenda and will be developed subsequently.

102 Beitrag E
12 Beitrag E: User Preferences in MSS Design –
State of the Art and Proposal of a Research Agenda
Titel User Preferences in MSS Design –
State of the Art and Proposal of a Research Agenda
Autoren
Daniel Stock, Robert Winter, Jörg Mayer
Universität St. Gallen, Institut für Wirtschaftsinformatik
Müller-Friedberg-Straße 8, 9000 St. Gallen, Schweiz
{daniel.stock | robert.winter | joerg.mayer}@unisg.ch
Publikationsorgan Arbeitsbericht, Universität St. Gallen, St. Gallen, S. 1-26
Tab. 20: Bibliografische Angaben zu Beitrag E
The case of Apple clearly demonstrates that in systems design, understanding users
and their preferences for interacting with technology is key. Such awareness of user
needs is particularly relevant in the field of management support systems (MSS),
where predominantly task-driven design often fails to succeed. While this topic received
much attention in the 1970s and 1980s, it remains as current as ever. This article
identifies research potential in the field of user segmentation and its implications
for MSS design. In particular, there is a need for (1) examining the effects of user
groups with distinct preferences on how systems are constructed and (2) moving from
pure requirements orientation to more differentiated constructional considerations.
These and further findings are the result of a systematic literature analysis. By conceptualizing
the existing body of knowledge, this article proposes a research agenda for
user-centric MSS.
Keywords: systems engineering, management support systems, user group preferences
12.1 Introduction
In the scientific literature, a long list of terms has been coined to classify systems
whose fundamental purpose is the IT-based support of managerial decision making.
The terms “management support systems” (MSS) [Clark Jr, Jones, Armstrong Curtis
2007] and “decision support systems” (DSS) [Arnott, Pervan 2008] were promoted to
encompass this broad class of systems. Since the evolution of DSS suggests a specific

Beitrag E 103
concept that started off to complement management information systems (MIS) and
was further developed by the concept of executive information systems (EIS), we will
refer to our subject of study as MSS [Power 2008]. The meaning of MSS goes back to
the work of Scott Morton [1984] and can be used as a generic term for DSS, EIS,
knowledge management systems (KMS), and business intelligence (BI) [Clark Jr,
Jones, Armstrong Curtis 2007].
Ideally, MSS design conforms to the requirements of all potential users. But confronted
with limited resources, MSS designers need to balance standardization (“onesize-fits-all”)
and adaptivity. In analogy to situational method engineering or to reference
modeling [Becker, Delfmann, Knackstedt 2007; Bucher et al. 2007; Gregor,
Jones 2007], MSS designers need to identify the optimum partitioning of requirements
to design solution. Yet in current requirements engineering practices, user segmentation
is primarily task-related (the needs of different roles) and disregards user preferences
[Darke, Shanks 1996; Kotonya 1999; Kotonya, Sommerville 1998; Leité,
Freeman 1991]. As a consequence, technology-centric solutions often fail to address
users’ needs [Gluchowski, Kemper 2006; Kemper, Pedell 2008; Pettey, Stevens 2010;
Raskino, Lopez 2008].
As early as 1979, Zmud [1979] echoes several authors by claiming that “individual
differences do exert a major force in determining MSS success.” However, this field of
research was not free of criticism. Only a few years later, Huber [1983] presented a
disillusioning stock taking of the research which took the wind out of its sails for many
years to come. Even Huber did not query the influence of preferences on MSS design,
he argued the effectiveness, rationality, and necessity of this research: too many individual
characteristics need to be considered, users should be better educated instead,
and future MSS might be completely configurable by the user anyway. Findings from
the last decades invalidate Huber’s line of argumentation. Firstly, the research on technology
acceptance clearly proves that user perception is predominant in system success
[Davis 1989; Venkatesh, Davis 2000; Venkatesh et al. 2003]. While training and
change management certainly influence a user’s mindset, their powers are limited
where system usage is voluntarily. In contrast to ERP systems, for MSS usually alternatives
for information gathering, analysis, and presentation exist. Secondly, MSS today
are flexible to some degree, but customization still requires the skills of a power
user or a subject expert. Even if flexibility and adaptation mechanisms continue to mature,
this necessity is unlikely to change. Thirdly, it is not the goal to develop individual
solutions that take into account all preferences a user might have. Instead, a limited

104 Beitrag E
set of user groups should be identified that share distinct characteristics so that adaptivity
can be provided at reasonable complexity (costs). In summary, this suggests that
designers of MSS ignore user preferences at their peril.
In order to pave the way for more user-centric MSS design, this article examines the
existing body of knowledge and suggests directions for future research. It is structured
as follows: in section 12.2, we introduce a conceptual framework for user-centric MSS
design. In section 12.3, we reflect on the existing body of knowledge and discuss our
findings. Conclusions follow in section 12.4.
12.2 Structuring Requirements for Management Support
Systems Design
In the course of our literature research, we examined systems design from the perspective
of two different disciplines. First, we looked at the requirements classification approach
used in requirements engineering (RE, section 12.2.1). Second, we used findings
from enterprise engineering (EE, section 12.2.2) to move from requirements to
specification by design. These findings are synthesized into a conceptual framework
(section 12.2.3).
12.2.1 Requirements Engineering
RE is a subdiscipline of systems and software engineering concerned with determining
the goals, functions, and constraints of hardware and software systems [Laplante
2009]. At this juncture, requirements can be defined as prerequisites, conditions, or
capabilities needed by users (individuals or systems) to solve a problem or achieve an
objective [IEEE 1990]. Separating demand (business) and supply (IT), some commentators
suggest that requirements should always be a statement of “what” a system
should do rather than “how” it should do it [Kotonya, Sommerville 1998]. But this
view is too simplistic in practice, since the fact that a system must be compatible with
its environment limits design freedom [Dietz 2007; Kotonya, Sommerville 1998].
Therefore, “requirements invariably contain a mixture of problem information, statements
of systems behavior and properties and design/manufacturing constraints” [Kotonya,
Sommerville 1998].
It is common to distinguish between functional and non-functional requirements [e.g.,
IFPUG 2010; Kotonya, Sommerville 1998; Landes, Studer 1995; Paech, Kerkow
2004; van Lamsweerde 2001]. While consensus exists regarding the meaning of “functional
requirements,” the rich set of definitions for non-functional requirements vary in

Beitrag E 105
scope [Glinz 2007]. Functional requirements define “what” the system should or must
do [Paech, Kerkow 2004; Robertson, Robertson 2006; Sommerville 2010] – a requirement
is “a function that a system (...) must be able to perform” [IEEE 1990].
More specifically, a function describes inputs (stimuli) and outputs (responses) and the
behavioral relationship between them [Davis 1993; Dietz 2007; IFPUG 2010]. Examples
of functional requirements could be role-based access rights or an overview of net
sales with drill-down functionality into different products, regions, and most important
customers.
Non-functional requirements, in contrast, define how well the IS performs within the
given environment as it fulfills its function [Paech, Kerkow 2004; Robertson, Robertson
2006; van Lamsweerde 2001]. These requirements thus comprise properties and
characteristics under which the system must operate. Disagreement exists in the literature
as to whether or not these characteristics include constraints to the system behavior
observable by users [Glinz 2007]. We will include all properties or characteristics
visible to users, as not doing so would imply, for example, that the requirement “response
time” would be functional in nature. Such a result is counterintuitive to the
proposition that everything not functional is per se “non-functional” and that functions
define “what” systems do. In addition to “response time”, typical examples of nonfunctional
requirements are “reliability” and “scalability” [cf. Boehm 1978; Chung,
Sampaio de Prado Leite 2009; Grady, Caswell 1987].
12.2.2 Enterprise Engineering
EE is a discipline within systems engineering that aims toward purposeful, theorybased
design and implementation of enterprises from an engineering perspective [Dietz
2006; Hoogervorst 2009; Saenz et al. 2009]. Therefore, the central aspect of EE is
accomplishing the transition from requirements to specification by design. Specification
by design may seem to closely resemble the overarching objective of RE, but entails
a difference in focus that becomes obvious when we understand the meaning of
the term “specification” in the EE context.

106 Beitrag E
Abb. 26: Requirements taxonomy
In RE, a specification is a formal document synthesizing all demand-side requirements
that have been collected, validated, and approved. This document forms the basis for
the solution design. Within EE, in turn, the specification is the result of the design
phase [Dietz 2007]. Therefore, the specification in EE includes not only requirements
from a user perspective, but also constraints to the solution design from the supplier
perspective. These constraints, which result from the supplier’s architecture, are called
“principles” [Dietz 2007; IEEE 2000; Stelzer 2009]. Like requirements, principles can
be either functional or non-functional. “Standardized dialogs” and “multilingual interfaces”
are examples of functional principles, while “service-oriented architecture” and
“client-server architecture with thin clients” are exemplary non-functional principles.
Abb. 26 compares the differing perspectives of RE and EE.

Beitrag E 107
12.2.3 Classification Scheme
Both disciplines thus distinguish between functional and non-functional requirements
that define demands from the user perspective. These sets of requirements form the
basis for the subsequent design phase. Here, EE explicitly incorporates a supplier
perspective by considering the architectural principles (functional and non-functional)
that limit the solution space. In addition, EE explicitly breaks the design process into
two stages. In the functional design phase, functional requirements and functional
principles are transformed into functional specifications (black box, “usage” model).
In the constructional phase, the black box model is transformed into constructional
specifications (white box model). In addition to fulfilling functional requirements and
principles, the white box model also fulfills constructional requirements and principles
[Dietz 2006; Dietz 2007; Hoogervorst 2009].
It can be argued that user preferences have an impact on requirements as well as principles.
Therefore, we will continue to apply this distinction to the articles that exist on
this topic. Firstly, we look at specific user segmentation techniques that can be applied
to identify heterogeneous user groups. Secondly, we look at articles that identify distinct
user groups (e.g., those of men vs. women or novices vs. experts). Such user
groups are often based on the previously mentioned segmentation techniques (e.g.,
they build on the different cognitive styles identified for men and for women). Next,
we identify articles that derive implications for functional or non-functional MSS design
requirements – for example, by examining the implications of cultural background
on information needs. And finally, we identify articles that derive implications
for design principles. An article about adapting the interface and architecture of an
MSS tool for a senior executive who travels a lot would be an example. Abb. 27 illustrates
our classification scheme.

108 Beitrag E
Abb. 27: Classification scheme

Beitrag E 109
12.3 Literature Analysis
We start by introducing our search strategy [vom Brocke et al. 2009] in subsection
12.3.1 and systemize our findings in subsection 12.3.2. Afterwards, we discuss the
existing body of knowledge in subsection 12.3.3.
12.3.1 Source Selection
Following the recommendations of Webster and Watson [2002], our literature analysis
targeted leading information systems research (ISR) outlets. We selected ten journals
based on the catalog provided by the London School of Economics (LSE) [Willcocks,
Whitley, Avgerou 2008]. We consider this catalog to be particularly appropriate for
our purposes, since it incorporates not only mainstream IS journals, but also those focusing
on the social study of IS. We chose five journals of each set, namely: MIS
Quarterly (MISQ), Information Systems Research (ISR), Information & Management
(I&M), Journal of Management Information Systems (JMIS), Decision Support Systems
(DSS), European Journal of Information Systems (EJIS), Information & Organization
(I&O), Information Systems Journal (ISJ), Journal of Organizational and End-
User Computing (JOEUC), and Journal of Information Technology (JIT). Our keyword
search resulted in 292 articles, of which we found 19 to be relevant. Applying a
backward search, we increased the number of relevant studies to 25 (see Tab. 21).

110 Beitrag E
No. Title Source 18
1 Physician acceptance of information technologies: Role of perceived
threat to professional autonomy [Walter, Lopez 2008]
2 Strategic decision making and support systems: Comparing American,
Japanese, and Chinese management [Martinsons, Davison 2007]
3 EIS adoption, use, and impact: The executive perspective [Elam, Leidner
1995]
4 Affect and acceptance: Examining the effects of positive mood on the
technology acceptance model [Djamasbi, Strong, Dishaw 2010]
5 Gender and DSS design: The research implications [Powell, Johnson
1995]
DSS
DSS
DSS
DSS
DSS
6a
What does it take for successful executive information systems [Rainer,
Watson 1995]
DSS
6b Determinates of EIS acceptance [Young, Watson 1995] I&M
7 Decision support for the administrative man: A prototype DSS case [Sena,
Olson 1996]
EJIS
8 Business drive and national achievement [McClelland 1962] HBR
9 Presenting uncertainty in expert systems: An issue in information portrayal
[Lamberti, Wallace 1987]
10 A cross-cultural analysis of the end user computing satisfaction instrument:
A multi-group invariance analysis [Deng et al. 2008]
11 Cognitive style may mitigate the impact of communication mode [Barkhi
2002]
12 Patterns of senior executives’ personal use of computers [Seeley, Targett
1999]
I&M
I&M
I&M
I&M
Tab. 21: Relevant articles for literature analysis
18 Harvard Business Review (HBR), Journal of Economic Behavior & Organization (JEBO), Leadership & Organizational
Development Journal (LODJ), Management Science (MS), Review of Educational Research (RER).

Beitrag E 111
No. Title Source
13 An examination of executive information system (EIS) users [Walstrom,
Wilson 1997]
14 The use and effects of knowledge-based system explanations: Theoretical
foundations and a framework for empirical evaluation [Dhaliwal, Benbasat
1996]
15 The impact of experience and time on the use of data quality information
in decision making [Fisher, Chengalur-Smith, Ballou 2003]
I&M
ISR
ISR
16 A model of decision making under bound rationality [Wall 1993] JEBO
17 Individual differences and decision making using various levels of aggregation
of information [Lederer, Smith 1988]
18 The use of explanations in knowledge-based systems: Cognitive perspective
and a process-tracing analysis [Mao, Benbasat 2000]
JMIS
JMIS
19a Decision styles – A perspective [Rowe, Boulgarides 1983] LODJ
19b Managerial decision making: A guide to successful business decisions
[Rowe, Boulgarides 1992]
Book
20 Evaluating MIS design principles [Nutt 1986] MISQ
21 Chartjunk or goldgraph Effects of presentation objectives and content
desirability on information presentation [Tractinsky, Meyer 1999]
22 Searching and scanning: How executives obtain information from executive
information systems [Vandenbosch, Huff 1997]
MISQ
MISQ
23a
The effectiveness of the cognitive-style constraint in implementing operations
research proposals [Huysmans 1970a]
MS
23b The implementation of operations research [Huysmans 1970b]
24 Field-dependent and field-independent cognitive styles and their educational
implications [Witkin et al. 1977]
Book
RER
25 Introduction to type [Myers 1976] Book
Tab. 21 : Relevant articles for literature analysis (cont’d)

112 Beitrag E
12.3.2 Literature Systemization
User segmentation: Most of the techniques presented here have their roots in psychology
and deal with an individual’s cognitive style. Although we are aware that other
techniques exist, we limited our scope to those that have been applied in ISR.
One of the most popular and widespread methods in research and practice is the
Myers-Briggs Type Indicator (MBTI) [Myers 1976]. This personality assessment is
based on the work of Jung [1959] and classifies an individual’s personality along four
dichotomies: attitude, perceiving function, judging function, and lifestyle. With respect
to decision support and decision making, the perceiving and judging functions are of
particular interest. For the first, a person tends to either trust the data and facts at hand
(sensing type) or seek for a broader context in which to understand the data (intuition
type). In terms of judging function, in turn, a person tends to either judge a situation
from a detached point using logical reasoning (thinking type) or by associating him- or
herself with the situation, including balancing the needs of those involved (feeling
type). An individual’s preference within each dimension is identified using a questionnaire
that asks the subject to choose intuitively from two answers for each question.
Related to the judging functions within MBTI is Witkin’s concept of field-dependence
and field- independence [Witkin et al. 1977]. Field-dependent individuals perceive
data in their context as a whole and are less attentive to detail (low analytical). Fieldindependent
people perceive data items independent of their context, paying much
more attention to details (high analytical). Thomas [1987] provides empirical evidence
that field-dependency is strongly related to MBTI’s feeling type and fieldindependency
to MBTI’s thinking type. The individual’s preference for one or the other
is tested via pairs of simple and complex figures. The subject is asked to find the
simple figure within the complex figure within a given time.
Another one-dimensional measure of a person’s decision style is Huysmans’s distinction
between the analytical and heuristic approach [Huysmans 1970a; Huysmans
1970b]. Individuals with a preference for the analytical style seek causal relationships
to identify an optimal solution to a problem, usually ignoring factors that cannot be
quantified. In contrast, individuals with a preference for a heuristic style include qualitative
factors in their model development (e.g., past experience, intuition, and unqualified
feelings). Huysmans uses independent judges to assess his subjects’ personalities
based on observations of them solving analytical puzzles and business cases [Huysmans
1970b].

Beitrag E 113
A two-dimensional classification of decision styles is provided by Rowe and Boulgarides
[1983]. According to an individual’s values (task- vs. people-oriented) and his or
her cognitive complexity (tolerance for ambiguity vs. a need for structure) four different
styles are differentiated: analytical, conceptual, directive, and behavioral. Individuals
with an analytic preference enjoy solving problems and use careful analysis (and
have a corresponding need for challenges). Individuals with a conceptual preference
are achievement-oriented and initiate new ideas (need for recognition). Individuals
with a directive preference expect results and follow their intuition (need for power).
Individuals with a behavioral preference are supportive and use limited data (need for
affiliation). The personality assessment is based on a sequence of questions that allows
the subject to assign scores, depending on how the subject sees himself or herself, to
four predefined answers each [Rowe, Boulgarides 1992].
Martinsons and Davis relate the work from Rowe and Boulgarides to the typology of
need developed by McClelland [Martinsons, Davison 2007]. McClelland [1962] proposed
that behavior is motivated by either a need for achievement (tolerance for ambiguity)
or for affiliation (need for structure). Both needs can be satisfied either intrinsically
(task-oriented) or extrinsically (people-oriented). The need for achievement is
measured by assessing a subject’s interpretation of a set of pictures (showing typical
work-life situations). The achievement score rises with every example of achievementorientation
in the subject’s description.
User groups: The articles discussed here either identify differentiating characteristics
that have an impact on MSS use and adoption (e.g., gender) or develop a typical profile
for a certain user group (e.g., senior executives). A user profile is defined as set of
directly observable user characteristics (e.g., American women) and the associated
behavior. The first set of articles identifies differentiating characteristics. Powell and
Johnson [1995] review the existing body of knowledge to argue that gender has an
effect on cognitive style and, therefore, should be considered when designing MSS.
Djamasbi et al. [2010] identify positive mood as an important factor in MSS adoption.
Since mood, unlike emotion, is within an organization’s control, this insight could also
have an impact on MSS design. Deng et al. [2008] identify cultural differences in the
level of MSS user satisfaction. Therefore, the MSS design needs to account for cultural
background. Tractinsky and Meyer [1999] claim that an MSS user is not only in a
receiving but also a presenting role. Consequently, they demonstrate that a user’s objective
(facilitating decision making or maintaining an impression) has an impact on
the preferred interface design. Finally, several authors demonstrate that a user’s level

114 Beitrag E
of expertise has an effect of MSS usage: Dhaliwal and Benbasat [1996], Fisher et al.
[2003], Lederer and Smith [1988], and Mao and Benbasat [2000].
Each article in the second set develops a profile for a certain user group. Walter and
Lopez [2008] argue from previous literature that physicians are rather atypical MSS
users. Empirically, they demonstrate that “ease of use” is less important to physicians
and is allaying their fears of a “perceived threat to professional autonomy.” Comparably,
Young and Watson [1995] and Rainer and Watson [1995] argue that executives (in
contrast to managers in general) are also not typical MSS users. They demonstrate
that “ease of use” has no significant effect on executives’ acceptance of MSS and derive
critical success factors for this user group, such as previous computer experience,
systems flexibility (resulting in low development times), and the level of efficiency
gains in day-to-day work. In particular, Walstrom and Wilson derived [1997] three
user types for executives: converts, pacesetters, and analyzers. The first group uses
MSS to improve information access; the second uses MSS to improve communication
and performance monitoring; and the third uses MSS to solve problems. Martinsons
and Davison [2007] examine the different decision styles of American, Japanese, and
Chinese managers. Built on the classification scheme introduced by Rowe and Boulgarides,
above, they provide evidence that Chinese business leaders are generally more
directive than their Japanese and American counterparts. Americans tend to be the
least directive, but more analytical than their Asian colleagues. Japanese business
leaders, in turn, tend to be more behavioral than American and Chinese managers. Seeley
and Targett [1999] identify four patterns of executive computer use: steady-state
users, growing users, born-again users, and declining users. Although there are indications
that certain MBTI types or age groups are more likely to exhibit particular patterns,
the study fails to really identify the event that leads an individual to move from
one group to another. Vandenbosch and Huff [1997] show that most executives do not
use MSS to search for information. This means executives see MSS as a chance to
gain faster access to information they have always used. Wall [1993] profiles the general
decision maker, assuming Simon’s [1955] concept of bounded rationality. He derives
eight statements on what Sena and Olson [1996] term the “administrative man”:
1) Decision making is dominated by the effects of complexity on the limited abilities
of humans to process large amounts of information. Thus, information processing
tends to be parsimonious, and solutions are simple-minded. 2) New solutions are synthesized
by modifying the currently implemented one; so search is local. 3) Alternatives
are considered one at a time, so search is sequential. 4) The search for a new and
better solution is undertaken only when it is deemed necessary. 5) A satisfaction-based

Beitrag E 115
mode is used when searching; the first solution that is “good enough” is implemented.
6) Goals are stated in terms of aspirations, which are formed by adaptation and learning
from experience. 7) Search strategies are developed on the basis of learning and
adaptation through experience. 8) The attention the decision maker pays to the environment
is the product of learning and adaptation, driven by experience.
Functional requirements: The articles discussed here derive functional requirements
for MSS design for one of the user profiles specified above. Martinsons and Davis
[2007] draw implications for the predominant decision style in America, Japan, and
China. They conclude that Chinese business leaders, given their preference for social
hierarchies and top-down control, will consider using MSS only to support routine decision
making or informal personal reporting. This preference differs fundamentally
from that of American business leaders for quantitative reasoning even in complex
situations. Therefore, American business leaders need MSS that codify valuable information.
Japanese business leaders also tend to apply systematic online reporting.
Their preference for behavioral decision making indicates that they value verbal over
textual cues. MSS must, therefore, effectively transmit verbal cues by integrating, for
example, built-in cameras and multimedia messaging as smartphones do.
These findings partially contradict an untested proposition of Elam and Leidner
[1995]. Based on a literature review, they conclude that those executives whose decision
styles are analytical or directive will adopt and use MSS to a greater extent than
those whose decision styles are conceptual or behavioral. This view suggests that
Chinese business leaders (directive) would use MSS to a greater extent than their colleagues
from Japan (behavioral) – something Martinsons and Davis had proven to be
wrong. An additional proposition suggests that executives who feel under pressure to
make decisions quickly will adopt and use MSS to a greater extent than executives
who do not perceive time pressure. Although this view is in line with general assumption
that decision makers using MSS are more efficient, it has not yet been verified.
Barkhi [2002] examines the impact of cognitive style (MBTI type) on preferred communication
mode. He proves that a face-to-computer communication mode results in a
decrease in trust for individuals with a feeling preference in decision making. Therefore,
MSS design needs to provide functionalities that support personal or quasipersonal
interaction. This can be related to the findings of Martinsons and Davis that
Japanese business leaders with a people orientation prefer verbal clues to textual ones.
Dhaliwal and Benbasat [1996] and Mao and Benbasat [2000] examine the different
explanation needs of novices and experts from MSS that provide decision recommen-

116 Beitrag E
dations. Dhaliwal and Benbasat found that novices tend to make greater use of “feedforward”
explanations (non-case specific, generalized information on the input cues
for decision making), while experts make greater use of “cognitive feedback” (casespecific
information that explains the outcome of an analysis). Regarding explanations
of the “cognitive feedback” type, Mao and Benbasat further show that novices need
“reasoning-trace” explanations (how) more than “justification” (why). The latter, in
turn, is more useful to experts who have better developed heuristic abilities than novices
and, therefore, might want to challenge the reasoning of the MSS rather than just
understand what input variables have been considered.
In a comparable manner, Fisher et al. [2003] explain why experts tend to use data
quality information more than novices do. He too states experts have better heuristic
skills and can adapt their decisions to them. Lederer and Smith [1988] conclude that
novice users prefer a lower level of aggregation than experts do. Reconciling both
needs could result in an aggregated overview with a drill-down functionality attached.
Optionally, the system could remember the preferred entry point of the MSS user.
Walstrom and Wilson [1997] define typical functionalities most likely to be used by
the three different types of executives (converts, pacesetters, and analyzers). In their
need to perform their tasks more efficiently, converts use MSS to access predefined
reports, sources outside the company, company news, and the latest updates on key
performance indicators. Analyzers, in turn, will use the MSS primarily to perform
analysis of data that was not previously available. Finally, pacesetters use the functionalities
employed by the other groups and make extensive use of electronic communication
capabilities.
Finally, Nutt [1986] tested the impact of user profiles on information requirements in
MSS design. He finds no evidence that either cognitive style (information preferences
as measured with MBTI, tolerance for ambiguity, and risk preferences) or user characteristics
(age and experience) have a significant impact. In fact, he states that the only
differences in executives’ information needs are task-related. This conclusion is contradictory
to all the other research presented above. Since Nutt’s article dates from
1986, it can be assumed that the research methodologies have advanced since that
time.
Functional principles: These articles develop concrete principles for MSS interface
design. Tractinsky and Meyer [1999] derive different functional principles depending
on the objectives of MSS users from a presenting perspective. They conclude that if the
reports in the MSS are used to aid decisions (for oneself or in preparation for others),

Beitrag E 117
the interface should be restricted to 2D bars and figures to not distract from the content.
However, if the reports in the MSS are used to maintain an impression in front of
others, the interface should apply 2.5D and 3D bars and figures.
Lamberti and Wallace [1987] design different types of user interfaces for portraying
uncertainty in an MSS for the military (DART – identifying critical targets in a realtime
environment). Based on the dimensions of field-dependence/field-independence
and systematic/heuristic decision style, they develop four screen setups that use different
colors, symbols, graphics, and numeric displays.
Sena and Olson [1996] design an MSS to support the typical manager, termed the
“administrative man”. They argue that, given our bounded rationality, MSS should
improve the managers’ mental models and modeling capacity by 1) expanding their
narrow task focus towards an understanding of problems in a more global organizational
view, 2) providing help to better master uncertainty, 3) increasing understanding
of appropriate levels of information search and exchange, and 4) increasing learning
from and about primary decision problems. The authors, therefore, introduce a systems
model to structure problems graphically; attach appropriate information to a map in the
form of uncertainty estimates, experiences, future estimates or any suitable comments;
and visualize connections or causalities across the individual’s problem space.
Non-functional requirements and constructional principles: None of the surveyed articles
considered implications of cognitive style on non-functional requirements or
constructional principles. Abb. 28 summarizes the results of the literature analysis.
Studies which relate to more than only one component of the classification scheme
appear more than once.

118 Beitrag E
Abb. 28: Results of literature analysis

Beitrag E 119
12.3.3 Discussion
Looking at Abb. 28, the first issue that becomes apparent is that none of the articles
analyzed here examines the effect of user preferences on non-functional requirements
and on constructional principles of MSS design (e.g., flexibility and usability). Two
possible explanations exist for this finding: either the scientific community does not
regard such research to be fruitful, or this research has not yet made its way into the
major ISR outlets. Although we cannot rule out first option, we would argue against it.
A simple example proving that user preferences do impact the constructional perspective
of a system comes from a major consulting firm. When this company rolled out a
new tool to track time and expenses, they failed to consider the working style of their
consultants. Since confidentiality concerns prevent the consultants from working for
their clients during travel, trips provide them with the perfect opportunity to catch up
with administrative tasks. Unfortunately, the new tool required a working Internet
connection to operate, which limited its accessibility during travel. While this example
does not originate from the MSS field, we are confident that similar analogies exist.
The second issue that becomes apparent when looking at Abb. 28 is the dominance of
studies that address requirements identification over those that address concrete IS
modeling and design. This imbalance could be due to the fact that design principles are
often broader in scope and, therefore, more difficult to verify with a comparable level
of rigor. In order to contribute to better MSS design, requirements identification will
not suffice. It needs to be complemented by constructional modeling and design principles
to create innovative artifacts. It is likely that practitioner outlets, which are not
included in our current sample, include further inputs. We will expand our literature
analysis to include practitioner journals in a planned extension of this study.
The third issue is a dominant focus on cognitive style (perception and decision making).
A minority of contributions considered further factors as seniority, mood, and
objectives in user segmentation. We believe that additional factors might be relevant
as well (e.g., experience in the current task and working style). In the previous consultancy
example, it was not cognitive style or one of the other user characteristics mentioned
before that had an impact on the required system design, but rather working
style. We think the entire research field would benefit from a consistent understanding
of distinct user characteristics documented in a catalog that integrates the existing
body of knowledge and includes such further aspects.

120 Beitrag E
Finally, the implications identified for functional requirements tend to focus narrowly
on specific functionalities, such as explanations, data quality information, or quantitative
and qualitative information. We think it would be more beneficial to provide a
commonly accepted model for MSS functionalities (comparably to Walstrom and Wilson
[1997]) to integrate user-specific requirements accordingly and identify further
research potential.
12.4 Summary of Findings
This study conducted a literature analysis in order to systemize and synthesize the current
body of knowledge in the field of user-centric MSS development. This analysis
identified a number of potential areas for future research: (1) examining the effect of
user preferences on constructional requirements and principles for MSS design, (2)
increasing focus on concrete design principles rather than just requirements identification,
(3) providing a commonly accepted definition of relevant user groups and associated
preferences, and (4) increasing the focus on developing comprehensive models
of functionalities for a limited set of user groups. The analysis also shows that potential
exists to improve this review by expanding the range of literature examined – by
adding conference proceedings and especially practitioner journals.
Our own future research will be twofold. On the one hand, we will improve the literature
analysis as discussed. On the other hand, we will contribute to improved MSS
design by identifying executive user groups that places greater emphasis on working
style. To do so, we will analyze an empirical study that was recently conducted to explore
executives’ individual preferences in leveraging MSS and synthesize the findings
to a set of distinct user groups.

Beitrag F 121
13 Beitrag F: Nutzertypen für die situative FIS-Gestaltung:
Ergebnisse einer empirischen Untersuchung
Titel
Autoren
Nutzertypen für die situative FIS-Gestaltung: Ergebnisse einer
empirischen Untersuchung
Jörg Mayer, Daniel Stock
Universität St. Gallen, Institut für Wirtschaftsinformatik
Müller-Friedberg-Straße 8, 9000 St. Gallen, Schweiz
{joerg.mayer | daniel.stock}@unisg.ch
Publikationsorgan Zu erscheinen in: Proceedings of WI 2011 (2011)
Tab. 22: Bibliografische Angaben zu Beitrag F
Der Erfolg von Informationssystemen (IS) hängt maßgeblich von der Wahrnehmung
ihrer Nützlichkeit durch die Anwender ab. Das ist insbesondere dann der Fall, wenn
sie sich aufgrund ihrer Stellung im Unternehmen organisatorischen Zwängen entziehen
können. Führungsinformationssysteme (FIS) am Arbeitsstil oberster Führungskräfte
auszurichten, ist daher eine maßgebliche Erfolgsdeterminante. Ein „one-sizefits-all“-Ansatz
ist insbesondere bei dieser Nutzergruppe wenig Erfolg versprechend.
Aber auch eine durchgängige Individualisierung ist aus Effizienz- und Konsistenzgründen
nicht sinnvoll. In diesem Artikel werden daher aufgrund der Ergebnisse
einer empirischen Untersuchung vier Nutzertypen von Vorständen definiert. Sie unterscheiden
sich hinsichtlich ihrer Anforderungen an FIS zum Teil erheblich und stellen
so eine geeignete Basis für Adaptionsmechanismen dar, die eine situative Anpassung
generischer Artefakte zur Entwicklung spezifischer FIS erlauben.
Schlüsselwörter: Führungsinformationssysteme, Nutzertypen, situative Problemanalyse
und Artefaktgestaltung
13.1 Einführung
Es gibt vielfältige Definitionen für Führungsinformationssysteme (FIS) [Rainer, Watson
1995], dennoch können zwei Charakteristika herausgestellt werden: Erstens, FIS
sind am Gesamtunternehmen, insbesondere dessen Fortschritt zur Erreichung der Unternehmensziele,
ausgerichtet [Kelly 1988]. Zweitens, FIS sollen auch technikunerfahrenen
Führungskräften helfen, durch Informationen zu navigieren, die auch aus ver-

122 Beitrag F
schiedenen Datenquellen stammen können [Nord, Nord 1995]. Die Systemhandhabung
sollte dabei direkt und einfach sein [Young, Watson 1995].
Je höher sich Führungskräfte in der Organisation wiederfinden, desto individueller
dürfte ihr Arbeitsstil ausgeprägt sein [Millet, Mawhinney 1992]. Der vorliegende Beitrag
konzentriert sich auf eine FIS-Ausprägung für oberste Führungskräfte. Wir nennen
sie Unternehmenssteuerungssysteme, um deren Ausrichtung an der gesamtunternehmerischen
Aufgabe dieser Führungskräfte zu verdeutlichen.
Im Vergleich zu anderen Informationssystemen (IS) im Unternehmen generieren die
exponierten Nutzer von Unternehmenssteuerungssystemen mit ihrem meist stark ausgeprägten
individuellen Arbeitsstil eine weite Spanne von Anforderungen [Elam,
Leidner 1995]. Ein „one-size-fits-all“-Ansatz ist daher nicht zielführend. Allerdings ist
ihre durchgängige Individualisierung unter Effizienzgesichtspunkten ebenfalls nicht
sinnvoll. Es muss daher eine Balance gefunden werden, die eine Adaption an wenige,
aber wesentliche Unterschiede im Nutzerverhalten erlaubt.
In Analogie zum situativen Methoden-Engineering (SME) und der situativen Referenzmodellierung
[Becker, Delfmann, Knackstedt 2007; Bucher et al. 2007; Gregor,
Jones 2007], muss der Entwickler das Optimum an unterschiedlichen Anforderungsprofilen
(Problemklassen) identifizieren, die durch die Lösung unterstützt werden sollen.
Im Anforderungsmanagement (AM) leiten sich diese Profile aus den Rollen der
Nutzer ab [Darke, Shanks 1996; Kotonya, Sommerville 1998; Leité, Freeman 1991].
Dabei werden subjektive Anforderungen und Präferenzen vernachlässigt. Als Konsequenz
beklagen viele Führungskräfte, trotz entsprechender Priorisierung von FIS in
den Unternehmen [Gartner 2008; Gartner 2009; Gartner 2010], auch heute noch deren
mangelnde Relevanz [Gluchowski, Kemper 2006; Wixom, Watson 2010].
Zwei Gründe sprechen dafür, sich aktuell mit Unternehmenssteuerungssystemen zu
beschäftigen. Zum einen sind jüngere Führungskräfte mittlerweile mit IS aufgewachsen
und haben eine zunehmend positive Einstellung zur IT, die aber mit höheren Anforderungen
einhergeht. Zum anderen hat sich die IT hinsichtlich ihrer Anwenderorientierung
weiterentwickelt. Data Warehouses sind als Plattform für analytische
Auswertungen etabliert [March, Hevner 2007] und intuitivere Nutzerschnittstellen
(„Frontends“), insbesondere aber auch neue Endgeräte, unterstützen die zunehmend
eigenständige Systemhandhabung durch die Führungskräfte selbst.
Zmud bekräftigte bereits 1979 mehrere Autoren mit der Aussage, dass „individual differences
do exert a major force in determining EIS success“ [Zmud 1979]. Nur wenige

Beitrag F 123
Jahre später übte Huber [Huber 1983] jedoch eine Fundamentalkritik, die diese Forschung
nachhaltig hemmte. Auch wenn er nicht den Einfluss individueller Anforderungen
auf das FIS-Design bestritt, so zweifelte er an der Effektivität, dem Sinn
und der Notwendigkeit dieser Forschung. Zu viele individuelle Charakteristika müssten
berücksichtigt werden, sodass es vorteilhafter wäre, Führungskräfte besser auszubilden.
Darüber hinaus sei davon auszugehen, dass in Zukunft FIS ohnehin völlig
flexibel und anpassbar werden.
Aus heutiger Sicht lässt sich dieser Standpunkt nicht aufrechterhalten: (1) Die IS-
Akzeptanzforschung hat belegt, dass die Wahrnehmung eines Nutzers entscheidend für
den Erfolg von IS ist [Davis 1989; Venkatesh, Davis 2000; Venkatesh et al. 2003].
Dies gilt vor allem dann, wenn sie sich, so wie die Mitglieder der Unternehmensleitung,
organisatorischen Zwängen entziehen können. (2) FIS sind heutzutage sicherlich
flexibler, aber es braucht weiterhin Experten, um grundlegende Änderungen wie eine
neue Datenstruktur vorzunehmen. (3) Es ist nicht das Ziel, jedem Mitglied der Unternehmensleitung
eine Individuallösung bereitzustellen. Es geht vielmehr darum, eine
begrenzte Anzahl an Nutzertypen zu identifizieren, sodass sich Anpassbarkeit zu vertretbaren
Kosten realisieren lässt. Hieraus leitet sich die Zielsetzung der Arbeit ab: Es
ist eine Typisierung oberster Führungskräfte zu erarbeiten. Sie soll helfen, situative
Empfehlungen für die Gestaltung von Unternehmenssteuerungssystemen zu fundieren.
Der Beitrag gliedert sich wie folgt: Nach der Einführung zur situativen IT-
Unterstützung oberster Führungskräfte werden verwandte Ansätze dargelegt (Abschnitt
13.2). Der Charakterisierung unserer empirischen Untersuchung im Financial
Times „Europe 500“ Report (Abschnitt 13.3) folgt die Konsolidierung maßgeblicher
Anforderungen an Unternehmenssteuerungssysteme mit Hilfe einer Faktoren- und
Clusteranalyse (Abschnitt 13.4). Das Ergebnis konzentriert sich in sogenannten Nutzungsfaktoren
und ihren idealtypischen Ausprägungen. Danach werden reale, das heißt
aus den Ergebnissen der empirischen Untersuchung abgeleitete Nutzertypen vorgestellt.
Wir unterscheiden dabei ein Zwei- und ein Vier-Klassen-Modell (Abschnitt 13.5).
Es folgen erste situative Anpassungsmechanismen für Unternehmenssteuerungssysteme
und die Reflektion des eigenen Vorgehens (Abschnitt 13.6). Ihre eigentliche Gestaltung
ist Teil weitergehender Forschungsarbeiten. Der Beitrag endet mit einer Zusammenfassung
und gibt einen Ausblick auf nächste Forschungsschritte.

124 Beitrag F
13.2 Grundlagen
13.2.1 Situative IS-Gestaltung
Die gestaltungsorientierte Forschung der Wirtschaftsinformatik (WI) ist auf die Entwicklung
nützlicher Artefakte ausgerichtet, die Probleme im Zusammenhang mit IS
lösen [23]: Konstrukte, Modelle, Methoden und Instanziierungen [Hevner et al. 2004;
March, Smith 1995]. Für deren Gestaltung spielt der Kontingenzansatz eine immer
größere Rolle. Dies schlägt sich im situativen Methoden-Engineering sowie der Referenzmodellierung
nieder [z. B. Becker, Delfmann, Knackstedt 2007; Bucher et al.
2007; Gregor, Jones 2007; vom Brocke, Buddendick 2006]. Dabei werden generische
Artefakte für unterschiedliche Problemklassen adaptierbar gemacht, um der immer
größer werdenden Komplexität an Gestaltungsanforderungen Rechnung zu tragen.
Situative Ansätze sind nicht neu und wurden zuerst in der Organisationstheorie aufgegriffen.
Nach Fiedler [z. B. Fiedler 1964; Kieser, Kubicek 1992] gibt es nicht den
einen Weg („one-size-fits-all“), um ein Unternehmen zu leiten, da viele interne und
externe Faktoren berücksichtigt werden müssen. Forschung verfolgt jedoch auch keine
Individuallösungen, da Generalität ein Qualitätsmerkmal darstellt. Somit steht der Forscher
vor der Wahl der richtigen Anzahl unterstützter Problemklassen, an die sich Artefakte
anpassen lassen sollten.
Becker et al. [Becker, Delfmann, Knackstedt 2007] haben diese Fragestellung als Referenzmodell-Dilemma
thematisiert, welches auch die Ausgangsbasis für die vorliegende
Arbeit darstellt. Aus einer empirischen Untersuchung werden vier Nutzertypen
von Vorständen identifiziert, deren Anforderungen die situative Gestaltung von Unternehmenssteuerungssystemen
determinieren.
13.2.2 Bestehende Ansätze in der FIS-Gestaltung
Unsere Literaturanalyse folgt Webster und Watson [Webster, Watson 2002] und ist auf
führende Journals der WI ausgerichtet. Aus dem Katalog der London School of Economics
and Political Science (LSE) wurden zehn Zeitschriften ausgewählt [Willcocks,
Whitley, Avgerou 2008]. Es handelt sich um die Top-5-WI-Zeitschriften: MIS Quarterly
(MISQ), Information Systems Research (ISR), Information & Management
(I&M), Journal of Management Information Systems (JMIS), Decision Support Systems
(DSS) sowie die im Umfeld „Management und IT“ eher allgemein gehaltenen
Zeitschriften European Journal of Information Systems (EJIS), Information & Organization
(I&O), Information Systems Journal (ISJ), Journal of Organizational and End-

Beitrag F 125
User Computing (JOEUC) und Journal of Information Technology (JIT). Mit einer
Schlagwortsuche wurden 292 Artikel identifiziert, von denen 19 als relevant eingestuft
wurden. Durch einen „Backward Search“ wurde die Anzahl relevanter Artikel auf 25
erhöht. Ihre Auflistung ist in Abb. 29 dargestellt.
Abb. 29: Entwicklungsstand der situativen Artefaktgestaltung von
Unternehmenssteuerungssystemen
Die Analyse der Beiträge führte zu einer Dreiteilung. Die erste Gruppe stellt auf Techniken
zur Nutzerdifferenzierung ab und hat ihre Wurzeln in der Psychologie. Sie klassifizieren
Individuen nach ihren (menschlichen) Eigenschaften und Präferenzen und
setzen sich damit auseinander, in welcher Form sie Informationen bevorzugt aufnehmen
und wie sie darauf basierend Entscheidungen treffen (kognitiver Stil) [z.B. Barkhi
2002; Elam, Leidner 1995; Lamberti, Wallace 1987; Martinsons, Davison 2007]. Beispiele
sind der Myers-Briggs Type Indicator (MBTI) [Myers 1976], Witkins Konzept
der Feldabhängigkeit/Feldunabhängigkeit [Witkin et al. 1977] sowie Rowes und Boulgarides
Klassifikation von Entscheidungsstilen [Rowe, Boulgarides 1983] nach „directive,
analytical, conceptual, and behavioral“.
Die zweite Gruppe typisiert Nutzergruppen. Entweder setzen die Beiträge auf den Modellen
der ersten Gruppe auf. Ein Beispiel ist der MBTI zur Differenzierung von Männern
als FIS-Nutzer gegenüber Frauen [Powell, Johnson 1995]. Oder die Beiträge gehen
explorativ vor und leiten Nutzergruppen aus deren tatsächlichen Anforderungen

126 Beitrag F
oder Verhalten ab. So identifizieren Seeley und Target mit „steady-state user“ (kontinuierliche
Nutzung), „growing user“ (steigende Nutzung), „born-again user“ (wiederkehrende
Nutzung) sowie „declining user“ (zunehmend keine Nutzung) vier Nutzertypen
auf Basis ihrer FIS-Anwendung über die Zeit [Seeley, Targett 1999]. Hieraus lassen
sich jedoch keine Gestaltungsempfehlungen für Unternehmenssteuerungssysteme
ableiten. Walstrom und Wilson hingegen differenzieren auf Basis genutzter Funktionalitäten
(z. B. Analysen und Unternehmens-News) drei Nutzertypen [Walstrom, Wilson
1997]: „converts“ nutzen FIS als Alternative zu papierbasierten Reports, „pacesetters“
nutzen FIS, um den Informationsfluss zu verbessern und „analyzers“ nutzen primär
FIS-Analysefunktionen, insbesondere Methoden der Statistik. Hierbei werden jedoch
keine nichtfunktionalen Aspekte wie Performance, Benutzerführung oder Datenqualität
berücksichtigt. Gluchowski et al. [Gluchowski, Gabriel, Dittmar 2008], die sich
überwiegend auf Arbeiten von Chamoni et al. [Chamoni, Hahne, Gluchowski 2005]
beziehen, unterscheiden nach Informationskonsumenten, Analysten und Spezialisten.
Sie fundieren die Nutzertypen mit unterschiedlichen Managementrollen im Unternehmen.
Hieraus werden Potenziale für rechnergestützte Arbeitsplätze für Führungskräfte
abgeleitet.
Die dritte Gruppe an Beiträgen nutzt die Eigenschaften bestimmter Nutzergruppen, um
deren Implikationen für die FIS-Gestaltung abzuleiten. Ein aktuelles Beispiel sind
Martisons und Davison, die anhand „typischer“ Entscheidungsstile von Managern in
Amerika, Japan und China Aussagen über die erwartete Akzeptanz und Nutzung von
FIS machen [Martinsons, Davison 2007].
Als Kritikpunkt der skizzierten Beiträge lässt sich die Fokussierung auf kognitive Stile
festhalten, sodass Eigenschaften wie der persönliche Arbeitsstil, die Erfahrung oder
persönliche Motive für die FIS-Nutzung nur selten beleuchtet werden [Dhaliwal, Benbasat
1996; Fisher, Chengalur-Smith, Ballou 2003; Tractinsky, Meyer 1999]. Das hat
unter anderem zur Folge, dass bei der Gestaltung von FIS in der Regel nur Teilaspekte
beleuchtet werden [Huber 1983]. Hier setzt unser Forschungsvorhaben an: Ziel ist es,
eine Typisierung von FIS-Nutzergruppen durchzuführen, die (implizit) alle relevanten
Eigenschaften der obersten Führungskräfte berücksichtigt.
Hierfür eignet sich ein explorativer Ansatz, da hierbei die wesentlichen Eigenschaften
implizit in den zugrunde liegenden Nutzer- und Anforderungsprofilen enthalten sind
[vgl. Seeley, Targett 1999; Walstrom, Wilson 1997]. Es lässt sich daraus zwar nicht
erklären, warum eine Nutzergruppe bestimmte Anforderungen hat, aber da im vorliegenden
Beitrag die situative Gestaltung von FIS im Vordergrund steht, ist dies nicht

Beitrag F 127
von Nachteil. Alternativ müsste man die Nutzergruppen explizit entlang ihrer Charakteristika
modellieren, die jeweiligen Implikationen und Querbeziehungen untersuchen
und bei der IS-Gestaltung berücksichtigen. Das würde eine sehr hohe Komplexität implizieren,
von der bereits Huber abgeraten hat [Huber 1983].
13.3 Empirische Untersuchung
Als Forschungsmethode liegt dem Beitrag eine vergleichende Feldstudie (Querschnittsanalyse)
zugrunde. Sie erlaubt, verschiedene Aspekte zur Unterstützung der Unternehmensleitung
und auch systematisch Erkenntnisse verschiedener Unternehmen zu
erfassen [Kubicek 1975]. Fallstudien sind im Vergleich häufig nicht so strukturiert und
Längsschnittanalysen schieden aufgrund der Belastung der avisierten Führungskräfte
aus.
Unternehmenssteuerungssysteme haben eine besondere Bedeutung für große, internationale
Konzerne. Da diese überwiegend als Aktiengesellschaften firmieren, wurden in
die Untersuchung ausschließlich Konzerne einbezogen, deren konzernleitende Gesellschaft
zum Zeitpunkt der Untersuchung in einem Aktienindex erfasst war. Um die
Antworten vergleichbar zu halten, wurden schließlich die 250 größten Konzerne in
Europa einbezogen, die am 30. Juni 2008 im Financial Times (FT) „Europe 500“ Report
erfasst waren. Er stellt die größten europäischen Unternehmen nach ihrer Marktkapitalisierung
zum Stichtag zusammen [Financial Times 2008].
Die Daten wurden mit einem Fragebogen erhoben. Es wurden die Vorsitzenden des
Vorstands (CEOs) und die Finanzvorstände (CFOs) angeschrieben. Für die Typisierung
der Nutzertypen kamen Fragen zum Soll-Profil für Unternehmenssteuerungssysteme
zur Anwendung. Der Katalog bestand aus 14 Fragen, die nach Berthel [Berthel
1975] in die fünf Kategorien der Informationsversorgung gruppiert waren: Informationsbedarfsanalyse,
-aufbereitung, -darstellung sowie die Terminierung und Richtigkeit
der bereitzustellenden Informationen. Dabei kamen fünfstufige Ordinalskalen
mit „1 (sehr gering), 2 (gering), 3 (mittel), 4 (hoch) und 5 (sehr hoch)“ zur Anwendung
[Bleymüller, Gehler, Gülicher 1989].
Letztendlich haben 51 Gesellschaften mit 59 Fragebögen geantwortet. So wurde eine
gesellschaftsbezogene Rücklaufquote von 20,4% erreicht. Die Repräsentativität der
Stichprobe wurde mit Chi-Quadrat-Homogenitätstests [Fahrmeier et al. 2007] hinsichtlich
Branchenzugehörigkeit und Marktkapitalisierung bestätigt [Witte, Kallmann,
Sachs 1981].

128 Beitrag F
Die Untersuchungsergebnisse wurden mit Hilfe multivariater Methoden einer Faktoren-
und Clusteranalyse generiert [Härdle, Simar 2003]. Sieben von den 59 Antworten
mussten aufgrund zumindest einer fehlenden Antwort ausgeschlossen werden. Hair et
al. [Hair Jr et al. 2006] nennen 50 Datensätze als untere Grenze für eine Faktorenanalyse.
Die Stichprobe stellt mit 52 Datensätzen somit eine kleinere, aber ausreichende
Grundlage dar und ist vergleichbar mit anderen Untersuchungen in dieser Zielgruppe:
Seeley und Targett [Seeley, Targett 1999] arbeiteten mit 85 Datensätzen, Walstrom
und Wilson [Walstrom, Wilson 1997] mit 43, Rainer und Watson [Rainer, Watson
1995] mit 48, Nord und Nord [Nord, Nord 1995] mit 47 und Watson et al. [Watson et
al. 1995] mit 43 Datensätzen.
13.4 Auswertung
In einem ersten Schritt wurde herausgearbeitet, nach welchen maßgeblichen Faktoren
sich die Nutzertypen der befragten Vorstände unterscheiden lassen [Thompson 2004].
Hierzu wurden die 14 Variablen der Stichprobe mittels einer explorativen Faktorenanalyse
auf wenige, wechselseitig unabhängige Einflussgrößen reduziert.
Um die Eignung der Stichprobe zu belegen, wurde zunächst mit dem Kaiser-Maier-
Olkin-Test (KMO-Test) und dem Bartlett-Test eine ausreichende Korrelation unter
den 14 Variablen nachgewiesen (Tab. 26) [Dziuban, Shirkey 1974]. Das ermittelte
KMO-Kriterium von 0,73 ist dabei als „gut“ zu klassifizieren [Kaiser 1958]. Des Weiteren
wurde das Vorhandensein einer Diagonalmatrix überprüft (Tab. 27). Die Anti-
Image-Kovarianz-Matrix weißt 40 Nichtdiagonalwerte ungleich null (>0,9) auf, was
einer Quote von 21,98% (max. 25%) entspricht und die Anwendbarkeit einer Faktorenanalyse
bestätigt [Backhaus et al. 2006].
Das Kaiser-Guttmann-Kriterium [Kaiser, Dickman 1959] und das Ellbogen-Kriterium
[Cattell 1966] wurden verwendet, um in einem zweiten Schritt die Anzahl der benötigten
Faktoren zu bestimmen. Sie wurde mit vier berechnet (Abb. 31) und dient als Ausgangsbasis
für eine Hauptkomponentenanalyse. Die Ergebnisse sind in Tab. 23 dargestellt.
Die vier Faktoren erklären 67,18% der Variablenvarianz, was als befriedigend bis
gut eingestuft werden kann.
Zum besseren Verständnis der Faktoren wurde die Komponentenmatrix mit Hilfe der
Varimax-Methode und der Kaiser-Normalisierung [Kaiser 1958] gedreht. Die Faktorenladungen
zeigen dabei den Einfluss der Variablen auf den jeweiligen Faktor und
bestimmen sich aus den Korrelationen der Variablen zu den Faktoren. Dabei sind nur

Beitrag F 129
diese relevant, die mit einer Größe von mehr als 0,5 laden [Thompson 2004]. Das Ergebnis
ist eine eindeutige Zuordnung der Variablen zu den vier Faktoren (Tab. 23).
Item
(F1)
(F2)
(F3)
(F4)
Einstiegs-
Nutzungs-
Geschäfts-
Analyse-
niveau
bereitschaft
orientierung
orientierung
Aggregationsgrad ,792 ,003 -,304 -,064
Überprüfbarkeit ,781 ,137 ,187 ,232
Datenaktualität -,706 ,051 ,126 ,303
Datengenauigkeit -,659 -,130 ,043 ,448
Objektiver
Informationsbedarf
,028 ,805 ,085 -,092
Oberflächengestaltung -,114 ,681 -,205 -,154
Dialogführung ,371 ,698 -,138 ,064
Zahlungsbereitschaft ,170 ,720 ,010 ,235
Schnelle Umsetzung -,114 ,645 ,336 ,086
Subjektiver
Informationsbedarf
(Ergänzende) operative
Informationen
,064 ,140 ,807 ,269
,312 ,157 ,785 ,135
Statistikfunktionen -,136 ,093 -,069 ,831
Prognosemethoden -,072 ,025 ,128 ,855
Simulationen -,028 -,041 ,098 ,838
13.4.1 Einstiegsniveau
Tab. 23: Rotierte Komponentenmatrix
Das Einstiegsniveau stellt auf die Art und Weise ab, wie sich die befragten Vorstände
die „Einflughöhe“ ihrer Arbeit mit Unternehmenssteuerungssystemen wünschen. Hierauf
laden vier Variablen: Der Aggregationsgrad und die nachgelagerte Überprüfbarkeit
der bereitgestellten Informationen determinieren die Granularität des System-

130 Beitrag F
einstiegs. Dabei werden Kompromisse bei der Aktualität und Genauigkeit toleriert
(negative Faktorenladung).
Hieraus lassen sich zwei idealtypische Ausprägungen an Nutzertypen ableiten: Generalisten
präferieren einen solchen Überblick. Die Informationen haben sich jedoch
stets durch Detailanalysen überprüfen zu lassen. Spezialisten hingegen wünschen sich
schon zu ihrem Einstieg (Detail-)Berichte und Analysen. Dabei spielen dann bereits zu
Analysebeginn die Aktualität und Genauigkeit der bereitgestellten Informationen eine
große Rolle.
13.4.2 Nutzungsbereitschaft
Der zweite Faktor erfasst die über den Systemeinstieg hinausgehende IS-
Nutzungsbereitschaft („Navigation“). Hierauf laden die Oberflächengestaltung und
Dialogführung. Dass der objektive Informationsbedarf positiv auf die Nutzungsbereitschaft
lädt, lässt sich damit erklären, dass die Vorstände ihre Analyse damit anfangen
wollen. Sind diese Rahmenbedingungen erfüllt, nehmen sie den Zeit- und Kostenaufwand
für die Konzeption und Umsetzung von Unternehmenssteuerungssystemen auch
in Kauf.
Vielnutzer sehen einen großen Nutzen in ihrer IT-Unterstützung. Sie bevorzugen die
eigene IS-Navigation, wollen also Berichte eigenständig aufrufen und bereitgestellte
Informationen selbst analysieren. Im Gegenzug tolerieren sie den Zeit- und Kostenaufwand
für Unternehmenssteuerungssysteme. Nichtnutzer hingegen haben faktisch
kein Interesse an Unternehmenssteuerungssystemen. Dies kann in negativen Erfahrungen
oder auch aus Unkenntnis heutiger IT-Möglichkeiten begründet liegen. Sie benötigen
daher lediglich ein Standardreporting, eine größere Investition in Unternehmenssteuerungssysteme
lässt sich für sie kaum rechtfertigen
13.4.3 Geschäftsorientierung
Führungskräfte haben meist einen individuellen Arbeitsstil und damit einen vom objektiven
Informationsbedarf abweichenden (zusätzlichen) subjektiven Informationsbedarf.
Er umfasst Informationen, die die Vorstände zu glauben brauchen, die sich aber
nicht aus ihren Aufgaben ableiten lassen [Mayer 1999]. Die Geschäftsorientierung
klärt deren Bedeutung für Unternehmenssteuerungssysteme, insbesondere auch das
Tagesgeschäft im IS abzubilden. Dies kann Kennzahlen wie Durchlaufzeiten in der
Produktion, Fehler oder Ausschussquoten in der Qualitätssicherung umfassen.

Beitrag F 131
Tagesgeschäftsorientierte „Macher“ nehmen operative, individuelle Informationen
gerne in Anspruch, um produkt- und branchennahe Entscheidungen zu treffen. „Perceiver“
hingegen haben das Tagesgeschäft in der Regel aus der Hand gegeben. Sie
verlassen sich bei ihrer Aufgabenbewältigung eher auf die nachlaufenden finanziellen
Kennzahlen.
13.4.4 Analyseorientierung
Der vierte Faktor stellt auf die Bedeutung tiefergehender Analysen ab. Statistikfunktionen,
Prognosemethoden und Simulationen laden positiv darauf.
Analysten sind faktengetrieben und kommen mit Logik zu rationalen Entscheidungen
(Abschnitt 13.2.2: MBTI-Typ „Thinking“). Daher spielen Auswertungen für sie eine
große Rolle. Konsumenten hingegen verlassen sich bei Entscheidungen mehr auf ihre
Intuition (Abschnitt 13.2.2: MBTI-Typ „Feeling“). Sie urteilen eher subjektiv, sodass
weiterführende Analysen von geringer Bedeutung sind.
13.5 Nutzertypen
Basierend auf den herausgearbeiteten Faktoren, wurde eine hierarchische Clusteranalyse
durchgeführt, um die Vorstände in möglichst homogene Nutzergruppen zu unterteilen.
Hierzu wurde der Ward-Algorithmus mit quadriertem euklidischem Distanzmaß
ausgewählt [Backhaus et al. 2006], weil er auch für kleinere Datensätze geeignet ist
[Hair Jr et al. 2006]. Das Dendogramm legt ein Zwei-Cluster- sowie ein symmetrisch
detaillierendes Vier-Cluster-Modell nahe (Abb. 32).
Das Zwei-Cluster-Modell umfasst analyseorientierte Vielnutzer sowie indifferente
Wenignutzer. Das Vier-Cluster-Modell unterscheidet Analytische Poweruser, opportunistische
Analysten, generalistische Basisnutzer und faktische Nichtnutzer (Tab. 24).
Ihre Profile lassen sich anhand ihrer Faktorenausprägungen darstellen, die Werte wurden
hierfür normiert [Backhaus et al. 2006]. Positive Achsenabschnitte weisen darauf
hin, dass Faktoren die Nutzertypen stärker als im Durchschnitt prägen und vice versa.
13.5.1 Analyseorientierte Vielnutzer
Analyseorientierte Vielnutzer zeichnen sich durch ihre hohe grundsätzliche IS-
Nutzungsbereitschaft aus (F2, Faktorenladung von 0,5). Dabei soll in erster Linie ihr
objektiver Informationsbedarf abgedeckt werden (Tab. 23). Hinzu kommt ihre sehr
hohe Analyseorientierung (F4, Faktorenladung von 0,75). Demgegenüber besitzen diese
Vorstandstypen eine nur schwach ausgeprägte Tendenz, mit einem Überblick in die

132 Beitrag F
Unternehmensanalyse einsteigen zu wollen (F1). Gleiches gilt dabei für ihr Interesse
an ergänzenden operativen Informationen (F3).
(F1)
(F2)
(F3)
(F4)
Einstiegs-
Nutzungs-
Geschäfts-
Analyse-
niveau
bereitschaft
orientierung
orientierung
Cluster A: Analyseorientierte Vielnutzer
0,2
0,5
0,2
0,75
(neutral)
(hoch)
(neutral)
(sehr hoch)
A.1
0,1
0,9
0,7
0,9
Analytische
(neutral)
(sehr hoch)
(sehr hoch)
(sehr hoch)
Poweruser
A.2
0,3
0,3
0,1
0,6
Opportunistische
(hoch)
(hoch)
(neutral)
(hoch)
Analysten
Cluster B: Indifferente Wenignutzer
-0,1
-0,5
-0,3
-0,3
(neutral)
(gering)
(gering)
(gering)
B.1
-0,3
0
-0,6
-0,3
Generalistische
(gering)
(neutral)
(sehr gering)
(gering)
Basisnutzer
B.2
0,0
-0,9
-0,2
-0,9
Faktische
(neutral)
(sehr gering)
(neutral)
(sehr gering)
Nichtnutzer
Tab. 24: Zwei-Cluster- und Vier-Cluster-Modell von Nutzertypen für Unternehmenssteuerungssysteme
13.5.1.1 Analytische Poweruser
Analytische Poweruser detaillieren diese Grundeinstellung. Diese Vorstände informieren
sich umfassend und sehr selbstständig am System. Hinsichtlich ihrer Bereitschaft,
IS zu nutzen (F2), erreichen sie das Niveau des idealtypischen Vielnutzers (Abschnitt
13.4.2). Dazu kommt ihre dezidierte Anforderung nach tiefergehenden Analysen (F4,
Faktorenladung von 0,9). Dieses Ergebnis entspricht dem Niveau des idealtypischen

Beitrag F 133
Analysten (Abschnitt 13.4.4). Im Vergleich zu einer Referenzstudie von Kemper
[Kemper 1999] aus 1999 ist dies eine maßgebliche Veränderung, insbesondere wenn
sich 19 der befragten 52 Vorstände zu dieser Kategorie zählen. Des Weiteren haben
analytische Poweruser einen sehr hohen Bedarf an ergänzenden individuellen Informationen
(F3, Faktorenladung von 0,7) und wollen mit einer sehr schwach ausgeprägten
Tendenz mit einem Überblick in ihre Unternehmensanalyse einsteigen (F1, Faktorenladung
von 0,1).
13.5.1.2 Opportunistische Analysten
Hinsichtlich ihrer Nutzungsbereitschaft fallen opportunistische Analysten im Vergleich
zu analytischen Powerusern zurück. Sie sind aber immer noch als aktive IS-
Nutzer einzustufen (F2, Faktorenladung von 0,3). Sie besitzen dabei die Fähigkeit,
Analysen am System (F4, Faktorenladung von 0,6) selbstständig auszuführen, legen
aber keinen großen Wert darauf, dies auch zu tun.
Opportunistische Analysten wollen ihre Auswertungen mit einem Überblick beginnen
(F1). Zusätzliche Informationsbedarfe decken sie aber nicht per se durch Unternehmenssteuerungssysteme
ab (F3, Faktorenladung von 0,1 im Vergleich zu 0,7 der Analysten).
Sie nutzen IS, wenn sie helfen, Entscheidungen zu fundieren, wägen deren
Nutzung aber stets gegen individuelle Erfahrungen und persönliche Gespräche mit
Kollegen und Mitarbeitern ab.
13.5.2 Indifferente Wenignutzer
Die indifferenten Wenignutzer zeigen nur geringes Nutzungsinteresse an Unternehmenssteuerungssystemen
(F2). Mit einer negativen Faktorenladung von -0,5 liegen sie
deutlich unter dem Durchschnitt aller Antworten. Dabei haben sie auch weniger Bedarf
an ergänzenden Informationen in Unternehmenssteuerungssystemen sowie weitergehenden
Analysen (F3, F4, negative Faktorenladung von jeweils -0,3). Beim Systemeinstieg
(F1) möchten indifferente Wenignutzer direkten Zugriff auf (Detail-) Informationen
für ihren abgegrenzten Aufgabenbereich haben.
13.5.2.1 Generalistische Basisnutzer
Generalistische Basisnutzer detaillieren diese Einstellung. Sie legen weniger Wert auf
Analysen, die sie selbst am System durchführen können (F4, Faktorenladung von -0,3).
Sie präferieren dabei finanzielle Kennzahlen gegenüber individuellen operativen Informationen
(F3, negative Faktorenladung von -0,6) und wünschen sich, eher mit Details
in das System einzusteigen (F1). Hinsichtlich ihrer weiterführenden Nutzungsbe-

134 Beitrag F
reitschaft (F2) sind sie indifferent und greifen eher auf Ihre Assistenz zur Informationsbeschaffung
zurück.
13.5.2.2 Faktische Nichtnutzer
Charakteristikum der Nichtnutzer ist ihre faktische Ablehnung von Unternehmenssteuerungssystemen
(F2, Faktorenladung von -0,9). Falls sie in Ausnahmefällen ein IS
nutzen, sind sie in ihrem Einstieg indifferent (F1). Sie schätzen eher finanzielle Kennzahlen.
Tiefergehende IT-gestützte Analysen (F4) werden als „nicht benötigt“ eingeschätzt
(F4, Faktorenladung von -0,9).
Trägt man die relativen Faktorenausprägungen je Nutzungstyp in einer Matrix der
Nutzungsfaktoren auf, lassen sich die Nutzertypen auch grafisch darstellen (Abb. 30).
Spannbreite zwischen
den idealtypischen Ausprägungen
(überblickorientierte)
Generalisten
Analysten
1.0
Cluster A
Analyseorientierte
Vielnutzer
Cluster A.2
Opportunistische
Analysten
Cluster A.1
Analytische
Poweruser
(F1) Einstiegsniveau
(F4) Analyseorientierung
0
Cluster B.1
Generalistische
Basisnutzer
(detailorientierte)
Spezialisten
Konsumenten
Cluster B
Cluster B.2
Indifferente
Faktische
Wenignutzer
Nichtnutzer
-1.0
-1.0 0
1.0
(eher finanziellgetriebene)
Perceiver
(F3) Geschäftsorientierung
(tagesgeschäftsgetriebene)
Macher
Vielnutzer
Nichtnutzer
(F2) Nutzungsbereitschaft
Abb. 30: Einordnung von Nutzertypen im Spannungsfeld
idealtypischer Ausprägungen

Beitrag F 135
13.6 Implikationen
13.6.1 Situative Gestaltungsempfehlungen
Basierend auf den herausgearbeiteten Nutzertypen, werden nunmehr noch situative
Empfehlungen für die Gestaltung von Unternehmenssteuerungssystemen abgeleitet.
Die Ergebnisse dieser Deduktion wurden mit Erfahrungswissen aus Interviews mit vier
Vorständen eines internationalen Automobilzulieferers unterlegt (Umsatzerlöse 2009:
24 Mrd. EUR; Mitarbeiter 2009: 150.000).
Dabei erfolgte die Auswahl der Vorstände derart, dass je ein Nutzertyp aus dem Vier-
Cluster-Modell abgedeckt wurde: Der ana-lyseorientierte Poweruser wurde durch den
Vorsitzenden des Vorstands abgedeckt und der Finanzvorstand entsprach dem opportunistischen
Analysten. Darüber hinaus repräsentierte einer der Divisionsvorstände den
Nutzertyp generalistischer Basisnutzer und der Arbeitsdirektor stellte einen faktischen
Nichtnutzer von Unternehmenssteuerungssystemen dar.
Nach Walls et al. [Walls, Widmeyer, El Sawy 1992] kann bei der FIS-Gestaltung zwischen
einer Produkt- und einer Prozesssicht unterschieden werden. Wir fokussieren die
Produktsicht und differenzieren nach einer Referenzarchitektur für analytische IS zwischen
der Nutzerschnittstelle („user interface“) sowie der Auswertungskomponente
von Unternehmenssteuerungssystemen mit ihrem zugehörigen Datenmodell [Kemper,
Mehanna, Unger 2006; Warmouth, Yen 1992]. Folgende (situative) Adaptionsmechanismen
je Nutzertyp stellen wir zur Diskussion (Tab. 25).
13.6.1.1 Nutzerschnittstelle
Die Nutzerschnittstelle entscheidet maßgeblich, ob und bis zu welcher Detailtiefe Vorstände
mit Unternehmenssteuerungssystemen arbeiten. Wir differenzieren entsprechend
unseren Nutzungsfaktoren zwischen dem (a) IS-Einstieg und der (b) weiterführenden
Nutzung.
(a) Tab. 24 zeigt, dass das Einstiegsniveau je Nutzertyp in einer eher geringen Spannbreite
von 0,3 um den Nullwert pendelt. Damit ist ein gemeinsamer Systemeinstieg für
alle Nutzertypen grundsätzlich denkbar, dennoch sollten folgende Präferenzen berücksichtigt
werden.
Analytischen Powerusern und opportunistischen Analysten sollte mit einem Topdown-Einstieg
ein inhaltlich umfassender Einstieg bei granularer „Einflughöhe“ bereitgestellt
werden. Ihnen sollten alle Berichte und Analysen mit Bezug auf ihren ob-

136 Beitrag F
jektiven Informationsbedarf zugängig sein. Eine Portfoliodarstellung oder ein One-
Page-Format mit Informationsclustern wie Finanz- und Rechnungswesen, Controlling,
Compliance und Programm-Management sowie Cash Flow- und Liquiditätsmanagement
können ein solcher Einstieg sein.
Indifferenten Wenignutzern sollte ein Bottom-up-Einstieg bereitgestellt werden, der
direkt deren individuellen Erkenntnisgewinn befriedigt. Einfach strukturierte, farblich
hinterlegte Detailanalysen haben diesen Vorständen einen Absprung „auf Klick“ zu
Kurz-Bilanzen, Deckungsbeitragsrechnungen, einer Risiko- oder Projektübersicht zu
ermöglichen. Weiterführende Bereiche sollten in einem solchen Einstieg ausgeblendet
sein. Für faktische Nichtnutzer bietet sich ein Ausdruck wesentlicher Berichte und Reports
in elektronischer Form als E-Book an.
(b) Hinsichtlich der Nutzungsbereitschaft spannen die analytischen Poweruser und die
faktischen Nichtnutzer die größte Breite der Untersuchung in Höhe von 1,8 auf. Ein
„klassisches“ Finanzreporting stellt hier die Schnittmenge der Anforderungen dar. Für
die übrigen drei Nutzertypen ist dieses wie folgt zu ergänzen:
Analyseorientierte Poweruser sind die anspruchsvollsten Nutzer. Ihnen ist eine flexible
Systemnavigation zur Verfügung zu stellen. Das bedeutet, ein Standardreporting mit
vordefinierten Berichten und Analysen sollte um eine aktive Dialoggestaltung, selbst
abrufbare Kommentare sowie Absprungpunkte („touchpoints“) für eine umfassende
Peripherie ergänzt werden. Diese Peripherie sollte Ad-hoc-Abfragen, nichtroutinemäßige
Informationen und direkte Verknüpfungen zu Vorsystemen ermöglichen. Mit
Blick auf die hohe Faktorladung der Geschäftsorientierung (Abb. 30) ist dabei an
Marktanteils- oder Konkurrenzanalysen zu denken, die aufgrund ihrer Detaillierung
nicht Teil des Standardreportings sind. Mit voreingestellten Parametern ist bei dieser
Nutzergruppe auch das Absetzen direkter Datenbankabfragen denkbar.
Für opportunistische Analysten sind vordefinierte Detailanalysen bereitzustellen (vgl.
Abb. 30). Gewinn- und Verlustrechnungen, detaillierte Risiko- und Projektaufstellungen
oder Produktdeckungsbeitragsrechnungen sind Beispiele, die im Vergleich zu Powerusern
weniger operative Daten als vielmehr finanzielle Kennzahlen umfassen.
Für generalistische Basisnutzer sollte das Standardreporting überwiegen. Direkte Absprungpunkte
(„touchpoints“) sind an dieser Stelle auf ein Minimum zu reduzieren und
aus dem Einstiegsbildschirm gänzlich zu entfernen. Hingegen sollten für diese Vorstände
Navigationsfunktionalitäten wie ein Traffic-Light-Coding oder eine breadcrumb-Leiste
im Vordergrund stehen. Bei Letzterem handelt es sich um eine Orientie-

Beitrag F 137
rungsleiste, die häufig genutzte Funktionen protokolliert und somit eine schnelle Navigation
zwischen einzelnen Analyseschritten erlaubt.
13.6.1.2 Auswertungs- und Datenmodell
Das Auswertungs- und Datenmodell wird durch den inhaltlichen Umfang der gewünschten
Informationen determiniert, insbesondere inwieweit auch Daten aus anderen
Systemen zu integrieren sind. Die Geschäftsorientierung weist eine Spannbreite
von 1,3 auf, die durch die Anforderungen der analyseorientierten Poweruser und der
generalistischen Basisnutzer bestimmt wird.
Analyseorientierten Powerusern ist eine flexible OLAP-Peripherie bereitzustellen. Sobald
operative Daten angefordert werden oder aggregierte Informationen zu überprüfen
sind, sollten „drill-through“-Funktionalitäten vorhanden sein. Als Beispiele sind
eine geführte Navigation in ein Produktionsplanungs- und -steuerungssystem (PPS)
bei einem Automobilzulieferer oder ein Absprung in ein Dokumentensystem bei einem
Chemieunternehmen zu nennen. Im Vergleich fordern opportunistische Analysten neben
dem finanziellen Standardreport mit weniger Nachdruck operative, geschäftsorientierte
Kennzahlen.
Direktabsprünge in Quellsysteme sind für generalistische Basisnutzer hingegen auszublenden.
Ihnen sind überwiegend finanzielle Kennzahlen bereitzustellen. Dies trifft
auch auf die faktischen Nichtnutzer zu. Neben Detailblättern des Finanz- und Rechnungswesens
wie „Sales/EBIT-Analysen“ ist ihnen z. B. ein „Aufriss“ aggregierter
Kennzahlen nach den Sichten „Produkt, Land und Kunde“ oder Granularitäten wie
Konzern, Division und Einzelgesellschaft zur Verfügung zu stellen.
Die analytischen Poweruser und die faktischen Nichtnutzer weisen bei der Analyseorientierung
eine Spannbreite von 1,8 auf. Die gemeinsame Berichtsstruktur ist daher
je nach Nutzertyp um Analysen zu ergänzen. Für analyseorientierte Poweruser sind
statistische Funktionen, Prognosemethoden und Simulation selbstverständliche Hilfsmittel
in der Unternehmenssteuerung. Da opportunistische Analysten eher selten
komplexere Auswertungen am System durchführen, benötigen sie diese Analysen
nicht.
Faktische Nichtnutzer benötigen maximal vordefinierte Detailanalysen, vor allem aber
keine flexible OLAP-Peripherie. Ihr Stab wird ihnen entsprechende Analysearbeiten
durchführen und dabei auf vordefinierten Detailanalysen aufbauen. Tab. 25 fasst die
Ergebnisse je Nutzertyp zusammen.

138 Beitrag F
Maximallösung: Expertensystem für analyseorientierte Poweruser
Nutzerschnittstelle
Einstiegsniveau: 0,1 (neutral)
=> Top-down-Einstieg: inhaltlich umfassend bei granularer „Einflughöhe“
Nutzungsbereitschaft: 0,9 (sehr hoch)
=> Standardreporting sowie sehr flexible Möglichkeiten der Interaktion
Auswertungs- und Datenmodell
Geschäftsorientierung: 0,7 (sehr hoch)
=> hohes Gewicht auf geschäftsorientierte Kennzahlen
Analyseorientierung: 0,9 (sehr hoch)
=> vielfältige vordefinierte Detailanalysen, flexible Peripherie für individuelle Analysen,
„drill-through“-Funktionalitäten sowie statistische Funktionen, Prognosemethoden
und Simulation
Umfassende Berichterstattung für opportunistische Analysten
Nutzerschnittstelle
Einstiegsniveau: 0,3 (hoch)
=> Top-down-Einstieg: inhaltlich umfassend bei granularer „Einflughöhe“
Nutzungsbereitschaft: 0,3 (hoch)
=> Standardreporting sowie vordefinierte Möglichkeiten der Interaktion auf „Mausklick“
Auswertungs- und Datenmodell
Geschäftsorientierung: 0,1 (neutral)
=> etwas höheres Gewicht auf geschäftsorientierte Kennzahlen und nicht auf finanzielle
Kennzahlen
Analyseorientierung: 0,6 (hoch)
=> vielfältige vordefinierte Detailanalysen, überwiegend vordefinierte IS-Peripherie
für individuelle Analysen, keine statistischen Funktionen, Prognosemethoden und
Simulation
Tab. 25: Komponenten situativer Artefaktgestaltung

Beitrag F 139
Klassisches Finanzreporting mit wenigen weiterführenden Berichten und Analysen für
generalistische Basisnutzer
Nutzerschnittstelle
Einstiegsniveau: -0,3 (gering)
=> Bottom-up-Systemeinstieg: direkt auf den individuellen Erkenntnisgewinn ausgerichtet
Nutzungsbereitschaft: 0 (neutral)
=> Standardreporting mit wenigen vordefinierten (Detail-)Berichten und -analysen
Auswertungs- und Datenmodell
Geschäftsorientierung: -0,6 (gering)
=> hohes Gewicht auf finanzielle Kennzahlen
Analyseorientierung: -0,3 (gering)
=> wenige vordefinierte Detailanalysen, keine flexible IS-Peripherie, statistische
Funktionen, Prognosemethoden und Simulation
Minimallösung: klassisches Finanzreporting für faktische Nichtnutzer
Nutzerschnittstelle
Einstiegsniveau: 0 (neutral)
=> Bottom-up-Systemeinstieg: direkt auf den individuellen Erkenntnisgewinn ausgerichtet
Nutzungsbereitschaft: -0,9 (sehr gering)
=> Standardreporting ohne weiterführende (Detail-)Berichten und -analysen
Auswertungs- und Datenmodell
Geschäftsorientierung: -0,2 (gering)
=> etwas höheres Gewicht auf finanzielle Kennzahlen
Analyseorientierung: -0,9 (sehr gering)
=> sehr wenige vordefinierte Detailanalysen, keine flexible IS-Peripherie, statistische
Funktionen, Prognosemethoden und Simulation
Tab. 25: Komponenten situativer Artefaktgestaltung (fortgesetzt)

140 Beitrag F
13.6.2 Reflexion des Forschungsprozesses
Der eigentlichen Forschungsarbeit ging eine umfassende Literaturrecherche (Abschnitt
13.2.2) voraus, um den Erkenntnisgewinn auf eine relevante Forschungslücke auszurichten.
Die empirische Untersuchung setzte am Kritikpunkt an, dass stets nur Einzelaspekte
bei der situativen Gestaltung von FIS berücksichtigt werden. Das Vorgehen ist
somit als anschlussfähig und relevant einzustufen.
Die Ergebnisse wurden mit einer Faktoren- und Clusteranalyse erarbeitet (Abschnitt
13.8). Der Forschungsprozess erfüllt dabei die bekannten statistischen Anforderungen,
dennoch lassen sich einige Aspekte kontrovers diskutieren: Erstens, wenn auch mit
anderen Untersuchungen oberster Führungskräfte vergleichbar (Abschnitt 13.3), ist der
Stichprobenumfang mit 52 Datensätzen als klein einzustufen. Grundsätzlich hätte die
Möglichkeit bestanden, die Untersuchung auszubauen. Ein signifikanter Unterschied
wäre bei der geringen Verfügbarkeit der Führungskräfte aber nur mit hohem Aufwand
erreichbar gewesen. Auch hätte bei größeren zeitlichen Erhebungsabständen die Vergleichbarkeit
der Datensätze nicht mehr sichergestellt werden können. Die Nachfassaktion
wurde daher nach drei Monaten abgeschlossen.
Zweitens ist der KMO-Test mit 0,729 und die erklärte Varianz von 67,18% „nur“ als
gut einzustufen. Eine Verbesserung könnte mit dem Weglassen statistischer „Ausreißer“
oder ausgewählter Fragen in die Faktorenanalyse erreicht werden. Zum einen ist
dies aber ab einem gewissen Umfang schwer zu rechtfertigen. Zum anderen würde der
Modellerklärungsgehalt geschwächt werden.
Drittens lässt sich die Granularität der Fragen diskutieren. Eine höhere Anzahl hätte
die Ergebnisse facettenreicher machen können. Es ist jedoch zu bedenken, dass sich
dadurch die Anzahl der Faktoren und auch der Cluster erhöhen kann und das Modell
schwerer verständlich und anwendbar wird. In einer ersten Untersuchung hat sich das
Vier-Klassen-Modell als hinreichend, aber auch ausreichend erwiesen, um Vorstände
nach ihren Anforderungen an Unternehmenssteuerungssysteme zu gruppieren.
Bei den Gestaltungsimplikationen (Abschnitt 13.6.1) wurde die Produktsicht detailliert
(Aufbau von Unternehmenssteuerungssystemen), nicht die prozessuale Sicht der FIS-
Gestaltung. Somit bleiben die Auswirkungen eines Einbezugs verschiedener Nutzertypen
auf die Informationsbedarfsanalyse offen. Gleiches gilt für die Gestaltung ihrer
wesentlichen Artefakte, wie ein Corporate Dashboard oder verschiedene Detailanalysen,
die Systemeinführung sowie den Betrieb von Unternehmenssteuerungssystemen
[Kemper, Mehanna, Unger 2006].

Beitrag F 141
13.7 Zusammenfassung und Ausblick
Unsere Literaturrecherche hat gezeigt, dass bisher kein mehrdimensionales Modell zur
Nutzertypklassifikation vorliegt, das umfassende Implikationen für die situative Gestaltung
von Führungsinformationssystemen erlaubt. Es wurden deshalb ein Zwei- und
ein Vier-Cluster-Modell zur Typisierung oberster Führungskräfte entwickelt. Es basiert
auf einer empirischen Untersuchung im FT „Europe 500“ Report, aus der reale
Nutzertypen von Vorständen großer, internationaler Konzerne hervorgehen.
Eine wesentliche Erkenntnis im Zeitvergleich zu anderen Studien [Kemper 1999] war
es dabei, dass zumindest nach einer Selbsteinschätzung nunmehr auch analyseorientierte
Führungskräfte auf der obersten Ebene des Unternehmens anzutreffen sind. In
diesem Zusammenhang sind verschiedene Ansatzpunkte für die gestaltungsorientierte
Forschung denkbar. In dieser Arbeit wurden erste Implikationen für die Nutzerschnittstelle
sowie das Auswertungs- und Datenmodell von Unternehmenssteuerungssystemen
skizziert. Hier setzt unser nächstes Forschungsvorhaben an. Mit verschiedenen
Prototypen ist die Gestaltungsarbeit auszubauen und die Nützlichkeit dieses situativen
Ansatzes zu evaluieren. Neue Erkenntnisse sind insbesondere im Hinblick auf geeignete
Prognose- und Simulationsfunktionen zu detaillieren.
Schließlich wurde eine Untersuchung initiiert, die die identifizierten Nutzertypen mit
unterschiedlichen Nutzungssituationen und Arbeitsstilen kombiniert. Erstere können
Analysetätigkeiten („alone“), „one-to-one“-Arbeitstreffen und „one-to-many“-
Präsentationen in einer Vorstandssitzung umfassen. Letztere stellen auf die stationäre,
portable und mobile Nutzung von Unternehmenssteuerungssystemen ab. Ergebnisse
werden situative Empfehlungen zu Endgeräten für Führungskräfte sein.
13.8 Anhang
13.8.1 Elemente des Fragebogens
• Bedeutung des objektiven Informationsbedarfs
• Bedeutung des subjektiven Informationsbedarfs
• Bedeutung von operativen Informationen
• Bedeutung von Compliance-Informationen*
• Gewünschter Aggregationsgrad
• Bedeutung der Überprüfbarkeit
• Bedeutung der Systemagilität*

142 Beitrag F
• Bedeutung der grafischen Präsentation*
• Bedeutung der Oberflächengestaltung
• Bedeutung der Dialogführung
• Bedeutung selbstaktiver Ausnahmeberichte*
• Bedeutung von Vergleichsfunktionen*
• Bedeutung von Statistikfunktionen
• Bedeutung von Prognosemethoden
• Bedeutung von Simulationen
• Bedeutung von Datenaktualität
• Bedeutung von Datengenauigkeit
• Bedeutung von Zuverlässigkeit*
• Zahlungsbereitschaft hoch/niedrig
• Hohe/geringe Bedeutung einer schnellen Umsetzung
* Aufgrund geringer Faktorenladungen nicht berücksichtigt.
13.8.2 Eignung für die Faktorenanalyse
Prüfung auf ausreichende Korrelation: Der KMO-Test und der Bartlett-Test weisen
im Datensatz ein akzeptables Maß an Abhängigkeiten nach (Tab. 26).
Maß der Stichprobe nach Kaiser-Maier-Olkin ,729
Bartlett-Test auf Sphärizität Ungefähres Chi-Quadrat 260,305
df 91
Signifikanz ,000
Tab. 26: KMO- und Bartlett-Test
Prüfung auf Diagonalmatrix: Insgesamt lassen sich in der Anti-Image-Kovarianz-
Matrix (Tab. 27) 40 Nichtdiagonalelemente mit einem Wert größer als 0,09 identifizieren
(21,98%).

Beitrag F 143
Item 1 2 3 4 5 6 7 8 9 10 11 12 13 14
1 ,50 ,06 ,02 ,09 ,03 ,10 ,14 ,06 ,00 ,14 ,02 ,05 ,15 ,08
2 ,06 ,61 ,27 ,01 ,09 ,00 ,04 ,00 ,00 ,13 ,02 ,02 ,04 ,09
3 ,02 ,27 ,58 ,16 ,01 ,03 ,00 ,06 ,01 ,06 ,01 ,01 ,07 ,00
4 ,09 ,01 ,16 ,44 ,19 ,07 ,03 ,00 ,03 ,01 ,12 ,04 ,02 ,06
5 ,03 ,09 ,01 ,19 ,52 ,09 ,06 ,01 ,11 ,03 ,01 ,17 ,01 ,05
6 ,10 ,00 ,03 ,07 ,09 ,65 ,17 ,06 ,07 ,04 ,16 ,02 ,04 ,03
7 ,14 ,04 ,00 ,03 ,06 ,17 ,49 ,06 ,01 ,00 ,16 ,00 ,07 ,06
8 ,06 ,00 ,06 ,00 ,01 ,06 ,06 ,46 ,15 ,14 ,09 ,03 ,01 ,07
9 ,00 ,00 ,01 ,03 ,11 ,07 ,01 ,15 ,42 ,12 ,03 ,10 ,05 ,01
10 ,14 ,13 ,06 ,01 ,03 ,04 ,00 ,14 ,12 ,45 ,00 ,05 ,04 ,02
11 ,02 ,02 ,01 ,12 ,01 ,16 ,16 ,09 ,03 ,00 ,52 ,10 ,04 ,09
12 ,05 ,02 ,01 ,04 ,17 ,02 ,00 ,03 ,10 ,05 ,10 ,52 ,01 ,03
13 ,15 ,04 ,07 ,02 ,01 ,04 ,07 ,01 ,05 ,04 ,04 ,01 ,58 ,15
14 ,08 ,09 ,00 ,06 ,05 ,03 ,06 ,07 ,01 ,02 ,09 ,03 ,15 ,66
Tab. 27: Anti-Image-Kovarianz-Matrix (Absolutwerte)
13.8.3 Bestimmung der Faktorenanzahl
Nach dem Ellenbogenkriterium liegt eine Faktorenanzahl kleiner fünf nahe (Abb. 31).
Die maximal erklärte Gesamtvarianz von 67,18% wird dabei mit vier Faktoren erklärt.

144 Beitrag F
13.8.4 Dendogramm
Abb. 31: Screeplot
Abb. 32: Dendogramm

Beitrag G 145
14 Beitrag G: End-User Device Selection for Executives
– Adapting Executive Information Systems to Different
Working Styles
Titel
Autoren
End-User Device Selection for Executives – Adapting Executive
Information Systems to Different Working Styles
Daniel Stock, Jörg Mayer, Robert Winter
Universität St. Gallen, Institut für Wirtschaftsinformatik
Müller-Friedberg-Straße 8, 9000 St. Gallen, Schweiz
{daniel.stock | joerg.mayer | robert.winter}@unisg.ch
Publikationsorgan Eingereicht bei: ECIS (2011), Helsinki
Tab. 28: Bibliografische Angaben zu Beitrag G
The utility of information systems (IS) is closely linked to the choice of individuals to
actually use them. This holds particularly true for executives. Therefore, in terms of
executive information systems (EIS), a “one-size-fits-all” approach is often doomed to
fail. While the literature extensively discusses their functional design, non-functional
aspects of EIS often go unconsidered. As end-user devices are the most visible EIS
component for executives, they are an important lever for their acceptance. This article
proposes a configuration model for end-user devices based on executives’ working
style as defined in three dimensions: EIS user type, use case, and access mode. Several
findings result: first, the selection of the “right” end-user device is independent of the
extent (consumer or analyst) to which executives use the EIS. Second, notebooks remain
the first choice in any presentation context. Third, the potential of smartphones
as the sole devices in the EIS domain is limited. Fourth, the significance of paperbased
solutions is increasingly declining. The article concludes with examples of seven
types of executives to demonstrate how the configuration model on hand can be applied
in EIS design.
Keywords: executive information systems (EIS), human-computer interface (HCI),
end-user devices

146 Beitrag G
14.1 Motivation
Among the extensive definitions of executive information systems (EIS), two characteristics
are particularly important [Clark Jr, Jones, Armstrong Curtis 2007; Rainer,
Watson 1995; Rockart, Treacy 1989]: First, their overall aim is to help an organization
carefully monitor its current status and progress toward achieving its goals [Kelly
1988]. Second, they should enable nontechnical senior executives [Arnott, Jirachiefpattana,
O'Donnell 2007; Pappas 1988] to navigate through strategic information
culled from several company databases [Nord, Nord 1995]. This access should be direct
and hands-on, and executives should be able to exercise it themselves [Houdeshel,
Watson 1987; Young, Watson 1995].
Ideally, EIS design conforms to the requirements of all potential users. But confronted
with diverging demands on the one hand and limited resources on the other hand, EIS
engineers need to balance standardization (“one-size-fits-all”) and individualization.
Analogous to situational method engineering [Bucher et al. 2007], reference modeling
[Becker, Delfmann, Knackstedt 2007], or artifact mutability [Gregor, Jones 2007], partitioning
the requirements have to be optimized when designing solutions. The prime
objective of the design then is to use adaptation mechanisms to adjust generic artifacts
for distinct classes of problems.
In requirements engineering practices, users are primarily segmented by their tasks.
EIS design is, therefore, driven by executives’ different roles within the organization,
from their responsibility for procurement, production or sales to general management
[Darke, Shanks 1996; Leité, Freeman 1991; Sommerville 2010]. Such an approach
disregards individual preferences in their working style. As a consequence, many executives
still question the relevance of EIS for their day-to-day work [Kemper, Pedell
2008; Wixom, Watson 2010].
As early as 1979, Zmud [1979] echoes several authors by claiming that “individual
differences do exert a major force in determining EIS success.” However, this research
did not escape criticism. Only a few years later, Huber (1983) took stock of the research
in a way that led the wind out of its sails for many years to come. He claimed
that too many characteristics need to be considered, users should be better educated
instead, and future EIS might be completely configurable by users anyway.
Findings from recent decades invalidate Huber’s line of argument: Research on technology
acceptance proves that user perception plays a predominant role in information
systems’ (IS) success [Davis 1989; Venkatesh et al. 2003] and EIS today are more

Beitrag G 147
flexible, but customization still requires the skills of a power user. Especially, the
present moment seems favorable for redesigning IS support for executives: First, today’s
executives grew up with IS and have an increasingly positive attitude towards IT
[Pijpers et al. 2001]. At the same time, they have higher expectations for IS than in the
past, especially in terms of usability. Second, new technologies have been established
in the field of corporate business intelligence (BI) [Wixom, Watson 2010]: EIS have
evolved to an integrated front-end module that is often accessed via web technologies
[Cheung, Babin 2006], while groupware allows e-mailing and other collaboration.
Third – likely most important to executives – new front-end interfaces (software perspective)
and new end-user devices (hardware perspective) simplify EIS handling, even
for technology-averse executives [Li, Lu, Zhang 2009].
As they provide direct access to the required information and analyses capabilities,
end-user devices are executives’ most visible EIS component and thus an important
lever to their IS acceptance. Furthermore, end-user devices allow design freedom to a
certain extent. 19 In the light of these considerations, this article contributes to situational
EIS design by defining distinct characteristics how executives use devices. We
discuss their working style in three dimensions: EIS user type, use case, and access
mode. Combining the levels to which they are evident in a matrix results in a configuration
model for end-user devices.
This article adheres to the design science approach of IS research, which aims at creating
innovative and useful artifacts that solve relevant design problems in organizations
[Hevner et al. 2004; March, Smith 1995]. Next to Hevner et al. (2004), such artifacts
are constructs, models, methods, and instantiations. Regarding the design process, we
follow Peffers et al. (2007): Section 14.2 discusses the related work to demonstrate the
research gap. Section 14.3 introduces a taxonomy for end-user devices. Section 14.4
designs the configuration model in a two-step approach: First, recommendations are
derived by analytical argumentation. Second, the configuration model is validated with
EIS experts. Section 14.5 evaluates the utility of the work on hand with seven cases.
The article concludes with a summary and discusses future research question for enduser
devices and EIS (section 14.6).
19 For example, no EIS engineer would consider a flash solution for smartphones since it is not supported by
them at this point. Also an “on-line” solution is not favorable for mobile use (e.g. car, plane) since a constant
VPN connection is required.

148 Beitrag G
14.2 Related Work
Following the recommendations of Webster and Watson [2002], our literature analysis
targeted leading IS research outlets. We selected ten journals 20 based on a catalog provided
by the London School of Economics [Willcocks, Whitley, Avgerou 2008]. Our
keyword search resulted in 292 articles, of which we found 26 to be relevant, including
in a backward search ( Abb. 33).
Abb. 33: Results of literature analysis
In general, each of the identified publications target one of three subsequent objectives.
The first group, rooted in psychology, designs techniques for user-group segmentation.
All these concepts deal with cognitive style. That is the way in which individuals
tend to grasp information (e.g., quantitatively vs. qualitatively) and how they
apply this information when making decisions (e.g., logical argumentation vs. intuition).
Examples are the Myers-Briggs Type Indicator [Myers 1976] or Witkins concept
of field dependence/field independence [Witkin et al. 1977].
The second group covers the characterization of user groups. Two different approaches
exist. Either the studies apply the techniques employed in the first group to explore
20 MIS Quarterly, Information Systems Research, Information & Management, Journal of Management Information
Systems, Decision Support Systems, European Journal of Information Systems, Information & Organization,
Information Systems Journal, Journal of Organizational and End-User Computing, and Journal of Information
Technology.

Beitrag G 149
the influence of certain user characteristics (e.g., women vs. men [Powell, Johnson
1995]) or they utilize an explorative procedure. As an example, Seeley & Target
(1999) identify four different user types on the basis of their EIS usage over time:
steady-state users, growing users, born-again users, and declining users. The third and
last group researches the implications of user types on EIS design.
Focusing on the latter, these articles look at the functional aspects of EIS in terms of
information scope and structure required and analysis functionality as well. None,
however, examine executives’ working style on the non-functional requirements (e.g.,
performance, usability, or flexibility). An example of how working style impact nonfunctional
IS aspects comes from a consulting firm. When this company rolled out a
tool to track time and expenses, they failed to consider the working style of their consultants.
Since confidentiality prevents them from client work during travel, trips are
the perfect opportunity for administrative tasks. Unfortunately, the new tool required a
smooth Internet connection to operate, which is obviously limited during travel. So,
better EIS design requires more than a design based on executives’ tasks. The design
needs to be complemented by non-functional aspects. Our contribution aims at identifying
those end-user devices that fit executives’ working style with EIS.
14.3 End-user devices
A wide variety of end-user devices are available. Every year new products enter the
market that blur the boundaries of formerly system classes. Recently, Apple’s iPad
(and alternative products such the Dell Streak or HP Slate) combined an A4-sized
screen and easy system handling to claim a niche between notebooks, ultra-mobile
PCs, and e-readers.
The predominant determinants in literature for end-user device classification are
screen size and its often associated functionality. Since the example of the iPad shows
that this assumption no longer necessarily holds, we propose a classification that emphasizes
the core aspects of usability: portability (including Internet access) and control
philosophy. Abb. 34 classifies typical end-user devices in terms of this taxonomy.

150 Beitrag G
Abb. 34: End-user devices taxonomy
Portability distinguishes whether or not a device is stationary or portable. While a stationary
device offers a bigger and brighter screen, a portable device is a must-have for
mobile use that is generally smaller and offers less functionality in several dimensions.
The control philosophy is important in terms of content consumption and creation
[e.g., McCracken 2010; Waters 2010]. Paper can be differentiated from personal computers
(PCs), which are traditionally controlled by mouse and keyboard, and infoterminals,
which are controlled by stylus or touch (gesture). Although it is not an electronic
device, paper is still an important medium, because it can be easily shared during
a conversation and annotated [Harper, Sellen 1995]. When it comes to the personal
computer (PC) and infoterminal, some electronic products aim to support both. Speaking
of the iPad, McCracken [2010] concludes that “the on-screen keyboard is probably
the best ever created, but it’s still no match for a real, tactile keyboard when it comes
to comfort and typing speed.” The same still holds true for tablet PCs supporting touch
control (e.g. Lenovo X201), where the lag between contact and response still feels unnatural.
14.4 Configuration Model
Two distinct approaches to model construction exist: a bottom-up approach that reuses
existing models and fragments [vom Brocke, Buddendick 2006] and a top-down
greenfield approach that utilizes analytic argumentation. While the first ensures consistency
with the body of knowledge, the second is better suited for innovative artifacts
design. Leveraging both, we start from the body of knowledge with a hypothesisdriven
design and justify the model brainstorming with EIS experts.

Beitrag G 151
14.4.1 Hypothesis-driven Design
In analogy to the “5 W” in information gathering [Media Awareness Network 2000],
the questions for determining the right end-user device for EIS could be formulated as:
who uses what, where, when, and why Although looking at all five questions would
provide the most comprehensive view, we focus on “what,” “where,” and “why.” Because
we do not look on individual solutions (section 14.1), the “who” in terms of a
one-by-one differentiation of executives would not add value. Knowing the “when,” in
terms of time during the day, should also be irrelevant to the choice of the device. As a
result, we look at end-user devices in three dimensions: EIS user type, use case, and
access mode.
EIS user type: It covers what category of executives uses the IS. In section 2, we have
seen that executives are distinguished by cognitive style meaning how an individual
gathers, analyses, and processes information in the context of decision making. Each
of these approaches differ between analytic and heuristic decision makers. Analysts
seek causal relationships, prefer quantitative data, and pay attention to detail. They
might use standard reporting as an entry point, but they need the ability to switch to an
interactive system for further detailed analysis. In terms of choosing the respective
end-user device, this implies that these executives need electronic devices that support
EIS handling (e.g., a PC with keyboard/mouse). Heuristic decision makers, on the other
hand, include qualitative factors in their decisions, and pay less attention to detail
[e.g., Myers 1976; Rowe, Boulgarides 1992; Witkin et al. 1977]. Unlike their analytic
counterparts, these “consumers” tend to rely on standard reporting, which provides
familiar content in a predefined order. They may be happy with a paper-based solution
or low-capacity electronic device.
EIS use case: It represents various working situations; in other words why executives
use IS. An important aspect of managerial work is the “monitoring, filtering, and dissemination
of information” [Hales 1986]. In this regard, Mintzberg [1975; 1994b] and
Burns [1957] distinguish between interpretation of information (to use in a directive
way) and communication (in order to disseminate privileged information to subordinates).
While the first task is generally performed alone (e.g., at the desk in one’s office),
the latter involves further stakeholders (e.g., the audience for a presentation). Of
course, interpretation and communication are not always completely separate tasks in
practice. For example, in working meetings, information is normally disseminated and
interpreted at the same time. Thus, we distinguish three use cases for an EIS, which are
distinguished by the number of participants for the sake of simplicity: analysis (execu-

152 Beitrag G
tives on his or her own), working meeting (one-to-few: executives with a few colleagues,
personal assistance or other staff), and presentation (one-to-many: executives
in front of an audience, e.g., a board meeting). As the number of participants increases,
the requirements for the end-user device screen do as well. While a smartphone might
suffice for an executive to analyze a standard report on his own, it is not the right
choice for presenting a document. Of course, it is common to increase the display size
of many devices (e.g., notebooks) by connecting them to a projector or external screen.
Still, it might be beneficial in some cases to have an interactive whiteboard available. 21
EIS access: It addresses where executives use EIS. Since most executives can be considered
to be mobile workers who are away from their desks at least 20% of the time
[Lamming et al. 2000], it is relevant to understand where an EIS user accesses the system:
from his or her own desk (stationary), in different places (portable) with the same
type of access, or on the move (mobile). Accessing electronic information sources is
relatively easy from one’s own desk because the IS infrastructure is readily available
to allow smooth Internet access via UMTS, W-LAN, or cable. In turn, people who carry
laptops with them can access the documents stored on them. However, accessing
other remote information sources is more difficult [Eldridge et al. 2000; Lamming et
al. 2000]. Internet access can be limited to GRPS, UMTS with disruption (car, train).
In some cases one is offline in travel situations (plane). As a result, accessing a “live”
interactive system to perform analysis is impracticable at these times. This implies that
an analyst-type executive who wants to work on the go needs an electronic device with
capacity to allow for the installation of a thick client with a local database. For example,
this functionality definitely exceeds the services offered by smartphones [Chae,
Kim 2003].
In contrast, a consumer executive in a mobile context can make use of paper-based
standard reports or access an electronic version via a low-capacity device. He or she
might also value the control philosophy of small end-user devices, such as smartphones,
which are most often on-line available [Chae, Kim 2003] rather than of booting
up a bulky notebook. In a stationary working context, either type of the EIS user
prefer a desktop PC, which provides easier access and better displays thanks to a keyboard
and crystal-clear screen. Abb. 35 shows recommended end-user devices in terms
21 For example, if the executive wants to navigate flexibly through the EIS while presenting (instead of just
clicking through a presentation), it might be better to carry out the necessary inputs directly at the display, so that
everybody can easily follow them.

Beitrag G 153
of user type, use case, and access mode. Table 1 lists the hypotheses for model construction.
Abb. 35: Preferred end-user devices by user type, use case, and access mode
14.4.2 Model Justification
The focus group for validating our proposed model consisted of 23 participants from
17 different companies. To include different perspectives, executives, accounting professionals,
and EIS professionals were represented almost equally. They came together
in a 4-hour moderated workshop in September, 2010, and belong to an expert group
since 2006, discussing trends in executives’ IS support.
In order to provide common ground, the participants were introduced to the applied
terminology and given some time to explore the “look and feel” of EIS implementations
on the following end-user devices: an Apple iPhone 3GS (smartphone), a Lenovo
X200t (notebook), an Apple iPad (tablet), and a SMARTboard (interactive whiteboard).
The questionnaire was designed to test our model design in two ways and thus provide
consistency checks (triangulation). The first part consisted of five-point Likert items to
validate the hypotheses listed in Tab. 29. Each item adhered to the format: 1) strongly
disagree, 2) disagree, 3) neither agree nor disagree, 4) agree, and 5) strongly agree.
The mode (most frequent) and median (middle) values for the responses are listed in
Tab. 29. Hypotheses that were not supported are shaded in grey.

154 Beitrag G
No. Hypotheses Mode Median
1 The “what” (standard or ad hoc report) is relevant for selecting
an end-user device.
2 The “why” (analysis, working meeting or presentation) is
relevant for selecting an end-user device.
3 The “where” (stationary, portable or mobile access) is relevant
for selecting an end-user device.
4 The “when” is not relevant for determining an end-user
device.
5 The capacity of a smartphone is sufficient for consuming a
standard report (e.g., as a PDF).
6 A keyboard/mouse control is favorable if frequent inputs
are necessary for information analysis (e.g., setting parameters
or defining transformations).
7 During presentations, an interactive whiteboard is favorable
when navigating through the EIS.
8 In general, screen size determines the level of comfort in
analyzing information.
9 In a mobile working context, the setup time of a device
(e.g., booting a notebook) determines whether it is used or
not.
10 In a mobile working context, the weight of a device determines
whether it is used or not.
11 In a mobile working context, the size of a device determines
whether it is used or not.
12 At the desk, an external monitor is favorable for analyzing
information due to its display quality.
13 In a mobile working context, paper versions are often preferred
over electronic reports.
Disagree
Disagree
Agree
Agree
Agree
Agree
Agree
Agree
Strongly
agree
Agree
Agree
Strongly
agree
Disagree
Disagree
Disagree
Agree
Agree
Agree
Agree
Agree
Agree
Agree
Agree
Agree
Strongly
agree
Undecided
Tab. 29: Mode and median responses from hypotheses testing

Beitrag G 155
The second part of the questionnaire consisted of multiple-choice answers. Respondents
were asked to pick their preferred end-user device for a given context (e.g., analyzing
a standard report at their desk). Aggregating the responses in a refined version
of our proposed model (Abb. 35), the result is shown in Abb. 36. New elements in the
matrix are printed in italics and obsolete elements are crossed out. The order of enduser
devices in each cell corresponds to the frequency scale in the responses.
Abb. 36: Aggregated results from questionnaire
Abb. 36 reveals some unexpected patterns. In order to gain further insights and check
for consistency, we verified them with the findings of the hypotheses testing.
First result: The selection of the “right” end-user devices is independent of the extent
(consumer or analyst) to which executives use EIS. Apart from working meetings and
analysis, where consumer executive types still see paper-based reports, the preferred
end-user devices for consumers and analysts are the same. The biggest difference derives
from the fact that hard copies are a viable option for standard reports from the
consumer perspective, but cannot replace an interactive EIS from the analyst perspective.
Since the paper-based consumption of standard reports plays a subordinate role
(least- or second-least frequent response), this is in line with the rejection of hypothesis
1 (Tab. 29).
Second result: Notebooks remain the first choice in any presentation context. Although
participants acknowledge the advantages of interactive whiteboards in general (hypothesis
7, Tab. 29), only six respondents considered them to be favorable, e.g., in board
meeting context. Either the respondents believe that the benefits of an interactive
whiteboard do not justify the cost of implementation (approx. USD 8,000) or they intrinsically
consider the use cases (e.g., presenting within the interactive system) as too
unlikely to necessitate an end-user device tailored for this purpose.

156 Beitrag G
Third result: The potential of smartphones as the sole devices in the EIS domain is
limited. Even in a mobile context, they rank after a tablet. This is in line with our hypotheses,
since a tablet is as readily available as a smartphone (hypothesis 9, Tab. 29),
but increases user comfort with a much larger and brighter screen (hypothesis 8, Tab.
29). For these reasons, notebooks supplemented with smartphones will remain the
standard for now. Since a tablet cannot replace a smartphone or a notebook in all regards,
an assessment of whether an executive accepts an additional device is necessary.
Fourth result: Paper-based solutions are increasingly losing significance. A finding
that is in line with our rejection of hypothesis 13 in Tab. 29. Only in a working meeting
context hand-outs still claim a top position. As tablets, which are already ranked
higher, continue to gain acceptance and advance in functionality (esp. in terms of adhoc
connectivity to share documents), paper will further decline in value.
Abb. 37: Final model design

Beitrag G 157
All in all, adopting our model is consistent with the findings of the hypotheses testing.
Reducing the complexity by abandoning the dimension "user type," the final model is
a 3x3 matrix (Abb. 37).
14.5 Application in Practice
To demonstrate utility, our model was used for EIS design in practice. First, it has to
check whether an executive has the end-user devices available that meet his or her
working style. For example, our model has to indicate that an executive who works in
mobile situations to a significant degree will benefit from having a tablet. Second, our
model has to assess whether the EIS is designed to support the preferred end-user devices.
For example, an executive might carry a smartphone for mobile use, but the IS
could not provide standard reports in a format that is accessible with this device.
The following examples present the results of seven interviews with executives of
companies in different size from September to November, 2010, to diagnose shortcomings
in EIS design. We began by profiling the executives in terms of their use case
and access mode and measured their level of satisfaction with the devices they currently
use.
Executive A: He is the CFO of an automotive supplier (2009 sales: about USD 32 bn.;
2009 employees: about 150,000). He uses the EIS to an equal extent for his own analysis
and in working meetings, accessing information predominantly from his office
(80%) and in a mobile context (20%). He is equipped with a desktop PC in the office,
a notebook, and a tablet. Instead of a smartphone, he uses an ordinary mobile phone
without e-mailing capability. In general, he is satisfied with his equipment. This is in
line with our model for an optimal support of this working profile.
Executive B: She is the CIO of a pharma company (2009 sales: about USD 10 bn.;
2009 employees: about 40,000) and uses the EIS in all facets of our model, accessing
information in a mobile context (50%) to the same degree as from the office (50%).
Equipped with a desktop PC in the office, a smartphone for mobile communication
including e-mailing and one-pager analysis for urgent decision making, and a tablet for
more complicated information analysis, she is completely satisfied.
Executive C: He is the CEO of a multicountry division of a chemicals company (2009
sales: about USD 65 bn.; 2009 employees: about 105,000) who travels weekly across
the Atlantic or between Europe and South Africa. He acts as an analyst with an IT flavor
and uses the EIS in all the use cases and access modes covered in our model.
Equipped with a notebook and a smartphone, he is rather dissatisfied. This is in line

158 Beitrag G
with our model, which would suggest additionally equipping him with a desktop PC at
his European headquarters and a tablet for more detailed information analysis in mobile
situations. Providing the tablet should increase his level of satisfaction, since our
model clearly indicates that most executives do not consider a notebook to be a suitable
solution in a mobile context.
Executive D: He is a board member of a smaller BI consultancy (2009 sales: about
USD 45 m.; 2009 employees: about 120). His profession and academic studies suggest
that he is an IS-trendsetter and, no matter, he uses the EIS in all the modes covered in
our model. He is accessing information in stationary (at the office or home) and mobile
situations in a ratio of 30 to 70%. In addition to a notebook, he has a desktop PC
available. He assesses his level of satisfaction as neither satisfied nor dissatisfied. Although
his current end-user devices suit his working profile for the most part, an additional
tablet was beneficial in his mobile context for e-mailing, internet search, and
analyzing complex statistics on the utilization of his consultants.
Executive E: He is the CFO of a medium-sized engineering company (2009 sales:
about USD 32,500 m.; 2009 employees: about 3,200). He is rather dissatisfied with his
current end-user devices, a desktop PC and a smartphone. This holds true according to
our model. A notebook would be an additional device. If the executive does not want a
bulky notebook, a tablet could be the second-best solution.
Executive F: He is the CEO of a solution provider for the print media industry (2009
sales: USD 2,250 m.; 2009 employees: about 1,150). He uses the EIS for his own
analysis and works predominantly at his desk at the office. He is equipped with a notebook
and a smartphone, and considers—as his slogan of corporate management—the
latter as his primary device for information consumption. In general, he is rather dissatisfied
with his equipment. A closer analysis revealed that the EIS does not support
standard reports for smartphones per se. According to our model, this CEO is actually
well equipped for his working profile, but the EIS has been developed for the wrong
end-user device. In the meantime, he might benefit from a tablet, which would provide
him with the features of a mobile device and the comfort of a bigger screen.
Executive G: He is the CFO of another automotive supplier (2009 sales: about USD
150,000 m.; 2009 employees: about 7,600). A full 80% of his EIS use takes place
away from his desk. He is equipped with a notebook and a smartphone and is rather
dissatisfied. In terms of our model, he is actually well equipped for his working profile,
although, like executive F, he might benefit from a tablet for his analysis and decision
making most often on the way to the several productions hubs of his company

Beitrag G 159
in Eastern Europe. His dissatisfaction grows not from the equipment itself, but rather
from the fact that the EIS is not tailored to the capacity and features of these end-user
devices. Since in this case, the system design completely disregards the targeted enduser
devices. The most appropriate answer would be to redesign the EIS presentation
format accordingly.
In summary: In the case of satisfied executives (A and B), the portfolio of end-user
devices was consistent with our model’s recommendations. In the case of somewhat
dissatisfied executives (C through G), the model provided pinpointed the shortcomings
of the current EIS solution. So, if an executive was satisfied, the portfolio of his individual
end-user devices was in line with our model. If an executive was not satisfied,
our model helped to find out if the organization provides the right end-user device(s)
available or if the EIS itself had to be redesigned to support the end-user devices available.
Herein, the biggest problem these days is executives’ increasing mobility. In
general, tablets constitute an interesting new device class, which should be considered
thoroughly in many cases.
14.6 Summary and Final Remarks
This article contributes to situational EIS design by introducing a configuration model
for end-user devices. It is based on an executive’s working style. The model was validated
with the input of 23 EIS experts. In its final version, it provides situational recommendations
for several EIS use cases (analysis, working meeting, or presentation)
and EIS access mode (stationary, portable, or mobile).
To demonstrate its utility, the model was validated with seven executives. The model
was used for pinpointing shortcomings in either the available end-user devices or the
respective design of the EIS. Synthesizing the findings shows that most problems today
grow from executives’ increasing mobility. Thus, while the notebook continues to
be the primary device in most cases, tablets constitute an interesting device class,
which should be considered additionally.
The configuration model leaves room for future research. First, the configuration rules
need to be translated into design principles for EIS implementation. For example, it
should be possible to identify functionality and design patterns that best support access
from an interactive whiteboard or the right balance of information security and comfortable
access in a mobile context. Second, the results should be incorporated into the
EIS design to define, for example, how requirements change when executives access
the EIS from a smartphone or tablet (e.g., strict top-down communication, key word

160 Beitrag G
storytelling, and predefined links to most important analyses). Third, the implications
of the increasing number of end-user devices on system administration should be surveyed
to determine, for example, architectures and policies that support governance,
efficient application development, and maintenance.

Literatur 161
Literatur
[Ackoff 1989]
Ackoff, Russell L.: From Data to Wisdom. In: Journal of Applied Systems
Analysis 16 (1989), S. 3-9.
[Alavi, Leidner 2001]
Alavi, Maryam; Leidner, Dorothy E.: Review: Knowledge Management and
Knowledge Management Systems: Conceptual Foundations and Research Issues.
In: MIS Quarterly 25 (2001) 1, S. 107-136.
[Anthony 1965]
Anthony, Robert Newton: Planning and Control Systems: A Framework for
Analysis. Harvard University Press, Boston 1965.
[Ariyachandra, Watson 2005]
Ariyachandra, Thilini R.; Watson, Hugh J.: Data Warehouse Architectures:
Factors in the Selection Decision and the Success of the Architectures. Terry
College of Business, University of Georgia, Athens 2005.
[Arnott, Jirachiefpattana, O'Donnell 2007]
Arnott, David; Jirachiefpattana, Waraporn; O'Donnell, Peter: Executive Information
Systems Development in an Emerging Economy. In: Decision Support
Systems 42 (2007) 4, S. 2078-2084.
[Arnott, Pervan 2008]
Arnott, David; Pervan, Graham: Eight Key Issues for the Decision Support Systems
Discipline. In: Decision Support Systems 44 (2008) 3, S. 657-672.
[ASG 2009]
ASG: ASG-metaGlossary. http://www.asg.com/pdf/DataSheets/ASG-metaGlos
sary_datasheet_en.pdf, Abruf am 12.11.2010.
[Auth 2003]
Auth, Gunnar: Prozessorientierte Organisation des Metadatenmanagements für
Data-Warehouse-Systeme. Dissertation, Universität St. Gallen, St. Gallen 2003.
[Backhaus et al. 2006]
Backhaus, Klaus; Erichson, Bernd; Plinke, Wulff; Weiber, Rolf: Multivariate
Analysemethoden - Eine anwendungsorientierte Einführung. 11. Aufl., Springer,
Berlin 2006.
[Barkhi 2002]
Barkhi, Reza: Cognitive Style May Mitigate the Impact of Communication
Mode. In: Information & Management 39 (2002), S. 677-688.
[Batini, Scannapieco 2006]
Batini, Carlo; Scannapieco, Monica: Data Quality - Concepts, Methodologies
and Techniques. Springer, Berlin 2006.
[Bauer, Günzel 2004]
Bauer, Andreas; Günzel, Holger: Data Warehouse Systeme - Architektur, Entwicklung,
Anwendung. 2. Aufl., dpunkt.verlag, Heidelberg 2004.
[Bayer 2004]
Bayer, Joachim: View-Based Software Documentation. Dissertation, Fraunhofer
IESE 2004.

162 Literatur
[Becker, Delfmann, Knackstedt 2007]
Becker, Jörg; Delfmann, Patrick; Knackstedt, Ralf: Adaptive Reference Modeling:
Integrating Configurative and Generic Adaptation Techniques for Information
Models. In: Becker, Jörg; Delfmann, Patrick (Hrsg.): Reference Modeling.
Physica, Heidelberg 2007, S. 27-58.
[Benander et al. 2000]
Benander, Alan; Benander, Barbara; Fadlalla, Adam; James, Gregory: Data
Warehouse Administration and Management. In: Information Systems Management
17 (2000) 1, S. 71-80.
[Berson, Dubov 2007]
Berson, Alex; Dubov, Larry: Master Data Management and Customer Data Integration
for a Global Enterprise. McGraw-Hill 2007.
[Berthel 1975]
Berthel, Jürgen: Betriebliche Informationssysteme. Poeschel, Stuttgart 1975.
[Blechar 2005]
Blechar, Michael J.: Magic Quadrant for Metadata Repositories, 2H05 to 1H06.
Gartner, Stamford 2005.
[Bleymüller, Gehler, Gülicher 1989]
Bleymüller, Josef; Gehler, Günther; Gülicher, Herbert: Statistik für Wirtschaftswissenschaftler.
6. Aufl., Vahlen, München 1989.
[Boardman et al. 2008]
Boardman, Anthony E.; Greenberg, David H.; Vining, Aidan R.; Weimer, David
Leo: Cost-Benefit Analysis: Concepts and Practice. 3rd edition. Aufl., Prentice
Hall, Upper Saddle River 2008.
[Boehm 1978]
Boehm, Barry W.: Characteristics of Software Quality. North-Holland, Amsterdam
1978.
[Brüggemann 2008]
Brüggemann, Stefan: Proaktives Management von Konsistenzbedingungen im
Analytischen Performance Management. In: Dinter, Barbara et al. (Hrsg.): Proceedings
of DW2008: Synergien durch Integration und Informationslogistik,
Bonn 2008, S. 95-112.
[Bucher et al. 2007]
Bucher, Tobias; Klesse, Mario; Kurpjuweit, Stephan; Winter, Robert: Situational
Method Engineering - On the Differentiation of "Context" and "Project
Type". In: Ralyté, Jolita; Brinkkemper, Sjaak; Henderson-Sellers, Brian
(Hrsg.): Proceedings of Situational Method Engineering - Fundamentals and
Experiences, Geneva 2007, S. 33-48.
[Bucher, Wlk 2008]
Bucher, Tobias; Wlk, Ulrich: Bereitstellung und Nutzung von Endbenutzungs-
Metadaten im Kontext der Informationslogistik - Empirische Erkenntnisse und
Gestaltungsempfehlungen. In: Dinter, Barbara et al. (Hrsg.): Proceedings of
DW 2008 - Synergien durch Integration und Informationslogistik, St. Gallen
2008, S. 75-93.
[Burns 1957]
Burns, Tom: Management in Action. In: Operational Research Society 8 (1957)
2, S. 45-60.

Literatur 163
[CA 2008]
CA: CA Repository for Distributed Systems r2.3. http://www.ca.com
/~/media/Files/ProductBriefs/repository_dist_product_brief_147902.pdf, Abruf
am 12.11.2010.
[CA 2009]
CA: CA Repository for z/OS r7.1. http://www.ca.com/Files/ProductBriefs/mp-
31489-ca-rep-zos-pb_147905.pdf, Abruf am 12.11.2010.
[Capgemini 2008]
Capgemini: Studie IT-Trends 2008. Capgemini, München 2008.
[Cattell 1966]
Cattell, Raymond B.: The Scree Test for the Number of Factors. In: Multivariate
Behavioral Research 1 (1966), S. 245-276.
[Chae, Kim 2003]
Chae, Minhee; Kim, Jinwoo: What’s So Different About the Mobile Internet
In: Communications of the ACM 46 (2003) 12, S. 240-247.
[Chamoni, Hahne, Gluchowski 2005]
Chamoni, Peter; Hahne, Michael; Gluchowski, Peter: Business Information
Warehouse. Springer, Berlin 2005.
[Chengalur-Smith, Ballou, Pazer 1999]
Chengalur-Smith, InduShobha; Ballou, Donald P.; Pazer, Harold L.: The Impact
of Data Quality Information on Decision Making. In: IEEE Transactions
on Knowledge and Data Engineering 11 (1999) 6, S. 853-864.
[Cheung, Babin 2006]
Cheung, Waiman; Babin, Gilbert: A metadatabase-enabled executive information
system (Part A): A flexible and adaptable architecture. In: Decision Support
Systems 42 (2006), S. 1589–1598.
[Chung, Sampaio de Prado Leite 2009]
Chung, Lawrence; Sampaio de Prado Leite, Julio Cesar: On Non-Functional
Requirements in Software Engineering. In: Borgida, A. T. (Hrsg.): Conceptual
Modeling: Foundations and Applications. Springer, Berlin 2009, S. 363-379.
[Clark Jr, Jones, Armstrong Curtis 2007]
Clark Jr, Thomas D.; Jones, Mary C.; Armstrong Curtis, P.: The Dynamic
Structure of Management Support Systems: Theory Development, Research
Focus, and Direction. In: MIS Quarterly 31 (2007) 3, S. 579-615.
[Cykana, Paul, Stern 1996]
Cykana, Phil; Paul, Alta; Stern, Miranda: DOD guidelines on data quality management.
In: Wang, Richard Y. (Hrsg.): Proceedings of MIT IQ Conference
1996, S. 154-171.
[Dale 2001]
Dale, Adrian: Designing Taxonomies at Unilever. In: Knowledge Management
Review Vol. 3 (2001) Issue 6, S. 30-34.
[DAMA 2009]
DAMA: The DAMA Guide to the Data Management Body of Knowledge.
Technics Publications, New Jersey 2009.

164 Literatur
[Darke, Shanks 1996]
Darke, Peta; Shanks, Graeme: Stakeholder Viewpoints in Requirements Definition:
A Framework for Understanding Viewpoint Development Approaches. In:
Requirements Engineering 1 (1996) 2, S. 88-105.
[Davis 1993]
Davis, Alan M.: Software Requirements: Objects, Functions, and States. Prentice
Hall, Upper Saddle River 1993.
[Davis 1989]
Davis, Fred D.: Perceived Usefulness, Perceived Ease of Use, and User Acceptance
of Information Technology. In: MIS Quartely 13 (1989) 3, S. 318-340.
[Dempsey, Heery 1998]
Dempsey, Lorcan; Heery, Rachel: Metadata: A Current View of Practice and
Issues. In: Journal of Documentation 54 (1998) 2, S. 145-172.
[Deng et al. 2008]
Deng, Xiaodong; Doll, William J.; Al-Gahtani, Said S.; Larsen, Tor J.; Pearson,
John Michael; Raghunathan, T. S.: A Cross-Cultural Analysis of the End-User
Computing Satisfaction Instrument: A Multi-Group Invariance Analysis. In: Information
& Management 45 (2008), S. 211-220.
[Dhaliwal, Benbasat 1996]
Dhaliwal, Jasbir S.; Benbasat, Izak: The Use and Effects of Knowledge-based
System Explanations: Theoretical Foundations and a Framework for Empirical
Evaluation. In: Information Systems Research 7 (1996) 3, S. 343-362.
[Dietz 2006]
Dietz, Jan L. G.: Enterprise Ontology - Theory and Methodology. Springer,
Berlin 2006.
[Dietz 2007]
Dietz, Jan L. G.: Architecture. Building Strategy into Design. Academic Service,
The Hague 2007.
[Dinter 2002]
Dinter, Barbara: Metadatenmanagement: Ein Plan zur "Schatzsuche". In: von
Maur, Eitel; Winter, Robert (Hrsg.): Proceedings of Data Warehousing 2002,
Friedrichshafen 2002, S. 173-191.
[Djamasbi, Strong, Dishaw 2010]
Djamasbi, Soussan; Strong, Diane M.; Dishaw, Mark: Affect and Acceptance:
Examining the Effects of Positive Mood on the Technology Acceptance Model.
In: Decision Support Systems 48 (2010), S. 383-394.
[Dziuban, Shirkey 1974]
Dziuban, Charles D.; Shirkey, Edwin C.: When is a Correlation Matrix Appropriate
for Factor Analysis In: Psychological Bulletin 81 (1974) 6, S. 358-361.
[Edmunds, Morris 2000]
Edmunds, Angela; Morris, Anne: The Problem of Information Overload in
Business Organisations: a Review of the Literature. In: International Journal of
Information Management 20 (2000) 1, S. 17-28.
[Eickhoff 1999]
Eickhoff, Birgit: Gleichstellung von Frauen und Männern in der Sprache. In:
Sprachspiegel 55 (1999) 1, S. 2-6.

Literatur 165
[Elam, Leidner 1995]
Elam, Joyce J.; Leidner, Dorothy G.: EIS Adoption, Use, Impact: The Executive
Perspective. In: Decision Support Systems 14 (1995), S. 89-103.
[Eldridge et al. 2000]
Eldridge, Marge; Lamming, Mik; Flynn, Mike; Jones, Chris; Pendlebury, David:
Studies of Mobile Document Work and Their Contributions to the Satchel
Project. In: Personal and Ubiquitous Computing 4 (2000) 2-3, S. 102-112.
[English 1999]
English, Larry P.: Improving Data Warehouse and Business Information Quality:
Methods for Reducing Costs and Increasing Profits. Wiley Computer, New
York 1999.
[Eriksson, Penker 2000]
Eriksson, Hans-Erik; Penker, Magnus: Business Modelling with UML - Business
Patterns at Work. John Wiley & Sons, New York 2000.
[Even, Shankaranarayanan, Watts 2006]
Even, Adir; Shankaranarayanan, Ganesan; Watts, Stephanie: Enhancing Decision
Making with Process Metadata: Theoretical Framework, Research Tool,
and Exploratory Examination. In: Sprague, Ralph H. (Hrsg.): Proceedings of
39th Hawaii International Conference on System Sciences, Kauai 2006, S. 1-10.
[Fahrmeier et al. 2007]
Fahrmeier, Ludwig; Künstler, Rita; Pigeot, Iris; Tutz, Gerhard: Statistik. 6.
Aufl., Springer, Berlin 2007.
[Felber, Budin 1989]
Felber, Helmut; Budin, Gerhard: Terminologie in Theorie und Praxis. Gunter
Narr, Tübingen 1989.
[Fiedler 1964]
Fiedler, Fred E.: A Contingency Model of Leadership Effectiveness. In: Advances
in Experimental Social Psychology 1 (1964), S. 149-190.
[Financial Times 2008]
Financial Times: Market values and share price on March 30, 2007.
http://www.ft.com/cms/s/0/0224b1f2-264a-11dc-8e18-000b5df10621dwp
_uuid=95d63dfa-257b-11de-b338-000b5df10621.html, Abruf am 03.02.2008.
[Finkelstein et al. 1992]
Finkelstein, Anthony; Kramer, Jeff; Nuseibeh, Bashar Ahmad; Finkelstein, L.;
Goedicke, Michael: Viewpoints: A Framework for Integrating Multiple Perspectives
in System Development. In: International Journal on Software Engineering
and Knowledge Engineering 2 (1992) 1, S. 31-58.
[Fisher, Chengalur-Smith, Ballou 2003]
Fisher, Craig W.; Chengalur-Smith, InduShobha; Ballou, Donald P.: The Impact
of Experience and Time on the Use of Data Quality Information in Decision
Making. In: Information System Research 14 (2003) 2, S. 170-188.
[Foshay 2005]
Foshay, Neil: The Influence of End-user Metadata on User Attitudes toward,
and Use of a Data Warehouse. IBM, Somers 2005.

166 Literatur
[Foshay, Mukherjee, Taylor 2007]
Foshay, Neil; Mukherjee, Avinandan; Taylor, Andrew: Does Data Warehouse
End-User Metadata Add Value In: Communications of the ACM 50 (2007) 11,
S. 70-77.
[Frie, Strauch 2001]
Frie, Thorsten; Strauch, Bernhard: Die Informationsbedarfsanalyse im Data
Warehousing - ein methodischer Ansatz am Beispiel der Balanced Scorecard.
In: Britzelmaier, B. Geberl S. Weinmann S. (Hrsg.): Proceedings of 3. Liechtensteinisches
Wirtschaftsinformatik-Symposium, Stuttgart 2001, S. 239-252.
[Gabler 2010]
Gabler: Gabler Wirtschaftslexikon. Gabler, Wiesbaden 2010.
[Gartner 2008]
Gartner: Gartner EXP Worldwide Survey of 1,500 CIOs Shows 85 Percent of
CIOs Expect Significant Change Over Next Three Years.
http://www.gartner.com/it/page.jspid=587309, Abruf am 29.03.2010.
[Gartner 2009]
Gartner: Gartner EXP Worldwide Survey of More than 1,500 CIOs Shows IT
Spending to Be Flat in 2009. http://www.gartner.com/it/page.jspid=855612,
Abruf am 29.03.2010.
[Gartner 2010]
Gartner: Gartner EXP Worldwide Survey of Nearly 1,600 CIOs Shows IT
Budgets in 2010 to be at 2005 Levels. http://www.gartner.com/
it/page.jspid=1283413, Abruf am 16.04.2010.
[Glinz 2007]
Glinz, Martin: On Non-Functional Requirements. In: Glinz, Martin; Heymans,
Patrick (Hrsg.): Proceedings of 15th IEEE International Requirements Engineering
Conference, Delhi 2007, S. 21-26.
[Gluchowski, Gabriel, Dittmar 2008]
Gluchowski, Peter; Gabriel, Roland; Dittmar, Carsten: Management Support
Systems und Business Intelligence - Computergestützte Informationssysteme
für Fach- und Führungskräfte. Springer, Berlin 2008.
[Gluchowski, Kemper 2006]
Gluchowski, Peter; Kemper, Hans-Georg: Quo Vadis Business Intelligence In:
BI-Spektrum 1 (2006) 1, S. 12-19.
[Grady, Caswell 1987]
Grady, Robert B.; Caswell, Deborah L.: Software Metrics: Establishing a Company-wide
Program. Prentice Hall, Upper Saddle River 1987.
[Grant 1996]
Grant, Robert M.: Toward a Knowledge-Based Theory of the Firm. In: Strategic
Management Journal 17 (1996) Winter Special Issue, S. 109-122.
[Gregor, Jones 2007]
Gregor, Shirley; Jones, David: The Anatomy of a Design Theory. In: Journal of
the Association for Information Systems 8 (2007) 5, S. 312-335.
[Grochla 1976]
Grochla, Erwin: Praxeologische Organisationstheorie durch sachliche und methodische
Integration. In: Zeitschrift für betriebswirtschaftliche Forschung 28
(1976) 10, S. 617-637.

Literatur 167
[Gutzwiller 1994]
Gutzwiller, Thomas A.: Das CC RIM-Referenzmodell für den Entwurf von betrieblichen,
transaktionsorientierten Informationssystemen. Physica, Heidelberg
1994.
[Hair Jr et al. 2006]
Hair Jr, Joseph F.; Black, William C.; Babin, Barry J.; Anderson, Rolph E.; Tatham,
Ronald L.: Multivariate Data Analysis. 6. Aufl., Prentice Hall, Upper
Saddle River 2006.
[Hales 1986]
Hales, Colin P.: What Do Managers Do A Critical Review of the Evidence. In:
Journal of Management Studies 23 (1986) 1, S. 88-115.
[Härdle, Simar 2003]
Härdle, Wolfgang; Simar, Léopold: Applied Multivariate Statistical Analysis.
Springer, Berlin 2003.
[Harmsen 1997]
Harmsen, Anton Frank: Situational Method Engineering. Dissertation, University
of Twente, Twente 1997.
[Harper, Sellen 1995]
Harper, Richard; Sellen, Abigail: Collaborative Tools and the Practicalities of
Professional Work at the International Monetary Fund. In: Katz, I. R. et al.
(Hrsg.): Proceedings of Conference on Human Factors in Computing Systems,
Denver 1995, S. 122-129.
[Hayes 2000]
Hayes, Diane S.: Evaluation and Application of a Project Charter Template to
Improve the Project Planning Process. In: Process Management Journal 31
(2000) 1, S. 14-23.
[Heutschi 2007]
Heutschi, Roger: Serviceorientierte Architektur. Dissertation, Universität St.
Gallen, St. Gallen 2007.
[Hevner, Chatterjee 2010]
Hevner, Alan R.; Chatterjee, Samir: Design Research in Information Systems:
Theory and Practice. Springer, Berlin 2010.
[Hevner et al. 2004]
Hevner, Alan R.; March, Salvatore T.; Park, Jinsoo; Ram, Sudha: Design
Science in Information Systems Research. In: MIS Quarterly 28 (2004) 1, S.
75-105.
[Hoogervorst 2009]
Hoogervorst, Jan A. P.: Enterprise Governance and Enterprise Engineering.
Springer, Berlin 2009.
[Horváth 2006]
Horváth, Péter: Controlling. 10. Aufl., Franz Vahlen, München 2006.
[Houdeshel, Watson 1987]
Houdeshel, George; Watson, Hugh J.: The Management Information and Decision
Support (MIDS) System at Lockheed-Georgia. In: MIS Quarterly 11
(1987) 1, S. 127-140.

168 Literatur
[Huber 1983]
Huber, Georg P.: Cognitive Style as a Basis for MIS and DSS design: Much
Ado about Nothing In: Management Science 29 (1983) 5, S. 567-579.
[Hüner, Otto 2009]
Hüner, Kai M.; Otto, Boris: The Effect of Using a Semantic Wiki for Metadata
Management: A Controlled Experiment. In: Sprague, Ralph H. (Hrsg.): Proceedings
of 42nd Hawaii International Conference on System Sciences, Waikoloa
2009, S. 1-9.
[Huysmans 1970a]
Huysmans, Jan H. B. M.: The Effectiveness of the Cognitive-Style Constraint
in Implementing Operations Research Proposals. In: Management Science 17
(1970a) 1, S. 92-104.
[Huysmans 1970b]
Huysmans, Jan H. B. M.: The Implementation of Operations Research. John
Wiley & Sons, New York 1970b.
[IEEE 1990]
IEEE: IEEE Standard Glossary of Software Engineering Terminology. IEEE
Computer Society, New York 1990.
[IEEE 2000]
IEEE: IEEE Recommended Practice for Architectural Description of Software
Intensive Systems (IEEE Std 1471-2000). IEEE Computer Society, New York
2000.
[IFPUG 2010]
IFPUG: Function Point Counting Practices Manual - Release 4.3.1. International
Function Point User Group (IFPUG), Princetion Junction 2010.
[Inmon, O'Neil, Fryman 2008]
Inmon, William H.; O'Neil, Bonnie; Fryman, Lowell: Business Metadata - Capturing
Enterprise Knowledge. Morgan Kaufmann, San Francisco 2008.
[Inmon, Strauss, Neushloss 2008]
Inmon, William H.; Strauss, Derek; Neushloss, Genia: DW 2.0: The Architecture
for the Next Generation of Data Warehousing. Elsevier Science, Amsterdam
2008.
[ISO 1999]
ISO: ISO 12620:1999 Computer applications in terminology -- Data categories.
International Organization for Standardization, Genf 1999.
[Jarke et al. 2000]
Jarke, Matthias; Lenzerini, Maurizio; Vassiliou, Yannis; Vassiliadis, Panos:
Fundamentals of Data Warehouses. Springer, Berlin 2000.
[JBoss 2008]
JBoss: MetaMatrix Enterprise Data Services Platform. http://www.jboss.com/
pdf/0508_MetaMatrixFAQ.pdf, Abruf am 12.11.2010.
[Jung 1959]
Jung, Carl: Psychological Types. Pantheon Books, New York 1959.
[Jung 2006]
Jung, Reinhard: Architekturen zur Datenintegration. Gestaltungsempfehlungen
auf der Basis fachkonzeptueller Anforderungen. Deutscher Universitäts-Verlag,
Wiesbaden 2006.

Literatur 169
[Kaiser 1958]
Kaiser, Henry F.: The Varimax Criterion for Analytic Rotation in Factor Analysis.
In: Psychometrika 23 (1958) 3, S. 187-200.
[Kaiser, Dickman 1959]
Kaiser, Henry F.; Dickman, Kern W.: Analytic Determination of Common Factors.
In: American Psychological Reports 14 (1959), S. 425-430.
[Kelly 1988]
Kelly, J. N.: Executive Information Systems. In: Patricia Seybold's Office
Computing Report 11 (1988) 12, S. 77-83.
[Kemper 1999]
Kemper, Hans-Georg: Architektur und Gestaltung von Management-
Unterstützungssystemen - Von isolierten Einzelsystemen zum integrierten Gesamtansatz.
Teubner, Wiesbaden 1999.
[Kemper, Mehanna, Unger 2006]
Kemper, Hans-Georg; Mehanna, Walid; Unger, Carsten: Business Intelligence -
Grundlagen und praktische Anwendungen. 2. Aufl., Friedrich Vieweg & Sohn,
Wiesbaden 2006.
[Kemper, Pedell 2008]
Kemper, Hans-Georg; Pedell, Burkhard: Business Intelligence im Controlling -
Ergebnisse einer empirischen Studie. Arbeitsbericht, Lehrstühle Wirtschaftsinformatik
1 und Controlling, Universität Stuttgart, Stuttgart 2008.
[Kieser, Kubicek 1992]
Kieser, Alfred; Kubicek, Herbert: Organisation. 3. Aufl., De Gruyter, Berlin,
New York 1992.
[Kimball, Ross 2002]
Kimball, Ralph; Ross, Margy: The Data Warehouse Toolkit. 2. Aufl., John Wiley
& Sons, New York 2002.
[Kingston 2001]
Kingston, Geoffrey: Cost Benefit Analysis in Theory and Practice. In: The Australian
Economic Review 34 (2001) 4, S. 478-487.
[Koegler 2010]
Koegler, Scott: Embracing a Metadata Strategy. http://www.ciostrategycenter.
com/Res/analytics/embracing_metadata_strat/index.html, Abruf am 06.05.2010.
[KOFRAH 2005]
KOFRAH, Konferenz der Gleichstellungs-und Frauenbeauftragten an Schweizer
Universitäten und Hochschulen: Zielsetzung. http://www.unige.ch/
rectorat/codefuhes/kofrah-index_fichiers/Page394.htm, Abruf am 24.07.2009.
[Koroknay 1993]
Koroknay, Jeffrey W.: Software Development Using Process Project Management.
In: Proceedings of PMI Seminar/Symposium, San Diego 1993, S. 544-
552.
[Kotonya 1999]
Kotonya, Gerald: Practical Experience with Viewpoint-Oriented Requirements
Specification. In: Requirements Engineering 4 (1999) 3, S. 115-133.
[Kotonya, Sommerville 1992]
Kotonya, Gerald; Sommerville, Ian: Viewpoints for Requirements Definition.
In: Software Engineering Journal 7 (1992) 6, S. 375-387.

170 Literatur
[Kotonya, Sommerville 1998]
Kotonya, Gerald; Sommerville, Ian: Requirements Engineering: Processes and
Techniques. John Wiley & Sons, New York 1998.
[Kremer, Kolbe, Brenner 2003]
Kremer, Stefan; Kolbe, Lutz M.; Brenner, Walter: Do you know your terms -
A procedure model for Terminology Management. In: Proceedings of European
Conference on Information Systems, Neapel 2003, S. 1-16.
[Kubicek 1975]
Kubicek, Herbert: Empirische Organisationsforschung. Poeschel, Stuttgart
1975.
[Kubicek 1977]
Kubicek, Herbert: Heuristische Bezugsrahmen und heuristisch angelegte Forschungsdesigns
als Elemente einer Konstruktionstheorie empirischer Forschung.
In: Köhler, Richard (Hrsg.): Empirische und handlungstheoretische
Forschungskonzeptionen in der Betriebswirtschaftslehre. Poeschel, Stuttgart
1977, S. 3-36.
[Kuhlen, Seeger, Strauch 2004]
Kuhlen, Rainer; Seeger, Thomas; Strauch, Dietmar: Grundlagen der praktischen
Information und Dokumentation. K. G. Saur, München 2004.
[Kumar, Welke 1992]
Kumar, Kuldeep; Welke, Richard J.: Methodology Engineering - A Proposal
for Situation-Specific Methodology Construction. In: Cotterman, William W.;
Senn, James A. (Hrsg.): Challenges and Strategies for Research in Systems Development.
John Wiley & Sons, New York 1992, S. 257-269.
[Lamberti, Wallace 1987]
Lamberti, Donna; Wallace, William A.: Presenting Uncertainty in Expert Systems:
An Issue in Information Portrayal. In: Information & Management 13
(1987), S. 159-169.
[Lamming et al. 2000]
Lamming, Mik; Eldridge, Marge; Flynn, Mike; Jones, Chris; Pendlebury, David:
Satchel: Providing Access to Any Document, Any Time, Anywhere. In:
ACM Transactions on Computer-Human Interaction 7 (2000) 3, S. 322-352.
[Landes, Studer 1995]
Landes, Dieter; Studer, Rudi: The Treatment of Non-Functional Requirements
in MIKE. In: Schäfer, Wilhelm; Botalla, Pere (Hrsg.): Proceedings of European
Software Engineering Conference, Sitges 1995, S. 1-13.
[Laplante 2009]
Laplante, Phillip A.: Requirements Engineering for Software and Systems.
CRC Press, Boca Raton 2009.
[Laudon, Laudon 2006]
Laudon, Kenneth C.; Laudon, Jane P.: Management Information Systems -
Managing the Digital Firm. 10. Aufl., Prentice Hall, Upper Saddle River 2006.
[Lederer, Smith 1988]
Lederer, Albert L.; Smith, George L.: Individual Differences and Decision-
Making Using Various Levels of Aggregation of Information. In: Journal of
Management Information Systems 5 (1988) 3, S. 53-69.

Literatur 171
[Lee et al. 2006]
Lee, Yang W.; Pipino, Leo L.; Funk, James D.; Wang, Richard Y.: Journey to
Data Quality. MIT Press, Boston 2006.
[Lehmann 2001]
Lehmann, P.: Meta-Datenmanagement in Data-Warehouse-Systemen. Rekonstruierte
Fachbegriffe als Grundlage einer konstruktiven, konzeptionellen Modellierung.
Dissertation, Universität Magdeburg, Magdeburg 2001.
[Lehmann, Jaszewski 1999]
Lehmann, Peter; Jaszewski, Johann: Business Terms as a Critical Success Factor
for Data Warehousing. In: Proceedings of CAiSE 1999 - International
Workshop on Design and Management of Data Warehouses, Heidelberg 1999,
S. 1-5.
[Leité, Freeman 1991]
Leité, Julio C. S. P.; Freeman, Peter A.: Requirements Validation Through
Viewpoint Resolution. In: IEEE Transactions on Software Engineering 17
(1991) 12, S. 1253-1269.
[Levine, Siegel 2001]
Levine, Marc; Siegel, Joel: What the Accountant Must Know About Data Warehousing.
In: The CPA Journal 71 (2001) 1, S. 37-42.
[Li, Lu, Zhang 2009]
Li, Niu; Lu, Jie; Zhang, Guangquan: Business Intelligence. In: Li, Niu; Lu, Jie;
Zhang, Guangquan (Hrsg.): Cognition-Driven Decision Support for Business
Intelligence. Springer, Berlin 2009, S. 19-29.
[Luftman, Kempaiah, Rigoni 2009]
Luftman, Jerry N.; Kempaiah, Rajkumar; Rigoni, Eduardo Henrique: Key Issues
for IT Executives 2008. In: MIS Quarterly Executive 8 (2009) 3, S. 151-
159.
[Lux 2010]
Lux, Carsten: Business Metadata Management with ASG-Rochade. Allen Systems
Group, Zurich 2010.
[Mao, Benbasat 2000]
Mao, Ji-Ye; Benbasat, Izak: The Use of Explanations in Knowledge-Based Systems:
Cognitive Perspectives and a Process-Tracing Analysis. In: Journal of
Management Information Systems 17 (2000) 2, S. 153-179.
[March, Hevner 2007]
March, Salvatore T.; Hevner, Alan R.: Integrated Decision Support Systems: A
Data Warehousing Perspective. In: Decision Support Systems 43 (2007) 3, S.
1031-1043.
[March, Smith 1995]
March, Salvatore T.; Smith, Gerald F.: Design and Natural Science Research on
Information Technology. In: Decision Support Systems 15 (1995) 4, S. 251-
266.
[Marco 2000]
Marco, David: Building and Managing the Meta Data Repository. John Wiley
& Sons, New York 2000.

172 Literatur
[Marco, Jennings 2004]
Marco, David; Jennings, Michael: Universal Meta Data Models. John Wiley &
Sons, New York 2004.
[Martinsons, Davison 2007]
Martinsons, Maris G.; Davison, Robert M.: Strategic Decision Making and
Support Systems: Comparing American, Japanese and Chinese Management.
In: Decision Support Systems 43 (2007), S. 284-300.
[Maslow 1999]
Maslow, Abraham W.: Motivation und Persönlichkeit. Rowohlt Taschenbuch,
Reinbek 1999.
[Mayer 1999]
Mayer, Jörg H.: Führungsinformationssysteme für die internationale Management-Holding.
Deutscher Universitäts-Verlag, Wiesbaden 1999.
[McClelland 1962]
McClelland, David C.: Business Drive and National Achievement. In: Harvard
Business Review 40 (1962) 4, S. 113-122.
[McCoy, Galletta, King 2007]
McCoy, Scott; Galletta, Dennis F.; King, William R.: Applying TAM across
Cultures: The Need for Caution. In: European Journal of Information Systems
16 (2007) 1, S. 81-90.
[McCracken 2010]
McCracken, Harry: iPad vs. Everything Else. In: PC World 28 (2010) 6, S. 76-
86.
[McKnight 1999]
McKnight, William: Data Warehouse Justification and ROI. In: DM Review 9
(1999) 11, S. 1-3.
[Media Awareness Network 2000]
Media Awareness Network: Knowing What's What and What's Not - The 5 Ws
(and 1 "H") of Cyberspace. http://www.media-awareness.ca/english/resources/
special_initiatives/wa_resources/wa_shared/tipsheets/5Ws_of_cyberspace.cfm,
Abruf am 10.09.2010.
[Melchert 2006]
Melchert, Florian: Integriertes Metadatenmanagement: Methode zur Konzeption
von Metadatenmanagementsystemen für das Data Warehousing. Logos, Berlin
2006.
[Millet, Mawhinney 1992]
Millet, Ido; Mawhinney, Charles H.: Executive Information Systems: A Critical
Perspective. In: Information & Management 23 (1992) 2, S. 83-92.
[Mintzberg 1975]
Mintzberg, Henry: The Manager's Job: Folklore and Fact. In: Harvard Business
Review 53 (1975) 4, S. 49-61.
[Mintzberg 1994a]
Mintzberg, Henry: The Rise and Fall of Strategic Planning. Prentice Hall, Upper
Saddle River 1994a.

Literatur 173
[Mintzberg 1994b]
Mintzberg, Henry: Rounding out the Manager's Job. In: Sloan Management
Review 36 (1994b) 1, S. 11-26.
[Mosley 2008]
Mosley, Mark: DAMA-DMBOK Functional Framework Version 3. DAMA
International 2008.
[Müller, Stöhr, Rahm 1999]
Müller, Robert; Stöhr, Thomas; Rahm, Erhard: An Integrative and Uniform
Model for Metadata Management in Data Warehousing Environments. In: Gatziu,
S. et al. (Hrsg.): Proceedings of International Workshop on Design and
Management of Data Warehouses, Heidelberg 1999, S. 12-28.
[Myers 1976]
Myers, Isabel Briggs: Introduction to Type. Center for Applications of Psychological
Type, Gainesville 1976.
[National Information Standards Organization 2004]
National Information Standards Organization: Understanding Metadata. NISO
Press, Bethesda 2004.
[Nevo, Wand 2005]
Nevo, Dorit; Wand, Yair: Organizational Memory Information Systems: A
Transactive Memory Approach. In: Decision Support Systems 39 (2005), S.
549-562.
[Niland, Rouse, Stahl 2006]
Niland, Joyce C.; Rouse, Layla; Stahl, Douglas C.: An Informatics Blueprint for
Healthcare Quality Information Systems. In: Journal of the American Medical
Informatics Association 13 (2006) 4, S. 402-417.
[Nord, Nord 1995]
Nord, Jeretta Horn; Nord, G. Daryl: Executive Information Systems: A Study
and Comparative Analysis. In: Information & Management 29 (1995) 2, S. 95-
106.
[Nutt 1986]
Nutt, Paul C.: Evaluating MIS Design Principles. In: MIS Quarterly 10 (1986)
2, S. 139-158.
[O'Neil 2007]
O'Neil, Bonnie: Semantics and Business Meta-Data. http://www.tdan.com/
view-articles/4934, Abruf am 24.02.2010.
[Ortner 1997]
Ortner, Erich: Methodenneutraler Fachentwurf: zu den Grundlagen anwendungsorientierter
Informatik. B. G. Teubner Verlagsgesellschaft, Stuttgart 1997.
[Paech, Kerkow 2004]
Paech, Barbara; Kerkow, Daniel: Non-Functional Requirements Engineering -
Quality is Essential. In: Proceedings of Requirements Engineering: Foundation
for Software Quality, Riga 2004, S. 27-40.
[Pappas 1988]
Pappas, K.: Executive Information Systems Help Senior Exes Manage More
Effectively. In: PC Week 16 (1988) 2, S. 16.

174 Literatur
[Peffers et al. 2006]
Peffers, Ken; Tuunanen, Tuure; Gengler, Charles E.; Rossi, Matti; Hui, Wendy;
Virtanen, Ville; Bragge, Johanna: The Design Science Research Process: A
Model for Producing and Presenting Information Systems Research. In: Chatterjee,
Samir; Hevner, Alan (Hrsg.): Proceedings of 1st International Conference
on Design Science in Information Systems and Technology, Claremont
2006, S. 83-106.
[Peffers et al. 2007]
Peffers, Ken; Tuunanen, Tuure; Rothenberger, Marcus A.; Chatterjee, Samir: A
Design Science Research Methodology for Information Systems Research. In:
Journal of Management Information Systems 24 (2007) 3, S. 45–77.
[Pettey, Stevens 2010]
Pettey, Christy; Stevens, Holly: Gartner EXP Worldwide Survey of Nearly
1,600 CIOs Shows IT Budgets in 2010 to be at 2005 Levels.
http://www.gartner.com/it/page.jspid=1283413, Abruf am 16.04.2010.
[Pfeffer, Salancik 2003]
Pfeffer, Jeffrey; Salancik, Gerald R.: The External Control of Organizations: A
Resource Dependence Perspective. Stanford University Press, Stanford 2003.
[Pijpers et al. 2001]
Pijpers, Augustinus G. M.; Bemelmanns, Theo M. A.; Heemstra, Fred; van
Montfort, Kees A. G. M.: Senior Executive use of information technology. In:
Information and Software Technology 43 (2001) 1, S. 959-971.
[Pipe 1997]
Pipe, Pamela: The Data Mart: A New Approach to Data Warehousing. In: International
Review of Law Computers 11 (1997) 2, S. 251-261.
[Pollert, Kirchner, Polzin 2001]
Pollert, Achim; Kirchner, Bernd; Polzin, Javier Morato: Das Lexikon der Wirtschaft:
Grundlegendes Wissen von A bis Z. Dudenverlag, Mannheim 2001.
[Powell, Johnson 1995]
Powell, Philip L.; Johnson, Johnnie E. V.: Gender and DSS Design: The Research
Implications. In: Decision Support Systems 14 (1995), S. 27-58.
[Power 2008]
Power, Daniel J.: Decision Support Systems: A Historical Overview. In: Burstein,
Frada; Holsapple, Clyde W. (Hrsg.): Handbook on Decision Support Systems
1: Basic Themes. Springer, Berlin 2008, S. 121-140.
[Price, Shanks 2005]
Price, Rosanne; Shanks, Graeme: A Semiotic Information Quality Framework:
Development and Comparative Analysis. In: Journal of Information Technology
20 (2005) 2, S. 88-102.
[Project Management Institute 2004]
Project Management Institute: A Guide to the Project Management Body of
Knowledge. 3. Aufl., Project Management Institute, Newtown Square 2004.
[Rainer, Watson 1995]
Rainer, R. Kelly; Watson, Hugh J.: What Does It Take for Successful Executive
Information Systems In: Decision Support Systems 14 (1995) 2, S. 147-156.

Literatur 175
[Raskino, Lopez 2008]
Raskino, Mark; Lopez, Jorge: The Gartner/Forbes Executive Survey. Gartner,
Stamford 2008.
[Robertson, Robertson 2006]
Robertson, Suzanne; Robertson, James: Mastering Requirements Engineering.
Addison-Wesley, Boston 2006.
[Rockart, Treacy 1989]
Rockart, John F.; Treacy, Michael E.: The CEO goes on-line. In: Nelson, Ryan
R. (Hrsg.): End-user computing: Concepts, issues, and applications. John Wiley
& Sons, New York 1989, S. 55-64.
[Rossi, Sein 2003]
Rossi, Matti; Sein, Maung K.: Design Research Workshop: A Proactive Research
Approach. http://www.cis.gsu.edu/~emonod/epistemology/Sein%20and
%20Rossi%20-%20design%20research%20-%20IRIS.pdf, Abruf am
10.10.2009.
[Rowe, Boulgarides 1983]
Rowe, Alan J.; Boulgarides, James D.: Decision Styles - A Perspective. In:
Leadership & Organizational Development Journal 4 (1983) 4, S. 3-9.
[Rowe, Boulgarides 1992]
Rowe, Alan J.; Boulgarides, James D.: Managerial Decision Making: A Guide
to Successful Business Decisions. Macmillan, New York 1992.
[Sabherwal, Jeyaraj, Chowa 2006]
Sabherwal, Rajiv; Jeyaraj, Anand; Chowa, Charles: Information System Success:
Individual and Organizational Determinants. In: Management Science 52
(2006) 12, S. 1849-1864.
[Saenz et al. 2009]
Saenz, Oscar A.; Chen, Chin-Sheng; Centeno, Martha; Giachetti, Ronald E.:
Defining Enterprise Systems Engineering. In: International Journal of Industrial
and Systems Engineering 4 (2009) 5, S. 483-501.
[SAP 2008]
SAP: SAP BusinessObjects Metadata Management. http://download.sap.com/
solutions/sapbusinessobjects/brochures/download.epdcontext=
3DA2F0FFF18907F833951E803A2D13F06F8ED8122EEFF0DC
E14406763FE034365524A835D3720F6FD960E65FE6734DF7E232F6EA266
BB48, Abruf am 12.11.2010.
[Schmaltz 2009]
Schmaltz, Moritz: Methode zur Messung und Steigerung der individuellen Akzeptanz
von Informationslogistik in Unternehmen. Dissertation, Universität St.
Gallen, St. Gallen 2009.
[Schubert, Klein 2006]
Schubert, Klaus; Klein, Martina: Das Politiklexikon. Dietz, Bonn 2006.
[Schulze et al. 2009]
Schulze, Klaus-Dieter; Besbak, Ursula; Dinter, Barbara; Overmeyer, Alexander;
Schulz-Sacharow, Christoph; Stenzel, Elmar: Business Intelligence-Studie
2009. Steria Mummert Consulting AG, Hamburg 2009.

176 Literatur
[Schwarz, Strauch, Rowohl 2000]
Schwarz, Stefan; Strauch, Bernhard; Rowohl, Frederic: Entwicklung einer integrierten
Metadatenmanagement-Lösung für das Data Warehousing. Universität
St. Gallen, St. Gallen 2000.
[Scott Morton 1984]
Scott Morton, Michael S.: Management Decision Systems: Computer-Based
Support for Desicion Making. In: McFarlan, F. Warren (Hrsg.): The Information
Research Challenge. Harvard University Press, Boston 1984, S. 13-41.
[Seeley, Targett 1999]
Seeley, Monica; Targett, David: Patterns of Senior Executives' Personal Use of
Computers. In: Information & Management 35 (1999), S. 315-330.
[Sen 2004]
Sen, Arun: Metadata Management: Past, Present, and Future. In: Decision Support
Systems 37 (2004) 1, S. 151-173.
[Sena, Olson 1996]
Sena, James A.; Olson, Dag H.: Decision Support for the Administrative Man:
A Prototype DSS Case. In: European Journal of Information Systems 5 (1996),
S. 10-23.
[Shankaranarayanan, Even 2004]
Shankaranarayanan, Ganesan; Even, Adir: Managing Metadata in Data Warehouses:
Pitfalls and Possibilities. In: Communications of the Association for Information
Systems 14 (2004), S. 247-274.
[Shankaranarayanan, Even 2006]
Shankaranarayanan, Ganesan; Even, Adir: The metadata enigma. In: Communications
of the ACM 49 (2006) 2, S. 88-94.
[Shankaranarayanan, Even, Watts 2006]
Shankaranarayanan, Ganesan; Even, Adir; Watts, Stephanie: The Role of
Process Metadata and Data Waulity Perceptions in Decision Making: An Empirical
Framework and Investigation. In: Journal of Information Technology
Management 17 (2006) 1, S. 51-68.
[Shankaranarayanan, Watts 2003]
Shankaranarayanan, Ganesan; Watts, Stephanie: A Relevant Believable Approach
for Data Quality Assessment. In: Eppler, Martin et al. (Hrsg.): Proceedings
of International Conference on Information Quality (IQ 2003), Boston
2003, S. 178-189.
[Shankaranarayanan, Ziad, Wang 2003]
Shankaranarayanan, Ganesan; Ziad, Mostapha; Wang, Richard Y.: Managing
Data Quality in Dynamic Decision Environments: An Information Product Approach.
In: Journal of Database Management 14 (2003) 4, S. 14-32.
[Simon 1955]
Simon, Herbert A.: A Behavioral Model of Rational Choice. In: The Quarterly
Journal of Economics 69 (1955) 1, S. 99-118.
[SOA 2009]
SOA: Repository Manager. http://www.soa.com/Resource_Center/Data_Sheets/
data_SOA_RepositoryManager.pdf, Abruf am 12.11.2010.
[Sommerville 2010]
Sommerville, Ian: Software Engineering. 6. Aufl., Pearson, München 2010.

Literatur 177
[Spender 1996]
Spender, John-Christopher: Making Knowledge the Basis of a Dynamic Theory
of the Firm. In: Strategic Management Journal 17 (1996) Winter Special Issue,
S. 45-62.
[Stedman 1999]
Stedman, Craig: Metadata. In: Computerworld 33 (1999) 42, S. 74.
[Stelzer 2009]
Stelzer, Dirk: Enterprise Architecture Principles: Literature Review and Research
Directions. In: Aier, Stephan; Schelp, Joachim; Schönherr, Marten
(Hrsg.): Proceedings of Workshop on Trends in Enterprise Architecture Research,
Stockholm 2009, S. 21-35.
[Stock, Gubler 2009]
Stock, Daniel; Gubler, Philipp: A Data Model for Terminology Management of
Analytical Information. In: Albano, Valentina; Mola, Lapo; D'Atri, Alessandro
(Hrsg.): Proceedings of European Students Workshop on Information Systems
2009 (ESWIS 2009), Verona 2009, S. 1-14.
[Tannenbaum 2002]
Tannenbaum, Adrienne: Metadata Solutions: Using Metamodels, Repositories,
XML, and Enterprise Portals to Generate Information on Demand. Addison-
Wesley, Boston 2002.
[Thomas 1987]
Thomas, Charles R.: Field Independence and Myers-Briggs Thinking Individuals.
In: Perceptual and Motor Skills 57 (1987) 3, S. 790.
[Thompson 2004]
Thompson, Bruce: Exploratory and Confirmatory Factor Analysis: Understanding
Concepts and Applications. American Psychological Association, Washington,
DC 2004.
[Tozer 1999]
Tozer, Guy: Metadata Management for Information Control and Business Success.
Artech House, Norwood 1999.
[Tractinsky, Meyer 1999]
Tractinsky, Noam; Meyer, Joachim: Chartjunk or Goldgraph Effects of Presentation
Objectives and Content Desirability on Information Presentation. In:
MIS Quarterly 23 (1999) 3, S. 397-420.
[Triano 2002]
Triano, Richard M.: Metadata Projects – A Yardstick Toward Success. Database
Design Solutions, Bernardsville 2002.
[Tuomi 1999]
Tuomi, Ilkka: Data is More Than Knowledge: Implications of the Reversed
Knowledge Hierarchy for Knowledge Management and Organizational Memory.
In: Journal of Management Information Systems 16 (1999) 3, S. 107-121.
[Ulrich, Barney 1984]
Ulrich, David; Barney, Jay B.: Perspectives in Organizations: Resource Dependence,
Efficiency, and Population. In: The Academy of Management Review 9
(1984) 3, S. 471-481.

178 Literatur
[Vaduva, Vetterli 2001]
Vaduva, Anca; Vetterli, Thomas: Metadata Management for Data Warehousing:
An Overview. In: International Journal of Cooperative Information Systems
10 (2001) 3, S. 273-298.
[Vaishnavi, Kuechler 2007]
Vaishnavi, Vijay K.; Kuechler, William, Jr.: Design Science Research Methods
and Patterns: Innovating Information and Communication Technology. Auerbach
Publications, New York 2007.
[van Lamsweerde 2001]
van Lamsweerde, Axel: Goal-Oriented Requirements Engineering: A Guided
Tour. In: Society, IEEE Computer (Hrsg.): Proceedings of 5th IEEE International
Symposium on Requirements Engineering, Toronto 2001, S. 249-263.
[van Slooten, Hodes 1996]
van Slooten, Kees; Hodes, Bert: Characterizing IS Development Projects. In:
Brinkkemper, Sjaak; Lyytinen, Kalle; Welke, Richard J. (Hrsg.): Proceedings of
Working Conference on Method Engineering, Atlanta 1996, S. 29-44.
[Vandenbosch, Huff 1997]
Vandenbosch, Betty; Huff, Sid L.: Searching and Scanning: How Executives
Obtain Information from Executive Information Systems. In: MIS Quarterly 21
(1997) 1, S. 81-107.
[Venkatesh, Davis 2000]
Venkatesh, Viswanath; Davis, Fred D.: A Theoretical Extension of the Technology
Acceptance Model: Four Longitudinal Field Studies. In: Management
Science 46 (2000) 2, S. 186-204.
[Venkatesh et al. 2003]
Venkatesh, Viswanath; Morris, Michael G.; Davis, Gordon Bitter; Davis, Fred
D.: User Acceptance of Information Technology: Toward A Unified View. In:
MIS Quarterly 27 (2003) 3, S. 425-478.
[vom Brocke 2007]
vom Brocke, Jan: Design Principles for Reference Modeling - Reusing Information
Models by Means of Aggregation, Specialization, Instantiation, and
Analogy. In: Fettke, Peter; Loos, Peter (Hrsg.): Reference Modeling for Business
Systems Analysis. Idea Group, Hershey 2007, S. 47-75.
[vom Brocke, Buddendick 2006]
vom Brocke, Jan; Buddendick, Christian: Reusable Conceptual Models - Requirements
Based on the Design Science Research Paradigm. In: Chatterjee,
Samir; Hevner, Alan (Hrsg.): Proceedings of DESRIST 2006, Claremont 2006,
S. 576-604.
[vom Brocke et al. 2009]
vom Brocke, Jan; Simons, Alexander; Niehaves, Björn; Riemer, Kai; Plattfaut,
Ralf; Cleven, Anne: Reconstructing the Giant: On the Importance of Rigour in
Documenting the Literature Search Process. In: Newell, Sue et al. (Hrsg.): Proceedings
of 17th European Conference On Information Systems, Verona 2009,
S. 2206–2217.
[Wall 1993]
Wall, Kent D.: A Model of Decision Making under Bounded Rationality. In:
Journal of Economic Behavior and Organization 21 (1993), S. 331-352.

Literatur 179
[Walls, Widmeyer, El Sawy 1992]
Walls, Joseph G.; Widmeyer, George R.; El Sawy, Omar A.: Building an Information
System Design Theory for Vigilant EIS. In: Information Systems Research
3 (1992) 1, S. 36-59.
[Walstrom, Wilson 1997]
Walstrom, Kent A.; Wilson, Rick L.: An Examination of Information Systems
(EIS) Users. In: Information & Management 32 (1997), S. 75-83.
[Walter, Lopez 2008]
Walter, Zhiping; Lopez, Melissa Succi: Physician Acceptance of Information
Technologies: Role of Perceived Threat to Professional Autonomy. In: Decision
Support Systems 46 (2008), S. 206-215.
[Wand, Wang 1996]
Wand, Yair; Wang, Richard Y.: Anchoring Data Quality Dimensions in Ontological
Foundations. In: Communications of the ACM 39 (1996) 11, S. 86-95.
[Wang 1998]
Wang, Richard Y.: A Product Perspective on Total Data Quality Management.
In: Communications of the ACM 41 (1998) 2, S. 58-65.
[Wang et al. 1998]
Wang, Richard Y.; Lee, Yang W.; Pipino, Leo L.; Strong, Diane M.: Manage
Your Information as a Product. In: Sloan Management Review 39 (1998) 4, S.
95-105.
[Wang, Strong 1996]
Wang, Richard Y.; Strong, Diane M.: Beyond Accuracy: What Data Quality
Means to Data Consumers. In: Journal of Management Information Systems 12
(1996) 4, S. 5-34.
[Warmouth, Yen 1992]
Warmouth, Michael T.; Yen, David: A Detailed Analysis of Executive Information
Systems. In: International Journal of Information Management 12 (1992),
S. 192-208.
[Waters 2010]
Waters, John K.: Enter the iPAD (or not). In: T.H.E. Journal 37 (2010) 6, S.
38-45.
[Watson et al. 1995]
Watson, Hugh J.; Watson, Richard T.; Singh, Sanjay; Holmes, David T.: Development
Practises of Executive Information Systems: Findings of a Field
Study. In: Decision Support Systems 14 (1995), S. 171-184.
[Webster, Watson 2002]
Webster, Jane; Watson, Richard T.: Analyzing the Past to prepare for the Future:
Writing a Literature Review. In: MIS Quarterly 26 (2002) 2, S. 13-23.
[Wegener 2007]
Wegener, Hans: Aligning Business and IT with Metadata - The Financial Services
Way. Wiley & Sons 2007.
[Wegener, Auth 2002]
Wegener, Hans; Auth, Gunnar: Die Swiss Re Data Language - Erfahrungen mit
Terminologiemanagement im Rahmen des Data Warehousing. In: von Maur,
Eitel; Winter, Robert (Hrsg.): Proceedings of Data Warehousing 2002, Friedrichshafen
2002, S. 193-213.

180 Literatur
[Wernerfelt 1984]
Wernerfelt, Birger: A Resource-Based View of the Firm. In: Strategic Management
Journal 5 (1984) 2, S. 171-180.
[West, Hess 2002]
West, Lawrence A.; Hess, Traci J.: Metadata as a Knowledge Management
Tool: Supporting Intelligent Agent and End User Access to Spatial Data. In:
Decision Support Systems 32 (2002), S. 247-264.
[Whitman, Mattord 2007]
Whitman, Michael R.; Mattord, Herbert H.: Principles of Information Security.
3. Aufl., Course Technology, Boston 2007.
[Willcocks, Whitley, Avgerou 2008]
Willcocks, Leslie P.; Whitley, Edgar A.; Avgerou, Chrisanthi: The Ranking of
Top IS Journals: A Perspective from the London School of Economics. In: European
Journal of Information Systems 17 (2008), S. 163–168.
[Winter 2008]
Winter, Robert: Design Science Research in Europe. In: European Journal of
Information Systems 17 (2008) 5, S. 470-475.
[Winter et al. 2007]
Winter, Robert; Baskerville, Richard; Frank, Ulrich; Heinzl, Armin; Hevner,
Alan R.; Venable, John R.: Relevance and Rigour - What are Acceptable Standards
and How are they Influenced In: Wirtschaftsinformatik 49 (2007) 5, S.
403-409.
[Winter, Fischer 2007]
Winter, Robert; Fischer, Ronny: Essential Layers, Artifacts, and Dependencies
of Enterprise Architecture. In: Journal of Enterprise Architecture 3 (2007) 2, S.
7-18.
[Winter, Gericke, Bucher 2009]
Winter, Robert; Gericke, Anke; Bucher, Tobias: Method versus Model – Two
Sides of the Same Coin In: Albani, A.; et al. (Hrsg.): Proceedings of CIAO!
2009 and EOMAS 2009, Amsterdam 2009, S. 1-15.
[Winter, Jung 2002]
Winter, Robert; Jung, Reinhard: Justification of Data Warehousing Projects. In:
Becker, Shirley A. (Hrsg.): Data Warehousing & Web Engineering. IRM Press,
Hershey 2002, S. 219-228.
[Winter, Strauch 2004]
Winter, Robert; Strauch, Bernhard: Information Requirements Engineering for
Data Warehouse Systems. In: Haddad, Hisham M. (Hrsg.): Proceedings of Applied
Computing 2004 - Proceedings of the 2004 ACM Symposion on Applied
Computing, Nicosia 2004, S. 1359-1365.
[Witkin et al. 1977]
Witkin, Herman A.; Moore, C. A.; Goodenough, Donald R.; Cox, P. W.: Field-
Dependent and Field-Independent Cognitive Styles and Their Educational Implications.
In: Review of Educational Research 47 (1977) 1, S. 1-64.
[Witte, Kallmann, Sachs 1981]
Witte, Eberhard; Kallmann, Andreas; Sachs, Gerd: Führungskräfte der Wirtschaft.
Poeschel, Stuttgart 1981.

Literatur 181
[Wixom, Watson 2001]
Wixom, Barbara H.; Watson, Hugh J.: An Empirical Investigation of the Factors
Affecting Data Warehousing Success. In: MIS Quarterly 25 (2001) 1, S.
17-41.
[Wixom, Watson 2010]
Wixom, Barbara H.; Watson, Hugh J.: The BI-Based Organization. In: International
Journal of Business Intelligence Research 1 (2010) 1, S. 13-28.
[Wolf 2005]
Wolf, Joachim: Organisation, Management, Unternehmensführung: Theorien
und Kritik. 2. Aufl., Gabler, Wiesbaden 2005.
[Xie et al. 2008]
Xie, Guotong; Yang, Yang; Liu, Shengping; Qiu, Zhaoming; Pan, Yue; Zhou,
Xiongzhi: 6th International Semantic Web Conference + 2nd Asian Semantic
Web Conference. In: Aberer, Karl (Hrsg.): Proceedings of The Semantic Web,
Busan 2008, S. 857-870.
[Young, Watson 1995]
Young, Dale; Watson, Hugh J.: Determinates of EIS Acceptance. In: Information
& Management 29 (1995) 3, S. 153-164.
[Zangemeister 1976]
Zangemeister, Christof: Nutzwertanalyse in der Systemtechnik: Eine Methodik
zur multidimensionalen Bewertung und Auswahl von Projektalternativen. 4.
Aufl. Aufl., Wittemannsche Buchhandlung, München 1976.
[Zmud 1979]
Zmud, Robert W.: Individual Differences and MIS Success: A Review of the
Empirical Literature. In: Management Science 25 (1979) 10, S. 966-977.

182 Lebenslauf des Autors
Lebenslauf des Autors
Persönliche Angaben
Name
Daniel Michael Nicolaus Stock
Geburtsdatum 29.10.1978
Geburtsort
Berlin, Deutschland
Schulische und universitäre Ausbildung
1989-1993 Gymnasium Neureut, Neureut, Deutschland; Abitur
1993-1994 Liskeard Secondary School, Liskeard, England; Auslandsjahr
1994-1999 Fichte Gymnasium, Karlsruhe, Deutschland; Abitur
2000-2006 Universität Karlsruhe (TH), Deutschland; Diplomstudium des Wirtschaftsingenieurwesens
2009-2010 Universität St. Gallen, Schweiz; Doktorandenstudium der Betriebswirtschaftslehre
Berufliche Tätigkeiten
1999-2000 ABC-Abwehrbataillon 750, Bruchsal, Deutschland; Wehrdienst
2002-2006 Institut für Angewandte Informatik und Formale Beschreibungsverfahren,
Universität Karlsruhe, Deutschland; Tutor
2005 Dresdner Bank, Frankfurt am Main, Deutschland; Praktikum
2006 DZ-Bank, Frankfurt am Main, Deutschland; Praktikum
2006 -2010 McKinsey & Company, Business Technology Office, Frankfurt am
Main, Deutschland; Berater
2008 -2010 Institut für Wirtschaftsinformatik, Universität St. Gallen, Schweiz;
Wissenschaftlicher Mitarbeiter am Lehrstuhl von Prof. Dr. Robert
Winter
Seit 2011
McKinsey & Company, Business Technology Office, Berlin,
Deutschland; Berater

Publikationsverzeichnis des Autors 183
Publikationsverzeichnis des Autors
Mayer, Jörg H.; Laartz, Jürgen; Habbel, Markus; Stock, Daniel: Emerging from the
economic crisis with a clearer view - A through-cycle approach to „Managing the
Company“ with the Corporate Navigator. Arbeitsbericht, Institut für Wirtschaftsinformatik,
Universität St. Gallen, St. Gallen 2009.
Mayer, Jörg H.; Stock, Daniel; Ganczarski, Wojciech: Steigerung der Flexibilität von
Unternehmenssteuerungssystemen - Detaillierung einer serviceorientierten Systemarchitektur.
Arbeitsbericht, Institut für Wirtschaftsinformatik, Universität St.
Gallen, St. Gallen 2009.
Mayer, Jörg H.; Stock, Daniel: Nutzertypen für die situative FIS-Gestaltung: Ergebnisse
einer empirischen Untersuchung. Zu erscheinen in: xxx (Hrsg.): Proceedings
of 10th International Conference on Wirtschaftsinformatik, Zurich 2011, S. 1-10.
Stock, Daniel: Functional Map for Business Metadata Tools. Arbeitsbericht, Institut
für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen 2010.
Stock, Daniel; Gubler, Philipp: A Data Model for Terminology Management of Analytical
Information. In: Albano, Valentina; Mola, Lapo; D’Atri, Alessandro
(Hrsg.): Proceedings of European Students Workshop on Information Systems
2009, Verona 2009, S. 1-14.
Stock, Daniel; Mayer, Jörg H.; Wortmann, Felix: Fachliche Metadaten: Kosten-
Nutzen-Analyse. In: BI-Spektrum 5 (2010) 2, S. 20-24.
Stock, Daniel; Mayer, Jörg H.; Winter, Robert: End-user Device Selection for Executives
– Adapting Executive Information Systems to Different Working Styles.
Arbeitsbericht, Institut für Wirtschaftsinformatik, Universität St. Gallen, St. Gallen
2010.
Stock, Daniel; Winter, Robert; Mayer, Jörg H.: Functional Service Domain Architecture
Management - Building the Foundation for Situational Method Engineering.
In: Pries-Heje, J. et al. (Hrsg.): Proceedings of IFIP WG 8.2/8.6 International
Working Conference, Perth 2010, S. 245-262.
Stock, Daniel; Winter, Robert: The Value of Business Metadata – Structuring the Benefits
in a Business Intelligence Context. In: D’Atri, A. et al. (Hrsg.): Proceedings
of VII Conference of the Italian Chapter of AIS, Neapel 2010, S. 1-8.

184 Publikationsverzeichnis des Autors
Stock, Daniel; Wortmann, Felix; Mayer, Jörg H.: Use Cases for Business Metadata –
A Viewpoint-Based Approach to Structuring and Prioritizing Business Needs. In:
Winter, Robert; Zhao, J. Leon; Aier, Stephan (Hrsg.): Proceedings of 5th International
Conference on Design Science Research in Information Systems and
Technology, St. Gallen 2010, S. 546-549.
Stock, Daniel; Wortmann, Felix; Mayer, Jörg H.: Use Cases for Business Metadata –
A Viewpoint-Based Approach to Structuring and Prioritizing Business Needs. In:
Abramowicz, W.; Tolksdorf, R.; Węcel, K. (Hrsg.): Proceedings of International
Conference on Business Information Systems, Berlin 2010, S. 226-237.
Stock, Daniel; Winter, Robert; Mayer, Jörg H.: User Preferences in MSS Design –
State of the Art and Proposal of a Research Agenda. Arbeitsbericht, Institut für
Wirtschaftsinformatik, Universität St. Gallen, St. Gallen 2010.

Hinweis zur Verwendung geschlechtsneutraler Formulierungen 185
Hinweis zur Verwendung geschlechtsneutraler Formulierungen
In der vorliegenden Dissertation werden konform der Zielsetzung der Konferenz der
Gleichstellungs- und Frauenbeauftragten an Schweizer Universitäten und Hochschulen
[KOFRAH 2005] die Empfehlungen der Dudenredaktion zur sprachlichen Gleichstellung
von Frauen und Männern [Eickhoff 1999] soweit möglich berücksichtigt.
Der Praxis der Dudenredaktion folgend [Eickhoff 1999: 3] wird jedoch im Sinne der
Lesbarkeit auf die Verwendung von Doppelnennungen und Kurzformen verzichtet.
Um die sprachliche Gleichbehandlung von Frauen und Männern zu gewährleisten,
wird deshalb – wo immer möglich – auf Partizipien oder Sachbezeichnungen an Stelle
von Personenbezeichnungen zurückgegriffen. Sofern dies aus sachlogischen Gründen
oder aus Gründen der sprachlichen Ästhetik nicht sinnvoll erscheint, wird in Ausnahmefällen
stellvertretend für beide Geschlechter und ohne Einschränkung der sprachlichen
Gleichstellung von Frauen und Männern die männliche Form verwendet.
Dadurch werden in der vorliegenden Dissertation Frauen und Männer gleichermaßen
berücksichtigt.