JP2007323198A - 保守出動管理プログラム、保守出動管理装置および保守出動管理方法 - Google Patents

Abstract

【課題】障害の発生頻度に応じて迅速に保守出動を要請する。
【解決手段】ＡＴＭ１００で障害が発生する度に、保守管理サーバ２００の障害履歴取得部２６１は、その障害に係る情報を障害情報としてＡＴＭ１００から取得し、保守出動判定部２６３は、その障害情報に係る時間間隔に基づいて保守出動を要するか否かを判定し、出動要請送信部２６４は、保守出動対象となるＡＴＭ１００の保守を管轄する所轄の保守センタクライアント３００に対して保守出動を要請する旨の情報を送信する。
【選択図】 図１

Description

この発明は、装置で検知された障害に基づいて該装置の保守点検を管轄する保守センタ内に設けられた保守出動要請受信装置に対して該装置への保守出動を要請する情報を送信する保守出動管理プログラム、保守出動管理装置および保守出動管理方法に関し、特に、障害の発生頻度に適合した迅速な保守出動を可能とし、保守点検の効率化を図ることができる保守出動管理プログラム、保守出動管理装置および保守出動管理方法に関するものである。

銀行の店舗などに設置されたＡＴＭ（Automatic Teller Machine）に障害が発生した場合、その障害が紙幣詰まりなどの軽微なものであれば店舗の事務員が対処する。しかし、軽微な障害であってもその障害が頻発し事務員の手には負えないようであれば、ＡＴＭの管理を担当する担当店員は、ベンダのコールセンタへ電話をかけ、電話を受けたコールセンタスタッフはその際の応答具合に基づいて保守点検員（カスタマーエンジニア）へ出動を要請するか否かを判断している。

また、特許文献１には、ＡＴＭがリモート保守装置に対して保守点検の要求を送信すると、リモート保守装置がそのＡＴＭと同じ店舗に設置されている他のＡＴＭに点検情報の送信を要求してそれらのＡＴＭから点検情報を送信させることで、店舗内にある全てのＡＴＭの状況を事前に把握することができ、かつ保守点検が必要なＡＴＭのみに限定して動作を停止させて点検作業を行うことでＡＴＭの稼働率を上昇させることができるリモート保守システムが開示されている。

特開２００４−７８９００号公報

しかしながら、電話による問い合わせだけでは、発生した障害に対する緊急度などの判断は担当店員やコールセンタスタッフの主観に依る部分が大きく、コールセンタに問い合わせられてから実際に保守出動が要請されるまでに多大な時間を要し非効率であるばかりでなく、判断結果にも個人差が生じてしまうという問題があった。

このため、緊急を要する障害であるにもかかわらずコールセンタからの保守出動要請に遅延が生じたり、また逆に、店舗の事務員だけでも対処可能な軽微な障害であるにもかかわらず保守出動を要請したりする事態を招いてしまう。ここで、保守センタで待機する保守点検員はコールセンタからの保守出動要請を受諾した時点で出動することから、場合によっては緊急を要する際の対処が遅れるばかりでなく、必要な人員が割けなくなる事態も発生しかねない。

また、特許文献１に記載の手法では、ＡＴＭで発生した障害の種別などをリモート保守装置が自動的に取得することができるものの、障害が発生したか否の判定はＡＴＭ側で行っているため、ＡＴＭ側での設定によってはその判断基準にばらつきが生じてしまう。

そこで、管理対象となる全てのＡＴＭに対して一律に適用される判断基準を設ける手法も考えられるが、この手法ではＡＴＭを管理する担当店員の性格（性急さ）を反映することができず、対応が遅いと一方的に思い込み不満を抱く担当店員が現れることにもなりかねない。

この発明は、上述した従来技術による問題点を解消するためになされたものであり、障害の発生頻度に適合した迅速な保守出動を可能とし、保守点検の効率化を図ることができる保守出動管理プログラム、保守出動管理装置および保守出動管理方法を提供することを目的とする。

上述した課題を解決し、目的を達成するため、本発明は、装置で検知された障害に基づいて該装置の保守点検を管轄する保守センタ内に設けられた保守出動要請受信装置に対して該装置への保守出動を要請する情報を送信する保守出動管理プログラムであって、コンピュータを、前記装置から送信された障害情報を履歴として記憶する障害履歴記憶手段、前記障害履歴記憶手段により記憶された障害情報に係る時間間隔に基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行う保守出動判定手段、として機能させることを特徴とする。

また、本発明は、上記発明において、コンピュータを、前記装置を管理する担当者を識別する担当者識別手段としてさらに機能させ、前記保守出動判定手段は、前記時間間隔が前記担当者識別手順により識別された担当者ごとに設定される閾値未満であるときに前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信することを特徴とする。

また、本発明は、上記発明において、コンピュータを、担当者が管理対象とする装置における障害の発生間隔に基づいて前記閾値を決定する閾値決定手段としてさらに機能させることを特徴とする。

また、本発明は、上記発明において、コンピュータを、担当者が管理対象とする装置における障害復旧から障害再発生までの時間間隔に基づいて前記閾値を決定する閾値決定手段としてさらに機能させることを特徴とする。

また、本発明は、上記発明において、コンピュータを、前記装置を管理する担当者から受け付けた保守出動依頼を履歴として記憶する保守出動依頼履歴記憶手段としてさらに機能させ、前記閾値決定手段は、前記障害履歴記憶手段により記憶された障害情報のうち、前記障害履歴記憶手段により記憶された保守出動依頼に係る日時から所定の期間内に記憶された障害情報に基づいて前記閾値を決定することを特徴とする。

また、本発明は、上記発明において、コンピュータを、障害発生開始日時と保守要求受付日時との間隔に基づいて、保守出動における緊急度を設定する緊急度設定手段としてさらに機能させ、前記保守出動判定手段は、前記緊急度設定手段により設定された緊急度に応じて設定された閾値と前記障害情報に係る時間間隔とに基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行うことを特徴とする。

また、本発明は、上記発明において、代替可能な装置が存在しない設置所における装置において発生した障害に対する緊急度を代替可能な装置が存在する設置所における装置において発生した障害に対する緊急度よりも高く設定する緊急度設定手段としてさらに機能させ、前記保守出動判定手段は、前記緊急度設定手段により設定された緊急度に応じて設定された閾値と前記障害情報に係る時間間隔とに基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行うことを特徴とする。

また、本発明は、上記発明において、コンピュータに、前記装置で発生した障害のうち繁忙期に発生した障害に対する緊急度を繁忙期以外に発生した障害に対する緊急度よりも高く設定する緊急度設定手段としてさらに機能させ、前記保守出動判定手段は、前記緊急度設定手段により設定された緊急度に応じて設定された閾値と前記障害情報に係る時間間隔とに基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行うことを特徴とする。

