特許 6572514 注文管理システム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6572514

(24)【登録日】2019年8月23日

(45)【発行日】2019年9月11日

(54)【発明の名称】注文管理システム

(51)【国際特許分類】

   G06Q 10/06 20120101AFI20190902BHJP

   G06Q 30/06 20120101ALI20190902BHJP

【ＦＩ】

   G06Q10/06 302

   G06Q30/06 304

【請求項の数】2

【全頁数】13

(21)【出願番号】特願2015-72000(P2015-72000)

(22)【出願日】2015年3月31日

(65)【公開番号】特開2016-192082(P2016-192082A)

(43)【公開日】2016年11月10日

【審査請求日】2018年1月4日

(73)【特許権者】

【識別番号】000110217

【氏名又は名称】トッパン・フォームズ株式会社

(74)【代理人】

【識別番号】100141139

【弁理士】

【氏名又は名称】及川 周

(74)【代理人】

【識別番号】100140774

【弁理士】

【氏名又は名称】大浪 一徳

(74)【代理人】

【識別番号】100206999

【弁理士】

【氏名又は名称】萩原 綾夏

(74)【代理人】

【識別番号】100064908

【弁理士】

【氏名又は名称】志賀 正武

(74)【代理人】

【識別番号】100134544

【弁理士】

【氏名又は名称】森 隆一郎

(74)【代理人】

【識別番号】100188558

【弁理士】

【氏名又は名称】飯田 雅人

(72)【発明者】

【氏名】小林 末衣

(72)【発明者】

【氏名】高橋 雅幸

(72)【発明者】

【氏名】村上 賢司

【審査官】 阿部 潤

(56)【参考文献】

【文献】 特開２０１０−０４４４５２（ＪＰ，Ａ）

【文献】 特開２００３−０９９６５９（ＪＰ，Ａ）

【文献】 特開２００４−１４５５９０（ＪＰ，Ａ）

【文献】 特開２００２−２０７７９９（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ９９／００

(57)【特許請求の範囲】

【請求項1】

複数の発注候補と、前記発注候補を管理する管理部門から構成される発注候補群のうち第１発注候補から商品を注文する注文情報を受信する受信部と、
前記注文情報に含まれる商品の注文数量と商品毎に定められた数量の基準値とを比較する比較部と、
前記比較結果において前記注文数量が前記基準値未満である場合には、前記発注候補群のうち前記第１発注候補以外の発注候補のうち少なくとも１つの発注候補を選定して前記管理部門に通知し、前記管理部門から前記選定された発注候補の承認通知を受信すると、前記選定された発注候補に、前記注文があった商品の注文数量が基準値未満であることを通知する通知部と
を有する注文管理システム。

【請求項2】

前記通知部は、前記複数の発注候補のそれぞれに設定される、前記商品を注文する可能性を表す発注可能性指数に基づいて、前記商品を注文する可能性が高い順に、前記通知を行う請求項１記載の注文管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、印刷物等をネットワークを介して注文販売する注文管理システムに関する。

【背景技術】

【0002】

印刷物を発注する場合、複数のグループのそれぞれが少量の注文数量で個別に発注するよりも、纏まった注文数量にて１度に発注した方が、商品価格が安くなる場合がある。特許文献１には、発注量の少ない商品であっても、価格を抑えて高品質の商品を提供できるようにしたシステムが開示されている。纏めて注文する場合、経理部や総務部等の備品管理を行う部署が、個々の代理店の発注状況や在庫状況を把握したうえで、商品の発注を取り纏めて注文を行うことが考えられる。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００１−２２２５８４号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、代理店が全国に数千店舗存在するような企業が纏めて注文を行う場合、個々の代理店の発注状況や在庫状況を把握したうえで、発注管理者が取り纏めて発注することは、非常に煩雑である。

【0005】

本発明は、上述の課題を鑑み、個々の発注候補での発注状況や在庫状況を把握したうえで取り纏め発注を簡単に行える注文管理システムを提供することを目的としている。

【課題を解決するための手段】

【0006】

