WWW Front-ends for Document andWorkflow Management Systems

Wargitsch, ChristophBavarian Research Center for Knowledge-Based Systems (FORWISS)

Information Systems Research GroupAm Weichselgarten 7

D-91058 Erlangen, Germany; wargitsch@forwiss.uni-erlangen.de

Wewers, ThorstenWirthmüller, Andreas

University of Erlangen-NurembergComputer Science Research Group B

Martensstr. 3D-91058 Erlangen, Germany; wewers@wiso.uni-erlangen.de

Abstract: World Wide Web techniques have a great potential for integrating informa-tional resources as well as application systems over the internet as well as within a cor-porate intranet. The same approach is taken by workflow management systems: They areoften described as the "backbone" of a company’s IS. We propose a workflow front-endbased on the World Wide Web covering most of the functionality desired for a conven-tional workflow front-end. As the underlying server system, we use a professional, large-scale workflow management system.

1. Introduction

Workflow Management Systems (WMS) control and manage business processes in compa-nies. They are often deemed the key factor in implementing reengineering measures, and dueto their inherent process orientation they take up an outstanding position among informationand communication systems. WMS are also described as being the "backbone" of a com-pany’s IS [Mert96b].

The Internet with all its uses, especially e-mail and the World Wide Web (WWW), is dis-seminated widely. WWW techniques are very well suited to make the most of a WMS’s inte-gration potential. In the beginning of the WWW, solely the static HTML (Hypertext MarkupLanguage) was used in order to display textual and graphical information. Soon after this,audio and video elements were added. Finally, the Common Gateway Interface (CGI) was in-troduced to especially link databases and to generate dynamic web pages. The next step, i.e. tobuild complex web-based information and communication systems, is obvious.

In this paper, we propose a WWW front-end for document and workflow management sys-tems. In particular, this front-end has been conceptualized for a document-oriented WMS("BusinessFlow" from COI GmbH - Consulting for Office and Information Management), andthe paper will discuss the already implemented components. The basis architecture is depictedin Figure 1-1. The core element is the Hypertext Transfer Protocol (HTTP) server that is en-tirely integrated into the object-oriented WMS and that can access its methods and databasecontents. An interface like the CGI is unnecessary.

Chapter 2 introduces basic aspects of workflow management as far as they are relevant for thesubsequent sections. Chapter 3 gives a short overview of internet and intranet technologies. Inchapter 4, the goals of WAX (Web-AXessed Workflow Management) are presented. Chapter5 comprises the main part of this paper: The concept and implementation of WAX are intro-duced. We structure the single functions following the Workflow Management Coalition’sreference model. Chapter 6 summarizes the fundamental statements and includes future steps.

2. Workflow Management Systems

2.1. Document-oriented WMS

Many attempts have been made to characterize and to classify the existing great variety ofWMS. One way to organize them is according to their origin [ErSc93; WeKr96]. There aresystems that have developed from operative applications, systems that have their roots indocument management systems, in e-mail systems, word processors, groupware products, per-sonal information systems, and imaging systems. In addition, there are systems that haveoriginally been developed as workflow products. Overviews of different ways of catalogingWMS can be found in [ScBö96; WeKr96], the state-of-the art in [Mumm96; Rech94].

Irrespective of special products, the general direction of WMS in terms of the informationflow is interesting [Vogl93, pp. 48]:

q Flow-oriented systems emphasize the information flow itself.

q With flow-object-oriented systems, the information that is transported becomes the focus ofattention. The approach of the Message Objects [RiNa96] is an example of this. Anotherextension to interorganizational processes is described in [WeFa96; Wewe96].

q With organization-oriented systems, the flow environment is the focal point. The systemsassume that the underlying organization implies its processes and does not need explicitprocess descriptions.

q Flow-subject-oriented systems give a special emphasis to the people that are involved.

WWW Browser

WWW Browser

OEL-HTTP-Server

WMS

DMS

RequestMethodCalls

Return of Data

+ Documents

Java-Applets

+ Graphics HTTP-ServerApache

HTML

Request

Figure 1-1: Architecture of the WWW front-end

The coordination model underlying a WMS is important in terms of the organization. Theprocess-oriented coordination form tries to structure the organizational workflows from acentral viewpoint, the coordination of the single activities of a process are in the foreground ofthe discussion [Schw96, pp. 306].

In this paper, we consider document-oriented WMS that manage business processes. A proc-ess is a metaphor for a special coordination form [Schw96, p. 298]. Documents reflect manyresults of business processes in the manufacturing and service industry as well as in publicadministration. In Germany, the business of WMS, especially document-oriented systems, isbooming [Yaki96]. Document-based WMS have the advantage of mirroring the traditionalpaper-based workflow very well. Most systems of this kind offer an electronic documentfolder as central workflow object. During the course of the workflow, this folder is beingrouted from one employee to the other and enriched with information that constitutes the re-sults of the single activities. Usually, the workers are not directly associated with an activity,but linked to it by a role. A role can encompass several employees and vice versa. At the endof the workflow, the document folder with all its audit data is archived.

2.2. The Workflow Management Coalition’s Reference Model

The Workflow Management Coalition (WfMC) is an association of WMS vendors and inter-est groups aiming at defining standards in the quite heterogeneous area of workflow manage-ment. This pertains to the development of a terminology on the one hand, and of an architec-ture model on the other hand. So far, the WfMC passed a glossary [WfMC96a] as well as areference model [WfMC96a; Vers95] that is depicted in Figure 2-1.

The reference model includes a central workflow engine with five interfaces. With interface 1,process definition tools are linked to the engine. Such a tool may be a graphical editor allow-ing for the modeling of workflows as activity networks. Interface 2, that has already been

Workflow Enactment Service

Workflow API

Inte

rfac

e 5Administration

and MonitoringTools

ApplicationsWorkflowClients

Other WorkflowEnactment Service

Interface 4

Interface 2 Interface 3

Interface 1

Workflow EngineWorkflow-Engine

Process DefinitionTools

Figure 2-1: The reference model of the Workflow Management Coalition

adopted by the WfMC, offers functionality to the front-end from where a workflow participantlogs on to the system, gets his to-do lists, and so on. With the help of interface 3, applicationsystems, often legacy software, that are necessary to execute certain workflow activities, aremanaged. Interface 4 controls the data exchange with other workflow engines. Explicitly, theexchange of documents and workflow control data over the internet standard MIME encodingis proposed [WfMC96b]. Finally, interface 5 defines the access of administration and moni-toring tools, e.g. user administration or process control, to the engine.

The WfMC describes these interfaces as five APIs (Application Programming Interface) andcalls the entirety WAPI (Workflow API). It is not defined, however, how the proposed func-tions have to be called. At this point, the WfMC leaves it up to the vendors to decide whetherto use, e.g., an RPC (Remote Procedure Call) or a messaging mechanism.

