JP2009099135A - 支援管理方法、支援管理システム及び情報処理装置 - Google Patents

Abstract

【課題】管理者の人的スキルに頼ることなく、且つ、対処要員の勤務状態を考慮することができ、遠隔地に設置された外部装置で発生した障害に対する対処支援を的確且つ迅速に行うことができる支援管理方法、該方法を実行するための支援管理システム及び該システムが備える情報処理装置を提供する。
【解決手段】対処支援の管理装置２は、遠隔地に設置された対象機器１、１、…で生じた障害についての障害情報を受信したとき、受信した障害情報に基づいて対処要員への連絡手順を取得すると共に対処要員の勤務状態を取得する。そして、取得した連絡手順と勤務状態との関係に基づいて最も適した対処要員を選定し、選定した対処要員の通信端末装置５へ対処指示を優先的に送信する。
【選択図】図１

Description

本発明は、外部機器で生じた障害に対する対処指示を通信端末装置へ送信する支援管理方法、支援管理システム及び情報処理装置に関し、特に、外部機器で生じた障害の内容と対処要員の勤務状況との関係に基づいて外部装置で生じた障害への対処に適した対処要員の通信端末装置へ優先的に送信することができる対処の支援管理方法、支援管理システム及び情報処理装置に関する。

従来、現金自動取引システム又は自動発券システムなどの基幹的な情報システムにあっては、システム障害が発生した場合に大きな影響を各種産業又は日常生活に与えることから、障害への対処を迅速にできるよう運用されていた。

例えば、従来の運用は、監視装置がシステムの障害を検出して管理者に連絡し、連絡を受けた管理者が発生した障害の内容と、対処要員のスキル、発生した障害に対する担当回数などとを考慮して障害への対処に適した対処要員を選定し、選定した対処要員に対処指示を出していた。

しかし、従来の運用にあっては、管理者が２４時間常勤して状況を把握し、判断ミス及び遅延することなく、障害への対処に適した対処要員を選定でき、選定した対処要員に迅速に指示を出すことができなければならず、管理者の人的スキルの高さに応じて運用が左右されるという問題を有していた。

そこで、従来、管理者に代わり、サーバが障害の内容に応じて対処要員を選定し、選定した通信端末装置へ連絡するようにしたシステムが提案された（例えば、特許文献１）。
特開２００２−３３７３１号公報

提案されたシステムによって、管理者の人的スキルに左右されることなく対処要員を選定して迅速に指示できるようになった。しかしながら、提案されたシステムにあっては、選定した対処要員が勤務時間外又は休暇中で連絡がとれない場合、又は選定した対処要員が専任でないため地理的に不慣れな障害発生地へ急行することができない場合などに対処することができない。

本発明はこのような事情に鑑みてなされたものであり、その目的とするところは、対処支援のための管理装置で、遠隔地に設置された外部装置で生じた障害についての障害情報を受信し、受信した障害情報に基づく複数の対処要員への連絡手順を取得すると共に、各対処要員の勤務状態を取得し、取得した連絡手順と勤務状態との関係に基づいて外部装置で生じた障害への対処に適した対処要員を選定し、取得した連絡手順のうち、選定した対処要員の通信端末装置へ対処指示を優先的に送信することにより、管理者の人的スキルに頼ることなく、対処要員の勤務状態に考慮して外部装置で生じた障害への対処支援を適格且つ迅速に行うことができる支援管理方法、支援管理システム及び情報処理装置を提供することにある。

上記目的を解決するために開示の支援管理方法は、対処支援のための管理装置で、遠隔地に設置された外部装置で生じた障害についての障害情報を受信し、受信した障害情報に基づく複数の対処要員への連絡手順を取得し、取得した連絡手順に従い外部装置で生じた障害に対する対処指示を対処要員の通信端末装置へ送信する支援管理方法において、前記管理装置で複数の対処要員の勤務状態を夫々取得し、前記取得した連絡手順と勤務状態との関係に基づいて外部装置で生じた障害への対処に適した対処要員を選定し、前記取得した連絡手順のうち、選定した対処要員の通信端末装置への送信を優先することを特徴とする。

また、開示の支援管理システムは、対処支援のための管理装置と、該管理装置と通信可能な複数の通信端末装置とを備え、前記管理装置は、遠隔地に設置された外部装置で生じた障害についての障害情報を受信する手段と、受信した障害情報に基づく複数の対処要員への連絡手順を取得する手段と、取得した連絡手順に従い外部装置で生じた障害に対する対処指示を対処要員の通信端末装置へ送信する送信手段とを支援管理システムにおいて、前記管理装置は、各対処要員の勤務状態を夫々取得する取得手段と、前記取得した連絡手順と勤務状態との関係に基づいて外部装置で生じた障害への対処に適した対処要員を選定する選定手段とを備え、前記送信手段は、前記取得した連絡手順のうち、前記選定手段が選定した対処要員の通信端末装置への送信を優先するようにしてあることを特徴とする。

この方法又はシステムにあっては、障害が生じた外部装置から障害情報を受信し、受信した障害情報に基づく複数の対処要員への連絡手段を取得することにより、対処に適した対処要員を抽出する。また、各対処要員の勤務状態を取得することにより、抽出した対処要員の勤務状態を把握する。また、取得した連絡手順と勤務状態との関係に基づいて外部装置で生じた障害への対処に適した対処要員を選定することにより、連絡する対処要員を正式に決定する。また、取得した連絡手順のうち、選定した対処要員の通信端末装置への送信を優先することにより、対処要員の能力及び勤務状態を考慮した上で最も適した対処要員に対処指示を優先的に送信する。

また、開示の支援管理システムは、前記管理装置は、障害が生じた外部装置が自ら対処できるか否かを判断する判断手段を更に備え、前記送信手段は、障害が生じた外部装置が自ら対処できると前記判断手段が判断した場合、対処要員の通信端末装置への送信を行わないようにしてあることを特徴とする。

このシステムにあっては、障害が生じた外部装置が自ら対処できると判断した場合、対処要員への指示を行わないようにしてあることにより、無用な対処指示を対処要員に行わない。

また、開示の支援管理システムは、前記勤務状態は、各対処要員が対処指示を受信して確認できる状態であるか否かを示すデータを含み、前記選定手段は、対処指示を確認できない対処要員を選定から除外するようにしてあることを特徴とする。

このシステムにあっては、連絡不可能な対処要員を除外して他の対処要員へ連絡することにより、対処要員への対処指示を確実行う。

また、開示の情報処理装置は、遠隔地に設置された外部装置で生じた障害についての障害情報を受信する手段と、受信した障害情報に基づく複数の対処要員への連絡手順を取得する手段と、取得した連絡手順に従い外部装置で生じた障害に対する対処指示を対処要員の通信端末装置へ送信する送信手段とを備える情報処理装置において、各対処要員の勤務状態を夫々取得する取得手段と、前記取得した連絡手順と勤務状態との関係に基づいて外部装置で生じた障害への対処に適した対処要員を選定する選定手段とを備え、前記送信手段は、前記取得した連絡手順のうち、前記選定手段が選定した対処要員の通信端末装置への送信を優先するようにしてあることを特徴とする。

この装置にあって、障害が生じた外部装置から障害情報を受信し、受信した障害情報に基づく複数の対処要員への連絡手段を取得することにより、対処に適した対処要員を抽出する。また、各対処要員の勤務状態を取得することにより、抽出した対処要員の勤務状態を把握する。また、取得した連絡手順と勤務状態との関係に基づいて外部装置で生じた障害への対処に適した対処要員を選定することにより、連絡する対処要員を正式に決定する。また、取得した連絡手順のうち、選定した対処要員の通信端末装置への送信を優先することにより、対処要員の能力及び勤務状態を考慮した上で最も適した対処要員に対処指示を優先的に送信する。

その他、開示の方法、システム及び装置にあっては、外部装置を遠隔操作して対処する場合、専任の対処要員に対処指示を優先的に送信することにより、操作が困難な遠隔操作については選任の対処要員が行うようにできる。

また、開示の方法、システム及び装置にあっては、障害の発生地で対処する場合、障害の発生地の近傍で勤務している対処要員に対処指示を優先的に送信することにより、障害への対処を迅速に実行させるようにできる。

また、開示の方法、システム及び装置にあっては、障害の発生地で対処する場合、障害の発生地までの地図情報を対処要員に提供することにより、外部装置の設置場所近傍の地理に不慣れな臨時担当の対処要員を目的地まで導くようにできる。

