Fundamental Concepts for Workflow Automation in Practice - CiteSeerX

Fundamental Concepts for Workflow Automation in Practice Stef Joosten and Sjaak Brinkkemper Centre for Telematics and Information Technology, University of Twente, The Netherlands March 12, 1995

This paper is submitted to the ICIS ’95 conference, Amsterdam, December 1995.

Mailing Address Centre for Telematics and Information Technology, University of Twente, P.O. Box 217 7500 AE ENSCHEDE The Netherlands tel. +31 53 893436 fax. +31 53 339605 internet: [email protected]

Keywords workflow support systems, business process re-engineering, collaborative work systems, field study. ISRL categories: DD0402, HA12, AI0108. 1

Fundamental Concepts for Workflow Automation in Practice Abstract Workflow systems are catching on rapidly due to the success of many workflow-based innovations in practice. Streamlining or even redesigning workflows in the primary business is observed to be effective in organisations that have problems coordinating work. In order to learn how and why workflow management systems are built, twelve organisations that use workflow systems have been analysed. The observations done in this project have led to the definition of terms, a modelling technique and knowledge about the innovation process of implementing automated workflow. This paper is interesting for methodologists who want to learn how workflow analysis can be done, for managers who want to learn what workflow means in practice, and for researchers to learn which practical problems require research attention. Keywords: workflow support systems, business process re-engineering, collaborative work systems, field study. ISRL categories: DD0402, HA12, AI0108.

1

Introduction

In order to evaluate the practical significance of workflow, a project under the name of WA-12 was set up during the summer of 1993. Twelve organisations with actual workflow experience were found to cooperate in this empirical research project. The purpose of the research project was to learn about the way in which workflow projects differ from other projects and to learn from the analysis and design processes that are carried out during the innovation. The ultimate goal is to develop an empirical basis upon which a method for workflow analysis and design can be built. Workflow management deals with the coordination of productive work in a business process. The workflow paradigm is characterised by:

 a focus on the interaction between actors rather than the activities themselves;  a number of different people and organisational units being involved;  boundary spanning both within and outside the organisation;  integration of procedures and tools. Actors can be individuals, groups or machines, which explains why workflow research is a combination of computer science and business science. In the turbulent world of information systems technology, workflow is positioned as a new breakthrough in administrative organisations. Vendors advertise advantages such as increased processing flexibility, shorter processing times, improved customer service, improved resource management, etc. Literature study [13] has shown that a majority of publications originates from vendor organisations, resulting in a large supply of case studies and tool-oriented articles. As a consequence, it is not easy to find out what workflow means in practice.

1

2

Background

There are different types of research related to workflow systems: technical, conceptual, organisational and methodological. Technical research is focused on finding technical primitives to support workflows. An example is the TriGSflow system in which workflows are organised on the basis of active objects [14]. Client/server architectures are being studied in order to enable workflow servers at different locations to cooperate [22]. Business transactions appear to be more complicated than database transactions. Consequently, researchers are looking into new transaction models [3, 2, 6]. Conceptual research is conducted in order to describe workflows effectively and efficiently. The work of Winograd and Flores [23] about speech acts has started an important new development, leading to the Action Workflow Approach [18]. Other approaches are based on Petri-nets [11]. Many tools, however, use their own conceptual framework such as [16]. Research in organisational and business sciences is done to find ways in which workflow tools are best exploited. Business process reengineering is a well known development in this area [10, 4]. The analogy with logistics has been noticed and used as a starting point for innovation of work procedures [24, 9]. Methodological research is motivated by the belief that workflow management represents a new paradigm. This justifies the search for new methods [1, 7, 8]. Research about the use of workflow in practice is an apparent omission in this overview. Available case studies are often used to advocate a specific tool. Comparative case studies are rare. Yet, if a method for the design and implementation of workflow systems is to succeed, it must take into account what practitioners have learned the hard way. The WA-12 project is based on this observation. It was intended to describe the experience with workflow projects in order to learn methodological aspects that are important for workflow analysis and design.

