JP2013069239A - 保守対応システム - Google Patents

Abstract

【課題】保守対応の適切性、迅速性、及び複数の拠点・複数の保守員間における保守対応の全体的な効率性・負荷分散を実現できる技術を提供する。
【解決手段】本システムのサーバの診断部は、管理情報（ＤＢ）等をもとに、対象の顧客の機器の保守対応のために、複数の拠点の複数の保守員の中から、担当者またはその候補となる拠点の保守員をマッチング判定する処理を行う。本処理において、第１条件（ｓ３−１）として、対象の顧客の機器の状態に応じた必要なスキルを持つ保守員を第１候補として選択し、第２条件（ｓ３−２）として、第１候補から、対象の顧客の機器との距離がなるべく近い拠点の保守員を第２候補として選択し、第３条件（ｓ３−３）として、第２候補から、複数の拠点または複数の保守員における保守対応の仕事の負荷分散が実現されるように、負荷がなるべく小さい拠点の保守員を第３候補として選択する。
【選択図】図４

Description

本発明は、顧客のコンピュータシステム（サーバ等のコンピュータ機器）を対象とした保守対応やヘルプデスク（顧客サポート）等の業務・サービスに係わる情報処理システム（保守対応システム）等に関し、特に、保守対応を行う保守員等（担当者）を決定する情報処理に関する。

従来、顧客のコンピュータシステムの保守対応やヘルプデスク等の業務・サービスに係わる保守対応システムの代表的な構成例として、対象の機器の状態を監視して、障害・エラー等の状態を検知した時、必要な復旧作業等の保守対応内容を判定し、保守対応を行う保守員を決定し、当該保守員へ保守対応の指示情報を通知する、といったシステムが挙げられる。

先行技術例として、特開２００２−２０３０６４号公報（特許文献１）などがある。特許文献１（「保守管理システム」等）では、課題として、保守員を適切に有効活用して効率的な保守を行うことが記載されている。解決手段として、機器の障害を監視し通知する遠隔監視制御システムと、保守員の位置情報を保持するシステムと、保守員の保守能力情報を保持するシステムと、機器の障害内容に対応して各保守能力の保守員へ提供すべき情報を保持するシステムと、保守員が携帯する無線端末とを有し、障害発生が通知されると、保守員の位置情報に基づき、障害発生位置に近い保守員を選び（リスティング）、選んだ保守員の保守能力情報を取り出し、取り出された保守員の保守能力情報に基づき、対応保守マニュアル情報を該当の無線端末へ送信することが記載されている。障害が通知された際に、障害発生場所に近い保守員から保守能力に応じて候補が絞られ、候補に対し対応する保守保全マニュアル情報が送られることが記載されている。また、保守能力情報の高い保守員の情報から先に取り出すことが記載されている。また、送信先の無線端末から応答が得られない場合に、次候補の保守員へ情報を送信することが記載されている。

特開２００２−２０３０６４号公報

前述の従来の保守対応システムでは、以下のような課題がある。

従来のシステムにおいて、例えば顧客のサーバ等のコンピュータ機器の障害状態を監視で検知した場合などに、例えば当該機器の復旧作業等の保守対応のために、保守員等の担当者が現地（当該機器が設置されている場所）へ訪問し、保守対応を実施する。その際、当該保守員は、最寄りの拠点（保守対応拠点）から現地へ派遣される。拠点は、保守員が保守対応の業務のために通常待機（スタンバイ）している場所・施設等である。保守員は、指示を受けると、最寄りの拠点から、保守作業に必要な保守部品などを携えて、現地へ移動し、保守作業等を実施する。

しかし、上記拠点で待機する保守員（要求されている保守対応のための適切なスキル等を持つ保守員）が不足する場合、要求されている保守対応を迅速に実現できない場合がある。例えば、複数の拠点のうち一部の拠点で待機している保守員が不足したり、拠点内の複数の保守員のうち一部の保守員に担当が集中したり、といったように、仕事の負荷が偏る場合がある。従来のシステムは、複数の保守員・複数の拠点間における仕事（保守対応）の効率性や負荷分散などについては不十分である。

また、顧客の機器の適切な保守対応のために、適切なスキルや言語を持つ保守員を担当させることが好ましいが、拠点に適切なスキルや言語を持つ保守員が待機しているとは限らず、適切な保守対応、迅速な保守対応を実現できない場合がある。スキルについては、対象の機器（サーバ等）の復旧作業等のための知識などが要求される。言語については、顧客とのコミュニケーション（会話などを含む）で顧客の使用する言語（例えば地域などによって異なる）によってはうまくコミュニケーションできず時間を要してしまう場合がある。

また例えば特許文献１では、機器の保守対応を行う保守員を決めるにあたり、要因として、保守員の位置と保守能力（スキルレベル）を考慮している。これにより、保守対応の迅速性や、能力的に適切な保守員の選択（担当）を実現している。しかしながら、これら要因の考慮だけでは、複数の保守員・複数の拠点間における仕事（保守対応）の効率性や負荷分散などについては不十分である。

以上を鑑み、本発明の主な目的は、保守対応（仕事）の適切性、迅速性、及び複数の拠点・複数の保守員間における保守対応（仕事）の全体的な効率性・負荷分散を実現できる技術を提供することである。

上記目的を達成するため、本発明のうち代表的な形態は、顧客のコンピュータシステム（サーバ等のコンピュータ機器）を対象とした保守対応やヘルプデスク（顧客サポート）等の業務・サービスに係わる情報処理システム（保守対応システム）、等であって、以下に示す構成を有することを特徴とする。