また、開示の方法、システム及び装置にあっては、障害の発生地で対処する場合、外部装置の設置施設内への入退出許可証データを対処要員に付与することにより、入退出許可証データを所有していない臨時担当の対処要員を迅速に設置施設内に入室させるようにできる。

開示の方法、システム又は装置は、管理者の人的スキルに頼ることなく、対処要員の勤務状態に考慮して外部装置で生じた障害への対処支援を適格且つ迅速に行うことができる。

実施の形態１．
以下、本発明に係る支援管理方法、支援管理システム及び情報処理装置について、実施の形態を示す図面に基づいて説明する。図１は本発明に係る支援管理システムの全体構成図、図２は管理装置の構成を示すブロック図、図３は障害情報テーブルの格納例を示す説明図、図４は障害対応リストテーブルの格納例を示す説明図、図５は連絡手順リストテーブルの格納例を示す説明図、図６は要員情報テーブルの格納例を示す説明図、図７は機器情報テーブルの格納例を示す説明図、図８は設置施設情報テーブルの格納例を示す説明図図９は入退出許可管理データの構造を示す説明図である。

図１で示すとおり、本実施の形態における支援管理システムは、対処支援のための管理装置２と、管理装置２に接続されたデータベース３と、対処要員が所持する通信端末装置５、５、…とを有する。各装置は、インターネットなどの通信網を介して相互に接続されている。また、支援管理システムの外部には、支援対処となる対象機器１、１、…と、ウェブサーバ４とが存在する。この装置は、通信網を介して支援管理システム内の装置と接続可能である。

各対象機器１は、対処要員によって修復される装置である。各対象機器１は、例えば、サーバ用のコンピュータ、クライアント用のパーソナルコンピュータ（Personal Computer）、ファクシミリ通信装置、現金自動取引機、自動発券機など通信機能を備えた機器が該当する。各対象機器１は、東京、大阪、名古屋、福岡など管理装置２又は対処要員の勤務地から遠隔の地に設置されている。各対象装置１は、自らに発生した障害を検出する障害検出部（図示せず）と、検出した障害の対処方法を分析する障害分析部（図示せず）と、検出した障害についての障害情報を送信する送信部（図示せず）と、コマンドによる遠隔操作を制御する遠隔操作部（図示せず）と、遠隔操作によるシステム再起動、システム復旧又は自己修復などを実行するための自己回復制御部（図示せず）とを有する。

管理装置２は、支援管理システムの全体を管理するための装置であり、少なくとも、障害への対処分析、連絡手順の取得、要員情報の取得、連絡手順の組み立て、連絡先の決定、対処指示の送信、連絡応答の確認、対処完了の確認、専任の判断、入退出許可証の臨時発行、現地への地図情報の提供、認証成功の確認、入退出許可証の削除などの各種処理を実行する装置である。なお、本実施の形態において、１台の管理装置２が各種処理を実行する例を説明している。しかし、例えば、複数の管理装置２、２、…が分担して各種処理を実行するようにしてもよい。

管理装置２は、外部記憶装置２１、通信インタフェース２２、ＲＡＭ２３、ＲＯＭ２４、補助記憶装置２５、入力インタフェース２６、出力インタフェース２７、データベース通信インタフェース２８及びＣＰＵ２９で構成されている。各ハードウェアは、バス２０を介して相互に接続されている。

外部記憶装置２１は、記録媒体２１ａに記憶してあるプログラム又は各種データを読み出すための装置である。外部記憶装置２１は、挿入口（図示せず）に記録媒体２１ａが挿入されたとき、挿入された記録媒体２１ａに記憶してあるプログラム又は各種データを読み出し、読み出したプログラムなどをＲＡＭ２３へ出力する。

記録媒体２１ａは、ＣＰＵ２９に対処支援管理に関する処理を実行させるためのプログラム又は各種データを記憶している。記録媒体２１ａは、例えば、ＤＶＤ（Digital Versatile Disc）又はＣＤ（Compact Disc）などの光ディスク、フレキシブルディスク、ハードディスクなどの磁気ディスク、ＩＣカードなどの半導体カード、マスクＲＯＭ、ＥＰＲＯＭ、ＥＥＲＯＭ、フラッシュＲＯＭなどの半導体メモリ、磁気テープなどが該当する。

通信インタフェース２２は、通信網の終端装置であり、通信網を介して各対象機器１、ウェブサーバ４、各通信端末装置５などの外部装置と通信を行うための窓口となる。通信網とは、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ回線網、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網などが該当する。
通信インタフェース２２は、外部から受け付けた各種データを受信し、受信した各種データをＲＡＭ２３へ出力する。また、通信インタフェース２２は、外部へ各種データ又は遠隔操作に関するコマンドを送信する。通信インタフェース２２で利用する伝送媒体は、ＩＥＥＥ１３３４、ＵＳＢ、電力線搬送、ＣＡＴＶ回線、電話回線、ＡＤＳＬ回線などの有線のみならず、赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、８０２．１１無線、ＨＤＲ、携帯電話機回線、衛星回線、地上波デジタル網などの無線が該当する。

ＲＡＭ２３は、複数の情報を記憶し、記憶順、記憶位置などに関係なく読み出すことが可能な主記憶装置であり、ＳＲＡＭ又はＤＲＡＭに分類される。ＲＡＭ２３は、例えば、ＲＯＭ２４から読み出したプログラム、該プログラムを実行することにより発生する各種データ、外部から受信した各種信号などを記憶する。ＲＡＭ２３は、ＣＰＵ２９の読出指示に応じて記憶してあるデータなどを適宜読み出す。

ＲＯＭ２４は、複数の情報を記憶し、記憶順、記憶位置などに関係なく読み出すことが可能な主記憶装置であり、電源を落としても記憶してある情報が消去されない。ＲＯＭ２４は、例えば、半導体素子で構成されており、マスクＲＯＭ、ＰＲＯＭ又はフラッシュメモリに分類される。ＲＯＭ２４は、例えば、管理装置２に対処支援管理に関する処理を実行させるためのプログラム又は各種データを記憶している。ＲＯＭ２４は、ＣＰＵ２９の読出指示に応じて記憶してあるデータなどを適宜読み出す。

補助記憶装置２５は、例えば、磁気記憶方式のハードディスクなどが該当する。補助記憶装置２５は、記録媒体２１ａから読み取ったプログラム及び各種データなどを記憶する。

入力インタフェース２６は、入力装置２６ａに接続してある。入力装置２６ａは、例えば、キーボード又はマウスなどが該当し、管理者の入力に応じた指示信号を出力する。入力装置２６ａは、対処支援管理に関する指示を入力するために用いる。入力インタフェース２６は、入力装置２６ａから出力された各種指示信号を受け付け、受け付けた各種指示信号をＣＰＵ２９へ出力する。

出力インタフェース２７は、ディスプレイ装置２７ａに接続してある。ディスプレイ装置２７ａは、対処支援管理に関する情報を映像出力するために用いる。出力インタフェース２７は、ディスプレイ装置２７ａへ各種情報を出力する。

データベース通信インタフェース２８は、データベース３に接続してあり、データベース３との通信を行うための窓口となる。

ＣＰＵ２９は、管理装置２の各ハードウェアを制御すると共に、対処支援管理に関する処理を実行する。なお、管理装置２が実行する対処支援管理に関する処理の手順については、後述にて説明する。

データベース３は、系統的に整理され、管理された情報の集まりであり、磁気記憶方式のハードディスクなどの記憶装置により実現されている。データベース３には、複数のテーブルが記憶してあり、記憶してあるテーブルは、管理装置２のＣＰＵ２９の指示に応じて適宜読み出される。

ここでデータベース３内に格納してある、障害情報テーブルＴ１、障害対応リストテーブルＴ２、連絡手順リストテーブルＴ３、要員情報テーブルＴ４、機器情報テーブルＴ５、設置施設情報テーブルＴ６、入退出許可管理データＴ７の格納例について説明する。

（障害情報テーブルＴ１）
障害が発生した対象機器１は、自らに発生した障害を障害検出部で検出し、検出した障害の対処方法を障害分析部で分析する。対象機器１は、検出した障害に関する障害情報を管理装置２へ送信する。管理装置２は、当該対象機器１から送信された障害情報を受信し、受信した障害情報を発生時間順に並べて障害情報テーブルＴ１に格納する。

障害情報テーブルＴ１には、各対象機器１に生じた障害についての障害情報が格納されている。障害情報テーブルＴ１に格納される障害情報には、障害の内容、障害の発生時間、障害が生じた対象機器１の識別ＩＤである発生対象、障害の詳細及びその他の事項が対応付けて含まれている。その他、障害の内容を識別するためのコード番号、障害が生じたアプリケーションソフト名、障害が生じた状況、障害の原因、障害が生じた対象機器１のＩＰアドレス、障害が生じた部品のＭＡＣアドレス、分析した対処方法及び対処に要する作業期間などが含まれている。

