Rework and Loops
Cases that go backwards. Invisible in aggregate reporting, substantial in the log, and always caused upstream of where they surface.
Analysis
A loop in the discovered map means work was done twice. It is one of the few findings that is unambiguous.
Finding it
Any activity occurring more than once in a case is a repeat.
Any transition that moves backwards in the intended sequence is a loop.
Count cases containing at least one loop, which is the headline figure.
Count total repeated activities, which is the effort.
Both are usually higher than the operation believes, because rework is handled locally and never aggregated.
The types
Correction loops: something was wrong and had to be redone. The most common and the most addressable.
Approval loops: rejected and resubmitted, sometimes repeatedly.
Clarification loops: back to the requester for information.
Escalation and return, where a case goes up a level and comes back.
System loops, where a technical failure caused a retry. Frequently mistaken for business rework and worth separating.
Where the cause is
Never where the loop appears.
A rejected approval was caused at submission, by missing information or a wrong value.
A correction loop was caused by whatever created the error, which may be several steps earlier or in another team.
Trace the loop cases back to their origin and look at what those cases have in common at the earlier step.
Sizing it
Cases affected, as a proportion.
Additional cycle time, median difference between looped and clean cases. This is usually the largest single number in the whole analysis.
Additional touches, which is the effort cost.
Downstream effect, since a looped case frequently misses a cut-off and cascades.
Present the cycle time difference first. "Cases with a rejection take 19 days against 6" lands harder than a percentage.
The reason codes
Where rejections carry a reason code, aggregate it. This is the closest the log comes to telling you why.
Where the codes are unusable — one dominant catch-all — that is a finding, and rewriting them with the people who select them takes an hour.
Where no code exists, ask for one. A single field on rejection converts a mystery into a distribution.
Preventing it
Fix the input. Most correction loops are caused by information that was missing or wrong at the start, and a validation at entry removes them.
Move the check upstream, so failure is detected before effort is spent.
Give the submitter the criteria, since approval rejections frequently reflect criteria nobody published.
Then measure the loop rate again, which is one of the cleanest before-and-after comparisons available in this field.
The predictable rework subset
The strongest finding type available, because it prevents rather than handles.
Compare cases that reworked against cases that did not, on their attributes at the start.
Look for an attribute combination that predicts the loop: a customer type, a value band, a product, a channel, a missing field.
Quantify: what proportion of that subset reworks, against the base rate.
Where the difference is large, route that subset differently at the start — an extra check, a different team, a request for the missing information up front.
Re-measure the loop rate for that subset, which is one of the cleanest before-and-after comparisons in the field.
System retries against business rework
Two things that look identical in the log and mean nothing alike.
A technical failure and retry produces a repeated activity with a very short gap.
Business rework has a human gap: hours or days.
Separate them by the duration of the repeat, which is usually a clean split.
Report them separately. A high system retry rate is an integration finding for IT; a high business rework rate is a process finding for the operation.
Conflating them produces a rework figure nobody owns, which is why neither gets addressed.
Distinguishing rework from iteration
A case returning to an earlier activity is not automatically waste.
Genuine rework: the step is repeated because it was done wrong or with missing information.
Designed iteration: the process intends repetition, as in negotiation or review cycles.
Data correction, which is rework caused upstream.
Escalation, where a case legitimately returns for a higher-level decision.
Separate them before costing anything, because presenting designed iteration as waste discredits the whole analysis.
Ask the process owner which loops are intended, which takes one conversation and prevents the most common credibility failure.