A Modeling Method and Arena Template - CiteSeerX

Integrating the Conceptualization and Simulation of Business Processes: A Modeling Method and Arena Template Gert-Jan de Vreede Department of Information Systems and Quantitative Analysis College of Information Science and Technology University of Nebraska at Omaha [email protected] Alexander Verbraeck Delft University of Technology Faculty of Technology, Policy, and Management The Netherlands [email protected] Daniel T. T. van Eijck ABZ Branche Initiatieven b.v. P.O. Box 124, 3700 AC Zeist The Netherlands Redesigning organizational processes and their coordination often involves the construction of conceptual models, empirical models, and change alternatives. Modeling of organizational processes can be a very time-consuming activity, and during the redesign phase of an organization, time is a scarce resource. During the phase of translating process models of an organization into simulation models for analysis, diagnosis, and design, a lot of time is spent on translating conceptual models into simulation models. Furthermore, the resulting simulation models often lack any resemblance to the original conceptual models. This makes the communication, verification, and change activities within the simulation study quite difficult. This paper describes a template that was built in the simulation language Arena, which decreases the gap between the conceptualization activities and the translation into a simulation model. This paper describes the requirements for the template, a prototype implementation, and a case example to test the applicability of the template. Keywords: Business process simulation, business engineering, model translation, simulation techniques

1. Introduction Modern organizations find themselves in a demanding, changing environment [1-3]. Organizations are subject to a constant need to adapt their structures, processes, and technologies to meet new demands from their environment [1, 4, 5]. Organizing, and therefore also reorganizing, can be defined as the process of dividing more complex organizational processes into distinct tasks, establishing the coordination between the tasks, and allocating (groups of) tasks to individuals or groups of persons [6]. The coordination of tasks aims at guiding and monitoring the process as a whole. Usually, not only the division and allocation of labor has to be reorganized but the coordinating activities as SIMULATION, Vol. 79, Issue 1, January 2003 43-55 © 2003 The Society for Modeling and Simulation International DOI: 10.1177/0037549703254725

| | | | | |

well. Coordination usually signifies the process of bringing separate entities into synergy, ensuring that they function together. It concerns the management of interdependencies between organizational resources [7]. The type of coordination that is described in this paper can best be described as organizational coordination (see, e.g., Mintzberg [6], Malone [7], and Thompson [8]). Several approaches for redesigning organizations propose radical change [9], gradual change, or a combination [10-12]. In this paper, we build on an approach that was named by the broad term dynamic modeling originally [13, 14] but can better be termed business engineering, which will be used in the rest of this paper. Business engineering uses the problem-solving paradigm, which means that an organizational problem with a “sense of urgency” is taken as a starting point. A central notion in the business engineering approach is the extensive use of models, both

de Vreede, Verbraeck, and van Eijck

for complexity reduction and for communication. A distinction is made between conceptual models and empirical models. Conceptual models define the structure of the problem and contain no or very little empirical data. Empirical models add data from the problem domain, which allows users to analyze and diagnose various versions of the models. Furthermore, the approach always starts with analyzing the current situation using as-is models and then researches several change alternatives with to-be models. One of the main problems in redesigning complex organizations is that the modeling process can take much longer than is considered acceptable. The “sense of urgency” of the problem usually forces an organization to reach a decision on a new structure quite fast. When the modeling process takes long, the organization has already changed by gradual changes before conclusions based on the modeling efforts have been reached. Most modeling methods as described in literature take a long time because many stakeholders need to be interviewed to form a scattered picture of the current situation. After that, the modeler has to confront them with conflicting information of other stakeholders to try to reach a single version of the model of the current organization on which most stakeholders agree. Then the modeler can try to get ideas for changes from within the organization. Many scattered ideas result from this activity as well, making it difficult to integrate them into a small set of “to-be” models the decision makers can discuss. Additional problems are that the stakeholders do not understand many of the models that are made, doubt the quantitative results they are presented with, and are not stimulated in finding creative solutions for the current problems. A central question that needs to be addressed is the following: What modeling methods, techniques, and tools are most appropriate to support business engineering projects? Early works on tools for business process modeling [15] placed an emphasis on CASE-like tools for depicting the processes within an organization. To really support the change process, more is needed. In addition to a clear and easy method to communicate the diagramming technique—supported by a diagramming tool or CASE tool, if possible—methods and tools for quantitative analysis using empirical models are needed as well. In the past decade, simulation, especially discrete event simulation, has proven to be of great value in business modeling projects [16-19]. Using simulation models, quantitative analysis of the current division of tasks over workers, carrying out tasks in the course of time, bottlenecks, proposed changes, and many performance indicators are relatively easy to obtain [19]. Building simulation models is, however, still a time-consuming task, and usually the simulation models have a structure that is quite different from the structure that was depicted in the conceptual models with a diagramming technique. This makes the simulation models hard to recognize for the stakeholders and hard to verify for the simulation model builders. This paper will show a new way to support business process simulation, which enables fast translation of a con-

