(57)【要約】【課題】  メーカが管理する在庫について、販社による無制限な引当を抑止し、その在庫の負担者たるメーカでその在庫の引当をコントロール可能にする。【解決手段】  本発明では、在庫の引当てについて、小売業者等の商品の販売に関する販売情報に基づいて、引当に対する制限を示す制限情報を算出し、これに基づいて引当てを含む在庫管理を行うものである。  より具体的には、複数の販売店からの要求される商品についての在庫引き当てを管理する在庫引当システムにおいて、予め前記複数の販売店それぞれについて、当該販売店の販売に関する販売情報、および、前記商品の各々についての在庫情報を記憶し、前記販売店の販売店装置から、商品についての引当要求を受信し、受信された前記引当要求の発信元である前記販売店の販売情報に用いて、前記引当要求で要求される商品についての引当有効日時を算出し、これに基づいて引当をコントロールする。【選択図】  図２
2010182128.tif 000002
【特許請求の範囲】
【請求項１】
複数の販売店からの要求される商品についての在庫引き当てを管理する在庫引当システムにおいて、
予め前記複数の販売店それぞれについて、当該販売店の販売に関する販売情報、および、前記商品の各々についての在庫情報を記憶する記憶装置と、
前記販売店の販売店装置から、商品についての引当要求を受信する受信手段と、
受信された前記引当要求の発信元である前記販売店の販売情報に用いて、前記引当要求で要求される商品についての引当有効日時を算出する算出手段と、
算出された前記引当有効日時および当該商品が引き当てられていること示す情報を、前記在庫情報に対応付けて記憶して記憶する記憶制御手段と、
前記引当有効日時に示す日時の検知に応じて、前記引き当てられていることを示す情報を削除する情報削除手段とを有することを特徴とする在庫引当システム。
【請求項２】
請求項１に記載の在庫引当システムにおいて、
前記販売情報には、少なくとも前記商品の粗利、シェア、価格のいずれか１つが含まれることを特徴とする在庫引当システム。
【請求項３】
請求項２に記載の在庫引当システムにおいて、
前記算出手段は、前記販売情報を構成する各評価項目毎に定められた重み付けの数値を合算し、合算された結果に応じた前記引当有効日時を算出することを特徴とする在庫引当システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の販売店や販社で販売される家電品などの商品の在庫管理に関するもので、その中でも特に、各販売店等からの要求に応じて、統合的に関している在庫についての引当てを管理するための技術に関する。
【背景技術】
【０００２】
従来、小売業者（販売店）が、メーカに対して必要とする商品の引当てを、メーカで管理している在庫に対して行うことがなされていた。例えば、特許文献１には、小売業者が商品在庫を持たずにカタログショッピングなどを行う場合に、構築されている卸売り業者毎に在庫検索・商品発注システムにおける問題を解決するための手法が記載されている。特許文献１では、在庫検索・商品発注システムを複数の小売業者で共用し（ＡＳＰ）、システム構築・運用の手間を省いている。特に、各小売業者はそれぞれ引当限度数の範囲で引当可能とするような技術が提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平１１−７３４７０号公報（[0028]および[0029]）
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１を含む従来技術においては、卸売り業者やメーカにおいて、在庫を管理することになり、さらに在庫に対する負担も卸売り業者やメーカで負担することになっていた。このため、小売業者では、在庫の確保（引当）を行っても、それらが売れなくとも自身に費用負担などのマイナス要因は掛からず、不要な在庫を増加させてしまう恐れがあった。逆に、メーカや卸売り業者は、自身でコントロールできない在庫についての負担だけを担ってしまう、との恐れがあった。
【０００５】
これらは、引当てを行うものが無制限に引当が可能であって、その在庫の負担者がその在庫の引当をコントロールできない、との問題によるものである。この点を解消することが本願の課題となる。
【発明の効果】
【０００６】
本発明によれば、小売業者などの共通在庫に対する引当てを制限することが可能になり、不要な在庫の増大を防止することが可能になる。
【図面の簡単な説明】
【０００７】
【図１】本実施形態の適用先である、商品の流通形態を示す図。
【図２】本実施形態のシステム構成図。
【図３】アロケーションパラメータの算出手順を示すフローチャート。
【図４】実際の管理の流れを示すフローチャート。
【図５】在庫ＤＢ５０１を示す図。
【図６】確保要求ＤＢ５０２を示す図。
【図７】確保設定パラメータＤＢを示す図。
【図８】過去実績ＤＢ８０１を示す図。
【図９】シェア・競争力ＤＢ８０２を示す図。
【図１０】売上規模ＤＢ８０３を示す図。
【図１１】販売政策ＤＢ８０４を示す図。
【図１２】粗利ＤＢ８０５を示す図。
【図１３】製品ライフサイクルＤＢを示す図。
【図１４】アロケーションパラメータ表を示す図。
【図１５】評価項目算出テーブルを示す図。
【発明を実施するための形態】
【０００８】
以下、本発明の実施の形態を、図面を用いて説明する。まず、図1に本実施形態の適用先である、商品の流通形態を示す。商品は、工場１ａで製造され、各流通の中間拠点２ａ〜２ｃに配送される。そして、この中間拠点２ａ〜ｃに存在する商品＝在庫、については各販社（や販売店）３ａ〜ｆで引当がなされ、それぞれ配送される。ここで、中間拠点２ａ〜ｃでの在庫について、情報として引当がなされても中々販社が物理的に引き取らないことがある。また、引当をキャンセルしてしまうこともある。このようなことが生じた場合、工場１ａ側でそれらの在庫のコスト負担をせざるを得なくなる。この問題を本実施形態では解消することを目的とする。このために、引当としての有効期限である引当有効日時を算出し、これに基づいて在庫の管理、すなわち、引き当てられているかの管理を行う。
【０００９】
このためのシステム構成図を、図２に示す。本システムは、生産工場１ａの工場コンピュータ１０、中間拠点２ａ〜ｃの拠点コンピュータ２０、販社３ａ〜ｆの販社コンピュータが３０および統括本部で用いられるデータ集約用コンピュータ４０、アロケーション計算用コンピュータ６０、アロケーションパラメータ用コンピュータ７０がネットワークなどで接続され構成される。そして、統括本部では、データベースサーバ１（６０）やデータベースサーバ２（８０）により、各種データを保持している。なお、統括本部の各コンピュータは一体、それぞれのコンピュータのサブコンビネーションとして構成されても構わない。また、データベース１と２も１つものとして構成してもよい。
【００１０】
次に、図３を用いて、アロケーションパラメータの算出手順について説明する。アロケーションパラメータとは、引当有効日時などの在庫管理のためのデータを算出するためのパラメータであって、商品の属性（シェアなど）から算出するものである。これを、データベースサーバ１に格納しておき、引当有効日時の算出の際に用いる。なお、引当有効日時などの算出については、図４を用いて後述する。
【００１１】
では、図３について説明する。まず、ステップｓ１０にて、アロケーションパラメータ用コンピュータ７０は、データベースサーバ２から各種ＤＢを読み込む。具体的には、アロケーションパラメータを算出すべき商品もしくは販社の少なくとも一方の指定を受け付ける。これは、管理者などからの入力に従ってもよいし、周期的に起動されるようにしてもよい。特に、周期的に行う場合、各商品のアロケーションパラメータをまとめて算出するように構成してもよい。この場合、タイマー機能で起動される。
【００１２】
そして、指定された、すなわち、算出が必要な商品の各データの要求をデータベースサーバ２に送信する。これは、製品名称などの商品を識別する情報と販社を識別する情報を含む検索要求をデータベースサーバ２に送信することになる。そして、データベースサーバ２では、この要求に対応する各データを検索する。すなわち、各ＤＢ（８０１〜８０６）の対応する「評価値」を検索する。より具体的には、販社Ａのアロケーションパラメータを算出する場合、各ＤＢの「販社Ａ」に対応付けられているデータ、つまり、過去実績ＤＢ８０１からは「過去実績評価値」＝４、シェア・競争力ＤＢ８０２からは「シェア・競争力評価値」＝３、売上規模ＤＢ８０３からは「売上規模評価値」＝３、販売政策ＤＢ８０４からは「販売政策評価値」＝４、粗利ＤＢ８０５からは「粗利評価値」＝４、製品ライフサイクルＤＢ８０６からは「ライフサイクル評価値」＝３がそれぞれ検索される。
【００１３】
なお、これらの各評価値は、統括本部の管理者などがそれまでの経験などで入力しておくことで、データベースサーバ２に格納されている。また、関連するデータを各ＤＢに格納し、それから算出するようにしてもよい（予め定められた規則に従って）。この場合、図15に示す「評価項目算出テーブル」に従って、各データ(例えば、販売規模について、販社Ａ＝５．５億円)に対応する評価値（この例の場合、「３」）を算出し格納する。また、各種データは、工場コンピュータ１０、拠点コンピュータ２０および販社コンピュータ３０からネットワークを介してデータ集約用コンピュータ４０が収集して、格納されるようにしてもよい。
【００１４】
そして、データベースサーバ２からアロケーションパラメー用コンピュータに、検索された各評価値がいずれの項目かを識別される形で送信される。これで、ステップｓ１０の各ＤＢの読込みを終わり、ステップｓ２０に進む。なお、ここでは、販社のみが指定された場合を例に説明したが、商品も指定されている場合には以下のように検索処理を実現する。それは、各ＤＢで商品毎のデータ(レコード)もあるものについては、指定された販社と商品の両方を含むもの、商品はなく販社ごとのデータ(レコード)しかないものはその販社のレコードの評価値を検索結果とする。このため、本実施形態では、以下の態様その１つにも含まれる。それは、まず「販社」で各ＤＢを検索し、その検索結果に対して「商品」(商品が指定されている場合)で検索をかける。この後の検索の結果、「商品」に対応するものが検索されなかった場合、「販社」で検索された結果を最終的な検索結果として出力する。
【００１５】
ステップｓ２０において、アロケーションパラメータ用コンピュータ７０は、送信された各評価値を用いて販社別（および／または商品別）のパラメータを算出する。上述のように検索された各評価値について、図15に示す「評価項目算出テーブル」の重み付けを掛け合わせる。そして、その結果を合算する。
つまり、「過去実績評価値」4X3 ＋「シェア・競争力評価値」3X4＋「売上規模評価値」 3X4＋「販売政策評価値」4X3＋「粗利評価値」4X5＋「ライフサイクル評価値」3X1＝71を算出する。なお、本例では、各評価値が満点(５点)のとき、重み付け計算後の合算値は100となる。このため、満点評価100に対して販社Ａの評価値71であり、図14に示すアロケーションパラメータ表に従いアロケーションパラメータ値を取得する。つまり、パラメータ値＝１が特定できる。この結果、本例（販社Ａの）例では、パラメータ値が1となるので図１５のアロケーションパラメータ表に従って、数量、納期ともに要求内容で在庫を確保することになる。つまり、このことを示す情報を、登録しておく。なお、図１４、１５に示す表は、アロケーションパラメータ用コンピュータ７０に格納されているものとする。なお、重み付けなど図１５の「評価項目算出テーブル」の各データは、管理者などが経験を元に各データを特定し、その内容がデータベースサーバ１のアロケーションパラメータＤＢ５０３に格納される。なお、この場合、販社を特定せず、各データを取り込む構成としてもよい。
【００１６】
次に、図４を用いて、実際の管理の流れを説明する。まず、ｓ１において、アロケーション計算用コンピュータ６０は、所定タイミングなど予め定められた起動条件を満たした場合、データベースサーバ１（５０）の各ＤＢのデータを読み込む。すなわち、処理が要求されている条件として販社の引当有効日時を算出したい場合、販社を識別する情報を含む検索要求を、アロケーション計算用コンピュータ４０からデータベースサーバ１に送信する。この結果、在庫ＤＢ５０１、販社確保要求ＤＢ５０２およびアロケーションパラメータＤＢ５０３から、対応するレコード(ここでは、販社Ａを例に以下説明する)が検索され、アロケーション計算用コンピュータ６０に返される。
【００１７】
次に、ステップｓ２において、アロケーション計算用コンピュータ７０は、確保要求ＤＢ５０２に格納された（販社コンピュータ３０から送信され）販社要求の確保期限が、当日を超過しているか判断する。これは、当該コンピュータ内の時計（タイマー）機能との突合せで判断する。この結果、超過している場合にはｓ２−１に進み、超過していない場合にはｓ３に進む。
【００１８】
次に、ｓ２−１、ｓ２−３、つまり、ｓ２において「超過している」と判断された場合のアロケーション計算用コンピュータ６０の処理について説明する。ｓ２−１において、在庫DB５０１について、販社確保要求DB期限経過の確保済在庫を引当可能在庫に戻し入れ処理を行う。つまり、販社Ａでのプラズマ１の確保要求が確保要求ＤＢ５０２から「３０」と判断されるので、在庫ＤＢ５０１の「プラズマ１」の確保済数３０をそれぞれ０とする（判断された確保要求「３０」を減算する）。そして、未確保数７０に３０を加え、100とする。
【００１９】
次に、ステップｓ２−２において、予め登録された販社、工場、中間拠点（のコンピュータ）のメールアドレスに対して、変更があった旨を示すメールを送信する。この場合、在庫ＤＢの更新内容を通知してもよいし、在庫ＤＢにアクセスするための情報（ｕｒｌ）を送信するようにしてもよい。
【００２０】
そして、ｓ３において、確保期限まで一定期間前（例えば3日前）を切っていないかを判断する。この結果、該当する場合には、当該データの販社等のコンピュータにその旨を示すアラームメールを送信する（ｓ４）。そうでない場合には、ｓ５に進む。
【００２１】
なお、ｓ２、ｓ３の判断に関しては、ｓ１で販社を特定しない場合、読み込んだ各データについて、その条件を満たすかを判断し、各データについてそれぞれの処理を実行する。
【００２２】
ｓ５、ｓ６において、データ集約用コンピュータ４０が、工場コンピュータ１０や拠点コンピュータ20から送信される情報に従って、在庫ＤＢ５０１の総在庫数（および未確保数）を更新する。つまり、工場コンピュータ１０から在庫から製品の出荷実績や出荷計画を受信し、拠点コンピュータ２０から在庫数を受信し、この結果に応じて在庫ＤＢ５０１の総在庫数（および未確保数）を更新する。この場合、工場コンピュータ１０からの出荷数を現状の総在庫数に加え、これを仮登録とし、拠点コンピュータ２０から情報で本登録としてもよい。
【００２３】
また、ｓ７において、販データ集約用コンピュータ４０が、社コンピュータ３０からの確保要求データに従って確保要求DB更新する。すなわち、販社コンピュータから送信された確保要求数を、在庫ＤＢ５０１の「確保要求数」に加えてそれを更新する。
【００２４】
このように在庫ＤＢ５０１が更新されたことをトリガに（もしくは一定周期ごとに更新を行う場合、その周期に従って）、ｓ９において、アロケーション計算用コンピュータ６０は、アロケーションパラメータＤＢに格納されたパラメータ値を用いて、販社/商社別に数量・確保期限を自動設定し、在庫DB、確保要求DBを更新する。すなわち、販社ごとに定められた図14に示す「計算方法」に従ってその確保期間を計算し、確保要求ＤＢの「確保計算結果」の確保期限に格納する。
【００２５】
そして、ｓ９において、アロケーション計算用コンピュータ６０は、予めメールアドレスが登録されている各工場コンピュータ１０、拠点コンピュータ２０および販社コンピュータ３０にデータベースが更新されたことを示すメールを送信する。以上で、本実施形態の説明を終わる。このように、データベースサーバ２に格納されるような複数の側面を有する販社（商品）の属性を考慮したパラメータを設定することで、より精度の高い「確保期限」＝在庫有効日時を計算することが可能になり、ひいてはより効率的な在庫管理が可能になる。
【符号の説明】
【００２６】
１０…工場コンピュータ、２０…拠点コンピュータ、３０…販社コンピュータ、４０…データ集約用コンピュータ、５０…データベースサーバ１、６０…アロケーション計算用コンピュータ、７０…アロケーションパラメータ用コンピュータ、８０…データベースサーバ８０
【図１】
2010182128.tif 000003
【図２】
2010182128.tif 000004
【図３】
2010182128.tif 000005
【図４】
2010182128.tif 000006
【図５】
2010182128.tif 000007
【図６】
2010182128.tif 000008
【図７】
2010182128.tif 000009
【図８】
2010182128.tif 000010
【図９】
2010182128.tif 000011
【図１０】
2010182128.tif 000012
【図１１】
2010182128.tif 000013
【図１２】
2010182128.tif 000014
【図１３】
2010182128.tif 000015
【図１４】
2010182128.tif 000016
【図１５】
2010182128.tif 000017