JP2005141574A - 配送管理システム - Google Patents

Abstract

【課題】 故障部品を検証する際に、故障部品を効率よく配送する。
【解決手段】 自動車販売会社の端末１００から配送管理サーバ１０１に、故障した自動車部品の回収リクエストを送信する。関連部署データベース１０２は、自動車部品が故障したときの関連部署の情報を記憶している。サーバ１０１は、受信した回収リクエストに含まれる故障部品の部品番号に対応する関連部署の情報を検索抽出する。さらに、サーバ１０１は、関連部署に故障部品の案内情報を送信する。案内情報対して故障部品の配送を希望する旨の回答を送信してきた関連部署を配送先として決定する。この配送先の情報に従って配送リクエストを物流担当の端末１３０に送信する。サーバ１０１は、故障部品の検証をメーカーが担当しない場合にも、故障部品やその配送スケジュール及び検証結果等の情報をメーカーに報告する。
【選択図】 図１

Description

本発明は、故障した自動車部品の回収処理及び検証処理において有用な配送管理システムに関する。

自動車部品は、非常に多くの種類及び形式が存在するため、全ての補修部品をサプライヤーの各販売拠点に保管しておくことは困難であった。特許文献１に記載の技術によれば、サプライヤー販売拠点の限られたスペースに適切な種類と適切な数の補修用部品を保管し、顧客の注文に対して販売拠点からの即時納入比率を向上させた在庫管理システムを検討している。
特開２００２−３４２４３１号。

ところで、一般に自動車産業界においては、部品メーカー（サプライヤー）が自動車メーカーに自動車の各部品を供給し、自動車メーカーが各部品を組み立てて自動車を完成させ、最後に自動車販売会社（ディーラー）が各ユーザーに完成した自動車を販売するといった取引形態が確立されている。とりわけ、ユーザーはディーラーとの関係が密接であるため、仮に自動車の任意の部品が故障すると、ユーザーがディーラーに自動車や当該故障部品を持ち込み、修理を依頼することになる。

故障した部品については、その原因を分析・検証し、必要であれば部品を改良することも考えられる。

そのため、ディーラーは、故障部品の回収をメーカーに依頼し、メーカーが当該故障部品を回収して、故障の原因を検証し、故障対策の確立や、部品の改善などを実行する。これらの作業は一般にメーカーの品質保証部門が担当することになるが、部品の種類によっては、メーカーで一次検証作業を実行し、その後で、サプライヤーが故障原因についての二次検証を担当することも多い。

ときには、メーカーで一次検証を行なうことのできないような故障部品もあるが、従来は、そのような場合にも必ずメーカーの品質保証部門に故障部品が配送され、その後で、サプライヤーへと故障部品が回送されていた。

このように、メーカーにおける一次検証が不要な場合は、ディーラーから直接的にサプライヤーへと故障部品を配送できれば、コスト的にも時間的にも効率が改善されよう。例えば、メーカーが広島にあり、ディーラーが北海道にあり、そしてサプライヤーが関東にあると仮定すると、本来は、北海道から関東のサプライヤーへと故障部品を配送すればよい。しかしながら、従来は、故障部品が北海道のディーラーから広島のメーカーへと配送され、そして広島から関東のサプライヤーに配送されていたため、コスト的にも時間的にも無駄が多かった。

ところが、ディーラーは、サプライヤーと直接の取引関係がないため、どの部品がどのサプライヤーから提供されたものかを知る由もなく、ディーラーから直接的にサプライヤーへと故障部品を配送することができなかった。また、メーカーの一次検証が必要な部品なのか不要な部品なのかも把握することができなかった。

その一方で、メーカーを介さずにディーラーとサプライヤー間で故障部品の配送がなされてしまうと、メーカーは故障に関する情報を得ることができなくなり、メーカーのイニシアチブが損なわれ兼ねない。特に、自動車メーカーが故障等の情報を十分に把握できず、また何の対処もできないことになければ、顧客満足度が低下しかねない。

そこで、本発明は、故障部品の検証に伴う配送効率等を改善することを目的とする。

はじめに本発明の上位概念たる技術思想を説明する。本発明の第１の観点は、自動車販売会社から回収される故障した自動車部品の配送処理を管理する配送管理システムであって、故障した自動車部品について自動車販売会社の端末から送信される回収リクエストを受信する回収リクエスト受信手段と、前記回収リクエストが受信されると、自動車部品ごとに該自動車部品が故障したときの配送先の情報を記憶した関連部署データベースから、該回収リクエストに含まれる前記故障した自動車部品の識別情報に基づいて、該故障した自動車部品の関連部署の情報を検索抽出する検索抽出手段と、前記検索抽出された関連部署の端末に対し、前記故障した自動車部品に関する配送の希望、連絡の希望及び検証結果の希望などに代表される該関連部署の希望を問い合せるための問い合せ情報を送信する問い合せ情報送信手段と、前記関連部署の端末からそれぞれ前記問い合せ情報に対する回答情報を受信する回答情報受信手段と、前記受信した回答情報のうち配送希望を含む回答情報を送信してきた関連部署が複数ある場合に所定のルールを読み出し、該ルールに基づいて配送順序を決定する配送順序決定手段と、前記決定された配送順序、前記配送希望を送信してきた関連部署及び前記故障した部品の配送元となる自動車販売会社に関する情報を伴う配送依頼情報を物流担当の端末に送信する配送依頼送信手段とを含むことを特徴とする。また、前記故障した自動車部品の配送に関するスケジュール等の配送情報を、予め登録された第１のアドレス宛てに送信する配送情報送信手段や、前記物流担当による前記配送先となる関連部署への前記故障した自動車部品の配送が完了すると、該故障した自動車部品に関する配送完了情報を、予め登録された第２のアドレス宛てに送信する配送完了情報送信手段を適宜備えてもよい。なお、第１のアドレスと第２のアドレスとが同一のアドレスであっても異なるアドレスであってもよいことはいうまでもない。

本発明の第２の観点は、第１の観点に記載の配送管理システムにおいて、前記回収リクエストには、前記故障した自動車部品の故障内容が含まれており、前記問い合せ情報送信手段は、前記故障内容を含む問い合せ情報を送信することを特徴とする。

本発明の第３の観点は、第１の観点又は第２の観点に記載の配送管理システムにおいて、前記関連部署データベースは、故障内容と対応付けて前記関連部署の情報を記憶しており、前記検索抽出手段は、前記回収リクエストに含まれる自動車部品の識別情報及び故障内容に対応する関連部署を検索抽出することで、故障内容に応じて案内情報を送信する宛先を変更することを特徴とする。

本発明の第４の観点は、第１ないし第３の観点うち何れか１の観点に記載の配送管理システムにおいて、前記配送順序決定手段は、前記関連部署データベースに記憶されている、複数の配送先のうちどれを優先すべきかを表す優先順位情報にしたがって配送順序を決定することを特徴とする。

本発明の第５の観点は、第１ないし第４の観点うち何れか１の観点に記載の配送管理システムにおいて、前記検索抽出された各配送先のアドレスに対して、前記決定された配送順序を承諾するか否かの伺い情報を送信する伺い情報送信手段と、前記伺い情報への応答として各配送先から送信される承諾情報を受信する承諾情報受信手段と、前記受信された承諾情報に基づいて必要であれば前記配送順序を変更する配送順序変更手段とを含むことを特徴とする。

本発明の第６の観点は、第１ないし第５の観点うち何れか１の観点に記載の配送管理システムにおいて、前記関連部署データベースが、各自動車部品ごとに回収の要・不要に関する情報を記憶している場合、前記回収リクエストが受信されると、該回収リクエストに関連する自動車部品の回収の要・不要に関する情報を前記検索抽出手段により検索抽出し、該検索抽出された回収の要・不要に関する情報が回収不要を示しているか否かを判定する回収要・不要判定手段と、前記回収不要と判定された場合に、前記回収リクエストを送信してきた自動車販売会社の端末に対して回収不要を表す情報を送信する回収不要情報送信手段とをさらに含むことを特徴等する。