3

Research Approach

A research project like WA-12, set out to generate a descriptive theory and to explain the concepts of workflow requires a qualitative research approach (e.g. grounded theory [17]). It must focus on the development of a context-based description of a phenomenon together with explanations. The causality based methods, using variance theory, are less suitable for this type of research [20]. Research questions of the WA-12 project have been refined by defining the following aspects of interest: terminology, modelling techniques, introduction of the workflow system and integration. In the selection of sites both differences and similarities were considered. The similarities should replicate the essence of the theory, being the actual use of techniques to analyse workflows. The differences were sought in the nature of workflows, the type of organisation and the way of supporting workflows. As a possible flaw in site selection, the orientation towards tools was identified. To prevent this from happening, suitable cases were sought with the help of system architects rather than tool vendors. The acquisition phase was supported by DCE Nederland B.V., an independent consulting organisation that specialises on workflow. The requirements for participation were

 demonstrable experience with workflow  open attitude towards researchers going through the organisation

2

numbers process consultancy

yes 12 5

no 26 10

no response 4 0

total 42 15

Table 1: Organisations approached for WA-12 These requirements exclude organisations that were still in the planning phase. Table 1 gives the numbers of organisations that were approached for participation in WA-12. The organisations in the category “process” are the actual workflow processes. Organisations in the category “consultancy” are companies that participated in pointing out the locations where workflow projects are executed. In this way we have often been in touch with the original designers of a workflow application. The process to be studied was identified during the acquisition phase in order to ensure a focus on the process rather than the tools. Data collection was based on a variety of research techniques: questionnaires, unstructured and semistructured interviews, observation and documentation study. The choice and the use of techniques was different for all cases to accommodate for the different situations encountered. Less interviews could be done in organisation that produced useful written information (e.g. design - or decision documents). Where documentation fell short, interviews were conducted to fill the gaps. It turned out that the differences were larger than anticipated, making the questionnaires almost useless. The use of different techniques at the same time is useful to generate theory, because it allows for verification of results [5]. Every contact with participating organisations has been coordinated with a contact-person, to ensure maximal cooperativeness in the organisation. Organisations were visited several times during the data collection phase. Each organisation has received an elaborate private report on its own situation. Furthermore, the final WA-12 report [12] has been presented to the participants in the form of a research monograph..

4

Research Results

The main results of this research project are in the comparisons of the twelve cases, to be preceded by short descriptions in the following table. The second column of this table contains three attributes of each process. Firstly, it contains Leifer’s classification [15] in stand-alone, centralised, distributed and decentralised systems. Secondly, Mintzberg’s typology [19] as simple structure, machine bureaucracy, professional bureaucracy, divisionalised form and adhocracy is given. Lastly, the main problem is given that lies at the root of the workflow innovation. 1.

2.

Supply and administration of car insurances at a bank. This project grew out of the need to maintain insurance folders electronically on a document imaging system. At the time of research, simple workflows are being supported. The system is living up to its expectations. Allocation and administration of domestic facilities in a large research laboratory of a major multinational concern. The workflow is about allocation of rooms, name shields, telephone and LAN connections, issuing of keys, etc. in an environment of dynamic research team formation, large numbers of people and projects and tight security measures. At the time of research, the system was operational for a year. The project is considered a success.

3

distributed system, machine bureaucracy, archiving problem

distributed system, machine bureaucracy, integration problem

3.

4.

5.

6.

7.

8.

9.

10.

11.

