JP2017068863A - 作業管理装置及び作業管理プログラム - Google Patents

Abstract

【課題】作業負担を考慮した人員配置を効率よく行えるようにする。
【解決手段】作業管理装置は、作業の業種別に、作業量と処理能力とから導出される負担度を示すインジケータを表す作業アイコンと、作業を補助する補助要員別に、その補助要員を表す補助要員アイコンとを、一画面に表示する。作業管理装置は、補助要員アイコンの選択と、該選択された前記補助要員アイコンで表される補助要員が補助する作業に対する作業アイコンの選択とを受け付ける。作業管理装置は、選択を受け付けた補助要員アイコンで表される補助要員に対し、選択を受け付けた作業アイコンで表される作業を補助する旨を通知する。
【選択図】 図８

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）などである。補助記憶デバイス２４は、ＣＰＵ２１が各種の処理を行う上で使用するデータや、ＣＰＵ２１での処理によって生成されたデータを保存する。補助記憶デバイス２４は、上記のアプリケーションプログラムを記憶する場合もある。

通信インターフェース２５は、ネットワーク１８に接続する。通信インターフェース２５は、他のサーバ１５，１６や端末１１，１３，１４からネットワーク１８を介して送られてくるデータ信号を受信する。また通信インターフェース２５は、他のサーバ１５，１６や端末１１，１３，１４に対してネットワーク１８を介してデータ信号を送信する。

時計部２６は、現在の日付及び時刻を計時する。時計部２６は、予め設定されたタイミングでＣＰＵ２１に割込信号を出力するタイマ機能を有する。時計部２６とは別に、タイマを設けてもよい。

Ｉ／Ｏコントローラ２７は、入力デバイス３１、表示デバイス３２等の入出力機器を制御する。入力デバイス３１は、キーボード、タッチパネル、ポインティングデバイス等である。表示デバイス３２は、液晶ディスプレイ等である。入出力機器は、その全てを作業管理サーバ１７が搭載してもよいし一部だけを搭載してもよい。あるいは、全ての入出力機器を作業管理サーバ１７に対して外付けしてもよい。

カメラコントローラ２８は、各ビデオカメラ１９で撮影される画像を取り込む。カメラコントローラ２８は、スイッチ機能を有しており、各ビデオカメラ１９の撮影画像を選択的にＲＡＭ２３の画像バッファに格納する。画像バッファに格納された撮影画像は、表示デバイス３２の画面上で再生できる。

このような構成の作業管理サーバ１７は、作業負担を考慮した人員配置を効率よく行うことができる作業管理装置として機能する。この機能を実現するために、作業管理サーバ１７は、補助記憶デバイス２４に調理場ファイル４１と担当者ファイル４２とを保存する。

図３は、調理場ファイル４１のデータ構造を示す模式図である。調理場ファイル４１は、各調理場の調理場ＩＤに関連付けて、調理場名，調理人数及びしきい値の各データを格納する。調理場名は、調理場に対して付与される固有名称である。調理人数は、調理場で調理作業等を行う厨房担当者の人数である。

しきい値は、負担度に対するしきい値である。負担度は、例えば仕事量を処理能力で除算することで算出される。本実施形態において、仕事量は、調理待ちメニュー品目の平均調理時間の累積時間である。処理能力は、厨房担当者の人数である。負担度が大きい調理場は、調理品の提供が遅れる可能性が高い。このような調理場に対しては、担当者を増員する必要がある。しきい値は、増員が必要か否かの判断基準となる負担度の値であり、調理場毎に任意に設定される。

負担度、仕事量、処理能力の算出方法は、本実施形態に限定されるものではない。負担度は、店の混雑度にも関係するので、仕事量を処理能力で除算した値に時間帯に応じた係数を乗算して算出してもよい。仕事量は、調理待ちメニュー品目だけでなく調理中メニュー品目の平均調理時間も加味して算出してもよい。処理能力は、厨房担当者の人数にその厨房担当者の熟練度に応じた係数を乗算して算出してもよい。勿論、各調理場のしきい値を共通に設定する運用を否定するものでもない。

