I have been invited to talk about Process Mining in healthcare at the Dutch Ngi event De mens en IT in de Zorg in Utrecht next Tuesday. The Ngi is an association for IT professionals in the Netherlands and is regularly organizing events around a variety of topics.

Process mining in healthcare is an exciting topic. Having good processes in place is relevant for society from both a cost-saving as well as from a quality perspective. At the same time, the complex nature of the processes in the healthcare domain leads to interesting challenges for process mining.

For those of you who are located in the Netherlands, let me know if you want to join. Normally, non-members pay 10 Euros but I will see if I can organize an invitation. You can RSVP at LinkedIn here.

It is one of my more pleasurable duties here at Fluxicon to announce updates to Nitro. We just released Nitro 2.1, and so again it’s time for me to walk you through the changes and new features in this version. As always, you can download installer packages for Windows and Mac OS X at http://fluxicon.com/nitro.

Simplified configuration

You are probably familiar with our interface to configure the columns of CSV and Excel files. We have made two changes to this interface, and we think that they make it even easier to quickly get your data converted.

We have extended the preview shown in the table to 1,000 rows, so that both you and Nitro have a better idea of the data you are configuring, and what it means. We have also added row numbering, so that even with that bigger preview, you always know what you are looking at.

Previously, you had to configure for each timestamp column whether that timestamp signified the start or the completion of the activity described by that table row. Actually, we found that Nitro can figure out pretty well on its own which timestamp is the first one, and which is the last. So, starting from version 2.1, Nitro will use the earliest timestamp per row as the activity’s start timestamp, and the latest will be used as the completion timestamp. One less thing to worry about, n’est-ce pas?

Events with duration

So far, Nitro’s event model followed that of the MXML and XES standards. That means we counted the starting and finishing of each activity as separate events. For academics that viewpoint may be pretty sound, but we found that for many practitioners it makes more sense to see an event as one execution of an activity — which, consequently, has a start and an end time.

For Nitro 2.1, we have reengineered the Octane layer to automatically correlate start and end timestamps for each event, no matter whether you load your log from a CSV, Excel, MXML, or XES file. For one thing, this means that if you have two timestamps per event in your log, the number of events Nitro will show you in the Statistics view will now be half of what you have seen before. But don’t worry, Nitro still has all your data, and it knows even more¹.

Since Nitro now knows the start and end timestamp for each event² it now knows about the duration of activities. Consequently, we have extended the statistics views for Activity and Resource event classes with some additional information.

For activities and resources, Nitro 2.1 now has three new charts (each both as Pareto charts or classical histograms):

• Mean duration of each activity / resource.
• Aggregate duration of each activity / resource (i.e., the complete time spent by each activity or resource over the whole log)
• Duration range for each activity / resource (showing you the differences in variation for each item)

The same information is also shown in the table view. We have added one column with an inline histogram that allows you to compare the mean duration of each activity / resource. Further, we have introduced a new inline histogram column which shows you the duration range for each item.

The “fat” bar in each row shows the range, i.e. its left edge shows the minimum duration, and its right edge the maximum duration of each item. Within this bar is another, ligher and “thinner” bar ending in a vertical line. This indicator shows you the mean duration, giving you more information about the actual distribution of durations.

Log explorer

Once you have loaded your log into Nitro 2.1, you will notice that the familiar Statistics view is now one of two alternative views on your log. We have added the Log explorer view, which allows you to view the actual cases in your log.

On the very left side of the log explorer view, you can see a list of case variants. Nitro now automatically organizes the cases in your log in such a way, that all cases that feature the same sequence of activities are grouped together in a so-called variant. So, the set of variants is the set of unique activity sequences in your log.

The second column from the left shows you the list of all cases that are grouped together in the selected variant³. When you select a case from that list, information about that case, including its precise sequence of events, will be shown in the right part of the log explorer view.

On the top of that case view, you will see a chart indicating when and over which timeframe in the log the selected case occurs. The chart shows the density of cases over the whole log’s timeframe as a blue curve area, with the selected case’s timeframe highlighted in red. This allows you to intuitively spot when in the log your case occurs, and how long it has been executing.

To the right of this chart, Nitro shows some statistics for the selected case:

• Number of events in the selected case.
• Starting date and time of the case.
• Duration of the case.
• Active time of the case (as a percentage of the complete duration).

