Motown: A Practical Approach to Workflows

Workflow management systems (WFMS) are intended to improve business processes in terms of analysis and of automation. Our approach, based on a realistic development life cycle, indicates the modeling and implementation requirements to speed up the development of workflows applications (mainly administrative and ad-hoc workflows [5]). This paper presents both our methodology and tool to support this lifecycle for human-oriented workflows [8].


Introduction
Diagram 1 shows a realistic development life cycle for workow applications which takes into account the work ow e v olution that will undoubtedly occur. 1

.1 Business process elicitation
This step is to identify and understand the processes of an organisation.This operation leads to mental models shared by all the people involved at this stage.The mental models are the organisational analysts' mental representation of the processes.Knowledge acquisition methods like those developed by expert system designers are highly suitable here.
Also at Information Systems Department, University of Geneva

Business process modeling
This step is to formalize the mental models in a conceptual model used by designers to perform analysis.We use three levels of process modeling Cf table 1: abstract, descriptive and operational.The mental models are represented at the abstract level to model the objectives of business processes.The descriptive level describes the means involved to full l these objectives.To build a work ow application, the descriptive models are re ned into operational models.The operational models of processes re ect exactly how the work ow application will work.

Work ow analysis
This step is to test the work ow speci cation and often highlights modeling errors and misunderstandings about business processes or between the analysts.The analysis may change the perception and objectives of the processes.This reconceptualisation may also modify either the abstract, the descriptive, or the operational models.
When the process representation does not evolve a n y more, a new series of tests is suitable, like bootlenecks detection or time cost simulation, for instance.

Work ow implementation
This step is to transform operational models of processes into an executable system.To ensure an error-free transformation, it should be fully automated.This approach based upon rapid application development, enables quickly to work and test the application.

Business process re-design
According to the evolution of business processes, possibly coming from daily work with the application, re-design leads to some changes in the experts' mental models.
To support most of these life cycle steps, we h a ve developed two tightly coupled tools: a graphical speci cation editor and a work ow enactment system.The speci cation editor is used to model processes and analyse work ows.
The implementation is fully automated, the target system is Lotus Notes 1 .The work ow enactment system monitors the process execution.
The following sections describe these tools and how they help to manage the business process evolutions.
Since the work ow applications are built on top of a groupware tool, some cooperative w ork and work ows can be mixed.2 The graphical speci cation editor 2.1 Business process modeling Like many w ork ow management systems, our approach o f modeling is activity-based 6 .The conceptual model is an extension of the OSSAD model.OSSAD O ce Support Systems Analysis and Design 3 stems from an ESPRIT project and is widely accepted by those carrying out for large scale o ce work modeling table 1.In our sense, OSSAD is widely accepted because it is not only a set of models, a modeling technique, but a method: OSSAD also provides a set of guidelines for modeling and managing a project 7, 2 .
In order to specify work ows  The abstract level see for example g. 1 3 , 2, 3 serves to specify what is to be done within an organisation.It is based on a breakdown of the organisation into sub-systems according to de ned objectives functions and sub-functions.
The sub-sytems are related to each other and to the environment outside the organisation by a o w of data packets.At the nest level of detail, the sub-functions regroup a number of activities.As the name suggests, the abstract level disregards the support system used to reach the organisation's objectives.The descriptive level concerns the organisational, human and technological support systems which are used to accomplish the organisation's objectives.This level contains two models, namely the procedure m o del and the operation model.The former describes how the information ows between procedures.The latter details a procedure Cf g. 4. It uses the concepts of role, operation, resource and facility cf.glossary.
The operational level extends the procedure model of a descriptive model to specify what is computer-supported as a part of a work ow.For this purpose, we add the concepts of document state and document structure Cf g. 5.The constraint concept is also very useful because an actor usually carries out several roles.We de ne constraints between operations which apply during the same work ow instance.They are of two t ypes, namely "must perform" and "cannot perform", for instance: the actor who performs the operation Fill in must also perform the operation Modify on the same document.the actor who performs the operation Fill in cannot also perform the operation Approve.A set of operational models de nes a work ow application which is implemented by Motown Builder.

