JP2002002925A

JP2002002925A - 配送システム

Info

Publication number: JP2002002925A
Application number: JP2000194009A
Authority: JP
Inventors: Akihiro Nishimura; 明弘西村; Masayoshi Ida; 昌佳井田
Original assignee: Advance KK
Current assignee: Advance KK
Priority date: 2000-06-28
Filing date: 2000-06-28
Publication date: 2002-01-09

Abstract

(57)【要約】【課題】ユーザー側で商品の不足が生じないようにし
ながら、商品の配送回数を少なくすることができる配送
システムを提供すること。【解決手段】管理コンピュータ１には、記憶部３と演
算部４とを備え、記憶部３には、ユーザーごとの消費商
品と、上記商品ごとの適正在庫量と、上記商品ごとの配
送必要時点での在庫量とを記憶し、演算部４では、上記
商品ごとに、上記適正在庫量と上記配送必要時点での在
庫量との差として配送量を算出する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ユーザーに商品
を届けるための、配送システムに関する。

【０００２】

【従来の技術】例えば、文具や、トナーなどのＯＡサプ
ライ品と日用雑貨など、多数の種類の商品を扱っている
業者は、商品をユーザーへ配達する場合に、ユーザーか
らの注文があるたびに、商品を配達するようにしてい
る。また、ユーザーは、個々の商品が無くなりそうにな
った時点で、それぞれの商品について数量を指定して発
注をする。例えば、ある商品の在庫が無くなりそうにな
ると、たとえ他の商品がたくさんあったとしても、無く
なりそうな商品を個別に発注する。業者側は、発注を受
けるとできるだけ早く、その商品を配送するようにして
いる。このように、ユーザーは、商品の在庫を個別に管
理し、それらが無くなりそうになったとき、個別に発注
するとともに、業者もユーザー側の注文に応えるように
して、その都度、何回も配送を繰り返していた。

【０００３】

【発明が解決しようとする課題】上記のようなオフィス
用品など多くの種類の商品の中には、消費速度が異なる
ものがほとんどである。そのために、各商品が無くなり
そうになる時期が異なるので、ユーザーが各商品を発注
するタイミングも異なる。しかも、同じ商品でも、残量
がどのくらいになったときに発注するのかということを
きちんと決めていない場合が、ほとんどである。そのう
え、１回の発注で、どれだけの数量を発注するかも決ま
っていない。つまり、発注タイミングや、発注数量は、
発注担当者の感覚で決められている場合が多い。そのた
め、発注タイミングがさらにばらついてしまうのが現実
であった。

【０００４】業者は、上記のようなバラバラの発注タイ
ミングに合わせて、商品を配送していたので、どうして
も配送回数が多くなり、その分、手間も経費もかかって
しまうという問題があった。また、ユーザー側は、しょ
っちゅう発注しなければならない上、いろいろな商品が
頻繁に配送されるので、その受け取りが面倒であるとい
う問題もあった。しかも、同じ商品でも、発注担当者の
気まぐれで、発注間隔がばらついてしまうことも多く、
業者側が発注を予測することは難しかった。そこで、い
つ発注があっても必要量を配送できるように準備してお
くため、業者側が余分の在庫を持たなければならないと
いう問題もあった。

【０００５】そこで、この発明の目的は、ユーザー側で
商品の不足が生じないようにしながら、商品の配送回数
を少なくすることができる配送システムを提供すること
である。また、別の目的は、配送日や、配送量などを予
測して、配送スケジュールを立てることができる配送シ
ステムを提供することである。

【０００６】

【課題を解決するための手段】第１の発明は、管理コン
ピュータには、記憶部と演算部とを備え、記憶部には、
ユーザーごとの消費商品と、上記商品ごとの適正在庫量
と、上記商品ごとの配送必要時点での在庫量とを記憶
し、演算部では、上記商品ごとに、上記適正在庫量と上
記配送必要時点での在庫量との差として配送量を算出す
る点に特徴を有する。第２の発明は、上記第１の発明を
前提とし、記憶部は、ユーザの購買履歴情報に基づいて
決めた予測消費速度を記憶し、演算部は、上記予測消費
速度と適正在庫量とから、配送必要時点での在庫量を演
算し、それに基づいて配送量を算出する点に特徴を有す
る。

