特許 7612030 監視システムおよび監視方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-12-26

(45)【発行日】2025-01-10

(54)【発明の名称】監視システムおよび監視方法

(51)【国際特許分類】

   G06Q 10/20 20230101AFI20241227BHJP

【ＦＩ】

G06Q10/20

【請求項の数】 7

(21)【出願番号】P 2023543517

(86)(22)【出願日】2021-08-24

(86)【国際出願番号】 JP2021030955

(87)【国際公開番号】W WO2023026356

(87)【国際公開日】2023-03-02

【審査請求日】2023-08-09

(73)【特許権者】

【識別番号】000236056

【氏名又は名称】三菱電機ビルソリューションズ株式会社

(73)【特許権者】

【識別番号】000006013

【氏名又は名称】三菱電機株式会社

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】濱田 恭平

(72)【発明者】

【氏名】田畠 広泰

(72)【発明者】

【氏名】井上 淳

(72)【発明者】

【氏名】橋口 拓弥

(72)【発明者】

【氏名】▲高▼橋 理子

(72)【発明者】

【氏名】川▲崎▼ 仁

【審査官】鈴木 和樹

(56)【参考文献】

【文献】特開２０１７－０２４８５６（ＪＰ，Ａ）

【文献】特開２００５－１２２７０７（ＪＰ，Ａ）

【文献】特開２００７－０３４７１２（ＪＰ，Ａ）

【文献】特開２０１９－０２８５５６（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００ － ９９／００

(57)【特許請求の範囲】

【請求項1】

昇降機の保守サービスの提供を監視する監視システムであって、
前記保守サービスを開始してから前記保守サービスの実施結果の顧客に対する報告が完了するまでの複数の作業に要する作業期間の遅延状態を予測する予測モデルと、前記複数の作業の各々の基準期間に対する実績期間とを記憶する記憶部と、
前記予測モデルおよび前記複数の作業の各々の実績期間に基づき前記遅延状態を予測する予測部と、
前記予測部が予測した前記遅延状態を表示する表示部とを備え、
前記顧客は、前記昇降機の保守会社と前記保守サービスの契約を行っており、
前記複数の作業は、前記保守サービスと、前記保守サービスの結果を入力する事務作業と、前記保守サービスの報告書を前記顧客が閲覧可能な状態にする報告作業とを含み、
前記予測モデルは、前記複数の作業の各々の基準期間と当該基準期間に対する実績期間との差分を用いて前記遅延状態を予測するモデルである、監視システム。

【請求項2】

前記複数の作業の各々の基準期間を用いて前記予測モデルを生成する生成部をさらに備える、請求項１に記載の監視システム。

【請求項3】

前記記憶部は、前記保守サービスを行ったときに前記昇降機が発報する発報データをさらに記憶し、
前記予測部は、前記発報データが発報されていないときは、前記発報データが発報されているときよりも、遅延していると評価されるように前記遅延状態を予測する、請求項１または請求項２に記載の監視システム。

【請求項4】

前記記憶部は、過去の前記保守サービスの結果をさらに記憶し、
前記監視システムは、過去の前記保守サービスの結果に基づき、前記予測モデルを更新する第１更新部をさらに備える、請求項１～請求項３のいずれか１項に記載の監視システム。

【請求項5】

前記予測モデルは、前記保守サービス中にトラブルが発生しなかった場合において前記遅延状態を予測する第１予測モデルと、前記保守サービス中にトラブルが発生した場合において前記遅延状態を予測する第２予測モデルとを含み、
前記予測部は、
前記保守サービス中にトラブルが発生しなかった場合は、前記第１予測モデルを用いて前記遅延状態を予測し、
前記保守サービス中にトラブルが発生した場合は、前記第２予測モデルを用いて前記遅延状態を予測する、請求項１～請求項４のいずれか１項に記載の監視システム。

【請求項6】

前記保守サービス中にトラブルが発生した場合における、過去の前記保守サービスの結果に基づき前記第２予測モデルを更新する第２更新部をさらに備える、請求項５に記載の監視システム。

【請求項7】

コンピュータが実行する、昇降機の保守サービスの提供を監視する監視方法であって、
前記保守サービスを開始してから前記保守サービスの実施結果の顧客に対する報告が完了するまでの複数の作業に要する作業期間の遅延状態を予測する予測モデルを記憶するステップと、
前記複数の作業の各々の基準期間に対する実績期間を記憶するステップと、
前記予測モデルおよび前記複数の作業の各々の実績期間に基づき前記遅延状態を予測するステップと、
前記予測するステップが予測した前記遅延状態を表示するステップとを備え、
前記顧客は、前記昇降機の保守会社と前記保守サービスの契約を行っており、
前記複数の作業は、前記保守サービスと、前記保守サービスの結果を入力する事務作業と、前記保守サービスの報告書を前記顧客が閲覧可能な状態にする報告作業とを含み、
前記予測モデルは、前記複数の作業の各々の基準期間と当該基準期間に対する実績期間との差分を用いて前記遅延状態を予測するモデルである、監視方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、昇降機の保守サービスの提供を監視する監視システムおよび監視方法に関する。

【背景技術】

【0002】

近年、昇降機の保守サービスの提供にあたり、ＳＬＡ（Service Level Agreement）が規定されるようになっている。たとえば、特開２０１９－１９１６６２号公報（特許文献１）に記載された設備遠隔監視システムにおいては、提供する保守サービスごとに評価項目を定め、評価項目ごとに提供する品質レベルの目標値をＳＬＡ契約として予め定めている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１９－１９１６６２号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

特許文献１に記載の設備遠隔監視システムにおいては、ＳＬＡの対象範囲として、保守サービスの開始から完了までを対象としている。しかしながら、保守サービス全体（保守サービスを開始してから保守結果を顧客に届けるまでの期限管理）を対象として、品質レベルを向上させることについては何ら考慮されていなかった。

【0005】

本開示は、このような課題を解決するためになされたものであって、その目的は、ＳＬＡを規定した保守サービスにおいて、保守サービス全体を対象としたＳＬＡの順守率を向上させて顧客満足度を高めることができる技術を提供することである。

