A Light Workflow Management System Using Simple Process Models

1

A light workflow managementsystem using simple process models∗

Alessandra Agostini, Giorgio De MichelisCooperation Technologies Laboratory, DISCO - University of Milano - Bicocca,Viale Sarca 202, 20126 Milano, Italy{agostini, gdemich}@dsi.unimi.it

Abstract. Workflow management systems are considered a hot technology.Nevertheless, up to now they have not had the diffusion other packages such asproductivity tools, e-mail systems and groupware platforms have. We believe that this factis due to the many limitations of current workflow technology (weak support for changes;complex exception handling mechanisms; limited openness to and integrability with othersystem components; ...) and that radically new workflow management systems should bedesigned and developed in order to offer adequate products to the market. In this paperwe outline the main innovative features of the workflow management component of theMILANO system making it highly flexible and adaptable. A particular attention is paid to itsmodelling framework which is based on a class of net systems well supported by efficientalgorithms and to the services it offers to both workflow designers and actors. The mostrelevant aspects of the MILANO workflow management system are also illustrated througha realistic example.

1. Introduction

For several years workflow management systems have been announced as thenext best-selling computer application (White and Fischer, 1994; Koulopoulos,1995). But up to now they have not attained the success of other packages such asproductivity tools, e-mail systems, web-browsers and even groupware platforms.

Why do workflow management systems remain in limbo? Almost everyobserver argues in favor of their utility, yet so few users really apply them withinreal organizations. While the question has no single simple answer (Schmidt andBannon, 1992; Abbott and Sarin, 1994), it deserves the attention of anyoneinterested in the development of workflow technology.

A good starting point in this respect, can be the above-mentioned paper bySchmidt and Bannon (1992) which opens the first issue of ‘Computer SupportedCooperative Work: an International Journal’. In it the authors discuss therelevance of articulation work within cooperative work arrangements. Articulationwork deals both with the meshing of tasks and performers within a cooperative

∗ To appear on “Computer Supported Cooperative Work. The Journal of Collaborative Computing”

2

work process and with the interleaving of different processes within the work timeof a performer. Moreover, it deals with the continuous changes of cooperativework arrangements. Therefore, systems supporting articulation work must on theone hand liberate workers as much as possible from the routine articulation workthey need for coordinating themselves (script); on the other, help them to becomeaware of the situation where they are performing and to negotiate new cooperativework arrangements whenever a breakdown occurs (maps) (Schmidt, 1997).Finally, they need to be open to continuous changes, in order to support acontinuous updating of both their maps and their scripts. Most current workflowmanagement systems offered in the market focus only on the first of the aboverequirements, giving a limited support to the other two. Also, most workflowmanagement systems under development in private and public research centers donot cover all: they focus either on supporting changes (see for instance (Swensonet al., 1994)) or on supporting maps (e.g., Dourish et al., 1996)).

Kjeld Schmidt and Carla Simone have proposed a comprehensive approach forsupporting articulation work. In particular, they have provided an environment forthe design of any sort of coordination mechanisms—based on a sophisticatedmodeling system (Schmidt and Simone, 1996).

In this paper we propose a different solution on the basis of some architecturaland modeling considerations. Let us say a few words about them.1. Workflow management systems need to be integrated with the tools theactors of a process use to perform within it: productivity tools; specializedtechnical support systems—CAD systems, graphic packages, softwareenvironments, etc.; information systems and data bases; but also mail systems andother communication systems. It is not conceivable that integration is reacheddeveloping a unique comprehensive framework embodying them all. In fact, onthe one hand, users have already made their choice of those systems and usuallyresist changing their tools for new ones just to get some support for theirarticulation work; on the other, the creation of complex applications alwayscreates more difficult obstacles to both opening collaboration to new workers andchanging cooperative work arrangements.

Therefore workflow management systems are not applications (that the actoropens to do a task), but components of a cooperative information system(Papazoglou and Schlageter, 1998) characterized by a three-faceted architecture:system, organizational and group collaboration facet (De Michelis et al., 1998,1998b).

From the system point of view, a workflow management system must be afully integrated component of the cooperative information system (see above),focusing on the coordination among different activities and leaving to othercomponents the duty of performing them, while avoiding to introduce anyconstraint to the interaction with other systems.

From the organizational point of view, the workflow management system mustsupport and make visible the workflows: defining part of the rules, roles andprocedures characterizing the company and/or institution where it is used;offering to its users the automation of the routine tasks; helping them to deal withexceptional situations and breakdowns (Borgida and Murata, 1999); providing thedistribution of decision tasks among the users (in accordance with their roles);

3

simulating their performances under diverse resource allocations; giving fullsupport for the change of the workflows checking their consistency; and, finally,enacting changes in the ongoing workflow instances (Ellis et al., 1995).

Lastly, from the group collaboration point of view, it is an artifact within theworkspace of their users supporting their performances; for instance, making theworkflow transparent when they are already capable of doing the requestedactivity; making the workflow visible when they need help in understanding whatto do, as well as when a breakdown requires them to negotiate a new cooperativework arrangement.

2. The relevance of workflow technology has grown jointly with the emergence ofprocess oriented organizations and the related change management techniques(e.g., business process reengineering and continuous process improvement; Whiteand Fischer, 1994). Therefore, as already claimed above, any workflowmanagement system should be oriented to making the organization as flexible aspossible and to supporting its changes. On the one hand therefore, workflowmanagement systems should allow end-users themselves (given appropriateauthorization) to change the flow of work, jumping back and forth within theworkflow model, in order to let them handle exceptions and breakdownseffectively without changing it. On the other, changes of the workflow modelshould be applied as fast as possible in order to react timely to process changes,and it should be possible to implement them into the already running workflowinstances. In conclusion, workflow management systems should get theirflexibility both from the ease of dynamically changing them and from their notneeding continuous frequent changes of the model (due to the possibility of end-users of changing the flow of work of a workflow instance without changing itsmodel).

With respect to these features, most existing workflow management systemsappear to be inadequate. It is difficult to interrupt them, to exit their normal flowand then reenter it. Meanwhile breakdowns are very frequent (they are the norm inmany cases). They are based on complex and sometimes multiple process models(integrating data models, normal and exceptional flows, role descriptions) whosechanges need careful and time consuming analysis. They need to be designed byexpert programmers, introducing a time delay between process and workflowchanges. They do not support multiple viewpoints on the process, correspondingto the various actors with the different objectives and roles they support (themanagers and those who have to control and evaluate the process execution, thetask performers and, why not, the customers waiting for its outcomes).

Many observers have also argued that most workflow management systemsmake business processes too rigid, not allowing their users to react freely to thebreakdowns occurring during their evolution (Bowers et al., 1995). Some seem toblame the responsibility of this rigidity on their using formal workflow models(formal models canot fully capture the knowledge people use while acting withina business process); others on the strict coupling between modeling and executingthey introduce (models should be cognitive artifacts; Norman, 1991; notconstraining the behavior of the actors; Suchman, 1987; Dourish et al., 1996). We

4

agree with the above points. However, we are convinced that the rigidity ofexisting workflow management systems should be attributed neither to their usingformal models nor to their coupling of modeling and execution; on the contrary, itis caused by the above-mentioned weaknesses affecting them.

We argue in this paper that—in contrast to common belief—formal theory-based models can contribute to the solution of the above problems; but if, andonly if, they are conceived from a different perspective. In fact, good algebraoffers effective tools for creating a process modeling environment exhibiting thefollowing properties:• it allows us to simulate the process before its execution;• it allows formal verification of some workflow properties;• it supports unambiguous graphical representations of the workflow;• it allows us to use a minimal input for redundant outputs, through the

