JP6357938B2 - 機器管理装置、機器管理システム、情報処理方法、及びプログラム - Google Patents

Description

本発明は、機器管理装置、機器管理システム、情報処理方法、及びプログラムに関する。

複合機、複写機、スキャナ、プリンタ、又はファクシミリ等に代表される画像形成装置等の機器ベンダと、顧客との間で、機器の正常稼動を保証するためのＳＬＡ（Service Level Agreement）が締結される場合が有る。ＳＬＡにおいては、例えば、稼働率を指標として、機器の稼働状況に関する保証内容が定義される。

ＳＬＡを履行の確認には、ネットワークを介して機器の稼働状況を遠隔監視するシステム（以下、「機器管理システム」という。）を利用することが考えられる。すなわち、機器管理システムでは、機器の状態の変化の履歴が管理されている。このような履歴を用いれば、所定期間における機器の稼働状況を把握することができ、ＳＬＡが履行されているか否かを示すレポートを得ることができる。

しかしながら、上記のようなレポートがＳＬＡの不履行を示すものである場合、レポートを入手した時点では、ＳＬＡの不履行が確定してしまっている可能性もある。

本発明は、上記の点に鑑みてなされたものであって、機器の稼働状況を適切な状況に維持できる可能性を高めることを目的とする。

そこで上記課題を解決するため、機器管理装置は、機器の状態の変化を示す状態情報を受信し、前記状態情報を状態情報記憶部に記憶する受信部と、前記受信部によって受信された状態情報が通知対象に該当する場合に、当該状態情報に関する通知情報を所定の宛先に送信する送信部と、前記状態情報記憶部に記憶された状態情報の履歴に基づいて特定される前記機器の稼働状況が、現時点において予定される状況を満たさない場合に、前記通知対象を拡大する変更部と、を有する。

機器の稼働状況を適切な状況に維持できる可能性を高めることができる。

本発明の実施の形態における機器管理システムの構成例を示す図である。 本発明の実施の形態における機器管理装置のハードウェア構成例を示す図である。 本発明の実施の形態における機器管理装置の機能構成例を示す図である。 コールの受信時に機器管理装置が実行する処理手順の一例を説明するためのフローチャートである。 コールの一例を示す図である。 コール仕様記憶部の構成例を示す図である。 コール履歴記憶部の構成例を示す図である。 ポイント係数記憶部の構成例を示す図である。 契約情報記憶部の構成例を示す図である。 通知対象とするコールの範囲の変更処理の処理手順の一例を説明するためのフローチャートである。 実績ポイントと予定ポイントとの算出結果の一例を示す図である。 保守コスト記憶部の構成例を示す図である。 予測コール数を算出するためのコールの履歴の集計例を示す図である。 課金額記憶部の構成例を示す図である。 本発明の実施の形態における機器管理システムの第二の構成例を示す図である。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における機器管理システムの構成例を示す図である。図１において、機器管理システム１は、機器管理装置１０と、１以上の機器２０とを含む。各機器２０と機器管理装置１０とは、ＬＡＮ（Local Area Network）又はインターネット等のネットワークを介して通信可能に接続される。

機器２０は、例えば、複合機又はプリンタ等の画像形成装置である。プロジェクタ（画像投影装置）、電子黒板、デジタルカメラ、又はテレビ会議システム等が、機器２０であってもよい。

機器管理装置１０は、各機器２０から状態の変化を示す情報を受信し、受信された情報に基づいて、機器２０の保守サービスを提供する事業者（以下、「保守サービス提供者」という。）による、ＳＬＡ（Service Level Agreement）の履行を支援するコンピュータである。ＳＬＡとは、機器２０のユーザと保守サービス提供者との間で締結される、保守サービスの品質等に関する契約をいう。したがって、保守サービス提供者にとって、機器２０のユーザは、顧客である。なお、機器管理装置１０は、機器２０のユーザ側（顧客側）のシステム環境に設置されてもよいし、保守サービス提供者側のシステム環境に設置されてもよい。また、本実施の形態では、便宜上、１つの顧客について説明するが、複数の顧客に対応する場合は、以下に説明される処理が、顧客ごとに実行されてもよい。

図２は、本発明の実施の形態における機器管理装置のハードウェア構成例を示す図である。図２の機器管理装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

機器管理装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って機器管理装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

なお、機器管理装置１０は、図２に示されるハードウェアを有する複数のコンピュータを含むコンピュータシステムであってもよい。

図３は、本発明の実施の形態における機器管理装置の機能構成例を示す図である。図３において、機器管理装置１０は、コール受信部１１、コール通知部１２、ポイント算出部１３、稼働状況判定部１４、コスト予測部１５、及び通知対象変更部１６等を有する。これら各部は、機器管理装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。機器管理装置１０は、また、コール仕様記憶部１２１、コール履歴記憶部１２２、ポイント係数記憶部１２３、契約情報記憶部１２４、保守コスト記憶部１２５、及び課金額記憶部１２６等を利用する。これら各記憶部は、補助記憶装置１０２、又は機器管理装置１０にネットワークを介して接続される記憶装置等を用いて実現可能である。

コール受信部１１は、各機器２０からコールを受信する。コールとは、機器２０の状態の変化を示す情報の一例である。機器２０の状態の変化の一例として、機器２０における異常の発生や、異常の解消等が挙げられる。ここでいう異常とは、機器２０の故障等に起因するものに限られない。例えば、トナー等の消耗品の消耗又は枯渇も異常に含まれる。コール受信部１１は、受信されたコールに関する情報をコール履歴記憶部１２２に記憶する。したがって、コール履歴記憶部１２２には、コールの履歴が記憶される。