本発明の第７の観点は、第６の観点に記載の配送管理システムにおいて、前記回収不要の自動車部品の識別情報と対応付けて故障原因に関する情報を記憶する故障対応データベースと、回収不要と判定された場合に、前記故障対応データベースから前記故障原因に関する情報を検索抽出する故障原因検索抽出手段とをさらに備え、前記回収不要情報送信手段は、前記回収リクエストを送信してきた前記自動車会社の端末に対して前記検索抽出された故障原因に関する情報も送信することを特徴とする。

本発明の第８の観点は、第１ないし第７の観点うち何れか１の観点に記載の配送管理システムにおいて、前記第２のアドレスは、前記故障した自動車部品の見取り評価を希望する関連部署のアドレスであり、前記見取り評価の関連部署の端末から送信された回答情報において指定されていた他の関連部署に該自動車部品が到着すると、前記配送完了情報送信手段が、該第２のアドレス宛に配送完了情報を送信することを特徴とする。

本発明の第９の観点は、第１ないし第８の観点うち何れか１の観点に記載の配送管理システムにおいて、前記故障した自動車部品の検証結果の送信宛先アドレスと、該自動車部品の識別情報とを対応付けて記憶する検証担当データベースと、検証結果が入力されると、前記回収リストに関連する故障した自動車部品の識別情報に基づいて、対応する前記検証結果の送信宛先アドレスを検索抽出する検証結果アドレス検索抽出手段と、前記検索抽出された前記検証結果の送信宛先アドレスに対し、前記入力された検証結果を送信する検証結果送信手段とをさらに含むことを特徴とする。

本発明の第１０の観点は、第１ないし第９の観点うち何れか１の観点に記載の配送管理システムにおいて、前記検索抽出手段により検索抽出された関連部署について、所定期間内又は所定回数にわたり同一又は類似の回収リクエストが受信された場合であって、該関連部署が案内情報及び回答情報の省略を選択している場合は、前記案内情報の送信をスキップさせ、前回の回答情報の内容を今回も利用するよう制御する送信制御手段をさらに含むことを特徴とする。

本発明の第１１の観点は、第１ないし第１０の観点うち何れか１の観点に記載の配送管理システムにおいて、前記回答情報を送信してきた関連部署が存在しなかった場合には、前記関連部署データベースに予め登録されているデフォルトの関連部署を配送先として設定する強制設定手段ををさらに含むことを特徴とする。

本発明の第１２の観点は、第１ないし第１１の観点うち何れか１の観点に記載の配送管理システムにおいて、前記案内情報を送信してからの経過時間を計時する計時手段と、前記計時手段に従い所定の経過時間内に回答情報を送信してきた関連部署に限って前記配送順序定手段により配送順序を決定させ、一方、前記所定の経過時間から遅れて回答情報を送信してきた関連部署は前記配送順序の最後に追加するよう前記配送順序決定手段を制御する制御手段とをさらに含むことを特徴とする。

本発明の第１３の観点は、第１ないし第１２の観点うち何れか１の観点に記載の配送管理システムにおいて、前記自動車部品ごとの大きさ及び質量に関する情報を記憶した部品データベースをさらに備え、前記配送リクエスト送信手段は、配送対象となっている前記故障した自動車部品について前記部品データベースから読み出された大きさ及び質量に関する情報とともに、前記配送リクエストを前記物流担当の端末に送信することを特徴とする。

なお、上記各観点に対応する方法及びコンピュータプログラムも本発明の一つである。

本発明によれば、故障した部品とその配送先（サプライヤーやメーカーなど）の情報とをデータベースにより管理しているため、ディーラーから故障した部品の回収を要請されると、その故障部品に対応する関連部署がデータベースによって特定される。次に、特定された関連部署に故障した部品に興味があるかどうかを問い合せ、例えば、配送希望を申し出てきた関連部署があれば、物流担当（物流業者や配送担当部門）への配送依頼がなされる。よって、メーカー等の検証が不要な故障部品を、ディーラーからサプライヤーへ直接的に配送することが可能となり、従来よりも配送コスト及び配送に要していた時間を節約できる。

また、故障した部品の種類や故障内容によっては、メーカーの品質保証部門だけでなく、メーカーの設計部門やサプライヤーなど、複数の検証担当が検証を行なう場合もある。そこで、同一の故障部品についても複数の配送先を指定できるようにした。また、配送先が複数ある場合は、配送の順序や配送の優先順位を指定できるようにした。例えば、メーカー優先と指定されている場合は、メーカーを最初の配送先に設定できる。例えば、時間優先と指定されている場合は、ディーラーから最短の時間で配送できる配送先に配送することができる。例えば、コスト優先と指定されている場合は、最も配送コストを節約できるルートを使用して故障部品を配送することができる。
また、回収スケジュールなどの回収情報がメーカーやサプライヤーなどに通知されるため、故障した部品の配送状況等をメーカーが監視することも可能となる。また、ディーラーに配送されれば、余裕をもって故障部品の発送準備に取り掛かることができよう。
さらに、物流担当が故障部品の配送を完了すると、配送完了がメーカーの品質保証部門やサプライヤーなどの検証担当に報告されるため、検証作業への取り掛かりまでの時間が短縮されよう。見取り評価を希望する関連部署に配送完了が送信されれば、近隣の関連部署に故障部品が到着したことを把握できるため、見取り評価が速やかに実行されよう。

また、同一の部品であってもその故障内容に依存してサプライヤー等が検証すべき場合や、メーカー等が検証すべき場合もある。そこで、故障内容を含む問い合せ情報を送信することで、各関連部署が故障内容に応じて、配送先、連絡先、及び配送先になるべきか、あるいは何れにもならないかを容易に判断できるようになる。

また、複数の配送先のうち、所定の配送順序では配送の効率が悪い場合もある。例えば、優先順位の高い配送先の都合が悪い場合には、配送順序を変更したほうが故障部品を円滑に回送できよう。そこで、複数の配送先に故障部品を配送について承諾を問い合せ、承諾できない場合は配送順序を変更することで、配送の効率が向上しよう。

また、部品によっては故障の原因が十分に解明されており、さらなる検証は不要な場合もあろう。そのような部品が故障のたびに配送されたのでは配送コストが無駄にかさむ。そこで、データベースに回収不要の旨を登録しておき、ディーラーから回収のリクエストを受け付けたときに当該データベースを参照し、回収不要な部品であれば、その旨をディーラーに告げるようにした。これにより、無駄な配送を抑制できよう。

なお、ディーラーが回収不要の理由や故障の原因を知りたい場合も予想される。そこで、回収不要となった理由や故障の原因等を通知することで、ディーラーや整備の担当者の疑問を解消することができよう。

また、故障した部品が所与の配送先に到着した場合には、故障部品の検証担当社や見取り評価者等に知らせることで、検証作業の取り掛かりが円滑になろう。また、メーカー、ディーラー、サプライヤー等に知らせれば、故障部品の配送状況を把握できる利点もあろう。

また、検証結果は、ディーラーやメーカーなど予め設定されたアドレス（例：電子メールアドレス、ＵＲＬアドレス、インスタントメッセンジャーのアドレス等）を通じて報告されるため、故障部品対策の立案に生かせるメリットがある。また、サプライヤーのみが検証した場合は、メーカーの品質保証担当部門等にも検証結果を送付することも可能なため、故障の原因等をメーカーも把握できるようになる。

また、ある期間内に同一条件の回収リクエストが複数受信される場合もある。そのような場合に、毎回同一の回答情報を作成して送信するのは面倒であろう。そこで、同一又は類似の条件の回収リクエストがある期間内に連続して発生したり、あるいは所定回数発生した場合は、案内情報を送信を省略し、前回の回答情報を代わりに利用することで、各関連部署の負担を軽減できるようにした。

