JP2019113973A - 商品受注配達システムおよび商品受注配達方法 - Google Patents

Abstract

【課題】特定エリアの顧客が情報端末装置を介して好みの商品を販売業者に注文することができ、顧客にも販売業者にも余計な負担がない商品受注配達システムおよび商品配達手法を提供する。【解決手段】複数の顧客１０３が情報端末装置１０７からローカルサーバ１０９にアクセスして、個人注文シート１１０に宅配弁当屋１０６に注文したい弁当の種類を記入し、保存する。ローカルサーバ１０９のプロセッサユニットは、予め定められた時刻になると個人注文シート１１０を読出し、宅配弁当屋１０６の従業員が判読して弁当１０５を用意することが容易な注文集計シート１１１を作成する（注文集計データの出力）。注文集計シート１１１は、広域ネットワーク１１２を介して宅配弁当屋１０６に送信される。宅配弁当屋１０６の従業員は、注文集計シート１１１に従って注文された弁当１０５を用意し、配達用トラック１１４を使って職場１０４に配達する。【選択図】図１

Description

本発明は、一般に顧客が注文した商品を販売業者が配達する業態の効率化に関し、より詳細には一定の時間範囲に複数の顧客が利用する複数の商品を特定エリアに配達する業態の注文受付け処理で用いられる商品受注配達システム及び商品受注配達方法に関する。

従来より、一定の時間範囲に複数の顧客が利用する複数の商品を特定エリアに配達する業態がある。より具体的には、催事の行われる会場に催事の時間に合せて食事を配膳する仕出し屋、あるいは昼食用の弁当を職場に配達する宅配弁当屋といった業態である。両者に厳密な区分はないが、一般に仕出し屋が提供する食事は一人一食当たりの価格が比較的高価であり、また、催事には相応の人数が集まることから利益率が高い。このため、電話やファックスを介して注文を受付ける仕出し屋は数多く存在する。

一方、職場や自宅に昼食を配達する宅配弁当屋は、一人一食当たりの価格を低く抑える必要があり、電話やファックスで個別に注文を受けて配達するというビジネスが成立ちにくい。その主な理由は、低価格の弁当の個別配達では配達に要する費用を賄えない、不特定多数の注文を電話やファックスで受けると空注文や代金未収の虞があるという２点である。これを解決するために、配達するための最低注文金額を設定する、顧客との間で定期購入契約を結んで配達費用も加味した価格の弁当を販売する、職場単位で注文を受けるといった手法が取られている。

配達費用も加味した弁当を販売する手法の一つとして、インターネットで注文を受付けるとともにウェブサーバに顧客情報を蓄積し、注文条件・配送先の多様化、注文・配送の迅速化、顧客個々の事情への柔軟な対応を図ることが提案されている（例えば、特許文献１参照）。これらのサービスは糖尿病食やカロリー制限等の顧客に対して適切な献立を用意するという優れた効果を奏するが、価格を低く抑えるという方向とは完全に逆行する。一方、職場単位で注文を受ける手法は、一定数量の弁当を同じ場所に配達すればよく、また空注文や代金未収の問題が発生しにくいので、宅配弁当屋にとっては旨味があるビジネスである。

ところが、この手法には職場側担当者の負担が大きいという課題がある（例えば、特許文献２参照）。特許文献２に背景技術として記載されている通り、職場の給食担当者が同僚の当日の注文を集約し、給食業者に電話やファックスで伝え、更に同僚から給食代金を徴収して給食業者に一括して支払うという手法では、職場の給食担当者の負担が非常に大きくなる。この課題に対する解決策として、特許文献２では、職場の給食利用者各々が電話、ファックス、電子メール、あるいはウェブサイトを介して給食サービス提供者に注文を伝え、給食サービス提供者は弁当製造業者から給食を買入れて職場に配達し、給食サービス提供者が給食利用者各々から代金回収を行うという手法が開示されている。

特開２００２−６３２５５号公報 特開２００５−１８２７２５号公報

上記の特許文献２に開示された手法は、やはり価格を低く抑えるという方向と逆行する。宅配弁当は生ものであり、在庫を翌日に回すということができない性質の商品であるため、給食サービス提供者が弁当製造業者から買入れる際に大量注文したとしても、注文するのが当日で、弁当の種類も数量もその時まで不明という状況では、ボリュームディスカウントは期待できない。従って、給食利用者は通常の弁当価格に加えて、給食サービス提供者の人件費を負担することになる。すなわち、特許文献２の手法は、職場の給食担当者の負担を給食サービス提供者に転嫁したに過ぎず、その費用は割高な弁当代金という形で給食利用者が負担せざるを得ない。

本願発明は、職場の給食担当者の負担を第三者に転嫁するのではなく、ＩＴ技術によってこの負担を解消する。すなわち、特定エリア（例えば、職場）の顧客（例えば、給食利用者）各々が情報端末装置を介して好みの商品（例えば、弁当）を販売業者（例えば、宅配弁当屋）に注文することができ、しかも顧客にも、販売業者にも、余計な負担を強いることがない、特定エリアへの商品配達手法としての商品受注配達システムおよび商品受注配達方法を提供するものである。

本発明の第１の形態の商品受注配達システムは、販売業者が特定エリアに配達する複数の商品を一定の時間範囲に利用する複数の顧客が使用する情報端末装置と、前記一定の時間範囲に先立って、前記顧客が前記情報端末装置に入力した顧客注文情報を、前記顧客を識別する情報と関連付けて、前記特定エリアごとに記憶する注文記憶手段と、前記顧客注文情報に基づいて、前記商品の分類に従う注文集計データを前記特定エリアごとに作成する注文集計手段と、前記注文集計データを前記販売業者に対して出力するデータ出力手段と、を備えることを特徴とする。

第２の形態の商品受注配達システムは、第１の形態において、前記特定エリアは、前記複数の顧客が前記一定の時間範囲を含む時間帯に滞在する場所であり、前記注文記憶手段および前記注文集計手段は、前記情報端末装置とローカルエリアネットワークを介して接続されたローカルサーバの機能の一部であることを特徴とする。

第３の形態の商品受注配達システムは、第１の形態において、前記出力手段は、前記情報端末装置と前記ローカルエリアネットワークを介して接続されたローカルサーバの機能の一部であり、前記注文集計データは、前記販売業者の従業員が判読可能な表形式であり、広域ネットワークを介して前記ローカルサーバから前記販売業者に送信されることを特徴とする。

