An Introduction to Workflow and Business
by M. C. Tanuan
This paper provides an introduction to building Workflow applications for business
information systems using the business process modeling approach.
The first part introduces the concept of a business process using a simple example:
Telephone Service Process in which a telephone company receives a request for a
new phone from a customer and results to the activation of a new phone and the
service is automatically billed. A business process model can be used as an input to
determine the specific requirements of the information systems. The CSC Catalyst®
BPM Notation will be used for describing the business process.
The second part of the paper introduces the concepts of Workflow as a means to
automate the business process model. Building information systems to support
business processes requires the four basic concepts of workflow, namely, Process
Logic, Match-making People and Tasks, Providing Information Resources for
Tasks, and Process Management. Detailed process definition specification is
presented through the use of the Telephone Service Process example.
The purpose of this paper is as follows:
to understand how to use business processes to define requirements for software
to describe a basic set of business process modeling (BPM) concepts and
to describe a basic set of Workflow concepts to specify business process
This paper will not discuss the merits of various re-engineering approaches to business
processes. It will not discuss the distinction between Business Process Re-engineering
(BPR, which is characterized by immediate and dramatic change) and Business Process
Improvement (BPI, which is characterized by gradual and incremental change).
BPR and BPI encompass a whole range of techniques. Modeling techniques for BPR can
involve workflow analysis, simulation, value chain analysis, critical path analysis and
performance measurement. On the other hand, organizational change techniques are
characterized by approaches to managing resistance to change, team building,
performance measurement and incentive compensation.
This paper will focus on the process concepts and modeling techniques to provide the
basis for workflow analysis. It will demonstrate how the business process models are
linked to the workflow analysis of process definition.
What is a business process?
If you have ever encountered delays with your application for a new telephone service
(i.e., activate your phone line to your new apartment or home at a specific date), you can
appreciate the need for process improvement. In this case the "process" is called the
requesting a new telephone service process, and the purpose of the process is to activate
your phone line, perform on-site service (if appropriate) and bill the services you
requested. The process begins with you (as a customer) requesting a new telephone
service and ends with you receiving the phone service bill.
The process steps are the activities that you and the telephone company personnel need to
complete the transaction. In this simple example, we have described a business process.
Hammer and Champy defines a business process as "a collection of activities that takes
one or more kinds of input and creates an output that is of value to the customer." A
business process is not the same as a business function. A process may be contained
within a departmental function; for example Forecast Customer Consumption. However,
a lot of meaningful business processes cuts across departmental functions and
boundaries; for example Request New Telephone Service spans Customer Service,
Technical Services, Credit Control and Invoicing.
An Example: Telephone Service Process
The process begins when a customer calls a service representative to order telephone
service. The service representative takes all the details of the order and initiates the
The customer may have all the physical requirements for the telephone service (i.e.,
phone lines to the property, phone jacks in desired locations, etc.). If so, the service
representative schedules a time to have the customer’s phone line activated. The
customer may opt to have same day service, or to have the phone line turned on at an
agreed upon future date.
If physical work at the customer’s site is required, the service representative can also
order a visit to the customer site by a technician. The service representative can order
activation of a new phone line, or an onsite visit, or both.
Note that a phone line can be activated before or after an onsite visit is performed. Should
both phone activation and onsite work be required, the application allows the two
activities to proceed independently of one another.
In this scenario, perform onsite service is a sub-process which includes the following
activities: schedule onsite visit, perform onsite visit, allocate resources (if onsite visit
cannot be performed by the assigned technician), and handle delay (if onsite visit is not
performed on schedule).
For simplicity, only the Phone Service Process will be discussed in detail.
Figure 1: A business process example: New Telephone Service
Figure 1 shows the process definition of New Telephone Service process. For simplicity,
the Process Hierarchy Diagram concepts (which models the whole enterprise) are not
discussed in this paper. For consistency, the terms business process and process definition
(instead of elementary business process and process thread, respectively) will be used in
Why re-engineer a business process?
Re-engineering assumes that the current business process is wrong or irrelevant. It means
that the current business process has a lot of activities that does not add value to the
customer. Re-engineering requires fundamental rethinking to challenge tradition by
asking the question: why? (e.g., Why does the service technician have to work in the
morning, i.e., from 8 a.m. to 5 p.m.?); it also requires a radical redesign by assuming that
there are no business and technical constraints (e.g., existing organization unit have
limited skills and knowledge and existing legacy system is running in a vendor-specific
computer, etc.); it expects dramatic improvement in orders of magnitude (i.e., 200%
improvement and not 20%). The key principles of BPR are summarized in Figure 2.
BPR is enabled by the dramatic improvements in information technology. New
technologies such as workflow management systems are rapidly bringing new
capabilities to businesses, thereby raising the competitive standards and the need to
improve business process dramatically.
Figure 2: Key Business Process Reengineering Principles
Improving (or re-engineering) business processes is an imperative for businesses to stay
competitive in today’s marketplace. For the past decade, companies have been forced to
improve their business processes because customers are expecting low-priced
products/services which are more specialized to their needs. If customers do not receive
what they want, they have many others to choose from (hence the competitive issue of
businesses). On the other hand, businesses are also forced to improve business processes
because of the surplus of goods and services which results to pressure on prices. For the
past decades, most companies have already improved the productivity in the
manufacturing process. The productivity in offices is the next area of opportunity for
businesses to stay competitive.
BPR, if implemented correctly, often results to flat organization structures through the
use of empowered process teams, removal of redundant activities and improved customer
What is a process definition?
Business Process Modeling (BPM) defines how the activities of a business process inter-
connect. The result of BPM is the process definition.
The Workflow Handbook defines a process definition as "the representation of a business
process in a form which supports automated manipulation, such as modeling, or
enactment by a workflow management system. The process definition consists of a
network of activities and their relationships, criteria to indicate the start and termination
of the process, and information about the individual activities, such as the participants,
associated IT applications and data, etc."
Figure 3 shows the relationships among basic terminology that relates to Business
Process. Note that the Business Process is defined in a Process Definition and Business
Process is managed by a Workflow Management System.
Figure 3: Relationships among basic terminology
A Process definition is composed of activities and sub-processes. Sub-processes will be
defined in the later sections. An activity can be manual (i.e., requires human intervention
such as perform onsite service) or automated (does not need human intervention such as
To automate the business process, a workflow management system (WFMS) is used.
WFMS uses the process definition to create process instances which includes one or more
activity instances. Each activity instance can have work items, invoked applications, or
both. A discussion of WFMS will be made in the Four Basic Workflow Concepts section.
By defining the process definition, process improvement can be made by eliminating
duplicate activities, introducing parallel activities and eliminating unnecessary movement
of work. In the more extreme case of BPR, the process can be totally reorganized such
that multiple activities are combined into one activity enabled by leading edge technology
(i.e., shared databases, expert systems, decision support systems, telecommunication
networks, wireless data communication and portable computers and workflow
For example the four different activities of Telephone Service Process can be rationalized
into a single process-based function Provide Customer Service. This "re-engineered"
process assigns all activities (except perform on-site service, if required) to the Service
Functional to Process Orientation
Based on the key BPR principles discussed above, we now have to rethink the way work
is done within a business. The hierarchical structuring of organizations into functional
units and sub-units has historically been the main focus of organizing businesses. Each
unit in each level which has a defined function within a company, is responsible for this
function and has directly assigned resources for accomplishing it.
One effect of this is that people belonging to one unit start thinking in a narrow way
concerning only their own functions. They no longer have the company as a whole in
mind and therefore build organizational barriers between them and other units. This leads
to a lack of communication between units and people, slower working and more intensive
administration. Adding more people and resources to units in order to make them more
efficient has exactly the reverse effect. This approach to building software application,
which was popular in the 70s and 80s is known as functional orientation.
Functional orientation builds software applications based on functional decomposition.
Functional applications are built to satisfy each departmental function and then interfaced
to other function applications. Figure 4 shows a sample suite of software application
based on functional orientation. The effect is little or no reuse of functional applications
across departmental boundaries.
Figure 4: Functional Applications
We have discussed that functional orientation can slow down work and adds
organizational barriers which are non-value-added activities for the customer.
Automating each function does not solve this problem.
Process Orientation is a means to solve this problem. Instead of asking "what are the
departmental functions? and how can we make each function more efficient?", we now
ask "what are the key business processes? and how can we improve the process?".
Business processes are used to define the flow of work, typically across organizational
boundaries, in order to add value for the customer (i.e., to meet business goals). Process-
based applications automates the process definition and uses (or re-use) workflow
enabled applications to accomplish activities of each process instance. Figure 5 shows
how a process based application is structured to meet business requirements.
Process orientation also means that people from various units work together for a specific
business process assigned to them. This is called the process team.
Figure 5: Process-based Applications
Business Processes operate "horizontally" through a company in contrast to the vertical
division of labor upon which traditional function decomposition approaches to business
analysis are based. Each activity along the process definition leaves the system in a
consistent state (e.g., enter an order and not "insert button is pressed") which adds value
to the business process. The flow of work is described explicitly by the process definition
in which each activity describes what information is to be used by whom. The process
definition will be used in the development of IT applications.
Figure 6 shows the relationship between a business process and the organization units
assigned for each activity. It shows that the activity Enter Order and Activate Line is
assigned to Customer Service Department, Onsite Service is assigned to Service and
Repair Department, and Generate Statement is assigned to Sales and Billing Department.
Figure 6: Relationship of Business Process and Organizational Units
How to specify a business process
Defining a business process involves identifying external business events and primary
results. Each business process is analyzed as a chain of activity for each pair of triggering
events and results.
A business process often involves multiple users and activities that take place over a
period of time. Not only do we need to examine the activities in which inputs are
converted into outputs, we need to be able to identify the correct activities in the first
place. A common approach is to attempt some form of functional decomposition, by
asking what are the system functions of each department and breaking these functions
down to a level where it can be coded (i.e., subprogram definition). This approach is not
helpful because not all the functions within the department is required to satisfy a specific
business process. Business processes therefore, is appropriately modeled using event-
Event-driven approaches to identify activities of a business process recognizes the fact
that identifying the correct activities has to be done "outside-in" (event-driven /
horizontal) rather than "top-down" (functional decomposition / hierarchical). Event-
driven approaches naturally considers passage of time as an important event in the model.
This means that event sequences can be modeled based on the business process
A business process consists of groups of activities performed in response to a set of
related business events. Business Processes are value chains (i.e., generates work that is
of value to the customer) of a business. Process Definitions are used to model the flow of
activities, initiated by a single business event. Flow of activities are controlled by
sequence dependency, iteration, concurrence and process breaks. A result from one
process definition may be a business event relative to another process definition. An
example would be the result of the Telephone Service Process (i.e., new phone request
activated and billed) is used for another process: Credit and Collection Process.
A business event is a stimulus which triggers an activity. In our Telephone Service
Process example, the activity "Enter Order" is triggered by business event "Customer
Business events may be input or output-driven. Input-driven business events are signaled
by the arrival of an input information flow; they can be external or internal; for example
Customer Calls In (external) or Clerk request Onsite Service (internal). Output-driven
business events may be temporal or conditional. Temporal events are signaled by the
arrival of a predefined point in time (e.g., Time to Activate Telephone Line). Conditional
events report the sensing of a particular circumstance which triggers another activity
(e.g., Credit limit exceeded).
In sum, business processes can be thought of as a family of activities which together
collaborate in different event driven groups to fulfill the business goals. These groups of
activities are decomposed by events that denote essential constraints imposed by the
business, not by technology. This allows us to identify activities that can be used on
different process definitions.
The dependencies (i.e., transitions) between activities are subjected to pre-conditions and
post-conditions. Pre-condition must evaluate to "true" to start the activity. On the other
hand, the post condition must evaluate to "true" before the activity can be completed.
Preconditions and post-conditions are important because they will help to govern the
behavior of required services (i.e., application components), when we model our system
interface (i.e., use cases).
When (at what level) do we stop business process decomposition?
Since there is no criteria for establishing a bottom level process component, the process
analyst/designer is faced with the problem of when to stop business process
decomposition (i.e., at what level should activity decomposition stop). One rule of thumb
is to specify the activities such that a task is performed by one person in one place at one
time, and which adds measurable business value and leaves the data in a consistent state.
Multiple levels of sub-process may be supported. A sub-process is useful for defining
reusable components within other processes. A sub-process will have its own process
A sub-process can be defined by creating another process definition (such as Onsite
Service Process) that can be called by another (initiating) process. Figure 7 shows a
sample Onsite Service sub-process which includes Schedule Visit and Onsite Service
Figure 7: Onsite Service Process
Strengthening the Process Definition
The Onsite Service Process defined in Figure 7 will be accurately followed if all
scheduled onsite visits have successful onsite service conducted by the technician
originally assigned. As soon as the technician cannot conduct a successful onsite service,
the process definition says nothing about what happens next.
To make the definition more robust, an optional dependency ("on abort" condition) is
introduced. This is shown in Figure 8 as a conditional transition from Perform Onsite
activity to Allocate Resource activity. A new Schedule Onsite activity has to be created
because the activity needs to distinguish between the schedule onsite for the first time and
the succeeding time. In the actual implementation, however, they may use the same
application component with different parameters (to distinguish first and succeeding
schedule). This is the concept of task generalization which allows different activities to
re-use the same application component.
Figure 8: More Robust Onsite Service Process
To add more robustness to the Onsite Service Process, a timer can be set once the
Perform Onsite activity has started; for example, the timer can be set for two business
days. If the Perform Onsite activity is completed before the timer expires (in two business
days), the timer is reset and the process ends. If the timer expires and the Perform Onsite
activity is not yet completed, a new activity such as Handle Delay activity will be
initiated (i.e., this will actually show up as a work list item for the supervisor). This
process of checking and reporting exceptions is called escalation. . The timer (two
business days) and Handle Delay activity are not shown on the diagram to limit
complexity; though they could be shown if required.
BPR and Workflow
BPR proposes the obliteration of existing work processes and the establishment of new
business methods based on new sets of assumptions regarding desired business
Workflow is the analysis, compression, and automation of information-based process
models that make up a business.
With this definition, workflow provides the metrics for reengineering. It can measure
which business processes and information systems are less efficient in order to pinpoint
the opportunities for reengineering. Therefore, workflow can be used for non-radical
Four Basic Workflow Concepts
With many competing workflow products today, it is important to understand the key
Workflow concepts which are as follows:
A workflow management system (WFMS) provides computer-based support for business
process logic. Using a WFMS, a business can both enforce and document the business
rules it uses.
WFMS controls the flow of business processes by:
representing the definition of each process
keeping track of the state of each instance of the process as it progresses through
its defined task stages
pushing the process along to the next task that needs to be performed, according
to the logic that is defined in the process
In our Phone Service Process example, all the activities and dependencies can be defined
using a WFMS. Creation of process instances and tracking the state of the process and
activity instances is also done by the WFMS.
Match-Making Between People and Tasks
WFMS take responsibility for ensuring that the tasks that need to be done are matched up
with the resources needed to perform them. When a task needs a person in order to be
completed, the WFMS will support the necessary match-making between people and
In our Phone Service example, Enter Order can be matched with users that have Service
Representative roles. Activate Line and Generate Statement activities can be done
automatically (i.e., assign an application service component to complete the task).
Providing Information Resources for Tasks
Tasks may require both human resources and information resources. When these
information resources are computer based, WFMS can make sure that the tasks which
needs to be done are matched up with the information resources that are needed to
complete the task.
In our Phone Service Process example, we can expect the WFMS to provide the customer
information to the generate statement application (instead of re-keying this information).
Process management is a key concept in WFMS; organizations are under constant
pressure to make better use of resources.
WFMS can be used to manage and control business processes. WFMS helps process
Making process logic explicit, discrete layer of design representation, which can
be reasoned about independently and , within limits, altered independently.
Allowing designers to create, collect and evaluate metrics relating to the time,
cost or quality of performing a process and its constituent tasks, thus enabling
intelligent improvements to be made to process design.
Business Processes and Object Orientation
BPM usually arises from a compelling business need or opportunity. Often this will
require software solutions to be rapidly developed or assembled. Information collected
from BPM must therefore be usable in systems analysis and design, and software
development, with as little translation or rework as possible.
Consistent with the methodology, objects are viewed as service providers to business
processes. The analysis in terms of business activities gives the starting point for
identifying system use cases. System use cases are essentially the ways in which actors
are going to use the proposed system. Activities that require an invoked application can
be described in more detail using Use Cases.
On the other hand, completion of each activity can be used to develop a conceptual
dynamic model for the key transactions modeled by the system. In Figure 9, the Order
Dynamic Model (or Life Cycle) can be modeled using a State Transition Diagram.
Therefore, business process models can be readily used as an input document to do object
Figure 9: Business Processes and Object Orientation
This paper introduced business process modeling (BPM) as an approach to defining
information systems requirements. It also illustrates the difference between functional
approach and process-based approach in specifying requirements. Based on the
Telephone Service example, we have demonstrated how business processes can be
described using an event-driven approach.
Workflow management systems (WFMS) is considered a new class of generic software
like database management systems. This paper gives an overview of the basic workflow
concepts to understand and appreciate the variety of WFMS available in the market
today. Finally, the link between business process models and object-oriented analysis is
summarized in the last section.
The field of business process modeling and workflow is continuously changing and
growing. Therefore, it is important to read and study the latest tools and techniques
available in the market today.
Business Process Modeling Notation
Notation Set: We will use a notation set for our business process models based upon, summarized below.
Figure 1: Business Process Modeling Notation Set
Business process modeling (BPM) creates two types of diagrams: process hierarchy diagrams and process
thread diagrams. The diagrams are produced both for the current "As Is" and the proposed "To Be" models.
The Process Hierarchy Diagram is used to capture and graphically display the relationship between the
levels of process granularity. At the very top sits the enterprise (or part of the enterprise) under study. This
is divided into a number of key business processes consisting of process groups. Process groups may be
nested as necessary, depending on size and complexity of the business under study. A process group
consists of a number of Elementary Business Processes (EBPs) and other process groups. EBPs can be re-
used both within and across different process threads. An elementary business process can optionally be
broken down into business steps.
Figure 2: Process Hierarchy Concepts
Process Thread Diagrams are used to capture and graphically display dependencies among chains of
EBPs driven by initiating business events and producing results of business value within process groups. A
process thread can include both EBPs and other process groups. The process groups can be decomposed
into other process groups and/or elementary business processes. A result produced by one process thread
can be a triggering event relative to another process thread. An activity could be common to more than one
process thread; it could also be used more than once in the same thread.
Figure 3: A Process Thread in Context
Forte Software, Inc., Using Forte Conductor 1.0 Training Manual, 1997
Hammer, M. and Champy, J., Reengineering the Corporation: A Manifesto for Business
Revolution, Harper Collins, New York, 1993
SELECT Software Tools, Inc., Process Mentor 5.1.4 (a computer based tutorial), 1997
Lawrence, Peter (editor), Workflow Handbook 1997, John Wiley and Sons Ltd., 1997