2.3. Extensions to the Reference Model

The model described so far contains components of a WMS from a technical point of view.Planning, implementing, introduction, and maintenance do not lie within its scope. The fol-lowing sections try to make up for this deficit.

2.3.1. Integration of Planning and Administration/Monitoring

The separated view on process definition tools on the one hand and administration/monitoringtools on the other, makes sense only if one assumes that all workflows of a specific type canbe mapped into a business process model or a workflow type model. This is not the case formany complex business processes that cannot be structured entirely. Instead, for this type ofbusiness process, we propose to configure workflows explicitly according to the requirementsof a concrete business case (see section 5.2.2.) [WaWe97]. The tasks "process definition" and"workflow administration" are integrated to one unit: the "workflow configuration". Build andrun time are fused. For the reference model, this means that the interfaces 1 and 5 collapse andmanage a combined definition and administration tool.

2.3.2. Integration of the Enactment Services

In a big company, usually several WMS will be implemented, particularly with respect to the"manageability" of large workflow applications; "large" in organizational and technical terms.It seems hardly possible to support all process types within a company by a single system –the requirements for the workflow modeling and definition, that would have to be carried outat once in order to remove every media clash, and the requirements for the technology, thatwould have to guarantee acceptable response times and data consistency, are too difficult. Forthese reasons, a big company will always employ several WMS. Thus, a homogeneous userview on the services of the WMS has to be created, and workflows must be freely moveablebetween different systems. This leads to a transparent view for the user; he does not noticeanymore for which WMS he actually performs actions, where the offered applications arestored, or on which DMS the data reside. Deiters et al. follow a similar concept with theirproprietary architecture VORTEL [DLB+96]. We base our approach on WWW techniques. Inaddition, such a decentralized WMS landscape enables an evolutionary workflow manage-ment: Starting with a WMS for one department, or even with a special workflow, subse-quently more WMS can be added. The existing WMS need no or only slight modifications.The mature structure then forms a decentralized WMS offering a high degree of manageabilityand modularity.

2.3.3. Integration of Document Aspects

Functions and data types to process documents, that are the core element of workflows withina document-oriented WMS, lie beyond the scope of the WfMC’s WAPI. They are indispensa-ble, though. The interface 4 may serve as an example: If a workflow is to be started on a re-mote WMS, workflow control data, e.g. the workflow type to be instantiated, have to bepassed. In addition, the remote system also needs the initial document, which may also be theworkflow folder. Section 5.4.1. describes a MIME-based communication server that transfersand receives workflow control data and documents.

3. Internet/Intranet

Currently, the internet and its use are growing rapidly. Many of its advantages and techniquesare increasingly exploited within a company’s "fire wall" as well; this is called an "intranet".

3.1. Internet

In addition to "traditional" users like universities or research institutes, the internet experi-ences increasing interest by commercial enterprises, too. Especially e-mail and the WWW aremuch-liked services. Market researchers predict a surging turnover that will be realized by thisdistribution channel over the next years [NN97]. However, the different forecasts vary heavilyfor single industries. A data collection on the meanwhile impressing professional use of theinternet can be found in [Kurb96, p. 2].

3.2. Intranet

In general, it is expected that the focal point of web-based activities will shift from the internetto the intranet. The number of intranet web pages exceeded the number of internet pages al-ready in 1996 and will be four times higher by 1999 according to a Braxter & Partner estimate[NN96]. High-performance servers for the intranet and elaborate intranet solutions are beingoffered by almost every large hardware and software vendor. Doubts in terms of data securitylose in importance with intranet solutions being separated from the outside by a fire wall.

3.3. Techniques

A simple page description language such as HTML with a limited "life of its own" does notsuffice to bring the whole functionality of an application system to the WWW. For example,actions like data transfer between input controls cannot be connected to "tags". This gap isfilled by script languages that make use of the CGI or programming languages like "Java" bySun as well as the ActiveX technology by Microsoft.

q Basic technology: HTML. The language HTML belongs to the SGML (Standard General-ized Markup Language) family, but includes only a small fraction of the latter's possibili-ties. For example, SGML's powerful elements to structure documents are almost entirelyneglected. The actual standard HTML 3.0 is supported by most common WWW browsers.Besides, there are some vendor-specific extensions, e.g. the possibility to subdivide thebrowser window into several frames in order to structure the page contents, or to realizecomplex navigation tool bars. Furthermore, special additional "plug-ins", that can be addedto Netscape's Navigator e.g., enhance the presentation and communication capabilities viaWWW by virtual-reality applications, voice mail, and so on. All the data are transferred bythe stateless protocol HTTP.

q CGI/Script languages. In order to cope with interactions with the web server, HTML offerselectronic forms. The contents of these forms is fed into a CGI program which "answers"with another HTML page. This functionality has been prevailingly used to query or updatedatabases. Generally, a CGI program can be realized in any programming language, thoughmainly script languages like PERL, TCL, etc. are employed. A drawback of CGI program-ming is the statelessness of the HTTP protocol that can be partially circumvented by"cookies" containing session information. Usually however, the browser has to transfersome session data each time the client opens a connection to the server. Another disadvan-tage is that the WWW clients do not participate in an update mechanism, i.e. they cannotbe informed about changes in the databases the CGI program works on. This shortcomingis remedied by a Java program.

q Java/Active X. HTML offers only very restricted functionality on the client side. It is notpossible to manage complex interactions with the user. To remove these limitations, pro-gramming languages like Sun’s Java [Flan96] or Microsoft’s ActiveX have been invented.With these languages, complete applications, so-called "applets" in Java, can be loaded intoand executed within the browser. An applet runs on the browser’s virtual machine and hasfar-reaching access to the client computer. Thus, the virtual Java machine includes manysecurity mechanisms. A complex application is composed of several Java classes that areautomatically loaded from different servers. This ensures that always the latest version is atthe user’s disposal even without any system administration on the client side.

4. Costs and Benefits

Generally, the advantages of WAX can be classified according to its location: within a com-pany’s computer network (intranet) and outside or between companies (internet). However,most benefits hold for both locations and are therefore treated together. If significant differ-ences can be identified, we explicitly state them.

4.1. Technical Advantages

Several technical advantages over "traditional" front-ends arise by using WWW front-ends forDMS/WMS. They can be classified in terms of hardware, software, and network technology.

4.1.1. Hardware

Due to the availability of WWW browsers on almost every platform, no additional hardwareneeds to be acquired. Compared to conventional WMS clients, WWW browsers save re-sources ("thin/lean client"), a hardware upgrade can be avoided in most cases.

4.1.2. Software