第４の形態の商品受注配達システムは、第１の形態において、前記注文集計手段は、前記顧客ごとの注文代金を一定の日数範囲にわたって集計した代金集計データを作成することを特徴とする。

第５の形態の商品受注配達システムは、第１の形態において、前記注文記憶手段および前記注文集計手段は、前記販売業者が管理もしくは利用するウェブサーバの機能の一部であることを特徴とする。

第６の形態の商品受注配達システムは、第５の形態において、前記顧客注文情報もしくは前記注文集計データに基づいて、複数の前記特定エリアから注文された前記商品の分類ごとの数量を集計したエリア合算データを作成するエリア合算手段を更に備えることを特徴とする。

本発明の第１の形態の商品受注配達方法は、販売業者が特定エリアに配達する複数の商品を一定の時間範囲に利用する複数の顧客が情報端末装置に顧客注文情報を入力するステップと、前記顧客注文情報を、前記顧客を識別する情報と関連付けて、前記特定エリアごとに注文記憶手段が記憶するステップと、前記顧客注文情報に基づいて、前記商品の分類に従う注文集計データを前記特定エリアごとに注文集計手段が作成するステップと、前記注文集計データを前記販売業者に対して出力するステップと、を有することを特徴とする。

本発明の第２の形態の商品受注配達方法は、第１の形態において、前記注文記憶手段および前記注文集計手段は、前記販売業者が管理もしくは利用するウェブサーバの機能の一部であり、前記ウェブサーバが、前記顧客注文情報もしくは前記注文集計データに基づいて、複数の前記特定エリアから注文された前記商品の分類ごとの数量を集計したエリア合算データを作成するステップを更に有することを特徴とする。

本発明の第３の形態の商品受注配達方法は、第１の形態において、商品仕分け装置が、前記商品に貼付けられた、非接触でのアクセスが可能な半導体チップを内蔵するとともに表面に可読情報が記載された無線タグによって前記商品を仕分けるステップを更に有し、前記半導体チップには、前記特定エリアを識別する情報が記憶され、前記可読情報は、前記商品の種類を示す情報と、前記顧客を識別する情報とを含むことを特徴とする。

本発明の第４の形態の商品受注配達方法は、第１の形態において、前記特定エリアが店舗であり、前記顧客注文情報が、前記顧客が前記店舗の従業員から個別に教示された前記特定エリアを指定するための情報を含むことを特徴とする。

本発明の第５の形態の商品受注配達方法は、第４の形態において、前記顧客注文情報を入力する際に、前記顧客のみが知り得る情報を利用することを特徴とする。

本発明によれば、一定の時間範囲に複数の顧客が利用する複数の商品を特定エリアに配達するシステムもしくは方法であって、顧客にも販売業者にも余計な負担を強いることがない効率的な商品受注配達システムもしくは商品受注配達方法が実現される。

図１は、実施形態１に係る商品受注配達システムの全体構成を示す模式ブロック図である。 図２は、実施形態１に係る商品受注配達システムの個人注文シートの一例を示す図である。 図３は、実施形態１に係る商品受注配達システムの注文集計シートの一例を示す図である。 図４は、実施形態１に係る商品受注配達システムの代金集計シートの一例を示す図である。 図５は、実施形態２に係る商品受注配達システムの全体構成を示す模式ブロック図である。 図６は、実施形態２に係る商品受注配達システムの商品受注データベースを示す模式図である。 図７は、実施形態２の変形例１に係る商品受注配達システムの受注商品仕分け装置を示す模式図である。 図８は、実施形態２の変形例２に係る商品受注配達システムの全体構成を示す模式ブロック図である。

（実施形態１）
本実施形態に係る商品受注配達システムは、特定エリアと販売業者のそれぞれが備える情報機器と、両者を接続する通信ネットワークによって構成される。特定エリアとは、一定の時間範囲（例えば昼食の時間帯）に複数の顧客が利用する複数の商品が配達される場所であり、例えば複数の顧客が勤務する職場、複数の顧客が居住する施設・住居、あるいは複数の顧客が集まる催事（慶弔の集まり、会社の行事・会議、パーティー・行楽行事）が開催される場所などである。また、販売業者とは、例えば宅配弁当屋、仕出し屋、宅配寿司屋、宅配ピザ屋、ネットスーパー、ネットコンビニ、あるいは弁当類の製造販売を行う工場などである。実施形態１では、「顧客が利用する商品」の一例として、「顧客が消費する食品を包装した弁当」を挙げる。なお、以下に説明する構成は、本発明の一例に過ぎず、本発明は下記実施形態に限定されることはなく、この実施形態以外であっても、本発明に係る技術的思想を逸脱しない範囲であれば、種々の変更が可能である。

図１は、実施形態１に係る商品受注配達システム１００の全体構成を示す模式ブロック図である。商品受注配達システム１００の構成要素は、特定エリア１０１と販売業者１０２に分かれて存在する。本実施形態では、特定エリア１０１は複数の顧客１０３が勤務する職場１０４、すなわち複数の顧客１０３が一定の時間範囲（例えば昼食時間）を含む時間帯に滞在する場所であり、販売業者１０２は弁当１０５を製造販売する宅配弁当屋１０６である。職場１０４には顧客１０３が使用する情報端末装置１０７が置かれており、ローカルエリアネットワーク１０８を介してローカルサーバ１０９に接続されている。すなわち、顧客１０３は自分が操作する情報端末装置１０７を介して、ローカルサーバ１０９のディスク記憶装置に記憶された電子ファイルにアクセス可能である。

ローカルサーバ１０９には、電子ファイルの一つとして、個人注文シート１１０が該ローカルサーバ１０９のディスク記憶装置に記憶されている。個人注文シート１１０の詳細は後述するが、顧客１０３は個人注文シート１１０に宅配弁当屋１０６に注文したい弁当１０５の種類を記入し、保存する。すなわち、顧客１０３が情報端末装置１０７に個人注文シート１１０を介して入力した顧客注文情報が注文記憶手段であるローカルサーバ１０９のディスク記憶装置に記憶される。ここで、例えば電子ファイルのファイル名を顧客名とするなどして、記憶された顧客注文情報は顧客１０３ごとに識別される。また、ローカルサーバ１０９に記憶される顧客注文情報は、商品（弁当１０５）の配達単位である職場１０４ごとに記憶される。例えば、複数の職場１０４が同一のローカルサーバ１０９を利用している場合には、ローカルサーバ１０９は職場１０４ごとにフォルダを分けるなどして、職場１０４ごとに顧客注文情報を保存する。