（障害対応リストテーブルＴ２）
障害対応リストテーブルＴ２には、障害に対する対処情報が格納されている。当該対処情報には、対応グループの識別番号、対処方法及び対応グループへの連絡方法が対応付けて含まれている。当該対処情報は、管理者により予め設定される。

管理装置２は、例えば、対象機器１が分析した対処方法が“現地対応”である場合、障害の発生地へ赴いて対処するよう対処要員へ対処指示を行う。また、対象機器１が分析した対処方法が“リモートメンテナンス”である場合、障害の発生地に赴くことなく対象機器１を遠隔操作して対処するよう対処要員へ対処指示を行う。また、対象機器１が分析した対処方法が“システム再起動”である場合、対処要員に連絡することなく、コマンド操作により対象装置１のオペレーションシステム（以下「ＯＳ」という。）を再起動させる。また、対象機器１が分析した対処方法が“システム復旧”である場合、対処要員に連絡することなく、コマンド操作により対象装置１のＯＳを障害前の状態に戻す。また、対象機器１が分析した対処方法が“自己修復”である場合、対処要員に連絡することなく、コマンド操作により対象装置１の破損したデータを自己修復させる。

また、管理装置２は、対象機器１が分析した対処方法に対応する連絡方法が“順次メール”である場合、電子メールを各対処要員の通信端末装置５に順次送信する。また、対象機器１が分析した対処方法に対応する連絡方法が“同報メール”である場合、電子メールを各対処要員の通信端末装置５に同時送信する。また、対象機器１が分析した対処方法に対応する連絡方法が“順次音声”である場合、音声情報を各対処要員の通信端末装置５に順次送信する。また、対象機器１が分析した対処方法に対応する連絡方法が“同報音声”である場合、音声情報を各対処要員の通信端末装置５に同時送信する。更にまた、対象機器１が分析した対処方法に対応する連絡方法が“非通知”である場合、各対処要員の通信端末装置５への連絡を行わない。

（機器情報テーブルＴ５）
機器情報テーブルＴ５には、対象機器１についての機器情報が対象機器１毎に分類されて格納されている。当該機器情報には、各対象機器１を識別するための識別ＩＤ、各対象機器１の設置場所、各対象機器１を制御するＯＳ及び各対象機器１にインストールされたアプリケーション名が対応付けて含まれている。当該機器情報は、管理者により予め設定される。

管理装置２は、障害が生じた対象機器１の識別ＩＤに対応する設置場所、ＯＳ及びアプリケーション名を機器情報テーブルＴ５から抽出する。管理装置２は、抽出した機器情報を連絡手順及び対処要員を決定するための判断材料とする。各対象機器１の設置場所は、例えば、設置施設の都道府県、市町村などの住所のみならず、設置施設における階数、部屋番号まで詳細に示されている。

なお、本実施の形態にあっては、機器情報テーブルＴ５がデータベース３に格納されている一例を説明した。しかし、開示する機器情報テーブルＴ５は、これに限定されるものでなく、支援管理システムと通信網を介して接続可能な、外部の資産管理システムにより管理されてもよい。

（連絡手順リストテーブルＴ３）
連絡手順リストテーブルＴ３には、対処要員への連絡手順が対応グループ毎に分類されて格納されている。当該連絡手順には、対応グループ、グループが対応できる障害の概要、グループに属するメンバの氏名及び保有スキルなどが対応付けて含まれている。当該連絡手順は、管理者により予め設定される。

管理装置２は、対象機器１で生じた障害の内容が連絡手順リストテーブルＴ３内の概要のいずれかに関連すると判断した場合、関連する概要を担当するグループの連絡手順を選定する。但し、対象機器１で生じた障害の内容に関連する概要が連絡手順リストテーブルＴ３内に存在しないと判断した場合、対象機器１で生じた障害に類似する概要を担当するグループの連絡手順を選定する。管理装置２は、一致する文字列の数が最多の障害内容及び概要を関連させる。

各グループに属するメンバは、左から右へ連絡順に並べて格納されている。管理装置２は、最左のメンバから優先的に対処指示を送信する。

（要員情報テーブルＴ４）
要員情報テーブルＴ４には、対処要員の勤務状態についての要員情報が対処要員毎に分類されて格納されている。当該要員情報には、対処要員の氏名、対処要員が担当する地域、対処要員が担当する時間、対処要員が担当した回数、対処要員が保有するスキル、対処要員の連絡先、対処要員のスケジュール、対処要員が専任であるか否かを示すデータ、対処要員の写真データが対応付けて含まれている。担当回数及びスケジュールを除く要員情報は、管理者により予め設定される。

管理装置２は、障害が生じた対象機器１の設置場所が要員情報テーブルＴ４内の担当地域のいずれかと一致又は近傍していると判断した場合、当該地域を担当する対処要員を最適な対処要員として選定する。管理装置２は、補助記憶装置２５に記憶してある各地の座標情報（図示せず）に基づいて、設置場所及び担当地域の距離が所定値を超えるか否かを判断することにより、一致又は近傍を判断する。

また、管理装置２は、障害の発生時間が要員情報テーブルＴ４内の担当時間のいずれかに属すると判断した場合、当該時間を担当する対処要員への連絡が可能である、即ち対処要員が対処指示を受信して確認できる状態であると判断する。

また、管理装置２は、対処に適した対処要員を複数選定した場合、担当回数の多い対処要員を最適な対処要員として優先的に選定する。管理装置２は、対処要員が修復を完了する都度その対処要員の担当回数を加算して更新しておく。

また、管理装置２は、対象機器１で生じた障害の内容が要員情報テーブルＴ４内の保有スキルのいずれかに関連すると判断した場合、関連するスキルを保有する対処要員を最適な対処要員として選定する。管理装置２は、文字列の一致数が最多の障害内容及び保有スキルを関連させる。

対処要員の連絡先とは、各対処要員が所有する通信端末装置５の連絡先であり、例えば、携帯電話機の電話番号、携帯電話機へのメールアドレス等が該当する。管理装置２は、当該連絡先を用いて通信端末装置５への連絡を行う。

また、管理装置２は、外部のスケジュール管理システムにより管理されているデータ、各通信端末装置５へのポーリングにより取得したデータ、又はＧＰＳ（Global Positioning System）により取得した位置データなどに基づいて各対処要員のスケジュールを分析して要員情報テーブルＴ４に格納する。管理装置２は、例えば、障害発生時のスケジュールが“通常勤務”であるか、又は障害発生地の近傍へ出張している対処要員への連絡が可能であると判断する。一方、障害発生時のスケジュールが“年休”である対処要員への連絡が不可能であると判断する。

また、管理装置２は、例えば、対処方法が“リモートメンテナンス”であるグループについて、専任の対処要員を臨時担当の対処要員より優先的に選定する。また、管理装置２は、臨時担当の対処要員を選定した場合、選定した臨時担当の対処要員に対し、現地における入退出許可証、及び現地への地図情報を送信する。

管理装置２は、障害対応リストテーブルＴ２、連絡手順リストテーブルＴ３及び要員情報テーブルＴ４に基づいて選定した情報を組み合わせることにより、障害への対処に適した対処要員を正式に決定する。なお、対処要員の決定処理の手順は、後述にて説明する。

（設置施設情報テーブルＴ６）
設置施設情報テーブルＴ６には、各対象機器１に関する設置施設情報が格納されている。当該設置施設情報には、対象機器１が設置されている施設名、施設の住所、入退出許可のオリジナルデータ、施設の電話番号、施設の緯度経度が対応付けて含まれている。当該設置施設情報は、管理者により予め設定される。

管理装置２は、入退出許可のオリジナルデータを用いて臨時担当の対処要員を設置施設に入退出させるための入退出許可情報を生成する。なお、入退出許可情報の生成処理の手順は、後述に説明する。

管理装置２は、施設の緯度経度を用いて臨時担当の対処要員に付与するための設置施設に関する地図情報を生成する。なお、地図情報の生成処理の手順は、後述にて説明する。

（入退出許可管理データＴ７）
入退出許可管理データＴ７は、入退出許可情報を管理するためのデータであり、設置施設毎に生成される。入退出許可管理データＴ７は、基本領域と更新領域とを含む。基本領域には、入退出許可情報を利用する場所（即ち設置場所）、発行可能枚数、発行枚数が格納されている。更新領域には、入退出許可情報を発行する毎に発行Ｎｏ、発行日、完了日、発行対象、入室日などのデータが追加格納される。