本システムは、複数の拠点の複数の保守員の中から顧客の機器の保守対応を行う担当者を決定する機能を持つ情報処理装置を有する。情報処理装置は、診断部と、管理情報を格納するＤＢとを有し、例えば外部から保守対応の要求の情報を入力する。診断部は、管理情報または入力情報をもとに、対象の顧客の機器の状態、必要な保守対応の内容及び条件を診断または確認する第１の処理と、管理情報または入力情報をもとに、複数の拠点と複数の保守員の最新の状態を診断または確認する第２の処理と、第１、第２の処理をもとに、対象の顧客の機器の保守対応のために、複数の拠点の複数の保守員の中から、担当者またはその候補となる拠点の保守員をマッチング判定する第３の処理とを行う。第３の処理において、第１条件として、必要な保守対応の条件として、対象の顧客の機器の状態に応じた必要なスキルを持つ保守員を第１候補として選択し、第２条件として、第１候補から、対象の顧客の機器との距離がなるべく近い拠点の保守員を第２候補として選択し、第３条件として、第２候補から、複数の拠点または複数の保守員における保守対応の仕事の負荷分散が実現されるように、負荷がなるべく小さい拠点の保守員を第３候補として選択する。

本発明のうち代表的な形態によれば、保守対応（仕事）の適切性、迅速性、及び複数の拠点・複数の保守員間における保守対応（仕事）の全体的な効率性・負荷分散を実現できる。

本発明の一実施の形態のシステム（保守対応システム）の全体の構成を示す図である。 本実施の形態のシステムにおける、管理情報（ＤＢ）の構成例を示す図である。 本実施の形態のシステムにおける、サーバ（制御部）の処理フローを示す図である。 本実施の形態のシステムにおける、診断部の処理フローを示す図である。 顧客・機器と複数の拠点・保守員との関係の一例（イメージ）を示す図である。 （ａ），（ｂ）は、マッチング判定の一例（イメージ）を示す図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。なお説明上、適宜、Ｕ：顧客、Ｃ：機器、Ｋ：拠点、Ｈ：保守員、といった記号を使用する。

＜概要等＞
本実施の形態のシステム（図１等）は、保守対応（仕事）に関する動的負荷分散を含む効率的なマッチング機能を持つ。この機能では、顧客コンピュータ機器の保守対応のために担当させる保守員・拠点を、保守員のスキルや言語、顧客機器との距離（位置）、及び全体的な負荷状態などの要因を考慮してマッチングし決定する。特に、複数の拠点の複数の保守員の間における仕事の負荷分散の状態になるように自動的に判断される。

本例では特に、対象の顧客コンピュータ機器が固定的なサーバでありその障害・エラー等の場合の保守対応を実施する例を用いて説明する。

［システム］
図１において、本実施の形態のシステムの全体の構成を示している。本システム全体は、センターシステム１と、顧客システム２と、拠点（保守対応拠点）３と、ヘルプデスクシステム４とを有し、これらがインターネット、無線網、あるいは専用線などのネットワーク５，６で接続されている。

（１） センターシステム１は、主制御システム部分であり、サーバ１０及び管理情報（ＤＢ）５０を有する。サーバ１０は、処理部として、監視部１１、診断部１２、指示部１３を有し、管理情報（ＤＢ）５０を管理・読み書きして処理を行う。診断部１２は、詳しくは、顧客機器診断部１２Ａ、拠点保守員診断部１２Ｂ、マッチング部１２Ｃを有する。管理情報（ＤＢ）５０は、詳しくは、顧客情報５１、機器情報５２、拠点情報５３、保守員情報５４、保守対応情報５５を含む。なおＤＢ５０の各情報（５１〜５５）を管理するためのサブシステムを設けてもよい（既存のサブシステムを利用してもよい）。

監視部１１は、顧客システム２側の監視対象の機器２１のエージェント２２と連携して、監視対象の機器２１の監視処理を行う。監視部１１は、エージェント２２から監視情報（ａ１）を受信して記録すると共に、監視情報（ａ１）の内容から機器２１の障害・エラー等の状態や負荷状態などを判断・検知する。

診断部１２は、監視部１１の処理結果及びＤＢ５０をもとに、本特徴的な診断処理（後述）を行い、対象の顧客（Ｕ）・機器２１（Ｃ）の保守対応のために担当させる拠点（Ｋ）・保守員（Ｈ）を決定する。診断部１２での制御内容（マッチング判定の際のアルゴリズム等）は、設定（ａ４）により変更可能となっている。設定（ａ４）は例えばセンターシステム１の設定者により設定用Ｗｅｂページでアルゴリズム（判定方式）を選択したりそのパラメータ値（例えば距離（時間）や負荷分散などの優先する観点や、判定用の閾値など）を変更する形などである（後述）。

指示部１３は、診断部１２の処理結果（どの拠点のどの保守員を保守対応の担当者とするか）をもとに、保守対応に係わる指示（ａ２）を対象の拠点３（３１，３２）へ送信する処理や、保守対応用設備（３１）や保守員の携帯端末３２から当該拠点や保守員の状態などの情報を取得する処理を行う。

（２） 顧客システム２は、顧客（Ｕ）が利用する情報処理システムであり、例えば顧客企業内に構築された業務用システム等であり、少なくとも顧客コンピュータ機器２１（「機器」と略す）を有する。機器２１は、センターシステム１により監視・保守の対象となる、例えばサーバ等であり、顧客システム２内に固定的に設置されている。なお、顧客システム２（機器２１）は、上記顧客企業内システムに限らず、データセンタ等を利用する形でもよい。この場合はデータセンタ内の機器が監視・保守の対象となる。

機器２１では、業務処理などが行われると共に、エージェント２１が稼働する。エージェント２２は、例えばソフトウェアプログラム処理で実現される。エージェント２２は、監視部１１と連携し、機器２１の動作・状態を監視する。例えば、エージェント２２は、設定情報に基づき、機器２１の動作・状態を表す監視情報（ａ１）を発行してネットワーク５を介してサーバ１０（監視部１１）へ送信する。なお、エージェント２２は、機器２１とは別の装置やそのプログラム処理などで実現されてもよい。監視情報ａ１は、例えば、機器２１のＩＤ，状態、位置などの情報を含む。なお機器２１の位置情報の送信は、予めセンターシステム１側で当該位置情報が登録・管理されている場合は必要無い。

