Object-Centric Process Mining in 2026: What It Shows You, What It Costs, and When to Skip It

By Soren Frederiksen, Founder and CTO, mindzie · Updated August 2026 · 10 min read

The Short Version

Object-centric process mining looks at a process through several related objects at once: a customer, an order, four order lines, two shipments, one invoice. Traditional process mining makes you pick one of those, call it the case, and throw away the rest. OCPM keeps all of them, plus the links between them. So you can finally follow one order across every system and department it touches without losing it halfway.

That is the upside. The cost is that somebody has to build the object model first, and in a real ERP landscape that is a substantial piece of data engineering. If your process has one obvious case ID and not much branching, you will get the same answers faster and cheaper the old way.

Worth it for: order-to-cash, procure-to-pay, manufacturing, claims. Anywhere one order spawns items, deliveries and documents that go their separate ways.
Not worth it for: single-object processes, first-time process mining projects, teams with no data engineering capacity.
The data standard: OCEL 2.0, which added object-to-object relationships, qualifiers, and attributes that change over time.
Where the field actually stands: the research through 2026 keeps landing on the same finding. The theory is settled. Real adoption is still thin, and the blockers are data modelling and tool usability rather than anything conceptual.

What Object-Centric Process Mining Actually Means

Take an order that came in last Tuesday. One customer, four line items. Three of those items get manufactured, the fourth is already sitting in the warehouse. The three that were made ship on one truck, the one from stock goes out on another, and the customer eventually gets a single invoice covering all four.

Count what is involved: customer, order, order line, production order, shipment, invoice. Six object types, each with its own start and end, its own timestamps, its own ways of going wrong.

Now try analysing that with a traditional event log. You have to pick one case ID. Pick the order and item-level detail vanishes. Pick the line item and every order-level event gets copied four times. Neither choice is right, and analysts have been living with that compromise for two decades.

Object-centric process mining is what you get when you stop making the choice. Events link to as many objects as they genuinely touch, and the relationships between objects get stored instead of discarded.

What Sits Inside an Object-Centric Event Log

The format most tools have converged on is OCEL 2.0. It defines six things:

Events. A specific execution of an activity, with a timestamp and attributes.
Objects. A uniquely identifiable instance of a type, like order-123.
Object types and activities. The schema layer describing what kinds of things exist.
Object-to-object relationships. New in 2.0. Two objects can be related even if they never appear in the same event, which is how an invoice connects to a contract it shares no history with.
Attributes that change over time. A credit limit or an order value can move mid-process, and you can see it move.
Qualifiers. Also new in 2.0. These describe the role an object plays in an event, so you can tell the actor apart from the subject.

Those last three do more work than they sound like they do. Without them you have a wider table. With them you have something that can reconstruct how a business actually operates.

The Two Ways Flattening Lies to You

There are two specific distortions that show up whenever multi-object data gets squeezed into a single case. Both have names, and both have been documented since the late 2010s.

Convergence. One event relates to several objects, so it gets duplicated onto all of them. Make the order line your case and a single “order approved” event now appears four times. Event counts inflate. Any cost or duration attached to that approval gets counted four times too. If you are reporting cycle time to a CFO, you are reporting a number that is wrong in a direction you cannot easily estimate.

Divergence. The reverse. Make the order your case and four separate “item picked” events collapse into one sequence with no way to tell which item did what. The model that comes out shows loops and backtracking that never happened. It is an artefact of the flattening rather than a finding about the business, but on screen it looks identical to a real one.

Most experienced analysts have workarounds for both, usually building three or four separate logs and reconciling them by hand in a spreadsheet. It works. It also eats a week every time the question changes.

The Case For It: Watching One Thing Move Through the Whole Company

The best argument for object-centric analysis is not that it produces better looking diagrams. It is that you can pick up a single real thing, a purchase order or a patient or a serial number or a claim, and follow it across every department, system and handoff it goes through without ever losing track of which one it is.

You finally see the gaps between departments

An order moves from sales to credit check to production to logistics to finance. In a case-centric world that is four or five separate analyses, because each system defines its own case. The order arrives at every boundary as a new thing with no memory. Object-centric analysis keeps it as one continuous entity, so “where does this order spend its time” becomes a question you can actually answer.

