Workflow Automation: Overview and Research Issues

Information Systems Frontiers 3:3, 281–296, 2001  C 2001 Kluwer Academic Publishers. Manufactured in The Netherlands. Workflow Automation: Overview and Research Issues Edward A. Stohr Wesley J. Howe School of Technology Management, Stevens Institute of Technology, Castle Point on Hudson, Hoboken, NJ 07030, USA E-mail: estohr@stevens-tech.edu J. Leon Zhao University of Arizona, McClelland 430, Tucson, AZ 85721, USA E-mail: lzhao@bap.arizona.edu Abstract. Workflow management systems, a relatively recent technology, are designed to make work more efficient, integrate heterogeneous application systems, and support interorganizational processes in electronic commerce applications. In this paper, we introduce the field of workflow automation, the subject of this special issue of Information Systems Frontiers. In the first part of the paper, we provide basic definitions and frameworks to aid understanding of workflow management technologies. In the remainder of the paper, we discuss technical and management research opportunities in this field and discuss the other contributions to the special issue. Key Words. workflow management systems, workflow overview, research issues 1. Introduction “Office automation” was a dream of the 1970’s. The hope at the time was to eliminate paper and automate a large proportion of office work. Like so many other information technology movements, office automation did not achieve its promise. Instead, paper has proliferated and only isolated office tasks such as word processing, mail merge, and faxing, have been automated. To be sure, the modern office is far different from the offices of the day when the term office automation was coined. But, the early dreams are yet to be realized. We are still saddled with paper, and inefficient processes prevent organizations from responding to the demands of a world characterized by global competition, shifting markets, and rapidly changing technology. Workflow management systems are a new breed of information technology designed to automate business processes by coordinating and controlling the flow of work and information between participants. They can also be viewed as a form of middleware linking separate office and legacy applications into an enterprisewide system. Many software companies crowd the workflow market by providing stand alone workflow products (IBM, Oracle, and Hewlett Packard) or implementing a workflow component in their existing software packages (Microsoft, SAP, BEA Systems, CommerceOne, and WebMethods.) Workflow management systems are now used not only for coordinating office tasks, but also for managing inter-organizational information flows. In short, workflow automation is a new wave of business process engineering for both intraand inter-organizational processes. While successful commercial Workflow Management Systems have been developed in the United States as well as abroad, it is interesting to note that most academic research on the subject has been conducted in Europe—a fact that is reflected in the authorship of the articles in this special issue. Given the implications of the technology for organizations, it is also interesting to note that research articles in the topic first appeared, and, for the most part, continue to appear, in the computer science literature. We believe that the present volume is the first issue of a major information systems journal that is entirely devoted to the topic of workflow technologies and their application in organizations. We hope that this collection of articles on current workflow research issues will stimulate others to work in this fascinating and important area. 281 282 Stohr and Zhao Because workflow management systems are relatively new, this introduction provides an overview of important workflow automation concepts as well as an introduction to the articles in the special issue. In the first several sections of the paper, we discuss the technical aspects of WfMS. We then develop a framework for the discussion of workflow research issues that is rooted in an organizational or managerial view of the field. This lays the foundation for discussing the five very different and valuable contributions to this special issue. 2. Brief Overview of Workflow Workflow management systems (WfMS) automate entire work processes, rather than isolated tasks. The idea of automating the transmission of documents from person to person in an organization first arose as a necessary adjunct of imaging systems in early applications such as insurance claims processing (Sviokla and Elam, 1992). Since that time, many commercial WfMS have been introduced (Ader, 2000) and other technologies such as document management systems, call centers, and enterprise resource planning systems (ERP) have developed workflow capabilities. Like other information technologies, the architecture of WfMS has moved from mainframes, to client server architectures, and more recently to the Web. The technology has experienced a 26% annual growth rate and an expanding range of applications (Gartner, 2000). Successful WfMS deployment results in significant process cycle time reductions, cost reductions, improved accuracy, greater control, and greater worker satisfaction. For example, (Ader, 2000) reports productivity gains from process automation of 5% to 30% and cycle time reductions of 30% to 80%. According to the Gartner survey cited above, successful workflow projects met or exceeded ROI expectations approximately 89% of the time. A comprehensive set of case studies of successful workflow projects is contained in (Fischer, 1997, 1998, 1999, 2000). Unfortunately many workflow projects are unsuccessful. In a related area, Grove et al. (1995) estimate that business process reengineering projects fail 50% of the time. The most important reasons for failure include poor change management, resistance from rigid bureaucratic organizations, and lack of sustained top management support. Workflow projects generally involve reengineering and similar failure rates and reasons for failure are likely to apply (Joosten et al., 1994). It is apparent that workflow automation is both a technical and managerial subject. Difficult challenges abound in both areas. Perhaps understandably, the technical issues have received more attention by researchers than the managerial and human issues. Fortunately, practical considerations have forced the investigation and development of workflow technology improvements along lines that satisfy organizational needs in a general way. For this reason, we are able to frame our very brief review of workflow research and development issues primarily in terms of organizational issues. However, there is an urgent need for more research on the impacts of workflow automation tools on humans, on the nature of work, on appropriate organizational structures, and on support for non-routine work. 3. Workflow Management Systems: Basic Concepts 3.1. Basic definitions We first introduce some basic concepts of workflow using terminology derived from the Workflow Management Coalition (WfMC, 1996).1 While different authors and workflow products use their own terminology, the following definitions are fairly standard. A business process consists of a sequence of activities. It has distinct inputs and outputs and serves a meaningful purpose within an organisation or between organisations. An activity is a discrete process step performed either by a machine or human agent. An activity may consist of one or more tasks. A set of tasks to be performed by a user in a workflow system is called a worklist. The worklist is prepared by the WfMS and displayed to the user on his/her screen. The individual tasks on the worklist are also called work items. A workflow is the automation of a business process in whole or in part, during which documents, information or tasks are passed from one participant to another according to a set of procedural rules. In other words, a workflow is a specific kind of process, whose transitions between activities are controlled by an information system, the WfMS. Note that it is not necessary for any or all of the information to be in electronic form (although this is usually the case). Processes and their corresponding workflows exist as logical or generalised models that have specific Workflow Automation: Overview and Research Issues instances. Thus, a new claims workflow instance must be initiated every time a new claim is received by the claims department in an insurance application. When a new workflow instance is instantiated, the job to be performed is often called a case. Many different cases may be in process simultaneously under the guidance of the same workflow model. Each case will have different data associated with it and may therefore take a different path through the organisation as dictated by the workflow model. This leads to a different perspective on workflow—that of the cases or jobs that are processed through the system. Consistent with this view, the package of data items that are associated with a job or case is called a work folder in some commercial systems. More generally, initiation of a new case causes the generation of associated work objects that are to be processed. The WfMS is said to enact the real world process for each process instance. A WfMS supports individual users in the performance of the tasks associated with the activity for which they are responsible by providing access to the required software and information. It also coordinates the flow of work from one user to another. Task assistance is most important for a business process that is performed predominately by a single person— the so-called “case” approach that is often touted in the business process reengineering literature (Davenport and Noria, 1994). It is also possible for tasks to be completely automated. For example, Kraft Food’s Accounts Payable workflow application contains a number of expert system “robots” that automate tasks such as validation and tax rate checking (Fischer, 2000, pp. 249–266). On the other hand, an emphasis on routing is more natural where the business process is designed to coordinate the activities of different people in situations where the division of labour (or expertise) is important. As discussed more fully later, a WfMS performs a number of coordination and control activities that should be of great interest to management scientists. Coordination activities include instantiating workflow instances, assigning human or non-human agents to perform individual activities, generating worklists, routing tasks and their associated work objects from agent to agent, sending reminders to human agents that a specific work item has to be performed, and so on. Thus, the coordination activities are similar to those that might be performed by a human supervisor in an office or factory. In the case of interorganizational workflows, the coordination task is made more 283 difficult because of the different locations and interests of the various parties to the transaction. The control functions performed by a WfMS include monitoring and reporting on the performance of processes and the human agents involved in their execution, enforcing deadlines, ensuring security, and authenticating users. In this aspect, a WfMS combines activities of human supervisors as well as those of accounting and auditing staff. Roughly speaking, a WfMS is to business processes as a DBMS is to data. A DBMS relieves developers of the need to manage the physical aspects of data, while a WfMS relieves developers of the complex task of managing the flow of data and control between interrelated process activities or tasks. Database management systems remove data dependence and therefore make information systems more flexible and adaptive to changes in data contents and structures. Analogously, workflow management systems remove process flow dependence (Leymann and Roller, 2000). Fig. 1 illustrates the idea of removing data and flow dependence by database management systems and workflow management systems. One of the great advantages of a WfMS is its ability to separate the logic of the workflow from the logic of the applications that are used to automate or assist users in performing specialized tasks. This allows application programs to act as independent computational units and greatly simplifies the task of enterprise integration. Workflow systems start other applications such as word processors, spreadsheets, imaging systems, and legacy mainframe applications. A related concept is that a WfMS can be viewed as “middleware” serving to integrate diverse applications such as mainframe legacy systems and ERP applications. 3.2. Workflow management system frameworks A standard framework developed by the Workflow Management Coalition (WfMC) provides a convenient platform for describing the capabilities of a workflow management system (see Fig. 2). The WfMS “engine”, shown at the center of the figure, contains the logic necessary to sporn new business process instances in response to triggering events, execute routing logic, determine the human or software agents to perform each of the process activities, route documents to the selected agent, generate and maintain a menu or “worklist” of tasks to be performed by each human agent, maintain security, and log all activities. As shown in the figure, the WfMS engine provides five standard workflow application program interfaces 284 Stohr and Zhao Fig. 1. The role of workflow automation. Fig. 2. The WfMC standard interfaces. (WAPI’s) by means of which it interacts with the external world. Interface 1 (Process Definition Services) is used at build-time to define the workflow process. Usually this consists of a graphic interface through which the developer defines the workflow process as a partial ordering of distinct activities. Interface 2 (Workflow Client Applications) defines the standard mechanism for interacting with the users of the WfMS—the worklists that appear on user screens, and so on. Interface 3 ( Invoked Applications) is the API through which the WfMS interacts with user applications such as ERP or mainframe legacy systems. This capability allows the WfMS to provide an important enterprise integration function. Interface 4 (Other workflow enactment services) is the standard API through which WfMS provided by different vendors can interoperate. This functionality is of particular importance in e-commerce applications. Interface 5 (Administration and Monitoring Services) is the API through which administrators gather Workflow Automation: Overview and Research Issues information from the log maintained by the WfMS. This supports managerial control through detailed analysis of the activities of each agent and the performance of the overall workflow process. The WfMC model is useful for understanding the relationships between the WfMS engine, its users, and other software systems. We now turn to a framework that is useful when considering the analysis and design requirements for a workflow system. The WfMS “enacts” an electronic model of a portion of the organization. This model consists of five related views or “perspectives” (Curtis, Kellner, and Over, 1992; Jablonski and Bussler, 1996). Fig. 3 illustrates the interrelations between these concepts. The functional perspective. What does the workflow do? This perspective specifies the workflow by decomposing high level functions into tasks that can be allocated to human or software agents. The behavioral perspective. When are the activities and tasks executed? A process model defines the time precedence of individual process activities, the events and triggers, and the pre- and post-conditions for activities. Rules associate agents with roles, roles with activities, and activities with data and software applications. These can be specified using process logic in Petri nets (Reisig, 1998), state-charts (Harel, 1987), or other process models (Kumar and Zhao, 1999). The informational perspective. What data is consumed and produced? This perspective describes the Fig. 3. The five perspectives of workflow. 285 business data, documents, and electronic forms that are transported between agents, and the files and databases that store persistent application information. The operational perspective. How is a workflow activity implemented? The WfMS provides coordination as specified by the behavioral perspective. The operational perspective specifies the workflow tools and applications that perform the discrete steps of the process. The organizational perspective. Who performs what tasks and with what tools? The organizational perspective defines the organizational hierarchy, the “roles”, the security and access authorizations, the document approval levels, the teams and work groups that need to be recognized, and the list of agents (individual people and software applications). A role is a collection of tasks and responsibilities that can be assigned to an agent at run-time. The notion of role is important for two reasons. First, it provides flexibility since the WfMS is insulated against the comings and goings of individual people in the organization. Second, it facilitates dynamic balancing of work loads since users can be switched between roles as bottlenecks occur. 3.3. Workflow analysis and build-time tools At build-time, the systems developer must define each of the above perspectives and ensure that the resulting system is internally consistent. 286 Stohr and Zhao The analysis and design of a workflow system presents new challenges to systems developers because these systems impact so many technical, human, and organizational aspects of the organization. A comprehensive development methodology is suggested by Kwan and Balasubramanian (1999). Powerful analytical tools such as Petri nets are needed to formally analyze workflow processes for correctness and consistency. Two articles in this special issue, by van der Aalst and Wirtz, et al., respectively, use the Petri net formalism. The van der Aalst article contains an appendix explaining the technique. Some WfMS engines are, in fact, designed around the Petri net formalism. Other WfMS are based on a state-event formalism. Most workflow processes are, however, designed using less formal techniques. Process modeling tools have been around for many years. Graphical representations were developed first for software specifications, for example, IDEF0 (Feldman, 1998) and incorporated in computer-aided software CASE tools such as ARIS (Scheer, 1998). The business process reengineering movement triggered a new spate of tools offering dynamic simulation capabilities (for example, CASEwise, 2000). All of the above tools have been used in the design phase of workflow applications. Nowadays, unless simulation of alternative process designs is required, most WfMS provide adequate graphical modeling tools. Moreover, in most cases, these graphical tools directly define the run-time system. Some systems such IBM’s MQ Series Workflow also provide a scripting language to support the definition of the processes, activities, organizational structures, data entry forms, and database structures, etc., that define the workflow. In other cases, such as Lotus Notes, only a scripting language is available to develop the workflow system. 4. Classes of WfMS Systems and Applications The majority of commercial WfMS today follow the highly structured model of a WfMS that was described in the previous section. They are therefore best suited to applications with standard inputs, processes, and outputs. Workflow applications in this area include production systems such as policy application and claims processing in insurance and order entry and billing in manufacturing. Here, processes are well defined and stable, although each instance of a process may follow a different path through the organization. These applications are characterized by a high volume of transactions, several thousand or more per day, and by the need for accuracy, reliability, efficiency, short processing cycles, security, and privacy. Administrative applications such as travel expense and new employee processing fit this standard model but have less stringent throughput requirements. Production and administrative WfMS are suitable for routine, clerical situations that demand efficient, consistent and accurate execution of fairly standard processes. They are not suitable for the increasingly important area of knowledge work, where processes can not be defined precisely beforehand and there is a need for communication and collaboration between workers. Here, processes are not structured or premeditated but, rather, “emerge” as actors choose their next steps one at a time. For these situations, more flexible, ad hoc workflow systems and/or collaborative tools are more suitable. Ad hoc workflow systems allow spontaneous, user-controlled document routing and support collaborative sharing of documents. Application areas for ad hoc WfMS include engineering design, planning for marketing campaigns, brainstorming, and knowledge sharing. Another viewpoint on this range of applications is to say that ad hoc and collaborative systems are relatively “unspecified” while application systems, at the other end of the spectrum, are highly “specified” (Bernstein, 2000). A view of the workflow arena based on this “flexibility” or “specificity” dimension is shown in Fig. 4. Outside of the workflow area, at the human-oriented end of the spectrum lies groupware such as IBM’s Lotus Notes and Fujitsu’s Teamware. At the machineoriented end of the spectrum lies application software, such as ERP or mainframe-based payroll, inventory, and order processing systems. Fig. 5 shows examples of commercial workflow and collaborative tools arrayed on the two dimensions of value added and repetitiveness (Ader, 2000). (To reconcile Figs. 4 and 5, note that the ability to execute repetitive transactions efficiently is usually accompanied by a lack of flexibility). The system classes along the flexibility spectrum face different challenges. Research and design issues for ad hoc WfMS include, ease of generating new oneoff processes, understandability, flexibility, information sharing, and protocols for decision support and collaboration. At the other end of the flexibility or Workflow Automation: Overview and Research Issues 287 Fig. 4. The flexibility spectrum. Fig. 5. Examples of commercial tools. specificity scale, research and design issues for production systems include scalability, ability to integrate external applications (ERP, legacy systems), security, data integrity, exception handling, process control and audit information, ease of use, and the ability to modify process designs without compromising existing transactions. An even more interesting challenge to researchers is to integrate systems of different classes so that, for example, knowledge workers using an ad hoc system can easily gather data from a production workflow system. A research prototype of a system that can accommodate the different levels of “specificity” along the flexibility frontier, has been developed by Bernstein (2000). 5. WfMS Architectures The appropriate architectures for WfMS of the different classes is a matter of debate. Fig. 6 shows three basic alternatives. Production architecture: Production WfMS support complex workflows, and communicate with corporate databases, mainframe systems, etc. Usually, a Fig. 6. Basic architectures. workflow folder containing all the documents related to a particular process instance or “case” is generated and presented in turn to each agent that needs to be involved in processing the case. Most existing production WfMS consist of a single workflow engine using a single database to provide services to a number of users in a (fat) client-server architecture. Examples of commercial production WfMS include Staffware, Filenet, and IBM’s MQ Series Workflow. 288 Stohr and Zhao Messaging-based architecture: Administrative WfMS support less demanding throughput requirements and are often implemented by adding workflow features to e-mail transport mechanisms such as SMTP. This primarily involves adding electronic form, logging, and worklist generation capabilities to the underlying e-mail system. These systems integrate easily with office suites using the DDE, MIME and OLE protocols. They are also fit naturally with telephone call centers and computer integrated telephony to bring telephone calls directly to the customer service representative’s desktop. Examples of commercial WfMS in this class include JetForm’s Intempo and Microsoft Exchange. Document-centric architecture: Systems using this architecture add workflow capabilities to document management systems. Example applications for these systems include management of engineering drawings and Lotus Notes administrative applications that are implemented using a scripting language. In cooperative workflow, work may be processed by one user passing work to another user through an e-mail message containing pointer(s) to the document(s) to be worked on next. The second user will then check the relevant documents out of the database, perform the work on them and return them to the database for the next user. Commercial systems in this class include Lotus Notes, and Documentum. Existing products in each of these three classes are rapidly being Internet-enabled. In addition, some systems such as Fujitsu’s i-Flow are being entirely developed using Web-based object-oriented architectures based on the Object Management Group’s (OMG) Common Object Request Broker Architecture (CORBA) (OMG, 1992). Architectures in this genre promise a much higher degree of interoperability between internal applications and the workflows of trading partners. They are driven by the rise of electronic commerce and the need for integration in distribution and supply chain applications. Because of their object orientation, these new WfMS should also be much easier to adapt to changing business requirements. The paper by Kwang and Ellis in this special issue provides a unique architecture classification scheme based on the degree to which processing logic is performed centrally or distributed to a process class or to individual instances of the process. We discuss this paper in more detail later. In another development, a sub-committee of the WfMC is developing an XML message set for interactions between requesters and providers of workflow business services. The proposed Wf-XML standard (WfMC, 2000) addresses issues of interoperability between workflow systems by taking advantage of emerging XML standards. It is based on existing workflow interoperability standards including previous efforts of the WfMC (WfMC, 1998), jFLOW in OMG Workflow Management Facility (OMG, 1998), and the Simple Workflow Access Protocol (SWAP) (Bolcer and Kaiser, 1999). Wf-XML provides a structured and well-formed XML message set encoding for both synchronous or asynchronous messagehandling that is independent of the particular transport mechanism. Interoperability issues are important in the ebusiness era because more and more companies are outsourcing their work to other companies and heterogeneous workflow systems from multiple companies need to interoperate seamlessly. In fact, workflow management systems are becoming platforms for Internet EDI. For instance, BEA Systems, Inc. has purchased a workflow company to use workflow engines to coordinate various e-business components (www.bea.com). Automating interorganizational processes across supply chains presents significant challenges in workflow management. Because point-to-point links between every buyer and supplier are impractical, the trend is to transform supply chains into open marketplaces. Three types of e-marketplaces are envisioned: process portal, process vortex, and dynamic trading processes (Sheth, van der Aalst, and Arpinar, 1999). A process portal helps companies manage intercompany processes on a one-to-one basis. For example, in the telecommunications industry, process portal services include consumer-to-business e-commerce applications such as integrated billing and customer self-care. E-commerce sites such as www.dell.com are examples of process portals that manage inter-company processes. A process vortex is more complex than a process portal because it can manage multi-party processes. Here, interactions between buyers and sellers occur through a third-party marketmaker as opposed to peer-to-peer interactions between buyers and sellers. Examples of process vortices are the Ariba and CommerceOne marketplaces. Dynamic trading processes, which are very transient and spontaneous, are not easily handled by current workflow systems. Hence, new workflow techniques are needed that will take into account unique company attributes and services to dynamically construct workflow processes on a per Workflow Automation: Overview and Research Issues customer basis. This is a major challenge for the workflow research community. 6. Research Perspectives Our aim in this special issue is to bring the issues of workflow research to a wider, information systems audience. In this brief overview, we can only skim the surface of possible research opportunities. Table 1 lists some research opportunities under the three categories of technical, managerial, and market, economic and social issues.2 The list is by no means exhaustive. The papers in this special issue cover five different areas (highlighted in the table) and are representative of the research currently under way in the field. In this section, we very briefly discuss the first and last research categories. We spend more time on the organizational and management issues because there has been so little research in this area and the opportunities for a significant contribution are correspondingly great. In essence, a WfMS is a “machine bureaucracy” (Mintzberg, 1983) in electronic form—a fact that should be of great interest to organization theorists! 6.1. Technical research issues Workflow technologies are not as mature as (say) database technology in terms of scalability, flexibility, fault tolerance, and the other technical qualities listed as research issues in the table. This is because they are a newer technology and because they face more demanding requirements such as long transactions (lasting hours or days), geographic distribution of processing nodes, and the involvement of humans in the processing steps. The technical issues in Table 1 are being actively researched and many research and commercial WfMS are being developed that will provide proof of concept for new ideas on workflow modeling, hardware and software architectures, and new approaches to handling problems of data integrity, and so on. However, progress is likely to be steady rather than revolutionary because of the technical complexity of these systems. Georgakopoulos, Hornick, and Sheth (1995) and Bolcer and Taylor (1999) provide good overviews of technical research issues. Of particular interest to management scientists is the technical research in the areas of exception handling (Hagen and Alonso, 2000), adaptive and flexible workflow management (Divitini and Simone, 2000), and workflow security (Gudes, Olivier, and van der Riet, 1999). 289 Table 1. Workflow research issues Technical issues • Interoperability: standards and implementation strategies • Scalability and WF architecture • Availabiliy, reliability, concurrency, fault tolerance • Security, especially in B2B workflows • Increasing the scope of systems (desktop, department, enterprise, B2B) • Integration of WfMS with: external application systems, ERP, component-based application systems, business objects • Integrity of cross-enterprise workflows (deadlocks, rollback, etc.) • Monitoring & controlling cross-organizational workflows • Integration of multi-paradigm process modeling methods • Business process management suites (modeling, simulation, verification, workflow, analysis) • Dynamic process change • Exception handling with and without manual intervention • Authorization flexibility and integrity • Resource management and brokering Management and organizational issues • New analysis and design methodologies for automated processes • Flexible modeling of workflows, verification of process models • Matching workflow to organizational strategy, structure, and culture • Analysis and design of collaborative systems • Workflow implementation and change management • Cost/benefit analysis and impact studies • Factors leading to adoption of workflow systems • Controling work and monitoring of employees • Performance measurements and incentive systems • Integration of audit trail data and data warehouses; data mining opportunities • Run-time scheduling and utilization of workflow human and software agents • Impact of WfMS on clerical work and middle management Market, economic and social issues • WF market directions and investment opportunities • Prospects for competing stand-alone, embedded, & component-based workflow engines • Impact of workflow on supply chain automation, electronic markets, & industry structure WfMS as a vehicle for enterprise integration and electronic commerce. To satisfy the demands for enterprise integration and electronic commerce, WfMS take advantage of the increasing availability of distributed processing technologies such as WWW, CORBA, XML, and Java. High interoperability is imperative for business-to-business electronic commerce because open trading transactions require cooperative workflows between buying, selling, and intermediary organizations (Fu et al., 1999). While many have 290 Stohr and Zhao stressed the importance of interoperability in electronic commerce systems, little work has been done to specify interoperability requirements. A new framework for describing interoperability consisting of four levels of workflow interoperability (connectivity, expressivity, visibility, and flexibility) is described in Zhao (1999). In an e-commerce environment, it is conceivable that workflows with various levels of automation must coexist. Some workflow systems can be completely automated with, possibly sophisticated, software agents, while other workflow systems may be completely manually coordinated. These heterogeneous workflow systems must be integrated seamlessly to support e-commerce transactions (Leung and Chung, 1999). There have been several attempts to develop systems, specifically for e-commerce workflows. These include the Vortex-based Coordination System proposed in Hull and Su (1999) and the Virtual Enterprise Coordinator (Ludwig and Whittingham, 1999). Vortexbased Coordination Systems provide a coordination interface in workflow systems that integrates workflow systems for passing information, querying status and history of workflow instances, and coordinating participating workflows. The Virtual Enterprise Coordinator is a method for establishing and managing workflow processes for outside organizations on the basis of simple agreements. Using VEC, organizations can provide external partners with a controlled way to access workflow processes, while retaining the freedom to change the internal details of those processes. 6.2. Managerial research issues Given the potential impact of workflow automation on organizations, it is surprising that there is so little research on the human and organizational impacts of workflow management technologies. We cover three sets of research issues here: WfMS in organizations, WfMS as a vehicle for knowledge sharing and learning, and WfMS as a support platform for performance measurement and control. Workflow in an organizational context. Researchers on work in organizations disagree with regard to the impact of information technologies on workers (Attewell and Rule, 1984). At one extreme, some researchers see automation as having a negative impact on the workplace. They claim that automation fragments work, deskills workers, and destroys morale. Others see automation leading to the elimination of drudgery and thereby to richer and more fulfilling jobs. There are also two different views as to the nature of work. The first view sees work as a structured process of activities that need to be performed. This corresponds to a naı̈ve view of workflow automation. However, even in the most rigid workflow process, a lot of activity takes place outside the purview of the WfMS. This includes, work-related conversation and manual work arounds for exceptional situations. The second view of work asserts that work is an emergent activity determined over time both by the technology itself and by the humans who use that technology (Orlikowski, 1992). This view is relevant to structured workflows and, to an even greater degree, to unstructured knowledge work. Workflow research should be informed by both of these research themes. Installing a WfMS inevitably changes business processes and work activities and therefore has a major impact on people and organizational culture. In this context, much might be learnt from studies of work such as those by Suchman (1983) and the socio-technical school (Mumford and Weir, 1979). Little research of this nature has focused on automated workflow systems, per se. An empirical study by Joostens et al. (1994) relates workflow management to the organizational structure types defined by Mintzberg (1983). In addition to the positive impacts of workflow noted earlier, this study cites possible negative impacts including: overly rigid procedures, reduced motivation of workers because their work is more mechanical, over reliance on machine performance data by managers, underestimation of the importance of human communication in performing work, and reduced learning by employees. Explicitly considering these “organic” aspects of the organization, in addition to the “mechanistic viewpoint” of workflow software, can be an important consideration in choosing workflow software and designing systems (Stohr and Zhao, 1997). Consider a typical “soft” workflow design issue: worker autonomy. A WfMS can impose a work environment that is so rigid that it is difficult to handle exceptions (Sachs, 1995). As a consequence, users develop time consuming manual “work arounds” which lower efficiency and create dissatisfaction with the system. Providing a less rigid workflow—one in which the users can, within limits, define the flow of work, could be advantageous. In other situations, such as workflows involving monetary transactions, no exceptions to the established work pattern should be tolerated and workers should have almost no freedom to change their pattern of work. To Workflow Automation: Overview and Research Issues fit either situation, a WfMS should allow the designer to vary the amount of autonomy provided to workers. For example, one way to increase worker autonomy is to substitute user choice for a hard-coded branching rule. Another way is to choose an ad hoc WfMS so that users can define their own workflows. Research is needed on how a workflow system can be designed, not only to execute the logic of the workflow, but also to satisfy human, cultural, and organizational needs. Besides the issue of worker autonomy, other “organic” design variables that should be considered are: process adaptability, worker empowerment, centralization versus decentralization of decision making, adherence to the hierarchy of the organization, team support, learning, performance measurement, and incentive schemes. Unfortunately, almost no research has been done in this area. The paper by Davis et al in this special issue is a notable exception. WfMS as a vehicle for control and performance measurement. Workflow automation provides unique opportunities for directing work and measuring performance. In effect, a WfMS supports a cybernetic feedback mechanism executing a continuous loop of six sub-processes: goal setting, directing work, monitoring work, measuring performance, recording outputs, analyzing outputs, and evaluating personnel (Child, 1989). Each of these sub-processes, especially the first and last, should involve significant management input. But, a WfMS automates a very significant proportion of the control cycle. As a result, a number of techniques from management science and accounting can be implemented with relative ease (zur Muhlen, 2001). With regard to directing work, most WfMS perform a rudimentary load balancing function. It is not difficult to imagine that more sophisticated personnel planning and resource scheduling techniques, analogous to those used in some manufacturing settings, could be brought to bear in “office factories” such as insurance claims processing. Because the WfMS always maintains knowledge of its state, monitoring performance on a real time basis is possible, and performance measurement becomes a matter of examining the system log. Using data mining techniques, it is possible to analyze processes in minute detail to identify bottlenecks and develop ideas for continuous improvement (Leymann and Roller, 2000). WfMS also facilitate the application of Activity-based Costing techniques (Cooper and Kaplan, 1991) to allocate costs to services and processes. This is because a large proportion of the 291 data collection is performed automatically. A similar observation applies to performance measurement and incentive techniques such as the Balanced Score Card (Kaplan and Norton, 1996). While workflow automation provides unprecedented opportunities to direct work and measure performance, there is a “dark side” to all of this. Management may have a tendency to over control, thereby stifling initiative and demotivating employees (Bowe and O’Flaherty, 1995). Worse still, a WfMS can be intrusive and subject to management abuse. Research is needed on the impact of various types of automated monitoring and control on the morale of employees and the overall performance of organizations. WfMS as a platform for knowledge sharing and learning. Because WfMS automate the mechanical aspects of work, an argument can be made that workers are free to perform more satisfying and creative intellectual activities. WfMS are, of course, a repository of valuable process knowledge. If the WfMS is capable of dynamic change as described by van der Aalst in this special issue, it can greatly facilitate continuous process improvement. Beyond this, a WfMS can directly support the learning objectives of an organization by acting as a vehicle for the collection and distribution of knowledge. We provide two examples. The first is an actual implementation of the “double loop learning” concept of Argyris (1994). The claims processing workflow system employed at Cigna involves about 30 steps executed by a single “case manager” (Nolan and Stoddart, 1995). The “inner learning loop” of the process executes work tasks and captures ideas and problems as a built-in part of the workflow. An analysis team that forms the “outer loop” analyzes suggestions from employees and the process data produced by the inner loop workflow to determine better ways to perform the work and interface with the customer. The ideas from the outer loop are then fed back to the work process in the inner loop. A key idea is that these chunks of knowledge from the outer loop are made available at the associated step in the workflow so that knowledge is supplied at precisely the point where it is needed in the decision process. Our second example, process-driven knowledge delivery goes one step further by searching for useful information on the user’s behalf (Abecker, Bernardi and Sintek, 1999; Zhao, Kumar and Stohr, 2001). The main thrust of the research in this area is to combine the 292 Stohr and Zhao process modeling and enactment functions of workflow management with the information modeling and delivery mechanisms of knowledge management. Research issues include adaptive user profiling, real-time process monitoring, accurate matching of knowledge demand and supply, and object-oriented knowledge capture and delivery. 6.3. Economic, market, and social issues Some studies in the trade literature have examined the market for workflow automation technologies (Gartner, 2000) and there has been considerable speculation on the competition between rival technologies, such as traditional stand-alone workflow systems versus workflow systems embedded in other applications such as ERP and CRM. However, little is known about the penetration of workflow automation in industry and its impact on organizations. On a grander scale, since WfMS can support e-commerce by speeding processes and reducing transaction costs, there is a possibility that the technology will have a long term impact on market structure. Finally, the automation of a significant portion of white collar work should increase productivity, but may have unanticipated social consequences in the long term. 7. Contents of the Special Issue We now introduce the five papers in this special issue in the context of the organizational issues discussed in the previous section (see Table 1). Dynamic process change. Information technology can have a significant impact on the ability of organizations to execute new strategies and to respond to external events (Lucas and Olson, 1994). This is particularly true of legacy systems, which are notoriously inflexible. It is also a danger with WfMS because it may be hard to change a process design both for technical reasons and because of resistance from users. On the other hand, workflow automation can help because at least there is a definitive definition of the process—a “process memory”, which is often lacking in manual processes. The existence of very long transactions, sometimes lasting days (loan application processes) or months (insurance claims), complicates the process of modifying an existing workflow process. It is relatively easy to process newly arriving work through a modified process. But then one is left with the question of how to handle process instances that are not yet complete. For legal and business policy reasons, it may be necessary to migrate them to the new process immediately—or at least as soon as this can be done without compromising the integrity of the existing process instance. An uncontrolled switch to the new process might result in skipped process steps, incorrect results, or even process deadlock. This is the issue addressed by Wil van der Aalst in his paper, “Exterminating the Dynamic Change Bug: A Concrete Approach to Support Workflow Change.” One approach to dynamically changing a process instance is to match the completion of the existing workflow design with the completion of the modified process design (Weske, 2001). In this volume, van der Aalst takes a more fine-grained approach to this problem by defining a “change region”, a subgraph of the process graph for the existing process instance that must be exited before the switch to the new process can be safely executed. The results in the paper are rigorously proved using Petri net theory. Authorization flexibility and integrity. To streamline manual work processes, there is a need for WfMS to reflect the policy of the organization with regard to decision making authorizations and security policies. The “role” concept introduced earlier provides a first level constraint on what each agent is authorized to perform. For example, a workflow activity, such as approving an expense voucher for payment, may be performed only by someone authorized to play the “Supervisor” role, and only certain people with the requisite training and responsibilities can act as supervisors. When the WfMS determines that the next process task is to be performed by a supervisor, it chooses from the list of agents who can play that role on the basis of their availability and current work load. Most WfMS systems provide this basic capability. However, in a real organization, the pattern of workflow authorizations may be much more complex. What happens if the only person authorized to play the role of supervisor in the payroll department is away? Most organizations will have the payroll checks approved by the supervisor’s manager. As another example, many financial workflows require enforcement of the “separation of duties” principle—for example, the person authorizing purchases should not also be the person authorized to pay the invoices. In addition to managing the agent-role assignments, there is a need Workflow Automation: Overview and Research Issues to specify which tasks can be performed by each agent so that appropriate software and information resources can be dynamically assembled for use by agents as they play their roles. Enabling flexible agent-role and role-task assignments and yet enforcing constraints, such as the separation of duties constraint, is a challenging task for WfMS designers and developers. In their paper, “Managing Workflow Authorization Constraints through Active Database Constraints,” Fabio Casati, Silvana Castano, and Maria Grazia Fugini, provide an elegant solution to the general problem of workflow authorizations. They represent organizational structure using a hierarchy of role levels and use the formalism of Event-Condition-Action rules from the field of active databases to define and execute the authorization process. Scalability and workflow architecture. Workflow systems may process hundreds or even thousands of workflow instances (transactions) per day. For example, telecommunications companies typically service ten thousand or more cases per day and employ hundreds of workflow users (Georgakopoulos, Hornick, and Sheth, 1995.) The processes themselves can be complex, involving hundreds of separate activities with complex branching logic. Inter-organizational workflows, in particular, are often complex and, in addition, require security capabilities such as digital certificates and encryption services, which add to the processing overhead. Finally, production workflow systems have requirements for flexibility, availability, robustness, and modifiability. Current systems run into serious performance barriers when handling requirements such as these. Developing systems architectures to achieve scalability is therefore a major research issue. Kwang-Hoon Kim and Clarence Ellis in their paper, “Performance Analytic Models and Analyses for Workflow Architectures” discuss a number of possible architecture choices for very high throughput WfMS. Their paper provides a novel framework for classifying possible workflow architectures based on the degree to which processing logic is performed centrally or distributed to a process class or to individual instances of the process. The major contribution of their paper is their use of an analytical technique based on queuing theory to assess the ability of three distinct workflow architectures to handle increasing workloads. They conclude that software architecture is as important as hardware architecture in determining throughput 293 capabilities. They also conclude that the client-server architecture commonly employed by commercial WfMS does not scale as well as the “class-active” or, ‘instance active” alternatives they also analyze. Modeling of workflows. As discussed in an earlier section, many general purpose and specialized tools can be used to specify a workflow system. The purpose of the WfMC standard process definition interface depicted in Fig. 2 is to allow multiple definition tools to provide input to the WfMS at build-time. Unfortunately, this part of the WFMC standard has yet to be finalized. Worse still, there is a mismatch between the available process design tools and the object-oriented distributed architecture of a modern WfMS. This is the problem addressed in the paper, “The OCoN Approach to Workflow Modeling in Objectoriented Systems,” by Wirtz, Weske, and Giese. In this paper, the authors describe a comprehensive modeling language that captures the five different “workflow perspectives” mentioned above. The language uses the Unified Modeling Language (UML) (Fowler and Scott, 2000) for the data representation component and Petri nets for rigorous modeling of the dynamic components. An important objective is to maintain the independence and relative simplicity of the five individual perspectives while, at the same time, unifying them to enforce consistency. This design approach should be especially beneficial for complex processes and, especially, for business-to-business applications. Analysis and design of collaborative work systems. The first four papers in this special issue focus on workflow management systems to support structured workflows. In contrast, the paper, “Creating Shared Information Spaces to Support Collaborative Design Work,” by Davis et al., describes experiences with a collaborative system to support knowledge work in the product development group at a major manufacturer. As knowledge work becomes more critical to organizations, the support of unstructured work situations becomes increasingly important. Systems to support collaborative work differ in a number of ways from traditional workflow systems. Information use is no longer organized around a particular process, but is much more diffuse and informal. As a consequence, the analysis phase of such a project calls for a much broader requirements gathering scheme in which an attempt is made to observe existing patterns of information flow. 294 Stohr and Zhao In their paper, Davis et al describe the use of an “information mapping” technique to reveal patterns of use and weaknesses in the current support. The goals of a collaborative system are to promote collaboration and information sharing rather than efficient information processing. This results in a number of novel requirements that are described in the paper. Finally, the paper discusses some preliminary findings gained from observing the system in use over an extended period. 8. Conclusion WfMS help implement large, heterogeneous distributed execution environments. In this sense, they are a response to current demands for decentralized decision making, efficient processes, detailed information for monitoring and control purposes, and the rise of ecommerce. In our discussion of research opportunities, we discussed research problems that were inherent in the technology from its beginning as a tool for supporting work in organizations. But we also discussed the expanding horizon for workflow technologies as a platform for enterprises application integration, as a means for communication with ERP systems, as a vehicle for management control and performance measurement, and as a platform for knowledge distribution and sharing. Research opportunities abound in all of these areas. Workflow technologies will no doubt evolve and may take entirely different forms than those we see in research labs and commercial applications today. A large portion of future white collar work will be completely automated or, at least, supported to a significant extent by workflow management systems. Interorganizational and customer-facing processes will also be workflow enabled. We believe that these trends are inevitable and that they will have profound implications for workers, organizations, markets, and society at large. Notes 1. Founded in 1993, the WfMC is a non-profit organisation of vendors, users and academics, whose mission is to establish standards for workflow terminology, interoperability and connectivity (http:www.wfmc.org). 2. The items in the table are based on Alonso and Schek (2001), a panel session on research at a recent conference (HICSS 2000), and our own experience. References Abecker A, Bernardi A, Sintek M. Enterprise information infrastructures for active, context-sensitive knowledge delivery. In: Proceedings of the European Conference on Information Systems, 1999. Ader M. Workflow Comparative Study, 2000 ed. available from www.waria.com. Argyris C. Good communication that blocks learning. Harvard Business Review, July-Aug., 1994. Attewell P, Rule J. Computing and organizations: What we know and What we don’t know. Communications of the ACM 1984; 27(12):1184–1192. Bernstein A. Populating the specificity frontier: IT-support for dynamic organizational processes. PhD Dissertation, MIT, 2000. Bolcer GA, Kaiser G. SWAP: Leveraging the web to manage workflow. IEEE Internet Computing 1999;3(1):85–88. Bolcer GA, Taylor RN. Advanced workflow management technologies. Journal of Software Process Practice and Improvement, Jan. 1999. Bowe P, O’Flaherty B. Implementing workflow automation systems: Implications for control. Working Paper 5/95, Executive Systems Research Center, University College, Cork, Ireland, 1995. CASEwise Corporate Modeler 2000, http://www.casewise.com. Child J. Organizations: A Guide to Problems and Practice. Paul Chapman, 1989. Cooper R, Kaplan RS. Profit priorities of activity-based costing. Harvard Business Review. May-June 1991:130–135. Curtis B, Kellner MI, Over J. Process modeling. Communications of the ACM 1992;35(9):75–90. Davenport TH, Noria N. Case management and the integration of labor. Sloan Management Review Winter 1994:11–23. Divitini M, Simone C. Supporting different dimensions of adaptability in workflow modeling. Computer Supported Cooperative Work: The Journal of Collaborative Computing 2000;9(3-4):365– 397. Feldman CG. The Practical Guide to Business Process Reengineering Using IDEF0. Dorset House, 1998. Fischer L. Excellence in Practice: Innovation and Excellence in Workflow and Imaging. Lighthouse Point, Florida: Future Strategies Inc., 1997–2000. Fowler M, Scott K. UML Distilled: A Brief Guide to the Standard Object Modeling Language, 2nd ed. Addison-Wesley, 2000. Fu S, et al. A practical approach to web-based internet EDI. In: Proceedings of the 19th International Conference on Distributed Computing Workshop, 1999. Gartner. Enterprise applications—Adoption of E-business and document technologies: 2000–2001. Available through http:// www.aiim.org. Georgakopoulos D, Hornick M, Sheth A. An overview of workflow management: From process modeling to workflow automation infrastructure. Distributed and Parallel Databases 1995;3(2):119– 153. Grove V, Jeong SR, Kettinger WJ, Teng TC. The implementation of business process engineering. Journal of MIS 1995;12(1):109– 144. Gudes E, Olivier MS, van der Riet RP. Modeling, specifying and implementing workflow security in cyberspace. Journal of Computer Security 1999;7(4):287–315. Workflow Automation: Overview and Research Issues Hagen C, Alonso G. Exception handling in workflow management systems. IEEE Transactions on Software Engineering 2000;26(10):943–958. Harel D. Statecharts: A visual formalism for complex systems. Science of Computer Programming 1987;3(8):231–274. Hull R, Su J. The vortex approach to integration and coordination of workflows. Workshop on Cross-Organisational Workflow Management and Co-ordination, 1999. Jablonski S, Bussler C. Workflow Management: Modeling Concepts, Architecture and Implementation. London: Thompson Computer Press, 1996. Joosten S, Aussems G, Duitshof M, Huffmeijer R, Mulder E. An Empirical Study of the Practice of Workflow Management. University of Twente, Center for Tele-informatics, 1994. Kaplan RS, Norton DP. Linking the balanced scorecard to strategy. California Management Review 1996;39(1):52–79. Kumar A, Zhao JL. Dynamic routing and operational controls in workflow management systems. Management Science 1999;45(2):253–272. Kwan M, Balasubramanian PR. Adding workflow analysis techniques to the IS development toolkit. In: Proc. 31st Annual Hawaii International Conference on System Science (HICSS), Jan. 1996; vol. IV:432–440. Leung KRPH, Chung JML. The liaison workflow engine architecture. In: Proceedings of the 32nd Annual Hawaii International Conference on Systems Sciences (HICSS). Maui;5–8 Jan. 1999. Leymann F, Roller D. Production Workflow: Concepts and Techniques. Prentice Hall, 2000. Lucas HC, Olson M. The impact of information technology on organizational flexibility. Journal of Organizational Computing 1994;4(2):155–176. Ludwig H, Whittingham K. Virtual enterprise coordinator— Agreement-driven gateways for cross-organizational workflow management. International Joint Conference on Work Activities Coordination and Collaboration, 22–25 February, 1999, San Francisco, USA. Mintzberg H. Structure in Fives: Designing Effective Organizations. Englewood Cliffs, N.J.: Prentice-Hall Inc., 1983. Mumford E, Weir N. Computer Systems in Work Design: The ETHICS Method. New York: John Wiley & Sons, 1979. Nolan RL, Stoddard DB. CIGNA property and casualty reengineering (A). Harvard Business School Case Study 9-196-059, Boston MA: Harvard Business School Publishing,1995. OMG Object management group. Object Management Architecture Guide. OMG TC Document 92.12.1, Rev. 1.1, 1992. OMG Object management group business object domain task force, jFLOW—Workflow management facility. Revised Submission July 4, 1998. Orlikowski W. The duality of technology: Rethinking the concept of technology in organizations. Organization Science 1995;3(3):398–427. Reisig W. Elements of Distributed Algorithms : Modeling and Analysis With Petri Nets. Berlin: Springer Verlag, 1998. Sachs P. Transforming work: Collaboration, learning, and design. Communications of the ACM 1995;38(9):36–45. Scheer A-W. ARIS—Business Process Frameworks, 2nd Ed. New York: Springer, 1998. Sheth AP, van der Aalst W, Arpinar IB. Processes driving the networked economy. IEEE Concurrency 1999;7(3):18–31. 295 Stohr EA, Zhao JL. A Technology adaptation model for business process automation. In: Proc. 30th Annual Hawaii International Conference on Information Systems, Jan. 1997. Suchman L. Office procedures as practical action: Models of work and system design. ACM Transactions on Office Systems 1983;1(4):320–328. Sviokla JJ, Elam JJ. Image Processing Project at USAA. Harvard Business School Case Study 9-190-155, Boston, MA: Harvard Business School Publishing, 1992. Weske M. Formal foundation and conceptual design of dynamic adaptations In a workflow management system. In: Proc. 34th Annual Hawaii International Conference on System Science (HICSS), Jan. 2001, vol. IV:390–399. WfMC Workflow Management Coalition. http://www.wfmc.org, 1996. WfMC. Workflow standard—interoperability: Internet e-mail MIME binding, workflow management coalition, WFMC-TC-101825Sept.-1998, Version 1.1. WfMC. Workflow management coalition standard—Interoperability Wf-XML binding document number WFMC-TC-1023, 1-May2000, Version 1.0. Zhao JL. Interoperability requirements for cooperative workflows in electronic commerce. In: Proceedings of the 2nd International Conference on Telecom. & Electronic Commerce (ICTEC99), Nashville, TN, Oct. 6–8, 1999. Zhao JL, Kumar A, Stohr EA. Workflow-centric information distribution through email. Journal of Management Information Systems, 2001;17(3):45–72. zur Muhlen M. Workflow-based process controlling—Or: What you can measure you can control. In: Fischer L, ed. Workflow Handbook 2001. Lighthouse Point FL:Future Strategies Inc. 2001: 61–78. Edward A. Stohr holds a Bachelor of Civil Engineering degree from Melbourne University, Australia, and M.B.A. and Ph.D. degrees in Information Science from the University of California, Berkeley. His research focuses on the problems of developing computer systems to support work and decision making in organizations. He is currently a professor in the Information Management Department at Stevens Institute of Technology. For the period 1984-95 he served as Chairman of the Information Systems Department at the Stern School of Business, New York University. From 1995 through 1999, he was Director of the Center for Information Intensive Organizations at the Stern School. In 1992, Professor Stohr served as chairman of the executive board of the International Conference on Information Systems (ICIS). Professor Stohr serves on the editorial boards of a number of major journals. J. Leon Zhao is an associate professor in the MIS Department, University of Arizona. He holds a 296 Stohr and Zhao Ph.D. degree in Information Systems from University of California, Berkeley, an M.S. degree from University of California, Davis, and a Bachelor of Engineering degree from Beijing Institute of Agricultural Mechanization. He has previously taught in Hong Kong University of Science and Technology and College of William and Mary. His research work has appeared in (or has been accepted to) Management Science, Information Systems Research, IEEE Transactions on Knowledge and Data Engineering, Communications of the ACM, and Journal of Management Information Systems.