Reconciling Knowledge Management and Workflow Management Systems: The Activity-Based Knowledge Management Approach

Abstract: Current trends in collaborative knowledge management emphasize the importance of inter- and intra-organizational business process support. Enactment of business processes has primarily been a domain of workflow management systems. In this paper we propose a hybrid architecture for reconciliation of knowledge management and workflow management systems in order to support process participants in organizations, who are increasingly distributed and need to share and distribute knowledge artifacts. Today one pressing challenge is to utilize software as to create, share, and exchange (knowledge) work in collaborative knowledge activities across locations, while still being business process aware. This paper develops a conceptual framework, discusses a software architecture, and presents examples of a software system implementation for activity-based knowledge management for global project teams.

Key Words: workflow, knowledge management

Category: H.4

1 Introduction

Organizations face unprecedented competition, forcing them to offer exceptional levels of service - at whichever stage or sector of the productive business process they find themselves. As a consequence organizations need to communicate, collaborate, and coordinate their (knowledge) work activities, projects, and complex business processes in real-time [Zeng, 01] and on a global scale. Knowledge is seen as a critical factor in optimizing corporate performance. Knowledge work requires the interaction of many individuals, groups, and project teams. Participants interact and coordinate their work with others, regardless where they are and what sort of computer or mobile device they use. Today e-mail is the most popular application on the Internet and used to exchange ideas, documents and "knowledge-artifacts" in general. But still it remains a challenge to manage knowledge-based projects and coordinate work activities. Whilst systems such as knowledge management (KM) and workflow management systems (WfMS) are becoming more and more commonplace, it is still true to say that the links between work activities, their resources, and communications between the actors are not recorded in KM systems. An important goal knowledge management initiatives aim for is to record the history of creation, seamless access, distribution, and assessment of knowledge work. The interdependence of IT and information assets have never been greater than in the area of the new networked global economy. Efficient technology and communication infrastructure is a key factor to the success and viability of a modern, flexible, and adaptive organization.

This leads to changing business objectives as well as changing communication practices. Organizations are forced to: manage and coordinate their product and service development processes; make their products and services available as quickly as possible; and to involve employees, customers, suppliers and partners in different stages of the business processes. Therefore organizations aim to resolve four major issues (in some instances with the help of KM systems): (a) coordination across departments, project groups and their various responsibilities, and applications; (b) coordination with their customers, partners, suppliers, distributors, retailers, employees and even competitors; (c) traceability of knowledge work at all stages of business processes regardless of location; and (d) adequate infrastructure to understand, evaluate, and monitor work activities and processes. The relatively new discipline of Knowledge Management has arisen as a result of the ongoing search by organizations for competitive advantage and leverage of their knowledge assets, allied with the progressive development of information systems. Two different schools of thought influence the literature on KM. The Japanese perspective [Nonaka, 98] distinguishes between explicit and tacit knowledge, and proposes the conversion between the two forms as the key to knowledge creation. The Western, mainly US view of knowledge is of a management process, with the systematic storage and retrieval of information in context.

The contribution of this paper is to present the Activity-based Knowledge Management approach as a conceptual basis for reconciling Knowledge Management with Workflow Management Systems. The underlying proposition of our approach is to associate work activities including their deliverables (e.g. artifacts) with time and cost related information with business processes (i.e. workflow instances). In essence, we think that for knowledge management activities support for ad hoc processes is crucial and do not aim to model knowledge-based business processes in advance. This contrasts a more traditional understanding of Workflow Management Systems. Therefore our approach focuses more on ad hoc process support rather than on techniques found in KM literature [e.g. Applehans, 98] and has more similarities with the approach presented by [Binbasioglu, Karagiannis, 00] and by [Karagiannis, 95]. The remainder of the paper is organized as follows: Section 2 elaborates on the conceptual framework for knowledge work activities. This is achieved by first decomposing knowledge work activities in the next section and then by presenting a "technology framework" in order to understand knowledge-based information systems along two orthogonal dimensions: Knowledge Usage and Knowledge Context. Section 3 discusses the building blocks of Activity-based Knowledge Management solutions. Section 4 discusses Related Work. Section 5 proposes a software architecture for enabling process modeling and instantiation for Activity-based KM systems for global project teams. Section 6 discusses an example of Activity-based Knowledge Management. Conclusions are finally presented in Section 7.

