A generic structure for BPM

Size: px
Start display at page:

Download "A generic structure for BPM"

Transcription

1 The research register for this journal is available at The current issue and full text archive of this journal is available at 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 # MCB UP Limited, DOI /

2 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:

3 (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

4 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)

5 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

6 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

7 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

8 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

9 (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

10 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);

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

22 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 Coad, P, North, D and Mayfield, M (1995), Object Models: Strategies, Patterns and Applications, Prentice-Hall, Englewood Cliffs, NJ

23 Curtis, B, Kellner, MI and Over, J (1992), ``Process modeling, Communication of the ACM, Vol 35 No 9, pp 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 Denna, EL, Jasperson, J, Fong, K and Middleman, D (1994), ``Modeling conversion process events, Journal of Information Systems, Vol 8 No 1, pp 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 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 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 Kettinger, WJ, Teng, J and Guha, S (1997), ``Business process change: a study of methodologies, techniques and tools, MIS Quarterly, March, pp 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 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 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 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 Wang, S (1994), ``OO modeling of business processes, Information System Management, Spring, pp 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 A generic 41

Chap 1. Introduction to Software Architecture

Chap 1. Introduction to Software Architecture Chap 1. Introduction to Software Architecture 1. Introduction 2. IEEE Recommended Practice for Architecture Modeling 3. Architecture Description Language: the UML 4. The Rational Unified Process (RUP)

More information

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

Malay A. Dalal Madhav Erraguntla Perakath Benjamin. Knowledge Based Systems, Inc. (KBSI) College Station, TX 77840, U.S.A. AN INTRODUCTION TO USING PROSIM FOR BUSINESS PROCESS SIMULATION AND ANALYSIS Malay A. Dalal Madhav Erraguntla Perakath Benjamin Knowledge Based Systems, Inc. (KBSI) College Station, TX 77840, U.S.A. ABSTRACT

More information

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

Business Process Reengineering (BPR) for Engineering Management (EM) Majors: Industry Perspective and Students Feedback Business Process Reengineering (BPR) for Engineering Management (EM) Majors: Industry Perspective and Students Feedback Rashmi Jain, PhD Associate Professor Stevens Institute of Technology Rashmi.Jain@stevens.edu

More information

DEVELOPING REQUIREMENTS FOR DATA WAREHOUSE SYSTEMS WITH USE CASES

DEVELOPING REQUIREMENTS FOR DATA WAREHOUSE SYSTEMS WITH USE CASES DEVELOPING REQUIREMENTS FOR DATA WAREHOUSE SYSTEMS WITH USE CASES Robert M. Bruckner Vienna University of Technology bruckner@ifs.tuwien.ac.at Beate List Vienna University of Technology list@ifs.tuwien.ac.at

More information

GOAL-BASED INTELLIGENT AGENTS

GOAL-BASED INTELLIGENT AGENTS International Journal of Information Technology, Vol. 9 No. 1 GOAL-BASED INTELLIGENT AGENTS Zhiqi Shen, Robert Gay and Xuehong Tao ICIS, School of EEE, Nanyang Technological University, Singapore 639798

More information

Ontologies for Enterprise Integration

Ontologies for Enterprise Integration Ontologies for Enterprise Integration Mark S. Fox and Michael Gruninger Department of Industrial Engineering,University of Toronto, 4 Taddle Creek Road, Toronto, Ontario M5S 1A4 tel:1-416-978-6823 fax:1-416-971-1373

More information

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

Announcements. SE 1: Software Requirements Specification and Analysis. Review: Use Case Descriptions Announcements SE 1: Software Requirements Specification and Analysis Lecture 4: Basic Notations Nancy Day, Davor Svetinović http://www.student.cs.uwaterloo.ca/ cs445/winter2006 uw.cs.cs445 Send your group

More information

Modelling and Verification of Business Processes

Modelling and Verification of Business Processes Modelling and Verification of Business Processes Costin Bădică Department of Computer Science King s College London, WC2R 2LS, UK badica@dcs.kcl.ac.uk Chris Fox Department of Computer Science University