また、本発明は、装置で検知された障害に基づいて該装置の保守点検を管轄する保守センタ内に設けられた保守出動要請受信装置に対して該装置への保守出動を要請する情報を送信する保守出動管理装置であって、前記装置から送信された障害情報を履歴として記憶する障害履歴記憶手段と、前記障害履歴記憶手段により記憶された障害情報に係る時間間隔に基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行う保守出動判定手段と、を備えたことを特徴とする。

また、本発明は、装置で検知された障害に基づいて該装置の保守点検を管轄する保守センタ内に設けられた保守出動要請受信装置に対して該装置への保守出動を要請する情報を送信する保守出動管理方法であって、前記装置から送信された障害情報を履歴として記憶する障害履歴記憶工程と、前記障害履歴記憶工程により記憶された障害情報に係る時間間隔に基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行う保守出動判定工程と、を含んだことを特徴とする。

本発明によれば、装置から送信された障害情報を履歴として記憶し、記憶した障害情報に係る時間間隔に基づいて装置への保守出動を要請する情報を保守出動要請受信装置に送信するか否かの判定を行うこととしたので、障害の発生頻度に適合した迅速な保守出動を可能とし、保守点検の効率化を図ることができるという効果を奏する。

また、本発明によれば、装置を管理する担当者を識別し、時間間隔が識別した担当者ごとに設定される閾値未満であるときに装置への保守出動を要請する情報を保守出動要請受信装置に送信することとしたので、保守出動を要請するか否かの判断基準を担当者ごとに設定することができ、担当者に合わせてフレキシブルに対応することができるという効果を奏する。

また、本発明によれば、担当者が管理対象とする装置における障害の発生間隔に基づいて閾値を決定することとしたので、担当者の性格などの要因により担当者ごとに異なる保守出動要請の判断基準を加味して保守点検を要するか否かを判定することができるという効果を奏する。

また、本発明によれば、担当者が管理対象とする装置における障害復旧から障害再発生までの時間間隔に基づいて閾値を決定することとしたので、担当者の性格などの要因により担当者ごとに異なる保守出動要請の判断基準を加味して保守点検を要するか否かを判定することができるという効果を奏する。

また、本発明によれば、装置を管理する担当者から受け付けた保守出動依頼を履歴として記憶し、記憶した障害情報のうち、記憶した保守出動依頼に係る日時から所定の期間内に記憶された障害情報に基づいて閾値を決定することとしたので、保守出動を要請するか否かを判定する際に、担当者が出動要請を依頼する状況の傾向を反映させることができるという効果を奏する。

また、本発明によれば、障害発生開始日時と保守要求受付日時との間隔に基づいて、保守出動における緊急度を設定し、緊急度に応じて設定された閾値と障害情報に係る時間間隔とに基づいて装置への保守出動を要請する情報を保守出動要請受信装置に送信するか否かの判定を行うこととしたので、障害発生開始日時と保守要求受付日時との間隔が短く切羽詰った状況下に置かれた担当者からの保守出動の依頼に対して優先的に保守出動を行わせることができるという効果を奏する。

また、本発明によれば、代替可能な装置が存在しない設置所における装置において発生した障害に対する緊急度を代替可能な装置が存在する設置所における装置において発生した障害に対する緊急度よりも高く設定し、緊急度に応じて設定された閾値と障害情報に係る時間間隔とに基づいて装置への保守出動を要請する情報を保守出動要請受信装置に送信するか否かの判定を行うこととしたので、代替可能な装置が存在せず障害発生により業務に重大な支障をきたすような場合には優先的に保守出動を行わせることができるという効果を奏する。

また、本発明によれば、装置で発生した障害のうち繁忙期に発生した障害に対する緊急度を繁忙期以外に発生した障害に対する緊急度よりも高く設定し、緊急度に応じて設定された閾値と障害情報に係る時間間隔とに基づいて装置への保守出動を要請する情報を保守出動要請受信装置に送信するか否かの判定を行うこととしたので、繁忙日など装置の稼働率が高い時期に発生した障害に対して優先的に保守出動を行わせることができるという効果を奏する。

以下に添付図面を参照して、この発明に係る保守出動管理プログラム、保守出動管理装置および保守出動管理方法の好適な実施例を詳細に説明する。

まず、本発明に係る保守出動管理処理の概念について説明する。この保守出動管理処理では、ＡＴＭなどの装置で紙幣詰まりなどの障害が検知される度に、その装置は保守点検のための保守出動が必要であるか否かの判定処理を行う保守管理サーバに障害に係る情報を送信し、その情報を受信した保守管理サーバは、受信した情報に係る障害発生間隔などの時間間隔に基づいて、障害が検知された装置に対する保守点検のための保守出動が必要であるか否かを判定している。

これにより、ＡＴＭなどの装置で発生した障害の発生頻度に適合した迅速な保守出動を可能とし、その装置に対する保守点検の効率化を図ることができる。

つぎに、本実施例に係る保守出動管理システムの構成について説明する。図１は、本実施例に係る保守出動管理システムの構成を示す機能ブロック図である。同図に示すように、この保守出動管理システム１は、ＡＴＭ１００と、保守管理サーバ２００と、保守センタクライアント３００とが、ネットワーク５０により相互に接続されて構成されている。

なお、ここでは説明の便宜上、同図においては１台のＡＴＭ１００、および１台の保守センタクライアント３００のみを示したが、ＡＴＭ１００および保守センタクライアント３００は多数存在する。

ＡＴＭ１００は、銀行の店舗などに設置された現金自動預け払い機であり、記憶部１１０と、通信Ｉ／Ｆ部１２０と、制御部１３０とを有する。なお、図１においては、ＡＴＭ１００の主たる機能である現金の預け払いに係る各処理部、すなわち入金、出金、通帳記入、レシート発行、各種情報の入出力などの処理を行う処理部については図示を省略している。

記憶部１１０は、ハードディスク装置や不揮発性メモリなどの記憶デバイスであり、障害種別テーブル１１１を記憶する。障害種別テーブル１１１は、ＡＴＭ１００で発生しうる障害の種別を記憶するテーブルである。

図２は、障害種別テーブル１１１の一例を示す図である。同図に示すように、この障害種別テーブル１１１は、ＡＴＭ１００で発生しうる障害の種別と、エラーコードとを対応付けて記憶する。

通信Ｉ／Ｆ部１２０は、保守管理サーバ２００との間で通信を行う通信インタフェースであり、この通信Ｉ／Ｆ部１２０を介して後述する障害情報が保守管理サーバ２００に送信される。