This matters more than it sounds like it should, because the gaps are where the money goes. Departments usually perform well against their own KPIs. Sales closes fast, credit clears its queue, the warehouse hits its pick rate. Meanwhile the order sat for six days waiting on a confirmation nobody owned, and the invoice could not go out because one of four items was still open. Nobody’s dashboard was red. The cash still arrived late.

Extract once, then ask whatever you want

With traditional logs, most new questions mean a new extraction. With an object-centric log you build the data once and then choose which objects to look through. Order view this week, shipment view next week, same underlying data. For teams who have spent more hours building event logs than analysing them, and that is nearly everyone, this is the benefit that shows up on the project plan rather than in the pitch deck.

Root causes usually live on a different object

Here is a pattern we see constantly. A delivery is late. The cause is not in the delivery. It is a supplier confirmation that came in four days behind schedule, sitting on a different object, in a different system, owned by a different team.

Because OCPM keeps the links between objects, you can walk from symptom to cause. Case-centric analysis can tell you two things correlate. Object-centric analysis can show you how they connect.

Your numbers stop being wrong

Once convergence and divergence are gone at the source, counts, durations and cost allocations get calculated once, against the object they belong to. Rework rates stop being inflated. Throughput stops being an average of averages. In audit and compliance work this alone can pay for the project, because a number you can defend line by line is worth considerably more than a number that is roughly right.

AI needs the relationships, not the sequence

This argument got a lot louder over the past eighteen months. An agent that is supposed to act on a blocked invoice needs to know which order it belongs to, which goods receipt is missing, which customer is affected and how much is exposed. A flat event log cannot tell it any of that. An object model can, because it is essentially a machine-readable map of how the business is wired together. Plenty of companies investing heavily in agentic automation are finding that the thing holding them back is not the model. It is that nothing in their data describes how their own processes connect.

The Case Against It: Complexity Is the Price

None of OCPM’s problems are theoretical. The theory has been solid for years. The problems are practical, and almost all of them come back to data complexity.

This is not a minority view. A systematic literature review of the field found that real-world adoption remains limited despite the promise. An industry study presented at ECIS in 2026, based on interviews with thirteen practitioners, put the barriers in two buckets: object-centric data modelling, and the usability of the tools. Dirk Fahland, one of the people who helped define the field, argues the real obstacle is socio-technical debt rather than difficulty.

1. The object model is the project

A case-centric event log needs three columns. Case ID, activity, timestamp. Done.

An object-centric log needs you to decide which object types exist, which events touch which objects, how objects relate to each other, which qualifiers apply and how attributes shift over time. That is a modelling exercise, and it requires someone who genuinely understands the source systems.

In an SAP or Oracle estate those relationships are spread across hundreds of tables. This is not a two-week extraction. It is a modelling engagement, and if you get it wrong the analysis will be confidently incorrect, which is a good deal worse than having no analysis at all.

2. Storage and compute climb faster than you expect

Object-centric event data does not sit comfortably in a relational database, and it does not fit the algorithms the process mining industry spent twenty years optimising for flat logs. Multi-object discovery, conformance checking and filtering all cost more than their single-case equivalents, and the data volume is larger too, because you are now keeping relationships you used to throw away. Delivering interactive, sub-second exploration over a large object-centric log is a genuinely harder engineering problem, and infrastructure cost follows.

3. Rainbow spaghetti

A traditional spaghetti diagram is hard to read. An object-centric one, with five or six object types overlaid and colour coded, can be worse. The field does not yet have settled visual conventions for reducing a multi-object model down to something an operations manager can act on in a Thursday morning meeting. What analysts often find is that a technically superior model produces a worse conversation. And a model nobody acts on is worth nothing, however accurate it is.

4. The skills are not out there yet

The number of people who can design an object model, read a multi-object process graph and then explain it to a business stakeholder is small, and most process mining training is still built around case-centric thinking. Budget for enablement as a real line item. Teams that skip it usually end up with an expensive model only one person understands, which becomes a problem the moment that person changes jobs.

5. Tool support varies more than the marketing suggests

