A Cost-object Model for Activity Based Costing Simulation of Business Processes

204 UKSim-AMSS 8th European Modelling Symposium A Cost-object Model for Activity Based Costing Simulation of Business Processes Vincenzo Cartelli, Giuseppe Di Modica, Daniele Manni, Orazio Tomarchio Department of Electrical, Electronic and Computer Engineering University of Catania Catania, Italy Email: {firstname.lastname}@dieei.unict.it Abstract The achievement of business goals is heavily affected by the capability of enterprises to design, enforce and govern business processes. The dynamism of the market requires business goals to be constantly tuned, thus obliging the enterprise to continuously re-design processes. The cost for process reengineering may be not negligible, if we consider that it may require several refinement steps and that tuning processes onthe-job may impair regular business activities. To this end, there is a growing interest towards tools that simulate the processes performance before they get actually enforced. In this paper we propose a novel business process simulator which makes use of a cost-object resource model to allow for Activity Based Costing (ABC) analysis of the simulation results. The simulator works with business processes modelled in the Business Process Model and Notation (BPMN) and exploits the rigor of the Colored Petri Nets (CPNets) formalism. A case study test has been conducted on a prototype implementation and related results are presented. Keywords Business process simulation, Activity Based Costing, BPMN, Colored Petri Nets I. INTRODUCTION In the globalised and dynamic market the chance of an enterprise to survive are related to its ability to promptly adapt to the ever changing market conditions. In order to be able to quickly and efficiently meet the demand for new products/services, enterprises need to enforce new processes (or re-organize old ones) and re-schedule the exploitation of internal resources in a way that is useful to the new processes and does not compromise other enterprise s business goals. Many players recognize the value of Business Process Management (BPM) as a strategic methodology to govern business processes. BPM combines established management methods with information technology to measure performance, identify bottlenecks and improve business processes more quickly and easily []. It enables business managers to make better-informed decisions and to look at the enterprise asa-whole when facing new market changes and challenges. Beyond process modeling, the analysis phase plays a key role in the BPM discipline. Business process analysis is a term used with a rather broad meaning, including a range of different tactics such as simulation and diagnosis, verification, and performance analysis of processes [2]. This paper put the focus on the process simulation. Simulation provides dynamic analysis of business processes, going beyond static diagrams and averaged numerical process verification. Processes involving variability, disruptions and interaction complexity are ideal for simulation. Simulation tools provide a structured environment in which business managers can understand, analyze, and improve business processes. With such tools it is possible to evaluate the performance of the existing process model (as-is model) and to compare it with its modified versions (to-be models) in order to verify the improvement of key performance indicators (KPIs). In this paper we present the design of a simulation tool that relies on the standard Business Process Model and Notation (BPMN) [3] and exploits the formalism of Colored Petri Nets [4] for which efficient and consolidated analysis techniques are available. One of the main contribution of our work with respect to existing tools is the definition and the integration of an enterprise s resource model within the simulation framework which accounts for both human and non-human resource types. A prototype of the simulator was also implemented and some details on the way it works are described by means of a use case example. The rest of the paper is organized as follows. In Section II the literature is reviewed and the motivation for this work is explained. Section III-B discusses the proposal of a Business Process Simulator and provides some architectural details. In Section IV a step-by-step example of how the simulator works is described. Concluding remarks can be found in Section V. II. LITERATURE REVIEW AND MOTIVATION The majority of literature works addressing the business process simulation mainly leverage on Petri Nets. Petri Nets are preferred to other modeling techniques because of their rigor and clear formalism. Also, there are many easily available and freely accessible tools which analyse Petri Nets and evaluate their soundness [5], i.e., whether the model is free of potential deadlocks and livelocks. The basic approach adopted by researchers is to transform the business process model (usually defined in the BPMN language) into its equivalent Petri Net model and to feed the model to a simulation engine [6], [7]. The Protos2CPN tool s strategy [8] is to transform a Protos model into a Colored Petri Net (CPNet), and simulate it in standard CPNet tools. CPNets [4] is a very powerful discrete-event modeling language combining the capabilities of Petri Nets with the capabilities of a high-level programming language. Petri Nets are rather a good technique which is proved to be particularly effective in the simulation of workflows. Unfortunately, business processes are not just workflows. Though the flow of activities may be considered as the skeleton of a business process, there are some important, yet necessary, 978--4799-742-2/4 $3.00 204 IEEE DOI 0.09/EMS.204.4 22