注文集計手段であるローカルサーバ１０９のプロセッサユニットは、予め定められた時刻になると個人注文シート１１０を読出し、注文集計シート（注文集計データの一例）１１１を作成する。注文集計シート１１１の詳細も後述するが、宅配弁当屋１０６の従業員が判読して弁当１０５を用意することが容易な表形式となっている。注文集計シート１１１は、広域ネットワーク１１２（例えば、インターネット）を介してローカルサーバ１０９から宅配弁当屋１０６に置かれたパソコン１１３に送信される。例えば、電子メールの添付ファイルとして注文集計シート１１１が送信される。ここでローカルサーバ１０９は、注文集計データである注文集計シート１１１を販売業者である宅配弁当屋１０６に対して出力するデータ出力手段を構成する。注文集計シート１１１を受信した宅配弁当屋１０６の従業員は、注文集計シート１１１に従って注文された弁当１０５を用意する。注文集計シート１１１に記載された弁当１０５が全て用意できると、宅配弁当屋１０６の従業員は配達用トラック１１４に弁当１０５を積んで職場１０４に配達する。

以下、本実施形態に係る商品受注配達システム１００について詳しく説明する。

図２は、顧客１０３が情報端末装置１０７から顧客注文情報を入力する際に記入する個人注文シート１１０の一例である。個人注文シート１１０は、例えばＭｉｃｒｏｓｏｆｔ Ｅｘｃｅｌ（登録商標）のワークシートとして作成される。個人注文シート１１０は、表題２０１、記入注釈欄２０２、カレンダー欄２０３、メニュー欄２０４、注文入力欄２０５、月度合計代金欄２０６によって構成されている。表題２０１には年月情報（図２では２０１７年１０月）が表示されており、この年月に対応する曜日配列がカレンダー欄２０３に表示されている。なお、個人注文シート１１０には顧客１０３を特定する表記はない。これは、個人注文シート１１０のファイル名そのものが顧客１０３の名前となっているためである。顧客１０３は自分の名前がファイル名のＥｘｃｅｌファイルを開き、顧客注文情報を入力する。

メニュー欄２０４には、宅配弁当屋１０６の代表的メニュー（日替わりＡ，日替わりＡ（小）、日替わりＢ、日替わりＢ（小）、日替わりＣ）とオプション（みそ汁、ふりかけ）が記載され、さらに日替わり以外の注文をする場合の自由記述欄２０７がある。日替わりメニューは宅配弁当屋１０６が決めたお仕着せメニューであるが、一定数の注文があることを想定して低価格に設定されている。また、日替わりメニュー自体を５種類用意しているのは、カロリー・脂肪・糖質摂取量を気にする顧客１０３に配慮したものである。その日の日替わりメニューが何であるかは、記入注釈欄２０２に記載のｕｒｌ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）をクリックすることでリンク先のウェブサイトが開き、１か月単位で確認することができる。日替わりメニューを注文する場合は、メニューと日付の交点に〇を記入する。オプションの注文も同様である。

一方、顧客１０３が日替わりメニュー以外を注文したい場合には、やはり記入注釈欄２０２に記載のｕｒｌからメニューリストを参照し、弁当名を自由記述欄２０７に記入する。また、注文間違いを避けるために、弁当名の他に値段も記入する。職場１０４で食べる昼食の弁当１０５であっても、顧客１０３は自分の好みの弁当１０５を注文したいと思っていることが想定される。特に顧客１０３自身が代金を支払う場合には、メニューのみならず値段も重要な判断要素となる。本例の個人注文シート１１０は、顧客１０３が自由にメニュー選択をできる上に、最低限の手間で好みの注文をすることができるようになっている。

個人注文シート１１０は１か月単位で入力できるようになっているが、個人注文シート１１０が集計されるのは、当日の始業時間以降に設定できる。従って、病欠、急な出張等で弁当１０５が不要になった場合のキャンセルにも、問題なく対応できる。また、カレンダーが休日（祝日や会社の休業日）の場合、注文入力欄２０５には斜線２０８が付されており、顧客１０３が間違って入力するのを防いでいる。さらに、月度合計代金欄２０６には、１か月単位で集計した注文代金が表示される。月度合計代金欄２０６は、月末に１か月分の代金を集計し、顧客１０３が宅配弁当屋１０６に支払うという場合、特に有効な表示である。

図３は、注文集計手段であるローカルサーバ１０９のプロセッサユニットによって作成される注文集計シート１１１の一例である。注文集計シート１１１も、例えばＭｉｃｒｏｓｏｆｔ Ｅｘｃｅｌ（登録商標）のワークシートとして作成されるが、さらにマクロ（自動実行プログラム）が埋込まれたワークブックとして保存されていてもよい。マクロは例えばプログラミング言語の一種であるＶＢＡ（ｖｉｓｕａｌ ｂａｓｉｃ ｆｏｒ ａｐｐｌｉｃａｔｉｏｎ）で記述されており、マクロが埋込まれたＥｘｃｅｌファイル自体の操作のみならず、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅ（登録商標）で実行される多くの機能を自動化することができる。すなわち、注文集計シート１１１のワークブックに埋め込まれたマクロがローカルサーバ１０９のプロセッサユニットによって実行されることで、注文集計シート１１１が自動的に作成される。

注文集計シート１１１は、職場名欄３０１、日付欄３０２、日替わりメニュー欄３０３、日替わり以外の注文欄３０４、合計数欄３０５、合計金額欄３０６によって構成されている。職場名欄３０１に記載の職場名は、個人注文シート１１０の集計単位であり、同じ注文集計シート１１１に記載された弁当１０５は同じ職場１０４に配達される。日付欄３０２は、宅配弁当屋１０６に対して注文日を明示するとともに、個人注文シート１１０からどの日付の注文を集計するかを決めるためのものである。日替わりメニュー欄３０３には、個人注文シート１１０と同じメニューが記載されるとともに、このメニューを注文した顧客１０３の名前（氏名）が表示される。一方、日替わり以外の注文欄３０４には個人注文シート１１０の自由記述欄２０７に顧客１０３が記入した弁当名、値段とともに、注文した顧客１０３の名前（氏名）が表示される。さらにオプション注文についても、顧客１０３ごとに〇印が付けられる。

