JP5184744B2 - スケジュールを管理する方法及び当該方法を実現するサーバ及びプログラム - Google Patents

Description

本発明は、スケジュールを管理する方法及び当該方法を実現するサーバ及びプログラムに関する。特に、勤務スケジュールを管理する方法及び当該方法を実現するサーバ及びプログラムに関する。

従来、従業員の勤務スケジュールを管理する方法として、様々なものが提案されている。例えば、特許文献１には、コールセンターのオペレータの希望スケジュールデータをネットワークを介して収集し、収集した当該希望スケジュールデータに基づいて、所定期間におけるスケジュールデータを作成するスケジュール管理システムが開示されている。

当該スケジュール管理システムは、各オペレータからの希望スケジュールデータをネットワークを介して受け付けると共に、所定期間に必要なオペレータの数を予測し、双方のデータを比較することによって、スケジュールを確定する。

このようなシステムによれば、各オペレータは、自らの希望スケジュールをネットワークを介して送信することにより、予測される必要なオペレータ数と過不足なく一致した場合には、その希望を反映した勤務スケジュールを確定することができる。
特開２００３−１６７９８１号公報

しかしながら、上述のようなシステムにおいては、各オペレータは、希望スケジュールを入力する際に、予測された必要なオペレータ数を知ることができない。そのため、例えば、ピーク日や閑散日など、日や時間帯によって予測された必要なオペレータ数に差異がある場合に、そのような差異に合わせて勤務スケジュールを調整可能なオペレータがいたとしても、そのような調整の検討を実際には行うことができない。

更に、随時希望スケジュールの入力が行われた結果、日や時間帯によって過不足人数の差異がある場合にも、同様の理由によって、各オペレータは、そのような過不足人数の際を認識して、入力する希望スケジュールの調整の検討を行うことができない。

上述のような調整の検討が行われないために、各オペレータの希望スケジュールの入力の結果が、予測された必要なオペレータ数と合わない可能性が高くなる。そして、そのような場合には、スケジュール管理者が再度スケジュールの調整を行わなければならない。

本発明は、上述のような課題を解決するために、希望する勤務スケジュールの送信を行う端末に対して、あらかじめ予測される必要人数に関する情報を送信する手段有するスケジュール管理サーバを提供することを目的とする。

（１） 通信ネットワーク（例えば、後述の内部通信ネットワーク３、外部通信ネットワーク５など）に接続されたコンピュータ（例えば、後述のサーバ１、管理者用端末２など）が複数の要員の勤務スケジュールを管理する方法であって、前記コンピュータが、前記複数の要員の想定スケジュールを表す想定スケジュールデータ（例えば、後述の想定スケジュールデータテーブルなど）を生成する想定スケジュールデータ生成ステップ（例えば、後述の想定スケジュールデータ作成処理ステップＳ１００）と、前記コンピュータが、所定期間を指定して、前記通信ネットワークに接続された端末（例えば、後述のオペレータ端末４、オペレータの携帯端末６ａ、６ｂなど）から前記複数の要員の希望スケジュールを表す希望スケジュールデータ（例えば、後述の希望スケジュールデータテーブルなど）の受け付けを開始する希望スケジュールデータ受け付け開始ステップ（例えば、後述のステップＳ２０１及びステップＳ２０３など）と、前記コンピュータが、前記通信ネットワークに接続された端末からの要求に応じて、生成した前記想定スケジュールデータを、前記端末に送信する想定スケジュールデータ送信ステップ（例えば、後述のステップＳ２０９など）と、前記コンピュータが、前記複数の要員の希望スケジュールを表す希望スケジュールデータを、前記端末から受信して記憶する希望スケジュールデータ受信ステップ（例えば、後述のステップＳ２１９など）と、前記コンピュータが、指定した前記所定期間の経過後、前記想定スケジュールデータと前記希望スケジュールデータとに基づいて前記複数の要員の仮決定スケジュールを表す仮決定スケジュールデータ（例えば、後述の仮決定スケジュールデータテーブルなど）を生成する仮決定スケジュールデータ生成ステップ（例えば、後述のステップＳ３００など）と、を含む方法。

（１）の発明によれば、当該コンピュータは、複数の要員の想定スケジュールを表す想定スケジュールデータを生成し、所定期間を指定して、通信ネットワークに接続された端末から当該複数の要員の希望スケジュールを表す希望スケジュールデータの受け付けを開始し、当該通信ネットワークに接続された端末からの要求に応じて、生成した当該想定スケジュールデータを、当該端末に送信し、当該複数の要員の希望スケジュールを表す希望スケジュールデータを、当該端末から受信して記憶し、指定した前記所定期間の経過後、当該想定スケジュールデータと当該希望スケジュールデータとに基づいて、当該複数の要員の仮決定スケジュールを表す仮決定スケジュールデータを生成する。

このことにより、当該端末に希望スケジュールデータを入力する複数の要員に対して、当該端末は、あらかじめ当該想定スケジュールを表示することができる。その結果、当該想定スケジュールを見た当該複数の要員は、その想定スケジュールを参考にして希望スケジュールを検討し、希望スケジュールデータを入力することができる。

（２） 前記コンピュータが、前記想定スケジュールデータ送信ステップにおいて、前記端末からの要求（例えば、後述のステップＳ２０５など）に応じて、記憶した前記希望スケジュールデータを、前記端末に合わせて送信（例えば、後述のステップＳ２０９など）する（１）に記載の方法。

（２）の発明によれば、当該コンピュータは、前記端末からの要求に応じて、記憶した前記希望スケジュールデータを、前記端末に合わせて送信する。

このことにより、当該所定期間において、当該複数の要員が希望スケジュールデータの入力を行う際に、当該端末は、その時点で当該コンピュータに記憶されている希望スケジュールを合わせて表示することができる。従って、各々の要員は、想定スケジュールに加えて、他の要員の希望スケジュールもあわせて参照して自らの希望スケジュールを検討することができる。

（３） 前記コンピュータが、前記想定スケジュールデータ生成ステップにおいて、前記想定スケジュールに関するピーク情報を表すピークデータ（例えば、後述の週休データなど）を更に生成（例えば、後述のステップＳ１１３など）し、前記コンピュータが、前記想定スケジュールデータ送信ステップにおいて、生成した前記ピークデータをあわせて前記端末に送信（例えば、後述のステップＳ２０９など）する（１）または（２）に記載の方法。

（３）の発明によれば、当該コンピュータは、当該想定スケジュールに関するピーク情報を表すピークデータを更に生成し、生成した当該ピークデータをあわせて当該端末に送信する。

