1 Introduction

Analysis of the performance and feasibility of business processes is important to evaluate the effects of business process reengineering and redesign efforts [6]. In order to assess the performance of these business process models, simulation is often used. However, Recker [15] shows that more research into the simulation of business process models is needed.

First, business process simulation engines should take into account basic simulation parameters, as described in the standard work on simulation by Law and Kelton [12]: each simulation engine should support a warm-up period, replications and confidence intervals. A warm-up period ensures correct simulation results, since the empty system at the beginning of the simulation can pollute the final performance of the model. In order to obtain confidence intervals using the central limit theorem, replications need to be in place in the simulation engine.

Second, a strong resource perspective is needed to ensure that the process models correctly represent reality. However, we will show in Sect. 2 that commonly used business process simulation engines have problems coping with advanced resource constructs, such as resource dependencies and queueing strategies. We focus on simulation engines that use the Business Process Model and Notation (BPMN) [14], because this has become the de-facto standard for modeling business processes. BPMN mainly focuses on the control-flow perspective of a process, while the resource perspective in the BPMN language is limited to the lanes and pools concepts [19]. In contrast, business process execution languages like YAWL [20] have extensive support for the resource perspective, which indicates that there is a need for supporting the resource perspective. The advanced resource patterns used in these execution languages are also defined in Russell et al. [18].

The consequence of the shortfalls of BPMN simulation engines, is that the results obtained by them will be less valid for the real-life process that is simulated. In our evaluation we will indeed show that BPMN models, in which advanced resource patterns are not included, have simulation results that deviate significantly from models, in which they are included. Consequently, we can conclude that BPMN models cannot be used to draw valid conclusions for business processes from practice that use advanced resource constructs, such as the case handling principle.

Therefore, the aim and contribution of this paper is to present the conceptual model and behavior of a simulation engine that supports the advanced simulation requirements outlined above. We also present a prototype implementation of this engine. This contributes to laying the foundation for the simulation of complex business processes with the complete inclusion of resources for real world processes, which can enhance business process engineering and redesign efforts.

Against this background, the remainder of this paper is structured as follows. Section 2 describes the state of the art of existing business process simulation engines. In Sect. 3 an extension of process models is proposed to make them fit for simulation purposes, solving the limitations of the existing models. In Sect. 4 the formal behavior of the new simulation engine is provided by means of a state-space and state-space transitions. Section 5 describes the implementation of the simulation engine from Sect. 4 and the evaluation of the engine. The focus in this section is on the effect of resource dependencies on the utilization of resources. In Sect. 6 the conclusion based upon the evaluation of the new simulation model is presented and future work is discussed.

2 Related Work

Table 1 provides the overview of the support of existing simulation engines for advanced simulation concepts. In order to assess the selected simulation engines, several criteria are taken from literature. These criteria focus on the support a simulation engine provides for the simulation of business processes with a special focus on the resource perspective. For each feature available in a tool there is a + symbol. If a feature is not available in a tool a – symbol is used. For cases where a feature can be found, but only in the form of a complex workaround or in a limited manner, there is a ± symbol.

Table 1. Analysis of simulation engines
Full size table

First basic flow criteria are assessed, based upon the paper of Van der Aalst et al. [24], three basic criteria are selected: sequence of activities, parallel execution of activities and branching or choice in activities. These have been chosen since these are in the top 10 of most used constructs [29]. Next to these basic flow criteria, the paper of Tumay [22] indicates that also activities and resources are basic elements in a simulation. Tumay [22] shows that each simulation needs an arrival process, also each activity can be associated with a duration and a cost function. The duration of an activity and arrival rate can consist of mathematical distributions. Activities can also require resources to be executed in the process model. Resources, according to the paper of Russell et al. [18], should be modeled having a certain capacity, role and schedule. Also resources may have costs of usage associated with them. Therefore all simulation engines are assessed on these criteria for activities and resources.

The paper of Russell et al. [18] also defines several different allocation strategies for resources, in this survey the focus will be on the constructs of separation of duties and case handling from the patterns defined. According to Russell et al. [18] separation of duties is described by as: “The ability to specify that two tasks must be allocated to different resources in a given workflow case” and case handling is described as: “The ability to allocate the work items within a given workflow case to the same resource”. The paper of Tumay [22] indicates that queueing strategies are important for the way entities are sequenced in queues at activities. Furthermore allocation strategies and case attributes are analyzed as important aspects in the simulation [18]. Next to these specific business process simulation properties, general properties of simulation engines will be reviewed in terms of duration of the simulation, ability to incorporate warm-up time, use of replications and the reporting of statistics making use of confidence intervals. These properties are prescribed by Van der Aalst et al. [23] as the main important properties to create a sound simulation experiment.