合計数欄３０５と合計金額欄３０６は宅配弁当屋１０６の従業員が注文状況を一目で分かるようにするためのものである。個人注文シート１１０は顧客１０３が注文を入力しやすいように最適化されたフォーマットになっているのに対し、注文集計シート１１１は宅配弁当屋１０６が注文を受けるために最適化されたフォーマットになっている。両フォーマットを人手で変換することも可能であるが、人手による集計は工数を要する上に集計間違いを生じる可能性が高い。このフォーマット変換をマクロによって自動で行うというのが、本実施形態の大きな特徴である。なお、それぞれに最適化されたフォーマットを用い、自動変換によって人手を介する必要を無くすというのが発明の本旨であり、このマクロ自体はＶＢＡによるプログラミング技能を有する者であれば、さほどの困難なく作成できる。

以下、このマクロの動作について簡単に説明する。注文集計シート１１１のマクロが起動されると、集計したい職場１０４に対応するローカルサーバ１０９上のフォルダにアクセスする。マクロは当該フォルダに保存された個人注文シート１１０を全数順次開いていき、日付欄３０２に対応する日付を個人注文シート１１０のカレンダー欄２０３から探す。次いで、マクロは該当の日付の下の注文入力欄２０５の記載内容を確認していき、日替わりメニューに〇印があると、当該日替わりメニューに対応する配列Ａ１〜Ａ５に、個人注文シート１１０のファイル名である顧客１０３の名前を順次記憶していく。その際、マクロはオプションの注文があるかどうかも確認して、オプションに対応する配列Ａ１１〜Ａ１５、Ａ２１〜Ａ２５に真／偽を記憶する。さらに、自由記述欄２０７に記入されている場合は、マクロは日替わりメニュー以外に対応する配列Ａ６、Ａ１６、Ａ２６に、顧客１０３の名前、自由記述欄２０７に顧客１０３が記入した弁当名、および値段をそれぞれ記憶する。また、マクロはオプションの有無についてもＡ３６、Ａ４６に記憶する。

個人注文シート１１０からの読出しが完了すると、今度は配列を順次読出しながら、注文集計シート１１１に各メニューを注文した顧客１０３の名前を埋めていくことになる。日替わり以外の注文欄３０４には顧客１０３が記入した弁当名、値段も入力される。完成した注文集計シート１１１は一旦Ｅｘｃｅｌファイルとして保存されるが、ＰＤＦファイルとしても保存される。これは、宅配弁当屋１０６に送信する注文集計シート１１１は書換え可能なＥｘｃｅｌファイルではなく、ＰＤＦファイルとする方が望ましいからである。同じマクロによってＭｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋ（登録商標）を起動し、定型文の電子メールに注文集計シート１１１のＰＤＦファイルを添付して、宅配弁当屋１０６に送信すれば注文集計と発注作業が自動化される。さらに、ローカルサーバ１０９に備わる時刻と連動したプログラム自動実行機能を用いれば、毎朝、定時に自動でマクロを起動することが可能となり、注文集計・発注作業は全く人手を介さずに実行可能である。

個人注文シート１１０の月度合計代金欄２０６には１か月単位で集計した注文代金が表示されるので、月末に１か月分の代金を顧客１０３が宅配弁当屋１０６に支払うことができるという点は、個人注文シート１１０で説明した通りである。ただ、宅配弁当屋１０６にとって、顧客１０３の各々から現金で代金を回収するというのは手間がかかる業務である。これに対して、本実施形態では、月に一度だけ代金回収を職場１０４の給食担当者が行い、まとめて宅配弁当屋１０６に支払うことも可能である。この手法を取る場合、宅配弁当屋１０６は日々の注文合計金額を１か月分集計して、職場１０４の給食担当者に請求すればよいが、給食担当者は顧客１０３各々の１か月分の代金を知る必要がある。

ここで、個人注文シート１１０に表示される月度合計代金欄２０６の金額をそのまま使うというのはリスクがある。例えば、悪意のある顧客１０３が日にちを遡って個人注文シート１１０の注文内容を改竄すると、月度合計代金欄２０６の金額を減額することが可能である。また、善意の顧客１０３であっても、過失で注文内容を事後に書換えてしまう可能性もある。職場１０４内の代金授受に齟齬があると、職場１０４の人間関係にも影響してしまう。そこで、職場１０４内の代金回収に間違いが生じないようにするのが、図４に一例を示す代金集計シート４００である。代金集金シートは一日一葉のＰＤＦファイル４０１として記憶保存されるが、一日分の内容はシンプルである。氏名欄４０２に顧客１０３の名前が並び、当日注文金額欄４０３にはその日注文した弁当１０５の代金、累計注文金額欄４０４にはその月に注文した弁当の累計代金が表示される。

このような代金集計シート４００を給食担当者のみがアクセス可能なフォルダに保管しておく。月末最終日の代金集計シート４００を見れば、給食担当者が顧客１０３の各々から徴収すべき月度合計代金がいくらであるかを一覧表で確認できる。また、顧客１０３の誰かの個人注文シート１１０との間で月度合計代金に齟齬が生じても、容易に原因を究明することができる。すなわち、齟齬が生じた顧客１０３の個人注文シート１１０と代金集計シート４００を突き合せれば、何日の注文で食違いが生じたのか、一目瞭然である。

代金集計シート４００も、注文集計シート１１１で説明したＶＢＡマクロを用いれば、注文集計シート１１１と同時に自動で作成することができる。すなわち、個人注文シート１１０からその日の注文を読取るステップで、併せて顧客１０３の名前と注文代金を新たな配列Ｂ１、Ｂ２に記憶させる。これを前日までの累計注文金額と足し合せるためには、１日分の代金集計シート４００のみＥｘｃｅｌファイルとしても保存しておけばよい。前日までの累計金額が書込まれたＥｘｃｅｌファイルに当日の代金を加算し、それを翌日また利用するという手法で、累計注文金額欄４０４の金額を日々加算していくことができる。また、当日の代金を加算後のＥｘｃｅｌファイルをＰＤＦファイルとしても保存し、そのＰＤＦファイルのファイル名に日付を付加すれば、一日一葉のＰＤＦファイル４０１となる。

