B-KIDE: A Framework and a Tool for Business...

PhD Thesis

B-KIDE: A Framework and a Tool for

Business Process Oriented Knowledge

Infrastructure Development

Markus B. Strohmaier

————————————–

Institute for Knowledge Management and Knowledge Visualization

Graz University of Technology, Austria

Head: Univ.-Prof. Dr. Klaus Tochtermann

In cooperation with Know-Center Graz

Evaluator: Univ.-Prof. Dr. Klaus Tochtermann

Supervisor: Univ.-Prof. Dr. Klaus Tochtermann

Second Reader: Univ.-Prof. Dr.Dr.h.c.mult. Hermann Maurer

Publisher: Shaker Verlag, January 2005. ISBN: 3-8322-3620-1

2

Preface

This PhD thesis1 comprises the key results of my intensive research performed

at the Know-Center Graz during the last years. Knowledge management as a sci-

entific domain has fascinated me since the very first time I encountered it. The

generation of new knowledge about knowledge management appeared to be both

a challenging and deeply satisfying task to me. My research was and is based

on the hypothesis that understanding knowledge as the critical factor in today’s

economy is key to achieving sustainable success for organizations. Therefore, the

Know-Center Graz, Austria’s competence center for knowledge based systems

and applications, represented a more than suitable environment for me to pursue

this PhD.

I would like to thank the people who contributed to and supported me in the

realization of this work: Klaus Tochtermann, my professor and advisor, devel-

oped a profound infrastructure and a creative environment for researchers at the

Know-Center. He was always available for critical and constructive discussions

about my ideas and concepts. I value your commitment to my research. Her-

mann Maurer, initiator of the Know-Center and my second reader, sparked off

my interest in research on knowledge infrastructures through the development of

the MT-Model for knowledge management systems (also see chapter 1). Stefanie

Lindstaedt, my division manager, gave me the opportunity and freedom to es-

tablish the domain of business process oriented knowledge management as a key

area of research at the Know-Center. All the people from the companies I have

1The document at hand represents a revised version of the PhD thesis completed by theauthor in December 2004.

conducted projects with always challenged my hypotheses and provided valuable

feedback. Thank you.

Johann Gotschl, and all participants of his philosophical circle for PhD stu-

dents, provided a deep source of inspiration and wisdom for my research as well

as for my life. Thank you.

The “Wissensmanagement Forum Graz”, and all members of this community

of motivated people, represented a dynamic and stimulating environment for me

that allowed for experimenting with ideas as well as with myself. Thank you.

Tobias Ley, Herwig Rollett, Peter Scheir and all other colleagues at the Know-

Center were always available for open-minded, thrilling and humorous discussions

about work, life and research. Thank you.

My parents, Gerda and Walter, taught me that curiosity is a quality. You

have always supported me in learning and advancing throughout my life. Thank

you.

And Pia - Thank you.

Graz, January 2005 Markus B. Strohmaier

4

Zusammenfassung (German abstract)

Die Notwendigkeit des effektiven Managements von Wissen wird heute von

Unternehmen zunehmend erkannt. Um diesem Anspruch gerecht zu werden,

wurden neue vielversprechende und umfassende Technologien von Wirtschaft

und Wissenschaft entwickelt. Mit der Verfugbarkeit und Weiterentwicklung

dieser Innovationen verstarkte sich auch die Bereitschaft von Unternehmen neue

Wissensmanagement-Technologien anzuwenden. Die erfolgreiche Anwendung in

Unternehmen stellt jedoch eine komplexe, mehrdimensionale Herausforderung

und ein aktuelles Forschungsgebiet dar. Die vorliegende Dissertation nimmt

sich deshalb diesem Thema an und stellt einen Framework fur die Entwicklung

von geschaftsprozessunterstutzenden, technologischen Wissensinfrastrukturen

vor. Wahrend dabei Geschaftsprozesse den organisatorischen Rahmen fur die

Anwendung von Wissensmanagement-Technologien bieten, so reprasentieren

Wissensinfrastrukturen ein Konzept, dass Wissensmanagement in Organisatio-

nen ermoglicht. Der in dieser Dissertation entwickelte B-KIDE Framework bietet

Unterstutzung in der Entwicklung von Wissensinfrastrukturen, welche innovative

Wissensmanagementfunktionalitaten beinhalten und sichtbar organisatorische

Geschaftsprozesse unterstutzen, an. Das entwickelte B-KIDE Tool erleichtert die

Anwendung des B-KIDE Frameworks fur Entwickler von Wissensinfrastrukturen.

Drei durchgefuhrte, empirische Studien mit Unternehmen unterschiedlichster

Branchen bekraftigen die Relevanz und Viabilitat der eingefuhrten Konzepte.

Schlusselworter: Wissensmanagement, Wissensinfrastrukturen, Geschaftspro-

zesse, Systemanalyse, Systemgestaltung, Entwicklungsinstrumente

5

Abstract

The need for an effective management of knowledge is gaining increasing

recognition in today’s economy. To acknowledge this fact, new promising and

powerful technologies have emerged from industrial and academic research.

With these innovations maturing, organizations are more and more willing to

adapt such new knowledge management technologies to improve their knowledge

intensive businesses. However, the successful application in given business

contexts is a complex, multidimensional challenge and a current research

topic. Therefore, this PhD thesis addresses this challenge and introduces a

framework for the development of business process-supportive, technological

knowledge infrastructures. While business processes represent the organizational

setting for the application of knowledge management technologies, knowledge

infrastructures represent a concept that can enable knowledge management

in organizations. The B-KIDE Framework introduced in this work provides

support for the development of knowledge infrastructures that comprise in-

novative knowledge management functionality and are visibly supportive of

an organization’s business processes. The developed B-KIDE Tool eases the

application of the B-KIDE Framework for knowledge infrastructure developers.

Three empirical studies that were conducted with industrial partners from

heterogeneous industry sectors corroborate the relevance and viability of the

introduced concepts.

Keywords: Knowledge Management, Knowledge Infrastructures, Business

Processes, System Analysis, System Design, Development Tools

Contents

1 Introduction 21

1.1 Research Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.1.1 Challenge 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.1.2 Challenge 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.1.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1.2 Focus of this PhD Work . . . . . . . . . . . . . . . . . . . . . . . 26

1.2.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.2.2 Demarcation . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.2.3 Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.3 PhD Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . 29

1.4 Terms and Definitions . . . . . . . . . . . . . . . . . . . . . . . . 30

2 Knowledge Infrastructure Development 34

2.1 The Knowledge Infrastructure Development Project . . . . . . . . 34

2.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.2.1 Knowledge Manager . . . . . . . . . . . . . . . . . . . . . 36

2.2.2 Project Manager . . . . . . . . . . . . . . . . . . . . . . . 37

2.2.3 Knowledge Worker . . . . . . . . . . . . . . . . . . . . . . 37

2.2.4 Knowledge Analyst . . . . . . . . . . . . . . . . . . . . . . 37

2.2.5 Knowledge Infrastructure Designer . . . . . . . . . . . . . 38

2.3 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.3.1 System Analysis . . . . . . . . . . . . . . . . . . . . . . . . 38

2.3.2 Requirements Engineering . . . . . . . . . . . . . . . . . . 39

2.3.3 System Design . . . . . . . . . . . . . . . . . . . . . . . . 39

2.3.4 System Usage . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.4 Process Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6

CONTENTS 7

2.4.1 Waterfall Model . . . . . . . . . . . . . . . . . . . . . . . . 41

2.4.2 Spiral Model . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.4.3 V-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.4.4 Rational Unified Process . . . . . . . . . . . . . . . . . . . 42

2.5 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.6 Relevant Scientific Domains . . . . . . . . . . . . . . . . . . . . . 43

2.7 Assessment in the Context of this Work . . . . . . . . . . . . . . . 45

3 Business Process Oriented Knowledge Management 47

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.2 Overview of Challenges and Approaches . . . . . . . . . . . . . . 48

3.3 Business Process Analysis . . . . . . . . . . . . . . . . . . . . . . 49

3.4 Business Process Modeling . . . . . . . . . . . . . . . . . . . . . . 49

3.4.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.4.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.4.3 Selected Approaches . . . . . . . . . . . . . . . . . . . . . 50

3.5 Business Process Learning . . . . . . . . . . . . . . . . . . . . . . 51

3.5.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.5.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52


3.6 Business Process Support . . . . . . . . . . . . . . . . . . . . . . 53

3.6.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.6.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54


3.7 Business Process Execution . . . . . . . . . . . . . . . . . . . . . 56

3.7.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.7.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57


3.8 Business Process Improvement . . . . . . . . . . . . . . . . . . . . 59

3.8.1 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.8.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60


3.9 Assessment in the Context of this Work . . . . . . . . . . . . . . . 61

3.10 Focal Point of this PhD Work . . . . . . . . . . . . . . . . . . . . 63

CONTENTS 8

4 Principle Approach 65

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4.2 Principle Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.3 Central Concept of Modeling Knowledge Processes . . . . . . . . 67

4.3.1 On Modeling Aspects of Organizations . . . . . . . . . . . 67

4.3.2 Illustration of Modeling Knowledge Processes . . . . . . . 68

4.3.3 Characteristics of Knowledge Processes . . . . . . . . . . . 70

4.4 Characteristics of Knowledge Infrastructures Following this Prin-

ciple Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

4.5 Conceptualization of this PhD Work . . . . . . . . . . . . . . . . 72

4.5.1 B-KIDE Context . . . . . . . . . . . . . . . . . . . . . . . 73

4.5.2 B-KIDE Model Architecture . . . . . . . . . . . . . . . . . 73

4.5.3 B-KIDE Method . . . . . . . . . . . . . . . . . . . . . . . 73

4.5.4 B-KIDE Tool . . . . . . . . . . . . . . . . . . . . . . . . . 73

5 B-KIDE Framework 75

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2 B-KIDE Context . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.2.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.2.2 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.2.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.2.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 77

5.2.5 Technological Environment . . . . . . . . . . . . . . . . . . 77

5.3 B-KIDE Model Architecture . . . . . . . . . . . . . . . . . . . . . 77

5.3.1 B-KIDE Modeling Structure . . . . . . . . . . . . . . . . . 78

5.3.2 B-KIDE Modeling Technique . . . . . . . . . . . . . . . . 86

5.4 B-KIDE Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

5.4.1 Design Process “Designing Knowledge Infrastructures” . . 91

5.4.2 B-KIDE Knowledge Infrastructure Template Architecture . 95

5.5 Remarks on B-KIDE Framework Application . . . . . . . . . . . . 98

6 B-KIDE Tool 100

6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

6.1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

CONTENTS 9

6.1.3 B-KIDE Tool Approach . . . . . . . . . . . . . . . . . . . 102

6.2 B-KIDE Tool Structure . . . . . . . . . . . . . . . . . . . . . . . . 103

6.3 B-KIDE Modeling Structure Mapping . . . . . . . . . . . . . . . . 105

6.3.1 Reference Models . . . . . . . . . . . . . . . . . . . . . . . 105

6.3.2 Interview Data . . . . . . . . . . . . . . . . . . . . . . . . 106

6.4 B-KIDE Tool Application . . . . . . . . . . . . . . . . . . . . . . 107

6.4.1 Setup and Pre-Modeling . . . . . . . . . . . . . . . . . . . 107

6.4.2 Interviewing . . . . . . . . . . . . . . . . . . . . . . . . . . 108

6.4.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

6.5 B-KIDE Tool Support for the B-KIDE Framework Application . . 113

6.6 B-KIDE Tool Implementation . . . . . . . . . . . . . . . . . . . . 114

7 Proof of Concept 118

7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

7.2 Case Study 1: Software Industry . . . . . . . . . . . . . . . . . . 120

7.2.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

7.2.2 Pursued Goals . . . . . . . . . . . . . . . . . . . . . . . . . 120

7.2.3 Approach Taken . . . . . . . . . . . . . . . . . . . . . . . 121

7.2.4 Achieved Results . . . . . . . . . . . . . . . . . . . . . . . 126

7.3 Pilot Study 1: Automotive Industry . . . . . . . . . . . . . . . . . 127

7.3.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

7.3.2 Pursued Goals . . . . . . . . . . . . . . . . . . . . . . . . . 128

7.3.3 Approach Taken . . . . . . . . . . . . . . . . . . . . . . . 128


7.4 Pilot Study 2: Consulting Industry . . . . . . . . . . . . . . . . . 133

7.4.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

7.4.2 Pursued Goals . . . . . . . . . . . . . . . . . . . . . . . . . 134

7.4.3 Approach Taken . . . . . . . . . . . . . . . . . . . . . . . 134


7.5 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

7.5.1 B-KIDE Framework . . . . . . . . . . . . . . . . . . . . . 140

7.5.2 B-KIDE Tool . . . . . . . . . . . . . . . . . . . . . . . . . 141

7.6 Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

CONTENTS 10

8 Future Work 146

8.1 On System Design and Implementation . . . . . . . . . . . . . . . 146

8.2 On Knowledge Process Optimization . . . . . . . . . . . . . . . . 147

8.3 On the Problem of Decoupled Knowledge Processes . . . . . . . . 147

8.4 On Oblivion of Knowledge . . . . . . . . . . . . . . . . . . . . . . 149

8.5 On Role-Orientation vs. Personalization . . . . . . . . . . . . . . 149

8.6 On Interactions between Knowledge Infrastructures and Business

Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

8.7 B-KIDE Framework Evolution Scenarios . . . . . . . . . . . . . . 150

8.8 B-KIDE Tool Evolution . . . . . . . . . . . . . . . . . . . . . . . 151

9 Future Applications 153

9.1 Identification of Knowledge Communities . . . . . . . . . . . . . . 154

9.2 Identification of Knowledge Risks . . . . . . . . . . . . . . . . . . 155

9.3 Raising KM Maturity Levels of Organizations . . . . . . . . . . . 155

9.4 Controlling of Knowledge-Based Strategies . . . . . . . . . . . . . 156

9.5 Enabling Intra-Organizational KM . . . . . . . . . . . . . . . . . 156

9.6 Ontology Engineering . . . . . . . . . . . . . . . . . . . . . . . . . 157

10 Conclusions 158

10.1 Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

10.2 Scientific Contributions . . . . . . . . . . . . . . . . . . . . . . . . 159

10.3 Final Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

A Quotes 162

B Research Approach 165

C Supporting Resources 169

C.1 Interview Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 169

C.1.1 B-KIDE Tool Preparation . . . . . . . . . . . . . . . . . . 169

C.1.2 Preparation for KI Analysts . . . . . . . . . . . . . . . . . 170

C.1.3 Preparation for Interviewees . . . . . . . . . . . . . . . . . 170

C.1.4 Documents necessary for Analysts . . . . . . . . . . . . . . 170

C.1.5 Documents necessary for Interviewees . . . . . . . . . . . . 171

C.1.6 Interview Setting . . . . . . . . . . . . . . . . . . . . . . . 171

CONTENTS 11

C.1.7 Interview Execution . . . . . . . . . . . . . . . . . . . . . 171

C.1.8 Interview Hints . . . . . . . . . . . . . . . . . . . . . . . . 173

C.2 Interview Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

D B-KIDE Tool Details 175

E Empirical Study Data 181

E.1 Case Study 1 - Software Industry . . . . . . . . . . . . . . . . . . 181

E.2 Pilot Study 1 - Automobile Industry . . . . . . . . . . . . . . . . 185

E.3 Pilot Study 2 - Consulting Industry . . . . . . . . . . . . . . . . . 187

Bibliography 190

Index 206

About the Author 209

List of Figures

1.1 Strategic Perspective on Knowledge Infrastructures (Based on

[Siv01]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.2 Networks of Business Processes . . . . . . . . . . . . . . . . . . . 23

1.3 The Maurer-Tochtermann (MT) Model . . . . . . . . . . . . . . . 24

1.4 Structure of this PhD Thesis . . . . . . . . . . . . . . . . . . . . . 30

1.5 Relationships between Key Terms of this PhD Work (Based on

[Rem02]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.1 Knowledge Infrastructure Development Projects (Based on

[SAA+02]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1 A Model of bpoKM Challenges . . . . . . . . . . . . . . . . . . . 48

4.1 The Principle Approach of this PhD Work . . . . . . . . . . . . . 66

4.2 Object and Model Systems (Based on [Sin95]) . . . . . . . . . . . 68

4.3 Modeling Knowledge Work of Business Processes (Based on [Str03a]) 69

4.4 Illustration of Resulting Knowledge Processes (Based on [Str03a]) 70

4.5 The B-KIDE Framework Conceptualization of this PhD Work . . 72

4.6 Focus of the B-KIDE Tool . . . . . . . . . . . . . . . . . . . . . . 74

5.1 Context of Applying the B-KIDE Framework and Tool (Based on

[Tol98]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.2 Scope of the B-KIDE Model Architecture . . . . . . . . . . . . . . 78

5.3 The B-KIDE Modeling Structure . . . . . . . . . . . . . . . . . . 79

5.4 The B-KIDE Business Process Perspective . . . . . . . . . . . . . 85

5.5 The B-KIDE Knowledge Process Perspective . . . . . . . . . . . . 86

5.6 The B-KIDE Modeling Technique . . . . . . . . . . . . . . . . . . 87

12

LIST OF FIGURES 13

5.7 Scope of the B-KIDE Method . . . . . . . . . . . . . . . . . . . . 91

5.8 Design Process “Designing Knowledge Infrastructures” . . . . . . 92

5.9 The Knowledge Infrastructure Template Architecture . . . . . . . 96

6.1 Scope of the B-KIDE Tool . . . . . . . . . . . . . . . . . . . . . . 101

6.2 Primary Actors of the B-KIDE Tool . . . . . . . . . . . . . . . . . 102

6.3 B-KIDE Tool Principle Approach . . . . . . . . . . . . . . . . . . 102

6.4 Simplified Illustration of B-KIDE Tool’s Main Structure and Ele-

ments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.5 Main User Interface of the B-KIDE Tool . . . . . . . . . . . . . . 104

6.6 Implementation of the B-KIDE Tool Reference Models . . . . . . 105

6.7 Implementation of the B-KIDE Tool Interview Forms . . . . . . . 106

6.8 Setting Up Interviews with the B-KIDE Tool . . . . . . . . . . . . 107

6.9 B-KIDE Tool’s Interview Forms per Interview . . . . . . . . . . . 108

6.10 Setting Up Reference Elements with the B-KIDE Tool . . . . . . 108

6.11 Inputting Interview Data with the B-KIDE Tool . . . . . . . . . . 109

6.12 Editing Reference Elements with the B-KIDE Tool . . . . . . . . 110

6.13 Creating Analysis Reports with the B-KIDE Tool . . . . . . . . . 111

6.14 The B-KIDE Tool Analysis Report “Business Process Landscape” 112

6.15 The B-KIDE Tool Analysis Report “Knowledge Process Landscape”113

6.16 Technological Fundament of the B-KIDE Tool: The .NET Frame-

work [Mica] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6.17 Architectural Sketch of the B-KIDE Tool . . . . . . . . . . . . . . 116

7.1 The Modeling Procedure Applied in Case Study 1 . . . . . . . . . 121

7.2 The Design Method Applied in Case Study 1 . . . . . . . . . . . . 123

7.3 A High Level Conceptualization of the Anticipated Support for

Knowledge Flows in Case Study 1 . . . . . . . . . . . . . . . . . . 124

7.4 An Example of Knowledge Process Definition in Case Study 1 . . 125

7.5 Case Study 1 Results: Four Role Oriented Knowledge Portals . . 127

7.6 The Modeling Procedure Applied in Pilot Study 1 . . . . . . . . . 128

7.7 The Evaluation Method Applied in Pilot Study 1 . . . . . . . . . 130


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


Knowledge Flows in Pilot Study 2 . . . . . . . . . . . . . . . . . . 137

7.13 An Example of Knowledge Process Definition in Pilot Study 2 . . 138

9.1 Applying B-KIDE in Diverse Domains by Developing Additional

B-KIDE Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

9.2 Identification of Knowledge Communities with the B-KIDE Frame-

work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

B.1 The Design Research Approach (Based on [VK04]) . . . . . . . . 166

C.1 The Interview Plan Template . . . . . . . . . . . . . . . . . . . . 174

D.1 Property-Form for the Reference Element “Knowledge Domain” . 175

D.2 Property-Form for the Reference Element “Business Process” . . . 176

D.3 Property-Form for the Reference Element “Organizational Role” . 176

D.4 Property-Form for “Knowledge Work” . . . . . . . . . . . . . . . 176

D.5 Property-Form for the Reference Element “Storage Object” . . . . 177

D.6 Property-Form for the Reference Element “Transfer Object” . . . 177

D.7 Setup Form for the Definition of Storage and Transfer Object Types178

D.8 Knowledge Process Landscape Generation with the B-KIDE Tool

(1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178


(2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179


(3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179


(4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

E.1 Microsoft Excel c©Interview Template Applied in Case Study 1 . . 181

E.2 Manually created Landscape of Identified Knowledge Processes . . 182

E.3 UI Mockup of a Knowledge Portal Fragment for Role TL and Cor-

responding Knowledge Processes (KP) . . . . . . . . . . . . . . . 184

E.4 B-KIDE-generated Knowledge Process Landscape . . . . . . . . . 185

LIST OF FIGURES 15

E.5 Landscape of Knowledge Processes Selected for Improvement . . . 186

E.6 B-KIDE-generated Knowledge Process Landscape . . . . . . . . . 187

E.7 Landscape of Knowledge Processes Selected and Defined for Support188

List of Tables

2.1 Aspects of Knowledge Infrastructure Development . . . . . . . . . 36

5.1 B-KIDE Reference Models and Business Analogies . . . . . . . . . 83

5.2 B-KIDE Model Perspectives . . . . . . . . . . . . . . . . . . . . . 84

5.3 B-KIDE Modeling Technique Activities . . . . . . . . . . . . . . . 87

7.1 Overview of Conducted Studies . . . . . . . . . . . . . . . . . . . 119

7.2 Scope Definition and Interview Planning in Case Study 1 . . . . . 122

7.3 KI Focus: Definition of Knowledge Processes to be Supported . . 123

7.4 Scope Definition and Interview Planning in Pilot Study 1 . . . . . 129


7.6 Scope Definition and Interview Planning in Pilot Study 2 . . . . . 135


8.1 Maturity Stages of the KPQM [PP02] . . . . . . . . . . . . . . . . 148

E.1 Example of a Role-Oriented Knowledge Profile Based on Identified

Knowledge Processes (KP) . . . . . . . . . . . . . . . . . . . . . . 183

E.2 Example of a Role-Oriented Knowledge Profile Based on Selected

Knowledge Processes (KP) . . . . . . . . . . . . . . . . . . . . . . 189

16

List of Acronyms

API Application Programming Interface

ARIS Architektur integrierter Informationssysteme

B-KIDE Business process oriented Knowledge Infrastructure Development

B2B Business to Business

bpoKM business process oriented Knowledge Management

BPR Business Process Re-engineering

CAME Computer Aided Methodology Engineering

CASE Computer Aided Software Engineering or Computer Aided System Engi-

neering

CKO Chief Knowledge Officer

CLR Common Language Runtime

CLS Common Language Specification

CoP Communities of Practice

COTS Commercial Off The Shelf

CPI Continuous Process Improvement

CRC Cooperative Requirements Capture

EDM Engineering Data Management

EU European Union

17

LIST OF TABLES 18

FAQ Frequently Asked Questions

HCI Human Computer Interaction

HTML Hypertext Markup Language

ICT Information and Communication Technology

IL Intermediate Language

ISO International Standardization Organization

IT Information Technology

JAD Joint Application Design

KI Knowledge Infrastructure

KM Knowledge Management

KMS Knowledge Management System

KPQM Knowledge Process Quality Model

LPP Legitimate Peripheral Participation

N/A Not Available

OMIS Organizational Memory Information System

PhD Philosophiæ Doctor. Doctor (or Doctorate) of Philosophy

QFD Quality Function Deployment

R&D Research and Development

SVG Scalable Vector Graphics

UI User Interface

UML Unified Modeling Language

W3C World Wide Web Consortium

WFMS WorkFlow Management System

LIST OF TABLES 19

XML Extensible Markup Language

XSLT Extensible Stylesheet Language Transformations

Chapter 1

Introduction

Es ist so schwer, den Anfang zu finden. Oder besser: Es ist schwer, am Anfang

anzufangen. Und nicht zu versuchen, weiter zuruckzugehen.

Appendix Chapter A on page 162

Knowledge in modern economies is increasingly playing a key role in achiev-

ing organizational success. Knowledge management as a concept and a scientific

discipline emerged to acknowledge this fact. Three main reasons can be iden-

tified for this development [Siv01]. 1) Need: Today’s information technology-

enabled organizations have to process and make use of ever more information in

ever decreasing time cycles. 2) Recognition of need: Organizations increasingly

recognize the need for and the importance of conscious management of knowl-

edge [MRH+04]. 3) Availability of KM-Instruments: Past research activities

(such as [MT02, MR02, Leh02, LSF+02, Rol03]) and product innovations (such

as [Hyp, Liv, Lot]) in the field of knowledge management promise to provide

sound instruments for addressing current KM challenges and for enabling the

management of knowledge in organizational settings. Therefore, the emergence

of knowledge management as a scientific discipline represents an important step

towards more profound approaches in this domain.

Practicing knowledge management in organizations can be achieved through

the development and implementation of knowledge infrastructures [Siv01] (figure

1.1). In this work, knowledge infrastructures are defined as the set of all

successfully implemented interventions, measures, institutions and facilities

that represent a supportive knowledge environment for knowledge workers who

execute knowledge intensive tasks. These knowledge infrastructures consist

20

CHAPTER 1. INTRODUCTION 21

Figure 1.1: Strategic Perspective on Knowledge Infrastructures (Based on [Siv01])

of three main dimensions: 1) people 2) organizational- and 3) technological

systems. According to a Delphi study on the future of knowledge management1,

the successful integration of knowledge management efforts into an organiza-

tion’s business processes is regarded to be the most pressing and challenging

theoretical research issue for the understanding and advancement of knowledge

management. By taking the increasing number of organizations certified accord-

ing to a process oriented management standard into account [isoa, isob], the

importance of this issue is even more emphasized. Among others, these insights

motivated the PhD work at hand, which aims to enable the development of

technological knowledge infrastructures that are integrated in and supportive of

an organization’s knowledge intensive business processes. The following research

challenges are of utmost importance in the context of this objective.

1.1 Research Challenges

Current research in the domain of knowledge management identifies a large field

of new challenges concerning the development of organizational knowledge infras-

tructures. Among them, the following two are especially relevant in the context

1carried out in 2001/2002 by the Fraunhofer Competence Center Knowledge Management,Berlin and the Institute for Psychology of the Humboldt-University, Berlin [MHV03, chapter8]


of this work:

1.1.1 Challenge 1

Networks of Business Processes: Business process management deals with

the management, continuous improvement and optimization of business processes

[ISO00a]. In knowledge intensive organizations, business processes are typically

more and more knowledge intensive [ESR99] and interconnected. Instead of fo-

cussing only on the optimization of isolated business processes, current standards

for business process- and quality management (such as [ISO00a]) suggest that

organizations should investigate, support and improve their networks of busi-

ness processes, especially focussing on interactions between them [ISO00c, sec-

tion 5.1.2]. Figure 1.2 provides a sketch of such situations in an abstract yet

illustrative way.

Figure 1.2: Networks of Business Processes

Knowledge as the key resource of knowledge intensive organizations represents

a significant cause for interactions between knowledge intensive business processes

[Str03a]. By failing to focus on such interactions, an organization is not able to

optimize the sum of its efforts (its business process network), instead it is target-

ing local optima (specific business processes) that do not necessarily contribute

to an organization’s overall goals. Although today’s organizational knowledge

management initiatives already focus on multiple business processes rather than

on a single business process [MR02], surprisingly neither existing process stan-

dards (such as [ISO00b]) nor existing business process modeling techniques (such

as [Sch96]) nor knowledge management approaches provide comprehensive con-

cepts on how to tackle the identified challenge. [RL00] strikingly acknowledge

the need for scientific concepts in this area by stressing that successful support

for knowledge intensive business processes is, to a greater extent, a matter of


supporting knowledge flows (knowledge interactions that span multiple business

processes [Rem02]) rather than workflows.

1.1.2 Challenge 2

Knowledge Management Technologies: Today, a heterogeneous set of

knowledge management technologies is available from industrial vendors (such

as [Hyp, Liv, Lot] and others) as well as from academia (such as [WK02, Dus02,

Eng03, HTEN03] and others). Failures of technology-driven KM2 projects in the

past that did not take critical business requirements of organizations into account

[Rol03, Chapter 3] urgently call for concepts that aid the application and config-

uration of KM technologies to specific business contexts. KM technology itself

can today be classified according to different dimensions. The MT3-Model intro-

duced by [MT02] distinctly classifies KM system functionalities based on different

types of communication between people and technological systems. Each class is

represented through a specific arrow index.

Figure 1.3: The Maurer-Tochtermann (MT) Model

Description: Arrow 1 in figure 1.3 depicts all organizational and

human aspects of knowledge management that cannot be supported

2KM...Knowledge Management3MT...Maurer-Tochtermann


by a (technological) KM system4. Arrow 2 describes the explicit

user action of inputting data into a KM system. Arrow 3 symbol-

izes the ability of computer systems, to generate new knowledge and

autonomously perform appropriate actions based on the implicit in-

put of data by users without burdening them. Arrow 4 describes

that computer systems can generate knowledge about users by ob-

serving them and their behavior. Arrow 5 indicates that users can

obtain information from the system by simply requesting it through

e.g. queries. In arrow 6, the ability of systems to proactively contact

users with information (without being explicitly asked by the user)

is represented. Lastly, arrow 7 symbolizes that computer systems are

able to generate new knowledge (through combination [NT97]) based

on existing knowledge. [MT02] state that traditional information sys-

tems typically comprise functionality as described in arrows 2 and

5. Arrows 3, 4, 6 and 7 are considered to represent distinctive KM

system functionality.

The non-intrusive nature of “Arrow 3” functionality combined with its high

potential to support the execution of knowledge intensive business processes

especially makes this type of KM functionality the most promising one to

be effectively applied to specific, operative business contexts. The scientific

challenge that emerges from this conclusion is how such a business alignment

of KM functionality can be achieved. Therefore, research challenge 2 calls for

concepts that support the successful application of KM functionality5 to given

business contexts.

1.1.3 Summary

On one hand, business process management represents an organizational environ-

ment for knowledge workers in today’s organizations. On the other hand, knowl-

4The MT-Model of [MT02] can be dated back to work performed in 1999 and 2000. The term“KM-System”, used by [MT02] would today probably be substituted by the more appropriateterm “Knowledge Infrastructure”, which is not a term strongly (mis-)used by the softwareindustry and better describes the anticipated concepts.

5more specifically: “Arrow 3” KM functionality of the MT-Model


edge management technologies represent a technological environment for them.

Ultimately, both efforts aim to (separately) support organizations in achieving

their respective business goals and the need for approaches that integrate both

efforts becomes visible6. It is all the more remarkable that currently no scientific

concepts are applied that align both efforts to collectively achieve their goals in

a synergistical way. By overlooking this aspect, organizations fail to provide en-

vironments that comprehensively support knowledge workers in executing their

corresponding business processes.

From a knowledge perspective, these arguments raise the need for a scientific

approach that aids 1) the identification of knowledge flows across a set of busi-

ness processes and 2) the design of support for these flows (and corresponding

knowledge workers), reified in technological knowledge infrastructures in order

to:

1. Support the execution of knowledge intensive and interconnected business

processes in organizations

2. Support the reasonable application of KM functionality in given business

contexts

1.2 Focus of this PhD Work

1.2.1 Objectives

The research challenges introduced in section 1.1 provide a sound fundament for

the definition of more concrete objectives. Thus, this PhD work aims to:

Introduce a framework and an according tool that allows for the de-

velopment of business process-supportive, technological knowledge in-

frastructures for knowledge intensive organizations.