（３） 複数の各拠点３（Ｋ）は、保守員（Ｈ）が保守対応の業務のために待機する地理的な拠点であり、保守対応用設備３１や保守部品３３（ストック）を備える。各保守員（Ｈ）は、保守対応の業務用に、携帯端末３２を所持する。保守対応用設備３１は、センターシステム１（指示部１３）からの指示（ａ２）を受信し、当該指示（ａ２）に対応する保守対応指示情報を、当該拠点３内の保守員（Ｈ）に対して出力（一覧表示、報知、あるいは保守員の携帯端末３２への情報送信等）する。拠点３の保守員（Ｈ）は、保守対応の指示を受けた場合、携帯端末３２及び必要な保守部品３３を持ちつつ、対象の顧客（Ｕ）の顧客システム２の機器２１へ出向き、保守対応のコミュニケーションや作業などを実施する（ａ３）。

携帯端末３２は、保守対応の業務用のアプリケーションを備えており、画面に、保守対応指示（例えば日時、顧客（Ｕ）、機器２１（Ｃ）などの指定）や、保守対応の具体的な作業内容等の指示（例えばエラー等の箇所、復旧手順、詳細情報など）の情報を表示する。また保守員（Ｈ）は、携帯端末３２の画面に保守対応の状況（例えば未完了／済みなど）を入力し、拠点３（３１）や、センターシステム１等へ状況を伝えることができる。これにより、センターシステム１等は、保守対応の仕事の指示に対しての当該仕事の未完了／済みなどの状態を把握できる。

なお保守対応用設備３１を省略する形態や、携帯端末３２を省略する形態とすることができる。保守対応用設備３１を省略する形態の場合は、センターシステム１から携帯端末３２へ直接的に指示（ａ２）を送信してもよい。

（４） ヘルプデスクシステム４は、公知のシステムであり、各要素（１，２，３）と接続され、顧客（Ｕ）からの電話やＷｅｂ等での問い合わせに対して応対者により応対し、センターシステム１や拠点３と連携しながら、保守対応に係わる顧客サポートを行う。なお本システムは、ヘルプデスクシステム４を無くした形態、ヘルプデスクシステム４とセンターシステム１を統合した形態も可能である。

（１２） 診断部１２において、顧客機器診断部１２Ａは、監視部１１で検知したエラー状態などの情報をもとに、当該顧客（Ｕ）・機器２１側の状態に応じた、必要な保守対応の内容（復旧作業など）を診断または確認する。なお監視部１１で診断済みの場合は１２Ａは不要である。

拠点保守員診断部１２Ｂは、監視部１１によるエラー状態などの検知時に、複数の各拠点３（Ｋ）・保守員（Ｈ）側の現在（リアルタイム）の状態（例えば拠点内に待機中か否か、保守対応を受け付け可能か否か等）を診断または確認する。当該確認は、随時実行しておくこととしてもよい。特に保守対応の迅速化の観点から、予め各拠点３等から情報を取得して最新の状況を確認し必要な情報を保持しておくとよい。

マッチング部１２Ｃは、１２Ａと１２Ｂの処理結果（マッチングのための基本的な前提条件の確認）をもとに、本特徴的な保守対応のマッチング判定処理（後述）を所定のアルゴリズム（ａ４で設定可能）により行う。これにより、当該顧客（Ｕ）の機器２１（Ｃ）の保守対応のために、複数の拠点（Ｋ）・保守員（Ｈ）のうちのどの拠点のどの保守員を担当させるかをマッチング（決定）する。これにより、全体的な仕事の負荷分散を含めて考慮した好適な担当者が決定される。

［管理情報］
図２は、管理情報（ＤＢ）５０（５１〜５５）の構成例を示す。なお下記の各情報要素の管理は適宜統合・分離してもよい。なお図５には各ＩＤ（Ｕ，Ｃ，Ｋ，Ｈ等）の値の具体例を示している。

（５１） 顧客情報５１は、（ａ）顧客ＩＤ、（ｂ）エリア／地域ＩＤ、（ｃ）言語、（ｄ）状態、の各情報を含む。

（ａ）顧客ＩＤは、顧客（Ｕ）ないし顧客システム２を識別する情報である。例えばＵｘ等で示す。（ｂ）エリア／地域ＩＤは、顧客システム２（機器２１）の存在するエリア／地域を識別する情報である。例えばＲｘ等で示す。（ｃ）言語は、顧客（Ｕ）ないし顧客システム２の使用する言語（日本語、英語など）を識別する情報である。例えばＷｘ等で示す。（ｄ）状態は、顧客（Ｕ）の状態として、例えば保守対応の要求の有無などを示す。

（５２） 機器情報５２は、（ａ）機器ＩＤ、（ｂ）位置、（ｃ）構成情報／属性情報、（ｄ）状態、各情報を含む。

（ａ）機器ＩＤは、機器２１の識別情報である。例えばＣｘ等で示す。（ｂ）位置は、当該機器２１の位置情報（例えばＧＰＳによる）である。例えばＬｘ等で示す。なお５１のｂのエリア（Ｒ）の情報と５２のｂの位置（Ｌ）の情報は対応しており、置き換えてもよいし、一方のみの管理としてもよい。ｂの位置情報は、予め設定してもよいし、監視情報（ａ１）により随時取得してもよい。

（ｃ）構成情報／属性情報は、機器２１の構成や属性を示す情報であり、例えば種別がサーバであることを示す情報や、構成要素の部品の識別情報などを有する。（ｄ）状態は、機器２１の正常や障害・エラー等の状態を表すコードや、負荷状態を示す情報や、保守対応必要有無を示す情報などがある。

（５３） 拠点情報５３は、（ａ）拠点ＩＤ、（ｂ）エリア／地域、（ｃ）位置、（ｄ）保守員ＩＤ、（ｅ）状態、の各情報を含む。

