Object-Centric Process Mining: Analyzing Processes Across Multiple Objects

What Is Object-Centric Process Mining?

Classical process mining methods typically group events using a selected case ID, such as an order or batch number.

This view is suitable when the chosen case perspective adequately represents the specific analysis question. However, operational information systems often contain multiple intertwined objects. An order contains several items, an invoice can cover several orders, and a shipment can combine items from different orders. Berti and van der Aalst therefore show that an event does not necessarily have to belong to exactly one case but can be associated with multiple objects of different types.^[1]

OCPM preserves these cross-object relationships for analysis. Instead of first choosing a single case perspective, events, objects, and their connections are considered together. This makes it possible to discover comprehensive models and extract individual object views as needed.^[1]

Investigating Test Waiting Times Across Connected Lots

An illustrative production sequence proceeds from a harvest through processing and drying to several inventory lots. Samples and test results are linked to these lots with their specific relationships. The analysis question is: How is the time between sampling, result availability, and subsequent release distributed across the affected lots?

First, the timestamps and their meanings must be defined. “Result available” can mean technical availability or completion of the substantive assessment. It must be clear which results each lot required. Shared test objects connect multiple lifecycles.

The analysis distinguishes the wait for the required result from the time until the subsequent decision. When counting completed tests, a shared result must not appear multiple times as a new test. When considering affected lots, however, the same waiting period can affect several lots; this unit of analysis must be stated explicitly.

Without measurement data, neither a duration nor the cause of a bottleneck can be inferred. The example describes an investigation setup. Only cleaned events, documented relationships, and defined calculation rules make a result possible.

Objects Have Their Own Lifecycles

Objects are not merely additional attributes of an event. Each object has its own lifecycle. A batch is created, processed, tested, placed on hold, and released. A piece of equipment is commissioned, used, cleaned, checked, and maintained. A sample is collected, transported, analyzed, and linked to a result.

These lifecycles do not run independently alongside one another. An equipment check can affect several production operations. An analysis result can influence the release of a batch. A material batch is consumed across several tasks and products. OCPM therefore examines not only the sequence of activities within a single case but also synchronization between objects of different types.

An object's lifecycle can be examined as a separate view without losing its relationships to other objects. For example, the path of a laboratory sample can be investigated and then traced back to the batch, sampling task, person, and release decision associated with it.

When a Single Case ID Hides Relationships

In a classical event log, the case ID determines which events belong to the same process instance. If the order is selected as the case, all events with the same order number appear in a shared trace. This sounds unambiguous but can distort relationships to invoices, shipments, or individual items.

A simple example:

• Order A contains items P1 and P2.
• Order B contains item P3.
• P1 and P3 are transported together in shipment S1.
• P2 follows later in shipment S2.
• Invoice R1 covers P1 and P2.

If the order number is used as the only case ID, the shipping event for S1 must be assigned to both order A and order B. The event may be duplicated. If the shipment is selected as the case instead, events that concern only the order or invoice disappear. Each perspective shows a partial view, but none preserves the complete relationship network.

The research literature describes this problem as a consequence of multiple intertwined case notions. Real systems such as ERP and CRM applications store their data in connected tables and objects; reducing them to a single case requires an initial transformation.^[1][2]

What Is Lost During Flattening

To analyze object-based data with classical methods, the data are often flattened. One object type is selected as the case notion. Events without an object of that type are removed; events with several objects of that type are replicated for each object.^[1]

This creates three typical problems:

Shared Participation Must Be Preserved

The process events of a test can connect both the sample and the affected lots. For a waiting-time analysis, the crucial question is which lots depended on which result. A mere list of all objects occurring during the period would not express this relationship.

XES and OCEL structure event data differently for exchange. Object-centric analysis must additionally account for the roles of relationships: the origin of a sample, the reference of a result, and the subject of a release are different connections.