More information

How To Develop Software

How To Develop Software Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

Karunya University Dept. of Information Technology

Karunya University Dept. of Information Technology PART A Questions 1. Mention any two software process models. 2. Define risk management. 3. What is a module? 4. What do you mean by requirement process? 5. Define integration testing. 6. State the main

More information

Developing and evaluating a methodology for business process improvement

Developing and evaluating a methodology for business process improvement Developing and evaluating a methodology for business process improvement Sola Adesola and Tim Baines Introduction Business environments are complex. Almost everywhere organisations are undergoing rapid

More information

Business Process Redesign/Reengineering: Introduction

Business Process Redesign/Reengineering: Introduction Business Process Redesign/Reengineering: Introduction Based on: Malhotra, Business Process Redesign: An Overview, http://www.brint.com/papers/bpr.htm. CA441 BPM: Introduction to BPR 1 What this Topic Focuses

More information

Management and optimization of multiple supply chains

Management and optimization of multiple supply chains Management and optimization of multiple supply chains J. Dorn Technische Universität Wien, Institut für Informationssysteme Paniglgasse 16, A-1040 Wien, Austria Phone ++43-1-58801-18426, Fax ++43-1-58801-18494

More information

3SL. Requirements Definition and Management Using Cradle

3SL. Requirements Definition and Management Using Cradle 3SL Requirements Definition and Management Using Cradle November 2014 1 1 Introduction This white paper describes Requirements Definition and Management activities for system/product development and modification

More information

Requirements Traceability. Mirka Palo

Requirements Traceability. Mirka Palo Requirements Traceability Mirka Palo Seminar Report Department of Computer Science University of Helsinki 30 th October 2003 Table of Contents 1 INTRODUCTION... 1 2 DEFINITION... 1 3 REASONS FOR REQUIREMENTS

More information

Chapter 4 Software Lifecycle and Performance Analysis

Chapter 4 Software Lifecycle and Performance Analysis Chapter 4 Software Lifecycle and Performance Analysis This chapter is aimed at illustrating performance modeling and analysis issues within the software lifecycle. After having introduced software and

More information

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

Contents. Introduction and System Engineering 1. Introduction 2. Software Process and Methodology 16. System Engineering 53 Preface xvi Part I Introduction and System Engineering 1 Chapter 1 Introduction 2 1.1 What Is Software Engineering? 2 1.2 Why Software Engineering? 3 1.3 Software Life-Cycle Activities 4 1.3.1 Software

More information

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

Applying 4+1 View Architecture with UML 2. White Paper Applying 4+1 View Architecture with UML 2 White Paper Copyright 2007 FCGSS, all rights reserved. www.fcgss.com Introduction Unified Modeling Language (UML) has been available since 1997, and UML 2 was

More information

A Framework for Adaptive Process Modeling and Execution (FAME)

A Framework for Adaptive Process Modeling and Execution (FAME) A Framework for Adaptive Process Modeling and Execution (FAME) Perakath Benjamin pbenjamin@kbsi.com Madhav Erraguntla merraguntla@kbsi.com Richard Mayer rmayer@kbsi.com Abstract This paper describes the

More information

Using UML Part Two Behavioral Modeling Diagrams

Using UML Part Two Behavioral Modeling Diagrams UML Tutorials Using UML Part Two Behavioral Modeling Diagrams by Sparx Systems All material Sparx Systems 2007 Sparx Systems 2007 Page 1 Trademarks Object Management Group, OMG, Unified Modeling Language,

More information

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

Tool Support for Software Variability Management and Product Derivation in Software Product Lines Tool Support for Software Variability Management and Product Derivation in Software s Hassan Gomaa 1, Michael E. Shin 2 1 Dept. of Information and Software Engineering, George Mason University, Fairfax,

More information

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

Analyzing Requirements of Knowledge Management Systems with the Support of Agent Organizations Analyzing Requirements of Knowledge Management Systems with the Support of Agent Organizations Renata S. S. Guizzardi 1, Anna Perini 2 1 Computer Science Department University of Twente (UT) P.O. Box 217

