You are on page 1of 23

The research register for this journal is available at The current issue and full text archive of this

this journal is available at


http://www.emeraldinsight.com/researchregisters http://www.emeraldinsight.com/1463-7154.htm

A generic structure for A generic


structure for
business process modeling BPM
Fu-Ren Lin, Meng-Chyn Yang and Yu-Hua Pai
Department of Information Management, 19
National Sun Yat-sen University, Kaohsiung, Taiwan, ROC
Keywords BPR, Modelling, Order processing
Abstract Among different BPR strategies and methodologies, one common feature is to
capture existing processes and represent new processes adequately. Business process modeling
plays a crucial role on such effort. This paper proposes a generic structure for modeling business
processes in order to capture essential concepts of business process and represent them
structurally. The generic structure possesses two main features suitable for business process
modeling: one is that it can represent a business process in various concerns and multiple layers
of abstraction, and the other is that it lowers the barriers between process representation and
model analysis by embedding verification and validation with the model. The generic modeling
method is illustrated by an order fulfillment process in supply chain networks.

1. Introduction
Business process reengineering (BPR) is a popular term since the 1990s,
especially after Hammer, Champy, and Davenport published books to elaborate
BPR related issues and cases (Hammer and Champy, 1993; Davenport, 1993).
Several companies and organizations report their successful experiences by
applying revolutionary approaches to obtain dramatic, radical, and
fundamental changes as Hammer and Champy (1993) suggested. However,
people rethought the myths of BPR after recognizing that 70 percent of BPRs
efforts failed (Davenport and Stoddard, 1994). One of these myths is that
business process redesign does not come from a clean slate to build new
processes from scratch. Generalized from various BPR methodologies as shown
in Table I, we identify one common task of these methodologies: to model the
existing and new business process (Davenport, 1993; Kettinger et al., 1995).
Notably, business processes modeling (BPM) is essential within a BPR life
cycle. The BPM within BPR mainly plays two important roles:
(1) to capture existing processes by structurally representing their activities
and related elements; and
(2) to represent new processes in order to evaluate their performance.
Besides the above two functions, a BPM method can possess the analysis
capability in facilitating process evaluation and alternative selection. To serve
these purposes, computer simulation is applicable due to the progress of
information technology.
BPM methods were emphasized on various perspectives by researchers and Business Process Management
practitioners during the last few years. It is confusing for users to select specific Journal, Vol. 8 No. 1, 2002, pp. 19-41.
# MCB UP Limited, 1463-7154
methods to fit in various domains. However, few research projects are DOI 10.1108/14637150210418610
BPMJ Methods Description Proposers
8,1
PADM (process The PADM consists of four phases which Wastell et al. (1996)
analysis and design intermingle and reciprocally interact.
methodology The four phases are (1) process definition;
(2) baseline process capture and representation;
(3) process evaluation; and (4) target process
20 design
PRLC (process The PRLC includes five stages: (1) envisioning Kettinger et al. (1995)
reengineering life process change; (2) inaugurating the
cycle) reengineering project; (3) diagnosing;
(4) (re)designing; and (5) (re)structuring
BPR framework The fundamental structure of the proposed Mayer et al. (1995)
BPR framework contains three elements:
(1) BPR principle; (2) BPR process; and
(3) BPR methods and tools
BPR stages A high-level approach to process innovation Davenport (1993)
consists of the five stages: (1) identifying
processes for innovation; (2) identifying change
levers; (3) developing process visions;
(4) understanding existing processes; and
(5) designing and prototyping the new process
BPR stages A stage-activity (S-A) framework for Kettinger et al. (1997)
Table I. reengineering was proposed, where BPR
Business process consists of six stages: (1) envision; (2) initiate;
reengineering (3) diagnose; (4) redesign; (5) reconstruct; and
methodologies (6) evaluate

dedicated to identifying differences among these methods and proposing


guidelines for better using these methods. Therefore, the first goal of this paper
is to compare various BPM methods in order to identify different emphases
among them and elicit generic features from these BPM methods. Second, we
attempt to develop a generic BPM method, which utilizes essential components
of process representation and incorporate other functions. Finally, an order
fulfillment process in supply chain networks is shown to demonstrate features
and capabilities of the generic BPM method.
We describe various BPM methods in the next section. A generic BPM
structure is proposed in section 3, and justification efforts are spent in section 4.
Section 5 concludes this paper.

2. Business process modeling methods


This section is aimed at introducing various BPM methods in the literature and
comparing them in different dimensions. These methods are listed and
discussed in the following subsections.

2.1 Reviews of business process modeling methods


A business process consists of five elements:
(1) a business process has its customers; A generic
(2) a business process is composed of activities; structure for
(3) these activities are aimed at creating value for customers; BPM
(4) activities are operated by actors which may be humans or machines; and
(5) a business process often involves several organizational units which are
responsible for a whole process (Davenport, 1993; Hammer and Champy, 21
1993).
Kueng et al. (1996) grouped process modeling approaches into four categories.
(1) Activity-oriented approaches tend to define a business process as a
specific ordering of activities (sometimes referred to as tasks). They
generally offer good support in refining process models. However, this
mechanistic view may fail to represent the true complexity of work and,
in turn, fail to implement new business processes.
(2) Object-oriented approaches are associated with object orientation, such
as encapsulation, inheritance, and specialization. The principles of
object orientation are applicable to business process modeling. However,
practitioners, such as process owners and team members, tend to
describe their work by activities rather than by objects.
(3) Role-oriented approaches suggest that a role be involved in a set of
activities, and carry out particular responsibilities (Ould, 1995). A group
of primitive activities can be assigned to a particular role (i.e. actor or
agent). However, they are not suitable to express an intricate sequencing
logic.
(4) Speech-act oriented approaches, based on speech act theory under
language/action perspective, view the communication process as four-
phased loop: proposal, agreement, performance, and satisfaction
(Medina-Mora et al., 1992). Although business cases can be viewed as a
communication between customers and performers, this modeling
approach does not provide much help in analyzing existing processes or
creating new processes.
From the comparisons of these BPM methods, we found that there would be a
large space to improve BPM methods. Efforts are needed to synthesize various
emphases in order to develop more viable approaches to capture existing
processes and design new target processes. A collection of BPM methods is
summarized in Table II by comparing their model components, representation,
main features, and modeling procedures. The selected BPM methods include
IDEF0, IDEF1, IDEF1X, IDEF3, RAD, REAL, Dynamic Modeling, Object-
Oriented Modeling (OO), AI and MAIS.
The IDEF0 is a function modeling method, designed to model the decisions,
actions and activities of an organization or system (Mayer et al., 1995). The
essential components of IDEF0 model are activities. Each activity is specified
8,1

22
BPMJ

methods
Table II.

process modelling
The list of business
Models Components Representation Main features Modeling procedure

1. IDEF0 Each activity is specified by A process is composed of ICOMs IDEF0 is a function modeling method
four elements: input, control, Hierarchical decomposition of activities
output and mechanism (ICOM) IDEF0 captures ``what organization does
2. IDEF1 Entity, entity class, relation, IDEF1 uses simple graphical IDEF1 is an information modeling method
relation class (similar to entity- convention (similar to ERD) to express: The information collected, stored and
relation diagram) (1) object; (2) physical or abstract managed by the enterprise
association maintained between The rules governing the management of
objects; (3) the information managed information
about objects; and (4) the data Logical relationships reflected in the
structure for representing information information
3. IDEFIX Four terms are involved in rule Using object-oriented representation IDEFIX is a business rule modeling method Model development
modeling: entity, message, to entities, attributes and their IDEFIX diagrams are refined into three refines the three
attribute and relationship relations levels of detail: (1) entity-relationship level; levels of detail
(2) key-based level; and (3) fully attributed from entity
level relationship to fully
Business rules are specified according to attributed level
different levels of detail
4. IDEF3 UOB (unit of behavior) is IDEF3 is a scenario-driven process Focuses on ``how things work in an
associated with elaboration and flow modeling method, which organization
decomposition supports two models: (1) process Facilitates modeling from multiple
UOBs are connected with flow description; and (2) object state perspectives and at multiple levels of
junctions and links transaction description abstraction
Elaboration specification: object, Enables both top-down and bottom-up
factor, constraint and description modeling
Supports both process-centered and
object-centered analysis
Represents temporal and logical
relationships
(continued)
Models Components Representation Main features Modeling procedure

5. RAD Processes are divided over Each role is represented as a Describe and define the roles work
roles separate shaded area Specifies the business role (how the
The process goals are States are represented as vertical process goes)
represented by states lines Process function
Activities Activities are shown as a black box Decision making
Interactions within a role Business scenario
Business rules Interactions are the horizontal line
joining roles
Business rules show up as the
pattern of sequencing, decision
making, and concurrent activity
that bind the above components
together

6. REAL Four components: REAL BPM concepts are Attempt to answer questions about each Identify business
Resource; independent from diagramming business event: events and
Event; technologies What happened and when? represent each with
Agent; and What roles were played and who/what a box
Location performed the roles? Identify the general
What kinds of resources were involved business rules
and how much was used? surrounding each
Where did the event occur? event by specifying
relationships
between each
event and its
related agents,
resources and
locations
Validate the REAL
model
(continued)

Table II.
A generic

23
structure for
BPM
8,1

24
BPMJ

Table II.
Models Components Representation Main features Modeling procedure

7. Dynamic Dynamic models Not mentioned A structured approach to analyze and Five steps in
modeling diagnose organizational problems using developing dynamic
dynamic models models:
Problem formulation
Problem
conceptualization
Model specification
Model checking
Solution finding
Solution
implementation
8. OO Four fundamental object classes: Represent four essential Use OOSA to identify the object in Iterative steps:
Output object classes perspectives: process Identify the output
Physiomorphic object classes Functional Apply the OOSA to business modeling class
Event object classes Behavioral Track backward or
Input object classes Organizational forward to events
Interactions between objects are Informational (from/to input to/
handled by means of message from output)
sending Refine the
inheritance structures
9. AI Social actors Strategic dependency model View processes as involving social Process analysis
Resource, task, goal and soft- Strategic rationale model actors who depend on one another for and design tools:
goal dependencies Analysis and design tools goals to be achieved, task to be Strategic
Resource, task, goal and soft- performed and resource to be furnished relationships analysis
goal dependencies and mean- Types of dependency: open, committed, Strategic relationship
ends and task-decomposition critical redesign
links Goal-based reasoning for process Qualitative reasoning
redesign for strategic rationale models support
Process verification
(continued)
Models Components Representation Main features Modeling procedure

10. MAIS Consists of four components: Types of agents: physical and An agent is an active object with unique Process modeling
Agent logical id. procedure
Task Links between agents: material and An agent is composed of action function, Model a business
Organization information flows learning mechanisms, states, database process according
Information infrastructure Swarm simulation framework to and knowledge base to the four
represent the MAIS Agents communiate through message components
passing according to their organizational Simulate and
boundaries evaluate the
process uding the
Swarm simulation
framework

Table II.
A generic

25
structure for
BPM
BPMJ by four elements: inputs, controls, outputs and mechanisms (ICOMs). In the
8,1 modeling procedure, it allows a hierarchical or top-down approach to analyze
processes at multiple levels of abstraction. It also focuses on functional
relationships to represent ``what things are performed within the process by its
ICOM based modeling diagram.
The IDEF1 modeling method is an information modeling method used to
26 identify:
. the information collected, stored and managed by the enterprise;
. the rules governing the management information;
. logical relationships within enterprise reflected in the information; and
. problems resulting from the lack of good information management
(Mayer et al., 1995). IDEF1 applies representations such as entity-
relation diagram (ERD) to achieve the above goals.
The IEEE IDEF1X is a semantic modeling standard for modeling business
rules, which involve four basic terms: entities, message, attributes, and
relationship. During modeling, IDEF1X diagram can be refined into three
different levels of detail:
(1) entity-relationship level which identifies entities and relationships
existing among entities;
(2) key-based level which resolves business rules using primary key of
entities; and
(3) fully attributed level using both primary and non-key attribute to
resolve rules (Appleton, 1995).
An IDEF3 process flow description captures a network of relations between
actions within the context of a specific scenario (Mayer et al., 1995). The basic
syntactic unit of IDEF3 graphical description is the unit of behavior (UOB)
represented by a box. Each UOB represents a specific view of the world in
terms of perceived state of affairs or state of change relative to the given
scenario. A UOB uses elaboration to describe its label, reference number,
objects, facts, constraints and description, as well as decomposition to
encapsulate other levels of UOBs. UOBs are connected to one another via
junctions, such as branch, join, AND, OR, XOR, and links. These junctions
represent temporal precedence, relational, and object flows. The role of IDEF3
as a BPM method can be summarized as follows:
(1) IDEF3 uses the scenario as the basic organizing structure to describe
how things work;
(2) it facilitates modeling from multiple perspectives and at multiple levels
of abstraction;
(3) it enables both top-down and bottom-up modeling sequences;
(4) it can support both process-centered and object-centered analysis; and
(5) it can represent temporal and logical relationships (Mayer et al., 1995). A generic
STRIM declares five key concepts of modeling business processes: structure for
(1) activities are divided among roles; BPM
(2) what an organization is trying to achieve with the process are the
process goals;
27
(3) activities are designed to achieve these goals;
(4) activities need people within the groups to interact collaboratively; and
(5) the organization operates or people cooperate according to the business
rules.
The heart of STRIM is the process modeling with role activity diagrams
(RADs). A RAD is composed of essential concepts, such as role, state, process
goal, activity, and interaction. The business rules are denoted as the pattern of
sequencing, concurrent activity, and action selection by combining these
essential concepts (Huckvale and Ould, 1995).
REAL, an acronym for resources, events, agents and locations, is developed
by Denna et al. (1994, 1995). REAL is aimed at answering the following
questions about a business event:
. What happened and when?
. What roles were played and who/what performed the roles?
. What kind of resources were involved and how much was used?
. Where did the event occur?
Although it provides specific steps in developing REAL model, it lacks
notations to present these four elements in the model.
Dynamic modeling is a structured approach to analyze and diagnose
organizational problems using dynamic models. A dynamic model of the
current situation is used to analyze the business processes, and afterwards, the
experimental outcomes with alternative solutions can be evaluated without
implementing them in the complex reality. A dynamic modeling approach
follows the following steps in developing dynamic models:
(1) problem formulation;
(2) problem conceptualization;
(3) model specification;
(4) model checking;
(5) solution finding; and
(6) solution implementation (van Meel et al., 1995).
An object-oriented process modeling (OO modeling) approach extended from
an object-oriented system analysis (OOA) model is proposed to analyze
existing business processes and assist their redesign (Wang, 1994). A system
BPMJ consists of four fundamental object classes, output, physiomorphic, event, and
8,1 input object classes. Besides possessing OOAs functional and informational
perspectives, the OO modeling method expands to include organizational and
behavioral dimensions. The systems dynamic behavioral properties are built
into the event classes.
An AI model, called i* framework (i* stands for distributed intentionality),
28 proposed by Yu and Mylopoulos (1996) is used to capture motivations, intents,
and rationales behind activities and entities. In the i* framework, a process
consists of social actors who depend on one another for goals to be achieved,
tasks to be performed, and resources to be used. The i* framework includes two
models:
(1) strategic dependency model, which represents the network of
relationship among actors in four types of dependency, goal, task,
resource, and soft-goal dependencies; and
(2) strategic rationale model, which describes and supports the reasoning of
relationship between actors by two types of links: means-ends and task
decomposition links.
ConGolog framework (for concurrent Golog), a declarative modeling language
for business processes, consists of tools for strategic relationship analysis,
redesign, qualitative reasoning support and process model verification and
validation.
Based on the multi-agent system (MAS) within the distributed artificial
intelligence (DAI) field, a multi-agent information system (MAIS) approach is
proposed to model the order fulfillment process (OFP) within supply chain
networks (SCNs) (Lin, 1996). A process is modeled by four components: agent,
task, organization and information infrastructure. An agent is defined as an
object with action and learning capabilities to receive input messages and
generate output messages to other agents. Through the information
infrastructure, agents communicate and coordinate with other agents to
perform tasks according to its organizational roles. The Swarm simulation
platform (Santa Fe Institute, 1996) is selected to implement the MAIS for
modeling the OFP processes and evaluating proposed BPR strategies. The
evaluation results of different OFP improvement strategies for various SCNs
demonstrate its capability in achieving agility of the OFP in SCNs.

2.2 Analysis of business process modeling methods


After decomposing BPM methods described in subsection 2.1, we identify
essential concepts in defining a business process. These essential concepts
include:
. activity, which is also named as task, function, or operation (used by
IDEF0, RAD, and MAIS);
. behavior, also called action, business rules, or control (used by IDEF1,
IDEF3, RAD, Dynamic Modeling, and MAIS);
.
resource, also called mechanism, or location (used by IDEF0, REAL, and AI); A generic
. relation, represented by relation class (IDEF1), junctions and links structure for
(IDEF3), interaction (RAD), dependencies, mean-ends and decomposition BPM
links (AI), object links (OO), or organization (MAIS);
. agent, also named as social actor, or role (used by RAD, REAL, AI, and
MAIS); 29
. information (IDEF1), represented by message (IDEF1X), message
sending (OO), or information infrastructure (MAIS);
.
entity (IDEF1X) or entity class (IDEF1), represented by attributes, or
object class (OO);
. event, represented as event objects (REAL, OO), or inputs/outputs
(IDEF0);
. verification and validation, using simulation (AI, MAIS) or dynamic
model (Dynamic modeling); and
.
modeling procedure proposed by IDEF1X, REAL, Dynamic Modeling,
OO, AI, and MAIS methods.
Curtis et al. (1992) propose four common perspectives in modeling business
process. In the functional perspective, a model represents what process
elements are performed. These process elements may consist of objects, data,
artifacts, or products. In the behavioral perspective, a model represents when
process elements are allocated (e.g. sequencing), and how related actions are
performed. In the organizational perspective, a model represents where and by
whom in the organization process elements are performed. In the informational
perspective, a model represents the informational entities produced by a
process, such as data, documents, etc. It includes the structure of information
entities and their relationships.
These four modeling perspectives cover the essence of business processes, such
as what, when, where and by whom the process elements are performed and how
related actions are executed. However, the model verification and validation and
the modeling procedure should be considered after reviewing various business
process modeling methods. Figure 1 lists the aforementioned BPM methods based
on the six modeling perspectives: functional, behavioral, organizational,
informational, verification and validation, and modeling procedure.

3. A generic business process modeling


After analyzing various BPM methods, we can view a business processes in the
six perspectives. Based on these six perspectives, we identify a set of essential
components for modeling business processes, and in turn, derive a generic
business process modeling method. First, we transform the qualitative estimate
of the BPM methods aforementioned into the quantitative measure based on
these six perspectives. A BPM method obtains five points for strongly
supporting certain perspectives, three points for a supported case, and one
BPMJ
8,1

30

Figure 1.
The comparison of BPM
methods under six
perspectives

point for a weakly supported case. Second, we sum up the total points each
component obtains according to its strength in supporting different
perspectives. The resulting points of a component denote its contributions to
represent different perspectives as shown in Figure 2. The results are
illustrated in Figure 3, and described as follows:

Figure 2.
The representation
strength of BPM
components under six
perspectives
A generic
structure for
BPM

31
Figure 3.
Essential concepts for
business processes

(1) Relation, behavior, and agent are main components needed in


representing the functional perspective. It can be interpreted as that: an
agent behaves itself to perform some activities according to its relation
with other agents.
(2) Behavior and relation are main components in forming the behavior
perspective. Behavior is represented by various elements such as business
rules, actions, etc. according to agents relations with their environments.
(3) Information and relation are main components in describing information
involved in business processes. Information elements, such as messages
and files, are processed and distributed on the information
infrastructure to facilitate business activities with various relations.
(4) Relation, agent and behavior are main components in denoting
organizational perspective. Organization consists of various agents
bound under certain relations. An agent behaves itself according to its
relative relationships with other agents within the organization.
(5) Those BPM methods with verification and validation are those
emphasizing behavior, agent and event components of a business process.
(6) Those BPM methods with modeling procedure commonly use such
components for process modeling as relation, behavior, resource, event,
information, and agent. The modeling procedure is necessary in designing
the sequence of forming and elaborating components of a target process.
From the above analysis and categorization, we obtain a generic structure for
business process modeling. The generic structure contains the listed ten
components covered by the six perspectives as shown in Figure 3. There are at
least two angles to view this generic process modeling method. One is to view it
as a meta-model to subsume existing and new BPM methods. We can identify
various competencies of different BPM methods in order to make the best use
of their strengths, and facilitate new BPM method development according to
these essential concepts and perspectives of business process modeling. The
other is to develop a generic BPM method, which demonstrates its generality.
This generic modeling method possesses several features suitable for business
BPMJ process modeling. For example, a business process can be represented in
8,1 separated concerns and multiple layers of abstraction, and analyzed by
embedding verification and validation with the BMP methods, which lower the
barriers between process representation and model analysis.

4. Modeling the OFP in SCNs using the generic modeling method


32 The generic process modeling approach with such properties as multiple layer
of abstraction and separation of concerns facilitates the business process
representation and analysis. They can be viewed as a grid, where y-axis
denotes multiple layer of abstraction, and x-axis represents separation of
concerns as shown in Figure 4. A target process can be represented by
composing eight essential concepts in different levels of detail ranging from
gross to fine-grained. A certain layer of abstraction may emphasize certain
perspectives. The multiple layer of abstraction removes the barriers of process
representation and model analysis by reusing and elaborating the details of
process elements. That is, efforts of transferring process representation for
model analysis are minimal. Therefore, the analysis including verification and
validation can be embedded with the model, and the modeling procedure can be
added to modeling activities. In order to illustrate such features, we apply this
modeling approach to the order fulfillment process in supply chain networks.
The order fulfillment process (OFP) starts from receiving orders from the
customers and ends with having the finished goods delivered. The OFP
involves the coordination of diverse activities such as sales commitment, credit
checking, manufacturing, logistics, accounts receivable, and relationships with
external suppliers from purchasing or shipping, which normally take place in
several different functional units across business entities in supply chain

Figure 4.
The generic BPM
method with multiple
layers of abstraction and
separation of concerns
networks (SCNs) (Davenport, 1993; Lin, 1996). The OFP in SCNs can be A generic
illustrated in Figure 5, where business entities have different functional units to structure for
support various activities for the OFP in the SCNs. The OFP in SCNs can be BPM
represented using the eight essential concepts of the generic modeling method
as shown in the following.
(1) Activity order management, production scheduling, capacity planning,
material planning, and supplier management. 33
(2) Resource materials, products, and orders.
(3) Behavior order committed decision (order management system),
coordination among production scheduling, capacity planning and
material planning (production scheduling, capacity planning, and
material planning systems), bidding and contracting (supplier
management system), and demand policy (business entities).
(4) Event order arrival, material available, and product finished.
(5) Information orders, production plan, bill of materials, capacity plan,
material requirement plan, and information infrastructure.
(6) Relation relative relationship between business entities by linking with
material and information flows or relation between entities.
(7) Agent logical agents for processing information, such as order
management, material requirement planning, capacity planning,
production scheduling systems, and physical agents for processing
materials, such as factory, production lines, and warehouse.
(8) Entity objects containing attributes, such as products and orders.
An activity denotes what a process does and an agent represents who performs
which actions and to whom the actions are rendered. Information denotes
messages an agent receives or sends in activities, and entities denote objects
being processed. Behavior demonstrates how an agent executes actions, and
events indicate when actions are executed. Agents are linked according to the

Figure 5.
The order fulfillment
process
BPMJ relation between each other to form organizations and utilize resources for the
8,1 target processes. Separation of concerns can be achieved by flexibly composing
different components to emphasize various perspectives among functional,
informational, organizational, and behavioral dimensions. For each concern, we
can represent and analyze under various layers of abstraction.
We elaborate the OFP in SCNs by the six perspectives in the following
34 paragraphs. In the organizational perspective, BPM methods usually elaborate
agent, relation, and behavior concepts. In describing the OFP in a SCN, the SCN
configuration can be represented in different degree of details according to the
organizational boundary. Figure 6 demonstrates multiple layer of abstraction
for SCNs in the organizational perspective. Entities within Circle A belong to an
enterprise, which can be viewed as an entity by its suppliers and customers
outside the enterprise but within the SCN. In a more detailed layer, supplier E
can be viewed as a set of entities composing the other SCN to supply materials
indicated by Circle B. The relations among business entities (viewed as agents)
can be represented by material flow links within and between organizational
boundaries. The OFP in SCNs is modeled by these main concepts in different
layers of detail as shown in Figure 7. In the supply chain network level,
suppliers, manufacturers, and retailers are agents which process materials and
information (orders) to facilitate the flow of materials and orders across the
network. In the enterprise level, the OFP requires the coordination among
manufacturing, assembling and distributing functional units within an
enterprise. For a functional unit, agents inside the unit perform the behaviors.
In the functional perspective, BPM methods usually elaborate agent,
relation, and behavior to describe activities within the process. Therefore, we

Figure 6.
The multiple layer of
abstraction of SCNs
A generic
structure for
BPM

35

Figure 7.
The multiple layer of
abstraction for the OFP
in SCNs

can view an activity in different degrees of detail by these concepts. For


example, the production activity in the OFP includes production planning and
execution sub-activities. Within each sub-activity, we can represent the related
tasks using main concepts as shown in Figure 8. We can further divide
production planning into five functions: order management, production
scheduling, material planning, capacity planning, and supplier management.

Figure 8.
Tasks of production
activity
BPMJ Production execution consists of shop floor control, production process,
8,1 inventory control, and packaging and shipping. Each function is represented
by possible inputs and outputs, which also indicate their relations and
embedded behaviors. Detailed function description can be elaborated by other
function representation methods, such as IPO, DFD, ICOM, etc.
In the informational perspective, we can illustrate information components
36 using various information system analysis methods, such as data flow diagram,
entity-relation diagram, object models, etc. One example is to utilize object-
oriented methods to represent information systems in four perspectives: problem
domain, human interaction, data management, and system interaction (Coad et
al., 1995; Norman, 1996). Objects within the dimension can be connected through
various links, such as generalization-specialization relation, whole-part relation,
and object connection. Message indicates the relations among components, and
objects achieve certain interaction by given scenarios. The Coads object-oriented
information system analysis and design method is aimed at mending two types of
gaps: one is between process model and data model, and the other is between
system analysis and design (Norman, 1996, p. 67). For example, an order
management object consists of object name, attributes and services as shown in
Figure 9. One of its services is to determine committed dates for incoming orders.
This service invokes functional modules across different objects through
messages denoted by dash lines with arrows. The invoked functional modules are
listed at the right of the Figure. The information system development can apply
these objects and their services during system analysis without major transitions.
In the behavior perspective, we focus on actions performed by each
individual agent and its influences emitted by agents as a whole. Therefore,
concepts, such as action, relation, and event, are the main elements in
describing an agents behavior. Technologies, such as decision rules, decision
tables, state-transition diagrams, etc. are applicable. In multiple layers of
abstraction, agents behavior can be refined to the lowest and detailed layer in
order to facilitate the process design or information system development. For

Figure 9.
Object-oriented
modeling in the
information perspective
example, a state-transition diagram (shown in Figure 10) can be used to A generic
represent the process of assigning committed dates to incoming orders. structure for
In the verification and validation perspectives, the generic BPM method can be BPM
easily embedded with simulation mechanisms, and conducted in multiple layer of
abstraction and separation of concerns. For example, Swarm is a multi-agent
simulation platform for the study of complex adaptive systems. A prototype of
the Swarm simulation system was developed at the Santa Fe Institute and aimed 37
to provide a general purpose simulation tool for building simulation models
(Santa Fe Institute, 1996). The features of Swarm can be summarized as follows:
. Swarm is a general-purpose simulator based on object-oriented framework
for simulating concurrent, distributed artificial worlds.
. Swarm uses the individual-based modeling approach. Individual-based
models allow an agent to have its internal state variables. An agents
past experiences determines its actions. The combination of individual
interactions determines the collective behavior of the whole group.
. In the Swarm system, an agent itself can be a swarm of agents. For
example, Swarm A is composed of a set of agents, {a1, a2, . . ., an}. An agent,
e.g. ak, itself is a swarm of agents called Swarm K (Swarm K = {k1, k2, . . .,
km}), where agent ak is the parent agent of agents in Swarm K. When child
agents (e.g. agents in Swarm K) receive messages from their parent swarms
scheduler (e.g. Swarm As scheduler), the behavior of that agent (e.g. ak ) is
the result of actions performed by the swarm of constituent child agents (e.g.
agents in Swarm K). This hierarchical inheritance, which can be a depth of
several layers, is called the nested inherent hierarchy property.
. Swarm supports nested hierarchy of schedules.
. Swarm uses the hybrid of both discrete event and time stepped
simulation schedules.
. Swarm provides the visualization capability.
Table III compares the properties of Swarm and supply chain networks, which
emphasizes the use of simulation system to simulate, verify, and validate the

Figure 10.
A state-transition
diagram to model order
committed date
determination behavior
BPMJ Supply chain networks Swarm simulation system
8,1
Composition of autonomous and semi- A swarm of agents with individual based
autonomous business entities modeling
Business entities act different organizational Agents are constructed with internal state
roles variables and action functions
38 Multiple layer abstraction Nested inherent hierarchy
Information flow between business entities Message passing between agents
Material flow during procurement, Discrete event simulation and time-stepped
manufacturing and distribution activities scheduling to trigger agent actions
In a SCN, the processes of individual entities In Swarm, the combination of individual
Table III. contribute to the global SCN performance behaviors determines the collective group
The properties of behavior
supply chain networks The visibility of a SCN is determine by the The boundaries of message passing determine
and Swarm information boundary the visibility

business processes in multiple layer of abstraction and separation of concerns.


Figure 11 demonstrates Swarms nested hierarchical inheritance to represent
agents in multiple levels of detail. The OFP Statistics Swarm is aimed at
analyzing the OFP performance executed by the Model Swarm in order to
verify and validate processes. The OFP Model Swarm consists of a set of
agents to represent the target processes.
The process modeling procedure should synthesize process representation,
analysis, and design tasks with the following efforts:
(1) Utilizing essential concepts, such as activities, resources, behavior,
event, information, relation, agent, and entity, to compose processes
under different perspectives.
(2) Embedded verification and validation mechanisms, such as simulation,
to analyze processes based on process goals and related parameters.
(3) Design or redesign processes according to the analysis results from the
existing processes, where intelligent agents can be added in facilitating
the new process design. For example, the development of the BPSLS
(Business Process Simulation and Learning System) utilizes
reinforcement learning agents with business process agents to design
new processes (Lin and Pai, 2000). The learning agent performs the
following four steps starting from receiving messages and ending with
sending out messages (see Figure 12):
. Step 1. The learning mechanism in an agent receives the message. The
message may come from its parent Swarm or other sibling agents.
. Step 2. The learning mechanism forwards the state and incoming
message to the Q-learning agent (Q-SwarmObj). The learning mechanism
works as a learning-task dispatcher and memorizes the learning
parameters and utilities returned from Q-SwarmObj.
A generic
structure for
BPM

39

Figure 11.
The implementation of
multiple-layer of
abstraction using
Swarms nested
hierarchical inheritance

. Step 3. The Q-learning agent (Q-SwarmObj) performs the reinforcement


learning task, and returns the action utilities.
. Step 4. The action function sends messages to other agents after
determining actions according to the action utilities.

5. Conclusions
Despite the fact that BPR methodologies advocate different BPR approaches and
stages, all of them share one common task; that is, to represent processes. In order
to represent processes, various modeling methods are proposed by many
researchers. However, to make the best use of these BPM methods, one would be
confused by their prolific terms and disappointed at their lack of complete support
for modeling activities. Therefore, in this article, we propose a generic structure
for modeling business processes in supporting the business process reengineering.
The proposed generic BPM method possesses such features as representing
business process in separation of concerns and multiple layers of abstraction,
and lowering the barriers between process representation and model analysis
by embedding verification and validation with the model. In order to elaborate
these features, we use an order fulfillment process in supply chain networks to
demonstrate how a generic BPM method works. An order fulfillment process
BPMJ
8,1

40

Figure 12.
Business process
simulation and learning
system (BPSLS)

can be represented by such essential concepts as activity, resource, behavior,


event, information, relation, agent, and entity. By emphasizing various
perspectives, the generic BPM modeling method can utilize different
representation schemas to formulate them as we describe in Section 4. The
barriers between process representation and analysis can be mended by
embedding simulation mechanisms with the model.
In summary, this research has two major contributions:
(1) synthesizing different business process modeling methods to design a
generic modeling method using essential concepts of process
representation; and
(2) illustrating the usage of the generic modeling method in supporting
business process modeling, analysis, and redesign.
However, analyzing the suitability of this generic BPM method on real world
processes can further enhance its applicability. In future research, we will
apply this generic BPM method to various domain processes in order to justify
further this method in different processes.
References
Appleton, D.S. (1995), ``Business reengineering with business rules, in Grover, V. and Ketinger, W.J.
(Eds), Business Process Change: Reengineering Concepts, Methods and Technologies, Idea
Group Publishing, London, pp. 291-329.
Coad, P., North, D. and Mayfield, M. (1995), Object Models: Strategies, Patterns and Applications,
Prentice-Hall, Englewood Cliffs, NJ.
Curtis, B., Kellner, M.I. and Over, J. (1992), ``Process modeling, Communication of the ACM, Vol. 35 A generic
No. 9, pp. 75-90.
Davenport, T.H. (1993), Process Innovation: Reengineering Work Through Information Technology,
structure for
Harvard Business School Press, Boston, MA. BPM
Davenport, T.H. and Stoddard, D.B. (1994), ``Reengineering: business change of mythic proportions,
MIS Quarterly, June, pp. 121-7.
Denna, E.L., Jasperson, J., Fong, K. and Middleman, D. (1994), ``Modeling conversion process
events, Journal of Information Systems, Vol. 8 No. 1, pp. 43-54. 41
Denna, E.L., Perry, L.T. and Jasperson, J. (1995), ``Reengineering and REAL business process
modeling, in Grover, V. and Kettinger, W.J. (Eds), Business Process Change: Reengineering
Concepts, Methods and Technologies, Idea Group Publishing, London, pp. 350-75.
Hammer, M. and Champy, J. (1993), Reengineering the Corporation: A Manifesto for Business
Revolution, Harper Business, New York, NY.
Huckvale, T. and Ould, M. (1995), ``Process modeling who, what and how: role activity
diagramming, in Grover, V. and Kettinger, W.J. (Eds), Business Process Change: Reengineering
Concepts, Methods and Technologies, Idea Group Publishing, London, pp. 330-49.
Kettinger, W.J., Guha, S. and Teng, J. (1995), ``The process reengineering life cycle methodology: a
case study, in Grover, V. and Kettinger, W.J. (Eds), Business Process Change: Reengineering
Concepts, Methods and Technologies, Idea Group Publishing, London, pp. 211-44.
Kettinger, W.J., Teng, J. and Guha, S. (1997), ``Business process change: a study of methodologies,
techniques and tools, MIS Quarterly, March, pp. 55-80.
Kueng, P., Kawalek, P. and Bichler, P. (1996), ``How to compose an object-oriented business
process model? in Brinkkemper, S. et al. (Eds), Method Engineering, Proceedings of the
IFIP WG8.1/WG8.2 Working Conference, Atlanta, GA.
Lin, F.-r. (1996), Reengineering the Order Fulfillment Process: A Multiagent Information System
Approach, Doctoral Dissertation, University of Illinois at Urbana-Champaign, Urbana, IL.
Mayer, R.J., Benjamin, P.C., Caraway, B.E. and Painter, M. (1995), ``A framework and a suite of
methods for business process reengineering, in Grover, V. and Kettinger, W.J. (Eds),
Business Process Change: Reengineering Concepts, Methods and Technologies, Idea Group
Publishing, London, pp. 245-90.
Medina-Mora, R., Winograd, T., Flores, R. and Flores, F. (1992), ``The action workflow approach
to workflow management technology, Proceedings of the Conference on Computer-
Supported Cooperative Work, CSCW92, Toronto, pp. 281-8.
Norman, R.J. (1996), Object-Oriented System Analysis and Design, Prentice-Hall, Inc., Englewood
Cliffs, NJ.
Ould, M.A. (1995), Business Processes: Modeling and Analysis for Re-engineering and
Improvement, Wiley, Chichester and New York, NY.
Santa Fe Institute (1996), Swarm Web Page, available http://www.swarm.org/.
van Meel, J.W., Bots, P.W.G. and Sol, H.G. (1995), ``Lessons learned from business engineering
within Amsterdam Municipal Police Force: the applicability of dynamic modeling, in
Grover, V. and Kettinger, W.J. (Eds), Business Process Change: Reengineering Concepts,
Methods and Technologies, Idea Group Publishing, London, pp. 402-23.
Wang, S. (1994), ``OO modeling of business processes, Information System Management, Spring,
pp. 36-43.
Wastell, D.G., White, P. and Kawalek, P. (1996), ``A methodology for business process redesign:
experiences and issues, Technical Report, Information Process Group, Department of
Computer Science, University of Manchester, Manchester.
Yu, E. and Mylopoulos, J. (1996), ``AI modeling for business process reengineering, IEEE Expert,
August, pp. 16-23.