1

Reengineering a Business Process with anInnovative Workflow Management System: a CaseStudy.*

A. Agostini, G. De Michelis, M.A. Grasso, S. Patriarca

ABSTRACTBusiness Process Reengineering (BPR) has been proposed as a newapproach to facing the challenge of improving the quality of a businessprocess while reducing its costs. Workgroup computing systems can beconsidered as the best candidates for BPR, since they aim to improve theeffectiveness of the group of people collaborating within a work process.In particular workflow management systems seem to offer the bestsupport to a reengineered business process.In this paper we report on a case of BPR. It consists in the application to areal bank procedure of both a new approach to the analysis of workprocesses (allowing the evaluation of its transaction costs) and a prototypeof a Workflow Management System (WMS), allowing an effectivehandling of procedure breakdowns without forcing the designers to takecare of them.

KEYWORDSComputer-Supported Cooperative Work, Groupware, Office Routine,Workflow Management System, Transaction Costs, Work Process,Conversation, Communication System

1. INTRODUCTIONToday firms, as well as public institutions and agencies, are challenged byrequests for improving their performance in terms both of reducing theircosts and of improving the quality of their services (responsiveness,customer satisfaction, ...). For a long time the above requests wereconsidered contradictory: quality and costs of a business process werethought directly reciprocally dependent. Business Process Reengineeringwas proposed by Mike Hammer [Hammer 1990], [Hammer & Champy1993] and many others [Davenport 1993], [Hall 1993] as a new approachto facing the challenge of improving the quality of a business processwhile reducing its costs. In their book [Hammer & Champy 1993]Hammer and Champy report on a case in which the reengineering of awork process caused a cost reduction of 80%, a performance enhanced by

* To appear in "Collaborative Computing", Chapman & Hall. This paper is an extended version of that

published in the Proceedings of the Conference on Organizational Computing Systems, pp.154-165, ed.

Simon Kaplan, Milpitas, CA, USA, November 1-4 1993, Association for Computing Machinery, Inc.

2

500%. In general, BPR is a global intervention redefining the skills of theinvolved persons, redesigning the organizational structures and thetechnological support. Information technologies play an important role inBPR because they allow us to overcome the (space and/or time) distancebetween actors, to automatize simple operations, to control effectively thebusiness process performances, and to support the crucial actors of thebusiness process in taking their decisions in a timely and effective way.Workgroup computing systems (other keywords are CSCW systems,groupware systems, cooperation technologies) can be considered as thebest candidates for BPR, since they aim to improve the effectiveness ofthe group of persons collaborating within a work process [De Michelis1994], [Ellis et al. 1991]. In particular Workflow Management Systems(WMSs) seem to offer the best support to a reengineered business process[White & Fisher 1994]. In fact WMSs are CSCW systems specificallydevoted to model and automate cooperative work processes. MoreoverWMSs are the first tools facing the problem of exceptional situations thatcan arise during routine work.It is many years that WMSs are developed in the academic field (we wantto remember here for example [Ellis et al. 1979], [Ellis 1982], [Kreifeltset al. 1991]), moreover WMSs are currently offered (e.g. [Swenson et al.1994], [Medina-Mora et al. 1992], [Sarin et al. 1991]) and/or announcedby many software and hardware suppliers. The number of applicationsunder development is growing, and designers as well as users express theneed for methods and tools to understand what can be expected in termsof benefits from these applications. Moreover, the first experimentalapplications should also allow us to understand which are the mostvaluable features of existing WMSs, and indicate some guidelines for thedevelopment of the next generation of WMSs [Abbott & Sarin 1994].In this paper we report on the application, to a real bank procedure, ofboth a new approach to the analysis of work processes, allowing theevaluation of its transaction costs; and a prototype of a computer-basedsupport system which integrates a WMS with a conversation handler,allowing an effective handling of procedure breakdowns without forcingthe designers to take care of them. Both the analysis approach and theprototypal system were successfully applied: the former was able to guidethe design of the WMS, allowing us to evaluate the expected benefits interms of responsiveness; the latter allowed us to design the computerizedprocedure as simply as possible, making it easily modifiable. Moreoverthis experience has given us many suggestions for the conception anddesign of a new computer-based support system fully exploiting theadvantages of the prototype we have used within it.

2. WORK PROCESSESAs the name clearly indicates, BPR calls for the relevance of businessprocesses within organizations. We fully agree with this claim since wethink that the structures of organizations, in order to obtain better

3

business process performances, must be designed reflecting the coreprocesses they perform instead of dividing organizations into functionaldepartments causing a mere distribution of work among organizationalstructures.In this paper we assume, therefore, that the basic units of any organizationare the work processes performed within it. We consider irrelevant thedistinction between business processes (where the emphasis is onexchange) and work processes (where the emphasis is on activities). Thispoint of view, constituting a radical shift in organizational analysis andstrongly supported by many recent contributions in management sciences[Keen 1991], [Scott-Morton 1991], offers in particular a useful insightinto work practices to designers of computer supports.While we do not enter into the discussion of the new perspective whichwork process-oriented analysis opens within management sciences, in thefollowing lines we propose some details on the main features of workprocess analysis we are adopting.

2.1 Work processes as relations

3Performer fulfills and reports

1Customer Requests

2Performer agrees

4Customer declares satisfaction

Can you do?

OK. I will do.

Done.OK. Thank you.

Figure 1: The Basic Process Model (source Action Technologies Inc.)

It is not our intention here to discuss in depth what work is as a humanactivity: we will assume a very general and to some extent fuzzy image ofwork, considering it the pragmatic dimension of human life. With thiswork image in mind, if we look at organizations such as firms and publicinstitutions we can characterize their behaviour in full (analyzing theirstructure, evaluating their performances, ...) through the work processestheir members are involved in. From this point of view, a work processis something more than the simple flow of actions giving rise to anexpected outcome: to understand the behaviour of an organization it isimportant to embed any flow of action within the relation giving it asense. The meaning of any action is strictly dependent on the context inwhich it is performed, i.e. on the customer-performer contract definingit.In accordance with Fernando Flores and his co-workers [Keen 1991],[Medina-Mora et al. 1992], we consider a work process as a cycle startingwith a customer generating the request for an action, continuing with a

4

