1

Workflow Management Systems vs. ERP Systems: Differences, Commonalities, and Applications

Jorge Cardoso1, Robert P. Bostrom2 and Amit Sheth1

1LSDIS Lab, Computer Science Department University of Georgia

Athens, GA, USA, 30602 jcardoso@uga.edu, amit@cs.uga.edu

2MIS Department Terry College of Business

University of Georgia, Athens, GA, USA, 30602 BBostrom@terry.uga.edu

Contact information: Amit Sheth

LSDIS Lab, Computer Science Department University of Georgia, USA

amit@cs.uga.edu Tel:(706) 542-2310, Fax: 2966

2

Abstract. New economies and global markets with their accompanying intense competition has generated the need for organizations to develop and adopt new working models and infrastructures. Most companies have recognized the need for business process reorganization and vigilant management to increase efficiency and to survive intense competition. Information systems have been a widely adopted solution to support process redesign and management. In particular, two classes of systems have distinguished themselves: Workflow Management Systems (WfMSs) and Enterprise Resource Planning (ERP) systems. Both solutions focus on the automation of business processes, data transfer, and information sharing across the organization. While the targeted problems are the same, the technological approach and features of each solution are distinct. It is, therefore, important to discern the advantages and limitations of each system. In this paper we present a comprehensive description of the differences of the two systems. We also discuss how the two types of systems can be used independently and together to address intra (enterprise) and inter (e-Commerce) organizational application integration now and in the future. The “ future” discussion will focus on roles of the two systems in the Web services architecture. This paper will help system implementers, managers and organizations to make better and more precise decisions when acquiring and implementing such systems.

Keywords: Workflow Management Systems, Enterprise Resource Planning Systems, and

Enterprise Application Integration.

3

1 Introduction

Today organizations face the challenges of globalization, which have led to unprecedented levels of competition. In competitive global markets, organizations need to find better business solutions, with flexible and reliable structures. Much of an enterprise’s infrastructure and organization is enabled by information systems that directly or indirectly support business processes of crucial importance to growth and survival. By managing these processes more efficiently, competitive advantage can be gained via cost reduction, product enhancement, and customer service improvements.

Global market change has become a constant, which reveals a clear and imperative need for continuously improving business processes. Since business processes are fundamental building blocks of an organization’s success, information technologies that focus on process management and improvement have been good candidates to help organizations to fulfill their corporate visions and to improve their competitive positions. In the past two decades, a special interest has been given to two distinct solutions that improve business processes: Workflow Management Systems (WfMSs) and Enterprise Resource Planning (ERP) systems.

WfMSs and ERP systems manage business processes. When managed correctly, a coherent picture of what is happening to an organization can be captured. The definition and management of processes allow for the integration of functional departmental data and applications allowing for better decision-making and planning. This integration is especially important when legacy applications are involved, since very often they do not interoperate with other systems.

�

�

�

��� ���

�

�

��� ��

Workflow Management System

Data

Applications

Human Resources

Workflow ModelFlexible

Customized

Legacy Systems

ERP System

Application

DataData

Data

Parameter based(embedded workflow

model)

Fig. 1. WfMSs and ERP systems

While both systems focus on business processes, the approach taken by each system is distinct. WfMSs provide a workflow model (Fig. 1), which is customized to accommodate specific business process structures. Workflows are designed based on business processes already existing in an organization that need to be improved or managed better. Once the design phase of the model is completed, instances are created to carry the actual steps described in a given workflow. During their execution, the workflow instances can access legacy systems, databases, applications, and can interact with users. Workflow systems are flow-independent; the control and data flow among tasks is graphically described during the workflow design phase. This makes applications independent from the underlying workflow system. The workflow applications include a set of independent specifications describing how the workflow system will schedule task executions and how the data will flow at runtime.

4

ERP systems are implemented around the idea of prefabricated applications (Fig. 1). Vendors develop applications for particular sectors of the industry. Organizations acquire the applications according to their needs. The workflow model is embedded in these applications. The applications are also parameterized to allow some flexibility in configuring business processes. Each application includes the logic necessary to control organizational processes from a data and information point of view. To archive a better “ fit” with the implementing organization, applications often need to be tailored by setting thousands of parameters.

Figure 1 clearly represents one of the key differences between WfMSs and ERP systems. WfMSs have a definition and model of the workflow/process that system implementers work directly with to develop applications. Workflow systems are process-centric. In ERP systems, the workflow model is usually embedded in the application software. System implementers work at configuring the system via setting parameters that are accessed by the applications. The more parameters an ERP has, the more flexibility to configure the workflow process in different ways. The ERP workflow model is often not very clear because it is embedded in applications and parameter tables. Of course with WfMSs, developers tend to have more flexibility since they are developing the workflow model directly, being limited only by the tools provided in the WfMSs development platform. The ERP systems are data-centric, providing a common homogeneous data infrastructures across the organization.

We could use the analogy with programming languages to illustrate this difference. Working with WfMSs is similar to programming in a non-procedural high-level language where developers are working directly with a graphical representation of the business workflow model. The WfMS development platform then generates necessary application components, database linkages, etc. to execute a workflow process. Working with ERP systems is like working with 3rd

generation procedural language, where it is necessary to deal directly with applications and data. The ERP workflow model is often not very clear because it is embedded in applications and parameter tables.

The correct selection of WfMSs or ERP systems is an important step for an organization. This paper gives a clear picture of the similarities and differences between WfMSs and ERP systems. We believe that our contribution will help system implementers, managers, and organizations to make better and more precise decisions when faced with the acquisition and integration of such systems.

This paper is structured as follows. Section 2 gives an overview of workflow systems and ERP systems. Section 3 presents the technological evolution of the systems. This will allow for a better understanding of each system. In section 4, the dimensions that will be used to distinguish WfMSs and ERP systems are presented. Three dimensions are analyzed: domain scope, technological scope, and system implementation. For each dimension, we present the main differences associated with each system. Each dimension distinguishes a set of important characteristics that are essential to consider when adopting one of the systems. Section 5 summarizes how best to apply each system. Section 6 discusses how the two types of systems can be used independently and together to address intra (enterprise) and inter (e-Commerce) organizational application integration. Section 6 also addresses how research in the two areas can be integrated. Finally, section 7 presents our conclusions.

2 Overview

WfMSs are a key tool for organizations motivated to improve competitive advantage, customer service, productivity, and conformity with standards. A workflow system is composed of a set of

5