【０００７】第３の発明は、第１の発明を前提とし、配
送必要時点での、実測した在庫量を基に、配送量を算出
する点に特徴を有する。第４の発明は、上記第２の発明
を前提とし、予測消費速度から配送必要時点での在庫量
を推測し、この在庫量を実測した在庫量で修正する点に
特徴を有する。第５の発明は、上記１〜４の発明を前提
とし、記憶部に、ユーザーごとに、商品ごとの基準在庫
量を予め記憶させ、演算部は、基準商品の在庫量が上記
基準在庫量に達した時点を、配送必要時点とする点に特
徴を有する。

【０００８】第６の発明は、第１〜第５の発明を前提と
し、記憶部は、複数の商品の、それぞれの基準在庫量を
記憶し、演算部は、これら商品のうち、いずれか１つの
商品が、基準在庫量に達したときを配送必要時点とする
点に特徴を有する。

【０００９】第７の発明は、第２または第４の発明を前
提とし、記憶部は、継続的に入力される各ユーザーの購
買履歴を記憶し、演算部は、所定期間ごとに上記ユーザ
ーの購買履歴に基づいて、消費速度を演算し直し、この
消費速度データに基づいて、配送必要時点での在庫量を
算出する点に特徴を有する。第８の発明は、第１〜第４
の発明を前提とし、予め設定した配送サイクルを基にし
て配送必要時点を特定する点に特徴を有する。

【００１０】

【発明の実施の形態】図１〜図３に、この発明の第１実
施例を示す。第１実施例の配送システムは、図１に示す
ように管理コンピュータ１と、この管理コンピュータ１
に、通信ネットＩを介して複数接続されたユーザー側端
末２とによって成り立っている。上記管理コンピュータ
１には、データを記憶する記憶部３と、記憶したデータ
を処理する演算部４とを備えている。なお、上記管理コ
ンピュータ１は、商品の提供業者が管理するようにして
いる。この提供業者は、メーカーであっても小売り業者
であってもかまわないし、配送業者であってもかまわな
い。

【００１１】上記記憶部３には、ユーザーごとに、商品
と、商品ごとの適正在庫量と、発注点の在庫量とを記憶
している。上記適正在庫量とは、各ユーザーが、在庫と
して持つことができる最大の在庫量のことである。この
量は、商品ごとに、ユーザーの単位機関あたりの使用量
や、ユーザー側で商品をストックしておくスペースなど
を考慮して決めるようにしている。

【００１２】また、上記発注点の在庫量とは、新しい商
品を発注すべき時点での在庫量のことである。この量
は、その商品の在庫として、最低でもこれだけは持って
いたい量ということを基準にして決める。どの商品も、
残りが何日分あれば安心という基準で決めることもでき
るし、商品の使用状況などを考慮して、商品ごとに設定
しても良い。例えば、１日でも、その商品が切れたら困
るような商品の場合には、上記発注点の在庫量を多めに
設定し、２，３日なら無くてもかまわないような商品の
場合には、発注点の在庫量を少な目に設定することもで
きる。上記発注点在庫量が、この発明の基準在庫量にあ
たる。なお、上記適正在庫量および発注点在庫量は、数
量で表したり、何日分という日数で表したりできるが、
この第１実施例では、数量で表すことにする。

【００１３】上記記憶部３が記憶しているデータを、図
２の表に示す。すなわち、記憶部３は、商品ａ，ｂ，
ｃ，ｄ，・・・それぞれに、適正在庫量Ｎ１と、発注点
の在庫量Ｎ２と、を対応させて記憶している。これらの
適正在庫量Ｎ１および発注点における在庫量Ｎ２の数量
は、商品ごとに異なるものである。例えば、商品ａは、
適正在庫量Ｎ１が１２０個であり、これは、最大で１２
０個を在庫としてストックしておくということである。