制御部１３０は、ＡＴＭ１００の全体制御を行う制御部であり、障害検知部１３１と、障害情報送信部１３２とを有する。

障害検知部１３１は、ＡＴＭ１００で発生した障害をリアルタイムに検知し、障害の発生を検知したときにはさらにその障害の種別を特定する処理部である。

障害情報送信部１３２は、障害検知部１３１が障害の発生を検知すると、通信Ｉ／Ｆ部１２０を介して障害情報を保守管理サーバ２００に送信する処理部である。ここで、障害情報とは、ＡＴＭ１００で発生した障害に関する情報のことであり、具体的には、各ＡＴＭ１００に固有のＩＤと、障害検知部１３１が特定した障害の種別に対応するエラーコードと、その障害が発生した日時とを対応付けた情報である。

また、この障害情報送信部１３２は、ＡＴＭ１００が障害発生により停止していた状態から復旧しＡＴＭ１００の再起動が行われた際にも、その再起動が行われた時間などの情報を障害情報として保守管理サーバ２００に送信する。この場合、障害情報送信部１３２は、障害情報に含まれるエラーコードについては、障害種別テーブル１１１に対応するエラーコードに代えて、再起動を示すコード「Ｒ」を対応付ける。

保守管理サーバ２００は、コールセンタに設置されたサーバ装置であり、各ＡＴＭ１００から送信された障害情報を取得するとともに、ＡＴＭ１００の管理を担当する担当店員から電話で保守出動要請を受け付けたときには、その障害情報に基づいてＡＴＭ１００の保守を管轄する所轄の保守センタに設置された保守センタクライアント３００に対して保守出動を要請する旨の情報を出力する。この保守管理サーバ２００は、操作入力部２１０と、表示部２２０と、電話入力部２３０と、通信Ｉ／Ｆ部２４０と、記憶部２５０と、制御部２６０とを有する。

操作入力部２１０は、マウスやキーボードなどの入力デバイスであり、コールセンタスタッフからの操作を受け付ける。表示部２２０は、モニタなどの表示装置であり、保守出動対象となるＡＴＭ１００に関する各種情報や、後述する保守出動要請画面などを表示する。

電話入力部２３０は、図示しない一般電話回線と接続され、コールセンタに掛けられた電話の発信元に係る情報などを受け付ける入力デバイスである。通信Ｉ／Ｆ部２４０は、ＡＴＭ１００および保守センタクライアント３００との間で通信を行う通信インタフェースである。

記憶部２５０は、ハードディスク装置や不揮発性メモリなどの記憶デバイスであり、障害履歴テーブル２５１と、障害緊急度テーブル２５２と、担当店員情報テーブル２５３と、所轄保守センタテーブル２５４と、出動要請履歴テーブル２５５とを記憶する。

障害履歴テーブル２５１は、通信Ｉ／Ｆ部２４０を介して各ＡＴＭ１００から取得した障害情報をＡＴＭ１００ごとに記憶するテーブルである。図３は、障害履歴テーブル２５１の一例を示す図である。同図に示すように、この障害履歴テーブル２５１は、エラーコードと、障害または再起動が発生した日時とを対応付けて、ＡＴＭ１００ごとに記憶する。

同図においては、ＩＤが「ATM001」であるＡＴＭ１００において、次のように障害または再起動が相次いで発生していることを示している。
（１）２００６年４月４日９時５０分に、エラーコード「E001」の障害が発生
（２）２００６年４月４日１０時０分に再起動
（３）２００６年４月４日１０時１５分に、エラーコード「E001」の障害が発生
（４）２００６年４月４日１０時３５分に再起動
（５）２００６年４月４日１０時４８分に、エラーコード「E001」の障害が発生

障害緊急度テーブル２５２は、ＡＴＭ１００で発生しうる障害に応じた緊急度に関する情報を記憶するテーブルである。図４は、障害緊急度テーブル２５２の一例を示す図である。同図に示すように、この障害緊急度テーブル２５２は、エラーコードと、障害の緊急度と、その障害の緊急度に対応する障害発生間隔閾値とを対応付けて記憶する。

ここで、緊急度は高い方から順に「Ａ」、「Ｂ」、「Ｃ」の３段階に分類されており、このうち最も低い緊急度「Ｃ」については、例えば紙幣詰まりなど、店舗の事務員でも充分に対処可能な軽微な障害が対応付けられている。

また、障害発生間隔閾値は、ＡＴＭ１００で発生した障害に対して保守出動を要請するか否かの判定を、その障害の発生間隔に基づいて行うときに用いる閾値である。同図においては、この障害発生間隔閾値は、緊急度「Ａ」の障害にはＴ_Aが、緊急度「Ｂ」の障害にはＴ_Bが対応する。

なお、緊急度「Ｃ」の障害については、この障害発生間隔閾値に代えて、後述する出動要請時障害発生間隔Ｔ_M（図５参照）の値を用いて保守出動の可否が判定されるため、同図においては緊急度「Ｃ」に対応する障害発生間隔閾値の値は「なし」となっている。

担当店員情報テーブル２５３は、ＡＴＭ１００の管理を担当する担当店員に関する情報や、その担当店員が管理対象とする各ＡＴＭ１００に関する情報を記憶するテーブルである。図５は、担当店員情報テーブル２５３の一例を示す図である。同図に示すように、この担当店員情報テーブル２５３は、担当店員ＩＤと、氏名と、電話番号と、出動要請時障害発生間隔と、管理対象とする全てのＡＴＭのＩＤとを対応付けて記憶する。

出動要請時障害発生間隔は、ＡＴＭ１００で発生した障害の緊急度が「Ｃ」である場合に、この障害に対して保守出動を要請するか否かの判定を、その障害の発生間隔に基づいて行うときに用いる閾値である。この出動要請時障害発生間隔は、ＡＴＭ１００の管理を担当し、出動要請を行う担当店員ごとに設定される値であり、出動要請時障害発生間隔算出部２６５により算出される。なお、この出動要請時障害発生間隔の算出方法については後述する。

ここで、電話番号については、担当店員が待機する店舗の事務局、または担当店員が所持する携帯電話のいずれの番号であってもよい。また、店舗によっては、ＡＴＭ１００を管理する担当店員が曜日によって異なる場合もあることから、担当する曜日に関する情報を上述した担当店員情報テーブル２５３にさらに対応付けて記憶させてもよい。

所轄保守センタテーブル２５４は、ＡＴＭ１００に対する保守点検を管轄する保守センタに関する情報を記憶するテーブルである。図６は、所轄保守センタテーブル２５４の一例を示す図である。同図に示すように、この所轄保守センタテーブル２５４は、ＡＴＭ１００のＩＤと、そのＡＴＭ１００に対する保守点検を管轄する保守センタを識別する所轄保守センタＩＤとを対応付けて記憶する。