このことにより、当該所定期間において、当該複数の要員が希望スケジュールデータの入力を行う際に、当該端末は、当該想定スケジュールに関するピーク情報を合わせて表示することができる。従って、各々の要員は、想定スケジュールに加えて、当該ピーク情報もあわせて参照して自らの希望スケジュールを検討することができる。

（４） 前記コンピュータが、前記希望スケジュールデータ受信ステップにおいて、前記希望スケジュールの優先順位を表す優先順位データをあわせて受信（例えば、後述のステップＳ２１９など）し、前記コンピュータが、前記仮決定スケジュールデータ生成ステップにおいて、前記想定スケジュールデータと、前記希望スケジュールデータと、前記優先順位データと、に基づいて仮決定スケジュールデータ（例えば、後述の仮決定スケジュールデータテーブルなど）を生成（例えば、後述のステップＳ３０９など）する（１）から（３）のいずれかに記載の方法。

（４）の発明によれば、当該コンピュータは、当該希望スケジュールの優先順位を表す優先順位データをあわせて受信し、当該想定スケジュールデータと、当該希望スケジュールデータと、当該優先順位データと、に基づいて仮決定スケジュールデータを生成する。

このことにより、当該要員が入力した当該希望スケジュールの優先順位に基づいて、仮決定スケジュールを決定することができる。したがって、各々の要員の希望スケジュールを、より柔軟な判断に基づいて当該仮決定スケジュールに反映することができる。

（５） 前記コンピュータが、前記希望スケジュールデータ受信ステップにおいて、各々の要員の端末から所定の回数のみ前記希望スケジュールデータの受信（例えば、後述のステップＳ２１９など）を行う（１）から（４）のいずれかに記載の方法。

（５）の発明によれば、当該コンピュータは、各々の要員の端末から所定の回数のみ前記希望スケジュールデータの受信を行う。

このことにより、特定の要員が他の要員に比べて大量の希望スケジュールデータを送信することを防止し、結果として、仮決定スケジュールデータにより多くの要員の希望スケジュールを反映させることができる。

（６） 前記コンピュータが、前記仮決定スケジュールデータ生成ステップにおいて、前記複数の要員の数が、あらかじめ指定された最大数を超えない範囲（例えば、図１８の上限線１８９）で、前記仮決定スケジュールデータを生成する、（１）から（５）のいずれかに記載の方法。

（６）の発明によれば、当該コンピュータは、要員の数が、あらかじめ指定された最大数を超えない範囲で、仮決定スケジュールデータを生成する。

このことにより、スケジュール可能な要員の最大数を超えたスケジュールの設定を防止することができる。

（７） 前記コンピュータが、前記仮決定スケジュールデータ生成ステップにおいて、前記複数の要員の、所定の作業に対する処理効率データ（例えば、図１８の処理効率１８６）に基づいて、前記仮決定スケジュールデータを生成する、（１）から（６）のいずれかに記載の方法。

（７）の発明によれば、要員の、所定の作業に対する処理効率データに基づいて、仮決定スケジュールデータを生成することができる。

このことにより、各々の処理効率が異なる複数の要員を含む場合であっても、要求される作業の量を満たすスケジュールを作成することが可能となる。例えば、ある作業について処理効率１００パーセントの要員が１人必要な場合に、処理効率５０パーセントの要員しかいない場合、処理効率５０パーセントの要員を２人スケジュールすることで、必要な作業量を満たすようにする、等の対応が可能となる。

（８） 前記コンピュータが、前記仮決定スケジュールデータ生成ステップにおいて、前記複数の要員のうち所定の要員について、重複した複数の仮決定スケジュールを生成する、（１）から（７）のいずれかに記載の方法。

（８）の発明によれば、所定の要員について、重複した複数の仮決定スケジュールデータを生成することができる。

このことにより、同時に複数の業務を担当できる要員について、同時に複数の業務を割り当てることができる。より具体的には、例えば、空いている時間に即時性の低い他の業務を行わせることができ、より効率的なスケジュール設定をすることが可能となる。

（９） 通信ネットワーク（例えば、後述の内部通信ネットワーク３、外部通信ネットワーク５など）に接続されたコンピュータ（例えば、後述のサーバ１、管理者用端末２など）に複数の要員の勤務スケジュールを管理させるプログラムであって、前記コンピュータに、前記複数の要員の想定スケジュールを表す想定スケジュールデータ（例えば、後述の想定スケジュールデータテーブルなど）を生成させる想定スケジュールデータ生成ステップ（例えば、後述の想定スケジュールデータ作成処理ステップＳ１００）と、前記コンピュータに、所定期間を指定して、前記通信ネットワークに接続された端末（例えば、後述のオペレータ端末４、オペレータの携帯端末６ａ、６ｂなど）から前記複数の要員の希望スケジュールを表す希望スケジュールデータ（例えば、後述の希望スケジュールデータテーブルなど）の受け付けを開始させる希望スケジュールデータ受け付け開始ステップ（例えば、後述のステップＳ２０１及びステップＳ２０３など）と、前記コンピュータに、前記通信ネットワークに接続された端末からの要求に応じて、生成した前記想定スケジュールデータを、前記端末に送信させる想定スケジュールデータ送信ステップ（例えば、後述のステップＳ２０９など）と、前記コンピュータに前記複数の要員の希望スケジュールを表す希望スケジュールデータを、前記端末から受信させて記憶させる希望スケジュールデータ受信ステップ（例えば、後述のステップＳ２１９など）と、前記コンピュータに、指定した前記所定期間の経過後、前記想定スケジュールデータと前記希望スケジュールデータとに基づいて前記複数の要員の仮決定スケジュールを表す仮決定スケジュールデータ（例えば、後述の仮決定スケジュールデータテーブルなど）を生成させる仮決定スケジュールデータ生成ステップ（例えば、後述のステップＳ３００など）と、を実行させるプログラム。

（９）に記載の発明によれば、当該コンピュータを運用することによって、（１）と同様の効果が期待できる。

（１０） 前記想定スケジュールデータ送信ステップにおいて、前記コンピュータに、前記端末からの要求（例えば、後述のステップＳ２０５など）に応じて、記憶した前記希望スケジュールデータを、前記端末に合わせて送信させる（例えば、後述のステップＳ２０９など）、（９）に記載のプログラム。

（１０）に記載の発明によれば、当該コンピュータを運用することによって、（２）と同様の効果が期待できる。

（１１） 前記想定スケジュールデータ生成ステップにおいて、前記コンピュータに、前記想定スケジュールに関するピーク情報を表すピークデータ（例えば、後述の週休取得禁止日など）を更に生成させるステップ（例えば、後述のステップＳ１１３など）を実行させ、前記想定スケジュールデータ送信ステップにおいて、前記コンピュータに、生成した前記ピークデータをあわせて前記端末に送信させる（例えば、後述のステップＳ２０９など）、（９）または（１０）に記載のプログラム。

