Process mining vs. process modeling vs. process context

These three get used as if they were competing purchases. They are not. They answer different questions, they fail in different directions, and there is a sensible order to them.

Process modeling: what should happen

Modeling is the discipline of describing intent. Someone decides how a process is supposed to run, and draws it: steps, sequence, decision points, swimlanes.

What it gives you: a statement of intent. Something to onboard against, to audit against, to design a system change against. It can describe processes that have never run, which mining cannot.

How it fails: it describes the process as designed, which may differ substantially from the process as performed, and the model has no way of knowing. It also goes stale immediately and silently, because nothing in a diagram records when it was last true.

Process mining: what did happen

Mining reads event logs out of your systems and reconstructs what actually occurred: the real paths, the frequencies, the durations, the variants, the rework loops.

What it gives you: reality, at scale, with numbers. It is very good at finding the gap between the process everyone describes and the process the logs show, and at telling you where the time goes.

How it fails: a log records that something happened, not why, and not what should have happened. It has no access to intent, to ownership, to the policy that constrains a step, or to the reason the exception path exists. So conformance analysis needs a reference model, and if one does not exist, the reference gets reconstructed from the log itself, which is circular, or supplied by a consultant, which is expensive and unverifiable.

Mining also only sees what the systems record. Work in email, in spreadsheets, or in someone's judgment is invisible to it.

Process context: what it all means

Context is the record of the work with meaning attached: the things that move and the events that change them, plus the people, policies, targets, systems and job aids attached to the specific step each one concerns, and evidence on every element showing where it came from.

What it gives you: the semantic layer neither of the other two holds. Who decides. What constrains it. Which system and which screen. Why the step exists. And, critically, whether each statement is verified and by whom.

How it fails: on its own, it describes intent, not reality. It cannot tell you that the approval step is skipped eleven per cent of the time. That is what mining is for.

The comparison in one table

| | Modeling | Mining | Context | |---|---|---|---| | Question | What should happen | What did happen | What it means | | Input | People's knowledge | System event logs | Documents you already have, confirmed by people | | Output | A diagram | Statistics and variants | A queryable, evidenced record | | Knows intent | Yes | No | Yes | | Knows reality | No | Yes | Not yet | | Knows who decides | Sometimes, informally | No | Yes | | Knows the constraining policy | Rarely | No | Yes, with the page it came from | | Goes stale | Immediately and silently | No, it re-reads the logs | Visibly, because every item is dated and sourced |

Why context comes first

Notice the failure symmetry. Mining knows reality and not intent. Modeling states intent and knows nothing about reality.

Conformance, the comparison people actually want, requires both. And of the two, intent is the one that has to exist first, because a deviation is only meaningful against a statement of what should have happened.

The designed process, with meaning and evidence attached, is the ground the event data lands on. With it, a deviation stops being a statistical artifact and becomes a comparison against a human-confirmed statement of intent, where every gap points back at the page that says what should have happened.

That is why the record here follows an open process-record standard from day one. When real event data arrives, it is an import rather than a rebuild.

The ladder

Define. Store how your processes are supposed to run, with evidence. This is what ships today.

Mine. Replay real event data against that record. On the roadmap, not shipped, and it is worth being precise about that, because a diagram showing four solid layers when one of them does not exist yet is exactly the kind of overclaim that costs credibility.

Operate. Agents acting inside a defined and measured process.

Each rung needs the one below it. Mining without a defined record gives you statistics with no meaning. Operating without measurement gives you automation with no feedback.

How the record gets built from documents you already have →

• What is enterprise process context?

  A definition, and the argument for why process, rather than data, is the thing everything else in an organization attaches to.

• How to document a business process (without a six-month workshop)

  The usual way puts forty people in a room and asks them to remember. There is a way that starts from what they already wrote down.