JP2003108650A - コールセンタシステムおよび応対者選定方法およびリクエストに対する対応者選定のためのコンピュータプログラム - Google Patents

Abstract

(57)【要約】 【課題】問い合わせや要求発生、あるいは支障発生等に
対して、的確な人選をして対応させることができるよう
にしたコールセンタシステムを提供すること。 【解決手段】クライアント側から発せられた要求内容情
報を持つリクエスト情報を受信する受信手段１１１と、
この受信手段にて受信されたリクエスト情報における要
求内容に対処させるべき人員の条件が要求内容情報別に
予め定められると共に、前記受信されたリクエスト情報
の持つ求内容情報から前記条件を取得する条件取得手段
１１３と、リクエスト情報における要求内容に対処させ
るべく待機する複数の人員各人のスキル情報およびその
各人の端末情報とを保持するデータベース１２０と、条
件取得手段にて取得された条件に適合する人員を前記デ
ータベースから検索する検索手段１１４と、この検索手
段により検索された人員に対処させるべく、リクエスト
情報を当該人員の端末に転送する転送手段１１５とを具
備する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、問い合わせや要求
に対して、それに対処する人員各人の有するスキルや人
員配置に応じた最適な人を選定して対処させることがで
きるようにしたコールセンタシステムおよび応対者選定
方法およびリクエストに対する対応者選定のためのコン
ピュータプログラムに関する。

【０００２】

【従来の技術】商業、工業等のあらゆる産業分野におい
て、情報を収集して活用したり、あるいは顧客から問合
わせに応じて必要な情報を迅速に提供する業務が極めて
重要である。例えば、コールセンタと呼ばれる顧客から
の問合わせに対応するためのサービス機能を持つ組織を
多くの企業が提供している。

【０００３】コールセンタには、顧客からの問合わせに
対して的確な対応ができる能力を持つ対応員が集中して
配備されており、各問合わせ毎に最適な対応員が回答す
るというようになっている。そして、電話やＦａｘでの
問合わせおよび回答を行うだけではなく、近年ではイン
ターネットの普及に伴い、コンピュータネットワークを
利用することで電子メールやＷｅｂシステムを利用して
の問合わせおよび回答ができるようにした技術も既に提
供されている。

【０００４】その一例として、いくつかの従来技術とそ
の問題点を以下に説明する。

【０００５】まず、特開平９−２６９７４６号公報に開
示された「顧客情報システム」の技術を取り上げてみ
る。この技術は、電話、葉書、Ｆａｘ、インターネット
など様々なメディアを利用して送られてくる情報を容易
に管理し、柔軟な管理ができるようにすることを目的と
したものである。

【０００６】そのため、こうしたバラバラの情報源を、
音声−テキスト自動変換、手書き文字−テキスト自動変
換、などを用いて、すべて電子的なテキスト情報に変換
した後に一括管理する。しかし、この発明では情報収集
の技術を提供しているだけで、問合わせ事項が含まれて
いた場合への対応手段を何ら提供していない。

【０００７】次に、特開平１０−９０３３７号公報に開
示された「相談システム」の技術を取り上げてみる。こ
の技術は、Ｗｅｂ上での相談システムを柔軟化するため
の技術である。複雑な問合わせをＷｅｂ上で行いたい場
合、通常レベルのユーザでは処理方法が分らない事態が
発生する。この「相談システム」では、特殊なボタンが
用意されており、どうしても解らないことがあればその
ボタンを押すと、相談員のところに自動的に電話がかか
り、電話による直接の質問、相談が可能となるという技
術である。

【０００８】しかし、着信を受けた相談員が必ず対処で
きるとは限らない。状況によって適切な回答ができる相
談員は異なるからである。この技術は、どういう事態に
どの相談員が対応すべきかを考慮していないことから、
相談に対して適切な回答を下せるまでに時間を要する事
態が発生する場合がある。

【０００９】次に特願平５−１９１２２５号公報に開示
された「電話を用いた在宅勤務システム」の技術を取り
上げてみる。この技術は、テレマーケティング業務をオ
ペレータが在宅で行えるようにしたシステムであり、登
録してあるオペレータが自宅から電話でテレマーケティ
ング業務を行うようにしたものであるが、オペレータと
顧客との間だけではなく、管理センタとの間でも交信を
行うようにして一種の３者通話状態にし、これにより、
管理センタで常に顧客とのやりとりをモニタでき、管理
センタの管理の元にオペレターに指示を出すことができ
るようにしたものである。そして、必要があれば、通話
に割り込んで対処することができるものであるが、付加
的な機能として、業務時間中にオペレータ自宅にかかっ
てきた電話は、自動的にセンタの留守電話に入るように
なっている。

【００１０】しかしながら、オペレータの業務知識レベ
ル（スキル）に応じて対応する技術が提供されていない
から、オペレータのスキルを超えた場合には、管理セン
タでその都度対応しなければばらないこととなって、管
理センタの負担が増大する。

【００１１】

【解決しようとする課題】顧客からの問い合わせに対し
て、的確な対応ができるようにコールセンタでは、問合
わせに対して的確な対応ができる能力を持つ対応員を配
備している。そして、電話やＦａｘでの問合わせに対し
て回答するだけでなく、コンピュータネットワーク利用
による電子メールやＷｅｂシステムを利用しての問合わ
せおよび回答ができるようにした技術も既に提供されて
いる。

【００１２】しかし、問い合わせに対して、的確に対応
できる回答者は、問い合わせ内容と各回答者の持つ力量
により異なるものとなり、応対要員（相談要員）として
確保されている人員ならば誰でも良いと云うわけではな
い。要求や問い合わせをたらい回しにしたり、必要以上
に対応に時間がかかることのないように、的確な人選を
して対応することが迅速なサービス提供、サポート環境
提供の上で必要不可欠であるが、そのような的確な人選
をして対応させることが可能なサポート機能は実現され
ていない。

【００１３】そこで、この発明の目的とするところは、
問い合わせや要求発生、あるいは支障発生等に対して、
的確な人選をして対応させることが可能なサポート機能
を有するコールセンタシステムおよび応対者選定方法お
よびリクエストに対する対応者選定のためのコンピュー
タプログラムを提供することにある。

【００１４】

【課題を解決するための手段】上記目的を達成するた
め、本発明は次のように構成する。すなわち、 ［１］第１には、本発明は、クライアント側から発せら
れた要求内容情報を持つリクエスト情報を受信する受信
手段と、この受信手段にて受信されたリクエスト情報に
おける要求内容に対処させるべき人員の条件が要求内容
情報別に予め定められると共に、前記受信されたリクエ
スト情報の持つ求内容情報から前記条件を取得する条件
取得手段と、前記リクエスト情報における要求内容に対
処させるべく待機する複数の人員各人のスキル情報およ
びその各人の端末情報とを保持するデータベースと、前
記条件取得手段にて取得された前記条件に適合する人員
を前記データベースから検索する検索手段と、この検索
手段により検索された人員に対処させるべく、前記リク
エスト情報を当該人員の端末に転送する転送手段とを具
備する。

【００１５】このシステムは、受け取ったリクエストの
内容を解析し、対応方法を自動判別する。リクエストを
受けると、リクエストの対応方法がシステム内で自動判
別される。判定するための情報はリクエストに含まれる
情報を利用する。

【００１６】リクエストの対応方法とは、そのリクエス
トに含まれる要求内容情報に対して対処できる人員の条
件を得る、該当の人員を決定することであるが、それは
登録された人員各人のスキルを元に選定する。

【００１７】本システムは、アラームや要求、問い合わ
せなどの要求内容情報を含むリクエストを受けたとき、
複数の人員の中から能力や資格などの情報を元に適切な
対応者を選択してその人員の操作端末にリクエストを転
送するようにしてその人員に対処を任せるようにする。

【００１８】すなわち、この構成によれば、リクエスト
に対応するために必要なスキルをキーとして、対応でき
る人員を検索することにより、適切な人員を選び、その
人員に当該リクエストの対応をさせることができる。従
って、それにより、クライアント側に対しての対応がよ
り的確になり、しかも迅速に対応できてサービス向上に
寄与するコールセンタシステムが得られる。また、この
ことから、クライアント側に対しての対応の質向上につ
ながる。

