現在ご覧のページは当社の旧webサイトになります。トップページはこちら

顧客接点を強化する顧客情報基盤の在り方

マネージャー 奥田 良治
『情報未来』No.35より

はじめに

企業の長期的な優位性確保の手段として、顧客との関係性強化が叫ばれるようになって久しい。顧客との良好な関係を維持するためには、お客さま一人ひとりを正しく理解し、あらゆる接点で、それぞれのお客さまに合わせた最適な対応をとる必要がある。それ故、数多くの企業がお客さまの正確な情報を必要なタイミングで供給できる顧客情報基盤の整備に取り組んでいる。しかしながら、実態としてうまくいっている例を目にすることは少ない。そこで、本稿では、あらためて、顧客との関係性を強化する顧客情報基盤の在り方について、その基本的な考え方を紹介したい。

複雑化する顧客接点業務がもたらす問題

現在、多くの企業が、多様化した顧客一人ひとりとの関係性強化を目的に、多様な商品・サービスを、多様な顧客接点チャネルを通じて、販売・提供している。しかも、各チャネルは単に販売のチャネルとして活用されているだけでなく、販売前のプロモーションのチャネルとして、あるいは、販売後のアフターフォロー(カスタマー・サービス)のチャネルとしても活用されており、その役割も多様化してきている。それ故、各顧客接点チャネルにおける業務は以前にも増して複雑化してきている。

商品・サービス、チャネルの多様化は、本来、多様化した顧客一人ひとりの満足度を高め、関係性を強化することが目的であったはずである。しかし、その多様化が、業務を複雑化させ、逆に、顧客の満足度を下げる事態を引き起こしている。例えば、自らが顧客となって電話やメールで問い合わせたとき、あるいは、電話やメールを通じてアプローチを受けたときのことを思い出して欲しい。読者の方々も、次のような不満を抱いたことがあるのではなかろうか。

(例1)それぐらい知っててよ!

OP(※1):「○○様、お問い合わせありがとうございます。Aサービスのアップグレードに伴う、月額料金のご案内ですね。アップグレード致しますと月額×××円になりますが…」

顧客:「あれっ、Bサービスの利用者には、割引があると聞いたんだけど…」

OP:「あっ、大変失礼いたしました。○○様はBサービスもご利用なのですね。
そうしますと…」

顧客:「(それぐらい知っててよ。じゃなきゃ、わざわざ電話で聞かないよ)」

(例2)さっきも教えたんだけど!

OP:「○○様、ご連絡ありがとうございます。商品Cの故障の件ですね。先ほどもメールでご連絡いただいたとのことですが、具体的に、どのような状況でしょうか?」

顧客:「(えっ、また、一から説明するの?)」

(例3) そんなのいらないよー

DM(※2):「Dサービスのご紹介、…」

顧客 :「(別にそんなのいらないよ)」

(例4)また、その話 …/ しつこい!

OP :「○○様でいらっしゃいますか? 本日はDサービスのご紹介でお電話差し上げました…」

顧客 :「(えっ、また、その話)」

※1:OP=オペレーター ※2:DM=ダイレクトメール

統合顧客情報基盤の必要性

前述はいずれもお客さまのことを理解していないがために発生した不満、すなわち、理解するのに必要な情報を、必要なタイミングで入手できなかったがために発生した不満と言える。無論、お客さまに応対したオペレーターの態度、マーケッターが検討したレコメンドの内容、応対のプロセスなどもその要因と考えられる。それ故、必ずしもお客さまの情報を入手できなかったことだけが要因とは言わない。ただ、最も根本的な要因の1つであるということは間違いないであろう。実際、いずれのケースにおいても、顧客一人ひとりのプロフィール(デモグラヒック属性)や契約・利用商品・サービス、各顧客接点チャネルでの過去の応対状況、そこから類推可能なライフスタイルや嗜好性などの情報を必要なタイミングで入手できていれば、前述のような不満を発生させずに済んだはずである。しかもこれらの情報はその企業のどこかに必ず存在しているか、あるいは、存在する情報から分析・類推することが可能な情報だ。

では、なぜこのようなお客さまの情報を入手できなったのか? それは情報システムの作られ方、顧客情報の蓄積のされ方によるところが大きい。具体的には、商品・サービス、チャネルの多様化の過程において、それぞれを管理する情報システムがバラバラに作られ、顧客情報がバラバラに生成・蓄積・管理されるようになったためだ。しかも本来同一の人物である顧客がシステムごとに別々のIDで管理されているため、同一人物であることすら認識できないという状況も発生している。このような状況では、電話を受けるコールセンターのオペレーターも、お客さまを直接訪問する営業も、あるいは、お客さまへのアプローチを考えるマーケッターも、顧客と対話する上で、あるいは、顧客との対話を検討する上で、必要となる正確な情報を必要なタイミングで手に入れることは極めて難しい。だからこそ、各システムに分散した顧客情報を顧客一意に紐付け、整理・統合した統合顧客情報基盤が必要とされるのだ。