また、案内情報を送付した関連部署から回答情報を受信できなかった場合は、予め設定しておいたデフォルトの関連部署を配送先・報告先等に設定することで、回収リクエストに対して無応答になってしまう事態を防止できよう。

また、配送順序を決定する際に、案内情報を送信してから所定期間までに受信された回答情報だけで配送順序を決定し、遅延して回答情報を送信してきた関連部署は配送順序を後回しにすることで、迅速に対応できるようにしている。すなわち、すべての回答情報を待ってから配送順序を決めていたのでは、故障部品の回収処理が思いのほか遅延する事態も考えら得る。そこで、時間制限を設けて一旦締め切ることで、回収処理の遅延を防止している。

また、故障部品の大きさや質量等のデータをデータベースにより管理し、故障部品の配送リクエストを送信する際に当該データも添付するようにしたので、物流担当は、配送者の手配や配送料金の算出の手間を軽減できる。

このように本発明では、メーカーなどを経由することなく適切な配送場所へと迅速かつ確実に故障部品を配送できるようになろう。

以下では、当業者が上記発明を実施する際に参考となると思われるいくつかの実施形態を示す。もちろん以下の実施形態は、上位概念として開示された本発明の下位概念にすぎない。

なお、以下の実施形態に記載する下位概念の発明について、そのすべてが特許請求の範囲に記載されているとは限らない。ただし、これは特許発明の技術的範囲から意識的に除外したのではなく、特許発明と均等の関係にあるため、あえて特許請求の範囲には記載していない場合がある。

図１は、本実施形態に係る故障部品の配送管理システムの全体像を示した図である。従来は、ディーラーから回収された部品は必ずメーカーを経由していたが、本実施形態では、部品の特性や故障に応じて適切な配送先へと配送させるものである。例えば、メーカーによる一次検証が不要な故障部品については、直接、サプライヤーへと配送できるため、配送処理の効率が改善されよう。

ディーラーには、故障した部品の回収リクエストを送信するためのコンピュータ端末１００が備えられている。メーカーには、故障した自動車部品に関連する部署の登録・変更の承認、配送の希望、配送の承認、部品回収情報の受信及び表示、部品到着情報の受信及び表示、並びに検証結果の表示など、これらの少なくとも一つの処理を実行するコンピュータ端末１１０が備えられている。関連する部署とは、必ずしも同一企業内の部門を意味するわけではなく、ディーラーやサプライヤーなどの他の企業も含まれる概念である。サプライヤーには、配送・連絡・検証の希望、配送の承諾、部品回収情報の受信及び表示、部品到着情報の受信及び表示、並びに検証結果の入力などの少なくとも一つを実行するためのコンピュータ端末１２０が備えられている。物流業者には、故障した部品に関する配送リクエストの受信・表示等を実行するコンピュータ端末１３０が備えられている。なお、これらのコンピュータ端末は、１台である必要はなく同様のものが複数設置されていてもよい。あるいは、デスクトップコンピュータ、モバイルコンピュータ及び専用端末など種類の異なるコンピュータが１以上設置されていてもよい。もちろん、これらの端末は、専用端末であってもよいが、本実施形態にかかるコンピュータプログラムを実行可能な一般的なコンピュータ端末であってもよいことはいうまでもない。

配送管理サーバ１０１は、上述の各コンピュータ端末とネットワーク（例：インターネットや専用回線など）を介して接続されており、配送の管理処理を実行するコンピュータである。配送管理サーバ１０１は、さらに、各自動車部品ごとに関連部署の情報を記憶した関連部署設定データベース１０２と、部品の識別情報を記憶した部品データベース１０３と、故障原因を記憶した故障原因データベース１０４と、回収対象の部品に関する各種情報を記憶した回収部品データベース１０５と、故障コードを管理するための故障コードデータベース１０６と、関連企業及び関連部門の住所情報を管理する住所データベース１０７と接続されている。

また、上記各コンピュータ端末及びサーバは、ＲＯＭやハードディスクドライブに格納されているコンピュータプログラムに基づいて様々な処理及び制御を実行する中央演算処理装置（ＣＰＵ）を備えている。制御プログラムとしては、後述するフローチャートにそって適宜の処理を実行する、例えば、ＷＥＢサーバプログラム、ＣＧＩプログラム、電子メールサーバプログラム、インターネットメッセンジャーのサーバプログラム、ＷＥＢクライアント（いわゆるブラウザ）プログラム、電子メールクライアントプログラム、インターネットメッセンジャーのクライアントプログラム及び種々のスクリプトなどがある。一時的なデータはＲＡＭに格納される。表示装置も備えられており、処理内容、処理結果などを表示する。また、タッチパネルデバイスやテンキー及びポインティングデバイスなどの入力装置も備えられている。またＣＰＵは、通信インタフェース回路を介して他の装置と以下のようなデータの送受信を行なう。

図２は、本実施形態に係る関連部署データベースの例示的なデータ構造を示した図である。当該データベース１０２には、例えば、車種を表すデータ、各部品を識別するための部品番号、各故障を識別するための故障コード、回収が必要な部品か不要な部品化を表す回収要否データ、故障原因（コードなど）を表す故障原因データ、関連部署の企業コード等を表す関連部署データ、故障部品に関する情報を必要としている設計部門（例えば見取り評価を希望している部門など）、故障部品の検証を担当する部門及び検証結果の報告先（メーカーの品質保証部門等）を表す関連部署データ、強制配送を行なう場合の配送先のデータ、強制配送を行なうときの条件、配送リクエストを送信する際に事前の承認が必要か否かを表す配送承認データ、及び複数の配送先が登録されている場合に、その配送の順序や優先順位などに関連する優先条件データなどが含まれている。
なお、案内情報を送信してから所定の制限時間内に回答情報を送信してきた関連部署についての配送順序を決定する場合は、各部品ごとの制限時間をデータベースにきおくしておいてもよい。制限時間は、例えば、故障内容によって変更してもよい。例えば、緊急を要する場合は制限時間を短くするが如くである。

図３は、本実施形態に係る部品データベースの例示的なデータ構造を示した図である。当該データベースには、例えば、車種を表すデータ、各部品を識別するための部品番号、部品の名称データ、一以上の故障コード、部品の外形サイズを表す大きさデータ、及び部品の重量を表す重量データなどが含まれている。なお、本データベースにおいて、上述の回答情報の受信に関する制限時間を登録しておいてもよい。

図４は、本実施形態に係る故障原因データベースの例示的なデータ構造を示した図である。当該データベースには、例えば、故障の原因を識別するための原因コード、及び各原因コードに対応する詳細な情報などが含まれている。

図５は、本実施形態に係る回収部品データベースの例示的なデータ構造を示した図である。当該データベースには、例えば、回収リクエストごとに発行されるＩＤ、車種を表すデータ、各部品を識別するための部品番号、各故障を識別するための故障コード、ディーラーなどの配送元に故障部品を引き取り（回収）に行く日を表す回収日データ、故障部品が指定された配送先に到着する日を表す到着日データ、配送先の企業コード等を表す配送先データ、連絡先データ、検証結果の報告先（アドレスなど）を表す報告先データ、検証結果の入力者又検証者などを表す入力者データ、検証の実行された日時を検証日時データ、及び検証結果を表す検証結果データなどが含まれる。同様に、ディーラーにおいて故障した部品に関連する修理を行なった日又は修理予定の日のデータが含まれていてもよい。

図６は、本実施形態に係る故障コードデータベースの例示的なデータ構造を示した図である。当該データベースには、例えば、各故障を識別するための故障コード、自動車部品の故障が発生した際に強制的に案内情報が送信される部署のデータ、強制案内を行なう際の条件を表す条件データ、故障した部品が強制的に配送される配送先部署のデータ、故障した部品の検証結果が強制的に送信される強制報告先のデータ、強制報告を実行するときの条件データ、故障部品を指定の配送先に配送する際に所定の者（例：メーカーの担当者など）の承認が必要か否かを表す配送承認データなどが含まれている。