The active time indicates the time spent executing the case’s activities, in relation to the complete case runtime, as a percentage. It allows you to get a grasp of the efficiency, or the relative waiting time, for a specific case.

On the lower part of the case view you can see the actual sequence of events in the selected case. This view can be switched between a graph view allowing for a quick overview, and a table view that allows you to see the values of attributes for each event.

Bugs and fixes

Nitro 2.1 contains all bug fixes up to and including version 2.0.8, plus additional bug fixes. At this point we would like to thank Michael Westergaard and Jan Claes for pointing out bugs that could occur in our configuration screen, and George Varvaressos for alerting us to an issue with the modification time for compressed MXML files. And of course a big thanks to all of you who sent us further bug reports and suggestions — we hear you and we like what we hear, keep it coming!

While we have tested Nitro 2.1 extensively, the changes under the hood are quite dramatic. Should you run into a bug or problem, please let us know at support@fluxicon.com, and we will fix it ASAP.

Epilogue

We hope you are as excited about the new features in Nitro 2.1. as we are. Make sure to download your copy right away at http://fluxicon.com/nitro.

By the way, how do you like these release write-ups so far? Do they help you to keep on track for where we’re going with Nitro, and do they give you a good idea of what you can do with Nitro? Are they too long and rambling, or would you like them even more in detail? I’d like to make this as useful for you as possible, so if you have any suggestions or feedback, please let me know in the comments!

1. Note that we have adjusted the event limit for our demo version to 5,000 events, since each event can now have two timestamps, and thus result in two events in the MXML or XES file. The limit of our professional and enterprise tickets remains the same, which means that with each ticket you can now analyze twice the amount of data than you could before! ↩
2. If you have two or more timestamps configured per row in a CSV or Excel file, or if you have loaded an MXML or XES file with start and complete events ↩
3. Note that you can also select to show all cases in the log at once, by selecting the Complete log option in the case variant browser. ↩

Processes that are primarily based on information flows are particularly challenging to analyze because they are inherently invisible. When I told Mathew, a Lean Six Sigma practitioner, about process mining he thought that was fantastic. And he made a comparison that I really like. He said:

Making information flows visible is the equivalent of walking on a factory floor.

In an assembly line, you can move from one step to the next step in the process and easily observe what is happening. But information-based processes usually don’t pass around piles of papers anymore. That means you simply can’t see what is going on. Making the process flows visible based on IT data is therefore really valuable.

Since 2009, we have used the X-ray metaphor to explain process mining. Wil often uses the metaphor of a TomTom navigation system. Now we have the factory floor metaphor. Which one do you like best? Which other metaphors have you seen? Let us know in the comments.

Meet us in Utrecht on 6 April

If you are in The Netherlands, come to the Lean Six Sigma Seminar in Utrecht next week Wednesday. We will have a product booth there and would love to talk to you in person!

The segregation of duties, also called the 4-Eyes-Principle, is one way for organizations to reduce the risk of fraud. For example, it may not be allowed for the same person to initiate a purchase order and pay the invoice for the same item.

Segregation of duties is often controlled via role-based access management in the IT systems. However, there are situations in which after-the-fact verification (based on audit files) is needed.

Here are three examples:

1. No preventive mechanisms are in place. Not every organization employes preventive mechanisms to ensure segregation of duties via IT controls. Sometimes there are simply not enough people to realize segregation of duties via separate roles. But auditors still have to prove that the 4-Eyes-Principle was obeyed in the operations.


2. Changing roles create loopholes. Changing roles may create loop holes for bypassing segregation of duty IT controls and create a risk for fraud. For example, a person who initiated a purchase order in role A may over time obtain role B and thus be able to pay the open invoice after the role change. Even complex role management tools usually verify the risk of violation at a static point in time (not over time).


3. Access management may have been circumvented. Processes often run across different systems. Increased certainty is needed in today’s climate in addition to preventive controls and beyond sampling. By automatically checking 100% of the process log files for violations of segregation of duty constraints, auditors can provide a higher assurance.

In this post, I give you a step-by-step instruction for how to actually check segregation of duty constraints using Nitro and ProM.

1. Determine Segregation of Duty rules