【００１９】［２］また、前記［１］項の構成におい
て、前記データベースは資格、経験年数、職能、職種の
うち、いずれか１つ以上から構成される情報を各人の前
記スキル情報として保持することを特徴とする。

【００２０】この構成によれば、前記［１項記載のコー
ルセンタシステムの効果に加えて、上記のスキルの項目
を複数定義することができる。たとえば資格、経験年
数、職能、職種などの中から２つ以上の項目を指定する
ことができる。それにより、より木目細かく相談の対応
をすることができるコールセンタシステムが得られる。

【００２１】［３］また、前記［１］項の構成におい
て、前記データベースの保持する各人の前記スキル情報
を変更可能な変更手段を有し、各人の前記スキル情報に
変更可能に構成したことを特徴とする。

【００２２】この構成は変更手段を有しており、スキル
情報の構造やデータを編集することができる。そのた
め、リクエストの内容対応に対処させるべき人員に必要
なスキルを定義し直すことができる。また、複数の定義
が可能になり、スキルを示すデータの変更、定義の変更
も可能になる。そして、このことにより、リクエストの
対応方針が変更されても、システムの変更は最小限に押
さえることができるシステムとなる。

【００２３】すなわち、この構成によれば、前記［１項
記載のコールセンタシステムの効果に加えて、スキル情
報を追加変更することができるシステムとなることか
ら、リクエスト情報における要求内容に対処させるべく
待機する人員各人のスキルが向上した場合にでもシステ
ムを容易に最新情報で対応させることができる。また、
リクエスト情報における要求内容に対処させるべく待機
する人員に新規参加や離職などによる変化が生じた場合
にも動的に対応できる効果が得られる。

【００２４】［４］また、本発明は、クライアント側か
ら発せられる各種の要求内容対応に当該各要求内容に対
処させるべき最適人員の条件をそれぞれ要求内容情報別
に予め定めて保持させると共に、前記リクエスト情報に
おける要求内容に対処させるべく待機する複数の人員各
人のスキル情報およびその各人の使用する操作端末の情
報を保持させ、クライアント側から発せられた要求内容
情報を持つリクエスト情報を受信すると、この受信され
たリクエスト情報における要求内容情報をキーとして抽
出し、抽出された情報をキーに、前記保持させてある前
記予め定めた前記要求内容情報別最適人員の条件中から
該当条件を検索し、得た条件に合う人員を前記保持させ
た各人のスキル情報中から抽出してその抽出した人員の
使用する操作端末に前記リクエスト情報を転送すること
により、そのリクエストに対する対応を前記抽出した人
員に割り当てることを特徴とする。

【００２５】この構成によれば、リクエストに対応する
ために必要なスキルをキーとして、対応できる人員を検
索することにより、適切な人員を選び、その人員に当該
リクエストの対応をさせることができる。従って、それ
により、クライアント側に対しての対応がより的確にな
り、しかも迅速に対応できてサービス向上に寄与するコ
ールセンタシステム用の応対者選定方法を提供できる。
また、このことから、クライアント側に対しての対応の
質向上につながる。

【００２６】

【発明の実施の形態】本発明は、顧客からの各種問い合
わせ、監視システムからのアラームなど、リクエストの
効率的解決を可能にするものであって、コンピュータネ
ットワークを用いた各種情報処理システムであり、実施
に当たって （１）応対者（相談員）のスキルに応じて自動的に振り
分ける。 （２）応対者の増加、削減、異動に自動的に対応でき
る。 （３）さまざまな業種のスキルに対応する。 （４）既存のシステムとの連携をする。 の４点をベースにしたものである。

【００２７】以下、本発明の実施の形態について、図面
を参照して説明する。

【００２８】図１に本発明システムの構成例を示す。図
において、１０は最適候補選定システムであり、コール
センタ側のシステムである。また、２０はクライアント
側システム、３０はオペレータ群である。

【００２９】これらのうち、クライアント側システム２
０は、専門家による対応を必要とするような問い合わせ
や要求等の発生、あるいは異常事態報知などをするもの
であり、最適候補選定システム１０はこの問い合わせ等
に対して応対させるに最適なオペレータをオペレータ群
３０中から選択して、その選択したオペレータの端末に
接続するものである。クライアント側システム１０はク
ライアントのパソコンなどのインテリジェント通信端末
やあるいは監視対象設備群の各種警報装置やモニタ装置
などが考えられる。

【００３０】オペレータ群３０は前記の問い合わせや警
報等に対して、対応できる人員群であるが、実際には最
適候補選定システム１０にネットワーク接続されたパソ
コンなどによる複数台のインテリジェント端末群であ
り、この各インテリジェント端末に人員が配置された場
合に、配置についた人員がそのインテリジェント端末に
よる応対者となるようにしたものであって、その応対者
の持つスキル（力量、技術力、分野別能力など）対応
に、クライアント側からの問い合わせ等に従って、最適
候補選定システム１０は応対者を人選してその選択した
応対者のインテリジェント端末にクライアント側を繋ぐ
といったことを行うようにしてある。

【００３１】クライアント側システム２０が監視対象設
備群である場合には、どの設備からのどの種の要請ある
いは状態報知かにより、最適候補選定システム１０は応
対者を人選してその選択した応対者のインテリジェント
端末にその内容等や対象を知らせるようにしてある。

【００３２】あくまでも一例であるが、クライアント側
システム２０からの前記問い合わせや要求等、あるいは
異常事態報知などの情報は、ここではそれを所定のフォ
ーマットによるリクエストなるテキストファイル形式で
最適候補選定システム１０に通知されるものとする。通
知は伝送路を介して行われる。

【００３３】最適候補選定システム１０はこのリクエス
トを受け取るためリクエスト・レシーバ１００を有して
おり、更に、この受け取ったリクエストを元に応対者を
人選する機能を得るために、リクエスト・プロセス・エ
ンジン（Ｒｅｑｕｅｓｔ Ｐｒｏｃｅｓｓ Ｅｎｇｉｎ
ｅ）１１０と、オペレータ情報やオペレータの選択など
に用いる各種情報・条件などを収めたデータベース１２
０からなる。なお、ここで云うオペレータとは相談員あ
るいは保守管理者といった応対者のことを指すもので、
前記リクエストによる問い合わせや警報等に対して、対
応できる人員である。

【００３４】ここに示す例に限るものではないが、デー
タベース１２０は、概念的に考えると例えば、図５，図
６，図７の如きの内容を収めたものと考えることができ
る。図５はリクエストの種類とオペレーションのための
条件を格納したテーブルであり、図６は、オペレーショ
ン実行条件を検索するためのテーブルであり、図７はオ
ペレータのプロファイルデータを収めたデータベースで
ある。

【００３５】ここで、オペレーションとは、リクエスト
にて要求される実行対象を示すものであり、オペレータ
にどのような処理が必要か伝えるために使用される。

【００３６】リクエスト・プロセス・エンジン１１０
は、リクエスト・レシーバ１００がクライアント側シス
テム２０から受けたリクエストを元に、データベース１
２０に基づいてそのリクエストに応答するに適したオペ
レータを選択するといった機能を有する。また、その選
択したオペレータに前記リクエストを取り継ぐといった
機能を有する。

【００３７】ここで最適候補選定システム１０はコンピ
ュータにより実現されるものであって、リクエスト・レ
シーバ１００を含め、リクエスト・プロセス・エンジン
１１０も、ソフトウエアで実現されているが、これは例
えば、プログラミング言語の一つであるＪａｖａ（Ｓｕ
ｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ；サンマイクロシステム
ズ社の商標）で記述されて実現されている。そして、リ
クエスト・プロセス・エンジン（Ｒｅｑｕｅｓｔ Ｐｒ
ｏｃｅｓｓ Ｅｎｇｉｎｅ）１１０は、機能ブロックで
区分して示すと図２に示す如く、リクエスト受信部１１
１、ワークフロー管理モジュール１１２、リクエスト条
件取得モジュール１１３、検索モジュール１１４、検索
結果転送モジュール１１５から構成される。

【００３８】これらのうち、リクエスト受信部１１１
は、リクエスト・レシーバ１００からリクエスト・プロ
セス・エンジン１１０に転送されてきたリクエストを受
信する役割を持つモジュールであり、リクエスト・プロ
セス・エンジン１１０の入力口としての役割を担うもの
である。