process elements which complement the workflow and may strongly impact the overall process dynamics. Authors in [9] identify such elements in, respectively, the environment where the process is enforced and the resources required to carry on the process activities. They propose to use an ad-hoc workflow language (YAWL [0]) to model resource involved in the process dynamics. Unfortunately the resulting model is only capable to represent human resources, neglecting the vast category of non-human resources which most of activities actually need in order to successfully complete. The intent of our work is not to explore new ways of simulating the process workflow; so basically the simulative approach we propose makes use of (Colored) Petri Nets as well. Rather, we put the focus on the definition of a process Context Model to be integrated to the process workflow. We define the Context of a process as the union of a Model, capable of characterizing both human and non-human resources from a cost-object perspective, and an Environment Model, which is used to define the salient features of the specific process environment. Through this model, information can be specified, for instance, on the type and quantity of a given resource R to be associated to a specific process task T ; or, which statistic distribution D is associated to the execution time of a process task T. The second contribution of this work is the design and the implementation of a Contextaware Business Process Simulator capable of a) elaborating on the process workflow and the context model, b) generating a CPNet model to be executed on a CPNet simulation engine and c) packaging the simulation results to be in a cost-sensitive format suitable for ABC analysis. III. PROPOSAL OF A BUSINESS PROCESS SIMULATOR The approach we propose eases the designer s work in that it keeps what is specific to workflow modeling separated from what is peculiar to context modeling. Designing a process workflow model will be as simple as drawing a standard BPMN diagram, while an extra effort is requested to design the process context according to the model that is discussed more in details in the Section III-A. Simply put, the proposed system s task is to integrate the two models and to craft a single Colored Petri Net model. Figure depicts the system s overall architecture. Fig.. System architecture In the picture, the Model Converter component receives a BPMN diagram and transforms it into a plain Petri Net (represented by the.pnml artifact) that is ready to be fed to the CPNet simulation engine. The Bridge component depicted in the top-right part of the diagram elaborates the Context model and creates an instance of the process context s runtime, which in turn will be called into play in two different steps: ) At system initialization time (before the simulation is actually triggered), it is responsible for coloring the plain Petri Net s created by the Model Converter; 2) At simulation time, it acts as a and Context manager and is invoked by the colored tokens to provide runtime information regarding the resources and the context respectively. The reader may refer to Section IV for the description of a concrete example of how the simulator and the involved components behave. A. A cost-centric resource model Differently from what other approaches have proposed, the work presented here focuses on the definition of an enterprise s Model and on its strong integration with the business process simulator. The Model aims at capturing and representing costs and other process related informations regarding any kind of resource that has to be consumed by each process task, be it a human or a non-human resource, and more specifically puts the basis for an Activity Based Costing (ABC) analysis of processes. We believe that an accurate representation of all resources potentially exploitable by the enterprise, along with the specification of a tight integration of such resources to the enterprise s business processes, will help the process designer to contextualize the process model and, thus, to better estimate the KPIs fulfillment. The starting point is suggested by the approach used in ABC analytical accounting systems []. We assume that all enterprise costs are generated whenever an activity consumes a resource. The strength of ABC is that all costs generated by resource consumptions are directly allocated to the activities by means of the appropriate resource drivers, in other words, all costs (including overhead costs produced by supporting activities) may be viewed as direct costs. Given the full activity cost configuration it is afterward possible to allocate this cost to every cost object through well suited activity drivers that define how a cost object consumes each activity. The Model defines the resource concept as a cost object extension itself. Figure 2 presents its relevant UML classes and their relationships. Each resource, as well as each cost object, is defined by its unit of measure and its unit cost. As measures and unit framework, a JSR-275 standard implementation has been used 2. The NonHuman class allows the definition of resources like goods and services. Consumable extends it by introducing the concept of residual amount and it is suited for available-if-in-stock resources. Schedulable represents a generic resource whose availability is defined by one or more calendars; the most common calendar based for our purpose the Renew tool was used: www.renew.de 2 http://jscience.org 222