利用場所及び発行可能枚数は、管理者により予め設定される。管理装置２は、入退出許可情報を発行する都度発行枚数を増やし、入退出許可情報を削除する都度発行枚数を減らす。

ウェブサーバ４は、ＨＴＭＬで記述された文書、画像又は電子メールなどのデータを蓄積しており、蓄積するデータを各通信端末装置５から送信された転送要求に応じて読み出して送信する。ウェブサーバ４は、プル型の情報のみならず、プッシュ型の情報を各通信端末装置５へ送信する。

各通信端末装置５は、対処要員が所有する通信可能な端末装置であり、例えば、携帯電話装置、通信機能付きＰＤＡ（Personal Digital Assistant）、通信機能付きノートパソコンなどが該当する。各通信端末装置５の連絡先は、要員情報テーブルＴ４の対処要員の連絡先として管理されている。管理装置２は、対処要員に連絡すべき情報を対処要員が所有する通信端末装置５へ送信する。

各通信端末装置５は、管理装置２から送信された対処指示を受信する受信部（図示せず）と、受信した対処指示又は遠隔操作に関するコマンドを入力する画面を表示する表示部（図示せず）と、リモートメンテナンスプログラムを記憶する記憶部（図示せず）、リモートメンテナンスプログラムに従って遠隔操作を制御する遠隔操作部（図示せず）と、処要員により入力された遠隔操作に関するコマンド及びその他の情報を受け付ける入力部（図示せず）と、遠隔操作に関するコマンド及びその他の情報を送信する送信部（図示せず）とを有する。

このように、本実施の形態における支援管理システムは、障害が生じた対象機器１が障害情報を送信し、送信された障害情報を管理装置２が受信する。そして、管理情報２が所定のルールに従って障害への対処に適した対処要員を選定し、選定した対処要員の通信端末装置５に対処指示を優先的に送信する。以下、管理装置２が実行する処理の手順について説明する。図１０及び図１１は管理装置２が実行する対処支援管理処理の手順を示すフローチャートである。

各対象機器１は、自らに発生した障害を障害検出部で検出し、検出した障害の対処方法を障害分析部で分析する。対処機器１は、障害に関する障害情報を管理装置２へ送信する。

管理装置２のＣＰＵ２９は、各対象機器１から送信された障害情報を受信したか否かを判断し（Ｓ１０１）、障害情報を受信していないと判断した場合（Ｓ１０１でＮＯ）、ステップＳ１０１へ戻り、処理を繰り返す。

一方、ＣＰＵ２９は、障害情報を受信したと判断した場合（Ｓ１０１でＹＥＳ）、対処分析処理を実行し（Ｓ１０２）、受信した障害情報を障害情報テーブルＴ１に順次格納する。なお、対処分析処理の手順は、後述にて説明する。

ＣＰＵ２９は、ステップＳ１０２で実行した対処分析処理の結果、対処方法が“システム再起動”、“システム復旧”又は“自己修復”に該当するか否かを判断する（Ｓ１０３）。その結果、ＣＰＵ２９は、対処方法が“システム再起動”、“システム復旧”又は“自己修復”に該当していないと判断した場合（Ｓ１０３でＮＯ）、ステップＳ１０６へ進む。

一方、ＣＰＵ２９は、対処方法が“システム再起動”、“システム復旧”又は“自己修復”に該当すると判断した場合（Ｓ１０３でＹＥＳ）、対処要員に連絡することなく対象機器１が自己解決できると判断し、実行コマンドを対象機器１へ送信する（Ｓ１０４）。対象機器１は、管理装置２から送信された実行コマンドを受信し、受信した実行コマンドに従ってシステム再起動、システム復旧又は自己修復を実行する。対象機器１は、システム再起動、システム復旧又は自己修復により正常な状態に回復した場合、回復信号を送信する。

ＣＰＵ２９は、対象機器１から送信された回復信号を受信したか否かを判断し（Ｓ１０５）、回復信号を受信したと判断した場合（Ｓ１０５でＹＥＳ）、対処支援管理処理を完了する。

一方、ＣＰＵ２９は、回復信号を受信していないと判断した場合（Ｓ１０５でＮＯ）、対処要員が必要であると判断し、ステップＳ１０６へ進む。

ＣＰＵ２９は、対処方法が“システム再起動”、“システム復旧”又は“自己修復”に該当していないと判断するか（Ｓ１０３でＮＯを参照）、回復信号を受信していないと判断した場合（Ｓ１０５でＮＯを参照）、対象機器１で生じた障害の内容に対応する連絡手順を連絡手順リストテーブルＴ３から取得する（Ｓ１０６）。ＣＰＵ２９は、要員情報取得処理を実行する（Ｓ１０７）。なお、要員情報取得処理の手順は、後述にて説明する。

ＣＰＵ２９は、取得した連絡手順及び要員情報に基づいて、対処要員への連絡順番を組み立てる連絡先組立処理を実行する（Ｓ１０８）。なお、連絡先組立処理の手順は、後述にて説明する。

ＣＰＵ２９は、連絡先組立処理により組み立てた連絡順番のうちの最先の対処要員の通信端末装置５へ対処指示を送信する（Ｓ１０９）。対処指示は、途中、ウェブサーバ４により画面データに形成されて通信端末装置５へ送信される。通信端末装置５は、管理装置２から送信された対処指示を受信し、受信した対処指示を表示部に画面出力する。通信端末装置５は、対処指示に応じて、対処要員により入力された応答信号を受け付け、受け付けた応答信号を管理装置２へ送信する。なお、対処指示は、画面データに限らず、ウェブブラウザ４により電子メールデータに形成されるか、音声データに形成されて通信端末装置５へ送信されてもよい。

管理装置２のＣＰＵ２９は、通信端末装置５から所定時間内に応答信号を受信したか否かを判断し（Ｓ１１０）、所定時間内に応答信号を受信していないと判断した場合（Ｓ１１０でＮＯ）、ステップＳ１０８に戻り、連絡先組立処理により組み立てた連絡順番のうち、応答がない対処要員の通信端末装置５を除いて最先となる対処要員の通信端末装置５へ対処指示を送信する。なお、応答がない通信端末装置５には、応答信号を送信していない場合のみならず、対処指示を受信することができない場合も含まれる。

一方、ＣＰＵ２９は、所定時間内に応答信号を受信したと判断した場合（Ｓ１１０でＹＥＳ）、ステップＳ１０２で実行した対処分析処理の結果において、対処方法が“リモートメンテナンス”であるか否かを判断する（Ｓ１１１）。その結果、ＣＰＵ２９は、対処方法が“リモートメンテナンス”であると判断した場合（Ｓ１１１でＹＥＳ）、遠隔対処処理を実行し（Ｓ１１２）、対処支援管理処理を完了する。なお、遠隔対処処理の手順は、後述にて説明する。

一方、ＣＰＵ２９は、対処方法が“リモートメンテナンス”でないと判断した場合（Ｓ１１１でＮＯ）、現地対処処理を実行し（Ｓ１１３）、対処支援管理処理を完了する。なお、現地対処処理の手順は、後述にて説明する。

このように、本実施の形態における対処支援システムは、管理者の人的スキルに頼ることなく、外部装置で発生した障害に対処する対処要員を的確且つ迅速に選定することができる。

次に管理装置２がステップＳ１０２で実行する対処分析処理の手順について説明する。図１２は対処分析処理の手順を示すフローチャートである。

管理装置２のＣＰＵ２９は、障害情報テーブルＴ１に格納してある障害情報のうちの障害の内容を抽出する（Ｓ２０１）。

ＣＰＵ２９は、抽出した障害の内容に関連する概要を連絡手順リストテーブルＴ３から抽出し、抽出した概要に対応する対応グループを連絡手順リストテーブルＴ３から一又は複数選定する（Ｓ２０２）。ＣＰＵ２９は、選定した対応グループに対応する対処方法を障害対応リストテーブルＴ２から抽出する（Ｓ２０３）。その結果、ＣＰＵ２９は、障害に対する対処方法の候補を取得する。

ＣＰＵ２９は、抽出した対処方法に対応する連絡方法を障害対応リストテーブルＴ２から抽出する（Ｓ２０４）。その結果、ＣＰＵ２９は、対処方法を実行する対処要員への連絡先を取得する。