What is meant by “Business Process-Supportive”? Business process sup-

port addresses two main aspects: 1) Employee-level : Here the term refers

to role-oriented, technological support for knowledge workers in their daily

6This need has already been identified by e.g. [Gia99, WC03] in the context of businessprocesses and information systems


knowledge intensive business processes and 2) Organization-level : Here, business

process-supportive refers to support for the effective execution of networks of

business processes.

What is meant by “Knowledge Infrastructures”? Knowledge infrastructures

are the set of all successfully implemented interventions, measures, institutions

and facilities that represent a knowledge environment for conscious and un-

conscious organizational knowledge work. Knowledge infrastructures consist of

three main dimensions: 1) people, 2) organizational and 3) technological systems

(similar to [Siv01], also see definitions in section 1.4).

What is meant by “Knowledge Intensive Organizations”? Organizations that

deal with knowledge intensive goods and services (such as software or automo-

tive industry) are typically considered to be knowledge intensive. Knowledge

intensity itself can be assessed by a series of indicators such as knowledge half

life, learning times and others [ESR99].

A concept that addresses the development of business process-supportive,

technological knowledge infrastructures has to deal with the following require-

ments:

1. The application of the concept leads to knowledge infrastructure designs

that improve environments of knowledge workers for their respective knowl-

edge intensive business processes


that enable role oriented access to knowledge for knowledge workers in or-

ganizations


that enable autonomous routing of knowledge from/to corresponding knowl-

edge workers in their business processes


that enforce a more standardized way of executing knowledge work in or-

ganizations


5. The application of the concept leads to increased transparency of knowl-

edge work in organizations and its implications for technological knowledge

infrastructures

1.2.2 Demarcation

This section demarcates the focus of this work regarding its targeted research

area:

Dimensions of Knowledge Infrastructures: Knowledge infrastructures are

considered to consist of various dimensions. This PhD work exclusively focuses

on designing technological aspects of knowledge infrastructures (also see the

outlined challenges in section 1.1).

Knowledge within or across vs. Knowledge about Business Processes: This

work focuses on identifying and supporting aspects of knowledge within or across

business processes. Knowledge about business processes represents the basis

for all investigations of this PhD work, yet there is no focus on providing this

knowledge to employees.

Knowledge and Constructivism vs. Realism: By defining knowledge as

information that is relevant for action (also see section 1.4), a constructivist

view on knowledge is employed. Business processes, together with corresponding

knowledge workers, accommodate this view by representing the context (the

action) in which knowledge is constantly being reconstructed.

Functionalities of KM systems: In the context of knowledge work in knowl-

edge intensive business processes that requires large amounts of relevant infor-

mation to be directed and transferred between knowledge workers and systems,

Arrow 3 of the MT-Model (figure 1.3) appears to be of special relevance. Arrow 3

depicts the ability to create new knowledge and perform subsequent appropriate

actions based on user interactions (with the KM system) without interfering with

the user’s work. To achieve this, KM systems are supposed to maintain linkages

between pieces of information and to transfer and/or handle information between

various organizational roles and systems according to certain conditions.


Therefore, this PhD work focuses its efforts on providing support for the design

of technological knowledge infrastructures that comprise “Arrow 3” functionality.

1.2.3 Non-Goals

This section describes further potential objectives that are relevant in this context

but which are not explicitly tackled within this work. Such non-goals include:

• considering cognitive factors and/or implications of technological knowledge

infrastructures

• considering pedagogical factors of providing and/or transferring knowledge

• considering HCI aspects of technological knowledge infrastructures

• considering aspects of different knowledge delivery options to respective

users (e.g. Push vs. Pull, representation, etc.)

• considering non-functional requirements of technological knowledge infras-

tructures such as security, modifiability, performance and others [BB98,

BCK98, RR99]

1.3 PhD Thesis Organization

Chapter 1 outlines the motivation for this work and identifies its main objectives.

Since this PhD work deals with knowledge infrastructures that aim to support

knowledge intensive business processes, chapters 2 and 3 introduce existing re-

search work in the domains of knowledge infrastructure development and business

process oriented knowledge management. Chapter 4 introduces the central idea

of this work in an illustrative and accessible way. In chapters 5 and 6 a framework

and an accompanying software tool which together tackle the identified challenges

of this work are described. Chapter 7 introduces three industrial studies that aim

to corroborate the developed concepts of this work. Chapters 8 and 9 point out

aspects that are not within the focus of this work, but play an important role

in future developments concerning the introduced concepts. Chapter 10 reflects

on the identified challenges as well as on the accomplishments of this work. The

main relations between the introduced chapters are illustrated in figure 1.4. The


research approach pursued in this work is introduced in greater detail in appendix

chapter B.

Figure 1.4: Structure of this PhD Thesis

1.4 Terms and Definitions

The following definitions clarify the meanings of central terms used in this PhD

work. While the definitions do not aim to describe the respective terms in a

holistic way, they narrow the meanings of these terms to provide explanations of

how they are used within this work.

Organizations are open, goal-oriented and combined social and technological

systems. They are open because of the manifold interactions with their envi-

ronment. Organizations are goal-oriented since all of their efforts are aligned

to respective business goals. Organizations represent combined social and

technological systems since organizational tasks are executed in collaborational

efforts between these systems [FS01, page 59].


Business process management deals with the explicit management of busi-

ness processes in organizations and focuses on the development, provision and

application of procedural knowledge. According to [ISO00b, p. 23], a process

is a “set of interrelated or interacting activities which transforms inputs into

outputs”. Additionally (in this PhD work), business processes are regarded to

be knowledge intensive and contribute to organizational value chains. Process

agents represent humans (employers and employees) responsible for executing

activities in organizational business processes.

Knowledge management deals with the conscious management of organi-

zational knowledge through knowledge management interventions. (Organi-

zational) knowledge is defined as information that is relevant for executing

certain (business) actions. Knowledge management interventions are the set

of all potential organizational initiatives that aim to improve an organization’s

knowledge infrastructure. They can become, if successfully deployed, an integral

part of knowledge infrastructures.

A striking distinction between business process and knowledge management

can be made by the simplistic interpretation that business process management

focuses on managing flows of organizational work, while knowledge management

focuses on the management of flows of organizational knowledge. Although the

term “flow” used here poses problems7, the analogy introduced represents a

practical approach to the domain at hand. By using this distinction, process

management can be regarded to be part of and a sound basis for knowledge

management by already putting effort into managing organizational knowledge

about “flows of work”.

Knowledge processes describe distributed, organizational knowledge work.

They are regarded to run within or across a set of business processes. Here,

7Knowledge is regarded to be context sensitive, continuously reconstructed by subjects andthus, cannot flow (knowledge as a process versus an object) [Rem02, page 122]. The term“flow of knowledge” here is simplistically used to describe a focused, constructivist relationshipbetween knowledge supply and knowledge application entities.


knowledge processes typically include descriptions of [Str03b]: knowledge flows,

specific knowledge activities, related persons or roles and associated business

processes regarding a certain knowledge domain.

(Organizational) Knowledge domains represent topical fields of knowledge

which are relevant in the context of undertaking certain (business) actions.

Knowledge management is often concerned with increasing transparency of

critical knowledge domains in organizations. In such efforts, knowledge domains

are typically identified and subsequently combined to form knowledge diagrams

which represent knowledge domains at various abstraction levels in a networked

(e.g. Topic Maps [Top01]) or hierarchically (e.g. knowledge structure diagrams

[Noh00]), organized way.

Specific knowledge activities are basic knowledge actions executed by people,

organizations or technological systems. Examples of specific knowledge activities

include the socialization, externalization, combination, generation, transfer or

application of knowledge8. In this PhD work, the specific knowledge activities

generation, storage, transfer and application [Hei01] are utilized since they

adequately9 describe knowledge work on an operative (or knowledge object

[SAA+02]) level. Various authors provide their very own sets of specific

knowledge activities [Hei01, NT97, Rol03] for different objectives and areas of

application.

Specific knowledge activities executed by an organizational role either within

or outside of business processes are referred to as knowledge work. Knowledge

work can therefore be a subset of both business and knowledge processes, but

is at least a subset of knowledge processes. Organizational roles that perform

knowledge work are regarded as knowledge workers .

Figure 1.5 depicts relationships between the key terms technological knowledge

infrastructure, business process, knowledge process, specific knowledge activity,

8Here, a necessary distinction between specific knowledge activities (on a knowledge objectlevel [SAA+02]) and knowledge management activities (such as knowledge planning, identifica-tion or assessment - on a knowledge management level [SAA+02]) has been made.

9with respect to the defined objectives of this work


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.


Technological knowledge infrastructures are technological systems. This in-

cludes software applications such as knowledge management-, document- or con-

tent management systems, intra- or extranets, file servers, data bases but also

custom tailored systems. Approaches focussing on the development of knowl-

edge infrastructures only sporadically exist (e.g. [Siv99]). Detailed concepts

concerning the domain at hand are not available. However, mature approaches

and concepts stemming from related research domains that are relevant in the

context of knowledge infrastructure development are available. For example,

work performed in the field of software-, systems- or method-engineering (such

as [You89, Bri96, Tol98]) as well as knowledge based or information system de-

velopment (such as [SAA+02, Sin95]) can significantly contribute to the topic at

hand.

2.1 The Knowledge Infrastructure Develop-

ment Project

Knowledge management initiatives, such as the development of knowledge

infrastructures, are typically organized as a project [MR02]. In this work, a

33

CHAPTER 2. KNOWLEDGE INFRASTRUCTURE DEVELOPMENT 34

knowledge infrastructure development project focuses on the design of techno-

logical systems that support knowledge workers. In figure 2.1, relevant roles

of knowledge infrastructure development projects are introduced. In order to

accomplish their respective goals, the roles need to perform certain tasks. Tasks

are typically organized and executed in a certain timely sequence, represented

through process models. Tools support the roles in executing their respective

goals1.

Figure 2.1: Knowledge Infrastructure Development Projects (Based on

[SAA+02])

This chapter introduces roles, tasks, processes and tools (see table 2.1) that are

of importance for the development of technological, business process-supportive

knowledge infrastructures in order to increase understanding about the execution

of knowledge infrastructure development projects. This conceptualization acts as

a sound fundament for the development of the anticipated framework of this PhD

1not depicted in figure 2.1


work.

All of these aspects are described from a knowledge infrastructure develop-

ment perspective (focussing on support for organizational knowledge processes

and knowledge workers) and are typically described on a higher abstractional

level than from an e.g. software development perspective.

Knowledge Infrastructure Development

Roles page 36

Tasks page 38

Process Models page 40

Tools page 42

Table 2.1: Aspects of Knowledge Infrastructure Development

2.2 Roles

Figure 2.1 depicts the context in which knowledge infrastructure development

projects are being executed together with a diverse set of roles that is related to

the process of knowledge infrastructure development. In this section, these roles

and corresponding responsibilities in an organization are introduced.

2.2.1 Knowledge Manager

The knowledge manager (or CKO - Chief Knowledge Officer) is regarded to be

highest ranked role in knowledge management [Mai02, p.143]. In this steering

position, his main responsibility is to develop and implement a knowledge man-

agement strategy that is aligned to an organization’s business strategy [Leh00, p.

226], [SAA+02, p. 22], [MHV03, p.107]. He initiates and coordinates knowledge

management projects and monitors the results in terms of their contribution to

the KM strategy as well as in terms of achieving economic benefits. In larger or-

ganizations, this role is typically performed by one CKO who supervises various

knowledge managers in his business unit [Mai02].


2.2.2 Project Manager

The project manager (or knowledge project manager [MHV03]) is in charge of

running knowledge management projects [SAA+02, p. 22]. He focuses on aspects

related to project management such as the development of project goals and plans

or the coordination of project team members [MHV03, p. 107]. The project

manager takes a business perspective on the project to ensure that the project

goals are met in time and within the provided resources. He is also responsible

for dealing with project monitoring, controlling and/or marketing.

2.2.3 Knowledge Worker

Knowledge workers are the primary target group of a knowledge infrastructure

development project (also see [Mai02, p. 150]). Such projects aim to support

and improve the work of knowledge workers [DJB95]. As defined in section 1.4,

knowledge workers are regarded to execute knowledge work within or outside

of business processes. They implicitly or explicitly generate, store, transfer and

apply knowledge. Thus, the role of a knowledge worker is broader than that of

a knowledge user [SAA+02, p. 22] (additional focus on knowledge generation,

storage and transfer), and is not related to the role of a knowledge management

worker [MHV03, p. 108], who is a trained person dedicated to perform operational

knowledge management activities such as categorizing or structuring knowledge

bases.

2.2.4 Knowledge Analyst

The knowledge analyst2 is responsible for analyzing organizational knowledge

work executed by knowledge workers. Similar to the role system analyst [You89,

p. 56], he investigates a complex object system (organizational knowledge work)

and generates models that illustrate core aspects of the system under investiga-

2[SAA+02, p. 20] unfortunately use the term knowledge analyst interchangeably with theterm knowledge engineer. Rooted in the domain of knowledge engineering, a knowledge engineeraims to elicit knowledge from experts to implement that knowledge in so-called knowledge basedsystems. Instead of replacing knowledge of experts, in this PhD work a knowledge analystaims to analyze knowledge work of knowledge workers in order to support them by means ofsupportive knowledge infrastructures.


tion. In doing so, the knowledge analyst provides specific knowledge views on

the system that represent a fundament for subsequent activities of knowledge

infrastructure designers.

2.2.5 Knowledge Infrastructure Designer

The knowledge infrastructure designer is responsible for transforming the devel-

oped models of organizational work into a design that describes a supportive

environment for knowledge workers (in analogy to [You89, p. 57]). He develops a

design of the system, which is the basis for implementation. Since knowledge in-

frastructures are typically not designed from scratch, a knowledge infrastructure

designer either utilizes available COTS3- or existing legacy systems. The knowl-

edge infrastructure designer (or an implementation team) finally implements the

final design. He also accompanies the validation of the solution with knowledge

workers.

2.3 Tasks

In figure 2.1, certain tasks of knowledge infrastructure development projects are

introduced. This section briefly introduces details concerning the execution of

these tasks.

2.3.1 System Analysis

System analysis deals with building models (model systems) about an object

system under investigation with the purpose of gaining a deeper understanding

about conceptualizations and interactions of people, groups of people, organiza-

tions and/or technology [You89]4. Typically, modeling tools (such as Structured

Analysis [You89], Unified Modeling Language [FS00], CommonKADS [SAA+02]

or ARIS [Sch96, Sch00]) aid system analysts in developing such models. They

provide formal conventions regarding graphical representations and conceptual

3COTS...Commercial-Off-The-Shelf4similar to what [FS01] define as the task layer (“Aufgabenebene”) of business information

systems


segmentations as well as a set of suggested modeling dimensions. In the con-

text of knowledge infrastructure development, system analysis contributes to the

modeling of organizational knowledge work as a sound fundament for designing

supportive knowledge infrastructures.

2.3.2 Requirements Engineering

Requirements engineering in the context of knowledge infrastructure development

represents an attempt to generate requirements for an anticipated knowledge in-

frastructure. Relevant requirements elicitation techniques [Mac96, Wer, KS98]

in this context are JAD (Joint Application Design), CRC (Cooperative Re-

quirements Capture), QFD (Quality Function Deployment), structured or un-

structured interviews, scenarios, observations, video recording, card games, job

shadowing, focus groups, future workshops, prototyping, mock ups and others.

Requirements are typically classified along two main dimensions: functional and

non-functional requirements [KS98, BB98, RR99]. Requirements engineering not

only deals with aspects of eliciting requirements, but also with aspects of pri-

oritization, negotiation, validation, traceability, maintenance and management

[KS98, RR99].

The following aspects are considered to be problematic and may pose risks for

the outcome of requirements engineering efforts when structured or unstructured

interview techniques are being applied [You89]:

• Interviewing wrong people at the wrong time

• Asking wrong questions and getting wrong answers

• Creating bad feelings between involved parties (knowledge analysts and

knowledge workers)

2.3.3 System Design

System design [YC79, You89] deals with transforming model systems and system

requirements into a system design that allows for implementing an anticipated

system (respectively a knowledge infrastructure). In system design, pre-built

system elements, components and modules, as well as system design techniques,


and/or reference system architectures typically provide guidance for system

designers (respectively knowledge infrastructure designers).

Patterns [Ale79, BMR+96, RZ96] can act as a vehicle for (pre-)packaging con-

ceptual elements of systems. They allow for easily reusing knowledge from past

projects for current system design efforts. Reference or template architectures (as

e.g. [Mai02] for knowledge management systems) typically act as blueprints for

the design of new systems. [Sin97] distinguishes between generic and non-generic

reference systems: Non-generic reference systems act as analysis and design tem-

plates for the design of systems while the reference system itself is not part of

the final design. Generic reference systems are able to deduce designs of systems

that can be traced back to the respective reference systems.

2.3.4 System Usage

After the technological knowledge infrastructure is deployed, knowledge workers

(end users) start working with it. In doing that, they generate valuable feedback

concerning the usability and applicability of the system. For the continuous

improvement of the system, consideration of this feedback is crucial.

Summarization: While system analysis by nature has a more descriptive

character (How an object system is), requirements engineering stronger focuses

on normative aspects (How a software system is supposed to be). System design

deals with specification aspects of software systems, while system usage comprises

user interactions with a knowledge infrastructure.

2.4 Process Models

This section depicts process models from various domains that are oriented to-

wards the development of systems. Although they are not directly related to

knowledge infrastructure development, they give an overview of prominent ap-

proaches towards system development and are general enough to fuel understand-

ing about different conceptualizations and applications in this domain.


2.4.1 Waterfall Model

The waterfall model represents a first approach by [Roy70] to structure system

development processes. Although [Roy70] did not use the term “waterfall model”

in his paper, this name was assigned to his work by later publications because of

the characteristic representation of his proposed process. Based on the work of

[Roy70], a broad range of different versions of his waterfall model emerged (e.g.

[You89, p.83], [Boe88]). Although [Roy70] acknowledged the fact that varying

iterations through his process model are potentially necessary, the basic concept

of the waterfall model generally is - incorrectly - perceived to be a development

process that is decomposed in a set of phases, whereby each phase has to be

completed before the next starts (in a strictly sequential order). Objections

against this model typically include arguments that focus on the sequential nature

of such waterfall models and the lack of feedback loops. [Boe88] argues that,

for example in interactive end-user applications, more iterative approaches are

demanded.

2.4.2 Spiral Model

According to [Boe88], the spiral model represents an iterative, risk driven process

approach to system development, rather than a strictly sequential document- or

code driven process. The spiral model aims to generalize a set of different develop-

ment models (such as the waterfall model) and thereby provides a deeper under-

standing and more comprehensive guidance concerning system development pro-

cesses. The iterative approach and the wide range of options allows for adapting

the model to a large set of specific situations. The spiral approach continuously

generates and tests hypothesis about the system to be developed. Instruments,

such as risk management plans, support system developers in taking appropriate

decisions.

2.4.3 V-Model

The V-Model [IAB95] is a german IT system development standard for industry

as well as public administration and military projects. It tackles system devel-

opment in a comprehensive way by considering not only software development,

but also project management, quality assurance and configuration management


issues. For all of these dimensions, the V-Model aims to provide supportive

procedures and methods as well as requirements for tools that support project

participants in executing their respective tasks. System development takes place

by iterating through the proposed process steps of the V-Model.

2.4.4 Rational Unified Process

The rational unified process [Kru] is a process model developed by Rational Soft-

ware that aims to provide guidance in software engineering processes. The main

process elements are business modeling, requirements, analysis and design, im-

plementation test, deployment, configuration and change management, project

management and environment. These elements are performed iteratively [LB03]

in what can be regarded as micro-waterfalls [Roy70]. The rational unified pro-

cess strongly focuses on developing and maintaining models of the system under

development. The process is typically utilized either as a basis for evolving a

company’s own standard or as an “electronic coach” for software engineering.

Rational Software provides comprehensive tool support for its process.

2.5 Tools

Computerized applications supporting and/or partially automating system de-

velopment activities are referred to as CASE5 tools (Based on [Fug93]). CASE

tools were classified along a large set of dimensions and categories [Fug93], a few

relevant of them are introduced here briefly:

• Upper vs. Lower CASE tools

• System development process vs. Metaprocess tools

• Tools vs. Workbenches vs. Environments

The term Upper CASE tool is used to describe CASE tools that provide

support on high abstractional (conceptual) levels, typically utilized during early

stages of system development [Tol98]. Lower CASE tools deal with more detailed,

5Multiple variants of the CASE acronym exist (also see [Sit02]). The most relevant in thecontext of this work is Computer Aided System Engineering


often software-specific aspects of CASE. CASE tools focussing on system devel-

opment processes provide support for system development teams, while CASE

tools focussing on meta-processes provide support for method engineers who are

aiming to design methods and tools for system development teams (by means of

metaCASE or CAME tools [Tol98, p.68]). CASE tools, workbenches and environ-

ments [Fug93] classify available instruments in terms of their ability to provide

support for only specific system development activities vs. the whole system

development process.

2.6 Relevant Scientific Domains

This section briefly introduces a set of scientific (sub-)domains that are related

to the identified challenges of this PhD work and can potentially comprise

valuable concepts for the development of business process-supportive knowledge

infrastructures:

Business Process Oriented Knowledge Management: In recent years,

increasing research has been performed in the domain of business process

oriented knowledge management. Some approaches rooted in this discipline

focus on the deduction of knowledge infrastructures based on an organization’s

business processes. By focussing on these aspects, this domain is of highest

relevance to the context of the PhD thesis. Therefore, business process oriented

knowledge management is introduced in greater detail in chapter 3.

Modeling and Engineering of Business Information Systems: This

scientific discipline (in German: “Modellierung betrieblicher Informationssys-

teme” [Sin95, Sin97, FS01]) separates organizational systems into two basic task

(“Aufgabenebene”) and task-carrier (“Aufgabentragerebene”) layers [FS01].

Tasks describe organizational activities that need to be carried out in order

to achieve certain business goals. Task carriers are organizational entities

(humans or systems) responsible for executing a certain task. Based on this

basic distinction, several instruments (e.g. Entity Relationship Diagrams, UML

Models) are utilized to design technological support for the execution of business

processes. This PhD work addresses both task layers and task-carrier layers and


introduces a framework that interconnects these concepts by providing support

for knowledge flows (between task carriers) that span multiple business processes

(at the task layer).

Requirements Engineering and Systems Analysis: Requirements

engineering deals with the process and related instruments of eliciting crucial

requirements for software projects [RR99]. Once the process of requirements

engineering is completed (the output are agreed upon requirements among

stakeholders), system analysts are in charge of modeling the requirements to

prove their correctness. When put to application, requirements engineering and

system analysis represent themselves not as two separate processes, but are

executed with a considerable timely and focal overlap. Requirements engineering

and systems analysis typically do not consider business or knowledge aspects as

a basis for conceptualizations, but utilize the notion of stakeholders to generate

sets of requirements. Here, the focus is on designing systems that satisfy iden-

tified stakeholders. System requirements are identified and represent the basis

for subsequent actions. While requirements engineering and systems analysis

focus on the development of systems from scratch, research on the development

of COTS based systems focuses on the adaption and configuration of already

existing systems. In the context of this PhD work, it is methodological knowledge

that mainly can be utilized from the approaches rooted in these scientific domains.

Social Network Analysis: This instrument, rooted in the scientific domain

of sociology, aims to identify informal relationships between a set of intercon-

nected people (e.g. [Pai03, MPF04, CLC04]). Thereby, roles and positions of

people within networks as well as relations between them can be identified and

analyzed. Especially improvements concerning cultural and organizational as-

pects can be designed based on such approaches.

User Observation and Pattern Analysis: Typically, approaches in

this domain deal with observing user interactions with computer systems (e.g.

[SRB03, HGM01]) aiming to understand intentions of users at high conceptual

levels. Based on collected data which typically represents logs of interactions on

a software application level, such approaches aim to identify higher level user

goals such as work tasks, work flows or knowledge flows in a bottom up way.


Major problems of such ideas are represented by the fact that users typically

execute various tasks or pursuit various goals at the same time and users’ current

business contexts are hard to grasp. This is the reason why such approaches

currently rely on very narrowing conditions and assumptions and on the abilities

of analysts who interpret the gathered data in an intelligent way.

Knowledge Management Technologies: During the last years, a

lot of research is being done on the domain of knowledge management

[NT97, PRR98, HNT99, Leh00]. A sub domain of this discipline focuses on the

conceptualization and classification of currently available and potential future

KM technologies (such as [Rol03, MR02, MT02]). These efforts provide profound

models for necessary, complexity reduced conceptualizations of the domain of

KM technologies.

This PhD work utilizes concepts from the aforementioned scientific disciplines,

but focuses on and is rooted in the discipline of business process oriented knowl-

edge management (introduced in greater detail in chapter 3).

2.7 Assessment in the Context of this Work

Although the existing work introduced in this chapter is not directly related to

the development of knowledge infrastructures, it provides a sound basis for con-

ceptualizing the domain of knowledge infrastructure development and for further

narrowing the focus of this PhD work. This PhD work focuses on providing sup-

port for knowledge analysts who aim to analyze organizational knowledge work

(system analysis) and for knowledge infrastructure designers who are responsible

for designing business process-supportive knowledge infrastructures. Thereby,

existing object systems (organizational knowledge work) need to be modeled and

transformed into a knowledge infrastructure design. The process models intro-

duced in section 2.4 indicate a current trend towards iterative approaches in

system engineering. Especially during implementation phases an iterative ap-

proach is strongly recommended to ensure tight integration of future users. Since

models of organizational knowledge work can be arbitrary large and complex

(depending on the scope of investigation), the need for supporting CASE tools


becomes obvious. Therefore, this PhD work aims to develop a framework and an

accompanying software tool that aids the process of developing business process-

supportive knowledge infrastructures.

Chapter 3

Business Process Oriented

Knowledge Management

Ich mochte nur darauf hinweisen, daß es eine Zeit gab, in der man die

Ahnlichkeit der Empfindungen zur Basis der Kategorisierung von Pflanze und

Tier gemacht hat. Man denke [...] an die fruhen Taxonomien des Ulisse

Aldrovandi aus dem 16. Jahrhundert, der die scheußlichen Tiere (die Spinnen,

Molche und Schlagen) und die Schonheiten (die Leoparden, die Adler usw.) zu

eigenen Gruppen [von Lebewesen] zusammenfasste.


3.1 Introduction

The emergence of the phenomenon of knowledge intensive business processes

raised the need for an integration of the existing research domains of business

process- and knowledge management. A commonly used term to describe this

relatively young research domain is “Business Process oriented Knowledge Man-

agement (bpoKM)” [Hei01, JHS01, AHMM02, Rem02] which itself is a rather new

term and includes a variety of concepts and approaches tackling a very diverse

field of challenges. Based on a comprehensive literature review, the following sec-

tion introduces a model of currently existing bpoKM challenges and approaches

to assess their relevance in the context of the challenges of this work.

46

CHAPTER 3. BUSINESS PROCESS ORIENTED KNOWLEDGE MANAGEMENT47

3.2 Overview of Challenges and Approaches

Figure 3.1: A Model of bpoKM Challenges

Figure 3.1 illustrates the main challenges of bpoKM that were explicitly or

implicitly addressed by research efforts in the domain of bpoKM during the last

years. As a starting point, most approaches in the domain of bpoKM with an

operative focus1 rely on analyzing business processes by taking a “knowledge

perspective” on them. Current bpoKM approaches mainly focus on one, but

cover and typically need to resolve more than one of the identified challenges.

As depicted in figure 3.1, current bpoKM approaches predominately focus

on Business Process Modeling, Business Process Learning, Business Process

Support, Business Process Execution or Business Process Improvement.

[Rem02, page 71] also provides a classification of diverse bpoKM challenges.

While his approach mainly focuses on what business process management

can do for knowledge management (defined elements of the classification are

“Introduction of Knowledge Management”, “Design of Knowledge Management

1Strategic aspects of business process oriented knowledge management are not explicitlymentioned in the depicted model in figure 3.1. The reason to that is because strategic con-siderations play an important role in each of the identified challenges. The importance ofstrategic considerations has been recognized by academia and comprehensive work regardingthese aspects is available (e.g. [MR01, MR02, Mai02, MR03]).


Systems”, “Knowledge Process Redesign”, “Increased Process Transparency”),

the classification introduced in figure 3.1 puts business process challenges up

front. Since knowledge management never represents an end in itself, the latter

approach provides more feasible arguments and benefit estimations for the

implementation of knowledge management efforts.

The following paragraphs first introduce the common ground of bpoKM

(which is represented by Business Process Analysis) and afterwards deal with

the main identified challenges of bpoKM. Based on a comprehensive literature

review, expected benefits as well as current prominent approaches per challenge

are introduced and described. The approaches classified here do not necessarily

exclusively focus on the respective challenges, but cover the targeted challenge

to a prominent extent.

3.3 Business Process Analysis

Knowledge oriented analysis of business processes represents the fundament of

most approaches in the field of bpoKM. Often, specific knowledge activities such

as the generation, socialization, integration or transfer of knowledge are utilized

to investigate business processes in terms of their respective knowledge work.

By taking a “knowledge perspective” on business processes, analysts are able to

identify knowledge implications, relationships and/or interactions which are typ-

ically not covered in traditional business models. These analysis provide valuable

insights for addressing the identified challenges depicted in figure 3.1.

3.4 Business Process Modeling

3.4.1 Challenges

Knowledge, as a key resource in today’s organization’s value generating processes

represents a factor that was not considered in traditional business process mod-

eling efforts. Such traditional business process models concentrated on modeling

the “flow of work” rather than the “flow of knowledge” in organizations [Str03a].

With knowledge gaining more and more importance, traditional business pro-


cess models can significantly be enhanced by integrating knowledge as a critical

resource. BpoKM approaches that focus on the modeling of business processes

aim to eliminate these deficits by introducing ways that allow for the integrated

modeling of work- as well as knowledge-related aspects.

3.4.2 Benefits

The benefits of considering knowledge aspects in business process models are man-

ifold: Knowledge domains that are crucial for the execution of certain business

processes become visible. Highly prioritized knowledge processes, which typically

span multiple business processes, can be identified, managed and treated as sepa-

rate important organizational processes. Knowledge deficits as well as knowledge

oversupplies can be identified and remedied [GPSW03]. In subsequent efforts,

knowledge workers can be provided with exactly the knowledge which suits their

roles in their corresponding business processes.

3.4.3 Selected Approaches

Approaches that focus on the knowledge oriented modeling of business processes

exist and are briefly described in this section.

ARIS

ARIS (ARchitektur integrierter InformationsSysteme) represents a concept for

the modeling of business processes developed by Prof. Scheer. Based on five

views (Organization, Function, Data, Output and Control View) [Sch96, Sch00],

different important aspects of organizational processes are modeled and consid-

ered. While this approach is rooted in the domain of traditional business process

management, the emergence of knowledge management led to extensions [All98].

Specific knowledge management instruments like knowledge structure diagrams

or landscapes as well as the modeling of knowledge work in organizations and the

modeling of specific knowledge processes is supported by a software tool (ARIS

Tool). Examples of using the concept ARIS for the modeling of knowledge

intensive business processes exist and can be found in [Har02, page 126] or

[Leh02, page 15].


K-Modeler

The University of Oldenburg is developing the description language K-Modeler

and an accompanying software tool that aids the integrated modeling of both

business and knowledge processes. K-Modeler aims to identify flaws and

weaknesses in organizational knowledge processes [GPSW03]. To achieve that,

the approach extends current existing business process modeling techniques with

elements focusing on describing knowledge work of process agents. Remark-

ably, K-modeler supports role-oriented as well as person-oriented modeling of

knowledge work. In doing that, [GPSW03] utilize Nonaka’s [NT97] four specific

knowledge activities (internalization, socialization, externalization, combination)

to model current and targeted degrees of organizational management concerning

knowledge processes.

Papavassiliou et al.

The concepts presented in [PMA02, PNAM02] focus on the modeling of weakly

