Data-Driven Analysis of Batch Processing Inefficiencies in Business Processes

In this section, we present the evaluation of our approach. First, we use a synthetic event log with artificially injected batches. With this experimentation, we validate the ability of our technique to discover batching behavior and analyze the different types of waiting times. Second, we apply our approach to a real-life event log to demonstrate its applicability in real-life scenarios. The implementation of the approach, as well as the event logs and results of the experiments, are available on GitHubFootnote.

Experiments with Synthetic Data

For the synthetic evaluation, we artificially added batches to a simulated event log of a loan application process with the specific purpose of evaluating if our technique was able to detect them. To do this, we first grouped the activity instances of three activities of the process. Then, we assigned a new resource to each group to ensure that the activity instances of a batch did not share their resource with other activity instances. Finally, we delayed the start and end timestamps of the activity instances of each group (as well as the timestamps of succeeding activity instances) to force their execution as a batch.

To increase the variety in the synthetic evaluation, we added batches of different sizes (10, 12, and 14) and types (parallel, sequential, and concurrent) to three different activities. We left some activity instances unaltered, so not all their executions were processed in a batch. Furthermore, for some batches, we designed the batch activation to be performed based on temporal rules, e.g., at a specific time of a specific day of the week. Finally, the waiting times were also altered to create batches with different characteristics, e.g., with or without the waiting time of a ready batch.

We evaluated our approach with this event log, resulting in the discovery of all artificially added batches. Moreover, due to the displacement of the batch processing activities and their successors, batch processing was also detected in other activities. The discovered activation rules corresponded to the designed temporal constraints, indicating the day of the week and hour of activation. Finally, the performance analysis detected the correct waiting times and CTE, accurately reporting cases in which some waiting times were set to 0.

Experiments with a Real-Life Log

This section demonstrates how batch processing inefficiencies can be identified by applying our approach to a real-life event log of a manufacturing production process. This event log has 225 traces, 26 activities, 4953 events, 48 resources and does not contain multitasking (i.e. the resources do not work in more than a task at the same time).

Batch Processing Discovery. We applied our approach to a real-life event log. First, we discovered batch processing activities from the event log. We set the minimum batch size threshold to two cases with no in-batch time gaps (intervals between the case processing within a batch) allowed. The output of this step is a report showing each batch processing activity, their case frequency, and batch processing frequency (see Table 1). From the report, we see that, for this event log, 12 activities had batch processing. The activities are sorted in descending order based on batch processing frequency. For each activity, the report shows the case frequency and the batch processing frequency. From the report (Table 1), we note that activities "Lapping", "Packing", and "Turning Rework", have high batch processing frequencies (91.07%, 83.75%, and 66.67% respectively). These cases are predominantly processed in batches and, therefore, relevant for batch efficiency analysis. However, the "Turning Rework" activity is executed for a comparatively negligent amount of cases (for 1.33% of total cases) and, therefore, has little impact on the process efficiency and is not considered for further analysis. Thus, the report shows that "Lapping" and "Packing" have high batch processing and case frequencies, and therefore, an analyst might decide to select these as an input for the next step.

Table 1. Batch processing discovery results.

Table 2. Batch processing analysis results.

Waiting time analysis. Having discovered the batch processing behavior, we focus on quantitatively analyzing the waiting times. The output for this step is a report that measures average waiting times per type and their impact on batch processing CTE (Table 3). For each activity, the average processing time (PT in Table 3) and the average waiting times per type are calculated ($WT_{accum}$, $WT_{ready}$, $WT_{other}$ in Table 3).

Table 3. Waiting time analysis results.