More information

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

Nr.: Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Nr.: Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Nr.: Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Impressum ( 5 TMG) Herausgeber: Otto-von-Guericke-Universität Magdeburg

More information

Methods and Tolls for Business Process Modeling

Methods and Tolls for Business Process Modeling Methods and Tolls for Business Process Modeling Operations Management Dr. Giuditta Pezzotta Università degli Studi di Bergamo 2011 Riproduzione riservata http://cels.unibg.it 1 Objectives of the lesson

More information

Business-Driven Software Engineering Lecture 3 Foundations of Processes

Business-Driven Software Engineering Lecture 3 Foundations of Processes Business-Driven Software Engineering Lecture 3 Foundations of Processes Jochen Küster jku@zurich.ibm.com Agenda Introduction and Background Process Modeling Foundations Activities and Process Models Summary

More information

A CONCEPTUAL MODELING APPROACH TO BUSINESS PROCESS REENGINEERING

A CONCEPTUAL MODELING APPROACH TO BUSINESS PROCESS REENGINEERING A CONCEPTUAL MODELING APPROACH TO BUSINESS PROCESS REENGINEERING Meral Binbasioglu, Hofstra University, acsmxb@hofstra.edu ABSTRACT The paper proposes an approach to understand the business process dynamics

More information

Algorithms, Flowcharts & Program Design. ComPro

Algorithms, Flowcharts & Program Design. ComPro Algorithms, Flowcharts & Program Design ComPro Definition Algorithm: o sequence of steps to be performed in order to solve a problem by the computer. Flowchart: o graphical or symbolic representation of

More information

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

... Chair of Mobile Business & Multilateral Security. Lecture 13 Business Informatics 2 (PWIN) Business Process Reengineering (BPR) SS 2015 Lecture 13 Business Informatics 2 (PWIN) Business Process Reengineering (BPR) SS 2015 Prof. Dr. Kai Rannenberg www.m-chair.de Chair of Mobile Business & Multilateral Security Jenser (Flickr.com) Business

More information

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

USING UML FOR OBJECT-RELATIONAL DATABASE SYSTEMS DEVELOPMENT: A FRAMEWORK USING UML FOR OBJECT-RELATIONAL DATABASE SYSTEMS DEVELOPMENT: A FRAMEWORK Ming Wang, California State University, ming.wang@calstatela.edu ABSTRACT Data model of object-relational databases (ORDBs) is

More information

Business Process Redesign and Modelling

Business Process Redesign and Modelling Business Process Redesign and Modelling The Business Process Redesign the Process Handbook the key idea of the Process Handbook approach is that a richly structured online repository about business processes

More information

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

The Development of a Supply Chain Management Process Maturity Model Using the Concepts of Business Process Orientation The Development of a Supply Chain Management Process Maturity Model Using the Concepts of Business Process Orientation Dr. Kevin McCormack Instructor, University of Alabama at Birmingham, School of Business

More information

A UML 2 Profile for Business Process Modelling *

A UML 2 Profile for Business Process Modelling * A UML 2 Profile for Business Process Modelling * Beate List and Birgit Korherr Women s Postgraduate College for Internet Technologies Institute of Software Technology and Interactive Systems Vienna University

More information

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

Chapter 13 BUILDING INFORMATION SYSTEMS. How does building new systems produce organizational change? MANAGING THE DIGITAL FIRM, 12 TH EDITION Learning Objectives Chapter 13 BUILDING INFORMATION SYSTEMS VIDEO CASES Case 1: IBM: Business Process Management in a Service Oriented Architecture and Managing

More information

How To Develop A Multi Agent System (Mma)

How To Develop A Multi Agent System (Mma) S-Tropos: An Iterative SPEM-Centric Software Project Management Process Yves Wautelet, Manuel Kolp, Youssef Achbany IAG Institut d Administration et de Gestion, ISYS Unité de Systèmes d Information, Université

More information

Axiomatic design of software systems

Axiomatic design of software systems Axiomatic design of software systems N.P. Suh (1), S.H. Do Abstract Software is playing an increasingly important role in manufacturing. Many manufacturing firms have problems with software development.