algorithmic completion of the model;• it supports multiple views of the process, through synthesis algorithms and

model conversions;• it allows the automatic derivation of exceptional paths from the acyclic normal

flow of the process, when needed;• it automatically enacts model changes on the running instances of a workflow,

protecting them from undesired outcomes.

What is needed in order to get all these services from algebraic theory is tokeep workflow models as simple as possible. That is, to use a divide et imperaapproach to the workflow, treating in a distinct way: the execution of the tasksembedded in the workflow steps; the data flow; the control flow, the latter beingthe only issue to be handled directly by the workflow management system. It hasto be underlined that simplifying the workflow models in accordance with theabove crtierion does not simplify (and therefore impoverish) the flow of work ofany process instance; therefore, any rigidity still remaining in the system shouldbe attributed to the organizational constraints reflected in the model and not to themodel itself. Using simpler models, which allow jumps, addresses the problemraised by the critics of workflow technology. The development of workflowmanagement systems based on them and the observation of their use in real worksettings will show whether or not the proposed solution actually offers an answerto the above criticism.

The above considerations have offered the guidelines for developing theprototype of the workflow management component of the MILANO system, agroupware platform supporting its users while performing concurrently variouscooperative processes (Agostini et al., 1997).

We claim that the MILANO workflow management system is highly flexible—at least with respect to current workflow management systems. In fact, its lightarchitecture gives it a high degree of openness (section 2); and its simplemodeling environment makes changes rare and easy to design (section 3). Thefunctionality and the interaction modes allow its users to cooperate with an

5

adequate degree of support with respect to their articulation work—as shownthrough a scenario-like example derived by a real bank procedure (section 4).

Some open problems and further research directions are discussed in theconclusion.

2. The architecture

As anticipated in the Introduction, the MILANO workflow management system(MWMS) is part of a groupware platform. The MWMS architecture cannot bedescribed in isolation. Rather, we must briefly recall some issues of the completeMILANO platform (Agostini et al., 1997) to explain the workflow componentadequately.

2.1. A CSCW PLATFORM

In 1994 at the Cooperation Technologies Laboratory the authors—together withMaria Antonietta Grasso and several students—began development of theprototype of a new CSCW system, called MILANO (De Michelis and Grasso,1994; Agostini et al., 1997). Successively, they kept on developing it when freefrom other more urgent duties.

MILANO is a CSCW platform supporting its users so that they can remainaware of the history they share with the actors with whom they cooperate and ofthe activities they are committed to perform in the future. The perspective fromwhich we observe work practices can be considered a Situated Language-ActionPerspective (Suchman, 1987; Winograd and Flores, 1986; De Michelis andGrasso, 1994).

MILANO integrates into the user workspace a workflow management system(MWMS) with a multimedia conversation handler (MCH) and also an objectrepository (MOR) where an organizational handbook is stored.

TCP-IP

To Do ListMCH

Mailbox

MCHMWMS

e-mailSafe-Tcl Interpreter

MOR

Workspace

Application Environment

Execution Environment

Figure 1. The overall architecture of the MILANO system

As components of a single platform, the MWMS and MCH are fully integratedand allow both opening a conversation from within a workflow and enacting aworkflow from within a conversation. The former possibility characterizes theexception handling mechanism of the MWMS (therefore it will be discussed inthe next sections of this paper); the latter—i.e. enacting a workflow from within a

6

conversation—allows us to embed any workflow within a customer-performerrelation as if it were a (computer-based) artifact characterizing their cooperativework arrangement (De Michelis, 1997). Within any cooperative process,workflows and conversations are fully integrated and give rise to a partial order of(communicative and action) events describing its history; however, whenever shewants, the user can abstract from the history both a communication flow and anaction flow.

Finally, it is relevant to say that the workflow models of an organization arestored in its MOR component.

The above sketched architecture can be characterized well by means of thepreviously cited three faceted architecture of cooperative information systems (DeMichelis et al., 1998b): integration among MWMS, MCH and MOR is an issueregarding the system facet; both the workflow models and their enacted instancesare relevant from the organizational facet viewpoint; and the mutual enactmentbetween MWMS and MCH defines the group collaboration facet of MILANO.

2.2. AN OPEN SYSTEM

During the time interval within which a work process is performed some actorsleave it while other new actors join it. Moreover, the various actors have differentlevels of engagement in it at different moments. Finally, some people participateonly occasionally in the work process. Therefore in a particular work processthere is a continuous movement between central and peripheral participation(Lave and Wenger, 1991).

A workflow management system—as well as the CSCW platform in which theWMS is integrated—should adapt itself to the above variety of human behaviorswith the maximum degree of plasticity in order to avoid constraining its users. Toreach this goal, the system should first and foremost be able to support interactionbetween people having the system and people not having it—let us call thiscapacity of a system openness.

MILANO uses the computational mail model (Borenstein, 1992) to obtainopenness (the Safe-Tcl environment (Borenstein, 1994) has been used). Thus thee-mail messages can be automatically manipulated when they are sent and/orreceived; and, in particular, they are computational since embed programs otherthan data. With computational mail, for example, messages can bring theexecution environment and the data necessary for reacting to them.

E-mail is often recognized as one of the most successful groupwareapplications (after fax and telephone). Moreover, the use of e-mail as adistribution model makes the group boundaries inherently dynamic, providingcontemporaneously different degrees of participation. Therefore e-mail is anatural candidate to be the middleware for groupware, that is, its enablingtechnology.

The resulting architecture of MILANO—for more detail see (Agostini et al.,1997)—supports, with different levels of service, cooperation between three typesof actors: those having the MILANO system; those having the Safe-Tcl interpreter;and those just using e-mail (see Figure 2).

7

TCP-IP

Mailbox

TCP-IP

e-mail

E-mail

TCP-IP

Mailbox

Safe-Tcl


To Do ListMCH

Mailbox

MCHMWMS


Milano

MOR

Workspace

Application Environment

Execution Environment

Figure 2. The multi-level user architecture of the MILANO system

Whereas two actors both having MILANO can obviously cooperate using thefull set of services offered by it, the other cases require further discussion. Theactor having a Safe-Tcl interpreter is still provided with a meaningful subset offunctionality (see section 4.3 for an example), since MILANO messages embeddata and source code that the interpreter executes on destination sites forinteracting with MILANO users. Some of the functions provided are: notificationof activities to be performed; visualization of the context of an activity; completehandling of the action flow (e.g., calculation of the next step, routing of theinvolved data, etc.); access to the state of the running work process.

For her part, the actor who just uses common e-mail is also provided withuseful information and can easily be involved in an ongoing cooperative process.In this case, in fact, any program embedded in a message cannot be executed sothe user can only read it. This is why messages always contain, at the beginningof the message, a user-readable ‘textual’ part giving all relevant information: thedescription of the activity to be executed; the information to be produced; theinstructions on how to answer the message, and so forth. Of course, the previouslyproduced documents—necessary for the exploitation of the activity—are enclosedin the message too.

Let us specify that, in case of a user having a MIME compliant reader, the‘textual’ part becomes a real hypertext (e.g., the attached files, web/e-mailadresses are activable items). Moreover, in order to handle the flow ofinformation, messages embed a form-like part for filling in some information.

