PR

 新光証券は2006年9月,東京都内のコール・センターを再構築した。さらに2007年1月10日には,大阪に第2コール・センターを開設。共にIPベースで構築した。IP化によってメリットを得た一方で,いかに従来のコール・センター並みの使い勝手を確保するかという点には苦心した。

写真1●新光証券の第1コール・センター
写真1●新光証券の第1コール・センター
 新光証券は2006年9月,東京都内のコール・センターを再構築した。さらに2007年1月10日には,大阪に第2コール・センターを開設。共にIPベースで構築した(写真1)。

当面の使い勝手より将来性を重視

 IPコール・センターに切り替えたのは,同社がそれまで5年にわたって運用してきたコール・センターのシステムが老朽化したため。呼制御には従来型のPBX(構内交換機)を使い,CTI(computer telephony integration)ソフトはWindows NTベースだった。このため,保守・サポート期間の終了問題が続出。システムの応答速度の低下も目立っていた。

写真2●新光証券の井上洋一IT戦略部IT戦略課マネージャー(写真左),濱根暁・東京コールセンター長(同中央),女屋康明IT戦略部副部長(同右)
写真2●新光証券の井上洋一IT戦略部IT戦略課マネージャー(写真左),濱根暁・東京コールセンター長(同中央),女屋康明IT戦略部副部長(同右)
 使い勝手の継続性を重視するなら,従来型のPBXで再構築することも考えられた。しかし2005年末にはIPベースに刷新する方針を固めた。「2006年4月に策定する中期経営計画に,東京に続く第2コール・センターを稼働させることを盛り込むと決まっていた。複数拠点で運用するなら,1カ所から集中制御が可能なIPベースの方が将来的に有利になると判断した」(濱根暁・東京コールセンター長,写真2)。

 ころ合いよく,導入を検討していた米シスコのCTIサーバー「Cisco Unified Contact Center」の新版が登場。従来版で不満だった管理機能が大幅に強化された。新光証券が重視したのは,オペレータの役割を動的に変更できるようになったこと。これにより,例えば商品説明担当のオペレータが不足した際に,別のオペレータを直ちに商品説明担当に変更できるようになる。「動的に変更する機能がなければ導入を見送っていた」(濱根東京コールセンター長)。

データ・センターが2拠点を一括制御

 IPコール・センターの構築に採用した主なシステムは,Unified Contact Centerのほか,同じくシスコのIP電話サーバー「Cisco Unified CallManager」,米オラクルのCRM(顧客情報管理)サーバー「PeopleSoft Enterprise」などである(図1)。シスコを主体に選んだのは,新光証券が内線電話網にCallManagerを利用していたことが大きい。「社内で蓄積してきた運用ノウハウをそのまま生かせる」(女屋康明IT戦略部副部長)。

図1●2006年9月にIPコール・センターを稼働させた新光証券   図1●2006年9月にIPコール・センターを稼働させた新光証券
米シスコのコール・センター用システムと米オラクルのCRMサーバーを組み合わせて構築した。2007年1月10日から大阪府に第2コール・センターも稼働させた。
[画像のクリックで拡大表示]

 これらのサーバー類はデータ・センターに集中配置した。東京,大阪の両コール・センターとはそれぞれ100Mビット/秒のイーサネット専用線2本で結び,一括で管理・運用する。例えば,コール・センターあての通話は,データ・センター側のIVR(音声自動応答装置)でいったん応答。両コール・センターのオペレータの状況などに応じて,適切に振り分ける。

 このような運用体制に切り替えたことで,「セキュリティ面が大幅に向上した」(井上洋一IT戦略部IT戦略課マネジャー)。従来システムは,コール・センターと同じビル内の一室に設置し,利用部門も運用を担っていた。データ・センターに設置した現在は,同社のシステム部門が責任をもってサーバーを運用する。

 最新のサーバーに一新したことなどにより,通話データを保存する時間を短縮する効果も得られた。「利用部門は利用に徹することができるようになった」(濱根東京コールセンター長)。

機能不足をカスタマイズや運用で補う

 IP化によってメリットを得た一方で,いかに従来のコール・センター並みの使い勝手を確保するかという点には苦心した。「長年,実績のある米アバイアのCTIシステムをカスタマイズして使っており,新たなIPコール・センターのシステムが機能面で見劣りするのは分かっていた」(濱根東京コールセンター長)。導入前から補完する必要があると考えていたのだ。

 例えば,オペレータの状態や着信状況を確認するデータの更新間隔。シスコの管理ツールをそのまま使うと,20秒ごとの更新となる。しかしこれでは,「管理画面を見て着信があるとオペレータに注意を促したら,とっくに電話が切れていたといった事態が頻発しかねない」(濱根センター長)。従来使っていたシステムでは,数秒程度でデータを更新していたという。

 そこで,インテグレーションを担当した日本ヒューレット・パッカードにカスタマイズを依頼。最終的に更新間隔を10秒に短縮して導入した。

 運用の工夫で対処したところもある。一例は,電話の転送時の応対だ。従来のシステムでは転送ボタンを押すと同時に自動的に保留音が流れた。ところが新システムでは保留音を流さず,転送先が応答するまで,転送元の受話器からの音が通話の相手に流れる仕様になっていた。

 システムを改修するのは作業が大がかりになると判明し,見送った。代わりに,オペレータが通話を転送する際に,転送ボタンと併せて音を消すミュートのボタンも押すことにした。

東京と大阪でデータ出力を分けたい

写真3●コール・センター用システムの画面
写真3●コール・センター用システムの画面
 管理ツールを使ったデータの出力・表示形式にも課題があるという(写真3)。現状では対応の内容を「一次電話応対」「支店の受注処理」といった役割別でまとめて出力することはできるものの,このデータをさらに東京と大阪のセンター別で分類して出力できない。同じ一次電話応対でも,応答にかかる平均時間などの傾向が東京と大阪で異なる可能性がある。現状ではそれを簡単にチェックできないわけだ。

 そこでオペレータに割り当てるユーザーIDの体系を東京と大阪で変え,そのIDごとに抽出するという運用で対処している。ただこの方式は,より詳細にデータを分析したい場合に向かない。「今後のバージョンアップなどで改善したい」(濱根東京コールセンター長)としている。