ＣＰＵ２９は、障害情報テーブルＴ１に格納してある障害情報のうちの障害の発生対象を抽出し、抽出した発生対象を示す識別ＩＤを含む機器情報を機器情報テーブルＴ５から取得する（Ｓ２０５）。ＣＰＵ２９は、次回処理を再開するまで待機する。その結果、ＣＰＵ２９は、対処方法を施す機器情報を取得する。

次に管理装置２がステップＳ１０７で実行する要員情報取得処理の手順について説明する。図１３は要員情報取得処理の手順を示すフローチャートである。

管理装置２のＣＰＵ２９は、ステップＳ２０２において選定した対応グループに属するメンバの氏名を連絡手順リストテーブルＴ３から抽出し（Ｓ３０１）、抽出した氏名の要員情報を要員情報テーブルＴ４から取得する（Ｓ３０２）。ＣＰＵ２９は、次回処理を再開するまで待機する。その結果、ＣＰＵ２９は、候補となる対処要員の要員情報を取得する。

次に管理装置２がステップＳ１０８で実行する連絡先組立処理の手順について説明する。図１４は連絡先組立処理の手順を示すフローチャートである。

管理装置２のＣＰＵ２９は、ステップＳ２０２において選定した対応グループに属するメンバとなる全ての対処要員に対して処理を実行したか否かを判断する（Ｓ４０１）。その結果、ＣＰＵ２９は、全ての対処要員に対して処理を実行したと判断した場合（Ｓ４０１でＹＥＳ）、次回実行要求があるまで待機する。

一方、ＣＰＵ２９は、いずれかの対処要員に対して処理を実行していないと判断した場合（Ｓ４０１でＮＯ）、ステップＳ３０２において取得した要員情報を解析する（Ｓ４０２）。具体的には、ＣＰＵ２９は、候補となる対処要員の担当地域、担当時間、担当回数、保有スキル、スケジュール及び専任の可否を要員情報テーブルＴ４から抽出する。

ＣＰＵ２９は、抽出した担当時間及びスケジュールに基づいて候補となる対処要員への連絡が可能であるか否かを判断する（Ｓ４０３）。その結果、ＣＰＵ２９は、対処要員への連絡が不可能であると判断した場合（Ｓ４０３でＮＯ）、ステップＳ４０１に戻り、更にいずれかの対処要員に対して処理を実行していないと判断した場合、次候補となる対処要員の要員情報を解析する。ここで対処要員への連絡が不可能な場合とは、上述するように障害の発生時間が候補となる対処要員の担当時間外であるか、障害発生時のスケジュールが“年休”であることをいう。

一方、ＣＰＵ２９は、対処要員への連絡が可能であると判断した場合（Ｓ４０３でＹＥＳ）、ステップＳ１０２で実行した対処分析処理の結果において、対処方法が“リモートメンテナンス”であるか否かを判断する（Ｓ４０４）。その結果、ＣＰＵ２９は、対処方法が“リモートメンテナンス”であると判断した場合（Ｓ４０４でＹＥＳ）、抽出した専任の可否に基づいて候補となる対処要員が専任であるか否かを判断する（Ｓ４０５）。ＣＰＵ２９は、候補となる対処要員が専任でないと判断した場合（Ｓ４０５でＮＯ）、ステップＳ４０１に戻り、更にいずれかの対処要員に対して処理を実行していないと判断した場合、次候補となる対処要員の要員情報を解析する。

一方、ＣＰＵ２９は、候補となる対処要員が専任であると判断した場合（Ｓ４０５でＹＥＳ）、候補となる対処要員を遠隔の対処要員として連絡順リストへ格納する（Ｓ４０６）。その後、ＣＰＵ２９は、ステップＳ４０１に戻り、全ての対処要員に対して処理を実行したか否かを判断する。

一方、ＣＰＵ２９は、ステップＳ４０４において、対処方法が“リモートメンテナンス”でないと判断した場合（Ｓ４０４でＮＯ）、抽出した対処要員の担当地域及びスケジュールに基づいて対処要員が障害発生地の近傍にいるか否かを判断する（Ｓ４０７）。その結果、ＣＰＵ２９は、対処要員が障害発生地の近傍にいないと判断した場合（Ｓ４０７でＮＯ）、ステップＳ４０１に戻り、更にいずれかの対処要員に対して処理を実行していないと判断した場合、次候補となる対処要員の要員情報を解析する。ここで対処要員が障害発生地の近傍にいない場合とは、例えば、担当する地域又は出張先と障害発生地との距離が所定値を超えるか、他の市町村である場合が該当する。

一方、ＣＰＵ２９は、対処要員が障害発生地の近傍にいると判断した場合（Ｓ４０７でＹＥＳ）、候補となる対処要員を現地の対処要員として連絡順リストへ格納する（Ｓ４０８）。その後、ＣＰＵ２９は、ステップＳ４０１に戻り、全ての対処要員に対して処理を実行したか否かを判断する。

次に管理装置２がステップＳ１１２で実行する遠隔対処処理の手順について説明する。図１５は遠隔対処処理の手順を示すフローチャートである。

管理装置２のＣＰＵ２９は、対処要員の通信端末装置５にリモートメンテナンスプログラムの起動コマンドを送信し（Ｓ５０１）、更に障害内容及び機器情報を送信する（Ｓ５０２）。その結果、通信端末装置５は、起動コマンドに従ってリモートメンテナンスプログラムを起動し、リモートメンテナンスプログラムに従い、対処要員により入力された遠隔操作に関するコマンドを受け付ける。また、通信端末装置５は、障害内容及び機器情報を表示部に出力する。また、通信端末装置５は、分析プログラムを起動し、障害内容及び機器情報を分析する。通信端末装置５は、対処要員により入力された遠隔操作に関するコマンドを受け付け、受け付けた遠隔操作に関するコマンドを管理装置２を介して障害が生じた対象機器１へ送信する。

管理装置２のＣＰＵ２９は、通信端末装置５と対象機器１との間で、遠隔操作に関するコマンドを中継する（Ｓ５０３）。ところで対処要員は、作業開始後に遠隔操作による対処が不可能であると判断する場合もある。かかる場合、通信端末装置５は、対処要員により入力された対処不可能の信号を受け付けて管理装置２へ送信する。

管理装置２のＣＰＵ２９は、通信端末装置５から送信された対処不可能信号を所定時間内に受信したか否かを判断し（Ｓ５０４）、対処不可能信号を所定時間内に受信したと判断した場合（Ｓ５０４でＹＥＳ）、遠隔対処処理を中止して現地対処処理を実行する（Ｓ５０５）。その結果、遠隔操作による対処から現地での対処に切り替えることができる。

一方、ＣＰＵ２９は、対処不可能信号を所定時間内に受信していないと判断した場合（Ｓ５０４でＮＯ）、更に通信端末装置５から送信された完了信号を受信したか否かを判断する（Ｓ５０６）。対処要員は、障害が生じた対象機器１を修復した後、修復の完了を通信端末装置５に入力する。通信端末装置５は、対処要員により入力された完了信号を受け付けた場合、受け付けた完了信号を管理装置２へ送信する。なお、通信端末装置５における完了信号の受付処理の手順については、後述にて詳述する。その結果、ＣＰＵ２９は、完了信号を受信していないと判断した場合（Ｓ５０６でＮＯ）、ステップＳ５０３に戻り、遠隔操作に関するコマンドの中継を引き続き行う。

一方、ＣＰＵ２９は、完了信号を受信したと判断した場合（Ｓ５０６でＹＥＳ）、対処要員の通信端末装置５にリモートメンテナンスプログラムの終了コマンドを送信する（Ｓ５０７）。ＣＰＵ２９は、次回実行要求があるまで待機する。

次に管理装置２がステップ１１３で実行する現地対処処理の手順について説明する。図１６は現地対処処理の手順を示すフローチャートである。

管理装置２のＣＰＵ２９は、障害内容及び機器情報を対処要員の通信端末装置５へ送信する（Ｓ６０１）。その結果、通信端末装置５は、障害内容及び機器情報を表示部に出力する。また、通信端末装置５は、分析プログラムを起動し、障害内容及び機器情報を分析する。

ＣＰＵ２９は、専任の可否に基づいて対処要員が専任であるか否かを判断し（Ｓ６０２）、対処要員が専任であると判断した場合（Ｓ６０２でＹＥＳ）、ステップＳ６０７へ進む。対処要員は、障害が生じた対象機器１に対する修復の完了を通信端末装置５に入力する。通信端末装置５は、対処要員により入力された完了信号を受け付けた場合、受け付けた完了信号を管理装置２へ送信する。