上述の課題を鑑み、本発明の一態様に係る注文管理システムは、複数の発注候補と、前記発注候補を管理する管理部門から構成される発注候補群のうち第１発注候補から商品を注文する注文情報を受信する受信部と、前記注文情報に含まれる商品の注文数量と商品毎に定められた数量の基準値とを比較する比較部と、前記比較結果において前記注文数量が前記基準値未満である場合には、前記発注候補群のうち前記第１発注候補以外の発注候補のうち少なくとも１つの発注候補を選定して前記管理部門に通知し、前記管理部門から前記選定された発注候補の承認通知を受信すると、前記選定された発注候補に、前記注文があった商品の注文数量が基準値未満であることを通知する通知部とを有することを特徴とする。

【発明の効果】

【0007】

本発明によれば、複数の発注候補から構成されるような発注候補群において、第１発注候補からの商品の注文があると、その注文された商品の注文数が基準値未満であれば、発注候補群における他の発注候補に対して注文が基準値に到達していないことを通知することができる。これにより、注文数が不足している商品を各発注候補に認識してもらうことができ、商品の注文を行うか否かの判断をしてもらうことが可能となる。これにより、一度に纏まった注文数量で発注を行うことが可能となる。

【図面の簡単な説明】

【0008】

【図1】本発明の第１の実施形態に係る注文管理システムの概略構成を示すブロック図である。

【図2】本発明の第１の実施形態に係る注文管理システムにおける注文サーバの機能に基づくブロック図である。

【図3】本発明の第１の実施形態に係る注文管理システムにおいて記憶部に格納されるテーブルの説明図である。

【図4】本発明の第１の実施形態に係る注文管理システムにおいて記憶部に格納されるテーブルの説明図である。

【図5】本発明の第１の実施形態に係る注文管理システムにおいて記憶部に格納されるテーブルの説明図である。

【図6】本発明の第１の実施形態に係る注文管理システムにおいてメールの説明図である。

【図7】本発明の第１の実施形態に係る注文管理システムにおける候補者確認画面の説明図である。

【図8】本発明の第１の実施形態に係る注文管理システムにおける発注可能性指数の算出処理を示すフローチャートである。

【図9】本発明の第１の実施形態の動作を示すシーケンス図である。

【発明を実施するための形態】

【0009】

以下、本発明の実施の形態について図面を参照しながら説明する。図１は、本発明の第１の実施形態に係る注文管理システムの概略構成を示すブロック図である。

【0010】

図１に示すように、本発明の第１の実施形態に係る注文管理システム１は、注文サーバ１１と、管理グループ端末１２と、グループ端末１３ａ、１３ｂ、１３ｃとから構成される。注文サーバ１１、管理グループ端末１２、グループ端末１３ａ、１３ｂ、１３ｃは、インターネット等のネットワーク１４を介して、互いに接続可能とされている。ここでは、グループ端末は、グループ端末１３ａ、１３ｂ、１３ｃの３つである場合について説明するが、４以上であってもよい。

【0011】

注文サーバ１１は、例えば、商品販売会社が運営するサーバであり、ネットワーク１４を介して商品の注文を受け付け、商品の注文の受付け、販売管理を行う。注文サーバ１１で扱う販売対象の商品は、例えば、帳票やカタログ等の印刷物である。なお、商品は印刷物以外の物品であってもよい。例えば、商品は、文房具、プリンタの消耗品、日用品等であってもよい。

【0012】

管理グループ端末１２は、商品購入を行う顧客となる会社の管理部門に置かれる端末である。例えば、会社の経理部や総務部が備品の管理や、商品の購入の管理を行っている場合、経理部や総務部が管理グループとなり、管理グループ端末１２は、経理部や総務部の端末となる。グループ端末１３ａ、１３ｂ、１３ｃは、商品の発注を行う１つの単位となるグループの端末である。例えば、支店単位でサービスを展開している会社では、支店単位で商品の購入を行っている。このような場合には、支店が１つのグループとなり、グループ端末１３ａ、１３ｂ、１３ｃは、支店に置かれる端末である。

【0013】