（ａ）拠点ＩＤは、拠点３を識別する情報である。例えばＫ１等で示す。（ｂ）エリア／地域ＩＤは、当該拠点３が存在するエリア／地域の識別情報である。Ｒ１等で示す。（ｃ）位置は、当該拠点３が存在する位置の位置情報（ＧＰＳ等による）である。前述同様にＲとＬは一方のみの管理でもよい。

（ｄ）保守員ＩＤは、当該拠点３（Ｋ）に関係付けられる保守員（Ｈ）の識別情報である。例えばＨ１−１，Ｈ１−２等で示す。本実施の形態では、（ｄ）保守員ＩＤは、当該拠点３に所属（基本的に待機）する複数の保守員（Ｈ）を示す。（ｅ）状態は、当該拠点３の状態として、当該拠点３に現在待機中の状態の保守員（Ｈ）のＩＤリストや、待機中の人数（ｍ）などの情報がある。

（５４） 保守員情報５４は、（ａ）保守員ＩＤ、（ｂ）スキル、（ｃ）言語、（ｄ）状態、（ｅ）担当、（ｆ）負荷、の各情報を含む。その他、保守員（携帯端末３２）の位置をＧＰＳ等で管理する形態の場合はその位置情報（Ｌ）を含む。

（ａ）保守員ＩＤは、保守員（Ｈ）の識別情報である。例えばＨ１−１等で示す。（ｂ）スキルは、当該保守員の保守対応に係わるスキルセット（能力）を示す情報である。例えばＳａ等で示す。例えば保守対応可能な機器２１の種別や、機器２１の知識や復旧作業に関するスキルを示す。（ｃ）言語は、当該保守員の使用する言語（日本語、英語等）を示す。例えばＷａ等で示す。

（ｄ）状態は、当該保守員の最新の状態として、当該保守員が所属する拠点（Ｋ）内に待機中か当該拠点（Ｋ）外に外出中か（最寄り拠点に居る／居ない）、等の状態を示す情報である。あるいは、当該保守員が、現在、保守対応用の時間が空いているか否か（新たな仕事を受け付け可能か否か）、仕事が休みかどうか、等の状態を示す情報である。

なお保守員（Ｈ）と拠点（Ｋ）との関係は、基本的には特定の拠点に所属する形とするが、ある保守員は複数の拠点に寄る（待機する）こともできる。その場合、どの拠点（Ｋ）に待機しているかを含めて情報を管理すればよい。

（ｅ）担当は、当該保守員が現在担当している保守対応の仕事（５５で管理される単位）に関する情報であり、保守対応ＩＤ（Ｐ１等）等で示される。

（ｆ）負荷は、状態の一種であるが、当該保守員の保守対応の仕事の負荷の大きさを示す情報である。負荷の情報は、例えば、大／中／小といったレベル値で管理してもよいし、当該保守員が担当している保守対応の仕事（５５で管理される単位）の数や量や、連続で担当している回数などで表してもよい。

なお拠点（Ｋ）ごとの状況、及び複数の拠点（Ｋ）を含む全体的な状況は、拠点情報５３、保守員情報５４を参照することでわかる。

（５５） 保守対応情報５５は、個々の保守対応の仕事を管理する情報であり、（ａ）保守対応ＩＤ、（ｂ）顧客ＩＤ、（ｃ）機器ＩＤ、（ｄ）状態コード、（ｅ）作業内容、（ｆ）必要条件、（ｇ）担当、（ｈ）状態、の各情報を含む。その他、仕事の期日などの時間情報を管理してもよい。

（ａ）保守対応ＩＤは、当該保守対応の仕事を識別する情報である。例えばＰ１等で示す。（ｂ）顧客ＩＤは、当該保守対応（Ｐ）の仕事の対象となる顧客（Ｕ）を示す識別情報である。（ｃ）機器ＩＤは、当該保守対応（Ｐ）の仕事の対象となる機器２１（Ｃ）の識別情報である。（ｄ）状態コードは、当該機器２１（Ｃ）の障害・エラー等の状態を示すコードであり、５２のｄの状態と対応する。（ｅ）作業内容は、当該保守対応（Ｐ）の作業内容を示す情報であり、例えば、ｄの状態コードに応じた復旧等の作業手順を示す情報であり、必須ではないが、例えば担当の保守員（Ｈ）の携帯端末３２へ提供してガイド情報として用いる。

（ｆ）必要条件は、当該保守対応（Ｐ）に係わる必要な条件を示し、例えば、必要保守部品（ｂ１等）、必要スキル（Ｓａ等）、必要言語（Ｗａ等）、等の情報がある。必要保守部品（ｂ１等）は、当該保守対応（Ｐ）で必要な交換部品などであり、拠点３に備える保守部品３３を用いる。必要スキル（Ｓａ等）は、当該保守対応（Ｐ）で必要な保守員（Ｈ）のスキルを示す。必要言語（Ｗａ等）は、当該保守対応（Ｐ）で当該顧客（Ｕ）とのコミュニケーションや当該機器２１の操作のために必要とされる言語を示す。なお、言語（Ｗ）については、必要条件とせずに推奨条件としてもよい。また言語（Ｗ）をスキル（Ｓ）の概念の中に含めて管理してもよい。

（ｇ）担当は、当該保守対応（Ｐ）の仕事を担当する拠点（Ｋ）・保守員（Ｈ）の識別情報（Ｋ１，Ｈ１−１等）などである。（ｈ）状態は、当該保守対応（Ｐ）の仕事の状態として、未完／済み等がある。

［具体例］
図５は、顧客（Ｕ）・機器（Ｃ）と複数の拠点（Ｋ）・保守員（Ｈ）との関係の一例を示す。エリアＲｘ（位置Ｌｘ）に、対象の顧客Ｕｘの顧客システム２・機器２１（Ｃｘ）がある。機器Ｃｘのエラー状態（００１）に関する保守対応（Ｐ１）のために、必要部品がｂ１、必要スキルがＳａであり、顧客Ｕｘの使用言語（必要言語）がＷａである。