コール通知部１２は、コール受信部１１によって受信されたコールのうち、通知対象に該当するコールの発生をサービスマンに通知するための処理を実行する。すなわち、コール通知部１２は、必ずしも全てのコールをサービスマンに通知するとは限らない。コールの通知は、例えば、所定の宛先に対してコールの発生を示す情報を送信することによって行われる。所定の宛先は、例えば、サービスマンのメールアドレスである。サービスマンとは、保守サービス提供者において、本実施の形態における各機器２０の保守作業を担当する個人をいう。

受信されたコールが通知対象に該当するか否かは、受信されたコールに含まれる情報を、コール仕様記憶部１２１に記憶された情報に当てはめることにより判定される。コール仕様記憶部１２１は、コールに関する仕様を示す情報を記憶する。コールに関する仕様を示す情報には、コールの分類を示す情報や、分類ごとの属性情報等が含まれる。

ポイント算出部１３は、コールによって検知された異常によって顧客に与える不利益の程度を数値化する。本実施の形態において、不利益の程度が数値化された値を「ポイント」という。例えば、ポイントは、異常の種別や、異常の発生から解消までの経過時間等に基づいて、ポイント係数記憶部１２３に記憶された係数及び契約情報記憶部１２４に記憶された情報等を利用して算出される。

ポイント係数記憶部１２３は、コールの種別ごとに、単位時間あたりのポイントを記憶する。契約情報記憶部１２４は、ＳＬＡにおいて定められた事項のうち、機器管理装置１０が実行する処理に必要な事項に関する情報を記憶する。保守コスト記憶部１２５は、保守作業（復旧作業）によって生じたコスト（以下、「保守コスト」という。）を記憶する。

なお、コール受信部１１、コール通知部１２、及びポイント算出部１３は、コール受信部１１によるコールの受信に応じて、同期的に処理を実行する。一方、稼働状況判定部１４、コスト予測部１５、及び通知対象変更部１６は、コールの受信とは非同期に処理を実行する。

稼働状況判定部１４は、コール履歴記憶部１２２に記憶されたコールの履歴に基づいて、機器２０の稼働状況が、ＳＬＡを履行するために予定される状況（許容される状況）を満たしているか否かを判定する。すなわち、コールの履歴は、機器２０における異常の発生や、当該異常の解消の履歴を示す情報である。斯かる情報によれば、機器２０の稼働状況を把握することができる。

コスト予測部１５は、機器２０の稼働状況がＳＬＡを履行するために予定される状況を満たしていないと判定される場合に、通知対象とするコールの範囲を拡大することによって生じるコストを予測する。ここでいうコストとは、サービスマンにコールが通知されることによって発生するコストをいう。すなわち、サービスマンは、異常の発生を示すコールが通知されると、客先に赴いて当該異常を解消するための作業（保守作業）を行う。コストは、斯かる保守作業によって発生する人件費等である。

通知対象変更部１６は、コスト予測部１５によって予測されるコストが、所定の条件を満たす場合に、通知対象とするコールの範囲を拡大する。通知対象とするコールの範囲の拡大は、保守サービスの質の向上につながる。すなわち、通知対象とするコールの範囲を拡大することによって、軽微な異常や、異常の予兆を示すコールに関する情報もサービスマンに通知されるようになる。したがって、サービスマンは、重大な異常が発生する前に、顧客先に赴き、機器２０の保守作業を行うことができる。その結果、ＳＬＡが履行される可能性を高めることができる。なお、所定の条件とは、例えば、コスト予測部１５によって予測されるコストが、保守サービスに対する課金額から利益分を差し引いた金額以内であることである。保守サービスに対する課金額とは、例えば、ＳＬＡ等において所定期間に関して顧客との間で定められた、課金額をいう。斯かる課金額は、課金額記憶部１２６に記憶されている。通知対象とするコールの範囲の拡大されるケースが、所定の条件が満たされる場合に限定されることにより、保守サービス質の向上が過剰となることを回避することができる。すなわち、保守サービス質の向上の程度が、保守サービス提供者に損失が生じない程度に抑制することができる。

以下、機器管理装置１０が実行する処理手順について説明する。図４は、コールの受信時に機器管理装置が実行する処理手順の一例を説明するためのフローチャートである。

コール受信部１１は、機器２０から送信されるコールの受信を待機している（Ｓ１０１）。又は、コール受信部１１が、機器２０に対してコールの有無を問い合わせてもよい。コール受信部１１は、コールを受信すると（Ｓ１０１でＹｅｓ）、当該コールが、異常発生を示すコールであるのか、又は異常の解消を示すコール（以下、「解消コール」という。）であるのかを判定する（Ｓ１０２）。

図５は、コールの一例を示す図である。図５では、コールｃ１が、ＸＭＬ（eXtensible Markup Language）形式のデータである例が示されている。但し、コールのデータ形式は、所定のものに限定されない。

コールｃ１は、ＤｅｖｉｃｅＩｄ要素ｅ１、ＣａｌｌＩｄ要素ｅ２、ＣａｌｌＴｙｐｅ要素ｅ３、及びＣａｌｌＤｅｔａｉｌ要素ｅ４等を含む。ＤｅｖｉｃｅＩｄ要素ｅ１の値は、コールｃ１の送信元の機器２０の機器ＩＤを示す。すなわち、ＤｅｖｉｃｅＩｄ要素ｅ１の値は、コールｃ１が示す状態の変化が発生した機器２０の機器ＩＤである。機器ＩＤとは、機器２０の機体ごとの識別情報である。ＣａｌｌＩｄ要素ｅ２の値は、コールごとの識別情報（以下、「コールＩＤ」という。）を示す。ＣａｌｌＴｙｐｅ要素ｅ３の値は、コール種別を示す。本実施の形態において、コール種別は、コールを分類する最上位の概念である。ＣａｌｌＤｅｔａｉｌ要素ｅ４の値は、コールの意味を詳細に示す情報である。