【００３９】また、ワークフロー管理モジュール１１２
は、別途用意された処理手順の定義書に記載された処理
手順を読み込む機能を持ち、その手順に従って処理の順
番を管理して処理手順の定義書に記載されたとおりに処
理を進める役割を果たすモジュールである。１つの例と
して、処理手順の定義書をＸＭＬ（Ｅｘｔｅｎｓｉｂｌ
ｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ（国際的団体Ｗｏ
ｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍが基
本仕様を策定したコンピュータ言語））に従った記述文
書とし、ワークフロー管理モジュール１１２にＸＭＬ文
書の読み込みと構造解析をするためのパーサ（Ｐａｒｓ
ｅｒ；ＸＭＬ文書がＤＴＤ（Ｄｏｃｕｍｅｎｔ Ｔｙｐ
ｅ Ｄｅｆｉｎｉｔｉｏｎ；ＸＭＬ文書において、ユー
ザ独自のタグを事前に設定し、文書構造を定義するため
の文書型定義）に従っているかどうか妥当性の検証とＤ
ＴＤの構文解釈を行い、ユーザーが利用可能な構造に変
換する既製のアプリケーション・プログラム）なる既製
のソフトウエアを組み込むことで実現が可能である。ま
た、処理手順の定義書をスクリプト言語（例えば、ｐｅ
ｒｌ、Ｐｙｔｈｏｎ等）で記述し、それをワークフロー
管理モジュール１１２が実行する形式でも実現可能であ
る。

【００４０】リクエスト条件取得モジュール１１３は、
リクエストの記述の中からリクエストを処理するための
条件を取り出す機能を有するモジュールである。ここで
は、データベース中にハッシュテーブルのように保存さ
れている条件に対して、キー（Ｋｅｙ）を与え、バリュ
ー（ｖａｌｕｅ；値）を取り出すと云った処理を行うよ
うになっている。尚、検索用のキーは、リクエストのフ
ァイルの記述中から得、このキーを元に検索してバリュ
ーを得る。上記検索モジュール１１４は、バリューに適
合するオペレータ（応対者）を選択抽出するものであっ
て、リクエスト条件取得モジュール１１３により得られ
たバリューに適合するオペレータを、オペレータ情報の
データベース１２０を元に、ログイン状態にあるオペレ
ータ中から検索して得ると共に、得た情報（抽出したオ
ペレータ）をワークフロー管理モジュール１０２に渡す
ものである。具体的には、バリューから、その条件を満
たすオペレータをオブジェクトリファレンス（ポインタ
のようなもの）で受け取る役割を持つ。

【００４１】検索結果転送モジュール１１５は、リクエ
スト・プロセス・エンジン１００の出力口の役割を担う
ものであって、ワークフロー管理モジュール１１２か
ら、リクエストと転送すべきオペレータ（検索モジュー
ル１１４にて抽出された応対者）の情報を受け取るとそ
のオペレータのログインしている端末に、リクエストを
渡すという機能を有する。

【００４２】このリクエストを受け取ったオペレータの
端末は、リクエストに含まれている情報を所定のフォー
ムで画面に表示し、オペレータがこの画面の内容から自
己の知識に基づいて対処したり、あるいは回答や指示を
与えることができるようになっている。

【００４３】［作用の説明］次に上記構成の本システム
の作用を説明する。ここでは、クライアント側システム
２０として機器や設備を想定し、機器や設備に発生した
切り替え、実行の要求や障害等を、その情報を含む所定
の書式に則ったリクエスト（Ｒｅｑｕｅｓｔ）なるデー
タ（例えば、テキストデータ形式のデータ）として当該
機器や設備から伝送路により最適候補選定システム１０
に伝送されて来るものとする。

【００４４】このようなデータの送信は、クライアント
側システム２０としての機器や設備に、リクエストすべ
き事象が発生した段階で、それをトリガにその事象対応
の内容のリクエストを送出するように予め当該機器や設
備にそのための機能要素を設けておくことで、あるいは
その部署の勤務者が端末操作により手入力で作成して最
適候補選定システム１０に送信することで実現可能であ
る。

【００４５】最適候補選定システム１０ではこのリクエ
ストをリクエスト・レシーバ１００にて受け取る。する
と、リクエスト・レシーバ１００はこのリクエストをリ
クエスト・プロセス・エンジン１１０に渡し、リクエス
ト・プロセス・エンジン１１０は、このリクエストを元
に、当該リクエストに対して対処させるに最適なオペレ
ータを、ログイン中で対処可能な状況下にある多数のオ
ペレータ中から選択し、その選択したオペレータの端末
に渡す。すなわち、オペレータについては各人のプロフ
ァイル情報がデータベース１２０に予め登録してあり、
オペレータが業務に就いて自己の端末を最適候補選定シ
ステム１０にログインすると、そのログ情報が最適候補
選定システム１０に登録され、リクエストに対しての対
処可能な人員として有効になる。

【００４６】そして、リクエスト・プロセス・エンジン
１１０は、ログインされた端末を用いて業務に就いてい
るオペレータの中から、リクエストの内容に従って適任
のオペレータを選択し、その選択したオペレータの端末
に当該受け付けたリクエスト情報を送って対応させるよ
うにする。人選に当たっては、リクエストの内容に応じ
た資格などの条件に従い、条件を満たす人員を以て決定
する。リクエストの内容に応じた条件は、予め定めてお
き、人員のプロファイル情報を参照して条件に当て嵌ま
る者を抽出する。

【００４７】具体的に説明する。本システムでは、予め
処理手順の定義書を用意してこれをリクエスト・プロセ
ス・エンジン１１０におけるワークフロー管理モジュー
ル１１２に読み込ませることで本システムにおける処理
手順をコントロールできるようにする。処理手順の定義
書は、本システムにおける処理手順が記載された文書情
報で、例えば、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒ
ｋｕｐ Ｌａｎｇｕａｇｅ）による文書ファイルとして
用意され、ワークフロー管理モジュール１１２に読み込
ませておくことで、当該ワークフロー管理モジュール１
１２では、この手順に従った処理制御を行うことができ
るようにしている。

【００４８】図２の例では、この定義書は「処理の順
番、処理の主体となるモジュール：処理名」の書式で書
かれている。ワークフロー管理モジュール１１２はこの
ファイルを読み込み、そしてこのファイルに記載された
順序に従って処理の主導をとる。本例では、リクエスト
がシステムに届いてから、適切な対処法（本例では適切
なオペレータに転送する）を見つけて実行するまでの、
処理手順が定義されている。

【００４９】送られてきたリクエストをリクエスト・レ
シーバ１００が受け取ると、最適候補選定システム１０
におけるリクエスト・プロセス・エンジン１１０にこれ
が渡される。すると、リクエスト・プロセス・エンジン
１１０におけるリクエスト受信部１０１は、このリクエ
ストを取り込み、ワークフロー管理モジュール１１２に
渡す。ワークフロー管理モジュール１１２は、処理手順
の定義書に記載された処理手順に従って処理の順番を管
理して処理を進めるが、リクエストの内容からログイン
中の複数のオペレータのうち、適任の者を選定する。オ
ペレータ選択は次のようにする。

【００５０】＜オペレータ選択＞与えられたリクエスト
に対するオペレータ（応対者）の選択は次のようにして
実施できる。

【００５１】リクエストは“Ｒｅｑｕｅｓｔ”というオ
ブジェクト（プログラムの単位）、または構造体の形で
クライアント側システム２０からテキストファイルで送
られて来る。これを受け取ることになるリクエスト受信
部（ＲｅｑｕｅｓｔＲｅｃｅｉｖｅｒモジュール）１１
１にはこのリクエスト（Ｒｅｑｕｅｓｔ）を受信処理す
るように記述されたメソッドであるリクエスト・ノーテ
ィフィケーション（ＲｅｑｕｅｓｔＮｏｔｉｆｉｃａｔ
ｉｏｎ）メソッドが実装されており、送られてきたリク
エストに対してこれを受信処理することができる。ここ
で、メソッドとは、ある一つの機能を実現するためのプ
ログラムの断片で、クラス（幾つかの機能をひとまとめ
にしたモジュール）やオブジェクトに組み込まれている
関数である。