グループ群１０は、例えば、１つの会社のさまざまな部署や拠点に設けられるグループ端末が含まれる。ここでは、グループ群１０を構成するグループ端末は、管理グループ端末１２と、グループ端末１３ａ、１３ｂ、１３ｃである。グループ群１０は、複数のグループから構成される。グループは、その会社に所属する複数の事業所、支店、部門等であってもよい。また、発注するグループは、経理部門や総務部門等、特定の部門によって行われてもよいし、いずれかの任意のグループによって行われてもよい。ここでいう、グループは、発注候補であればよく、例えば、複数人から構成される団体や、個人単位の発注者であってもよい。
また、グループ群１０には、異なる会社（グループ）がグループとして含まれるように構成されてもよい。例えば、互いに提携関係がある複数の企業がそれぞれグループとして含まれており、それぞれにグループ端末が設けられていてもよい。

【0014】

図２は、注文サーバ１１の機能を表す概略ブロック図である。図２に示すように、注文サーバ１１は、通信部１０１と、制御部１０２と、記憶部１０３とから構成される。

【0015】

通信部１０１は、ネットワーク１４を介して、管理グループ端末１２、グループ端末１３ａ、１３ｂ、１３ｃとの通信を行う。制御部１０２は、ＣＰＵ(Central Processing Unit)等からなり、プログラムを実行して、注文サーバ１１が提供する各種のサービスを記憶部１０３に記憶されたプログラムを読み出して実行することにより実現する。

【0016】

制御部１０２は、受信部１１１と、比較部１１２と、発注可能性指数比較部１１３と、候補者選定部１１４と、通知部１１５と、を有している。

【0017】

受信部１１１は、管理グループ端末１２やグループ端末１３ａ、１３ｂ、１３ｃからの注文情報を受信する。比較部１１２は、期限日までの注文数量が目標部数（基準値）に達しているかどうかを判定する。発注可能性指数比較部１１３は、過去の注文回数、最終発注日から現在日までの差日数、過去の注文部数、想定使用量と在庫数等から、発注可能性指数を算出する。候補者選定部１１４は、発注可能性指数比較部１１３で求められた発注可能性指数に基づいて、商品の発注の可能性の高い候補グループを選定する。通知部１１５は、比較部１１２での比較結果や、候補者選定部１１４での選定結果に基づいて、管理グループ端末１２やグループ端末１３ａ、１３ｂ、１３ｃに、電子メールやウェブページで各種の通知を行う。

【0018】

記憶部１０３には、カートテーブル１２１、注文履歴テーブル１２２、回数・ポイントテーブル１２３、差日数・ポイントテーブル１２４、部数・ポイントテーブル１２５、残日数・ポイントテーブル１２６、想定消費量テーブル１２７、在庫テーブル１２８が格納されている。

【0019】

図３（Ａ）に示すように、カートテーブル１２１は、カートＩＤと、製品ＩＤと、目標部数と、納期と、通知期限日数の項目からなる。カートテーブル１２１は、管理グループ端末１２からの商品の取り纏め発注のイベントが発生したことにも基づいて、制御部１０２が各商品毎に生成してカートテーブル１２１に記憶する。

【0020】

図３（Ｂ）に示すように、注文履歴テーブル１２２は、カートＩＤと、ユーザＩＤと、製品ＩＤと、注文部数と、在庫数と、注文日の項目からなる。注文履歴テーブル１２２は、管理グループ端末１２や、グループ端末１３ａ、１３ｂ、１３ｃ等のグループ端末から商品の注文情報を受信した制御部１０２によって生成される。

【0021】

回数・ポイントテーブル１２３、差日数・ポイントテーブル１２４、部数・ポイントテーブル１２５、残日数・ポイントテーブル１２６は、発注可能性指数比較部１１３で発注可能性指数を計算する際に用いられる。回数・ポイントテーブル１２３、差日数・ポイントテーブル１２４、部数・ポイントテーブル１２５、残日数・ポイントテーブル１２６は、それぞれ、記憶部１０３に予め記憶される。

【0022】

回数・ポイントテーブル１２３には、図４（Ａ）に示すように、製品ＩＤ毎に、注文回数に対応するポイント数が格納される。差日数・ポイントテーブル１２４には、図４（Ｂ）に示すように、製品ＩＤ毎に、最終注文日と現在の日付との差日数に対応するポイント数が格納される。部数・ポイントテーブル１２５には、図４（Ｃ）に示すように、製品ＩＤ毎に、過去の注文部数の平均に対応するポイント数が格納される。残日数・ポイントテーブル１２６には、図４（Ｄ）に示すように、製品ＩＤ毎に、在庫の残日数に対応するポイント数が格納される。