2 Conceptual Framework for Knowledge-Based Work Activities

Knowledge Management (KM) is often loosely defined in terms of processes, culture, and ways of communicating. KM, it can be argued, represents the processes that enable the organization to act, in response to the changing internal and external environments in which they operate. Drucker (1994) discusses a "knowledge society" where "knowledge workers" play a central role and "knowledge-based intangibles" such as product development know-how being the capital of the future.

In order to understand key functionalities of information systems aiming to support Knowledge Management Table 1 [Doculabs, 03] provides an overview of functional categories of KM systems.

There are many framework proposed in the literature focusing on understanding key functionalities of information systems aiming to support Knowledge Management [e.g. Applehans, 98; Binbasioglu, Karagiannis, 00, Doculabs, 03] to name a few. Some of the proposed categories help us to gain a clear picture as to in which areas KM systems should provide IT support to organizations. In some categories KM systems on the market today are not sufficient, but require interfaces to systems such as workflow management systems, Groupware, or Project Management (PM) systems.

Advances in the area of Internet Computing, WfMS, and KM are often seen as substantial for supporting distributed knowledge work. Cooperative knowledge work in teams is increasing and as a consequence the use of collaborative KM systems and WfMS are becoming more pervasive. WfMS have been defined as "technology based systems that define, manage, and execute workflow processes through the execution of software whose order of execution is driven by a computer representation of the workflow process logic" [WfMC, 95]. To fully understand the context of collaborative technologies for organizations it is important to first analyze the dimensions of current systems. In this paper our model to analyze collaborative technologies distinguishes two dimensions: Knowledge Usage and Knowledge Context as shown in Figure 1. Knowledge Usage is about the "paradigm" knowledge is used. In its simplest form knowledge is only retrieved. The next stage allows retrieval and sharing of knowledge. The following stage enables users to create workspaces by organizing knowledge artifacts using files and folder hierarchies. The distribution stage enables knowledge workers to distribute knowledge artifacts (objects) by using push/pull mechanisms. Finally the link stage allows retrieval, sharing, workspaces, distribution, and in addition allows links between all knowledge artifacts. The second dimension Knowledge Context reveals contextual information on knowledge artifacts. Generally we can say that the higher contextual information is the more process awareness is stored together with knowledge artifacts. In its simplest stage it allows auditing of knowledge artifacts. For example users may view timestamp information on creation and routing of artifacts. The second stage enables organizational modeling, i.e. to define persons, roles, departments, and other organizational constructs required to design organizational structure. Organizational models allow organizations to define a set of access rights and rules for artifacts. The third stage additionally enables process modeling. Process tracking enables administrators to view the progress of business processes and the progress of activities as the building blocks of processes. Finally Reporting and Analysis supports analysis of all previously explained stages, and statistical comparisons between them.

We find it useful to relate technologies on the market today to those two dimensions in order to elaborate our proposed Activity-based KM approach. Groupware systems usually provide very low knowledge context information but provide relatively high knowledge usage capabilities, since they enable users to retrieve, share, organize their work in workspaces, and to distribute artifacts. An example of a system also supporting linkage of knowledge artifacts will be presented in section 4. Document Management systems are increasingly integrated with WfMS as recent mergers demonstrate (e.g. Lotus Notes/OneStone). Project management (PM) software is still mostly viewed as a software for individuals (i.e. project managers) and rarely offers collaborative or business process aware solutions. Moreover, in most cases PM software is not integrated with corporate information systems and in fact is only utilized as a graphical modeling tool for outlining tasks. Most Knowledge Management systems on the market today are workspace-centered and provide only very simple forms to model organizational structures (e.g. using roles only, but not skills). It is interesting to note that nearly no KM system provides interfaces to business process modeling and enactment systems (the domain of WfMS). Most KM-systems enable users to retrieve knowledge artifacts from repositories, but rarely allow distribution and process awareness (see section 3 for examples).