performer agreeing with the customer to do the required action and thencompleting it, and finishing when the customer declares her satisfaction(the Action Workflow; see Figure 1). Any organization, such as a firmor a public institution, can be characterized by the work processes itsmembers are able to initiate, and its behaviour can be described in termsof those processes.The image of a work process given in Figure 1 has many interestingfacets: let us recall some of them.A work process is a communicative relation between a principal customerand a principal performer (both can be persons or juridical entitiesrepresented by persons) within which the latter performs in order tosatisfy the customer request, but both of them assume responsibilities andconsume time and resources.A work process is a cycle since, after the successful completion of aperformance, the relation can be continued with a new request of thecustomer, taking into account the completed performances. In the case wediscuss in this paper, a customer who has already obtained a credit fromthe bank can ask for a renewal without restarting from scratch: i.e. awork process has memory of the requests on the part of the customer theperformer has already fulfilled (as well as of those she has not fulfilled).Within a work process the principal performer can either instantiate apre-defined procedure that will be performed by other actors accordingto its flow, or open other sub-processes with other performers, becomingtheir customer. In the first case the work process under development issuccessfully anticipated by the designed procedure; in the other, therequest opening the work process is new and needs the principalperformer to design the flow of activities satisfying it. In both cases theprincipal performer together with her co-actors may need to open sub-processes to overcome the breakdowns occurring during the developmentof the work process. We must underline that also the customer, e.g. in thesatisfaction phase, can open sub-processes to face the breakdowns she mayencounter in formulating her request. The above distinction may bedisregarded if we assume that the arrows linking the steps of a procedurecan be considered as representing customer-performer cycles.Within a work process the principal performer together with all thepersons involved in it and all those with whom she has opened a sub-process constitute the cooperation network [De Michelis 1994] of thework process itself. The cooperation network is not usually a unit of theorganization the performer belongs to because it is impossible to constrainthe cooperation network of a work process within the boundaries of apredefined organization without reducing its effectiveness in regard topossible breakdowns. Any person participating in the cooperation networkof the work process plays a role within it. This role is characterized bythe sub-processes in which she can participate on the basis of her abilitiesand responsibilities [De Cindio et al. 1988].

2.2 Duality

5

From a work process we can abstract its action flow, taking into accountonly the performed input-output transformation. On the other hand, it ispossible to abstract from a work process its communication flow; itcharacterizes the mutual relations between the members of its cooperationnetwork.The interleaving of acting and conversing within a work process cannotbe modelled: whenever a breakdown occurs within a work process, a newwork sub-process is opened, but breakdowns are generally unpredictable.If we try to take into account all the possibilities of breakdownoccurrences, we have a combinatorial explosion of the dimensions of ourmodel; if we select only the most meaningful or probable potentialbreakdowns, we oversimplify the model. On the contrary, the interleavingof acting and conversing within an ongoing work process is unique,depending on its specificity. Also if the action flow follows a predefiniteschema, as is the case for most of the business procedures (consider forinstance insurance or finance companies), the work process itself cannotbe reduced to that schema, but it is properly characterized by the way inwhich it interleaves actions and conversations.

2.3 Complexity and Transaction CostsThe above recalled observations on work processes can be synthesized inthe following claim: work processes are complex, since their distinctivefeatures (customer-performer relation, cooperation network, action flow,communication flow, organizational structure, etc.) cannot be captured bya single point of view. The complexity of the work processes is the maincause of transaction costs [Williamson 1975] a firm must afford, andanalyzing the former can be a good starting point for evaluating the latter(for a richer discussion of this point see [De Michelis 1994]). If we takeinto account the autonomy and multiplicity that characterize thecomplexity of a work process, we can try to give a more detailed accountof its transaction costs, providing the factors affecting them.From the multiplicity point of view:• the number of members of the cooperation network;• the number of sub-processes;• the number of participants in any sub-process;• the number of sub-processes running in the same period of time;• the turnover rate of the organization.

From the autonomy point of view, the relevant factors are:• the number of work processes any participant is also involved in;• the threshold of sustainable complexity of its participants.

By threshold of sustainable complexity (for more details see [De Michelis1994]) we intend the number of work processes and/or interactions aperson may engage in without having difficulty managing them. Thethreshold of sustainable complexity of any person depends on her culturalbackground and on the tools she can use; it is a multiplicative cofficient of

6

the other factors affecting transaction costs, since its value determinestheir impact on transaction costs.

2.4 Computer-based ToolsThe introduction of computer-based tools in a firm is one of the startingpoints for the reengineering of a work process [De Michelis 1990], [White& Fischer 1994]. In particular as claimed above, WMSs are computer-based tools expecially devoted to support work processes. They supportmulti-user applications managing the routing of individual activities;interconnecting individual activities; integrating them; eliminating all theinteractions due to the lack of that integration; and, finally, giving theirusers easy access to the context of any activity (enhancing therefore theirthreshold of sustainable complexity). WMSs provide the users data neededfor each activity as well as a global view of the procedure they areinvolved in.

3. WooRKS & UTUCS: COUPLING A WORKFLOWMANAGEMENT SYSTEM WITH A COMMUNICATIONSUPPORT SYSTEMAs we have said above, a work process can be seen as a two-facet object:that is, when workflow follows the previously defined plans, it is made upof activities to be done by various actors (the routine dimension of thework process is emphasized); and when a breakdown blocks the plannedworkflow, it becomes a subject of conversation among the same group ofpeople (the creative dimension of work processes is emphasized).Generally, the computer-based system, where a performer executes herroutinized task, is separated from the system supporting her conversationswith other actors; and therefore, when a breakdown occurs, she has toleave the first system and enter the second. The integration of someworkgroup computing tools (or features) within generic OfficeEnvironments is only a partial answer to the above problem. Theseenriched Office Environments make it easy, for example, to switch froma form manager (to fill a formal document) to a conversation manager (torequest some help), but they are not able to help the user in selecting theperson who can help on the basis of the formal document she was filling.The two views are not integrated: they are just merged.WMSs are the first tools facing the problem of offering an integratedsupport to routine work and non-routine work, when they provide theirusers with some exception-handling mechanisms. Two different lines havebeen followed in this respect: either a communication support system isembedded within a WMS (e.g. [Kreifelts et al. 1991]), or a WMS isembedded within a communication support system [Medina-Mora et al.1992]. In the first case the communication support is generally restrictingthe communication possibility on the basis of the procedure definition,while in the second the procedure definition can appear more complicatedon the assumption that any task results from an interaction between a

7

client and a performer. On the contrary, the support system we haverealized (see the architecture in Figure 2) coupling together a WMS,WooRKS, and a conversation handler, UTUCS, presents a differentsolution to the problem (for further details see [De Michelis & Grasso1993]).

procedure

information(what)

event(relate)

organization(who)

time(when)

operator(do)

communication(about)

WooRKS

HooDSCooL

NooDLE

Unix Environment

OO-Library

Development Support System

Execution Support System

CommunicationSupport System

UTUCS

Figure 2: The WooRKS-UTUCS Overall Architecture

The realized environment in fact allows us to design the workflow as asimple stream of actions (no loops are necessary, no exceptional pathsneed to be foreseen), i.e. as a resource for actions [Suchman 1987]; itsupports a natural and immediate switch from the WMS to thecommunication support system within a common framework in order toaccompany the user while her attention switches from the routine to thesolution of the occurred breakdown; it generates an integrated record ofboth all the performed actions and all the performed conversations,providing its users with a direct access to the context within which theyare acting.It has to be underlined that the realized environment, while going beyondthe features of the two components on which it based, makes unneccessarysome service they offer (due to their independent design). It is thereforepossible to re-design it in a more effective way (cutting off theunnecessary functionalities) on the basis of newly conceived components(see Conclusions).In the next sections first we will briefly describe the principal features ofthe two systems, then we will emphasize the peculiarities of UTUCS as anexception handler in WooRKS procedures.