【００１４】一方、発注点在庫量Ｎ２は、１２個であ
る。つまり、在庫量１２個が、発注するなどして、商品
ａを追加しようとする基準値である。なお、このシステ
ムで管理する商品ａ，ｂ，ｃ，ｄ，・・・は、ユーザー
が消費する全ての商品でなくてよい。ユーザーの消費量
が多い品目や、業者にとって主力の商品などを選択する
ことができる。例えば、ユーザーごとに、消費量の多い
品目を数品目〜１０品目くらい選んで、上記記憶部３に
記憶させてもよい。さらに、上記演算部４は、ユーザー
へ配達する各商品の配送量を算出する機能を備えてい
る。具体的には、上記演算部４は、上記適正在庫量と、
配送時点で、ユーザー側に残っている在庫量とから、配
送すべき個数を算出する。

【００１５】このようなシステムにおいて、上記演算部
が、配送量を算出して、商品を配送するまでを、図３の
フローチャートにしたがって以下に説明する。まず、こ
のシステムを導入する際には、ステップ１で、商品ａ，
ｂ，ｃ，ｄ，・・・を、上記適正在庫量Ｎ１に揃えてお
く。ステップ２では、各商品の現時点での現在庫量Ｎ
を、上記記憶部３へ入力する。この第１実施例では、各
商品の現在庫量Ｎをユーザー側で計数して、ユーザー端
末２から業者側の管理コンピュータ１へ送信している。

【００１６】ステップ３では、上記現時点での現在庫量
Ｎと発注点在庫量Ｎ２とを比較する。図３のフローでは
表していないが、ここでは各商品ごとに、現在庫量Ｎと
発注点在庫量Ｎ２との比較を行う。そして、現在庫量Ｎ
が発注点在庫量Ｎ２以下の商品が１つでもあれば、ステ
ップ４に進む。ステップ４では、全商品について、それ
ぞれの配送量ｎとして｛適正在庫量Ｎ１−現在庫量Ｎ｝
を算出する。つまり、各商品とも、適正在庫量Ｎ１から
消費した分を、配送量ｎとする。ステップ５では、上記
算出した配送量ｎに基づいて、全商品を配送する。これ
により、ユーザー側の在庫は、全ての商品が適正在庫量
に揃い、ステップ１の状態になる。

【００１７】上記のようなシステムにおいては、管理コ
ンピュータ１が、ユーザーが消費する複数の商品を管理
し、それらの商品のうち、１つでも発注点在庫量Ｎ２に
達した場合には、全ての商品を同時に配送するようにし
ている。つまり、上記ステップ４で、いずれかの商品の
現在庫量Ｎが発注点在庫量Ｎ２に達したときが、この発
明の配送必要時点である。そして、商品の消費速度がバ
ラバラなので、上記配送必要時点では、現在庫量Ｎが発
注点在庫量Ｎ２に達していない商品があることもある。
しかし、配送時には、発注点在庫量Ｎ２に達していない
商品も同時に配送し、全ての商品野在庫を適正在庫量Ｎ
１に揃えようにしている。

【００１８】例えば、商品ａが発注点在庫量Ｎ２に達し
た時点で、商品ｂの現在庫量Ｎが発注点在庫量Ｎ２に近
い量であったとしても、従来のように商品ａだけを配送
した場合には、次に、すぐに商品ｂが発注点在庫量Ｎ２
になる。商品ｂが発注点在庫量Ｎ２になった時点で、今
度は、商品ｂを配達しなければならない、しかし、この
システムでは、商品ａの配達時に、全ての商品が、適正
在庫Ｎ１になるので、次の配送時期を大幅に遅らせるこ
とができる。つまり、各商品が、バラバラに発注点在庫
量Ｎ２に達するたびに配送しなければならない従来と比
べて、配送回数を減らすことができる。そのため、業者
側は、配送にかかるコストを節約することができるし、
ユーザー側は、商品受け取りの手間を少なくすることが
できる。

【００１９】また、上記第１実施例では、各商品の現在
庫量Ｎをユーザーが調べて、端末２からコンピューター
システム１へ送信するようにしているが、業者側の人が
在庫量を調べて、上記管理コンピュータ１の記憶部３に
入力してもかまわない。そのようにすれば、ユーザー
は、在庫管理も不要になる。なお、全商品の現在庫量Ｎ
を正確に計数しなくても、最も消費量が多くて、発注点
在庫量Ｎ２に近そうな商品の現在庫量Ｎだけを調査し
て、そのデータを上記管理コンピュータ１へ送信するよ
うにしても良い。その場合には、業者は、在庫量データ
の送信されなかった商品については、多めに準備して配
送し、配達時点で、全商品の在庫を適正在庫量Ｎ１に合
わせることができる。このようにすれば、ユーザーの在
庫チェックの手間が楽になる。

