Cases where the arrow-path is connected to the upstream process for Reworking are not uncommon. However, there is a possibility that visibility of Tasks might be reduced in [My Tasks] or on the [Heat Map] if "Issues to be reworked" and "New Issues" are mixed together. Therefore, you should consider separating "Steps for Reworking" in a flow with high traffic and the occurrence of Reworkings is high.
1. Overview of Rework of Cases
- a. Unplanned Rework
- For example, when defects are found in the original application, or when a Task is assigned to an operator who does not have the necessary authority, etc.
- b. Planned Rework
- For example, to gradually achieve completion by receiving feedback during planning operations, etc.
2. Organizing the Steps where Reworking Occurs Frequently
- a. Steps with many Input Items
- For example, expense reimbursement claims, request for leave, request for decision-making, etc.
- b. Steps where Reviews are Common
- For example, creating an estimate, registering a draft agreement which was accepted by a business partner, etc.
3. Add a Rework Step
- 1. Place a dedicated Step on the Same Swimlane
- Add a Step which is dedicated to Reworking.
- 2. Connect using an Arrow-path
- Add a path for Reworking and name it. For example, "Rework request".
- You can also make this using an XOR Gateway
- In many cases its data reading level (read-write permission) will have the same settings as the "Input Step"
- Also, consider placing a [Throwing Message Intermediate Event (email) in order to quickly recognize the occurrence of a Rework request
4. Consider Ways to Reduce the Occurrence of Rework
- 1. Measure the Number of Occurrences
- Aggregate the number of Issues which have reached the Rework Step, or the total number of re-inputs, etc.
- 2. Investigate the Cause
- Classify the common cause of Reworkings.
- 3. Improve it
- Improve the Description on the Input screen or "Work Manual".
X. Blog article
- 2019-07-16: I Hate Such a Workflow! – Can’t Send Back!