applications and tools that allows for the definition, the creation, and the management of the various activities associated with workflows (business processes). Workflow instances run on one or more workflow engines, which are able to interpret workflow definitions, interact with workflow participants, and, where required, invoke the use of external tools and applications.

A few decades ago, work was carried on traditionally; work items passed from one participant or worker to another. Business process were coordinated and managed by their participants, since they inherently knew the business rules. With the introduction of workflow systems the process itself became automated, and the system became responsible for the scheduling and execution of the tasks associated with the processes.

WfMSs are based on the concept of a workflow, which is an abstraction of a business process. A workflow normally comprises a number of logical steps (known as tasks), dependencies among tasks, routing rules, and participants. A task can require human involvement, or it might be executed automatically by IT (Information Technology) applications. A workflow system reads, automates, processes, and manages workflows by coordinating the sharing and routing of information. During processing, tasks, information, and documents are passed from one participant to another in a way that is governed according to a set of rules, routes, and roles. The automation of work items increases process efficiency. Furthermore, the management and analysis of workflow instances provides an opportunity for measuring parameters of business processes in order that continuous improvements can be made [1].

ERP systems have emerged to automate business functions and offer an integrated data solution across an organization’s infrastructure. Enterprise resource planning systems are configurable information systems that integrate information and information-based processes within and across functional areas in an organization. Traditionally, companies developed separate computer applications to satisfy the needs of each of their functional segments - such as accounting, purchasing, inventory and planning. Such systems grew into inconsistent islands of information; hence their consolidation was not possible even when it was needed. As a solution, ERP systems provide the capability to manage and integrate the information and services of departments throughout an entire enterprise. This allows organizations to better manage all their resources, thus achieving cost reduction and efficiency through the integration of all information among various business processes.

3 Systems Evolution and Matur ity

The historical evolution and maturity of WfMSs and ERP systems show two distinct movements. The study of these systems provides information valuable for understanding the actual difference between the two systems, which evolved from distinct domains. Furthermore, this study explains why ERP systems have found a stronger acceptance and deployment around the world, in comparison with WfMSs.

The idea of workflow management systems arose in the 90’s. But, there is some consensus that the office information systems (OIS) field, an important field in the 70’s, is the predecessor of workflow systems [2]. The first OIS prototypes were developed in the late seventies. Pioneer systems included the SCOOP project [3], which was oriented to the automation of office procedures, and Officetalk [4, 5], which provided a visual electronic desktop metaphor, a set of personal productivity tools for manipulating information, and a network environment for sharing information.

6

In the 80’s, due to several failures in office automation projects and installations [6, 7], the interest in office information systems declined, and work was directed to the research of flexible groupware systems and models [8].

In the 90’s, the reappearance of interest in OIS occurs. New technological approaches, such as transaction processing, document image processing, and integrated office systems are investigated and developed. The fundamental support of these technologies has paved the way for the emergence of workflow management technology, which claimed to be one of the innovative applications of the 90’s. While Alonso et al. [9] point out that they are innovative, they also observe that workflow management systems have gained a high level of popularity; nevertheless, they have not yet matured into well-proven and stable technology. Research prototypes include METEOR [10], MOBILE [11], ADEPT [12], Exotica [13], and MENTOR [14]; commercial products include MQSeries Workflow [15], Staffware [16], TIBCO InConcert [17], and COSA Workflow [18]. General information on WfMSs can be found at the Workflow and Reengineering International Association [19] and the Workflow Management Coalition [20] Web sites.

Historically, the origin of ERP systems can be traced back to the 60’s, when the focus of organizational information systems was mainly on handling traditional inventories. In the 70’s, the systems focused on material requirements planning (MRP) [21]. These systems helped to translate master production schedules into the planning of raw material requirements. In the 80’s came the concept of MRP-II, which involved optimizing an entire plant’s production processes. Future evolutions included the management of other areas such as finance, human resource, engineering, and project management. New technological advances facilitated the development of software systems to manage functional units, and made possible the implementation of the conceptual model proposed by Blumenthal [22]. This model described an integrated architecture and framework for organizational information systems; it can be seen as the seed of ERP systems. Important progress has been made since then, and currently various ERP systems are available, including Baan [23], CSC [24], JD Edwards [25], Oracle [26], PeopleSoft [27], and SAP [28]. General information on ERP systems can be found at the TechRepublic Web site [29].

By analyzing the historical evolution and maturity of the two systems, we can observe that ERP systems emerged from a smooth, regular, and steady progression that can be traced from the 60’s to a high point in the mid-90’s, with major success stories across the world. This progressive evolution – which embraced basic inventory systems, MRP, MRP-II and MRP-II extensions – has lead to a trustable and well-known product in the industry, with high credibility, a good position in the market, and a strong advantage over competitive systems. Furthermore, ERP systems were in a mature state, and WfMSs were not, at the time organizations needed to solve integration problems, such as the Y2K problem and the replacement of outdated legacy systems [30].

Unfortunately, the history of WfMSs was not as notable and prominent. Office information systems, the precursor of WfMSs, cycled from high popularity in the 70’s to low popularity in the 80’s, mainly caused by unsuccessful OIS implementations. Nevertheless, technological advances made WfMSs regain a high popularity in the 90’s. In the late 90’s, we started seeing work that focuses on integrating WfMSs and ERP systems [31], which indicates both a certain stability and the importance of such systems for organizations. This cycle, which includes three phases – in the 70’s, 80’s, and 90’s – has certainly generated confusion among managers and end-users and provoked a certain reluctance to adopt workflow systems. This paper will help clear up this confusion via comparing these systems.

7

4 WfMSs and ERP systems

Keeping in mind the evolution and maturity paths of the systems under study, we now concentrate our attention on conceptual differences between the two systems. We divide our comparison study in three main parts: domain scope, technological scope, and system implementation. Each part, which we call a dimension, contrasts the two systems from a specific point of view. The major differences are summarized in Table 1.

WfMSs ERP systems

Domain Scope Customized processes

Domain independence

Ad-hoc and dynamic domains

No international settings

Embedded processes

Domain specific (use of reference models)

Static domains

International settings

Technological Scope

Process-centric

Supports workflows involving humans, IT applications, and transactional workflows

Heterogeneous and autonomous environments

Data-centric

Transactional processes

Homogeneous environments with common data infrastructures

System Implementation

Acquired as ready systems; Code automatically generated

Bottom-up approach

May require data conversions

Based on pre-written “off-the-shelf ” components

Top-down approach

Require data conversions

Table 1 – WfMSs vs. ERP Systems summary table

4.1 Domain Scope

