Cross-organisational process mining

What is cross-organisational process mining?

Cross-organisational process mining analyses a process that runs across several independent organisations rather than inside one company. Each party keeps its own systems, its own identifiers and its own internal steps, and the analysis joins the points where they interact.

Think of an order that a retailer places with a manufacturer, who books a carrier to deliver it. No single system holds the whole story. The goal is usually end-to-end performance, smoother collaboration, compliance, or finding the delays that sit at the boundaries between parties.

The important word is independent. You are not treating every organisation as one big information system. You are linking shared interactions, such as order, shipment, receipt and payment, while each party stays in control of its own data.

Working with distributed event logs

The data stays spread across separate logs, and matching them is rarely automatic. The manufacturer records a purchase order, the carrier records a shipment, the customer records a goods receipt, and none of them share an activity name, a timestamp convention or a case ID.

So correlation has to be built on purpose. Shared business keys, message identifiers and object relationships link the logs; timestamps alone almost never do. Keep the source organisation, the local event ID and the lineage on every record. A combined log that erases where each event came from is one you cannot trust.

Public and private behaviour

No organisation has to expose every internal activity. Public events describe the interactions and contractual milestones the parties share; private events stay inside each company. A joint model can show the public handovers and represent each party's internal work as a single abstract step.

The level of abstraction should be enough to answer the shared question without giving away trade secrets or internal controls. When a party needs to dig into a problem on its own side, it can run root cause analysis locally and share only the explanation, not the raw events.

Example: a supply chain handover

A retailer orders from a manufacturer, who hands the goods to a carrier. The retailer sees order confirmation, a dispatch notice and the receipt. The carrier logs pickup, hub scans and delivery. Neither sees the other's internal steps.

The joint analysis shows most of the delay sits between the manufacturer marking goods ready and the carrier picking them up. The factory's internal steps are not needed to see that. If the manufacturer wants to know why, it can analyse its own logs and report back a cause, without opening its shop floor to everyone.

Matching events and messages

A message has a send event on one side and a receive event on the other. Network delay, retries and duplicates can make the two counts disagree, so decide which event stands for the contractual transition and how you treat missing acknowledgements.

Wording is another trap. "Shipped" might mean a label was created, or the goods left the warehouse, or the carrier collected them, depending on who says it. Agree a shared vocabulary that pins down each event's definition, time zone, key and quality rule, and do not force different meanings into one generic activity.

How this differs from internal process mining

Internal process mining works within one organisation's governance and access, even when its systems are scattered. Cross-organisational analysis adds boundaries around contracts, trust, competition, data ownership and who handles incidents.

That changes the architecture choices. A central trusted party can collect everyone's data and analyse it, which is simple but concentrates risk. Federated or secure-computation approaches run the calculation over local data and share only agreed results. A layered model can combine public process fragments while each party keeps its private model. Every option trades usefulness against complexity and trust.

What to watch out for with cross-organisational process mining

Process data reveals commercial secrets. Volumes, prices, customer relationships and operational weak spots can all leak, and pseudonymising names does not hide them. Even a discovered process model can expose private business logic without showing a single raw event.

The contract does the heavy lifting. Agree the purpose, the dataset, the roles, retention, security, which analyses are allowed and how data is deleted, before anyone shares a log. Handle personal data under the applicable law.

A shared chart is not a neutral referee. Compare event counts on both sides of each handover, investigate unmatched messages, and sync clocks or model the uncertainty. When parties disagree, the model informs the conversation; it does not settle a contract dispute on its own.