Applying Process Mining to an HR Process

Last time, I showed you some results from a case study with ASML. Today, I want to talk about a process mining analysis that we performed for a customer’s internal HR process.

HR process

In Human Resources (HR), one of the typical processes is that the internal HR department reacts to requests and questions from employees of the company. For example, the employees may have questions about their contracts or training programs.

In the HR department we worked with, the service is delivered in a 3-line model: Easy cases can be resolved at the 1st line, while more complicated questions may need more activities and are either handled in the 2nd line or even with the help of an external specialist.

Goal of the analysis

The goal of the analysis was to get a clear picture of the current ‘As-is’ process because the company wants to deploy a new IT system in the HR department and use these insights to improve the process.

The event log

The screenshot below shows an anonymized fragment of the data that was extracted from the current HR system. More detailed information about the questions of the employees were available but have been removed here for confidentiality reasons.

Figure 1: The Input Data from the HR System contained information about the individual status changes for each handled case.

Using Nitro, we could easily convert these data in an event log that could then be analyzed with the process mining toolset ProM.

Furthermore, we could explore different views on the same data. For example, we chose to analyze the differences of the HR process for cases that are handled in the 1st line vs. those that need help from the 2nd line or the specialists.

Process mining results

Using process discovery, we could automatically discover an objective picture of the HR process in these 3 service lines (see below). One can see that cases in the 1st line are indeed directly handled, while in the 2nd line and with the specialist there are more steps necessary.

Figure 2: A process model of the HR process that was automatically discovered based on the event log of the HR system. The numbers and the coloring indicate the frequency of activities and followed paths.

Because the log data also contains information about the time of the status changes, we can dive deeper and analyze the timing behavior of the process.

For example, in the process fragment below one can see that there is considerable time lost when a case is scheduled for a specialist until it is actually picked up by the specialist.

Figure 3: A fragment of the discovered process model annotated with performance information at the arcs (in days).

Here are some further results from the analysis:

  • We found that if a case goes more than twice to the specialist, it is most likely taking longer than the targeted cycle time allows (some cases go to the specialist up to 7 times).
  • It is unclear what the ‘in progress’ state contributes to the process. It may add overhead to the process that is not needed and could be removed. For example, after being completed at the specialist, the cases should be directly completed instead of going back to ‘in progress’.
  • Furthermore, a closer integration of the external specialists from an organizational perspective would help to speed up the process.

We also analyzed the root causes of overly long-lasting cases by comparing different topics asked by the employees to the HR department.

Bottom line

The main focus of the analysis was on the process flow and its variations, and on the target cycle time. While the cycle times did match the intended service level, the variation analysis was surprising: The top 3 process variants were followed in 80% of all cases, but there were 210 different process variants in total.

Based on our ‘As-Is’ process analysis, the company used their domain knowledge to identify suitable improvements. The results gave the process owner a solid, data-based foundation to understand the current process reality before making any improvements in the new system.