以上説明したように、本実施形態の商品受注配達システム１００は、宅配弁当屋１０６が職場１０４に配達する複数の弁当１０５を一定の時間範囲に利用する複数の顧客１０３が使用する情報端末装置１０７と、一定の時間範囲に先立って、顧客１０３が情報端末装置１０７に入力した個人注文シート１１０（顧客注文情報）を、顧客を識別する情報と関連付けて（顧客１０３の名前をファイル名として）、特定エリアである職場１０４ごとに記憶する注文記憶手段と、個人注文シート１１０に基づいて、商品である弁当１０５の種類に従う注文集計シート１１１を職場１０４ごとに作成する注文集計手段とを備え、宅配弁当屋１０６が、注文集計シート１１１を参照することで、弁当１０５を用意し、一定の時間範囲に先立って、職場１０４に配達する。

このような構成とすることで、顧客１０３は注文を入力しやすいように最適化された個人注文シート１１０に入力すればよく、宅配弁当屋１０６は注文を受けるために最適化された注文集計シート１１１を受取ることができる。また、個人注文シート１１０から注文集計シート１１１への変換は、注文集計手段によって自動的に行われるので、変換時に集計間違いを生じることがなく、人手による工数をかける必要もない。また、個人注文シート１１０を集計して注文集計シート１１１を作成する時刻を当日の始業時間以降に設定すれば、病欠、急な出張等で弁当１０５が不要になった場合のキャンセルにも、問題なく対応できる。

また、注文記憶手段および注文集計手段は、職場１０４の情報端末装置１０７とローカルエリアネットワーク１０８を介して接続されたローカルサーバ１０９の機能の一部であってもよい。この場合、個人注文シート１１０から注文集計シート１１１への変換は職場１０４において完結するので、宅配弁当屋１０６側にプログラミングあるいはサーバ運用のノウハウがなく、これを外注する出費も避けたいという状況でも、容易に商品受注配達システム１００を導入することができる。

注文集計シート１１１は、広域ネットワーク１１２を介してローカルサーバ１０９から宅配弁当屋１０６に送信されてもよい。注文集計シート１１１を電子メールの添付ファイルとして送信すれば、注文集計シート１１１を宅配弁当屋１０６に伝える部分までＶＢＡマクロによって実行することが可能となり、注文集計と発注作業が全て自動化される。

さらに、ローカルサーバ１０９が実行するマクロで（注文集計手段で）、顧客１０３ごとの注文代金を一定の日数範囲にわたって集計した代金集計シート（代金集計データ）４００を作成してもよい。職場１０４の給食担当者が月末最終日の代金集計シート４００を見れば、顧客１０３の各々から徴収すべき月度合計代金がいくらであるかを一覧表で確認できる。また、顧客１０３の誰かの個人注文シート１１０との間で月度合計代金に齟齬が生じても、容易に原因を究明することができる。

（実施形態２）
図５は、実施形態２に係る商品受注配達システム５００の全体構成を示す模式ブロック図である。商品受注配達システム５００の構成要素は、特定エリア５０１と販売業者５０２に分かれており、特定エリア５０１は複数の顧客５０３が勤務する職場５０４であり、職場５０４には顧客５０３が使用する情報端末装置５０５が置かれている点は、実施形態１と同じである。本実施形態が実施形態１と異なる点は、販売業者５０２が宅配弁当屋１０６に比べて大量の弁当５０６を製造販売する弁当直販工場５０７であり、弁当直販工場５０７は自らが管理もしくは利用するウェブサーバ５０８を保有していることである。ここで、ウェブサーバ５０８がオンプレミスで弁当直販工場５０７に置かれている必要はなく、クラウドサービスによって提供されるウェブサーバを弁当直販工場５０７が利用する形であってもよい。

顧客５０３は、情報端末装置５０５からインターネット５０９を介してウェブサーバ５０８にアクセスすることができる。実施形態１ではローカルサーバ１０９の機能の一部であった注文記憶手段および注文集計手段が、本実施形態では販売業者５０２が管理もしくは利用するウェブサーバ５０８の機能の一部となっている。ウェブサーバ５０８上には、商品受注配達システム５００の中心的役割を果たす商品受注データベース（図５では図示せず、後述する図６で示す符号６００）が構築されている。商品受注データベース６００の詳細は後述するが、顧客５０３がウェブサーバ５０８にアクセスすると表示される個人注文サイトから注文したい弁当の種類を入力すると、入力された顧客注文情報は商品受注データベース６００に追記される。顧客が個人注文サイトにアクセスする際に入力するユーザＩＤは職場５０４ごとに設定された職場識別コードと関連付けられており、商品受注データベース６００の中で職場識別コードに対応する職場サブデータベースに保存される。

商品受注データベース６００はいわゆるリレーショナルデータベースであり、クエリ（データベース管理システムに対する問合せ形式の処理要求）によって検索条件に合致するデータを抽出することができる。例えば、商品受注データベース６００全体から職場５０４を限定せずにその日に注文された弁当の種類ごとの数を集計したエリア合算データをリストとして出力できる。このエリア合算データに従って、弁当直販工場５０７の製造部門は弁当生産を行う。また、別のクエリによって職場サブデータベースごとにその日に配達する弁当の種類と数を集計した注文集計データをリスト出力することもできる。製造部門で製造された弁当の数と、配達すべき弁当の数は種類ごとに完全に一致するので、配達部門で製造された弁当を仕分け、各職場５０４に向けて配達用トラック５１０で配達する。

以下、本実施形態に係る商品受注配達システム５００、特に商品受注データベース６００について詳しく説明する。

図６は、実施形態２においてウェブサーバ５０８上に構築される商品受注データベース６００の模式図である。ウェブサーバ５０８にアクセスすると表示される注文サイト６０３から顧客５０３が入力した情報をリレーショナルデータベースに保存するという手法は、インターネットを介した電子商取引で一般的に用いられている。例えば、サーバのオペレーティングシステムであるＬｉｎｕｘ（登録商標）、サイト表示機能を提供するＡｐａｃｈｅ（登録商標）、リレーショナルデータベースであるＭｙＳＱＬ（登録商標）、動的サイトのプログラミング言語であるＰＨＰ（登録商標）を用いてこのようなシステムを構築する手法はＬＡＭＰと呼ばれ、ＬＡＭＰおよびその類似システムは多くの電子商取引の注文サイトで利用されている。以下の説明では、このようなシステムが既にウェブサーバ５０８として構築されていることを前提に、商品受注データベース６００の構成を説明する。