Before you start, you need to know what the segregation of duty rules for your process are. For example, in a Purchase-to-Pay process it is most likely not allowed that the same person issues a purchase order and also approves it.

Here is an example from this ERP vendor blog. The matrix illustrates with an ‘X’ all those two tasks that should be separated. The red marking highlights one of the task combinations that are not allowed:

In the rest of this post, I continue with the call center demo example used earlier. This way, even if you don’t have a log file that you want to check yourself, you can follow the steps using the demo file that comes with Nitro. (Download the free demo version of Nitro here.)

2. Import Audit File

Using Nitro the process log can be imported from a CSV or Excel file. The meaning of the columns is configured in the GUI.

You need to at least configure the following columns:

• CaseID: Distinguishes different executions of the process (i.e., process instances)
• Activity: Determines the tasks that were executed
• Resource: The person who performed the activity

The other columns are optional. For example, you can configure the columns as shown in the screenshot shown above.

Now, the audit file can be exported in MXML format, which is needed for importing the data in ProM 5.2. (Download ProM here.)

3. Choose 2 Activities

After the import of the converted log file in ProM, start the LTL Checker by choosing ‘Analysis → Raw ExampleLog.mxml.gz (unfiltered) → LTL Checker‘ from the menu.

In the LTL Checker settings screen:

1. Choose ‘exists_person_doing_task_A_and_B‘ from the list of pre-defined formulas. This is the formula that checks segregation of duties.
2. Write down the names of the two activities that should not be performed by the same person for the same case.
3. Click on ‘Check formula‘

4. View and Export Violations

Now, potential violations are displayed and the details can be exported.

In the screenshot above you see the result for our segregation of duty check with respect to the activities ‘Email Outbound‘ and ‘Call Outbound‘.¹

In total, there were 75 cases for which the segregation of duty rule was violated (‘Correct process instances‘ means that the formula could be matched) and 3810 cases were without problem (‘Incorrect process instances‘ means that the formula was not matched — so this is a bit counter-intuitive).

You can also switch between the “Correct” and “Incorrect” set of cases and inspect individual process instances. For example, in the screenshot above the case 3278 is visualized and the found Segregation of duty violation is highlighted.

For further analysis in Excel, you can export the found violations by choosing ‘Exports → Correct instances → CSV for log Exporter‘ from the menu.

Discussion

Do you think checking segregation of duties after-the-fact makes sense? Have you needed it at some point in time? Which tools did you use, and what did you like or dislike about that solution?

Let us know in the comments.

1. Granted, the example does not make any sense here. This call center process simply does not have any segregation of duty constraints. But I am sure you will have plenty of examples from your own processes.  ↩

You might have noticed: Products—and especially consumer electronics—are becoming more and more complex. As a result, people are not always able to deal with these complexities and usability becomes a distinguishing factor in brand reputation and customer satisfaction.

Process mining is a new technology that makes invisible process flows visible by analyzing existing log data in a bottom-up manner. Earlier, we have seen how process mining can be applied to the test process of ASML and an HR process. But can process mining also help to improve the usability of products?

Usability Testing

In the context of the Master’s project of Pieter Hofstra, together with Jeroen Keijzers, Yuan Lu, and Ton Weijters, we investigated the applicability of process mining for usability tests¹.

Usability tests, for example first-use consumer tests, can help to get early feedback from the field while there is still time to adapt the product before releasing it to the market. Traditional usability measures include mostly static information, for example:

• number of errors produced,
• the time required to complete a task,
• number of keystrokes, etc.

The results typically do not reflect the temporal aspects of the test data. So, in this project, we looked at how process mining can be used to get insights into the actual user behavior.

Experimental Setup

For the project, a group of 29 Dutch volunteers (from age of 22 to 66) participated in a usability test for a new television. 19 participants were male and 10 were female. The usability test took place in a simulated living room to make them feel at home as much as possible.

The participants were asked to complete the following three tasks:

1. Channel selection. After installation of the television, channel RTL 7 has been automatically programmed on channel 25. The participants were asked to put RTL 7 on channel 7.
2. Dual screen. The ‘Dual screen’ function is innovative in comparison with previous versions of the product. It is one of the features promoted by marketing to sell the product. The participants were asked to watch the channels NEDERLAND 2 and NET 5 simultaneously.
3. Digital picture. Another function that is new in comparison with previous versions of the television is the ‘Digital picture’ function, which allows to view digital pictures from a USB stick on the television screen.