The simulation engines which are selected for this survey are composed of two types of tools: general purpose simulation tools and business process simulation tools, with the main focus on BPMN simulation engines. Based upon the paper from Jansen-Vullers and Netjes [7] two general purpose simulation tools are identified as Arena [9] and CPN Tools [8]. Furthermore all tools mentioned in the book Fundamentals of BPM [5] in Chap. 7.4.3 Simulation Tools will be assessed. Unfortunately ARIS, OpenText, Oracle and Savvion have no public available simulation tool to assess and therefore are excluded from the survey. Also the developed prototype as discussed in this paper will be scored on the criteria presented in Table 1.

As can be seen in Table 1 the two general purpose simulation tools perform quite well on mainly all aspects, only on the resource allocation rules they score a ±. In contrast the regular business process simulation tools perform worse on the resource allocation rules, where barely any advanced construct is supported. Furthermore there are major issues in general simulation properties, lack of confidence intervals, replications and warm-up periods makes most tools unfit for proper simulation according to the paper of Van der Aalst et al. [23]. General purpose simulation tools are less in favor than the business process simulation tools, which are easier to use and do not take a steep learning curve to model processes, since they use the BPMN modeling language [21, 27].

3 Advanced Simulation Model

The basic idea to simulating a business process model is to transform it into a queueing network [12]. In order to create that network, each activity in the BPMN model is transformed into a queue that contains cases on which that activity must be performed. Whenever the activity has been performed for a case in the queue, the case is put into the queue of the next activity that should be performed on it, conform the behavior that is described by the BPMN model.

In addition to this basic translation, which is common for all BPMN simulation engines, we propose constructs to simulate the following advanced constructs: case attributes, resource schedules, resources acting in multiple roles, queueing principles, resource dependencies, and simulation parameters. For illustration purposes, Fig. 1 shows a BPMN model that includes these advanced constructs. We explain these constructs in the following paragraphs.

Fig. 1.
figure 1

BPMN Model with advanced parameters

Full size image

3.1 Case Attributes

A case is an executable instance of a process, where each case can have certain attributes, also known as case data [28]. In practice, the choice between alternative paths through a process depends on the values of the case data. However, current simulation engines solve a choice between alternative paths by placing probabilities on the paths themselves. The benefit of associating alternative paths with the values of case data, is that this allows for interaction between multiple alternative paths to be captured.

To facilitate this, we define case attributes on the process level, where each attribute has a name and a value associated with it. Values for different attributes can be obtained from the probability distributions of the attributes as specified in the process model. Distributions can be either numerical or categorical, numerical distributions can be the normal distribution, the exponential distribution, the uniform distribution or a static value in this simulator. Categorical variables are uniformly distributed variables, where the attribute is assigned one of the values of the categorical variable. All values for the case are determined at the arrival of the case at the process. For example a case of an insurance claim process is of the category car (0.25), house (0.40) or travel (0.35) and has a certain amount of money claimed, which is normally distributed with an average of 1750 and a variance of 500.

3.2 Resource Schedules

According to Russell et al. [18] resources need to have a schedule. A schedule is an overview of the periods during which a resource is available for processing cases, also called the active state. When a resource is outside of the scheduled times, it is passive. During the time a resource is passive it will not actively participate in the execution of the business process. Each schedule is denoted by a chain of times in a day when a resource changes its state. For the first time in the schedule the resource becomes active and at each following event the state will change to passive if the resource was active and the state will change to active when the resource was passive. We will represent a schedule as a list of times at which the resource changes state from active to passive or vice versa, assuming that the resource starts passive, for example [08:00, 12:00, 13:00, 18:00]. Each resource will finish the last activity, if necessary in overtime, before becoming passive according to the schedule.

3.3 Resources Acting in Multiple Roles