【課題を解決するための手段】

【0006】

本開示に係る監視システムは、昇降機の保守サービスの提供を監視する。監視システムは、記憶部と、予測部と、表示部とを備える。記憶部は、保守サービスを開始してから保守サービスの実施結果の顧客に対する報告が完了するまでの複数の作業に要する作業期間の遅延状態を予測する予測モデルと、複数の作業の各々の基準期間に対する実績期間とを記憶する。予測部は、予測モデルおよび複数の作業の各々の実績期間に基づき遅延状態を予測する。表示部は、予測部が予測した遅延状態を表示する。予測モデルは、複数の作業の各々の基準期間と当該基準期間に対する実績期間との差分を用いて遅延状態を予測するモデルである。

【0007】

本開示に係る監視方法は、昇降機の保守サービスの提供を監視する方法である。監視方法は、保守サービスを開始してから保守サービスの実施結果の顧客に対する報告が完了するまでの複数の作業に要する作業期間の遅延状態を予測する予測モデルを記憶するステップと、複数の作業の各々の基準期間に対する実績期間を記憶するステップと、予測モデルおよび複数の作業の各々の実績期間に基づき遅延状態を予測するステップと、予測するステップが予測した遅延状態を表示するステップとを備える。予測モデルは、複数の作業の各々の基準期間と当該基準期間に対する実績期間との差分を用いて遅延状態を予測するモデルである。

【発明の効果】

【0008】

本開示によれば、ＳＬＡを規定した保守サービスにおいて、保守サービス全体を対象としたＳＬＡの順守率を向上させて顧客満足度を高めることができる。

【図面の簡単な説明】

【0009】

【図1】第１実施形態に係る監視システムの概要を説明する図である。

【図2】第１実施形態に係る監視システムのハードウェア構成の一例を示す図である。

【図3】第１実施形態に係る監視システムの機能ブロック図の一例を示す図である。

【図4】第１実施形態に係る監視システムが実行する処理のフローチャートである。

【図5】第１実施形態に係る作業期間の遅延状態を説明するための図である。

【図6】第１実施形態に係る作業期間の遅延状態を説明するための図である。

【図7】第１実施形態に係る作業期間の遅延状態を説明するための図である。

【図8】第１実施形態に係る作業期間の遅延状態を説明するための図である。

【図9】第１実施形態に係る作業期間の遅延状態を説明するための図である。

【図10】第２実施形態に係る監視システムの機能ブロック図の一例を示す図である。

【図11】第２実施形態に係る監視システムが実行する処理のフローチャートである。

【発明を実施するための形態】

【0010】

以下、図面を参照しつつ、実施の形態について説明する。以下の説明では、同一の部品には同一の符号を付してある。それらの名称および機能も同じである。したがって、それらについての詳細な説明は繰り返さない。

【0011】

［第１実施形態］
まず、第１実施形態に係る監視システム１について説明する。図１は、第１実施形態に係る監視システム１の概要を説明する図である。図２は、第１実施形態に係る監視システムのハードウェア構成の一例を示す図である。

【0012】

監視システム１は、昇降機の保守サービスの提供を監視するシステムである。以下では、昇降機の一例としてエレベーターを例示し、エレベーターの保守サービスについて説明する。監視システム１は、監視装置２００と、保守会社端末４００と、エレベーター制御装置１００とを含む。

【0013】

本実施の形態においては、顧客と保守会社との契約において、昇降機の保守サービス全体をＳＬＡの評価項目として定めているものとする。監視装置２００は、昇降機の保守サービス全体を対象として、その遅延状態を管理する。ここで、「保守サービス全体」とは、保守サービス（「保守作業」とも称する）を開始してから保守サービスの実施結果の顧客に対する報告（「保守結果報告」とも称する）が完了するまでを指す。

【0014】

ＳＬＡの契約として、保守サービスの開始から保守結果報告の完了まで期間の目標値（後述する「目標日数Ｘ」）が定められている。本実施の形態では、監視装置２００が保守サービス全体の遅延状態を管理することで作業遅延に対する注意喚起を行い、保守結果報告の期限を遵守するよう行動を促す。これにより、ＳＬＡの遵守率を向上させることができる。

【0015】

ここでは、保守会社は、ビル１０のオーナーである顧客とビル１０のエレベーターを定期的に点検する契約（保守サービスの契約）を行っているものとする。たとえば、目標日数Ｘ＝２８日としてＳＬＡ契約を行っている場合、監視装置２００は、２８日以内に点検結果を報告できるように、作業の遅延状態を管理する。その具体的方法については、以下で説明する。

【0016】

本例において、ビル１０は、顧客が所有する４階建てのビルである。ビル１０には、エレベーターが設置されている。エレベーターのかご３４１は、昇降路３５１内を移動する。かご３４１は、各階に停止可能であり、１階の乗場３３１～４階の３３４からかご３４１に乗車可能である。ビル１０の機械室には、エレベーター制御装置１００が設置されている。エレベーター制御装置１００は、かご３４１を制御する。

【0017】

本実施の形態において、エレベーター制御装置１００は、ネットワークを介して監視装置２００と接続可能である。監視装置２００は、昇降機の保守サービスの提供を監視する装置である。監視装置２００は、たとえば、保守会社の情報センター２０に設置されている。

【0018】

保守会社端末４００は、ネットワークを介して監視装置２００と接続可能である。保守会社端末４００は、たとえば、保守会社の支店４０に設置されている。保守会社端末４００は、昇降機の保守サービスに関する情報を入力するための端末である。

【0019】

本例においては、顧客はビル１０におり、顧客が所有する顧客端末３００にアクセス可能であるとする。顧客端末３００は、ネットワークを介して監視装置２００と接続可能である。

【0020】

図２に示すように、監視装置２００は、ＣＰＵ（Central Processing Unit）２１１と、ＲＯＭ（Read Only Memory）２１２と、ＲＡＭ（Random Access Memory）２１３と、記憶部２１４と、通信インターフェイス２１５と、Ｉ／Ｏインターフェイス２１６とを有する。これらは、バスを介して相互に通信可能に接続されている。

【0021】