コールｃ１が異常の発生を示すコールであるか、又は異常の解消を示すコールであるかは、コール仕様記憶部１２１を参照することにより判定可能である。

図６は、コール仕様記憶部の構成例を示す図である。図６において、コール仕様記憶部１２１は、コール種別名、コール名、ＣａｌｌＴｙｐｅ、ＣａｌｌＤｅｔａｉｌ、及び通知グループ等の項目を有する。

コール種別名は、コール種別の名前である。本実施の形態において、異常の発生を示すコールは、アラームコール、サービスコール、及びサプライコールのいずれかに大別される、なお、異常の解消を示すコール種別（以下、「解消コール」という。）については、便宜上、図６では省略されている。アラームコールは、軽微な異常の発生又は異常の予兆の発生等、サービスマンによる迅速な保守作業が必ずしも必要ではない異常を示すコールである。但し、アラームコールに応じて保守作業が行われることで、サービスコールやサプライコール等の発生等を未然に防止できる可能性を高めることができる。

サービスコールは、サービスマンによる迅速な保守作業が行われる必要のある又は行われることが望ましい異常の発生を示すコールである。サプライコールは、トナー、ステープル、及びカートリッジ等、消耗品（サプライ）の一定以上の消耗又は枯渇を示すコールである。サプライが一定以上消耗した場合又は枯渇した場合、機器２０の正常な稼動に支障をきたす可能性が高い。したがって、サプライコールについても、サービスマンによる迅速な作業が行われる必要のある又は行われることが望ましい状態を示すコールであるといえる。

コール名は、上記した通りである。ＣａｌｌＴｙｐｅは、コールｃ１に含まれるＣａｌｌＴｙｐｅ要素ｅ３に対応する項目である。ＣａｌｌＤｅｔａｉｌは、コールｃ１に含まれるＣａｌｌＤｅｔａｉｌ要素ｅ４に対応する項目である。グループ番号は、通知対象であるか否かを１以上のコール名を含むグループ（以下、「コールグループ」という。）ごとに区別可能とするための項目である。具体的には、本実施の形態では、グループ番号の値が、通知対象番号α以下であるコールが、通知対象とされる。通知対象番号αとは、通知対象とするゴールグループを区別するための変動的な閾値であり、通知対象変更部１６によって設定される。コールグループは、例えば、コールの発生頻度に基づいて分類されてもよい。例えば、図６の例では、グループ番号の値は、サプライコール、サービスコール、アラームコールの順に大きくなっている。このことは、サプライコールの発生頻度が最も低く、アラームコールの発生頻度が最も高いことを示す。但し、コール種別と発生頻度とは必ずしも対応付かなくてもよい。例えば、アラームコールに属するコールであっても、サプライコールに属するコールよりも発生頻度が高くなるコールがあってもよい。また、図６では、コール種別とグループ番号とは１対１に対応しているが、一つのコールグループは、相互に異なるコール種別に属するコール群によって形成されてもよい。また、通知対象とするコールを、コール名ごとに区別したい場合は、コール名ごとに異なるグループ番号が割り当てられてもよい。

上記より、ステップＳ１０２では、受信されたコールのＣａｌｌＴｙｐｅ要素ｅ３の値が、アラームコールを示す１、サービスコールを示す２、又はサプライコールを示す４であれば、当該コールは異常の発生を示すコールであると判定される。

受信されたコールが異常の発生を示すコールである場合（Ｓ１０２でＹｅｓ）、コール受信部１１は、当該コールに関する情報を記憶するための新たなレコードを、コール履歴記憶部１２２に生成する（Ｓ１０３）。続いて、コール受信部１１は、受信されたコールに関する情報を、新たに生成されたレコードに記憶する（Ｓ１０４）。

図７は、コール履歴記憶部の構成例を示す図である。図７において、コール履歴記憶部１２２は、いずれかの機器２０において発生した、異常の発生を示すコールごとに、機器ＩＤ、コール種別名、コールＩＤ、発生日時、解消日時、復旧時間、及び発生ポイント等を記憶する。

機器ＩＤは、コールが発生した機器２０の機器ＩＤである。コール種別名は、発生したコールのコール種別の名前である。コールＩＤは、発生したコールのコールＩＤである。発生日時は、コールが発生した日時である。解消日時は、コールが解消した日時である。復旧時間は、発生日時から解消日時までの経過時間である。発生ポイントは、コールに基づいて発生したポイントである。

Ｓ１０４では、ステップＳ１０３において生成されたレコードの機器ＩＤ、コール種別名、コールＩＤ、発生日時に値が記憶される。すなわち、機器ＩＤには、受信されたコールのＤｅｖｉｃｅＩｄ要素ｅ１の値が記憶される。コール種別名には、受信されたコールに含まれるＣａｌｌＴｙｐｅ要素ｅ３の値及びＣａｌｌＤｅｔａｉｌ要素ｅ４の値を、コール仕様記憶部１２１のＣａｌｌＴｙｐｅの項目及びＣａｌｌＤｅｔａｉｌ項目の値に当てはめることにより特定されるレコードのコール種別名が記憶される。コールＩＤには、当該コールのＣａｌｌＩｄ要素ｅ２の値が記憶される。発生日時には、当該コールの受信日時が記憶される。

