JP6196933B2 - 飲食店向け管理端末及びその制御プログラム、並びに調理時間分析装置 - Google Patents

Description

本発明の実施形態は、飲食店向け管理端末及びその制御プログラムと、この管理端末を用いた調理時間分析装置に関する。

多くの飲食店では、メニュー品目毎に調理時間の目標値を定めている。この目標値を達成するためには、食材の事前の加工処理いわゆる下拵えが必要である。下拵えには、いくつかの工程メニューがあり、例えば食材を切ったり混ぜたりする第１工程、食材に下味をつける第２工程、調理直前の状態まで加工する第３工程等がある。工程数は、飲食店毎、またはメニュー品目毎に異なる。メニュー品目によっては、第２工程が省略されたり、第３工程がさらに細分化されたりする。

下拵えされて作り置きされた食材は、調理されずに所定の時間が経過すると廃棄される。すなわち、廃棄ロスが発生する。廃棄ロスを恐れて下拵えの量を減らすと、作り置きの食材が不足し、調理に時間がかかる場合がある。すなわち、顧客満足度の低下あるいは処理効率の低下を招く。このため飲食店では、下拵えをどの段階まで行うか、またどの程度の量を作り置きするか、という管理が大変重要である。そのためには、食材の事前の加工度合いとメニュー品目の調理時間との関係を分析することが必要となる。

特開２００２‐２１５７５５号公報

一実施形態が解決しようとする課題は、飲食店での食材の事前の加工度合いとメニュー品目の調理時間との関係を分析可能とする飲食店向け管理端末及びその制御プログラムと、この管理端末を用いた調理時間分析装置を提供しようとするものである。

一実施形態において、飲食店向け管理端末は、表示部と、開始宣言手段と、加工度受付手段と、実測手段と、格納手段とを含む。表示部は、飲食の注文を受けたメニュー品目を表示する。開始宣言手段は、表示部に表示されたメニュー品目の調理開始宣言を受け付ける。加工度受付手段は、調理開始宣言を受け付けたメニュー品目に係る食材の加工度合いを受け付ける。実測手段は、調理開始宣言を受け付けたメニュー品目の調理時間を求める。格納手段は、メニュー品目毎に調理時間と加工度合いとを関連付けて格納する。

一実施形態である飲食店システムの概略構成図。 メニューデータベースに格納されるメニューデータレコードのデータ構造を示す模式図。 前処理データベースに格納される前処理データレコードのデータ構造を示す模式図。 注文データベースに格納される注文データレコードのデータ構造を示す模式図。 分析データベースに格納される分析データレコードのデータ構造を示す模式図。 厨房端末の要部構成を示すブロック図。 調理指示バッファのデータ構造を示す模式図。 厨房端末のＣＰＵが制御プログラムにしたがって実行する主要な情報処理手順を示す流れ図。 図８における調理開始処理の具体的手順を示す流れ図。 図８における調理終了処理の具体的手順を示す流れ図。 調理指示画面の一表示例を示す図。 工程数選択画面の一表示例を示す図。 メニュー別平均調理時間レポートの一表示例を示す図。 メニュー別下拵え分析レポートの一表示例を示す図。

以下、下拵えに関わる管理を支援できる飲食店向け管理端末及びこの端末を用いた調理時間分析装置の実施形態について、図面を用いて説明する。なお、この実施形態は、飲食店向け管理端末の一態様として厨房端末を例示する。

図１は、本実施形態の厨房端末及び調理時間分析装置を含む飲食店システム１の概略構成図である。飲食店システム１は、複数のオーダ端末１１、中継機１２、複数の厨房端末１３、会計端末１４、通信ユニット１５、コンソール１６、メニューサーバ１７、注文管理サーバ１８、分析サーバ１９等を備える。飲食店システム１は、ＬＡＮ（Local Area Network）等のネットワーク２０を含み、このネットワーク２０を介して各厨房端末１３、会計端末１４、通信ユニット１５及びコンソール１６と、各サーバ１７，１８，１９とを接続する。飲食店システム１は、ネットワーク２０に中継機１２を接続し、各サーバ１７，１８，１９と各オーダ端末１１とを、中継機１２を介して無線通信により接続する。

オーダ端末１１は、フロア担当者が携帯する携帯型の無線通信端末である。オーダ端末１１は、キーボード，タッチパネル等の入力デバイスと液晶ディスプレイ等の表示デバイスとを備える。入力デバイスは、メニュー品目のオーダ入力に対応したものである。表示デバイスは、注文を受けたメニュー品目の表示に対応したものである。オーダ端末１１は、無線回路を内蔵しており、この無線回路を介して中継機１２との間で双方向の無線通信を行う。

オーダ端末１１は、客席毎に取り付けられ、客自身が操作してオーダ入力等を行うセルフ式オーダ端末であってもよい。

中継機１２は、客席フロア内のフロア担当者が携帯するオーダ端末１１と無線通信が可能なように、例えば客席フロアの天井部などに取り付けられる。中継機１２は１台に限定されるものではない。客席フロアの複数個所にそれぞれ中継機１２を設けてもよい。

厨房端末１３は、入力デバイスと、表示デバイスとを備える。厨房端末１３は、プリンタを備えてもよい。入力デバイスは、メニュー品目の調理開始、調理終了などの指示入力に対応したものである。表示デバイスは、調理待ち状態にあるメニュー品目の一覧表示に対応したものである。タッチパネルを用いて、入力デバイスと表示デバイスとを兼用させてもよい。

厨房端末１３は、厨房の調理場毎に設置される。そして厨房端末１３は、設置された調理場で調理を行うメニュー品目に関するデータを表示または印刷出力する。調理担当者は、厨房端末１３からの出力に従って調理作業を行う。因みに本実施形態は、調理場を揚げ場コーナ、焼き場コーナ、刺し場コーナ及びデザートコーナに区分した飲食店に導入される場合を例示する。

会計端末１４は、飲食代金の支払い処理に対応したものである。会計端末１４は、周知のＰＯＳ（Point Of Sales）端末を適用できる。会計端末は、ＰＯＳ端末に限定されるものではない。飲食代金の支払い処理に対応した電子機器であればよい。

通信ユニット１５は、インターネット等の広域ネットワークを介して接続される店外のコンピュータシステムとの間でデータ通信を行う。店外のシステムとしては、例えば店舗の運営を管理する本部に構築される本部コンピュータシステムが該当する。

