JP2019191662A - 設備遠隔監視システムおよび設備遠隔監視方法 - Google Patents

Abstract

【課題】ＳＬＡを規定した保守サービスにおいて、ＳＬＡの順守率を向上させて顧客満足度を高める。【解決手段】提供する保守サービス毎に評価項目を定め、評価項目と提供する品質レベルの目標値とを対応づけてＳＬＡＤＢ２３０に記憶するサービス契約管理部２２３と、保守サービスを提供する保守作業員が保持する保守端末から送信されるサービス提供情報に基づいて、評価項目の品質レベルの実績値を生成して実績ＤＢ１４０に記憶する実績値生成部１３１と、保守サービス毎に、評価項目の目標値と実績値とを比較し、実績値が目標値を満足しない場合、当該評価項目を契約不順守原因と特定する原因特定部１３３と、契約不順守原因と特定された評価項目を提示する提示部１３４と、を備える設備遠隔監視システムを提供する。【選択図】図３

Description

本発明は、昇降機などの設備を遠隔地で監視する遠隔監視技術に関し、特に、異常発生時の保守サービス提供支援技術に関する。

パフォーマンスを基準とした保守契約が広がりつつあり、これに伴い、保守サービスの提供にあたり、ＳＬＡ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）が規定されるようになっている。例えば、特許文献１には、「従来、被保守側システムと、保守側システムの保守サービス支援システム及び保守サービス拠点システムで、それぞれ別に行っていた端末別のＳＬＡ契約情報の管理を、被保守側センタが備える端末別ＳＬＡ管理ＤＢにより一元管理すると共に、端末装置に障害が発生し保守側システムに障害情報を通報する際に、障害が発生した端末装置に該当するＳＬＡ契約情報を障害情報に付加し、これを保守側システムに送信する（要約抜粋）」ＳＬＡ監視システムが開示されている。

特開２００８−５９０２３号公報

特許文献１に開示の技術では、ＳＬＡ規定時間の超過直前に注意喚起を、またＳＬＡ規定時間の超過直後に警告を、それぞれ保守拠点に設置される端末装置にて行う。しかしながら、特許文献１に開示の技術では、ＳＬＡを順守できなかった場合の原因の特定や改善策の提案までは考慮されていない。従って、将来的なＳＬＡの順守率の向上には必ずしもつながらない。

本発明は、上記事情に鑑みてなされたもので、ＳＬＡを規定した保守サービスにおいて、ＳＬＡの順守率を向上させて顧客満足度を高める技術を提供することを目的とする。

本発明は、設備に対する保守サービスの提供状況を遠隔地で監視する設備遠隔監視システムであって、提供する前記保守サービス毎に評価項目を定め、前記評価項目と提供する品質レベルの目標値とを対応づけてサービス契約データベースに記憶するサービス契約管理部と、前記保守サービスを提供する保守作業員が保持する保守端末から送信されるサービス提供情報に基づいて、当該保守サービスについて、前記評価項目の前記品質レベルの実績値を生成して当該評価項目に対応づけて実績データベースに記憶する実績値生成部と、前記保守作業員が提供した前記保守サービス毎に、前記評価項目の前記目標値と前記実績値とを比較し、当該実績値が当該目標値を満足しない場合、当該評価項目を契約不順守原因と特定する原因特定部と、前記契約不順守原因と特定された前記評価項目を提示する提示部と、を備えることを特徴とする。

本発明は、ＳＬＡを規定した保守サービスにおいて、ＳＬＡの順守率を向上させて顧客満足度を高めることができる。上記した以外の課題、構成および効果は、以下の実施形態の説明により明らかにされる。

本発明の実施形態の遠隔監視システムの全体構成例を示す図である。 （ａ）および（ｂ）は、それぞれ、本発明の実施形態の異常情報および出動要請のデータ構成の一例を説明するための図である。 本発明の実施形態の遠隔監視装置およびＳＬＡ管理装置の機能ブロック図である。 （ａ）〜（ｄ）は、それぞれ、本発明の実施形態の顧客マスタテーブル、保守拠点マスタテーブル、保守端末マスタテーブル、改善策データベースのデータの構成例を示す図である。 （ａ）および（ｂ）は、それぞれ、本発明の実施形態の作業登録データベースおよび実績データベースの一例を示す図である。 本発明の実施形態のＳＬＡデータベースの一例を示す図である。 本発明の実施形態の遠隔監視装置のハードウェア構成図である。 本発明の実施形態の実績値登録処理のフローチャートである。 本発明の実施形態の監視処理のフローチャートである。 本発明の実施形態の原因特定処理のフローチャートである。 （ａ）および（ｂ）は、それぞれ、本発明の実施形態の原因改善策表示画面の例を示す図である。 本発明の実施形態の変形例の遠隔監視装置およびＳＬＡ管理装置の機能ブロック図である。

以下、図面を参照しながら、本発明の実施形態を説明する。本実施形態の遠隔監視システムでは、設備の稼働状態を遠隔地で監視し、定期的または異常が発生した場合に保守サービスを提供する。本実施形態の遠隔監視システムでは、提供する保守サービス毎に評価項目を定め、評価項目毎に提供する品質レベルの目標値を、ＳＬＡ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）契約として予め定めておく。そして、提供した保守サービスについて、各評価項目の品質レベルの実績値が目標値に満たない場合、その原因を特定するとともに、その改善策を提示する。

以下、本実施形態では、保守対象設備をエレベーターとし、提供する保守サービスを、異常発生時の復旧サービスとし、評価項目を、保守サービスを完了させるために必要な作業（イベント）時間とする場合を例にあげて説明する。具体的には、通報時間、出動時間、救出時間、復旧時間等である。品質レベルは、各評価項目の所要時間で評価される。

すなわち、本実施形態では、ＳＬＡ契約において、結果を示す指標であるＫＧＩ（Ｋｅｙ Ｇｏａｌ Ｉｎｄｉｃａｔｏｒ）を、異常発生から保守サービスを完了するまでの全所要時間とし、過程を見る指標であるＫＰＩ（Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒ）を、イベント毎の所要時間とする。

［遠隔監視システムの全体構成］
図１は、本実施形態に係る遠隔監視システム１０１の全体構成例を示す図である。本実施形態の遠隔監視システム１０１は、遠隔監視装置１００と、ＳＬＡ（Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）管理装置２００と、保守拠点システム３００と、エレベーター４００ａ〜４００ｃと、を備える。

また、エレベーター４００ａ〜４００ｃは、顧客施設（ビル）内に設置され、それぞれ、制御装置４２０、監視装置４１０を備える。

制御装置４２０は、エレベーター４００の運行を制御する。例えば、乗りかごを昇降させたり、扉の開閉を制御したりする。また、運行以外にも、図示しない電磁接触器、停電灯、各種ランプなどの種々のエレベーター４００が備える機器の制御も行う。

監視装置４１０は、制御装置４２０からエレベーター４００の制御情報や稼働情報を読み出して監視し、エレベーター４００の異常の有無を検出する。異常を検出した場合は、異常情報を生成し、広域回線網等のネットワーク５１０を介して遠隔監視装置１００に異常情報を送信する。

