Emergent Workflow: Planning and Performance of ... - CiteSeerX

Emergent Workflow: Planning and Performance of Process Instances Håvard D. Jørgensen, Steinar Carlsen SINTEF Telecom and Informatics PO Box. 124, Blindern, N-0314 OSLO , Norway {hdj,sca}@sintef.no

Abstract. Emergent workflows constitute a particular category of adaptive workflows. An emergent workflow is described by a partially structured process model that emerges from the workflow itself; i.e. process definition and enactment are intertwined. The dynamic and ad-hoc work that is becoming increasingly important in today’s knowledge intensive organisations has an emergent nature. We describe a prototype cooperation support environment for such work currently being developed. This WORKWARE system includes task management and interactive workflow enactment with contextual awareness support, available through a simple web browser interface. The architecture is highly tailorable, allowing users to add and interconnect new tools and information types. Our workflow definition language is simple, yet expressive, and it narrows the semantic gap between the planning (definition) of the workflow and the performance of the work, enabling ordinary end users to do both. The user-oriented workflow modelling language has its focus on process instances, not on process types. It targets in situ articulation work and temporarily circumvents complexity stemming from the need to consider future instances of "similar" processes. Since the user-oriented process instance models are mutable and possibly incomplete, the environment is extended to include interactive workflow enactment, where the enactment service and users cooperate in managing the workflow.

1  Introduction We view workflow as active support for planning, performance and coordination of work based on a (more or less complete) explicit process model. Traditional approaches [43, 32, 34] generally separate process definition from process enactment. These activities are supported by different tool components, and performed by different actors or roles. The traditional separation between dynamic/adaptive and static/production workflow refers to whether changes to the definition of a workflow type can affect running workflow instances. At the same time, researchers have suggested different approaches. Ellis, et al. [19] point to the need for the specification and execution modules of workflow systems to be tightly interwoven, Haake and Wang [28] to the need for supporting processes with emerging structure. Design and software engineering are examples of such work processes [33].

Our aim is to support knowledge work, projects performed by actors who largely plan their own work. This paper makes the case for emergent workflow support, a bottom-up approach where the focus is on planning and performing work process instances. Process definition, or planning, is viewed as an activity that is also part of the process it defines. Process model templates, fragments, and patterns are resources for adaptation rather than prescriptions of action. AIS1 is an ongoing project in which we address workflow as one component in a wider intranet cooperation setting. The project builds and experiments with prototypes to advice future implementation and deployment. The structure of this paper is as follows: First, we describe the background of our work and the need for emergent workflow solutions. We then detail our approach to this field, presenting the conceptual design of the WORKWARE system, the workflow modelling language, and principles for interactive enactment support which integrate contextual awareness services to support flexible coordination. Later we contrast AIS WORKWARE to other research prototypes that support adaptive workflow. This discussion points to some interesting areas for further work, which is outlined in the final section alongside our conclusions.

2  The Need for Emergent Workflow Our view of workflow as active support for planning, performance, and coordination of work based on a (more or less complete) explicit process model, differs slightly from the traditional definition given by the Workflow Management Coalition (WfMC) [43]. WfMC define workflow as "the automation of a business process, in whole or part, during which documents information or tasks are passed from one participant to another for action according to a set of procedural rules". We broaden the scope by including support for more forms of coordination, less structured process models, and by integrating process definition, or planning, as part of the process. This section explores the reasons for this slight change of perspectives. 2.1 Change and Uncertainty Ability to change is an important competitive factor in most segments of industry. Management of change as a main challenge for cooperative information systems, has been highlighted [15]. Customers’ demands and requirements change frequently and vary from case to case, causing a need for solutions tailored to each particular situation. Consequently, competitors and partners change. Advances in technology continuously alter what is feasible as well as customer expectations. Vital information has multiple interpretations, blurring the picture even more. This has created a focus on knowledge management and agile enterprises [18], yet to be supported adequately 1

AIS is an acronym (in Norwegian) for Advanced Intranet Collaboration. The project is sponsored by the Norwegian Research Council and the project partners are Det Norske Veritas, NCR Metis, Saga Petroleum, FAFO (Institute of Applied Social Science) and SINTEF Telecom and Informatics.

by workflow management theory and applications. Thus, we need solutions that treat change as the rule of the game, not as exceptions that should be handled in a manner similar to the way they are handled in programming languages. An important reason for utilising emergent workflow solutions rather than other coordination tools to support project work, is traceability. Capturing both the history of the process definition and the enactment in an extended audit trail, gives unique material for later reasoning about the process, increasing the probability of informed decision making and learning from experience. Externalising what you have done in a process model is also important for the accountability of individuals and organisations [4], a property that is becoming increasingly important with the increased rate of change. 2.2 Empowerment As more and more routine tasks have been automated, the remaining challenge of work support technologies is knowledge work; work relying heavily on the intangible skills and tacit knowledge of individuals and groups. This challenge has been answered in organisational practice and theory by decentralised decision-making and empowerment. Empowerment with respect to workflow process models and their encoded behaviour implies an ability to browse available organisational actions and to create one’s own libraries of actions to “invoke” when they are found suitable [11], resembling “advisory” process models [1]. This is also related to layered policies in business process definitions, as in OBLIGATIONS [7]. Empowerment with respect to the work support infrastructure demands support for end-user customisation of system features, enabling them to create personalised workspaces. 2.3 Advances in Use of Technology Recent advances in technological infrastructure, like the Internet, growing maturity and use of standards for system interoperability, and increased availability and deployment of groupware components, have only to a limited degree influenced the design of workflow management systems. The scope of workflow management is a central issue here. For instance, workflow tools should focus more on supporting flow of work, not flow of “documents” [1]. Information management and sharing, access control, communication, rich conversation support etc. could be left to external tools especially designed for those tasks.