統合顧客を中心とした顧客情報の活用サイクル


図表1:統合顧客情報基盤を中心とした顧客情報の活用サイクルと業務
出所:NTT データ経営研究所にて作成

前述のお客さまの不満を解消するためには、システムごとにバラバラに生成・蓄積・管理された顧客情報の統合とともに、統合顧客情報基盤を中心とした情報活用のサイクルを回していく必要がある(図表1)。このサイクルにおいて実施される業務は大きく2つある。

(1)フロントエンド業務:顧客との対話を遂行する業務

1つは、言わずもがな、統合顧客基盤に蓄積された情報を参照しながら、実際に顧客との対話を遂行する業務である。例えば、コールセンターやEメールなどを介して、お客さまからの質問に応えたり、あるいは、逆にお客さまに対してお奨めの商品・サービスなどを紹介したりする業務である。このように実際に顧客との対話を遂行する業務をここではフロントエンド業務と呼ぶ。

(2)バックエンド業務:対話に必要な情報を創出する業務

もう1つは、各顧客接点での効率的・効果的な対話を実現するため、統合顧客情報基盤に蓄積された情報から、より付加価値の高い情報を創出・提供する業務である。例えば、コールセンターやWEBを介して、お客さまがアプローチしてきた際に、あるいは、こちらからプロアクティブにアプローチする際に、新たな商品・サービスの購買・利用を促すことがあるだろう。そのためには、過去のお客さまの購買・利用行動や現在の属性情報などを分析し、あらかじめ「誰に、いつ(どんなタイミングで)、どこで(どのようなチャネルを通じて)、何を(どのような商品・サービスを)、どのように(訴求ポイント・メッセージなど)、アプローチするのか?」の仮説を立てておく必要がある。このような仮説を立案するための分析業務をここではバックエンド業務と呼ぶ。

繰り返しになるが、前述のようなお客さまの不満を解消するためには、単に統合顧客情報基盤を中心に据えて、これを見ながら顧客と対話((1)フロントエンド業務)するだけでなく、その際に必要となるより付加価値の高い情報を生み出すような活動((2)バックエンド業務)も重要となる。逆に言えば、統合顧客情報基盤はこれら2つの業務で活用されることを念頭において、検討すべき情報システムだと言える。

統合顧客に求められるサービスレベルと実装方針


図表2:各業務の業務特性・要件と統合顧客情報基盤に求められるサービスレベル
出所:NTT データ経営研究所にて作成

では、これらの業務に活用される統合顧客情報基盤を実際どのように実装すればよいのだろうか? これまでの議論の中ではあたかも1つの情報システムであるかのようにお話してきたが、実を言うと、統合顧客情報基盤は(1)、(2)のそれぞれの業務に合わせて、別々のシステムとして構築されるケースがが多い。なぜならば、各業務の特性が大きく異なるため、システムに求められるサービスレベルも大きく異なるからだ(図表2)。

具体的にはこうである。

1 各業務が求めるシステムの 可用性・信頼性・保守性 

(1)フロントエンド業務において求められる可用性・信頼性・保守性

以前は時間を区切って提供してきたWEBやコールセンターにおける申し込みの受け付けや問い合わせ、トラブルへの対応といったサービス((1)フロントエンド業務)も、現在では限りなく24時間365日に近い対応が求められている。このような状況下においては、統合顧客情報基盤に対しても、当然24時間365日できる限り停止することなく、稼働し続けることが求められる。

(2)バックエンド業務で求められる可用性・信頼性・保守性

一方、分析を主体とする(2)バックエンド業務では必ずしも24時間365日停止することなく稼働し続ける必要はない。決まった時間までに分析に必要なデータをそろえてくれれば、また分析業務を行う間さえ動いていてくれればよい。仮に停止したとしても、実際にお客さまとリアルに対応する(1)フロントエンド業務ほど、クリティカルなものにはならないはずだ。

(3)各業務が求める可用性・信頼性・保守性(まとめ)

このように各業務が求める(A)-a システムの可用性(稼働していて欲しい時間)とそれを担保するシステムの(A)-b 信頼性(故障のし難しさ)、(A)-c 保守性(故障からのリカバリのし易さ)に対する要求度にはかなりの違いがあることが分かる。

2 各業務が求めるシステムの処理性能 

