(57)【特許請求の範囲】
【請求項１】
装置の保守依頼を受け付けて該当保守会社に保守依頼する保守先選定方法において、
コンピュータが備える手段が、
装置の保守依頼を受け付けるステップと、
前記受け付けた保守について、当該保守の場所および保守可能な保守会社を、予め保守場所および保守可能な装置に関する情報を登録したテーブルから抽出するステップと、
前記抽出した保守会社に入札依頼を通知するステップと、
前記入札依頼を通知した保守会社からの入札を受け付けると共に時間を記憶するステップと、
前記複数の保守会社からの入札を予め設定した第１の所定時間内に受け付けたときに、当該複数の保守会社のうち、過去の履歴から算出した順位を登録したテーブルを参照し、順位の最も高い保守会社を選定するステップと、
前記第１の所定時間内に入札した保守会社がなく、当該第１の所定時間よりも長い第２の所定時間内に入札があったときは、最初に入札があった保守会社を選定するステップと、
前記選定した保守会社に、保守を通知するステップと
を実行することを特徴とする保守先選定方法。
【請求項２】
コンピュータが備える手段が、
前記第２の所定時間内に入札した保守会社がない場合、過去の履歴から算出した順位を登録したテーブルを参照し、順位の高い保守会社から順に、保守依頼を通知することを特徴とする請求項１記載の保守先選定方法。
【請求項３】
コンピュータが備える手段が、
前記テーブルに登録する順位として、入札応答時間が短い程、順位を高くすることを特徴とする請求項１あるいは請求項２記載の保守先選定方法。
【請求項４】
コンピュータが備える手段が、
前記テーブルに登録する順位として、入札回数が多い程、順位を高くすることを特徴とする請求項１から請求項３のいずれかに記載の保守先選定方法。
【請求項５】
コンピュータに、
装置の保守依頼を受け付けるステップと、
前記受け付けた保守について、当該保守の場所および保守可能な保守会社を、予め保守場所および保守可能な装置に関する情報を登録したテーブルから抽出するステップと、
前記抽出した保守会社に入札依頼を通知するステップと、
前記入札依頼を通知した保守会社からの入札を受け付けると共に時間を記憶するステップと、
前記複数の保守会社からの入札を予め設定した第１の所定時間内に受け付けたときに、当該複数の保守会社のうち、過去の履歴から算出した順位を登録したテーブルを参照し、順位の最も高い保守会社を選定するステップと、
前記第１の所定時間内に入札した保守会社がなく、当該第１の所定時間よりも長い第２の所定時間内に入札があったときは、最初に入札があった保守会社を選定するステップと、
前記選定した保守会社に、保守を通知するステップと
して機能させるための保守先選定プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、装置の保守依頼を受け付けて該当保守会社に保守依頼する保守先選定方法および保守先選定プログラムに関するものである。
【背景技術】
【０００２】
従来、取り纏め役の保守管理会社は、顧客会社に設置したたパソコンなどの装置に故障が発生して修理依頼を電話や電子メールなどで受け付けると、予め契約を結んだ関連保守会社の中から修理を行なうのに最適な保守会社を選定し、修理依頼を行なっていた。
【０００３】
また、網監視装置からの障害情報に基づき、重要度が高い障害情報である場合に、障害内容と発生場所などと各保守担当会社の所在地やサービス提供時間などを照合して障害復旧を行うのに最適な保守担当者を予め登録された複数の保守担当会社から選択する技術がある（特許文献１）。
【特許文献１】特開平０６−２３７２５０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述した前者の技術では、電話で修理を行なう最適な保守会社を選定し、電話で当該保守会社に修理を引き受けてくれるか確認し、引き受けられないときは、次に最適な保守会社を選定し、電話で確認するという手間が必要になってしまうと共に、関連保守会社はいつも受身の作業となり、修理の注文をとるためにサービスを向上させようとするインセンティブがわきにくいという問題があった。
【０００５】
また、上述した後者の技術でも、取り纏め役の保守会社が最適な修理担当の保守会社に電話で連絡を取って修理依頼するものであり、関連保守会社は受身であって、サービスを向上させようとするインセンティブがわきにくいという問題があった。
【課題を解決するための手段】
【０００６】
本発明は、これらの問題を解決するため、取り纏め役の保守会社が装置の修理等の依頼を受け付けたときに、修理等を担当するエリアおよび資格のある保守会社に保守入札依頼を通知し、入札があったときに入札時間の短い、評価の高い保守会社に修理等を依頼すると共に、その作業結果を蓄積するようにしている。
【発明の効果】
【０００７】
本発明は、取り纏め役の保守会社が装置の修理等の依頼を受け付けたときに、修理等を担当するエリアおよび資格のある保守会社に保守入札依頼を通知し、入札があったときに入札時間の短い、評価の高い保守会社に修理等を依頼すると共に、その作業結果を蓄積することにより、保守会社に入札で修理等の依頼を行なうことで保守会社のサービス向上を促すことが可能となる。
【発明を実施するための最良の形態】
【０００８】
本発明は、取り纏め役の保守会社が装置の修理等の依頼を受け付けたときに、修理等を担当するエリアおよび資格のある保守会社に保守入札依頼を通知し、入札があったときに入札時間の短い、評価の高い保守会社に修理等を依頼すると共に、その作業結果を蓄積し、保守会社に入札で修理等の依頼を行なうことで保守会社のサービス向上を促すことを実現した。
【実施例１】
【０００９】
図１は、本発明のシステム構成図を示す。
図１において、取り纏めサーバ１は、障害情報を受け付けて該当する保守会社に入札依頼して入札した保守会社に保守通知を行なうなどを実行するサーバであって、ここでは、受付手段２、障害切分手段３、入札通知手段４、入札決定手段５、および情報ＤＢ１１などから構成されるものである。
【００１０】
受付手段２は、顧客の会社のパソコンなどの装置の修理依頼を受け付けるものであって、例えば電話、ＦＡＸや電子メールなどで送られてきた障害情報（顧客の会社名、障害発生した装置名、障害内容など）を受け付けるものである。
【００１１】
障害切分手段３は、受付手段２で受け付けた障害情報をもとに、発生した障害を切り分けるものであって、例えば障害機種（例えばＧＰ６など）、障害内容（例えばディスク障害など）などに切り分けるものである。
【００１２】
入札通知手段４は、受け付けた障害情報をもとに障害切分手段３で切り分けた障害機種、障害内容、更に、障害発生場所などについて、対処可能な保守会社に入札依頼を通知するものである（図２から図６参照）。
【００１３】
入札決定手段５は、入札があったときに該当保守会社に入札を決定（落札）するものである（図２から図６参照）。
【００１４】
情報ＤＢ１１は、各種テーブルを外部記憶装置に格納したものであって、ここでは、保守会社情報テーブル１２、抽出条件テーブル１３、障害情報テーブル１４、保守依頼情報テーブル１５、入札回数情報テーブル１６、リピート障害割合情報テーブル１７、作業履歴情報テーブル１８、評価情報テーブル１９、評価条件テーブル２０、および評価順位テーブル２１などを格納したものである。
【００１５】
保守会社情報テーブル１２は、保守会社に関する情報（保守会社名、保守可能エリア、保有資格、通知先アドレスなど）を予め登録したものである（図４参照）。
【００１６】
抽出条件テーブル１３は、保守可能な保守会社に入札依頼を通知して入札があったときに、いずれの保守会社に入札決定するかを決定するための時間（第１の所定時間、第２の所定時間）を予め登録するものである（図４参照）。
【００１７】
障害情報テーブル１４は、受け付けた障害情報（顧客会社名、障害場所、障害機種、障害日時、障害内容など）を登録して管理するものである（図４参照）。
【００１８】
保守依頼情報テーブル１５は、保守依頼した情報（保守担当フラグ、保守会社名、入札受付開始時間など）を登録して保守担当状態を管理するものである（図４参照）。
【００１９】
入札回数情報テーブル１６は、保守会社が入札した回数などの情報（機種、累計入札回数など）を管理するものである（図４参照）。
【００２０】
リピート障害割合情報テーブル１７は、保守会社がリピート障害の保守を行なった情報（例えば、保守会社名、機種、リピート障害件数、合計障害対応件数など）を登録して管理するものである（図４参照）。
【００２１】
作業履歴情報テーブル１８は、保守会社の作業履歴に関する情報（例えば機種、障害受付番号、入札対応時間、レスポンスタイム、作業時間など）を登録して管理するものである（図４参照）。
【００２２】
評価情報テーブル１９は、保守会社が保守した作業に関する情報（例えば、平均入札対応時間、累計入札回数、平均レスポンスタイム、平均作業時間、リピート障害率など）を登録して管理するものである（図４参照）。
【００２３】
評価条件テーブル２０は、評価情報テーブル１９に登録して管理している情報をもとに評価点を算出する情報（例えば係数）を登録して管理するものである（図４参照）。
【００２４】
評価順位テーブル２１は、保守会社の評価の順位に関する情報（順位、順位を算出するための情報（平均入札対応時間、評価後入札回数など））を登録して管理するものである（図４参照）。
【００２５】
保守会社端末３１は、ネットワーク３５に接続された保守会社の端末であって、保守依頼を受け付けたり、入札したり、作業結果情報を入力したりなどするためのものであり
（図２から図６参照）、入札受信手段３２、入札手段３３、落札受信手段３４などから構成されるものである。
【００２６】
入札受信手段３２は、取り纏めサーバ１から通知された入札依頼を受信するものである（図２から図６参照）。
【００２７】
入札手段３３は、入札受信手段３２で受信した入札依頼について、入札情報を取り纏めサーバ１に送信するものである（図２から図６参照）。
【００２８】
落札受信手段３４は、入札手段３３で入札したことに対応して、落札を受信するものである（図２から図６参照）。
【００２９】
ネットワーク３５は、複数の保守会社端末３１と取り纏めサーバ１とを相互に通信するためのネットワークであって、インターネットなどである。
【００３０】
次に、図２のフローチャートの順番に従い、図１の構成の動作を順次詳細に説明する。
図２は、本発明の動作説明フローチャートを示す。
【００３１】
図２の（ａ）は、取り纏めサーバ１における動作を示す。
図２の（ａ）において、Ｓ１は、障害受付情報が入力されたか判別する。これは、図１の取り纏めサーバ１を構成する受付手段２が電話、ＦＡＸあるいは電子メールで、顧客から装置の障害情報を受け付けたか判別する。ＹＥＳの場合には、Ｓ２に進む。ＮＯの場合には、待機する。
【００３２】
Ｓ２は、Ｓ１のＹＥＳで障害情報が受け付けられたと判明したので、同一場所、同一会社、同一機種、同一障害内容のリピート障害が過去にあるか判別する。例えば図４の（ｃ）の障害情報テーブル１４中の（１）のエントリの今回受け付けた障害情報
・顧客会社名：ＦＦＦ
・障害場所  ：新宿区新宿１−２−３
・障害機種  ：ＧＰ６
（・障害日時  ：２００６０３１３）
・障害内容  ：ディスク故障
と同じ過去の障害情報として、図４の（ｃ）の障害情報テーブル１４中の（２）のエントリの
・顧客会社名：ＦＦＦ
・障害場所  ：新宿区新宿１−２−３
・障害機種  ：ＧＰ６
（・障害日時  ：２００６０１１３）
・障害内容  ：ディスク故障
がある場合には、リピート障害が過去にあったと判明したので、Ｓ２のＹＥＳとなり、Ｓ３に進む。一方、リピート障害が過去になかった場合には、新規の障害として、Ｓ２のＮＯとなり、Ｓ５に進む。
【００３３】
Ｓ３は、Ｓ２のＹＥＳでリピート障害と判明したので、以前保守担当した会社に保守依頼通知し、保守依頼情報に登録（例えば図４の（ｄ）の保守依頼情報テーブル１５の（３）に当該障害情報を登録）し、保守会社のリピート障害件数に「１」を加算（例えば図４の（ｆ）のリピート障害割合情報テーブル１７中の（４）のエントリのリピート障害件数を「１」加算）し、当該保守会社のリピート障害件数を累積して記録する。
【００３４】
Ｓ４は、保守担当フラグを「１」にする。これは、Ｓ３で登録した図４の（ｄ）の（３）のエントリの保守担当フラグを「１」に設定して保守担当する旨を明示（記憶）する。
【００３５】
以上のＳ１、Ｓ２のＹＥＳ，Ｓ３、Ｓ４によって、障害が受け付けられたときに、リピート障害と判明した場合には、以前に保守した保守会社に保守依頼（図４の（ｄ）の保守依頼情報テーブル１５の（３）のエントリに情報（障害受付番号、保守担当フラグ「１」、保守会社名）を登録して保守依頼）と決定して保守依頼通知することが可能となる。そして、リピート障害の保守依頼通知を受信した保守会社は、図２の（ｂ）のＳ１１でＹＥＳとなり、Ｓ１６で保守作業を行い、Ｓ１７でレスポンスタイム、作業時間を入力して取り纏めサーバ１に送信し、取り纏めサーバ１では図３のフローチャートで履歴、順位更新を行なうことが可能となる。
【００３６】
Ｓ５は、Ｓ２のＮＯでリピート障害でなく新規の障害と判明したので、障害場所を含む保守エリアを有し、さらに障害機種を保守するのに必要な資格をもつ保守員を有する保守会社を抽出し、保守依頼情報に登録する。例えば、図４の図４の（ｃ）の障害情報テーブル１４中の（５）のエントリの新規の障害が受け付けられた場合、当該新規障害
・場所    ：港区六本木１−２−３
・障害機種：ＧＰ６
を満たす保守会社として、図４の（ａ）の保守会社情報テーブル１２を参照し、（６）で示す保守会社
・あああ
・いいい
・ううう
の３社を抽出し、これら３社を図４の（ｄ）の保守依頼情報テーブル１５中の（７）で示すエントリに登録する。
【００３７】
Ｓ６は、抽出された保守会社に対して障害受付情報を開示して入札依頼通知し、入札開始時間を登録する。これは、Ｓ５で抽出した、ここでは、３社に電子メールで受け付けた障害情報を開示して入札依頼通知すると共に、図４の（ｄ）の保守依頼情報テーブル１５の（７）で示す３つのエントリ中の入札受付開始時刻を登録（ここでは、１１：３０に登録）する。そして、入札依頼通知を３社の端末にそれぞれ送信し、後述する図２の（ｃ）の保守会社端末側でＳ２１からＳ２９の処理で入札などを行なう。
【００３８】
以上のＳ１、Ｓ２のＮＯ，Ｓ５、Ｓ６によって、受け付けた障害がリピート障害でなく新規の障害と判明した場合には、受け付けた障害情報（例えば図４の（ｃ）の（５））の場所、障害機種を満たす保守会社を抽出して登録（例えば図４の（ｄ）の保守依頼情報テーブル１５の（７）で示す３つのエントリのように登録）し、これら保守会社に入札依頼を通知することが可能となる。これら入札依頼通知を受けた各保守会社は、入札を電子メールなどで取り纏めサーバ１に通知し、取り纏めサーバ１では、図２の（ｃ）のＳ２１からＳ２９の処理で落札社を決めて電子メールで通知し、通知を受けた保守会社は図２の（ｂ）でＳ１５のＹＥＳとなり、Ｓ１６で保守作業を行い、Ｓ１７でレスポンスタイム、作業時間を入力して取り纏めサーバ１に送信し、取り纏めサーバ１では図３のフローチャートで履歴、順位更新を行なうことが可能となる。以下順次詳細に説明する。
【００３９】
図２の（ｂ）は、保守会社端末３１の動作を示す。
図２の（ｂ）において、Ｓ１１は、リピート障害対応依頼を受信したか判別する。ＹＥＳの場合には、Ｓ１６で保守作業を開始し、Ｓ１７で作業が完了すると、レスポンスタイムおよび作業時間を入力し、取り纏めサーバ１に向けて送信する。一方，Ｓ１１のＮＯの場合には、リピート障害対応依頼でないと判明したので、Ｓ１２に進む。
【００４０】
Ｓ１２は、入札依頼を受信したか判別する。これは、受信したものが入札依頼か判別する。ＹＥＳの場合には、Ｓ１３に進む。ＮＯの場合には、終了する。
【００４１】
Ｓ１３は、入札希望依頼登録したか判別する。これは、入札希望依頼を取り纏めサーバ１に登録したか判別する。ＹＥＳの場合には、Ｓ１４に進む。ＮＯの場合には、終了する。
【００４２】
Ｓ１４は、落札成功ＯＲ落札失敗通知を受信したか判別する。落札成功を受信した場合には、Ｓ１６で落札した障害情報の保守作業を開始し、Ｓ１７で作業が完了すると、レスポンスタイム、作業時間を入力し電子メールで取り纏めサーバ１に送信し、取り纏めサーバ１は、図３のフローチャートに従い、順位などを更新する。一方、Ｓ１４で落札失敗を受信した場合には、終了する。
【００４３】
図２の（ｃ）は、取り纏めサーバ１における処理を示す。
図２の（ｃ）において、Ｓ２１は、入札希望依頼を受信すると入札対応時間を登録し、累計入札回数に「１」を加算する。これは、取り纏めサーバ１がＳ６で入札依頼通知を行った保守会社から、入札希望依頼を受信した場合、入札対応時間を図４の（ｄ）の保守依頼情報テーブル１５の該当保守会社の入札対応時間（入札受付開始時刻から入札希望依頼を受信したときまでの時間）を登録すると共に、図４の（ｅ）の入札回数情報テーブル１６の該当保守会社の累計入札回数に「１」を加算する。
【００４４】
Ｓ２２は、一定時間（２）内に入札があったか判別する。これは、一定時間（２）（図４の（ｂ）の抽出条件テーブル１３の一定時間（２）＝３分）内に入札があったか判別する。ＹＥＳの場合には、Ｓ２３で一定時間（２）（ここでは、３分）内に複数社から入札がある場合には、最も評価の高い会社に保守担当フラグ「１」を登録（図４の（ｄ）の保守依頼情報テーブル１５中の該当保守会社の保守担当フラグ欄に「１」を登録）し、落札決定通知を送信し、Ｓ２４で落札した会社以外の入札会社に対して入札否決通知送信し、保守担当フラグを「０」を登録し、終了する。一方、Ｓ２２のＮＯの場合には、Ｓ２５に進む。
【００４５】
Ｓ２５は、Ｓ２２のＮＯで一定時間（２）（例えば３分）経過しても１つも入札がないと判明したので、一定時間（１）（図４の（ｂ）の抽出条件テーブル１３中の一定時間（１）＝１０分）内に入札があったか判別する。ＹＥＳの場合には、一定時間（１）（１０分）以内に入札があったと判明したので、Ｓ２６で最も入札時刻が早い会社に落札決定通知を送信し、終了する。一方、Ｓ２５のＮＯの場合には、一定時間（１）（１０分）を経過しても入札がなかったと判明したので、Ｓ２７で最も評価の高い保守会社（例えば図４の（ｊ）の評価順位テーブル２１中の順位欄の最も評価の高い会社（順位１の保守会社））に依頼通知し、Ｓ２８で承諾通知受信か判別し、ＹＥＳのときにＳ２９で保守担当フラグを「１」に登録して終了し、ＮＯのときにＳ３０で次に評価の高い保守会社に依頼通知し、Ｓ２８を繰り返す。
【００４６】
以上によって、取り纏めサーバ１では、入札依頼を保守会社に通知して当該保守会社からの入札希望の受信を待機し、一定時間（２）（ここでは、３分）以内に入札があった場合には、評価の最も高い保守会社に落札通知し、当該一定時間（２）内に入札がなく更に一定時間（１）（ここでは、１０分）以内に入札があったときは最も早い入札した保守会社に落札通知し、更に、一定時間（１）を経過しても入札がない場合には、順位の高い順に保守依頼を順次通知して承諾した保守会社に保守依頼通知することが可能となる。
【００４７】
図３は、本発明の動作説明フローチャート（順位更新等）を示す。
図３において、Ｓ３１は、保守会社よりレスポンスタイムおよび作業時間の入力ありか判別する。これは、既述した図２の（ｂ）のＳ１７でレスポンスタイムおよび作業時間の入力を行い、電子メールで送信（あるいはホームページから入力して送信）されたか判別する。ＹＥＳの場合には、Ｓ３２に進む。ＮＯの場合には、待機する。
【００４８】
Ｓ３２は、保守した機種についての合計障害対応件数に「１」を加算する（図４の（ｆ）のリピート障害割合情報テーブル１７中の合計障害対応件数欄に「１」を加算する）。
【００４９】
Ｓ３３は、機種毎の入札対応時間その他の評価項目に重み付けをして総合評価点数を算出して登録する。これは、図４の（ｈ）の評価情報テーブル１９に示す、機種、会社毎の平均入札対応時間、累計入札回数、平均レスポンスタイム、平均作業時間、リピート障害率の各項目値に、図４の（ｉ）の評価条件テーブル２０の重み付けの値をそれぞれ乗算して図４の（ｊ）の評価順位テーブル２１の平均入札対応時間、累計入札回数、平均レスポンスタイム、平均作業時間、リピート障害率の各欄にそれぞれ設定した後、これらの総計を求めて総合評価点数欄に登録する。
【００５０】
Ｓ３４は、機種毎に順位を算出して更新する。これは、Ｓ３３で算出した機種毎の総合評価点数欄の値の小さい順に順位１，２，３・・・を更新する。
【００５１】
以上によって、保守作業を落札して作業を終了した保守会社から通知されたレスポンスタイム、作業時間などの情報を登録すると共に、総合評価点数を再計算して順位を更新することが可能となる。これにより、平均入札対応時間、平均レスポンスタイム、平均作業時間、リピート障害率、累計入札回数が小さくなる程、総合評価点数が小さくなって順位を良くすることが可能となって、より多くの障害情報の入札を落札することが可能となる。
【００５２】
図４は、本発明のテーブル例を示す。
図４の（ａ）は、保守会社情報テーブル例を示す。保守会社情報テーブル１２は、保守会社の情報を登録して管理するものであって、図示の下記の情報を対応づけて登録して管理するものである。
【００５３】
・保守会社名：
・保守可能エリア：
・保守資格：
・通知先アドレス
ここで、保守会社名は保守会社を一意に判別する名前である。保守可能エリアは、障害発生装置を保守するエリア（場所）である。保守資格は、保守可能な資格（例えば機種ＧＰ５の保守可能な資格）である。通知先アドレスは、入札依頼などを通知するアドレスである。
【００５４】
図４の（ｂ）は、抽出条件テーブル例を示す。抽出条件テーブル１３は、既述した図２の（ｃ）で落札を決定するときに使用する時間を登録して管理するものであって、ここでは、図示の下記の時間を登録して管理するものである。
【００５５】
・一定時間（１）：１０分
・一定時間（２）：３分
図４の（ｃ）は、障害情報テーブル例を示す。障害情報テーブル１４は、受け付けた障害情報を登録して管理するものであって、図示の下記の情報を対応づけて登録して管理するものである。
【００５６】
・障害受付番号：
・顧客会社名：
・障害場所：
・障害機種：
・障害日時：
・障害内容：
ここで、障害受付番号は受け付けた障害情報に付与した一意の番号である。顧客会社名は受け付けた障害の発生した会社名である。障害場所、障害機種、障害日時、障害内容は、発生した障害の場所、装置の機種、障害発生日時、障害の内容（例えばディスク故障）である。
【００５７】
図４の（ｄ）は、保守依頼情報テーブル例を示す。保守依頼情報テーブル１５は、保守依頼する保守会社などの情報を登録して管理するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。
【００５８】
・障害受付番号：
・保守担当フラグ：
・保守会社名：
・入札受付開始時刻：
・入札対応時間：
ここで、障害受付番号は、障害受付時に付与した当該障害の番号である。保守担当フラグは、落札して保守担当と決まったときに１、保守担当でないときに０と設定して管理するものである。保守会社名、入札受付開始時刻、入札対応時間は、入札依頼通知した保守会社名、入札受付を開始した時刻、入札希望を通知した時間（例えば入札開始時刻から入札希望を取り纏めサーバ１に送信して到着するまでの時間）である。
【００５９】
図４の（ｅ）は、入札回数情報テーブル例を示す。入札回数情報テーブル１６は、保守会社毎に入札回数などを登録して管理するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。
【００６０】
・会社名：
・機種：
・累計入札回数：
ここで、会社名は保守を行なった保守会社名である。機種は、保守を行なった装置の機種である。累計入札回数は、取り纏めサーバ１からの入札依頼通知に対応して、入札希望を取り纏めサーバ１に送信して入札した累計回数である。
【００６１】
図４の（ｆ）は、リピート障害割合情報テーブル例を示す。リピート障害割合情報テーブル１７は、リピート障害件数などを登録して管理するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。
【００６２】
・会社名：
・機種：
・リピート障害件数：
・合計障害対応件数：
ここで、会社名は保守会社名である。機種は、障害の保守を行った装置の機種である。リピート障害件数は、同一機種の同一障害内容の障害（リピート障害）を保守した累計回数である。合計障害対応件数は、リピート障害、新規の障害を合わせた合計障害対応件数である。
【００６３】
図４の（ｇ）は、作業履歴情報テーブル例を示す。作業履歴情報テーブル１８は、保守会社毎に、機種毎の作業履歴を登録して管理するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。
【００６４】
・会社名：
・機種：
・障害受付番号：
・入札対応時間：
・レスポンスタイム：
・作業時間：
ここで、会社名は保守を行なった保守会社名である。機種、障害受付番号は、保守した装置の機種、受け付けた障害に付与した受付番号である。入札対応時間、レスポンスタイム、作業時間は、入札開始から入札までの時間、応答時間、作業に要した時間である。
【００６５】
図４の（ｈ）は、評価情報テーブル例を示す。評価情報テーブル１９は、評価点を算出するための情報を登録して管理するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。
【００６６】
・機種：
・会社名：
・平均入札対応時間（分）：
・累計入札回数（１／回）：
・平均レスポンスタイム（分）：
・平均作業時間（分）：
・リピート障害率（％）：
ここで、機種は障害発生した装置の機種である。会社名は保守した保守会社名である。平均入札対応時間（分）は、入札対応時間の平均である。累計入札回数（１／回）は、累計の入札回数の逆数である。平均レスポンスタイムは、応答した時間の平均である。平均作業時間は。保守した作業時間の平均である。リピート障害率は、全障害に対するリピート障害の割合（％）である。
【００６７】
図４の（ｉ）は、評価条件テーブル例を示す。評価条件テーブル２０は、図４の（ｈ）の評価情報テーブル１９に登録した平均入札対応時間などに乗算して評価点を算出するための重みを登録して管理するものであって、ここでは、図示の下記の重みを対応づけて登録して管理するものである。
【００６８】
・評価要素：重みづけ
・入札対応時間：
・累計入札回数：
・レスポンスタイム：
・作業時間：
・リピート障害率：
図４の（ｊ）は、評価順位テーブル例を示す。評価順位テーブル２１は、図４の（ｈ）の評価情報テーブル１９の各欄の値に、図４の（ｉ）の評価条件テーブル２０の各欄の重みの値をそれぞれ乗算して算出した各評価点を設定するものであって、ここでは、図示の下記の情報を対応づけて登録して管理するものである。
【００６９】
・機種：
・会社名：
・平均入札対応時間：
・累計入札回数：
・平均レスポンスタイム：
・作業時間評価点：
・リピート障害率：
・総合評価点数：
・順位：
ここで、機種、会社名、平均入札対応時間、累計入札回数、平均レスポンスタイム、作業時間評価点、リピート障害率は、図４の（ｈ）の評価情報テーブル１９の各欄の値に、図４の（ｉ）の評価条件テーブル２０の各欄の重みの値をそれぞれ乗算した評価点をそれぞれ設定するものである。総合評価点数は、各欄の評価点の総合点である。順位は、総合評価点数の小さい順に、順位１，２，３．４・・・付与したものである。
【００７０】
図５および図６は、本発明の画面／メッセージ例を示す。
図５の（ａ）は、保守会社端末（リピート障害でない場合）の画面例を示す。これは、図１の保守会社端末３１の表示装置上に表示した画面例であって、ここでは、図示の下記の情報を表示する。
【００７１】
・メッセージ：
「スポット保守入札依頼を受信しました。」
・障害情報：
「顧客会社名、障害場所、障害機種、障害日時、障害内容」
・「入札受付開始時刻」
・入札アイコン：
「入札をしますか？」
・作業員スケジュール表
ここで、メッセージは、受信した電子メールの内容で、ここでは、保守入札依頼の例を表す。障害情報は、保守入札の障害情報である。入札受付開始時刻は、入札の受付を開始した時刻である。
【００７２】
以上の情報を参照し、入札希望を取り纏めサーバ１に送信して入札するには、下段の入札ボタンを押下することで自動的に入札する。
【００７３】
図５の（ｂ）は、保守会社端末の画面例を示す。これは、図１の保守会社端末３１の表示装置上に表示した作業結果報告を送信するときの画面例であって、ここでは、図示の下記の情報を表示する。
【００７４】
・作業結果報告：
「障害受付番号・・の作業時間とレスポンスタイムを入力して下さい。」
図５の（ｃ）は、取り纏めサーバの画面例を示す。これは、図１の取り纏めサーバ１の表示装置上に表示された画面例であって、ここでは、図示の下記の情報を表示する。
【００７５】
・メッセージ：
「障害情報が登録されました。
【００７６】
下記の３社に入札依頼を行いました。」
・障害情報：
「顧客会社名、障害場所、障害機種、障害日時、障害内容」
・入札情報開示先会社：
「あああ社
いいい社
ううう社」
・落札結果：
「いいい社」
ここで、メッセージは、障害情報の登録、入札依頼を行なったの内容を表示する。障害情報は、保守入札の障害情報である。入札情報開示先会社は、入札情報（障害情報）を通知した保守会社名を表示する。落札結果は、落札した保守会社名を表示する。
【００７７】
図６の（ｄ）は、保守依頼通知メール（リピート障害）例を示す。ここでは、リピート障害を受け付けたので、図示の下記の情報を送信する例を示す。
【００７８】
・えええ社殿：
「障害受付番号５５５５の保守作業をお願い致します。
【００７９】
障害受付番号２２２２のリピート障害です。」
ここで、えええ社は、リピート障害を発生させた保守会社名である。メッセージの上段は障害の障害受付番号と保守作業の依頼のメッセージであり、下段は過去の障害のメッセージである。
【００８０】
図６の（ｅ）は、落札通知メールの例を示す。これは、取り纏めサーバ１が落札した保守会社「いいい社」に落札した旨および落札した保守作業を依頼する電子メールのメッセージ例を示す。
【００８１】
図６の（ｆ）は、入札応答メールンの例を示す。これは、取り纏めサーバ１が入札したが落札した保守会社に送信する電子メールのメッセージ例を示す。
【産業上の利用可能性】
【００８２】
本発明は、取り纏め役の保守会社が装置の修理等の依頼を受け付けたときに、修理等を担当するエリアおよび資格のある保守会社に保守入札依頼を通知し、入札があったときに入札時間の短い、評価の高い保守会社に修理等を依頼すると共に、その作業結果を蓄積し、保守会社に入札で修理等の依頼を行なうことで保守会社のサービス向上を促す
保守先選定方法および保守先選定プログラムに関するものである。
【図面の簡単な説明】
【００８３】
【図１】本発明のシステム構成図である。
【図２】本発明の動作説明フローチャートである。
【図３】本発明の動作説明フローチャート（順位更新等）である。
【図４】本発明のテーブル例である。
【図５】本発明の画面／メッセージ例（その１）である。
【図６】本発明の画面／メッセージ例（その２）である。
【符号の説明】
【００８４】
１：取り纏めサーバ
２：受付手段
３：障害切分手段
４：入札通知手段
５：入札決定手段
１１：情報ＤＢ
１２：保守会社情報テーブル
１３：抽出条件テーブル
１４：障害情報テーブル
１５：保守依頼情報テーブル
１６：入札回数情報テーブル
１７：リピート障害割合情報テーブル
１８：作業履歴情報テーブル
１９：評価情報テーブル
２０：評価条件テーブル
２１：評価順位テーブル
３１：保守会社端末
３２：入札受信手段
３３：入札手段
３４：落札受信手段
３５：ネットワーク
【図１】
0004795093.tif 000002
【図２】
0004795093.tif 000003
【図３】
0004795093.tif 000004
【図４】
0004795093.tif 000005
【図５】
0004795093.tif 000006
【図６】
0004795093.tif 000007