PhD Thesis
B-KIDE: A Framework and a Tool for Business Process Oriented Knowledge Infrastructure Development
Markus B...
19 downloads
546 Views
3MB Size
Report
This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form
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 scientific 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, developed 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. Hermann 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 establish 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 1
The document at hand represents a revised version of the PhD thesis completed by the author in December 2004.
conducted projects with always challenged my hypotheses and provided valuable feedback. Thank you. Johann G¨otschl, and all participants of his philosophical circle for PhD students, 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 KnowCenter 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 Verf¨ ugbarkeit und Weiterentwicklung dieser Innovationen verst¨arkte 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 f¨ ur die Entwicklung von gesch¨aftsprozessunterst¨ utzenden, technologischen Wissensinfrastrukturen vor. W¨ahrend dabei Gesch¨aftsprozesse den organisatorischen Rahmen f¨ ur die Anwendung von Wissensmanagement-Technologien bieten, so repr¨asentieren Wissensinfrastrukturen ein Konzept, dass Wissensmanagement in Organisationen erm¨oglicht. Der in dieser Dissertation entwickelte B-KIDE Framework bietet Unterst¨ utzung in der Entwicklung von Wissensinfrastrukturen, welche innovative Wissensmanagementfunktionalit¨aten beinhalten und sichtbar organisatorische Gesch¨aftsprozesse unterst¨ utzen, an. Das entwickelte B-KIDE Tool erleichtert die Anwendung des B-KIDE Frameworks f¨ ur Entwickler von Wissensinfrastrukturen. Drei durchgef¨ uhrte, empirische Studien mit Unternehmen unterschiedlichster Branchen bekr¨aftigen die Relevanz und Viabilit¨at der eingef¨ uhrten Konzepte. Schlu orter: Wissensmanagement, Wissensinfrastrukturen, Gesch¨aftspro¨ sselw¨ 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 innovative 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 1.1
21
Research Challenges . . . . . . . . . . . . . . . . . . . . . . . . .
22
1.1.1
Challenge 1 . . . . . . . . . . . . . . . . . . . . . . . . . .
23
1.1.2
Challenge 2 . . . . . . . . . . . . . . . . . . . . . . . . . .
24
1.1.3
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
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
1.2
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
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
Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
2.3
2.4
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
Business Process Learning . . . . . . . . . . . . . . . . . . . . . .
51
3.5.1
Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
3.5.2
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
3.5.3
Selected Approaches . . . . . . . . . . . . . . . . . . . . .
52
3.5
3.6
. . . . . . . . . . . . . . . . . . . . . .
53
3.6.1
Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
3.6.2
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
3.6.3
Selected Approaches . . . . . . . . . . . . . . . . . . . . .
54
Business Process Execution . . . . . . . . . . . . . . . . . . . . .
56
3.7.1
Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
3.7.2
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
3.7.3
Selected Approaches . . . . . . . . . . . . . . . . . . . . .
57
Business Process Improvement . . . . . . . . . . . . . . . . . . . .
59
3.8.1
Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
3.8.2
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
3.8.3
Selected Approaches . . . . . . . . . . . . . . . . . . . . .
60
Assessment in the Context of this Work . . . . . . . . . . . . . . .
61
3.10 Focal Point of this PhD Work . . . . . . . . . . . . . . . . . . . .
63
3.7
3.8
3.9
Business Process Support
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 4.5
Characteristics of Knowledge Infrastructures Following this Principle Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
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
B-KIDE Model Architecture . . . . . . . . . . . . . . . . . . . . .
77
5.3.1
B-KIDE Modeling Structure . . . . . . . . . . . . . . . . .
78
5.3.2
B-KIDE Modeling Technique . . . . . . . . . . . . . . . .
86
B-KIDE Method . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
5.4.1
Design Process “Designing Knowledge Infrastructures” . .
91
5.4.2
B-KIDE Knowledge Infrastructure Template Architecture .
95
Remarks on B-KIDE Framework Application . . . . . . . . . . . .
98
5.3
5.4
5.5
6 B-KIDE Tool 6.1
100
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.4
6.3.1
Reference Models . . . . . . . . . . . . . . . . . . . . . . . 105
6.3.2
Interview Data . . . . . . . . . . . . . . . . . . . . . . . . 106
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
7.3
7.4
7.5
7.6
. . . . . . . . . . . . . . . . . . 120
7.2.1
Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.2.2
Pursued Goals . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.2.3
Approach Taken
7.2.4
Achieved Results . . . . . . . . . . . . . . . . . . . . . . . 126
. . . . . . . . . . . . . . . . . . . . . . . 121
Pilot Study 1: Automotive Industry . . . . . . . . . . . . . . . . . 127 7.3.1
Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.3.2
Pursued Goals . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.3.3
Approach Taken
7.3.4
Achieved Results . . . . . . . . . . . . . . . . . . . . . . . 133
. . . . . . . . . . . . . . . . . . . . . . . 128
Pilot Study 2: Consulting Industry . . . . . . . . . . . . . . . . . 133 7.4.1
Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7.4.2
Pursued Goals . . . . . . . . . . . . . . . . . . . . . . . . . 134
7.4.3
Approach Taken
7.4.4
Achieved Results . . . . . . . . . . . . . . . . . . . . . . . 139
. . . . . . . . . . . . . . . . . . . . . . . 134
Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 7.5.1
B-KIDE Framework . . . . . . . . . . . . . . . . . . . . . 140
7.5.2
B-KIDE Tool . . . . . . . . . . . . . . . . . . . . . . . . . 141
Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
CONTENTS 8 Future Work
10 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 C.1.7 Interview Execution
11 . . . . . . . . . . . . . . . . . . . . . 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]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
33
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 Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Framework [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 Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 c E.1 Microsoft Excel 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 Corresponding 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 Engineering 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 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
18
LIST OF TABLES XML Extensible Markup Language XSLT Extensible Stylesheet Language Transformations
19
Chapter 1 Introduction Es ist so schwer, den Anfang zu finden. Oder besser: Es ist schwer, am Anfang anzufangen. Und nicht zu versuchen, weiter zur¨ uckzugehen. Appendix Chapter A on page 162 Knowledge in modern economies is increasingly playing a key role in achieving organizational success. Knowledge management as a concept and a scientific discipline emerged to acknowledge this fact. Three main reasons can be identified for this development [Siv01]. 1) Need: Today’s information technologyenabled 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 knowledge [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 organization’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 according 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 infrastructures. Among them, the following two are especially relevant in the context 1
carried out in 2001/2002 by the Fraunhofer Competence Center Knowledge Management, Berlin and the Institute for Psychology of the Humboldt-University, Berlin [MHV03, chapter 8]
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 focussing 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 business processes, especially focussing on interactions between them [ISO00c, section 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 targeting 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 standards (such as [ISO00b]) nor existing business process modeling techniques (such as [Sch96]) nor knowledge management approaches provide comprehensive concepts 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 configuration of KM technologies to specific business contexts. KM technology itself can today be classified according to different dimensions. The MT3 -Model introduced 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 2 3
KM...Knowledge Management MT...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 symbolizes the ability of computer systems, to generate new knowledge and autonomously perform appropriate actions based on the implicit input of data by users without burdening them. Arrow 4 describes that computer systems can generate knowledge about users by observing 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 systems 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 environment for knowledge workers in today’s organizations. On the other hand, knowl4
The 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 appropriate term “Knowledge Infrastructure”, which is not a term strongly (mis-)used by the software industry and better describes the anticipated concepts. 5 more 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 environments 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 business 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 development of business process-supportive, technological knowledge infrastructures for knowledge intensive organizations. What is meant by “Business Process-Supportive”? Business process support addresses two main aspects: 1) Employee-level : Here the term refers to role-oriented, technological support for knowledge workers in their daily 6
This need has already been identified by e.g. [Gia99, WC03] in the context of business processes 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 unconscious 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 automotive 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 requirements: 1. The application of the concept leads to knowledge infrastructure designs that improve environments of knowledge workers for their respective knowledge 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 organizations 3. The application of the concept leads to knowledge infrastructure designs that enable autonomous routing of knowledge from/to corresponding knowledge 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 organizations
CHAPTER 1. INTRODUCTION
27
5. The application of the concept leads to increased transparency of knowledge 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 knowledge intensive business processes that requires large amounts of relevant information 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 infrastructures 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 research 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 environment. 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 business 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 organizational 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, 7
Knowledge is regarded to be context sensitive, continuously reconstructed by subjects and thus, 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 relationship between 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, 8
Here, a necessary distinction between specific knowledge activities (on a knowledge object level [SAA+ 02]) and knowledge management activities (such as knowledge planning, identification or assessment - on a knowledge management level [SAA+ 02]) has been made. 9 with 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 includes software applications such as knowledge management-, document- or content management systems, intra- or extranets, file servers, data bases but also custom tailored systems. Approaches focussing on the development of knowledge 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 development (such as [SAA+ 02, Sin95]) can significantly contribute to the topic at hand.
2.1
The Knowledge Infrastructure Development 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 technological 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 1
not depicted in figure 2.1
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT
35
work. All of these aspects are described from a knowledge infrastructure development 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 management 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 organizations, this role is typically performed by one CKO who supervises various knowledge managers in his business unit [Mai02].
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT
2.2.2
36
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 investiga2
[SAA+ 02, p. 20] unfortunately use the term knowledge analyst interchangeably with the term knowledge engineer. Rooted in the domain of knowledge engineering, a knowledge engineer aims to elicit knowledge from experts to implement that knowledge in so-called knowledge based systems. Instead of replacing knowledge of experts, in this PhD work a knowledge analyst aims to analyze knowledge work of knowledge workers in order to support them by means of supportive 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 developed 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 infrastructures are typically not designed from scratch, a knowledge infrastructure designer either utilizes available COTS3 - or existing legacy systems. The knowledge 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, organizations 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 3
COTS...Commercial-Off-The-Shelf similar to what [FS01] define as the task layer (“Aufgabenebene”) of business information systems 4
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT
38
segmentations as well as a set of suggested modeling dimensions. In the context 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 infrastructure. Relevant requirements elicitation techniques [Mac96, Wer, KS98] in this context are JAD (Joint Application Design), CRC (Cooperative Requirements Capture), QFD (Quality Function Deployment), structured or unstructured 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 prioritization, 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 conceptual 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 templates 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 towards the development of systems. Although they are not directly related to knowledge infrastructure development, they give an overview of prominent approaches towards system development and are general enough to fuel understanding about different conceptualizations and applications in this domain.
CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT
2.4.1
40
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 development models (such as the waterfall model) and thereby provides a deeper understanding and more comprehensive guidance concerning system development processes. 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 development 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 Software that aims to provide guidance in software engineering processes. The main process elements are business modeling, requirements, analysis and design, implementation 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 process 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 development 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, 5
Multiple variants of the CASE acronym exist (also see [Sit02]). The most relevant in the context 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 development 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 environments [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 Informationssysteme” [Sin95, Sin97, FS01]) separates organizational systems into two basic task (“Aufgabenebene”) and task-carrier (“Aufgabentr¨agerebene”) 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 identified 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 interconnected 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 aspects 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 knowledge 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 conceptualizing the domain of knowledge infrastructure development and for further narrowing the focus of this PhD work. This PhD work focuses on providing support 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 introduced in section 2.4 indicate a current trend towards iterative approaches in system engineering. Especially during implementation phases an iterative approach 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 processsupportive knowledge infrastructures.
Chapter 3 Business Process Oriented Knowledge Management Ich m¨ochte 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 fr¨ uhen Taxonomien des Ulisse Aldrovandi aus dem 16. Jahrhundert, der die scheußlichen Tiere (die Spinnen, Molche und Schlagen) und die Sch¨onheiten (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 Management (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 section 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 1
Strategic aspects of business process oriented knowledge management are not explicitly mentioned in the depicted model in figure 3.1. The reason to that is because strategic considerations play an important role in each of the identified challenges. The importance of strategic considerations has been recognized by academia and comprehensive work regarding these 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 typically not covered in traditional business models. These analysis provide valuable insights for addressing the identified challenges depicted in figure 3.1.
3.4 3.4.1
Business Process Modeling 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 modeling 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 manifold: 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 separate 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 considered. 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. Remarkably, 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, Transfer and Application), a meta model for the integration of knowledge in business 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 CognoVision 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 3.5.1
Business Process Learning Challenges
Today’s training of employees in organizations usually takes place in a domainor 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 occurs 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 knowledge workers since available training is tailored to abstract fields of knowledge instead of concrete business problems. BpoKM approaches that focus on business 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 decrease 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] represents 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 transfer knowledge generated in business processes and 2) provide a business process oriented ICT2 infrastructure for enabling novice process agents to learn from colleague 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 (CoP3 s) and organizational aspects of learning.
3.6 3.6.1
Business Process Support Challenges
Supporting knowledge workers in executing their business process tasks is a rather complex undertaking. Knowledge workers are highly dependent on business process specific, task-oriented and action-relevant information. In today’s organizations, knowledge workers are responsible for filtering this information from various sources within or outside their organizations and relating it to their corresponding 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 organizations. BpoKM approaches focusing on business process support aim to tackle 2 3
ICT...Information and Communication Technology COP...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 support typically provide knowledge workers with action relevant information, information 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 explicitly 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 relationships 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 (Gesch¨aftsProzess 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 3.7.1
Business Process Execution Challenges
Currently, the most prominent way of technologically enabling the execution of business processes is the utilization of formally available business process context 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 processes. 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 provide 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 technological interventions aligned to the concepts of WFMS).
3.7.2
Benefits
Traditional WFMS typically aid organizations in the traceable execution of business processes across multiple business process instances and multiple participating process agents [Hol95]. BpoKM approaches that focus on business process execution aid process agents in executing their assigned tasks. Thereby, organizations 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
4
existing WFMS to an OMIS . 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 4
OMIS...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 revealed 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 supporting process agents in executing their business process tasks. Beneath a methodological approach, DECOR employs a WFMS and enriches traditional workflow models with information needs models of process agents as a basis for supporting 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 3.8.1
Business Process Improvement Challenges
BPR5 is a prominent and often utilized approach for improving business processes of organizations although it represents a rather radical way of achieving improvements. Typically, BPR discards existing business process modeling efforts and designs new business process models from scratch. By taking knowledge implications of existing business process models into account, BPR would be able to better anticipate future knowledge interactions between newly developed business 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 5 6
BPR...Business Process Re-engineering CPI...Continuous Process Improvement
CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT59 processes in terms of fulfilling their respective business process performance indicators. CPI in the past proved itself successful for improving selective sequences of work in organizations. The improvement of complex networks of business processes (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 comprise noticeable improvement potentials. BpoKM approaches that focus on business process improvement are typically twofold: They either consider knowledge implications when redesigning business processes (focus on improving organizational 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 Manufacturing Strategies) GmbH and Fraunhofer IFF (Institut f¨ ur 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 GrOupware) [VA+ 02, DRA+ 03] represents an approach developed in a joint effort between Fraunhofer IESE (Institute for Experimental Software Engineering) and Fraunhofer AIS (Autonomous Intelligent Systems). This approach uses the concept 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 participate 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 important 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 knowledge 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 improving business 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 modeling of knowledge-intensive business processes as a necessary basis for the selection of KM interventions. Therefore, the enriched modeling of business 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 business 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 interventions 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 intensive 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 extending 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 structured 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 workflows) or [HTEN03] (a system for ad-hoc workflows). Since WFMS only represent a very specific part of knowledge infrastructures (mainly containing 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 improvements from a knowledge perspective. Noticeable improvements in business process performance were reported [DHB01]. Still, the identification of complex 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. 1
BMW...Bayrische Motoren Werke
64
While
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 organization’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 infrastructures. 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 subsequent 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 processes [ESR99] are typically weakly structured and therefore not capable of being a direct basis for the development of business process-supportive knowledge infrastructures. A commonly used approach to overcome these problems is to 2
also 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 knowledge 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 support 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 elements 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 system (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 specifications 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 instrument 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 exemplary 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 relevance 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 relationships between knowledge suppliers and enquirers. By identifying such relationships, communication channels that are considered to be essential in organizational value chains become visible. Specific Knowledge Activities: Specific knowledge activities (like the generation, 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 management 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 Infrastructures Following this Principle Approach
Knowledge infrastructures that were implemented based on the principle approach introduced here typically support knowledge processes that span multiple 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 organization’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 infrastructures (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 Framework. It aids knowledge analysts on an operative level in building models about organizations and knowledge infrastructure designers in designing appropriate 3
B-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 assumptions 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 directives 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 subsequent 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 aspects (section 1.2.1) of business process-supportive, technological knowledge infrastructures on top of knowledge process models of organizations. The B-KIDE Method guides knowledge infrastructure designers through the process of designing 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 oriented interviews with employees of a target organization, the tool supports knowledge 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 processsupportive 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 BKIDE Method for designing business process-supportive knowledge infrastructures are introduced. Whenever appropriate, the UML1 , a sophisticated, objectoriented modeling language is utilized to structure and conceptualize the framework 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 BKIDE 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. 1
UML...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 operatively 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 considered. 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 organizational 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 organizational 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 2
SER...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 technique (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 knowledge 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 environment 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 application) 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 tics, random stimuli, assumption smashing, etc.)
80 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 Processes 3 and comprises explicit knowledge of a Knowledge Domain. The attribute Locality contains a geographical 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 Processes 4 .
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 3
To reduce complexity in figure 5.3, these relationships are not depicted there. More details can be found in section 6.3 4 Again, for the same reason, these relationships are not depicted in figure 5.3. More details can 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 Storage 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 others 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 hierarchically5 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, business processes, etc.) in models of organizational work. This is considered to be a critical factor for validation of developed models [KS98]. Here, reference mod5
In certain cases (e.g. extensively complex business process landscapes) more sophisticated structures than hierarchical ones may be necessary. Topic maps [Pep00, Top01] represent a concept that is well equipped for modeling such complex structures and can, if necessary, be integrated 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 represent 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 reference model structures existing knowledge storage possibilities, the transfer object reference model structures existing knowledge transferring instruments and mechanisms 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 hierarchical 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 processes. 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 Diagram
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 Business
Central Structuring
Purpose
Element Process
Business Processes
Perspective
Basis for the Creation and Validation of the Model
Knowledge Process
Knowledge Domains
Perspective
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 6
The introduced UML diagrams of model perspectives in this section define how the model perspectives need to be structured in order to fulfill their respective tasks. They depict a specific processing result achieved through transformation operations performed on the modeling structure in figure 5.3. Thus, the UML diagrams themselves do not contain information about transformation 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 principles 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 organization. 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 analyst 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 organizational 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 scheduled 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 existing organizational documentation can be utilized for this purpose. Although no business analogy for generation, storage, transfer and application object reference 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 setting 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 interviews 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 expertise 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 interview (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 knowledge 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 knowledge domains. During the development of knowledge infrastructure designs, these descriptions will help knowledge infrastructure designers in gaining a better understanding about the object system.
5.4
B-KIDE Method
The B-KIDE Method introduces a normative design process Designing Knowledge Infrastructures that leads KI designers through necessary design activities. In addition, a knowledge infrastructure template architecture acts as a fundament 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 knowledge infrastructure template architecture in UML (see figure 5.9 on page 96), while Designing Knowledge Infrastructures is described by a normative design 7
Aspects of validation include checks for 1) self consistency, 2) uniqueness of model elements and 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 Infrastructures”
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 process 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 management 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 comprehensive support for knowledge intensive business processes. To specify these requirements, the knowledge infrastructure designer uses the identified as-is knowledge processes and, together with knowledge workers and representatives of the management, 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 specification.” (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 8
This decision may already be made in section 5.3.2. Nevertheless, at this point, the decision may 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 appropriate in the context of each organization has to be determined while at the same time taking framing conditions such as financial, organizational or technological 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 Portals [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. 9
Here, knowledge infrastructure design is understood as a product; e.g. a design document that marks out the form of the final solution. 10 While the fit criteria introduced here apply well to designing technological aspects of knowledge infrastructures, other fit criteria (such as [Kun02, chapter 3]) may be adopted when it comes 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 activities) 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 Knowledge Process Landscape. Taking a role-perspective on knowledge work allows KI designers to understand what contents and functionality of a knowledge infrastructure 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 infrastructure development projects prescribes what needs to be implemented in the targeted knowledge infrastructure designs (in the sense of functional requirements in order to support the defined knowledge processes), but not how this functionality is provided.
5.4.2
B-KIDE Knowledge Infrastructure Template Architecture
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) Contents 2) Taxonomies and Meta Knowledge11 and 3) Access. Based on identified knowledge processes in organizations, the knowledge infrastructure template architecture 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 infrastructure (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 categories, 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. 11
Both taxonomies and meta knowledge represent concepts for knowledge organization and therefore 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 infrastructure 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 developed 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 technological knowledge infrastructures. Such instruments can utilize hierarchical tree or list navigation, catalogues (such as [Net04]), retrieval systems, complex visualizations (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 respective knowledge work. Standards for the formalization of access concepts already exist and are available for application (such as [Ame03]).
CHAPTER 5. B-KIDE FRAMEWORK
5.5
97
Remarks on B-KIDE Framework Application
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 oriented 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 organization [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 functionalities (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 organization. The B-KIDE Tool introduced in this chapter aims to provide software functionality that is able to map interview data gathered from structured, process 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 infrastructure 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 environment. 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. Therefore, 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 investigations, and by applying the accompanying B-KIDE Method, Arthur is able to lay out the design of a technological knowledge infrastructure 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 processoriented 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, provide 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 BKIDE 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 interviews 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, 1
The Generation and Application Reference Models were not implemented in the B-KIDE Tool 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
6.3
104
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 Structure are implemented in the B-KIDE Tool Reference Models area depicted in figure 6.5. While each reference model is hierarchically organized, specific reference 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 activities. 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. 2
the so-called “Business Process-Roles Assignment” - also see appendix chapter C
CHAPTER 6. B-KIDE TOOL
6.3.2
105
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 specific 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 corresponding 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
6.4
106
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 Organizational Roles Reference Model (based on e.g. an existing organigram) represent 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 interviewee 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. 3
In prose, this relation can be described in the following way: In Business Process “Acquisition”, knowledge about customers is applied by the organizational role “sales agent”.
CHAPTER 6. B-KIDE TOOL
6.4.3
110
Analysis
The B-KIDE Tool supports the generation of two main, configurable analysis reports: 1) the Business Process Landscape and 2) the Knowledge Process Landscape. Both analysis reports build on the model perspectives which were introduced 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 infrastructure designers in generating analysis reports on top of gathered interview data. These reports can be filtered according to specific interviews, organizational 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 detailed 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 Perspective 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 “Acqui4
This screenshot was graphically revised in order to increase comprehensibility of the concepts 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 5
This screenshot was graphically revised in order to increase comprehensibility of the concepts 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 provides 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 questions 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 manifold 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 depicted 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 features 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 Mic [Micc], the identified knowledge processes (generated through the crosoft Visio Knowledge Process Landscape analysis report) themselves can become the basis for the definition of to-be knowledge processes.
6.6
B-KIDE Tool Implementation
c The B-KIDE Tool implementation is based on Microsoft’s .NET Framework [Micb] and the programming language VB.NET utilizing an object-oriented application 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, systems, and devices” [Micd].
Figure 6.16: Technological Fundament of the B-KIDE Tool: The .NET Framework [Mica] The .NET Framework is based on a platform independent fundament, a socalled 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 “crosslanguage 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 6
In 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 illustrative 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 repository. 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
c [Ado]). Because (such as HTML browsers that installed Adobe’s SVG Plugin these analysis reports are based on XML and the vector-based graphics format SVG, generated reports can easily be transformed to other formats with technologies such as XSLT or can be graphically revised with existing graphical software c [Micc]). More details about the B-KIDE applications (such as Microsoft Visio 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 development of business process-supportive, technological knowledge infrastructures for knowledge intensive organizations [page 26]. 1
also 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
Software
Automotive indus-
Consulting
Context
try,
indus-
ISO9001:2000 try, formally defined
certified Project
Knowledge
Goals
design
portal
Hypothesis B-KIDE Framework
indus-
try, weakly designed
business processes
business processes
EDM system im-
Intranet
provement
ment
improve-
B-KIDE Framework and B-KIDE Tool
tested Framework Design
Evaluation
Design
Application Project
Design
Results
knowledge portals
Study
of
four
EDM
system
Design of a KI to
improvement poten-
support the acquisi-
tials
tion process
Explorative
Justificative
Justificative
The author
A 3rd person
A 3rd person
Style Primary Actor Evaluation
PhD objectives
concerning 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 7.2.1
Case Study 1: Software Industry 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 continuously 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 generating 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 infrastructure, 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 company A as well, but not a strict requirement for this case study.
CHAPTER 7. PROOF OF CONCEPT
7.2.3
120
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 2
At the time of conducting this case study, the B-KIDE Tool was not yet available and therefore, the modeling and analysis activities were performed semi-automatically by utilizing c Microsoft’s standard software Excel .
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 c template depicted in figure E.1 on page analyst used the Microsoft Excel 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 knowledge 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 knowledge 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 3
This 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 organizational 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 infrastructure. Four organizational roles are supported in their respective knowledge processes while support for one role (MD) was discarded. The scope demarcation 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 4
especially the lack of available metadata assigned to documents, necessary for enhanced personalization 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 architecture (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 included 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 knowledge 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 identified organizational role, a supportive knowledge portal was developed. The knowledge portals represent role specific perspectives on the organization’s knowledge infrastructure. The portals are interconnected to each other through the knowledge 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 BKIDE 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 7.3.1
Pilot Study 1: Automotive Industry 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 understanding about the department’s main processes and activities. Concerning technological equipment, engineers in their respective business processes are supported 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
7.3.2
127
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) technologically supporting knowledge interactions between the business process product development and related business processes by leveraging the existing EDM system 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 utilized 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 pilot, 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 interviews: 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 interviewees’ 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 restrictions 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 interviews 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 improvement 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 infrastructure could be evaluated concerning the generation of improvement potentials. 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 representatives 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 efforts. 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 personal 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 meeting 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 knowledge infrastructure. • The transfer of knowledge shall be supported to the extent described within the defined knowledge processes by the anticipated knowledge infrastructure. • 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 evaluation 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 allowed for detailed investigations of the existing knowledge infrastructure (the EDM system) of company B. Not only could the role of company B’s EDM system 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 improvement 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 7.4.1
Pilot Study 2: Consulting Industry Context
Pilot study 2 was performed in cooperation with a consulting company C, providing consulting services in the domains of organizational development, information technology and engineering, with about 30 employees. Company C has a conceptualization 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 consists of six main business processes that depict the most critical processes of company C. Employees share a moderate common understanding about the execution 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
7.4.2
133
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 corresponding 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) provide 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, appropriate 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 toolsupported, 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 meetings. 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). 5
with the exception of one interview only lasting 30 minutes because of time restrictions imposed by the interviewee
CHAPTER 7. PROOF OF CONCEPT
135
Model System Refinement: The knowledge analyst refined gathered interview 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 technological 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 technological 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 process 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 design 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 defining 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 generation 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 implement 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 infrastructure 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 knowledge 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 knowledge interactions between the acquisition business process and related business processes. Also, the defined knowledge processes illustratively reveal that usage 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 7.5.1
Lessons Learned B-KIDE Framework
The application of the B-KIDE Framework in the three conducted studies generated valuable feedback for framework improvements. One issue that emerged from applying the B-KIDE Framework to real-world scenarios was the introduction 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 criteria 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 infrastructure 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 process 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 interviewed 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 BKIDE 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 knowledge analysts. However, users needed some amount of training to be able to appropriately apply the B-KIDE Tool. Therefore, interview guidelines for knowledge 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 enhance 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 functionality that was suggested by knowledge analysts includes a software feature that dynamically fades in the current status of knowledge processes. Another improvement 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. 6
such as software development business processes vs. e.g. generic project management processes
CHAPTER 7. PROOF OF CONCEPT
7.6
141
Assessment
In this section, the B-KIDE Framework is assessed in the light of the three conducted 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 improve 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 processes and 3) ensure support for knowledge processes in improved knowledge infrastructures through the concept of fit criteria. Pilot study 1 (EDM system 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 enable role oriented access to knowledge for knowledge workers in organizations The B-KIDE model architecture allows for performing role-oriented analyses (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, roleoriented 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 development projects by applying the B-KIDE Framework. 3. The concept leads to knowledge infrastructure designs that enable autonomous routing of knowledge from/to corresponding knowledge 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 criteria 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 provided. 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 enforce 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 knowledge 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. Therefore, 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 imperative 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 reasonable amount of time, the complementary B-KIDE Tool allows for the effective application of the B-KIDE Framework as demonstrated in two industrial pilot studies. The B-KIDE Tool achieves that by implementing the B-KIDE Modeling Structure. Thereby, it eases the application and reduces 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 indicators 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 domains. • 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 BKIDE 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, 7
The descriptive power of knowledge processes was introduced in detail in section 4.3.3 on page 70
CHAPTER 7. PROOF OF CONCEPT
144
all three studies focused on areas where the knowledge domains investigated where considered to be on a very concrete level, within clearly defined 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 provided (section 5.4.1). Often, organizational knowledge infrastructures are based on available software (so-called COTS products) such as [Hyp, Liv, Lot]. Therefore, in order to be implementable, the developed, vendor-independent knowledge infrastructure designs need to be mapped on concrete, vendor-specific system designs. 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 significantly increasing accuracy of the developed knowledge infrastructure designs and reducing work burden for system designers. 145
CHAPTER 8. FUTURE WORK
8.2
146
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 Framework 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 selfoptimization 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 1
Attributed to the highest maturity level 5 (Optimizing) of the Knowledge Process Quality Model (KPQM) [PP02, OP03] 2 However, 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 Maturity Stage
Description
1 - Initial
The quality of knowledge processes is not
147
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 ensure 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
To enhance the systematic process management,
Managed
measures of performance are used to plan and track processes.
5 - Optimizing
The focus of this stage is on establishing structures for continuous improvement and selfoptimization.
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 decoupled 3 . 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 application can be brought together (not necessarily physically), thereby redesign3
Reasons for such situations may lie in technological systems that implement and encapsulate the transfer and routing of knowledge or dedicated organizational roles (such as knowledge brokers) who explicitly focus on knowledge transfer and thereby potentially decouple knowledge generators and appliers. 4 through 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 necessary to gain a deeper understanding about factors promoting the appearance of decoupled knowledge processes and to develop effective countermeasures. The BKIDE 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 selective oblivion respectively deletion of knowledge in organizational memories (on individual, organizational and/or technological levels) represents a pressing challenge 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, important 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 increasingly 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 infrastructures 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. organizational 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 Infrastructures 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 management system may cause severe adaptations to an organization’s business processes (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 influence 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. 5
By understanding the B-KIDE Framework as a network of
First work concerning this question already exists [GPSW03]. However, the applicability of 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 Framework 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 6 7
The B-KIDE Method and the B-KIDE Modeling Technique represent such processes such 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 BKIDE 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 BKIDE Methods The B-KIDE Framework together with the B-KIDE Tool increases transparency 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 participation (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 depicted 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, businessrelevant 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 Framework
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 identification 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 reduce 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 businesscritical knowledge risks may emerge.
9.3
Raising KM Maturity Levels of Organizations
The identification, support, management and improvement of knowledge processes is of especial relevance in the context of knowledge management maturity models. Existing maturity models1 build on an assessment of the quality of 1
such 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 organizations. 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 . Therefore, 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 organization’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 organizations, but span different organizations e.g. along a supply chain or within distributed value generating networks. In such settings, the appropriate management of knowledge is even more crucial and also harder to achieve because of e.g. competitive situations, geographically dispersed actors, varying organizational cultures, -languages or -vocabulary. Here, initiatives (such as cluster, B2B3 2 3
also see table 8.1 on page 148 B2B...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 formal 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 domain partly integrates the concept of ontologies into existing approaches for the implementation of technological knowledge infrastructures [KHS03]. In organizational 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 organizations (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 Th¨atigkeit 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 perspective (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 knowledge 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 corresponding knowledge workers in a traceable and repeatable way. Thereby, it ensures quality and reduces arbitrariness of the developed knowledge infrastructure designs across various application domains. The B-KIDE Framework 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 knowledge workers. The introduced concept of knowledge processes allows for 1
These two were the studies where the B-KIDE Method was applied in a design (vs. evaluation) 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 knowledge 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 integrative concept, which connects knowledge requirements of business processes to technological KM functionality, the B-KIDE Framework significantly 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 organizational knowledge work. Analyzing complex, combined social and technological systems such as organizations is not typically accomplished through direct interventions in the system, but indirectly through appropriate models of the system in question [FS01]. The B-KIDE Framework introduces a model architecture for modeling organizational knowledge work that specifies model elements, relationships, rules and semantics and thus enables modelers to check structural and behavioral consistency as well as completeness of their models. The innovative B-KIDE Tool represents an implementation 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 knowledge 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 application of the B-KIDE Framework in knowledge infrastructure development projects enables organizations to raise their knowledge management maturity level and to significantly increase their ability to appropriately deal with the critical resource knowledge.
CHAPTER 10. CONCLUSIONS
10.3
160
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 knowledge 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 relevance for future research. This PhD work lays a sound fundament for the development 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 knowledge in an effective and efficient way.
Appendix A Quotes Although providing the source of quotes gives important context for understanding 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 zur¨ uckzugehen. Ludwig Wittgenstein, On Certainty, §471 Chapter 2 Objectivity is a subject’s delusion that observing can be done without him. Heinz von F¨orster, Einf¨ uhrung in den Konstruktivismus, Page 31 Chapter 3 Ich m¨ochte 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 fr¨ uhen 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 Sch¨onheiten (die Leoparden, die Adler usw.) zu eigenen Gruppen [von Lebewesen] zusammenfasste. Heinz von Foerster, Wahrheit ist die Erfindung eines L¨ ugners, 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 Poincar´e 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 Th¨atigkeit 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 F¨orster et al, Einf¨ uhrung 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 fundament 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 illustrated. While figure B.1 visualizes the way research was performed in this PhD 1
It is important to point out the two different usages of the term design here: The first usage refers to designing a theoretical construct (a theory) about the process of conceptualizing business 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 process 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 employed 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 criteria 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 represents 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 evaluation. 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 organization 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 intervention [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 execution 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 - Advanced 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 perspective 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 involved 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 activities:
APPENDIX C. SUPPORTING RESOURCES
171
Introduction • The analyst introduces himself to the interviewee. • The analyst introduces the background, objectives and benefits of the BKIDE 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 information 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 interviewee. 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 interviewees 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 interviewee gives his answers from the appropriate perspective (role).” Rule 4 “Before creating a new reference element, check existing reference 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
C.2
173
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
Figure D.5: Property-Form for the Reference Element “Storage Object”
Figure D.6: Property-Form for the Reference Element “Transfer Object”
176
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
c Interview Template Applied in Case Study 1 Figure E.1: Microsoft Excel c interview template that was applied Figure E.1 depicts the Microsoft Excel 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 knowledge 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 Corresponding 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
E.2
184
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 company 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
E.3
186
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. M¨ uller.
Gesch¨aftsprozess-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. Papvassiliou. Business-Process Oriented Delivery of Knowledge through Domain Ontologies. In Proceedings of DEXA conference, TAKMA2001, Second International Workshop on Theory and Applications of Knowledge Management, 2001.
[Ass02]
Association for Computing Machinery. ACM Computing Classification System, 2002.
[BB98]
P.O. Bengtsson and J. Bosch. Scenario-Based Software Architecture 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 [BM04]
190
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 Patterns. Wiley, 1996. [Boe88]
B. W. Boehm. A Spiral Model of Software Development and Enhancement. 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 Management in der Praxis - Prozessorientierte L¨osungen zwischen Knowledge 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 International Conference on Space Mission Challenges for Information Technology (SMC-IT), 2003.
BIBLIOGRAPHY [DHB01]
191
I. D¨ammig, U. Hess, and C. Borgmann. Wissenstransparenz als Wettbewerbsvorteil - 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. Situated Knowledge Management - KM on the Borderline Between chaos and Rigidity. In Proceedings of PAKM 2000 - Conference on Practical 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 Element Set (Draft), 02 2003.
[Dus02]
S. Dustdar. Collaborative Knowledge Flow - Improving ProcessAwareness and Traceability of Work Activities. In Proceedings of the Fourth International Conference on Practical Aspects of Knowledge Management (PAKM2002), 2002.
[Eng03]
W. Engelbach.
Vorgebaute Informationsr¨aume f¨ ur Information-
srecherchestrategien in wissensintensiven Gesch¨aftsprozessen.
In
U. Reimer, A. Abecker, S. Staab, and G. Stumme, editors, WM 2003, Professionelles Wissensmanagement - Erfahrungen und Visionen, Luzern, 2003.
BIBLIOGRAPHY [ESR99]
192
M. J. Eppler, P. M. Seifried, and A. R¨opnack. Improving Knowledge 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 Incremental 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 Einf¨ uhrung 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 Business Processes and Information Systems. Communications of the Association for Information Systems, 1, 1999.
[Goe02]
T. Goesmann.
Ein Ansatz zur Unterst¨ utzung wissensinten-
siver Prozesse durch Workflow-Management-Systeme. PhD thesis, Fakult¨at IV - Elektrotechnik und Informatik der technischen Universit¨at Berlin, Berlin, Deutschland, 2002. [GPSW03] N. Gronau, U. Palmer, K. Schulte, and T. Winkler. Modellierung von wissensintensiven Gesch¨aftsprozessen mit der Beschreibungssprache K-Modeler. In U. Reimer, A. Abecker, S. Staab, and G. Stumme, editors, 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 [Gro03]
193
SVG Working Group. Scalable Vector Graphics (SVG) 1.1 Specification. Technical report, W3C - World Wide Web Consortium, 2003.
[Gua98]
N. Guarino. Formal Ontology and Information Systems. In Proceedings 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 Unterst¨ utzung des wissenschaftlichen Forschungsprozesses. Master’s thesis, Wirtschaftswissenschaftliche Fakult¨at der Universit¨at Regensburg, Regensburg, Deutschland, 2002. [Hei01]
P. Heisig.
Business Process oriented Knowledge Management -
Methode zur Verkn¨ upfung von Wissensmanagement und Gesch¨aftsprozessgestaltung. In Proceedings of WM2001, 1. Konferenz Professionelles 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 Gesch¨aftsprozessorientiertes 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 Information 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 Coalition, Jan 1995.
BIBLIOGRAPHY [HTEN03]
194
C. Huth, N. Tas, I. Erdmann, and L. Nastansky. GroupProcess Web: Graphisch interaktives Management von Ad-hoc-Gesch¨aftsprozessen im Web. In U. Reimer, A. Abecker, S. Staab, and G. Stumme, editors, 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. Qualit¨atsmanagementsysteme: Anforderungen (ISO 9001:2000), Dezember 2000.
[ISO00b]
ISO - International Organisation for Standardization. Qualit¨atsmanagementsysteme: Grundlagen und Begriffe (ISO 9000:2000), Dezember 2000.
[ISO00c]
ISO - International Organisation for Standardization. Qualit¨atsmanagementsysteme:
Leitfaden zur Leistungsverbesserung (ISO
9004:2000), Dezember 2000.
BIBLIOGRAPHY [Jan00]
195
C. Jansen. Prozessunterst¨ utzung durch Wissensplattformen. PhD thesis, Universit¨at St. Gallen, Hochschule f¨ ur Wirtschafts-, Rechtsund Sozialwissenschaften (HSG), St. Gallen, Schweiz, 2000.
[JHS01]
S. Jablonski, S. Horn, and M. Schlundt. Process Oriented Knowledge Management. In Eleventh International Workshop on Research Issues in Data Engineering: Document Management for Data Intensive Business and Scientific Applications, Heidelberg, Germany, pages 77–84. IEEE Computer Society, 2001.
[Kan03]
D. Kandpal. Augmenting Knowledge-Intensive Systems with Dynamic 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, Hierarchically Structured Knowledge Spaces. In Proceedings der GI Workshopwoche 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 Proceedings of PAKM 2000 - Conference on Practical Aspects of Knowledge Management, pages 13–1–13–7, 2000.
BIBLIOGRAPHY [Kun02]
196
S. Kundermann. sensprozessen.
Ans¨atze zur Qualit¨atsverbesserung von WisMaster’s thesis,
Johann Wolfgang Goethe-
Universit¨at, Lehrstuhl f¨ ur Entwicklung betrieblicher Informationssysteme, 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 M¨ unchen Wien, 2000.
[Leh02]
F. Lehner. Informationsbrosch¨ ure des Lehrstuhls: TEIL W - Wissensmanagement und Prozeßmanagement. Technical report, Universit¨at Regensburg, Mai 2002.
[Lin98]
S.N. Lindstaedt. Group Memories: A Knowledge Medium for Communities 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. Rollett. Integration von Prozess- und Wissensmanagement-orientierten Designstrategien zur Erstellung benutzerfreundlicher Unternehmensportale. In U. Reimer, A. Abecker, S. Staab, and G. Stumme, editors, WM 2003, Professionelles Wissensmanagement - Erfahrungen und Visionen, Luzern, 2003.
BIBLIOGRAPHY [Mac96]
197
L. Macaulay. Requirements for Requirements Engineering Techniques. In 2nd International Conference on Requirements Engineering (ICRE ’96), 1996.
[Mac97]
M.S. MacNealy. Toward Better Case Study Research. IEEE Transactions 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 Analysis 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 [MR01]
198
R. Maier and U. Remus. Towards a Framework for Knowledge Management Strategies: Process Orientation as Strategic Starting Point. In Proceedings of the 34th Hawaii International Conference on System Sciences, 2001.
[MR02]
R. Maier and U. Remus. Defining Process-oriented Knowledge Management Strategies. Knowledge and Process Management, 9(2):103– 118, 2002.
[MR03]
R. Maier and U. Remus. Implementing Process-Oriented Knowledge 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, Unternehmen 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 Discovery, 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 report, HBI Stuttgart, 2000.
[Noh02]
H. Nohr. Strategie- und Gesch¨aftsprozessorientiertes Wissensmanagement. Technical report, Hochschule der Medien, Studiengang Informationswirtschaft, 2002.
BIBLIOGRAPHY [NT97]
I. Nonaka and H. Takeuchi.
199 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 Qualit¨atsverbesserung 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 Proceedings 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 Knowledge 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. Managing Knowledge in Weakly-Structured Administrative Processes. In Proceedings of The Third European Conference on Organizational Knowledge, Learning, and Capabilities - OKLC 2002, Athens, Greece, April 2002. [PP02]
O. Paulzen and P. Perc. A Maturity Model for Quality Improvement in Knowledge Management. In A. Wenn, M. McGrath, and F. Burstein, editors, Enabling Organisations and Society through Information 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 Processes 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 Unternehmen ihre wertvollste Ressource optimal nutzen. Dr. Th. Gabler Verlag, 1998.
[Rem01]
U. Remus. Integrierte Prozeß- und Kommunikationsmodellierung als Ausgangspunkt f¨ ur die Verbesserung von wissensintensiven Gesch¨aftsprozessen. In Proceedings of WM2001, 1. Konferenz Professionelles Wissensmanagement, Baden - Baden, 2001.
[Rem02]
U. Remus. Prozeßorientiertes Wissensmanagement - Konzepte und Modellierung. PhD thesis, Wirtschaftswissenschaftliche Fakult¨at der Universit¨at 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 Management 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 KnowledgeBased System to Support Business Processes. Knowledge-Based Systems, 13(5):261–269, 2000.
BIBLIOGRAPHY [Rol03]
201
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 Development and Management. Giga Information Group, January, 8th 2003.
[RZ96]
D. Riehle and H. Z¨ ullighoven. 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. Shadbolt, 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. Ans¨atze zur fachlichen Modellierung betrieblicher Informationssysteme - Entwicklung, Aktueller Stand und Trends. Bamberger Beitr¨age zur Wirtschaftsinformatik, 34, 1995.
[Sin97]
E. Sinz. Architektur betrieblicher Informationssysteme. Bamberger Beitr¨age zur Wirtschaftsinformatik, 40, 1997.
[Sit02]
A.A. Sitiol. CASE Technology. In 2002 Student Conference on Research and Development, Shah Alam, Malaysia, 2002.
[Siv99]
Y.Y. Sivan. Launching a Knowledge Infrastructure: How to Jumpstart the Process. WebNet Journal, 1(4):16–19, October 1999.
BIBLIOGRAPHY [Siv01]
202
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 ADVISOR 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 Wissensmanagement), 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 Infrastructures. In Proceedings der GI Workshopwoche LLWA - Workshop der Fachgruppe FGWM (Fachgruppe Wissensmanagement), October 2003.
[TK02]
R. Telesko and D. Karagiannis. Process-based Knowledge Management: 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 Peter J. Nuernberg, editor, Metainformatics: International Symposium (MIS), Esbjerg, Denmark, 2002.
[Tol98]
J.-P. Tolvanen.
Incremental Method Engineering with Modeling
Tools. PhD thesis, University of Jyv¨askyl¨a, 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 [TPSS04]
203
C. Tempich, S. Pinto, S. Staab, and Y. Sure. A Case Study in Supporting Distributed, Loosely-Controlled and Evolving Engineering of Ontologies (DILIGENT). In Proceedings of I-Know’04 - 4th International 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 Systems. 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 Reengineering with Information Systems Development: Issues & Implications. 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 Management Systems Based on KM-Services: The PROMOTE Approach. 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 Wissensmanagement, 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 OrganizationalMemory-Based Approach for an Evolutionary Workflow Management 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. PrenticeHall, 1979.
[You89]
E. Yourdon. Modern Structured Analysis. Prentice-Hall, 1989.
Index .NET framework, 113
BKM, 53 Business process, 78
Access, 96
Business process analysis, 48
ADVISOR, 51
Business process execution, 55, 61
Application object, 80
Business process improvement, 58, 62
Architecture, 64
Business process landscape, 110
ARIS, 49
Business process learning, 50, 61 Business process management, 30
B-KIDE context, 71, 72, 74
Business process modeling, 48, 61
design process, 90
Business process oriented knowledge management, 46
framework, 71, 72, 112, 117, 139,
Business process perspective, 83
145, 157, 160 framework application, 97
Business process re-engineering, 58
framework evolution, 149
Business process support, 52, 61
knowledge infrastructure tem-
case study, 117, 119
plate architecture, 94
CASE tools, 41
method, 71, 72, 89, 113, 122, 129,
Constructivism, 27
135, 158, 160
Contents, 95
model architecture, 71, 72, 76,
Continuous process improvement, 58
160
DECOR, 58
modeling structure, 77, 104, 105, 113
Decoupled knowledge processes, 146
modeling technique, 85, 112, 120,
EULE, 58
127 reference models, 81, 103, 104,
Fit criteria, 92, 124, 131, 138
106, 120, 128, 134 Generation object, 79
tool, 71, 72, 99, 140, 160
GPO-WM, 54
tool evolution, 150 205
INDEX
206
indiGO, 60
model, 54 Knowledge process definition, 91,
K-Modeler, 50
122, 129, 135
Knowledge, 30 Knowledge analysts, 36, 85, 99, 106, 107
Knowledge process quality model,
Knowledge domains, 31, 79
146, 154
Knowledge flows, 70 infrastructure
design
evaluation, 124, 131, 138 Knowledge infrastructure design validation, 94 Knowledge infrastructure designers, 37, 90, 99, 110 Knowledge infrastructure development project, 33 Knowledge infrastructures, 20, 26, 33, 70 Knowledge management, 20, 30 Knowledge management activities, 32 Knowledge management interventions, 30 Knowledge management maturity levels, 146, 154 Knowledge management strategies, 47, 155 Knowledge
Knowledge process optimization, 146 Knowledge process perspective, 84
Knowledge communities, 153
Knowledge
Knowledge process landscape, 111
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
management
system
functionality, 23
Oblivion, 148 Ontologies, 96, 156
Knowledge management technologies, 44
Organizational knowledge, 30 Organizational roles, 79
Knowledge management worker, 36
Organizations, 26, 29
Knowledge managers, 35 Knowledge
networks
reference
Pattern analysis, 43
INDEX
207
Patterns, 39 Personalization, 148 Pilot studies, 117, 126, 132 Pre-modeling, 87, 106, 120, 128, 134 Preliminary knowledge infrastructure 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 doctoral 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 process management, organizational development, business information systems and systems analysis and design.
208