複数の各拠点３（Ｋ）として、例えばＫ１，Ｋ２，Ｋ３を有し、それぞれエリアＲ（位置Ｌ）がＲ１（Ｌ１），Ｒ２（Ｌ２），Ｒ３（Ｌ３）である。これらそれぞれの、顧客Ｕｘ・機器Ｃｘ側のエリアＲｘ（Ｌｘ）との距離（Ｅとする）をＥ１，Ｅ２，Ｅ３とする。

拠点Ｋ１は、所属する保守員として、Ｈ１−１，Ｈ１−２等を有し、例えばＨ１−１は待機中、Ｈ１−２は外出中であり、Ｋ１内の待機人数（ｍ）が１である。拠点Ｋ２は、所属する保守員として、Ｈ２−１，Ｈ２−２等を有し、例えばいずれも待機中であり、Ｋ２内の待機人数（ｍ）が２である。拠点Ｋ３は、所属する保守員として、Ｈ３−１，Ｈ３−２，Ｈ３−３等を有し、例えばいずれも待機中であり、Ｋ３内の待機人数（ｍ）が３である。

［処理（１）］
図３は、本システムにおけるサーバ（制御部）１０の処理例を示す（ｓ１等は処理ステップを示す）。

（ｓ０） まず前提（トリガ）として、前述のように、監視部１１が、監視情報ａ１から対象の顧客（Ｕ）側の機器２１（Ｃ）の障害・エラー等の状態を判断・検知し、ＤＢ５０の顧客情報５１や機器情報５２に当該情報を反映する。あるいは別のトリガとして、ヘルプデスクシステム４から保守対応の依頼が入る。

（ｓ１） 顧客機器診断部１２Ａは、ｓ０の監視部１１からの情報（例：顧客ＩＤ、機器ＩＤ、エラー状態を示すコードなど）、ＤＢ５０（５１，５２）をもとに、対象の顧客（Ｕ）・機器（Ｃ）側の状態と、当該状態に応じた必要な保守対応（Ｐ）の作業内容、必要条件（必要保守部品、必要スキル、必要言語など）を診断または確認し、ＤＢ５０（保守対応情報５５等）に反映する処理を行う。例えば５５のａ〜ｆの値を格納する。

（ｓ２） 拠点保守員診断部１２Ｂは、ｓ０の監視部１１からの情報、ＤＢ５０（５３，５４）をもとに、対象（候補）となる複数の各拠点（Ｋ）・保守員（Ｈ）側の現在（最新）の状態（拠点３内に待機中か否か、保守対応を受け付け可能か否か等）を診断または確認し、ＤＢ５０（５３，５４）に反映する処理を行う。

（ｓ３） マッチング部１２Ｃは、ｓ１，ｓ２の結果情報（ＤＢ５０）をもとに、顧客（Ｕ）・機器（Ｃ）側と拠点（Ｋ）・保守員（Ｈ）側とにおける保守対応（Ｐ）のマッチング判定処理（図４）を行う。

（ｓ４） 診断部１２は、ｓ３の結果の候補から、当該保守対応（Ｐ）を実際に担当させる拠点（Ｋ）・保守員（Ｈ）を所定人数（例えば１人）選択して決定し、ＤＢ５０（５５等）に反映する処理を行う。例えば５５のｇの値を格納する。ｓ４で所定人数を選択する際には、例えばランダム、ラウンドロビン等、適当な手法を用いることができる。なおｓ３の結果で既に候補が１人などに絞られている場合はｓ４は不要とできる。なお対象の仕事（Ｐ）に応じて担当者を１人ではなく複数人にすることもできる。

（ｓ５） 指示部１３は、ｓ４の結果（ＤＢ５０）に従い、該当の拠点（Ｋ）・保守員（Ｈ）（対応する設備３１や携帯端末３２）へ保守対応（Ｐ）の作業内容等を含む指示（ａ２）を送信する処理を行う。これにより、その後、当該指示（ａ２）に従って担当者により保守対応（ａ３）が実施される。

［処理（２）］
図４は、診断部１２のマッチング部１２Ｃ（図３のｓ３）の処理例を示す。マッチング部１２Ｃは、図３の１２Ａ，１２Ｂの処理結果情報（ＤＢ５０）をもとに、顧客（Ｕ）・機器（Ｃ）側と拠点（Ｋ）・保守員（Ｈ）側とにおける保守対応のマッチング判定処理を所定のアルゴリズム（設定ａ４に基づく）により行う。この判定は、大別して第１の条件判定（ｓ３−１）、第２の条件判定（ｓ３−２）、第３の条件判定（ｓ３−３）がある。これにより、対象の顧客（Ｕ）の機器２１（Ｃ）の保守対応（Ｐ）のために、複数の拠点（Ｋ）・保守員（Ｈ）のうちのどの拠点（Ｋ）のどの保守員（Ｈ）を担当させるか（候補）を決定し、ここで決定した担当の情報をＤＢ５０（５４のｅ、５５のｇ等）に反映する。

（ｓ３−１） 第１条件判定： まず基本条件（必要条件）として、当該保守対応の仕事が現在受付可能な状態であり、対象の機器（Ｃ）のエラー等の状態に対処可能なスキル（Ｓ）を持ち、対象の顧客（Ｕ）と同じ言語（Ｗ）を使用する、等の観点から第１候補を抽出する。

（ｓ４０１） ｓ４０１では、マッチング部１２Ｃは、第１条件として、対象の保守対応の仕事（Ｐ）にあたって、必要なスキル（Ｓ）、必要な言語（Ｗ）を持ち、休みではなく拠点（Ｋ）に待機中などの状態であり、当該時点で当該仕事（Ｐ）用の時間的な空きがあり受付可能な状態である第１条件を満たす保守員（Ｈ）及び対応拠点（Ｋ）をＤＢ５０から検索により抽出し、これを第１候補とする。