図４は、担当者ファイル４２のデータ構造を示す模式図である。担当者ファイル４２は、各フロア担当者の担当者ＩＤに関連付けて、担当者名、補助可ＩＤ及び勤務コードの各データを格納する。担当者ＩＤは、フロア担当者毎に設定される固有のコードである。各フロア担当者は、異なる担当者ＩＤによって識別される。担当者名は、担当者の固有名称である。補助可ＩＤは、担当者が厨房作業を補助できる調理場の調理場ＩＤである。全ての調理場を補助できる担当者に対しては、補助可ＩＤとして“ＡＬＬ”がセットされる。逆に、調理場を補助できない担当者に対しては、補助可ＩＤとして“０”がセットされる。

勤務コードは、担当者の当日の勤務体系を表す勤務データがセットされた勤務データファイル５２（図２，図６を参照）の識別コードである。勤務コードは、各担当者に対して一意に割り当てられる。すなわち、各担当者に対して１つの勤務データファイル５２がそれぞれ割り当てられる。

作業管理サーバ１７は、作業管理装置としての機能を実現するために、ＲＡＭ２３に調理場別の作業データファイル５１と担当者別の勤務データファイル５２とを保存する。

図５は、作業データファイル５１のデータ構造を示す模式図である。作業データファイル５１は、調理場の数だけＲＡＭ２３に保存される。作業データファイル５１は、調理場ＩＤ、調理人数及び警告カウンタＨＴの格納エリアと、メニューＩＤ、平均調理時間、客席ＩＤ及び進捗状況ステータスの蓄積エリアとを有する。

調理場ＩＤエリアには、調理場ＩＤが格納される。調理人数エリアには、この調理場ＩＤで識別される調理場で作業をしている人数が格納される。警告カウンタＨＴは、初期値が“０”であり、負担度が前記しきい値を超える時間の経過に応じてカウントアップする。

メニューＩＤ、平均調理時間、客席ＩＤ及び進捗状況ステータスは、この調理場ＩＤで識別される調理場において調理されるメニュー品目のなかで、注文を受け付けたメニュー品目のデータである。メニューＩＤ及び平均調理時間は、メニュー品目毎に設定されたデータである。客席ＩＤは、当該メニュー品目を注文した客が着いた客席の客席ＩＤである。進捗状況ステータスは、当該メニュー品目の調理進捗状況を識別するデータである。進捗状況とは、例えば未調理、調理中、調理終了等である。

図６は、勤務データファイル５２のデータ構造を示す模式図である。勤務データファイル５２は、少なくともフロア担当を含む所定の店員の人数分だけＲＡＭ２３に保存される。勤務データファイル５２は、勤務コード及び出退フラグの格納エリアと、作業時間帯及び休憩時間帯の蓄積エリアとを有する。

勤務コードは、各店員に対して割り当てられたコードである。出退フラグは、その勤務コードで特定される店員の出退勤を識別するフラグである。作業時間帯及び休憩時間帯は、所定の期間（１週間、１か月間等）における毎出勤日の作業時間帯と休憩時間帯である。

作業管理サーバ１７は、作業管理装置としての機能を実現するために、ＲＯＭ２２にアプリケーションプログラムである作業管理プログラムを格納する。図７〜図９は、この作業管理プログラムにしたがってＣＰＵ２１が実行する主要な情報処理手順を示す流れ図である。図１１〜図１３は、表示デバイス３２に表示される画面の一例である。以下、図９〜図１３を用いて、作業管理サーバ１７の主要な動作について説明する。

図１０の画面は、基本画面６０である。基本画面６０は、フロアエリア６１を中央に配置し、向って左端に担当者エリア６２を配置し、右端に厨房エリア６３を配置する。フロアエリア６１は、客席フロアのレイアウト画像を表示する領域である。レイアウト画像は、客席に対応した複数の客席アイコン６１Ａ〜６１Ｋを客席のレイアウトにしたがって配置した画像である。客席アイコン６１Ａ〜６１Ｋは、客席の状況（空席、着席等）によって例えば色が変化する。注文したメニュー品目が配膳されたか否かによって、客席アイコン６１Ａ〜６１Ｋの色等を変化させてもよい。複数のフロアを有する飲食店の場合には、タブの選択により別フロアのレイアウト画像に切り替えられる。