Work ow analysis
The analysis, test and debugging of work ow speci cations are mainly based on net analysis and simulation.Crossreferencing analysis is also used to maintain consistency between the three levels of modeling.

Net analysis
Full advantage has been taken here from the fact that the operational models can be translated into Petri Nets.Feasibility c hecks can then be performed using these net representations, in order to identify unusual and unexpected situations in the work ow, as early as at the speci cation.For instance, Motown checks the reachability of operations and states and the liveness of the graph which is the workow model.

Simulation
Moreover, dynamic quanti ed simulations may be launched in order to answer numerous questions about cost, duration, and processes requirements for human or material resources.During the simulation, an animation displays the queues on procedure objects.
A simulation may concern the durations, the costs or both.The parameters of a simulation are: the assignments of actors to roles 4 , the probability for each OR post-condition , the duration and cost of an operation 5 , the duration and cost of a resource.Here, the duration means the time to transmit the resource.the duration and cost of a procedure6 , the values of all parameters, the list of termination points of the procedure, the earliest, latest and average durations, the number of procedure's runs, the number of procedure's ended runs, the minimun, maximum and average costs, the amount of treated operations, resources and documents by state, the amount of uncompleted operations, resources and documents by state, for each role, the number of actors e ectively involved, and the average time of work of actors per role.It is also possible to focus simulations on a particular termination point of a procedure.If a termination point represents a failure of a procedure, we m a y e v aluate for instance, the costs of a failure.
An accurate quanti cation of parameters is required to run a realistic simulation.De ning a pertinent quantication is time consuming and involves a rigorous method to evaluate the durations and costs of operations.If such an e ort is not carried out, the simulations results have n o meaning.Another approach is to implement the work ow application and to use the traces' reports to specify the simulation parameters.A simulation, even if costly to run, is very useful to test the feasibility of procedures designs according to a set of given resources.

Work ow implementation
With Motown, the implementation step of the life cycle is fully automated g. 68 .When the work ow speci cation ful lls the designers' criteria, Motown builds a Lotus Notes base which contains all the processes de nitions.The designer then adds manually the documents structures as Notes Forms.By assigning actors to processes' roles, the Notes base becomes a work ow application which is ready to deploy to all its users.4

Activating and monitoring the ow
From the end users viewpoint, three main features of an application are central to the interactions with the work ow enactment system: Graphical help All the graphical speci cations of processes are available to users, either as an organisational documenta- tion of the application or as an on-line contextual help, when they process a document.
To Do Lists They are used to display the documents which a user has to process.The displayed list takes into account the user's roles, the current state of the documents, and constraints between operations, if any.A w ork ow application may also contain other document views, as in any Notes Base.The Go on action This action 9 is present whenever a user edits a document for which he has to perform some operation.Since we consider human-oriented work ows, not any d o cument modi cation by an actor corresponds to the completion of an operation: the actor has to assert that he achieved some work on a particular document some operation whose input state is the current state of the document.The action Go on of the document is to assert this completion.This action sends the assertion the monitor.The monitor asks information to the work ow meta-model in order to determine the achieved operation and its output state.This query may lead to interactions with the actor: several operations may share the same input-state, or the actor has to choose one of several possible output-states.

