The research register for this journal is available at http://www.emeraldinsight.

com/researchregisters

The current issue and full text archive of this journal is available at http://www.emeraldinsight.com/1463-7154.htm

A generic structure for business process modeling

Fu-Ren Lin, Meng-Chyn Yang and Yu-Hua Pai
Department of Information Management, 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.

A generic structure for BPM 19

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 practitioners during the last few years. It is confusing for users to select specific methods to fit in various domains. However, few research projects are

Business Process Management Journal, Vol. 8 No. 1, 2002, pp. 19-41. # MCB UP Limited, 1463-7154 DOI 10.1108/14637150210418610

BPMJ 8,1

Methods

Description

Proposers Wastell et al. (1996)

20

Table I. Business process reengineering methodologies

PADM (process The PADM consists of four phases which 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 design PRLC (process The PRLC includes five stages: (1) envisioning 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 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 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 reengineering was proposed, where BPR consists of six stages: (1) envision; (2) initiate; (3) diagnose; (4) redesign; (5) reconstruct; and (6) evaluate

Kettinger et al. (1995)

Mayer et al. (1995)

Davenport (1993)

Kettinger et al. (1997)

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; (2) a business process is composed of activities; (3) these activities are aimed at creating value for customers; (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, 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 fourphased 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, ObjectOriented 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

A generic structure for BPM 21

22

BPMJ 8,1

Models A process is composed of ICOMs IDEF0 is a function modeling method Hierarchical decomposition of activities IDEF0 captures ``what organization does IDEF1 is an information modeling method The information collected, stored and managed by the enterprise The rules governing the management of information Logical relationships reflected in the information

1. IDEF0

2. IDEF1

3. IDEFIX Four terms are involved in rule Using object-oriented representation IDEFIX is a business rule modeling method modeling: entity, message, to entities, attributes and their IDEFIX diagrams are refined into three attribute and relationship relations levels of detail: (1) entity-relationship level; (2) key-based level; and (3) fully attributed level Business rules are specified according to different levels of detail Focuses on ``how things work in an organization Facilitates modeling from multiple perspectives and at multiple levels of abstraction Enables both top-down and bottom-up modeling Supports both process-centered and object-centered analysis Represents temporal and logical relationships

4. IDEF3

Table II. The list of business process modelling methods Representation Main features Modeling procedure IDEF1 uses simple graphical convention (similar to ERD) to express: (1) object; (2) physical or abstract association maintained between objects; (3) the information managed about objects; and (4) the data structure for representing information Model development refines the three levels of detail from entity relationship to fully attributed level (continued)

Components

Each activity is specified by four elements: input, control, output and mechanism (ICOM)

Entity, entity class, relation, relation class (similar to entityrelation diagram)

UOB (unit of behavior) is IDEF3 is a scenario-driven process associated with elaboration and flow modeling method, which decomposition supports two models: (1) process UOBs are connected with flow description; and (2) object state junctions and links transaction description Elaboration specification: object, factor, constraint and description

Models Each role is represented as a separate shaded area States are represented as vertical lines Activities are shown as a black box within a role 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 REAL BPM concepts are independent from diagramming technologies Attempt to answer questions about each business event: What happened and when? What roles were played and who/what performed the roles? What kinds of resources were involved and how much was used? Where did the event occur? Identify business events and represent each with a box Identify the general business rules surrounding each event by specifying relationships between each event and its related agents, resources and locations Validate the REAL model (continued) Describe and define the roles work Specifies the business role (how the process goes) Process function Decision making Business scenario

Components

Representation

Main features

Modeling procedure

5. RAD

Processes are divided over roles The process goals are represented by states Activities Interactions Business rules

6. REAL

Four components: Resource; Event; Agent; and Location

A generic structure for BPM

Table II.

23

24

BPMJ 8,1

Models Not mentioned A structured approach to analyze and diagnose organizational problems using dynamic models

7. Dynamic Dynamic models modeling

8. OO

9. AI

Table II. Representation Main features Modeling procedure Five steps in developing dynamic models: Problem formulation Problem conceptualization Model specification Model checking Solution finding Solution implementation Iterative steps: Identify the output class Track backward or forward to events (from/to input to/ from output) Refine the inheritance structures View processes as involving social actors who depend on one another for goals to be achieved, task to be performed and resource to be furnished Types of dependency: open, committed, critical Goal-based reasoning for process redesign for strategic rationale models Process analysis and design tools: Strategic relationships analysis Strategic relationship redesign Qualitative reasoning support Process verification (continued) Represent four essential perspectives: Functional Behavioral Organizational Informational Use OOSA to identify the object in process Apply the OOSA to business modeling Strategic dependency model Strategic rationale model Analysis and design tools

Components

Four fundamental object classes: Output object classes Physiomorphic object classes Event object classes Input object classes Interactions between objects are handled by means of message sending

Social actors Resource, task, goal and softgoal dependencies Resource, task, goal and softgoal dependencies and meanends and task-decomposition links

Models Types of agents: physical and logical Links between agents: material and information flows Swarm simulation framework to represent the MAIS An agent is an active object with unique id. An agent is composed of action function, learning mechanisms, states, database and knowledge base Agents communiate through message passing according to their organizational boundaries

Components

Representation

Main features

Modeling procedure Process modeling procedure Model a business process according to the four components Simulate and evaluate the process uding the Swarm simulation framework

10. MAIS

Consists of four components: Agent Task Organization Information infrastructure

A generic structure for BPM

Table II.

25

BPMJ 8,1

26

by four elements: inputs, controls, outputs and mechanisms (ICOMs). In the 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 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 entityrelation 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). STRIM declares five key concepts of modeling business processes: (1) activities are divided among roles; (2) what an organization is trying to achieve with the process are the process goals; (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

A generic structure for BPM 27

BPMJ 8,1

28

consists of four fundamental object classes, output, physiomorphic, event, and 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), 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); relation, represented by relation class (IDEF1), junctions and links (IDEF3), interaction (RAD), dependencies, mean-ends and decomposition links (AI), object links (OO), or organization (MAIS); agent, also named as social actor, or role (used by RAD, REAL, AI, and MAIS); 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.

A generic structure for BPM 29

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 8,1

process modeling. For example, a business process can be represented in 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 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

32

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 illustrated in Figure 5, where business entities have different functional units to support various activities for the OFP in the SCNs. The OFP in SCNs can be 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. (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

A generic structure for BPM 33

Figure 5. The order fulfillment process

BPMJ 8,1

34

relation between each other to form organizations and utilize resources for the 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 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 8,1

36

Production execution consists of shop floor control, production process, 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 using various information system analysis methods, such as data flow diagram, entity-relation diagram, object models, etc. One example is to utilize objectoriented 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 represent the process of assigning committed dates to incoming orders. In the verification and validation perspectives, the generic BPM method can be 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 to provide a general purpose simulation tool for building simulation models (Santa Fe Institute, 1996). The features of Swarm can be summarized as follows:
.

A generic structure for BPM 37

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 8,1

Supply chain networks Composition of autonomous and semiautonomous business entities Business entities act different organizational roles Multiple layer abstraction Information flow between business entities Material flow during procurement, manufacturing and distribution activities In a SCN, the processes of individual entities contribute to the global SCN performance The visibility of a SCN is determine by the information boundary

Swarm simulation system A swarm of agents with individual based modeling Agents are constructed with internal state variables and action functions Nested inherent hierarchy Message passing between agents Discrete event simulation and time-stepped scheduling to trigger agent actions In Swarm, the combination of individual behaviors determines the collective group behavior The boundaries of message passing determine the visibility

38

Table III. The properties of supply chain networks and Swarm

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 No. 9, pp. 75-90. Davenport, T.H. (1993), Process Innovation: Reengineering Work Through Information Technology, Harvard Business School Press, Boston, MA. 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. 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 ComputerSupported 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.

A generic structure for BPM 41