Selling and maintaining leasing arrangements at a leasing company. A remarkable feat of this project is that a large number of relatively small workflows has been (re-)designed for workflow, among which the design of a workflow itself. At the time of research, the system was about to be rolled out to the user organisation. Applications at an insurance company for the medical profession. The purpose of the project was to increase the product quality by decreasing throughput delays and enhancing customer service. This involved an imaging system in order to get the primary information stream on an electronic infrastructure. The project is considered successful, although it has more characteristics of imaging than workflow. The distinction between the two is not always made in practice. At the time of research, the system was operational for over a year. Filing financial reports of companies at a chamber of commerce. The project development went relatively smooth due to thorough preparation and early commitment of employees. The project was just operational when this research started. Mortgage administration in an investment company. This workflow involves all activities starting with a request for a mortgage down to the final wrapping up. The developed system was being implemented within the organisation at the time of research. Mortgage administration at an insurance company. This process was meant to solve problems with the inaccessibility of paper files, shortage of storage capacity and serious problems with the quality of work. In a highly ambitious project which took no longer than a year, a new technical infrastructure together with imaging and workflow functionality has been designed and introduced. Although the introduction was not completed at the time of research, it was clear already that the project goals were met. Granting of tenant subsidies at a governmental department. As an innovation, this project was successful. However, it turned out that it was more a document automation project than actual workflow. Nevertheless, some workflow aspects are visible in the project. Archiving of documents at a provincial government. The project was started because of archiving problems, and aimed at a large scale introduction of document imaging. A workflow in the primary process was selected as a pilot to demonstrate the workflow capabilities. The project has a troublesome history, mainly caused by a lack of commitment and continuity. Social insurances administration at an administrative service organisation. The project goals were to increase the efficiency in the process and to offer better service to customers. At the time of research, the project was in its introduction phase. The project ran into several delays due to the sheer size of the process. The project goals are still expected to be achieved. Provision of credit-worthiness information at a commercial credit insurance company. At the time of research, this project was in use for about half a year. It was intended to demonstrate the potention of workflow management to the organisation, and was successful in this respect.

4

distributed system, machine bureaucracy, problems with control

centralised system, professional bureaucracy, problems with throughput and archiving

distributed system, professional bureaucracy, archiving problem

distributed system, professional bureaucracy, archiving problem

distributed system, divisionalised form, problems with throughput and quality of data

centralised system, professional bureaucracy, problems with malfunctioning system

distributed system, machine bureaucracy, archiving problems

centralised system, machine bureaucracy, problems with client focus and quality of data

distributed system, professional bureaucracy, throughput problem

12.

Issuing of environmental licences and industrial waste dispensations in a provincial government. This organisation is often confronted with changes in procedures that are dictated by political developments. The project took excessively long, and clear cut project goals were never defined. Nevertheless, limited results were achieved.

centralised system, machine bureaucracy, archiving problem

The aspects of interest identified in the research approach are terminology, modelling techniques, introduction of the workflow system, integration and organisation. A selection of the results for each of these aspects is given. For a complete account we refer to [12]. In analysing documents and interview reports for the use of terms, we found a great deal of consensus about the nature of workflow. Although people in different groups in different organisations often use different words, the analysis did not uncover any conceptual disagreements about the nature of workflow. This analysis resulted in figure 1, which shows the conceptual framework of workflow management in the form of an ER-diagram. These concepts have been given mutually consistent definitions, leading to the subprocess of

object

element of

carries element of

event

process

performs

activity triggers

actor responsible

