Rework: the invisible cost that real execution lets you measure

A process can meet its outcome and still destroy value.

It can close the case, answer the request or deliver the service — but only after several returns, corrections and repeated activities. The final result shows as met; the additional cost stays hidden inside the operation.

That repeated work is rework. It is not merely an inefficiency: it consumes capacity that could serve new cases, prolongs response times, raises operating cost and erodes the experience of customers, citizens and staff.

Most organizations know they have rework. Many can describe where they believe it happens. Few can answer three basic questions with evidence:

1. How many cases have to go back?
2. In which activity does the correction originate?
3. How much time and capacity does it consume?

The difficulty is rarely a lack of interest. It lies in the instrument used to measure it.

The process people remember is not always the process that ran

Workshops, interviews and surveys are useful for understanding the purpose of a process, forming hypotheses and gathering the knowledge of the people who operate it. The problem appears when they become the only source for measuring rework.

An interview reconstructs what people remember. Execution records what actually happened.

The difference matters for three reasons:

• Nobody observes the full cycle alone. Rework tends to appear in the white space between departments. Whoever returns a file may not know how many times it will come back; whoever receives the correction may not know where the error began.
• People describe the expected path more easily. When explaining a process, it is natural to reconstruct the correct sequence. Going back is remembered as an exception, even when it is a routine part of the operation.
• An estimate without a source cannot be governed. An approximate figure from a workshop can guide an investigation, but it does not let you reconstruct the cases behind it, repeat the calculation or show that a redesign produced an improvement.

The workshop helps frame the question. The execution record makes it possible to answer it.

The four traces of rework

When a process runs on an engine, deviations leave evidence. You do not have to start by asking how much rework exists. The investigation can begin by looking for its traces.

1. Transitions that return to an earlier stage

A file moves from review back to intake, from approval back to analysis, or from validation back to capture.

Some returns are legitimate and should be designed as a governed exception. Others reveal incomplete information, late controls or decisions placed too far along the process.

The difference is not simply that the case goes back. It is whether that path was designed, under which condition it is allowed and what outcome it must produce.

2. Activities repeated within the same case

When an activity appears two or more times in the history of an instance, there is a direct signal of possible rework.

Repetition can be valid — a periodic verification, for instance. But if the activity repeats to correct a datum, redo a document or fix a decision, the process is paying again for work it had already done.

3. Reopened cases or requests filed again

A reopening indicates that the closure did not fully resolve the need. A new filing of the same matter shows that the rework has already crossed the organization’s boundary and reached the customer or the citizen.

At that point the cost is no longer only internal. It also shows up as more effort for the user, repeated contacts, lost trust and pressure on the service channels.

4. Time stalled waiting for a correction

Not all rework is represented by a repeated activity. Sometimes the case sits still while someone completes a datum, corrects a document or obtains an approval that should have been secured earlier.

That time can be mistaken for normal waiting. But when it is tied to a return, it is a design signal: the process moved forward without a condition it needed in order to continue.

From an impression to a governable indicator

There is no single universal rework metric. The definition has to fit the process and distinguish legitimate returns from avoidable failures.

Three indicators offer a useful starting point.

Rework rate

The percentage of closed instances that had at least one unplanned return, one activity repeated for correction, or one reopening.

Rework rate = cases with rework / total cases closed in the period

The definition of the numerator must be explicit. If different departments interpret differently what counts as rework, the indicator will not be comparable.

Rework effort

The working time invested in repeated activities or corrections within the same case.

It should not be confused with total elapsed time. A case can sit stalled for three days yet require only two hours of additional work. Both measures matter, but they answer different questions:

• elapsed time explains the effect on the service;
• working time approximates the capacity consumed.

Estimated cost of rework

The additional effort can be turned into an economic estimate when the organization has rates or costs per resource, role or activity.

Estimated cost = additional effort × applicable resource cost

It is wise to present the result as an estimate and state its assumptions. The aim is not an artificially precise figure, but to make visible the capacity the organization consumes without generating new value.

The figure needs context

An overall rate can be useful to the executive committee, but it does not say what to redesign.

To support decisions, the indicator must break down along dimensions such as:

• process and version;
• activity or transition;
• responsible department;
• request type;
• intake channel;
• product or service;
• recorded cause;
• customer, segment or territory;
• period;
• final outcome.

This breakdown distinguishes different problems. The same percentage can stem from incomplete forms, ambiguous rules, failed integrations, late validations or decisions that depend on information that is not available.

Without that context, the indicator describes the problem. With it, it guides the intervention.

What Dexon BPM records, and where each trace shows

In Dexon BPM, the execution history is kept as part of the case. The process does not have to be reconstructed only from interviews after the fact.

