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 that need to be reworked and new Issues are mixed together. Therefore, you should consider separating Steps where reworking is necessary 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!