To carry on the procedure—after concluding her task—the user must reply tothe message enclosing all modified or new documents and checking the‘completed’ choice (in the form-like part of the message). A specific MILANOagent at the receiver’s workstation—usually the workstation of the person incharge of the procedure—is automatically activated to parse and elaborate themessage; this is to completely update the status of the procedure as well as tocalculate the next step(s) of the procedure. Both the information provided by theuser and the system information included in the heading of the message (e.g.identification numbers of the activity and its procedure) are used for elaboratingit.

8

The MILANO user in charge of the successive activity does not see anydifference with respect to the other two cases (i.e. when an activity is executedusing MILANO or the Safe-Tcl interpreter).

Finally, the content of the message allows basic handling of those cases inwhich the user is unable to complete the activity. In fact, while replying to themessage, the user can choose—within the form-like part of the message—fromamong general reasons for not accomplishing her task (e.g. requesting delegation,asking for missing information, etc.). However, in these cases a human agent willreceive the message only partially elaborated by MILANO.

2.3 THE PROCESS MODELING FACILITY

As in many workflow management systems, coordination among the activities ofa workflow is managed by the MWMS by means of its formal model. We havechosen a class of Petri Nets (Reisig and Rozenberg, 1998) as the theoreticalframework for building process models. More specifically, since we have decidedto keep the control flow separate from the activities coordinated by it, we couldchoose a very simple class of Petri Nets (namely Elementary Net Systems;Rozenberg and Engelfriet, 1998) that are easy to design and read.

Petri Nets are not limited to allowing formal, executable and graphicalrepresentations of a process. Rather, they also offer a sound theoretical frameworkfor supplying a large variety of services to the users of a process model:generating multiple different representations of a workflow; computingexceptional paths on the basis of the regular workflow; checking the correctnessof a workflow change and enacting it within all the ongoing instances of thatworkflow. With respect to exceptional paths, the process modeling facility iscomplemented by a powerful undo mechanism (for backward jumps) and an agentgenerating the form to be filled in order to have all the needed information at agiven state (for forward jumps). Both these mechanisms, implemented up to nowonly with respect to form managing workflows, need to be extended also to thoseinteracting with the information system.

The process modeling facility of the MWMS delivers its services not only tothe run time engine and to the simulation module, but also to the interface module(generating the best fitting and/or requested representation of the workflow aswell as visualizing different categories of jumps allowed in a given state - see nextsection), to the design environment (checking the correctness of any newlydesigned workflow with respect to its minimal critical specification), and to theenactment mechanism (separating the ongoing instances that are and are not in asafe state).

Therefore, the process modeling facility of the MWMS is an importantcomponent contributing to its usability, effectiveness and flexibility. More aboutthe formal properties of the workflow models of the MWMS can be found in(Agostini and De Michelis, 1998) and in the next section.

9

3. The process model

As already indicated in previous paragraphs, MILANO is based on the idea thatworkflow models must be as simple as possible. On the one hand in fact, processdesigners should be able to describe a work process even if they have little or noexperience with formal languages and mathematical theories; that is, thetheoretical model should be simple to learn while providing an easy to understandrepresentation. On the other hand, they should be allowed to give a minimal inputin designing the workflow, disregarding all unnecessary details, even if they getback redundant and/or tailorized information.

With these goals in mind, we chose to use Elementary Net Systems (ENS)(Rozenberg and Engelfriet, 1998) for modeling workflows in MILANO. In fact,they provide a nice graphical representation. And they are easy to learn since justfew objects and concepts need to be understood for representing the dependenciesbetween activities as well as their parallelism and/or branching.

To obtain the second goal—that is, simplify the design of the workflowwithout diminishing expressiveness of the model—we allow process designers todisregard at the design phase all possible exceptions and/or breakdowns whichusually occur during the execution of a work process; in other words, the user candesign the plan as a partial order of progressing activities (steps). This has beenachieved by coupling and exploiting two architectural characteristics of theMILANO workflow: the integration of communication and action (see section 2.1)and the mathematical basis (in particular, the algorithm for computing exceptionalpaths see section 3.2).

Without the constraint of taking into account exceptions as well as all possiblerepetitions of parts of the process, we are able to reduce the Elementary NetSystem category to a simpler subcategory: namely Free-Choice Acyclic ENS. Ingeneral, the workflow can be defined without using cycles or loops (i.e. it isacyclic); and when there are various alternatives (i.e. choices) the branch to befollowed is locally computable, since the choice does not depend on externalprocesses (i.e. it is free). Thanks to the above restrictions our class of net systemsis supported by efficient algorithms; in particular, the synthesis of a net systemfrom a sequential transition system is polinomial, while for generic ENSs it is NP-complete (Badouel et al., 1997).

Finally, in order to handle big workflows, consisting of a large number ofactivities, it is possible to design the model as a hierarchy of Free-Choice AcyclicENS where lower level models refine the activities of the higher level model.

3.1. MULTIPLE REPRESENTATIONS

A primary characteristic of the MILANO WMS—deriving directly from itsmathematical basis—is the capacity to provide to its users differentrepresentations of the workflow, as well as to freely allow the switching amongthem. In particular, two main representations are offered: the first, calledWorkflow Net Model (WNM), is based on Elementary Net Systems (Rozenbergand Engelfriet, 1998); while the second, called Workflow Sequential Model

10

(WSM), is based on Elementary Transition Systems (Nielsen et al., 1992;Bernardinello, 1993; Badouel and Darondeau, 1998).

The Workflow Net Model (see Figure 5a on following pages) is arepresentation making explicit the local conditions characterizing any state of theworkflow; for example, the independence between two activities is easily visiblebecause independent activities have disjoint pre-conditions. On the contrary, theWorkflow Sequential Model describes a workflow as a sequential automatonwhere activities are connected by global states (Figure 5b); for instance, thesequential path followed during the execution of an instance is traced as a line andtherefore it is useful for having a global view of the workflow.

In particular, the WNM representation can be used by the performers of a workprocess while focusing on the activity they have to do and on its pre- and post-conditions. Instead the WSM view is more useful for supporting a managerialview of the process (e.g. showing the state reached by all its instances), as well asfor helping exception handling (showing to which states an instance can jump; seenext sections).

Since the sequential behavior of an ENS can be represented as an ETS and,conversely, given an ETS it is possible to synthesize an ENS whose sequentialbehavior is equivalent to it, switching from one representation to the other can beautomatically supported by the system (Nielsen et al., 1992) and consequently, theswitch between the WNM and WSM can be computed whenever necessaryi.

While hierarchical models allow us to keep WNMs small, they don’t preventus from having a state space explosion in the WSMs of highly concurrentworkflows. The problems related to the graphical visualization of large WSMs(multi-dimensional graphs of WSM will appear as intricate and difficult to readgraphs) are not considered in this context. They will be discussed briefly in theConclusion.

3.2. EXCEPTIONS AND LOCAL CHANGES

Our theoretical framework allows us to create additional paths (jumps) connectingtwo states of a workflow, as if the partial order of progressing activities were aminimal set of generators of all the paths connecting its states. Moreover, theframework allows us also to distinguish various categories of jumps, so thatdifferent jumps (exceptional paths) can be associated to different responsibilities.Whenever the performer of an activity in a workflow cannot act in accordancewith the model, she can jump (either forward or backward) to another state fromwhich the execution can progress again.

