保守運営システム
【課題】障害発生以前に得られる情報を利用して、保守サービスの効率化を図る。
【解決手段】保守運営システム１００は、ユーザシステム２００に接続されている遠隔監視装置２０１からの情報に基づきユーザシステム２００での障害発生確率を計算するユーザ状況管理システム１０１から障害発生確率情報を入力し、障害発生確率に基づき、サービス員を割当てるユーザシステム２００を選択し、サービス員の派遣スケジュールを参照し、割当て対象として選択したユーザシステム２００にサービス員を割当てて、サービス員の派遣スケジュールを生成する。
【解決手段】保守運営システム１００は、ユーザシステム２００に接続されている遠隔監視装置２０１からの情報に基づきユーザシステム２００での障害発生確率を計算するユーザ状況管理システム１０１から障害発生確率情報を入力し、障害発生確率に基づき、サービス員を割当てるユーザシステム２００を選択し、サービス員の派遣スケジュールを参照し、割当て対象として選択したユーザシステム２００にサービス員を割当てて、サービス員の派遣スケジュールを生成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、保守運営システムに関し、特に、保守対象装置に対するサービス員の派遣スケジュールの管理、保守のための部品の管理、保守対象装置に対する保守サービス料金の管理に関する。
【背景技術】
【０００２】
従来、コンピュータシステムにシステム障害が発生した場合、コンピュータシステムのユーザが、障害の発生した箇所に応じて、保守サービス提供会社に電話や電子メール等で連絡して、障害箇所の修理や交換をしてもらっていた。
【０００３】
障害発生から、修理を行うまでの時間を短くするためには、システムを監視する機能をユーザ拠点に設置し、障害発生時にシステム監視機能が自動的に携帯電話等で保守サービス提供会社に連絡するという方法もある。
また、障害発生以前にその兆候が検出できるような装置（ハードディスク装置、ＵＰＳ（Ｕｎｉｎｔｅｒｒｕｐｔｉｂｌｅ Ｐｏｗｅｒ Ｓｕｐｐｌｙ）装置など）の場合、その兆候を検出した時点で、ユーザや保守サービス会社に連絡することで、障害の発生以前に対応することも可能である（例えば、特許文献１、特許文献２）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−１５０４０６号公報
【特許文献２】特開２００９−２１７７７０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
これらの従来システムは、ユーザ側からみるとシステムの可用性があがっているが、保守サービス提供会社から見ると、修理対応の時期が前にずれるだけであり、保守サービス全体としてのメリットはほとんどないのが実情である（可用性が上がることで、ユーザの満足度が上がる等のビジネス上のメリットはある）。
【０００６】
この発明は、このような事情に鑑み、障害発生以前に得られる情報を利用して、保守サービスの効率化を図ることを主な目的とする。
【課題を解決するための手段】
【０００７】
本発明に係る保守運営システムは、
保守対象装置に対するサービス員の派遣スケジュールを管理する保守運営システムであって、
サービス員の派遣スケジュールが示される派遣スケジュール情報を記憶する派遣スケジュール情報記憶部と、
保守対象装置での障害発生確率を計算する障害発生確率計算装置から、保守対象装置ごとに、保守対象装置での障害発生確率が示される障害発生確率情報を入力する第１の入力部と、
前記障害発生確率情報に示される保守対象装置ごとの障害発生確率に基づいてサービス員を割当てる保守対象装置を選択し、前記派遣スケジュール情報に示される派遣スケジュールを参照し、割当て対象として選択した保守対象装置にサービス員を割当てて、サービス員の派遣スケジュールを生成する派遣スケジュール生成部とを有することを特徴とする。
【発明の効果】
【０００８】
本発明では、障害発生確率に基づいてサービス員を割当てる保守対象装置を選択し、派遣スケジュールを生成するため、障害発生確率が高い保守対象装置に絞ってサービス員を派遣することができ、保守サービスの効率化を図ることができる。
【図面の簡単な説明】
【０００９】
【図１】実施の形態１〜３に係るシステム構成例を示す図。
【図２】実施の形態１に係るユーザ状況管理システムと保守運営システムの構成例を示す図。
【図３】実施の形態１に係る保守運営システムの動作例を示すフローチャート図。
【図４】実施の形態１に係るサービス員スケジュールテーブルの例を示す図。
【図５】実施の形態２に係るユーザ状況管理システムと保守運営システムの構成例を示す図。
【図６】実施の形態２に係る保守運営システムの動作例を示すフローチャート図。
【図７】実施の形態２に係る部品ユーザ管理テーブルの例を示す図。
【図８】実施の形態２に係る部品在庫テーブルの例を示す図。
【図９】実施の形態３に係るユーザ状況管理システムと保守運営システムの構成例を示す図。
【図１０】実施の形態３に係る保守運営システムの動作例を示すフローチャート図。
【図１１】実施の形態１〜３に係る保守運営システムのハードウェア構成例を示す図。
【発明を実施するための形態】
【００１０】
実施の形態１〜３において、遠隔監視システムをユーザ側に設置し、保守サービス会社に設置し、遠隔監視システムと保守運営システムとを連携することで、保守サービス全体の効率化を図る構成を説明する。
【００１１】
図１は、実施の形態１〜３に係るシステム構成例を示す。
図１において、保守サービス会社１には、保守運営システム１００と、ユーザ状況管理システム１０１が配置される。
ユーザ拠点２には、ユーザシステム２００と、遠隔監視装置２０１が配置される。
ユーザ状況管理システム１０１と遠隔監視装置２０１はネットワーク３００で接続されている。
図１では、ユーザ拠点２は１つしか図示していないが、ユーザ拠点２は複数存在するものとする。
【００１２】
ユーザ拠点２に配置されているユーザシステム２００は、保守サービス会社１が保守の対象とする保守対象装置である。
遠隔監視装置２０１は、ユーザシステム２００の状況を監視する。
遠隔監視装置２０１は、ネットワーク３００を介して、ユーザシステム２００の状況を示すユーザ情報を保守サービス会社１内のユーザ状況管理システム１０１に送信する。
保守サービス会社１では、ユーザ情報をユーザ状況管理システム１０１にて処理し、その結果を保守運営システム１００に通知する。
【００１３】
遠隔監視装置２０１は、ユーザシステム２００の障害の発生を検出するだけではなく、ユーザシステム２００のハードディスクやＵＰＳ等の稼働状況、エラー率、温度、湿度など、障害発生前に検出できる情報も採取可能である。
また、ユーザシステムの累計稼働時間など、障害発生の頻度を検出できる情報も採取可能である。
【００１４】
ユーザ状況管理システム１０１は、遠隔監視装置２０１からのユーザ情報に基づき、保守対象装置であるユーザシステムの障害発生確率を計算することができる。
ユーザ状況管理システム１０１は、障害発生確率計算装置の例に相当する。
【００１５】
保守運営システム１００は、ユーザ状況管理システム１０１で計算された障害発生確率に基づき、ユーザシステムに対するサービス員の派遣スケジュールの管理、保守のための部品の管理、ユーザシステムに対する保守サービス料金の管理を行うことができる。
実施の形態１では、保守運営システム１００がサービス員の派遣スケジュールの管理を行う例を説明する。
実施の形態２では、保守運営システム１００が保守のための部品の配分の管理を行う例を説明する。
実施の形態３では、保守運営システム１００が保守サービス料金の管理を行う例を説明する。
【００１６】
実施の形態１．
保守サービス会社は、通常は、障害発生時にサービス員を派遣するが、障害の発生が予想できない場合は、想定される障害発生確率に基づいて派遣員の人数を準備する。
この場合、障害の発生が重なると、派遣すべきサービス員の人数が派遣可能な人数を超えてしまい、結果としてサービスの質を下げることになる。
サービス員の数を多数揃えると、障害が発生していない時に作業をしていないサービス員が増えることになり、人件費が増えることになる。
本実施の形態では、遠隔監視装置２０１からの情報で、障害発生より前に障害を検知することができ、その場合は、障害発生時より緊急度が低いため、障害が発生しているシステムへ優先的に派遣員を派遣し、作業完了後に、障害を予想検知したシステムに派遣することで、派遣員を効率的に配置することができる。
これらは保守運営システム１００によりスケジューリングされる。
以下、詳細に説明する。
【００１７】
図２は、本実施の形態に係るユーザ状況管理システム１０１と保守運営システム１００の構成例を示す。
【００１８】
ユーザ状況管理システム１０１において、障害発生確率計算部１０１１は、遠隔監視装置２０１からユーザ情報を受信し、受信したユーザ情報と障害履歴管理部１０１２で管理されているユーザシステム２００における障害履歴および過去の類似システムや類似部品の障害発生情報などに基づき、ユーザシステム２００の障害発生確率を計算する。
なお、障害発生確率計算部１０１１による障害発生確率の計算は、既存の技術により実現可能であるため、計算手順の詳細な説明は省略する。
また、障害発生確率計算部１０１１は、ユーザシステム２００の障害発生確率を示す障害発生確率情報を保守運営システム１００に出力する。
なお、障害発生確率計算部１０１１は、ユーザシステム２００における障害発生を通知する障害発生通知を遠隔監視装置２０１から受信した場合には、即座に保守運営システム１００に転送する。
【００１９】
保守運営システム１００において、入力部１００１は、ユーザ状況管理システム１０１から障害発生確率情報を入力する。
また、入力部１００１は、ユーザ状況管理システム１０１から障害発生通知を入力する。
入力部１００１は、第１の入力部及び第２の入力部の例である。
【００２０】
サービス員スケジュールテーブル記憶部１００３は、サービス員の派遣スケジュールが示されるサービス員スケジュールテーブルを記憶する。
サービス員スケジュールテーブルは、例えば、図４に示すテーブルである。
サービス員スケジュールテーブルは、日付ごと（図４の例では、２０１１年３月１５日）に、サービス員ＩＤに対して、派遣先の割当て状況と、派遣先のユーザのユーザＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）、派遣先のユーザのユーザシステムＩＤが対応付けられている。
サービス員スケジュールテーブルは派遣スケジュール情報の例に相当し、サービス員スケジュールテーブル記憶部１００３は派遣スケジュール情報記憶部の例に相当する。
【００２１】
サービス員スケジューリング部１００２は、サービス員スケジュールテーブルに示されるサービス員の派遣スケジュールと、ユーザ状況管理システム１０１からの障害発生確率情報に示されるユーザシステム２００ごとの障害発生確率とに基づき、ユーザシステム２００ごとにサービス員を割当てる。
より具体的には、サービス員スケジューリング部１００２は、障害発生確率情報に示される障害発生確率が所定の閾値以上のユーザは、「障害発生の可能性が高い」ユーザとして分類し、障害発生確率が所定の閾値未満のユーザは、「障害発生の可能性が低い」ユーザに分類される。
そして、サービス員スケジューリング部１００２は、「障害発生の可能性が高い」とされたユーザのユーザシステム２００に派遣するサービス員を決定する。
なお、以下では、「障害発生の可能性が高い」を「可能性高い」とも表記し、「障害発生の可能性が低い」を「可能性低い」とも表記する。
また、サービス員スケジューリング部１００２は、ユーザ状況管理システム１０１から障害発生通知が入力された場合は、障害が発生したユーザシステム２００（障害発生保守対象装置）に対して優先してサービス員を割当てて、派遣スケジュールを生成する。
また、サービス員スケジューリング部１００２は、障害発生通知が入力された際に、サービス員スケジュールテーブルにおいて派遣先が未割当のサービス員が存在しなければ、いずれかのサービス員の割当てを解除し、当該サービス員を障害が発生したユーザシステム２００に割当てる。
更に、サービス員スケジューリング部１００２は、障害発生通知が入力された際にサービス員の割当てが解除されたユーザシステム２００に対して優先してサービス員を割当てる。
サービス員スケジューリング部１００２は、派遣スケジュール生成部の例に相当する。
【００２２】
出力部１００４は、サービス員スケジューリング部１００２により生成されたサービス員スケジュールテーブルを、保守サービス会社の社員に対して出力する。
【００２３】
次に、本実施の形態に係る保守運営システム１００の動作を説明する。
なお、本実施の形態では、説明の簡明化のために、サービス員は各ユーザに対して一名のみ派遣され、作業は一日かかるものと仮定する。
また、各ユーザからの情報により、ユーザ状態として「障害発生」、「障害発生の可能性が高い」、「障害発生の可能性が低い」に分類されるものとする。
つまり、遠隔監視装置２０１より障害が発生されたと通知されたユーザは、ユーザ状態が「障害発生」に分類され、前述したように障害発生確率が所定の閾値以上のユーザは、ユーザ状態が「障害発生の可能性が高い」に分類され、障害発生確率が所定の閾値未満のユーザは、ユーザ状態が「障害発生の可能性が低い」に分類される。
ユーザからの情報は、「障害発生」時は、即時に通知される。
「障害発生」でない場合は、一日一度通知されるものとする。
サービス員の配置は、「障害発生」の通知が来た場合、及び一日一回計算されるものとする。
サービス員のスケジュールは、図４に示すように、「障害発生」、「可能性高い」、「空き」のいずれかである。
「障害発生」は、障害が発生したユーザにサービス員が派遣されることを示しており、「可能性高い」は、障害の発生の可能性が高いユーザにサービス員が派遣されることを示しており、「空き」は、派遣先のユーザが決まっていないことを示している。
【００２４】
以上を前提にして、図３を参照して本実施の形態に係る保守運営システム１００の動作例を説明する。
【００２５】
ユーザシステム２００において障害が発生し、遠隔監視装置２０１から発信された障害発生通知が、ユーザ状況管理システム１０１を経由して入力部１００１に入力された際に（Ｓ１０１でＹＥＳ）、サービス員スケジューリング部１００２が、サービス員スケジュールテーブル記憶部１００３から翌日のサービス員スケジュールテーブルを取得し、翌日のサービス員のスケジュールを確認する（Ｓ１０２）。
割当て状況が「空き」になっているサービス員がいれば（Ｓ１０３でＹＥＳ）、サービス員スケジューリング部１００２は、そのサービス員を障害が発生したユーザシステム２００への派遣員にアサインして終了する（Ｓ１０４）。
具体的には、サービス員スケジューリング部１００２は、サービス員スケジュールテーブルにおいて、対象となるサービス員の割当て状況を「空き」から「障害発生」に変更し、また、派遣先のユーザＩＤとユーザシステムＩＤをユーザＩＤ欄とユーザシステムＩＤ欄に書き込む。
【００２６】
一方、割当て状況が「空き」になっているサービス員がいなければ（Ｓ１０３でＮＯ）、サービス員スケジュールテーブル内で割当て状況が「可能性高い」になっているサービス員を検索する（Ｓ１０５）。
そして、「可能性高い」となっているサービス員がいた場合に（Ｓ１０５でＹＥＳ）、そのサービス員の現在の割当てを解除し、そのサービス員を障害が発生しているユーザに割当て、そのサービス員に割り当てられていた「可能性高い」ユーザへの対応は、翌日以降に再度スケジューリングする（Ｓ１０６）。
つまり、サービス員スケジューリング部１００２は、そのサービス員の割当て状況を「気可能性高い」から「障害発生」に変更し、現在ユーザＩＤ欄とユーザシステムＩＤ欄に記述されているユーザＩＤとユーザシステムＩＤ（「可能性高い」ユーザＩＤとユーザシステムＩＤ）を再スケジュール用のキューに登録し、サービス員スケジュールテーブルのユーザＩＤ欄とユーザシステムＩＤ欄を障害が発生しているユーザのユーザＩＤとユーザシステムＩＤに書き換える。
再スケジュールは、Ｓ１０９以降の処理により行われる。
【００２７】
Ｓ１０５の判定にて、割当て状況が「可能性高い」になっているサービス員がなければ（Ｓ１０５でＮＯ）、サービス員スケジューリング部１００２は、更に翌日のサービス員スケジュールテーブルを取得し、サービス員のスケジュールを確認する（Ｓ１０７）。
以降は、Ｓ１０２からの処理を繰り返して、派遣するサービス員を決定する。
【００２８】
障害発生通知が入力されずにサービス員の配置を決定するタイミングになった際に、ユーザ状況管理システム１０１から通知された障害発生確率が所定の閾値以上のユーザシステム２００があれば、「障害発生の可能性が高い」ユーザシステム２００が存在するので（Ｓ１０８でＹＥＳ）、サービス員スケジューリング部１００２は、サービス員スケジュールテーブル記憶部１００３から翌日のサービス員スケジュールテーブルを取得し、翌日のサービス員のスケジュールを確認する（Ｓ１０９）。
なお、Ｓ１０８の判断において障害発生確率が閾値以上のユーザシステム２００が存在しなくても、前述したＳ１０６において割当てが解除されて、再スケジュール用キューに登録されたユーザシステム２００が存在する場合には、Ｓ１０９以降の処理が実施される。
また、Ｓ１０８の判断で障害発生確率が閾値以上とされたユーザシステム２００と、Ｓ１０６において再スケジュール用のキューに登録されたユーザシステム２００の両者が存在する場合には、Ｓ１０６で再スケジュール用のキューに登録されたユーザシステム２００を優先して取り扱う。具体的には、Ｓ１０６で再スケジュール用のキューに登録されたユーザシステム２００から先にＳ１１０以降の処理を行う。
【００２９】
翌日のサービス員スケジュールテーブルにおいて、割当て状況が「空き」になっているサービス員がいれば（Ｓ１１０でＹＥＳ）、サービス員スケジューリング部１００２は、そのサービス員を「障害発生の可能性が高い」ユーザシステム２００への派遣員にアサインして終了する（Ｓ１１１）。
具体的には、サービス員スケジューリング部１００２は、サービス員スケジュールテーブルにおいて、対象となるサービス員の割当て状況を「空き」から「可能性高い」に変更し、また、派遣先のユーザＩＤとユーザシステムＩＤをユーザＩＤ欄とユーザシステムＩＤ欄に書き込む。
【００３０】
一方、割当て状況が「空き」になっているサービス員がいなければ（Ｓ１１０でＮＯ）、サービス員スケジューリング部１００２は、更に翌日のサービス員スケジュールテーブルを取得し、サービス員のスケジュールを確認する（Ｓ１１２）。
以降は、Ｓ１０９からの処理を繰り返して、派遣するサービス員を決定する。
【００３１】
以上の説明では、各ユーザにサービス員１名を割当てているが、同様な手法で２名以上のスケジューリングも可能である。
また、作業が１日ではなくて、半日、あるいは１時間等の場合も同様にスケジューリング可能である。
また、障害発生の可能性が「高い」、「低い」だけでなく、よりきめ細かく計算できる場合も同様にスケジューリング可能である。
【００３２】
以上、本実施の形態では、障害発生以前に得られる情報を利用して、ユーザ拠点に派遣するサービス員のスケジューリング管理を効率化する構成を説明した。
【００３３】
実施の形態２．
本実施の形態では、障害発生以前に得られる情報を利用して、保守のために用いられる部品の配置数、配置場所などを効率的に決定する構成を説明する。
【００３４】
ここでは、ユーザシステムの故障時又は保守時に使用する部品の部品保管拠点として地点Ａ、地点Ｂの２箇所の場合を考える。
地点Ａ、地点Ｂは、例えば、それぞれ地理的に離れた部品保管倉庫が考えられる。
本実施の形態に係る保守運営システム１００は、地点Ａ、地点Ｂでの部品保管数の配分を決定する。
【００３５】
図５は、本実施の形態に係るユーザ状況管理システム１０１と保守運営システム１００の構成例を示す。
ユーザ状況管理システム１０１の構成は、図２と同じであるため説明を省略する。
【００３６】
保守運営システム１００において、入力部１００１は、実施の形態１と同様に、ユーザ状況管理システム１０１から障害発生確率情報を入力する。
【００３７】
部品ユーザ管理テーブル記憶部１００６は、部品ユーザ管理テーブルを記憶する。
部品ユーザ管理テーブルは、部品保管拠点ごとに、部品保管拠点と対応付けられているユーザシステム２００（保守対象装置）が示される情報である。
部品ユーザ管理テーブルは、例えば、図７に示すテーブルである。
部品ユーザ管理テーブルは、部品単位（図７の例では、部品ＩＤ：ＬＭＮ−１２３という部品が対象）で、部品保管拠点（図７の例では、地点Ａ、地点Ｂ）ごとに、部品供給先のユーザのユーザＩＤとユーザシステムＩＤとが対応付けられている。
部品ユーザ管理テーブルは拠点装置情報の例に相当し、部品ユーザ管理テーブル記憶部１００６は拠点装置情報記憶部の例に相当する。
【００３８】
部品在庫テーブル記憶部１００７は、部品在庫テーブルを記憶する。
部品在庫テーブルは、部品保管拠点ごとに、部品保管拠点における部品在庫数が示される情報である。
部品在庫テーブルは、例えば、図８に示すテーブルである。
部品在庫テーブルは、部品単位（図８の例では、部品ＩＤ：ＬＭＮ−１２３等）で、部品保管拠点（図８の例では、地点Ａ、地点Ｂ）ごとに、部品保管拠点における部品在庫数が示される。
部品在庫テーブルは部品在庫数情報の例に相当し、部品在庫テーブル記憶部１００７は部品在庫数情報記憶部の例に相当する。
【００３９】
部品再配置計算部１００５は、部品ユーザ管理テーブルに示される部品保管拠点とユーザシステム２００との対応付けに基づき、共通する部品保管拠点に対応付けられているユーザシステム２００の障害発生確率を合算して、部品保管拠点ごとに障害発生確率の合算値を求め、部品保管拠点ごとの障害発生確率の合算値に基づき、複数の部品保管拠点間の部品保管数の配分を決定する。
更に、部品再配置計算部１００５は、決定した部品保管拠点間の部品保管数の配分と、部品在庫テーブルに示される部品保管拠点ごとの部品在庫数とに基づき、部品保管拠点ごとに、部品保管拠点に供給すべき部品数を判定する。
部品再配置計算部１００５は、部品保管数管理部の例に相当する。
【００４０】
出力部１００４は、部品再配置計算部１００５により決定された部品保管数の配分、部品保管拠点ごとの部品供給数を保守サービス会社の社員に対して出力する。
【００４１】
次に、本実施の形態に係る保守運営システム１００の動作を説明する。
なお、本実施の形態では、説明の簡明化のために、１つの部品に対する動作を行う。
また、ここでは、説明の対象となる部品の総数をｍ個とする。
障害が発生しているユーザには、必要な修理部品はアサインされているため、本実施の形態では障害発生確率に基づいて地点Ａ、地点Ｂの部品供給数を決定する手順を説明する。
【００４２】
以上を前提にして、図６を参照して本実施の形態に係る保守運営システム１００の動作例を説明する。
【００４３】
部品再配置計算部１００５は、部品ユーザ管理テーブルに示される地点とユーザシステム２００との対応付けに基づき、ユーザ状況管理システム１０１から入力された障害発生確率情報を、地点Ａに対応付けられているユーザシステム２００の障害発生確率情報（以下、地点Ａの障害発生確率情報）と地点Ｂに対応付けられているユーザシステム２００の障害発生確率情報（以下、地点Ｂの障害発生確率情報）に分類する。
更に、部品再配置計算部１００５は、地点Ａの障害発生確率情報に記述されている障害発生確率を合算して、地点Ａの全ユーザシステムにおける障害発生確率の総和ａＡＬＬ％を求める（Ｓ２０１）。
また、部品再配置計算部１００５は、同様に、地点Ｂの障害発生確率情報に記述されている障害発生確率を合算して、地点Ｂの全ユーザシステムにおける障害発生確率の総和ｂＡＬＬ％を求める（Ｓ２０２）。
【００４４】
次に、部品再配置計算部１００５は、部品ｍ個を、ａＡＬＬ：ｂＡＬＬの比で配分して、当該部品の地点Ａでの最適数と地点Ｂでの最適数を求める（Ｓ２０３）。
最後に、部品再配置計算部１００５は、地点Ａの最適数と部品在庫テーブルに示される地点Ａの部品在庫数との差から実際に地点Ａに配送する部品数を決定し、地点Ｂの最適数と部品在庫テーブルに示される地点Ｂの部品在庫数との差から実際に地点Ｂに配送する部品数を決定し、決定した部品数を出力部１００４から出力させる（Ｓ２０４）。
これにより、地点Ａ、地点Ｂに適切な数量の部品が配送される。
【００４５】
なお、ここでは、２地点の例を示したが、同様の処理にて３地点以上の場合にも適用できる。また、最適な部品配置が求められた後でも、配送にかかる時間、費用、配送間隔などを勘案して実際の配置を行うことも可能である。
【００４６】
以上、本実施の形態では、障害発生以前に得られる情報を利用して、効率的に部品供給数を決定する構成を説明した。
【００４７】
実施の形態３．
システムの運用状況により、障害の発生率を統計的に知ることができる。
システムに利用されている部品などには、使用回数によって寿命があるものがあるため、システムの利用頻度が低い（例：平日の９時から１７時までしか使わない、電源は入っていても使われていない）場合と頻度が高い場合（例：２４時間３６５日休みなく使われる、常時性能の１００％近く利用されている）では障害の頻度が変わってくる。
この頻度に従って、保守の費用を変更することができる。
例えば、２４時間３６５日使用のユーザには基本料金を課金し、平日昼のみ使用のユーザには基本料金×７０％の料金を課金するという料金体系が考えられる。
また、遠隔監視装置２０１をつけるだけで以上のような効率化が行えるため、遠隔監視装置２０１が設置されていないユーザは基本料金のまま、遠隔監視装置２０１が設置されているユーザは基本料金×８０％の料金というように保守料金を下げることも可能である。
ここでは、基本料金（高）、基本料金（低）の２通りを設定するケースに付いて説明する。
【００４８】
図９は、本実施の形態に係るユーザ状況管理システム１０１と保守運営システム１００の構成例を示す。
ユーザ状況管理システム１０１の構成は、図２と同じであるため説明を省略する。
【００４９】
保守運営システム１００において、入力部１００１は、ユーザ状況管理システム１０１からユーザシステム２００（保守対象装置）ごとの障害履歴が示される障害履歴情報を入力する。
【００５０】
稼動状態テーブル記憶部１００９は、稼動状態テーブルを記憶する。
稼動状態テーブルは、ユーザシステム２００の稼動状態が示される情報であり、例えば、ユーザシステム２００の稼動時間（平日の９時から１７時までしか稼動しない、２４時間３６５日稼動している等）、稼働環境（空調設備の整った環境で稼働している、高温の環境で稼働している等）が示される。
稼動状態テーブルは稼動状態情報の例に相当し、稼動状態テーブル記憶部１００９は稼動状態情報記憶部の例に相当する。
【００５１】
保守費用計算部１００８は、ユーザ状況管理システム１０１から入力した障害履歴情報と稼動状態テーブル記憶部１００９内の稼動状態テーブルから障害発生率を算出し、算出した障害発生率に基づき保守サービス料金である保守費用を算出する。
保守費用計算部１００８は、例えば、稼動時間が長いユーザシステム２００ほど高い障害発生率を算出し、障害発生率が高いユーザシステム２００を使用しているユーザほど高い金額となるように保守費用を算出する。
保守費用計算部１００８は、料金算出部の例に相当する。
【００５２】
次に、図１０を参照して本実施の形態に係る保守運営システム１００の動作例を説明する。
【００５３】
保守費用計算部１００８は、入力部１００１を介して、ユーザ状況管理システム１０１から障害履歴情報を入力し、障害履歴情報に示される障害履歴と稼動状態テーブルに示される稼動状態を用いて、ユーザごとに、一定期間の障害発生率の平均値を求める（Ｓ３０１）。
平均値の算出の対象となる期間は、例えば数ヶ月〜１年である。
また、１つのユーザに複数のユーザシステム２００がある場合は、全てのユーザシステム２００についての障害発生率の平均値を算出する。
なお、障害発生率の算出アルゴリズムは既存技術を用いることができるので、算出手順の詳細は省略する。
【００５４】
次に、保守費用計算部１００８は、ユーザごとに、障害発生率の平均値から、利用状況に応じた保守費用を決定する（Ｓ３０２）。
より具体的には、予め決めておいた障害発生率の閾値よりも高い場合は基本料金（高）を、閾値以下の場合は基本料金（低）を、次回の保守料金とする。
【００５５】
なお、ここでは、保守費用を「高い」、「低い」の２段階に分けたが、３段階以上に分けることも可能である。
【００５６】
本実施の形態では、障害発生率を用いて、効率的にユーザごとに保守料金を決定する構成を説明した。
【００５７】
最後に、実施の形態１〜３に示した保守運営システム１００のハードウェア構成例について説明する。
図１１は、実施の形態１〜３に示す保守運営システム１００のハードウェア資源の一例を示す図である。
なお、図１１の構成は、あくまでも保守運営システム１００のハードウェア構成の一例を示すものであり、保守運営システム１００のハードウェア構成は図１１に記載の構成に限らず、他の構成であってもよい。
【００５８】
図１１において、保守運営システム１００は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
実施の形態１〜３で説明した「〜記憶部」は、ＲＡＭ９１４、磁気ディスク装置９２０等により実現される。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。
【００５９】
通信ボード９１５は、ネットワークに接続されている。
例えば、通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）、インターネット、ＷＡＮ（ワイドエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）などに接続されている。
【００６０】
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。
【００６１】
また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。
【００６２】
また、ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
保守運営システム１００の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。
【００６３】
上記プログラム群９２３には、実施の形態１〜３の説明において「〜部」（「〜記憶部」以外、以下同様）として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
【００６４】
ファイル群９２４には、実施の形態１〜３の説明において、「〜の判断」、「〜の判定」、「〜の計算」、「〜の比較」、「〜の検索」、「〜の更新」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の入力」、「〜の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。
ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出される。
そして、読み出された情報やデータや信号値や変数値やパラメータは、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１〜３で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示す。
データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。
また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【００６５】
また、実施の形態１〜３の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。
すなわち、実施の形態１〜３で説明したフローチャートに示すステップ、手順、処理により、保守運営システム１００の処理をデータ処理方法として捉えることができる。
また、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。
或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。
ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。
プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。
すなわち、プログラムは、実施の形態１〜３の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１〜３の「〜部」の手順や方法をコンピュータに実行させるものである。
【００６６】
このように、実施の形態１〜３に示す保守運営システム１００は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータである。
そして、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
【符号の説明】
【００６７】
１ 保守サービス会社、２ ユーザ拠点、１００ 保守運営システム、１０１ ユーザ状況管理システム、２００ ユーザシステム、２０１ 遠隔監視装置、３００ ネットワーク、１００１ 入力部、１００２ サービス員スケジューリング部、１００３ サービス員スケジュールテーブル記憶部、１００４ 出力部、１００５ 部品再配置計算部、１００６ 部品ユーザ管理テーブル記憶部、１００７ 部品在庫テーブル記憶部、１００８ 保守費用計算部、１００９ 稼動状態テーブル記憶部、１０１１ 障害発生確率計算部、１０１２ 障害履歴管理部。
【技術分野】
【０００１】
本発明は、保守運営システムに関し、特に、保守対象装置に対するサービス員の派遣スケジュールの管理、保守のための部品の管理、保守対象装置に対する保守サービス料金の管理に関する。
【背景技術】
【０００２】
従来、コンピュータシステムにシステム障害が発生した場合、コンピュータシステムのユーザが、障害の発生した箇所に応じて、保守サービス提供会社に電話や電子メール等で連絡して、障害箇所の修理や交換をしてもらっていた。
【０００３】
障害発生から、修理を行うまでの時間を短くするためには、システムを監視する機能をユーザ拠点に設置し、障害発生時にシステム監視機能が自動的に携帯電話等で保守サービス提供会社に連絡するという方法もある。
また、障害発生以前にその兆候が検出できるような装置（ハードディスク装置、ＵＰＳ（Ｕｎｉｎｔｅｒｒｕｐｔｉｂｌｅ Ｐｏｗｅｒ Ｓｕｐｐｌｙ）装置など）の場合、その兆候を検出した時点で、ユーザや保守サービス会社に連絡することで、障害の発生以前に対応することも可能である（例えば、特許文献１、特許文献２）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００３−１５０４０６号公報
【特許文献２】特開２００９−２１７７７０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
これらの従来システムは、ユーザ側からみるとシステムの可用性があがっているが、保守サービス提供会社から見ると、修理対応の時期が前にずれるだけであり、保守サービス全体としてのメリットはほとんどないのが実情である（可用性が上がることで、ユーザの満足度が上がる等のビジネス上のメリットはある）。
【０００６】
この発明は、このような事情に鑑み、障害発生以前に得られる情報を利用して、保守サービスの効率化を図ることを主な目的とする。
【課題を解決するための手段】
【０００７】
本発明に係る保守運営システムは、
保守対象装置に対するサービス員の派遣スケジュールを管理する保守運営システムであって、
サービス員の派遣スケジュールが示される派遣スケジュール情報を記憶する派遣スケジュール情報記憶部と、
保守対象装置での障害発生確率を計算する障害発生確率計算装置から、保守対象装置ごとに、保守対象装置での障害発生確率が示される障害発生確率情報を入力する第１の入力部と、
前記障害発生確率情報に示される保守対象装置ごとの障害発生確率に基づいてサービス員を割当てる保守対象装置を選択し、前記派遣スケジュール情報に示される派遣スケジュールを参照し、割当て対象として選択した保守対象装置にサービス員を割当てて、サービス員の派遣スケジュールを生成する派遣スケジュール生成部とを有することを特徴とする。
【発明の効果】
【０００８】
本発明では、障害発生確率に基づいてサービス員を割当てる保守対象装置を選択し、派遣スケジュールを生成するため、障害発生確率が高い保守対象装置に絞ってサービス員を派遣することができ、保守サービスの効率化を図ることができる。
【図面の簡単な説明】
【０００９】
【図１】実施の形態１〜３に係るシステム構成例を示す図。
【図２】実施の形態１に係るユーザ状況管理システムと保守運営システムの構成例を示す図。
【図３】実施の形態１に係る保守運営システムの動作例を示すフローチャート図。
【図４】実施の形態１に係るサービス員スケジュールテーブルの例を示す図。
【図５】実施の形態２に係るユーザ状況管理システムと保守運営システムの構成例を示す図。
【図６】実施の形態２に係る保守運営システムの動作例を示すフローチャート図。
【図７】実施の形態２に係る部品ユーザ管理テーブルの例を示す図。
【図８】実施の形態２に係る部品在庫テーブルの例を示す図。
【図９】実施の形態３に係るユーザ状況管理システムと保守運営システムの構成例を示す図。
【図１０】実施の形態３に係る保守運営システムの動作例を示すフローチャート図。
【図１１】実施の形態１〜３に係る保守運営システムのハードウェア構成例を示す図。
【発明を実施するための形態】
【００１０】
実施の形態１〜３において、遠隔監視システムをユーザ側に設置し、保守サービス会社に設置し、遠隔監視システムと保守運営システムとを連携することで、保守サービス全体の効率化を図る構成を説明する。
【００１１】
図１は、実施の形態１〜３に係るシステム構成例を示す。
図１において、保守サービス会社１には、保守運営システム１００と、ユーザ状況管理システム１０１が配置される。
ユーザ拠点２には、ユーザシステム２００と、遠隔監視装置２０１が配置される。
ユーザ状況管理システム１０１と遠隔監視装置２０１はネットワーク３００で接続されている。
図１では、ユーザ拠点２は１つしか図示していないが、ユーザ拠点２は複数存在するものとする。
【００１２】
ユーザ拠点２に配置されているユーザシステム２００は、保守サービス会社１が保守の対象とする保守対象装置である。
遠隔監視装置２０１は、ユーザシステム２００の状況を監視する。
遠隔監視装置２０１は、ネットワーク３００を介して、ユーザシステム２００の状況を示すユーザ情報を保守サービス会社１内のユーザ状況管理システム１０１に送信する。
保守サービス会社１では、ユーザ情報をユーザ状況管理システム１０１にて処理し、その結果を保守運営システム１００に通知する。
【００１３】
遠隔監視装置２０１は、ユーザシステム２００の障害の発生を検出するだけではなく、ユーザシステム２００のハードディスクやＵＰＳ等の稼働状況、エラー率、温度、湿度など、障害発生前に検出できる情報も採取可能である。
また、ユーザシステムの累計稼働時間など、障害発生の頻度を検出できる情報も採取可能である。
【００１４】
ユーザ状況管理システム１０１は、遠隔監視装置２０１からのユーザ情報に基づき、保守対象装置であるユーザシステムの障害発生確率を計算することができる。
ユーザ状況管理システム１０１は、障害発生確率計算装置の例に相当する。
【００１５】
保守運営システム１００は、ユーザ状況管理システム１０１で計算された障害発生確率に基づき、ユーザシステムに対するサービス員の派遣スケジュールの管理、保守のための部品の管理、ユーザシステムに対する保守サービス料金の管理を行うことができる。
実施の形態１では、保守運営システム１００がサービス員の派遣スケジュールの管理を行う例を説明する。
実施の形態２では、保守運営システム１００が保守のための部品の配分の管理を行う例を説明する。
実施の形態３では、保守運営システム１００が保守サービス料金の管理を行う例を説明する。
【００１６】
実施の形態１．
保守サービス会社は、通常は、障害発生時にサービス員を派遣するが、障害の発生が予想できない場合は、想定される障害発生確率に基づいて派遣員の人数を準備する。
この場合、障害の発生が重なると、派遣すべきサービス員の人数が派遣可能な人数を超えてしまい、結果としてサービスの質を下げることになる。
サービス員の数を多数揃えると、障害が発生していない時に作業をしていないサービス員が増えることになり、人件費が増えることになる。
本実施の形態では、遠隔監視装置２０１からの情報で、障害発生より前に障害を検知することができ、その場合は、障害発生時より緊急度が低いため、障害が発生しているシステムへ優先的に派遣員を派遣し、作業完了後に、障害を予想検知したシステムに派遣することで、派遣員を効率的に配置することができる。
これらは保守運営システム１００によりスケジューリングされる。
以下、詳細に説明する。
【００１７】
図２は、本実施の形態に係るユーザ状況管理システム１０１と保守運営システム１００の構成例を示す。
【００１８】
ユーザ状況管理システム１０１において、障害発生確率計算部１０１１は、遠隔監視装置２０１からユーザ情報を受信し、受信したユーザ情報と障害履歴管理部１０１２で管理されているユーザシステム２００における障害履歴および過去の類似システムや類似部品の障害発生情報などに基づき、ユーザシステム２００の障害発生確率を計算する。
なお、障害発生確率計算部１０１１による障害発生確率の計算は、既存の技術により実現可能であるため、計算手順の詳細な説明は省略する。
また、障害発生確率計算部１０１１は、ユーザシステム２００の障害発生確率を示す障害発生確率情報を保守運営システム１００に出力する。
なお、障害発生確率計算部１０１１は、ユーザシステム２００における障害発生を通知する障害発生通知を遠隔監視装置２０１から受信した場合には、即座に保守運営システム１００に転送する。
【００１９】
保守運営システム１００において、入力部１００１は、ユーザ状況管理システム１０１から障害発生確率情報を入力する。
また、入力部１００１は、ユーザ状況管理システム１０１から障害発生通知を入力する。
入力部１００１は、第１の入力部及び第２の入力部の例である。
【００２０】
サービス員スケジュールテーブル記憶部１００３は、サービス員の派遣スケジュールが示されるサービス員スケジュールテーブルを記憶する。
サービス員スケジュールテーブルは、例えば、図４に示すテーブルである。
サービス員スケジュールテーブルは、日付ごと（図４の例では、２０１１年３月１５日）に、サービス員ＩＤに対して、派遣先の割当て状況と、派遣先のユーザのユーザＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）、派遣先のユーザのユーザシステムＩＤが対応付けられている。
サービス員スケジュールテーブルは派遣スケジュール情報の例に相当し、サービス員スケジュールテーブル記憶部１００３は派遣スケジュール情報記憶部の例に相当する。
【００２１】
サービス員スケジューリング部１００２は、サービス員スケジュールテーブルに示されるサービス員の派遣スケジュールと、ユーザ状況管理システム１０１からの障害発生確率情報に示されるユーザシステム２００ごとの障害発生確率とに基づき、ユーザシステム２００ごとにサービス員を割当てる。
より具体的には、サービス員スケジューリング部１００２は、障害発生確率情報に示される障害発生確率が所定の閾値以上のユーザは、「障害発生の可能性が高い」ユーザとして分類し、障害発生確率が所定の閾値未満のユーザは、「障害発生の可能性が低い」ユーザに分類される。
そして、サービス員スケジューリング部１００２は、「障害発生の可能性が高い」とされたユーザのユーザシステム２００に派遣するサービス員を決定する。
なお、以下では、「障害発生の可能性が高い」を「可能性高い」とも表記し、「障害発生の可能性が低い」を「可能性低い」とも表記する。
また、サービス員スケジューリング部１００２は、ユーザ状況管理システム１０１から障害発生通知が入力された場合は、障害が発生したユーザシステム２００（障害発生保守対象装置）に対して優先してサービス員を割当てて、派遣スケジュールを生成する。
また、サービス員スケジューリング部１００２は、障害発生通知が入力された際に、サービス員スケジュールテーブルにおいて派遣先が未割当のサービス員が存在しなければ、いずれかのサービス員の割当てを解除し、当該サービス員を障害が発生したユーザシステム２００に割当てる。
更に、サービス員スケジューリング部１００２は、障害発生通知が入力された際にサービス員の割当てが解除されたユーザシステム２００に対して優先してサービス員を割当てる。
サービス員スケジューリング部１００２は、派遣スケジュール生成部の例に相当する。
【００２２】
出力部１００４は、サービス員スケジューリング部１００２により生成されたサービス員スケジュールテーブルを、保守サービス会社の社員に対して出力する。
【００２３】
次に、本実施の形態に係る保守運営システム１００の動作を説明する。
なお、本実施の形態では、説明の簡明化のために、サービス員は各ユーザに対して一名のみ派遣され、作業は一日かかるものと仮定する。
また、各ユーザからの情報により、ユーザ状態として「障害発生」、「障害発生の可能性が高い」、「障害発生の可能性が低い」に分類されるものとする。
つまり、遠隔監視装置２０１より障害が発生されたと通知されたユーザは、ユーザ状態が「障害発生」に分類され、前述したように障害発生確率が所定の閾値以上のユーザは、ユーザ状態が「障害発生の可能性が高い」に分類され、障害発生確率が所定の閾値未満のユーザは、ユーザ状態が「障害発生の可能性が低い」に分類される。
ユーザからの情報は、「障害発生」時は、即時に通知される。
「障害発生」でない場合は、一日一度通知されるものとする。
サービス員の配置は、「障害発生」の通知が来た場合、及び一日一回計算されるものとする。
サービス員のスケジュールは、図４に示すように、「障害発生」、「可能性高い」、「空き」のいずれかである。
「障害発生」は、障害が発生したユーザにサービス員が派遣されることを示しており、「可能性高い」は、障害の発生の可能性が高いユーザにサービス員が派遣されることを示しており、「空き」は、派遣先のユーザが決まっていないことを示している。
【００２４】
以上を前提にして、図３を参照して本実施の形態に係る保守運営システム１００の動作例を説明する。
【００２５】
ユーザシステム２００において障害が発生し、遠隔監視装置２０１から発信された障害発生通知が、ユーザ状況管理システム１０１を経由して入力部１００１に入力された際に（Ｓ１０１でＹＥＳ）、サービス員スケジューリング部１００２が、サービス員スケジュールテーブル記憶部１００３から翌日のサービス員スケジュールテーブルを取得し、翌日のサービス員のスケジュールを確認する（Ｓ１０２）。
割当て状況が「空き」になっているサービス員がいれば（Ｓ１０３でＹＥＳ）、サービス員スケジューリング部１００２は、そのサービス員を障害が発生したユーザシステム２００への派遣員にアサインして終了する（Ｓ１０４）。
具体的には、サービス員スケジューリング部１００２は、サービス員スケジュールテーブルにおいて、対象となるサービス員の割当て状況を「空き」から「障害発生」に変更し、また、派遣先のユーザＩＤとユーザシステムＩＤをユーザＩＤ欄とユーザシステムＩＤ欄に書き込む。
【００２６】
一方、割当て状況が「空き」になっているサービス員がいなければ（Ｓ１０３でＮＯ）、サービス員スケジュールテーブル内で割当て状況が「可能性高い」になっているサービス員を検索する（Ｓ１０５）。
そして、「可能性高い」となっているサービス員がいた場合に（Ｓ１０５でＹＥＳ）、そのサービス員の現在の割当てを解除し、そのサービス員を障害が発生しているユーザに割当て、そのサービス員に割り当てられていた「可能性高い」ユーザへの対応は、翌日以降に再度スケジューリングする（Ｓ１０６）。
つまり、サービス員スケジューリング部１００２は、そのサービス員の割当て状況を「気可能性高い」から「障害発生」に変更し、現在ユーザＩＤ欄とユーザシステムＩＤ欄に記述されているユーザＩＤとユーザシステムＩＤ（「可能性高い」ユーザＩＤとユーザシステムＩＤ）を再スケジュール用のキューに登録し、サービス員スケジュールテーブルのユーザＩＤ欄とユーザシステムＩＤ欄を障害が発生しているユーザのユーザＩＤとユーザシステムＩＤに書き換える。
再スケジュールは、Ｓ１０９以降の処理により行われる。
【００２７】
Ｓ１０５の判定にて、割当て状況が「可能性高い」になっているサービス員がなければ（Ｓ１０５でＮＯ）、サービス員スケジューリング部１００２は、更に翌日のサービス員スケジュールテーブルを取得し、サービス員のスケジュールを確認する（Ｓ１０７）。
以降は、Ｓ１０２からの処理を繰り返して、派遣するサービス員を決定する。
【００２８】
障害発生通知が入力されずにサービス員の配置を決定するタイミングになった際に、ユーザ状況管理システム１０１から通知された障害発生確率が所定の閾値以上のユーザシステム２００があれば、「障害発生の可能性が高い」ユーザシステム２００が存在するので（Ｓ１０８でＹＥＳ）、サービス員スケジューリング部１００２は、サービス員スケジュールテーブル記憶部１００３から翌日のサービス員スケジュールテーブルを取得し、翌日のサービス員のスケジュールを確認する（Ｓ１０９）。
なお、Ｓ１０８の判断において障害発生確率が閾値以上のユーザシステム２００が存在しなくても、前述したＳ１０６において割当てが解除されて、再スケジュール用キューに登録されたユーザシステム２００が存在する場合には、Ｓ１０９以降の処理が実施される。
また、Ｓ１０８の判断で障害発生確率が閾値以上とされたユーザシステム２００と、Ｓ１０６において再スケジュール用のキューに登録されたユーザシステム２００の両者が存在する場合には、Ｓ１０６で再スケジュール用のキューに登録されたユーザシステム２００を優先して取り扱う。具体的には、Ｓ１０６で再スケジュール用のキューに登録されたユーザシステム２００から先にＳ１１０以降の処理を行う。
【００２９】
翌日のサービス員スケジュールテーブルにおいて、割当て状況が「空き」になっているサービス員がいれば（Ｓ１１０でＹＥＳ）、サービス員スケジューリング部１００２は、そのサービス員を「障害発生の可能性が高い」ユーザシステム２００への派遣員にアサインして終了する（Ｓ１１１）。
具体的には、サービス員スケジューリング部１００２は、サービス員スケジュールテーブルにおいて、対象となるサービス員の割当て状況を「空き」から「可能性高い」に変更し、また、派遣先のユーザＩＤとユーザシステムＩＤをユーザＩＤ欄とユーザシステムＩＤ欄に書き込む。
【００３０】
一方、割当て状況が「空き」になっているサービス員がいなければ（Ｓ１１０でＮＯ）、サービス員スケジューリング部１００２は、更に翌日のサービス員スケジュールテーブルを取得し、サービス員のスケジュールを確認する（Ｓ１１２）。
以降は、Ｓ１０９からの処理を繰り返して、派遣するサービス員を決定する。
【００３１】
以上の説明では、各ユーザにサービス員１名を割当てているが、同様な手法で２名以上のスケジューリングも可能である。
また、作業が１日ではなくて、半日、あるいは１時間等の場合も同様にスケジューリング可能である。
また、障害発生の可能性が「高い」、「低い」だけでなく、よりきめ細かく計算できる場合も同様にスケジューリング可能である。
【００３２】
以上、本実施の形態では、障害発生以前に得られる情報を利用して、ユーザ拠点に派遣するサービス員のスケジューリング管理を効率化する構成を説明した。
【００３３】
実施の形態２．
本実施の形態では、障害発生以前に得られる情報を利用して、保守のために用いられる部品の配置数、配置場所などを効率的に決定する構成を説明する。
【００３４】
ここでは、ユーザシステムの故障時又は保守時に使用する部品の部品保管拠点として地点Ａ、地点Ｂの２箇所の場合を考える。
地点Ａ、地点Ｂは、例えば、それぞれ地理的に離れた部品保管倉庫が考えられる。
本実施の形態に係る保守運営システム１００は、地点Ａ、地点Ｂでの部品保管数の配分を決定する。
【００３５】
図５は、本実施の形態に係るユーザ状況管理システム１０１と保守運営システム１００の構成例を示す。
ユーザ状況管理システム１０１の構成は、図２と同じであるため説明を省略する。
【００３６】
保守運営システム１００において、入力部１００１は、実施の形態１と同様に、ユーザ状況管理システム１０１から障害発生確率情報を入力する。
【００３７】
部品ユーザ管理テーブル記憶部１００６は、部品ユーザ管理テーブルを記憶する。
部品ユーザ管理テーブルは、部品保管拠点ごとに、部品保管拠点と対応付けられているユーザシステム２００（保守対象装置）が示される情報である。
部品ユーザ管理テーブルは、例えば、図７に示すテーブルである。
部品ユーザ管理テーブルは、部品単位（図７の例では、部品ＩＤ：ＬＭＮ−１２３という部品が対象）で、部品保管拠点（図７の例では、地点Ａ、地点Ｂ）ごとに、部品供給先のユーザのユーザＩＤとユーザシステムＩＤとが対応付けられている。
部品ユーザ管理テーブルは拠点装置情報の例に相当し、部品ユーザ管理テーブル記憶部１００６は拠点装置情報記憶部の例に相当する。
【００３８】
部品在庫テーブル記憶部１００７は、部品在庫テーブルを記憶する。
部品在庫テーブルは、部品保管拠点ごとに、部品保管拠点における部品在庫数が示される情報である。
部品在庫テーブルは、例えば、図８に示すテーブルである。
部品在庫テーブルは、部品単位（図８の例では、部品ＩＤ：ＬＭＮ−１２３等）で、部品保管拠点（図８の例では、地点Ａ、地点Ｂ）ごとに、部品保管拠点における部品在庫数が示される。
部品在庫テーブルは部品在庫数情報の例に相当し、部品在庫テーブル記憶部１００７は部品在庫数情報記憶部の例に相当する。
【００３９】
部品再配置計算部１００５は、部品ユーザ管理テーブルに示される部品保管拠点とユーザシステム２００との対応付けに基づき、共通する部品保管拠点に対応付けられているユーザシステム２００の障害発生確率を合算して、部品保管拠点ごとに障害発生確率の合算値を求め、部品保管拠点ごとの障害発生確率の合算値に基づき、複数の部品保管拠点間の部品保管数の配分を決定する。
更に、部品再配置計算部１００５は、決定した部品保管拠点間の部品保管数の配分と、部品在庫テーブルに示される部品保管拠点ごとの部品在庫数とに基づき、部品保管拠点ごとに、部品保管拠点に供給すべき部品数を判定する。
部品再配置計算部１００５は、部品保管数管理部の例に相当する。
【００４０】
出力部１００４は、部品再配置計算部１００５により決定された部品保管数の配分、部品保管拠点ごとの部品供給数を保守サービス会社の社員に対して出力する。
【００４１】
次に、本実施の形態に係る保守運営システム１００の動作を説明する。
なお、本実施の形態では、説明の簡明化のために、１つの部品に対する動作を行う。
また、ここでは、説明の対象となる部品の総数をｍ個とする。
障害が発生しているユーザには、必要な修理部品はアサインされているため、本実施の形態では障害発生確率に基づいて地点Ａ、地点Ｂの部品供給数を決定する手順を説明する。
【００４２】
以上を前提にして、図６を参照して本実施の形態に係る保守運営システム１００の動作例を説明する。
【００４３】
部品再配置計算部１００５は、部品ユーザ管理テーブルに示される地点とユーザシステム２００との対応付けに基づき、ユーザ状況管理システム１０１から入力された障害発生確率情報を、地点Ａに対応付けられているユーザシステム２００の障害発生確率情報（以下、地点Ａの障害発生確率情報）と地点Ｂに対応付けられているユーザシステム２００の障害発生確率情報（以下、地点Ｂの障害発生確率情報）に分類する。
更に、部品再配置計算部１００５は、地点Ａの障害発生確率情報に記述されている障害発生確率を合算して、地点Ａの全ユーザシステムにおける障害発生確率の総和ａＡＬＬ％を求める（Ｓ２０１）。
また、部品再配置計算部１００５は、同様に、地点Ｂの障害発生確率情報に記述されている障害発生確率を合算して、地点Ｂの全ユーザシステムにおける障害発生確率の総和ｂＡＬＬ％を求める（Ｓ２０２）。
【００４４】
次に、部品再配置計算部１００５は、部品ｍ個を、ａＡＬＬ：ｂＡＬＬの比で配分して、当該部品の地点Ａでの最適数と地点Ｂでの最適数を求める（Ｓ２０３）。
最後に、部品再配置計算部１００５は、地点Ａの最適数と部品在庫テーブルに示される地点Ａの部品在庫数との差から実際に地点Ａに配送する部品数を決定し、地点Ｂの最適数と部品在庫テーブルに示される地点Ｂの部品在庫数との差から実際に地点Ｂに配送する部品数を決定し、決定した部品数を出力部１００４から出力させる（Ｓ２０４）。
これにより、地点Ａ、地点Ｂに適切な数量の部品が配送される。
【００４５】
なお、ここでは、２地点の例を示したが、同様の処理にて３地点以上の場合にも適用できる。また、最適な部品配置が求められた後でも、配送にかかる時間、費用、配送間隔などを勘案して実際の配置を行うことも可能である。
【００４６】
以上、本実施の形態では、障害発生以前に得られる情報を利用して、効率的に部品供給数を決定する構成を説明した。
【００４７】
実施の形態３．
システムの運用状況により、障害の発生率を統計的に知ることができる。
システムに利用されている部品などには、使用回数によって寿命があるものがあるため、システムの利用頻度が低い（例：平日の９時から１７時までしか使わない、電源は入っていても使われていない）場合と頻度が高い場合（例：２４時間３６５日休みなく使われる、常時性能の１００％近く利用されている）では障害の頻度が変わってくる。
この頻度に従って、保守の費用を変更することができる。
例えば、２４時間３６５日使用のユーザには基本料金を課金し、平日昼のみ使用のユーザには基本料金×７０％の料金を課金するという料金体系が考えられる。
また、遠隔監視装置２０１をつけるだけで以上のような効率化が行えるため、遠隔監視装置２０１が設置されていないユーザは基本料金のまま、遠隔監視装置２０１が設置されているユーザは基本料金×８０％の料金というように保守料金を下げることも可能である。
ここでは、基本料金（高）、基本料金（低）の２通りを設定するケースに付いて説明する。
【００４８】
図９は、本実施の形態に係るユーザ状況管理システム１０１と保守運営システム１００の構成例を示す。
ユーザ状況管理システム１０１の構成は、図２と同じであるため説明を省略する。
【００４９】
保守運営システム１００において、入力部１００１は、ユーザ状況管理システム１０１からユーザシステム２００（保守対象装置）ごとの障害履歴が示される障害履歴情報を入力する。
【００５０】
稼動状態テーブル記憶部１００９は、稼動状態テーブルを記憶する。
稼動状態テーブルは、ユーザシステム２００の稼動状態が示される情報であり、例えば、ユーザシステム２００の稼動時間（平日の９時から１７時までしか稼動しない、２４時間３６５日稼動している等）、稼働環境（空調設備の整った環境で稼働している、高温の環境で稼働している等）が示される。
稼動状態テーブルは稼動状態情報の例に相当し、稼動状態テーブル記憶部１００９は稼動状態情報記憶部の例に相当する。
【００５１】
保守費用計算部１００８は、ユーザ状況管理システム１０１から入力した障害履歴情報と稼動状態テーブル記憶部１００９内の稼動状態テーブルから障害発生率を算出し、算出した障害発生率に基づき保守サービス料金である保守費用を算出する。
保守費用計算部１００８は、例えば、稼動時間が長いユーザシステム２００ほど高い障害発生率を算出し、障害発生率が高いユーザシステム２００を使用しているユーザほど高い金額となるように保守費用を算出する。
保守費用計算部１００８は、料金算出部の例に相当する。
【００５２】
次に、図１０を参照して本実施の形態に係る保守運営システム１００の動作例を説明する。
【００５３】
保守費用計算部１００８は、入力部１００１を介して、ユーザ状況管理システム１０１から障害履歴情報を入力し、障害履歴情報に示される障害履歴と稼動状態テーブルに示される稼動状態を用いて、ユーザごとに、一定期間の障害発生率の平均値を求める（Ｓ３０１）。
平均値の算出の対象となる期間は、例えば数ヶ月〜１年である。
また、１つのユーザに複数のユーザシステム２００がある場合は、全てのユーザシステム２００についての障害発生率の平均値を算出する。
なお、障害発生率の算出アルゴリズムは既存技術を用いることができるので、算出手順の詳細は省略する。
【００５４】
次に、保守費用計算部１００８は、ユーザごとに、障害発生率の平均値から、利用状況に応じた保守費用を決定する（Ｓ３０２）。
より具体的には、予め決めておいた障害発生率の閾値よりも高い場合は基本料金（高）を、閾値以下の場合は基本料金（低）を、次回の保守料金とする。
【００５５】
なお、ここでは、保守費用を「高い」、「低い」の２段階に分けたが、３段階以上に分けることも可能である。
【００５６】
本実施の形態では、障害発生率を用いて、効率的にユーザごとに保守料金を決定する構成を説明した。
【００５７】
最後に、実施の形態１〜３に示した保守運営システム１００のハードウェア構成例について説明する。
図１１は、実施の形態１〜３に示す保守運営システム１００のハードウェア資源の一例を示す図である。
なお、図１１の構成は、あくまでも保守運営システム１００のハードウェア構成の一例を示すものであり、保守運営システム１００のハードウェア構成は図１１に記載の構成に限らず、他の構成であってもよい。
【００５８】
図１１において、保守運営システム１００は、プログラムを実行するＣＰＵ９１１（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ、中央処理装置、処理装置、演算装置、マイクロプロセッサ、マイクロコンピュータ、プロセッサともいう）を備えている。
ＣＰＵ９１１は、バス９１２を介して、例えば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）９１３、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）９１４、通信ボード９１５、表示装置９０１、キーボード９０２、マウス９０３、磁気ディスク装置９２０と接続され、これらのハードウェアデバイスを制御する。
更に、ＣＰＵ９１１は、ＦＤＤ９０４（Ｆｌｅｘｉｂｌｅ Ｄｉｓｋ Ｄｒｉｖｅ）、コンパクトディスク装置９０５（ＣＤＤ）、プリンタ装置９０６、スキャナ装置９０７と接続していてもよい。また、磁気ディスク装置９２０の代わりに、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、光ディスク装置、メモリカード（登録商標）読み書き装置などの記憶装置でもよい。
ＲＡＭ９１４は、揮発性メモリの一例である。ＲＯＭ９１３、ＦＤＤ９０４、ＣＤＤ９０５、磁気ディスク装置９２０の記憶媒体は、不揮発性メモリの一例である。これらは、記憶装置の一例である。
実施の形態１〜３で説明した「〜記憶部」は、ＲＡＭ９１４、磁気ディスク装置９２０等により実現される。
通信ボード９１５、キーボード９０２、マウス９０３、スキャナ装置９０７、ＦＤＤ９０４などは、入力装置の一例である。
また、通信ボード９１５、表示装置９０１、プリンタ装置９０６などは、出力装置の一例である。
【００５９】
通信ボード９１５は、ネットワークに接続されている。
例えば、通信ボード９１５は、ＬＡＮ（ローカルエリアネットワーク）、インターネット、ＷＡＮ（ワイドエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）などに接続されている。
【００６０】
磁気ディスク装置９２０には、オペレーティングシステム９２１（ＯＳ）、ウィンドウシステム９２２、プログラム群９２３、ファイル群９２４が記憶されている。
プログラム群９２３のプログラムは、ＣＰＵ９１１がオペレーティングシステム９２１、ウィンドウシステム９２２を利用しながら実行する。
【００６１】
また、ＲＡＭ９１４には、ＣＰＵ９１１に実行させるオペレーティングシステム９２１のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。
また、ＲＡＭ９１４には、ＣＰＵ９１１による処理に必要な各種データが格納される。
【００６２】
また、ＲＯＭ９１３には、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）プログラムが格納され、磁気ディスク装置９２０にはブートプログラムが格納されている。
保守運営システム１００の起動時には、ＲＯＭ９１３のＢＩＯＳプログラム及び磁気ディスク装置９２０のブートプログラムが実行され、ＢＩＯＳプログラム及びブートプログラムによりオペレーティングシステム９２１が起動される。
【００６３】
上記プログラム群９２３には、実施の形態１〜３の説明において「〜部」（「〜記憶部」以外、以下同様）として説明している機能を実行するプログラムが記憶されている。プログラムは、ＣＰＵ９１１により読み出され実行される。
【００６４】
ファイル群９２４には、実施の形態１〜３の説明において、「〜の判断」、「〜の判定」、「〜の計算」、「〜の比較」、「〜の検索」、「〜の更新」、「〜の設定」、「〜の登録」、「〜の選択」、「〜の入力」、「〜の出力」等として説明している処理の結果を示す情報やデータや信号値や変数値やパラメータが、「〜ファイル」や「〜データベース」の各項目として記憶されている。
「〜ファイル」や「〜データベース」は、ディスクやメモリなどの記録媒体に記憶される。
ディスクやメモリなどの記憶媒体に記憶された情報やデータや信号値や変数値やパラメータは、読み書き回路を介してＣＰＵ９１１によりメインメモリやキャッシュメモリに読み出される。
そして、読み出された情報やデータや信号値や変数値やパラメータは、抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示などのＣＰＵの動作に用いられる。
抽出・検索・参照・比較・演算・計算・処理・編集・出力・印刷・表示のＣＰＵの動作の間、情報やデータや信号値や変数値やパラメータは、メインメモリ、レジスタ、キャッシュメモリ、バッファメモリ等に一時的に記憶される。
また、実施の形態１〜３で説明しているフローチャートの矢印の部分は主としてデータや信号の入出力を示す。
データや信号値は、ＲＡＭ９１４のメモリ、ＦＤＤ９０４のフレキシブルディスク、ＣＤＤ９０５のコンパクトディスク、磁気ディスク装置９２０の磁気ディスク、その他光ディスク、ミニディスク、ＤＶＤ等の記録媒体に記録される。
また、データや信号は、バス９１２や信号線やケーブルその他の伝送媒体によりオンライン伝送される。
【００６５】
また、実施の形態１〜３の説明において「〜部」として説明しているものは、「〜回路」、「〜装置」、「〜機器」であってもよく、また、「〜ステップ」、「〜手順」、「〜処理」であってもよい。
すなわち、実施の形態１〜３で説明したフローチャートに示すステップ、手順、処理により、保守運営システム１００の処理をデータ処理方法として捉えることができる。
また、「〜部」として説明しているものは、ＲＯＭ９１３に記憶されたファームウェアで実現されていても構わない。
或いは、ソフトウェアのみ、或いは、素子・デバイス・基板・配線などのハードウェアのみ、或いは、ソフトウェアとハードウェアとの組み合わせ、さらには、ファームウェアとの組み合わせで実施されても構わない。
ファームウェアとソフトウェアは、プログラムとして、磁気ディスク、フレキシブルディスク、光ディスク、コンパクトディスク、ミニディスク、ＤＶＤ等の記録媒体に記憶される。
プログラムはＣＰＵ９１１により読み出され、ＣＰＵ９１１により実行される。
すなわち、プログラムは、実施の形態１〜３の「〜部」としてコンピュータを機能させるものである。あるいは、実施の形態１〜３の「〜部」の手順や方法をコンピュータに実行させるものである。
【００６６】
このように、実施の形態１〜３に示す保守運営システム１００は、処理装置たるＣＰＵ、記憶装置たるメモリ、磁気ディスク等、入力装置たるキーボード、マウス、通信ボード等、出力装置たる表示装置、通信ボード等を備えるコンピュータである。
そして、上記したように「〜部」として示された機能をこれら処理装置、記憶装置、入力装置、出力装置を用いて実現するものである。
【符号の説明】
【００６７】
１ 保守サービス会社、２ ユーザ拠点、１００ 保守運営システム、１０１ ユーザ状況管理システム、２００ ユーザシステム、２０１ 遠隔監視装置、３００ ネットワーク、１００１ 入力部、１００２ サービス員スケジューリング部、１００３ サービス員スケジュールテーブル記憶部、１００４ 出力部、１００５ 部品再配置計算部、１００６ 部品ユーザ管理テーブル記憶部、１００７ 部品在庫テーブル記憶部、１００８ 保守費用計算部、１００９ 稼動状態テーブル記憶部、１０１１ 障害発生確率計算部、１０１２ 障害履歴管理部。
【特許請求の範囲】
【請求項１】
保守対象装置に対するサービス員の派遣スケジュールを管理する保守運営システムであって、
サービス員の派遣スケジュールが示される派遣スケジュール情報を記憶する派遣スケジュール情報記憶部と、
保守対象装置での障害発生確率を計算する障害発生確率計算装置から、保守対象装置ごとに、保守対象装置での障害発生確率が示される障害発生確率情報を入力する第１の入力部と、
前記障害発生確率情報に示される保守対象装置ごとの障害発生確率に基づいてサービス員を割当てる保守対象装置を選択し、前記派遣スケジュール情報に示される派遣スケジュールを参照し、割当て対象として選択した保守対象装置にサービス員を割当てて、サービス員の派遣スケジュールを生成する派遣スケジュール生成部とを有することを特徴とする保守運営システム。
【請求項２】
前記保守運営システムは、更に、
いずれかの保守対象装置での障害の発生を通知する障害発生通知を入力する第２の入力部を有し、
前記派遣スケジュール生成部は、
前記第２の入力部により障害発生通知が入力された際に、障害が発生した障害発生保守対象装置に対して優先してサービス員を割当てて、サービス員の派遣スケジュールを生成することを特徴とする請求項１に記載の保守運営システム。
【請求項３】
前記派遣スケジュール生成部は、
前記第２の入力部により障害発生通知が入力された際に、前記派遣スケジュール情報において派遣先が未割当のサービス員が存在しなければ、いずれかのサービス員の割当てを解除し、当該サービス員を前記障害発生保守対象装置に割当てることを特徴とする請求項２に記載の保守運営システム。
【請求項４】
前記派遣スケジュール生成部は、
前記第２の入力部により障害発生通知が入力された際にサービス員の割当てが解除された保守対象装置に対して優先してサービス員を割当てることを特徴とする請求項３に記載の保守運営システム。
【請求項５】
前記派遣スケジュール生成部は、
障害発生確率が所定レベル以上の保守対象装置に対してのみサービス員を割当てることを特徴とする請求項１〜４のいずれかに記載の保守運営システム。
【請求項６】
複数の部品保管拠点を管理する保守運営システムであって、
部品保管拠点ごとに、部品保管拠点と対応付けられている保守対象装置が示される拠点装置情報を記憶する拠点装置情報記憶部と、
保守対象装置での障害発生確率を計算する障害発生確率計算装置から、保守対象装置ごとに、保守対象装置での障害発生確率が示される障害発生確率情報を入力する入力部と、
前記拠点装置情報に示される部品保管拠点と保守対象装置との対応付けに基づき、共通する部品保管拠点に対応付けられている保守対象装置の障害発生確率を合算して、部品保管拠点ごとに障害発生確率の合算値を求め、部品保管拠点ごとの障害発生確率の合算値に基づき、前記複数の部品保管拠点間の部品保管数の配分を決定する部品保管数管理部とを有することを特徴とする保守運営システム。
【請求項７】
前記保守運営システムは、更に、
部品保管拠点ごとに、部品保管拠点における部品在庫数が示される部品在庫数情報を記憶する部品在庫数情報記憶部を有し、
前記部品保管数管理部は、
前記複数の部品保管拠点間の部品保管数の配分と、前記部品在庫数情報に示される部品保管拠点ごとの部品在庫数とに基づき、部品保管拠点ごとに、部品保管拠点に供給すべき部品数を判定することを特徴とする請求項６に記載の保守運営システム。
【請求項８】
保守対象装置に対する保守サービスの料金を管理する保守運営システムであって、
前記保守対象装置での障害履歴が示される障害履歴情報を入力する入力部と、
前記保守対象装置の稼動状態が示される稼動状態情報を記憶する稼動状態情報記憶部と、
前記障害履歴情報に示される障害履歴と前記稼動状態情報に示される稼動状態とを用いて障害発生率を算出し、算出した障害発生率に基づき前記保守対象装置に対する保守サービス料金を算出する料金算出部とを有することを特徴とする保守運営システム。
【請求項９】
前記稼動状態情報記憶部は、
前記稼動状態情報として前記保守対象装置の稼働時間が示される情報を記憶しており、
前記料金算出部は、
前記稼動状態情報に示される稼動時間が長い保守対象装置ほど高い障害発生率を算出し、障害発生率が高い保守対象装置ほど高い金額となるように保守サービス料金を算出することを特徴とする請求項８に記載の保守運営システム。
【請求項１】
保守対象装置に対するサービス員の派遣スケジュールを管理する保守運営システムであって、
サービス員の派遣スケジュールが示される派遣スケジュール情報を記憶する派遣スケジュール情報記憶部と、
保守対象装置での障害発生確率を計算する障害発生確率計算装置から、保守対象装置ごとに、保守対象装置での障害発生確率が示される障害発生確率情報を入力する第１の入力部と、
前記障害発生確率情報に示される保守対象装置ごとの障害発生確率に基づいてサービス員を割当てる保守対象装置を選択し、前記派遣スケジュール情報に示される派遣スケジュールを参照し、割当て対象として選択した保守対象装置にサービス員を割当てて、サービス員の派遣スケジュールを生成する派遣スケジュール生成部とを有することを特徴とする保守運営システム。
【請求項２】
前記保守運営システムは、更に、
いずれかの保守対象装置での障害の発生を通知する障害発生通知を入力する第２の入力部を有し、
前記派遣スケジュール生成部は、
前記第２の入力部により障害発生通知が入力された際に、障害が発生した障害発生保守対象装置に対して優先してサービス員を割当てて、サービス員の派遣スケジュールを生成することを特徴とする請求項１に記載の保守運営システム。
【請求項３】
前記派遣スケジュール生成部は、
前記第２の入力部により障害発生通知が入力された際に、前記派遣スケジュール情報において派遣先が未割当のサービス員が存在しなければ、いずれかのサービス員の割当てを解除し、当該サービス員を前記障害発生保守対象装置に割当てることを特徴とする請求項２に記載の保守運営システム。
【請求項４】
前記派遣スケジュール生成部は、
前記第２の入力部により障害発生通知が入力された際にサービス員の割当てが解除された保守対象装置に対して優先してサービス員を割当てることを特徴とする請求項３に記載の保守運営システム。
【請求項５】
前記派遣スケジュール生成部は、
障害発生確率が所定レベル以上の保守対象装置に対してのみサービス員を割当てることを特徴とする請求項１〜４のいずれかに記載の保守運営システム。
【請求項６】
複数の部品保管拠点を管理する保守運営システムであって、
部品保管拠点ごとに、部品保管拠点と対応付けられている保守対象装置が示される拠点装置情報を記憶する拠点装置情報記憶部と、
保守対象装置での障害発生確率を計算する障害発生確率計算装置から、保守対象装置ごとに、保守対象装置での障害発生確率が示される障害発生確率情報を入力する入力部と、
前記拠点装置情報に示される部品保管拠点と保守対象装置との対応付けに基づき、共通する部品保管拠点に対応付けられている保守対象装置の障害発生確率を合算して、部品保管拠点ごとに障害発生確率の合算値を求め、部品保管拠点ごとの障害発生確率の合算値に基づき、前記複数の部品保管拠点間の部品保管数の配分を決定する部品保管数管理部とを有することを特徴とする保守運営システム。
【請求項７】
前記保守運営システムは、更に、
部品保管拠点ごとに、部品保管拠点における部品在庫数が示される部品在庫数情報を記憶する部品在庫数情報記憶部を有し、
前記部品保管数管理部は、
前記複数の部品保管拠点間の部品保管数の配分と、前記部品在庫数情報に示される部品保管拠点ごとの部品在庫数とに基づき、部品保管拠点ごとに、部品保管拠点に供給すべき部品数を判定することを特徴とする請求項６に記載の保守運営システム。
【請求項８】
保守対象装置に対する保守サービスの料金を管理する保守運営システムであって、
前記保守対象装置での障害履歴が示される障害履歴情報を入力する入力部と、
前記保守対象装置の稼動状態が示される稼動状態情報を記憶する稼動状態情報記憶部と、
前記障害履歴情報に示される障害履歴と前記稼動状態情報に示される稼動状態とを用いて障害発生率を算出し、算出した障害発生率に基づき前記保守対象装置に対する保守サービス料金を算出する料金算出部とを有することを特徴とする保守運営システム。
【請求項９】
前記稼動状態情報記憶部は、
前記稼動状態情報として前記保守対象装置の稼働時間が示される情報を記憶しており、
前記料金算出部は、
前記稼動状態情報に示される稼動時間が長い保守対象装置ほど高い障害発生率を算出し、障害発生率が高い保守対象装置ほど高い金額となるように保守サービス料金を算出することを特徴とする請求項８に記載の保守運営システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１２−１９０３２４（Ｐ２０１２−１９０３２４Ａ）
【公開日】平成２４年１０月４日（２０１２．１０．４）
【国際特許分類】
【出願番号】特願２０１１−５４１２６（Ｐ２０１１−５４１２６）
【出願日】平成２３年３月１１日（２０１１．３．１１）
【出願人】（５０１１５８５３８）三菱電機インフォメーションテクノロジー株式会社 (28)
【Ｆターム（参考）】
【公開日】平成２４年１０月４日（２０１２．１０．４）
【国際特許分類】
【出願日】平成２３年３月１１日（２０１１．３．１１）
【出願人】（５０１１５８５３８）三菱電機インフォメーションテクノロジー株式会社 (28)
【Ｆターム（参考）】
[ Back to top ]