（１１）に記載の発明によれば、当該コンピュータを運用することによって、（３）と同様の効果が期待できる。

（１２） 前記希望スケジュールデータ受信ステップにおいて、前記コンピュータに、前記希望スケジュールの優先順位を表す優先順位データをあわせて受信（例えば、後述のステップＳ２１９など）させるステップを実行させ、前記仮決定スケジュールデータ生成ステップにおいて、前記コンピュータに、前記想定スケジュールデータと、前記希望スケジュールデータと、前記優先順位データと、に基づいて仮決定スケジュールデータ（例えば、後述の仮決定スケジュールデータテーブルなど）を生成させる（例えば、後述のステップＳ３０９など）、（９）から（１１）のいずれかに記載のプログラム。

（１２）に記載の発明によれば、当該コンピュータを運用することによって、（４）と同様の効果が期待できる。

（１３） 前記希望スケジュールデータ受信ステップにおいて、前記コンピュータに、各々の要員の端末から所定の回数のみ前記希望スケジュールデータの受信（例えば、後述のステップＳ２１９など）を行わせる、（９）から（１２）のいずれかに記載のプログラム。

（１３）に記載の発明によれば、当該コンピュータを運用することによって、（５）と同様の効果が期待できる。

（１４） 前記仮決定スケジュールデータ生成ステップにおいて、前記コンピュータに、前記複数の要員の数が、あらかじめ指定された最大数を超えない範囲で、前記仮決定スケジュールデータを生成させる、（９）から（１３）のいずれかに記載の方法。

（１４）の発明によれば、当該コンピュータを運用することによって、（６）と同様の効果が期待できる。

（１５） 前記コンピュータに、前記仮決定スケジュールデータ生成ステップにおいて、前記複数の要員の、所定の作業に対する処理効率データに基づいて、前記仮決定スケジュールデータを生成させる、（９）から（１４）のいずれかに記載の方法。

（１５）の発明によれば、当該コンピュータを運用することによって、（７）と同様の効果が期待できる。

（１６） 前記コンピュータに、前記仮決定スケジュールデータ生成ステップにおいて、前記複数の要員のうち所定の要員について、重複した複数の仮決定スケジュールを作成させる、（９）から（１５）のいずれかに記載の方法。

（１６）の発明によれば、当該コンピュータを運用することによって、（８）と同様の効果が期待できる。

（１７） （９）から（１６）のいずれかに記載のプログラムを記憶する記憶媒体。

（１７）に記載の発明によれば、当該記憶媒体を当該コンピュータに挿入して当該プログラムを実行させることによって、それぞれ（１）から（８）と同様の効果が期待できる。

本発明によれば、端末に希望スケジュールデータを入力する複数の要員に対して、当該端末は、あらかじめ想定スケジュールを表示することができる。このことにより、当該想定スケジュールを見た当該複数の要員は、その想定スケジュールを参考にして希望スケジュールを検討し、希望スケジュールデータを入力することができる。

その結果、各々の要員は、自らの希望が仮決定スケジュールに反映される、という期待感を持ちつつ、当該希望スケジュールの入力時に、想定スケジュールを参照し、自らが入力する希望スケジュールの検討が可能となることによって、勤務スケジュール管理において、おのずと労使協調関係を醸成する可能性がある。

以下、本発明の好適な実施形態の一例について、図面に基づいて以下に説明する。

図１は、本発明の好適な実施形態の一例に係るコンピュータシステムの全体構成を示す概念図である。本システムにおいて、サーバ１、管理者用端末２、及びオペレータ端末４は、内部通信ネットワーク３を介して相互に接続されて構成されている。また、これらの情報機器は、更に外部通信ネットワーク５を介して、オペレータの携帯端末６ａ、６ｂに接続可能であってよい。ここで、本システムを構成するサーバ１、管理者用端末２、オペレータ端末４、オペレータの携帯端末６ａ、６ｂの数は任意であり、状況に応じて選択可能である。

サーバ１は、本システム全体の管理を行い、オペレータ端末４等にデータ送信を行う。そして、過去のコール量等の統計データ、オペレータのスキルや連絡先等の個人情報、評価情報、スケジュールデータ等を記憶し、管理者用端末２やオペレータ端末４等からの要求に応じて、スケジュールデータを作成するなどの各種処理を実行する。

ここで、スケジュールとは、所定の単位の業務について、オペレータの割り当てや週休管理を行う情報のことをいう。そして、このスケジュールを記憶したものがスケジュールデータである。このスケジュールデータには、過去のコール量から予想されるコール量を算出し、予想される当該コール量に基づいてオペレータの想定人数を決定して作成する想定スケジュールデータ、また、当該想定スケジュールに基づいて、実際にオペレータの配置や募集を行って作成する、仮決定スケジュールデータ等がある。

管理者用端末２は、管理者の入力操作に基づいて、サーバ１に対してスケジュールの作成要求を行ったり、スケジュールにしたがってオペレータの割り当てや週休の管理を行う端末である。また、随時サーバ１にアクセスし、スケジュールの設定やオペレータの応募もしくは募集についての作成要求や応答を行う。

オペレータ端末４は、オペレータの入力操作に基づいて、サーバ１が公開する各スケジュールに対して、週休の希望申請やオペレータの募集に対する応募や採用等に対する応答を行う端末である。

図２は、本発明の好適な実施形態の一例に係るサーバ１、管理者用端末２、オペレータ端末４の構成を示すブロック図である。

サーバ１は、制御部１１、通信部１２、記憶部１３、入力部１６、及び表示部１７により構成され、それぞれバス１８を介して接続されている。また、記憶部１３は、少なくとも統計データ記憶部１４及びスケジュールデータ記憶部１５を含む。統計データ記憶部１４は、コール量統計データやオペレータに関する情報等の統計データを記憶する。スケジュールデータ記憶部１５は、想定スケジュールデータ、仮決定スケジュールデータ、その他スケジュールデータを作成するための各種データを記憶する。その他スケジュールデータを作成するための各種データとは、例えば、予測コール量データ、週休データ等である。

制御部１１は、情報の演算、処理を行う情報演算処理装置（ＣＰＵ）であり、サーバ１全体の制御を行う。制御部１１は、記憶部１３に記憶された各種プログラムを適宜読み出して実行することにより、上述のハードウエアと協働し、本発明に係る各種機能を実現している。