担当者エリア６２は、複数個（図では６個）の担当者アイコン６２Ａ〜６２Ｆを表示する領域である。担当者アイコン６２Ａ〜６２Ｆは、それぞれフロア担当者を表す。調理場に対して増員が必要となった場合、フロア担当者の多くは補助要員として調理場に一時的に配置転換される。ここに、担当者アイコン６２Ａ〜６２Ｆは、補助要員を表す補助要員アイコンとして機能する。

担当者エリア６２に表示される担当者アイコン６２Ａ〜６２Ｆの数は６個に限定されるものではなく、５個以下でもよいし、７個以上でもよい。担当者エリア６２内を担当者アイコン６２Ａ〜６２Ｆがスクロール表示されるようにしてもよい。担当者アイコン６２Ａ〜６２Ｆに表示される文字は、その担当者の固有名称を示す。

厨房エリア６３は、厨房の各調理場にそれぞれ対応した調理場アイコン６３Ａ〜６３Ｅと人数アイコン６４とを表示する領域である。人数アイコン６４は、調理場で作業する厨房担当者の人数を示す。調理場アイコン６３Ａ〜６３Ｅは、インジケータ６５を含む。インジケータ６５は、調理場の負担度を示す。ここに、調理場アイコン６３Ａ〜６３Ｅは、作業アイコンとして機能する。

このような基本画面６０は、作業管理プログラムにしたがってＣＰＵ２１が表示させる。ここにＣＰＵ２１は、作業の業種別（調理場別）に負担度を示すインジケータ６５を表す作業アイコン（調理場アイコン６３Ａ〜６３Ｅ）と、補助要員別にその補助要員を表す補助要員アイコン（担当者アイコン６２Ａ〜６２Ｆ）とを、一画面に表示する表示手段を構成する。

図７は、作業管理プログラムにしたがってＣＰＵ２１が実行する割込処理の手順を示す流れ図である。この処理は、任意の時間であるｔ秒毎に発生する割込み信号の入力によりスタートする。

すなわち割込信号が入力されると、ＣＰＵ２１は、ＩＤカウンタｎを“０”にリセットする（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４６の処理を実行してもよい。

一方、Act４３において警告中の場合（Act４３にてＹＥＳ）、あるいはAct４５において予測負担度Ｂ０がしきい値Ｓ１を超える場合には（Act４５にてＹＥＳ）、ＣＰＵ２１は、補助者を戻してよいかオペレータに問い合わせるメッセージを表示デバイス３２に表示させる（Act４９）。そしてＣＰＵ２１は、オペレータからの入力を待機する（Act５０）。ここで、入力デバイス３１を介して「ＮＯ」、つまり取消操作がなされた場合には（Act５０にてＮＯ）、補助者を戻さない旨を受け付けたので、ＣＰＵ２１は、この処理を終了する。

これに対し、入力デバイス３１を介して「ＹＥＳ」、つまり実行操作がなされた場合には（Act５０にてＹＥＳ）、補助者を戻す旨を受け付けたので、ＣＰＵ２１は、Act４６の処理に進む。すなわちＣＰＵ２１は、補助者である店員「ＥＥ」の作業終了を通知するメッセージを送信する。

このように、増員した補助者を元へ戻す場合においても、その補助者を示すアイコン６６を選択するだけの簡単な操作で対応することができる。

本発明は、前記実施形態に限定されるものではない。
例えば前記実施形態では、負担度Ｂが増加したことを警告する報知手段として、ライブ画像７０を表示する例を示したが、報知手段はこれに限定されるものではない。例えば、負担度Ｂが増加した調理場の調理場アイコン６３Ａ〜６３Ｅの表示形態を変えることで警告してもよい。あるいは、音声出力によって警告してもよいのは言うまでもないことである。

また、基本画面６０のレイアウトは、図１０に示す画像に限定されるものではない。少なくとも担当者アイコン６２Ａ〜６２Ｆが配列される担当者エリア６２と、調理場アイコン６３Ａ〜６３Ｅが配列される厨房エリア６３とが一画面に表示されていればよい。また、補助要員アイコンである担当者アイコン６２Ａ〜６２Ｆの選択操作と、作業アイコンである調理場アイコン６３Ａ〜６３Ｅの選択操作もドラッグ＆ドロップに限定されるものではなく、種々の方法を適用することができる。

