یک مدل مرجع تیم خود فعالی برای سیستم های مدیریت جریان کار

Today's workflow systems assume that each work item is executed by a single worker. From the viewpoint of the system, a worker with the proper qualifications selects a work item, executes the associated work, and reports the result. There is usually no support for teams, i.e., groups of people collaborating by jointly executing work items (e.g., the program committee of a conference, the management team of a company, a working group, and the board of directors). In this paper, we propose the addition of a team concept to today's workflow management systems. Clearly, this involves a marriage of workflow and groupware technology. To shed light on the introduction of teams, we extend the traditional organizational meta model with teams and propose a team-enabled workflow reference model. For this reference model and to express constraints with respect to the distribution of work to teams, we use object constraint language (OCL).

Most publications on workflow management focus on the process (or control-flow) perspective, neglecting the representation of organizational structures and the distribution of work [26], as they relate to a workflow management system. Thus, there is a lack of consensus on the type of organizational structures to be supported. For example, consider how the Staffware system supports the concept of a so-called work queue. Both workers and work items are assigned to work queues. A worker may be linked to multiple work queues and a work queue may be visible to multiple workers, in which case it is called a group queue. Each worker also has a personal queue. Personal work queues can be used to support a push mechanism, i.e., work items are assigned to specific workers. On the other hand, group queues can be used to support a pull mechanism, i.e., multiple workers can view a shared pile of work items and select specific work items. Other workflow systems use other paradigms: IBM's MQ Series Workflow [20] supports both organizations and roles instead of one queue mechanism. Another example is the workflow management system COSA [8], which supports arbitrary organizational dimensions (e.g., groups, roles, authorization, etc.) and merges all relevant work items into one personalized list. The fact that the available systems are quite different with respect to their handling of organizational issues is demonstrated by the varying support for delegation: Systems either have no support for delegation or offer rather specific functionality. Another aspect in which systems are quite different is the distinction between authorization and work distribution. In many systems authorization (the ability to execute a work item) and distribution (assigning tasks to workers) coincide. (Recall the work queue paradigm in Staffware.) Other systems such as FLOWer by Pallas Athena allow for a clear separation of authorization and work distribution. This lack of consensus is also illustrated by the absence of any proposals from the Workflow Management Coalition (WfMC, [24]) concerning the representation of organizational structures and the distribution of work. Although there is a working group on resource modeling (WfMC/WG9), no standards have been proposed. The absence of consensus is an important problem and has been addressed recently by some authors [26] and [27]. The scope of this paper is limited to the representation of organizational structures and the distribution of work in the context of team support. To the best of our knowledge, all commercial workflow products assume a functional relation (in the mathematical sense) between (executed) work items and workers, i.e., from the viewpoint of the workflow management system each work item is executed by a single worker. A worker selects a work item, executes the corresponding actions, and reports the result. It is not possible to model or to support the fact that a group of people, i.e., a team, executes a work item. Note that current workflow technology does not prevent the use of teams: Each step in the process can be executed by a team. However, only one team member can interact with the workflow management system with respect to the selection and completion of the work item. Thus, current workflow technology is not cognizant of teams. This is a major problem since teams are very relevant when executing workflow processes. Consider for example the selection committee of a contest, the management team of a subdivision, the steering committee of an IT project, and the board of directors of a car manufacturer. In addition to providing explicit support for modeling teams, it is also important to recognize that individuals typically perform different roles within different teams. For example, a full professor can be the secretary of the selection committee for a new dean, and the head of the selection committee for tenure track positions. These examples show that modeling of teams should be supported by the future generation of workflow products. In this paper, we explore concepts and technologies for making workflow management systems team enabled. Groupware technology ranging from message-based systems such as Lotus Notes to group decision support systems such as GroupSystems offer support for people working in teams. However, these systems are not equipped to design and enact workflow processes. Based on this observation a marriage between groupware technology and workflow technology seems to be an obvious choice for developing team-enabled workflow solutions. Systems such as Lotus Domino Workflow [28] provide such a marriage between groupware and workflow technologies. Unfortunately, these systems only partially support a team working on a work item. For example, in Lotus Domino Workflow, for each work item one needs to appoint a so-called activity owner who is the only person who can decide whether an activity is completed or not, i.e., a single person serves as the interface between the workflow engine and the team. Clearly such a solution is not satisfactory. As a starting point for investigating team-enabled workflow management systems, we take a basic organizational meta model. This model serves as a reference model for the basic functionality offered by today's workflow management systems. This model is a simplification of the meta models of existing workflow management systems and the meta models proposed in literature (cf. [6], [23], [26] and [27]). Next, we focus on the addition of teams. Therefore, we take the “greatest common divisor” of existing organizational meta models and add the concept of teams. We use UML class diagrams to represent the basic and extended meta model. Moreover, we clearly define the constraints in terms of object constraint language (OCL). OCL [30], [31] and [39] is an integral part of the UML (version 1.1 and upwards, [16] and [32]). OCL is a powerful language to describe constraints at the meta level. For example, it is possible to specify that a worker not having the required role cannot execute a work item. OCL can also be used to describe constraints specific for the organization or the workflow process, e.g., “The department head should either approve or pre-check each purchase.” and “Insurance claims involving more than $5000 should not be handled by an office clerk but by a trained expert.” Examples will show that many constraints at the meta, organizational, and process level can be expressed quite easily using OCL. Based on the team-enabled reference model we explore various aspects of work distribution in the presence of teams. For example, teams can vote on the outcome of a successfully completed work item. In fact, the completion of a work item executed by a team could be subject to discussion, e.g., there can be a conflict: Some team members may dispute the completion of work item reported to be finished by other team members. In the traditional setting, one worker indicates the completion of a work item. This is not necessarily the case for teams. Other issues related to the operation of a team are: working at same time/different time, same place/different places, scheduled/ad hoc meetings, etc. We will classify and structure these issues in more detail later and discuss possible realizations of the team concept. Clearly, team-enabled workflow management systems should borrow concepts or components of existing groupware technology. Therefore, we propose a marriage between workflow and groupware technologies, and give an architecture for it. The remainder of this paper is organized as follows. First we introduce the basic workflow concepts, a simple organizational meta model, and OCL as a language to express workflow constraints. In Section 3, we introduce the team concept and extend the organizational meta model to incorporate support for teams. We also provide generic (i.e., meta level) and specific (i.e., organizational/process level) constraints. In Section 4, we explore team allocation mechanisms. Then we discuss possible realizations using groupware technology. Section 6 concludes this paper.