一方、ＣＰＵ２９は、対処要員が専任でないと判断した場合（Ｓ６０２でＮＯ）、専任でない対処要員、即ち臨時担当の対処要員を設置施設に入退出させるための入退出許可情報の生成処理を実行する（Ｓ６０３）。なお、入退出許可情報生成処理の手順は、後述に説明する。

また、ＣＰＵ２９は、設置施設内外の地理に不慣れな臨時担当の対処要員に付与するための設置施設に関する地図情報の生成処理を実行する（Ｓ６０４）。なお、地図情報生成処理の手順は、後述にて説明する。

ＣＰＵ２９は、生成した入退出許可情報及び地図情報を臨時担当の対処要員の通信端末装置５へ送信する（Ｓ６０５）。通信端末装置５は、管理装置２から送信された入退出許可情報及び地図情報を受信し、受信した入退出許可情報及び地図情報を表示部に出力する。通信端末装置５を所持する臨時担当の対処要員は、出力された地図情報を参照して障害が生じた対象機器１の設置施設へ赴き、付与された入退出許可情報を用いて認証を行う。

管理装置２のＣＰＵ２９は、入退出許可情報を用いた認証が成功したか否かを判断し（Ｓ６０６）、入退出許可情報を用いた認証が失敗したと判断した場合（Ｓ６０６でＮＯ）、ステップＳ６０８へ進む。なお、認証処理の手順については、後述にて説明する。

一方、ＣＰＵ２９は、入退出許可情報を用いた認証が成功したと判断した場合（Ｓ６０６でＹＥＳ）、ステップＳ６０７へ進む。対処要員は、障害が生じた対象機器１を修復した後、修復の完了を通信端末装置５に入力する。通信端末装置５は、対処要員により入力された完了信号を受け付けた場合、受け付けた完了信号を管理装置２へ送信する。

ＣＰＵ２９は、対処要員が専任であると判断した場合（Ｓ６０２でＹＥＳを参照）、又は入退出許可情報を用いた認証が成功したと判断した場合（Ｓ６０６でＹＥＳを参照）、通信端末装置５から送信された完了信号を受信したか否かを判断する（Ｓ６０７）。その結果、ＣＰＵ２９は、完了信号を受信していないと判断した場合（Ｓ６０７でＮＯ）、ステップＳ６０７の処理を繰り返す。

一方、ＣＰＵ２９は、完了信号を受信したと判断した場合（Ｓ６０７でＹＥＳ）、ステップＳ６０８へ進む。

ＣＰＵ２９は、入退出許可情報を用いた認証が失敗したと判断した場合（Ｓ６０６でＮＯを参照）、又は完了信号を受信したと判断した場合（Ｓ６０７でＹＥＳを参照）、入退出許可情報の削除コマンドを対処要員の通信端末装置５へ送信する（Ｓ６０８）。ＣＰＵ２９は、次回実行要求があるまで待機する。本ステップＳにより、臨時担当の対処要員に一時的に付与した入退室許可情報が悪用されることを回避できる。

次にステップＳ６０３において実行する入退出許可情報の生成処理の手順について説明する。なお、本実施の形態にあっては、入退出許可情報を静的に生成するか、動的に生成することができる。従って、以下、実施例に分けて説明する。図１７は入退出許可情報の表示例を示す模式図である。

実施例１．
実施例１では、入退出許可情報を静的に生成する処理の手順を説明する。図１８は入退出許可情報生成処理の手順を示すフローチャートである。管理装置２のＣＰＵ２９は、補助記憶装置２５に記憶してある障害一覧テーブル（図示せず）を参照し、障害内容に応じた作業期間を決定する（Ｓ７０１）。

ＣＰＵ２９は、発生対象を障害情報テーブルＴ１から抽出し、抽出した発生対象を示す識別ＩＤに対応する対象機器１の設置場所を機器情報テーブルＴ５から抽出する（Ｓ７０２）。ＣＰＵ２９は、抽出した設置場所に対応する入退出許可のオリジナルデータを設置施設情報テーブルＴ６から抽出する（Ｓ７０３）。

ＣＰＵ２９は、抽出した設置場所に対応する利用場所を含む入退出許可管理データＴ７から、発行可能枚数及び発行枚数を抽出する。ＣＰＵ２９は、抽出した発行枚数を１つ増やした枚数が発行可能枚数を超えるか否かを判断する（Ｓ７０４）。その結果、ＣＰＵ２９は、発行可能枚数を超えると判断した場合（Ｓ７０４でＹＥＳ）、ステップＳ７０４へ戻り、入退出許可情報が削除されて発行枚数が減るまで、処理を繰り返す。

一方、ＣＰＵ２９は、発行可能枚数以下であると判断した場合（Ｓ７０４でＮＯ）、発行Ｎｏを入退出許可のオリジナルデータに採番する（Ｓ７０５）。ＣＰＵ２９は、処理の実行日を発行日とし、発行日から作業期間経過した日を完了日とし、実行日及び完了日を入退出許可のオリジナルデータに付与する（Ｓ７０６）。ＣＰＵ２９は、生成した入退出許可データをテキスト形式の画像データに変換して入退出許可情報とし、次回処理を再開するまで待機する。入退出許可情報は、通信端末装置５の表示部に出力される（図１７（ａ））。以上、実施例１について説明した。

実施例２．
実施例２では、入退出許可情報を動的に生成する処理の手順を説明する。図１９は入退出許可情報生成処理の手順を示すフローチャートである。管理装置２のＣＰＵ２９は、障害一覧テーブルを参照し，障害内容に応じた作業期間を決定する（Ｓ８０１）。

ＣＰＵ２９は、発生対象を障害情報テーブルＴ１から抽出し、抽出した発生対象を示す識別ＩＤに対応する対象機器１の設置場所を機器情報テーブルＴ５から抽出する（Ｓ８０２）。ＣＰＵ２９は、抽出した設置場所に対応する入退出許可のオリジナルデータを設置施設情報テーブルＴ６から抽出する（Ｓ８０３）。

ＣＰＵ２９は、抽出した設置場所に対応する利用場所を含む入退出許可管理データＴ７から、発行可能枚数及び発行枚数を抽出する。ＣＰＵ２９は、抽出した発行枚数を１つ増やした枚数が発行可能枚数を超えるか否かを判断する（Ｓ８０４）。その結果、ＣＰＵ２９は、発行可能枚数を超えると判断した場合（Ｓ８０４でＹＥＳ）、ステップＳ８０４へ戻り、入退出許可情報が削除されて発行枚数が減るまで、処理を繰り返す。

一方、ＣＰＵ２９は、発行可能枚数以下であると判断した場合（Ｓ８０４でＮＯ）、対処要員の写真データを要員情報テーブルＴ４から抽出する（Ｓ８０５）。ＣＰＵ２９は、発行Ｎｏを入退出許可のオリジナルデータに採番する（Ｓ８０６）。ＣＰＵ２９は、処理の実行日を発行日とし、発行日から作業期間経過した日を完了日とし、実行日及び完了日を入退出許可のオリジナルデータに付与する（Ｓ８０７）。ＣＰＵ２９は、生成した入退出許可データを写真付き画像データに変換して入退出許可情報とし、次回処理を再開するまで待機する。入退出許可情報は、通信端末装置５の表示部に出力される（図１７（ｂ））。以上、実施例２について説明した。

次にステップＳ６０４において実行する地図情報の生成処理の手順について説明する。図２０は地図情報の表示例を示す模式図、図２１は地図情報生成処理の手順を示すフローチャートである。管理装置２のＣＰＵ２９は、発生対象を障害情報テーブルＴ１から抽出し、抽出した障害対象を示す識別ＩＤに対応する対象機器１の設置場所を機器情報テーブルＴ５から抽出する（Ｓ９０１）。ＣＰＵ２９は、抽出した設置場所の緯度経度データを設置施設情報テーブルＴ６から抽出する（Ｓ９０２）。

ＣＰＵ２９は、対処要員の担当地域及びスケジュールに基づいて出発点の緯度経度データを取得する（Ｓ９０３）。ＣＰＵ２９は、外部のシステムから取得した地図データに出発点の緯度経度と設置場所の緯度経度とを当て嵌め、出発点から設置場所までの経路を探索する（Ｓ９０４）。

ＣＰＵ２９は、出発点及び設置場所の記号と、設置場所への経路と地図データに重畳して地図情報とし、次回処理を再開するまで待機する。地図情報は、通信端末装置５の表示部に出力される（図２０）。

次にステップＳ６０６において判断される認証処理の手順について説明する。図２２は入退出許可情報を用いた認証処理の手順を示すフローチャートである。通信端末装置５は、上述した入退出許可情報及び地図情報を受信し、受信した地図情報を参照して障害が生じた対象機器１の設置施設へ赴き、設置施設に入室するために入退出許可情報を用いて認証を行う。