出動要請履歴テーブル２５５は、コールセンタに対して保守出動が要請された日時に関する情報を記憶するテーブルである。図７は、出動要請履歴テーブル２５５の一例を示す図である。同図に示すように、この出動要請履歴テーブル２５５は、担当店員ＩＤと、保守出動要請を受け付けた日時とを対応付けて記憶する。

制御部２６０は、保守管理サーバ２００の全体制御を行う制御部であり、障害履歴取得部２６１と、担当店員識別部２６２と、保守出動判定部２６３と、出動要請送信部２６４と、出動要請時障害発生間隔算出部２６５とを有する。

障害履歴取得部２６１は、通信Ｉ／Ｆ部２４０を介してＡＴＭ１００から障害情報を受信し、その障害情報に基づいて送信元のＡＴＭ１００に対応する障害履歴テーブル２５１を更新する処理部である。

担当店員識別部２６２は、担当店員情報テーブル２５３に基づいてコールセンタに対して保守出動を要請した担当店員を識別する処理部であり、例えば電話入力部２３０により取得された発信元の電話番号などにより担当店員を識別する。

保守出動判定部２６３は、担当店員がコールセンタへ保守出動を要請する要因となった障害について、その障害の発生間隔に基づいてそのＡＴＭ１００への保守出動の可否を判定する処理部である。

具体的には、この保守出動判定部２６３は、まず担当店員識別部２６２が識別した担当店員が管理対象とする全てのＡＴＭを担当店員情報テーブル２５３から抽出し、それらのＡＴＭに対応する障害履歴テーブル２５１を参照する。そして、保守出動判定部２６３は、そのうち障害が発生したＡＴＭ１００に対し、一定時間内（例えば２４時間以内）において、障害発生が検知され始めてからのその障害発生間隔の平均値（算術平均）ΔＴaveが所定の閾値未満であるか否かを判定する。

例えば、図３に示したような障害が発生した場合は、この保守出動判定部２６３は、障害発生間隔の平均値ΔＴaveを、以下の手順により算出する。
（i）障害発生が検知され始めた９時５０分（１）と、次に障害発生が検知された１０時１５分（３）との時間間隔ΔＴ₁を算出する。ここで、ΔＴ₁＝２５（分）である。
（ii）障害発生が検知された１０時１５分（３）と、その次に障害発生が検知された１０時４８分（５）との時間間隔ΔＴ₂を算出する。ここで、ΔＴ₂＝３３（分）である。
（iii）上で求めたΔＴ₁とΔＴ₂との算術平均ΔＴaveを算出する。ここで、ΔＴave＝（２５＋３３）／２＝２９（分）である。

そして、保守出動判定部２６３は、この障害発生間隔の平均値ΔＴaveが所定の閾値未満である場合は、そのＡＴＭ１００において障害が頻発し保守出動を要すると判断し、そのＡＴＭ１００が設置された店舗への保守出動を保守センタに要請する操作をコールセンタスタッフから受け付ける保守出動要請画面を表示部２２０に対して表示させる。

ここで、保守出動判定部２６３は、上記閾値として、障害の緊急度が「Ａ」または「Ｂ」、すなわち障害の緊急度が比較的高い場合は、障害緊急度テーブル２５２において障害の種別に設定された障害発生間隔閾値を用いる。例えば、図４においては、その障害発生間隔閾値は、緊急度「Ａ」の障害にはＴ_Aが対応し、緊急度「Ｂ」の障害にはＴ_Bが対応する。

一方、障害の緊急度が「Ｃ」、すなわち軽微な障害である場合は、保守出動判定部２６３は、上記閾値として、担当店員情報テーブル２５３において担当店員ごとに設定された出動要請時障害発生間隔Ｔ_Mを用いる。この出動要請時障害発生間隔Ｔ_Mは、出動要請時障害発生間隔算出部２６５により担当店員ごとに算出される値である。

出動要請送信部２６４は、保守出動判定部２６３により出力された保守出動要請画面においてコールセンタスタッフにより操作入力部２１０から保守出動の要請を受け付けた際に、所轄保守センタテーブル２５４に基づいて保守出動対象となるＡＴＭ１００の保守点検を管轄する保守センタクライアント３００に対して、そのＡＴＭ１００への保守出動要請を障害の種別やその緊急度などと対応付けて送信する処理部である。

なお、ここでは、出動要請送信部２６４は、コールセンタスタッフからの操作を受け付けるまで保守センタクライアント３００に対して保守出動要請を送信する処理を待つこととしたが、コールセンタスタッフからの操作を待つことなく自動的に保守センタクライアント３００に対して保守出動要請を送信することとしてもよい。

出動要請時障害発生間隔算出部２６５は、担当店員ごとに設定された出動要請時障害発生間隔Ｔ_Mの値を算出する処理部である。この出動要請時障害発生間隔算出部２６５は、上述した障害発生間隔の平均値ΔＴaveの統計を取ることにより出動要請時障害発生間隔Ｔ_Mの値を算出する。

図８は、出動要請時障害発生間隔について説明するための説明図である。同図（ａ）は、性急な性格である担当店員Ａ氏に対する出動要請時障害発生間隔の算出手順を示しており、同図（ｂ）は、気長な性格である担当店員Ｂ氏に対する出動要請時障害発生間隔の算出手順を示している。

同図（ａ）の（１）において、ＡＴＭ１００において障害が頻発し担当店員Ａ氏により保守出動が要請されると、保守出動判定部２６３は、その要請を受け付けた日時を終点とする一定の期間内（ΔＴave算出範囲）における障害発生間隔ΔＴ₁₁，ΔＴ₁₂，ΔＴ₁₃を算出し、さらにその算術平均を障害発生間隔の平均値ΔＴaveとして算出し、その平均値ΔＴaveが所定の閾値未満であるか否かを判定する。

同様に、保守出動判定部２６３は、同図（ａ）の（２）において保守出動の要請を受け付けたときには、障害発生間隔ΔＴ₂₁，ΔＴ₂₂，ΔＴ₂₃を算出し、（３）において保守出動の要請を受け付けたときには、障害発生間隔ΔＴ₃₁，ΔＴ₃₂，ΔＴ₃₃を算出する。

そして、出動要請時障害発生間隔算出部２６５は、これらの（１）〜（３）において算出された全ての障害発生間隔ΔＴ_ijの算術平均を算出し、この値を担当店員Ａ氏に設定される出動要請時障害発生間隔Ｔ_MAとする。