3.1 WooRKSWooRKS has been developed within the ESPRIT funded ITHACA project.The objective of the ITHACA project was to reduce the long-term costs ofapplication development and maintenance for standard application inselected domains using an object-oriented methodology. WooRKS [Ader

8

et al. 1994] is the application developed in order to verify themethodology in the office domain. It is based on the consideration that alot of routine office work can be described as structured recurring tasks(called procedures) whose basic work item (activity) must be performedby various office workers and computer systems (denominated actors) ina certain order (sequential or parallel). The coordination between theactors is characterized by the circulation of documents. A WMS is used toassist people in defining, executing, coordinating and monitoring suchroutine office procedures based on a shared environment. As such,WooRKS satisfies the following requirements:

- WooRKS acts as both a group work scheduler able to assign actions toactors and monitor their execution, and as an integrator able to invokeany classical office tool when it is needed for the execution of an action;

- WooRKS offers tools to describe the organization and the proceduresof a group, and to configure and specialize its own models to meetspecific group requirements.

- WooRKS does not replace classic office applications but it encapsulatesthem in such a way that it can monitor their execution; it also providesan easy way of introducing new applications into its environment;

- WooRKS handles the context of the tasks under the responsibility of thegroup according to the defined procedures for the group and thedescription of actor roles.

WooRKS is implemented on top of an object oriented development systemcalled HooDS (Highly object oriented Development System), whose maincomponents are the programming language CooL (Combined objectoriented Language) and the database management system NooDLE (Newobject oriented Database system for advanced programming LanguageEnvironments). WooRKS provides reusable object classes defining severalinterrelated models. The Organization Model represents the actors of agroup and their roles, in such a way that actions can be properly assignedto the actors; the Information Model represents the semantic of theinformation manipulated by office procedure at a level that enablesautomation; the Time Model represents all time related concepts andincludes an agenda and a time event mechanism; the Event Model allowsus to manage external events and associate them either to a new procedureor to an existing one; the Operator Model implements an abstraction ofthe various office invocations of applications on external objectsrepresented by references; the Procedure Model captures the definition ofthe work process to be assisted in terms of actions on informationassigned to actors.The application developer's task is to specialize these models in order toadapt the system to the requirements of each specific group.

9

To define activities and procedures, while modelling routinized work, thededicated programming language ADL (Activity Description Language) isprovided. ADL is used by the application developers to describe howactivities are connected by data and control links and who are the actorsthat have responsibilities to start and execute each one of them. Theinterface between the user and the system, which handle the procedurecontrol, is defined by the behaviour of an object called 'WorkflowBasket'. It is just a container, associated to each actor, for receiving andpresenting procedures and activities to be started/executed. From it eachactor can perform some action, like:- start/abort procedures, if the Workflow Basket owner is responsible for

them;- start activities that have been delivered to her;- forward activities to other actors in the organization;- show ended/aborted procedures;- use UTUCS functionalities (see next section).

3.2 UTUCSUTUCS (User to User Communication Support) is a system forsupporting a group of people (an office, a team), interconnected in acommunication network, in handling conversations carried on throughdifferent communication media: asynchronous (e-mail) and synchronous(face-to-face, meeting) (for further details see [Agostini et al. 1994]). Thefact that our interest was to investigate the way in which communication islinked to action and vice versa led us to adopt the language/actionperspective [Winograd 1988], [Winograd & Flores 1986]. At that time wewere, and we still are, aware of the discussions accompanying the work ofFlores and Winograd (e.g. [Bowers & Churcher 1988], [Robinson 1991],[Suchman 1993]). We adopted their approach on the one hand to evaluateit in depth, extending it to multimedia conversations; on the other, becauseour analysis of the Coordinator convinced us that its users may easilycircumvent its prescriptive nature [Ciborra 1993]. We have dedicated tothe analysis of the language/action perspective a long section of [DeMichelis & Grasso 1994] within which a new conversation model isproposed; we will come back to this point in the Conclusions.In accordance with the language/action perspective, in UTUCS the basicitem of the communication is the conversation involving the actor whoopens it, the partner with whom the conversation is going on, andoptionally a set of users that the actor can designate to have visibility onthe conversation. We will denominate 'active' the person directly involvedin the accomplishment of the commitment, 'passive' the other.UTUCS conversations are classified in four kinds, according to thecommitment they speak about:- "Commitment to Do". This type of conversation subsumes all

conversations in which people discuss a commitment for doing anaction;

10

- "Commitment to Be". This category consists of conversations forpossibility. Their effect is to transform the organizational setting;

- "Information Handling". This type of conversation can be opened todelegate someone to manage an information base;

- "Information Providing". This type of conversation can be opened togive or request some information.

Each type of conversation can be represented by an automaton <S, I, Ω>where:- S is a finite set of states, representing the states of the commitments;- I is a finite set of transitions;- Ω is the function that receives as inputs the current state and a

transition, and calculates as output the next state.

Figure 3 shows the state-transition diagram of a "Commitment to Do"conversation; in each state the possible speech acts are represented by theoriented arcs. Figure 4 shows a summing up of the speech acts of aconversation of this kind. In the figures only the transitions that changethe state of the conversation are depicted, but at any time the interlocutorsare able to send some notes, solicitations or comments to the partner.

Transition of Active

Transition of Passive

Concluded

Satisfied Not Satisfied

TakenDeleted Rejected

Requested Offered

Figure 3: The "Commitment to Do" Automaton (revised version of theConversation for Action- Action Technologies Inc.)

Let us suppose that Passive (P) makes a request to Active (A), forexample "Could you test my program by the end of the week?". There aremany possible states in which the commitment under discussion can movefrom the state "Requested" depending on the response of A. If A agrees toperform the action on the proposed terms, e.g. within that deadline, thestate becomes "Taken"; otherwise "Rejected", if A refuses to assume thecommitment. In the case in which A is willing to test the program, but shewould like to negotiate the conditions of the action to carry out -forexample she wants to postpone the time of accomplishment- theconversation reaches the "Offered" state. It might happen that A has

11

already done the requested action, then her response will lead inevitablyto the state "Concluded". Also P can determine a transformation of thecommitment to the state "Deleted", if she changes opinion for some reasonafter the request and withdraws. In the state "Concluded" the Passiveevaluates if the commitment has been brought successfully to a conclusion,going to the alternative terminal state "Satisfied" or "Not Satisfied".

Present State Speech Act Next State

()

Requested

Offered

Taken

Concluded

OfferedRequested

OfferedRejected*TakenConcludedDeleted*

RequestedTakenRejected*Deleted*

RequestedDeleted*OfferedConcluded

TakenSatisfied*Not Satisfied*

A P

A A A A P

PPPA

PPAA

PPP

OffersRequests

Counter-OffersRefusesAcceptsConcludesWithdraws

Counter-RequestsAcceptsRefusesWithdraws

Counter-RequestsCancelsCounter-OffersConcludes

RefusesApprovesDisapproves

* Terminal States; A = Active, P = Passive.

Figure 4: The Speech Acts of a "Commitment to Do"

We want to underline that UTUCS is a general support to thecommunication between users; in fact it handles not only conversationslinked to activity or procedure, but also free conversations (i.e. with afree subject). In the following we will focus on the first aspect. Forfurther explanations about how UTUCS conversations can be carried outsee [Agostini et al. 1994].