（ｓ３−２） 第２条件判定： 次にｓ３−２では、距離（言い換えると時間）の観点から判定し、第１候補から絞り込み、第２候補とする。対象の顧客（Ｕ）の機器（Ｃ）と、保守員（Ｈ）の拠点（Ｋ）との距離（Ｅ）がなるべく近いという第２条件を満たすものを第２候補とする。即ち、保守員（Ｈ）が現場へ移動する際の時間が短くなるように選択する。

（ｓ４０２） ｓ４０２では、ｓ４０１の結果の第１候補の保守員（Ｈ）が、同一の拠点（Ｋ）に関係付けられる保守員であるかどうかを判断する。同一拠点である場合（ｓ４０２−Ｙ）、ｓ４０３の判定は不要であるため、当該保守員を第２候補として、ｓ３−３へ遷移する。

（ｓ４０３） ｓ４０３では、第１候補の複数の保守員（Ｈ）に関係付けられる複数の拠点（Ｋ）のエリアＲ（または位置Ｌ）、及び、対象の顧客（Ｕ）の機器２１（Ｃ）のエリアＲ（または位置Ｌ）を確認する（ＤＢ５０内の５１〜５４のエリアＲまたは位置Ｌの情報を参照すればよい）。ここではエリアＲで判定する方式とする。

そして、それぞれの候補について、顧客（Ｕ）・機器（Ｃ）側と拠点（Ｋ）・保守員（Ｈ）側の両者のエリアＲ間の距離Ｅを判定する。ここでは距離Ｅを所定長（例えば５ｋｍ毎）で区分した範囲Ｆで判定する方式とする。そして、当該距離Ｅ（範囲Ｆ）が一番近い拠点（Ｋ）及び対応する保守員（Ｈ）を抽出（選択）し、これを第２候補とする。

（ｓ３−３） 第３条件判定： 次にｓ３−３では、センターシステム１で管理している複数の拠点（Ｋ）・複数の保守員（Ｈ）を含む全体の範囲で、保守対応の仕事に関する効率性・負荷分散の観点から判定し、第２候補から絞り込み、第３候補とする。各拠点（Ｋ）内に待機人数を確保するとともに、特定の保守員（Ｈ）に仕事が集中しないようにする。

（ｓ４０４） ｓ４０４では、上記ｓ３−２の結果の第２候補の拠点（Ｋ）・保守員（Ｈ）における仕事（Ｐ）の負荷状態が概略同様であるかどうかを判断する。概略同様の負荷状態である場合（ｓ４０４−Ｙ）、ｓ４０５以降の判定は不要であるため、当該保守員を第３候補として、ｓ３−３の終わりへ遷移する。

（ｓ４０５） ｓ４０５では、上記第２候補の保守員（Ｈ）における１人（任意選択）の保守員（Ｈｉとする）ごとに、当該保守員Ｈｉの対応拠点（Ｋｉとする）の待機人数（ｍ）を確認する。即ち当該保守員Ｈｉを保守対応（Ｐ）に担当させると仮定したとき、当該拠点Ｋｉの現在の待機人数（ｍ）から当該保守員Ｈｉ分を除いた人数（ｍ−１）をみる。この仮定の待機人数が、所定人数（例えば１）以上確保されるかどうかを判断する。これは、効率性・負荷分散の観点から、当該拠点Ｋｉで保守対応の仕事を受けるために所定人数以上の待機人数を確保しておくことが望ましいからである。上記確保できない場合（ｓ４０５−Ｎ）、ｓ４０６で当該保守員Ｈｉを候補から除外する。

（ｓ４０７） ｓ４０７では、上記第２候補の保守員（Ｈｉ）ごとに、保守対応の仕事の負荷が大きすぎないかどうかを確認する。即ち、当該保守員Ｈｉが今回の保守対応の仕事（Ｐ）を担当すると仮定したとき、当該保守員Ｈｉに仕事が集中しすぎていたり、当該保守員Ｈｉが何回も連続して仕事を受けていたりといったように、負荷が大きい状態を望ましくない状態として判定する。例えばＤＢ５０内の保守員の負荷の情報（５４のｆ）を参照し、当該負荷のレベル等を閾値と比較して判定する。上記負荷が高い場合（ｓ４０７−Ｙ）、ｓ４０８で当該保守員Ｈｉを候補から除外する。上記のように一部の保守員の負荷が大きい状態は、全体的な効率性・負荷分散の観点から望ましくないため、ここで除外される。

（ｓ４０９） ｓ４０９では、上記第２候補の拠点（Ｋ）・保守員（Ｈ）（待機人数が十分確保され負荷も高すぎない状態）における保守対応の仕事の負荷分散を判定する。例えば、複数の中から負荷が一番小さい拠点（Ｋ）・保守員（Ｈ）を選択し、これを第３候補とする。なお担当者はｓ４で最終的に決定するため、候補は複数人が選択されてもよい。

例えば、拠点Ｋ単位の負荷分散の判定として、同じ範囲Ｆ（同程度の距離Ｅ）に含まれる複数の拠点Ｋがある場合、それらのうち一番負荷が小さい拠点Ｋ（対応する保守員Ｈ）を選択する。

例えば、保守員Ｈ単位の負荷分散の判定として、同じ範囲Ｆや拠点Ｋの中の複数の保守員Ｈがいる場合、それらのうち一番負荷が小さい保守員Ｈを選択する。

なお第３判定（ｓ３−３）で、該当の候補が無くなる場合（ｓ４１０−Ｙ）は、例えば第２判定（ｓ３−２）に戻り、距離の観点で次の候補（次に距離が近いもの）を選択してやりなおす（同様の処理の繰り返し）。