また、同図（ｂ）においても同様に、（４）および（６）において、ＡＴＭ１００において障害が頻発し担当店員Ｂ氏により保守出動が要請されると、保守出動判定部２６３は、その要請を受け付けた日時を終点とする一定の期間内（ΔＴave算出範囲）における障害発生間隔ΔＴ₄₁，ΔＴ₄₂，ΔＴ₄₃およびΔＴ₅₁，ΔＴ₅₂，ΔＴ₅₃を算出し、出動要請時障害発生間隔算出部２６５はこれらの（４）および（６）における全ての障害発生間隔ΔＴ_ijの算術平均を算出し、この値を担当店員Ｂ氏に設定される出動要請時障害発生間隔Ｔ_MBとする。

ここで、担当店員Ｂ氏は気長な性格であることから、同図（ｂ）における（５）においては、ＡＴＭ１００で障害が発生したものの、担当店員Ｂ氏はその障害発生間隔は長く保守出動を要請するほどでもない軽微な障害であると判断しており、保守出動を要請していない。従って、この（５）で発生した障害における障害発生間隔は、担当店員Ｂ氏に設定される出動要請時障害発生間隔Ｔ_MBの値には反映されていない。

一方、担当店員Ａ氏は性急な性格であることから、同図（ａ）における（２）において、同図（ｂ）の（５）と同様の障害発生間隔であるにもかかわらず、担当店員Ａ氏は保守出動を要請している。従って、担当店員Ａ氏に設定される出動要請時障害発生間隔Ｔ_MAの値には、この比較的長めな障害発生間隔の値（ΔＴ₂₁，ΔＴ₂₂，ΔＴ₂₃）が反映される。

このことから、性急な性格である担当店員Ａ氏に設定される出動要請時障害発生間隔Ｔ_MAの値は、気長な性格である担当店員Ｂ氏に設定される出動要請時障害発生間隔Ｔ_MBの値よりも大きな値をとることとなる。

そして、保守出動判定部２６３は、障害発生間隔Ｔaveがこの出動要請時障害発生間隔Ｔ_M（Ｔ_MA，Ｔ_MB）未満であるか否かを調べることにより、担当店員の性格（性急さ）を加味して保守出動の可否を判定することができる。

具体的には、担当店員Ａ氏に設定された出動要請時障害発生間隔Ｔ_MAについては、その値が大きくなることから、その担当店員Ａ氏は障害の発生間隔が長く緊急を要するほどでもない場合であってもコールセンタへ保守出動を要請する性急な性格であるとみなされ、障害発生間隔の平均値ΔＴaveが出動要請時障害発生間隔Ｔ_M未満となる場合が多くなり、保守出動が必要と判定される確率が高くなる。

逆に、担当店員Ｂ氏に設定された出動要請時障害発生間隔Ｔ_MBについては、その値が小さくなることから、その担当店員Ｂ氏は障害の発生間隔が短く比較的緊急を要するような場合にしか保守出動を要請しない気長な性格であるとみなされ、障害発生間隔の平均値ΔＴaveが出動要請時障害発生間隔Ｔ_M未満とはならない場合が多くなり、保守出動が必要と判定される確率が低くなる。

保守センタクライアント３００は、ＡＴＭ１００の保守点検を管轄する保守センタなどに設置されたコンピュータであり、保守管理サーバ２００から送信された保守出動要請に応じて、保守点検員は保守出動対象となるＡＴＭ１００が設置された店舗へと出動する。

次に、本実施例に係る保守管理サーバ２００が実行する保守出動可否判定処理の処理手順について説明する。図９は、本実施例に係る保守管理サーバ２００が実行する保守出動可否判定処理の処理手順を示すフローチャートである。同図に示すように、保守管理サーバ２００の担当店員識別部２６２は、ＡＴＭ１００の管理を担当する担当店員から電話による保守出動要請を受け付けると、電話入力部２３０を介してその担当店員を発信元の電話番号などから識別し（ステップＳ１０１）、その担当店員に対応する出動要請履歴テーブル２５５を更新する（ステップＳ１０２）。

そして、保守出動判定部２６３は、障害履歴取得部２６１によって取得され障害履歴テーブル２５１に記憶された障害情報を参照し、担当店員が管理するＡＴＭ１００の中から障害が発生したＡＴＭ１００を特定する（ステップＳ１０３）。

そして、保守出動判定部２６３は、障害が発生したＡＴＭ１００に対応する障害履歴テーブル２５１において、コールセンタへの保守出動を要請する要因となった障害について、その障害発生間隔の平均値（算術平均）ΔＴaveを算出する（ステップＳ１０４）。

具体的には、保守出動判定部２６３は、障害履歴テーブル２５１に基づいて、一定期間内において、障害発生が検知され始めてからの各障害の発生日時の時間間隔ΔＴ₁，ΔＴ₂，・・に対する算術平均ΔＴaveを算出する。

その後、保守出動判定部２６３は、発生した障害のエラーコードに対応する緊急度を障害緊急度テーブル２５２から読み出し、その障害の緊急度を判定する（ステップＳ１０５）。

その結果、障害の緊急度が「Ｃ」である場合（ステップＳ１０５，「Ｃ」）、すなわち軽微な障害である場合は、保守出動判定部２６３は、コールセンタに問い合わせた担当店員ごとに設定された出動要請時障害発生間隔Ｔ_Mを担当店員情報テーブル２５３から読み出し（ステップＳ１０６）、障害発生間隔の平均値ΔＴaveが、担当店員ごとに設定された出動要請時障害発生間隔Ｔ_M未満であるか否かを判定する（ステップＳ１０７）。

その結果、障害発生間隔の平均値ΔＴaveがＴ_M未満である場合は（ステップＳ１０７，Ｙｅｓ）、保守出動判定部２６３は、保守点検が必要であると判断し、表示部２２０に保守出動要請画面を表示させる（ステップＳ１０８）。

一方、障害発生間隔の平均値ΔＴaveがＴ_M以上である場合は（ステップＳ１０７，Ｎｏ）、保守出動判定部２６３は、保守点検は不要であると判断し、障害が発生したＡＴＭ１００に対する重点監視を担当店員に促す指示を表示部２２０に出力させ（ステップＳ１０９）、コールセンタスタッフにより担当店員に対してそのＡＴＭ１００に対する重点監視を電話で指示させ、この保守出動可否判定処理を終了する。

また、ステップＳ１０５において、障害の緊急度が「Ａ」または「Ｂ」である場合（ステップＳ１０５，「ＡまたはＢ」）、すなわち緊急度が比較的高い障害である場合は、保守出動判定部２６３は、障害発生間隔の平均値ΔＴaveが、障害緊急度テーブル２５２においてその障害の緊急度に対応する閾値（障害発生間隔閾値）未満であるか否かを判定する（ステップＳ１１０）。

その結果、障害発生間隔の平均値ΔＴaveが閾値未満である場合は（ステップＳ１１０，Ｙｅｓ）、ステップＳ１０８に移り、保守出動判定部２６３は、表示部２２０に保守出動要請画面を表示させる。

一方、障害発生間隔の平均値ΔＴaveが閾値以上である場合は（ステップＳ１１０，Ｎｏ）、ステップＳ１０６に移り、保守出動判定部２６３は、閾値として障害の種別ごとに対応する障害発生間隔閾値Ｔ_A，Ｔ_Bに代えて、担当店員ごとに設定された出動要請時障害発生間隔Ｔ_Mを用いてΔＴaveの値を再判定する。このとき、その障害の緊急度は「Ｃ」へと変更される。

その後、出動要請送信部２６４は、保守出動要請画面において、操作入力部２１０を介してコールセンタスタッフにより保守出動を要請する旨の入力がなされるまで待つ（ステップＳ１１１）。

そして、出動要請送信部２６４は、保守出動の要請する旨の入力を受け付けると、所轄保守センタテーブル２５４を参照して保守出動の要請を受け付けたＡＴＭ１００の保守点検を管轄する保守センタクライアント３００を特定し、通信Ｉ／Ｆ部２４０を介してその保守センタクライアント３００に対して、発生した障害の種別やその緊急度などと対応付けてそのＡＴＭ１００への保守出動を要請する情報を送信する（ステップＳ１１２）。

その後、出動要請時障害発生間隔算出部２６５は、コールセンタに問い合わせた担当店員の出動要請時障害発生間隔Ｔ_Mを再計算して担当店員情報テーブル２５３を更新し（ステップＳ１１３）、この保守出動可否判定処理を終了する。

このように、担当店員識別部２６２が、コールセンタに問い合わせた担当店員を識別し、保守出動判定部２６３が、その担当店員に対応する出動要請時障害発生間隔に基づいて保守点検の出動を保守センタクライアント３００に要請する保守出動要請画面を出力するか否かを判定し、出動要請送信部２６４が、障害が発生したＡＴＭ１００の保守点検を所轄する保守センタクライアント３００に対して保守出動要請を送信することによって、担当店員の性格を加味して速やかに保守出動を要請することができる。

なお、本実施例では、本発明をＡＴＭに適用した場合を示したが、本発明はこれに限定されるものではなく、他の各種装置にも同様に適用することができる。

また、本実施例では、障害の発生間隔に基づいて保守出動要請の可否を判定する場合について説明したが、本発明はこの方法に限定されず、障害発生により停止していた状態から復旧しＡＴＭの再起動が行われてから再び障害が発生するまでの時間間隔に基づいて保守出動要請の可否を判定する場合にも同様に適用することができる。

また、本実施例では、担当店員ごとに設定された出動要請時障害発生間隔Ｔ_Mを、保守出動が要請された際の障害発生間隔の算術平均として算出したが、その算出方法は上述した方法に限定されず、障害が発生したにもかかわらず保守出動が要請されなかった場合の障害発生間隔をも考慮した値として算出してもよい。一例として、判別分析法などの統計的手法が考えられる。

また、本実施例では、障害発生間隔の平均値ΔＴaveが出動要請時障害発生間隔Ｔ_M以上である場合は、保守管理サーバ２００は保守点検が不要であると判断して重点監視の指示を促すこととしたが、これに代えて障害の緊急度が「Ｃ」よりもさらに低い緊急度「Ｄ」を対応付けて保守出動要請画面を呼び出し、保守センタクライアント３００に対してこの緊急度「Ｄ」と対応付けて保守出動要請を送信して保守点検を行わせることとしてもよい。これにより、保守点検を要するほどでもない軽微な障害に対して保守出動を要請する必要が生じた際に、その出動優先度を保守点検員に容易に判断させることができる。

また、本実施例では、障害の種別に対応する緊急度を固定的に定めたが、障害発生間隔以外の他の要因に応じてこの緊急度を可変とする構成としてもよい。

例えば、ＡＴＭが１台しか設置されていない店舗に関する情報を担当店員情報テーブル２５３にさらに対応付け、保守出動判定部２６３はそのＡＴＭで発生した障害に対しては緊急度をＡＴＭが１台しか設置されていない店舗における障害の緊急度よりも高く設定することとしてもよい。また、保守出動判定部２６３は、月末などの繁忙日に発生した障害に対しては、その緊急度を繁忙日以外に発生した障害の緊急度よりも高く設定することとしてもよい。

さらに、保守出動判定部２６３は、ＡＴＭで障害発生が検知され始めた日時と保守出動要請を受け付けた日時との時間間隔に基づいて緊急度を変更する構成としてもよい。例えば、障害発生が検知され始めてから保守出動要請を受け付けるまでの時間間隔が短いほど、担当店員にとっては切羽詰った状況であるとみなすことができるので、時間間隔が所定値よりも短い場合にはそれが所定値よりも長い場合よりも緊急度を高く設定することとしてもよい。

上述してきたように、本実施例では、障害履歴取得部２６１が、ＡＴＭ１００から送信された障害情報を障害履歴テーブル２５１に記憶させ、保守出動判定部２６３が、障害履歴取得部２６１により障害履歴テーブル２５１に記憶された障害情報に係る時間間隔に基づいてＡＴＭ１００への保守出動を要請する情報を保守センタクライアント３００に送信するか否かの判定を行うこととしたので、障害の発生頻度に適合した迅速な保守出動を可能とし、保守点検の効率化を図ることができる。

また、本実施例では、担当店員識別部２６２が、ＡＴＭ１００を管理する担当店員を識別し、保守出動判定部２６３が、時間間隔が担当店員ごとに設定される閾値未満であるときにＡＴＭ１００への保守出動を要請する情報を保守センタクライアント３００に送信することとしたので、保守出動を要請するか否かの判断基準を担当者ごとに設定することができ、担当者に合わせてフレキシブルに対応することができる。

また、本実施例では、出動要請時障害発生間隔算出部２６５が、担当店員が管理対象とするＡＴＭ１００における障害の発生間隔に基づいて閾値を決定することとしたので、担当者の性格などの要因により担当者ごとに異なる保守出動要請の判断基準を加味して保守点検を要するか否かを判定することができる。

また、本実施例では、出動要請時障害発生間隔算出部２６５が、担当店員が管理対象とするＡＴＭ１００における障害復旧から障害再発生までの時間間隔に基づいて閾値を決定することとしたので、担当者の性格などの要因により担当者ごとに異なる保守出動要請の判断基準を加味して保守点検を要するか否かを判定することができる。

また、本実施例では、担当店員識別部２６２が、ＡＴＭ１００を管理する担当店員から受け付けた保守出動依頼を履歴として出動要請履歴テーブル２５５に記憶させ、出動要請時障害発生間隔算出部２６５が、障害履歴テーブル２５１に記憶された障害情報のうち、出動要請履歴テーブル２５５に記憶された保守出動依頼に係る日時から所定の期間内に記憶された障害情報に基づいて閾値を決定することとしたので、保守出動を要請するか否かを判定する際に、担当者が出動要請を依頼する状況の傾向を反映させることができる。

また、本実施例では、保守出動判定部２６３が、障害発生開始日時と保守要求受付日時との間隔に基づいて、保守出動における緊急度を設定し、その緊急度に応じて設定された閾値と障害情報に係る時間間隔とに基づいてＡＴＭ１００への保守出動を要請する情報を保守センタクライアント３００に送信するか否かの判定を行うこととしたので、障害発生開始日時と保守要求受付日時との間隔が短く切羽詰った状況下に置かれた担当者からの保守出動の依頼に対して優先的に保守出動を行わせることができる。

また、本実施例では、保守出動判定部２６３が、代替可能な装置が存在しない設置所における装置において発生した障害に対する緊急度を代替可能な装置が存在する設置所における装置において発生した障害に対する緊急度よりも高く設定し、その緊急度に応じて設定された閾値と障害情報に係る時間間隔とに基づいてＡＴＭ１００への保守出動を要請する情報を保守センタクライアント３００に送信するか否かの判定を行うこととしたので、代替可能な装置が存在せず障害発生により業務に重大な支障をきたすような場合には優先的に保守出動を行わせることができる。

また、本実施例では、保守出動判定部２６３が、ＡＴＭ１００で発生した障害のうち繁忙期に発生した障害に対する緊急度を繁忙期以外に発生した障害に対する緊急度よりも高く設定し、その緊急度に応じて設定された閾値と障害情報に係る時間間隔とに基づいてＡＴＭ１００への保守出動を要請する情報を保守センタクライアント３００に送信するか否かの判定を行うこととしたので、繁忙日など装置の稼働率が高い時期に発生した障害に対して優先的に保守出動を行わせることができる。

ところで、上記実施例で説明した各種の処理は、あらかじめ用意されたプログラムをコンピュータで実行することによって実現することができる。そこで、以下では、図９を用いて、上記各種処理を実現するプログラムを実行するコンピュータの一例について説明する。図１０は、図１に示した保守管理サーバ２００となるコンピュータのハードウェア構成を示す図である。

このコンピュータは、ユーザからのデータの入力を受け付ける入力装置４００、ディスプレイなどの表示装置４０１、ＲＡＭ（Random Access Memory）４０２、ＲＯＭ（Read Only Memory）４０３、各種プログラムを記録した記録媒体からプログラムを読み取る媒体読み取り装置４０４、ネットワークを介して他のコンピュータとの間でデータの授受を行うネットワークインターフェース４０５、ＣＰＵ（Central Processing Unit）４０６およびＨＤＤ（Hard Disk Drive）４０７をバス４０８で接続して構成される。

そして、ＨＤＤ４０７には、保守管理サーバ２００の機能と同様の機能を発揮するプログラム、すなわち保守出動管理プログラム４０７ｂが記憶されている。なお、この保守出動管理プログラム４０７ｂについては、適宜分散して記憶することとしてもよい。

そして、ＣＰＵ４０６が、保守出動管理プログラム４０７ｂをＨＤＤ４０７から読み出して実行することにより、保守出動管理プロセス４０６ａとして機能するようになる。

この保守出動管理プロセス４０６ａは、図１に示した障害履歴取得部２６１、担当店員識別部２６２、保守出動判定部２６３、出動要請送信部２６４および出動要請時障害発生間隔算出部２６５の各機能部に対応する。

また、ＨＤＤ４０７には、各種データ４０７ａが記憶される。なお、各種データ４０７ａは、図１に示した障害履歴テーブル２５１、障害緊急度テーブル２５２、担当店員情報テーブル２５３、所轄保守センタテーブル２５４および出動要請履歴テーブル２５５に対応する。

そして、ＣＰＵ４０６は、各種データ４０７ａをＨＤＤ４０７に記憶する処理を実行するとともに、各種データ４０７ａをＨＤＤ４０７から読み出してＲＡＭ４０２に格納し、ＲＡＭ４０２に格納された各種データ４０２ａに基づいてデータ処理を実行する。

ところで、保守出動管理プログラム４０７ｂは、必ずしも最初からＨＤＤ４０７に記憶させておく必要はない。たとえば、コンピュータに挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、または、コンピュータの内外に備えられるハードディスクドライブ（ＨＤＤ）などの「固定用の物理媒体」、さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータに接続される「他のコンピュータ（またはサーバ）」などに各プログラムを記憶しておき、コンピュータがこれらから各プログラムを読み出して実行するようにしてもよい。

さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施例にて実施されてもよいものである。

また、本実施例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。

この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した保守管理サーバの各構成要素は機能概念的なものであり、必ずしも物理的に図示のように構成されていることを要しない。すなわち、保守管理サーバの分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

さらに、保守管理サーバにて行われる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

（付記１）装置で検知された障害に基づいて該装置の保守点検を管轄する保守センタ内に設けられた保守出動要請受信装置に対して該装置への保守出動を要請する情報を送信する保守出動管理プログラムであって、
コンピュータを、
前記装置から送信された障害情報を履歴として記憶する障害履歴記憶手段、
前記障害履歴記憶手段により記憶された障害情報に係る時間間隔に基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行う保守出動判定手段、
として機能させることを特徴とする保守出動管理プログラム。

（付記２）コンピュータを、前記装置を管理する担当者を識別する担当者識別手段としてさらに機能させ、前記保守出動判定手段は、前記時間間隔が前記担当者識別手段により識別された担当者ごとに設定される閾値未満であるときに前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信することを特徴とする付記１に記載の保守出動管理プログラム。

（付記３）コンピュータを、担当者が管理対象とする装置における障害の発生間隔に基づいて前記閾値を決定する閾値決定手段としてさらに機能させることを特徴とする付記２に記載の保守出動管理プログラム。

（付記４）コンピュータを、担当者が管理対象とする装置における障害復旧から障害再発生までの時間間隔に基づいて前記閾値を決定する閾値決定手段としてさらに機能させることを特徴とする付記２に記載の保守出動管理プログラム。