コンソール１６は、各サーバ１７〜１９に指示を与える入力デバイスと、各サーバ１７〜１９から取得した情報を表示する表示デバイスとを有する。コンソール１６は、例えばパーソナルコンピュータ、タブレット等である。コンソール１６は、ネットワーク２０に対して必ずしも有線で接続されていなくてもよい。無線ＬＡＮ等を利用して、コンソール１６が各サーバ１７〜１９と通信を行えるようにしてもよい。

メニューサーバ１７は、飲食店が提供するメニュー品目に関するデータの管理に特化したコンピュータである。メニューサーバ１７は、メニューデータベース１７１と前処理データベース１７２とを有する。メニューデータベース１７１及び前処理データベース１７２は、メニューサーバ１７に内蔵されていてもよいし、メニューサーバ１７に外付けされた記憶装置に保存されていてもよい。

メニューデータベース１７１は、メニュー品目毎に作成されるメニューデータレコードＲ１を格納する。メニューデータレコードＲ１のデータ構造の要部を図２に示す。図示するようにメニューデータレコードＲ１は、メニューＩＤ、名称（メニュー品目名）、価格、調理場ＩＤ、目標調理時間、前処理フラグＦ、前処理ＩＤ等のデータ項目からなる。

メニューＩＤは、メニュー品目毎に設定される固有のコードである。各メニュー品目は、異なるメニューＩＤによって識別される。名称および価格は、メニューＩＤによって識別されるメニュー品目（以下、該当メニュー品目と称する）の名称と１点当たりの値段である。調理場ＩＤは、該当メニュー品目を調理する調理場固有のコードである。各調理場は、異なる調理場ＩＤによって識別される。目標調理時間は、該当メニュー品目の調理に要する目標時間である。目標調理時間は、人為的に設定された理論値である。目標調理時間は、過去の実測調理時間等を基に算出される統計値であってもよい。前処理フラグＦは、該当メニュー品目を調理する前に食材の加工工程、いわゆる下拵えが必要であるか否かを識別する値である。例えば、下拵えが必要な場合の前処理フラグＦを“１”とし、下拵えが不要な場合の前処理フラグＦを“０”とする。前処理ＩＤは、該当メニュー品目に対する食材の事前の加工工程に関する情報（以下、前処理工程情報と称する）を示す前処理データレコードＲ２（図３を参照）を特定するコードである。下拵えが不要なメニュー品目のメニューデータレコードＲ１については、前処理ＩＤとして“０”がセットされている。

前処理データベース１７２は、下拵えが必要なメニュー品目毎に作成される前処理データレコードＲ２を格納する。前処理データレコードＲ２のデータ構造の要部を図３に示す。図示するように前処理データレコードＲ２は、前処理ＩＤ、工程数ｎ及びその工程数ｎ分の前処理工程情報（前処理工程１〜前処理工程ｎ）等のデータ項目からなる。

工程数ｎは、対応する前処理ＩＤで特定される前処理工程情報の工程数である。工程数ｎの最小値は“１”である。最大値は、特に定めはないが、“３”〜“５”程度が現実的である。下拵えには、食材を切ったり混ぜたりする第１工程と、食材に下味をつける第２工程と、調理直前の状態まで加工する第３工程とがある。メニュー品目によっては、第２工程が省略されたり、第３工程がさらに細分化されたりする。例えば第１工程、第２工程及び第３工程の下拵えがそれぞれ必要なメニュー品目の前処理ＩＤを含む前処理データレコードＲ２の工程数ｎは“３”となる。同様に、第１工程と第３工程との下拵えが必要なメニュー品目の前処理ＩＤを含む前処理データレコードＲ２の工程数ｎは“２”となる。

前処理工程情報（前処理工程１〜前処理工程ｎ）は、対応する工程での食材の加工内容を説明するテキストデータである。例えば、食材を切るという下拵えに対応した前処理工程情報としては、「切工程」のようなテキストデータが考えられる。同様に、下味を付けるという下拵えに対応した前処理工程情報としては、「下味工程」のようなテキストデータが考えられる。テキストデータの内容はこれに限定されるものではなく、要は、厨房端末１３のオペレータ（通常は調理担当者）が食材の加工工程の内容を理解できればよい。

注文管理サーバ１８は、客が注文したメニュー品目、点数等の注文データの管理に特化したコンピュータである。注文管理サーバ１８は、注文データベース１８１を有する。注文データベース１８１は、注文管理サーバ１８に内蔵されていてもよいし、注文管理サーバ１８に外付けされた記憶装置に保存されていてもよい。

注文データベース１８１は、注文データレコードＲ３を格納する。注文データレコードＲ３は、一人で来店した個人客に対してはその個人客毎に、複数名のグループで来店した客に対してはそのグループ毎に作成される。注文データレコードＲ３のデータ構造の要部を図４に示す。図示するように注文データレコードＲ３は、伝票番号、客席ＩＤ、人数、注文メニューデータ、合計データ等のデータ項目からなる。

伝票番号は、来店した客（個人客またはグループ客）に対して発番される固有の番号である。客は、異なる伝票番号によって識別される。客席ＩＤは、伝票番号で識別される客（以下、当該客と称する）が着いた客席固有のコードである。各客席は、異なる客席ＩＤによって識別される。人数は、当該客の人数である。注文データは、当該客が注文したメニュー品目のメニューコード，点数、金額等である。合計データは、当該客が注文したメニュー品目の合計点数及び合計金額である。

客の注文データは、フロア担当者がオーダ端末１１の入力デバイスを操作することによって入力される。すなわちフロア担当者は、客からメニュー品目の注文を受けると、先ず、その客が着いた客席の客席ＩＤと人数とを入力する。次にフロア担当者は、注文データを入力する。注文データの入力を終えると、フロア担当者は、注文確定の入力を行う。注文確定が入力されると、オーダ端末１１は、入力された注文データを客席ＩＤ，人数等のデータとともに無線送信する。無線送信された注文データは、中継機１２で受信され、ネットワーク２０を経由して、注文管理サーバ１８に送信される。

注文データを受信した注文管理サーバ１８は、新規の伝票番号を発番する。そして注文管理サーバ１８は、図示しないプリンタを動作させて、注文伝票を発行する。また注文管理サーバ１８は、注文データレコードＲ３を生成し、注文データベース１８１に登録する。さらに注文管理サーバ１８は、注文を受けたメニュー品目毎に調理指示データを生成する。そして注文管理サーバ１８は、ネットワーク２０を介して調理指示データを厨房端末１３に送信する。

