Multi-perspective process mining

What is multi-perspective process mining?

Multi-perspective process mining looks at a business process from several angles at once, not only the order in which activities happen. Alongside the sequence of steps it brings in timing, the data attached to each case, the people and systems doing the work, the decisions taken along the way, and sometimes the objects that flow through the process.

Plain process mining usually starts with a control-flow model: which paths cases follow, where they branch, where they loop. That answers what happens. The extra perspectives answer for which cases, by whom, when, and with what result.

It helps to treat the term as a way of working rather than a single algorithm. You pick the perspectives your question needs and combine what they tell you.

The perspectives you can combine

Most analyses draw on some mix of the following.

• Control flow. The activities, their order, choices, parallel work and loops. Variant analysis and conformance checking show which paths are common and which deviate. On its own, a rare path does not tell you whether it was a mistake or the right call.

• Time and performance. Timestamps give throughput time, waiting time and busy periods. You can compare performance per step, per path or per segment. A slow step is not automatically a bottleneck if it runs in parallel or touches few cases.

• Data and decisions. Case attributes such as product, amount or customer type often explain why cases take different routes. Decision mining looks at which attributes line up with a chosen branch, for example that high-value orders tend to pick up an extra approval.

• Resources and organisation. Who did the work, in which role or team, and how work moves between them. This is the ground that organisational mining covers in more depth.

• Objects. A classic event log fixes one case notion. Object-centric process mining links events to several objects at once, such as an order, its items, the shipments and the invoices, so you can see how their timelines interact.

Example: an order-to-cash delay

Say order-to-cash cases are running two days slower than target and nobody is sure why.

Control flow shows a credit check that keeps repeating. Performance analysis confirms that the variant with the repeat runs two days longer. Segmenting on case data shows the loop mostly hits changed, high-value orders. Looking at resources points to a handover between sales and finance each time the order is amended. Object data reveals that partial deliveries trigger several separate invoices.

No single perspective explained the delay. Together they turn "it is slow" into a specific, fixable pattern.

Integrated models versus linked views

There are two common ways to bring perspectives together. One builds a single model annotated with data, timing and resource information. The other keeps separate views that stay in sync, so selecting a set of cases in one view filters all the others to the same cases.

A single annotated model is complete but gets hard to read fast. Linked views keep each picture simple, as long as the filters and the underlying population really do stay aligned. Whichever you use, write down which perspective each metric comes from and at what point in the case an attribute became known.

What data you need

On top of the usual case ID, activity and timestamp, you need consistent resource fields, case attributes, event-level attributes and, ideally, lifecycle information that separates active work from waiting.

Watch for data leakage. A final outcome that is only filled in after a case closes must not be used to explain a decision that was made earlier, when that information did not yet exist. Check missing values by time, system and segment too, because selective logging can invent relationships that are not real.

What to watch out for with multi-perspective process mining

Correlation is not cause. The data perspective can show that high amounts travel with an extra approval step, but the amount might just track complexity or a policy rule. Test other explanations with someone who knows the process before you act.

More perspectives, more re-identification risk. A rare route combined with a time, a role and an amount can point to one person or one case. Keep attributes to what the question needs, work at team or role level where you can, and apply pseudonymisation where it fits.

Event counts are not a scoreboard. The resource perspective is tempting to read as a ranking of people. Complex work and invisible tasks distort those numbers, so use them to discuss workload and process design, not as a performance rating.