The published SEFM example shows the convergence distortion directly: event 9913 (place order) belongs to order o2 and at the same time to items i3, i4, and i5. If item is selected as the case notion, the same real event has to be assigned to three item cases.^[5]

This is the analytical distortion: three entries in the flattened view must not be interpreted as three real order events. The original event identity and its relationships to multiple objects need to be preserved.

Relationships Between Objects

Not every domain relationship arises only through a shared event. A sub-batch belongs to a production batch, a piece of equipment is located in a room, and an SOP version replaces an earlier version. OCEL 2.0 can therefore also represent qualified object-to-object relationships.^[3]

This level matters for analysis. If a deviation is identified on a piece of equipment, the question may be which batches were processed with that equipment during a particular period. This requires equipment, task, and batch relationships to be combined. A single case trace does not automatically provide this context.

Object relationships also depend on time. Equipment can move to another room, a person can take on a different role, and a material batch can be split. An object-centric model must therefore show when a relationship or attribute applied. Otherwise, current assignments may be incorrectly applied to earlier operations. OCEL 2.0 provides timestamps for changes to object attributes. An object-to-object relationship, by contrast, consists of two object identifiers and a qualifier, without its own validity interval. To analyze a room change, for example, its temporal meaning must be modeled separately, such as through a change event with the participating objects.

From Multiple Views to an Overall Model

OCPM does not mean displaying all data in an unreadable overall picture. Object-centric models can represent multiple object types together while still being filtered or simplified for a particular perspective. Berti and van der Aalst describe object-centric Petri nets whose places correspond to object types and whose transitions can consume or produce objects of different types.^[1]

For users, the specific Petri-net notation matters less than the principle: analysis starts with a connected object model. A view is selected only for a specific question. This makes it possible to understand which relationships have been excluded and which remain in the result.

A classical model, by contrast, often starts by selecting a single case type. Other relationships must then be reconstructed using additional attributes, joins, or separate analyses.

Questions That Object-Centric Analyses Make Possible

An object-centric data foundation expands the possible process questions. For example, it can be used to investigate:

• which material batches were used in which products,
• which tasks affected several batches or pieces of equipment simultaneously,
• how often responsibility for a sample changed between collection and result,
• which equipment events coincide in time with subsequent deviations,
• whether releases waited for all required sub-objects,
• how splitting, merging, and further processing took place,
• which variants occur only in particular combinations of material, equipment, and role.

These questions connect behavior and structure. The issue is not only which activity followed another. It also matters which objects participated in that transition and how their lifecycles influenced one another.

The Intended Model and Object-Centric Execution

A workflow model describes the intended tasks, decisions, and transitions. Object-centric event data, by contrast, show which specific objects participated in execution.

These levels complement one another. The workflow model can require a sample to exist before release. OCPM can show whether the decision was actually connected to the correct sample and the affected inventory lot, whether several lots referred to the same result, or whether waiting times accumulate at particular object handoffs.

Merely connecting an event to several objects does not yet prove conformance. The expected relationships, cardinalities, and sequences must first be defined in domain terms and then compared with observed execution.

Process relationships make explicit which roles events and objects play within the shared process.

Limits of Object-Centric Analyses

• More relationships do not automatically mean better data. Incorrectly linked objects produce a plausible but inaccurate process picture.
• An object-centric log does not prove completeness. Missing events or relationships remain missing even in a more expressive model.
• Correlation is not causation. Shared objects and temporal proximity alone do not establish that one event caused another.
• OCPM is not evidence of regulatory compliance. Analyses can reveal deviations and relationships; their legal and substantive assessment is still required.

The Unit of Analysis Determines the Result

A test can affect several lots. This creates different questions: How many tests took place, how many lots waited, and at which transition did the waiting time arise? OCPM helps investigate these questions using a connected data foundation.

The value lies in the understandable selection and analysis of these relationships. The model must show which objects, events, and time references were considered. Only then can an unusual transition be subjected to a targeted substantive investigation without already inferring a cause from shared participation.