保守部品手配方法及びシステム
【課題】本発明は保守部品手配方法及びシステムに関し、保守部品の供給を速やかに行なうことを目的としている。
【解決手段】前記障害受付サーバが前記顧客システムから障害通知を受け付けると、障害重要度を含む障害受付情報を登録する工程と、障害の現象から交換部品を予測する工程と、前記障害重要度が低い場合には通常の部品手配を行なう工程と、前記障害重要度が高い場合において、前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がある場合には部品手配依頼を行なう工程と、前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がない場合には、前記部品と同一部品について払い出し中の部品があるか否かを検索する工程と、他の保守員が保管している同一部品であり、かつ前記部品が重要でない部品について検索して、前記保守員に前記部品を転送してもらう工程とを有して構成される。
【解決手段】前記障害受付サーバが前記顧客システムから障害通知を受け付けると、障害重要度を含む障害受付情報を登録する工程と、障害の現象から交換部品を予測する工程と、前記障害重要度が低い場合には通常の部品手配を行なう工程と、前記障害重要度が高い場合において、前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がある場合には部品手配依頼を行なう工程と、前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がない場合には、前記部品と同一部品について払い出し中の部品があるか否かを検索する工程と、他の保守員が保管している同一部品であり、かつ前記部品が重要でない部品について検索して、前記保守員に前記部品を転送してもらう工程とを有して構成される。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は保守部品手配方法及びシステムに関し、更に詳しくは保守契約を行なっている顧客のシステムから重要障害通報を受け付け、重要な交換部品が部品倉庫に在庫していない場合に、他案件のために既に払い出して他の保守員が保管している部品や他案件を解決するために既に払い出された配送中の部品の中から当案件に転送できそうな部品を割り出して転送依頼を行なう保守部品手配方法及びシステムに関する。
【背景技術】
【0002】
障害が発生すると、障害原因を予測して被疑部品を特定し、被疑部品の在庫があり障害現場に近い部品倉庫に発送依頼を行なうシステムが既に考案されている。しかしながら、部品倉庫に在庫がない場合は新たに部品を発注するか、遠距離にある部品倉庫からの発送を余儀なくされており、障害復旧に時間を要する場合があった。
【0003】
一方、ある障害案件を解決するためにすでに部品倉庫から払い出されたが、障害原因が予測と異なっているために前記部品が使われずに保守員の手元に存在する場合がある。この場合は、後日部品倉庫に返送されることになるが、長期間に亘って保守員の手元に放置されたままの場合があった。このような場合、部品倉庫には部品在庫がないが、保守員の手元にある使用されない部品をすぐに転用できれば便利である。
【0004】
また、障害が発生すると障害原因を予測して被疑部品を特定するが、被疑部品は1種類だけを持って行くのではなく、通常は被疑部品の使用予測精度70%の部品、被疑部品使用予測精度30%の部品というように複数の部品を持って行く場合が多い。例えば、電源が入らないという現象に対しては電源装置を交換すれば復旧する可能性が一番高いが、ファンや電源ケーブルに原因がある場合もある。そのために、電源装置だけではなく、ファンや電源ケーブルなど考えられる全ての交換部品を現場に持っていくことが望ましい。
【0005】
例えばA案件について使用予測精度の低い部品について、他の障害事件(B案件)で被疑部品使用予測精度が前記事件(A案件)よりも高い場合には、使用予測精度が高い事件(B案件)の方に部品を転用した方が便利である。そのため、被疑部品が運送会社のトラックによって配送中であったとしても届け出先を変更した方がよい場合がある。
【0006】
従来のこの種のシステムとしては、ユーザコンピュータ10で障害が発生した際に、ユーザコンピュータ10から通信ネットワーク100を介して障害解析システム20に障害情報が通知され、通知された情報を基に障害解析が行われるものであり、解析の結果、必要となる被疑部品情報を部品管理システム30に通知し、被疑部品を手配し、ユーザ先への発送を行なうようにしたシステムが知られている(例えば特許文献1参照)。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特開2001−306360号公報(段落0011〜0017、図1)
【発明の概要】
【発明が解決しようとする課題】
【0008】
本発明はこのような課題に鑑みてなされたものであって、障害復旧に必要な部品が部品倉庫にないが、前記部品が他の保守員の手元にある場合や、他の障害案件解決のために既に払い出されて配送中の場合であって、今回の障害案件に、優先して前記部品を適用すべきと考えられる場合に、前記部品を今回の障害復旧のために再度払い出せるような仕組みを実現することができる保守部品手配方法及びシステムを提供することを目的としている。
【課題を解決するための手段】
【0009】
前記した課題を解決するため、本発明は以下のような構成をとる。
【0010】
(1)請求項1記載の発明は、障害受付サーバと、該障害受付サーバと接続された各種テーブルを記憶するデータベースと、部品供給会社サーバと、該部品供給会社サーバと接続された部品を記憶する部品倉庫管理テーブルと、配送会社サーバと、顧客システムと、保守員携帯端末と、配送車端末とがそれぞれネットワークを介して接続されたシステムにおいて、前記障害受付サーバが前記顧客システムから障害通知を受け付けると、障害重要度を含む障害受付情報を登録する工程と、障害の現象から交換部品を予測する工程と、前記障害重要度が低い場合には通常の部品手配を行なう工程と、前記障害重要度が高い場合において、前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がある場合には部品手配依頼を行なう工程と、前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がない場合には、前記部品と同一部品について払い出し中の部品があるか否かを検索する工程と、他の保守員が保管している部品と同一部品であり、かつ前記部品が重要でない部品について検索して、前記保守員に前記部品を転送してもらう工程と、を有することを特徴とする。
【0011】
(2)請求項2記載の発明は、前記部品倉庫管理テーブルの内容を参照して前記部品倉庫に部品がない場合には、前記部品と同一部品について払い出し中の部品があるか否か検索する工程と、他の保守員が保管している部品と同一部品であり、かつ前記部品が重要でない部品について検索して、前記保守員に前記部品を転送してもらう場合の第1の到着時間を計算する工程と、他作業のために配送中の部品があるか否かを検索して、前記部品がありかつ予測精度が低く重要でない部品の場合には配送先を変更した場合の第2の到着時間を計算する工程と、前記第1の到着時間と第2の到着時間を比較して障害発生地点に早く到着する方法を選択して部品手配依頼を行なう工程と、を含むことを特徴とする。
【0012】
(3)請求項3記載の発明は、障害受付サーバと、該障害受付サーバと接続された各種テーブルを記憶するデータベースと、部品供給会社サーバと、該部品供給会社サーバと接続された部品を記憶する部品倉庫管理テーブルと、配送会社サーバと、顧客システムと、保守員携帯端末と、配送車端末とがネットワークを介して接続されたシステムにおいて、前記障害受付サーバが前記顧客システムから障害通知を受け付けると、障害重要度を含む障害受付情報を登録する手段と、障害の現象から交換部品を予測する手段と、前記障害重要度が低い場合には通常の部品手配を行なう手段と、前記障害重要度が高い場合において、前記部品倉庫管理テーブルの内容を参照して在庫部品がある場合には部品手配依頼を行なう手段と、前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がない場合には、前記部品と同一部品について払い出し中の部品があるか否かを検索する手段と、他の保守員が保管している部品と同一部品であり、かつ前記部品が重要でない部品について検索して、前記保守員に前記部品を転送してもらう手段と、を有することを特徴とする。
【発明の効果】
【0013】
本発明によれば、以下のような効果を奏する。
【0014】
(1)請求項1記載の発明によれば、障害復旧に必要な部品が部品倉庫にないが、前記部品が他の保守員の手元にある場合や、他の障害案件解決のために既に払い出されて配送中の場合であって、今回の障害案件に、優先して前記部品を適用すべきと考えられる場合に、前記部品を今回の障害復旧のために再度払い出せるような仕組みを実現することができる。
【0015】
(2)請求項2記載の発明によれば、倉庫に保守部品がない場合において、他の保守員が当該部品を所持している場合において、当該保守員から当該部品を転送してもらう場合の到着時間と、配送中の部品の中に当該部品がある場合において、配送先を変更した場合の到着時間とを比較して、障害発生地点に早く到達する方法を選択することで、保守部品の供給を速やかに行なうことができる。
【0016】
(3)請求項3記載の発明によれば、障害復旧に必要な部品が部品倉庫にないが、前記部品が他の保守員の手元にある場合や、他の障害案件解決のために既に払い出されて配送中の場合であって、今回の障害案件に、優先して前記部品を適用すべきと考えられる場合に、前記部品を今回の障害復旧のために再度払い出せるような仕組みを実現することができる。
【図面の簡単な説明】
【0017】
【図1】本発明の一実施例を示すブロック図である。
【図2】顧客テーブルの構成例を示す図である。
【図3】重要障害判断テーブルの構成例を示す図である。
【図4】保守員テーブルの構成例を示す図である。
【図5】部品倉庫住所テーブルの構成例を示す図である。
【図6】部品倉庫管理テーブルの構成例を示す図である。
【図7】払い出し部品管理テーブルの構成例を示す図である。
【図8】障害受付テーブルの構成例を示す図である。
【図9】障害対応部品テーブルの構成例を示す図である。
【図10】振替時間比較テーブルの構成例を示す図である。
【図11】部品割当管理テーブルの構成例を示す図である。
【図12】輸送車両管理テーブルの構成例を示す図である。
【図13】障害受付サーバの動作を示すフローチャートである。
【図14】障害受付サーバの動作を示すフローチャートである。
【図15】障害受付サーバの動作を示すフローチャートである。
【図16】配送会社サーバの動作を示すフローチャートである。
【発明を実施するための形態】
【0018】
以下、図面を参照して本発明の実施例を詳細に説明する。図1は本発明の一実施例を示すブロック図である。 図において、1は顧客システム、2は該顧客システム1からの障害情報を受け取って障害受付制御を行なう障害受付サーバである。該障害受付サーバ2は、障害受付手段21、部品検索手段22、部品到着時間比較手段23、部品手配手段24、部品振替依頼手段25及び配送先変更依頼手段26とから構成されている。
【0019】
3は障害受付サーバ2と接続され、各種のテーブルを記憶するデータベース(DB)である。該データベース3は、顧客テーブル31、重要障害判断テーブル32、保守員テーブル33、部品倉庫住所テーブル34、払い出し部品管理テーブル35、障害受付テーブル36、障害対応部品テーブル37、振替時間比較テーブル38、部品割当管理テーブル39及び輸送車両管理テーブル40とから構成されている。
【0020】
4は部品供給処理を行なう部品供給会社サーバ、5は該部品供給会社サーバ4と接続された倉庫内の部品の管理情報を記憶している部品倉庫管理テーブルである。6は保守員携帯端末、7は配送会社サーバ、8は輸送車端末である。10はこれら各構成要素間を接続するためのネットワークである。該ネットワーク10としては、例えばインターネット、ISDNネットワーク、LAN等が用いられる。配送会社サーバ7には、輸送状況管理手段71が含まれ、輸送車端末8にはGPS装置81が含まれる。障害受付サーバ2、部品供給会社サーバ4及び配送会社サーバ7としては、例えばパーソナルコンピュータが用いられる。
【0021】
次に、データベース3に記憶されている各種テーブルの構成について説明する。図2は顧客テーブル31の構成例を示す図である。図に示すように顧客名と、顧客ランクと、システム規模と、顧客住所と、顧客Eメールアドレスとから構成されている。ここで、顧客ランクとは、例えば取引量の多さにより区別される。例えば、「通常顧客」と「ロイヤル顧客」とに区別される。ロイヤル顧客は取引量の多い顧客である。
【0022】
図3は重要障害判断テーブル32の構成例を示す図である。図に示すように、顧客ランクとシステム規模と障害重要度とから構成されている。ここで、システム規模とは、システムの規模のことであり、通常の規模である「通常システム」と大きな規模である「社会システム」とに区別される。図4は保守員テーブル33の構成例を示す図である。図に示すように、保守員名と、Eメールアドレスと、所課住所とから構成されている。
【0023】
図5は部品倉庫住所テーブル34の構成例を示す図である。図に示すように、倉庫名と管轄エリアと住所とから構成されている。図6は部品倉庫管理テーブル5の構成例を示す図である。図に示すように、部品名と、部品型名と、対象装置型名と、部品がストックされている倉庫名と、部品の製造NOと、在庫有無と、払い出し期日と、払い出し先とから構成されている。
【0024】
図7は払い出し部品管理テーブル35の構成例を示す図である。図に示すように、部品名と、部品型名と、対象装置型名と、製造NOと、障害受付番号と、予測精度と、担当保守員と、ステータスと、現在地点とから構成されている。ここで、予測精度とは、当該部品が交換部品である可能性のことである。ステータスとは、その部品が今どのような状況におかれているかを示している。
【0025】
図8は障害受付テーブル36の構成例を示す図である。図に示すように、障害受付番号と、受付日と、受付時刻と、顧客名と、装置型名と、障害の現象と、障害重要度から構成されている。図9は障害対応部品テーブル37の構成例を示す図である。図に示すように、現象と、交換部品と、予測精度とから構成されている。例えば、現象が「異常音がする」場合、交換部品としては「ファン」と「メインボード」が考えられ、これら「ファン」と「メインボード」の該当する確率(予測精度)は、「ファン」の場合が高く、「メインボード」の場合は低いことになる。
【0026】
図10は振替時間比較テーブル38の構成例を示す図である。図に示すように、障害受付番号と、部品型名と、製造NOと、保守員所持振替時間と、輸送中部品振替時間とから構成されている。ここで、保守員所持振替時間は、保守員がその部品を持っていた場合に、当該障害箇所に振り替えるまでにかかる時間で、輸送中部品振替時間は、当該部品を輸送中に当該箇所に振り替えるまでにかかる時間を示す。
【0027】
図11は部品割当管理テーブル39の構成例を示す図である。図に示すように、障害受付番号と、交換部品丸1と、製造NO(部品丸1)と、交換部品丸2と製造NO(部品丸2)と、交換部品丸3と、製造NO(部品丸3)とから構成されている。図より明らかなように、各交換部品毎に製造NOが付されており、図では交換部品丸2で「FAN506」用の部品丸2の製造NO「F11111」が交換部品丸1の交換部品丸1である「FAN506」に充当された場合を示している。図12は輸送車両管理テーブル40の構成例を示す図である。図に示すように、障害受付番号と、配送車番号と、配送車Eメールとから構成されている。
【0028】
このように構成された図1に示すシステムの動作を説明すれば、以下の通りである。図13〜図15は障害受付サーバ2の動作の詳細を示すフローチャート、図16は配送会社サーバの動作を示すフローチャートである。先ず図13〜図15の障害受付サーバ2の動作について説明する。
【0029】
障害受付手段21が顧客システム1からの障害通報メールを受信すると(S1)、障害受付情報を障害受付テーブル36に登録する(S2)。その後、部品検索手段22は障害対応部品テーブル37を検索し、障害の現象に応じて必要となる部品を決定し、当該部品について部品供給会社サーバ4から部品倉庫管理テーブル5を参照して当該部品を保持する該当する部品倉庫を検索する(S3)。
【0030】
そして、当該倉庫に在庫部品があるかどうかをチェックする(S4)。在庫部品がある場合は、部品手配手段24が部品手配の依頼を行なう(S7)。ステップS4において、在庫部品がない場合には、当該案件は重要障害であるかどうかチェックする(S5)。重要障害でない場合には、部品手配手段24が部品手配の依頼を行なう(S7)。当該案件が重要障害である場合には、障害受付サーバ2は、重要障害判断の予測精度が高い部品であるかどうかチェックする(S6)。予測精度が高い部品でない場合には、部品手配依頼を行なう(S7)。予測精度が高い部品である場合にはステップS16にスキップする。ステップS7の部品手配依頼を行なう場合には、部品手配手段24がすべての予測交換部品手配が完了したかどうかチェックする(S8)。すべての予測交換部品手配完了であった場合には処理を終了する(丸4へ)。すべての予測交換部品手配完了でなかった場合にはステップS3にスキップする。
【0031】
ステップS1において、障害通知メールの受信でなかった場合には、部品供給会社サーバ4から部品の払い出し通知があったかどうかチェックする(S9)。部品の払い出し通知があった場合には、前記部品を払い出し部品管理テーブル35に情報登録し、ステータスを[輸送中]とする(図7参照)。次に、輸送車両管理テーブル40に情報を登録する(S11)。
【0032】
次に、ステップS9において、部品の払い出し通知がなかった場合、部品供給会社サーバ4から部品の輸送終了通知があったかどうかチェックする(S12)。部品の輸送終了通知があった場合には、保守員がその部品を受け取ることになるから、払い出し部品管理テーブル35のステータスを[保守員保管中]に更新する(S13)。
【0033】
ステップS12において、部品供給会社サーバ4から部品の輸送終了通知がなかった場合、保守員から保管中の部品のステータス変更通知があったかどうかチェックする(S14)。ステータス変更通知があった場合には、払い出し部品管理テーブル35のステータスを[対応済]に更新する(S15)。
【0034】
ステップS6において、予測精度が高い部品であった場合、ステップS16にスキップする。ステップS16では、保守員が保管している同一部品があるか検索する(S16)。そして、保守員が保管している利用可能な部品の中で交換部品と同一のものがあるかどうかチェックする(S17)。ない場合には、部品手配手段24は他作業のために輸送している部品について当該部品と同じものがあるかどうか検索する(S22)。ある場合には、前記部品が割り当てられている案件が重要障害であるかどうかチェックする(S18)。
【0035】
ステップS18において重要障害でない場合には、部品手配手段24は前記案件における前記部品の予測精度が高いかどうかをチェックする(S19)。予測精度が高いかどうかは、データベース3内の払い出し部品管理テーブル35を検索して判断する。予測精度が高い場合はステップS22にスキップし、輸送車両中の部品について同一部品を検索する処理に移行する。
【0036】
ステップS19において、前記部品の予測精度か低い場合には、部品到着時間比較手段23が保守員が持っている当該部品の障害現場への輸送に要する時間を計算して、振替時間比較テーブル38に登録する(S20)。その後、同一部品の全ての計算を行ったかどうかをチェックする(S21)。終わっていない場合には、ステップS17にスキップして交換部品と同一のものがあるかどうかチェックする動作を繰り返すことになる。
【0037】
当該部品が他作業のために輸送している部品について検索する場合(S22)、部品検索手段22は輸送中の部品の中に同一のものがあるかどうかチェックする(S23)。同一のものがない場合には、ステップS29にスキップする。交換部品と同一のものがあった場合、重要障害判断テーブル32を参照して当該部品が割り当てられている案件は重要障害であるかどうかチェックする(S24)。
【0038】
重要障害であった場合にはステップS28にスキップする。重要障害でなかった場合には、前記案件における前記部品の予測精度が高いかどうかチェックする(S25)。予測精度が高い場合には、ステップS24に戻る。予測精度が低い場合には、障害受付サーバ2は、輸送中車両の現在時点を配送会社サーバ7に問い合わせ、最新情報に更新する(S26)。次に、部品到着までの時間を計算して振替時間比較テーブル38に登録する(S27)。
【0039】
次に、同一部品のすべての計算を行なったかどうかチェックする(S28)。同一部品のすべての計算を行なっていない場合には、ステップS24まで戻る。同一部品の全ての計算を行なっていた場合には、ステップS29に進む。
【0040】
ステップS29では、データベース3の障害対応部品テーブル37に登録されているデータがあるかどうかチェックする(S29)。障害対応部品テーブル37に登録されているデータがない場合には、部品手配手段24が部品手配を行なう(S35)。障害対応部品テーブル37にデータがある場合は、部品到着時間比較手段23は、保守員保管中の部品からの発送(*1)と、輸送車からの発送(*2)との場合を比較して、最も到着予想時間が短いルートを決定する(S30)。
【0041】
決定したルートが保守員保管中の部品からの発送であった場合、部品振替依頼手段25は保守員に対して部品発送依頼メールを送信する(S31)。決定したルートが輸送車からの発送の場合、部品振替依頼手段25は部品の配送先変更処理を行なう(S32)。その後、配送先変更依頼手段26は輸送車ドライバーの輸送車端末8に対して配送先変更メールを送信する(S33)。配送車端末8はこのメールを受け付ける。
【0042】
その後、部品割当管理テーブル39に部品の振替処理情報を登録する(S36)。図11に示すテーブルの場合を例にとると、交換部品(2)の製造NOがF11111の部品を交換部品(1)の製造NOがF11111の場所に移動させる。これで、部品の振替処理が終わったことになる。次に、障害受付サーバ2は、すべての予測交換部品の手配が終わったかどうかチェックする(S37)。全ての予測交換部品の手配が終わったら、ステップS1に戻る。即ち、一連の処理が終了したことになる。全ての予測交換部品の手配が終わっていない場合は、ステップS3に戻り、障害の現象に応じて必要となる部品について部品倉庫を検索する。
【0043】
図16は配送会社サーバ7の動作を示すフローチャートである。先ず、一定間隔毎に輸送車から現在位置情報を取得する(S1)。次に、輸送車両の現在位置の問い合わせがあったかどうかチェックする(S2)。問い合わせがあった時には、障害受付サーバ2に輸送車の現在位置情報を回答する(S3)。該障害受付サーバ2では、この情報を受け付けると、部品到着時間比較手段23が、前記したシステムの障害現場に部品を届ける時間を算出するための位置情報として用いることになる。
【0044】
上述の実施例では、保守部品を手配する場合について説明したが、本発明はこれに限るものではなく、ある地点である品物乃至は商品の在庫が切れてきた場合にも同様に適用することができる。
【0045】
このように、本発明によれば、障害復旧に必要な部品が部品倉庫にないが、前記部品が他の保守員の手元にある場合や、他の障害案件解決のために既に払い出されて配送中の場合であって、今回の障害案件に優先して前記部品を適用すべきと考えられる場合に、前記部品を今回の障害復旧のために再度払い出せるような仕組みを実現することができる。
【0046】
また、倉庫に保守部品がない場合において、他の保守員が当該部品を所持している場合において、当該保守員から当該部品を転送してもらう場合の到着時間と、配送中の部品の中に当該部品がある場合において、配送先を変更した場合の到着時間とを比較して、障害発生地点に早く到達する方法を選択することで、保守部品の供給を速やかに行なうことができる。
【符号の説明】
【0047】
1 顧客システム
2 障害受付サーバ
3 データベース
4 部品供給会社サーバ
5 部品倉庫管理テーブル
6 保守員携帯端末
7 配送会社サーバ
8 輸送車端末
10 ネットワーク
【技術分野】
【0001】
本発明は保守部品手配方法及びシステムに関し、更に詳しくは保守契約を行なっている顧客のシステムから重要障害通報を受け付け、重要な交換部品が部品倉庫に在庫していない場合に、他案件のために既に払い出して他の保守員が保管している部品や他案件を解決するために既に払い出された配送中の部品の中から当案件に転送できそうな部品を割り出して転送依頼を行なう保守部品手配方法及びシステムに関する。
【背景技術】
【0002】
障害が発生すると、障害原因を予測して被疑部品を特定し、被疑部品の在庫があり障害現場に近い部品倉庫に発送依頼を行なうシステムが既に考案されている。しかしながら、部品倉庫に在庫がない場合は新たに部品を発注するか、遠距離にある部品倉庫からの発送を余儀なくされており、障害復旧に時間を要する場合があった。
【0003】
一方、ある障害案件を解決するためにすでに部品倉庫から払い出されたが、障害原因が予測と異なっているために前記部品が使われずに保守員の手元に存在する場合がある。この場合は、後日部品倉庫に返送されることになるが、長期間に亘って保守員の手元に放置されたままの場合があった。このような場合、部品倉庫には部品在庫がないが、保守員の手元にある使用されない部品をすぐに転用できれば便利である。
【0004】
また、障害が発生すると障害原因を予測して被疑部品を特定するが、被疑部品は1種類だけを持って行くのではなく、通常は被疑部品の使用予測精度70%の部品、被疑部品使用予測精度30%の部品というように複数の部品を持って行く場合が多い。例えば、電源が入らないという現象に対しては電源装置を交換すれば復旧する可能性が一番高いが、ファンや電源ケーブルに原因がある場合もある。そのために、電源装置だけではなく、ファンや電源ケーブルなど考えられる全ての交換部品を現場に持っていくことが望ましい。
【0005】
例えばA案件について使用予測精度の低い部品について、他の障害事件(B案件)で被疑部品使用予測精度が前記事件(A案件)よりも高い場合には、使用予測精度が高い事件(B案件)の方に部品を転用した方が便利である。そのため、被疑部品が運送会社のトラックによって配送中であったとしても届け出先を変更した方がよい場合がある。
【0006】
従来のこの種のシステムとしては、ユーザコンピュータ10で障害が発生した際に、ユーザコンピュータ10から通信ネットワーク100を介して障害解析システム20に障害情報が通知され、通知された情報を基に障害解析が行われるものであり、解析の結果、必要となる被疑部品情報を部品管理システム30に通知し、被疑部品を手配し、ユーザ先への発送を行なうようにしたシステムが知られている(例えば特許文献1参照)。
【先行技術文献】
【特許文献】
【0007】
【特許文献1】特開2001−306360号公報(段落0011〜0017、図1)
【発明の概要】
【発明が解決しようとする課題】
【0008】
本発明はこのような課題に鑑みてなされたものであって、障害復旧に必要な部品が部品倉庫にないが、前記部品が他の保守員の手元にある場合や、他の障害案件解決のために既に払い出されて配送中の場合であって、今回の障害案件に、優先して前記部品を適用すべきと考えられる場合に、前記部品を今回の障害復旧のために再度払い出せるような仕組みを実現することができる保守部品手配方法及びシステムを提供することを目的としている。
【課題を解決するための手段】
【0009】
前記した課題を解決するため、本発明は以下のような構成をとる。
【0010】
(1)請求項1記載の発明は、障害受付サーバと、該障害受付サーバと接続された各種テーブルを記憶するデータベースと、部品供給会社サーバと、該部品供給会社サーバと接続された部品を記憶する部品倉庫管理テーブルと、配送会社サーバと、顧客システムと、保守員携帯端末と、配送車端末とがそれぞれネットワークを介して接続されたシステムにおいて、前記障害受付サーバが前記顧客システムから障害通知を受け付けると、障害重要度を含む障害受付情報を登録する工程と、障害の現象から交換部品を予測する工程と、前記障害重要度が低い場合には通常の部品手配を行なう工程と、前記障害重要度が高い場合において、前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がある場合には部品手配依頼を行なう工程と、前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がない場合には、前記部品と同一部品について払い出し中の部品があるか否かを検索する工程と、他の保守員が保管している部品と同一部品であり、かつ前記部品が重要でない部品について検索して、前記保守員に前記部品を転送してもらう工程と、を有することを特徴とする。
【0011】
(2)請求項2記載の発明は、前記部品倉庫管理テーブルの内容を参照して前記部品倉庫に部品がない場合には、前記部品と同一部品について払い出し中の部品があるか否か検索する工程と、他の保守員が保管している部品と同一部品であり、かつ前記部品が重要でない部品について検索して、前記保守員に前記部品を転送してもらう場合の第1の到着時間を計算する工程と、他作業のために配送中の部品があるか否かを検索して、前記部品がありかつ予測精度が低く重要でない部品の場合には配送先を変更した場合の第2の到着時間を計算する工程と、前記第1の到着時間と第2の到着時間を比較して障害発生地点に早く到着する方法を選択して部品手配依頼を行なう工程と、を含むことを特徴とする。
【0012】
(3)請求項3記載の発明は、障害受付サーバと、該障害受付サーバと接続された各種テーブルを記憶するデータベースと、部品供給会社サーバと、該部品供給会社サーバと接続された部品を記憶する部品倉庫管理テーブルと、配送会社サーバと、顧客システムと、保守員携帯端末と、配送車端末とがネットワークを介して接続されたシステムにおいて、前記障害受付サーバが前記顧客システムから障害通知を受け付けると、障害重要度を含む障害受付情報を登録する手段と、障害の現象から交換部品を予測する手段と、前記障害重要度が低い場合には通常の部品手配を行なう手段と、前記障害重要度が高い場合において、前記部品倉庫管理テーブルの内容を参照して在庫部品がある場合には部品手配依頼を行なう手段と、前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がない場合には、前記部品と同一部品について払い出し中の部品があるか否かを検索する手段と、他の保守員が保管している部品と同一部品であり、かつ前記部品が重要でない部品について検索して、前記保守員に前記部品を転送してもらう手段と、を有することを特徴とする。
【発明の効果】
【0013】
本発明によれば、以下のような効果を奏する。
【0014】
(1)請求項1記載の発明によれば、障害復旧に必要な部品が部品倉庫にないが、前記部品が他の保守員の手元にある場合や、他の障害案件解決のために既に払い出されて配送中の場合であって、今回の障害案件に、優先して前記部品を適用すべきと考えられる場合に、前記部品を今回の障害復旧のために再度払い出せるような仕組みを実現することができる。
【0015】
(2)請求項2記載の発明によれば、倉庫に保守部品がない場合において、他の保守員が当該部品を所持している場合において、当該保守員から当該部品を転送してもらう場合の到着時間と、配送中の部品の中に当該部品がある場合において、配送先を変更した場合の到着時間とを比較して、障害発生地点に早く到達する方法を選択することで、保守部品の供給を速やかに行なうことができる。
【0016】
(3)請求項3記載の発明によれば、障害復旧に必要な部品が部品倉庫にないが、前記部品が他の保守員の手元にある場合や、他の障害案件解決のために既に払い出されて配送中の場合であって、今回の障害案件に、優先して前記部品を適用すべきと考えられる場合に、前記部品を今回の障害復旧のために再度払い出せるような仕組みを実現することができる。
【図面の簡単な説明】
【0017】
【図1】本発明の一実施例を示すブロック図である。
【図2】顧客テーブルの構成例を示す図である。
【図3】重要障害判断テーブルの構成例を示す図である。
【図4】保守員テーブルの構成例を示す図である。
【図5】部品倉庫住所テーブルの構成例を示す図である。
【図6】部品倉庫管理テーブルの構成例を示す図である。
【図7】払い出し部品管理テーブルの構成例を示す図である。
【図8】障害受付テーブルの構成例を示す図である。
【図9】障害対応部品テーブルの構成例を示す図である。
【図10】振替時間比較テーブルの構成例を示す図である。
【図11】部品割当管理テーブルの構成例を示す図である。
【図12】輸送車両管理テーブルの構成例を示す図である。
【図13】障害受付サーバの動作を示すフローチャートである。
【図14】障害受付サーバの動作を示すフローチャートである。
【図15】障害受付サーバの動作を示すフローチャートである。
【図16】配送会社サーバの動作を示すフローチャートである。
【発明を実施するための形態】
【0018】
以下、図面を参照して本発明の実施例を詳細に説明する。図1は本発明の一実施例を示すブロック図である。 図において、1は顧客システム、2は該顧客システム1からの障害情報を受け取って障害受付制御を行なう障害受付サーバである。該障害受付サーバ2は、障害受付手段21、部品検索手段22、部品到着時間比較手段23、部品手配手段24、部品振替依頼手段25及び配送先変更依頼手段26とから構成されている。
【0019】
3は障害受付サーバ2と接続され、各種のテーブルを記憶するデータベース(DB)である。該データベース3は、顧客テーブル31、重要障害判断テーブル32、保守員テーブル33、部品倉庫住所テーブル34、払い出し部品管理テーブル35、障害受付テーブル36、障害対応部品テーブル37、振替時間比較テーブル38、部品割当管理テーブル39及び輸送車両管理テーブル40とから構成されている。
【0020】
4は部品供給処理を行なう部品供給会社サーバ、5は該部品供給会社サーバ4と接続された倉庫内の部品の管理情報を記憶している部品倉庫管理テーブルである。6は保守員携帯端末、7は配送会社サーバ、8は輸送車端末である。10はこれら各構成要素間を接続するためのネットワークである。該ネットワーク10としては、例えばインターネット、ISDNネットワーク、LAN等が用いられる。配送会社サーバ7には、輸送状況管理手段71が含まれ、輸送車端末8にはGPS装置81が含まれる。障害受付サーバ2、部品供給会社サーバ4及び配送会社サーバ7としては、例えばパーソナルコンピュータが用いられる。
【0021】
次に、データベース3に記憶されている各種テーブルの構成について説明する。図2は顧客テーブル31の構成例を示す図である。図に示すように顧客名と、顧客ランクと、システム規模と、顧客住所と、顧客Eメールアドレスとから構成されている。ここで、顧客ランクとは、例えば取引量の多さにより区別される。例えば、「通常顧客」と「ロイヤル顧客」とに区別される。ロイヤル顧客は取引量の多い顧客である。
【0022】
図3は重要障害判断テーブル32の構成例を示す図である。図に示すように、顧客ランクとシステム規模と障害重要度とから構成されている。ここで、システム規模とは、システムの規模のことであり、通常の規模である「通常システム」と大きな規模である「社会システム」とに区別される。図4は保守員テーブル33の構成例を示す図である。図に示すように、保守員名と、Eメールアドレスと、所課住所とから構成されている。
【0023】
図5は部品倉庫住所テーブル34の構成例を示す図である。図に示すように、倉庫名と管轄エリアと住所とから構成されている。図6は部品倉庫管理テーブル5の構成例を示す図である。図に示すように、部品名と、部品型名と、対象装置型名と、部品がストックされている倉庫名と、部品の製造NOと、在庫有無と、払い出し期日と、払い出し先とから構成されている。
【0024】
図7は払い出し部品管理テーブル35の構成例を示す図である。図に示すように、部品名と、部品型名と、対象装置型名と、製造NOと、障害受付番号と、予測精度と、担当保守員と、ステータスと、現在地点とから構成されている。ここで、予測精度とは、当該部品が交換部品である可能性のことである。ステータスとは、その部品が今どのような状況におかれているかを示している。
【0025】
図8は障害受付テーブル36の構成例を示す図である。図に示すように、障害受付番号と、受付日と、受付時刻と、顧客名と、装置型名と、障害の現象と、障害重要度から構成されている。図9は障害対応部品テーブル37の構成例を示す図である。図に示すように、現象と、交換部品と、予測精度とから構成されている。例えば、現象が「異常音がする」場合、交換部品としては「ファン」と「メインボード」が考えられ、これら「ファン」と「メインボード」の該当する確率(予測精度)は、「ファン」の場合が高く、「メインボード」の場合は低いことになる。
【0026】
図10は振替時間比較テーブル38の構成例を示す図である。図に示すように、障害受付番号と、部品型名と、製造NOと、保守員所持振替時間と、輸送中部品振替時間とから構成されている。ここで、保守員所持振替時間は、保守員がその部品を持っていた場合に、当該障害箇所に振り替えるまでにかかる時間で、輸送中部品振替時間は、当該部品を輸送中に当該箇所に振り替えるまでにかかる時間を示す。
【0027】
図11は部品割当管理テーブル39の構成例を示す図である。図に示すように、障害受付番号と、交換部品丸1と、製造NO(部品丸1)と、交換部品丸2と製造NO(部品丸2)と、交換部品丸3と、製造NO(部品丸3)とから構成されている。図より明らかなように、各交換部品毎に製造NOが付されており、図では交換部品丸2で「FAN506」用の部品丸2の製造NO「F11111」が交換部品丸1の交換部品丸1である「FAN506」に充当された場合を示している。図12は輸送車両管理テーブル40の構成例を示す図である。図に示すように、障害受付番号と、配送車番号と、配送車Eメールとから構成されている。
【0028】
このように構成された図1に示すシステムの動作を説明すれば、以下の通りである。図13〜図15は障害受付サーバ2の動作の詳細を示すフローチャート、図16は配送会社サーバの動作を示すフローチャートである。先ず図13〜図15の障害受付サーバ2の動作について説明する。
【0029】
障害受付手段21が顧客システム1からの障害通報メールを受信すると(S1)、障害受付情報を障害受付テーブル36に登録する(S2)。その後、部品検索手段22は障害対応部品テーブル37を検索し、障害の現象に応じて必要となる部品を決定し、当該部品について部品供給会社サーバ4から部品倉庫管理テーブル5を参照して当該部品を保持する該当する部品倉庫を検索する(S3)。
【0030】
そして、当該倉庫に在庫部品があるかどうかをチェックする(S4)。在庫部品がある場合は、部品手配手段24が部品手配の依頼を行なう(S7)。ステップS4において、在庫部品がない場合には、当該案件は重要障害であるかどうかチェックする(S5)。重要障害でない場合には、部品手配手段24が部品手配の依頼を行なう(S7)。当該案件が重要障害である場合には、障害受付サーバ2は、重要障害判断の予測精度が高い部品であるかどうかチェックする(S6)。予測精度が高い部品でない場合には、部品手配依頼を行なう(S7)。予測精度が高い部品である場合にはステップS16にスキップする。ステップS7の部品手配依頼を行なう場合には、部品手配手段24がすべての予測交換部品手配が完了したかどうかチェックする(S8)。すべての予測交換部品手配完了であった場合には処理を終了する(丸4へ)。すべての予測交換部品手配完了でなかった場合にはステップS3にスキップする。
【0031】
ステップS1において、障害通知メールの受信でなかった場合には、部品供給会社サーバ4から部品の払い出し通知があったかどうかチェックする(S9)。部品の払い出し通知があった場合には、前記部品を払い出し部品管理テーブル35に情報登録し、ステータスを[輸送中]とする(図7参照)。次に、輸送車両管理テーブル40に情報を登録する(S11)。
【0032】
次に、ステップS9において、部品の払い出し通知がなかった場合、部品供給会社サーバ4から部品の輸送終了通知があったかどうかチェックする(S12)。部品の輸送終了通知があった場合には、保守員がその部品を受け取ることになるから、払い出し部品管理テーブル35のステータスを[保守員保管中]に更新する(S13)。
【0033】
ステップS12において、部品供給会社サーバ4から部品の輸送終了通知がなかった場合、保守員から保管中の部品のステータス変更通知があったかどうかチェックする(S14)。ステータス変更通知があった場合には、払い出し部品管理テーブル35のステータスを[対応済]に更新する(S15)。
【0034】
ステップS6において、予測精度が高い部品であった場合、ステップS16にスキップする。ステップS16では、保守員が保管している同一部品があるか検索する(S16)。そして、保守員が保管している利用可能な部品の中で交換部品と同一のものがあるかどうかチェックする(S17)。ない場合には、部品手配手段24は他作業のために輸送している部品について当該部品と同じものがあるかどうか検索する(S22)。ある場合には、前記部品が割り当てられている案件が重要障害であるかどうかチェックする(S18)。
【0035】
ステップS18において重要障害でない場合には、部品手配手段24は前記案件における前記部品の予測精度が高いかどうかをチェックする(S19)。予測精度が高いかどうかは、データベース3内の払い出し部品管理テーブル35を検索して判断する。予測精度が高い場合はステップS22にスキップし、輸送車両中の部品について同一部品を検索する処理に移行する。
【0036】
ステップS19において、前記部品の予測精度か低い場合には、部品到着時間比較手段23が保守員が持っている当該部品の障害現場への輸送に要する時間を計算して、振替時間比較テーブル38に登録する(S20)。その後、同一部品の全ての計算を行ったかどうかをチェックする(S21)。終わっていない場合には、ステップS17にスキップして交換部品と同一のものがあるかどうかチェックする動作を繰り返すことになる。
【0037】
当該部品が他作業のために輸送している部品について検索する場合(S22)、部品検索手段22は輸送中の部品の中に同一のものがあるかどうかチェックする(S23)。同一のものがない場合には、ステップS29にスキップする。交換部品と同一のものがあった場合、重要障害判断テーブル32を参照して当該部品が割り当てられている案件は重要障害であるかどうかチェックする(S24)。
【0038】
重要障害であった場合にはステップS28にスキップする。重要障害でなかった場合には、前記案件における前記部品の予測精度が高いかどうかチェックする(S25)。予測精度が高い場合には、ステップS24に戻る。予測精度が低い場合には、障害受付サーバ2は、輸送中車両の現在時点を配送会社サーバ7に問い合わせ、最新情報に更新する(S26)。次に、部品到着までの時間を計算して振替時間比較テーブル38に登録する(S27)。
【0039】
次に、同一部品のすべての計算を行なったかどうかチェックする(S28)。同一部品のすべての計算を行なっていない場合には、ステップS24まで戻る。同一部品の全ての計算を行なっていた場合には、ステップS29に進む。
【0040】
ステップS29では、データベース3の障害対応部品テーブル37に登録されているデータがあるかどうかチェックする(S29)。障害対応部品テーブル37に登録されているデータがない場合には、部品手配手段24が部品手配を行なう(S35)。障害対応部品テーブル37にデータがある場合は、部品到着時間比較手段23は、保守員保管中の部品からの発送(*1)と、輸送車からの発送(*2)との場合を比較して、最も到着予想時間が短いルートを決定する(S30)。
【0041】
決定したルートが保守員保管中の部品からの発送であった場合、部品振替依頼手段25は保守員に対して部品発送依頼メールを送信する(S31)。決定したルートが輸送車からの発送の場合、部品振替依頼手段25は部品の配送先変更処理を行なう(S32)。その後、配送先変更依頼手段26は輸送車ドライバーの輸送車端末8に対して配送先変更メールを送信する(S33)。配送車端末8はこのメールを受け付ける。
【0042】
その後、部品割当管理テーブル39に部品の振替処理情報を登録する(S36)。図11に示すテーブルの場合を例にとると、交換部品(2)の製造NOがF11111の部品を交換部品(1)の製造NOがF11111の場所に移動させる。これで、部品の振替処理が終わったことになる。次に、障害受付サーバ2は、すべての予測交換部品の手配が終わったかどうかチェックする(S37)。全ての予測交換部品の手配が終わったら、ステップS1に戻る。即ち、一連の処理が終了したことになる。全ての予測交換部品の手配が終わっていない場合は、ステップS3に戻り、障害の現象に応じて必要となる部品について部品倉庫を検索する。
【0043】
図16は配送会社サーバ7の動作を示すフローチャートである。先ず、一定間隔毎に輸送車から現在位置情報を取得する(S1)。次に、輸送車両の現在位置の問い合わせがあったかどうかチェックする(S2)。問い合わせがあった時には、障害受付サーバ2に輸送車の現在位置情報を回答する(S3)。該障害受付サーバ2では、この情報を受け付けると、部品到着時間比較手段23が、前記したシステムの障害現場に部品を届ける時間を算出するための位置情報として用いることになる。
【0044】
上述の実施例では、保守部品を手配する場合について説明したが、本発明はこれに限るものではなく、ある地点である品物乃至は商品の在庫が切れてきた場合にも同様に適用することができる。
【0045】
このように、本発明によれば、障害復旧に必要な部品が部品倉庫にないが、前記部品が他の保守員の手元にある場合や、他の障害案件解決のために既に払い出されて配送中の場合であって、今回の障害案件に優先して前記部品を適用すべきと考えられる場合に、前記部品を今回の障害復旧のために再度払い出せるような仕組みを実現することができる。
【0046】
また、倉庫に保守部品がない場合において、他の保守員が当該部品を所持している場合において、当該保守員から当該部品を転送してもらう場合の到着時間と、配送中の部品の中に当該部品がある場合において、配送先を変更した場合の到着時間とを比較して、障害発生地点に早く到達する方法を選択することで、保守部品の供給を速やかに行なうことができる。
【符号の説明】
【0047】
1 顧客システム
2 障害受付サーバ
3 データベース
4 部品供給会社サーバ
5 部品倉庫管理テーブル
6 保守員携帯端末
7 配送会社サーバ
8 輸送車端末
10 ネットワーク
【特許請求の範囲】
【請求項1】
障害受付サーバと、該障害受付サーバと接続された各種テーブルを記憶するデータベースと、部品供給会社サーバと、該部品供給会社サーバと接続された部品を記憶する部品倉庫管理テーブルと、配送会社サーバと、顧客システムと、保守員携帯端末と、配送車端末とがそれぞれネットワークを介して接続されたシステムにおいて、
前記障害受付サーバが前記顧客システムから障害通知を受け付けると、障害重要度を含む障害受付情報を登録する工程と、
障害の現象から交換部品を予測する工程と、
前記障害重要度が低い場合には通常の部品手配を行なう工程と、
前記障害重要度が高い場合において、前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がある場合には部品手配依頼を行なう工程と、
前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がない場合には、前記部品と同一部品について払い出し中の部品があるか否かを検索する工程と、
他の保守員が保管している部品と同一部品であり、かつ前記部品が重要でない部品について検索して、前記保守員に前記部品を転送してもらう工程と、
を有することを特徴とする保守部品手配方法。
【請求項2】
前記部品倉庫管理テーブルの内容を参照して前記部品倉庫に部品がない場合には、前記部品と同一部品について払い出し中の部品があるか否か検索する工程と、
他の保守員が保管している部品と同一部品であり、かつ前記部品が重要でない部品について検索して、前記保守員に前記部品を転送してもらう場合の第1の到着時間を計算する工程と、
他作業のために配送中の部品があるか否かを検索して、前記部品がありかつ予測精度が低く重要でない部品の場合には配送先を変更した場合の第2の到着時間を計算する工程と、
前記第1の到着時間と第2の到着時間を比較して障害発生地点に早く到着する方法を選択して部品手配依頼を行なう工程と、
を含むことを特徴とする請求項1記載の保守部品手配方法。
【請求項3】
障害受付サーバと、該障害受付サーバと接続された各種テーブルを記憶するデータベースと、部品供給会社サーバと、該部品供給会社サーバと接続された部品を記憶する部品倉庫管理テーブルと、配送会社サーバと、顧客システムと、保守員携帯端末と、配送車端末とがネットワークを介して接続されたシステムにおいて、
前記障害受付サーバが前記顧客システムから障害通知を受け付けると、障害重要度を含む障害受付情報を登録する手段と、
障害の現象から交換部品を予測する手段と、
前記障害重要度が低い場合には通常の部品手配を行なう手段と、
前記障害重要度が高い場合において、前記部品倉庫管理テーブルの内容を参照して在庫部品がある場合には部品手配依頼を行なう手段と、
前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がない場合には、前記部品と同一部品について払い出し中の部品があるか否かを検索する手段と、
他の保守員が保管している部品と同一部品であり、かつ前記部品が重要でない部品について検索して、前記保守員に前記部品を転送してもらう手段と、
を有することを特徴とする保守部品手配システム。
【請求項1】
障害受付サーバと、該障害受付サーバと接続された各種テーブルを記憶するデータベースと、部品供給会社サーバと、該部品供給会社サーバと接続された部品を記憶する部品倉庫管理テーブルと、配送会社サーバと、顧客システムと、保守員携帯端末と、配送車端末とがそれぞれネットワークを介して接続されたシステムにおいて、
前記障害受付サーバが前記顧客システムから障害通知を受け付けると、障害重要度を含む障害受付情報を登録する工程と、
障害の現象から交換部品を予測する工程と、
前記障害重要度が低い場合には通常の部品手配を行なう工程と、
前記障害重要度が高い場合において、前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がある場合には部品手配依頼を行なう工程と、
前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がない場合には、前記部品と同一部品について払い出し中の部品があるか否かを検索する工程と、
他の保守員が保管している部品と同一部品であり、かつ前記部品が重要でない部品について検索して、前記保守員に前記部品を転送してもらう工程と、
を有することを特徴とする保守部品手配方法。
【請求項2】
前記部品倉庫管理テーブルの内容を参照して前記部品倉庫に部品がない場合には、前記部品と同一部品について払い出し中の部品があるか否か検索する工程と、
他の保守員が保管している部品と同一部品であり、かつ前記部品が重要でない部品について検索して、前記保守員に前記部品を転送してもらう場合の第1の到着時間を計算する工程と、
他作業のために配送中の部品があるか否かを検索して、前記部品がありかつ予測精度が低く重要でない部品の場合には配送先を変更した場合の第2の到着時間を計算する工程と、
前記第1の到着時間と第2の到着時間を比較して障害発生地点に早く到着する方法を選択して部品手配依頼を行なう工程と、
を含むことを特徴とする請求項1記載の保守部品手配方法。
【請求項3】
障害受付サーバと、該障害受付サーバと接続された各種テーブルを記憶するデータベースと、部品供給会社サーバと、該部品供給会社サーバと接続された部品を記憶する部品倉庫管理テーブルと、配送会社サーバと、顧客システムと、保守員携帯端末と、配送車端末とがネットワークを介して接続されたシステムにおいて、
前記障害受付サーバが前記顧客システムから障害通知を受け付けると、障害重要度を含む障害受付情報を登録する手段と、
障害の現象から交換部品を予測する手段と、
前記障害重要度が低い場合には通常の部品手配を行なう手段と、
前記障害重要度が高い場合において、前記部品倉庫管理テーブルの内容を参照して在庫部品がある場合には部品手配依頼を行なう手段と、
前記部品倉庫管理テーブルの内容を参照して部品倉庫に在庫部品がない場合には、前記部品と同一部品について払い出し中の部品があるか否かを検索する手段と、
他の保守員が保管している部品と同一部品であり、かつ前記部品が重要でない部品について検索して、前記保守員に前記部品を転送してもらう手段と、
を有することを特徴とする保守部品手配システム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【公開番号】特開2012−198783(P2012−198783A)
【公開日】平成24年10月18日(2012.10.18)
【国際特許分類】
【出願番号】特願2011−62775(P2011−62775)
【出願日】平成23年3月22日(2011.3.22)
【出願人】(598057291)株式会社富士通エフサス (147)
【公開日】平成24年10月18日(2012.10.18)
【国際特許分類】
【出願日】平成23年3月22日(2011.3.22)
【出願人】(598057291)株式会社富士通エフサス (147)
[ Back to top ]