structured and knowledge intensive business processes. Based on the specific

knowledge activities introduced by [Hei01] (which are Generation, Storage, Trans-

fer and Application), a meta model for the integration of knowledge in busi-

ness process models was developed. Therefore, a differentiation between Normal

(Business) Tasks and Knowledge Management Tasks is proposed. A developed

tool that integrates the existing software tools Microsoft Visio 2000 and Cog-

noVision supports business process engineers during modeling. In subsequent

efforts, [PMA02] use their concepts to model business processes as a basis for the

utilization of workflow management systems.

3.5 Business Process Learning

3.5.1 Challenges

Today’s training of employees in organizations usually takes place in a domain-

or product-oriented way. Examples for such traditional training are e.g. project

management courses or MS Winword training. For knowledge workers in today’s

organizations, learning is a continuous, problem-centered effort that typically oc-

curs right at their work places without having time to participate in comprehen-


sive seminars. Traditional learning techniques (like courses, e-learning, seminars,

classes, etc.) do not satisfy the highly specific business needs of these knowl-

edge workers since available training is tailored to abstract fields of knowledge

instead of concrete business problems. BpoKM approaches that focus on busi-

ness process learning typically stem from learning theory and aim to resolve the

aforementioned conflict. By conceptualizing learning as being an integral part

of knowledge worker’s business processes, such approaches provide personalized,

problem-oriented and context-sensitive access to learning resources that aid the

development of necessary knowledge.

3.5.2 Benefits

BpoKM approaches that focus on business process learning aid knowledge workers

in effectively building up knowledge and abilities needed in order to fulfill tasks

in their corresponding business processes. Typically, such approaches support

knowledge workers in acquiring knowledge that comprises a noticeable learning

curve and focus on knowledge that needs to be applied in very specific contexts

(often referred to as experience) as well as more context-independent knowledge

(models or theories). The main benefit that organizations as well as knowledge

workers reap from support provided by such approaches is that the time a novice

needs to become an expert typically decreases. Thereby, organizations can de-

crease the costs of potential fluctuation and knowledge workers receive support

in building up critical knowledge that is needed in order to perform well in their

corresponding business processes.


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


enriching existing business process models with previously unconsidered aspects

of learning. Thereby, knowledge workers are supported in acquiring knowledge

they need within their business processes. Additionally, ADVISOR supports

the provision of target group specific views on business processes. This aids

employees in reducing complexity about organizational models and focusing on

relevant aspects of available organizational knowledge.

MODEL

MODEL (Multimedia for Open and Dynamic Executives Learning) [PPS02] rep-

resents an approach that aims to foster work-based learning processes. [PPS02]

tackle this challenge by designing a KM system that aims to 1) capture and trans-

fer knowledge generated in business processes and 2) provide a business process

oriented ICT2 infrastructure for enabling novice process agents to learn from col-

league experts (via the KM systems). The vision of MODEL is to establish a

self-sustaining, multi-subjective KM system that acts as a medium for knowledge

transfer as well as a source of knowledge for organizational knowledge workers.

By doing that, this approach both focuses on technological (supporting ICT) and

on human (CoP3s) and organizational aspects of learning.

3.6 Business Process Support

3.6.1 Challenges

Supporting knowledge workers in executing their business process tasks is a rather

complex undertaking. Knowledge workers are highly dependent on business pro-

cess specific, task-oriented and action-relevant information. In today’s organi-

zations, knowledge workers are responsible for filtering this information from

various sources within or outside their organizations and relating it to their cor-

responding business process contexts. This work strongly relies on knowledge

workers; it is time consuming and most of the time not documented or traceable

at all. Thus, such work represents itself as being risky and expensive for organi-

zations. BpoKM approaches focusing on business process support aim to tackle

2ICT...Information and Communication Technology3COP...Communities of Practice


the identified challenges by providing instruments, which aid knowledge workers

in acquiring and organizing relevant information that is critical to their business

processes.

3.6.2 Benefits

Given that knowledge workers maintain the necessary abilities to execute their

business process activities, bpoKM approaches focusing on business process sup-

port typically provide knowledge workers with action relevant information, in-

formation sources and channels. Thereby, knowledge workers receive focused

support in their corresponding business processes which enables them to make

informed decisions. Organizations profit from such efforts also since information

needs, sources and channels of their knowledge workers are made explicit, thus

are documented and thereby capture parts of implicit knowledge of knowledge

workers. Also, by identifying these needs, organizations are now able to explic-

itly trace and manage the delivery of information that is considered to be of high

relevance for the achievement of certain process or business goals.


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”


and deduced the design of a knowledge portal that supports researchers in

executing this critical business process.

Knowledge Networks Reference Model

The knowledge networks reference model [RES+00] developed at the research

center Knowledge Source at St. Gallen aims to support business processes

and corresponding knowledge workers by means of designing organizational

knowledge networks. Here, knowledge networks comprise organizational as

well as technological instruments that can be used to facilitate social relation-

ships in organizations. Together with the network approach which is based

on investigating an organization’s business strategy and its corresponding

knowledge work processes, [RES+00] introduce a business process oriented

knowledge management architecture approach which is based on investigations

of an organization’s business processes too. Both approaches are considered to

complement themselves [RES+00, page 39]. Additionally, the work provides

a comprehensive classification of existing knowledge management technologies

that themselves represent the building blocks of knowledge networks.

GPO-WM

The method GPO-WM (GeschaftsProzess Orientiertes WissensManagement)

[Hei01, MHV03] developed at Fraunhofer IPK Berlin aims to support business

processes by selecting and implementing appropriate KM interventions. [Hei01]

utilizes four specific knowledge activities (Generation, Storage, Transfer and

Application) to investigate business processes in terms of their knowledge work.

Based on this analysis, the method deduces technological, human oriented

and organizational KM interventions that aim to support an organization’s

business processes. Additionally, this approach provides KM best practices for

certain types of common business processes. Thereby, organizations are aided

in identifying appropriate, supportive KM interventions for their most critical

business processes.

Other Approaches

The approach of [MHA03] focuses on the design of process oriented knowledge

structures. Through analysis of existing business process structures as well


as through consensus workshops with stakeholders, knowledge structures that

are aligned to business processes are developed. Thereby, organizational work

and knowledge environments become integrated and knowledge workers are

supported via business process oriented access to process instance specific

information.

Another concrete example of conceptualizing business process support for

a specific role can be found in [Jan00]. In his PhD thesis, he analyzes the

main processes of business engineers and subsequently designs an appropriate,

technological knowledge infrastructure (a business engineer portal).

PRomisE2 (the PRocess oriented Organizational Memory Information System

navigator II) [HHDG02] represents another approach that provides knowledge

workers with situated process information. Here, the PRomisE2 system delivers

target group specific (e.g. according to the knowledge worker’s role or associated

division) and work context sensitive information to knowledge workers. Thereby,

knowledge workers can easily relate to business process models since the models

are instantiated with personalized information specific to knowledge workers’

context.

3.7 Business Process Execution

3.7.1 Challenges

Currently, the most prominent way of technologically enabling the execution of

business processes is the utilization of formally available business process con-

text information. WFMS support the routing and assignment of work packages

across multiple roles or employees of organizations and thereby maintain formal

information about the status of currently executed business processes. In doing

that, WFMS promise to provide infrastructures for the execution of a large set of

business processes in a comprehensive way. Nevertheless, at present WFMS are

utilized mainly when it comes to supporting well-structured and simple business

processes such as vacation requests or requests for business cards. The reason

to that commonly is credited to the nature of knowledge intensive business pro-

cesses. Knowledge intensive business processes are typically weakly structured,


their output strongly depends on knowledge workers and the learning time for

properly executing the processes is high [ESR99]. Therefore, traditional WFMS

bear a significant improvement potential. By integrating mechanisms that are

focused on dealing with the critical resource knowledge, WFMS could even pro-

vide more support to users of such systems (by e.g. providing information that is

relevant for executing certain assigned work packages). BpoKM approaches that

focus on business process execution typically suggest extensions to traditional

WFMS from a knowledge perspective in order to get rid of the described deficits.

These approaches differ to Business Process Support approaches in terms of their

historical roots (WFMS), their targeted business processes (still less knowledge

intensive and complex) and their targeted intervention levels (exclusively tech-

nological interventions aligned to the concepts of WFMS).

3.7.2 Benefits

Traditional WFMS typically aid organizations in the traceable execution of busi-

ness processes across multiple business process instances and multiple participat-

ing process agents [Hol95]. BpoKM approaches that focus on business process

execution aid process agents in executing their assigned tasks. Thereby, orga-

nizations not only get the benefit of assured and traceable accomplishment of

assigned work, they can also influence the quality of assigned work by explicitly

providing support concerning the important resource knowledge. Such enhanced

WFMS can ensure that knowledge is provided, treated and documented according

to organizational guidelines in an organization’s business processes.


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


organizations with a focus on software development environments. In Milos,

business process models are enriched with process agents’ skills and information

needs models as well as links to background knowledge. Business process

planning is supported by implementing a best practice process module library

and providing specific software interfaces and functionality (e.g. yellow pages)

to project planers. Business process execution is supported by providing

coordination, communication and notification features for participating process

agents. Milos also puts a strong focus on organizational learning by utilizing

instruments such as experience bases and process feedback loops.

PROMOTE

PROMOTE [KT00, AHMM02, TK02, WK02, Woi03, WK03] was developed

within an EU project and represents an approach developed by the company

BOC GmbH. PROMOTE consists of a methodology and an accompanying

software tool [AHMM02, page 68]. The main goals of this approach (formulated

in [KT00]) are to support employees in executing their business processes.

Therefore, PROMOTE focuses on providing context-sensitive knowledge to

employees and on establishing mechanism that aid employees in the provision

of knowledge to the PROMOTE system. PROMOTE extends existing workflow

systems by enabling a pass over of business process context information to

knowledge processes, which therewith get pre-configured according to users

needs. A later publication concerning PROMOTE focuses on the explicit

management of various strategies concerning the provision of knowledge services

to employees [WK03].

Workbrain

Workbrain [WWT98] is an approach developed by the Bavarian Research Center

for Knowledge-based Systems. Workbrain represents an effort to extent an

existing WFMS to an OMIS4. This approach focuses on supporting employees in

1) mastering and 2) improving workflows as well as 3) providing and retrieving

knowledge to/from Workbrain.

Other Approaches

4OMIS...Organizational Memory Information System


EULE ([RMS00]) is a knowledge-based, cooperative system for supporting office

work in insurance business environments developed by the Information Systems

Research Group of Swiss Life. EULE provides process agents with models of

business processes that comprise reasoning and explanations for them as well as

role-oriented views on business process activities. A conducted field study re-

vealed that novice as well as expert process agents received considerable work

support from the EULE system. While EULE is not yet integrated in a WFMS,

[RMS00] designed the system with these aspects in mind and stress the fact

that EULE would complement well with the concepts of WFMSs by focusing on

declarative on top of procedural knowledge.

DECOR (DElivery of Context-sensitive ORganizational knowledge) [AML+01] is

a project funded by the EU which utilizes the concept of ontologies for support-

ing process agents in executing their business process tasks. Beneath a method-

ological approach, DECOR employs a WFMS and enriches traditional workflow

models with information needs models of process agents as a basis for support-

ing them. [AML+01] plan to achieve such operational support through knowledge

archives and active information delivery concepts that utilize context information

available in WFMS.

3.8 Business Process Improvement

3.8.1 Challenges

BPR5 is a prominent and often utilized approach for improving business processes

of organizations although it represents a rather radical way of achieving improve-

ments. Typically, BPR discards existing business process modeling efforts and

designs new business process models from scratch. By taking knowledge impli-

cations of existing business process models into account, BPR would be able to

better anticipate future knowledge interactions between newly developed busi-

ness processes and thereby might develop more optimal and sustainable business

processes. CPI6, another effort targeted at improving existing business processes,

promotes the continuous controlling, analyzing and improving of single business

5BPR...Business Process Re-engineering6CPI...Continuous Process Improvement


processes in terms of fulfilling their respective business process performance indi-

cators. CPI in the past proved itself successful for improving selective sequences

of work in organizations. The improvement of complex networks of business pro-

cesses (also see challenge 1 in section 1.1.1) has not been among the major goals

of CPI efforts. Because of their roots in process management, both approaches

do not explicitly take a knowledge perspective when aiming at business process

improvements. Since a successful improvement of knowledge intensive business

processes is regarded to be stronger related to the improvement of knowledge flows

rather than work flows [RL00], the above mentioned approaches however com-

prise noticeable improvement potentials. BpoKM approaches that focus on busi-

ness process improvement are typically twofold: They either consider knowledge

implications when redesigning business processes (focus on improving organiza-

tional knowledge flows) or utilize new instruments from knowledge management

to improve business processes (focus on improving organizational work flows).

3.8.2 Benefits

The benefits of bpoKM approaches that focus on business process improvement

are somewhat obvious. All such efforts contribute to improvements concerning

either work or knowledge flows. Both benefits aim to fulfill an organization’s

overall business goals to a higher degree.


Approaches that focus on the improvement of business processes exist and are

briefly described in this section.

KODA

KODA (KOmmunikationsDiAgnose) [AHMM02] represents a methodology

and an accompanying software tool developed by IMS (Institute for Manu-

facturing Strategies) GmbH and Fraunhofer IFF (Institut fur Fabrikbetrieb

und -automatisierung). Based on software tool-supported interviews with

knowledge workers, KODA aids in eliciting information flows which are related

to organizational business process models. Thereby, KODA generates various

views (organizational, business process, resource, flow chart, responsibility and


communication views [AHMM02, page 147]) on an organization and aids in

identifying improvement potentials of existing business processes. Conducted

case studies [DHB01] report that with KODA, substantial improvements in

investigated business processes were achieved. While KODA seems to succeed

in improving and optimizing business processes, [Rem02] criticizes the fact

that no framework for the systematically deduction of knowledge management

interventions exists.

indiGO

indiGO (INtegrative software engineering through DIscourse supported GrOup-

ware) [VA+02, DRA+03] represents an approach developed in a joint effort be-

tween Fraunhofer IESE (Institute for Experimental Software Engineering) and

Fraunhofer AIS (Autonomous Intelligent Systems). This approach uses the con-

cept of process communities [Rem02] to improve current business process models.

Knowledge workers, who execute a common business process and are considered

to be part of a corresponding business process community, are engaged to partic-

ipate in online discourses about the structure, content or execution of regarding

business process. Finished discourses are analyzed in terms of their contributed

improvement suggestions and represent the basis for the development of new,

enhanced business process models.7

3.9 Assessment in the Context of this Work

Regardless of varying aspects, the introduced bpoKM approaches share one im-

portant common property: By orienting all considered knowledge management

interventions, methods or techniques to business processes, undertaken knowledge

management efforts visibly contribute to value chains of organizations. This not

only provides more feasible arguments for the benefits generated through knowl-

edge management projects but also integrates knowledge management activities

more tightly into daily work situations of employees.

The following paragraph aims to assess current accomplishments concerning the

7[VA+02] and [DRA+03] use the term “process learning” to describe the process of improvingbusiness processes. In this thesis, the meaning of the term “process learning” is used differently(as introduced in section 3.5).


identified bpoKM challenges and deduce conclusions for this PhD work.

• Business Process Modeling: Most bpoKM approaches regard the mod-

eling of knowledge-intensive business processes as a necessary basis for the

selection of KM interventions. Therefore, the enriched modeling of busi-

ness processes is relevant in the context of this PhD work. This domain

received much attention in past research, successful concepts for modeling

knowledge in business processes already exist and can act as a starting

point for tackling the goals of this work. However, a central challenge that

remains is: How exactly can these models aid the development of business

process-supportive knowledge infrastructures?

• Business Process Learning: BpoKM approaches focusing on business

process learning partly utilize business processes as an navigational index

to learning resources (as e.g. suggested in [RL00]). Thereby, employees have

to think in business processes (which itself is a questionable condition) in

order to navigate to relevant knowledge. Since considering human factors

is excluded from this PhD work, concepts from this domain only add little

to addressing the objectives of this PhD work.

• Business Process Support: Most bpoKM approaches focussing on busi-

ness process support are successful in niche domains (e.g. [Jan00, Har02]).

Existing comprehensive approaches typically lack detailed descriptions on

how to deduce necessary knowledge management interventions. While

GPO-WM [Hei01] successfully suggests knowledge management interven-

tions on a conceptual level, operative support for knowledge workers is not

among the major goals. The knowledge networks reference model [RES+00]

for example stresses the importance of designing ICT infrastructures to

support knowledge work processes too, but a comprehensive and scalable

approach for the development of knowledge infrastructures that support an

organization’s most critical knowledge intensive business processes is not

available yet. Nevertheless, by aiming to design support for knowledge in-

tensive business processes, existing approaches in this domain are tackling

goals similar to the objectives of this PhD work and provide valuable inputs

and stimuli.


• Business Process Execution: BpoKM approaches that focus on extend-

ing WFMS to support knowledge management typically struggle with rigid

workflow definitions that do not satisfy the needs of highly complex and

knowledge intensive processes. Here, the trend is to support weakly struc-

tured or ad-hoc WFMS that more capably aid employees in executing their

knowledge intensive business process activities. Examples for such efforts

are [PNAM02] (a modeling language for modeling weakly structured work-

flows) or [HTEN03] (a system for ad-hoc workflows). Since WFMS only

represent a very specific part of knowledge infrastructures (mainly contain-

ing and processing knowledge about business processes), few can be drawn

for addressing the objectives of this PhD work.

• Business Process Improvement: BpoKM approaches that focus on the

improvement of business processes have proven themselves successful in the

past. For example, KODA [AHMM02] elicits existing information flows in

business processes and, based on that, deduces business process improve-

ments from a knowledge perspective. Noticeable improvements in business

process performance were reported [DHB01]. Still, the identification of com-

plex knowledge processes that span multiple business processes remains a

challenging task. Such existing knowledge interactions between business

processes are considered to be the cause for the failure of BPR projects in

the past [Str03b]. Since approaches in this field partly focus on improving

knowledge processes, certain aspects of such approaches nevertheless are

relevant in the context of this work.

3.10 Focal Point of this PhD Work

The biggest challenge of bpoKM seems to lie in the development of knowledge

infrastructures that support an organization’s knowledge intensive business

processes in a way that suits both, an organization and its employees. No

comprehensive approach currently exists that provides detailed instructions on

how to develop such business process-supportive knowledge infrastructures. The

model of bpoKM challenges introduced in this chapter (see figure 3.1) represents

a profound ground for a classification of this PhD work. This PhD work aims

to provide guidance in the development of technological support for knowledge


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.


4.1 Introduction

When BMW1 planned a new automobile development center in Munich, the

requirements for the building hosting this center were somewhat different to

regular architectural projects: “Take care that the product development time

frame of our products declines from ten to four years” [Wol03]. The approach

that Gunter Henn, industrial architect responsible for designing the building,

took to address BMW’s objective provides an interesting ground for discussing

business process implications for organizations. When designing BMW’s new

development center, he analyzed its targeted product development processes

and elicited impacts on the building’s architecture. Thereby, business processes

became the basis for the design of a building that supports an organization’s

business goals [Str03b].

What can be drawn from this example is that business processes obviously

pose implications for the architecture of organizational buildings. In certain

cases, the implementation of these implications even seems to be mandatory

for organizations in order to effectively achieve their business goals. While

1BMW...Bayrische Motoren Werke

64

CHAPTER 4. PRINCIPLE APPROACH 65

a building’s architecture (in an industrial context) deals with optimizing the

management of physical entities (e.g. physical resources or employees), an

organizational knowledge infrastructure deals with optimizing the management

of knowledge. Although this analogy has its weaknesses2, it strikingly illustrates

the importance of linking organizational knowledge infrastructures to an organi-

zation’s business processes [Str03b].

The main goal of this work is to introduce a framework and an accompanying

tool that aid the development of business process-supportive knowledge infras-

tructures. The framework aims to resolve both identified challenges of chapter

1, which are: 1) support for the execution of knowledge flows across and within

business processes and 2) support for the application of typical KM functionality

in given business contexts. In this work, organizational business processes and

the central concept of knowledge processes represent the starting point for all sub-

sequent actions in knowledge infrastructure development projects. An accessible

introduction to the principle approach of this work follows.

4.2 Principle Approach

Figure 4.1: The Principle Approach of this PhD Work

Modeling of organizational knowledge work is not considered in traditional

business process modeling techniques. Also, knowledge intensive business pro-

cesses [ESR99] are typically weakly structured and therefore not capable of be-

ing a direct basis for the development of business process-supportive knowledge

infrastructures. A commonly used approach to overcome these problems is to

2also see footnote on page 31 about a constructivist view on knowledge


identify and model organizational knowledge (based on business processes, such

as [Str03a], [Rem02, chapter 11.3], [GPSW03]) that visualize relevant, executed

knowledge work in an appropriate way. Since support for knowledge inten-

sive business processes is regarded to be stronger related to supporting knowl-

edge work and flows rather than workflows [Rem01], the need to identify and

model knowledge processes becomes obvious. By modeling knowledge processes

which are considered to run within and/or orthogonally to business processes

[DHMS00, ON01, PP02], a concrete and profound basis for the development of

future business process-supportive knowledge infrastructures can be established.

Based on knowledge processes, knowledge infrastructure designs that aim to sup-

port the execution of these knowledge processes can be developed and thereby

can contribute to, given that the designs are successfully implemented, business

process-supportive knowledge infrastructures (see figure 4.1).

4.3 Central Concept of Modeling Knowledge

Processes

Since the concept of modeling knowledge processes is central to the principle

approach of this work, it is introduced in greater detail in this section:

4.3.1 On Modeling Aspects of Organizations

Investigating and analyzing complex systems such as organizations is typically

not accomplished through direct interventions with the system, but indirectly

through appropriate models of the system in question. In addition, modeling

is always connected to certain goals of investigations. According to [FS01], a

model consists of the triple (see figure 4.2):

M=(SO, SM ,f)

with SO being the object system under investigation comprising system ele-

ments VO, SM being a model system comprising system elements VM and f being

the model transformation SO → SM .


Figure 4.2: Object and Model Systems (Based on [Sin95])

In the context of modeling knowledge work of organizations, SO is a real sys-

tem (the organization and corresponding knowledge work), while SM is a formal

system (modeled knowledge processes). A main problem that comes with the

transformation of real systems into formal systems is that verifying structural or

behavioral consistency can only take place at an informal level [Sin95]. A key

criterion for the quality of such models is generally regarded to be the “Fitness for

Use” [Rem02]. To avoid that the quality of models only depends on the abilities

of modelers, model architectures (or meta models [Sin95]) including specifica-

tions of model elements, relationships, rules and semantics are introduced. A

model architecture enables modelers to check consistency and completeness of

their models as well as to check structural and behavioral consistency of their

models in a better (yet still informal) way.

4.3.2 Illustration of Modeling Knowledge Processes

In this section, an illustrative, yet abstract example of modeling and visualizing

organizational knowledge work is introduced. This example acts as an instru-

ment for the illustrative communication of the chosen approach for modeling

knowledge processes. Also, it lays the basis for the detailed definition of a model

architecture introduced in section 5.3. The model architecture provides a rich

meta model for modeling the current state of distributed, organizational work

through the concept of knowledge processes.


Figure 4.3 illustrates the results of fictive, process-oriented investigations in

a target organization. The knowledge work of process agents in three exem-

plary business processes regarding three fictive knowledge domains is depicted.

Thereby, the work of organizational roles in their respective business processes is

analyzed in terms of their contribution to four specific knowledge activities. The

visualization in figure 4.3 is especially appropriate for creating and validating

models of organizational work, since process agents can easily relate to it.

Figure 4.3: Modeling Knowledge Work of Business Processes (Based on [Str03a])

Example: In figure 4.3, the organizational role X generates knowledge about

the knowledge domain A in business process 1 step 1 (and in two other steps of

business process 2). The organizational role Z applies that knowledge in business

process 3 step 1 and 4.

By employing an orthogonal (knowledge oriented) view on figure 4.3, hidden

knowledge processes that are executed and/or are only partially documented in

organizational business processes now become visible in a way that is illustrated

in figure 4.4. Per knowledge domain, related business process steps and roles

(represented as e.g. BP1S3 | X - Business Process 1 Step 3 | Role X in figure

4.4) are illustrated to give an idea, where (during the course of which business

processes) and by whom (by which organizational role) this knowledge domain

is generated, stored, transferred and/or applied. Thus, redundancies, gaps, re-


lationships and/or interactions can be identified and analyzed on top of these

representations of knowledge processes. Although the arrows in figure 4.4 imply

a sequential execution of the considered specific knowledge activities, they do not

necessarily have to take place in that timely order [Str03a]. The question marks

in figure 4.4 depict potential flaws in organizational knowledge work.

Figure 4.4: Illustration of Resulting Knowledge Processes (Based on [Str03a])

Through analysis of modeled knowledge processes, a broad range of various

KM interventions all closely related to employees’ daily knowledge work can be

initiated (also see section 9). By utilizing the concept of knowledge processes

(which itself is based on the concept of business processes), organizational rel-

evance of the resulting models can be guaranteed (taking the basic conditions

formulated in section 5.5 into account).

4.3.3 Characteristics of Knowledge Processes

The following aspects are characteristic for and typically included in current

knowledge process approaches [Str03b] which mainly stem from the bpoKM

domain of Business Process Modeling (see chapter 3 on bpoKM). Knowledge

processes typically focus on a single knowledge domain and include descriptions


of:

Knowledge Flows: Knowledge flows depict business process relevant rela-

tionships between knowledge suppliers and enquirers. By identifying such rela-

tionships, communication channels that are considered to be essential in organi-

zational value chains become visible.

Specific Knowledge Activities: Specific knowledge activities (like the gen-

eration, externalization, storage, etc. of knowledge) further describe the handling

of knowledge within and/or across business processes. The distinction between

specific knowledge activities plays a vital role in the development of supportive

knowledge management interventions (as e.g. in [PRR98] or in [Rol03]).

Related Persons or Roles: By illustrating related persons or organizational

roles, critical knowledge workers of an organization become visible. This provides

a profound starting point for designing people- or role-centric knowledge manage-

ment interventions that support knowledge workers in their respective business

processes. Often, information about related persons or roles is gathered from

existing business process models.

Associated Business Processes: All of the above mentioned properties

implicitly referred to associated business processes. The relationship between

knowledge and business processes is obviously fundamental to the concept of

knowledge processes (that run within or across business processes) and therefore,

needs to be represented in knowledge process models.

4.4 Characteristics of Knowledge Infrastruc-

tures Following this Principle Approach

Knowledge infrastructures that were implemented based on the principle ap-

proach introduced here typically support knowledge processes that span multi-

ple business processes and organizational roles. Thereby, they route knowledge

from/to corresponding knowledge workers and thus provide focused access to

relevant knowledge for knowledge workers. The implementation of knowledge

processes within knowledge infrastructures leads to a more standardized and

managed way of knowledge work in organizations. Knowledge infrastructures


designed on the basis of knowledge processes are strongly related to the organi-

zation’s business processes and thereby can support them traceably.

4.5 Conceptualization of this PhD Work

The conceptualization of this PhD work is related to the principle approach

introduced in this chapter in a way that is illustrated in figure 4.5:

Figure 4.5: The B-KIDE Framework Conceptualization of this PhD Work

The B-KIDE Framework3 of this PhD thesis aims to provide guidance in the

business process oriented development of knowledge infrastructures and consists

of three main components: 1) the B-KIDE Model Architecture 2) the B-KIDE

Method and 3) the B-KIDE Context. While the B-KIDE Model Architecture

deals with aspects of modeling knowledge processes as a fundament for a large

set of heterogeneous challenges (also see chapter 9 “Future Applications”), the

B-KIDE Method focuses on the design of certain aspects of knowledge infrastruc-

tures (see focus and objectives of this PhD work in chapter 1) based on identified

knowledge processes. The B-KIDE Context describes the environment in which

the B-KIDE Framework and an accompanying software tool, the B-KIDE Tool,

is employed. The B-KIDE Tool supports the application of the B-KIDE Frame-

work. It aids knowledge analysts on an operative level in building models about

organizations and knowledge infrastructure designers in designing appropriate

3B-KIDE...Business process oriented Knowledge Infrastructure Development


knowledge infrastructures based on these models (similar to what [Tol98] defines

as method-tool companionship).

4.5.1 B-KIDE Context

The B-KIDE context introduced in section 5.2 briefly describes the anticipated

goals of the B-KIDE Framework, as well as participating roles, underlying as-

sumptions and targeted technological environments.

4.5.2 B-KIDE Model Architecture

The B-KIDE Model Architecture introduced in section 5.3 provides a set of direc-

tives for creating models of organizational knowledge work through the concept

of knowledge processes. In doing that, it not only offers a comprehensive model

architecture that allows for identifying and visualizing knowledge processes in

organizations, but also offers a sound fundament for a series of various subse-

quent analysis and design actions that go beyond the scope of this work (also see

chapter 9).

4.5.3 B-KIDE Method

The B-KIDE Method introduced in section 5.4 focuses on designing certain as-

pects (section 1.2.1) of business process-supportive, technological knowledge in-

frastructures on top of knowledge process models of organizations. The B-KIDE

Method guides knowledge infrastructure designers through the process of de-

signing knowledge infrastructures that comply with the objectives formulated

in chapter 1. In doing that, the B-KIDE Method represents a single, specific

application of the introduced B-KIDE Model Architecture.

4.5.4 B-KIDE Tool

By complementing the B-KIDE Framework, the B-KIDE Tool aids knowledge

analysts in efficiently identifying and analyzing knowledge processes in business

process oriented organizations (also see chapter 6). During business process ori-

ented interviews with employees of a target organization, the tool supports knowl-

edge analysts in structuring, capturing, verifying and validating interview data.


Figure 4.6: Focus of the B-KIDE Tool

Subsequently, the tool provides a set of specific reports (model perspectives) that

aid knowledge infrastructure designers in the development of business process-

supportive knowledge infrastructures (Figure 4.6).

Chapter 5

B-KIDE Framework

Problems cannot be solved at the same level of awareness that created them.


5.1 Introduction

This chapter introduces the B-KIDE Framework in detail. The context in which

the B-KIDE Framework gets applied is described and subsequently, the B-KIDE

Model Architecture for modeling organizational knowledge processes and the B-

KIDE Method for designing business process-supportive knowledge infrastruc-

tures are introduced. Whenever appropriate, the UML1, a sophisticated, object-

oriented modeling language is utilized to structure and conceptualize the frame-

work and its elements. Knowledge about the UML specification [Gro] is assumed

by the author and a prerequisite for appropriately interpreting the following UML

diagrams.

5.2 B-KIDE Context

Figure 5.1 depicts the environment, in which the B-KIDE Framework and the B-

KIDE Tool are applied. Goals addressed, roles involved, assumptions made and

technological conditions concerning the application of the B-KIDE Framework

are introduced in this section.

1UML...Unified Modeling Language

74

CHAPTER 5. B-KIDE FRAMEWORK 75

Figure 5.1: Context of Applying the B-KIDE Framework and Tool (Based on

[Tol98])

5.2.1 Goals

The B-KIDE Framework and the accompanying B-KIDE Tool aim to provide

methodological and conceptual as well as tool support for the development of

business process-supportive, technological knowledge infrastructures that fulfill

the requirements defined in section 1.2.1.

5.2.2 Roles

The B-KIDE Framework aids knowledge analysts in modeling organizational

knowledge work as well as knowledge infrastructure designers in the design of

business process-supportive knowledge infrastructures. The B-KIDE Tool op-

eratively supports knowledge analysts in building models about organizational

knowledge work and knowledge designers in analyzing the models of knowledge

work as a basis for the design of appropriate knowledge infrastructures.

5.2.3 Limitations

Business process modeling, which itself represents a research domain at its own,

is beyond the scope of the B-KIDE Framework. The reason to that is because

in many organizations business process models already are available [isoa, isob]


and play a prominent role. Beneath that, the implementation of the developed