3.3 UTUCS for Exception Handling in WooRKS ProceduresLet's recall the view of a work process as a two-facet object, made up ofboth flows of activities and nets of conversations. What we want to pointout here is that a work process is a situated activity [Suchman 1987],consisting of several actions performed by its actors and of severalconversations involving groups of them. The articulation of the actions to-be performed can either be generated day by day, on the basis of thealready performed actions, or it can be anticipated in a plan. In the secondcase, we can distinguish between the plans that are created at thebeginning of the work process and can be modified during it (e.g. projectplans) and the plans that are predefined outside the work process for alarge class of work processes and are recalled at the beginning of one ofthem that cannot be modified during it (e.g. administrative procedures).The computer-based system we present in this paper is specificallyoriented to work processes of this latter type. Despite the fact this latter

12

case appears more "structured" than the other two, also in this case workis situated. Routine work is in fact less routine than its name shows:exceptions are in some sense the rule within it! Any ongoing "routine"work process is a unique combination of actions, foreseen and notforeseen in the plan, and of conversations interconneting them.From this point of view, plans are resources that people use to refer toduring work; but each plan is enriched by all the events (actions andconversations) that are unique to it. The history of a procedure is uniqueand the context that generated it makes sense to each event. Any taskwithin any activity has a changing appearance for a user: sometimes shelooks at it as if it were something to be done (her tasks); other times shelooks at it as if it were something to converse about (her responsibilities).The executed actions within an activity contain relevant information forsharing a view with the partners of that activity during the conversationsopen in it; meanwhile, the conversations performed in it contain relevantinformation for doing the actions required by it. In other words, whileacting and conversing are independent of each other within an activity,they share the same context, made up of a variety of factors: its actors(the creator of the activity workflow, its activator, its performers), itsinputs, its previously executed tasks and the conversations that haveoccurred in it.Supporting office workers while performing their task within an activitycan be done by a couple of interlinked tools, a workflow managementsystem and a conversation handler, all sharing a common context andallowing the user to switch from one to another without exiting from thecontext itself.In this sense we have enriched the procedure execution environment ofWooRKS with communication functionalities whose main purposes are:- help the worker to link the communication to the context that generated

it (dynamic nature of the context);- help the worker to navigate the context to retrieve the information she

needs to solve the situation (static nature of context).

Briefly the integration of UTUCS in WooRKS intends to supportconversations among users in order to handle exceptional situations thatcan arise during procedure execution. Typically when an exception ariseswhile an actor is executing an activity at her workstation, she needs tocontact either one of the actors participating in the workflow procedureprocessing or the person responsible for the procedure. The activity thatcreates the problem is the subject of the conversation with itscorresponding procedure context, and the result of the conversation canbe the missing information being provided, or an action of the procedureresponsible in the context in order to solve the stalled situation. To gofurther into details each actor can choose to open from Workflow Basketa conversation on an activity. Then a message form is displayed with somefields automatically entered:

13

- receiver: is the person responsible for the procedure/activity (the inputhelp gives the actors involved in the procedure);

- subject: is the name of the procedure/activity in exception (the inputhelp gives the activities belonging to the procedure);

- response time: if the procedure has some time constraints, they are usedto set this field.

Each one of these fields can however be modified by the sender, who, forexample, can decide to open the conversation with someone else she thinkscan help her solve the problem. The actor can choose the proper receiverusing the input help functionality associated with the field.With the conversation a bidirectional link between the activity and theconversation is created. That is, it is always possible during thevisualization of a conversation to resume all information about the activityand the procedure that invoked it and from the Workflow Basket visualizethe set of conversations that have been opened on an activity. The personresponsible for the procedure can also see all the conversations on allactivities. In order to clarify how UTUCS can be used to handle exceptionsituations during execution of WooRKS procedures, we will give anexample in section 5.Before closing this section, let us observe that the integration of UTUCSwithin WooRKS, has also two other effects. On the one hand, thepossibility of handling all the exceptions through UTUCS allows us todesign the workflows as simple streams of actions: both the language tospecify workflows (ADL) and the run-time support module of WooRKSappear too complicated with respect to their new roles. On the other, inorder to use UTUCS as a means of handling exceptions (and also as ameans of starting any action), we don't need the structured type ofconversations we have implemented in UTUCS: we can gain in flexibilityleaving conversations unstructured and creating a special type ofattachment for starting actions of any type (for further details see [DeMichelis & Grasso 1994]).

4. THE CASE STUDYAs a demonstration of the WooRKS-UTUCS environment, a prototypalapplication of it within a bank was developed. The experiment was carriedout reworking the analysis of the credit work process previously made bya team of Datamont and RSO professionals, and reengineering it with theWooRKS-UTUCS prototype. In the same bank the RSO professionals alsoreengineered the reporting system of the credit management process usinganother WMS [Schael & Zeller 1993].

4.1 The BankThe bank involved in this case study is a limited liability cooperative thatwas established almost 120 years ago. Its headquarters is in a medium sizetown in northern Italy. The bank was founded and initially developed as abank local of scope whose main purpose was to achieve widespread

14

penetration in its home province. The bank's regional character changedwith time. It is a peculiar characteristic of this bank to constantly fosterthe expansion and diversification of its operating structure on diversemarkets, thus achieving economies of scale. At the same time, a balance isalways kept between the need for expansion and the necessity toconsolidate the acquired market share. Subsequent to the local presence,the bank opened branches in various adjacent sub-regions, reaching a totalnumber of 56 branches.

4.2 Short Description of the ProcedureThe selected procedure was the process through which a customer requestfor a new credit is managed. The client interacts with the agency directorwho is responsible for the whole procedure. Client of the procedure maybe a private person (physical) or a legal person (company). After apreliminary informal investigation of which the director is in charge, aformal request document has to be signed by the client. The documentmust contain information about the requested amount, duration of thecredit and, when requested, guarantees. Furthermore, the client has togive detailed information about her financial position. The agencydirector looks in the clients' database in order to see whether the client isalready known and to check her financial position with respect to thebank. After this first investigation, the branch director activates severalsecondary workflows with the client, the branch secretariat and thecentral credit office of the bank in order to decide whether she is infavour of giving the credit or not. If the branch director supports thecredit request she will sign it. If the credit request is under 50,000,000Lit. and the interest rate is higher than 17.5%, the signature is sufficientto make operative the credit after its registration in the "book of credits".Otherwise other bodies of the bank have to sign the form. The client getsan official letter about the resolution on her request, after it has beensigned by the resolution body and all technical necessities have beenfulfilled. The client has to send a signed copy of this letter back to thebank in order to state her acceptance of the credit and the relatedconditions.This procedure has been affected by some critical aspects: lack ofattention to the client's needs, low efficiency and high internal costs.Improving the accesses to data, reducing the bottleneck due to approvaldecision providing an asynchronous communication medium, making theprocess easy to be modified, and supplying a better way to handlebreakdowns all mean providing a more efficient service to the client andincreasing the concurrency of the service by reducing its cost.

15

4.3 Identification of the Cooperation Network of the Processand Professional Characteristics

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

Agency credit secretariat

