Limits on spotting true concurrency from event logs in process data
Resolution limits for process comparison from event data
DatabasesMachine Learning
Summary
Sometimes hospitals run tests at the same time, and sometimes one after another; telling which happened and in what order matters for managing resources. The authors found that usual methods looking only at event sequences can’t reliably tell if tasks really ran concurrently or just sequentially in mixed orders. They show it’s not a matter of collecting more data, but rather about what extra information is recorded, like start and end times or tracking individual objects within processes. This helps managers plan better when services truly happen at the same time versus just in quick succession.
What this means in practice
- •For hospital data teams: Determine when it is impossible to infer true concurrency from logged hospital events, guiding better recording practices for efficient resource planning.
- •For business process analysts: Use timing and object-level data for more accurate models of processes when traditional event logs fail to distinguish concurrent from sequential tasks.
A theory result. No direct application yet.
Authors
Antony R. Lee, Peter Tiňo, Iain B. Styles
Abstract
One hospital runs bloods and imaging at the same time. Another runs them one after the other, in either order, equally often. Knowing which actually happened, and how it is recorded in data, is critical for all operational managers. In process mining, the standard approach is to construct an event log, and attempt to discover concurrent and sequential processes in a data-driven way. We show this standard approach, built on the stochastic language of an event log, reports only the assumptions of its discovery algorithm, because every such log is explained equally well by a model with no concurrency at all. Further, before any data is acquired, we characterise when data can and cannot distinguish concurrent behaviour. Where it cannot, the distinction is recoverable from evidence the stochastic language discards, such as the times at which activities start and end, or object-centric records that fix an order within an execution. The remedy is therefore a choice of what is recorded, rather than a larger sample. This impacts decision making, as planning resource for truly concurrent services is very different from sequential services.