Reading a Process Map Without Drowning

TL;DR: A process mining process map (often a directly-follows graph) shows activities and the transitions between them. Read starts and ends first, then thick paths, then loops and delays, and use filters so rare noise does not drown the story.

What you will learn

1. How to interpret nodes, edges, and common map decorations
2. What a directly-follows graph (DFG) is and is not
3. A step-by-step reading method for busy stakeholders
4. How variants and filters turn dense maps into insight
5. Mistakes that lead to wrong redesign decisions

What are you looking at?

When discovery runs on an event log, the first artifact most people see is a process map: boxes (or circles) for activities and arrows for "this tended to happen next." In many tools the underlying structure is a directly-follows graph (DFG): simple, intuitive, and powerful when read carefully.

Definition: A process map in process mining is a visual summary of observed control flow, typically activities as nodes and directly-follows relations as edges, often annotated with frequency and performance measures from the event log.

It is a summary of observed behavior, not a proof that every arrow is mandatory, desirable, or still current policy.

Anatomy of a typical map

Different tools decorate maps differently, but the reading logic stays the same: structure first, then volume, then time, then exceptions.

What is a directly-follows graph, really?

In a DFG, an edge from Approve to Ship means: in the log, Ship was recorded immediately after Approve for some cases (after sorting that case's events by time). It does not automatically mean:

1. Approve causes Ship in a causal sense beyond succession
2. The edge is allowed by policy
3. Parallelism is fully represented (true concurrency needs richer models)
4. Infrequent edges are equally important as frequent ones

DFGs are excellent for communication. Formal models (for example, Petri nets or BPMN with gateways) can express concurrency and exclusive choices more precisely. That precision is useful later, especially for conformance. For 101 reading skills, mastering the DFG gets you surprisingly far.

A five-step method to read any map

1. Orient to boundaries. Find start and end activities. Unexpected starts (for example, cases beginning at "Cancel") often signal truncated logs or odd case definitions.
2. Follow the highway. Trace the thickest path from start to end. That is your empirical happy path (or at least the modal path).
3. Name the junctions. Where does the highway split? Splits are decision points or uncontrolled variation. Investigate with attributes later.
4. Hunt loops. Loops and back-edges often mean rework, clarifications, or system retries. Quantify before blaming people.
5. Overlay time. Switch from frequency to performance view. A thin edge with huge wait time can matter more than a thick, fast edge.

Walk this method live with a process owner. Ten minutes of structured reading beats an hour of unstructured staring.

Variants: the practical antidote to overwhelm

A variant is a distinct sequence of activities (sometimes abstracted). Showing "top 5 variants cover 62% of cases" is often clearer than a full map. Use variants to:

1. Separate mainstream work from long-tail exceptions
2. Assign owners to exception clusters
3. Decide what to standardize versus deliberately allow

Rule of thumb: if stakeholders freeze at the full map, start the meeting in a variant table, then open the map filtered to those variants.

Filters that save meetings

Use filters deliberately. Document them so you do not hide important exceptions without saying so.

Pair a filtered view with an explicit note: "Excluded 18% of cases that are open or under 1% edges."

Common misreads (and how to avoid them)

1. "The map is the process we must enforce." It is the process you had. Decide intentionally what to keep.
2. "Every arrow is a bug." Flexibility can be valuable; measure impact first.
3. "Thicker is always more important." Cost, risk, and customer pain may sit on thin paths.
4. "Self-loops mean incompetent staff." Often bad UX, missing info upstream, or duplicate logging.
5. "If it is not on the map, it did not happen." Offline work and unlogged steps remain invisible.

From map reading to next analysis

Once the room can read the map:

1. Use conformance when you need "allowed versus observed" language (A5)
2. Use enhancement when the question is delay, resource, or prediction (A2, A6)
3. Fix the event log when the map is nonsense (A3)

Maps are a shared language. Literacy, not denser graphics, is the unlock.

Key takeaways

1. Process maps summarize observed flows; DFGs connect activities that directly follow each other in the log.
2. Read boundaries, then highways, then junctions, then loops, then time.
3. Variants and filters prevent map overwhelm. Document what you hide.
4. Frequency is not the same as importance; validate thin, painful paths too.
5. Treat the map as evidence for conversation, not as automatic policy.

FAQ

What is a process map in process mining?

A process map visualizes how activities follow one another across cases, often as a directly-follows graph (DFG) with activities as nodes and observed transitions as edges. Frequency and performance metrics are usually shown on those nodes and edges so you can prioritize what to inspect first.

What is a directly-follows graph (DFG)?

A DFG connects activity A to activity B when B is observed immediately after A in at least one case. Edge thickness or labels often show how often that succession occurs or how long the wait was between them. It is a practical communication model, with known limits around concurrency.

Why do process maps look cluttered?

Because real logs contain many rare paths, retries, and naming inconsistencies. Without filters, infrequent edges clutter the view. Filtering by frequency, focusing on top variants, and cleaning activity names usually restores readability without pretending exceptions do not exist.

How should beginners read a process mining map?

Start with start and end activities, then the thickest edges (common paths), then loops and long waits. Compare a few individual case traces to the aggregate map before proposing process changes. Individual stories catch data issues the aggregate hides.

Further reading

1. Process Mining Handbook (open access): https://doi.org/10.1007/978-3-031-08848-3
2. Previous: Event Logs in Plain English
3. Related: Process Mining 101: What It Is (and Is Not)
4. Related: The Three Questions: Discover, Check, Enhance
5. Next: Conformance Checking Without the Jargon

Attribution

Educational synthesis inspired by the open-access Process Mining Handbook (van der Aalst and Carmona, eds., 2022), https://doi.org/10.1007/978-3-031-08848-3. This article is not a substitute for the handbook. It is not legal, audit, or vendor advice.