More information

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

Journal of Information Technology Management SIGNS OF IT SOLUTIONS FAILURE: REASONS AND A PROPOSED SOLUTION ABSTRACT Journal of Information Technology Management ISSN #1042-1319 A Publication of the Association of Management SIGNS OF IT SOLUTIONS FAILURE: REASONS AND A PROPOSED SOLUTION MAJED ABUSAFIYA NEW MEXICO TECH

More information

Issues in Information Systems Volume 15, Issue I, pp. 52-60, 2014

Issues in Information Systems Volume 15, Issue I, pp. 52-60, 2014 ORGANIZATIONALLY AGNOSTIC BUSINESS MODELING: HOW TO MAKE BUSINESS ARCHITECTURE ADAPTABLE TO ORGANIZATIONAL CHANGE Carlos E. Martinez, The MITRE Corporation, cmartinez@mitre.org Sheila A. Cane, The MITRE

More information

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

A New Methodology For Developing The MIS Master Plan Mohammad Dadashzadeh, Ph.D., Oakland University, USA A New Methodology For Developing The MIS Master Plan Mohammad Dadashzadeh, Ph.D., Oakland University, USA ABSTRACT Organizations, small and large, for profit and non-profit, service oriented as well as

More information

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

A Survey of Good Practices and Misuses for Modelling with i* Framework A Survey of Good Practices and Misuses for Modelling with i* Framework Ilca Webster 1, Juliana Amaral 2, Luiz Marcio Cysneiros1 1 Department of Mathematic and Statistics - Information Technology Program

More information

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

Business Processes Attempts to Find a Definition. Ann Lindsay, Ken Lunn School of Computing and Engineering, University of Huddersfield, UK Business Processes Attempts to Find a Definition Ann Lindsay, Ken Lunn School of Computing and Engineering, University of Huddersfield, UK Abstract This paper proposes that definitions of business process

More information

Answers to Review Questions

Answers to Review Questions Tutorial 2 The Database Design Life Cycle Reference: MONASH UNIVERSITY AUSTRALIA Faculty of Information Technology FIT1004 Database Rob, P. & Coronel, C. Database Systems: Design, Implementation & Management,

More information

SOA: The missing link between Enterprise Architecture and Solution Architecture

SOA: The missing link between Enterprise Architecture and Solution Architecture SOA: The missing link between Enterprise Architecture and Solution Architecture Jaidip Banerjee and Sohel Aziz Enterprise Architecture (EA) is increasingly being acknowledged as the way to maximize existing

More information

The SPES Methodology Modeling- and Analysis Techniques

The SPES Methodology Modeling- and Analysis Techniques The SPES Methodology Modeling- and Analysis Techniques Dr. Wolfgang Böhm Technische Universität München boehmw@in.tum.de Agenda SPES_XT Project Overview Some Basic Notions The SPES Methodology SPES_XT

More information

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

Systematization of Requirements Definition for Software Development Processes with a Business Modeling Architecture Systematization of Requirements Definition for Software Development Processes with a Business Modeling Architecture Delmir de Azevedo Junior 1 and Renato de Campos 2 1 Petrobras University, Republican

More information

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

Kuwait Chapter of Arabian Journal of Business and Management Review Vol. 3, No.4; Dec. 2013 EFFECTS OF PROCESS ANALYSIS AND SIMULATION TOOLS TO IMPROVE THE PURCHASING PROCESS AND PRACTICE OF TYPICAL INDUSTRIAL Hossein Ebadati 1 *, Seyed Yahya Seyed Danesh 2, Esmail Malek Akhlagh 3 1* -Department

More information

A TAXONOMY OF BUSINESS PROCESS MODELLING AND INFORMATION SYSTEMS MODELLING TECHNIQUES

A TAXONOMY OF BUSINESS PROCESS MODELLING AND INFORMATION SYSTEMS MODELLING TECHNIQUES A TAXONOMY OF BUSINESS PROCESS MODELLING AND INFORMATION SYSTEMS MODELLING TECHNIQUES George M. Giaglis Department of Information Systems and Computing Brunel University, Uxbridge UB8 3PH, Middlesex, UK