【００２０】また、上記のように、ユーザー側の在庫量
データを、管理コンピュータ１に常時入力しなくても、
ユーザーは、特定の商品が発注点在庫量Ｎ２に達したと
判断した時点で、従来のように発注してもかまわない。
その場合にも、業者側は、全商品を適正在庫量Ｎ１にで
きる量の商品を準備して配送すれば良い。

【００２１】図４〜図８に示す第２実施例では、管理コ
ンピュータ１が、ユーザーの消費速度を予測して、タイ
ミング良く商品を配送するようにした点が、上記第１実
施例と異なる。システムの構成は、図１に示す第１実施
例と同様である。ただし、上記管理コンピュータ１の記
憶部３には、ユーザーの購買履歴データが記憶されてい
る。この購買履歴データに基づいて、上記演算部４が、
特定のユーザーの、特定の商品の消費速度を予測するこ
とができる。この第２実施例のシステムの作用は、商品
ごとの予測消費速度から、各時点での、現在庫量Ｎを算
出し、さらに、予測した現在庫量Ｎから、配送必要時点
を特定するというものである。また、ユーザー端末２に
は、各商品の現在庫量Ｎを、後で説明する図５〜図８に
示すグラフや表によって、表示するようにしている。

【００２２】以下に、この第２実施例のシステムの作用
を、図４のフローチャートにしたがって具体的に説明す
る。まず、ステップ１１で、記憶部３に記憶されている
購買履歴データから、商品ごとの消費速度Ａを予測す
る。ここで、消費速度Ａを予測する商品の品目は、上記
第１実施例の場合と同様に、そのユーザーにとって、重
要であったり、消費量が多かったりするものの中から選
んだ商品である。また、上記購買履歴データから算出す
る消費速度Ａは、前年の年間の消費速度を基にし、その
値に、季節要因などに関する係数を乗じたものである。

【００２３】例えば、清涼飲料は、冬場より夏場の消費
量の多いので、夏場の消費速度を、冬場よりも大きくし
なければならない。このような商品の場合には、消費速
度を算出する際に、平均的な消費速度に、夏場は冬場よ
りも大きな係数を乗じるようにしている。また、ユーザ
ーの事業形態によっては、特に消費量に、ばらつきがあ
る場合ももある。例えば、期末にはコピー用紙の消費量
が多くなるなどである。このような変動要因も考慮した
算出式を、演算部４に予め設定しておく。そして、商品
ごとに、予測の消費速度Ａを算出し、この消費速度Ａ
は、再計算されて修正されるまでの間、記憶部３に、ユ
ーザーの情報として記憶しておく。

【００２４】ステップ１２では、適正在庫日数Ｂを設定
入力する。この適正在庫日数Ｂとは、上記適正在庫量Ｎ
１に対応するもので、ユーザーが在庫として持っておく
ことができる最大の在庫量を日数で表したものである。
つまり、理論的には、適正在庫量Ｎ１の状態から、適正
在庫日数Ｂが経過した時点で在庫が無くなることにな
る。そして、上記適正在庫日数Ｂは、購買履歴を考慮し
て業者側が提案するとともに、ユーザーの要望も取り入
れて設定する。

【００２５】ステップ１３では、発注点在庫日数Ｃを設
定入力する。この発注点在庫日数Ｃとは、上記第１実施
例で説明した発注点在庫量Ｎ２に対応するものであっ
て、発注点在庫量Ｎ２を日数の単位で表したものであ
る。つまり、ある商品の在庫が、上記発注点在庫量Ｎ２
であるということは、その商品がＣ日分だけ残っている
ということである。この発注点在庫日数Ｃも、ユーザー
の要望や過去の購買履歴を考慮して設定する。ステップ
１４では、適正在庫日数Ｂと消費速度Ａとから、適正在
庫量Ｎ１を算出する。ステップ１５では、発注点在庫日
数Ｃと消費速度Ａとから、発注点在庫量Ｎ２を算出す
る。