The “correct procedures” to solve each of these three usability tasks is shown in the picture below. Further down, you can see the process models of the actual user behavior for the middle task (Dual Screen).

(Process models of the optimal user behavior for solving each of the three television usability tasks.)

The entire experiment took about 15-40 minutes per person, depending on the participants’ performance. During the experiment, the participants and the television screen were captured on a video camera. From these video recordings, an event log of the actual usage behavior was created semi-automatically. You can find more details about the event log creation in Pieter’s Master thesis.

Results

One of the goals of the study was to assess the effect of a consumer’s (product) knowledge on usability. People with high product knowledge are assumed to be more familiar with the product, and to have more experience in using it.

The test participants were divided into ‘High Knowledge’ (13 people) and ‘Low Knowledge’ (16 people) groups based on their knowledge ratings in the questionnaire². Process mining was done on the usage logs of these two groups separately.

Look at the behavior of the ‘High Knowledge’ group performing the Dual Screen task above. One can nicely see the paths that were taken from the start to the end of the task.

• Most people use the dual screen button and immediately enter the dual screen menu, whereas some people find the dual screen menu via the TV menu.
• In the dual screen mode, some participants press on the TV button to select the preferred channel of the left screen (which is not needed) and then go back to the dual screen mode.
• If people from the ‘High Knowledge’ group visit a deviant state, they return to the dual screen mode.
• An interesting loop that shows the switches between the screens leads from ‘Highlight second screen’ back to ‘Highlight first screen’ and then to ‘Selected channel first screen’.

(Process model discovered for the ‘Low Knowledge’ group performing the Dual Screen task. Compared to the ‘High Knowledge’ group this model is more complex showing more variability among the group of users.)

In the model above it is very visible that the people in the ‘Low Knowledge’ were even further away from the optimal solution. One person even had to give up.

• The participants in this group exhibit more varied behavior, which can be seen from the lower frequency numbers on the arcs.
• Furthermore, they visit many menus that are irrelevant for the dual screen task.
• Interestingly, the participants in this group return to the main menu more frequently than the participants in the ‘High Knowledge’ group.
• Another important insight is that people from the ‘Low Knowledge’ group are not able to visit the dual screen mode via the TV menu (there is no arc between ‘TV menu’ and ‘Dual screen mode’), since they seem to get stuck in this menu.

I find this is a nice example that through the visualization of actual user behavior it is possible to reveal usage patterns, which provide both qualitative and quantitative feedback.

Not only for Consumers

Also in a business context usage behavior can be crucial. For example, in call centers there is an increasing use of analytics for operational performance management. Agents often have to switch between 4-6 different applications (Siebel, SAP, etc.) while handling a call. Desktop analysis tools can analyze the key strokes of an agent and the resulting insight can be used to build an abstracting layer on top of the actual applications that matches the typical call flow.

Do you see other examples where understanding user behavior is important? Let us know in the comments.

1. See details in P.P.H.J. Hofstra. Analysing the Effect of Consumer Knowledge on Product Usability Using Process Mining Techniques. Master’s thesis, Eindhoven University of Technology, Department of Industrial Design, Eindhoven, The Netherlands, 2009.  ↩
2. The knowledge level of each participant was measured by asking them questions assessing their “familiarity” and “expertise” with televisions and computers. For example, participants had to react to statements such as “Compared to most other people, I know less about televisions/computers” (familiarity) and “I usually talk with friends and colleagues about new developments regarding televisions/computers” (expertise) on a 5-point Likert scale (ranging from total disagreement to total agreement). For more details see Pieter’s thesis.  ↩

It has been more than two weeks since I told you about the 2.0.2 update for Nitro. In this time, we have steadily released further updates, the latest of which is version 2.0.6, released last Saturday.

For the most part, updates should not be something you have to worry about. We keep fixing bugs, improving performance, and introducing new features continually, and you will get them automatically via Nitro’s built-in auto-update feature. We believe that, instead of tracking and installing updates, your time is better spent on actually interesting stuff, hence our auto-update approach. Still, for some of you it may be interesting to learn about what we’ve been up to.