図７は、本実施形態に係る住所データベースの例示的なデータ構造を示した図である。当該データベースには、例えば、各関連企業の企業ＩＤ、企業名称のデータ、企業の住所データ、電話番号データなどが含まれている。

図８は、本実施形態に係る関連部署に関連するデータの設定処理を示したフローチャートである。ここでは、故障部品の関連部署を設定するのであるが、故障部品の検証を担当するサプライヤーやメーカーの品質保証部門だけでなく、検証を実行するわけではないが故障部品を一度見てみたいと考えている設計部門等の他の部門なども関連部署として設定できる。すなわち、配送は不要であるが、近くの検証担当部門に故障部品が配送された場合には、自ら足を運んでその故障部品を見てみたい（いわゆる見取り評価を実行したい）と考える開発者や研究者も存在する。その場合も、関連部署として見取り評価部門の企業コード、部門コード又は電子メールアドレス等を登録しておくことで、故障部品の案内情報を得ることができる。

ステップＳ８００において、メーカー端末１１０のＣＰＵは、キーボード等の入力装置から配送先設定処理の起動を指示されると、配送管理サーバ１０１に設定処理の開始要求を送信する。例えば、本システムをＷＥＢベースで構築する場合は、配送管理サーバ１０１のＵＲＬを入力することになろう。

ステップＳ８０２において、サーバ１０１のＣＰＵは、メーカーの端末１１０からの開始要求を受信すると、関連部署設定用の画面情報を作成する。

図９は、本実施形態に係る関連部署設定画面の一例を示す図である。サーバ１０１は、予めハードディスクドライブ等に格納された雛型ファイルをオープンし、メーカー端末１１０の操作者の名称など、各設定者ごとにカスタマイズすべき情報を書き込むことで、画面情報を作成する。操作者の名称等は、例えば、サーバ１０１へのログイン時に使用されたＩＤ又は当該ＩＤに対応する名称データをデータベースから読み出して設定してもよい。なお、画面情報としては、ＨＴＭＬファイル、ＸＭＬファイル及びＪａｖａ（登録商標）スクリプトなどを用いて実現することができる。

ステップＳ８０４において、サーバ１０１のＣＰＵは、メーカーの端末１１０に関連部署設定用の画面情報を送信する。
ステップＳ８０６において、メーカー端末１１０のＣＰＵは、受信した画面情報を表示装置に出力する。たとえば、ＷＥＢブラウザによって画面情報を表示データに変換して表示する。メーカー端末１１０のＣＰＵは、入力装置から入力される指示に応じて車種データ等を入力する。例えば、車種データを入力するときは、車種の欄の横に表示された「参照」ボタンを押して、車種リストが表示され、ポインティングデバイス等により何れか一つの車種を選択すると車種データの欄に車種コードが設定される。これは、ＨＴＭＬの技術である＜ＳＥＬＥＣＴ＞エレメントを使用すれば最も簡単に実現できよう。車種などのリストデータも画面情報とともに受信したものである。部品番号や関連部署などの他のデータについても同様の手順で入力することができる。関連部署には、故障部品の配送先も含まれる。ここでいう配送先とは、部品が故障したときに当該部品をディーラーから引き取る部門を意味する。通常は、部品を製造したサプライヤーが配送先となろう。

ステップＳ８０８において、メーカー端末１１０のＣＰＵは、ポインティングデバイス等から設定の変更要求（例えば、図９のＯＫボタンなど）が押されたことを検出すると、入力された車種データや部品番号データとともに設定の変更要求をサーバ１０１に送信する。

ステップＳ８１０において、サーバ１０１は、通信インタフェースを介して設定変更要求を受信すると、設定変更要求に伴って受信された車種データ、部品番号データ、故障コード及びなどを検索キーとして関連部署設定データベース１０２を検索し、対応するレコードを抽出し、ＲＡＭに保存する。図９の例で説明すると、車種：０１５１、部品番号：１２３４及び故障コード：０１２であったとすると、最も上のレコードが抽出される。そして、サーバ１０１のＣＰＵは、次に受信した関連部署のデータを用いてレコードの内容を書き換え、データベース１０２に保存する。

ステップＳ８２０において、サーバ１０１は、変更承認後のレコードの内容を含む変更完了通知をサプライヤーの端末１２０に送信する。また、設定変更完了通知へアクセスするためのＵＲＬを記入した電子メールが送信されてもよい。また、インスタントメッセ−ジャーによってリアルタイムで完了通知を送信してもよい。以上の手順により、各部品ごとの関連部署がデータベース上に登録される。

図１０は、本実施形態に係る故障部品回収処理の例示的なフローチャートである。図１０を用いてディーラーにおいて故障部品の回収を要求し、その要求が部品回収データベースに登録されるまでを説明する。

ステップＳ１０００において、ディーラー端末１００のＣＰＵは、キーボード等から部品回収リクエスト用のＵＲＬが入力されると、当該入力されたＵＲＬに従いサーバ１０１へと回収設定画面要求を送信する。

ステップＳ１００２において、サーバ１０１のＣＰＵは当該要求を受信すると、回収設定画面の雛形ファイル（例えば、ＨＴＭＬファイルや画像ファイルなど）をハードディスクドライブから読み出し、回収設定画面の情報を作成し、ディーラー端末１１０に送信する。

図１１は、本実施形態に係る回収設定画面の一例を示す図である。回収依頼者の欄には、各ディーラーの名称データが反映されているが、例えば、サーバ１０１へのログイン時のＩＤ等に基づいて設定されたものである。

ステップＳ１００４において、端末１００のＣＰＵは、通信インタフェース介して回収設定画面情報を受信し、ＷＥＢブラウザを使用して表示装置に表示する。端末１００のＣＰＵは、入力装置からの指示に従って、車種データ、部品番号データ及び故障コードをＲＡＭに記憶する。

ステップＳ１００６において、端末１００のＣＰＵは、ＯＫボタン（例えば、ＨＴＭＬのフォームエレメントにおけるＳｕｂｍｉｔボタンに相当する。）の押し下げを検出すると、ＲＡＭから車種データ等を読み出して、読み出されたデータを伴う登録要求をサーバ１０１に送信する。

ステップＳ１００８において、サーバ１０１のＣＰＵは、登録要求とともに車種データ等を受信すると、対応するレコードを関連部署データベース１０２から読出し、ＲＡＭに記憶する。図２に示した例のように、この中には、回収が必要な部品か、または不要な部品かを表す情報も含まれていてもよい。

ステップＳ１０１０において、サーバ１０１のＣＰＵは、ＲＡＭから回収要否データを読出し、読み出された回収要否が「回収要」であるかどうかを判定する。「回収要」であればステップＳ１０１４に進む。

一方、回収不要であれば、ステップＳ１０１２に進み、ＲＡＭに記憶されている対応レコードから故障原因コードを読出す。さらに、読み出されたコードに対応する故障原因の詳細情報を、故障原因データベース１０４から検索抽出する。そして、回収不要情報を作成し、ディーラーの端末１００に送信する。

図１２は、本実施形態に係る回収不要情報の一例を示す図である。当該図面によれば、回収要求にともなう部品データとともに、回収不要であること及び詳細な故障原因が表示されることになる。これにより、ディーラー等は回収が不要であることを把握でき、さらにその理由までも知ることができるので、今後、同様の故障が発生した場合にも対応しやすくなろう。

ステップＳ１０１４において、サーバ１０１のＣＰＵは、回収部品データベース１０５を参照し、新しい回収ＩＤを決定し（例えば、通し番号なら１つ番号をインクリメントする。）、ＲＡＭに記憶しておいた対応レコードから、車種データ、部品番号データ、故障コードデータ、及び関連部署のデータを読み出す。これらの関連部署のデータは、企業コードであってもよいし、ＵＲＬ、ＩＰアドレス、電子メールアドレスなどであってもよい。読み出したデータに基づいて、案内情報を作成する。案内情報は、電子メール、インスタントメッセージ、ＷＥＢページやその他などの何れを使用してもよい。
ステップＳ１０１６において、サーバ１０１は、関連部署データベース１０２から読み出した各関連部署を宛先に設定して、作成した案内情報を送信する。なお、回答情報の受信期限を管理する場合は、サーバ１０１のＣＰＵが、タイマーを起動し、データベースから読み出した所定の制限時間が計時されたか否かを判定する。