【００２６】この第２実施例では、初めに、日数を基準
にした適正在庫日数Ｂと発注在庫日数Ｃを設定して、在
庫の数量を算出しているが、初めから、数量を基準とし
た適正在庫量Ｎ１および発注在庫量Ｎ２を設定入力する
ようにしてもかまわない。この時点で、管理コンピュー
タ１の記憶部３には、ユーザーごとに、図５に示すよう
なデータが記憶されている。つまり、商品ａ，ｂ，ｃ，
ｄそれぞれの適正在庫量Ｎ１と、発注点在庫量Ｎ２、消
費速度Ａのデータである。ここでは、全製品の適正在庫
日数Ｂを３０日とし、発注点在庫日数Ｃを３日とした場
合を例に説明する。例えば、商品ａの場合、適正在庫量
Ｎ１は１２０個であり、この１２０個は３０日間で全部
消費される量である。そして、在庫が１２個、つまり、
３日分より少なくなる前に、新しい商品ａを配送しなけ
ればならない。

【００２７】ステップ１６，１７では、全商品を配送
し、ユーザー側での在庫量を全て適正在庫量Ｎ１に揃え
る。この時点で、現在庫量Ｎ＝適正在庫量Ｎ１である。
ステップ１８では、配送日までの間の時間計測を開始す
る。ステップ１９で、予定配送日を算出する。｛（適正
在庫量Ｎ１−発注点在庫量Ｎ２）／消費速度Ａ｝によっ
て、今から何日後に、現在庫量Ｎが発注点在庫量Ｎ２に
達するかを算出することができる。したがって、何日後
に、配送すればよいかがわかる。ステップ２０で、今日
が配送日かどうかを判定し、配送日なら、ステップ２６
へ進むが、配送日でなければステップ２１へ進む。

【００２８】ステップ２１では、現在庫量Ｎと、予定配
送日データをユーザー端末２へ送信し、ユーザー端末２
のディスプレイに表示させる。このとき、ユーザー端末
２のディスプレイには、図６に示すようなグラフと表が
表示される。このグラフは、フルスケールを適正在庫量
Ｎ１とした現在庫量Ｎのグラフである。そして、ユーザ
ー側の全商品が適正在庫量Ｎ１に揃った時点を６月１日
として説明する。

【００２９】図６に示す６月１日の時点では、全商品の
現在庫量Ｎが、適正在庫量Ｎ１であるとともに、この時
点での予想配送日は、６月２８日である。つまり、各商
品が、予測した消費速度Ａで消費されれば、在庫が６月
２８日に発注点在庫量Ｎ２になるはずである。一方、ユ
ーザー端末２側では、管理コンピュータ１から送信さ
れ、表示された現在庫量Ｎを確認するとともに、この実
際の在庫量と差があった場合には、ディスプレイ上で修
正することができる。その修正は、図６の表の、現在庫
量Ｎの欄の数字を修正すれば良い。ユーザー端末２で、
現在庫量Ｎの数値が変更されるとそのデータは、自動的
に管理コンピュータ１へ送信される。

【００３０】そこで、ステップ２２では、ユーザーが現
在庫量Ｎの数値を修正したかどうかを判断できる。ここ
で、現在庫量Ｎが修正されていた場合には、ステップ２
３で現在庫量Ｎを修正して記憶部３に記憶して、ステッ
プ２４へ進む。一方、ユーザー側での現在庫量Ｎの修正
が無かった場合には、そのままステップ２４へ進む。ス
テップ２４では、１日経過したかどうかを判断する。経
過していない場合、ステップ２１に戻る。１日が終了す
るまでは、ステップ２１〜ステップ２４を繰り返す。た
だし、その間に、ユーザー側で、現在庫量Ｎが修正され
た場合には、上記演算部４が、最新の現在庫量Ｎに基づ
いて修正したグラフをユーザー端末２へ送信し、表示す
る。