【００５２】図３に、当該リクエストに含まれるデータ
の一例を示す。図に示すように、リクエストのデータは
ゼネラル・インフォメーション（Ｇｅｎｅｒａｌ Ｉｎ
ｆｏｒｍａｔｉｏｎ）と、リクエスト・インフォメーシ
ョン（Ｒｅｑｕｅｓｔ Ｉｎｆｏｒｍａｔｉｏｎ）の２
つの部分に分けてある。

【００５３】これらのうち、ゼネラル・インフォメーシ
ョン（Ｇｅｎｅｒａｌ Ｉｎｆｏｒｍａｔｉｏｎ）は、
すべてのリクエストにおいて必ず含まれるデータであ
る。ゼネラル・インフォメーションには、例えば、“Ｎ
ａｍｅ ｏｆ ｔｈｅ ｔａｒｇｅｔ（対象名）”、
“Ｌｏｃａｔｉｏｎ ｏｆ ｔｈｅ ｔａｒｇｅｔ（対
象の位置）”、“Ｔｉｍｅ（時間（発生時刻））”、
“Ｔｙｐｅ ｏｆ ｄａｔａ（データ型）”、“Ｓｔａ
ｔｕｓ（ステータス）”、“Ａｄｄｉｔｉｏｎｌ Ｄａ
ｔａ（付加データ（履歴データ等））”などがある。

【００５４】このようなゼネラル・インフォメーション
は、“運転状況の通知”、“履歴データの送信”など、
このリクエストに対してオペレータによる何らかのオペ
レーション（オペレータによる何らかによる対処）を必
要としない場合に、このデータだけが送付される。

【００５５】また、リクエスト・インフォメーション
（Ｒｅｑｕｅｓｔ Ｉｎｆｏｒｍａｔｉｏｎ）は、たと
えば、“機器の故障”、“切り替え要求”、“動作承
認”などが発生した場合に送られる情報であって、リク
エストに対してオペレータによるオペレーションの必要
がある場合に送られるデータであり、誰に送れば良いか
を判断する種となる情報である“Ｔｙｐｅ ｏｆ Ｄｉ
ｒｅｃｔｉｏｎ”、“Ｒｅｑｕｉｅｒｄ Ｐｅｒｓｏ
ｎ”、“Ｐｒｉｏｒｉｔｙ”などが含まれている。

【００５６】リクエスト・インフォメーション中の“Ｔ
ｙｐｅ ｏｆ Ｄｉｒｅｃｔｉｏｎ”は変数であり、例
えば、図４の如きである。この図４の例では、“Ｔｙｐ
ｅｏｆ Ｄｉｒｅｃｔｉｏｎ”は、“機器Ａの修理要
請”、“機器Ｂのグループ切り替え”、“処理Ｃの実行
承認”、“装置Ｄの作動”といったものであるという例
である。

【００５７】リクエスト・プロセス・エンジン１１０で
は、リクエスト（Ｒｅｑｕｅｓｔ）を受け取ると、当該
リクエスト・プロセス・エンジン１１０の構成要素であ
るワークフロー管理モジュール１１２が、当該リクエス
トに含まれる変数“Ｔｙｐｅｏｆ Ｄｉｒｅｃｔｉｏ
ｎ”（図３、図４）の情報を取り出す。

【００５８】“Ｔｙｐｅ ｏｆ Ｄｉｒｅｃｔｉｏｎ”
変数は、リクエストを受け取ることとなったオペレータ
（すなわち、発生したリクエストに対して対処するのに
適任と判断されることとなった応対者）に行わせるべき
オペレーション（要求される実行対象）の内容を示して
いる。すなわち、オペレータにどのような処理が必要か
伝えるために使用される。

【００５９】また、運用上の仕組みとして、本発明では
各オペレーションには、そのオペレーションの実行が許
されるオペレータの条件が定められている。

【００６０】従って、オペレーションが必要なリクエス
トに対しての最適オペレータを選定するに当たっては、
オペレーションを実行するための条件に当て嵌まる人の
中から選ばねばならない。

【００６１】本実施例における前提として、“Ｔｙｐｅ
ｏｆ Ｄｉｒｅｃｔｉｏｎ”変数に含まれるデータの
値の種類はあらかじめ定められていると仮定する。“Ｔ
ｙｐｅ ｏｆ Ｄｉｒｅｃｔｉｏｎ”変数の中味となり
得るデータは図４の如きであったとして、このデータは
実際にはバリューとの関係で図５のような特定の対応関
係にある。そして、このデータは、テーブル化してデー
タベース１２０に格納しておいても良いし、オブジェク
トの中に埋め込んでおいても良く、いずれの方法でも
“Ｔｙｐｅ ｏｆ Ｄｉｒｅｃｔｉｏｎ”変数の中味を
キーに、対応のバリューを取得することができる仕組み
が得られる。

【００６２】図５のテーブルを用いた場合、リクエスト
・プロセス・エンジン１００では、“Ｔｙｐｅ ｏｆ
Ｄｉｒｅｃｔｉｏｎ”変数に含まれるデータの値をキー
に図５のテーブルで検索することによって、検索のキー
となるオペレーションに必要なスキルをバリュー（ｖａ
ｌｕｅ）として得る。

【００６３】図５のテーブルは、リクエストの種類（ｋ
ｅｙ）からバリュー（ｖａｌｕｅ）を検索するものであ
るが、オペレータ候補の条件を導き出すためのテーブル
となっている。“Ｔｙｐｅ ｏｆ Ｄｉｒｅｃｔｉｏ
ｎ”変数に含まれるデータの値の内容が“機器Ａの修理
要請”であった場合にはバリューとしては資格が“Ｐマ
スタ”で従事年数が“３”（３年）、役職は“−（問わ
ない）”という条件であり、“Ｔｙｐｅ ｏｆ Ｄｉｒ
ｅｃｔｉｏｎ”変数に含まれるデータの値の内容が“機
器Ｂグループの切り替え”であった場合にはバリューと
しては資格が“ＰマスタかつＱ技術者”でその職務に従
事した年数が“５”（５年）、役職は“−（問わな
い）”という条件であり、“Ｔｙｐｅ ｏｆ Ｄｉｒｅ
ｃｔｉｏｎ”変数に含まれるデータの値の内容が“処理
Ｃの実行承認”であった場合にはバリューとしては資格
は“−（問わず）”で従事年数が“１０”（１０年）、
役職は“課長”という条件であり、“Ｔｙｐｅ ｏｆ
Ｄｉｒｅｃｔｉｏｎ”変数に含まれるデータの値の内容
が“装置Ｄの作動”であった場合にはバリューとしては
資格は“−（問わず）”で従事年数が“５”（５年）、
役職は“−（問わず）”という条件であるという内容で
あることを示している。

【００６４】リクエストの内容である“Ｒｅｑｕｅｓｔ
Ｉｎｆｏａｔｉｏｎ”における“Ｔｙｐｅ ｏｆ Ｄ
ｉｒｅｃｔｉｏｎ”変数の中味として上述した４種類の
データを持ち得ると仮定すると、“Ｔｙｐｅ ｏｆ Ｄ
ｉｒｅｃｔｉｏｎ”の内容が４種類のうちのどれである
かにより、上述の中の対応のバリューが得られることに
なる。

【００６５】リクエストの種類（ｋｅｙ）からバリュー
（ｖａｌｕｅ）を検索できるように、これらの情報をオ
ブジェクトの中に埋め込んでおく方法は次のようにする
と良い。

【００６６】たとえば、プログラム言語としてＪａｖａ
を想定した場合、当該Ｊａｖａなどには実装言語に付属
する機能であるハッシュテーブル（Ｈａｓｈｔａｂｌ
ｅ）クラスのメソッドがあり、このハッシュテーブル
（Ｈａｓｈｔａｂｌｅ）クラスのメソッドではキーを与
えてバリュー（Ｖａｌｕｅ）を取得することができる。
これを利用すれば、キーに“リクエストの種類”、バリ
ューとしては条件として“資格”と“従事年数”、そし
て、“役職”を属性に持つオブジェクトあるいは構造体
を登録すれば良い。