ステップＳ１０１８において、案内情報を受信した各端末は、当該案内情報を表示装置に表示する。なお、強制案内先として予め故障コードデータベース１０６に登録されており、しかも強制条件が満たされているときは、関連部署として設定されてなくても案内先として設定される。

図１３は、本実施形態に係る例示的な案内情報を示す図である。上述したデータのほかに、回収日時を入力するためのテキストボックス、故障内容などのコメントを入力するテキストボックス、配送希望の要否を選択するためのチェックボックス、連絡希望の要否を選択するためのチェックボックス、連絡希望を選択した場合にどの関連部署に故障部品が配送されてきたときに配送完了の連絡を受領したいかを示すための関連部署の入力欄、故障部品の検証結果が得られた場合にその報告を受けたいか否かを表すチェックボックス、及びリピート返答を希望するかどうかを表す入力欄が設けられている。リピート返答は、所定期間内（例えば５日以内など。代替的に所定回数としてもよい。また所定期間内に所定回数としてもよい。）に同一内容の故障部品についての回収リクエストを受信した場合に、サーバ１０１は、リピート返答を希望している部署には案内情報の送付を省略して、最初に選択した希望条件をコピーして使用することを意味する。

ステップＳ１０２０において、各端末のＣＰＵは、ＯＫボタンが入力されたことを検出すると、予め入力装置から入力された回収日時、コメント、配送希望、連絡希望、及び報告希望に関するデータ（希望情報）をサーバ１０１に送信する。

ステップＳ１０２２において、サーバ１０１は、予め案内情報を送信しておいた各端末から希望情報の受信を完了すると、受信した希望情報を解析し、配送先となることを希望している部署を配送先として決定し、連絡先となることを希望している部署を連絡先として決定し、報告先となることを希望している部署を報告先として決定し、回収部品データベース１０５に登録するためのレコード情報を作成し、一旦、ＲＡＭに記憶しておく。なお、強制配送先として予め関連部署データベース１０２に登録されており、しかも強制条件が満たされているときは、希望情報の如何にかかわらず配送先として設定される。また、強制報告先についても同様である。また、配送先等を希望する回答情報が存在しなかった場合は、ＣＰＵが、強制配送先等をデフォルトの配送先等として選択してもよい。

なお、回答情報の受信期限を管理する場合は、所定の制限時間内に受信された回答情報についてステップＳ１０２２の処理を実行する。また、制限時間の経過後に到着した回答情報に関しては、配送順序の優先順位を下げるようにＣＰＵが制御する。

ステップＳ１０２４において、配送先が複数設定されていると判定すると、サーバ１０１のＣＰＵは、さらに、対応レコード配送優先データを読出し、当該配送優先データにしたがって、配送順序を決定する。たとえば、配送順序が「メーカー優先」となっていれば、メーカーを最初の配送先として設定する。また、「コスト優先」となっていれば、ディーラーの住所データと各配送先の住所データを住所データベースから読出し、コストが再安となるように配送順序を設定する。例えば、各拠点間の配送コストを予めデータベース化しておけば、この内容をＣＰＵが参照することで容易に最安の配送順序を決定できよう。「時間優先」の場合は、最短で効率よく配送できる配送順序を決定する。この場合も、各拠点間の標準所要時間をデータベース化しておくことで容易に決定できよう。

ステップＳ１０２６において、サーバ１０１のＣＰＵは、決定された配送先の確認画面を作成する。確認画面の情報も上述と同様にＨＴＭＬ形式などのＷＥＢベースで作成することができる。

ステップＳ１０２８において、サーバ１０１は、確認画面情報をディーラー端末１００に送信する。なお、確認画面へとアクセスするためのＵＲＬを含んだ電子メールやインスタントメッセージを送信してもよい。ステップＳ１０３０において、端末１１０のＣＰＵは、ＷＥＢブラウザ等を使用して確認画面情報を表示装置に表示する。

図１４は、本実施形態に係る配送確認画面の一例を示している。この図によれば、回収要求ごとの識別番号（これはサーバ１０１のＣＰＵが回収登録要求（Ｓ１００６）を受信したときに発行したもの）、車種データ、部品番号、故障コードとともに、回収日時や修理日（予定日でも可）及び所定のコメントなどが表示される。なお、回収日時や修理日等はこの段階で端末１００から入力してもよい。

ステップＳ１０３２において、端末１００のＣＰＵは、回収依頼ボタンの押し下げを検出すると、入力された回収日時等のデータとともに回収依頼情報をサーバ１０１に送信する。
ステップＳ１０３４において、サーバ１０１のＣＰＵは受信した回収日時データ等を含む回収レコード（図５）作成し、回収部品データベース１０５に書き込む。回収レコードは、ディーラーから受信した情報と、予め関連部署データベース１０２から読み出したデータ等に基づいて作成される。

図１５は、本実施形態に係る配送処理の例示的なフローチャートである。図１５を用いて、配送の承認処理から故障部品の到着通知処理までを説明する。

ステップＳ１５００において、サーバ１０１のＣＰＵは、回収部品データベース１０５へと新規に登録されたレコードを読出し、さらに読み出されたレコードに含まれていた車種データ、部品番号及び故障コードに基づいて関連部署データベース１０２から配送承認の要否データを読み出す。配送の開始前に事前にメーカー等の予め定められた者の承認が必要とデータベース１０２に登録されていれば、ステップＳ１５０２へと進み、そうでなければ、ステップＳ１５０８に進む。

ステップＳ１５０２において、ＣＰＵは、回収部品データベース１０５に対応レコードに基づいて配送承認画面の情報を作成し、配送承認要求としてメーカー端末１１０に送信する。ステップＳ１５０４において、メーカー端末１１０のＣＰＵは、配送承認要求を受信すると、ＷＥＢブラウザを用いて配送承認画面を表示装置に出力する。

図１６は、本実施形態に係る配送承認画面の一例を示す図である。図によれば、いずれも回収部品データベース１０５から読み出されたデータが列挙されている。なお、図５によれば回収依頼者のデータがデータベース１０５に記載されていないが、これは省略されているに過ぎない。この配送承認画面に表示された内容に同意するのであれば、承認ボタンが押し下げられる。なお、配送先、連絡先、報告先、配送順序、配送の優先規則等を変更できるようにしてもよい。ここで変更された内容は、サーバ１０１に送信され、回収部品データベース１０５に記憶される。

ステップＳ１５０６において、メーカー端末１１０のＣＰＵは、承認ボタンの押し下げを検出すると、配送承認情報をサーバ１０１に送信する。

ステップＳ１５０８において、サーバ１０１は、各配送先の配送承諾が必要か否かを判定する。例えば、配送承諾の要否が、関連部署データベース１０２に登録されている場合は、その内容を参照して要否を判定する。要であれば、ステップＳ１５１０に進み、不要であれば、ステップＳ１５１６に進む。

ステップＳ１５１０において、サーバ１０１のＣＰＵは、回収部品データベース１０５に登録されている各配送先に対して、配送の承諾要求を送信する。配送の承諾要求には、配送対象の部品番号、故障コード、回収日（又は回収日から求めた配送予定日）など、回収部品データベース１０５に登録されているデータが含まれている。

ステップＳ１５１２において、配送先として指定されたサプライヤーの端末１２０は、承諾要求を受信すると、配送内容を表示装置に出力する。ステップＳ１５１４において、ＣＰＵは、もし配送予定日や配送順序が配送先の都合に合わなければ、配送順序の変更要求（例えば、希望の配送順序に関する情報を含む。）をサーバ１０１に送信する。サーバ１０１は、希望の配送順序について、配送承認処理（Ｓ１５０２ないしＳ１５０６）を実行する。