記憶部１３は、制御部１１と組み合わせてプログラムの実行に使用するローカルメモリ、大容量のバルクメモリ、および当該バルクメモリの検索を効率的に行うために使用するキャッシュメモリを含んでよい。そして、制御部１１が実行する各種プログラム等を記憶する。記憶部１３を実現するコンピュータ可読媒体としては、電気的、磁気的、光学的、電磁的に実現するものを含んでよい。より具体的には、半導体記憶装置、磁気テープ、磁気ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リードオンリー・メモリ（ＲＯＭ）、ＣＤ−ＲＯＭとＣＤ−Ｒ／ＷとＤＶＤとを含む光ディスクが含まれる。また、記憶部１３に含まれる統計データ記憶部１４、スケジュールデータ記憶部１５については、サーバ１とは別体であってよい。

入力部１６は、管理者等による入力の受付を行うものであり、キーボード、ポインティングデバイス等を含んでよい。入力部１６は、直接または介在Ｉ／Ｏコントローラを介してサーバ１と接続することができる。

表示部１７は、管理者等にデータの入力を受け付ける画面を表示したり、サーバ１による演算処理結果の画面を表示したりするものであり、ブラウン管表示装置（ＣＲＴ）、液晶表示装置（ＬＣＤ）等のディスプレイ装置を含む。

通信部１２は、サーバ１を内部通信ネットワーク３または外部通信ネットワーク５を介してオペレータ端末またはオペレータの携帯端末６ａ、６ｂや記憶装置と接続できるようにするためのネットワーク・アダプタである。通信部１２は、モデム、ケーブル・モデムおよびイーサネット（登録商標）・アダプタを含んでよい。

管理者用端末２及びオペレータ端末４は、それぞれ、制御部２１、４１、通信部２２、４２、記憶部２３、４３、入力部２４、４４、表示部２５、４５で構成され、それぞれバス２６、４６を介して接続されている。

制御部２１、４１は、情報の演算、処理を行う情報演算処理装置（ＣＰＵ）であり、それぞれ管理者用端末２、オペレータ端末４の全体の制御を行う。制御部２１、４１は、記憶部２３、４３に記憶された各種プログラムを適宜読み出して実行することにより、それぞれ上述のハードウエアと協働し、本発明に係る各種機能を実現している。

記憶部２３、４３は、それぞれ制御部２１、４１と組み合わせてプログラムの実行に使用するローカルメモリ、大容量のバルクメモリ、および当該バルクメモリの検索を効率的に行うために使用するキャッシュメモリを含んでよい。そして、制御部２１、４１が実行する各種プログラム等を記憶する。記憶部２３、４３を実現するコンピュータ可読媒体としては、電気的、磁気的、光学的、電磁的に実現するものを含んでよい。より具体的には、半導体記憶装置、磁気テープ、磁気ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リードオンリー・メモリ（ＲＯＭ）、ＣＤ−ＲＯＭとＣＤ−Ｒ／ＷとＤＶＤとを含む光ディスクが含まれる。

入力部２４、４４は、管理者等による入力の受付を行うものであり、キーボード、ポインティングデバイス等を含んでよい。入力部２４、４４は、直接または介在Ｉ／Ｏコントローラを介してそれぞれ管理者用端末２、オペレータ端末４と接続することができる。

表示部２５、４５は、それぞれユーザにデータの入力を受け付ける画面を表示したり、管理者用端末２による演算処理結果の画面を表示したりするものであり、ブラウン管表示装置（ＣＲＴ）、液晶表示装置（ＬＣＤ）等のディスプレイ装置を含む。

通信部２２、４２は、それぞれ管理者用端末２又はオペレータ端末４を内部通信ネットワーク３または外部通信ネットワーク５を介して別の演算処理システムまたは記憶装置と接続できるようにするためのネットワーク・アダプタである。通信部２２、４２は、モデム、ケーブル・モデムおよびイーサネット（登録商標）・アダプタを含んでよい。

図３は、本発明の好適な実施形態の一例に係るスケジュールの作成を行うメインフローである。以下、図面に基づいて説明する。

ステップＳ１００においては、想定スケジュールデータ作成処理を行う。この処理においては、例えば、管理者用端末２から想定スケジュール作成要求を受信したサーバ１は、コール量統計データから予測コール量データを算出し、当該予測コール量データに基づいてオペレータが参照するための想定されるオペレータの必要人数を含む週休データを作成する。この処理の詳細については後述する。この処理が終了した場合には、ステップＳ２００に処理を移す。

ステップＳ２００においては、希望スケジュールデータ作成処理を行う。この処理においては、例えば、サーバ１は、ステップＳ１００で作成した想定スケジュールデータをオペレータ端末４からの要求に応じて送信し、当該オペレータ端末４から送信されるオペレータの週休希望情報等を加味した希望スケジュールデータを作成する。この処理の詳細については後述する。この処理が終了した場合には、ステップＳ３００に処理を移す。

ステップＳ３００においては、仮決定スケジュールデータ作成処理を行う。この処理においては、例えば、サーバ１は、管理者用端末２からの要求に応じて、ステップＳ１００で作成した想定スケジュールデータと、ステップＳ２００で作成した希望スケジュールデータとに基づいて、仮決定スケジュールデータを作成する。この処理の詳細については後述する。この処理が終了した場合には、メインフローを終了する。

図４は、本発明の好適な実施形態の一例に係る想定スケジュールデータ作成処理を行う、サブルーチンのフローを示す図である。以下、図４から図１２に基づいて想定スケジュールデータ作成処理について説明する。

まず、管理者用端末２において、管理者の入力操作に応じて、管理者用端末２の制御部２１は、通信部２２を介して、想定スケジュールデータ作成要求信号をサーバ１に送信する（ステップＳ１０１）。サーバ１の制御部１１は、通信部１２を介して当該想定スケジュールデータ作成要求信号を受信する（ステップＳ１０３）。

ステップＳ１０５では、サーバ１の制御部１１は、当該想定スケジュールデータ作成要求信号の受信に応じてコール量統計データを統計データ記憶部１４から読み込む。コール量統計データとは、例えば、過去のある日付のコール量の記録を時間帯ごとに示したものである。このコール量統計データは、図５に示すようにグラフの様に表示され得る。この、サーバ１が読み込むコール量統計データは、ステップＳ１０１の想定スケジュールデータ作成要求を送信する際に管理者が指定してもよいし、又は、直近の日付や直近の過去の同じ曜日のコール量統計データをサーバ１が自動的に選択して読み込んでもよい。この処理が終了した場合には、ステップＳ１０７に処理を移す。

ステップＳ１０７では、制御部１１は、当該コール量統計データに基づいて、予測コール量を算出する。予測コール量の算出は、例えば、ステップＳ１０５で読み込んだコール量統計データに基づいて、週ごとの平均や特定日の平均等を計算して行う。この処理を行うにあたって、制御部１１は、一旦コール量統計データを管理者用端末２に送信して、管理者用端末２に表示（図６）して管理者による調整入力を受け付けた後、管理者用端末２の制御部２１が調整後の予測コール量データをサーバ１に送信するようにしてもよい。また、サーバ１に予め、例えば週の平均等から算出するように設定しておき、自動的にサーバ１の制御部１１がコール量統計データを読み出して予測コール量を算出するようにしてもよい。この処理が終了した場合には、ステップＳ１０９に処理を移す。

