Object-Centric Process Mining: When One Process View No Longer Tells the Whole Story

Object-centric process mining shows how orders, deliveries, invoices and payments really interact. Here is when it changes the decisions you make, and when classic process mining is still the better choice.

Picture a typical review meeting in a process mining project. Procurement, logistics and finance look at the same order-to-cash analysis, and each team recognises only part of its own work. Logistics asks where the partial deliveries went. Finance cannot see why invoices were held.

Now consider what happens when the team changes the perspective from orders to deliveries. What looked like a straightforward order fulfilment process can reveal a very different picture: partial deliveries, consolidated shipments and invoices that depend on several orders. Nothing in the underlying data has changed. Only the viewpoint has.

The data behind the analysis can be accurate and the dashboard technically correct. The problem is that the analysis follows one thread through the business, while the work itself does not. An order becomes three deliveries, two of those deliveries end up on one invoice, and one payment clears invoices from several weeks of orders. Decisions made from that single thread can rest on an incomplete picture.

Why case-centric analysis can miss the bigger picture

Classic process mining starts by choosing one identifier as the case. For a service ticket, an incident or a single-document approval, that choice is usually straightforward, and the method works very well.

It gets harder when one business event belongs to several orders, deliveries or invoices. A shipment consolidates lines from several orders, and one payment settles a batch of invoices. Depending on which object you choose as the case, traditional analysis may duplicate events, hide relationships or create process patterns that never happened. The numbers can still look credible, even when the operational story is incomplete.

Process mining research calls these effects convergence, divergence and deficiency. With convergence, one shipment covering five orders may be counted as five shipment events. With divergence, activities involving different related objects can appear repeatedly within one case, creating the impression of rework that never happened. With deficiency, events that do not fit the chosen case type may disappear from the analysis altogether.

Consider an order-to-cash process where the order-level analysis suggests that order processing is running smoothly. Switch to the delivery perspective, however, and a different pattern may emerge: repeated partial deliveries, consolidated shipments and delays that were difficult to see from the original view.

The bottleneck hasn't necessarily moved. The analysis has revealed a part of the process that was previously hidden.

There is also a practical cost. In traditional case-centric analysis, answering questions from different perspectives often means preparing and maintaining separate event logs. This adds work and can make it harder to reconcile findings across teams.

One model, multiple perspectives

Object-centric process mining (OCPM) is an approach to process mining that analyses multiple interconnected business objects, such as orders, deliveries and invoices, within a single process model. It preserves the relationships between these objects and the events that affect them, showing how work moves across different parts of the business.

Instead of analysing each part of a process separately, you can see how they affect one another.

OCPM extends classic process mining rather than replacing it. From one connected model, you can look at the process from the perspective of an order, a delivery or an invoice, using the charts and performance measures your team already knows.

QPR ProcessAnalyzer is QPR's process mining and process intelligence platform, combining traditional case-centric analysis and object-centric process mining in one solution. It allows teams to explore different viewpoints within the same model, without building a separate analysis for each one.

For example, an analyst can start with late deliveries, trace which invoices were affected and identify the order patterns behind both. Each perspective answers a different question, but the relationships between them remain visible.

The model can be built from data already available in business systems such as SAP, Oracle or Microsoft Dynamics 365. Rather than manually creating separate event logs for every perspective, QPR ProcessAnalyzer uses the relationships in the source data to create a connected model.

For customers using QPR ProcessAnalyzer as a Snowflake Native App, this takes place within their own Snowflake environment, without moving the data elsewhere.
The real value, however, is not in how the model is built, but in what it allows organisations to see and understand about their operations.

What this changes for business operations

For an organisation, the value of OCPM shows up in several practical ways:

• Faster root-cause analysis across departments. A delay can be traced across procurement, logistics and finance without each team having to build its own analysis.

• Less duplicated data preparation. One connected model can support multiple analytical perspectives instead of maintaining separate event logs for each.

• Better visibility into delays, rework and dependencies. Partial deliveries, consolidated invoices and shared materials remain visible, making it easier to understand how issues in one area affect another.

• More reliable context for AI-driven analysis. Relationships between business objects provide a richer foundation for AI to investigate operational questions.

This matters most where one event touches several objects and a delay in one spills into others. Order-to-cash is an obvious example. In supply chains, one late component can hold up several production orders. In quality management, a material batch may need to be traced through every product in which it was used.

Shipbuilding is a particularly good example.

At Meyer Turku, designs drive purchase requisitions and purchase orders, and materials from more than 1,000 suppliers must arrive when production needs them. No single case ID can represent that entire flow.

The company is connecting design, planning, purchase requisitions, purchase orders, goods receiving and invoicing into one end-to-end view in QPR ProcessAnalyzer. The analysis has already challenged long-held assumptions by showing what is actually happening across interconnected processes, rather than relying on generalisations.

“We can pinpoint exactly where we have challenges, and which parts are really working well.”

Kimmo Liukkonen

Head of Business Processes, Meyer Turku

From process intelligence to operational context for AI

AI agents need more than access to enterprise data. To answer meaningful questions about business operations, they need to understand how orders, deliveries, invoices and other business objects are connected, and how work actually flows between them. 
They too can see loops that never happened or miss ones that actually matter.

This is where object-centric process mining can provide something particularly valuable: a connected view of how business operations actually work. An object-centric model keeps the loop attached to the object it belongs to, so an agent can recognise repetition as repetition and reason about the cause.

Consider a simple question: Why did invoicing slow down last quarter?

A traditional analysis built around a single case type may reveal delays within that view, but miss the relationships between orders, partial deliveries and consolidated invoices. An object-centric model preserves those connections, making it possible to investigate how delays in one part of the process affect another.

For AI agents, access to this kind of connected process information creates an opportunity to move beyond isolated metrics towards a more complete understanding of operational reality.

This is also why process intelligence has an increasingly important role to play as the operational context layer for enterprise AI. The more accurately AI can access and interpret how work actually happens, the better equipped it is to support meaningful business decisions.

When should you choose object-centric process mining?

Not every process needs it. A simple rule of thumb:

My own quick test: if changing the case ID changes the story your process data tells, consider an object-centric model. If one case still describes the process accurately, keep it simple.

The aim is an analysis that reflects the complexity already present in your business, and no more. As AI becomes part of everyday operational decisions, getting that picture right matters more each year.