Figure 1: ER Model of Concepts definition of the concept of workflow: Definition 1 (workflow) A workflow is a system whose elements are activities, related to one another by a trigger relation and triggered by external events, which represents a business process starting with a commitment and ending with the termination of that commitment. Next to terminology, techniques and methods that are used in practice have been studied in order to find out what analysts do in order to chart the situation. Table 2 gives an overview of modelling techniques used in the different cases. In the absence of modelling techniques especially for workflow, most organisations used conventional tools and techniques, such as modelling of the process, the control flow, the dataflow, state transitions, etc. In order to compare the different modelling techniques, we have divided them in techniques for modelling data (e.g. entity-relationship modelling), process (e.g. dataflow, process hierarchy), control (e.g. flowchart, triggers, state transition) and organisation (e.g. organigram). Besides, the approach was classified as either informal, graphical or formal. Formal specification techniques were not found to be used. It came as a surprise that data modelling was hardly done. Almost all organisations made a control model of the workflow. In one organisation the analysis and design of workflows was function oriented. This was unexpected, because workflows consist of activities rather than functions. The orientation towards business functions can lead to partial analysis of the workflow to be considered In studying the introduction of workflow systems, observations were done about key numbers, project initiators, project goals and motivations. Table 3 shows, interestingly enough, that most workflow projects were initiated by management and relatively few by IT departments and even fewer by Administrative Organisation (AO) departments. Apparently, this is an innovation that is business driven rather than technologically pushed. In most cases a project organisation is used to carry out the intended innovation. 5

Case 1 2 3 4 5 6 7 8 9 10 11 12

Techniques used informal informal graphical graphical graphical graphical graphical graphical informal graphical graphical informal

data

process

p p

control p p p p p p p p

p p p

p p p

p p

p

organisation

p

Table 2: Modelling Techniques Used

Organisation 1 2 3 4 5 6 7 8 9 10 11 12

Management p p

Users

p p

p

p p p

p

p p

p

Initiated by IT-department

AO-department

p

p p

p

Table 3: Project Initiation A popular structure is to have a steering group and a project group headed by the project manager. We found that projects where external workflow expertise was involved were more successful than projects on a do-it-yourself basis. Integration is one of the technical aspects of workflow support that causes practical problems. Although workflow literature usually assumes the existence of an electronic infrastructure, we found that this is not always the case in practice. In all organisations, existing information systems (also called legacy systems) were integrated in the workflow system. This results frequently in the need to use data objects from one application inside another. DDE is a popular candidate to solve this problem. Interfacing between workflow support tools is entirely absent. Some technical interfacing aspects have been collected in table 4. Legacy applications can be triggered by events that occur in a workflow. Perceiving the existing systems as ‘vertical applications’ gives a separation of applications and workflow. Some organisations apply this perception in their development philosophy. Data is not exclusively accessible via a single application, but also with general tools. Routing decisions are mostly carried out in the workflow system and applications are triggered by passing the proper parameters. Interfacing a workflow tool to commercially available databases may or may not require developing the interface modules, depending on the interface functionality offered in the tools used. The current status of job should be stored in a database rather than a file system for reasons of security. The information 6

1 2 3 4 5 6 7 8 9 10 11 12

C/S p p p p p p p — p — p —

DBMS Informix Oracle Sybase PACE Informix Informix Oracle IMS DB2 Mainframe Mainframe Oracle

Network Token Ring Ethernet Token Ring Wang Token Ring Ethernet Ethernet Ether+T.R. Token Ring — Ethernet —

Operating system Dos/Win/Unix Dos/Win/Unix Dos/Win VS Dos/Win Dos/Win Dos/Win/Unix Dos/Unix OS/2 / Unix Unix Dos/Win Dos/Win

Workflow tool WFM (Digital) — Staffware (Staffware) — FloWare (Plexus) FloWare (Plexus) Event Manager (Unisys) — Work Management Builder (IBM) Staffware (Staffware) FileNet WorkFlo (Olivetti) —