ステップＳ１５１６において、サーバ１０１は、物流担当の端末１３０に対し、配送依頼情報を作成し、送信する。例えば、サーバ１０１は、配送対象となっている故障部品の大きさ、重量に関するデータを部品データベース１０３から読み出すとともに、回収依頼者の企業コードと、配送先の企業コードとからそれぞれの住所及び電話番号等の配送に必要な情報を住所データベース１０７から読出し、これらの読み出された情報を含む配送依頼情報を作成する。物流担当の端末１３０は、配送依頼情報を受信すると、表示装置又は印刷装置等から出力する。物流担当端末１３０は、配送依頼情報に基づいて配送元（故障部品を発送するディーラー）に故障部品を引き取りに行く日（回収日）と、配送先へ配達する日（到着日）を決定し、発送日と到着日の情報をサーバ１０１に送信する。サーバ１０１は、これらの日付データを、回収部品データベース１０５内の対応するレコードに記憶する。なお、回収日が予めディーラーにより指定されているときはそのまま使用してもよい。

ステップＳ１５１８において、サーバ１０１のＣＰＵは、回収部品データベース１０５から回収対象部品のレコードを読出し、当該レコードの内容を反映した最新の回収情報を作成する。

図１７は、本実施形態に係る回収情報の一例を示す図である。例えば、回収情報には、回収依頼者、回収ＩＤ、部品番号、故障コード、各配送先ごとの集配日などが含まれている。これによって、メーカーやサプライヤー等の配送先は、それぞれ配送品の受け入れ準備を整えることができ、また、メーカーを経由せず直接的にサプライヤーに配送される場合もメーカーが故障部品の発生と配送を把握することができる。

ステップＳ１５２０及びＳ１５２２において、サーバ１０１は、連絡先、報告先、配送先等の予め定められたアドレスに回収情報を送信する。回収情報は、例えば、電子メールにて送信してもよいし、サーバ１０１の回収情報のページに所定の端末がアクセスしてきたときにＷＥＢ情報として送信してもよい。そして、ステップＳ１５２４及びＳ１５２６において、回収情報を受信した端末は、表示装置や印刷装置から出力する。

ステップＳ１５２８において、物流担当の端末１３０から配送の完了などを表す配達情報を送信する。ステップＳ１５３０において、サーバ１０１は、受信した配達情報と、回収部品データベース１０５から読み出した対象部品の部品番号等を含む部品到着情報を作成する。ステップＳ１５３２及びＳ１５３４においてサーバ１０１は、連絡先、配送先、報告先等の予め定められたアドレスに対し部品到着情報を送信する。ステップＳ１５３６及びＳ１５３８において、各端末において部品到着情報が出力される。

図１８は、本実施形態に係る部品到着情報の一例を示す図である。例えば、部品到着情報には、回収依頼者、回収ＩＤ、部品番号、故障コード、故障部品の到着先、次の配送先などの情報が含まれている。

図１９は、本実施形態に係る検証結果の登録処理に関する例示的なフローチャートである。この図を用いて検証結果の入力から表示までを説明する。この例では、サプライヤーが検証担当となっている場合であるが、もちろんメーカーの品質保証部門が検証担当であってもよい。後者の場合も同様に本発明を適用できることはいうまでもない。

ステップＳ１９００において、サプライヤー端末１２０は、検証結果を入力するための入力要求をサーバ１０１に送信する。入力要求は、例えば、入力ページのＵＲＬなどを含んでいる。なお、故障部品の送付票に予め当該ＵＲＬを記載しておけば、検証入力がしやすくなろう。また、アクセス先の情報をバーコード化して送付票に印刷しておき、端末１２０のバーコードリーダーで読み出して、それをＵＲＬに変換してサーバ１０１にアクセスしてもよい。

ステップＳ１９０２において、サーバ１０１は、入力画面の情報（例えば、ＨＴＭＬファイルなど）を生成する。ステップＳ１９０４において、サーバ１０１は、作成した入力画面情報を端末１２０に送信する。

ステップＳ１９０６において、端末１２０は、入力画面情報を受信し、表示装置に表示する。図２０は、本実施形態に係る検証結果の入力画面の一例を示す図である。この図によれば、回収ＩＤ、車種ＩＤ、部品番号、故障コード、回収日時、故障原因、詳細な検証結果等が含まれおり、それぞれ端末１２０において入力される。あるいは、入力要求の際に故障部品に添付されていたか回収ＩＤをサーバ１０１に送信することで、回収部品データベース１０５から必要なデータを読み出して入力画面を作成してもよい。また、次の配送先をこの時点で登録してもよい。その場合は、ＧＯボタンを押すことで、配送先を選択する画面を呼び出して次の配送先を指定する。なお、今後、検証は不要（すなわち回収も不要）と考える場合は、回収不要の登録要求もサーバ１０１に送信してもよい。この場合は、関連部署データベース１０２の内容がサーバ１０１によって更新されよう。

また、検証結果は、テキストのみである必要はなく、音声情報、画像情報及び動画情報の少なくとも一つが含まれていもよい。これは、今後の故障対象に役立つ情報であるため、添付されることが望ましいかもしれない。

ステップＳ１９０８において、端末１２０のＣＰＵは、検証結果の入力完了ボタンの押し下げを検出すると、故障原因や検証結果等を含む登録要求をサーバ１０１に送信する。

ステップＳ１９１０において、サーバ１０１は、受信した登録要求に含まれている回収ＩＤを検索キーとして、対応するレコードを回収部品データベースから検索抽出し、受信した検証結果等の情報をレコードに反映させて再びデータベースに書き込む。ステップＳ１９１２において、サーバ１０１は、変更後のレコードに基づいて検証結果情報を作成する。図２１は、本実施形態に係る検証結果の表示画面の一例を示す図である。検証結果の表示画面には、回収部品データベースに登録された部品番号、故障コード、故障原因、及び検証結果などが含まれている。

ステップＳ１９１４及びＳ１９１８において、サーバ１０１は、予め定められた報告先に対して検証結果の表示画面情報を送信する。さらに、ステップＳ１９１６及びＳ１９２０において、当該情報を受信した各端末は、検証結果の表示画面情報を出力する。なお、検証結果は、電子メールアドレスに対して送信してもよい。

ところで、サーバ１０１は、回収部品データベース１０５の到着日時と検証日時とを適宜のタイミングで読出し、到着日時から所定日時を経過しても検証日時が入力されていない場合には、配送先（検証担当）に対して検証を促す電子メール等を送信してもよい。

また、上述の回答情報の制限時間を適用する場合は、遅延した回答情報を受信する度に、あるいはいくつか受信したときに、あるいは残りの回答情報をすべて受信したときに、遅延してきた回答情報に係る配送先を配送順序に追加してもよい。新しい配送順序に基づいてサーバ１０１は、回収部品データベース１０５を更新し、更新後の配送順序を物流担当の端末に送信する。また、更新後の配送順序に関して回収情報等を連絡先や報告先に送信してもよい。

また、サーバ１０１が、各故障部品についての統計的な発生状況に関するデータベースを作成している場合は、関連部署の設定画面（図９）等に当該発生状況の参照ボタンを設けることで、過去の発生状況についての統計資料（表やグラフ）などを表示できるようにしてもよい。あるいは、サーバ１０１が、ある回収リクエストを受信すると、関連する過去の発生状況をデータベースから読出し、所定期間内における発生頻度がしきい値を超えているかどうかを判定し（例えば、１ヶ月に１０件以上発生しているなど）、しきい値を超えていれば、案内情報のウインドウ内に警告を促すようなメッセージを表示するようにしてもよい。このようにすることで、特定の部品についての特定の故障の発生頻度が高ければ、それに応じて関連部署を変更することもできよう。

