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
Preface
This PhD thesis1comprises 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 the
Johann G¨otschl, 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.
Zusammenfassung (German abstract)
Die Notwendigkeit des effektiven Managements von Wissen wird heute von Unternehmen zunehmend erkannt. Um diesem Anspruch gerecht zu werden, wurden neue vielversprechende und umfassende Technologien von Wirtschaft und Wissenschaft entwickelt. Mit der Verf¨ugbarkeit und Weiterentwicklung dieser Innovationen verst¨arkte sich auch die Bereitschaft von Unternehmen neue Wissensmanagement-Technologien anzuwenden. Die erfolgreiche Anwendung in Unternehmen stellt jedoch eine komplexe, mehrdimensionale Herausforderung und ein aktuelles Forschungsgebiet dar. Die vorliegende Dissertation nimmt sich deshalb diesem Thema an und stellt einen Framework f¨ur die Entwicklung von gesch¨aftsprozessunterst¨utzenden, technologischen Wissensinfrastrukturen vor. W¨ahrend dabei Gesch¨aftsprozesse den organisatorischen Rahmen f¨ur die Anwendung von Wissensmanagement-Technologien bieten, so repr¨asentieren Wissensinfrastrukturen ein Konzept, dass Wissensmanagement in Organisatio-nen erm¨oglicht. Der in dieser Dissertation entwickelte B-KIDE Framework bietet Unterst¨utzung in der Entwicklung von Wissensinfrastrukturen, welche innovative Wissensmanagementfunktionalit¨aten beinhalten und sichtbar organisatorische Gesch¨aftsprozesse unterst¨utzen, an. Das entwickelte B-KIDE Tool erleichtert die Anwendung des B-KIDE Frameworks f¨ur Entwickler von Wissensinfrastrukturen. Drei durchgef¨uhrte, empirische Studien mit Unternehmen unterschiedlichster Branchen bekr¨aftigen die Relevanz und Viabilit¨at der eingef¨uhrten Konzepte.
Schl¨usselw¨orter: Wissensmanagement, Wissensinfrastrukturen, Gesch¨ aftspro-zesse, Systemanalyse, Systemgestaltung, Entwicklungsinstrumente
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
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
2.4.1 Waterfall Model . . . 41
2.4.2 Spiral Model . . . 41
2.4.3 V-Model . . . 41
2.4.4 Rational Unified Process . . . 42
2.5 Tools . . . 42
2.6 Relevant Scientific Domains . . . 43
2.7 Assessment in the Context of this Work . . . 45
3 Business Process Oriented Knowledge Management 47 3.1 Introduction . . . 47
3.2 Overview of Challenges and Approaches . . . 48
3.3 Business Process Analysis . . . 49
3.4 Business Process Modeling . . . 49
3.4.1 Challenges . . . 49
3.4.2 Benefits . . . 50
3.4.3 Selected Approaches . . . 50
3.5 Business Process Learning . . . 51
3.5.1 Challenges . . . 51
3.5.2 Benefits . . . 52
3.5.3 Selected Approaches . . . 52
3.6 Business Process Support . . . 53
3.6.1 Challenges . . . 53
3.6.2 Benefits . . . 54
3.6.3 Selected Approaches . . . 54
3.7 Business Process Execution . . . 56
3.7.1 Challenges . . . 56
3.7.2 Benefits . . . 57
3.7.3 Selected Approaches . . . 57
3.8 Business Process Improvement . . . 59
3.8.1 Challenges . . . 59
3.8.2 Benefits . . . 60
3.8.3 Selected Approaches . . . 60
3.9 Assessment in the Context of this Work . . . 61
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.3 B-KIDE Tool Approach . . . 102
6.2 B-KIDE Tool Structure . . . 103
6.3 B-KIDE Modeling Structure Mapping . . . 105
6.3.1 Reference Models . . . 105
6.3.2 Interview Data . . . 106
6.4 B-KIDE Tool Application . . . 107
6.4.1 Setup and Pre-Modeling . . . 107
6.4.2 Interviewing . . . 108
6.4.3 Analysis . . . 111
6.5 B-KIDE Tool Support for the B-KIDE Framework Application . . 113
6.6 B-KIDE Tool Implementation . . . 114
7 Proof of Concept 118 7.1 Introduction . . . 118
7.2 Case Study 1: Software Industry . . . 120
7.2.1 Context . . . 120
7.2.2 Pursued Goals . . . 120
7.2.3 Approach Taken . . . 121
7.2.4 Achieved Results . . . 126
7.3 Pilot Study 1: Automotive Industry . . . 127
7.3.1 Context . . . 127
7.3.2 Pursued Goals . . . 128
7.3.3 Approach Taken . . . 128
7.3.4 Achieved Results . . . 133
7.4 Pilot Study 2: Consulting Industry . . . 133
7.4.1 Context . . . 133 7.4.2 Pursued Goals . . . 134 7.4.3 Approach Taken . . . 134 7.4.4 Achieved Results . . . 139 7.5 Lessons Learned . . . 140 7.5.1 B-KIDE Framework . . . 140 7.5.2 B-KIDE Tool . . . 141 7.6 Assessment . . . 142
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.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
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
5.7 Scope of the B-KIDE Method . . . 91
5.8 Design Process “Designing Knowledge Infrastructures” . . . 92
5.9 The Knowledge Infrastructure Template Architecture . . . 96
6.1 Scope of the B-KIDE Tool . . . 101
6.2 Primary Actors of the B-KIDE Tool . . . 102
6.3 B-KIDE Tool Principle Approach . . . 102
6.4 Simplified Illustration of B-KIDE Tool’s Main Structure and Ele-ments . . . 103
6.5 Main User Interface of the B-KIDE Tool . . . 104
6.6 Implementation of the B-KIDE Tool Reference Models . . . 105
6.7 Implementation of the B-KIDE Tool Interview Forms . . . 106
6.8 Setting Up Interviews with the B-KIDE Tool . . . 107
6.9 B-KIDE Tool’s Interview Forms per Interview . . . 108
6.10 Setting Up Reference Elements with the B-KIDE Tool . . . 108
6.11 Inputting Interview Data with the B-KIDE Tool . . . 109
6.12 Editing Reference Elements with the B-KIDE Tool . . . 110
6.13 Creating Analysis Reports with the B-KIDE Tool . . . 111
6.14 The B-KIDE Tool Analysis Report “Business Process Landscape” 112 6.15 The B-KIDE Tool Analysis Report “Knowledge Process Landscape”113 6.16 Technological Fundament of the B-KIDE Tool: The .NET Frame-work [Mica] . . . 115
6.17 Architectural Sketch of the B-KIDE Tool . . . 116
7.1 The Modeling Procedure Applied in Case Study 1 . . . 121
7.2 The Design Method Applied in Case Study 1 . . . 123
7.3 A High Level Conceptualization of the Anticipated Support for Knowledge Flows in Case Study 1 . . . 124
7.4 An Example of Knowledge Process Definition in Case Study 1 . . 125
7.5 Case Study 1 Results: Four Role Oriented Knowledge Portals . . 127
7.6 The Modeling Procedure Applied in Pilot Study 1 . . . 128
7.7 The Evaluation Method Applied in Pilot Study 1 . . . 130
7.8 A High Level Conceptualization of the Anticipated Support for Knowledge Flows in Pilot Study 1 . . . 131
7.10 The Modeling Procedure Applied in Pilot Study 2 . . . 134 7.11 The Design Method Applied in Pilot Study 2 . . . 136 7.12 A High Level Conceptualization of the Anticipated Support for
Knowledge Flows in Pilot Study 2 . . . 137 7.13 An Example of Knowledge Process Definition in Pilot Study 2 . . 138 9.1 Applying B-KIDE in Diverse Domains by Developing Additional
B-KIDE Methods . . . 153 9.2 Identification of Knowledge Communities with the B-KIDE
Frame-work . . . 155 B.1 The Design Research Approach (Based on [VK04]) . . . 166 C.1 The Interview Plan Template . . . 174 D.1 Property-Form for the Reference Element “Knowledge Domain” . 175 D.2 Property-Form for the Reference Element “Business Process” . . . 176 D.3 Property-Form for the Reference Element “Organizational Role” . 176 D.4 Property-Form for “Knowledge Work” . . . 176 D.5 Property-Form for the Reference Element “Storage Object” . . . . 177 D.6 Property-Form for the Reference Element “Transfer Object” . . . 177 D.7 Setup Form for the Definition of Storage and Transfer Object Types178 D.8 Knowledge Process Landscape Generation with the B-KIDE Tool
(1) . . . 178 D.9 Knowledge Process Landscape Generation with the B-KIDE Tool
(2) . . . 179 D.10 Knowledge Process Landscape Generation with the B-KIDE Tool
(3) . . . 179 D.11 Knowledge Process Landscape Generation with the B-KIDE Tool
(4) . . . 180 E.1 Microsoft Excel cInterview 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
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
2.1 Aspects of Knowledge Infrastructure Development . . . 36
5.1 B-KIDE Reference Models and Business Analogies . . . 83
5.2 B-KIDE Model Perspectives . . . 84
5.3 B-KIDE Modeling Technique Activities . . . 87
7.1 Overview of Conducted Studies . . . 119
7.2 Scope Definition and Interview Planning in Case Study 1 . . . 122
7.3 KI Focus: Definition of Knowledge Processes to be Supported . . 123
7.4 Scope Definition and Interview Planning in Pilot Study 1 . . . 129
7.5 KI Focus: Definition of Knowledge Processes to be Supported . . 131
7.6 Scope Definition and Interview Planning in Pilot Study 2 . . . 135
7.7 KI Focus: Definition of Knowledge Processes to be Supported . . 137
8.1 Maturity Stages of the KPQM [PP02] . . . 148
E.1 Example of a Role-Oriented Knowledge Profile Based on Identified Knowledge Processes (KP) . . . 183
E.2 Example of a Role-Oriented Knowledge Profile Based on Selected Knowledge Processes (KP) . . . 189
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
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
XML Extensible Markup Language
Introduction
Es ist so schwer, den Anfang zu finden. Oder besser: Es ist schwer, am Anfang anzufangen. Und nicht zu versuchen, weiter zur¨uckzugehen.
Appendix Chapter A on page 162 Knowledge in modern economies is increasingly playing a key role in 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 ofknowledge 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
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, chapter 8]
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 ofisolated 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 situasec-tions 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 Management 3MT...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 anorganizational 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 appropriate term “Knowledge Infrastructure”, which is not a term strongly (mis-)used by the software industry and better describes the anticipated concepts.
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 ofbusiness process-supportive, technologicalknowledge 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 business
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 ofknowledge workers for their respective knowl-edge intensive business processes
2. The application of the concept leads to knowledge infrastructure designs that enable role orientedaccess to knowledge for knowledge workers in or-ganizations
3. The application of the concept leads to knowledge infrastructure designs that enable autonomousrouting of knowledgefrom/to corresponding knowl-edge workers in their business processes
4. The application of the concept leads to knowledge infrastructure designs that enforce a more standardized way of executing knowledge work in or-ganizations
5. The application of the concept leads to increased transparency of knowl-edge work in organizations and its implications for technological knowlknowl-edge 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 knowledgewithin 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 and
thus, cannot flow (knowledge as a process versus an object) [Rem02, page 122]. The term “flow of knowledge” here is simplistically used to describe a focused, constructivist relationship between knowledge supply and knowledge application entities.
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 termstechnological knowledge infrastructure, business process, knowledge process, specific knowledge activity,
8Here, a necessary distinction between specificknowledge activities (on a knowledge object
level [SAA+02]) andknowledge 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]).
Knowledge Infrastructure
Development
Objectivity is a subject’s delusion that observing can be done without him.
Appendix Chapter A on page 162 Technological knowledge infrastructures are technological systems. This in-cludes software applications such as knowledge management-, document- or con-tent management systems, intra- or extranets, file servers, data bases but also custom tailored systems. Approaches focussing on the development of knowl-edge infrastructures only sporadically exist (e.g. [Siv99]). Detailed concepts concerning the domain at hand are not available. However, mature approaches and concepts stemming from related research domains that are relevant in the context of knowledge infrastructure development are available. For example, work performed in the field of software-, systems- or method-engineering (such as [You89, Bri96, Tol98]) as well as knowledge based or information system de-velopment (such as [SAA+02, Sin95]) can significantly contribute to the topic at hand.
2.1
The
Knowledge
Infrastructure
Develop-ment Project
Knowledge management initiatives, such as the development of knowledge infrastructures, are typically organized as a project [MR02]. In this work, a
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
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 the
termknowledge engineer. Rooted in the domain of knowledge engineering, a knowledge engineer aims to elicit knowledge from experts to implement that knowledge in so-called knowledge based systems. Instead of replacing knowledge of experts, in this PhD work a knowledge analyst aims to analyze knowledge work of knowledge workers in order to support them by means of supportive knowledge infrastructures.
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, certaintasks 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-Shelf
4similar to what [FS01] define as the task layer (“Aufgabenebene”) of business information
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, whilesystem usagecomprises 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 togeneralizea 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. Theiterative 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 develdevel-opment, 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 softSoft-ware 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 the
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]). CASEtools,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 basictask
(“Aufgabenebene”) and task-carrier (“Aufgabentr¨agerebene”) layers [FS01]. Tasks describe organizational activities that need to be carried out in order to achieve certain business goals. Task carriers are organizational entities (humans or systems) responsible for executing a certain task. Based on this basic distinction, several instruments (e.g. Entity Relationship Diagrams, UML Models) are utilized to design technological support for the execution of business processes. This PhD work addresses bothtask layers andtask-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 forknowledge 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 aframework and an
accompanying software tool that aids the process of developing business process-supportive knowledge infrastructures.
Business Process Oriented
Knowledge Management
Ich m¨ochte nur darauf hinweisen, daß es eine Zeit gab, in der man die ¨
Ahnlichkeit der Empfindungen zur Basis der Kategorisierung von Pflanze und Tier gemacht hat. Man denke [...] an die fr¨uhen Taxonomien des Ulisse Aldrovandi aus dem 16. Jahrhundert, der die scheußlichen Tiere (die Spinnen, Molche und Schlagen) und die Sch¨onheiten (die Leoparden, die Adler usw.) zu eigenen Gruppen [von Lebewesen] zusammenfasste.
Appendix Chapter A on page 162
3.1
Introduction
The emergence of the phenomenon of knowledge intensive business processes raised the need for an integration of the existing research domains of business process- and knowledge management. A commonly used term to describe this relatively young research domain is “Business Process oriented Knowledge 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.
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 explicitly
mentioned 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 of strategic considerations has been recognized by academia and comprehensive work regarding these 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 modmod-eling 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