また、作業管理装置として次のような実施形態も考えられる。図１４は、他の実施形態において、表示デバイス３２に表示される画面８０の一例である。すなわちこの画面８０は、基本画面６０のフロアエリア６１と担当者エリア６２とを、担当者別の時間帯エリア８１としたものである。時間帯エリア８１には、フロア担当者毎に時間帯を示すグラフ８２Ａ〜８２Ｆが表示される。グラフ８２Ａ〜８２Ｆは、作業時間帯とそれ以外の時間帯とを区別する。図１４では、作業時間帯をハッチングで示している。

例えば、基本画面６０が表示されているときに担当者エリア６２がクリックされると、画面８０に切り替わるようにする。そうすることにより、作業管理者は、各フロア担当者の作業時間帯を容易に知ることができる。

また、図１４の画面例では、担当者アイコン６２Ａ〜６２Ｆに数字が表示されている。この数字は、現在時刻（図では破線Ｔ）を基準とした場合の残りの作業時間帯を示す。例えば担当者アイコン６２Ａに表示それる数字“１”は、残りの作業時間が１時間以上で２時間未満を示す。同様に、例えば担当者アイコン６２AＢに表示それる数字“３”は、残りの作業時間が３時間以上で４時間未満を示す。作業担当者は、この数字を見ることにより、各フロア担当者の残りの作業時間を容易に知ることができる。

つまり、いずれかの調理場で負担度が増加したためにサポートが必要となった場合、作業管理者は、図７の画面８０を表示させる。そうすると、この画面８０に表示される情報から、作業管理者は、補助者としてふさわしいフロア担当者を容易に選定することができる。

前記実施形態は、飲食店向けの作業管理装置として作業管理サーバ１７を例示したが、作業管理装置は、飲食店向けのものに限定されるものではない。通常は、異なる作業をそれぞれの担当者が実施するが、いずれかの作業で端度が増加した場合には別の作業担当者を補助者として一時的に異動させる場合の作業管理装置として適用できるのである。

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

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

１…飲食店システム、１１…オーダ端末、１２…中継機、１３…厨房端末、１４…会計端末、１５…メニューサーバ、１６…注文管理サーバ、１７…作業管理サーバ、１９…ビデオカメラ、４１…調理場ファイル、４２…担当者ファイル、５１…作業データファイル、５２…勤務データファイル、６０…基本画面。

一実施形態において、作業管理装置は、表示手段と、確認手段と、検出手段と、制御手段とを備える。表示手段は、作業の業種別に作業量と処理能力とから導出される負担度を示すインジケータを表す作業アイコンと、前記作業を補助する補助要員別にその補助要員を表す補助要員アイコンとを、一画面に表示する。確認手段は、前記作業の業種毎に前記負担度が所定のしきい値を超えたか否かを確認する。検出手段は、前記負担度が所定のしきい値を超えた業種の作業補助を可能な補助要員を検出する。制御手段は、前記一画面に表示される前記補助要員アイコンのうち前記検出手段により検出された補助要員を表す補助要員アイコンを補助可能であることを示す表示形態とする。

つまり、いずれかの調理場で負担度が増加したためにサポートが必要となった場合、作業管理者は、図１４の画面８０を表示させる。そうすると、この画面８０に表示される情報から、作業管理者は、補助者としてふさわしいフロア担当者を容易に選定することができる。