This paper started with the observation that team support is missing in contemporary workflow management systems. Yet, there are numerous, real-world applications where tasks are performed by teams. Therefore, effective support for team activities in workflow systems is essential. Secondly, there is a great need for integrating groupware support within a workflow system. Unfortunately, there is hardly any literature on the “marriage” between team-enabled systems developed in the CSCW domain and workflow- enabled systems developed by workflow vendors. Although there is a working group on resource modeling (WG9), the Workflow Management Coalition (WfMC) did not consider activities executed by teams. Both researchers and software developers in the CSCW domain have developed a wide range of group support systems. These systems are team-enabled but do not explicitly model the business processes and organizational structures. Therefore, these systems are unaware of the workflow processes at hand and do not support the enactment of these processes. It should be noted that systems like Lotus Domino Workflow (Lotus/IBM, [28]) allow for teams. However, these systems use a so-called activity owner as a mediator between the workflow management system and the team members. The team member can share information regarding the activity being executed. However, team positions within teams, requirements on the size and structure of the team, and termination conditions involving voting are not taken into account. The activity owner simply reports the completing of the task. In this paper, we first proposed a reference model for making workflow management systems team-enabled and then developed an architecture for integrating workflow and groupware technologies. The reference model has been expressed in terms of a UML class diagram, which we named the Team- enabled workflow reference model ( Fig. 4). This reference model is based on a core model involving standard concepts such as case, task, work item, activity, role, qualification, position, competence and resource, and has been further extended with team-specific concepts such as team, team type, team position and contribution. One of the interesting features of this model is the presence of detailed OCL constraints. OCL allows for the specification of generic (i.e., at the meta level) and specific (i.e., at the organizational/process level) constraints. We illustrated how this reference model can be applied to the case of the tenure evaluation process, an example application that requires considerable amount of team activity, and one that many of our readers can relate to. Finally, an architecture for integrating groupware support into a workflow system by means of an API was discussed. In the Eindhoven Digital Laboratory for Business Processes [11], we currently use the workflow management system Staffware [37] and the group support system GroupSystems [18]. Both systems are used in several courses given at Eindhoven University of Technology and have been used to build research prototypes. To demonstrate the conceptual ideas in this paper, we plan to integrate Staffware and GroupSystems using the team-enabled workflow reference model and the architecture presented in this paper.