Data-Driven Analysis of Batch Processing Inefficiencies in Business Processes

In this section, we present the proposed approach for discovering batch processing inefficiencies. First, we present an overview of the approach and then provide a more detailed description of each step.

Fig. 1. Overview of the proposed approach

The approach for identifying batch processing inefficiencies consists of three steps (see Fig. 1). First, given an event log, the batch processing activities - i.e., the activities that are executed in batches - are discovered. The output of this stage is a report listing such activities, as well as the frequency of their execution being part of a batch. The second step is to analyze their batch processing behavior, i.e., type of batch processing, batch size distribution, and batch activation rules. The result of the step is a report describing the batch processing behavior per activity. The final step is to analyze the time that the cases spend waiting before they are batch-processed. This includes an analysis of how batch processing and their associated waiting times impact the CTE. The final output is a report presenting results on batch-processing activities that, based on CTE, can be used to identify improvement opportunities.

Batch Processing Discovery

For the discovery of batch processing activities, we use the approach proposed by Martin et al. that identifies different types of batch processing activities. They use the resource, start, and end time data to detect when an activity instance is being executed as part of a batch, i.e., by the same resource, and either in sequence, concurrently, or in parallel w.r.t. other activity instances in the batch. Thus, the necessary requirement for the event log is to have the data on the resources, start and end timestamps. In this paper, we focus on batches intentionally processed as such, i.e., the activities were not executed once they were enabled (available for processing) but accumulated and processed as a group. If a case becomes available for processing after the start of the batch, it is excluded as it was not accumulated for batch processing. Accordingly, we extend the definition of a batch with the constraint that all cases part of a batch must be enabled before the batch starts. Therefore, we filter the results obtained by Martin et al. technique to remove such cases.

To perform such filtering, we need to calculate the enabled time of each activity instance. For cases where this information is not available in the event log, we set the enabled time as the end time of the previous activity if no concurrency relation exists. To obtain the concurrency relations between the activities, we use the concurrency heuristics from the Heuristics Miner, as their sensibility to outliers provides more robust results than other naïve techniques. As part of this filtering, we also allow the analyst to define a minimum batch size, i.e., the minimum number of cases that should be accumulated and processed as a group for it to be considered a batch (see Inputs in Fig. 1). The analyst can also define a maximum time gap between the end of processing of a particular case and the start of the next one within one batch (max in-batch gap). This input allows for the discovery of batch processing when interruptions occur. Such interruptions are common for processes executed by human resources, e.g., when a resource needs a break or a set-up for particular cases is required.

The output of this step is a report listing the activities where the batch processing occurs. For these activities, we identify their case frequency (i.e., the number of cases in which an activity is processed w.r.t. the total number of cases of the process) and batch processing frequency (i.e., the number of times an activity is processed as part of a batch w.r.t. its total number of executions). The list of batch processing activities is sorted by the batch processing frequency in descending order. An analyst can decide which batch processing activities to analyze further based on the frequencies. For instance, the list might have an activity with only 60% batch-processed cases, but the case frequency might be close to 100%. Therefore, the improvement of such batch processing would target 60% of all cases. On the other hand, the improvement of the activity with batch processing frequency close to 100% (all cases are batch-processed) and case frequency of 5% would affect a relatively small number of cases and thus, the overall impact would be negligible. Therefore, a combination of batch processing frequency and case frequency indicates the impact of the batch processing activity. Based on this information, the analyst can determine which batch processing activities to analyze further.

Batch Processing Behavior Analysis

For each identified batch processing activity, we discover its behavior, i.e., the characteristics of how the batch is processed. We describe batch processing behavior with batch processing frequency, type, size, and activation rule/-s. Batch processing frequency indicates the proportion of cases of an activity that are processed in a batch w.r.t. its total executions. Batch size illustrates the number of cases processed in a batch. The batch size can be constant (e.g., batch size = 5 cases in 100% of cases) or variable (e.g., batch size = 5 in 40% of cases, batch size = 6 in 60% of cases). Batch processing type describes how the cases are batch-processed. In this research, we discover five batch processing types defined by Martin et al. Parallel batch processing is when all cases are processed at the same time. In a sequential task-based batch processing, one activity is executed for all the cases in the batch, one after another. In sequential case-based batch processing, a set of activities are sequentially executed for each case in a batch. Concurrent task-based batch processing is when one activity is executed for all cases, but with a partial overlap in case processing. In concurrent case-based batch processing, multiple activities are performed for each case with partial processing time overlap.