44 SIMULATION

Volume 79, Number 1

ceptual model into a simulation model. The gain in speed and the similarity between the conceptual model and the empirical model are valuable as is but also ease the possibilities for verification and feedback by stakeholders. The paper first describes a modeling method and introduces a conceptual modeling technique for business engineering. Second, the functional requirements for a simulation tool for quantitative analysis of as-is and to-be models are described. Third, a prototype of a support tool is presented and applied in an example case. The paper concludes with a discussion and directions for further research. 2. Modeling for Business Engineering A systems approach is adopted as the basis for modeling organizational processes and coordination. A system is defined as a nested structure of objects that exchange information [20, 21]. Organizations and business processes can be seen as purposeful systems, acting to achieve a certain goal [20]. The description of a system (and therefore also of an organizational system) is given by a conceptual model of each of its objects. During conceptualization, a consistent set of structure elements for describing the system is chosen as well as a modeling language to formally represent these structure elements. The initially vague knowledge of the system is translated into a written or schematized description, including the tentative system boundaries. For modeling purposes, the object-attribute-action worldview is an example of a fruitful way to conceptualize the system [22]. This worldview fits seamlessly with the systems view described above as it incorporates the notions of actor (i.e., objects) and actions (resulting in information exchange). Using the object-attribute-action worldview, the structure of the system is modeled by identifying the discrete objects in the system and describing their properties in terms of attributes and their behavior in terms of actions. The attribute part contains data elements describing the state of the object. The action part contains the tasks and decisions that reflect the possible behavior of an object. The object structure, attributes, and actions have a close relation to the structure, properties, and activities of elements we encounter in the business system that is being studied, and the object-attribute-action worldview allows for depicting any level of detail needed for modeling complex organizational processes. It should be noted, however, that a model is always a reduction of the real-world complexity and therefore cannot contain a valid representation of all system aspects we encounter in reality. A choice for the aspects that should be taken into account for solving business engineering problems is therefore worked out in the following section. 2.1 The Conceptual Model The conceptual model within business engineering describes the structure of the organizational processes and their coordination. It also defines the boundary between

CONCEPTUALIZATION AND SIMULATION OF BUSINESS PROCESSES

the system being redesigned or engineered and the environment. The object-oriented modeling method mentioned above is used as a basis for describing the business system. For objects to cooperate or coordinate the actions of other objects, the objects need to communicate. Therefore, an organization can be seen as a nested structure of communicating objects. A number of generic object classes that help to structure the conceptual model of an organization can be distinguished [13, 14]. For describing organizational processes and their coordination, a distinction between active objects and passive objects can be quite useful. Active objects or item processors carry out activities and (mutually) communicate. Passive objects, also called items, do not carry out actions themselves and only have attributes that describe their properties. In a sense, passive objects are being communicated between active objects. Properties of passive objects are changed by the activities of the active objects. An activity can also be seen as an object, describing how the actions of the item processors are actually carried out. These three object definitions constitute the basic classes, from which a number of more detailed object classes can be derived. The resulting object hierarchy is depicted in Figure 1. We derive three types of items from the generic item class: messages, products, and persons. A message stands for a collection of information, a product stands for physical matter, and a person can be considered as an item when the modeler chooses to depict the person as a passive object without activities. An example of a passive person could be a patient in a hospital when the flow of patients is modeled without the patients carrying out tasks or making decisions. When looking at the item processor, two classes are derived: a node that is a place where items can be processed or stored and a link that represents a communicating relationship between two nodes. When a node processes information, we call it an actor (e.g., an office worker); when it just stores information, we call it a repository (e.g., a database). Each item processor can carry out actions, modeled as activity objects. An activity can be a decision, which is a choice between two or more courses of action or a task that describes that course of action. An activity can be modeled in a hierarchical way, and it can consist of several subactivities. Extensive coverage of the object classes and the rationale behind the choices can be found in de Vreede [14]. When these classes are used to make a conceptual model of a specific system, it would be hard to understand the model when just the object descriptions would be created. Therefore, three graphical aspect models are defined, which bring together a number of the model elements in a graphical way. This makes it much easier for the modeler to view the relations between the classes that are derived from the basic model in Figure 1. The three aspect models we define are the following: • the network model, specifying the formal and informal

communication and interaction between the nodes in a process; • the process model, specifying the sequence of activities in a process carried out by the nodes of the network model (the use of hierarchy for modeling activities leads to several neatly arranged diagrams); • the actor model, specifying the sequence of activities of a single actor in the system.