臨時担当の対処要員は、例えば、自らが所持する通信端末装置５の表示部に出力する入退出許可情報を設置施設の守衛に示す。守衛は、入退出許可情報の発行Ｎｏと入室日とを端末装置に入力する。端末装置は、守衛により入力された発行Ｎｏ及び入室日を受け付けて管理装置２へ送信する。

管理装置２のＣＰＵ２９は、端末装置から送信された発行Ｎｏ及び入室日を受信し（Ｓ１００１）、受信した発行Ｎｏが入退出許可管理データＴ７に存在するか否かを判断する（Ｓ１００２）。その結果、ＣＰＵ２９は、発行Ｎｏが入退出許可管理データＴ７に存在していないと判断した場合（Ｓ１００２でＮＯ）、認証が失敗したと判断する（Ｓ１００３）。

一方、ＣＰＵ２９は、発行Ｎｏが入退出許可管理データＴ７に存在すると判断した場合（Ｓ１００２でＹＥＳ）、発行Ｎｏに対応する発行日及び完了日を入退出許可管理データＴ７から抽出する。ＣＰＵ２９は、受信した入室日が発行日から完了日までの期間内にあるか否かを判断し（Ｓ１００４）、入室日が発行日から完了日までの期間外であると判断した場合（Ｓ１００４でＮＯ）、認証が失敗したと判断する（Ｓ１００３）。

一方、ＣＰＵ２９は、受信した入室日が発行日から完了日までの期間内であると判断した場合（Ｓ１００４でＹＥＳ）、認証に成功したと判断する（Ｓ１００５）。

実施の形態２．
上述した実施の形態１では、選定した１名の対処要員が障害の対処を行う一例を説明した。しかし、開示の支援管理方法、支援管理システム及び情報処理装置は、これに限定されるものでなく、例えば、選定した１名の対処要員から追加要求を受け付けた場合、異なる対処要員を更に選定するようにしてもよい。そこで、実施の形態２において、対処要員を追加する支援管理方法、支援管理システム及び情報処理装置について説明する。

実施の形態２における支援管理システムの全体構成は、上述した実施の形態１の場合と同様であるので、対応箇所に同一符号を付してその説明を省略する。

実施の形態２における支援管理システムは、対象機器１が自らに生じた障害を解析して障害情報を取得し、取得した障害情報を送信する。管理装置２は、対象機器１から送信された障害情報を受信し、受信した障害情報及び所定のルールに基づいて障害への対処に適した対処要員を選定し、選定した対処要員の通信端末装置５に対処指示を優先的に送信する。

まず、実施の形態２における管理装置２のＣＰＵ２９は、上述した実施の形態１の対処支援管理処理を実行することにより、主となる１名の対処要員の通信端末装置５へ対処指示を送信する（Ｓ１０９参照）。通信端末装置５は、管理装置２から送信された対処指示を受信し、受信した対処指示を表示部に画面表示する。通信端末装置５は、対処指示に応じて、主となる対処要員により入力された応答信号を受け付け、受け付けた応答信号を管理装置２へ送信する。

主となる対処要員は、一人で対処することが困難と考えたとき、自らが属するグループから別の対処要員の追加を要求する。通信端末装置５は、主となる対処要員により入力された追加要求及び対象となるグループ名を受け付け、受け付けた追加要求及びグループ名を管理装置２へ送信する。

管理装置２のＣＰＵ２９は、所定時間内に応答信号を受信したと判断した場合（Ｓ１１０でＹＥＳを参照）であって、追加要求及びグループ名を受信した場合、上述した実施の形態１の対処支援管理処理を実行するのと並行して以下の要員追加処理を実行する。図２３は要員追加処理の手順を示すフローチャートである。

ＣＰＵ２９は、主となる対処要員の通信端末装置５から送信された追加要求及びグループ名を受信し（Ｓ１１０１）、受信したグループ名の連絡手順を連絡手順リストテーブルＴ３から取得する（Ｓ１１０２）。

ＣＰＵ２９は、取得した連絡手順に基づいて要員情報取得処理を実行する（Ｓ１１０３）。なお、要員情報取得処理の手順は、上述した実施の形態１における要員情報取得処理の手順と同様であるから、対応手順に同一のステップ番号を付してその説明を省略する。

ＣＰＵ２９は、取得した連絡手順及び要員情報に基づいて、追加すべき対処要員への連絡順番を組み立てる連絡先組立処理を実行する（Ｓ１１０４）。なお、連絡先組立処理の手順は、上述した実施の形態１における連絡先組立処理の手順と同様であるから、対応手順に同一のステップ番号を付してその説明を省略する。

ＣＰＵ２９は、連絡先組立処理により組み立てた連絡順番のうちの主たる対処要員の通信端末装置５を除いて最先となる対処要員の通信端末装置５へ対処指示を送信する（Ｓ１１０５）。対処要員の通信端末装置５は、管理装置２から送信された対処指示を受信し、受信した対処指示を表示部に画面出力する。通信端末装置５は、対処指示に応じて、対処要員により入力された応答信号を受け付け、受け付けた応答信号を管理装置２へ送信する。

管理装置２のＣＰＵ２９は、通信端末装置５から所定時間内に応答信号を受信したか否かを判断し（Ｓ１１０６）、所定時間内に応答信号を受信していないと判断した場合（Ｓ１１０６でＮＯ）、ステップＳ１１０４へ戻り、連絡先組立処理により組み立てた連絡手順のうち、主たる対処要員及び応答がない対処要員の通信端末装置５を除いて最先となる対処要員の通信端末装置５へ対処指示を送信する。

一方、ＣＰＵ２９は、所定時間内に応答信号を受信したと判断した場合（Ｓ１１０６でＹＥＳ）、ステップＳ１０２で実行した対処分析処理の結果において、対処方法が“リモートメンテナンス”であるか否かを判断する（Ｓ１１０７）。その結果、ＣＰＵ２９は、対処方法が“リモートメンテナンス”である場合（Ｓ１１０７でＹＥＳ）、追加すべき対処要員に対して遠隔対処処理を実行し（Ｓ１１０８）、要員追加処理を完了する。なお、遠隔対処処理の手順は、上述した実施の形態１における遠隔対処処理の手順と同様であるから、対応手順に同一のステップ番号を付してその説明を省略する。

一方、ＣＰＵ２９は、対処方法が“リモートメンテナンス”でないと判断した場合（Ｓ１１０７でＮＯ）、現地対処処理を実行し（Ｓ１１０９）、追加要員処理を完了する。なお、現地対処処理の手順は、上述した実施の形態１における現地対処処理の手順を同様であるから、対応手順に同一のステップ番号を付してその説明を省略する。

このように、実施の形態２における対処支援システムにあっては、異なる対処要員を追加させることができる。

以上の実施の形態に関し、更に以下の付記を開示する。

（付記１）
対処支援のための管理装置で、遠隔地に設置された外部装置で生じた障害についての障害情報を受信し、受信した障害情報に基づく複数の対処要員への連絡手順を取得し、取得した連絡手順に従い外部装置で生じた障害に対する対処指示を対処要員の通信端末装置へ送信する支援管理方法において、
前記管理装置で複数の対処要員の勤務状態を夫々取得し、前記取得した連絡手順と勤務状態との関係に基づいて外部装置で生じた障害への対処に適した対処要員を選定し、前記取得した連絡手順のうち、選定した対処要員の通信端末装置への送信を優先することを特徴とする支援管理方法。

（付記２）
対処支援のための管理装置と、該管理装置と通信可能な複数の通信端末装置とを備え、前記管理装置は、遠隔地に設置された外部装置で生じた障害についての障害情報を受信する手段と、受信した障害情報に基づく複数の対処要員への連絡手順を取得する手段と、取得した連絡手順に従い外部装置で生じた障害に対する対処指示を対処要員の通信端末装置へ送信する送信手段とを支援管理システムにおいて、
前記管理装置は、
各対処要員の勤務状態を夫々取得する取得手段と、
前記取得した連絡手順と勤務状態との関係に基づいて外部装置で生じた障害への対処に適した対処要員を選定する選定手段と
を備え、
前記送信手段は、前記取得した連絡手順のうち、前記選定手段が選定した対処要員の通信端末装置への送信を優先するようにしてあることを特徴とする支援管理システム。