監視装置４１０が生成して遠隔監視装置１００に送信する異常情報４４０のデータ構成の一例を図２（ａ）に示す。本図に示すように、本実施形態の異常情報４４０は、異常が発生したエレベーター４００を特定するための情報であるエレベーターＩＤ４４１と、異常内容を示す情報である異常内容４４２と、異常が検出された日時を示す情報である異常検出日時４４３と、を含む。

なお、本実施形態では、エレベーター４００ａ〜４００ｃのそれぞれが、制御装置４２０および監視装置４１０を備える構成としているが、これら各エレベーター４００ａ〜４００ｃを統括的に管理、監視する１台の制御装置４２０、１台の監視装置４１０を有する構成としてもよい。また、エレベーター４００ａ〜４００ｃは、特に区別する必要がない場合は、エレベーター４００で代表する。また、エレベーター４００を構成する主ロープ、釣合い錘、乗りかご、巻上機などについては、従前の構成と同様であるため、説明を省略する。

遠隔監視装置１００は、管理センタ等の遠隔地においてエレベーター４００を監視する。例えば、エレベーター４００から異常情報４４０を受信した場合、当該エレベーター４００の保守を担当する保守拠点システム３００の保守拠点装置３１０に出動を要請する情報（出動要請）を送信する。また、本実施形態では、出動要請に応じて出動して行った保守サービスが契約通りになされたか否かを監視する。遠隔監視装置１００の機能の詳細は、後述する。

本実施形態の出動要請１９０のデータ構成の一例を図２（ｂ）に示す。本図に示すように、本実施形態の出動要請１９０には、異常情報４４０のエレベーターＩＤ４４１と、異常内容４４２と、異常検出日時４４３と、にそれぞれ対応するエレベーターＩＤ１９１、異常内容１９２、異常検出日時１９３、が含まれる。さらに、異常が発生したエレベーター４００が配置されているビルを特定する情報であるビルＩＤ１９４が含まれていてもよい。

ＳＬＡ管理装置２００は、顧客毎に契約したＳＬＡを管理する。ＳＬＡ管理装置２００が管理するＳＬＡの詳細は、後述する。

保守拠点システム３００は、エレベーター４００の保守を行う各拠点に配置され、それぞれ、保守拠点装置３１０および保守端末３２０を備える。なお、図１では、保守拠点システム３００が１つである場合を例示しているが、保守拠点システム３００は、複数であってもよい。

保守拠点装置３１０は、遠隔監視装置１００から出動要請１９０を受け付けると、保守作業員に出動を促す出力を行う。保守拠点装置３１０は、例えば、出動要請１９０に含まれる情報を、出力デバイスである表示装置に表示させる。保守拠点装置３１０と遠隔監視装置１００とは、例えば、社内ＬＡＮ等のネットワーク５２０を介して接続される。

保守端末３２０は、保守作業員により携帯される、通信機能を備える携帯型情報処理装置である。本実施形態では、例えば、ネットワーク５１０を介して遠隔監視装置１００に接続され、遠隔監視装置１００が保持する各種の情報の参照や登録を行う。

保守端末３２０は、遠隔監視装置１００にアクセスし、情報を参照したり登録したりするための、例えば、Ｗｅｂブラウザ等が導入されていてもよい。なお、本実施形態では、保守端末３２０から遠隔監視装置１００にアクセスし、直接情報を登録するよう構成しているが、例えば、登録する情報を、通信データとして、遠隔監視装置１００に送信するよう構成してもよい。

［遠隔監視装置およびＳＬＡ管理装置の機能ブロック］
図３は、本実施形態の遠隔監視装置１００と、ＳＬＡ管理装置２００との機能ブロック図である。

［遠隔監視装置］
本図に示すように、本実施形態の遠隔監視装置１００は、通信部１２１と、データベース（ＤＢ）アクセス制御部１２２と、契約順守支援部１２３と、登録支援部１２４と、を備える。契約順守支援部１２３は、実績値生成部１３１と、監視部１３２と、原因特定部１３３と、提示部１３４と、を備える。

また、遠隔監視装置１００は、マスタＤＢ１７０と、実績ＤＢ１４０と、改善策ＤＢ１５０と、作業登録ＤＢ１６０と、を備える。

通信部１２１は、ネットワーク５１０を介して監視装置４１０および保守端末３２０との通信を行う。また、ネットワーク５２０を介して、保守拠点装置３１０との通信を行う。

ＤＢアクセス制御部１２２は、遠隔監視装置１００に保持される各種ＤＢを操作する。ＤＢアクセス制御部１２２は、各ＤＢに対し、例えば、規定のＳＱＬ文を発行し、データの検索、更新、レコードの登録や削除を行う。

登録支援部１２４は、保守端末３２０および保守拠点装置３１０が、遠隔監視装置１００が管理するデータを閲覧したり、遠隔監視装置１００にデータを登録したりすることを支援する。本実施形態では、保守端末３２０が、後述する作業登録ＤＢ１６０に、イベント毎の完了日時を登録することを支援する。

登録支援部１２４は、例えば、Ｗｅｂサーバの機能を有するユニットであってもよい。この場合、登録支援部１２４は、保守端末３２０に導入されているＷｅｂブラウザからの要求に従い、完了日時を登録する登録画面等をＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）などのマークアップ言語を用いて生成する。また、登録支援部１２４は、保守端末３２０および保守拠点装置３１０で動作する、画面制御用のスクリプトを生成する。画面やスクリプトは、遠隔監視装置１００が保持する各種のＤＢからデータを取得して生成される。

実績値生成部１３１は、異常情報４４０に応じて保守作業員が提供した保守サービスについて、イベント毎に、その所要時間の実績値を登録する。

本実施形態では、実績値生成部１３１は、監視装置４１０から異常情報４４０を受信すると、当該異常情報４４０の発信元のエレベーター４００の保守を担当する保守拠点システム３００の保守拠点装置３１０に出動要請１９０を出力する。また、作業登録ＤＢ１６０および実績ＤＢ１４０に、当該異常情報４４０に対応する新たなレコードを生成する。そして、保守端末３２０を介して作業登録ＤＢ１６０に登録されたデータを用いて、実績ＤＢ１４０のレコードを完成させる。実績値生成部１３１の機能、動作については、後述のフローチャートに従って説明する。

監視部１３２は、異常が発生した際、その異常への対処が、サービス契約を満たしたものであるか否かを監視する。

本実施形態では、異常情報４４０を受信すると、経過時間のカウントを開始する。そして、経過時間が、サービス契約で規定した時間を超えたか否かを判定し、超えている場合、遅延が発生していると判定する。

遅延が発生している場合、監視部１３２は、通信部１２１を介して保守拠点装置３１０および保守端末３２０に警告を出力する。警告を出力する保守拠点装置３１０は、その異常の発生したエレベーター４００の保守を担当する装置である。また、警告を出力する保守端末３２０は、実際に保守作業を行っている保守作業員が保持する端末である。監視部１３２による、監視処理および改善策提案処理の詳細は、後述する。

