I’ve been thinking about something lately. We spend a lot of time connecting machines and collecting data from the shop floor — tags, sensors, OPC UA servers, the whole IIoT stack. And then there’s this other world called process mining, where tools like Celonis analyze ERP and MES logs to show you how your processes actually run versus how they’re supposed to.
But what happens when you connect those two worlds?
The Gap I Keep Seeing
Most process mining projects I’ve seen work great for business processes like order-to-cash or procure-to-pay. They pull data from ERP systems and generate beautiful Sankey diagrams that reveal how work truly flows.
But here’s the catch: by the time a transaction reaches your ERP or MES, the real story on the shop floor has already happened.
You might see a work order that took six hours when it should’ve taken two. Process mining will show you that. What it won’t show you is why — that the machine waited 45 minutes for material, stopped 30 minutes due to a sensor failure, and then needed manual overrides because the recipe wouldn’t load correctly.
That kind of detail lives in your IIoT data. And in most companies, those two data streams — transactional and operational — exist in parallel but never really meet.
What I Explored a Few Years Back
Around 2020, I was part of a team working on rapid deployment packages for manufacturing. One idea we discussed was combining process mining with quality and manufacturing execution data.
The concept was simple: feed your MES/OEE data — equipment states, downtime events, quality checks, material movements — into the same process mining engine that’s already analyzing ERP transactions.
We didn’t build the full solution, but the discussions were promising. The goal was end-to-end visibility: not just “this work order is late,” but “this work order is late because Line 3 starved for material at 2:47 PM, which happened because the upstream buffer ran empty, which happened because…”
You get the picture — moving from symptoms to root causes.
A Few Use Cases Worth Exploring
1. Downtime root cause that actually makes sense
If you ask most plants why Line 5 had four hours of downtime last week, you’ll likely get a list of codes: “Mechanical failure.” “Changeover.” “No operator.”
But what if process mining could correlate those entries with real data? Pull in SCADA alarms, MES material records, maintenance logs, and batch steps. Suddenly, “mechanical failure” becomes “bearing temperature spiked 20 minutes before the stop, maintenance was called but arrived 30 minutes later because they were finishing another job.”
That’s actionable insight.
2. Material flow bottlenecks
In one facility I worked with, some lines kept starving for material even though the warehouse showed everything in stock. ERP transactions showed that picking and staging were on time. But shop floor data — conveyors, AGVs, manual scan points — revealed that materials sat in staging for an average of 18 minutes because there was no trigger to move them forward.
ERP said “staged”. The line said “waiting”. If process mining had access to both, it could’ve exposed that hidden gap.
3. Quality escapes and process deviations
This one’s huge in food & beverage. When a batch fails or a complaint appears, you trace back through MES and ERP to find the root cause. But you won’t see that the mixer speed dipped below spec for 90 seconds at 3:15 AM, or that the temperature probe had intermittent connectivity issues all week.
Bringing historian data into process mining could shrink investigations from days to hours.
4. Energy and sustainability
Here’s a forward-looking one. Your IIoT system already tracks energy meter data. Your ERP and MES know which products you’re making and when.
Process mining could identify which process variants consume the most energy — helping you optimize production schedules, minimize your carbon footprint, or align with renewable energy windows.
It’s not common yet, but it’s coming.
The Technical Reality
So how do you actually make this happen?
Option 1: Push IIoT events into your process mining data model
Most process mining tools expect a log with a few key fields: case ID, activity, timestamp, and attributes. You could transform your IIoT events into that format. For example:
- Case ID: Work Order or Batch ID
- Activity: “Equipment Started,” “Alarm Raised,” “Material Loaded”
- Timestamp: From SCADA or historian
- Attributes: Line, Product, Operator, etc.
This transformation could happen in your data lake or middleware. Just be selective — not every tag change, only meaningful state transitions.
Option 2: Use the Unified Namespace (UNS) as the integration layer
If you’re building an event-driven architecture with a UNS (using MQTT/Sparkplug B), your process mining tool could subscribe to specific topics. Whenever a key event occurs — a downtime, a quality check, a material move — it’s published to the UNS and picked up in real time.
This is cleaner and event-driven, but few process mining tools currently support that kind of integration.
Option 3: Use the historian and data lake as the bridge
This is the most practical route today. IIoT data flows into your historian or cloud twin, and then into your enterprise data lake (Snowflake, Databricks, etc.). ERP and MES data are already there, so process mining tools can run analysis across all sources.
The downside is batch processing and slight delays — but at least all the data lives in one place.
My Honest Take
The intersection of process mining and IIoT is still largely untapped. Most companies are focused on foundational tasks — connecting equipment, stabilizing data pipelines, and building dashboards. Meanwhile, process mining often sits in IT or business transformation teams, far from the shop floor.
But those who connect these two domains will gain a real competitive edge. They’ll move from “we have data” to “we understand what’s happening — and why.”
The main challenge is collaboration. OT teams know the shop floor. IT teams manage the data platforms. Business process teams understand workflows. Yet they rarely work together.
If you’re exploring this, start small. Pick one meaningful process — maybe order fulfillment on a single line, quality investigations, or downtime analysis. Get both your IIoT and transactional data in one place. Run a simple process mining test. Show the value. Then scale from there.
Anyway, that’s what I’ve been thinking about. If you’ve tried something like this or have your own ideas, I’d love to hear them.
Leave a Comment