BRANCH 2

...

... ...

Agency director

Agency credit secretariat

BRANCH n

...

Figure 5: Organizational Structure of the Bank

The organizational structure of the bank is sketched in Figure 5, whereonly people or offices that take part in the Credit Procedure are shown. Inthe following a brief description of the organizational roles belonging tothe cooperation network is provided:- Agency director - She is responsible for the agency's overallperformance and for commercial development. According to theorganizational model of the bank, she is the initiator of the CreditProcedure. In line with current rules of the bank, her role ischaracterized by autonomy and full responsibility in initiating a loanrequest procedure; her deliberation competence is limited to loans <=50,000,000 Lit and Interest rate >= 17.5%.- Agency credit secretariat - This office supports the agency directorin preparing the credit dossier, i.e the bureaucratic documentation needed.- District coordinator - She has responsibility over the bank budgetfor credit operations in her area of competence. She is informed on allcredit proposals in order to explore new business opportunities. Herdeliberation competence is limited to loans <= 80,000,000 Lit and interestrate >= 14.5%.- Credit office director - She is an experienced manager. Who inmost cases has reached that position after a career in the agencies. Sheusually also has some experience as a credit evaluator; the responsibilityof the director is to assure a check on credit activities in general. Herdeliberation competence is limited to loans <= 200,000,000 Lit. andinterest rate >= 14.5%.- Credit office evaluator - She deals with the risk assessment of theclient, taking no formal decision. She is in charge of gathering randominformation and forecasting market evolution of the client's company. Sheis responsible for the formal check on the Credit Procedure and on theproposed conditions.- Credit office secretariat - It is mainly concerned in the formalrecording of official decisions; it is responsible for data gathering andfilling-in of complex standard forms.

16

- Risk centre - This office is responsible for the administration of datainside the information system. It is in charge of the enhancement of therate of data exchange between the various organizational units.- Resolution body - Its deliberation competence is extended to loans >200,000,000 Lit. and interest rate <14.5%. Vice Director is in charge ofdeliberations about loans <= 300,000,000 Lit. with a rate of interest <=14,5%; General Director has deliberation competence limited to loans <=600,000,000 Lit. and any interest rate; the Committee of GeneralDirectors decides on credits <= 1,500,000,000 Lit.- EDP centre - This office is responsible for the punching of data in theinformation system.- Office in charge of perfecting the practice - It is responsible forthe completion of the practice and its subsequent registration when thereare guarantees involved. It is the competent office for stocks, mortgagesor foreign business affairs.

In order to take her decision, the agency director may ask the agencycredit secretariat for additional information about the client. Thisinformation can be obtained from several sources, which can be internalor external to the bank, for example:- Agency vice-director- Special credit office- Information offices:

- Chamber of Commerce,- Court,- Risk Center of Banca d'Italia.

- Committee of local experts etc.

All these organizational roles are involved in sub-processes of the CreditProcedure as shown in Figure 6. It depicts the process from theCommunicative Interactions point of view, embedding any activityperformed within it into a sub-process; each sub-process is characterizedby the action it embodies, the customer requiring the service and theperformer that either executes the action or starts a new sub-process.

4.4 Identification of All the Foreseen CommunicativeInteractionsTo represent the procedure we use the Action WorkflowTM notation; eachsub-process is identified by a code that explains its level: if the code of thecurrent sub-process ends with a letter, it means that this sub-process isalways done, if the code ends with a number the sub-process is alternativeto others sub-processes in the same level. The process in Figure 6 can besummarized by Table 1. For each sub-process (corresponding to a row inthe table), the principal-performer and the principal-client are identifiedby a capital letter "P" and a capital letter "C" respectively. Since theprincipal-performer of a sub-process is a performer also in the process ofupper level, we identify this kind of performer with a lower-case letter

17

"p". If there are two or more "p"s in a row, it means that a CoordinationProblem arises in that process. A Coordination Problem is always presentwhen, in a work process, different activities performed by differentactors are inter-related; and this is the case of a work process that hasdifferent sub-processes.

External Info

client

agency

director

current

account

credit

exploitation

of the client's

motivation

agency

directorclient

A

agency

director clientdocuments

for credit

B

agency

director information about

the client

C

agency

director

proceeding compl.

and 1st credit's

evaluation

agency credit

secretariat

D

agency

director

agency credit

secretariat

credit evaluation

authorization &

registrationagency

director

E

agency credit

secretariatinformation

request External Info

(CERVED)

DAA

credit

office

credits in other

banks

>= 80 000 000

DA

agency credit

secretariat

credit

office

External Info

(BANKITALIA)

credits in other

banks

>= 80 000 000DB

punchingEDP

perfecting the

credit request

practice

risk

centreagency credit

secretariat

load credit in

information

system

HA

H

credit

office

signature for

sightdistrict

coordinator

credit

office

credit

office

credit auth. &

registration book

of credits

resolution

body

credit

office

credit

registration

risk

centre

credit

office

monthly report

registered

creditsEDP

credit

office

monthly report

unregistered

credits

risk

centre

archive

practice

get conditions

approval client

office in

chargeagency credit

secretariat

perfecting the

practice with

guarantees

HB

EDP

punching

HAA

EA

EB

EC

ED

EE

ECArisk

centre

F

agency

director

agency credit

secretariat

G

agency

director

risk

centre

office in

charge

HBA

load credit in

information

system

risk

centre

HBAA

punching credit

and guarantees EDPrisk

centre

Figure 6: The Credit Procedure

18

Principal WorkFlow

WorkFlow A

WorkFlow B

WorkFlow C

WorkFlow D

WorkFlow DA

WorkFlow DAA

WorkFlow DB

WorkFlow E

WorkFlow EA

WorkFlow EB

WorkFlow EC

WorkFlow ECA

WorkFlow ED

WorkFlow EE

WorkFlow F

WorkFlow G

WorkFlow H

WorkFlow HA

WorkFlow HAA

WorkFlow HB

WorkFlow HBA

WorkFlow H BAA

Office

Perf.

p

P

C

Agency

Director

P

C

C

C

C

C

C

C

C

Agency

Secret.

p

P

C

C

P

P

C

C

Credit

Office

p

p

P

C

P

C

C

C

C

C

District

Coord.

p

P

Risk

Centre

p

P

C

P

p

P

C

p

P

C

Resol

Body

p

P

EDP

Centre

p

p

P

P

p

P

p

P

Client

C p

P

P

P

Ext.

Info

p

P

p

p

P

P

Table 1: Principal Clients, Principal Performers and Performerssummary

On the basis of this data we can perform some "measurements" on theprocess. For instance we can count how many Communicative Interactionseach actor is involved in, either as customer or as performer. We can alsoevaluate the size of the whole process giving the range of the number ofactual-performed Interactions. These parameters are summarized in Table2. If we divide the value obtained by adding values of the "Total" columninto 2, we obtain the real number of Communicative Interactions as eachof them involves two actors.

Customer Performer Total

