Event driven simulation possibilities for the capacity management an industrial case study

Event driven simulation possibilities for the capacity management an industrial case study Andreas End *, Andreas Schmietendorf Abstract The paper deals with simulation possibilities used for the capacity management of business processes. After a selection process of several simulation tools, the AnyLogic framework is used to implement a prototype. Within this paper, the focus is on the conception and implementation phase of the simulation model. The multi-layered structure of the simulation model is shown, as well as selected implementation details of corresponding resources. Furthermore the author s vision of an integrated simulation environment is introduced. This allows the integration with process modelling tools, configurable interfaces for a parameter transfer and the automation of simulation experiments. 1 Introduction and aims The correct sizing of business processes is a very difficult part in the industries. The capacity management wants to consider technical and human resources under consideration of given time constraints of the business process. Typical questions deal with the required time and costs to fulfil a specific customer request. To give a right answer there are different possibilities: - Use of experience to estimate the corresponding metrics, - Use of statistic methods and known mathematical functions, - Use of event driven simulation systems. We used the last mentioned approach. The reason for this choice was driven by a process oriented view of our customers and available process models established with the EPC-notation (event driven process chain). In particular, the fulfilment process for different telecom specific products (single, double and triple play) should be investigated. The expected results of simulation experiments can be characterized as follows: - realizable order quantities per time unit, - process times and latencies within specific activities, - reachable productivities of a specific process instances, - aspects of synchronisation between corresponding activities, * T-Systems Enterprise Services GmbH, System Integration - Project Delivery Unit Telco, Goslarer Ufer 35, 10589 Berlin, Email: andreas.end@t-systems.com HWR Berlin Berlin School of Economics and Law, FB II Business Information Systems, Neue Bahnhofstr. 11-17, 10245 Berlin, Email: andreas.schmietendorf@hwrberlin.de

- possible bottlenecks within process instances, - effects restricted or outlandish IT-resources, - What if performance analysis of alternative process instance. One important aspect considers the verification (correctness of the established model structure) and validation (correlation of the results with real process instances) possibilities. Beside the results of simulation experiments the usability and automation possibilities should be investigated. 2 Related works The application of simulation models is a well known approach to investigate the system behaviour of a real system. The used model provides an abstract view and simplifies several aspects of the investigated system under consideration of assumptions. In general a simulation model is realized by the use of a computer program that reflects the dynamic behaviour as well as the static structure of the investigated system. During the computer program works, the simulation clock runs, and there are reproduced condition alterations of a temporal sequence that corresponds to the original (see [Lorenz 1994], [Shannon 1975]). The development of simulation models implies a great challenge and should consider the following PLAN DO CHECK ACT steps (under use of [Lilja 2000], [Bossel 2005], [Page 2005], [Schriber 1990]): - Aims of the simulation model, - Available information about the investigated system, - Possibilities to implement simulation models, - Realization of simulation experiments, - Representation and animation of simulation results, - Model validation and result verification, - Mapping the results to the real system. An interesting work about possible application domains of simulation models can be found by [Bossel 2005]. He describes 100 simulation experiments inside the following domains: - Elementary Systems, Physics, Engineering, - Climate, Ecosystems, Resources, - Economy, Society, Development. As mentioned in the previous chapter we want to concentrate on the performance relevant aspects of business processes. This scope is not new, but mostly used to solve strategic and planning problems. Our research project wants to use simulation models under consideration of the following aspects: - Support of operative decisions, - Automation of simulation experiments, - Integration possibilities of simulation tools, - Dynamic parameterization of simulation models, - Relationships between IT-resources and business processes.