The creation of jumps is performed through the computation of processextensions of the WNM (or through the completion of the graph in the WSM,which is the same thing). Jumps are distinguished on the basis of two differentcriteria: first, from the viewpoint of their direction between forward and backwardjumps; second, from the viewpoint of the number of tokens they move in theWNM.

11

Forward and backward jumps address complementary and opposite needs: theforward jumps cause the skipping of some activities while the backward onesinvolve going back—in some previous state of the workflow—for re-executing orperfecting some activities.

With respect to the second criterion—taking into account that jumps areactivated by one actor when a breakdown occurs—we want to avoid herinterfering with the activities of the other actors which are going on concurrentlyand are therefore beyond her control, except for blocking them. Therefore, theMILANO workflow management system allows either to move one single token inthe WNM or to cancel two or more tokens and write one token (in this case,several concurrent activities are stopped and the workflow is moved to a statewith a lower degree of concurrency). It has to be underlined that the two allowedcategories of jump can be visualized efficiently through a partial representation ofthe WSM, where only one line of the graph describing the concurrent activitiesneeds to be represented. This avoids state space explosion and offers users a clearpicture of the options among which they can choose.

Combining the two above criteria, we therefore allow four classes of jumps:strongly linear backward and forward jumps; weakly linear backward and forwardjumps (see section 4.4 for an example), where we call strongly linear jumps thosewhich move only one token in the WNM and weakly linear jumps those whichcancel two or more tokens and write one token in the WNM. The MILANOworkflow management system allows us to associate to each of these classes adifferent responsibility, in accordance with the roles and rules of the organization:for example, forward jumps and weakly linear jumps may need the authorizationof the process owner, while strongly linear backward jumps are under theresponsibility of the actor herself. Other policies may also be defined andembedded in the organizational handbook component of MILANO (MOR).

When a breakdown occurs, MILANO offers the user the possibility of seeing allthe jumps of one of the above categories, so she can choose one of them. Theauthorization for it, if needed, is requested and discussed within a conversationwith the responsible role that MILANO opens automatically. Within thisconversation, it is also possible to assign to any actor some specific tasks (e.g. inorder to perform some of the skipped activities in forward jumps).

We would like to underline that cases can be handled also with standard (i.e.unexceptional) jumps; that is, users can avoid specifying standard parts of theworkflow. For instance, repetitions and shortcuts can be managed through jumps.

3.3 DYNAMIC GLOBAL CHANGES

The MILANO modeling framework allows performers of a workflow to choosehow to solve a breakdown (e.g. an insufficiency of a process description).Furthermore, the framework supports workflow designers when they need tochange the structure of a process.

We assume that a workflow model is a specific organizational choice withrespect to a minimal critical specification defining what it must in any case do;

12

when no explicit minimal critical specification is given, then by default the n-dimensional graph allowing any order in the execution of the activities isconsidered. Changes of a workflow model are correct if and only if: on the onehand, they have no deadlocks; and on the other, they are consistent with theminimal critical specification. While many approaches for checking changecorrectness support only deadlock-freeness—see for instance (Van der Aalst,1998)—MILANO also evaluates its consistency with the minimal criticalspecification.

In fact, the user can formally define the Minimal Critical Specification (seebelow and (Agostini and De Michelis, 1998)), using it as a reference for guidingany successive change. The correctness check of a change is made verifying if themorphism from the changed workflow model to the Minimal CriticalSpecification induced by the names labeling the activities exists and is injective(Agostini and De Michelis, 1998).

As its name suggests, a Minimal Critical Specification (MCS) is lessconstraining than any workflow model correct with respect to it; i.e. it admits thelargest class of behaviors. For instance, the Minimal Critical Specification—givena set of n activities and no temporal constraint among them—is a workflow whereall the n activities can be executed concurrently; in other words, the WSMrepresentation contains a flow for each possible ordering of the n activities (theMCS defined by default in MILANO). In short, the administrator—in defining theMCS—should insert the causal and temporal constraints among the activities,while avoiding insertion of those constraints related to the actual policy of theorganization.

However, even if a particular change of the workflow maintains the correctnessof the process, when a workflow is instanced a large number of times—as usuallyoccurs, e.g. in banks, insurance companies and public administrations—it is notpossible to move all of them to the new model, since some of them may becomeinconsistent. Sometimes moving all the instances to the new model could be notnecessary; however, frequently organizations request it, even at the cost ofrestarting all of them. Therefore managing new models through a versioningmechanism is not sufficient and dynamic change is the best suitable solution.

To face this problem we distinguish in the old model between safe and unsafestates with respect to the proposed changeii. An instance is moved to the newmodel if and when it is in a safe state; so that it can continue until its correctcompletion. In practical terms, one running workflow instance is in a safe state ifthere is a univocally determined image of its state within the new model of theworkflow; moreover, moving this instance to the new model (i.e. to the uniquestate/image within the new model) the workflow can be correctly completed. Wewould underline that we consider incorrect even those cases where, moving to thenew model, some activities should be re-executed.

The treatment of dynamic changes we propose is strictly related to the oneproposed by Ellis, Rozenberg and Keddara (Ellis et al., 1995). The maindifference is that, while Ellis and co-workers move any workflow instance to anew model where unsafe states and paths are preserved in order to avoid

13

inconsistencies, in our approach the move of the instances is delayed until theyreach a safe state.

Figure 3 summarizes the three main patterns of change allowed by the MILANOtheoretical framework, shading the unsafe states: parallelization, making twosequential activities concurrent (Figure 3, a); sequentialization, creating asequence with two previously concurrent activities (Figure 3, b); swapping,inverting the order of two sequential activities (Figure 3, c).

e1

e2

e1

e2 e1

e2

Parallelization

e1

e2

e1

e2 e1

e2

Sequentialization

e1

e2

e2

e1

Swapping

a) b) c)

Figure 3. The three classes of changes available in the MILANO workflow management system

The class of changes introduced above is quite small and we are aware that itdoes not cover the real needs of users. A precise definition of activities’refinement can further extend the class of supported changes.

4. The functionality and interaction modes

Up to now we have given a brief description of the architecture of the MWMS(section 2) and we have highlighted some features of the theoretical frameworkfor modeling processes embedded within it (section 3). A different view on it—focusing on the functionality and interaction modes it offers to its users—mayhelp the reader to understand how both architectural choices and theoreticalgrounds of the MWMS converge to shape a highly usable system.

4.1. THE CREDIT PROCEDURE EXAMPLE

To explain the main features of the MILANO workflow we will use a scenario-likeexample derived from a real credit procedure used within an Italian bank; for amore complete description see (Schael and Zeller, 1993; Agostini et al., 1994).This procedure supports the process through which a customer request for a newcredit is managed by a bank.

The organizational structure of the bank is sketched in Figure 4, where onlypeople or offices taking part in the credit procedure are shown. In the following abrief description of the organizational roles belonging to the cooperation networkis provided.

14

Credit office director Credit office evaluator

Office in charge for ...

EDP centre

Resolution body

Risk centre

Credit office secretariat

HEADQUARTER

...

Agency director

Agency credit secretariat

BRANCH 1

......

...District coordinator

DISTRICT 1

District coordinator

DISTRICT n

Agency director


BRANCH 2

...

... ...

Agency director


BRANCH n

...

Figure 4. The organizational structure of the bank

The Agency Director—AD in short in the next Figures—is responsible for theagency's overall performance and for commercial development. According to theorganizational model of the bank, she is the initiator of the credit procedure. Inline with current bank rules, her role is characterized by autonomy and fullresponsibility in initiating a credit request procedure; her deliberation competenceis limited to loans • 50,000,000 Lit.