We also identify batch activation rule, i.e. the condition(s) that trigger the batch processing. In the batch activation rule discovery, we follow the approach and batch activation rule types proposed by Martin et al. The activation rules can be volume-based (batch processing is triggered when a certain volume, weight, or number of cases are accumulated), time-based (batch processing is time-triggered, e.g., by scheduled date and time, when a case reaches a waiting time limit), resource-based (batch processing activation is dependent on the resource attributes, e.g., the batch is processed when the resource workload allows processing this amount of work), case-based (batch processing is initiated based on the case-related attributes, e.g., arrival of the case of a particular type such as emergency or high-priority case), or context-based (rules embracing other aspects out of the process scope such as meteorological conditions).

Batch can be activated with a single rule, multiple rules, or on an ad-hoc basis. A single rule consists of one condition to be fulfilled to initiate batch processing, e.g., accumulated orders are shipped on scheduled date. Multiple rules present a combination of different types of rules are used to activate a batch processing, e.g., the combination of volume and time-based rules: accumulated orders are shipped based either on the scheduled date or when certain weight, volume, or number of cases are collected. However, when no specific pattern that confidently correlates with the start of batch processing can be identified (i.e., no activation rule is assigned), it is assumed that the batch processing is determined by the resources, i.e., executed ad-hoc. In our approach, the batch activation rules are elicited using the RIPPER technique. The quality of the discovered batch activation rule is measured by support and confidence parameters. The output of this step is a report detailing the behavior of each selected batch processing activity. This information serves as an input for the next step and can be used later by the analyst to identify what parameters to alter to improve batch processing.

Waiting Time Analysis of Batch Processing Activities

In this section, we describe the characteristics of the five batch processing types considered by our approach, and the waiting times they might induce. We determine three types of waiting times associated with the batch processing – waiting time for batch accumulation, waiting time of a ready batch, and waiting time to process other cases of the batch.

Parallel Batch Processing. In parallel batch processing, a resource starts and completes processing all cases of a batch at the same time. First cases are accumulated, and once accumulated, they can be processed. There are two waiting time types in parallel batch processing (Fig. 2). The first is waiting time for batch accumulation, i.e., the time it takes to build up a batch ($WT_{accum}$ in Fig. 2). When all the cases are accumulated, a batch is ready to be processed. But a batch might not be processed as soon as it is ready. Thus, there is a second waiting time - waiting time of a ready batch ($WT_{ready}$ in Fig. 2).

Fig. 2. Waiting times in parallel batch processing

To identify these waiting times from the event log, we need enabled time (when a case becomes available for processing), start time (when a case starts being processed), and completion time (when a case processing is finished). The enabled time is often the same as the completion time of the preceding activity. However, they might differ where parallel activity execution occurs. Therefore, when there are two parallel activities, both of which must be completed before the processing can continue, enabled time is the completion time of the latter activity. Thus, once enabled time is recorded, the case is ready to be processed ($t_{enabled}$ in Fig. 2).

Waiting time for batch accumulation is the time cases wait before a batch is accumulated and ready to be processed. A batch is accumulated when all the included cases are available for processing. Therefore, a batch is accumulated when the last-arriving case in the batch is enabled. Until the enablement of the last case, all earlier cases wait for the batch to be accumulated. Thereby, waiting time for batch accumulation ($WT_{accumC1}$, $WT_{accumC2}$ in Fig. 2) is calculated as the difference between the enabled time of the cases in a batch and the enabled time of the last-arrived case. In Fig. 2, a batch is activated when three cases have been accumulated. Cases (see Cases C1, C2) wait until the batch is ready to be processed (accumulated). Their waiting time is, therefore, from their enabled times (see $t_{enabledC1}$, $t_{enabledC2}$) until the enabled time of the last case included in the batch, i.e., the third case (see $t_{enabledC3}$). The earlier a case arrives, the longer it waits. The last-arriving case (see Case C3) has no waiting time for batch accumulation since its arrival marks the batch as ready to be processed.