【００６７】この場合でのテーブル内容は、図６に示す
如く、キー“機器Ａの修理要請”に対してバリューは
“Ｖａｌｕｅ＿ａオブジェクト”という名のオブジェク
トに格納されるデータであり、この“Ｖａｌｕｅ＿ａオ
ブジェクト”におけるオブジェクト内データとしては
“Ｐマスタ”，“３”，“ｎｏｎｅ”が格納してあり、
キー“機器Ｂグループの切り替え”に対してＶａｌｕｅ
は“Ｖａｌｕｅ＿ｂオブジェクト”という名のオブジェ
クトに格納されるデータであり、この“Ｖａｌｕｅ＿ｂ
オブジェクト”におけるオブジェクト内データとしては
“Ｐマスタ，Ｑ技術者”，“５”，“ｎｏｎｅ”が格納
してあり、キー“処理Ｃ実行承認”に対してＶａｌｕｅ
は“Ｖａｌｕｅ＿ｃオブジェクト”という名のオブジェ
クトに格納されるデータであり、この“Ｖａｌｕｅ＿ｃ
オブジェクト”におけるオブジェクト内データとしては
“ｎｏｎｅ”，“１０”，“ＧｒｏｕｐＬｅａｄｅｒ
（課長）”が格納してあり、キー“装置Ｄの作動”に対
してＶａｌｕｅは“Ｖａｌｕｅ＿ｄオブジェクト”とい
う名のオブジェクトに格納されるデータであり、この
“Ｖａｌｕｅ＿ｄオブジェクト”におけるオブジェクト
内データとしては“ｎｏｎｅ”，“５”，“ｎｏｎｅ”
が格納してある、という形式となる。これにより、キー
に対してどのオブジェクトを用いれば良いかが分かり、
その結果、選択したオブジェクトからオペレーション実
行条件を取得でき、図５のテーブル検索と同様の機能を
実現できたことになる。

【００６８】＜オペレータの検索方法＞このようにし
て、オペレーション実行条件が取得されたならば、この
条件に適合するオペレータを図７の如きオペレータのプ
ロファイルデータから検索して抽出する。このプロファ
イルデータはデータベース１２０に予め保存されている
が、ログインしているオペレータのプロファイルデータ
についてのみ、検索時での参照が可能となるように管理
されているものとする。

【００６９】ここで、図７に示すように、オペレータの
プロファイルデータ（オペレータのスキルデータ）は次
のような構造を持つ。図７の例ではオペレータとしてＩ
氏、Ｊ氏、Ｋ氏が任命されていたとして、そのうちのＩ
氏は資格として“Ｐマスタ”なるものを有しており、そ
の資格を活用しての職務経験年数である従事年数が
“２”（２年）であるが、役職は有しておらず、また、
Ｊ氏は資格として“Ｐマスタ”なるものと“Ｑ技術者”
なるものを有しており、その資格を活用しての職務経験
年数である従事年数が“６”（６年）であるが役職は有
しておらず、また、Ｋ氏は資格として“Ｑ技術者”なる
ものを有していて、その資格を活用した職務経験年数で
ある従事年数が“１２”（１２年）であり、役職は“課
長”である。このような内容を持つオぺレータのプロフ
ァイルデータが、図７に示すプロファイルデータであ
る。

【００７０】このプロファイルデータを用いてリクエス
ト・プロセス・エンジン１１０におけるオペレータ検索
モジュール１１４は、取得バリューに条件が合致する人
を選択する。具体的にはその取得したバリューを引数と
して、データベース１２０にオペレータ選出のためのメ
ソッド呼び出しを行う。その仕組みを説明する。

【００７１】基本的には、オペレータのプロファイルデ
ータ（スキルデータ）の持ち方としては、本例ではオブ
ジェクトのＴｒｅｅ（木）構造として保持し、従事年数
分類、資格分類、役職分類に分けて各分類から条件別に
細分化し、最後に該当のオペレータに行き着くようなか
たちにしている。例えば、従事年数分類であれば条件分
けとなる３年以上、５年以上の枝に細分化し、その細分
化された枝の末端に該当のオペレータの氏名を記述して
条件対応に枝を辿れば、該当するプロファイルを持つオ
ペレータに行き着くような構造にする。そして、従事年
数分類、資格分類、役職分類の各枝をバリュー対応に辿
ることで、それぞれの分類での該当オペレータがピック
アップされるので、検索モジュール１１４は全ての分類
に共通してあらわれるオペレータを最終的に条件を満た
すオペレータとして選択する。

【００７２】こうしてオペレータがピックアップされた
ならば、ワークフロー管理モジュール１１２は検索結果
の転送モジュール１１５にこれを渡し、当該転送モジュ
ール１１５はそのオペレータに対し、もとのリクエスト
を渡す。これにより、当該ピックアップされたオペレー
タの端末にリクエストが渡され、画面にリクエストの内
容が表示されて、当該端末のオペレータはこのリクエス
トに対する対処を実施することになる。

【００７３】＜Ｊａｖａによるオペレータの検索方法＞
次に、Ｊａｖａを用いたオペレータの検索の実現例を示
す。オペレータのプロファイルデータ（スキルデータ）
の持ち方としては、本例ではオブジェクトのＴｒｅｅ
（木）構造として保持し、オブジェクトへのメッセージ
送信で取得するようにする。

【００７４】図８に、オペレータのスキル構造を保持す
るためのクラス構造を示す。上記クラスのうち、「従事
年数分類」、「資格分類」、「役職分類」はリクエスト
・プロセス・エンジン１１０から参照される。これらの
クラス群には、検索処理を実行するためのメソッドであ
る“ｇｅｔＯｐｅｒａｔｏｒ０”なるメソッドと、新し
い条件およびオペレータを追加する処理のためのメソッ
ドである“ａｄｄＯｐｅｒａｔｏｒ０”なるメソッドが
用意されている。そして、たとえば「機器Ｂの切り替
え」なる内容を持つリクエストが送られて来た場合、図
５、図６に示すハッシュテーブルを用いることにより、
当該「機器Ｂの切り替え」をキーとして“ｖａｌｕｅ＿
ｂ”オブジェクトが取得されるので、次に、この“Ｖａ
ｌｕｅ＿ｂ”オブジェクトから当該オブジェクトに含ま
れる次の如きのデータを取得することができることとな
る。 資格：Ｐマスタ、Ｑ技術者 従事年数：５年以上 役職：必要なし（ｎｏｎｅ） ここまでの処理段階で、受け取った前記の「機器Ｂの切
り替え」なるリクエストに対処可能なオペレータの条件
としては上記の如きの条件に符合する人員でなければな
らないことがリクエスト・プロセス・エンジン１１０は
認識することとなる。次に、それぞれの条件に合ったオ
ペレータを選出するために、抽出処理を実現するための
メソッドである資格分類オブジェクト、従事年数オブジ
ェクトの“ｇｅｔＯｐｅｒａｔｏｒ０”メソッドを呼び
出す。資格分類オブジェクトの呼び出しには、資格名
「Ｐマスタ」「Ｑ技術者」を引数とし、従事年数オブジ
ェクトへの呼び出しには年数を示す「５」を引数とす
る。具体的には、資格分類オブジェクトおよび従事年数
オブジェクトに対して、次のようなオペレーションを送
る。

【００７５】資格分類オブジェクトへの呼び出し例 Ｏｐｅｒａｔｏｒ ｏｐｅｒａｔｏｒ＝資格分類．ｇｅ
ｔＯｐｅｒａｔｏｒ（Ｐマスタ、Ｑ技術者） ； 従事年数オブジェクトへの呼び出し例 Ｏｐｅｒａｔｏｒ ｏｐｅｒａｔｏｒ＝従事年数分類．
ｇｅｔＯｐｅｒａｔｏｒ（５）；ここで、Ｏｐｅｒａｔ
ｏｒ ｏｐｅｒａｔｏｒ＝資格分類．ｇｅｔＯｐｅｒａ
ｔｏｒ（Ｐマスタ、Ｑ技術者）；は、資格分類の中にお
けるＰマスタ並びにＱ技術者の資格を持つ者を入手して
これを変数“Ｏｐｅｒａｔｏｒ ｏｐｅｒａｔｏｒ”に
代入せよ、という内容であり、Ｏｐｅｒａｔｏｒ ｏｐ
ｅｒａｔｏｒ＝従事年数分類．ｇｅｔＯｐｅｒａｔｏｒ
（５）；は、従事年数分類の中における５（５年）の経
歴を持つ者を入手してこれを変数“ｏｐｅｒａｔｏｒ”
に代入せよ、という内容である。