The District Coordinator (DC) has responsibility over the bank budget forcredit operations in her area of competence. She is informed on all creditproposals in order to explore new business opportunities. Her deliberationcompetence is limited to loans • 80,000,000 Lit.

The Credit Office director (CO) is an experienced manager. She has theresponsibility of assuring a check on credit activities in general. Her deliberationcompetence is limited to loans • 200,000,000 Lit.

The Resolution Body (RB)—that is, the Top Management Council of theBank—has the deliberation competence on all loans > 200,000,000 Lit.

In the credit procedure the client interacts with the Agency Director (AD) whois responsible for the whole procedure. After a preliminary informal investigation,where the client motivation is exploited, the documents the clients provides tosupport her request are collected and two parallel processes start: in the first, theinformation about the client accounts are collected and the practice is perfected,while in the second several external data bases are checked to see if the client hasany insolvency or any other critical financial situation. The two processes joinwhen a report on the credit request is written. At this point the decision processstarts and it follows different paths depending on the value of the requested credit.For instance, if the credit request is under 50,000,000 Lit. the AD can write acredit proposal and submit it to the District Coordinator (DC) for her approval.Otherwise other bodies of the bank (e.g., the Credit Office director—CO; theResolution Body—RB) have to write the credit proposal and/or decide upon itsapproval. If the credit proposal gets the corresponding approval, the clientreceives a copy of the contract for signing.

In order to take her decision, the agency director asks agency employees(generally credit and/or EDP experts) for information about the client. This

15

information can be obtained from several sources, which can be internal orexternal to the bank.

4.2. MULTIPLE REPRESENTATIONS

As already explained in previous paragraphs, a workflow is a resource used bydifferent persons with different goals and needs. Therefore, it is an impassableroad trying to provide a single representation of it, since the latter becomesunreadable if it contains all the information needed by all of them. Moreover,even the greatest (graphical) representation is not suitable for all varioussituations. In the current implementation of MILANO, the users are allowed toview the model of a workflow in two complementary representations (i.e. theWNS and the WSM models; see section 3); however, we are investigating thepossibility of adding further graphical views (see for instance (Schmidt andZiemer, 1998)).

The first representation—that is, the Workflow Net Model, see Figure 5ashowing the Credit Procedure—is usually used in the bank for teaching theorganizational procedures to the newcomers. In fact, in the Net both the activitiesmaking up a procedure and their interdependencies (concurrency, temporal andcausal dependencies, etc.) are clearly visible. Moreover, the performers of theactivities—since they are involved contemporaneously in many instances ofdifferent procedures—are in the habit of looking at the Net representation whenthey need to understand what to do.

b15

b14b13

b12b11

b16

b17

b18

b19

b1

b3

b6

Client Documents

b7

b8

b9

Exploitation of Client Motivation

Collecting

b2

b4

b5

CollectingClient Information

PerfectingPractice

Checking external Credits

Checking

Further Investigation

Financial Insolvencies

b10

WritingReport

DC:WritingProposal(=<80M)

WritingProposal(=<200M)

RB:Evaluation

RB:WritingProposal (>200M)

RB:Evaluation


AD:

CO:

Client:Approval Conditions& Signature

AD:Seconding Request

DC:Seconding Request

CO:Seconding Request

& Approval

EvaluationDC: & Approval

& Approval

CO:Evaluation& Approval


Client Documents Collecting


PerfectingPractice

DC:WritingProposal(=<80M)

RB:WritingProposal (>200M)


AD:

Proposal

AD:Seconding Request

DC:Seconding Request

CO:Seconding Request

{b1}

{b2}

{b3, b6}

{b4, b6}

{b5, b6}


{b3, b7}

{b4, b7}

{b5, b7}

CeC

CeC

PP

CCI

{b3, b8}

{b4, b8}

{b5, b8}CFI

PP

CCI

{b3, b9}

{b4, b9}


{b5, b9}FI

PP

CCI

CFI

Checking FinancialInsolvencies

FI

{b11}

Writing Report

{b12}

{b13}

{b10}

{b14}

{b16}{b15}

{b17}

{b18}

{b19}

(=<200M)

RB:Evaluation & Approval

RB:Evaluation & Approval

EvaluationDC: & Approval

CO:Evaluation& Approval

WritingCO:

Client:Approval Conditions& Signature

a b

Figure 5. The WNM (a) and the WSM (b) models of the Credit Procedure.

16

On the contrary, when an exception occurs (see section 4.4), usually they wantto know the path followed in this particular instance and therefore they look to theWSM (see Figure 5b). The WSM is also used by managers and designers. In fact,this representation makes the global state of a workflow explicit. It is also a goodway for analyzing at a glance many instances of a procedure for comparing theirevolution.

Let us imagine that—during the Easter period—the bank temporarily re-organizes the employees’ responsibilities in order to provide a complete service tothe clients even though many employees are on vacation. Therefore one of theemployees usually working at the front desk is in charge of ‘Checking FinancialInsolvencies’ within the Credit Procedure. She finds four new instances on her to-do list this morning.

“Phew! Around Easter time it seems that everybody needs more money. Nextyear, I really must remember to refuse this duty.”—she confesses to the colleaguenear her.

“...and I cannot remember even a single word of the explanation of the personin charge”—she thinks. She selects the first ‘Checking Financial Insolvencies’instance and quickly opens the Net view of it (see Figure 6).

Figure 6. The Net view of the Credit Procedure and the to do list on the background.

“OK. The check of the external credits is not part of my activity. Moreover, ithas already been successfully completed.” Double clicking on the ‘Checkingexternal Credits’ activity she finds who executed it (see Figure 7). He is not onvacation; this is good information to know in advance. Finally, she starts her workand the MILANO workflow launches the various scripts and applications related toher activity, guiding her work smoothly up through completion.

17

Figure 7. The main information about the ‘Checking external Credits’ activity.

...In the meantime, the Agency Director is preparing her yearly report in herbeautiful office. She has already collected the details regarding how many creditshave been issued and how many have been denied during this year; however, shelikes to insert the data regarding the ongoing requests of credits with the details oftheir current state. Therefore, she opens the WSM view—choosing to visualize allrunning instances of credits in the same window—and prints it.

4.3. OPENNESS

...Over the last period the Credit Office director has traveled a lot to the bankheadquarter in Rome. In the last month she has spent only a couple of days in heroffice. In fact, the bank is re-organizing and possible merger with another Italianbank needs to be discussed continually. Moreover, she is without her personallaptop since some software upgrade was necessary. Temporarily, she received asubstitute portable computer but only general purpose software is installed in it(inparticular, the Safe-Tcl interpreter is installed but not the MILANO system).

Looking through her hotel room window at the beautiful panorama of Romelife, she connects to Internet to read her e-mail.

When she reads e-mail using MILANO the activities to be done are filtered andput in the user’s to do list; when she reads e-mail with another mailer—as in thiscase—the activities are mixed with the other messages in the user’s mailbox. Infact, as already explained in section 2.2, the (data of) activities are embedded inMIME messages together with the Safe-Tcl programs for handling them.However, the activities are easily distinguishable from the other ‘textual’messages thanks to the initial part of the subject (MWMS:).

We want to recall that—within the procedure handling the request of a credit—the Credit Office director is responsible for either writing the proposal (creditrequest under 200,000,000 Lit) or seconding the request (credit request over200,000,000 Lit).