Table 4: Technical Aspects of Integration needed to do the work may or may not be stored in a database system, usually depending on situational factors. Workflow definitions and operational workflow data are also stored in a database. The workflow support system covers the whole business process, as opposed to an existing application that supports a single activity or a number of activities. A majority of systems is linked to standard office tools, e.g. word processor, spreadsheet, e-mail or e-fax. Further, workflow systems are frequently used in combination with imaging tools. This combination is obvious, because work is much easier to schedule, monitor and distribute when the majority of documents resides in an electronic infrastructure. As long as most of the work is carried over on paper, much of the workflow has to be coordinated manually. The organisational typology of Mintzberg [19] forms the basis of the comparison of the organisations in WA-12 with respect to organisational applicability. This comparison draws from three sources: the coordination mechanisms distinguished by Mintzberg, the different types of information systems identified by Leifer [15] and the information collected about the WA-12 organisations. Leifer’s information technical approach aligns with the organisational approach of Mintzberg. Although the five organisational types as described by Mintzberg almost never occur in their pure form, they do provide a framework in which structural characteristics of (administrative) organisations can be compared. Both the organisational and the information technical approaches are complemented by the results of WA12. Most organisations are of the standardisation based type, which is in line with recent trends. Almost half the organisations were identified as a machine bureaucracy and the other half as a professional bureaucracy. The divisionalised form is identified at one organisation only. This is due to the fact that this type consists of a combination of the other two types and the fact that the categorisation is made on a process level. Eight out of the twelve organisations have a distributed system and the other four have a centralised system. These results do not contradict the theory of Mintzberg and Leifer. In this comparison we have paid attention to terminology, modelling techniques, introduction of the workflow system, integration and organisation. The following section contains a discussion at a more general level, in order to prepare conclusions that go beyond the scope of the twelve organisations.

5

Discussion

The discussion is presented in four parts. The first part gives general considerations about workflow management, based on the empirical results of WA-12 and literature. Technological aspects of workflow 7

systems, such as integration, are discussed in the second part. The third part deals with the role of workflow support systems in organisations. The fourth discussion is about project characteristics of workflow management innovations.

5.1

Theory

In section 2 we argued that there is a lack of methodological literature about workflow management and automation. Most of the practical publications about workflow management originate from suppliers, focusing on tools and case studies in support of those tools. Workflow is an emerging technology, likely to be presented as a panacea for all business problems. No specific workflow methods are known to analists facing the challenge to implement the “workflow promise”. Therefore, conventional modelling and even implementation techniques are widely used. These observations justify the conclusion that workflow support lacks a theoretical basis. This basis should make clear what workflow is, which techniques are to be used in which circumstances, how to describe a workflow formally, etc. A number of methods and techniques already exist to support workflow, such as the published technique of Action Workflow [18], or the proprietary technique of DCE [21]. In practice, methods and techniques are often chosen by convention or by the availability of CASE-tools. Consequently, the methods used do not always focus on the key issues in a workflow analysis, such as the triggering dynamics of the system. Furthermore, ill defined responsibilities appear to be an important source of problems in workflow projects. A theory of workflow support should therefore focus on triggering, activities and responsibility of actors. The concepts given in figure 1 must be incorporated in methods and techniques for the analysis and design of workflow support systems.

5.2

Technology

Due to the fact that a workflow system is a combination of centralised control and local interactive processing, it is ideally suited for a client/server architecture. This architecture allows for implementations ranging from conventional mainframe based situations through interconnected local area networks. Many organisations have the infrastructure already in place, which is frequently based on PC workstations with MS-DOS/MS-Windows. Few workflow tools support character terminals explicitly. Figure 2 gives the generic architecture of workflow support systems. This is essentially a client/server architecture. It is generic in the sense that each of the components can occur multiply in different guises. It is also generic with respect to the concrete machines on which the components are located. Any component can be mapped on any machine, which includes the possibility of combinations of components on one machine. Three different storage components are distinguished: a definition store, a transaction store and an observation store. The definition store contains the structure of workflows. The transaction store keeps track of all activities performed in a workflow-instance. The observation store contains information about workflows, which is used for workload balancing, productivity measurement, accounting, etc. There are three different types of active component in a workflow support system: interface processors, event managers and workflow managers. An interface processor links applications to the workflow system. It can be either custom or tailor-made. The event manager maintains a list of work to be done, guarding deadlines and work conditions and notifying other actors. A workflow manager coordinates within workflows, spawns and monitors other workflows, and communicates with other workflow managers when necessary. The clients occur in three different roles: workers, developers and managers. They are distinguished because they require different functionality from a workflow support system. In practice, combinations of these roles are not uncommon. 8