【0023】

想定消費量テーブル１２７及び在庫テーブル１２８は、各ユーザＩＤ毎に、製品の在庫が尽きる（在庫が０になる）までの残日数を算出するのに用いられる。想定消費量テーブル１２７には、図５（Ａ）に示すように、ユーザＩＤ、製品ＩＤ毎に想定される一日当たりの消費量が格納される。在庫テーブル１２８には、図５（Ｂ）に示すように、ユーザＩＤ、製品ＩＤ毎に、在庫数が格納される。

【0024】

本発明の第１の実施形態に係る注文管理システム１では、１つの会社のようなグループ群で注文数が目標部数以上となるように、経理部や総務部のような管理グループで商品の取り纏めを行い、各グループに商品の購入を促すことができる。これにより、遠隔地にあるグループや、お互いの交流が少ないグループがグループ群に所属していたとしても、纏まった注文数量にて１度に発注を行い、商品購入価格を安く抑えることが可能となる。

【0025】

図１及び図２において、商品を纏めて発注するイベントを行う際、管理グループの担当者は、管理グループ端末１２により注文サーバ１１にログインし、纏め発注のカートの作成を行う。このような纏め発注のカートを作成すると、図３（Ａ）に示したカートテーブル１２１にレコードが追加される。なお、この例では、１カートＩＤについて、１つの製品のレコードが生成される。

【0026】

カートの作成が行われると、注文サーバ１１は、全てのグループ端末１３ａ、１３ｂ、１３ｃに、案内メールＤ１を送付する。この案内メールＤ１には、図６（Ａ）に示すように、イベントの内容、対象製品、目標部数等が記載されている。また、この案内メールＤ１には、商品を発注する際のアドレス（ＵＲＬ；Uniform Resource Locator）が含まれている。

【0027】

各グループの担当者は、送られてきた案内メールＤ１をグループ端末にて受信し、表示画面上に表示させて確認する。そして、各グループの担当者は、対象となる商品の購入を希望する場合には、グループ端末１３ａ、１３ｂ、１３ｃのいずれかから、案内メールＤ１に記載されているアドレスをアクセスし、商品の注文の入力を行う。

【0028】

図２における注文サーバ１１の受信部１１１は、グループ端末１３ａ、１３ｂ、１３ｃから、注文情報を受信する。商品の注文が行われ、グループ端末から注文内容を表す情報（注文元のグループを表すユーザＩＤ、製品ＩＤ、注文数量（注文部数）等）が送信され、注文サーバ１１が受信すると、図３（Ｂ）に示した注文履歴テーブル１２２に、注文情報が生成される。すなわち、注文が確定すると、注文を行ったグループがユーザＩＤとして入力され、注文した製品の製品ＩＤと、注文部数と、在庫数と、注文日が注文履歴テーブル１２２に入力され書き込まれる。

【0029】

比較部１１２は、注文サーバ１１の受信部１１１で受け付けた注文数と、カートテーブル１２１の目標部数とを比較している。そして、注文数量が目標部数未満である場合には、通知部１１５は、管理グループ端末１２に通知メールＤ２を送信する。ここでは、製品ＩＤ毎に目標部数が対応付けて記憶部１０３に記憶されている。

【0030】

つまり、図３（Ｂ）に示した注文履歴テーブル１２２には、グループ端末１３ａ、１３ｂ、１３ｃから注文がある毎に、注文情報が生成される。比較部１１２は、この注文履歴テーブル１２２の注文部数の項目から、カートＩＤ毎に注文部数を合算し、カートＩＤ毎の注文部数の総数を算出する。そして、比較部１１２は、対応するカートＩＤについて、図３に示したカートテーブル１２１の目標部数と、算出した注文部数の総数とを比較する。また、比較部１１２は、図３（Ａ）に示したカートテーブル１２１の納期から通知期限日数を減じた日付を求め、現在の日付と比較し、現在の日付が納期から通知期限日数を減じた日付を越えているかを判定する。そして、通知部１１５は、（現在日付＞納期−通知期限日数）という条件と、（目標部数＞注文部数の合算値）という条件が共に満足する場合に、管理グループ端末１２に、図６（Ｂ）に示すような、注文対象の製品の注文数量が基準値に到達していないことを表す通知メールＤ２を送信する。管理グループの担当者は、この通知メールＤ２により、注文数が目標部数に達していないことを確認する。そして、管理グループの担当者は、通知メールＤ２に含まれているアドレスをアクセスし、注文状況の確認を行う。