分析サーバ１９は、メニュー品目の調理時間に関わるデータの分析に特化したコンピュータである。分析サーバ１９は、分析データベース１９１を有する。分析データベース１９１は、分析サーバ１９に内蔵されていてもよいし、分析サーバ１９に外付けされた記憶装置に保存されていてもよい。

分析データベース１９１は、日付別に作成される分析データレコードＲ４を格納する。分析データレコードＲ４のデータ構造の要部を図５に示す。図示するように分析データレコードＲ４は、日付、メニューＩＤ、名称、調理場ＩＤ、目標調理時間、工程数ｎ、前処理工程情報（前処理工程１〜前処理工程ｎ）別の回数及び累積調理時間等のデータ項目からなる。

日付は、分析データレコードＲ４が作成された日付である。メニューＩＤ、名称、調理場ＩＤ及び目標調理時間の各情報は、メニューデータレコードＲ１の情報である。工程数ｎ及び前処理工程情報は、前処理データレコードＲ２の情報である。回数は、対応する前処理工程情報で特定される前処理の段階まで下拵えされていた食材を使って該当メニュー品目の調理を始めた回数であり、累積調理時間は、その回数分の調理時間実測値の累積である。

図６は、厨房端末１３の要部構成を示すブロック図である。厨房端末１３は、ＣＰＵ（Central Processing Unit）１３１、ＲＯＭ（Read Only Memory）１３２、ＲＡＭ（Random Access Memory）１３３、補助記憶デバイス１３４、通信インターフェース１３５、時計部１３６、タッチパネル１３７及びＩ／Ｏコントローラ１３８等を備える。そして厨房端末１３は、ＣＰＵ１３１に、ＲＯＭ１３２、ＲＡＭ１３３、補助記憶デバイス１３４、通信インターフェース１３５、時計部１３６及びＩ／Ｏコントローラ１３８の各部を、アドレスバス，データバス等のバスライン１３９で接続する。

ＣＰＵ１３１は、コンピュータの中枢部分に相当する。ＣＰＵ１３１は、オペレーティングシステムやアプリケーションプログラムに従って、厨房端末１３としての各種の機能を実現するべく各部を制御する。

ＲＯＭ１３２は、上記コンピュータの主記憶部分に相当する。ＲＯＭ１３２は、上記のオペレーティングシステムやアプリケーションプログラムを記憶する。ＲＯＭ１３２は、ＣＰＵ１３１が各部を制御するための処理を実行する上で必要なデータを記憶する場合もある。

ＲＡＭ１３３は、上記コンピュータの主記憶部分に相当する。ＲＡＭ１３３は、ＣＰＵ１３１が処理を実行する上で必要なデータを記憶する。またＲＡＭ１３３は、ＣＰＵ１３１によって情報が適宜書き換えられるワークエリアとしても利用される。

補助記憶デバイス１３４は、上記コンピュータの補助記憶部分に相当する。補助記憶デバイス１３４は、例えばＥＥＰＲＯＭ（Electric Erasable Programmable Read-Only Memory）、ＨＤＤ（Hard Disc Drive）、あるいはＳＳＤ（Solid State Drive）などである。補助記憶デバイス１３４は、ＣＰＵ１３１が各種の処理を行う上で使用するデータや、ＣＰＵ１３１での処理によって生成されたデータを保存する。補助記憶デバイス１３４は、上記のアプリケーションプログラムを記憶する場合もある。

補助記憶デバイス１３４またはＲＯＭ１３３が記憶するアプリケーションプログラムの１つに、後述する制御プログラムがある。厨房端末１３の譲渡は一般に、制御プログラム等のプログラムが補助記憶デバイス１３４またはＲＯＭ１３３に記憶された状態にて行われる。しかしこれに限らず、コンピュータ装置が備える書き込み可能な記憶デバイスに、このコンピュータ装置とは個別に譲渡された制御プログラム等がユーザなどの操作に応じて書き込まれてもよい。制御プログラム等の譲渡は、リムーバブルな記録媒体に記録して、あるいはネットワークを介した通信により行うことができる。記録媒体は、ＣＤ−ＲＯＭ，メモリカード等のようにプログラムを記憶でき、かつ装置が読み取り可能であれば、その形態は問わない。また、プログラムのインストールやダウンロードにより得る機能は、装置内部のＯＳ（オペレーティング・システム）等と協働してその機能を実現させるものであってもよい。

通信インターフェース１３５は、ネットワーク２０を接続する。通信インターフェース１３５は、各サーバ１７〜１９からネットワーク２０を介して厨房端末１３宛に送信されるデータを受信する。通信インターフェース１３５は、各サーバ１７〜１９に対する送信データを、ネットワーク２０を介して送信する。

時計部１３６は、現在の日付及び時刻を計時する。この時計部１３６で計時される時刻が、メニュー品目の調理開始時刻及び調理終了時刻となる。

タッチパネル１３７は、平面型のディスプレイ１３７ａと、このディスプレイ１３７ａの画面上に配置されるタッチセンサ１３７ｂとからなる。タッチパネル１３７は、後述する調理指示画面を表示可能なものである。なお、タッチパネル１３７の代わりに、入力デバイスであるキーボード又はマウスと、表示デバイスである液晶ディスプレイ等とを備えてもよい。

Ｉ／Ｏコントローラ１３８は、ディスプレイ１３７ａに対する画面表示を制御する。またＩ／Ｏコントローラ１３８は、タッチセンサ１３７ｂからの信号を取り込み、画面上のタッチ位置座標を検出する。

このような構成の厨房端末１３は、図示しない電源スイッチのオン操作により電源が投入されると、制御プログラムが起動する。この制御プログラムの起動により、ＣＰＵ１３１は、初期化処理を行う。この初期化処理において、ＣＰＵ１３１は、ＲＡＭ１３２に調理指示バッファ３０としての領域を形成する。

図７は、調理指示バッファ３０のデータ構造を示す模式図である。図示するように調理指示バッファ３０は、一連番号順に、オーダ時刻、客席ＩＤ、メニューＩＤ、名称、点数、ステータスＳＴ、工程No.ｉ、調理開始時刻、調理終了時刻及び調理時間の各項目データをそれぞれ格納するための領域を有する。

各項目データのうち、オーダ時刻、客席ＩＤ、メニューＩＤ、名称及び点数は、注文管理サーバ１８にて生成される調理指示データの項目である。ステータスＳＴは、対応するメニュー品目の調理に関わる状態を示すデータである。状態には、調理前の状態、調理中の状態及び調理後（配膳待ち）の状態がある。本実施形態では、調理前の状態を示すステータスＳＴを“０”、調理中の状態を示すステータスＳＴを“１”、調理後（配膳待ち）の状態を示すステータスＳＴを“２”と定義する。