We want to stress that the aspect models can all be directly derived from the underlying object model. In other words, the aspect models are merely different visualizations that highlight particular characteristics of the modeled business process. It is up to the modeler to decide to which level of detail each aspect model has to be constructed. 2.2 The Empirical Model The empirical model is derived from the conceptual model, and it gives a more detailed specification of the modeled situation. It should have a high degree of correspondence with the organizational processes as perceived in reality [23]. One should also be able to experiment with the model and get quantitative results when studying the current system or alternatives for the system. The dynamics of the business system should be represented in a good way. Simulation modeling is one of the best candidates for serving this purpose, and taking advantage of simulation tools is described as one of the prospective best practices in business process design [24]. A rough framework for using simulation for business process redesign has been sketched in Giaglis and Paul [17]. Examples for the use of general-purpose simulation tools for business engineering have been described as well [13, 14, 25, 26]. Many authors have proposed requirements for business process modeling tools (see, e.g., Paul, Giaglis, and Hlupic [19]; Spurr et al. [15]). A comprehensive list of ideal properties to a tool for business process design has been compiled by Davenport [10, p. 206]. This list is consistent with empirical findings in Hlupic and Robinson [27] and Kettinger [28]: • graphically portraying the process steps; • depicting the flow of materials and information between these steps; • accepting and portraying flow rate, resource and time consumption, and capacity and/or trigger information for each step; • rolling up or exploring the steps of the process in a hierarchical fashion to accommodate varying levels of detail; • presenting a highly interactive and preferably graphical user interface; • running live simulations and producing real-time graphical output; • identifying key bottlenecks and constraints in the processes; • linking to data and procedure modeling aspects of the CASE tool set to be used in information technology (IT)– based systems design. Volume 79, Number 1

SIMULATION

45

de Vreede, Verbraeck, and van Eijck

Basic classes

Item

Item ProcessoH

Network Link classes

Message

Product Person Item Classes

Activity

Node

Actor Repository Node Classes

Task Decision Activity Classes

Figure 1. Object hierarchy for conceptual modeling

Many of these properties can be found in discrete event simulation tools or libraries especially developed for business process modeling. To carry out successful simulations for business engineering, an empirical model should consist of the following elements: simulation code, empirical data about item properties and activity times, and an experimental design for testing different settings of parameters for the model [22]. This paper focuses on the construction of the simulation part of the empirical model. To arrive at a simulation model of the processes under investigation, the following steps should be taken (this is also referred to as the specification process): 1. Specify output variables to enable a comparison between the empirical model and reality and between the empirical model and models of alternatives. Output variables measure the organizational performance as displayed by the model. 2. Specify model reductions to reduce the complexity of reality as displayed in the conceptual model. An example is the introduction of stochastic variables instead of deterministic ones. In fact, any model is itself a reduction reflecting the specific interests and perspectives of the modeler. It is, however, important to specify these reductions to prevent major model inaccuracies. 3. Collect empirical (input) data to instantiate the object classes of the conceptual model. Realistic input data are of great importance in building a model that shows sufficient correspondence. Sometimes it is hard to obtain this information, which usually takes more time than expected. 4. Construct a simulation model based on the results of the previous steps. 5. Construct an animation of the simulation model, if necessary. Modern simulation environments feature animation facilities that serve as a communication vehicle, verification device, and presentation tool [29]. 46 SIMULATION

Volume 79, Number 1

6. Specify initial treatment for validation purposes. A fully specified treatment enables the modeler to run the simulation model. A treatment of a simulation model consists of a specification of input data, a collection of input data and initialization conditions, run control conditions, and a specification of output data [30].

3. Simulation Support for Business Process Modeling Traditionally, building a simulation model has been a timeconsuming and complex activity. A direct mapping of the conceptual model elements to simulation code is seldom possible. To support the transition from a conceptual to a simulation model, early efforts focused on a structured procedure to translate conceptual object definitions into simulation code [13]. Later research focused more on providing libraries of tailored simulation building blocks that closely match the elements of the conceptual model [14, 31]. However, when there are even slight differences in the constructs of the conceptual model and those of the simulation language, the translation of the conceptual model into the library constructs is also difficult and, in the case of nonextendable libraries, sometimes even impossible. Examples of business process modeling libraries for traditional simulation languages are BP$im for Arena, ProcessModel for ProModel, SimProcess for Modsim, and Extend+BPR for Extend [16, p. 826]. In our case, it proved to be difficult to use one of these libraries because there are vast differences between our conceptual model and the concepts underlying the available simulation libraries. In our case, we wanted to simulate the concepts of the network model, process model, and actor model introduced earlier in this paper. To reduce the translation gap between the conceptual and the empirical model, the simulation library elements should follow our object hierarchy for organizational modeling as closely as possible. This poses a set of requirements on the simulation library to be developed, which will be worked out in more detail below.

CONCEPTUALIZATION AND SIMULATION OF BUSINESS PROCESSES