More information

(Refer Slide Time 00:56)

(Refer Slide Time 00:56) Software Engineering Prof.N. L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-12 Data Modelling- ER diagrams, Mapping to relational model (Part -II) We will continue

More information

Analysis and Implementation of Workflowbased Supply Chain Management System

Analysis and Implementation of Workflowbased Supply Chain Management System Analysis and Implementation of Workflowbased Supply Chain Management System Yan Tu 1 and Baowen Sun 2 1 Information School, Central University of Finance and Economics, Beijing, 100081, P.R.China,Yolanda_tu@yahoo.com.cn

More information

THE ENTERPRISE INTEGRATION ISSUES ENCOUNTERED WITH AGILE PROCESS INTRODUCTION

THE ENTERPRISE INTEGRATION ISSUES ENCOUNTERED WITH AGILE PROCESS INTRODUCTION THE ENTERPRISE INTEGRATION ISSUES ENCOUNTERED WITH AGILE PROCESS INTRODUCTION K.J.(Jamie) Rogers 1, Larry Whitman 2, D. Ryan Underdown 2 1 The University of Texas at Arlington IMSE Dept. PO Box 19017 Arlington,

More information

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 10 Outline The Role of Information Systems in

More information

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

1. Process Modeling. Process Modeling (Cont.) Content. Chapter 7 Structuring System Process Requirements Content Chapter 7 Structuring System Process Requirements Understand the logical (&physical) process modeling by using data flow diagrams (DFDs) Draw DFDs & Leveling Balance higher-level and lower-level

More information

The Project Planning Process Group

The Project Planning Process Group 3 The Project Planning Process Group............................................... Terms you ll need to understand: Activity Activity attributes Activity list Activity on arrow diagram (AOA) Activity

More information

A Reference Model for Process-Oriented Software Development Organizations

A Reference Model for Process-Oriented Software Development Organizations A Reference Model for Process-Oriented Software Development Organizations João M. Fernandes 1 and Francisco J. Duarte 2 1 Dep. Informática, Universidade do Minho, Braga, Portugal 2 Blaupunkt Auto-Rádio

More information

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

QUALITY TOOLBOX. Understanding Processes with Hierarchical Process Mapping. Robert B. Pojasek. Why Process Mapping? QUALITY TOOLBOX Understanding Processes with Hierarchical Process Mapping In my work, I spend a lot of time talking to people about hierarchical process mapping. It strikes me as funny that whenever I

More information

feature requirements engineering

feature requirements engineering feature requirements engineering Exploring Alternatives during Requirements Analysis John Mylopoulos, University of Toronto Goal-oriented requirements analysis techniques provide ways to refine organizational

More information

PROCESS-DRIVEN SOFTWARE DEVELOPMENT METHODOLOGY FOR ENTERPRISE INFORMATION SYSTEM

PROCESS-DRIVEN SOFTWARE DEVELOPMENT METHODOLOGY FOR ENTERPRISE INFORMATION SYSTEM PROCESS-DRIVEN SOFTWARE DEVELOPMENT METHODOLOGY FOR ENTERPRISE INFORMATION SYSTEM Kwan Hee Han 1 and Yongsun Choi 2 1 Department of Industrial & Systems Engineering, Engineering Research Institute, Gyeongsang

More information

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

Dynamic business process management based on the combined control and data networks Preprints of the 2013 IFAC Conference on Manufacturing Modelling, Management, and Control, Saint Petersburg State University and Saint Petersburg National Research University of Information Technologies,

More information

Artificial Intelligence and Business Process Reengineering

Artificial Intelligence and Business Process Reengineering Knowledge Management For Best Practices Daniel E. O Leary and Peter Selfridge Perhaps one of the most celebrated and significant recent developments in information systems in business has been business

More information

Verifying Semantic of System Composition for an Aspect-Oriented Approach