商品受注データベース６００は、職場識別コードに関連付けられた職場サブデータベース６０１を有している。さらに、職場サブデータベース６０１の中には、月ごとの注文を集計する月度テーブル６０２が存在する。顧客５０３がウェブサーバ５０８にアクセスすると、ユーザＩＤとパスワードの入力を求められるが、ユーザＩＤは顧客５０３に対して発行される時点で職場識別コードと関連付けられている。ユーザＩＤとパスワードがウェブサーバ５０８によって認証されると、注文サイト６０３が顧客５０３の情報端末装置５０５に表示される。注文サイト６０３の基本構成は図２に示した個人注文シート１１０と同様である。個人注文シート１１０の場合は、Ｅｘｃｅｌファイルとして保存されるだけであるが、注文サイト６０３に顧客５０３が顧客注文情報を入力して決定ボタンをクリックすると、顧客注文情報が職場サブデータベース６０１の中の月度テーブル６０２に書込まれる。

ここで、職場サブデータベース６０１としてはユーザＩＤに関連付けられた職場識別コードに対応するものが選択され、月度テーブル６０２としては注文サイト６０３で選択した年月に対応するものが選択される。また、月度テーブル６０２にはフィールド（行／列形式でデータを表示したときの列に相当）として顧客名、配達日、弁当種類、注文金額、注文日時等があり、顧客名と配達日が一致するレコード（行／列形式でデータを表示したときの行に相当）が既に存在する場合は、弁当種類、金額、注文日時等を上書きする。以上の書込みは、ＰＨＰプログラム中にＭｙＳＱＬに対するクエリを記述することで、所望の動作が実現される。

上記の商品受注データベース６００がウェブサーバ５０８上に構築されていれば、弁当直販工場５０７は必要な出力データをクエリによって取得できる。その代表的なものが、上述したエリア合算データ６０４および注文集計データ６０５である。ウェブサーバ５０８のプロセッサユニットは、全職場サブデータベース６０１にわたって、当日の月度に対応する月度テーブル６０２を参照し、配達日が当日である顧客名、弁当種類等を抽出して弁当種類ごとの数量を合算する。ウェブサーバ５０８のプロセッサユニットは、顧客注文情報もしくは注文集計データ６０５に基づいて、複数の特定エリア５０１から注文された商品の分類ごとの数量を集計したエリア合算データ６０４を作成するエリア合算手段を構成する。エリア合算データ６０４は弁当直販工場５０７の製造部門が弁当生産を行う際に参照するものなので、出力リストに顧客名を含める必要はない。また、エリア合算データ６０４は弁当直販工場５０７の製造部門の従業員が判読可能な表形式であってもよいし、弁当直販工場５０７の製造ライン管理システムに直接送信されるバイナリデータであってもよい。

また、注文集計データ６０５は、職場サブデータベース６０１の各々について、当日の月度に対応する月度テーブル６０２を参照し、配達日が当日である顧客名、弁当種類等を抽出して弁当種類ごとに顧客名をリスト化する。注文集計データ６０５は販売業者である弁当直販工場５０７の従業員が判読可能な表形式であり、注文集計データ６０５に従って製造部門で製造した弁当を仕分け、各職場５０４に配達する。なお、弁当の仕分けを人手に頼らず自動化することも可能であり、自動化手法の一例については本実施形態の変形例１で説明する。

さらに、実施の形態１の代金集計シート４００に相当するものとして、代金集計データ６０６も出力可能である。顧客５０３がウェブサーバ５０８にアクセスして顧客注文情報を商品受注データベース６００に書込む際に、注文締切り後にその日以前が配達日となっている月度テーブル６０２上のレコードを書換え禁止としておけば、実施形態１で危惧したような集計の齟齬が生じることはない。単純に、月度テーブル６０２から顧客５０３ごとの注文金額を集計すれば、顧客５０３ごとの月度合計代金となる。月度合計代金の決済方法としては、一般の電子商取引と同じく、種々の決済手段を採用可能である。代表的には、顧客５０３がユーザＩＤの取得を申請する際に併せてクレジットカード情報を入力してクレジットカード決済とする、銀行口座を登録して口座引落しにする、顧客５０３が請求代金を口座振込みする、あるいは弁当直販工場５０７がコンビニで支払い可能な口座振替用紙を発行する等である。

以上説明したように、本実施形態の商品受注配達システム５００は、弁当直販工場５０７が職場５０４に配達する複数の弁当５０６を一定の時間範囲に利用する複数の顧客５０３が情報端末装置５０５に顧客注文情報を入力し、顧客５０３を識別する情報と関連付けて、職場５０４ごとにウェブサーバ５０８上の商品受注データベース６００に記憶し、商品受注データベース６００から、弁当５０６の種類に従う注文集計データ６０５を職場５０４ごとに出力し、弁当直販工場５０７が、注文集計データ６０５を参照することで、弁当５０６を用意し、一定の時間範囲に先立って、職場５０４に配達する。

このような構成とすることで、顧客５０３は注文を入力しやすいように最適化された注文サイト６０３に入力すればよく、弁当直販工場５０７は配達仕分けをするために最適化された注文集計データ６０５を出力することができる。また、注文集計データ６０５の出力は、注文集計手段でもあるウェブサーバ５０８上の商品受注データベース６００によって自動的に行われるので、出力時に集計間違いを生じることがなく、人手による工数をかける必要もない。また、注文集計データ６０５を出力する時刻を当日の始業時間以降に設定すれば、病欠、急な出張等で弁当５０６が不要になった場合のキャンセルにも、問題なく対応できる。

また、ウェブサーバ５０８の商品受注データベース６００から、複数の職場５０４から注文された弁当５０６の種類ごとの数量を集計したエリア合算データ６０４を出力してもよい。エリア合算データ６０４によれば、その日に製造すべき弁当５０６の種類ごとの数量が分かるので、弁当直販工場５０７の製造部門の作業が効率化される。このような生産管理方法を用いれば、見込みで弁当５０６を製造する必要がなくなるので、弁当５０６の廃棄ロスが生じることはない。さらに、顧客５０３は自分が注文した弁当５０６を確実に受取ることができる。