【００３１】ステップ２４で、１日が終了したことを判
定した場合には、ステップ２５へ進み、現在庫量Ｎを、
｛Ｎ−Ａ｝として算出する。つまり、ユーザー側の修正
が無ければ、現在庫量Ｎは、毎日、Ａ（個）ずつ減って
行くのである。ステップ２５で、毎日、現在庫量Ｎを算
出して、ステップ１９へ戻り、ステップ１９で、配送日
を算出する。商品の消費速度Ａが、管理コンピュータ１
側で予測した値と一致していた場合には、現在庫量Ｎの
修正も無いので、配送日も当初予測した通りの６月２８
日のはずである。ところが、ユーザー側で、現在庫量Ｎ
の修正があった場合には、配送日の予測も狂ってくる。

【００３２】そのため、配送日も修正しなければならな
い。そこで、図７を用いて、配送日の修正を具体的に説
明する。上記図７は、６月１０日に、ユーザー端末２に
表示された在庫量データである。現在庫量Ｎの欄には、
管理コンピュータ１の演算部で算出した数値が表示され
る。この値は、６月１日から６月１０日までの間の消費
量が反映されている。そして、この数値に対応したグラ
フも表示されている。この日までに、ユーザー側の修正
が無かった場合には、各商品の、グラフの棒の長さは全
て等しい。

【００３３】しかし、実際にユーザーが調べた在庫量
が、表の現在庫量Ｎの欄に表示された数値と違った場
合、例えば、商品ａの在庫が、実際には６０なのに、表
には８４と表示されていた場合には、ユーザーは、その
欄の数値を８４から６０に修正する。この図７では、修
正後の数値を四角で囲んでいる。このデータが、上記演
算部４に送信されて、ステップ２１で、表示するグラフ
も斜線を付けたように修正される。上記のように、現在
庫量Ｎの値が修正されると、演算部４のステップ１９で
の予定発送日の演算で算出される発送日も修正される。
つまり、初めの予想より、在庫量Ｎが少なくなったのだ
から、配送予定日は、６月２８日から６月２２日に早ま
る。

【００３４】上記のように、図４のステップ１９〜ステ
ップ２５を、配送日になるまで繰り返す。その間に、ユ
ーザー端末２に表示された表の中の数値を修正すれば、
演算部４は、その数値に合わせて、現在庫量Ｎと配送予
定日とを修正する。ステップ２０で、配送日であると判
断した場合、例えば、図８に示すように６月２２日に、
商品ａの現在庫量Ｎが、発注点在庫量Ｎ２に達した場
合、ステップ２６に進む。ステップ２６では、各商品ご
とに、配送量ｎを｛適正在庫量Ｎ１−現在庫量Ｎ｝とし
て算出し、全商品を配送する（ステップ２７）。

【００３５】ここで、再度、ユーザーの在庫は、全商品
とも適正在庫量Ｎ１に揃う。また、商品の売り上げが上
がった段階で、ユーザーの購買データを入力し、記憶部
３に記憶させる（ステップ２８）。そして、上記適正在
庫日数Ｂや発注点在庫日数Ｃを設定し直す必要がなけれ
ば、上記ステップ１７〜ステップ２８の作業を繰り返
す。なお、ステップ２７での配送時には、全商品を配送
し、全商品の在庫をそれぞれの適正在庫量Ｎ１に調整す
る。管理コンピュータ１側が正しい在庫量データを予測
できていなかった場合にも、この配送時点で、全ての商
品の在庫量データを適性在庫量Ｎ１に修正することがで
きる。

【００３６】この第２実施例でも、商品ごとの消費速度
がまちまちで、発注点在庫量Ｎ２に達するタイミングが
ずれていたとしても、最も早く発注点在庫量Ｎ２に達し
た商品ａのタイミングに合わせて、全商品を配送し、適
正在庫量Ｎ１に揃えるようにしている。そのため、短期
間に何回も商品を発送する必要がなくなり、発送回数を
減らすことができる。しかも、ユーザーの消費速度Ａを
予測して、配送予定日を決めているので、予測が、正確
であれば、ユーザーは、在庫量の修正や、発注の必要が
なくなる。