The first dimension analyzes both systems according to their domain scope. The domain scope defines the suitability of a system for a specific type of application or organization. This characterization is important since organizations have different needs and characteristics. For example, a multinational organization obviously has different needs compared to an organization that has only a regional base, and a financial organization has different requirements from a marketing organization.

Workflow systems have been installed and deployed successfully in a wide spectrum of organizations. Muth et al. [32] observe, “most workflow management systems, both products and research prototypes, are rather monolithic and aim at providing full-fledged support for the widest possible application spectrum.” The same workflow infrastructure (e.g., METEOR [33]) can be deployed to various domains, such as bio-informatics applications [34], healthcare [35],

8

the telecommunication industry [36, 37], the military [38], and administrative processes for school administration [39]. Leymann and Roller [40] discuss the application of workflow to other areas, such as mobile computing, systems management, multi-databases, the Internet, application development, object technology, operating systems, and transaction management.

In figure 2 a workflow process from genomics exemplifies how workflow systems can allow the design of processes for a broad spectrum of domains. A major task in genomics is determining the complete set of instructions for making an organism. The first draft of the entire sequence of the human genome has been recently reported. Genome projects are very demanding and include high costs and high labor requirements. There are many different types of tasks that must be performed, such as sequencing, sequence finishing, sequence processing, data annotation, and data submission. A single genomic workflow may be spread across multiple research centers managing the individual tasks carried out at one or more of the participating centers. Many of the challenges of building an information system to manage a physically distributed gemone project can be addressed by a workflow system.

Fig. 2. Genomic Workflow Example

The workflow design or process flow model graphically specifies the control and data flow among tasks. For example, in Figure 2 we see a workflow process composed of several tasks interconnected with transitions. The tasks illustrated with circles represent automatic tasks, while the ones illustrated with boxes represent sub-workflows.

At runtime, the workflow system reads the model specifications and transparently schedules task executions, providing the right data at the right time. Workflow systems allow the management of distributed genomic tasks located at different research centers, allow the inter-operation of heterogeneous tasks, such as DNA sequencing machines, matching algorithms,

9

human resources, and supply a framework to easily reengineer a genomic workflow when new technological, biological, and chemical advances are made.

Workflow systems enable developers to separate the flows among a system’s components (applications and data) from the workflow process model, making these applications flow-independent. The separation of flows among tasks and activities keeps workflow systems outside the application domain. The flow-independence concept makes workflow technology suitable to a large number of domains; therefore, WfMSs constitute a generic tool that can be used to integrate different types of data and applications in a broad spectrum of contexts.

Sheth et al. [41] estimate that the number of readily available workflow systems is between 200 and 300. While some workflow systems are generic, others are more oriented to particular domains. The overall high degree of domain independence allows for customization, specialization, and a high level of uniqueness for the workflows created. While it as been said that workflow systems can be applied to many domains, no valuable solution has yet been proposed for workflow deployment in an international setting. This is because WfMSs do not yet include some indispensable features, such as internationalization, multi-currencies, and multi-languages, which are valuable when deploying workflows in worldwide markets.

On the other hand, ERP systems are domain specific due to the adoption of reference models or process templates that embody the best business practices. ERP systems include libraries of predefined business processes for various functional areas. Reference models supposedly reflect preferred business models, including underlying data and process models, as well as organizational structures. As a result, ERP systems provide a solution that satisfies standard organizations, supplying a broad spectrum of dedicated applications.

ERP systems have developed industry best-practice solutions for specific domains, such as aerospace and defense, automotive, consumer products, chemicals, engineering and construction, health care, high technology and electronics, oil and gas, pharmaceuticals, the public sector, retail, software, telecommunications, and utilities. The system allows for the setting of thousands of parameters in order to customize applications to particular organizational features.

While the adoption of best practices is a seductive approach, Kumar and Hillegersberg [42] note considerable mismatches between the actual country, industry, and company specific business practices and the reference models embedded in ERP systems. This mismatch has led to many implementation problems and failures. One of the most notable failures is FoxMeyer Drug, a $5 billion company that filed for bankruptcy in 1996, arguing that the primary cause of problems was a failed ERP implementation [43](Scoot and Vessey, 2001). Mismatches between ERP systems and organizational processes often call for a considerable implementation of code and an adaptation of the models used.

Compared to WfMSs, ERP systems do not supply an effective framework for dynamic domains, in which a process topology can constantly change due, for example, to new technological advances. Additionally, ad hoc and heterogeneous processes are better managed using WfMSs, mainly because they do not rely on predefined reference models. On the other hand, ERP systems are well suited for international domains, since they offer features such as multi-language support, and multi-currency support. These features are important since language is one the cultural barriers to effective and efficient cooperation, and currency is the basis for any trading process among international organizations. Additionally, ERPs provide dedicated solutions for specific industries, allowing organizations not striving for a differentiation to be more efficient and competitive.

10

4.2 Technological Scope

The second dimension that we use to compare WfMSs and ERP systems is the technological scope dimension. This dimension characterizes the systems based on their technological capabilities. Both technologies are similar in that their architectures have moved from mainframes, to client server architectures, and more recently to the Web. Both systems manage business processes. But processes can be inherently distinct and include very different structures and requirements.

As an example, let us consider two business processes. The first one, a trading process, is used to update customer orders, inventory, and financial databases in response to commercial transactions between suppliers and customers. The workflow reflects the changes that are made to the order database, to the inventory, and to the financial database. The second business process manages a genetic sequencing procedure [44]. The workflow is responsible for coordinating lab assistants in their tasks, controlling sequencing equipment, and executing DNA matching algorithms against genetic databases. The two processes have a different set of technological requirements; in the first case, the support is targeted toward database access, data synchronization, and database interoperability, while the second process requires human coordination, equipment control, and application execution.

WfMSs and ERP systems have been developed with distinct sets of technological capabilities. WfMSs expose a broader spectrum of capabilities than ERP systems. The goal of WfMSs are the coordination of human tasks, and the integration of independent, heterogeneous and often distributed information systems (HAD), data, and applications [37, 45]. In particular, workflow technology allows for the integration of previously separate communication, information, and data flows into a working process at any time, while accommodating unpredictable complexity.

At the same time, workflow technology is an environment that supports the integration of previously separate information systems, such as office information systems, electronic data processing, telecommunication networks, etc. [46]. WfMSs technology focuses its attention and effort on supporting three different types of applications [37]:

(1) Workflows involving humans (our second example above), (2) Workflows involving systems and applications (examples provided in the integration

section), and (3) Transactional workflows (our first example above).