原因特定部１３３は、提供した保守サービスに遅延が発生している場合、その原因を特定する。本実施形態では、原因特定部１３３は、遅延が発生した場合、各イベントの所要時間を参照し、いずれのイベントへの対処に、遅延の原因があるかを突き止める。

提示部１３４は、原因特定部１３３が特定した原因（遅延原因）を、その改善策とともに、保守を担当した保守拠点装置３１０および保守端末３２０に出力する。本実施形態では、改善策は、イベント毎に改善策が格納されている改善策ＤＢ１５０から抽出する。

なお、遅延原因および改善策は、提示部１３４によらず、登録支援部１２４のＷｅｂサーバ機能により、保守拠点装置３１０および保守端末３２０に表示させてもよい。また、提示部１３４は、遅延原因および改善策を、さらに、遠隔監視装置１００のユーザに提示してもよい。

マスタＤＢ１７０は、本実施形態の遠隔監視装置１００による遠隔監視に必要な各種のマスタデータを管理する。本実施形態では、顧客マスタテーブル１７１と、保守拠点マスタテーブル１７２と、保守端末マスタテーブル１７３等が管理される。

顧客マスタテーブル１７１は、顧客毎のエレベーター４００を管理する。顧客マスタテーブル１７１で管理される各レコードのデータ構成を図４（ａ）に示す。本図に示すように、顧客マスタテーブル１７１では、顧客を一意に識別するための顧客ＩＤ１７１ａと、ビルを一意に識別するためのビルＩＤ１７１ｂと、エレベーターを一意に識別するためのエレベーターＩＤ１７１ｃとの各情報が、１つのレコードに対応づけて記憶される。

保守拠点マスタテーブル１７２は、保守拠点システム３００毎の保守を担当するエレベーター４００または顧客を管理する。保守拠点マスタテーブル１７２で管理される各レコードのデータ構成を図４（ｂ）に示す。本図に示すように、保守拠点マスタテーブル１７２では、保守拠点装置３１０を一意に識別する識別情報である保守拠点ＩＤ１７２ａと、ビルＩＤ１７２ｂと、エレベーターＩＤ１７２ｃとが、１つのレコードに対応づけて管理される。

保守端末マスタテーブル１７３は、保守拠点システム３００が管理する１台以上の保守端末３２０を管理する。保守端末マスタテーブル１７３で管理される各レコードのデータ構成を図４（ｃ）に示す。本図に示すように、保守端末マスタテーブル１７３では、保守拠点ＩＤ１７３ａと、保守端末を一意に識別する識別情報である保守端末ＩＤ１７３ｂとが、１つのレコードに対応づけて管理される。

改善策ＤＢ１５０には、イベント毎の改善策が管理される。改善策ＤＢ１５０は、図４（ｄ）に示すように、イベント１５１毎に、改善策１５２が１つのレコードに対応づけて管理される。なお、イベント毎の改善策は、複数登録されていてもよい。

本実施形態では、例えば、通報時間に対する改善策として、「通信手段変更」が登録されている。これは、例えば、無線通信を使用して監視している場合、より通信速度の速い有線通信に変更するといった改善策である。また、出動時間に対する改善策として、「出動経路見直しおよび発生時間に応じて複数の出動経路を用意」が登録されている。これは、周辺環境や出動ルートの交通事情について再確認を促したりする改善策である。そして、救出時間および復旧時間に対する改善策として「要員増」が登録されている。これは、保守作業員の追加の提案である。

作業登録ＤＢ１６０は、保守端末３２０からサービス提供情報として送信される、保守サービスの各イベントの完了日時が蓄積される。

作業登録ＤＢ１６０には、異常情報４４０毎に、実績値生成部１３１により、１つのレコードが生成されて登録される。各レコードには、図５（ａ）に示すように、異常情報４４０から得たエレベーターＩＤ１６１、異常内容１６２および異常検出日時１６３と、保守端末ＩＤ１６４、到着日時１６５、救出完了日時１６６、および復旧完了日時１６７とが登録される。

保守端末ＩＤ１６４は、保守サービスを担当する保守作業員が保持する保守端末３２０を一意に識別する情報である。保守端末ＩＤ１６４は、例えば、最初に保守端末３２０を介して遠隔監視装置１００にアクセスした際、登録される。

到着日時１６５、救出完了日時１６６、および復旧完了日時１６７は、それぞれ、保守作業員がこれらのイベント（作業）を完了した際、保守端末３２０を介して遠隔監視装置１００にアクセスし、登録する。例えば、保守作業員は、遠隔監視装置１００にアクセスし、自身の保守端末ＩＤ１６４が登録されているレコードで、これらの情報が未登録のレコードを抽出し、登録する。

実績ＤＢ１４０には、異常情報４４０で通知された異常に対する保守サービスの、評価項目毎の品質レベルの実績値が蓄積される。本実施形態では、保守サービスのイベント毎の所要時間の実績値が登録される。

実績ＤＢ１４０には、異常情報４４０毎に、実績値生成部１３１により、１つのレコードが生成されて登録される。各レコードには、図５（ｂ）に示すように、エレベーターＩＤ１４１と、異常内容１４２と、異常検出日時１４３と、保守端末ＩＤ１４４と、通報時間実績値１４５と、出動時間実績値１４６と、救出時間実績値１４７と、復旧時間実績値１４８と、警告フラグ１４９と、が登録される。

エレベーターＩＤ１４１は、異常が発生したエレベーター４００を特定する情報である。エレベーターＩＤ１４１と、異常内容１４２と、異常検出日時１４３とには、遠隔監視装置１００が受信した異常情報４４０に含まれる同名の情報がそのまま登録される。通報時間実績値１４５は、通報時間の実績値である。異常検出日時１４３と、異常情報４４０の受信時刻とに基づいて算出され、登録される。

出動時間実績値１４６と、救出時間実績値１４７と、復旧時間実績値１４８とは、それぞれ、出動時間、救出時間、復旧時間の、実績値である。それぞれ、作業登録ＤＢ１６０を参照し、必要に応じて演算を行い、得られた値が登録される。

なお、保守端末ＩＤ１４４は、送信元の保守端末３２０のＩＤである。また、警告フラグ１４９は、警告がなされた場合に、監視部１３２により登録される。

［ＳＬＡ管理装置］
ＳＬＡ管理装置２００は、図３に示すように、通信部２２１と、ＤＢアクセス制御部２２２と、サービス契約管理部２２３と、ＳＬＡＤＢ２３０と、を備える。

通信部２２１およびＤＢアクセス制御部２２２は、遠隔監視装置１００の同名の構成と同様の機能を備える。ただし、本実施形態では、通信部２２１は、遠隔監視装置１００の通信部１２１とデータの送受信を行う。

サービス契約管理部２２３は、顧客と結んだ保守サービス契約（ＳＬＡ）を管理する。本実施形態では、ＳＬＡ契約内容を、ＤＢアクセス制御部２２２を介してＳＬＡＤＢ２３０に登録して管理する。

ＳＬＡＤＢ２３０には、顧客毎の契約内容が蓄積される。本実施形態では、エレベーター４００毎に、異常内容に応じて提供する保守サービスが登録される。また、保守サービスを構成するイベント毎に、最大許容時間が目標値として登録される。さらに、提供された保守サービスが目標値を満たさなかった場合のペナルティが登録される。ペナルティは、例えば、達成度に応じた費用が登録される。

