Process Mining on the Factory Floor

Manufacturing teams tend to have good data. Production orders in an ERP. Lab results in a QMS. Dispatch records in a WMS. What they seldom have is a single, time-ordered view of how a batch actually moved through the facility — from component parts being issued to the line, through production, into testing, and out to dispatch.

That gap between having data and having an end-to-end process view is where a lot of operational insight gets lost. And it's where process mining tends to quickly earn its place.

This article is about a project I worked on in a large manufacturing environment running batch production with a multi-stage parallel testing process. The finding was, in retrospect, simple. Getting there required joining up data sources that had never been connected before.

The Process We Were Looking At

The production process had a clear flow: goods issue to line, production start, production end, testing, batch release, dispatch. Testing was where the process got a bit more complex. Rather than a single sequential test, the process involved four independent tests that could run in parallel, but in a lab with equipment and personnel constraints. Each test needed to be completed before the batch could be released for dispatch. The total time to clear testing was therefore determined not by the average of the four, but by whichever finished last.

The event data came from two systems: SAP for production orders, and QCLIMS (Quality Control Laboratory Information Management System) for the testing workflow. Neither system on its own gave you a view of the full process. So joining the data into a single event log using a common batch identifier and timestamps from both systems was the foundational step that made the end-to-end process visible.

The discovered process map showed all four tests running in parallel, each with their own sequential steps and each converging on batch release. Overlaid on the map was the distribution of waiting times at each transition: most importantly the waiting time before each test was started, and the waiting time between each test being completed and the batch release being triggered.

What the Data Showed

The finding came from looking at aggregate patterns rather than individual batches. On any given batch, the order in which the tests started varied, and so did how long each took.

Because all four tests had to be completed before a batch could be released, the release time was determined by whichever finished last. And across hundreds of batches, one test was consistently starting last and finishing last.

The data couldn't tell us exactly why this test was consistently the last to start and the last to finish. But it was clear that the test wasn't just slow. Because it was also the last to start on aggregate, there was clearly room to optimise the lab's scheduling of tests.

The lab team of course knew that batch release depended on them completing their tests. But the impact of how they scheduled that work on overall release times had never been made explicit. The connection existed, but it was invisible.

Once process mining had made this connection both visible and measurable, the conversation could move from the general to the specific: not just “the lab affects dispatch” but “here is exactly where, and by how much.” The conversation was focused and evidence-based.

The Same Process View, Used Twice

The same process view that surfaced the bottleneck became the measurement tool for the change. Once scheduling changes were made, the process map updated and you could directly see the overall batch release time improve.

No need to rely on additional reporting or people's accounts of whether changes in the lab had positively impacted batch release times or not.

Final Thought

This is the kind of insight that feels obvious in retrospect, but genuinely isn't without aggregated metrics overlaid on an end-to-end process map. When we showed the output to a VP, they assumed this was a technology demo with fabricated data for story telling purposes. They simply weren't used to seeing their own data mapped in this way.

When your testing process lives entirely inside a QMS and your production process lives entirely inside an ERP, and nobody has ever joined them together in a time-ordered process view, there is no natural place for these kinds of observations to surface.

The data exists. The connection between test scheduling and dispatch time exists. But it doesn't become visible until the data is structured as a process.

For another practical example of process mining in action, see Process Mining in Practice. For a deeper look at why process views reveal what traditional analytics miss, see The Hidden Story in Your Data.