Client 1 3 4Agency Director 7-8 1 8-9Agency Credit Secretariat 2-4 3 5-7District Coordinator 0 0-1 0-1Credit Office 0-6 0-2 0-8Risk Centre 2-3 2-4 4-7Office for Perfecting Practice 1 1 2Resolution Body 0 0-1 0-1External Info Sources 0 1-3 1-3EDP 0 2-4 2-4

Total/2 13-23

Table 2: Number of Communicative Interactions

4.5 Costs EvaluationAmong the multiplicity factors of transaction costs listed in Section 2.3,the ones affecting the performances of the Credit Procedure are thefollowing:

19

- the number of members of cooperation network: some of the membershave a limited role (supporting information providing) and can beeliminated;

- the number of sub-processes: information acquisition could beperformed automatically.

The procedure has limited parallelism and in the Bank there is a limitedturn-over.

Both the autonomy factors of transaction costs listed in Section 2.3 affectthe performances of the Credit Procedure:• the managers involved in it, in fact, are deeply involved in many other

business processes, and constitute a bottleneck in the Procedure(because of a low threshold of sustainable complexity - see below);

• the threshold of sustainable complexity of the managers is low: they arehighly skilled professionals, but they lack both tools allowing them tointeract effectively both synchronously and asynchronously and toolshelping them to recall the matter in question within a work process.The threshold of sustainable complexity emphasizes therefore thenegative impact of the other factors on transaction costs.

To conclude this Section we must underline that a drawback of the CreditProcedure is that it is difficult to modify, because its modificationrequires the training (with informational content) of a great number ofpersons throughout the Bank.

5. REENGINEERING THE PROCESS WITH WORKFLOWMANAGEMENT SYSTEMSThe actors involved in the Credit Procedure deal only with theInformation System and with the paper forms specific to the procedure.The bank Information System is based on an IBM 3090 mainframerunning the MVS-SE operating system. The logical architecture's core is aVSAM database called CEFI (CEntral FIle). The search for information ismade by transactions; the outcomes of these queries are copied on theappropriate forms and then, collected in files, exchanged among actors.With the introduction in the bank of the WMS, we will be able to simplifythe procedure cutting off all the Communicative Interactions which aredevoted to asking for services that actors could perform themselves ifsupported by adequate tools. For instance, if an actor can directly accessthe information she needs in the context of the activity she is performing,we can eliminate all the Communicative Interactions with other peopledevoted to requesting and collecting them. In this way, we eliminate allthe Interactions with the EDP center as well as the Risk Centre.As in the previous example, the process can be summarized by Table 3.As foreseen, the introduction of the WMS reduces the number ofCoordination Problems and allows a general fine tuning of the process.

20

district

coordinator

E22A

agency credit

secretariat

client

agency

director

current

account

credit

exploitation

of the client's

motivation

agency

directorclient

A

agency

director clientdocuments

for credit

B

agency

director information about

the client

C

agency

director

proceeding compl.

and 1st credit's

evaluation

agency credit

secretariat

D

agency

director agency credit

secretariat

perfecting the

credit request

practice credit

office

credit

evaluationagency

director

credit

conditions

approvalagency

director

E1

district

coordinator

E2

signature for

sight

E21

credit

proposal

E211

E211Adistrict

coordinator

district

coordinator

credit

resolution

E22

resolution

body

get conditions

approval

credit

resolution

district

coordinator

E212

E2A2A

agency credit

secretariatinformation

request External Info

(CERVED)

DAA

credit

office

credits in other

banks

>= 80 000 000

DA

agency credit

secretariat

credit

office

External Info

(BANKITALIA)

credits in other

banks

>= 80 000 000DB

credit

office

credit

office

district

coordinator

credit

office

credit

office

credit

office

credit

office

get conditions

approval

get conditions

approval

resolution

body

resolution

body

clientagency credit

secretariat

further

documents for

conclusion

FA

F

Figure 7: The Credit Procedure after the Reengineering

Principal WorkFlow

WorkFlow A

WorkFlow B

WorkFlow C

WorkFlow D

WorkFlow DA

WorkFlow DAA

WorkFlow DB

WorkFlow E1

WorkFlow E2

WorkFlow E21

WorkFlow E 211

WorkFlow E211A

WorkFlow E 212

WorkFlow E212A

WorkFlow E22

WorkFlow E 22A

WorkFlow F

WorkFlow FA

Agency

Director

P

C

C

C

C

C

C

C

Agency

Secret.

p

P

P

C

C

P

C

District

Coord.

p

P

p

P

C

C

P

C

Credit

Office

p

p

P

C

P

C p

P

C

P

C

C

Resol.

Body

p

P

p

P

p

P

Client

C p

P

P

p

P

Ext.

Info

p

p

P

P

Table 3: Principal Client, Principal Performer,and Performer Summaryafter the Reengineering

This affects the Transaction Costs of the process reducing themproportionally to the number of Communicative Interactions cut off asshown in Table 4.

21

Customer Performer Total

Client 1 3 4Agency Director 5-6 1 6-7Agency Credit Secretariat 3 1-3 4-6District Coordinator 0-1 0-1 0-2Credit Office 0-3 0-3 0-6Risk Centre 0 0 0Office for Perfecting Practice 0 0 0Resolution Body 0 0-1 0-1External Info Sources 0 0-2 0-2EDP 0 0 0

Total/2 7-14

Table 4: Number of Communicative Interactions after the Reengineering

5.1 Description of the Credit Procedure with ADL FormalismThe information flow between the activities of the Credit Procedure hasbeen designed using the ADL language provided in the WooRKSenvironment; data objects, roles and actions (objects which embody thecomputational part of the activities) have been implemented using theobject-oriented language CooL.In the following, a piece of ADL code which refers to the first part of theProcedure and its graphical representation are shown. With this kind oflanguage the procedural aspect of a work process, as input/outputtransformation, is emphasized; so the information flow is described bydeclaring the input objects each activity needs, the places these objectscome from and the output each activity produces.

DEF_PROCEDURE CreditDealingROLE Manager OF CONTEXT BranchOBJECTSCONTEXT..

INPUTClient

OUTPUTform7 FROM action_2form12b FROM ALT_REJECT OF action_6

OR ALT_REJECT OF action_8form12 FROM ALT_ACCEPT OF action_6

OR ALT_ACCEPT OF action_8

ACTIVITY action_1: MeetClientROLE Manager OF CONTEXT BranchINPUT

Start FROM OUTER_WORLD

22

OUTPUTmeetingDate

END_ACTIVITY

ACTIVITY action_2: NewCreditProcedureROLE Manager OF CONTEXT BranchINPUT

meetingDate FROM action_1OUTPUT

form1 -- requested credit amount and typeform2 -- client's identification on the anagraphical databaseform3 -- comment on new credit procedure

END_ACTIVITY

ACTIVITY action_3: MeetClient..END_ACTIVITY

ACTIVITY action_4: PrelimCreditInvestROLE Manager OF CONTEXT BranchINPUT

meetingDate FROM action_3form1 FROM action_2form2 FROM action_2form3 FROM action_2

OUTPUTform4 -- client's exposition to the bank/risk profileform5 -- client's updated anagraphical dataform6 -- client's motivationsform7 -- list of necessary and collected/missing documents

END_ACTIVITY

ACTIVITY action_5: PrepLetter..END_ACTIVITY