A modeled business process such as "customer order entry" can be modeled using a WfMS. However a modeled process can only be enacted (instantiated) as it was designed. If an exception occurs, a workflow administrator needs to re-model the process before the execution can continue. This limits the usability of WfMS in a world where constant adaptation to new situations is necessary and where teams are increasingly mobile and distributed. An example of an ad-hoc process is discussion of a project's design review using e-mail (Groupware). Workflow management systems are typically organizationally aware because they contain an explicit representation of organizational processes. In recent years there has been considerable attempts to merge workflow and knowledge management technologies [Dayal, 01]. Industrial research labs [Chen, 01] and product teams [Dustdar, 02; 04] have made significant steps forward. A WfMS can impose a rigid work environment on users, which often has a consequence. One example is among users who perform time-consuming manual "work arounds"; the consequence is lower efficiency and dissatisfaction with the system. Workflow automation provides unique opportunities for direction information flow and monitoring work performance. As a consequence WfMS enable continuous loops of sub processes such as goal setting, working, monitoring the work, measuring performance, recording and analyzing the outputs and evaluating the "productivity" of personnel. Users of WfMS often consider the controlling and monitoring possibilities as a "dark side" of these systems, which results in demotivating employees. A business process has well defined inputs and outputs and serves a meaningful purpose either inside or between organizations. Business processes and their corresponding workflows exist as logical models. When business process models are executed they have specific instances. When a workflow is instantiated the whole workflow is called a work case [WfMC, 95]. The WfMS enacts the real world business process for each process instance. A business process consists of a sequence of activities. An activity is a distinct process step and may be performed either by a human agent or by a machine. Any activity may consist of one or more tasks. A set of tasks to be worked on by a user (human agent or machine) is called work list. The work list itself is managed by the WfMS. The WfMC calls the individual task on the work list work item [WfMC, 95]. To summarize, a workflow is the instantiated (enacted or executed) business process, either in whole or in parts. During enactment of a business process documents, which are associated to tasks are passed from one task participant to another. In most cases this passing of documents or executing applications is performed according to a set of rules. A WfMS is responsible for control and coordination such as instantiating the workflow, assigning human or non-human agents to perform activities, generating worklists for individuals, and routing tasks and their associated objects such as documents between the agents. For an in-depth discussion on WfMS we refer to e.g. Bussler in [Bussler, 99].

Research shows that team performance is positively affected by communications between team members, as shown in [McDonough, 99]. Literature stresses the importance of the formal and informal communicative aspects of collaborative systems, which reflect the underlying structural dependencies in work settings [McDonough, 99]. Working in organizations is often characterized as "networks of commitments," as people in the organization send work through the systems [Winograd, 86]. Figure 1 suggests that KM systems of moving from currently being mostly "retrieval" oriented towards "collaborative" direction and on the business process spectrum some KM systems strive to support the spectrum of ad-hoc business processes and modeled processes as depicted in Figure 1.

3 Foundations of Activity-Based Knowledge Management

Knowledge can be viewed as information enriched with context. With context we mean information about the "who, when, how, and why". As an example, consider an "Explorer"-like view on a file system. This view allows the person to see documents (artifacts) stored inside folders. The name of such folders might reflect project names themselves. The mentioned view on these documents does not contain further contextual information on what a person (yourself, or others) actually have to do (did) with it (e.g. create another document, send an e-mail to customer, call partner organization, etc.). For example if the person in the above example needs to see who actually received a document stored in any given (project) folder, he is required to manually retrieve his e-mail box in order to find this information. This simple example shows that links between artifacts, such as documents or database information, and activities performed by persons are usually not stored in information systems such as KM or WfMS. However this linkage is of paramount importance for knowledge-intense business processes in order to provide contextual information on knowledge artifacts for processes such as new product development, which cannot be modeled using a WfMS. We propose activities as an important building block for reconciliation of KM systems and WfMS. Activities have multiple relationships with other entities highly relevant to information systems dealing with knowledge work, as depicted in Figure 2. Activities require resources (e.g. persons), documents, time, and deliver deliverables. Resources are required to perform activities. Those resources used for activities generate costs. The same applies to the time required to perform activities: it generates costs.

