The Event Log

Everything rests on the event log. Most of the difficulty in this field is in producing a correct one.

The three mandatory columns

Case identifier. What the process instance is: an order, a claim, a patient, an invoice. Every event belongs to exactly one case.

Activity name. What happened, from a controlled vocabulary.

Timestamp. When.

With these three you can discover a process. Without any one of them you cannot.

The columns worth adding

Resource. Who or what performed the activity. Enables handover analysis and, if a person, raises the questions covered in the task mining section.

Start and end timestamps, rather than one. This separates working time from waiting time, which is the single most valuable distinction available.

Case attributes: customer type, value, region, product. These drive every useful comparison.

Event attributes: amount, decision, reason code.

Cost, where available.

The case identifier problem

The hardest design decision and the one that determines what questions you can ask.

Choose the wrong level and the analysis answers nothing. An order-level case cannot show line-item rework; a line-level case cannot show order lead time.

Cases split and merge in real processes. One order becomes three shipments; three orders combine into one invoice. A single case identifier cannot represent both.

Identifiers change as a case moves between systems, and joining them is a mapping exercise.

Decide the level from the question, and expect to build more than one log for a process with several relevant levels.

Activity naming

Too granular and the discovered model is unreadable — hundreds of activities, no visible structure.

Too coarse and the interesting behaviour disappears inside one step.

Inconsistent and the same real action appears as several activities, inflating the variant count for no reason.

Build a controlled vocabulary, map source events onto it, and record the mapping. This is unglamorous and it decides whether the output is usable.

Timestamps

Precision matters. Events recorded only to the day produce ties, and ties make ordering arbitrary.

Clock agreement across systems is essential and frequently absent.

Time zones and daylight saving produce a predictable hour of nonsense twice a year.

Recording time is not event time. A batch job writing yesterday's events at midnight timestamps them all identically, which destroys the sequence.

What to check before analysing

Cases with no start or no end, which are incomplete and distort duration.

Events out of order, which indicates a clock or extraction problem.

Duplicate events.

Cases spanning implausible durations.

The proportion excluded by each check, documented, because it will be questioned.

Building the first log

A sequence that avoids the usual rework.

Write the question down first, because it determines the case level.

Choose the case identifier and confirm it exists on every event you need.

List the source events and map them to a controlled activity vocabulary.

Check timestamp precision and clock agreement across every contributing system.

Extract three months, not three years, for the first pass.

Run the completeness checks and record what each excluded.

Only then discover. Every hour spent here saves a day of disputed findings later.