工程No.ｉは、対応するメニュー品目の調理を開始する際に、食材がどの段階まで加工されていたかを示すデータである。例えば、切工程の第１段階まで下拵えされていた食材を使って調理を開始した場合には、工程No.ｉとして“１”がセットされる。同様に、下味工程の第２段階まで下拵えされていた食材を使って調理を開始した場合には、工程No.ｉとして“２”がセットされる。

調理開始時刻、調理終了時刻及び調理時間は、対応するメニュー品目の調理を開始した時刻（時分秒）、調理を終了した時刻（時分秒）及び調理開始時刻から調理終了時刻までの経過時間（秒）である。なお、経過時間の単位を秒としたが、分と秒とで表してもよい。

初期化処理が終了すると、ＣＰＵ１３１は、タッチパネル１３７に初期画面を表示する。初期画面には、業務開始を宣言するアイコンが表示されている。このアイコンがタッチ操作されると、ＣＰＵ１３１は、図８〜図１０の流れ図に示す手順の情報処理を実行する。この処理は、制御プログラムに従った処理である。なお、図８〜図１０に示すとともに以下に説明する処理の内容は一例であって、同様な結果を得ることが可能な様々な処理を適宜に利用できる。

ＣＰＵ１３１は、注文管理サーバ１８からネットワーク２０を介して送られてくる調理指示データを待機する（Act１）。調理指示データは、注文を受けたメニュー品目のメニューＩＤ、名称及び点数と、そのメニュー品目を注文した客のオーダ時刻及び客席ＩＤと、そのメニュー品目のメニューデータレコードＲ１に記録されている調理場ＩＤとを含む。ＣＰＵ１３１は、通信インターフェース１３５を介して受信した調理指示データの中に、自らに設定されている調理場ＩＤを含む調理指示データが有るか否かを確認する。該当する調理指示データが有る場合（Act１にてＹＥＳ）、ＣＰＵ１３１は、その調理指示データを取り込む。そしてＣＰＵ１３１は、取り込んだ順に調理指示データのオーダ時刻、客席ＩＤ、メニューＩＤ、名称及び点数を、調理指示バッファ３０の空番号エリアに格納する（Act２）。このときＣＰＵ３１は、この空番号エリアのステータスＳＴを、調理前の状態を示す“０”とする。その後、ＣＰＵ１３１は、Act３〜Act１７の処理を実行する。

Act３では、ＣＰＵ１３１は、番号カウンタｋを“０”にリセットする。番号カウンタｋをリセットしたならば、ＣＰＵ１３１は、Act４の処理に進む。Act４では、ＣＰＵ１３１は、件数カウンタｐを“０”にリセットする。件数カウンタｐをリセットしたならば、ＣＰＵ１３１は、Act５の処理に進む。番号カウンタｋ及び件数カウンタｐは、ＲＡＭ１３３に形成される。なお、Act３とAct４との処理順序は、この順序に限定されるものではない。先にAct４の処理を実行し、後からAct３の処理を実行してもよい。

Act５では、番号カウンタｋを“１”だけカウントアップする。番号カウンタｋをカウントアップしたならば、ＣＰＵ１３１は、Act６の処理に進む。Act６では、ＣＰＵ１３１は、番号カウンタｋのカウント値で調理指示バッファ３０を検索する。そしてＣＰＵ１３１は、レコード番号ｋ（ｋは番号カウンタの値）のエリアに、調理指示データのオーダ時刻、客席ＩＤ、メニューＩＤ、名称及び点数がセットされているか否かを確認する。レコード番号ｋのエリアに調理指示データが格納されている場合（Act６にてＹＥＳ）、ＣＰＵ１３１は、Act７の処理に進む。

Act７では、ＣＰＵ１３１は、レコード番号ｋのエリアに格納されているデータのステータスＳＴが “２”であるか否かを確認する。ステータスが“２”の場合（Act７にてＹＥＳ）、当該レコード番号ｋによって特定されるデータレコードのメニュー品目は、既に調理を終えている。したがってＣＰＵ１３１は、Act５の処理に戻る。

Act７において、ステータスが“０”または“１”の場合（Act７にてＮＯ）、当該レコード番号ｋによって特定されるデータのメニュー品目は、調理前若しくは調理中である。この場合、ＣＰＵ１３１は、Act８及びAct９の処理に進む。

Act８では、ＣＰＵ１３１は、調理指示バッファ３０からレコード番号ｋのデータレコードを検出する。そしてＣＰＵ１３１は、このデータレコードのオーダ時刻、客席ＩＤ、名称、点数及びステータスＳＴを表示バッファ（不図示）に格納する。Act９では、ＣＰＵ１３１は、件数カウンタｐを“１”だけカウントアップする。なお、Act８とAct９との処理順序は、この順序に限定されるものではない。先にAct９の処理を実行し、後からAct８の処理を実行してもよい。Act８及びAct９の処理を終えたならば、ＣＰＵ１３１は、Act５の処理に戻る。

すなわちＣＰＵ１３１は、番号カウンタｋを“１”ずつ加算する。そして、レコード番号ｋのエリアにステータスＳＴが“２”以外のデータレコードが格納されている場合に、ＣＰＵ１３１は、このデータレコードのオーダ時刻、客席ＩＤ、名称、点数及びステータスＳＴを表示バッファ（不図示）に格納する処理を繰り返す。

Act６において、レコード番号ｋのエリアに調理指示データが格納されていない場合（Act６にてＮＯ）、ＣＰＵ１３１は、Act１０の処理に進む。Act１０では、ＣＰＵ１３１は、件数カウンタｐが“０”であるか否かを確認する。件数カウンタｐが“０”の場合（Act１０にてＹＥＳ）、後述する調理指示画面に表示すべきデータがない。この場合、ＣＰＵ１３１は、Act１の処理に戻る。

Act１０において、件数カウンタｐが“０”よりも大きい場合（Act１０にてＮＯ）、ＣＰＵ１３１は、Act１１の処理に進む。Act１１では、ＣＰＵ１３１は、表示バッファのデータに基づいて調理指示画面を作成する。そしてＣＰＵ１３１は、Act１２として表示部であるタッチパネル１３７のディスプレイ１３７ａに調理指示画面を表示させる。