Quantity, Unit of Measure and Amount package Quantity Duration Money CostObject Durable NonHuman Schedulable..* calendar «bind» Q: NumberOf<Human> Calendar Skill Feature skills features Unit Dimensionless Refillable Consumable Organizational Human Amount NumberOf T Asset OrganizationalUnit OrganizationalBranch OrganizationalTeam 0, higherlevel Role OrganizationalGroup groups positions delegates 0, directreport positopn occupant OrganizationalPosition subordinates Fig. 2. model resource is the Human who occupies an OrganizationalPosition within an OrganizationalGroup or an OrganizationalUnit structure (organizational chart). The base class for and Activity is the CostObject class. In order to avoid possible misunderstandings, we find it useful to clarify that the concept of activity adopted in this context is that of the ABC methodology, that is, an activity can represent any business operation that transforms input resources into output products, from elementary tasks to macro-processes. Each cost object can rely on a set of other cost objects requirements (see Figure 3), enabling hierarchical cost object modeling and costs aggregation providing a generic chart of cost object accounts that enables the modeling of enterprise concepts such as the bill of activities or the bill of materials. The Context Model uses this feature to map the ABC resource driver concept on the task s resource requirements. Requirement usage Usage requirements costobject Empty StartEvent «bind» CostObject Q: NumberOf<Activity> Event StartEvent Fig. 3. Message StartEvent Task Inclusive Gateway Bridge interface SubProcess Activity Reference Gateway bpmnelement BpmnElement flows..* Exclusive Gateway TopLevel Process Figure 3 shows how the Context Model implements the bridge interface between the simulation engine and the Model. In standard ABC accounting, activity drivers are generally defined by the ratio between the number of activity instances related to the given cost object and the total number of activity instances or, in case of an activity that works on a mix of different cost objects, by the ratio of time spent by the activity Pool Flow working on the given cost object and the total work time of the activity. The second approach is well justified when low levels of informations about the inner structure of the activity are available, so that it is not possible to exploit the trace of the elementary tasks composing the entire activity in a simple way. Under the business process management view, it is reasonably possible to assert that the latter scenario should never occur. Given the fundamental approach of BPM modeling and implementation phases, that imposes a full breakdown of all processes up to their task levels in conformity with each dataobject lifecycle, it can be safely assumed that the Context Model enables a full resource-activity-cost object mapping given that resources are consumed by tasks that generally work on a single and well defined set of cost objects. The only exception may arise in case of high-level non-executable process models. It should be under the responsibility of the designer to detail the Context Model up to the required level. B. Model Converter s architecture The Model Converter depicted in the Figure is responsible for the generation of a plain Petri Nets model (.pnml) representing the process workflow. The.pnml generation is a complex process which requires the work of some components whose relationship and interactions are shown in the Figure 4. The reader may notice that the conversion process also requires a set of pattern models which are nothing but a representation of the main BPMN elements (tasks, events, etc.) in the Petri Nets language. A description of the role of patterns, as well as an explanatory example, are reported further on. The Model Converter is broken down in three sub-components: a) BPMN XML Converter: Its task is to parse the BPMN Model, to make a model normalization and to produce a Java object-model (class instances representing the workflow elements). The normalization procedure is necessary as it simplifies the original BPMN model by eliminating any complex sub-workflow which the BPMN 2.0 specification may allow. In the Figure 5 an example of model normalization is showed. 223