Every case keeps:

• the activities each instance went through;
• the statuses it passed through;
• the recorded dates and times;
• who performed each activity;
• the data used and modified;
• the returns the design provides for;
• the closures and reopenings that are part of the process;
• the reasons or categories captured during the operation.

On that evidence, the platform already ships the pieces to follow each trace and compute each indicator:

• What ran against what was designed. Each process sheet in Dexon Architect shows the transitions the design does not provide for, the designed paths nobody takes, the most frequent paths with the load on each, and the real duration of every activity against the expected one. Unplanned returns and repeated activities appear there, counted: the first and second traces.
• Time in each status. The time each case spent in each status is a report column, and measured work is recorded separately from elapsed time. That is exactly the distinction between rework effort and stalled time: the fourth trace, with both of its measures.
• The facts of every closure. Each closure leaves on the case who closed it and how, whether the solution was documented, its age, service-level compliance, reopenings, and whether the requester had to file again. Reopening a closed case requires a reason and leaves its history, and factory reports follow the reopened cases, those closed without a documented solution and the repeat filings: the third trace, with its recorded cause.
• A sample you can repeat. A report can return a deterministic sample of its result, the same for the whole month, to audit closure quality on the same cases and compare next month with the same definition.
• Cost, by activity and by technician. The observed cost of the process is computed from measured work and the rates of each role or resource, aggregated by design activity and by technician. The estimated cost of rework stops being a workshop guess.

Reports and indicators turn this data into repeatable measures that break down by process, activity, department, category, channel or period, with drill-down to the case behind them. The concrete definition of the indicator still depends on the model and on the data the organization has decided to record.

Dexon Architect also provides the other half of the problem: it relates the process to its objective, the capabilities it orchestrates, the service it delivers, the risks that condition it and the indicators that verify its outcome.

That relationship matters because reducing rework is not simply about removing loops. Some of them protect the process against a risk or guarantee a necessary review. The improvement lies in distinguishing the controls that add value from the corrections that compensate for an incomplete design.

From the indicator to the executive decision

For senior management, rework should not be presented only as an efficiency metric.

Its impact reaches several decisions:

• Capacity: how much additional volume could be absorbed without adding headcount if repeated work were reduced.
• Service: what part of the response time comes from avoidable waits and corrections.
• Quality: how many cases reach the expected outcome without a return or a reopening.
• Experience: how much additional effort is shifted to the customer or citizen.
• Risk: which returns correspond to necessary controls and which reveal design failures.
• Investment: where an improvement to a form, a rule, an integration or master data would have the greatest economic effect.

The value of the indicator is not in producing a percentage for the dashboard. It is in letting the organization decide where to intervene first.

Rework usually starts before it becomes visible

The return shows up in one activity, but its cause usually lies upstream.

It can originate in:

• a datum requested too late;
• a field that was not validated when captured;
• a document that was not required in the right status;
• a rule that different departments interpret differently;
• a decision made without enough information;
• an integration that carried incomplete data;
• a closure that did not verify the expected outcome.

That is why an effective redesign is usually less spectacular than automating the existing rework.

It may consist of validating the datum when it enters, making it mandatory by state, bringing a decision forward, or preventing the case from advancing without the necessary evidence.

Before the change goes live, it can be tested. Dexon BPM’s simulation runs Monte Carlo scenarios on the measured durations and the real frequency of each branch, and compares the current process with the redesigned one by median and worst case. The question “how much do we gain if this return disappears?” is answered with your own execution, not with an assumption.

And after the change, the organization can recompute the indicator with the same definition and the same source.

That is the principle of evidence-based continuous improvement: redesign with operational data and verify the result on the next round of execution.

Five questions for your next diagnosis

1. Does the figure come from an estimate or from identifiable cases?
   If you cannot get from the indicator to the instances behind it, the measure is not auditable.

2. Does the organization distinguish a legitimate return from an avoidable correction?
   Removing necessary controls can artificially lower the indicator and raise the risk.

3. Can you identify where the rework begins?
   The activity that receives the return is not always where the failure occurred.

4. Does the indicator also show the economic and service effect?
   The percentage should be complemented with effort, elapsed time, reopenings and estimated cost.

5. Can the measurement be repeated without another workshop?
   If every measurement requires reconstructing the process through interviews again, the organization does not yet have a continuous-improvement system.

The first step is not to set an arbitrary reduction target. It is to pick a critical process, define what counts as rework and rebuild the measure directly from execution.

At Dexon we can show, on one of your processes, what evidence each case leaves behind and how to turn it into a verifiable indicator to guide the redesign.

← All articles