Verifying Semantic of System Composition for an Aspect-Oriented Approach 2012 International Conference on System Engineering and Modeling (ICSEM 2012) IPCSIT vol. 34 (2012) (2012) IACSIT Press, Singapore Verifying Semantic of System Composition for an Aspect-Oriented Approach

More information

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

Ubiquitous, Pervasive and Mobile Computing: A Reusable-Models-based Non-Functional Catalogue Ubiquitous, Pervasive and Mobile Computing: A Reusable-Models-based Non-Functional Catalogue Milene Serrano 1 and Maurício Serrano 1 1 Universidade de Brasília (UnB/FGA), Curso de Engenharia de Software,

More information

Space project management

Space project management ECSS-M-ST-80C Space project management Risk management ECSS Secretariat ESA-ESTEC Requirements & Standards Division Noordwijk, The Netherlands Foreword This Standard is one of the series of ECSS Standards

More information

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

An Automatic Tool for Checking Consistency between Data Flow Diagrams (DFDs) An Automatic Tool for Checking Consistency between Data Flow Diagrams (DFDs) Rosziati Ibrahim, Siow Yen Yen Abstract System development life cycle (SDLC) is a process uses during the development of any

More information

Quality Ensuring Development of Software Processes

Quality Ensuring Development of Software Processes Quality Ensuring Development of Software Processes ALEXANDER FÖRSTER,GREGOR ENGELS Department of Computer Science University of Paderborn D-33095 Paderborn, Germany {alfo engels}@upb.de ABSTRACT: Software

More information

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

TECH. Requirements. Why are requirements important? The Requirements Process REQUIREMENTS ELICITATION AND ANALYSIS. Requirements vs. CH04 Capturing the Requirements Understanding what the customers and users expect the system to do * The Requirements Process * Types of Requirements * Characteristics of Requirements * How to Express

More information

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

The S 3 (Strategy-Service-Support) Framework for Business Process Modelling The S 3 (Strategy-Service-Support) Framework for Business Process Modelling P. Loucopoulos Department of Computation University of Manchester Institute of Science & Technology P.O. Box 88, Manchester,

More information

A Methodology for the Development of New Telecommunications Services

A Methodology for the Development of New Telecommunications Services A Methodology for the Development of New Telecommunications Services DIONISIS X. ADAMOPOULOS Centre for Communication Systems Research School of Elec. Eng., IT and Mathematics University of Surrey Guildford

More information

Compliance and Requirement Traceability for SysML v.1.0a

Compliance and Requirement Traceability for SysML v.1.0a 1. Introduction: Compliance and Traceability for SysML v.1.0a This document provides a formal statement of compliance and associated requirement traceability for the SysML v. 1.0 alpha specification, which

More information

Software Project Management and UML

Software Project Management and UML Software Project Management and UML Ali Bigdelou Computer Aided Medical Procedures (CAMP), Technische Universität München, Germany Outline Intro to Software Project Management Project Requirements Specification

More information

Course Syllabus For Operations Management. Management Information Systems

Course Syllabus For Operations Management. Management Information Systems For Operations Management and Management Information Systems Department School Year First Year First Year First Year Second year Second year Second year Third year Third year Third year Third year Third

More information

TOGAF usage in outsourcing of software development

TOGAF usage in outsourcing of software development Acta Informatica Pragensia 2(2), 2013, 68 76, DOI: 10.18267/j.aip.25 Section: Online: aip.vse.cz Peer-reviewed papers TOGAF usage in outsourcing of software development Aziz Ahmad Rais 1, Rudolf Pecinovsky

More information

Project Time Management

Project Time Management Project Time Management Study Notes PMI, PMP, CAPM, PMBOK, PM Network and the PMI Registered Education Provider logo are registered marks of the Project Management Institute, Inc. Points to Note Please

More information

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

11 Tips to make the requirements definition process more effective and results more usable 1 11 Tips to make the s definition process more effective and results more usable This article discusses what I believe are the key techniques for making s definition process repeatable from project to

More information

Introduction to Workflow

Introduction to Workflow Introduction to Workflow SISTEMI INFORMATICI SUPPORTO ALLE DECISIONI AA 2006-2007 Libro di testo: Wil van der Aalst and Kees van Hee. Workflow Management: Models, Methods, and Systems. The MIT Press, paperback

More information

ERP modeling: a comprehensive approach

ERP modeling: a comprehensive approach Information Systems 28 (2003) 673 690 ERP modeling: a comprehensive approach Pnina Soffer, Boaz Golany*, Dov Dori Faculty of Industrial Engineering and Management, Technion-Israel Institute of Technology,

More information

Business Architecture with ArchiMate symbols and TOGAF Artefacts

Business Architecture with ArchiMate symbols and TOGAF Artefacts Business Architecture with ArchiMate symbols and TOGAF Artefacts This is a supplement to the broader framework TOGAF s generic conceptual framework with ArchiMate symbols http://grahamberrisford.com/00eaframeworks/03togaf/togaf%20conceptual%20framework%20-%20with%20archimate%20symbols.pdf

More information

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Service Oriented Analysis and Design (SOAD) in Practice Part 4 Adomas Svirskas Vilnius University October 2005 Agenda Service identification and definition Business process

More information

Business Process Modeling

Business Process Modeling Business Process Modeling e-framework Workshop Balbir Barn 12 th February 2007 Agenda Why we construct Business Process Models A historical context Approaches to business process modelling Business Process

More information

Object Oriented Programming. Risk Management

Object Oriented Programming. Risk Management Section V: Object Oriented Programming Risk Management In theory, there is no difference between theory and practice. But, in practice, there is. - Jan van de Snepscheut 427 Chapter 21: Unified Modeling

More information

LECTURE 11: PROCESS MODELING

LECTURE 11: PROCESS MODELING LECTURE 11: PROCESS MODELING Outline Logical modeling of processes Data Flow Diagram Elements Functional decomposition Data Flows Rules and Guidelines Structured Analysis with Use Cases Learning Objectives

More information

A MULTI-METHOD FOR DEFINING THE ORGANIZATIONAL CHANGE

A MULTI-METHOD FOR DEFINING THE ORGANIZATIONAL CHANGE A MULTI-METHOD FOR DEFINING THE ORGANIZATIONAL CHANGE Selmin Nurcan *+, Associate Professor, Business Administration Institute - Université Paris 1 - Sorbonne Colette Rolland *, Professor, Université Paris

More information

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams

Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Chapter 10 Practical Database Design Methodology and Use of UML Diagrams Copyright 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 10 Outline The Role of Information Systems in

More information

A Role-Based Framework for Business Process Modeling

A Role-Based Framework for Business Process Modeling A Role-Based Framework for Business Process Modeling Artur Caetano 1,3, Marielba Zacarias 1, António Rito Silva 2,3, José Tribolet 1,3 1 Organizational Engineering Center, INESC INOV. 2 Software Engineering

More information

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

Questions? Assignment. Techniques for Gathering Requirements. Gathering and Analysing Requirements Questions? Assignment Why is proper project management important? What is goal of domain analysis? What is the difference between functional and non- functional requirements? Why is it important for requirements

More information

Develop Project Charter. Develop Project Management Plan

Develop Project Charter. Develop Project Management Plan Develop Charter Develop Charter is the process of developing documentation that formally authorizes a project or a phase. The documentation includes initial requirements that satisfy stakeholder needs

More information

An Automated Workflow System Geared Towards Consumer Goods and Services Companies

An Automated Workflow System Geared Towards Consumer Goods and Services Companies Proceedings of the 2014 International Conference on Industrial Engineering and Operations Management Bali, Indonesia, January 7 9, 2014 An Automated Workflow System Geared Towards Consumer Goods and Services

More information

A Business Process Driven Approach for Generating Software Modules

A Business Process Driven Approach for Generating Software Modules A Business Process Driven Approach for Generating Software Modules Xulin Zhao, Ying Zou Dept. of Electrical and Computer Engineering, Queen s University, Kingston, ON, Canada SUMMARY Business processes

More information

Scenario-based Requirements Engineering and User-Interface Design