This evening she is involved in a work dinner and has only half an hour to getready. Absent-mindedly hearing the light noise of the hard disk downloading thedaily tens of messages, she thinks: “@#! I have no time to dry my hair.” Finally,when the mailer stops, she quickly sorts the mailbox by subject—consequently,

18

the activities are sorted by deadline, procedure name, and activity name since thisinformation is contained in the subject.

“Better skip all ‘Writing Proposal’ activities!”. Leaving unread all thesemessages, she decides to take a short look at the single over 200 millions creditreceived. Double clicking on it (or whatever she must do to read a message in thisparticular mailer), she sees the ‘Seconding Request’ form appear on the screenshowing the main details of the credit (see Figure 8). The usual Safe-Tcl windowalerting the user that a Safe-Tcl program is running appears on the top of thescreen, too (see Figure 8).

Figure 8. A sample of the interface of a Safe-Tcl user.

For safety’s sake, each time a Safe-Tcl program embedded in a message isstarted the user is made aware of it. Of course, more serious safety rules are alsoused: see (Borenstein, 1994) for details.

She clicks on the context button for showing the history of the process (see(Agostini et al., 1997)) and the Safe-Tcl window appears on the top again.Meanwhile, the data related to this instance of the procedure are automaticallyselected from another (MIME) part of the same message. “Wow! It is really likeusing MILANO directly. Just a little slower.”, she exclaims realizing with somedelay that MILANO is not installed.

She clicks the ‘Seconding the Request’ button and a reply message with herdecision is automatically generated. She confirms it and the message is sent to thenext actor who may or may not have MILANO. (Who knows? And who reallycares?).

“That’s all, folks. I’ve done enough work for today.”; she claims taking onelast look at the mirror before leaving for dinner.

4.4. EXCEPTION HANDLING VIA JUMPS ANDCOMMUNICATION

In our Bank—but similar organizations can adopt similar rules—jumps forhandling the exceptional cases are grouped in two different classes: jumps a

19

performer can negotiate directly with the other performers preceding her on theworkflow (since they request an extra effort on some of the previous activities);jumps which must be authorized by the Agency Director (in fact, either they areshortcuts skipping some activities or they cause stopping several ongoingactivities). The first class contains strongly linear backward jumps (see section3.2); the second is composed by strongly linear forward jumps (that is, skippingsome activities) as well as weakly linear (backward and forward) jumps (that is,stopping several concurrent activities).

When a breakdown occurs, the performer can ask the system to compute theavailable jumps with respect to the current state of the workflow instance.Depending on the jump she selects, the system opens a conversation either withthe Agency Director (strongly linear forward jumps or weakly linear jumps) orwith the involved performers (strongly linear backward jumps). The algorithm forthe computation of jumps together with the integration of the workflowmanagement system with the conversation handler in MILANO provides the userwith a flexible and effective exception handling mechanism. Meantime theworkflow designer is free from considering all foreseeable exceptions. Moreover,the workflow model remains simple (no loops, limited number of cases) andtherefore designing and changing it has a more limited complexity.

Let us make one example. The actor responsible for ‘Perfecting the Practice’discovers that it has not been specified whether or not the client is married (inItaly married people with a ‘shared properties system’ must have their spouse’sapproval for many financial transactions) and therefore she is unable to completeher job. The employee responsible for ‘Collecting Client Information’ forgot it.“He always forgets something”, she complains to a colleague. Since she alreadyknows which activity needs to be re-executed, she selects directly where to jump(i.e. to the state {b3, b9}). In this case the system—instead of providing thevarious alternatives to the user—only checks the validity of the jump. This jumpis a strongly linear backward one (the dashed lines in Figure 9 show all stronglylinear jumps available from the state {b4, b9}) and therefore the system opens aconversation between the performers of the two activities (i.e. ‘Collecting ClientInformation’ and ‘Perfecting the Practice’) to allow the negotiation of the jump.

Let us specify that, in the current implementation of MILANO, the abovementioned conversation is started by an e-mail message between the two people.In the near future however, the system will propose to the user the most suitablecommunication media for contacting the other person (e.g. chat, phone, videoconference). In fact, we are already developing a module for recommending thebest communication media depending on the user’s preferences, the availablemedia, what the other user is doing, etc.

20




PerfectingPractice

{b1}

{b2}

{b3, b6}

{b4, b6}

{b5, b6}


{b3, b7}

{b4, b7}

{b5, b7}

CeC

CeC

PP

CCI

{b3, b8}

{b4, b8}

{b5, b8}CFI

PP

CCI

{b3, b9}

{b4, b9}


{b5, b9}FI

PP

CCI

CFI


FI

Writing Report

{b10}

.

.

.

Figure 9.

In designing the Credit Procedure, it is not necessary to specify the cases ofwithdrawal or rejection. Even if they are frequent and relevant, they have beenconsidered as special cases, to be treated as exceptions. Let us imagine that whenan instance of the Credit Procedure is in the state {b4, b9} the client withdraws;then the process instance can be brought to its conclusion through one of theallowed weakly linear jumps (see the dashed lines in Figure 10). In this case,when the jump closing the workflow is chosen—canceling the two tokens,respectively, in b4 and b9 and putting one token in the final state {b19}(see Figure5 in which the complete workflow is shown)—the system opens a conversationwith the Agency Director to request her authorization.




PerfectingPractice

{b1}

{b2}

{b3, b6}

{b4, b6}

{b5, b6}


{b3, b7}

{b4, b7}

{b5, b7}

CeC

CeC

PP

CCI

{b3, b8}

{b4, b8}

{b5, b8}CFI

PP

CCI

{b3, b9}

{b4, b9}


{b5, b9}FI

PP

CCI

CFI


FI

Writing Report

{b10} ......

.

.

.

Figure 10

4.5 DESIGNING CHANGES

Frequent recurrent exceptions may also require that the workflow model ischanged in order to minimize their impact on the future instances. For example,the Credit Office director—analyzing all the Credit Procedure instances of the lastthree months—discovers that most of rejection cases were due to the discovery of

21

some ‘Financial Insolvencies’ (the path followed by the various instances is easilyvisible using the WSM representation). Therefore, she decides that the analysis ofthe ‘Financial Insolvencies’ needs to be performed as soon as possible in order toavoid performing unnecessary activities, such as ‘Checking external Credits’ incase of client’s insolvency. The workflow model is changed accordingly—seeFigure 11b—modifying the order of execution of the two activities (i.e. swappingthem).




PerfectingPractice


CeC

CeC

PP

CCI

CFI

PP

CCI


FI

PP

CCI

CFI


FI

Writing Report

.

.

.




PerfectingPractice


CeC

CeC PP

CCI

CFI

PP

CCI


FI

PP

CCI

CFI


FI

Writing Report

..

.

a b

Figure 11.

In order to increase the efficiency of the procedure immediately, the CreditOffice director wants the new model to be enacted in all already running instances(dynamic change). In this case it is critical to know if an instance can be movedautomatically on the new model or not (i.e. if it is in a safe state or not). In thisparticular case—among all possible states of the running instances—there areonly three unsafe states (the three shaded states in Figure 11a). Therefore themajority of the instances can be safely moved and continued in the new model(Figure 11b), while those in one of the three unsafe states continue in accordancewith the old model until they reach a safe state.

