Rework loop

What is a rework loop?

A rework loop is the pattern where the same activity is repeated within one case. An invoice gets created, rejected, adjusted and re-created. A request goes to approval, comes back with comments, gets reworked and has to go through the same approval again.

In lean and Six Sigma, rework has been a classic form of waste for decades: work done over to fix an earlier mistake. In process mining that pattern takes a visual form: repetitions show up on the process map as arrows that curl back to an earlier activity. Those are the rework loops.

How do you spot it in your event log?

If your event log is in order, rework is not hard to detect. You need a case ID, an activity and a timestamp. Within one case ID you count how often the same activity name shows up. Greater than one means you have rework on that step by definition.

Process mining tools make this visual. You see an arrow running from an activity back to itself (a self-loop), or an arrow that jumps back to an earlier activity. Variant analysis separates the heavy cases from the light ones: the lucky cases run through the process once, the unlucky ones sit in a variant that goes through the same approval several times.

The cost of rework

Rework costs on three levels. First there is the direct cost per repetition: every extra approval or correction takes someone's time. Fifteen minutes per extra loop, over thousands of cases a year, is a serious bite out of team capacity.

Then there is the customer side: a longer throughput time. The customer waits longer for their invoice or their answer, and they feel it.

And there is first-time-right: the share of cases handled correctly in one go. The lower that ratio, the more often your team fights fires instead of delivering new work. Rework is work the customer does not see and does not pay for: the cost sits with you.

Typical causes

• Incomplete intake: at the moment a case starts, fields are missing that turn out to matter later. The case has to come back to collect that info.

• Unclear rules: approvers apply different criteria. What one lets through, another sends back.

• Bad master data: outdated customer data, wrong VAT codes, discontinued articles. The process runs correctly on faulty input.

• Hand-offs between teams: what sales considers complete is not finished to finance.

Example: invoicing with VAT corrections

Take a classic invoicing flow in a small business. In the ideal variant an invoice is created from an order, approved and sent.

The event log shows something else. On a slice of cases you see: invoice created, approved, sent, credited, created again, approved again, sent again. The cause sits in a wrong VAT code on a product that only surfaces during the accounting check. Each rework loop costs three extra activities and two working days of throughput. Process mining shows that the problem starts in your master data, not with the invoicing clerk. So you clean up the VAT codes instead of adding extra controls.

Rework versus retry

Rework happens at the process level. A person or a team decides a result is not good enough and repeats one or more business activities. The loop shows up in the event log as repeated activities within the same case.

Retry is technical: an API call fails, a batch job breaks, an integration times out, and the system tries again automatically. Those retries belong in your infrastructure logs, not in your business event log. If they leak into the business log, you will see more rework than there actually is.