Workcase-centric workflow model

Jacques Wainer and Paulo Barthelmess
Department of Computer Science
Universidade Estadual de Campinas, Brazil
{wainer, paulobar}@dcc.unicamp.br

Abstract

We present a model of office work and workflow systems that we call workcase centric, based on the view that office work is a collaborative construction of a case artifact.

This model allows for the uniform treatment of cases for which the organization has no predefined procedure, of exceptional cases where the standard procedure must be modified, and of standard cases.

Introduction

Most of the existing workflow management systems target formal procedures automation only. Informal or unstructured procedures are, for the most part, treated as exceptions. As the name implies, exceptions are by definition things for which no support is provided, because they should be rare. As a result, the most challenging and demanding organizational work is not dealt with.

In these systems, there is usually a clear cut separation between modeling and enactment, due perhaps to the influence of traditional systems analysis. This approach seems not to work well for workflow systems, because of the much more fluid nature of office work. In order to cope with diversity, at enactment time one must plan, re-plan and execute activities, all simultaneously. Users must take the role normally performed by systems analysts, modeling new situations in an ad-hoc manner at execution time.

Based on these views, we propose a different metaphor for the office activity, with important consequences for the design of workflow systems. Office work should be seen as a collaborative construction of an artifact: the workcase. Office workers collectively construct a workcase, by performing actions to this workcase. We call this a workcase centered approach to office work and workflow systems.

We oppose the workcase centered view to the traditional view, where office work is seen as a sequence of well defined activities performed onto well defined objects. The traditional view emphasizes the modeling activity, the workcase-centric model emphasizes the enactment.

There are three important consequences deriving from workcase centered view:

The workcase cannot be defined a priori, or in other words, one cannot model what workcases are or will be. The users in the process of their office work will create different artifacts, sometimes through very creative/unplanned/non-standard means, for different situations.
The central aspect of a workflow system is to provide the user with tools to alter, add to, modify the workcase being constructed. Thus a workflow system should be more concerned in providing tools for the performance of the activities than to control how these activities should be ordered.
It is the user - the office worker - how knows how to get the job done. Instead of trying to straight-jacket the user, our model let him drive the process the way he sees fit.

The remainder of this paper presents our proposed model. Section 2 gives a model overview. Sections 3, 4 and 5 presents work, flow and workers related aspects respectively. The paper ends with conclusions and a bibliography.

The Artifact

The main metaphor for the workcase artifact is a folder in non-automated office systems. A folder contains the forms used in the normal processing of the workcase, but also may contain a fax from the client stating that the missing documents were send by currier, a note from a faculty to the graduate candidate selection committee saying that she has spoken with the candidate and doubts he is really committed to graduate studies, a post-it note attached to the form that explains that the customer's phone number will change in March, a memo from the Marketing V.P. stating that this customer's processing should proceed as urgent as possible, copies of the all the mail exchanged with the client's engineering department about requirements, and so on. A folder carries the context of that case, that is, it contains all the information the office workers believe will be useful for the subsequent processing of that case.

The main aspect of the workcase artifact is this ability to add to it new and unpredictable information, which will be inspected and modified at a later time. The fact that the workcase artifact is an computational implementation of a folder allows one to overcome a series of short comings of folders in offices. Among these deficiencies are:

All documents in a folder are visible to all that have access to the folder. In our system, the information added to the artifact have different modes of access control. A new information may be restricted by activity and by user. For example, the information about the salary of a manager being hired may not be accessible to the activities of entering the new employee into the organizational databases or updating the organization's charts, but may be accessible to the activity of writing the contract. On the other hand, a memo from the marketing V.P. exempting a client from credit check should only be accessible to a few people in the organization. On the limit, an user can attach to a case information that only he can access, to document to himself why certain decisions were made, but precluding other members in the organization of having access to his expertise.
A folder is only accessible to the person in whose desk the folder is at the moment. Therefore paper folders cannot be replicated and, more important, cannot be searched for information. On the other hand, the workcase artifacts are stored in a database. There can be parallel activities acting upon the same workcase and the workcase database can be queried about workcases that bare some similarity with a current one.
There is another important consequence of the fact that workcases are stored: users that are not responsible for current activities being performed onto the workcase may have access to it. This is very important to deal with asynchronous events (or signal exception [BW95]) related to the workcase: the awareness of an asynchronous events may come to someone that is not currently working on that workcase - a secretary receives a letter from the customer cancelling a purchase order while the purchase order is in the activity of production scheduling - and that office worker must have access to the workcases in order to associate the event with the workcase.

