In the context of Business Process Management (BPM)  , a large attention has been given to events, activities and decisions dealing with the processes of an organization.
Several techniques have been developed in the analysis of the actual (As-Is) situation of organization’s processes, as well as in the re-engineering phase that leads to restructured (To-Be) processes. Among the existing techniques, computer-based Discrete Event Simulation (DES)  is one of the most used analysis approach.
Several research areas have already used simulation techniques, i.e., Computational Social Science  , Geography  or Sociology  . Although different simulation techniques have been involved in business processes, their application in the field of BPM has not yet been developed as it deserves  . Nevertheless, planning, management and decision-making would greatly benefit from the analysis of the outcomes of simulated scenarios. Simulation results allow to detect inefficiencies, bottlenecks, constraints, and risks as well as to estimate the performance of the system when process modifications, as new strategies or an increase of the workload, have to be applied.
Nowadays, the public sector is increasingly required to provide better services at lower cost. In this article, we deal with the Contact Center of a public social and welfare center. Our work includes the following three points of interest:
1) Framework: a general and repeatable methodological framework has been developed and applied to real cases. It includes both traditional analysis techniques (such as SIPOC diagrams) and recent techniques such as “What-If” analysis by scenario simulation.
2) Real Data: the simulation model was developed based on a careful statistical analysis of real data for the process under consideration.
3) Performance indicators: the proposed approach allows treating simultaneously several different process indicators, such as cycle times, resource utilization, queues (bottlenecks), costs and so on.
In the following section, we introduce a review of related works on BPM and simulations studies, including some applications (Section 2). Section 3 describes the methodological framework, while Section 4 details the construction of the As-Is model for the case study used in this article. Section 5 describes the definition of the scenarios used to specify possible evolutions of the As-Is model and their analysis using a discrete event simulator. Finally, we draw some concluding remarks in Section 6.
2. Related Works
The analysis of business processes usually refers to methods, techniques, and software used to support the management of an organization  . Recently, a large attention involves the procedures concerning design, control, and analysis of operational tasks regarding humans, documents, organizations, or applications  .
The adoption of computer-based simulations to business process analysis and modeling was first applied in industrial re-engineering   . In the public sector, some studies modeled public policies  , services  , public administration processes  , political decision-making  , as well as care processes in the medical field  .
Simulations was also applied to call centers, which focus on phone-calls   , and to contact centers, dealing with more complex cases of user requests  .
In addition to statistical approaches (i.e., staff-planning  , resources optimization  , queueing modeling  ), Discrete Event Simulations emerged as an alternative method to model contact center  and, more recently, also Agent-Based modeling techniques have been applied   .
In recent works, computer-based Decision Support Systems provided effective and efficient workforce planning and performance reporting in call centers  . In a similar study, a flexible business process modeling, simulation and re- engineering (BPMSR) approach was presented  . Scenario analysis (or “What-If” analysis) has been applied to explore different options for restructuring an existing process  before any change is effectively made.
3. The BP-M* Framework
This section introduces our methodological framework that is based on the BP-M* Methodology and the BP-M* Process Model.
3.1. The BP-M* Methodology
The BP-M* Methodology has been briefly described in  and consists of four phases:
1) Context Analysis: the context analysis phase aims to fix the overall strategic scenario of the enterprise and to determine the organizational components that will be investigated.
2) Functional Analysis and Process Engineering: the initial purpose of this phase is the determination of the activities that are carried out in the corporate functions involved in the process and of the causal relationships existing among them. The process is then reconstructed starting from external input/output events and/or objects: this gives the Process Diagram (sometimes referred to as a process map or flowchart). The process model must therefore be validated with stakeholders involved in the process, using animation and simulation of its specification, obtaining the so called As-Is model. This model provides managers and engineers with a careful specification of the enterprise as it stands, out of which they can make: a) a good assessment of its status and b) an accurate estimation of available capabilities.
3) Process Diagnosis and Reorganization: the purpose of this phase is to trace back from the problems highlighted in the previous phase to possible solutions to be taken in order to restructure the As-Is model generating in this way the new To-Be version.
4) Information System and Workflow Implementation: when the To-Be model has been approved, it has to be transmitted to engineers for implementation. In the BP-M* methodology, two implementation aspects are considered: 1) the specification of the Information System environment, and 2) the specification of the Workflow execution environment.
Because the aim of this paper is the analysis of a real process, we will deal primarily with Phase 2 of the BP-M* methodology, other phases will not be discussed.
In the following, we describe the specification model used in the methodology.
3.2. The BP-M* Process Model
In the BP-M* approach, process activities do their job by working on transactions. A transaction is an object that flows through the process and represents such things as an order form in an order entry process, a patient which follows a surgical procedure, or a component in a manufacturing line.
The BP-M* Process Model integrates the process diagram with a description of how each activity deals with a transaction, how much time it takes and what are the necessary resources. The basic elements of the model are:
・ Activities. Activities take time to deal with a transaction and one of the primary objectives of a process modeling and simulation approach is to measure times and costs related to the process. In the BP-M*Process Model it is possible to define the period of time (duration) that each activity takes to deal with a transaction and to assign costs both to activities and to the resources used at the activities.
・ Resources. A resource is a person, machinery or an organizational asset used to process a transaction. In the BP-M* Process Model you can specify the amount of resources available, the behavior of resources, work schedules, and the allocation of resources to activities. When multiple transactions are processed, activities can contend for resources.
・ Times and Costs. The most common objectives of the process modeling and simulation tasks are to measure the time a process takes to be executed and to determine process and transaction costs. In a simulation, time is usually measured as the time required for a transaction to flow through a process, from an initial event to a final event which is usually referred to as cycle time. A cycle time typically includes the time required for each activity to deal with a transaction, and the time a transaction spends waiting in a queue to enter an activity or waiting for a necessary resource to become available. During a simulation, costs are accumulated and reported by transaction, by activity, and by resource.
Time and cost are closely related and you may find yourself trading one off for the other. For example, if you want to reduce processing time, you may add additional resources, but this may have the effect of increasing processing cost. On the other hand, you may reduce cost by reducing resources, but this may increase processing time. One of the great benefits of process simulation is to easily make this trade-offs and determine their impacts.
The new concepts that have been introduced to better characterize the process will be illustrated best during the analysis of the following case study.
4. The SPUN Case Study
Our case study is related to a public Contact Center (CC), called SPUN, which furnishes health and social information to citizens of an urban area of about 50,000 inhabitants in the northern Italy (the name SPUN is the acronym of Italian words “Sportello Unico”, which means Central Information desk). The existing wide spectrum of social and health agencies available to citizens provides many and very different benefits to peoples’ well-being, such as services, subsidies, incentives, facilitation or discounts. Sometimes, it is difficult for users to correctly address their needs, often involving different agencies at the same time.
The needs of users can range from very simple cases (such as the opening hours of a certain service) to more complex cases involving different public agencies, as well as the knowledge of rights and laws that are often difficult to access by people.
After several interviews with manager and operators of the office (Phase 1 of the BP-M* methodology), we documented the core aspects of the process in a SIPOC diagram. A SIPOC (Suppliers, Inputs, Process, Outputs and Customers) diagram is a high-level overview of a process that is used in different approaches to process improvement, such as the Six Sigma methodology  . In our case, the SIPOC diagram is detailed in Figure 1.
Suppliers are the users of the service, posing as input a request by calling the CC desk. Once the request is received, operators have to establish its type. For simple cases [41%], they directly answer to the call. In complex cases [59%], operators must obtain the necessary information by consulting manuals or other external agencies. The answer to the user’s request is the output object of the process that will be provided to the user who made the request. We analyzed real data about the functioning of the service in last five years. In particular, to be closer on today’s functioning, we focused on data about the type of contacts and the type of requests for the year 2016.
Figure 1. SIPOC diagram of the SPUN contact center.
First the type of contacts mostly concern phone calls from citizens, but contacts by operators of other organizations and agencies are also relevant. The direct access to the SPUN office by citizens is another important way to ask information, while the e-mail requests are of little importance, even if we notice an interesting increment in the last two years (see Table 1).
The argument of requests regards in majority Home care and Economic benefits, and this parameter is important because it is linked to the time that the operator spends to respond. For example, Table 2 shows the arguments of the requests and the average time used by the operator to communicate and explain the answer.
This type of generic analysis provides a first insight for managers on the operation of the Contact Center service.
According to the Phase 2 of the BP-M* methodology, activities, events and decision points of the CC process, and the causal relationships that exist among them were analyzed. Using the Business Process Modeling and Notation (BPMN) language  the CC process diagram is illustrated in Figure 2. The diagram has been designed with the iGrafx Process 2015  tool that supports the latest version of the BPMN language (BPMN2.0).
Table 1. Typology of contacts in the year 2016: number N of requests and percentage.
Table 2. Arguments of requests, count, percentage and average estimated duration (mi- nutes).
Figure 2. The contact center process diagram.
The diagram includes:
・ Four concurrent processes, the CC process and three Back-office processes.
・ Each process has an initial event (respectively, request, meeting, DB update and Other) and a final event (respectively, answer, end M, end UDB and end E).
・ Two lanes, SPUN Office and External Agency, which contain activities (rectangles with rounded corners) and gateways (diamonds).
・ Three timer events, T1, T2 and T3, representing a delay when operators take over the processing of the request as soon as possible.
・ An artifact, register, which represents a set of tables containing data on (simple and complex) requests and answers.
Process activities can be described as follows.
・ Analyze request. In this task the operator must decide whether the request is simple (the answer is known) or complex.
・ Provide immediate answer. When the answer is known, it must be provided to the client and then the operator updates the table of simple answers (Update Sregister activity).
・ Communicate recall. When the operator is not able to give an immediate response, the customer must be informed that there will be a recall until full information has not been recovered.
・ Collect information. The operator searches for the correct answer in the previous answers table and has to decide whether other organizations must be consulted.
・ Provide answer. When the answer is complete, it must be provided to the client and then the operator updates the table of complex answers (Update Cregister activity).
・ Obtain information. If the CC tables do not contain the required information, the operator will try to obtain the answer asking to other organizations or public agencies, and then update the answer table (Update answer activity).
The analysis of historical CC data has also allowed us to quantify the decision points (or gateways) of the process. In particular, the following gateways have been identified:
・ Immediate answer? Simple requests are immediately solved (and follow the Yes [41%] branch), while difficult ones (No [59%] branch) have to be processed in a more detailed manner.
・ External info? Several requests can be solved only by information existing in the CC internal tables (No [33%] branch), the other have to be solved with (at least) one external consultation (Yes [67%] branch).
・ Other info? A small percentage of requests require the consultation of more agencies (Yes [10%] branch), the other requests (No [90%] branch) do not require further investigation.
Back-office activities: Operators are engaged in other activities not directly related to customers, such as periodic updates of the database (Update DB) as well as meetings with stakeholders (Participate meetings) or the participation in other activities of the SPUN center (Exec other activities).
These activities can be represented as concurrent processes that operate in parallel to the main one and use the same resources.
5. Simulation and What-If Analysis
The simulation environment for the BP-M* Process Model is based on the iGrafx Process2015 tool which is very suitable for process mapping and simulation modeling in business process management projects. It not only allows to specify the process diagram, but also the extensions for the BPMN language required in the BP-M* Process Model can be taken into account, as the definition of resources, their allocation policy, the duration of activities and so on (see Section 3.2).
5.1. As-Is Model Development
The statistical analysis of the CC context provided quantitative information for the assessment of the execution time for the various activities of the process. Oftentimes the duration of an activity depends essentially on the type of request that arrives at the Contact Center; this raises the need to distinguish different types of request and can be done by introducing some attributes for the transaction which represents the incoming request.
An attribute is a variable used to communicate information and manage the flow of transactions through a process. Some common uses of attributes are:
・ Setting the duration of an activity based on the value of a transaction attribute.
・ Controlling the flow of a specific transaction through a decision output.
In our case study, we specified four attributes: contact, argument, agency, and needs. For instance, according to Table 1, the attribute contact (which can take the values: phone, direct, email and org) refers to the different ways in which requests arrive at the Contact Center desk, including: 1) by phone calls [phone: 46.8%], 2) from people who present themselves directly to the office [direct: 25.3%], 3) by e-mail [email: 0.8%] and 4) from other organizations [org: 27.1%].
The data on the type of request is used by iGrafx Process2015 to introduce the transactions during the simulation of the CC process. In particular, the generator which corresponds to the initial event request introduces 11 transactions per day distributed in a random manner in the intervals defined by the timetable of Figure 3. For instance, three requests arrive between 9.00 am and 10.30 am, and so on.
For each transaction, the distribution function setTypeOfContact returns a value for the attribute contact. For example, the intervals in Figure 4 specify that 46.8% of the time the function returns the value phone and so on.
The function setTimeOfContact (see Figure 5) is used to set the average duration of the activity Analyze request by mapping the set (phone, direct, email, org) into a set of time values.
Table 3 shows for each activity the temporal distribution that was used in the simulation.
Figure 3. The dialog box to deﬁne the transaction distribution.
Figure 4. The dialog box to deﬁne the setTypeOfContact distribution function.
Figure 5. The dialog box to define the setTimeOfContact function.
Table 3. Duration of activities (minutes).
In Table 3, TriangleDist(m;M;md) stands for a triangular distribution in the range minimum (m), maximum (M), and median value (md). Dist(m:M) stands for a uniform distribution in range from minimum (m) to maximum (M) value.
Figure 6 shows the dialog box to specify a resource. The figure explains the definition of number of resources, costs and overtime policy for the two operators that work together to respond to customer requests. The schedule is the working hours (between 9 am and 3 pm) of the SPUN office (and of the operators), and is described in another dialog box.
Figure 7 illustrates the specification of the duration (Task clause) of the activity Collect information by a triangular distribution TriangleDist(10;25;15). In the Resources clause, it is possible to specify the resources needed to perform the activity. For the SPUN case, all activities are performed by a single operator, except for the activity Participate meetings that requires both operators.
5.2. As-Is Model Validation
Once the As-Is model is completed with the description of resources and their use in the activities, generators of transactions to be entered during the simulation, and the time required by the activities, it is necessary to validate the model in order to check that it represents the system as it is and with all the aspects needed to build up new scenarios to increase the service level of the system.
The validation step can be easily performed if the process specification language is executable. In this case, it is possible to simulate the process and verify the validity of the model by comparing the values obtained from the simulation, for a set of indicators, with the same values measured on the real process.
In our tests, 150 weeks (about 3 years) of work of the Contact Center have been taken into account. The validation analysis has covered the average cycle time for the different activities of the process, resulting from the sum of the av-
Figure 6. The dialog box to define resources.
Figure 7. The dialog box to define the duration of the Collect information activity.
erage working time (the time spent by the operators during the execution of the activity) and the average waiting time (includes time waiting for resources necessary to the activity and the time in which the resources are inactive, for example, are outside working hours).
Table 4 shows the simulation results for the activities of the CC process. In the table, the G type for the Analyze request activity indicates that this activity is always performed, while the S or C type indicates that the corresponding activities are carried out only for simple (S) or complex (C) tasks.
The results shown in Table 4 were presented to managers and operators in the contact center who judged reasonable these simulated times based on their experience and an assessment with real data (controlled over a short period, about 3 months, of work).
The comparison between simulated and actual times concludes the validation step for the As-Is model which is then ready for the analysis of possible different scenarios.
5.3. What-If Analysis
A scenario can be defined as a description of a possible future situation. Scenarios are not meant to be a complete description of the future, but rather to consider the basic elements of a possible future and to draw the attention of analysts to the key factors that can help to effectively improve the process.
Table 4. Average times (minutes) for the activities of the CC process.
Scenarios will be compared on the basis of a significant set of indicators. Literature is full of indicators on contact centers  , typically focused on the quantitative aspects of the service. In particular, in agreement with the Contact Center management three groups of indicators were taken into account:
1) Service Level (SL). A common way to define Service Level is by looking at the fraction of requests answered within a defined time frame (usually called the Acceptable Waiting Time-AWT). A typical value is that 80% of all calls has to be answered in 20 seconds  , but for the SPUN case is not important to be fast, but to respond completely and correctly. According to the manager, a particularly interesting indicator is the service level for complex requests. In this case, a 12-working-hours AWT is considered acceptable (higher delays are not), so the SL indicator will be evaluated as the percentage of complex requests handled before the AWT, over the total number of complex requests. According to management, values higher than 80% are considered satisfactory.
2) Resource Utilization (RU) measures the average percent of time operators are actively occupied on a request.
3) Cost Per Contact (CpC). In our case, only the cost of operators has been taken into account because the Contact Center desk is housed in a public center and then other costs (infrastructure, energy, rents and so on) were not considered relevant by the management.
In the BP-M* approach the specification of the scenarios to be analyzed is very simple if they can be defined as changes to be made to the As-Is model parameters. According to the managers, four different types of scenarios have been considered for our case study, which will then be compared with the baseline scenario provided by the As-Is model of the CC process (Base scenario):
1) Workload (S1): two increments (20% and 40%) of the workload will be considered, from 11 requests per day to 13 requests (S1.1) and 15 requests (S1.2).
2) Mixing of requests (S2): two different mixing will be considered, S2.1 (60% simple, 40% complex) and S2.2 (25% simple, 75% complex).
3) Opening hours (S3): in the first sub-scenario (S3.1) the opening time is limited in the morning (between 9 am and 1 pm) from Monday to Friday, with the same workload of 11 requests per day (reduction in service opening time). In the second sub-scenario (S3.2) the service opening time is also extended to Saturdays (between 9 am and 1 pm) but the workload remains roughly the same as the Base scenario (9 requests for 6 days are expected).
4) Composite scenario (S4): different types of change can be applied simultaneously. For example, we can assign to simple requests a higher priority than the one reserved for complex requests (priority change) and introduce tools to improve response times. In fact, we plan to install an integrated information system and the assisted search of the answers should improve response times, lowered by at least 20%.
Each scenario has been simulated on the basis of 150 weeks and the results are shown in Table 5. Note that:
a) SL: for what concerns the Service Level, only complex requests have been considered because simple ones did not present any particular problems.
b) RU: for what concerns the Resource Utilization, account has been taken for all the activities carried out by operators (including back-office activities).
c) CpC: for what concerns the costs per contact, they are considered separately for simple (CpCS) and complex requests (CpCC) as their values are significantly different. Costs are reported in euros.
Let us start on the Service Level SL, which is focused on complex requests (they have a stronger impact on the process as a whole).
As shown in Table 5, the reduction in opening time (S3.1 and S3.2) greatly influences the delay in answering to complex requests: the service level drops to about 50%, which means that about half of requests exceeds the acceptable waiting time. At the same time, resources become overweighed (resource utilization RU increases up to about 90% in both S3.1 and S3.2 scenarios). Even the increase in complex requests (Scenario S1.2) produces the same result. In both cases, the level of service is not satisfactory.
Focusing on costs, only scenario S4 shows a significant reduction in cost per contact (about 5% for complex requests and 10% for simple ones). This means that the costs for the organization are roughly proportional to the number of contacts and, for example, costs related to scenario S1.2 (40% increase in contacts) have been considered hard to deal with by management.
Table 5. Resource utilization, service level and costs per contact (simple and complex).
The simulation results of the various scenarios were considered very interesting by the service manager and are currently being studied to determine whether or not it is possible, and how, to improve the organization of the contact center.
In this paper, we described a model-based approach, the BP-M* framework, to design and reason about the organization’s business environment, with a focus on Key Performance Indicators.
The BP-M* framework includes a methodology to model, validate and analyze business processes, and an extended process model that allows the simulation of the actual (As-Is) process. A “What-If” analysis of scenarios which describe possible evolutions of the actual process has been introduced and in this way analyst scan get useful suggestions for deciding on the most appropriate restructuring actions to improve the process efficiency (To-Be model).
The possibilities offered by the BP-M* framework have been illustrated through the complex case study SPUN, which describes the behavior of a public Contact Center that answers to different typologies of users’ requests. The SPUN case has demonstrated that it is possible to build an accurate model of the process being tested, able to be validated and analyzed by a powerful discrete event simulator.
The simulation allows to easily study a number of possible operational scenarios (“What-If” analysis), thus providing the analysts with useful information to evaluate the restructuring actions on the CC process. In the near future, the phases of the BP-M* methodology that have not been discussed in this article will be considered and illustrated with the help of the SPUN case study.
We are grateful for collaboration to managers and operators of the SPUN Contact Center of the Consorzio Sociale “Il Filo da Tessere”. SPUN is a project financed by two Italian public institutions, ASL BI and Cissabo.