上述したマッチング判定のアルゴリズム（図４）は、先に距離（第２条件）を優先して考慮し次に負荷分散（第３条件）を考慮して担当（候補）を判定する形態の場合である。これに限らず、優先の順序を逆にし、先に負荷分散（第３条件）を優先して考慮し次に距離（第２条件）を考慮して担当（候補）を判定する形態も可能である。更に、距離（時間）や負荷分散の観点（条件、効果）のいずれを優先して担当（候補）を決定するかを、設定（ａ４）や指示入力や状態検知などによって可変に制御してもよい。例えば対象の機器２１の状態が深刻であることを検知した場合や、顧客（Ｕ）がヘルプデスク（４）に対して即時対応を要求している場合などには、距離優先で決定し、そうではない場合は負荷分散優先で決定する、等が挙げられる。

［判定例］
図６は、診断部１２によるマッチング判定例を示す。図６のＩＤ値は図５の例と対応している。図６（ａ）は第１の例、図６（ｂ）は第２の例を示す。星印はマッチング判定で選択される候補を示す。

各拠点Ｋ１，Ｋ２，Ｋ３は、前述の距離Ｅ１，Ｅ２，Ｅ３の順に顧客Ｕｘ（Ｃｘ）のエリアＲｘ（Ｌｘ）から遠くなる場合である。顧客Ｕ側と拠点Ｋ側との距離Ｅの判定方式として、エリアＲ間の距離を判定する方式とするが、位置Ｌ間の距離を判定する方式としてもよい。また更に、距離Ｅの判定方式として、距離Ｅを細かく算出する方式としてもよいが、本実施の形態では、距離Ｅを所定の範囲（Ｆとする）に区分し、この距離区分範囲Ｆを単位として判定する方式を用いる。

図６（ａ）で、距離Ｅの判定に関し、拠点Ｋ１（Ｅ１），Ｋ２（Ｅ２）は範囲Ｆ１に含まれ、拠点Ｋ３（Ｅ３）は範囲Ｆ２に含まれ、Ｃｘに対してＦ１（Ｋ１，Ｋ２）の方がＦ２（Ｋ３）よりも近い。図５と同様に各拠点Ｋ内に保守員Ｈ（Ｈ１−１〜Ｈ３−３）がいる状態とする。また、これらの保守員は、いずれも、機器Ｃｘの保守対応（Ｐ１）のためのスキルＳａ及び言語Ｗａを持つとする。また、各保守員Ｈの負荷状態として、Ｋ１内のＨ１−１、Ｋ２内のＨ２−２、Ｋ３内のＨ３−３は負荷大であり、Ｋ２内のＨ２−１、Ｋ３内のＨ３−１，Ｈ３−２は負荷小であるとする。

前述（図４）の制御処理により、図６（ａ）の第１の例では、第１候補は、必要スキルＳａ等持つ、図示する６人（Ｈ１−１〜Ｈ３−３）となる。第２候補は、距離Ｅ（範囲Ｆ）が近いＦ１に該当する３人（Ｈ１−１，Ｈ２−１，Ｈ２−２）となる。そして、第３候補は、Ｆ１の中で負荷状態が一番小さい条件に該当するＨ２−１（１人）となる。

なお、範囲Ｆ１の中で、負荷ではなく距離Ｅが近い方を優先する場合（第２判定までの場合）、Ｋ１内のＨ１−１が該当するが、Ｈ１−１を担当者としてしまうと、Ｋ１内の待機人数が０人になってしまうため、ＮＧ（除外）とする。そこで、Ｋ２内のＨ２−１は負荷が小さいため、ＯＫ（第３候補）となる。

図６（ｂ）では、図６（ａ）と概略同様の状態であるが、Ｋ２内のＨ２−１，Ｈ２−２ともに負荷が大きい状態とする。前述（図４）の制御処理により、同様に、第１候補は図示する６人（Ｈ１−１〜Ｈ３−３）となる。第２候補は、最初、距離Ｅ（範囲Ｆ）が近いＦ１に該当する３人（Ｈ１−１，Ｈ２−１，Ｈ２−２）となる。しかし、これらの負荷状態はいずれも大きいため、ＮＧとして、第２候補を決めなおし、次に近い範囲Ｆ２に該当する３人（Ｈ３−１〜Ｈ３−３）となる。そして、第３候補は、範囲Ｆ２の中で負荷が一番小さい条件に該当するＨ３−１，Ｈ３−２（２人）となる。例えばＫ２内のＨ２−１は近いが負荷が大きいためＮＧとなり、少し遠くても負荷が小さいＨ３−１等がＯＫ（第３候補）となる。このように第２の例では、距離よりも負荷分散を優先するアルゴリズムとした場合である。

［効果等］
以上説明したように、本実施の形態のシステムによれば、複数の各拠点（Ｋ）・保守員（Ｈ）におけるスキル（Ｓ）・言語（Ｗ）、顧客（Ｕ）・機器（Ｃ）との距離（Ｅ）、及び動的な負荷分散などを考慮して保守対応の仕事（Ｐ）のマッチング判定を行う機能により、保守対応の仕事の適切性、迅速性、及び複数の拠点（Ｋ）・複数の保守員（Ｈ）間における全体的な効率性・負荷分散を実現できる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。実施の形態の変形例として以下が挙げられる。

（１） 前述の処理例（図４）では、第２条件として距離を判定し、第３条件として負荷分散を判定したが、設定（ａ４）等に基づき、第１条件と第２条件のみで候補／担当を決定する形としてもよいし、第１条件と第３条件のみで候補／担当を決定する形としてもよい。

（２） 保守対応（Ｐ）の仕事の対象の顧客（Ｕ）・機器（Ｃ）が前（過去）と同じである場合に、当該仕事の適切性・効率性を考慮して、前（過去）と同じ担当者となるように決定してもよい。この場合、担当者となる保守員の負荷が大きくなる可能性があるが、例えば以降の他の仕事を他の保守員に担当させるように負荷分散することにより、当該保守員の負荷を抑制させる。例えばセンターシステム１内（ＤＢ５０）に過去の担当の情報を履歴として保持しておき、マッチングの際に当該履歴情報を参照して判定することにより、上記のような処理を実現する。