Finally there is another aspect of the folder that is important for our model: folders are untyped - folders can store any kind of documents and can be used for any process in the organization. The equivalent of this property for the workcase artifact is that these artifacts should be dynamically typed and that a most generic artifact type should be available. Sometimes an organization receives requests that cannot be classified as one of its standard procedures and yet it must be dealt with, necessarily in an ad-hoc way. Sometimes a request is not recognized immediately as one of the standard organization's procedures, and so the case is "passed around" until someone realizes that the workcase can be typed as one of the standard types and proceed from there on. Sometimes a workcase of a certain type, say a purchase order, becomes a workcase of another type, say suing the customer.

Work, in our model, is to add new information to the workcase and to transform information already present. The essence of an activity is an interface to the components of the workcase artifact. This emphasis on the activity itself is somewhat different form traditional workflow systems which put more emphasis on the process modeling.

The Flow

The sequencing of activities (or in fact the next activity to be executed) will be determined by the values of four data items in the workcase artifact that are interpreted by the workflow management system. With this four fields, which can be set and altered by the user, one can have a uniform treatment of the flow of cases that varies from a totally new case to a standard case.

The main task of the workflow management system is to determine when an activity ends what will be the next activity and who will perform it (the WFMS also has to perform synchronization of and-joins and batch activities [BW95] but we will not discuss these issues in this paper).

At the end of an activity the system verifies the two data items: next activity, next executor and if they are set, those will be the next activity and the executor of that activity. Given the characteristics of this case a user may decide that his boss and not him should approve the credit, or that the organization legal department should give some opinion about the contract, or that John Smith should perform this activity instead, since John Smith knows well the client, an so on.

If these fields are not set by the user, then the workflow management system uses the plan data item to determine what is the next activity/executor pair. The plan is represented as rules that may access other workcase data, databases and so on, in order to determine the next pair activity/executor. We believe that there is a representational inadequacy of using simple graphic languages to represent the plan for an workcase, as it was pointed out by [Bus94,KLR+95] among others, and that stronger representations are needed.

The important aspect is that the plan is part of the artifact and thus can be altered by users with the correct permission. This adds the possibility of re-planing at enactment time [BK95] [SMM+94]

The last interpretable data item of the workcase is thereturn stack. Each entry in the stack is a pair activity/executor, and next activity, next executor can be set to the top element of the stack. Thus the return mechanism allows an activity to "subcontract" other activities, that is to become a goal node allowing "open ended processing to perform exception handling" [EN93]. This lets coordination to be maintained between interdependent tasks and yet allows discretion at the local sub-task level.

With the combination of these features, the system could allow for the following work situation: when credit checking a client, Maria sends the case to the legal department (via the next activity, next executor pair) for an opinion on some documents attached by the client. At the legal department the case is "send around" until someone realizes that Toshi has experience with this kind of document and send it to him. Tom writes the comment and sends it back to Maria (via the return data item). Given the legal opinion Maria sends the case to her manager, who decides that all authorization on this case should be done at the V.P. level (and thus alter the plan) and sends the case back to its now modified processing.

Conclusions

We have presented a model that separates coordination from activity support, providing a coordination kernel that allows flexible processing of both structured and unstructured activities in a uniform way. We have also argued that the actual work support is best provided by artifact construction.

References

[BK95] D.P. Bogia and S.M. Kaplan, Flexibility and Control for Dynamic Workflows in the wOrlds Environment, in Proceedings of the 1995 ACM Conference on Organizational Computing Systems (COOCS'95), N. Comstock and C.A. Ellis (eds.), pp 148--159, Milpitas, California, 1995.

[BN95] R. Blumenthal and G.J. Nutt, Supporting Unstructured Workflow Activities in the Bramble ICN System, in Proceedings of the 1995 ACM Conference on Organizational Computing Systems (COOCS'95), N. Comstock and C.A. Ellis (eds.), pp 130--137, Milpitas, California, 1995.

[Bus94] C.J. Bussler, Policy Resolution in Worklow management Systems, Digital Technical Journal, vol. 6 number 4, pp. 23-49, Fall 1994.

[BW95] P. Barthelmess and J. Wainer, Workflow Systems: a few definitions and a few suggestions, in Proceedings of the 1995 ACM Conference on Organizational Computing Systems (COOCS'95), N. Comstock and C.A. Ellis (eds.), pp 138--147, Milpitas, California, 1995.

[KLR+95] G. Kappel and P. Lang and S. Rausch-Schott and W. Retschitzegger, Workflow Management Based on Objects, Rules, and Roles, in Bulletin of the Technical Committee on Data Engineering, IEEE Computer Society, vol. 18, number 1, pages 11-18, March 1995.

[Rob93] Robinson, M., Design for Unanticipated Use..., Proceedings of the Third European Conference on Computer-Supported Cooperative Work, sept. 1993, G. de Michelis, C. Simone and K. Schmidt (Editors).

[SMM+94] K.D. Swenson and R.J. Maxwell and T. Matsumoto B. Saghari and K. Irwin, A Business Process Environment Supporting Collaborative Planning, in CSCW'94, ACM, 1994.