Managing the evolution of business processes
Several factors usualy lead to an evolution of business processes.These factors are either external or internal to the process itself.Among the external ones, we m a y cite changes with the legal requirements and regarding organisation, as well as the emergence of new technologies standards like EDI or internet that are requested by customers or suppliers.Other reasons cited in 5 include increasing customer satisfaction and quality of products, as well as meeting new business challenges and opportunities.External factors are usually overriding and they lead to radical re-engineering.
Internal factors come from the daily use of work ows applications.For instance, users may h a ve new ideas to increase the overall process e ciency.The major internal factor is the periodic reports of work ows execution which include workloads, operation completion times and so on.These statistics provide meaningful data to run accurate simulations on process changes.Fr instance: what is the average procedure completion times when we add actors to a role?
The users' feedbacks of a work ow system also highlight problems like unforeseen bootlenecks that result from either the design of the process itself, or unrealistic parameter quanti cations.Internal factors lead to design improvements of the current processes.Iterative and fast re-design and re-implementation tools are thus very useful to such an evolutionary design approach.
Whatever the root cause of the process evolution, workow enactment systems should provide tools to update several running work ows instances.
In a document h uman role -oriented system like Motown, there are three dimensions of changes at the enactment level, which are usually conbined in an evolution: Changes on the relevant documents set of a process, and on document structures.
At the design level, if document t ypes are removed from a process, then, at the enactment level, all the pending operations on documents of these types are stopped.The documents come out of the work ow and can be archived by the application manager.
For the changes on document structures, we rely on Lotus Notes which provides the simple form document model where the form does not de ne the structure of a document.Changes on actors, roles and assignments.At the enactment level, Motown provides a diagnosis tool for the detection of access rights violations on documents.Access rights violations may occur only if work ow models include constraints between operations.
Changes on the ow.They result from a new design of procedures.Some procedures operations may h a ve been created, other removed.Their ordering may be di erent.The assignment of role to operations should also be modi ed.
Motown uses a diagnosis tool to detect some blocking situations which m a y occur if a work ow model includes constraints between operations.In order to satisfy the constraints on "ill" documents 10 , the organisational analysts have to understand the e ects of changes on the current w ork ow instances.
Although each modeling operator is conceptually well understood, their overall e ects are more di cult to understand 3 .One di cult point is to decide, which documents in which state have to follow the "old" work ows, whereas others have to follow the new process de nitions immediate change.Moreover, some documents will have to the old work ow u n til they reach a particular state, and then they will follow the new processes delayed change.How t o recognize automatically these situations is still an open issue, thus, our work ow enactment system provides functions to make these changes when they are required.

Conclusion
According to 1 which provides meaningful arguments, we claim that state-based models are very pertinent for workow applications.In Motown, the underlying Petri net representation is very useful for analysis and simulation of the process models.Our approach is practical and improves current w ork ow methods or tools on the following topics: it is based on a more realistic lifecycle which i n tegrates the business process evolution as a possible step, the modeling concepts are easily understandable by project teams and end users, cutting down the training and acceptance time.simulations provide realistic and pratical results.implementation is fully automated.Modeling changes can be integrated in an existing application either automatically for simple changes or assisted by an analyst for more complex changes. 10A document is said to be ill, if its history prevents the new procedure speci cation whatever the changes are from being satis ed according to the current role assignments.

Perspectives
This last section presents some issues that should be addressed when tending to improve business process modeling and re-design.

Improvement of the analysis
The analysis of business processes focuses on testing only whether the speci cation matches the users' needs.For some critical applications, we m a y w ant to prevent the occurrence of some undesirable actor coordination or situation, such a s the synthesis of distributed critical information, or an unrecoverable situation resulting from a particular ow.Arti cial Intelligence Planning tools may b e v ery useful for improving analysis of undesirable situations.

Process evolution analysis
To analyse the process evolution, a method should enable the evaluation of the changes' bene ts and should guide the transition to the new processes.The evolution itself should be guided according to the results of simulations or enactments.

Procedure canceling
Another important issue is to manage the cancellation of a procedure.This issue is meaningful at the modeling and implementation steps.The modeling level should provide concepts to specify which, when and how a procedure can be aborted.Moreover, the consequences of a procedure cancellation on other procedures should also be analyzed.At the implementation level, the issue is to de ne a powerful mechanism ensuring correct management of the task cancellation.This issue might be a research issue.

Mixing unstructured and structured processes
At the enactment level of Motown, Lotus Notes enables both cooperative w ork and structured work.
At the modeling level, this cooperative w ork could be speci ed according to some well known cooperation models.The interactions between these works types should also be modeled.