Later, thanks to new available employees, the bank decides to further improveefficiency by augmenting the concurrence among activities. Therefore it opts toput the ‘Checking external Credits’ activity and the ‘Checking FinancialInsolvencies’ and ‘Further Investigation’ sequence of activities in parallel. In thiscase all the states of the original procedure are safe states with respect to thischange; that is, all running instances can be safely moved in the new model. TheWSM of Figure 12 shows the effect of this change to the original WSM (seeFigure 5)—in the cube only the most external edges are labeled, since everyparallel arc has the same label.

22




PerfectingPractice

Further Checking FinancialInsolvencies

Writing Report

..

.

Investigations

external CreditsChecking

Figure 12.

4.6 INTEGRATION IN THE PLATFORM

As already said, the MWMS is a component of the MILANO system. Its usersadopt it within the cooperative environment offered by MILANO. This means thatthe user can obtain several more services from the system: she can move from aworkflow to the communication environment of the cooperative process where ithas been enacted for reading and/or writing some messages; she can move fromone cooperative process to another where she has received an important message;she can check her mailbox or her to do list, etc.

It is not the case here to enter into detail about the integrated support MILANOoffers cooperative processes (Agostini et al., 1997). However, in order to fullyunderstand the main features and peculiarity of the MWMS, it is important tounderstand that it allows its users to act while being situated in the cooperativeprocesses where they are involved—thanks to the ‘immersion’ and integration ofthe MWMS in a complete CSCW system.

5. Conclusion

The prototype of the MILANO workflow management system we have developedhas proved its effectiveness in offering its users a large variety of services. Thereader may object that this result has be achieved at the expense of simplifyingtoo much the workflow models supported by it. The question is legitimate, sincethe small sub-class of Elementary Net Systems on which it is based does allowneither loops nor intricated flows. Nevertheless, it has to be observed that: on theone hand, intricated flows should be avoided in the design of workflow modelsand their occurrence is generally due to changes involving a section of the modelwhere both loops and concurrency occur; on the other hand, the partial order ofprogressing activities represented in the model allows to generate any loops with

23

no loss of generality (if some of them are forbidden, this is due to organizationalreasons; see section 3.2 above).In any case, even if we are convinced that our solution does not suffer of severelimitations, only the verification on real work settings will allow us to getevidence of our intuition.

In 1999 the National Research Program on “Intelligent Agents: Interaction andKnowledge Acquisition” has gotten underway creating the context where thedevelopment of a second release of the MILANO system is planned. This offers usthe possibility of both completing and renovating its workflow managementcomponent. We are following four main research directions:

1. The Safe-Tcl environment has offered us clear guidelines for designing anelegant architecture of the MWMS; however, the performances of our system areinadequate. Moreover, upgrading the system to the newest versions of the TCLlanguage—which includes many (but not all) features of the previously externalSafe-Tcl library—will entail a careful analysis in order to maintain the opennessof MILANO architecture. Therefore, we are analyzing the possibility ofreimplementing MILANO-2 in Java, to get most of the advantages of Safe-Tclwhile (probably) gaining in performance.

2. The current demonstrative prototype of the MWMS does not have a designenvironment helping organizational designers without programming skills todefine workflows. The new release will offer workflow designers a designframework where they can design both workflows and activities. Moreover, usinga system for the visualization of graph-based models (Bertolazzi et al., 1995),both (WNM and WSM) graphical representations of a changed workflow will beautomatically computed. In developing this module, we need to deal with theproblems emerging from the partial visualization of almost chaotic graphs, whichrepresent highly concurrent workflows.

3. In the organizational handbook of MILANO-2 (MOR), we need two componentsstoring both the workflows and the activities, so that their reuse will be possibleand well supported.

4. Finally, since MILANO-2 will be a more complete prototype ranging beyond thedemonstration of the feasibility of some ideas, it will allow us to observe how it isused in order to evaluate its ability to offer adequate services in differentsituations (in particular with respect to the rigidity issue).

Acknowledgments

A short preliminary version of this paper was presented at the workshop“Towards Adaptive Workflow Systems” (Klein et al., 1998). Its final version hasbeen greatly improved on the basis of suggestions by three anonymous reviewerswho carefully read it and indicated where more clarification was needed.

24

Development of MILANO began within the Esprit BRA Project COMIC 6225and is currently continuing with the financial support of the Italian Ministry ofUniversity and Research within the National Research Program on “IntelligentAgents: Interaction and Knowledge Acquisition”.

Special thanks are due to all the students who have participated in thedevelopment effort: Roberto Tisi, Paolo Bertona, Pietro Nardella and MarioManzoli.

References

Abbott, Kenneth R., and Sunil K. Sarin (1994): Experiences with Workflow Management: Issuesfor the Next Generation. In R. Furuta and C. Neuwirth (eds.): CSCW’94. Proceedings of theConference on Computer Supported Cooperative Work, Chapel Hill, NC, October 22-26, 1994.New York, NY: ACM Press, pp. 113-120.

Agostini, Alessandra, and Giorgio De Michelis (1998): Simple Workflow Models. In WorkflowManagement: Net-based Concepts, Models, Techniques and Tools, Computing Science Report98/07, Eindhoven, The Netherlands: Eindhoven University of Technology, pp. 146-164.

Agostini, Alessandra, De Michelis, Giorgio, Grasso, Maria A., and Stefano Patriarca (1994):Reengineering a business process with an innovative Workflow Management System: a CaseStudy. Collaborative Computing, vol. 1, no. 3, pp.163-190.

Agostini, Alessandra, De Michelis, Giorgio, and Maria Antonietta Grasso (1997): RethinkingCSCW systems: the architecture of MILANO. In J. Hughes et al. (eds.): ECSCW’97.Proceedings of the Fifth European Conference on Computer Supported Cooperative Work,Lancaster, UK, September 7-11, 1997. Dordrecht, The Netherlands: Kluwer AcademicPublishers, pp. 33-48.

Badouel, Eric, and Philippe Darondeau (1998): Theory of Regions. In W. Reisig and G. Rozenberg(eds.): Lectures on Petri Nets I: Basic Models. LNCS 1491, Berlin, Germany: Springer Verlag.

Badouel, Eric, Bernardinello, Luca, and Philippe Darondeau (1997): The synthesis problem forelementary net systems is NP-complete. Theoretical Computer Science. No. 186, pp. 107-134.

Bernardinello, Luca (1993): Synthesis of Net Systems. In Application and Theory of Petri Nets,LNCS 691, Berlin, Germany: Springer Verlag, pp. 89-105.

Borgida, Alex, and Takahiro Murata (1999): Tolerating Exceptions in Workflows: a UnifiedFramework for Data and Processes. In D. Georgakopoulos, W. Prinz and A. L. Wolf (eds.):WACC’99. Proceedings of the International Joint Conference on Work Activities Coordinationand Collaboration, San Francisco, CA, February 22-25, 1999. New York, NY: ACM Press, pp.59-68.

Borenstein, Nathaniel S. (1992): Computational Mail as Network Infrastructure for Computer-Supported Cooperative Work. In J. Turner and R. Kraut(eds.): CSCW’92. Proceedings of theConference on Computer-Supported Cooperative Work, Toronto, Canada, October 31-November 4, 1992. New York, NY: ACM Press, pp. 67-74.

Borenstein, Nathaniel S. (1994): Email with a Mind of Its Own: The Safe-Tcl Language forEnabled Mail. In Proceedings of the IFIP WG 6.5 Conference on Upper Layer Protocols,Applications, and Architectures, Barcelona, Spain, June 1994.