According to Van der Aalst, Weske and Grünbauer [25] a resource can have multiple roles, based on the organizational model of the enterprise. To facilitate this, we define a resource as having a certain resource type, which is a list of roles belonging to a resource. A resource type can be a single role or a combination of multiple roles which exist in the same pool in a process model. Furthermore each of the resource types has an integer which represents the number of instances of the resource type. Each instance of a resource type is able to serve the roles which are associated with the type in the process and will stick to the order of the roles for prioritizing roles. For example if there are two roles, say A and B, resources can be of type [A], type [B], type [A,B] or type [B,A]. The quantities of resource types are defined as part of the process.

3.4 Queueing Principles

Queueing principles are the order in which a resource selects a case from a queue to handle it, this is also called the service discipline of the queue. The queue is the worklist which contains the work items offered to the resource. According to Righter et al. [16] queues can have different service disciplines, such as First In First Out (FIFO) and Last In First Out (LIFO). In the FIFO system the case first in the queue is also the first one to be handled by the resource. Where with the LIFO system the last case in the queue is handled first by the resource. Next to those two variants a random selection can be applied as a service discipline, in which the next case to be handled is selected randomly, or a priority system can be used to sort the queue according to the priority value of each case [12].

3.5 Resource Dependencies

Resource dependencies are specific dependencies on resource instances between activities in a process. From the paper of Russell et al. [18] two resource dependencies between activities can be identified: separation of duties (SOFD) and case handling (CASE). A resource dependency is an extra constraint on which resources may handle the activity. The separation of duties dependency yields that a different resource instances should execute the activities affected by the dependency. For the case handling dependency it is the other way around, it yields that the same resource instance should execute the activities affected by the dependency. Regularly each activity is not affected by any resource dependency and can be executed on its own by a resource instance. When there are resource dependencies between multiple activities for each activity in the dependency it should be denoted which type of dependency applies and which other activities are involved. For example if the activities A02 and A04 are subject to the resource dependency case handling both will have the resource dependency label CASE and the associated set of activities {A02, A04} in their properties denoted. If no resource dependency label is provided it is assumed that there is no resource dependency in the model for the given activity.

3.6 Simulation Parameters

In order to perform simulation, several main components should be defined in the BPMN model. According to Van der Aalst et al. [23] and Law and Kelton [12] the duration of the simulation, warm-up period, number of replications and confidence intervals are vital components of a simulation model. The warm-up period of the simulation is the amount of time where no performance metrics are recorded at the start of a simulation run [13]. This is needed because steady state simulation models start empty and idle, this empty state influences the performance metrics and therefore need to be corrected for. Replications are the repetition of a simulation with fixed inputs but different outputs due to different random number streams [3], these are needed to obtain reliable values for performance metrics. Using the values from the different replications confidence intervals can be computed using the central limit theorem [23]. These confidence intervals are a limited bandwidth where the actual value of a performance metric can be approached with a certain probability. These parameters should be set at the model level of a BPMN model in order to enable proper execution.

4 Advanced Simulation Behavior

In this section we formally define the behavior of a discrete event simulation that can simulate the concepts that are defined in the previous section. We define the behavior in terms of the statespace of a simulation model as it is specified in the previous section, the initial state of that model and the state transitions that the simulation model will take from the initial state.

The behavior is defined for the meta-model that is implicitly defined in the previous section and exemplified in Fig. 1. Due to space limitations, we only postulate the existence of the concepts that we need from the meta-model.

Definition 1

(Model Elements). Let \(\mathcal {I}\) be the set of all possible identifiers and \(id: \mathcal {I}\) the function that returns a new unique identifier. Furthermore, let \(\mathcal {L}\) be the set of all possible labels, \(\mathcal {V}\) be the set of all possible data values, \(\mathcal {S}\) be the set of all possible schedules and \(\mathcal {D}\) be the set of all possible probability distributions.

A simulation model defines a set of \(\mathrm {activities} \subseteq \mathcal {L}\) and a set of \(\mathrm {attributes} \subseteq \mathcal {L}\) by their labels. It describes a set of \(\mathrm {resourcetypes} \subseteq \mathcal {L} \times \mathbb {P}(\mathrm {activities}) \times \mathcal {S} \times \mathbb {N}\) (where \(\mathbb {P}\) represents the powerset), such that each resource type \((l, as, s, n) \in \mathrm {resourcetypes}\) has a label l, a set of activities as that a resource of that type can perform, a schedule s for the availability for resources of that type, and a number of resources n of that resource type. A schedule is a list of timestamps at which a resource changes state, a function to retrieve the next time of a state change is \(t = getnext(s, currenttime)\), which returns the next time in a schedule at which the resource changes state. In addition a simulation model describes: a processing time distribution for each activity a, denoted as \(\mathrm {dist}_a\), an interarrival time distribution, denoted as \(\mathrm {dist}_i\), and a distribution for the values of each case attribute d, denoted as \(\mathrm {dist}_d\). We define the existence of a function \(\mathrm {sample}:\mathcal {D}\rightarrow \mathcal {V}\) that samples a value from a distribution.

