"顧客の機器を対象とした保守対応の業務に係わる情報処理を行う保守対応システムであって、複数の拠点の複数の保守員の中から前記顧客の機器の保守対応を行う担当者を決定する機能を持つ情報処理装置を有し、前記情報処理装置は、診断部と、管理情報を格納するDBとを有し、前記情報処理装置は、外部から前記保守対応の要求の情報を入力し、前記診断部は、前記管理情報または入力情報をもとに、対象の顧客の機器の状態、必要な保守対応の内容及び条件を診断または確認する第1の処理と、前記管理情報または入力情報をもとに、複数の拠点と複数の保守員の最新の状態を診断または確認する第2の処理と、前記第1、第2の処理をもとに、対象の顧客の機器の保守対応のために、前記複数の拠点の複数の保守員の中から、担当者またはその候補となる拠点の保守員をマッチング判定する第3の処理と、を行い、前記第3の処理において、第1条件として、前記必要な保守対応の条件として、前記対象の顧客の機器の状態に応じた必要なスキルを持つ保守員を第1候補として選択し、第2条件として、前記第1候補から、対象の顧客の機器との距離がなるべく近い拠点の保守員を第2候補として選択し、第3条件として、前記第2候補から、複数の拠点または複数の保守員における保守対応の仕事の負荷分散が実現されるように、負荷がなるべく小さい拠点の保守員を第3候補として選択すること、を特徴とする保守対応システム。請求項1記載の保守対応システムにおいて、前記診断部の第3の処理において、前記第1条件として、前記必要な保守対応の条件として、前記顧客の言語に応じた必要な言語を持つ保守員を第1候補として選択すること、を特徴とする保守対応システム。請求項1記載の保守対応システムにおいて、前記診断部の第3の処理において、前記第2条件の判定の際には、前記対象の顧客の機器が存在するエリアまたは位置の情報と、前記保守員の拠点が存在するエリアまたは位置の情報とを確認し、両者間の距離またはその距離区分範囲を判定すること、を特徴とする保守対応システム。請求項1記載の保守対応システムにおいて、前記診断部の第3の処理において、前記第3条件の判定の際には、拠点の待機人数が所定人数以上確保されないものを候補から除外すること、を特徴とする保守対応システム。請求項1記載の保守対応システムにおいて、前記診断部の第3の処理において、前記第3条件の判定の際には、前記保守員の負荷状態を判定し、負荷が大きすぎるものを候補から除外すること、を特徴とする保守対応システム。請求項1記載の保守対応システムにおいて、設定または入力に基づいて、前記診断部の第3の処理において、前記第2条件の距離と、前記第3条件の負荷分散とで、前記第2条件の距離を優先して前記担当者またはその候補を決定すること、を特徴とする保守対応システム。請求項1記載の保守対応システムにおいて、設定または入力に基づいて、前記診断部の第3の処理において、前記第2条件の距離と、前記第3条件の負荷分散とで、前記第3条件の負荷分散を優先して前記担当者またはその候補を決定すること、を特徴とする保守対応システム。請求項1記載の保守対応システムにおいて、前記情報処理装置は、監視部と、指示部とを有し、前記監視部は、前記顧客の機器の状態及び位置を監視し、保守対応が必要な状態を検知する処理を行い、前記指示部は、前記診断部の処理結果をもとに、前記担当者となる保守員の拠点の設備または当該保守員の携帯端末へ保守対応の指示情報を送信する処理、及び当該設備または携帯端末から当該拠点の保守員の状態を取得する処理を行うこと、を特徴とする保守対応システム。前述の従来の保守対応システムでは、以下のような課題がある。従来のシステムにおいて、例えば顧客のサーバ等のコンピュータ機器の障害状態を監視で検知した場合などに、例えば当該機器の復旧作業等の保守対応のために、保守員等の担当者が現地当該機器が設置されている場所へ訪問し、保守対応を実施する。その際、当該保守員は、最寄りの拠点保守対応拠点から現地へ派遣される。拠点は、保守員が保守対応の業務のために通常待機スタンバイしている場所施設等である。保守員は、指示を受けると、最寄りの拠点から、保守作業に必要な保守部品などを携えて、現地へ移動し、保守作業等を実施する。しかし、上記拠点で待機する保守員要求されている保守対応のための適切なスキル等を持つ保守員が不足する場合、要求されている保守対応を迅速に実現できない場合がある。例えば、複数の拠点のうち一部の拠点で待機している保守員が不足したり、拠点内の複数の保守員のうち一部の保守員に担当が集中したり、といったように、仕事の負荷が偏る場合がある。従来のシステムは、複数の保守員複数の拠点間における仕事保守対応の効率性や負荷分散などについては不十分である。また、顧客の機器の適切な保守対応のために、適切なスキルや言語を持つ保守員を担当させることが好ましいが、拠点に適切なスキルや言語を持つ保守員が待機しているとは限らず、適切な保守対応、迅速な保守対応を実現できない場合がある。スキルについては、対象の機器サーバ等の復旧作業等のための知識などが要求される。言語については、顧客とのコミュニケーション会話などを含むで顧客の使用する言語例えば地域などによって異なるによってはうまくコミュニケーションできず時間を要してしまう場合がある。また例えば特許文献1では、機器の保守対応を行う保守員を決めるにあたり、要因として、保守員の位置と保守能力スキルレベルを考慮している。これにより、保守対応の迅速性や、能力的に適切な保守員の選択担当を実現している。しかしながら、これら要因の考慮だけでは、複数の保守員複数の拠点間における仕事保守対応の効率性や負荷分散などについては不十分である。以上を鑑み、本発明の主な目的は、保守対応仕事の適切性、迅速性、及び複数の拠点複数の保守員間における保守対応仕事の全体的な効率性負荷分散を実現できる技術を提供することである。上記目的を達成するため、本発明のうち代表的な形態は、顧客のコンピュータシステムサーバ等のコンピュータ機器を対象とした保守対応やヘルプデスク顧客サポート等の業務サービスに係わる情報処理システム保守対応システム、等であって、以下に示す構成を有することを特徴とする。本システムは、複数の拠点の複数の保守員の中から顧客の機器の保守対応を行う担当者を決定する機能を持つ情報処理装置を有する。情報処理装置は、診断部と、管理情報を格納するDBとを有し、例えば外部から保守対応の要求の情報を入力する。診断部は、管理情報または入力情報をもとに、対象の顧客の機器の状態、必要な保守対応の内容及び条件を診断または確認する第1の処理と、管理情報または入力情報をもとに、複数の拠点と複数の保守員の最新の状態を診断または確認する第2の処理と、第1、第2の処理をもとに、対象の顧客の機器の保守対応のために、複数の拠点の複数の保守員の中から、担当者またはその候補となる拠点の保守員をマッチング判定する第3の処理とを行う。第3の処理において、第1条件として、必要な保守対応の条件として、対象の顧客の機器の状態に応じた必要なスキルを持つ保守員を第1候補として選択し、第2条件として、第1候補から、対象の顧客の機器との距離がなるべく近い拠点の保守員を第2候補として選択し、第3条件として、第2候補から、複数の拠点または複数の保守員における保守対応の仕事の負荷分散が実現されるように、負荷がなるべく小さい拠点の保守員を第3候補として選択する。本発明のうち代表的な形態によれば、保守対応仕事の適切性、迅速性、及び複数の拠点複数の保守員間における保守対応仕事の全体的な効率性負荷分散を実現できる。以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。なお説明上、適宜、U:顧客、C:機器、K:拠点、H:保守員、といった記号を使用する。<概要等>本実施の形態のシステム図1等は、保守対応仕事に関する動的負荷分散を含む効率的なマッチング機能を持つ。この機能では、顧客コンピュータ機器の保守対応のために担当させる保守員拠点を、保守員のスキルや言語、顧客機器との距離位置、及び全体的な負荷状態などの要因を考慮してマッチングし決定する。特に、複数の拠点の複数の保守員の間における仕事の負荷分散の状態になるように自動的に判断される。本例では特に、対象の顧客コンピュータ機器が固定的なサーバでありその障害エラー等の場合の保守対応を実施する例を用いて説明する。[システム]図1において、本実施の形態のシステムの全体の構成を示している。本システム全体は、センターシステム1と、顧客システム2と、拠点保守対応拠点3と、ヘルプデスクシステム4とを有し、これらがインターネット、無線網、あるいは専用線などのネットワーク5,6で接続されている。1センターシステム1は、主制御システム部分であり、サーバ10及び管理情報DB50を有する。サーバ10は、処理部として、監視部11、診断部12、指示部13を有し、管理情報DB50を管理読み書きして処理を行う。診断部12は、詳しくは、顧客機器診断部12A、拠点保守員診断部12B、マッチング部12Cを有する。管理情報DB50は、詳しくは、顧客情報51、機器情報52、拠点情報53、保守員情報54、保守対応情報55を含む。なおDB50の各情報51~55を管理するためのサブシステムを設けてもよい既存のサブシステムを利用してもよい。監視部11は、顧客システム2側の監視対象の機器21のエージェント22と連携して、監視対象の機器21の監視処理を行う。監視部11は、エージェント22から監視情報a1を受信して記録すると共に、監視情報a1の内容から機器21の障害エラー等の状態や負荷状態などを判断検知する。診断部12は、監視部11の処理結果及びDB50をもとに、本特徴的な診断処理後述を行い、対象の顧客U機器21Cの保守対応のために担当させる拠点K保守員Hを決定する。診断部12での制御内容マッチング判定の際のアルゴリズム等は、設定a4により変更可能となっている。設定a4は例えばセンターシステム1の設定者により設定用Webページでアルゴリズム判定方式を選択したりそのパラメータ値例えば距離時間や負荷分散などの優先する観点や、判定用の閾値などを変更する形などである後述。指示部13は、診断部12の処理結果どの拠点のどの保守員を保守対応の担当者とするかをもとに、保守対応に係わる指示a2を対象の拠点331,32へ送信する処理や、保守対応用設備31や保守員の携帯端末32から当該拠点や保守員の状態などの情報を取得する処理を行う。2顧客システム2は、顧客Uが利用する情報処理システムであり、例えば顧客企業内に構築された業務用システム等であり、少なくとも顧客コンピュータ機器21機器と略すを有する。機器21は、センターシステム1により監視保守の対象となる、例えばサーバ等であり、顧客システム2内に固定的に設置されている。なお、顧客システム2機器21は、上記顧客企業内システムに限らず、データセンタ等を利用する形でもよい。この場合はデータセンタ内の機器が監視保守の対象となる。機器21では、業務処理などが行われると共に、エージェント21が稼働する。エージェント22は、例えばソフトウェアプログラム処理で実現される。エージェント22は、監視部11と連携し、機器21の動作状態を監視する。例えば、エージェント22は、設定情報に基づき、機器21の動作状態を表す監視情報a1を発行してネットワーク5を介してサーバ10監視部11へ送信する。なお、エージェント22は、機器21とは別の装置やそのプログラム処理などで実現されてもよい。監視情報a1は、例えば、機器21のID,状態、位置などの情報を含む。なお機器21の位置情報の送信は、予めセンターシステム1側で当該位置情報が登録管理されている場合は必要無い。3複数の各拠点3Kは、保守員Hが保守対応の業務のために待機する地理的な拠点であり、保守対応用設備31や保守部品33ストックを備える。各保守員Hは、保守対応の業務用に、携帯端末32を所持する。保守対応用設備31は、センターシステム1指示部13からの指示a2を受信し、当該指示a2に対応する保守対応指示情報を、当該拠点3内の保守員Hに対して出力一覧表示、報知、あるいは保守員の携帯端末32への情報送信等する。拠点3の保守員Hは、保守対応の指示を受けた場合、携帯端末32及び必要な保守部品33を持ちつつ、対象の顧客Uの顧客システム2の機器21へ出向き、保守対応のコミュニケーションや作業などを実施するa3。携帯端末32は、保守対応の業務用のアプリケーションを備えており、画面に、保守対応指示例えば日時、顧客U、機器21Cなどの指定や、保守対応の具体的な作業内容等の指示例えばエラー等の箇所、復旧手順、詳細情報などの情報を表示する。また保守員Hは、携帯端末32の画面に保守対応の状況例えば未完了/済みなどを入力し、拠点331や、センターシステム1等へ状況を伝えることができる。これにより、センターシステム1等は、保守対応の仕事の指示に対しての当該仕事の未完了/済みなどの状態を把握できる。なお保守対応用設備31を省略する形態や、携帯端末32を省略する形態とすることができる。保守対応用設備31を省略する形態の場合は、センターシステム1から携帯端末32へ直接的に指示a2を送信してもよい。4ヘルプデスクシステム4は、公知のシステムであり、各要素1,2,3と接続され、顧客Uからの電話やWeb等での問い合わせに対して応対者により応対し、センターシステム1や拠点3と連携しながら、保守対応に係わる顧客サポートを行う。なお本システムは、ヘルプデスクシステム4を無くした形態、ヘルプデスクシステム4とセンターシステム1を統合した形態も可能である。12診断部12において、顧客機器診断部12Aは、監視部11で検知したエラー状態などの情報をもとに、当該顧客U機器21側の状態に応じた、必要な保守対応の内容復旧作業などを診断または確認する。なお監視部11で診断済みの場合は12Aは不要である。拠点保守員診断部12Bは、監視部11によるエラー状態などの検知時に、複数の各拠点3K保守員H側の現在リアルタイムの状態例えば拠点内に待機中か否か、保守対応を受け付け可能か否か等を診断または確認する。当該確認は、随時実行しておくこととしてもよい。特に保守対応の迅速化の観点から、予め各拠点3等から情報を取得して最新の状況を確認し必要な情報を保持しておくとよい。マッチング部12Cは、12Aと12Bの処理結果マッチングのための基本的な前提条件の確認をもとに、本特徴的な保守対応のマッチング判定処理後述を所定のアルゴリズムa4で設定可能により行う。これにより、当該顧客Uの機器21Cの保守対応のために、複数の拠点K保守員Hのうちのどの拠点のどの保守員を担当させるかをマッチング決定する。これにより、全体的な仕事の負荷分散を含めて考慮した好適な担当者が決定される。[管理情報]図2は、管理情報DB5051~55の構成例を示す。なお下記の各情報要素の管理は適宜統合分離してもよい。なお図5には各IDU,C,K,H等の値の具体例を示している。51顧客情報51は、a顧客ID、bエリア/地域ID、c言語、d状態、の各情報を含む。a顧客IDは、顧客Uないし顧客システム2を識別する情報である。例えばUx等で示す。bエリア/地域IDは、顧客システム2機器21の存在するエリア/地域を識別する情報である。例えばRx等で示す。c言語は、顧客Uないし顧客システム2の使用する言語日本語、英語などを識別する情報である。例えばWx等で示す。d状態は、顧客Uの状態として、例えば保守対応の要求の有無などを示す。52機器情報52は、a機器ID、b位置、c構成情報/属性情報、d状態、各情報を含む。a機器IDは、機器21の識別情報である。例えばCx等で示す。b位置は、当該機器21の位置情報例えばGPSによるである。例えばLx等で示す。なお51のbのエリアRの情報と52のbの位置Lの情報は対応しており、置き換えてもよいし、一方のみの管理としてもよい。bの位置情報は、予め設定してもよいし、監視情報a1により随時取得してもよい。c構成情報/属性情報は、機器21の構成や属性を示す情報であり、例えば種別がサーバであることを示す情報や、構成要素の部品の識別情報などを有する。d状態は、機器21の正常や障害エラー等の状態を表すコードや、負荷状態を示す情報や、保守対応必要有無を示す情報などがある。53拠点情報53は、a拠点ID、bエリア/地域、c位置、d保守員ID、e状態、の各情報を含む。a拠点IDは、拠点3を識別する情報である。例えばK1等で示す。bエリア/地域IDは、当該拠点3が存在するエリア/地域の識別情報である。R1等で示す。c位置は、当該拠点3が存在する位置の位置情報GPS等によるである。前述同様にRとLは一方のみの管理でもよい。d保守員IDは、当該拠点3Kに関係付けられる保守員Hの識別情報である。例えばH1-1,H1-2等で示す。本実施の形態では、d保守員IDは、当該拠点3に所属基本的に待機する複数の保守員Hを示す。e状態は、当該拠点3の状態として、当該拠点3に現在待機中の状態の保守員HのIDリストや、待機中の人数mなどの情報がある。54保守員情報54は、a保守員ID、bスキル、c言語、d状態、e担当、f負荷、の各情報を含む。その他、保守員携帯端末32の位置をGPS等で管理する形態の場合はその位置情報Lを含む。a保守員IDは、保守員Hの識別情報である。例えばH1-1等で示す。bスキルは、当該保守員の保守対応に係わるスキルセット能力を示す情報である。例えばSa等で示す。例えば保守対応可能な機器21の種別や、機器21の知識や復旧作業に関するスキルを示す。c言語は、当該保守員の使用する言語日本語、英語等を示す。例えばWa等で示す。d状態は、当該保守員の最新の状態として、当該保守員が所属する拠点K内に待機中か当該拠点K外に外出中か最寄り拠点に居る/居ない、等の状態を示す情報である。あるいは、当該保守員が、現在、保守対応用の時間が空いているか否か新たな仕事を受け付け可能か否か、仕事が休みかどうか、等の状態を示す情報である。なお保守員Hと拠点Kとの関係は、基本的には特定の拠点に所属する形とするが、ある保守員は複数の拠点に寄る待機することもできる。その場合、どの拠点Kに待機しているかを含めて情報を管理すればよい。e担当は、当該保守員が現在担当している保守対応の仕事55で管理される単位に関する情報であり、保守対応IDP1等等で示される。f負荷は、状態の一種であるが、当該保守員の保守対応の仕事の負荷の大きさを示す情報である。負荷の情報は、例えば、大/中/小といったレベル値で管理してもよいし、当該保守員が担当している保守対応の仕事55で管理される単位の数や量や、連続で担当している回数などで表してもよい。なお拠点Kごとの状況、及び複数の拠点Kを含む全体的な状況は、拠点情報53、保守員情報54を参照することでわかる。55保守対応情報55は、個々の保守対応の仕事を管理する情報であり、a保守対応ID、b顧客ID、c機器ID、d状態コード、e作業内容、f必要条件、g担当、h状態、の各情報を含む。その他、仕事の期日などの時間情報を管理してもよい。a保守対応IDは、当該保守対応の仕事を識別する情報である。例えばP1等で示す。b顧客IDは、当該保守対応Pの仕事の対象となる顧客Uを示す識別情報である。c機器IDは、当該保守対応Pの仕事の対象となる機器21Cの識別情報である。d状態コードは、当該機器21Cの障害エラー等の状態を示すコードであり、52のdの状態と対応する。e作業内容は、当該保守対応Pの作業内容を示す情報であり、例えば、dの状態コードに応じた復旧等の作業手順を示す情報であり、必須ではないが、例えば担当の保守員Hの携帯端末32へ提供してガイド情報として用いる。f必要条件は、当該保守対応Pに係わる必要な条件を示し、例えば、必要保守部品b1等、必要スキルSa等、必要言語Wa等、等の情報がある。必要保守部品b1等は、当該保守対応Pで必要な交換部品などであり、拠点3に備える保守部品33を用いる。必要スキルSa等は、当該保守対応Pで必要な保守員Hのスキルを示す。必要言語Wa等は、当該保守対応Pで当該顧客Uとのコミュニケーションや当該機器21の操作のために必要とされる言語を示す。なお、言語Wについては、必要条件とせずに推奨条件としてもよい。また言語WをスキルSの概念の中に含めて管理してもよい。g担当は、当該保守対応Pの仕事を担当する拠点K保守員Hの識別情報K1,H1-1等などである。h状態は、当該保守対応Pの仕事の状態として、未完/済み等がある。[具体例]図5は、顧客U機器Cと複数の拠点K保守員Hとの関係の一例を示す。エリアRx位置Lxに、対象の顧客Uxの顧客システム2機器21Cxがある。機器Cxのエラー状態001に関する保守対応P1のために、必要部品がb1、必要スキルがSaであり、顧客Uxの使用言語必要言語がWaである。複数の各拠点3Kとして、例えばK1,K2,K3を有し、それぞれエリアR位置LがR1L1,R2L2,R3L3である。これらそれぞれの、顧客Ux機器Cx側のエリアRxLxとの距離EとするをE1,E2,E3とする。拠点K1は、所属する保守員として、H1-1,H1-2等を有し、例えばH1-1は待機中、H1-2は外出中であり、K1内の待機人数mが1である。拠点K2は、所属する保守員として、H2-1,H2-2等を有し、例えばいずれも待機中であり、K2内の待機人数mが2である。拠点K3は、所属する保守員として、H3-1,H3-2,H3-3等を有し、例えばいずれも待機中であり、K3内の待機人数mが3である。[処理1]図3は、本システムにおけるサーバ制御部10の処理例を示すs1等は処理ステップを示す。s0まず前提トリガとして、前述のように、監視部11が、監視情報a1から対象の顧客U側の機器21Cの障害エラー等の状態を判断検知し、DB50の顧客情報51や機器情報52に当該情報を反映する。あるいは別のトリガとして、ヘルプデスクシステム4から保守対応の依頼が入る。s1顧客機器診断部12Aは、s0の監視部11からの情報例:顧客ID、機器ID、エラー状態を示すコードなど、DB5051,52をもとに、対象の顧客U機器C側の状態と、当該状態に応じた必要な保守対応Pの作業内容、必要条件必要保守部品、必要スキル、必要言語などを診断または確認し、DB50保守対応情報55等に反映する処理を行う。例えば55のa~fの値を格納する。s2拠点保守員診断部12Bは、s0の監視部11からの情報、DB5053,54をもとに、対象候補となる複数の各拠点K保守員H側の現在最新の状態拠点3内に待機中か否か、保守対応を受け付け可能か否か等を診断または確認し、DB5053,54に反映する処理を行う。s3マッチング部12Cは、s1,s2の結果情報DB50をもとに、顧客U機器C側と拠点K保守員H側とにおける保守対応Pのマッチング判定処理図4を行う。s4診断部12は、s3の結果の候補から、当該保守対応Pを実際に担当させる拠点K保守員Hを所定人数例えば1人選択して決定し、DB5055等に反映する処理を行う。例えば55のgの値を格納する。s4で所定人数を選択する際には、例えばランダム、ラウンドロビン等、適当な手法を用いることができる。なおs3の結果で既に候補が1人などに絞られている場合はs4は不要とできる。なお対象の仕事Pに応じて担当者を1人ではなく複数人にすることもできる。s5指示部13は、s4の結果DB50に従い、該当の拠点K保守員H対応する設備31や携帯端末32へ保守対応Pの作業内容等を含む指示a2を送信する処理を行う。これにより、その後、当該指示a2に従って担当者により保守対応a3が実施される。[処理2]図4は、診断部12のマッチング部12C図3のs3の処理例を示す。マッチング部12Cは、図3の12A,12Bの処理結果情報DB50をもとに、顧客U機器C側と拠点K保守員H側とにおける保守対応のマッチング判定処理を所定のアルゴリズム設定a4に基づくにより行う。この判定は、大別して第1の条件判定s3-1、第2の条件判定s3-2、第3の条件判定s3-3がある。これにより、対象の顧客Uの機器21Cの保守対応Pのために、複数の拠点K保守員Hのうちのどの拠点Kのどの保守員Hを担当させるか候補を決定し、ここで決定した担当の情報をDB5054のe、55のg等に反映する。s3-1第1条件判定:まず基本条件必要条件として、当該保守対応の仕事が現在受付可能な状態であり、対象の機器Cのエラー等の状態に対処可能なスキルSを持ち、対象の顧客Uと同じ言語Wを使用する、等の観点から第1候補を抽出する。s401s401では、マッチング部12Cは、第1条件として、対象の保守対応の仕事Pにあたって、必要なスキルS、必要な言語Wを持ち、休みではなく拠点Kに待機中などの状態であり、当該時点で当該仕事P用の時間的な空きがあり受付可能な状態である第1条件を満たす保守員H及び対応拠点KをDB50から検索により抽出し、これを第1候補とする。s3-2第2条件判定:次にs3-2では、距離言い換えると時間の観点から判定し、第1候補から絞り込み、第2候補とする。対象の顧客Uの機器Cと、保守員Hの拠点Kとの距離Eがなるべく近いという第2条件を満たすものを第2候補とする。即ち、保守員Hが現場へ移動する際の時間が短くなるように選択する。s402s402では、s401の結果の第1候補の保守員Hが、同一の拠点Kに関係付けられる保守員であるかどうかを判断する。同一拠点である場合s402-Y、s403の判定は不要であるため、当該保守員を第2候補として、s3-3へ遷移する。s403s403では、第1候補の複数の保守員Hに関係付けられる複数の拠点KのエリアRまたは位置L、及び、対象の顧客Uの機器21CのエリアRまたは位置Lを確認するDB50内の51~54のエリアRまたは位置Lの情報を参照すればよい。ここではエリアRで判定する方式とする。そして、それぞれの候補について、顧客U機器C側と拠点K保守員H側の両者のエリアR間の距離Eを判定する。ここでは距離Eを所定長例えば5km毎で区分した範囲Fで判定する方式とする。そして、当該距離E範囲Fが一番近い拠点K及び対応する保守員Hを抽出選択し、これを第2候補とする。s3-3第3条件判定:次にs3-3では、センターシステム1で管理している複数の拠点K複数の保守員Hを含む全体の範囲で、保守対応の仕事に関する効率性負荷分散の観点から判定し、第2候補から絞り込み、第3候補とする。各拠点K内に待機人数を確保するとともに、特定の保守員Hに仕事が集中しないようにする。s404s404では、上記s3-2の結果の第2候補の拠点K保守員Hにおける仕事Pの負荷状態が概略同様であるかどうかを判断する。概略同様の負荷状態である場合s404-Y、s405以降の判定は不要であるため、当該保守員を第3候補として、s3-3の終わりへ遷移する。s405s405では、上記第2候補の保守員Hにおける1人任意選択の保守員Hiとするごとに、当該保守員Hiの対応拠点Kiとするの待機人数mを確認する。即ち当該保守員Hiを保守対応Pに担当させると仮定したとき、当該拠点Kiの現在の待機人数mから当該保守員Hi分を除いた人数m-1をみる。この仮定の待機人数が、所定人数例えば1以上確保されるかどうかを判断する。これは、効率性負荷分散の観点から、当該拠点Kiで保守対応の仕事を受けるために所定人数以上の待機人数を確保しておくことが望ましいからである。上記確保できない場合s405-N、s406で当該保守員Hiを候補から除外する。s407s407では、上記第2候補の保守員Hiごとに、保守対応の仕事の負荷が大きすぎないかどうかを確認する。即ち、当該保守員Hiが今回の保守対応の仕事Pを担当すると仮定したとき、当該保守員Hiに仕事が集中しすぎていたり、当該保守員Hiが何回も連続して仕事を受けていたりといったように、負荷が大きい状態を望ましくない状態として判定する。例えばDB50内の保守員の負荷の情報54のfを参照し、当該負荷のレベル等を閾値と比較して判定する。上記負荷が高い場合s407-Y、s408で当該保守員Hiを候補から除外する。上記のように一部の保守員の負荷が大きい状態は、全体的な効率性負荷分散の観点から望ましくないため、ここで除外される。s409s409では、上記第2候補の拠点K保守員H待機人数が十分確保され負荷も高すぎない状態における保守対応の仕事の負荷分散を判定する。例えば、複数の中から負荷が一番小さい拠点K保守員Hを選択し、これを第3候補とする。なお担当者はs4で最終的に決定するため、候補は複数人が選択されてもよい。例えば、拠点K単位の負荷分散の判定として、同じ範囲F同程度の距離Eに含まれる複数の拠点Kがある場合、それらのうち一番負荷が小さい拠点K対応する保守員Hを選択する。例えば、保守員H単位の負荷分散の判定として、同じ範囲Fや拠点Kの中の複数の保守員Hがいる場合、それらのうち一番負荷が小さい保守員Hを選択する。なお第3判定s3-3で、該当の候補が無くなる場合s410-Yは、例えば第2判定s3-2に戻り、距離の観点で次の候補次に距離が近いものを選択してやりなおす同様の処理の繰り返し。上述したマッチング判定のアルゴリズム図4は、先に距離第2条件を優先して考慮し次に負荷分散第3条件を考慮して担当候補を判定する形態の場合である。これに限らず、優先の順序を逆にし、先に負荷分散第3条件を優先して考慮し次に距離第2条件を考慮して担当候補を判定する形態も可能である。更に、距離時間や負荷分散の観点条件、効果のいずれを優先して担当候補を決定するかを、設定a4や指示入力や状態検知などによって可変に制御してもよい。例えば対象の機器21の状態が深刻であることを検知した場合や、顧客Uがヘルプデスク4に対して即時対応を要求している場合などには、距離優先で決定し、そうではない場合は負荷分散優先で決定する、等が挙げられる。[判定例]図6は、診断部12によるマッチング判定例を示す。図6のID値は図5の例と対応している。図6aは第1の例、図6bは第2の例を示す。星印はマッチング判定で選択される候補を示す。各拠点K1,K2,K3は、前述の距離E1,E2,E3の順に顧客UxCxのエリアRxLxから遠くなる場合である。顧客U側と拠点K側との距離Eの判定方式として、エリアR間の距離を判定する方式とするが、位置L間の距離を判定する方式としてもよい。また更に、距離Eの判定方式として、距離Eを細かく算出する方式としてもよいが、本実施の形態では、距離Eを所定の範囲Fとするに区分し、この距離区分範囲Fを単位として判定する方式を用いる。図6aで、距離Eの判定に関し、拠点K1E1,K2E2は範囲F1に含まれ、拠点K3E3は範囲F2に含まれ、Cxに対してF1K1,K2の方がF2K3よりも近い。図5と同様に各拠点K内に保守員HH1-1~H3-3がいる状態とする。また、これらの保守員は、いずれも、機器Cxの保守対応P1のためのスキルSa及び言語Waを持つとする。また、各保守員Hの負荷状態として、K1内のH1-1、K2内のH2-2、K3内のH3-3は負荷大であり、K2内のH2-1、K3内のH3-1,H3-2は負荷小であるとする。前述図4の制御処理により、図6aの第1の例では、第1候補は、必要スキルSa等持つ、図示する6人H1-1~H3-3となる。第2候補は、距離E範囲Fが近いF1に該当する3人H1-1,H2-1,H2-2となる。そして、第3候補は、F1の中で負荷状態が一番小さい条件に該当するH2-11人となる。なお、範囲F1の中で、負荷ではなく距離Eが近い方を優先する場合第2判定までの場合、K1内のH1-1が該当するが、H1-1を担当者としてしまうと、K1内の待機人数が0人になってしまうため、NG除外とする。そこで、K2内のH2-1は負荷が小さいため、OK第3候補となる。図6bでは、図6aと概略同様の状態であるが、K2内のH2-1,H2-2ともに負荷が大きい状態とする。前述図4の制御処理により、同様に、第1候補は図示する6人H1-1~H3-3となる。第2候補は、最初、距離E範囲Fが近いF1に該当する3人H1-1,H2-1,H2-2となる。しかし、これらの負荷状態はいずれも大きいため、NGとして、第2候補を決めなおし、次に近い範囲F2に該当する3人H3-1~H3-3となる。そして、第3候補は、範囲F2の中で負荷が一番小さい条件に該当するH3-1,H3-22人となる。例えばK2内のH2-1は近いが負荷が大きいためNGとなり、少し遠くても負荷が小さいH3-1等がOK第3候補となる。このように第2の例では、距離よりも負荷分散を優先するアルゴリズムとした場合である。[効果等]以上説明したように、本実施の形態のシステムによれば、複数の各拠点K保守員HにおけるスキルS言語W、顧客U機器Cとの距離E、及び動的な負荷分散などを考慮して保守対応の仕事Pのマッチング判定を行う機能により、保守対応の仕事の適切性、迅速性、及び複数の拠点K複数の保守員H間における全体的な効率性負荷分散を実現できる。以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。実施の形態の変形例として以下が挙げられる。1前述の処理例図4では、第2条件として距離を判定し、第3条件として負荷分散を判定したが、設定a4等に基づき、第1条件と第2条件のみで候補/担当を決定する形としてもよいし、第1条件と第3条件のみで候補/担当を決定する形としてもよい。2保守対応Pの仕事の対象の顧客U機器Cが前過去と同じである場合に、当該仕事の適切性効率性を考慮して、前過去と同じ担当者となるように決定してもよい。この場合、担当者となる保守員の負荷が大きくなる可能性があるが、例えば以降の他の仕事を他の保守員に担当させるように負荷分散することにより、当該保守員の負荷を抑制させる。例えばセンターシステム1内DB50に過去の担当の情報を履歴として保持しておき、マッチングの際に当該履歴情報を参照して判定することにより、上記のような処理を実現する。3マッチング判定で一旦担当者保守員H、拠点Kを決定した後、当該担当者の都合が悪くなり当該保守対応が実施できない場合などには、当該保守員等を除いて再度のマッチング判定を行ったり、あるいは順序付きで保持しておいた別の候補から選択して決定してもよい。4言語W等に関して、必須条件として判定するのではなく、例えば推奨条件として判定してもよい。例えば、スキルS等を必須条件や優先条件とし、言語Wを推奨条件なるべく顧客Uの言語Wと同じになるように考慮するとして候補を決定する。候補の保守員Hが顧客Uの言語Wと同じにならない場合は、例えば顧客Uの言語Wと同じである別の者を同行させるように複数人の担当者を決定する。設定a4により、距離優先や負荷分散優先だけでなく、スキル優先や言語優先などを同様に設定可能とする。5制御的にはより単純化した形態であるが、個別の担当者となる保守員Hを決定するのではなく、より大まかな単位として、担当させる1つの拠点Kを決定する形態も可能である。担当拠点Kの決定後は、その担当拠点K複数の保守員Hの中で任意に対応させる。6前記第2条件の距離の判定に関して、距離情報と時間情報とを関係付けてDB50に管理してもよい。この場合、前記第2条件の距離の判定は、直接的に時間判定になる。即ち、拠点K保守員H側から顧客U機器C側への移動時間が一番短いものを候補とするような形となる。"