knowledge infrastructure designs is also not within the focus of the framework.

Implementation of knowledge infrastructures in organizations depends on a large

spectrum of influencing, sometimes even conflicting factors (such as corporate

culture, existing knowledge barriers or social resistance). A consideration of such

aspects is typically attributed to the domain of change management and is not

dealt with in this work.

5.2.4 Assumptions

The B-KIDE Framework focuses on the initial, static identification of currently

executed knowledge processes in organizations as a basis for the development

of business process-supportive knowledge infrastructures. Dynamic aspects of

knowledge processes (e.g. change over time, also see section 8.2) are not con-

sidered. By relating the SER2-Model introduced by [FMO+94] to the context of

this work it becomes clear that the B-KIDE Framework contributes to a seeding

phase of knowledge infrastructure development.

5.2.5 Technological Environment

The B-KIDE Framework aims to provide support in the development of

knowledge infrastructures on an implementation- and vendor-independent level.

Thereby, resulting knowledge infrastructures can be represented through orga-

nizational intranets, file servers, document-, content- or knowledge management

systems or any other technological basis that is able to fulfill the requirements

defined in section 1.2.1.

5.3 B-KIDE Model Architecture

The B-KIDE Model Architecture provides directives for creating models of or-

ganizational knowledge work. It consists of two main elements: 1) a modeling

structure (section 5.3.1) and 2) a modeling technique (section 5.3.2). These two

elements correspond to what [HvR00] describe, in the context of modeling object

systems, as the “Way of Modeling” and the “Way of Working”. The modeling

2SER...Seeding - Evolutionary Growth - Reseeding


structure (The Way of Modeling) introduces the conceptualizations that are used

in a modeling effort (notations, conceptual structures) while the modeling tech-

nique (The Way of Working) describes the procedures by which models about an

object system are constructed (the process).

Figure 5.2: Scope of the B-KIDE Model Architecture

The modeling structure depicted in figure 5.2 is described by the conceptual

B-KIDE Modeling Structure in UML (see figure 5.3 on page 79), while knowl-

edge process modeling is described by means of the B-KIDE Modeling Technique

(see figure 5.6 on page 87). The input for the B-KIDE Model Architecture is

represented through (modeled) business processes (see section 5.5 on page 98),

while the output represents modeled organizational knowledge processes about

the object system (see figure 5.5 on page 86).

5.3.1 B-KIDE Modeling Structure

The B-KIDE Modeling Structure defines how organizational knowledge work is

being modeled within the B-KIDE Framework. Figure 5.3 depicts the essential

elements and relationships of the modeling structure illustrated by a conceptual

UML diagram.

Figure 5.3 is explained in greater detail in the following sections by introducing

1) essential elements, attributes and relationships 2) reference models, 3) the

model of organizational work and 4) model perspectives.


Figure 5.3: The B-KIDE Modeling Structure

Essential Elements, Attributes and Relationships

The basic elements of figure 5.3 are Knowledge Work, Business Process,

Undefined Work Activity, Organizational Role, Knowledge Domain, Specific

Knowledge Activities, Generation Object, Storage Object, Transfer Object and

Application Object :

Knowledge Work: Knowledge Work is performed whenever knowledge

of a certain Knowledge Domain is processed (generated, stored, transferred or

applied) by an Organizational Role within a Business Action. To be compliant

with the introduced definition of section 1.4, Knowledge Work needs to be

related to at least one specific knowledge activity.

Business Process: Business Processes represent an organizational environ-

ment in which Knowledge Work is performed. The element Business Process

has an attribute Descriptive Title containing a descriptive name for the Business


Process.

Undefined Work Activity: An Undefined Work Activity represents the

complement set to Business Processes. These activities contain all organizational

Business Actions not modeled in Business Processes.

Organizational Role: An Organizational Role is responsible for executing

organizational Knowledge Work, within a Business Action. The element

Organizational Role has an attribute Descriptive Title containing a descriptive

name for the Organizational Role.

Knowledge Domain: A Knowledge Domain represents a topical field of

knowledge which is relevant in the context of undertaking Business Actions.

The element Knowledge Domain is attributed regarding a set of dimensions:

Descriptive Title contains a descriptive name for the Knowledge Domain, Buzz

Words contains a set of distinctive words (typically strongly rooted in the

specific language of the target organization) that further refine the meaning

of the Knowledge Domain. Knowledge Domain Type allows for classifying the

type of knowledge (e.g. procedural vs. descriptive) and Knowledge Domain

Assessment allows for assessing the Knowledge Domain regarding its relevance

in the target organization. Here it is important to note that a knowledge domain,

in order to be compliant with the introduced definition of section 1.4, needs to

be related to at least one specific knowledge activity.

Specific Knowledge Activities: Specific Knowledge Activities represent

qualified associations (such as the generation, storage, transfer and applica-

tion) between Knowledge Work and Knowledge Domains. Specific Knowledge

Activities are further refined by additional Generation, Storage, Transfer and

Application Objects. Structure and attributes of these objects, which represent

extensions to the principle approach introduced in chapter 4, are adaptable to

specific contexts.

Generation Object: The Generation Object further details the specific

knowledge activity generation. It represents applied techniques (such as synec-


tics, random stimuli, assumption smashing, etc.) or instruments (such as

brainstorming tools, simulations, etc.) [Rol03, chapter 5] that aid knowledge

workers in the process of knowledge generation. The element Generation Object

has an attribute Descriptive Title containing a descriptive name for the object.

Storage Object: The Storage Object describes how explicit knowledge of

certain Knowledge Domains is stored (e.g. in documents, systems, books, etc.)

in a target organization. The Storage Object allows for a more comprehensive

modeling of storage activities. A Storage Object is related to Organizational

Roles and Formally Responsible Business Processes3 and comprises explicit

knowledge of a Knowledge Domain. The attribute Locality contains a geographi-

cal or virtual place where the Storage Object is stored, Descriptive Title contains

a descriptive name and Description contains prose text to further refine the

meaning of the Storage Object at hand.

Transfer Object: The Transfer Object describes how knowledge of certain

Knowledge Domains is transferred (e.g. in meetings, through e-mail or informal

communications, etc.) in a target organization. Responsible senders as well

as receivers of knowledge transfer situations are depicted through relating the

Transfer Object to Organizational Roles as well as to Formally Responsible

Business Processes4. A Transfer Object has an attribute Periodicity that

contains information about the frequency of the knowledge transfer situation.

Descriptive Title contains a descriptive name and Description contains prose

text to further refine the meaning of the Transfer Object at hand.

Application Object: The Application Object further details the specific

knowledge activity application. It represents all applied instruments and

techniques that take aspects of knowledge application (such as pedagogy) into

account. This includes, but is not limited to e.g. checklists, learning materials,

information retrieval instruments, training, mentoring, coaching and others.

The element Application Object has an attribute Descriptive Title containing a

3To reduce complexity in figure 5.3, these relationships are not depicted there. More detailscan be found in section 6.3

4Again, for the same reason, these relationships are not depicted in figure 5.3. More detailscan be found in section 6.3


descriptive name for the object.

Distinction between Storage and Transfer Objects: Since a distinction

between storage and transfer objects is not always obvious, the following

definitions aim to provide clarification:

Definition 1: An Object is a Storage Object whenever the object in question

is stored by an individual or system and is available to others.

Definition 2: An Object is a Transfer Object whenever the object in

question is intentionally transferred by an individual or a system to a receiver,

and the receiver reliably receives the object.

Example 1: An electronic document residing on an intranet represents a Stor-

age Object, since the document is stored on a drive which is available to others,

but the document is not intentionally transferred to receivers. Example 2: A

private e-mail communication represents a Transfer Object, since the e-mail is

intentionally and reliably transferred to a receiver, yet the e-mail itself is not

available to others. Example 3: An e-mail list represents both a Storage and a

Transfer Object, since the e-mail list is stored in an archive that is available to oth-

ers and e-mails are intentionally and reliably transferred to receivers (subscribers

of the e-mail list).

Reference Models

Within the B-KIDE Modeling Structure, certain elements are organized in hier-

archically5 structured reference models (similar to the ARIS-House concept by

[Sch00]). These elements are called reference elements. Reference models fulfill

the purpose of ensuring uniqueness of elements (such as knowledge domains, busi-

ness processes, etc.) in models of organizational work. This is considered to be

a critical factor for validation of developed models [KS98]. Here, reference mod-

5In certain cases (e.g. extensively complex business process landscapes) more sophisticatedstructures than hierarchical ones may be necessary. Topic maps [Pep00, Top01] represent aconcept that is well equipped for modeling such complex structures and can, if necessary, beintegrated into the B-KIDE Framework easily.


els represent no generic blueprints that are applicable across various knowledge

infrastructure development projects, but a set of unique elements instantiated

per project. In total, seven reference models exist (see table 5.1): a business

process-, knowledge domain-, organizational roles-, storage object- and transfer

object reference model. The business process reference model aims to repre-

sent existing business process landscapes, the knowledge domain reference model

aims towards structuring knowledge domains according to knowledge structure

diagrams [Noh00], the organizational roles reference model represents existing

organizational structures, the generation object reference model contains existing

instruments applied for the generation of knowledge, the storage object refer-

ence model structures existing knowledge storage possibilities, the transfer object

reference model structures existing knowledge transferring instruments and mech-

anisms and the application object reference models contains existing instruments

that aid the application of available knowledge. The power of these reference

models lies in the integration of existing business conceptualizations such as hier-

archical organizational structures and the introduction of new conceptualizations

such as generation, storage, transfer or application object reference models that

together allow for the comprehensive modeling of organizational knowledge pro-

cesses. Within the B-KIDE Framework, reference models are used as a common

conceptualization of certain dimensions of organizational knowledge work.

Reference Model Business Analogy

Business Process Reference Model Business Process Landscape

Knowledge Domain Reference Model Knowledge Structure Dia-

gram

Organizational Roles Reference Model Organizational Structures

and Hierarchies

Generation Object Reference Model N/A

Storage Object Reference Model N/A

Transfer Object Reference Model N/A

Application Object Reference Model N/A

Table 5.1: B-KIDE Reference Models and Business Analogies


The Model of Organizational Knowledge Work

The aforementioned elements and reference models are networked (according to

the relationships defined in figure 5.3) to a model of organizational knowledge

work. The modeling technique described in section 5.3.2 explains how the process

of modeling is performed with the B-KIDE Framework. In chapter 6, the B-KIDE

Tool is introduced that represents an instrument that aids knowledge analysts in

creating these models.

Model Perspectives

The B-KIDE Model Architecture enables the creation of model perspectives

(or view points as depicted in figure 5.1) on an object system. This allows

for performing the transformation illustratively introduced in 4.3.2. While the

B-KIDE Model Architecture allows for a broad range of model perspectives (see

chapter 9), two perspectives are of special relevance in the context of this PhD

work. These two model perspectives are introduced in table 5.2 and are further

defined6 in figures 5.4 and 5.5.

Model Perspec-

tive

Central Structuring

Element

Purpose

Business Process

Perspective

Business Processes Basis for the Creation and

Validation of the Model

Knowledge Process

Perspective

Knowledge Domains Basis for the Development

of Knowledge Infrastructure

Designs

Table 5.2: B-KIDE Model Perspectives

Business Process Perspective:

The business process perspective in figure 5.4 represents a traditional approach

6The introduced UML diagrams of model perspectives in this section define how the modelperspectives need to be structured in order to fulfill their respective tasks. They depict a spe-cific processing result achieved through transformation operations performed on the modelingstructure in figure 5.3. Thus, the UML diagrams themselves do not contain information abouttransformation operations.


to modeling knowledge in business processes (such as [All98, GPSW03]). The

main structuring elements of this perspective are business processes. Thus,

along business processes, the generation, storage, transfer and application

of knowledge by organizational roles is illustrated. This perspective, which

corresponds to the principles introduced in figure 4.3, is especially useful to

validate the created models with organizational reality, since knowledge workers

of a target organization easily can relate to the (already familiar) business

process models. However, the business process perspective is no sound basis for

the deduction of business process-supportive knowledge infrastructures because

of the focus on work- instead of knowledge flows and thus, raises the need for an

additional view on the created model.

Figure 5.4: The B-KIDE Business Process Perspective

Knowledge Process Perspective:

The knowledge process perspective in figure 5.5, which corresponds to the prin-

ciples introduced in figure 4.4, represents an orthogonal view on the business

process perspective [Str03a]. The main structuring elements of this perspective

are not business processes, but knowledge domains. Along knowledge domains,

business processes (respectively business actions) together with organizational

roles that contribute to the generation, storage, transfer and application of the


Figure 5.5: The B-KIDE Knowledge Process Perspective

knowledge domain in question are illustrated. Thereby, the knowledge process

perspective allows to easily “follow” the flow of knowledge through an organi-

zation. Additional information about the way, how the knowledge domain in

question is generated (Generation Object), stored (Storage Object), transferred

(Transfer Object) and applied (Application Object) complement the knowledge

process perspective. This perspective represents the core concept of this PhD

work and the central input for the B-KIDE Method (described in section 5.4).

5.3.2 B-KIDE Modeling Technique

Introduction

Modeling within the B-KIDE Framework is based on structured, process-oriented

interviews with knowledge workers of a target organization. The knowledge ana-

lyst performs interviews with certain organizational roles. The main instrument

for performing the interviews is the B-KIDE Tool (introduced in chapter 6) that

represents a specific implementation of the B-KIDE Modeling Structure (section

5.3.1).

The modeling technique in figure 5.6 describes the way of modeling organiza-

tional knowledge work with the B-KIDE Framework. The process is divided into

four main sub activities that are introduced in this section:


Figure 5.6: The B-KIDE Modeling Technique

B-KIDE Modeling Technique

Scope Definition page 87

Pre-Modeling page 88

Object System Modeling page 88

Model System Refinement page 90

Table 5.3: B-KIDE Modeling Technique Activities

Modeling Activity 1: Scope Definition

Decision on a Target Area: A decision upon the target area of the anticipated

knowledge infrastructure needs to be made. This decision has to define targeted

business processes at a targeted abstraction level as well as targeted roles that

shall be supported with the future knowledge infrastructure.

Selection of Interviewees: A minimum of two interview partners per

targeted role needs to be interviewed. While the first interview partner represents

an expert in his (process) domain, the second represents an intermediate that

knows the basics of the organization and its processes, but is relatively new

to it. The reasons for that are twofold: First, by interviewing two persons

per role, a more comprehensive understanding about organizational roles and

their functions can achieved while second, the mixture of an expert and an

intermediate is able to identify a richer spectrum of existing knowledge processes.

Development of an Interview Plan: An interview plan (as depicted in

appendix section C.2) aids a knowledge analyst in better organizing his sched-

uled interviews. The interview plan typically includes a description of targeted

business processes, targeted organizational roles and persons as well as the timely


sequence of the interviews.

Modeling Activity 2: Pre-Modeling

Gathering Existing Documentation: Documentation that is useful in the

context of modeling organizational work needs to be gathered and analyzed.

Such documentation includes existing business process models, knowledge

structure diagrams, hierarchical organization charts, business strategies (as a

starting point for deducing knowledge structure diagrams), existing technological

systems, filing structures, communication channels and others. This material

represents a sound basis for preparing the B-KIDE reference models.

Pre-Modeling B-KIDE Reference Models: With the material gathered,

parts of the reference models introduced in section 5.3.1 can well be prepared

before actually starting to model the object system of organizational knowledge

work through interviews. The business analogies of table 5.1 depict which ex-

isting organizational documentation can be utilized for this purpose. Although

no business analogy for generation, storage, transfer and application object ref-

erence models exist, they as well can be prepared by coarsely listing all relevant,

currently known, generation, storage, transfer and application objects. In order

to enhance the quality of pre-modeling efforts, e.g. knowledge domain reference

models can be refined by performing pre-interviews with domain experts. Also,

relationships between roles and business processes need to be assigned based on

existing business process models. This is a necessary input for appropriately set-

ting up the B-KIDE Tool (chapter 6) for interviews. Pre-modeling significantly

lowers the burden of work for knowledge analysts during interview situations.

Modeling Activity 3: Object System Modeling

Interview Preparation: For each interview, the knowledge analyst prepares

himself according to the interview guidelines of appendix C.

Interview Organization: The knowledge analyst performs a set of inter-

views with employees in order to model the object system of organizational

knowledge work according to the B-KIDE Modeling Structure. In each interview,


he has to clearly communicate the goals as well as the content of the interview to

the interviewee. He introduces the interview process and subsequently, starts to

collect information from the interviewee by asking the corresponding questions

and using the B-KIDE Tool introduced in chapter 6.

Object System Modeling: The knowledge analyst guides each interviewee

through process-oriented interviews. In each interview, he gathers information

about the knowledge work of the interviewee in the respective business processes

(according to the business process perspective introduced in section 5.3.1) and

refines the pre-modeled reference models. In doing that, the knowledge analyst

utilizes (provisional) reference models of past interviews for current interview

situations. This is in stark contrast to approaches such as [KHS03, page 269]

which define (knowledge) ontologies a priori and, in a strict order, subsequently

utilize these ontologies as a basis for knowledge flow identification. Because

during knowledge flow identification activities (such as structured interviews) new

knowledge domains may come up, pre-modeled (knowledge) ontologies strongly

need revision. Concerning an iterative approach of modeling reference models,

[SAA+02] remark:

“This is typical of elicitation: the (provisional) knowledge structures

the analysts build are subsequently used to focus the elicitation of ex-

pertise data.” [SAA+02, page 206]

Of special importance is the challenging task of matching knowledge domains

(that depict results of previous interview situations) to current interview

situations. Here, the knowledge analyst has to decide if an interview partner A

and an interview partner B talk about similar, identical or separate knowledge

domains. The B-KIDE Model Architecture supports knowledge analysts in this

task by providing room for detailed descriptions of knowledge domains as well as

organization-specific buzz words that add helpful meaning to knowledge domains.

Model System Validation: At the end of each interview, the knowledge

analyst confronts the interviewee with the information gathered during this inter-

view (through an appropriate, interview centered business process perspective).

The knowledge analyst together with the interviewee correct and validate this


perspective7. Before officially closing the interview, it is helpful, to exchange

contact details between the knowledge analyst and interviewee, to be able to

deal with open questions or complementary comments that may emerge after the

interview.

Modeling Activity 4: Model System Refinement

Reference Model Organization: After completing each interview, the

knowledge analyst reorganizes the hierarchical reference models according to

his gained understanding about the object system. Although the knowledge

analyst (the modeler) slightly influences the model system in doing that, this

activity supports the knowledge analyst in subsequent interview situations. Also,

relationships between various reference models are not concerned by reorganizing

specific reference models.

Reference Elements Refinement: Since in interview situations the knowl-

edge analyst is typically under time pressure, he may not be able to gather all

necessary information in an appropriate way. This activity therefore allows the

knowledge analyst to refine descriptions of e.g. only coarsely described knowl-

edge domains. During the development of knowledge infrastructure designs, these

descriptions will help knowledge infrastructure designers in gaining a better un-

derstanding about the object system.

5.4 B-KIDE Method

The B-KIDE Method introduces a normative design process Designing Knowl-

edge Infrastructures that leads KI designers through necessary design activities.

In addition, a knowledge infrastructure template architecture acts as a funda-

ment for the design of technological knowledge infrastructures that address the

objectives of this PhD work.

The KI template architecture depicted in figure 5.7 is described by the knowl-

edge infrastructure template architecture in UML (see figure 5.9 on page 96),

while Designing Knowledge Infrastructures is described by a normative design

7Aspects of validation include checks for 1) self consistency, 2) uniqueness of model elementsand 3) model accuracy (based on [KS98, p.103-104]).


Figure 5.7: Scope of the B-KIDE Method

process in section 5.4.1 (see figure 5.8 on page 92). The input for the B-KIDE

Method is represented through modeled knowledge processes (see figure 5.5 on

page 86), while the output represents a knowledge infrastructure design that

appropriately supports knowledge processes (see chapter 7 on page 118).

5.4.1 Design Process “Designing Knowledge Infrastruc-

tures”

For the development of knowledge infrastructures that support an organization’s

knowledge intensive business processes, a normative design process is introduced.

Based on knowledge processes identified by knowledge analysts, this design pro-

cess aids KI designers in integrating identified (knowledge) requirements into

their knowledge infrastructure designs. Typically, design is either perceived as

a product or a process. Because of the emergent field of knowledge manage-

ment systems and vendors and the lack of common conceptualizations, this work

predominately focuses on a process approach to design. Thereby, the resulting

approach can be applied across different knowledge management system vendors

and conceptualizations. In this PhD work, the following definition of design by

[YC79] is applied:

“Design means to plan or mark out the form and method of a solution.

It is the process which determines the major characteristics of the final

system [...].” [YC79, p. 8]


The design process consists of three main design activities illustrated in figure

5.8: 1) Preliminary Knowledge Process Definition 2) Knowledge Infrastructure

Design and 3) Knowledge Infrastructure Design Validation.

Figure 5.8: Design Process “Designing Knowledge Infrastructures”

Design Activity 1: Knowledge Process Definition

Knowledge processes represent the major imperative for the design process. By

integrating requirements from knowledge processes in knowledge infrastructure

designs, the resulting knowledge infrastructures are able to provide comprehen-

sive support for knowledge intensive business processes. To specify these require-

ments, the knowledge infrastructure designer uses the identified as-is knowledge

processes and, together with knowledge workers and representatives of the man-

agement, defines to-be knowledge processes based on them. To achieve agreement

about the final knowledge process definitions between a set of different project

stakeholders and constraints, a quality gateway [RR99] is utilized:

“The quality gateway is the activity where each knowledge process is

examined to determine if it is suitable for inclusion in the specifica-

tion.” (Based on [RR99, page 182])

In order to be able to decide upon the inclusion of knowledge processes, a

clear picture about 1) the organizational roles that need to be supported8 and 2)

the specific goals that the knowledge infrastructure development project pursues

8This decision may already be made in section 5.3.2. Nevertheless, at this point, the decisionmay be altered and the scope may be narrowed because of new identified constraints or findings.


is essential. To define these goals, fit criteria [RR99] need to be developed. Fit

criteria allow for checking the developed knowledge infrastructure design9 for

integration of appropriate knowledge process support. While the fit criteria are

developed in this design activity, the check is performed later on - in design

activity 3 in section 5.4.1. Examples for such fit criteria10 are:

• Organizational roles shall have appropriate access to the knowledge they

need to apply in the KI.

• Organizational roles shall be able to appropriately provide the defined

knowledge to the KI.

• Defined storage objects shall appropriately be supported and managed by

the KI.

• Knowledge shall appropriately be transferred by the KI.

In the process of defining to-be knowledge processes, the meaning of appro-

priate in the context of each organization has to be determined while at the

same time taking framing conditions such as financial, organizational or techno-

logical constraints into account. An example for such conditions would be the

support of existing knowledge processes through the mandatory application of

certain knowledge management system functionality (such as Hyperwave Por-

tals [Hyp]). In such a case, only as-is knowledge processes focussing on explicit

knowledge may be considered, and only functionality provided by the knowledge

management system Hyperwave may be utilized to provide support.

Fork A in figure 5.8 illustrates the two principle ways the B-KIDE Method

can be applied: Option 1 represents a way to evaluate existing KIs and KI designs

for improvement potentials while option 2 specifies new knowledge infrastructure

designs from scratch.

9Here, knowledge infrastructure design is understood as a product; e.g. a design documentthat marks out the form of the final solution.

10While the fit criteria introduced here apply well to designing technological aspects of knowl-edge infrastructures, other fit criteria (such as [Kun02, chapter 3]) may be adopted when itcomes to designing e.g. organizational aspects.


Design Activity 2: Preliminary Knowledge Infrastructure Design

The KI template architecture introduced in section 5.4.2 together with knowledge

process definitions represent the main input for this design activity. Here, the

template architecture introduced in section 5.4.2 is instantiated according to

the constraints of each KI development project. In each template architecture

layer the KI designer considers the requirements specified by the knowledge

process definitions. Thereby, the KI designer either designs and introduces a

new technological infrastructure, or alters existing infrastructures to enhance

technological environments of knowledge workers. The fit criteria developed in

design activity 1 (which are applied in design activity 3 in section 5.4.1) already

guide the KI designer in his design efforts. This not only allows him to perform

the design process in a more efficient way, it also reduces the complexity of this

task.

The knowledge infrastructure design typically consists of the four elements

of the knowledge infrastructure template architecture: 1) a content concept

that includes and defines all employed knowledge infrastructure objects and

-functionality. 2) a metadata concept that allows for accessing contents through

a certain set of different dimensions. 3) a structure concept that typically

describes the predominant way of navigating to contents and 4) An access

concept that defines users, roles and permissions for the anticipated knowledge

infrastructure. Finally these contents need to be integrated as described in

section 5.4.2. The development of these concepts allows to validate the KI design

in detail against the defined fit criteria in the next design activity.

Latest research work on how knowledge processes (and specific knowledge ac-

tivities) can be supported by KM technology (such as [Rol03]) especially aids

KI designers in designing the contents layer (defining the necessary contents and

functionality) of knowledge infrastructures. In addition to that, the access layer

can also well be designed by taking role-oriented views on the developed Knowl-

edge Process Landscape. Taking a role-perspective on knowledge work allows

KI designers to understand what contents and functionality of a knowledge in-

frastructure organizational roles need to access. To glue these layers together,

KI designers subsequently develop appropriate structure and metadata concepts


based on existing methods and techniques (also see section 5.4.2).

Design Activity 3: KI Design Validation

This design activity validates the developed KI design in terms of its support

for knowledge processes. The fit criteria developed in design activity 1 now

fulfill the purpose of an instrument that is utilized for validating the preliminary

knowledge infrastructure design. By checking each fit criterion against 1) every

defined knowledge process and 2) against the knowledge infrastructure design,

the knowledge infrastructure designer can identify fits as well as deficits in

the current design. A lack of sufficient fits leads to iterations through design

activity 2 and 3. Examples for performing that kind of validation includes

investigating the knowledge infrastructure design by means of role-oriented

inspection, checking for existence of necessary generation, storage, transfer and

application objects or examining support for knowledge flows. Fork B illustrates

this in case 2. Case 1 depicts a situation, where the knowledge infrastructure

design suffices the requirements identified and thus, can be utilized as a profound

basis for implementation.

To summarize:

The application of the B-KIDE Method yields to a design space that

is quantitatively open (in terms of the number of possible designs) but

qualitatively closed (in terms of the requirements supported).

In other words, the application of the B-KIDE Method in knowledge infrastruc-

ture development projects prescribes what needs to be implemented in the tar-

geted knowledge infrastructure designs (in the sense of functional requirements -

in order to support the defined knowledge processes), but not how this function-

ality is provided.

5.4.2 B-KIDE Knowledge Infrastructure Template Archi-

tecture

The knowledge infrastructure template architecture in figure 5.9 represents a

system architecture, which illustrates the basic layers of technological solutions


tackling the challenges introduced in section 1.2.1. The basic layers are: 1) Con-

tents 2) Taxonomies and Meta Knowledge11 and 3) Access. Based on identified

knowledge processes in organizations, the knowledge infrastructure template ar-

chitecture is instantiated per KI development project for the design of appropriate

knowledge infrastructures for organizations.

Figure 5.9: The Knowledge Infrastructure Template Architecture

Contents

All elements and services accessible to an organization through its ICT infrastruc-

ture (such as documents, templates, guidelines, lessons learned, chats, forums,

messages, e-mails, calendars, task lists, FAQs, e-learning modules, yellow pages,

agents, web sites, proprietary systems and others) are regarded to be part of

the contents layer of knowledge infrastructures. Comprehensive research work on

contents and types of contents of technological knowledge management systems

has been performed and is already available [Mai02, chapter 7]. These elements

and services (or contents) can be organized according to a set of different cate-

gories, as introduced in the next paragraph.

Taxonomies and Meta Knowledge

Taxonomies and meta knowledge allow for organizing the contents of knowledge

infrastructures. Taxonomies structure the contents of knowledge infrastructures

while meta knowledge enriches content by attaching descriptive information.

11Both taxonomies and meta knowledge represent concepts for knowledge organization andtherefore are grouped together


Both instruments represent the basis for accessing knowledge infrastructure

elements. Taxonomies and meta knowledge are regarded to pose a strong

influence on the usefulness of technological knowledge infrastructures. They 1)

determine how quick employees can navigate to contents and 2) represent the

basis for the employees’ mental models of the knowledge infrastructure. Thus,

both instruments have descriptive and normative aspects [Mai02, section 7.2.3].

Categorizations, which are utilized to structure and enrich knowledge infras-

tructure contents include, but are not limited to: domain-, process-, method-,

product-, project-, customer-, organization-, time-, person- and role-oriented

categorizations.

Taxonomies and meta knowledge concepts often utilize a combination of a

set of different categorizations. In practice, these concepts are typically devel-

oped heuristically in workshops, without much methodical support [Mai02, p.

204]. Instruments that could aid the structured development of such concepts

are standards (such as [Dub03, Ass02]), procedures (such as [DB03]), methods

(such as [MHA03]) or best practices (such as [RR03]). Ontologies too represent

a concept that can be utilized in such contexts (e.g. in [AML+01, KHS03]).

Access

The access layer consists of instruments for accessing the contents of technolog-

ical knowledge infrastructures. Such instruments can utilize hierarchical tree or

list navigation, catalogues (such as [Net04]), retrieval systems, complex visualiza-

tions (such as Infosky [KSG+03]) as well as portals [Dia01, Noh02, LSF+03]. All

instruments utilize the taxonomy and meta knowledge layer for providing access

to the contents layer below. The access layer thus represents an environment for

knowledge workers that aims to provide comprehensive support for their respec-

tive knowledge work. Standards for the formalization of access concepts already

exist and are available for application (such as [Ame03]).


5.5 Remarks on B-KIDE Framework Applica-

tion

The B-KIDE Framework represents an idealized way of executing knowledge

infrastructure development projects. Nevertheless, the framework can be

employed selectively in knowledge management projects: The B-KIDE Method

can be applied without detailed empirical knowledge process identification

(where e.g. the functionality of knowledge infrastructures is entirely defined by

an expert project team) or knowledge processes can be identified for analysis

purposes only (e.g. for identifying areas with a high potential of improvement).

Either way, the B-KIDE Framework provides means (such as the B-KIDE KI

Template Architecture or the B-KIDE Tool) that support knowledge analysts

as well as knowledge infrastructure designers in performing their corresponding

tasks. However, the power of the B-KIDE Framework lies in the strong ties

between analysis and design phases of knowledge infrastructure development

projects.

To be applicable, the framework relies on finding the following basic conditions

in target organizations:

• The target organization has implemented and lives a business process ori-

ented management approach which comprises modeled business processes.

• The business processes of the target organization represent a feasible way of

doing business. This is an especially necessary prerequisite, since this work

does not focus on improving certain business processes, but on supporting

a network of business processes appropriately.

• Employees of the target organization share a common set of vocabularies

and a common language when communicating business relevant issues.

• The target organization is regarded to be a knowledge-intensive organiza-

tion [ESR99] and is producing / delivering knowledge-intensive goods or

services.

• Key roles of the target organization are involved in knowledge intensive

activities [ESR99] and are available for structured interviews.


• The target organization has IT systems with knowledge management func-

tionalities (such as [MR02, MT02]) at its disposal and is willing to use

it.

• The target organization employs a culture that is open for change.

Chapter 6

B-KIDE Tool

Consistency is the last refuge of the unimaginative.


6.1 Introduction

Today, the identification of knowledge flows typically relies on fuzzy instruments

such as unstructured workshops, interviews or talks with employees of an orga-

nization. The B-KIDE Tool introduced in this chapter aims to provide software

functionality that is able to map interview data gathered from structured, pro-

cess oriented interviews with knowledge workers of a target organization onto

the B-KIDE Modeling Structure. In doing that, the B-KIDE Tool complements

the B-KIDE Framework (as depicted in figure 6.1). The relation between the

framework and the tool can best be described as a method-tool companionship

[Tol98].

6.1.1 Goals