ＣＰＵ２１１は、監視装置２００全体を総括的に制御する。ＣＰＵ２１１は、ＲＯＭ２１２に格納されているプログラムをＲＡＭ２１３に展開して実行する。ＲＯＭ２１２は、監視装置２００が行う処理の処理手順が記されたプログラムを格納する。

【0022】

ＲＡＭ２１３は、ＣＰＵ２１１がプログラムを実行する際の作業領域となるものであり、プログラムやプログラムを実行する際のデータ等を一時的に記憶する。また、記憶部２１４は、不揮発性の記憶装置であり、たとえば、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等である。

【0023】

通信インターフェイス２１５は、エレベーター制御装置１００、保守会社端末４００および顧客端末３００との通信を制御する。監視装置２００は、通信インターフェイス１１５を介してこれらの装置またはシステムと通信を行うことができる。

【0024】

Ｉ／Ｏインターフェイス２１６は、ＣＰＵ２１１が外部機器と接続するためのインターフェイスである。たとえば、ＣＰＵ２１１は、Ｉ／Ｏインターフェイス２１６を介してディスプレイなどの表示装置、あるいはキーボードやマウスなどの入力装置と接続可能である。

【0025】

図示しないが、顧客端末３００および保守会社端末４００も、監視装置と同様に、ＣＰＵと、ＲＯＭと、ＲＡＭと、記憶部と、通信インターフェイスと、Ｉ／Ｏインターフェイスとを有するものとする。

【0026】

エレベーター制御装置１００は、ＣＰＵ１１１と、ＲＯＭ１１２と、ＲＡＭ１１３と、通信インターフェイス１１５とを有する。これらは、バスを介して相互に通信可能に接続されている。

【0027】

ＣＰＵ１１１は、エレベーター制御装置１００全体を総括的に制御する。ＣＰＵ１１１は、ＲＯＭ１１２に格納されているプログラムをＲＡＭ１１３に展開して実行する。ＲＯＭ１１２は、エレベーター制御装置１００が行う処理の処理手順が記されたプログラムを格納する。

【0028】

ＲＡＭ１１３は、ＣＰＵ１１１がプログラムを実行する際の作業領域となるものであり、プログラムやプログラムを実行する際のデータ等を一時的に記憶する。

【0029】

通信インターフェイス１１５は、かご３４１、各階の乗場に設置された装置（呼び釦を含む乗場装置）、監視装置２００との通信を制御する。エレベーター制御装置１００は、通信インターフェイス１１５を介してこれらの装置等と通信を行うことができる。

【0030】

エレベーター制御装置１００は、保守員２１が所持するメンテナンスコンピュータ３０と接続可能である。メンテナンスコンピュータ３０は、保守作業の際に使用する端末（たとえば、タブレット端末）であって、エレベーター制御装置１００と接続可能である。

【0031】

メンテナンスコンピュータ３０は、エレベーター制御装置１００と接続することで、エレベーター制御装置１００が保持する各種情報（信号）の取得、エレベーター制御装置１００の設定変更等を行うことができる。

【0032】

図１に戻り、保守員２１は、保守作業を開始する際に、メンテナンスコンピュータ３０をエレベーター制御装置１００に接続する。

【0033】

エレベーター制御装置１００は、メンテナンスコンピュータ３０との接続により、保守作業を開始したことを示す発報データを発報する。監視装置２００は、ネットワークを介して、この発報データを受信および記録する（詳細は後述する）。その後、本例では、保守員２１は、３階の乗場３３３において、点検作業を行っている。

【0034】

保守サービスの開始から保守結果報告の完了までには、複数の作業を行う必要がある。本実施の形態においては、複数の作業として、Ｎ個（たとえば、１０個）の作業を行う必要がある。Ｎ個の作業の各名称は、フロー１、フロー２、フロー３、・・・フローＮであるとする。

【0035】

詳しくは、図４～図６を用いて後述するが、フロー１は、保守員が行う保守作業である。フロー２は、事務員が行う事務作業である。フロー３は、確認者が行う確認作業である。そして、最後のフローＮは、報告者が行う報告作業である。報告者が報告作業を行うと、顧客は、ビル１０の顧客端末３００において、保守作業の報告書を閲覧することができる。

【0036】

フロー１～Ｎの入力作業は、保守会社端末４００を用いて行われる。保守会社端末４００は、複数の作業者がそれぞれ所持する複数の端末であってもよい。保守会社端末４００において入力されたデータは、ネットワークを介して監視装置２００の記憶部２１４に記憶される。

【0037】

監視装置２００は、フロー１～Ｎに関する遅延状況を予測する。予測した遅延状況は、保守会社端末４００に接続された表示装置、あるいは、監視装置２００に接続された表示装置で確認することができる。なお、監視装置２００および保守会社端末４００は、１台の装置によって構成するようにしてもよい。

【0038】

次に、監視システム１が実行する各種処理について説明する。図３は、第１実施形態に係る監視システム１の機能ブロック図の一例を示す図である。

【0039】

図３に示すように、監視システム１は、予測部１３０、表示部１３１、および生成部１３２を備える。記憶部２１４は、第１予測モデル１９１、実施履歴情報１９２、発報データ１９３、および過去履歴情報１９４などの情報を記憶する。なお、記憶部２１４が記憶する情報の一部または全部は、保守会社端末４００が備える記憶装置に記憶してもよいし、その他の外部装置（データベースサーバ等）が備える記憶装置に記憶するようにしてもよい。

【0040】

監視システム１が実行する各種処理は、たとえば、保守会社端末４００あるいは監視装置２００に接続された入力装置をユーザーが操作することで実行するようにしてもよい。監視システム１が実行する各種処理は、監視装置２００および保守会社端末４００のいずれかが実行してもよいし、一部を監視装置２００が実行し、残りを保守会社端末４００が実行してもよい。

【0041】

監視装置２００は、所定のＵＲＬにアクセスすることで保守会社端末４００から接続可能なＷＥＢサーバを備える装置であってもよい。所定のＵＲＬにアクセスすることで、フロー１～Ｎの入力画面と監視装置２００が予測した遅延状況とを、保守会社端末４００が起動するブラウザ上で表示させる構成にしてもよい。あるいは、保守会社端末４００に専用のソフトウェアをインストールして、フロー１～Ｎの入力画面および遅延状況を、保守会社端末４００の表示装置に表示させるようにしてもよい。