Furthermore, a BPMN model describes a behavior that can be defined in terms of a token-game, as explained for example in Van Gorp and Dijkman [26] and Dijkman, Dumas and Ouyang [4]. Here, we assume the existence of functions that implement the token game. These functions should be implemented conform the BPMN semantics, as defined in these papers.

Definition 2

(Model Behavior). Let \(\mathcal {M}\) be the set of all possible markings in a token game on a BPMN model. Given a particular model, there is: a function \(\mathrm {initialmarking}:\mathcal {M}\) that returns the initial marking of the model for a starting case, a function \(\mathrm {enabled}: \mathcal {M} \rightarrow \mathbb {P}(\mathrm {activities})\) that returns the set of activities that can happen in a given marking, and a function \(\mathrm {fire}: \mathcal {M} \times \mathrm {activities} \rightarrow \mathcal {M}\) that defines the marking to which a model transitions when a particular activity happens in a particular marking.

With these definitions, we can define the statespace of the simulation model. Since a discrete event simulation is based on a queueing network, we define an abstract ‘queue’ type.

Definition 3

(Queue). Let queue and \(queue'\) be two queues and e be a potential element of a queue, we postulate a the existence of functions and constants: [], which represents the empty queue; \(queue' = put(queue,e)\), which places the element e in the queue, resulting in a new queue (the exact position at which the element e is placed in the queue may depend on the queueing policy, e.g. in a FIFO queue the element e is placed at the end, but in a LIFO queue the element e is placed at the start); \(e \in queue\), which returns true is the element e is in the queue; \(e = first(queue)\), which returns the first element in the queue; \(queue' = removefirst(queue)\), which removes the first element from the queue; and \(queue' = remove(e, queue)\), which removes element e from the queue.

The parts of the statespace are: the queues that contain the cases that are queueing for a certain activity to be performed on it; the queues that contain the resources that are waiting to perform an activity that they can perform according to their resource type; a queue of simulation events that still have to occur in the simulation; and the current simulation time. Consequently, we define these elements as follows.

Definition 4

(Case, Resource, Event, Statespace). Let \(\mathcal {T}\) be the set of possible timestamps.

A case is a tuple (id, as), in which: \(id \in \mathcal {I}\) is a unique identifier; \(as \subseteq attributes \times \mathcal {V}\) is a set that assigns values to attribute labels for the case.

A resource is a tuple (id, rt), in which: \(id \in \mathcal {I}\) is a unique identifier; and \(rt \subseteq \mathcal {L}\) is the label of the resource type of this resource.

A simulation event is a tuple (t, type, i), in which: \(t \in \mathcal {T}\) is the timestamp at which the event is scheduled to occur; \(type \in \{\mathrm {Arrival},\mathrm {Complete}, \mathrm {Activate}, \mathrm {Passivate}\}\) is the type of simulation event, which can either be the arrival of a new case in the system, the completion of an activity for a case, an activation of a resource or pacification of a resource; and i is the information that is associated with the event, which is a case if \(type = \mathrm {Arrival}\), a resource if \(type = \mathrm {Activate}\) or \(\mathrm {Passivate}\), a tuple (r, c, a) if \(type = \mathrm {Complete}\), in which a is the activity that was just completed, r is the resource that was performing the activity and c is the case for which the activity was being performed.

By convention, we refer to elements of a tuple by the labels that are defined for them above. E.g. for an event e, \(e_\mathrm {type}\) refers to the type of e.

We can now define the statespace of a simulation model as follows.

Definition 5