ＳＬＡＤＢ２３０で管理されるレコード例を図６に示す。本図に示すように、各レコードは、エレベーターＩＤ２３１と、異常内容２３２と、保守サービス２３３と、その保守サービス全体の最大許容時間である規定時間目標値２３４と、各イベントの最大許容時間（目標値）と、ペナルティ２３９と、を備える。本実施形態では、各イベントの目標値として、通報時間目標値２３５と、出動時間目標値２３６と、救出時間目標値２３７と、復旧時間目標値２３８とが格納される。なお、規定時間目標値２３４は、本実施形態では、他のイベントの目標値の合計である。各データは、契約に基づいて、登録される。

本図に示すように、エレベーターＩＤ２３１が「１２３４５６７８」のエレベーター４００においては、異常内容２３２が閉じ込めの場合、提供する保守サービス２３３は、救出である。通報時間目標値２３５は１分、出動時間目標値２３６は２０分、救出時間目標値２３７は１０分、復旧時間目標値２３８は３０分、ペナルティ２３９には、１分の遅延当たり、１００円が格納される。

なお、異常内容２３２が、起動不能および安全操作動作の場合は、提供する保守サービス２３３は、復旧であり、救出作業がないため、救出時間目標値２３７は０分が格納される。

［ハードウェア構成］
図７に、本実施形態の遠隔監視装置１００のハードウェア構成の一例を示す。本図に示すように、本実施形態の遠隔監視装置１００は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１１と、ＲＡＭ（Ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）１１２と、ＲＯＭ（Ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）１１３と、ネットワークインタフェース（Ｎ／Ｗ Ｉ／Ｆ）１１４と、ハードディスク等の記憶装置（ＨＤＤ：Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１１５と、入力Ｉ／Ｆ１１６と、出力Ｉ／Ｆ１１７とを備える。

ＣＰＵ１１１は、ＲＯＭ１１３やＨＤＤ１１５に記憶されているプログラムを、ＲＡＭ１１２に展開し、演算実行する処理装置である。ＣＰＵ１１１は、プログラムを演算実行することで、遠隔監視装置１００内部の各ハードウェアを統括的に制御する。ＲＡＭ１１２は、揮発性メモリであり、ＣＰＵ１１１が処理する際のワークメモリである。ＲＡＭ１１２は、ＣＰＵ１１１がプログラムを演算実行している間、必要なデータを一時的に記憶する。

ＲＯＭ１１３は、不揮発性メモリであり、遠隔監視装置１００の起動の際にＣＰＵ１１１で実行されるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）や、ファームウェアを記憶している。

ＨＤＤ１１５は、データを不揮発的に記憶する補助記憶装置である。ＨＤＤ１１５は、ＣＰＵ１１１が演算実行するプログラムや、制御データを記憶する。本実施形態では、通信部１２１、ＤＢアクセス制御部１２２、契約順守支援部１２３の各部の機能を実現するプログラムやデータベースが事前に導入、構築されている。ＣＰＵ１１１は、これらのプログラムをＲＡＭ１１２にロードして実行することにより、上記各機能を実現する。また、上記各ＤＢは、ＨＤＤ１１５またはＲＯＭ１１３に記憶される。

ネットワークＩ／Ｆ１１４は、外部機器との間で行われるデータ通信の制御を担うインターフェイスボードである。

入力Ｉ／Ｆ１１６は、入力デバイス１０６との間で信号の入出力を制御するインターフェイスである。出力Ｉ／Ｆ１１７は、ＣＰＵ１１１から指示を受けて、出力デバイス１０７に、例えば、画像を描画させる。

入力デバイス１０６は、例えば、キーボードやマウスなどであり、出力デバイス１０７は、例えば、平面モニターやディスプレイである。なお、入力デバイス１０６や出力デバイス１０７は、タッチパネルディスプレイで実現されてもよい。

本実施形態の監視装置４１０、保守拠点装置３１０、保守端末３２０、ＳＬＡ管理装置２００も基本的に同様のハードウェア構成を有する。

［実績値生成登録処理］
次に、本実施形態の実績値生成部１３１による、実績値生成登録処理の流れを説明する。図８は、本実施形態の実績値生成登録処理の処理フローである。ここでは、保守端末３２０による処理も併せて説明する。なお、本処理は、監視装置４１０から異常情報４４０を受信したことを契機に開始される。

以下、各処理フローの説明において、各種のＤＢへのアクセスは、ＤＢアクセス制御部１２２を介して行われるが、ここでは、その説明を省略する。

以下、異常内容が閉じ込めである場合を例にあげて、処理の流れを説明する。この場合、保守サービスでは、エレベーター４００の利用者が乗りかご内に閉じ込められているかを確認し、閉じ込められている場合は、利用者を乗りかごの外に救出した後で、故障復旧作業を行う。

実績値生成部１３１は、監視装置４１０から異常情報４４０を受信すると（ステップＳ１１０１）、異常情報４４０の送信元のエレベーター４００の保守を担当する保守拠点システム３００を特定する（ステップＳ１１０２）。

ここでは、異常情報４４０を解析し、異常情報４４０の送信元のエレベーター４００のエレベーターＩＤ４４１を抽出する。そして、保守拠点マスタを参照し、保守拠点ＩＤ１７２ａを抽出することにより、当該エレベーター４００の保守を担当する保守拠点システム３００の保守拠点装置３１０を特定する。

遠隔監視装置１００の実績値生成部１３１は、特定した保守拠点システム３００の保守拠点装置３１０に出動要請１９０を送信するとともに、実績ＤＢ１４０および作業登録ＤＢ１６０の新レコード（実績値レコード１４０ｒおよび作業レコード１６０ｒ）をそれぞれ生成し、登録する（ステップＳ１１０３）。

なお、出動要請１９０を受信した保守拠点装置３１０は、受信した出動要請１９０を、例えば、表示装置に表示する。これを見て、保守作業員は、保守端末３２０を携帯して異常が発生したエレベーター４００へ出動する。このとき、保守端末３２０は、保守拠点装置３１０から、出動要請１９０に含まれる情報を取得する。取得する情報は、具体的には、エレベーターＩＤ４４１、異常内容４４２、および、異常検出日時４４３である。

また、このとき、実績値生成部１３１は、実績値レコード１４０ｒおよび作業レコード１６０ｒに、異常情報４４０に格納されたエレベーターＩＤ４４１、異常内容４４２および異常検出日時４４３を、それぞれ、エレベーターＩＤ１４１、１６１、異常内容１４２、１６２、異常検出日時１４３、１６３として登録する。

実績値生成部１３１は、実際に通報に要した時間を算出し、実績ＤＢ１４０の実績値レコード１４０ｒの通報時間実績値１４５として登録する（ステップＳ１１０４）。ここでは、異常情報４４０を受信した日時から、異常情報４４０に格納される異常検出日時４４３を減算し、通報時間実績値１４５とする。

例えば、図５（ｂ）の例では、異常情報４４０を２０１８年２月２８日の１８時０１分に受信した場合、異常検出日時が同日の１８時であるため、実通報時間は、１分と算出される。