The argument of platform independence also holds for the software used: For every commonoperating system and their user interfaces, WWW browsers exist. Because of the open stan-dards, all existing browsers can be equally used, and a comfortable independence from thebrowser vendors results. The installation of WAX is very easy, it is equivalent to installing aWWW browser, further actions are unnecessary. We did not use any exotic browser plug-ins.The advantages when patching or updating actual program versions are very well known fromthe discussion about the net computer and "network-centered computing". Maintenance is justcarried out on the server side.

4.1.3. Net Architecture

A higher availability of the communication infrastructure comes along with a distributed net-work architecture like the internet: The message routing depends on the availability of net-work nodes, i.e. a message is flexible in terms of the path it takes. Hence, the internet or anintranet are well prepared against system failures. Exceptions are of course non-redundantgateways between net segments. The routing is transparent to the user.

4.2. Integration Advantages

4.2.1. Organizational Integration

WAX has several advantages for the integration of organization members. Generally, WAXsmoothes process interfaces and can be better integrated within the organizational structure.The latter argument is best explained with the matrix in Table 4-1. We have to differentiatelegally and spatially separated persons and organizational units. Their degree of separation inthese two dimensions is different. Organization members that are spatially and legally fullyintegrated have the strongest link to the company. The advantage of WAX at this end of thespectrum is that persons which normally do not work with computers can be persuaded to useWAX. An example for such people is managers who use a workflow monitor and perhaps acoupled MIS (Management Information System).

Spatial Integration

Legal Integration Strong Weak

StrongManagement, inhouse workflowparticipants

Teleworkers, sales representa-tives, service personnel, sub-sidiaries

Weak

Freelancers, subcontractors Customers, suppliers, partnercompanies, members of virtualorganizations [MeFa97]

Table 4-1: Degrees of organizational integration

For organizational members that legally belong to the organization, but are working spatiallyseparated, the advantage consists in the fact that those members can transparently participatein the workflow from every computer which has an internet connection and a WWW browser.They do not need a conventional front-end. This advantage manifests itself especially withvarying or mobile computers. Besides performing workflow actions, these people can alsoquery customer documents or product documentation. Managers that want to keep themselvesinformed even during a business trip can use a WWW workflow monitor and intervene incritical processes.

Freelancers and subcontractors can be spatially close, but are legally bound more weakly thanthe last user group. For these people and for the group of spatially and legally weakly linkedworkflow participants, the WWW front-end creates the possibility to use the internet interac-tively with a high range1 and to bind them more tightly to the company than would be possibleby conventional means. Especially the often neglected interfaces at both ends of the workflow,

1 A typology of interorganizational internet uses can be found in [Kurb96].

i.e. to customers and suppliers, can be paid more attention to. Both groups can avoid a pro-prietary WMS installation. If other companies with which they cooperate also use a web-basedfront-end, they can integrate these companies as well. Furthermore, WAX supports the "totalcustomer care" thinking. A customer has the possibility to choose among different degrees ofinteraction with the company (see [Kurb96]):

q Passive. Customers can:

♦ Search for products and solutions for a special problem in online catalogs.

♦ Query the state of workflows that they triggered in the company or that concern them.

♦ Examine the result of a workflow.

q Active. Customers can:

♦ Ask for information material. Telephone and e-mail directories enable them to find themost appropriate contact person.

♦ Place an inquiry.

♦ Place an order.

♦ Express criticism in general.

♦ Make a complaint for a product or process.

All discussed interactions have in common that the customer is bound more tightly to thecompany. The easy and fast way for the customer to contact the company and to trigger work-flows gives him the impression of influencing the company and that he has a certain controland knows what is happening.

4.2.2. Informational Integration

4.2.2.1. User Interface

Due to the increasing variety of different hardware and software within a company, the num-ber of different user interfaces grew over the past years. This results in many problems forprofessional systems with high requirements (see Table 4-2).

An intranet solution in general and hence also for DMS/WMS remedies these problems: Ahomogeneous interface with a common "look+feel" for all platforms and application systems.The user friendliness and high acceptance of hypermedia techniques is widely acknowledged.They provide an "... elegant possibility how to wrap complex technology..." [Wagn96]. In-stead of confronting the user with cryptic abbreviations, the system offers information andfunctions "in plain language". Graphical elements, powerful navigation and query tools fa-cilitate the search for the desired information. While with other systems programming a user-friendly interface requires enormous efforts on the side of the software engineer, this is carriedout very easily and fast with hypermedia techniques. Additionally, the possibility is givenwithin a company to position the functional elements for all application systems at the sameplace and to provide them with the same looks. Another advantage is that informational andfunctional elements can be combined according to the situation. Thus, each user may config-ure his preferred interface and set electronic bookmarks for heavily-accessed information.

4.2.2.2. Information Repositories and Application Systems

The WMS as the backbone of the IS is additionally embedded in an environment which sup-ports a company’s activities that are not assigned to business processes, e.g. non-cooperativeor one-time processes. The integration of WAX into the intranet frame (or vice-versa) allowsfor connections to any possible information source without changing the application system,i.e. the browser (see Figure 4-1). The long and costly search for information can thus beshortened.

Besides documents being managed by the DMS (or a form management system – "FORMS"),figure 4-1 also contains documents that are linked from other sources. This can be realized byhyperlinks that are included in the workflow folder. From each application system that pro-vides a WWW front-end, results of an activity (a document or structured data) can be put intothe workflow folder. This way, process-specific information is integrated with all other com-pany data. This embedding can contribute to avoiding isolated views on single business proc-

Requirement Problem Effect Cost factors

Graphical user interface Different development en-vironments

Different user interfaces,multiple training, multiplemaintenance

Personnel costs

Additive run-time compo-nents of the presentationsystems

Heavy storage usage, highsystem load

Hardware costs, person-nel costs due to waittimes

Provision of comprehen-sive information

Missing links betweensystems

Handling effort, efficiencyloss, unsufficient informa-tion

Personnel costs, costs dueto quality loss

System access Different log-on proce-dures

Multiple input of loginname and password

Personnel costs due toefficiency loss

Access control to data andfunctions

Multiple authorizationsystems

Multiple authorizationdata

Registration and admini-stration effort

Process-oriented work-flow

Procedural breaks at sys-tem boundaries

Training expense, effi-ciency loss, quality loss

Personnel costs, costs dueto quality loss

Table 4-2: Cost factors of heterogenous user interfaces (acc. to [Sale97])

INTRANETINTRANET

WMS Engine

DMS FORMS

To do!

Workflow folder:

WMSWMSCAD WORD

EPC

INTERNETINTERNET

WMS Engine

DMS FORMS

WMSWMS

EPC

OnlineDatabase

HTML

