【保険業務BPR】 課題・ニーズの洗い出し（例）

現状業務を整理しながら、クライアントが抱える課題を洗い出していきます。”発散”の段階なので、検討の漏れがないようにすべて可視化することがポイントで、どのような観点（フレームワーク）で課題・ニーズを洗い出ししたがクライアント側からも理解できるように整理します。

①. 課題仮説の検討 現状業務の課題・ニーズのヒアリングや分析は、何も考えずに始めると結構偏ります。声の大きい人の課題だけが集まる、分かりやすい非効率（IT・入力作業）に寄ってしまう等の傾向があるため、事前にどんな課題がありそうかを把握しておきます。よく使われる観点（プロセス・IT/システム・組織/人・顧客・ルール）等を使って課題を洗い出しておくとともに、他PJの事例・ITベンダーの情報・業務知見者等から情報を集めて、課題仮説を整理しておきます。ほとんどケースで、クライアント側が想定している課題も提示されると思うので、そこも考慮しますが、本当にそうなのか？他にないのか？という視点で考えます。

②. 業務データ分析（裏付け） 仮説として整理した課題を検証しにいきます。できれば、業務部門にヒアリングする前に対象業務のデータをもらって、課題が存在するか、存在する場合のインパクト等を確認します。例えば、処理にかかるリードタイムや作業工数を数字で集計して、問題があるプロセスの特定や優先度付けの客観的な論拠とします。ただ、「新契約」や「保険金支払」等は業務上のシステム登録が必須なため、品質の高いデータがありますが、「募集（営業）」や「代理店支援」等は入力が徹底されてなくて、データが不十分だったりします。それでも、クレンジングする等で重要そうな課題だけでも定量的に確認しておくと、後々の経営層への説明の根拠となるので、可能な限り対応します。

③. 課題・ニーズのヒアリング（裏付け） 課題仮説の整理と業務データ分析である程度の想定課題の整理を行ったら、課題・ニーズを業務部門の担当者にヒアリングしに行きます。ふわっと聞きにいくのは厳禁で、事前にヒアリングシートを作っておきます。ヒアリング項目（質問）一つにつき検証したい課題仮説が一つあるのがベストですが、厳密にやりすぎると本音を引き出せなかったり、重要な課題を見逃したりするので、この辺のファシリテーションは結構難しかったりします。発言しやすい雰囲気を醸成するため、マネジメント層と担当者層を分けたり、参加者を絞ってヒアリングをする等で、”発散”を意識して課題・ニーズを確認していきます。

④. 課題・ニーズの整理

業務データ分析とヒアリングで検証した課題・ニーズを成果物としてアウトプットしていきます。整理して終わりでなく、課題・ニーズをもとにTo-Beを検討していくので、事実ベースで具体的に記載するとともに、パッと見て理解できるようにもします。課題を一覧化してただ並べるのではなく、確認の漏れがないことも示すため、検討した観点も表現した上で構造化して整理します。例えば、業務プロセスと関係者でマッピングする、観点（≒原因：プロセス・IT/システム・組織/人・顧客）ごとにまとめる等で資料に落とします。下記は、損害サービス業務の課題をプロセスと関係者でまとめた例です。

課題の整理例（自動車 損害サービス業務）

大きな課題分類は見やすく整理する一方で、具体的な課題は事実ベースで納得感を得るように記載することも重要です。単に、「業務が非効率」、「属人化している」と書くのではなく、業務データ分析結果等をもとに、「例外処理が全体件数の15％だが、工数の45％を占めている」、「特定業務を担当できるのが2名のみで、引継ぎに3か月必要」等の発生している事象を含めて書くことで、関係者の認識がずれないようにします。

課題の整理例（自動車 損害サービス業務）

下記は、募集（営業）業務の課題を洗い出した観点で整理した例です。

課題の整理例（募集）

あくまで例なので、曖昧に記載していますが、実際のプロジェクトでは、別紙のExcelで確認した課題・ニーズを細かく整理する成果物があるケースが多いです。

課題の整理例（募集）

⑤. 課題・ニーズの重み付け

ここまでで課題・ニーズを洗い出して整理しましたが、リソース制約等で残念ながら全てをいっぺんに解決することはできません。限られたリソースで最も大きな効果を発現させるために、今後のプロジェクト意思決定に向けて関係者が同じ判断軸を持つために、課題・ニーズに優先順位を付けていきます。まずは、課題・ニーズを評価する基準を作ります。例えば、「作業負荷・業務品質・顧客満足・コンプラリスク」で軸を定義して、各軸を評価する考え方もまとめます。各軸ごとに点数を付ける（1～5）などしたスコアリング結果を踏まえて、課題の重要度を「高・中・低」等で重み付けしていきます。プロジェクトによっては、課題への優先順位付けはそこまで厳密に行わず、課題への打ち手に対して「インパクト・実行難易度」等で優先度を付けるケースもあります。この辺は関係者とも会話しながら進めます。

⑥. 関係者での合意

BPRで解決すべき課題・ニーズと優先度を整理したら、プロジェクト関係者での合意形成を図ります。合意とは、メンバー全員が賛同することではなく、プロジェクトとして承認することです。キーマンを抑えにいくか、トップダウン的に決めるか等、状況に応じて事前にすり合わせ、会議体で共有して議事録等に証跡を残します。結論だけでなく、なぜそうなったかのプロセス（課題の洗い出し方法／データ分析とヒアリング結果／重み付けの基準）とともに、優先度が低い課題も実行されないのではなく、順番の問題であることを説明します。

BPRの構想策定フェーズにおいては、課題・ニーズが明確に定まれば、成功の確率はかなり高まります。「イシューから始めよ」とよく言いますが、この言葉通り、解決すべき課題を定義することで、成果を生み出す対応策として何をすべきかがブレにくくなるからです。課題への打ち手の検討は、このフェーズだと夢も語れるので結構楽しいケースもあります。