【0042】

第１実施形態において、予測部１３０は、予測モデルとして第１予測モデル１９１を用いて作業期間の遅延状態を予測する。ここで、「作業期間」は、保守サービスを開始してから保守結果報告が完了するまでの複数の作業（フロー１～Ｎ）に要する期間、つまり、保守サービス全体が完了するまでの期間を指す。

【0043】

予測モデル（第１予測モデル１９１）は、複数の作業（フロー１～Ｎ）の各々の基準期間と当該基準期間に対する実績期間との差分を用いて遅延状態を予測するモデルである。「基準期間」（「基準日数」とも称する）は、各作業（フロー）に要すると想定される日数を規定したものである。「実績期間」（「実績日数」とも称する）は、実際に各作業（フロー）に要した日数である。

【0044】

実績期間は、作業担当者に作業が割当てられて（フローの開始）から、作業担当者が作業を完了（フローの終了）するまでの期間を指す。たとえば、フロー１において、保守員が現場での点検作業に着手したタイミングがフローの開始とは限らない。保守員に作業が割当てられてから、実際に現場に赴くまでの期間も実績期間に含まれる。また、基準期間は、過去の実績期間の平均値から算出するようにしてもよいが、作業担当者の作業効率、あるいは月間の勤務時間などを加味して基準期間を補正してもよい。

【0045】

以下、フロー１の基準期間を「基準日数１」、フロー１の実績期間を「実績日数１」とそれぞれ称する。フロー２の基準期間を「基準日数２」、フロー２の実績期間を「実績日数２」とそれぞれ称する。以下同様であり、フローＮの基準期間を「基準日数Ｎ」、フローＮの実績期間を「実績日数Ｎ」とそれぞれ称する。たとえば、予測モデルは、以下の式で表すことができる。

【0046】

予測モデル＝－１×［Ｘ－（基準日数１＋基準日数２・・・＋基準日数Ｎ）＋｛（基準日数１－実績日数１）×ｍ１＋（基準日数２－実績日数２）×ｍ２・・・＋（基準日数Ｎ－実績日数Ｎ）×ｍＮ｝］＋Ｙ
本予測モデルを用いた場合、出力される予測結果が大きければ大きいほど、保守作業結果の報告完了までに大きな遅延が発生することが示される。

【0047】

ここで、Ｘは、保守作業を開始してから保守結果報告が完了するまでの目標日数である。ｍ１，ｍ２・・・ｍＮは、各フローを実施済みの場合に「１」を設定し、各フローが未実施の場合は「０」を設定する。未実施のフローには実績日数に「０」が設定される。実施済みのフローには、実績日数にデータがセットされる。

【0048】

Ｙは、後述の、発報データが発報されていないとき（この状態を「未発報状態」とも称する）に１００を設定し、発報データが発報されているとき（この状態を「発報済状態」とも称する）に「０」を設定する。なお、予測モデルに発報データを使用しなくてもよい。この場合、常にＹ＝０となる。

【0049】

生成部１３２は、複数の作業（フロー１～Ｎ）の各々の基準期間を用いて第１予測モデル１９１を生成する。具体的には、生成部１３２は、過去履歴情報１９４に基づき基準日数１～Ｎをそれぞれ決定する。そして、生成部１３２は、決定した基準日数１～Ｎを設定することで、第１予測モデル１９１を生成している。

【0050】

過去履歴情報１９４は、保守会社が管理する全ビルについての保守サービス全体の履歴情報である。生成部１３２は、ビルごと、ビル内の昇降機ごと、あるいは昇降機の機種ごとに、過去履歴情報１９４から実績日数１～Ｎのセットを取得可能である。

【0051】

たとえば、取得した複数の実績日数１の平均値を基準日数１として決定する。同様に、取得した複数の実績日数２の平均値を基準日数２として決定し、取得した複数の実績日数Ｎの平均値を基準日数Ｎとして決定する。

【0052】

ビル１０に関する全ての実績日数１～Ｎを取得して、基準日数１～Ｎを算出する場合は、ビル１０固有の事情に応じた予測モデルを構築することができる。ビルが大規模であれば作業時間が長くなるといった事情等を加味することができる。

【0053】

ビル１０に設置されたエレベーターのＡ号機に関する全ての実績日数１～Ｎを取得して、基準日数１～Ｎを算出する場合は、Ａ号機固有の事情に応じた予測モデルを構築することができる。エレベーターの機種Ｘに関する全ての実績日数１～Ｎを取得して、基準日数１～Ｎを算出する場合は、機種Ｘ固有の事情に応じた予測モデルを構築することができる。このようにすることで、昇降機ごとあるいは現場ごとなど、状況に応じた予測モデルを構築することができる。

【0054】

監視装置２００の記憶部２１４は、保守サービスを行ったときに昇降機が発報する発報データ１９３を記憶する。上述のように、エレベーター制御装置１００は、メンテナンスコンピュータ３０との接続を検出すると、保守サービスを開始したことを示す発報データを発報する。

【0055】

監視装置２００は、ネットワークを介して、発報された発報データを受信する。受信した発報データは、記憶部２１４に記憶される。予測部１３０は、遅延状態を予測する際に、記憶部２１４から発報データを取得する。

【0056】

予測部１３０は、未発報状態のときは発報済状態のときよりも遅延していると評価されるように遅延状態を予測する。具体的には、未発報状態においてＹ＝１００を設定し、発報済状態においてＹ＝０を設定している。このようにすることで、発報データにより保守作業が行われたことを確実に把握できるとともに、保守作業の実施に対する注意喚起（保守作業の実施の促進）を行うことができる。

【0057】