The B-KIDE Tool aims to support knowledge analysts and knowledge infrastruc-

ture designers in applying the B-KIDE Framework. Therefore, the B-KIDE Tool

implements the B-KIDE Modeling Structure to provide a formal, supportive

instrument for process-oriented interviews that reduces complexity of applying

the B-KIDE Framework. The B-KIDE Tool aims to support a broad range of

analysis options on top of the developed models of organizational work in order

99

CHAPTER 6. B-KIDE TOOL 100

Figure 6.1: Scope of the B-KIDE Tool

to aid knowledge analysts as well as knowledge infrastructure designers in their

respective tasks (section 2.2).

To illustratively explain the goals of the B-KIDE Tool, a usage narrative

[Coc00] sketches up a typical application scenario:

Arthur, a knowledge analyst and knowledge infrastructure designer, is

in charge of developing and conceptualizing a technological knowledge

infrastructure for the company KnowIntBusiness Corp., which itself

is producing knowledge intensive goods in a knowledge intensive envi-

ronment. Since Arthur has to develop a knowledge infrastructure that

supports the company’s employees in their most critical, knowledge

intensive and value generating activities and tasks, he investigates the

company’s business processes from a knowledge perspective. There-

fore, Arthur performs a series of process-oriented interviews with

KnowIntBusiness Corp.’s knowledge workers, utilizing the B-KIDE

Tool to structure and prepare the interviews as well as to document

interview results according to the B-KIDE Modeling Structure. After

interviewing, Arthur uses various B-KIDE Tool Reports to analyze

and synthesize the gathered data in terms of various perspectives on

the developed model of organizational work. Based on these investi-

gations, and by applying the accompanying B-KIDE Method, Arthur

is able to lay out the design of a technological knowledge infrastruc-

ture that warrants a certain degree of support for KnowIntBusiness


Corp.’ employees in their respective business processes.

In section 6.4, the main functionality of the B-KIDE Tool in the light of this

usage narrative is introduced.

6.1.2 Scope

The B-KIDE Tool is designed to be applied by knowledge analysts and knowledge

infrastructure designers during knowledge infrastructure development projects.

Figure 6.2 illustrates the primary actors of the B-KIDE Tool.

Figure 6.2: Primary Actors of the B-KIDE Tool

6.1.3 B-KIDE Tool Approach

The B-KIDE Tool is a supportive instrument for structured, business process-

oriented interviews between knowledge analysts and knowledge workers of an

organization. The gathered interview data is analyzed and subsequently utilized

to lay out the design of business process-supportive knowledge infrastructures by

knowledge infrastructure designers.

Figure 6.3: B-KIDE Tool Principle Approach

Figure 6.3 illustrates the principle approach of the B-KIDE Tool. Front end

interview forms, applied by knowledge analysts during interview situations, pro-

vide means to map gathered interview data onto the B-KIDE Modeling Structure.


This ensures that gathered interview data conforms to the B-KIDE Modeling

Structure. On top of the interview data, a set of B-KIDE Tool Reports allows

for generating a wide range of different model perspectives and thereby allows

for generating different models of organizational work as a profound basis for

analysis.

In the next section, the main logical structure and the core elements of the B-

KIDE Tool are introduced.

6.2 B-KIDE Tool Structure

Figure 6.4: Simplified Illustration of B-KIDE Tool’s Main Structure and Elements

The B-KIDE Tool is based on the logical structure depicted in the simplified

illustration in figure 6.4. Thus, a B-KIDE project consists of multiple inter-

views and a set of (in total five) reference models1. Each interview contains

information about the interview context as well as the actual interview data.

Interview context contains information about the corresponding interviewee, his

organizational role, and the analyst who performs the interview. Interview data

contains all elicited, interviewee-specific interview information gathered through

a series of interview forms (further details in section 6.3.2). In addition to that,

1The Generation and Application Reference Models were not implemented in the B-KIDETool because of the foci of the anticipated pilot studies


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


6.3 B-KIDE Modeling Structure Mapping

This section describes the mapping of the B-KIDE Tool data structures onto the

B-KIDE Modeling Structure introduced in 5.3.1 on page 78.

6.3.1 Reference Models

Figure 6.6: Implementation of the B-KIDE Tool Reference Models

Figure 6.6 depicts how the reference models of the B-KIDE Modeling Struc-

ture are implemented in the B-KIDE Tool Reference Models area depicted in

figure 6.5. While each reference model is hierarchically organized, specific ref-

erence models can be interconnected with each other. Firstly, an assignment of

organizational roles to business processes2 takes place based on the organizational

involvement of roles in business processes. This lays the fundament for business

process oriented interviews where each interviewee is confronted with exactly

those business processes, which his role is involved in. Transfer Objects comprise

relations to organizational roles that act as senders or receivers in transfer activ-

ities. Storage Objects comprise relations to organizational roles that perform the

act of storing. Both Transfer and Storage Objects maintain linkages to business

processes in which these knowledge activities are defined.

2the so-called “Business Process-Roles Assignment” - also see appendix chapter C


6.3.2 Interview Data

Figure 6.7: Implementation of the B-KIDE Tool Interview Forms

The interview data area depicted in figure 6.5 is structured according to the

UML diagram depicted in figure 6.7. For each business process the interviewee

is involved in, an interview form is generated. Each interview form consists of

two interview data panels, one focussing on the generation and the other on the

application of knowledge by the interviewee. Interview data panels themselves

contain multiple interview lines. Each interview line is concerned with a spe-

cific knowledge domain that is either applied or generated by the interviewed

knowledge worker (based on communication request/respond patterns). For each

knowledge domain, communication partners (organizational roles in correspond-

ing business processes) and aspects of storage/transfer can be documented. The

B-KIDE Tool ensures the appropriate mapping of the gathered data onto the

B-KIDE Modeling Structure.


6.4 B-KIDE Tool Application

Application of the B-KIDE Tool can be divided in three main phases: 1) Setup

and Pre-Modeling 2) Interviewing and 3) Analysis.

6.4.1 Setup and Pre-Modeling

Before knowledge analysts actually can use the B-KIDE Tool for executing

process-oriented interviews, the tool needs to be appropriately set up. In

figure 6.8 the interface for setting up the context of a series of interviews is

illustrated. For each interview, an analyst, an interviewee and a corresponding

organizational role of the organization has to be assigned.

Example: In the depicted interview in figure 6.8, Arthur interviews Bill in

the role of a sales agent.

Figure 6.8: Setting Up Interviews with the B-KIDE Tool

In order to be able to start with to the execution of interviews, certain aspects

of the target organization need to be pre-modeled. A Business Process Reference


Model (based on e.g. an existing Business Process Landscape), as well as an Or-

ganizational Roles Reference Model (based on e.g. an existing organigram) rep-

resent a prerequisite for the B-KIDE Tool to generate a set of (process-oriented)

interview forms per interview, realized as windows form tabs (depicted in figure

6.9). These forms represent the underlying, formal structure for the anticipated

interviews. This ensures that, during interviews, interviewees are (exclusively)

confronted with business processes they are involved in.

Figure 6.9: B-KIDE Tool’s Interview Forms per Interview

Figure 6.10 illustrates how a new organizational role can be added to the

Organizational Roles Reference Model during pre-modeling.

Figure 6.10: Setting Up Reference Elements with the B-KIDE Tool

6.4.2 Interviewing

In interview situations, the B-KIDE Tool guides analysts through a series of

process oriented interview forms per interviewee. In doing that, the B-KIDE

Tool provides not only a (process-oriented) structure for the interviews, but

also displays questions that knowledge analysts need to ask during interviews

(depicted in figure 6.11, mouse pointer B). The B-KIDE Tool bases its questions


on request/response patterns of knowledge workers to identify knowledge

processes. Answers given by interviewees are modeled by dragging and dropping

reference elements from the Reference Model area (see figure 6.11, mouse pointer

A) to the respective answer fields in the process oriented interview forms within

the interview data area.

Figure 6.11: Inputting Interview Data with the B-KIDE Tool

Example: Knowledge analyst Arthur, utilizing the B-KIDE Tool, asks inter-

viewee Bill, what information he needs in order to be able to execute the business

process “Acquisition”, in which he is involved. Bill replies that information

about potential customers is necessary for him in order to successfully execute

this process. Arthur drags the already existing knowledge domain “knowledge

about customers” from the knowledge domain reference model to the respective

answer field in the interview data area (depicted in Figure 6.11, mouse pointer


A). The B-KIDE Tool notices this action and translates the established relation3

to the B-KIDE Modeling Structure. In doing that, knowledge work is modeled

in a way that was depicted and introduced in figure 4.3 on page 69.

In the likely event that new reference elements emerge during interview

situations, knowledge analysts can manipulate the respective reference models

by inserting, editing or deleting reference elements in a way that is depicted in

figure 6.10 and 6.12.

Figure 6.12: Editing Reference Elements with the B-KIDE Tool

Example: Figure 6.12 depicts a concrete example of editing the properties of

a specific reference element: The Transfer Object “Sales Meeting”. In this figure,

the Sales Meeting is a transfer object of the type “meeting”. This meeting takes

place weekly and during this meeting, marketing staff communicates information

about potential customers to sales agents. The meeting is not defined in any

modeled business processes.

3In prose, this relation can be described in the following way: In Business Process “Acqui-sition”, knowledge about customers is applied by the organizational role “sales agent”.


6.4.3 Analysis

The B-KIDE Tool supports the generation of two main, configurable analysis

reports: 1) the Business Process Landscape and 2) the Knowledge Process Land-

scape. Both analysis reports build on the model perspectives which were intro-

duced in section 5.3.1 on page 84.

Figure 6.13: Creating Analysis Reports with the B-KIDE Tool

The B-KIDE report assistant depicted in figure 6.13 assists knowledge infras-

tructure designers in generating analysis reports on top of gathered interview

data. These reports can be filtered according to specific interviews, organiza-

tional roles or specific knowledge activities (step 2 and 3 of the report assistant).

The built-in configurability of B-KIDE Tool reports allows for in depth and de-

tailed investigations of knowledge work in organizations as a basis for knowledge

infrastructure development.

Business Process Landscape

The Business Process Landscape in figure 6.14 depicts knowledge work of business

processes in a way that was introduced in figure 4.3 and thereby represents an

implementation of a Business Process Perspective. The Business Process Perspec-

tive utilizes business processes as the central structuring element. The generation,

storage, transfer and application of knowledge is depicted along the respective

business processes (see section 5.3.1).

In the simple example of figure 6.144, two business processes are depicted.

The visualization is interpreted in the following way: In business process “Acqui-

4This screenshot was graphically revised in order to increase comprehensibility of the con-cepts to be communicated


Figure 6.14: The B-KIDE Tool Analysis Report “Business Process Landscape”

sition” sales agents need to apply “Knowledge about Potential Customers”. In

the second business process “Market Analysis”, this knowledge about potential

customers is generated by the organizational role “Marketing”. The knowledge

domain is transferred through dedicated “Sales Meetings”, where “Marketing”

communicates “Knowledge about Potential Customers” to “Sales”.

Knowledge Process Landscape

The Knowledge Process Landscape in figure 6.15 depicts knowledge processes in

a way that is illustrated in figure 4.4 and thereby represents an implementation

of a Knowledge Process Perspective. The Knowledge Process Perspective utilizes

knowledge domains as the central structuring element. Business processes that

generate, store, transfer or apply knowledge are depicted along the respective

knowledge domain (see section 5.3.1).

In the example of figure 6.155, the knowledge process resulting from figure

6.14 is introduced. The visualization is interpreted in the following way: The

knowledge domain “Knowledge about Potential Customers” is generated in the

5This screenshot was graphically revised in order to increase comprehensibility of the con-cepts to be communicated


Figure 6.15: The B-KIDE Tool Analysis Report “Knowledge Process Landscape”

business process “Market Analysis” by the organizational role “Marketing”. The

knowledge domain is transferred via “Sales Meetings” (In the “Market Analysis”

business process) to “Sales”, who need to apply it in their respective business

process “Acquisition”. The knowledge domain is not stored in any way.

6.5 B-KIDE Tool Support for the B-KIDE

Framework Application

The B-KIDE Tool represents an implementation of the B-KIDE Modeling

Structure and thereby reduces complexity of applying the B-KIDE Framework.

This means that the B-KIDE Tool provides support for applying the: 1) the

B-KIDE Modeling Technique and 2) the B-KIDE Method.

Support for the B-KIDE Modeling Technique: The B-KIDE Tool pro-

vides support for various phases of the B-KIDE Modeling Technique (see section

5.3.2). During “Scope Definition”, it provides means to structure and capture

interview context information (as illustrated in figure 6.8). “Pre-Modeling”

is supported by providing means to setup reference models in a structured,

hierarchical way. By providing a set of specific attributes for each reference

element (as depicted in figure 6.12), the descriptive power of reference elements

is further enhanced. During interviews, the B-KIDE Tool provides knowledge


analysts with an organized, process-oriented procedure, with predefined ques-

tions and a structured concept for answering them (figure 6.11). In doing that,

the B-KIDE Tool ensures that the gathered interview data is organized in a way

that conforms to the B-KIDE Modeling Structure. Validation of the gathered

interview data is supported through a user interface that knowledge analysts

can present to interviewees at the end of interviews. After the execution of

interviews, knowledge analysts can input additional interview information into

the B-KIDE Tool and thereby refining the data gathered during the interview.

Support for the B-KIDE Method: The B-KIDE Method receives mani-

fold support from the application of the B-KIDE Tool in knowledge infrastructure

development projects. First and foremost, the B-KIDE Tool Knowledge Process

Landscape (figure 6.15) represents the most important input for the B-KIDE

Method. By supporting the configurable generation of analysis reports (as de-

picted in figure 6.13), the B-KIDE Tool allows for differentiated assessments of

the gathered interview data. The generated reports aid knowledge infrastructure

designers in understanding knowledge work in a target organization, questioning

support of existing knowledge infrastructures as well as in suggesting new fea-

tures for improved infrastructures. The B-KIDE Tool also allows for selecting

and marking certain (high priority) knowledge domains - an important function

when it comes to the design activity “Knowledge Process Definition”. In this

activity, as-is knowledge processes are assessed and to-be knowledge processes

are defined. Since the B-KIDE Tool generates XML- and vector-based reports

which are processible with modern graphical software applications such as Mi-

crosoft Visio c© [Micc], the identified knowledge processes (generated through the

Knowledge Process Landscape analysis report) themselves can become the basis

for the definition of to-be knowledge processes.

6.6 B-KIDE Tool Implementation

The B-KIDE Tool implementation is based on Microsoft’s .NET Framework c©[Micb] and the programming language VB.NET utilizing an object-oriented ap-

plication and data structure. The .NET Framework, with its main components

depicted in figure 6.16, is considered to be a


“Set of software technologies for connecting information, people, sys-

tems, and devices” [Micd].

Figure 6.16: Technological Fundament of the B-KIDE Tool: The .NET Frame-

work [Mica]

The .NET Framework is based on a platform independent fundament, a so-

called Common-Language-Runtime (CLR) that is designed to compile .NET-code

just-in-time for targeted platform environments (operating systems). In addition

to that, the .NET Framework provides a Common-Language-Specification (CLS)

that allows for integrating existing, or developing new programming languages on

top of the .NET Framework by implementing appropriate compilers6. Thereby,

programming concepts such as object inheritance or invocation are available

across .NET-based programming languages (providing the concept of “cross-

language interoperability”). To make such sophisticated functionality available,

the .NET framework uses a so-called Intermediate Language (IL) that acts as an

intermediary between .NET-based programming languages (implementing the

CLS) and the CLR. A common base class library together with common services

(such as ADO.NET for data manipulation) and concepts (such as windows

forms) build a comprehensive infrastructure for the development of software

applications. Because of the sophisticated requirements concerning the B-KIDE

6In order to achieve that, accordance with the CLS is necessary


Tool’s main user interface, the B-KIDE Tool was implemented with VB.NET,

which provides powerful access to .NET’s concept of windows forms.

Figure 6.17: Architectural Sketch of the B-KIDE Tool

Figure 6.17 depicts the B-KIDE Tool’s main application architecture in an il-

lustrative way. The main B-KIDE Tool user interface provides knowledge analysts

with access to interview data across a series of user sessions (interviews). With

.NET’s serialization service System.Runtime.Serialization.Formatters.Binary,

data objects are persisted throughout these sessions in a binary data reposi-

tory. Analysis reports, generated by the B-KIDE Tool, utilize the Scalable Vector

Graphics (SVG) [Gro03] standard developed by the W3C. This standard itself

is based on XML [BPSM+04], a flexible, human- and computer-readable data

format. Therefore, the B-KIDE Tool applies Microsoft’s XML Parser MSXML

4.0 SP2 that supports the generation of XML-based files. Also, the B-KIDE

Tool ensures that the generated XML-based files comply to the SVG standard.

Analysis reports of the B-KIDE Tool are visualized with the help of SVG viewers


(such as HTML browsers that installed Adobe’s SVG Plugin c© [Ado]). Because

these analysis reports are based on XML and the vector-based graphics format

SVG, generated reports can easily be transformed to other formats with technolo-

gies such as XSLT or can be graphically revised with existing graphical software

applications (such as Microsoft Visio c© [Micc]). More details about the B-KIDE

Tool can be found in appendix D.

Chapter 7

Proof of Concept

What counts as its test? - “But is this an adequate test? And, if so, must it not

be recognizable as such in logic?” - As if giving grounds did not come to an end

sometime. But the end is not an ungrounded presupposition: it is an

ungrounded way of acting.


7.1 Introduction

This chapter provides proof that the B-KIDE Framework significantly contributes

to the main challenges addressed by this PhD work. For this purpose, the concept

of case and pilot studies1 was employed to assess the ability of the B-KIDE

Framework to achieve reasonable results within complex, real-world scenarios.

The selection of appropriate studies was driven by the ambition to apply the

B-KIDE Framework in the most heterogeneous environment available in order

to determine the supported degree of generality. Therefore, three studies were

conducted with companies from software, automotive and consulting industry

to demonstrate that the B-KIDE Framework is capable of achieving its design

objective, which is to:

Introduce a framework and an according tool that allows for the de-

velopment of business process-supportive, technological knowledge in-

frastructures for knowledge intensive organizations [page 26].

1also see section B for further details on the selected research approach

117

CHAPTER 7. PROOF OF CONCEPT 118

Case Study 1 Pilot Study 1 Pilot Study 2

Project

Context

Software indus-

try, ISO9001:2000

certified

Automotive indus-

try, formally defined

business processes

Consulting indus-

try, weakly designed

business processes

Project

Goals

Knowledge portal

design

EDM system im-

provement

Intranet improve-

ment

Hypothesis

tested

B-KIDE Framework B-KIDE Framework and B-KIDE Tool

Framework

Applica-

tion

Design Evaluation Design

Project

Results

Design of four

knowledge portals

EDM system

improvement poten-

tials

Design of a KI to

support the acquisi-

tion process

Study

Style

Explorative Justificative Justificative

Primary

Actor

The author A 3rd person A 3rd person

Evaluation

concern-

ing

PhD objectives

Table 7.1: Overview of Conducted Studies

Table 7.1 gives an overview of the main contents of the conducted studies. In

the following sections, three case/pilot studies applying the B-KIDE Framework

from a heterogeneous range of industrial backgrounds are introduced. First and

foremost, the context in which the studies were conducted is described per case.

The goals as well as the specific approaches are explained in order to further

enhance understanding about the main activities executed. Also, the execution

of each step of the B-KIDE Framework is briefly introduced. Subsequently,

the core results of the studies are illustrated to give an idea, how the outputs

of these undertakings were utilized by the industrial study partners to develop

their knowledge infrastructures. Finally, in section 7.6, the accomplishments of

the B-KIDE Framework in the light of the three conducted studies are discussed.


The arrangement of the studies in this chapter indicates the timely sequence of

realization.

7.2 Case Study 1: Software Industry

7.2.1 Context

Case study 1 was performed in cooperation with a software developing company

A with about 200 employees. The case study itself took place in the R&D division

of the company, which is certified according to the process-oriented ISO9001:2000

standard and consists of about 80 employees. About 30 business processes are

modeled to describe the core work of this division and are managed and con-

tinuously improved by a dedicated quality management team. Employees are

integrated well in ongoing, organizational process development efforts. They

therefore share an excellent, common understanding about the core, value gener-

ating activities of their organization and follow the collectively defined processes

tightly. Concerning technological equipment, the company has a technological

KM system with typical KM functionality (as introduced in chapter 1) at its

disposal.

7.2.2 Pursued Goals

In this case study, company A aimed to design and implement a knowledge in-

frastructure, based on technological knowledge portals, for five of its most critical

organizational roles. These knowledge portals were supposed to 1) provide the

targeted roles with information relevant for their respective business processes

and 2) be interlinked with each other, to effectively route information from/to

related knowledge workers. A more implicitly pursued goal was to further define,

refine and establish communication channels for information exchange between

knowledge workers in their respective business processes. Since this implicit goal

evokes not only technological measures, suggestions concerning organizational

improvements (such as business process modifications) were appreciated by com-

pany A as well, but not a strict requirement for this case study.


7.2.3 Approach Taken

In this case study, the principle approach of the B-KIDE Framework was utilized

to address the case study goals. In detail, B-KIDE’s Modeling Technique (as

depicted in figure 7.1) and B-KIDE’s Modeling Structure as well as the B-KIDE

Method were applied2.

Application of the B-KIDE Modeling Technique

Figure 7.1: The Modeling Procedure Applied in Case Study 1

Scope Definition: During the B-KIDE Modeling Technique activity “Scope

Definition”, the investigation area in the target organization was delimited. The

five organizational roles to be supported were defined to consist of: VPE (Vice

President Engineering), CRD (Coordinator), TL (Team Leader), PM (Project

Manager) and MD (Module Developers). For each role, at least two interviewees

were assigned (with the exception of the VPE, see table 7.2). A total of seven

interviewees (some of them bearing more than one role) were interviewed. All

business processes, in which the selected roles were involved, were determined to

be the basis for process-oriented interviews.

Pre-Modeling: Three dimensions of the B-KIDE reference models were

pre-modeled in order to prepare for the interviews. The Business Process

Reference Model was pre-modeled based on an existing Business Process

Landscape as well as the Organizational Roles Reference Model based on an

existing organigram of company A. Pre-modeling of these models was performed

by the knowledge analyst based on provided documentation (the ISO 9001:2000

quality management manual). Also, an initial Knowledge Domain Reference

2At the time of conducting this case study, the B-KIDE Tool was not yet available andtherefore, the modeling and analysis activities were performed semi-automatically by utilizingMicrosoft’s standard software Excel c©.


Role Interviewee

VPE A

CRD A, B

TL C, D

PM D, E

MD F, G

Table 7.2: Scope Definition and Interview Planning in Case Study 1

Model was developed based on the company’s “Vision and Strategy” document.

This reference model was set up by the knowledge analyst and discussed and

further refined with company A’s top management as well as with employees

during the object system modeling activity.

Object System Modeling: Object system modeling took place via seven,

process-oriented interviews with knowledge workers A-G. Each interview took

place in a separate, quite room preventing distractions and disturbances and

lasted around two hours. During the interviews, interviewees had sketches of

all relevant business processes at their disposal. The knowledge analyst had all

pre-modeled reference models available. During the interviews, the knowledge

analyst used the Microsoft Excel c© template depicted in figure E.1 on page

181 to structure gathered interview data. The questions illustrated in this

figure are based on request/respond patterns of concrete, past executions of

business processes. At the end of the interviews, no validation of interview

data took place since the gathered interview data was not available in a format

that was easy to relate to interview data previously gathered in other interviews3.

Model System Refinement: After conducting the interviews, the knowl-

edge analyst refined the interview excel sheets with information he could not

document during interview time because of time restrictions. Based on these

excel sheets, the Knowledge Process Landscape (containing more than 40 knowl-

edge processes) depicted in appendix E in figure E.2 on page 182 was manually

created in accordance with the B-KIDE Modeling Structure by the knowledge

3This fact, among others, raised the need for developing the B-KIDE Tool.


analyst.

Application of the B-KIDE Method

Figure 7.2: The Design Method Applied in Case Study 1

The B-KIDE Method (consisting of the design process depicted in figure

7.2 and the KI template architecture) was applied during this case study in

order to design knowledge portals that support company A’s employees in their

respective business processes.

Knowledge Process Definition: In this first design activity, the created

Knowledge Process Landscape was filtered according to the related organiza-

tional roles. For each role, a set of relevant knowledge processes that need to be

supported by the anticipated knowledge portals was defined. Table 7.3 gives an

overview of agreed upon and selected knowledge processes that were determined

to be supported by the anticipated, technological knowledge infrastructure.

VPE CRD TL PM MD

KP Selected for Support [#] 16 9 15 10 0

Percentage [%] 59 50 68 53 0

KP not Selected for Support [#] 11 9 7 9 32

Percentage [%] 41 50 32 47 100

Involved in KPs - Total [#] 27 18 22 19 32

Percentage Total [%] 100 100 100 100 100

Table 7.3: KI Focus: Definition of Knowledge Processes to be Supported

At this point, technological support for one organizational role (MD) was

discarded since this role had highly role-independent, task and project-specific


knowledge needs that could not be covered to the necessary extent with the

available infrastructure4.

Figure 7.3: A High Level Conceptualization of the Anticipated Support for

Knowledge Flows in Case Study 1

Figure 7.3 illustrates the design scope of the anticipated knowledge infras-

tructure. Four organizational roles are supported in their respective knowledge

processes while support for one role (MD) was discarded. The scope demarca-

tion represents the fundament for defining future knowledge processes since it

determines the primary actors in the anticipated knowledge infrastructure.

In figure 7.4, the in- and output of the process of defining a specific knowledge

process to be supported in the anticipated knowledge infrastructure is depicted.

While in the identified knowledge process A, the project manager transfers

knowledge about the project progress through private e-mails to other employees

(where each of them archives them separately), the defined knowledge process B

demands a new Storage Object 1.3 (an e-mail archive accessible for all concerned

roles) that centrally stores and archives e-mails. The storage process itself is

in the responsibility of the knowledge infrastructure. This reduces the burden

of organizing knowledge for each organizational role involved. In addition to

that, knowledge process B demands that the transfer of these e-mails needs to

be integrated in the respective business processes in the future (Transfer Object

4especially the lack of available metadata assigned to documents, necessary for enhancedpersonalization features, led to this decision


1.4 e-mail alias).

Figure 7.4: An Example of Knowledge Process Definition in Case Study 1

Preliminary KI Design: The knowledge infrastructure template architec-

ture (section 5.9) provided guidance concerning the main design results of this

activity. Based on the set of related knowledge processes per organizational role,

UI mockups of supportive knowledge portals were developed. This was achieved

by analyzing and investigating the related knowledge processes and by designing

support for them within the anticipated knowledge portals. Thereby, the

application of the B-KIDE Framework led to a design of knowledge portals that

supports knowledge processes across a set of organizational roles and business

processes. Together with corresponding organizational roles, the UI mockups

were subsequently discussed and further refined pursuing a participatory design

approach. Figure E.3 on page 184 depicts such a UI mockup that represents

a fragment of the design of the anticipated solution on the access layer of the

KI template architecture. Based on the design of this layer, the corresponding

underlying KI template architecture layers were designed.

KI Design Evaluation: In this activity, the preliminary KI design was under

evaluation concerning its respective knowledge processes and certain fit criteria


(also see figure E.3 on page 184). With respect to the goals of this case study,

the selected fit criteria were determined to be:

• All defined storage objects (SO) shall appropriately be supported and in-

cluded in the anticipated knowledge infrastructure.

• All defined roles shall be able to provide knowledge they generate within the

defined knowledge processes to the anticipated knowledge infrastructure in

a fast and easily comprehensible way.

• The transfer of knowledge shall be supported by the anticipated knowl-

edge infrastructure to the extent described within the defined knowledge

processes.

• All defined knowledge activities shall be integrated into the organization’s

business processes.

In cases of lacking appropriate support, the design was revised by the KI

designer, who thereby looped through the preceding activity. After checking each

fit criterion for inclusion in the KI design, the preliminary design was approved

and handed over to a team of implementers.

7.2.4 Achieved Results

Figure 7.5 illustratively depicts the main results of case study 1. For each identi-

fied organizational role, a supportive knowledge portal was developed. The knowl-

edge portals represent role specific perspectives on the organization’s knowledge

infrastructure. The portals are interconnected to each other through the knowl-

edge infrastructure. Beneath that, they are connected to other (legacy) systems

and applications that play important roles in the targeted business processes.

Beneath the (visible) results of figure 7.5, a set of concepts (including an access-,

structure- and content concept) derived from the KI template architecture was

developed. The application of the B-KIDE Design Process together with the B-

KIDE KI Template Architecture and the developed concepts assured support for

knowledge processes within the final design of the solution.


Figure 7.5: Case Study 1 Results: Four Role Oriented Knowledge Portals

7.3 Pilot Study 1: Automotive Industry

7.3.1 Context

Pilot study 1 was conducted in cooperation with a car-manufacturing company

B with about 10.000 employees. The pilot study was conducted with a specific

group of the engineering department comprising 150 employees. Before this pilot

study took place, the department’s core business process product development

and its six main sub-processes were modeled in detail in cooperation with related

engineers using the available modeling technique and tool ARIS [Sch00]. Because

of the tight cooperation during modeling, engineers share a broad common un-

derstanding about the department’s main processes and activities. Concerning

technological equipment, engineers in their respective business processes are sup-

ported through a variety of technological, custom-tailored systems. Among them,

the employed engineering data management (EDM) system is the most important

technological instrument in this area (as perceived by pilot study representatives).


7.3.2 Pursued Goals

The role DetK (Detail Constructor) is considered to be the most critical role

by pilot study representatives. His main activities are focused on the business

process product development in company B. With this pilot study, company B

aimed to analyze the role of the EDM system for the organizational role DetK

in its respective business processes and to generate improvement suggestions for

this system from a knowledge perspective. This overall goal included: 1) techno-

logically supporting knowledge interactions between the business process product

development and related business processes by leveraging the existing EDM sys-

tem and 2) improving the EDM system to better suit the knowledge needs of

DetK.


In this pilot study, the principle approach of the B-KIDE Framework was uti-

lized to address the study goals. In detail, B-KIDE’s Modeling Technique (as

depicted in figure 7.6) together with the B-KIDE Tool and the B-KIDE Method

were applied. Instead of designing a new technological infrastructure in this pi-

lot, an existing infrastructure was evaluated and improvement suggestions were

generated.


Figure 7.6: The Modeling Procedure Applied in Pilot Study 1

Scope Definition: In this activity, the scope of investigations was delimited.

During the course of this pilot study, the knowledge analyst together with pilot

study representatives determined two organizational roles for structured inter-

views: DetK and KstrP (Construction Inspector). The reason for that was to


involve the views of the targeted role DetK as well as the views of an external

role (KstrP) who was considered to be important. As depicted in table 7.4, three

DetK were available for interviews, while one person was interviewed as a KstrP,

summing up to a total of four interviews. All interviews were based on the in-

terviewees’ involvement in the engineering’s department main business process

product development.

Role Interviewee

DetK A, B, C

KstrP D

Table 7.4: Scope Definition and Interview Planning in Pilot Study 1

Pre-Modeling: In this pilot, pre-modeling of five dimensions of the

B-KIDE reference models took place. While the Business Process Reference

Model was created based on the developed ARIS business process models, the

Organizational Roles Model was created based on an available organigram. The

Knowledge Domain-, Storage Object-, and Transfer Object Reference Models

together were pre-modeled by interviewing a domain expert in the field of

engineering who is working in the engineering department.

Object System Modeling: Object system modeling took place via four

process-oriented and tool-supported interviews with knowledge workers A-D.

All of the interviews were conducted in large office spaces with multiple other

employees present and working. Each interview lasted between 45 and 80

minutes. No business process diagrams were available during interviews since all

interviewees participated in the business process modeling effort that preceded

this pilot. The analyst applied the B-KIDE Tool to raise the necessary interview

questions and to document/structure corresponding answers. Validation of

interview data took place by confronting the interviewees with their answers

given at the end of the interviews.

Model System Refinement: The knowledge analyst refined the gathered

interview data after each interview as well as after all interviews took place with

information he did not document during interview time because of a) time restric-

