This is Flux Capacitor, the company weblog of Fluxicon.
You can find more articles here.

You should follow us on Twitter here.

Is Process Mining More Suitable for Manual or Automated Processes 2

This is another data requirements FAQ post with a question that I get quite often:

FAQ #2: Is Process Mining more suitable for manual or automated processes?

Process mining is most suitable for IT-supported (thus observable) processes with human touch points. On the spectrum of automation, neither totally manual nor totally automated processes are particularly interesting for process mining.

Here is why.

Totally manual

Completely manual processes are those without any IT support. Think for example of someone who:

Clearly, this is a manual process. But also if you handle a purchase order by:

this is technically still a manual process. The problem with manual processes is that there are no structured log data, or at least none that can be easily used for process mining.

In this case, one can still observe the process for a few weeks (by instrumentation or manual logging) and collect data that way. It can be valuable to do so, but one of the drawbacks of this approach (besides the extra effort) is that one has only a limited sample of data for the analysis.

Totally automated

At the other end of the spectrum are completely automated processes (machines talking to machines). Brian Arthur gives the following example for full automation in The second economy:

Twenty years ago, if you went into an airport you would walk up to a counter and present paper tickets to a human being. […] Today, you walk into an airport and look for a machine. You put in a frequent-flier card or credit card, and it takes just three or four seconds to get back a boarding pass, receipt, and luggage tag. What interests me is what happens in those three or four seconds.

From a process mining perspective I am not interested in what happens in these three to four seconds. If a process can be totally automated, then there is not much uncertainty about how it is actually executed.

Observability vs. Automation

Process mining is most interesting for IT-supported processes where humans are in the loop. Often, there are parts of the process that are automated, but in between there are activities where real people are doing real things in the physical world. They make decisions, talk to someone, take action.

Humans introduce variability into business processes because they have to deal with the complexities of the real world. Today’s IT systems make these underlying processes observable, regardless of how automated they are.

Observable means that people are managing their work with the help of IT systems (whether these are ERP, CRM, ACM, PDM, BPM, HIM, ECM, or legacy or custom systems). All these systems store significant events, such as the approval of a purchase order, or the registration of a new customer complaint, to facilitate process work among multiple people. In this way, IT systems make milestones in the executed processes observable and produce data (as a byproduct) that can be used for process mining.

The benefit of process mining is then that it can provide complete and fact-based visualizations and measurements of the actual process flows with all their variations. Usually, nobody has a complete overview of what is actually going on. Process mining can provide this overview in an objective manner, across multiple people, departments, and even across organizations.

So, process mining is for IT supported processes with human touch points. If you have examples of successful instrumentation and mining of manual processes, or of process mining use cases for completely automated processes, please let us know in the comments!

Comments (2)

Nice post! I’d say totally automated processes can be interesting too. Think of a fully automated manufacturing process that still features uncertainties (e.g. actuator or sensor error margins). An automated process might also feature retries or waiting times that can be made visible with process mining!

Hi Eric,

Thanks for your comment! You are right, and I am going to note down your example. In fact, along the same lines (automated retries in a partially automated test process) there is another example that we wrote about on this blog.

Here is the link, perhaps you find it interesting:

Leave a reply