3.1 Functional Requirements for Business Process Modeling The building blocks in the business process simulation library should be natural extensions of the conceptual building blocks of Section 2. The core of the conceptual models is the set of actors who perform tasks and the repositories that store items. So the basic structure of the conceptual model is reflected in the network model. In our view, the construction of a simulation model should start with a specification of the network model. This involves the following building blocks: actor, repository, link, and item. Although the items are passive objects, they flow through the organizational network and, in a way, keep the simulation model “alive” and trigger the activities that the actors should carry out. To be able to specify the activities an actor performs, we need the following building blocks: activity (for compound tasks), task (for simple tasks), and decision. At the system boundaries, items are generated and disposed of. The generation and disposal of items are in fact reduction operators, mapping the processes outside the system boundaries in a simple way. We need two constructs to achieve these reductions in a simulation model: an item generator and an item disposer. When the above constructs are available in a simulation library, the elements of our conceptual modeling approach are available to construct a simulation model. The constructs available in the simulation library will be called modules. Below, the functional specifications of the actor, link, item, activity, task, and item generator modules are described. The specifications are numbered and start with the first letter of the module name, followed by their type: basic functions that a module performs, (denoted by F); different ways in which a module can be used apart from its basic functionality, called options (denoted by O); the way in which performance indicators related to the module are specified, called statistics (denoted by S); and the way in which the module appears on the screen when the simulation model is running (i.e., the animation) (denoted by A). 3.1.1 The Actor Module The actor is the central object and is active in the sense that he or she can carry out tasks and take decisions. However, these tasks and decisions can be the same for different actors, so within the actor module there should only be a reference to the tasks he or she may carry out and the conditions under which these tasks are executed. The actor module should be able to receive and send items and also fetch items from repositories when necessary (see Table 1). From a simulation viewpoint, however, the actor also functions as a resource, as he or she has a limited capacity and can carry out only one task at a time. In the implementation, this dual character of the actor needs to be taken into account.

3.1.2 The Link Module The link is a simple module and just transfers items between actors and repositories or between actors (see Table 2). 3.1.3 The Item Module The item is a passive object and performs no actions of its own. Therefore, it has no functions or options, only statistics requirements and animation features (see Table 3). 3.1.4 The Activity Module When it is compound, the activity module encapsulates several tasks and decisions that an actor may carry out. When it is simple, it assumes the functionality of a task. In an actor module, there may be references to several activity modules; each reference is then related to specific conditions. An activity can be used by one actor or by several actors at the same time. Because the letter A was reserved for the actor, the requirements code of the activity module starts with Y (see Table 4). 3.1.5 The Task Module Tasks transfer specified preconditions into specified postconditions by changing attribute values of the item that is being processed or the values of global variables in the model. Meanwhile, they keep the concerned actor busy during the specified time delay (see Table 5). In that way, the tasks are the processes that claim actor resources and release them after the task has been finished. 3.1.6 The Item Generator Module The item generator establishes a part of the system boundary. It generates and initializes the attribute values of the items. After an item is generated, it is sent to a first destination (i.e., an actor or a repository) across a link (see Table 6). Items can be generated according to a probability distribution or after a keystroke. The keystroke option is created for verification and gaming purposes. 3.2 Generic Requirements for Specification Support When selecting a simulation environment to implement the business process simulation library, several generic requirements also need to be taken into account. When looking at the generic simulation literature [16, 22, 32] and the specific requirements for the specification process, the following requirements can be deduced. All requirements are coupled to the steps of the specification process of Section 2.2. 1. Specify output variables. To measure the performance of a modeled situation, it should be possible to specify the following types of output variables: throughput times between specified time stamps or Volume 79, Number 1

SIMULATION

47

de Vreede, Verbraeck, and van Eijck

Table 1. Specifications of the actor Functions AF.1 Taking items from one or more links, thereby seizing a resource AF.2 Giving items access to activities, keeping the resource seized AF.3 Sending items to one or more links that take items to their destination Options AO.1 Selecting between activities, including externally defined activities AO.2 Generating copies of items AO.3 Handling prioritized items AO.4 Accessing repositories AO.5 Temporarily changing the capacity (breaks, etc.) Statistics AS.1 Keeping track of capacity utilization AS.2 Keeping track of the average number of items in queue AS.3 Keeping track of maximum and minimum number of items in queue AS.4 Keeping track of the average throughput time of items with the actor AS.5 Keeping track of the minimum and maximum throughput time of items Animation AA.1 Displaying the actor’s status AA.2 Displaying the queue in front of the actor AA.3 Changing the appearance of items

Table 2. Specifications of the link Functions LF.1 Transferring one or more items Statistics LS.1 Keeping track of the number of items transferred by the link LS.2 Keeping track of the capacity utilization of the link Animation LA.1 Showing the transfer of items

Table 3. Specifications of the item Statistics IS.1 Average throughput time of an item between preset events IS.2 Maximum and minimum throughput time of items Animation IA.1 A visualization of the movement of an item between active objects IA.2 A visualization of the item itself and the changes it may undergo

Table 4. Specifications of the activity Functions YF.1 When compound, give item access to underlying tasks and decisions YF.2 When simple, assume functionality of the task (see below) Options YO.1 An activity can be either compound or simple

48 SIMULATION

Volume 79, Number 1

CONCEPTUALIZATION AND SIMULATION OF BUSINESS PROCESSES