LEGEND client component active component

worker

developer

manager

storage component

Interface processor

event manager

workflow manager

definitions

transactions

observations

Figure 2: A Generic Architecture for a Workflow Support System In many situations, workflow support and document imaging are an obvious and successful combination. A mature electronic communication infrastructure within an organisation stores and transports most of the information objects used in a business process. This includes documents, files and archives, which makes the role of imaging technology an obvious one. A document imaging system is often an essential part of the infrastructure in which a workflow system is operational. In the absence of specific workflow standards, integration problems of different kinds (e.g. e-mail, API’s, GUI’s, etc.) must be anticipated in a workflow project. DDE was seen in many of the WA-12 organisations. Although most vendors claim their tools will integrate with almost anything, current workflow tools are all mutually incompatible. The following questions with respect to integration are found to be relevant for workflow projects:

 Which activities in the workflow are supported by which existing applications?  Which integration options exist for each of the mentioned applications?  Which integration options are desired (data sharing, communication, user interface)  What effort is needed for each of the defined integration options?  Which alternatives are possible (rewriting an application, applying standard software)  Which trends in integration can be anticipated? It is important that these integration issues are made explicit in the analysis phase, in order to avoid unexpected problems in the implementation phase. A design method for workflow systems should take this into account. In the WA-12 cases, the observed operating systems, database management systems and networking technology all follow accepted industry standards. Integration problems on that level are likely to be small or absent.

5.3

Organisation

Manufacturing processes and administrative processes differ on a number of structural characteristics. This has consequences for the way in which principles from one field can be applied in the other. In 9

manufacturing processes, the distinction between the production process and the information system to control and coordinate this process is clear. In administrative organisations, this distinction is often hard to make, because both systems process information. Workflow management can be used to separate the control and coordination mechanisms from the primary process. This yields insight in the (primary) process, helping to realise the promised advantages of flexibility and integration. None of the 12 processes in WA-12 has been modelled in a logistic manner. This is due to the fact that the situation before workflow automation was not quantified. The introduction of a workflow system will have a lasting effect on future innovations, because workflow support yields the quantitative information to assess future innovations in detail. With respect to the workflow projects and the way in which they are managed, we have first and foremost observed that project goals have largely been met, In spite of problems and inadequacies during those projects. Projects run in a strict project organisation achieve ambitious goals in a reasonable time. The projects in WA-12 seem to suggest that separate steering and project groups, a strong project manager from within the organisation, sufficient commitment and an external systems integrator are components of a successful workflow project. The fact that workflow management is relatively new, that it is meant to support primary processes and that it involves the coordination of work imply that workflow projects have a relatively high project risk. In WA-12, the following generic project risks were encountered: commitment, user acceptance, technical integration, project organisation. Apart from integration, technical project risks are relatively unimportant as opposed to organisational project risks. The need for better, structured modelling techniques follows from two arguments. Analysts claim that they do not know how to analyse a business process in order to support workflow management. Also, they frequently choose conventional analysis techniques rather than specific workflow analysis and design techniques. Many designers tend to use free diagrams, justified by the desire not to be restricted by technique rules. However, the quality of the analysis often suffers from this. Implementing a workflow support system is said to require business process redesign [4]. However, most organisations in WA-12 did not redesign their business processes. In these cases the word streamlining was more appropriate, as workflow support was used to let the process evolve towards a new situation. Although it is reasonable to advocate doing a BPR related to workflow, it must be concluded that a redesign is not strictly necessary.

6

Conclusions