4 Related Work

There has been a lot of work on classification models for collaborative systems, however, no "one and agreed upon" taxonomy of analyzing and understanding collaborative systems has been proposed so far. Academia and industry suggest various classification schemes. In industry for example, people frequently use the term e-mail and groupware interchangeably. More generally, there is the tendency to classify categories of collaborative systems by naming a product (e.g. often many use the term Lotus Notes and Groupware interchangeably). Academic research has suggested many different classification models. For a recent extensive survey of collaborative application taxonomies see [Bafoutsou, Mentzas, 02]. [DeSanctis, Gallupe, 87], Ellis, Gibbs and Rein [Ellis et al, 91] and [Johansen, 88] suggest a two dimensional matrix based on time and place, where they differentiate between systems' usage at same place/same time (e.g. electronic meeting rooms), same place/different time (e.g. newsgroups), different place/different time (e.g. workflow, e-mail), different place/same time (audio/video conferencing, shared editors). This classification model helps to easily analyze many tools on the market today; however, it fails to provide detailed insights on collaborative work activities themselves as well as their relationship to business processes. [Ellis, 98] provides a functionally oriented taxonomy of collaborative systems, which assists in understanding the integration issues of workflow and groupware systems and is shown in Table 2.

The classification system of Ellis [Ellis, 98] provides a framework to understand the characteristics of collaborative systems and their technical implementations. The first category (Keepers) provides those functionalities related to storage and access to shared data (persistency). The metaphor used for systems based on this category is a "shared workspace". A shared workspace is basically a central repository where all team members put (upload) shared artifacts (in most cases documents) and share those among the team members. Technical characteristics of "keepers" include database features, access control, versioning, and backup/recovery control. Popular systems examples include BSCW [Bentley et al., 97], IBM/Lotus TeamRoom and the Peer-to-Peer workspace system Groove [Groove, 02]. The second category (Communicators) groups all functionality related to explicit communications among team members. Basically this boils down to messaging systems (e-mail). Its fundamental nature is a point-to-point interaction model, where team members are identified only by their name (e-mail address) and not by other means (e.g. by skills, roles or other constructs, as in some advanced workflow systems). The third category (Coordinators) is related to ordering and synchronization of individual activities that make up a whole process. Examples of Coordinator systems include workflow management systems. Finally, the fourth category (Team-Agents,) refers to (semi-)intelligent software components that perform domain-specific functions and thereby help the group dynamics. An example for this category is a meeting scheduler agent. Most systems in this category are not off-the-shelf standard software. Both evaluation models presented above provide guidance to virtual teams on how to evaluate products based on the frameworks. Current systems for virtual teamwork have their strength in one or two categories of Ellis' framework. Most systems on the market today provide features for Keepers and Communicators support or are solely Coordinator systems (e.g. Workflow Management Systems) or are Team-Agents. To the best of our knowledge there is no system integrating at least three of the above categories in one system. In the following section we evaluate current collaborative systems categories for their usage in virtual teams and summarize their shortcomings in respect to the requirement for virtual teamwork.

4.1 Evaluation of Collaborative Systems

Cooperative tasks in virtual teams are increasing, and as a consequence the use of collaborative systems is becoming more pervasive. In recent years it has increasingly become difficult to categorize systems according to the frameworks discussed above, since systems boundaries have become increasingly fuzzy and due to recent requirements for virtual teamwork. Traditional systems in the area of interest to virtual teamwork are groupware, project management (PM) and workflow management systems (WfMS). The mentioned system categories are based on different "metaphors". Groupware systems mainly can be categorized along two lines (metaphors), namely the communications or workspace metaphor.