（付記３）
前記管理装置は、
障害が生じた外部装置が自ら対処できるか否かを判断する判断手段を更に備え、
前記送信手段は、障害が生じた外部装置が自ら対処できると前記判断手段が判断した場合、対処要員の通信端末装置への送信を行わないようにしてあることを特徴とする付記２に記載の支援管理システム。

（付記４）
前記勤務状態は、各対処要員が対処指示を受信して確認できる状態であるか否かを示すデータを含み、
前記選定手段は、対処指示を確認できない対処要員を選定から除外するようにしてあることを特徴とする付記２又は３に記載の支援管理システム。

（付記５）
前記管理装置は、
対処指示を遠隔操作による対処又は現地での対処の何れかに特定する特定手段を更に備え、
前記取得手段は、該特定手段にて対処指示を遠隔操作による対処と特定した場合、対処要員が専任であるか否かを示すデータを含む勤務状態を取得し、
前記選定手段は、専任の対処要員の通信端末装置への送信を優先するようにしてあることを特徴とする付記２乃至４の何れか一つに記載の支援管理システム。

（付記６）
前記取得手段は、前記特定手段にて対処指示を現地での対処と特定した場合、対処要員が障害が生じた外部機器の設置場所の近傍で勤務しているか否かを示すデータを含む勤務状態を取得し、
前記選定手段は、障害が生じた外部機器の設置場所の近傍で勤務している対処要員の通信端末装置への送信を優先するようにしてあることを特徴とする付記５に記載の支援管理システム。

（付記７）
前記送信手段は、対処指示と共に、障害が生じた外部機器の設置場所への入退出を許可する入退出許可情報と、該設置場所についての地図情報とを送信するようにしてあることを特徴とする付記６に記載の支援管理システム。

（付記８）
遠隔地に設置された外部装置で生じた障害についての障害情報を受信する手段と、受信した障害情報に基づく複数の対処要員への連絡手順を取得する手段と、取得した連絡手順に従い外部装置で生じた障害に対する対処指示を対処要員の通信端末装置へ送信する送信手段とを備える情報処理装置において、
各対処要員の勤務状態を夫々取得する取得手段と、
前記取得した連絡手順と勤務状態との関係に基づいて外部装置で生じた障害への対処に適した対処要員を選定する選定手段と
を備え、
前記送信手段は、前記取得した連絡手順のうち、前記選定手段が選定した対処要員の通信端末装置への送信を優先するようにしてあることを特徴とする情報処理装置。

（付記９）
障害が生じた外部の装置で対処できるか否かを判断する対処判断手段を更に備え、
前記指示送信手段は、該対処判断手段にて外部装置で対処できると判断した場合、対処要員の通信端末装置への送信を行わないようにしてあることを特徴とする付記８に記載の情報処理装置。

（付記１０）
前記状態取得手段は、少なくとも対処要員が対処指示を確認できる状態であるか否かを示すデータを含む勤務状態を取得し、
前記要員選定手段は、対処指示を確認できる状態でない対処要員を選定から除外するようにしてあることを特徴とする付記８又は９に記載の情報処理装置。

（付記１１）
対処指示を遠隔操作による対処又は現地での対処の何れかに特定する対処特定手段を更に備え、
前記状態取得手段は、該対処特定手段にて対処指示を遠隔操作による対処と特定した場合、対処要員が専任であるか否かを示すデータを含む勤務状態を取得し、
前記要員選定手段は、専任の対処要員の通信端末装置への送信を優先するようにしてあることを特徴とする付記８乃至１０の何れか一つに記載の情報処理装置。

（付記１２）
前記状態取得手段は、前記対処特定手段にて対処指示を現地での対処と特定した場合、対処要員が障害が生じた外部の装置の設置位置の近傍で勤務しているか否かを示すデータを含む勤務状態を取得し、
前記要員選定手段は、障害が生じた外部の装置の設置場所の近傍で勤務している対処要員の通信端末装置への送信を優先するようにしてあることを特徴とする付記１１に記載の情報処理装置。

（付記１３）
前記指示送信手段は、対処指示と共に、障害が生じた外部の装置の設置場所への入退出許可情報と、該設置場所についての地図情報とを送信するようにしてあることを特徴とする付記１２に記載の情報処理装置。

本発明に係る支援管理システムの全体構成図である。 管理装置の構成を示すブロック図である。 障害情報テーブルの格納例を示す説明図である。 障害対応リストテーブルの格納例を示す説明図である。 連絡手順リストテーブルの格納例を示す説明図である。 要員情報テーブルの格納例を示す説明図である。 機器情報テーブルの格納例を示す説明図である。 設置施設情報テーブルの格納例を示す説明図である。 入退出許可管理データの構造を示す説明図である。 管理装置が実行する対処支援管理処理の手順を示すフローチャートである。 管理装置が実行する対処支援管理処理の手順を示すフローチャートである。 対応分析処理の手順を示すフローチャートである。 要員情報取得処理の手順を示すフローチャートである。 連絡先組立処理の手順を示すフローチャートである。 遠隔対処処理の手順を示すフローチャートである。 現地対処処理の手順を示すフローチャートである。 入退出許可情報の表示例を示す模式図である。 入退出許可情報生成処理の手順を示すフローチャートである。 入退出許可情報生成処理の手順を示すフローチャートである。 地図情報の表示例を示す模式図である。 地図情報生成処理の手順を示すフローチャートである。 入退出許可情報を用いた認証処理の手順を示すフローチャートである。 要員追加処理の手順を示すフローチャートである。

符号の説明

１ 対象機器
２ 管理装置
２１ 外部記憶装置
２２ 通信インタフェース
２３ ＲＡＭ
２４ ＲＯＭ
２５ 補助記憶装置
２６ 入力インタフェース
２７ 出力インタフェース
２８ データベース通信インタフェース
２９ ＣＰＵ
３ データベース
４ ウェブサーバ
５ 通信端末装置

Claims (5)

1. 対処支援のための管理装置で、遠隔地に設置された外部装置で生じた障害についての障害情報を受信し、受信した障害情報に基づく複数の対処要員への連絡手順を取得し、取得した連絡手順に従い外部装置で生じた障害に対する対処指示を対処要員の通信端末装置へ送信する支援管理方法において、
   前記管理装置で複数の対処要員の勤務状態を夫々取得し、前記取得した連絡手順と勤務状態との関係に基づいて外部装置で生じた障害への対処に適した対処要員を選定し、前記取得した連絡手順のうち、選定した対処要員の通信端末装置への送信を優先することを特徴とする支援管理方法。
2. 対処支援のための管理装置と、該管理装置と通信可能な複数の通信端末装置とを備え、前記管理装置は、遠隔地に設置された外部装置で生じた障害についての障害情報を受信する手段と、受信した障害情報に基づく複数の対処要員への連絡手順を取得する手段と、取得した連絡手順に従い外部装置で生じた障害に対する対処指示を対処要員の通信端末装置へ送信する送信手段とを支援管理システムにおいて、
   前記管理装置は、
   各対処要員の勤務状態を夫々取得する取得手段と、
   前記取得した連絡手順と勤務状態との関係に基づいて外部装置で生じた障害への対処に適した対処要員を選定する選定手段と
   を備え、
   前記送信手段は、前記取得した連絡手順のうち、前記選定手段が選定した対処要員の通信端末装置への送信を優先するようにしてあることを特徴とする支援管理システム。
3. 前記管理装置は、
   障害が生じた外部装置が自ら対処できるか否かを判断する判断手段を更に備え、
   前記送信手段は、障害が生じた外部装置が自ら対処できると前記判断手段が判断した場合、対処要員の通信端末装置への送信を行わないようにしてあることを特徴とする請求項２に記載の支援管理システム。
4. 前記勤務状態は、各対処要員が対処指示を受信して確認できる状態であるか否かを示すデータを含み、
   前記選定手段は、対処指示を確認できない対処要員を選定から除外するようにしてあることを特徴とする請求項２又は３に記載の支援管理システム。
5. 遠隔地に設置された外部装置で生じた障害についての障害情報を受信する手段と、受信した障害情報に基づく複数の対処要員への連絡手順を取得する手段と、取得した連絡手順に従い外部装置で生じた障害に対する対処指示を対処要員の通信端末装置へ送信する送信手段とを備える情報処理装置において、
   各対処要員の勤務状態を夫々取得する取得手段と、
   前記取得した連絡手順と勤務状態との関係に基づいて外部装置で生じた障害への対処に適した対処要員を選定する選定手段と
   を備え、
   前記送信手段は、前記取得した連絡手順のうち、前記選定手段が選定した対処要員の通信端末装置への送信を優先するようにしてあることを特徴とする情報処理装置。

Images