業務プロセス設計では、作業を細かく並べるだけでなく、担当者、入力情報、受け渡し条件、完了の定義まで決めます。営業が受注見込みを持ち、現場が実行し、人事が採用や配置を支える事業では、部門の境目にある情報が抜けると、納期・品質・採用のすべてに影響します。
最初から高機能なシステムを選ぶより、まずは業務の流れを紙一枚に落とし、どこで判断が止まっているかを見つける方が先です。
業務プロセス設計で決める5つの要素
一つの工程は、次の5項目がそろうと別の担当者へ渡せる状態になります。
- 開始条件:何が起きたら業務を始めるか
- 担当:実行する人と判断する人は誰か
- 入力:作業に必要な情報や資料は何か
- 完了条件:どこまで終われば次へ渡せるか
- 例外:情報不足、期限超過、差し戻しをどう扱うか
「営業が現場へ共有する」「人事が採用を進める」だけでは、入力と完了条件が曖昧です。例えば、案件の開始予定日、必要な役割、想定工数、顧客との約束、候補者を探す期限まで定義しておくと、次の担当者が確認のために何度も聞き返す時間を減らせます。
現状業務を棚卸しする順番
棚卸しは、理想のフローから始めると実態と離れます。直近の案件や採用1件を選び、実際に起きた順番を書き出します。
- 依頼や案件が発生した時点を記録する
- 誰が、どの資料や画面を見て判断したかを確認する
- 担当者が変わった場所と、確認が差し戻された場所に印を付ける
- 待ち時間と実作業時間を分けて記録する
- 本来は不要だった入力・会議・転記を洗い出す
手順書に書かれている流れではなく、担当者のメール、表計算ファイル、チャット、会議で情報がどう動いたかを見ます。同じ内容を複数のファイルへ転記しているなら、業務負荷だけでなく情報の不一致も起きやすい箇所です。
担当・入力・完了条件を一つの表にする
| 工程 | 主担当 | 受け取る情報 | 完了の条件 | 例外時の行き先 |
|---|---|---|---|---|
| 案件情報の登録 | 営業 | 顧客、開始日、役割、見込み度 | 必須項目が入力されている | 営業責任者 |
| 要員依頼 | 現場責任者 | スキル、工数、期間、勤務条件 | 必要枠と優先度が確定している | 案件責任者 |
| 候補確認 | 人事または採用担当 | 経歴、稼働可能日、希望条件 | 候補者が条件を確認している | 配置責任者 |
| 開始準備 | 現場 | 契約、連絡先、初日の作業 | 初日までの準備が完了している | 運営責任者 |
この表は、担当者を固定するためだけのものではありません。情報が足りない依頼を次工程へ流さないための入口として使います。役職名ではなく、実際に判断できる人を主担当に置くのがポイントです。
案件発生から配置までの設計例
案件型の事業では、営業の受注情報と人事の採用情報を同じものとして扱わない方が安全です。営業側は顧客との商談を管理し、配置側は必要な役割と稼働枠を管理します。両者をつなぐ共通項目を、案件ID、役割ID、開始予定日、必要工数に絞ると、情報の責任範囲が明確になります。
確度の低い商談を確定配置として扱うと、候補者や社内人材を先に押さえたのに案件が延期されることがあります。見込み、仮押さえ、確定、延期、失注を状態として分け、状態が変わったときに誰へ通知するかまで定義します。
小さく試して改善する方法
全社の業務を一度に変えるのではなく、1つの案件種別や1つの採用ポジションで試します。試行期間は、完了までの日数、差し戻し件数、入力漏れ、担当者の確認時間を測ります。数字が悪かったときに担当者を責めるのではなく、入力欄が多すぎる、判断権限が不明、例外の行き先がないといった設計上の原因を探します。
業務プロセスが固まった後に、ワークフローや業務アプリ、CRMなどのツールを選びます。ツールを先に導入すると、現場の曖昧な運用が画面に固定されるためです。
まとめ
業務プロセス設計では、工程名よりも、開始条件・担当・入力・完了条件・例外を決めることが大切です。まず実際の案件や採用の流れを棚卸しし、部門間の受け渡しを表にします。小さく試して待ち時間や差し戻しを測り、運用が固まってからツールや連携を検討すると、現場で使える業務設計に近づきます。


コメント