業務プロセス改善
自動化の対象を決める前に、業務の開始・完了条件、情報の受け渡し、判断、例外を現場の人と一緒に整理しましょう。ここでは、フロー図に何を記録し、改善手段と小規模検証をどう選ぶかを順に解説します。
業務フローの可視化は、作業をきれいな図にすることが目的ではありません。実際の仕事がどこから始まり、誰が何を受け取り、どの条件で判断し、どう完了するかを共有し、改善の選択肢を現実的に比べるための土台です。手順書に書かれた標準の流れだけでなく、待ち時間、二重入力、差し戻し、担当者の経験に頼る場面も含めて記録します。
とくに自動化を検討するときは、「通常の処理ができるか」だけでなく、「うまく処理できないときにどう止まり、誰へ渡るか」が重要です。現場への聞き取りと実際の記録を合わせ、判断根拠や例外の扱いまで見える形にしましょう。
フローを描き始める前に、まず「何が起きたらこの業務が始まるのか」と「何をもって完了とするのか」を関係者間でそろえます。同じ「請求書処理」でも、受信箱に届いた時点から数えるのか、内容確認を始めた時点からなのかで、見える待ち時間や責任範囲は変わります。
開始条件は、依頼・書類・データが届く場所と、処理を始める条件で具体化します。完了条件も「担当者が作業した」ではなく、たとえば承認が終わり、必要なシステムに登録され、依頼元へ結果が戻った状態など、確認できる状態として定義します。
次に、対象に含める工程と、別の業務として扱う工程の境界を決めます。対象範囲が曖昧なままでは、前工程の入力待ちや後工程の再確認が抜け、改善案の評価も揃いません。複数の部署が関わる場合は、引き継ぎの前後を含めるかどうかも合意しておきます。
作業名だけを順番に並べても、なぜ時間がかかるのか、どこで情報が欠けるのかは見えにくいものです。各工程に「担当者」「使うシステムや帳票」「受け取る情報」「次に渡す相手」を添え、同じ図または記録表で追えるようにします。部門や役割ごとにレーンを分けると、受け渡しや確認待ちが見つけやすくなります。
特に、同じ情報を別の画面へ入力し直している箇所、別の担当者が同じ項目を再確認している箇所、承認依頼を出してから返事を待つ箇所に注目してください。作業時間だけでなく、待ち時間、差し戻し、二重入力がどこで発生するかも記録します。
下図は請求書業務を題材にした一般的な整理例です。各工程の上に記載した番号は読み順であり、標準手順や特定の組織の実績を示すものではありません。担当部署、利用ツール、承認条件は現場への聞き取りで置き換えてください。
メールや共有場所に届く。対象書類と受付条件を確認する。
必要項目を取り出し、発注・取引先情報と照合する。
不一致や判断が必要な書類を担当者へ渡す。
確認後に会計システムへ登録し、完了状態を記録する。
例外の分岐も同じ図に残す
金額や取引先が一致しない、必要情報がない、至急の判断が必要、といった場合は自動処理を止め、誰が何を確認してどこへ戻すかを記録します。
図に書ききれない条件は、工程ごとの補足として残します。たとえば「金額が一定以上なら別の承認者へ回す」「添付書類が欠けていれば依頼元へ確認する」といった条件です。条件と処理結果が記録されていれば、後から担当者が変わっても、どの場面で判断が必要かを検討できます。
通常どおり進む案件だけでフローを作ると、自動化後に例外対応だけが現場へ集中することがあります。情報不足、内容の不一致、重複、急ぎ案件、担当者不在など、実際に起きたケースを担当者に思い出してもらい、何が起きたか、誰が気づいたか、どう解決したかを一件ずつ記録しましょう。
聞き取りでは「例外はありますか」と尋ねるだけでなく、「差し戻した直近のケースは何が原因でしたか」「判断に迷ったとき、何を見て誰に相談しますか」「手順書にないけれど毎回行っている確認はありますか」と具体的な場面を尋ねます。経験に基づく判断を、すぐに自動化すべきルールと決めつけず、必要な情報や判断根拠を確認します。
例外ごとに、発生頻度だけでなく処理が止まった場合の影響、誤って通過した場合の影響、解決に必要な役割も整理します。頻度が低くても影響が大きいケースは、担当者への確実な引き継ぎや、処理を止める条件を優先して設計する必要があります。
不足項目を明示し、依頼元へ確認。補完後にどの工程へ戻すかを決める。
自動で確定せず、照合根拠と確認担当者を示して保留にする。
通常の順番を変える条件と、優先判断できる担当者を明らかにする。
フローの各工程を、すべてAIに置き換える必要はありません。処理の性質と誤りの影響に合わせて、AI、定型ルール、システム連携、手作業を比較します。シンプルな条件分岐で確実に処理できる工程には、ルールや既存機能の設定のほうが扱いやすい場合があります。
条件が明確で、結果が一意に決まる処理に向きます。例：必須項目の有無を確認し、不足を知らせる。ルールの変更頻度や例外条件も記録します。
同じ情報を複数のツールへ移す工程に向きます。連携元・連携先、更新のタイミング、失敗時の通知と再処理方法を確認します。
形式や表現に幅がある文書の分類・情報抽出など、固定ルールだけでは扱いにくい作業で候補になります。誤りや確信度の扱い、根拠確認、人へ回す条件を設計します。
影響が大きい判断、情報が不十分な例外、責任の所在を明確にすべき工程には、人の確認を残す選択肢があります。確認者が必要な情報へアクセスできることも確かめます。
比較の軸は、処理の安定性、例外の量、誤りが及ぼす影響、既存システムとの接続、運用後に誰が確認・修正するかです。AIを採用すること自体を目的にせず、業務上の問題を解決できる最小の方法から検討します。自動処理と人の承認を組み合わせるなら、確認対象、差し戻し先、手動で再開する手順までフローに書き込みます。
改善案は、対象件数、担当者、入力データ、対象工程を絞って小さく検証します。通常ケースだけでなく、よくある例外と、見落とすと影響が大きい例外も含めます。比較する前に、現状の処理時間や差し戻し、確認負担などを同じ条件で記録しておくと、変更後に何が変わったかを判断しやすくなります。
評価は速さだけで決めません。たとえば、処理にかかる時間、抽出や分類の正しさ、例外を適切に保留できたか、担当者の確認時間、差し戻しの発生状況を組み合わせて見ます。結果に問題があったときは、対象範囲を広げるのではなく、入力条件・ルール・確認手順のどこを見直すかを先に検討します。
次の一歩
フローを描いた後は、課題の原因と例外の影響を確かめ、ルール・連携・AI・人の確認を組み合わせて検討します。対象範囲や利用環境が決まっていない段階でも、まず現状の業務について相談できます。
ご相談
現在の手順や困っている工程がまとまっていなくても構いません。依頼の入口、関係する担当者やツール、確認待ち・差し戻しの例など、分かる範囲からご連絡ください。支援の対象や進め方は、業務内容と利用環境を伺ったうえで確認します。