An empirical analysis of 41 modelling tools for business processes has shown that 66 percent support simulation possibilities, mostly from a planning point of view. Unfortunately, these possibilities are not reflected in the industrial context. Simulation possibilities are partly used by less than 20 percent of all businesses. (see [Schmietendorf 2008]) What are the reasons for the low acceptance? 3 Concept and Implementation 2.1 Sources and Requirements for a simulation model In an industrial project with the aim to give management reports about process performance and resource utilisation for capacity management there was the wish to use simulation models for sophisticated planning efforts. In a pre-requirement analysis some facts were named that this model should take into consideration. Figure 1: Templates from an ARIS process model Beside the typical characteristics of process models like conditional branches, activities with delay times and the usage of staff resources and queues for their utilisation, there were some additional requirements. As shown in figure 1 it should be possible to map the behaviour of a lot of different IT-Systems which are used over the whole business process. The red-circled blue caskets represent two of these IT- Systems. Furthermore these two IT-Systems belong to one activity in the process model, so this feature had to be also considered. The IT system concept that had to be

drafted for the simulation model should take the challenge to provide the possibility of uniform failure handling for non-available and overloaded IT-Systems. Another requirement was the post-processing of orders that are not ready for production because of process errors. Beside these general requirements for the model structure there was also the aim to integrate simulation models with a data warehouse that gains daily deliveries of process parameters. These data should be used in the simulation process model wherever it is possible and useful to keep the simulation model up to date. Anymore it is planned to run validated simulation models as server services to give standardised simulation results for actual parameter sets. This should increase the automation of simulation runs when no interaction with the simulation model is necessary because of stable conditions. Not least the integration of simulation models should also provide the ability to export important simulation results to a data warehouse to integrate them into planning reports. A prototype was developed to understand and proof the selected simulation tool AnyLogic. It should also verify and implement the identified requirements that belong to the chosen process model. 2.2 The Model Root a central collection point for model navigation Figure 2: Head of the process model as part of the model root class Figure 2 shows the four main processes of the developed simulation model. Contact management, assignment and provision represent the standard workflow for ordering of products via a call centre. During processing, standard failures may appear which are modelled directly in the workflow. These failures lead to so called tickets in the main CRM-system and cause a post-processing to complete work. To advance the workflow as far as possible, processing is continued after failures. At a given point of the model an order is asked for occurred standard failures. It is routed to post processing (and back) to follow a non-standard workflow. This is shown in figure 2 through the arrows that lead in and come out of the post-processing part. The buttons around the process model provideprovide access to other parts of the simulation application. There are statistical overviews, the resource pool overview and the controls sector for model manipulation which can be seen in figure 3.

Figure 3: controls for manipulating the simulation model Figure 4: processing times for the developed simulation model One example for the statistical monitoring aspects of the model can be seen in figure 4 which shows the processing times for completed activities. Due to the fact that a monitoring feature for process entities is missing in AnyLogic this feature had to be added. This was possible because of the open architecture of the program. It lets you include own class code as well as encapsulate modelling functionality to provide custom notation elements. These elements can be accessed through own modelling palettes which represent the self-created libraries.

Figure 5: Association to the model root element In order to make referring, requesting and routing possible for every sub-process of this model an association to the model root object has to be hold from every of these parts. (see figure 5) The aim of constructing the whole helper elements was always to hide these parts from a business modeller who is usually not familiar with programming topics. 2.3 IT systems an interaction of services, pools and timeout behaviour The main concept to be implemented was the concept of including the usage of ITresources that means especially a business related view to the used software applications. First of all the IT systems as itself had to be modelled. For this reason the applications were mapped as resource pools and connected via a network. (see figure 6) Figure 6: resource pool networks for agents and IT systems The capacity of such a pool in combination with each service request from the process makes a simple IT utilisation behaviour possible. The more power such a system has, the more capacity points it can have. A technical breakdown can be realised in setting the total capacity points of such a pool to zero. As already mentioned our goal was to implement a business oriented view to the IT-system, not the internal hardware or software details. The collection of these resource pools to logical networks is used to fulfil the requirement that one process activity can use more than one IT system for processing.

