Ask most process mining tools why an order arrived late, and they will trace one thing: the order. You will get a tidy timeline, placed, picked, packed, shipped, delivered, with a flag on the step that took three days longer than usual. That is true. It is also the wrong story of what happened.
The order did not sit for three days because of anything about the order. It sat because the trailer carrying it, along with a few hundred other parcels, was held at a hub while another lane got priority. The order is one thread in a much larger fabric of shared resources: vehicles, staff, hubs, equipment. A tool that only sees the order will tell you the same incomplete story for every one of those few hundred parcels, one at a time, as if each were an isolated incident rather than a single shared cause.
This is the core limitation behind most process mining today, and it comes down to one modelling decision: the case ID.
The case ID problem
Traditional process mining tools need a single thread to follow through a process, usually called a case ID, though it is sometimes just called the case identifier, or simply "the case." Every event in the system, a scan, a status change, a handoff, gets attached to that one ID, and the tool reconstructs a timeline from it. For a process that genuinely has one moving part, this works well.
The trouble starts with how much data a real operation actually generates. A single warehouse or logistics network can throw off millions of data points a day, scans, status changes, handoffs, across a WMS, a TMS, scanner feeds, and workforce systems. Flatten all of that into one file keyed on a single case ID, and most of that richness never makes it through: a flat, tabular file has room for one identifier per row, so anything else the event touched can only be recorded as a static label, not as a link to another record with its own history. In other words, if the only thing being tracked is which case an event belongs to, there is no field left to record which other objects, which resource, which vehicle, which location, that same event also belonged to.
Most operational processes do not have one moving part. A single parcel shares a van with a hundred others, shares a driver with weeks of other rounds, and shares a hub's outbound lane with an entire day's volume for that route. A single warehouse order shares a picker, a pallet, and a dock slot with dozens of other orders moving through the same shift.
The practical effect is that shared-cause problems get reported as if they were hundreds of unrelated ones. Nobody sees the hub delay. Everybody sees three hundred late orders.
A concrete example
Take a single order moving through a warehouse: it gets picked, packed, and dispatched. Along the way it shares resources with dozens of other orders in the same shift, a picker, a packing station, a dock slot, a delivery run. Another approach is to treat each of these, the order, the picker, the station, the vehicle, as its own object with its own defined attributes, rather than folding them all into a single case. Here is how the two approaches read the exact same event data.
Picking
Order #4471 is picked eleven minutes later than the average for its SKU. A flattened model, tracking only the order, logs this as a case-level anomaly: "Order #4471, picking delay, cause unknown." Look at the object-centric version of the same event, and a different picture appears: the same picker who handled #4471 also picked twenty-two other orders that hour, and nineteen of them show the identical delay pattern, starting at the same minute. The picker did not get slower at picking, they were reassigned mid-shift to cover a gap on another line, and every order that happened to be in their queue absorbed the same lost time. Whoever is reviewing the list only has to look into that once, not nineteen times over.
Packing
SKU CD-2290 shows up in six separate "packing delay" flags across the afternoon shift, each attached to a different order. Flattened view: six unrelated incidents, no visible link between them. Object-centric view: every one of those six orders passed through the same packing lane, which was paused for a scheduled conveyor changeover during that window. The delay belongs to the lane and the changeover, not to the SKU or to any of the six orders carrying it.
Dispatch
Order #5209 makes its scheduled van, but the van itself leaves the dock nineteen minutes late. In the flattened model, this shows up as a last-mile SLA risk flagged against the order, "at risk of late delivery," with no further context. In the object-centric model, the same lateness is visible as a property of the vehicle and the dock slot: the van was held because the trailer ahead of it was still being loaded past its allotted slot. Every order on that van, not just #5209, inherits the same, correctly attributed nineteen minutes, and the dock-slot scheduling becomes the thing worth investigating, not the individual order.
Run this across a full day, and the difference compounds. A flattened model produces a long list of "anomalies" with no visible relationship to each other, the kind of list that gets triaged one ticket at a time, usually never all the way back to a root cause. An object-centric model collapses the same events into a small number of resource-level explanations: one picker reassignment, one conveyor changeover, one dock-slot overrun, each of which explains a cluster of symptoms at once. The underlying events have not changed. What changed is whether the model was built to see the relationships that were there all along.
| Flattened (case ID) | Object-centric | Benefit |
|---|---|---|
| One entity, usually the order, is "the case"; everything else is a field on it. | Order, SKU, resource, and location are all tracked as distinct, related objects. | Nothing about the process is discarded before analysis even starts. |
| A shared cause, for example one delayed resource, surfaces as many unrelated case-level anomalies. | The same delay surfaces once, correctly attributed to the shared object. | One thing to investigate, instead of dozens of duplicate tickets. |
| Rules are typically hardcoded templates applied on top of the data. | Rules are discovered directly from how the objects actually behaved. | Rules stay accurate as the process legitimately changes over time. |
What "object-centric" actually means
This approach has a name: Object-Centric Process Mining (OCPM). Instead of flattening everything into one case, OCPM keeps every object, order, SKU, resource, location, whatever the process actually involves, as its own entity, and records how they relate to each other at each event. The data structure this produces is often called an Event Knowledge Graph: a network where objects are nodes, and events are the timestamped connections between them.
The interchange format most commonly used for this is OCEL (Object-Centric Event Log), a structured way of recording not just "this event happened at this time," but "this event happened, and it involved these specific objects, in these specific roles." And those links do not stop at one event: the same shift can cover several different scans, each touching entirely different items, and a single scan can touch several different SKUs, each of which has its own warehouse. The diagram below shows a small slice of what that looks like, a shift shared across two scans, and one of those scans touching two SKUs, each linked to its own warehouse.
Every box is an object; every line is a relationship recorded at the moment it happened. Zoom out from this small slice and the same pattern repeats across a full shift, a full depot, a full network, the graph just keeps growing in the same way, one linked event at a time.
The result is a model that does not need to guess which entity mattered most. It keeps all of them, and lets the actual pattern of relationships in the data determine what explains what.
Why this matters more than it sounds
The immediate benefit is accuracy: fewer false anomalies, and root causes that point at the actual shared resource instead of a symptom. But the more important shift is in where the rules come from in the first place.
A flattened model, because it can only see one entity at a time, generally has to be told what "correct" looks like, a hardcoded template of the expected process, built by someone who has to guess or assume how work is supposed to flow. An object-centric model, because it retains the full relationship structure of the data, can discover the process as it actually runs, including the legitimate variation that exists across different resources, routes, or teams. That is a materially different starting point: instead of measuring a process against someone's assumption of how it should work, you are measuring it against what the data shows actually happens most of the time, and treating meaningful deviations from that as the signal worth investigating.
That distinction becomes more important, not less, as operations get more automated and more interconnected. The more systems a process touches, a WMS here, a TMS there, a scanner feed, a workforce system, the more entities are genuinely in play at once, and the more a single-case-ID view quietly loses.
None of this is really about process mining as a category, it is about whether the model you are using can see the process the way it actually happens: as a web of shared objects, not a single thread. That is the assumption pAud is built around. If this is a pattern you have run into in your own operations, problems that keep surfacing as many unrelated incidents instead of one shared cause, we would be glad to show you what it looks like against your own data.