(57)【要約】【課題】保守ビジネスの観点から、障害案件の重要度に応じたサービスマンの適切な手配を行い、保守機器の稼働率向上を図る管理装置、サービスマン手配方法、プログラム、及び記録媒体を提供することを課題とする。【解決手段】本発明に係る管理装置は、保守契約対象の機器の障害が発生したとき、当該障害機器の障害対応を行うサービスマンを選定する管理装置であって、前記障害機器の保守契約上取り決めされた保証稼働率と、前記障害機器の障害発生時点での稼働率とを記憶する記憶手段と、前記保証稼働率及び前記稼働率の差分値に基づき、当該障害機器の障害対応を行うべき優先度を判定する判定手段と、前記優先度が所定値以上の場合、サービスマンを優先して前記障害機器の障害対応の手配を行う手配手段とを有する。【選択図】図３
2011129055.tif 000002
【特許請求の範囲】
【請求項１】
保守契約対象の機器の障害が発生したとき、当該障害機器の障害対応を行うサービスマンを選定する管理装置であって、
前記障害機器の保守契約上取り決めされた保証稼働率と、前記障害機器の障害発生時点での稼働率とを記憶する記憶手段と、
前記保証稼働率及び前記稼働率の差分値に基づき、当該障害機器の障害対応を行うべき優先度を判定する判定手段と、
前記優先度が所定値以上の場合、サービスマンを優先して前記障害機器の障害対応の手配を行う手配手段と、
を有することを特徴とする管理装置。
【請求項２】
前記手配手段は、前記優先度が所定値以上の場合、サービスマン情報に基づき手配を行うサービスマンの選定を行うこと、
を特徴とする請求項１記載の管理装置。
【請求項３】
前記優先度は優先度レベルを含み、
前記サービスマン情報は、サービスマンの現在の状態を含み、
前記手配手段は、前記サービスマン情報の前記現在の状態に基づきサービスマンの手配を行う際に当該サービスマンが他の障害対応により当該障害対応を行えない場合、前記他の障害対応の優先度レベルと、当該障害対応の優先度レベルを比較し、優先度レベルの高い方の障害対応を優先すべく当該サービスマンの手配を行うこと、
を特徴とする請求項２記載の管理装置。
【請求項４】
前記サービスマン情報は、障害対応の熟練度を含み、
前記手配手段は、前記サービスマン情報の前記現在の状態に基づきサービスマンの手配を行う際に当該サービスマンが他の障害対応により当該障害対応を行えない場合、当該障害対応の障害難易度と、当該サービスマンの熟練度を比較し、前記障害難易度より前記熟練度を有するサービスマンの手配を行うこと、
を特徴とする請求項２又は３記載の管理装置。
【請求項５】
前記熟練度は、障害対応完了される毎に対応内容はフィードバックされ、新たな熟練度として反映されること、
を特徴とする請求項４記載の管理装置。
【請求項６】
保守契約対象の機器の障害が発生したとき、当該障害機器の障害対応を行うサービスマンを選定する管理装置におけるサービスマン手配方法であって、
前記管理装置が、
前記障害機器の保守契約上取り決めされた保証稼働率と、前記障害機器の障害発生時点での稼働率とを記憶する記憶手順と、
前記保証稼働率及び前記稼働率の差分値に基づき、当該障害機器の障害対応を行うべき優先度を判定する判定手順と、
前記優先度が所定値以上の場合、サービスマンを優先して前記障害機器の障害対応の手配を行う手配手順と、
を有することを特徴とするサービスマン手配方法。
【請求項７】
前記手配手順は、前記優先度が所定値以上の場合、サービスマン情報に基づき手配を行うサービスマンの選定を行うこと、
を特徴とする請求項６記載のサービスマン手配方法。
【請求項８】
前記優先度は優先度レベルを含み、
前記サービスマン情報は、サービスマンの現在の状態を含み、
前記手配手順は、前記サービスマン情報の前記現在の状態に基づきサービスマンの手配を行う際に当該サービスマンが他の障害対応により当該障害対応を行えない場合、前記他の障害対応の優先度レベルと、当該障害対応の優先度レベルを比較し、優先度レベルの高い方の障害対応を優先すべく当該サービスマンの手配を行うこと、
を特徴とする請求項７記載のサービスマン手配方法。
【請求項９】
前記サービスマン情報は、障害対応の熟練度を含み、
前記手配手順は、前記サービスマン情報の前記現在の状態に基づきサービスマンの手配を行う際に当該サービスマンが他の障害対応により当該障害対応を行えない場合、当該障害対応の障害難易度と、当該サービスマンの熟練度を比較し、前記障害難易度より前記熟練度を有するサービスマンの手配を行うこと、
を特徴とする請求項７又は８記載のサービスマン手配方法。
【請求項１０】
前記熟練度は、障害対応完了される毎に対応内容はフィードバックされ、新たな熟練度として反映されること、
を特徴とする請求項９記載のサービスマン手配方法。
【請求項１１】
請求項６ないし１０何れか一項記載のサービスマン手配方法をコンピュータに実行させるためのプログラム。
【請求項１２】
請求項１１記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、管理装置、サービスマン手配方法、プログラム、及び記録媒体の分野に関する。
【背景技術】
【０００２】
システムの性能を示す指標の１つに可用性がある。可用性とは、単純にはシステムが使えるということであるが、さらにシステムの故障のしにくさを示す場合もある。近年、コンピュータ社会を迎え、あらゆる業態、環境下においてコンピュータシステムが稼動する中、これらシステムを安定的に稼動させるためには、日常的にシステムを監視し、万一の障害発生時には、迅速且つ効率的な復旧対応が求められており、従来から様々なシステム管理方法や障害対応方法が提案されている。
【０００３】
このようなシステム保守に関し、機器メーカや機器販売者（保守サービス提供者という）は、単に機器を販売して設置するだけではなく、その後の販売機器の安定的な運用を目的として、顧客に対して保守サービスを提供し、また各種対応内容に応じた保守サービス・メニュー（例えば３６５日２４時間対応など）を用意している。
【０００４】
ここで、顧客と保守サービス提供者との保守契約においては、一般にＳＬＡ（Service Level Agreement）と呼ばれる契約事項が盛り込まれることも多い。ＳＬＡとは、サービス提供者が、顧客にサービスの品質を保証する制度をいい、保守契約においては、保守サービス提供者が顧客システムの可用性について一定の範囲を保証する制度をいう。例えば、保守契約では、「ネットワークデバイス全体の稼動時間が全体の何％以上であること」、「一機器のサービスコールが月に何回以下であること」などといったサービス品質の保証項目や条件が取り交わされ、またそれらを達成できなかった場合の規定（保守料金減額、違約金等）も保守契約に含んでいる。
【０００５】
よって保守サービス提供者としては、保守契約を遵守すべく、保守契約対象の機器の稼働率（Up Time)を一定値以上に維持しなくてはならない。機器の稼働率を計測するため、故障が発生した際に顧客からのサービスコールを受け付けたオペレータは、管理システム（チケット管理システムという）を利用して、故障発生から修理完了までの流れを管理している。具体的に、チケット管理システムを利用してチケット（故障対応に関する記録又は情報等をいう）を発行する。機器修理を行うサービスマンは、機器修理を完了した後、発行された該当チケットをクローズさせる。このような一連の流れによって、機器の稼働率が計測される。
【０００６】
以上のように、高品質な保守サービスを提供し、さらには保守ビジネスを優位に進めていくためには、出来る限り機器の稼働率を最大（故障率を最小）にすることが非常に重要といえる。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来より高品質な保守サービス提供を目的として、機器の故障が発生した際、迅速な対応を行えるようサービスマン人員の拡充や教育による技術の向上といった施策が行われてきた。また一部では、サービスマンのサポート効率を高める目的で、サービスマンの位置情報や現在の状態、熟練度に応じて、障害案件に対するサービスマンの最適手配を行うという施策も行われている（例えば特許文献１参照）。
【０００８】
しかしながら、従来いずれのやり方においても、保守ビジネスや保守契約において重要視される稼働率の観点で、障害案件の重要度や優先順位を考慮しその対応を行うまでには至っていない。障害案件の重要度に関わらず、オペレータへのサービスコール先着順に障害案件が処理されているのが現状である。従って、さほど重要ではない障害案件が先に対応され、重要度の高い障害案件が後回しになるケースも生じてしまうという問題があった。
【０００９】
そこで本発明では上記のような問題に鑑みて、保守ビジネスの観点から、障害案件の重要度に応じたサービスマンの適切な手配を行い、保守機器の稼働率向上を図る管理装置、サービスマン手配方法、プログラム、及び記録媒体を提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本発明に係る管理装置は、保守契約対象の機器の障害が発生したとき、当該障害機器の障害対応を行うサービスマンを選定する管理装置であって、前記障害機器の保守契約上取り決めされた保証稼働率と、前記障害機器の障害発生時点での稼働率とを記憶する記憶手段と、前記保証稼働率及び前記稼働率の差分値に基づき、当該障害機器の障害対応を行うべき優先度を判定する判定手段と、前記優先度が所定値以上の場合、サービスマンを優先して前記障害機器の障害対応の手配を行う手配手段とを有する。
【００１１】
また上記課題を解決するため、前記管理装置において、前記手配手段は、前記優先度が所定値以上の場合、サービスマン情報に基づき手配を行うサービスマンの選定を行う。
【００１２】
また上記課題を解決するため、前記管理装置において、前記優先度は優先度レベルを含み、  前記サービスマン情報は、サービスマンの現在の状態を含み、前記手配手段は、前記サービスマン情報の前記現在の状態に基づきサービスマンの手配を行う際に当該サービスマンが他の障害対応により当該障害対応を行えない場合、前記他の障害対応の優先度レベルと、当該障害対応の優先度レベルを比較し、優先度レベルの高い方の障害対応を優先すべく当該サービスマンの手配を行う。
【００１３】
また上記課題を解決するため、前記管理装置において、前記サービスマン情報は、障害対応の熟練度を含み、前記手配手段は、前記サービスマン情報の前記現在の状態に基づきサービスマンの手配を行う際に当該サービスマンが他の障害対応により当該障害対応を行えない場合、当該障害対応の障害難易度と、当該サービスマンの熟練度を比較し、前記障害難易度より前記熟練度を有するサービスマンの手配を行う。
【００１４】
また上記課題を解決するため、前記管理装置において、前記熟練度は、障害対応完了される毎に対応内容はフィードバックされ、新たな熟練度として反映される。
【００１５】
なお、本発明の構成要素、表現または構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、などに適用したものも本発明の態様として有効である。
【発明の効果】
【００１６】
本発明によれば、保守ビジネスの観点から、障害案件の重要度に応じたサービスマンの適切な手配を行い、保守機器の稼働率向上を図る管理装置、サービスマン手配方法、プログラム、及び記録媒体を提供することができる。
【図面の簡単な説明】
【００１７】
【図１】本実施形態に係るシステム構成図である。
【図２】本実施形態の障害発生から障害対応完了までの全体的な流れを示すフロー図である。
【図３】本実施形態に係るサービスマン管理サーバ１３０の一実施形態の主要機能を示す機能ブロック図である。
【図４】サービスマン情報の一例を示す。
【図５】チケットの一例を示す。
【図６】機器情報の一例を示す。
【図７】本実施形態に係る各サーバの一実施形態の主要構成を示すハードウェア構成図である。
【図８】本実施形態に係るサービスマン手配の処理動作を示すフローチャートである。
【図９】「熟練度」の情報をより詳細に示す図である。
【図１０】本実施形態に係るサービスマン手配の処理動作を示すフローチャートである。
【発明を実施するための形態】
【００１８】
以下、本発明を実施するための最良の形態を各実施形態において図面を用いて説明する。
【００１９】
[概要]
図１は、本実施形態に係るシステム構成図である。図に示されるように、サービスサイト（保守サービス提供者側）１００には、チケット管理サーバ１１０、チケット管理サーバ１２０、サービスマン管理サーバ１３０、サービスマン端末１４０、オペレータ端末１５０を含み、顧客サイト（顧客側）２００には、機器２１０を含み構成される。
【００２０】
また図２は、本実施形態の障害発生から障害対応完了までの全体的な流れを示すフロー図である。まず図１及び図２を参照しながら、全体的な流れの把握を目的として、本実施形態を概要的に説明していく。
【００２１】
顧客サイト２００には、保守対象の機器２１０が設置されている。顧客と保守サービス提供者は、当該機器２１０に対して保守契約を交わしており、保守契約において「稼働率（Up Time）」をある一定値以上を維持する旨の契約がなされている。
【００２２】
チケット管理サーバ１１０は、保守機器の障害に関する状況を管理する保守管理サーバであり、障害案件毎にチケットという概念の情報を用いて顧客サイト２００の機器２１０を管理する。チケットとは、故障対応に関する記録又は情報等をいう（チケットの具体例は再度後述）。
【００２３】
機器情報管理サーバ１２０は、顧客サイト２００の保守機器２１０に関する情報を、例えば設置時及び定期的に収集するサーバである。またチケット管理サーバ１１０から各機器２１０の障害案件のチケットに関する情報も定期的に収集し、収集された情報を基に顧客向けのレポートが作成される。
【００２４】
サービスマン管理サーバ１３０は、保守サービス提供者であるサービスマンに関する情報を管理するサーバである。また故障発生時には、適切なサービスマンを選出し、サービスマンの手配、アサインを行う。
【００２５】
以上のシステム構成図(図１)において、障害発生から障害対応完了までの全体的な流れを説明する（図２）。
【００２６】
まず顧客サイト２００にて機器２１０の障害（故障）が発生する（Ｓ２０１）。障害が発生すると、顧客からオペレータへのサービスコールがなされることにより、障害が認識される（Ｓ２０２）。またもしくは、顧客サイト２００に、例えばネットワーク監視システムが導入されている場合、監視システムが機器障害を検知しオペレータへ通知することによっても障害が認識されうる。
【００２７】
オペレータは、チケット管理サーバ１１０を操作し、新規のチケットを発行する（Ｓ２０３）。チケット発行により当該障害案件はオープンする。つまり障害案件が提起されたことになる。
【００２８】
続いて、障害案件に対応するためにはサービスマンのアサインが必要となるので、サービスマン管理サーバ１３０は、障害案件に対応するサービスマンの手配を行う（Ｓ２０４）。手配は、例えばサービスマン端末１４０への連絡（メール含む）により行われる。
【００２９】
当該サービスマンは、サービスマン管理サーバ１３０からサービスマン端末１４０を介して指示を受けると、顧客サイト２００の機器２１０の障害対応を行う。障害対応は、リモート及びオンサイトからの作業を含む。
【００３０】
そして障害対応が完了すると、当該サービスマンはサービスマン端末１４０を介してチケット管理サーバ１１０にアクセスし、チケットのクローズを行う（Ｓ２０６）。つまり当該障害案件が終了されたことになる。なお、チケット発行に伴って故障機器の稼働率は低下し始め、チケットがクローズされると故障機器の稼働率の低下は停止するので、保守機器の稼働率を向上させるには、いかに適切なサービスマンを迅速に手配するかが重要といえる。
【００３１】
このように、実施形態に係るサービスマン管理サーバ１３０は、稼働率（Up Time）に基づいて障害案件の重要度を判定し、また障害案件に適切に対応可能なサービスマンの選定を行って、サービスマンの手配を行う。以下、詳しく説明していく。
【００３２】
[実施形態１]
＜サービスマン管理サーバ＞
サービスマン管理サーバ１３０は、保守サービス提供者であるサービスマンに関する情報を管理するサーバである。また保守機器２１０の障害発生時には、適切なサービスマンを選出し、サービスマンの手配、アサインを行う。
【００３３】
(機能)
図３は、本実施形態に係るサービスマン管理サーバ１３０の一実施形態の主要機能を示す機能ブロック図である。サービスマン管理サーバ１３０は、主要な機能として、機器情報取得部１３１、チケット情報取得部１３２、チケット優先度判定部１３３、サービスマン手配部１３４、サービスマン状態判定部１３５、サービスマン情報１３６、サービスマン指示部１３７を含む構成である。以下簡潔に説明する。
【００３４】
機器情報取得部１３１は、機器情報管理サーバ１２０から、障害機器の保守契約上取り決めされた「保証稼働率」を取得し、また障害機器の障害発生時点での「稼働率」を取得する。顧客と保守サービス提供者との保守契約では、ＳＬＡ契約事項が盛り込まれており、契約上、この両者間で取り決めされた稼働率を保証稼働率と呼ぶこととする。また障害機器の障害発生時点での稼働率を単に稼働率と呼ぶこととする。保証稼働率及び稼働率は、機器情報管理サーバ１２０の機器情報１２１に含まれている。
【００３５】
チケット情報取得部１３２は、チケット管理サーバ１１０からチケット情報１１１を取得する。チケット情報取得部１３２は、チケット管理サーバ１１０を常に監視しており、チケット発行を感知すると、サービスマン手配部１３４にその旨通知する。即ちチケット発行の感知により障害の発生がサービスマン管理サーバ１３０上で認識される。
【００３６】
チケット優先度判定部１３３は、保証稼働率及び稼働率の差分値に基づき、当該障害機器の障害対応を行うべき優先度を判定する。仮に差分値が小さい場合、迅速に障害対応を行わなければ保証稼働率を維持することが困難になってくる。従って、所定差分値（閾値）以下である場合、迅速に障害対応を行うべきであるので、その優先すべき程度を判定する（詳細後述）。
【００３７】
サービスマン手配部１３４は、特に、保証稼働率及び稼働率の差分値が所定差分値以下（即ち優先度が所定値以上）の場合、サービスマン状態を考慮してサービスマンを選定、優先して手配する。
【００３８】
サービスマン状態判定部１３５は、サービスマン情報１３６に基づき、現在アサイン可能なサービスマンを判定する。判定結果はサービスマン手配部１３４に通知される。
【００３９】
サービスマン指示部１３７は、サービスマン手配部１３４の指示により、具体的手段（メール等）を用いて、顧客サイト名や障害機器などを通知し、サービスマンに障害対応の指示を行う。
【００４０】
なおこれらの機能は、実際にはＣＰＵが実行するプログラムによりコンピュータ（サービスマン管理サーバ１３０）に実現させるものである。例えば、各種機能部は、サービスマン管理プログラムなどにより実現できる。また、上記各機能部構成は一例であり、サービスマン手配部１３４が最終的にサービスマンを手配するので、サービスマン手配部１３４に全ての機能を備えさせることもでき、この場合、サービスマン手配部１３４が機器情報及びチケット情報の取得からチケット優先度判定、サービスマン状態判定を行ってサービスマンを選定し、サービスマンに指示を出すように構成することもできる。
【００４１】
(サービスマン情報)
図４は、サービスマン情報の一例を示す。サービスマン情報１３６は、保守サービス提供者のサービスマンに関する情報であり、１人のサービスマン毎に作成される。またサービスマン管理サーバ１３０の補助記憶装置１０４（図７）等の記憶手段に保持されている。
【００４２】
「サービスマン名」は、サービスマンの名称を示す。「所属」は、サービスマンの所属部署を示す。「担当範囲」は、サービスマンが担当しているエリアや担当している顧客先を示す。「連絡先」は、サービスマンの連絡先を示す。例えばサービスマン端末１４０のメールアドレス、電話番号等を含むので、サービスマン手配時、障害対応指示を行う際に使用される。これら情報は基本的に予め登録され変更の際は都度更新される。
【００４３】
「所在情報」は、ＧＰＳによるサービスマンの現在の位置情報（例えば座標情報）を示す。サービスマン手配の際、現在の位置情報から顧客サイトに近いサービスマンを判断するときに使用される。「現在の状態」は、サービスマンの現ステータスを示す。例えば、待機中、作業中、移動中、不在等の状態があり、サービスマン手配の際、障害対応可能なサービスマンを判断するときに使用される。
【００４４】
「熟練度」は、機器毎（機器種類毎）のサービスマンの対応能力に応じた熟練度、スキルを示す。「熟練度」については、後述の実施形態２において詳しく説明する。
【００４５】
＜チケット管理サーバ＞
チケット管理サーバ１１０は、保守機器の障害に関する状況を管理する保守管理サーバであり、障害案件毎にチケットという概念の情報を用いて顧客サイト２００の機器２１０を管理する。チケットとは、障害対応に関する記録又は情報等をいう。
【００４６】
顧客サイト２００にて機器２１０の障害が発生した場合、顧客からオペレータへ障害発生の旨の連絡（サービスコール）がなされる。またもしくは、顧客サイト２００に、例えばネットワーク監視システムが導入されている場合、監視システムが機器故障を検知しオペレータへ通知することによっても障害が認識されうる。
【００４７】
障害が認識されると、オペレータはチケット管理サーバ１１０にて新規の障害案件のチケットを発行する操作を行なう。オペレータのチケット発行により当該障害案件はオープンし、サービスマンにより機器修理が完了されると、発行されたチケットはクローズされる。なお顧客サイト２００に、例えば上述のネットワーク監視システムが導入されている場合、オペレータを介さずに監視システムによりチケットを発行する構成も可能であるが、ここでは構成を容易にするためオペレータによりチケットは発行されるものとして以下説明していくものとする。
【００４８】
（チケットの一例）
図５は、チケットの一例を示す。チケット（障害情報に相当）は、機器障害の際に作成される障害に関する記録であり、１の障害毎に作成されるので、図５は１のチケットの内容を示している。
【００４９】
「Ticket ID」は、チケットを識別するためのＩＤ（固有値）を示す。チケットは、一の障害毎に作成されるので、「Ticket ID」もまた一の障害毎に自動発行される重複不可能な固有値である。「Create Date」は、チケットの作成日を示す。例えばオペレータによりチケットが作成された日時が記録される。また「Resolve Date」は、チケットの解決日を示す。例えばサービスマンにより故障機器が修理されたことに伴いチケットがクローズされた日時が記録される。なおいずれも年月日時分秒まで記録可能である。
【００５０】
「Type」は、障害の種類や内容を示す。例えば、機器２１０が画像形成装置である場合、「紙詰まり」、「トナー」、「各種エラー」などが記録される。「Level of Difficulty」は、故障難易度を示す。チケット作成時、オペレータが判断し入力されてもよいし、「Type」による障害の種類や内容に応じて入力されてもよい。「Level of Demand」は、顧客の要望レベルを示す。顧客が優先して対応を望むチケットほど高いレベルの要望レベルが入力される。オペレータにより判断され入力される。
【００５１】
「Machine Serial Number」は、故障した機器のシリアルナンバーを示す。故障が発生した機器を識別するためものである。「Description」は、機器故障の具体的な記述を示す。「Solution」は、解決方法（修理方法）の具体的な記述を示す。「Total Time」は、チケットのクローズまでにかかった時間を示す。「Create Date」と「Resolve Date」の差分値から自動入力されてもよい。「Creater」は、チケット発行者（例えばオペレータ名）を示す。またチケット発行者の属性情報や、その他障害に関する項目が記録されてもよい。
【００５２】
＜機器情報管理サーバ＞
機器情報管理サーバ１２０は、顧客サイト２００の保守機器２１０に関する機器情報１２１を設置時に登録し、また定期的に収集するサーバである。また、チケット管理サーバ１１０から各機器２１０の障害案件のチケットに関する情報も定期的に収集しており、収集された情報を基にして契約上の期間毎に顧客向けの保守レポートが作成される。
【００５３】
障害発生の際、サービスマン管理サーバ１３０に対して、保証稼働率や稼働率を含む機器情報１２１を提供する。上述したように機器情報１２１は、サービスマン管理サーバ１３０によるサービスマン手配の際に使用される。
【００５４】
なお、機器情報管理サーバ１２０は、保守機器２１０に関する機器情報１２１を定期的に収集しているので、さらに監視機能を有するよう構成するとよい。この場合、機器情報管理サーバ１２０はネットワーク監視システムとしても機能するので、機器情報１２１を定期的に収集しつつ、機器２１０の障害が発生すると機器障害を検知しオペレータへ通知する。
【００５５】
（機器情報）
図６は、機器情報の一例を示す。機器情報１２１は、保守機器２１０に関する情報であり、１の機器毎に作成されるので、図６は１の機器についての情報の内容を示している。機器情報１２１は、大きく基本情報、契約情報、状態情報に分類できる。基本情報は、機器の基本的な属性情報からなり設置時に登録される固定的な情報である。契約情報は、当該機器の保守契約情報からなり設置時に登録される固定的な情報である。状態情報は、当該機器の保守情報からなり随時に更新される可変的な情報である。
【００５６】
「顧客ナンバー」は、機器の所属を特定するための顧客固有の番号を示す。「機器名」は、機器名称を示す。「機器モデル名」は、機器モデル名や型番などを示す。「シリアルナンバー」は、機器固有のシリアルナンバーを示す。「ネットワークアドレス」は、ＩＰアドレスなどの通信アドレスを示す。「顧客側管理者名」は、顧客側管理者名、またその連絡先を示す。「担当サービスマン」は、当該機器を担当しているサービスマン名、またその連絡先を示す。
【００５７】
「保証稼働率」は、契約上の稼働率を示す。上述のように顧客と保守サービス提供者は、機器２１０に対して保守契約を交わしており、保守契約において稼働率（保証稼働率）をある一定値以上を維持する旨の契約がなされている。「対応時間」は、契約上保守対応を行う時間を示す。平日９−１８時、２４時間３６５日など保守契約による。「パーツ保証」は、交換パーツの保証レベルを示す。完全無償交換、一部有償交換など保守契約による。
【００５８】
「稼働率」は、当該機器の稼働率を示す。「稼動時間」は、当該機器の稼動時間を示す。「障害時間」は、当該機器の障害時間を示す。「修理時間」は、当該機器が故障した際その修理時間を示す。「修理回数」は、当該機器が故障した際その修理回数を示す。「サービスコール数」は、オペレータへのサービスコール回数を示す。
【００５９】
なおここで、実際の稼働率は、「（稼働時間／全体時間）×１００」により算出されうる。例えば、保守対象期間である全体時間３０日（７２０時間）、障害時間８時間である場合、稼働時間は７１２時間なので、稼働率は約９８．８８％となる。
【００６０】
＜ハードウェア＞
ここで、チケット管理サーバ１１０、機器情報管理サーバ１２０、サービスマン管理サーバ１３０のハードウェア構成について簡潔に触れておく。図７は、本実施形態に係る各サーバの一実施形態の主要構成を示すハードウェア構成図である。主要な構成として、ＣＰＵ１０１、ＲＯＭ（Read Only Memory）１０２、ＲＡＭ（Random Access Memory）１０３、補助記憶装置１０４、記憶媒体読取装置１０５、入力装置１０６、表示装置１０７、及び通信装置１０８を含む構成である。
【００６１】
ＣＰＵ１０１は、マイクロプロセッサ及びその周辺回路から構成され、装置全体を制御する回路である。また、ＲＯＭ１０２は、ＣＰＵ１０１で実行される所定の制御プログラム（ソフトウェア部品）を格納するメモリであり、ＲＡＭ１０３は、ＣＰＵ１０１がＲＯＭ１０２に格納された所定の制御プログラム（ソフトウェア部品）を実行して各種の制御を行うときの作業エリア（ワーク領域）として使用するメモリである。
【００６２】
補助記憶装置１０４は、汎用のＯＳ（Operating System）、各種情報を格納する装置であり、不揮発性の記憶装置であるＨＤＤ（Hard Disk Drive）などが用いられる。なお、上記各種情報は、補助記憶装置１０４以外にも、ＣＤ−ＲＯＭ（Compact Disk - ROM）やＤＶＤ（Digital Versatile Disk）などの記憶媒体やその他のメディアを記憶されてもよく、これらの記憶媒体に格納された各種情報は、記憶媒体読取装置１０５などのドライブ装置を介して読み取ることが可能である。また、必要に応じて記録媒体を記憶媒体読取装置１０５にセットすることで、各種情報が得られる。
【００６３】
入力装置１０６は、ユーザが各種入力操作を行うための装置である。入力装置１０６は、マウス、キーボード、表示装置１０７の表示画面上に重畳するように設けられたタッチパネルスイッチなどを含む。表示装置１０７は、例えば、ＬＣＤ(Liquid Crystal Display)、ＣＲＴ(Cathode Ray Tube)などから構成される。通信装置３は、ネットワーク５を介して、被管理装置３や機器管理端末２との通信を行う装置である。有線ネットワークや無線ネットワークなど含む各種ネットワーク形態に応じた通信をサポートする。
【００６４】
以上、各サーバのハードウェア構成であるが、サービスマン端末１４０やオペレータ端末１５０のハードウェアについての説明は省略する。一般的なＰＣや情報処理端末（携帯端末）が備えるハードウェアや機能成を備えていればよいからである。
【００６５】
＜動作＞
図８は、本実施形態に係るサービスマン手配の処理動作を示すフローチャートである。既説及び重複する点もあるが、サービスマン手配の処理動作について図面を参照しながら説明していく。
【００６６】
まず顧客サイト２００にて機器２１０の障害（故障）が発生すると、顧客からオペレータへのサービスコールがなされることにより、障害が認識される。またもしくは、顧客サイト２００に、例えばネットワーク監視システムが導入されている場合、監視システムが機器故障を検知しオペレータへ通知することによっても障害が認識されうる。オペレータは、チケット管理サーバ１１０を操作し、新規のチケットを発行する。チケット発行により当該障害案件はオープンする。つまり障害案件が提起されたことになる。
【００６７】
チケット管理サーバ１１０にてチケットが発行されると、サービスマン管理サーバ１３０のチケット情報取得部１３２は、定期的なポーリングによってチケット発行を感知する（Ｓ８０１）。チケット情報取得部１３２は、チケット管理サーバ１１０を常に監視しており、チケット発行を感知すると、サービスマン手配部１３４にその旨通知する。即ちチケット発行の感知により障害の発生がサービスマン管理サーバ１３０上で認識される。
【００６８】
なお、本実施形態ではサービスマン管理サーバ１３６側がチケット管理サーバ１１０に対してポーリングを行ってチケット発行を感知する構成としたのは、既設のチケット管理サーバに対しても本実施形態のサービスマン管理サーバ１３０をそのまま適用できる点で効果的だからである。つまり、既設のチケット管理サーバに変更を加える手間が不要である。勿論、これに対しチケットが発行されるとチケット管理サーバ１１０から、サービスマン管理サーバ１３６にチケット情報を送信するように構成することもできる。この場合、即時性が保たれる点で効果的である。
【００６９】
サービスマン手配部１３４は、チケット情報取得部１３２に発行されたチケット情報１１１を取得させる（Ｓ８０２）。またサービスマン手配部１３４は、機器情報取得部１３１にチケット情報１１１の「Machine Serial Number」（故障した機器のシリアルナンバー）で特定される機器の機器情報１２１を取得させる(Ｓ８０３)。取得されたチケット情報１１１及び機器情報１２１は、補助記憶装置１０４等の記憶手段に保持しておく。
【００７０】
チケット優先度判定部１３３は、取得された機器情報１２１に含まれる保証稼働率及び稼働率に基づき、当該障害機器の障害対応を行うべき優先度を算出、判定する(Ｓ８０４)。即ち、顧客と契約上取り決めされた目標とされる保証稼働率（Up Time）の値と、機器の現在時点の稼働率（Up Time）の値とを比較して、両値の差分値に基づき優先度（優先順位）を判定する。ここで優先度は、保守サービス提供者によって予め規定され、補助記憶装置１０４等に保持されているものを使用する。例えば、
・現在時点の稼働率の値と保証稼働率の値との差が20%未満の場合、「優先度１」
・現在時点の稼働率の値と保証稼働率の値との差が21%以上40%未満の場合、「優先度２」
・現在時点の稼働率の値と保証稼働率の値との差が41%以上60%未満の場合、「優先度３」
・現在時点の稼働率の値と保証稼働率の値との差が61%以上80%未満の場合、「優先度４」
・現在時点の稼働率の値と保証稼働率の値との差が81%以上の場合、「優先度５」
のように規定されうる。
【００７１】
例えば、現在時点の稼働率が「８９％」、保証稼働率が「７０％」であるとすると、その差は「１９％」であるので、「優先度１」と判定される。このように、現在時点の稼働率の値と保証稼働率の値との差が所定閾値以下、つまり、優先度が所定値（所定程度）を超えているか否か比較される。勿論優先度の規定値は、運用に応じてまた契約に応じて、任意の値を定めることができる。
【００７２】
サービスマン手配部１３４は、チケット優先度判定部１３３により判定された優先度が所定値以上の場合、早急に本障害案件に対応すべきと判断し、サービスマン状態を考慮してサービスマンを選定、優先して手配する処理を行う（Ｓ８０５）。ここでは、早急に対応すべきとされる障害案件の優先度の所定値を「優先度２」とすると、上述の例の場合、チケット優先度判定部１３３により判定された優先度は「優先度１」であるので、早急に対応すべき障害案件と判断され、Ｓ８０６へ進む。
【００７３】
次に、サービスマン状態判定部１３５は、サービスマン情報１３６に基づき、現在アサイン可能なサービスマンを判定、抽出する。判定結果はサービスマン手配部１３４に通知される。具体的に、サービスマン情報１３６の「位置情報」に基づき、障害発生の顧客サイトに近い順にサービスマンを抽出する（Ｓ８０６）。地理的に近いほど迅速に顧客サイトに移動できるからである。
【００７４】
またサービスマン状態判定部１３５は、サービスマン情報１３６の「現在の状態」に基づき、「待機中」のステータスであるサービスマンを抽出する（Ｓ８０７）。「現在の状態」が「作業中」、「移動中」、又は「不在」の場合、障害対応は不可能だからである。
【００７５】
待機中の該当者があれば、判定結果は、該当サービスマンの「連絡先」とともにサービスマン手配部１３４に通知される。なお、ここで該当者がなければＳ８０６に戻り、再度顧客サイトに近い順にサービスマンを抽出すればよい。サービスマン手配部１３４は、「連絡先」に基づき、該当のサービスマンへ障害対応の指示を行う（Ｓ８０９）。
【００７６】
一方、Ｓ８０４にて例えば「優先度３」と算出、判定された場合、Ｓ８０５にて早急に対応すべき障害案件ではないと判断される。この場合、サービスマン状態判定部１３５は、サービスマン情報１３６の「担当サービスマン名」に基づき、当該顧客を担当するサービスマンを抽出する（Ｓ８１０）。そしてサービスマン手配部１３４は、「連絡先」に基づき、該当のサービスマンへ障害対応の指示を行う（Ｓ８０９）。担当サービスマンは、障害対応の指示を受けるものの、すぐに対応が要求されているわけではなく、当該顧客担当として自身の判断やスケジュールに応じて当該障害案件の対応を行うことができる。
【００７７】
以上このように、本実施形態に係るサービスマン手配部１３４は、顧客と保守契約上取り決めされた目標とされる保証稼働率（Up Time）の値と、機器の現在時点の稼働率（Up Time）の値とに基づき、当該障害案件の対応の重要度、優先度（緊急度ともいえる）を判定し、サービスマンの手配を行う。従来、オペレータへのサービスコール先着順、また障害の被害状況等に応じて障害案件が処理されているのが現状であるところ、本実施形態によれば、保守ビジネスや保守契約において重要視される稼働率の観点で、障害案件の重要度や優先順位を考慮しサービスマンがアサインされ迅速な障害対応を行える。チケット発行に伴って故障機器の稼働率は低下し始め、チケットがクローズされると故障機器の稼働率の低下は停止するところ、特に保守契約上、保証稼働率の遵守が危ぶまれる保守機器について、出来る限り稼働率の低下を防止し、保証稼働率の遵守ひいては保守契約の遵守という効果が期待される。
【００７８】
[実施形態２]
上述の実施形態１においては、サービスマン手配部１３４は、チケット優先度判定部１３３により判定された優先度が所定値以上の場合、早急に本障害案件に対応すべきと判断し、サービスマンを選定、優先して手配する処理を行った。つまり、優先度が所定値以上か以下かの２つケースによって、早急に対応すべき障害案件か否かが判断された。
【００７９】
本実施形態２においては、優先度の段階（レベル）に応じてよりきめ細かい障害対応が行えるよう、熟練度やスキルを考慮しながらサービスマンを選定、優先して手配する処理を行うものである。これにより、より迅速な障害案件のクローズを図り、出来る限り稼働率の低下を防止し、保証稼働率の遵守ひいては保守契約の遵守という効果を奏することができる。以下説明していく。
【００８０】
＜熟練度＞
サービスマン管理サーバ１３０は、障害発生時、適切なサービスマンを選出し、サービスマンの手配、アサインを行う。適切なサービスマンを選出にあたっては、サービスマン情報１３６（図４）が参照されることは上述した通りである。ここでサービスマン情報１３６（図４）には、「熟練度」の情報が含まれる。「熟練度」は、機器毎（機器種類毎）のサービスマンの対応能力に応じた熟練度、スキルを示す。
【００８１】
図９は、「熟練度」の情報をより詳細に示す図である。図９の「熟練度」の情報は、サービスマンの対応可能な分野毎の熟練度レベルの情報を含み、機器が画像形成装置（ＭＦＰ）を想定した場合の分野毎の熟練度レベルが示されている。
【００８２】
熟練度レベルは例えば次のように算出できる。サービスマン毎に、障害難度(例えばLv1〜Lv5等)別の対応件数を実績として記録しておき、障害難度ごとの係数と掛け合わせ、その合計値を熟練度とする。合計値が大きいほど熟練度は高くなる。障害難度が高いほど、係数の値を大きくする。例えば、Lv1は係数0.2、Lv2は係数0.4、Lv3は係数0.6、Lv4は係数1.0、Lv5は係数1.5など、とする。
【００８３】
このような「熟練度」の情報を用いることによって、電子系の障害案件が発生した場合、サービスマン状態判定部１５３は、電子系の熟練度が高いサービスマンを優先して抽出することができる。また電子系熟練度が等しいサービスマン同士の場合、全体熟練度が高いサービスマンを優先して抽出することもできる。即ちサービスマン管理サーバ１３０において、サービスマンの得意とする修理分野を記録・管理しておき、障害発生時サービスマンを抽出する際に、全体的（一般的）な熟練度だけでなく、修理分野毎の熟練度の情報を基にして、より適切なサービスマンの手配を行える。
【００８４】
＜動作＞
図１０は、本実施形態に係るサービスマン手配の処理動作を示すフローチャートである。上述の実施形態１の図８のフローチャートと同様のステップは同一番号を付してある。つまりＳ８０１〜Ｓ８０６、Ｓ８０９、Ｓ８１０は同様の処理ステップであるのでここは簡単な説明に留め、Ｓ１００１〜Ｓ１００６（点線囲い）について特に説明していく。
【００８５】
まず顧客サイト２００にて機器２１０の障害（故障）が発生すると、顧客からオペレータへのサービスコールがなされることにより、またもしくは監視システムが機器障害を検知することにより、障害が認識される。オペレータは、チケット管理サーバ１１０を操作し、新規のチケットを発行する。つまり障害案件が提起されたことになる。
【００８６】
チケット管理サーバ１１０にてチケットが発行されると、サービスマン管理サーバ１３０のチケット情報取得部１３２は、定期的なポーリングによってチケット発行を感知する（Ｓ８０１）。
【００８７】
サービスマン手配部１３４は、チケット情報取得部１３２に発行されたチケット情報１１１を取得させる（Ｓ８０２）。またサービスマン手配部１３４は、機器情報取得部１３１にチケット情報１１１の「Machine Serial Number」（故障した機器のシリアルナンバー）で特定される機器の機器情報１２１を取得させる(Ｓ８０３)。
【００８８】
チケット優先度判定部１３３は、取得された機器情報１２１に含まれる保証稼働率及び稼働率に基づき、当該障害機器の障害対応を行うべき優先度を算出、判定する(Ｓ８０４)。顧客と契約上取り決めされた目標とされる保証稼働率（Up Time）の値と、機器の現在時点の稼働率（Up Time）の値とを比較して、両値の差分値に基づき優先度（優先順位）を判定する。優先度は予め規定されているものを使用し、上述したように、例えば、現在時点の稼働率の値と保証稼働率の値との差により、「優先度１」、「優先度２」、「優先度３」、「優先度４」、「優先度５」のように規定されうる。
【００８９】
サービスマン手配部１３４は、チケット優先度判定部１３３により判定された優先度が所定値以上の場合、早急に本障害案件に対応すべきと判断し、サービスマン状態を考慮してサービスマンを選定、優先して手配する処理を行う（Ｓ８０５）。ここでは、早急に対応すべきとされる障害案件の所定値を「優先度２」とすると、チケット優先度判定部１３３により判定された優先度は「優先度１」であるので、早急に対応すべき障害案件と判断され、Ｓ８０６へ進む。
【００９０】
次に、サービスマン状態判定部１３５は、サービスマン情報１３６に基づき、現在アサイン可能なサービスマンを判定、抽出する。判定結果はサービスマン手配部１３４に通知される。具体的に本実施形態においては、サービスマン情報１３６の「位置情報」、「熟練度」、さらに「優先度」、「故障難度」、「顧客の要望レベル」等に基づき、現在アサイン可能なサービスマンを判定、抽出する。以下説明する。
【００９１】
まず、障害発生の顧客サイトに近い順にサービスマンを抽出する（Ｓ８０６）。地理的に近いほど迅速に顧客サイトに移動できるからである。
【００９２】
次に、顧客サイトに近いとして抽出されたサービスマンが「熟練度」に基づき熟練度のレベルが一定以上か否か判定される（Ｓ１００１）。早急に対応すべき障害案件は、ある一定以上のスキルを有するサービスマンが手配されることが望ましい。従って例えば、一定レベルが全体熟練度がLV3以上と定められている場合、サービスマン情報１３６の全体熟練度（図９）がLV3以上のサービスマンか否か判定される。また図９に示されるように、「熟練度」には、分野毎の熟練度レベルの情報が含まれているので、チケット情報１１１の「Type」の情報と照らし合わせ、障害の種類や内容に応じた分野毎の熟練度レベルを採用することも可能である。この場合、障害の種類とサービスマンの専門分野に合った熟練度レベルの判定を行うことができる。一方、一定の熟練度レベルに満たないサービスマンであった場合、Ｓ８０６に戻り、顧客サイトに次に近いサービスマンが抽出される。
【００９３】
そしてサービスマン情報１３６の「現在の状態」に基づき、一定の熟練度レベルに満たすサービスマンは、「待機中」のステータスであるか判定される。（Ｓ１００２）。「作業中」や「不在」の場合、障害対応は不可能だからである。待機中の該当者があれば、判定結果は、該当サービスマンの「連絡先」とともにサービスマン手配部１３４に通知される。サービスマン手配部１３４は、「連絡先」に基づき、該当のサービスマンへ障害対応の指示を行う（Ｓ８０９）。
【００９４】
一方、一定の熟練度レベルに満たすサービスマンが「待機中」でなければ、そのサービスマンの「現在状態」としては「作業中」や「移動中」の場合が考えられる。この場合、現在作業中（移動中）の障害案件と比較し、いずれの障害案件に対応すべきかが判定される。なお、「現在状態」が「不在」の場合、サービスマンの休暇等が考えられ、いずれにしても対応は不可能であるので、Ｓ８０６に進み、次に候補となるサービスマンが抽出されればよい。この点フロー上は省略している。
【００９５】
一定の熟練度レベルに満たすサービスマンが「作業中」の場合、優先度の比較が行われる。つまり、現在サービスマンが作業中の案件と優先度の比較を行う（Ｓ１００３）。例えば本障害案件は「優先度２」と判定されている（Ｓ８０４）。そして現在サービスマンが作業中の案件の優先度が「優先度５」である場合、サービスマンは現在の作業を一旦中断し、優先すべき「優先度２」の本障害案件に対応すべきと判定される。この場合、別のサービスマンを作業中の案件に対して手配する（Ｓ１００６）。手配方法は例えばＳ８０６以降の同様の処理によって手配できる。そして、判定結果は、作業中であった当該サービスマンの「連絡先」とともにサービスマン手配部１３４に通知される。サービスマン手配部１３４は、「連絡先」に基づき、該当のサービスマンへ障害対応の指示を行う（Ｓ８０９）。
【００９６】
また一方、現在サービスマンが作業中の案件の方がその優先度が高い場合、次に「故障難度」の比較を行う（Ｓ１００４）。チケット情報１１１の「Level of Difficulty」により故障難易の比較を行うことができる。「Level of Difficulty」は、チケット発行時にオペレータにより判断され入力されたり、監視システムと連携し自動入力されうる。例えば、「Level of Difficulty」はＡ〜ＥやLv1〜5などのように段階評価された値を有する。そして本障害案件の「故障難度」が、現在サービスマンが作業中の案件の「故障難度」より高い場合、サービスマンは一旦作業を中断し、故障難度の高い本障害案件に対応すべきと判定される。この場合、同様に別のサービスマンを作業中の案件に対して手配する（Ｓ１００６）。そしてまた判定結果は、作業中であった当該サービスマンの「連絡先」とともにサービスマン手配部１３４に通知され、該当のサービスマンへ障害対応の指示がなされる（Ｓ８０９）。
【００９７】
また一方、現在サービスマンが作業中の案件の方がその故障難度が高い場合、次に「顧客の要望レベル」の比較を行う（Ｓ１００５）。チケット情報１１１の「Level of Demand」により要望レベルの比較を行うことができる。「Level of Demand」は、チケット発行時にオペレータにより判断され入力されうる。例えば、「Level of Demand」はＡ〜ＥやLv1〜5などのように段階評価された値を有する。そして本障害案件の「顧客の要望レベル」が、現在サービスマンが作業中の案件の「顧客の要望レベル」より高い場合、サービスマンは一旦作業を中断し、要望レベルの高い本障害案件に対応すべきと判定される。この場合、同様に別のサービスマンを作業中の案件に対して手配する（Ｓ１００６）。そしてまた判定結果は、作業中であった当該サービスマンの「連絡先」とともにサービスマン手配部１３４に通知され、該当のサービスマンへ障害対応の指示がなされる（Ｓ８０９）。
【００９８】
また一方、現在サービスマンが作業中の案件の方がその顧客の要望レベルが高い場合、再びＳ８０６に戻り、顧客サイトに次に近いサービスマンが抽出される。なお、「熟練度」、「優先度」、「故障難度」、「顧客の要望レベル」のいずれか同一レベル値であったような場合は、さらに他の項目との兼ね合いや比較から最終的に手配すべきサービスマンを決定すればよい。
【００９９】
また一方で、現在サービスマンが作業中の案件の方の優先度が高い場合に再びＳ８０６に戻り、顧客サイトに次に近いサービスマンを抽出し、同一レベルであった場合には故障難度の比較を行うといったように、「優先度」、「故障難度」、「顧客の要望レベル」に対する重要度を定めて、重要度の高い比較項目から比較を行い、同一レベルの際には次に重要度の高い比較項目に対しての比較を行うといった方法で手配すべきサービスマンを決定するようにしてもよい。
【０１００】
最後にサービスマンは、障害対応を完了した後、サービスマン端末１４０を介してチケット管理サーバ１１０にアクセスし、発行された該当チケットをクローズさせる。なおこのとき、障害対応完了する毎に対応内容（作業内容）はフィードバックされるので、チケット管理サーバ１１０とサービスマン管理サーバ１３０間で、サービスマン情報１３６の新たな「熟練度」として反映されるようにするとよい。つまり経験を熟練度値に反映させる。
【０１０１】
以上このように、本実施形態に係るサービスマン手配部１３４は、顧客と保守契約上取り決めされた目標とされる保証稼働率（Up Time）の値と、機器の現在時点の稼働率（Up Time）の値とに基づき、当該障害案件の対応の重要度、優先度（緊急度ともいえる）を判定するとともに、優先すべき重要案件に対しよりきめ細かい障害対応が行えるよう、サービスマンの熟練度やスキル等を考慮しながらサービスマンを選定、優先して手配する処理を行う。これにより、熟練度やスキルの高いサービスマンによって対応がなされるので、より迅速な障害案件のクローズを図り、出来る限り稼働率の低下を防止し、保証稼働率の遵守ひいては保守契約の遵守という効果を奏することができる。
【０１０２】
[補足１]
上述したように、サービスマン管理サーバ１３０のチケット情報取得部１３２は、定期的なポーリングによってチケット発行を感知し（Ｓ８０１）、チケット情報取得部１３２により発行されたチケット情報１１１が取得される（Ｓ８０２）。そしてチケット情報１１１が取得されると、サービスマン管理サーバ１３０のサービスマン手配部１３４は、早急に本障害案件に対応すべきか判断を行なってから、サービスマン状態を考慮してサービスマンを選定、優先して手配する処理を行う（Ｓ８０５）。
【０１０３】
ここで、ある一の定期的なポーリングによって、複数のチケット発行が感知され、複数のチケット情報１１１が取得される場合がある。保守サービス提供者は複数の顧客に対して保守サービスを提供しており、例えば全国各地においては定期的なポーリング間隔間で何件もの障害案件が発生しうるからである。
【０１０４】
サービスマン管理サーバ１３０は、チケットを同時に複数取得した際に、複数のチケット毎の優先度を比較し、優先度に応じてサービスマンを選定、優先して手配するとよい。チケットが発行されるとチケット管理サーバ１１０から、サービスマン管理サーバ１３６にチケット情報を送信するように構成されている場合も同様である。
【０１０５】
[補足２]
各実施形態において、発行されたチケットに対応して手配すべきサービスマンを決定するときに、チケット情報の「Machine Serial Number」と機器情報の「シリアルナンバー」および「ネットワークアドレス」または「顧客側管理社名」に記載された情報を用いて、障害案件に対応する機器または管理者連絡先に対して、現在障害対応中である旨あるいは「現在サービスマンが向かっています」等の障害対応のステータスを通知する、または機器情報管理サーバなどに通知させてもよい。
【０１０６】
これにより、顧客サイトにおいて機器を管理する管理者および機器の利用者は、管理者端末のディスプレイあるいは機器に搭載されたディスプレイを介して、障害が発生した機器に対する情報を得ることができ、余計な作業負荷の軽減に寄与することができる。
【０１０７】
特に監視システムによる障害の自動検知が行われ、既に本障害案件への対応が開始されているにも関わらず、サービスマンが到着するまでの間に利用者が再度オペレータに本障害を連絡する、といった重複作業の防止に繋がる。
【０１０８】
＜総括＞
以下、本実施形態に係るサービスマン管理サーバ１３０の作用効果について説明する。
【０１０９】
サービスマン管理サーバ１３０の構成において、保守契約対象の機器の障害が発生したとき、当該障害機器の障害対応を行うサービスマンを選定する管理装置であって、前記障害機器の保守契約上取り決めされた保証稼働率と、前記障害機器の障害発生時点での稼働率とを記憶する記憶手段と、前記保証稼働率及び前記稼働率の差分値に基づき、当該障害機器の障害対応を行うべき優先度を判定する判定手段と、前記優先度が所定値以上の場合、サービスマンを優先して前記障害機器の障害対応の手配を行う手配手段とを有する。
【０１１０】
このように、本実施形態に係るサービスマン管理サーバ１３０は、顧客と保守契約上取り決めされた目標とされる保証稼働率（Up Time）の値と、機器の現在時点の稼働率（Up Time）の値とに基づき、当該障害案件の対応の重要度、優先度（緊急度ともいえる）を判定し、サービスマンの手配を行う。従来、オペレータへのサービスコール先着順、また障害の被害状況等に応じて障害案件が処理されているのが現状であるところ、本実施形態によれば、保守ビジネスや保守契約において重要視される稼働率の観点で、障害案件の重要度や優先順位を考慮しサービスマンがアサインされ迅速な障害対応を行える。チケット発行に伴って故障機器の稼働率は低下し始め、チケットがクローズされると故障機器の稼働率の低下は停止するところ、特に保守契約上、保証稼働率の遵守が危ぶまれる保守機器について、出来る限り稼働率の低下を防止し、保証稼働率の遵守ひいては保守契約の遵守という効果が期待される。
【０１１１】
以上、図面を参照して本発明の実施形態について述べたが、これらは本発明の例示であり、以上以外にも様々な構成を採用することもできる。
【０１１２】
例えば、上述の実施形態においては、チケット管理サーバ１１０、チケット管理サーバ１２０、サービスマン管理サーバ１３０は、別個の装置により構成される構成としたが、これらサーバを１のサーバで構成することも可能である。このように構成すれば、導入コストや保守、また通信処理（ネットワーク負荷低減）の観点からより有利な効果を奏することができる。
【０１１３】
また、既に上述したが、本実施形態においては、サービスマン管理サーバ１３６側がチケット管理サーバ１１０に対してポーリングを行ってチケット発行を感知する構成とした。既設のチケット管理サーバに対しても本実施形態のサービスマン管理サーバ１３０をそのまま適用でき、既設のチケット管理サーバに変更を加える手間が不要であるからである。勿論、これに対しチケットが発行されるとチケット管理サーバ１１０から、サービスマン管理サーバ１３６にチケット情報を送信するように構成することもできる。このように構成すれば、即時性が保たれる点で効果的である。機器情報管理サーバ１２０は、保守機器２１０に関する機器情報１２１を定期的に収集しているので、さらに機器情報管理サーバ１２０が監視機能を有するよう構成するとよい。
【０１１４】
以上本発明によれば、保守ビジネスの観点から、障害案件の重要度に応じたサービスマンの適切な手配を行い、保守機器の稼働率向上を図る管理装置、サービスマン手配方法、プログラム、及び記録媒体を提供することが可能となる。
【０１１５】
なお、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【０１１６】
１００    サービスサイト
１０１    ＣＰＵ
１０２    ＲＯＭ
１０３    ＲＡＭ
１０４    補助記憶装置
１０５    記憶媒体読取装置
１０６    入力装置
１０７    表示装置
１０８    通信装置
１１０    チケット管理サーバ
１１１    チケット情報
１２０    機器情報管理サーバ
１２１    機器情報
１３０    サービスマン管理サーバ
１３１    機器情報取得部
１３２    チケット情報取得部
１３３    チケット優先度判定部
１３４    サービスマン手配部
１３５    サービスマン状態判定部
１３６    サービスマン情報
１３７    サービスマン指示部
１４０    サービスマン端末
１５０    オペレータ端末
２００    顧客サイト
２１０    機器
【先行技術文献】
【特許文献】
【０１１７】
【特許文献１】特開２００４‐１１０４９６号
【図１】
2011129055.tif 000003
【図２】
2011129055.tif 000004
【図３】
2011129055.tif 000005
【図４】
2011129055.tif 000006
【図５】
2011129055.tif 000007
【図６】
2011129055.tif 000008
【図７】
2011129055.tif 000009
【図８】
2011129055.tif 000010
【図９】
2011129055.tif 000011
【図１０】
2011129055.tif 000012