保守作業員は、異常情報送信元のエレベーター４００（以下、作業対象エレベーターと呼ぶ）に到着すると、保守端末３２０を介して遠隔監視装置１００にアクセスし、到着日時を登録する（ステップＳ１２０１）。本実施形態では、保守端末３２０を介して遠隔監視装置１００にアクセスし、作業登録ＤＢ１６０を呼びだす。そして、出動要請１９０に含まれるエレベーターＩＤ１６１、異常内容１６２および異常検出日時１６３に対応する作業レコード１６０ｒを特定し、当該作業レコード１６０ｒに、到着日時１６５を登録する。

なお、このとき、保守端末３２０の識別情報である保守端末ＩＤ１６４も併せて登録してもよい。なお、保守端末ＩＤ１６４は、保守端末３２０から遠隔監視装置１００にアクセスした際、自動的に登録されるよう構成してもよい。

実績値生成部１３１は、保守端末３２０を介して、到着日時１６５が登録されると、実出動時間を算出し、実績ＤＢ１４０の該当する実績値レコード１４０ｒの出動時間実績値１４６に登録する（ステップＳ１１０５）。

ここでは、まず、到着日時１６５が登録された作業レコード１６０ｒのエレベーターＩＤ１６１、異常内容１６２および異常検出日時１６３に対応する情報が登録されている実績値レコード１４０ｒを特定する。そして、その実績値レコード１４０ｒの出動時間実績値１４６に、算出した出動時間実績値１４６を登録する。出動時間実績値１４６は、異常情報４４０を受信した日時から、到着日時１６５を減算した値とする。

図５（ａ）および図５（ｂ）の例では、作業レコード１６０ｒに登録された到着日時１６５は、１８時３１分である。異常情報４４０を受信した日時は、１８時０１分であるため、出動時間実績値１４６は、３０分と算出される。

なお、このとき、出動時間実績値１４６の算出および登録時に用いた作業レコード１６０ｒに登録されている保守端末ＩＤ１６４を、実績値レコード１４０ｒの保守端末ＩＤ１４４に登録してもよい。

保守作業員は、作業対象エレベーターにおいて、救出処理を完了すると、保守端末３２０を介して遠隔監視装置１００にアクセスし、作業登録ＤＢ１６０の、同じ保守端末ＩＤ１６４が登録されている作業レコード１６０ｒの救出完了日時１６６に救出が完了した日時を登録する（ステップＳ１２０２）。

実績値生成部１３１は、保守端末３２０を介して救出完了日時１６６が登録されると、実救出時間を算出し、実績ＤＢ１４０の該当する実績値レコード１４０ｒの救出時間実績値１４７に登録する（ステップＳ１１０６）。ここでは、作業レコード１６０ｒの到着日時１６５から救出完了日時１６６までの時間を、救出時間実績値１４７として算出する。そして、実出動時間算出時と同様の手法で実績値レコード１４０ｒを特定し、特定された実績値レコード１４０ｒに登録する。

図５（ａ）および図５（ｂ）の例では、作業レコード１６０ｒに登録された救出完了日時１６６は、１８時３６分である。また、到着日時１６５は、１８時３１分である。従って、救出時間実績値１４７は、５分と算出される。

保守作業員は、作業対象エレベーターにおいて、復旧処理を完了すると、保守端末３２０を介して遠隔監視装置１００にアクセスし、作業登録ＤＢ１６０の作業レコード１６０ｒの復旧完了日時１６７にその日時を登録する（ステップＳ１２０３）。

実績値生成部１３１は、保守端末３２０を介して復旧完了日時１６７が登録されると、実復旧時間を算出し、実績ＤＢ１４０の該当する実績値レコードの復旧時間実績値１４８に登録する（ステップＳ１１０７）。ここでは、救出完了日時１６６から復旧完了日時１６７までの時間を、復旧時間実績値１４８と算出する。そして、実出動時間算出時と同様の手法で実績値レコード１４０ｒを特定し、特定された実績値レコード１４０ｒに登録する。

図５（ａ）および図５（ｂ）の例では、作業レコード１６０ｒに登録された復旧完了日時１６７は、１９時２６分である。また、救出完了日時１６６は、１８時３６分である。従って、復旧時間実績値１４８は、５０分と算出される。

以上により、異常情報４４０を受信した際、当該異常に対する保守サービスの実績値が、実績値レコード１４０ｒとして実績ＤＢ１４０に登録される。

［監視処理］
次に、本実施形態の監視部１３２による監視処理の流れを説明する。図９は、本実施形態の監視処理のフローチャートである。

実績ＤＢ１４０を監視し、新たな実績値レコード１４０ｒが登録されると（ステップＳ１３０１）、監視部１３２は、まず、当該異常に対する保守サービスの契約内容を把握する。

具体的には、まず、新たに登録された実績値レコード１４０ｒのエレベーターＩＤ１４１、異常内容１４２および異常検出日時１４３を抽出する（ステップＳ１３０２）。

そして、抽出したエレベーターＩＤ１４１および異常内容１４２に、エレベーターＩＤ２３１および異常内容２３２が合致するＳＬＡレコード２３０ｒを、ＳＬＡＤＢ２３０から取得する（ステップＳ１３０３）。

次に、目標規定時間までの残時間をカウントするタイマ（残時間タイマ）を作動させる（ステップＳ１３０４）。ここでは、現在時刻と異常検出日時１４３と規定時間目標値２３４とを用い、異常検出日時１４３に規定時間目標値２３４を加えた日時から現在時間を減算し、残時間の初期値を算出し、カウントを開始する。

残時間が０、すなわち残時間タイマが満了した場合（ステップＳ１３０５）、監視部１３２は、保守サービスが完了しているか否かを判別する。具体的には、監視部１３２は、再度実績ＤＢ１４０を参照し、ステップＳ１３０１で新たに登録された実績値レコード１４０ｒが完成しているか否かを判別する（ステップＳ１３０６）。ここでは、例えば、当該実績値レコード１４０ｒの復旧時間実績値１４８が登録されていれば、完成していると判別する。

登録されていれば、その保守サービスは、契約内容を満たしていると判断し、そのまま処理を終了する。

一方、登録されていない場合、まず、その保守サービスを提供した保守作業員の保守端末３２０と保守拠点とを特定する（ステップＳ１３０７）。ここでは、当該実績値レコード１４０ｒの保守端末ＩＤ１４４を抽出し、さらに、保守拠点マスタテーブル１７２を参照し、当該保守端末ＩＤ１４４を管理する保守拠点システム３００の保守拠点装置３１０を特定する。

そして、特定した、保守端末３２０と保守拠点装置３１０とに、通信部１２１を介して警告を通知する（ステップＳ１３０８）。また、実績値レコード１４０ｒに警告フラグ１４９を設定し（ステップＳ１３０９）、処理を終了する。

［原因特定処理］
次に、原因特定部１３３および提示部１３４による、遅延原因を特定する原因特定処理の流れを説明する。図１０は、本実施形態の原因特定処理の処理フローである。本処理は、実績値レコード１４０ｒが完成後、実行される。