図１１は、調理指示画面Ｇ１の一表示例である。調理指示画面Ｇ１には、オーダ時刻の早い順番に、客席ＩＤで特定されるテーブル名と、メニューＩＤで特定されるメニュー品目の名称と、そのメニュー品目の注文点数とが１行ずつ表示される。また、ステータスＳＴによって特定されるメニュー品目毎の調理状況も、同じ行内に表示される。画面Ｇ１では、調理中を示すマークＭが点灯（実線で示す）されている行のメニュー品目が調理中（ステータスＳＴ＝１）であり、マークＭが消灯（破線で示す）されている行のメニュー品目が調理待ち（ステータスＳＴ＝０）である。また、調理指示画面Ｇ１には、調理中及び調理待ちのメニュー品目の合計件数が、残りメニュー数として表示される。

なお、調理指示画面Ｇ１のレイアウトは図１１のものに限定されるものではない。要は、調理又または調理中のメニュー品目とその注文数とが調理担当者にとって把握できる画面であればよい。

調理指示画面Ｇ１を表示させたならば、ＣＰＵ１３１は、Act１３の処理に進む。Act１３では、ＣＰＵ１３１は、調理指示画面Ｇ１のタッチ操作により、メニュー品目名が表示されている行が選択されたか否かを確認する（開始宣言手段）。選択されていない場合（Act１３にてＮＯ）、ＣＰＵ１３１は、Act１４の処理に進む。Act１４では、ＣＰＵ１３１は、次の調理指示データを受信したか否かを確認する。受信していない場合（Act１４にてＮＯ）、ＣＰＵ１３１は、Act１３に処理に戻る。すなわちＣＰＵ１３１は、調理指示画面Ｇ１の行が選択されるか、次の調理指示データを受信するのを待機する。なお、Act１３とAct１４との処理順序は、この順序に限定されるものではない。先に調理指示データを受信しているか否かを確認し（Act１４）、受信していない場合に、調理指示画面Ｇ１の行が選択されたか否かを確認してもよい（Act１３）。

調理指示データを受信した場合（Act１４にてＹＥＳ）、ＣＰＵ１３１は、Act２の処理に戻る。すなわちＣＰＵ１３１は、受信した調理指示データのオーダ時刻、客席ＩＤ、メニューＩＤ、名称及び点数を、調理指示バッファ３０の空番号エリアに格納し、この空番号エリアのステータスＳＴを“０”とした後、Act３〜Act１２の処理を再度実行して、調理指示画面Ｇ１を更新する。

調理指示画面Ｇ１のメニュー品目名が表示されている行が選択された場合（Act１３にてＹＥＳ）、ＣＰＵ１３１は、Act１５の処理に進む。Act１５では、ＣＰＵ１３１は、選択された行に表示されている調理状況に対応したステータスＳＴが“０”であるか否かを確認する。ステータスＳＴが“０”のとき（Act１５にてＹＥＳ）、選択された行のメニュー品目は調理待ちである。この場合、ＣＰＵ１３１は、Act１６の処理に進む。ステータスＳＴが“０”でない、すなわち“１”のときには（Act１５にてＮＯ）、選択された行のメニュー品目は調理中である。この場合、ＣＰＵ１３１は、Act１７の処理に進む。

Act１６では、ＣＰＵ３１は、調理開始処理を実行する。
図９は、調理開始処理の手順を具体的に示す流れ図である。調理開始処理を開始すると、ＣＰＵ１３１は、選択されたメニュー品目のメニューＩＤを問合せキーとして、メニューサーバ１７に対してメニューデータを問合せる（Act２１）。

この問合せを受信したメニューサーバ１７は、メニューデータベース１７１を検索して、問合せキーであるメニューＩＤを含むメニューデータレコードＲ１を検出する。そしてメニューサーバ１７は、メニューデータレコードＲ１の前処理フラグＦをチェックする。前処理フラグＦが“０”、すなわち下拵えが不要なメニュー品目のレコードの場合、メニューサーバ１７は、メニューデータレコードＲ１を問合せ元の厨房端末１３に送信する。

これに対し、前処理フラグＦが“１”、すなわち下拵えが必要なメニュー品目のレコードの場合には、メニューサーバ１７は、そのメニューデータレコードＲ１の前処理ＩＤで前処理データベース１７２を検索し、この前処理ＩＤを含む前処理データレコードＲ２を読み出す。そしてメニューサーバ１７は、メニューデータレコードＲ１と前処理データレコードＲ２とを対にして、問合せ元の厨房端末１３に送信する。

メニューデータを問い合わせたＣＰＵ１３１は、メニューサーバ１７からの応答を待機する（Act２２）。応答があった場合（Act２２にてＹＥＳ）、ＣＰＵ１３１は、その応答されたメニューデータレコードＲ１の前処理フラグＦを調べる（Act２３）。前処理フラグＦが“０”の場合（Act２３にてＮＯ）、ＣＰＵ１３１は、時計部１３６で計時されている現在時刻を取得する。そしてＣＰＵ１３１は、この現在時刻を、選択されたメニュー品目の調理開始時刻として調理指示バッファ３０に登録する（Act２８）。またＣＰＵ１３１は、選択されたメニュー品目のステータスＳＴを、調理中を示す“１”に変更する（Act２９）。以上で、ＣＰＵ１３１は、調理開始処理を終了する。

なお、Act２８〜Act２９の処理手順はこの順序に限定されるものではない。先にステータスを “１”に変更してから（Act２９）、調理開始時刻を調理指示バッファ３０に登録してもよい（Act２８）。

一方、前処理フラグＦが“１”の場合には（Act２３にてＹＥＳ）、ＣＰＵ１３１は、メニューデータレコードＲ１とともに受信した前処理データレコードＲ２から工程数ｎ及び前処理工程情報を検出する（検出手段）。そしてＣＰＵ１３１は、この工程数ｎと前処理工程情報とを基に工程数ｎの選択画面を作成する。ＣＰＵ１３１は、この選択画面を、タッチパネル１３７のディスプレイ１３７ａに表示させる（加工度受付手段）。

図１２は、工程数ｎの選択画面Ｇ２の一表示例である。この例は、工程数ｎが“３”の場合である。図示するように選択画面Ｇ２は、調理指示画面Ｇ１の上に重ねてポップアップ表示される。選択画面Ｇ２には、工程数ｎに１を加算した数のボタンＢ０，Ｂ１，Ｂ２，Ｂ３が表示される。また、ボタンＢ０を除くボタンＢ１，Ｂ２，Ｂ３に対しては、対応する前処理工程情報が表示される。さらに、選択されたメニュー品目の名称［○○○○○］も表示される。因みに、工程数ｎが“２”の場合には、選択画面Ｇ２にボタンＢ０，Ｂ１，Ｂ２が表示され、工程数ｎが“１”の場合には、選択画面Ｇ２にボタンＢ０，Ｂ１が表示される。

