From mining to intelligence

Process mining began as a research field with a simple premise: every enterprise system records timestamps, and those timestamps can be assembled into a picture of the process as it really happened. Discovery algorithms turn event logs into process maps; conformance checking compares those maps to the intended model; performance analysis shows where time and rework accumulate. For two decades this was mostly a diagnostic tool — powerful, but backward-looking.

Process intelligence is the broader discipline that grew around it. It adds the context that mining alone lacks: the business objects a case touches, the KPIs a step affects, the systems and roles involved, the policies that apply. In 2026 the analyst community renamed the process-mining category to reflect this: the market is now evaluated as process intelligence platforms, where mining is one capability among several.

What makes it predictive

A process map tells you that 11% of invoices loop through a second approval and take four days longer. That is useful, and it is history. Predictive process intelligence asks a different question of the same data: for this open invoice, right now, how likely is it to loop — and what would change that?

Technically this is instance-level predictive process monitoring. Models are trained on completed cases — the sequence of events, their attributes, the objects involved — and applied to open cases as they progress. Typical targets are the next activity, the remaining time, the probability of breaching a service level or a due date, and the probability of a specific outcome such as a dispute, a late payment or a short shipment. The research field is mature; the commercial use of it inside operations is still young.

Why prediction alone is not enough

A prediction that nobody acts on is a more expensive report. Two things have to be true for prediction to change an outcome. First, it has to arrive while there is still an intervention window — a number of days in which an action can still alter the trajectory. Second, there has to be a permitted, practical action to take, routed to whoever or whatever can take it.

This is where process intelligence meets orchestration. The connection between a prediction and an action needs policy (what is allowed), value (what the action is worth), risk (what could go wrong) and often human judgment. When those are explicit, the leap from “the model says” to “the system does” is not hidden; it is governed.

What a process intelligence platform has to do

• Connect to the systems where work leaves its trace — ERP, CRM, service systems, data platforms — and normalize events around business objects.
• Reconstruct process reality: variants, conformance, root causes, KPI decomposition and value leakage.
• Predict, per open case, what is likely to happen next, with calibrated confidence and drivers a team can act on.
• Turn predictions into permitted next steps, bounded by policy and explained in plain language.
• Orchestrate the response across people, AI agents, automation and systems at an approved level of autonomy.
• Record what was predicted, decided, done and achieved, so the value is measured and the next prediction is better.

How to evaluate one

Ask to see the loop on one of your processes, not a demo dataset: how long until the first process model, how the prediction target is defined and tested, what action runs at which autonomy level, and how the result is measured against comparable untreated cases. Be wary of accuracy percentages quoted without a process, a horizon and a baseline. And ask what the platform does not do — a straight answer is a good sign.

The test of process intelligence is not how well it describes the past, but how much sooner it lets you change the future.