Waiting time of a ready batch (see $WT_{readyC1-C3}$ in Fig. 2), on the other hand, is the time from when the cases are ready to be processed (batch accumulated) until they are processed (batch processing starts). Therefore, it is calculated as the difference between the enabled time of the last-arrived case ($t_{enabledC3}$) and the start time of the batch processing ($t_{start}$).

Sequential Batch Processing. In sequential batch processing, a resource accumulates a group of cases and processes them one after another. In sequential task-based batch processing (Fig. 3), the same activity is executed for all cases, one by one. However, in sequential case-based batch processing (Fig. 4), several activities are performed for each case in a batch.

Fig. 3. Waiting times in sequential task-based batch processing

Fig. 4. Waiting times in sequential case-based batch processing

Sequential task-based (Fig. 3) and case-based (Fig. 4) batch processing have, similar to parallel batch processing, waiting time for batch accumulation and waiting time of a ready batch. But sequential task-based and case-based batch processing also have waiting time for other cases to be processed within the batch processing, i.e., the time when a case waits while work is done on other cases in the same batch. This waiting time occurs when the resource is processing some case/-s in the batch (e.g., Case C1 in Fig. 3), other cases have to wait for their turn ($WT_{otherC3}$ for Case C2 and $WT_{otherC3}$ for Case C3 in Fig. 3).

Waiting time for other cases to be processed is calculated as the difference (interval) between the start time of the first case/-s ($t_{startC1}$ in Fig. 3) in a batch and the start time of the other case/-s ($t_{startC2}$ and $t_{startC2}$ in Fig. 3). In a sequential case-based batch processing (Fig. 4), several consecutive activities are performed for each case of a batch. Waiting time types in sequential case-based batch processing correspond to those in sequential task-based batch processing (see Fig. 4).

Concurrent Batch Processing. Concurrent batch processing is when cases are processed sequentially but with partial time overlap. Concurrent task-based batch processing (Fig. 5) is to execute the same activity for all cases in the batch with an overlap in processing time. In contrast, for the case-based type (Fig. 6), multiple activities are performed for each case with an overlap in processing time. In concurrent task-based (Fig. 5) and case-based (Fig. 6) batch processing, the waiting times are the same as sequential batch processing. Although there is an overlap in processing time, the cases still have to wait for their turn to be processed. Therefore, waiting time for other cases to be processed occurs (e.g., $WT_{otherC2}$, $WT_{otherC3}$ in Fig. 5). Given the similar activity processing times, the difference between these batch processing types lies in a shorter waiting time for other cases to be processed due to processing time overlaps.

Fig. 5. Waiting times in concurrent task-based batch processing

Waiting Time Analysis. We analyze discovered waiting times to identify inefficiencies. We, first, determine how long cases wait on average before they are batch-processed. Then we examine the batch processing efficiency by calculating its CTE, i.e., the ratio of the processing time to the cycle time of the batch processing activity/-ies. Finally, we measure the impact of each waiting time type on batch processing efficiency. We express the impact as the potential CTE improvement, i.e., how much improvement of the CTE can be obtained if a particular waiting time type is eliminated.

Fig. 6. Waiting times in concurrent case-based batch processing

The first step is to examine the average waiting time per type. We measure, for each waiting time type, the average waiting time for batch accumulation, average waiting time of a ready batch, average waiting time for other cases to be processed, and average total waiting time. These metrics depict how long cases wait during batch accumulation and processing.

The analysis of waiting times provides the input required to assess the impact of discovered waiting time types on the batch processing CTE. It enables the discovery of batch processing inefficiencies from event logs. The impact of each waiting time ($CTE\_{im}$) on the batch processing CTE is measured as the difference between the CTE of the batch processing activity/-ies and the CTE if that particular waiting time is eliminated. Thus, this metric illustrates the potential CTE improvement if that particular waiting time is eliminated. Thus, if the CTE of a batch processing activity is 50% and, for instance, after eliminating its waiting time of a ready batch, the CTE increases to 70%, the potential improvement opportunity of addressing this activity is $CTE_{im}$ = 40%.

The output of this step is a report that presents discovered waiting times per type and their impact on the batch processing activity CTE ($CTE_{im}$). Process analysts can use the obtained results to identify batch processing inefficiencies and from where (what particular waiting time type) the inefficiencies stem. Thus, the results can aid the analyst in identifying which batch processing activities to focus on in their improvement initiatives and how they can be improved.