In type 1 workflow systems, the workflow involves humans who collaborate, and who are

coordinated when performing tasks. The WfMS is responsible for controlling and coordinating the human tasks. Such settings increase the complexity of WfMSs implementation; the system has to share responsibility to ensure the consistency of documents and workflow data among its users.

In type 2 systems, WfMSs implementations are responsible for the control, coordination, and execution of computation-intensive operations and specialized software tasks, with little or no human intervention. In addition to being highly automated, this type of workflow system may require access to HAD information systems (for example, relational databases, web servers, and XML-repositories), presenting a good means of integrating applications that cannot be rewritten, and of integrating monolithic codes too complex to maintain.

Finally, type 3 WfMSs involve human intervention and system orientation that is transactional-based. Such systems involve the coordinated execution of multiple tasks that may

11

involve humans, require access to heterogeneous, autonomous and distributed systems, and support selective use of transactional properties (e.g., atomicity, consistency, isolation, and durability) for individual tasks or for entire workflows. The support of such properties requires sophisticated techniques such as concurrency control and recovery techniques in order to ensure the consistency and reliability of the system. The challenge involved in the development of methods that support transactional workflows is complex. Nevertheless, solutions have been investigated in the context of extended transaction models (from database management systems) and include work from Rusinkiewicz and Sheth [47], Georgakopoulos et al. [37], Eder and Liebhart [48], Alonso et al. [9], and Worah and Sheth [49].

ERP systems constitute an integrated solution only concerned with the integration of distributed data. The objective is to provide an integrated basis for serving all business units (financial, sales, human resource, etc.) from one base of information. The underpinning of shared data structures across applications eliminates the need to pass data step-to-step among applications, which can now access data from a common structure. The focus is mainly on structured data transactions. ERP functional modules operate directly with common interoperable databases to ensure consistent information for all purposes. This makes the manipulation of data easy.

The ERP concept makes the strong assumption that data infrastructures are homogeneous across the organization, that is, that data is stored in interoperable databases, and in some cases, that databases used are all from the same vendor. Some ERP systems (for example, Oracle 11I [26]) only support specific database management systems. Such a strong assumption forces organizations to migrate from existing systems to a standardized environment. During implementation, only data integration from interoperable databases needs to be considered. Other ERP systems are more versatile, supporting the most well known database platforms. Such a strong assumption forces organizations to migrate from existing systems to a standardized environment. During implementation, only data integration from interoperable databases needs to be considered. ERP systems are data-centric. Thus, they are well-suited to model transactional processes for which only data integration is needed, which is the case for the first business process presented in our example.

WfMSs are process-centric and therefore address all three types of workflow systems outlined above, whereas ERP systems address only the third type, transactional workflows (which are data oriented). WfMS are more suitable to model workflows involving humans and software systems (types 1 and 2), especially if the systems are autonomous and heterogeneous. On the other side, ERP systems are more appropriate to model transactional workflows. This is because ERP systems work directly on the top of database infrastructures that supply well-defined transaction models. Nevertheless, when transactional workflows involve heterogeneous systems, a more appropriate solution would be the adoption of a WfMS.

For small organizations with heterogeneous infrastructures, the adoption of a WfMS to integrate their systems may be a more adequate solution, since it does not require the time and cost investments associated with ERP implementations.

4.3 System Implementation

The third dimension under analysis answers a question often raised by managers: “How does the implementation of a WfMS differ from the implementation of an ERP system?” This dimension characterizes the systems based on the strategy and methodology used during the implementation

12

phase. Both systems supply a large improvement in software implementation productivity. Both systems come ready to be used to execute or support a business process [41].

Thus, there is not a lot time wasted in reinventing the wheel and writing ever-new software. This trend has been particularly significant among the largest companies, who in the past considered that they had the necessary resources to develop business solutions on their own. WfMSs and ERP systems differ in three main aspects: pre-written vs. automatically generated code, bottom-up vs. top-down strategy, and data conversion.

Pre-wr itten vs. Automatically Generated Code

Business information systems can be designed as custom applications, or they can be purchased as standard ”off-the-shelf” solutions. Since the development of custom applications is generally expensive and is often plagued by uncertainties, the second approach if often preferred when implementing information systems. ERP systems are composed of prewritten software modules available ”off-the-shelf” ; they supply sufficient flexibility to match most organizations’ needs by the setting of thousands of parameters. When an ERP module is acquired, it is fully deployed for a department. To link different departments it is necessary to acquire different modules. For example, to link a human resource and a financial department, two ERP modules need to be deployed; one for each department. The infrastructure created allows for an automatic flow of information between the two departments.

WfMSs, on the other hand, are not module-oriented; there is no need to acquire and deploy special modules to departments that are involved in cooperation or coordination. WfMSs are spread through an organization, without the need to reengineer the foundation of each department unless desired. Since the system is generic (see section 4.1), workflows can be designed with cross-organizational [36] and cross-departmental settings. Each task of a workflow represents an activity to be carried out; it can be executed in any department.

The WfMS controls the information flow from each department and transfers it to the appropriate task to be processed. Once workflows are designed, the deployment of applications is accomplished with little programming; the system automatically generates the necessary code for each application [10]. This is an important feature since when business processes are represented as hard or semi-hard coded applications, as is the case with ERPs, an inherent flexibility is missing. The only flexibility in an ERP system comes from the parameters that have been set up. In WfMSs, the idea is to be able to model processes, typically by using visual tools, and then delegate the responsibility of ”designing” the behavior of the software to the workflow system. Automatic code generation makes the technology very suitable for the integration of legacy applications and systems.

Bottom-Up vs. Top-Down Strategy

WfMS implementation can be viewed as a bottom-up approach inside the organization. One of the starting points is to identify existing business processes – their logic, control flow, and data flow. The second step is for the organization to reengineer the process, if necessary. Once these steps are completed a workflow model can be constructed based on the information gathered. The bottom-up approach allows organizations to customize WfMSs to their business processes, rather than the inverse. The existing business processes drive the workflow model construction and final structure.

ERP implementation can be viewed as a top-down approach inside the organization. One of the starting points is to acquire an ERP package (or application) to be deployed for a particular

13

department. The package includes the core business logic for the sector being targeted. The second step is to set parameters to tailor the applications to specific characteristics and needs of the organization. The acquired application, in conjunction with its parameters, creates a business process that corresponds to the processes being replaced. Unfortunately, most of the time the deployed process does not exactly correspond to the process being replaced; as a consequence, a huge effort is necessary to manage change in the organization. The top-down approach forces organizations to follow external applications logic and policies. For this reason, change management becomes necessary and indispensable at the work-force level.