【００７６】なお、Ｐマスタとは例えば、施設管理責任
者であるとか、ネットワークのスペシャリストであると
か、セキュリティのスペシャリストであるといったよう
な能力・権力的な内容を示したものであり、Ｑ技術者と
は第１種電気工事士とか第２種情報処理技術者とかとい
った技術的な資格保持内容を示したものである。

【００７７】スキル条件とオペレータのオブジェクト関
連は図９の如きであるとすれば、このオブジェクトを実
行させた結果、当該図９より、資格分類オブジェクトへ
の呼び出しから「Ｊ」（Ｊ氏）なる検索結果が返却さ
れ、従事年数オブジェクトへの呼び出しからは、「Ｊ」
（Ｊ氏），「Ｋ」（Ｋ氏）なる情報が返却される。これ
を受けてリクエスト・プロセス・エンジン１１０では、
返された結果から、両方の条件を満たす「Ｊ」（Ｊ氏）
をリクエストに対する適任のオペレータとして選択す
る。 ＜処理の転送＞オペレータの情報は文字情報化（キャラ
クタコード化）されたオブジェクトの参照（リファレン
スやポインタ、ＣＯＲＢＡのＩＯＲ等）の形でデータベ
ース１２０に格納されている。これらは、オペレータが
本システムにログインしたときにそのログインしたオペ
レータの端末より送信され、格納される。それをオブジ
ェクトの形に再現し、その再現されたオブジェクトに対
して転送処理の内容を持つメソッドを呼び出すようにす
ることで、転送先となる選択されたオペレータの端末へ
転送することでリクエストに対して対処させるべきオペ
レータを特定し、そのオペレータにリクエストを引き継
がせるようにする。

【００７８】すなわち、参照した範囲内において、条件
を満たすこととなった「Ｊ」なる該当情報（図１０の点
線の丸で囲まれたＲｅｆに相当）をリクエスト・プロセ
ス・エンジン１１０が抽出すると（図１１のｔ２）、当
該リクエスト・プロセス・エンジン１１０は次に、受信
した元のリクエストの内容を転送するためのリクエスト
・オブジェクト（楕円で囲んで表示されているＲｅｕｑ
ｅｓｔ Ｏｂｊｅｃｔ）を生成し（図１１のｔ３）、こ
の生成したリクエスト・オブジェクト（Ｒｅｑｕｅｓｔ
Ｏｂｊｅｃｔ）に対して、上記抽出した情報（この場
合は「Ｊ」）を渡す（図１１のｔ４）。

【００７９】そして、この渡された「Ｊ」なる情報を取
り込んだリクエスト転送用のリクエスト・オブジェクト
（Ｒｅｑｕｅｓｔ Ｏｂｊｅｃｔ）を転送処理する（図
１１のｔ５、ｔ６）。

【００８０】つまり、ＲｅｑｕｅｓｔＯｂｊｅｃｔ ｒ
ｅｑｕｅｓｔＯｂｊｅｃｔ＝ｎｅｗ ＲｅｑｕｅｓｔＯ
ｂｊｅｃｔ（Ｊ）；（初期化と同時にデータ「Ｊ」を渡
す。） ｒｅｑｕｅｓｔＯｂｊｅｃｔ．ｓｅｎｄＯｐｅｒａｔｉ
ｏｎ（ｒｅｑｕｅｓｔ）；（リクエストの転送） を実施するわけである。これにより、「Ｊ」氏の端末に
このリクエスト転送用のリクエスト・オブジェクト（Ｒ
ｅｑｕｅｓｔ Ｏｂｊｅｃｔ）が送られて、このリクエ
スト転送用のリクエスト・オブジェクト（Ｒｅｑｕｅｓ
ｔ Ｏｂｊｅｃｔ）に含まれる元のリクエストの内容が
「Ｊ」氏の端末におけるディスプレイに表示され、
「Ｊ」氏はクライアント側システム２０からのリクエス
トの内容であった「機器Ｂグループの切り替え」という
オペレーションに対処することになる。

【００８１】「機器Ｂグループの切り替え」というオペ
レーションは 資格はＰマスタ並びにＱ技術者の保持者
であること、そして、従事年数が５年以上であることと
云う取り扱い者条件があるが、「Ｊ」氏はこの要件に合
致する人員であるからこのリクエストを受け取った
「Ｊ」氏は有資格者として支障無く対処可能であり、リ
クエストはその持つ内容から適格となる人員に円滑に割
り付けられたことになる。

【００８２】［モジュール間に必要なインタフェース］
本システムを構築するに当たり、モジュール間に必要な
ソフトウエアによるインタフェースを図１２を参照して
説明する。

【００８３】図中のＩＦ１〜ＩＦ５は、モジュール外へ
公開するインタフェースを示す。以下、各インタフェー
スについて説明する。

【００８４】［１］図１２におけるＩＦ１は、リクエス
トを受信するためのインタフェースである。このインタ
フェースＩＦ１はＲｅｑｕｅｓｔ型のオブジェクトを渡
すようになっている。このオブジェクトには図３のデー
タとデータの読み出し、書き込みのためのメソッドが含
まれている。

【００８５】［２］図１２におけるＩＦ２は、オペレー
タのログイン／ログアウトの通知のインタフェースであ
る。このインタフェースＩＦ２は、オペレータがシステ
ムにログインされると図９に示すオブジェクト群にその
情報を登録する。方法としては、次の２つがある。

【００８６】・人を示すＩ（Ｉ氏）、Ｊ（Ｊ氏）、Ｋ
（Ｋ氏）などのデータをキャラクタコードで実際に生成
させる。ログインした人のオブジェクトだけを登録する
ようにする。ログアウトすればその人のオブジェクトを
登録抹消する。

【００８７】・すべてのオペレータのオブジェクトを事
前に生成しておき、Ｔｒｅｅ構造の末端に存在させる。
オペレータからのログイン情報を受け取るとＴｒｅｅ構
造の末端におけるそのオペレータの該当オブジェクトに
その情報（ログイン状態にあると云う情報）を書き込
み、オペレータからのログアウト情報を受け取るとＴｒ
ｅｅ構造の末端におけるそのオペレータの該当オブジェ
クトにその情報（ログアウト状態にあると云う情報）を
書き込む。

【００８８】［３］図１２におけるＩＦ３は、検索用オ
ブジェクトの登録のインタフェースである。このインタ
フェースＩＦ３は、図９のオブジェクト群を登録するた
めのインタフェースである。これを事前に登録しておく
ことにより、リクエストを受信したリクエスト・レシー
バ（ＲｅｑｕｅｓｔＲｅｃｅｉｖｅｒ）のリクエスト・
プロセス・エンジン１１０が、その登録されたオブジェ
クトを呼び出すことによって検索することができる。デ
ータ・プロファイル（Ｄａｔａ Ｐｒｏｆｉｌｅ）には
クラシフィケーション・オブジェクト（Ｃｌａｓｓｉｆ
ｉｃａｉｏｎＯｂｊｅｃｔ）以下のオブジェクト群が登
録され、リクエスト・プロセス・エンジン１１０にはク
ラシフィケーション・オブジェクト（Ｃｌａｓｓｉｆｉ
ｃａｔｉｏｎＯｂｊｅｃｔ）型の「ＸＸＸ分類」オブジ
ェクトが登録される。

【００８９】［４］図１２におけるインタフェースＩＦ
４は、オペレータ検索のためのインタフェースである。
このインタフェースＩＦ４には、Ｃｌａｓｓｉｆｉｃａ
ｔｉｏｎＯｂｊｅｃｔ型のＸＸＸ分類オブジェクトに対
して、“ｇｅｔＯｐｅｒａｔｏｒｓ０”を呼び出す機能
を持たせてある。

【００９０】［５］図１２におけるインタフェースＩＦ
５は、状態通知を行うインタフェースである。

【００９１】＜初期化の条件＞これらのインタフェース
を用いて本システムが動作するようにするための条件を
説明する。 〔リクエスト受信〕本システムがリクエストを受けるた
めに、図１２におけるインタフェースＩＦ１をリクエス
ト送信元へ公開する必要がある。そのためにｍａｉｎ関
数などでＲｅｑｕｅｓｔＲｅｃｅｉｖｅｒオブジェクト
を初期化し、インタフェースＩＦ１の参照（ポインタな
ど）を渡す。