tions or b) misunderstandings with interviewees. Figure E.4 on page 185 depicts


the resulting Knowledge Process Landscape containing 25 identified knowledge

processes. This landscape was auto-generated by the B-KIDE Tool after all in-

terviews were completed and laid a sound fundament for the evaluation of the

targeted knowledge infrastructure.


Figure 7.7: The Evaluation Method Applied in Pilot Study 1

The B-KIDE Method (consisting of the design process and the KI template

architecture) was applied during this case study in order to generate improve-

ment suggestions for a knowledge infrastructure that better supports company

B’s organizational role DetK in its respective knowledge intensive (sub) business

processes. The dotted lines in figure 7.7 represent activities that were not carried

out during this pilot.

Knowledge Process Definition: In this activity, ideal knowledge processes

were defined. By defining ideal knowledge processes, the existing knowledge in-

frastructure could be evaluated concerning the generation of improvement po-

tentials. Improvement potentials here were considered to be the delta between

existing support for identified and possible support for ideal knowledge processes

in a knowledge infrastructure. Based on a subjective assessment of represen-

tatives of the pilot company B, 12 knowledge processes were determined to be

revised and to be supported by an improved knowledge infrastructure. Table 7.5

depicts knowledge processes per role that were selected for support.

Figure 7.8 illustrates the target roles and interactions of this pilot study ef-

forts. While the main actor supported is DetK, the role KstrP and a number of

other relevant roles are also within the focus of the improvement efforts.


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



Knowledge Flows in Pilot Study 1

In figure 7.9, the in- and outputs of an exemplary knowledge process definition

are depicted. Knowledge process A, which was identified through the performed

B-KIDE analysis, describes how knowledge about change requests concerning

construction drawings was handled in company B. While the KstrP generated

this knowledge in the respective construction drawing sub process, he transferred

it to the DetK through informal, bilateral meetings and documented it via per-

sonal notes. The knowledge then was applied in the business process 3D-Modeling

by the DetK and in two further business processes by the KstrP. The supposed,

idealized knowledge process B now introduces a new Storage Object 1.2 (a meet-

ing minutes document) as well as a new Transfer Object 1.4 (a document folder)

that 1) provides a dedicated container for this knowledge domain and 2) ensures

the transfer of this knowledge domain to the corresponding knowledge application

roles. A knowledge infrastructure that implements the two newly introduced ob-


jects would represent an improved knowledge infrastructure because it supports

the execution of the idealized, defined knowledge process B.

Figure 7.9: An Example of Knowledge Process Definition in Pilot Study 1

KI Design Evaluation: The existing knowledge infrastructure design was

evaluated with respect to 1) the defined, idealized knowledge processes and 2)

the developed fit criteria of this pilot study. With respect to the goals of this

pilot study, the fit criteria employed were the following:

• All defined storage objects shall be supported within the anticipated knowl-

edge infrastructure.

• The transfer of knowledge shall be supported to the extent described within

the defined knowledge processes by the anticipated knowledge infrastruc-

ture.

• All selected roles shall have access to the knowledge they need to apply

within the defined knowledge processes.

A lack of support for one of the defined, idealized knowledge processes and

corresponding fit criteria in the existing knowledge infrastructure led to the

generation of improvement potentials for the improved knowledge infrastructure.

Preliminary KI Design: When applying the B-KIDE Method in an evalua-

tion mode, the improvement potentials identified in the previous activity now can

be translated to an improved knowledge infrastructure design. During this pilot


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.


The application of the B-KIDE Framework together with the B-KIDE Tool al-

lowed for detailed investigations of the existing knowledge infrastructure (the

EDM system) of company B. Not only could the role of company B’s EDM sys-

tem within the product development business process be assessed - by defining

ideal knowledge processes, substantial improvement potentials for the existing

knowledge infrastructure could be generated. By addressing the identified im-

provement potentials, company B is able to employ “Arrow 3” KM functionality

to better support their knowledge-intensive business processes and knowledge

workers. In doing that, a clear (knowledge) vision of how the existing EDM

system should evolve in the future was developed.

7.4 Pilot Study 2: Consulting Industry

7.4.1 Context

Pilot study 2 was performed in cooperation with a consulting company C, provid-

ing consulting services in the domains of organizational development, information

technology and engineering, with about 30 employees. Company C has a con-

ceptualization of its main business processes available (in the sense of a Business

Process Landscape). However, these business processes are not documented or

modeled in an extensive, detailed way. The Business Process Landscape con-

sists of six main business processes that depict the most critical processes of

company C. Employees share a moderate common understanding about the ex-

ecution of these processes. Concerning technological equipment, company C has

a well structured intranet with functionalities such as document management or

HTML provision available.


7.4.2 Pursued Goals

This pilot study aimed to lay out the design of a knowledge infrastructure that

supports the organizational role business manager (BM) in executing its corre-

sponding acquisition business process including e.g. support for the creation of

project proposals and/or promotions. In detail, the knowledge infrastructure was

supposed to: 1) collect the necessary information from project staff (MA), project

managers (PL), project office (PO) and the business manager himself and 2) pro-

vide this kind of information to the business manager in an appropriate way.

Since the current situation involves an organizational role performing the kind

of work that the anticipated knowledge infrastructure aims to implement, appro-

priate business process modifications were necessary and among the goals of this

pilot study as well.


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.


Figure 7.10: The Modeling Procedure Applied in Pilot Study 2

Scope Definition: The scope of investigations was delimited in this activity.

The project team agreed upon interviewing the four organizational roles BM, PL,

MA and PO in order to gain a comprehensive overview of interactions between

the BM and supporting roles. Because of resource restrictions, only one employee

per role was interviewed. In total, four interviews were performed. The business

processes, in which the selected roles were involved, acted as a basis for tool-

supported, process-oriented interviews.


Role Interviewee

BM A

PL B

MA C

PO D

Table 7.6: Scope Definition and Interview Planning in Pilot Study 2

Pre-Modeling: Five dimensions of the B-KIDE reference models were

pre-modeled in order to prepare the execution of interviews. The Business

Process Reference Model was pre-modeled based on the conceptualization of

company C’s main business processes. The Organizational Roles Reference

Model was modeled based on the existing organigram which was documented

in company C’s organizational guidelines. A Storage Object Reference Model

was prepared based on investigations performed on the company’s intranet.

A preliminary Transfer Object Reference Model was developed based on

discussions with employees of the organization. An initial Knowledge Domain

Reference Model was established considering the most important knowledge

domains that were addressed from management during preparatory meet-

ings. All of these preliminary reference models were modeled by applying the

B-KIDE Tool reference modeling features (as depicted in figure 6.10 on page 108).

Object System Modeling: Object system modeling took place via

four process-oriented and tool-supported interviews with knowledge workers

A-D. All of the interviews were conducted in a separate, quite room lasting

between one and two hours5. During the interviews, interviewees had the main

conceptualization of company C’s business processes at their disposal. All

pre-modeled reference models were available in the B-KIDE Tool. The analyst

applied the B-KIDE Tool to raise necessary questions and document/structure

corresponding answers. Validation of interview data took place by the knowledge

analyst right during interview time (double checking answers given and checking

them with interview data already available from other interviews).

5with the exception of one interview only lasting 30 minutes because of time restrictionsimposed by the interviewee


Model System Refinement: The knowledge analyst refined gathered in-

terview data after each interview mainly by enriching existing reference elements

with metadata. This information was provided during the interviews, but could

not be modeled at this time because of time restrictions. Figure E.6 on page

187 depicts the resulting Knowledge Process Landscape containing 28 identified

knowledge processes. This landscape was auto-generated by the B-KIDE Tool

after all interviews were completed and laid a sound fundament for the design of

the anticipated knowledge infrastructure.


Figure 7.11: The Design Method Applied in Pilot Study 2

The B-KIDE Method (as depicted in figure 7.11) was applied in this pilot

study to lay out the design of a knowledge infrastructure that supports the

company’s business managers in their corresponding acquisition process.

Knowledge Process Definition: In this activity, from the 28 identified

knowledge processes, eight were selected for support in the anticipated techno-

logical knowledge infrastructure. Thereby, 20 knowledge processes could not be

supported with a technological approach because of various reasons including

the nature of knowledge investigated (tacit knowledge), a lack of available tech-

nological features, a limited willingness and/or ability to document necessary

knowledge and other factors. The 8 selected knowledge processes were defined

based on the elicited knowledge processes and on how they should be executed

in the future with a supportive knowledge infrastructure. During definition, two

new knowledge processes emerged and were included in the final knowledge pro-

cess definition totaling 10 defined knowledge processes. In parallel, a preliminary

KI design (based on the B-KIDE KI Template Architecture) was created that


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


Figure 7.12 depicts the scope of the anticipated knowledge infrastructure de-

sign in an illustrative way. The main actor supported is the organizational role

BM in its corresponding acquisition business process. Beneath that, support for

the role PL is considered as well.


Knowledge Flows in Pilot Study 2

Figure 7.13 exemplarily depicts the in- and outputs of the process of defin-

ing knowledge processes that are to be supported by the anticipated knowledge

infrastructure. Based on identified knowledge processes, and taking the focus of

the anticipated knowledge infrastructure into account (as defined in figure 7.12),

to-be knowledge processes were defined. While the identified knowledge process

A in figure 7.13 depicts that two organizational roles are concerned with the gen-

eration of the knowledge at hand, the defined knowledge process B only considers

one of them for support due to a limited KI project focus imposed by the pilot

company. Information previously stored in a so-called project index in the future


is stored within the anticipated knowledge infrastructure that needs to imple-

ment a Storage Object 2.4 (e.g. a set of data forms or documents) capturing

this knowledge. The software documentation (illustrated in knowledge process

A) remains with the respective tool currently employed by the pilot company. In

the case of knowledge process B, the technological knowledge infrastructure itself

does not support the transfer of this knowledge (also see the definition of transfer

on page 82) - this was an issue with all defined knowledge processes of this pilot

study and was due to a low prioritization of this problem by pilot company C.

However, the knowledge process definitions together with the defined fit criteria

highlighted the lack of support for the in-time transfer of knowledge and thus

raised the need for addressing this problem on an organizational level.

Finally, knowledge process B demands that the anticipated knowledge infrastruc-

ture needs to provide appropriate access to this knowledge domain for business

managers in their corresponding acquisition process. The organizational roles

PL and MA (identified in knowledge process A) again do not receive support in

applying this knowledge domain by the knowledge infrastructure due to imposed

focus limitations.

Figure 7.13: An Example of Knowledge Process Definition in Pilot Study 2

Preliminary KI Design: Based on the defined knowledge processes and

an instantiation of the B-KIDE KI Template Architecture, the KI designer

laid out the design of a business process-supportive knowledge infrastructure

with the requirements of the defined knowledge processes in mind. An access,

structure and content concept were developed for an anticipated software

tool that captures, stores and provides relevant knowledge. While the access


concept provides concrete ideas about how the related roles access knowledge,

the structure and content concept focused on the internal representation of

knowledge within the anticipated knowledge infrastructure.

KI Design Evaluation: The developed KI design was evaluated according

to the defined knowledge processes and corresponding fit criteria. With respect to

the goals of this pilot study, the agreed upon fit criteria comprised the following

checks:

• All defined storage objects shall be supported within the anticipated knowl-

edge infrastructure.

• All defined roles shall be able to provide knowledge they generate within the

defined knowledge processes to the anticipated knowledge infrastructure.

• All defined roles shall have access to the knowledge they need to apply

within the defined knowledge processes.

• All defined knowledge activities shall be integrated into the organization’s

business processes.

A lack of support for one of the knowledge processes and corresponding fit

criteria caused an iteration through the preliminary KI design activity.


The application of the B-KIDE Framework together with the B-KIDE Tool led

to a knowledge infrastructure design that supports business managers in their

corresponding acquisition business process and at the same time supports knowl-

edge interactions between the acquisition business process and related business

processes. Also, the defined knowledge processes illustratively reveal that us-

age of the anticipated knowledge infrastructure mainly benefits the targeted role

business manager. Other integrated roles mainly fulfill the role of knowledge

providers (as depicted in figure 7.12). While this might pose no problem for the

design and implementation of a technological knowledge infrastructure, it might

invoke acceptance problems among participants. Since extending the scope of the

anticipated knowledge infrastructure (for e.g. supporting multiple organizational


roles) represented no option for company C during the course of this pilot study,

the issue was bypassed and addressed on an organizational level by modifying

the respective business processes with additional tasks for project managers.

7.5 Lessons Learned

7.5.1 B-KIDE Framework

The application of the B-KIDE Framework in the three conducted studies gen-

erated valuable feedback for framework improvements. One issue that emerged

from applying the B-KIDE Framework to real-world scenarios was the introduc-

tion and labelling of knowledge domains during modeling. Knowledge analysts

struggled with heterogeneous vocabulary and term boundaries in organizations.

To overcome this issue, two major measures were taken: 1) the element knowledge

domain was extended with the attribute buzzwords to allow for the assignment

of multiple labels to a single knowledge domain. 2) Pre-modeling of knowledge

domains was introduced to the pre-modeling activity of the B-KIDE Modeling

Technique. In this activity, domain experts are interviewed for the development

of an initial prototype of a Knowledge Domain Reference Model in order to ease

the process of interviewing. Experiences made in one pilot study indicate that

with such a procedure, approximately 50% of all identified knowledge domains

can be pre-modeled. Another issue that emerged in one pilot study was the

definition of fit criteria during B-KIDE Method application. In this case, the

pilot study partner company struggled to define fit criteria on an operative level.

This issue was addressed by providing exemplary fit criteria that aid the fit cri-

teria definition process. Also, the development of so-called knowledge problem

patterns may aid identifying weak spots of existing knowledge processes. Such

weak spots could generate valuable knowledge about necessary knowledge infras-

tructure development directions and corresponding fit criteria. Beneath that,

the availability of quality business process models at the beginning of knowledge

infrastructure development projects appeared to positively influence the quality

of the resulting knowledge processes. Those studies, where quality business pro-

cess models were available seemed to generate “fitter” knowledge process models.

Also, the involvement of the interviewed persons in knowledge process analy-


sis activities had positive affects on the final knowledge infrastructure designs

too. Lastly, B-KIDE modeling of knowledge work based on business processes

that were tightly aligned to an application domain6 seemed to generate the most

valuable knowledge process model perspectives for the development of effective

knowledge infrastructures. It can be hypothesized that business process models

that are tightly aligned to an application domain describe the work of inter-

viewed knowledge workers more accurately and therefore lead to more concrete

and relevant knowledge process models.

7.5.2 B-KIDE Tool

The utilization of the B-KIDE Tool in knowledge infrastructure development

projects allowed knowledge analysts who were mainly unfamiliar with the B-

KIDE Framework to easily conduct process-oriented interviews that conform to

the B-KIDE Modeling Structure. Experiences in two studies showed that the

application of the B-KIDE Tool significantly lowered the work burden for knowl-

edge analysts. However, users needed some amount of training to be able to

appropriately apply the B-KIDE Tool. Therefore, interview guidelines for knowl-

edge analysts were provided (see chapter C) and with each knowledge analyst,

a set of supervised test interviews (two to three) was conducted in order to en-

hance the performance of subsequent interviews. In addition, knowledge analysts

agreed that comprehensive pre-modeling eases the actual process of interviewing.

Also, in all studies knowledge analysts considered it helpful to be able to refine

the gathered interview data right after interview situations. By considering the

aforementioned aspects, the B-KIDE Tool was capable to be applied in real-time

by knowledge analysts in the conducted study interviews. New tool functional-

ity that was suggested by knowledge analysts includes a software feature that

dynamically fades in the current status of knowledge processes. Another im-

provement suggestion concerned dynamic checks for already existing buzzwords

to synchronize the meaning of these terms. The underlying hypothesis of both

feature suggestions is that an implementation would support the challenging task

of matching knowledge domains.

6such as software development business processes vs. e.g. generic project managementprocesses


7.6 Assessment

In this section, the B-KIDE Framework is assessed in the light of the three con-

ducted studies. In order to do so, the degree of achieving the defined objectives

of this PhD work is presented and critically discussed. The following goals were

defined to be the goals of the B-KIDE Framework (also see page 27):

1. The concept leads to knowledge infrastructure designs that im-

prove environments of knowledge workers for their respective

knowledge intensive business processes

All conducted studies led to designs of knowledge infrastructures that

were oriented towards improving technological environments for knowledge

workers in their knowledge intensive business processes. This was mainly

achieved by the Framework’s capability to 1) identify existing and 2) define

improved knowledge processes based on knowledge workers’ business pro-

cesses and 3) ensure support for knowledge processes in improved knowledge

infrastructures through the concept of fit criteria. Pilot study 1 (EDM sys-

tem improvement) effectively demonstrated how improvement potentials for

knowledge infrastructures can be identified based on applying the B-KIDE

Framework.

2. The concept leads to knowledge infrastructure designs that en-

able role oriented access to knowledge for knowledge workers in

organizations

The B-KIDE model architecture allows for performing role-oriented anal-

yses (see e.g. table E.1 on page 183) on top of the identified knowledge

processes. Thereby, and by applying the normative B-KIDE Method, role-

oriented access to knowledge can be designed. Especially the empirical

results of case study 1 (knowledge portals) and pilot study 2 (a knowledge

infrastructure supporting the acquisition process) provided proof that role

oriented access can well be achieved in knowledge infrastructure develop-

ment projects by applying the B-KIDE Framework.

3. The concept leads to knowledge infrastructure designs that enable

autonomous routing of knowledge from/to corresponding knowl-

edge workers in their business processes


Among the main characteristics of knowledge processes is the capability to

comprise descriptions of knowledge flows (see page 70). By defining fit cri-

teria that focus on the implementation of support for knowledge flows and

-transfer in technological knowledge infrastructures, the aspect of routing

knowledge is addressed. Thereby, not only knowledge interactions within

and across business processes are supported, but also concrete instructions

on how to apply “Arrow 3” KM functionality in business contexts are pro-

vided. Convincing empirical evidence for these statements can be found in

e.g. case study 1, where knowledge is autonomously routed between a set

of knowledge workers by means of networked knowledge portals.

4. The concept leads to knowledge infrastructure designs that en-

force a more standardized way of executing knowledge work in

organizations

The B-KIDE Framework applied in the conducted studies was useful to

contribute to increased standardization of knowledge work in areas selected

by the industrial study partners. By defining future organizational knowl-

edge processes, and designing support for them in technological knowledge

infrastructures, a more standardized way of executing knowledge work was

enforced. Pilot study 2 (supporting an acquisition process) illustrates such

an effort in an excellent way. Here, knowledge flows between the BM and the

PM were defined and integrated in the design of the anticipated knowledge

infrastructure, leading to defined communication channels between these

two roles. However, other issues such as user acceptance, implementation

quality or usability aspects of technological knowledge infrastructures also

play a vital role in efforts aiming to standardize knowledge work. There-

fore, these aspects need to be considered to a reasonable extent in projects

that pursue such goals.

5. The concept leads to increased transparency of knowledge work

in organizations and its implications for technological knowledge

infrastructures

In all studies conducted, knowledge processes represented the major impera-

tive for designing technological support. Knowledge processes illustratively


visualized knowledge work7 in the three study organizations in great detail

and, in combination with existing concepts such as [Rol03], laid the basis

for informed decisions concerning the design of knowledge infrastructures.

In addition to these accomplishments, a set of further challenges could be

addressed to some extent:

• The concept can be reasonably applied in real-world knowledge

infrastructure development projects

While the developed B-KIDE Framework alone is not applicable in a rea-

sonable amount of time, the complementary B-KIDE Tool allows for the

effective application of the B-KIDE Framework as demonstrated in two in-

dustrial pilot studies. The B-KIDE Tool achieves that by implementing

the B-KIDE Modeling Structure. Thereby, it eases the application and re-

duces complexity of the B-KIDE Framework for knowledge analysts and

knowledge infrastructure designers.

• The concept can be applied to organizations across industries

The selection of case and pilot studies was made with this goal in mind. The

B-KIDE Framework was applied in three studies that spanned software-,

automotive- and consulting industry. During study execution, no indica-

tors where found that would point to a limited applicability of the B-KIDE

Framework to certain organizations or industries. However, future research

might focus on testing the B-KIDE Framework in other application do-

mains.

• The concept can be applied at various abstraction levels of

knowledge

Although the accomplishment of this statement strongly depends on the

definition and demarcation of the term abstraction levels chosen, the B-

KIDE Framework supports the development of reference models (such as

the Knowledge Domain-, Business Process- or Transfer Object Reference

Model) on arbitrary detail levels through hierarchical concepts. However,

7The descriptive power of knowledge processes was introduced in detail in section 4.3.3 onpage 70


all three studies focused on areas where the knowledge domains investi-

gated where considered to be on a very concrete level, within clearly de-

fined system boundaries. The application of the B-KIDE Framework on

higher abstraction levels such as in intra-organizational settings is among

the aspects that need to be elaborated on in future research efforts (also

see section 9.5).

Chapter 8

Future Work

Es verdient festgehalten zu werden, daß man bezweifeln kann, ohne zu

kritisieren, und kritisieren, ohne zu bezweifeln.


The introduced B-KIDE Framework comprises a set of powerful concepts

that successfully addresses the objectives of this PhD thesis. Beneath that, some

new and challenging questions emerged from the introduced concepts that might

stimulate further research. Therefore, this chapter aims to present issues that

need to be resolved in future research efforts:

8.1 On System Design and Implementation

The B-KIDE Framework successfully aids in prescribing what needs to be part

of knowledge infrastructure designs, but not how these requirements are pro-

vided (section 5.4.1). Often, organizational knowledge infrastructures are based

on available software (so-called COTS products) such as [Hyp, Liv, Lot]. There-

fore, in order to be implementable, the developed, vendor-independent knowledge

infrastructure designs need to be mapped on concrete, vendor-specific system de-

signs. Although existing concepts (as exemplarily introduced in section 5.4.2)

can aid this process, a formal methodology for mapping knowledge infrastructure

designs on concrete system designs is supposed to bear the potential of signifi-

cantly increasing accuracy of the developed knowledge infrastructure designs and

reducing work burden for system designers.

145

CHAPTER 8. FUTURE WORK 146

8.2 On Knowledge Process Optimization

The current version of the B-KIDE Framework successfully addresses the initial,

static identification of knowledge processes and the development of supportive

technological knowledge infrastructures. The B-KIDE Framework achieves that

through focused, temporally-restricted interventions in organizations. Thereby,

continuous improvement and self-optimization1 of knowledge processes are not

covered by the introduced concepts. Therefore, future extensions to the B-KIDE

Framework are necessary in order to deal with changing environments such as

1) the introduction of new organizational roles or 2) the modification of existing

business processes. In such situations, the current version of the B-KIDE Frame-

work continuously needs to be re-applied which may not be practical in real-world

scenarios2 and does not contribute to the requirement of e.g. the KPQM for self-

optimization depicted in table 8.1. The emergence of these issues calls for future

research work in this domain and raises the following questions that need to be

addressed: How can dynamic aspects of business- and knowledge processes be

integrated in the B-KIDE Framework? How can support for knowledge processes

be designed in a sustainable and self-optimizing way? What kinds of knowledge

process performance measures are suitable for evaluation? To what extent can the

KM role knowledge process owner [PP02] contribute to the identified challenges?

8.3 On the Problem of Decoupled Knowledge

Processes

Where knowledge generation, storage, transfer and application is performed by a

set of different individuals, severe problems for organizations may arise: In such

situations, e.g. employees who need to apply knowledge might have no context

knowledge about the required knowledge domain such as by whom and in which

context it was originally generated. This can result in both, either dogmatic

1Attributed to the highest maturity level 5 (Optimizing) of the Knowledge Process QualityModel (KPQM) [PP02, OP03]

2However, the B-KIDE Framework comprehensively aids in anticipating the (knowledge)effects of modifications to a single business process within complex business process networks


Maturity Stage Description

1 - Initial The quality of knowledge processes is not

planned and changes randomly. This state can

be best described as one of chaotic processes.

2 - Aware Awareness for knowledge processes has been

gained. First structures are implemented to en-

sure a higher process quality.

3 - Established This stage focuses on the systematic structure

and definition of knowledge processes. Processes

are tailored to react to special requirements.

4 - Quantitatively

Managed

To enhance the systematic process management,

measures of performance are used to plan and

track processes.

5 - Optimizing The focus of this stage is on establishing struc-

tures for continuous improvement and self-

optimization.

Table 8.1: Maturity Stages of the KPQM [PP02]

belief in or total disbelief of available knowledge. Also, this situation might

lead to knowledge generators (employees) having no vision of what knowledge

appliers (other employees) really require. Here, the generation and application

of knowledge is structurally and cognitively decoupled3. Therefore, the author

suggests introducing the term “Decoupled Knowledge Process” in order to

describe the outlined problem.

Decoupled Knowledge Processes can be tackled on two different levels: Either

1) awareness for knowledge processes can be raised among knowledge knowledge

workers4 or 2) responsible knowledge workers for knowledge generation and ap-

plication can be brought together (not necessarily physically), thereby redesign-

3Reasons for such situations may lie in technological systems that implement and encapsulatethe transfer and routing of knowledge or dedicated organizational roles (such as knowledgebrokers) who explicitly focus on knowledge transfer and thereby potentially decouple knowledgegenerators and appliers.

4through e.g. intelligent process visualizations such as [BM04]


ing and streamlining corresponding knowledge processes. Both measures aim

to close the cognitive gap between knowledge generators and appliers and avoid

the problem of decoupled processes. However, further research work is neces-

sary to gain a deeper understanding about factors promoting the appearance of

decoupled knowledge processes and to develop effective countermeasures. The B-

KIDE Framework provides a sound fundament for future work since it identifies

situations, where the problem of decoupled knowledge processes might occur.

8.4 On Oblivion of Knowledge

Beneath the generation, storage, transfer and application of knowledge, the selec-

tive oblivion respectively deletion of knowledge in organizational memories (on

individual, organizational and/or technological levels) represents a pressing chal-

lenge for organizations [Leh00, page 283]. For example in technological contexts,

the controlled deletion of useless knowledge bears tremendous administration-,

maintenance- and thus, cost-saving potentials for organizations. Therefore, im-

portant decisions concerning the deletion vs. preservation of knowledge artifacts

have to be made. The B-KIDE Framework does not deal with these aspects

because of the chosen focus of this PhD work. However, in the future of an in-

creasingly knowledge-based economy, controlled knowledge oblivion/deletion is

considered to pose an even more severe and complex problem for organizations.

Therefore, the challenge at hand strongly calls for future research work in this

area integrating knowledge oblivion with the concepts of the B-KIDE Framework

answering questions such as: Under which conditions can knowledge artifacts be

deleted? Can the concept of knowledge life cycles contribute to the problem at

hand? How can the risks involved in both knowledge oblivion and preservation

be assessed?

8.5 On Role-Orientation vs. Personalization

Personalization is a concept concerned with the adaption of knowledge infras-

tructures to specific user needs. Current research considers personalization of a

system to be

The adaptation of 1) its system features, 2) the content managed by


the system and 3) its structural components for organizing content

according to the internal model of reality, states and activities system

users have. [Toc02]

This definition powerfully strengthens the role of individual users (vs. or-

ganizational roles) in knowledge infrastructures. In the context of the B-KIDE

Framework, the future need for extending the introduced, role-oriented concepts

towards the consideration of individual persons emerges. Questions concerning

this challenge include: To which degree can role-oriented and person-oriented

approaches be combined?5 How can business process aspects be considered in

current personalization models? Can the B-KIDE Framework also contribute to

the concepts of dynamic personalization [Kan03]?

8.6 On Interactions between Knowledge Infras-

tructures and Business Processes

Not only do business processes pose implications for knowledge infrastructures,

but the design and application of knowledge infrastructures pose implications on

business processes as well. For example, the introduction of a knowledge man-

agement system may cause severe adaptations to an organization’s business pro-

cesses (supposing a “technological imperative” [Leh00, page 48/49]). This issue

may cause conflicts between organizational units and interests such as knowledge

management and process management. Questions that can be raised based on

this observation include: To which degree should knowledge infrastructures influ-

ence business processes and vice versa? How can common quality attributes be

defined for such interweaved environments? What kinds of trade-offs are involved

in business process oriented knowledge infrastructure design decisions?

8.7 B-KIDE Framework Evolution Scenarios

Obviously, the B-KIDE Framework itself can be improved from a knowledge

perspective. By understanding the B-KIDE Framework as a network of

5First work concerning this question already exists [GPSW03]. However, the applicabilityof such concepts, especially in large-scale settings, is an open research challenge.


processes6 and knowledge workers7, the B-KIDE Framework can be applied

to itself. Thereby, knowledge weak spots may be analyzed and a supportive

knowledge infrastructure for knowledge workers may be designed. Although this

undertaking is not within the scope of this PhD thesis, it represents a more than

interesting approach to the further development of the B-KIDE Framework.

Another B-KIDE Framework evolution scenario includes the development of

knowledge problem patterns that indicate problems in organizational knowledge

work based on certain knowledge process configurations. An example for

such a pattern might be a lack of appropriate transfer between knowledge

generators and appliers (illustrated in knowledge process visualizations by a

lack of responsible transfer objects). The existence and development of such

knowledge problem patterns would substantially ease the application of the

B-KIDE Framework and the process of developing business process-supportive

knowledge infrastructures.

A third possible evolution scenario might be the adaption of the B-KIDE Frame-

work to specific industry sectors, providing tailored blue-print reference models

and knowledge infrastructure design solutions that aid the efficient realization

of knowledge infrastructure development projects. Questions concerning such

an approach include: To which degree can reference models be anticipated in

organizations of the same sector? Do the developed knowledge infrastructures

share common characteristics that can be implemented in the future without

performing detailed organization-specific analysis? And if so, can these solutions

be described as patterns (in the sense of [Ale79]) also and be integrated into the

B-KIDE Framework?

8.8 B-KIDE Tool Evolution

The B-KIDE Tool proved itself successful in reducing the burden of collecting

and structuring interview data for knowledge analysts. The developed reports

provided comprehensive support for analyzing the defined model perspectives.

However, the B-KIDE Tool lacks support for the flexible generation of additional

6The B-KIDE Method and the B-KIDE Modeling Technique represent such processes7such as the B-KIDE knowledge analyst or the B-KIDE knowledge infrastructure designer


model perspectives (beyond the two predefined analysis reports) that might be

of use in further applications (also see chapter 9). The development of e.g. a B-

KIDE Tool Application Programming Interface (API) can address this problem

in the future. Also, the B-KIDE Tool only indirectly supports KI designers

in the actual activity of defining knowledge processes through a dedicated user

interface. Future tool extensions might focus on a knowledge process definition

interface that benefits KI designers to a greater extent. The B-KIDE Tool in its

current version is limited to hierarchical structures of reference models. Future

tool versions may focus on support for more sophisticated structures such as

topic maps [Top01] to provide more comprehensive support for the modeling of

relationships between reference model elements.

Chapter 9

Future Applications

Merely by taking thought a man cannot add an iota to his knowledge of the

world of facts.


Figure 9.1: Applying B-KIDE in Diverse Domains by Developing Additional B-

KIDE Methods

The B-KIDE Framework together with the B-KIDE Tool increases trans-

parency of knowledge work in organizations. While this PhD work demonstrates

the reasonability of the developed models of organizational knowledge work in

the context of the development of technological knowledge infrastructures, the

B-KIDE Framework is open for addressing a multitude of other challenges in

diverse contexts by developing complementary B-KIDE Methods on the basis of

152

CHAPTER 9. FUTURE APPLICATIONS 153

the B-KIDE Modeling Architecture (as depicted in figure 9.1). Thereby, not only

technological, but organizational or human aspects of knowledge management