Moreover, a service object is required to request these systems for work. Beside the standard functionality of seizing, delaying and releasing the named IT resource units there are other features that have to be implemented. Figure 7: the inner structure of a service object for IT systems Figure 7 illustrates the inwards of the developed IT service object. It is represented via its icon and its class parameters for users of this palette element. As mentioned before AnyLogic provides no built-in functionality for monitoring processed entities. Figure 8: example of the monitoring functionality for entities Figure 8 shows a part of the monitoring functionality for entities. A service object considers breakdown time and performance bottlenecks for the requested IT systems. Other important times such as agents processing time are measured between the seize and release objects for agent resource pools whereas the total processing time is measured between source and sink elements in the model. 1 1 See the finalize method in figure 2 and the constructor of the models main entity class

Figure 9: Common timeout entry for all IT service objects possible Another advantage of this service element is a more general approach for possible timeout behaviour. Timeout ports are features of AnyLogic elements with queuing aspects to describe the situation that requested resource pools are not longer requested after a given time. In that case the handled entity doesn t leave such an object using its usual out port, but through a separate timeout port. In the given self constructed service object this feature was extended to enable a custom routing to a central timeout element. (see the red-framed property in figure 9) Due to that there is no separate modelling of timeout behaviour on every timeout port is necessary. A simple reference to the central timeout element can be reused for every modelled service. To complete the implementation of the IT concept all timed out entities have to be handled at a central place in the model where a central and continuous queuing and availability checking takes place. The red T-symbol in figure 2 stands for this part of the model logic. There is no connection point for standard workflows as in normal sub-processes because there is only one instance of this model class available via the model root which can be reached via its enter object. 2 Figure 10 shows the elements which are used to realise common timeout behaviour. 2 See the exit_timeout_destination property in figure 8

Figure 10: Implementation of the central timeout behaviour This model class consists of two important parts. The first one is a half-connected queue. Entities enter this object after passing the enter- and Agents_release objects and stay inside the queue until they are removed programmatically. A recurring trigger proofs in a given time if the unavailable IT systems are restored/repaired for work. In the positive case it routes the entity back to the process via its given jumping attribute that was set from the last IT service object. In the negative case it creates a new instance of the trigger element which calls the proof methods again after a given time. Beside these logical elements there are paintings such as arrows and ovals to

improve the understanding and handling with the model. 3 In order to make these custom routings possible an entity has to have some special technical attributes which will be described in the next section. 2.4. BusinessCase an entity with special monitoring, jumping and processing attributes Figure 11: Different attributes of the models entity class 3 Compare figure 2 and figure 9.

One of the main assumptions for all the content based routings was to consider a point where all the necessary information of a special entity had to be placed. Therefore the entity classes which were used to generate a models processing entities where extended hierarchically to store all the necessary information during the process. Figure 11 displays the different kinds of entities attributes 4 passing the model during a simulation run. The Business class holds all the flags which are set during the simulation run when a process failure appears. If one of theses flags is set, the entity is routed to the pre-processing part. The second Entity class MonitoredEntity is more interesting. It provides monitoring attributes for time measurements and jumping attributes for custom routing and timeout handling. MonitoredSplittedEntity has to be set with inherited time attributes and has an association to its original entity. It is used with split/fork elements. The reference to the original entity is required to add the monitored times to the original entity for correct monitoring. These last two classes are provided with the constructed custom modelling palette and can be used with inheritance to give these attributes to model entities that are used during the simulation run. In this way a clear separation of palettes and models is possible without the need for casting types explicitly for property checks of entities. With the usage of jumping attributes it is possible to route an entity back to its last position in the workflow after some custom handling like in the timeout part. (see the lastobject attribute in figure 11) The property unavailable_it_systems commits the requested systems from the service objects to the entity t logic. Figure 12: encapsulation of developed functionality in a modelling palette All of these described mechanisms are hidden, so that a business modeller is not overwhelmed. It is completely encapsulated in a library and nearly ready for an outof-the box usage in a modelling palette. (See figure 12) This shows that the open architecture of the tool gives enough freedom for customizing using inserted modelling primitives and Java code without increasing complexity of the modelling environment for a standard user. The next section shows future intentions for a whole simulation architecture which are also realisable because of the given features of the tool. 4 One could also say POJO s to these simple Java classes with attributes and getter/setter methods.