Figure 4-1: Embedding of the WMS within the intra-/internet frames

esses and to preventing processes from being "cut out of the company’s body" [Mert96a], andthe loss of workflow-comprehensive contexts. The possibility to manage information fromexternal application systems as hyperlinks solves the problem that every system has to be in-tegrated into the WMS. The lean information coupling is less expensive than the functionalintegration and mostly sufficient.

The integration does not stop at the company’s fire wall: External information sources, likeonline databases, can be managed as links directly in the WMS as well and can be assigned toprocesses. Furthermore, application systems or information offerings from customers or sup-pliers, e.g. electronic product catalogs, can be integrated into the WWW front-end in order toextend the process chain into both directions.

4.3. Cost Advantages

All the advantages mentioned above are directly reflected in cost advantages. In general,economies in personnel costs and resources can be realized by use of WAX. These are:

q lower costs due to platform independence (hardware, operating system)

q little costs for WWW browsers, no more front-end licence fees

q lower installation and maintenance costs for WMS clients due to the use of standard soft-ware

q lower costs due to fewer system failures

q cuts in costs that occur at the process interfaces, i.e. to customers, suppliers, service em-ployees, etc.: communication costs, costs due to media breaks (e.g. multiple data input)

q homogeneous user interface: no more costs that emerge from heterogeneous interfaces (seeTable 4-2)

q no/less training costs

q lower personnel costs due to higher efficiency of the workflow processing (e.g. lowersearch times)

5. WAX Functionality

We use the WfMC reference model (see Figure 2-1) to illustrate the WMS architecture. Itserves to structure the functions of WAX. These are:

q A function for the DMS that provides dynamically generated HTML pages to searchdocuments, to show folder structures, and to download and upload documents. The systemBSCW of the Gesellschaft für Mathematik und Datenverarbeitung (GMD) basically repre-sents such a tool [Busb96].

q A function to model workflows. It is used in the definition phase of a workflow as well asto configure a single business case. Particularly, organizational members use it to restruc-ture a workflow model on the fly.

q A function to show the to-do lists of internal or external workflow participants. Addition-ally, it should be able to trigger application systems from within the to-do mask.

q A function to launch applications which have also a web front-end and to transfer data anddocuments which have been generated or edited.

q A function to monitor active workflows and to illustrate measures of finished workflows.Information like the current state of a workflow, the expected cycle time, and the structureof the activity network is included here as well.

Each of the suggested functions has been implemented prototypically, based on theDMS/WMS BusinessFlow 3.3 which is distributed by COI GmbH [COI96]. We added anHTTP server to the basic architecture that is tightly coupled with the DMS/WMS functions.The primary function works like this: Each URL request to the server is transformed into amethod call of the basic system and HTML code - sometimes enriched with Java applets - isreturned. Therefore, the major part of the original client functionality of BusinessFlow can bemapped by a WWW browser, e.g. the Netscape Navigator. Each WMS user receives a startURL leading him to the login page. According to his permissions, e.g. the right to changeworkflow models, specific functionalities are offered.

5.1. Scenarios

To demonstrate the WAX functions in a more concrete way we apply them to two real-worldscenarios. The first scenario refers to the inquiry/offer process for special bearings of INAWälzlager Schaeffler KG in Herzogenaurach, the second one to the administrative process forthe disposal of special waste in Bavaria.

5.1.1. Inquiry/Offer Process

INA produces roller bearings, motor elements, and linear-guidance systems for car manufac-turers and the machine tool industry. Standardized catalog bearings as well as customer-specific bearings are produced. The set up of an offer is organized in the process phases de-picted in Table 5-1.

Table 5-1: Workflow phases of the inquiry/offer process at INA

The inquiry/offer process is a long-term process that passes through several hierarchy levels ofINA. It consists of well and poorly structured process parts. This spread is challenging for aWMS designer. The involved employees are mostly high-qualified specialists with a long-term experience. The fluctuation rate of the staff is low. The high specialization results in astrongly functional orientation and a ramified organizational structure. The process costs foraccomplishing an offer are about 4,000 DM. According to habits in the machine tool industry,these costs are not billed. The process is tactically important because special bearings oftenbecome catalog bearings and special solutions that are generated within the process are usedas weapons against competitors. The process supports innovations and the developmentslaunched by the customer ensure INA to stay close to market needs. Even though the catalogbusiness has a higher revenue, the special bearings are of importance because a lot of custom-

Phase Description Subsequent PhaseA Register Inquiry BB Processing by application engineers CC Inquiry evaluation DD Decision E or FE Start offer process GF Reject inquiry Process TerminationG Product design HH Make-or-buy decision and calculation II Accomplish offer JJ Send offer Process Termination

ers want to get all bearings they need from a single source of supply. The complexity of theprocess can simply be shown by some figures [KlWa96]: About 700 people and 300 organ-izational units can be involved in inquiry/offer processes. The elementary actions that have tobe done are over 100. The cycle time is 55 days on average whereas one business case cancontain up to several hundred documents. 2,000 inquiries have to be processed per year.

5.1.2. Disposal Record Process

The disposal record process is an interorganizational business process which has to be exe-cuted by a producer of special waste, a disposal company, and the responsible approvalauthorities prior to the disposal itself. The central document of the process is the disposal rec-ord which is composed of the four parts: producer’s declaration (PD), waste analysis (WA),declaration of acceptance (DA), and authorities’ approval (AA). In simplified terms, the proc-ess can be described like this: First, a waste producer fills out the PD where he notes type,amount, and source of the waste. Then the disposal record is sent to a disposal company, thatsometimes analyzes the waste and imposes restrictions on the producer in terms of packingand delivery, filled into the disposal record. At the end, the disposal record is checked by theauthorities responsible for the approval of the disposal of special waste. In Bavaria, this is theLandesamt für Umweltschutz (LfU). Finally, the record is approved or rejected. Then the LfUsends back a copy to the waste producer and the disposal company. The entire workflow isstructured very well and consists of 30 mainly sequentially processed activities. Special casesare quite rare. In total, about 20 employees take part in the process.

The particular challenges of this application scenario are at first the high data volume: Dis-posal records are valid for five years. The LfU approved about 40,000 cases in the last sixyears. The document handling cannot be done efficiently without information technology, theformer cycle times up to several months have not been acceptable. The effect is that wasteproducers frequently call the disposal company to get information on the state of the disposalrecord. A solution here would be a monitoring component available to all waste producers.The internet seems to be promising according to its proliferation.

5.2. Modeling and Planning