Data Conversion

Since both systems are solutions for data integration, it is expected that during system implementation some sort of data manipulation or data conversion occur. Since workflow systems do not require a uniform and interoperable data infrastructure, legacy database systems can be integrated without any substantial change. For WfMSs, data conversion is not mandatory; nevertheless, for optimization and organizational purposes, data can be converted into a more significant format. On the other hand, ERP systems frequently require data conversions. The platform defines architecture for data storage. As a consequence, legacy databases need to be replaced with ERP-compatible databases. The task also involves transferring, ”cleaning” , and improving existing data elements.

5 Applications and Integration

Now that the reader has a clear understanding of WfMS and ERP systems differences, in this section, we want to summarize the potential applications of the two technologies. We will use the model introduced previously that describes the three different types of workflow applications to support business processes [37]:

(1) Workflows involving humans, (2) Workflows involving systems and applications, and (3) Transactional workflows. Most WfMSs address all the three types of workflows outlined above, whereas ERP systems

mainly address the third type, transactional workflows. WfMSs are more suitable to model workflows involving humans and software systems (types 1 and 2), especially if the systems are autonomous and heterogeneous. On the other side, ERP systems are more appropriate to model transactional workflows. Nevertheless, when transactional workflows involve heterogeneous systems a more appropriate solution would be the adoption of a WfMS. This is because ERP systems generally rely on a common, homogeneous, and interoperable infrastructure.

Thus, organizations may need ERP systems or WfMSs, or both. Workflow management systems are more directed toward process management, involving application and data integration of heterogeneous, autonomous, and distributed systems. Most of the systems show domain independence, in the sense they can be implemented in any business sector. This type of system is particularly suited to a departmental or dynamic working groups’ scope, and its implementation is generally carried out in a bottom-up approach.

ERP systems are data-centric and, therefore, are more focused on information management and on the data integration. This type of system is domain-dependent. Business templates are

14

provided to be used in specific functional and market sectors. ERP systems are very suitable for a departmental, organizational, and cross-organizational scope operating on a national or international scale, where there is a good fit between desired organizational processes and those embedded in ERP applications. The system is usually constructed using a top-down approach, being built from prefabricated applications.

One of the key problems developers have with ERP systems is to understand the process model embedded in the applications. To address this problem, a recent trend has been to incorporate workflow components into existing ERP systems (SAP [28] is an example). Many of the ERP vendors are following this approach to take advantage of the usefulness of workflow tools. However, this strategy is simply a documentation aid since the underlying ERP architecture does not change. Some ERP vendors also provide their own stand-alone WfMS product, which is not integrated with ERP system (again SAP [28] is an example).

6 Application Integration

System interoperability and application integration are critical areas that many companies are currently struggling with. There are many failures cited in the literature. Last year, Gateway wrote off $140 million from its failed effort to run their on-line store with a purchased software system [50]. The software did not work well with Gateway’s existing systems. Another example is the candy maker Hershey Foods. They installed three software application packages, part of a $112 million system, with disastrous results due to incompatibilities with other application programs [50].

In this section, we address how WfMSs and ERP systems can be used independently or together to address intra (enterprise) and inter (e-Commerce) organizational application integration now and in the future. The “ future” discussion will focus on the roles of these two systems in the Web services architecture. Both types of systems are promoted based on their application integration capabilities. We end the section with a brief plea for research integration in this area.

6.1 Enterpr ise Integration

We are starting to see work that focuses on integrating WfMSs and ERP systems [31], which indicates a certain stability and the importance of both systems for organizations. Workflow systems can orchestrate and start other applications such as spreadsheets, legacy systems, ERP systems, etc. This capability makes them ideal for implementing workflows involving systems and applications, type 2 systems. Thus, WfMSs acting in this mode could be viewed as a type of “middleware” platform serving to integrate diverse applications such as legacy applications [49] and ERP applications [2, 49]. This capability allows WfMSs to provide an important enterprise integration function.

In the practitioner literature, the systems to develop this type of workflow applications are referred to as “Enterprise Application Integration” (EAI) tools [51]. Slater cites an example from Bose where two legacy call center applications, plus an e-Commerce Web application, are all linked to an underlying database that is connected to an ERP system. They are linked by an EAI toolset such as the one available from SeeBeyond [52].

As with workflow systems, EAI systems implementers use a graphical tool to model processes (much like the model presented in Figure 2). By simply pointing and clicking in the graphical

15

interface, a process model can be constructed, changed, or adapted. When alterations are made, the EAI software reflects the changes correctly in its code for routing or transforming data. In these types of applications, the nodes in a process model represent different external systems or applications. Each application has a single graphical connector that clearly reflects, in a simple diagram, its relationship with other systems or components. Using this approach, it is possible to continue using existing applications underneath this EAI/workflow layer and use EAI to manage and change processes.

ERP vendors are trying to provide to organizations a total set of integrated applications that meet all the organization needs. Although organizations might find this advantageous to have only one vendor to interact with, this is not happening because ERP vendors cannot meet the needs in all the areas with quality software. Even in key ERP domains, companies will often buy and integrate different vendors’ ERP components. For example, the Navy is moving toward using PeopleSoft in the human resource area and SAP in the supply area. Workflow systems, such as EAI, provide an important enterprise integration function.

6.2 E-Commerce: Value Chain Integration

Interoperability is a key issue in the e-Commerce world because more and more companies are creating B2B (Business-to-Business) links to better manage their value or supply chain. In order for these B2B links to be successful, heterogeneous systems from multiple companies need to interoperate seamlessly. Automating inter-organizational processes across value chains presents significant challenges [2]. These processes are often complex and involve more of a variety of systems than enterprise integration.

ERP vendors have moved into the supply chain management area. The integration of ERP systems into a value chain is a complex task. ERP modules are designed to reflect a particular way of doing business. Organizations must adapt to the ERP system and not vice versa. This philosophy makes the integration of two or more different businesses in the value chain difficult. One of the questions that arise is which ERP business model to select. Consider the case of integrating two ERP systems in a value chain; if the two systems are from the same vendor, the integration can be achieved after the two application models involved are modified and connected. But, if the two ERP systems to integrate have a different architecture (because they are from different vendors) the integration can be difficult to achieve.

