CXのためのSIPOCおよびその他のプロセス発見ツール

ドバイのある銀行で、新規口座開設の完了までに平均11日かかっていた。フロントのエージェントは礼儀正しく、チャットボットの応答は速く、アプリの画面設計も悪くない。それでも顧客満足度は下がり続けていた。原因はジャーニーマップのどこにも書かれていなかった。KYC書類が3つの部署を手作業で往復し、そのたびに紙の承認プロセスが止まっていたのだ。

これはよくある構図だ。CXチームは顧客の「見える部分」を磨き込むのに時間をかけるが、遅延と苛立ちの本当の発生源は、顧客の目に入らない社内プロセスの中にある。SIPOCのようなプロセス発見ツールが必要なのは、まさにこの盲点を埋めるためだ。ジャーニーマップが「顧客が何を感じたか」を描くのに対し、SIPOCは「その体験を生み出した業務が実際に何をしているか」を暴き出す。両方がなければ、CX改善は表面の塗り直しで終わる。

なぜジャーニーマップだけではボトルネックが見えないのか

ジャーニーマップは顧客の視点から描かれる。タッチポイント、感情の起伏、ペインポイントを時系列で並べる作業には価値があるが、地図はあくまで「表側」の記録だ。裏側で誰が何を、どの順番で、どのシステムを使って処理しているかは描かれない。CXジャーニー設計の現場でよく起きる失敗は、マップ上の「承認待ち」という一行を、実際に3人の承認者と2つの手作業入力を経由する業務として分解しないまま改善案を書いてしまうことだ。

結果として、顧客対応のスクリプトやUIコピーは変わるが、処理時間そのものは変わらない。Lynn Shostackが1984年にHarvard Business Reviewで発表した論文「Designing Services That Deliver」は、サービスは製造業の製品と同様に「設計可能な工程」であると指摘し、サービスブループリントという裏側の業務フローを可視化する手法を提示した。この発想の核は今も変わらない――顧客が感じる遅さは、たいてい顧客が見ていない場所で生まれている。

SIPOCとはどういうツールで、CXにどう使えるのか

SIPOCはSupplier（供給者)・Input（インプット)・Process（プロセス)・Output（アウトプット)・Customer（顧客)の5列を1枚の表に整理し、プロセスの全体像を高い視点から可視化するフレームワークだ。もともとはシックスシグマのDMAIC(Define-Measure-Analyze-Improve-Control)手法の「Define」フェーズで使われる品質管理ツールとして体系化されたが、CXの文脈に持ち込むと威力が変わる。

使い方は単純だ。プロセスの名前をひとつ決める――「新規口座開設」「解約リクエスト対応」「保証クレーム処理」など。そのプロセスに対して、誰が何を提供し(Supplier/Input)、社内でどんな工程が行われ(Process)、何が生み出され(Output)、それを最終的に誰が受け取るのか(Customer)を、5〜7ステップ程度の粗い粒度で書き出す。詳細なフローチャートではない。目的は網羅性ではなく、プロセスの境界と関与者を最初に確定させることにある。

顧客が体験する遅延の原因は、たいてい顧客の視界に入らない場所にある。SIPOCの価値は、その場所を最初に指し示すことだ。

SIPOCワークショップはどう進めるのか

実務では、SIPOCは1〜2時間のワークショップとして進めるのがもっとも効果的だ。プロセスに関わる現場の担当者を集め、次の手順で進める。

1. プロセスの開始点と終了点を確定する。「顧客がリクエストを送った瞬間」から「顧客が結果を受け取った瞬間」まで、範囲を明確に区切る。範囲があいまいだと議論が発散する。
2. アウトプットとカスタマーから逆算する。先に「何が顧客に届くべきか」を書き、そこから逆にプロセスをたどる。顧客視点を最初に固定することで、社内の都合に偏った工程整理を防げる。
3. プロセスを5〜7の粗いステップに分解する。各部署の担当者が「自分の工程では実際にこう処理している」と発言する場を作る。ここで初めて、マネジメントが知らなかった手作業や二重入力が表に出る。
4. インプットとサプライヤーを特定する。各ステップが何を必要とし、それを誰が(どの部署、どのシステム、どの外部ベンダーが)提供しているかを書き出す。
5. ステップごとの所要時間と待ち時間を書き添える。SIPOC単体では時間軸は必須ではないが、CX目的で使う場合はここに時間データを足すことで、どのステップが本当に体験を遅らせているかが数字で見える。

このワークショップの最大の副産物は、表そのものではなく、部署をまたいだ担当者が初めて「隣の工程で何が起きているか」を知ることだ。ここで見えた重複作業や手待ち時間が、後のプロセス設計の出発点になる。

SIPOC以外にどんなプロセス発見ツールを使うべきか

SIPOCは優れた出発点だが、万能ではない。粒度が粗いため、実際のボトルネックの深さまでは届かないことが多い。CXの現場で組み合わせるべき代表的な手法は次のとおりだ。

• サービスブループリント ― 顧客の行動(表側)と、それを支えるフロントステージ・バックステージの従業員行動、システム、サポートプロセスを同じ時間軸に並べる。Nielsen Norman Groupが2018年に公開した記事「Service Blueprints: Definition」は、この手法が「顧客の体験」と「その体験を生み出す運営の仕組み」を1枚でつなぐ点に価値があると説明している。SIPOCで境界を確定したあと、ブループリントで顧客の感情と業務を同期させると効果が高い。
• プロセスマイニング ― CRM、ERP、チケット管理システムのログデータから実際の処理経路を再構築する手法。人が「こう処理しているはず」と語る内容と、システムログが示す実態は驚くほど食い違うことが多い。ヒアリング型のSIPOCと、データ駆動型のプロセスマイニングは、必ず両方使うべき。片方だけだと「思い込みの地図」か「文脈のない数字」のどちらかに偏る。
• バリューストリームマッピング(VSM) ― 各工程が顧客にとっての価値を生んでいるか、単なる待ち時間や手直しかを区別する。製造業の生産管理から来た手法だが、バックオフィス業務の「付加価値のない時間」を可視化するのに向いている。
• RACIマトリクス ― SIPOCで工程の全体像を掴んだあと、各ステップの責任者(Responsible)、承認者(Accountable)、相談先(Consulted)、報告先(Informed)を割り当てる。承認待ちのボトルネックは、たいてい「誰が最終承認者か」が曖昧なところで発生する。