ボタンＢ０〜Ｂ３は、選択されたメニュー品目の調理に先立ち、食材の前処理（加工），いわゆる下拵えがどこまで行われているのかを宣言するボタンである。下拵えが全く行われていない場合、オペレータ（通常は調理担当者）は、ボタンＢ０にタッチする。工程No.が１である第１工程の下拵えまで行われていた場合、オペレータはボタンＢ１にタッチする。工程No.が２である第２工程の下拵えまで行われていた場合、オペレータはボタンＢ２にタッチする。工程No.が３である第３工程の下拵えまで行われていた場合、オペレータはボタンＢ３にタッチする。

工程数ｎの選択画面Ｇ２を表示させたＣＰＵ１３１は、工程No.ｉが選択されるのを待機する（Act２５）。選択画面Ｇ２のいずれかのボタンＢ０〜Ｂ３がタッチされた場合、ＣＰＵ１３１は、そのボタンＢ０〜Ｂ３に対応した工程No.ｉが選択されたと認識する（Act２５にてＹＥＳ）。そしてＣＰＵ１３１は、その工程No.ｉを調理指示バッファ３０に登録する（Act２６）。またＣＰＵ１３１は、工程数ｎの選択画面Ｇ２を消去する（Act２７）。その後、ＣＰＵ１３１は、時計部１３６で計時されている現在時刻を取得する。そしてＣＰＵ１３１は、この現在時刻を、選択されたメニュー品目の調理開始時刻として調理指示バッファ３０に登録する（Act２８）。またＣＰＵ１３１は、選択されたメニュー品目のステータスＳＴを、調理中を示す“１”に変更する（Act２９）。以上で、ＣＰＵ１３１は、調理開始処理を終了する。

なお、Act２６〜Act２９の処理手順はこの順序に限定されるものではない。例えば、ステータスＳＴを“１”に変更してから（Act２９）、工程No.ｉ及び調理開始時刻を調理指示バッファ３０に登録し（Act２６，２８）、選択画面Ｇ２を消去してもよい（Act２７）。あるいは、選択画面Ｇ２を消去し（Act２７）、ステータスＳＴを“１”に変更してから（Act２９）、工程No.ｉ及び調理開始時刻を調理指示バッファ３０に登録してもよい（Act２６，２８）。

図８に説明を戻す。Act１７では、ＣＰＵ３１は、調理終了処理を実行する。
図１０は、調理終了処理の手順を具体的に示す流れ図である。調理終了処理を開始すると、ＣＰＵ１３１は、時計部１３６で計時されている現在時刻を取得する。そしてＣＰＵ１３１は、この現在時刻を、選択されたメニュー品目の調理終了時刻として調理指示バッファ３０に登録する（Act３１）。

次にＣＰＵ１３１は、この選択されたメニュー品目の調理開始時刻から調理終了時刻までの差分時間を算出する（Act３２）。そしてＣＰＵ１３１は、この差分時間を、選択されたメニュー品目の調理時間として調理指示バッファ３０に登録する（Act３３：実測手段）。その後、ＣＰＵ１３１は、選択されたメニュー品目のステータスＳＴを、調理完了を示す“２”に変更する（Act３４）。以上で、ＣＰＵ１３１は、調理終了処理を終了する。

なお、Act３４の処理は、Act３１の処理の前に行ってもよい。すなわちＣＰＵ１３１は、選択されたメニュー品目のステータスＳＴを、調理完了を示す“２”に変更した後（Act３４）、調理終了時刻の登録（Act３１）、調理時間の算出（Act３２）、及び調理時間の登録（Act３３）、を処理してもよい。

再び、図８に説明を戻す。Act１６の調理開始処理あるいはAct１７の調理終了処理を終了すると、ＣＰＵ１３１は、Act３の処理に戻る。そしてＣＰＵ１３１は、Act３〜Act１２の処理を再度実行して、調理指示画面Ｇ１を更新する。
以上で、制御プログラムに従った処理の説明を終了する。

上述したように、厨房端末１３は、注文管理サーバ１８から調理指示データを受信する毎に、その調理指示データのオーダ時刻、客席ＩＤ、メニューＩＤ、名称及び点数を調理指示バッファ３０に蓄積する。そして厨房端末１３は、調理指示バッファ３０に蓄積されたデータに基づいて調理指示画面Ｇ１を作成し、タッチパネル１３７に表示する。

調理指示画面Ｇ１には、調理前のメニュー品目に係る情報と、調理中のメニュー品目に係る情報とが、注文を受け付けた順番に表示される。調理前なのか調理中なのかの識別は、調理状況マークＭによって可能である。調理担当者は、調理指示画面Ｇ１を見て調理を開始するメニュー品目を決める。そして調理担当者は、調理を開始する際にそのメニュー品目の情報が表示されている行にタッチして、選択を行う。

ここで、下拵えが必要なメニュー品目が選択された場合、タッチパネル１３７に下拵えの工程数ｎに対応した選択画面Ｇ２が表示される。そこで調理担当者は、食材の下拵えがどの段階まで行われているかを確認し、該当するボタンにタッチする。例えば第１工程の下拵えまで行われていた場合、調理担当者はボタンＢ１にタッチする。そうすると、調理指示バッファ３０の当該メニュー品目に対する工程No.ｉが“１”となる。また、調理指示バッファ３０の当該メニュー品目に対する調理開始時刻として現在時刻が登録される。さらに、調理指示画面Ｇ１の当該メニュー品目に対する調理状況マークＭが点灯するので、調理担当者は、当該メニュー品目の調理を開始する。

調理を終えると、調理担当者は、再び調理指示画面Ｇ１の当該メニュー品目の情報が表示されている行にタッチする。そうすると、調理指示バッファ３０の当該メニュー品目に対する調理終了時刻として現在時刻が登録される。また、調理開始時刻から調理終了時刻までの経過時間が調理時間として、調理指示バッファ３０に登録される。そして、調理指示画面Ｇ１から当該メニュー品目の情報が消去される。

このように、厨房端末１３の格納手段である調理指示バッファ３０には、その厨房端末１３が設置されている調理場で調理したメニュー品目毎に、そのメニュー品目を調理する際の下拵えの段階を示す工程No.ｉと調理時間の実測値とが格納される。

