b-kide: a framework and a tool for business...
TRANSCRIPT
PhD Thesis
B-KIDE: A Framework and a Tool for
Business Process Oriented Knowledge
Infrastructure Development
Markus B. Strohmaier
————————————–
Institute for Knowledge Management and Knowledge Visualization
Graz University of Technology, Austria
Head: Univ.-Prof. Dr. Klaus Tochtermann
In cooperation with Know-Center Graz
Evaluator: Univ.-Prof. Dr. Klaus Tochtermann
Supervisor: Univ.-Prof. Dr. Klaus Tochtermann
Second Reader: Univ.-Prof. Dr.Dr.h.c.mult. Hermann Maurer
Publisher: Shaker Verlag, January 2005. ISBN: 3-8322-3620-1
2
Preface
This PhD thesis1 comprises the key results of my intensive research performed
at the Know-Center Graz during the last years. Knowledge management as a sci-
entific domain has fascinated me since the very first time I encountered it. The
generation of new knowledge about knowledge management appeared to be both
a challenging and deeply satisfying task to me. My research was and is based
on the hypothesis that understanding knowledge as the critical factor in today’s
economy is key to achieving sustainable success for organizations. Therefore, the
Know-Center Graz, Austria’s competence center for knowledge based systems
and applications, represented a more than suitable environment for me to pursue
this PhD.
I would like to thank the people who contributed to and supported me in the
realization of this work: Klaus Tochtermann, my professor and advisor, devel-
oped a profound infrastructure and a creative environment for researchers at the
Know-Center. He was always available for critical and constructive discussions
about my ideas and concepts. I value your commitment to my research. Her-
mann Maurer, initiator of the Know-Center and my second reader, sparked off
my interest in research on knowledge infrastructures through the development of
the MT-Model for knowledge management systems (also see chapter 1). Stefanie
Lindstaedt, my division manager, gave me the opportunity and freedom to es-
tablish the domain of business process oriented knowledge management as a key
area of research at the Know-Center. All the people from the companies I have
1The document at hand represents a revised version of the PhD thesis completed by theauthor in December 2004.
conducted projects with always challenged my hypotheses and provided valuable
feedback. Thank you.
Johann Gotschl, and all participants of his philosophical circle for PhD stu-
dents, provided a deep source of inspiration and wisdom for my research as well
as for my life. Thank you.
The “Wissensmanagement Forum Graz”, and all members of this community
of motivated people, represented a dynamic and stimulating environment for me
that allowed for experimenting with ideas as well as with myself. Thank you.
Tobias Ley, Herwig Rollett, Peter Scheir and all other colleagues at the Know-
Center were always available for open-minded, thrilling and humorous discussions
about work, life and research. Thank you.
My parents, Gerda and Walter, taught me that curiosity is a quality. You
have always supported me in learning and advancing throughout my life. Thank
you.
And Pia - Thank you.
Graz, January 2005 Markus B. Strohmaier
4
Zusammenfassung (German abstract)
Die Notwendigkeit des effektiven Managements von Wissen wird heute von
Unternehmen zunehmend erkannt. Um diesem Anspruch gerecht zu werden,
wurden neue vielversprechende und umfassende Technologien von Wirtschaft
und Wissenschaft entwickelt. Mit der Verfugbarkeit und Weiterentwicklung
dieser Innovationen verstarkte sich auch die Bereitschaft von Unternehmen neue
Wissensmanagement-Technologien anzuwenden. Die erfolgreiche Anwendung in
Unternehmen stellt jedoch eine komplexe, mehrdimensionale Herausforderung
und ein aktuelles Forschungsgebiet dar. Die vorliegende Dissertation nimmt
sich deshalb diesem Thema an und stellt einen Framework fur die Entwicklung
von geschaftsprozessunterstutzenden, technologischen Wissensinfrastrukturen
vor. Wahrend dabei Geschaftsprozesse den organisatorischen Rahmen fur die
Anwendung von Wissensmanagement-Technologien bieten, so reprasentieren
Wissensinfrastrukturen ein Konzept, dass Wissensmanagement in Organisatio-
nen ermoglicht. Der in dieser Dissertation entwickelte B-KIDE Framework bietet
Unterstutzung in der Entwicklung von Wissensinfrastrukturen, welche innovative
Wissensmanagementfunktionalitaten beinhalten und sichtbar organisatorische
Geschaftsprozesse unterstutzen, an. Das entwickelte B-KIDE Tool erleichtert die
Anwendung des B-KIDE Frameworks fur Entwickler von Wissensinfrastrukturen.
Drei durchgefuhrte, empirische Studien mit Unternehmen unterschiedlichster
Branchen bekraftigen die Relevanz und Viabilitat der eingefuhrten Konzepte.
Schlusselworter: Wissensmanagement, Wissensinfrastrukturen, Geschaftspro-
zesse, Systemanalyse, Systemgestaltung, Entwicklungsinstrumente
5
Abstract
The need for an effective management of knowledge is gaining increasing
recognition in today’s economy. To acknowledge this fact, new promising and
powerful technologies have emerged from industrial and academic research.
With these innovations maturing, organizations are more and more willing to
adapt such new knowledge management technologies to improve their knowledge
intensive businesses. However, the successful application in given business
contexts is a complex, multidimensional challenge and a current research
topic. Therefore, this PhD thesis addresses this challenge and introduces a
framework for the development of business process-supportive, technological
knowledge infrastructures. While business processes represent the organizational
setting for the application of knowledge management technologies, knowledge
infrastructures represent a concept that can enable knowledge management
in organizations. The B-KIDE Framework introduced in this work provides
support for the development of knowledge infrastructures that comprise in-
novative knowledge management functionality and are visibly supportive of
an organization’s business processes. The developed B-KIDE Tool eases the
application of the B-KIDE Framework for knowledge infrastructure developers.
Three empirical studies that were conducted with industrial partners from
heterogeneous industry sectors corroborate the relevance and viability of the
introduced concepts.
Keywords: Knowledge Management, Knowledge Infrastructures, Business
Processes, System Analysis, System Design, Development Tools
Contents
1 Introduction 21
1.1 Research Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.1.1 Challenge 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.1.2 Challenge 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.1.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2 Focus of this PhD Work . . . . . . . . . . . . . . . . . . . . . . . 26
1.2.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.2.2 Demarcation . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.2.3 Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.3 PhD Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . 29
1.4 Terms and Definitions . . . . . . . . . . . . . . . . . . . . . . . . 30
2 Knowledge Infrastructure Development 34
2.1 The Knowledge Infrastructure Development Project . . . . . . . . 34
2.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.2.1 Knowledge Manager . . . . . . . . . . . . . . . . . . . . . 36
2.2.2 Project Manager . . . . . . . . . . . . . . . . . . . . . . . 37
2.2.3 Knowledge Worker . . . . . . . . . . . . . . . . . . . . . . 37
2.2.4 Knowledge Analyst . . . . . . . . . . . . . . . . . . . . . . 37
2.2.5 Knowledge Infrastructure Designer . . . . . . . . . . . . . 38
2.3 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.1 System Analysis . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.2 Requirements Engineering . . . . . . . . . . . . . . . . . . 39
2.3.3 System Design . . . . . . . . . . . . . . . . . . . . . . . . 39
2.3.4 System Usage . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4 Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6
CONTENTS 7
2.4.1 Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.2 Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.3 V-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.4 Rational Unified Process . . . . . . . . . . . . . . . . . . . 42
2.5 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.6 Relevant Scientific Domains . . . . . . . . . . . . . . . . . . . . . 43
2.7 Assessment in the Context of this Work . . . . . . . . . . . . . . . 45
3 Business Process Oriented Knowledge Management 47
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2 Overview of Challenges and Approaches . . . . . . . . . . . . . . 48
3.3 Business Process Analysis . . . . . . . . . . . . . . . . . . . . . . 49
3.4 Business Process Modeling . . . . . . . . . . . . . . . . . . . . . . 49
3.4.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.3 Selected Approaches . . . . . . . . . . . . . . . . . . . . . 50
3.5 Business Process Learning . . . . . . . . . . . . . . . . . . . . . . 51
3.5.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.5.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.5.3 Selected Approaches . . . . . . . . . . . . . . . . . . . . . 52
3.6 Business Process Support . . . . . . . . . . . . . . . . . . . . . . 53
3.6.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.6.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.6.3 Selected Approaches . . . . . . . . . . . . . . . . . . . . . 54
3.7 Business Process Execution . . . . . . . . . . . . . . . . . . . . . 56
3.7.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.7.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.7.3 Selected Approaches . . . . . . . . . . . . . . . . . . . . . 57
3.8 Business Process Improvement . . . . . . . . . . . . . . . . . . . . 59
3.8.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.8.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.8.3 Selected Approaches . . . . . . . . . . . . . . . . . . . . . 60
3.9 Assessment in the Context of this Work . . . . . . . . . . . . . . . 61
3.10 Focal Point of this PhD Work . . . . . . . . . . . . . . . . . . . . 63
CONTENTS 8
4 Principle Approach 65
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2 Principle Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3 Central Concept of Modeling Knowledge Processes . . . . . . . . 67
4.3.1 On Modeling Aspects of Organizations . . . . . . . . . . . 67
4.3.2 Illustration of Modeling Knowledge Processes . . . . . . . 68
4.3.3 Characteristics of Knowledge Processes . . . . . . . . . . . 70
4.4 Characteristics of Knowledge Infrastructures Following this Prin-
ciple Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5 Conceptualization of this PhD Work . . . . . . . . . . . . . . . . 72
4.5.1 B-KIDE Context . . . . . . . . . . . . . . . . . . . . . . . 73
4.5.2 B-KIDE Model Architecture . . . . . . . . . . . . . . . . . 73
4.5.3 B-KIDE Method . . . . . . . . . . . . . . . . . . . . . . . 73
4.5.4 B-KIDE Tool . . . . . . . . . . . . . . . . . . . . . . . . . 73
5 B-KIDE Framework 75
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2 B-KIDE Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.2.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2.5 Technological Environment . . . . . . . . . . . . . . . . . . 77
5.3 B-KIDE Model Architecture . . . . . . . . . . . . . . . . . . . . . 77
5.3.1 B-KIDE Modeling Structure . . . . . . . . . . . . . . . . . 78
5.3.2 B-KIDE Modeling Technique . . . . . . . . . . . . . . . . 86
5.4 B-KIDE Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.4.1 Design Process “Designing Knowledge Infrastructures” . . 91
5.4.2 B-KIDE Knowledge Infrastructure Template Architecture . 95
5.5 Remarks on B-KIDE Framework Application . . . . . . . . . . . . 98
6 B-KIDE Tool 100
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
CONTENTS 9
6.1.3 B-KIDE Tool Approach . . . . . . . . . . . . . . . . . . . 102
6.2 B-KIDE Tool Structure . . . . . . . . . . . . . . . . . . . . . . . . 103
6.3 B-KIDE Modeling Structure Mapping . . . . . . . . . . . . . . . . 105
6.3.1 Reference Models . . . . . . . . . . . . . . . . . . . . . . . 105
6.3.2 Interview Data . . . . . . . . . . . . . . . . . . . . . . . . 106
6.4 B-KIDE Tool Application . . . . . . . . . . . . . . . . . . . . . . 107
6.4.1 Setup and Pre-Modeling . . . . . . . . . . . . . . . . . . . 107
6.4.2 Interviewing . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.4.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.5 B-KIDE Tool Support for the B-KIDE Framework Application . . 113
6.6 B-KIDE Tool Implementation . . . . . . . . . . . . . . . . . . . . 114
7 Proof of Concept 118
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.2 Case Study 1: Software Industry . . . . . . . . . . . . . . . . . . 120
7.2.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.2.2 Pursued Goals . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.2.3 Approach Taken . . . . . . . . . . . . . . . . . . . . . . . 121
7.2.4 Achieved Results . . . . . . . . . . . . . . . . . . . . . . . 126
7.3 Pilot Study 1: Automotive Industry . . . . . . . . . . . . . . . . . 127
7.3.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.3.2 Pursued Goals . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.3.3 Approach Taken . . . . . . . . . . . . . . . . . . . . . . . 128
7.3.4 Achieved Results . . . . . . . . . . . . . . . . . . . . . . . 133
7.4 Pilot Study 2: Consulting Industry . . . . . . . . . . . . . . . . . 133
7.4.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7.4.2 Pursued Goals . . . . . . . . . . . . . . . . . . . . . . . . . 134
7.4.3 Approach Taken . . . . . . . . . . . . . . . . . . . . . . . 134
7.4.4 Achieved Results . . . . . . . . . . . . . . . . . . . . . . . 139
7.5 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
7.5.1 B-KIDE Framework . . . . . . . . . . . . . . . . . . . . . 140
7.5.2 B-KIDE Tool . . . . . . . . . . . . . . . . . . . . . . . . . 141
7.6 Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
CONTENTS 10
8 Future Work 146
8.1 On System Design and Implementation . . . . . . . . . . . . . . . 146
8.2 On Knowledge Process Optimization . . . . . . . . . . . . . . . . 147
8.3 On the Problem of Decoupled Knowledge Processes . . . . . . . . 147
8.4 On Oblivion of Knowledge . . . . . . . . . . . . . . . . . . . . . . 149
8.5 On Role-Orientation vs. Personalization . . . . . . . . . . . . . . 149
8.6 On Interactions between Knowledge Infrastructures and Business
Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
8.7 B-KIDE Framework Evolution Scenarios . . . . . . . . . . . . . . 150
8.8 B-KIDE Tool Evolution . . . . . . . . . . . . . . . . . . . . . . . 151
9 Future Applications 153
9.1 Identification of Knowledge Communities . . . . . . . . . . . . . . 154
9.2 Identification of Knowledge Risks . . . . . . . . . . . . . . . . . . 155
9.3 Raising KM Maturity Levels of Organizations . . . . . . . . . . . 155
9.4 Controlling of Knowledge-Based Strategies . . . . . . . . . . . . . 156
9.5 Enabling Intra-Organizational KM . . . . . . . . . . . . . . . . . 156
9.6 Ontology Engineering . . . . . . . . . . . . . . . . . . . . . . . . . 157
10 Conclusions 158
10.1 Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
10.2 Scientific Contributions . . . . . . . . . . . . . . . . . . . . . . . . 159
10.3 Final Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
A Quotes 162
B Research Approach 165
C Supporting Resources 169
C.1 Interview Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 169
C.1.1 B-KIDE Tool Preparation . . . . . . . . . . . . . . . . . . 169
C.1.2 Preparation for KI Analysts . . . . . . . . . . . . . . . . . 170
C.1.3 Preparation for Interviewees . . . . . . . . . . . . . . . . . 170
C.1.4 Documents necessary for Analysts . . . . . . . . . . . . . . 170
C.1.5 Documents necessary for Interviewees . . . . . . . . . . . . 171
C.1.6 Interview Setting . . . . . . . . . . . . . . . . . . . . . . . 171
CONTENTS 11
C.1.7 Interview Execution . . . . . . . . . . . . . . . . . . . . . 171
C.1.8 Interview Hints . . . . . . . . . . . . . . . . . . . . . . . . 173
C.2 Interview Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
D B-KIDE Tool Details 175
E Empirical Study Data 181
E.1 Case Study 1 - Software Industry . . . . . . . . . . . . . . . . . . 181
E.2 Pilot Study 1 - Automobile Industry . . . . . . . . . . . . . . . . 185
E.3 Pilot Study 2 - Consulting Industry . . . . . . . . . . . . . . . . . 187
Bibliography 190
Index 206
About the Author 209
List of Figures
1.1 Strategic Perspective on Knowledge Infrastructures (Based on
[Siv01]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2 Networks of Business Processes . . . . . . . . . . . . . . . . . . . 23
1.3 The Maurer-Tochtermann (MT) Model . . . . . . . . . . . . . . . 24
1.4 Structure of this PhD Thesis . . . . . . . . . . . . . . . . . . . . . 30
1.5 Relationships between Key Terms of this PhD Work (Based on
[Rem02]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.1 Knowledge Infrastructure Development Projects (Based on
[SAA+02]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1 A Model of bpoKM Challenges . . . . . . . . . . . . . . . . . . . 48
4.1 The Principle Approach of this PhD Work . . . . . . . . . . . . . 66
4.2 Object and Model Systems (Based on [Sin95]) . . . . . . . . . . . 68
4.3 Modeling Knowledge Work of Business Processes (Based on [Str03a]) 69
4.4 Illustration of Resulting Knowledge Processes (Based on [Str03a]) 70
4.5 The B-KIDE Framework Conceptualization of this PhD Work . . 72
4.6 Focus of the B-KIDE Tool . . . . . . . . . . . . . . . . . . . . . . 74
5.1 Context of Applying the B-KIDE Framework and Tool (Based on
[Tol98]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2 Scope of the B-KIDE Model Architecture . . . . . . . . . . . . . . 78
5.3 The B-KIDE Modeling Structure . . . . . . . . . . . . . . . . . . 79
5.4 The B-KIDE Business Process Perspective . . . . . . . . . . . . . 85
5.5 The B-KIDE Knowledge Process Perspective . . . . . . . . . . . . 86
5.6 The B-KIDE Modeling Technique . . . . . . . . . . . . . . . . . . 87
12
LIST OF FIGURES 13
5.7 Scope of the B-KIDE Method . . . . . . . . . . . . . . . . . . . . 91
5.8 Design Process “Designing Knowledge Infrastructures” . . . . . . 92
5.9 The Knowledge Infrastructure Template Architecture . . . . . . . 96
6.1 Scope of the B-KIDE Tool . . . . . . . . . . . . . . . . . . . . . . 101
6.2 Primary Actors of the B-KIDE Tool . . . . . . . . . . . . . . . . . 102
6.3 B-KIDE Tool Principle Approach . . . . . . . . . . . . . . . . . . 102
6.4 Simplified Illustration of B-KIDE Tool’s Main Structure and Ele-
ments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.5 Main User Interface of the B-KIDE Tool . . . . . . . . . . . . . . 104
6.6 Implementation of the B-KIDE Tool Reference Models . . . . . . 105
6.7 Implementation of the B-KIDE Tool Interview Forms . . . . . . . 106
6.8 Setting Up Interviews with the B-KIDE Tool . . . . . . . . . . . . 107
6.9 B-KIDE Tool’s Interview Forms per Interview . . . . . . . . . . . 108
6.10 Setting Up Reference Elements with the B-KIDE Tool . . . . . . 108
6.11 Inputting Interview Data with the B-KIDE Tool . . . . . . . . . . 109
6.12 Editing Reference Elements with the B-KIDE Tool . . . . . . . . 110
6.13 Creating Analysis Reports with the B-KIDE Tool . . . . . . . . . 111
6.14 The B-KIDE Tool Analysis Report “Business Process Landscape” 112
6.15 The B-KIDE Tool Analysis Report “Knowledge Process Landscape”113
6.16 Technological Fundament of the B-KIDE Tool: The .NET Frame-
work [Mica] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
6.17 Architectural Sketch of the B-KIDE Tool . . . . . . . . . . . . . . 116
7.1 The Modeling Procedure Applied in Case Study 1 . . . . . . . . . 121
7.2 The Design Method Applied in Case Study 1 . . . . . . . . . . . . 123
7.3 A High Level Conceptualization of the Anticipated Support for
Knowledge Flows in Case Study 1 . . . . . . . . . . . . . . . . . . 124
7.4 An Example of Knowledge Process Definition in Case Study 1 . . 125
7.5 Case Study 1 Results: Four Role Oriented Knowledge Portals . . 127
7.6 The Modeling Procedure Applied in Pilot Study 1 . . . . . . . . . 128
7.7 The Evaluation Method Applied in Pilot Study 1 . . . . . . . . . 130
7.8 A High Level Conceptualization of the Anticipated Support for
Knowledge Flows in Pilot Study 1 . . . . . . . . . . . . . . . . . . 131
7.9 An Example of Knowledge Process Definition in Pilot Study 1 . . 132
LIST OF FIGURES 14
7.10 The Modeling Procedure Applied in Pilot Study 2 . . . . . . . . . 134
7.11 The Design Method Applied in Pilot Study 2 . . . . . . . . . . . . 136
7.12 A High Level Conceptualization of the Anticipated Support for
Knowledge Flows in Pilot Study 2 . . . . . . . . . . . . . . . . . . 137
7.13 An Example of Knowledge Process Definition in Pilot Study 2 . . 138
9.1 Applying B-KIDE in Diverse Domains by Developing Additional
B-KIDE Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
9.2 Identification of Knowledge Communities with the B-KIDE Frame-
work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
B.1 The Design Research Approach (Based on [VK04]) . . . . . . . . 166
C.1 The Interview Plan Template . . . . . . . . . . . . . . . . . . . . 174
D.1 Property-Form for the Reference Element “Knowledge Domain” . 175
D.2 Property-Form for the Reference Element “Business Process” . . . 176
D.3 Property-Form for the Reference Element “Organizational Role” . 176
D.4 Property-Form for “Knowledge Work” . . . . . . . . . . . . . . . 176
D.5 Property-Form for the Reference Element “Storage Object” . . . . 177
D.6 Property-Form for the Reference Element “Transfer Object” . . . 177
D.7 Setup Form for the Definition of Storage and Transfer Object Types178
D.8 Knowledge Process Landscape Generation with the B-KIDE Tool
(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
D.9 Knowledge Process Landscape Generation with the B-KIDE Tool
(2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
D.10 Knowledge Process Landscape Generation with the B-KIDE Tool
(3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
D.11 Knowledge Process Landscape Generation with the B-KIDE Tool
(4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
E.1 Microsoft Excel c©Interview Template Applied in Case Study 1 . . 181
E.2 Manually created Landscape of Identified Knowledge Processes . . 182
E.3 UI Mockup of a Knowledge Portal Fragment for Role TL and Cor-
responding Knowledge Processes (KP) . . . . . . . . . . . . . . . 184
E.4 B-KIDE-generated Knowledge Process Landscape . . . . . . . . . 185
LIST OF FIGURES 15
E.5 Landscape of Knowledge Processes Selected for Improvement . . . 186
E.6 B-KIDE-generated Knowledge Process Landscape . . . . . . . . . 187
E.7 Landscape of Knowledge Processes Selected and Defined for Support188
List of Tables
2.1 Aspects of Knowledge Infrastructure Development . . . . . . . . . 36
5.1 B-KIDE Reference Models and Business Analogies . . . . . . . . . 83
5.2 B-KIDE Model Perspectives . . . . . . . . . . . . . . . . . . . . . 84
5.3 B-KIDE Modeling Technique Activities . . . . . . . . . . . . . . . 87
7.1 Overview of Conducted Studies . . . . . . . . . . . . . . . . . . . 119
7.2 Scope Definition and Interview Planning in Case Study 1 . . . . . 122
7.3 KI Focus: Definition of Knowledge Processes to be Supported . . 123
7.4 Scope Definition and Interview Planning in Pilot Study 1 . . . . . 129
7.5 KI Focus: Definition of Knowledge Processes to be Supported . . 131
7.6 Scope Definition and Interview Planning in Pilot Study 2 . . . . . 135
7.7 KI Focus: Definition of Knowledge Processes to be Supported . . 137
8.1 Maturity Stages of the KPQM [PP02] . . . . . . . . . . . . . . . . 148
E.1 Example of a Role-Oriented Knowledge Profile Based on Identified
Knowledge Processes (KP) . . . . . . . . . . . . . . . . . . . . . . 183
E.2 Example of a Role-Oriented Knowledge Profile Based on Selected
Knowledge Processes (KP) . . . . . . . . . . . . . . . . . . . . . . 189
16
List of Acronyms
API Application Programming Interface
ARIS Architektur integrierter Informationssysteme
B-KIDE Business process oriented Knowledge Infrastructure Development
B2B Business to Business
bpoKM business process oriented Knowledge Management
BPR Business Process Re-engineering
CAME Computer Aided Methodology Engineering
CASE Computer Aided Software Engineering or Computer Aided System Engi-
neering
CKO Chief Knowledge Officer
CLR Common Language Runtime
CLS Common Language Specification
CoP Communities of Practice
COTS Commercial Off The Shelf
CPI Continuous Process Improvement
CRC Cooperative Requirements Capture
EDM Engineering Data Management
EU European Union
17
LIST OF TABLES 18
FAQ Frequently Asked Questions
HCI Human Computer Interaction
HTML Hypertext Markup Language
ICT Information and Communication Technology
IL Intermediate Language
ISO International Standardization Organization
IT Information Technology
JAD Joint Application Design
KI Knowledge Infrastructure
KM Knowledge Management
KMS Knowledge Management System
KPQM Knowledge Process Quality Model
LPP Legitimate Peripheral Participation
N/A Not Available
OMIS Organizational Memory Information System
PhD Philosophiæ Doctor. Doctor (or Doctorate) of Philosophy
QFD Quality Function Deployment
R&D Research and Development
SVG Scalable Vector Graphics
UI User Interface
UML Unified Modeling Language
W3C World Wide Web Consortium
WFMS WorkFlow Management System
LIST OF TABLES 19
XML Extensible Markup Language
XSLT Extensible Stylesheet Language Transformations
Chapter 1
Introduction
Es ist so schwer, den Anfang zu finden. Oder besser: Es ist schwer, am Anfang
anzufangen. Und nicht zu versuchen, weiter zuruckzugehen.
Appendix Chapter A on page 162
Knowledge in modern economies is increasingly playing a key role in achiev-
ing organizational success. Knowledge management as a concept and a scientific
discipline emerged to acknowledge this fact. Three main reasons can be iden-
tified for this development [Siv01]. 1) Need: Today’s information technology-
enabled organizations have to process and make use of ever more information in
ever decreasing time cycles. 2) Recognition of need: Organizations increasingly
recognize the need for and the importance of conscious management of knowl-
edge [MRH+04]. 3) Availability of KM-Instruments: Past research activities
(such as [MT02, MR02, Leh02, LSF+02, Rol03]) and product innovations (such
as [Hyp, Liv, Lot]) in the field of knowledge management promise to provide
sound instruments for addressing current KM challenges and for enabling the
management of knowledge in organizational settings. Therefore, the emergence
of knowledge management as a scientific discipline represents an important step
towards more profound approaches in this domain.
Practicing knowledge management in organizations can be achieved through
the development and implementation of knowledge infrastructures [Siv01] (figure
1.1). In this work, knowledge infrastructures are defined as the set of all
successfully implemented interventions, measures, institutions and facilities
that represent a supportive knowledge environment for knowledge workers who
execute knowledge intensive tasks. These knowledge infrastructures consist
20
CHAPTER 1. INTRODUCTION 21
Figure 1.1: Strategic Perspective on Knowledge Infrastructures (Based on [Siv01])
of three main dimensions: 1) people 2) organizational- and 3) technological
systems. According to a Delphi study on the future of knowledge management1,
the successful integration of knowledge management efforts into an organiza-
tion’s business processes is regarded to be the most pressing and challenging
theoretical research issue for the understanding and advancement of knowledge
management. By taking the increasing number of organizations certified accord-
ing to a process oriented management standard into account [isoa, isob], the
importance of this issue is even more emphasized. Among others, these insights
motivated the PhD work at hand, which aims to enable the development of
technological knowledge infrastructures that are integrated in and supportive of
an organization’s knowledge intensive business processes. The following research
challenges are of utmost importance in the context of this objective.
1.1 Research Challenges
Current research in the domain of knowledge management identifies a large field
of new challenges concerning the development of organizational knowledge infras-
tructures. Among them, the following two are especially relevant in the context
1carried out in 2001/2002 by the Fraunhofer Competence Center Knowledge Management,Berlin and the Institute for Psychology of the Humboldt-University, Berlin [MHV03, chapter8]
CHAPTER 1. INTRODUCTION 22
of this work:
1.1.1 Challenge 1
Networks of Business Processes: Business process management deals with
the management, continuous improvement and optimization of business processes
[ISO00a]. In knowledge intensive organizations, business processes are typically
more and more knowledge intensive [ESR99] and interconnected. Instead of fo-
cussing only on the optimization of isolated business processes, current standards
for business process- and quality management (such as [ISO00a]) suggest that
organizations should investigate, support and improve their networks of busi-
ness processes, especially focussing on interactions between them [ISO00c, sec-
tion 5.1.2]. Figure 1.2 provides a sketch of such situations in an abstract yet
illustrative way.
Figure 1.2: Networks of Business Processes
Knowledge as the key resource of knowledge intensive organizations represents
a significant cause for interactions between knowledge intensive business processes
[Str03a]. By failing to focus on such interactions, an organization is not able to
optimize the sum of its efforts (its business process network), instead it is target-
ing local optima (specific business processes) that do not necessarily contribute
to an organization’s overall goals. Although today’s organizational knowledge
management initiatives already focus on multiple business processes rather than
on a single business process [MR02], surprisingly neither existing process stan-
dards (such as [ISO00b]) nor existing business process modeling techniques (such
as [Sch96]) nor knowledge management approaches provide comprehensive con-
cepts on how to tackle the identified challenge. [RL00] strikingly acknowledge
the need for scientific concepts in this area by stressing that successful support
for knowledge intensive business processes is, to a greater extent, a matter of
CHAPTER 1. INTRODUCTION 23
supporting knowledge flows (knowledge interactions that span multiple business
processes [Rem02]) rather than workflows.
1.1.2 Challenge 2
Knowledge Management Technologies: Today, a heterogeneous set of
knowledge management technologies is available from industrial vendors (such
as [Hyp, Liv, Lot] and others) as well as from academia (such as [WK02, Dus02,
Eng03, HTEN03] and others). Failures of technology-driven KM2 projects in the
past that did not take critical business requirements of organizations into account
[Rol03, Chapter 3] urgently call for concepts that aid the application and config-
uration of KM technologies to specific business contexts. KM technology itself
can today be classified according to different dimensions. The MT3-Model intro-
duced by [MT02] distinctly classifies KM system functionalities based on different
types of communication between people and technological systems. Each class is
represented through a specific arrow index.
Figure 1.3: The Maurer-Tochtermann (MT) Model
Description: Arrow 1 in figure 1.3 depicts all organizational and
human aspects of knowledge management that cannot be supported
2KM...Knowledge Management3MT...Maurer-Tochtermann
CHAPTER 1. INTRODUCTION 24
by a (technological) KM system4. Arrow 2 describes the explicit
user action of inputting data into a KM system. Arrow 3 symbol-
izes the ability of computer systems, to generate new knowledge and
autonomously perform appropriate actions based on the implicit in-
put of data by users without burdening them. Arrow 4 describes
that computer systems can generate knowledge about users by ob-
serving them and their behavior. Arrow 5 indicates that users can
obtain information from the system by simply requesting it through
e.g. queries. In arrow 6, the ability of systems to proactively contact
users with information (without being explicitly asked by the user)
is represented. Lastly, arrow 7 symbolizes that computer systems are
able to generate new knowledge (through combination [NT97]) based
on existing knowledge. [MT02] state that traditional information sys-
tems typically comprise functionality as described in arrows 2 and
5. Arrows 3, 4, 6 and 7 are considered to represent distinctive KM
system functionality.
The non-intrusive nature of “Arrow 3” functionality combined with its high
potential to support the execution of knowledge intensive business processes
especially makes this type of KM functionality the most promising one to
be effectively applied to specific, operative business contexts. The scientific
challenge that emerges from this conclusion is how such a business alignment
of KM functionality can be achieved. Therefore, research challenge 2 calls for
concepts that support the successful application of KM functionality5 to given
business contexts.
1.1.3 Summary
On one hand, business process management represents an organizational environ-
ment for knowledge workers in today’s organizations. On the other hand, knowl-
4The MT-Model of [MT02] can be dated back to work performed in 1999 and 2000. The term“KM-System”, used by [MT02] would today probably be substituted by the more appropriateterm “Knowledge Infrastructure”, which is not a term strongly (mis-)used by the softwareindustry and better describes the anticipated concepts.
5more specifically: “Arrow 3” KM functionality of the MT-Model
CHAPTER 1. INTRODUCTION 25
edge management technologies represent a technological environment for them.
Ultimately, both efforts aim to (separately) support organizations in achieving
their respective business goals and the need for approaches that integrate both
efforts becomes visible6. It is all the more remarkable that currently no scientific
concepts are applied that align both efforts to collectively achieve their goals in
a synergistical way. By overlooking this aspect, organizations fail to provide en-
vironments that comprehensively support knowledge workers in executing their
corresponding business processes.
From a knowledge perspective, these arguments raise the need for a scientific
approach that aids 1) the identification of knowledge flows across a set of busi-
ness processes and 2) the design of support for these flows (and corresponding
knowledge workers), reified in technological knowledge infrastructures in order
to:
1. Support the execution of knowledge intensive and interconnected business
processes in organizations
2. Support the reasonable application of KM functionality in given business
contexts
1.2 Focus of this PhD Work
1.2.1 Objectives
The research challenges introduced in section 1.1 provide a sound fundament for
the definition of more concrete objectives. Thus, this PhD work aims to:
Introduce a framework and an according tool that allows for the de-
velopment of business process-supportive, technological knowledge in-
frastructures for knowledge intensive organizations.
What is meant by “Business Process-Supportive”? Business process sup-
port addresses two main aspects: 1) Employee-level : Here the term refers
to role-oriented, technological support for knowledge workers in their daily
6This need has already been identified by e.g. [Gia99, WC03] in the context of businessprocesses and information systems
CHAPTER 1. INTRODUCTION 26
knowledge intensive business processes and 2) Organization-level : Here, business
process-supportive refers to support for the effective execution of networks of
business processes.
What is meant by “Knowledge Infrastructures”? Knowledge infrastructures
are the set of all successfully implemented interventions, measures, institutions
and facilities that represent a knowledge environment for conscious and un-
conscious organizational knowledge work. Knowledge infrastructures consist of
three main dimensions: 1) people, 2) organizational and 3) technological systems
(similar to [Siv01], also see definitions in section 1.4).
What is meant by “Knowledge Intensive Organizations”? Organizations that
deal with knowledge intensive goods and services (such as software or automo-
tive industry) are typically considered to be knowledge intensive. Knowledge
intensity itself can be assessed by a series of indicators such as knowledge half
life, learning times and others [ESR99].
A concept that addresses the development of business process-supportive,
technological knowledge infrastructures has to deal with the following require-
ments:
1. The application of the concept leads to knowledge infrastructure designs
that improve environments of knowledge workers for their respective knowl-
edge intensive business processes
2. The application of the concept leads to knowledge infrastructure designs
that enable role oriented access to knowledge for knowledge workers in or-
ganizations
3. The application of the concept leads to knowledge infrastructure designs
that enable autonomous routing of knowledge from/to corresponding knowl-
edge workers in their business processes
4. The application of the concept leads to knowledge infrastructure designs
that enforce a more standardized way of executing knowledge work in or-
ganizations
CHAPTER 1. INTRODUCTION 27
5. The application of the concept leads to increased transparency of knowl-
edge work in organizations and its implications for technological knowledge
infrastructures
1.2.2 Demarcation
This section demarcates the focus of this work regarding its targeted research
area:
Dimensions of Knowledge Infrastructures: Knowledge infrastructures are
considered to consist of various dimensions. This PhD work exclusively focuses
on designing technological aspects of knowledge infrastructures (also see the
outlined challenges in section 1.1).
Knowledge within or across vs. Knowledge about Business Processes: This
work focuses on identifying and supporting aspects of knowledge within or across
business processes. Knowledge about business processes represents the basis
for all investigations of this PhD work, yet there is no focus on providing this
knowledge to employees.
Knowledge and Constructivism vs. Realism: By defining knowledge as
information that is relevant for action (also see section 1.4), a constructivist
view on knowledge is employed. Business processes, together with corresponding
knowledge workers, accommodate this view by representing the context (the
action) in which knowledge is constantly being reconstructed.
Functionalities of KM systems: In the context of knowledge work in knowl-
edge intensive business processes that requires large amounts of relevant infor-
mation to be directed and transferred between knowledge workers and systems,
Arrow 3 of the MT-Model (figure 1.3) appears to be of special relevance. Arrow 3
depicts the ability to create new knowledge and perform subsequent appropriate
actions based on user interactions (with the KM system) without interfering with
the user’s work. To achieve this, KM systems are supposed to maintain linkages
between pieces of information and to transfer and/or handle information between
various organizational roles and systems according to certain conditions.
CHAPTER 1. INTRODUCTION 28
Therefore, this PhD work focuses its efforts on providing support for the design
of technological knowledge infrastructures that comprise “Arrow 3” functionality.
1.2.3 Non-Goals
This section describes further potential objectives that are relevant in this context
but which are not explicitly tackled within this work. Such non-goals include:
• considering cognitive factors and/or implications of technological knowledge
infrastructures
• considering pedagogical factors of providing and/or transferring knowledge
• considering HCI aspects of technological knowledge infrastructures
• considering aspects of different knowledge delivery options to respective
users (e.g. Push vs. Pull, representation, etc.)
• considering non-functional requirements of technological knowledge infras-
tructures such as security, modifiability, performance and others [BB98,
BCK98, RR99]
1.3 PhD Thesis Organization
Chapter 1 outlines the motivation for this work and identifies its main objectives.
Since this PhD work deals with knowledge infrastructures that aim to support
knowledge intensive business processes, chapters 2 and 3 introduce existing re-
search work in the domains of knowledge infrastructure development and business
process oriented knowledge management. Chapter 4 introduces the central idea
of this work in an illustrative and accessible way. In chapters 5 and 6 a framework
and an accompanying software tool which together tackle the identified challenges
of this work are described. Chapter 7 introduces three industrial studies that aim
to corroborate the developed concepts of this work. Chapters 8 and 9 point out
aspects that are not within the focus of this work, but play an important role
in future developments concerning the introduced concepts. Chapter 10 reflects
on the identified challenges as well as on the accomplishments of this work. The
main relations between the introduced chapters are illustrated in figure 1.4. The
CHAPTER 1. INTRODUCTION 29
research approach pursued in this work is introduced in greater detail in appendix
chapter B.
Figure 1.4: Structure of this PhD Thesis
1.4 Terms and Definitions
The following definitions clarify the meanings of central terms used in this PhD
work. While the definitions do not aim to describe the respective terms in a
holistic way, they narrow the meanings of these terms to provide explanations of
how they are used within this work.
Organizations are open, goal-oriented and combined social and technological
systems. They are open because of the manifold interactions with their envi-
ronment. Organizations are goal-oriented since all of their efforts are aligned
to respective business goals. Organizations represent combined social and
technological systems since organizational tasks are executed in collaborational
efforts between these systems [FS01, page 59].
CHAPTER 1. INTRODUCTION 30
Business process management deals with the explicit management of busi-
ness processes in organizations and focuses on the development, provision and
application of procedural knowledge. According to [ISO00b, p. 23], a process
is a “set of interrelated or interacting activities which transforms inputs into
outputs”. Additionally (in this PhD work), business processes are regarded to
be knowledge intensive and contribute to organizational value chains. Process
agents represent humans (employers and employees) responsible for executing
activities in organizational business processes.
Knowledge management deals with the conscious management of organi-
zational knowledge through knowledge management interventions. (Organi-
zational) knowledge is defined as information that is relevant for executing
certain (business) actions. Knowledge management interventions are the set
of all potential organizational initiatives that aim to improve an organization’s
knowledge infrastructure. They can become, if successfully deployed, an integral
part of knowledge infrastructures.
A striking distinction between business process and knowledge management
can be made by the simplistic interpretation that business process management
focuses on managing flows of organizational work, while knowledge management
focuses on the management of flows of organizational knowledge. Although the
term “flow” used here poses problems7, the analogy introduced represents a
practical approach to the domain at hand. By using this distinction, process
management can be regarded to be part of and a sound basis for knowledge
management by already putting effort into managing organizational knowledge
about “flows of work”.
Knowledge processes describe distributed, organizational knowledge work.
They are regarded to run within or across a set of business processes. Here,
7Knowledge is regarded to be context sensitive, continuously reconstructed by subjects andthus, cannot flow (knowledge as a process versus an object) [Rem02, page 122]. The term“flow of knowledge” here is simplistically used to describe a focused, constructivist relationshipbetween knowledge supply and knowledge application entities.
CHAPTER 1. INTRODUCTION 31
knowledge processes typically include descriptions of [Str03b]: knowledge flows,
specific knowledge activities, related persons or roles and associated business
processes regarding a certain knowledge domain.
(Organizational) Knowledge domains represent topical fields of knowledge
which are relevant in the context of undertaking certain (business) actions.
Knowledge management is often concerned with increasing transparency of
critical knowledge domains in organizations. In such efforts, knowledge domains
are typically identified and subsequently combined to form knowledge diagrams
which represent knowledge domains at various abstraction levels in a networked
(e.g. Topic Maps [Top01]) or hierarchically (e.g. knowledge structure diagrams
[Noh00]), organized way.
Specific knowledge activities are basic knowledge actions executed by people,
organizations or technological systems. Examples of specific knowledge activities
include the socialization, externalization, combination, generation, transfer or
application of knowledge8. In this PhD work, the specific knowledge activities
generation, storage, transfer and application [Hei01] are utilized since they
adequately9 describe knowledge work on an operative (or knowledge object
[SAA+02]) level. Various authors provide their very own sets of specific
knowledge activities [Hei01, NT97, Rol03] for different objectives and areas of
application.
Specific knowledge activities executed by an organizational role either within
or outside of business processes are referred to as knowledge work. Knowledge
work can therefore be a subset of both business and knowledge processes, but
is at least a subset of knowledge processes. Organizational roles that perform
knowledge work are regarded as knowledge workers .
Figure 1.5 depicts relationships between the key terms technological knowledge
infrastructure, business process, knowledge process, specific knowledge activity,
8Here, a necessary distinction between specific knowledge activities (on a knowledge objectlevel [SAA+02]) and knowledge management activities (such as knowledge planning, identifica-tion or assessment - on a knowledge management level [SAA+02]) has been made.
9with respect to the defined objectives of this work
CHAPTER 1. INTRODUCTION 32
Figure 1.5: Relationships between Key Terms of this PhD Work (Based on
[Rem02])
knowledge work and knowledge worker.
In addition to specific knowledge activities, knowledge management activities
deal with goal setting, measurement and assessment of knowledge management
interventions (as introduced by [PRR98] and stressed by [RL00]).
Chapter 2
Knowledge Infrastructure
Development
Objectivity is a subject’s delusion that observing can be done without him.
Appendix Chapter A on page 162
Technological knowledge infrastructures are technological systems. This in-
cludes software applications such as knowledge management-, document- or con-
tent management systems, intra- or extranets, file servers, data bases but also
custom tailored systems. Approaches focussing on the development of knowl-
edge infrastructures only sporadically exist (e.g. [Siv99]). Detailed concepts
concerning the domain at hand are not available. However, mature approaches
and concepts stemming from related research domains that are relevant in the
context of knowledge infrastructure development are available. For example,
work performed in the field of software-, systems- or method-engineering (such
as [You89, Bri96, Tol98]) as well as knowledge based or information system de-
velopment (such as [SAA+02, Sin95]) can significantly contribute to the topic at
hand.
2.1 The Knowledge Infrastructure Develop-
ment Project
Knowledge management initiatives, such as the development of knowledge
infrastructures, are typically organized as a project [MR02]. In this work, a
33
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT 34
knowledge infrastructure development project focuses on the design of techno-
logical systems that support knowledge workers. In figure 2.1, relevant roles
of knowledge infrastructure development projects are introduced. In order to
accomplish their respective goals, the roles need to perform certain tasks. Tasks
are typically organized and executed in a certain timely sequence, represented
through process models. Tools support the roles in executing their respective
goals1.
Figure 2.1: Knowledge Infrastructure Development Projects (Based on
[SAA+02])
This chapter introduces roles, tasks, processes and tools (see table 2.1) that are
of importance for the development of technological, business process-supportive
knowledge infrastructures in order to increase understanding about the execution
of knowledge infrastructure development projects. This conceptualization acts as
a sound fundament for the development of the anticipated framework of this PhD
1not depicted in figure 2.1
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT 35
work.
All of these aspects are described from a knowledge infrastructure develop-
ment perspective (focussing on support for organizational knowledge processes
and knowledge workers) and are typically described on a higher abstractional
level than from an e.g. software development perspective.
Knowledge Infrastructure Development
Roles page 36
Tasks page 38
Process Models page 40
Tools page 42
Table 2.1: Aspects of Knowledge Infrastructure Development
2.2 Roles
Figure 2.1 depicts the context in which knowledge infrastructure development
projects are being executed together with a diverse set of roles that is related to
the process of knowledge infrastructure development. In this section, these roles
and corresponding responsibilities in an organization are introduced.
2.2.1 Knowledge Manager
The knowledge manager (or CKO - Chief Knowledge Officer) is regarded to be
highest ranked role in knowledge management [Mai02, p.143]. In this steering
position, his main responsibility is to develop and implement a knowledge man-
agement strategy that is aligned to an organization’s business strategy [Leh00, p.
226], [SAA+02, p. 22], [MHV03, p.107]. He initiates and coordinates knowledge
management projects and monitors the results in terms of their contribution to
the KM strategy as well as in terms of achieving economic benefits. In larger or-
ganizations, this role is typically performed by one CKO who supervises various
knowledge managers in his business unit [Mai02].
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT 36
2.2.2 Project Manager
The project manager (or knowledge project manager [MHV03]) is in charge of
running knowledge management projects [SAA+02, p. 22]. He focuses on aspects
related to project management such as the development of project goals and plans
or the coordination of project team members [MHV03, p. 107]. The project
manager takes a business perspective on the project to ensure that the project
goals are met in time and within the provided resources. He is also responsible
for dealing with project monitoring, controlling and/or marketing.
2.2.3 Knowledge Worker
Knowledge workers are the primary target group of a knowledge infrastructure
development project (also see [Mai02, p. 150]). Such projects aim to support
and improve the work of knowledge workers [DJB95]. As defined in section 1.4,
knowledge workers are regarded to execute knowledge work within or outside
of business processes. They implicitly or explicitly generate, store, transfer and
apply knowledge. Thus, the role of a knowledge worker is broader than that of
a knowledge user [SAA+02, p. 22] (additional focus on knowledge generation,
storage and transfer), and is not related to the role of a knowledge management
worker [MHV03, p. 108], who is a trained person dedicated to perform operational
knowledge management activities such as categorizing or structuring knowledge
bases.
2.2.4 Knowledge Analyst
The knowledge analyst2 is responsible for analyzing organizational knowledge
work executed by knowledge workers. Similar to the role system analyst [You89,
p. 56], he investigates a complex object system (organizational knowledge work)
and generates models that illustrate core aspects of the system under investiga-
2[SAA+02, p. 20] unfortunately use the term knowledge analyst interchangeably with theterm knowledge engineer. Rooted in the domain of knowledge engineering, a knowledge engineeraims to elicit knowledge from experts to implement that knowledge in so-called knowledge basedsystems. Instead of replacing knowledge of experts, in this PhD work a knowledge analystaims to analyze knowledge work of knowledge workers in order to support them by means ofsupportive knowledge infrastructures.
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT 37
tion. In doing so, the knowledge analyst provides specific knowledge views on
the system that represent a fundament for subsequent activities of knowledge
infrastructure designers.
2.2.5 Knowledge Infrastructure Designer
The knowledge infrastructure designer is responsible for transforming the devel-
oped models of organizational work into a design that describes a supportive
environment for knowledge workers (in analogy to [You89, p. 57]). He develops a
design of the system, which is the basis for implementation. Since knowledge in-
frastructures are typically not designed from scratch, a knowledge infrastructure
designer either utilizes available COTS3- or existing legacy systems. The knowl-
edge infrastructure designer (or an implementation team) finally implements the
final design. He also accompanies the validation of the solution with knowledge
workers.
2.3 Tasks
In figure 2.1, certain tasks of knowledge infrastructure development projects are
introduced. This section briefly introduces details concerning the execution of
these tasks.
2.3.1 System Analysis
System analysis deals with building models (model systems) about an object
system under investigation with the purpose of gaining a deeper understanding
about conceptualizations and interactions of people, groups of people, organiza-
tions and/or technology [You89]4. Typically, modeling tools (such as Structured
Analysis [You89], Unified Modeling Language [FS00], CommonKADS [SAA+02]
or ARIS [Sch96, Sch00]) aid system analysts in developing such models. They
provide formal conventions regarding graphical representations and conceptual
3COTS...Commercial-Off-The-Shelf4similar to what [FS01] define as the task layer (“Aufgabenebene”) of business information
systems
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT 38
segmentations as well as a set of suggested modeling dimensions. In the con-
text of knowledge infrastructure development, system analysis contributes to the
modeling of organizational knowledge work as a sound fundament for designing
supportive knowledge infrastructures.
2.3.2 Requirements Engineering
Requirements engineering in the context of knowledge infrastructure development
represents an attempt to generate requirements for an anticipated knowledge in-
frastructure. Relevant requirements elicitation techniques [Mac96, Wer, KS98]
in this context are JAD (Joint Application Design), CRC (Cooperative Re-
quirements Capture), QFD (Quality Function Deployment), structured or un-
structured interviews, scenarios, observations, video recording, card games, job
shadowing, focus groups, future workshops, prototyping, mock ups and others.
Requirements are typically classified along two main dimensions: functional and
non-functional requirements [KS98, BB98, RR99]. Requirements engineering not
only deals with aspects of eliciting requirements, but also with aspects of pri-
oritization, negotiation, validation, traceability, maintenance and management
[KS98, RR99].
The following aspects are considered to be problematic and may pose risks for
the outcome of requirements engineering efforts when structured or unstructured
interview techniques are being applied [You89]:
• Interviewing wrong people at the wrong time
• Asking wrong questions and getting wrong answers
• Creating bad feelings between involved parties (knowledge analysts and
knowledge workers)
2.3.3 System Design
System design [YC79, You89] deals with transforming model systems and system
requirements into a system design that allows for implementing an anticipated
system (respectively a knowledge infrastructure). In system design, pre-built
system elements, components and modules, as well as system design techniques,
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT 39
and/or reference system architectures typically provide guidance for system
designers (respectively knowledge infrastructure designers).
Patterns [Ale79, BMR+96, RZ96] can act as a vehicle for (pre-)packaging con-
ceptual elements of systems. They allow for easily reusing knowledge from past
projects for current system design efforts. Reference or template architectures (as
e.g. [Mai02] for knowledge management systems) typically act as blueprints for
the design of new systems. [Sin97] distinguishes between generic and non-generic
reference systems: Non-generic reference systems act as analysis and design tem-
plates for the design of systems while the reference system itself is not part of
the final design. Generic reference systems are able to deduce designs of systems
that can be traced back to the respective reference systems.
2.3.4 System Usage
After the technological knowledge infrastructure is deployed, knowledge workers
(end users) start working with it. In doing that, they generate valuable feedback
concerning the usability and applicability of the system. For the continuous
improvement of the system, consideration of this feedback is crucial.
Summarization: While system analysis by nature has a more descriptive
character (How an object system is), requirements engineering stronger focuses
on normative aspects (How a software system is supposed to be). System design
deals with specification aspects of software systems, while system usage comprises
user interactions with a knowledge infrastructure.
2.4 Process Models
This section depicts process models from various domains that are oriented to-
wards the development of systems. Although they are not directly related to
knowledge infrastructure development, they give an overview of prominent ap-
proaches towards system development and are general enough to fuel understand-
ing about different conceptualizations and applications in this domain.
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT 40
2.4.1 Waterfall Model
The waterfall model represents a first approach by [Roy70] to structure system
development processes. Although [Roy70] did not use the term “waterfall model”
in his paper, this name was assigned to his work by later publications because of
the characteristic representation of his proposed process. Based on the work of
[Roy70], a broad range of different versions of his waterfall model emerged (e.g.
[You89, p.83], [Boe88]). Although [Roy70] acknowledged the fact that varying
iterations through his process model are potentially necessary, the basic concept
of the waterfall model generally is - incorrectly - perceived to be a development
process that is decomposed in a set of phases, whereby each phase has to be
completed before the next starts (in a strictly sequential order). Objections
against this model typically include arguments that focus on the sequential nature
of such waterfall models and the lack of feedback loops. [Boe88] argues that,
for example in interactive end-user applications, more iterative approaches are
demanded.
2.4.2 Spiral Model
According to [Boe88], the spiral model represents an iterative, risk driven process
approach to system development, rather than a strictly sequential document- or
code driven process. The spiral model aims to generalize a set of different develop-
ment models (such as the waterfall model) and thereby provides a deeper under-
standing and more comprehensive guidance concerning system development pro-
cesses. The iterative approach and the wide range of options allows for adapting
the model to a large set of specific situations. The spiral approach continuously
generates and tests hypothesis about the system to be developed. Instruments,
such as risk management plans, support system developers in taking appropriate
decisions.
2.4.3 V-Model
The V-Model [IAB95] is a german IT system development standard for industry
as well as public administration and military projects. It tackles system devel-
opment in a comprehensive way by considering not only software development,
but also project management, quality assurance and configuration management
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT 41
issues. For all of these dimensions, the V-Model aims to provide supportive
procedures and methods as well as requirements for tools that support project
participants in executing their respective tasks. System development takes place
by iterating through the proposed process steps of the V-Model.
2.4.4 Rational Unified Process
The rational unified process [Kru] is a process model developed by Rational Soft-
ware that aims to provide guidance in software engineering processes. The main
process elements are business modeling, requirements, analysis and design, im-
plementation test, deployment, configuration and change management, project
management and environment. These elements are performed iteratively [LB03]
in what can be regarded as micro-waterfalls [Roy70]. The rational unified pro-
cess strongly focuses on developing and maintaining models of the system under
development. The process is typically utilized either as a basis for evolving a
company’s own standard or as an “electronic coach” for software engineering.
Rational Software provides comprehensive tool support for its process.
2.5 Tools
Computerized applications supporting and/or partially automating system de-
velopment activities are referred to as CASE5 tools (Based on [Fug93]). CASE
tools were classified along a large set of dimensions and categories [Fug93], a few
relevant of them are introduced here briefly:
• Upper vs. Lower CASE tools
• System development process vs. Metaprocess tools
• Tools vs. Workbenches vs. Environments
The term Upper CASE tool is used to describe CASE tools that provide
support on high abstractional (conceptual) levels, typically utilized during early
stages of system development [Tol98]. Lower CASE tools deal with more detailed,
5Multiple variants of the CASE acronym exist (also see [Sit02]). The most relevant in thecontext of this work is Computer Aided System Engineering
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT 42
often software-specific aspects of CASE. CASE tools focussing on system devel-
opment processes provide support for system development teams, while CASE
tools focussing on meta-processes provide support for method engineers who are
aiming to design methods and tools for system development teams (by means of
metaCASE or CAME tools [Tol98, p.68]). CASE tools, workbenches and environ-
ments [Fug93] classify available instruments in terms of their ability to provide
support for only specific system development activities vs. the whole system
development process.
2.6 Relevant Scientific Domains
This section briefly introduces a set of scientific (sub-)domains that are related
to the identified challenges of this PhD work and can potentially comprise
valuable concepts for the development of business process-supportive knowledge
infrastructures:
Business Process Oriented Knowledge Management: In recent years,
increasing research has been performed in the domain of business process
oriented knowledge management. Some approaches rooted in this discipline
focus on the deduction of knowledge infrastructures based on an organization’s
business processes. By focussing on these aspects, this domain is of highest
relevance to the context of the PhD thesis. Therefore, business process oriented
knowledge management is introduced in greater detail in chapter 3.
Modeling and Engineering of Business Information Systems: This
scientific discipline (in German: “Modellierung betrieblicher Informationssys-
teme” [Sin95, Sin97, FS01]) separates organizational systems into two basic task
(“Aufgabenebene”) and task-carrier (“Aufgabentragerebene”) layers [FS01].
Tasks describe organizational activities that need to be carried out in order
to achieve certain business goals. Task carriers are organizational entities
(humans or systems) responsible for executing a certain task. Based on this
basic distinction, several instruments (e.g. Entity Relationship Diagrams, UML
Models) are utilized to design technological support for the execution of business
processes. This PhD work addresses both task layers and task-carrier layers and
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT 43
introduces a framework that interconnects these concepts by providing support
for knowledge flows (between task carriers) that span multiple business processes
(at the task layer).
Requirements Engineering and Systems Analysis: Requirements
engineering deals with the process and related instruments of eliciting crucial
requirements for software projects [RR99]. Once the process of requirements
engineering is completed (the output are agreed upon requirements among
stakeholders), system analysts are in charge of modeling the requirements to
prove their correctness. When put to application, requirements engineering and
system analysis represent themselves not as two separate processes, but are
executed with a considerable timely and focal overlap. Requirements engineering
and systems analysis typically do not consider business or knowledge aspects as
a basis for conceptualizations, but utilize the notion of stakeholders to generate
sets of requirements. Here, the focus is on designing systems that satisfy iden-
tified stakeholders. System requirements are identified and represent the basis
for subsequent actions. While requirements engineering and systems analysis
focus on the development of systems from scratch, research on the development
of COTS based systems focuses on the adaption and configuration of already
existing systems. In the context of this PhD work, it is methodological knowledge
that mainly can be utilized from the approaches rooted in these scientific domains.
Social Network Analysis: This instrument, rooted in the scientific domain
of sociology, aims to identify informal relationships between a set of intercon-
nected people (e.g. [Pai03, MPF04, CLC04]). Thereby, roles and positions of
people within networks as well as relations between them can be identified and
analyzed. Especially improvements concerning cultural and organizational as-
pects can be designed based on such approaches.
User Observation and Pattern Analysis: Typically, approaches in
this domain deal with observing user interactions with computer systems (e.g.
[SRB03, HGM01]) aiming to understand intentions of users at high conceptual
levels. Based on collected data which typically represents logs of interactions on
a software application level, such approaches aim to identify higher level user
goals such as work tasks, work flows or knowledge flows in a bottom up way.
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT 44
Major problems of such ideas are represented by the fact that users typically
execute various tasks or pursuit various goals at the same time and users’ current
business contexts are hard to grasp. This is the reason why such approaches
currently rely on very narrowing conditions and assumptions and on the abilities
of analysts who interpret the gathered data in an intelligent way.
Knowledge Management Technologies: During the last years, a
lot of research is being done on the domain of knowledge management
[NT97, PRR98, HNT99, Leh00]. A sub domain of this discipline focuses on the
conceptualization and classification of currently available and potential future
KM technologies (such as [Rol03, MR02, MT02]). These efforts provide profound
models for necessary, complexity reduced conceptualizations of the domain of
KM technologies.
This PhD work utilizes concepts from the aforementioned scientific disciplines,
but focuses on and is rooted in the discipline of business process oriented knowl-
edge management (introduced in greater detail in chapter 3).
2.7 Assessment in the Context of this Work
Although the existing work introduced in this chapter is not directly related to
the development of knowledge infrastructures, it provides a sound basis for con-
ceptualizing the domain of knowledge infrastructure development and for further
narrowing the focus of this PhD work. This PhD work focuses on providing sup-
port for knowledge analysts who aim to analyze organizational knowledge work
(system analysis) and for knowledge infrastructure designers who are responsible
for designing business process-supportive knowledge infrastructures. Thereby,
existing object systems (organizational knowledge work) need to be modeled and
transformed into a knowledge infrastructure design. The process models intro-
duced in section 2.4 indicate a current trend towards iterative approaches in
system engineering. Especially during implementation phases an iterative ap-
proach is strongly recommended to ensure tight integration of future users. Since
models of organizational knowledge work can be arbitrary large and complex
(depending on the scope of investigation), the need for supporting CASE tools
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT 45
becomes obvious. Therefore, this PhD work aims to develop a framework and an
accompanying software tool that aids the process of developing business process-
supportive knowledge infrastructures.
Chapter 3
Business Process Oriented
Knowledge Management
Ich mochte nur darauf hinweisen, daß es eine Zeit gab, in der man die
Ahnlichkeit der Empfindungen zur Basis der Kategorisierung von Pflanze und
Tier gemacht hat. Man denke [...] an die fruhen Taxonomien des Ulisse
Aldrovandi aus dem 16. Jahrhundert, der die scheußlichen Tiere (die Spinnen,
Molche und Schlagen) und die Schonheiten (die Leoparden, die Adler usw.) zu
eigenen Gruppen [von Lebewesen] zusammenfasste.
Appendix Chapter A on page 162
3.1 Introduction
The emergence of the phenomenon of knowledge intensive business processes
raised the need for an integration of the existing research domains of business
process- and knowledge management. A commonly used term to describe this
relatively young research domain is “Business Process oriented Knowledge Man-
agement (bpoKM)” [Hei01, JHS01, AHMM02, Rem02] which itself is a rather new
term and includes a variety of concepts and approaches tackling a very diverse
field of challenges. Based on a comprehensive literature review, the following sec-
tion introduces a model of currently existing bpoKM challenges and approaches
to assess their relevance in the context of the challenges of this work.
46
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT47
3.2 Overview of Challenges and Approaches
Figure 3.1: A Model of bpoKM Challenges
Figure 3.1 illustrates the main challenges of bpoKM that were explicitly or
implicitly addressed by research efforts in the domain of bpoKM during the last
years. As a starting point, most approaches in the domain of bpoKM with an
operative focus1 rely on analyzing business processes by taking a “knowledge
perspective” on them. Current bpoKM approaches mainly focus on one, but
cover and typically need to resolve more than one of the identified challenges.
As depicted in figure 3.1, current bpoKM approaches predominately focus
on Business Process Modeling, Business Process Learning, Business Process
Support, Business Process Execution or Business Process Improvement.
[Rem02, page 71] also provides a classification of diverse bpoKM challenges.
While his approach mainly focuses on what business process management
can do for knowledge management (defined elements of the classification are
“Introduction of Knowledge Management”, “Design of Knowledge Management
1Strategic aspects of business process oriented knowledge management are not explicitlymentioned in the depicted model in figure 3.1. The reason to that is because strategic con-siderations play an important role in each of the identified challenges. The importance ofstrategic considerations has been recognized by academia and comprehensive work regardingthese aspects is available (e.g. [MR01, MR02, Mai02, MR03]).
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT48
Systems”, “Knowledge Process Redesign”, “Increased Process Transparency”),
the classification introduced in figure 3.1 puts business process challenges up
front. Since knowledge management never represents an end in itself, the latter
approach provides more feasible arguments and benefit estimations for the
implementation of knowledge management efforts.
The following paragraphs first introduce the common ground of bpoKM
(which is represented by Business Process Analysis) and afterwards deal with
the main identified challenges of bpoKM. Based on a comprehensive literature
review, expected benefits as well as current prominent approaches per challenge
are introduced and described. The approaches classified here do not necessarily
exclusively focus on the respective challenges, but cover the targeted challenge
to a prominent extent.
3.3 Business Process Analysis
Knowledge oriented analysis of business processes represents the fundament of
most approaches in the field of bpoKM. Often, specific knowledge activities such
as the generation, socialization, integration or transfer of knowledge are utilized
to investigate business processes in terms of their respective knowledge work.
By taking a “knowledge perspective” on business processes, analysts are able to
identify knowledge implications, relationships and/or interactions which are typ-
ically not covered in traditional business models. These analysis provide valuable
insights for addressing the identified challenges depicted in figure 3.1.
3.4 Business Process Modeling
3.4.1 Challenges
Knowledge, as a key resource in today’s organization’s value generating processes
represents a factor that was not considered in traditional business process mod-
eling efforts. Such traditional business process models concentrated on modeling
the “flow of work” rather than the “flow of knowledge” in organizations [Str03a].
With knowledge gaining more and more importance, traditional business pro-
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT49
cess models can significantly be enhanced by integrating knowledge as a critical
resource. BpoKM approaches that focus on the modeling of business processes
aim to eliminate these deficits by introducing ways that allow for the integrated
modeling of work- as well as knowledge-related aspects.
3.4.2 Benefits
The benefits of considering knowledge aspects in business process models are man-
ifold: Knowledge domains that are crucial for the execution of certain business
processes become visible. Highly prioritized knowledge processes, which typically
span multiple business processes, can be identified, managed and treated as sepa-
rate important organizational processes. Knowledge deficits as well as knowledge
oversupplies can be identified and remedied [GPSW03]. In subsequent efforts,
knowledge workers can be provided with exactly the knowledge which suits their
roles in their corresponding business processes.
3.4.3 Selected Approaches
Approaches that focus on the knowledge oriented modeling of business processes
exist and are briefly described in this section.
ARIS
ARIS (ARchitektur integrierter InformationsSysteme) represents a concept for
the modeling of business processes developed by Prof. Scheer. Based on five
views (Organization, Function, Data, Output and Control View) [Sch96, Sch00],
different important aspects of organizational processes are modeled and consid-
ered. While this approach is rooted in the domain of traditional business process
management, the emergence of knowledge management led to extensions [All98].
Specific knowledge management instruments like knowledge structure diagrams
or landscapes as well as the modeling of knowledge work in organizations and the
modeling of specific knowledge processes is supported by a software tool (ARIS
Tool). Examples of using the concept ARIS for the modeling of knowledge
intensive business processes exist and can be found in [Har02, page 126] or
[Leh02, page 15].
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT50
K-Modeler
The University of Oldenburg is developing the description language K-Modeler
and an accompanying software tool that aids the integrated modeling of both
business and knowledge processes. K-Modeler aims to identify flaws and
weaknesses in organizational knowledge processes [GPSW03]. To achieve that,
the approach extends current existing business process modeling techniques with
elements focusing on describing knowledge work of process agents. Remark-
ably, K-modeler supports role-oriented as well as person-oriented modeling of
knowledge work. In doing that, [GPSW03] utilize Nonaka’s [NT97] four specific
knowledge activities (internalization, socialization, externalization, combination)
to model current and targeted degrees of organizational management concerning
knowledge processes.
Papavassiliou et al.
The concepts presented in [PMA02, PNAM02] focus on the modeling of weakly
structured and knowledge intensive business processes. Based on the specific
knowledge activities introduced by [Hei01] (which are Generation, Storage, Trans-
fer and Application), a meta model for the integration of knowledge in busi-
ness process models was developed. Therefore, a differentiation between Normal
(Business) Tasks and Knowledge Management Tasks is proposed. A developed
tool that integrates the existing software tools Microsoft Visio 2000 and Cog-
noVision supports business process engineers during modeling. In subsequent
efforts, [PMA02] use their concepts to model business processes as a basis for the
utilization of workflow management systems.
3.5 Business Process Learning
3.5.1 Challenges
Today’s training of employees in organizations usually takes place in a domain-
or product-oriented way. Examples for such traditional training are e.g. project
management courses or MS Winword training. For knowledge workers in today’s
organizations, learning is a continuous, problem-centered effort that typically oc-
curs right at their work places without having time to participate in comprehen-
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT51
sive seminars. Traditional learning techniques (like courses, e-learning, seminars,
classes, etc.) do not satisfy the highly specific business needs of these knowl-
edge workers since available training is tailored to abstract fields of knowledge
instead of concrete business problems. BpoKM approaches that focus on busi-
ness process learning typically stem from learning theory and aim to resolve the
aforementioned conflict. By conceptualizing learning as being an integral part
of knowledge worker’s business processes, such approaches provide personalized,
problem-oriented and context-sensitive access to learning resources that aid the
development of necessary knowledge.
3.5.2 Benefits
BpoKM approaches that focus on business process learning aid knowledge workers
in effectively building up knowledge and abilities needed in order to fulfill tasks
in their corresponding business processes. Typically, such approaches support
knowledge workers in acquiring knowledge that comprises a noticeable learning
curve and focus on knowledge that needs to be applied in very specific contexts
(often referred to as experience) as well as more context-independent knowledge
(models or theories). The main benefit that organizations as well as knowledge
workers reap from support provided by such approaches is that the time a novice
needs to become an expert typically decreases. Thereby, organizations can de-
crease the costs of potential fluctuation and knowledge workers receive support
in building up critical knowledge that is needed in order to perform well in their
corresponding business processes.
3.5.3 Selected Approaches
Approaches that focus on business process learning exist and are briefly described
in this section.
ADVISOR
ADVISOR (ADVanced Instruction Technologies for Services ORganisations)
[SP01] represents a framework as well as a software that, building on the existing
business process management software ADONIS, aims to provide employees
with process oriented access to learning resources. [SP01] achieve this goal by
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT52
enriching existing business process models with previously unconsidered aspects
of learning. Thereby, knowledge workers are supported in acquiring knowledge
they need within their business processes. Additionally, ADVISOR supports
the provision of target group specific views on business processes. This aids
employees in reducing complexity about organizational models and focusing on
relevant aspects of available organizational knowledge.
MODEL
MODEL (Multimedia for Open and Dynamic Executives Learning) [PPS02] rep-
resents an approach that aims to foster work-based learning processes. [PPS02]
tackle this challenge by designing a KM system that aims to 1) capture and trans-
fer knowledge generated in business processes and 2) provide a business process
oriented ICT2 infrastructure for enabling novice process agents to learn from col-
league experts (via the KM systems). The vision of MODEL is to establish a
self-sustaining, multi-subjective KM system that acts as a medium for knowledge
transfer as well as a source of knowledge for organizational knowledge workers.
By doing that, this approach both focuses on technological (supporting ICT) and
on human (CoP3s) and organizational aspects of learning.
3.6 Business Process Support
3.6.1 Challenges
Supporting knowledge workers in executing their business process tasks is a rather
complex undertaking. Knowledge workers are highly dependent on business pro-
cess specific, task-oriented and action-relevant information. In today’s organi-
zations, knowledge workers are responsible for filtering this information from
various sources within or outside their organizations and relating it to their cor-
responding business process contexts. This work strongly relies on knowledge
workers; it is time consuming and most of the time not documented or traceable
at all. Thus, such work represents itself as being risky and expensive for organi-
zations. BpoKM approaches focusing on business process support aim to tackle
2ICT...Information and Communication Technology3COP...Communities of Practice
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT53
the identified challenges by providing instruments, which aid knowledge workers
in acquiring and organizing relevant information that is critical to their business
processes.
3.6.2 Benefits
Given that knowledge workers maintain the necessary abilities to execute their
business process activities, bpoKM approaches focusing on business process sup-
port typically provide knowledge workers with action relevant information, in-
formation sources and channels. Thereby, knowledge workers receive focused
support in their corresponding business processes which enables them to make
informed decisions. Organizations profit from such efforts also since information
needs, sources and channels of their knowledge workers are made explicit, thus
are documented and thereby capture parts of implicit knowledge of knowledge
workers. Also, by identifying these needs, organizations are now able to explic-
itly trace and manage the delivery of information that is considered to be of high
relevance for the achievement of certain process or business goals.
3.6.3 Selected Approaches
Approaches that focus on supporting business processes exist and are briefly
described in this section.
BKM
The BKM (Business Knowledge Management) Methodology by [BsV00] is
focused on the selection and design of KM interventions on technological (system
design) and on organizational (organizational development) levels based on
analyses of potentials and business processes. By analyzing business processes,
the BKM methodology aims to increase transparency over existing knowledge
sources in organizations and identify deficits and improvement potentials
concerning the management of knowledge. KM interventions deduced from
such investigations are destined to support the respective business processes.
The BKM methodology was utilized by e.g. [Har02] as a basis for designing
technological support for a single, core business process of academic researchers.
[Har02] analyzed the knowledge intensive business process “literature research”
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT54
and deduced the design of a knowledge portal that supports researchers in
executing this critical business process.
Knowledge Networks Reference Model
The knowledge networks reference model [RES+00] developed at the research
center Knowledge Source at St. Gallen aims to support business processes
and corresponding knowledge workers by means of designing organizational
knowledge networks. Here, knowledge networks comprise organizational as
well as technological instruments that can be used to facilitate social relation-
ships in organizations. Together with the network approach which is based
on investigating an organization’s business strategy and its corresponding
knowledge work processes, [RES+00] introduce a business process oriented
knowledge management architecture approach which is based on investigations
of an organization’s business processes too. Both approaches are considered to
complement themselves [RES+00, page 39]. Additionally, the work provides
a comprehensive classification of existing knowledge management technologies
that themselves represent the building blocks of knowledge networks.
GPO-WM
The method GPO-WM (GeschaftsProzess Orientiertes WissensManagement)
[Hei01, MHV03] developed at Fraunhofer IPK Berlin aims to support business
processes by selecting and implementing appropriate KM interventions. [Hei01]
utilizes four specific knowledge activities (Generation, Storage, Transfer and
Application) to investigate business processes in terms of their knowledge work.
Based on this analysis, the method deduces technological, human oriented
and organizational KM interventions that aim to support an organization’s
business processes. Additionally, this approach provides KM best practices for
certain types of common business processes. Thereby, organizations are aided
in identifying appropriate, supportive KM interventions for their most critical
business processes.
Other Approaches
The approach of [MHA03] focuses on the design of process oriented knowledge
structures. Through analysis of existing business process structures as well
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT55
as through consensus workshops with stakeholders, knowledge structures that
are aligned to business processes are developed. Thereby, organizational work
and knowledge environments become integrated and knowledge workers are
supported via business process oriented access to process instance specific
information.
Another concrete example of conceptualizing business process support for
a specific role can be found in [Jan00]. In his PhD thesis, he analyzes the
main processes of business engineers and subsequently designs an appropriate,
technological knowledge infrastructure (a business engineer portal).
PRomisE2 (the PRocess oriented Organizational Memory Information System
navigator II) [HHDG02] represents another approach that provides knowledge
workers with situated process information. Here, the PRomisE2 system delivers
target group specific (e.g. according to the knowledge worker’s role or associated
division) and work context sensitive information to knowledge workers. Thereby,
knowledge workers can easily relate to business process models since the models
are instantiated with personalized information specific to knowledge workers’
context.
3.7 Business Process Execution
3.7.1 Challenges
Currently, the most prominent way of technologically enabling the execution of
business processes is the utilization of formally available business process con-
text information. WFMS support the routing and assignment of work packages
across multiple roles or employees of organizations and thereby maintain formal
information about the status of currently executed business processes. In doing
that, WFMS promise to provide infrastructures for the execution of a large set of
business processes in a comprehensive way. Nevertheless, at present WFMS are
utilized mainly when it comes to supporting well-structured and simple business
processes such as vacation requests or requests for business cards. The reason
to that commonly is credited to the nature of knowledge intensive business pro-
cesses. Knowledge intensive business processes are typically weakly structured,
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT56
their output strongly depends on knowledge workers and the learning time for
properly executing the processes is high [ESR99]. Therefore, traditional WFMS
bear a significant improvement potential. By integrating mechanisms that are
focused on dealing with the critical resource knowledge, WFMS could even pro-
vide more support to users of such systems (by e.g. providing information that is
relevant for executing certain assigned work packages). BpoKM approaches that
focus on business process execution typically suggest extensions to traditional
WFMS from a knowledge perspective in order to get rid of the described deficits.
These approaches differ to Business Process Support approaches in terms of their
historical roots (WFMS), their targeted business processes (still less knowledge
intensive and complex) and their targeted intervention levels (exclusively tech-
nological interventions aligned to the concepts of WFMS).
3.7.2 Benefits
Traditional WFMS typically aid organizations in the traceable execution of busi-
ness processes across multiple business process instances and multiple participat-
ing process agents [Hol95]. BpoKM approaches that focus on business process
execution aid process agents in executing their assigned tasks. Thereby, orga-
nizations not only get the benefit of assured and traceable accomplishment of
assigned work, they can also influence the quality of assigned work by explicitly
providing support concerning the important resource knowledge. Such enhanced
WFMS can ensure that knowledge is provided, treated and documented according
to organizational guidelines in an organization’s business processes.
3.7.3 Selected Approaches
Approaches that focus on the execution of business processes exist and are
briefly described in this section. A comprehensive overview of such approaches
can be found in [Goe02].
Milos
Milos [MH99, MT02] is a tool developed in a cooperative effort by the University
of Calgary and the University of Kaiserslautern. It represents an approach
that focuses on supporting business process planning and execution in learning
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT57
organizations with a focus on software development environments. In Milos,
business process models are enriched with process agents’ skills and information
needs models as well as links to background knowledge. Business process
planning is supported by implementing a best practice process module library
and providing specific software interfaces and functionality (e.g. yellow pages)
to project planers. Business process execution is supported by providing
coordination, communication and notification features for participating process
agents. Milos also puts a strong focus on organizational learning by utilizing
instruments such as experience bases and process feedback loops.
PROMOTE
PROMOTE [KT00, AHMM02, TK02, WK02, Woi03, WK03] was developed
within an EU project and represents an approach developed by the company
BOC GmbH. PROMOTE consists of a methodology and an accompanying
software tool [AHMM02, page 68]. The main goals of this approach (formulated
in [KT00]) are to support employees in executing their business processes.
Therefore, PROMOTE focuses on providing context-sensitive knowledge to
employees and on establishing mechanism that aid employees in the provision
of knowledge to the PROMOTE system. PROMOTE extends existing workflow
systems by enabling a pass over of business process context information to
knowledge processes, which therewith get pre-configured according to users
needs. A later publication concerning PROMOTE focuses on the explicit
management of various strategies concerning the provision of knowledge services
to employees [WK03].
Workbrain
Workbrain [WWT98] is an approach developed by the Bavarian Research Center
for Knowledge-based Systems. Workbrain represents an effort to extent an
existing WFMS to an OMIS4. This approach focuses on supporting employees in
1) mastering and 2) improving workflows as well as 3) providing and retrieving
knowledge to/from Workbrain.
Other Approaches
4OMIS...Organizational Memory Information System
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT58
EULE ([RMS00]) is a knowledge-based, cooperative system for supporting office
work in insurance business environments developed by the Information Systems
Research Group of Swiss Life. EULE provides process agents with models of
business processes that comprise reasoning and explanations for them as well as
role-oriented views on business process activities. A conducted field study re-
vealed that novice as well as expert process agents received considerable work
support from the EULE system. While EULE is not yet integrated in a WFMS,
[RMS00] designed the system with these aspects in mind and stress the fact
that EULE would complement well with the concepts of WFMSs by focusing on
declarative on top of procedural knowledge.
DECOR (DElivery of Context-sensitive ORganizational knowledge) [AML+01] is
a project funded by the EU which utilizes the concept of ontologies for support-
ing process agents in executing their business process tasks. Beneath a method-
ological approach, DECOR employs a WFMS and enriches traditional workflow
models with information needs models of process agents as a basis for support-
ing them. [AML+01] plan to achieve such operational support through knowledge
archives and active information delivery concepts that utilize context information
available in WFMS.
3.8 Business Process Improvement
3.8.1 Challenges
BPR5 is a prominent and often utilized approach for improving business processes
of organizations although it represents a rather radical way of achieving improve-
ments. Typically, BPR discards existing business process modeling efforts and
designs new business process models from scratch. By taking knowledge impli-
cations of existing business process models into account, BPR would be able to
better anticipate future knowledge interactions between newly developed busi-
ness processes and thereby might develop more optimal and sustainable business
processes. CPI6, another effort targeted at improving existing business processes,
promotes the continuous controlling, analyzing and improving of single business
5BPR...Business Process Re-engineering6CPI...Continuous Process Improvement
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT59
processes in terms of fulfilling their respective business process performance indi-
cators. CPI in the past proved itself successful for improving selective sequences
of work in organizations. The improvement of complex networks of business pro-
cesses (also see challenge 1 in section 1.1.1) has not been among the major goals
of CPI efforts. Because of their roots in process management, both approaches
do not explicitly take a knowledge perspective when aiming at business process
improvements. Since a successful improvement of knowledge intensive business
processes is regarded to be stronger related to the improvement of knowledge flows
rather than work flows [RL00], the above mentioned approaches however com-
prise noticeable improvement potentials. BpoKM approaches that focus on busi-
ness process improvement are typically twofold: They either consider knowledge
implications when redesigning business processes (focus on improving organiza-
tional knowledge flows) or utilize new instruments from knowledge management
to improve business processes (focus on improving organizational work flows).
3.8.2 Benefits
The benefits of bpoKM approaches that focus on business process improvement
are somewhat obvious. All such efforts contribute to improvements concerning
either work or knowledge flows. Both benefits aim to fulfill an organization’s
overall business goals to a higher degree.
3.8.3 Selected Approaches
Approaches that focus on the improvement of business processes exist and are
briefly described in this section.
KODA
KODA (KOmmunikationsDiAgnose) [AHMM02] represents a methodology
and an accompanying software tool developed by IMS (Institute for Manu-
facturing Strategies) GmbH and Fraunhofer IFF (Institut fur Fabrikbetrieb
und -automatisierung). Based on software tool-supported interviews with
knowledge workers, KODA aids in eliciting information flows which are related
to organizational business process models. Thereby, KODA generates various
views (organizational, business process, resource, flow chart, responsibility and
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT60
communication views [AHMM02, page 147]) on an organization and aids in
identifying improvement potentials of existing business processes. Conducted
case studies [DHB01] report that with KODA, substantial improvements in
investigated business processes were achieved. While KODA seems to succeed
in improving and optimizing business processes, [Rem02] criticizes the fact
that no framework for the systematically deduction of knowledge management
interventions exists.
indiGO
indiGO (INtegrative software engineering through DIscourse supported GrOup-
ware) [VA+02, DRA+03] represents an approach developed in a joint effort be-
tween Fraunhofer IESE (Institute for Experimental Software Engineering) and
Fraunhofer AIS (Autonomous Intelligent Systems). This approach uses the con-
cept of process communities [Rem02] to improve current business process models.
Knowledge workers, who execute a common business process and are considered
to be part of a corresponding business process community, are engaged to partic-
ipate in online discourses about the structure, content or execution of regarding
business process. Finished discourses are analyzed in terms of their contributed
improvement suggestions and represent the basis for the development of new,
enhanced business process models.7
3.9 Assessment in the Context of this Work
Regardless of varying aspects, the introduced bpoKM approaches share one im-
portant common property: By orienting all considered knowledge management
interventions, methods or techniques to business processes, undertaken knowledge
management efforts visibly contribute to value chains of organizations. This not
only provides more feasible arguments for the benefits generated through knowl-
edge management projects but also integrates knowledge management activities
more tightly into daily work situations of employees.
The following paragraph aims to assess current accomplishments concerning the
7[VA+02] and [DRA+03] use the term “process learning” to describe the process of improvingbusiness processes. In this thesis, the meaning of the term “process learning” is used differently(as introduced in section 3.5).
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT61
identified bpoKM challenges and deduce conclusions for this PhD work.
• Business Process Modeling: Most bpoKM approaches regard the mod-
eling of knowledge-intensive business processes as a necessary basis for the
selection of KM interventions. Therefore, the enriched modeling of busi-
ness processes is relevant in the context of this PhD work. This domain
received much attention in past research, successful concepts for modeling
knowledge in business processes already exist and can act as a starting
point for tackling the goals of this work. However, a central challenge that
remains is: How exactly can these models aid the development of business
process-supportive knowledge infrastructures?
• Business Process Learning: BpoKM approaches focusing on business
process learning partly utilize business processes as an navigational index
to learning resources (as e.g. suggested in [RL00]). Thereby, employees have
to think in business processes (which itself is a questionable condition) in
order to navigate to relevant knowledge. Since considering human factors
is excluded from this PhD work, concepts from this domain only add little
to addressing the objectives of this PhD work.
• Business Process Support: Most bpoKM approaches focussing on busi-
ness process support are successful in niche domains (e.g. [Jan00, Har02]).
Existing comprehensive approaches typically lack detailed descriptions on
how to deduce necessary knowledge management interventions. While
GPO-WM [Hei01] successfully suggests knowledge management interven-
tions on a conceptual level, operative support for knowledge workers is not
among the major goals. The knowledge networks reference model [RES+00]
for example stresses the importance of designing ICT infrastructures to
support knowledge work processes too, but a comprehensive and scalable
approach for the development of knowledge infrastructures that support an
organization’s most critical knowledge intensive business processes is not
available yet. Nevertheless, by aiming to design support for knowledge in-
tensive business processes, existing approaches in this domain are tackling
goals similar to the objectives of this PhD work and provide valuable inputs
and stimuli.
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT62
• Business Process Execution: BpoKM approaches that focus on extend-
ing WFMS to support knowledge management typically struggle with rigid
workflow definitions that do not satisfy the needs of highly complex and
knowledge intensive processes. Here, the trend is to support weakly struc-
tured or ad-hoc WFMS that more capably aid employees in executing their
knowledge intensive business process activities. Examples for such efforts
are [PNAM02] (a modeling language for modeling weakly structured work-
flows) or [HTEN03] (a system for ad-hoc workflows). Since WFMS only
represent a very specific part of knowledge infrastructures (mainly contain-
ing and processing knowledge about business processes), few can be drawn
for addressing the objectives of this PhD work.
• Business Process Improvement: BpoKM approaches that focus on the
improvement of business processes have proven themselves successful in the
past. For example, KODA [AHMM02] elicits existing information flows in
business processes and, based on that, deduces business process improve-
ments from a knowledge perspective. Noticeable improvements in business
process performance were reported [DHB01]. Still, the identification of com-
plex knowledge processes that span multiple business processes remains a
challenging task. Such existing knowledge interactions between business
processes are considered to be the cause for the failure of BPR projects in
the past [Str03b]. Since approaches in this field partly focus on improving
knowledge processes, certain aspects of such approaches nevertheless are
relevant in the context of this work.
3.10 Focal Point of this PhD Work
The biggest challenge of bpoKM seems to lie in the development of knowledge
infrastructures that support an organization’s knowledge intensive business
processes in a way that suits both, an organization and its employees. No
comprehensive approach currently exists that provides detailed instructions on
how to develop such business process-supportive knowledge infrastructures. The
model of bpoKM challenges introduced in this chapter (see figure 3.1) represents
a profound ground for a classification of this PhD work. This PhD work aims
to provide guidance in the development of technological support for knowledge
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT63
intensive business processes with a focus on supporting both organizations and
employees. Therefore, this PhD work focuses on the bpoKM domain of Business
Process Support, but utilizes concepts from other domains (such as Business
Process Modeling) whenever the application of them appears to be appropriate.
Chapter 4
Principle Approach
Nicht das Sammeln und Speichern von Wissen, sondern die Nutzung des
Wissens in den Prozessen bestimmt den Wert von Wissen.
Appendix Chapter A on page 162
4.1 Introduction
When BMW1 planned a new automobile development center in Munich, the
requirements for the building hosting this center were somewhat different to
regular architectural projects: “Take care that the product development time
frame of our products declines from ten to four years” [Wol03]. The approach
that Gunter Henn, industrial architect responsible for designing the building,
took to address BMW’s objective provides an interesting ground for discussing
business process implications for organizations. When designing BMW’s new
development center, he analyzed its targeted product development processes
and elicited impacts on the building’s architecture. Thereby, business processes
became the basis for the design of a building that supports an organization’s
business goals [Str03b].
What can be drawn from this example is that business processes obviously
pose implications for the architecture of organizational buildings. In certain
cases, the implementation of these implications even seems to be mandatory
for organizations in order to effectively achieve their business goals. While
1BMW...Bayrische Motoren Werke
64
CHAPTER 4. PRINCIPLE APPROACH 65
a building’s architecture (in an industrial context) deals with optimizing the
management of physical entities (e.g. physical resources or employees), an
organizational knowledge infrastructure deals with optimizing the management
of knowledge. Although this analogy has its weaknesses2, it strikingly illustrates
the importance of linking organizational knowledge infrastructures to an organi-
zation’s business processes [Str03b].
The main goal of this work is to introduce a framework and an accompanying
tool that aid the development of business process-supportive knowledge infras-
tructures. The framework aims to resolve both identified challenges of chapter
1, which are: 1) support for the execution of knowledge flows across and within
business processes and 2) support for the application of typical KM functionality
in given business contexts. In this work, organizational business processes and
the central concept of knowledge processes represent the starting point for all sub-
sequent actions in knowledge infrastructure development projects. An accessible
introduction to the principle approach of this work follows.
4.2 Principle Approach
Figure 4.1: The Principle Approach of this PhD Work
Modeling of organizational knowledge work is not considered in traditional
business process modeling techniques. Also, knowledge intensive business pro-
cesses [ESR99] are typically weakly structured and therefore not capable of be-
ing a direct basis for the development of business process-supportive knowledge
infrastructures. A commonly used approach to overcome these problems is to
2also see footnote on page 31 about a constructivist view on knowledge
CHAPTER 4. PRINCIPLE APPROACH 66
identify and model organizational knowledge (based on business processes, such
as [Str03a], [Rem02, chapter 11.3], [GPSW03]) that visualize relevant, executed
knowledge work in an appropriate way. Since support for knowledge inten-
sive business processes is regarded to be stronger related to supporting knowl-
edge work and flows rather than workflows [Rem01], the need to identify and
model knowledge processes becomes obvious. By modeling knowledge processes
which are considered to run within and/or orthogonally to business processes
[DHMS00, ON01, PP02], a concrete and profound basis for the development of
future business process-supportive knowledge infrastructures can be established.
Based on knowledge processes, knowledge infrastructure designs that aim to sup-
port the execution of these knowledge processes can be developed and thereby
can contribute to, given that the designs are successfully implemented, business
process-supportive knowledge infrastructures (see figure 4.1).
4.3 Central Concept of Modeling Knowledge
Processes
Since the concept of modeling knowledge processes is central to the principle
approach of this work, it is introduced in greater detail in this section:
4.3.1 On Modeling Aspects of Organizations
Investigating and analyzing complex systems such as organizations is typically
not accomplished through direct interventions with the system, but indirectly
through appropriate models of the system in question. In addition, modeling
is always connected to certain goals of investigations. According to [FS01], a
model consists of the triple (see figure 4.2):
M=(SO, SM ,f)
with SO being the object system under investigation comprising system ele-
ments VO, SM being a model system comprising system elements VM and f being
the model transformation SO → SM .
CHAPTER 4. PRINCIPLE APPROACH 67
Figure 4.2: Object and Model Systems (Based on [Sin95])
In the context of modeling knowledge work of organizations, SO is a real sys-
tem (the organization and corresponding knowledge work), while SM is a formal
system (modeled knowledge processes). A main problem that comes with the
transformation of real systems into formal systems is that verifying structural or
behavioral consistency can only take place at an informal level [Sin95]. A key
criterion for the quality of such models is generally regarded to be the “Fitness for
Use” [Rem02]. To avoid that the quality of models only depends on the abilities
of modelers, model architectures (or meta models [Sin95]) including specifica-
tions of model elements, relationships, rules and semantics are introduced. A
model architecture enables modelers to check consistency and completeness of
their models as well as to check structural and behavioral consistency of their
models in a better (yet still informal) way.
4.3.2 Illustration of Modeling Knowledge Processes
In this section, an illustrative, yet abstract example of modeling and visualizing
organizational knowledge work is introduced. This example acts as an instru-
ment for the illustrative communication of the chosen approach for modeling
knowledge processes. Also, it lays the basis for the detailed definition of a model
architecture introduced in section 5.3. The model architecture provides a rich
meta model for modeling the current state of distributed, organizational work
through the concept of knowledge processes.
CHAPTER 4. PRINCIPLE APPROACH 68
Figure 4.3 illustrates the results of fictive, process-oriented investigations in
a target organization. The knowledge work of process agents in three exem-
plary business processes regarding three fictive knowledge domains is depicted.
Thereby, the work of organizational roles in their respective business processes is
analyzed in terms of their contribution to four specific knowledge activities. The
visualization in figure 4.3 is especially appropriate for creating and validating
models of organizational work, since process agents can easily relate to it.
Figure 4.3: Modeling Knowledge Work of Business Processes (Based on [Str03a])
Example: In figure 4.3, the organizational role X generates knowledge about
the knowledge domain A in business process 1 step 1 (and in two other steps of
business process 2). The organizational role Z applies that knowledge in business
process 3 step 1 and 4.
By employing an orthogonal (knowledge oriented) view on figure 4.3, hidden
knowledge processes that are executed and/or are only partially documented in
organizational business processes now become visible in a way that is illustrated
in figure 4.4. Per knowledge domain, related business process steps and roles
(represented as e.g. BP1S3 | X - Business Process 1 Step 3 | Role X in figure
4.4) are illustrated to give an idea, where (during the course of which business
processes) and by whom (by which organizational role) this knowledge domain
is generated, stored, transferred and/or applied. Thus, redundancies, gaps, re-
CHAPTER 4. PRINCIPLE APPROACH 69
lationships and/or interactions can be identified and analyzed on top of these
representations of knowledge processes. Although the arrows in figure 4.4 imply
a sequential execution of the considered specific knowledge activities, they do not
necessarily have to take place in that timely order [Str03a]. The question marks
in figure 4.4 depict potential flaws in organizational knowledge work.
Figure 4.4: Illustration of Resulting Knowledge Processes (Based on [Str03a])
Through analysis of modeled knowledge processes, a broad range of various
KM interventions all closely related to employees’ daily knowledge work can be
initiated (also see section 9). By utilizing the concept of knowledge processes
(which itself is based on the concept of business processes), organizational rel-
evance of the resulting models can be guaranteed (taking the basic conditions
formulated in section 5.5 into account).
4.3.3 Characteristics of Knowledge Processes
The following aspects are characteristic for and typically included in current
knowledge process approaches [Str03b] which mainly stem from the bpoKM
domain of Business Process Modeling (see chapter 3 on bpoKM). Knowledge
processes typically focus on a single knowledge domain and include descriptions
CHAPTER 4. PRINCIPLE APPROACH 70
of:
Knowledge Flows: Knowledge flows depict business process relevant rela-
tionships between knowledge suppliers and enquirers. By identifying such rela-
tionships, communication channels that are considered to be essential in organi-
zational value chains become visible.
Specific Knowledge Activities: Specific knowledge activities (like the gen-
eration, externalization, storage, etc. of knowledge) further describe the handling
of knowledge within and/or across business processes. The distinction between
specific knowledge activities plays a vital role in the development of supportive
knowledge management interventions (as e.g. in [PRR98] or in [Rol03]).
Related Persons or Roles: By illustrating related persons or organizational
roles, critical knowledge workers of an organization become visible. This provides
a profound starting point for designing people- or role-centric knowledge manage-
ment interventions that support knowledge workers in their respective business
processes. Often, information about related persons or roles is gathered from
existing business process models.
Associated Business Processes: All of the above mentioned properties
implicitly referred to associated business processes. The relationship between
knowledge and business processes is obviously fundamental to the concept of
knowledge processes (that run within or across business processes) and therefore,
needs to be represented in knowledge process models.
4.4 Characteristics of Knowledge Infrastruc-
tures Following this Principle Approach
Knowledge infrastructures that were implemented based on the principle ap-
proach introduced here typically support knowledge processes that span multi-
ple business processes and organizational roles. Thereby, they route knowledge
from/to corresponding knowledge workers and thus provide focused access to
relevant knowledge for knowledge workers. The implementation of knowledge
processes within knowledge infrastructures leads to a more standardized and
managed way of knowledge work in organizations. Knowledge infrastructures
CHAPTER 4. PRINCIPLE APPROACH 71
designed on the basis of knowledge processes are strongly related to the organi-
zation’s business processes and thereby can support them traceably.
4.5 Conceptualization of this PhD Work
The conceptualization of this PhD work is related to the principle approach
introduced in this chapter in a way that is illustrated in figure 4.5:
Figure 4.5: The B-KIDE Framework Conceptualization of this PhD Work
The B-KIDE Framework3 of this PhD thesis aims to provide guidance in the
business process oriented development of knowledge infrastructures and consists
of three main components: 1) the B-KIDE Model Architecture 2) the B-KIDE
Method and 3) the B-KIDE Context. While the B-KIDE Model Architecture
deals with aspects of modeling knowledge processes as a fundament for a large
set of heterogeneous challenges (also see chapter 9 “Future Applications”), the
B-KIDE Method focuses on the design of certain aspects of knowledge infrastruc-
tures (see focus and objectives of this PhD work in chapter 1) based on identified
knowledge processes. The B-KIDE Context describes the environment in which
the B-KIDE Framework and an accompanying software tool, the B-KIDE Tool,
is employed. The B-KIDE Tool supports the application of the B-KIDE Frame-
work. It aids knowledge analysts on an operative level in building models about
organizations and knowledge infrastructure designers in designing appropriate
3B-KIDE...Business process oriented Knowledge Infrastructure Development
CHAPTER 4. PRINCIPLE APPROACH 72
knowledge infrastructures based on these models (similar to what [Tol98] defines
as method-tool companionship).
4.5.1 B-KIDE Context
The B-KIDE context introduced in section 5.2 briefly describes the anticipated
goals of the B-KIDE Framework, as well as participating roles, underlying as-
sumptions and targeted technological environments.
4.5.2 B-KIDE Model Architecture
The B-KIDE Model Architecture introduced in section 5.3 provides a set of direc-
tives for creating models of organizational knowledge work through the concept
of knowledge processes. In doing that, it not only offers a comprehensive model
architecture that allows for identifying and visualizing knowledge processes in
organizations, but also offers a sound fundament for a series of various subse-
quent analysis and design actions that go beyond the scope of this work (also see
chapter 9).
4.5.3 B-KIDE Method
The B-KIDE Method introduced in section 5.4 focuses on designing certain as-
pects (section 1.2.1) of business process-supportive, technological knowledge in-
frastructures on top of knowledge process models of organizations. The B-KIDE
Method guides knowledge infrastructure designers through the process of de-
signing knowledge infrastructures that comply with the objectives formulated
in chapter 1. In doing that, the B-KIDE Method represents a single, specific
application of the introduced B-KIDE Model Architecture.
4.5.4 B-KIDE Tool
By complementing the B-KIDE Framework, the B-KIDE Tool aids knowledge
analysts in efficiently identifying and analyzing knowledge processes in business
process oriented organizations (also see chapter 6). During business process ori-
ented interviews with employees of a target organization, the tool supports knowl-
edge analysts in structuring, capturing, verifying and validating interview data.
CHAPTER 4. PRINCIPLE APPROACH 73
Figure 4.6: Focus of the B-KIDE Tool
Subsequently, the tool provides a set of specific reports (model perspectives) that
aid knowledge infrastructure designers in the development of business process-
supportive knowledge infrastructures (Figure 4.6).
Chapter 5
B-KIDE Framework
Problems cannot be solved at the same level of awareness that created them.
Appendix Chapter A on page 162
5.1 Introduction
This chapter introduces the B-KIDE Framework in detail. The context in which
the B-KIDE Framework gets applied is described and subsequently, the B-KIDE
Model Architecture for modeling organizational knowledge processes and the B-
KIDE Method for designing business process-supportive knowledge infrastruc-
tures are introduced. Whenever appropriate, the UML1, a sophisticated, object-
oriented modeling language is utilized to structure and conceptualize the frame-
work and its elements. Knowledge about the UML specification [Gro] is assumed
by the author and a prerequisite for appropriately interpreting the following UML
diagrams.
5.2 B-KIDE Context
Figure 5.1 depicts the environment, in which the B-KIDE Framework and the B-
KIDE Tool are applied. Goals addressed, roles involved, assumptions made and
technological conditions concerning the application of the B-KIDE Framework
are introduced in this section.
1UML...Unified Modeling Language
74
CHAPTER 5. B-KIDE FRAMEWORK 75
Figure 5.1: Context of Applying the B-KIDE Framework and Tool (Based on
[Tol98])
5.2.1 Goals
The B-KIDE Framework and the accompanying B-KIDE Tool aim to provide
methodological and conceptual as well as tool support for the development of
business process-supportive, technological knowledge infrastructures that fulfill
the requirements defined in section 1.2.1.
5.2.2 Roles
The B-KIDE Framework aids knowledge analysts in modeling organizational
knowledge work as well as knowledge infrastructure designers in the design of
business process-supportive knowledge infrastructures. The B-KIDE Tool op-
eratively supports knowledge analysts in building models about organizational
knowledge work and knowledge designers in analyzing the models of knowledge
work as a basis for the design of appropriate knowledge infrastructures.
5.2.3 Limitations
Business process modeling, which itself represents a research domain at its own,
is beyond the scope of the B-KIDE Framework. The reason to that is because
in many organizations business process models already are available [isoa, isob]
CHAPTER 5. B-KIDE FRAMEWORK 76
and play a prominent role. Beneath that, the implementation of the developed
knowledge infrastructure designs is also not within the focus of the framework.
Implementation of knowledge infrastructures in organizations depends on a large
spectrum of influencing, sometimes even conflicting factors (such as corporate
culture, existing knowledge barriers or social resistance). A consideration of such
aspects is typically attributed to the domain of change management and is not
dealt with in this work.
5.2.4 Assumptions
The B-KIDE Framework focuses on the initial, static identification of currently
executed knowledge processes in organizations as a basis for the development
of business process-supportive knowledge infrastructures. Dynamic aspects of
knowledge processes (e.g. change over time, also see section 8.2) are not con-
sidered. By relating the SER2-Model introduced by [FMO+94] to the context of
this work it becomes clear that the B-KIDE Framework contributes to a seeding
phase of knowledge infrastructure development.
5.2.5 Technological Environment
The B-KIDE Framework aims to provide support in the development of
knowledge infrastructures on an implementation- and vendor-independent level.
Thereby, resulting knowledge infrastructures can be represented through orga-
nizational intranets, file servers, document-, content- or knowledge management
systems or any other technological basis that is able to fulfill the requirements
defined in section 1.2.1.
5.3 B-KIDE Model Architecture
The B-KIDE Model Architecture provides directives for creating models of or-
ganizational knowledge work. It consists of two main elements: 1) a modeling
structure (section 5.3.1) and 2) a modeling technique (section 5.3.2). These two
elements correspond to what [HvR00] describe, in the context of modeling object
systems, as the “Way of Modeling” and the “Way of Working”. The modeling
2SER...Seeding - Evolutionary Growth - Reseeding
CHAPTER 5. B-KIDE FRAMEWORK 77
structure (The Way of Modeling) introduces the conceptualizations that are used
in a modeling effort (notations, conceptual structures) while the modeling tech-
nique (The Way of Working) describes the procedures by which models about an
object system are constructed (the process).
Figure 5.2: Scope of the B-KIDE Model Architecture
The modeling structure depicted in figure 5.2 is described by the conceptual
B-KIDE Modeling Structure in UML (see figure 5.3 on page 79), while knowl-
edge process modeling is described by means of the B-KIDE Modeling Technique
(see figure 5.6 on page 87). The input for the B-KIDE Model Architecture is
represented through (modeled) business processes (see section 5.5 on page 98),
while the output represents modeled organizational knowledge processes about
the object system (see figure 5.5 on page 86).
5.3.1 B-KIDE Modeling Structure
The B-KIDE Modeling Structure defines how organizational knowledge work is
being modeled within the B-KIDE Framework. Figure 5.3 depicts the essential
elements and relationships of the modeling structure illustrated by a conceptual
UML diagram.
Figure 5.3 is explained in greater detail in the following sections by introducing
1) essential elements, attributes and relationships 2) reference models, 3) the
model of organizational work and 4) model perspectives.
CHAPTER 5. B-KIDE FRAMEWORK 78
Figure 5.3: The B-KIDE Modeling Structure
Essential Elements, Attributes and Relationships
The basic elements of figure 5.3 are Knowledge Work, Business Process,
Undefined Work Activity, Organizational Role, Knowledge Domain, Specific
Knowledge Activities, Generation Object, Storage Object, Transfer Object and
Application Object :
Knowledge Work: Knowledge Work is performed whenever knowledge
of a certain Knowledge Domain is processed (generated, stored, transferred or
applied) by an Organizational Role within a Business Action. To be compliant
with the introduced definition of section 1.4, Knowledge Work needs to be
related to at least one specific knowledge activity.
Business Process: Business Processes represent an organizational environ-
ment in which Knowledge Work is performed. The element Business Process
has an attribute Descriptive Title containing a descriptive name for the Business
CHAPTER 5. B-KIDE FRAMEWORK 79
Process.
Undefined Work Activity: An Undefined Work Activity represents the
complement set to Business Processes. These activities contain all organizational
Business Actions not modeled in Business Processes.
Organizational Role: An Organizational Role is responsible for executing
organizational Knowledge Work, within a Business Action. The element
Organizational Role has an attribute Descriptive Title containing a descriptive
name for the Organizational Role.
Knowledge Domain: A Knowledge Domain represents a topical field of
knowledge which is relevant in the context of undertaking Business Actions.
The element Knowledge Domain is attributed regarding a set of dimensions:
Descriptive Title contains a descriptive name for the Knowledge Domain, Buzz
Words contains a set of distinctive words (typically strongly rooted in the
specific language of the target organization) that further refine the meaning
of the Knowledge Domain. Knowledge Domain Type allows for classifying the
type of knowledge (e.g. procedural vs. descriptive) and Knowledge Domain
Assessment allows for assessing the Knowledge Domain regarding its relevance
in the target organization. Here it is important to note that a knowledge domain,
in order to be compliant with the introduced definition of section 1.4, needs to
be related to at least one specific knowledge activity.
Specific Knowledge Activities: Specific Knowledge Activities represent
qualified associations (such as the generation, storage, transfer and applica-
tion) between Knowledge Work and Knowledge Domains. Specific Knowledge
Activities are further refined by additional Generation, Storage, Transfer and
Application Objects. Structure and attributes of these objects, which represent
extensions to the principle approach introduced in chapter 4, are adaptable to
specific contexts.
Generation Object: The Generation Object further details the specific
knowledge activity generation. It represents applied techniques (such as synec-
CHAPTER 5. B-KIDE FRAMEWORK 80
tics, random stimuli, assumption smashing, etc.) or instruments (such as
brainstorming tools, simulations, etc.) [Rol03, chapter 5] that aid knowledge
workers in the process of knowledge generation. The element Generation Object
has an attribute Descriptive Title containing a descriptive name for the object.
Storage Object: The Storage Object describes how explicit knowledge of
certain Knowledge Domains is stored (e.g. in documents, systems, books, etc.)
in a target organization. The Storage Object allows for a more comprehensive
modeling of storage activities. A Storage Object is related to Organizational
Roles and Formally Responsible Business Processes3 and comprises explicit
knowledge of a Knowledge Domain. The attribute Locality contains a geographi-
cal or virtual place where the Storage Object is stored, Descriptive Title contains
a descriptive name and Description contains prose text to further refine the
meaning of the Storage Object at hand.
Transfer Object: The Transfer Object describes how knowledge of certain
Knowledge Domains is transferred (e.g. in meetings, through e-mail or informal
communications, etc.) in a target organization. Responsible senders as well
as receivers of knowledge transfer situations are depicted through relating the
Transfer Object to Organizational Roles as well as to Formally Responsible
Business Processes4. A Transfer Object has an attribute Periodicity that
contains information about the frequency of the knowledge transfer situation.
Descriptive Title contains a descriptive name and Description contains prose
text to further refine the meaning of the Transfer Object at hand.
Application Object: The Application Object further details the specific
knowledge activity application. It represents all applied instruments and
techniques that take aspects of knowledge application (such as pedagogy) into
account. This includes, but is not limited to e.g. checklists, learning materials,
information retrieval instruments, training, mentoring, coaching and others.
The element Application Object has an attribute Descriptive Title containing a
3To reduce complexity in figure 5.3, these relationships are not depicted there. More detailscan be found in section 6.3
4Again, for the same reason, these relationships are not depicted in figure 5.3. More detailscan be found in section 6.3
CHAPTER 5. B-KIDE FRAMEWORK 81
descriptive name for the object.
Distinction between Storage and Transfer Objects: Since a distinction
between storage and transfer objects is not always obvious, the following
definitions aim to provide clarification:
Definition 1: An Object is a Storage Object whenever the object in question
is stored by an individual or system and is available to others.
Definition 2: An Object is a Transfer Object whenever the object in
question is intentionally transferred by an individual or a system to a receiver,
and the receiver reliably receives the object.
Example 1: An electronic document residing on an intranet represents a Stor-
age Object, since the document is stored on a drive which is available to others,
but the document is not intentionally transferred to receivers. Example 2: A
private e-mail communication represents a Transfer Object, since the e-mail is
intentionally and reliably transferred to a receiver, yet the e-mail itself is not
available to others. Example 3: An e-mail list represents both a Storage and a
Transfer Object, since the e-mail list is stored in an archive that is available to oth-
ers and e-mails are intentionally and reliably transferred to receivers (subscribers
of the e-mail list).
Reference Models
Within the B-KIDE Modeling Structure, certain elements are organized in hier-
archically5 structured reference models (similar to the ARIS-House concept by
[Sch00]). These elements are called reference elements. Reference models fulfill
the purpose of ensuring uniqueness of elements (such as knowledge domains, busi-
ness processes, etc.) in models of organizational work. This is considered to be
a critical factor for validation of developed models [KS98]. Here, reference mod-
5In certain cases (e.g. extensively complex business process landscapes) more sophisticatedstructures than hierarchical ones may be necessary. Topic maps [Pep00, Top01] represent aconcept that is well equipped for modeling such complex structures and can, if necessary, beintegrated into the B-KIDE Framework easily.
CHAPTER 5. B-KIDE FRAMEWORK 82
els represent no generic blueprints that are applicable across various knowledge
infrastructure development projects, but a set of unique elements instantiated
per project. In total, seven reference models exist (see table 5.1): a business
process-, knowledge domain-, organizational roles-, storage object- and transfer
object reference model. The business process reference model aims to repre-
sent existing business process landscapes, the knowledge domain reference model
aims towards structuring knowledge domains according to knowledge structure
diagrams [Noh00], the organizational roles reference model represents existing
organizational structures, the generation object reference model contains existing
instruments applied for the generation of knowledge, the storage object refer-
ence model structures existing knowledge storage possibilities, the transfer object
reference model structures existing knowledge transferring instruments and mech-
anisms and the application object reference models contains existing instruments
that aid the application of available knowledge. The power of these reference
models lies in the integration of existing business conceptualizations such as hier-
archical organizational structures and the introduction of new conceptualizations
such as generation, storage, transfer or application object reference models that
together allow for the comprehensive modeling of organizational knowledge pro-
cesses. Within the B-KIDE Framework, reference models are used as a common
conceptualization of certain dimensions of organizational knowledge work.
Reference Model Business Analogy
Business Process Reference Model Business Process Landscape
Knowledge Domain Reference Model Knowledge Structure Dia-
gram
Organizational Roles Reference Model Organizational Structures
and Hierarchies
Generation Object Reference Model N/A
Storage Object Reference Model N/A
Transfer Object Reference Model N/A
Application Object Reference Model N/A
Table 5.1: B-KIDE Reference Models and Business Analogies
CHAPTER 5. B-KIDE FRAMEWORK 83
The Model of Organizational Knowledge Work
The aforementioned elements and reference models are networked (according to
the relationships defined in figure 5.3) to a model of organizational knowledge
work. The modeling technique described in section 5.3.2 explains how the process
of modeling is performed with the B-KIDE Framework. In chapter 6, the B-KIDE
Tool is introduced that represents an instrument that aids knowledge analysts in
creating these models.
Model Perspectives
The B-KIDE Model Architecture enables the creation of model perspectives
(or view points as depicted in figure 5.1) on an object system. This allows
for performing the transformation illustratively introduced in 4.3.2. While the
B-KIDE Model Architecture allows for a broad range of model perspectives (see
chapter 9), two perspectives are of special relevance in the context of this PhD
work. These two model perspectives are introduced in table 5.2 and are further
defined6 in figures 5.4 and 5.5.
Model Perspec-
tive
Central Structuring
Element
Purpose
Business Process
Perspective
Business Processes Basis for the Creation and
Validation of the Model
Knowledge Process
Perspective
Knowledge Domains Basis for the Development
of Knowledge Infrastructure
Designs
Table 5.2: B-KIDE Model Perspectives
Business Process Perspective:
The business process perspective in figure 5.4 represents a traditional approach
6The introduced UML diagrams of model perspectives in this section define how the modelperspectives need to be structured in order to fulfill their respective tasks. They depict a spe-cific processing result achieved through transformation operations performed on the modelingstructure in figure 5.3. Thus, the UML diagrams themselves do not contain information abouttransformation operations.
CHAPTER 5. B-KIDE FRAMEWORK 84
to modeling knowledge in business processes (such as [All98, GPSW03]). The
main structuring elements of this perspective are business processes. Thus,
along business processes, the generation, storage, transfer and application
of knowledge by organizational roles is illustrated. This perspective, which
corresponds to the principles introduced in figure 4.3, is especially useful to
validate the created models with organizational reality, since knowledge workers
of a target organization easily can relate to the (already familiar) business
process models. However, the business process perspective is no sound basis for
the deduction of business process-supportive knowledge infrastructures because
of the focus on work- instead of knowledge flows and thus, raises the need for an
additional view on the created model.
Figure 5.4: The B-KIDE Business Process Perspective
Knowledge Process Perspective:
The knowledge process perspective in figure 5.5, which corresponds to the prin-
ciples introduced in figure 4.4, represents an orthogonal view on the business
process perspective [Str03a]. The main structuring elements of this perspective
are not business processes, but knowledge domains. Along knowledge domains,
business processes (respectively business actions) together with organizational
roles that contribute to the generation, storage, transfer and application of the
CHAPTER 5. B-KIDE FRAMEWORK 85
Figure 5.5: The B-KIDE Knowledge Process Perspective
knowledge domain in question are illustrated. Thereby, the knowledge process
perspective allows to easily “follow” the flow of knowledge through an organi-
zation. Additional information about the way, how the knowledge domain in
question is generated (Generation Object), stored (Storage Object), transferred
(Transfer Object) and applied (Application Object) complement the knowledge
process perspective. This perspective represents the core concept of this PhD
work and the central input for the B-KIDE Method (described in section 5.4).
5.3.2 B-KIDE Modeling Technique
Introduction
Modeling within the B-KIDE Framework is based on structured, process-oriented
interviews with knowledge workers of a target organization. The knowledge ana-
lyst performs interviews with certain organizational roles. The main instrument
for performing the interviews is the B-KIDE Tool (introduced in chapter 6) that
represents a specific implementation of the B-KIDE Modeling Structure (section
5.3.1).
The modeling technique in figure 5.6 describes the way of modeling organiza-
tional knowledge work with the B-KIDE Framework. The process is divided into
four main sub activities that are introduced in this section:
CHAPTER 5. B-KIDE FRAMEWORK 86
Figure 5.6: The B-KIDE Modeling Technique
B-KIDE Modeling Technique
Scope Definition page 87
Pre-Modeling page 88
Object System Modeling page 88
Model System Refinement page 90
Table 5.3: B-KIDE Modeling Technique Activities
Modeling Activity 1: Scope Definition
Decision on a Target Area: A decision upon the target area of the anticipated
knowledge infrastructure needs to be made. This decision has to define targeted
business processes at a targeted abstraction level as well as targeted roles that
shall be supported with the future knowledge infrastructure.
Selection of Interviewees: A minimum of two interview partners per
targeted role needs to be interviewed. While the first interview partner represents
an expert in his (process) domain, the second represents an intermediate that
knows the basics of the organization and its processes, but is relatively new
to it. The reasons for that are twofold: First, by interviewing two persons
per role, a more comprehensive understanding about organizational roles and
their functions can achieved while second, the mixture of an expert and an
intermediate is able to identify a richer spectrum of existing knowledge processes.
Development of an Interview Plan: An interview plan (as depicted in
appendix section C.2) aids a knowledge analyst in better organizing his sched-
uled interviews. The interview plan typically includes a description of targeted
business processes, targeted organizational roles and persons as well as the timely
CHAPTER 5. B-KIDE FRAMEWORK 87
sequence of the interviews.
Modeling Activity 2: Pre-Modeling
Gathering Existing Documentation: Documentation that is useful in the
context of modeling organizational work needs to be gathered and analyzed.
Such documentation includes existing business process models, knowledge
structure diagrams, hierarchical organization charts, business strategies (as a
starting point for deducing knowledge structure diagrams), existing technological
systems, filing structures, communication channels and others. This material
represents a sound basis for preparing the B-KIDE reference models.
Pre-Modeling B-KIDE Reference Models: With the material gathered,
parts of the reference models introduced in section 5.3.1 can well be prepared
before actually starting to model the object system of organizational knowledge
work through interviews. The business analogies of table 5.1 depict which ex-
isting organizational documentation can be utilized for this purpose. Although
no business analogy for generation, storage, transfer and application object ref-
erence models exist, they as well can be prepared by coarsely listing all relevant,
currently known, generation, storage, transfer and application objects. In order
to enhance the quality of pre-modeling efforts, e.g. knowledge domain reference
models can be refined by performing pre-interviews with domain experts. Also,
relationships between roles and business processes need to be assigned based on
existing business process models. This is a necessary input for appropriately set-
ting up the B-KIDE Tool (chapter 6) for interviews. Pre-modeling significantly
lowers the burden of work for knowledge analysts during interview situations.
Modeling Activity 3: Object System Modeling
Interview Preparation: For each interview, the knowledge analyst prepares
himself according to the interview guidelines of appendix C.
Interview Organization: The knowledge analyst performs a set of inter-
views with employees in order to model the object system of organizational
knowledge work according to the B-KIDE Modeling Structure. In each interview,
CHAPTER 5. B-KIDE FRAMEWORK 88
he has to clearly communicate the goals as well as the content of the interview to
the interviewee. He introduces the interview process and subsequently, starts to
collect information from the interviewee by asking the corresponding questions
and using the B-KIDE Tool introduced in chapter 6.
Object System Modeling: The knowledge analyst guides each interviewee
through process-oriented interviews. In each interview, he gathers information
about the knowledge work of the interviewee in the respective business processes
(according to the business process perspective introduced in section 5.3.1) and
refines the pre-modeled reference models. In doing that, the knowledge analyst
utilizes (provisional) reference models of past interviews for current interview
situations. This is in stark contrast to approaches such as [KHS03, page 269]
which define (knowledge) ontologies a priori and, in a strict order, subsequently
utilize these ontologies as a basis for knowledge flow identification. Because
during knowledge flow identification activities (such as structured interviews) new
knowledge domains may come up, pre-modeled (knowledge) ontologies strongly
need revision. Concerning an iterative approach of modeling reference models,
[SAA+02] remark:
“This is typical of elicitation: the (provisional) knowledge structures
the analysts build are subsequently used to focus the elicitation of ex-
pertise data.” [SAA+02, page 206]
Of special importance is the challenging task of matching knowledge domains
(that depict results of previous interview situations) to current interview
situations. Here, the knowledge analyst has to decide if an interview partner A
and an interview partner B talk about similar, identical or separate knowledge
domains. The B-KIDE Model Architecture supports knowledge analysts in this
task by providing room for detailed descriptions of knowledge domains as well as
organization-specific buzz words that add helpful meaning to knowledge domains.
Model System Validation: At the end of each interview, the knowledge
analyst confronts the interviewee with the information gathered during this inter-
view (through an appropriate, interview centered business process perspective).
The knowledge analyst together with the interviewee correct and validate this
CHAPTER 5. B-KIDE FRAMEWORK 89
perspective7. Before officially closing the interview, it is helpful, to exchange
contact details between the knowledge analyst and interviewee, to be able to
deal with open questions or complementary comments that may emerge after the
interview.
Modeling Activity 4: Model System Refinement
Reference Model Organization: After completing each interview, the
knowledge analyst reorganizes the hierarchical reference models according to
his gained understanding about the object system. Although the knowledge
analyst (the modeler) slightly influences the model system in doing that, this
activity supports the knowledge analyst in subsequent interview situations. Also,
relationships between various reference models are not concerned by reorganizing
specific reference models.
Reference Elements Refinement: Since in interview situations the knowl-
edge analyst is typically under time pressure, he may not be able to gather all
necessary information in an appropriate way. This activity therefore allows the
knowledge analyst to refine descriptions of e.g. only coarsely described knowl-
edge domains. During the development of knowledge infrastructure designs, these
descriptions will help knowledge infrastructure designers in gaining a better un-
derstanding about the object system.
5.4 B-KIDE Method
The B-KIDE Method introduces a normative design process Designing Knowl-
edge Infrastructures that leads KI designers through necessary design activities.
In addition, a knowledge infrastructure template architecture acts as a funda-
ment for the design of technological knowledge infrastructures that address the
objectives of this PhD work.
The KI template architecture depicted in figure 5.7 is described by the knowl-
edge infrastructure template architecture in UML (see figure 5.9 on page 96),
while Designing Knowledge Infrastructures is described by a normative design
7Aspects of validation include checks for 1) self consistency, 2) uniqueness of model elementsand 3) model accuracy (based on [KS98, p.103-104]).
CHAPTER 5. B-KIDE FRAMEWORK 90
Figure 5.7: Scope of the B-KIDE Method
process in section 5.4.1 (see figure 5.8 on page 92). The input for the B-KIDE
Method is represented through modeled knowledge processes (see figure 5.5 on
page 86), while the output represents a knowledge infrastructure design that
appropriately supports knowledge processes (see chapter 7 on page 118).
5.4.1 Design Process “Designing Knowledge Infrastruc-
tures”
For the development of knowledge infrastructures that support an organization’s
knowledge intensive business processes, a normative design process is introduced.
Based on knowledge processes identified by knowledge analysts, this design pro-
cess aids KI designers in integrating identified (knowledge) requirements into
their knowledge infrastructure designs. Typically, design is either perceived as
a product or a process. Because of the emergent field of knowledge manage-
ment systems and vendors and the lack of common conceptualizations, this work
predominately focuses on a process approach to design. Thereby, the resulting
approach can be applied across different knowledge management system vendors
and conceptualizations. In this PhD work, the following definition of design by
[YC79] is applied:
“Design means to plan or mark out the form and method of a solution.
It is the process which determines the major characteristics of the final
system [...].” [YC79, p. 8]
CHAPTER 5. B-KIDE FRAMEWORK 91
The design process consists of three main design activities illustrated in figure
5.8: 1) Preliminary Knowledge Process Definition 2) Knowledge Infrastructure
Design and 3) Knowledge Infrastructure Design Validation.
Figure 5.8: Design Process “Designing Knowledge Infrastructures”
Design Activity 1: Knowledge Process Definition
Knowledge processes represent the major imperative for the design process. By
integrating requirements from knowledge processes in knowledge infrastructure
designs, the resulting knowledge infrastructures are able to provide comprehen-
sive support for knowledge intensive business processes. To specify these require-
ments, the knowledge infrastructure designer uses the identified as-is knowledge
processes and, together with knowledge workers and representatives of the man-
agement, defines to-be knowledge processes based on them. To achieve agreement
about the final knowledge process definitions between a set of different project
stakeholders and constraints, a quality gateway [RR99] is utilized:
“The quality gateway is the activity where each knowledge process is
examined to determine if it is suitable for inclusion in the specifica-
tion.” (Based on [RR99, page 182])
In order to be able to decide upon the inclusion of knowledge processes, a
clear picture about 1) the organizational roles that need to be supported8 and 2)
the specific goals that the knowledge infrastructure development project pursues
8This decision may already be made in section 5.3.2. Nevertheless, at this point, the decisionmay be altered and the scope may be narrowed because of new identified constraints or findings.
CHAPTER 5. B-KIDE FRAMEWORK 92
is essential. To define these goals, fit criteria [RR99] need to be developed. Fit
criteria allow for checking the developed knowledge infrastructure design9 for
integration of appropriate knowledge process support. While the fit criteria are
developed in this design activity, the check is performed later on - in design
activity 3 in section 5.4.1. Examples for such fit criteria10 are:
• Organizational roles shall have appropriate access to the knowledge they
need to apply in the KI.
• Organizational roles shall be able to appropriately provide the defined
knowledge to the KI.
• Defined storage objects shall appropriately be supported and managed by
the KI.
• Knowledge shall appropriately be transferred by the KI.
In the process of defining to-be knowledge processes, the meaning of appro-
priate in the context of each organization has to be determined while at the
same time taking framing conditions such as financial, organizational or techno-
logical constraints into account. An example for such conditions would be the
support of existing knowledge processes through the mandatory application of
certain knowledge management system functionality (such as Hyperwave Por-
tals [Hyp]). In such a case, only as-is knowledge processes focussing on explicit
knowledge may be considered, and only functionality provided by the knowledge
management system Hyperwave may be utilized to provide support.
Fork A in figure 5.8 illustrates the two principle ways the B-KIDE Method
can be applied: Option 1 represents a way to evaluate existing KIs and KI designs
for improvement potentials while option 2 specifies new knowledge infrastructure
designs from scratch.
9Here, knowledge infrastructure design is understood as a product; e.g. a design documentthat marks out the form of the final solution.
10While the fit criteria introduced here apply well to designing technological aspects of knowl-edge infrastructures, other fit criteria (such as [Kun02, chapter 3]) may be adopted when itcomes to designing e.g. organizational aspects.
CHAPTER 5. B-KIDE FRAMEWORK 93
Design Activity 2: Preliminary Knowledge Infrastructure Design
The KI template architecture introduced in section 5.4.2 together with knowledge
process definitions represent the main input for this design activity. Here, the
template architecture introduced in section 5.4.2 is instantiated according to
the constraints of each KI development project. In each template architecture
layer the KI designer considers the requirements specified by the knowledge
process definitions. Thereby, the KI designer either designs and introduces a
new technological infrastructure, or alters existing infrastructures to enhance
technological environments of knowledge workers. The fit criteria developed in
design activity 1 (which are applied in design activity 3 in section 5.4.1) already
guide the KI designer in his design efforts. This not only allows him to perform
the design process in a more efficient way, it also reduces the complexity of this
task.
The knowledge infrastructure design typically consists of the four elements
of the knowledge infrastructure template architecture: 1) a content concept
that includes and defines all employed knowledge infrastructure objects and
-functionality. 2) a metadata concept that allows for accessing contents through
a certain set of different dimensions. 3) a structure concept that typically
describes the predominant way of navigating to contents and 4) An access
concept that defines users, roles and permissions for the anticipated knowledge
infrastructure. Finally these contents need to be integrated as described in
section 5.4.2. The development of these concepts allows to validate the KI design
in detail against the defined fit criteria in the next design activity.
Latest research work on how knowledge processes (and specific knowledge ac-
tivities) can be supported by KM technology (such as [Rol03]) especially aids
KI designers in designing the contents layer (defining the necessary contents and
functionality) of knowledge infrastructures. In addition to that, the access layer
can also well be designed by taking role-oriented views on the developed Knowl-
edge Process Landscape. Taking a role-perspective on knowledge work allows
KI designers to understand what contents and functionality of a knowledge in-
frastructure organizational roles need to access. To glue these layers together,
KI designers subsequently develop appropriate structure and metadata concepts
CHAPTER 5. B-KIDE FRAMEWORK 94
based on existing methods and techniques (also see section 5.4.2).
Design Activity 3: KI Design Validation
This design activity validates the developed KI design in terms of its support
for knowledge processes. The fit criteria developed in design activity 1 now
fulfill the purpose of an instrument that is utilized for validating the preliminary
knowledge infrastructure design. By checking each fit criterion against 1) every
defined knowledge process and 2) against the knowledge infrastructure design,
the knowledge infrastructure designer can identify fits as well as deficits in
the current design. A lack of sufficient fits leads to iterations through design
activity 2 and 3. Examples for performing that kind of validation includes
investigating the knowledge infrastructure design by means of role-oriented
inspection, checking for existence of necessary generation, storage, transfer and
application objects or examining support for knowledge flows. Fork B illustrates
this in case 2. Case 1 depicts a situation, where the knowledge infrastructure
design suffices the requirements identified and thus, can be utilized as a profound
basis for implementation.
To summarize:
The application of the B-KIDE Method yields to a design space that
is quantitatively open (in terms of the number of possible designs) but
qualitatively closed (in terms of the requirements supported).
In other words, the application of the B-KIDE Method in knowledge infrastruc-
ture development projects prescribes what needs to be implemented in the tar-
geted knowledge infrastructure designs (in the sense of functional requirements -
in order to support the defined knowledge processes), but not how this function-
ality is provided.
5.4.2 B-KIDE Knowledge Infrastructure Template Archi-
tecture
The knowledge infrastructure template architecture in figure 5.9 represents a
system architecture, which illustrates the basic layers of technological solutions
CHAPTER 5. B-KIDE FRAMEWORK 95
tackling the challenges introduced in section 1.2.1. The basic layers are: 1) Con-
tents 2) Taxonomies and Meta Knowledge11 and 3) Access. Based on identified
knowledge processes in organizations, the knowledge infrastructure template ar-
chitecture is instantiated per KI development project for the design of appropriate
knowledge infrastructures for organizations.
Figure 5.9: The Knowledge Infrastructure Template Architecture
Contents
All elements and services accessible to an organization through its ICT infrastruc-
ture (such as documents, templates, guidelines, lessons learned, chats, forums,
messages, e-mails, calendars, task lists, FAQs, e-learning modules, yellow pages,
agents, web sites, proprietary systems and others) are regarded to be part of
the contents layer of knowledge infrastructures. Comprehensive research work on
contents and types of contents of technological knowledge management systems
has been performed and is already available [Mai02, chapter 7]. These elements
and services (or contents) can be organized according to a set of different cate-
gories, as introduced in the next paragraph.
Taxonomies and Meta Knowledge
Taxonomies and meta knowledge allow for organizing the contents of knowledge
infrastructures. Taxonomies structure the contents of knowledge infrastructures
while meta knowledge enriches content by attaching descriptive information.
11Both taxonomies and meta knowledge represent concepts for knowledge organization andtherefore are grouped together
CHAPTER 5. B-KIDE FRAMEWORK 96
Both instruments represent the basis for accessing knowledge infrastructure
elements. Taxonomies and meta knowledge are regarded to pose a strong
influence on the usefulness of technological knowledge infrastructures. They 1)
determine how quick employees can navigate to contents and 2) represent the
basis for the employees’ mental models of the knowledge infrastructure. Thus,
both instruments have descriptive and normative aspects [Mai02, section 7.2.3].
Categorizations, which are utilized to structure and enrich knowledge infras-
tructure contents include, but are not limited to: domain-, process-, method-,
product-, project-, customer-, organization-, time-, person- and role-oriented
categorizations.
Taxonomies and meta knowledge concepts often utilize a combination of a
set of different categorizations. In practice, these concepts are typically devel-
oped heuristically in workshops, without much methodical support [Mai02, p.
204]. Instruments that could aid the structured development of such concepts
are standards (such as [Dub03, Ass02]), procedures (such as [DB03]), methods
(such as [MHA03]) or best practices (such as [RR03]). Ontologies too represent
a concept that can be utilized in such contexts (e.g. in [AML+01, KHS03]).
Access
The access layer consists of instruments for accessing the contents of technolog-
ical knowledge infrastructures. Such instruments can utilize hierarchical tree or
list navigation, catalogues (such as [Net04]), retrieval systems, complex visualiza-
tions (such as Infosky [KSG+03]) as well as portals [Dia01, Noh02, LSF+03]. All
instruments utilize the taxonomy and meta knowledge layer for providing access
to the contents layer below. The access layer thus represents an environment for
knowledge workers that aims to provide comprehensive support for their respec-
tive knowledge work. Standards for the formalization of access concepts already
exist and are available for application (such as [Ame03]).
CHAPTER 5. B-KIDE FRAMEWORK 97
5.5 Remarks on B-KIDE Framework Applica-
tion
The B-KIDE Framework represents an idealized way of executing knowledge
infrastructure development projects. Nevertheless, the framework can be
employed selectively in knowledge management projects: The B-KIDE Method
can be applied without detailed empirical knowledge process identification
(where e.g. the functionality of knowledge infrastructures is entirely defined by
an expert project team) or knowledge processes can be identified for analysis
purposes only (e.g. for identifying areas with a high potential of improvement).
Either way, the B-KIDE Framework provides means (such as the B-KIDE KI
Template Architecture or the B-KIDE Tool) that support knowledge analysts
as well as knowledge infrastructure designers in performing their corresponding
tasks. However, the power of the B-KIDE Framework lies in the strong ties
between analysis and design phases of knowledge infrastructure development
projects.
To be applicable, the framework relies on finding the following basic conditions
in target organizations:
• The target organization has implemented and lives a business process ori-
ented management approach which comprises modeled business processes.
• The business processes of the target organization represent a feasible way of
doing business. This is an especially necessary prerequisite, since this work
does not focus on improving certain business processes, but on supporting
a network of business processes appropriately.
• Employees of the target organization share a common set of vocabularies
and a common language when communicating business relevant issues.
• The target organization is regarded to be a knowledge-intensive organiza-
tion [ESR99] and is producing / delivering knowledge-intensive goods or
services.
• Key roles of the target organization are involved in knowledge intensive
activities [ESR99] and are available for structured interviews.
CHAPTER 5. B-KIDE FRAMEWORK 98
• The target organization has IT systems with knowledge management func-
tionalities (such as [MR02, MT02]) at its disposal and is willing to use
it.
• The target organization employs a culture that is open for change.
Chapter 6
B-KIDE Tool
Consistency is the last refuge of the unimaginative.
Appendix Chapter A on page 162
6.1 Introduction
Today, the identification of knowledge flows typically relies on fuzzy instruments
such as unstructured workshops, interviews or talks with employees of an orga-
nization. The B-KIDE Tool introduced in this chapter aims to provide software
functionality that is able to map interview data gathered from structured, pro-
cess oriented interviews with knowledge workers of a target organization onto
the B-KIDE Modeling Structure. In doing that, the B-KIDE Tool complements
the B-KIDE Framework (as depicted in figure 6.1). The relation between the
framework and the tool can best be described as a method-tool companionship
[Tol98].
6.1.1 Goals
The B-KIDE Tool aims to support knowledge analysts and knowledge infrastruc-
ture designers in applying the B-KIDE Framework. Therefore, the B-KIDE Tool
implements the B-KIDE Modeling Structure to provide a formal, supportive
instrument for process-oriented interviews that reduces complexity of applying
the B-KIDE Framework. The B-KIDE Tool aims to support a broad range of
analysis options on top of the developed models of organizational work in order
99
CHAPTER 6. B-KIDE TOOL 100
Figure 6.1: Scope of the B-KIDE Tool
to aid knowledge analysts as well as knowledge infrastructure designers in their
respective tasks (section 2.2).
To illustratively explain the goals of the B-KIDE Tool, a usage narrative
[Coc00] sketches up a typical application scenario:
Arthur, a knowledge analyst and knowledge infrastructure designer, is
in charge of developing and conceptualizing a technological knowledge
infrastructure for the company KnowIntBusiness Corp., which itself
is producing knowledge intensive goods in a knowledge intensive envi-
ronment. Since Arthur has to develop a knowledge infrastructure that
supports the company’s employees in their most critical, knowledge
intensive and value generating activities and tasks, he investigates the
company’s business processes from a knowledge perspective. There-
fore, Arthur performs a series of process-oriented interviews with
KnowIntBusiness Corp.’s knowledge workers, utilizing the B-KIDE
Tool to structure and prepare the interviews as well as to document
interview results according to the B-KIDE Modeling Structure. After
interviewing, Arthur uses various B-KIDE Tool Reports to analyze
and synthesize the gathered data in terms of various perspectives on
the developed model of organizational work. Based on these investi-
gations, and by applying the accompanying B-KIDE Method, Arthur
is able to lay out the design of a technological knowledge infrastruc-
ture that warrants a certain degree of support for KnowIntBusiness
CHAPTER 6. B-KIDE TOOL 101
Corp.’ employees in their respective business processes.
In section 6.4, the main functionality of the B-KIDE Tool in the light of this
usage narrative is introduced.
6.1.2 Scope
The B-KIDE Tool is designed to be applied by knowledge analysts and knowledge
infrastructure designers during knowledge infrastructure development projects.
Figure 6.2 illustrates the primary actors of the B-KIDE Tool.
Figure 6.2: Primary Actors of the B-KIDE Tool
6.1.3 B-KIDE Tool Approach
The B-KIDE Tool is a supportive instrument for structured, business process-
oriented interviews between knowledge analysts and knowledge workers of an
organization. The gathered interview data is analyzed and subsequently utilized
to lay out the design of business process-supportive knowledge infrastructures by
knowledge infrastructure designers.
Figure 6.3: B-KIDE Tool Principle Approach
Figure 6.3 illustrates the principle approach of the B-KIDE Tool. Front end
interview forms, applied by knowledge analysts during interview situations, pro-
vide means to map gathered interview data onto the B-KIDE Modeling Structure.
CHAPTER 6. B-KIDE TOOL 102
This ensures that gathered interview data conforms to the B-KIDE Modeling
Structure. On top of the interview data, a set of B-KIDE Tool Reports allows
for generating a wide range of different model perspectives and thereby allows
for generating different models of organizational work as a profound basis for
analysis.
In the next section, the main logical structure and the core elements of the B-
KIDE Tool are introduced.
6.2 B-KIDE Tool Structure
Figure 6.4: Simplified Illustration of B-KIDE Tool’s Main Structure and Elements
The B-KIDE Tool is based on the logical structure depicted in the simplified
illustration in figure 6.4. Thus, a B-KIDE project consists of multiple inter-
views and a set of (in total five) reference models1. Each interview contains
information about the interview context as well as the actual interview data.
Interview context contains information about the corresponding interviewee, his
organizational role, and the analyst who performs the interview. Interview data
contains all elicited, interviewee-specific interview information gathered through
a series of interview forms (further details in section 6.3.2). In addition to that,
1The Generation and Application Reference Models were not implemented in the B-KIDETool because of the foci of the anticipated pilot studies
CHAPTER 6. B-KIDE TOOL 103
reference models, which exist in parallel to interview data, represent models of
specific dimensions of organizational systems and provide the fundament for
modeling organizational work with the B-KIDE Tool (further details in section
6.3.1). These dimensions are based on five reference models from the B-KIDE
Model Architecture, which are: 1) Knowledge Domain Reference Model 2)
Business Process Reference Model 3) Organizational Roles Reference Model
4) Transfer Object Reference Model and 5) Storage Object Reference Model.
With the B-KIDE Tool, these dimensions are modeled in a collaborative effort
between knowledge analysts and interviewees.
Figure 6.5 depicts the implementation of the main elements in the B-KIDE
Tool user interface. While the area containing the reference models remains the
same across different interviews of the same project, the interview context depicts
information specific to certain interviews. The interview data area, which changes
with changing interviewees, represents the central area for analysts to gather
information during interviews.
Figure 6.5: Main User Interface of the B-KIDE Tool
CHAPTER 6. B-KIDE TOOL 104
6.3 B-KIDE Modeling Structure Mapping
This section describes the mapping of the B-KIDE Tool data structures onto the
B-KIDE Modeling Structure introduced in 5.3.1 on page 78.
6.3.1 Reference Models
Figure 6.6: Implementation of the B-KIDE Tool Reference Models
Figure 6.6 depicts how the reference models of the B-KIDE Modeling Struc-
ture are implemented in the B-KIDE Tool Reference Models area depicted in
figure 6.5. While each reference model is hierarchically organized, specific ref-
erence models can be interconnected with each other. Firstly, an assignment of
organizational roles to business processes2 takes place based on the organizational
involvement of roles in business processes. This lays the fundament for business
process oriented interviews where each interviewee is confronted with exactly
those business processes, which his role is involved in. Transfer Objects comprise
relations to organizational roles that act as senders or receivers in transfer activ-
ities. Storage Objects comprise relations to organizational roles that perform the
act of storing. Both Transfer and Storage Objects maintain linkages to business
processes in which these knowledge activities are defined.
2the so-called “Business Process-Roles Assignment” - also see appendix chapter C
CHAPTER 6. B-KIDE TOOL 105
6.3.2 Interview Data
Figure 6.7: Implementation of the B-KIDE Tool Interview Forms
The interview data area depicted in figure 6.5 is structured according to the
UML diagram depicted in figure 6.7. For each business process the interviewee
is involved in, an interview form is generated. Each interview form consists of
two interview data panels, one focussing on the generation and the other on the
application of knowledge by the interviewee. Interview data panels themselves
contain multiple interview lines. Each interview line is concerned with a spe-
cific knowledge domain that is either applied or generated by the interviewed
knowledge worker (based on communication request/respond patterns). For each
knowledge domain, communication partners (organizational roles in correspond-
ing business processes) and aspects of storage/transfer can be documented. The
B-KIDE Tool ensures the appropriate mapping of the gathered data onto the
B-KIDE Modeling Structure.
CHAPTER 6. B-KIDE TOOL 106
6.4 B-KIDE Tool Application
Application of the B-KIDE Tool can be divided in three main phases: 1) Setup
and Pre-Modeling 2) Interviewing and 3) Analysis.
6.4.1 Setup and Pre-Modeling
Before knowledge analysts actually can use the B-KIDE Tool for executing
process-oriented interviews, the tool needs to be appropriately set up. In
figure 6.8 the interface for setting up the context of a series of interviews is
illustrated. For each interview, an analyst, an interviewee and a corresponding
organizational role of the organization has to be assigned.
Example: In the depicted interview in figure 6.8, Arthur interviews Bill in
the role of a sales agent.
Figure 6.8: Setting Up Interviews with the B-KIDE Tool
In order to be able to start with to the execution of interviews, certain aspects
of the target organization need to be pre-modeled. A Business Process Reference
CHAPTER 6. B-KIDE TOOL 107
Model (based on e.g. an existing Business Process Landscape), as well as an Or-
ganizational Roles Reference Model (based on e.g. an existing organigram) rep-
resent a prerequisite for the B-KIDE Tool to generate a set of (process-oriented)
interview forms per interview, realized as windows form tabs (depicted in figure
6.9). These forms represent the underlying, formal structure for the anticipated
interviews. This ensures that, during interviews, interviewees are (exclusively)
confronted with business processes they are involved in.
Figure 6.9: B-KIDE Tool’s Interview Forms per Interview
Figure 6.10 illustrates how a new organizational role can be added to the
Organizational Roles Reference Model during pre-modeling.
Figure 6.10: Setting Up Reference Elements with the B-KIDE Tool
6.4.2 Interviewing
In interview situations, the B-KIDE Tool guides analysts through a series of
process oriented interview forms per interviewee. In doing that, the B-KIDE
Tool provides not only a (process-oriented) structure for the interviews, but
also displays questions that knowledge analysts need to ask during interviews
(depicted in figure 6.11, mouse pointer B). The B-KIDE Tool bases its questions
CHAPTER 6. B-KIDE TOOL 108
on request/response patterns of knowledge workers to identify knowledge
processes. Answers given by interviewees are modeled by dragging and dropping
reference elements from the Reference Model area (see figure 6.11, mouse pointer
A) to the respective answer fields in the process oriented interview forms within
the interview data area.
Figure 6.11: Inputting Interview Data with the B-KIDE Tool
Example: Knowledge analyst Arthur, utilizing the B-KIDE Tool, asks inter-
viewee Bill, what information he needs in order to be able to execute the business
process “Acquisition”, in which he is involved. Bill replies that information
about potential customers is necessary for him in order to successfully execute
this process. Arthur drags the already existing knowledge domain “knowledge
about customers” from the knowledge domain reference model to the respective
answer field in the interview data area (depicted in Figure 6.11, mouse pointer
CHAPTER 6. B-KIDE TOOL 109
A). The B-KIDE Tool notices this action and translates the established relation3
to the B-KIDE Modeling Structure. In doing that, knowledge work is modeled
in a way that was depicted and introduced in figure 4.3 on page 69.
In the likely event that new reference elements emerge during interview
situations, knowledge analysts can manipulate the respective reference models
by inserting, editing or deleting reference elements in a way that is depicted in
figure 6.10 and 6.12.
Figure 6.12: Editing Reference Elements with the B-KIDE Tool
Example: Figure 6.12 depicts a concrete example of editing the properties of
a specific reference element: The Transfer Object “Sales Meeting”. In this figure,
the Sales Meeting is a transfer object of the type “meeting”. This meeting takes
place weekly and during this meeting, marketing staff communicates information
about potential customers to sales agents. The meeting is not defined in any
modeled business processes.
3In prose, this relation can be described in the following way: In Business Process “Acqui-sition”, knowledge about customers is applied by the organizational role “sales agent”.
CHAPTER 6. B-KIDE TOOL 110
6.4.3 Analysis
The B-KIDE Tool supports the generation of two main, configurable analysis
reports: 1) the Business Process Landscape and 2) the Knowledge Process Land-
scape. Both analysis reports build on the model perspectives which were intro-
duced in section 5.3.1 on page 84.
Figure 6.13: Creating Analysis Reports with the B-KIDE Tool
The B-KIDE report assistant depicted in figure 6.13 assists knowledge infras-
tructure designers in generating analysis reports on top of gathered interview
data. These reports can be filtered according to specific interviews, organiza-
tional roles or specific knowledge activities (step 2 and 3 of the report assistant).
The built-in configurability of B-KIDE Tool reports allows for in depth and de-
tailed investigations of knowledge work in organizations as a basis for knowledge
infrastructure development.
Business Process Landscape
The Business Process Landscape in figure 6.14 depicts knowledge work of business
processes in a way that was introduced in figure 4.3 and thereby represents an
implementation of a Business Process Perspective. The Business Process Perspec-
tive utilizes business processes as the central structuring element. The generation,
storage, transfer and application of knowledge is depicted along the respective
business processes (see section 5.3.1).
In the simple example of figure 6.144, two business processes are depicted.
The visualization is interpreted in the following way: In business process “Acqui-
4This screenshot was graphically revised in order to increase comprehensibility of the con-cepts to be communicated
CHAPTER 6. B-KIDE TOOL 111
Figure 6.14: The B-KIDE Tool Analysis Report “Business Process Landscape”
sition” sales agents need to apply “Knowledge about Potential Customers”. In
the second business process “Market Analysis”, this knowledge about potential
customers is generated by the organizational role “Marketing”. The knowledge
domain is transferred through dedicated “Sales Meetings”, where “Marketing”
communicates “Knowledge about Potential Customers” to “Sales”.
Knowledge Process Landscape
The Knowledge Process Landscape in figure 6.15 depicts knowledge processes in
a way that is illustrated in figure 4.4 and thereby represents an implementation
of a Knowledge Process Perspective. The Knowledge Process Perspective utilizes
knowledge domains as the central structuring element. Business processes that
generate, store, transfer or apply knowledge are depicted along the respective
knowledge domain (see section 5.3.1).
In the example of figure 6.155, the knowledge process resulting from figure
6.14 is introduced. The visualization is interpreted in the following way: The
knowledge domain “Knowledge about Potential Customers” is generated in the
5This screenshot was graphically revised in order to increase comprehensibility of the con-cepts to be communicated
CHAPTER 6. B-KIDE TOOL 112
Figure 6.15: The B-KIDE Tool Analysis Report “Knowledge Process Landscape”
business process “Market Analysis” by the organizational role “Marketing”. The
knowledge domain is transferred via “Sales Meetings” (In the “Market Analysis”
business process) to “Sales”, who need to apply it in their respective business
process “Acquisition”. The knowledge domain is not stored in any way.
6.5 B-KIDE Tool Support for the B-KIDE
Framework Application
The B-KIDE Tool represents an implementation of the B-KIDE Modeling
Structure and thereby reduces complexity of applying the B-KIDE Framework.
This means that the B-KIDE Tool provides support for applying the: 1) the
B-KIDE Modeling Technique and 2) the B-KIDE Method.
Support for the B-KIDE Modeling Technique: The B-KIDE Tool pro-
vides support for various phases of the B-KIDE Modeling Technique (see section
5.3.2). During “Scope Definition”, it provides means to structure and capture
interview context information (as illustrated in figure 6.8). “Pre-Modeling”
is supported by providing means to setup reference models in a structured,
hierarchical way. By providing a set of specific attributes for each reference
element (as depicted in figure 6.12), the descriptive power of reference elements
is further enhanced. During interviews, the B-KIDE Tool provides knowledge
CHAPTER 6. B-KIDE TOOL 113
analysts with an organized, process-oriented procedure, with predefined ques-
tions and a structured concept for answering them (figure 6.11). In doing that,
the B-KIDE Tool ensures that the gathered interview data is organized in a way
that conforms to the B-KIDE Modeling Structure. Validation of the gathered
interview data is supported through a user interface that knowledge analysts
can present to interviewees at the end of interviews. After the execution of
interviews, knowledge analysts can input additional interview information into
the B-KIDE Tool and thereby refining the data gathered during the interview.
Support for the B-KIDE Method: The B-KIDE Method receives mani-
fold support from the application of the B-KIDE Tool in knowledge infrastructure
development projects. First and foremost, the B-KIDE Tool Knowledge Process
Landscape (figure 6.15) represents the most important input for the B-KIDE
Method. By supporting the configurable generation of analysis reports (as de-
picted in figure 6.13), the B-KIDE Tool allows for differentiated assessments of
the gathered interview data. The generated reports aid knowledge infrastructure
designers in understanding knowledge work in a target organization, questioning
support of existing knowledge infrastructures as well as in suggesting new fea-
tures for improved infrastructures. The B-KIDE Tool also allows for selecting
and marking certain (high priority) knowledge domains - an important function
when it comes to the design activity “Knowledge Process Definition”. In this
activity, as-is knowledge processes are assessed and to-be knowledge processes
are defined. Since the B-KIDE Tool generates XML- and vector-based reports
which are processible with modern graphical software applications such as Mi-
crosoft Visio c© [Micc], the identified knowledge processes (generated through the
Knowledge Process Landscape analysis report) themselves can become the basis
for the definition of to-be knowledge processes.
6.6 B-KIDE Tool Implementation
The B-KIDE Tool implementation is based on Microsoft’s .NET Framework c©[Micb] and the programming language VB.NET utilizing an object-oriented ap-
plication and data structure. The .NET Framework, with its main components
depicted in figure 6.16, is considered to be a
CHAPTER 6. B-KIDE TOOL 114
“Set of software technologies for connecting information, people, sys-
tems, and devices” [Micd].
Figure 6.16: Technological Fundament of the B-KIDE Tool: The .NET Frame-
work [Mica]
The .NET Framework is based on a platform independent fundament, a so-
called Common-Language-Runtime (CLR) that is designed to compile .NET-code
just-in-time for targeted platform environments (operating systems). In addition
to that, the .NET Framework provides a Common-Language-Specification (CLS)
that allows for integrating existing, or developing new programming languages on
top of the .NET Framework by implementing appropriate compilers6. Thereby,
programming concepts such as object inheritance or invocation are available
across .NET-based programming languages (providing the concept of “cross-
language interoperability”). To make such sophisticated functionality available,
the .NET framework uses a so-called Intermediate Language (IL) that acts as an
intermediary between .NET-based programming languages (implementing the
CLS) and the CLR. A common base class library together with common services
(such as ADO.NET for data manipulation) and concepts (such as windows
forms) build a comprehensive infrastructure for the development of software
applications. Because of the sophisticated requirements concerning the B-KIDE
6In order to achieve that, accordance with the CLS is necessary
CHAPTER 6. B-KIDE TOOL 115
Tool’s main user interface, the B-KIDE Tool was implemented with VB.NET,
which provides powerful access to .NET’s concept of windows forms.
Figure 6.17: Architectural Sketch of the B-KIDE Tool
Figure 6.17 depicts the B-KIDE Tool’s main application architecture in an il-
lustrative way. The main B-KIDE Tool user interface provides knowledge analysts
with access to interview data across a series of user sessions (interviews). With
.NET’s serialization service System.Runtime.Serialization.Formatters.Binary,
data objects are persisted throughout these sessions in a binary data reposi-
tory. Analysis reports, generated by the B-KIDE Tool, utilize the Scalable Vector
Graphics (SVG) [Gro03] standard developed by the W3C. This standard itself
is based on XML [BPSM+04], a flexible, human- and computer-readable data
format. Therefore, the B-KIDE Tool applies Microsoft’s XML Parser MSXML
4.0 SP2 that supports the generation of XML-based files. Also, the B-KIDE
Tool ensures that the generated XML-based files comply to the SVG standard.
Analysis reports of the B-KIDE Tool are visualized with the help of SVG viewers
CHAPTER 6. B-KIDE TOOL 116
(such as HTML browsers that installed Adobe’s SVG Plugin c© [Ado]). Because
these analysis reports are based on XML and the vector-based graphics format
SVG, generated reports can easily be transformed to other formats with technolo-
gies such as XSLT or can be graphically revised with existing graphical software
applications (such as Microsoft Visio c© [Micc]). More details about the B-KIDE
Tool can be found in appendix D.
Chapter 7
Proof of Concept
What counts as its test? - “But is this an adequate test? And, if so, must it not
be recognizable as such in logic?” - As if giving grounds did not come to an end
sometime. But the end is not an ungrounded presupposition: it is an
ungrounded way of acting.
Appendix Chapter A on page 162
7.1 Introduction
This chapter provides proof that the B-KIDE Framework significantly contributes
to the main challenges addressed by this PhD work. For this purpose, the concept
of case and pilot studies1 was employed to assess the ability of the B-KIDE
Framework to achieve reasonable results within complex, real-world scenarios.
The selection of appropriate studies was driven by the ambition to apply the
B-KIDE Framework in the most heterogeneous environment available in order
to determine the supported degree of generality. Therefore, three studies were
conducted with companies from software, automotive and consulting industry
to demonstrate that the B-KIDE Framework is capable of achieving its design
objective, which is to:
Introduce a framework and an according tool that allows for the de-
velopment of business process-supportive, technological knowledge in-
frastructures for knowledge intensive organizations [page 26].
1also see section B for further details on the selected research approach
117
CHAPTER 7. PROOF OF CONCEPT 118
Case Study 1 Pilot Study 1 Pilot Study 2
Project
Context
Software indus-
try, ISO9001:2000
certified
Automotive indus-
try, formally defined
business processes
Consulting indus-
try, weakly designed
business processes
Project
Goals
Knowledge portal
design
EDM system im-
provement
Intranet improve-
ment
Hypothesis
tested
B-KIDE Framework B-KIDE Framework and B-KIDE Tool
Framework
Applica-
tion
Design Evaluation Design
Project
Results
Design of four
knowledge portals
EDM system
improvement poten-
tials
Design of a KI to
support the acquisi-
tion process
Study
Style
Explorative Justificative Justificative
Primary
Actor
The author A 3rd person A 3rd person
Evaluation
concern-
ing
PhD objectives
Table 7.1: Overview of Conducted Studies
Table 7.1 gives an overview of the main contents of the conducted studies. In
the following sections, three case/pilot studies applying the B-KIDE Framework
from a heterogeneous range of industrial backgrounds are introduced. First and
foremost, the context in which the studies were conducted is described per case.
The goals as well as the specific approaches are explained in order to further
enhance understanding about the main activities executed. Also, the execution
of each step of the B-KIDE Framework is briefly introduced. Subsequently,
the core results of the studies are illustrated to give an idea, how the outputs
of these undertakings were utilized by the industrial study partners to develop
their knowledge infrastructures. Finally, in section 7.6, the accomplishments of
the B-KIDE Framework in the light of the three conducted studies are discussed.
CHAPTER 7. PROOF OF CONCEPT 119
The arrangement of the studies in this chapter indicates the timely sequence of
realization.
7.2 Case Study 1: Software Industry
7.2.1 Context
Case study 1 was performed in cooperation with a software developing company
A with about 200 employees. The case study itself took place in the R&D division
of the company, which is certified according to the process-oriented ISO9001:2000
standard and consists of about 80 employees. About 30 business processes are
modeled to describe the core work of this division and are managed and con-
tinuously improved by a dedicated quality management team. Employees are
integrated well in ongoing, organizational process development efforts. They
therefore share an excellent, common understanding about the core, value gener-
ating activities of their organization and follow the collectively defined processes
tightly. Concerning technological equipment, the company has a technological
KM system with typical KM functionality (as introduced in chapter 1) at its
disposal.
7.2.2 Pursued Goals
In this case study, company A aimed to design and implement a knowledge in-
frastructure, based on technological knowledge portals, for five of its most critical
organizational roles. These knowledge portals were supposed to 1) provide the
targeted roles with information relevant for their respective business processes
and 2) be interlinked with each other, to effectively route information from/to
related knowledge workers. A more implicitly pursued goal was to further define,
refine and establish communication channels for information exchange between
knowledge workers in their respective business processes. Since this implicit goal
evokes not only technological measures, suggestions concerning organizational
improvements (such as business process modifications) were appreciated by com-
pany A as well, but not a strict requirement for this case study.
CHAPTER 7. PROOF OF CONCEPT 120
7.2.3 Approach Taken
In this case study, the principle approach of the B-KIDE Framework was utilized
to address the case study goals. In detail, B-KIDE’s Modeling Technique (as
depicted in figure 7.1) and B-KIDE’s Modeling Structure as well as the B-KIDE
Method were applied2.
Application of the B-KIDE Modeling Technique
Figure 7.1: The Modeling Procedure Applied in Case Study 1
Scope Definition: During the B-KIDE Modeling Technique activity “Scope
Definition”, the investigation area in the target organization was delimited. The
five organizational roles to be supported were defined to consist of: VPE (Vice
President Engineering), CRD (Coordinator), TL (Team Leader), PM (Project
Manager) and MD (Module Developers). For each role, at least two interviewees
were assigned (with the exception of the VPE, see table 7.2). A total of seven
interviewees (some of them bearing more than one role) were interviewed. All
business processes, in which the selected roles were involved, were determined to
be the basis for process-oriented interviews.
Pre-Modeling: Three dimensions of the B-KIDE reference models were
pre-modeled in order to prepare for the interviews. The Business Process
Reference Model was pre-modeled based on an existing Business Process
Landscape as well as the Organizational Roles Reference Model based on an
existing organigram of company A. Pre-modeling of these models was performed
by the knowledge analyst based on provided documentation (the ISO 9001:2000
quality management manual). Also, an initial Knowledge Domain Reference
2At the time of conducting this case study, the B-KIDE Tool was not yet available andtherefore, the modeling and analysis activities were performed semi-automatically by utilizingMicrosoft’s standard software Excel c©.
CHAPTER 7. PROOF OF CONCEPT 121
Role Interviewee
VPE A
CRD A, B
TL C, D
PM D, E
MD F, G
Table 7.2: Scope Definition and Interview Planning in Case Study 1
Model was developed based on the company’s “Vision and Strategy” document.
This reference model was set up by the knowledge analyst and discussed and
further refined with company A’s top management as well as with employees
during the object system modeling activity.
Object System Modeling: Object system modeling took place via seven,
process-oriented interviews with knowledge workers A-G. Each interview took
place in a separate, quite room preventing distractions and disturbances and
lasted around two hours. During the interviews, interviewees had sketches of
all relevant business processes at their disposal. The knowledge analyst had all
pre-modeled reference models available. During the interviews, the knowledge
analyst used the Microsoft Excel c© template depicted in figure E.1 on page
181 to structure gathered interview data. The questions illustrated in this
figure are based on request/respond patterns of concrete, past executions of
business processes. At the end of the interviews, no validation of interview
data took place since the gathered interview data was not available in a format
that was easy to relate to interview data previously gathered in other interviews3.
Model System Refinement: After conducting the interviews, the knowl-
edge analyst refined the interview excel sheets with information he could not
document during interview time because of time restrictions. Based on these
excel sheets, the Knowledge Process Landscape (containing more than 40 knowl-
edge processes) depicted in appendix E in figure E.2 on page 182 was manually
created in accordance with the B-KIDE Modeling Structure by the knowledge
3This fact, among others, raised the need for developing the B-KIDE Tool.
CHAPTER 7. PROOF OF CONCEPT 122
analyst.
Application of the B-KIDE Method
Figure 7.2: The Design Method Applied in Case Study 1
The B-KIDE Method (consisting of the design process depicted in figure
7.2 and the KI template architecture) was applied during this case study in
order to design knowledge portals that support company A’s employees in their
respective business processes.
Knowledge Process Definition: In this first design activity, the created
Knowledge Process Landscape was filtered according to the related organiza-
tional roles. For each role, a set of relevant knowledge processes that need to be
supported by the anticipated knowledge portals was defined. Table 7.3 gives an
overview of agreed upon and selected knowledge processes that were determined
to be supported by the anticipated, technological knowledge infrastructure.
VPE CRD TL PM MD
KP Selected for Support [#] 16 9 15 10 0
Percentage [%] 59 50 68 53 0
KP not Selected for Support [#] 11 9 7 9 32
Percentage [%] 41 50 32 47 100
Involved in KPs - Total [#] 27 18 22 19 32
Percentage Total [%] 100 100 100 100 100
Table 7.3: KI Focus: Definition of Knowledge Processes to be Supported
At this point, technological support for one organizational role (MD) was
discarded since this role had highly role-independent, task and project-specific
CHAPTER 7. PROOF OF CONCEPT 123
knowledge needs that could not be covered to the necessary extent with the
available infrastructure4.
Figure 7.3: A High Level Conceptualization of the Anticipated Support for
Knowledge Flows in Case Study 1
Figure 7.3 illustrates the design scope of the anticipated knowledge infras-
tructure. Four organizational roles are supported in their respective knowledge
processes while support for one role (MD) was discarded. The scope demarca-
tion represents the fundament for defining future knowledge processes since it
determines the primary actors in the anticipated knowledge infrastructure.
In figure 7.4, the in- and output of the process of defining a specific knowledge
process to be supported in the anticipated knowledge infrastructure is depicted.
While in the identified knowledge process A, the project manager transfers
knowledge about the project progress through private e-mails to other employees
(where each of them archives them separately), the defined knowledge process B
demands a new Storage Object 1.3 (an e-mail archive accessible for all concerned
roles) that centrally stores and archives e-mails. The storage process itself is
in the responsibility of the knowledge infrastructure. This reduces the burden
of organizing knowledge for each organizational role involved. In addition to
that, knowledge process B demands that the transfer of these e-mails needs to
be integrated in the respective business processes in the future (Transfer Object
4especially the lack of available metadata assigned to documents, necessary for enhancedpersonalization features, led to this decision
CHAPTER 7. PROOF OF CONCEPT 124
1.4 e-mail alias).
Figure 7.4: An Example of Knowledge Process Definition in Case Study 1
Preliminary KI Design: The knowledge infrastructure template architec-
ture (section 5.9) provided guidance concerning the main design results of this
activity. Based on the set of related knowledge processes per organizational role,
UI mockups of supportive knowledge portals were developed. This was achieved
by analyzing and investigating the related knowledge processes and by designing
support for them within the anticipated knowledge portals. Thereby, the
application of the B-KIDE Framework led to a design of knowledge portals that
supports knowledge processes across a set of organizational roles and business
processes. Together with corresponding organizational roles, the UI mockups
were subsequently discussed and further refined pursuing a participatory design
approach. Figure E.3 on page 184 depicts such a UI mockup that represents
a fragment of the design of the anticipated solution on the access layer of the
KI template architecture. Based on the design of this layer, the corresponding
underlying KI template architecture layers were designed.
KI Design Evaluation: In this activity, the preliminary KI design was under
evaluation concerning its respective knowledge processes and certain fit criteria
CHAPTER 7. PROOF OF CONCEPT 125
(also see figure E.3 on page 184). With respect to the goals of this case study,
the selected fit criteria were determined to be:
• All defined storage objects (SO) shall appropriately be supported and in-
cluded in the anticipated knowledge infrastructure.
• All defined roles shall be able to provide knowledge they generate within the
defined knowledge processes to the anticipated knowledge infrastructure in
a fast and easily comprehensible way.
• The transfer of knowledge shall be supported by the anticipated knowl-
edge infrastructure to the extent described within the defined knowledge
processes.
• All defined knowledge activities shall be integrated into the organization’s
business processes.
In cases of lacking appropriate support, the design was revised by the KI
designer, who thereby looped through the preceding activity. After checking each
fit criterion for inclusion in the KI design, the preliminary design was approved
and handed over to a team of implementers.
7.2.4 Achieved Results
Figure 7.5 illustratively depicts the main results of case study 1. For each identi-
fied organizational role, a supportive knowledge portal was developed. The knowl-
edge portals represent role specific perspectives on the organization’s knowledge
infrastructure. The portals are interconnected to each other through the knowl-
edge infrastructure. Beneath that, they are connected to other (legacy) systems
and applications that play important roles in the targeted business processes.
Beneath the (visible) results of figure 7.5, a set of concepts (including an access-,
structure- and content concept) derived from the KI template architecture was
developed. The application of the B-KIDE Design Process together with the B-
KIDE KI Template Architecture and the developed concepts assured support for
knowledge processes within the final design of the solution.
CHAPTER 7. PROOF OF CONCEPT 126
Figure 7.5: Case Study 1 Results: Four Role Oriented Knowledge Portals
7.3 Pilot Study 1: Automotive Industry
7.3.1 Context
Pilot study 1 was conducted in cooperation with a car-manufacturing company
B with about 10.000 employees. The pilot study was conducted with a specific
group of the engineering department comprising 150 employees. Before this pilot
study took place, the department’s core business process product development
and its six main sub-processes were modeled in detail in cooperation with related
engineers using the available modeling technique and tool ARIS [Sch00]. Because
of the tight cooperation during modeling, engineers share a broad common un-
derstanding about the department’s main processes and activities. Concerning
technological equipment, engineers in their respective business processes are sup-
ported through a variety of technological, custom-tailored systems. Among them,
the employed engineering data management (EDM) system is the most important
technological instrument in this area (as perceived by pilot study representatives).
CHAPTER 7. PROOF OF CONCEPT 127
7.3.2 Pursued Goals
The role DetK (Detail Constructor) is considered to be the most critical role
by pilot study representatives. His main activities are focused on the business
process product development in company B. With this pilot study, company B
aimed to analyze the role of the EDM system for the organizational role DetK
in its respective business processes and to generate improvement suggestions for
this system from a knowledge perspective. This overall goal included: 1) techno-
logically supporting knowledge interactions between the business process product
development and related business processes by leveraging the existing EDM sys-
tem and 2) improving the EDM system to better suit the knowledge needs of
DetK.
7.3.3 Approach Taken
In this pilot study, the principle approach of the B-KIDE Framework was uti-
lized to address the study goals. In detail, B-KIDE’s Modeling Technique (as
depicted in figure 7.6) together with the B-KIDE Tool and the B-KIDE Method
were applied. Instead of designing a new technological infrastructure in this pi-
lot, an existing infrastructure was evaluated and improvement suggestions were
generated.
Application of the B-KIDE Modeling Technique
Figure 7.6: The Modeling Procedure Applied in Pilot Study 1
Scope Definition: In this activity, the scope of investigations was delimited.
During the course of this pilot study, the knowledge analyst together with pilot
study representatives determined two organizational roles for structured inter-
views: DetK and KstrP (Construction Inspector). The reason for that was to
CHAPTER 7. PROOF OF CONCEPT 128
involve the views of the targeted role DetK as well as the views of an external
role (KstrP) who was considered to be important. As depicted in table 7.4, three
DetK were available for interviews, while one person was interviewed as a KstrP,
summing up to a total of four interviews. All interviews were based on the in-
terviewees’ involvement in the engineering’s department main business process
product development.
Role Interviewee
DetK A, B, C
KstrP D
Table 7.4: Scope Definition and Interview Planning in Pilot Study 1
Pre-Modeling: In this pilot, pre-modeling of five dimensions of the
B-KIDE reference models took place. While the Business Process Reference
Model was created based on the developed ARIS business process models, the
Organizational Roles Model was created based on an available organigram. The
Knowledge Domain-, Storage Object-, and Transfer Object Reference Models
together were pre-modeled by interviewing a domain expert in the field of
engineering who is working in the engineering department.
Object System Modeling: Object system modeling took place via four
process-oriented and tool-supported interviews with knowledge workers A-D.
All of the interviews were conducted in large office spaces with multiple other
employees present and working. Each interview lasted between 45 and 80
minutes. No business process diagrams were available during interviews since all
interviewees participated in the business process modeling effort that preceded
this pilot. The analyst applied the B-KIDE Tool to raise the necessary interview
questions and to document/structure corresponding answers. Validation of
interview data took place by confronting the interviewees with their answers
given at the end of the interviews.
Model System Refinement: The knowledge analyst refined the gathered
interview data after each interview as well as after all interviews took place with
information he did not document during interview time because of a) time restric-
tions or b) misunderstandings with interviewees. Figure E.4 on page 185 depicts
CHAPTER 7. PROOF OF CONCEPT 129
the resulting Knowledge Process Landscape containing 25 identified knowledge
processes. This landscape was auto-generated by the B-KIDE Tool after all in-
terviews were completed and laid a sound fundament for the evaluation of the
targeted knowledge infrastructure.
Application of the B-KIDE Method
Figure 7.7: The Evaluation Method Applied in Pilot Study 1
The B-KIDE Method (consisting of the design process and the KI template
architecture) was applied during this case study in order to generate improve-
ment suggestions for a knowledge infrastructure that better supports company
B’s organizational role DetK in its respective knowledge intensive (sub) business
processes. The dotted lines in figure 7.7 represent activities that were not carried
out during this pilot.
Knowledge Process Definition: In this activity, ideal knowledge processes
were defined. By defining ideal knowledge processes, the existing knowledge in-
frastructure could be evaluated concerning the generation of improvement po-
tentials. Improvement potentials here were considered to be the delta between
existing support for identified and possible support for ideal knowledge processes
in a knowledge infrastructure. Based on a subjective assessment of represen-
tatives of the pilot company B, 12 knowledge processes were determined to be
revised and to be supported by an improved knowledge infrastructure. Table 7.5
depicts knowledge processes per role that were selected for support.
Figure 7.8 illustrates the target roles and interactions of this pilot study ef-
forts. While the main actor supported is DetK, the role KstrP and a number of
other relevant roles are also within the focus of the improvement efforts.
CHAPTER 7. PROOF OF CONCEPT 130
DetK KstrP
KP Selected for Support [#] 12 4
Percentage [%] 48 33
KP not Selected for Support [#] 13 8
Percentage [%] 52 67
Involved in KPs - Total [#] 25 12
Percentage Total [%] 100 100
Table 7.5: KI Focus: Definition of Knowledge Processes to be Supported
Figure 7.8: A High Level Conceptualization of the Anticipated Support for
Knowledge Flows in Pilot Study 1
In figure 7.9, the in- and outputs of an exemplary knowledge process definition
are depicted. Knowledge process A, which was identified through the performed
B-KIDE analysis, describes how knowledge about change requests concerning
construction drawings was handled in company B. While the KstrP generated
this knowledge in the respective construction drawing sub process, he transferred
it to the DetK through informal, bilateral meetings and documented it via per-
sonal notes. The knowledge then was applied in the business process 3D-Modeling
by the DetK and in two further business processes by the KstrP. The supposed,
idealized knowledge process B now introduces a new Storage Object 1.2 (a meet-
ing minutes document) as well as a new Transfer Object 1.4 (a document folder)
that 1) provides a dedicated container for this knowledge domain and 2) ensures
the transfer of this knowledge domain to the corresponding knowledge application
roles. A knowledge infrastructure that implements the two newly introduced ob-
CHAPTER 7. PROOF OF CONCEPT 131
jects would represent an improved knowledge infrastructure because it supports
the execution of the idealized, defined knowledge process B.
Figure 7.9: An Example of Knowledge Process Definition in Pilot Study 1
KI Design Evaluation: The existing knowledge infrastructure design was
evaluated with respect to 1) the defined, idealized knowledge processes and 2)
the developed fit criteria of this pilot study. With respect to the goals of this
pilot study, the fit criteria employed were the following:
• All defined storage objects shall be supported within the anticipated knowl-
edge infrastructure.
• The transfer of knowledge shall be supported to the extent described within
the defined knowledge processes by the anticipated knowledge infrastruc-
ture.
• All selected roles shall have access to the knowledge they need to apply
within the defined knowledge processes.
A lack of support for one of the defined, idealized knowledge processes and
corresponding fit criteria in the existing knowledge infrastructure led to the
generation of improvement potentials for the improved knowledge infrastructure.
Preliminary KI Design: When applying the B-KIDE Method in an evalua-
tion mode, the improvement potentials identified in the previous activity now can
be translated to an improved knowledge infrastructure design. During this pilot
CHAPTER 7. PROOF OF CONCEPT 132
study, this translation process was not performed because of restrictive economic
framing conditions. However, the improvement potentials shed light on critical
requirements for the future development of the EDM system from a knowledge
perspective.
7.3.4 Achieved Results
The application of the B-KIDE Framework together with the B-KIDE Tool al-
lowed for detailed investigations of the existing knowledge infrastructure (the
EDM system) of company B. Not only could the role of company B’s EDM sys-
tem within the product development business process be assessed - by defining
ideal knowledge processes, substantial improvement potentials for the existing
knowledge infrastructure could be generated. By addressing the identified im-
provement potentials, company B is able to employ “Arrow 3” KM functionality
to better support their knowledge-intensive business processes and knowledge
workers. In doing that, a clear (knowledge) vision of how the existing EDM
system should evolve in the future was developed.
7.4 Pilot Study 2: Consulting Industry
7.4.1 Context
Pilot study 2 was performed in cooperation with a consulting company C, provid-
ing consulting services in the domains of organizational development, information
technology and engineering, with about 30 employees. Company C has a con-
ceptualization of its main business processes available (in the sense of a Business
Process Landscape). However, these business processes are not documented or
modeled in an extensive, detailed way. The Business Process Landscape con-
sists of six main business processes that depict the most critical processes of
company C. Employees share a moderate common understanding about the ex-
ecution of these processes. Concerning technological equipment, company C has
a well structured intranet with functionalities such as document management or
HTML provision available.
CHAPTER 7. PROOF OF CONCEPT 133
7.4.2 Pursued Goals
This pilot study aimed to lay out the design of a knowledge infrastructure that
supports the organizational role business manager (BM) in executing its corre-
sponding acquisition business process including e.g. support for the creation of
project proposals and/or promotions. In detail, the knowledge infrastructure was
supposed to: 1) collect the necessary information from project staff (MA), project
managers (PL), project office (PO) and the business manager himself and 2) pro-
vide this kind of information to the business manager in an appropriate way.
Since the current situation involves an organizational role performing the kind
of work that the anticipated knowledge infrastructure aims to implement, appro-
priate business process modifications were necessary and among the goals of this
pilot study as well.
7.4.3 Approach Taken
This pilot study employed the B-KIDE Framework to achieve its goals. In detail,
the B-KIDE Modeling Technique (as depicted in figure 7.10) and the B-KIDE
Tool together with the B-KIDE Method were applied.
Application of the B-KIDE Modeling Technique
Figure 7.10: The Modeling Procedure Applied in Pilot Study 2
Scope Definition: The scope of investigations was delimited in this activity.
The project team agreed upon interviewing the four organizational roles BM, PL,
MA and PO in order to gain a comprehensive overview of interactions between
the BM and supporting roles. Because of resource restrictions, only one employee
per role was interviewed. In total, four interviews were performed. The business
processes, in which the selected roles were involved, acted as a basis for tool-
supported, process-oriented interviews.
CHAPTER 7. PROOF OF CONCEPT 134
Role Interviewee
BM A
PL B
MA C
PO D
Table 7.6: Scope Definition and Interview Planning in Pilot Study 2
Pre-Modeling: Five dimensions of the B-KIDE reference models were
pre-modeled in order to prepare the execution of interviews. The Business
Process Reference Model was pre-modeled based on the conceptualization of
company C’s main business processes. The Organizational Roles Reference
Model was modeled based on the existing organigram which was documented
in company C’s organizational guidelines. A Storage Object Reference Model
was prepared based on investigations performed on the company’s intranet.
A preliminary Transfer Object Reference Model was developed based on
discussions with employees of the organization. An initial Knowledge Domain
Reference Model was established considering the most important knowledge
domains that were addressed from management during preparatory meet-
ings. All of these preliminary reference models were modeled by applying the
B-KIDE Tool reference modeling features (as depicted in figure 6.10 on page 108).
Object System Modeling: Object system modeling took place via
four process-oriented and tool-supported interviews with knowledge workers
A-D. All of the interviews were conducted in a separate, quite room lasting
between one and two hours5. During the interviews, interviewees had the main
conceptualization of company C’s business processes at their disposal. All
pre-modeled reference models were available in the B-KIDE Tool. The analyst
applied the B-KIDE Tool to raise necessary questions and document/structure
corresponding answers. Validation of interview data took place by the knowledge
analyst right during interview time (double checking answers given and checking
them with interview data already available from other interviews).
5with the exception of one interview only lasting 30 minutes because of time restrictionsimposed by the interviewee
CHAPTER 7. PROOF OF CONCEPT 135
Model System Refinement: The knowledge analyst refined gathered in-
terview data after each interview mainly by enriching existing reference elements
with metadata. This information was provided during the interviews, but could
not be modeled at this time because of time restrictions. Figure E.6 on page
187 depicts the resulting Knowledge Process Landscape containing 28 identified
knowledge processes. This landscape was auto-generated by the B-KIDE Tool
after all interviews were completed and laid a sound fundament for the design of
the anticipated knowledge infrastructure.
Application of the B-KIDE Method
Figure 7.11: The Design Method Applied in Pilot Study 2
The B-KIDE Method (as depicted in figure 7.11) was applied in this pilot
study to lay out the design of a knowledge infrastructure that supports the
company’s business managers in their corresponding acquisition process.
Knowledge Process Definition: In this activity, from the 28 identified
knowledge processes, eight were selected for support in the anticipated techno-
logical knowledge infrastructure. Thereby, 20 knowledge processes could not be
supported with a technological approach because of various reasons including
the nature of knowledge investigated (tacit knowledge), a lack of available tech-
nological features, a limited willingness and/or ability to document necessary
knowledge and other factors. The 8 selected knowledge processes were defined
based on the elicited knowledge processes and on how they should be executed
in the future with a supportive knowledge infrastructure. During definition, two
new knowledge processes emerged and were included in the final knowledge pro-
cess definition totaling 10 defined knowledge processes. In parallel, a preliminary
KI design (based on the B-KIDE KI Template Architecture) was created that
CHAPTER 7. PROOF OF CONCEPT 136
aimed to suffice the requirements of the defined knowledge processes.
BM PL PO MA
KP Selected for Support [#] 8 6 - -
Percentage [%] 33 24 - -
KP not Selected for Support [#] 16 19 22 22
Percentage [%] 67 76 100 100
Involved in KPs - Total [#] 24 25 22 22
Percentage Total [%] 100 100 100 100
Table 7.7: KI Focus: Definition of Knowledge Processes to be Supported
Figure 7.12 depicts the scope of the anticipated knowledge infrastructure de-
sign in an illustrative way. The main actor supported is the organizational role
BM in its corresponding acquisition business process. Beneath that, support for
the role PL is considered as well.
Figure 7.12: A High Level Conceptualization of the Anticipated Support for
Knowledge Flows in Pilot Study 2
Figure 7.13 exemplarily depicts the in- and outputs of the process of defin-
ing knowledge processes that are to be supported by the anticipated knowledge
infrastructure. Based on identified knowledge processes, and taking the focus of
the anticipated knowledge infrastructure into account (as defined in figure 7.12),
to-be knowledge processes were defined. While the identified knowledge process
A in figure 7.13 depicts that two organizational roles are concerned with the gen-
eration of the knowledge at hand, the defined knowledge process B only considers
one of them for support due to a limited KI project focus imposed by the pilot
company. Information previously stored in a so-called project index in the future
CHAPTER 7. PROOF OF CONCEPT 137
is stored within the anticipated knowledge infrastructure that needs to imple-
ment a Storage Object 2.4 (e.g. a set of data forms or documents) capturing
this knowledge. The software documentation (illustrated in knowledge process
A) remains with the respective tool currently employed by the pilot company. In
the case of knowledge process B, the technological knowledge infrastructure itself
does not support the transfer of this knowledge (also see the definition of transfer
on page 82) - this was an issue with all defined knowledge processes of this pilot
study and was due to a low prioritization of this problem by pilot company C.
However, the knowledge process definitions together with the defined fit criteria
highlighted the lack of support for the in-time transfer of knowledge and thus
raised the need for addressing this problem on an organizational level.
Finally, knowledge process B demands that the anticipated knowledge infrastruc-
ture needs to provide appropriate access to this knowledge domain for business
managers in their corresponding acquisition process. The organizational roles
PL and MA (identified in knowledge process A) again do not receive support in
applying this knowledge domain by the knowledge infrastructure due to imposed
focus limitations.
Figure 7.13: An Example of Knowledge Process Definition in Pilot Study 2
Preliminary KI Design: Based on the defined knowledge processes and
an instantiation of the B-KIDE KI Template Architecture, the KI designer
laid out the design of a business process-supportive knowledge infrastructure
with the requirements of the defined knowledge processes in mind. An access,
structure and content concept were developed for an anticipated software
tool that captures, stores and provides relevant knowledge. While the access
CHAPTER 7. PROOF OF CONCEPT 138
concept provides concrete ideas about how the related roles access knowledge,
the structure and content concept focused on the internal representation of
knowledge within the anticipated knowledge infrastructure.
KI Design Evaluation: The developed KI design was evaluated according
to the defined knowledge processes and corresponding fit criteria. With respect to
the goals of this pilot study, the agreed upon fit criteria comprised the following
checks:
• All defined storage objects shall be supported within the anticipated knowl-
edge infrastructure.
• All defined roles shall be able to provide knowledge they generate within the
defined knowledge processes to the anticipated knowledge infrastructure.
• All defined roles shall have access to the knowledge they need to apply
within the defined knowledge processes.
• All defined knowledge activities shall be integrated into the organization’s
business processes.
A lack of support for one of the knowledge processes and corresponding fit
criteria caused an iteration through the preliminary KI design activity.
7.4.4 Achieved Results
The application of the B-KIDE Framework together with the B-KIDE Tool led
to a knowledge infrastructure design that supports business managers in their
corresponding acquisition business process and at the same time supports knowl-
edge interactions between the acquisition business process and related business
processes. Also, the defined knowledge processes illustratively reveal that us-
age of the anticipated knowledge infrastructure mainly benefits the targeted role
business manager. Other integrated roles mainly fulfill the role of knowledge
providers (as depicted in figure 7.12). While this might pose no problem for the
design and implementation of a technological knowledge infrastructure, it might
invoke acceptance problems among participants. Since extending the scope of the
anticipated knowledge infrastructure (for e.g. supporting multiple organizational
CHAPTER 7. PROOF OF CONCEPT 139
roles) represented no option for company C during the course of this pilot study,
the issue was bypassed and addressed on an organizational level by modifying
the respective business processes with additional tasks for project managers.
7.5 Lessons Learned
7.5.1 B-KIDE Framework
The application of the B-KIDE Framework in the three conducted studies gen-
erated valuable feedback for framework improvements. One issue that emerged
from applying the B-KIDE Framework to real-world scenarios was the introduc-
tion and labelling of knowledge domains during modeling. Knowledge analysts
struggled with heterogeneous vocabulary and term boundaries in organizations.
To overcome this issue, two major measures were taken: 1) the element knowledge
domain was extended with the attribute buzzwords to allow for the assignment
of multiple labels to a single knowledge domain. 2) Pre-modeling of knowledge
domains was introduced to the pre-modeling activity of the B-KIDE Modeling
Technique. In this activity, domain experts are interviewed for the development
of an initial prototype of a Knowledge Domain Reference Model in order to ease
the process of interviewing. Experiences made in one pilot study indicate that
with such a procedure, approximately 50% of all identified knowledge domains
can be pre-modeled. Another issue that emerged in one pilot study was the
definition of fit criteria during B-KIDE Method application. In this case, the
pilot study partner company struggled to define fit criteria on an operative level.
This issue was addressed by providing exemplary fit criteria that aid the fit cri-
teria definition process. Also, the development of so-called knowledge problem
patterns may aid identifying weak spots of existing knowledge processes. Such
weak spots could generate valuable knowledge about necessary knowledge infras-
tructure development directions and corresponding fit criteria. Beneath that,
the availability of quality business process models at the beginning of knowledge
infrastructure development projects appeared to positively influence the quality
of the resulting knowledge processes. Those studies, where quality business pro-
cess models were available seemed to generate “fitter” knowledge process models.
Also, the involvement of the interviewed persons in knowledge process analy-
CHAPTER 7. PROOF OF CONCEPT 140
sis activities had positive affects on the final knowledge infrastructure designs
too. Lastly, B-KIDE modeling of knowledge work based on business processes
that were tightly aligned to an application domain6 seemed to generate the most
valuable knowledge process model perspectives for the development of effective
knowledge infrastructures. It can be hypothesized that business process models
that are tightly aligned to an application domain describe the work of inter-
viewed knowledge workers more accurately and therefore lead to more concrete
and relevant knowledge process models.
7.5.2 B-KIDE Tool
The utilization of the B-KIDE Tool in knowledge infrastructure development
projects allowed knowledge analysts who were mainly unfamiliar with the B-
KIDE Framework to easily conduct process-oriented interviews that conform to
the B-KIDE Modeling Structure. Experiences in two studies showed that the
application of the B-KIDE Tool significantly lowered the work burden for knowl-
edge analysts. However, users needed some amount of training to be able to
appropriately apply the B-KIDE Tool. Therefore, interview guidelines for knowl-
edge analysts were provided (see chapter C) and with each knowledge analyst,
a set of supervised test interviews (two to three) was conducted in order to en-
hance the performance of subsequent interviews. In addition, knowledge analysts
agreed that comprehensive pre-modeling eases the actual process of interviewing.
Also, in all studies knowledge analysts considered it helpful to be able to refine
the gathered interview data right after interview situations. By considering the
aforementioned aspects, the B-KIDE Tool was capable to be applied in real-time
by knowledge analysts in the conducted study interviews. New tool functional-
ity that was suggested by knowledge analysts includes a software feature that
dynamically fades in the current status of knowledge processes. Another im-
provement suggestion concerned dynamic checks for already existing buzzwords
to synchronize the meaning of these terms. The underlying hypothesis of both
feature suggestions is that an implementation would support the challenging task
of matching knowledge domains.
6such as software development business processes vs. e.g. generic project managementprocesses
CHAPTER 7. PROOF OF CONCEPT 141
7.6 Assessment
In this section, the B-KIDE Framework is assessed in the light of the three con-
ducted studies. In order to do so, the degree of achieving the defined objectives
of this PhD work is presented and critically discussed. The following goals were
defined to be the goals of the B-KIDE Framework (also see page 27):
1. The concept leads to knowledge infrastructure designs that im-
prove environments of knowledge workers for their respective
knowledge intensive business processes
All conducted studies led to designs of knowledge infrastructures that
were oriented towards improving technological environments for knowledge
workers in their knowledge intensive business processes. This was mainly
achieved by the Framework’s capability to 1) identify existing and 2) define
improved knowledge processes based on knowledge workers’ business pro-
cesses and 3) ensure support for knowledge processes in improved knowledge
infrastructures through the concept of fit criteria. Pilot study 1 (EDM sys-
tem improvement) effectively demonstrated how improvement potentials for
knowledge infrastructures can be identified based on applying the B-KIDE
Framework.
2. The concept leads to knowledge infrastructure designs that en-
able role oriented access to knowledge for knowledge workers in
organizations
The B-KIDE model architecture allows for performing role-oriented anal-
yses (see e.g. table E.1 on page 183) on top of the identified knowledge
processes. Thereby, and by applying the normative B-KIDE Method, role-
oriented access to knowledge can be designed. Especially the empirical
results of case study 1 (knowledge portals) and pilot study 2 (a knowledge
infrastructure supporting the acquisition process) provided proof that role
oriented access can well be achieved in knowledge infrastructure develop-
ment projects by applying the B-KIDE Framework.
3. The concept leads to knowledge infrastructure designs that enable
autonomous routing of knowledge from/to corresponding knowl-
edge workers in their business processes
CHAPTER 7. PROOF OF CONCEPT 142
Among the main characteristics of knowledge processes is the capability to
comprise descriptions of knowledge flows (see page 70). By defining fit cri-
teria that focus on the implementation of support for knowledge flows and
-transfer in technological knowledge infrastructures, the aspect of routing
knowledge is addressed. Thereby, not only knowledge interactions within
and across business processes are supported, but also concrete instructions
on how to apply “Arrow 3” KM functionality in business contexts are pro-
vided. Convincing empirical evidence for these statements can be found in
e.g. case study 1, where knowledge is autonomously routed between a set
of knowledge workers by means of networked knowledge portals.
4. The concept leads to knowledge infrastructure designs that en-
force a more standardized way of executing knowledge work in
organizations
The B-KIDE Framework applied in the conducted studies was useful to
contribute to increased standardization of knowledge work in areas selected
by the industrial study partners. By defining future organizational knowl-
edge processes, and designing support for them in technological knowledge
infrastructures, a more standardized way of executing knowledge work was
enforced. Pilot study 2 (supporting an acquisition process) illustrates such
an effort in an excellent way. Here, knowledge flows between the BM and the
PM were defined and integrated in the design of the anticipated knowledge
infrastructure, leading to defined communication channels between these
two roles. However, other issues such as user acceptance, implementation
quality or usability aspects of technological knowledge infrastructures also
play a vital role in efforts aiming to standardize knowledge work. There-
fore, these aspects need to be considered to a reasonable extent in projects
that pursue such goals.
5. The concept leads to increased transparency of knowledge work
in organizations and its implications for technological knowledge
infrastructures
In all studies conducted, knowledge processes represented the major impera-
tive for designing technological support. Knowledge processes illustratively
CHAPTER 7. PROOF OF CONCEPT 143
visualized knowledge work7 in the three study organizations in great detail
and, in combination with existing concepts such as [Rol03], laid the basis
for informed decisions concerning the design of knowledge infrastructures.
In addition to these accomplishments, a set of further challenges could be
addressed to some extent:
• The concept can be reasonably applied in real-world knowledge
infrastructure development projects
While the developed B-KIDE Framework alone is not applicable in a rea-
sonable amount of time, the complementary B-KIDE Tool allows for the
effective application of the B-KIDE Framework as demonstrated in two in-
dustrial pilot studies. The B-KIDE Tool achieves that by implementing
the B-KIDE Modeling Structure. Thereby, it eases the application and re-
duces complexity of the B-KIDE Framework for knowledge analysts and
knowledge infrastructure designers.
• The concept can be applied to organizations across industries
The selection of case and pilot studies was made with this goal in mind. The
B-KIDE Framework was applied in three studies that spanned software-,
automotive- and consulting industry. During study execution, no indica-
tors where found that would point to a limited applicability of the B-KIDE
Framework to certain organizations or industries. However, future research
might focus on testing the B-KIDE Framework in other application do-
mains.
• The concept can be applied at various abstraction levels of
knowledge
Although the accomplishment of this statement strongly depends on the
definition and demarcation of the term abstraction levels chosen, the B-
KIDE Framework supports the development of reference models (such as
the Knowledge Domain-, Business Process- or Transfer Object Reference
Model) on arbitrary detail levels through hierarchical concepts. However,
7The descriptive power of knowledge processes was introduced in detail in section 4.3.3 onpage 70
CHAPTER 7. PROOF OF CONCEPT 144
all three studies focused on areas where the knowledge domains investi-
gated where considered to be on a very concrete level, within clearly de-
fined system boundaries. The application of the B-KIDE Framework on
higher abstraction levels such as in intra-organizational settings is among
the aspects that need to be elaborated on in future research efforts (also
see section 9.5).
Chapter 8
Future Work
Es verdient festgehalten zu werden, daß man bezweifeln kann, ohne zu
kritisieren, und kritisieren, ohne zu bezweifeln.
Appendix Chapter A on page 162
The introduced B-KIDE Framework comprises a set of powerful concepts
that successfully addresses the objectives of this PhD thesis. Beneath that, some
new and challenging questions emerged from the introduced concepts that might
stimulate further research. Therefore, this chapter aims to present issues that
need to be resolved in future research efforts:
8.1 On System Design and Implementation
The B-KIDE Framework successfully aids in prescribing what needs to be part
of knowledge infrastructure designs, but not how these requirements are pro-
vided (section 5.4.1). Often, organizational knowledge infrastructures are based
on available software (so-called COTS products) such as [Hyp, Liv, Lot]. There-
fore, in order to be implementable, the developed, vendor-independent knowledge
infrastructure designs need to be mapped on concrete, vendor-specific system de-
signs. Although existing concepts (as exemplarily introduced in section 5.4.2)
can aid this process, a formal methodology for mapping knowledge infrastructure
designs on concrete system designs is supposed to bear the potential of signifi-
cantly increasing accuracy of the developed knowledge infrastructure designs and
reducing work burden for system designers.
145
CHAPTER 8. FUTURE WORK 146
8.2 On Knowledge Process Optimization
The current version of the B-KIDE Framework successfully addresses the initial,
static identification of knowledge processes and the development of supportive
technological knowledge infrastructures. The B-KIDE Framework achieves that
through focused, temporally-restricted interventions in organizations. Thereby,
continuous improvement and self-optimization1 of knowledge processes are not
covered by the introduced concepts. Therefore, future extensions to the B-KIDE
Framework are necessary in order to deal with changing environments such as
1) the introduction of new organizational roles or 2) the modification of existing
business processes. In such situations, the current version of the B-KIDE Frame-
work continuously needs to be re-applied which may not be practical in real-world
scenarios2 and does not contribute to the requirement of e.g. the KPQM for self-
optimization depicted in table 8.1. The emergence of these issues calls for future
research work in this domain and raises the following questions that need to be
addressed: How can dynamic aspects of business- and knowledge processes be
integrated in the B-KIDE Framework? How can support for knowledge processes
be designed in a sustainable and self-optimizing way? What kinds of knowledge
process performance measures are suitable for evaluation? To what extent can the
KM role knowledge process owner [PP02] contribute to the identified challenges?
8.3 On the Problem of Decoupled Knowledge
Processes
Where knowledge generation, storage, transfer and application is performed by a
set of different individuals, severe problems for organizations may arise: In such
situations, e.g. employees who need to apply knowledge might have no context
knowledge about the required knowledge domain such as by whom and in which
context it was originally generated. This can result in both, either dogmatic
1Attributed to the highest maturity level 5 (Optimizing) of the Knowledge Process QualityModel (KPQM) [PP02, OP03]
2However, the B-KIDE Framework comprehensively aids in anticipating the (knowledge)effects of modifications to a single business process within complex business process networks
CHAPTER 8. FUTURE WORK 147
Maturity Stage Description
1 - Initial The quality of knowledge processes is not
planned and changes randomly. This state can
be best described as one of chaotic processes.
2 - Aware Awareness for knowledge processes has been
gained. First structures are implemented to en-
sure a higher process quality.
3 - Established This stage focuses on the systematic structure
and definition of knowledge processes. Processes
are tailored to react to special requirements.
4 - Quantitatively
Managed
To enhance the systematic process management,
measures of performance are used to plan and
track processes.
5 - Optimizing The focus of this stage is on establishing struc-
tures for continuous improvement and self-
optimization.
Table 8.1: Maturity Stages of the KPQM [PP02]
belief in or total disbelief of available knowledge. Also, this situation might
lead to knowledge generators (employees) having no vision of what knowledge
appliers (other employees) really require. Here, the generation and application
of knowledge is structurally and cognitively decoupled3. Therefore, the author
suggests introducing the term “Decoupled Knowledge Process” in order to
describe the outlined problem.
Decoupled Knowledge Processes can be tackled on two different levels: Either
1) awareness for knowledge processes can be raised among knowledge knowledge
workers4 or 2) responsible knowledge workers for knowledge generation and ap-
plication can be brought together (not necessarily physically), thereby redesign-
3Reasons for such situations may lie in technological systems that implement and encapsulatethe transfer and routing of knowledge or dedicated organizational roles (such as knowledgebrokers) who explicitly focus on knowledge transfer and thereby potentially decouple knowledgegenerators and appliers.
4through e.g. intelligent process visualizations such as [BM04]
CHAPTER 8. FUTURE WORK 148
ing and streamlining corresponding knowledge processes. Both measures aim
to close the cognitive gap between knowledge generators and appliers and avoid
the problem of decoupled processes. However, further research work is neces-
sary to gain a deeper understanding about factors promoting the appearance of
decoupled knowledge processes and to develop effective countermeasures. The B-
KIDE Framework provides a sound fundament for future work since it identifies
situations, where the problem of decoupled knowledge processes might occur.
8.4 On Oblivion of Knowledge
Beneath the generation, storage, transfer and application of knowledge, the selec-
tive oblivion respectively deletion of knowledge in organizational memories (on
individual, organizational and/or technological levels) represents a pressing chal-
lenge for organizations [Leh00, page 283]. For example in technological contexts,
the controlled deletion of useless knowledge bears tremendous administration-,
maintenance- and thus, cost-saving potentials for organizations. Therefore, im-
portant decisions concerning the deletion vs. preservation of knowledge artifacts
have to be made. The B-KIDE Framework does not deal with these aspects
because of the chosen focus of this PhD work. However, in the future of an in-
creasingly knowledge-based economy, controlled knowledge oblivion/deletion is
considered to pose an even more severe and complex problem for organizations.
Therefore, the challenge at hand strongly calls for future research work in this
area integrating knowledge oblivion with the concepts of the B-KIDE Framework
answering questions such as: Under which conditions can knowledge artifacts be
deleted? Can the concept of knowledge life cycles contribute to the problem at
hand? How can the risks involved in both knowledge oblivion and preservation
be assessed?
8.5 On Role-Orientation vs. Personalization
Personalization is a concept concerned with the adaption of knowledge infras-
tructures to specific user needs. Current research considers personalization of a
system to be
The adaptation of 1) its system features, 2) the content managed by
CHAPTER 8. FUTURE WORK 149
the system and 3) its structural components for organizing content
according to the internal model of reality, states and activities system
users have. [Toc02]
This definition powerfully strengthens the role of individual users (vs. or-
ganizational roles) in knowledge infrastructures. In the context of the B-KIDE
Framework, the future need for extending the introduced, role-oriented concepts
towards the consideration of individual persons emerges. Questions concerning
this challenge include: To which degree can role-oriented and person-oriented
approaches be combined?5 How can business process aspects be considered in
current personalization models? Can the B-KIDE Framework also contribute to
the concepts of dynamic personalization [Kan03]?
8.6 On Interactions between Knowledge Infras-
tructures and Business Processes
Not only do business processes pose implications for knowledge infrastructures,
but the design and application of knowledge infrastructures pose implications on
business processes as well. For example, the introduction of a knowledge man-
agement system may cause severe adaptations to an organization’s business pro-
cesses (supposing a “technological imperative” [Leh00, page 48/49]). This issue
may cause conflicts between organizational units and interests such as knowledge
management and process management. Questions that can be raised based on
this observation include: To which degree should knowledge infrastructures influ-
ence business processes and vice versa? How can common quality attributes be
defined for such interweaved environments? What kinds of trade-offs are involved
in business process oriented knowledge infrastructure design decisions?
8.7 B-KIDE Framework Evolution Scenarios
Obviously, the B-KIDE Framework itself can be improved from a knowledge
perspective. By understanding the B-KIDE Framework as a network of
5First work concerning this question already exists [GPSW03]. However, the applicabilityof such concepts, especially in large-scale settings, is an open research challenge.
CHAPTER 8. FUTURE WORK 150
processes6 and knowledge workers7, the B-KIDE Framework can be applied
to itself. Thereby, knowledge weak spots may be analyzed and a supportive
knowledge infrastructure for knowledge workers may be designed. Although this
undertaking is not within the scope of this PhD thesis, it represents a more than
interesting approach to the further development of the B-KIDE Framework.
Another B-KIDE Framework evolution scenario includes the development of
knowledge problem patterns that indicate problems in organizational knowledge
work based on certain knowledge process configurations. An example for
such a pattern might be a lack of appropriate transfer between knowledge
generators and appliers (illustrated in knowledge process visualizations by a
lack of responsible transfer objects). The existence and development of such
knowledge problem patterns would substantially ease the application of the
B-KIDE Framework and the process of developing business process-supportive
knowledge infrastructures.
A third possible evolution scenario might be the adaption of the B-KIDE Frame-
work to specific industry sectors, providing tailored blue-print reference models
and knowledge infrastructure design solutions that aid the efficient realization
of knowledge infrastructure development projects. Questions concerning such
an approach include: To which degree can reference models be anticipated in
organizations of the same sector? Do the developed knowledge infrastructures
share common characteristics that can be implemented in the future without
performing detailed organization-specific analysis? And if so, can these solutions
be described as patterns (in the sense of [Ale79]) also and be integrated into the
B-KIDE Framework?
8.8 B-KIDE Tool Evolution
The B-KIDE Tool proved itself successful in reducing the burden of collecting
and structuring interview data for knowledge analysts. The developed reports
provided comprehensive support for analyzing the defined model perspectives.
However, the B-KIDE Tool lacks support for the flexible generation of additional
6The B-KIDE Method and the B-KIDE Modeling Technique represent such processes7such as the B-KIDE knowledge analyst or the B-KIDE knowledge infrastructure designer
CHAPTER 8. FUTURE WORK 151
model perspectives (beyond the two predefined analysis reports) that might be
of use in further applications (also see chapter 9). The development of e.g. a B-
KIDE Tool Application Programming Interface (API) can address this problem
in the future. Also, the B-KIDE Tool only indirectly supports KI designers
in the actual activity of defining knowledge processes through a dedicated user
interface. Future tool extensions might focus on a knowledge process definition
interface that benefits KI designers to a greater extent. The B-KIDE Tool in its
current version is limited to hierarchical structures of reference models. Future
tool versions may focus on support for more sophisticated structures such as
topic maps [Top01] to provide more comprehensive support for the modeling of
relationships between reference model elements.
Chapter 9
Future Applications
Merely by taking thought a man cannot add an iota to his knowledge of the
world of facts.
Appendix Chapter A on page 162
Figure 9.1: Applying B-KIDE in Diverse Domains by Developing Additional B-
KIDE Methods
The B-KIDE Framework together with the B-KIDE Tool increases trans-
parency of knowledge work in organizations. While this PhD work demonstrates
the reasonability of the developed models of organizational knowledge work in
the context of the development of technological knowledge infrastructures, the
B-KIDE Framework is open for addressing a multitude of other challenges in
diverse contexts by developing complementary B-KIDE Methods on the basis of
152
CHAPTER 9. FUTURE APPLICATIONS 153
the B-KIDE Modeling Architecture (as depicted in figure 9.1). Thereby, not only
technological, but organizational or human aspects of knowledge management
may be addressed as well. This chapter gives an overview of a series of potential
application domains in research as well as in industry that appear to be capable
of successfully building on the concepts of this PhD work.
9.1 Identification of Knowledge Communities
Communities of Practice (CoP) represent a concept that focuses on learning in
groups of people through apprenticeship or so-called legitimate peripheral par-
ticipation (LPP) [Lin98]. Members of a CoP typically share common interests,
processes, practices and/or terminology. A more recent and process-centered
term used to describe a specific type of a community is knowledge community
[Rem02]. Knowledge communities are considered to be “communities that deal
with knowledge domains which are processed within or across various business
processes”. In this context, the B-KIDE Framework can aid identifying relevant
knowledge communities by identifying knowledge processes that 1) span multiple
business processes and 2) point to a set of organizational roles who all deal with
similar knowledge domains. Based on this identification, community nurturers
[Pre00] may focus on certain knowledge communities that are considered to be
important and may design instruments for supporting the development of them.
With the B-KIDE Framework, not only knowledge communities, but the role
different organizational roles play in these communities may be identified (as de-
picted in figure 9.2) answering questions such as: Who is mainly active or passive
in a given community? Who are the knowledge providers and consumers? Who
are knowledge hubs or brokers? Who are boundary spanners? Future research on
communities of practice can strongly benefit from considering existing, business-
relevant knowledge relations (as depicted in e.g. knowledge processes) between
actors.
CHAPTER 9. FUTURE APPLICATIONS 154
Figure 9.2: Identification of Knowledge Communities with the B-KIDE Frame-
work
9.2 Identification of Knowledge Risks
For knowledge-intensive organizations, a lack of knowledge management may
pose risks for achieving organizational success. Inaccurately managed knowledge
processes represent such risks. Since the B-KIDE Framework identifies existing
knowledge processes, it bears the potential of being an instrument for the identifi-
cation and reduction of relevant knowledge risks. Based on knowledge processes,
risk analysts may either reduce the probability of risk occurrence (through e.g.
ensuring the execution of specific knowledge activities by modifying business
processes or the establishment of knowledge process owners [PP02]) or aim to re-
duce the consequences evoked by these risks (through e.g. risk hedging). Future
approaches addressing the management of risks from a knowledge perspective
are strongly advised to take such knowledge process investigations into account,
since knowledge processes describe business-relevant situations in which business-
critical knowledge risks may emerge.
9.3 Raising KM Maturity Levels of Organiza-
tions
The identification, support, management and improvement of knowledge pro-
cesses is of especial relevance in the context of knowledge management maturity
models. Existing maturity models1 build on an assessment of the quality of
1such as the KPQM of [PP02, OP03] depicted in table 8.1 on page 148
CHAPTER 9. FUTURE APPLICATIONS 155
organizational knowledge processes in order to assign KM maturity levels for or-
ganizations. A necessary prerequisite for such an assessment is the identification
of knowledge processes. The B-KIDE Framework allows for the identification of
knowledge processes based on business processes and represents them in a way
that allows for evaluating the degree of organizational management concerning
them. By applying the B-KIDE Framework in concrete knowledge infrastructure
development projects, an organization is enabled to raise their maturity level
from ’1 - initial’ or ’2 - aware’ up to the level of ’3 - established’ [PP02]2. There-
fore, the B-KIDE Framework may play a key role in 1) the knowledge-oriented
development of organizations and 2) future research concerning the development
of knowledge-process oriented KM maturity models.
9.4 Controlling of Knowledge-Based Strategies
Organizations that consider knowledge as a key resource often are concerned
with the development, implementation, controlling, evaluation and improvement
of corporate knowledge strategies and corresponding operationalized knowledge
goals. The B-KIDE Framework allows for evaluating the degree to which such
organizational knowledge goals are considered in organizational structures. The
B-KIDE Framework identifies 1) if these knowledge goals are pursued in the
organization’s business processes and 2) if they find consideration in the organi-
zation’s knowledge infrastructure. Based on such evaluations, organizations may
adjust their KM interventions to better achieve their defined knowledge goals.
9.5 Enabling Intra-Organizational KM
Business processes are typically not limited to the boundaries of single organi-
zations, but span different organizations e.g. along a supply chain or within
distributed value generating networks. In such settings, the appropriate man-
agement of knowledge is even more crucial and also harder to achieve because
of e.g. competitive situations, geographically dispersed actors, varying organiza-
tional cultures, -languages or -vocabulary. Here, initiatives (such as cluster, B2B3
2also see table 8.1 on page 1483B2B...Business-to-Business
CHAPTER 9. FUTURE APPLICATIONS 156
or marketplace initiatives), might benefit from having knowledge about critical,
cross-organizational knowledge processes that are in need for structured support
or management.
9.6 Ontology Engineering
An ontology is a logical theory accounting for the intended meaning of a for-
mal vocabulary, i.e. its ontological commitment to a particular conceptualization
of the world [Gua98]. Deeply rooted in philosophy, ontologies are applied in a
broad range of disciplines such as in artificial intelligence, knowledge- or language
engineering. Business process oriented knowledge management as a scientific do-
main partly integrates the concept of ontologies into existing approaches for the
implementation of technological knowledge infrastructures [KHS03]. In organi-
zational settings, heterogeneous vocabulary used by employees may prevent the
successful development and/or application of ontologies. Because the B-KIDE
Framework is able to identify the usage of heterogeneous vocabulary in orga-
nizations (through structured interviews), it may aid efforts that focus on the
engineering of ontologies in industrial environments (such as [TPSS04]).
Chapter 10
Conclusions
Um zu reflectieren, muß der Geist in seiner fortschreitenden Thatigkeit einen
Augenblick still stehn, das eben Vorgestellte in eine Einheit fassen, und auf
diese Weise, als Gegenstand, sich selbst entgegenstellen.
Appendix Chapter A on page 162
The B-KIDE Framework addresses the two research challenges (page 22) of this
PhD thesis, which are: 1) to support the execution of knowledge intensive and
interconnected business processes and 2) to support the reasonable application
of typical, technological KM functionality in given business contexts. “Business
Process Oriented Knowledge Management” (bpoKM, page 47), relatively a young
research domain emerged from the more established scientific domains of business
process- and knowledge management, aims to provide answers for the identified
research challenges. From a comprehensive review of current bpoKM approaches,
the following main conclusions can be drawn: 1) most existing bpoKM approaches
are based on performing analysis of business processes from a knowledge perspec-
tive (page 48) 2) some approaches already have successfully designed technological
support for specific business processes in specific application domains (“Business
Process Support” on page 62) and 3) yet no approaches tackle the two research
challenges of this PhD work in an integrative way (page 25).
10.1 Assessment
This thesis gives an answer to the introduced research challenge 1: The B-KIDE
Framework successfully identified relevant knowledge interactions in complex
157
CHAPTER 10. CONCLUSIONS 158
business process networks in three studies conducted with industrial partners.
By applying the B-KIDE Method for the development of technological knowl-
edge infrastructures, support for such knowledge interactions could be ensured
and achieved. Research challenge 2 was also successfully addressed: The B-KIDE
Framework provides comprehensive insights on how to employ “Arrow 3” KM
functionality in given business contexts in a way that suits both organizations
and employees. Two1 of the three studies performed actually integrated “Arrow
3” KM functionality in their respective knowledge infrastructure designs for the
support of knowledge intensive business processes.
10.2 Scientific Contributions
This PhD thesis has successfully addressed its research objectives. The following
main scientific contributions, already briefly mentioned in chapter 1, could be
achieved:
• This work provides a generic framework for the development of business
process-supportive, technological knowledge infrastructures. The B-KIDE
Framework leads to knowledge infrastructure designs that ensure a certain
degree of support for knowledge intensive business processes and corre-
sponding knowledge workers in a traceable and repeatable way. Thereby, it
ensures quality and reduces arbitrariness of the developed knowledge infras-
tructure designs across various application domains. The B-KIDE Frame-
work therefore represents a universal theory for knowledge infrastructure
development projects in organizations that is easily applicable and testable
by the principle of instantiation.
• Although the identification of knowledge processes has received attention
from current research, this work introduces a novel and suitable concept
for the identification and visualization of complex knowledge processes and
interactions that span a multitude of business processes and related knowl-
edge workers. The introduced concept of knowledge processes allows for
1These two were the studies where the B-KIDE Method was applied in a design (vs. evalu-ation) mode: Case study 1 (on page 120) and pilot study 2 (on page 133)
CHAPTER 10. CONCLUSIONS 159
the identification, visualization and modeling of greatly distributed knowl-
edge work in organizations. Thereby, it enables detailed investigations of
organizational knowledge work by taking the complex nature of knowledge
into account.
• This work uniquely integrates organizational and technological dimensions
of knowledge infrastructure development efforts. By introducing an inte-
grative concept, which connects knowledge requirements of business pro-
cesses to technological KM functionality, the B-KIDE Framework signifi-
cantly contributes to current research focussing on closing the gap between
business process management- and information systems design approaches
[Gia99, WC03].
• This work introduces a novel model architecture and a supportive software
tool that enable the development of inter-subjective models of organiza-
tional knowledge work. Analyzing complex, combined social and techno-
logical systems such as organizations is not typically accomplished through
direct interventions in the system, but indirectly through appropriate mod-
els of the system in question [FS01]. The B-KIDE Framework introduces a
model architecture for modeling organizational knowledge work that spec-
ifies model elements, relationships, rules and semantics and thus enables
modelers to check structural and behavioral consistency as well as com-
pleteness of their models. The innovative B-KIDE Tool represents an im-
plementation of the B-KIDE Model Architecture that eases the application
of the introduced concepts. Applying the B-KIDE Framework together
with the accompanying B-KIDE Tool reduces complexity found in knowl-
edge intensive organizations (with respect to a modeling goal) and leads
to the development of inter-subjective models of organizational knowledge
work.
• This work answers the question of how certain maturity levels of existing
KM maturity models (such as [PP02, OP03]) can be achieved. The appli-
cation of the B-KIDE Framework in knowledge infrastructure development
projects enables organizations to raise their knowledge management ma-
turity level and to significantly increase their ability to appropriately deal
with the critical resource knowledge.
CHAPTER 10. CONCLUSIONS 160
10.3 Final Statement
This work proposes that the introduced B-KIDE Framework provides a solution
to 1) supporting knowledge interactions in complex business process networks
and 2) the reasonable application of typical KM functionality in given business
contexts. The B-KIDE Framework represents a universally applicable theory
comprising the B-KIDE Model Architecture for modeling organizational knowl-
edge work, the B-KIDE Method for designing support for knowledge intensive
business processes and the B-KIDE Context that describes in which situations
the framework can successfully be employed. In addition, the B-KIDE Tool,
implementing the B-KIDE Model Architecture, provides an instrument that
reduces complexity and increases accuracy of applying the B-KIDE Framework.
With knowledge gaining more and more importance in modern organizations,
the challenges addressed in this PhD thesis are considered to be of highest rel-
evance for future research. This PhD work lays a sound fundament for the de-
velopment of knowledge infrastructures in knowledge intensive organizations. It
is hoped that the research performed here will 1) stimulate and trigger future
research on knowledge infrastructure development and the concept of knowledge
processes and 2) benefit organizations to mature their ability to deal with knowl-
edge in an effective and efficient way.
Appendix A
Quotes
Although providing the source of quotes gives important context for understand-
ing the intended meaning of the creator in a much better way, it also narrows
the reader’s mind. At the beginning of each chapter of this thesis, a quote is
introduced without giving the appropriate context right away to stimulate the
mind of the interested reader and, with respect to knowledge management,
to provide examples that powerfully illustrate the important role of context
information. For the sake of completeness, all quotes with their respective
sources are listed in this chapter.
Chapter 1
Es ist so schwer, den Anfang zu finden. Oder besser: Es ist schwer, am Anfang
anzufangen. Und nicht zu versuchen, weiter zuruckzugehen.
Ludwig Wittgenstein, On Certainty, §471
Chapter 2
Objectivity is a subject’s delusion that observing can be done without him.
Heinz von Forster, Einfuhrung in den Konstruktivismus, Page 31
Chapter 3
Ich mochte nur darauf hinweisen, daß es eine Zeit gab, in der man die
Ahnlichkeit der Empfindungen zur Basis der Kategorisierung von Pflanze und
Tier gemacht hat. Man denke [...] an die fruhen Taxonomien des Ulisse
Aldrovandi aus dem 16. Jahrhundert, der die scheußlichen Tiere (die Spinnen,
161
APPENDIX A. QUOTES 162
Molche und Schlagen) und die Schonheiten (die Leoparden, die Adler usw.) zu
eigenen Gruppen [von Lebewesen] zusammenfasste.
Heinz von Foerster, Wahrheit ist die Erfindung eines Lugners, Page 22/23
Chapter 4
Nicht das Sammeln und Speichern von Wissen, sondern die Nutzung des
Wissens in den Prozessen bestimmt den Wert von Wissen.
V. Bach, H. Osterle and P. Vogler. Business Knowledge Management in der
Praxis, Page 119
Chapter 5
Problems cannot be solved at the same level of awareness that created them.
Attributed to Albert Einstein (1879-1955)
Chapter 6
Consistency is the last refuge of the unimaginative.
Attributed to Oscar Wilde (1854-1900)
Chapter 7
What counts as its test? - “But is this an adequate test? And, if so, must it not
be recognizable as such in logic?” - As if giving grounds did not come to an end
sometime. But the end is not an ungrounded presupposition: it is an
ungrounded way of acting.
Ludwig Wittgenstein, On Certainty, §110
Chapter 8
Es verdient festgehalten zu werden, daß man bezweifeln kann, ohne zu
kritisieren, und kritisieren, ohne zu bezweifeln.
Sir K.R. Popper, Objektive Erkenntnis, Page 160 citing Poincare in
Wissenschaft und Hypothese.
Chapter 9
Merely by taking thought a man cannot add an iota to his knowledge of the
world of facts.
Sir K.R. Popper, The Logic of Scientific Discovery, Page 75
APPENDIX A. QUOTES 163
Chapter 10
Um zu reflectieren, muß der Geist in seiner fortschreitenden Thatigkeit einen
Augenblick still stehn, das eben Vorgestellte in eine Einheit fassen, und auf
diese Weise, als Gegenstand, sich selbst entgegenstellen.
Wilhelm von Humboldt, cited in Heinz von Forster et al, Einfuhrung in den
Konstruktivismus, Page 32
Appendix B
Research Approach
This PhD work aims to design and construct a framework for the development
of business process-supportive knowledge infrastructures1. In contrast to natural
sciences, the object of research here is a complex artifact (that is the framework)
designed and constructed by mankind (by the researcher vs. e.g. phenomena
observable in nature). The design, construction and evaluation of such artifacts
are inherent parts of a series of scientific domains such as method engineering
[Tol98], human-computer interfaces or algorithmics. A research approach that
focuses on these aspects of conducting research is design research:
“Design research involves the analysis of the use and performance
of designed artifacts to understand, explain and very frequently to
improve on the behavior of aspects of the artifact. [VK04]”
Therefore, the methodological research approach chosen to serve as a funda-
ment for this PhD work is design research. However, other research approaches
(such as case study research [Mac97] or action research [Koc97]) are utilized in
clearly defined areas of application within the overall design research approach.
Figure B.1 depicts the main process steps of design research along with expected
outputs and knowledge interactions between these steps. Also, complementary
research approaches utilized in this PhD work to achieve specific steps are illus-
trated. While figure B.1 visualizes the way research was performed in this PhD
1It is important to point out the two different usages of the term design here: The firstusage refers to designing a theoretical construct (a theory) about the process of conceptualizingbusiness process-supportive knowledge infrastructures as the main result of this PhD work.The second usage refers to the actual process itself.
164
APPENDIX B. RESEARCH APPROACH 165
project, the document at hand contains the final results of these efforts. In the
following sections, the chosen PhD research approach with its corresponding pro-
cess steps is introduced in greater detail (based on the approach introduced by
[VK04]).
Figure B.1: The Design Research Approach (Based on [VK04])
Awareness of Problem
The first step of design research deals with gaining a deeper understanding about
the problem domain. Desk research, the analysis of existing approaches and
related scientific domains based on available industrial and academic literature,
represents a sound instrument for successfully accomplishing this step. In this
PhD work, especially work from the scientific domains introduced in section 2.6
and chapter 2 and 3 provided valuable inputs for conceptualizing the problem
domain. The output of this step was a research proposal sketching up the main
challenges of this PhD work.
Suggestion
This step, immediately following the previous step, is concerned with developing
tentative designs. In the context of this PhD work, this was accomplished by
developing a tentative framework. In order to improve this tentative framework
an explorative case study was conducted. Case study research is especially em-
ployed in situations, where a contemporary phenomenon within its real-world
APPENDIX B. RESEARCH APPROACH 166
context is investigated and the boundaries between phenomenon and context are
not clearly evident [Mye04]. The conducted case study aimed to 1) improve the
quality of the tentative framework 2) achieve a more precise definition of the
research question and 3) identify new problems (since often relevant problems
arise when practitioners encounter new situations for which no guidelines have
been developed yet) [Mac97]. Following a case study research approach generated
valuable knowledge for the aforementioned aims.
Development
This step involves the development of artifacts based on experiences made in
previous steps. Within this PhD work, the core inputs were: 1) a profound
conceptualization of the problem domain 2) the tentative framework as well as 3)
insights gained from the conducted case study. Two artifacts, a framework (the
B-KIDE Framework, chapter 5) together with a software tool (the B-KIDE Tool,
chapter 6), were developed and represent the main output of this step.
Proof of Concept
In this step, the developed artifacts are evaluated according to the defined cri-
teria made explicit in the created proposal (for these criteria see the objectives
defined in section 1.2.1). Since in this PhD work the developed artifact repre-
sents a framework and an accompanying tool for the development of business
process-supportive knowledge infrastructures, concrete knowledge infrastructure
development projects with client organizations are necessary for proper evalua-
tion. To acknowledge this fact, the concept of action research was utilized. Action
research here is regarded to pursue a dual goal [Koc97]: 1) Improving the organi-
zation participating in the research through so-called positive interventions (pilot
studies) and 2) rigorously generating valid and consistent knowledge with respect
to a defined research question. Two justificative pilot studies were conducted that
both applied (through instantiation and utilization) the artifacts developed (see
chapter 7). The output of this step is an assessment of the suitability of the
developed artifacts with respect to the defined objectives.
APPENDIX B. RESEARCH APPROACH 167
Conclusion
Finally, the results of the proof of concept are interpreted in the light of the
tackled problem domain and conclusions for the improvement of the central
concepts of this work are drawn. Experiences are reflected and integrated in a
revised version following an iterative approach.
[VK04] summarize the process of design research in the following, illustrative
way:
The design researcher creates a reality through constructive inter-
vention [Development], then reflectively becomes a positivist observer
[Evaluation], recording the behavior of the system and comparing it
to the predictions (theory) set out during the [...] [Suggestion] phase
[VK04].
Appendix C
Supporting Resources
This chapter contains supporting resources for knowledge analysts.
C.1 Interview Guidelines
Interview guidelines provide support and checklists for the preparation and exe-
cution of interviews within the B-KIDE Framework.
C.1.1 B-KIDE Tool Preparation
1. Preparation of a list of all participating interviewees (B-KIDE Tool: Menu
- Project - Interview Setup - Interviewee Setup)
2. Preparation of a list of all participating analysts (B-KIDE Tool: Menu -
Project - Interview Setup - Analysts Setup)
3. Preparation of an organizational roles reference model (B-KIDE Tool:
Menu - Project - Reference Model Setup)
4. Preparation of a set of interviews (B-KIDE Tool: Menu - Project - Interview
Setup - Interview Setup)
5. Preparation of storage object and transfer object types (B-KIDE Tool:
Menu - Project - Advanced Setup - Generic Elements Setup)
6. Preparation of knowledge domain types (B-KIDE Tool: Menu - Project -
Advanced Setup - Knowledge Domain Type Setup)
168
APPENDIX C. SUPPORTING RESOURCES 169
7. Preparation of storage access types (B-KIDE Tool: Menu - Project - Ad-
vanced Setup - Storage Object Access Type Setup)
8. Preparation of a business process reference model (B-KIDE Tool: Menu -
Project - Reference Model Setup)
9. Preparation of business process - organizational roles assignment (B-KIDE
Tool: Menu - Project - Reference Model Setup)
C.1.2 Preparation for KI Analysts
• Preparation of all necessary documents (see section C.1.4)
• Establishment of an overview and an understanding about the targeted
business processes and organizational roles
• Investigation of the target area’s business strategy from a knowledge per-
spective for the development of an initial structure of the knowledge domain
reference model
C.1.3 Preparation for Interviewees
Interviewees can be asked to prepare themselves for the interviews by providing
them with the list of business processes that is relevant for them and asking
them to think about, what information they require and what information others
require from them in each of the listed business processes. By using this set of
answers as a starting point in corresponding interviews, the quality of gathered
interview data may be increased.
C.1.4 Documents necessary for Analysts
• Business Process Landscape including the targeted business process area
• Business Process Diagrams (Overview Flowcharts) for each business process
involved in the targeted interview
• Detailed Process Management Manual including each business process in-
volved in the targeted interview
APPENDIX C. SUPPORTING RESOURCES 170
• Organigram including the hierarchy of roles in the targeted organization
• Organizational Roles Assignment including all targeted organizational roles
and assigned employees
C.1.5 Documents necessary for Interviewees
• Business Process Landscape including the targeted business process area
• Business Process Diagrams (Overview Flowcharts) for each business process
involved in the targeted interview
C.1.6 Interview Setting
• The interview should be executed in a quiet environment, to avoid the
occurrence of any interference.
• The interview should not take longer than 2 hours, since after this time
experience showed that concentration of both analysts and interviewees
rapidly decreases.
• The analyst exclusively should use the computer during interviews. Only
for validation reasons at the end of each interview, the analyst should share
the B-KIDE Tool screen with the interviewee.
• Analysts and interviewee should have the documents, prepared in sections
C.1.4 and C.1.5, available to be able to look necessary things up during
interview time.
• Access to the interviewee’s work environment (e.g. intranet, etc.) at a
second computer would be beneficial to look up details that may emerge
during interviews.
C.1.7 Interview Execution
From an analyst perspective, the interview consists of the following main activi-
ties:
APPENDIX C. SUPPORTING RESOURCES 171
Introduction
• The analyst introduces himself to the interviewee.
• The analyst introduces the background, objectives and benefits of the B-
KIDE project.
• The analyst introduces the main process of interviewing.
• The analyst introduces the business processes for this interview. He checks
if they are known to the interviewee.
• The analyst checks for any questions up to now.
Main Interview Process
• For each relevant business process, the analyst determines which informa-
tion is needed by the interviewee, and which information others need from
the interviewee.
• For each piece of information, the analyst asks questions concerning aspects
of storing and transferring this information.
• In case of missing reference elements (such as knowledge domains, storage
objects, etc.) the analyst creates these objects together with the intervie-
wee. The analyst cross-checks the attributes of reference elements with the
interviewee each time he references them.
• The analyst validates the gathered interview data by presenting the B-KIDE
Tool interview screen with all relevant data to the interviewee.
Interview Close Out
• Interviews represent an opportunity to collect business process improvement
suggestions. Therefore, the analyst can take the opportunity and ask the
interviewee for potential improvements.
• The analyst introduces subsequent actions and steps in the respective
project.
APPENDIX C. SUPPORTING RESOURCES 172
• The analyst asks for any remaining questions.
• The analyst leaves his business card so that the interviewee can contact
him after the interview.
C.1.8 Interview Hints
Sticking to the following rules aids analysts in eliciting information from inter-
viewees in a way that suits the B-KIDE Framework.
Rule 1 “Utilize past typical and concrete business process executions
of the interviewee for setting the interview questions in an appropriate
context.”
Rule 2 “While performing interviews, focus on what information the
interviewee processes (needs, transfers, makes available, etc.) in his
corresponding business processes, not on what the interviewee does
within them.”
Rule 3 “In case an interviewee has more than one role, confront the
interviewee with the appropriate role description for this interview
at the beginning of the interview. Frequently check his answers for
potential misconceptions during the interview to ensure that the in-
terviewee gives his answers from the appropriate perspective (role).”
Rule 4 “Before creating a new reference element, check existing refer-
ence elements together with the interviewee to avoid duplicates. For
knowledge domain objects, utilize the buzzwords metadata to deal
with heterogeneous vocabulary.”
Rule 5 “Extend current reference elements and models only in a way
that preserves and refines previously gathered interview data.”
APPENDIX C. SUPPORTING RESOURCES 173
C.2 Interview Plan
The Interview Plan Template depicted in figure C.1 aids KI analysts in focus
setting and in planning their interview activities.
Figure C.1: The Interview Plan Template
Appendix D
B-KIDE Tool Details
This chapter introduces selected, detailed screenshots of the B-KIDE Tool.
Figure D.1: Property-Form for the Reference Element “Knowledge Domain”
174
APPENDIX D. B-KIDE TOOL DETAILS 175
Figure D.2: Property-Form for the Reference Element “Business Process”
Figure D.3: Property-Form for the Reference Element “Organizational Role”
Figure D.4: Property-Form for “Knowledge Work”
APPENDIX D. B-KIDE TOOL DETAILS 176
Figure D.5: Property-Form for the Reference Element “Storage Object”
Figure D.6: Property-Form for the Reference Element “Transfer Object”
APPENDIX D. B-KIDE TOOL DETAILS 177
Figure D.7: Setup Form for the Definition of Storage and Transfer Object Types
Figure D.8: Knowledge Process Landscape Generation with the B-KIDE Tool
(1)
APPENDIX D. B-KIDE TOOL DETAILS 178
Figure D.9: Knowledge Process Landscape Generation with the B-KIDE Tool
(2)
Figure D.10: Knowledge Process Landscape Generation with the B-KIDE Tool
(3)
APPENDIX D. B-KIDE TOOL DETAILS 179
Figure D.11: Knowledge Process Landscape Generation with the B-KIDE Tool
(4)
Appendix E
Empirical Study Data
E.1 Case Study 1 - Software Industry
Figure E.1: Microsoft Excel c© Interview Template Applied in Case Study 1
Figure E.1 depicts the Microsoft Excel c© interview template that was applied
to document gathered interview data in case study 1. Experiences made in case
study 1 showed that the complexity of the B-KIDE Modeling Structure calls
for a more sophisticated tool that supports knowledge analysts in the process of
interviewing more comprehensively. This issue laid the basis for the development
of the B-KIDE Tool.
180
APPENDIX E. EMPIRICAL STUDY DATA 181
Figure E.2: Manually created Landscape of Identified Knowledge Processes
Figure E.2 depicts the manually created landscape of identified knowledge
processes in case study 1. This landscape visualized knowledge work through the
concept of knowledge processes at case study company A.
APPENDIX E. EMPIRICAL STUDY DATA 182
Team Leader (TL) Knowledge Profile
KP Nr. Involved in
Specific Knowledge Activity
1.1.6 T, A
1.2.2 A
1.2.3 A
1.3.1 A
1.4.1 G
1.4.2 T
5.1.1 G, A
5.1.2 G
5.1.3 A
5.1.4 A
5.1.5 G
5.1.7 G,A
5.1.8 A
5.2.1 G,A
5.2.2 T
5.2.3 T, A
5.2.5 G, A
5.2.6 A
Table E.1: Example of a Role-Oriented Knowledge Profile Based on Identified
Knowledge Processes (KP)
Table E.1 comprises the results of a role-oriented filtering of the created
Knowledge Process Landscape of figure E.2. For each knowledge process, the
involvement of the organizational role Team Leader (TL) in the specific knowl-
edge activities generation (G), storage (S), transfer (T) and application (A) is
depicted. This filtering laid the basis for the creation of a knowledge portal
mockup (the Access Layer of the B-KIDE Knowledge Infrastructure Template
Architecture) for the role TL.
APPENDIX E. EMPIRICAL STUDY DATA 183
Figure E.3: UI Mockup of a Knowledge Portal Fragment for Role TL and Cor-
responding Knowledge Processes (KP)
Figure E.3 depicts the knowledge portal mockup that was created based on
the identified and filtered knowledge processes. Annotations flag corresponding
knowledge processes.
APPENDIX E. EMPIRICAL STUDY DATA 184
E.2 Pilot Study 1 - Automobile Industry
Figure E.4: B-KIDE-generated Knowledge Process Landscape
Figure E.4 depicts the results of investigations performed at pilot study com-
pany B. In total, 25 knowledge processes could be identified.
APPENDIX E. EMPIRICAL STUDY DATA 185
Figure E.5: Landscape of Knowledge Processes Selected for Improvement
Figure E.5 depicts the input for the B-KIDE Method “Knowledge Process
Definition” activity. In this activity, 12 knowledge processes were defined and
thereby laid the basis for the identification of improvement potentials.
APPENDIX E. EMPIRICAL STUDY DATA 186
E.3 Pilot Study 2 - Consulting Industry
Figure E.6: B-KIDE-generated Knowledge Process Landscape
Figure E.6 depicts the results of the investigations performed at pilot study
company C. In total, 28 knowledge processes could be identified.
APPENDIX E. EMPIRICAL STUDY DATA 187
Figure E.7: Landscape of Knowledge Processes Selected and Defined for Support
Figure E.7 depicts the results of the B-KIDE Method “Knowledge Process
Definition” activity. In this activity, 10 knowledge processes were defined and
laid the basis for the design of a supportive knowledge infrastructure.
APPENDIX E. EMPIRICAL STUDY DATA 188
Business Manager (BM) Knowledge Profile
KP Nr. Involved in
Specific Knowledge Activity
1 G, S, A
3 A
5 G, S, A
13.4 A
13.5 G, S, A
14 / 14.1 S, A
14.2 A
16.4 A
X1 Open
X2 A
Table E.2: Example of a Role-Oriented Knowledge Profile Based on Selected
Knowledge Processes (KP)
Table E.2 comprises the results of a role-oriented filtering of the created
Knowledge Process Landscape of figure E.7. For each knowledge process, the
involvement of the organizational role Business Manager (BM) in the specific
knowledge activities generation (G), storage (S), transfer (T) and application
(A) is depicted. This filtering laid the basis for the creation of the B-KIDE
Knowledge Infrastructure Template Architecture Access Layer for the role BM.
Bibliography
[Ado] Adobe. SVG Plugin. http://www.adobe.com/svg, last accessed on
June 14th, 2004.
[AHMM02] A. Abecker, K. Hinkelmann, H. Maus, and H.J. Muller.
Geschaftsprozess-orientiertes Wissensmanagement. Springer, Berlin,
2002.
[Ale79] C. Alexander. The Timeless Way of Building. Oxford Press, 1979.
[All98] T. Allweyer. Modellbasiertes Wissensmanagement. IM Information
Management, 13(1):37–45, 1998.
[Ame03] American National Standard for Information Technology. Role Based
Access Control (Draft), 4 2003.
[AML+01] A. Abecker, G. Mentzas, M. Legal, S. Ntioudis, and G. Papvas-
siliou. Business-Process Oriented Delivery of Knowledge through
Domain Ontologies. In Proceedings of DEXA conference, TAKMA-
2001, Second International Workshop on Theory and Applications
of Knowledge Management, 2001.
[Ass02] Association for Computing Machinery. ACM Computing Classifica-
tion System, 2002.
[BB98] P.O. Bengtsson and J. Bosch. Scenario-Based Software Architec-
ture Reengineering. In Proceedings of International Conference of
Software Reuse 5 (ICSR5), June 1998.
[BCK98] L. Bass, P. Clements, and R. Kazman. Software Architecture in
Practice. Addison Wesley, 1998.
189
BIBLIOGRAPHY 190
[BM04] R. A. Burkhard and M. Meier. Tube Map: Evaluation of a Visual
Metaphor for Interfunctional Communication of Complex Projects.
In Proceedings of I-Know’04 - 4th International Conference on
Knowledge Management, Graz, Austria, 2004.
[BMR+96] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal.
Pattern-Oriented Software Architecture, Volume 1: A System of Pat-
terns. Wiley, 1996.
[Boe88] B. W. Boehm. A Spiral Model of Software Development and En-
hancement. IEEE Computer, 21(5), 1988.
[BPSM+04] T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler, F. Yergeau,
and J. Cowan. Extensible Markup Language (XML) 1.1 - W3C
Recommendation 04 February 2004, edited in place 15 April 2004.
Technical report, W3C - World Wide Web Consortium, 2004.
[Bri96] S. Brinkkemper. Method Engineering: Engineering of Information
Systems Development Methods and Tools. Information and Software
Technology, 38:275–280, 1996.
[BsV00] V. Bach, H. Osterle, and P. Vogler. Business Knowledge Manage-
ment in der Praxis - Prozessorientierte Losungen zwischen Knowl-
edge Portal und Kompetenzmanagement. Springer Verlag, 2000.
[CLC04] S.Y. Choy, W.B. Lee, and C.F. Cheung. A Systematic Approach
for Knowledge Audit Analysis: Integration of Knowledge Inventory,
Mapping and Knowledge Flow Analysis. In Proceedings of I-Know’04
- 4th International Conference on Knowledge Management, Graz,
Austria, 2004.
[Coc00] A. Cockburn. Writing Effective Use Cases. Addison-Wesley Pub
Co, 2000.
[DB03] J. Dutra and J. Busch. Taxonomy Development with NASA. In In-
ternational Conference on Space Mission Challenges for Information
Technology (SMC-IT), 2003.
BIBLIOGRAPHY 191
[DHB01] I. Dammig, U. Hess, and C. Borgmann. Wissenstransparenz als Wet-
tbewerbsvorteil - Einstiegsmethode und -werkzeug in das praktische
Wissensmanagement von Unternehmen. In Proceedings of WM2001,
1. Konferenz Professionelles Wissensmanagement, Baden - Baden,
2001.
[DHMS00] M. Diefenbruch, M. Hoffmann, A. Misch, and Helge Schneider. Situ-
ated Knowledge Management - KM on the Borderline Between chaos
and Rigidity. In Proceedings of PAKM 2000 - Conference on Prac-
tical Aspects of Knowledge Management, pages 8–1–8–7, 2000.
[Dia01] C. Dias. Corporate Portals: A Literature Review of a New Concept
in Information Management. International Journal of Information
Management, 21(4):269–287, August 2001.
[DJB95] T. Davenport, S. Jarvenpaa, and M. Beers. Improving Knowledge
Work Processes (Working Paper). Technical report, Ernst & Young
LLP, Center for Business Innovation, 1995.
[DRA+03] B. Decker, J. Rech, K.D. Althoff, A. Klotz, E. Leopold, and A. Voss.
Participative Process Introduction: A Case Study in the indigo
Project. In Proceedings of I-Know ’03, 3rd international conference
on knowledge management, Graz, Austria, 2003.
[Dub03] Dublin Core Metadata Initiative. The Dublin Core Metadata Ele-
ment Set (Draft), 02 2003.
[Dus02] S. Dustdar. Collaborative Knowledge Flow - Improving Process-
Awareness and Traceability of Work Activities. In Proceedings of the
Fourth International Conference on Practical Aspects of Knowledge
Management (PAKM2002), 2002.
[Eng03] W. Engelbach. Vorgebaute Informationsraume fur Information-
srecherchestrategien in wissensintensiven Geschaftsprozessen. In
U. Reimer, A. Abecker, S. Staab, and G. Stumme, editors, WM
2003, Professionelles Wissensmanagement - Erfahrungen und Vi-
sionen, Luzern, 2003.
BIBLIOGRAPHY 192
[ESR99] M. J. Eppler, P. M. Seifried, and A. Ropnack. Improving Knowl-
edge Intensive Processes through an Enterprise Knowledge Medium.
In Proceedings of the 1999 ACM SIGCPR conference on Computer
personnel research, 1999.
[FMO+94] G. Fischer, R. McCall, J. Ostwald, B. Reeves, and F. Shipman.
Seeding, Evolutionary Growth and Reseeding: Supporting the In-
cremental Development of Design Environments. In Proceedings of
the Conference on Computer-Human Interaction (CHI’94), Boston,
MA, USA, 1994.
[FS00] M. Fowler and K. Scott. UML konzentriert - Eine strukturierte
Einfuhrung in die Standard-Objektmodellierungssprache, 2. Ausgabe.
Addison-Wesley, 2000.
[FS01] O. K. Ferstl and E. J. Sinz. Grundlagen der Wirtschaftsinformatik,
Bd.1, 4. Auflage. Oldenbourg Verlag, 2001.
[Fug93] A. Fuggetta. A Classification of CASE Technology. IEEE Computer,
26(12):25–38, December 1993.
[Gia99] G. M. Giaglis. On the Integrated Design and Evaluation of Busi-
ness Processes and Information Systems. Communications of the
Association for Information Systems, 1, 1999.
[Goe02] T. Goesmann. Ein Ansatz zur Unterstutzung wissensinten-
siver Prozesse durch Workflow-Management-Systeme. PhD thesis,
Fakultat IV - Elektrotechnik und Informatik der technischen Uni-
versitat Berlin, Berlin, Deutschland, 2002.
[GPSW03] N. Gronau, U. Palmer, K. Schulte, and T. Winkler. Modellierung von
wissensintensiven Geschaftsprozessen mit der Beschreibungssprache
K-Modeler. In U. Reimer, A. Abecker, S. Staab, and G. Stumme, ed-
itors, WM 2003, Professionelles Wissensmanagement - Erfahrungen
und Visionen, Luzern, 2003.
[Gro] Object Management Group. UML Resource Page. http://www.
omg.org/technology/uml/, last accessed on September 24th, 2004.
BIBLIOGRAPHY 193
[Gro03] SVG Working Group. Scalable Vector Graphics (SVG) 1.1 Spec-
ification. Technical report, W3C - World Wide Web Consortium,
2003.
[Gua98] N. Guarino. Formal Ontology and Information Systems. In Proceed-
ings of FOIS’98, Trento, Italy, pages 3–15, Amsterdam, 1998. IOS
Press.
[Har02] H.J. Hartl. Konzeption eines Wissensportals auf der Ba-
sis von Hyperwave zur Unterstutzung des wissenschaftlichen
Forschungsprozesses. Master’s thesis, Wirtschaftswissenschaftliche
Fakultat der Universitat Regensburg, Regensburg, Deutschland,
2002.
[Hei01] P. Heisig. Business Process oriented Knowledge Management -
Methode zur Verknupfung von Wissensmanagement und Geschaft-
sprozessgestaltung. In Proceedings of WM2001, 1. Konferenz Pro-
fessionelles Wissensmanagement, Baden - Baden, 2001.
[HGM01] M. Hoffmann, T. Goesmann, and A. Misch. Unsichtbar oder
Vergessen - Wie man ”verborgenen Wissensprozessen” auf die
Schliche kommt. In Proceedings des Workshops Geschaftsprozes-
sorientiertes Wissensmanagement der 1. Konferenz ”Professionelles
Wissensmanagement” WM 2001, pages 59–63. Shaker-Verlag, 2001.
[HHDG02] M. Hoffmann, T. Herrmann, M. Diefenbruch, and T. Goesmann.
PRomisE2 - Recording and Displaying Situated Process Informa-
tion in Knowledge Management Applications. In Proceedings of
I-Know’02 - International Conference on Knowledge Management,
Graz - Austria, July 2002.
[HNT99] M.T. Hansen, N. Nohria, and T. Tierney. What’s your Strategy
for Managing Knowledge? Harvard Business Review, March-April
1999.
[Hol95] D. Hollingsworth. Workflow Management Coalition - The Workflow
Reference Model. Technical report, Workflow Management Coali-
tion, Jan 1995.
BIBLIOGRAPHY 194
[HTEN03] C. Huth, N. Tas, I. Erdmann, and L. Nastansky. GroupProcess Web:
Graphisch interaktives Management von Ad-hoc-Geschaftsprozessen
im Web. In U. Reimer, A. Abecker, S. Staab, and G. Stumme, edi-
tors, WM 2003, Professionelles Wissensmanagement - Erfahrungen
und Visionen, Luzern, 2003.
[HvR00] B.J. Hommes and V. van Reijswoud. Assessing the Quality of
Business Process Modelling Techniques. In Proceedings of the 33rd
Hawaii International Conference on System Sciences, 2000.
[Hyp] Hyperwave. Knowledge Management Software. http://www.
hyperwave.com, last accessed on September 9th, 2004.
[IAB95] IABG. V-Model, Lifecycle Process Model - Brief Description. IABG
Industrieanlagen-Betriebsgesellschaft mbH, Einsteinstr. 20, D-85521
Ottobrunn, 1995.
[isoa] The ISO Survey of ISO 9000 and ISO 14000 Certificates
- Eleventh Cycle: Up to and including December 31st,
2001. http://www.iso.ch/iso/en/prods-services/otherpubs/
pdf/survey11thcycle.pdf, last accessed on September 9th, 2004.
[isob] The ISO Survey of ISO 9000 and ISO 14000 Certificates - Twelfth
Cycle: Up to and including December 31st, 2002. http://www.
iso.ch/iso/en/iso9000-14000/pdf/survey12thcycle.pdf, last
accessed on September 9th, 2004.
[ISO00a] ISO - International Organisation for Standardization. Qualitatsman-
agementsysteme: Anforderungen (ISO 9001:2000), Dezember 2000.
[ISO00b] ISO - International Organisation for Standardization. Qualitatsman-
agementsysteme: Grundlagen und Begriffe (ISO 9000:2000), Dezem-
ber 2000.
[ISO00c] ISO - International Organisation for Standardization. Qualitats-
managementsysteme: Leitfaden zur Leistungsverbesserung (ISO
9004:2000), Dezember 2000.
BIBLIOGRAPHY 195
[Jan00] C. Jansen. Prozessunterstutzung durch Wissensplattformen. PhD
thesis, Universitat St. Gallen, Hochschule fur Wirtschafts-, Rechts-
und Sozialwissenschaften (HSG), St. Gallen, Schweiz, 2000.
[JHS01] S. Jablonski, S. Horn, and M. Schlundt. Process Oriented Knowl-
edge Management. In Eleventh International Workshop on Research
Issues in Data Engineering: Document Management for Data In-
tensive Business and Scientific Applications, Heidelberg, Germany,
pages 77–84. IEEE Computer Society, 2001.
[Kan03] D. Kandpal. Augmenting Knowledge-Intensive Systems with Dy-
namic Personalization Concepts. PhD thesis, Graz University of
Technology, Graz, Austria, 2003.
[KHS03] S. Kim, H. Hwang, and E. Suh. A Process-based Approach to
Knowledge-Flow Analysis: A Case Study of a Manufacturing Firm.
Knowledge and Process Management, 10(4), 2003.
[Koc97] N.F. Kock Jr. The Effects of Asynchronous Groupware on Business
Process Improvement. PhD thesis, University of Waikato, Hamilton,
New Zealand, 1997.
[Kru] P. Kruchten. What is the Rational Unified Process? http://
www.therationaledge.com/content/jan_01/f_rup_pk.html, last
accessed on December 19th, 2003.
[KS98] G. Kotonya and I. Sommerville. Requirements Engineering. John
Wiley & Sons Ltd, 1998.
[KSG+03] W. Kienreich, V. Sabol, M. Granitzer, F. Kappe, and K. Andrews.
InfoSky: A System for Visual Exploration of Very Large, Hierarchi-
cally Structured Knowledge Spaces. In Proceedings der GI Work-
shopwoche LLWA - Workshop der Fachgruppe FGWM (Fachgruppe
Wissensmanagement), October 2003.
[KT00] D. Karagiannis and R. Telesko. The EU-Project PROMOTE: A
Process-Oriented Approach for Knowledge Management. In Proceed-
ings of PAKM 2000 - Conference on Practical Aspects of Knowledge
Management, pages 13–1–13–7, 2000.
BIBLIOGRAPHY 196
[Kun02] S. Kundermann. Ansatze zur Qualitatsverbesserung von Wis-
sensprozessen. Master’s thesis, Johann Wolfgang Goethe-
Universitat, Lehrstuhl fur Entwicklung betrieblicher Information-
ssysteme, Frankfurt am Main, 2002.
[LB03] C. Larman and V.R. Basili. Iterative and Incremental Development:
A Brief History. IEEE Computer, 36(6):47–56, 2003.
[Leh00] F. Lehner. Organizational Memory. Carl Hanser Verlag Munchen
Wien, 2000.
[Leh02] F. Lehner. Informationsbroschure des Lehrstuhls: TEIL W - Wis-
sensmanagement und Prozeßmanagement. Technical report, Univer-
sitat Regensburg, Mai 2002.
[Lin98] S.N. Lindstaedt. Group Memories: A Knowledge Medium for Com-
munities of Interest. PhD thesis, University of Colorado, Boulder,
U.S.A., 1998.
[Liv] Livelink. Knowledge Management Software, OPENTEXT. http:
//www.opentext.com, last accessed on September 9th, 2004.
[Lot] Lotus. Knowledge Management Software, IBM. http://www.
lotus.com, last accessed on September 9th, 2004.
[LSF+02] S. Lindstaedt, M. Strohmaier, J. Farmer, J. Hrastnik, and H. Rollett.
KMap: Providing Orientation for Practitioners when Introducing
Knowledge Management. In Proceedings of the 4th International
Conference on Practical Aspects of Knowledge Management (PAKM
2002). Springer Verlag, 2002.
[LSF+03] S. Lindstaedt, M. Strohmaier, J. Farmer, J. Hrastnik, and H. Rol-
lett. Integration von Prozess- und Wissensmanagement-orientierten
Designstrategien zur Erstellung benutzerfreundlicher Unternehmen-
sportale. In U. Reimer, A. Abecker, S. Staab, and G. Stumme, edi-
tors, WM 2003, Professionelles Wissensmanagement - Erfahrungen
und Visionen, Luzern, 2003.
BIBLIOGRAPHY 197
[Mac96] L. Macaulay. Requirements for Requirements Engineering Tech-
niques. In 2nd International Conference on Requirements Engineer-
ing (ICRE ’96), 1996.
[Mac97] M.S. MacNealy. Toward Better Case Study Research. IEEE Trans-
actions on Professional Communication, 40(3):182–196, September
1997.
[Mai02] R. Maier. Knowledge Management Systems. Springer Verlag Berlin,
2002.
[MH99] F. Maurer and H. Holz. Process-Oriented Knowledge Management
for Learning Software Organizations. In Proceedings of the 12th
Workshop on Knowledge Acquisition, Modeling, and Management
(KAW-99), 1999.
[MHA03] K. Mertins, P. Heisig, and K. Alwert. Process-Oriented Knowledge
Structuring. Journal of Universal Computer Science, 9(6), 2003.
[MHV03] K. Mertins, P. Heisig, and J. Vorbeck. Knowledge Management -
Concepts and Best Practices. Springer Verlag Berlin Heidelberg New
York, 2003.
[Mica] Microsoft. Moving Java Applications to .NET. http:
//msdn.microsoft.com/library/en-us/dndotnet/html/dotnet_
movingjavaapps.asp, last accessed on June 14th, 2004.
[Micb] Microsoft. .NET Framework. http://www.microsoft.com/net, last
accessed on June 14th, 2004.
[Micc] Microsoft. Visio 2003. http://www.microsoft.com/office/visio,
last accessed on June 14th, 2004.
[Micd] Microsoft. What is .NET? http://www.microsoft.com/net/
basics, last accessed on June 14th, 2004.
[MPF04] T. Mueller-Prothmann and I. Finke. SELaKT - Social Network Anal-
ysis as a Method for Expert Localisation and Sustainable Knowledge
Transfer. In Proceedings of I-Know’04 - 4th International Conference
on Knowledge Management, Graz, Austria, 2004.
BIBLIOGRAPHY 198
[MR01] R. Maier and U. Remus. Towards a Framework for Knowledge Man-
agement Strategies: Process Orientation as Strategic Starting Point.
In Proceedings of the 34th Hawaii International Conference on Sys-
tem Sciences, 2001.
[MR02] R. Maier and U. Remus. Defining Process-oriented Knowledge Man-
agement Strategies. Knowledge and Process Management, 9(2):103–
118, 2002.
[MR03] R. Maier and U. Remus. Implementing Process-Oriented Knowl-
edge Management Strategies. Journal of Knowledge Management,
7(4):62–74, 2003.
[MRH+04] K. Matzler, M. Rier, H. Hinterhuber, B. Renzl, and C. Stadler.
Methoden und Konzepte im strategischen Management - Bedeutung,
Zufriedenheit, Forschungsbedarf. In Weissenberger-Eibl, editor, Un-
ternehmen im Umbruch - Konzepte, Instrumente und Erfolgsmuster.
Cactus Group Verlag, 2004.
[MT02] H. Maurer and K. Tochtermann. On a New Powerful Model for
Knowledge Management and its Applications. Journal of Universal
Computer Science, 8(1):85–96, 2002.
[Mye04] M.D. Myers. Qualitative Research in Information Systems. Archival
Version: MIS Quarterly (21:2), June 1997, pp. 241-242. MISQ Dis-
covery, June 1997. Updated Version available from http://www.
misq.org/discovery/MISQD_isworld/, last accessed on September
9th, 2004, revision from February 24th, 2004.
[Net04] Netscape Communication Corporation. DMOZ - Open Directory
Project (ODP), 2004.
[Noh00] H. Nohr. Wissen und Wissensprozesse visualisieren. Technical re-
port, HBI Stuttgart, 2000.
[Noh02] H. Nohr. Strategie- und Geschaftsprozessorientiertes Wissensman-
agement. Technical report, Hochschule der Medien, Studiengang
Informationswirtschaft, 2002.
BIBLIOGRAPHY 199
[NT97] I. Nonaka and H. Takeuchi. Die Organisation des Wissens.
Wie japanische Unternehmen eine brachliegende Ressource nutzbar
machen. Campus, Frankfurt a.M., New York, 1997.
[ON01] E. Oxendine and M. E. Nissen. Knowledge Process and System
Design for the Carrier Battle Group. Knowledge and Innovation:
Journal of the Knowledge Management Consortium International,
1(3), 2001.
[OP03] A. Oberweis and O. Paulzen. Kontinuierliche Qualitatsverbesserung
im Wissensmanagement - ein prozessbasiertes Reifegradmodell. In
Proceedings der KnowTech 2003 - 5. Konferenz zum Einsatz von
Knowledgemanagement in Wirtschaft und Verwaltung, 2003.
[Pai03] D. Paier. Network Analysis: A Tool for Analysis and Monitoring
of the Dynamics of Knowledge Processes in Organizations. In Pro-
ceedings of I-Know ’03, 3rd international conference on knowledge
management, Graz, Austria, 2003.
[Pep00] S. Pepper. The TAO of Topic Maps. In Proceedings of XML Europe
2000, Paris, France, 2000.
[PMA02] G. Papavassiliou, G. Mentzas, and A. Abecker. Integrating Knowl-
edge Modelling in Business Process Management. In ECIS2002
conference: The Xth European Conference on Information Systems,
2002.
[PNAM02] G. Papavassiliou, S. Ntioudis, A. Abecker, and G. Mentzas. Man-
aging Knowledge in Weakly-Structured Administrative Processes.
In Proceedings of The Third European Conference on Organiza-
tional Knowledge, Learning, and Capabilities - OKLC 2002, Athens,
Greece, April 2002.
[PP02] O. Paulzen and P. Perc. A Maturity Model for Quality Improve-
ment in Knowledge Management. In A. Wenn, M. McGrath, and
F. Burstein, editors, Enabling Organisations and Society through In-
formation Systems, Proceedings of the 13th Australasian Conference
BIBLIOGRAPHY 200
on Information Systems (ACIS 2002), pages 243–253, Melbourne,
2002.
[PPS02] A. Papargyris, A. Poulymenakou, and K. Samiotis. Knowledge Pro-
cesses Embedded in Task Structures: Implications for the Design
of a Technical and Organisational Solution. In Proceedings of the
Fourth International Conference on Practical Aspects of Knowledge
Management (PAKM2002), 2002.
[Pre00] J. Preece. Online Communities: Designing Usability and Supporting
Sociability. John Wiley & Sons; 1st edition, september 2000.
[PRR98] G. Probst, S. Raub, and K. Romhard. Wissen managen - wie Un-
ternehmen ihre wertvollste Ressource optimal nutzen. Dr. Th. Gabler
Verlag, 1998.
[Rem01] U. Remus. Integrierte Prozeß- und Kommunikationsmodellierung
als Ausgangspunkt fur die Verbesserung von wissensintensiven
Geschaftsprozessen. In Proceedings of WM2001, 1. Konferenz Pro-
fessionelles Wissensmanagement, Baden - Baden, 2001.
[Rem02] U. Remus. Prozeßorientiertes Wissensmanagement - Konzepte und
Modellierung. PhD thesis, Wirtschaftswissenschaftliche Fakultat der
Universitat Regensburg, Regensburg, Deutschland, 2002.
[RES+00] J. Raimann, E. Enkel, A. Seufert, G. von Krogh, and A. Back.
Supporting Business Processes through Knowledge Management -
A Technology-based Analysis. Technical report, Research Center
Knowledge Source, University of St. Gallen, March 2000.
[RL00] U. Remus and F. Lehner. The Role of Process-oriented Enter-
prise Modeling in Designing Process-oriented Knowledge Manage-
ment Systems. In Proceedings of the AAAI Symposium on Bringing
Knowledge to Business Processes. Stanford, CA, USA, 2000.
[RMS00] U. Reimer, A. Margelisch, and M. Staudt. EULE: A Knowledge-
Based System to Support Business Processes. Knowledge-Based Sys-
tems, 13(5):261–269, 2000.
BIBLIOGRAPHY 201
[Rol03] H. Rollett. Knowledge Management - Processes and Technologies.
Kluwer Academic Publishers, Boston/Dordrecht/London, 2003.
[Roy70] W.W. Royce. Managing the Development of Large Software Systems.
In Proceedings of IEEE Wescon, August 1970.
[RR99] S. Robertson and J. Robertson. Mastering the Requirements Process.
ACM Press, 1999.
[RR03] L. Ramos and D.W. Rasmus. Best Practices in Taxonomy Devel-
opment and Management. Giga Information Group, January, 8th
2003.
[RZ96] D. Riehle and H. Zullighoven. Understanding and Using Patterns
in Software Development. Theory and Practice of Object Systems,
2(1), 1996.
[SAA+02] G. Schreiber, H. Akkermans, A. Anjewierden, R. de Hoog, N. Shad-
bolt, W. Van de Velde, and B. Wielinga. Knowledge Engineering
and Management. The MIT Press, 2002.
[Sch96] A.W. Scheer. ARIS-House of Business Engineering. IWI Hefte, 133,
1996.
[Sch00] A.W. Scheer. ARIS - Business Process Modeling. Springer Verlag,
2000.
[Sin95] E. Sinz. Ansatze zur fachlichen Modellierung betrieblicher Informa-
tionssysteme - Entwicklung, Aktueller Stand und Trends. Bamberger
Beitrage zur Wirtschaftsinformatik, 34, 1995.
[Sin97] E. Sinz. Architektur betrieblicher Informationssysteme. Bamberger
Beitrage zur Wirtschaftsinformatik, 40, 1997.
[Sit02] A.A. Sitiol. CASE Technology. In 2002 Student Conference on Re-
search and Development, Shah Alam, Malaysia, 2002.
[Siv99] Y.Y. Sivan. Launching a Knowledge Infrastructure: How to Jump-
start the Process. WebNet Journal, 1(4):16–19, October 1999.
BIBLIOGRAPHY 202
[Siv01] Y.Y. Sivan. Nine Keys to a Knowledge Infrastructure: A Proposed
Analytic Framework for Organizational Knowledge Management.
Research Paper, March 2001.
[SP01] P. Starkloff and K. Pook. Process-Integrated Learning: The ADVI-
SOR Approach for Corporate Development. In Proceedings of The
Third International Workshop on Learning Software Organizations
(LSO’01), September 2001.
[SRB03] S. Schwarz and T. R. Roth-Berghofer. Towards Goal Elicitation
by User Observation. In Proceedings der GI Workshopwoche LLWA
- Workshop der Fachgruppe FGWM (Fachgruppe Wissensmanage-
ment), October 2003.
[Str03a] M. Strohmaier. A Business Process Oriented Approach for the
Identification and Support of Organizational Knowledge Processes.
In 4. Oldenburger Fachtagung Wissensmanagement, Potenziale -
Konzepte - Werkzeuge, 2003.
[Str03b] M. Strohmaier. Designing Business Process Oriented Knowledge In-
frastructures. In Proceedings der GI Workshopwoche LLWA - Work-
shop der Fachgruppe FGWM (Fachgruppe Wissensmanagement),
October 2003.
[TK02] R. Telesko and D. Karagiannis. Process-based Knowledge Man-
agement: Experiences with two Projects. In Proceedings of Tenth
European Conference on Information Systems ECIS 2002, Gdansk,
Poland, June 2002.
[Toc02] K. Tochtermann. Personalization in Knowledge Management. In Pe-
ter J. Nuernberg, editor, Metainformatics: International Symposium
(MIS), Esbjerg, Denmark, 2002.
[Tol98] J.-P. Tolvanen. Incremental Method Engineering with Modeling
Tools. PhD thesis, University of Jyvaskyla, Finland, 1998.
[Top01] TopicMaps.Org Authoring Group. XML Topic Maps (XTM) 1.0 -
TopicMaps.Org Specification, 08 2001. Available from: http://www.
topicmaps.org/, Editors: Steve Pepper, Graham Moore.
BIBLIOGRAPHY 203
[TPSS04] C. Tempich, S. Pinto, S. Staab, and Y. Sure. A Case Study in Sup-
porting Distributed, Loosely-Controlled and Evolving Engineering
of Ontologies (DILIGENT). In Proceedings of I-Know’04 - 4th In-
ternational Conference on Knowledge Management, Graz, Austria,
2004.
[VA+02] A. Voss, K.D. Althoff, , U. Becker-Kornstaedt, B. Decker, A. Klotz,
E. Leopold, and J. Rech. Enhancing Experience Management and
Process Learning with Moderated Discourses: the indiGo Approach.
In Proceedings of the Fourth International Conference on Practical
Aspects of Knowledge Management (PAKM2002), 2002.
[VK04] V. Vaishnavi and W. Kuechler. Design Research in Information Sys-
tems. http://www.isworld.org/Researchdesign/drisISworld.
htm, last accessed on September 9th, 2004, revision from February
20th, 2004.
[WC03] V. Weerakkody and W. Currie. Integrating Business Process Reengi-
neering with Information Systems Development: Issues & Implica-
tions. In Proceedings of Business Process Management Conference
(BPM), Eindhoven, Netherlands, June 2003.
[Wer] P. Werbicki. Summary of Chapters 1-6 of the Book ”Requirements
Engineering”ISBN 3-540-76006-7, Springer-Verlag, Linda Macaulay,
1996. http://www.criticaljunction.com/werbicki/, last ac-
cessed on January 9th, 2004.
[WK02] R. Woitsch and D. Karagiannis. Process-oriented Knowledge Man-
agement Systems Based on KM-Services: The PROMOTE Ap-
proach. In Proceedings of the Fourth International Conference on
Practical Aspects of Knowledge Management (PAKM2002), 2002.
[WK03] R. Woitsch and D. Karagiannis. Knowledge Management Service
Based Organisations. In 4. Oldenburger Fachtagung Wissensman-
agement, Potenziale - Konzepte - Werkzeuge, 2003.
[Woi03] R. Woitsch. Knowledge Management Services as a Basic Concept
for Enterprise Knowledge Management System. In Proceedings of I-
BIBLIOGRAPHY 204
Know ’03, 3rd international conference on knowledge management,
Graz, Austria, 2003.
[Wol03] U. Woltron. Der Ort als Maschine. Der Standard, page A8, May,
31th, 2003.
[WWT98] C. Wargitsch, T. Wewers, and F. Theisinger. An Organizational-
Memory-Based Approach for an Evolutionary Workflow Manage-
ment System-Concepts and Implementation. In Proceedings of
HICCS’31, the 31st Hawaii International Conference on Systems
Sciences, 1998.
[YC79] E. Yourdon and L.L. Constantine. Structured Design - Fundamentals
of a Discipline of Computer Program and Systems Design. Prentice-
Hall, 1979.
[You89] E. Yourdon. Modern Structured Analysis. Prentice-Hall, 1989.
Index
.NET framework, 113
Access, 96
ADVISOR, 51
Application object, 80
Architecture, 64
ARIS, 49
B-KIDE
context, 71, 72, 74
design process, 90
framework, 71, 72, 112, 117, 139,
145, 157, 160
framework application, 97
framework evolution, 149
knowledge infrastructure tem-
plate architecture, 94
method, 71, 72, 89, 113, 122, 129,
135, 158, 160
model architecture, 71, 72, 76,
160
modeling structure, 77, 104, 105,
113
modeling technique, 85, 112, 120,
127
reference models, 81, 103, 104,
106, 120, 128, 134
tool, 71, 72, 99, 140, 160
tool evolution, 150
BKM, 53
Business process, 78
Business process analysis, 48
Business process execution, 55, 61
Business process improvement, 58, 62
Business process landscape, 110
Business process learning, 50, 61
Business process management, 30
Business process modeling, 48, 61
Business process oriented knowledge
management, 46
Business process perspective, 83
Business process re-engineering, 58
Business process support, 52, 61
case study, 117, 119
CASE tools, 41
Constructivism, 27
Contents, 95
Continuous process improvement, 58
DECOR, 58
Decoupled knowledge processes, 146
EULE, 58
Fit criteria, 92, 124, 131, 138
Generation object, 79
GPO-WM, 54
205
INDEX 206
indiGO, 60
K-Modeler, 50
Knowledge, 30
Knowledge analysts, 36, 85, 99, 106,
107
Knowledge communities, 153
Knowledge domains, 31, 79
Knowledge flows, 70
Knowledge infrastructure design
evaluation, 124, 131, 138
Knowledge infrastructure design val-
idation, 94
Knowledge infrastructure designers,
37, 90, 99, 110
Knowledge infrastructure develop-
ment project, 33
Knowledge infrastructures, 20, 26,
33, 70
Knowledge management, 20, 30
Knowledge management activities,
32
Knowledge management interven-
tions, 30
Knowledge management maturity
levels, 146, 154
Knowledge management strategies,
47, 155
Knowledge management system
functionality, 23
Knowledge management technolo-
gies, 44
Knowledge management worker, 36
Knowledge managers, 35
Knowledge networks reference
model, 54
Knowledge process definition, 91,
122, 129, 135
Knowledge process landscape, 111
Knowledge process optimization, 146
Knowledge process perspective, 84
Knowledge process quality model,
146, 154
Knowledge processes, 30, 66–69
Knowledge project managers, see
Project managers
Knowledge risks, 154
Knowledge user, 36
Knowledge work, 31, 66, 78
Knowledge workers, 31, 36
KODA, 59
Lessons learned, 139
Maurer-Tochtermann model, 23
Meta knowledge, 95
Milos, 56
MODEL, 52
Model perspectives, 83, 110
Model system refinement, 89, 121,
128, 135
Object system modeling, 87, 121,
128, 134
Oblivion, 148
Ontologies, 96, 156
Organizational knowledge, 30
Organizational roles, 79
Organizations, 26, 29
Pattern analysis, 43
INDEX 207
Patterns, 39
Personalization, 148
Pilot studies, 117, 126, 132
Pre-modeling, 87, 106, 120, 128, 134
Preliminary knowledge infrastruc-
ture design, 93, 124, 131, 137
Project managers, 36
PRomisE2, 55
PROMOTE, 57
Quality gateway, 91
Rational unified process, 41
Realism, 27
Requirements engineering, 38
Role orientation, 26, 148
Scope definition, 86, 120, 127, 133
Social network analysis, 43
Specific knowledge activities, 31, 70,
79
Spiral model, 40
Storage object, 80, 81, 123, 130, 137
System analysis, 37
System design, 38
System usage, 39
Taxonomies, 95
Transfer object, 80, 81, 123, 130
Undefined work activity, 79
User observation, 43
V-Model, 40
Waterfall model, 40
Workbrain, 57
Workflow management systems, 55
About the Author
Markus B. Strohmaier received a master’s degree in Telematics from Graz
University of Technology in 2002 (Institute for Technical Informatics) and a doc-
toral degree in Technical Sciences from the Graz University of Technology in 2004
(Institute for Knowledge Management and Knowledge Visualization). Prior to
joining the Know-Center Graz as a project manager and researcher, he worked
for the Austrian Research Centers (ARC), Knapp Logistics, Siemens PSE and
numerous other companies. His research interests include knowledge and pro-
cess management, organizational development, business information systems and
systems analysis and design.
208