（付記５）コンピュータを、前記装置を管理する担当者から受け付けた保守出動依頼を履歴として記憶する保守出動依頼履歴記憶手段としてさらに機能させ、前記閾値決定手段は、前記障害履歴記憶手段により記憶された障害情報のうち、前記障害履歴記憶手段により記憶された保守出動依頼に係る日時から所定の期間内に記憶された障害情報に基づいて前記閾値を決定することを特徴とする付記３または４に記載の保守出動管理プログラム。

（付記６）コンピュータを、障害発生開始日時と保守要求受付日時との間隔に基づいて、保守出動における緊急度を設定する緊急度設定手段としてさらに機能させ、前記保守出動判定手段は、前記緊急度設定手段により設定された緊急度に応じて設定された閾値と前記障害情報に係る時間間隔とに基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行うことを特徴とする付記１〜５のいずれか一つに記載の保守出動管理プログラム。

（付記７）コンピュータを、代替可能な装置が存在しない設置所における装置において発生した障害に対する緊急度を代替可能な装置が存在する設置所における装置において発生した障害に対する緊急度よりも高く設定する緊急度設定手段としてさらに機能させ、前記保守出動判定手段は、前記緊急度設定手段により設定された緊急度に応じて設定された閾値と前記障害情報に係る時間間隔とに基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行うことを特徴とする付記１〜５のいずれか一つに記載の保守出動管理プログラム。

（付記８）コンピュータを、前記装置で発生した障害のうち繁忙期に発生した障害に対する緊急度を繁忙期以外に発生した障害に対する緊急度よりも高く設定する緊急度設定手段としてさらに機能させ、前記保守出動判定手段は、前記緊急度設定手段により設定された緊急度に応じて設定された閾値と前記障害情報に係る時間間隔とに基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行うことを特徴とする付記１〜５のいずれか一つに記載の保守出動管理プログラム。

（付記９）装置で検知された障害に基づいて該装置の保守点検を管轄する保守センタ内に設けられた保守出動要請受信装置に対して該装置への保守出動を要請する情報を送信する保守出動管理装置であって、
前記装置から送信された障害情報を履歴として記憶する障害履歴記憶手段と、
前記障害履歴記憶手段により記憶された障害情報に係る時間間隔に基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行う保守出動判定手段と、
を備えたことを特徴とする保守出動管理装置。

（付記１０）装置で検知された障害に基づいて該装置の保守点検を管轄する保守センタ内に設けられた保守出動要請受信装置に対して該装置への保守出動を要請する情報を送信する保守出動管理方法であって、
前記装置から送信された障害情報を履歴として記憶する障害履歴記憶工程と、
前記障害履歴記憶工程により記憶された障害情報に係る時間間隔に基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行う保守出動判定工程と、
を含んだことを特徴とする保守出動管理方法。

以上のように、本発明に係る保守出動管理プログラム、保守出動管理装置および保守出動管理方法は、効率的な保守点検が要求される保守出動管理システムに対して有用である。

本実施例に係る保守出動管理システムの構成を示す機能ブロック図である。 障害種別テーブル１１１の一例を示す図である。 障害履歴テーブル２５１の一例を示す図である。 障害緊急度テーブル２５２の一例を示す図である。 担当店員情報テーブル２５３の一例を示す図である。 所轄保守センタテーブル２５４の一例を示す図である。 出動要請履歴テーブル２５５の一例を示す図である。 出動要請時障害発生間隔について説明するための説明図である。 本実施例に係る保守管理サーバ２００が実行する保守出動可否判定処理の処理手順を示すフローチャートである。 図１に示した保守管理サーバ２００となるコンピュータのハードウェア構成を示す図である。

符号の説明

１ 保守出動管理システム
５０ ネットワーク
１００ ＡＴＭ
１１０ 記憶部
１１１ 障害種別テーブル
１２０ 通信Ｉ／Ｆ部
１３０ 制御部
１３１ 障害検知部
１３２ 障害情報送信部
２００ 保守管理サーバ
２１０ 操作入力部
２２０ 表示部
２３０ 電話入力部
２４０ 通信Ｉ／Ｆ部
２５０ 記憶部
２５１ 障害履歴テーブル
２５２ 障害緊急度テーブル
２５３ 担当店員情報テーブル
２５４ 所轄保守センタテーブル
２５５ 出動要請履歴テーブル
２６０ 制御部
２６１ 障害履歴取得部
２６２ 担当店員識別部
２６３ 保守出動判定部
２６４ 出動要請送信部
２６５ 出動要請時障害発生間隔算出部
３００ 保守センタクライアント

Claims (5)

1. 装置で検知された障害に基づいて該装置の保守点検を管轄する保守センタ内に設けられた保守出動要請受信装置に対して該装置への保守出動を要請する情報を送信する保守出動管理プログラムであって、
   コンピュータを、
   前記装置から送信された障害情報を履歴として記憶する障害履歴記憶手段、
   前記障害履歴記憶手段により記憶された障害情報に係る時間間隔に基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行う保守出動判定手段、
   として機能させることを特徴とする保守出動管理プログラム。
2. コンピュータを、前記装置を管理する担当者を識別する担当者識別手段としてさらに機能させ、前記保守出動判定手段は、前記時間間隔が前記担当者識別手段により識別された担当者ごとに設定される閾値未満であるときに前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信することを特徴とする請求項１に記載の保守出動管理プログラム。
3. コンピュータを、担当者が管理対象とする装置における障害の発生間隔に基づいて前記閾値を決定する閾値決定手段としてさらに機能させることを特徴とする請求項２に記載の保守出動管理プログラム。
4. 装置で検知された障害に基づいて該装置の保守点検を管轄する保守センタ内に設けられた保守出動要請受信装置に対して該装置への保守出動を要請する情報を送信する保守出動管理装置であって、
   前記装置から送信された障害情報を履歴として記憶する障害履歴記憶手段と、
   前記障害履歴記憶手段により記憶された障害情報に係る時間間隔に基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行う保守出動判定手段と、
   を備えたことを特徴とする保守出動管理装置。
5. 装置で検知された障害に基づいて該装置の保守点検を管轄する保守センタ内に設けられた保守出動要請受信装置に対して該装置への保守出動を要請する情報を送信する保守出動管理方法であって、
   前記装置から送信された障害情報を履歴として記憶する障害履歴記憶工程と、
   前記障害履歴記憶工程により記憶された障害情報に係る時間間隔に基づいて前記装置への保守出動を要請する情報を前記保守出動要請受信装置に送信するか否かの判定を行う保守出動判定工程と、
   を含んだことを特徴とする保守出動管理方法。

Images