さらに、サーバ１０１は、各回収ＩＤごとに、現在の故障部品の所持部署と所持期間（配送完了日からの経過日）を回収部品データベース１０５に記憶してもよい。例えば、所持期間が所定の期間より長くなれば、故障の検証が遅いとしてサーバ１０１が警告情報を送信することもできよう。このようにすれば故障部品の停滞を防止できる利点があろう
上述の実施形態では、ＷＥＢベースで本発明を実施する場合を説明したが、一部又は全部において電子メール、ファクシミリ及び独自の通信プロトコルなどＷＥＢベース以外の技術を用いて実現してもよい。また、ネットワークは、インターネットである必要はなく、専用線を用いたクローズされたネットワークであってもよいし、双方を適宜に組み合わせてもよい。

また、上述の実施形態における各ステップのうち順番を変えたとしても結果に影響がないものは適宜入れ替えてもよいことは明らかであろう。すなわち、これらステップを入れ替えたフローについても本願において実質的に開示されているといえよう。

図１は、本実施形態に係る故障部品の配送管理システムの全体像を示した図である。 図２は、本実施形態に係る関連部署データベースの例示的なデータ構造を示した図である。 図３は、本実施形態に係る部品データベースの例示的なデータ構造を示した図である。 図４は、本実施形態に係る故障原因データベースの例示的なデータ構造を示した図である。 図５は、本実施形態に係る回収部品データベースの例示的なデータ構造を示した図である。 図６は、本実施形態に係る故障コードデータベースの例示的なデータ構造を示した図である。 図７は、本実施形態に係る住所データベースの例示的なデータ構造を示した図である。 図８は、本実施形態に係る配送先に関連するデータの設定処理を示したフローチャートである。 図９は、本実施形態に係る配送先設定画面の一例を示す図である。 図１０は、本実施形態に係る故障部品回収処理の例示的なフローチャートである。 図１１は、本実施形態に係る回収設定画面の一例を示す図である。 図１２は、本実施形態に係る回収不要情報の一例を示す図である。 図１３は、本実施形態に係る例示的な案内情報を示す図である。 図１４は、本実施形態に係る配送確認画面の一例を示している。 図１５は、本実施形態に係る配送処理の例示的なフローチャートである。 図１６は、本実施形態に係る配送承認画面の一例を示す図である。 図１７は、本実施形態に係る回収情報の一例を示す図である。 図１８は、本実施形態に係る部品到着情報の一例を示す図である。 図１９は、本実施形態に係る検証結果の登録処理に関する例示的なフローチャートである。 図２０は、本実施形態に係る検証結果の入力画面の一例を示す図である。 図２１は、本実施形態に係る検証結果の表示画面の一例を示す図である。

Claims (27)

1. 自動車販売会社から回収される故障した自動車部品の配送処理を管理する配送管理システムであって、
   故障した自動車部品について自動車販売会社の端末から送信される回収リクエストを受信する回収リクエスト受信手段と、
   前記回収リクエストが受信されると、自動車部品ごとに該自動車部品が故障したときの配送先の情報を記憶した関連部署データベースから、該回収リクエストに含まれる前記故障した自動車部品の識別情報に基づいて、該故障した自動車部品の関連部署の情報を検索抽出する検索抽出手段と、
   前記検索抽出された関連部署の端末に対し、前記故障した自動車部品に関する配送の希望、連絡の希望及び検証結果の希望などに代表される該関連部署の希望を問い合せるための問い合せ情報を送信する問い合せ情報送信手段と、
   前記関連部署の端末からそれぞれ前記問い合せ情報に対する回答情報を受信する回答情報受信手段と、
   前記受信した回答情報のうち配送希望を含む回答情報を送信してきた関連部署が複数ある場合に所定のルールを読み出し、該ルールに基づいて配送順序を決定する配送順序決定手段と、
   前記決定された配送順序、前記配送希望を送信してきた関連部署及び前記故障した部品の配送元となる自動車販売会社に関する情報を伴う配送依頼情報を物流担当の端末に送信する配送依頼送信手段と、
   前記故障した自動車部品の配送に関するスケジュール等の配送情報を、予め登録された第１のアドレス宛てに送信する配送情報送信手段と、
   前記物流担当による前記配送先となる関連部署への前記故障した自動車部品の配送が完了すると、該故障した自動車部品に関する配送完了情報を、予め登録された第２のアドレス宛てに送信する配送完了情報送信手段と
   を含む配送管理システム。
2. 前記回収リクエストには、前記故障した自動車部品の故障内容が含まれており、前記問い合せ情報送信手段は、前記故障内容を含む問い合せ情報を送信することを特徴とする請求項１に記載の配送管理システム。
3. 前記関連部署データベースは、故障内容と対応付けて前記関連部署の情報を記憶しており、前記検索抽出手段は、前記回収リクエストに含まれる自動車部品の識別情報及び故障内容に対応する関連部署を検索抽出することで、故障内容に応じて案内情報を送信する宛先を変更することを特徴とする請求項１又は２に記載の配送管理システム。
4. 前記配送順序決定手段は、前記関連部署データベースに記憶されている、複数の配送先のうちどれを優先すべきかを表す優先順位情報にしたがって配送順序を決定することを特徴とする請求項１ないし３の何れか１項に記載の配送管理システム。
5. 前記検索抽出された各配送先のアドレスに対して、前記決定された配送順序を承諾するか否かの伺い情報を送信する伺い情報送信手段と、
   前記伺い情報への応答として各配送先から送信される承諾情報を受信する承諾情報受信手段と、
   前記受信された承諾情報に基づいて必要であれば前記配送順序を変更する配送順序変更手段と
   を含むことを特徴とする請求項１ないし４の何れか１項に記載の配送管理システム。
6. 前記関連部署データベースが、各自動車部品ごとに回収の要・不要に関する情報を記憶している場合、前記回収リクエストが受信されると、該回収リクエストに関連する自動車部品の回収の要・不要に関する情報を前記検索抽出手段により検索抽出し、該検索抽出された回収の要・不要に関する情報が回収不要を示しているか否かを判定する回収要・不要判定手段と、
   前記回収不要と判定された場合に、前記回収リクエストを送信してきた自動車販売会社の端末に対して回収不要を表す情報を送信する回収不要情報送信手段と
   をさらに含む請求項１ないし請求項５の何れか１項に記載の配送管理システム。
7. 前記回収不要の自動車部品の識別情報と対応付けて故障原因に関する情報を記憶する故障対応データベースと、
   回収不要と判定された場合に、前記故障対応データベースから前記故障原因に関する情報を検索抽出する故障原因検索抽出手段と
   をさらに備え、
   前記回収不要情報送信手段は、前記回収リクエストを送信してきた前記自動車会社の端末に対して前記検索抽出された故障原因に関する情報も送信することを特徴とする請求項６に記載の配送管理システム。
8. 前記第２のアドレスは、前記故障した自動車部品の見取り評価を希望する関連部署のアドレスであり、前記見取り評価の関連部署の端末から送信された回答情報において指定されていた他の関連部署に該自動車部品が到着すると、前記配送完了情報送信手段が、該第２のアドレス宛に配送完了情報を送信することを特徴とする請求項１ないし７の何れか１項に記載の配送管理システム。
9. 前記故障した自動車部品の検証結果の送信宛先アドレスと、該自動車部品の識別情報とを対応付けて記憶する検証担当データベースと、
   検証結果が入力されると、前記回収リストに関連する故障した自動車部品の識別情報に基づいて、対応する前記検証結果の送信宛先アドレスを検索抽出する検証結果アドレス検索抽出手段と、
   前記検索抽出された前記検証結果の送信宛先アドレスに対し、前記入力された検証結果を送信する検証結果送信手段と
   をさらに含む請求項１ないし８の何れかに記載の配送管理システム。