原因特定部１３３は、実績値レコード１４０ｒが完成した場合、当該実績値レコード１４０ｒの保守サービスに対し、警告が出力されたか否かを判別する（ステップＳ１４０１）。ここでは、当該実績値レコード１４０ｒの警告フラグ１４９が設定されているか否かを判別する。

警告フラグ１４９が登録されていない場合は、警告がなされていないため、規定時間内にサービスを終えたため、遅延原因を特定する必要はなく、そのまま処理を終了する。

一方、警告フラグ１４９が登録されている場合、すなわち、警告が出力された場合、この保守サービスは、契約した規定時間目標値２３４内にサービスを終えることができなかったものである。従って、遅延原因を特定する必要がある。

原因特定部１３３は、まず、当該実績値レコード１４０ｒと、当該実績値レコード１４０ｒとエレベーターＩＤ１４１および異常内容１４２を同じくするＳＬＡレコード２３０ｒとを抽出する（ステップＳ１４０２）。

そして、イベント毎に、登録されている所要時間（実績値と目標値）を比較し（ステップＳ１４０３）、実績値レコード１４０ｒの値の方が大きいイベントを原因として特定する（ステップＳ１４０４）。ここでは、実績値と目標値とを比較し、実績値が目標値を超えるイベントを遅延原因として特定する。具体的には、通報時間実績値１４５と通報時間目標値２３５とを、出動時間実績値１４６と出動時間目標値２３６とを、救出時間実績値１４７と救出時間目標値２３７とを、復旧時間実績値１４８と復旧時間目標値２３８とを、それぞれ、比較し、遅延原因を特定する。

原因特定部１３３は、遅延原因として特定されたイベントに対応づけて、改善策ＤＢ１５０に登録されている改善策を抽出し（ステップＳ１４０５）、提示部１３４が抽出された改善策を提示し(ステップＳ１４０６)、処理を終了する。

なお、提示部１３４による提示先は、前述のように、保守サービスを担当した保守拠点の保守端末３２０および保守拠点装置３１０である。このとき、原因および改善策は、遠隔監視装置１００の出力デバイス１０７に出力されてもよい。

このとき、表示される原因改善策表示画面６１０の一例を図１１（ａ）に示す。本図に示すように、原因改善策表示画面６１０は、異常が発生したエレベーター４００を特定する情報と、異常内容、発生日時を特定する情報を表示する異常表示領域６１１と、遅延原因となった項目および考えられる改善策を表示する原因改善策表示領域６１２と、を備える。異常表示領域６１１には、遅延が発生した保守サービスの元となった異常情報４４０に含まれる情報が表示される。

ユーザは、異常表示領域６１１の表示を見て、どの異常情報４４０に対する保守サービスに遅延が発生したかを把握できる。また、原因改善策表示領域６１２を見ることにより、遅延発生の原因となる作業、および、今後の改善方針を知ることができる。

なお、原因特定処理は、監視処理中、ステップＳ１３０８の警告通知処理に続いて行われてもよい。この場合、ステップＳ１３０９およびステップＳ１４０１の処理はなくてもよい。

また、監視処理は行わなくてもよい。すなわち、本実施形態では、監視部１３２により、異常発生時からの経過時間を計測し、保守サービスの規定時間を超えた場合、警告を行い、遅延原因を特定しているが、これに限定されない。例えば、実績値生成部１３１が、イベント毎の実績値を算出する毎に、原因特定部１３３は、対応するイベントの目標値と実績値とを比較し、実績値が目標値を満たしていない場合、当該イベントを遅延原因と特定してもよい。なお、実績値と目標値との比較は、実績値レコード１４０ｒが完成後に行ってもよい。

また、ＳＬＡ契約の評価項目が１つである場合、原因特定処理は行わなくてもよい。

また、遅延原因を特定後、改善策とともにユーザに提示しているが、遅延原因のみ提示するように構成してもよい。

このとき、改善策は、ユーザから受け付けるように構成してもよい。この場合、提示部１３４は、原因改善策表示画面６１０において、原因改善策表示領域６１２に遅延原因のみ表示し、改善策は、ユーザが入力可能とする。

以上説明したように、本実施形態では、提供する保守サービス毎に、各イベントの所要時間の目標値をＳＬＡＤＢ２３０に管理するサービス契約管理部２２３と、保守サービスを提供する保守作業員が保持する保守端末３２０から送信される完了日時に基づいて、イベント毎の所要時間の実績値を生成して実績ＤＢ１４０に記憶する実績値生成部１３１と、各イベントについて目標値と実績値とを比較し、実績値が目標値を満足しない場合、そのイベントが遅延原因と特定する原因特定部１３３と、遅延原因をユーザに提示する提示部１３４と、を備える。

このため、本実施形態によれば、保守拠点等のユーザは、どのような異常に対する保守サービスで、ＳＬＡ契約不順守、すなわち、遅延が発生したかを、原因となる作業（イベント）とともに、確実に把握できる。これにより、保守拠点等のユーザは、改善すべき作業を容易に把握できる。把握した作業を、ＳＬＡ契約を満たすよう改善することにより、ＳＬＡ契約の順守率を向上させることができ、その結果、ペナルティも低減できる。また、ＳＬＡ契約の順守率が向上するため、顧客満足度も向上する。

さらに、遅延原因とともに、改善策が提示される場合、その改善策に従って保守サービスを改善することができる。

さらに、遅延が発生する保守サービスおよびその原因の把握を積み重ねることにより、現状の保守サービス体制におけるＳＬＡ契約条項の適否を判別できる。そして、不適切な契約であれば、ＳＬＡ契約の契約条項を見直したり、保守サービスの体制を再構築したり対策を講じることができる。例えば、特定の設備において、ＳＬＡ契約不順守が頻発する場合、そのＳＬＡ契約条項自体を見直したり、その設備への保守体制を強化したりすることができる。

これにより、より順守率の高い、適切なＳＬＡ契約の締結を支援できる。また、順守率が向上することにより、高い確度で顧客の期待に応じた保守サービスが提供でき、顧客満足度もさらに高まる。

また、保守サービス全体の所要時間が規定時間以内であっても、個々のイベントについて遅延の有無を判断するよう構成されている場合、保守サービス自体に遅延が発生していなくても、遅延が発生しがちなイベント（作業）を把握することができる。これにより、例えば、当該顧客との契約更改時や、他顧客との新規契約時に、ＳＬＡの各イベント（評価項目）の所要時間の配分を見直すためのデータを蓄積できる。

＜変形例＞
改善策とともに、改善策により増加するコスト（費用）も併せて登録するように構成してもよい。この場合、遠隔監視装置１００は、図１２に示すように、費用対効果算出部１３５を、さらに備えてもよい。費用対効果算出部１３５は、改善策により増加するコストと、低減するコストとから、総コストの変化額を、費用対効果として算出する。

例えば、遅延原因として、複数のイベントが特定された場合、それぞれのイベントに応じて改善策が考えられる。費用対効果算出部１３５は、改善策と、その追加費用が登録される毎に、その改善策による費用対効果を算出し、ユーザに提示する。