Fig. 4. Model Converter s components and related interactions Starting from a normalized model, the subsequent pnml model conversion will be able to create a Petri Net model with a reduced (and strictly required) set of places/transitions. Fig. 6. Class diagram of the PNML Model Builder Fig. 5. Workflow normalization example b) PNML Model Builder: It converts the workflow Java object model into a Petri Net Java object model. The class diagram of the PNML Model Builder is depicted in the Figure 6. The overall conversion is orchestrated by the ModelBuilder. Key elements are the Adapters, which are responsible for processing each workflow object and converting it into its Petri Net equivalent. Each Adapters is instructed by a PNML Pattern, which is a PNML representation of a specific BPMN element. Patterns have been defined for the following BPMN elements: Process, Empty Start Event, Message Start Event, End Event, Send Message Event, Receive Message Event, Task, Parallel Gateway Join, Parallel Gateway Split, Exclusive Gateway Join, Exclusive Gateway Split, Event Based Gateway, Sub Process Start and Sub Process End. Finally, the BpmnNavigator is the class that the ModelBuilder relies on in order to construct the BPMN process execution flow. c) Pnml XML Converter: It provides two-way Java2XML conversion capabilities which have been exploited several times in the project. In particular, in this specific step it takes the Java object instances created by the Model Builder and finally produces the Petri Net in the form of an XML document (.pnml) ready to be simulated. IV. SIMULATOR AT WORK The designed simulator tool has been tested on a simple yet not trivial use case: the release of a construction permit by a city Building Authority. The BPMN model of the considered use case is not fully presented due to space limitations, but an excerpt of it is shown in the Figure 7. The reader may refer to [2] for a thorough description of the use case and its simulation scenario. The whole process involves different actors who interact each other exchanging information and/or documents (represented in the model as specific messages). The involved actors are: Applicant: it is the private citizen/company who needs to obtain the building permit and triggers the whole process; Clerk: it is the front-office employee of the Building Authority who receives the Application and is in charge of a) checking the documentation of the application, b) interacting with the applicant in order to obtain required documents and c) sending back the result of the application; Senior Clerk: it is the back-office employee of the Building Authority who evaluates and decides on the application; Expert: it is an external expert who may be called upon by the Senior Clerk whenever specific technical issues 224

Fig. 7. process BPMN excerpt of the Building Authority application arise and the final decision may not be autonomously taken. The business process spans four swimlanes, one for each actor. Both the Applicant and the Expert are external entities, i.e., are not part of the enterprise s business process dynamics. While there was no reason to represent the Applicant in the resource model, the Expert was modeled as a Durable (paid on hourly basis). The Clerk and the Senior Clerk were modeled as OrganizationalPosition. Other considered (nonhuman) resources in the scenario are energy, modeled as a Durable, paper and stamps, both modeled as Consumable. The xml definition of the resource model follows: <resources> <organizational-position id="clerk" timeunit="hour" moneyunit="eur" units="" timeunitcost="0" /> <organizational-position id="senior_clerk" timeunit="hour" moneyunit="eur" units="2" timeunitcost="20" /> <durable-resource id="external_expert" unit="numberof" timeunit="hour" moneyunit="eur" timeunitcost="30" /> <durable-resource id="energy" unit="watt,*e3" timeunit="hour" moneyunit="eur" timeunitcost="0.3" /> <consumable-resource id="stamp" unit="numberof" moneyunit="eur" unitcost="0.8" /> <consumable-resource id="paper" unit="numberof" moneyunit="eur" unitcost="0." /> </resources> To sum up, the Model for this example is populated by Clerk and Senior Clerk for what concerns human resources, paper and stamps regarding the non-human resource set. Another relevant component of the Context Model is the empty start events definition. Every empty start event instantiates a TopLevelProcess with a frequency given by each cost-object demand rate. In this context a cost-object has to be interpreted as one of the ABC final cost allocation item within a single process instance. For the simulation scenario, four types of permits (representing the cost objects in the ABC terminology) were considered: Building Renovation, Maintenance, Preservation & Restoration and Urban Restructuring. The Expert s advice is always requested for applications requiring permits of type Preservation&Restoration; for other types of application the Expert is called upon with a likelihood which follows a Uniform distribution (typically, 25% of times the Expert is involved). In the following an excerpt of the empty start event xml definition is reported. <empty-start-events> <empty-start-event class="constructionpermit" id="sid-2d3f909-8be9-4d9c-9385-2634ac464997"> <cost-objects> <cost-object name="building Renovation"> <frequency timeunit="hour"> <exponential beta="240" /> </frequency> <cost-object name="maintenance">... <cost-object name="preservation & Restoration">... <cost-object name="urban Restructuring">... </cost-objects> </empty-start-event> </empty-start-events> The Petri Net model of the process workflow is then generated by the ModelConverter as described in the Section III-B. Figure 8 shows a graphic representation of the Petri Net elaborated by the conversion process on the BPMN diagram excerpt shown in the the Figure 7. The obtained.pnml file is ready to be loaded in the simulation engine. The simulation starts with the initialization phase. This phase instantiates each Context Model s element in the form of colored token and injects them in the corresponding query place of the relative BPMN element. The sequence diagram in the Figure 9 describes how the initialization step works: the simulation engine interfaces with the the Bridge component to retrieve information stored in the Context Model which are useful to initialize (read to color ) the Petri Net. The injected tokens embed the Java code that the simulation engine will call and that, at run-time, put in force the interaction between the process workflow and the process context model. While the tokens traverse the Petri Net, the process object costs are accordingly updated. A full report of costs shared by application instances and the related activities can be found in [2]. V. CONCLUSION Business process simulation is a widely adopted technique which helps enterprises to estimate the cost of process execution. Former works in the literature mainly focus on the workflow of processes and worry about evaluating just the soundness of workflow models; the work we propose broadens 225

