Workflow Management Systems vs. ERP Systems: Differences ...Document Transcript
Workflow Management Systems vs. ERP Systems:
Differences, Commonalities, and Applications
Jorge Cardoso1, Robert P. Bostrom2 and Amit Sheth1
1 LSDIS Lab, Computer Science Department
University of Georgia
Athens, GA, USA, 30602
Terry College of Business
University of Georgia,
Athens, GA, USA, 30602
Contact information: Amit Sheth
LSDIS Lab, Computer Science Department
University of Georgia, USA
Tel:(706) 542-2310, Fax: 2966
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.
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 ERP System
¤¥ §§ ¦¦ Parameter based
Workflow Model (embedded workflow Application
Human Resources Data
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.
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
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
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.
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
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 .
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 Maturity
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 . The first OIS prototypes were developed in the late seventies. Pioneer
systems included the SCOOP project , 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
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 .
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.  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 , MOBILE , ADEPT , Exotica , and MENTOR
; commercial products include MQSeries Workflow , Staffware , TIBCO InConcert
, and COSA Workflow . General information on WfMSs can be found at the Workflow
and Reengineering International Association  and the Workflow Management Coalition 
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) . 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 . 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 , CSC , JD Edwards , Oracle , PeopleSoft , and
SAP . General information on ERP systems can be found at the TechRepublic Web site .
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
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 , 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.
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 Embedded processes
Domain independence Domain specific (use of reference
Ad-hoc and dynamic domains Static domains
No international settings International settings
Technological Process-centric Data-centric
Scope Supports workflows involving Transactional processes
humans, IT applications, and
Heterogeneous and autonomous Homogeneous environments with
environments common data infrastructures
System Acquired as ready systems; Code Based on pre-written “off-the-
Implementation automatically generated shelf ” components
Bottom-up approach Top-down approach
May require data conversions 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
Workflow systems have been installed and deployed successfully in a wide spectrum of
organizations. Muth et al.  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 )
can be deployed to various domains, such as bio-informatics applications , healthcare ,
the telecommunication industry [36, 37], the military , and administrative processes for
school administration . Leymann and Roller  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,
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.  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 
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 (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.
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
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 . 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. . WfMSs technology focuses its attention and
effort on supporting three different types of applications :
(1) Workflows involving humans (our second example above),
(2) Workflows involving systems and applications (examples provided in the integration
(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
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
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 , Georgakopoulos et al. , Eder and
Liebhart , Alonso et al. , and Worah and Sheth .
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
) 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
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 .
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-written 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  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 . 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
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.
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 :
(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
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  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  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 . 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
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 Enterprise Integration
We are starting to see work that focuses on integrating WfMSs and ERP systems , 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 
and ERP applications [2, 49]. This capability allows WfMSs to provide an important enterprise
In the practitioner literature, the systems to develop this type of workflow applications are
referred to as “Enterprise Application Integration” (EAI) tools . 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 .
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
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 . 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 . 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.
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 . 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 , 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 . 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
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.
 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
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 .
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 . 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
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 . The WSFL enables developers to easily, create, combine, and execute Web services
for complex processes and workflows (see example in Snell ). Other proposals have been
created by Microsoft, with XLANG , and by DAML , with DAML-S. IBM and other
vendors are pushing for flow language standards that can be implemented by a variety of
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 . 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-
of-breed applications integrated using Web services . 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  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 ). 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  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.
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
requirements, WfMSs or ERP systems, or both, can be selected and implemented to enhance
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.
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.
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.
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.
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
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.
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.
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.
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.
51. Slater, D., Costly, Painful and Worth It. CIO Magazine, 2002. 15
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.
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.
56. German Shegalov, Michael Gillmann, and G. Weikum, XML-enabled workflow
management for e-services across heterogeneous platforms. The VLDB Joumal, 2001.
57. Chen, Q., et al. Dynamic-Agents, Workflow and XML for E-Commerce Automation. in
EC-Web. 2000. pp. 314-323.
58. Leymann, F., Web Services Flow Language (WSFL 1.0). IBM Corporation. http://www-
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-
61. Thatte, S., XLANG: Web Services for Business Process Design. Microsoft, Inc.
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