OCEL 2.0 support across the market in 2026 is uneven. Some platforms handle object-centric discovery and conformance properly. Some ingest object-centric data and then quietly flatten it before the analytics run. Some describe multi-log correlation as object-centric because the word sells. During evaluation, insist on seeing the whole path on your own data: ingestion, discovery, conformance, filtering, visualisation. A curated demo dataset hides exactly the problems you need to find.

6. The organisational cost gets underestimated every time

This is the one that surprises people. A company that already succeeded with case-centric process mining has built tooling, methodology, governance and expertise on top of one assumption: a process is a sequence of events inside a bounded case. OCPM removes that assumption. The switching cost is organisational at least as much as technical, and business cases routinely leave it out entirely.

When You Should Not Use It

Being straight about this is more useful than another list of benefits. OCPM is a specialised instrument, not a general upgrade. Here is roughly how we see it play out.

Your situation	What to do	Why
One clear case notion: a ticket, an application, a single item order	Stay case-centric	There is no convergence or divergence to fix, so OCPM adds cost without adding truth.
This is your first process mining project	Start case-centric, but design the data model with objects in mind	Prove value and build internal literacy before you take on a modelling problem.
No dedicated data engineering capacity	Case-centric, or bring in partner support for the modelling	Modelling against ERP source systems is the single biggest effort in an OCPM project.
The question is narrow: one bottleneck, one team	Targeted case-centric analysis, or task mining	A cross-object model is overhead for a question scoped inside one team.
Hard deadline, results needed in weeks	Case-centric now, object-centric as phase two	OCPM timelines are governed by data modelling, and that is hard to compress.
Stakeholders are new to process mining	Case-centric with simple visuals	Multi-object models are harder to explain, and early credibility depends on being understood.
Order-to-cash, procure-to-pay, manufacturing, claims, patient pathways	Object-centric	Real one-to-many and many-to-many relationships mean flattening destroys information you need.
Feeding AI agents or automated decisions with process context	Object-centric	Agents need relational context, and a flat log cannot supply it.

A rule of thumb that has held up well: if you cannot name two object types whose relationship you genuinely need to analyse, you do not need object-centric process mining yet.

Side by Side

Dimension	Traditional (case-centric)	Object-centric (OCPM)
Unit of analysis	One case ID	Many related objects
Log format	Flat XES or CSV	OCEL 2.0 (JSON, XML, SQLite)
Relationships	Discarded when flattening	Kept, including object to object
Convergence and divergence	Present, worked around by hand	Avoided by design
Data preparation	Low to moderate	High, a modelling exercise
Compute and storage	Modest	Considerably higher
Ease of interpretation	Familiar to business users	Needs trained analysts
Time to first insight	Days to weeks	Weeks to months
Best fit	Single-object, bounded processes	Multi-object ERP and supply chain work

Three Middle Paths That Work

The choice is not really binary, and most companies end up somewhere between the two. Three approaches hold up in practice.

Model objects, analyse cases. Build the data layer so object relationships are preserved and documented, then generate case-centric views out of it. You get today’s speed without painting yourself into a corner, and you avoid the most expensive mistake in this area: a data foundation that has to be rebuilt the day you go object-centric.

Run parallel perspectives. Produce two or three case-centric logs from the same source. Order view, item view, invoice view. This is not real OCPM and it will not fix convergence, but it surfaces many of the same cross-object questions for a fraction of the effort.

Pick one process and go deep. Choose the single process where multi-object complexity is demonstrably costing money and build the object model there. Prove it works, grow the skills, then expand. Every successful OCPM rollout I have seen started this way. The ones that started as a platform initiative mostly stalled.

What to Check When You Are Buying

If you have concluded object-centric analysis is right for you, here is what to test. On your data, not theirs.

Real OCEL 2.0 support, including object-to-object relationships and qualifiers. Being able to load multi-object data is a lower bar than it sounds.
Data preparation tooling. A visual, low-code way to build and reshape object models, because this is where the project time goes.
Connectors that already understand your systems, with object relationships mapped rather than left to you.
Performance at your volume. Benchmark interactive filtering and discovery on a realistic data set.
Visualisation you can present. Can it reduce a multi-object model to something a process owner will act on?
A route back to case-centric views, which you will still need for operational reporting.
Deployment, scripting and API access that match your data residency rules and the analyses nobody anticipated.
Total cost of ownership and training, including the compute this data consumes and the fact that few people currently have these skills.