Most WMS projects start with the modeling of the considered business processes (processdefinition phase). Using HTML, Java, and the HTTP server, we set up a graphical browserfront-end for workflow modeling. A changed model can be sent back to the HTTP serverwhich transforms it to the internal workflow representation of FLEXWARE (see section5.2.2.). This function appears to be superficial since in the conventional workflow approach afrequent modeling executed by many persons does not happen. In such a case, the alreadyavailable modeling tool (called VisualFloware in BusinessFlow) would be sufficient. How-ever, a WWW front-end in our case has two decisive advantages:

Firstly, the front-end enables the distributed modeling via internet and intranet of a company.Secondly, the approach of case-oriented workflow configuration is supported (see also section5.2.2.) [WaWe97]. Both are explained in the following part of the paper.

5.2.1. Distributed Modeling

Usually many "knowledge workers" that work in spatial and temporal separation participate incomplex workflows. They, as well as external consultants, must have the possibility to modeltheir workflows. It is desirable to provide them with full-time access to the models in order tolet them execute their modeling tasks at each point of time and at alternative locations. At the

University of Saarland the groupware system ContAct has been developed [HaGS96]. It offersmechanisms for distributed modeling. For this, the WWW represents an ideal platform.

Figure 5-1 shows the web-based modeling tool each modeler receives from the HTTP serverafter logging in. The modeler chooses one workflow model out of a list of available modelswhich is then locked in order to preserve consistency. The representation of the workflowmodel is an activity network with vertices (the activities) and edges (the control flow). Eachactivity has a name, roles, planned cycle times, and execution times as well as an activity costrate assigned to it.

After editing the network it can be saved and the lock on the model is released again. A time-out mechanism avoids the model to be locked for all times in case of the modeler forgetting tolog out.

Remote administration by the workflow system provider

In analogy to remote diagnosis of computer systems [Mert95], it is possible to provide a front-end for consulting companies or the workflow system provider to administer the WMS re-motely. This refers to the user management as well as to maintaining the system with e.g.patches.

5.2.2. Case-oriented Workflow Configuration

For complex workflow-enabled business processes like the inquiry/offer process the authorsintroduce a new approach that substitutes the conventional workflow phase model that strictlydistinguishes build time and run time of workflows [MoRW96]. Complex, partly-structured

Figure 5-1: Java Modeling Tool

workflows can barely be mapped to a few basic workflow models. It is unrealistic to supply acomplete workflow model for each special case. Firstly, not every exception can be modeled apriori, secondly, a huge number of variants would result. The alternative is to modularize theworkflow models in single building blocks:

The workflow planner configures subworkflows (workflow phases), activities, and elementaryactions according to the requirements of each concrete business case that has to be processedby the workflow system (see Figure 5-2).

To facilitate the workflow planner’s tasks, he can use a CBR system to find historical work-flows that are similar to the current workflow he has to plan and use them as a template[WaWe97]. If necessary, he can change the old model using a library of building blocks tosubstitute parts of the model or restructure it completely (see Figure 5-2). If the customer isoffered the option to trigger a workflow in a company, a pre-configuration can be automati-cally executed according to the customer’s input. A particular workflow planner or the em-ployee who has to perform the first workflow activity can reconfigure this model and refine it.Figure 5-3 shows an HTML form that an INA customer can use to launch an inquiry/offerprocess. For complex engineering problems he probably is not able to do this. In this case, theresponsible field engineer is provided an extended entry form. Similarly, a pre-configurationof the workflow takes place. Figure 5-4 shows the configuration mask where specific sub-workflow designs can be assigned to the workflow phases.

KonventionellesWorkflow-Management

ConventionalWorkflow Management

Fallorientierte Workflow-Konfiguration

Case-oriented Workflow Configuration

Workflow Type Model(Process Type)

Workflow Instances(Concrete

Business Cases)

HistoricalWorkflow Cases

Workflow Building Blocks

Workflow Instances(Concrete

Business Cases)

Figure 5-2: Principle of the case-oriented workflow configuration

Figure 5-3: WAX function to launch the INA workflow

Figure 5-4: WAX function to configure a workflow

In addition, in the case of exceptions the workflow participants are able to change the work-flow on the fly. Thus, one major drawback of WMS, the missing flexibility [Schw96], is re-moved and the basis of a self-organized workflow execution is given [Hack86]. An especiallydesigned workflow engine (FLEXWARE) controls these flexible workflows. To support thisapproach, a hypermedia-based front-end seems to be adequate to provide an intuitive user in-terface for workflow planner and workflow participant. Figure 5-5 shows the Java-basedworkflow editor, already known from section 5.2.1.

5.3. Launching Workflows

It is possible to integrate customers in all business processes that require just a minimum ofinteraction with the customer, e.g. all processes that refer to standard items. The IS then servesas "prolongation" of your own systems to your customer [Mieb95, p. 4]. Mass processesshould be handled without media clashes (see Table 4-1). Offers, e.g., should be transferreddirectly to the WMS and input data not be typed in a second time [Flor95, p. 177]. Kremer re-ports such an example at the Gothaer Credit Versicherung AG in Köln [Krem96]: Customerscan enter insurance applications into the intranet using a WWW browser. The major share ofall applications is processed automatically, special cases are passed to an employee's elec-tronic desktop.

Figure 5-6 shows an entry form for disposal records in a Netscape browser. When the wasteproducer has completed the form it is sent to the disposal company where a workflow is trig-

Figure 5-5: Workflow editor

gered. A large variety of aids like hyperlinks to decrees in this area facilitates the accom-plishment of this task.

5.4. Interoperable WMS

5.4.1. Mail Communications Server – WORKONNECTOR

To support the interoperability of WMS a mail communications server, the WORKONNEC-TOR, based on internet e-mail has been implemented [WeFa96]. This server enables a quickand flexible coupling of WMS based on the MIME standards.

The communication procedure of two WMS is shown in Figure 5-7. Each WMS is linked to aWORKONNECTOR server. To start a workflow in company B the workflow server of com-pany A calls a certain server function supplemented with a bunch of parameters. TheWORKONNECTOR then composes an e-mail in a standardized format and sends it to com-pany B that represents a completely distinct organization. Only the name of the workflow tobe called and the e-mail address of the WORKONNECTOR in company B must be known.Together with the function call documents or parts of it can be transferred. The fields of anentry form, graphics, or other documents are transferred using MIME encoding. The WORK-ONNECTOR of company B receives and analyzes the mail and triggers the WMS. When alltasks in B are executed the workflow server returns the results to the calling workflow of A.

Figure 5-6: Entry form for a disposal record

The described mechanism treats the cooperating workflows as black boxes. For the disposalrecord scenario, this means that e.g. the subworkflows of the waste producer, the disposalcompany, and the approval authorities are implemented in separate WMS. Only the linkingpoints with expected and sent documents are made public. An address book and special mailactivities in each company guarantee an error-free routing. In case of exceptions three proce-dures are suggested: With FLEXWARE it is possible to restructure an activity network if nec-cessary. If company B misses information from company A, it can be requested ad hoc via e-mail including all workflow information (as a hyperlink to WAX, e.g.). If "hard" exceptionsoccur, workflows can be canceled.