ステップＳ１０９では、制御部１１は、予測コール量に基づいて想定されるオペレータの必要人数を算出する。具体的には、例えば、所定の目標処理時間と予測コール量、平均待ち合わせ時間等から、オペレータの必要人数を算出していく。

例えば、現在、オペレータ数が７人でオペレータの１コールにかかる処理時間が５分である場合、１時間当たり６６個のコールがランダムに入るときに、平均待ち合わせ時間が１２秒以下になるようなオペレータ数を求めるとする。
入ってくる総呼量ａを求めると、１時間に６６コールで通話時間ｈが５分であるので、

オペレータ数ｃが７人であるため、これを下記の式に代入して計算する。

式２より、Ｅ_７（５．５）＝０．１５となる。そして、これから下記の式により、平均待ち合わせ時間Ｗを求めると、

となる。これは、現在の平均待ち合わせ時間が１．５２分であることを示している。次に、式３を使用して、この平均待ち合わせ時間Ｗを１２秒以下となるようにオペレータ数ｃを計算すると、ｃ＝９のときにＷ＝０．１８５分（１１．１秒）となるので、この場合は、９名必要であると算出される。

この想定されるオペレータの必要人数は、他の項目を加味して算出してもよい。例えば、コールを取ることのできない割合を示す放棄率やオペレータの欠席率、サービスレベル等である。サービスレベルとは、着信応答呼のうち、何パーセントの呼を何秒以内に応答するかを示すものである。例えば、図７のように、単位時間当たりの想定されるオペレータの必要人数が算出された結果が管理者用端末２の表示部２５に表示されてもよい。この図７では、棒グラフ７０が単位時間当たりの想定されるオペレータの必要人数を示している。この処理が終了した場合には、ステップＳ１１３に処理を移す。

ステップＳ１１３では、制御部１１は、予測コール量データ及び想定されるオペレータの必要人数のデータに基づいて、週休データを作成する。具体的には、例えば、制御部１１は、現在の総オペレータ数に対して、予測コール量データ及び想定されるオペレータの必要人数のデータに基づいて、週休取得可能な人数を自動的に算出する。例えば、図８の週休データテーブルのように、ある日付に対して週休取得可能な人数が入力される。この、週休データテーブルにおいて、週休取得可能な人数がゼロの場合は、週休取得禁止日となる。ところで、この週休取得禁止日は、例えば、管理者用端末２からの要求信号の受信に応じて管理者用端末２に送信し、管理者用端末２の制御部２１が、図９のような画面を表示部１７に表示して、管理者が任意の日を週休取得禁止日として入力することに応じて設定してもよい。図９では、各日付のチェックボックスにチェックを入力することにより、週休取得禁止日が設定されることを示している。更に、週休取得可能な人数のデータを、管理者用端末２からの要求信号の受信に応じて管理者用端末２に送信し、管理者用端末２の制御部２１が、図１０のように、表示部１７に表示してもよい。この処理が終了した場合には、ステップＳ１１５に処理を移す。

ステップＳ１１５では、制御部１１は、ピークデータ及び週休データを記憶部１３のスケジュールデータ記憶部１５に記憶する。この処理が終了した場合には、ステップＳ１１７に処理を移す。

ステップＳ１１７では、制御部１１は、想定スケジュールデータを作成する。想定スケジュールデータは、例えば、図１１のようなテーブルで表される。図１１の想定スケジュールデータテーブルは、ある日についての時間帯ごとに想定されるオペレータの必要人数を示したテーブルである。図１１では、例えば、８月１日の７時において、想定されるオペレータの必要人数は２６人であることを示している。この処理が終了した場合には、ステップＳ１１９に処理を移す。

ステップＳ１１９では、制御部１１は、想定スケジュールデータを記憶部１３のスケジュールデータ記憶部１５に記憶し、想定スケジュールデータを管理者用端末２に送信する（ステップＳ１２１）。この処理が終了した場合には、ステップＳ１２３に処理を移す。

ステップＳ１２３では、管理者用端末２の制御部２１は、想定スケジュールデータを受信し、想定スケジュールデータを表示部２５に表示する（ステップＳ１２５）。具体的には、例えば、図１２のような画面である。図１２では、単位時間及び業務の種類ごとに想定されるオペレータの必要人数が表示されている。例えば、図１２のグラフ１２１には、「サポートＥ−ｍａｉｌ」、「サポートＣｈａｔ」、及び「サポート電話」の３種類の業務の必要人数が示されている。そして、キューメニュー１２２から必要人数を算出したい業務名を選択することにより、業務毎の画面が表示され、各業務の必要人数を算出することができる。例えば、図１２の表示例では、サポート電話業務についての必要人数を算出するための画面であることを示す。このように、業務全体の必要人数が表示されるだけでなく、業務毎の必要人数が表示され、それぞれの業務についてスキルを持つオペレータを募集するための想定スケジュールを設定することが可能である。

ここで、管理者は、必要があれば、想定スケジュールデータを編集することが可能である。例えば、図１２のような画面を表示部２５に表示して、入力部２４を介して予測コール量の増減や、稼働率や応答の所要時間等を入力し、これに伴う想定されるオペレータの必要人数の増減といった編集を行うようにしてもよい（ステップＳ１２７）。

ステップＳ１２９では、管理者用端末２の制御部２１は、通信部２２を介して、編集した想定スケジュールデータをサーバ１に送信する。そして、ステップＳ１３１では、サーバ１の制御部１１が、通信部１２を介して管理者用端末２から送信された想定スケジュールデータを受信し、想定スケジュールデータを更新する（ステップＳ１３３）。この処理が終了した場合には、本サブルーチンを終了し、図３のステップＳ２００に移る。

図１３は、本発明の好適な実施形態の一例に係る希望スケジュールデータの作成処理を行うサブルーチンを示すフローの図である。以下、図１３から図１５に基づいて希望スケジュールデータ作成処理について説明する。

まず、ステップＳ２０１において、管理者用端末２の制御部２１は、通信部２２を介して希望スケジュールデータ入力受付開始指示信号を、サーバ１に送信する。そして、サーバ１の制御部１１は、通信部１２を介して希望スケジュールデータ入力受付開始指示信号を受信し、オペレータ端末４からの受付を開始する（ステップＳ２０３）。