Where mindzie Fits

Most of the risk in an object-centric project sits upstream of the analysis, in building and maintaining the data model. That is what mindzie’s Data Designer is built for: a low-code environment for creating, reshaping and versioning event logs from your source systems, with Python scripting for the transformations that outgrow a drag and drop interface.

From there, the mindzie platform handles multi-perspective analysis across the objects you have modelled, with an AI copilot for asking questions in plain language and an Automated Action Engine for turning findings into something that actually changes. It runs on-premises, in private cloud or as SaaS, and there is a free desktop edition if you want to try the approach on your own data first. To be blunt, we would rather help you work out that case-centric analysis solves your problem this quarter than sell you a modelling exercise you do not need.

Common Questions

What is object-centric process mining in simple terms?

It is process mining that follows several related things at once, such as an order, its line items, its shipments and its invoice, instead of forcing every event onto a single case. That lets you see how an object really moves through a company, across departments and systems, without losing detail or inventing behaviour that never happened.

How is OCPM different from traditional process mining?

Traditional process mining ties every event to exactly one case ID and flattens multi-object data to make it fit. That causes convergence, where events get duplicated, and divergence, where separate items collapse into false loops. OCPM ties each event to multiple objects and keeps the relationships between them, so counts, durations and process models reflect what actually happened.

What is OCEL 2.0?

OCEL 2.0 is the standard used to store and exchange object-centric event data. It defines events, objects, object types, activities, object-to-object relationships, qualifiers that describe the role an object plays in an event, and attribute values that change over time. It comes in JSON, XML and SQLite representations.

What are the main disadvantages of object-centric process mining?

Data complexity is the big one. Building an accurate object model against ERP source systems takes serious data engineering effort, storage and compute costs go up, multi-object models are harder for business users to read, skilled analysts are scarce, and tool support is uneven. Research through 2026 consistently points to object-centric data modelling and tool usability as the two leading barriers to adoption.

Is object-centric process mining always better?

No. If your process has one clear case notion and little multi-object complexity, traditional process mining will be faster, cheaper and easier for stakeholders to act on, and it will give you the same answers. OCPM earns its cost only where genuine one-to-many or many-to-many relationships mean flattening destroys information you need.

Which processes benefit most from OCPM?

Order-to-cash, procure-to-pay, manufacturing and production planning, insurance and healthcare claims, patient pathways, and supply chain and logistics. All of these involve one entity that creates or connects to many others across multiple systems.

How long does an object-centric process mining project take?

Longer than a case-centric one, and nearly all of the difference sits in data preparation. A focused OCPM project on a single well understood process usually runs in months rather than the weeks a comparable case-centric analysis takes, with object modelling accounting for most of that time.

Do I need OCPM to use AI on my process data?

Not strictly, but it helps a great deal. AI agents and automated decisioning need relational context: which invoice belongs to which order, which goods receipt is missing, which customer is exposed. An object-centric model supplies that context in a form a machine can use. A flattened event log cannot.

Where This Leaves You

Object-centric process mining solves a real problem that has been sitting in plain sight for twenty years. Businesses do not run on isolated cases. They run on objects that create other objects and travel together through the organisation. Being able to follow one of those from first touch to final payment is worth something, and increasingly it is the difference between an AI initiative that has context and one that is guessing.

The honest read on 2026, though, is that OCPM is a specialised tool with a real price, and that price is data complexity. The companies getting value from it have genuine multi-object processes, the engineering capacity to model them, and analysts who can turn a model into a decision somebody actually makes. The ones struggling usually adopted it because it was newer, not because their process demanded it. So start with the process, not the methodology. If you can name the objects and the relationship between them that matters, object-centric analysis will pay for itself. If you cannot, traditional process mining will get you further and faster.

Book a demo and we will talk through whether object-centric analysis fits your process, or download mindzie Desktop free and test it on your own data.

About the Author

Soren Frederiksen is the Founder and CTO of mindzie, where he leads development of the company’s process mining and process intelligence platform. He spends most of his time working directly with enterprise teams on event log design, data modelling, and getting process data into a shape that AI and automation systems can actually use.