各厨房端末１３の調理指示バッファ３０に蓄積されたデータは、１日の営業が終了した後の閉店後処理において、分析サーバ１９によって収集される。すなわち分析サーバ１９は、閉店後の所定の時刻になると、ネットワーク２０を介して各厨房端末１３に調理指示バッファ３０の収集コマンドを送信する。このコマンドを受信した厨房端末１３は、調理指示バッファ３０に蓄積されたデータを、ネットワーク２０を介して分析サーバ１９に送信するので、分析サーバ１９は、各厨房端末１３から収集したデータを基に分析データベース１９１を更新する。

具体的には分析サーバ１９は、各厨房端末１３から収集したデータに含まれるメニューＩＤ毎に、日付、メニューＩＤ、名称、調理場ＩＤ、目標調理時間を含むメニューデータレコードＲ４を作成する。そして分析サーバ１９は、同一メニューＩＤのデータの点数と調理時間とを、そのデータの工程No.に一致する前処理工程の回数エリア及び累積調理時間エリアに加算する。例えば、調理指示バッファ３０から収集したメニューＩＤ＝９９９のデータの工程No.が“１”で調理時間が３００秒であった場合、分析サーバ１９は、メニューＩＤ＝９９９の分析データレコードＲ４の前処理工程１に対する回数に１を加算し、かつ、累積調理時間に３００秒を加算する。同様に、同じメニューＩＤ＝９９９のデータの工程No.が“２”で調理時間が２５０秒であった場合、分析サーバ１９は、メニューＩＤ＝９９９の分析データレコードＲ４の前処理工程２に対する回数に１を加算し、かつ、累積調理時間に２５０秒を加算する（収集手段）。

かくして分析サーバ１９は、分析データベース１９１を用いて、食材の下拵えが必要なメニュー品目毎に、下拵えの段階（加工度合い）別に、その段階から調理を開始した回数と、その段階から調理を開始したときの調理に要した時間とを日単位で集計する。

分析データベース１９１にて集計された日単位の調理時間に関わるデータは、例えばコンソール１６と協働することにより分析できる。この場合、分析サーバ１９とコンソール１６とは、調理時間分析装置として機能する。あるいは、分析データベース１９１にて集計された日単位の調理時間に関わるデータは、例えば厨房端末１３と協働することにより分析できる。この場合、分析サーバ１９と厨房端末１３とは、調理時間分析装置として機能する。
以下では、厨房端末１３と協働して分析データベース１９１のデータを分析する調理時間分析装置について説明する。

厨房端末１３は、ＲＯＭ１３２または補助記憶デバイス１３４に記憶されるアプリケーションプログラムの１つとして分析プログラムを有する。例えば初期画面には、分析モードを宣言するアイコンが表示されている。このアイコンがタッチ操作されると、分析プログラムが起動する。分析プログラムが起動すると、ＣＰＵ１３１は、タッチパネル１３７に日付入力画面を表示する。日付入力画面は、分析を行う日付の入力が可能である。ＣＰＵ１３１は、日付が入力されると、分析サーバ１９に対して分析コマンドを送信する。分析コマンドには、入力された日付と、当該厨房端末１３にとって固有の調理場ＩＤとが含まれる。

分析コマンドを受信した分析サーバ１９は、分析データベース１９１を検索して、コマンド中の日付と調理場ＩＤとを含む分析データレコードＲ４を抽出する。そして分析サーバ１９は、抽出した分析データレコードＲ４毎に、前処理工程情報別の回数と累積調理時間とをそれぞれ合算し、累積調理時間の合計を回数の合計で除算して、該当メニュー品目の平均調理時間を算出する。

分析サーバ１９は、抽出した分析データレコードＲ４のメニューＩＤ毎に、名称、目標調理時間、前処理工程情報別回数の合計及び平均調理時間からなる平均調理時間分析データを生成する。そして分析サーバ１９は、この平均調理時間分析データをコマンド送信元の厨房端末１３に送信する。

平均調理時間分析データを受信した厨房端末１３のＣＰＵ１３１は、このデータを基にメニュー品目別の平均調理時間レポート画面を作成し、タッチパネル１３７に表示させる。

図１３は、平均調理時間レポート画面Ｇ３の一表示例である。図示するように画面Ｇ３には、分析を行う日付Ｄとともに、メニュー品目毎に、目標調理時間（目標）と平均調理時間（実測）とがそれぞれ対比可能なように棒グラフによって表示される。また、メニュー品目の名称とともにオーダ数も表示される。オーダ数は、前処理工程情報別回数の合計値である。

したがってオペレータ（例えば店舗管理者）は、画面Ｇ３の情報から、日付Ｄにおいて、調理時間が目標調理時間をオーバーしているメニュー品目とオーバーしていないメニュー品目とを簡単に識別することができる。またオペレータは、各メニュー品目のオーダ総数も把握することができる。

また、画面Ｇ３には、調理時間が目標調理時間をオーバーしているメニュー品目に対しては「×」マークＮ１が表示され、オーバーしていないメニュー品目に対しては「○」マークＮ２が表示される。したがってオペレータは、これらのマークＮ１，Ｎ２を確認するだけで、調理時間が目標調理時間をオーバーしているメニュー品目の有無を把握できる。

ところで、調理時間が目標時間に達しない原因の１つに下拵えの準備不足が考えられる。例えば下拵えとして３工程が必要なメニュー品目について、第１工程までしか下拵えをしていなかったために、第２工程から調理を開始した場合、調理に時間を要するのは明らかである。また、第３工程まで下拵えをしていたが、その数が少なかったために作り置きの食材が不足し、途中から、下拵えの第１段階から調理を開始した場合、多くの時間を調理に要してしまう。

そこでオペレータは、「×」マークＮ１が表示されているメニュー品目の品目名にタッチする。そうすると、ＣＰＵ１３１は、先に日付入力画面から入力された日付とともにそのメニュー品目のメニューＩＤを含む下拵え分析コマンドを生成して、分析サーバ１９に送信する。

下拵え分析コマンドを受信した分析サーバ１９は、分析データベース１９１を検索して、コマンド中の日付とメニューＩＤとを含む分析データレコードＲ４を抽出する。そして分析サーバ１９は、この分析データレコードＲ４の前処理工程別に累積調理時間を回数で除算して、前処理工程別の平均調理時間を算出する（演算手段）。分析サーバ１９は、抽出した分析データレコードＲ４の名称、目標調理時間、前処理工程情報別の回数及び平均調理時間からなる下拵え分析データを生成する。そして分析サーバ１９は、この下拵え分析データをコマンド送信元の厨房端末１３に送信する（出力手段）。