Communications-oriented groupware supports unstructured work activities using communications as the underlying interaction pattern. One very popular instance of communications-oriented groupware is e-mail. When e-mail is used as the main medium for virtual teams (as in most cases), data and associated information (such as attachments) remain on central mail servers and/or personal inboxes without any context information in which those email communications were used (involved business processes, performed activities, created artifacts as described above). Enterprise groupware systems are generally focused on enterprise-wide messaging and discussion databases and do not support organizational components and structures such as people and their associated roles, groups, task, skills, etc. This leads to "organizationally unaware" systems treating all messages alike (semantically) and without any awareness of underlying business processes, which are essential for efficient collaboration in project teams.

Workspace-oriented groupware, on the other hand, allows team members to upload/download artifacts using files and folders to organize their work. Groupware, as indicated above, usually does not implement an underlying organizational model (i.e. providing information on the structure of a team such as team members and their roles, skills, tasks, and responsibilities). The lack of explicit organizational "structuring" is a disadvantage as well as an advantage at the same time. It is disadvantageous because traditional groupware has no "hooks" for integrating business process information, which is important in order to integrate artifacts, resources, and processes. This will be discussed in more depth in the next section. The advantage of the lack of explicit organizational structure information is the fact that such systems may be used in all organizational settings without much prior configuration efforts on the one hand and secondly this leads to increased personal flexibility, as the proliferation of e-mail systems in teamwork demonstrate.

The second category, which we will briefly investigate in this section are project management systems (PM). As we have stated above virtual teamwork is in most cases organized as project work. Projects have well defined goals and are defined by their begin and end dates as well as by the required resources and their tasks (work breakdown structure). It is interesting to note however, that PM systems traditionally support the work of the project manger as the main (and only) user of the PM system. They do not support dynamic interaction (instantiation) of processes. More recently, project management systems combine with information sharing tools (shared workspaces) to provide a persistent storage for artifacts.

The enactment of the task by team members, as defined by the project manager, is not supported by PM systems. In other words we can conclude that PM systems are not geared towards virtual teamwork but focused more on the planning aspect. They provide "static" snapshots (usually in the form of GANNT charts) of projects and how they "should" be. There is no support for the work activities performed by the virtual team members.

The purpose of workflow management systems is to support the notion of processes within and in some cases between organizations [e.g. Aalst and Kumar, 01]. A business process can be unstructured (ad-hoc), semi-structured, or highly structured (modeled). For example a business process such as "customer order entry" can be modeled using a traditional WfMS. However highly structured processes can only be enacted (instantiated) as they were designed. If an exception occurs, a workflow administrator needs to re-model the process before the execution can continue. This limits the usability of WfMS in a world where constant adaptation to new situations is necessary and where teams are increasingly mobile and distributed. An example of an ad-hoc process is discussion of a project's design review. A semi-structured process consists of groups of activities, which are modeled; however in contrast to a structured (modeled) process it may also consist of activities, which are not pre-defined. A process is semi-structured, when there might be one or more activities between already modeled activities such as assign process, which are not known beforehand and therefore cannot be modeled in advance. Most WfMS distinguish models of a business process (build time) and their enactment (run time). For a comprehensive study of Workflow products and their characteristics see [Aalst, Hee 02]. For a detailed discussion of WfMS-shortcomings, e.g. unclear semantics of Workflow control patterns see [Aalst et al., 03]. The often required modeling of workflows before enactment, as well as their unclear modeling semantics, frequently lead to substantial inflexibility for virtual teams. In (cross-organizational) virtual teams "exceptions are the rule", therefore modeling a process (project) is often not possible for creative, innovative virtual teams of knowledge workers such as in product development or consulting teams, as our small motivating scenario presented above, indicates.

