Next week, the International Conference on Process Mining will take place. We will be there to present Konekti during the Object-Centric Event Data Symposium. So what’s the symposium about, and why are we there?
The Achilles heel of traditional process mining
Imagine your business process is a Rubik’s cube1. Each little colored cube represents a document or resource in your process, with its respective lifecycle. In the ideal world, you have this whole cube solved somewhere in your data warehouse. However, in the real world, these cubes are scattered around your systems like a child’s Lego throughout the living room. If you want to get a grasp of what the whole cube looks like, you must start picking up the pieces and organizing them.
In traditional process mining we are limited to analyzing one side of the cube at a time. So we have to pick, in advance, which color we want to look at. We do that by selecting the case identifier first, and then prepare our data.
But, if you’re looking at one side of the cube, there’s still five sides that you’re not seeing. And if you’re solving one side (i.e. improving your process), that does not mean that the other sides look better. In fact, often it’s quite the opposite!
So where do we see these processes with multiple perspectives? Let’s see a couple of examples:
- Patient flow in hospitals, which can be analyzed from the angle of the patient, the nurse, doctors, or equipment;
- Purchase-to-pay, where every document can be viewed as a different side of the cube; purchase orders, goods receipts, invoices, and payments.
- Air travel, where we can look at the passenger, the plane, the check-in desk, the departing or arrival airport.
Traditionally, we would start with selecting the perspective – the side of the cube – and then solve it; build the event log from this angle. This has several serious consequences:
- It’s a lot of work; the common rule of thumb is that 80% of a process mining project is spent on data preparation. The fact that you must bring down the multi-dimensional data to a single perspective, is a huge part of this work.
- It makes it inflexible for new use cases; changing the case perspective means changing every part of your code. You’d need separate data preparation pipelines to look at a process from multiple perspectives, resulting in more work and more maintenance.
- Oversimplification; the actual process is more complex than the event log illustrates
Konekti: today’s process mining simplified, prepared for tomorrow
More and more research is done to enable object-centric process mining, which would remove this Achilles heel. However, it requires a whole new approach to transforming your data. Unless you are transforming your data in Konekti. Because in Konekti, you build an object-centric data model, that you can either export as an object-centric data model, or “flatten” to a traditional event log.
This set-up enables:
- Faster data preparation; the data model resembles closely how data is actually stored in the system
- Flexibility to explore a new use case by using another case perspective
- One source of truth for multiple event logs
- Deciding the level of simplification yourself; export the object-centric data model, or flatten it into one or multiple event logs
Curious to see what that looks like? Attend the object-centric process mining symposium at the ICPM, or, if you can’t make it to Rome, reach out!
1 It would be downplaying to compare to a 3x3x3x Rubik’s cube, but let’s say it’s somewhere between the 5x5x5 and the 21x21x21 (https://www.youtube.com/watch?v=CoAeCy1R6Qo)