Table 5. Specifications of the task Functions TF.1 Transfer specified preconditions into specified postconditions TF.2 Keep the concerned actor busy during the specified time delay

Table 6. Specifications of the item generator Functions IGF.1 Generating items IGF.2 Assigning values to attributes of items IGF.3 Sending items to one or more links that take them to their destination Options IGO.1 Generation of items according to a probability distribution IGO.2 Generation of items after a keystroke Statistics IGS.1 Keeping track of the total number of items generated Animation IGA.1 Show the generation of items

events (e.g., throughput time of an activity), process times of specific tasks or processes, queue lengths, capacity utilization of actors, and values of attributes and global variables. The simulation environment should be able to measure their average, maximum, minimum, end value, variation, and frequency distribution. 2. Specify model reductions. Reduction operators refine and extend the attribute and action parts of the objects as identified in the conceptual model. As to the attribute parts, specification support should allow reduction operators of the following kinds within the resulting simulation model: • operators that replace deterministic attribute values by stochastic values (e.g., the duration of a specific task can be modeled by a normal distribution), • operators that course the range set of attribute values.

As to the action part, specification support should allow reduction operators that replace repeating tasks or event sequences by functions or procedures that can be invoked by one or more objects. Furthermore, the specification method should allow the reduction of relevant objects that lie outside the borders of the system studied. This can be done, for example, by means of item generators and item disposers. 3. Collect input data. Where necessary, the item generators should be able to use external data to control the

generation process or read the item attributes from external data sources in case we want to replay an existing situation based on real data. 4. Construct the simulation model. The specification support tool should provide constructs that specify the attribute and action parts of the objects as identified in the conceptual model, taking the reduction operators as specified above into account. It should also provide an environment in which simulation models can be constructed in much the same way as the conceptual models are constructed: placing individual objects on the screen and connecting them in the right way. Furthermore, the specification environment should not restrict the user merely to the use of the predefined building blocks. It should, for example, be possible to use simulation constructs already provided by other templates or to extend the building blocks for personal use. 5. Construct animation. Each building block should have an animation part that can be specified by the modeler. This animation component should include a visualization of the behavior of the object itself, as well as the possible handling and routing of items to another object (e.g., the animation should display the functioning of repositories as well as the reception, storage, and routing of items). 6. Specify initial treatment. Within the simulation model, it should be possible to specify the input data, the initialization conditions, and the run control Volume 79, Number 1

SIMULATION

49

de Vreede, Verbraeck, and van Eijck

conditions. Together with the earlier mentioned specification of output data, the model can then be used for verification and validation purposes. Furthermore, it should be possible to expose the simulation model to different treatments and perform sensitivity analyses with it.

3.3 The Arena Simulation Environment Based on the functional and generic requirements, the simulation language Arena [32] was chosen to implement the support environment for business process simulation. The Arena simulation environment allows a modeler to develop a library of building blocks and to construct a simulation model from these predefined building blocks [32, 33]. The complexity of the building blocks ranges from simple statements of the simulation language to very complex constructs such as servers, conveyor belts, and automatically guided vehicles. The building blocks are presented as modules in a template. A simulation model is then constructed by dragging the modules from the template onto the modeling screen, connecting them, and entering the right data in the user interface of the module, which satisfies generic requirement 4. The notion of predefined modules also conforms to the distinction between object class (i.e., an “empty” module consisting of logic and “empty” attributes) and object instance (i.e., a copy of a module containing specific data as attribute values). An example of this is the server module of the standard Arena template. When selected, the server is empty and represents the object class server. The server is instantiated by giving it a name (e.g., Employee_01) and by entering empirical data into the input fields of its user interface. With the Arena professional edition [34], it is possible to define templates and to create specific modules that can be seen as specific object classes that can be instantiated in a model. This user-defined template can be used in conjunction with other predefined templates because the templates function as a kind of “macro” that converts the template building blocks to the lowest level Arena building blocks (i.e., SIMAN simulation statements). Each template can be given a user interface, in which the user can set the values for the instance of the building block. The template building blocks can be made smart in the sense that parts that are not needed but given a user input are not translated into low-level simulation statements. This so-called conditional compilation can keep the resulting model small, although the model has been built from rich and extensive modules that contain the code for all user settings. Finally, Arena is a general-purpose simulation environment that also satisfies all the stated generic requirements. Arena is capable of providing numerous indicators using standard statistical building blocks such as TALLY, DSTAT, and COUNT (requirement 1). Every simulation language, including Arena, is able to work with variables 50 SIMULATION

Volume 79, Number 1