It is likely that workflow support systems will affect the way in which businesses operate, because there is a sufficient number of good examples of successful workflow projects. The current use seems to be more in streamlining processes rather than in a complete redesign. Although quite likely in theory, it remains to be seen whether workflow support systems will be the great BPR enabler in the daily practice of businesses. The case studies in this research project show specific characteristics that give workflow its own flavour. The coordination of work across the boundaries of departments or even organisations is the key problem that is addressed by workflow management. Current workflow research addresses problems such as transaction models for workflow systems, database primitives for workflow support, concepts and system architectures. The problems that occur in practice however have to do with integration on a technical and organisational level, methods and techniques and a lack of theory. There is an apparent discrepancy between ongoing research and workflow practice, which makes it necessary to revisit research agendas. Issues that should be topics of workflow research include distribution of workflow enactment functionality, the use of existing standards for integration on different levels and the use of existing technology to under the control of a workflow support system. 10

From the WA-12 research we have learned that the triggering behaviour is the prime aspect of workflow. Therefore, we believe that this aspect should be the first to be considered in any analysis of workflows. This conclusion has implications for the way in which organisations are being analysed today, which is often procedure- or data-oriented. The analysis for workflow support should focus on interactions rather than actions in the business process. Consequently, there is much attention to interactions across departmental boundaries and even across corporate boundaries. This conclusion has been worked out by the author in a modelling technique called Trigger Modelling [11], which has been designed especially for easy analysis of workflows and is supported by formal semantics. Further research in the area of workflow support needs to be done. This research is mainstream business information technology research, because of the strong interaction between business science and computer science. The following research questions need attention (among others):

 How should a workflow be represented in order to generate the corresponding enactment engine(s)?  How should enactment engines at different locations work together to mimic a single enactment engine?  Which are the interactions between workflows, and how do the affect the business process as a whole?  Which theory of workflow support will help workflow analysts?  Which generalised solutions for technical integration problems can be offered to the end-user in ready-to-use modules?  How must workflow support systems of different vendors be made to cooperate and behave like a single system?  How can workflow-based BPR be effectuated with minimal risk involved?

Acknowledgements The authors wish to thank Gaston Aussems, Matthijs Duitshof, Richard Huffmeijer and Erik Mulder and the participating organisations for their cooperation in this research project. We also with to thank DCE Nederland B.V., Data General, Deloitte and Touche, Euroforum, Image Group Europe, MID, Otten System Consulting, Pallas Athena B.V., Staffware Benelux B.V. and Wang Nederland B.V for their efforts to find the participating organisations.

References [1] BLYTH, A., CHUDGE, J., DOBSON, J., AND STRENS, M. Ordit: A new methodology to assist in the process of eliciting and modelling organisational requirements. In Proceedings of the Conference on Organisational Computing Systems (Milpitas, California, USA, Nov. 1993), ACM Press, pp. 216 – 227. [2] DAYAL, U., HSU, M., AND LADIN, R. Organizing long-running activities with triggers and transactions. In Proceedings of the 1990 ACM SIGMOD International Conference on Management of Data (Atlantic City, NJ, 1990). [3] DEACON, A., SCHEK, H.-J., AND WEIKUM, G. Semantics-based multilevel transaction management in federated systems. In Proceedings the 10th Int. Conf. on Data Engineering (ICDE’94) (Houston, Texas, Feb. 1994). 11