【0031】

注文サーバ１１の発注可能性指数比較部１１３は、注文状況の確認を受けると、過去の注文回数、最終発注日から現在日までの差日数、過去の注文部数、想定使用量と在庫数等から、発注可能性指数を算出する。発注可能性指数の算出については、後に詳述する。そして、注文サーバ１１の候補者選定部１１４は、この発注可能性指数の大きいグループの順に、商品を発注する可能性の高いグループとして、候補者（ユーザＩＤ）を抽出する。そして、通知部１１５は、抽出された候補者（ユーザＩＤ）及び発注可能性指数の情報を管理グループ端末１２に送信する。

【0032】

管理グループ端末１２には、図７に示すように、候補者確認画面Ｗ１が表示される。候補者の欄には、ユーザＩＤに対応するグループの名称が表示される。ポイントは、発注可能性指数を表す。管理グループ端末１２の担当者は、この候補者確認画面Ｗ１で候補者を確認し、承認する対象の候補者について、チェックボックスにチェックマークを入力し、確定ボタンをクリックすることで、グループ端末から注文サーバ１１に承認通知を送信する。

【0033】

注文サーバ１１は、候補者の承認通知を受信すると、選定された候補者のグループ端末１３ａ、１３ｂ、１３ｃに、案内メールＤ３を送信する。この案内メールＤ３には、図６（Ｃ）に示すように、イベントの内容、対象製品、不足数、促進メッセージ等が記載されている。また、この案内メールＤ３には、商品を発注する際のアドレス（ＵＲＬ）が含まれている。

【0034】

各グループの担当者は、候補者として送られてきた案内メールＤ３を確認し、不足数や促進メッセージを読む。対象となる商品の購入を希望する場合には、候補者となる各グループの担当者は、グループ端末１３ａ、１３ｂ、１３ｃのいずれかの自身に利用可能に割当てられているグループ端末によって、案内メールＤ３に含まれているアドレスをアクセスし、商品の注文を行う。このときの注文画面には、デフォルトでは、目標部数に足りない注文数量を表示される。不足部数は、カートテーブル１２１の目標部数から、注文履歴テーブルの対象商品の注文部数の合算値を減算することで注文サーバ１１において求められる数である。

【0035】

なお、図６（Ｃ）に示したように、候補となるグループ端末１３ａ、１３ｂ、１３ｃに送付される案内メールＤ３には、不足部数が記載されている。また、上述のように、候補者となるグループ端末１３ａ、１３ｂ、１３ｃにより、案内メールＤ３に含まれているアドレスをアクセスしたときには、そのアクセスした時点において不足している数量が注文ンサーバ１１において計算され、グループ端末に表示される。このように、候補者となるグループ端末１３ａ、１３ｂ、１３ｃの担当者は、案内メールＤ３が送られてきた時点での不足部数と、注文サーバ１１にアクセスした時点での不足部数とを把握し、ＵＲＬにアクセスすることで、その時点におけるリアルタイムでの不足部数を把握することができる。

【0036】

本実施形態では、注文サーバ１１にアクセスした時点で、不足部数が表示されるため、現時点での不足部数を考慮して、注文を行うことができる。例えば、案内メールＤ３が来た時点では目標部数に達していなかったが、現時点では、他のグループが商品を注文しており、目標部数に達している場合がある。このような場合には、候補者となるグループ端末１３ａ、１３ｂ、１３ｃの担当者は、商品を購入しようとして注文サーバ１１にアクセスしたとしても、注文サーバ１１にアクセスした時点で目標部数に達していることを知ることができる。これにより、目標部数に達しているため、価格が抑えられていることが確定しているので、一緒に注文することもできるし、現在のイベントでは目標部数に達しているため、次回のイベントの際に一緒に注文することで他のグループへの協力をすることもできる。

