(57)【要約】 【課題】  故障部品を検証する際に、故障部品を効率よく配送する。【解決手段】  自動車販売会社の端末１００から配送管理サーバ１０１に、故障した自動車部品の回収リクエストを送信する。配送先設定データベース１０２は、自動車部品が故障したときの配送先の情報を記憶している。サーバ１０１は、受信した回収リクエストに含まれる故障部品の部品番号に対応する配送先の情報を検索抽出する。さらに、サーバ１０１は、配送先の情報に従って配送リクエストを物流担当の端末１３０に送信する。サーバ１０１は、故障部品の検証をメーカーが担当しない場合にも、故障部品やその配送スケジュール及び検証結果等の情報をメーカーに報告する。【選択図】  図１
2005138987.tif 000002
【特許請求の範囲】
【請求項１】
自動車販売会社から回収される故障した自動車部品の配送処理を管理する配送管理システムであって、
自動車部品ごとに該自動車部品が故障したときの配送先の情報を記憶した配送先データベースと、
故障した自動車部品について自動車販売会社の端末から送信される回収リクエストを受信する回収リクエスト受信手段と、
前記受信した回収リクエストに含まれる前記故障した自動車部品の識別情報に基づいて、該故障した自動車部品の配送先の情報を前記配送先データベースから検索抽出する検索抽出手段と、
前記検索抽出された配送先の情報に従って該配送先へと前記故障した自動車部品を配送させるための配送リクエストを物流担当の端末に送信する配送リクエスト送信手段と、
前記故障した自動車部品の回収に関して、該回収のスケジュール等の回収情報を、予め登録された第１のアドレス宛てに送信する回収情報送信手段と、
前記物流担当による前記配送先への前記故障した自動車部品の配送が完了すると、該故障した自動車部品に関する配送完了情報を、予め登録された第２のアドレス宛てに送信する配送完了情報送信手段と
を含む配送管理システム。
【請求項２】
前記配送先データベースは、さらに前記配送先の情報と故障内容とを対応付けて記憶しており、
前記検索抽出手段は、前記回収リクエストに含まれている前記故障した自動車部品の識別情報と前記故障内容とに基づいて、該故障した自動車部品の配送先の情報を前記配送先データベースから検索抽出することを特徴とする請求項１に記載の配送管理システム。
【請求項３】
前記配送先データベースが、一つの自動車部品について複数の配送先の情報を対応付けて記憶する場合は、さらに、該複数の配送先のうちどれを優先すべきかを表す優先順位情報も前記自動車部品の識別情報と対応付けて記憶していることを特徴とする請求項１または２に記載の配送管理システム。
【請求項４】
前記配送先の検索抽出の際に、前記検索抽出手段により、前記回収対象の自動車部品に関する前記配送先の優先順位情報も検索抽出された場合に、該優先順位情報にしたがって配送順序を決定する配送順序決定手段と、
前記検索抽出された各配送先のアドレスに対して、前記決定された配送順序を承諾するか否かの問い合わせ情報を送信する問合情報送信手段と、
前記問合情報への応答として各配送先から送信される承諾情報を受信する承諾情報受信手段と、
前記受信された承諾情報に基づいて必要であれば前記配送順序を変更する配送順序変更手段と
を含み、
前記回収情報は前記配送順序が反映されていることを特徴とする請求項３に記載の配送管理システム。
【請求項５】
前記配送先データベースが、各自動車部品ごとに回収の要・不要に関する情報を記憶している場合、前記回収リクエストが受信されると、該回収リクエストに関連する自動車部品の回収の要・不要に関する情報を前記検索抽出手段により検索抽出し、該検索抽出された回収の要・不要に関する情報が回収不要を示しているか否かを判定する回収要・不要判定手段と、
前記回収不要と判定された場合に、前記回収リクエストを送信してきた自動車販売会社の端末に対して回収不要を表す情報を送信する回収不要情報送信手段と
をさらに含む請求項１ないし請求項４の何れか１項に記載の配送管理システム。
【請求項６】
前記回収不要の自動車部品の識別情報と対応付けて故障原因に関する情報を記憶する故障対応データベースと、
回収不要と判定された場合に、前記故障対応データベースから前記故障原因に関する情報を検索抽出する故障原因検索抽出手段と
をさらに備え、
前記回収不要情報送信手段は、前記回収リクエストを送信してきた前記自動車会社の端末に対して前記検索抽出された故障原因に関する情報も送信することを特徴とする請求項５に記載の配送管理システム。
【請求項７】
前記故障した自動車部品を検証する検証担当のアドレスと該自動車部品の識別情報とを対応付けて記憶する検証担当データベースと、
前記回収リストに関連する故障した自動車部品の識別情報に基づいて、対応する前記検証担当のアドレスを検索抽出する検証担当検索抽出手段と、
前記検索抽出された前記検証担当のアドレスに対し、前記故障した自動車部品の配送先の情報と配送スケジュールに関する情報とを送信する配送先情報送信手段と
をさらに含む請求項１ないし６の何れか１項に記載の配送管理システム。
【請求項８】
前記故障した自動車部品の検証結果の送信宛先アドレスと該自動車部品の識別情報とを対応付けて記憶する検証担当データベースと、
検証結果が入力されると、前記回収リストに関連する故障した自動車部品の識別情報に基づいて、対応する前記検証結果の送信宛先アドレスを検索抽出する検証結果アドレス検索抽出手段と、
前記検索抽出された前記検証結果の送信宛先アドレスに対し、前記入力された検証結果を送信する検証結果送信手段と
をさらに含む請求項１しない７の何れかに記載の配送管理システム。
【請求項９】
前記配送先に関する情報が検索抽出されると、該配送先の情報と、前記故障した自動車部品の故障内容に関する情報とを含む配送承認リクエストを、予め設定された承認担当のアドレスに対して送信する配送承認リクエスト送信手段と、
前記配送承認リクエストに対する応答として承認可否情報を受信する承認可否情報受信手段とをさらに備え、
前記配送リクエスト送信手段は、前記受信された承認可否情報が配送の承認を意味しているときは、承認された配送先に配送リクエストを送信し、該承認可否情報が承認の却下又は配送先の変更を意味しているときは、前記承認担当の端末から指定された配送先に対して前記配送リクエストを送信することを特徴とする請求項１ないし８の何れか１項に記載の配送管理システム。
【請求項１０】
前記自動車部品ごとの大きさ及び質量に関する情報を記憶した部品データベースをさらに備え、
前記配送リクエスト送信手段は、配送対象となっている前記故障した自動車部品について前記部品データベースから読み出された大きさ及び質量に関する情報とともに、前記配送リクエストを前記物流担当の端末に送信することを特徴とする請求項１ないし９の何れか１項に記載の配送管理システム。
【請求項１１】
前記配送先データベースに記憶されている内容の変更リクエストを受信する変更リクエスト受信手段と、
前記変更リクエストを受信すると、予め登録された変更承認担当のアドレスに対して変更承認リクエストを送信する変更承認リクエスト送信手段と、
前記変更承認リクエストに対する応答が変更承認を意味している場合に前記配送先データベースに記憶されている内容の変更を許可する変更制御手段と
をさらに含む請求項１ないし１０の何れか１項に配送管理システム。
【請求項１２】
自動車販売会社から回収される故障した自動車部品の配送処理を管理する配送管理方法であって、
故障した自動車部品について自動車販売会社の端末から送信される回収リクエストを受信するステップと、
自動車部品ごとに該自動車部品が故障したときの配送先の情報を記憶した配送先データベースから、前記受信した回収リクエストに含まれる前記故障した自動車部品の識別情報に基づいて、該故障した自動車部品の配送先の情報を検索抽出するステップと、
前記検索抽出された配送先の情報に従って該配送先へと前記故障した自動車部品を配送させるための配送リクエストを物流担当の端末に送信するステップと、
前記故障した自動車部品の回収に関して、該回収のスケジュール等の回収情報を、予め登録された第１のアドレス宛てに送信するステップと、
前記物流担当による前記配送先への前記故障した自動車部品の配送が完了すると、該故障した自動車部品に関する配送完了情報を、予め登録された第２のアドレス宛てに送信するステップと
を含む配送管理方法。
【請求項１３】
前記配送先データベースは、さらに前記配送先の情報と故障内容とを対応付けて記憶しており、
前記検索抽出のステップにおいて、前記回収リクエストに含まれている前記故障した自動車部品の識別情報と前記故障内容とに基づいて、該故障した自動車部品の配送先の情報を前記配送先データベースから検索抽出することを特徴とする請求項１２に記載の配送管理方法。
【請求項１４】
前記配送先データベースが、一つの自動車部品について複数の配送先の情報を対応付けて記憶する場合は、さらに、該複数の配送先のうちどれを優先すべきかを表す優先順位情報も前記自動車部品の識別情報と対応付けて記憶していることを特徴とする請求項１２または１３に記載の配送管理方法。
【請求項１５】
前記配送先の検索抽出の際に、前記回収対象の自動車部品に関する前記配送先の優先順位情報も検索抽出された場合に、該優先順位情報にしたがって配送順序を決定するステップと、
前記検索抽出された各配送先のアドレスに対して、前記決定された配送順序を承認するか否かの問い合わせ情報を送信するステップと、
前記問合情報への応答として各配送先から送信される承諾情報を受信するステップと、
前記受信された承諾情報に基づいて必要であれば前記配送順序を変更するステップと
を含み、
前記回収情報は前記配送順序が反映されていることを特徴とする請求項１４に記載の配送管理方法。
【請求項１６】
前記配送先データベースが、各自動車部品ごとに回収の要・不要に関する情報を記憶している場合、前記回収リクエストが受信されると、該回収リクエストに関連する自動車部品の回収の要・不要に関する情報を検索抽出し、該検索抽出された回収の要・不要に関する情報が回収不要を示しているか否かを判定するステップと、
前記回収不要と判定された場合に、前記回収リクエストを送信してきた自動車販売会社の端末に対して回収不要を表す情報を送信するステップと
をさらに含む請求項１２ないし請求項１５の何れか１項に記載の配送管理方法。
【請求項１７】
前記回収不要と判定された場合に、前記回収不要の自動車部品の識別情報と対応付けて故障原因に関する情報を記憶する故障対応データベースから、前記故障原因に関する情報を検索抽出するステップと、
前記回収リクエストを送信してきた前記自動車会社の端末に対して前記検索抽出された故障原因に関する情報を送信するステップと
をさらに含む請求項１６に記載の配送管理方法。
【請求項１８】
前記故障した自動車部品を検証する検証担当のアドレスと該自動車部品の識別情報とを対応付けて記憶する検証担当データベースから、前記回収リストに関連する故障した自動車部品の識別情報に基づいて、対応する前記検証担当のアドレスを検索抽出するステップと、
前記検索抽出された前記検証担当のアドレスに対し、前記故障した自動車部品の配送先の情報と配送スケジュールに関する情報とを送信するステップと
をさらに含む請求項１２ないし１７の何れか１項に記載の配送管理方法。
【請求項１９】
検証結果が入力されると、前記故障した自動車部品の検証結果の送信宛先アドレスと該自動車部品の識別情報とを対応付けて記憶する検証担当データベースから、前記回収リストに関連する故障した自動車部品の識別情報に基づいて、対応する前記検証結果の送信宛先アドレスを検索抽出するステップと、
前記検索抽出された前記検証結果の送信宛先アドレスに対し、前記入力された検証結果を送信するステップと
をさらに含む請求項１２ないし１８の何れか１項に記載の配送管理方法。
【請求項２０】
前記配送先に関する情報が検索抽出されると、該配送先の情報と、前記故障した自動車部品の故障内容に関する情報とを含む配送承認リクエストを、予め設定された承認担当のアドレスに対して送信するステップと、
前記配送承認リクエストに対する応答として承認可否情報を受信するステップと、
前記受信された承認可否情報が配送の承認を意味しているときは、承認された配送先に配送リクエストを送信し、該承認可否情報が承認の却下又は配送先の変更を意味しているときは、前記承認担当の端末から指定された配送先に対して前記配送リクエストを送信するステップと
をさらに含む請求項１２ないし１９の何れか１項に記載の配送管理方法。
【請求項２１】
前記自動車部品ごとの大きさ及び質量に関する情報を記憶した部品データベースから、配送対象となっている前記故障した自動車部品について読み出された大きさ及び質量に関する情報を前記物流担当の端末に送信するステップをさらに含む請求項１２ないし２０の何れか１項に記載の配送管理方法。
【請求項２２】
前記配送先データベースに記憶されている内容の変更リクエストを受信するステップと、
前記変更リクエストを受信すると、予め登録された変更承認担当のアドレスに対して変更承認リクエストを送信するステップと、
前記変更承認リクエストに対する応答が変更承認を意味している場合に前記配送先データベースに記憶されている内容の変更を許可するステップと
をさらに含む請求項１２ないし２１の何れか１項に記載の配送管理方法。
【請求項２３】
請求項１２ないし２２の何れか１項に記載の配送管理方法の各ステップをコンピュータにおいて実行させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、故障した自動車部品の回収処理及び検証処理において有用な配送管理システムに関する。
【背景技術】
【０００２】
自動車部品は、非常に多くの種類及び形式が存在するため、全ての補修部品をサプライヤーの各販売拠点に保管しておくことは困難であった。特許文献１に記載の技術によれば、サプライヤー販売拠点の限られたスペースに適切な種類と適切な数の補修用部品を保管し、顧客の注文に対して販売拠点からの即時納入比率を向上させた在庫管理システムを検討している。
【特許文献１】特開２００２−３４２４３１号。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ところで、一般に自動車産業界においては、部品メーカー（サプライヤー）が自動車メーカーに自動車の各部品を供給し、自動車メーカーが各部品を組み立てて自動車を完成させ、最後に自動車販売会社（ディーラー）が各ユーザーに完成した自動車を販売するといった取引形態が確立されている。とりわけ、ユーザーはディーラーとの関係が密接であるため、仮に自動車の任意の部品が故障すると、ユーザーはディーラーに自動車や当該故障部品を持ち込み、修理を依頼することになる。
【０００４】
故障した部品については、その原因を分析・検証し、必要であれば部品を改良することも考えられる。
【０００５】
そのため、ディーラーは、故障部品の回収をメーカーに依頼し、メーカーが当該故障部品を回収して、故障の原因を検証し、故障対策の確立や、部品の改善などを実行する。これらの作業は一般にメーカーの品質保証部門が担当することになるが、部品の種類によっては、メーカーで一次検証作業を実行し、その後で、サプライヤーが故障原因についての二次検証を担当することも多い。
【０００６】
ときには、メーカーで一次検証を行なうことのできないような故障部品もあるが、従来は、そのような場合にも必ずメーカーの品質保証部門に故障部品が配送され、その後で、サプライヤーへと故障部品が回送されていた。
【０００７】
このように、メーカーにおける一次検証が不要な場合は、ディーラーから直接的にサプライヤーへと故障部品を配送できれば、コスト的にも時間的にも効率が改善されよう。例えば、メーカーが広島にあり、ディーラーが北海道にあり、そしてサプライヤーが関東にあると仮定すると、本来は、北海道から関東のサプライヤーへと故障部品を配送すればよい。しかしながら、従来は、故障部品が北海道のディーラーから広島のメーカーへと配送され、そして広島から関東のサプライヤーに配送されていたため、コスト的にも時間的にも無駄が多かった。
【０００８】
ところが、ディーラーは、サプライヤーと直接の取引関係がないため、どの部品がどのサプライヤーから提供されたものかを知る由もなく、ディーラーから直接的にサプライヤーへと故障部品を配送することができなかった。また、メーカーの一次検証が必要な部品なのか不要な部品なのかも把握することができなかった。
【０００９】
その一方で、メーカーを介さずにディーラーとサプライヤー間で故障部品の配送がなされてしまうと、メーカーは故障に関する情報を得ることができなくなり、メーカーのイニシアチブが損なわれ兼ねない。特に、自動車メーカーが故障等の情報を十分に把握できなければ顧客満足度が低下しかねない。
【００１０】
そこで、本発明は、故障部品の検証に伴う配送効率等を改善することを目的とする。
【課題を解決するための手段】
【００１１】
はじめに本発明の上位概念たる技術思想を説明する。本発明の第１の観点は、自動車販売会社から回収される故障した自動車部品の配送処理を管理する配送管理システムであって、自動車部品ごとに該自動車部品が故障したときの配送先の情報を記憶した配送先データベースと、故障した自動車部品について自動車販売会社の端末から送信される回収リクエストを受信する回収リクエスト受信手段と、前記受信した回収リクエストに含まれる前記故障した自動車部品の識別情報に基づいて、該故障した自動車部品の配送先の情報を前記配送先データベースから検索抽出する検索抽出手段と、前記検索抽出された配送先の情報に従って該配送先へと前記故障した自動車部品を配送させるための配送リクエストを物流担当の端末に送信する配送リクエスト送信手段を備えることを特徴とする。さらに、前記故障した自動車部品の回収に関して、該回収のスケジュール等の回収情報を、予め登録された第１のアドレス宛てに送信する回収情報送信手段を備えてもよい。また、前記物流担当による前記配送先への前記故障した自動車部品の配送が完了すると、該故障した自動車部品に関する配送完了情報を、予め登録された第２のアドレス宛てに送信する配送完了情報送信手段を備えてもよい。なお、第１のアドレスと第２のアドレスとが同一のアドレスであっても異なるアドレスであってもよいことはいうまでもない。
【００１２】
本発明の第２の観点は、上記第１の観点において、前記配送先データベースが、さらに前記配送先の情報と故障内容とを対応付けて記憶しており、前記検索抽出手段は、前記回収リクエストに含まれている前記故障した自動車部品の識別情報と前記故障内容とに基づいて、該故障した自動車部品の配送先の情報を前記配送先データベースから検索抽出することを特徴とする。
【００１３】
本発明の第３の観点は、第１または第２の観点において、前記配送先データベースが、一つの自動車部品について複数の配送先の情報を対応付けて記憶する場合は、さらに、該複数の配送先のうちどれを優先すべきかを表す優先順位情報も前記自動車部品の識別情報と対応付けて記憶していることを特徴とする。
【００１４】
本発明の第４の観点は、第３の観点において、前記配送先の検索抽出の際に、前記検索抽出手段により、前記回収対象の自動車部品に関する前記配送先の優先順位情報も検索抽出された場合に、該優先順位情報にしたがって配送順序を決定する配送順序決定手段と、前記検索抽出された各配送先のアドレスに対して、前記決定された配送順序を承諾するか否かの問い合わせ情報を送信する問合情報送信手段と、前記問合情報への応答として各配送先から送信される承諾情報を受信する承諾情報受信手段と、前記受信された承諾情報に基づいて必要であれば前記配送順序を変更する配送順序変更手段とを含み、前記回収情報は前記配送順序が反映されていることを特徴とする。
【００１５】
本発明の第５の観点は、第１ないし第４の観点において、前記配送先データベースが、各自動車部品ごとに回収の要・不要に関する情報を記憶している場合、前記回収リクエストが受信されると、該回収リクエストに関連する自動車部品の回収の要・不要に関する情報を前記検索抽出手段により検索抽出し、該検索抽出された回収の要・不要に関する情報が回収不要を示しているか否かを判定する回収要・不要判定手段と、前記回収不要と判定された場合に前記回収リクエストを送信してきた自動車販売会社の端末に対して回収不要を表す情報を送信する回収不要情報送信手段とをさらに含むことを特徴とする。
【００１６】
本発明の第６の観点は、第５の観点において、前記回収不要の自動車部品の識別情報と対応付けて故障原因に関する情報を記憶する故障対応データベースと、前記回収不要と判定された場合に、前記故障対応データベースから前記故障原因に関する情報を検索抽出する故障原因検索抽出手段とをさらに備え、前記回収不要情報送信手段は、前記回収リクエストを送信してきた前記自動車会社の端末に対して前記検索抽出された故障原因に関する情報も送信することを特徴とする。
【００１７】
本発明の第７の観点は、第１ないし第６の観点において、前記故障した自動車部品を検証する検証担当のアドレスと該自動車部品の識別情報とを対応付けて記憶する検証担当データベースと、前記回収リストに関連する故障した自動車部品の識別情報に基づいて、対応する前記検証担当のアドレスを検索抽出する検証担当検索抽出手段と、前記検索抽出された前記検証担当のアドレスに対し、前記故障した自動車部品の配送先の情報と配送スケジュールに関する情報とを送信する配送先情報送信手段とをさらに含むことを特徴とする。
【００１８】
本発明の第８の観点は、第１ないし第７の観点において、前記故障した自動車部品の検証結果の送信宛先アドレスと該自動車部品の識別情報とを対応付けて記憶する検証担当データベースと、検証結果が入力されると、前記回収リストに関連する故障した自動車部品の識別情報に基づいて、対応する前記検証結果の送信宛先アドレスを検索抽出する検証結果アドレス検索抽出手段と、前記検索抽出された前記検証結果の送信宛先アドレスに対し、前記入力された検証結果を送信する検証結果送信手段とをさらに含むことを特徴とする。
【００１９】
本発明の第９の観点によれば、第１ないし第８の観点において、前記配送先に関する情報が検索抽出されると、該配送先の情報と、前記故障した自動車部品の故障内容に関する情報とを含む配送承認リクエストを、予め設定された承認担当のアドレスに対して送信する配送承認リクエスト送信手段と、前記配送承認リクエストに対する応答として承認可否情報を受信する承認可否情報受信手段とをさらに備え、前記配送リクエスト送信手段は、前記受信された承認可否情報が配送の承認を意味しているときは、承認された配送先に配送リクエストを送信し、該承認可否情報が承認の却下又は配送先の変更を意味しているときは、前記承認担当の端末から指定された配送先に対して前記配送リクエストを送信することを特徴とする。
【００２０】
本発明の第１０の観点は、第１ないし第９の観点において、前記自動車部品ごとの大きさ及び質量に関する情報を記憶した部品データベースをさらに備え、前記配送リクエスト送信手段は、配送対象となっている前記故障した自動車部品について前記部品データベースから読み出された大きさ及び質量に関する情報とともに、前記配送リクエストを前記物流担当の端末に送信することを特徴とする。
【００２１】
本発明の第１１の観点は、第１ないし第１０の観点において、前記配送先データベースに記憶されている内容の変更リクエストを受信する変更リクエスト受信手段と、前記変更リクエストを受信すると、予め登録された変更承認担当のアドレスに対して変更承認リクエストを送信する変更承認リクエスト送信手段と、前記変更承認リクエストに対する応答が変更承認を意味している場合に前記配送先データベースに記憶されている内容の変更を許可する変更制御手段とをさらに含むことを特徴とする。
【００２２】
なお、上記各観点に対応する方法及びコンピュータプログラムも本発明の一つである。
【発明の効果】
【００２３】
本発明によれば、故障した部品とその配送先（サプライヤーやメーカーなど）の情報とをデータベースにより管理しているため、ディーラーから故障した部品の回収を要請されると、その故障部品の配送先がデータベースによって特定され、さらに物流担当（物流業者や配送担当部門）に配送依頼がなされる。よって、メーカー等の検証が不要な故障部品を、ディーラーからサプライヤーへ直接的に配送することが可能となる。また、回収スケジュールなどの回収情報がメーカーやサプライヤーなどに通知されるため、故障した部品の配送状況等をメーカーが監視することも可能となり、従来よりも配送コスト及び配送に要していた時間を節約できる。さらに、物流担当が故障部品の配送を完了すると、配送完了がメーカーの品質保証部門やサプライヤーなどの検証担当に報告されるため、検証作業への取り掛かりまでの時間が短縮されよう。
【００２４】
また、同一の部品であってもその故障内容に依存してサプライヤー等が検証すべき場合や、メーカー等が検証すべき場合がある。そこで、故障内容に応じて配送先を変更することにより、より一層、故障部品の配送効率が向上しよう。
【００２５】
また、故障した部品の種類や故障内容によっては、メーカーの品質保証部門だけでなく、メーカーの設計部門やサプライヤーなど、複数の検証担当が検証を行なう場合もある。そこで、同一の故障部品についても複数の配送先を指定できるようにした。また、配送先が複数ある場合は、配送の順序や配送の優先順位を指定できるようにした。例えば、メーカー優先と指定されている場合は、メーカーを最初の配送先に設定できる。例えば、時間優先と指定されている場合は、ディーラーから最短の時間で配送できる配送先に配送することができる。例えば、コスト優先と指定されている場合は、最も配送コストを節約できるルートを使用して故障部品を配送することができる。
【００２６】
また、複数の配送先のうち、所定の配送順序では配送の効率が悪い場合もある。例えば、優先順位の高い配送先の都合が悪い場合には、配送順序を変更したほうが故障部品を円滑に回送できよう。そこで、複数の配送先に故障部品を配送について承諾を問合せ、承諾できない場合は配送順序を変更することで、配送の効率が向上しよう。
【００２７】
また、部品によっては故障の原因が十分に解明されており、さらなる検証は不要な場合もあろう。そのような部品が故障のたびに配送されたのでは配送コストが無駄にかさむ。そこで、データベースに回収不要の旨を登録しておき、ディーラーから回収のリクエストを受け付けたときに当該データベースを参照し、回収不要な部品であれば、その旨をディーラーに告げるようにした。これにより、無駄な配送を抑制できよう。
【００２８】
なお、ディーラーが回収不要の理由や故障の原因を知りたい場合も予想される。そこで、回収不要となった理由や故障の原因等を通知することで、ディーラーや整備の担当者の疑問を解消することができよう。
【００２９】
また、故障した部品が配送先に到着した場合には、故障部品の検証担当社等に知らせることで、検証作業の取り掛かりが円滑になろう。また、メーカー、ディーラー、サプライヤー等に知らせれば、故障部品の配送状況を把握できる利点もあろう。
【００３０】
また、検証結果は、ディーラーやメーカーなど予め設定されたアドレス（例：電子メールアドレス、ＵＲＬアドレス、インスタントメッセンジャーのアドレス等）を通じて報告されるため、故障部品対策の立案に生かせるメリットがある。また、サプライヤーのみが検証した場合は、メーカーの品質保証担当部門等にも検証結果を送付することも可能なため、故障の原因等をメーカーも把握できるようになる。
【００３１】
また、物流担当に配送リクエストを送信する際に、メーカー等の承認担当の承認を得るようにした。例えば、故障部品や故障内容によっては通常の検証手順では、十分でない場合も考えられる。故障内容が従来は報告されていなかったような特殊な場合の如くである。そこで、このような場合にも対象可能とすべく、メーカー等の承認を得てから配送リクエストを送信できるようにした。また、必要であれば承認担当等が配送順序や配送先等を変更できるようにした。例えば、データベースのデフォルト設定では、サプライヤーに直接配送されることになっていたが、故障内容が重大である場合は、メーカーにて一次検証を実行してからサプライヤーに回送することが望ましいだろう。本発明では、このように配送順序について柔軟性を確保できる。
【００３２】
また、故障部品の大きさや質量等のデータをデータベースにより管理し、故障部品の配送リクエストを送信する際に当該データも添付するようにしたので、物流担当は、配送者の手配や配送料金の算出の手間を軽減できる。
【００３３】
配送先を管理するデータベースをサプライヤー等が変更する際には、メーカーの承認を受けた上で変更できるようにした。例えば、メーカーを１次の配送先とし、サプライヤーを２次の配送先とデータベースに設定されている場合に、サプライヤーが勝手にサプライヤーを１次の配送先に変更できてしまうと、メーカーが故障の把握についてのイニシアチブを損ないかねない。そこで、メーカーの承認を必要とすることで、メーカーが関知しないところで故障部品の処理がなされてしまうことを防止できよう。
【００３４】
このように本発明では、メーカーなどを経由することなく適切な配送場所へと迅速かつ確実に故障部品を配送できるようになろう。
【発明を実施するための最良の形態】
【００３５】
以下では、当業者が上記発明を実施する際に参考となると思われるいくつかの実施形態を示す。もちろん以下の実施形態は、上位概念として開示された本発明の下位概念にすぎない。
【００３６】
なお、以下の実施形態に記載する下位概念の発明について、そのすべてが特許請求の範囲に記載されているとは限らない。ただし、これは特許発明の技術的範囲から意識的に除外したのではなく、特許発明と均等の関係にあるため、あえて特許請求の範囲には記載していない場合がある。
【００３７】
図１は、本実施形態に係る故障部品の配送管理システムの全体像を示した図である。従来は、ディーラーから回収された部品は必ずメーカーを経由していたが、本実施形態では、部品の特性や故障に応じて適切な配送先へと配送させるものである。例えば、メーカーによる一次検証が不要な故障部品については、直接、サプライヤーへと配送できるため、配送処理の効率が改善されよう。
【００３８】
ディーラーには、故障した部品の回収リクエストを送信するためのコンピュータ端末１００が備えられている。メーカーには、配送先の登録・変更の承認、配送の承認、部品回収情報の受信及び表示、部品到着情報の受信及び表示、並びに検証結果の表示など、これらの少なくとも一つの処理を実行するコンピュータ端末１１０が備えられている。サプライヤーには、配送先の設定、配送の承諾、部品回収情報の受信及び表示、部品到着情報の受信及び表示、並びに検証結果の入力などの少なくとも一つを実行するためのコンピュータ端末１２０が備えられている。物流業者には、故障した部品に関する配送リクエストの受信・表示等を実行するコンピュータ端末１３０が備えられている。なお、これらのコンピュータ端末は、１台である必要はなく同様のものが複数設置されていてもよい。あるいは、デスクトップコンピュータ、モバイルコンピュータ及び専用端末など種類の異なるコンピュータが１以上設置されていてもよい。もちろん、これらの端末は、専用端末であってもよいが、本実施形態にかかるコンピュータプログラムを実行可能な一般的なコンピュータ端末であってもよいことはいうまでもない。
【００３９】
配送管理サーバ１０１は、上述の各コンピュータ端末とネットワーク（例：インターネットや専用回線など）を介して接続されており、配送の管理処理を実行するコンピュータである。配送管理サーバ１０１は、さらに、自動車部品ごとに当該自動車部品が故障したときの配送先の情報を記憶した配送先設定データベース１０２と、部品の識別情報を記憶した部品データベース１０３と、故障原因を記憶した故障原因データベース１０４と、回収対象の部品に関する各種情報を記憶した回収部品データベース１０５と、故障コードを管理するための故障コードデータベース１０６と、関連企業及び関連部門の住所情報を管理する住所データベース１０７と接続されている。
【００４０】
また、上記各コンピュータ端末及びサーバは、ＲＯＭやハードディスクドライブに格納されているコンピュータプログラムに基づいて様々な処理及び制御を実行する中央演算処理装置（ＣＰＵ）を備えている。制御プログラムとしては、後述するフローチャートにそって適宜の処理を実行する、例えば、ＷＥＢサーバプログラム、ＣＧＩプログラム、電子メールサーバプログラム、ＷＥＢクライアント（いわゆるブラウザ）プログラム、電子メールクライアントプログラム及び種々のスクリプトなどがある。一時的なデータはＲＡＭに格納される。表示装置も備えられており、処理内容、処理結果などを表示する。また、タッチパネルデバイスやテンキー及びポインティングデバイスなどの入力装置も備えられている。またＣＰＵは、通信インタフェース回路を介して他の装置と以下のようなデータの送受信を行なう。
【００４１】
図２は、本実施形態に係る配送先データベースの例示的なデータ構造を示した図である。当該データベース１０２には、例えば、車種を表すデータ、各部品を識別するための部品番号、各故障を識別するための故障コード、回収が必要な部品か不要な部品化を表す回収要否データ、故障原因（コードなど）を表す故障原因データ、配送先の企業コード等を表す配送先データ、故障部品に関する情報を必要としている設計部門や検証担当部門等の連絡先データ、検証結果の報告先（メーカーの品質保証部門等）を表す報告先データ、配送リクエストを送信する際に事前の承認が必要か否かを表す配送承認データ、及び複数の配送先が登録されている場合に、その配送の順序や優先順位などに関連する優先条件データなどが含まれている。
【００４２】
図３は、本実施形態に係る部品データベースの例示的なデータ構造を示した図である。当該データベース１０３には、例えば、車種を表すデータ、各部品を識別するための部品番号、部品の名称データ、一以上の故障コード、部品の外形サイズを表す大きさデータ、及び部品の重量を表す重量データなどが含まれている。
【００４３】
図４は、本実施形態に係る故障原因データベースの例示的なデータ構造を示した図である。当該データベース１０４には、例えば、故障の原因を識別するための原因コード、及び各原因コードに対応する詳細な情報などが含まれている。
【００４４】
図５は、本実施形態に係る回収部品データベースの例示的なデータ構造を示した図である。当該データベース１０５には、例えば、回収リクエストごとに発行されるＩＤ、車種を表すデータ、各部品を識別するための部品番号、各故障を識別するための故障コード、ディーラーなどの配送元に故障部品を引き取り（回収）に行く日を表す回収日データ、故障部品が指定された配送先に到着する日を表す到着日データ、配送先の企業コード等を表す配送先データ、連絡先データ、検証結果の報告先（アドレスなど）を表す報告先データ、検証結果の入力者又検証者などを表す入力者データ、検証の実行された日時を検証日時データ、及び検証結果を表す検証結果データなどが含まれる。また、ディーラーにおいて故障した部品に関連する修理を行なった日又は修理予定の日のデータが含まれていてもよい。
【００４５】
図６は、本実施形態に係る故障コードデータベースの例示的なデータ構造を示した図である。当該データベース１０６には、例えば、各故障を識別するための故障コード、故障部品を指定の配送先に配送する際に所定の者（例：メーカーの担当者など）の承認が必要か否かを表す配送承認データ、及び配送承認データ条件付で承認を要求するとの内容であった場合に、その条件を表す条件データなどが含まれている。
【００４６】
図７は、本実施形態に係る住所データベースの例示的なデータ構造を示した図である。当該データベース１０７には、例えば、各関連企業の企業ＩＤ、企業名称のデータ、企業の住所データ、電話番号データなどが含まれている。
【００４７】
図８は、本実施形態に係る配送先に関連するデータの設定処理を示したフローチャートである。ここでは、故障部品の配送先を設定するのであるが、故障部品の検証を担当するサプライヤーやメーカーの品質保証部門だけでなく、検証するわけではないが故障部品を一度見てみたいと考えている設計部門等の他の部門なども自ら配送先として設定できる。また、配送は不要であるが、近くの検証担当部門に故障部品が配送された場合には、自ら足を運んでその故障部品を見てみたいと考える開発者や研究者も存在する。その場合は、連絡先の項目に自己の企業コード、部門コード又は電子メールアドレス等を登録しておくことで、故障部品の到着情報を得ることができる。
【００４８】
ステップＳ８００において、サプライヤー端末１２０のＣＰＵは、キーボード等の入力装置から配送先設定処理の起動を指示されると、配送管理サーバ１０１に設定処理の開始要求を送信する。例えば、本システムをＷＥＢベースで構築する場合は、配送管理サーバ１０１のＵＲＬを入力することになろう。
【００４９】
ステップＳ８０２において、サーバ１０１のＣＰＵは、サプライヤーの端末１２０からの開始要求を受信すると、配送先設定用の画面情報を作成する。
【００５０】
図９は、本実施形態に係る配送先設定画面の一例を示す図である。サーバ１０１は、予めハードディスクドライブ等に格納された雛型ファイルをオープンし、サプライヤー端末１２０の操作者の名称など、各設定者ごとにカスタマイズすべき情報を書き込むことで、画面情報を作成することができる。操作者の名称等は、例えば、サーバ１０１へのログイン時に使用されたＩＤ又は当該ＩＤに対応する名称データをデータベースから読み出して設定してもよい。なお、画面情報としては、ＨＴＭＬファイル、ＸＭＬファイル及びＪａｖａ（登録商標）スクリプトなどを用いて実現することができる。
【００５１】
ステップＳ８０４において、サプライヤーの端末１２０のＣＰＵは、受信した画面情報を表示装置に出力する。たとえば、ＷＥＢブラウザによって画面情報を表示データに変換して表示する。サプライヤー端末１２０のＣＰＵは、入力装置から入力される指示に応じて車種データ等を入力する。例えば、車種データを入力するときは、車種の欄の横に表示された「参照」ボタンを押して、車種リストが表示され、ポインティングデバイス等により何れか一つの車種を選択すると車種データの欄に車種コードが設定される。これは、ＨＴＭＬの技術である＜ＳＥＬＥＣＴ＞エレメントを使用すれば最も簡単に実現できよう。車種などのリストデータも画面情報とともに受信したものである。部品番号や配送先などの他のデータについても同様の手順で入力することができる。ここでいう配送先とは、部品が故障したときに当該部品をディーラーから引き取る部門を意味する。通常は、部品を製造したサプライヤーが配送先となろう。
【００５２】
ステップＳ８０８において、サプライヤー端末１２０のＣＰＵは、ポインティングデバイス等から設定の変更要求（例えば、図９のＯＫボタンなど）が押されたことを検出すると、入力された車種データや部品番号データとともに設定の変更要求をサーバ１０１に送信する。
【００５３】
ステップＳ８１０において、サーバ１０１は、通信インタフェースを介して設定変更要求を受信すると、設定変更要求に伴って受信された車種データ、部品番号データ、故障コード及びなどを検索キーとして配送先設定データベース１０２を検索し、対応するレコードを抽出し、ＲＡＭに保存する。図９の例で説明すると、車種：０１５１、部品番号：１２３４及び故障コード：０１２であったとすると、最も上のレコードが抽出される。そして、ＣＰＵは、次に受信した配送先のデータを用いてレコードの内容を書き換える。最後に、書き換えたレコードに基づいて設定変更承認画面を作成する。
【００５４】
ステップＳ８１２において、サーバ１０１のＣＰＵは、作成した承認画面の情報を承認要求とともに、予め定められた端末（この例ではメーカーの端未１１０）に送信する。設定変更画面へアクセスするためのＵＲＬを記入した電子メールが送信されてもよい。また、インスタントメッセ−ジャーによってリアルタイムで承認要求を送信してもよい。なお、承認要求は即時性が要求されるためインスタントメッセンジャーで承認要求を送信することが望ましいだろう。
【００５５】
ステップＳ８１４において、メーカーの端末１１０は、承認要求と設定変更承認画面を受信し、表示装置に表示させる。
【００５６】
図１０は、本実施形態に係る設定変更承認画面の一例を示す図である。このようにして表示された変更後のレコードの内容に問題がなければ、承認ボタンが押され、承認済みを表す承認応答がサーバ１０１に送信される。一方、承認担当者が一部の情報を変更する場合は、参照ボタン又はテキストの直接入力によってデータが変更される。
【００５７】
ステップＳ８１６において、メーカーの端末１１０のＣＰＵは、変更ボタンの押し下げを検出すると、変更後の内容を承認応答として送信する。
【００５８】
ステップＳ８１８において、サーバ１０１は、変更承認後のレコードの内容を配送先設定データベース１０２に登録する。
【００５９】
ステップＳ８２０において、サーバ１０１は、変更承認後のレコードの内容を含む変更完了通知をサプライヤーの端末１２０に送信する。また、設定変更完了通知へアクセスするためのＵＲＬを記入した電子メールが送信されてもよい。また、インスタントメッセ−ジャーによってリアルタイムで完了通知を送信してもよい。以上の手順により、各部品ごとの配送先がデータベース１０２上に登録される。また、同様の手順により、連絡先や報告先を登録できることはいうまでもない。
【００６０】
図１１は、本実施形態に係る故障部品回収処理の例示的なフローチャートである。図１１を用いてディーラーにおいて故障部品の回収を要求し、その要求が回収部品データベース１０５に登録されるまでを説明する。
【００６１】
ステップＳ１１００において、ディーラー端末１００のＣＰＵは、キーボード等から部品回収リクエスト用のＵＲＬが入力されると、当該入力されたＵＲＬに従いサーバ１０１へと回収設定画面要求を送信する。
【００６２】
ステップＳ１１０２において、サーバ１０１のＣＰＵは当該要求を受信すると、回収設定画面の雛形ファイル（例えば、ＨＴＭＬファイルや画像ファイルなど）をハードディスクドライブから読み出し、回収設定画面の情報を作成し、ディーラー端末１１０に送信する。
【００６３】
図１２は、本実施形態に係る回収設定画面の一例を示す図である。回収依頼者の欄には、各ディーラーの名称データが反映されているが、例えば、サーバ１０１へのログイン時のＩＤ等に基づいて設定されたものである。
【００６４】
ステップＳ１１０４において、端末１００のＣＰＵは、通信インタフェース介して回収設定画面情報を受信し、ＷＥＢブラウザを使用して表示装置に表示する。端末１００のＣＰＵは、入力装置からの指示に従って、車種データ、部品番号データ及び故障コードをＲＡＭに記憶する。
【００６５】
ステップＳ１１０６において、端末１００のＣＰＵは、ＯＫボタン（例えば、ＨＴＭＬのフォームエレメントにおけるＳｕｂｍｉｔボタンに相当する。）の押し下げを検出すると、ＲＡＭから車種データ等を読み出して、読み出されたデータを伴う登録要求をサーバ１０１に送信する。
【００６６】
ステップＳ１１０８において、サーバ１０１のＣＰＵは、登録要求とともに車種データ等を受信すると、対応するレコードを配送先データベース１０２から読出し、ＲＡＭに記憶する。図２に示した例のように、この中には、回収が必要な部品か、または不要な部品かを表す情報も含まれていてもよい。
【００６７】
ステップＳ１１１０において、サーバ１０１のＣＰＵは、ＲＡＭから回収要否データを読出し、読み出された回収要否が「回収要」であるかどうかを判定する。「回収要」であればステップＳ１１１４に進む。
【００６８】
一方、回収不要であれば、ステップＳ１１１２に進み、ＲＡＭに記憶されている対応レコードから故障原因コードを読出す。さらに、読み出されたコードに対応する故障原因の詳細情報を、故障原因データベース１０４から検索抽出する。そして、回収不要情報を作成し、ディーラーの端末１００に送信する。
【００６９】
図１３は、本実施形態に係る回収不要情報の一例を示す図である。当該図面によれば、回収要求にともなう部品データとともに、回収不要であること及び詳細な故障原因が表示されることになる。これにより、ディーラー等は回収が不要であることを把握でき、さらにその理由までも知ることができるので、今後、同様の故障が発生した場合にも対応しやすくなろう。
【００７０】
ステップＳ１１１４において、サーバ１０１のＣＰＵは、ＲＡＭに記憶しておいた対応レコードから、配送先、連絡先及び報告先のデータを読み出す。これらのデータは、企業コードであってもよいし、ＵＲＬ、ＩＰアドレス、電子メールアドレスなどであってもよい。
【００７１】
ステップＳ１１１６において、配送先が複数設定されていると判定すると、サーバ１０１のＣＰＵは、さらに、対応レコード配送優先データを読出し、当該配送優先データにしたがって、配送順序を決定する。たとえば、配送順序が「メーカー優先」となっていれば、メーカーを最初の配送先として設定する。また、「コスト優先」となっていれば、ディーラーの住所データと各配送先の住所データを住所データベース１０７から読出し、コストが再安となるように配送順序を設定する。例えば、各拠点間の配送コストを予めデータベース化しておけば、この内容をＣＰＵが参照することで容易に最安の配送順序を決定できよう。「時間優先」の場合は、最短で効率よく配送できる配送順序を決定する。この場合も、各拠点間の標準所要時間をデータベース化しておくことで容易に決定できよう。
【００７２】
ステップＳ１１１８において、サーバ１０１のＣＰＵは、決定された配送先の確認画面を作成する。確認画面の情報も上述と同様にＷＥＢベースで作成することができる。
【００７３】
ステップＳ１１２０において、サーバ１０１は、確認画面情報をディーラー端末１００に送信する。なお、確認画面へとアクセスするためのＵＲＬを含んだ電子メールやインスタントメッセージを送信してもよい。ステップＳ１１２２において、端末１１０のＣＰＵは、ＷＥＢブラウザを使用して確認画面情報を表示装置に表示する。
【００７４】
図１４は、本実施形態に係る配送確認画面の一例を示している。この図によれば、回収要求ごとの識別番号（これはサーバ１０１のＣＰＵが回収登録要求を受信した時に発行したもの）、車種データ、部品番号、故障コードとともに、回収日時や修理日（予定日でも可）及び所定のコメントなどが表示される。なお、回収日時や修理日等はこの段階で端未１００から入力してもよい。
【００７５】
ステップＳ１１２４において、端末１００のＣＰＵは、回収依頼ボタンの押し下げを検出すると、入力された回収日時等のデータとともに回収依頼情報をサーバ１０１に送信する。
ステップＳ１１２６において、サーバ１０１のＣＰＵは受信した回収日時データ等を含む回収レコード（図５）作成し、回収部品データベース１０５に書き込む。回収レコードは、ディーラーから受信した情報と、予め配送先データベース１０２から読み出したデータ等に基づいて作成される。
【００７６】
図１５は、本実施形態に係る配送処理の例示的なフローチャートである。図１５を用いて、配送の承認処理から故障部品の到着通知処理までを説明する。
【００７７】
ステップＳ１５００において、サーバ１０１のＣＰＵは、回収部品データベース１０５へと新規に登録されたレコードを読出し、さらに読み出されたレコードに含まれていた車種データ、部品番号及び故障コードに基づいて配送先データベース１０２から配送承認の要否データを読み出す。配送の開始前に事前にメーカー等の予め定められた者の承認が必要とデータベース１０２に登録されていれば、ステップＳ１５０２へと進み、そうでなければ、ステップＳ１５０８に進む。
【００７８】
ステップＳ１５０２において、ＣＰＵは、回収部品データベース１０５に対応レコードに基づいて配送承認画面の情報を作成し、配送承認要求としてメーカー端末１１０に送信する。ステップＳ１５０４において、メーカー端末１１０のＣＰＵは、配送承認要求を受信すると、ＷＥＢブラウザを用いて配送承認画面を表示装置に出力する。
【００７９】
図１６は、本実施形態に係る配送承認画面の一例を示す図である。図によれば、いずれも回収部品データベース１０５から読み出されたデータが列挙されている。なお、図５によれば回収依頼者のデータがデータベースに記載されていないが、これは省略されているに過ぎない。この配送承認画面に表示された内容に同意するのであれば、承認ボタンが押し下げられる。なお、配送先、連絡先、報告先、配送順序、配送の優先規則等を変更できるようにしてもよい。ここで変更された内容は、サーバ１０１に送信され、回収部品データベース１０５に記憶される。
【００８０】
ステップＳ１５０６において、メーカー端末１１０のＣＰＵは、承認ボタンの押し下げを検出すると、配送承認情報をサーバ１０１に送信する。
【００８１】
ステップＳ１５０８において、サーバ１０１は、各配送先の配送承諾が必要か否かを判定する。例えば、配送承諾の要否が、配送先設定データベース１０２に登録されている場合は、その内容を参照して要否を判定する。要であれば、ステップＳ１５１０に進み、不要であれば、ステップＳ１５１６に進む。
【００８２】
ステップＳ１５１０において、サーバ１０１のＣＰＵは、回収部品データベースに登録されている各配送先に対して、配送の承諾要求を送信する。配送の承諾要求には、配送対象の部品番号、故障コード、回収日（又は回収日から求めた配送予定日）など、回収部品データベースに登録されているデータが含まれている。
【００８３】
ステップＳ１５１２において、配送先として指定されたサプライヤーの端末１２０は、承諾要求を受信すると、配送内容を表示装置に出力する。ステップＳ１５１４において、ＣＰＵは、もし配送予定日や配送順序が配送先の都合に合わなければ、配送順序の変更要求（例えば、希望の配送順序に関する情報を含む。）をサーバ１０１に送信する。サーバ１０１は、希望の配送順序について、配送承認処理（Ｓ１５０２ないしＳ１５０６）を実行する。
【００８４】
ステップＳ１５１６において、サーバ１０１は、物流担当の端末１３０に対し、配送依頼情報を作成し、送信する。例えば、サーバ１０１は、配送対象となっている故障部品の大きさ、重量に関するデータを部品データベースから読み出すとともに、回収依頼者の企業コードと、配送先の企業コードとからそれぞれの住所及び電話番号等の配送に必要な情報を住所データベースから読出し、これらの読み出された情報を含む配送依頼情報を作成する。物流担当の端末１３０は、配送依頼情報を受信すると、表示装置又は印刷装置等から出力する。物流担当端末１３０は、配送依頼情報に基づいて配送元（故障部品を発送するディーラー）に故障部品を引き取りに行く日（発送日）と、配送先へ配達する日（到着日）を決定し、発送日と到着日の情報をサーバ１０１に送信する。サーバ１０１は、これらの日付データを、回収部品データベース１０５内の対応するレコードに記憶する。
【００８５】
ステップＳ１５１８において、サーバ１０１のＣＰＵは、回収部品データベース１０５から回収対象部品のレコードを読出し、当該レコードの内容を反映した最新の回収情報を作成する。
【００８６】
図１７は、本実施形態に係る回収情報の一例を示す図である。例えば、回収情報には、回収依頼者、回収ＩＤ、部品番号、故障コード、各配送先ごとの集配日などが含まれている。これによって、メーカーやサプライヤー等の配送先は、それぞれ配送品の受け入れ準備を整えることができ、また、メーカーを経由せず直接的にサプライヤーに配送される場合もメーカーが故障部品の発生と配送を把握することができる。
【００８７】
ステップＳ１５２０及びＳ１５２２において、サーバ１０１は、回収情報を、連絡先、報告先、配送先等の予め定められたアドレスに送信する。回収情報は、例えば、電子メールにて送信することもできるし、サーバ１０１の回収情報のページに所定の端末がアクセスしてきたときにＷＥＢ情報として送信してもよい。そして、ステップＳ１５２４及びＳ１５２６において、回収情報を受信した端末は、表示装置や印刷装置から出力する。
【００８８】
ステップＳ１５２８において、物流担当の端末１３０から配送の完了などを表す配達情報を送信する。ステップＳ１５３０において、サーバ１０１は、受信した配達情報と、回収部品データベース１０５から読み出した対象部品の部品番号等を含む部品到着情報を作成する。ステップＳ１５３２及びＳ１５３４においてサーバ１０１は、連絡先、配送先、報告先等の予め定められたアドレスに対し、部品到着情報を送信する。ステップＳ１５３６及びＳ１５３８において、各端末において部品到着情報が出力される。
【００８９】
図１８は、本実施形態に係る部品到着情報の一例を示す図である。例えば、部品到着情報には、回収依頼者、回収ＩＤ、部品番号、故障コード、故障部品の到着先、次の配送先などの情報が含まれている。
【００９０】
図１９は、本実施形態に係る検証結果の登録処理に関する例示的なフローチャートである。この図を用いて検証結果の入力から表示までを説明する。この例では、サプライヤーが検証担当となっている場合であるが、もちろんメーカーの品質保証部門が検証担当であってもよい。後者の場合も同様に本発明を適用できることはいうまでもない。
【００９１】
ステップＳ１９００において、サプライヤー端末１２０は、検証結果を入力するための入力要求をサーバ１０１に送信する。入力要求は、例えば、入力ページのＵＲＬなどを含んでいる。なお、故障部品の送付票に予め当該ＵＲＬを記載しておけば、検証入力がしやすくなろう。また、アクセス先の情報をバーコード化して送付票に印刷しておき、端末１２０のバーコードリーダーで読み出して、それをＵＲＬに変換してサーバ１０１にアクセスしてもよい。
【００９２】
ステップＳ１９０２において、サーバ１０１は、入力画面の情報（例えば、ＨＴＭＬファイルなど）を生成する。ステップＳ１９０４において、サーバ１０１は、作成した入力画面情報を端末１２０に送信する。
【００９３】
ステップＳ１９０６において、端末１２０は、入力画面情報を受信し、表示装置に表示する。図２０は、本実施形態に係る検証結果の入力画面の一例を示す図である。この図によれば、回収ＩＤ、車種ＩＤ、部品番号、故障コード、回収日時、故障原因、詳細な検証結果等が含まれおり、それぞれ端末１２０において入力される。あるいは、入力要求の際に故障部品に添付されていたか回収ＩＤをサーバ１０１に送信することで、回収部品データベースから必要なデータを読み出して入力画面を作成してもよい。また、次の配送先をこの時点で登録してもよい。その場合は、ＧＯボタンを押すことで、配送先を選択する画面を呼び出して次の配送先を指定する。なお、今後、検証は不要（すなわち回収も不要）と考える場合は、回収不要の登録要求もサーバ１０１に送信してもよい。この場合は、配送先データベース１０２の内容がサーバ１０１によって更新されよう。
【００９４】
また、検証結果は、テキストのみである必要はなく、音声情報、画像情報及び動画情報の少なくとも一つが含まれていもよい。これは、今後の故障対象に役立つ情報であるため、添付されることが望ましいかもしれない。
【００９５】
ステップＳ１９０８において、端末１２０のＣＰＵは、検証結果の入力完了ボタンの押し下げを検出すると、故障原因や検証結果等を含む登録要求をサーバ１０１に送信する。
【００９６】
ステップＳ１９１０において、サーバ１０１は、受信した登録要求に含まれている回収ＩＤを検索キーとして、対応するレコードを回収部品データベース１０５から検索抽出し、受信した検証結果等の情報をレコードに反映させて再びデータベースに書き込む。ステップＳ１９１２において、サーバ１０１は、変更後のレコードに基づいて検証結果情報を作成する。図２１は、本実施形態に係る検証結果の表示画面の一例を示す図である。検証結果の表示画面には、回収部品データベースに登録された部品番号、故障コード、故障原因、及び検証結果などが含まれている。
【００９７】
ステップＳ１９１４及びＳ１９１８において、サーバ１０１は、予め定められた報告先に対して検証結果の表示画面情報を送信する。さらに、ステップＳ１９１６及びＳ１９２０において、当該情報を受信した各端末は、検証結果の表示画面情報を出力する。なお、検証結果は、電子メールアドレスに対して送信してもよい。
【００９８】
ところで、サーバ１０１は、回収部品データベース１０５の到着日時と検証日時とを適宜のタイミングで読出し、到着日時から所定日時を経過しても検証日時が入力されていない場合には、配送先（検証担当）に対して検証を促す電子メール等を送信してもよい。
【００９９】
また、サーバ１０１が、各故障部品についての統計的な発生状況に関するデータベースを作成している場合は、配送先の設定画面（図９）、配送先変更の承認画面（図１０）または配送承認画面（図１６）等に当該発生状況の参照ボタンを設けることで、過去の発生状況についての統計資料（表やグラフ）などを表示できるようにしてもよい。あるいは、サーバ１０１が、ある回収リクエストを受信すると、関連する過去の発生状況をデータベースから読出し、所定期間内における発生頻度がしきい値を超えているかどうかを判定し（例えば、１ヶ月に１０件以上発生しているなど）、しきい値を超えていれば、案内情報のウインドウ内に警告を促すようなメッセージを表示するようにしてもよい。このようにすることで、特定の部品についての特定の故障の発生頻度が高ければ、それに応じて配送先等を変更することもできよう。
【０１００】
さらに、サーバ１０１は、各回収ＩＤごとに、現在の故障部品の所持部署と所持期間（配送完了日からの経過日）を回収部品データベース１０５に記憶してもよい。例えば、所持期間が所定の期間より長くなれば、故障の検証が遅いとしてサーバ１０１が警告情報を送信することもできよう。このようにすれば故障部品の停滞を防止できる利点があろう。
【０１０１】
上述の実施形態では、ＷＥＢベースで本発明を実施する場合を説明したが、一部又は全部において電子メール、ファクシミリ及び独自の通信プロトコルなどＷＥＢベース以外の技術を用いて実現してもよい。また、ネットワークは、インターネットである必要はなく、専用線を用いたクローズされたネットワークであってもよいし、双方を適宜に組み合わせてもよい。
【０１０２】
また、上述の実施形態における各ステップのうち順番を変えたとしても結果に影響がないものは適宜入れ替えてもよいことは明らかであろう。すなわち、これらステップを入れ替えたフローについても本願において実質的に開示されているといえよう。
【図面の簡単な説明】
【０１０３】
【図１】図１は、本実施形態に係る故障部品の配送管理システムの全体像を示した図である。
【図２】図２は、本実施形態に係る配送先データベースの例示的なデータ構造を示した図である。
【図３】図３は、本実施形態に係る部品データベースの例示的なデータ構造を示した図である。
【図４】図４は、本実施形態に係る故障原因データベースの例示的なデータ構造を示した図である。
【図５】図５は、本実施形態に係る回収部品データベースの例示的なデータ構造を示した図である。
【図６】図６は、本実施形態に係る故障コードデータベースの例示的なデータ構造を示した図である。
【図７】図７は、本実施形態に係る住所データベースの例示的なデータ構造を示した図である。
【図８】図８は、本実施形態に係る配送先に関連するデータの設定処理を示したフローチャートである。
【図９】図９は、本実施形態に係る配送先設定画面の一例を示す図である。
【図１０】図１０は、本実施形態に係る設定変更承認画面の一例を示す図である。
【図１１】図１１は、本実施形態に係る故障部品回収処理の例示的なフローチャートである。
【図１２】図１２は、本実施形態に係る回収設定画面の一例を示す図である。
【図１３】図１３は、本実施形態に係る回収不要情報の一例を示す図である。
【図１４】図１４は、本実施形態に係る配送確認画面の一例を示している。
【図１５】図１５は、本実施形態に係る配送処理の例示的なフローチャートである。
【図１６】図１６は、本実施形態に係る配送承認画面の一例を示す図である。
【図１７】図１７は、本実施形態に係る回収情報の一例を示す図である。
【図１８】図１８は、本実施形態に係る部品到着情報の一例を示す図である。
【図１９】図１９は、本実施形態に係る検証結果の登録処理に関する例示的なフローチャートである。
【図２０】図２０は、本実施形態に係る検証結果の入力画面の一例を示す図である。
【図２１】図２１は、本実施形態に係る検証結果の表示画面の一例を示す図である。
【図１】
2005138987.tif 000003
【図２】
2005138987.tif 000004
【図３】
2005138987.tif 000005
【図４】
2005138987.tif 000006
【図５】
2005138987.tif 000007
【図６】
2005138987.tif 000008
【図７】
2005138987.tif 000009
【図８】
2005138987.tif 000010
【図９】
2005138987.tif 000011
【図１０】
2005138987.tif 000012
【図１１】
2005138987.tif 000013
【図１２】
2005138987.tif 000014
【図１３】
2005138987.tif 000015
【図１４】
2005138987.tif 000016
【図１５】
2005138987.tif 000017
【図１６】
2005138987.tif 000018
【図１７】
2005138987.tif 000019
【図１８】
2005138987.tif 000020
【図１９】
2005138987.tif 000021
【図２０】
2005138987.tif 000022
【図２１】
2005138987.tif 000023