この他、本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
以下に、本願の分割直前の特許請求の範囲に記載された発明を付記する。
［１］作業の業種別に、作業量と処理能力とから導出される負担度を示すインジケータを表す作業アイコンと、前記作業を補助する補助要員別に、その補助要員を表す補助要員アイコンとを、一画面に表示する表示手段と、前記補助要員アイコンの選択と、該選択された前記補助要員アイコンで表される前記補助要員が補助する作業に対する前記作業アイコンの選択とを受け付ける受付手段と、前記受付手段により選択を受け付けた前記補助要員アイコンで表される補助要員に対し、前記受付手段により選択を受け付けた前記作業アイコンで表される作業を補助する旨を通知する通知手段と、を具備したことを特徴とする作業管理装置。
［２］前記作業の業種毎に前記負担度が所定のしきい値を超えたか否かを確認する確認手段と、前記負担度が前記しきい値を超えた作業を報知する報知手段と、をさらに具備したことを特徴とする付記［１］記載の作業管理装置。
［３］前記受付手段は、前記負担度が前記しきい値を超えていない作業に対する作業アイコンが選択された場合に確認を促すことを特徴とする付記２記載の作業管理装置。
［４］前記補助要員アイコンで表される補助要員が作業補助を可能か判定する判定手段、をさらに具備し、前記受付手段は、前記作業補助を可能でないと判定された補助要員を表す補助要員アイコンの選択を拒否することを特徴とする付記［１］乃至［３］のうちいずれか１に記載の作業管理装置。
［５］前記受付手段により選択を受け付けた前記補助要員アイコンで表される補助要員が前記受付手段により選択を受け付けた前記作業アイコンで表される作業を補助することによってアップする処理能力で前記負担度を導出して前記インジケータを更新する更新手段、をさらに具備したことを特徴とする付記［１］乃至［４］のうちいずれか１に記載の作業管理装置。
［６］表示デバイスを備えるコンピュータに、作業の業種別に、作業量と処理能力とから導出される負担度を示すインジケータを表す作業アイコンと、前記作業を補助する補助要員別に、その補助要員を表す補助要員アイコンとを、前記表示デバイスの一画面に表示させる機能、前記補助要員アイコンの選択と、該選択された前記補助要員アイコンで表される前記補助要員が補助する作業に対する前記作業アイコンの選択とを受け付ける機能、及び前記選択を受け付けた前記補助要員アイコンで表される補助要員に対し、前記選択を受け付けた前記作業アイコンで表される作業を補助する旨を通知する機能、を実現させるための作業管理プログラム。

Claims (6)

1. 作業の業種別に、作業量と処理能力とから導出される負担度を示すインジケータを表す作業アイコンと、前記作業を補助する補助要員別に、その補助要員を表す補助要員アイコンとを、一画面に表示する表示手段と、
   前記補助要員アイコンの選択と、該選択された前記補助要員アイコンで表される前記補助要員が補助する作業に対する前記作業アイコンの選択とを受け付ける受付手段と、
   前記受付手段により選択を受け付けた前記補助要員アイコンで表される補助要員に対し、前記受付手段により選択を受け付けた前記作業アイコンで表される作業を補助する旨を通知する通知手段と、を具備したことを特徴とする作業管理装置。
2. 前記作業の業種毎に前記負担度が所定のしきい値を超えたか否かを確認する確認手段と、
   前記負担度が前記しきい値を超えた作業を報知する報知手段と、をさらに具備したことを特徴とする請求項１記載の作業管理装置。
3. 前記受付手段は、前記負担度が前記しきい値を超えていない作業に対する作業アイコンが選択された場合に確認を促すことを特徴とする請求項２記載の作業管理装置。
4. 前記補助要員アイコンで表される補助要員が作業補助を可能か判定する判定手段、をさらに具備し、
   前記受付手段は、前記作業補助を可能でないと判定された補助要員を表す補助要員アイコンの選択を拒否することを特徴とする請求項１乃至３のうちいずれか１に記載の作業管理装置。
5. 前記受付手段により選択を受け付けた前記補助要員アイコンで表される補助要員が前記受付手段により選択を受け付けた前記作業アイコンで表される作業を補助することによってアップする処理能力で前記負担度を導出して前記インジケータを更新する更新手段、
   をさらに具備したことを特徴とする請求項１乃至４のうちいずれか１に記載の作業管理装置。
6. 表示デバイスを備えるコンピュータに、
   作業の業種別に、作業量と処理能力とから導出される負担度を示すインジケータを表す作業アイコンと、前記作業を補助する補助要員別に、その補助要員を表す補助要員アイコンとを、前記表示デバイスの一画面に表示させる機能、
   前記補助要員アイコンの選択と、該選択された前記補助要員アイコンで表される前記補助要員が補助する作業に対する前記作業アイコンの選択とを受け付ける機能、及び
   前記選択を受け付けた前記補助要員アイコンで表される補助要員に対し、前記選択を受け付けた前記作業アイコンで表される作業を補助する旨を通知する機能、
   を実現させるための作業管理プログラム。