【0037】

注文数量が目標部数以上である場合には、注文サーバ１１の通知部１１５は、管理グループ端末１２に目標到達メールＤ４を送信する。図６（Ｄ）に示すように、この目標到達メールＤ４には、纏め購入が確定したメッセージが含まれる。また、注文数量が目標部数以上である場合には、注文サーバ１１の通知部１１５は、グループ端末１３ａ、１３ｂ、１３ｃに、目標到達メールＤ５を送信する。図６（Ｅ）に示すように、この目標到達メールＤ５には、纏め購入が確定したメッセージが含まれる。

【0038】

なお、発注可能性指数の大きさに基づいて、候補者として選定するグループ数は、任意に定めることができる。また、通知を送信したグループから発注を受けたとしても、基準値に到達しなかった場合には、発注可能性指数が低いグループに順に、候補者として通知を行うようにしてもよい。

【0039】

次に、本発明の第１の実施形態に係る注文管理システム１における発注可能性指数の算出処理について説明する。上述のように、本発明の第１の実施形態に係る注文管理システム１では、発注可能性指数比較部１１３で発注可能性指数を算出し、候補者選定部１１４で、求められた発注可能性指数に基づいて、商品の発注の可能性の高い候補者を選定している。発注可能性指数は、過去の注文回数、前回の注文からの日数、過去の発注数量、想定される在庫日数等により算出され、発注の可能性の高さを示す指標となるものである。

【0040】

図８は、発注可能性指数の算出処理を示すフローチャートである。図８において、発注可能性指数比較部１１３は、過去の注文回数から、付与するポイント数を算出する（ステップＳ１０１）。つまり、過去の注文回数が多ければ、次に商品を注文する可能性が高い。このことから、発注可能性指数比較部１１３は、過去注文回数が多いほど、高いポイントを付与している。

【0041】

過去の注文回数は、図３（Ｂ）に示した注文履歴テーブル１２２の情報から求めることができる。すなわち、注文履歴テーブル１２２から、ユーザＩＤによりグループを抽出し、製品ＩＤにより対象製品を特定して、注文回数を合算することで、ユーザＩＤにより示される各グループ毎の対象製品の注文回数が求められる。また、図４（Ａ）に示したように、回数・ポイントテーブル１２３には、製品ＩＤ毎に、注文回数の範囲と、ポイント数とが対応付けられて格納されている。各グループ毎の対象製品の注文回数が求められたら、発注可能性指数比較部１１３は、回数・ポイントテーブル１２３を参照して、付与するポイントを求める。図４（Ａ）に示すように、この例では、例えば、製品ＩＤがＡ０１についての過去の注文回数が「１」回から「５」回である場合には、１０ポイント付与される。過去の注文回数が「６」回から「１０」回である場合には、２０ポイント付与される。このように、過去の注文回数が多いほど、大きいポイント数が付与される。この過去の注文回数に関し、「過去」は、定められた期間を指定することもできる。

【0042】

次に、発注可能性指数比較部１１３は、最終発注日から現在日までの差日数から、付与するポイント数を算出する（ステップＳ１０２）。商品の発注間隔は、おおよそ決まっている傾向がある。したがって、最終発注日から現在日時までの日数が長いほど、次に商品を注文する可能性は高い。このことから、発注可能性指数比較部１１３は、最終発注日から現在日時までの日数が長いほど、高いポイントを付与している。

【0043】

最終発注日から現在日までの差日数は、図３（Ｂ）に示した注文履歴テーブル１２２の情報から求めることができる。すなわち、注文履歴テーブル１２２から、ユーザＩＤによりグループを抽出し、製品ＩＤにより対象製品を特定して、注文日の項目から最終注文日を取得する。そして、発注可能性指数比較部１１３は、現在の日時から最終発注日を減算して、最終発注日から現在日時までの差日数を求める。また、図４（Ｂ）に示すように、差日数・ポイントテーブル１２４には、製品ＩＤ毎に、最終発注日から現在日までの差日数の範囲と、ポイント数とが対応付けられて格納されている。最終発注日から現在日までの差日数が求められたら、発注可能性指数比較部１１３は、差日数・ポイントテーブル１２４を参照して、付与するポイントを求める。図４（Ｂ）に示すように、この例では、前回注文した日数からの差日数が、６１日から９０日である場合には、３０ポイントが付与される。前回注文した日数からの差日数が、３１日から６０日である場合には、２０ポイントが付与される。このように、前回注文した日数からの差日数が長いほど、大きいポイント数が付与される。

