Desktop Client: How can I show rework in a Lean VSM?

In thinking about how to handle rework, keep in mind that the main goal of VSM is to expose and visualize waste, and have a language and analysis method to eliminate that waste in the value stream. So as long as we keep in mind the goal of communicating wasted effort and eliminating it, vs. precise data analysis, there are 2 broad methods one might use:

1. Show impacts of causing a prior step to have to do more work due to quality issues. For example, use Defect% to show work that has to be done again (completely, taking the same time as the first effort), or at least show a 'loop-back' arrow to indicate back-flow.
2. Show impacts of a following additional step that exists simply because data must be reworked. Thus use a separate step and forward flow to show additional effort for the defective product (though this is harder to show data impacts).

Neither method is perfect, particularly for service VSM, but either may effectively communicate NVA effort, depending upon your goals and how you use a VSM diagram. The two methods broadly break down into the following ways to show rework in a VSM:

Method 1: Use Prior Steps to Show Impacts

1. Use the Defect% field to show repeated/duplicated effort on defective product. While the iGrafx documentation defines the defect % as “The percentage of flawed products discarded at a step”, it also notes that it is used to “calculate Timeline data type Rolled Throughput Yield.” When tracking Rolled Throughput Yield (RTY), you are effectively counting each time you’ve had a defect, whether you rework the product or simply scrap it. So you effectively indicate with Defect% how much percentage of work you have to do over again because what you created at the step was incorrect. So not only can you track rework as a Defect%, but you can also get RTY calculation from it. The primary issue with using Defect% is that it assumes you have to do the entire step over again to produce a good product, and that may not be the case for some (or even most) service rework. However, again, the point of the VSM is to expose waste and eliminate it, not necessarily to be precise with measurements. So simply using the Defect% field on the step where the rework occurs can show worst-case impact to productivity due to rework.
2. Show rework flow in the material flow to expose the problem, e.g. by using a loop-back arrow (a semi-circle arrow, available on the toolbox toolbar) and information box to show what % of the work must be sent back for rework. You may then either use Defect% on the prior step to show data impacts (e.g. method "A" above), or not show data impact at all if you're not comfortable using the Defect% field.

Method 2: Use following separate steps explicitly for rework

1. Show rework as forward material flow into a new box. Assuming the rework is not a complete re-do of some step (e.g. in a service process, the product is information, and it takes less time to fill in the holes in the information than it does to get the information in the first place), then the new box would then have the time it takes to correct the data and send it on. The problem with this method is that it’s not easy to show how much of the product is defective and thus reworked, and will thus not show resource, bottleneck, or time impacts quite as well. You can annotate the diagram with percentage of work that goes to the separate box, but this won't affect the timeline and other data.
2. Show which resources are involved in the separate rework step, either by use of swimlanes in your VSM, or simply through use of a resource or swimlane name in the data box itself. We hope this helps you think about how you might show rework in your Lean VSM diagrams.