なお、予測モデルは、以下のように重みＷ１，Ｗ２を付加したものであってもよい。Ｗ１は、対象となる案件における過去のトラブル発生回数、あるいはエレベーター自体の故障履歴に基づき値を設定する（たとえば、トラブルが発生しやすい案件においては、Ｗ１の値を大きくする）。Ｗ２は、顧客のレスポンスの速さに基づき値を設定する（たとえば、顧客のレスポンスが早い案件においては、Ｗ２の値を小さく（負の値に）設定する）。

【0058】

予測モデル＝－１×［Ｘ－（基準日数１＋基準日数２・・・＋基準日数Ｎ）＋｛（基準日数１－実績日数１）×ｍ１＋（基準日数２－実績日数２）×ｍ２・・・＋（基準日数Ｎ－実績日数Ｎ）×ｍＮ｝］＋Ｙ＋Ｗ１＋Ｗ２
図４は、第１実施形態に係る監視システム１が実行する処理のフローチャートである。図４のフローチャートは、予測部１３０および表示部１３１が実行する処理を示す。以下、「ステップ」を単に「Ｓ」とも称する。

【0059】

図４に示すように、上記処理が開始すると、Ｓ１において、監視システム１の予測部１３０は、記憶部２１４が記憶する予測モデルと、複数の作業（フロー１～Ｎ）の各々の基準期間に対する実績期間とを取得し、処理をＳ２に進める。具体的に、予測部１３０は、第１予測モデル１９１と、実施履歴情報１９２から実績日数１～Ｎとを取得する。

【0060】

Ｓ２において、監視システム１の予測部１３０は、第１予測モデル１９１および複数の作業（フロー１～Ｎ）の各々の実績期間に基づき遅延状態を予測し、処理をＳ２に進める。具体的に、予測部１３０は、第１予測モデル１９１および実績日数１～Ｎに基づき遅延状態を予測する。

【0061】

Ｓ３において、監視システム１の表示部１３１は、予測部１３０が予測した遅延状態を表示し、処理を終了する。以下、図５～図９を用いて具体例を説明する。図５～図９は、第１実施形態に係る作業期間の遅延状態を説明するための図である。

【0062】

まず、図５，図６を用いて、遅延状態の算出イメージを説明する。ここでは、簡単のため、フローはフロー１～３で構成されるものとする。また、本例では、遅延状態の予測に発報データを使用しないものとする（常にＹ＝０）。

【0063】

まず、図５を用いて、遅延なく保守結果報告が完了した例を示す。ここでは、目標日数Ｘ＝２８日と設定されているものとする。「フロー１基準」は、フロー１の基準日数１を示し、基準日数１＝７日であるとする。「フロー２基準」は、フロー２の基準日数２を示し、基準日数２＝７日であるとする。「フロー３基準」は、フロー３の基準日数３を示し、基準日数３＝７日であるとする。

【0064】

計画通りに進行すると、２１日（＝７＋７＋７）で保守結果報告が完了する予定である。この日数を「完了予定日数」と表記する。図中の「予備」（「予備日数」とも称する）＝目標日数Ｘ－完了予定日数である。この場合、予備＝７日（＝２８－２１）である。言い換えると、この場合、目標日数Ｘからの遅延日数＝－７日である。遅延日数は、予測部１３０による遅延状態の予測結果である。

【0065】

ここで、フロー１を実施し、フロー１の実績日数１（フロー１実績）＝４、つまり、計画よりも３日（＝７－４）早くフロー１の作業が完了したとする。これにより、予備日数は３日増えて、１０日（＝７＋３）になる（遅延日数＝－１０日）。

【0066】

さらに、フロー２を実施し、フロー２の実績日数２（フロー２実績）＝４、つまり、計画よりも３日（＝７－４）早くフロー２の作業が完了したとする。これにより、予備日数は３日増えて、１３日（＝１０＋３）になる（遅延日数＝－１３日）。

【0067】

最後に、フロー３を実施し、フロー３の実績日数３（フロー３実績）＝４、つまり、計画よりも３日（＝７－４）早くフロー３の作業が完了したとする。これにより、予備日数は３日増えて、１６日（＝１６＋３）になる（遅延日数＝－１６日）。

【0068】

予測部１３０は、遅延状態として遅延日数を算出する。遅延状態には、実績期間（実績日数１～３）を含めてもよい。表示部１３１は、遅延日数を表示する。併せて、表示部１３１は、実績期間を表示してもよいし、図５に示されたような、全体の遅延状況が把握しやすくなるような図を表示してもよい。このようにすることで、フロー開始前、フロー１実施後、フロー２実施後の遅延状態（遅延予想）を把握することができる。

【0069】

次に、図６を用いて最終的に遅延が発生した例を示す。図５と同様に、目標日数Ｘ＝２８日、基準日数１＝７日、基準日数２＝７日、基準日数３＝７日であるとする。完了予定日数＝２１日であり、予備（予備日数）＝７日である（遅延日数＝－７日）。

【0070】

ここで、フロー１を実施し、フロー１の実績日数１（フロー１実績）＝１０、つまり、フロー１の作業が計画よりも３日遅延（＝１０－７）したとする。これにより、予備日数は３日減って、４日（＝７－３）になる（遅延日数＝－４日）。

【0071】

さらに、フロー２を実施し、フロー２の実績日数１（フロー１実績）＝１２、つまり、フロー１の作業が計画よりも５日遅延（＝１２－７）したとする。これにより、予備日数は５日減って、－１日（＝４－５）になる（遅延日数＝１日）。このように、遅延日数＞０となった場合は、目標日数Ｘからの遅延が発生することが予想される。つまり、ＳＬＡ契約を遵守できない可能性がある。

【0072】

最後に、フロー３を実施し、フロー３の実績日数３（フロー３実績）＝９、つまり、フロー３の作業が計画よりも２日遅延（＝９－７）したとする。これにより、予備日数は２日減って、－３日（＝－１－２）になる。すなわち、目標日数Ｘからの遅延日数＝３日となっている。

【0073】

本例では、最終作業工程であるフロー３の実施前の、フロー２の実施時点で、目標日数Ｘからの遅延が１日発生することが予想される。このため、目標日数Ｘ内で作業を完了させるためには、フロー３の作業を１日短縮させて、実績日数３＝６日（＝７－１）となるよう、作業計画を立てる必要がある。

【0074】