So we will keep you informed about the development of Nitro here on our blog, in irregular intervals. In this post I will highlight two noteworthy changes in Nitro 2.0.6. The technically inclined can find a more comprehensive list of changes below, and your copy of Nitro will auto-update to version 2.0.6 the next time you start it up (as described in my last post).

Avoid unsuitable attributes

Many event logs in CSV or Excel format have columns with information that is unsuitable for process mining. One example is a column which contains free-text comments. You cannot create a process model from that kind of data, since every event carries a unique value. Another example are columns that have only one or two values over the whole data set. You may actually want to see that information in the converted log, but then again, maybe you’d rather not.

Since version 2.0.3, we have added a feature to Nitro which warns you about unsuitable attribute columns, such as the examples described earlier. In the above screenshot, you can see that Nitro now displays a warning badge in the column configuration panel when it thinks that column may be unsuitable. In this example, the column contains “more than 99%” unique values, which means that almost any event has a value in that column which is not repeated in any other row.

Nitro does not forbid you from using these columns for conversion. However, you may run into problems during conversion if unsuitable attributes are selected. Furthermore, these attributes almost always turn out to be unsuitable for analysis later on, or create problems in your analysis software. So, when you choose to use a column for an attribute and see that warning, we recommend that you remove it before converting the log, if possible.

Redesigned case analysis charts

With version 2.0 of Nitro we released a completely redesigned analysis view, complete with charts for analyzing the structure of your log. For version 2.0.5 we have redesigned two of these charts again, to be more useful.

In the overview section of the analysis view, the “Case duration” and “Events per case” charts now behave differently than the other histograms in the analysis view. Rather than featuring each value in a separate column, our redesigned charts actually take advantage of the fact that they display actual ranges of values, rather than a set of discrete values. Now, the horizontal axis corresponds to the range of values (i.e., duration or number of events), while the vertical axis shows the frequency of each value.

We think that this view better corresponds to typical statistical distribution charts, and that it gives you more actionable information about the structure of cases in your log.

Change log

For the sake of completeness, here you can find the list of changes per released version of Nitro:

Version 2.0.3
(10 March 2011)

• Introduced warning badges for unsuitable and problematic attribute columns.
• Fixed potential bugs in Octane layer.

Version 2.0.4
(11 March 2011)

• Improved the performance for logs with a large number of cases.
• Improved general performance.

Version 2.0.5
(17 March 2011)

• Redesigned analysis charts for case duration and number of events per case.
• Improved performance for very large logs.
• Fixed bugs in analysis view.

Version 2.0.6
(19 March 2011)

• Fixed bugs that caused rare crashes for certain types of logs.

That’s it

Thanks again for all your bug reports, feature requests, and general thoughts and ideas about Nitro! Please keep them coming, either through Nitro’s built-in feedback feature or by sending a mail to support@fluxicon.com!

If you have data and questions about your process, there are many powerful tools around that you can use to manipulate, query, and analyze the data to answer these questions. For example, SAS is often used by auditors to combine and filter data. Routines can be programmed and automated to a large extent.

So, how are these tools different from process mining?

The main difference is that you need to know what you are looking for if you use a query-based tool.

Process mining allows for a much more explorative analysis of your process, without the need to have all the questions in advance. Here are 2 examples.

Discovery

Process discovery works by taking the real execution logs of your process as input and then generates a graphical model of what has been happening.

Even if you are not sure what exactly you are looking for, process mining can provide you with an accurate picture about how your business process looks like in practice. This again may trigger questions that you would have never thought of in advance.

For example, in one of our customer projects we found out that advances that were made for some clients sometimes lead to a double payment in the regular process. The advance payment process was manually managed and thought to be under control. But just from looking at the discovered process model it became clear that much more cases slipped through the manual control than people thought.

Conformance

Often, there already exists a description or a model of the process as it should be. By comparing the actual log data from the IT system with the ideal process, one can find out where deviations have occurred and how many.

Checking data against a complete process description is almost impossible to do in a standard query tool, because it is hard to capture the complete target process in a query.


Query tools are very powerful and can be best combined with process mining. Do you have any experience of using both? What are your observations?

I just wanted to briefly let you know about two small updates we made to Nitro this week.

Fixing bugs…