However, using a workflow system to integrate a value chain may be simpler than using an ERP system. A WfMS can work as a bridge between two or more organizations. The approach we outlined above for enterprise integration can be applied to e-Commerce as well. Remember that a WfMS does not require a radical change to basic applications and data infrastructures of organizations. Instead, a workflow business process that spans organizations, reflecting the value chain topology, is created. This workflow interoperation capability can be applied to link and manage the control flow and data flow involved between two different ERP systems.

There are efforts in the workflow area to develop systems specifically designed for e-Commerce workflows [2]. For example, the Virtual Enterprise Coordinator (VEC) allows implementers to create and manage B2B processes based on simple agreements between business partners. The EAI tools discussed above are also used to provide real-time management of B2B processes.

16

6.3 Future Integration: Web Services

The latest IT hype is called Web services. The biggest providers of computer software and services are making large investments to support and promote it heavily [53]. What they are promoting is a whole new approach to information systems (IS) and IS architecture. The approach goes by different names: IBM calls it “Web Services” , Microsoft refers to it as “ .Net” , Oracle calls it “Network Services” , and Sun talks about an “Open Network Environment” . Web services promises to enable organizations to integrate and reuse software already built and reduce the hassle and expense of systems integration. In this section, we briefly explain what the Web services architecture is, its role in enterprise and value chain integration, and the role of workflow and ERP technology within it.

At the foundation of Web services architecture are software standards and communication protocols, such as XML and SOAP [54], which allow information to be accessed and exchanged easily among different programs. These tools allow applications/programs to communicate with each other regardless of the programming languages they were written in or the platform they were developed for. Web services are not used to build monolithic systems; they are a set of tools used to stitch together existing applications to create new distributed systems. Applications can be owned and maintained on company’s hardware or be a service that is rented from a provider on the Internet.

The middle level of the architecture is referred to as service grid [53]. The service grid provides tools for Web service users and providers to find and connect with each other. The top layer of the architecture comprises a diverse array of applications/IS, referred to as application services – such as payment processing and inventory control – that automate particular business functions. Some application services are proprietary to a company or set of companies, while other others are shared among companies like package software is today. Companies may decide to develop their own applications and then choose to sell them on a subscription basis to other companies.

In terms of integration, Web services provide the core architecture that allows any two Web applications to talk to each other. Thus, it is a very real solution to enterprise and e-Commerce application integration. When dealing with Web services, it is often desirable to compose Web services into a workflow, depicting the business process being implemented by combining the Web applications. Several researchers have identified workflows as the computing model that enables a standard method of building Web services applications and processes to connect and exchange information over the Web [55-58].We briefly addressed this application of workflow technology when discussing EAI systems in the Enterprise Integration section. Leymann et al. [59] provides a comprehensive overview of the role of workflow technology in Web services and how it is being implemented in IBM’s approach.

Lets expand the Bose’s example previously cited and recast it into a Web services framework. The Web service applications are: two legacy call center applications and an ERP system (the ERP system can be broken into separate Web services that would be treated independently) housed on internal computers; and an e-Commerce application that allows customers to make on-line orders, which is being rented from a software vendor. Once the Web services are identified, a process flow model (similar in format to the one in Figure 2) depicting the business process is constructed. Based on this model, the WfMS automatically generates the appropriate code to coordinate the flow of data and messaging between Web services using standards defined in the foundational level of the Web services architecture. The nodes (tasks) in the flow model

17

represent Web services and other activities, such as human tasks. At runtime, the WfMS reads the flow model specification and transparently schedules Web services for execution.

In interorganizational integration, separate flow models describe the activities to be performed by each company involved. These models can be integrated into a single overall process/flow model describing the interactions between the companies. When a Web service is invoked, an appropriate run-time instance is created by the WfMS within the Web services architecture. Besides using a workflow model to capture business process and Web service applications, a workflow model can also be made available as a Web service [59].

An additional advantage of workflow technology is that once the workflow model is implemented, suitable tools are available to manage the execution of business processes. This can be accomplished by defining events in the business flow model that can be used to report on progress of individual processes or overall aggregate process execution. In the IBM Web services architecture, these progress reports are collected by a dashboard infrastructure [59]. The dashboard provides a high-level summary of process status and also provides drill down into detail analyses of specific applications and activities.

Workflow technology provides the tools within Web services architecture to weave together and manage Web services within an enterprise or across enterprises [55-58]. Currently, Web services implementations only support limited integration capabilities as an alternative to the EAI tools discussed earlier. The Web services tools should be cheaper and more flexible than the EAI tools. However, current Web service implementations are not using workflow technologies, which are available in some EAI tools. Integration of applications in current Web services is accomplished at the programming level, not through a flow model.

Besides the lack of higher-level workflow interfaces, there are serious questions surrounding security and reliability of current Web services. However, Web services is an emerging technology and these issues are likely to be resolved. The biggest names in hardware and software have made major commitments and investments in Web services. If Web services can mature successfully, it will cause a major paradigm shift in the ways companies built and choose software.

The area of workflow and business process definition is an important part of Web services. This area is still under development and no definitive standards exist today. However, there are proposals currently being considered. For example, IBM has put together a proposal for a Web services flow language, WSFL, which will serve as IBM’s input into the standards process in this area [58]. The WSFL enables developers to easily, create, combine, and execute Web services for complex processes and workflows (see example in Snell [60]). Other proposals have been created by Microsoft, with XLANG [61], and by DAML [62], with DAML-S. IBM and other vendors are pushing for flow language standards that can be implemented by a variety of WfMSs.

Given how quickly ERP vendors point out the numerous unresolved issues surrounding Web services, one gets the impression that they are especially concerned with the direction Web services is taking [63]. In order to get the integration desired, customers have been locked into a particular suite of applications – based on propriety interfaces – from a single ERP vendor. However, the trade-off for the customers was that not all applications in suite were best-of-breed. Although ERP systems have solved many integration problems, most large companies still have a hodgepodge of unintegrated systems.

But with advent of Web services, much of the rationale for purchasing ERP application suites from one vendor will disappear. Although the vendors argue that they will leverage Web services to increase integration capabilities, it is difficult to see how they will out-perform a set of best-

18

of-breed applications integrated using Web services [63]. For example, a company could use Web services to integrate best-of-breed applications from ERP vendors – such as SAP and PeopleSoft – with current in-house unintegrated systems and newly purchased specialized applications as needed.

6.4 Research Integration

We want to conclude this section with a brief discussion of research in the workflow area. Stohr and Zhao [2] outlined key research issues in this area. Although the integration issues previously discussed were cited as critical research areas in their article, the key role of workflow technology in Web services was not mentioned. Other than the Web services issue, we can add little to their list of research issues. However, we would like to express support for some of Stohr and Zhao views on research and add some of our own points.