このように、本実施の形態では、保守サービス全体に関する作業の遅延状態を常に把握することができる。これにより、途中段階において遅延に対する注意喚起を行うことができ、作業の遅延を抑制することができる。

【0075】

次に、図７～図９を用いて、具体例について説明する。ここでは、フローはフロー１～Ｎで構成されるとする。また、本例では、遅延状態の予測に発報データを使用するものとする。

【0076】

図７は、全てのフローが実施されていない状態である。各フローには、「作業内容」、「担当」、「基準日数」および「実績日数」といった情報が設定される。この状態においては、あらかじめ「作業内容」、「担当」および「基準日数」が設定されているが、「実績日数」は設定されていない。

【0077】

フロー１は、保守員が行うエレベーターの保守作業である。フロー１の「作業内容」として「エレベーター保守」、「担当」として「保守員」、「基準日数（基準日数１）」として「３日」がそれぞれ設定されている。ただし、全てのフローが未実施であるため、現状「実績日数（実績日数１）」は設定されていない。

【0078】

フロー２は、事務員が行う事務作業である。具体的には、保守員が行った保守作業の結果を入力する。フロー２の「作業内容」として「保守結果入力」、「担当」として「事務員」、「基準日数（基準日数２）」として「１日」がそれぞれ設定されている。「実績日数（実績日数２）」は設定されていない。

【0079】

フロー３は、確認者が行う確認作業である。具体的には、保守員および事務員の上長が、入力された保守結果の内容を確認および検認する作業である。フロー３の「作業内容」として「確認作業」、「担当」として「確認者（上長）」、「基準日数（基準日数３）」として「３日」がそれぞれ設定されている。「実績日数（実績日数３）」は設定されていない。

【0080】

最後のフローＮは、報告者が行う報告作業である。具体的には、報告書を顧客端末３００から閲覧可能な状態にする作業である。フローＮの「作業内容」として「報告作業」、「担当」として「報告者」、「基準日数」として「３日」がそれぞれ設定されている。「実績日数」は設定されていない。

【0081】

上記例は、フローの一例であるが、これに限らない。確認者として、複数のフローにより複数の人物が検認するようにしてもよいし、作業工程をさらに細分化してもよい。報告作業は、サーバへの報告書のアップロード作業、アップロードに対する承認作業、アップロードした報告書の公開作業（この時点で顧客端末３００から閲覧可能になる）にフローを分割してもよい。

【0082】

図５の状態において、基準日数１＝３、基準日数２＝１・・・基準日数Ｎ＝３、ｍ１＝０、ｍ２＝０・・・、ｍＮ＝０、Ｙ＝１００（未発報状態）である。このため、予測モデル＝－１×［２８－（３＋１・・・＋３）＋｛（３－実績日数１）×０＋（１－実績日数２）×０・・・＋（３－実績日数Ｎ）×０｝］＋１００となる。

【0083】

ここで、基準日数１～Ｎの総和が２８（つまり、Ｘと一致する）とする。この場合、予測モデル（第１予測モデル１９１）＝１００となる。つまり、第１予測モデル１９１による推定結果として、遅延＝１００が得られる。

【0084】

上述のように、未発報状態ではＹ＝１００が設定され、発報済状態ではＹ＝０が設定される。このように、未発報状態において大きな数値を設定することで、保守作業（フロー１）の実施の促進を行うことができる。

【0085】

ここで、フロー１（保守作業）が実施され、その実績日数が２日であったとする。これにより、図８に示すように、フロー１の「実績日数（実績日数１）」として「２日」が設定される。また、保守作業の実行により、発報データが発報される。これにより、発報状態による遅延評価は、Ｙ＝－１００からＹ＝０に変化する。

【0086】

予測モデル＝－１×［０＋｛（３－実績日数１）×１＋（１－実績日数２）×０・・・＋（３－実績日数Ｎ）×０｝］＋０＝－（３－実績日数１）となる。実績日数１＝２である。このため、第１予測モデル１９１による推定結果として、遅延＝－（３－２）＝－１が得られる。

【0087】

次に、フロー２（保守結果入力）が実施され、その実績日数が３日であったとする。これにより、図７に示すように、フロー２の「実績日数（実績日数２）」として「３日」が設定される。

【0088】

予測モデル＝－（３－実績日数１）－（１－実績日数２）となる。実績日数１＝２、実績日数２＝３である。このため、第１予測モデル１９１による推定結果として、遅延＝－（３－２）－（１－３）＝１が得られる。図示しないが、フロー３～Ｎが実施された場合も、上記同様に推定結果が更新される。

【0089】

表示部１３１は、遅延（遅延日数）を表示する。併せて、表示部１３１は、実績期間を表示してもよいし、図７～図９に示されたような、全体の遅延状況が把握しやすくなるような図を表示してもよい。このようにすることで、フロー開始前、各フロー実施後の遅延状態（遅延予想）を把握することができる。

【0090】

以上説明したように、保守サービス全体に関する作業の遅延状態を表示させることで、保守サービス全体についての作業の遅延に対する注意喚起を行うことができ、作業の遅延を抑制することができる。また、遅延状態として、フローごとの基準日数、実績日数および遅延日数を表示することで、保守を実施してから顧客に対して保守結果を報告するまでの流れを可視化して、監視することができる。以上のように構成することで、ＳＬＡを規定した保守サービスにおいて、保守サービス全体を対象としたＳＬＡの順守率を向上させて顧客満足度を高めることができる。

【0091】

［第２実施形態］
以下、第２実施形態について説明する。第２実施形態の説明においては、第１実施形態と異なる点について説明し、共通する部分については説明を省略する。

【0092】

図１０は、第２実施形態に係る監視システム１の機能ブロック図の一例を示す図である。第１実施形態においては、監視システム１は、予測部１３０、表示部１３１、および生成部１３２を備え、記憶部２１４は、第１予測モデル１９１、実施履歴情報１９２、発報データ１９３、および過去履歴情報１９４を記憶するように構成した。

【0093】

これに対して、第２実施形態においては、図１０に示すように、監視システム１は、第１更新部１３４および第２更新部１３５をさらに備える。記憶部２１４は、第２予測モデル１９７、点検情報１９５、および全社点検情報１９６をさらに記憶する。