Fig. 8. Petri Net obtained from converting the process workflow Fig. 9. Sequence diagram of the simulation initialization phase the boundary of the process to also encompasses the resources and the execution environment it interacts with. In this paper we discussed about the definition of a cost-centric resource model and the design and implementation of a CPNet simulator of business processes. A use case was also developed to show how the simulator works in practice. REFERENCES [] M. Weske, Business Process Management: Concepts, Languages, Architectures (2nd ed.). Springer-Verlag, 202. [2] K. Vergidis, A. Tiwari, and B. Majeed, Business Process Analysis and Optimization: Beyond Reengineering, Systems, Man, and Cybernetics, Part C: Applications and Reviews, IEEE Transactions on, vol. 38, no., pp. 69 82, Jan 2008. [3] OMG, Business Process Model and Notation (BPMN 2.0), http://www.omg.org/spec/bpmn/2.0/, Jan. 20. [4] K. Jensen, Coloured Petri Nets: Basic Concepts, Analysis Methods and Practical Use. London, UK: Springer-Verlag, 996. [5] O. Kherbouche, A. Ahmad, and H. Basson, Using model checking to control the structural errors in bpmn models, in Research Challenges in Information Science (RCIS), 203 IEEE Seventh International Conference on, May 203, pp. 2. [6] R. M. Dijkman, M. Dumas, and C. Ouyang, Semantics and analysis of business process models in BPMN, Information and Software Technology, vol. 50, no. 2, pp. 28 294, Nov. 2008. [7] S. Koizumi and K. Koyama, Workload-aware business process simulation with statistical service analysis and Timed Petri Net, in Proceedings - 2007 IEEE International Conference on Web Services, ICWS 2007, 2007, pp. 70 77. [8] F. Gottschalk, W. van der Aalst, M. Jansen-Vullers, and H. Verbeek, Protos2CPN: Using colored Petri nets for configuring and testing business processes, International Journal on Software Tools for Technology Transfer, vol. 0, no., pp. 95 0, 2008. [9] W. M. P. Van der Aalst, J. Nakatumba, A. Rozinat, and N. Russell, Business process simulation: How to get it right, in International Handbook on Business Process Management. Springer-Verlag, 2008. [0] W. M. P. Van der Aalst and A. H. M. Ter Hofstede, YAWL: Yet Another Workflow Language, Information Systems, vol. 30, no. 4, pp. 245 275, Jun. 2005. [] R. Cooper and R. S. Kaplan, Activity-based systems: Measuring the costs of resource usage, in Accounting Horizons, vol. 6, no. 3, 992, pp. 2. [2] V. Cartelli, G. Di Modica, and O. Tomarchio, A -aware simulation tool for Business Processes, in ICEB 204 - Proceedings of the 4th International Conference on e-business, Vienna (Austria), 204. 226