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

You should follow us on Twitter here.

Two Misunderstandings About Process Mining and How to Avoid Them 3

Giving good presentations is hard. You want your give your audience a new perspective — but to send them in the right direction you need to know where they are coming from. Otherwise, they can be lost on the way.

Barcelona traffic

In the past weeks, I have given several invited talks about process mining. As always, I was met with the enthusiasm I usually encounter when people hear about process mining for the first time and see it in action. And there were loads of follow-up questions and discussions in the break afterwards.

From the questions that I get, I can typically see whether the attendees have understood the concept. Good questions are, for example, about data quality or additional analysis questions (“Can I also do X?”). Not so good questions (for me as a presenter, of course) reveal more fundamental misunderstandings.

I think I got a better grip on two common misunderstandings last week, which I want to share with you here. Perhaps this is useful for your own process mining presentations as it might help you to spot similar confusion.

1. Event logs are not actually logs

The first misunderstanding is mostly caused by the terminology (“logs”, “event logs”, “transaction logs”) and the way that we talk about data in the process mining field. When we say “logs”, people often think of something like an Apache server log or an error log. Of course, this is not what we usually have in mind for process mining.

The transaction records we look for are rarely written out of the information system as an actual “log file”. The relevant information is typically stored in some internal database. Sometimes there is a direct way to export the data as a CSV1 file. Other times we start hunting down timestamped data for relevant business events in the system’s database. For example, in a sales process, relevant process milestones such as “Proposal sent” are most likely recorded somewhere in the supporting IT system, together with a timestamp of when that milestone happened.

One of the big advantages of process mining is precisely that there is no fixed format or “log file” required, but rather that existing information that is already available in your system is used in novel ways. Because there are very few requirements towards the data to be able to do process mining (Case ID, Activity, and Timestamp), it is applicable to almost any process.

My recommendation: Show an example and emphasize that the “event log” does not need to be there in that form, but that the data can be extracted from almost any IT system.

2. Processes are already there

People who are not working with business processes sometimes wonder why businesses would bother to “create processes” at all. They do not realize that all these processes we are talking about are already there. All organizations have processes, hundreds of them — to buy things, to hire people, to sell, to produce, to engineer, to advice, to support clients, to support employees, and so forth — Process mining just helps to understand them better.

Conversely, people in the BPM field often think of processes only in terms of the BPM lifecycle. We talked about this in a previous post on 7 misunderstandings about process mining. It is way too narrow to think about processes just in the context of automation. There are many processes leaving traces in non-BPM IT systems today (for example CRM, ERP, PDM, ITSM, Home-made or legacy systems, data warehouses, or even Excel). These processes can be perfectly analyzed with process mining as they are.

My recommendation: Keep in mind where your audience is coming from. Is their background in BPM? You might want to emphasize that process mining is applicable to processes from other types of systems, too. Is their background very far from typical process improvement topics? You should give them an example of what kind of processes you are talking about.


Have you had similar experiences when you explained process mining to people who are new to the topic? What other misunderstandings have you encountered? Let us know in the comments!


  1. Comma-Separated Values. 

Comments (3)

Yes absolutely, misunderstanding #1, I meet that every single time I talk process mining with people not familiar with process mining. “But we don’t store logs in a way making it possible to import” is always stated.

Another misunderstanding I see is that people often underestimate the analysis capabilities of a process mining tool. “But we can do most of the analysis in an Excel pivot table” is often said.

I fnd that digging out the processes (process discovery) is usually accepted as an advantage when talking to people new to process mining. However, the misunderstandings that the log files are not accessible and that the analysis could be done in Excel, needs more conversation

Thanks, John!

That’s an interesting point. I wonder whether those who say that they could do that in Excel have tried to analyze process flows in Excel – It’s actually really hard.

Just think of something as simple as measuring the time it takes to get from activity A to activity C. To get such metrics from Excel, people put the activity timstamps in dedicated columns (one column per activity), but this brings other problems: You lose the visibility of loops (because only the last occurrence is visible) and you make assumptions about the process flow, which do not need to hold in reality.

And of course you don’t have the visual representation of the process in Excel, which for more complex processes is absolutely vital. And you don’t get the variants, and you don’t have the process-oriented filtering, …

When you hear that the next time, perhaps you can ask which part of the analysis exactly they are referring to. I would be curious!

I totally agree.

I plan on (some day) making some specific examples so that the limitations becomes more clear.

I’ll keep you posted on that


Leave a reply