【0094】

第２実施形態においては、予測モデルとして、第２予測モデル１９７をさらに含む。ここで、第１予測モデル１９１は、保守サービス中にトラブルが発生しなかった場合において遅延状態を予測するモデルである。第２予測モデル１９７は、保守サービス中にトラブルが発生した場合において遅延状態を予測するモデルである。トラブルが発生した場合は、点検情報１９５にトラブル情報が記録される。

【0095】

なお、第１実施形態における第１予測モデル１９１は、保守サービス中にトラブルが発生しなかった場合において遅延状態を予測するモデルであってもよいし、作業期間中にトラブルが発生しなかった場合も発生した場合も含んで遅延状態を予測するモデルであってもよい。

【0096】

以下、フローチャートに基づき処理の流れを説明する。図１１は、第２実施形態に係る監視システム１が実行する処理のフローチャートである。図１１に示すように、エレベーター制御装置１００が実行する処理が開始すると、Ｓ２１の処理を実行する。

【0097】

監視システム１の予測部１３０は、Ｓ２１において、保守サービス中にトラブルが発生したか否かを判定する。トラブルが発生したか否かは、点検情報１９５に記録されたトラブル情報に基づき判断される。点検情報１９５には、トラブル情報を含む定期点検の結果が蓄積されている。

【0098】

予測部１３０は、保守サービス中にトラブルが発生したと判定した場合（Ｓ２１でＹＥＳ）、処理をＳ２３に進める。予測部１３０は、保守サービス中にトラブルが発生したと判定しなかった場合（Ｓ２１でＮＯ）、処理をＳ２２に進める。

【0099】

Ｓ２２において、予測部１３０は、予測モデルとして第１予測モデル１９１を選択し、処理をＳ２３に進める。監視システム１の第１更新部１３４は、Ｓ２３において、第１予測モデル１９１の更新が要求されたか否かを判定する。

【0100】

第１予測モデル１９１の更新は、入力装置によるユーザーからの入力により要求が行われるように構成してもよいし、所定期間（たとえば、４ヶ月）ごとに要求が行われるようにしてもよい。また、常に更新要求を行うようにしてもよい。このようにした場合、常に第１予測モデル１９１が更新されることになる。

【0101】

第１更新部１３４は、第１予測モデル１９１の更新が要求されたと判定した場合（Ｓ２３でＹＥＳ）、処理をＳ２４に進める。第１更新部１３４は、第１予測モデル１９１の更新が要求されたと判定しなかった場合（Ｓ２３でＮＯ）、処理をＳ２８に進める。

【0102】

Ｓ２４において、第１更新部１３４は、過去の保守サービスの結果に基づき、第１予測モデル１９１を更新し、処理をＳ２８に進める。第１更新部１３４の処理内容は、生成部１３２の処理内容と同じであり、過去履歴情報１９４に基づき基準日数１～Ｎをそれぞれ決定する。そして、第１更新部１３４は、決定した基準日数１～Ｎを設定することで、第１予測モデル１９１を更新している。このようにすることで、過去の保守サービスの実施状況に応じて予測モデルを更新することができる。

【0103】

Ｓ２５において、予測部１３０は、予測モデルとして第２予測モデル１９７を選択し、処理をＳ２６に進める。監視システム１の第２更新部１３５は、Ｓ２６において、第２予測モデル１９７の更新が要求されたか否かを判定する。

【0104】

第２予測モデル１９７の更新は、入力装置によるユーザーからの入力により要求が行われるように構成してもよいし、所定期間（たとえば、４ヶ月）ごとに要求が行われるようにしてもよい。また、常に更新要求を行うようにしてもよい。このようにした場合、トラブル発生時は常に第２予測モデル１９７が更新されることになる。

【0105】

第２更新部１３５は、第２予測モデル１９７の更新が要求されたと判定した場合（Ｓ２６でＹＥＳ）、処理をＳ２７に進める。第２更新部１３５は、第２予測モデル１９７の更新が要求されたと判定しなかった場合（Ｓ２６でＮＯ）、処理をＳ２８に進める。

【0106】

Ｓ２７において、第２更新部は、保守サービス中にトラブルが発生した場合における、過去の保守サービスの結果に基づき第２予測モデル１９７を更新し、処理をＳ２８に進める。

【0107】

具体的には、第２更新部は、全社点検情報１９６に基づき、第２予測モデル１９７を更新する。全社点検情報１９６は、各ビルのエレベーターに関して、トラブルが発生した場合における過去の保守サービスの結果を蓄積した情報である。このようにすることで、トラブル発生時の過去の保守サービスの実施状況に応じて予測モデルを更新することができる。

【0108】

トラブルが発生した場合は、フロー１の保守作業に時間がかかるだけでなく、後工程の作業も時間がかかる可能性が高い。上記のように、予測モデルを切り替えることで、全体としてどの程度の遅延が発生するか把握することができるため、トラブル発生状況下における遅延に対処しやすくなる。

【0109】

Ｓ２８において、予測部１３０は、選択された予測モデルを用いて遅延状態を予測し、処理をＳ２９に進める。具体的には、予測モデルとして第１予測モデル１９１が選択された場合は、第１予測モデル１９１および実績日数１～Ｎに基づき遅延状態を予測する。一方で、予測モデルとして第２予測モデル１９７が選択された場合は、第２予測モデル１９７および実績日数１～Ｎに基づき遅延状態を予測する。Ｓ２９において、表示部１３１は、予測部１３０が予測した遅延状態を表示し、処理を終了する。

【0110】

以上説明したように、予測部１３０は、保守サービス中にトラブルが発生しなかった場合は、第１予測モデル１９１を用いて遅延状態を予測する。予測部１３０は、保守サービス中にトラブルが発生した場合は、第２予測モデル１９７を用いて遅延状態を予測する。このようにすることで、トラブル発生状況に適合した遅延状態を把握することができ、トラブル発生状況下における作業の遅延を抑制することができる。以上説明したように構成することで、ＳＬＡを規定した保守サービスにおいて、保守サービス全体を対象としたＳＬＡの順守率を向上させて、より顧客満足度を高めることができる。