また、改善策ＤＢ１５０に、イベント毎に複数の改善策およびその改善策による追加コストが用意されている場合、費用対効果算出部１３５は、ユーザがその中から改善策を選択する毎に、その改善策による費用対効果を算出し、ユーザに提示するよう構成してもよい。

この場合に表示される原因改善策表示画面６２０の例を、図１１（ｂ）に示す。原因改善策表示画面６２０は、改善策入力領域６２１と、確認ボタン６２２と、対策前費用内訳表示領域６２３と、対策後費用内訳表示領域６２４と、効果表示領域６２５と、を備える。原因改善策表示画面６２０は、改善策の入力を受け付ける受付画面としても機能する。なお、原因改善策表示画面６２０も、原因改善策表示画面６１０と同様に、異常表示領域６１１を備えてもよい。

改善策入力領域６２１は、遅延原因とされたイベント毎に、改善策および追加費用の選択または入力を受け付ける領域である。本領域を介して、ユーザは、改善策および追加費用を選択または入力する。

確認ボタン６２２は、ユーザによる、改善策および追加費用の費用対効果算出指示を受け付ける。費用対効果算出部１３５は、確認ボタン６２２の押下を受け付けた際、改善策入力領域６２１に表示されている改善策および追加費用に基づき、後述する対策後費用内訳と、総ペナルティと、費用対効果とを算出する。

対策前費用内訳表示領域６２３は、改善策による対策を行う前、すなわち、現状のペナルティの内訳を表示する領域である。費用対効果算出部１３５は、遅延原因が特定された場合、遅延原因とされた各イベントの所要時間の実績値と目標値との差を算出し、ペナルティ２３９を参照し、内訳と総ペナルティ金額を算出し、内訳を、対策前費用内訳表示領域６２３に、例えば、グラフ化して表示する。

対策後費用内訳表示領域６２４は、確認ボタン６２２の押下により決定された改善策による、対策後のペナルティの内訳を表示する領域である。費用対効果算出部１３５は、上述のように、対策後費用内訳と、総ペナルティとを算出し、内訳を、対策後費用内訳表示領域６２４に、例えば、グラフ化して表示する。

効果表示領域６２５は、改善策による費用対効果を表示する領域である。費用対効果算出部１３５は、先に算出した対策後の総費用から対策前の総費用を減算し、その結果を効果表示領域６２５に表示する。

例えば、図１１（ｂ）の例では、通報時間、出動時間、救出時間、復旧時間、それぞれに遅延が発生している。そして、改善策として出動時間の遅延に対し、出動経路見直し、および、追加費用として、経路が延長することによる燃料費の追加分として３００円が入力される。例えば、多少遠回りであっても、信号が少なく、制限速度が速い幹線道路を通る経路等に変更する例である。

対策前は、通報の遅延に起因するペナルティが１５０円、出動の遅延に起因するペナルティが９００円、救出の遅延に起因するペナルティが１００円、復旧の遅延に起因するペナルティが４５０円であり、総ペナルティは１６００円である。

出動経路を見直すという改善策を講じた場合、出動に起因するペナルティは０円となり、一方、その他のイベントに起因するペナルティはそのまま維持される。出動の遅延に起因するペナルティ９００円が０円になる代わりに、経路が延長することによる追加コスト３００円が発生する。従って、対策後の総ペナルティは１０００円である。

費用対効果は、対策後の総費用１０００円から対策前の総費用１６００円を減算して得られる−６００円である。

なお、保守端末３２０または保守拠点装置３１０のユーザからの入力を受け付ける場合、提示部１３４は、原因改善策表示画面６２０を、ＨＴＭＬなどのマークアップ言語を用いて生成し、これらの装置に導入されているＷｅｂブラウザからの要求に従って提供してもよい。

このように、遅延が発生した際、ユーザが改善策を入力可能とすることにより、個々の遅延に最適な改善策を得ることができる。特に、図１１（ｂ）に示す例のように、予め複数の改善策を用意しておき、ユーザがその中から、個々の保守サービスに最適な改善案を選択するように構成することにより、ユーザによる負担も低減できる。

また、本変形例のように、改善策による対策前と後との費用の内訳、費用対効果が一目でわかるような表示を行うことにより、ユーザは、その改善策の効果を容易に把握できる。

また、複数の改善案それぞれの対策後の総費用および／または費用内訳を、全て算出し、表示させるよう構成してもよい。

また、原因改善策表示画面６２０の出力先装置が、位置情報取得機能や地図情報を備えている場合、遅延原因として出動時間が特定された際、実際の出動経路を地図上に表示させるよう構成してもよい。これにより、ユーザは、直感的に保守作業員が選択した経路の適否を判別でき、よりよい改善策選択を支援できる。

また、上記実施形態および変形例では、提供された保守サービス毎に、遅延の有無を判別し、原因を特定したり、改善策を提示したり、費用対効果を算出したりしているが、これに限定されない。実績値レコード、遅延の有無および遅延原因を蓄積し、所定数集まった時点で、蓄積されたデータを解析するよう構成してもよい。

例えば、同じエレベーター４００の保守サービスの複数の実績値レコードを、異常の発生時刻に応じて並べてユーザに表示してもよい。これにより、ユーザは、発生時刻に応じた所要時間の変化を把握でき、より適切な改善策を講じることができる。例えば、所定の時間帯で出動時間に遅延が発生している場合、当該時間帯に、現状の経路で渋滞が発生している等の判断ができる。従って、改善策として、所定の時間帯のみ、追加費用がかかっても、他の経路を採用する等を提供できる。

例えば、同じエレベーター４００の保守サービスの複数の実績値レコードを、時系列に並べてユーザに表示してもよい。これにより、ユーザは、各イベントの所要時間の推移を一目で把握でき、将来の見通しを立てることもできる。例えば、所要時間が単調増加しているイベントが有る場合、現状では、目標値を満足している場合であっても、近い将来、目標値を満たさない事態が発生する可能性が高い。このような場合、例えば、契約の見直しを提案するなど、予防的な措置を講じることができる。

なお、上記実施形態等では、保守サービスの所要時間が規定時間目標値２３４を越えた場合に警告を行うよう構成しているが、これに限定されない。例えば、目標規定時間の、予め定めた時間前に、事前警告を行うよう構成してもよい。

また、上記実施形態等では、提供する品質レベルとして、保守サービスの各イベントの所要時間を用いているが、これに限定されない。例えば、エレベーター４００等の設備の稼働率を用いてもよい。

また、上記実施形態および変形例では、遠隔監視装置１００と、ＳＬＡ管理装置２００とを独立した装置で実現する場合を例にあげて説明したが、これらは、１つの装置で実現されてもよい。

また、保守対象設備は、エスカレーター、水平型エスカレーター、オートスロープなどであってもよい。

なお、本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることが可能であり、また、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