(Statespace). The statespace is of a simulation model is composed of:

  • foreach activity a, a queue \(queue_a\) of cases that are queueing for that activity;

  • foreach resourcetype rt, a queue \(queue_{rt}\) of resources that are queueing to perform activities;

  • a queue \(queue_s\) of simulation events ordered by their timestamp with the event with the lowest timestamp first in the queue;

  • a function \( states : case \rightarrow \mathcal {M}\) that associates cases with their current marking in the BPMN model;

  • a set of \( assignments \subseteq resource \times case \) of resources currently working on a case;

  • the \( currenttime \) of the simulation model; and

  • a set \( passiveresources \) of resources that are passive.

An example of a statespace is provided in Table 2. Six cases and five resources are active in the model. For activities where no resource is available, the cases are queued in the activity queues. For resources where all associated activity queues are empty are queued in the resource queues. The marking is not specifically defined, we illustrate the marking as activities marked with cases.

Table 2. Example of a statespace
Full size table

We can now define the algorithms that set the initial state of the simulation and that describe the behavior of the simulation. The initial state of the simulation is constructed through Algorithm 1. The algorithm creates: an empty queue of waiting cases for each activity; a queue of resources for each resource type, containing as many resources as specified by the resource type; the queue of simulation events, containing one new case arrival event and activation events for all resources; an empty set of assignments; and a set of passive resources, which initially contains all resources.

figure a
figure b

After the initial state, the simulation events in the event queue are processed by the simulation engine. Algorithm 2 specifies how this works. The algorithm processes simulation events in the order in which they should occur. If the simulation event is an arrival event, the case that arrives is put in the queues of the activities that are enabled in the current (initial) marking of the case. Subsequently, an event is generated for the next arrival. If the simulation event is a completion event, the resource processing the completed activity is released, the next marking of the case is computed, and the case is put in the queues of the activities that are enabled in that marking. If the simulation event is an activate event, the passive resource is activated and a new passivate event is scheduled. If the simulation event is a passivate event, first there is checked whether the resource which should become passive is currently processing an activity for a case, if so a new passivate event is scheduled at the completion time of the activity. If the resource is not currently processing an activity, it is removed from the resource queue and moved to the passiveresources and a new activate event is scheduled. Subsequently, it is determined if there are any activities on waiting cases that can now be performed, because there are resources available to do so. Activities must be processed in an order that is ‘fair’, for example longest-waiting-time-first or round-robin.

5 Evaluation

The advanced simulation engine that is defined in this manner, improves on current BPMN simulation tools. Consequently, the hypothesis of this paper is that the current BPMN simulation tools produce analysis results that significantly deviate from reality.

In order to test this hypothesis, a simulation experiment will be conducted. In this paper the focus will be on resource dependencies, which consist of the concepts of separation of duties and case handling. In future work we will also investigate the effect of different queueing principles, case data, and other advanced resource patterns.

5.1 Simulation Methodology

The evaluation of the effect of the different resource dependencies is performed using simulation. The simulation will be run on a newly built discrete event simulation engineFootnote 1 which is able to handle the new queue mapping and the resource dependencies. This new simulator is developed in Java and makes use of the Desmo-J library. The simulation engine supports the resource dependencies, queueing strategies, case attributes and replications, warm-up periods and confidence intervals for the performance measures. A more extensive example process is available in the GitHub location to test the simulator.

The simulation model that will be used to test the hypothesis consists of two sequential activities served by the same resource type to simulate the patterns described by the resource dependencies. This provides three scenarios, where in all scenarios the same resource type is used, but which resource instance can handle the case depending on the resource dependency. Both of the activities have an exponentially distributed processing time with \(\mu =2.0\). The exponentially distributed arrival rate of the system will vary from 0.01 to the number of resources divided by the inter-arrival rate of 4.0. The number of resources in the simulation will increase from 2 to 10 resources. The duration of the simulation is 1440 h and the warm-up period is 192 h, which is visually confirmed by observing stability of the utilization rate, and 30 replications are performed per scenario. In Fig. 2 the simulation model is shown in BPMN 2.0.

Fig. 2.
figure 2

Model for simulation

Full size image

In order to evaluate the effect of these dependencies the utilization rate of the simulation model is plotted against the theoretical predicted utilization rate of the model. From Kleinrock [10] the theoretical utilization rate for an M/M/c queue is equal to: \(\rho = \frac{\lambda }{ c \cdot \mu }\). Where the assumption is made that the arrival process and the processing time are exponentially distributed and that there are c resources available for this queue. The theoretical expected utilization rate is adapted to correct for the number of queues which need to be served, where q stands for the number of queues which are served by the specific resource type: \(\rho =\frac{\lambda \cdot q}{c \cdot \mu }\). Using this metric the theoretical utilization rate is calculated using the provided simulation parameters, assuming equal processing time for all queues. In the described simulation situation this is the case, so the metric can be used.