【００３７】そして、上記予測の精度を上げるために、
ユーザーの消費性状を正確に把握する必要があるが、購
買履歴データを蓄積することにより、予測精度を上げる
ことができる。現在庫量Ｎの予測値の信頼性が上がれ
ば、ユーザー側は、全く在庫管理をする必要がなくなる
し、業者側も、配送日を予測できる。また、各商品の現
在庫量Ｎを正確に予測できるようになれば、配送量も正
確に予測できるので、余分に持って行って持ち帰る量を
減らすことができる。つまり、配送日や、配送量を予測
して、予め配送スケジュールを立てられるようになる。

【００３８】図９は、第３実施例の、配送スケジュール
を説明する線図である。この第３実施例における配送シ
ステムは、図１に示す第１実施例と同様の構成をしてい
る。ただし、配送日は、予め設定した配送サイクルに基
づいて決定する点が、上記第１、第２実施例と異なる。
図９は、ユーザーＸの適正在庫日数と、業者Ｓの配送サ
イクルＴを表した線図である。

【００３９】まず、業者Ｓの配送サイクルＴを設定す
る。サイクルＴごとに、配送日，，，，・・・
が決定する。次にユーザーの適正在庫日数Ｂを設定す
る。このとき、適正在庫日数Ｂ＝ｘとし、ｘ≧Ｔとす
る。この適正在庫日数ｘは、上記第２実施例で説明した
適正在庫日数Ｂと同じもので、適正在庫量Ｎ１がｘ日分
の在庫量である。そして、上記適正在庫量Ｎ１は、全て
の商品についてｘ日分として設定する。そして、業者Ｓ
は、各配送日，，，，・・・には、ユーザーＸ
の消費品目全ての商品を配送し、全商品を上記適正在庫
量Ｎ１に揃えて帰るようにする。

【００４０】このシステムにおいても、第１回目の配送
日で、全商品を適正在庫量Ｎ１に揃えておく。その日
から、ｘ日後には、在庫が無くなるということである
が、ｘ日以内に次の商品を配送すれば、ユーザー側で、
商品不足になることはない。上記業者Ｓの配送サイクル
Ｔ ≧ｘなので、ユーザー側在庫を適正在庫量Ｎ１にし
てから、サイクルＴごとに配送すれば、在庫が無くなる
前に商品を補充できることになる。

【００４１】このように、配送サイクルに基づいて、適
正在庫量Ｎ１を設定することができれば、配送側の都合
で配送スケジュールを立てることができる。また、複数
のユーザーの適正在庫日数Ｂを共通に設定すれば、複数
のユーザーに、同じ配送日に商品を配送することが可能
になり、さらに配送回数を少なくできる。ただし、上記
のように、定期的に配送するだけで足りるのは、ユーザ
ーの、各商品の消費速度が、予測した消費速度からそれ
程ずれていないことが前提である。予測消費速度の精度
が低い場合には、サイクルＴ以外にも、ユーザーからの
発注に応じた配送が必要になる。

【００４２】しかし、第２実施例と同様に、ユーザーの
購買履歴データを蓄積することによって、消費速度の予
測精度を高めることができる。そして、予測消費速度か
ら適正在庫量Ｎ１を設定する際に、ユーザーの要望によ
って、配送サイクルＴの方を修正するようにしても良
い。サイクルＴ ≦Ｂとなる範囲で、配送日，，
，，・・・が、商品の配送必要時点と一致するよう
に、配送サイクルＴまたは適正在庫日数Ｂとを調整すれ
ばよい。

【００４３】上記第２，第３実施例とも、予測消費速度
の修正を基に、適正在庫量Ｎ１を修正し、正確な予測が
できるようになれば、ユーザーは、在庫管理や発注作業
をする必要がなくなるうえ、商品の受け取りも決まった
時にまとめてできるようになる。また、業者の配送回数
も、必要最小限にすることができ、そのための手間やコ
ストを削減できる。

【００４４】

【発明の効果】第１の発明によれば、多数の品種を配送
する場合に、一度の配送で、全ての商品を適正在庫量に
することができるので、従来のように、ユーザーが発注
したときに、その商品だけを配送する場合と比べて、配
送回数を少なくすることができる。したがって、配送に
かかる手間やコストを削減できる。第２の発明によれ
ば、購買履歴情報に基づいて予測した消費速度によっ
て、配送量を算出できるので、ユーザーは、在庫を管理
して、発注する手間が省ける。