【0044】

次に、発注可能性指数比較部１１３は、過去の注文部数から、付与するポイント数を算出する（ステップＳ１０３）。つまり、過去の注文部数が多ければ、次に注文する可能性が高い。このことから、発注可能性指数比較部１１３は、過去注文部数の平均値が多いほど、高いポイントを付与している。

【0045】

過去の注文部数は、図３（Ｂ）に示した注文履歴テーブル１２２の情報から求めることができる。すなわち、発注可能性指数比較部１１３は、注文履歴テーブル１２２から、ユーザＩＤによりグループを抽出し、製品ＩＤにより対象製品を特定して、注文部数を抽出する。そして、発注可能性指数比較部１１３は、ユーザＩＤにより識別されるグループ毎に、注文部数の平均を算出する。また、図４（Ｃ）に示したように、部数・ポイントテーブル１２５には、製品ＩＤ毎に、注文部数の範囲と、ポイント数とが対応付けられて格納されている。各グループ毎の対象製品の注文部数の平均が求められたら、発注可能性指数比較部１１３は、部数・ポイントテーブル１２５を参照して、付与するポイントを求める。図４（Ｃ）に示すように、この例では、商品ＩＤがＡ０１の商品について、過去の発注の注文数量（部数）が「１」から「１００００」部である場合には、１０ポイントが付与される。「１０００１」から「２００００」部である場合には、２０ポイントが付与される。このように、過去の注文部数の平均が多いほど、大きいポイント数が付与される。この過去の注文部数に関し、「過去」は、定められた期間を指定することもできる。

【0046】

次に、発注可能性指数比較部１１３は、想定使用量と在庫数とから、付与するポイント数を算出する（ステップＳ１０４）。つまり、グループ内にその商品の在庫が多くあれば、次に注文する可能性は低い。その商品の在庫が無くなりそうなら、次に注文する可能性は高い。このことから、発注可能性指数比較部１１３は、想定使用量と在庫数とから、そのグループの在庫があと何日でなくなるかを残日数として算出する。そして、発注可能性指数比較部１１３は、残日数が短いほど、高いポイントを付与している。

【0047】

残日数は、以下のようにして求められる。図５（Ａ）に示す想定消費量テーブル１２７には、ユーザＩＤ及び製品ＩＤ毎に、想定される一日当たりの消費量（部数）が格納されている。この想定消費量テーブル１２７から、ユーザＩＤで識別される各グループ毎に、各製品についての一日当たりの消費量が分かる。

【0048】

また、図５（Ｂ）に示す在庫テーブル１２８には、ユーザＩＤ及び製品ＩＤ毎に、在庫数が格納されている。この在庫テーブル１２８は、在庫を消費する際に、在庫数から減算され、現在の在庫数が分かるようになっている。この在庫テーブル１２８から、ユーザＩＤで識別される各グループ毎に、各製品についての在庫数が分かる。在庫数を一日当たりの消費量で割り算すれば、在庫が尽きるまでの残日数が求められる。発注可能性指数比較部１１３は、このようにして、想定消費量テーブル１２７と在庫テーブル１２８とを用いて、各グループ毎の対象製品についての残日数を算出する。

【0049】

図４（Ｄ）に示したように、残日数・ポイントテーブル１２６には、製品ＩＤ毎に、残日数とポイント数とが対応付けられて格納されている。各グループ毎の対象製品についての残日数が求められたら、発注可能性指数比較部１１３は、残日数・ポイントテーブル１２６を参照して、付与するポイントを求める。図４（Ｄ）に示すように、この例では、商品ＩＤがＡ０１の商品について、残日数が「１」日である場合には、８０ポイントが付与される。残日数が「２」日である場合には、６０ポイントが付与される。このように、残日数が短いほど、大きいポイント数が付与される。

【0050】