The WORKONNECTOR has been embedded in WAX’s overall functionality. Figure 5-8shows this interface for the disposal record process: The user chooses the desired workflow,and then selects the documents of the workflow folder to be sent. In this case, the PD, theWA, and the DA are transferred to the authorities for approval; the addressee is implicitlygiven by the type of process. The workflow then waits for the LfU’s answer and automaticallyroutes the incoming AA to the folder.

:RUNIORZ6HUYHU

$

6HUYHU�&DOO

3URFHVV�5HVXOWV

:25.21�

1(&725

$

:25.21�

1(&725

%

:RUNIORZ6HUYHU

%

5HWXUQ�5HVXOWV

6WDUW�1HZ�3URFHVV

1HW1HW

Figure 5-7: Communication between WMS on the basis of internet mails

Figure 5-8: Sending a workflow via the WORKONNECTOR

5.4.2. "Self-navigating" workflows

Riempp et al. suggest "messageobjects" (MOs) to handle work-flows [RiNa96]. These objectsrepresent the complete workflow:documents, the history of theworkflow, the planned workflowroute, and the current state. MOsare sent from one system to theother.

Extending this notion, one couldthink of a "trunk" system that sim-ply has the task to interpret themessage object information andpresent it to the user for displayingand editing. Internet and intranetare able to provide such a func-tion. The leanest version of thiskind of workflow consists of anHTML form which is the centralworkflow document as well as ad-ditional data for the workflow ad-ministration and Java applets, e.g.to show the workflow history or to

change workflow plans (see Figure 5-9). These data and applets could be integrated as hyper-links to the distributed, physical locations of documents and applications. The next step wouldbe to replace the HTML form by a folder that contains all documents with their type informa-tion in order to be able to launch the related application in the web browser. Since hardwareand software transparency is given, a workflow can leave the enterprise borders without anytechnical obstacles. Eder and Groiss implemented a simple system that works like this[EdGr96]. However, it has to be taken into account that such a scenario is not feasible withoutthe cooperating companies having fixed some sort of interchange agreement. As the memberof the Board of Directors of SAP, Zencke, puts it [Zenc97]: "Java applets freely floatingaround somewhere are unthinkable."

5.5. Monitoring

If a customer wants to know the current state of an inquiry that he has started earlier, he mightcall his sales representative. Alternatively, he can use his WWW browser to query specific in-formation about his case, e.g. the estimated time until he gets the offer. It is also conceivableto give a restricted insight into the activity network in order to decide if it is still possible tochange the specification of his inquiry.

Based on the modeling tool (see section 5.2.) we implemented a graphical workflow monitorthat provides this kind of information. In addition, the monitoring subsystem calculates meas-ures like average or maximal cycle times for activities and processes or their costs. The dis-played information is always user-specific since a customer should not be able to view a com-pany’s internal accounting data.

To do!

Workflow folder:

Appli-cations:

To do!

Workflow folder:

Appli-cations:

To do!

Workflow folder:

Appli-cations:

Documents

Workflow Data

WorkflowApplets

/LQNV�WR�

Documents

Workflow Data

WorkflowApplets

/LQNV�WR�

Documents

Workflow Data

WorkflowApplets

/LQNV�WR�

Figure 5-9: Message objects between WWW browsers

One view e.g. is a management report in the sense of an MIS tool (see Figure 5-10): A man-ager can view the most important workflow data at one sight: active and finished processesand their measures, an e-mail interface, and his own to-do list (e.g. signatures that have to bedone or forms containing decisions). Another view is the customer view (see Figure 5-11):The customer receives all workflows in a WWW browser and keeps himself informed aboutthe expected remaining cycle time. This is important for instance in the disposal record sce-nario: The high rate of telephone calls to the disposal company can be shifted to internetservices.

5.6. To-do lists

The usage of the internet makes it possible to integrate the field service, teleworkers, and sub-sidiaries into workflows. Nowadays, field-service employees already use laptops to generateindividual offers directly at the customer’s location. The employee connects e.g. in the eveningwith the WMS in the headquarters and triggers all workflows "that he has collected during hisday tour". Vice versa, he receives his to-do lists if e.g. some additional data from the customerare needed. Figure 5-12 shows a to-do list of an INA employee who is dealing with in-quiry/offer workflows. For teleworkers the web connectivity allows more flexible workingforms and times.

Figure 5-10: Workflow monitor for a manager (INA scenario)

Figure 5-11: Workflow monitor for a customer (waste disposal scenario)

Figure 5-12: To-do lists

In virtual enterprises (VE) [MeFa97] the companies that are cooperating can coordinate theiractivities in distributed worklists [WeFa96].

The to-do lists generated in different WMS can be integrated into one user interface, i. e. anemployee receives hyperlinks to the to-do lists of each WMS and can execute activities oneach system.

According to the workflow meta model in section 5.2.2., elementary actions that are per-formed by a single user are not modeled as self-sufficient activities which are part of a controlflow, but are summarized in one activity. As an aid and for documentation purposes, the em-ployee is provided with a checklist that shows all actions, gives additional hints, and has spacefor annotations. Figure 5-13 shows such a checklist for the activity "Register Inquiry" - per-formed by field-service personnel.

Figure 5-13: Checklist

5.7. Document Management

The front-end functions for the DMS appear in the to-do lists of the users by offering a hyper-link to a workflow folder which contains displayable documents. If needed, it is possible tonavigate through folders and subfolders (see Figure 5-12). WAX has also a full front-end toDOSSIER, the DMS of BusinessFlow: Documents can be retrieved by their attributes, edited,and added. Figure 5-14 shows the result of a document search.

All documents are stored in one workflow folder together with the workflow and subwork-flow description files and the checklists (see Table 5-2). Therefore, besides the technicaldocuments which represent the actual workflow object all meta information about a businesscase itself is available in the workflow folder. A top-level workflow report provides a sum-mary about the most important workflow data.

5.8. Application Systems

WAX allows for the gradual integration of application systems: from fully-integrated systemslike TADDY that was implemented in BusinessFlow’s programming language OEL to appli-cation systems that are loosely coupled by a "link" mechanism over which data are transferred(see Figure 5-15).

The INA application systems KODAS or MEDIAS also possess WWW front-ends. KODASis a system with which certain informational objects, "items" in "INA slang", can be found byelaborated search mechanisms. "Items" are e.g. construction parts, norm drawings, or CADform parts. MEDIAS is an electronic product catalog for INA’s linear-guidance systems im-plemented on the basis of MS Access. Besides drawings and descriptions of catalog parts,technical calculations can be performed as well. Both application systems have been inte-

Figure 5-14: Result of a document investigation

grated into the WAX interface and can be executed during the offer processing, e.g. whenlooking for repeat parts (see Figure 5-16). Once the desired information is found, it can be in-serted into the workflow folder as a hyperlink. By this, a lean integration of application sys-tems is accomplished very easily. KODAS and MEDIAS information (structured data or en-capsulated documents) are not really imported by the BusinessFlow DMS. It is just a link thatis stored as an ASCII document in the workflow folder.

In contrast, TADDY is a system that ishighly integrated into BusinessFlow.It provides solutions for specific areasof application that the constructor can"browse" as a hierarchical system.Figure 5-17 shows the TADDYWWW front-end. Search criteria, e.g.the customer’s name or an applicationfield (as a number code), have to beentered into the form. The result isone or more TADDY folders that canbe navigated by the user.

Between these two extremes, applica-tion systems are located that provide adata interface like DDE, ODBC, AS-CII files, or EDI, or that have a"functional" interface like Java. In thecase of a data interface, the WWW

Folder Level 1 Folder Level 2

Workflow Report

Workflow PlansInquiry, Type: Change of Quantity, Version 0

Inquiry, Type: Change of Quantity, Version 1

Inquiry, Type: Change of Quantity, Version 2

Subworkflow PlansRegister Inquiry, Version 0

Register Inquiry, Version 1

Register Inquiry, Version 2

Register Inquiry, Version 3

Evaluate Inquiry, Version 0

Evaluate Inquiry, Version 1

Evaluate Inquiry, Version 2

ChecklistsChecklist # 2759: "Create Requirement Specs"

Checklist # 3993: "Legal Contract Check"

Technical DocumentsINA Data Sheet

Calculation Form

Field-Service Report

Offer/Supply Design

Table 5-2: Contents of a workflow folder

high

low

q TADDY

q KODAS

q MEDIAS

q Java applications

q MS Word etc.

q Host applications

Deg

ree

of in

tegr

atio

n

Figure 5-15: Degrees of integration of application

systems

server acts as a mediator between the user and the application in that it re-implements part ofthe functionality and maps the user interaction to certain calls of the data interface. Figure5-18 shows the example of a search in a database containing descriptions and key codes forspecial waste types.

An example for the functional integration by Java is the workflow modeling tool known fromsection 5.2. It was re-implemented as a stand-alone application after BusinessFlow’s own tool.It receives workflow data (graphical data, roles, plan times, and costs) from the server andthen is just in charge of handling the user interaction. After the user having modeled the work-flow the data are sent back to the server which writes them to the database.

6. State and Future Work

In our project, the WWW technologies turned out to be useful within two contexts: In the in-ternet, it provides a powerful mechanism to let people outside the organization participate inthe workflows: modeling, performing workflow actions, monitoring, and maintenance can beexecuted by them. Furthermore, workflows can cross company boundaries.

The WWW technologies meet many requirements in this area: easy handling, worldwide-available infrastructure, and integration. It should be kept in mind, though, that a lot of workremains to be done. The internet doesn’t guarantee a minimal bandwith, nor does it offer any

Figure 5-16: Integration of the MEDIAS application

standardized encryption methods, identification mechanisms, or acknowledgments, like e.g.X.400 protocols include.

In the intranet, particularly the advantages mentioned in chapter 4 count: user friendliness, astandardized user interface, the integration of application systems, and the flexibility to createintelligent user interfaces.

One of the weaknesses of the chosen WAX architecture for BusinessFlow is that the user in-terface and its logic that the system provides in its kernel have to be programmed anew. Thisconcerns e.g. the basic DMS functionality, like document search. It is desirable at this point tohave an HTML kernel for the system (see introduction of chapter 5), that takes care of theHTML processing.

The described process monitor could be enhanced by knowledge-based components, e.g.methods of data mining in order to find weaknesses of the workflows on the basis of a meas-ure system.

Furthermore, the WMS will be extended to a comprehensive Organizational Memory Infor-mation System (see [Warg96]). In this context, WAX has two main advantages: On the onehand to have a possibility to present data contextually and user-friendly, and on the other handto be able to "leanly" integrate knowledge sources into the operative system. This facilitatesthe bidirectional knowledge transfer (usage of knowledge that is "produced" during workflowexecution and knowledge updating or extension).

Figure 5-17: TADDY search mask

5HIHUHQFHV

[Busb96] Busbach, U.: BSCW: Eine Applikation zur organisationsübergreifendenKooperationsunterstützung auf der Basis des World-Wide Web. In Uellner, S.(ed.): Proceedings of the GI workshop "CSCW in großen Unternehmen".Telekom, Darmstadt 1996, pp. 54-63.

[COI96] COI Consulting für Office und Information Management GmbH (ed.): UserManual BusinessFlow 3.3. Herzogenaurach 1996.

[DLB+96] Deiters, W.; Lindert, F.; Böhm, M.; Friedrich, M.; Schulze, W.: WorkflowManagement as Teleservice. In Computer Networks and ISDN Systems 28(1996) 4, pp. 1961-1969.

[EdGr96] Eder, J.; Groiss, H.: Workflow-Systeme im WWW. In ADV Arbeitsgemein-schaft für Datenverarbeitung (ed.): Proceedings of the ADV Congress. Wien1996.

[ErSc93] Erdl, G.; Schönecker, H.: Vorgangssteuerungssysteme im Überblick. In OfficeManagement 41 (1993) 3, pp. 14-21.

Figure 5-18: WWW interface of a database

[Flan96] Flanagan, D.: Java in a Nutshell. Sebastopol, CA, 1996.

[Flor95] Flory, M.: Computergestützter Vertrieb von Investitionsgütern. Wiesbaden1995.

[Hack86] Hackman, J.R.: The psychology of self-management in organizations. In Pal-lak, M.S.; Pasloff, R. (ed.): Psychology and work. American PsychologicalAssociation. Washington 1986, pp. 85-136.

[HaGS96] Hagemeyer, J.; Galler, J.; Scheer, A.-W.: Koordination verteilter Workflow-modelierung mit ContAct. In Becker, J.; Rosemann, M. (ed.): Workflowman-agement - State-of-the-Art aus Sicht von Theorie und Praxis. Proceedings ofthe GI workshop. Münster 1996, pp. 20-25.

[KlWa96] Klemann, A.; Wargitsch, C.: Workflowanalyse und Komplexitätsrechnungzum industriellen Geschäftsprozeß "Anfrage-/Angebotsabwicklung für Son-derlager der INA Wälzlager Schaeffler KG". Unpublished working paper ofthe COI GmbH. November 1996.

[Krem96] Kremer, H.-J.: Gothaer Credit: Mehr Nutzen als bunte Web-Seiten. In Com-puterwoche from 08/30/96, pp. 42-43.

[Kurb96] Kurbel, K.: Das Internet aus betriebswirtschaftlicher Sicht: Nutzen und zukün-ftige Erwartungen. In Proceedings of the 1st Internet Congress for the NewLänder. Frankfurt (Oder), December 3/4, 1996.

[Mert95] Mertens, P.: Integrierte Informationsverarbeitung 1 - Administrations- undDispositionssysteme in der Industrie. 10th edition. Wiesbaden 1995.

[Mert96a] Mertens, P.: Process focus considered harmful. In WIRTSCHAFTSINFOR-MATIK 38 (1996) 4, pp. 446-447.

[Mert96b] Mertens, P.: Beitrag eines Workflow-Management-Systems zur Integrationvon Daten- und Dokumentenverarbeitung am Beispiel der Anfrage-/Angebots-Abwicklung bei der INA Wälzlager Schaeffler AG. Manuscript of the talk onthe COI Roadshow, Nürnberg 06/11/96.

[MeFa97] Mertens, P.; Faisst, W.: Virtuelle Unternehmen, Einführung und Überblick. InHahn, D.; Taylor, B. (ed.): Strategische Unternehmensplanung - StrategischeUnternehmensführung. 7th edition. Heidelberg et al. 1997, in preparation.

[Mieb95] Miebach, J.T.: Nutzung von EDIFACT im steuerberatenden Berufsstand unterbesonderer Berücksichtigung der Buchungssatzgenerierung. Ph.D. dissertation,University of Erlangen-Nürnberg, Nürnberg 1995.

[MoRW96] Morschheuser, S.; Raufer, H.; Wargitsch, C.: Challenges and Solutions ofDocument and Workflow Management in a Manufacturing Enterprise: A CaseStudy. In Lynn, M.S. (ed.): Proceedings of the 29th Annual Hawaii Interna-

tional Conference on System Sciences, Vol. V. Los Alamitos 1996, pp. 4-13.

[Mumm96] Mummert + Partner Unternehmensberatung GmbH (ed.): Marktübersicht:Workflow-Management, Geschäftsprozeßanalyse, Ablaufmodellierung, Re-engineering. Frankfurt 1996.

[NN96] N.N.: Mehr Web-Pages für Intranets. In Computerzeitung 27 (1996) 51+52, p.21.

[NN97] N.N.: In Hülle und Fülle. In manager magazin 27 (1997) 3, pp. 146-150.

[Rech94] Rechlin, A.: Entwicklung einer State-of-the-Art-Datenbank für Dokumenten-und Workflow-Management-Systeme sowie deren Anwendungen. Master the-sis. University of Erlangen-Nürnberg, Nürnberg 1994.

[RiNa96] Riempp, G.; Nastansky, L.: Workflow Management zwischen verteiltenGroupware-basierten Büros (Wide Area OfficeFlow). In Uellner, S. (ed.). Pro-ceedings of the GI workshop "CSCW in großen Unternehmen". Telekom,Darmstadt 1996, pp. 193-207.

[Sale97] Saleck, T.: Die betriebswirtschaftlichen Chancen der Intranet-Architektur. Init management 4 (1996) 1, pp. 18-25.

[ScBö96] Schulze, W.; Böhm, M.: Klassifikation von Vorgangsverwaltungssystemen. InVossen, G.; Becker, J. (ed.): Geschäftsprozeßmodellierung und Workflow-Management. Bonn 1996, pp. 279-294.

[Schw96] Schwab, K.: Koordinationsmodelle und Softwarearchitekturen als Basis fürdie Auswahl und Spezialisierung von Workflow-Management-Systemen. InVossen, G.; Becker, J. (ed.): Geschäftsprozeßmodellierung und Workflow-Management. Bonn 1996, pp. 295-318.

[Vers95] Versteegen, G.: Den Tendenzen zum Wildwuchs entgegenwirken - WorkflowManagement Coalition ist um Standardisierung bemüht. In ComputerwocheExtra 3, 08/18/95, pp. 12-15.

[Vogl93] Vogler, P.: Konzeption und Realisierung eines Unterstützungssytems zur Vor-gangsabwicklung und Informationslogistik in verteilten Büroumgebungen.Ph.D. dissertation. University of Erlangen-Nürnberg, Nürnberg 1993.

[Wagn96] Wagner, S.: Prozesse übers Internet steuern. In Computerwoche 23 (1996) 38,Focus: SW Engineering: Vielfalt ist angesagt, 09/20/96.

[Warg96] Wargitsch, C.: Ein Organizational-Memory-basierter Ansatz für ein lernendesWorkflow-Management-System. Unpublished manuscript of the Departmentof Information Systems I of the University of Erlangen-Nürnberg, Nürnberg1996.

[WaWe97] Wargitsch, C.; Wewers, T.: FLEXWARE: Fallorientierte Konfiguration vonkomplexen Workflows. To appear in Proceedings of the workshop "Planningand Configuration" on the XPS ’97. Bad Honnef 1997.

[WeKr96] Weiß, D.; Krcmar, H.: Workflow-Management: Herkunft und Klassifikation.In WIRTSCHAFTSINFORMATIK 38 (1996) 5, pp. 503-513.

[WeFa96] Wewers, T.; Faisst, W.: Kooperierende Workflow-Management-Systeme fürVirtuelle Unternehmen. In Uellner, S. (ed.): Proceedings of the GI workshop"CSCW in großen Unternehmen". Telekom, Darmstadt 1996, pp. 167-177.

[Wewe96] Wewers, T.: Konzeption eines zwischenbetrieblichen Workflow-Management-Systems zur Unterstützung von Geschäftsprozessen bei der Sonderabfallent-sorgung. Working paper no. 4/96 of the Department of Information Systems Iof the University of Erlangen-Nürnberg, Nürnberg 1996.

[WfMC96a] Workflow Management Coalition (ed.): Terminology and Glossary. PaperWfMC-TC-1011, Version 2.0. Brüssel 1996.

[WfMC96b] Workflow Management Coalition (ed.): Interoperability – Internet e-mailMIME Binding. Paper WfMC-TC-1018, Version 1.0. Brüssel 1996.

[Yaki96] Yaki, A.: Germany - A high growth market, poised for major change. InDocument World 5/1996, pp. 14-16.

[Zenc97] Zencke, B.: Betriebswirtschaftliche Prozesse in vernetzten Unternehmen. In-vited talk at the 3rd International Conference "Wirtschaftsinformatik", Berlin27.02.97.