5.2 Results

From the results obtained in the simulation it can be concluded that the hypothesis is true, without taking the resource dependencies into account the result can differ as much as about fifty percent on performance of the resources in the process model. First the results from the separation of duties resource dependency will be discussed, next the case handling resource dependency is discussed. In each figure the three different scenario’s are plotted against each other, where the blue line is the scenario without resource dependencies, the red dashed line is the scenario with separation of duties and the orange dash-dot line is the case handling scenario. For each line the 95% confidence interval is calculated and the differences are significant between the lines.

For the case where there are no resource dependencies it is observed that the achieved utilization in the simulation aligns perfectly with the theoretical utilization. This supports the claim that the simulation tool properly models the utilization of the resources.

The separation of duties resource dependency has a major impact in the scenario with only two resources as can be seen in Fig. 3. From a theoretical utilization of 0.9 there is a deviation where the resource is less optimally used in terms of utilization. For the scenario’s with more resources the deviations between the separation of duties dependency and the situation without any resource dependencies are not significantly different. This can be explained by the fact that the restricting behavior of the separation of duties principle becomes less when there are more resources available. In the situation with only two resources the principle excludes 50% of the resources from handling the second task, where with five resources, see Fig. 3, only 20% of the resources is excluded from the handling the case.

The case handling resource dependency has an equal impact on the resource utilization as the separations of duties resource dependency in the scenario with only two resources, see Fig. 3, where both lines overlap but deviate from the line without resource dependencies. When increasing the number of resources the effect does not diminish as with the separation of duties resource dependency but increases significantly. In the scenario with five resources the utilization drops to 0.8 when it is expected to be 1.0. If the number of resources is further increased to eight resources then the utilization drops further to 0.7 instead of the expected 1.0. In contrast to the separations of duties resource dependency, the case handling resource dependency shows the same effect with only two resources as the separation of duties resource dependency, but in stead of a decrease in the restricting behavior the restricting behavior increases. For the scenario of two resources the principle excludes 50% of the resources from handling the second task. Where with five resources the restricting behavior has increased to excluding 80% of the resources to handle the second task. This translates to a heavily decrease of resource utilization in the model compared to the expected performance of the model. Therefore the waiting times in the model explode, since there is a lack of resources for processing these cases. Next to the lack of availability of resource because of the resource dependencies there is a random allocation strategy applied for the resources. With a process aware resource allocation algorithm this effect can be lessened, but the resource restrictions still apply, so the lack of resource availability still has an effect on the performance of the process.

Fig. 3.
figure 3

Comparison with different number of resources

Full size image

6 Conclusion and Future Work

This paper contributes to the field of business process management and business process simulation by providing a new simulation engine which provides the foundation for further incorporation of resource perspectives in business process simulation. In the related work section the lack of incorporation of certain aspects of business processes is shown. In the evaluation it is shown that the effects of not incorporating these aspects can lead to significant differences in performance metrics for the simulation. And since in practice companies aim for high utilization rates of 0.8 and above for their resources, these differences found are very relevant for the performance of the real world processes.

For future research the effect of the resource dependencies in larger processes can be studied to see how big the influence is on a large scale. Furthermore the use of advanced allocation algorithms for resources to cases can be investigated to obtain better performances of the model using the same set of resources. Also the resource assignment can be more formalized, as for example in Cabanillas et al. [2]. The effects of other extensions in the process model can be investigated further to show their impact on the performance of the process. For the discrete event simulation more mappings are possible, for example to map BPMN first to CPN Tools and then to discrete event simulation, here is chosen to map BPMN directly to discrete event simulation. Not all patterns from Russell et al. [18] and their interactions are described, which is a limitation of this paper. Also a limitation is that there is only looked at a single process instance, to increase the validity of the results more instances should be tested. Furthermore the simulation tool can be validated in future work by comparing it to other simulators, for example CPN Tools. In general more research should be conducted in the field of business process simulation, especially in combination with advanced resource perspectives. Thus this simulation engine is the first step in the direction of accurate simulation of complex real world processes.