１００：遠隔監視装置、１０１：遠隔監視システム、１０６：入力デバイス、１０７：出力デバイス、１１１：ＣＰＵ、１１２：ＲＡＭ、１１３：ＲＯＭ、１１４：ネットワークＩ／Ｆ、１１５：ＨＤＤ、１１６：入力Ｉ／Ｆ、１１７：出力Ｉ／Ｆ、１２１：通信部、１２２：ＤＢアクセス制御部、１２３：契約順守支援部、１２４：登録支援部、１３１：実績値生成部、１３２：監視部、１３３：原因特定部、１３４：提示部、１３５：費用対効果算出部、
１４０：実績ＤＢ、１４０ｒ：実績値レコード、１４１：エレベーターＩＤ、１４２：異常内容、１４３：異常検出日時、１４４：保守端末ＩＤ、１４５：通報時間実績値、１４６：出動時間実績値、１４７：救出時間実績値、１４８：復旧時間実績値、１４９：警告フラグ、
１５０：改善策ＤＢ、１５１：イベント、１５２：改善策、
１６０：作業登録ＤＢ、１６０ｒ：作業レコード、１６１：エレベーターＩＤ、１６２：異常内容、１６３：異常検出日時、１６４：保守端末ＩＤ、１６５：到着日時、１６６：救出完了日時、１６７：復旧完了日時、
１７０：マスタＤＢ、１７１：顧客マスタテーブル、１７１ａ：顧客ＩＤ、１７１ｂ：ビルＩＤ、１７１ｃ：エレベーターＩＤ、１７２：保守拠点マスタテーブル、１７２ａ：保守拠点ＩＤ、１７２ｂ：ビルＩＤ、１７２ｃ：エレベーターＩＤ、１７３：保守端末マスタテーブル、１７３ａ：保守拠点ＩＤ、１７３ｂ：保守端末ＩＤ、１９０：出動要請、１９１：エレベーターＩＤ、１９２：異常内容、１９３：異常検出日時、１９４：ビルＩＤ、
２００：ＳＬＡ管理装置、２２１：通信部、２２２：ＤＢアクセス制御部、２２３：サービス契約管理部、
２３０：ＳＬＡＤＢ、２３０ｒ：ＳＬＡレコード、２３１：エレベーターＩＤ、２３２：異常内容、２３３：保守サービス、２３４：規定時間目標値、２３５：通報時間目標値、２３６：出動時間目標値、２３７：救出時間目標値、２３８：復旧時間目標値、２３９：ペナルティ、
３００：保守拠点システム、３１０：保守拠点装置、３２０：保守端末、
４００：エレベーター、４００ａ：エレベーター、４００ｂ：エレベーター、４００ｃ：エレベーター、４１０：監視装置、４２０：制御装置、４４０：異常情報、４４１：エレベーターＩＤ、４４２：異常内容、４４３：異常検出日時、
５１０：ネットワーク、５２０：ネットワーク、
６１０：原因改善策表示画面、６１１：異常表示領域、６１２：原因改善策表示領域、６２０：原因改善策表示画面、６２１：改善策入力領域、６２２：確認ボタン、６２３：対策前費用内訳表示領域、６２４：対策後費用内訳表示領域、６２５：効果表示領域

Claims (11)

1. 設備に対する保守サービスの提供状況を遠隔地で監視する設備遠隔監視システムであって、
   提供する前記保守サービス毎に評価項目を定め、前記評価項目と提供する品質レベルの目標値とを対応づけてサービス契約データベースに記憶するサービス契約管理部と、
   前記保守サービスを提供する保守作業員が保持する保守端末から送信されるサービス提供情報に基づいて、当該保守サービスについて、前記評価項目の前記品質レベルの実績値を生成して当該評価項目に対応づけて実績データベースに記憶する実績値生成部と、
   前記保守作業員が提供した前記保守サービス毎に、前記評価項目の前記目標値と前記実績値とを比較し、当該実績値が当該目標値を満足しない場合、当該評価項目を契約不順守原因と特定する原因特定部と、
   前記契約不順守原因と特定された前記評価項目を提示する提示部と、を備えること
   を特徴とする設備遠隔監視システム。
2. 請求項１記載の設備遠隔監視システムであって、
   前記提示部は、前記契約不順守原因と特定された前記評価項目について前記品質レベルを改善する改善策をさらに提示すること
   を特徴とする設備遠隔監視システム。
3. 請求項１記載の設備遠隔監視システムであって、
   前記保守サービス毎に、複数の前記評価項目が予め定められ、
   前記評価項目それぞれの前記品質レベルは、所要時間で評価されること
   を特徴とする設備遠隔監視システム。
4. 請求項３記載の設備遠隔監視システムであって、
   前記保守作業員が提供した前記保守サービス毎に、当該保守サービスの全ての前記評価項目の前記実績値の合計が、前記目標値の合計を超えるか否かを監視する監視部をさらに備え、
   前記原因特定部は、前記実績値の合計が、前記目標値の合計を超えた場合、前記評価項目それぞれについて前記目標値と前記実績値とを比較すること
   を特徴とする設備遠隔監視システム。
5. 請求項４記載の設備遠隔監視システムであって、
   前記監視部は、前記実績値の合計が前記目標値の合計を超えた場合、警告を出力すること
   を特徴とする設備遠隔監視システム。
6. 請求項２記載の設備遠隔監視システムであって、
   前記改善策は、予め記憶されること
   を特徴とする設備遠隔監視システム。
7. 請求項２記載の設備遠隔監視システムであって、
   前記提示部は、前記契約不順守原因として特定された前記評価項目に対し、前記改善策の入力を受け付ける受付画面をさらに提示し、当該受付画面を介して、前記改善策を受け付けること
   を特徴とする設備遠隔監視システム。
8. 請求項２記載の設備遠隔監視システムであって、
   前記改善策の費用対効果を算出する費用対効果算出部をさらに備え、
   前記改善策は、当該改善策に係るコストを含み、
   前記サービス契約データベースには、前記目標値の達成度に応じたペナルティがさらに記憶され、
   前記費用対効果算出部は、提示する前記改善策について、前記コストと前記ペナルティとを用いて、前記費用対効果を算出し、
   前記提示部は、前記費用対効果をさらに提示すること
   を特徴とする設備遠隔監視システム。
9. 請求項３記載の設備遠隔監視システムであって、
   前記保守サービスは、前記設備に異常が発生した際の対応であり、
   前記評価項目は、前記異常が検出されてから通報までの通報時間、前記通報を受けてから前記異常が発生した前記設備に前記保守作業員が到着するまでの出動時間、および前記保守作業員が前記設備に到着してから前記設備が復旧するまでの復旧時間を含むこと
   を特徴とする設備遠隔監視システム。
10. １つまたは複数のコンピュータによる、設備に対する保守サービスの提供状況を遠隔地で監視する設備遠隔監視方法であって
    前記保守サービスを提供する保守作業員が保持する保守端末から送信されるサービス提供情報に基づいて、当該保守サービスについて、予め定められた評価項目の品質レベルの実績値を生成し、
    生成した前記実績値を、予め記憶された前記評価項目の前記品質レベルの目標値と比較し、
    当該実績値が当該目標値を満足しない場合、当該評価項目を契約不順守原因として提示すること
    を特徴とする設備遠隔監視方法。
11. 請求項１０記載の設備遠隔監視方法であって、
    前記契約不順守原因として前記評価項目を提示する際、当該評価項目について前記品質レベルを改善する改善策をさらに提示すること
    を特徴とする設備遠隔監視方法。

Images