drawn from stochastic distributions, and every simulation language contains artifacts that can be placed on the model border to generate or dispose dynamic objects (requirement 2). Arena provides means to read data from Excel or from files. Via Visual Basic, data can also be read directly from databases (requirement 3). Arena was especially chosen because of the graphical support for the user in the model building process. Drag-and-drop and connecting building blocks are core to the Arena simulation environment (requirement 4). One of the advantages of the Arena template building blocks is that the animation to be shown in the model can be created as an integral part of the building block itself. By placing the building block on the screen, the default animation that shows the dynamic behavior of the building block is also instantiated (requirement 5). With Arena, as with most simulation languages, the treatment information, run length, number of runs, and model initialization period can be specified (requirement 6). 4. A Prototype for Business Process Simulation in Arena A prototype of the simulation template was constructed based on the above requirements and functional specifications. The prototype was implemented in version 5.0 of the Arena Professional Edition. The prototype consists of seven modules, grouped in a template that can be attached to Arena: • • • • • • •

Actor module Repository module Activity module Task module Decision module Item generator module Item disposer module

Next to these modules, the regular Arena modules can also be used. Of course, the model builder has to take into account that a number of attributes, variables, stations, and statics are used for specific purposes in the template modules and are not to be used freely. We defined no module for the link object. The beginning and end points of a link are implemented as stations within the actor and the repository module. The connection between these beginning and end points is established by taking a route from the animation template that is part of the simulation environment. In that way, both instant connections between tasks—a route time equal to zero—and transfers that do take time can be modeled. The item object is not implemented as a module either. Items and their attributes are provided by the simulation engine itself and are generated by the item generator module. Each module has been implemented by carrying out the following steps [34]: • The construction of a user interface. The functionality is implemented by specifying the windows and window entries that should be presented to the user.

CONCEPTUALIZATION AND SIMULATION OF BUSINESS PROCESSES

Table 7. Implementation of the specification tool Module

Functions

Actor

AF.1 AF.2 AF.3

Link

LF.1

Options √ √ √

AO.1 AO.2 AO.3 AO.4 AO.5

Statistics √ √ U √ U

@

Item Activity Task Item generator Note.

√

YF.1 YF.2 TF.1 TF.2 IGF.1 IGF.2 IGF.3

√ √ √ √ √ √ √

YO.1

IGO.1 IGO.2

√

√ √

Animation √ √ √

AS.1 AS.2 AS.3 AS.4 AS.5 LS.1 LS.2 IS.1 IS.2

@ @ @ @ √

AA.1 AA.2 AA.3

U U U @

LA.1

@

IA.1 IA.2

@ @

IGS.1

@

IGA.1

√

= implemented; @ = provided by Arena; U = user code.

• The implementation of the module’s simulation logic. For the logic of a module, the language constructs of the simulation engine can be used. Within the simulation statements, references to entries in the user interface can be specified. • The specification of the module’s options (called switches). Specific options for a module can be specified in the user interface by means of check boxes and radio buttons. The Boolean variables that contain the options that are selected in a module have to be specified separately. • The construction of the module’s animation features. Each module has a basic appearance for animation purposes.

user coding, but because these statistics can easily be calculated by inserting one ASSIGN and one TALLY block, no special objects were created in the library to gather these statistics. The effort needed to implement the template was about 10 person weeks in total, after the conceptual model had been completed. We spent 7 weeks on the initial design and building of the seven modules. One week was spent on reviewing and testing the models. In the final 2 weeks, the insights from the tests were evaluated, and several improvements were built into the modules. 5. An Example Application of the Library

For simple models, this template is all that is needed to construct a model. For more complex models, it is possible to attach other templates, provided by the Arena environment, that contain lower level or higher level building blocks. Table 7 shows which elements of the functional speci√ fication are implemented in the template. A represents the fact that an element of the functional specifications was implemented, and an “@” indicates that an element was automatically provided by Arena. Two of the options of the actor have to be implemented by using standard Arena building blocks, indicated by a “U” in Table 7. These are the handling of prioritized items (AO.3) and temporary capacity changes (AO.5). Both options are easy to implement by the modeler by setting the priority in a separate ASSIGN block and by using the ALTER block to change the availability of an actor. These building blocks from the standard Arena templates can be inserted by the modeler into the activity specification between successive tasks and decisions. Because the statistics functionality was already strongly supported by generic Arena building blocks, the implementation of statistic support in the prototype did not take much effort. Three types of statistics also need some

To test the library, we used a real example of three service engineers who electronically request service assignments from a database and carry these out. A secretary answers phone calls from clients—who are modeled as an item generator—and determines the problem to be able to assign a service engineer to the job. The job is put into a database for later retrieval by the engineer. When an engineer has finished the job, he or she sends a report to the service desk, modeled as an exit point. The network model of this example is given in Figure 2 and the implementation in the template in Figure 3. In the network model, circles represent actors or repositories, arrows represent links, and triangles represent items. The “M” in the triangles indicates that the items are messages. As can be seen, the template enables us to create a simulation model that strongly resembles the conceptual model. Also in modeling the activities of actors, the simulation model stays close to the conceptual model. This is shown in Figure 4, depicting the actor model of an engineer for the compound activity “fix system” and the specification of the activity in terms of tasks and decisions. The rectangles in the actor model represent tasks, the circles represent Volume 79, Number 1

SIMULATION

