A generic structure for BPM



Similar documents
Chap 1. Introduction to Software Architecture

Malay A. Dalal Madhav Erraguntla Perakath Benjamin. Knowledge Based Systems, Inc. (KBSI) College Station, TX 77840, U.S.A.

Business Process Reengineering (BPR) for Engineering Management (EM) Majors: Industry Perspective and Students Feedback

DEVELOPING REQUIREMENTS FOR DATA WAREHOUSE SYSTEMS WITH USE CASES

GOAL-BASED INTELLIGENT AGENTS

Ontologies for Enterprise Integration

Announcements. SE 1: Software Requirements Specification and Analysis. Review: Use Case Descriptions

Modelling and Verification of Business Processes

How To Develop Software

Karunya University Dept. of Information Technology

Developing and evaluating a methodology for business process improvement

Business Process Redesign/Reengineering: Introduction

Management and optimization of multiple supply chains

3SL. Requirements Definition and Management Using Cradle

Requirements Traceability. Mirka Palo

Chapter 4 Software Lifecycle and Performance Analysis

Contents. Introduction and System Engineering 1. Introduction 2. Software Process and Methodology 16. System Engineering 53

Applying 4+1 View Architecture with UML 2. White Paper

A Framework for Adaptive Process Modeling and Execution (FAME)

Using UML Part Two Behavioral Modeling Diagrams

Tool Support for Software Variability Management and Product Derivation in Software Product Lines

Analyzing Requirements of Knowledge Management Systems with the Support of Agent Organizations

Nr.: Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg

Methods and Tolls for Business Process Modeling

Business-Driven Software Engineering Lecture 3 Foundations of Processes

A CONCEPTUAL MODELING APPROACH TO BUSINESS PROCESS REENGINEERING

Algorithms, Flowcharts & Program Design. ComPro

... Chair of Mobile Business & Multilateral Security. Lecture 13 Business Informatics 2 (PWIN) Business Process Reengineering (BPR) SS 2015

USING UML FOR OBJECT-RELATIONAL DATABASE SYSTEMS DEVELOPMENT: A FRAMEWORK

Business Process Redesign and Modelling

The Development of a Supply Chain Management Process Maturity Model Using the Concepts of Business Process Orientation

A UML 2 Profile for Business Process Modelling *

Chapter 13 BUILDING INFORMATION SYSTEMS. How does building new systems produce organizational change?

How To Develop A Multi Agent System (Mma)

Axiomatic design of software systems

Journal of Information Technology Management SIGNS OF IT SOLUTIONS FAILURE: REASONS AND A PROPOSED SOLUTION ABSTRACT

Issues in Information Systems Volume 15, Issue I, pp , 2014

A New Methodology For Developing The MIS Master Plan Mohammad Dadashzadeh, Ph.D., Oakland University, USA

A Survey of Good Practices and Misuses for Modelling with i* Framework

Business Processes Attempts to Find a Definition. Ann Lindsay, Ken Lunn School of Computing and Engineering, University of Huddersfield, UK

Answers to Review Questions

SOA: The missing link between Enterprise Architecture and Solution Architecture

The SPES Methodology Modeling- and Analysis Techniques

Systematization of Requirements Definition for Software Development Processes with a Business Modeling Architecture

Kuwait Chapter of Arabian Journal of Business and Management Review Vol. 3, No.4; Dec. 2013

A TAXONOMY OF BUSINESS PROCESS MODELLING AND INFORMATION SYSTEMS MODELLING TECHNIQUES

(Refer Slide Time 00:56)

Analysis and Implementation of Workflowbased Supply Chain Management System

THE ENTERPRISE INTEGRATION ISSUES ENCOUNTERED WITH AGILE PROCESS INTRODUCTION

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams

1. Process Modeling. Process Modeling (Cont.) Content. Chapter 7 Structuring System Process Requirements

The Project Planning Process Group

A Reference Model for Process-Oriented Software Development Organizations

QUALITY TOOLBOX. Understanding Processes with Hierarchical Process Mapping. Robert B. Pojasek. Why Process Mapping?

feature requirements engineering

PROCESS-DRIVEN SOFTWARE DEVELOPMENT METHODOLOGY FOR ENTERPRISE INFORMATION SYSTEM

Dynamic business process management based on the combined control and data networks

Artificial Intelligence and Business Process Reengineering

Verifying Semantic of System Composition for an Aspect-Oriented Approach

Ubiquitous, Pervasive and Mobile Computing: A Reusable-Models-based Non-Functional Catalogue

Space project management

An Automatic Tool for Checking Consistency between Data Flow Diagrams (DFDs)

Quality Ensuring Development of Software Processes

TECH. Requirements. Why are requirements important? The Requirements Process REQUIREMENTS ELICITATION AND ANALYSIS. Requirements vs.

The S 3 (Strategy-Service-Support) Framework for Business Process Modelling

A Methodology for the Development of New Telecommunications Services

