Where the Process Starts and Ends
A different boundary produces a different process and a different cycle time. Choosing it deliberately, and stating it with every figure.
Analysis
Two analyses of the same operation will disagree if their boundaries differ, and the disagreement will be attributed to the data.
Why it matters so much
Cycle time is measured between the boundaries. Moving the start earlier makes the process look slower, with no change in reality.
The bottleneck may sit outside a narrow scope, in which case the analysis will find a different one and the improvement will produce nothing.
Waiting frequently concentrates at the handover into the scope, which a narrow boundary hides entirely.
Choosing the start
The customer-visible start — when the request was made — gives the honest cycle time and requires data from wherever the request arrives, frequently email.
The system start — when the record was created — is available and excludes any delay before creation.
The gap between them is often substantial, and it is a finding rather than a nuisance.
Where you can only measure from record creation, say so, and estimate the preceding delay separately.
Choosing the end
Completion of the last activity is easy and may not be the end for the customer.
Payment received, goods delivered, ticket confirmed closed by the requester — each is later and more meaningful.
Cases that never end need a rule: excluded, or counted as open with an age.
The handover boundaries
Where a case crosses into another team or system, the waiting concentrates.
A scope that stops at the handover attributes none of that delay to anyone.
Extending across the handover is where the largest findings usually are, and it is also where the extraction difficulty multiplies.
Sequence it: mine within one boundary first, deliver a finding, then extend across the handover with the credibility that produces.
Sub-processes
A large process is easier as several linked logs than as one.
Mine each with its own boundary, then measure the handover delays between them explicitly.
This is more tractable than an end-to-end log and produces most of the same findings.
Stating it
Every figure carries its boundary. "Median cycle time 14 days, measured from order creation to despatch confirmation, cases completed within the window."
Written into the report, not the covering note.
Unchanged between baseline and follow-up, or the comparison is meaningless.
When someone quotes a different figure, check the boundary first. It is the explanation nine times out of ten.
Measuring the pre-record delay
The invisible waiting before anything is logged, and it is frequently the largest single component.
Take a sample of source requests — emails, forms, calls — with their arrival times.
Match to the records created from them.
Compute the gap.
A manual exercise, done once, on fifty cases.
The result is usually days, and it is the number that makes the honest cycle time far worse than the reported one — which is exactly why it is worth knowing before a customer points it out.
Sub-process logs rather than end to end
The tractable alternative to a merged log across six systems.
Mine each stage with its own boundary, delivering a finding from each.
Then measure the handovers between them explicitly: last event in one, first event in the next, for matched cases.
That handover measure captures most of what the end-to-end log would show, at a fraction of the extraction cost.
Build the merged log only if the handover analysis raises something the separate views cannot explain.
Choosing where the process starts and ends
A decision that changes every number and is frequently made by accident.
Start too late and the waiting before the first recorded event disappears, which is often where the delay is.
End too early and rework after apparent completion is invisible.
Include upstream and downstream events where they exist, even in another system.
State the boundary explicitly with every figure, because a lead time measured from order entry and one measured from approval are not comparable and will be compared.
Test the sensitivity: recompute the headline duration with the boundary moved one event either way. If it changes materially, the boundary is the finding.