続いて、コール通知部１２は、受信されたコールのグループ番号が、通知対象番号α以下であるか否かを判定する（Ｓ１０５）。当該コールのグループ番号は、当該コールに含まれるＣａｌｌＴｙｐｅ要素ｅ３の値及びＣａｌｌＤｅｔａｉｌ要素ｅ４の値を、コール仕様記憶部１２１のＣａｌｌＴｙｐｅの項目及びＣａｌｌＤｅｔａｉｌ項目の値に当てはめることにより特定されるレコードのグループ番号である。例えば、図５に示したコールｃ１のグループ番号は、２である。また、本実施の形態において、通知対象番号αの初期値は１であるとする。したがって、コールｃ１に関しては、グループ番号が通知対象番号α以下ではないと判定される。

グループ番号が通知対象番号α以下である場合（Ｓ１０５でＹｅｓ）、コール通知部１２は、受信されたコールに関する情報を、所定の宛先に送信する（Ｓ１０６）。例えば、当該コールがそのまま所定の宛先に転送されてもよい。その結果、当該宛先に係るサービスマンに当該コールが通知される。当該サービスマンは、当該コールの通知に応じ、当該コールに含まれる機器ＩＤに係る機器２０が設置されている客先に赴き、保守作業等を行う。なお、所定の宛先は、例えば、機器ＩＤ等に関連付けられて、補助記憶装置１０２等に予め記憶されていてもよい。

保守作業によって異常が解消されると、機器２０は、当該異常の解消を示す解消コールを機器管理装置１０に送信する。解消コールは、機器２０が自動的に送信してもよいし、サービスマンの操作に応じて機器２０が送信してもよい。解消コールの構成は、図５に示したものと同様でよい。例えば、解消コールのＣａｌｌＩｄ要素ｅ２には、解消された異常に係るコールのコールＩＤが含まれる。また、ＣａｌｌＴｙｐｅ要素ｅ３及びＣａｌｌＤｅｔａｉｌ要素ｅ４には、解消コールであることを示す値が含まれる。

斯かる解消コールがステップＳ１０１で受信されると（Ｓ１０２でＮｏ）、コール受信部１１は、当該解消コールに対応するレコード（以下、「対応レコード」という。）をコール履歴記憶部１２２から検索する（Ｓ１０７）。対応レコードは、当該解消コールが含む機器ＩＤ及びコールＩＤの値に一致する機器ＩＤ及びコールＩＤを含むレコードである。

続いて、コール受信部１１は、対応レコードの解消日時に、当該解消コールが受信された日時を記憶する（Ｓ１０８）。続いて、ポイント算出部１３は、当該レコードに関する復旧時間を算出する（Ｓ１０９）。すなわち、ポイント算出部１３は、当該レコードの発生日時から解消日時までの経過時間（分）を算出する。

続いて、ポイント算出部１３は、ポイント係数記憶部１２３及び契約情報記憶部１２４等を参照して、当該レコードに関する発生ポイント（すなわち、当該レコードに係る異常よって顧客に与えた不利益を示すポイント）を算出する（Ｓ１１０）。

図８は、ポイント係数記憶部の構成例を示す図である。図８において、ポイント係数記憶部１２３は、コール種別名に対応づけて、ポイント係数を記憶する。図８に示されるポイント係数の値は、対応するコール種別名に係るコールの重要度又は深刻度に応じて大きくなるように設定されている。

発生ポイントは、斯かるポイント係数を次の式（１）に当てはめることにより算出される。

発生ポイント＝ポイント係数×復旧時間 ・・・（１）
なお、ポイント係数の値やポイントの算出式等は、例えば、ＳＬＡにおいて顧客ごとに定められてもよい。

また、契約情報記憶部１２４においてポイントの算出に関して追加条件が記憶されている場合、当該追加条件も適用されて、発生ポイントが算出されてもよい。

図９は、契約情報記憶部の構成例を示す図である。図９において、契約情報記憶部１２４の各レコードは、評価項目、サービス条件、サービスレベル、及び追加条件等の項目を含む。

評価項目は、保守サービスに関するＳＬＡの履行に関して評価される項目である。サービス条件は、後述のサービスレベルに対して基準となる値である。サービスレベルは、各評価項目に関して、サービス条件に対して顧客が要求する程度、又は顧客が許容する程度を示す。追加条件は、各評価項目のサービスレベルに対して追加的に付加される条件である。

例えば、１番目のレコードは、毎日２４時間稼動を基準とする９５％の可用性が要求されることを示す。２番目のレコードは、復旧時間に関して、基本的には１０分以内とし、１ヶ月あたりの発生ポイントが１００００ポイント以下であることが要求されることを示す。３番目のレコードは、重大な障害の発生件数が、１ヶ月あたり２件以内であることが要求されることを示す。すなわち、本実施の形態では、１ヶ月ごとにＳＬＡの履行の有無が評価される。

契約情報記憶部１２４に記憶される情報は、顧客とのＳＬＡに基づいて設定される。したがって、評価項目の種類や、サービス条件及びサービスレベルの値は、顧客ごとに異なってもよい。なお、保守サービスに対する課金額は、ＳＬＡの内容に応じて定められてもよい。すなわち、厳しい条件が要求される程、課金額が高く設定されてもよい。

図９において、ステップＳ１１０における発生ポイントの算出に関係する項目は、２番目のレコードの追加条件である。すなわち、復旧時間が１０分を超える場合、式（１）の代わりに、以下の式（２）が適用されて発生ポイントが算出される。

発生ポイント＝ポイント係数×復旧時間×２ ・・・（２）
なお、１０分を超えた分に関してのみ、ポイントが２倍とされてもよい。この場合、復旧時間が１０分を超える場合、以下の式（３）が適用されてもよい。

発生ポイント＝ポイント係数×１０＋（復旧時間−１０）×２ ・・・（３）
式（２）及び式（３）のいずれが適用されるかについても、ＳＬＡにおいて定めされてもよい。なお、図７では、式（２）が適用されて発生ポイントが算出された例が示されている。