51

de Vreede, Verbraeck, and van Eijck

Engineer 1

Engineer 2

Engineer 3

A

A

A Assignment Info Assignment Info

M

M

Service desk

Assignment Info

A Reports

M

M

R

A

A

Assignments Assignment database

Figure 2. Network model of the service engineers example

Figure 3. Arena view of the network model

52 SIMULATION

Complaints

M

Volume 79, Number 1

M Secretary

Clients

CONCEPTUALIZATION AND SIMULATION OF BUSINESS PROCESSES

A

Drive to client

Activity

Task

Investigate system

Task

Drive to client

Investigate system

Type of system ?

Decision Type A

Type of system

Type B

Fix type A system

Fix type B system

Task Write service note

Fix type A system Fix type B system

Task

Task

Write service notice

Figure 4. Actor model and corresponding specification in the business process template

decisions, and the arrows represent the precedence relationship between these two constructs. With the template, it is possible to model an actor model only once and apply it to multiple actors. This facilitates the specification of groups of actors who carry out the same task. In the example, this means that the actor model of an engineer is specified only once. Within each instance of an engineer, there is a reference to the corresponding actor model. One of the big advantages of the template implementation is that the flow-oriented character of the task structure and network model can be depicted almost one-to-one in the simulation model. The simulation model has in that sense almost become the conceptual model of the system that is studied. When taken one stage further, the conceptualization activities for business process modeling could be supported by the same tool as the dynamic simulation and capacity analysis.

6. Evaluation and Conclusions In the first section of this paper, it was indicated that time is a scarce resource in business engineering projects. Although simulation seems to be an ideal tool to analyze current and future business processes in a quantitative manner, much time is usually lost in translating conceptual models into simulation models. The library-based approach, which has been presented in this paper, solves this problem. The translation between the conceptual business model and the simulation model is one-to-one, enabling even automatic translation. Because the internal code of the building blocks in the library has been verified already, the simulation model builder does not have to spend time on verifying the simulation code. The valuable time of the business engineering team can be used to get the concepts right instead of getting the simulation code right. In Section 2.2, the requirements for a business process design tool were defined [10, 15, 19]. When comparing

Volume 79, Number 1

SIMULATION

53

de Vreede, Verbraeck, and van Eijck

these properties to the business process simulation library in this paper, it is clear that the simulation models built with the library satisfy these requirements. The model is graphical and portrays the process steps, called “tasks” in our approach. The flow of information between tasks can be shown using the animation. The fact that the animation can be stopped or slowed down can be a big help for the business engineering team to identify bottlenecks. Statistics about time consumption are gathered both for the actors and for the items. Models can be detailed hierarchically, and the user interface is interactive and graphical. Properties of each of the building blocks can be changed easily by double clicking on the building block and modifying the parameters in a pop-up screen. Finally, the resulting model is a simulation model in a simulation environment that gives us all the advantages of the simulation environment for using stochastic distributions, specifying treatments, analyzing results, and generating reports. The more specific requirements we posed for the tool in Section 3.1 have also been satisfied. Table 7 clearly shows that all the functionality needed is provided by building developed blocks, by standard Arena functionality, or by using a very limited number of standard Arena blocks that can be inserted between the blocks provided by the template. The template has been used in several cases and works fine. During the projects carried out with the template, another interesting advantage of use of the template became apparent. The building blocks in the library determine the full set of parameters that is needed to get the model working. In a normal business engineering simulation project, data requirements grow slowly during the implementation, and the organization has to be approached over and over again to provide new data. The approach presented in this paper benefits not only from the one-to-one translation of the conceptual model into a simulation model but also from the decreased effort put into gathering data. 7. References [1] Dickson, G. W., and G. DeSanctis. 2001. Information technology and the future enterprise: New models for managers. Mahwah, NJ: Prentice Hall. [2] Fulk, J., and G. DeSanctis. 1995. Electronic communication for changing organizational forms. Organization Science 6 (4): 33749. [3] Lewin, A. Y., and C. U. Stephens. 1993. Designing post-industrial organizations: Theory and practice. In Organization change and redesign, edited by G. P. Huber and W. H. Glick, 393-409. New York: Oxford University Press. [4] Burns, T., and G. Stalker. 1961. The management of innovation. London: Tavistock. [5] Huber, G. P., and R. McDaniel. 1986. The decision making paradigm of organizational design. Management Science 32 (5): 572-89. [6] Mintzberg, H. 1979. The structuring of organizations. Englewood Cliffs, NJ: Prentice Hall. [7] Malone, T. W., and K. Crowston. 1994. The interdisciplinary study of coordination. ACM Computing Surveys 26 (1): 87-119. [8] Thompson, J. D. 1967. Organizations in action. New York: McGrawHill.

54 SIMULATION Volume 79, Number 1