Stohr and Zhao note that most academic research in workflow area has been done in Europe and the research appears mostly in the Computer Science literature. The special issue in which their article appeared was an attempt to expose and stimulate the Information Systems (IS) community to work in this important area. We hope this issue and our article, in particular, further stimulates IS interest in workflow systems.

It is interesting to note that most ERP research has taken place in the United States and appears in IS journals (see Scott and Vessey [64]). ERP research is relatively unknown in Computer Science. Both WfMS and ERP researchers are interested in information technology that focuses on process improvement and management. There is a real need to see integrated research teams, from Computer Science and IS, attack some of the key workflow issues and challenges. The authors of this paper, two computer scientists and an IS Professor, are a good example of an integrated team. Stohr and Zhao [2] list three major research areas: technical issues; management and organizational issues; and market, economic and social issues. Technical issues have had the most focus since they are the primary interest in computer science. ERP researchers in IS bring important expertise, relevant research models, and empirical data in the latter two research areas. Since these issues are also applicable to WfMS, a better integration of research in these two areas, via joint research teams or other mechanisms, is needed.

A similar argument can be made for teaching. Although you will find some process mapping in system development classes, it is limited. Workflow technology and business process definition are not covered in depth in IS required classes in most Universities. Workflow technology may be covered briefly in Groupware or Decision Support Systems electives. On the other hand, ERP systems are discussed in most IS required classes and many schools have a complete course devoted to ERP systems. Given the importance of workflow technology, especially in the Web services area, more attention to business process definition and workflow technology is needed in IS curriculums.

7 Conclusions

WfMSs and ERP systems have been aimed at both creating a strategic infrastructure for information management, and providing support for business processes, both administrative and operational. WfMSs and ERP systems are two distinct types of information systems that have been adopted to integrate information and processes across the functional areas of organizations. Both types of systems include specific characteristics; depending on an organization’s needs and

19

requirements, WfMSs or ERP systems, or both, can be selected and implemented to enhance process management.

Unfortunately, it seems that there is not a clear view of the main differences between WfMSs and ERP systems. The identification of those differences is important since they aid in the selection of the appropriate system for a particular set of requirements and needs. To ease this situation, we have outlined the main differences between the two types of systems in a concise and comprehensive way (see summary of differences in Table 1). While both systems focus on a similar problem, they solve it with different degrees of efficiency and in different ways. We have also outlined how these two systems might be integrated to better accomplish enterprise and inter-organizational process integration; in particular, their role in the Web services architecture.

8 References

1. Cardoso, J. and A. Sheth, Implementing QoS Management for Workflow Systems. Technical Report. LSDIS Lab, Department of Computer Science, University of Georgia, Athens, GA. 2002.

2. Stohr, E.A. and J.L. Zhao, Workflow Automation: Overview and Research Issues. Information Systems Frontiers, 2001. 3(3):281-196.

3. Zisman, M., Representation, Specification and Automation of Office Procedures. PhD Dissertation. Department of Business Administration, Wharton School, University of Pennsylvania, Philadelphia, PA. 1977.

4. Ellis, C.A. Information Control Nets: A Mathematical Model of Office Information Flow. in Conference on Simulation, Measurement and Modelling of Computer Systems. 1979, ACM, New York. pp. 225-239.

5. Ellis, C.A. and M. Bernal, OfficeTalk-D: An experimental office information system. SIGOA Newsletter, 1982. 3(1):131-140.

6. Hammer, M., The OA Mirage. Datamation, 1984. 30(2):36-46 7. Suchman, L. and E. Wynn, Procedures and Problems in the Office. Office: Technology

and People, 1984. 2(2):133-154. 8. Ellis, C.A. and G.J. Nutt. Workflow: The Process Spectrum. in NSF Workshop on

Workflow and Process Automation in Information Systems. 1996. Athens, Georgia. pp. 140-145.

9. Alonso, G. Advanced Transaction Models in Workflow Contexts. in Proceedings of the International Conference on Data Engineering. 1996. pp. 574-581.

10. Kochut, K.J., A.P. Sheth, and J.A. Miller, ORBWork: A CORBA-Based Fully Distributed, Scalable and Dynamic Workflow Enactment Service for METEOR. Large Scale Distributed Information Systems Lab, Department of Computer Science, University of Georgia, Athens, GA. 1999.

11. Jablonski, S. MOBILE: A Modular Workflow Model and Architecture. in Proceedings of the 4th International Working Conference on Dynamic Modelling and Information Systems. 1994. Noordwijkerhout, Netherlands.

12. Reichert, M. and P. Dadam, ADEPTflex - Supporting Dynamic Changes of Workflows Without Losing Control. Journal of Intelligent Information Systems - Special Issue on Workflow Managament, 1998. 10(2):93-129.

13. Mohan, C., et al., Exotica: A Research Perspective ob Workflow Management Systems. Data Engineering Bulletin, 1995. 18(1):19-26.

20

14. Wodtke, D., et al. The MENTOR Project: Steps Towards Enterprise-Wide Workflow Management. in Proceedings of the International Conference on Data Engineering. 1996. New Orleans.

15. IBM, MQSeries Workflow. http://www-3.ibm.com/software/ts/mqseries/workflow/. 2002. 16. Staffware, STAFFWARE. http://www.staffware.com/. 2002. 17. TIBCO, TIBCO InConcert. http://www.tibco.com/products/in_concert/. 2002. 18. COSA, COSA Workflow. http://www.ley.de/cosa/index.htm. 2002. 19. WARIA, Workflow and Reengineering International Association.

http://www.waria.com/. 2002. 20. WfMC, Workflow Management Coalition. http://www.wfmc.org/. 2002. 21. Lunn, T. and S.A. Neff, Material Requirements Plannning: Integrating Material

Requirement Planning and Modern Business. 1992: McGraw-Hill Professional Publishing.

22. Blumenthal, S.C., Management Information Systems: A Framework for Planning and Development. 1969, NJ: Prentice Hall.

23. Baan. Baan. http://www.baan.com. 2001. 24. CSC. Computer Sciences Corp. http://www.csc.com. 2001. 25. JDE. J.D. Edwards & Co. http://www.jdedwards.com. 2001. 26. Oracle. Oracle Corp. http://www.oracle.com. 2001. 27. PeopleSoft. PeopleSoft. http://www.peoplesoft.com. 2001. 28. SAP. SAP. http://www.sap.com. 2001. 29. TechRespublic, TechRespublic ERP supersite.