10. 前記検索抽出手段により検索抽出された関連部署について、所定期間内又は所定回数にわたり同一又は類似の回収リクエストが受信された場合であって、該関連部署が案内情報及び回答情報の省略を選択している場合は、前記案内情報の送信をスキップさせ、前回の回答情報の内容を今回も利用するよう制御する送信制御手段をさらに含むことを特徴とする請求項１ないし９の何れか１項に記載の配送管理システム。
11. 前記回答情報を送信してきた関連部署が存在しなかった場合には、前記関連部署データベースに予め登録されているデフォルトの関連部署を配送先として設定する強制設定手段ををさらに含む請求項１ないし１０の何れか１項に記載の配送管理システム。
12. 前記案内情報を送信してからの経過時間を計時する計時手段と、
    前記計時手段に従い所定の経過時間内に回答情報を送信してきた関連部署に限って前記配送順序定手段により配送順序を決定させ、一方、前記所定の経過時間から遅れて回答情報を送信してきた関連部署は前記配送順序の最後に追加するよう前記配送順序決定手段を制御する制御手段と
    をさらに含む請求項１ないし１１の何れか１項に記載の配送管理システム。
13. 前記自動車部品ごとの大きさ及び質量に関する情報を記憶した部品データベースをさらに備え、
    前記配送リクエスト送信手段は、配送対象となっている前記故障した自動車部品について前記部品データベースから読み出された大きさ及び質量に関する情報とともに、前記配送リクエストを前記物流担当の端末に送信することを特徴とする請求項１ないし１２の何れか１項に記載の配送管理システム。
14. 自動車販売会社から回収される故障した自動車部品の配送処理を管理する配送管理方法であって、
    故障した自動車部品について自動車販売会社の端末から送信される回収リクエストを受信するステップと、
    前記回収リクエストが受信されると、自動車部品ごとに該自動車部品が故障したときの配送先の情報を記憶した関連部署データベースから、該回収リクエストに含まれる前記故障した自動車部品の識別情報に基づいて、該故障した自動車部品の関連部署の情報を検索抽出するステップと、
    前記検索抽出された関連部署の端末に対し、前記故障した自動車部品に関する配送の希望、連絡の希望及び検証結果の希望などに代表される該関連部署の希望を問い合せるための問い合せ情報を送信するステップと、
    前記関連部署の端末からそれぞれ前記問い合せ情報に対する回答情報を受信するステップと、
    前記受信した回答情報のうち配送希望を含む回答情報を送信してきた関連部署が複数ある場合に所定のルールを読み出し、該ルールに基づいて配送順序を決定するステップと、
    前記決定された配送順序、前記配送希望を送信してきた関連部署及び前記故障した部品の配送元となる自動車販売会社に関する情報を伴う配送依頼情報を物流担当の端末に送信するステップと、
    前記故障した自動車部品の配送に関するスケジュール等の配送情報を、予め登録された第１のアドレス宛てに送信するステップと、
    前記物流担当による前記配送先となる関連部署への前記故障した自動車部品の配送が完了すると、該故障した自動車部品に関する配送完了情報を、予め登録された第２のアドレス宛てに送信するステップと
    を含む配送管理方法。
15. 前記回収リクエストには、前記故障した自動車部品の故障内容が含まれており、前記問い合せ情報送信のステップにおいて、前記故障内容を含む問い合せ情報を送信することを特徴とする請求項１４に記載の配送管理方法。
16. 前記関連部署データベースは、故障内容と対応付けて前記関連部署の情報を記憶しており、前記検索抽出のステップにおいて、前記回収リクエストに含まれる自動車部品の識別情報及び故障内容に対応する関連部署を検索抽出することで、故障内容に応じて案内情報を送信する宛先を変更することを特徴とする請求項１４又は１５に記載の配送管理方法。
17. 前記配送順序決定のステップにおいて、前記関連部署データベースに記憶されている、複数の配送先のうちどれを優先すべきかを表す優先順位情報にしたがって配送順序を決定することを特徴とする請求項１４ないし６の何れか１項に記載の配送管理方法。
18. 前記検索抽出された各配送先のアドレスに対して、前記決定された配送順序を承諾するか否かの伺い情報を送信するステップと、
    前記伺い情報への応答として各配送先から送信される承諾情報を受信するステップと、
    前記受信された承諾情報に基づいて必要であれば前記配送順序を変更するステップと
    を含むことを特徴とする請求項１４ないし１７の何れか１項に記載の配送管理方法。
19. 前記関連部署データベースが、各自動車部品ごとに回収の要・不要に関する情報を記憶している場合、前記回収リクエストが受信されると、該回収リクエストに関連する自動車部品の回収の要・不要に関する情報を前記検索抽出のステップにおいて検索抽出し、該検索抽出された回収の要・不要に関する情報が回収不要を示しているか否かを判定するステップと、
    前記回収不要と判定された場合に、前記回収リクエストを送信してきた自動車販売会社の端末に対して回収不要を表す情報を送信するステップと
    をさらに含む請求項１４ないし請求項１８の何れか１項に記載の配送管理方法。
20. 前記回収不要と判定された場合に、前記回収不要の自動車部品の識別情報と対応付けて故障原因に関する情報を記憶する故障対応データベースから、前記故障原因に関する情報を検索抽出するステップと、
    前記回収リクエストを送信してきた前記自動車会社の端末に対して前記検索抽出された故障原因に関する情報を送信するステップと
    をさらに含む請求項１９に記載の配送管理方法。
21. 前記第２のアドレスは、前記故障した自動車部品の見取り評価を希望する関連部署のアドレスであり、前記見取り評価の関連部署の端末から送信された回答情報において指定されていた他の関連部署に該自動車部品が到着すると、前記配送完了情報送信のステップにおいて、該第２のアドレス宛に配送完了情報を送信することを特徴とする請求項１４ないし２０の何れか１項に記載の配送管理方法。
22. 検証結果が入力されると、前記故障した自動車部品の検証結果の送信宛先アドレスと該自動車部品の識別情報とを対応付けて記憶する検証担当データベースから、前記回収リストに関連する故障した自動車部品の識別情報に基づいて、対応する前記検証結果の送信宛先アドレスを検索抽出するステップと、
    前記検索抽出された前記検証結果の送信宛先アドレスに対し、前記入力された検証結果を送信するステップと
    をさらに含む請求項１４ないし２１の何れか１項に記載の配送管理方法。
23. 前記検索抽出ステップにより検索抽出された関連部署について、所定期間内又は所定回数にわたり同一又は類似の回収リクエストが受信された場合であって、該関連部署が案内情報及び回答情報の省略を選択している場合は、前記案内情報の送信をスキップさせ、前回の回答情報の内容を今回も利用するよう制御するステップをさらに含むことを特徴とする請求項１４ないし２２の何れか１項に記載の配送管理方法。
24. 前記回答情報を送信してきた関連部署が存在しなかった場合には、前記関連部署データベースに予め登録されているデフォルトの関連部署を配送先として設定するステップををさらに含む請求項１４ないし２３の何れか１項に記載の配送管理方法。
25. 前記案内情報を送信してからの経過時間を計時するステップと、
    所定の経過時間内に回答情報を送信してきた関連部署に限って前記配送順序定のステップにおいて配送順序を決定させ、一方、前記所定の経過時間から遅れて回答情報を送信してきた関連部署については前記配送順序の最後に追加するよう制御するステップと
    をさらに含む請求項１４ないし２４の何れか１項に記載の配送管理方法。
26. 前記自動車部品ごとの大きさ及び質量に関する情報を記憶した部品データベースをさらに備え、
    前記配送リクエスト送信ステップは、配送対象となっている前記故障した自動車部品について前記部品データベースから読み出された大きさ及び質量に関する情報とともに、前記配送リクエストを前記物流担当の端末に送信することを特徴とする請求項１４ないし２５の何れか１項に記載の配送管理方法。
27. 請求項１４ないし２６の何れか１項に記載の配送管理方法の各ステップをコンピュータにおいて実行させるためのコンピュータプログラム。

Images