Compliance and Requirement Traceability for SysML v.1.0a

Software Project Management and UML

Course Syllabus For Operations Management. Management Information Systems

TOGAF usage in outsourcing of software development

Project Time Management

11 Tips to make the requirements definition process more effective and results more usable

Introduction to Workflow

ERP modeling: a comprehensive approach

Business Architecture with ArchiMate symbols and TOGAF Artefacts

Service Oriented Architecture

Business Process Modeling

Object Oriented Programming. Risk Management

LECTURE 11: PROCESS MODELING

A MULTI-METHOD FOR DEFINING THE ORGANIZATIONAL CHANGE

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams

A Role-Based Framework for Business Process Modeling

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements

Develop Project Charter. Develop Project Management Plan

An Automated Workflow System Geared Towards Consumer Goods and Services Companies

A Business Process Driven Approach for Generating Software Modules

Scenario-based Requirements Engineering and User-Interface Design

Evaluating Data Warehousing Methodologies: Objectives and Criteria

TEACHING AGGREGATE PLANNING IN AN OPERATIONS MANAGEMENT COURSE

Object Oriented Design

i. Node Y Represented by a block or part. SysML::Block,

Chapter 7: Structuring System Process Requirements

On Applying Normalized Systems Theory to the Business Architectures of Information Systems

Acknowledgement. Software Engineering. CS 3141: Team Software Project Introduction

FUNCTIONAL ANALYSIS AND ALLOCATION

Research Framework of Education Supply Chain, Research Supply Chain and Educational Management for the Universities

Requirements Analysis Concepts & Principles. Instructor: Dr. Jerry Gao

Program Understanding in Software Engineering

Process Analysis. Work Process Documentation Guidelines. Purpose

Masters of Science in Software & Information Systems

Transcription:

The research register for this journal is available at http://wwwemeraldinsightcom/researchregisters The current issue and full text archive of this journal is available at http://wwwemeraldinsightcom/1463-7154htm A generic 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 A generic 19 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 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 BPR s 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 () is essential within a BPR life cycle The 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 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 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 101108/14637150210418610