On Tuesday, Joos alerted us to two bugs that were present in Nitro 2.0.0. The first one is especially annoying, since it led to the fact that you would see our “demo limitation” dialog every time after you exported a log — even if your log was below the demo limit (or the limit set by your ticket).

The only time you should see this dialog is of course in a situation like above, when you have actually exceeded the export limit.

The other bug was a problem where exporting a certain type of event logs to XES would result in files that could not be properly loaded by ProM 6. Both these bugs were fixed in Nitro 2.0.1, which was released yesterday.

…and adding features

Today we received a feature request from Martina, who asked whether it was possible to export the information shown in the analysis view to Excel. That is actually an awesome idea, and I wondered why I did not think of this in the first place. Sometimes viewing this information is only the first step, and you want to analyze it further with Excel or statistics software, or create some nice charts from it.

However, I did not want to clutter Nitro’s user interface with more buttons. In my experience, having a nice and clean user interface really helps to find your way around a software tool, and makes you more productive.

The solution I came up with is, in hindsight, rather obvious: When you right-click¹ any table in Nitro’s analysis result, you can now choose to export this table’s data to a CSV² file, which can be loaded in Excel and many other tools.

Get it while it’s hot

We have released Nitro 2.0.2 today, which incorporates both the bug fixes contained in 2.0.1, as well as the export of analysis data to CSV, as described above. How do you get the latest Nitro version?

• If you are not already running the 2.0.x version of Nitro, download it from www.fluxicon.com/nitro/.
• Every time you start Nitro, it will check whether updates are available. Nitro will also check for updates every few minutes while it’s running.
• Whenever an update is available, Nitro will automatically download it in the background. A badge on the update button in Nitro’s toolbar shows you that an update is ready to be installed.
• Nitro needs to be restarted to install an update. You can either restart Nitro manually, or you can do this from the update dialog (which is shown when you click the update button in Nitro’s toolbar).
• After Nitro has been restarted, the latest update is installed and ready for use.

A big thanks to all of you who have sent us your bug reports and suggestions for Nitro! We work hard to fix bugs as soon as we are aware of them, and we always try to implement your suggestions. Some of them just take a little longer, until we know how to do it right.

Thanks for your patience, and keep that feedback coming, either through Nitro’s built-in feedback or by sending us a mail to support@fluxicon.com!

1. On Mac OS X, you can press the “control” button while you click. ↩
2. Comma-separated values ↩

“Powerpoint reality” is what Wil van der Aalst calls the level of insight that organizations often have into their business processes. The processes that are modeled, communicated and put on Powerpoints are usually much more complex in reality than people think they are.

At the same time, IT systems record detailed information about the executed processes. These data can be automatically analyzed by process mining techniques to generate graphical process maps which bring the actual process reality into the picture.

In an interview for the Dutch I/O ICT magazine, Wil van der Aalst, Boudewijn van Dongen, Erik Verbeek and myself talked to Karina Meerman about process mining. Here is the full article (in Dutch).

It is always a challenge to explain process mining to people outside the field. There is just so much context to be considered:

1. There needs to be a realization of the importance of business processes and process thinking for improving the quality and efficiency of organizations. Otherwise the question is, “Why would you even want process models, be it in Powerpoint or not?”
2. You need to have IT support in place for these processes, and the data that are collected by the systems need to fulfill certain minimum criteria. Also, the person you are talking to needs to be aware of the fact that this data is already available. Otherwise you would not believe that it is possible to automatically discover processes by looking at the data.

As for the latter point, Wil made it clear that there is more and more data, so this point is hardly an issue anymore¹:

The amount of data grows exponentially. Earlier on, you went to a travel agent and you got a paper ticket. The number of transfer times was limited. Now, when you book a ticket online, that site contacts several airline companies and a payment system. All those events are recorded.

Wil explained that these data reflect the real world in an increasingly better way:

The time is ripe for process mining. The digital world is very close to the real world. The introduction of diagnosis-treatment combinations in hospitals — which mean that payments are only provided based on registered event logs — has triggered an explosion of data. And if you, for example, order a book at Bol.com then it does not matter whether the book really is in stock — that you can see it on a shelf — because if the information system says it is there, then it is there.

What about your experience? Do you find it difficult to explain process mining? And if so, which aspect or part of it do you find particularly hard to explain? Let us know in the comments.

1. Freely translated by myself.  ↩

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.

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.