Abstract

Workflow management systems are an effective means of guaranteeing a high quality in the execution of business processes and services. Furthermore, they enable the establishment of telework places which are gaining more and more importance in the competitive business environment. Despite the obvious advantages, there are still some obstacles which will have to be overcome to make distributed working a real success. One of the major drawbacks of the existing systems is that they have no means of supporting synchronous co-operative work e.g. by using multimedia desktop conference systems. Another shortcoming is that only first steps have been done to establish interfaces between workflow management systems. As a consequence, it is hardly possible to execute one coherent workflow using different workflow management systems. The integration of control data for other applications like conference relevant information has not been taken into account. In this contribution we present some concepts which lead the way to more developed, intelligent, distributed assistant systems which will be able to comprehensively support co-operative work.

We aim at the interoperability of hetrogenuous applications into an enterprise and over enterprise borders, to establish a service which optimal supports work in an virtual enterprise (see fig. 1).

Fig. 1: Architecture of enterpriseware [Cole95]

The concepts described are based on the work from the project WoTel of the Siemens AG (developed with other major companies and the German Telekom) and from the project Polivest, from SNI AG and Siemens AG with the German Ministry for Research.

Integration of synchronous co-operative work

Workflow management systems can only support more or less sequent tasks what we call asynchronous telecooperation. They proceed on the assumption that work can be divided into steps so that every step can be handled with the results of the former steps and knowledge of the current employee. They also presume that no mistakes have been done earlier in this chain. Unfortunately in daily work there are many violations on these assumptions. Finally today's workflow management systems do not take into consideration that even well structured operations include often tasks that strongly influence each other because the nature of the tasks is interrelated, concurrent or informal. These processes could not be captured by a workflow management system. The use of Multimedia Collaboration (MMC) Conference systems can contribute to eliminate these drawbacks, since they allow to work together in teams on specific topics, directly from the desktop without leaving once place. This mode of operation we call synchronous telecooperation. Additionally the integration of MMC Conference systems into workflow management systems allows to contact managers, other workflow participants or the system support group without lengthy interruptions.

Another advantage of MMC Conferences is the reduction of media breaks which inevitably occur when a workflow participant leaves his place to join a "normal" conference.

Distinctive Characteristics of Multimedia Conferences

In the workflow context, basically MMC Conferences can be differentiated by the following aspects (see also [SSS 96], [SMDSS 96]):

Moment of Modeling
Coordination of the Conference

Moment of Modeling

Considering the time when the conference is modeled we can distinct two instants. Conferences that are already planned at the moment of the development of the workflow are called pre-scheduled conferences.

In contrast to that the occurrence of an ad-hoc conference is not foreseeable at the time where the workflow is specified, e.g. because of an unexpected problem. The point of starting a MMC Conference depends on the actual situation. At the development time there are no information about the conference, because at this time no conference is planned.

Coordination of the Conference

A further possibility to distinct MMC Conferences is how or by whom the execution of the conference will be controlled and coordinated (see [RSVW94]). If the conference is coordinated by the system it is called static conference. If it is coordinated by a participant of the conference we call it dynamic conference.

As static conferences are concerned the content and the way how the conference will be executed are described in detail. The conference activities are fixed (see also [Jabl94]). The conference has a rigid and somehow inflexible structure. The conference activities are totally transparent to the workflow system. Consequently the workflow can interrupt and reinvoke the conference.

In contrast to this the execution of a dynamic conference is free and imposes no constraints on the conference participants concerning the way how they organise their work during the conference. They are the only responsible for the conference coordination. The content is specified by the subject of the conference and an agenda. At the beginning of the conference the conference activities need not to be fixed. The workflow refers to the work on this agenda as a single process activity.

Checklist

Beside the usual applications like Word or Excel the checklist is an additional document that will be shared during a MMC Conference. It is a tool to support the co-ordination of conferences. As for static conferences all conference activities are workflow activities the checklist serves only as an agenda. Here it is only a supplementary information source for the conference participants.

Fig. 2: Checklist

