{'fraction_non_alphanumeric': 0.02916495831624983, 'fraction_numerical': 0.01104277709443761, 'mean_word_length': 4.582239853524565, 'pattern_counts': {'":': 0, '<': 5, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Discovering Business Process Simulation Models in the Presence of Multitasking

Business process simulation is a versatile technique for analyzing business processes from a quantitative perspective. A well-known limitation of process simulation is that the accuracy of the simulation results is limited by the faithfulness of the process model and simulation parameters given as input to the simulator. To tackle this limitation, several authors have proposed to discover simulation models from process execution logs so that the resulting simulation models more closely match reality. Existing techniques in this field assume that each resource in the process performs one task at a time. In reality, however, resources may engage in multitasking behavior. Traditional simulation approaches do not handle multitasking. Instead, they rely on a resource allocation approach wherein a task instance is only assigned to a resource when the resource is free. This inability to handle multitasking leads to an overestimation of execution times. This paper proposes an approach to discover multitasking in business process execution logs and to generate a simulation model that takes into account the discovered multitasking behavior. The key idea is to adjust the processing times of tasks in such a way that executing the multitasked tasks sequentially with the adjusted times is equivalent to executing them concurrently with the original processing times. The proposed approach is evaluated using a real-life dataset and synthetic datasets with different levels of multitasking. The results show that, in the presence of multitasking, the approach improves the accuracy of simulation models discovered from execution logs.


Introduction
Business process simulation (BPS) is a widely used technique for analyzing quantitative properties of business processes. The basic idea of BPS is to execute a large number of instances of a process, based on a process model and a number of simulation parameters, in order to collect performance measures such as waiting times of tasks, processing times, execution cost, and cycle time [1,10]. BPS tools (simulators) allow analysts to identify performance bottlenecks [18] and to estimate how a given change to a process may affect its performance [16].
The accuracy of a process simulation, and hence the usefulness of the conclusions drawn from it, is to a large extent dependent on how faithfully the process model and simulation parameters capture the observed reality. Traditionally, process models are manually designed by analysts for the purpose of communication and documentation. As such, these models do not capture all the intricacies of how the process is actually performed. In particular, manually designed process models tend to focus on frequent pathways, leaving aside exceptions. Yet, in many cases, exceptions occur in a non-negligible percentage of instances of a process. Moreover, simulation parameters for BPS are traditionally estimated based on expert intuition, sampling, and manual curve fitting, which do not always lead to an accurate reflection of reality [18].
To tackle these limitations, several authors have advocated the idea of automatically discovering simulation models from business process execution logs (also known as event logs) [13,8]. Simulation models discovered in this way are generally more faithful since they capture not only common pathways, but also exceptional behavior. Moreover, automated approaches to simulation model discovery typically explore a larger space of options when tuning the simulation parameters compared to what an analyst is able to explore manually.
The automated discovery of BPS models from event logs opens up the possibility of capturing resource behavior at a finer granularity than manual BPS modeling approaches. In particular, Martin et al. [14] demonstrated the possibility of discovering fine-grained resource availability timetables from event logs and the benefits of using these timetables to enhance the accuracy of BPS models.
Inspired by this possibility, this paper studies the problem of discovering another type of resource behavior, namely multitasking, from an event log. Multitasking refers to the situation where a resource executes multiple task instances simultaneously, meaning that the resource divides its attention across multiple active task instances [15]. The inability to capture multitasking behavior has been identified as a limitation of existing BPS approaches, for example in [2].
Concretely, the paper proposes an approach to discover multitasking behavior from an event log and to generate a BPS model that takes into account the discovered multitasking behavior. The key idea is to adjust the processing times of task instances in such a way that executing the multitasked task instances sequentially with the adjusted times is equivalent to executing them concurrently with the original processing times. Once the event log is adjusted is this way, we discover a BPS model using existing BPS model discovery techniques, namely those embedded in the SIMOD tool [9]. The proposed approach is evaluated using a real-life dataset and synthetic datasets with different levels of multitasking.
The rest of this article is structured as follows. Section 2 motivates our research. Section 3 introduces basic concepts and related work. Section 4 describes the proposed approach. Finally, Section 5 reports on the evaluation of the approach while Section 6 draws conclusions and outlines directions for future work.

Motivation
During business process execution, certain events are recorded which capture, for example, the moment when a task instance started and ended, the resource that executed the task instance, etc. Such events are stored in event logs, which can be used to analyze the performance of the process or to discover process models that faitfully reflect the actual execution of the process.
Sometimes, the events associated to a given resource in an event log may show that the resource started a task instance before completing a previous one. Hence, during some period of time, the resource performs multiple task instances simultaneously, a situation known as multitasking. Multitasking arises, for example, when a resource postpones the completion of a task due to missing information. While this information becomes available, the resource may start another task instance to avoid idle times. Figure 1 represents a subset of four tasks carried out by resource R1, where each continuous line represents the duration of each task. These four tasks result in seven execution intervals. In intervals A(0-10), C (75-95) and G(140-150) only one task is executed, T1, T1 and T3, respectively. Other segments reflect multitask execution: in B (10-75), D(95-110) and F (130-140) two tasks are executed (T1, T2), (T1, T3) and (T3, T4), respectively; and in interval E (110-130) multitasking is performed between three tasks (T1, T3, T4). These tasks may belong to one or more traces. A trace contains the ordered sequence of events observed for a given process instance [10]. An event log is composed of one or more traces.
Given the data of this event log segment, a traditional simulator would calculate a total execution time of 280 minutes, because it would take each duration individually, one task after the other. However, in Figure 1, it is possible to see that all tasks are executed between the 0 and the 150 minute. This means that during certain intervals, the resource R1 divided its time and attention into more than one task. Therefore, it would not be correct to consider as total task execution time the time between the start and end record of the task, but the time should be distributed among all the tasks that overlap in a given period.
Since there is usually no detailed record of the specific time that each resource spends on the execution of each task in multitasking scenarios, we consider it necessary to propose a mechanism to adjust processing times to reflect the time spent by each resource more accurately.

Background and Related Work
In a simulation scenario, a work item is created during a process simulation, when a task is ready to be executed, which can be seen as an instance of a task that will be executed [19]. A simulator tries to assign each work item to a resource. Once that it is been assigned, the simulator determines the work item duration and that work item is placed in suspend mode during the assigned duration time. When the duration time ends, the work item is considered completed and the resource is again available to be used by another work item [10].
Many efforts have been made to try to simulate process models as close to reality as possible. However, simplifications of these processes are still needed due to the technical limitations of certain simulators [3]. One of the areas of interest that still has deficiencies is related to the behavior of resources involved in a process execution. Several workflow resource patterns are presented in [19], describing how resources are represented and used in a workflow. However, behaviors such as described in [1] and [2] have not yet been fully incorporated into simulation techniques. On the basis of patterns described in [19], Afifi et al. presented in [5] and [4], the extension of BPSim, the Business Process Simulation Standard [20]. BPSim provides a metamodel and an electronic file format to define process models including simulation-specific parameters. However, a tool to support for this proposal is suggested as future work.
Ling et al. [11] propose a prototype simulation tool that considers differences between resources based on their experience and on personnel movements such as recruitment, transfer and resignation. However, this proposal does not consider the possibility of performing more than one task in a given time instant. Although Ouyang et al. [15] point out that real business processes are resource-intensive, where multitasking situations are typical, their study focuses on proposing a conceptual model, in which its possible to model and schedule the use of shared material resources, such as surgical material that is shared by several doctors during a surgical operation; but unlike our proposal, the authors do not analyze real execution data, nor do they simulate proposals for the use of shared resources, since their implementation is proposed as future work.
In the approach proposed by Rusinaite et al. in [18], resources (human or not) are classified as shareable resource, to indicate a resource can be used by several activities simultaneously; and non-shareable resource, when a resource is allocated to only one activity at a time. For the modeling and simulation a resource is defined by means of attributes of capacity (reusable or consumable) and shareability (shareable and non-shareable). A simulation engine was used to validate the proposal, where authors found that when two or more resources are available, average time decreased considerably as shared resources are used. From the shared use of five resources, the difference in time was less noticeable. Authors do not specify how shared times are defined and calculated. One inconvenience of this proposal is the need to know beforehand the characteristics of the resource being used. On the contrary, in our proposal, we use event logs to identify if a (human) resource has been running simultaneous tasks and to determine the fragments of time in which the tasks were executed simultaneously.

Approach
As explained in Section 2, a resource can start a work item before finishing one or more work item he/she started before, but simulators are not capable of taking this behavior into account. To cope with this lack, we propose to pre-process event logs to adjust the processing times, which is to proportionally divide the interval of execution time where different tasks intersect by the number of tasks involved. In this way, multitasking can be approached without modifying the structure and operations of the simulators. Figure 2 shows how the duration of multitasked intervals ( Figure 1) are distributed proportionally among the number of tasks in each interval. For example, in interval B, the total time (65 minutes) is divided proportionally between tasks T1 and T2 (32.5 minutes for each); or in segment C, three tasks are executed, so the 20 minutes of its duration are divided between tasks T1, T3 and T4. In this way, the new task execution times are more similar to the real dedication of the resource. The objective of pre-processing event log is, on the one hand, to identify the resources that perform multitasking, determine in which time periods the multitasking execution is performed and to make an adjustment of the work item duration times according to the multitasking periods. And, on the other hand, to determine how the multitasking execution intervals influence the general performance of the business process. We assume that resources are involved in only one business process at a time.
The following definitions describe step-by-step how the event log is preprocessed. To do this, we begin by formally defining the concepts of event, trace, event log and work item.
Definition 1 (Events, Attribute). Let E be the set of all possible events that occur during a process execution. Let's assume an event e can be described by means of a set of attributes att, where att = {id, type, r, st, et}, id is the identifier of the event; type represents the event type, the activity name; r represents the resource that performs the event; st indicates the event start timestamp; et indicates the event end timestamp. In such a way that, for example, att r (e) = e r = r 1 , where r 1 is a particular resource performing e.
Definition 2 (Trace). Let T be the set of all possible traces defined as a sequence of events, such that, σ ∈ T , σ =< e 1 , e 2 , ..., e n > Definition 3 (Event Log). An event log can be defined as a set of traces, L ⊆ T , where L =< σ 1 , σ 2 , ..., σ n > Definition 4 (Work Item). Let wi be a work item representing an event in a process simulation, in such a way that wi ≈ e. Therefore, a trace can be represented as a sequence of work items, such that σ ∈ T , σ =< wi 1 , wi 2 , ..., wi n >.
As with events, a work item has the set of attributes att. For example, att r (wi) = wi r = r 1 , where r 1 is the resource that has the wi assigned to it.
Multitasking can be generated by work items generated in a single trace or by work items belonging to different traces. In this proposal, the broadest case is considered, so all traces in which each resource participates is considered. In order to identify the task (and work items) in which a resource perform multitasking, the log L is divided into as many Segment per Resource as there are resources in log. Each segment consists of all the work items of each resource in L, which will be ordered according to the start timestamp of each work item (wi st ). Figure 1 represents one Segment per Resource (sr 1 ) with four work items for resource R1.
Definition 5 (Segment per Resource). Given an event log L, R represents the set of all possible resources that execute at least one work item in any trace in a log L. Such that, ∀r ∈ R, ∃wi ⊆ T ⊆ L | wi r = r Then, let S be the set of all possible ordered subsets of work items conforming the traces of a log, in such a way that Having divided L into different (sr i ), the Sweep Line algorithm [6] is applied to each sr i to identify intersection points between work items determined by their start and end timestamps. For each pair of intersection points between the different work items, auxiliary work items (wiaux) are created.
To identify the set of wiaux, first, for each segment per resource sr i an ordered list of time (ordtimes) is created, where ordtimes = { point 1 , point 2 , ..., point n }. Each element of the list, called points, is a tuple point i = (tstamp i , wiid i , symbol i ), where tstam i could be a start timestamp or an end timestamp of any of the work items in sr i ; wi i id is the identifier of the work item with start or end timestamp equals to tstamp i ; symbol i could be '+' if tstamp i corresponds to a start timestamp, or '-' if it is an end timestamp; and wi i is the complete work item used to obtain the other values of the tuple.
Once the ordtimes i has been created, concrete intervals of time intervals i are specified, identifying also the work items wi n that are being executed for each interval, intervals i = {(start int 1 , end int 1 , list wiids 1 ), ..., (start int k , end int k , Based on the above definitions, Algorithm 1 describes how the adjustment of task execution times is performed taking into account the number of tasks that are simultaneously executed by a resource, by means of the creation of the lwiaux list. Applying the Definition 6 and the Algorithm 1 to the scenario depicted in Figures 1 and 2, the set of values presented in Table 1 are obtained. From L it is possible to generate a "coalescing log" L that contains a set of coalesing work items wicoal. Each wicoal is the result of the sum of the pre-processed times (wiaux) of each original wi in L.
From the above definitions we can deduce that: ∀L∃L , L | L ≡ L ≡ L ∧ len(L) ≤ len(L ) ∧ len(L ) ≥ len(L ) ∧ len(L) = len(L ) In addition, if len(L) == len(L ) there is no multitasking, because the execution times do not intersect for any work item of any resource in the event log L and ∀wi i ∈ L | wi i = {wiaux i } The level of multitasking in a given log, is determined by the amount of overlap between the execution times of pairs of events in a log, for a given resource, in proportion to the number of total pairs of events that can be formed between the work items of each sr i . In order to determine the level of multitasking in a given log L, we propose a measure called Multitasking Log Index (MTLI ). To calculate the M T LI of a log L, we based on the idea that a log is divided by grouping all the work items of a given resource (r), generating sr i ∈ S (See Definition 5). The multitasking of a log is derived from the overlap between the execution times of two work items executed by the same resource. Therefore, for each sr i , let W I sr be the set of all possible work items in sr i and SRW I r be the set of all possible pairs of work items in sr i .
For each pair of events (wi 1 , wi 2 ) i ∈ SRW I r , 1 < i <| SRW I r |, an overlap function is calculated as the maximum between the zero and the difference of the minimum of the end timestamps of the work items and the maximum of their start timestamps; divided by the maximum value of the duration of the two work items. The Multitasking Work Items Index (MTWII) is another measure related to multitasking that is calculated in a very similar way that M T LI, but in this case, only overlapped pairs of events are considered. The set of all possible overlapped pairs of events for a resource is defined as follows.
The function overlap(wi 1 , wi 2 ) is calculated the same way. Now, the value of M T RI r is calculated only for those pairs of events ovelapped (M T RI or ).

Evaluation
The pre-processing of an event log for the identification of multitasking work items, the overlapping time periods, the adjustment of the execution times for these work items and the calculation of multitasking indexes is done by means of a Sweeper Python script. It receives as input a base event log (L) in eXtensible Event Stream (XES) format and generates as output an event log with the adjusted times according to the multitasking previously identified (L ). The L must contain work items with at least the task name, the resources that executed the work item, and the start and end timestamps for each work item. An identifier for each work item is assigned during pre-processing. In addition, the events in the log must reflect multitasking in order to perform the analysis. Based on these restrictions, the evaluation was twofold and was performed using a real event log and a set of synthetic logs. Event logs 3 and scripts 4 are available online. The experiments were carried out on a computer using Windows 10 Enterprise (64bit), a processor Inter Core i5-6200U, CPU 2.3GHz and 16.0 GB RAM.
In both real and synthetic cases, after generating the event logs with the adjusted times derived from multitasking, the SIMOD tool [9] was used to discover business process simulation models. This tool uses the hyper-parameter optimization technique "to search in the space of possible configurations in order to maximize the similarity between the behavior of the simulation model and the behavior observed in the log". Process models are discovered using the Split Miner algorithm [7], which considers different levels of sensibility and depends on two parameters: the parallelism threshold, epsilon( ) that determines the quantity of concurrent relations between events to be captured; and the percentile for frequency threshold, eta (η), that acts as a filter over the incoming and outgoing edges of each node and retains only the most frequent percentiles. Both parameters are defined in a range between 0 and 1. The resulting simulation models can be executed using Scylla [17] and BIMP [12]. As in [8], we use BIMP because it allows a wider set of distribution probabilities to be used, thus widening the space for configuration options. During SIMOD executions, an objective evaluation of the results is made by means of similarity measures which will be described in more detail in the following subsections.

Evaluation based on a Real-life Event Log
The objective of this section is to identify the actual accuracy gains of the proposal, using a real-life event log. The hypothesis in this scenario is that adjusting execution times derived from multitasking provides more accurate execution results, reduces the total execution time of tasks and processes; avoid over-utilization of resources due to sequential simulation of task execution; and maintains the correct alignment of the model generated according to the original model derived from the log. The real event log represents an academic credentials recognition (ACR log) process in an University during the first semester of 2016. This log has 954 traces, 18 tasks, 6870 events and involves 561 resources.
Experimental setup. The validation process is divided into the following steps: 1. Create the adjusted log. Execute the sweeper.py script using the ACR log to generate a new event log with the adjusted times (ACR adjusted log). 2. Calculate measures.
-The execution of the Sweeper script also provides a set of values and indexes to identify the level of multitasking in the ACR log.
-The hyper-parameter optimization of SIMOD was used with both logs to obtain similarity measures in each case. 50 BPS models were generated using different setup combinations of processing parameters. Parameters and η varied from 0.0 to 1.0. Each BPS model was executed 5 times, for that, 250 simulations were evaluated for each of the both event logs.
-Finally, Apromore 5 can be used for the comparison of processing times and BIMP 6 to analyze resource utilization values.
3. Analyze the results. Compare values between two logs.
Analysis of results. Executing SIMOD using the ACR log, very similar results were obtained to those presented in [8], using half number of simulations. In that proposal, the similarity measure Timed String Distance (TSD) is calculated. TSD is a modification of the distance measure called Demerau-Levinstein (DL) that assesses the similarity between two process traces. TSD allows to include a penalty related to the time difference in processing and waiting times providing a single measure of accuracy. In [8], TSD is equal to 0.9167. In our experiment, TSD is equal to 0.906 with =0.615 and η=0.559. Executing ACR adjusted log, similarity measure is equal to 0.929 with =0.484 and η=0.591.
The difference between similarity values of both logs is 2.54%. Although this value may seem low, it should not be seen by itself; it should be analyzed in relation to the amount of multitasking identified in the log. Table 2 shows the characteristics related to the content of the event log. Out of the 18 tasks in the event log, 17 are overlapped in at least one instance (work item) within the log. From the 6870 events (work items), 1267 are overlap with at least one other event. Out of the 561 resources involved in the log, 76 executed at least one event with multitasking. Finally, after grouping all events according to the resource that executed them, 1116776 pairs of events were identified. Of all of them, 1036 are overlapped in some period of their execution time. This last feature is very significant as it indicates that the log used for this analysis actually has a low amount of multitasked events. This is a possible reason why the percentage of similarity improvement was quite low (2.54%). In addition, from the BPS model results generated by SIMOD, it is possible to extract the Average Cycle Time of each simulation. When comparing the results of both logs, an improvement of approximate 14% of the ACR adjusted log with respect to ACR log was obtained. As mentioned in Section 4, Multitasking Log Index (MTLI) is another measure that helps identify the percentage of multitasking in the entire event log. For the ACR log, M T LI = 1.05%. If M T LI is low, one would expect the rate of improvement in the analysis to be low as well, but as the level of multitasking in the log increases, the measure should improve proportionally. This indicates that when analyzing all possible pairs of events, only the 1.05% of the time of those events were overlapped, which represents low level of multitasking. For the same log, the Multitasking Work Item Index is M T W II = 58.54%, that indicates that, for those events where multitasking has been identified, the pairs of events are overlapping by 58.54% of their total duration.
Using Apromore, ACR log and ACR adjusted log were analyzed and compared in terms of time. Figure 3 shows the average duration of process tasks. Blue bars represent the average time duration of ACR log tasks and red bars the average time duration of ACR adjusted log tasks. Both RD and HGR reflect a difference of 0.6 hours (h), followed by HGR with 0.43 h; EC and CC with 0.35h; CS, VBPC and RC with 0.15 h; VS 0.07; VSPH 0.04; VF with 0.02 h; RSH does not show improvement; and the last 6 task do not reflect improvement either, but can be considered activities of instant duration. Finally, using BIMP, three resource pools were identified and slight differences in the percentage of resource utilization were noticed.
In general, the above results show that with the pre-processing of log it is possible to effectively reduce processing times of tasks and to maintain and/or improve similarity between traces involved in each log. Besides, we figured that the level of improvement in the results depends on the multitasking level in the log: the number of event pairs overlapped and the percentage of overlap between each event pair. As we have only been able to identify and use one real-life log with multitasking characteristics to show dependence between the amount of multitasking and the result improvements, in the following subsection, a synthetic log was modified to generate a log set with different multitasking levels.

Evaluation based on a Synthetic Log
The objective of this section is to identify how the level of multitasking affects the discovery and simulation of BPS models. Our hypothesis is based on the assumption that the results of BPS models vary and are enhanced depending on the amount of overlap identified in each log. This scenario is composed of a set of event logs derived from a synthetic log called PurchasingExample.xes. This is one of the public event logs available through the SIMOD distribution [9] that was generated from a purchase-to-pay process model not available to the authors. This event log, which does not contain multitasking characteristics (PE 0P log), has 608 traces, 21 tasks, 9119 events and involves 27 resources.
Experimental setup. The validation process if divided into the following steps: 1. Selection and preparation of the base log. The PE 0P log base log does not contain multitasking characteristics. Therefore, when calculating their multitasking indexes they have a value of zero. New logs were generated using different percentage of shifting (overlap between events or work items) for each log. To generate the new event logs, we implemented a Python script (percentage.py) that, given a percentage of shifting (between 0.0 and 1.0) generates a new event log in XES format including events overlapped in that percentage of their processing times. The script algorithm works as follows.
-The base event log is divided by grouping the events that are executed by a particular resource (see Description 5, segment per resource). -The events of each segment per resource are ordered according to their start timestamps. -For each segment per resource, the first event is taken as the pivot and the next adjacent event is searched among the remaining events. Two events (e 1 , e 2 ) are adjacent events if the end timestamp of e 1 has the same value as the start timestamp of e 2 . In Figure 4.a, the first pair of events shown are adjacent events. -When a pair of adjacent events are identified, the timestamps are shifted depending on the percentage assigned. In Figure 4.b, 20% of shifting is applied, while in Figure 4.c, the shifting is 40%. -The two events of a pair of adjacent events are excluded from the following search. The next event in the segment per resource is taken as pivot and the search is repeated. If no adjacent event is found, it is not modified and the search is repeated with a new pivot. -The search of adjacent events is repeated for all segment per resources. -The resulting log will have a multitasking percentage MTWII similar to the percentage of shifting indicated in the script, although we will comment this value may vary. However, the total percentage of multitasking in the log (MTLI ), depends on the number of adjacent events identified. 2. Generate the set of adjusted logs. The Sweeper script is run on each of the logs generated in the previous step. 3. Calculate measures.
-Using the Sweeper script the multitasking indexes in the log were calculated (MTWII and MTLI ). -The hyper-parameter optimization of SIMOD was used with each log to obtain similarity measures in each case. To do that, 100 BPS models were generated using different setup combinations of processing parameters. Parameters epsilon and eta varied from 0.0 to 1.0. Each simulation model was executed 5 times, for that, 500 simulations were evaluated for each log in the set. -BIMP can be used to analyze the resource utilization percentages.

Comparison and analysis of results.
Analysis of the results. The set of synthetic event logs was made up of 6 logs. The PE 0P log and 5 more logs built using the Percentage script with the PE 0P log as a base log and using a percentage of shifting of 5%, 10%, 15%, 20% and 25%. With regard to resources, in PE 0P log participate 27 resources and 11 of them reflect multitasking. From the 9119 events in PE 0P log, 2625561 pairs of events were identified. From these, 789 are adjacent events to be used for time shifting of the logs, excluding in this set all instantaneous events. Table 3 shows the percentage of shifting applied to the adjacent events in each generated log; the multitasking indexes (MTWII and MTLI ) for each log in the set; the number of pairs of events in which overlapping was identified (multitasking); and the value of two similarity measures obtained using SIMOD. DL-Mean Absolute Error (DL-MAE ) assesses the similarity between two traces evaluating an attribute, in this case the cycle time of traces, and the Mean Absolute Error (MAE ) of the cycle time traces expressed in seconds.
The percentage reflected in the column MTWII should be the same as Shifting, because the number of adjacent events on which the shifts were made was the same for all the logs. However, certain MTWII values are slightly higher since the shifting of some events may generate overlapping between events that initially were not adjacent. This is also reflected in the column Overlapping Pairs, where the number of pairs of events overlapped is greater than 789 and increases as the shifting increases. Above a certain amount of shifting, the value of MTWII is less than the percentage of shifting. This is because a shift can cause one event to be embedded within another (Figure 4.c), and if the shifting increases, the event is still embedded and does not provide more multitasking to the log. As could be deduced by identifying the number of events in the log, the MTLI is quite low. However, like MTWII, it increases when the percentages of shifting increase. Similarly, since the amount of multitasking in the log is low, the difference between DL MAE values varies and improves slightly for those cases where the percentage of shifting is quite similar to MTWII (0, 5, 10, 15) and worsen slightly for those cases where the shifting and index vary more. Finally, when calculating the MAE we see that although there is a significant difference between a log with and without multitasking, as the multitasking is increased, and the adjustment in the logs, the MAE is gradually reduced, which means that the discovered BPS models are more accuracy. BPS models were simulated using BIMP. 5 resource pools were discovered, two of them with high percentage of resource utilization (RU). The RU in BPS models derived from multitasking is reduced, especially for those resource pools where the RU is higher.

Conclusion
This paper outlined an approach to discover BPS models that take into account multitasking behavior. Specifically the paper showed how to pre-process an event log in order to discover multitasking behavior and how to adjust the processing times of tasks in such a way that the resulting log does not contain multitasking behavior, yet the resource utilization in the resulting log is equivalent to that in the original log. In this way, the BPS model discovered from the pre-processed log takes into account the multitasking behavior but can be simulated using a traditional process simulator (e.g. BIMP). The evaluation showed that, in the presence of multitasking, the approach improves the accuracy of BPS models. We also identified that the greater the percentage of overlap in multitasking events in a log, the more the approach improves the accuracy of the generated BPS models. The experimental evaluation was restricted to one real-life and the amount of multitasking in this logs was low, so it was difficult to generalize the results. The evaluation on synthetic logs partially addressed this limitation by introducing varying levels of multitasking. Still, the obtained levels of multitasking remained relatively low due to the approach employed to add multitasking behavior in the synthetic log.
The discovery of simulation models is key to the setup of as-is scenarios that allow the reliable evaluation of what-if scenarios focused on process optimization. Processes are dynamic and the results of their execution may vary over time, largely due to the behavior of the human resources involved, and this characteristic is independent of the defined process model. Even in those cases in which the process is not clearly defined and only execution records are available, simulation models obtained allow the analysis of processing times or resource utilization rates, which can be influenced by human behavior such as multitasking, batching or delaying of low-priority tasks.
A possible direction for future work is to extend the evaluation to other real-life logs with higher levels of multitasking. The challenge here is that event logs where both the start and end times of tasks are available are generally not available in the public domain. An alternative approach is to design new methods for generating realistic synthetic logs with high levels of multitasking.
The present work was limited to multitasking across multiple instances of one business process. Another avenue for future work is to discover and handle multitasking across multiple business processes. The latter would require the ability to simulate multiple business processes simultaneously.