ACTIVITY action_6: RegSignature..END_ACTIVITY

ACTIVITY action_7: DecisionOnCredibilityROLE Manager OF CONTEXT BranchINPUT

letter FROM action_5

23

signatureDate action_6OUTPUT

ALTERNATIVE ALT_ACCEPTform12 -- instruction for progression

ALTERNATIVE ALT_REVISEform13 -- instruction for investig.

ALTERNATIVE ALT_REJECTform12b -- reject motivation

END_ACTIVITY

ACTIVITY action_8: ReportOnInvestigationROLE Secretary OF CONTEXT BranchINPUT

form13 FROM ALT_REVISE OF action_7OUTPUT

form14 -- report on investigationEND_ACTIVITY

ACTIVITY action_9: DecisionOnCredibilityROLE Manager OF CONTEXT BranchINPUT

CONTEXT form14 FROM action_8OUTPUT

ALTERNATIVE ALT_ACCEPTform12 -- instruction for progression

ALTERNATIVE ALT_REJECTform12b -- reject motivation

END_ACTIVITY

END_DEF_PROC

Due to the fact in the WooRKS environment the client cannot interactdirectly with the system (and the system cannot deal directly with externalinformation sources), we have to consider activities which involve clients(and external information sources) as 'borderline' activities.As shown in Figure 8 two parts constitute this kind of activity: an'external' part, which cannot be implemented within the system (the leftone); and an 'internal' part, which is represented in ADL code (the rightone). Each time a client performs an action, the related internal partyregisters the event. Anyway, we can imagine 'borderline' activities asatomic; moreover, different WMSs allow the client to interact directlywith the information system of the bank.

24

EXTERNALWORLD

BANK

13

14

RegSignature

creditSecretary

ReportInvestig

creditSecretary

NewCreditProcAgencyDirector

1 2 3

PrelimInvestAgencyDirector

4 5 6

7

DecOnCred

agencyDirector

REJACCREV

PrepLetter

AgencyDirector

ACC REJ

DecOnCred

agencyDirector

12 12b

signatureDate

Letter

Client

Paper

Letter

Sign Letter

Signed

Letter

External Information

Source

Collect

Information

Infos

MeetClientAgencyDirector

Start

meetingDate

Meet Client

Client

Event

Registration

MeetClientAgencyDirector

meetingDate

Meet Client

Client

Event

Registration

Event

Registration

Event / Info

Registration

Figure 8: The Procedure in Accordance with ADL Formalism

In this perspective we can redraw the procedure as shown in Figure 9,where the presence of the client (or of the external information sources)simply becomes a precondition for the execution of specific activities.Thisrepresentation allows us to verify the linearity we have been able to reachusing our WMS.

25

13

14

ReportInvestig

creditSecretary

NewCreditProc

AgencyDirector

1 2 3

PrelimInvestAgencyDirector

4 5 67

DecOnCred

agencyDirector

REJACCREV

PrepLetter

AgencyDirector

ACC REJ

DecOnCred

agencyDirector

12 12b

signatureDate

Letter

Paper

LetterClient

Signed

Letter

External Information

Source

StartClient

Client

creditSecretaryRegSignature

Figure 9: The Procedure Redrawn Emphasizing Linearity

6. AN EXAMPLEWe want to show a specific case in which the coupled system UTUCS andWooRKS can both handle exceptions and reduce dimensions, complexityand costs of our process. During the process there are many situationswhere an exception may arise, and so a communicative activity devoted toresolving it may be started. For example, in the Preliminary Investigationactivity, the Agency director has to check the list of documents which theclient must deliver; if the client supplies some documents in place of therequested ones, because she thinks they are analog, it is possible that thedirector is not sure about the legal correctness of this substitution andshould ask for information. The first message of a new conversationopened by the Director is depicted in Figure 10. She requests theSecretary to get information from the legal office. This request forinformation is not provided for explicitly in the procedure; however it ispossible to handle it as an exception by means of the communicationsystem.In regard to the reduction of size, we can identify all the activities that canbe dropped. After the client has signed the credit request, the Director canconsider necessary initiating further investigations before taking anydecision. The Credit Procedure explicitly embeds this activity - as Figure11 shows. This information request is not really necessary in all cases.Hence it can be eliminated - reducing the procedure size - and handled asan exceptional case thanks to the communication system. Both the reportsrelated to the instructions for the further investigations and its outcomes(Figure 8/9 form 13 and form 14 respectively) are enclosed in the

26

conversation messages. We must emphasize that all requests forinformation, not only this one, can be deleted from the procedure.

Figure 10: The Opening Message

Figure 11: The Unnecessary Activity

27

7. BENEFITSIn the previous sections we have described a case study dealing withreengineering our Credit Procedure using the WMS technology. Let usnow discuss how the factors of the transaction costs of the CreditProcedure are decreased by the reengineered process.We distinguish the benefits deriving from the redesign of the processthrough the use of a WMS from those deriving from the use of theWooRKS-UTUCS environment.

Benefits deriving from the redesign of the process through the use of aWMS:- reduction of both the number of members of cooperation network and

of the number of sub-processes (Table 4). We must observe that the useof a WMS also allows the automation of the routing, linking andintegrating of individual activities (Fig. 9) reducing also the productioncosts of the Credit Procedure;

- limited reduction of the threshold of sustainable complexity of themanagers allowing them to interact effectively both synchronously andasynchronously. The help to recall the matter in question within a workprocess provided by a standard WMS is very small, since it is limited todisplaying, when necessary, the formal documents created within theProcedure and to monitoring its progress;

- the Procedure is easily modifiable, by means of the WMS facilities.

Further benefits deriving from the use of the WooRKS-UTUCSenvironment:- larger reduction of the threshold of sustainable complexity of the

managers, because the help to recall the matter in question within aprocess provided by the WooRKS-UTUCS environment extends itselfto support handling any breakdown within the context of theProcedure, and accessing together formal documents as well as theconversations through which the breakdowns were handled;

- the Procedure requires a smaller number of changes since it is reducedto its simple flow of actions, with no explicit exception handling loops.

CONCLUSIONSThe experience reported in this paper has given us some suggestions forthe system design. In fact it is possible to re-design the system in a moreeffective way (cutting off the unnecessary functionalities) on the basis ofnewly conceived components. In this way the resulting architecture of aWMS inspired by our approach can be radically different from both theWMSs embodying exception handling mechanisms, because its workflowmodels are simpler and therefore more easily modifiable, and the ActionWorkflow, because its conversation model is unstructured.

28

The above hints has been for us a relevant input for the new prototype,Milano, a work processes support system we are currently developing atthe Cooperation Technologies Laboratory.In fact,- Milano will integrate a WMS with a conversation handler as UTUCS-

WooRKS;- Milano will have a new WMS, that in allowing us to design simpler

workflows (without loops and without taking in account any exceptionhandling mechanism), obtains an easy modifiability both static anddynamic [Ellis & Keddara 1993], while granting the correctness of thechanges;

- Milano will have a conversation handler based on a newly definedconversation model that will interpret the language/action perspectivein a non prescriptive way [De Michelis & Grasso 1994].