[9] Hammer, M., and J. Champy. 1994. Reengineering the corporation. London: Nicholas Brealy Publishing. [10] Davenport, T. H. 1993. Process innovation: Reengineering work through information technology. Boston: Harvard Business School Press. [11] Galliers, R. D. 1995. The place of information technology and radical/incremental change in business process redesign. In Business process change: Reengineering concepts, methods and technologies, edited by V. Grover and W. J. Kettinger, 125-42. Harrisburg, PA: Idea Group Publishing. [12] Grover, V., and W. J. Kettinger, eds. 1995. Business process change: Reengineering concepts, methods and technologies. Harrisburg, PA: Idea Group Publishing. [13] de Vreede, G. J., D. T. T. van Eijck, and H. G. Sol. 1996. Dynamic modeling for re-engineering organizations. Journal of Information Systems and Operational Research (INFOR) 34 (1): 28-42. [14] de Vreede, G. J., and D. T. T. van Eijck. 1998. Modeling and simulating organizational coordination. Simulation & Gaming 29 (1): 60-87. [15] Spurr, K., P. Layzell, L. Jennison, and N. Richards, eds. 1993. Software assistance for business re-engineering. Chichester, UK: Wiley. [16] Banks, J. 1998. Handbook of simulation. New York: John Wiley. [17] Giaglis, G. M., and R. J. Paul. 1996. It’s time to engineer reengineering: Investigating the potential of simulation modeling for business process redesign. In Business process modeling, edited by B. Scholz-Reiter and E. Stickel, 313-32. Berlin: Springer-Verlag. [18] Nidumolu, S. R., N. M. Menon, and B. P. Zeigler. 1998. Objectoriented business process modeling and simulation: A discrete event system specification framework. Simulation Practice and Theory 6:533-71. [19] Paul, R. J., G. M. Giaglis, and V. Hlupic. 1999. Integrating simulation in organisational design studies. International Journal of Information Management 19 (3): 219-36. [20] Ackoff, R. L., and F. E. Emery. 1972. On purposeful systems. Chicago: Aldine-Atherton. [21] Checkland, P. B. 1981. Systems thinking, systems practice. Chichester, UK: Wiley. [22] Sage, A. P., and W. B. Rouse, eds. 1999. Handbook of systems engineering and management. New York: John Wiley. [23] Bots, P. W. G. 1992. Modeling for organizational change: From problems to objects to solutions. In Proceedings of HICSS-25: Vol. 1. Architecture and emerging technologies, edited by V. Milutinovic and B. R. Shriver, 568-77. Los Alamitos, CA: IEEE Computer Society Press. [24] Carr, D. K., and H. J. Johansson. 1995. Best practices in reengineering. New York: McGraw-Hill. [25] Giaglis, G. M. 1999. On the integrated design and evaluation of business processes and information systems. Communications of the AIS 2 (5). [26] Paul, R. J., G. M. Giaglis, and V. Hlupic. 1999. Simulation of business processes. American Behavioral Scientist 42 (10): 1551-76. [27] Hlupic, V., and S. Robinson. 1998. Business process modeling and analysis using discrete-event simulation. In Proceedings of the 1998 Winter Simulation Conference, edited by D. J. Medeiros, E. F. Watson, J. S. Carson, and M. S. Manivannan, 1363-70. Los Alamitos, CA: IEEE Computer Society Press. [28] Kettinger, W. J., and J. T. C. Teng. 1997. Business process change: A study of methodologies, techniques, and tools. MIS Quarterly 21 (1): 55-80. [29] de Vreede, G. J., and A. Verbraeck. 1996. Animating organizational processes: Insight eases change. Simulation Practice and Theory 4:245-63. [30] Ören, T. I., and B. P. Zeigler. 1979. Concepts for advanced simulation methodologies. SIMULATION 32 (3): 69-82. [31] Fishwick, P. A. 1995. Simulation model design and execution: Building digital worlds. Englewood Cliffs, NJ: Prentice Hall.

CONCEPTUALIZATION AND SIMULATION OF BUSINESS PROCESSES

[32] Kelton, W. D., R. P. Sadowski, and D. A. Sadowski. 2002. Simulation with Arena. 2d ed. New York: McGraw-Hill. [33] Pegden, C. D., R. E. Shannon, and R. P. Sadowski. 1995. Introduction to simulation using SIMAN. 2d ed. New York: McGraw-Hill. [34] Systems Modeling Corporation. 1994. Arena professional edition reference guide. Sewickley, PA: Systems Modeling Corporation.

the Department of Information Systems and Quantitative Analysis at the University of Nebraska at Omaha.

Gert-Jan de Vreede is with the Faculty of Technology, Policy, and Management at the Delft University of Technology, the Netherlands, and the College of Information Science and Technology in

Daniel T. T. van Eijck is with the ABZ Branche Initiatieven b.v., Zeist, the Netherlands.

Alexander Verbraeck is with the Faculty of Technology, Policy, and Management at the Delft University of Technology, the Netherlands, and the University of Maryland, Robert H. Smith School of Business, College Park, Maryland.

Volume 79, Number 1

SIMULATION

55