(1)フロントエンド業務において求められるリアルタイムの処理性能

実際にお客さまとの対話を遂行する(1)フロントエンド業務においては、あらゆる顧客接点で得られたお客さま一人ひとりの最新の情報を、正確かつリアルタイムに必要とする場合が多い。例えば、Eメールで問い合わせてきた顧客が、即座にコールセンターへと電話をかけてくることを想像して欲しい。対応したコールセンターのオペレーターも事前にEメールによる問い合わせがあったかどうか、どんな問い合わせだったか、を知って対応するのと、知らずに対応するのとでは、その対応品質に大きな差が出ることは言うまでもない。あらゆる顧客接点チャネルで、絶え間なく更新されていく情報は、システムにおいてもリアルタイムに更新・反映され、あらゆる顧客接点チャネルで共有される必要がある。

(2)バックエンド業務で求められる大量履歴情報の処理性能

一方、分析を主体とする(2)バックエンド業務においては、必ずしもリアルタイム性は求められない。基本的には、1日なり、1週間なり、1ヶ月なりのまとまった期間の情報を後日まとめて正確に更新・反映してくれればそれで十分である。

(2)バックエンド業務において考慮すべきは、むしろ、情報の更新・反映に際して処理されるデータ量への対処である。一般に、(2)バックエンド業務では、全顧客の過去の購買・利用行動データなど大容量の履歴データを保持・処理することが多い。例えば、顧客ごとのレコメンド商品は、過去の購買・利用行動の変化から、どんな商品・サービスを利用した顧客が、次にどんな商品・サービスを購買・利用しやすいかの傾向を見いだすことで決定される。そのためには、過去数ヶ月~数年に遡っての全顧客の購買・利用行動履歴データが必要だ。このような履歴を含んだ大容量のデータを保持・処理するため、(2)バックエンド業務では、リアルタイムに処理する能力よりもむしろ大容量のデータを一度に処理する能力が求められるのだ。

(3)各業務が求める処理性能(まとめ)

以上から、各業務が求めるシステムの処理性能は次のように整理できる。(1)フロントエンド業務では、顧客一人ひとりの小容量データをリアルタイムに大量・多重に処理する処理性能が、(2)バックエンド業務では、リアルタイムである必要はないものの、履歴を含む大容量データを一度にまとめて処理する処理性能が求められる。このように各業務が統合顧客情報基盤に求める(B)にも大きな違いがあることが分かる。

3 DWHとODS に分割しての実装 

以上のように各業務において求められるサービスレベルが異なることを考えれば、業務ごとに別々の情報システムとして構築するという考え方は自然である。仮に1つのシステムとして構築しようとしても、求められる情報の種類、(B)処理性能の違いから、結果的に機能として分離されることになる。また、(A)可用性・信頼性・保守性といったサービスレベルの面においても、1つのシステムとして構築しようとすれば、両業務の要求レベルの内、より高いレベルに合わせる必要があることから、必要以上のコストが要求される。これは構築時だけでなく、運用時についても言えることだ。

図表3:ODS(オペレーショナル・データ・ストア) と DWH(データ・ウエアハウス)
出所:NTT データ経営研究所にて作成

それ故、統合顧客情報基盤という1つの概念で語ってきた情報システムも、実際には別々に構築されるべきなのである。このとき、(1)の業務で活用される統合顧客情報基盤をODS(オペレーショナル・データ・ストア)と、(2)の業務で活用する統合顧客基盤をDWH(データ・ウエアハウス)と一般には呼んでいる。すなわち、統合顧客情報基盤の実態とは、この(1)ODSと(2)DWHの集合体なのだ(図表3)。

おわりに

ここまで、顧客接点チャネル業務の複雑化が引き起こす問題から統合顧客情報基盤の必要性を述べるとともに、その実装方針としてフロントとバックの両業務が求めるサービスレベルの違いから、別々のシステムとして作る必要があることを述べてきた。読者の中には、至極当たり前で、取り立てて本誌で語るべきことか?と思われた方もいたかもしれない。しかしながら、これらを区別せずに検討を進めているが故に混乱をきたしているプロジェクトを筆者は数多く見ている。そのため、あらためてこのようなレポートを書いた次第だ。確かに、業務側の要件を素直に紙に落とせば、図表1のような統合顧客情報基盤という1つのシステムイメージになるかもしれない。しかし、一度どう作るかという議論になった瞬間、それが1つでは破綻する。異なる用途で活用するシステムならば、別々に作るのが自然であろう。今必要とされている統合顧客情報基盤とはどちらなのか? 

このことを念頭において、優先順位を付けながら、統合顧客情報基盤の実現に取り組む必要がある。

Page Top