ステップＳ１０１〜ステップＳ１０４により、過去注文回数、最終発注日から現在日までの差日数、過去の注文部数の平均、及び想定使用量と在庫数とから、付与するポイント数が算出されたら、発注可能性指数比較部１１３は、これらのポイント数をユーザＩＤにより識別されるグループ毎に合算し、発注可能性指数とする（ステップＳ１０５）。

【0051】

図９は、本発明の第１の実施形態の動作を示すシーケンス図である。図２において、商品を纏めて発注するイベントを行う際、管理グループ端末１２により、纏め発注する商品のカートが生成される（ステップＳ１）。注文サーバ１１は、全てのグループ端末１３ａ、１３ｂ、１３ｃに、案内メールＤ１を送付する（ステップＳ２ａ、Ｓ２ｂ、Ｓ２ｃ）。グループ端末１３ａ、１３ｂ、１３ｃでは、案内メールＤ１を参照して、商品の注文が行われる（ステップＳ３）。この例では、グループ端末１３ａで商品が注文されている。

【0052】

注文サーバ１１は、その商品の注文数が目標部数に達しているかどうかを判定する（ステップＳ４）。注文部数が目標部数に達していない場合（ステップＳ４：Ｎｏ）、注文サーバ１１から管理グループ端末１２に、通知メールＤ２が送信される（ステップＳ５）。通知メールＤ２の送付により、管理グループ端末１２で注文状況の確認が行われ（ステップＳ６）。

【0053】

注文サーバ１１は、管理グループ端末１２から注文状況の確認を受信すると、各グループについて、商品を注文する可能性を表す発注可能性指数を算出する（ステップＳ７）。そして、注文サーバ１１は、この発注可能性指数の大きい順に、商品を発注する可能性の高いグループを候補者として選定し、選定された候補者及び発注可能性指数の情報を管理グループ端末１２に送信する（ステップＳ８）。これにより、管理グループ端末１２には候補者確認画面Ｗ１が表示される。

【0054】

管理グループ端末１２では、選定された候補者の確認が行われる。そして、管理グループ端末１２から注文サーバ１１に、候補者の承認通知が送信される（ステップＳ９）。

【0055】

注文サーバ１１は、候補者の承認通知を受信すると、選定された候補者のグループ端末１３ａ、１３ｂ、１３ｃに、案内メールＤ３を送信する（ステップＳ１０）。ここでは、グループ端末１３ｃのグループが候補者として選定され、注文サーバ１１からグループ端末１３ｃに案内メールＤ３が送信されている。

【0056】

候補者となる各グループの担当者は、対象となる商品の購入を希望する場合には、グループ端末１３ａ、１３ｂ、１３ｃにより、商品の注文を行う（ステップＳ１１）。この例では、候補者はグループ端末１３ｃのグループであり、グループ端末１３ｃの担当者が案内メールＤ３を読んで、注文サーバ１１にアクセスし、商品を注文している。

【0057】

ステップＳ４において、対象製品の注文部数が目標部数に達していると判定された場合（ステップＳ４：Ｙｅｓ）、注文サーバ１１は管理グループ端末１２に、目標到達メールＤ４を送信する（ステップＳ１２）。また、注文サーバ１１はグループ端末１３ａ、１３ｂ、１３ｃに、目標到達メールＤ５を送信する（ステップＳ１３ａ、１３ｂ、１３ｃ）。

【0058】

以上説明したように、本発明の第１の実施形態に係る注文管理システム１では、発注可能性指数に基づいて、発注可能性指数が高い順に所定数のグループに対して通知を行うようにしたので、発注してもらえる可能性が高いグループに対して注文を促すことができ、発注してもらえる可能性が低いグループについては、早い段階では通知されないため、不要な通知がされてしまうことを低減することができる。

【0059】

なお、注文管理システム１の全部または一部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各部の処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。

【0060】

以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。

【符号の説明】

【0061】

１１：注文サーバ
１２：管理グループ端末
１３ａ〜１３ｃ： グループ端末
１０１：通信部
１０２：制御部
１０３：記憶部
１１１：受信部
１１２：比較部
１１３：発注可能性指数算出部
１１４：候補者選定部
１１５：通知部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】