ステップＳ２０５では、オペレータ端末４の制御部４１は、通信部４２を介して、想定スケジュールデータ送信要求信号を送信する。そして、サーバ１の制御部１１は、通信部１２を介して想定スケジュールデータ送信要求信号を受信する（ステップＳ２０７）と、想定スケジュールデータ及び週休データをスケジュールデータ記憶部１５から読み込み、通信部１２を介してオペレータ端末４に送信する（ステップＳ２０９）。

ステップＳ２１１では、サーバ１から想定スケジュールデータ及び週休データを受信したオペレータ端末４の制御部４１は、表示部４５に表示する。そして、オペレータは、これらのデータを見ながら入力部４４を介して希望スケジュールデータを検討する。具体的には、例えば、図１４のような週休希望日を設定する画面において行う。図１４では、日付ごとに週休取得可能人数や現在の申請者数が記載されており、これを参照しながらオペレータが週休希望日の入力ボックス１４１にチェック又は優先順位（後述）を入力していく。そして、この表示部４５に表示される画面は、少なくとも、他のオペレータが週休データをサーバ１に送信してサーバ１が受信する度に更新されてもよい。オペレータが図１４のような画面を参照することにより、これから週休希望日を入力するオペレータに対して、すでに申請者数が週休取得可能人数を超えている日又は申請者数と週休取得可能人数が同じ日を避けて週休希望日を申請するように促す効果がある。このように、オペレータは、他のオペレータの希望スケジュールデータの送信を随時反映した情報をオペレータ端末４の表示部４５の表示を見て確認することが可能である。更に、送信される週休データが刻々と変化していくので、常に最新の情報に基づいてオペレータ自身が希望を調整することができることになる。したがって、管理者による、申請者数が週休取得可能人数を超えていた場合の再調整をできる限り不要とし、管理者の負担を軽減しつつ、自然と労使協調関係を醸成する可能性が生まれることとなる。

ステップＳ２１５では、オペレータ端末４の制御部４１は、週休希望日の優先順位の入力を受け付ける。この入力は、図１４の画面において、優先順位をつけて週休申請することにより行ってよい。具体的には、例えば、週休申請の入力ボックス１４１に優先順位の番号の入力を受け付ける。優先順位が１番の場合は、入力ボックス１４１に「１」と入力し、優先順位が２番の場合は、入力ボックス１４１に「２」と入力するなどである。この優先順位に関する入力は、優先順位データとしてサーバ１に送信されることになる。尚、優先順位を設定しない場合は、入力ボックス１４１にチェックを入力するようにしてもよい。この処理が終了した場合には、ステップＳ２１７に処理を移す。

ステップＳ２１７では、オペレータ端末４の制御部４１は、これまでステップＳ２１３及びＳ２１５において受け付けた入力から、希望スケジュールデータを作成し優先順位データと共に通信部４２を介してサーバ１に送信する。なお、この送信は、管理者用端末２からの希望スケジュールデータ入力受付終了指示信号（詳細は後述）をサーバ１が受信するまでは、任意の回数を送信可能である。この送信回数はオペレータ毎に所定の回数であってもよいし、無制限であってもよい。この処理が終了した場合には、ステップＳ２１９に処理を移す。ここで、希望スケジュールデータを送信できる回数並びに各優先順位を送信できる回数は、管理者の入力を受け付けることにより、オペレータ毎に調整可能としてもよい。この場合、管理者は、各オペレータの過去の評価や勤務実績等を考慮してこれらのパラメータを調整することとなる。

ステップＳ２１９では、サーバ１の制御部１１は、オペレータ端末４から送信された希望スケジュールデータ及び優先順位データを受信する。そして、各オペレータ端末４から送信された希望スケジュールデータを、希望スケジュールデータテーブルに登録していく。例えば、図１５のような希望スケジュールデータテーブルを作成する。このテーブルでは、オペレータのＩＤとオペレータ名、及び週休希望日の第１希望と第２希望が登録される。なお、週休希望日の優先順位は、図１５では第２希望まで記載してあるが、この数に限られない。第３希望や第５希望等、これより多くしてもよいし、第１希望のみでもよい。あるいは第１希望が複数受付可能であってもよい。

この、希望スケジュールデータ及び優先順位データの受付は、管理者用端末２からの希望スケジュールデータ入力受付終了指示信号がサーバ１に送信される（ステップＳ２２１）まで、行われる。この希望スケジュールデータ入力受付終了指示信号の送信は、管理者用端末２において、管理者が送信指示を入力部２４から入力し、制御部２１が受け付けることにより送信してもよいし、予め所定の期間を定めておき、所定の期間経過後に自動的に希望スケジュールデータ入力の受付を終了するようにしてもよい。

ステップＳ２２３では、制御部１１は、管理者用端末２から希望スケジュールデータ入力受付終了指示信号を受信したか否かを判別する。希望スケジュールデータ入力受付終了指示信号を受信しない場合は、ステップＳ２０５もしくはステップＳ２０７に戻り、オペレータ端末４からの想定スケジュールデータ要求又は希望スケジュールデータ及び優先順位データの受付を継続する。希望スケジュールデータ入力受付終了指示信号を受信した場合は、これまで登録した希望スケジュールデータテーブルをスケジュールデータ記憶部１５に記憶する（ステップＳ２２５）。この処理が終了した場合には、本サブルーチンを終了し、図３のステップＳ３００に処理を移す。

図１６は、本発明の好適な実施形態の一例に係る仮決定スケジュールデータの作成処理を行うサブルーチンを示す図である。以下、図１６から図２０に基づいて想定スケジュールデータ作成処理を説明する。

まず、管理者用端末２の制御部２１は、仮決定スケジュールを設定するために、想定スケジュールデータ及び希望スケジュールデータ送信要求信号をサーバ１に対して通信部２２を介して送信する（ステップＳ３０１）。

ステップＳ３０３では、サーバ１の制御部１１は、管理者用端末２から送信された想定スケジュールデータ及び希望スケジュールデータ送信要求信号を、通信部１２を介して受信する。そして、想定スケジュールデータ及び希望スケジュールデータをスケジュールデータ記憶部１５から読み込み、管理者用端末２に対して通信部１２を介し、送信する（ステップＳ３０５）。

ステップＳ３０７では、管理者用端末２の制御部２１は、サーバ１から送信された想定スケジュールデータ及び希望スケジュールデータを受信し、表示部２５に表示する。例えば、図１７又は図１８のような画面が仮決定スケジュール作成画面として表示される。

図１７は、管理者が週休取得可能人数や現在の申請者数と共に、週休を申請したオペレータが表示され、週休取得の許可を行う画面を示している。この画面には、ステップＳ３０７で受信した希望スケジュールデータテーブルの情報をもとに、週休取得可能人数や現在の申請者数と共に、週休を申請したオペレータ名等が表示されている。そして、管理者による選択チェックボックスの入力を受け付けることによって、週休取得の許可の設定を行う（ステップＳ３０９）。

