Timestamps

Every duration, every ordering and every bottleneck finding rests on the timestamps. Their defects are the least visible and most damaging in the field.

Precision

Date only means all events on a day are simultaneous. The order within a day is lost, and so is any duration under a day.

Second precision is adequate for most business processes.

Sub-second matters where automated steps fire in sequence.

Check what you actually have, because a datetime column may hold dates with a zero time.

Ordering when times tie

Events sharing a timestamp have no defined order, and every discovery algorithm will pick one.

Different tools pick differently, which is why two analyses of the same log disagree.

Impose an explicit tie-break: a sequence number if one exists, otherwise a fixed activity priority.

Document it, and report how many events were affected.

Batch timestamps

A nightly job stamps hundreds of events with one time.

The map then shows a process where nothing happens for a day and then everything happens at once, which is an artefact.

Detect it by counting events per second per activity; a spike is a batch.

Handle it by treating the batch time as an upper bound, or by excluding the batched activity from duration analysis and saying so.

Time zones

Multi-site processes mix zones, and a naive comparison produces negative durations.

Daylight saving produces an hour of nonsense twice a year, including apparently backwards events.

Normalise everything to one zone at ingestion, and keep the local time separately if working hours matter.

Check for negative durations as a standing data quality test; they should be zero.

System clock drift

Events from different systems compared on unsynchronised clocks produce wrong sequences.

Verify offsets directly between every contributing system, before any cross-system analysis.

Re-verify periodically, because drift returns and new systems arrive unsynchronised.

Working time against elapsed time

A case that waits over a weekend shows two days of delay that no intervention could remove.

Compute both where the process runs in business hours: elapsed for the customer view, working time for the improvement view.

Requires a calendar including holidays and site-specific hours.

Report which you used, because the two figures differ substantially and the difference will otherwise be read as an error.

The standing tests

Run these on every log, every refresh.

Negative durations: should be zero.

Events per second: spikes indicate batching.

Timestamps at exactly midnight: indicates date-only data.

Durations equal to a shift or a day: indicates a default rather than a measurement.

Cases with all events at one time: indicates a migration or a bulk load.

The five standing tests

Run on every log and every refresh, before any conclusion.

Negative durations: should be exactly zero.

Events per second per activity: spikes indicate batching.

Timestamps at exactly midnight: indicates date-only precision.

Durations equal to a shift or a day: indicates a default rather than a measurement.

Cases with all events at one instant: indicates a migration or a bulk load.

Automate them and report the results on the same page as the findings, so figures are read with the right confidence.

Working time calendars

Necessary wherever the process runs in business hours, and usually absent.

Elapsed time includes nights, weekends and holidays, which no intervention removes.

Working time is what the operation can influence, and it is what improvement targets should use.

Build the calendar per site, including local holidays, which multi-site processes require.

Report both figures, because the customer experiences elapsed time and the operation controls working time.

State which one every target refers to, or the target is either unreachable or trivially met.

The batch write problem

A specific defect that silently destroys sequence and looks like a genuine finding.

A nightly job writes the day's events at midnight, timestamping them identically.

Every case in that batch appears to complete instantaneously, or in an arbitrary order determined by row insertion.

Detect it by counting events sharing an exact timestamp. Large clusters at round times are the signature.

Look for the real event time in another column, which frequently exists and is not the one the extraction picked.

Where it does not exist, exclude the affected activities from any duration analysis and say so, rather than reporting durations you know are wrong.