3  The Challenge of Emergent Workflow The usefulness of workflow support for dynamic, ad-hoc knowledge work processes needs to be investigated further, though some basic insights can be highlighted. A typical project is put together to solve a new, unique task, and uses people from

different organisational units and disciplines, who may work at different times and locations. In such a situation, support infrastructures based on process models can serve a number of needs. They support coordination across time and distance, through the availability of updated process models showing current plan and progress. As Miers [34] states, to support adhocracies, workflow should allow for coordination through mutual adjustment in creating, adapting, combining, and linking process model fragments. To accomplish this, the process models must be the property of the project team, who must actively use the models to articulate and coordinate work. Thus, solutions that focus on the integrated planning, articulation, and performance of work are needed. This requires that we allow dynamic modifications to the models, and that we support also the enactment of incomplete and inconsistent models, if such a model is the best view the users are able or willing to reflect at a given point in time. Thus, in order to support knowledge intensive project work, we have identified three cornerstones of our emergent workflow approach: • User-oriented process models, • Integrated support for planning, coordination and performance of work, • Process knowledge management. All these areas needs further research. The following subsections overview challenging research topics within each area. 3.1 User-Oriented Process Modelling Languages Workflow solutions should be useful for autonomous workgroups and features provided should be relevant for “normal” end-users, not only for designated process experts. This requires increased process model comprehensibility [13]; languages that map well to the conceptual world of those performing the work. Simplicity with regard to the predefined set of modelling concepts, extensibility, allowing users to specialise and introduce new concepts, and user-defined views that show only the aspects of the model relevant for the task at hand, are ways of increasing model comprehensibility. Recognising that a model is a conceptualisation of someone's perception of reality at a moment in time, syntactic and semantic rules should not prevent the most accurate capture of a process that the users provide. In particular, there is a need for more user-oriented modelling languages suitable for performance and management of process instances. Most user-oriented languages target abstract process type specifications, while models generally used for workflow enactment, like Petri nets [20], are often more suited for manipulation by a computer system than by humans. 3.2 Integrated support At the same time, process models need to be interpreted by a workflow enactment service to be actively supported. This calls for formal models, preferably complete and consistent. We need workflow tools that enable this trade-off between useroriented and software-oriented models to be made explicit, to be made the subject of decision by the user organisation. Thus there is an identified need for providing an

integrated environment with tools supporting the modelling of abstract business process types, like the "Sales" process, as well as concrete, unique process instances. In addition to process modelling, task management, and access to external tools and applications, awareness of the actions of others needs to be supported. Live process models provide an excellent opportunity for creating environmental feedback [25], propagating event notifications through the process structures [36, 37], so that the users receive information that is relevant in their current context, i.e. alongside the other information about the task that this event affects. Tailorability, allowing organisations, groups, and individuals to adapt the system to their special needs and preferences [5], should be a basic property of emergent workflow solutions, in order to support empowerment, local variants, and changing conditions. All parts of the integrated support environment should be tailorable, including the modelling languages, the enactment, awareness, and worklist components. 3.3 Process Knowledge Management When planning work processes by creating or adapting process models as part of the ongoing articulation work, people create knowledge, of which some is externalised in the situated process models. This knowledge can be reused, harvested, combined and linked with existing knowledge. We may say that process models constitute an arena for knowledge creation [35]. Knowledge management can be defined as the collection of processes necessary for innovation, dissemination, and exploitation of knowledge in a cooperating ensemble where knowledge seekers are linked to knowledge sources and a shared knowledge base is cultivated. In emergent workflow a knowledge management perspective is explicitly addressed through user-oriented process models, improving the users’ ability to externalise their knowledge. Support for incomplete and inconsistent models reflects the fact that the participants always will have tacit knowledge that is not externalised in the models, so the models will only reflect a portion of their knowledge. Process templates are regarded as reusable knowledge resources. Constructive composition [30] of models from parts, i.e. knowledge combination, is enhanced by supporting model templates as a basis for model composition. Templates include personal, group, and organisational fragments [34], process examples and patterns, in addition to complete models of some routine processes. We still need new modelling language concepts and software services that better support composition of process models from parts. Knowledge harvesting refers to gaining experience from past models to update template repositories. Theoretical and experimental work is needed to develop a methodology for selecting processes and fragments suitable for reuse. Harvesting can be supported by integrated conversation tools to further uncover experiences from each process. Simulation techniques and role play may be utilised in training based on process models of real world cases. In short, there are a number of issues that arise from looking at process modelling and workflow with a knowledge management perspective. Insights from enterprise modelling [8], process handbooks [31], CSCW, organisational learning, and

