上流工程に差し戻すための矢印経路を接続するケースは少なくありません。しかし "差し戻された案件" と "未着手の案件" が混在すると［マイタスク］や［ヒートマップ］における視認性が下がる可能性があります。案件流量が多く、また差し戻しの発生頻度も高いような工程では、"再入力用の工程" を分離することを検討します。
1. 手戻りパターンについて、概要を理解する
- a. 計画されていない手戻り
- 申請業務において不備がある場合、決裁権限外のタスクがきた場合、など
- b. 計画された手戻り
- 企画業務においてフィードバックを受けて徐々に完成度を高める場合、など
2. 差し戻しが多く発生する工程を整理する
- a. 入力項目が多い工程
- 立替金の申請、休暇の申請、稟議書の申請、など
- b. レビュー要素が高い工程
- 見積書案の作成、取引先から受領した契約書案の登録、など
3. 再入力工程を追加する
- 1. 同じスイムレーン上に配置する
- 差し戻しに対応するための専用工程を追加します
- 2. 矢印経路を接続する
- 差し戻すための経路を追加し "差戻" といった経路名称を付けます
- 単一選択分岐（XOR ゲートウェイ）でも同様の業務の流れを実現できます
- 多くの場合、データ閲覧レベル（読み書き権限）は、初回の "入力工程" と同じ設定になります
- 差し戻しの発生をいち早く検知させるために［メッセージ送信中間イベント（メール）］の配置も検討します
4. 手戻りの発生を減らす工夫を考える
- 1. 発生件数を計測する
- 再入力工程に到達した案件数や、再入力の延べ回数等を集計します
- 2. 発生原因を調査する
- 手戻り件数が多い工程について、その原因を分類します
- 3. カイゼンを行う
- データ入力画面における "入力ヒント" や "業務マニュアル" を改良します
X. ブログ記事
- 2019-06-19: こんなワークフローはイヤだ「差し戻しできない」
コメント
0件のコメント
サインインしてコメントを残してください。