【００９２】〔Ｒｅｑｕｅｓｔの解析のデータ〕図５の
テーブルをリクエスト・プロセス・エンジン１１０に持
たせる。本システムではハッシュテーブルの形式で生成
し、その参照（ポインタ）をリクエスト・プロセス・エ
ンジン１１０へ渡す。

【００９３】〔オペレータの条件を設定〕本システムの
管理者は、インタフェースＩＦ３を用いてデータベース
１２０にオペレータ用プロファイル情報を渡す。 〔リクエスト送信者の設定〕オペレータのクライアント
システムにインタフェースＩＦ２を渡す。オペレータが
ログインするとこのインタフェースＩＦ２を通してデー
タベース１２０にそのことが伝えられる。

【００９４】これでリクエストを受け取り、リクエスト
の内容に基づく条件を抽出し、この条件に合うオペレー
タをログイン状態にあるオペレータ中から抽出すること
が可能な環境が整う。

【００９５】リクエスト・プロセス・エンジン１１０が
リクエストを受信してから、本システムによってオペレ
ータを選択し、そのオペレータの参照（リファレンス）
に対して、リクエストを転送するまでの手順を纏めてお
く。大きく分けると、ステップＳ１．Ｒｅｑｕｅｓｔ
Ｒｅｃｅｉｖｅｒを経由して、リクエストを受信する。
ステップＳ２．リクエストの中からリクエスト内容を示
す部分を取り出す。ステップＳ３．２の情報を元に、そ
のリクエストを処理するために必要な条件を取得する。
ステップＳ４．検索の結果選られたオペレータに対して
リクエストを送信する。の計４ステップである。

【００９６】ステップＳ１では、リクエスト受信部（Ｒ
ｅｑｕｅｓｔ Ｒｅｃｅｉｖｅｒ）１１１を経由して、
リクエストを受信する（リクエスト受信部による受
信）。受信されたリクエストはワークフロー管理モジュ
ール１１２へ集められる。

【００９７】ステップＳ２では、リクエストの中からリ
クエスト内容を示す部分を取り出す。ワークフロー管理
モジュール１１２でリクエスト内容を示す部分が取り出
されるわけである。本実施例では、これは「ＴｙｐｅＯ
ｆＤｉｒｅｃｔｉｏｎ」変数に記載された情報である。
また、ワークフロー管理モジュール１１２では、処理手
順定義書の処理手順を読み込み、その内容に従って順番
に処理を行う。そして、ワークフロー管理モジュール１
１２によって「検索条件の取得」を読み取られると、リ
クエスト条件取得モジュール１１３に処理が渡される。
リクエスト条件取得モジュール１１３では、「Ｔｙｐｅ
ＯｆＤｉｒｅｃｔｉｏｎ」の値をキーとして、テーブル
情報のデータベースへ照会し、対応するバリュー（ｖａ
ｌｕｅ）を取得する。取得されたバリューはワークフロ
ー管理モジュール１１２へ返却される。

【００９８】ステップＳ３では、ステップＳ２での情報
を元に、そのリクエストを処理するために必要な条件を
取得する。すなわち、ワークフロー管理モジュール１１
２では、次のステップである「検索」に移行する。検索
のステップでは、リクエスト条件取得モジュール１１３
より結果として返却されたバリューを検索モジュール１
１４へ渡す。検索モジュール１１４では、オペレータ情
報を管理している（スキル条件とオペレータのオブジェ
クトの関連に相当する）。渡されたバリューを引数とし
て、条件（すなわち、バリュー）に適合するオペレータ
のオブジェクトリファレンスを検索する。検索結果はワ
ークフロー管理モジュール１１２へ返却する。

【００９９】ステップＳ４では、検索の結果、選らばれ
ることなったオペレータに対し、リクエストを送信す
る。すなわち、ワークフロー管理モジュール１１２で
は、「検索結果の返却」ステップへ移行する。検索モジ
ュール１１４で得られ、ワークフロー管理モジュール１
１２で受け取った検索結果（この例ではオペレータのオ
ブジェクトリファレンスあるいはポインタ）を、検索結
果の転送モジュール１１５へ送る。

【０１００】以上で、リクエストに対しての人選と割り
当てが終了する。

【０１０１】次に、本システムの動作のトリガとなるリ
クエストの入力について触れておく。

【０１０２】本発明では、クライアント側からリクエス
トを送ることで、最適オペレータが選択され、そのリク
エストに対しての対応を割り当てることになるが、トリ
ガとなるリクエストは次のように発生させる。

【０１０３】手法としては、次の２通りがある。一つは
クライアント側としての機器からの入力であり、もう一
つはユーザからの問い合わせである。

【０１０４】機器からの入力の場合；この場合でのリク
エスト情報は、工場のプラント機器や野外や道路などに
配置されたセンサから計測された信号を元に取得する。
現場ではセンサ値や、ビット列などのかたちで情報が発
生すると考えられるが、一般的にはその信号を集め、そ
れを解析可能なデータに変換するローカルサーバに収集
して解析するようにし、このローカルサーバから解析結
果に基づく意味ある情報としてリクエストを発生させる
ことで、自動リクエスト送信による入力環境が実現可能
となる。従って、リクエスト生成に当たって、図３のよ
うな形式のファイル情報として送信されれるようにすれ
ばよい。

【０１０５】ユーザからの問い合わせ；ユーザからの問
い合わせをトリガとするリクエストの場合、これは物流
システム、防災システム、電化製品の故障や使用方法の
問い合わせなど、人からの要求がリクエストになる場合
であるが、この場合には、ファイル情報としてのリクエ
ストをクライアント側（ユーザ側）から受け取ることは
難しいと考えられるので、本システムで利用するための
適切なデータとなるように入力口（受付窓口）で引き出
す必要がある。

【０１０６】そのためには、例えば、受付窓口に端末を
設置し、この端末にはＧＵＩ（グラフィカル・ユーザ・
インタフェース）を利用した画面上でリクエスト内容や
問題の症状を入力する支援機能を持たせてユーザからの
問い合わせをこの画面上で入力し、リクエスト用のフォ
ームによるファイル情報化を実施して、最適候補選定シ
ステム１０に渡し、ここからリクエスト・プロセス・エ
ンジン１１０に渡すといった方法を採る。また、ＷＷＷ
（ワールドワイドウエブ）などを介して状況の大まかな
絞り込みをするための画面を提供し、ユーザにはこのＷ
ＷＷを介して自己のパソコン（ＰＣ）や携帯端末と繋
ぎ、ＷＷＷの提供画面からリクエスト内容や問題の症状
を入力するといったＧＵＩを利用したサポート技術を利
用し、ユーザの問い合わせをリクエスト用のフォームに
よるファイル情報化処理して、最適候補選定システム１
０に渡し、ここからリクエスト・プロセス・エンジン１
１０に渡すといった方法も考えられる。以上、本発明は
要求内容情報を持たせたリクエスト情報を送ると、これ
をもとに、この要求内容に対処させるべき人員を選択し
てその人員に前記リクエスト情報を渡し、対処させるよ
うにしたものであり、リクエスト情報の持つ要求内容情
報に応じて応対者のスキル条件を定め、応対者としての
候補にはその個人の持つスキルをプロファイル情報とし
て登録し、リクエスト情報を受けるとそのリクエスト情
報の持つ要求内容情報対応にスキル条件を抽出し、この
抽出したスキル条件を満たす応対者を前記応対者候補の
プロファイル情報をもとに抽出して前記リクエスト情報
に対する応対者として定めるようにしたものである。

【０１０７】従って、発生したリクエスト情報の持つ要
求内容情報に対して最適な応対者を選別してその選定し
た応対者にその要求内容情報の対処を行わせることがで
きるので、的確な対処を迅速に行うことができるように
なり、人選が不適切で要求内容に対処できず、たらい回
しにされたり、必要以上に対処に時間を要したり、対処
しきれなかったりするという事態を回避することができ
るようになる。

【０１０８】なお、本発明は上述した実施形態に限定さ
れるものではなく、種々変形して実施可能である。