以下、実施形態１の変形例を列挙する。

（変形例１）
図７は実施形態２の変形例１に係る受注商品仕分け装置７００の要部斜視図である。実施形態２ではエリア合算データ６０４に基づいて弁当直販工場５０７の製造部門が弁当５０６を製造し、注文集計データ６０５に基づいて配達部門が仕分けをする。弁当直販工場５０７が毎日製造する弁当５０６の総数が数百個までであれば、人手でこの仕分けを行うことも可能であり、製造部門と配達部門の連携で仕分けを効率化する方策も講じ得る。しかし、数千個以上の弁当５０６を製造・配達する場合には、人手による仕分けでは非常に効率が悪くなる。

本変形例はこの点に着目してなされたものであり、弁当５０６の製造に先立ち、注文集計データ６０５に基づいて無線タグ７０１を準備する。無線タグ７０１は非接触でのアクセスが可能な半導体チップ７０２を内蔵するとともに表面に可読情報７０３が記載されている。無線タグ７０１を準備する際に、半導体チップ７０２には少なくとも職場識別コードを書込み、可読情報としては弁当５０６の種類を示す情報と顧客５０３を識別する情報を印字する。弁当直販工場５０７の製造部門には、この無線タグ７０１が一括して、あるいは順次供給される。弁当直販工場５０７の製造部門では、弁当５０６を製造する度にその弁当５０６の種類に対応する無線タグ７０１を貼付ける。

無線タグ７０１を貼付けられた弁当５０６は、商品仕分け装置７００を構成するベルトコンベヤ７０４上に置かれる。一方、商品仕分け装置７００には配達先となる職場５０４ごとに仕分け棚７０５がベルトコンベヤ７０４の長手方向に沿うようにして用意される。弁当５０６に貼付けられた無線タグ７０１に書込まれた職場識別コードは、ベルトコンベヤ７０４の上方であって、仕分け棚７０５よりも上流（紙面左側）に設けられた無線リーダライタ７０６によって読取られ、弁当５０６はその職場識別コードに対応する仕分け棚７０５に収納されていく。仕分け棚７０５は上下動が可能であり（矢印ａ）、弁当５０６が１個収納される度に弁当５０６の１個分の高さだけ沈み込む。従って、ベルトコンベヤ７０４から仕分け棚７０５への移載は単純なスライド動作となるので、弁当５０６に加えられる衝撃は最低限に抑えられる。

図７には図示していないが、商品仕分け装置７００は制御装置を備えており、ベルトコンベヤ７０４の駆動制御、無線リーダライタ７０６の読取り制御、弁当５０６の移載制御等を行う。制御装置が注文集計データ６０５を参照して、特定の仕分け棚７０５に収納された弁当５０６が、職場コードによって対応付けられる職場５０４への配達個数に達したと判断すると、弁当直販工場５０７配達部門の従業員に全数が揃った旨を報知する。報知を受けた従業員は、仕分け棚７０５にある弁当５０６を職場５０４へ配達する。

本変形例では、弁当直販工場５０７の製造部門で製造した弁当５０６に無線タグ７０１を貼付けることで、仕向け先の職場５０４ごとに分類する作業を自動化する。この自動化によって、大量の弁当５０６を効率よく仕分けることが可能になり、人手で仕分ける場合と比較して弁当容器を変形させてしまう等の瑕疵も生じにくくなる。また、無線タグ７０１には、弁当５０６の種類を示す情報と顧客５０３を識別する情報が可読情報として印字されているので、職場５０４において弁当５０６を顧客５０３ごとに分配する作業が、容易に間違いなく実行できる。

（変形例２）
図８は実施形態２の変形例２に係る商品受注配達システム８００の模式ブロック図である。本変形例では、販売業者５０２が弁当製造工場８０１であり、弁当製造工場８０１は自らが管理もしくは利用するウェブサーバ５０８を保有しており、顧客５０３は、情報端末装置５０５からインターネット５０９を介してウェブサーバ５０８にアクセスして弁当５０６を注文し、弁当５０６が配達用トラック５１０で配達されるという点は、実施形態２と同様である。

本変形例が実施形態２と異なるのは、弁当５０６の配達先が職場ではなくコンビニエンスストア（以下、コンビニと表記する）等の店舗８０２であることである。顧客５０３が属する職場が弁当５０６の配達を受け取らない場合、職場が工事現場等で配達場所を指定できない場合、あるいは職場で弁当５０６を注文する顧客５０３の人数が少ない場合などに、この変形例は好適である。すなわち、店舗８０２が仮想的な職場として機能することで、実施形態２と同様の作用・効果を奏することができる。

弁当製造工場８０１が製造した弁当５０６を店舗８０２に配達して、顧客５０３がそれを受取るという部分だけを切り出すと、ごく当たり前のビジネスである。また、店舗８０２のイベントとして顧客５０３から特別な弁当（例えば、土用の丑の日に合せた鰻弁当）の予約注文を受付けて、イベント日に手渡すということも広く行われている。それらのビジネスと比較した場合の本変形例の特徴は、顧客５０３が当日の朝に注文した好みの弁当５０６を昼食用に受取ることができるという点である。また、そのための手続きはシステム化・自動化されているのでコストアップ要因が少なく、顧客５０３は店舗８０２に並べられた弁当を買う場合と同等の価格で弁当５０６を購入できる。

さらに言えば、コンビニの店頭に並べられた弁当の価格には消費期限切れとなって廃棄される弁当のコストも加味されているのに対し、本変形例では廃棄ロスは発生しないので、店頭の弁当よりも割安になる可能性もある。この廃棄ロスが発生しないという点に関して言うと、顧客５０３が確実に弁当５０６を受取りに来ることが重要であり、店舗８０２と顧客５０３の間に信頼関係が成立していることが望ましい。言い換えると、店舗８０２が所謂「なじみ客」である顧客５０３に対してこの販売手法を取ることが望ましく。これが「店舗８０２が仮想的な職場として機能する」と表現した所以である。