Dynamic conferences need the checklist for conference coordination and monitoring. It describes the activities for the conference like a to-do list, which can be dynamically changed (expanded or shortened). Furthermore the checklist is a tool to record the conference results. Figure 2 shows how the checklist looks like. The row containing "activity state" indicates whether all conference activities are completed. If the conference is interrupted and continued some days later the participants know which activities have been completed and on which activities work is required. This is necessary because the workflow cannot support this task as he refers to the conference as a single process activity. The row "importance" enables the conference participants to postpone or ignore activities that do not necessarily contribute to a successful conference result such as activities like writing a protocol. This is a means to offer a more way to work during MMC conferences. The "Checklist Responsible" is regarded as a conference leader. This person undertakes the conference coordination. The concept "task responsible" in conferences is the same than in workflow management systems. So conferences and workflows can be analysed by a uniform evaluation mechanism. Furthermore the checklist can be adapted to specific requirements, e.g. by introducing timestamps for billing purposes.

Workflow-Workflow Interoperability

Since workflow management systems and their functional scopes are not standardised until now, many different products are available. Depending on their strength each of these different systems will be used to support specific tasks or to satisfy the requirements of the particular companies, departments within companies, etc.. For this reason in the future it will become a must to have interoperability concepts to connect these different products. A workflow will neither have to stop at enterprise borders nor will an enterprise have to concentrate on a single product. So business and task specific workflow frameworks will be established that exploit the advantages of the workflow management systems used. Furthermore only these interoperabiltity concepts make it possible to efficiently establish virtual enterprises.

Workflow Connect (WfC)

The protocol

The execution of processes over multiple workflow systems will be synchronised by sending messages with specific protocol information (and documents) from one workflow management system to the other over a connection and communication service. Looking at the heterogeneity in the area of workflow management systems the protocol must be very general to fit with all of them. Specific information need not be transmitted. It consists of two parts:

Workflow related part
Application specific extensions

Connection Service specific extensions

The Workflow related part of the protocol contains actions, that will be executed on the other workflow system. Additional parameters for control are also part of the protocol, to guarantee correct execution and addressing.

Application specific extensions:

This block is used to give the possibility to make the protocol individual configurable and easy extendible. It will be used by applications to transfer specific information.

Error handling

In case of an error, an error message will be send to the initiating workflow management system with an error code.

Realisation of WfC

The realisation of the transmission of the data, the protocol etc. and the synchronisation will be done by the WfCClient (fig. 3). The WfCClient also includes objects like documents and sends all as a request in the context of a session with an unique ID to the partner WfMS. The ID is used to unique assign replies, confirmations, actions, etc. to the right session [Mull94]. The model demands, that the execution of a task defined in a request will be done exactly once, that means the session must be an atomic transaction, which satisfies the requirements of the "at-most-once"-semantic. The session itself will be initiated by a process activity within the flow.

The whole session consists of the preparation of a request with the protocol and the needed objects, the transfer of the request to the connection service, the actions to transmit it to the WfCServer of the receiving system and the execution of the specified action.

Fig. 3: e-mail solution

Features for the parsing of workflow management system related e-mail contents, address resolution, time-out mechanisms for lost mails, automatic receipts to avoid multiple sending of messages have been included. The WfCClient and WfCServer have been implemented in a modular way, so that the change of the underlying connection service is simple.

Literature

[Cole95]	Coleman, D., Groupware Technology and Applications: An Overview of Groupware, in: Groupware Technolgy and Applications, Coleman, D., Khanna, R., (Hrsg.), Prentice Hall PTR, New Jersey, 1995
[SSS96]	Schneider, G., Scheller-Houy, A., Schweitzer, J., Vom Workflow-Management-System zur Vorgangsbearbeitungsplattform mit integrierter Telekooperation, in: Proceedings of the D-CSCW'96, Stuttgart, September 1996, to appear
[SMDSS96]	Schneider, G., Maus, M., Dietel, C., Scheller-Houy, A., Schweitzer, J., Concepts for a flexibilisation of workflow management systems with respect to task adaptable solutions, in: Proceedings of the AAAI-Workshop "AI in Business", Portland, Oregeon, August 1996, to appear
[RSVW94]	Reinhard, W., Schweitzer, J., Völksen, G., Weber, M., CSCW Tools: Concepts and Architectures, in: IEEE "Computer", May 1994, Vol. 27, No.5
[Jabl94]	Jablonski, S., MOBILE: A Modular Workflow Model and Architecture, in: Proceedings of the Fourth International Conference on Dynamic Modelling and Information Systems, Noordwijkerhout, The Netherlands, 1994
[Mull94]	Distributed Systems, Sape Mullender et al., Addison Wesley, ACM Press, 1994