図１８は、グラフ１８０、想定されるオペレータの必要人数１８１、及びオペレータの必要人数に対する勤務可能なオペレータの配置人数１８２、オペレータの配置人数に効率を掛けた配置人数＊効率１８３、及び過不足人数＊効率１８４が表示されている。配置人数＊効率１８３及び過不足人数＊効率１８４は、オペレータの処理効率１８６から算出した作業量／時間の値である。ここで、想定されるオペレータの必要人数に達しない時間帯については、過不足人数＊効率１８４欄においてマイナス表示され、オペレータ数が不足していることを示している。同時に帯グラフ１８８においてマイナス表示されている。

そして、下の表１８５には、勤務可能なオペレータ及び各オペレータの作業の処理効率１８６が表示され、管理者はどのオペレータを実際に採用するかを決定し、入力する。入力は、例えば、採用したいオペレータが記載されている行のチェックボックス１８７にチェックを入力することにより行う（ステップＳ３０９）。なお、管理者がチェックボックス１８７にチェックを入力する度にグラフ１８０や配置人数１８２、配置人数＊効率１８３、及び過不足人数＊効率１８４等が変化していくようにしてもよい。そして、必要人数を満たすだけの配置人数＊効率となるようにオペレータを採用していく。例えば、平均的なオペレータの処理効率を１００とするときに、３００の処理が必要な業務があった場合、処理効率１００のオペレータであれば３人必要であるが、１５０のオペレータがいれば２人で済むことになる。また、逆に新人等の業務に不慣れであるため、処理効率が５０の者が２人含まれていた場合は、処理効率１００のオペレータが２人と処理効率５０の者が２人の計４人必要となる。このように、オペレータの処理効率を考慮することにより、必要な作業量を満たす分の要員をスケジュールすることが可能となるので、単に人数だけでスケジュールするよりも作業量において過不足の無い要員のアサインをすることができる。

また、帯グラフ１８８は、各オペレータの設定済みスケジュールを示している。この帯グラフ１８８では、業務種別ごとに色分けされ、現在どのような業務がどのくらいの人数に割り当てられているかを確認できるようにしてもよい。これにより、例えば、即時性の低い資料作成やＷｅｂ応答の業務が割り当てられているオペレータに対して、コール量が多いときにはコール対応も可能な要員として割り当てる等のフレキシブルなスケジュール管理を行うことが可能となる。

このように、管理者はこれらの画面を使用して仮決定スケジュールを作成していく。この処理が終了した場合には、ステップＳ３１１に処理を移す。尚、採用する要員の上限は、例えば、座席数等のような同時に業務をすることのできる最大数であってよい。要員の上限は、グラフ１８０内の上限線１８９で示される。このように、例えば、グラフ１８０内の上限線１８９で示される最大数を超えた人数を表１８５において採用することはできない設定を行うことができる。チェックボックス１８７に最大数を超えるチェックを入力使用とした場合には、サーバ１の制御部１１は、入力不可の旨のメッセージを管理者用端末２に送信して、管理者用端末２の制御部２１が表示部２５に受信したメッセージを表示するようにしてもよい。または、サーバ１の制御部１１がチェックの入力を受け付けないようにしてもよい。もし、上限線１８９を超える必要人数が想定されている場合は、同時に業務をすることのできるオペレータの最大数が業務に対して不足していることを示す。

これにより、管理者にとっては、現在の例えば座席数が業務に対して適当であるかを判断する材料となる。例えば、必要人数が上限線１８９をはるかに超えるようであれば、座席数の増設が必要であることを示し、必要人数が上限線１８９を常に下回るようであれば、座席数が多すぎることを示すことになる。

ステップＳ３１１では、管理者用端末２の制御部２１は、ステップＳ３０９において作成した仮決定スケジュールデータをサーバ１に対して、通信部２２を介して送信する。この送信される仮決定スケジュールデータは、例えば、図１９のようなテーブルである。この仮決定スケジュールデータテーブルは、ある日のある時間帯における必要人数、配置人数、配置人数＊効率、及び過不足人数＊効率の人数を示している。例えば、８月１日の９時００分から１０時００分の間において、オペレータの必要人数は２６．５人であり、現在の配置人数は１９．７５人であり、配置人数＊効率は、１９．９５人、過不足人数＊効率はマイナス６．７５人である。このように、この仮決定スケジュールデータは、仮決定した要員（オペレータ）の配置人数と、配置人数から必要人数を減算した、必要人数の過不足の人数の情報を持つ。さらに、日付及び／又は時間帯による現在のオペレータ数や過不足数等を示す。なお、図１９では、時間単位が１時間単位でテーブルが作成されているが、これに限られない。例えば、１０分等のように、短い時間の単位でもよく、２時間等のように長い時間単位でもよい。また、オペレータの最大数が設定されており、必要人数がオペレータの最大数を超えている場合には、過不足人数＊効率の値は、配置人数＊効率からオペレータの最大数を減算した値となる。これは、実際には、オペレータの最大数を超えて配置することができないからである。これにより、実質的に不足する配置可能な人数＊効率を示すことができる。

ステップＳ３１３では、サーバ１の制御部１１は、通信部１２を介して仮決定スケジュールデータを受信する。そして、受信した仮決定スケジュールデータをスケジュールデータ記憶部１５に記憶する（ステップＳ３１５）。

更に、オペレータ端末４からの送信要求（ステップＳ３１６）に応じて、送信要求を受信（ステップＳ３１７）したサーバ１の制御部１１は、通信部１２を介して、仮決定スケジュールデータをオペレータ端末４に送信する（ステップＳ３１８）。なお、この送信は、メールサーバを介して自動的にオペレータの携帯端末６ａ、６ｂに送信してもよい。

ステップＳ３１９では、サーバ１から送信された仮決定スケジュールデータを、オペレータ端末４の制御部４１が通信部４２を介して受信し、表示部４５に表示する。また、同時に記憶部４３に記憶してもよい。表示部４５に表示する仮決定スケジュールデータは、例えば、図２０のような画面となる。この画面は、日にちごとに勤務時間や週休日が表示された表である。図２０では、週表示となっているが、月単位でもよく、一日のスケジュールで表示してもよい。この処理が終了した場合には、本サブルーチンを終了する。

以上、本発明の実施形態を説明したが、具体例を例示したに過ぎず、特に本発明を限定しない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施形態に記載された効果に限定されない。