may be addressed as well. This chapter gives an overview of a series of potential

application domains in research as well as in industry that appear to be capable

of successfully building on the concepts of this PhD work.

9.1 Identification of Knowledge Communities

Communities of Practice (CoP) represent a concept that focuses on learning in

groups of people through apprenticeship or so-called legitimate peripheral par-

ticipation (LPP) [Lin98]. Members of a CoP typically share common interests,

processes, practices and/or terminology. A more recent and process-centered

term used to describe a specific type of a community is knowledge community

[Rem02]. Knowledge communities are considered to be “communities that deal

with knowledge domains which are processed within or across various business

processes”. In this context, the B-KIDE Framework can aid identifying relevant

knowledge communities by identifying knowledge processes that 1) span multiple

business processes and 2) point to a set of organizational roles who all deal with

similar knowledge domains. Based on this identification, community nurturers

[Pre00] may focus on certain knowledge communities that are considered to be

important and may design instruments for supporting the development of them.

With the B-KIDE Framework, not only knowledge communities, but the role

different organizational roles play in these communities may be identified (as de-

picted in figure 9.2) answering questions such as: Who is mainly active or passive

in a given community? Who are the knowledge providers and consumers? Who

are knowledge hubs or brokers? Who are boundary spanners? Future research on

communities of practice can strongly benefit from considering existing, business-

relevant knowledge relations (as depicted in e.g. knowledge processes) between

actors.


Figure 9.2: Identification of Knowledge Communities with the B-KIDE Frame-

work

9.2 Identification of Knowledge Risks

For knowledge-intensive organizations, a lack of knowledge management may

pose risks for achieving organizational success. Inaccurately managed knowledge

processes represent such risks. Since the B-KIDE Framework identifies existing

knowledge processes, it bears the potential of being an instrument for the identifi-

cation and reduction of relevant knowledge risks. Based on knowledge processes,

risk analysts may either reduce the probability of risk occurrence (through e.g.

ensuring the execution of specific knowledge activities by modifying business

processes or the establishment of knowledge process owners [PP02]) or aim to re-

duce the consequences evoked by these risks (through e.g. risk hedging). Future

approaches addressing the management of risks from a knowledge perspective

are strongly advised to take such knowledge process investigations into account,

since knowledge processes describe business-relevant situations in which business-

critical knowledge risks may emerge.

9.3 Raising KM Maturity Levels of Organiza-

tions

The identification, support, management and improvement of knowledge pro-

cesses is of especial relevance in the context of knowledge management maturity

models. Existing maturity models1 build on an assessment of the quality of

1such as the KPQM of [PP02, OP03] depicted in table 8.1 on page 148


organizational knowledge processes in order to assign KM maturity levels for or-

ganizations. A necessary prerequisite for such an assessment is the identification

of knowledge processes. The B-KIDE Framework allows for the identification of

knowledge processes based on business processes and represents them in a way

that allows for evaluating the degree of organizational management concerning

them. By applying the B-KIDE Framework in concrete knowledge infrastructure

development projects, an organization is enabled to raise their maturity level

from ’1 - initial’ or ’2 - aware’ up to the level of ’3 - established’ [PP02]2. There-

fore, the B-KIDE Framework may play a key role in 1) the knowledge-oriented

development of organizations and 2) future research concerning the development

of knowledge-process oriented KM maturity models.

9.4 Controlling of Knowledge-Based Strategies

Organizations that consider knowledge as a key resource often are concerned

with the development, implementation, controlling, evaluation and improvement

of corporate knowledge strategies and corresponding operationalized knowledge

goals. The B-KIDE Framework allows for evaluating the degree to which such

organizational knowledge goals are considered in organizational structures. The

B-KIDE Framework identifies 1) if these knowledge goals are pursued in the

organization’s business processes and 2) if they find consideration in the organi-

zation’s knowledge infrastructure. Based on such evaluations, organizations may

adjust their KM interventions to better achieve their defined knowledge goals.

9.5 Enabling Intra-Organizational KM

Business processes are typically not limited to the boundaries of single organi-

zations, but span different organizations e.g. along a supply chain or within

distributed value generating networks. In such settings, the appropriate man-

agement of knowledge is even more crucial and also harder to achieve because

of e.g. competitive situations, geographically dispersed actors, varying organiza-

tional cultures, -languages or -vocabulary. Here, initiatives (such as cluster, B2B3

2also see table 8.1 on page 1483B2B...Business-to-Business


or marketplace initiatives), might benefit from having knowledge about critical,

cross-organizational knowledge processes that are in need for structured support

or management.

9.6 Ontology Engineering

An ontology is a logical theory accounting for the intended meaning of a for-

mal vocabulary, i.e. its ontological commitment to a particular conceptualization

of the world [Gua98]. Deeply rooted in philosophy, ontologies are applied in a

broad range of disciplines such as in artificial intelligence, knowledge- or language

engineering. Business process oriented knowledge management as a scientific do-

main partly integrates the concept of ontologies into existing approaches for the

implementation of technological knowledge infrastructures [KHS03]. In organi-

zational settings, heterogeneous vocabulary used by employees may prevent the

successful development and/or application of ontologies. Because the B-KIDE

Framework is able to identify the usage of heterogeneous vocabulary in orga-

nizations (through structured interviews), it may aid efforts that focus on the

engineering of ontologies in industrial environments (such as [TPSS04]).

Chapter 10

Conclusions

Um zu reflectieren, muß der Geist in seiner fortschreitenden Thatigkeit einen

Augenblick still stehn, das eben Vorgestellte in eine Einheit fassen, und auf

diese Weise, als Gegenstand, sich selbst entgegenstellen.


The B-KIDE Framework addresses the two research challenges (page 22) of this

PhD thesis, which are: 1) to support the execution of knowledge intensive and

interconnected business processes and 2) to support the reasonable application

of typical, technological KM functionality in given business contexts. “Business

Process Oriented Knowledge Management” (bpoKM, page 47), relatively a young

research domain emerged from the more established scientific domains of business

process- and knowledge management, aims to provide answers for the identified

research challenges. From a comprehensive review of current bpoKM approaches,

the following main conclusions can be drawn: 1) most existing bpoKM approaches

are based on performing analysis of business processes from a knowledge perspec-

tive (page 48) 2) some approaches already have successfully designed technological

support for specific business processes in specific application domains (“Business

Process Support” on page 62) and 3) yet no approaches tackle the two research

challenges of this PhD work in an integrative way (page 25).

10.1 Assessment

This thesis gives an answer to the introduced research challenge 1: The B-KIDE

Framework successfully identified relevant knowledge interactions in complex

157

CHAPTER 10. CONCLUSIONS 158

business process networks in three studies conducted with industrial partners.

By applying the B-KIDE Method for the development of technological knowl-

edge infrastructures, support for such knowledge interactions could be ensured

and achieved. Research challenge 2 was also successfully addressed: The B-KIDE

Framework provides comprehensive insights on how to employ “Arrow 3” KM

functionality in given business contexts in a way that suits both organizations

and employees. Two1 of the three studies performed actually integrated “Arrow

3” KM functionality in their respective knowledge infrastructure designs for the

support of knowledge intensive business processes.

10.2 Scientific Contributions

This PhD thesis has successfully addressed its research objectives. The following

main scientific contributions, already briefly mentioned in chapter 1, could be

achieved:

• This work provides a generic framework for the development of business

process-supportive, technological knowledge infrastructures. The B-KIDE

Framework leads to knowledge infrastructure designs that ensure a certain

degree of support for knowledge intensive business processes and corre-

sponding knowledge workers in a traceable and repeatable way. Thereby, it

ensures quality and reduces arbitrariness of the developed knowledge infras-

tructure designs across various application domains. The B-KIDE Frame-

work therefore represents a universal theory for knowledge infrastructure

development projects in organizations that is easily applicable and testable

by the principle of instantiation.

• Although the identification of knowledge processes has received attention

from current research, this work introduces a novel and suitable concept

for the identification and visualization of complex knowledge processes and

interactions that span a multitude of business processes and related knowl-

edge workers. The introduced concept of knowledge processes allows for

1These two were the studies where the B-KIDE Method was applied in a design (vs. evalu-ation) mode: Case study 1 (on page 120) and pilot study 2 (on page 133)


the identification, visualization and modeling of greatly distributed knowl-

edge work in organizations. Thereby, it enables detailed investigations of

organizational knowledge work by taking the complex nature of knowledge

into account.

• This work uniquely integrates organizational and technological dimensions

of knowledge infrastructure development efforts. By introducing an inte-

grative concept, which connects knowledge requirements of business pro-

cesses to technological KM functionality, the B-KIDE Framework signifi-

cantly contributes to current research focussing on closing the gap between

business process management- and information systems design approaches

[Gia99, WC03].

• This work introduces a novel model architecture and a supportive software

tool that enable the development of inter-subjective models of organiza-

tional knowledge work. Analyzing complex, combined social and techno-

logical systems such as organizations is not typically accomplished through

direct interventions in the system, but indirectly through appropriate mod-

els of the system in question [FS01]. The B-KIDE Framework introduces a

model architecture for modeling organizational knowledge work that spec-

ifies model elements, relationships, rules and semantics and thus enables

modelers to check structural and behavioral consistency as well as com-

pleteness of their models. The innovative B-KIDE Tool represents an im-

plementation of the B-KIDE Model Architecture that eases the application

of the introduced concepts. Applying the B-KIDE Framework together

with the accompanying B-KIDE Tool reduces complexity found in knowl-

edge intensive organizations (with respect to a modeling goal) and leads

to the development of inter-subjective models of organizational knowledge

work.

• This work answers the question of how certain maturity levels of existing

KM maturity models (such as [PP02, OP03]) can be achieved. The appli-

cation of the B-KIDE Framework in knowledge infrastructure development

projects enables organizations to raise their knowledge management ma-

turity level and to significantly increase their ability to appropriately deal

with the critical resource knowledge.


10.3 Final Statement

This work proposes that the introduced B-KIDE Framework provides a solution

to 1) supporting knowledge interactions in complex business process networks

and 2) the reasonable application of typical KM functionality in given business

contexts. The B-KIDE Framework represents a universally applicable theory

comprising the B-KIDE Model Architecture for modeling organizational knowl-

edge work, the B-KIDE Method for designing support for knowledge intensive

business processes and the B-KIDE Context that describes in which situations

the framework can successfully be employed. In addition, the B-KIDE Tool,

implementing the B-KIDE Model Architecture, provides an instrument that

reduces complexity and increases accuracy of applying the B-KIDE Framework.

With knowledge gaining more and more importance in modern organizations,

the challenges addressed in this PhD thesis are considered to be of highest rel-

evance for future research. This PhD work lays a sound fundament for the de-

velopment of knowledge infrastructures in knowledge intensive organizations. It

is hoped that the research performed here will 1) stimulate and trigger future

research on knowledge infrastructure development and the concept of knowledge

processes and 2) benefit organizations to mature their ability to deal with knowl-

edge in an effective and efficient way.

Appendix A

Quotes

Although providing the source of quotes gives important context for understand-

ing the intended meaning of the creator in a much better way, it also narrows

the reader’s mind. At the beginning of each chapter of this thesis, a quote is

introduced without giving the appropriate context right away to stimulate the

mind of the interested reader and, with respect to knowledge management,

to provide examples that powerfully illustrate the important role of context

information. For the sake of completeness, all quotes with their respective

sources are listed in this chapter.

Chapter 1

Es ist so schwer, den Anfang zu finden. Oder besser: Es ist schwer, am Anfang

anzufangen. Und nicht zu versuchen, weiter zuruckzugehen.

Ludwig Wittgenstein, On Certainty, §471

Chapter 2

Objectivity is a subject’s delusion that observing can be done without him.

Heinz von Forster, Einfuhrung in den Konstruktivismus, Page 31

Chapter 3

Ich mochte nur darauf hinweisen, daß es eine Zeit gab, in der man die

Ahnlichkeit der Empfindungen zur Basis der Kategorisierung von Pflanze und

Tier gemacht hat. Man denke [...] an die fruhen Taxonomien des Ulisse

Aldrovandi aus dem 16. Jahrhundert, der die scheußlichen Tiere (die Spinnen,

161

APPENDIX A. QUOTES 162

Molche und Schlagen) und die Schonheiten (die Leoparden, die Adler usw.) zu

eigenen Gruppen [von Lebewesen] zusammenfasste.

Heinz von Foerster, Wahrheit ist die Erfindung eines Lugners, Page 22/23

Chapter 4

Nicht das Sammeln und Speichern von Wissen, sondern die Nutzung des

Wissens in den Prozessen bestimmt den Wert von Wissen.

V. Bach, H. Osterle and P. Vogler. Business Knowledge Management in der

Praxis, Page 119

Chapter 5

Problems cannot be solved at the same level of awareness that created them.

Attributed to Albert Einstein (1879-1955)

Chapter 6

Consistency is the last refuge of the unimaginative.

Attributed to Oscar Wilde (1854-1900)

Chapter 7

What counts as its test? - “But is this an adequate test? And, if so, must it not

be recognizable as such in logic?” - As if giving grounds did not come to an end

sometime. But the end is not an ungrounded presupposition: it is an

ungrounded way of acting.

Ludwig Wittgenstein, On Certainty, §110

Chapter 8

Es verdient festgehalten zu werden, daß man bezweifeln kann, ohne zu

kritisieren, und kritisieren, ohne zu bezweifeln.

Sir K.R. Popper, Objektive Erkenntnis, Page 160 citing Poincare in

Wissenschaft und Hypothese.

Chapter 9

Merely by taking thought a man cannot add an iota to his knowledge of the

world of facts.

Sir K.R. Popper, The Logic of Scientific Discovery, Page 75

APPENDIX A. QUOTES 163

Chapter 10

Um zu reflectieren, muß der Geist in seiner fortschreitenden Thatigkeit einen

Augenblick still stehn, das eben Vorgestellte in eine Einheit fassen, und auf

diese Weise, als Gegenstand, sich selbst entgegenstellen.

Wilhelm von Humboldt, cited in Heinz von Forster et al, Einfuhrung in den

Konstruktivismus, Page 32

Appendix B

Research Approach

This PhD work aims to design and construct a framework for the development

of business process-supportive knowledge infrastructures1. In contrast to natural

sciences, the object of research here is a complex artifact (that is the framework)

designed and constructed by mankind (by the researcher vs. e.g. phenomena

observable in nature). The design, construction and evaluation of such artifacts

are inherent parts of a series of scientific domains such as method engineering

[Tol98], human-computer interfaces or algorithmics. A research approach that

focuses on these aspects of conducting research is design research:

“Design research involves the analysis of the use and performance

of designed artifacts to understand, explain and very frequently to

improve on the behavior of aspects of the artifact. [VK04]”

Therefore, the methodological research approach chosen to serve as a funda-

ment for this PhD work is design research. However, other research approaches

(such as case study research [Mac97] or action research [Koc97]) are utilized in

clearly defined areas of application within the overall design research approach.

Figure B.1 depicts the main process steps of design research along with expected

outputs and knowledge interactions between these steps. Also, complementary

research approaches utilized in this PhD work to achieve specific steps are illus-

trated. While figure B.1 visualizes the way research was performed in this PhD

1It is important to point out the two different usages of the term design here: The firstusage refers to designing a theoretical construct (a theory) about the process of conceptualizingbusiness process-supportive knowledge infrastructures as the main result of this PhD work.The second usage refers to the actual process itself.

164

APPENDIX B. RESEARCH APPROACH 165

project, the document at hand contains the final results of these efforts. In the

following sections, the chosen PhD research approach with its corresponding pro-

cess steps is introduced in greater detail (based on the approach introduced by

[VK04]).

Figure B.1: The Design Research Approach (Based on [VK04])

Awareness of Problem

The first step of design research deals with gaining a deeper understanding about

the problem domain. Desk research, the analysis of existing approaches and

related scientific domains based on available industrial and academic literature,

represents a sound instrument for successfully accomplishing this step. In this

PhD work, especially work from the scientific domains introduced in section 2.6

and chapter 2 and 3 provided valuable inputs for conceptualizing the problem

domain. The output of this step was a research proposal sketching up the main

challenges of this PhD work.

Suggestion

This step, immediately following the previous step, is concerned with developing

tentative designs. In the context of this PhD work, this was accomplished by

developing a tentative framework. In order to improve this tentative framework

an explorative case study was conducted. Case study research is especially em-

ployed in situations, where a contemporary phenomenon within its real-world


context is investigated and the boundaries between phenomenon and context are

not clearly evident [Mye04]. The conducted case study aimed to 1) improve the

quality of the tentative framework 2) achieve a more precise definition of the

research question and 3) identify new problems (since often relevant problems

arise when practitioners encounter new situations for which no guidelines have

been developed yet) [Mac97]. Following a case study research approach generated

valuable knowledge for the aforementioned aims.

Development

This step involves the development of artifacts based on experiences made in

previous steps. Within this PhD work, the core inputs were: 1) a profound

conceptualization of the problem domain 2) the tentative framework as well as 3)

insights gained from the conducted case study. Two artifacts, a framework (the

B-KIDE Framework, chapter 5) together with a software tool (the B-KIDE Tool,

chapter 6), were developed and represent the main output of this step.

Proof of Concept

In this step, the developed artifacts are evaluated according to the defined cri-

teria made explicit in the created proposal (for these criteria see the objectives

defined in section 1.2.1). Since in this PhD work the developed artifact repre-

sents a framework and an accompanying tool for the development of business

process-supportive knowledge infrastructures, concrete knowledge infrastructure

development projects with client organizations are necessary for proper evalua-

tion. To acknowledge this fact, the concept of action research was utilized. Action

research here is regarded to pursue a dual goal [Koc97]: 1) Improving the organi-

zation participating in the research through so-called positive interventions (pilot

studies) and 2) rigorously generating valid and consistent knowledge with respect

to a defined research question. Two justificative pilot studies were conducted that

both applied (through instantiation and utilization) the artifacts developed (see

chapter 7). The output of this step is an assessment of the suitability of the

developed artifacts with respect to the defined objectives.


Conclusion

Finally, the results of the proof of concept are interpreted in the light of the

tackled problem domain and conclusions for the improvement of the central

concepts of this work are drawn. Experiences are reflected and integrated in a

revised version following an iterative approach.

[VK04] summarize the process of design research in the following, illustrative

way:

The design researcher creates a reality through constructive inter-

vention [Development], then reflectively becomes a positivist observer

[Evaluation], recording the behavior of the system and comparing it

to the predictions (theory) set out during the [...] [Suggestion] phase

[VK04].

Appendix C

Supporting Resources

This chapter contains supporting resources for knowledge analysts.

C.1 Interview Guidelines

Interview guidelines provide support and checklists for the preparation and exe-

cution of interviews within the B-KIDE Framework.

C.1.1 B-KIDE Tool Preparation

1. Preparation of a list of all participating interviewees (B-KIDE Tool: Menu

- Project - Interview Setup - Interviewee Setup)

2. Preparation of a list of all participating analysts (B-KIDE Tool: Menu -

Project - Interview Setup - Analysts Setup)

3. Preparation of an organizational roles reference model (B-KIDE Tool:

Menu - Project - Reference Model Setup)

4. Preparation of a set of interviews (B-KIDE Tool: Menu - Project - Interview

Setup - Interview Setup)

5. Preparation of storage object and transfer object types (B-KIDE Tool:

Menu - Project - Advanced Setup - Generic Elements Setup)

6. Preparation of knowledge domain types (B-KIDE Tool: Menu - Project -

Advanced Setup - Knowledge Domain Type Setup)

168

APPENDIX C. SUPPORTING RESOURCES 169

7. Preparation of storage access types (B-KIDE Tool: Menu - Project - Ad-

vanced Setup - Storage Object Access Type Setup)

8. Preparation of a business process reference model (B-KIDE Tool: Menu -

Project - Reference Model Setup)

9. Preparation of business process - organizational roles assignment (B-KIDE

Tool: Menu - Project - Reference Model Setup)

C.1.2 Preparation for KI Analysts

• Preparation of all necessary documents (see section C.1.4)

• Establishment of an overview and an understanding about the targeted

business processes and organizational roles

• Investigation of the target area’s business strategy from a knowledge per-

spective for the development of an initial structure of the knowledge domain

reference model

C.1.3 Preparation for Interviewees

Interviewees can be asked to prepare themselves for the interviews by providing

them with the list of business processes that is relevant for them and asking

them to think about, what information they require and what information others

require from them in each of the listed business processes. By using this set of

answers as a starting point in corresponding interviews, the quality of gathered

interview data may be increased.

C.1.4 Documents necessary for Analysts

• Business Process Landscape including the targeted business process area

• Business Process Diagrams (Overview Flowcharts) for each business process

involved in the targeted interview

• Detailed Process Management Manual including each business process in-

volved in the targeted interview


• Organigram including the hierarchy of roles in the targeted organization

• Organizational Roles Assignment including all targeted organizational roles

and assigned employees

C.1.5 Documents necessary for Interviewees

• Business Process Landscape including the targeted business process area

• Business Process Diagrams (Overview Flowcharts) for each business process

involved in the targeted interview

C.1.6 Interview Setting

• The interview should be executed in a quiet environment, to avoid the

occurrence of any interference.

• The interview should not take longer than 2 hours, since after this time

experience showed that concentration of both analysts and interviewees

rapidly decreases.

• The analyst exclusively should use the computer during interviews. Only

for validation reasons at the end of each interview, the analyst should share

the B-KIDE Tool screen with the interviewee.

• Analysts and interviewee should have the documents, prepared in sections

C.1.4 and C.1.5, available to be able to look necessary things up during

interview time.

• Access to the interviewee’s work environment (e.g. intranet, etc.) at a

second computer would be beneficial to look up details that may emerge

during interviews.

C.1.7 Interview Execution

From an analyst perspective, the interview consists of the following main activi-

ties:


Introduction

• The analyst introduces himself to the interviewee.

• The analyst introduces the background, objectives and benefits of the B-

KIDE project.

• The analyst introduces the main process of interviewing.

• The analyst introduces the business processes for this interview. He checks

if they are known to the interviewee.

• The analyst checks for any questions up to now.

Main Interview Process

• For each relevant business process, the analyst determines which informa-

tion is needed by the interviewee, and which information others need from

the interviewee.

• For each piece of information, the analyst asks questions concerning aspects

of storing and transferring this information.

• In case of missing reference elements (such as knowledge domains, storage

objects, etc.) the analyst creates these objects together with the intervie-

wee. The analyst cross-checks the attributes of reference elements with the

interviewee each time he references them.

• The analyst validates the gathered interview data by presenting the B-KIDE

Tool interview screen with all relevant data to the interviewee.

Interview Close Out

• Interviews represent an opportunity to collect business process improvement

suggestions. Therefore, the analyst can take the opportunity and ask the

interviewee for potential improvements.

• The analyst introduces subsequent actions and steps in the respective

project.


• The analyst asks for any remaining questions.

• The analyst leaves his business card so that the interviewee can contact

him after the interview.

C.1.8 Interview Hints

Sticking to the following rules aids analysts in eliciting information from inter-

viewees in a way that suits the B-KIDE Framework.

Rule 1 “Utilize past typical and concrete business process executions

of the interviewee for setting the interview questions in an appropriate

context.”

Rule 2 “While performing interviews, focus on what information the

interviewee processes (needs, transfers, makes available, etc.) in his

corresponding business processes, not on what the interviewee does

within them.”

Rule 3 “In case an interviewee has more than one role, confront the

interviewee with the appropriate role description for this interview

at the beginning of the interview. Frequently check his answers for

potential misconceptions during the interview to ensure that the in-

terviewee gives his answers from the appropriate perspective (role).”

Rule 4 “Before creating a new reference element, check existing refer-

ence elements together with the interviewee to avoid duplicates. For

knowledge domain objects, utilize the buzzwords metadata to deal

with heterogeneous vocabulary.”

Rule 5 “Extend current reference elements and models only in a way

that preserves and refines previously gathered interview data.”


C.2 Interview Plan

The Interview Plan Template depicted in figure C.1 aids KI analysts in focus

setting and in planning their interview activities.

Figure C.1: The Interview Plan Template

Appendix D

B-KIDE Tool Details

This chapter introduces selected, detailed screenshots of the B-KIDE Tool.

Figure D.1: Property-Form for the Reference Element “Knowledge Domain”

174

APPENDIX D. B-KIDE TOOL DETAILS 175

Figure D.2: Property-Form for the Reference Element “Business Process”

Figure D.3: Property-Form for the Reference Element “Organizational Role”

Figure D.4: Property-Form for “Knowledge Work”


Figure D.5: Property-Form for the Reference Element “Storage Object”

Figure D.6: Property-Form for the Reference Element “Transfer Object”


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)



(2)


(3)



(4)

Appendix E

Empirical Study Data

E.1 Case Study 1 - Software Industry

Figure E.1: Microsoft Excel c© Interview Template Applied in Case Study 1

Figure E.1 depicts the Microsoft Excel c© interview template that was applied

to document gathered interview data in case study 1. Experiences made in case

study 1 showed that the complexity of the B-KIDE Modeling Structure calls

for a more sophisticated tool that supports knowledge analysts in the process of

interviewing more comprehensively. This issue laid the basis for the development

of the B-KIDE Tool.

180

APPENDIX E. EMPIRICAL STUDY DATA 181

Figure E.2: Manually created Landscape of Identified Knowledge Processes

Figure E.2 depicts the manually created landscape of identified knowledge

processes in case study 1. This landscape visualized knowledge work through the

concept of knowledge processes at case study company A.


Team Leader (TL) Knowledge Profile

KP Nr. Involved in

Specific Knowledge Activity

1.1.6 T, A

1.2.2 A

1.2.3 A

1.3.1 A

1.4.1 G

1.4.2 T

5.1.1 G, A

5.1.2 G

5.1.3 A

5.1.4 A

5.1.5 G

5.1.7 G,A

5.1.8 A

5.2.1 G,A

5.2.2 T

5.2.3 T, A

5.2.5 G, A

5.2.6 A

Table E.1: Example of a Role-Oriented Knowledge Profile Based on Identified

Knowledge Processes (KP)

Table E.1 comprises the results of a role-oriented filtering of the created

Knowledge Process Landscape of figure E.2. For each knowledge process, the

involvement of the organizational role Team Leader (TL) in the specific knowl-

edge activities generation (G), storage (S), transfer (T) and application (A) is

depicted. This filtering laid the basis for the creation of a knowledge portal

mockup (the Access Layer of the B-KIDE Knowledge Infrastructure Template

Architecture) for the role TL.


Figure E.3: UI Mockup of a Knowledge Portal Fragment for Role TL and Cor-

responding Knowledge Processes (KP)

Figure E.3 depicts the knowledge portal mockup that was created based on

the identified and filtered knowledge processes. Annotations flag corresponding

knowledge processes.


E.2 Pilot Study 1 - Automobile Industry

Figure E.4: B-KIDE-generated Knowledge Process Landscape

Figure E.4 depicts the results of investigations performed at pilot study com-

pany B. In total, 25 knowledge processes could be identified.


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.


E.3 Pilot Study 2 - Consulting Industry

Figure E.6: B-KIDE-generated Knowledge Process Landscape

Figure E.6 depicts the results of the investigations performed at pilot study

company C. In total, 28 knowledge processes could be identified.


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.


Business Manager (BM) Knowledge Profile

KP Nr. Involved in

Specific Knowledge Activity

1 G, S, A

3 A

5 G, S, A

13.4 A

13.5 G, S, A

14 / 14.1 S, A

14.2 A

16.4 A

X1 Open

X2 A

Table E.2: Example of a Role-Oriented Knowledge Profile Based on Selected

Knowledge Processes (KP)

Table E.2 comprises the results of a role-oriented filtering of the created

Knowledge Process Landscape of figure E.7. For each knowledge process, the

involvement of the organizational role Business Manager (BM) in the specific

knowledge activities generation (G), storage (S), transfer (T) and application

(A) is depicted. This filtering laid the basis for the creation of the B-KIDE

Knowledge Infrastructure Template Architecture Access Layer for the role BM.

Bibliography

[Ado] Adobe. SVG Plugin. http://www.adobe.com/svg, last accessed on

June 14th, 2004.

[AHMM02] A. Abecker, K. Hinkelmann, H. Maus, and H.J. Muller.

Geschaftsprozess-orientiertes Wissensmanagement. Springer, Berlin,

2002.

[Ale79] C. Alexander. The Timeless Way of Building. Oxford Press, 1979.

[All98] T. Allweyer. Modellbasiertes Wissensmanagement. IM Information

Management, 13(1):37–45, 1998.

[Ame03] American National Standard for Information Technology. Role Based

Access Control (Draft), 4 2003.

[AML+01] A. Abecker, G. Mentzas, M. Legal, S. Ntioudis, and G. Papvas-

siliou. Business-Process Oriented Delivery of Knowledge through

Domain Ontologies. In Proceedings of DEXA conference, TAKMA-

2001, Second International Workshop on Theory and Applications

of Knowledge Management, 2001.

[Ass02] Association for Computing Machinery. ACM Computing Classifica-

tion System, 2002.

[BB98] P.O. Bengtsson and J. Bosch. Scenario-Based Software Architec-

ture Reengineering. In Proceedings of International Conference of

Software Reuse 5 (ICSR5), June 1998.

[BCK98] L. Bass, P. Clements, and R. Kazman. Software Architecture in

Practice. Addison Wesley, 1998.

189

http://www.adobe.com/svg

BIBLIOGRAPHY 190

[BM04] R. A. Burkhard and M. Meier. Tube Map: Evaluation of a Visual

Metaphor for Interfunctional Communication of Complex Projects.

In Proceedings of I-Know’04 - 4th International Conference on

Knowledge Management, Graz, Austria, 2004.

[BMR+96] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal.

Pattern-Oriented Software Architecture, Volume 1: A System of Pat-

terns. Wiley, 1996.

[Boe88] B. W. Boehm. A Spiral Model of Software Development and En-

hancement. IEEE Computer, 21(5), 1988.

[BPSM+04] T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler, F. Yergeau,

and J. Cowan. Extensible Markup Language (XML) 1.1 - W3C

Recommendation 04 February 2004, edited in place 15 April 2004.

Technical report, W3C - World Wide Web Consortium, 2004.

[Bri96] S. Brinkkemper. Method Engineering: Engineering of Information

Systems Development Methods and Tools. Information and Software

Technology, 38:275–280, 1996.

[BsV00] V. Bach, H. Osterle, and P. Vogler. Business Knowledge Manage-

ment in der Praxis - Prozessorientierte Losungen zwischen Knowl-

edge Portal und Kompetenzmanagement. Springer Verlag, 2000.

[CLC04] S.Y. Choy, W.B. Lee, and C.F. Cheung. A Systematic Approach

for Knowledge Audit Analysis: Integration of Knowledge Inventory,

Mapping and Knowledge Flow Analysis. In Proceedings of I-Know’04

- 4th International Conference on Knowledge Management, Graz,

Austria, 2004.

[Coc00] A. Cockburn. Writing Effective Use Cases. Addison-Wesley Pub

Co, 2000.

[DB03] J. Dutra and J. Busch. Taxonomy Development with NASA. In In-

ternational Conference on Space Mission Challenges for Information

Technology (SMC-IT), 2003.

BIBLIOGRAPHY 191

[DHB01] I. Dammig, U. Hess, and C. Borgmann. Wissenstransparenz als Wet-

tbewerbsvorteil - Einstiegsmethode und -werkzeug in das praktische

Wissensmanagement von Unternehmen. In Proceedings of WM2001,

1. Konferenz Professionelles Wissensmanagement, Baden - Baden,

2001.

[DHMS00] M. Diefenbruch, M. Hoffmann, A. Misch, and Helge Schneider. Situ-

ated Knowledge Management - KM on the Borderline Between chaos

and Rigidity. In Proceedings of PAKM 2000 - Conference on Prac-

tical Aspects of Knowledge Management, pages 8–1–8–7, 2000.

[Dia01] C. Dias. Corporate Portals: A Literature Review of a New Concept

in Information Management. International Journal of Information