A Glossary of motown modeling concepts
This glossary includes the de nitions of concepts from OS-SAD 7 and Motown.Concepts of the operational level A.3 are ours.
A.1 Abstract level Function or subfunction A major division of the actions and of the structure of an organisation, usually based on the need to co-ordinate, direct and control to obtain speci ed outcomes independently of the actual means used.A function may be divided into subfunctions, with the numb e r o f s u c h levels re ecting the need for detail.
Activity The nest division of functions.It is the smallest amount o f w ork that must be done for which a meaningful objective and or easily de nable output can be identi ed.
Packet A set of objects data that passes between activities and between them and the external environment.

A.2 Descriptive level
An activity in the abstract level maps onto a procedure in the descriptive level.F or instance the activity work ow implementation g. 1 maps on to the procedure work ow implementation detailed in gure 6.
A packet in the abstract level maps onto a set of resources in the descriptive level.F or instance, the packet work ow speci cation g. 1 maps to the resources: process de nitions, documents structures and actors g. 6.
Operation The basic most detailed element w ork relevant to the description of the organisation.The desired level of detail depends on the nature and purpose of the speci c model.Team An aggregation of roles based on one or more organisational requirements for co-ordination or control.Teams may be aggregated into higher level teams, culminating at the level of the entire organisation.
Task A task is a term that is occasionally used in the OS-SAD context.It is not represented as a symb o l i n t h e OSSAD formalism.It is the set of operations which are performed by a given role and contained within a single procedure.
Actor An individual who carries out a role.Job description A set of roles an actor has to carry out.

A.3 Operational level
The operational level, a re nement of the OSSAD descriptive level is to specify work ows.The concepts introduced at this level are speci c to Motown.For each procedure, there is a work ow model.De ning a work ow model of a procedure consists of re ning the operation model of the procedure.Thus the question is: which resources will be documents in the work ow enactment system?Then states are added to documents to specify how operations a ect the documents.Noti cation A signal sent t o e a c h actor of a role.It signals that a document reaches a state that enables an operation of their task to be carried out.
Constraint a rule between two operations stating whether the same actor should or shoud not perform these two operations in the same procedure execution.

Figure 1 :
Figure 1: work ow development life cycle Each life cycle steps are described below:

Figure 2 :
Figure 2: abstract level: functions of an organisation

Figure 6 :
Figure 6: work ow implementation procedure Procedure A coherent set of operations, undertaken by one or collaboratively by several roles, which result in a meaningful objective being achieved or a the production of resources.Resource Data or objects which are inputs to or outputs from operations procedures.

Facility
Physical or technological support to perform work.Role An organisational responsability c o vering a set of operations performed by an individual or more than one individual if they are collaborating in a procedure.
Document a w ork ow-supported resource.State the document status within a procedure execution.It speci es how a n operation a ects the document.Document structure A set of elds whose domains are the same as those of Lotus Notes. 2

Table 1 :
The Motown process modeling levels 2in table 1, the extensions of OSSAD for work ow are written in italics.At the end of this paper a glossary is provided.
3g 1 is also an abstract model of a work ow development lifecycle.
Figure3: abstract level: sub-functions of the Sales Function., a number of waiting inputs to start the operation, an earliest time and a latest time.These parameters are optional.Any duration may be xed or variable according to a Gamma law of probability whose average is user-speci ed.A cost can be broken in two parts: a xed part and a variable part.The xed cost is taken into account whenever an object 7 is used.
subfunction Returned Figure 5: operational level: a work ow model of the procedure Expense submission for an operation

Table 2 :
.1 ArchitectureThe work ow enactment system is a Lotus Notes base including the Motown work ow engine.The four levels of its architecture are: monitor, work ow meta-model, information structure, documents table 2. The monitor controls The levels of the Work ow Enactment System the evolution of a document according to the work ow.The work ow speci cation is stored according to a meta-model.The information structure de nes the forms which allow access to the documents.The fourth level is the level of documents created, updated and deleted by the users.Lotus Notes covers the two bottom levels.The monitor updates the document status according to the user work.The updates depend on the speci cation work ow stored in the meta-model.