Handovers and the Social Network
Who passes work to whom. Each handover adds a queue, and the pattern reveals coordination problems no process map shows.
Analysis
With a resource field, the log describes not only the process but the organisation working it.
What it produces
A handover graph: who performed an activity, and who performed the next one.
Handover counts per case, which correlate strongly with cycle time.
Team-level flow, which is the aggregate view and the one to use.
Bottleneck individuals or roles, which is where care is needed.
The identity decision
Resource data is personal data, and this analysis is where that becomes concrete.
Aggregate to role or team by default. Almost every useful finding survives it: handover counts, cross-team flow, queue formation.
Individual-level analysis needs a stated reason, limited access and a retention period, and it should not be the default view in a tool everyone can open.
This is the same boundary described in the task mining section, and it applies to process mining too whenever the resource field is present.
What the pattern shows
Handover count per case. Cases with more handovers take longer, reliably, and the relationship is usually strong enough to be the whole argument for reducing them.
Ping-pong, where work passes back and forth between two teams. Almost always a definition problem about who owns a decision.
A single point of concentration, where one role touches most cases. An operational risk as well as a bottleneck.
Cross-team loops, which are the most expensive rework because each crossing adds a queue.
Cases handled entirely within one team, which are usually much faster and are worth understanding.
The ping-pong finding
Worth separating because it is common and fixable.
Two teams each believe the other owns a decision.
Cases bounce, sometimes several times, with a queue at each crossing.
Detect it as a repeated transition between the same two resources or teams within a case.
Fix it by naming the decision owner, which is a five-minute decision that nobody has made.
Re-measure the bounce rate, which is a clean before-and-after.
Segmenting
By case type, since some case types require more coordination legitimately.
By period, which shows whether handovers are increasing — usually they are, as processes accrete steps.
By outcome, since cases with many handovers frequently also fail.
What to report
Median handovers per case, trended.
The five most frequent team-to-team transitions, with the median queue at each.
Ping-pong pairs, with case counts.
Concentration: the proportion of cases touching the busiest role.
At team level, always, unless there is a stated reason and a control for going below it.
Detecting ping-pong
A common finding with a five-minute fix, and it is invisible without the resource field.
Look for a repeated transition between the same two resources or teams within one case.
Count cases with two or more crossings of the same pair.
Measure the queue at each crossing, which is where the cost is.
The cause is almost always an ownership ambiguity: each team believes the other decides.
Name the decision owner, which is one meeting, and re-measure the bounce rate.
Handovers against cycle time
The correlation that makes the argument, and it takes one query.
Count handovers per case.
Plot median cycle time by handover count.
The relationship is usually strong and close to linear, which is a more persuasive chart than any process map.
It reframes the improvement question from speeding up steps to removing crossings.
Check the confounder: complex cases legitimately need more handovers. Segment by case type before concluding.
The resource dimension, carefully
Handover analysis needs the resource column, and that column is where individual attribution enters.
At team or role level it answers the question: where work bounces between groups, where it queues at a handover, which pairs exchange most.
At individual level it invites performance comparison, which is a different activity with different obligations and a real cost in cooperation.
Aggregate to role or team at ingestion unless there is a stated reason not to.
Where individual resource is needed for a specific question, treat it under the rules in the task mining section.
Bounce-backs between two groups are usually a specification problem at the handover, not a performance problem in either group.