例えば、ウェブサーバ５０８によって表示されるウェブサイトにおいて顧客５０３が店舗８０２を指定するための情報を店舗８０２の従業員から個別に教示されるようにすることで、この手法は具現化される。以下に、より具体的な一例を開示する。一般的なコンビニでは、日常的にその店舗８０２を利用する顧客に対する販売が売上げ全体に占める比率が高い。また、コンビニ店舗の従業員によっては、なじみの顧客の顔を覚えており、その顧客に応じた声掛けを行っている。この延長として、日常的に昼食用の弁当５０６を買いに来る顧客５０３に店舗８０２の従業員から声を掛け、「このサイトにアクセスして、当日朝９時までに注文してくれたら、確実に弁当をお渡しできますよ。」という説明を行うとともに、サイトのｕｒｌと店舗８０２を指定するコードを教示する（図８で示す矢印ｂ）。

教示は、サイトのｕｒｌと店舗８０２を指定するコードを印刷物として手渡してもよいし、その場で顧客５０３の携帯端末で２次元バーコードを読取ってもらうという手法でもよい。ただ、これらの情報が広く知られてしまっては、店舗８０２と顧客５０３の間の信頼関係が担保されなくなってしまい、第三者のなりすましによる空注文が生じる虞もある。これを防止するために、顧客注文情報を入力する際に、顧客５０３のみが知り得る情報を利用するようにしてもよい。顧客５０３のみが知り得る情報とは、例えば、店舗８０２の会員カード番号とそのパスワード、顧客５０３が保有するクレジットカードの番号とその有効期限等である。

本変形例によれば、顧客５０３が属する職場が弁当５０６の配達を受け取らない場合、職場が工事現場等で配達場所を指定できない場合、あるいは職場で弁当５０６を注文する顧客５０３の人数が少ない場合などであっても本発明を実施することが可能になり、そのような状況にある顧客５０３に対しても、注文を入力しやすいように最適化された注文サイト６０３に入力すれば好みの弁当５０６が注文でき、注文した弁当５０６を昼食時に確実に入手でき、当日の朝に弁当５０６が不要になった場合のキャンセルにも問題なく対応できるサービスが提供される。また、一般の店頭販売と比較した場合の効果として、弁当５０６の廃棄ロスが生じることがない。さらに、コンビニ等の店舗８０２がなじみの顧客に対する優遇サービスとして運用することにより、なじみの顧客の満足度が高まり、顧客の囲い込みに寄与するという付加的な効果も期待できる。

１００，５００ 商品受注配達システム
１０１，５０１ 特定エリア
１０２，５０２ 販売業者
１０３，５０３ 顧客
１０５，５０６ 弁当
１０７，５０５ 情報端末装置
１０９ ローカルサーバ
１１０ 個人注文シート
１１１ 注文集計シート
４００ 代金集計シート
５０８ ウェブサーバ
６００ 商品受注データベース
７０１ 無線タグ
８０２ 店舗

Claims (11)

1. 販売業者が特定エリアに配達する複数の商品を一定の時間範囲に利用する複数の顧客が使用する情報端末装置と、
   前記一定の時間範囲に先立って、前記顧客が前記情報端末装置に入力した顧客注文情報を、前記顧客を識別する情報と関連付けて、前記特定エリアごとに記憶する注文記憶手段と、
   前記顧客注文情報に基づいて、前記商品の分類に従う注文集計データを前記特定エリアごとに作成する注文集計手段と、
   前記注文集計データを前記販売業者に対して出力するデータ出力手段と、を備えることを特徴とする商品受注配達システム。
2. 前記特定エリアは、前記複数の顧客が前記一定の時間範囲を含む時間帯に滞在する場所であり、
   前記注文記憶手段および前記注文集計手段は、前記情報端末装置とローカルエリアネットワークを介して接続されたローカルサーバの機能の一部であることを特徴とする請求項１に記載の商品受注配達システム。
3. 前記出力手段は、前記情報端末装置と前記ローカルエリアネットワークを介して接続されたローカルサーバの機能の一部であり、前記注文集計データは、前記販売業者の従業員が判読可能な表形式であり、広域ネットワークを介して前記ローカルサーバから前記販売業者に送信されることを特徴とする請求項１に記載の商品受注配達システム。
4. 前記注文集計手段は、前記顧客ごとの注文代金を一定の日数範囲にわたって集計した代金集計データを作成することを特徴とする請求項１に記載の商品受注配達システム。
5. 前記注文記憶手段および前記注文集計手段は、前記販売業者が管理もしくは利用するウェブサーバの機能の一部であることを特徴とする請求項１に記載の商品受注配達システム。
6. 前記顧客注文情報もしくは前記注文集計データに基づいて、複数の前記特定エリアから注文された前記商品の分類ごとの数量を集計したエリア合算データを作成するエリア合算手段を更に備えることを特徴とする請求項５に記載の商品受注配達システム。
7. 販売業者が特定エリアに配達する複数の商品を一定の時間範囲に利用する複数の顧客が情報端末装置に顧客注文情報を入力するステップと、
   前記顧客注文情報を、前記顧客を識別する情報と関連付けて、前記特定エリアごとに注文記憶手段が記憶するステップと、
   前記顧客注文情報に基づいて、前記商品の分類に従う注文集計データを前記特定エリアごとに注文集計手段が作成するステップと、
   前記注文集計データを前記販売業者に対して出力するステップと、を有することを特徴とする商品受注配達方法。
8. 前記注文記憶手段および前記注文集計手段は、前記販売業者が管理もしくは利用するウェブサーバの機能の一部であり、
   前記ウェブサーバが、前記顧客注文情報もしくは前記注文集計データに基づいて、複数の前記特定エリアから注文された前記商品の分類ごとの数量を集計したエリア合算データを作成するステップを更に有することを特徴とする請求項７に記載の商品受注配達方法。
9. 商品仕分け装置が、前記商品に貼付けられた、非接触でのアクセスが可能な半導体チップを内蔵するとともに表面に可読情報が記載された無線タグによって前記商品を仕分けるステップを更に有し、
   前記半導体チップには、前記特定エリアを識別する情報が記憶され、
   前記可読情報は、前記商品の種類を示す情報と、前記顧客を識別する情報とを含むことを特徴とする請求項７に記載の商品受注配達方法。
10. 前記特定エリアが店舗であり、
    前記顧客注文情報が、前記顧客が前記店舗の従業員から個別に教示された前記特定エリアを指定するための情報を含むことを特徴とする請求項７に記載の商品受注配達方法。
11. 前記顧客注文情報を入力する際に、前記顧客のみが知り得る情報を利用することを特徴とする請求項１０に記載の商品受注配達方法。

Images