続いて、ポイント算出部１３は、ステップＳ１０９において算出された復旧時間とステップＳ１１０において算出された発生ポイントとを、ステップＳ１０７において対応レコードに記憶する（Ｓ１１１）。

図４を用いて説明したように、いずれかの機器２０において異常が発生又は異常が解消すると、当該異常の発生又は解消を示すコールが機器管理装置１０において受信され、コール履歴記憶部１２２に記憶される。したがって、コール履歴記憶部１２２には、各機器２０の稼働状況を示す情報が記憶される。例えば、コール履歴記憶部１２２に記憶される発生ポイントは、直接的には顧客に与えた不利益の程度を示す値であるが、斯かる不利益は、機器２０が正常に稼動していないことにより生じるものである。したがって、発生ポイントは、裏返せば、機器２０の稼働状況を示す値であるともいえる。

続いて、月末になってＳＬＡの不履行が確定してしまう前に、ＳＬＡの不履行の可能性を検知し、当該不履行の可能性を低下させるために機器管理装置１０が実行する処理について説明する。本実施の形態では、ポイントの発生状況又は発生の推移に応じて、通知対象番号αを変更する（すなわち、通知対象とするコールの範囲を変更する）ことにより、ＳＬＡの不履行の可能性の低下が図られる。

図１０は、通知対象とするコールの範囲の変更処理の処理手順の一例を説明するためのフローチャートである。

稼働状況判定部１４は、通知対象番号αの見直し時期の到来を待機している（Ｓ２０１）。例えば、通知対象番号αの見直し時期は、１時間おき等、定期的に到来する。通知対象番号αの見直し時期が到来すると（Ｓ２０１でＹｅｓ）、稼働状況判定部１４は、当月の現時点までの発生ポイントを算出する（Ｓ２０２）。具体的には、稼働状況判定部１４は、コール履歴記憶部１２２から、解消日時が当月に属するレコード群を抽出する。稼働状況判定部１４は、抽出されたレコード群のそれぞれの発生ポイントを合算することで、当月の現時点までの発生ポイントを算出する。以下、算出されたポイントを「実績ポイント」という。なお、当月とは、今回の見直し時期が属する月をいう。

続いて、稼働状況判定部１４は、当月の当日までの予定ポイントを算出する（Ｓ２０３）。当日までの予定ポイントとは、ＳＬＡを履行するために、当日の時点で予定される又は許容されるポイントをいう。

本実施の形態では、過去における同月のコールの履歴に基づいて予定ポイントが算出される。具体的には、当日が、２０１４年７月１８日であるとする。この場合、例えば、２０１４年より前の７月の中で、ＳＬＡを履行できた７月のコールの履歴に基づいて予定ポイントが算出されてもよい。ここでは、１ヶ月あたりの発生ポイントが１００００ポイント以下である月が、ＳＬＡを履行できた月であるとする。例えば、２０１２年の７月において、ＳＬＡが履行された場合、稼働状況判定部１４は、コール履歴記憶部１２２から、解消日時が２０１２年７月に属するレコード群を抽出する。稼動状況判定部は、抽出されたレコード群の発生ポイントを各日について集計する。その結果、予定ポイントの推移が得られる。又は、過去の数年間の各７月の毎日の発生ポイントの平均値が、予定ポイントとして算出されてもよい。また、予定ポイントの月末時点の合計が１００００ポイントに満たない場合や、１００００ポイントを超える場合は、合計が１００００ポイントになるように、各日の予定ポイントが正規化されてもよい。また、他の統計的手法等によって、予定ポイントが算出されてもよい。

ステップＳ２０２及びＳ２０３の実行により、図１１に示されるような情報が得られる。

図１１は、実績ポイントと予定ポイントとの算出結果の一例を示す図である。図１１では、テーブル形式と、グラフ形式とによって、実績ポイントと予定ポイントとの算出結果の一例が示されている。なお、図１１の例では、予定ポイントの１ヶ月分の合計は、９０００ポイントとなっている。このような場合、当該合計が９０００ポイントとなるように、各日の予定ポイントが正規化されてもよい。また、図１１において、当日は、１８日である。したがって、実績ポイントについては、１８日までの値が算出されている。なお、各日の予定ポイントは、１００００ポイントを当月の日数で除することにより算出されてもよい。但し、実際のポイントの発生状況は、必ずしも均一ではなく、顧客による機器２０の利用状況に応じて推移する傾向に有る。例えば、月末において利用頻度が高い場合、月末において発生ポイントが高くなる傾向にある。また、ポイントの発生状況は、月ごとにも異なる可能性が有る。例えば、期末の月は、機器２０の発生頻度が高くなり、ポイントの発生ポイントも高くなる可能性が有る。したがって、過去の同月のコールの履歴に基づいて予定ポイントが算出されることにより、顧客による機器２０の利用状況に即した予定ポイントが求められる可能性を高めることができる。

続いて、稼働状況判定部１４は、当月の現時点までの実績ポイントと、当月の当日までの予定ポイントとを比較する（Ｓ２０４）。図１１の例において、当該実績ポイントは、３９６０であり、当該予定ポイントは、３０５０である。

図１１の例に示されるように、実績ポイントが予定ポイントを上回っている場合（Ｓ２０４でＹｅｓ）、月末時点での発生ポイントの合計が、１００００ポイントを超えてしまう可能性が高い。そこで、ステップＳ２０５以降の処理が実行される。

ステップＳ２０５において、コスト予測部１５は、当月の現時点までに既に発生している保守コストを保守コスト記憶部１２５を参照して算出する。

図１２は、保守コスト記憶部の構成例を示す図である。図１２において、保守コスト記憶部１２５は、実際に行われた保守作業ごとに、開始日時、終了日時、機器ＩＤ、及び保守コスト等を記憶する。開始日時は、保守作業の開始日時である。終了日時は、保守作業の終了日時である。機器ＩＤは、保守作業の対象とされた機器２０の機器ＩＤである。保守コストは、保守作業によって発生したコスト（人件費）である。

ステップＳ２０５では、保守コスト記憶部１２５において、終了日時が当月に属するレコード群の保守コストが合算されることにより、当月の現時点までの保守コストが算出される。

続いて、コスト予測部１５は、２を底とする現在の通知対象番号αの対数に１を加算した値を、変数ｄに代入する（Ｓ２０６）。すなわち、（ｌｏｇ_２（通知対象番号α）＋１）の算出結果が、変数ｄに代入される。本実施の形態において、通知対象番号αと比較されるグループ番号は、２のべき乗である。ｌｏｇ_２（通知対象番号α）によって、現在の通知対象番号αが、２の何乗であるかが算出される。その算出結果に１が加算されることにより、現在の通知対象番号αより大きい最小のグループ番号が、２の何乗であるかが求められる。例えば、現在の通知対象番号αが１である場合、変数ｄには１が代入される。

続いて、コスト予測部１５は、以下の算出結果の整数値（整数部分）を、変数Ｎに代入する（Ｓ２０７）。

（（実績ポイント−予定ポイント）／予定ポイント）×１０
すなわち、実績ポイントと予定ポイントとの差分の予定ポイントに対する割合に１０を乗じた値の整数値が、変数Ｎに代入される。例えば、実績ポイントと予定ポイントとの差分の予定ポイントに対する割合が３０％である場合、Ｎの値は３となる。変数Ｎは、ステップＳ２０９以降におけるループの回数の上限を決める変数である。変数Ｎの値が、このような演算によって求められるは、実績ポイントと予定ポイントとの差分が大きいほど、ステップＳ２０９以降のループ回数を多くするためである。当該ループでは、段階的に、通知対象番号αの値が増加される。したがって、Ｎの値が大きい程、すなわち、実績ポイントと予定ポイントとの差分が大きい程、通知対象番号αの値の増加幅を大きくすることができる。

続いて、コスト予測部１５は、変数ｉに０を代入する（Ｓ２０８）。変数ｉは、ステップＳ２０９以降のループの回数をカウントするための変数である。

続いて、コスト予測部１５は、変数ｉの値が変数Ｎの値未満であり、かつ、２^ｄ（２のｄ乗）が、グループ番号の最大値以下であるか否かを判定する（Ｓ２０９）。変数ｉの値が変数Ｎの値未満という条件は、ループ回数をＮ回以下にするためのものである。２^ｄが、グループ番号の最大値以下であるという条件は、通知対象番号αが最大値に達しているのにも拘わらず、通知対象番号αの増加を試みるといった無駄な処理の発生を回避するためのものである。

これらの条件が満たされる場合（Ｓ２０９でＹｅｓ）、コスト予測部１５は、コール履歴記憶部１２２を参照して、当月の月末までに発生すると予測される、グループ番号が２^ｄ以下であるコールの数（以下、「予測コール数」という。）を算出する（Ｓ２１０）。

予測コール数は、例えば、予定ポイントの算出に利用したコールの履歴（コール履歴記憶部１２２のレコード群）を、図１３に示されるように集計することにより求められてもよい。

図１３は、予測コール数を算出するためのコールの履歴の集計例を示す図である。図１３には、２０１２年の７月のコールの履歴に基づいて、各日のサービスコール数、サプライコール数、及びアラームコール数が集計された結果が示されている。なお、予定ポイントと同様に、７月の各日のサービスコール数、サプライコール数、及びアラームコール数について、過去の複数年の平均値が算出されてもよい。

コスト予測部１５は、図１３に示される集計結果の７月１９日から７月３１日までのレコードについて、グループ番号が２^ｄ以下であるコール種別のコール数を集計する。例えば、変数ｄの値が１である場合、グループ番号が２以下である、サービスコール及びサプライコールのコール数が集計される。集計結果は、コール種別が区別されなくてよい。例えば、サービスコールの集計結果と、サプライコールの集計結果とが合算されてもよい。したがって、一つの数値が、集計結果として導出される。当該数値が、予測コール数である。

続いて、コスト予測部１５は、ステップＳ２０５において算出された、当月の現時点までの保守コストの実績値に、予測コール数×単価を加算した値を、当月の保守コストの予測値（以下、「当月予測コスト」という。）として算出する（Ｓ２１２）。単価とは、例えば、サービスマンの１回あたりの派遣によって生じる最低の人件費である。予測コール数×単価は、通知対象番号αを２^ｄに変更した場合の、当日の翌日以降から月末までに発生するコストの予測値である。

続いて、コスト予測部１５は、ＳＬＡ等によって予め定められている当月の課金額から当月予測コストを差し引いた値が、β以上であるか否かを判定する（Ｓ２１２）。βは、例えば、確保すべき利益の値である。また、当月の課金額は、課金額記憶部１２６に記憶されている。

図１４は、課金額記憶部の構成例を示す図である。図１４において課金額記憶部１２６は、月ごとに、標準課金額を記憶する。標準課金額とは、ＳＬＡが履行された場合の課金額をいう。ＳＬＡの不履行が発生した場合、例えば、不履行の程度に応じて、標準課金額から減額された金額が、課金される。標準課金額及びＳＬＡの不履行の場合の減額の程度等に関しては、ＳＬＡ等において予め定められてもよい。なお、標準課金額が月ごとに設定されるのは、月ごとに機器２０の利用状況が異なる場合が考慮されているためである。例えば、３月は、機器２０の利用頻度が高まるため、標準課金額が高く設定されている。