http://www.techrepublic.com/supersiterd.html. 2002. 30. Kappelman, L.A., Year 2000: A Reality Check. Communications of the AIS, 1999. 2(1). 31. Schuler, C., et al. Workflows over Workflows: Practical Experiences with the Integration

of SAP R/3 Business Workflows in WISE. in Enterprise-wide and Cross-enterprise Workflow Management: Concepts, Systems, Applications. 1999. Paderborn, Germany.

32. Muth, P., et al. Workflow history management in virtual enterprises using a light-weight workflow management system. in Proceedings of the 9th International Workshop on Research Issues in Data Engineering. 1999. Sydney, Australia, Available at http://www-dbs.cs.uni-sb.de/~mlite/. pp. 148-155.

33. METEOR, METEOR (Managing End-To-End OpeRations) Project Home Page. LSDIS Lab. http://lsdis.cs.uga.edu/proj/meteor/meteor.html. 2002.

34. Hall, D., et al., Using Workflow to Build an Information Management System for a Geographically Distributed Genome Sequence Initiative. Technical Report. LSDIS Lab, Department of Computer Science, University of Georgia, Athens, GA. 2000.

35. Anyanwu, K., et al., Healthcare Enterprise Process Development and Integration. Technical Report. LSDIS Lab, Department of Computer Science, University of Georgia, Athens, GA. 1999.

36. Luo, Z., Knowledge Sharing, Coordinated Exception Handling, and Intelligent Problem Solving to Support Cross-Organizational Business Processes. Ph.D. Dissertation. Department of Computer Science, University of Georgia, Athens, GA. pp. 171. 2000.

37. Georgakopoulos, D., M. Hornick, and A. Sheth, An Overview of Workflow Management: From Process Modeling to Infrastructure for Automation. Distributed and Parallel Databases, An International Journal, 1995. 3(2):119-153.

21

38. Kang, M.H., et al. A Multilevel Secure Workflow Management System. in Proceedings of the 11th Conference on Advanced Information Systems Engineering. 1999. Heidelberg, Germany, Springer. pp. 271-285.

39. CAPA, Course Approval Process Automation (CAPA). LSDIS Lab, Department of Computer Science, University of Georgia, Athens, GA. 1997.

40. Leymann, F. and D. Roller, Production Workflow: Concepts and Techniques. 2000, Upper Saddle River, New Jersey: Prentice-Hall.

41. Sheth, A.P., W.v.d. Aalst, and I.B. Arpinar, Processes Driving the Networked Economy. IEEE Concurrency, 1999. 7(3):18-31.

42. Kumar, K. and J.V. Hillegersberg, ERP Experiences and Evolution. Communications of the ACM, 2000. 43(4):23-26.

43. Iacovou, C.L., Managing MIS Project Failures: A Crisis Management Perspective. Ph.D. Dissertation. University of British Columbia, Vancouver, B.C., Canada. 1998.

44. Cardoso, J., Workflow Quality of Service and Semantic Workflow Composition. Ph.D. Dissertation. Department of Computer Science, University of Georgia, Athens, GA. 2002.

45. Jablonski, S. and C. Bussler, Workflow Management: Modeling Concepts, Architecture and Implementation. 1996: International Thomson Computer Press.

46. Schael, T., Information Systems in Public Administration: From Transaction Processing to Computer Supported Cooperative Work, in The Design of Computer Supported Cooperative Work and Groupware Systems, D. Shapiro, M. Tauber, and R. Traunmiiller, Editors. 1996, North-Holland: Amsterdam.

47. Rusinkiewicz, M. and A.P. Sheth, Specification and Execution of Transactional Workflows, in Modern Database Systems: The Object Model, Interoperability, and Beyond, W. Kim, Editor. 1994, Addison-Wesley.

48. Eder, J. and W. Liebhart. Workflow Recovery. in IFCIS Conference on Cooperative Information Systems. 1996. Brussels, Belgium. pp. 124-134.

49. Worah, D. and A.P. Sheth, Transactions in Transactional Workflows, in Advanced Transaction Models and Architectures, S. Jajodia and L. Kerschberg, Editors. 1997, Kluwer Kluwer Academic Publishers.

50. Hopkins, J. and M. Kessler, Companies Squander Billions on Tech. USA TODAY, 2002. 4(351):1A

51. Slater, D., Costly, Painful and Worth It. CIO Magazine, 2002. 15 January.http://www.cio.com/archive/011502/costly.html

52. SeeBeyond. SeeBeyond. http://www.seebeyond.com/ (see eBusiness integration demo for good overview of EAI type tools and applications). 2002.

53. Hagel, J. and J.S. Brown, Your Next IT Strategy. Harvard Business Review, 2001. 79(9):105-113.

54. SOAP, Simple Object Access Protocol. http://www.w3.org/TR/SOAP/. 2002. 55. Fensel, D. and C. Bussler, The Web Service Modeling Framework. Vrije Universiteit

Amsterdam (VU) and Oracle Corporation. http://www.cs.vu.nl/~dieter/ftp/paper/wsmf.pdf. 2002.

56. German Shegalov, Michael Gillmann, and G. Weikum, XML-enabled workflow management for e-services across heterogeneous platforms. The VLDB Joumal, 2001. 10:91-103.

57. Chen, Q., et al. Dynamic-Agents, Workflow and XML for E-Commerce Automation. in EC-Web. 2000. pp. 314-323.

22

58. Leymann, F., Web Services Flow Language (WSFL 1.0). IBM Corporation. http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf. 2001.

59. Leymann, F., D. Roller, and M.T. Schmidt, Web Services and Business Process Management. IBM Systems Journal, 2002. 41(2):198-211.

60. Snell, J., The Web services insider, Part 5: Getting into the flow: Business process modeling with WSFL. http://www-106.ibm.com/developerworks/webservices/library/ws-ref5/#h14177. 2001.

61. Thatte, S., XLANG: Web Services for Business Process Design. Microsoft, Inc. http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm. 2001.

62. Ankolekar, A., et al. DAML-S: Semantic Markup for Web Services. in Proceedings of the International Semantic Web Working Symposium (SWWS). 2001. pp. 39-54.

63. Vizard, M., Fear and loathing of Web services. InfoWorld, 2002. March 18:8 64. Scott, J.E. and I. Vessey, Managing Risks in Enterprise Systems Implementations.

Communications of the ACM, 2002. 45(4):74-81