Questions process mining can answer
- Which process variants actually occur?
- Where do cases wait, loop or deviate from the intended path?
- Which products, sites, suppliers or order types explain the deviation?
- Are apparent bottlenecks operational or caused by missing and delayed bookings?
Data requirements
A classic event log needs a case identifier, activity and timestamp. Manufacturing and logistics processes often involve several interacting objects such as order, material, handling unit, batch and delivery. Their relationships and the semantic meaning of status changes are clarified before analysis. Time zones, duplicates, cancellations and missing events are tested explicitly.
Approach
- Define the decision and process boundary.
- Identify source systems and create a documented event-data model.
- Validate completeness, chronology and object relationships.
- Discover variants and performance patterns.
- Check conformance against intended rules where a reference model exists.
- Confirm causes with process owners and prioritise measures.
Results and deliverables
- Event-log and data-quality specification
- Process and variant map
- Lead-time, rework and waiting-time analysis
- Conformance and root-cause findings
- Prioritised improvement backlog and measurement concept
The PM² methodology behind the approach
The steps above follow PM², the process mining project methodology published in 2015 by van Eck, Lu, Leemans and van der Aalst. It structures a project into six stages: planning and extraction up front, then a repeated loop of data processing, mining and analysis and evaluation, and finally process improvement and support.
Two properties of the methodology drive that choice. First, it translates project goals into concrete research questions that are refined and answered iteratively; performance and compliance findings follow, and improvement ideas follow from those. Second, the loop is deliberate — an analysis iteration takes anywhere from minutes to days, and the project moves on only once the findings hold. Earlier methodologies aimed instead at a single integrated process model.
Technical basis and limitations
A reliable event log needs at least a meaningful case or object assignment, an activity and a time reference — the three mandatory attributes set out in the Process Mining Manifesto of the IEEE Task Force on Process Mining (2012). Data origin, time zone, status changes, duplicates, missing events and the treatment of parallel work are documented as well. The same document distinguishes the three basic types that determine how a project is scoped: discovery derives a model from the data, conformance compares data against a target model, and enhancement extends an existing model with what the data shows.
A directly-follows graph shows observed adjacency, but it is not a complete process model. Van der Aalst set out why in 2019: the graph cannot represent concurrency and introduces loops that look like rework instead; frequency-based simplification means most traces can no longer be replayed on the graph, and reported times between two activities remain conditional values. DFG-based performance diagnostics alone are therefore not a basis for decisions.
Further reading: data requirements and pitfalls in production and logistics, event logs, conformance checking and object-centric process mining.
Sources: van der Aalst, W. et al. (2012): Process Mining Manifesto, LNBIP 99, pp. 169–194, Springer. — van Eck, M. L.; Lu, X.; Leemans, S. J. J.; van der Aalst, W. M. P. (2015): PM²: A Process Mining Project Methodology, CAiSE 2015, LNCS 9097, pp. 297–313. — van der Aalst, W. M. P. (2019): A practitioner's guide to process mining: Limitations of the directly-follows graph, Procedia Computer Science 164, pp. 321–328.