当月の標準課金額から当月予測コストを差し引いた値が、β以上である場合（Ｓ２１２でＹｅｓ）、通知対象変更部１６は、通知対象番号αに、２^ｄを代入する（Ｓ２１３）。その結果、通知対象となるコールの範囲が拡大される。図４のステップＳ１０５において、グループ番号が通知対象番号α以下であると判定されるコールの数が増加するからである。

続いて、コスト予測部１５は、変数ｉと変数ｄとのそれぞれに１を加算して（Ｓ２１４）、ステップＳ２０９以降を繰り返す。すなわち、通知対象とするコールの範囲を更に拡大しても、コストに見合う場合には、通知対象番号αが更に大きくされる。

一方、当月の標準課金額から当月予測コストを差し引いた値が、β未満である場合（Ｓ２１２でＮｏ）、図１０の処理は終了する。通知対象番号αが、２ｄまで増加すると、コストに見合わなくなるからである。また、変数ｉがＮ以上となった場合、又は２^ｄが、グループ番号の最大値を超える場合（Ｓ２０９でＮｏ）、図１０の処理は終了する。

一方、ステップＳ２０４において、実績ポイントが予定ポイント以下である場合（Ｓ２０４でＮｏ）、通知対象変更部１６は、実績ポイントが予定ポイントよりも小さいか否かを判定する（Ｓ２１５）。実績ポイントと予定ポイントとが等しい場合（Ｓ２１５でＮｏ）、図１０の処理は終了する。この場合、ポイントの発生状況は予定通りであるからである。但し、換言すれば、この場合は、ポイントの発生状況がボーダーライン上にあるともいえる。したがって、実績ポイントと予定ポイントとが等しい場合も、ステップＳ２０５以降が実行されてもよい。

実績ポイントが予定ポイントよりも小さい場合（Ｓ２１５でＹｅｓ）、通知対象変更部１６は、ステップＳ２１６以降において、通知対象番号αを小さくするための処理を実行する。ＳＬＡの履行に余裕が有るため、サービスマンの派遣回数を減らして、保守コストを低下させるためである。

ステップＳ２１６において、通知対象変更部１６は、２を底とする現在の通知対象番号αの対数から１を減算した値を、変数ｄに代入する（Ｓ２１６）。すなわち、（ｌｏｇ_２（通知対象番号α）−１）の算出結果が、変数ｄに代入される。例えば、現在の通知対象番号αが４である場合、変数ｄには１が代入される。

続いて、コスト予測部１５は、以下の算出結果の整数値（整数部分）を、変数Ｎに代入する（Ｓ２１７）。

（予定ポイント−実績ポイント）／予定ポイント）×１０
当該演算式は、予定ポイントから実績ポイントが差し引かれる点が、ステップＳ２０７における演算式と異なる。

続いて、通知対象変更部１６は、変数ｉに０を代入する（Ｓ２１８）。続いて、通知対象変更部１６は、変数ｉの値が変数Ｎの値未満であり、かつ、２^ｄが、グループ番号の最小値以上であるか否かを判定する（Ｓ２１９）。これらの条件が満たされる場合（Ｓ２１９でＹｅｓ）、通知対象変更部１６は、通知対象番号αに２^ｄを代入する（Ｓ２２０）。その結果、通知対象となるコールの範囲が縮小される。図４のステップＳ１０５において、グループ番号が通知対象番号α以下であると判定されるコールの数が減少するからである。

続いて、コスト予測部１５は、変数ｉに１を加算し、変数ｄから１を減算して（Ｓ２２１）、ステップＳ２１９以降を繰り返す。その結果、ステップＳ２２０は、最大でＮ回実行される。すなわち、実績ポイントが予定ポイントに対して小さければ小さいほど、通知対象番号αは小さくされる。但し、ステップＳ２１５でＹｅｓの場合、ステップＳ２１７〜Ｓ２１９、及びステップＳ２２１は実行されずに、ステップＳ２２０が１回実行されてもよい。すなわち、１回の見直し時期において、通知対象番号αの最大の低下幅は、１段階であってもよい。これは、通知対象番号αの増加幅についても同様である。すなわち、ステップＳ２０７〜Ｓ２０９、及びステップＳ２１４は実行されずに、ステップＳ２１０〜Ｓ２１３が実行されてもよい。

上述したように、本実施の形態によれば、所定期間（例えば、一ヶ月）の或る時点における機器２０の稼働状況が、当該時点においてＳＬＡ等に基づいて予定される状況を満たさない場合（例えば、実績ポイントが予定ポイントを超える場合）、通知対象とするコールの範囲が拡大される。その結果、以降におけるコールの多発が未然に防止される可能性を高めることができる。したがって、機器２０の稼働状況を適切な状況に維持できる可能性を高めることができる。

また、通知対象のコールの範囲の拡大は、コストに見合う場合に限って行われる。したがって、対価を超える保守作業の発生を抑制することができる。

更に、或る時点における機器２０の稼働状況が、当該時点において予定される状況を満たしている場合（例えば、実績ポイントが予定ポイント未満である場合）、通知対象とするコールの範囲が縮小される。その結果、保守コストを低下させることができる。

なお、機器管理システムは、図１５に示されるように構成されてもよい。図１５は、本発明の実施の形態における機器管理システムの第二の構成例を示す図である。図１５中、図１と同一部分には同一符号を付し、その説明は省略する。

図１５に示される機器管理システム２おいて、遠隔監視装置３０は、１以上の機器管理装置１０にネットワークを介して接続される。各機器管理装置１０は、１以上の機器２０にネットワークを介して接続される。各機器管理装置１０は、それぞれ同じ顧客に対して設置されてもよいし、相互に異なる顧客に対して設置されてもよい。