[4] DENNING, P., AND MEDINA-MORA, R. Case study: George mason university. In New Tools for New Times: The Workflow Paradigm (Alameda, CA, Mar. 1994), Future Strategies Inc., pp. 235–251. [5] EISENHARDT, K. Building theories from case study research. Academy of Management Review 14, 4 (Oct. 1989), 532–550. [6] ELMAGARMID, A. Database Transaction Models for Advanced Applications. Morgan Kaufmann Publishers, Inc., San Mateo, CA, 1992. [7] FAFCHAMPS, D. Ethnographic workflow analysis: specifications for design. In Human Aspects in Computing. Design and Use of Interactive Systems and Work with Terminals. Proceedings of the Fourth International Conference on Human-Computer Interaction (Amsterdam, 1991), H.-J. Bullinger, Ed., Elsevier, pp. 709–15. [8] GARNETT, P. Workflow: A methodology for performing a qualitative risk assessment. In 13th National Computer Security Conference. Proceedings. Information Systems Security. Standards - the Key to the Future, Washington DC (Gaithersburg, MD, USA, 1990), NIST, pp. 470–9 vol.2. [9] GERRITS, H. Redesigning information production processes for controlled production time. IFIP Transactions A [Computer Science and Technology] A-14 (1992), 143–149. [10] HAMMER, M. Reengineering work: Don’t automate, obliterate. Harvard Business Review (July 1990), 104–112. [11] JOOSTEN, S. Trigger modelling for workflow analysis. In Proceedings CON ’94: Workflow Management, Challenges, Paradigms and Products (Oct. 1994), A. B. G. Chroust, Ed., Oldenbourg, Wien, M¨unchen, pp. 236–247. [12] JOOSTEN, S., AUSSEMS, G., DUITSHOF, M., HUFFMEIJER, R., AND MULDER, E. Wa-12: an empirical study about the practice of workflow management. Tech. rep., University of Twente, dept. of Comp. Sc., P.O. Box 217, 7500 AE ENSCHEDE, the Netherlands, July 1994. Research monograph. [13] JOOSTEN, S., MULDER, E., AND MCCRORY, J. Workflow literature guide. Sept. 1994. ¨ , B., RAUSCH-SCHOTT, S., AND RETSCHITZEGGER, W. Trigsflow active object[14] KAPPEL, G., PROLL oriented workflow management. In Proceedings HICSS ’95 (1995). to appear. [15] LEIFER, R. Matching computer-based information systems with organizational structures. MIS Quarterly (March 1988). [16] LEYMANN, F., AND ALTENHUBER, W. Managing business processes as an information resource. IBM Systems Journal 33, 2 (1994). [17] MARTIN, P., AND TURNER, B. Grounded theory and organizational research. Journal of Applied Behavioral Science 22, 2 (1986), 141–157. [18] MEDINA-MORA, R., WINOGRAD, T., FLORES, R., AND FLORES, F. The action workflow approach to workflow management technology. In Proceedings CSCW ’92: Sharing Perspectives (1515 Broadway, New York, New York 10036 USA, Nov. 1992), J. Turner and R. Kraut, Eds., Association for Computing Machinery, pp. 281–288. [19] MINTZBERG, H. The Structure of Organizations. Prentice-Hall, Englewood Cliffs, NJ, 1979. [20] ORLIKOWSKI, W., AND BAROUDI, J. Studying information technology in organizations: Research approaches and assumptions. Information Systems Research 2, 2 (1991), 1–28. [21] OVERBEEK, J., POTTJEWIJD, P., BROEKHUISEN, H., AND SPANHOFF, G. Stroomlijnen van werkprocessen, Aanpak voor analyse en verbetering van interne bedrijfsvoering (Streamlining of work processes, an Approach for analysing and improving internal business processes, in Dutch). DCE Nederland b.v., 1993. 12

[22] SCHUSTER, H., JABLONSKI, S., KIRSCHE, T., AND BUSS LER, C. A client/server architecture for distributed workflow management systems. In Proc. Parallel and Distributed Information Systems Conference (Sept. 1994), pp. 253–256. [23] WINOGRAD, T., AND FLORES, F. Understanding Computers and Cognition: A New Foundation for Design. Ablex Publishing Corporation, 335 Chesnutt Street, Norwood, New Jersey, 1986. [24] WORTMANN, J. Factory of the future: towards an integrated theory for one-of-a-kind production. IFIP Transactions B [Applications in Technology] B-2 (1992), 37–74.

13