これらを一度にすべて実施する必要はない。目的に応じて選ぶのが実務的だ。範囲確定と関与者の把握にはSIPOC、顧客体験と業務の同期にはサービスブループリント、実態の裏付けにはプロセスマイニングという順序で使うと、無理なく深度を上げていける。

プロセス発見でCXチームが陥りやすい罠は何か

プロセス発見のワークショップ自体は簡単に企画できる。難しいのは、そこで出てきた情報を正しく扱うことだ。現場で繰り返し見る失敗は次のようなものだ。

• 参加者を管理層だけに絞ってしまう。実際に手を動かしている担当者を招かないと、プロセスは「本来こうあるべき」という理想形で語られ、実態の抜け穴が見えなくなる。
• 粒度を最初から細かくしすぎる。SIPOCの目的は境界確定であり、詳細フローチャートではない。最初から詳細化しようとすると議論が停滞し、参加者の集中力が切れる。
• プロセスを1回描いて終わりにする。業務プロセスはシステム更新や組織変更で変わる。四半期ごとの見直しがないSIPOCは、半年後には現実と食い違った「化石の地図」になる。
• 顧客への影響を数値化しないまま提出する。「このステップは非効率だ」という主張だけでは経営層は動かない。そのステップが顧客の待ち時間や解約率にどう跳ねているかを、モーメント・オブ・トゥルースと結びつけて提示する必要がある。

もうひとつ、意外と見落とされがちな罠がある。プロセスを可視化した瞬間に、それを設計した部署の担当者が防御的になることだ。SIPOCワークショップは「誰が悪いかを暴く」場ではなく「顧客にとって何が起きているかを一緒に発見する」場だと最初に宣言しておく必要がある。ここを誤ると、次回以降の協力が得られなくなる。

ボトルネックを見つけたあと、何をすべきか

SIPOCとサービスブループリントで発見したボトルネックは、そのままでは改善にならない。ここで行動経済学の視点が効いてくる。心理学者Clark Hullが提唱し、後に消費者行動やゲーミフィケーションの分野で広く応用されているゴール・グラディエント効果――目標に近づくほど人はペースを上げる、という原理は、社内プロセスにも当てはまる。承認フローの最終段階に近い担当者ほど処理を後回しにしがちなのは、彼らにとって「ゴールに近い」という実感が薄いからだ。プロセスの各ステップに、顧客までの残り工程数を可視化するだけで、処理速度が変わることがある。

もうひとつ有効なのは、行動経済学者Richard Thalerが提唱したスラッジ(sludge)という概念だ。摩擦(friction)が意図せず発生する障害であるのに対し、スラッジは組織側の都合(承認プロセスの多層化、重複したデータ入力、部署間の押し付け合い)によって作られた不必要な障害を指す。SIPOCで暴かれる社内ボトルネックの多くは、実はスラッジだ。誰かの都合で追加された承認ステップ、統合されていないシステム間の二重入力――これらは顧客のためではなく、組織の防御のために存在している。プロセス発見の本当の目的は、それを特定して削ることにある。

実務では、発見したボトルネックを次の3段階で処理するとよい。

1. 影響度で優先順位をつける。顧客の待ち時間・解約率・クレーム件数への影響が大きいボトルネックから着手する。すべてを同時に直そうとすると、どれも中途半端に終わる。
2. 削除できるステップを先に削る。改善よりも、まず「本当に必要か」を問う。承認ステップの半分は、リスク回避のために慣習として残っているだけで、実際の意思決定には関与していない。
3. 残ったステップを再設計し、実行責任者を置く。可視化しただけでは何も変わらない。改善案を担当者・期限付きのロードマップに落とし込み、実行を追跡する仕組みが必要だ。

この一連の流れを組織的に定着させるには、プロセス改善が一度きりのプロジェクトで終わらないようにするチェンジマネジメントの視点も欠かせない。プロセスマップを更新しても、それを使う文化がなければ、6か月後には誰も見ない資料になる。

自社のプロセス発見と改善がどの段階にあるかを客観的に把握したい場合は、CX成熟度アセスメントで12の構成要素にわたる現状を確認するところから始めるとよい。

むすび:プロセスを描くことは、顧客への約束を書き直すことだ

SIPOCは地味なツールだ。派手なダッシュボードもなければ、AIも使わない。ホワイトボードとポストイットで十分に機能する。だがその地味さこそが強みだ。プロセス発見に必要なのは高度な分析ではなく、部署の壁を越えて「実際に何が起きているか」を正直に言い合う場をつくることだけだ。

顧客が最後に覚えているのは、担当者の笑顔でも、アプリの操作性でもなく、待たされた時間の記憶であることが多い。その記憶を変えたいなら、フロントの演出をいじる前に、裏側のプロセスを一度、紙の上に正直に描いてみることだ。そこから見えてくるボトルネックは、たいてい誰も意図して作ったものではない。だからこそ、見つけて削る価値がある。プロセスを可視化し、設計しなおす力を体系的に組織に根づかせたい場合は、Renascenceのサービスデザイン支援が、SIPOCからロードマップ実行までを一貫して支える。