knowledge management need to be combined and contrasted. A more detailed discussion of process knowledge management is beyond the scope of this paper.

4  The AIS Workware Approach to Emergent Workflow This section outlines our solution to the challenge of supporting emergent workflows. First, we give a brief introduction to our reference model for process modelling, spanning from generic enterprise processes to actual work process instances, integrated to support innovation, reuse, and management of process knowledge. We then present the AIS WORKWARE process modelling language, which primarily targets the lower layers of this framework. The modelling concepts map directly to entities in the user interface of the WORKWARE system. The conceptual design of this system is presented and related to the models. 4.1 Workflow and Process Modelling To integrate process modelling at different levels, from enterprise modelling of generic business process types to emergent workflow perspectives at the instance level, the AIS project has developed a process modelling reference model (figure 1). The reference model gives an overview of a holistic approach to process orientation, modelling, and knowledge management. Process Logic Description (Properties)

Activity Specification (Parameters)

Process Knowledge Management

Work Management (Attributes)

Work Performance (Multiple values)

Fig. 1. Process modelling reference model [12].

It identifies 4 layers of process knowledge representation, from general process logic to actual, situated work performance. Process modelling (or articulation) occurs at several levels concurrently, and may start at any level. WORKWARE primarily targets the lower two levels of the reference model, performance and management of work. The more abstract levels of process logic and activity description may provide

constraints and useful resources (in the form of process templates) to the planning and performance of an emergent workflow. Level 1 – Process Logic Description. At this level, we identify the constituent activities of generic, repetitive processes and the logical dependencies between these activities. A process model at this level should be transferable across time and space to a mixture of execution environments. Common examples of process logic are conceptual value chains and normative descriptions of “ways of working” for particular organisations. Level 2 – Activities Specification. Here process models are expanded and elaborated to sufficiently cover realisation. Elaboration includes concretisation, decomposition, and specialisation. Abstract resources required for actual performance are described. Thus, more reasons for dependencies between the subactivities of a plan are uncovered. Level 3 – Work Management. Here more detailed decisions are taken regarding the performance of work in the actual work environment with its organisational, information, and tool resources. The scope is narrowed down to an actual process instance. Concrete resources increasingly are intertwined in the model, leading to the introduction of more dependencies. Management of activities may be said to consist of detail planning, coordination and preparation for resource allocation. Level 4 – Work Performance. This lowest level of our reference model covers the actual execution of tasks according to the determined granularity of work breakdown. When a group or a person performs the task, whether to supply a further decomposition may be left to their discretion. Alternative candidate decompositions can be provided as advisory resources. At this level resources are utilised or consumed, in an exclusive or shared manner. Process Knowledge Management. Process knowledge management is active at all levels of the reference model. In particular, models of past process instances typically situated at the lower levels - may be subject to a harvesting process in order to update templates available at the higher levels. These updated templates then become resources for situated planning in the future. 4.2 Workflow Modelling Conventional, well-known process modelling languages have a suitable graphical depiction supporting decomposition, and a procedural conceptualisation. In AIS we want to provide continuity in conceptual modelling methods and techniques. At the same time, we want to simplify the number of modelling concepts and make the mapping between modelling concepts and user interface entities straightforward, to bridge the semantic gap between process definition and enactment, creating a modelling language suitable for ordinary end users.

The WORKWARE modelling language is inspired by the Action Port Model (APM) [9, 10]. APM is based on a conceptual modelling framework for information systems development, PPM [24, 44]. PPM process models are extended data flow diagrams [21], taking a traditional transformational (i.e. IPO – Input Process Output) view as a starting point, but adding interface descriptions (ports). Avoiding unnecessary classification, the most basic concept in AIS WORKWARE is the work item, which intentionally, and dependent on its lifecycle, may correspond to both a process, an activity and a task in contemporary workflow systems. For an atomic work item, the default interpretation is that the responsible actors may or may not choose to supply a decomposition. In the life-cycle of a work item, a composition might be supplied – corresponding to responsible actors planning their own work; a composition might be changed or removed – corresponding to replanning; or a work item may simply be reported as performed, ignoring an available plan (decomposition). Composite work items are either work item collections, which only have an unordered list of components, or workflows where some of the component work items are interconnected. The interconnection network of a workflow is made up of two types of objects: • Flows, representing dependencies between work-items, the assumed flow of work. • Decision connectors, either joining or splitting a set of flows. We have three types of connectors, OR, XOR, and AND. The type refers to the logical relationship between multiple input (for joins) or output (fork) flows. The default connector is OR, which represent an unspecified relationship, either detailed in another submodel or left to the user to resolve. These three concepts, workitems, flows, and decisions, constitute what is needed for enactment of workflows, which is the subject of a following section. A graphical notation for the workflow language is depicted below.



1DPH )ORZ 5HVRXUFHV

25

;25

$1'

:RUN,WHP

'HFLVLRQFRQQHFWRUV%RWK-RLQDQG)RUN

ZLWKUHVRXUFHVLJQDWXUHLQSXWDQG

