はじめに
Googleがどのように私たちのために「全員」になろうとしているのかを背景に、他の企業があきらめずに新しいサービスやテクノロジーの開発を続けているのは素晴らしいことです...
先週マイクロソフトを訪問した後、 マイクロソフトカスタマーケアフレームワークについての話を聞いて楽しみました。 さらに、このシステムの主要な設計者の1人と話をすることができました。
システムについて
それがどのようなシステムであり、何と一緒に食べられるかについて簡単に説明します。
マイクロソフト自体は、そのシステムを次のように説明しています。
Microsoft Customer Care 2009（CCF）は、複合アプリケーションを配信するためのエンドツーエンドのソフトウェアインフラストラクチャです。 システム（システム）には、アプリケーション開発用のコンポーネントとランタイムコンポーネントの両方が含まれています。 CCFベースのアプリケーションは、さまざまなエンタープライズアプリケーションに分散された顧客情報への統合されたアクセスを提供し、顧客とのさまざまな対話モードを集約します。 © MSDNからの無料翻訳 。
危機にwhatしているものを理解しやすくするために、「指で」説明するようにします。
典型的なシナリオ
巨大な銀行のサポートサービスの従業員を想像してください。 マイク付きのヘッドフォンに座って、怒っているクライアントから電話がかかってくるのを待っています。 理論的には、クライアントはどんな問題でも呼び出すことができます。 彼はプラスチックカードでブロックされている可能性があります。新しい預金の条件などの詳細を明確にするために、ローンでいくら支払う必要があるかを調べたいと考えています。 通常、銀行には、サービスまたはサービスのグループに対して異なるUIを持つ異なるアプリケーションがあり、承認されたユーザーのアカウントが異なる場合があります。
次に、画像を想像してみましょう...クライアントが上記の問題の1つ（および、おそらくいくつかの問題）を呼び出しています。 彼はサポートの従業員によって答えられます。 彼は、目的のアプリケーションを見つけて起動するまで1分間待つように要求します。 それからもう一分、なぜなら 彼はこのシステムのアカウントでログインする必要があります。 それからもう一分、なぜなら 従業員が選択したアプリケーションでミスを犯しました。 そして、ここに待望の瞬間が来ます...サポートサービスの従業員は、この質問に答えることができず、通話を別の部門にリダイレクトする必要があることに突然気付きました... 。 さて、誰が電話で10分間ハングアップし、同じ問題を3回完全に異なる人々に説明したいのでしょうか？ ところで、あなたの一人がすでにクライアント側で同様の状況にいることに気付いた可能性は十分にあります。 銀行が単にあなたについて気にせず、顧客を気にしないという気持ちはありませんでしたか？
私たちは顧客を大切にします
上記のシナリオで発生する多くの問題を解決するために、Microsoftは、サポートデスクの従業員がクライアントと連携するために必要な多くの社内アプリケーションのすべてをAgent Desktopと呼ばれる単一のユーザーウィンドウに結合できる概念を開発しました。
同時に、システム自体とプラットフォームの両方には、非常に便利なプロパティと機能が数多くあります。 私の意見では、それらの中で最も重要なものを以下にリストします：
- SSOサポート
- オペレーターが必要とするすべてのアプリケーションのUIは、異なるタブの1つのウィンドウに表示されます
- 統合はUIレベルで行われるため、統合アプリケーションの開発は非常に高速です。
- プラットフォームの最も重要な部分にはオープンソースが付属しています
- クライアントコンテキストは、さまざまな統合可能なアプリケーションで使用できます。
- システムはさまざまな通信手段を組み合わせています
- システムは簡単に拡張できます
そして、各アイテムについてさらに説明します。
シングルサインオン
オペレーターがアクセス用に1つのログインとパスワードのみを入力するという事実により、多くの多様なアプリケーションを入力するのに必要な時間が大幅に節約されます。
シングルUI
UIを組み合わせることにより、オペレーターはアプリケーションを切り替える必要がありません。 クライアント、問題などの一般的なコンテキスト情報を含め、すべての情報が1つのウィンドウに便利に配置されます。少し「待ち伏せ」がある場合があります。 アプリケーションが高解像度用に設計されている場合、Agent Desktopのタブに配置すると、スクロールバーが表示される場合があります。 これはオペレーターにとって不便かもしれません。
迅速な統合
アプリケーションの統合は主にUIレベルで行われるため、統合メカニズムを詳細に説明する必要はありません。 基本バージョンでは、何もプログラミングする必要はありません。 アプリケーションとコンテキスト間の情報交換を保証する必要がある場合、プログラミングが必要です。 この場合、.Netアダプターが機能します。これは、アプリケーションのユーザーインターフェイスと対話し、情報を抽出して配置することができます。
オープンソース
はい、マイクロソフトはパートナーと会う準備ができており、プラットフォームの一部のソースコードを提供します。これにより、最も洗練された統合方法を実装できます。 私の理解では、Agent Desktopのソースコードについて話しているところです。 たぶん何か他のもの。
クライアントコンテキスト
クライアントのコンテキストは、統合アプリケーションが相互に交換できる最も一般的な情報です。
通常、コンテキストは、メインウィンドウの上部、統合アプリケーションのタブを結合するフレームの上にある個別のエージェントデスクトップフレームに表示されます。 情報の構成とそのタイプは、開発者が決定します。
マルチチャネル通信
このシステムは、顧客からのリクエストが来るさまざまなチャネルを統合することもできます。 これは、電子メール、インスタントメッセージング、 IVR 、SMSなどです。
このアプローチにより、すべての情報フローを1か所に保存し、それらにすばやく簡単にアクセスできます。
スケーリング
CCFは、マルチスレッドの最新の要件を考慮して、標準のMicrosoft Composite Application Blocksに基づいて構築されています。 データベースレベルとアプリケーションサーバーレベルの両方が簡単にクラスター化されるため、システムは24 * 7モードでの中断のない動作を保証し、多数のユーザーとの作業時に高い負荷に耐えることができます。
技術的な詳細
実際、私は実際的な経験がないため、多くの技術的な詳細を説明することはできません。 しかし、アーキテクトと話をする過程で私が捉えた要素がいくつかあります。 まず、CCFはフレームワークであり、単なるアプリケーション/システムではないことを明確に理解する必要があります。 つまり、システムを作成できるツールのセットです。 多くの既製のモジュール、メカニズム、拡張機能などがあります。 また、マイクロソフトは開発者の面倒を見て、多くの詳細を熟考し、できるだけ多くの既存のアプリケーションと統合するための既製のツールを作成しました。
MS CCFに基づいて作成されたアプリケーションは、最新のマルチレベルアプローチを考慮して構築されます。
データベース
予想どおり、Microsoft SQL Serverをデータベースとして使用することが提案されています。 すでにこの時点で、マイクロソフトはクラスターについて考えることを推奨しています。
データベースには、システムのユーザーのアクションおよび構成の監査に関する情報が格納されます。これは、システムの管理者によって更新されます。 さらに、着信コールを別のオペレーターにリダイレクトする必要がある場合、ユーザーのコンテキストはデータベースに保存されます。
アプリケーションサーバーレベル
アプリケーションサーバーレベルでは、データアクセスメソッド（いくつかのDALがあると仮定します）と、ビジネスロジックを実装します。ビジネスロジックは、視覚的な開発ツールを使用してWWFの観点から説明できます。
ユーザーインターフェース
UIは、Windows UIとWeb UIの両方の他のアプリケーションのメインウィンドウを（タブ-タブストリップコントロールで）描画できる古典的なWindows .Netアプリケーションです。 ソリューションの秘trickは、Agent Desktopが他のアプリケーションの呼び出しをラップして、（デフォルトで行われるように）Desktopではなく、Agent Desktop自体のブックマークに描画されるようにすることです。
データは、ウィンドウコントロール（Windowsアプリケーションの場合）またはHTTP-GET、HTTP-POST、SOAP（Webアプリケーションの場合）を介して直接交換されます。 このアプローチのおかげで、集約アプリケーションとその集約の間のインターフェースの調整は必要ありません。
繰り返しますが、アプリケーションは、親ウィンドウ（Agent Desktop）および統合が行われる他のアプリケーションの存在について何も知らない可能性があることに注意してください。 厳密な標準に従って、または厳密なプロトコルのサポートを使用して作成する必要はありません。 最も一般的なウィンドウ、Webアプリケーション、または会社で長年使用されているコンソール端末マシンでさえあります。 なんらかの形でそれらを適応または書き換える必要はありません。 すべては自分自身で透過的に行われます。
おわりに
説明からわかるように、MS CCFに基づいて構築されたシステムは、時間を大幅に節約し、顧客の要求に対応するプロセスでのエラーの数を減らすことができます。 これは、サービスコストの削減と顧客満足度の向上を意味します。 一般的に、このことは私にとってかなり面白そうに思えました。 まず第一に、その興味深い点は、私の意見では、元のアイデア-UIレベルでの統合です。 実際、ここでは氷山の一角だけを説明しました。 BizTalk、SOAインフラストラクチャなどとの統合に関連するCCF機能については触れませんでした。 合計であり、この記事のフレームワークではカバーされていません。 より現実的なアプリケーションのどこかに「タッチ」し、アプリケーションの詳細を既に共有できることを願っています。 最後まで読んでくれてありがとう。
PS：上記のプラットフォームについて詳しくは、 こちらをご覧ください 。
技術記事はこちら 。