
許認可、地方税、日常的な市民サービスを扱う欧州のある中規模の政府機関が、SAP Customer Experience(CX)上で、市民との関わり方を作り直しました。ケース管理にはSAP Service Cloud、1つのログインと同意管理にはSAP Customer Data Cloud、リマインダーにはSAP Emarsys、決済にはSAP Commerce Cloudを使い、SAP Business Technology Platform(BTP)でこれらをバックオフィスにつなぎました。処理時間はほぼ50%短縮されました。最も効果が大きかった変更は、どのモジュールよりも単純なものでした。同じ申請について、市民と職員が同じ状況を見られるようにしたことです。
市民は、公共サービスにもオンラインバンキングのような分かりやすさを期待するようになっていました。私たちがインタビューした人たちから聞いたのは、まさにそのことです。1回ログインすれば、すべてが1か所で見られ、自分の申請が公正に扱われていると信じられること。それが望まれていました。従来のシステムには、それができませんでした。部門ごとに別々の記録を持ち、どの窓口でも同じ質問を繰り返し、職員は他の場所ですでに受け取ったデータを再入力していました。
最初に学んだことは単純でした。設計する前に、まず耳を傾けることです。初期の優先事項の多くは、窓口で寄せられた苦情、アンケートのメモ、ちょっとした立ち話から生まれました。どんな計画資料よりも役に立ちました。
SAP CXのポートフォリオから、それぞれに明確な役割を持つ製品を選びました。
| モジュール | 解決した課題 | 変わったこと |
|---|---|---|
| SAP Service Cloud | ケースが部門ごとに散在し、共有ビューがない | 職員には1つのケースビュー、市民には追跡できるステータス |
| SAP Customer Data Cloud | サービスごとに別のログインがあり、同意が見えない | 1つの安全なログイン。市民が自分の同意状況を確認、管理できる |
| SAP Emarsys(現SAP Engagement Cloud) | 市民が機関を追いかけ、機関から連絡することはなかった | 更新、手数料、期限のリマインダー |
| SAP Commerce Cloud | 支払いは窓口で、照合は手作業 | オンライン決済、即時の領収書、財務への直接反映 |
Service Cloudが主力になりました。申請がオンライン、電話、窓口のどこから入っても、同じプロセスをたどります。ケース担当者は、駐車許可を申請したばかりの市民が、先週、税金のことで電話もしていたことを、ようやく把握できるようになりました。サービスレベルをシステム内に設定したことで、説明責任が生まれました。期限が見えて、しかも現実的であることに、市民は気づきました。
チャットボットは、単純な用途にとどめました。ある市民は、保留で待たされることなく、開庁時間について素早く答えてもらえたのは助かったと話しました。ただ、こうも言いました。「争いごとがあるなら、人と話したい」。私たちも同じ考えでした。
Customer Data Cloudによって、許認可、税金、事業免許ごとの別々のログインがなくなりました。同意も見えるようになりました。フィードバックのセッションで、地元の事業主がこう言いました。「少なくとも、自分のデータがどこへ行くのかが分かるようになりました。以前は、目隠しで署名しているような気分でした」。この透明性は、想像以上に大きな意味を持ちました。
Emarsysは、電話を待つモデルから、リマインダー、期限の通知、最新情報を送るモデルへと反転させました。控えめにすることも学びました。リマインダーが多すぎると無視されます。更新や納税期限の通知が注目されたのは、自分に関係があると感じられたからです。
Commerce Cloudは、申請、手数料、確認を1回のオンラインセッションにまとめました。領収書は即時に発行され、行列は短くなり、財務職員が夜にスプレッドシートの照合に追われることもなくなりました。
テスト運用でのことを覚えています。市民向けポータルでは「処理中」と表示され、職員の画面では「承認待ち」と表示されていました。同じ申請なのに、ステータスが2つあったのです。このずれは、問い合わせを減らすどころか、新たな問い合わせを生みました。
私たちは、両側が同じService Cloudのレコードから、まったく同じデータを読むようにして解決しました。この修正こそが、どの機能よりも、電話の件数が減り始めたきっかけです。市民が何よりも重んじるのは分かりやすさであり、速さよりも重んじることを学びました。
当初は、システム間の隙間にどれだけ手作業が潜んでいるかを過小評価していました。市民は許可をオンラインで申請できましたが、職員はその申請をERPに手で入力しなければなりませんでした。支払いはデジタルで届くものの、財務との照合は週末にまとめて行っていました。社会サービス部門は独自にケース管理を運用しており、他部門からは何も見えませんでした。
BTPがその橋渡し役になりました。Service CloudをS/4HANAや従来のプラットフォームにつなぐと、次のようになりました。
- 許可申請が、ERP内で直接ワークフローを開始するようになりました。
- Commerce Cloud経由の支払いが、発生と同時に財務記録を更新するようになりました。
- 社会サービスのケースのステータスが、プライバシー規則の範囲内で、他部門からも見えるようになりました。
- リマインダーを送信Emarsys(現Engagement Cloud)が期限を通知
- ログインは一つCustomer Data Cloudで同意が見える
- 申請と支払いCommerce Cloudで領収書を即時発行
- ケースを作成Service Cloudで全チャネル同じプロセス
- ERPワークフローが始動SAP BTP経由で、誰も再入力しない
- 状況は一つ市民と職員が同じレコードを見る
市民が、申請の状況を問い合わせる電話をかけなくなる
社会プログラムが最も難しい部分でした。プライバシー規則による制約があるため、ケースの状況は概要レベルでのみ公開し、詳細なメモは決して見せませんでした。それでも違いは出ました。住宅担当部局は、市民がすでに支援プログラムに入っているかどうかを確認でき、支援の重複を避けられました。あるケース担当者は、こう話してくれました。「初めて、4つのシステムを掘り返さなくても、市民のケースの全体像が見えるようになりました」。
連携でプログラムが止まっているなら、SAP Integration Suiteの納期遅延についての私の記事で、よくある原因を扱っています。
「360度の市民ビュー」は、最初は専門用語のように聞こえました。職員と市民にとっての意味は単純でした。同じ事情を5回も説明させるのをやめる、ということです。本人情報、取引、サービス要求、やり取りの履歴を、1つのプロフィールにまとめました。誰かが住宅補助金を申請したとき、ケース担当者は、進行中の医療給付の請求や、税務署との最近のやり取りも見ることができました。機関は、1つの組織として動き始めました。
データのクレンジングは時間がかかり、ときに退屈でした。それでも、誤りが減ると、信頼は高まりました。重複したレコードの上に作った360度ビューは、重複を全員に見せてしまいます。
| 領域 | 導入前 | 導入後 |
|---|---|---|
| 処理時間 | ベースライン | ほぼ50%短縮 |
| 申請の追跡 | 電話と窓口への来訪 | 市民がオンラインで申請を追跡 |
| ログイン | 部門ごとに別のアカウント | 同意が見える、1つの安全なログイン |
| 職員のデータ入力 | システム間での再入力 | 1つのケースビュー。職員は例外に対応 |
| 支払い | 窓口で行い、週次で手作業の照合 | オンライン。領収書は即時発行 |
許可、税金、免許がようやく同じ手順をたどるようになり、市民はその一貫性に気づきました。市民は「自分の申請はどうなっているのか」と尋ねなくなりました。自分で確認できるようになったからです。
市民が何よりも重んじるのは、速さよりも分かりやすさです。
- まず聞くこと。 ベンダーのデモ台本ではなく、窓口への苦情、アンケート、満足度スコアを使って優先順位を決めます。
- ステータスは1つにする。 市民と職員が同じレコードを見られなければなりません。これほど速く問い合わせを減らす方法はありません。
- オムニチャネルは、モバイルだけという意味ではありません。 誰もが「モバイルファーストにしよう」と言いましたが、高齢の住民はウェブか電話を好みました。市民がオンラインで始めて電話に切り替えられるようにし、職員が同じ地点から引き継ぐようにしました。
- 単純なケースから自動化する。 私たちは、ルールが明確な更新手続きから始めました。職員は、複雑なケースの主導権を失うことを不安に思っていたので、段階的に進めました。その辛抱が信頼につながりました。
- 送るのはリマインダーで、マーケティングではない。 メッセージは、期限とケースの更新に絞ります。
- 連携の前にデータをきれいにする。 そうしないと、360度ビューがあらゆる誤りを一度に見せてしまいます。
最大の教訓は、最も単純なものでもありました。人の時間を尊重することです。そうすると、信頼はあとからついてきました。公共部門のSAPプロジェクトにおける規制面については、私のSAP公共部門コンプライアンスのガイドをご覧ください。同じ分野の調達の事例としては、SAP AribaのUAE公共部門導入事例があります。
その後のSAPポートフォリオの変化
名称が1つ変わりました。2026年2月、SAPはSAP EmarsysをSAP Engagement Cloudに改称しました。SAP Marketing Cloudはサポート終了を迎えたため、新たに始めるプログラムでは、プロアクティブなコミュニケーションにEngagement Cloudを使うことになります。上記の設計上の教訓は、製品名には左右されません。
公共部門の市民エンゲージメントには、SAP CXのどのモジュールが最も適していますか?
このプログラムでは、ケース管理にSAP Service Cloud、1つのログインと同意にSAP Customer Data Cloud、リマインダーにSAP Emarsys(現SAP Engagement Cloud)、決済にSAP Commerce Cloudを使いました。まずケースの層から始め、次にID、そのあとにアウトリーチと決済を加えてください。
SAP CXは、この機関にどのような成果をもたらしましたか?
処理時間はほぼ50%短縮されました。市民は電話をかける代わりにオンラインで申請を追跡できるようになり、複数あったログインは1つになり、職員はシステム間でデータを再入力しなくなり、支払いはオンラインに移って領収書が即時に発行されるようになりました。
SAP Service Cloudは、政府機関向けの標準的なCRMと何が違いますか?
営業向けのCRMは、リードとパイプラインを軸に作られています。Service Cloudは、ケース、サービスレベル、解決を軸に作られており、ウェブ、電話、窓口を横断して1つのビューを提供します。SAP BTPとS/4HANAにつなぐと、市民の申請が、誰も再入力することなく、バックオフィスのワークフローを開始できます。
公共部門のSAP CX導入では、プライバシーと同意をどう扱うべきですか?
市民に、自分で確認も変更もできる同意設定を備えた1つのIDを持たせます。これはSAP Customer Data Cloudが対応しています。機微な情報は、必要な範囲でのみ部門間で共有してください。今回のケースでは、社会サービスのケースは、詳細なメモではなく、概要のステータスとして見えるようにしました。同意の透明性は、EUにおけるGDPRへの準拠も後押しします。
市民エンゲージメントのプログラムの成功は、どう測りますか?
ケースの種類ごとの解決までの時間、初回連絡での解決率、オンラインで完結した取引の割合、市民満足度スコア、1件あたりの対応コスト、そしてステータスを尋ねる電話が実際に減っているかどうかです。ポータルの登録数だけでは意味がありません。登録しても状況の確認に電話してくるなら、透明性の問題は解決していません。
市民向けサービスで、SAP BTPはどのような役割を果たしますか?
市民向けのフロントエンドを、バックオフィスにつなぎます。それがなければ、デジタルで受け付けた申請も、財務やケース管理のシステムに再入力されることになります。つなげば、許可申請がERPのワークフローを開始し、支払いは発生と同時に財務記録を更新し、ケースの状況はプライバシー規則の範囲内で部門間を流れます。
次のステップ
いまERPプログラムを進めていますか?
この記事が、いま進行中のプログラムに関わる内容だったなら、社内でさらに1週間分析を重ねるよりも、30分の対話のほうが多くの場合ずっと前に進めます。




