Object-Centric Process Mining

Most traditional process mining tools assume your process follows a single "case" with a linear sequence of events. But real business processes are rarely that simple.

The Traditional Limitation

Traditional process mining assumes:

• One case ID (e.g., Order ID)
• Events belong to exactly one case
• Linear sequence of activities
• No complex relationships between entities

Problem: This doesn't match reality for many processes.

Before: one thing, one flow

Some processes really are a single thing moving through a single flow. A loan application is the classic case: one application, submitted, checked, reviewed, approved or rejected. Every event belongs to that one application, and a case-based tool describes it perfectly well.

Most operational processes are not like that.

After: Order to Cash

Take the Order to Cash project in the Examples workspace. It has six object types, and they are linked:

• a customer places many sales orders; each order belongs to one customer
• a sales order has one or more sales order items — its lines; each item belongs to one order
• each item names one product, and a product appears on many items
• each delivery and each invoice belongs to one order, and some orders are invoiced more than once

Each object type has its own events. Orders are created, blocked, unblocked and have their delivery date changed. Items are created, confirmed, and have their quantity, price or discount changed. Deliveries are created and goods are issued against them. Invoices are created and cleared.

Why it cannot be flattened into one case

To use a case-based tool you have to pick one of those objects as "the case" and force everything else onto it. Whichever you pick, the data bends.

Pick the sales order as the case. An order with three lines has three Create Sales Order Item events and three Confirm Sales Order Item events in its history. On a case-based map that looks like the same step repeating — rework — when it is really three lines being handled side by side. An order invoiced twice shows Create Invoice twice, and you can no longer tell which clearing belongs to which invoice. This is divergence: one case, many objects of another type, and their events tangled together.

Pick the item as the case. Now every order-level event has to be copied onto every line. A block on a three-line order becomes three blocks; the order's creation is counted three times. Averages and counts over orders are quietly wrong. This is convergence: one event, copied into many cases.

Pick the customer as the case. Every order that customer ever placed runs through the same case, interleaved, and the order flow disappears entirely.

There is no right answer, because the question is wrong. The process is not one thing.

The object-centric solution

Flow Myna keeps the objects and their relations as they are, and lets you choose the viewpoint instead of the data model:

• Multiple object types — Customer, Sales Order, Sales Order Item, Product, Delivery and Invoice, each with its own events and attributes
• Relations kept, not flattened — an order's items, delivery and invoices are linked to it, not copied into it
• A lens, not a case — look at the map through Sales Orders, then switch to Sales Order Items or Invoices; each is the same data from a different object's point of view
• Related events on demand — bring delivery and invoice events onto the order map with Events in Graph when you want the whole order-to-cash story in one picture

Process Mining Fundamentals

This is part of a 4-part introduction to process mining: