Heuristics Miner

What is the Heuristics Miner?

The Heuristics Miner is a process discovery algorithm designed for logs that contain noise and incomplete behaviour, which describes almost every real business log. It reads an event log and builds a process model based on how often activities follow one another.

Instead of treating every observed step as equally meaningful, it weighs the frequencies. A path taken by thousands of cases is treated as part of the real process; a path seen twice is treated as an exception and can be left out.

That single idea, counting rather than just noticing, is what makes it one of the most used discovery algorithms in practice.

The dependency measure

The engine of the algorithm is the dependency measure. If activity A is very often followed directly by B, and B is almost never followed directly by A, that lopsidedness is strong evidence of a real step from A to B.

The measure compares how often each direction occurs and scales the difference to a value between roughly zero and one. A high value means a dependable step; a value near zero means the two activities have no clear order.

Frequency on its own does not prove cause and effect. The measure describes the order in which things were recorded, which the analyst then has to interpret against how the business actually works.

Thresholds and what they control

The Heuristics Miner is driven by thresholds you set yourself. A dependency threshold decides how strong a relation has to be before it appears in the model. A minimum number of observations stops a single accidental transition from becoming a permanent arrow.

Set the thresholds high and you get a clean picture of the main process, but you risk dropping valid exceptions. Set them low and the model captures more behaviour at the cost of becoming crowded and hard to read.

Because the output depends on these settings, two analysts can hand you two different models from the same log. Always record the values you used.

A worked example

Imagine a log with a thousand cases where A is followed by B, and three cases where B is followed by A, caused by an odd recording order or a rare piece of rework.

The Alpha Miner would see both directions and might wrongly conclude that A and B run in parallel. The Heuristics Miner keeps the strong A to B step and pushes the weak reverse below the threshold, so the model reflects the dominant reality.

There is a warning inside this example. If those three cases are a serious compliance breach rather than random noise, filtering them away hides something you needed to see. Discovery and investigation are different jobs.

Short loops and rework

The algorithm uses separate measures for a step that repeats once (A, A) and for a two-step back-and-forth (A, B, A). This lets it tell genuine rework apart from two activities that simply happen in a flexible order.

Even so, the result is only as good as the data. Duplicate events can invent a loop that never happened, so it is worth opening the actual cases behind a loop before you label it as rework.

Heuristics Miner versus Alpha Miner

The Alpha Miner reasons purely about whether a relation appears and assumes a clean, complete log. The Heuristics Miner reasons about how often relations appear, which is why it survives contact with real data where the Alpha Miner falls apart.

That resilience comes at the price of the threshold settings, which the Alpha Miner does not have. The trade is worth it on messy logs and pointless on tidy textbook ones.

Heuristics Miner versus Inductive Miner

The Inductive Miner builds a block-structured model and guarantees soundness, meaning the model has no dead ends. The Heuristics Miner focuses on frequent dependencies and gives no such structural guarantee; the model it draws can, in some cases, be hard to execute cleanly.

Neither is simply better. Compare them on the same log, with the same preparation, and judge which one answers your question.

What to watch out for with the Heuristics Miner

Rare is not the same as wrong. The behaviour you filter out is often the most interesting part: the fraud, the escalation, the broken exception. Keep the rare variants for a separate look.

Report what you dropped. State what share of cases, events, and paths fell outside the model, so nobody mistakes a filtered view for the whole picture.

The visual is not the verdict. A thick arrow means frequent, not correct. Check fitness and precision on the final model rather than trusting how the diagram looks.

Talk to the people who do the work. A surprising dependency is a question for a domain expert, not a conclusion on its own.