not cover all: they focus either on supporting changes (see for instance (Swenson ..... In this case, in fact, any program embedded in a message cannot be ...
A light workflow management system using simple process models
∗
Alessandra Agostini, Giorgio De Michelis Cooperation 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 as productivity tools, e-mail systems and groupware platforms have. We believe that this fact is due to the many limitations of current workflow technology (weak support for changes; complex exception handling mechanisms; limited openness to and integrability with other system components; ...) and that radically new workflow management systems should be designed and developed in order to offer adequate products to the market. In this paper we outline the main innovative features of the workflow management component of the MILANO system making it highly flexible and adaptable. A particular attention is paid to its modelling framework which is based on a class of net systems well supported by efficient algorithms and to the services it offers to both workflow designers and actors. The most relevant aspects of the MILANO workflow management system are also illustrated through a realistic example.
1. Introduction For several years workflow management systems have been announced as the next best-selling computer application (White and Fischer, 1994; Koulopoulos, 1995). But up to now they have not attained the success of other packages such as productivity tools, e-mail systems, web-browsers and even groupware platforms. Why do workflow management systems remain in limbo? Almost every observer argues in favor of their utility, yet so few users really apply them within real organizations. While the question has no single simple answer (Schmidt and Bannon, 1992; Abbott and Sarin, 1994), it deserves the attention of anyone interested in the development of workflow technology. A good starting point in this respect, can be the above-mentioned paper by Schmidt and Bannon (1992) which opens the first issue of ‘Computer Supported Cooperative Work: an International Journal’. In it the authors discuss the relevance of articulation work within cooperative work arrangements. Articulation work deals both with the meshing of tasks and performers within a cooperative ∗ To appear on “Computer Supported Cooperative Work. The Journal of Collaborative Computing”
1
work process and with the interleaving of different processes within the work time of a performer. Moreover, it deals with the continuous changes of cooperative work arrangements. Therefore, systems supporting articulation work must on the one hand liberate workers as much as possible from the routine articulation work they need for coordinating themselves (script); on the other, help them to become aware of the situation where they are performing and to negotiate new cooperative work arrangements whenever a breakdown occurs (maps) (Schmidt, 1997). Finally, they need to be open to continuous changes, in order to support a continuous updating of both their maps and their scripts. Most current workflow management systems offered in the market focus only on the first of the above requirements, giving a limited support to the other two. Also, most workflow management systems under development in private and public research centers do not cover all: they focus either on supporting changes (see for instance (Swenson et al., 1994)) or on supporting maps (e.g., Dourish et al., 1996)). Kjeld Schmidt and Carla Simone have proposed a comprehensive approach for supporting articulation work. In particular, they have provided an environment for the design of any sort of coordination mechanisms—based on a sophisticated modeling system (Schmidt and Simone, 1996). In this paper we propose a different solution on the basis of some architectural and modeling considerations. Let us say a few words about them. 1. Workflow management systems need to be integrated with the tools the actors of a process use to perform within it: productivity tools; specialized technical support systems—CAD systems, graphic packages, software environments, etc.; information systems and data bases; but also mail systems and other communication systems. It is not conceivable that integration is reached developing a unique comprehensive framework embodying them all. In fact, on the one hand, users have already made their choice of those systems and usually resist changing their tools for new ones just to get some support for their articulation work; on the other, the creation of complex applications always creates more difficult obstacles to both opening collaboration to new workers and changing cooperative work arrangements. Therefore workflow management systems are not applications (that the actor opens 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 a fully integrated component of the cooperative information system (see above), focusing on the coordination among different activities and leaving to other components the duty of performing them, while avoiding to introduce any constraint to the interaction with other systems. From the organizational point of view, the workflow management system must support and make visible the workflows: defining part of the rules, roles and procedures characterizing the company and/or institution where it is used; offering to its users the automation of the routine tasks; helping them to deal with exceptional situations and breakdowns (Borgida and Murata, 1999); providing the distribution of decision tasks among the users (in accordance with their roles);
2
simulating their performances under diverse resource allocations; giving full support 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 the workspace of their users supporting their performances; for instance, making the workflow transparent when they are already capable of doing the requested activity; making the workflow visible when they need help in understanding what to do, as well as when a breakdown requires them to negotiate a new cooperative work arrangement. 2. The relevance of workflow technology has grown jointly with the emergence of process oriented organizations and the related change management techniques (e.g., business process reengineering and continuous process improvement; White and Fischer, 1994). Therefore, as already claimed above, any workflow management system should be oriented to making the organization as flexible as possible and to supporting its changes. On the one hand therefore, workflow management systems should allow end-users themselves (given appropriate authorization) to change the flow of work, jumping back and forth within the workflow model, in order to let them handle exceptions and breakdowns effectively without changing it. On the other, changes of the workflow model should 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 workflow instances. In conclusion, workflow management systems should get their flexibility both from the ease of dynamically changing them and from their not needing continuous frequent changes of the model (due to the possibility of endusers of changing the flow of work of a workflow instance without changing its model). With respect to these features, most existing workflow management systems appear to be inadequate. It is difficult to interrupt them, to exit their normal flow and then reenter it. Meanwhile breakdowns are very frequent (they are the norm in many cases). They are based on complex and sometimes multiple process models (integrating data models, normal and exceptional flows, role descriptions) whose changes need careful and time consuming analysis. They need to be designed by expert programmers, introducing a time delay between process and workflow changes. They do not support multiple viewpoints on the process, corresponding to the various actors with the different objectives and roles they support (the managers and those who have to control and evaluate the process execution, the task performers and, why not, the customers waiting for its outcomes). Many observers have also argued that most workflow management systems make business processes too rigid, not allowing their users to react freely to the breakdowns occurring during their evolution (Bowers et al., 1995). Some seem to blame the responsibility of this rigidity on their using formal workflow models (formal models canot fully capture the knowledge people use while acting within a business process); others on the strict coupling between modeling and executing they introduce (models should be cognitive artifacts; Norman, 1991; not constraining the behavior of the actors; Suchman, 1987; Dourish et al., 1996). We
3
agree with the above points. However, we are convinced that the rigidity of existing workflow management systems should be attributed neither to their using formal models nor to their coupling of modeling and execution; on the contrary, it is caused by the above-mentioned weaknesses affecting them. We argue in this paper that—in contrast to common belief—formal theorybased models can contribute to the solution of the above problems; but if, and only if, they are conceived from a different perspective. In fact, good algebra offers effective tools for creating a process modeling environment exhibiting the following 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 to keep workflow models as simple as possible. That is, to use a divide et impera approach to the workflow, treating in a distinct way: the execution of the tasks embedded in the workflow steps; the data flow; the control flow, the latter being the only issue to be handled directly by the workflow management system. It has to be underlined that simplifying the workflow models in accordance with the above crtierion does not simplify (and therefore impoverish) the flow of work of any process instance; therefore, any rigidity still remaining in the system should be attributed to the organizational constraints reflected in the model and not to the model itself. Using simpler models, which allow jumps, addresses the problem raised by the critics of workflow technology. The development of workflow management systems based on them and the observation of their use in real work settings will show whether or not the proposed solution actually offers an answer to the above criticism. The above considerations have offered the guidelines for developing the prototype of the workflow management component of the MILANO system, a groupware platform supporting its users while performing concurrently various cooperative 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 light architecture gives it a high degree of openness (section 2); and its simple modeling environment makes changes rare and easy to design (section 3). The functionality and the interaction modes allow its users to cooperate with an
4
adequate degree of support with respect to their articulation work—as shown through a scenario-like example derived by a real bank procedure (section 4). Some open problems and further research directions are discussed in the conclusion.
2. The architecture As anticipated in the Introduction, the MILANO workflow management system (MWMS) is part of a groupware platform. The MWMS architecture cannot be described in isolation. Rather, we must briefly recall some issues of the complete MILANO platform (Agostini et al., 1997) to explain the workflow component adequately.
2.1. A CSCW PLATFORM In 1994 at the Cooperation Technologies Laboratory the authors—together with Maria Antonietta Grasso and several students—began development of the prototype of a new CSCW system, called MILANO (De Michelis and Grasso, 1994; Agostini et al., 1997). Successively, they kept on developing it when free from other more urgent duties. MILANO is a CSCW platform supporting its users so that they can remain aware of the history they share with the actors with whom they cooperate and of the activities they are committed to perform in the future. The perspective from which we observe work practices can be considered a Situated Language-Action Perspective (Suchman, 1987; Winograd and Flores, 1986; De Michelis and Grasso, 1994). MILANO integrates into the user workspace a workflow management system (MWMS) with a multimedia conversation handler (MCH) and also an object repository (MOR) where an organizational handbook is stored. Workspace
MCH Mailbox
To Do List
MWMS
MCH
Application Environment
Execution Environment
MOR
Safe-Tcl Interpreter
e-mail
TCP-IP
Figure 1. The overall architecture of the MILANO system
As components of a single platform, the MWMS and MCH are fully integrated and allow both opening a conversation from within a workflow and enacting a workflow from within a conversation. The former possibility characterizes the exception handling mechanism of the MWMS (therefore it will be discussed in the next sections of this paper); the latter—i.e. enacting a workflow from within a
5
conversation—allows us to embed any workflow within a customer-performer relation as if it were a (computer-based) artifact characterizing their cooperative work 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 she wants, the user can abstract from the history both a communication flow and an action flow. Finally, it is relevant to say that the workflow models of an organization are stored in its MOR component. The above sketched architecture can be characterized well by means of the previously cited three faceted architecture of cooperative information systems (De Michelis et al., 1998b): integration among MWMS, MCH and MOR is an issue regarding the system facet; both the workflow models and their enacted instances are relevant from the organizational facet viewpoint; and the mutual enactment between 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 actors leave it while other new actors join it. Moreover, the various actors have different levels of engagement in it at different moments. Finally, some people participate only occasionally in the work process. Therefore in a particular work process there 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 the WMS is integrated—should adapt itself to the above variety of human behaviors with the maximum degree of plasticity in order to avoid constraining its users. To reach this goal, the system should first and foremost be able to support interaction between people having the system and people not having it—let us call this capacity of a system openness. MILANO uses the computational mail model (Borenstein, 1992) to obtain openness (the Safe-Tcl environment (Borenstein, 1994) has been used). Thus the e-mail messages can be automatically manipulated when they are sent and/or received; and, in particular, they are computational since embed programs other than data. With computational mail, for example, messages can bring the execution environment and the data necessary for reacting to them. E-mail is often recognized as one of the most successful groupware applications (after fax and telephone). Moreover, the use of e-mail as a distribution model makes the group boundaries inherently dynamic, providing contemporaneously different degrees of participation. Therefore e-mail is a natural candidate to be the middleware for groupware, that is, its enabling technology. The resulting architecture of MILANO—for more detail see (Agostini et al., 1997)—supports, with different levels of service, cooperation between three types of actors: those having the MILANO system; those having the Safe-Tcl interpreter; and those just using e-mail (see Figure 2).
6
Milano
Safe-Tcl MCH Mailbox
To Do List
Mailbox
MWMS
E-mail Mailbox
MCH MOR
Safe-Tcl Interpreter
e-mail
Safe-Tcl Interpreter
TCP-IP
e-mail
TCP-IP
e-mail
TCP-IP
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 the full set of services offered by it, the other cases require further discussion. The actor having a Safe-Tcl interpreter is still provided with a meaningful subset of functionality (see section 4.3 for an example), since MILANO messages embed data and source code that the interpreter executes on destination sites for interacting with MILANO users. Some of the functions provided are: notification of activities to be performed; visualization of the context of an activity; complete handling of the action flow (e.g., calculation of the next step, routing of the involved 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 with useful 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 so the user can only read it. This is why messages always contain, at the beginning of the message, a user-readable ‘textual’ part giving all relevant information: the description of the activity to be executed; the information to be produced; the instructions on how to answer the message, and so forth. Of course, the previously produced documents—necessary for the exploitation of the activity—are enclosed in 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-mail adresses are activable items). Moreover, in order to handle the flow of information, messages embed a form-like part for filling in some information. To carry on the procedure—after concluding her task—the user must reply to the message enclosing all modified or new documents and checking the ‘completed’ choice (in the form-like part of the message). A specific MILANO agent at the receiver’s workstation—usually the workstation of the person in charge of the procedure—is automatically activated to parse and elaborate the message; this is to completely update the status of the procedure as well as to calculate the next step(s) of the procedure. Both the information provided by the user and the system information included in the heading of the message (e.g. identification numbers of the activity and its procedure) are used for elaborating it.
7
The MILANO user in charge of the successive activity does not see any difference with respect to the other two cases (i.e. when an activity is executed using MILANO or the Safe-Tcl interpreter). Finally, the content of the message allows basic handling of those cases in which the user is unable to complete the activity. In fact, while replying to the message, the user can choose—within the form-like part of the message—from among general reasons for not accomplishing her task (e.g. requesting delegation, asking for missing information, etc.). However, in these cases a human agent will receive the message only partially elaborated by MILANO.
2.3 THE PROCESS MODELING FACILITY As in many workflow management systems, coordination among the activities of a workflow is managed by the MWMS by means of its formal model. We have chosen a class of Petri Nets (Reisig and Rozenberg, 1998) as the theoretical framework for building process models. More specifically, since we have decided to keep the control flow separate from the activities coordinated by it, we could choose 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 graphical representations of a process. Rather, they also offer a sound theoretical framework for supplying a large variety of services to the users of a process model: generating multiple different representations of a workflow; computing exceptional paths on the basis of the regular workflow; checking the correctness of a workflow change and enacting it within all the ongoing instances of that workflow. With respect to exceptional paths, the process modeling facility is complemented by a powerful undo mechanism (for backward jumps) and an agent generating the form to be filled in order to have all the needed information at a given state (for forward jumps). Both these mechanisms, implemented up to now only with respect to form managing workflows, need to be extended also to those interacting with the information system. The process modeling facility of the MWMS delivers its services not only to the 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 as well as visualizing different categories of jumps allowed in a given state - see next section), to the design environment (checking the correctness of any newly designed workflow with respect to its minimal critical specification), and to the enactment mechanism (separating the ongoing instances that are and are not in a safe state). Therefore, the process modeling facility of the MWMS is an important component contributing to its usability, effectiveness and flexibility. More about the formal properties of the workflow models of the MWMS can be found in (Agostini and De Michelis, 1998) and in the next section.
8
3. The process model As already indicated in previous paragraphs, MILANO is based on the idea that workflow models must be as simple as possible. On the one hand in fact, process designers should be able to describe a work process even if they have little or no experience with formal languages and mathematical theories; that is, the theoretical model should be simple to learn while providing an easy to understand representation. On the other hand, they should be allowed to give a minimal input in designing the workflow, disregarding all unnecessary details, even if they get back 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 just few objects and concepts need to be understood for representing the dependencies between activities as well as their parallelism and/or branching. To obtain the second goal—that is, simplify the design of the workflow without diminishing expressiveness of the model—we allow process designers to disregard at the design phase all possible exceptions and/or breakdowns which usually occur during the execution of a work process; in other words, the user can design the plan as a partial order of progressing activities (steps). This has been achieved by coupling and exploiting two architectural characteristics of the MILANO workflow: the integration of communication and action (see section 2.1) and the mathematical basis (in particular, the algorithm for computing exceptional paths see section 3.2). Without the constraint of taking into account exceptions as well as all possible repetitions of parts of the process, we are able to reduce the Elementary Net System category to a simpler subcategory: namely Free-Choice Acyclic ENS. In general, the workflow can be defined without using cycles or loops (i.e. it is acyclic); and when there are various alternatives (i.e. choices) the branch to be followed is locally computable, since the choice does not depend on external processes (i.e. it is free). Thanks to the above restrictions our class of net systems is supported by efficient algorithms; in particular, the synthesis of a net system from a sequential transition system is polinomial, while for generic ENSs it is NPcomplete (Badouel et al., 1997). Finally, in order to handle big workflows, consisting of a large number of activities, it is possible to design the model as a hierarchy of Free-Choice Acyclic ENS 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 its mathematical basis—is the capacity to provide to its users different representations of the workflow, as well as to freely allow the switching among them. In particular, two main representations are offered: the first, called Workflow Net Model (WNM), is based on Elementary Net Systems (Rozenberg and Engelfriet, 1998); while the second, called Workflow Sequential Model
9
(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 a representation making explicit the local conditions characterizing any state of the workflow; for example, the independence between two activities is easily visible because independent activities have disjoint pre-conditions. On the contrary, the Workflow Sequential Model describes a workflow as a sequential automaton where activities are connected by global states (Figure 5b); for instance, the sequential path followed during the execution of an instance is traced as a line and therefore it is useful for having a global view of the workflow. In particular, the WNM representation can be used by the performers of a work process while focusing on the activity they have to do and on its pre- and postconditions. Instead the WSM view is more useful for supporting a managerial view of the process (e.g. showing the state reached by all its instances), as well as for helping exception handling (showing to which states an instance can jump; see next 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 sequential behavior is equivalent to it, switching from one representation to the other can be automatically supported by the system (Nielsen et al., 1992) and consequently, the i switch between the WNM and WSM can be computed whenever necessary . While hierarchical models allow us to keep WNMs small, they don’t prevent us from having a state space explosion in the WSMs of highly concurrent workflows. The problems related to the graphical visualization of large WSMs (multi-dimensional graphs of WSM will appear as intricate and difficult to read graphs) are not considered in this context. They will be discussed briefly in the Conclusion.
3.2. EXCEPTIONS AND LOCAL CHANGES Our theoretical framework allows us to create additional paths (jumps) connecting two states of a workflow, as if the partial order of progressing activities were a minimal set of generators of all the paths connecting its states. Moreover, the framework allows us also to distinguish various categories of jumps, so that different jumps (exceptional paths) can be associated to different responsibilities. Whenever the performer of an activity in a workflow cannot act in accordance with the model, she can jump (either forward or backward) to another state from which the execution can progress again. The creation of jumps is performed through the computation of process extensions 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 different criteria: first, from the viewpoint of their direction between forward and backward jumps; second, from the viewpoint of the number of tokens they move in the WNM.
10
Forward and backward jumps address complementary and opposite needs: the forward jumps cause the skipping of some activities while the backward ones involve going back—in some previous state of the workflow—for re-executing or perfecting some activities. With respect to the second criterion—taking into account that jumps are activated by one actor when a breakdown occurs—we want to avoid her interfering with the activities of the other actors which are going on concurrently and are therefore beyond her control, except for blocking them. Therefore, the MILANO workflow management system allows either to move one single token in the 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 state with a lower degree of concurrency). It has to be underlined that the two allowed categories of jump can be visualized efficiently through a partial representation of the WSM, where only one line of the graph describing the concurrent activities needs to be represented. This avoids state space explosion and offers users a clear picture 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 forward jumps (see section 4.4 for an example), where we call strongly linear jumps those which move only one token in the WNM and weakly linear jumps those which cancel two or more tokens and write one token in the WNM. The MILANO workflow management system allows us to associate to each of these classes a different responsibility, in accordance with the roles and rules of the organization: for example, forward jumps and weakly linear jumps may need the authorization of the process owner, while strongly linear backward jumps are under the responsibility of the actor herself. Other policies may also be defined and embedded in the organizational handbook component of MILANO (MOR). When a breakdown occurs, MILANO offers the user the possibility of seeing all the jumps of one of the above categories, so she can choose one of them. The authorization for it, if needed, is requested and discussed within a conversation with the responsible role that MILANO opens automatically. Within this conversation, it is also possible to assign to any actor some specific tasks (e.g. in order 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 the workflow. 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 choose how to solve a breakdown (e.g. an insufficiency of a process description). Furthermore, the framework supports workflow designers when they need to change the structure of a process. We assume that a workflow model is a specific organizational choice with respect to a minimal critical specification defining what it must in any case do;
11
when no explicit minimal critical specification is given, then by default the ndimensional graph allowing any order in the execution of the activities is considered. Changes of a workflow model are correct if and only if: on the one hand, they have no deadlocks; and on the other, they are consistent with the minimal critical specification. While many approaches for checking change correctness support only deadlock-freeness—see for instance (Van der Aalst, 1998)—MILANO also evaluates its consistency with the minimal critical specification. In fact, the user can formally define the Minimal Critical Specification (see below and (Agostini and De Michelis, 1998)), using it as a reference for guiding any successive change. The correctness check of a change is made verifying if the morphism from the changed workflow model to the Minimal Critical Specification 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 less constraining than any workflow model correct with respect to it; i.e. it admits the largest class of behaviors. For instance, the Minimal Critical Specification—given a set of n activities and no temporal constraint among them—is a workflow where all the n activities can be executed concurrently; in other words, the WSM representation contains a flow for each possible ordering of the n activities (the MCS defined by default in MILANO). In short, the administrator—in defining the MCS—should insert the causal and temporal constraints among the activities, while avoiding insertion of those constraints related to the actual policy of the organization. However, even if a particular change of the workflow maintains the correctness of the process, when a workflow is instanced a large number of times—as usually occurs, e.g. in banks, insurance companies and public administrations—it is not possible to move all of them to the new model, since some of them may become inconsistent. Sometimes moving all the instances to the new model could be not necessary; however, frequently organizations request it, even at the cost of restarting all of them. Therefore managing new models through a versioning mechanism is not sufficient and dynamic change is the best suitable solution. To face this problem we distinguish in the old model between safe and unsafe ii states with respect to the proposed change . An instance is moved to the new model if and when it is in a safe state; so that it can continue until its correct completion. In practical terms, one running workflow instance is in a safe state if there is a univocally determined image of its state within the new model of the workflow; moreover, moving this instance to the new model (i.e. to the unique state/image within the new model) the workflow can be correctly completed. We would underline that we consider incorrect even those cases where, moving to the new model, some activities should be re-executed. The treatment of dynamic changes we propose is strictly related to the one proposed by Ellis, Rozenberg and Keddara (Ellis et al., 1995). The main difference is that, while Ellis and co-workers move any workflow instance to a new model where unsafe states and paths are preserved in order to avoid
12
inconsistencies, in our approach the move of the instances is delayed until they reach a safe state. Figure 3 summarizes the three main patterns of change allowed by the MILANO theoretical framework, shading the unsafe states: parallelization, making two sequential activities concurrent (Figure 3, a); sequentialization, creating a sequence 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
e1
e2
Parallelization
e2
e1
e1
e1
e2
e2
e2
e1
Sequentialization
a)
b)
Swapping
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 it does 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 framework for modeling processes embedded within it (section 3). A different view on it— focusing on the functionality and interaction modes it offers to its users—may help the reader to understand how both architectural choices and theoretical grounds 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-like example derived from a real credit procedure used within an Italian bank; for a more complete description see (Schael and Zeller, 1993; Agostini et al., 1994). This procedure supports the process through which a customer request for a new credit is managed by a bank. The organizational structure of the bank is sketched in Figure 4, where only people or offices taking part in the credit procedure are shown. In the following a brief description of the organizational roles belonging to the cooperation network is provided.
13
HEADQUARTER Credit office director
Credit office evaluator
Credit office secretariat
EDP centre
Risk centre
Office in charge for ...
...
Resolution body
DISTRICT 1
...
District coordinator
DISTRICT n
...
...
District coordinator
BRANCH 1
BRANCH 2
Agency director
Agency director
Agency credit secretariat
Agency credit secretariat
...
...
BRANCH n
...
Agency director Agency credit secretariat
...
Figure 4. The organizational structure of the bank
The Agency Director—AD in short in the next Figures—is responsible for the agency's overall performance and for commercial development. According to the organizational model of the bank, she is the initiator of the credit procedure. In line with current bank rules, her role is characterized by autonomy and full responsibility in initiating a credit request procedure; her deliberation competence is limited to loans • 50,000,000 Lit. The District Coordinator (DC) has responsibility over the bank budget for credit operations in her area of competence. She is informed on all credit proposals in order to explore new business opportunities. Her deliberation competence is limited to loans • 80,000,000 Lit. The Credit Office director (CO) is an experienced manager. She has the responsibility of assuring a check on credit activities in general. Her deliberation competence is limited to loans • 200,000,000 Lit. The Resolution Body (RB)—that is, the Top Management Council of the Bank—has the deliberation competence on all loans > 200,000,000 Lit. In the credit procedure the client interacts with the Agency Director (AD) who is responsible for the whole procedure. After a preliminary informal investigation, where the client motivation is exploited, the documents the clients provides to support her request are collected and two parallel processes start: in the first, the information 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 has any insolvency or any other critical financial situation. The two processes join when a report on the credit request is written. At this point the decision process starts 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 a credit 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; the Resolution Body—RB) have to write the credit proposal and/or decide upon its approval. If the credit proposal gets the corresponding approval, the client receives 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
14
information can be obtained from several sources, which can be internal or external to the bank.
4.2. MULTIPLE REPRESENTATIONS As already explained in previous paragraphs, a workflow is a resource used by different persons with different goals and needs. Therefore, it is an impassable road trying to provide a single representation of it, since the latter becomes unreadable if it contains all the information needed by all of them. Moreover, even the greatest (graphical) representation is not suitable for all various situations. In the current implementation of MILANO, the users are allowed to view the model of a workflow in two complementary representations (i.e. the WNS and the WSM models; see section 3); however, we are investigating the possibility of adding further graphical views (see for instance (Schmidt and Ziemer, 1998)). The first representation—that is, the Workflow Net Model, see Figure 5a showing the Credit Procedure—is usually used in the bank for teaching the organizational procedures to the newcomers. In fact, in the Net both the activities making up a procedure and their interdependencies (concurrency, temporal and causal dependencies, etc.) are clearly visible. Moreover, the performers of the activities—since they are involved contemporaneously in many instances of different procedures—are in the habit of looking at the Net representation when they need to understand what to do. b1 Exploitation of Client Motivation b2 Collecting Client Documents b6 Checking external Credits
b3 Collecting Client Information
{b1}
b7
Exploitation of Client Motivation
Checking Financial Insolvencies
b4 Perfecting Practice
{b2} Collecting Checking Client Documents external Credits
b8 Further Investigation
b5
b9
Collecting Client Information
Writing Report
{b4, b6}
AD:Seconding Request
AD: Writing Proposal (=
