(57)【特許請求の範囲】
【請求項１】
部品を発注する複数の拠点に対応する複数の端末装置と、
前記複数の拠点からの発注に応答して前記複数の拠点に部品を発送する管理拠点に対応する処理装置とを備えたバックオーダー処理システムであって、
前記複数の端末装置の各々は、
前記複数の拠点のうちの前記各々に対応する拠点が１台の車両を修理するときに使用される発注部品の部品数を指定する修理情報を前記処置装置に送る発注部を備え、
前記処理装置は、
在庫部品の在庫数を記憶する記憶部と、
前記複数の端末装置から送られてくる複数の修理情報がそれぞれ示す部品数の合計が前記在庫数より大きいときに、前記複数の修理情報のうちの部品数が少ない修理情報から優先した順位で前記在庫部品を割り振り、前記複数の拠点のうちの前記在庫部品が割り振られた修理情報を送った拠点を前記在庫部品の発送先としてメモリに登録する演算部とを備えた
バックオーダー処理システム。
【請求項２】
前記発注部は、前記修理情報に、更に修理完了要求日を含めて前記処理装置に送り、
前記演算部は、前記複数の修理情報のうちの前記修理完了要求日の早い修理情報から優先した順位で前記在庫部品を割り振り、前記修理完了要求日が同一の場合は、前記修理完了要求日が同一である複数の修理情報のうちの部品数が少ない修理情報から順番に前記在庫部品を割り振る
請求項１に記載のバックオーダー処理システム。
【請求項３】
前記発注部は、前記修理情報に、更に修理予定日を含めて前記処理装置に送り、
前記演算部は、部品数が競合した場合に、前記競合した複数の修理情報のうちの前記修理予定日の早い修理情報から優先した順位で前記在庫部品を割り振る
請求項１又は２に記載のバックオーダー処理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、バックオーダー処理システムに関し、特に在庫数が限られている部品を最適に配分する技術に関する。
【０００２】
【従来の技術】
従来、車両の保守のために使用される部品やアクセサリ部品を管理するパーツシステムが知られている。このようなパーツシステムは、或る地域の複数のディーラーの各々に設置されるものの他に、その地域を統括して管理する管理拠点に設置されるものがある。
【０００３】
各ディーラーに設置されるパーツシステムは、自己が保有するパーツの在庫を管理し、点検や整備を行うサービス部門からの要求に応じて部品を払い出す。このパーツシステムは、部品の在庫が不足する場合は、管理拠点のパーツシステムに部品を発注し、常に適正な在庫数になるように管理する。
【０００４】
一方、管理拠点に設置されるパーツシステムは、複数のディーラーからの要求に応じて部品を出荷する。なお、管理拠点に設置されるパーツシステムで部品の在庫数が不足する場合はメーカーに発注する。このように、拠点→管理拠点→メーカーといった具合に、順次後方へ発注を行うことをバックオーダーという。
【０００５】
ところで、このパーツシステムでは、複数のディーラーから部品の出荷要求があった場合に、要求された全部品の在庫がある場合は問題ないが、在庫が不足する場合に、何れのディーラーに部品を割り振るかが問題になる。このような場合における従来の処理方法を説明する。
【０００６】
図１１は、修理完了要求日として５月１０日を指定してきた顧客の車両の修理を行うために、５箇所のディーラー１〜５（以下、「拠点１〜５」という）から管理拠点に部品の発注がある例を示している。
【０００７】
拠点１では、１人の顧客の車両の修理予定日は４月３０日であるが１個の部品ａ及び１個の部品ｂが不足し、他の１人の顧客の車両の修理予定日は４月２８日であるが２個の部品ａ及び１個の部品ｂが不足する。従って、拠点１では３個の部品ａと２個の部品ｂを管理拠点に発注する。
【０００８】
拠点２では、１人の顧客の車両の修理予定日は５月９日であるが２個の部品ａが不足し、他の１人の顧客の車両の修理予定日は５月１日であるが２個の部品ｂが不足する。従って、拠点２では２個の部品ａと２個の部品ｂを管理拠点に発注する。
【０００９】
拠点３では、１人の顧客の車両の修理予定日は４月２７日であるが１個の部品ａ及び１個の部品ｂが不足し、他の１人の顧客の車両の修理予定日は４月３０日であるが１個の部品ａが不足する。従って、拠点３では２個の部品ａと１個の部品ｂを管理拠点に発注する。
【００１０】
拠点４では、１人の顧客の車両の修理予定日は５月５日であるが２個の部品ａが不足し、他の１人の顧客の車両の修理予定日は５月２日であるが１個の部品ａが不足する。従って、拠点４では３個の部品ａを管理拠点に発注する。
【００１１】
拠点５では、１人の顧客の車両の修理予定日は５月７日であるが１個の部品ａ及び１個の部品ｂが不足し、他の１人の顧客の車両の修理予定日は５月４日であるが１個の部品ｂが不足する。従って、拠点５では１個の部品ａと２個の部品ｂを管理拠点に発注する。
【００１２】
このような発注を受けた管理拠点では、１１個の部品ａと７個の部品ｂとが必要になるが、７個の部品ａと４個の部品ｂの在庫しかないと仮定する。この場合、従来の管理拠点では、次のような方法で部品を各拠点に割り振って発送している。
【００１３】
第１の方法は、図１２に示すように、単純に、拠点１から順番に部品を各拠点に割り振る方法である。この例では、拠点１に３個の部品ａと２個の部品ｂが発送され、拠点２に２個の部品ａと２個の部品ｂが発送され、拠点３に２個の部品ａが発送される。
【００１４】
従って、図１２で丸印を付した５人の顧客の車両、即ち、拠点１の２人の顧客の車両、拠点２の２人の顧客の車両及び拠点３の１人の顧客の車両の修理が可能になる。一方、拠点３の１人の顧客の車両、拠点４の２人の顧客の車両及び拠点５の２人の顧客の車両の修理は不可能である。この場合、１個の部品ａが管理拠点で余ることになる。
【００１５】
第２の方法は、図１３に示すように、各拠点における修理予定日が早いものから順番に部品を割り振る方法である。この例では、最も早い修理予定日（４月２７日）を含む拠点３に２個の部品ａと１個の部品ｂが発送され、次に早い修理予定日（４月２８日）を含む拠点１に３個の部品ａと２個の部品ｂが発送され、次に早い修理予定日（５月１日）を含む拠点２に１個の部品ｂが発送され、次に早い修理予定日（５月２日）を含む拠点４に２個の部品ａが発送される。
【００１６】
従って、図１３で丸印を付した５人の顧客の車両、即ち、拠点１の２人の顧客の車両、拠点３の２人の顧客の車両及び拠点４の１人の顧客の車両の修理が可能になる。一方、拠点２の２人の顧客の車両、拠点４の１人の顧客の車両及び拠点５の２人の顧客の車両の修理は不可能である。この場合、拠点２では１個の部品ｂが入荷するが顧客の車両を修理するには不足し、拠点３では２個の部品ａが入荷するので１人の顧客の車両を修理できるが、他の１人の顧客の車両を修理するには不足である。
【００１７】
【発明が解決しようとする課題】
上述した第１の方法では、単純に、所定の拠点から順番に部品を割り振るだけであるので、部品の必要の度合いは考慮されておらず、限られた数の部品が必ずしも最適に割り振られているとはいえない。また、部品が不足しているにも拘わらず不使用部品が出るといった場合が発生し、限られた数の部品で最大数の顧客の車両を修理することはできない。
【００１８】
また、上述した第２の方法では、修理予定日の順番で部品を割り振るが、部品の必要度合いは考慮されておらず、限られた数の部品が必ずしも最適に割り振られているとはいえない。また、上記第１の方法と同様に、限られた数の部品で最大数の顧客の車両を修理することはできない。
【００１９】
本発明は、上述した従来の問題点を解消するためになされたものであり、その目的は、部品の必要の度合いを考慮して最適な部品の割り振りができるとともに、限られた数の部品で最大数の顧客の車両を修理できるように部品を割り振ることのできるバックオーダー処理システムを提供することにある。
【００２０】
【課題を解決するための手段】
本発明に係るバックオーダー処理システムは、上記目的を達成するために、部品を発注する複数の拠点と、前記複数の拠点からの発注に応答して前記複数の拠点に部品を発送する管理拠点、とを備えたバックオーダー処理システムであって、前記複数の拠点の各々は、発注する部品及び該部品が使用される車両を指定する修理情報を前記管理拠点に送ることにより部品を発注する発注部、を備え、前記管理拠点は、部品の在庫数を記憶する記憶部と、前記複数の拠点から送られてくる前記修理情報に基づいて、前記記憶部に記憶された部品の在庫数で修理できる前記車両の数が最大になるように、在庫している部品を、部品を発注した拠点に割り振る演算部と、前記演算部で部品が割り振られた拠点を部品の発送先に決定する発送先決定部、とを備えている。
【００２１】
このバックオーダー処理システムによれば、管理拠点では、車両毎の必要部品数を把握することができるので、在庫している部品数で修理できる車両の数が最大になるように、在庫している部品を、部品を発注した拠点に割り振ることが可能になる。従って、限られた部品の在庫数で修理できる車両の数を最大にできるので、全体として顧客の満足度を向上させることができる。
【００２２】
この発明に係るバックオーダー処理システムにおける前記発注部は、前記修理情報に、更に修理完了要求日を含めて前記管理拠点に送り、前記発送先決定部は、前記修理完了要求日の早い車両を有する拠点から順番に発送先を決定し、前記修理完了要求日が同一の場合は、前記演算部で部品が割り振られた拠点を部品の発送先に決定するように構成できる。
【００２３】
また、この発明に係るバックオーダー処理システムにおける前記発注部は、前記修理情報に、更に修理予定日を含めて前記管理拠点に送り、前記発送先決定部は、前記演算部で部品が割り振られた拠点を部品の発送先に決定し、前記演算部による割り振りが競合した場合に、前記修理予定日の早い車両を有する拠点から順番に発送先を決定するように構成できる。
【００２４】
更に、この発明に係るバックオーダー処理システムにおける前記発注部は、前記修理情報に、更に顧客のクラスを表す情報を含めて前記管理拠点に送り、前記発送先決定部は、前記演算部で部品が割り振られた拠点を部品の発送先に決定し、前記演算部による割り振りが競合した場合に、前記クラスの高い顧客の車両を有する拠点から順番に発送先を決定するように構成できる。
【００２５】
【発明の実施の形態】
以下、本発明の実施の形態に係るバックオーダー処理システムを図面を参照しながら詳細に説明する。
【００２６】
図１は、このバックオーダー処理システムの構成を示す図である。このバックオーダー処理システムは、処理装置１０、データベース１１及び端末装置２０1〜２０5から構成されている。処理装置１０と端末装置２０1〜２０5との間は回線３０1〜３０5でそれぞれ接続されている。なお、この実施の形態では、処理装置１０に５台の端末装置が接続される例を示しているが、端末装置の数は５台に限定されず任意である。
【００２７】
処理装置１０は、本発明の管理拠点に対応する。また、本発明の演算部及び発送先決定部は、この処理装置１０の処理により構成される。管理拠点は、例えば或る領域内の複数のディーラーを統括する現地法人である。この処理装置１０は、例えばパーソナルコンピュータ、ワークステーション、汎用コンピュータといった情報処理装置から構成されており、当該バックオーダー処理システムを統括的に制御する。
【００２８】
データベース１１は、本発明の記憶部に対応する。このデータベース１１は、例えばディスク装置から構成され、処理装置１０に接続されている。このデータベース１１は、管理拠点における部品の在庫数を記憶する。
【００２９】
端末装置２０1〜２０5（以下、符号２０で代表する）は、本発明の複数の拠点に対応する。本発明の発注部は、この端末装置２０の処理により構成される。複数の拠点は、例えば或る領域内に配置された複数のディーラーである。各端末装置２０は、例えばパーソナルコンピュータ、ワークステーション、汎用コンピュータといった情報処理装置から構成されている。
【００３０】
端末装置２０には、図示しないデータベースを備えている。このデータベースは、ディーラーで管理している部品の在庫数を記憶する。各ディーラーは、このデータベースで管理される部品の在庫が不足する場合に、管理拠点である処理装置１０に部品を発注する。
【００３１】
このバックオーダー処理システムでは、複数の拠点から管理拠点に部品の発注がなされたときに、管理拠点での在庫が不足する場合は、以下で説明する優先順位に従って各拠点への部品の割り振りがなされる。
【００３２】
図２は、このバックオーダー処理システムで採用されている優先順位を示す。この優先順位は、最も高い「１」から最も低い「６」までの６段階に分けられている。具体的には、優先順位が最も高いものから順番に、「受注区分」、「修理完了要求日」、「数量」、「修理予定日」、「発注の種類」、「顧客管理」に分けられている。この優先順位を表す情報は、複数の拠点から管理拠点に部品を発注する際に、各拠点から管理拠点に送られる修理情報に含まれる。
【００３３】
優先順位１の「受注区分」は、図３に示すように、「ホットライン」、「ＦＯＣ（緊急）」、「緊急オーダー」、「ＦＯＣ（定期）」及び「定期オーダー」といった５項目から構成されており、各項目毎に更に優先順位が付されている。具体的には、「ホットライン」に優先順位１、「ＦＯＣ（緊急）」に優先順位２、「緊急オーダー」に優先順位３、「ＦＯＣ（定期）」に優先順位４及び「定期オーダー」に優先順位５が割り当てられている。
【００３４】
受注区分に含まれる「ホットライン」は、車両が動かなくなった場合のオーダーを表す。「ＦＯＣ（緊急）」は、販売した部品が不良を起こしてしまい、無料で交換する場合のオーダーを表す。「緊急オーダー」は、顧客の注文がついているオーダーを表す。「ＦＯＣ（定期）」は、部品不良を起こしてしまい、無料で交換する場合であって、顧客がついていない場合のオーダーを表す。「定期オーダー」は、在庫補充等のオーダーを表す。なお、ＦＯＣ（Free Of Charge）は、無償で部品を顧客に提供することを表す。
【００３５】
優先順位２の「修理完了要求日」は、顧客が車両の修理完了を希望する日であり、点検・整備の受付時に顧客から指定される。
【００３６】
優先順位３の「数量」は、発注する部品の数であり、後に詳述するように、修理に必要とする部品数が少ない車両を所有する顧客（修理依頼人）から優先的に部品が割り振られる。
【００３７】
優先順位４の「修理予定日」は、修理依頼を受け付けた車両をディーラーで修理する予定の日であり、各ディーラーにおいて、該ディーラーの作業スケジュールに基づいて決定される。
【００３８】
優先順位５の「発注の種類」は、図４に示すように、「納車前点検」、「定期点検」、「一般修理」及び「板金／塗装」といった４項目から構成されており、各項目毎に更に優先順位が付されている。具体的には、「納車前点検」に優先順位１、「定期点検」に優先順位２、「一般修理」に優先順位３及び「板金／塗装」に優先順位４がそれぞれ割り当てられている。
【００３９】
優先順位６の「顧客管理」は、ＶＩＰＸ−ＡＢＣＤマトリックス法で採用されるクラスに優先順位が付けられている。ここで、ＶＩＰＸ−ＡＢＣＤマトリックス法を説明する。このＶＩＰＸ−ＡＢＣＤトリックス法では、図５に示すような、層別管理表が使用される。この層別管理表において、縦軸のＶＩＰＸは販売台数による管理、横軸のＡＢＣＤは販売店訪問回数による管理がそれぞれ行われることを表している。この層別管理表は、ディーラー側から見れば、ＶＩＰＸはセールスという観点から見た層別区分、ＡＢＣＤはサービスという観点から見た層別区分ということができる。
【００４０】
ここで、「Ｖ」は当該ディーラーが取り扱うメーカーの車両を２台以上所有している顧客の数を表す。「Ｉ」は他メーカーの複数の車両の一部を当該ディーラーが取り扱うメーカーの車両に代替し、他メーカーの車両とを合わせて２台以上所有している顧客の数を表す。「Ｐ」は１台の新車を所有する顧客の数を表す。「Ｘ」はサービスを受けるためにのみ訪れる顧客の数を表す。
【００４１】
また、「Ａ」は１年に４回以上当該ディーラーを訪れる顧客の数を表す。「Ｂ」は１年に２〜３回当該ディーラーを訪れる顧客の数を表す。「Ｃ」は１年に１回だけ当該ディーラーを訪れる顧客の数を表す。「Ｄ」は数年に１回だけ当該ディーラーを訪れる顧客の数を表す。
【００４２】
この層別管理表を参照することにより、当該ディーラーの営業上の最重要顧客であるＶＡクラスから、その対極にあるＸＤクラスまでの顧客の分布を一見して認識することができる。この層別管理表は、例えば以下のような顧客管理に利用することができる。
【００４３】
即ち、ＸＤクラスに属する顧客、即ちサービスを目的とする顧客が圧倒的に多ければ、当該ディーラーは、収益性に問題があると分析することができる。また、この層別管理表を見れば顧客分布が明らかであるので、車両販売の営業において、顧客が属するクラスに応じたアプローチをとるために使用できる。
【００４４】
この「顧客管理」は、図５に示すように、ＶＡクラスに優先順位１、ＶＢ、ＩＡ及びＩＢに優先順位２、ＶＣ、ＩＣ、ＰＡ、ＰＢ及びＰＣに優先順位３、ＶＤ、ＩＤ、ＰＤ、ＸＡ、ＸＢ及びＸＣに優先順位４、並びにＸＤに優先順位５がそれぞれ割り当てられている。なお、優先順位の割り当ては上記に限定されず、任意である。
【００４５】
次に、上記のように構成される本発明のバックオーダー処理システムの動作を図６〜図９に示したフローチャートを参照しながら説明する。
【００４６】
先ず、複数の拠点である端末装置２０の動作を、図６に示したフローチャートを参照しながら説明する。
【００４７】
ディーラー（拠点）に車両の修理依頼があると、修理情報が端末装置２０に入力される（ステップＳ１）。ここで、入力される修理情報には、顧客の名前、車種、修理内容、修理に必要な部品を指定する情報、優先順位（受注区分、発注の種類及び顧客管理の場合は更にそれらの中の優先順位）、数量、修理完了要求日、修理予定日等が含まれる。
【００４８】
次いで、端末装置２０に接続されたデータベース（図示しない）を参照することにより、入力された修理情報によって指定される部品の在庫があるかどうかが調べられる（ステップＳ２）。ここで、在庫があることが判断されると、部品を発注する必要がないので、拠点における処理を終了する。
【００４９】
一方、上記ステップＳ２で、在庫がないことが判断されると、管理拠点に部品を発注するための発注処理が行われる（ステップＳ３）。次いで、修理情報を送信する処理が行われる（ステップＳ４）。本発明の発注部は、このステップＳ３及びＳ４の処理により実現されている。以上により、各拠点から管理拠点への部品の発注が完了する。
【００５０】
以下では、この実施の形態の動作の理解を深めるために、具体的な数値を用いた例を併記しながら説明する。今、管理拠点では、データベース１１に７個の部品ａと４個の部品ｂの在庫があることが記憶されているものとする。また、各拠点では、従来の技術の欄で説明した場合と同様の部品の発注が行われるものとする。
【００５１】
即ち、拠点１では、１人の顧客の車両の修理予定日は４月３０日であるが１個の部品ａ及び１個の部品ｂが不足し、他の１人の顧客の車両の修理予定日は４月３０日であるが２個の部品ａ及び１個の部品ｂが不足する。従って、拠点１では３個の部品ａと２個の部品ｂを管理拠点に発注する。
【００５２】
拠点２では、１人の顧客の車両の修理予定日は５月９日であるが２個の部品ａが不足し、他の１人の顧客の車両の修理予定日は５月１日であるが２個の部品ｂが不足する。従って、拠点２では２個の部品ａと２個の部品ｂを管理拠点に発注する。
【００５３】
拠点３では、１人の顧客の車両の修理予定日は４月２７日であるが１個の部品ａ及び１個の部品ｂが不足し、他の１人の顧客の車両の修理予定日は４月３０日であるが１個の部品ａが不足する。従って、拠点３では２個の部品ａと１個の部品ｂを管理拠点に発注する。
【００５４】
拠点４では、１人の顧客の車両の修理予定日は５月５日であるが２個の部品ａが不足し、他の１人の顧客の車両の修理予定日は５月２日であるが１個の部品ａが不足する。従って、拠点４では３個の部品ａを管理拠点に発注する。
【００５５】
拠点５では、１人の顧客の車両の修理予定日は５月７日であるが１個の部品ａ及び１個の部品ｂが不足し、他の１人の顧客の車両の修理予定日は５月４日であるが１個の部品ｂが不足する。従って、拠点５では１個の部品ａと２個の部品ｂを管理拠点に発注する。
【００５６】
次に、管理拠点である処理装置１０の動作を、図７〜図９に示したフローチャートを参照しながら説明する。
【００５７】
処理装置１０は、先ず、各拠点の端末装置２０からの発注された部品の受注処理を行う（ステップＳ１０）。次いで、受注部品の集計処理を行う（ステップＳ１１）。この集計処理により、１１個の部品ａと７個の部品ｂとが必要であることが判明する。
【００５８】
次に、実際の部品の在庫数を確認し（ステップＳ１２）、受注した部品数が在庫数より大きいかどいうかが調べられる（ステップＳ１３）。ここで、受注した部品数が在庫数より大きくない、つまり受注した部品の全てを管理拠点に在庫する部品で賄うことができることが判断されると、部品が、部品を発注した拠点に発送される（ステップＳ１６）。これにより、管理拠点における処理が完了する。
【００５９】
一方、上記ステップＳ１３で、受注した部品数が在庫数より大きい、つまり受注した部品の全てを管理拠点に在庫する部品で賄うことができないことが判断されると、部品割り振り処理が行われる（ステップＳ１４）。この部品割り振り処理では、下述するように、データベース１１に記憶された部品の在庫数で修理できる車両の数が最大になるように、在庫している部品を、部品を発注した拠点に割り振る処理が行われる。
【００６０】
次いで、発送先決定処理が行われる（ステップＳ１５）。この発送先決定処理は、本発明の発送先決定部に対応する。その後、部品発送が行われる（ステップＳ１６）。以上により、管理拠点での処理が完了する。
【００６１】
次に、上記ステップＳ１４で行われる部品割り振り処理の詳細を、図８及び図９に示したフローチャートを参照しながら説明する。
【００６２】
この部品割り振り処理では、端末装置２０から受け取った修理情報に含まれる優先順位を参照し、「１」であるかどうか、即ち、受注区分が指定されているかどうかを調べる。そして、受注区分が指定されている場合は、受注区分内の優先順位に従って部品の割り振り処理が行われる。この処理の内容は、後述する、修理情報で優先順位３の数量が指定されている場合の処理と同じである。
【００６３】
修理情報で受注区分が指定されていない場合は、修理情報に含まれる修理完了要求日の早いものから順番に部品割り振りが行われる。以下、修理完了要求日が５月１０日に指定されている場合の例を説明する。
【００６４】
先ず、処理装置１０は、部品ａ又は部品ｂを１個だけ発注した顧客が含まれる拠点を検索する（ステップＳ２０）。これにより、１個の部品ａを発注した拠点３、１個の部品ａを発注した拠点４及び１個の部品ｂを発注した拠点５が検索される。次いで、在庫不足かどうかが調べられる（ステップＳ２１）。即ち、検索された拠点で必要な数の部品がデータベース１１に格納されている在庫数以下であるかどうかが調べられる。
【００６５】
ここで、在庫数不足でないことが判断されると、次いで、検索された拠点が発送先として、図示しないメモリに登録される（ステップＳ２２）。これにより、拠点３に部品ａを１個、拠点４に部品ａを１個、拠点５に部品ｂを１個発送するようにメモリに登録される。
【００６６】
次いで、データベース１１中の部品ａ及び部品ｂの在庫数が更新される（ステップＳ２３）。これにより、データベース１１に登録されている部品ａの数は５個、部品ｂの数は３個にそれぞれ変更される。
【００６７】
次いで、部品ａ及び部品ｂをそれぞれ１個発注した顧客が含まれる拠点が検索される（ステップＳ２４）。これにより、部品ａ及び部品ｂをそれぞれ１個発注した拠点１、拠点３及び拠点５が検索される。次いで、在庫不足かどうかが調べられる（ステップＳ２５）。即ち、検索された拠点で必要な数の部品がデータベース１１に格納されている在庫数以下であるかどうかが調べられる。
【００６８】
ここで、在庫数不足でないことが判断されると、次いで、検索された拠点が発送先として、図示しないメモリに登録される（ステップＳ２６）。これにより、拠点１、拠点３及び拠点４に１個の部品ａと１個の部品ｂを発送するようにメモリに登録される。
【００６９】
次いで、データベース１１中の部品ａ及び部品ｂの在庫数が更新される（ステップＳ２７）。これにより、データベース１１に登録されている部品ａの数は２個、部品ｂの数は０個にそれぞれ変更される。なお、図示は省略しているが、上記ステップＳ２４〜Ｓ２７の処理は、部品ａ及び部品ｂの何れかの在庫がゼロになるまで繰り返される。
【００７０】
次いで、部品ａを２個又は部品ｂを２個発注した顧客が含まれる拠点が検索される（ステップＳ２８）。これにより、部品ａを２個及び部品ｂを２個発注した拠点２、部品ａを２個発注した拠点４が検索される。次いで、在庫不足かどうかが調べられる（ステップＳ２９）。即ち、検索された拠点で必要な数の部品がデータベース１１に格納されている在庫数以下であるかどうかが調べられる。
【００７１】
ここで、在庫数不足でないことが判断されると、次いで、検索された拠点が発送先として、図示しないメモリに登録される（ステップＳ３０）が、在庫不足の場合は優先割り振り処理が行われる（ステップＳ３２）。この優先割り振り処理では、修理予定日が早い発注を行った拠点が発送先としてメモリに登録される。この場合、２個の部品ａが在庫しており、部品ａを２個必要とする拠点２と拠点４のうち、拠点４の修理予定日が５月５日であり拠点２の修理予定日５月９日より早いので、拠点４に２個の部品ａを発送するようにメモリに登録される。
【００７２】
なお、この優先割り振り処理で、修理予定日が同日である場合は、優先順位５の「発注の種類」の優先順位に従ってメモリに登録する発送先の拠点が決定される。更に、発注の種類の優先順位も同一である場合は、優先順位６の「顧客管理」の優先順位に従ってメモリに登録する発送先の拠点が決定される。
【００７３】
次いで、データベース１１中の部品ａ及び部品ｂの在庫数が更新される（ステップＳ３１）。これにより、データベース１１に登録されている部品ａ及び部品ｂの数は双方とも０個にそれぞれ変更される。その後、図７に示した管理拠点における処理のステップＳ１５に戻る。
【００７４】
上記ステップＳ２１及びステップＳ２５で在庫不足と判断された場合も、上述した優先割り振り処理が実行される。その結果、図１０に示すように、拠点１に部品ａが１個と部品ｂが１個発送され、拠点３に部品ａが２個と部品ｂが１個発送され、拠点４に部品ａが３個発送され、拠点５に部品ａが１個と部品ｂが２個発送されることになる。以上により、部品割り振り処理が終了する。
【００７５】
以上説明したように、この実施の形態に係るバックオーダー処理システムによれば、管理拠点に在庫がある７個の部品ａと４個の部品ｂで、図１０の丸印で示すように、７人の顧客の車両の修理が可能になり、限られた部品の在庫数で修理できる車両の数を最大にできる。これに対し、従来の技術では、図１２及び図１３を参照して説明したように、５人の顧客の車両の修理しかできないので、全体として顧客の満足度を向上させることができる。
【００７６】
また、この実施の形態に係るバックオーダー処理システムによれば、修理完了予定日を優先して部品を割り振るので、顧客に迷惑をかけることを減少できる。更に、修理完了予定日を考慮して部品を割り振るので、各拠点の負担も軽減される。
【００７７】
次に、この実施の形態に係るバックオーダー処理システムの変形例を説明する。この変形例に係るバックオーダー処理システムは、上述した優先割り振り処理において、修理予定日の代わりに、優先順位６の顧客管理における優先順位が使用される。より詳しくは、修理予定日が早い発注を行った拠点が発送先としてメモリに登録される代わりに、顧客管理における優先順位が高いクラスの顧客の車両に使用される部品の発注を行った拠点が発送先としてメモリに登録される。
【００７８】
なお、修理予定日の代わりに、優先順位５の発注の種類の優先順位を使用することもできる。この場合、発注の種類の優先順位が同一である場合は、顧客管理の優先順位に従ってメモリに登録する発送先の拠点を決定することができる。
【００７９】
以上の説明では、本発明の１つの実施の形態として、拠点の数が「５」であり、発注される部品が２種類であり、更に顧客の車両の修理に必要な部品の最大数を「２」とした場合の例について説明したが、本発明は上述した場合に限らない。部品割り振り処理において、部品数の少ない顧客の車両から順番に部品を割り振っていくことにより、修理できる顧客の車両が最大になるような部品の割り振りが可能である。
【００８０】
【発明の効果】
以上詳述したように、本発明によれば、部品の必要の度合いを考慮して最適な部品の割り振りができるとともに、限られた数の部品で最大数の顧客の車両を修理できるように部品を割り振ることのできるバックオーダー処理システムを提供提供できる。
【図面の簡単な説明】
【図１】本発明の実施の形態に係るバックオーダー処理システムの概略構成を示す図である。
【図２】本発明の実施の形態に係るバックオーダー処理システムで使用される部品割り振りの優先順位を説明するための図である。
【図３】図２における受注区分内の優先順位を説明するための図である。
【図４】図２における発注の種類内の優先順位を説明するための図である。
【図５】図２における顧客管理内の優先順位を説明するための図である。
【図６】本発明の実施の形態に係るバックオーダー処理システムの拠点における処理を示すフローチャートである。
【図７】本発明の実施の形態に係るバックオーダー処理システムの管轄拠点における処理を示すフローチャートである。
【図８】図７における部品割り振り処理の詳細（その１）を示すフローチャートである。
【図９】図７における部品割り振り処理の詳細（その２）を示すフローチャートである。
【図１０】本発明の実施の形態に係るバックオーダー処理システムの動作を説明するための図である。
【図１１】従来のバックオーダー処理を説明するための図である。
【図１２】従来のバックオーダー処理において拠点順に部品を割り振る場合の例を説明するための図である。
【図１３】従来のバックオーダー処理において修理予定日順に部品を割り振る場合の例を説明するための図である。
【符号の説明】
１０  処理装置
１１  データベース
２０（２０1〜２０5）  端末装置
３０1〜３０5  回線
【図１】
0003992133.tif 000002
【図２】
0003992133.tif 000003
【図３】
0003992133.tif 000004
【図４】
0003992133.tif 000005
【図５】
0003992133.tif 000006
【図６】
0003992133.tif 000007
【図７】
0003992133.tif 000008
【図８】
0003992133.tif 000009
【図９】
0003992133.tif 000010
【図１０】
0003992133.tif 000011
【図１１】
0003992133.tif 000012
【図１２】
0003992133.tif 000013
【図１３】
0003992133.tif 000014