（３） マッチング判定で一旦担当者（保守員Ｈ、拠点Ｋ）を決定した後、当該担当者の都合が悪くなり当該保守対応が実施できない場合などには、当該保守員等を除いて再度のマッチング判定を行ったり、あるいは順序付きで保持しておいた別の候補から選択して決定してもよい。

（４） 言語（Ｗ）等に関して、必須条件として判定するのではなく、例えば推奨条件として判定してもよい。例えば、スキルＳ等を必須条件や優先条件とし、言語Ｗを推奨条件（なるべく顧客Ｕの言語Ｗと同じになるように考慮する）として候補を決定する。候補の保守員Ｈが顧客Ｕの言語Ｗと同じにならない場合は、例えば顧客Ｕの言語Ｗと同じである別の者を同行させるように複数人の担当者を決定する。設定（ａ４）により、距離優先や負荷分散優先だけでなく、スキル優先や言語優先などを同様に設定可能とする。

（５） 制御的にはより単純化した形態であるが、個別の担当者となる保守員Ｈを決定するのではなく、より大まかな単位として、担当させる１つの拠点Ｋを決定する形態も可能である。担当拠点Ｋの決定後は、その担当拠点Ｋ（複数の保守員Ｈ）の中で任意に対応させる。

（６） 前記第２条件の距離の判定に関して、距離情報と時間情報とを関係付けてＤＢ５０に管理してもよい。この場合、前記第２条件の距離の判定は、直接的に時間判定になる。即ち、拠点Ｋ・保守員Ｈ側から顧客Ｕ・機器Ｃ側への移動時間が一番短いものを候補とするような形となる。

本発明は、ヘルプデスクシステム、統合監視システム、等に利用可能である。

１…センターシステム、２…顧客システム、３…拠点（保守対応拠点）、４…ヘルプデスクシステム、５．６…ネットワーク、１０…サーバ（制御部）、１１…監視部、１２…診断部、１２Ａ…顧客機器診断部、１２Ｂ…拠点保守員診断部、１２Ｃ…マッチング部、１３…指示部、２１…機器、２２…エージェント、３１…保守対応用設備、３２…携帯端末、３３…保守部品、５０…管理情報（ＤＢ）、５１…顧客情報、５２…機器情報、５３…拠点情報、５４…保守員情報、５５…保守対応情報。

Claims (8)

1. 顧客の機器を対象とした保守対応の業務に係わる情報処理を行う保守対応システムであって、
   複数の拠点の複数の保守員の中から前記顧客の機器の保守対応を行う担当者を決定する機能を持つ情報処理装置を有し、
   前記情報処理装置は、診断部と、管理情報を格納するＤＢとを有し、
   前記情報処理装置は、外部から前記保守対応の要求の情報を入力し、
   前記診断部は、
   前記管理情報または入力情報をもとに、対象の顧客の機器の状態、必要な保守対応の内容及び条件を診断または確認する第１の処理と、
   前記管理情報または入力情報をもとに、複数の拠点と複数の保守員の最新の状態を診断または確認する第２の処理と、
   前記第１、第２の処理をもとに、対象の顧客の機器の保守対応のために、前記複数の拠点の複数の保守員の中から、担当者またはその候補となる拠点の保守員をマッチング判定する第３の処理と、を行い、
   前記第３の処理において、
   第１条件として、前記必要な保守対応の条件として、前記対象の顧客の機器の状態に応じた必要なスキルを持つ保守員を第１候補として選択し、
   第２条件として、前記第１候補から、対象の顧客の機器との距離がなるべく近い拠点の保守員を第２候補として選択し、
   第３条件として、前記第２候補から、複数の拠点または複数の保守員における保守対応の仕事の負荷分散が実現されるように、負荷がなるべく小さい拠点の保守員を第３候補として選択すること、を特徴とする保守対応システム。
2. 請求項１記載の保守対応システムにおいて、
   前記診断部の第３の処理において、前記第１条件として、前記必要な保守対応の条件として、前記顧客の言語に応じた必要な言語を持つ保守員を第１候補として選択すること、を特徴とする保守対応システム。
3. 請求項１記載の保守対応システムにおいて、
   前記診断部の第３の処理において、前記第２条件の判定の際には、前記対象の顧客の機器が存在するエリアまたは位置の情報と、前記保守員の拠点が存在するエリアまたは位置の情報とを確認し、両者間の距離またはその距離区分範囲を判定すること、を特徴とする保守対応システム。
4. 請求項１記載の保守対応システムにおいて、
   前記診断部の第３の処理において、前記第３条件の判定の際には、拠点の待機人数が所定人数以上確保されないものを候補から除外すること、を特徴とする保守対応システム。
5. 請求項１記載の保守対応システムにおいて、
   前記診断部の第３の処理において、前記第３条件の判定の際には、前記保守員の負荷状態を判定し、負荷が大きすぎるものを候補から除外すること、を特徴とする保守対応システム。
6. 請求項１記載の保守対応システムにおいて、
   設定または入力に基づいて、前記診断部の第３の処理において、前記第２条件の距離と、前記第３条件の負荷分散とで、前記第２条件の距離を優先して前記担当者またはその候補を決定すること、を特徴とする保守対応システム。
7. 請求項１記載の保守対応システムにおいて、
   設定または入力に基づいて、前記診断部の第３の処理において、前記第２条件の距離と、前記第３条件の負荷分散とで、前記第３条件の負荷分散を優先して前記担当者またはその候補を決定すること、を特徴とする保守対応システム。
8. 請求項１記載の保守対応システムにおいて、
   前記情報処理装置は、監視部と、指示部とを有し、
   前記監視部は、前記顧客の機器の状態及び位置を監視し、保守対応が必要な状態を検知する処理を行い、
   前記指示部は、前記診断部の処理結果をもとに、前記担当者となる保守員の拠点の設備または当該保守員の携帯端末へ保守対応の指示情報を送信する処理、及び当該設備または携帯端末から当該拠点の保守員の状態を取得する処理を行うこと、を特徴とする保守対応システム。

Images