Process Discovery ≠ Process Identification
Matthijs challenged me to come up with a list of 7 pitfalls using process mining. To allow for a more detailed discussion, I decided to start a series on the misconceptions around process mining and process discovery that I have seen so far.
Here is the first one:
Pitfall #1: Process mining discovers which processes exist.
Process mining cannot help you to discover which processes exist in an organization in the first place1. The starting point is usually the desire to improve or simply better understand one particular process. Then, one looks for the data that is needed to do the process mining analysis.
I recommend to read Alec Sharp’s BPTrends article ‘Some Thoughts on Process Discovery’, in which he nicely illustrates that there are at least four different interpretations of the word “Process Discovery”:
The initial identification of what the processes are, producing a list or simple block diagram.
Building a visual representation of process flow, which is often called process mapping or process modeling.
Tracing or enumerating all the actual execution paths through a process to identify the factors that contribute to successful or problematic cases.
A more general assessment of what is right or wrong with a process.
The core idea of process mining relates to item No. 2, and process mining can certainly help with No. 3 and No. 4. But it will most likely not help you at all with No. 1.
Alec also uses the term “Process Identification” for finding out what the processes are in an organization. In this first phase, the process scope, context, and goals are established. “Process Discovery” as we mean it in the area of process mining2 falls into a later phase, in which the goal is to understand a current ‘as-is’ process (of which the process scope is clear) in detail. Traditionally, this requires the manual modeling (or mapping) of the process flows as identified via workshops or interviews.
Compared to the traditional, manual process mapping, one of the main benefits of process mining is that it can help you understand how your process really works based on hard evidence. But it cannot help you to identify the processes that you should mine.
What do you say? Have you encountered this misconception as well? Or what are other misconceptions that you have seen?
There is one exception: In the case that the organization is already driven by a Process-aware information system with defined processes and a generic logging mechanism, one can look at the log data to find out which of these defined processes are actually used (and how and how much). But this is usually not the case. ↩︎
In fact, also within the process mining community there are ongoing discussions about terminology as pointed out by Keith Swenson in his latest Process Mining Update. ↩︎