To our knowledge, traditional groupware and workflow management systems do not support the requirements outlined above (see e.g. [Bafoutsou, Mentzsa, 02]. Most groupware systems follow a "workspace" metaphor, which allows users to upload/download artifacts using files and folder to organize their work. When e-mail is used as the main medium for project teams (as in most cases), data and associated information (such as attachments) remain on central mail servers and/or personal inboxes without any context information in which those email communications were used (involved business processes, performed activities, created artifacts as described above). Enterprise groupware systems are generally focused on enterprise-wide messaging and discussion databases and do not support organizational components and structures such as people and their associated roles, groups, task, skills etc. This leads to "organizationally unaware" systems treating all messages alike (semantically) and without any awareness of underlying business processes, which are essential for efficient collaboration in project teams.

To summarize: The requirements for virtual teams cannot simply be met by loosely coupling traditional workflow and groupware systems, which are based on different metaphors and goals. To summarize, we suggest that an integrated Workflow and Groupware system needs to (i) provide organizational constructs (persons, roles, skills, groups, tasks) in order to flexibly model an organizational structure and responsibilities of virtual teams; (ii) provide constructs for modeling generic tasks and associated document-templates or applications in order to enact them for particular team members; (iii) provide the means to graphically model a control flow for business processes at a high level of abstraction (granularity); (iv) allow cross-organizational process enactment with ad-hoc processes (without modelling) and analysis of interaction patterns between team members; and (v) allow integration (and communications-references) of database repositories as an important resource for artifact management.

Our goal for the next section is to distil the above requirements of (cross-organizational) virtual teams into a systems-architecture and present our design goals and to outline architectural considerations of Caramba [Caramba Labs 04; Dustdar, 04].

5 Architectural Issues

In the following section we will provide an overview of architectural issues we are concerned with while designing an activity-based KM system called Caramba [Caramba Labs, 2004]. An in-depth presentation of the architecture or the software itself is beyond the scope and focus of this paper. However, we will discuss relevant issues based on our proposed activity-based KM approach in this section. Software prototype development began in 1997 and it evolved into a commercial product, which has been launched in 2001. Software architectures typically include the description of components, connectors, and configurations [Perry, 92; Shaw, 96]. For this it is important to decompose a system into a well-defined set of components that have clear responsibilities [Parnas, 72]. Since architectures in the KM and WfMS area have to cope with and to integrate with various information systems installed in organizations we decided to strive for a middleware style rather than a classical client-server style. The following descriptions will point out the respective architectural style used in a particular layer or component. The Caramba software architecture [Dustdar, 04] is composed of multiple layers: middleware, client suite, and a persistence store. Objects and services are accessed through the Transparent Access Layer (TAL) from the CarambaSpace platform (middleware). Depending on access mechanisms and the requested services (e.g. via Java client with RMI protocol or via Web browser with http), Caramba provides a unique way to handle requests using a meta model framework to describe content and separating presentation, logic and data. This model permits high flexibility, enables customization, and extensions as well as the adoption of new devices or technologies. The goal of this layer is to offer transparent access to a CarambaSpace. The TAL utilizes various services to transform, describe, manipulate and observe objects. All objects managed through a CarambaSpace are well described using a meta model description framework. Objects can be customized in their structure (e.g. adding columns to tables, adding relations to objects) and their presentation by adopting their meta model description. Any changes are dynamically reflected by client components. Based on the meta model description framework Caramba enables various options to customize data and content and to integrate data from different resources (e.g. corporate databases).

This layer also provides facilities for fine-grained object notification services and the implementation of customized services based on object observers. The middleware does not manage states and persistence of objects. Objects are stored, manipulated, and retrieved via the Persistence Layer (PEL). Caramba leverages and adopts standard Java based technologies (e.g. JDBC, JNDI, HTTP, etc.) to access and integrate data. Figure 3 depicts an overview of the conceptual architecture.

6 Activity-Based KM Component - An Example

The activity-based knowledge management component (ObjectCenter) will be presented in this section. The goal of this component is to provide a mechanism to link activities with artifacts, as discussed in section 3. Based on the metamodel discussed above, Caramba provides a set of organizational objects: Persons, Roles, Groups, Skills, Units, Organization, Tasks, and Documents (i.e. Templates). Utilizing these organizational constructs an administrator is able to model any organizational structure, such as hierarchical, flat, or matrix. Each object class consists of attributes describing the object. The object class Persons contains attributes about the Person such as name, address etc. The object class Roles allows definition of organizational roles such as "Head of IT". The object class Group defines project settings such as "Product Team IT-Solutions". Skills enable definition of required skill sets such as "Certified Java Developer". Units describe permanent departments such as "Marketing". The ObjectCenter provides means (by drag & drop) to link the rows of object classes with each other, as depicted in Figure 4.

It allows users to view relationships between who (organizational constructs) is performing which activities (Tasks) and using what (Documents), as shown in Figure 5. In fact, the ObjectCenter and the MatrixEditor enable project team members to view actual relationships between any of Caramba's object classes in an easy manner. In global project team settings it is of paramount importance to allow "location aware" queries, such as "show all project team members with Java-Skills (Organizational construct) located in Vienna".

In this case the project team member has to narrow down his query by using the Operator contains "Vienna" applied to the Attribute "Location" (MatrixEditor). System administrators may even add organizational object classes (named "Organizational" inside the ObjectCenter) to suit their global project requirements. They may do this by editing the metamodel of Caramba. One example is that, as in global project teams cultural issues are very relevant, the project team would like to add a new organizational object class named "culture portfolio" to the list of managed object classes. This object class stores "cultural variables" and may be linked to Persons or Groups (or any other customized object classes). For example the global project team could agree to store Hofstede's dimensions [Dustdar, Hofstede, 99] such as power distance, individualism, masculinism, uncertainty avoidance, and long-term orientation. The goal in this case is to provide means to describe required cultural variables in order to be successful in a certain project team setting. The ObjectCenter can be utilized in order to link and to store Persons, their Roles, Skills, etc. (all object classes in the Organizational constructs tree) with customized objects (e.g. cultural variables discussed above). This is one example of how the Activity-based KM component can to be expanded and customized for global and "culture-sensitive" project team settings.

In order to fulfil one of the main goals of a reconciled KM and WfMS, Caramba supports modeling of business processes and their enactment by implementing a workflow engine (Process Modeler), utilizing the information presented in the section above (ObjectCenter), using tasks and their associated organizational constructs in directed graphs.

7 Conclusions

This paper outlines the requirements to reconcile knowledge management and workflow management systems in order to provide business process awareness to knowledge artifacts. The Activity-based Knowledge Management approach presented here enables knowledge workers to link knowledge artifacts such as documents (format independent) or database entries to activities performed by human actors. These hyperlinks between artifacts and process activities enacted by people are currently not implemented by traditional Knowledge Management systems. We believe that the Activity-based approach to Knowledge Management provides a solid foundation for reconciliation of Knowledge Management and Workflow Management Systems. In this paper we argue that activities performed by persons need to be linked to knowledge artifacts in order to provide process awareness and -support to KM systems. A software architecture and implementation is presented in order to show the viability of our concepts.

References

[Aalst et al., 03] W.M.P. van der Aalst, A.H.M. Hofstede, B. Kiepusziewski, A.P. Barros, Workflow Patterns, Distributed and Parallel Databases, 14(3), pp. 5-51, 2003.

[Aalst, Hee, 02] W.M.P. van der Aalst, K. Hee, Workflow Management: Models, Methods, and Systems, MIT Press, Cambridge, MA, 2002.

[Aalst, Kumar 01] W.M.P. van der Aalst, A. Kumar, A reference model for team-enabled workflow management systems. Data & Knowledge Engineering 38 (2001), 335-363, 2001.

[Applehans, 98] W. Applehans, A. Globe, G. Lugero, Managing Knowledge: A Practical Approach. New York: Addison-Wesley 1998.

[Bafoutsou, Mentzsa, 02] G. Bafoutsou, G. Mentzsa, Review and functional classification of collaborative systems. International Journal of Information Management 22 (2002), pp. 281-305, Elsevier Science, 2002.

[Bentley et al., 97] R. Bentley, W. Appelt, U. Busbach, E. Hinrichs, D. Kerr, K. Sikkel, J. Trevor, G. Woetzel, Basic support for cooperative work on the World Wide Web, International Journal of Human-Computer Studies, 46, pp. 827-846, 1997.

[Binbasioglu, Karagiannis, 00] M. Binbasioglu, D. Karagiannis, A System for Supporting Organizations in Knowledge-Based Document Preperation. Information Systems, 25/6-7, pp. 453-463, 2000.

[Bussler, 99] C. Bussler, Enterprise-wide Workflow Management. IEEE Concurrency 7 (3), 32-43.

[Caramba Labs, 04] Caramba Labs Software AG, http://www.CarambaLabs.com

[Chen, 01] Q. Chen, M. Hsu, U. Dayal, Peer-to-Peer Collaborative Internet Business Servers. HP-Labs Technical Working Paper HPL-2001-14, 2001.

[Dayal, 01] U. Dayal, M. Hsu, R. Ladin, Business Process Coordination: State of the Art, Trends, and Open Issues. In Proceedings of the 27th VLDB Confererence, Roma, Italy, 2001.

[DeSanctis, Gallupe, 87] G. DeSanctis, R. B. Gallupe, A foundation study of group decision support systems." Management Science, 23(5), pp. 589-609, 1987.

[Doculabs, 03] Special Report on Knowledge Management Products A Doculabs Software Analysis Report 2003. Chicago, IL.

[Drucker, 94] F. Drucker, Post-Capitalist Society. New York: Harper Business, 2004.

[McDonough, 99] E.F. McDonough, K.B. Kahn, A. Griffin, Managing Communication on Global Product Development Teams. IEEE Transactions on Engineering Management 46, 375-386, 1999.

[Doculabs, 03] Special Report on Knowledge Management Products, A Doculabs Software Analysis Report. Chicago, IL, 2003.

[Dustdar, 04] S. Dustdar, Caramba - A Process-Aware Collaboration System Supporting Ad Hoc and Collaborative Processes in Virtual Teams, Distributed and Parallel Databases, 15:1, 45-66, Kluwer Academic Publishers, Special Issue on Teamware Technologies, January 2004

[Dustdar, 02] S. Dustdar, Mobility of Context for project teams. Proceedings of the International Workshop on Mobile Teamwork at the 22nd International Conference on Distributed Computing Systems (ICDCS 2002), July, IEEE Computer Society Press.

[Dustdar, Hofstede 99] S. Dustdar, G. Hofstede, Videoconferencing across cultures - a conceptual framework for floor control issues. Journal of Information Technology, 14, pp. 161-169, 1999.

[Ellis et al., 91] C.A. (Skip) Ellis, S.J. Gibbs, G.L. Rein, Groupware: Some issues and experiences." Communications of the ACM, 34(1), 1991.

[Ellis, 98] Ellis, C.A. (Skip), A Framework and Mathematical Model for Collaboration Technology, in. Coordination Technology for Collaborative Applications - Organizations, Processes, and Agents (Conen and Neumann, Eds.), Springer Verlag, pp.121-144, 1998.

[Groove 02] Groove Networks (2002), http://www.groove.net

[Johansen, 88] R. Johansen, Groupware. Computer-support for business teams. The Free Press. New York, 1988.

[Karagiannis, 95] D. Karagiannis, L. Marinos, Integrating Engineering Applications via Loosley Coupled Techniques: A Knowledge-Based Approach, Expert Systems With Applications, 8, 2, pp. 303-319, 1995.

[Nonaka, 98] I. Nonaka, H. Takeuchi, Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. Oxford: Oxford University Press, 1998

[Parnas, 72] D.L. Parnas, On the criteria to be used in decomposing systems into modules, Communications of the ACM, 15(12), 1053-1058, 1972.

[Perry, 92] D.E. Perry, A.L. Wolf, Foundations for the study of software architecture. ACM SIGSOFT Software Engineering Notes, 17 (4): 40-52, 1992.

[Shaw, 96] M. Shaw, D. Garlan, Software architectures, perspectives on an emerging discipline. Englewood Cliffs, NJ: Prentice-Hall, 1996.

[WfMC, 95] Workflow Management Coalition - Workflow Management Specification: http://www.wfmc.org/standards/docs/tc003v11.pdf

[Winograd, 86] T. Winograd, F. Flores, Understanding Computers and Cognition. Norwood, NJ: Ablex, 1986.

[Zeng, 01] L. Zeng, B. Benatallah A.H.H. Ngu, On demand business-to-business integration. In Proceedings CoopIS 2001, 403-714, Computer Science Lecture Notes, Heidelberg: Springer.