各機器管理装置１０は、遠隔監視装置３０にコールを転送してもよい。この場合、遠隔監視装置３０が、上記において機器管理装置１０が実行するとして説明した処理を実行してもよい。すなわち、遠隔監視装置３０が、図３に示される機能構成を有してもよい。又は、図３に示される機能構成が、遠隔監視装置３０と機器管理装置１０とに分散されてもよい。例えば、遠隔監視装置３０は、顧客ごとに、コール仕様記憶部１２１、コール履歴記憶部１２２、ポイント係数記憶部１２３、契約情報記憶部１２４、保守コスト記憶部１２５、及び課金額記憶部１２６を有し、各機器管理装置１０は、コール受信部１１、コール通知部１２、ポイント算出部１３、稼働状況判定部１４、コスト予測部１５、及び通知対象変更部１６を有してもよい。

なお、本実施の形態において、コール受信部１１は、受信部の一例である。コールは、状態情報の一例である。コール通知部１２は、送信部の一例である。所定の宛先に対して送信されるコールの発生を示す情報は、通知情報の一例である。通知対象変更部１６は、変更部の一例である。コール履歴記憶部１２２は、状態情報記憶部の一例である。稼働状況判定部１４は、特定部の一例である。コスト予測部１５は、予測部の一例である。実績ポイントは、状態情報の履歴に基づいて特定される前記機器の稼働状況の一例である。予定ポイントは、現時点において予定される状況の一例である。機器管理装置１０、又は機器管理装置１０及び遠隔監視装置３０は、情報処理システム及び情報処理装置の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１、２ 機器管理システム
１０ 機器管理装置
１１ コール受信部
１２ コール通知部
１３ ポイント算出部
１４ 稼働状況判定部
１５ コスト予測部
１６ 通知対象変更部
２０ 機器
３０ 遠隔監視装置
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１２１ コール仕様記憶部
１２２ コール履歴記憶部
１２３ ポイント係数記憶部
１２４ 契約情報記憶部
１２５ 保守コスト記憶部
１２６ 課金額記憶部
Ｂ バス

特開２０１２‐１５１７３８号公報

Claims (8)

1. 機器の状態の変化を示す状態情報を受信し、前記状態情報を状態情報記憶部に記憶する受信部と、
   前記受信部によって受信された状態情報が通知対象に該当する場合に、当該状態情報に関する通知情報を所定の宛先に送信する送信部と、
   前記状態情報記憶部に記憶された状態情報の履歴に基づいて特定される前記機器の稼働状況が、現時点において予定される状況を満たさない場合に、前記通知対象を拡大する変更部と、
   を有することを特徴とする機器管理装置。
2. 前記状態情報記憶部に記憶された状態情報の履歴に基づいて、所定期間における現時点までの前記機器の稼働状況として予定される状況を特定する特定部を有し、
   前記変更部は、前記状態情報記憶部に記憶された状態情報の履歴のうち、前記所定期間における現時点までの状態情報の履歴に基づいて特定される前記機器の稼働状況が、前記特定部によって特定された状況を満たさない場合に、前記通知対象を拡大する、
   ことを特徴とする請求項１記載の機器管理装置。
3. 前記所定期間において受信される状態情報のうち前記通知対象を拡大した場合に拡大後の前記通知対象に該当する状態情報の数を、前記状態情報記憶部に記憶された状態情報の履歴に基づいて予測する予測部を有し、
   前記変更部は、前記予測部によって予測される数に応じて、前記通知対象を拡大する、
   ことを特徴とする請求項２記載の機器管理装置。
4. 前記予測部は、前記予測部によって予測される数と、前記通知情報の送信によって発生するコストとに基づいて、前記所定期間におけるコストを予測し、
   前記変更部は、前記所定期間におけるコストが所定値以下である場合に、前記通知対象を拡大する、
   ことを特徴とする請求項３記載の機器管理装置。
5. 前記変更部は、前記状態情報記憶部に記憶された状態情報の履歴に基づいて特定される前記機器の稼働状況が、現時点において予定される状況を満たしている場合に、前記通知対象を縮小する、
   ことを特徴とする請求項１乃至４いずれか一項記載の機器管理装置。
6. １以上の情報処理装置を含む機器管理システムであって、
   機器の状態の変化を示す状態情報を受信し、前記状態情報を状態情報記憶部に記憶する受信部と、
   前記受信部によって受信された状態情報が通知対象に該当する場合に、当該状態情報に関する通知情報を所定の宛先に送信する送信部と、
   前記状態情報記憶部に記憶された状態情報の履歴に基づいて特定される前記機器の稼働状況が、現時点において予定される状況を満たさない場合に、前記通知対象を拡大する変更部と、
   を有することを特徴とする機器管理システム。
7. コンピュータが、
   機器の状態の変化を示す状態情報を受信し、前記状態情報を状態情報記憶部に記憶する受信手順と、
   前記受信手順において受信された状態情報が通知対象に該当する場合に、当該状態情報に関する通知情報を所定の宛先に送信する送信手順と、
   前記状態情報記憶部に記憶された状態情報の履歴に基づいて特定される前記機器の稼働状況が、現時点において予定される状況を満たさない場合に、前記通知対象を拡大する変更手順と、
   を実行することを特徴とする情報処理方法。
8. コンピュータに、
   機器の状態の変化を示す状態情報を受信し、前記状態情報を状態情報記憶部に記憶する受信手順と、
   前記受信手順において受信された状態情報が通知対象に該当する場合に、当該状態情報に関する通知情報を所定の宛先に送信する送信手順と、
   前記状態情報記憶部に記憶された状態情報の履歴に基づいて特定される前記機器の稼働状況が、現時点において予定される状況を満たさない場合に、前記通知対象を拡大する変更手順と、
   を実行させるプログラム。

Images