第9回 コンタクトセンターの科学：「大きいことはよいこと」

前々回、前回とアーランの基礎を学びました。すでにご活用されていますでしょうか？
エージェント数の算出だけてなく、例えば、IVRに必要なポート数（回線数）を求めることにも応用できます。

さて、今回は、前回学んだ内容を応用してみましょう。はじめてこの連載を読まれる方は、前回分を先におさらいして下さい。

大きいことはよいこと

前回学んだアーランを使って、１つの大きなサイトと３つの小さなサイトを数学的に比較してみましょう。
同じスキルの電話を受けるのに、ある条件下でシングルサイトと３つのマルチサイトで対応する場合とで、どのような違いがあるでしょうか？

以下の条件で考えてみましょう。

同じサーベルレベルを維持するのに、シングルサイトでは６３人のエージェントで済むのに対し、マルチサイトは、２３ｘ３＝６９人のエージェントが必要となります。
その差、なんと ６９－６３＝６人になります。ピーク時に６人ものエージェントが少なく済むということは、センターにどのようなメリットがありますでしょうか？

逆に、シングルサイトに必要な６３人で、マルチサイトで対応したとすると、サービスレベルは、58％にしかなりません。

ばらばらのセンターでばらばらに受けるより、まとめた方がよいのです。
これがスケールメリット、つまり、大きいことは良いことということなのです。

５分で理解するアバイアのIP PBXとは？

ちょっとだけ話が脱線しますが、この後に話すことに関係があるので先に説明させて下さい。

今のアバイアのIP PBX、Avaya Aura Communication Managerの前身に、DEFINITY（ディフィニティー）というPBXがありました。この時代のPBXは、呼制御をするプロセッサー（CPU部分、人間で言うと頭にあたる）と、電話機や局線を収容するパーツ（手足にあたる）が、１つのボディーに収められていました。そのため東京と大阪にそれぞれセンターがある場合、東京に１セット、大阪に別の１セットを用意する必要がありました。

ここにIP PBXビックバンが起きました。頭にあたる部分と手足にあたる部分を分離しIPネットワークで繋ぐ構造になりました。これにより、ネットワークさえ繋がっていれば、頭と手足を別々の場所に置くことができるようになったのです。

言い換えれば、1箇所のサイト（例えばデータセンターや東京）に頭をおいてしまえば、他の場所にあるサイトには手足を置くだけでよくなりました。
複数サイトがあっても、実は1つの頭だけで対応できる。言うなれば、マルチサイトだけど、バーチャルなシングルサイト - 分散型IPコンタクトセンターなのです。

物理的にはマルチサイトですが、システム的にはシングルサイト（１つのシステム）であるがゆえ、CMSは１台ですみます。コールフローもサイト共通で持つこともできますし、１つのスキルの電話をサイトでまたがって対応できるようになります。ハードやライセンスなども圧縮できるので、コストも下げることができるでしょう。

この仕組みでは、「頭と手足の間のネットワークが切れたらどうなるのか？」、「障害に弱いのでは？」という疑問を持たれる方もいらっしゃいますでしょうが、ご安心下さい。もちろん、考えられています。

頭と手足の間のWANのネットワークを二重化することが可用性をあげることはもちろんなのですが、手足にあたるゲートウェイには、"小さな頭"をつけることができます。この"小さな頭"で、ネットワーク障害時にメインの頭と通信ができなくても呼を処理することができます。また、サーバー側（頭）の方も２重化構成がとれます。さらに、頭の分身を他のサイトに置く構成をとることもできるのです。メインが障害のときは、分身が代わりに呼処理をします。

スケールメリットを生かそう

分散型IPコンタクトセンターがどのようなものかお分かりになりましたでしょうか？
ではここで話を元に戻して、スケールメリットを生かすためにはどうしたらよいでしょうか？
３つ考えることができます。

①マルチスキル化で、エージェントプールを大きくせよ。

まずは、マルチスキル化です。１人のエージェントが複数のスキルを持つことにより、全体で１つの電話に対する受け皿（エージェントプール）を大きくすることができます。

②複数サイト（複数PBX）ならばBSRでバーチャル化せよ。

これは物理的にもシステム的にも複数のサイト（複数のシステム）の場合、アバイア同士のPBXであれば、バーチャルルーティング機能の１つBSR（Best ServiceRouting：ベストサービスルーティング）を利用できます。この機能を使えば、複数サイトをあたかも１つのセンターとして振舞うように呼をルーティングすることができます。

③バーチャルなシングルサイト（分散型IPコンタクトセンター）を利用せよ。

これはIP PBX、分散型IPコンタクトセンターを使った場合になります。拠点は複数あるが、それを１台のIP PBXでカバーします。そのようにすれば、結局シングルサイトと同じことになります。同じスキルの電話をサイトにまたがって受電するため運用の問題をクリアする必要があるかもしれませんが、スケールメリットを十分に活用することができるでしょう。

コンタクトセンターをネットワーク化しこれらを利用することで、できる限りリソースを有効活用し、お客様を少しでもお待たせせず、スケールメリットで高いパフォーマンスを追及できるでしょう。

ロケーションIDを利用しよう

さて、ここからはCMSのレポートのお話です。
バーチャルなシングルサイトの構成の場合、１つのスキルが複数のサイトで受電されることになります。ここで１つ問題が出てきます。その１つのスキルがサイト毎に何件応答されたかをどうやって知るのでしょうか？

ここで利用できるのがロケーションIDです。ロケーションIDとは、電話機がどこのロケーションに所属しているかがわかるIDのことです。エージェント電話機にログインすると、ロケーションIDがCMSに渡されます。
では、これを利用しどのように求めるのかというと、方法は２つあります。
１つは、CMSのエージェントのテーブルを利用します。エージェントテーブルには、エージェントが、どこのロケーションIDにログインして、どのスキルで、何件応答できたかの情報を持っています。これを利用すれば、ロケーションIDをキーにして、サイト毎何件応答されたのかを計算することができます。なお、スキルやVDNのレポートには、ロケーションIDを含まないため、計算することはできません。

２つめの方法は、ECHのデータを利用します。ECHのデータは、呼ごとの明細情報となり、いつ・誰が・どのスキルで・どのロケーションでという情報を含んでいます。これを利用すれば、サイト毎（ロケーション毎）に応答した件数を計算することができます。
※ECHについては、この連載の第１回、2回を参照して下さい。

１つのシステムでもサイト毎に応答するスキルを分けたい

実は、先に説明したBSRは、複数のPBXをあたかも１つのPBXのようにするだけでなく、複数のスキルをあたかも１つのスキルかのごとく、ルーティングすることもできるのです。
これを利用すれば、物理的なサイト毎に、応答するスキルを分けることができます。１つの内容の電話をサイト毎（スキル毎）にCMSでレポートすることができます。

おわりに

さて、今回は基礎を使って応用してみましたが、いかがでしたでしょうか？
次回もアーランを使った別の応用を考察してみたいと思います。

第10回

「今さらですがCTIを使いたい！」
－CTIをもっと使え（前半：理論編）