Event logs need defined case or object identities, activity semantics and timestamps before reliable process analysis is possible.
What is an event log?
An event log is a structured collection of operational process events. In classic process mining each event contains at least a case ID, activity and timestamp. Optional attributes include resource, site, material, quantity, cost or system.
Minimum structure
| Field | Business question |
|---|---|
| Case or object | Which instance or business object does the event belong to? |
| Activity | Which business step occurred? |
| Time | When did the step start, end or get posted? |
| Attributes | Which characteristics explain variants or performance? |
Cases and objects
Manufacturing and logistics often connect orders, materials, batches, handling units and deliveries. One case ID can lose relationships or multiply events. Object-centric process mining can preserve those relations.
Quality checks
- stable IDs and complete relevant cases
- timestamp meaning, time zones and resolution
- duplicates, cancellations and technical repeats
- overwritten states and late manual postings
An event log is therefore a documented business data model, not a neutral raw export.
Technical basis
The three mandatory fields — case, activity and time — follow the definition in the Process Mining Manifesto (IEEE Task Force on Process Mining, 2012). It defines the event log as a collection of events used as input for process mining and states explicitly that events need not sit in a dedicated log file: they may be scattered across database tables, message logs and transaction logs. What matters more than the storage format is the quality of the data. The limits of simplified process representations are covered by 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, DOI 10.1016/j.procs.2019.12.189. Further reading: process mining in production and logistics.
Applying Event log in a project
An event log should be tailored to a defined decision, explicit event semantics and a documented observation period.
Before applying Event log, define the objective, system boundary and decision to be supported. The distinction from adjacent methods and systems is equally important: which processes are included, which interfaces remain outside the scope and which metrics indicate an improvement? This prevents a term from becoming a label and avoids local optimisation that creates new problems elsewhere.
A reliable assessment of Event log combines current-state data with documented assumptions. Sources, reference periods, units and exceptions need to be transparent. Alternatives or measures can then be compared using consistent criteria. Depending on the task, these include performance and cost as well as space, inventory, ergonomics, quality, feasibility, risk and expandability.
The output from applying Event log should support a concrete decision or a verifiable next step. Ownership, a target value and a review date make the expected effect measurable. To transfer the concept to a real assignment, it can be combined with the relevant consulting, planning, optimisation and digital capture services.
Event log in practice: Our services overview brings together the relevant planning and consulting approaches.