物品購入申請に「課長起案ルート」を追加。課長の自己承認を省略し、部長決裁へ直接進めることで、手続きの停滞防止とリードタイム短縮を図ります。
1. 課題：課長起案時に発生する自己承認の手間
SakuSaku商事では、物品購入の稟議に「申請 → 課長承認 → 部長決裁」の階層型承認フローを運用していました。この承認フローでは、課長自身が起案者となる案件においても一律で同じルートを通るため、「課長が自分の申請を自分で承認する」という状況が発生していました。
このことは、課長にとっては実質的な意味を持たない無駄な手間となっていました。
2. 解決策：課長用の申請開始ポイントを追加
プロセスオーナーは、課長が申請を開始できる専用の開始ポイントをワークフローに追加しました。
プロセスモデルでは、スイムレーン「課長ロールの誰か」を新設し、そのレーンにヒューマンタスク「課長申請」を配置しました。課長が起案する場合は、この工程から申請を開始します。
「課長申請」から開始された案件は課長承認工程を経由せず、部長決裁へ直接進みます。
Before
ワークフロー図詳細を見る
1. 申請
社員が物品購入の申請を行います。
AI診断
申請内容をAIが診断します。不備や誤記の可能性、課長の承認コメント案・差戻コメント案を提示します。
2. 課長承認
課長が申請内容を確認します。差戻の場合は申請者が修正して再申請します。承認された場合は部長決裁へ進みます。
3. 部長決裁
部長が最終判断を行います。決裁または否決の結果は申請者にメールで通知されます。
After
ワークフロー図詳細を見る
1. 申請
社員が物品購入の申請を行います。
AI診断
申請内容をAIが診断します。不備や誤記の可能性、課長の承認コメント案・差戻コメント案を提示します。
2. 課長承認
課長が申請内容を確認します。差戻の場合は申請者が修正して再申請します。承認された場合は部長決裁へ進みます。
1b. 課長申請
課長自身が起案する場合は、部長決裁へ直接進みます。
3. 部長決裁
部長が最終判断を行います。決裁または否決の結果は申請者にメールで通知されます。
3. 効果
申請処理の待ち時間の削減（スピード）
課長が起案した申請は課長承認工程を経由せずに部長決裁へ進むため、申請から次工程までの待ち時間が発生しません。これにより、申請手続きのリードタイムが短縮されます。
課長の形式的な承認作業を削減（負荷）
課長による自己承認が不要となるため、通知確認や承認操作といった形式的な作業がなくなります。これにより、課長の作業負荷が軽減されます。
申請と承認の役割の明確化（統制）
課長が起案した申請は課長承認工程を通らないため、課長の業務は「部長への申請」と「部下の申請に対する承認」に分かれます。これにより、申請と承認の責任範囲が明確になります。
4. その他の業務への応用
稟議・決裁ワークフロー
起案者の役職と承認者が重複する場合、開始ポイントや分岐ルートを分けることで、不要な承認工程を回避できます。
経費精算
マネージャーが申請者となる場合に、同一人物の承認工程が発生しないよう申請ルートを分けることで、承認フローを整理できます。
プロジェクト申請
プロジェクト責任者が起案する場合も、役割ごとに開始ルートを用意することで、承認構造の重複を避けたプロセス設計が可能です。