Scenario-based Requirements Engineering and User-Interface Design Scenario-based Requirements Engineering and User-Interface Institut für Computertechnik ICT Institute of Computer Technology Hermann Kaindl Vienna University of Technology, ICT Austria kaindl@ict.tuwien.ac.at

More information

Evaluating Data Warehousing Methodologies: Objectives and Criteria

Evaluating Data Warehousing Methodologies: Objectives and Criteria Evaluating Data Warehousing Methodologies: Objectives and Criteria by Dr. James Thomann and David L. Wells With each new technical discipline, Information Technology (IT) practitioners seek guidance for

More information

TEACHING AGGREGATE PLANNING IN AN OPERATIONS MANAGEMENT COURSE

TEACHING AGGREGATE PLANNING IN AN OPERATIONS MANAGEMENT COURSE TEACHING AGGREGATE PLANNING IN AN OPERATIONS MANAGEMENT COURSE Johnny C. Ho, Turner College of Business, Columbus State University, Columbus, GA 31907 David Ang, School of Business, Auburn University Montgomery,

More information

Object Oriented Design

Object Oriented Design Object Oriented Design Kenneth M. Anderson Lecture 20 CSCI 5828: Foundations of Software Engineering OO Design 1 Object-Oriented Design Traditional procedural systems separate data and procedures, and

More information

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

i. Node Y Represented by a block or part. SysML::Block, OMG SysML Requirements Traceability (informative) This document has been published as OMG document ptc/07-03-09 so it can be referenced by Annex E of the OMG SysML specification. This document describes

More information

Chapter 7: Structuring System Process Requirements

Chapter 7: Structuring System Process Requirements Chapter 7: Structuring System Process Requirements Multiple Choice Questions 1. Data flow diagrams that concentrate on the movement of data between processes are referred to as: a. process models b. data

More information

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

On Applying Normalized Systems Theory to the Business Architectures of Information Systems Baltic J. Modern Computing, Vol. 2 (204), No. 3, 32-49 On Applying Normalized Systems Theory to the Business Architectures of Information Systems Erki EESSAAR Department of Informatics, Tallinn University

More information

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

Acknowledgement. Software Engineering. CS 3141: Team Software Project Introduction CS 3141: Team Software Project Introduction Ali Ebnenasir Department of Computer Science Michigan Technological University Acknowledgement Betty H.C. Cheng Software Engineering Systematic approach for

More information

FUNCTIONAL ANALYSIS AND ALLOCATION

FUNCTIONAL ANALYSIS AND ALLOCATION Functional Analysis Allocation CHAPTER 5 FUNCTIONAL ANALYSIS AND ALLOCATION 5.1 INTRODUCTION The purpose of this systems engineering process activity is to transform the functional, performance, interface

More information

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

Research Framework of Education Supply Chain, Research Supply Chain and Educational Management for the Universities Framework of Education Supply Chain, Supply Chain and Educational Management for the Universities Md. Mamun Habib Founder & President, Engineering Education & Career Program, Bangladesh mamunhabib@gmail.com

More information

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

Requirements Analysis Concepts & Principles. Instructor: Dr. Jerry Gao Requirements Analysis Concepts & Principles Instructor: Dr. Jerry Gao Requirements Analysis Concepts and Principles - Requirements Analysis - Communication Techniques - Initiating the Process - Facilitated

More information

Program Understanding in Software Engineering

Program Understanding in Software Engineering Taming the complexity: The need for program understanding in software engineering Raghvinder S. Sangwan, Ph.D. Pennsylvania State University, Great Valley School of Graduate Professional Studies Robert

More information

Process Analysis. Work Process Documentation Guidelines. Purpose

Process Analysis. Work Process Documentation Guidelines. Purpose Purpose The purpose of this tool is threefold: Convey a common understanding of the basis for documenting work processes by defining the five levels of detail for capturing work process Provide instructions

More information

Masters of Science in Software & Information Systems

Masters of Science in Software & Information Systems Masters of Science in Software & Information Systems To be developed and delivered in conjunction with Regis University, School for Professional Studies Object Oriented Design Table of Contents January

More information