本発明の実施形態の一例に係るコンピュータシステムの全体構成を示す概念図である。 本発明の実施形態の一例に係るコンピュータシステムの構成を示すブロック図である。 本発明の実施形態の一例に係るメインフローを示す図である。 本発明の実施形態の一例に係る想定スケジュールデータ作成処理のフローを示す図である。 本発明の実施形態の一例に係るコール量統計データの表示例である。 本発明の実施形態の一例に係る予測コール量の表示例である。 本発明の実施形態の一例に係る単位時間当たりの想定されるオペレータの必要人数を示す画面の表示例である。 本発明の実施形態の一例に係る週休データテーブルを示す図である。 本発明の実施形態の一例に係る週休禁止日設定の表示例である。 本発明の実施形態の一例に係る週休取得可能人数の表示例である。 本発明の実施形態の一例に係る想定スケジュールデータテーブルを示す図である。 本発明の実施形態の一例に係る単位時間及び業務の種類ごとに想定されるオペレータの必要人数を示す画面の表示例である。 本発明の実施形態の一例に係る希望スケジュールデータ作成処理を示すフローである。 本発明の実施形態の一例に係る週休取得申請入力画面の表示例である。 本発明の実施形態の一例に係る希望スケジュールデータテーブルを示す図である。 本発明の実施形態の一例に係る仮決定スケジュールデータ作成処理を示すフローである。 本発明の実施形態の一例に係る週休取得申請の承認入力画面の表示例である。 本発明の実施形態の一例に係る仮決定スケジュール作成画面の表示例である。 本発明の実施形態の一例に係る仮決定スケジュールデータテーブルを示す図である。 本発明の実施形態の一例に係る仮決定通知画面の表示例である。

符号の説明

１ サーバ
２ 管理者用端末
３ 内部通信ネットワーク
４ オペレータ端末
５ 外部通信ネットワーク
６ａ、６ｂ 携帯端末
１２ 通信部
１３ 記憶部
１４ 統計データ記憶部
１５ スケジュールデータ記憶部
１６ 入力部
１７ 表示部
２１ 制御部
２２ 通信部
２３ 記憶部
２４ 入力部
２５ 表示部
４１ 制御部
４２ 通信部
４３ 記憶部
４４ 入力部
４５ 表示部

Claims (8)

1. サーバ、管理者端末、及び要員端末が通信ネットワークを介して接続され、前記管理者端末で複数の要員の勤務スケジュールを管理する方法であって、
   前記サーバが、
   事業所における作業量に関する作業量統計データに応じて、前記複数の要員に関する勤務の想定スケジュールを表す想定スケジュールデータを生成して記憶部に記憶する想定スケジュールデータ生成ステップと、
   所定期間を指定して前記要員端末から要員毎にその勤務の希望スケジュールを表す希望スケジュールデータの受け付けを開始する希望スケジュールデータ受け付け開始ステップと、
   前記所定期間が経過するまで、要員毎の前記希望スケジュールデータを前記要員端末から受信して記憶部に記憶する希望スケジュールデータ受信ステップと、
   前記所定期間が経過するまで、前記要員端末からの要求に応じて、前記想定スケジュールデータ、及び記憶した前記希望スケジュールデータの集計データを前記要員端末に送信する想定スケジュールデータ送信ステップと、を行い、
   前記管理者端末が、前記所定期間の経過後、前記サーバから前記想定スケジュールデータと前記希望スケジュールデータとを受けて前記想定スケジュールデータと前記希望スケジュールデータとに基づいて要員毎の勤務に係る仮決定スケジュールを表す仮決定スケジュールデータを生成する仮決定スケジュールデータ生成ステップを行い、
   前記想定スケジュールデータは、日毎の週休取得可能な人数を示す週休データを含み、
   前記希望スケジュールデータは、要員毎の希望週休取得日を示す方法。
2. 前記想定スケジュールデータ生成ステップで、前記想定スケジュールに関するピーク情報を表すピークデータを更に生成し、
   前記想定スケジュールデータ送信ステップで、生成した前記ピークデータをあわせて前記要員端末に送信する請求項１に記載の方法。
3. 前記希望スケジュールデータ受信ステップで、前記サーバは前記希望スケジュールの優先順位を表す優先順位データを受信し、
   前記仮決定スケジュールデータ生成ステップで、前記管理者端末は、前記サーバから前記優先順位データを受けて、前記想定スケジュールデータと、前記希望スケジュールデータと、前記優先順位データとに基づいて仮決定スケジュールデータを生成する請求項１又は２に記載の方法。
4. 前記希望スケジュールデータ受信ステップで、前記サーバは前記要員端末から所定の回数のみ前記希望スケジュールデータを受信する請求項１から３のいずれかに記載の方法。
5. 前記仮決定スケジュールデータ生成ステップで、前記管理者端末は前記複数の要員の数が、あらかじめ指定された最大数を超えない範囲で、前記仮決定スケジュールデータを生成する請求項１から４のいずれかに記載の方法。
6. 前記仮決定スケジュールデータ生成ステップで、前記管理者端末は前記複数の要員の所定の作業に対する処理効率データに基づいて、前記仮決定スケジュールデータを生成する請求項１から５のいずれかに記載の方法。
7. 前記仮決定スケジュールデータ生成ステップで、前記複数の要員のうち所定の要員について重複した複数の仮決定スケジュールを生成する請求項１から６のいずれかに記載の方法。
8. サーバ、管理者端末、及び要員端末が通信ネットワークを介して接続され、前記管理者端末で複数の要員の勤務スケジュールを管理する際に用いられるプログラムであって、
   前記サーバが備えるコンピュータに、
   事業所における作業量に関する作業量統計データに応じて、前記複数の要員に関する勤務の想定スケジュールを表す想定スケジュールデータを生成して記憶部に記憶する想定スケジュールデータ生成ステップと、
   所定期間を指定して前記要員端末から要員毎にその勤務の希望スケジュールを表す希望スケジュールデータの受け付けを開始する希望スケジュールデータ受け付け開始ステップと、
   前記所定期間が経過するまで、要員毎の前記希望スケジュールデータを前記要員端末から受信して記憶部に記憶する希望スケジュールデータ受信ステップと、
   前記所定期間が経過するまで、前記要員端末からの要求に応じて、前記想定スケジュールデータ、及び記憶した前記希望スケジュールデータの集計データを前記要員端末に送信する想定スケジュールデータ送信ステップと、を実行させ、
   前記管理者端末が備えるコンピュータに、前記所定期間の経過後、前記サーバから前記想定スケジュールデータと前記希望スケジュールデータとを受けて前記想定スケジュールデータと前記希望スケジュールデータとに基づいて要員毎の勤務に係る仮決定スケジュールを表す仮決定スケジュールデータを生成する仮決定スケジュールデータ生成ステップを実行させ、
   前記想定スケジュールデータは、日毎の週休取得可能な人数を示す週休データを含み、
   前記希望スケジュールデータは、要員毎の希望週休取得日を示すプログラム。

Images