【0111】

［主な構成および効果］
以下、前述した実施の形態の主な構成および効果を説明する。

【0112】

（１） 監視システム１は、昇降機の保守サービスの提供を監視する。監視システム１は、記憶部２１４と、予測部１３０と、表示部１３１とを備える。記憶部２１４は、保守サービスを開始してから保守サービスの実施結果の顧客に対する報告が完了するまでの複数の作業に要する作業期間の遅延状態を予測する第１予測モデル１９１（第２予測モデル１９７）と、複数の作業の各々の基準期間に対する実績期間とを記憶する。予測部１３０は、第１予測モデル１９１および複数の作業の各々の実績期間に基づき遅延状態を予測する。表示部１３１は、予測部１３０が予測した遅延状態を表示する。第１予測モデル１９１は、複数の作業の各々の基準期間と当該基準期間に対する実績期間との差分を用いて遅延状態を予測するモデルである。このように、保守サービス全体に関する作業の遅延状態を表示させることで、保守サービス全体についての作業の遅延に対する注意喚起を行うことができ、作業の遅延を抑制することができる。これにより、ＳＬＡを規定した保守サービスにおいて、保守サービス全体を対象としたＳＬＡの順守率を向上させて顧客満足度を高めることができる。

【0113】

（２） 監視システム１は、生成部１３２をさらに備える。生成部１３２は、複数の作業の各々の基準期間を用いて第１予測モデル１９１を生成する。これにより、昇降機ごとあるいは現場ごとなど、状況に応じた予測モデルを構築することができる。

【0114】

（３） 記憶部２１４は、保守サービスを行ったときに昇降機が発報する発報データをさらに記憶する。予測部１３０は、発報データが発報されていないときは、発報データが発報されているときよりも、遅延していると評価されるように遅延状態を予測する。このようにすることで、発報データにより保守作業が行われたことを確実に把握できるとともに、保守作業の実施に対する注意喚起を行うことができる。これにより、ＳＬＡを規定した保守サービスにおいて、保守サービス全体を対象としたＳＬＡの順守率を向上させて顧客満足度を高めることができる。

【0115】

（４） 記憶部２１４は、過去の保守サービスの結果をさらに記憶する。監視システム１は、過去の保守サービスの結果に基づき、第１予測モデル１９１を更新する第１更新部をさらに備える。このようにすることで、過去の保守サービスの実施状況に応じて予測モデルを更新することができる。これにより、ＳＬＡを規定した保守サービスにおいて、保守サービス全体を対象としたＳＬＡの順守率を向上させて顧客満足度を高めることができる。

【0116】

（５） 予測モデルは、保守サービス中にトラブルが発生しなかった場合において遅延状態を予測する第１予測モデル１９１と、保守サービス中にトラブルが発生した場合において遅延状態を予測する第２予測モデル１９７とを含む。予測部１３０は、保守サービス中にトラブルが発生しなかった場合は、第１予測モデル１９１を用いて遅延状態を予測する。予測部１３０は、保守サービス中にトラブルが発生した場合は、第２予測モデル１９７を用いて遅延状態を予測する。このようにすることで、トラブル発生状況に適合した遅延状態を把握することができ、トラブル発生状況下における作業の遅延を抑制することができる。これにより、ＳＬＡを規定した保守サービスにおいて、保守サービス全体を対象としたＳＬＡの順守率を向上させて顧客満足度を高めることができる。

【0117】

（６） 監視システム１は、第２更新部をさらに備える。第２更新部は、保守サービス中にトラブルが発生した場合における、過去の保守サービスの結果に基づき第２予測モデル１９７を更新する。このようにすることで、トラブル発生時の過去の保守サービスの実施状況に応じて予測モデルを更新することができる。これにより、ＳＬＡを規定した保守サービスにおいて、保守サービス全体を対象としたＳＬＡの順守率を向上させて顧客満足度を高めることができる。

【0118】

（７） 監視方法は、昇降機の保守サービスの提供を監視する方法である。監視方法は、保守サービスを開始してから保守サービスの実施結果の顧客に対する報告が完了するまでの複数の作業に要する作業期間の遅延状態を予測する第１予測モデル１９１（第２予測モデル１９７）を記憶するステップと、複数の作業の各々の基準期間に対する実績期間を記憶するステップと、第１予測モデル１９１および複数の作業の各々の実績期間に基づき遅延状態を予測するステップと、予測するステップが予測した遅延状態を表示するステップとを備える。第１予測モデル１９１は、複数の作業の各々の基準期間と当該基準期間に対する実績期間との差分を用いて遅延状態を予測するモデルである。このように、保守サービス全体に関する作業の遅延状態を表示させることで、保守サービス全体についての作業の遅延に対する注意喚起を行うことができ、作業の遅延を抑制することができる。これにより、ＳＬＡを規定した保守サービスにおいて、保守サービス全体を対象としたＳＬＡの順守率を向上させて顧客満足度を高めることができる。

【0119】

今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本開示の範囲は上記した説明ではなくて請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。

【符号の説明】

【0120】

１，１ａ 監視システム、１０ ビル、２０ 情報センター（保守会社）、２１ 保守員、３０ メンテナンスコンピュータ、４０ 支店（保守会社）、１００ エレベーター制御装置、１１１，２１１ ＣＰＵ、１１２，２１２ ＲＯＭ、１１３，２１３ ＲＡＭ、２１４ 記憶部、１１５，２１５ 通信インターフェイス、１１６，２１６ Ｉ／Ｏインターフェイス、１３０ 予測部、１３１ 表示部、１３２ 生成部、１３４ 第１更新部、１３５ 第２更新部、１９０ 予測モデル、１９１ 第１予測モデル、１９２ 実施履歴情報、１９３ 発報データ、１９４ 過去履歴情報、１９５ 点検情報、１９６ 全社点検情報、１９７ 第２予測モデル、２００ 監視装置、３００ 顧客端末、３４１ かご、３５１ 昇降路、３３１～３３４ 乗場、４００ 保守会社端末。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】