YDULDQWVH[LVWIRUDOOW\SHV

RXWSXWGHFLVLRQFRQQHFWRUV

Fig. 2. The WORKWARE process modelling language.

Each workitem has one input and one output decision connector, corresponding to starting and completing work on the item. Work items are performed by their actors utilising other resources; typically tools and information objects. A taxonomy of work item resources, is depicted in figure 3. The actors, tools, information etc. required for a workitem constitute the resource signature of the workitem. The external interface of a workitem consists of the input and output decision connectors and the resource signature. At runtime, resources may be allocated dynamically through integrated resource brokers.

In general, we treat information as a shared resource in our process models. Flows may include information objects, but primarily reflect flow of work [1]. Coordinating access to information resources is the duty of a shared workspace application working in cooperation with WORKWARE. This solution helps us to simplify the process models by limiting superfluous information flow. $30 5HVRXUFH

5HVRXUFH7D[RQRP\

Organizational Actor

2EMHFW

7RRO

$FWRU

Manual Tool

Agent

Software Tool

Material Object

Invoked Software Tool

Software Agent

'HWDLOHGUHVRXUFHSURSHUWLHV role

concrete

Invoked vs. available

software resource

composite resource

Information Object

Active Information Object

Pluggable Action Definition

Fig. 3. WORKWARE resource taxonomy [10].

4.3 Conceptual Design of the Workware Tool Work items are available from a worklist tool, as shown in the example screenshot in figure 4. A worklist may present all current work items belonging to a project (like AIS and External in the example), or only work items currently allocated to a particular person (like Ongoing work and New work). Each work item is accessed through its individual worktop, with links to relevant resources (tools, people, information etc.). An example worktop is shown in figure 5. It is configured according to the particular task and to the preferences of the user. Through this user interface we give access to three types of work item services: • Planning services, which conform to articulation work [3, 38, 40], including process modelling. • Performance services, which provide access to the necessary tools and information objects for performing work. • Coordination services, which correspond to changing the work item state, i.e. progressing work. We also provide access to communication channels (external tools) for more ad-hoc coordination.

Fig. 4. WORKWARE worklist for the user Haavard, tailored according to his preferences.

Fig. 5. WORKWARE worktop example.

Work item services correspond to commands the user can invoke on the work item. Services are configured through an available system service; users may add, remove, or compose new services. We provide some general services as part of every configuration, in addition we support configuration templates for work item categories, and let users maintain their personal configurations.

4.4 Interactive Workflow Enactment Much research into adaptive workflow enactment [20, 14] focus on creating better algorithms for exception handling, i.e. following the traditional mechanistic view [11] of the enactment engine as a Turing machine. We also find it fruitful to view the enactment engine as an interaction machine [42], where the software system and its users cooperate to bring the workflow forward in the situations that arise. This poses interesting challenges concerning how the software system best can involve its users in the problem solving and decision making process. The AIS enactment software is based on a state transition model for work items, external interfaces of work items, and the interpretation of coordination events brought forward by the coordination services. WORKWARE process models represent planned and ongoing partially connected instances of work items. At any time, the users may alter the model of a workflow, changing future interpretation of events by the enactment software. Thus, the models are considered resources for situated action [40, 7, 4]; they are socially constructed artefacts forming the basis for performing work. Activation. Flow of work is propagated through activating flows and connectors. Activation may be triggered by users invoking coordination services, or internally by the enactment component interpreting effects of other events. Each flow then represents one instance of a past or anticipated future signal. This view allows us to ignore loops and repetition in the WORKWARE models. Every repetition involves a unique set of workitem, flow, and connector instances, i.e. we linearise the loops. This simple enactment model of flows and connectors makes it easy to graphically depict the current status of a workflow, by marking all the elements that have been activated (figure 6).

:+DQGOH:RUNZDUH&KDQJH5HTXHVWV,PSURYHGHOHJDWLRQVXSSRUW Reject proposal Evaluate proposal

w2 Implement GUI Changes

w1  Prepare Changes

w3

&

w4 Implement Server Changes

 Accept new version

&

w6

+

w5

Fig. 6. WORKWARE model showing current status (activated and started elements have a red, thick border).

User Involvement and Contextual Awareness. The usefulness of the enactment component increases with the degree of specificity of the workflow models. When flows connect workitems, the enactment engine reasons about work item state changes triggered by the users, and may automatically activate flows and make new workitems ready. If a decomposition model contains no flows, just a work item collection, no active support is given, the users have full control of the process, and they have to do all the work of updating work item statuses themselves. When a workflow is loosely specified, the actors cooperating on the work items are still supported by components of the WORKWARE system. Most notably, we supply shared worklists [29] that allow the users to communicate and share information about their work in the context of particular work items. Another essential component is the awareness monitor, which provide information about the actions of others to each user within the context of his or her work items. The awareness monitor will utilise the workflow models to provide environmental feedback [25], propagating event notifications through the workflow structures. Presenting awareness information within the context of a worktop for a workitem, lightens the cognitive burden of interpreting this information. Also, grouping the information to the workitems reduces the information overload problem often associated with asynchronous awareness mechanisms [16]. The awareness monitor may also trigger opportunistic involvement [17] in starting work on a work item although not all of its required inputs are ready. When you are provided with information about the progress of the workflow, you are better equipped to decide when it is time for your work to begin. The awareness service will also support the need for coordination that arises when two work items that depend on each other (have a flow between them) are both active due to opportunistic involvement. This constitutes a more general interpretation of the flow concept, not only as a signal controlling the sequence of tasks, but as a dependency that needs to be coordinated. The awareness monitor thus supports coordination through mutual adjustment. Decisions. The decision connectors play an important role in the interactive enactment framework. A decision connector represents an issue to resolve regarding the flow of work. Some decisions may be straightforward to predefine during the early planning of a process, while others need to be made by human actors during work performance. Some connectors are easily interpreted by the enactment software, like an AND split or an XOR join, others may not even be identified before they emerge as critical issues. The default connector type is OR, which doesn’t say much about the relationship between multiple inputs or outputs. Altering the type to AND or XOR adds constraints to the workflow, but needn’t make the interpretation of what to do much simpler for the enactment software. What the software does know, however, is that it needs to act when a connector is ready to be activated. If it is not able to determine which output(s) to activate, it must ask a user what to do next. We call this the fallback mechanism. The position of a decision connector influences the interpretation of the model. For instance, it determines which user to assign decision making to. Input and output decisions are left to the actor responsible for the workitem, while loose connectors are decisions to be made by the actors responsible for the parent workitem. In the model

in figure 7a, the decision whether to prepare or reject changes is to be made locally in w1, while in figure 7b that decision is part of the parent process.

Reject proposal Evaluate proposal

w2

Reject proposal

w1 

w1 Prepare Changes

w3

w2

Evaluate proposal



w3

&

D /RFDOGHFLVLRQLQZ

Prepare Changes

&

E +LJKHUOHYHOGHFLVLRQ

Fig. 7. Modelling decision-making authority and responsibility.

A connector that is not straightforward to interpret for the enactment engine, is converted into a decision making workitem when it is time to decide, and placed in the worklist of the actor(s) responsible for its parent. In all, this constitutes a simple and powerful mechanism for assigning responsibility and authority of decision making during the integrated planning and performance of a work process.

5  Evaluation and Discussion The AIS project builds prototypes, and we have not yet been able to do formal evaluations of our approach in real world settings. In the absence of detailed empirical evidence, we will contrast and compare our approach to other research initiatives targeting flexible, adaptive, and collaborative workflow. The project is controlled by the user companies and they have taken active part in the requirements analysis and overall design of WORKWARE. Their background includes enterprise modelling, consultant work, and intra-networking a global enterprise. NCR Metis has helped to implement the WORKWARE modelling language in their modelling tool, and interface it with the worklist tool. 5.1 User-Oriented Workflow Languages Heinl et.al [26] claim that ad-hoc modelling is not feasible, that although ad-hoc changes will occur, they cannot be handled by ordinary end users updating the models in an uncontrolled way. This claim is based on the view that workflow type modelling is difficult and time consuming, and requires expert knowledge not possessed by an average user. The AIS WORKWARE approach circumvents these problems, by not hardwiring process definition to the type level. Our basic objective is to support the planning, articulation, coordination and performance of unique workitem instances,

so we support the modelling of these instances as well as the definition of types. In doing so, we remove the great complexity that stems from having to look at all present and future instances of a process type whenever you want to modify a model. By not enforcing flow dependencies to be included in the models, our solution on one extreme corresponds simply to shared task management [29], which is feasible for ordinary end users. The optional added complexity of representing flow dependencies, is not all that different from the project plans that ordinary project managers and participants write today. Our opinion, thus, is that the claimed impossibility of ad-hoc modelling stems from a particular workflow paradigm that does not separate process modelling from process type definition, it is not a fundamental problem of all process support technologies. WORKWARE’s potential for high pragmatic quality process models [13] is ensured through a preferred procedural conceptualisation of processes in a semantically explicit graphical language. By limiting classification of concepts, and removing information flows, we obtain a simple language. The direct mapping between work items in process models and the worklist tool, bridges the semantic gap between definition and enactment. In the CHIPS system [28], a cooperative hypermedia infrastructure is extended with process support, to integrate collaboration, communication, and coordination aspects of business processes, including processes with emerging structure. Their modelling language includes five link (flow) types, one for workflow (’precedes’), and four for coordinating information sharing and flow (’share’, ’copy’, ’transfer’, and ’integrate’). CHIPS models are richer, but easily become more cluttered than WORKWARE models. By leaving information management to other applications, we direct focus at the flow of work, and the decisions that control it. CHIPS also provides five "task node types", distinguishing atomic nodes from composite, automated from manual, and highlighting iteration. The existence of a decomposition is also shown in WORKWARE models. We consider the separation between atomic and composite work items to reflect the current stage in the work item life cycle only, it is not an inherent property of the work item, and should not be determining "process type". In our reference model, iteration is most relevant for higher-level process type definition. A WORKWARE model, representing only instances, reflects iterations by showing several instances of work items or flows. We can do without special loop and repetition symbols at this level. This solution highlights each iteration as a separate work item, minimising the gap between the model and what is represented in the worklists. CHIPS models also contain pre- and post-conditions for each task, and transition conditions for links, enabling representation of AND and XOR join and forks. WORKWARE, through the decision concept, highlights the importance and possibility of human intervention, and link the location of a decision connector to responsibility and authority of decision making, increasing the expressiveness of the language. TEAMWARE FLOW, like WORKWARE, also includes user-oriented graphical process models as a design goal [41], but does not include WORKWARE’s rich perspective on workflow resources. In TEAMWARE FLOW, collaborative planning of work is approached through divide and conquer with individuals taking responsibility of “their own” process model fragments; the focus is not on emergent processes per se. Like WORKWARE, hierarchical decomposition is supported, but the focus is more on complete workflow models; not on models consisting of more or less articulated

model fragments in unison, where awareness support and fallback is included as enactment mechanisms. Recently, adaptive workflow approaches based on constraint reasoning have been proposed [22, 17]. These approaches focus on carving out spaces of possible solution alternatives to process enactment through the explicit representation of constraints between various tasks, roles etc. Thus, problems with “over-serialisation” in traditional process models are avoided, but these approaches may lead to incomprehensible models since they by nature are like statements in a programming language. A graphic depiction is difficult since it would correspond to a visualisation of several possible solutions to the set of constraint equations constituting the process model. Over-serialisation should not be a major problem for WORKWARE, which supports coordination of loose work item collections as well as workflows, and does not interpret flows rigidly. The shared worklists and awareness support should foster concurrency when appropriate. WORKWARE is based on the premise that the process models only reflect a portion of someone's perceived reality. The more details you add to process models, the more you focus intended future actions. In this respect our approach is similar to constraint-based techniques. In other systems, adding details is viewed as generalising the model [45], as a way of increasing flexibility. This is the result of viewing process models as a reasonably complete set of alternative paths. 5.2 Interactive Workflow Enactment A number of other tools provide better support for workflow enactment than the current WORKWARE prototype. Our aim here is simply to illustrate the usefulness of interactive enactment, how this concept can foster improved support for emergent workflows. Several approaches to adaptive workflow are based on the manipulation of Petri nets or derived models. The well-documented CHAUTAUQUA system [20] is an example of this approach. Execution of Petri nets is based on tokens moving along the arcs (flows) of the graph model. Tokens may split and later merge. Each token can be viewed as a "thread" in the work process. CHAUTAUQUA includes operators for splitting threads, and conflicts between threads are resolved interactively as part of a merge operation. Exception handling is supported through the send to operator, jumping to another activity to be performed by a given actor or role. AIS WORKWARE currently lacks powerful conflict resolution features. Our solution, not assuming complete, consistent, or well-nested models operates through activation of flows and connectors, and work item state transitions directly. Ambiguities are captured at the decision connectors, enabling the enactment engine to involve human actors through the fallback mechanism. Each user may override the current model, by explicitly making a decision, activating a flow, or starting a work item. Supporting this directly in Petri nets, would loosely correspond to adding a new thread (token), and in many cases also altering the model. Rather than acting reactively on the arrival of a token, we allow the users to act proactively, supported by their knowledge of the process plan and status and the activities of others, as mediated by the awareness services.

5.3 Integrated Support Environments AIS being an ongoing project, and WORKWARE a research prototype, other tools certainly provide a more complete collaboration support environment. For instance CHIPS [28] and MILANO [2] provide a richer integration with conversation support infrastructures and shared workspaces than WORKWARE at the moment. The strength of WORKWARE lies in its alignment with Internet technology, the service concept, which allows uniform configuration and access of internal functionality and external tools, and the close integration of process definition and enactment.

6  Conclusions and Further Work We have described emergent workflow, a new category of process support environments that focus on integrated support for planning and performance of work, user-oriented process models, and process knowledge management. Emergent workflow support is needed for ad-hoc project and knowledge work, to handle change, support empowerment, and utilise new technologies. In our work, we focus on graphical comprehensible models as a necessity for closing the gap between flexible representation in emergent workflow and knowledge management covering business and work processes. Our reference model ties enterprise models to workflow models intended to support autonomous groups who both plan and perform their own work, often coordinated through mutual adjustment. We propose a simple, yet powerful workflow modelling language, suitable for enduser manipulation and adaptation. The language supports flow of work, and highlights decisions in the process. It targets process instances, yet provides a more high-level notation than most languages used at the enactment level. How models built with the WORKWARE language can be enacted in an interactive manner, has also been described. By explicitly modelling decisions in the process, and utilising contextual awareness services to support coordination through mutual adjustment, human control of the enactment process is fostered. 6.1 Further work We have already indicated a number of challenging research areas within emergent workflow, especially within process knowledge management. For our own work, we first and foremost need to apply the WORKWARE prototype to real world cases outside the project organisations. Emergent workflow and the holistic process modelling approach will be essential in a forthcoming project involving several of the AIS partners, where we will perform 3 case studies. Another fascinating area is the presentation of process models. We need to support dynamic, user-defined views, and manipulation of models through these views. Techniques from information visualisation may be applied to further enhance the joint presentation of overview and detail in large process models. Presentation of process status and history through animation, is another area of great potential, especially when linked with simulation techniques. All of these presentation techniques can be

utilised to increase model comprehensibility and improve the potential for learning from the models. This potential for pragmatic model quality [13] can be further enhanced by adapting existing explanation generation and complexity reduction facilities to WORKWARE via its parent languages APM / PPM [23, 39]. The enactment support of the WORKWARE prototype should be improved. Creating a reusable set of automated decisions, is a first step in this direction, experimenting with milestones and time considerations in enactment another. Constraint-based approaches like FREEFLOW [17] and GPSG [22] look like promising starting points for making the WORKWARE enactment engine more flexible and powerful. We also need to build better resource brokers, supporting flexible allocation of personnel [27], improved contextual access to shared information workspaces and a richer integration of external tools, supporting data transfer as well as control integration. The awareness mechanisms need to be refined to support customised environmental feedback. We believe that a variant of Magic Lenses [6] can be attached to the elements of the workflow models, to filter the flow of awareness information. This solution would create a simple, customisable awareness framework, suitable for reuse and adaptation across different categories of processes. Another approach would be to apply the formalisms of the spatial model [36] or the Aeather awareness engine [37]. Acknowledgements. This work was supported by SINTEF and the AIS research project, sponsored by the Norwegian Research Council (Grant No. 120038/223). In particular, we thank Tore Christiansen (Det Norske Veritas) and Frank Lillehagen (NCR Metis) for contributions to this work.

References 1. Abbot, K. R. and Sarin, S. K. Experiences with Workflow Management: Issues for The Next Generation, Computer-Supported Cooperative Work (CSCW 94), (1994). 2. Agostini, A., De Michelis, G. and Grasso, M. A. Rethinking CSCW systems: the architecture of MILANO, The Fifth European Conference on Computer Supported Cooperative Work, Lancaster, UK, (1997). 3. Bannon, L. J. and Schmidt, K. CSCW: Four characters in search of a context, Proceedings of the 1st European Conference on Computer Supported Cooperative Work (EC-CSCW ’89), Gatwick, U.K., (1989). 4. Bardram, J. E. Plans as Situated Action: An Activity Theory Approach to Workflow Systems, Fifth European Conference on Computer Supported Cooperative Work, Lancaster, England, (1997). 5. Bentley, R. and Dourish, P. Medium versus mechanism: Supporting collaboration through customisation, European Conference on Computer-Supported Cooperative Work (ECSCW ’95), Stockholm, (1995). 6. Bier, E., Stone, M., Pier, K., Buxton, W. and DeRose, T. Toolglass and Magic Lenses: The See-Through Interface, SIGGRAPH’93, Anaheim, California, (1993). 7. Bogia, D. P. and Kaplan, S. M. Flexibility and Control for Dynamic Workflows in the wOrlds Environment, COOCS’ 95: Conference on Organizational Computing Systems, Milpitas California, USA, (1995).

8. Brathaug, T. A. and Evjen, T. Å. Enterprise Modelling, SINTEF Production Engineering, Trondheim STF 38 A96302, (1996). 9. Carlsen, S. Conceptual Modeling and Composition of Flexible Workflow Models, PhDthesis, NTNU - Norwegian University of Science and Technology, Trondheim, Norway (1997) . 10. Carlsen, S. Action Port Model: A Mixed Paradigm Conceptual Workflow Modeling Language, Third IFCIS Conference on Cooperative Information Systems (CoopIS'98), New York, (1998). 11. Carlsen, S. and Gjersvik, R. Organizational Metaphors as Lenses for Analyzing Workflow Technology, GROUP '97, Phoenix, Arizona USA, (1997). 12. Carlsen, S. and Jørgensen, H. Emergent Workflow: The AIS Workware Demonstrator, CSCW-98 Workshop: Towards Adaptive Workflow Systems, Seattle, (1998). 13. Carlsen, S., Krogstie, J., Sølvberg, A. and Lindland, O. I. Evaluating Flexible Workflow Systems, Hawaii International Conference on System Sciences (HICSS-30), Maui, Hawaii, (1997). 14. Casati, F., Ceri, S., Pernici, B. and Pozzi, G. Workflow Evolution, 15th ER'96 International Conference, Cottbus, Germany, (1996). 15. De Michelis, G., Dubois, E., Jarke, M., Matthes, F., Mylopoulos, J., Pohl, K., Schmidt, J., Woo, C. and Yu, E. Cooperative Informations Systems: A Manifesto, in Cooperative Information Systems: Trends and Directions, M. Papazoglou and G. Schlageter, Eds.: Academic Press, (1997). 16. Dourish, P. and Bellotti, V. Awareness and Coordination in Shared Workspaces, ACM Conference on Computer-Supported Cooperative Work (CSCW'92), Toronto, (1992). 17. Dourish, P., Holmes, J., MacLean, A., Marqvardsen, P. and Zbyslaw, A. Freeflow: Mediating Between Representation and Action in Workflow Systems, Computer-Supported Cooperative Work (CSCW'96), Boston, Mass, (1996). 18. Dove, R. Knowledge Management, Response Ability and the Agile Enterprise, Journal of Knowledge Management, vol. March 1999, (1999). 19. Ellis, C., Keddara, K. and Rozenberg, G. Dynamic Change Within Workflow Systems, COOCS’ 95: Conference on Organizational Computing Systems, Milpitas California, USA, (1995). 20. Ellis, C. S. and Maltzahn, C. The Chautauqua Workflow System, Hawaii International Conference on System Sciences (HICSS-30), Maui, Hawaii, (1997). 21. Gane, C. and Sarson, T. Structured Systems Analysis: Tools and Techniques: Prentice Hall, (1979). 22. Glance, N. S., Pagani, D. S. and Pareschi, R. Generalized Process Structure Grammars (GPSG) for Flexible Representation of Work, Computer-Supported Cooperative Work (CSCW'96), Boston, Mass, (1996). 23. Gulla, J. A. A General Explanation Component for Conceptual Modeling in CASE Environments, ACM Transactions on Information Systems, vol. 14, no. 3, (1996), 297329. 24. Gulla, J. A., Lindland, O. I. and Willumsen, G. PPP - An Integrated CASE Environment, Third International Conference on Advanced Information Systems Engineering (CAiSE'91), Trondheim, Norway, (1991). 25. Gutwin, C., Greenberg, S. and Roseman, M. Workspace Awareness in Real-Time Distributed Groupware: Framework, Widgets, and Evaluation, The HCI'96, (1996). 26. Heinl, P., Horn, S., Jablonski, S., Neeb, J., Stein, K. and Teschke, M. A Comprehensive Approach to Flexibility in Workflow Management Systems, WACC '99 - International Joint Conference on Work Activities Coordination and Collaboration, San Francisco, USA, (1999). 27. Herrmann, T. and Hoffmann, M. Augmenting Self-controlled Work Allocation in Workflow-Management-Applications, CSCW-98 Workshop: Towards Adaptive Workflow Systems, Seattle, (1998).

28. Haake, J. M. and Wang, W. Flexible Support for Business Processes: Extending Cooperative Hypermedia with Process Support, GROUP ’97, Phoenix, Arizona USA, (1997). 29. Kreifelts, T., Hinrichs, E. and Woetzel, G. Sharing To-Do Lists with a Distributed Task Manager, Third European Conference on Computer Supported Cooperative Work (ECSCW’93), (1993). 30. Langefors, B. Theoretical Analysis of Information Systems: Studentliteratur - Sweden, AUERBACH Publishers Inc. Philadephia, (1973). 31. Malone, T. W., Crowston, K., Lee, J., Pentland, B., Dellarocas, C., Wyner, G., Quimby, J., Osborne, C. and Bernstein, A. Tools for inventing organizations: Toward a handbook of organizational processes, Center for Coordination Science, Massachusetts Institute of Technology MIT CCSWP198; available from http://ccs.mit.edu/CCSWP198/, (1997). 32. Marshak, R. T. Workflow: Applying Automation to Group Processes, in Groupware Collaborative Strategies for Corporate LANs and Intranets, D. Coleman, Ed.: Prentice Hall PTR, (1997), chapter 6, pp. 143--181. 33. Maurer, F. and Pews, G. Supporting Cooperative Work in Urban Land-Use Planning, COOP’96: Second International Conference on the Design of Cooperative Systems, Juanles-Pins, France, (1996). 34. Miers, D. The Workware Evaluation Framework, ENIX Ltd URL: http://www.enix.co.uk/wf_or_ww.htm, (1996). 35. Nonaka, I. A Dynamic Theory of Organizational Knowledge Creation, Organization Science, vol. 5, no. 1, (1994), 14-37. 36. Rodden, T. Populating the Application: A Model of Awareness for Cooperative Applications, Computer-Supported Cooperative Work (CSCW’96), Boston, Mass, (1996). 37. Sandor, O., Bogdan, C. and Bowers, J. Aether: An Awareness Engine for CSCW, European Conference on Computer Supported Cooperative Work, Lancaster, UK, (1997). 38. Schmidt, K. and Simone, C. Coordination Mechanisms: Towards a Conceptual Foundation of CSCW Systems Design, Computer Supported Cooperative Work: The Journal of Collaborative Computing, vol. 5, (1996), 155-200. 39. Seltveit, A. H. An Approach to Information Systems Modelling Based on Systematic Complexity Reduction, HICCS’96, Hawaii, (1996). 40. Suchman, L. Plans and Situated Actions. New York: Cambridge University Press, (1987). 41. Swenson, K. D., Maxwell, R. J., Matsumoto, T., Saghari, B. and Irwin, I. A Business Process Environment Supporting Collaborative Planning, Journal of Collaborative Computing, vol. 1, no. 1, (1994), 15-34. 42. Wegner, P. Why interaction is more powerful than algorithms, Communications of the ACM, vol. 40, no. 5, (1997), 80-91. 43. WfMC WfMC - Workflow Handbook 1997, edited by Peter Lawrence: Workflow Management Coalition, John Wiley & Sons Ltd, (1997). 44. Willumsen, G., Gulla, J. A., Lindland, O. I. and Seltveit, A. H. An Integrated Environment for Validating Conceptual Models, The 6th International Workshop on Computer-Aided Software Engineering (CASE’93), Singapore, (1993). 45. Wyner, G. M. and Lee, J. Applying Specialization to Process Models, COOCS’ 95: Conference on Organizational Computing Systems, Milplitas California, USA, (1995).