Bowers, John, Button, Graham, and Wes Sharrock (1995): Workflow from Within and Without:Technology and Cooperative Work on the Print Industry Shopfloor. In H. Marmolin, Y.Sundblad and K. Schmidt (eds.): ECSCW’95. Proceedings of the Fourth European Conferenceon Computer Supported Cooperative Work, Stockholm, Sweden, September 10-14, 1995.Dordrecht, The Netherlands: Kluwer Academic Publishers, pp. 51-66.

De Michelis, Giorgio (1997): Work Processes, Organizational Structures and CooperationSupports: Managing Complexity. Annual Reviews in Control, vol. 21, pp. 149-157.

25

De Michelis, Giorgio, and Clarence A. Ellis (1998): Computer Supported Cooperative Work andPetri Nets. In W. Reisig and G. Rozenberg (eds.): Lectures on Petri Nets II: Applications,LNCS 1492, Berlin, Germany: Springer Verlag.

De Michelis, Giorgio, and Maria A. Grasso (1994): Situating conversations within thelanguage/action perspective: the Milan Conversation Model. In R. Furuta and C. Neuwirth(eds.): CSCW’94. Proceedings of the Conference on Computer Supported Cooperative Work,Chapel Hill, NC, October 22-26, 1994. New York, NY: ACM Press, pp. 89-100.

De Michelis, Giorgio, Dubois, Eric, Jarke, Matthias, Matthes, Florian, Mylopoulos, John,Papazoglou, Michael P., Pohl, Klaus, Schmidt, Joachim W., Woo, Carson, and Eric Yu (1998):Cooperative Information Systems: A Manifesto. In Papazoglou, M. P., and G. Schlageter (eds.)(1998): Cooperative Information Systems: Trends & Directions, New York, NY: Academic-Press, pp.315-363.

De Michelis, Giorgio, Dubois, Eric, Jarke, Matthias, Matthes, Florian, Mylopoulos, John, Schmidt,Joachim W., Woo, Carson, and Eric Yu (1998b): A Three-Faceted View of InformationSystems: The Challenge of Change. Communications of the ACM, vol. 41, no. 12, pp. 64-70.

Dourish, Paul, Holmes, Jim, Mac Lean, Allan, Marqvardsen, Pernille, and Alex Zbyslaw (1996):Freeflow: Mediating Between Representation and Action in Workflow Systems. In M. S.Ackerman (ed.): CSCW’96. Proceedings of the Conference on Computer SupportedCooperative Work, Cambridge, MA, November 16-20, 1996. New York, NY: ACM Press, pp.190-198.

Ellis, Clarence A., Keddara, Karim, and Grzegorz Rozenberg. (1995): Dynamic Change withinWorkflow Systems. In N. Comstock and C. Ellis (eds.): COOCS’95. Proceedings of theConference on Organizational Computing Systems, Milpitas, CA, August 13-16, 1995. NewYork, NY: ACM Press, pp. 10-21.

Klein, Mark, Dellarocas, Chris, and A. Bernstein (eds.) (1998): Towards Adaptive WorkflowSystems. Workshop within the Conference on Computer Supported Cooperative Work, Seattle,WA, 14th November, 1998.

Koulopoulos, T. M. (1995):The Workflow Imperative. New York, NY: Van Nostrand Reinhold.Nielsen, Mogens, Rozenberg, Grzegorz, and P. S. Thiagarajan (1992): Elementary Transition

Systems. Theoretical Computer Science, vol. 96, no. 1, pp. 3-33.Norman, Donald A. (1991): Cognitive Artifacts. In J. M. Carroll. (ed.): Designing Interaction.

Psychology at the Human computer Interface, Cambridge, UK: Cambridge University Press,pp. 17-38.

Papazoglou, Michael P., and Gunter Schlageter (eds.) (1998): Cooperative Information Systems:Trends & Directions, New York, NY: Academic-Press.

Reisig, Wolfgang, and Grzegorz Rozenberg (eds.) (1998): Lectures on Petri Nets I: Basic Models.LNCS 1491, Berlin, Germany: Springer Verlag.

Reisig, Wolfgang, and Grzegorz Rozenberg (eds.) (1998b): Lectures on Petri Nets II: Applications.LNCS 1492, Berlin, Germany: Springer Verlag.

Rozenberg, Grzegorz, and Joost Engelfriet (1998): Elementary Net Systems. In W. Reisig and G.Rozenberg (eds.): Lectures on Petri Nets I: Basic Models. LNCS 1491, Berlin, Germany:Springer Verlag.

Schael, Thomas, and Buni Zeller (1993): Workflow Management Systems for Financial Services.In S. Kaplan (ed.): COOCS’93. Proceedings of the Conference on Organizational ComputingSystems, Milpitas, CA, November 1-4, 1993. New York, NY: ACM Press , pp.142-153.

Schmidt, Joachim W., and S. Ziemer (1998): The Maps, Tabs and TiX (MTX) - Model: A“Transport” Approach to Workflow-Modeling. Talk within the Workshop of the CIS project,Varese, Italy.

Schmidt, Kjeld (1997): Of maps and scripts: the status of formal constructs in cooperative work. InS. C. Hayne and W. Prinz (eds.): GROUP’97. Proceedings of the International ACMSIGGROUP Conference on Supporting Group Work, Phoenix, AR, November 16-19, 1997.New York, NY: ACM Press, pp. 138-147.

26

Schmidt, Kjeld, and Liam Bannon (1992): Taking CSCW Seriously: Supporting ArticulationWork. Computer Supported Cooperative Work (CSCW). An International Journal, vol. 1, nos.1-2, pp. 7-40.

Schmidt, Kjeld, and Carla Simone (1996): Coordination mechanisms: Towards a conceptualfoundation of CSCW systems design. Computer Supported Cooperative Work. The Journal ofCollaborative Computing, vol. 5, nos. 2-3, pp.155-200.

Suchman, Lucy (1987): Plans and Situated Actions. The problem of human-machinecommunication. Cambridge, UK: Cambridge University Press.

Swenson, Keith, Maxwell, R. J., Matsumoto, T. Saghari B., and K. Irwin (1994): A BusinessProcess Environment Supporting Collaborative Planning. Collaborative Computing, vol. 1, no.1, pp. 15-34.

van der Aalst, W. M. P. (1998): Finding Errors in the Design of a Workflow Process. A Petri-net-based Approach. InWorkflow Management: Net-based Concepts, Models, Techniques andTools, Computing Science Report 98/07, Eindhoven, The Netherlands: Eindhoven Universityof Technology , pp. 60-81.

White, Thomas E., and Layna Fischer (eds.) (1994): The Workflow Paradigm. Alameda, CA:Future Strategies.

Winograd, Terry, and Fernando Flores (1986): Understanding Computer and Cognition: A NewFoundation for Design. Norwood, N.J.: Ablex Publishing Corp.

27

i The algorithm to build the WSM corresponding to a WNM is based on a synthesis algorithm

for ENS by Luca Bernardinello (1993). This algorithm has been proved to be NP-complete(Badouel et al., 1997) and therefore impractical in real applications. However, a WNM can besynthesized from a WSM through a polynomial algorithm (in the size of the set of states of theWSM) (Agostini and De Michelis, 1998), so that the switch between the two representations iscomputationally feasible.

ii Using map composition, we search for the existence of a morphism between the new and theold model see (Agostini and De Michelis, 1998).

A Light Workflow Management System Using Simple Process Models

Documents

Transcript of A Light Workflow Management System Using Simple Process Models