As working from home became mandatory during the COVID19 lockdown, many businesses feared negative productivity shifts originating from the new way of working based on the same processes and technology. Process Mining as a data-driven process discovery, analysis and monitoring method o ers the continuous monitoring of process performance. In practice, however, severe limitations arise when assessing the time e ort required for process execution as many enterprise resource planning systems do not record the time required for the execution of activities. In this context, the contributions of this paper are twofold: rst, we present E ort Mining as a process- and system-agnostic method that allows us to estimate the time required for process steps; second, we apply this method to compare the e ort before and during the lockdown as a means to identify productivity gaps induced by the pandemic. Our investigation has identi ed no substantial change in the employees' productivity, indicating that the underlying business processes and corresponding technology were t for purpose in both scenarios.
Improving operations is a promising investment in times of stability. In times of
crisis, however, the focus shifts to survival and maintaining the current level of
operational excellence as well as liquidity become the main goal. This was also
the case when COVID-19 hit the economy, working remotely from home became
mandatory for many rms, and the environment of the people executing the
processes changed. To assess process performance, Process Mining has emerged
as a holistic and data-driven methodology in the last decade [
The remainder of this paper is structured as follows: Sec. 2 brie y describes the situation our clients faced during the lockdown, which motivated the development of E ort Mining. Sec. 3 describes the technical steps required in E ort Mining. This includes the minimum data requirements, the executed data transformation and the assumptions required to deduct a start timestamp. Sec. 4 reports on the results that can be achieved by using E ort Mining with a focus on the comparison of data recorded during the lockdown in April/May 2020 and data recorded in the previous year. The results originate from a client active in Financial Services, but as the method is process-agnostic, the results can be seen as indicative for any process or industry. Sec. 5 outlines the additional experience we have gained when applying E ort Mining, the feedback we have received until now, and the kind of applications we see for E ort Mining in the future.
On 11th of March 2020, the World Health Organisation announced in a press
conference that COVID-19 was a pandemic and that immediate actions needed
to be taken by governments [
After the initial phase of COVID-19, a common question was if and how remote working impacted the productivity of employees. For several clients, our team had previously executed process mining projects and created the required data models based on data generated and stored in the clients' ERP systems. The process mining data models were extensive, well-developed, and validated in previous projects. Thus, it was regarded as a reliable and high-quality data source. Further, data visualisation with process mining dashboarding tools was already implemented. Previously, the main purpose of the process mining infrastructure had been to ensure compliance and to identify process improvement potentials, but now a new scope was added: the goal of these studies was to use the existing process mining data models to identify changes in employee performance and behaviour. To achieve this, we have created a process-agnostic approach that is based on process mining event logs and can be used to assess processing times for the execution of activities, gives insight into the daily rhythm in which activities in the ERP system are executed, and estimates the overall involvement of employees in terms of overall working hours. 3
The starting point for these projects were existing process mining event logs as a data source and the existing process mining infrastructure. To assess productivity within the rm, we deduct the number of manual activities executed in time intervals. Another relevant productivity metric is the typical execution time of speci c activities: this metric is not available directly as the ERP systems record only the end timestamp of an activity. However, we have developed a statistical procedure to estimate the start timestamp. Further, we estimate the duration of workdays based on the rst and last timestamp submitted by users on each day. 3.1
The table structure of the process mining event log is depicted in Table 1, having the typical columns of the CaseID, the timestamp, and the occurring event. This is the typical minimum data required for process mining. Further, the
CaseID Timestamp Event UserID CaseNo1 2020-06-04 08:35:45 EventA User1 CaseNo1 2020-06-04 08:36:45 EventB User1 CaseNo2 2020-06-04 08:37:00 EventB User1 CaseNo2 2020-06-04 09:05:30 EventA User1 CaseNo3 2020-06-04 09:05:30 EventC User1 CaseNo3 2020-06-04 09:05:30 EventD User1 CaseNo3 2020-06-04 09:05:30 EventD User1 CaseNo3 2020-06-04 10:00:15 EventD User1 ... ... ... ...
CaseNo9 2020-06-04 17:25:15 EventA User1 UserID of the user executing the respective process step is a piece of the required information for E ort Mining because it is needed to add information about a possible activity start.
Based on the hypothesis that users perform multiple activities in a day for the process in scope, we transform the process mining eventlog and create the e ort log as shown in Table 2. This table has one entry for each manual activity performed in the respective process. Here, we de ne one activity as a distinct combination of the UserID and the recorded timestamp. One activity can affect several cases and can create several events in the event log (e.g. compare ActivityID 4 in Table 2 and entries at the timestamp `2020-06-04 09:05:30' in Table 1). Further, we make an estimate for the processing time based on the previous activity executed by the same user on the same day. A direct consequence is that the processing time of the rst activity of each user on each speci c date is missing and will be estimated in a subsequent step. 3.2
The e ort log (Table 2) generated from the event log (Table 1) provides us with a set of possible activities being executed in the process. For each distinct activity, we obtain a set of observed processing times from which we construct a respective distribution. Figure 1 shows the distribution of observed processing times for three di erent activities. The mode of this distribution we account as the most likely or typical processing time of the respective activity inside the ERP system. If the observed processing time exceeds the typical processing time by far, the respective user likely executed activities outside of the ERP system. These activities outside of the ERP system could include preparations for the respective activity (e.g. making inquiries), executing activities in di erent processes, administrative tasks or taking a break. Even though a detailed decomposition of this e ect is beyond the scope of this paper and might even not be possible without additional information, the observed processing time can serve as an ActivityID UserID Timestamp
Observed Processing Time N ull 60 sec 15 sec indication for the overall working time required to execute the respective action. Further, we can assume that the mixture of the activities outside of the ERP systems remains consistent over time and that it is distributed homogeneously over the users and activities if the number of users and activities is large.
To estimate the start timestamp of a speci c activity, we de ne a threshold in dependence on the typical time of the respective activity. If the threshold is not exceeded, we use the observed processing times to deduct the start timestamp of the respective activity. If the threshold is exceeded, we consider the typical processing time to deduct the start timestamp. Further, we use the typical processing time to deduct the start timestamp for the rst activity of each day for each user, where no observed processing time is available (see Table 2). It is essential to acknowledge that this method is an approximation and does not deliver exact values for each activity. However, for commonly executed activities in large organizations su cient data points are available to calculate the typical times accurately and deduct the start timestamp of the rst activity of a user in a reasonable manner. Overall, this method gives solid evidence about how much time employees spend in the ERP system for all common activities of the process. A relevant question is whether behavioural changes occurred during the lockdown. To tackle this question, we visualise the distribution of actions over the day. Further, we can deduct the length of a working day based on the rst and the last timestamp of a day. E.g., for User1 in Table 2, we would deduct a starting time of the workday on the 4th June 2020 at 8:35 and an end time of the workday at 17:25, resulting in a workday duration of 8.8 hours. Starting from the workday duration in hours of individual users, it is possible to deduct the overall working hours required to execute the respective process and the number of FTEs involved. It should be noted that this approach neglects the duration of the rst activity of a user on a respective day. A solution for this is to approximate the start of the rst activity using the average observed processing time of the respective activity.
Our standard E ort Mining analysis results in a table which summarises the most relevant KPIs describing the work time consumption of the process in scope, as depicted in Table 3: for each activity, we quantify how often it is executed, we deliver the typical processing time required to execute the activity in the ERP system, the total time spent in the organisation to execute the respective activities in the ERP system, as well as the overall working time required. If required, it is also possible to break down the results for di erent organisational units and compare, for instance, the processing times for certain activities across the organisation. 4.2
When looking at changes in the working behaviour caused by the lockdowninduced remote working, it makes sense to look at temporal changes of KPIs
Typical Overall Time Overall Processing Times Count Activities in ERP System Working Time listed in Table 3. In the following, we will look at the temporal evolution of processing times, the distribution of workday duration, and the number of executed activities. We will speci cally compare the results from April/May of 2019, the year before the rst lockdown, and the results of April/May 2020 when the rst and most strict lockdown was imposed on our clients.
Figure 2 a) depicts how often Activity 3 was executed in each month in scope: overall, we do not observe a signi cant increase or decrease in activities in any period. In Figure 2 b) we aim to learn whether the typical processing time in the ERP system for activity execution changed over time. We de ne, as described in subsection 3.2, an upper threshold to de ne a sample and calculate the mean of the sample as well as its standard error. When looking at the resulting plot, we do not observe an increase in the processing time from the moment employees had been sent home to work remotely. We rather observe a slight constant decrease over time, while the number of executed activities remains at a similar level (Figure 2 a)). This trend is underlined by Figure 2 c), which compares the distribution of observed processing times in April/May 2020 for Activity 3 with the observed processing times observed in the previous year: the distribution in 2020 is shifted towards faster processing times, which might be an e ect of a more routinised activity execution by the users. But a signi cant e ect on performance induced due to the lockdown starting in March 2020 was neither observed for the shown activity, nor for any other activity. In the next step, we aim to understand whether the daily routine of our clients' employees changed during the lockdown. To achieve this, we examine the distribution of timestamps of the recorded activities over the day, which carries information about the activity of the ERP system users and their daily rhythm. Further, we will look at the duration of workdays as de ned in subsection 3.3 to elucidate if users had longer or shorter working days.
Figure 3 a) compares the distribution of occurring activities over the day for April/May 2019 and April/May 2020. The distributions appear overall very similar: the number of recorded activities in the ERP system increases in the morning between 7:00 and 8:00, which corresponds to the start of the working day of the users. Activity in the ERP system decreases drastically between 12:00 and 13:00, which corresponds to the lunch break, and rises after that to an activity level slightly lower than in the morning. Between 17:00 and 18:00, the number of activities decreases again as people nish their workday. When comparing the distribution of April/May 2020 during the lockdown with employees mostly working from home with the one from the previous year, we do not observe remarkable changes. This is indicative of the stable daily rhythm of the employees. It is worth noting that it was possible to identify organisational units for which late work after 20:00 increased during the lockdown (up to 3 % of all activities were executed after 20:00). However, this is in the range of typical uctuations of late work observed within the organisation.
Figure 3 b) compares the distributions of the workday duration for both periods. Many users participate in activities outside of the respective process and execute only for a fraction of their actual workday activities in the process. These users create short working days between 0 and 7 hours. Both distributions have a clear maximum between 8 and 10 hours, which re ects the typical workday duration. Longer working days are rather an exception for both periods in scope. It could be that for 2020 the distribution is shifted by 0.2 to 0.3 hours to a slightly shorter workday. However, when evaluating the temporal evolution of the workday duration (Figure 3 c)), it becomes obvious that this is within the range of natural uctuations.
Overall, this one-o analysis provided the respective client with the security that the productivity and the daily working rhythm of the employees did not change measurably due to the lockdown and that no immediate control action was required after two months of home o ce. 5
This paper has presented E ort Mining, a new approach to measuring the e ort required by activities in a process, thereby adding a novel perspective to process mining and allowing the precise quanti cation of e ort in terms of time. We illustrate the use of E ort Mining in a case study based on real industry data, comparing the productivity of employees before and during a lockdown. As a result of this analysis, the client had the security that the process execution and employee performance was not impaired measurably by the home o ce. However, as the scope of this one-o analysis was limited to two months after the lockdown, long-term e ects are not covered here. Future work might extent the time period covered by this analysis.
Overall, the feedback we received on this method was excellent and the calculated values of typical processing times and overall working times were in good agreement with the expectations of our clients. Another validation of the methodology was delivered by evaluating the overall working time of the most active UserIDs: They delivered a number of working hours to be expected by one FTE. After the initial application of e ort mining in the here presented usecase, we used the methodology for several clients on di erent processes, such as order-to-cash, purchase-to-pay, record-to-report and enterprise asset management based on SAP data. We found that the methodology appears to be process-, industry- and system-agnostic. The only requirement is that the ERP system captures a su ciently large amount of similar activities from su ciently active users, which is typically given for core systems of large organisations.
One of the most relevant opportunities that arise through E ort Mining is judging the systemic work e ort present in any given ERP system. As we utilise the execution pattern of users through all process steps, we can understand how users spend their time in the system. From that, we derive the typical processing time for each process step, allowing us to judge the business impact of each process execution. With e ort mining, the time spent on process steps can be made transparent without using any additional, intrusive software component. We utilised this approach to create transparency in terms of work e ort executed at home during the COVID-19 induced lockdown. It became evident that relocating employees to their own home for working did, in this case, not a ect processing times or the number of activity executions. Further, the daily rhythm of the system users showed no drastic change in the remote working setting. A key message for the client was that the shift to working from home did not compromise human e ciency in the process execution. However, one should be careful to generalise from this case to the situation of other rms as the results will depend on the employee behaviour and the culture of the organisation.
An additional opportunity for E ort Mining is the quanti cation of
automation opportunities. Quantifying the systemic work e ort in hours required to
execute each process step enables us to associate a clear monetary value with
each manual activity execution. This translation of systemic work e ort into
costs allows companies to optimise their spending on business improvement
opportunities, e.g., robotic process automation initiatives [
An analytical area heavily impacted by E ort Mining could be business
process simulation and prediction: these elds demand adequate information about
resources used as an input, including human resources [