【０１０９】例えば、上記実施例では、クライアント側
からのリクエストを定型のテキストデータファイル形式
で受け取ることを前提に話を進めたが、このリクエスト
は必要時にクライアント側で状況対応に自動生成して送
り出す方式の他、入力画面を用意してクライアント側の
人員がこの入力画面に従い、必要事項を入力することで
定型のテキストデータファイル形式でリクエストを送り
出すことができるようにしたり、ユーザからの各種問い
合わせや照会などのサービスに適用する場合には、電話
やファックスで入電する問い合わせ内容を一旦、受付窓
口のオペレータが受け付け、その内容をリクエストを定
型のテキストデータファイル形式化してリクエストとし
て本システムに渡すことで、最適オペレータ（最適応対
者）を選択してそのリクエストを渡すようにすることも
できる。そのため、顧客からの各種問い合わせ、監視シ
ステムからのアラームなど、種々の分野におけるリクエ
ストの効率的解決を可能にするシステムとして利用可能
であり、商業、工業などあらゆる産業分野におけるコン
ピュータネットワークを用いた各種情報処理システムに
適用可能である。

【０１１０】また、本発明は、データベースを入れ替え
ることによって、さまざまな監視制御システムの解析に
使用できる。

【０１１１】また、本システムは検索モジュール１１４
においてＸＭＬ文書を読み込むためのパーサを組み込ん
でおけば、オペレータの情報をＸＭＬデータとして保持
して利用することも可能である。

【０１１２】また、本発明のシステムは、応対者（オペ
レータ）と、リクエストの発行元とを対応付けてあらか
じめ登録しておくことによって特定の発行元からのリク
エストは特定の人員（オペレータ）に転送することがで
きる仕組みとなる。このようにすることで処理時間が短
縮され、的確な人員をそのリクエストに対して振り向け
ることができるようになる。

【０１１３】さらにまた、本システムは業種に関係な
く、スキル情報を定義することができるものであり、ス
キル構造と業種とは無関係な構造であって、構造の追加
方法のみが規定されているものであるため、さまざまな
業種に適用することができて、広範、多様な応用が可能
である。

【０１１４】また、本発明において、上記実施形態には
種々の段階の発明が含まれており、開示される複数の構
成要件における適宜な組み合わせにより種々の発明が抽
出され得る。例えば、実施形態に示される全構成要件か
ら幾つかの構成要件が削除されても、発明が解決しよう
とする課題の欄で述べた課題の少なくとも１つが解決で
き、発明の効果の欄で述べられている効果の少なくとも
１つが得られる場合には、この構成要件が削除された構
成が発明として抽出され得る。また、本発明は、実施の
形態で説明した手法をコンピュータ用のアプリケーショ
ンプログラムとしてネットワーク上で頒布したり、コン
ピュータにて読み込み実行可能な記録媒体に記録して頒
布したり、また、このアプリケーションプログラムをコ
ンピュータに読み込んで実行する形態も本発明に含まれ
る。

【０１１５】

【発明の効果】以上、詳述したように、本発明によれ
ば、クライアント側から発せられた要求内容情報を持つ
リクエスト情報を受信すると、このリクエスト情報に対
処するために必要なスキルをキーとして、対応できる人
員を検索するようにしたことにより、発生したリクエス
ト情報に対して適切な人員を選び、その人員に当該リク
エストの対応をさせることができる。従って、クライア
ント側に対しての対応がより的確になり、しかも迅速に
対応できて質の高いサービスができるようになるコール
センタシステムおよび応対者選定方法を提供できる。

【図面の簡単な説明】

【図１】本発明システムの構成例を示すブロック図であ
る。

【図２】本発明システムを機能ブロックで示した図であ
る。

【図３】本発明システムで用いるリクエストに含まれる
データの一例を示す図である。

【図４】オペレーションの種類を示す変数「Ｔｙｐｅ
ｏｆ Ｄｉｒｅｃｔｉｏｎ」とその値の例を説明する図
である。

【図５】本発明システムで用いるリクエストの種類とオ
ペレーションのための条件を格納したテーブル例を示す
図である。

【図６】本発明システムで用いるオペレーション実行条
件を検索するためのテーブル例を示す図である。

【図７】本発明システムで用いるオペレータのプロファ
イルデータ例を示す図である。

【図８】本発明システムで用いるオペレータのスキル構
造を保持するためのクラス構造例を示す図である。

【図９】本発明システムで用いる スキル条件とオペレ
ータのオブジェクトの関連を示す図である。

【図１０】本発明システムにおける処理の概要（本装置
によるリクエスト受信から、オペレータへの転送まで）
を示す図である。

【図１１】本発明システムにおける処理の流れ（シーケ
ンス図）を示す図である。

【図１２】本発明システムにおけるモジュール間に必要
なインタフェースを説明する図である。

【符号の説明】

１０…最適候補選定システム、２０…クライアント側シ
ステム、３０…オペレータ群、１０…リクエスト・レシ
ーバ １１０…プロセス・エンジン、１１１…リクエスト受信
部、１１２…ワークフロー管理モジュール、１１３…リ
クエスト条件取得モジュール、１１４…検索モジュー
ル、１１５…検索結果転送モジュール

Claims (5)

【特許請求の範囲】
1. 【請求項１】クライアント側から発せられた要求内容情
   報を持つリクエスト情報を受信する受信手段と、 この受信手段にて受信されたリクエスト情報における要
   求内容に対処させるべき人員の条件が要求内容情報別に
   予め定められると共に、前記受信されたリクエスト情報
   の持つ求内容情報から前記条件を取得する条件取得手段
   と、 前記リクエスト情報における要求内容に対処させるべく
   待機する複数の人員各人のスキル情報およびその各人の
   端末情報とを保持するデータベースと、前記条件取得手
   段にて取得された前記条件に適合する人員を前記データ
   ベースから検索する検索手段と、 この検索手段により検索された人員に対処させるべく、
   前記リクエスト情報を当該人員の端末に転送する転送手
   段と、を具備してなるコールセンタシステム。
2. 【請求項２】前記データベースは資格、経験年数、職
   能、職種のうち、いずれか１つ以上から構成される情報
   を各人の前記スキル情報として保持することを特徴とす
   る請求項１記載のコールセンタシステム。
3. 【請求項３】前記データベースの保持する各人の前記ス
   キル情報を変更可能な変更手段を有し、各人の前記スキ
   ル情報に変更可能に構成したことを特徴とする請求項１
   記載のコールセンタシステム。
4. 【請求項４】クライアント側から発せられる各種の要求
   内容対応に当該各要求内容に対処させるべき最適人員の
   条件をそれぞれ要求内容情報別に予め定めて保持させる
   と共に、前記リクエスト情報における要求内容に対処さ
   せるべく待機する複数の人員各人のスキル情報およびそ
   の各人の使用する操作端末の情報を保持させ、 クライアント側から発せられた要求内容情報を持つリク
   エスト情報を受信すると、この受信されたリクエスト情
   報における要求内容情報をキーとして抽出し、抽出され
   た情報をキーに、前記保持させてある前記予め定めた前
   記要求内容情報別最適人員の条件中から該当条件を検索
   し、得た条件に合う人員を前記保持させた各人のスキル
   情報中から抽出してその抽出した人員の使用する操作端
   末に前記リクエスト情報を転送することにより、そのリ
   クエストに対する対応を前記抽出した人員に割り当てる
   ことを特徴とする応対者選定方法。
5. 【請求項５】クライアント側から発せられた要求内容情
   報を持つリクエスト情報を受信処理する受信ステップ
   と、 この受信ステップにて受信処理されたリクエスト情報に
   おける要求内容に対処させるべき人員の条件が要求内容
   情報別に予め定められており、これをもとに、前記受信
   されたリクエスト情報の持つ求内容情報から前記条件を
   取得する条件取得ステップと、 前記リクエスト情報における要求内容に対処させるべく
   待機する複数の人員各人のスキル情報およびその各人の
   端末情報とを保持するデータベースと、 前記条件取得ステップにて取得された前記条件に適合す
   る人員を前記データベースから検索する検索ステップ
   と、 この検索ステップにより検索された人員に対処させるべ
   く、前記リクエスト情報を当該人員の端末に転送する転
   送ステップと、を備えたリクエストに対する対応者選定
   のためのコンピュータプログラム。