Processes That Cross Systems
Where the largest findings are and where the extraction difficulty multiplies. How to get there without a year of preparation.
Procedure
Waiting concentrates at system boundaries, which is exactly where the log is hardest to build.
Why the findings are there
Each system boundary is a handover, and each handover carries a queue.
Neither system's own reporting sees the delay, because each measures only its own portion.
So the delay is nobody's number, and it is frequently the largest single component of cycle time.
Why it is hard
Different case identifiers, with no shared key.
Different clocks, producing wrong sequences.
Different time zones.
Different activity vocabularies.
Different retention, so one system's history is shorter than the other's.
Different owners, each requiring a separate access approval.
Finding the join
Look for a link table, which usually exists somewhere and is the best case.
Look for a shared reference carried as a field: an order number in the invoice, a ticket reference in the change record.
Reconstruct by attribute and time as a last resort — same customer, same amount, within a window. This is a probabilistic match and must be labelled as one.
Report the match rate, always. Unmatched cases are themselves a finding about work falling between systems.
The sequencing that works
Do not start here.
Mine each system separately first, with its own boundary, and deliver a finding from each.
Then measure the handover delay specifically: last event in system A to first event in system B, for matched cases.
That single measure frequently justifies the whole cross-system effort and it requires only the join, not a merged log.
Build the full merged log only if the handover analysis shows something the separate views cannot explain.
The clock problem, specifically
Verify offsets directly between every contributing system before computing anything across them.
A drift of minutes produces confidently wrong sequences at the boundary, which is precisely where the interesting events are.
Normalise to one time zone at ingestion, keeping local time separately if working hours matter.
Test for negative handover durations, which should be zero and which reveal the problem immediately.
What to report
Handover delay per boundary, median and ninetieth percentile.
Match rate, and what the unmatched cases have in common.
Cases that cross more than once, which is cross-system ping-pong and the most expensive rework there is.
The proportion of total cycle time spent between systems, which is the headline and is usually larger than either system's own reporting suggests.
The organisational obstacle
Each system has an owner, and the delay belongs to neither.
Which means the finding has no natural recipient and needs a sponsor above both.
Establish that sponsor before starting, because a cross-boundary finding with no owner is the most reliable way to produce a well-received analysis and no change.
Measuring the boundary delay alone
The cheapest cross-system analysis and frequently the largest single finding.
Match cases across the two systems, by whatever key exists.
Take the last event in the first system and the first event in the second.
Compute the gap, median and ninetieth percentile.
Report it as a proportion of total cycle time, which is usually startling.
No merged log required, only the join, which makes this achievable in days rather than months.
Finding the sponsor first
The organisational prerequisite for any cross-boundary finding.
The delay belongs to neither system owner, which means the finding has no natural recipient.
Identify who is accountable for the end-to-end outcome before starting.
If nobody is, that is the finding, and it is more useful than any measurement.
Get their agreement to receive the analysis, in advance.
A cross-boundary finding with no owner is the most reliable way to produce a well-received analysis and no change.
Joining logs across systems
The problem that makes end-to-end analysis hard, and it is mostly identifier reconciliation.
Identifiers change as a case crosses a boundary, and the mapping is rarely recorded anywhere.
Build the crosswalk explicitly, as a table, versioned.
Check clock agreement between systems before computing any cross-boundary duration.
Expect the handover itself to be the finding. Cases waiting at a system boundary is the most common end-to-end result.
Where the crosswalk cannot be built, analyse the segments separately and say so, rather than producing an end-to-end number you cannot support.