JP2004203531A - 商品の適正在庫管理 - Google Patents

Abstract

【課題】ビジネス消耗品の在庫管理を一元管理することにより、少ない在庫量で短時間にユーザにビジネス消耗品を納品可能な在庫管理による流通制御を目的とする。
【解決手段】通信ネットワークを介して接続された製造者11、製造者からビジネス消耗品を受け取るマスタ倉庫5、地理的に分散配置され、マスタ倉庫からビジネス消耗品が配給され、ビジネス消耗品を顧客4に配送する複数のブランチ倉庫6とを含む流通制御システムで、商品あるいは顧客単位に時系列の受注確率を管理するデータベース8から得られた受注確率に基づいて、特定商品について顧客4から受注し得る受注数ごとに、時系列に該受注数が発現する確率を求めて記憶し、受注数が発現する確率に基づいて、特定時期の特定商品の適正在庫数を算出して、算出された適正在庫数を、通知先データベースに記憶された通知先情報と関連付け、所定の通信回線を介して通知する。
【選択図】 図４

Description

【０００１】
【発明の属する技術分野】
本発明は商品の適正在庫管理による流通制御に関し、例えば、トナーカートリッジなどのビジネス消耗品を効率的かつ効果的に在庫する在庫管理に関するものである。
【０００２】
以下本明細書では、商品としてビジネス消耗品であるトナーカートリッジを例に説明するが、本発明の対象となる商品はこれに限定されるものではなく、定期的あるいは消耗期間が来ると取り替えが必要となる商品について同様な効果を奏するものであり、これらも本発明の商品管理に含まれるものである。
【０００３】
【従来の技術】
電子写真方式を利用する機器には、トナーカートリッジと呼ばれるカートリッジによってトナーが供給されるものがある。各機器には、その機種に応じたトナーカートリッジを装着する必要があり、同じプリンタでも機種が異なれば、大概は、異なるトナーカートリッジが必要になる。従って、多種類の機器を利用するオフィスや事業所では、多種類のトナーカートリッジを在庫し維持管理する必要がある。尚、トナーカートリッジに限らず、オフィスや事業所で消費されるすべてのビジネス用品は適正在庫の維持管理が要求される。以下では、トナーカートリッジのような物品を「ビジネス消耗品」と呼ぶ場合がある。「ビジネス消耗品」には、トナーカートリッジのほか、複写機用のトナー、感光ドラム、インクジェットプリンタ用のインク、その他サービスパーツ、紙やOHPシートなどを挙げることができる。 このような特性をもつビジネス消耗品の販売形態、在庫管理に関して、次に示すような要望がある。
【０００４】
利用機器に応じたビジネス消耗品を供給し販売する製造者や販売店は、顧客へビジネス消耗品を短期間に供給する必要から、それぞれの倉庫にかなりのビジネス消耗品を在庫している。しかし、ビジネス消耗品の多種多様性、需要予測の困難さから適正在庫になっているとはいえない。このため、顧客から受注したビジネス消耗品の在庫がなく、地理的に離れた他の販売店には過剰にあるという事態が発生する。この場合、過剰在庫をもつ販売店から顧客へビジネス消耗品を供給することはできても、通常の配送地域から外れるなどの問題から、到底、短期間に納品することはできない。従って、ビジネス消耗品の多種多様性及び需要予測の困難さを考慮した在庫管理が望まれている。
【０００５】
商品ごと物流拠点に適正在庫を管理する為には商品ごと物流拠点ごとの過去の販売履歴を基に販売の平均値、確率分布などを求め将来の需要を予測する方法 （特開平８−２７９０１３号）などが考案され実施されている。これらの方法を使えば、図１のように物流拠点における日々の販売数量が多い場合には過去の販売履歴が正規分布などの統計的確率分布に従うと考えられる為、特開平８−２７９０１３号のように在庫リスクの算出を行うことも可能となる。又、インターネットなどの普及により顧客ごとの販売数量を管理することが容易になりそれを基にした在庫管理を行うことも可能となっている。
【０００６】
【発明が解決しようとする課題】
ビジネス消耗品のような商品は消耗品がなくなると新しい消耗品を本体機器に設置するまで本体機器の使用が停止してしまうので、顧客は短期間の納期で商品が配送されることを期待している。このような顧客のニーズに対応する為には特開２００１−２２５９２２などにも示されている通り、例えばオフィス街などの顧客の近くに在庫を保有しておくことが有効であるが同じ商品を分散して保管することで各倉庫の販売数量は少なくなる。しかし、物流拠点における日々の販売数量が少ない場合には、図２に示す通り日々の販売数量が大きく振れてしまうことが多く、販売履歴が正規分布などの統計的確率分布に従わない為、一般的に行われている特開平8-279013 のような過去の販売履歴を基にした需要予測が適用できないと考えられる。
【０００７】
本発明は、上述の課題を解決するためのものであり、ビジネス消耗品の在庫管理を一元管理することにより、少ない在庫量で短時間にユーザにビジネス消耗品を納品可能な在庫管理による流通制御を目的とする。
【０００８】
【課題を解決するための手段】
かかる課題を解決するために、本発明の適正在庫数決定方法は、商品あるいは顧客単位に時系列の受注確率を管理するデータベースを保持する工程と、前記データベースから得られた前記受注確率に基づいて、特定商品について顧客から受注し得る受注数ごとに、時系列に該受注数が発現する確率を求めて記憶する工程と、前記受注数が発現する確率に基づいて、特定時期の前記特定商品の適正在庫数を算出する工程とを具備することを特徴とする。
【０００９】
【発明の実施の形態】
以下、本発明にかかるビジネス消耗品の販売回収システムを、図面を参照して詳細に説明する。尚、本実施形態では電子写真方式のプリンタ、複写機、ファクシミリ装置などの機器に使用されるトナーカートリッジをビジネス消耗品の一例として説明するが、他のビジネス消耗品にも本発明を適用することができる。例えば、上記機器用のビジネス消耗品としては、複写機用のトナー、感光ドラム、その他サービスパーツ、紙やOHPシート、インクジェットプリンタ用のインクなどを挙げることができる。
【００１０】
＜本実施形態の概要＞
本実施形態は、商品あるいは顧客単位に時系列の受注確率を管理するデータベースを保持する工程と、前記データベースから得られた前記受注確率に基づいて、特定商品について顧客から受注し得る受注数ごとに、時系列に該受注数が発現する確率を求めて記憶する工程と、前記受注数が発現する確率に基づいて、特定時期の前記特定商品の適正在庫数を算出する工程とを具備する。
【００１１】
ここで、前記受注確率を、顧客の受注履歴に基づき算出される前記顧客の購入間隔に関する確率分布と、前記顧客の最新受注時期とに基づき算出する工程を更に具備する。又、前記確率分布は正規分布を適用する。又、前記受注数ごとに発現する確率は、該受注数ごとに顧客それぞれが購入するか購入しないかの組み合わせが発現する確率の総和に基づき算出する。又、前記適正在庫数の算出工程では、受注数ごとの発現確率と前記商品の在庫切れ危険率を示す所定値との比較に基づき、適正在庫数を算出する。
【００１２】
又、画像形成装置に利用される記録材を収納したカートリッジの適正在庫数を制御する適正在庫数制御方法であって、所定期間後における受注確率を決定する受注確率決定モジュールの起動に応じて、地域情報とカートリッジの種別とが関連付けられた顧客販売履歴情報を記憶するデータベースより前記顧客販売履歴情報を読込む読込工程と、前記読込工程にて読込まれた顧客毎の販売履歴情報より、前記顧客毎の所定期間後の購入確率を算出する第１算出工程と、前記第１算出工程にて算出された前記顧客毎の所定期間後の購入確率より、地域情報毎における購入数に対応した地域別購入確率を算出して記憶する第２算出工程と、前記第２算出工程より算出された地域別購入確率に基づいて、地域情報の夫々に対応した地域別適正在庫数を算出する算出工程と、前記算出工程にて算出された地域別適正在庫数を、通知先データベースに記憶された前記地域情報毎の通知先情報と関連付け、該関連づけられた通知先情報に基づいて前記地域別適正在庫数を所定の通信回線を介して通知する通知工程とを備える。
【００１３】
又、通信ネットワークを介して接続された情報処理装置を有する、少なくとも、製造者、製造者からビジネス消耗品を受け取るマスタ倉庫、地理的に分散配置され、前記マスタ倉庫から前記ビジネス消耗品が配給され、前記ビジネス消耗品を顧客に配送する複数のブランチ倉庫とを含む流通制御システムであって、商品あるいは顧客単位に時系列の受注確率を管理するデータベースと、前記データベースから得られた前記受注確率に基づいて、ビジネス消耗品の流通を管理する情報処理装置を有し、該情報処理装置は、前記データベースから得られた前記受注確率に基づいて、特定商品について顧客から受注し得る受注数ごとに、時系列に該受注数が発現する確率を求めて記憶する手段と、前記受注数が発現する確率に基づいて、特定時期の前記特定商品の適正在庫数を算出する手段と、前記算出手段にて算出された適正在庫数を、通知先データベースに記憶された通知先情報と関連付け、所定の通信回線を介して通知する手段とを備える。
【００１４】
＜トナーカートリッジの流れの概略＞
（従来の流れの例）
図３は、従来のトナーカートリッジの流れを示す図である。
【００１５】
図３において、製造者1の工場11で生産計画に合わせて製造されたトナーカートリッジは、随時、製造者の倉庫12へ送られる。ユーザ4から注文がある場合、販売者3からユーザ4へは、もし販売者3に在庫があれば遅くとも一日（注文の翌日）で納入可能である。しかしながら、販売者3に在庫がなく注文が販売者3から製造者1へ入る場合には、販売者3（又はその倉庫）へ納入するのにかなり日数がかかる場合があり、結果的にユーザ4への納入日数が増すことになる。
【００１６】
（本実施形態の流れの例）
図４は本実施形態におけるトナーカートリッジの流れを示す図である。
【００１７】
図４において、製造者1の工場11で生産計画に合わせて製造されたトナーカートリッジは、随時、マスタ倉庫5へ送られる。マスタ倉庫5に一旦入荷したトナーカートリッジは、出庫スケジュールに合わせて各地に分散配置されたブランチ倉庫6へ配送される。ユーザ4から注文が入ると、ブランチ倉庫6からユーザ4へトナーカートリッジが納入される。
【００１８】
図４に示すマスタ倉庫5は、トナーカートリッジの流れの中心になる主管的な倉庫であり、製造者1、販売者3あるいは物流業者などによって営まれる。ユーザ4との接点になるブランチ倉庫6は、物流業者によって営まれるのが好ましい。
【００１９】
また、共有データベース(DB)8は、工場11の生産、マスタ倉庫5及びブランチ倉庫6の在庫、ユーザ4の注文、さらに、工場11、マスタ倉庫5、ブランチ倉庫6、ユーザ4及び回収センタ7の間の回収を含む物流を一元管理するものである。共有DB8による一元管理を行うことにより、適切な生産、在庫及び物流を実現し、ユーザ4から注文を受けたトナーカートリッジの例えば一日以内の納入を可能とする。
【００２０】
すなわち、図４に示すようなトナーカートリッジの流れを構築してシステム化することによって、ユーザは短期間に確実にトナーカートリッジを入手することができるようになる。従って、多種類のプリンタ、複写機、ファクシミリ装置を利用するオフィスや事業所における、多種類のトナーカートリッジの在庫の維持管理を容易にできる。さらに、小規模なオフィスや事業所であれば、例えば、トナーの残量がある閾値を割り、プリンタなどからトナーカートリッジの交換予告が通知された時にトナーカートリッジを発注すれようにすれば、在庫管理自体を不要にすることも可能である。
【００２１】
言い換えれば、共有DB8により多種多様なトナーカートリッジの生産、物流、在庫、受注及び配送を一元管理することにより、例えば、生産及び受注に応じてマスタ倉庫5及びブランチ倉庫6の間でトナーカートリッジの在庫を調整することができるので、販売者3などの倉庫にビジネス消耗品を在庫しなくても、ユーザ4へトナーカートリッジを短期間に供給することができ、販売者3の在庫なしや過剰在庫に起因する問題、例えば過剰在庫による金利負担増などを解消することができる。
【００２２】
＜本実施形態の販売回収システムの構成例＞
以下では、図４に示すトナーカートリッジの流れを実現する本実施形態の販売回収システムを詳細に説明する。
【００２３】
図５はトナーカートリッジの販売回収システムのハイドウエア構成例を示す図である。
【００２４】
メインサーバ81は、共有DB8を提供するサーバ装置である。尚、共有DB8は、一台のサーバ装置によって提供されるとは限らず、複数台のサーバ装置に分割されて、あるいは、並列に提供されることもある。つまり、共有DB8は、論理的に１つのデータベースとして提供されればよい。
【００２５】
メインサーバ81には、インターネットなどのワイドエリアネットワーク(WAN)100を介して、共有DB8を利用する複数の端末装置が接続される。端末装置13、31、41、51、61及び71はそれぞれ製造者1、販売者3、ユーザ4、マスタ倉庫5、ブランチ倉庫6及び回収センタ7の端末である。また、端末装置32は販売者3のセールスマンやサービスマンが使用するモバイル端末、端末装置62は物流業者の配送係が使用するモバイル端末である。
【００２６】
（共有データベースの構成例）
共有DB8には、下に一例を示すようなデータベース及びそのフィールド情報が格納されている。これらの情報は、図３に示す各端末装置へ提供されるとともに、それら端末装置により更新される。尚、下に示すデータベース及びそのフィールドは、本実施形態の実現に必要なものを記載しているが、販売回収システムの対象とするユーザやビジネス消耗品の特性などに応じて、追加又は削除される場合がある。それぞれの詳細な構成は、以下の本実施形態の説明で必要な部分において更に説明されるが、そのフォーマットなどの説明は本発明の特徴的構成に関連しないものは、煩雑さを避けるために説明を省く。
【００２７】
●販売者情報データベース
販売者ID及びパスワード
名称、住所、電話番号及びファクシミリ番号
電子メールアドレス
顧客担当者情報
販売実績情報
在庫情報
●倉庫情報データベース
マスタ倉庫情報
ブランチ倉庫情報
マスタ-ブランチ間連結情報
倉庫別在庫情報
倉庫属性テーブル
在庫切れ危険率S
商品別、日別季節変動係数
商品別、日別必要在庫数
マスタ倉庫情報やブランチ倉庫情報には、それら倉庫の所在地などが含まれる。また、マスタ-ブランチ間連結情報には、マスタ倉庫5からブランチ倉庫6へ物品を配送するのに必要な時間、及び、ブランチ倉庫6の相互間で物品を配送するのに必要な時間を示す情報などが含まれる。さらに、倉庫別在庫情報には、各倉庫の適正在庫量を示す情報などが含まれる。
【００２８】
メインサーバ81は、これらの情報に基づき、マスタ倉庫5からブランチ倉庫6への在庫移動、及び、複数のブランチ倉庫6に対する配送の振り分けを制御する。また、ユーザ4から受注したトナーカートリッジが最寄りのブランチ倉庫6にない場合、ユーザ4の希望納期で、又は、最短で納品できるように倉庫間の在庫移動を制御する。
【００２９】
●製品情報データベース
製品名及び型番
関連消耗品
製品別在庫情報
価格情報
代替商品テーブル
●顧客情報データベース
ユーザID及びパスワード
名称、住所、電話番号及びファクシミリ番号
電子メールアドレス
担当販売者、セールスマン及びサービスマン
最寄りのブランチ倉庫#1
最寄りのブランチ倉庫#2
購入製品名（型番）及び数
発注履歴
購入履歴
支払履歴
価格情報
装置稼動情報
●出庫情報データベース
出庫先顧客情報
ステータス
注文番号
注文日時
注文アイテム
納期
価格
支払方法
出庫日時
着荷日時
検収日時
出庫倉庫
●製造者、販売者情報、物流業者情報データベース
製造者ID及びパスワード
販売者ID及びパスワード
セールスマンID及びパスワード
サービスマンID及びパスワード
倉庫ID及びパスワード
配送係ID及びパスワード
●統計情報データベース
購入確率分布（平均、分散ごとの日別購入確率）
購入確率累計分布（日別購入確率累計）
集団決定最低データ数
顧客別、商品別、母集団種類別データ数
一般的な統計情報（度数分布表など）
＜本実施形態のメインサーバの構成例＞
図５に示されたメインサーバ81の内部構造について、図６のブロック図を参照して説明する。
【００３０】
図６に示されるように、メインサーバ81は、CPU(Central Processing Unit)2501、入力装置2502、主記憶装置2503、出力装置2504、補助記憶装置2505及び通信装置2506などから構成される。
【００３１】
処理装置であるCPU2501は、システム内の各装置に命令を送り、その動作を制御する制御機能、並びに、サーバの中心的な部分でディジタルデータの演算処理を行う機能を有する。
【００３２】
入力装置は2502は、各種データを入力するための装置で、例えばキーボード、マウスなどのポインティングデバイス、タッチパネル、感圧パッド、CCDカメラ、カード読取機、紙テープ読取機、磁気テープ装置などが考えられる。例えば、図６のインタフェース画面を介して、マウスなどの入力装置2502から指示データが入力される。CPU2501は、入力された情報を認識し、次の処理に移行する。
【００３３】
主記憶装置2503とは、各処理装置及び内部記憶装置において、命令を実行するために使われるアドレス可能なメモリ空間全体を指す。主記憶装置2503は、主として半導体素子により構成され、入力したプログラムやデータを格納、保持する。CPU2501は、メモリに保持されているデータを例えばレジスタに読み出す。主記憶装置2503を構成する半導体素子としては、RAM(Random Access Memory)やROM(Read Only Memory)などである。図５のユーザインタフェースを介して入力されたID、パスワード情報は主記憶装置2503に一時記憶され、一時記憶された情報はCPU2501により通信装置2506を介して送信される。また、図５のユーザインタフェースを表示するための表示用メモリとしての機能も有する。
【００３４】
出力装置2504は、CPU2501による演算結果を出力するための装置で、例えばCRT、プラズマディスプレイ、液晶ディスプレイ、その他の表示装置、プリンタなどの印刷装置、音声出力装置などが該当する。本実施形態では、例えば、図５に示される各端末装置の表示装置が出力装置2504に該当する。
【００３５】
補助記憶装置2505は、主記憶装置2503の記憶容量を補うため、不揮発にデータを保持するための装置で、例えば磁気ディスク装置、光ディスク装置、半導体ディスク装置、並びに、フロッピー（登録商標）ディスク、CD-ROM、CD-R、CD-R/W、MO、DVDなどのメディア及びドライブが該当する。補助記憶装置2505は、データベースの機能を実現するための装置で、本実施形態においては、例えば共有DB8が補助記憶装置2505に該当する。また、主記憶装置と同様にプログラムを格納する機能も有している。
【００３６】
通信装置2506は、外部のネットワークと通信を行うための装置で、接続されるネットワークに応じて適宜データの送受信やデジタル/アナログ変換などを行う。本実施形態においては、例えば図１４の各ステップにおいて送信されるデータは、CPU2501の制御下で、通信装置2506を介して送信される。
【００３７】
上述した各装置は、アドレスバス又はデータバスにより相互に接続されており、双方向の各種データの通信に利用される。
【００３８】
本実施形態に記載された各フローチャート及び各図を用いて説明する処理は、主記憶装置2503又は補助記憶装置2505に記憶された各種プログラムコードに基づく各装置の制御を、CPU2501が処理することによって実現される。
【００３９】
図５に示される端末装置13、31、41、51、61及び71、端末装置32、並びに、モバイル端末装置62も、データ及びプログラムの一部が異な他は図６と略同様の構成を有する。
【００４０】
（データベースの記憶例）
図７は、共有DB8（補助記憶装置2505）における各データベースの記憶例を示す図である。各データベース内あるいは必要であればデータベース間で、それぞれの項目に従って記憶領域が更にポイントされたり、リンクされたりして、関連情報の検索・読み出しや、データのグループ化などが可能である。これらに技術については、ここでは詳説しない。
【００４１】
図７に示すように、本実施形態では、販売者情報データベース8a、倉庫情報データベース8b、製品情報データベース8c、顧客情報データベース8d、出庫情報データベース8e、通知先（製造者、販売者情報、物流業者情報）データベース8f、統計情報データベース8gがそれぞれ記憶されている。
【００４２】
（各種データ及びプログラムの記憶例）
図８は、主記憶装置2503に一時記憶されるデータ及びプログラムの記憶を示す図である。尚、図８には、OS等の装置に必須な共有データやプログラムは記載されていない。
【００４３】
201は、データ記憶領域の記憶例であり、本実施形態で使用されるデータや演算結果などが記憶される。それらのデータとしては、本実施形態の流通制御の基礎データとなる購入間隔データ201a、購入間隔データ201a算出に使用される母集団データ201b、購入間隔データ201aから算出される各顧客あるいは各装置単位のビジネス消耗品の購入を示す購入確率Ｘ（ｚ）201c、購入確率Ｘ（ｚ）201cを各ブランチ倉庫やマスタ倉庫などのビジネス消耗品の納入拠点で累計する購入確率累計Ｚ（ｔ）201d、ビジネス消耗品がｍ個発注・納入される購入確率Ｙ（ｍ）201e、各納入拠点での必要在庫数量Ｎ201fが含まれる。尚、図８では、１種類のビジネス消耗品について必要なデータを示したが、複数種類のビジネス消耗品の在庫管理のためには、それぞれ複数のデータを用意すればよい。
【００４４】
202は、プログラム記憶領域の記憶例であり、本実施形態で使用されるプログラムが記憶される。それらのプログラムとしては、本実施形態の流通制御の内で在庫管理を行ない在庫管理メインプログラム202a（図９参照）、在庫管理メインプログラム202aで使用される各モジュールプログラムである、必要在庫算出モジュール202b（図１３参照）、受注処理モジュール202c（図２０参照）、出庫処理モジュール202d（図２１参照）、在庫補充モジュール202e（図２２参照）、母集団算出モジュール202f（図２６参照）、購入間隔算出モジュール202g（図３０参照）、通信制御モジュール202hが含まれる。
【００４５】
尚、上記データやプログラムは、補助記憶装置2505に保存されていて主記憶装置2503のRAMに読み出されても良いし、主記憶装置2503のROMに格納されていても良い。
【００４６】
＜本実施形態のメインサーバの動作例＞
図９に従って、本実施形態のメインサーバの在庫管理に関する動作手順を説明する。尚、図９には在庫管理外の製造・運搬・回収・課金処理などの手順は含まれていないが、これらも図９以下を参照すれば容易に実現可能である。
【００４７】
まず、ステップS101では、図５に示される端末からのアクセスを待つ。アクセスがあると、ステップS102,S107でユーザ（顧客）からのアクセスか、在庫部（納入拠点）あるいは物流業者の配送係りからのアクセスかを判定して、それぞれに適応する処理を実行する。尚、ここでは、在庫部（納入拠点）と物流業者を一括して同様の処理にしたが、図４の工場、マスタ倉庫、ブランチ倉庫などによって異なる処理を行ってもよく、その相違は本発明の要旨を変えるものではないので、ここでは言及しない。
【００４８】
ユーザ（顧客）からのアクセスの場合は、ステップS103に進んで受注処理モジュール（図２０）を実行する。ステップS104では受注処理モジュールの中で受注が有ったか否かを判断し、受注が無ければ処理を終了する。受注があれば、ステップS105に進んで出庫処理モジュール（図２１）を実行する。出庫処理が終了すると、次にステップS106で在庫補充処理（図２２）を行って、処理を終了する。
【００４９】
在庫部（納入拠点）又は物流業者の配送係からのアクセスの場合は、ステップS108で納品の確認か否かを判断し、例えば、物流業者の配送係のモバイル端末62から入力される情報に基づき、受注情報に対応する納品が行われたか否かが判定され、納品確認であればステップS109で共有DB8の納品手続及び受注情報の更新（納品済フラグをオンにするなど）を行う。納品確認でなければ、ステップS110に進んで在庫補充確認か否かを判断し、在庫補充確認であればステップS111で在庫情報の更新を行う。在庫補充確認でなければ、ステップS112に進んで納品や補充が期待期間内に行われなかった場合（タイムアウト）の通知か否かを判断する。タイムアウトの通知であればステップS113に進んで出庫又は在庫補充の再処理を指示する。タイムアウトの通知でもなければ、ステップS114で他の処理を行う。
【００５０】
（必要在庫数算出例）
前述したとおり共有DB8を用いて多種多様なトナーカートリッジの生産、物流、在庫、受注及び配送を一元管理すれば、例えば、生産及び受注に応じてマスタ倉庫5及びブランチ倉庫6の間でトナーカートリッジの在庫を調整することができ、過剰在庫による金利負担増などの問題を解消することができる。しかし、ユーザへの納入時間を短縮する為に多くのブランチ倉庫を持ち、各トナーカートリッジ在庫をユーザの近くに配置すると各倉庫のトナーカートリッジ在庫が分散されて、前述した図２で示したように日々の出庫数量が大きく振れてしまい適切な在庫管理が困難になる場合が考えられる。
【００５１】
以下に、このような場合の適正在庫を計算する方法の一例と、メインサーバ81に実装された共有DB8と計算モジュールによって構成される適正在庫管理システムにおける、購入確率の予測方法について詳しく説明する。
【００５２】
あるトナーカートリッジを購入した顧客は、そのトナーカートリッジを使用する装置を所有し、購入したトナーカートリッジを使用しているわけであるから、当然、再びそのトナーカートリッジを購入することがメインサーバ81により予測される。
【００５３】
そして、図１０に示すように、そのトナーカートリッジを購入する購入経過日（最新の購入履歴からの経過日数）ごとの確率は、前回、そのトナーカートリッジを購入した日(t=0)から増加し、ある日tp(tp＞0)でピークを迎え、ある日t(t＞tp)に零になる正規分布を描くと仮定する。このようなある顧客がある日あるトナーカートリッジを購入する確率を購入確率x(t)と呼ぶこととする。勿論、前述した"日"の替わりに"時間"、"週"など他の時間単位を用いることも可能である。図１０は購入確率x(t)の一例を示す図で、５日目(t=5)でピークを迎え、１０日目(t=10)で零に戻る例である。
【００５４】
尚、具体的な計算例はここでは示さないが、各日ごとの購入確率の計算は一般的な正規分布における確率計算により求めることができる。
【００５５】
ある顧客が、ある日、トナーカートリッジを購入しなければ、翌日、そのトナーカートリッジを購入する確率は上昇する。つまり、購入確率x(t)の総和Σx(t)は100%になる。言い換えれば、買わなかった日の確率は翌日に繰り越されるといえる。従って、購入確率x(t)を累計していけば、ある顧客が、ある日、そのトナーカートリッジを購入する可能性を知ることができ、これを購入確率累計Z(t)と呼ぶことにする。図１１は図１０の購入確率x(t)に対応する購入確率累計を示す図である。図１０及び１１に示されるような情報が共有DB8（統計情報データベース8g）に格納されていて、メインサーバ81のCPU2501により参照され各種確率演算に利用される。
【００５６】
このようにして、メインサーバ81の処理により、ある日、ある顧客が、あるトナーカートリッジを購入する確率を予測することができる。尚、購入確率x(t)の分布は必ずしも正規分布に従う必要はなく、正規分布以外であっても購入確率を累計する手法は適用可能である。
【００５７】
−購入確率の算出−
さて、各ブランチ倉庫6は、あるトナーカートリッジに対して複数の顧客を有する。従って、在庫切れを防ぐには、ブランチ倉庫ごと、トナーカートリッジの種類ごとにすべての顧客の購入確率累計に応じた必要在庫数を計算する必要がある。尚、説明を簡単にするために、以下では、一人の顧客があるトナーカートリッジを１回の注文で一個買うと仮定して計算する。
【００５８】
ここで、ある日、ある顧客の、あるトナーカートリッジの購入確率累計をZp（ただしp=1〜n）とする。さらに、ある日、n人の顧客が、あるトナーカートリッジを合計m(=0〜n)個購入する確率をY(m) （ΣY(m)＝100％）とする。例えば、２人の顧客(n=2)が、0,1,2個（合計）購入する場合の確率をY(0),Y(1),Y(2)と定義する。１人の顧客があるトナーカートリッジを一個買うと仮定すればY(3)以上の確率は0である。
【００５９】
２人の顧客の購入確率累計をそれぞれZ1 、Z2とするとY(0)は２人とも購入しない場合である為、購入確率累計は(1-Z1)と(1-Z2)の積で計算することができる。Y(1) は1つのカートリッジが購入される確率なので２人のうちどちらか一人が購入し、どちらか一人が購入しない場合と考えられるため Z1×（1-Z2)と (1-Z1) ×Z2 の和で計算することができる。同様にY(2)は2つのカートリッジが購入される確率なのでZ1×Z2で計算することができる。Y(0),Y(1),Y(2)の合計ΣY(m)( m=0〜2)は100%になる。
【００６０】
以上の結果をまとめると。
【００６１】
Y(0) = (1-Z1)×(1-Z2)
Y(1) = Z1×(1-Z2) + (1-Z1)×Z2
Y(2) = Z1×Z2
ΣY(m) (m=0〜2)＝Y(0)+ Y(1)+ Y(2) =100%
となる。
【００６２】
また、５人の顧客を仮定すると、ある日、あるトナーカートリッジを購入する確率は、次のようになる。
【００６３】
Y(0) = (1-Z1)(1-Z2)(1-Z3)(1-Z4)(1-Z5)
Y(1) = (Z1'+Z2'+Z3'+Z4'+Z5')×Y(0)
Y(2) = (Z1'Z2'+Z2'Z3'+Z3'Z4'+Z4'Z5'+Z5'Z1')×Y(0)2
:
Y(5) = Z1×Z2×Z3×Z4×Z5
ここで、Z1' = Z1/(1-Z1)
:
Z5' = Z5/(1-Z5)
同様にｎ人の顧客に対する購入確率を計算することができる。上で説明してきたような演算を実行するためのプログラム（必要在庫算出モジュール202b）が補助記憶装置2505（共有DB8）に格納されていて、メインサーバ81のCPU2501によってプログラムが読み出され、読み出されたプログラムに基づく演算が行われる。
【００６４】
次に、図１２に、計算結果を示した購入周期及び前回の購入日が同じ複数の顧客として顧客２人を例に、あるトナーカートリッジを購入する確率Yを計算する例を具体的に示す。
【００６５】
図１２に示すステップS902の顧客Aの購入確率X(a)を累計したステップS903での購入確率累計Ｚ(a)、及び顧客BのステップS905での購入確率累計Ｚ(ｂ)がどちらも30%である4日目を例に、以下計算の事例を示す。
【００６６】
ブランチ倉庫において0個、1個、2個の在庫を持った場合の計算は以下の通りになる。
【００６７】
Y(0) = (1 - 0.30)×(1 - 0.30)×100 = 49（％） (Ｓ906)
Y(1) = {0.30×(1 - 0.30) + (1 - 0.30)×0.30}×100 = 42％ (Ｓ907)
Y(2) = 0.30×0.30×100 = 9％ (Ｓ908)
つまり、購入周期及び前回の購入日が同じ顧客２人が、あるトナーカートリッジを購入しない確率は約49％、１個購入する確率は約42％、２個購入する確率は約9％と計算される。
【００６８】
−必要在庫数の決定−
上記の計算例では、その日、２人の顧客がともに、あるトナーカートリッジを購入する確率は9％であり、どちらかが購入する確率は42％である。つまり、在庫を１つも持っていなかった場合に在庫切れを起こす確率は、２人の顧客が合計１個又は２個購入する場合でありその確率は9％+42％=51%である。又、在庫を１つ持っていた場合に在庫切れを起こす確率は２人の顧客が合計２個購入する場合のみでありその場合の確率は前述した通り9％である。この場合に在庫切れの許容度を10％とすると１個の在庫を持っていれば必在庫切れの確率は許容度以内に納まることになる。
【００６９】
以下では、幾つ在庫すべきかを示す数を「必要在庫数N」と呼び、在庫切れを防ぐための判定値（言い換えれば必要在庫数を決定するための判定値）を「在庫切れ危険率S」と呼んで、在庫切れ危険率Sの値に基づく必要在庫数Nを求めるメインサーバ81の演算処理に関して説明する。在庫切れ危険率Sは任意に設定可能であるが、例えば、在庫切れ危険率Sを5%にした場合、上記の計算例で２人の顧客が２個購入する確率は9％であるから、在庫切れ危険率S(=5%)以上であり２個の在庫が必要である。勿論、２人の顧客が購入しない場合を含めた確率ΣYが在庫切れ危険率S未満であれば、その日は在庫は不要である。
【００７０】
図１２で購入周期及び前回の購入日が同じ顧客２人が、あるトナーカートリッジを購入する各日の確率を説明すると、ステップＳ910で示した通り在庫切れ危険率S=5%で、１日目の必要在庫数Nは零、２日目及び３日目は一個、４日目以降は２個である。尚、ステップＳ909で示した通り在庫切れ危険率S=10%にすると、４日目の必要在庫数Nが１個になる。
【００７１】
図１２では顧客２人を例にして説明したが、２人に限定されるものではなく、１人又は３人以上にも適応可能であり、メインサーバ81は１人又は３人以上の顧客に対する必要在庫数Nを計算することができる。
【００７２】
（必要在庫数算出モジュールの手順例）
図１３は、ブランチ倉庫6における、ある商品の必要在庫数Nを求める手順例を示すフローチャートである。図１３のフローチャートの各ステップは、メインサーバ81に設けられた主記憶装置又は補助記憶装置に記憶されたプログラムコード基づき、CPU2501が実行する処理である。
【００７３】
計算の対象となる各顧客の商品別購入間隔データを顧客DBから読み込み（S1001）、該購入間隔データの平均値と分散を算出し（S1002）、各顧客の商品別、日別のトナーカートリッジの購入確率x(t)を算出する（S1003）。各顧客の購入確率累計Z(t)を求め(S1004)、n人の顧客が合計m(=0〜n)個のトナーカートリッジを購入する確率Y(m)を求める(S1005)。
【００７４】
次に、共有DB8など、補助記憶装置に予め設定された在庫切れ危険率Sを取得し(S1006)、必要在庫数Nを得るためのパラメータY及びカウンタiを初期化する(S1007)。i＞0であれば(S1008)、上記のように確率Yを累計して(S1009)、確率Yと在庫切れ危険率Sとを比較して(S10010)、Y≦Sならばiをデクリメントし(S1011)、ステップS1007へ戻る処理をi＞0の間繰り返す。
【００７５】
そして、Y＜Sになれば必要在庫数N=iを決定し(S1012)、ステップＳ1008でi≦0であれば必要在庫数N=0を決定し、それぞれ決定された必要在庫数量Nを倉庫情報DBに格納する(S1012、S1013)。
【００７６】
図１３に示す処理を各日に対して行えば、図１２に示すような必要在庫数Nを示すテーブルを得ることができ、先に示した図２の場合のように販売数量が少なく、日々の販売数量が大きく変動する場合でも各ブランチ倉庫6ごと、商品ごとに日別の適正な在庫数を決定することができる。
【００７７】
また、図示はされていないが、夫々のブランチ倉庫には対応する電子メールアドレス等の通知先情報がデータベースに記憶されており、算出された各ブランチ倉庫の適正在庫数の情報は算出されると共に、対応した通知先情報に基づく連絡先に通知されるようになっている。言い換えれば、決定された地域別適性在庫数は、通知先データベースに記憶された前記地域情報毎の通知先情報と関連付けられ、該関連づけた通知先情報応に、自動的或は半自動的（ユーザの承諾入力等に応じて）に所定の通信回線を介して通知される。
【００７８】
上記では、１人の顧客はトナーカートリッジを１個しか購入しないという前提を設けた。しかし、１人の顧客が同じトナーカートリッジを使用する複数台の装置を保有し使用する場合もあり、一度に複数のトナーカートリッジを注文する場合も考えられる。このような場合を考慮すると、顧客単位に購入確率を予測するのではなく、例えば顧客Aの装置A及び装置B、顧客Bに装置A、顧客Cの装置A、装置B及び装置C、...のように装置単位に購入確率を予測するのが望ましく、そのような予測を用いれば上記の手法をそのまま適用できる。
【００７９】
例えば、各装置すべての購入確率を計算し求めることにより、数日後の購入確率を計算することが可能になる。また、機種ごとに購入確率を求めれば、機種に対応した特定の種類のカートリッジが購入される確率を求めることができ、どの機種のカートリッジを幾つ在庫する必要がるかを計算することが可能である。
【００８０】
（発注シーケンス及び表示画面例）
図１４はトナーカートリッジの発注シーケンスの一例を示す図であり、図１５から図１９はトナーカートリッジの発注時にユーザ4の端末装置41に表示される画面の一例を示す図である。
【００８１】
まず、ユーザ4は、端末装置41を介してメインサーバ81にアクセスする。つまり、ユーザ4は、端末装置41で稼動するWebブラウザなどのソフトウェアによりメインサーバ81のURL(Uniform Resource Locator)を指定する。これに応じてメインサーバ81から、ログイン画面に対応するHTML(Hyper Text Markup Language)で記述されたデータ（以下「HTMLデータ」と呼ぶ）が端末装置41に供給され、端末装置41のモニタに図１５に示すログイン画面が表示される。
【００８２】
ユーザ4は、図１４に示すステップS1で、お客様番号に対応するユーザIDを入力し、パスワードを入力した後、[OK]ボタンを押して、ユーザID及びパスワードをメインサーバ81に通知する。尚、ユーザID及びパスワードは、プリンタなどのユーザ（オフィスや事業所）単位に、予め販売者3によって通知されているものとする。
【００８３】
ユーザID及びパスワードを通知されたメインサーバ81は、ステップS2で、顧客情報データベースを参照して、通知されたユーザID及びパスワードに対応するユーザが存在するか否かを判定する。そして、対応するユーザが存在すればユーザ承認を経て、注文画面に対応するHTMLデータを生成し端末装置41に供給する。これにより、端末装置41のモニタには図１６に示す注文画面が表示される。
【００８４】
図１６に示す注文画面は、主に、ユーザが利用している機器に対応するトナーカートリッジのリスト101、決済方法の選択部102、納期の指定部103及び使用済みトナーカートリッジの回収への参加申し込み部104から構成される。尚、納期の指定部103は、下記の[ ]で括った部分がプルダウンし、休日や祭日を除く営業日が指定できるプルダウンメニュー形式が望ましい。その場合、対応メッセージは「ご希望の納期をプルダウンメニューによって指定し、午前/午後の配達時間帯を指定してください」のようになる。
【００８５】
(例) 納期[2000]年[ 2]月[14]日 ●午前 ○午後
リスト101には、トナーカートリッジの型番及び対応する機器の型番、並びに、価格が表示され、トナーカートリッジの型番ごとに注文数を入力するための入力枠が備わっている。尚、図１６には、２種類のトナーカートリッジしか示さないが、実際には、ユーザが利用しているプリンタ、複写機、ファクシミリ装置などの機種すべてに対応するトナーカートリッジの型番がリストされる。
【００８６】
ユーザが利用している機器の情報は、顧客情報データベースの購入製品名フィールドから得られる。この情報に対応する製品名又は型番を有するレコードを製品情報データベースから検索し、そのレコードの関連消耗品フィールドからトナーカートリッジの型番を導き出すことができる。
【００８７】
発注画面の所定項目が入力された後、[送信する]ボタンが押されるとステップS3で、リスと101に対応する注文アイテム及び注文数のデータ、選択部102に対応する決済方法のデータ、指定部103に対応する希望納期のデータがメインサーバ81へ送られる。
【００８８】
尚、図１９には、図１６に対応して更にトナー回収がされた場合の画面例を示す。
【００８９】
次に、メインサーバ81は、受信したデータ及びフラグに従い、ステップS4で注文確認画面に対応するHTMLデータを生成し端末装置41に供給する。これにより、端末装置41のモニタには図１７に示す注文確認画面が表示される。
【００９０】
ユーザ4は、ステップS5で、注文確認画面を参照して、注文内容が正しければ[OK]ボタンを押す。また、誤りや訂正したい内容があれば[Cancel]ボタンを押す。[Cancel]ボタンが押された場合は、端末装置41のモニタに、再び注文画面が表示される。[OK]ボタンが押されれば、図１８のような注文受付の画面が表示される。
【００９１】
メインサーバ81は、注文確認を受信すると、新規受注を示す情報を生成する。この情報には、注文番号、ユーザID、発注履歴、担当の販売者ID、注文日時、注文アイテム、注文数、希望納期、価格及び支払方法などのデータが含まれる。
【００９２】
続いて、メインサーバ81は、顧客情報データベース及び倉庫情報データベースを用いて納期を調べる。具体的には、ユーザIDに対応する最寄りブランチ倉庫#1及び#2フィールドを調べ、倉庫別在庫情報フィールドからそれらのブランチ倉庫6に注文数分の注文アイテムが在庫されているか否かを調べ、その結果から納期を設定する。通常、最寄りブランチ倉庫#1及び#2フィールドに登録されたブランチ倉庫6に在庫があれば翌日には納入可能である。もし、それらのブランチ倉庫6に在庫がなければ、メインサーバ81は、倉庫情報データベースを利用して納期を割り出し、納期を設定する。
【００９３】
次に、メインサーバ81は、ステップS7で上記の受注情報に価格確認要求を含めて、ユーザ4を担当する販売者3へ送る。これは、ユーザへの納入価格は販売者3によって設定され、ユーザとの取引状況によって納入価格が変動するので、それを確認する必要があるからである。この価格確認要求は、販売者3の端末装置31上で稼働するソフトウェアによりただ直ちに処理され、ステップS8で価格確認又は発注取消などの情報がメインサーバ81に返される。又は、この価格確認要求は、ユーザの担当セールスマンの携帯端末32に送信され、ステップS8で、価格確認又は発注取消などの情報がセールスマンによって携帯端末32を通してメインサーバ81に送信される。
【００９４】
メインサーバ81は、価格確認を受信した場合は直ちに、ステップS9で受注情報に発注承認要求を含めて製造者1へ送る。この発注承認要求は、製造者1の端末装置13上で稼働するソフトウェアにより直ちに承認処理されるか、又は、端末装置13を管理するオペレータにより直ちに承認処理され、ステップS10では通常は発注承認が、メインサーバ81に返される。また、価格に誤りがあり、発注取消を示す情報を受信した場合は、対応する受注情報に対して、ステータスを例えば「取消」という形式に変更する。
【００９５】
続いてメインサーバ81は、ステップS11で、発注承認を受信した場合は、発注確認を示す電子メールを生成し、その電子メールをユーザ4及び販売者3に送信する。この電子メールには、注文番号、ユーザ名称、注文日時、注文アイテム、納入数、納期、価格及び販売者3の情報(名称、住所、電話番号及びファクシミリ番号)などの情報が含まれる。
【００９６】
また、受注情報におけるステータスが発注取消を示すステータスである場合は、発注取消確認を示す電子メールを生成し、その電子メールをユーザ4及び販売者3に送信する。この電子メールには、発注取消理由、注文番号、ユーザ名称、注文日時、注文アイテム、納入数、納期、価格及び販売者3の情報(名称、住所、電話番号及びファクシミリ番号)などの情報が含まれる。
【００９７】
以上でトナーカートリッジの発注シーケンスは終了する。ただし、図１４には示さないが、ステップS5でユーザ4が注文確認を送った後、ユーザ4の端末装置41のモニタには図15に示すような注文の継続、注文内容の再確認あるいは注文の終了（ログアウト）を選択するための画面が表示される。ユーザ4が[logout]ボタンを押せば、メインサーバ81と端末装置41との接続が解除される。
【００９８】
このように、ユーザ4は、多種多様のトナーカートリッジの中から利用機器に対応するトナーカートリッジを選択する必要はなく、利用機器に応じたトナーカートリッジを容易に注文することができる。従って、誤った注文を行う可能性が激減され、誤って注文したトナーカートリッジを返品するなどの手間も削減される。さらに、注文画面にはユーザ4に応じた価格が表示されるから、ユーザ4は、トナーカートリッジの購入に必要な費用を直ちに知ることができる。
【００９９】
また、販売者3などからみれば、ユーザ4に応じた価格を提示することができるので、インターネット100を利用したトナーカートリッジの販売を促進して、業務の効率化を図ることが可能になる。さらに、誤った注文による返品を処理する手間も省ける、などの効果がある。
【０１００】
（メインサーバの処理モジュール例）
次に、メインサーバ81が実行する他の処理モジュール例を説明する。
【０１０１】
（受注処理モジュールの手順例：図９のS103）
図２０は受注処理の一例を示すフローチャートで、図１４に示す発注シーケンスに対応するものである。
【０１０２】
ユーザ4からユーザID及びパスワードが送られてくると、顧客情報データベースに基づき、ステップS21で登録ユーザか否かの判定が、ステップS22でパスワードの認証が行われる。登録ユーザであり、パスワードの認証にも成功した場合は、顧客情報データベースに基づき、ステップS23でユーザ4に関する不正情報があるか否かが判定され、なければステップS24で注文画面のHTMLデータを生成する。具体的には、ユーザIDに応じて図１６及び図１９に示すリスト101及び選択部102が生成され、さらに、図１６に示す参加申し込み部104を表示させるか、図１９に示す表示部105を表示するかが決定される。このようにして生成された注文画面のHTMLデータは、ステップS25でユーザ4へ送信される。
【０１０３】
尚、登録ユーザではない、パスワードの認証に失敗した、並びに、ユーザ4に関する不正情報がある場合、処理は終了される。
【０１０４】
続いて、ステップS26で注文データが受信されると、ステップS27で注文データに異常なデータが含まれるか否かが判定され、異常なデータが含まれていれば処理はステップS25へ戻される。また、異常なデータが含まれてなければ、ステップS28で、注文データに基づき図１７に示す注文確認画面のHTMLデータが生成され、ステップS29でユーザ4へ送信される。
【０１０５】
続いて、ステップS30で注文確認を示すデータが受信されたか否かを判定し、もし、キャンセルを示すデータが受信された場合、処理はステップS25へ戻される。また、注文確認を示すデータが受信された場合はステップS31で、顧客情報データベース（具体的には発注履歴など）が更新され、ステップS32で前述した受注情報が生成される。
【０１０６】
（出庫処理モジュールの手順例：図９のS105）
図２１は受注情報に基づく出庫処理の一例を示すフローチャートである。
【０１０７】
ステップS41で１つの受注情報が読み込まれる。そして、受注情報に記録されたユーザID、注文アイテム及び注文数に基づき、ステップS42からS46で在庫確認が行われる。つまり、最寄りのブランチ倉庫#1、最寄りのブランチ倉庫#2、マスタ多倉庫5、ユーザIDに対応する販売者（担当販売者）3、製造者1の順に各ノードの在庫を確認して、最もユーザ4寄りの（あるいは納品時間の短い）ノードに対して出庫手続が行われる。
【０１０８】
例えば、他のノードには在庫がなく、製造者1に在庫があった場合はステップS47からS49において、製造者1、マスタ倉庫5、ブランチ倉庫6の順に出庫手続が行われる。これらの出庫処理は、トナーカートリッジの流れに同期して行われるものであることは言うまでもない。
【０１０９】
また、ブランチ倉庫6及びマスタ倉庫5に在庫がなく、販売者3に在庫があった場合は、ステップS52で販売者3に納品を依頼する。この依頼に応じて販売者3は例えばサービスマンに納品を行わせる。この場合、ステップS50では、サービスマンのモバイル端末32から入力される情報に基づき、受注情報に対応する納品が行われたか否かが判定される。
【０１１０】
また、製造者1にも在庫がない場合は、ステップS53でバックオーダ手続及び受注情報の更新が行われる。
【０１１１】
前記図１３のフローで示したような顧客別の購入確率を利用した適正在庫の計算を予め行い、倉庫情報DBにデータを格納し、そのデータに基き各ブランチ倉庫に適正在庫を持つように、メインサーバ81が各倉庫間の在庫制御を行なうことで前記ステップS42の処理において最寄のブランチ倉庫に在庫が確保されている確率が高くなり、言い換えれば顧客の納期に間に合う倉庫に在庫が存在しない可能性が低くなり、注文から納期までの時間が一日以内など納期の短い注文などにも確実に対応できる仕組みが実現できる。
【０１１２】
（在庫補充処理モジュールの手順例：図９のS106）
図２２に、在庫補充処理モジュールの手順例のフローチャートを示す。
【０１１３】
まず、ステップS61で先に詳細に説明した図１３の必要在庫数算出モジュールに従って、現在の全ての場所で必要在庫数を算出する。ステップS62で算出された必要在庫数と実際の在庫数を比較し、ステップS63で在庫数が不足か否かが判定される。全ての場所で不足がなければそのまま処理を終了する。いずれかに不足があればステップS64に進んで不足分を補充をし、ステップS61に戻って、ステップS64の補充による在庫の変化に基づいて再度全ての場所で現在の必要在庫数を算出する。これらの在庫不足の判定は不足場所が無くなるまで繰り替えされる。
【０１１４】
＜他の必要在庫数算出の概要＞
前記受注確率の算出工程は、前記受注履歴の集計範囲を複数の範囲から選択する工程を含む。又、前記データベースは倉庫ごとの属性を管理するデータベースを含み、前記受注確率を求める顧客データ、該顧客へ出庫している倉庫の他の顧客データ、又は前記倉庫と属性が同じ１つ以上の倉庫の顧客データ、の内の少なくとも１つの顧客データを前記受注履歴データの集計範囲に適用する。又、前記データベースは、該顧客へ出庫している商品の代替商品を管理するデータベースを有し、該商品と代替商品の顧客データを併せて前記受注履歴データの集計範囲に適用する。又、前記代替商品を管理するデータベースは代替商品の優先順位を有し、該優先順位に基き受注履歴データの集計範囲を適用する。又、前記データベースは季節変動を管理するデータベースを更に含み、前記受注確率の算出工程は、前記受注履歴データに季節変動による修正を更に含む。又、前記季節変動は受注履歴データを基にした購入間隔の変動値である。
【０１１５】
（他の必要在庫数算出例）
上記必要在庫数算出例では 顧客レベルで顧客夫々の販売履歴が十分にあり、顧客の購入間隔の分布が統計的確率分布に従う場合について説明を行った。在庫計算の為の母集団の決定においてこの方法が一番精度が高いと考えられる。しかし、実際には顧客の購入履歴が十分に無く母数が少ない為に購入間隔の分布が図２３のように統計的確率分布に従わない場合もある。
【０１１６】
以下、このような場合の母集団決定方法の一例について説明する。同じ消耗品を使用するプリンタなどの本体機器はプリントスピードなどのスペックが同じであればその機器を使用する顧客は一日にプリントする枚数、トナーの消費量などは同じような傾向を示す場合が多い。その為、同じ顧客でなくとも同じ消耗品を使う顧客は同じような購入間隔のばらつきになると考えられる。さらに同じブランチ倉庫の顧客に限定すればその倉庫の配送エリアが例えばオフィス街であったり、工業地帯であるなど地域特性により本体機器の使い方が類似の場合も多いと考えられる。そこで顧客の購入履歴の少ない場合には次にに精度が高い方法としてこの顧客と同じブランチ倉庫のすべての顧客の購入間隔を母集団とすることが考えられる。このようにすることで、例えば図２３のような購入間隔の分布の顧客、図２４のような購入間隔の分布などさまざまな分布の顧客のデータを併せることで図２５のように正規分布に近い分布を得ることが可能になる。
【０１１７】
同様に母集団として採用する範囲を他のブランチ倉庫、他の商品に広げる方法も考えられる。
【０１１８】
１つは、顧客に商品を配送するブランチ倉庫のみでなく、該倉庫と同じ属性をもつブランチ倉庫6から出庫されたトナーカートリッジの出庫履歴を含めて母集団にする方法である。尚、ブランチ倉庫6の属性として、例えば、図２７に一例を示す倉庫属性テーブルのように、倉庫規模、顧客当りの平均出庫金額及び立地（オフィス街、工場街、商店街、住宅地又はその近所にあるといった）などが適切と考えられる。
【０１１９】
別の方法として、上記のすべての倉庫から出庫された同じ種類のトナーカートリッジの出庫履歴を母集団にする方法がある。
【０１２０】
さらに別の方法として、新製品などで該商品そのものの出庫履歴がない、あっても小さいなど、母集団に適さない場合などに、類似商品の出庫履歴を母集団に含める方法である。例えば図２８はある商品の出庫履歴がない又は小さい場合に適用する代替商品テーブルの一例を示す図である。図２８において、「対象商品」とは母集団を必要とする商品、「第１代替商品」とは対象商品の出庫履歴がない又は小さい場合に、出庫履歴を参照する商品、「第２代替商品」とは対象商品及び第１代替商品の出庫履歴がない又は小さい場合に、出庫履歴を参照する商品である。
【０１２１】
（母集団の算出手順例）
以下メインサーバ81が購入確率の計算を行なう為の母集団を決定する処理の一例について説明する。尚、過去の分析結果から予め定められた母数以上であれば購入確率分布が正規分布に従うということが分かっているとし、この条件に適合する母集団をメインサーバ81が検索し、母集団を決定する処理を行なう。
【０１２２】
まずは対象となる顧客の各母集団のデータ数の算出及び該データの統計DBへ格納する処理について図２６のフローチャートで説明する。
【０１２３】
まず、顧客DBから各顧客の所定の商品の販売履歴を読み込む(S2201)。読み込まれたデータから販売履歴のデータ数を算出しデータ数を統計情報ＤＢの第一母集団のフィールドの格納する(S2202)。次に、所定のユーザへの配送担当倉庫のすべての顧客の前記販売履歴のデータ数を算出し、該倉庫の顧客の第二母集団のフィールドに格納する(S2203)。さらにメインサーバ81は、図２７に例示した倉庫属性テーブルから属性が同じブランチ倉庫を抽出する(S2204)。図２７に示した例だと倉庫Aがユーザへの配送担当倉庫だとすると属性が倉庫規模は"中"、1顧客あたり平均出庫金額は"大"、立地は"オフィス街"でありどの属性も一致する倉庫として倉庫Cが抽出される。その後抽出されたブランチ倉庫の前記商品の販売履歴データ数を該倉庫の顧客の第三母集団に格納する(S2205)。
【０１２４】
さらにすべての顧客の前記商品の販売履歴のデータ数を算出し、該倉庫の顧客の第四母集団に格納する(S2206) 。該商品の類似商品を図２８に例示した類似商品テーブルから抽出する(S2207)。例えば、CRG XであればCRG X`, CRG YであればCRG Y`,CRG YYなどがメインサーバ81によって抽出される。これら抽出された商品についてすべての顧客の前記商品及び類似商品の販売履歴のデータ数を算出し、該倉庫の顧客の第五母集団に格納する(S2208)。以上の処理が終了すると顧客別商品別統計情報ＤＢに図２９に例示したようにデータ入力が完了される。
【０１２５】
（購入間隔データの算出手順例）
次に購入確率を計算する為の母集団を統計情報ＤＢに格納された各データ数から決定し、購入間隔データを顧客ＤＢに格納するまでのフローチャートを図３０を用いて説明する。
【０１２６】
まず統計情報ＤＢから各顧客、商品別の各母集団のデータ数を読み込む(S2601）次に統計基礎DBから予め決められた母集団選択に必要な最低データ数Minを読み込む(S2602）。最低データ数Minとは過去の販売履歴データを統計的に分析し、母集団として採用する為に必要だと考えられるデータ数の最低値を予め定めておいて統計基礎DBに登録しておいた数値である。前記閾値Minと前記顧客別商品別各母集団のデータ数とを比較して、閾値Minを超える最低の母集団を選択する(S2603)。閾値Minが500、母集団は前記図２９を例にとると、第1、第2母集団は閾値以下であり条件は満たさないが第三母集団がデータ数578であり条件を満たす最低の母集団であり、この場合は第三母集団が採用されることとなる。但し、すべての母集団が条件を満たさない場合は例外処理が必要になり処理は終了され(S2604)、その後管理者に異常の警告などがされる。尚、本例では閾値Minを超える最低の母集団を選択したが、これは母集団の信頼度が順次低くなることを想定したものであり、実際の母集団の傾向により、より信頼性の高い母集団を選択するように制御するのが望ましい。
【０１２７】
何れかの母集団が採用された場合は該母集団の出庫履歴データが顧客DBから読み込まれる(S2605）。さらに倉庫DBから季節変動データが読み込まれ(S2606）、前記出庫履歴データと前記季節変動データからメインサーバ81が顧客別の購入間隔を算出する(S2607）。季節変動データについては後述詳細に説明する。算出された購入間隔データを顧客ＤＢに格納する(S2608）。
【０１２８】
尚、以上説明した図３０のフローチャートでは説明を簡単にする為に 過去の分析結果から予め定められた母数以上であれば購入確率分布が正規分布に従うということが分かっている場合について説明した。しかし、さらに精度を高める為には統計学で用いられるいくつかの検定方を用いて複数の母集団の中からより信頼性の高いデータを選択する方法も考えられる。
【０１２９】
このようにメインサーバ81が複数の母集団から最適な母集団を検索し、顧客別、商品別の購入確率を求める為の母集団に決定する処理を行なうことで、顧客の販売履歴が少ない場合、倉庫の規模が小さい場合、商品が新しく、該商品そのものの販売履歴がない場合などさまざまな場合でも実施例1で示した方法で適正在庫の計算を行なうことが可能になる。
【０１３０】
（季節変動の算出例）
次に、メインサーバ81によるデータベースで前述した季節変動の算出処理について説明する。
【０１３１】
まず、顧客のある月の購入日を基準に、前回の購入日を調べ、月別の購入間隔を求める。そして、一年間の平均購入間隔を計算し、各月の購入間隔との解離度を算出して季節変動係数とする。
【０１３２】
図３１はある顧客の一年を通した購入間隔、及び、季節変動係数の一例を示す図である。各季節変動係数は、その月の購入間隔を平均購入間隔で割った値として示される。図３１に示されるようなデータが共有DB8に格納されている。メインサーバ81が前記ステップＳ2606で抽出された月別季節変動係数を出庫履歴データから求められるすべての購入間隔データに乗算する。例えば９月１０日に購入した顧客が９月２０日に購入したとすると、購入間隔は１０日であるが図３１の季節変動係数が0.9であるので １０×０.９=９日と計算され ９日が購入間隔のデータとして顧客DBに格納される。尚、前回購入日と最新購入日で月がまたがるときは最新購入日の季節変動係数を採用する。トナーカートリッジはビジネス向けに利用されることが多く、例えば８月などの多くの企業が休暇になる月などは消費が大幅に落ちることが在庫管理上の問題となっていて月別季節変動係数を用いることでこの問題が解決される。
【０１３３】
＜本実施形態の対象となるビジネス消耗品の具体例＞
（レーザビームプリンタの場合）
図３２は、本実施形態のビジネス消耗品を搭載するレーザビームプリンタ(LBP)の構成例を示す概観図である。
【０１３４】
図３２において、イメージスキャナ2201は、原稿画像を読み取り、原稿画像に対してディジタル画像処理を行う。また、プリンタ2202は、イメージスキャナ2201で読み取られた原稿画像に対応した画像を記録紙上に形成し出力する。
【０１３５】
イメージスキャナ2201において、2200は原稿圧板、2203は原稿台硝子（プラテン硝子）で、原稿2204はその記録面を図の下方へ向けて載置され、原稿圧板2200によって固定される。蛍光灯ランプ2205から出力される光は、原稿2204に反射され、ミラー2206、2207及び2208に導かれて、レンズ2209によりリニアCCDイメージセンサ（以下「CCD」と呼ぶ）2210上に結像する。尚、レンズ2209には赤外カットフィルタが設けられている。CCD2210は、原稿2204の反射光を赤(R)、緑(G)及び青(B)の各色に分解して読み取り、得られたアナログ画像信号を画像処理部2211へ送る。ここで、蛍光灯2205及びミラー2206を有するユニットは速度Vで、ミラー2207及び2208を有するユニットは速度V/2で、CCD2210に直交する副走査方向に機械的に移動されることにより、原稿2204の全体が読み取られる。
【０１３６】
CCD2210は、例えば、RGB各色約7500画素の受光画素が3ライン（1210-1から1210-3）に並べられたもので、A3サイズの原稿の短手方向297mmを600dpiの解像度で読み取ることが可能である。もし、A3サイズの原稿の短手方向297mmを400dpiの解像度で読み取るには、RGB各色約5000画素の一次元イメージセンサがあればよい。
【０１３７】
画像処理部2211は、CCD2210から出力されるアナログ画像信号をディジタル画像信号に変換し、印刷用のトナー色に対応するイエロー(Y)、マゼンタ(M)、シアン(C)及びブラック(BK)の各色成分画像を形成してプリンタ2202へ送る。また、イメージスキャナ2201における１回の原稿スキャン（１回の副走査）につきYMCBKのうち一つの色成分画像がプリンタ2202に送られる。従って、４回の原稿スキャンにより４色成分の画像信号を順次プリンタ2202に送出されて一枚のプリントが完了する。尚、画像処理部2211内に必要充分なメモリがあれば、１回の原稿スキャンで得られる画像信号をそのメモリに格納して、残る３回の原稿スキャンを不要にすることもできる。
【０１３８】
このようにして画像処理部2211より順次送出されるYMCBK色成分の画像信号は、プリンタ2202内のレーザドライバ2212へ入力される。レーザドライバ2212は、入力される画像信号に応じてレーザダイオード2213を発光させる。レーザダイオード2213から出力されるレーザ光は、ポリゴンミラー2214、f-θレンズ2215及びミラー2216を介して感光ドラム2217上を走査し、感光ドラム2217上に静電潜像を形成する。
【０１３９】
レーザ光により形成された感光ドラム上の静電潜像は、イエロー、マゼンタ、シアン及びブラックのトナーを有する現像器2219から2222により現像される。つまり、４個の現像器2219から2222が順次感光ドラム2217に当接し、色トナーによる現像が行われる。
【０１４０】
記録紙カセット2224又は2225より供給される記録紙は、静電気の作用により、転写ドラム2223へ巻き付けられ、感光ドラム2217上のトナー像が転写される。４色のトナーを使用する記録処理においては、転写ドラム2223が四回転することで各色のトナーが記録紙へ重畳転写される。その後、記録紙は、転写ドラム2223から剥離され、定着ユニット226でトナー像が定着され、装置外部へ排出される。
【０１４１】
このようなLBPにおいて、感光ドラム2217、現像器2219から2222の中に収容されるトナー又はトナーカートリッジ、並びに、記録紙カセット2224及び2225に収容される記録紙はビジネス消耗品である。
【０１４２】
（インクジェットプリンタの場合）
図29は本実施形態のビジネス消耗品を搭載するインクジェットプリンタ(IJRA)の構成例を示す概観図である。
【０１４３】
図３３において、駆動モータ5013の正逆回転に連動し、駆動力伝達ギア5011及び5009を介して回転するリードスクリュー5004の螺旋溝5005に係合するキャリッジHCは、ピン（不図示）を有し、矢印a及びb方向に往復移動される。このキャリッジHCには、インクジェットカートリッジIJCが搭載されている。
【０１４４】
5002は紙押え板で、キャリッジHCの移動方向に亙って、記録紙Pをプラテン5000に対して押圧する。5007及び5008はフォトセンサで、モータ5013の回転方向を切換えるために、センサが配置された領域にキャリッジHCのレバー5006が存在するか否かを確認するホームポジション検知手段である。5016は記録ヘッドIJHの前面をキャップするキャップ部材5022を支持する部材、5015はこのキャップ内を吸引する吸引手段で、キャップ内開口5023を介して、記録ヘッドIJHの吸引回復を行う。
【０１４５】
5017はクリーニングブレード、5019はこのブレードを前後方向に移動可能にする部材であり、本体支持板5018にこれらが支持されている。クリーニングブレードはこの形態に限らず、周知のクリーニングブレードが本実施形態に適用できることは言うまでもない。また、5021は吸引回復の吸引を開始するためのレバーで、キャリッジHCと係合するカム5020の移動に伴って移動し、駆動モータ5013からの駆動力がクラッチ切換えなどの公知の伝達手段で移動制御される。
【０１４６】
これらのキャッピング、クリーニング及び吸引回復は、キャリッジHCがホームポジション側の領域にきたときに、リードスクリュー5004の作用により、それらの対応位置で所望の処理が行えるように構成されているが、周知のタイミングで所望の作動を行うようにすればよい。
【０１４７】
このようなIJRAにおいて、インクジェットカートリッジIJC又はその中に搭載されるインクがビジネス消耗品である。
【０１４８】
尚、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（又は記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（又はCPUやMPU）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることはいうまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（OS）などが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることはいうまでもない。
【０１４９】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるCPUなどが実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることはいうまでもない。
【０１５０】
本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明した図１４に示すシーケンス、及び/又は、図９、１３、２０−２２、２６、３０に示すフローチャートに対応するプログラムコード、並びに/あるいは、図１２から図１９に示す画面のデータを作成するプログラムコードが格納されることになる。
【０１５１】
【発明の効果】
以上説明したように、本発明によれば、ビジネス消耗品の在庫管理を一元管理することにより、少ない在庫量で短時間にユーザにビジネス消耗品を納品可能な在庫管理による流通制御を提供できる。
【０１５２】
すなわち、倉庫間におけるビジネス消耗品の流通を適正に制御することができる。さらに商品ごと、顧客ごとの出庫履歴を管理できる流通方法であれば倉庫という形態に限らず、例えば事務機器の販売店、量販店などであっても説明した方法でビジネス消耗品の流通を適正に制御することができる。
【図面の簡単な説明】
【図１】出庫数の多い場合の販売実績推移の例を示す図である。
【図２】出庫数の少ない場合の販売実績推移の例を示す図である。
【図３】現状のトナーカートリッジの流れを説明する図である。
【図４】本実施形態におけるトナーカートリッジの流れを示す図である。
【図５】トナーカートリッジの販売回収システムの構成例を示す図である。
【図６】メインサーバを構成するコンピュータの代表的な構成例を示すブロック図である。
【図７】共有データベースの構成例を示す図である。
【図８】主記憶装置の記憶構成例を示す図である。
【図９】本実施形態のメイサーバの動作手順例を示すフローチャートである。
【図１０】購入確率x(t)の一例を示す図である。
【図１１】図１０の購入確率x(t)に対応する購入確率累計z(t)を示す図である。
【図１２】購入周期及び前回の購入日が同じ顧客２人が、あるトナーカートリッジを購入する各日の確率を示す図である。
【図１３】ある商品の必要在庫数を求める手順例を示すフローチャートである。
【図１４】トナーカートリッジの発注シーケンスの一例を示す図である。
【図１５】トナーカートリッジの発注時にユーザの端末装置に表示される画面の一例を示す図である。
【図１６】トナーカートリッジの発注時にユーザの端末装置に表示される画面の一例を示す図である。
【図１７】トナーカートリッジの発注時にユーザの端末装置に表示される画面の一例を示す図である。
【図１８】トナーカートリッジの発注時にユーザの端末装置に表示される画面の一例を示す図である。
【図１９】トナーカートリッジの発注時にユーザの端末装置に表示される画面の一例を示す図である。
【図２０】受注処理の一例を示すフローチャートである。
【図２１】受注情報に基づく出庫処理の一例を示すフローチャートである。
【図２２】出庫処理後の在庫補充処理の一例を示すフローチャートである。
【図２３】ある顧客のトナーカートリッジの購入間隔のばらつきの一例を示す図である。
【図２４】ある顧客のトナーカートリッジの購入間隔のばらつきの一例を示す図である。
【図２５】倉庫全体でのトナーカートリッジの購入間隔のばらつきの一例を示す図である。
【図２６】各母集団のデータ数を算出する一例を示すフローチャートである。
【図２７】倉庫属性テーブルの一例を示す図である。
【図２８】代替商品テーブルの一例を示す図である。
【図２９】商品/顧客別の母集団データ数テーブルの一例を示す図である。
【図３０】ある商品の顧客ごとの母集団を算出して格納する一例を示すフローチャートである。
【図３１】ある顧客の一年を通した購入間隔及び季節変動係数の一例を示す図である。
【図３２】本実施形態のビジネス消耗品を使用するレーザビームプリンタの構成例を示す概観図である。
【図３３】本実施形態のビジネス消耗品を使用するインクジェットプリンタの構成例を示す概観図である。

Claims (1)

1. 商品あるいは顧客単位に時系列の受注確率を管理するデータベースを保持する工程と、
   前記データベースから得られた前記受注確率に基づいて、特定商品について顧客から受注し得る受注数ごとに、時系列に該受注数が発現する確率を求めて記憶する工程と、
   前記受注数が発現する確率に基づいて、特定時期の前記特定商品の適正在庫数を算出する工程とを具備することを特徴とする適正在庫数決定方法。

Images