J 8,1 20 Table I Business process reengineering methodologies Methods Description Proposers PADM (process analysis and design methodology PRLC (process reengineering life cycle) BPR framework BPR stages BPR stages The PADM consists of four phases which intermingle and reciprocally interact The four phases are (1) process definition; (2) baseline process capture and representation; (3) process evaluation; and (4) target process design The PRLC includes five stages: (1) envisioning process change; (2) inaugurating the reengineering project; (3) diagnosing; (4) (re)designing; and (5) (re)structuring The fundamental structure of the proposed BPR framework contains three elements: (1) BPR principle; (2) BPR process; and (3) BPR methods and tools 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 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 Wastell et al (1996) 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 methods in order to identify different emphases among them and elicit generic features from these methods Second, we attempt to develop a generic 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 method We describe various methods in the next section A generic 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 methods in the literature and comparing them in different dimensions These methods are listed and discussed in the following subsections 21 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 (ie 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 methods, we found that there would be a large space to improve 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 methods is summarized in Table II by comparing their model components, representation, main features, and modeling procedures The selected 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 A generic 21

J 8,1 22 Table II The list of business process modelling methods Models Components Representation Main features Modeling procedure A process is composed of ICOMs IDEF0 is a function modeling method Hierarchical decomposition of activities IDEF0 captures ``what organization does 1 IDEF0 Each activity is specified by four elements: input, control, output and mechanism (ICOM) 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 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 representing information 2 IDEF1 Entity, entity class, relation, relation class (similar to entityrelation diagram) Model development refines the three levels of detail from entity relationship to fully attributed level IDEFIX is a business rule modeling method IDEFIX diagrams are refined into three 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 Using object-oriented representation to entities, attributes and their relations 3 IDEFIX Four terms are involved in rule modeling: entity, message, attribute and relationship 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 IDEF3 is a scenario-driven process flow modeling method, which supports two models: (1) process flow description; and (2) object state transaction description Elaboration specification: object, factor, constraint and description 4 IDEF3 UOB (unit of behavior) is associated with elaboration and decomposition UOBs are connected with junctions and links (continued)

Models Components Representation Main features Modeling procedure Describe and define the role s work Specifies the business role (how the process goes) Process function Decision making Business scenario 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 5 RAD Processes are divided over roles The process goals are represented by states Activities Interactions Business rules 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) 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? REAL concepts are independent from diagramming technologies 6 REAL Four components: Resource; Event; Agent; and Location A generic 23 Table II

J 8,1 24 Table II Models Components Representation Main features Modeling procedure Five steps in developing dynamic models: Problem formulation Problem conceptualization Model specification Model checking Solution finding Solution implementation Dynamic models Not mentioned A structured approach to analyze and diagnose organizational problems using dynamic models 7 Dynamic modeling Iterative steps: Identify the output class Track backward or forward to events (from/to input to/ from output) Refine the inheritance structures Use OOSA to identify the object in process Apply the OOSA to business modeling Represent four essential perspectives: Functional Behavioral Organizational Informational 8 OO 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 Process analysis and design tools: Strategic relationships analysis Strategic relationship redesign Qualitative reasoning support Process verification (continued) 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 Strategic dependency model Strategic rationale model Analysis and design tools 9 AI Social actors Resource, task, goal and softgoal dependencies Resource, task, goal and softgoal dependencies and meanends and task-decomposition links

Models 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 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 Types of agents: physical and logical Links between agents: material and information flows Swarm simulation framework to represent the MAIS 10 MAIS Consists of four components: Agent Task Organization Information infrastructure A generic 25 Table II

J 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 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? A generic 27 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

J 8,1 28 consists of four fundamental object classes, output, physiomorphic, event, and input object classes Besides possessing OOA s functional and informational perspectives, the OO modeling method expands to include organizational and behavioral dimensions The system s 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 22 Analysis of business process modeling methods After decomposing methods described in subsection 21, 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 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 (eg 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 methods based on the six modeling perspectives: functional, behavioral, organizational, informational, verification and validation, and modeling procedure A generic 29 3 A generic business process modeling After analyzing various 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 methods aforementioned into the quantitative measure based on these six perspectives A method obtains five points for strongly supporting certain perspectives, three points for a supported case, and one

J 8,1 30 Figure 1 The comparison of 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 components under six perspectives

A generic 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 methods with verification and validation are those emphasizing behavior, agent and event components of a business process (6) Those 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 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 methods We can identify various competencies of different methods in order to make the best use of their strengths, and facilitate new method development according to these essential concepts and perspectives of business process modeling The other is to develop a generic method, which demonstrates its generality This generic modeling method possesses several features suitable for business

J 8,1 32 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 Figure 4 The generic 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 33 Figure 5 The order fulfillment process

J 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, 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, 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 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

J 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 Coad s 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 agent s behavior Technologies, such as decision rules, decision tables, state-transition diagrams, etc are applicable In multiple layers of abstraction, agent s 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 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: 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 agent s 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, {a 1, a 2,, a n } An agent, eg a k, itself is a swarm of agents called Swarm K (Swarm K = {k 1, k 2,, k m }), where agent a k is the parent agent of agents in Swarm K When child agents (eg agents in Swarm K) receive messages from their parent swarm s scheduler (eg Swarm A s scheduler), the behavior of that agent (eg a k ) is the result of actions performed by the swarm of constituent child agents (eg 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 A generic 37 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

J 8,1 38 Table III The properties of supply chain networks and Swarm 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 business processes in multiple layer of abstraction and separation of concerns Figure 11 demonstrates Swarm s 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 39 Figure 11 The implementation of multiple-layer of abstraction using Swarm s 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 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 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 method works An order fulfillment process

J 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 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 method on real world processes can further enhance its applicability In future research, we will apply this generic method to various domain processes in order to justify further this method in different processes References Appleton, DS (1995), ``Business reengineering with business rules, in Grover, V and Ketinger, WJ (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, MI and Over, J (1992), ``Process modeling, Communication of the ACM, Vol 35 No 9, pp 75-90 Davenport, TH (1993), Process Innovation: Reengineering Work Through Information Technology, Harvard Business School Press, Boston, MA Davenport, TH and Stoddard, DB (1994), ``Reengineering: business change of mythic proportions, MIS Quarterly, June, pp 121-7 Denna, EL, Jasperson, J, Fong, K and Middleman, D (1994), ``Modeling conversion process events, Journal of Information Systems, Vol 8 No 1, pp 43-54 Denna, EL, Perry, LT and Jasperson, J (1995), ``Reengineering and REAL business process modeling, in Grover, V and Kettinger, WJ (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, WJ (Eds), Business Process Change: Reengineering Concepts, Methods and Technologies, Idea Group Publishing, London, pp 330-49 Kettinger, WJ, Guha, S and Teng, J (1995), ``The process reengineering life cycle methodology: a case study, in Grover, V and Kettinger, WJ (Eds), Business Process Change: Reengineering Concepts, Methods and Technologies, Idea Group Publishing, London, pp 211-44 Kettinger, WJ, 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 WG81/WG82 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, RJ, Benjamin, PC, Caraway, BE and Painter, M (1995), ``A framework and a suite of methods for business process reengineering, in Grover, V and Kettinger, WJ (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, CSCW 92, Toronto, pp 281-8 Norman, RJ (1996), Object-Oriented System Analysis and Design, Prentice-Hall, Inc, Englewood Cliffs, NJ Ould, MA (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://wwwswarmorg/ van Meel, JW, Bots, PWG and Sol, HG (1995), ``Lessons learned from business engineering within Amsterdam Municipal Police Force: the applicability of dynamic modeling, in Grover, V and Kettinger, WJ (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, DG, 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 41