顧客の業務フローを整理する方法｜担当者間の受け渡しを図にする
顧客の業務フローを整理するときは、作業の順序に加えて、誰が何を受け取り、次の人へ何を渡すかを並べます。通常の流れだけでなく、差し戻しや待ちも描くと、どこを追加で確認すべきかが見えてきます。
「承認を速くしてほしい」と聞いても、ボタンの操作が遅いのか、必要な書類がそろわないのか、次の担当者に届いていないのかは分かりません。一つの画面の中だけで考えず、その前後の仕事を図にしてみましょう。
この記事では、担当者ごとの区画を使い、作業の受け渡しを共有する方法を紹介します。厳密な記法を覚えることより、関係者が現状を確認できる図を作ることを優先します。記号や線の意味は図のそばに短く書き、同じ意味で使います。
- 開始と終了を決め、一つの業務に範囲を絞る。
- 作業の担当、受け取る情報、渡す情報を一緒に書く。
- 現状と改善案、確認済みと未確認を分ける。
開始と終了を一つの業務で決める
最初に「何のために、どの業務を確認するか」を決めます。「経理業務全体」では範囲が広いため、例えば「申請者が経費を申請してから、経理が処理できる状態になるまで」と区切ります。
以下は架空の経費申請を題材にした例です。担当や手順は説明用であり、実在する顧客の業務やアーコレ！の機能ではありません。
| 図にする前の設定 | 架空の記入例 |
|---|---|
| 確認したいこと | 書類不足の差し戻しが、どこで誰に伝わるか |
| 対象の業務 | 経費の申請と確認 |
| 開始 | 申請者が申請内容と領収書を提出する |
| 終了 | 経理が処理に必要な情報を確認できる |
| 今回含めない範囲 | 振込処理、会計上の判断の詳細 |
| 情報の根拠 | 担当者の説明、閲覧を許可された手順書など |
範囲外に置いた仕事も、完全に存在しないものとして扱うわけではありません。次の工程へ何を渡すかだけは端に書き、必要になれば別の図で確認します。
役割ごとの区画を用意する
紙や図表ツールに、申請者・承認者・経理の区画を作ります。この区画は「レーン」とも呼ばれ、作業を置いた場所によって担当が分かるようにします。横向きでも縦向きでも構いません。
Microsoftの部門連係フローチャートの説明では、業務の手順と、それを担当する部門や役割との関係をレーンで表します。本記事ではその考え方を使い、顧客との確認用に簡単な図へ落とし込みます。Visioなど特定のツールを使う必要はありません。
役割は個人名だけでなく、「申請する人」「内容を承認する人」のように書きます。一人が複数の役割を担う場合もありますし、同じ役割を複数人で分担する場合もあります。顧客とユーザーの違いと同様に、誰が契約したかと、実際にどの仕事をするかは分けて確認します。
顧客の気持ちや接点を時間順に捉える図と違い、ここでは作業の担当と受け渡しが中心です。似た図でも、何を確かめるために作るのかを決めて使います。
作業と受け渡す情報をつなぐ
まず、普段どおりに進む流れを並べます。作業名は「確認」だけでなく、「領収書と金額を確認する」のように、対象が分かる言葉にします。
架空の例なら、次のようにつながります。
- 申請者が、申請内容と領収書を提出する。
- 承認者が、内容を確認して承認結果を渡す。
- 経理が、承認済みの申請と添付資料を確認する。
この三つを矢印で結ぶだけでなく、矢印のそばに「申請内容＋領収書」「承認結果」のように、渡す情報を書きます。「担当が変わった」のに、何が渡されたか分からない箇所を探せます。
下の表は、図を描く前に使える本記事独自の作業表です。角括弧を自分の業務の記録へ置き換えてください。
| 項目 | 記入欄 |
|---|---|
| 作業 | ［何を、どうするか］ |
| 担当する役割 | ［この作業を行う人］ |
| 受け取るもの | ［情報、書類、承認など］ |
| 作業後に渡すもの | ［次の担当が必要とするもの］ |
| 次の担当・渡し方 | ［誰に、どの方法で渡すか］ |
| 例外・待ち | ［進められない条件、戻す先］ |
| 根拠と未確認点 | ［確認した記録、まだ聞けていないこと］ |
サービス外の作業も含める
アプリの中で完結しない作業も残します。紙を確認する、表計算で金額をまとめる、チャットで担当者を呼ぶ、といった手順が次の操作の前提かもしれません。
提供側が見たい画面だけに範囲を狭めると、顧客が何を待っているかを見落とします。一方、すべての情報を集める必要もありません。今回の受け渡しを理解するために必要な範囲で、許可された資料や説明を使います。
差し戻しと待ちを描く
経理が添付資料の不足に気づいたとき、申請者へ直接返すのか、承認者を経由するのかを確認します。この違いを推測で埋めると、後の改善案もずれてしまいます。
差し戻しは、戻る相手と理由を矢印に書きます。待ちがあるなら「承認結果を待つ」のように何を待つかを書きます。時間を測っていないのに「平均三日」などの数字を付けないでください。
未確認の矢印は点線にして「返却先は未確認」と添えるなど、図の中で区別できます。色だけに頼らず、文字や線の種類も使うと読み合わせやすくなります。
関係者と現状図を読み合わせる
図を作った人だけで正しいと判断せず、各役割の担当者と、最近の具体的な一件をたどります。図に確認日と対象の業務条件を添えると、後から手順が変わった際にも比較できます。「いつもこの流れですか」だけより、前回何を受け取り、何を渡したかを確認すると、抜けていた手順を見つけやすくなります。
確認するときは、次の問いを使えます。
- この作業を始めるには、何がそろっている必要がありますか。
- 次の担当者へ渡すとき、完了をどのように知らせますか。
- 情報が足りない場合、誰に何を返しますか。
- 担当者が不在の場合も、同じ流れですか。
- 手順書と実際の進め方が違うところはありますか。
担当者同士の説明が食い違ったら、どちらかをその場で正解にしないようにします。対象の案件や時期、例外条件が違うかもしれません。発言者の役割と場面を残し、追加で確認する点にします。
未確認点を改善候補へ渡す
現状図に、理想の流れを混ぜないようにします。「承認後に自動通知したい」は改善案であり、現在すでに行われている仕事ではありません。現状図はそのまま残し、改善案を別の図や欄に置いて比べます。
| 現状図から気づいたこと | まだ決めないこと | 次に確かめること |
|---|---|---|
| 差し戻し先が担当者によって違う | 返却先を一つに固定する | 案件の条件で分けているのか |
| 次の担当者が提出に気づかない場合がある | 通知機能を追加する | 今の連絡方法と、見落とす場面 |
| 同じ情報を別の表へ転記している | 転記をすべて自動化する | 転記先で追加している判断や加工 |
図の中で手順が多く見えても、その作業が不要とは限りません。確認や責任分担のために必要な工程かもしれないため、理由を聞いてから改善候補にします。背景を開発へ伝えるときは、曖昧な機能要望を具体化する方法へつなげられます。
まずは一つの業務だけを描き、関係者が確認できる状態にしてみてください。見つかった未確認点や改善候補は、根拠となる場面と一緒に要望の記録へ残します。継続して扱う方法は機能要望管理の基本で確認できます。図をきれいに完成させることより、次に誰へ何を聞くかが分かることを目指しましょう。
参考資料
- Microsoft：Create a cross-functional flowchart：役割ごとのレーンと業務手順の関係を参照。表と架空例は本記事独自の整理であり、BPMNなどの厳密な図式に準拠するものではありません。