【００４５】第３の発明によれば、実測した在庫量を基
に配送量を決めるので、配送時にユーザの在庫を適性在
庫量に揃えるのに必要な商品の量に対して、上記配送量
が多すぎたり、不足したりすることがない。そのため、
配送した商品を持ち帰ったり、追加配送したりする必要
がない。第４の発明によれば、予測在庫量の修正ができ
るので、予測値と実際値との間に差があった場合も、ユ
ーザーの在庫が不足したり、過剰になったりすることを
防止できる。第５の発明によれば、配送必要時点を、基
準在庫量によって決めているので、特定の商品の在庫
が、決まった量まで減ったときに配送される。在庫が十
分にあるのに、必要以上に配送されることがない。

【００４６】第６の発明によれば、１つの商品が基準在
庫量に達した時点を配送必要時点として、その他の商品
も配送できる。第７の発明によれば、ユーザーの購買履
歴に基づく予測消費速度の、精度を上げることができ
る。第８の発明によれば、予め、配送サイクルを決める
ことができるので、配送側のスケジュールがより立てや
すい。

【図面の簡単な説明】

【図１】第１実施例のシステムの全体図である。

【図２】第１実施例のデータを示した表である。

【図３】第１実施例のフローチャートである。

【図４】第２実施例のフローチャートである。

【図５】第２実施例のデータを示した表である。

【図６】第２実施例の作用を説明する図であり、ユーザ
ー端末に表示されるデータである。

【図７】第２実施例の作用を説明する図であり、ユーザ
ー端末に表示されるデータである。

【図８】第２実施例の作用を説明する図であり、ユーザ
ー反町に表示されるデータである。

【図９】第３実施例の配送サイクルを示した線図であ
る。

【符号の説明】

１管理コンピュータ２ユーザー端末３記憶部４演算部

───────────────────────────────────────────────────── フロントページの続きＦターム(参考） 3F022 AA09 AA13 MM02 MM11 MM19 MM28 MM35 5B049 AA06 CC05 CC28 EE01 EE31 GG04 GG07

Claims

【特許請求の範囲】

【請求項１】管理コンピュータには、記憶部と演算部
とを備え、記憶部には、ユーザーごとの消費商品と、上
記商品ごとの適正在庫量と、上記商品ごとの配送必要時
点での在庫量とを記憶し、演算部では、上記商品ごと
に、上記適正在庫量と配送必要時点での在庫量との差と
して配送量を算出する配送システム。
【請求項２】記憶部は、ユーザの購買履歴情報に基づ
いて決めた予測消費速度を記憶し、演算部は、上記予測
消費速度と適正在庫量とから、配送必要時点での在庫量
を演算し、それに基づいて配送量を算出する請求項１に
記載の配送システム。
【請求項３】配送必要時点での、実測した在庫量を基
に、配送量を算出する請求項１に記載の配送システム。
【請求項４】予測消費速度から配送必要時点での在庫
量を推測し、この在庫量を実測した在庫量で修正する請
求項２に記載の配送システム。
【請求項５】記憶部に、ユーザーごとに、消費商品ご
との基準在庫量を予め記憶させ、演算部は、基準商品の
在庫量が上記基準在庫量に達した時点を、配送必要時点
とする請求項１〜４のいずれか１に記載の配送システ
ム。
【請求項６】記憶部は、複数の商品の、それぞれの基
準在庫量を記憶し、演算部は、これら商品のうち、いず
れか１の商品が、基準在庫量に達したときを配送必要時
点とする請求項１〜４のいずれか１に記載の配送システ
ム。
【請求項７】記憶部は、継続的に入力される各ユーザ
ーの購買履歴を記憶し、演算部は、所定期間ごとに上記
ユーザーの購買履歴に基づいて、消費速度を演算し直
し、この消費速度データに基づいて、配送必要時点での
在庫量を算出する請求項２または４に記載の配送システ
ム。
【請求項８】予め設定した配送サイクルを基にして配
送必要時点を特定する請求項１〜４のいずれか１に記載
の配送システム。