ACKNOWLEDGEMENTSThis paper is an extended version of the one the authors presented atCOOCS'93 in Milpitas (California). The authors express their thanks toall members of the ITHACA project, in particular Martin Ader, JosepMonguio and Michel Tueni. We would like to thank the COMIC projectthat supports the study of transaction cost of work processes.Furthermore, the authors thank DATAMONT for supporting AlessandraAgostini in the integration phase of UTUCS in WooRKS and StefanoPatriarca in the implementation phase of the Credit Procedure. Finally wewish to emphasize the invaluable help given by Thomas Schael and BuniZeller of RSO Milan, who studied the credit procedure and supplied uswith a lot of material. The methods and tools used within this experimentwere partly supported by the European Community within the ESPRITProgramme, respectively by the BRA COMIC (ESPRIT #6225) and theITHACA (ESPRIT #2705) Projects.

REFERENCESAbbott, K.R., and Sarin, S.K. (1994) Experiences with WorkflowManagement: Issues for The Next Generation. In Proceedings of the 5thConference on CSCW, ACM, New York, NY, pp.113-120.Ader, M., Lu, G., Pons, P., Monguio, J., Lopez, L., De Michelis, G.,Grasso, M.A., and Vlondakis, G. (1994) WooRKS, an Object OrientedWorkflow System for Offices. Technical Report ITHACA, Bull S.A.,T.A.O. S.A., Università di Milano, and Communication and ManagementSystems Unit.Agostini, A., De Michelis, G., Patriarca, S., and Tinini, R. (1994) APrototype of an Integrated Coordination Support System. In ComputerSupported Cooperative Work. An International Journal, 2.4, pp.209-238.Bowers, J., Churcher, J. (1988) Local and Global Structuring ofComputers Mediate Communication: Developing Linguistic Perspective

29

On CSCW in COSMOS. In Proceedings of the 2nd Conference on CSCW.ACM, New York, NY, pp.125-139.Bullen, C.V., and Bennett, J.L. (1990) Learning from User Experiencewith Groupware. In Proceedings of the 3rd Conference on CSCW. ACM,New York, NY, pp.291-302.Ciborra, C. (1993) Team, Markets and Systems. Cambridge UniversityPress, Cambridge, UK.Davenport, T. (1993) Process Innovation. Harvard Business School Press,Cambridge, MA.De Cindio, F., De Michelis, G., Simone, C., Vassallo, R. and Zanaboni,A. (1986) CHAOS as a Coordination Technology. In Proceedings of the1st Conference on CSCW. MCC, Austin, TX, pp.325-342.De Cindio, F., Simone, C., Vassallo, R., and Zanaboni, A. (1988)CHAOS: a Knowledge-based System for Conversing inside Offices. InOffice Knowledge: Representation, Management and Utilization. NorthHolland, Amsterdam, The Netherlands, pp.257-276.De Michelis, G. (1990) Computer Support for Cooperative Work. ButlerCox Foundation, London, UK.De Michelis, G. (1994) Computer Support for Cooperative Work:Computers between Users and Social Complexity. In OrganizationalLearning and Technological Change. Springer Verlag, Berlin, Germany.(to appear).De Michelis, G., Grasso, M.A. (1993) Routines and Conversations. InStructured Programming, 14, pp.110-118.De Michelis, G., Grasso, M.A. (1994) Situating Conversations Within theLanguage/Action Perspective: The Milan Conversation Model. InProceeding of the 5th Conference on CSCW. ACM, New York, NY,pp.89-100.Ellis, C.A., Gibbons, R., and Morris, P. (1979) Office Streamlining. InNaffah, N. (ed.): Integrated Office Systems-Burotics. North-HollandPublishing Company, Amsterdam, pp.111-125.Ellis, C.A. (1982) Office Talk-D: An Experimental Office InformationSystem. In Proceeding of the 1st Conference on Office InformationSystems. ACM, New York, NY, pp.131-140.Ellis, C.A., Gibbs, S.J and Rein, G.L. (1991) Groupware: some issues andexperiences. Comm. ACM 34.1. pp.39-58.Ellis, C.A., Keddara, K. (1993) Dynamic Change within WorkflowSystems. Technical Report July, University of Colorado.Hall, G., Rosenthal, J., and Wade, J. (1993) How to Make ReengineeringReally Work. Harvard Business Review. Nov. Dec., pp.119-132.Hammer, M. (1990) Reengineering Work: Don't Automate, Obliterate.Harvard Business Review, July/August, pp.104-111.Hammer, M., Champy, J. (1993) Reengineering the Corporation: AManifesto for Business Revolution. Harper, New York, NY.Keen, P.G.W. (1991) Shaping the Future: Business Design throughInformation Technology. Harvard Business School Press, Boston, MA.

30

Kreifelts, T., Hinrichs, E., Klein, K.H., Seuffert, P., and Woetzel, G.(1991) Experiences with the DOMINO Office Procedure System. InProceedings of the 2nd European Conference on CSCW. Kluwer,Dordrecht, The Netherlands, pp.117-130.Medina-Mora, R., Winograd, T., Flores, R., and Flores, F. (1992) TheAction Workflow Approach to Workflow Management Technology. InProceedings of the 4th Conference on CSCW. ACM, New York, NY,pp.281-297.Robinson, M. (1991) Computer Supported Co-operative Work: Case andConcepts. In Hendriks, P.R. (ed), Groupware 1991: The Potential ofTeam and Organisational Computing. SERC, Utrecht, The Netherlands,pp.59-75.Sarin, S.K., Abbott, K.R., and McCarthy, D.R. (1991) A Process Modeland System for Supporting Collaborative Work. In Proceedings of theConference on Organizational Computing Systems. ACM, New York,NY, pp.213-224.Schael, T., Zeller, B. (1993) Workflow Management Systems forFinancial Services. In Kaplan, S. (ed.). In Proceedings of the Conferenceon Organizational Computing Systems. ACM, New York, NY, pp.142-153.Scott-Morton, M. (1991) The Corporations Of The 1990s: InformationTechnology And Transformation Of Organizations. Oxford Press, NewYork, NY.Suchman, L. (1987) Plans and Situated Actions. Cambridge UniversityPress, New York, NY.Suchman, L. (1993) Do Categories Have Politics? The Language/ActionPerspective Reconsidered. In Proceeding of the 3rd European Conferenceon CSCW. Kluwer, Dordrecht, The Netherlands, pp.1-14.Swenson, K.D., Maxwell, R.J., Matsumoto, T., Saghari, B., and Irwin, K.(1994) A Business Process Environment Supporting CollaborativePlanning. In Collaborative Computing, 1.1, pp.15-34.White, T.E., Fischer, L. (eds.) (1994) The Workflow Paradigm. FutureStrategies, Alameda, CA.Williamson, O.E. (1975) Markets and Hierarchies. Free Press, New York,NY.Winograd, T., Flores, F. (1986) Understanding Computer and Cognition:A New Foundation for Design. Ablex Publishing Corp., Norwood, NJ.Winograd, T. (1988) A Language/Action Perspective on the Design ofCooperative Work. In Human Computer Interaction, 3.1, pp.3-30.