(57)【要約】【課題】需要予測結果に矛盾が発生することを回避しつつ、複数店舗の需要予測の結果をより速く取得する。【解決手段】各店舗の購買実績データを集計した集計店データを生成する集計店データ生成部と、特売の企画に係る購買数の変動因子を含む特売企画データ、および購買実績データを表示する編集画面を外部装置に表示させ、表示された特売企画データの変動因子の編集を受け付ける入力受付部と、変動因子に対する入力受付部を介した編集を受けた特売企画データに応じ、集計店データに対する購買数の予測計算を実行するとともに、集計店データに対する予測計算後、編集を受けた特売企画データに応じ、店舗毎の単品購買実績データに対する購買数の予測計算を実行する予測購買数算出部と、を備え、予測購買数算出部は、店舗毎の単品購買実績データに対する購買数の予測計算が終了していない場合には、集計店データに対する購買数の予測計算を実行しない。【選択図】図５
2016012219.tif 000002
【特許請求の範囲】
【請求項１】
複数の店舗の購買実績データを収集するデータ収集部と、
各店舗の購買実績データを集計した集計店データを生成する集計店データ生成部と、
特売の企画に係る目的変数である購買数の変動因子を含む特売企画データ、および前記購買実績データを表示する編集画面を外部装置に表示させ、表示された前記特売企画データの変動因子の編集を受け付ける入力受付部と、
前記変動因子に対する前記入力受付部を介した編集を受けた前記特売企画データに応じ、前記集計店データに対する購買数の予測計算を実行するとともに、前記集計店データに対する予測計算後、前記編集を受けた前記特売企画データに応じ、前記店舗毎の前記単品購買実績データに対する購買数の予測計算を実行する予測購買数算出部と、
を備え、
前記予測購買数算出部は、前記店舗毎の前記単品購買実績データに対する購買数の予測計算が終了していない場合には、前記集計店データに対する購買数の予測計算を実行しない、
ことを特徴とする需要予測装置。
【請求項２】
前記予測購買数算出部は、前記集計店データに対する購買数の予測計算に際して、前記店舗毎の前記単品購買実績データに対する購買数の予測計算が終了していない場合には、予測計算中である旨を報知する、
ことを特徴とする請求項１記載の需要予測装置。
【請求項３】
前記予測購買数算出部は、前記予測計算中である旨を表示する、
ことを特徴とする請求項２記載の需要予測装置。
【請求項４】
前記予測購買数算出部は、前記店舗毎の前記単品購買実績データに対する購買数の予測計算が完了した場合には、前記店舗毎の予測計算が完了した旨を報知する、
ことを特徴とする請求項１ないし３の何れか一記載の需要予測装置。
【請求項５】
前記予測購買数算出部は、前記店舗毎の予測計算が完了した旨を表示する、
ことを特徴とする請求項４記載の需要予測装置。
【請求項６】
コンピュータを、
複数の店舗の購買実績データを収集するデータ収集部と、
各店舗の購買実績データを集計した集計店データを生成する集計店データ生成部と、
特売の企画に係る目的変数である購買数の変動因子を含む特売企画データ、および前記購買実績データを表示する編集画面を外部装置に表示させ、表示された前記特売企画データの変動因子の編集を受け付ける入力受付部と、
前記変動因子に対する前記入力受付部を介した編集を受けた前記特売企画データに応じ、前記集計店データに対する購買数の予測計算を実行するとともに、前記集計店データに対する予測計算後、前記編集を受けた前記特売企画データに応じ、前記店舗毎の前記単品購買実績データに対する購買数の予測計算を実行する予測購買数算出部と、
として機能させ、
前記予測購買数算出部は、前記店舗毎の前記単品購買実績データに対する購買数の予測計算が終了していない場合には、前記集計店データに対する購買数の予測計算を実行しない、
ことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、需要予測装置およびプログラムに関する。
【背景技術】
【０００２】
従来、ＰＯＳ（Point  of  Sales）システムが普及し、商品ごとの購買実績（売上）データが容易に収集できるようになった。そして、商品毎の購買実績データに基づく、小売店等の商品別の需要予測が使用され始めた。例えば、購買実績データを分析した需要予測を、発注量過多に起因する売れ残り商品の廃棄ロスの発生や、発注量過少に起因する商品の品切れによる機会ロスの発生の抑制に使用できる。そして、需要予測をＥＤＩ（Electronic  Data  Interchange）による企業間取引の電子化と結合させ、自動発注システムまで発展させる技術が提案され始めている。
【０００３】
自動発注システムに使用できる需要予測の手法としては、公知の重回帰分析がある。そして、重回帰分析を用いることで、商品毎に需要予測（シミュレーション）を行うことができる。
【０００４】
従来の重回帰分析を用いた需要予測では、目的変数である購買数の変動因子として販売価格、販売形態実施期間、陳列位置、陳列数、広告宣伝方法等を変動因子として用いることが試行されている。また、商品とその関連商品の相互影響を考慮し、各商品の購買数を変動因子として用いることが試行されている。
【０００５】
従来の重回帰分析を用いた需要予測装置では、販売者側が予め特売商品を選定し、販売価格、販売形態実施期間、陳列位置、陳列数、販売日時等を販売者側が需要予測装置に入力し、過去購買実績も併せて商品の需要予測を行っている。
【０００６】
ところで、近年、複数店舗を統括する本部においては、バイヤが複数店舗に共通する商品を一括発注し、仕入価格を低く抑えることがある。この場合、バイヤは店舗ごとに需要予測を行って、全店舗の予測購買数を把握しなければならない。
【０００７】
しかしながら、上述のように本部において店舗ごとの需要予測を行う場合、店舗数が増加するにつれて全ての店舗の需要予測の結果を取得するまでに時間がかかってしまう、という問題がある。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明が解決しようとする課題は、需要予測結果に矛盾が発生することを回避しつつ、複数店舗の需要予測の結果をより速く取得することができる需要予測装置およびプログラムを提供することである。
【課題を解決するための手段】
【０００９】
実施形態の需要予測装置は、複数の店舗の購買実績データを収集するデータ収集部と、各店舗の購買実績データを集計した集計店データを生成する集計店データ生成部と、特売の企画に係る目的変数である購買数の変動因子を含む特売企画データ、および前記購買実績データを表示する編集画面を外部装置に表示させ、表示された前記特売企画データの変動因子の編集を受け付ける入力受付部と、前記変動因子に対する前記入力受付部を介した編集を受けた前記特売企画データに応じ、前記集計店データに対する購買数の予測計算を実行するとともに、前記集計店データに対する予測計算後、前記編集を受けた前記特売企画データに応じ、前記店舗毎の前記単品購買実績データに対する購買数の予測計算を実行する予測購買数算出部と、を備え、前記予測購買数算出部は、前記店舗毎の前記単品購買実績データに対する購買数の予測計算が終了していない場合には、前記集計店データに対する購買数の予測計算を実行しない。
【図面の簡単な説明】
【００１０】
【図１】図１は、実施形態にかかる需要予測システムの構成を示すブロック図である。
【図２】図２は、コンピュータのハードウェア構成を示すブロック図である。
【図３】図３は、需要予測装置を含んだ本部のシステム構成を示すブロック図である。
【図４】図４は、需要予測処理の流れを概略的に示すフローチャートである。
【図５】図５は、需要予測処理の手順を示すシーケンス図である。
【図６】図６は、需要予測処理の実行の中止を示す通知画面の一例を示す正面図である。
【発明を実施するための形態】
【００１１】
図１は、実施形態にかかる需要予測システム１の構成を示すブロック図である。図１に示すように、需要予測システム１は、有線または無線の通信回線２を介して相互に電気的に接続された複数のコンピュータ３で形成される本部システムに対して、複数の本部特売企画端末１２４や各店舗に設けられた店舗発注端末１２５が有線または無線の通信回線（例えば、インターネットやＬＡＮ等）５を介して接続されている。
【００１２】
本実施形態の需要予測システム１では、一つまたは複数のコンピュータ３が、所定のサービス（アプリケーション）を提供するアプリケーションサーバ、またはデータベースサーバとして機能する。また、本部特売企画端末１２４や店舗発注端末１２５は、サービスを享受するクライアントとして機能する。この需要予測システム１では、例えばＳａａＳ（Software  as  a  Service）の形態でサービス（アプリケーション）が提供されうる。なお、需要予測システム１は、サーバクライアントの形態であっても良い。
【００１３】
また、本部システムには、複数のＰＯＳ（Point  of  Sales）端末１２６を接続する店舗サーバ１２０が有線または無線の通信回線（例えば、インターネットやＬＡＮ等）５を介して接続されている。
【００１４】
上述したようなコンピュータ３、本部特売企画端末１２４、店舗発注端末１２５は、一般的なパーソナルコンピュータである。なお、本部特売企画端末１２４や店舗発注端末１２５については、タブレット端末であっても良い。ここでは、コンピュータ３を例に説明する。図２は、コンピュータ３のハードウェア構成を示すブロック図である。図２に示すように、コンピュータ３は、情報処理を行うＣＰＵ（Central  Processing  Unit）１０１、ＢＩＯＳなどを記憶した読出し専用メモリであるＲＯＭ（Read  Only  Memory）１０２、各種データを書換え可能に記憶するＲＡＭ（Random  Access  Memory）１０３を備えている。
【００１５】
また、コンピュータ３は、各種データベースとして機能するとともに各種のプログラムを記憶する記憶部であるＨＤＤ（Hard  Disk  Drive）１０４、記憶媒体１１０を用いて情報を保管したり外部に情報を配布したり外部から情報を入手するためのＤＶＤドライブ等の媒体読取装置１０５、各通信回線を介して外部の他の機器と情報を伝達するための通信制御装置１０６、処理経過や結果等を操作者に表示するＬＣＤ（Liquid  Crystal  Display）等の表示部１０７、並びに操作者がＣＰＵ１０１に命令や情報等を入力するためのキーボードやマウス等のポインティングデバイスである入力部１０８等を備えている。
【００１６】
また、コンピュータ３においては、上述した各部間で送受信されるデータは、バスコントローラ１０９によって調停される。
【００１７】
このようなコンピュータ３では、オペレータが電源を投入するとＣＰＵ１０１がＲＯＭ１０２内のローダーというプログラムを起動させ、ＨＤＤ１０４よりＯＳ（Operating  System）というコンピュータのハードウェアとソフトウェアとを管理するプログラムをＲＡＭ１０３に読み込み、このＯＳを起動させる。このようなＯＳは、オペレータの操作に応じてプログラムを起動したり、情報を読み込んだり、保存を行ったりする。ＯＳのうち代表的なものとしては、Ｗｉｎｄｏｗｓ（登録商標）等が知られている。これらのＯＳ上で走る動作プログラムをアプリケーションプログラムと呼んでいる。なお、アプリケーションプログラムは、所定のＯＳ上で動作するものに限らず、後述の各種処理の一部の実行をＯＳに肩代わりさせるものであってもよいし、所定のアプリケーションソフトやＯＳなどを構成する一群のプログラムファイルの一部として含まれているものであってもよい。
【００１８】
すなわち、ＨＤＤ１０４に記憶されているアプリケーションプログラムの違いによって、パーソナルコンピュータは、クライアントとして機能する本部特売企画端末１２４や店舗発注端末１２５、コンピュータ３（アプリケーションサーバまたはデータベースサーバ）としてそれぞれ機能することになる。
【００１９】
例えば、本部特売企画端末１２４や店舗発注端末１２５には、アプリケーションプログラムとして、ウェブブラウザや、ウェブブラウザに対してプラグイン形式を用いて提供されるソフトウェアがインストールされている。プラグインのうち代表的なものとして、Microsoft  Silverlight（商標）が挙げられる。Microsoft  Silverlightは、インストール後はブラウザ上でアニメーションや、グラフィックスの表示、音声・動画の再生などを行うフレームワークである。
【００２０】
また、一般的には、コンピュータ３のＨＤＤ１０４にインストールされるアプリケーションプログラムは、ＣＤ−ＲＯＭやＤＶＤなどの各種の光ディスク、各種光磁気ディスク、フレキシブルディスクなどの各種磁気ディスク、半導体メモリ等の各種方式のメディア等の記憶媒体１１０に記録され、この記憶媒体１１０に記録された動作プログラムがＨＤＤ１０４にインストールされる。このため、ＣＤ−ＲＯＭやＤＶＤ等の光情報記録メディアやＦＤ等の磁気メディア等の可搬性を有する記憶媒体１１０も、アプリケーションプログラムを記憶する記憶媒体となり得る。さらには、アプリケーションプログラムは、例えば通信制御装置１０６を介して外部から取り込まれ、ＨＤＤ１０４にインストールされても良い。
【００２１】
コンピュータは、ＯＳ上で動作するアプリケーションプログラムが起動すると、このアプリケーションプログラムに従い、ＣＰＵ１０１が各種の演算処理を実行して各部を集中的に制御する。
【００２２】
以下において、本部システムを構成する各コンピュータ３の各ＣＰＵ１０１がアプリケーションプログラムにより実行する各種の演算処理のうち、本実施形態の特長的な処理である需要予測処理について説明する。
【００２３】
ここで、図３は需要予測装置を含んだ本部のシステム構成を示すブロック図である。図３に示すように、本部システムを構成する各コンピュータ３のＣＰＵ１０１は、アプリケーションプログラムを実行することにより、需要予測装置１００、特売企画支援システム１２１、発注数決定支援システム１２２、発注システム１２３を実現する。
【００２４】
発注数決定支援システム１２２はサブシステムともいうべきものであり、各端末と接続され、各担当者と本部の需要予測装置１００とをつなぐインタフェースとして機能する。
【００２５】
特売企画支援システム１２１は、特売企画を支援するために構築されたシステムであり、特売の企画を行う複数の本部特売企画端末１２４と接続されている。特売企画とは、例えば、スーパーマーケットの本部において、商品カテゴリ別のバイヤの特売企画担当者としての業務とする。そして、本部特売企画端末１２４は、過去実績や推奨情報を参照した特売企画担当者から、特売企画における、特売対象となる商品を示す特売品コード（名称）、特売価格、特売日、ちらし掲載等の販促データの入力を受け付ける。そして、特売企画支援システム１２１は、需要の予測を行う際に、これらの入力された情報を、需要予測装置１００の入力受付部１１４に出力する。
【００２６】
また、発注数決定支援システム１２２は、特売品および通常価格で販売される定番品の発注数を決定する複数の店舗発注端末１２５と接続されている。店舗発注端末１２５は、店舗の発注担当者が特売品および定番品の発注数を過去実績や推奨情報を参照して入力するものである。そして、発注数決定支援システム１２２は、各店舗の店舗発注端末１２５と通信等を行うことで、各店舗の発注数を決定するためのシステムとする。発注システム１２３は、発注数決定支援システム１２２で決定された全店舗の発注数に従って、商品の製造、販売等をしている業者に対して、商品の発注を要求するシステムとする。
【００２７】
発注システム１２３は、需要予測装置１００と連携する外部システムであって、特売品および定番品の商品コード、発注数、納品日、仕入れ価格等の発注データを受取り、卸、メーカ等に送信する。
【００２８】
需要予測装置１００は、記憶部１１１と、データ収集部１１２と、予測購買数算出部１１３と、入力受付部１１４と、集計店データ生成部１１５と、を備える。
【００２９】
記憶部１１１は、ＰＯＳデータデータベースと、発注データデータベースと、廃棄データデータベースと、企画マスタデータベースと、商品マスタデータベースと、発注マスタデータベースと、気象データデータベースと、を備える。また、記憶部１１１は、需要予測装置１００のみならず、他の端末やシステムで利用される情報も管理する。また、記憶部１１１は需要予測装置１００に内蔵されるのみならず、外部にデータベースサーバとして需要予測装置１００と異なる構成としても良い。
【００３０】
ＰＯＳデータデータベースは、レシート明細等に対して掲載される各店舗のＰＯＳデータを管理する。発注データデータベースは、各店舗の商品の発注データを管理する。廃棄データデータベースは、各店舗の商品の廃棄データを管理する。
【００３１】
商品マスタデータベースは、商品コード、商品名、商品分類等の商品基本データを管理する。企画マスタデータベースは、特売品コード、特売価格、特売日、ちらし掲載等の特売企画データを管理する。発注マスタデータベースは、商品コード、発注ロット等の発注基本データを管理する。
【００３２】
気象データデータベースは、気温、湿度、降水量等の気象過去データおよび気象予報データを記憶する。
【００３３】
このように複数の店舗の業務を統括する小売企業の本部において、記憶部１１１の各データベースが、各店舗や本部が必要とする情報を一括管理する。
【００３４】
データ収集部１１２は、各店舗から送信されるＰＯＳデータ、発注データ、廃棄データ等を集計して、ＰＯＳデータデータベース、発注データデータベース、廃棄データデータベースにそれぞれ記憶する。例えば、データ収集部１１２は、各店舗の閉店後に日集計処理を実行する。また、データ収集部１１２は、各気象過去データおよび気象予報データを収集して、気象データデータベースに記憶する。
【００３５】
予測購買数算出部１１３は、記憶部１１１に記憶された単品購買実績データであるＰＯＳデータと、特売企画データなどの変動因子となるデータと、に基づいて、商品毎に、上述した過去の所定期間より後の、換言すれば現在以降の所定期間内に購買される可能性のある購買数を示した予測購買数を算出する。
【００３６】
入力受付部１１４は、発注数決定支援システム１２２や特売企画支援システム１２１等から、将来における変動因子となるデータの入力を受け付ける。そして、入力を受け付けた変動因子となるデータから導き出されたベクトル（例えば、販売価格、曜日、休日、気温、降水量、地域イベント、ちらし掲載の有無等）を、予測購買数算出部１１３に設定することで、特売企画等に基づいた予測販売数の算出を行うことができる。
【００３７】
入力受付部１１４は、編集画面である需要予測画面（図示せず）を生成し、この需要予測画面を外部装置である本部特売企画端末１２４や店舗発注端末１２５に対して送信する。
【００３８】
集計店データ生成部１１５は、夜間の計算処理で各店舗の店舗データを集計した集計店の店舗データ（集計店データ）を生成する。集計店データは、一つの店舗に見立てた集計店を設置し、その店舗の店舗データとして保有されるものである。
【００３９】
次に、需要予測画面を用いた需要予測処理の流れについて図４のフローチャートおよび図５のシーケンス図を参照しつつ説明する。
【００４０】
図４に示すように、入力受付部１１４は、本部のバイヤが操作する本部特売企画端末１２４に編集画面である需要予測画面を表示させ、まず、店舗や日付などの基本情報、対象となる特売企画データなどを選択させる（ステップＳ１）。
【００４１】
続いて、図４に示すように、入力受付部１１４は、対象となる特売企画データを取得する（ステップＳ２）。例えば、需要予測画面に設けられた所定のボタンを操作すると、入力受付部１１４は、直ちに企画ナンバーに応じた集計データ（単品購買実績データ）の取得を開始する。
【００４２】
ところで、集計データ（単品購買実績データ）の取得の際には、各店舗別に保持する単品購買実績データを集計することになる。しかしながら、店舗数や予測購買数の算出に用いる変動因子が増加することで集計時間が増加し、需要予測（シミュレーション）の応答時間が遅くなるという問題があった。
【００４３】
そこで、本実施形態においては、上述の問題を解決すべく、夜間の計算処理で各店舗の店舗データを集計した集計店の店舗データ（集計店データ）を生成しておく。すなわち、集計店データＤＴは、全店舗（店舗１〜店舗Ｋ）の店舗データＤ１〜ＤＫを集計したものである。なお、店舗データＤ１〜ＤＫ（Ｋ＝１、２、３、・・・）は、店舗（店舗１、店舗２、・・・、店舗Ｋ）ごとの、一定期間に渡って収集した購買実績データを示している。各店舗の購買実績データは、商品の売価・陳列など、販売地域に依存しない条件データ（非地域データ）と、販促チラシ、天候、気温など、販売地域によって異なる条件データ（地域データ）と、更に、それらの条件下において商品の実際に売れた数を示す実績購買数とを含むものである。集計店データＤＴは、一つの店舗に見立てた集計店を設置し、その店舗の店舗データとして保有されるものである。
【００４４】
集計店の集計データ（単品購買実績データ）の取得処理が終了すると、需要予測画面には取得された集計店の集計データ（単品購買実績データ）が表示される。
【００４５】
続いて、図４に示すように、入力受付部１１４は、対象となる特売企画データに対する編集処理を実行する（ステップＳ３）。例えば、編集処理として、一商品の売価を変更する。
【００４６】
上述のようにして特売企画データの編集のためのデータ入力（例えば、一商品の売価変更）の完了後、需要予測画面に設けられた所定のボタンを操作すると、図４に示すように、予測購買数算出部１１３は、修正された特売企画データをＲＡＭ１０３上の出力テーブルに書き込み、集計店の購買実績データ（集計店データＤＴ）に対する購買数の需要予測計算処理に先立って現在の排他条件を確認する（ステップＳ４）。
【００４７】
後述するように本実施形態においては、集計店と各店舗（以下、個店）とを分けて需要予測計算を実行する。このような場合、集計店の需要予測計算処理が終わった場合に即時、需要予測計算結果を返すため、各店舗の需要予測計算処理が終わらないまま本部のバイヤが操作する本部特売企画端末１２４に操作が戻ることとなる。
【００４８】
この時、別ユーザもしくは同一ユーザが需要予測計算中の単品と購買数に影響を与える単品（以下、食い合い単品とする）に対して需要予測処理（シミュレーション）を再度実施すると、初回の需要予測計算結果が２回目の需要予測計算結果で上書きされてしまう可能性があり、ユーザから見て正しい需要予測計算結果を取得できない可能性がある。
【００４９】
そこで、本実施形態においては、図５に示すように、予測購買数算出部１１３は、集計店の需要予測処理（シミュレーション）の開始前に各店舗の需要予測処理の現在の排他条件を確認する。予測購買数算出部１１３は、各店舗の現在の需要予測計算状態を記憶する排他マネージャを有しており、排他マネージャの各店舗の現在の需要予測計算状態を参照することにより、各店舗の現在の排他条件を確認する。
【００５０】
予測購買数算出部１１３は、排他マネージャの現在の需要予測計算状態がオンである場合には、排他中であるとみなし（ステップＳ５のＹｅｓ）、各店舗の需要予測処理が終わるまで、需要予測処理（シミュレーション）の実行を中止し（ステップＳ６）、ステップＳ３に戻って再度データ編集が可能な状態にする。この場合、予測購買数算出部１１３は、需要予測処理（シミュレーション）の実行の中止を示す通知画面を表示部１０７の需要予測画面にポップアップ表示として出力する。ここで、図６は需要予測処理の実行の中止を示す通知画面Ｓの一例を示す正面図である。図６に示すように、通知画面Ｓには、「計算中の為、訂正できません。」というメッセージＭと、「ＯＫ」ボタンＢとが表示されている。
【００５１】
一方、予測購買数算出部１１３は、排他マネージャの現在の需要予測計算状態がＯＦＦである場合には、排他中でないとみなし（ステップＳ５のＮｏ）、排他マネージャの各店舗の現在の需要予測計算状態をＯＮ（排他条件ＯＮ）として（ステップＳ７）、需要予測計算中の単品と食い合い単品が需要予測処理（シミュレーション）されないようにする。
【００５２】
次いで、予測購買数算出部１１３は、集計店の購買実績データ（集計店データＤＴ）に対する購買数の需要予測計算を実行し（ステップＳ８）、その計算結果を需要予測画面に出力する（ステップＳ９）。
【００５３】
なお、集計店の購買実績データ（集計店データＤＴ）に対する購買数の需要予測計算においては、販売地域に依存しない条件データ（非地域データ）を変動因子として用いる。
【００５４】
加えて、予測購買数算出部１１３は、集計店の購買実績データ（集計店データＤＴ）に対する購買数の需要予測結果を需要予測画面に出力している間、店舗単位で、各店舗固有の購買実績データに基づく需要予測計算の処理を行う（ステップＳ１０）。
【００５５】
予測購買数算出部１１３は、ステップＳ５の処理を全店舗データ（店舗データＤ１〜店舗データＤＫ）に対して実施し、処理を完了すると（ステップＳ１１のＹｅｓ）、その処理の完了を示す通知を表示部１０７の需要予測画面にポップアップ表示する（ステップＳ１２）。
【００５６】
加えて、予測購買数算出部１１３は、各店舗の需要予測処理（シミュレーション）が全て完了した後に、排他マネージャの各店舗の現在の需要予測計算状態をＯＦＦ（排他条件ＯＦＦ）として（ステップＳ１３）、排他を解除する。
【００５７】
このように本実施形態においては、排他処理を実施することにより、予測購買数算出部１１３は、店舗毎の単品購買実績データに対する購買数の予測計算が終了していない場合には、集計店データに対する購買数の予測計算を実行しない。これにより、別ユーザもしくは同一ユーザが需要予測計算中の単品と購買数に影響を与える単品（以下、食い合い単品とする）に対して需要予測処理（シミュレーション）を再度実施してしまうことを防止し、需要予測結果に矛盾が発生することを回避しつつ、複数店舗の需要予測の結果をより速く取得することができる。
【００５８】
次いで、入力受付部１１４は、ステップＳ１３の通知の出力後に、本部のバイヤが集計店の需要予測結果から店舗ごとの需要予測結果に表示を切り替える操作があったか否かを判定する（ステップＳ１４）。
【００５９】
店舗ごとの需要予測結果に表示を切り替える操作があったと判定すると（ステップＳ１４のＹｅｓ）、予測購買数算出部１１３は、各店舗（店舗１、店舗２、・・・、店舗Ｋ）の需要予測結果を需要予測画面に出力する（ステップＳ１５）。
【００６０】
次いで、入力受付部１１４は、予測結果を採用するか否かを判定する（ステップＳ１６）。
【００６１】
需要予測画面に設けられた所定のボタンの操作があり、予測結果が期待していたものではないと判断すると（ステップＳ１６のＮｏ）、入力受付部１１４は、ステップＳ３に戻って再度データ編集が可能な状態にする。
【００６２】
一方、需要予測画面に設けられた所定のボタンの操作があり、予測結果が期待していたものであると判断すると（ステップＳ１６のＹｅｓ）、入力受付部１１４は、特売企画データの編集を確定する（ステップＳ１７）。
【００６３】
最後に、図４に示すように、入力受付部１１４は、特売企画データの確定後、需要予測画面に設けられた所定のボタンの操作があったと判断すると、特売企画データを特売企画支援システム１２１に配信する（ステップＳ１８）。
【００６４】
上述したように、夜間の計算処理で予め集計店といった各店舗のデータを集計した店舗データを生成し、その集計店の購買実績データ（集計店データＤＴ）に対する購買数の需要予測計算を先に行い、需要予測結果をＧＵＩ（画面）に返却し、各店舗の需要予測計算はその後にバックグラウンドで実行する。これにより、本部の発注担当者であるバイヤは、全店舗の購買実績データをサンプルとした需要予測計算の結果を需要予測装置１００から即座に取得し、需要予測画面でそれを分析することが可能になる。また、その分析中に各店舗の詳細な結果を需要予測装置１００から取得し、需要予測画面でそれを確認することができる。例えば、本部の発注担当者であるバイヤが全店舗に共通する商品の発注をかけるときに、集計店データの需要予測結果を分析し、店舗ごとの固有の商品の発注をかけるときには、店舗ごとの需要予測結果を分析するなどの使い方ができる。
【００６５】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００６６】
１００      需要予測装置
１１２      データ集計部
１１３      予測購買数算出部
１１４      入力受付部
１１５      集計店データ生成部
【先行技術文献】
【特許文献】
【００６７】
【特許文献１】特開２０１２−１５０６７１号公報
【図１】
2016012219.tif 000003
【図２】
2016012219.tif 000004
【図３】
2016012219.tif 000005
【図４】
2016012219.tif 000006
【図５】
2016012219.tif 000007
【図６】
2016012219.tif 000008