下拵え分析データを受信した厨房端末１３のＣＰＵ１３１は、このデータを基に当該メニュー品目の下拵え分析レポート画面を作成し、タッチパネル１３７に表示させる。

図１４は、下拵え分析レポート画面Ｇ４の一表示例である。図示するように画面Ｇ４には、分析を行う日付Ｄとともに、当該メニュー品目の目標調理時間（目標）と前処理工程別の平均調理時間とがそれぞれ対比可能なように棒グラフによって表示される。また、メニュー品目の名称とともに前処理工程別のオーダ数（回数）も表示される。

したがってオペレータは、画面Ｇ４の情報から、当該メニュー品目について、下拵えをしなかった場合の平均調理時間、第１工程まで下拵えをした場合の平均調理時間、第２工程まで下拵えをした場合の平均調理時間、及び第３工程まで下拵えをした場合の平均調理時間をそれぞれ確認することができる。したがってオペレータは、目標調理時間を達成するためにはどの段階までどの程度下拵えをしておけばよいかというような分析を容易に行うことができる。

例えば画面Ｇ４の場合には、下拵えをしなかった場合と、第１工程まで下拵えをした場合には、目標調理時間を達成できないが、第２工程まで下拵えをしておけば目標調理時間を達成できることがわかる。また、１日の総オーダ数がわかるので、どの程度の数を下拵えすればよいかの判断にも役立つ。

以上説明したように、本実施形態によれば、飲食店での食材の事前の加工度合いとメニュー品目の調理時間との関係を分析するために必要なデータを取得できる厨房端末を提供することができる。また、この厨房端末で得られたデータを基に、飲食店での食材の事前の加工度合いとメニュー品目の調理時間との関係を分析できるめ調理時間分析装置を提供できる。

なお、本発明は、前記実施形態に限定されるものではない。
例えば、分析データレコードＲ４の項目に調理開始時刻を含ませることで、１日の時間帯別に加工度合い別の平均調理時間を算出するようにしてもよい。通常、飲食店は時間帯によって混雑度が異なる。そこで、加工度合い別の平均調理時間を時間帯別に表示することで、時間帯毎にどの段階まで下拵えをすればよいか、またどのくらいの量を処理しておけばよいかといったきめ細かな分析を行えるようになる。

前記実施形態では、選択画面Ｇ２に表示されるボタンの数を、対応するメニュー品目に対する下拵えの工程数ｎに１を加算した数としている。ボタンの数は、この数に限定されない。全てのメニュー品目に対して、最大工程数に１を加算した数のボタンが配置された選択画面を表示させてもよい。また、ボタンを表示させるのでなく、テンキーを用いてオペレータが該当する数値を入力してもよい。テンキーは、ハードキーでもよいし、タッチパネル１３７の画面に表示されるソフトキーでもよい。

図１３及び図１４では、目標調理時間と平均調理時間との対比を棒グラフによって示している。対比の表示形式は棒グラフに限定されない。例えば目標調理時間を閾値とし、平均調理時間を折れ線グラフで表して、対比させてもよい。

前処理データベース１７２は、メニューサーバ１７でなく他のサーバ、例えば分析サーバ１９あるいは注文管理サーバ１８に設けてもよい。また、メニューデータレコードの項目前処理ＩＤに代えて、当該前処理ＩＤで特定される前処理データレコードＲ２の工程数ｎと前処理工程情報（前処理工程１〜前処理工程ｎ）とを格納することで、前処理データベース１７２を省略することも可能である。

前記実施形態は、飲食店向け管理端末の一態様として厨房端末を例示したが、管理端末は厨房端末に限定されるものではない。例えば、タブレットなどの汎用端末で飲食店の誰でもが確認できる端末に、管理端末としての機能を搭載してもよい。

この他、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１…飲食店システム、１１…オーダ端末、１３…厨房端末、１４…会計端末、１５…通信ユニット、１６…コンソール、１７…メニューサーバ、１８…管理サーバ、１９…分析サーバ、３０…調理指示バッファ、１７１…メニューデータベース、１７２…前処理データベース、１８１…注文データベース、１９１…分析データベース。

Claims (6)

1. 飲食の注文を受けたメニュー品目を表示する表示部と、
   前記表示部に表示されたメニュー品目の調理開始宣言を受け付ける開始宣言手段と、
   前記調理開始宣言を受け付けたメニュー品目に係る食材の加工度合いを受け付ける加工度受付手段と、
   前記調理開始宣言を受け付けたメニュー品目の調理時間を求める実測手段と、
   前記メニュー品目毎に前記調理時間と前記加工度合いとを関連付けて格納する格納手段と、
   を具備したことを特徴とする飲食店向け管理端末。
2. 前記メニュー品目毎にそのメニュー品目に係る食材の加工工程を設定してなる記憶部から、調理開始宣言を受け付けたメニュー品目に係る食材の加工工程を検出する検出手段、
   をさらに具備し、
   前記加工度受付手段は、前記検出手段で検出された加工工程のうちどの工程まで食材が加工されているのかを受け付けることを特徴とする請求項１記載の飲食店向け管理端末。
3. 請求項１または２記載の飲食店向け管理端末の前記格納手段で格納された情報を収集する収集手段と、
   前記収集手段で収集した情報に基づいて、前記メニュー品目毎に、そのメニュー品目に係る食材の加工度合い別の平均調理時間を算出する演算手段と、
   前記演算手段により算出された前記メニュー品目に係る食材の加工度合い別の平均調理時間を出力する出力手段と、
   を具備したことを特徴とする調理時間分析装置。
4. 前記出力手段は、前記メニュー品目に係る食材の加工度合い別の平均調理時間を、そのメニュー品目の目標調理時間と対比させて出力することを特徴とする請求項３記載の調理時間分析装置。
5. 前記出力手段は、前記飲食店向け管理端末の表示部に表示出力させる手段であることを特徴とする請求項３又は４記載の調理時間分析装置。
6. 飲食の注文を受けたメニュー品目を表示する表示部を備えた飲食店向け管理端末のコンピュータに、
   前記表示部に表示されたメニュー品目の調理開始宣言を受け付ける機能と、
   前記調理開始宣言を受け付けたメニュー品目に係る食材の加工度合いを受け付ける機能と、
   前記調理開始宣言を受け付けたメニュー品目の調理時間を求める機能と、
   前記メニュー品目毎に前記調理時間と前記加工度合いとを関連付けて記憶部に格納する機能と、
   を実現させるための制御プログラム。

Images