Management, 21(4):269–287, August 2001.

[DJB95] T. Davenport, S. Jarvenpaa, and M. Beers. Improving Knowledge

Work Processes (Working Paper). Technical report, Ernst & Young

LLP, Center for Business Innovation, 1995.

[DRA+03] B. Decker, J. Rech, K.D. Althoff, A. Klotz, E. Leopold, and A. Voss.

Participative Process Introduction: A Case Study in the indigo

Project. In Proceedings of I-Know ’03, 3rd international conference

on knowledge management, Graz, Austria, 2003.

[Dub03] Dublin Core Metadata Initiative. The Dublin Core Metadata Ele-

ment Set (Draft), 02 2003.

[Dus02] S. Dustdar. Collaborative Knowledge Flow - Improving Process-

Awareness and Traceability of Work Activities. In Proceedings of the

Fourth International Conference on Practical Aspects of Knowledge

Management (PAKM2002), 2002.

[Eng03] W. Engelbach. Vorgebaute Informationsraume fur Information-

srecherchestrategien in wissensintensiven Geschaftsprozessen. In

U. Reimer, A. Abecker, S. Staab, and G. Stumme, editors, WM

2003, Professionelles Wissensmanagement - Erfahrungen und Vi-

sionen, Luzern, 2003.

BIBLIOGRAPHY 192

[ESR99] M. J. Eppler, P. M. Seifried, and A. Ropnack. Improving Knowl-

edge Intensive Processes through an Enterprise Knowledge Medium.

In Proceedings of the 1999 ACM SIGCPR conference on Computer

personnel research, 1999.

[FMO+94] G. Fischer, R. McCall, J. Ostwald, B. Reeves, and F. Shipman.

Seeding, Evolutionary Growth and Reseeding: Supporting the In-

cremental Development of Design Environments. In Proceedings of

the Conference on Computer-Human Interaction (CHI’94), Boston,

MA, USA, 1994.

[FS00] M. Fowler and K. Scott. UML konzentriert - Eine strukturierte

Einfuhrung in die Standard-Objektmodellierungssprache, 2. Ausgabe.

Addison-Wesley, 2000.

[FS01] O. K. Ferstl and E. J. Sinz. Grundlagen der Wirtschaftsinformatik,

Bd.1, 4. Auflage. Oldenbourg Verlag, 2001.

[Fug93] A. Fuggetta. A Classification of CASE Technology. IEEE Computer,

26(12):25–38, December 1993.

[Gia99] G. M. Giaglis. On the Integrated Design and Evaluation of Busi-

ness Processes and Information Systems. Communications of the

Association for Information Systems, 1, 1999.

[Goe02] T. Goesmann. Ein Ansatz zur Unterstutzung wissensinten-

siver Prozesse durch Workflow-Management-Systeme. PhD thesis,

Fakultat IV - Elektrotechnik und Informatik der technischen Uni-

versitat Berlin, Berlin, Deutschland, 2002.

[GPSW03] N. Gronau, U. Palmer, K. Schulte, and T. Winkler. Modellierung von

wissensintensiven Geschaftsprozessen mit der Beschreibungssprache

K-Modeler. In U. Reimer, A. Abecker, S. Staab, and G. Stumme, ed-

itors, WM 2003, Professionelles Wissensmanagement - Erfahrungen

und Visionen, Luzern, 2003.

[Gro] Object Management Group. UML Resource Page. http://www.

omg.org/technology/uml/, last accessed on September 24th, 2004.

http://www.omg.org/technology/uml/

http://www.omg.org/technology/uml/

BIBLIOGRAPHY 193

[Gro03] SVG Working Group. Scalable Vector Graphics (SVG) 1.1 Spec-

ification. Technical report, W3C - World Wide Web Consortium,

2003.

[Gua98] N. Guarino. Formal Ontology and Information Systems. In Proceed-

ings of FOIS’98, Trento, Italy, pages 3–15, Amsterdam, 1998. IOS

Press.

[Har02] H.J. Hartl. Konzeption eines Wissensportals auf der Ba-

sis von Hyperwave zur Unterstutzung des wissenschaftlichen

Forschungsprozesses. Master’s thesis, Wirtschaftswissenschaftliche

Fakultat der Universitat Regensburg, Regensburg, Deutschland,

2002.

[Hei01] P. Heisig. Business Process oriented Knowledge Management -

Methode zur Verknupfung von Wissensmanagement und Geschaft-

sprozessgestaltung. In Proceedings of WM2001, 1. Konferenz Pro-

fessionelles Wissensmanagement, Baden - Baden, 2001.

[HGM01] M. Hoffmann, T. Goesmann, and A. Misch. Unsichtbar oder

Vergessen - Wie man ”verborgenen Wissensprozessen” auf die

Schliche kommt. In Proceedings des Workshops Geschaftsprozes-

sorientiertes Wissensmanagement der 1. Konferenz ”Professionelles

Wissensmanagement” WM 2001, pages 59–63. Shaker-Verlag, 2001.

[HHDG02] M. Hoffmann, T. Herrmann, M. Diefenbruch, and T. Goesmann.

PRomisE2 - Recording and Displaying Situated Process Informa-

tion in Knowledge Management Applications. In Proceedings of

I-Know’02 - International Conference on Knowledge Management,

Graz - Austria, July 2002.

[HNT99] M.T. Hansen, N. Nohria, and T. Tierney. What’s your Strategy

for Managing Knowledge? Harvard Business Review, March-April

1999.

[Hol95] D. Hollingsworth. Workflow Management Coalition - The Workflow

Reference Model. Technical report, Workflow Management Coali-

tion, Jan 1995.

BIBLIOGRAPHY 194

[HTEN03] C. Huth, N. Tas, I. Erdmann, and L. Nastansky. GroupProcess Web:

Graphisch interaktives Management von Ad-hoc-Geschaftsprozessen

im Web. In U. Reimer, A. Abecker, S. Staab, and G. Stumme, edi-

tors, WM 2003, Professionelles Wissensmanagement - Erfahrungen


[HvR00] B.J. Hommes and V. van Reijswoud. Assessing the Quality of

Business Process Modelling Techniques. In Proceedings of the 33rd

Hawaii International Conference on System Sciences, 2000.

[Hyp] Hyperwave. Knowledge Management Software. http://www.

hyperwave.com, last accessed on September 9th, 2004.

[IAB95] IABG. V-Model, Lifecycle Process Model - Brief Description. IABG

Industrieanlagen-Betriebsgesellschaft mbH, Einsteinstr. 20, D-85521

Ottobrunn, 1995.

[isoa] The ISO Survey of ISO 9000 and ISO 14000 Certificates

- Eleventh Cycle: Up to and including December 31st,

2001. http://www.iso.ch/iso/en/prods-services/otherpubs/

pdf/survey11thcycle.pdf, last accessed on September 9th, 2004.

[isob] The ISO Survey of ISO 9000 and ISO 14000 Certificates - Twelfth

Cycle: Up to and including December 31st, 2002. http://www.

iso.ch/iso/en/iso9000-14000/pdf/survey12thcycle.pdf, last

accessed on September 9th, 2004.

[ISO00a] ISO - International Organisation for Standardization. Qualitatsman-

agementsysteme: Anforderungen (ISO 9001:2000), Dezember 2000.

[ISO00b] ISO - International Organisation for Standardization. Qualitatsman-

agementsysteme: Grundlagen und Begriffe (ISO 9000:2000), Dezem-

ber 2000.

[ISO00c] ISO - International Organisation for Standardization. Qualitats-

managementsysteme: Leitfaden zur Leistungsverbesserung (ISO

9004:2000), Dezember 2000.

http://www.hyperwave.com

http://www.hyperwave.com

http://www.iso.ch/iso/en/prods-services/otherpubs/pdf/survey11thcycle.pdf

http://www.iso.ch/iso/en/prods-services/otherpubs/pdf/survey11thcycle.pdf

http://www.iso.ch/iso/en/iso9000-14000/pdf/survey12thcycle.pdf

http://www.iso.ch/iso/en/iso9000-14000/pdf/survey12thcycle.pdf

BIBLIOGRAPHY 195

[Jan00] C. Jansen. Prozessunterstutzung durch Wissensplattformen. PhD

thesis, Universitat St. Gallen, Hochschule fur Wirtschafts-, Rechts-

und Sozialwissenschaften (HSG), St. Gallen, Schweiz, 2000.

[JHS01] S. Jablonski, S. Horn, and M. Schlundt. Process Oriented Knowl-

edge Management. In Eleventh International Workshop on Research

Issues in Data Engineering: Document Management for Data In-

tensive Business and Scientific Applications, Heidelberg, Germany,

pages 77–84. IEEE Computer Society, 2001.

[Kan03] D. Kandpal. Augmenting Knowledge-Intensive Systems with Dy-

namic Personalization Concepts. PhD thesis, Graz University of

Technology, Graz, Austria, 2003.

[KHS03] S. Kim, H. Hwang, and E. Suh. A Process-based Approach to

Knowledge-Flow Analysis: A Case Study of a Manufacturing Firm.

Knowledge and Process Management, 10(4), 2003.

[Koc97] N.F. Kock Jr. The Effects of Asynchronous Groupware on Business

Process Improvement. PhD thesis, University of Waikato, Hamilton,

New Zealand, 1997.

[Kru] P. Kruchten. What is the Rational Unified Process? http://

www.therationaledge.com/content/jan_01/f_rup_pk.html, last

accessed on December 19th, 2003.

[KS98] G. Kotonya and I. Sommerville. Requirements Engineering. John

Wiley & Sons Ltd, 1998.

[KSG+03] W. Kienreich, V. Sabol, M. Granitzer, F. Kappe, and K. Andrews.

InfoSky: A System for Visual Exploration of Very Large, Hierarchi-

cally Structured Knowledge Spaces. In Proceedings der GI Work-

shopwoche LLWA - Workshop der Fachgruppe FGWM (Fachgruppe

Wissensmanagement), October 2003.

[KT00] D. Karagiannis and R. Telesko. The EU-Project PROMOTE: A

Process-Oriented Approach for Knowledge Management. In Proceed-

ings of PAKM 2000 - Conference on Practical Aspects of Knowledge

Management, pages 13–1–13–7, 2000.

http://www.therationaledge.com/content/jan_01/f_rup_pk.html

http://www.therationaledge.com/content/jan_01/f_rup_pk.html

BIBLIOGRAPHY 196

[Kun02] S. Kundermann. Ansatze zur Qualitatsverbesserung von Wis-

sensprozessen. Master’s thesis, Johann Wolfgang Goethe-

Universitat, Lehrstuhl fur Entwicklung betrieblicher Information-

ssysteme, Frankfurt am Main, 2002.

[LB03] C. Larman and V.R. Basili. Iterative and Incremental Development:

A Brief History. IEEE Computer, 36(6):47–56, 2003.

[Leh00] F. Lehner. Organizational Memory. Carl Hanser Verlag Munchen

Wien, 2000.

[Leh02] F. Lehner. Informationsbroschure des Lehrstuhls: TEIL W - Wis-

sensmanagement und Prozeßmanagement. Technical report, Univer-

sitat Regensburg, Mai 2002.

[Lin98] S.N. Lindstaedt. Group Memories: A Knowledge Medium for Com-

munities of Interest. PhD thesis, University of Colorado, Boulder,

U.S.A., 1998.

[Liv] Livelink. Knowledge Management Software, OPENTEXT. http:

//www.opentext.com, last accessed on September 9th, 2004.

[Lot] Lotus. Knowledge Management Software, IBM. http://www.

lotus.com, last accessed on September 9th, 2004.

[LSF+02] S. Lindstaedt, M. Strohmaier, J. Farmer, J. Hrastnik, and H. Rollett.

KMap: Providing Orientation for Practitioners when Introducing

Knowledge Management. In Proceedings of the 4th International

Conference on Practical Aspects of Knowledge Management (PAKM

2002). Springer Verlag, 2002.

[LSF+03] S. Lindstaedt, M. Strohmaier, J. Farmer, J. Hrastnik, and H. Rol-

lett. Integration von Prozess- und Wissensmanagement-orientierten

Designstrategien zur Erstellung benutzerfreundlicher Unternehmen-

sportale. In U. Reimer, A. Abecker, S. Staab, and G. Stumme, edi-

tors, WM 2003, Professionelles Wissensmanagement - Erfahrungen


http://www.opentext.com

http://www.opentext.com

http://www.lotus.com

http://www.lotus.com

BIBLIOGRAPHY 197

[Mac96] L. Macaulay. Requirements for Requirements Engineering Tech-

niques. In 2nd International Conference on Requirements Engineer-

ing (ICRE ’96), 1996.

[Mac97] M.S. MacNealy. Toward Better Case Study Research. IEEE Trans-

actions on Professional Communication, 40(3):182–196, September

1997.

[Mai02] R. Maier. Knowledge Management Systems. Springer Verlag Berlin,

2002.

[MH99] F. Maurer and H. Holz. Process-Oriented Knowledge Management

for Learning Software Organizations. In Proceedings of the 12th

Workshop on Knowledge Acquisition, Modeling, and Management

(KAW-99), 1999.

[MHA03] K. Mertins, P. Heisig, and K. Alwert. Process-Oriented Knowledge

Structuring. Journal of Universal Computer Science, 9(6), 2003.

[MHV03] K. Mertins, P. Heisig, and J. Vorbeck. Knowledge Management -

Concepts and Best Practices. Springer Verlag Berlin Heidelberg New

York, 2003.

[Mica] Microsoft. Moving Java Applications to .NET. http:

//msdn.microsoft.com/library/en-us/dndotnet/html/dotnet_

movingjavaapps.asp, last accessed on June 14th, 2004.

[Micb] Microsoft. .NET Framework. http://www.microsoft.com/net, last

accessed on June 14th, 2004.

[Micc] Microsoft. Visio 2003. http://www.microsoft.com/office/visio,

last accessed on June 14th, 2004.

[Micd] Microsoft. What is .NET? http://www.microsoft.com/net/

basics, last accessed on June 14th, 2004.

[MPF04] T. Mueller-Prothmann and I. Finke. SELaKT - Social Network Anal-

ysis as a Method for Expert Localisation and Sustainable Knowledge

Transfer. In Proceedings of I-Know’04 - 4th International Conference

on Knowledge Management, Graz, Austria, 2004.

http://msdn.microsoft.com/library/en-us/dndotnet/html/dotnet_movingjavaapps.asp



http://www.microsoft.com/net

http://www.microsoft.com/office/visio

http://www.microsoft.com/net/basics

http://www.microsoft.com/net/basics

BIBLIOGRAPHY 198

[MR01] R. Maier and U. Remus. Towards a Framework for Knowledge Man-

agement Strategies: Process Orientation as Strategic Starting Point.

In Proceedings of the 34th Hawaii International Conference on Sys-

tem Sciences, 2001.

[MR02] R. Maier and U. Remus. Defining Process-oriented Knowledge Man-

agement Strategies. Knowledge and Process Management, 9(2):103–

118, 2002.

[MR03] R. Maier and U. Remus. Implementing Process-Oriented Knowl-

edge Management Strategies. Journal of Knowledge Management,

7(4):62–74, 2003.

[MRH+04] K. Matzler, M. Rier, H. Hinterhuber, B. Renzl, and C. Stadler.

Methoden und Konzepte im strategischen Management - Bedeutung,

Zufriedenheit, Forschungsbedarf. In Weissenberger-Eibl, editor, Un-

ternehmen im Umbruch - Konzepte, Instrumente und Erfolgsmuster.

Cactus Group Verlag, 2004.

[MT02] H. Maurer and K. Tochtermann. On a New Powerful Model for

Knowledge Management and its Applications. Journal of Universal

Computer Science, 8(1):85–96, 2002.

[Mye04] M.D. Myers. Qualitative Research in Information Systems. Archival

Version: MIS Quarterly (21:2), June 1997, pp. 241-242. MISQ Dis-

covery, June 1997. Updated Version available from http://www.

misq.org/discovery/MISQD_isworld/, last accessed on September

9th, 2004, revision from February 24th, 2004.

[Net04] Netscape Communication Corporation. DMOZ - Open Directory

Project (ODP), 2004.

[Noh00] H. Nohr. Wissen und Wissensprozesse visualisieren. Technical re-

port, HBI Stuttgart, 2000.

[Noh02] H. Nohr. Strategie- und Geschaftsprozessorientiertes Wissensman-

agement. Technical report, Hochschule der Medien, Studiengang

Informationswirtschaft, 2002.

http://www.misq.org/discovery/MISQD_isworld/

http://www.misq.org/discovery/MISQD_isworld/

BIBLIOGRAPHY 199

[NT97] I. Nonaka and H. Takeuchi. Die Organisation des Wissens.

Wie japanische Unternehmen eine brachliegende Ressource nutzbar

machen. Campus, Frankfurt a.M., New York, 1997.

[ON01] E. Oxendine and M. E. Nissen. Knowledge Process and System

Design for the Carrier Battle Group. Knowledge and Innovation:

Journal of the Knowledge Management Consortium International,

1(3), 2001.

[OP03] A. Oberweis and O. Paulzen. Kontinuierliche Qualitatsverbesserung

im Wissensmanagement - ein prozessbasiertes Reifegradmodell. In

Proceedings der KnowTech 2003 - 5. Konferenz zum Einsatz von

Knowledgemanagement in Wirtschaft und Verwaltung, 2003.

[Pai03] D. Paier. Network Analysis: A Tool for Analysis and Monitoring

of the Dynamics of Knowledge Processes in Organizations. In Pro-

ceedings of I-Know ’03, 3rd international conference on knowledge

management, Graz, Austria, 2003.

[Pep00] S. Pepper. The TAO of Topic Maps. In Proceedings of XML Europe

2000, Paris, France, 2000.

[PMA02] G. Papavassiliou, G. Mentzas, and A. Abecker. Integrating Knowl-

edge Modelling in Business Process Management. In ECIS2002

conference: The Xth European Conference on Information Systems,

2002.

[PNAM02] G. Papavassiliou, S. Ntioudis, A. Abecker, and G. Mentzas. Man-

aging Knowledge in Weakly-Structured Administrative Processes.

In Proceedings of The Third European Conference on Organiza-

tional Knowledge, Learning, and Capabilities - OKLC 2002, Athens,

Greece, April 2002.

[PP02] O. Paulzen and P. Perc. A Maturity Model for Quality Improve-

ment in Knowledge Management. In A. Wenn, M. McGrath, and

F. Burstein, editors, Enabling Organisations and Society through In-

formation Systems, Proceedings of the 13th Australasian Conference

BIBLIOGRAPHY 200

on Information Systems (ACIS 2002), pages 243–253, Melbourne,

2002.

[PPS02] A. Papargyris, A. Poulymenakou, and K. Samiotis. Knowledge Pro-

cesses Embedded in Task Structures: Implications for the Design

of a Technical and Organisational Solution. In Proceedings of the

Fourth International Conference on Practical Aspects of Knowledge

Management (PAKM2002), 2002.

[Pre00] J. Preece. Online Communities: Designing Usability and Supporting

Sociability. John Wiley & Sons; 1st edition, september 2000.

[PRR98] G. Probst, S. Raub, and K. Romhard. Wissen managen - wie Un-

ternehmen ihre wertvollste Ressource optimal nutzen. Dr. Th. Gabler

Verlag, 1998.

[Rem01] U. Remus. Integrierte Prozeß- und Kommunikationsmodellierung

als Ausgangspunkt fur die Verbesserung von wissensintensiven

Geschaftsprozessen. In Proceedings of WM2001, 1. Konferenz Pro-

fessionelles Wissensmanagement, Baden - Baden, 2001.

[Rem02] U. Remus. Prozeßorientiertes Wissensmanagement - Konzepte und

Modellierung. PhD thesis, Wirtschaftswissenschaftliche Fakultat der

Universitat Regensburg, Regensburg, Deutschland, 2002.

[RES+00] J. Raimann, E. Enkel, A. Seufert, G. von Krogh, and A. Back.

Supporting Business Processes through Knowledge Management -

A Technology-based Analysis. Technical report, Research Center

Knowledge Source, University of St. Gallen, March 2000.

[RL00] U. Remus and F. Lehner. The Role of Process-oriented Enter-

prise Modeling in Designing Process-oriented Knowledge Manage-

ment Systems. In Proceedings of the AAAI Symposium on Bringing

Knowledge to Business Processes. Stanford, CA, USA, 2000.

[RMS00] U. Reimer, A. Margelisch, and M. Staudt. EULE: A Knowledge-

Based System to Support Business Processes. Knowledge-Based Sys-

tems, 13(5):261–269, 2000.

BIBLIOGRAPHY 201

[Rol03] H. Rollett. Knowledge Management - Processes and Technologies.

Kluwer Academic Publishers, Boston/Dordrecht/London, 2003.

[Roy70] W.W. Royce. Managing the Development of Large Software Systems.

In Proceedings of IEEE Wescon, August 1970.

[RR99] S. Robertson and J. Robertson. Mastering the Requirements Process.

ACM Press, 1999.

[RR03] L. Ramos and D.W. Rasmus. Best Practices in Taxonomy Devel-

opment and Management. Giga Information Group, January, 8th

2003.

[RZ96] D. Riehle and H. Zullighoven. Understanding and Using Patterns

in Software Development. Theory and Practice of Object Systems,

2(1), 1996.

[SAA+02] G. Schreiber, H. Akkermans, A. Anjewierden, R. de Hoog, N. Shad-

bolt, W. Van de Velde, and B. Wielinga. Knowledge Engineering

and Management. The MIT Press, 2002.

[Sch96] A.W. Scheer. ARIS-House of Business Engineering. IWI Hefte, 133,

1996.

[Sch00] A.W. Scheer. ARIS - Business Process Modeling. Springer Verlag,

2000.

[Sin95] E. Sinz. Ansatze zur fachlichen Modellierung betrieblicher Informa-

tionssysteme - Entwicklung, Aktueller Stand und Trends. Bamberger

Beitrage zur Wirtschaftsinformatik, 34, 1995.

[Sin97] E. Sinz. Architektur betrieblicher Informationssysteme. Bamberger

Beitrage zur Wirtschaftsinformatik, 40, 1997.

[Sit02] A.A. Sitiol. CASE Technology. In 2002 Student Conference on Re-

search and Development, Shah Alam, Malaysia, 2002.

[Siv99] Y.Y. Sivan. Launching a Knowledge Infrastructure: How to Jump-

start the Process. WebNet Journal, 1(4):16–19, October 1999.

BIBLIOGRAPHY 202

[Siv01] Y.Y. Sivan. Nine Keys to a Knowledge Infrastructure: A Proposed

Analytic Framework for Organizational Knowledge Management.

Research Paper, March 2001.

[SP01] P. Starkloff and K. Pook. Process-Integrated Learning: The ADVI-

SOR Approach for Corporate Development. In Proceedings of The

Third International Workshop on Learning Software Organizations

(LSO’01), September 2001.

[SRB03] S. Schwarz and T. R. Roth-Berghofer. Towards Goal Elicitation

by User Observation. In Proceedings der GI Workshopwoche LLWA

- Workshop der Fachgruppe FGWM (Fachgruppe Wissensmanage-

ment), October 2003.

[Str03a] M. Strohmaier. A Business Process Oriented Approach for the

Identification and Support of Organizational Knowledge Processes.

In 4. Oldenburger Fachtagung Wissensmanagement, Potenziale -

Konzepte - Werkzeuge, 2003.

[Str03b] M. Strohmaier. Designing Business Process Oriented Knowledge In-

frastructures. In Proceedings der GI Workshopwoche LLWA - Work-

shop der Fachgruppe FGWM (Fachgruppe Wissensmanagement),

October 2003.

[TK02] R. Telesko and D. Karagiannis. Process-based Knowledge Man-

agement: Experiences with two Projects. In Proceedings of Tenth

European Conference on Information Systems ECIS 2002, Gdansk,

Poland, June 2002.

[Toc02] K. Tochtermann. Personalization in Knowledge Management. In Pe-

ter J. Nuernberg, editor, Metainformatics: International Symposium

(MIS), Esbjerg, Denmark, 2002.

[Tol98] J.-P. Tolvanen. Incremental Method Engineering with Modeling

Tools. PhD thesis, University of Jyvaskyla, Finland, 1998.

[Top01] TopicMaps.Org Authoring Group. XML Topic Maps (XTM) 1.0 -

TopicMaps.Org Specification, 08 2001. Available from: http://www.

topicmaps.org/, Editors: Steve Pepper, Graham Moore.

http://www.topicmaps.org/

http://www.topicmaps.org/

BIBLIOGRAPHY 203

[TPSS04] C. Tempich, S. Pinto, S. Staab, and Y. Sure. A Case Study in Sup-

porting Distributed, Loosely-Controlled and Evolving Engineering

of Ontologies (DILIGENT). In Proceedings of I-Know’04 - 4th In-

ternational Conference on Knowledge Management, Graz, Austria,

2004.

[VA+02] A. Voss, K.D. Althoff, , U. Becker-Kornstaedt, B. Decker, A. Klotz,

E. Leopold, and J. Rech. Enhancing Experience Management and

Process Learning with Moderated Discourses: the indiGo Approach.

In Proceedings of the Fourth International Conference on Practical

Aspects of Knowledge Management (PAKM2002), 2002.

[VK04] V. Vaishnavi and W. Kuechler. Design Research in Information Sys-

tems. http://www.isworld.org/Researchdesign/drisISworld.

htm, last accessed on September 9th, 2004, revision from February

20th, 2004.

[WC03] V. Weerakkody and W. Currie. Integrating Business Process Reengi-

neering with Information Systems Development: Issues & Implica-

tions. In Proceedings of Business Process Management Conference

(BPM), Eindhoven, Netherlands, June 2003.

[Wer] P. Werbicki. Summary of Chapters 1-6 of the Book ”Requirements

Engineering”ISBN 3-540-76006-7, Springer-Verlag, Linda Macaulay,

1996. http://www.criticaljunction.com/werbicki/, last ac-

cessed on January 9th, 2004.

[WK02] R. Woitsch and D. Karagiannis. Process-oriented Knowledge Man-

agement Systems Based on KM-Services: The PROMOTE Ap-

proach. In Proceedings of the Fourth International Conference on

Practical Aspects of Knowledge Management (PAKM2002), 2002.

[WK03] R. Woitsch and D. Karagiannis. Knowledge Management Service

Based Organisations. In 4. Oldenburger Fachtagung Wissensman-

agement, Potenziale - Konzepte - Werkzeuge, 2003.

[Woi03] R. Woitsch. Knowledge Management Services as a Basic Concept

for Enterprise Knowledge Management System. In Proceedings of I-

http://www.isworld.org/Researchdesign/drisISworld.htm

http://www.isworld.org/Researchdesign/drisISworld.htm

http://www.criticaljunction.com/werbicki/

BIBLIOGRAPHY 204

Know ’03, 3rd international conference on knowledge management,

Graz, Austria, 2003.

[Wol03] U. Woltron. Der Ort als Maschine. Der Standard, page A8, May,

31th, 2003.

[WWT98] C. Wargitsch, T. Wewers, and F. Theisinger. An Organizational-

Memory-Based Approach for an Evolutionary Workflow Manage-

ment System-Concepts and Implementation. In Proceedings of

HICCS’31, the 31st Hawaii International Conference on Systems

Sciences, 1998.

[YC79] E. Yourdon and L.L. Constantine. Structured Design - Fundamentals

of a Discipline of Computer Program and Systems Design. Prentice-

Hall, 1979.

[You89] E. Yourdon. Modern Structured Analysis. Prentice-Hall, 1989.

Index

.NET framework, 113

Access, 96

ADVISOR, 51

Application object, 80

Architecture, 64

ARIS, 49

B-KIDE

context, 71, 72, 74

design process, 90

framework, 71, 72, 112, 117, 139,

145, 157, 160

framework application, 97

framework evolution, 149

knowledge infrastructure tem-

plate architecture, 94

method, 71, 72, 89, 113, 122, 129,

135, 158, 160

model architecture, 71, 72, 76,

160

modeling structure, 77, 104, 105,

113

modeling technique, 85, 112, 120,

127

reference models, 81, 103, 104,

106, 120, 128, 134

tool, 71, 72, 99, 140, 160

tool evolution, 150

BKM, 53

Business process, 78

Business process analysis, 48

Business process execution, 55, 61

Business process improvement, 58, 62

Business process landscape, 110

Business process learning, 50, 61

Business process management, 30

Business process modeling, 48, 61

Business process oriented knowledge

management, 46

Business process perspective, 83

Business process re-engineering, 58

Business process support, 52, 61

case study, 117, 119

CASE tools, 41

Constructivism, 27

Contents, 95

Continuous process improvement, 58

DECOR, 58

Decoupled knowledge processes, 146

EULE, 58

Fit criteria, 92, 124, 131, 138

Generation object, 79

GPO-WM, 54

205

INDEX 206

indiGO, 60

K-Modeler, 50

Knowledge, 30

Knowledge analysts, 36, 85, 99, 106,

107

Knowledge communities, 153

Knowledge domains, 31, 79

Knowledge flows, 70

Knowledge infrastructure design

evaluation, 124, 131, 138

Knowledge infrastructure design val-

idation, 94

Knowledge infrastructure designers,

37, 90, 99, 110

Knowledge infrastructure develop-

ment project, 33

Knowledge infrastructures, 20, 26,

33, 70

Knowledge management, 20, 30

Knowledge management activities,

32

Knowledge management interven-

tions, 30

Knowledge management maturity

levels, 146, 154

Knowledge management strategies,

47, 155

Knowledge management system

functionality, 23

Knowledge management technolo-

gies, 44

Knowledge management worker, 36

Knowledge managers, 35

Knowledge networks reference

model, 54

Knowledge process definition, 91,

122, 129, 135

Knowledge process landscape, 111

Knowledge process optimization, 146

Knowledge process perspective, 84

Knowledge process quality model,

146, 154

Knowledge processes, 30, 66–69

Knowledge project managers, see

Project managers

Knowledge risks, 154

Knowledge user, 36

Knowledge work, 31, 66, 78

Knowledge workers, 31, 36

KODA, 59

Lessons learned, 139

Maurer-Tochtermann model, 23

Meta knowledge, 95

Milos, 56

MODEL, 52

Model perspectives, 83, 110

Model system refinement, 89, 121,

128, 135

Object system modeling, 87, 121,

128, 134

Oblivion, 148

Ontologies, 96, 156

Organizational knowledge, 30

Organizational roles, 79

Organizations, 26, 29

Pattern analysis, 43

INDEX 207

Patterns, 39

Personalization, 148

Pilot studies, 117, 126, 132

Pre-modeling, 87, 106, 120, 128, 134

Preliminary knowledge infrastruc-

ture design, 93, 124, 131, 137

Project managers, 36

PRomisE2, 55

PROMOTE, 57

Quality gateway, 91

Rational unified process, 41

Realism, 27

Requirements engineering, 38

Role orientation, 26, 148

Scope definition, 86, 120, 127, 133

Social network analysis, 43

Specific knowledge activities, 31, 70,

79

Spiral model, 40

Storage object, 80, 81, 123, 130, 137

System analysis, 37

System design, 38

System usage, 39

Taxonomies, 95

Transfer object, 80, 81, 123, 130

Undefined work activity, 79

User observation, 43

V-Model, 40

Waterfall model, 40

Workbrain, 57

Workflow management systems, 55

About the Author

Markus B. Strohmaier received a master’s degree in Telematics from Graz

University of Technology in 2002 (Institute for Technical Informatics) and a doc-

toral degree in Technical Sciences from the Graz University of Technology in 2004

(Institute for Knowledge Management and Knowledge Visualization). Prior to

joining the Know-Center Graz as a project manager and researcher, he worked

for the Austrian Research Centers (ARC), Knapp Logistics, Siemens PSE and

numerous other companies. His research interests include knowledge and pro-

cess management, organizational development, business information systems and

systems analysis and design.

208

B-KIDE: A Framework and a Tool for Business...

Documents

Transcript of B-KIDE: A Framework and a Tool for Business...