4 Future work an integrated simulation environment Figure 13: Architecture for an integrated simulation environment Future work envisions the aim to integrate developed simulation models with additional components. AnyLogic allows extracting models as Java applications. Due to that it is possible to let a scheduler or a trigger start this models programmatically. In this way a simulation model should run experiments when new relevant process and business data are given by a Data Warehouse which gets daily deliveries for a lot of such data. Important results should be transferred to a Data Warehouse where they are stored for forecasting reports. To allow this, a middleware layer named ModelConfigurator has to provide generic access to a Data Warehouse, has to have logic for mapping this database data to the right models state variables and has to implement functionality for distribution fitting of the source generator elements on the basis of incoming orders. Another middleware component named ModelMapper should allow mapping process models from different sources like other simulation tools, enterprise modelling tools and process models form Business process engines. 5 The ability to export models as java applets without runtime license keys allows it to provide developed models to a wide area of users. Although no Database and filesystem is intended, it is a good way to get into the model and make some on-the-fly changes with the given control elements. 5 Although those sounds easy it is a difficult and complex part of the architecture.

5 Conclusion The aim of this paper was to describe the concepts for the implementation of a simulation prototype in an industrial project. It is planed to permanently use an integrated simulation environment for sophisticated simulation modelling and experimenting. Specifications like error handling, pre-processing and IT usage had to be conceptualised and implemented to proof the feasibility of the requirements for the chosen simulation environment in terms of modelling and integration. These requirements could be implemented. Future intentions were also proved and are technically feasible because of the open architecture of the simulation environment. Nonetheless this was no typical simulation study. All of the used probabilities, distribution functions and the model structure itself haven t been validated, so one of main efforts in simulation studies has still to be taken. 6 6 References [Becker 2007] Becker, J.; Kugeler, M.; Rosemann, M.: Prozessmanagement. Ein Leitfaden zur prozessorientierten Organisationsgestaltung. Springer, 2007 [Bossel 2005] Bossel, H.: Systemzoo 100 Simulationsmodelle aus Systemdynamik, Technik, Physik, Ökologie, Land- und Forstwirtschaft, Ressourcendynamik, Wirtschaft, Gesellschaft und Entwicklung. CD-Rom, co.tec, Rosenheim, 2005 [End 2008] End, A.: Cyclic simulation of business processes, bachelor thesis, University of applied science Harz, 2008 [Jansen-Vullers 2006] Jansen-Vullers, M.; Netjes, M.: Business Process Simulation, in Proc. Of Seventh Workshop and Tutorial on Practical Use of Coloured Petri Nets and the CPN Tools, University of Aarhus, Denmark, 2006 [Lilja 2000] Lilja, D. J.: Measuring Computer Performance A practitioner s guide, Cambridge University Press, 2000 [Lorenz 1994] Lorenz, P.: Simulation I, Teil 1. Vorlesungsskript, Otto-von-Guericke- Universität Magdeburg, Institut für Simulation und Graphik, Magdeburg, 1994 [Page 2005] Page, B.; Kreutzer, W.: The Java Simulation Handbook - Simulating Discrete Event Systems with UML and Java, Shaker-Verlag, Aachen 2005 [Rücker 2008] Rücker, B.: Business Process Simulation - selbst gemacht, Java-Magazin Ausgabe 05/08 [Schmietendorf 2008] Schmietendorf, A.: Assessment of Business Process Modeling Tools under Consideration of Business Process Management Activities, in Lecture Notes in Computer Science, Volume 5338/2008, pp. 150 163, Springer- Verlag Berlin Heidelberg 2008 [Schriber 1990] Schriber, T. J.: An Introduction to Simulation Using General Purpose Simulation System H., John Wiley and Sons Ltd, 1990 [Shannon 1975] Shannon, R. E.: System Simulation: The Art and Science, Englewood Cliffs, N. J., Prentice-Hall, Inc., 1975 6 For more information see Law & Kelton: Simulation, Modelling and Analysis, McGraw Hill Higher Education