JP5184745B2 - 不足要員を補充する方法及び当該方法を実現するコンピュータ及びプログラム - Google Patents

Description

本発明は、不足要員を補充する方法及び当該方法を実現するコンピュータ及びプログラムに関する。特に、勤務スケジュール上の不足要員を補充する方法及び当該方法を実現するコンピュータ及びプログラムに関する。

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

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

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

しかしながら、このようなシステムにおいては、当該勤務スケジュールの管理者は、当該募集を行うにあたって、いつ、どのようなスキルの募集対象のオペレータが不足しているかについて正確に知ることはできない。そのため、当該管理者は、当該希望を反映した勤務スケジュールの確定後、不足募集対象のオペレータの募集を正確に行うことができない。

本発明は、上述のような課題を解決するために、不足する要員を的確に補充する事が可能なスケジュール管理コンピュータを提供することを目的とする。具体的には次のようなものを提供する。

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

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

このことにより、当該管理者は、表示された不足スケジュールを見て募集計画を検討することができる。

（２） 前記コンピュータが、前記不足スケジュールデータと前記複数の要員の属性を表す要員属性データ（例えば、後述のオペレータスキルデータなど）とに基づいて募集連絡を行う要員を表す募集連絡データ（例えば、後述の募集連絡データなど）を生成する募集連絡データ生成ステップ（例えば、後述のステップＳ１１５など）をさらに含む（１）に記載の方法。

（２）の発明によれば、当該コンピュータは、当該不足スケジュールデータと当該複数の要員の属性を表す要員属性データとに基づいて募集連絡を行う要員を表す募集連絡データを生成する。

このことにより、当該管理者は、当該募集連絡データに基づいて、募集連絡を行うことができる。

（３） 前記コンピュータが、前記通信ネットワークを介して、前記要員の公開されている連絡先のみに対して、前記募集連絡データを送信可能とする募集連絡データ送信可能化ステップをさらに含む（２）に記載の方法。

（３）の発明によれば、当該コンピュータは、前記通信ネットワークを介して、公開されている連絡先のみに対して募集連絡データを送信可能とする。

このことにより、要員が非公開としている連絡先に募集連絡データが送信されないので、要員が非公開としたい連絡先に募集連絡データが送信されることを防止することが可能となる。その結果、コールセンター等において登録している要員（募集対象のオペレータ）は、会社には開示しても、管理担当者には開示したくない個人情報にアクセスされることなく募集連絡を受けることが可能となる。このようにして、要員（募集対象のオペレータ）のプライバシーに配慮しつつ迅速な募集プロセスを実現できる可能性がある。

（４） 前記コンピュータが、前記通信ネットワークを介して、前記募集連絡を行った要員（募集対象のオペレータ）からの応募データ（例えば、後述の応募データなど）を受信したこと（例えば、後述のステップＳ１２７など）に応じて、前記応募データの記憶を行う応募データ記憶ステップ（例えば、後述のステップＳ２０７など）をさらに含む（２）又は（３）に記載の方法。

（４）の発明によれば、当該コンピュータは、前記通信ネットワークを介して、前記募集連絡を行った要員からの応募データを受信したことに応じて、当該応募データの記憶を行う。

このことにより、当該コンピュータは、応募のあった要員からの応募データを自動的に受け付けて集計することができる。

（５） 前記コンピュータが、前記募集連絡を行った要員からの応募データを記憶したことに応じて、採用要員を表す採用データ（例えば、後述の採用データなど）を生成する採用データ生成ステップ（例えば、後述のステップＳ２０７など）をさらに含む（４）に記載の方法。

（５）の発明によれば、当該コンピュータは、当該通信ネットワークを介して、当該募集連絡を行った要員からの応募データを記憶したことに応じて、採用要員を表す採用データを生成する。

このことにより、応募データの受信に応じて自動的に採用要員を決定することができる。

（６）前記コンピュータが、前記端末が前記募集連絡を行った要員による閲覧を受け付けたことを表す閲覧確認データを前記端末から受信（例えば、後述のステップＳ１１９）したことに応じて、前記閲覧確認データを記憶（例えば、後述のステップＳ１１９）する、閲覧確認データ記憶ステップをさらに含む、（４）に記載の方法。

（６）の発明によれば、当該コンピュータは、募集連絡を受信した端末から、端末において当該募集連絡を閲覧したことを表す閲覧確認データを受信したことに応じて、当該閲覧確認データを記憶する。

このことにより、当該コンピュータにおいて、募集連絡を行った要員の端末における、募集連絡の閲覧状況の自動集計が可能となる。

（７） 前記コンピュータが、管理者の要求を受け付けた（例えば、後述のステップＳ３０９）ことに応じて、記憶した前記応募データと、記憶した前記閲覧確認データと、を表示する（例えば、後述のステップＳ３１３）、応募・閲覧状況表示ステップをさらに含む、（６）に記載の方法。

（７）の発明によれば、当該コンピュータは、管理者の要求を受け付けたことに応じて、記憶した応募データと、閲覧確認データと、を表示することができる。

このことにより、募集連絡を送信した要員が当該募集連絡を閲覧したか否かを管理者が把握することができ、再度募集をする際に応募意思が無い可能性の高い、閲覧済みの要員への再連絡を避けつつ、応募意思がある可能性のある、閲覧をしていない要員に対して効果的、効率的に連絡をすることを容易にすることができる。

（８） 前記管理者の要求を受け付けたことに応じて、前記想定スケジュールデータと、前記希望スケジュールデータと、前記想定スケジュールデータと前記希望スケジュールデータとに基づいて前記複数の要員の仮決定スケジュールデータを表す仮決定スケジュールデータ（例えば、図１１の仮決定スケジュールデータテーブル）と、に基づいて、スケジュールの作成状況を表すスケジュール作成状況データの表示（例えば、図２６）を行うスケジュール作成状況表示ステップをさらに含む（７）に記載の方法。

（８）の発明によれば、管理者が要求した際に想定スケジュールデータと、希望スケジュールデータと、仮決定スケジュールデータと、に基づいて、スケジュールの作成状況を表すスケジュール作成状況データを表示することが可能となる。

このことにより、管理者が要求した際のスケジュール作成状況を確認することができるので、例えば、管理者が要員に対して再募集を行ったりする際に、業務の割り当ての無い要員等を確認して、募集をかける等、的確な要員の補充をすることが可能となる。

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

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

（１０） 前記コンピュータに、前記不足スケジュールデータと前記複数の要員の属性を表す要員属性データ（例えば、後述のオペレータスキルデータなど）とに基づいて募集連絡を行う要員を表す募集連絡データ（例えば、後述の募集連絡データなど）を生成させる募集連絡データ生成ステップ（例えば、後述のステップＳ１１５など）をさらに実行させる（９）に記載のプログラム。

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

（１１） 前記コンピュータに、前記通信ネットワークを介して、前記要員の公開されている連絡先のみに対して、前記募集連絡データを送信可能とさせる募集連絡データ送信可能化ステップをさらに実行させる（１０）に記載のプログラム。

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

（１２） 前記コンピュータに、前記通信ネットワークを介して、前記募集連絡を行った要員からの応募データ（例えば、後述の応募データなど）を受信したこと（例えば、後述のステップＳ１２７など）に応じて、前記応募データの記憶を実行させる応募データ記憶ステップ（例えば、後述のステップＳ１３７など）をさらに含む（１０）又は（１１）に記載のプログラム。

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

（１３） 前記コンピュータに、前記通信ネットワークを介して、前記募集連絡を行った要員からの応募データを記憶したことに応じて、採用要員を表す採用データ（例えば、後述の採用データなど）を生成させる採用データ生成ステップ（例えば、後述のステップＳ２０７など）をさらに実行させる（１０）又は（１１）に記載のプログラム。

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

（１４）前記コンピュータに、前記端末が前記募集連絡を行った要員による閲覧を受け付けたことを表す閲覧確認データを前記端末から受信（例えば、後述のステップＳ１１９）したことに応じて、前記閲覧確認データを記憶（例えば、後述のステップＳ１１９）させる、閲覧確認データ記憶ステップをさらに実行させる、（１２）に記載のプログラム。

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

（１５） 前記コンピュータに、管理者の要求を受け付けた（例えば、後述のステップＳ３０９）ことに応じて、記憶した前記応募データと、記憶した前記閲覧確認データを表示させる（例えば、後述のステップＳ３１３）、応募・閲覧状況表示ステップをさらに実行させる、（１４）に記載のプログラム。

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

（１６） 前記コンピュータに、前記通信ネットワークを介して、前記管理者の要求を受け付けたことに応じて、前記想定スケジュールデータと、前記希望スケジュールデータと、前記想定スケジュールデータと前記希望スケジュールデータとに基づいて前記複数の要員の仮決定スケジュールデータを表す仮決定スケジュールデータ（例えば、図１１の仮決定スケジュールデータテーブル）と、に基づいて、スケジュールの作成状況を表すスケジュール作成状況データの表示を行わせる（例えば、図２６）、スケジュール作成状況データ表示ステップをさらに実行させる、（１５）に記載のプログラム。

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

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

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

本発明によれば、当該コンピュータは、当該想定スケジュールデータと当該希望スケジュールデータとに基づいて当該複数の要員の不足スケジュールを表す不足スケジュールデータを生成して表示することにより、管理者は的確に募集連絡を行うことができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ステップＳ１００は、募集連絡データ作成処理を行う。この処理においては、例えば、管理者用端末２から募集連絡データ作成要求を受信したサーバ１は、仮決定スケジュールデータから不足する人数の情報を得て、要求スキルデータ及びオペレータスキルデータに基づいて募集する対象者を決定する。そして、対象者への募集連絡データを作成し、募集対象のオペレータに募集連絡データを送信する。さらに、サーバ１は、オペレータ端末４から送信された応募データを受信し、記憶する。これらの処理の詳細については後述する。この処理が終了した場合には、ステップＳ２００に処理を移す。

ステップＳ２００は、採用決定・採用通知データ作成処理を行う。この処理においては、例えば、サーバ１は、オペレータ端末４から受信した応募データ及び募集連絡データに基づいて採用する募集対象のオペレータを決定し、採用データを作成し、採用データに基づいて採用通知データを作成し、オペレータ端末４に送信する。これらの処理については後述する。この処理が終了した場合には、メインフローを終了する。

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

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

ステップＳ２５では、サーバ１の制御部１１は、当該想定スケジュールデータ作成要求信号の受信に応じて、想定スケジュールデータを作成する。具体的には、例えば、コール量統計データを統計データ記憶部１４から読み込んで、予測コール量を算出し、予測コール量から想定される募集対象のオペレータの必要人数を算出して行ってもよい。コール量統計データとは、例えば、過去のある日付のコール量の記録を時間帯ごとに示したものである。この、サーバ１が読み込むコール量統計データは、ステップＳ２１の想定スケジュールデータ作成要求を送信する際に管理者が指定してもよいし、又は、直近の日付や直近の過去の同じ曜日のコール量統計データをサーバ１が自動的に選択して読み込んでもよい。この処理が終了した場合には、ステップＳ２７に処理を移す。

この想定スケジュールデータは、例えば、図５のようなテーブルで表される。図５の想定スケジュールデータテーブルは、ある日についての時間帯ごとに想定される募集対象のオペレータの必要人数を示したテーブルである。図５では、例えば、８月１日の９時において、募集対象のオペレータの必要人数は２６．５人であることを示している。

ステップＳ２７では、制御部１１は、想定スケジュールデータを記憶部１３のスケジュールデータ記憶部１５に記憶する。この処理が終了した場合には、本サブルーチンを終了し、図３のステップＳ６０に移る。

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

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

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

ステップＳ６６では、オペレータ端末４の制御部４１は、サーバ１から想定スケジュールデータを受信し、表示部４５に表示する。そして、募集対象のオペレータは、これらのデータを見ながら入力部４４を介して希望スケジュールデータを検討する。具体的には、例えば、図１４のような週休の希望を設定する画面において行う。図７では、日付ごとに週休取得可能人数や現在の申請者数が記載されており、これを参照しながら募集対象のオペレータが週休希望を入力していく。そして、この表示部４５に表示される画面は、少なくとも、他の募集対象のオペレータが週休可能データをサーバ１に送信し、サーバ１が受信する度に更新されてもよい。そして、オペレータ端末４の制御部４１は、募集対象のオペレータによる希望スケジュールの入力を受け付ける（ステップＳ６７）。

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

ステップＳ６９では、サーバ１の制御部１１は、オペレータ端末４から送信された希望スケジュールデータを受信する。そして、各オペレータ端末４から送信された希望スケジュールデータを、希望スケジュールデータテーブルに登録していく。例えば、図８のような希望スケジュールデータテーブルを作成する。このテーブルでは、募集対象のオペレータのＩＤとオペレータ名、及び週休希望日が登録される。

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

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

ステップＳ７３では、制御部１１は、仮決定スケジュールデータを作成する。具体的には、例えば、制御部１１は、管理者用端末２からの要求に応じて、希望スケジュールデータテーブルを管理者用端末２に送信し、図９や図１０のような画面を表示部２５に表示させるようにしてもよい。このような場合は、例えば、制御部２１は、管理者用端末２の表示部２５に図９のような画面を表示する。図９の画面には、ステップＳ７２でサーバ１の制御部１１が記憶した希望スケジュールデータテーブルの情報をもとに、週休取得可能人数や現在の申請者数と共に、週休を申請したオペレータ名等が表示されている。そして、制御部２１は、管理者による選択チェックボックスの入力を受け付けることによって、週休取得の許可の設定を行ってもよい。

さらに、制御部２１は、受信した希望スケジュールデータテーブルに基づいて、図１０のような画面を表示して、管理者による採用する募集対象のオペレータの決定の入力を受け付ける。この画面は、グラフ１８０、オペレータを配置できる最大人数を示す線１８９、想定される募集対象のオペレータの必要人数１８１、及び募集対象のオペレータの必要人数に対する勤務可能な募集対象のオペレータの配置人数１８２、募集対象のオペレータの配置人数に効率を掛けた配置人数＊効率１８３、及び過不足人数＊効率１８４が表示されている。配置人数＊効率１８３及び過不足人数＊効率１８４は、募集対象のオペレータの処理効率１８６から算出した作業量／時間の値である。ここで、想定される募集対象のオペレータの必要人数に達しない時間帯については、過不足人数＊効率１８４欄においてマイナス表示され、募集対象のオペレータ数が不足していることを示している。同時に帯グラフ１８８においてマイナス表示されている。また、過不足人数＊効率１８４欄においては、オペレータを配置できる最大人数から不足する数を表示してもよい。例えば、最大人数が座席数であるとすると、現在の必要人数に対して座席数が足りているか否かについても管理者が把握することができる。

そして、下の表１８５では、勤務可能な募集対象のオペレータ１８５及び各募集対象のオペレータの作業の処理効率１８６が表示されている。そして、管理者用端末２の制御部２１は、採用する募集対象のオペレータについての管理者による入力を受け付ける。入力の受付は、例えば、採用したい募集対象のオペレータが記載されている行のチェックボックス１８７に、入力部２４を使用してチェックが入力されるのを受け付けることにより行う（ステップＳ７３）。なお、管理者によるチェックボックス１８７にチェックの入力を受け付けることに応じて、グラフ１８０や配置人数１８２、配置人数＊効率１８３、及び過不足人数＊効率１８４等の値が変化していくようにしてもよい。そして、管理者は、必要人数を満たすだけの配置人数＊効率となるように募集対象のオペレータを採用していくこととなる。

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

このように、管理者はこれらの画面を使用して仮決定スケジュールを作成していく。この処理が終了した場合には、ステップＳ７４に処理を移す。

尚、仮決定スケジュールデータテーブル（図１１）は、ある日のある時間帯における必要人数、稼働率、仮決定人数及び過不足数を示している。例えば、１１月１日の９時００分から１０時００分の間において、募集対象のオペレータの必要人数は２６．５人であり、現在の配置人数は１９．７５人であり、過不足数はマイナス６．７５人である。このように、仮決定スケジュールデータは、仮決定した要員（募集対象のオペレータ）の配置人数を含み、必要人数の差分である過不足の人数も含み、日付及び／又は時間帯による募集対象のオペレータの配置人数や過不足数等を示す。また、この過不足数は、募集対象のオペレータの処理効率から算出されてもよい。

サーバ１の制御部１１は、このようにステップＳ７３において生成された仮決定スケジュールデータ（図１１）を、スケジュールデータ記憶部１５に記憶する（ステップＳ７４）ようにしてもよい。この処理が終了した場合には、本サブルーチンを終了し、図３のステップＳ１００に処理を移す。

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

まず、管理者用端末２の制御部２１は、通信部２２を介して、募集連絡データ作成処理要求信号をサーバ１に送信（ステップＳ１０１）し、サーバ１の制御部１１は、募集連絡データ作成処理要求信号を受信し（ステップＳ１０３）、仮決定スケジュールデータをスケジュールデータ記憶部１５から読み込む（ステップＳ１０５）。

ステップＳ１０７では、サーバ１の制御部１１は、さらに募集をしているスケジュールに係る業務の要求スキルデータを読み込み、在籍する募集対象のオペレータのオペレータスキルデータ（ステップＳ１０９）をさらに読み込む。この要求スキルデータとは、例えば、図１４にあるようなテーブルである。このテーブルには、スケジュール毎に要求するスキルが対応付けられている。例えば、スケジュールＡについて、要求されるスキルは、「サーバ対応スキル」及び「英語対応スキル」であり、スケジュールＢについては特に無く、スケジュールＣについては、「中国語対応スキル」が要求される。

また、オペレータスキルデータは、例えば、図１５のようなテーブルで示される。図１５のテーブルでは、募集対象のオペレータの組織名、氏名、ＩＤ，雇用タイプ、保有スキルが記載されている。尚、募集対象のオペレータは上記の個人情報の他、連絡先として、個人のメールアドレスや電話番号等を登録しておくことが可能である。そして、募集連絡データ等の送付先をこれらの個人のメールアドレス等に指定することができる。また、逆にこれらの個人情報を管理者等に非公開とすることも可能である。具体的には、例えば、図１６のように、連絡先等の個人情報を登録しておき、これらの情報の公開又は非公開について、チェックボックス９０へのチェックの有無により選択する。

ステップＳ１１１では、制御部１１は、要求スキルデータ及びオペレータスキルデータに基づいて、募集対象のオペレータを決定する。この決定は、例えば、オペレータスキルデータが持つ募集対象のオペレータのスキル情報と要求スキルデータとを比較して、要求スキルを満たすオペレータを募集対象のオペレータとしてもよい。また、これらの情報を管理者用端末２に送信して表示し、管理者用端末２において管理者が募集対象のオペレータを指定することにより、決定し、当該決定したデータをサーバ１に送信するようにしてもよい。この処理が終了した場合には、ステップＳ１１３に処理を移す。

ステップＳ１１３では、制御部１１は、募集対象者データを記憶部１３のスケジュールデータ記憶部１５に記憶し、ステップＳ１１５に移る。

ステップＳ１１５では、制御部１１は、募集対象のオペレータへの募集連絡データを作成する。次に、ステップＳ１１６では、制御部１１は、募集対象のオペレータへ募集連絡がある旨を示すメールを通信部１２を介して送信し、ステップＳ１１７へ移る。ステップＳ１１７では、オペレータ端末４の制御部４１は、サーバ１からのメールを、通信部４２を介して受信し、表示部４５に表示する。そして、制御部４１は、当該募集対象のオペレータが当該メールを閲覧して、当該オペレータによる募集連絡データの送信の要求を受け付けたことに応じて、募集連絡データの送信要求信号を送信する（ステップＳ１１８）。

具体的には、例えば、以下のような方法がある。第１の方法として、図１７のように、内部通信ネットワーク３内において、Ｗｅｂ上で閲覧するメールで募集連絡データが送信された場合には、Ｗｅｂサーバを介して送信した募集連絡データのメールを、オペレータ端末４の制御部４１が表示部４５に表示した際に、確認済みボタン２２１を表示するようにしておく。そして、制御部４１が、募集対象のオペレータによる入力部４４を介して確認済みボタン２２１への押下を受け付けることにより、閲覧したことを示す閲覧データをＷｅｂサーバからサーバ１へ送信する。また、制御部４１が応募ボタン２２２への押下を受け付けた場合にも、閲覧データを同様にＷｅｂサーバからサーバ１へ送信する。

また、第２の方法として、外部へのメールサーバから外部通信ネットワーク５を通じて、募集対象のオペレータの携帯端末６ａ、６ｂに募集連絡データを送信した場合には、携帯端末６ａ、６ｂの表示部に図１８のような画面が表示される。例えば、まず、案件募集のお知らせ画面２３０が表示され、お知らせ画面２３０内に所定のＵＲＬ２３１が記載されている。そして、募集対象のオペレータによるＵＲＬ２３１の選択を携帯端末６ａ、６ｂの制御部４１が受け付けると、外部通信ネットワーク５を介してＷｅｂサーバがログイン画面２３２を送信する。さらに携帯端末６ａ、６ｂが、募集対象のオペレータによるＩＤとパスワードの入力を受け付けてＷｅｂサーバにログインすると、Ｗｅｂサーバは、応募画面２３３を携帯端末６ａ、６ｂに送信する。このことにより、当該募集対象のオペレータは、募集連絡データを閲覧したことになるので、Ｗｅｂサーバは、応募画面２３３を携帯端末６ａ、６ｂに送信すると共にサーバ１に閲覧データを送信する。また、さらに応募画面２３３を受信した携帯端末６ａ、６ｂの制御部４１は、表示部４５に応募画面２３３を表示すると共に、この応募画面２３３に、応募ボタン２３４を表示する。そして、この応募ボタン２３４への募集対象のオペレータによる選択を受け付けた場合に、携帯端末６ａ、６ｂの制御部４１が外部通信ネットワーク５からＷｅｂサーバを介して応募データをサーバ１に送信するようにしてもよい。そしてさらに、応募データを受信したサーバ１は、応募完了の旨をＷｅｂサーバを介して外部通信ネットワーク５を介して携帯端末６ａ、６ｂに送信し、携帯端末６ａ、６ｂの制御部４１は表示部４５に応募完了画面２３５を表示するようにしてもよい。

サーバ１の制御部１１は、閲覧データ及び募集連絡送信要求信号を受信（ステップＳ１１９）する。この処理が終了した場合には、ステップＳ１２１に移る。

ステップＳ１２１では、オペレータ端末４の制御部４１からの要求（ステップＳ１１８）に応じて、サーバ１の制御部１１は、当該募集連絡データを送信する。そして、オペレータ端末４の制御部４１は、通信部４２を介して募集連絡データを受信し、表示部４５に表示する（ステップＳ１２３）。尚、この募集連絡データの送信処理は、決定により、メールサーバから外部通信ネットワーク５を介して募集対象のオペレータの携帯端末６ａ、６ｂに自動的に送信してもよい。そして、制御部４１は、募集連絡データに対する返答として、募集対象のオペレータによる応募データの入力操作を受け付け（ステップＳ１２５、図１３）、記憶部４３に記憶（ステップＳ１２７）する。そして、管理者用端末２の制御部２１は、サーバ１が募集連絡データを送信した後、サーバ１に対し、応募データ受付開始指示信号を送信する（ステップＳ１２９）。サーバ１の制御部１１は、応募データ受付開始指示信号を受信し、応募データの受付を開始する（ステップＳ１３１）。

オペレータ端末４の制御部４１は、通信部４２を介してサーバ１に応募データを送信する（ステップＳ１３３）。尚、この応募データには、応募するという旨だけでなく、募集に対して参加しないという旨の応答も含んでよい。この処理が終了した場合には、ステップＳ１３５に移る。

ステップＳ１３５では、サーバ１の制御部１１は、通信部１２を介してオペレータ端末４が送信する応募データを受信する。そして、スケジュールデータ記憶部１５に記憶する（ステップＳ１３７）。この受信は、管理者用端末２から応募データ受付終了指示信号が送信（ステップＳ１３９）されるまで継続される。又は、所定の期間を設定しておき、受信開始から所定の期間経過後に自動的に受信を終了してもよい。

尚、応募データの受付開始から応募データ入力受付終了指示信号受信までの間に、管理者用端末２からの要求（ステップＳ１３８）により、応募データの受付の途中経過を示すデータをサーバ１の制御部１１が管理者用端末２へ送信し、管理者用端末２の表示部４５に表示するようにしてもよい。この場合は、管理者用端末２の制御部２１が、閲覧データ表示要求信号をサーバ１へ送信し（ステップＳ１３８）、これを受信（ステップＳ１３９）したサーバ１の制御部１１は、閲覧データを記憶部２３から読み込み、管理者用端末２へ送信する（ステップＳ１４０）。そして、閲覧データを受信した管理者用端末２の制御部２１は、表示部２５に表示する（ステップＳ１４１）。

表示部２５に表示される画面は、例えば、図１９のような案件状況表示画面である。これは、案件状況表示画面は、管理者が参照する画面であり、制御部２１は、管理者による、入力部２４を介した履歴表示１７１への選択を受け付けることで、閲覧データ表示要求信号をサーバ１に送信する（ステップＳ１３８）。そして、サーバ１から閲覧データを受信すると、制御部２１は、連絡データを送信した案件等の詳細を示す表１７２と募集連絡データを送信した要員の一覧表１７３を表示部２５に表示する。募集対象のオペレータが募集連絡データをオペレータ端末４の表示部４５で閲覧したことを示す閲覧データをサーバ１の制御部１１が受信した場合に、一覧表１７３内の確認済み列１７４において、アスタリスクを表示する。閲覧データとは、このように募集対象のオペレータが募集連絡データを閲覧したか否かを示すデータである。図１９の表示例では、１番目と３番目の募集対象のオペレータにアスタリスクが表示されているので、当該募集対象のオペレータが募集連絡データを閲覧したことが管理者に分かるようになる。

尚、閲覧データは、例えば図２０のようなテーブルで示される。図１９の閲覧データテーブルには、募集連絡データを送信した募集対象のオペレータ名やＩＤ、募集連絡データの閲覧の有無（確認済み列２０１）が少なくとも用意されており、確認済み列２０１には、通常は「ゼロ」が記入されている。そして、サーバ１の制御部１１が閲覧データを受信した場合には、「１」が記入されて、当該募集対象のオペレータが募集連絡データを受信したことを表す。この「ゼロ」又は「１」が案件状況表示画面における確認済み列１７４でのアスタリスクの有無を示す。

ステップＳ１４３では、管理者用端末２から応募データ受付終了指示信号を受信（ステップＳ１４２）したか否かを判別する。受信しない場合は、ステップＳ１３３もしくはステップＳ１３５に戻り、受信の受付を継続する。また、応募データ受付終了指示信号を受信した場合は、本サブルーチンを終了する。

図２１は、本発明の好適な実施形態の一例に係る採用決定・採用通知データ作成処理自動で行うサブルーチンのフローである。以下、図２１から図２２に基づいて採用決定・採用通知データ作成処理について説明する。

まず、管理者用端末２の制御部２１は、通信部２２を介して、採用データ作成処理要求信号をサーバ１に送信する（ステップＳ２０１）。サーバ１は、管理者用端末２から送信された採用データ作成処理要求信号を受信（ステップＳ２０３）すると、スケジュールデータ記憶部１５から募集連絡データ及び応募データを読み込む（ステップＳ２０５）。

ステップＳ２０７では、募集連絡データ及び応募データに基づいて、採用する募集対象のオペレータを決定し、採用データを作成する。具体的には、例えば、応募データを受信した順番に採用する募集対象のオペレータを決定してもよいし、予め募集対象のオペレータの採用についての優先順位を定めておき、優先順位順に採用を自動的に決定してもよい。

尚、採用データは、例えば、図２２のようなテーブルである。図２２の採用データテーブルは、ＩＤ、名前、応募日、スキル、評価、雇用タイプ等の項目がある。例えば、ＩＤ１２３４番の募集対象のオペレータは、○○花子という名前であり、２００５年８月５日に応募し、スキルはサーバ対応及び英語対応が可能であり、評価はＡの正社員であることを示している。尚この採用データテーブルの項目は、本実施例以外の項目が追加されてよいし、本実施例の項目よりも少なくてよい。例えば、各募集対象のオペレータの連絡先や希望優先順位、欠席率等の項目があってよい。この処理が終了した場合には、ステップＳ２０９に処理を移す。

ステップＳ２０９では、制御部１１は、ステップＳ２０７で作成した採用データを記憶部１３のスケジュールデータ記憶部１５に記憶する。この処理が終了した場合には、ステップＳ２１１に処理を移す。

ステップＳ２１１では、制御部１１は、採用通知データを作成する。具体的には、例えば、サーバ１の制御部１１は、採用者に対して所定の形式でメール等を作成し、オペレータ端末４からの採用通知データ送信要求信号を受信することに応じて（ステップＳ２１２、Ｓ２１３）送信する（ステップＳ２１４）ことになる。この送信先は、オペレータ端末４であってよいし、外部用のメールサーバから外部通信ネットワーク５を通じて募集対象のオペレータの携帯端末６ａ，６ｂ等にメールを送信してもよい。送信先の設定はオペレータ端末４において行うことができ、設定結果は、サーバ１に送信され、統計データ記憶部１４に記憶される。そして、オペレータ端末４の制御部４１は、通信部４２を介して採用通知データを受信する（ステップＳ２１５）。

ステップＳ２１７では、制御部１１は、採用データに含まれるデータを仮決定スケジュールデータに登録し、仮決定スケジュールデータを更新する。この処理が終了した場合には、ステップＳ２１９に処理を移す。

ステップＳ２１９では、ステップＳ２１７で更新した仮決定スケジュールデータをスケジュールデータ記憶部１５に記憶する。この処理が終了した場合には、ステップＳ２２１に処理を移す。

ステップＳ２２１では、採用した募集対象のオペレータの人数が、不足人数と同じであるか否かを判別する。不足人数と同じであれば、現在不足する人数はゼロであることになる。採用した募集対象のオペレータの人数が不足人数を下回る場合は、まだ募集対象のオペレータ数が不足していることになる。この場合は、再度募集をかけるか、スケジュール調整を行うか等の検討が行われることになる。

図２１は、採用決定・採用通知データ作成処理を自動で行う場合のフローであるが、手動で行うようにしてもよい。図２３、図２４は、採用決定・採用通知データ作成処理を手動で行う場合のフローである。以下、図に基づいて説明する。

まず、管理者用端末２の制御部２１は、通信部２２を介して、採用データ作成処理要求信号をサーバ１に送信する（ステップＳ３０１）。サーバ１は、管理者用端末２から送信された採用データ作成処理要求信号を受信（ステップＳ３０３）すると、スケジュールデータ記憶部１５から募集連絡データ及び応募データを読み込む（ステップＳ３０５）。

ステップＳ３０７では、管理者用端末２の制御部２１は、閲覧データ表示要求信号を、通信部２２を介してサーバ１に送信する。そして、閲覧データ表示要求信号を、通信部１２を介して受信（ステップＳ３０９）したサーバ１の制御部１１は、閲覧データを読み込み、管理者用端末２へ通信部１２を介して送信する（ステップＳ３１１）。通信部２２を介して閲覧データを受信した管理者用端末２の制御部２１は、表示部２５に表示する。表示例としては、例えば、図２５のような画面である。そして、採用したい募集対象のオペレータについて、管理者が入力部２４を介してチェックボックス１２１にチェックを入力したことを制御部２１が受け付けることにより、採用データが作成される（ステップＳ３１４）。そして、管理者用端末２の制御部２１は、採用データを、通信部２２を介してサーバ１に送信（ステップＳ３１５）する。そして、サーバ１の制御部１１は、通信部１２を介して採用データを受信（ステップＳ３１６）し、記憶部１３に記憶する。以降の処理は、図２１のステップＳ２０９以降と同様である。

再度募集をかける場合に、再度募集を行う要員を検討する際には、例えば、図１９の案件状況確認画面を参照すれば、募集連絡データを閲覧していない要員を優先して募集をかけるようにすることができるので、応募する可能性のあるような要員に対して効率的に募集をかけることが可能となる。また、図２６のような画面では、現在進行中または将来予定されている業務についてのスケジュール作成状況の一覧を参照するようにしてもよい。

図２６では、各業務に関するスケジュール作成において、日単位で要員の過不足を表示したり、スケジュール作成の進行度合いを表示する。例えば、お客様サポートという業務においては、進捗状況２４２が１０段階に表示されており、その下に具体的な進行状況文２４３が記載されている。この場合は、スケジュール配布済みとなっている。そして、進行状況文２４３の下には、日単位での予定されている要員数２４４が記載される。この場合は、８月１日が８人、２日に８人、３日に９人が予定されている。また、４日には、８人不足、５日は２人不足していることが示され、さらに６日は４人、７日は７人が予定されていることを示す。このように正の数は予定される配置人数、負の数は不足している配置人数を示すことにより、スケジュール作成の進行度合いや、ある日付における要員の過不足について他の業務に関するスケジュールを横断的に確認することが可能となる。

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

本発明の好適な実施形態の一例に係るコンピュータシステムの全体構成を示す概念図である。 本発明の好適な実施形態の一例に係るコンピュータシステムの構成を示すブロック図である。 本発明の好適な実施形態の一例に係るメインフローを示す図である。 本発明の好適な実施形態の一例に係る想定スケジュールデータ作成処理のフローである。 本発明の好適な実施形態の一例に係る想定スケジュールデータテーブルを示す図である。 本発明の好適な実施形態の一例に係る希望スケジュールデータ作成処理を示すフローである。 本発明の好適な実施形態の一例に係る週休取得申請入力画面の表示例である。 本発明の好適な実施形態の一例に係る希望スケジュールデータテーブルを示す図である。 本発明の好適な実施形態の一例に係る週休取得承認入力画面の表示例である。 本発明の好適な実施形態の一例に係る仮決定スケジュール作成画面の表示例である。 本発明の好適な実施形態の一例に係る仮決定スケジュールデータテーブルを示す図である。 本発明の好適な実施形態の一例に係る募集連絡データ作成処理のフローである。 本発明の好適な実施形態の一例に係る募集連絡データ作成処理のフローである。 本発明の好適な実施形態の一例に係る要求スキルデータテーブルを示す図である。 本発明の好適な実施形態の一例に係るオペレータスキルテーブルの表示例である。 本発明の好適な実施形態の一例に係る個人情報設定の表示例である。 本発明の好適な実施形態の一例に係る募集連絡データのメールの表示例である。 本発明の好適な実施形態の一例に係る募集連絡データのメールの表示例である。 本発明の好適な実施形態の一例に係る案件状況表示画面の表示例である。 本発明の好適な実施形態の一例に係る閲覧データテーブルを示す図である。 本発明の好適な実施形態の一例に係る採用決定・採用通知データ作成処理のフロー（自動）である。 本発明の好適な実施形態の一例に係る採用データテーブルを示す図である。 本発明の好適な実施形態の一例に係る採用決定・採用通知データ作成処理のフロー（手動）である。 本発明の好適な実施形態の一例に係る採用決定・採用通知データ作成処理のフロー（手動）である。 本発明の好適な実施形態の一例に係る採用決定入力画面の表示例である。 本発明の好適な実施形態の一例に係る仮決定スケジュールデータ一覧画面の表示例である。

符号の説明

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

Claims (10)

1. サーバ、管理者端末、及び要員端末が通信ネットワークを介して接続され、前記管理者端末で複数の要員の勤務スケジュールを管理する方法であって、
   前記サーバが、
   事業所における作業量に関する作業量統計データに応じて、前記複数の要員に関する勤務の想定スケジュールを表す想定スケジュールデータを生成して記憶部に記憶する想定スケジュールデータ生成ステップと、
   前記要員端末からの要求に応じて前記想定スケジュールデータを前記要員端末に送信する想定スケジュールデータ送信ステップと、
   所定期間を指定して前記要員端末から要員毎にその勤務の希望スケジュールを表す希望スケジュールデータの受け付けを開始し、要員毎の希望スケジュールを表す希望スケジュールデータを前記要員端末から受信して記憶部に記憶する希望スケジュールデータ受信ステップと、を行い、
   前記管理者端末が、
   前記所定期間の経過後、前記サーバから前記想定スケジュールデータと前記希望スケジュールデータとを受けて、前記想定スケジュールデータと前記希望スケジュールデータとに基づいて要員毎の勤務に係る仮決定スケジュールを表す仮決定スケジュールデータを生成する仮決定スケジュールデータ生成ステップと、
   前記想定スケジュールデータによって示される時間帯毎の必要人数から、前記仮決定スケジュールデータによって示される配置予定の要員数に要員毎の処理効率を乗じた値を減じて、当該時間帯毎の要員の不足量を示す不足量データを生成する不足量データ生成ステップと、
   前記不足量データを表示部に表示する不足量データ表示ステップと、を行う方法。
2. 前記管理者端末は、前記不足量データ表示ステップにおいて、前記不足量が正である時間帯には、当該不足量をマイナス値で表示し、前記不足量が負又はゼロである時間帯には、前記仮決定スケジュールデータによって示される配置予定の要員数を表示する請求項１に記載の方法。
3. 前記管理者端末が、前記不足量データと前記複数の要員の属性を表す要員属性データとに基づいて募集連絡を行う要員を表す募集連絡データを生成する募集連絡データ生成ステップをさらに行う請求項１又は２に記載の方法。
4. 前記サーバが、前記通信ネットワークを介して、前記要員の公開されている連絡先である要員端末のみに対して、前記管理者端末で生成された前記募集連絡データを送信する募集連絡データ送信ステップをさらに行う請求項３に記載の方法。
5. 前記サーバが、前記通信ネットワークを介して、前記募集連絡を行った要員の要員端末からの応募データを受信したことに応じて、前記応募データを前記記憶部に記憶する応募データ記憶ステップをさらに行う請求項４に記載の方法。
6. 前記管理者端末は、前記サーバが前記募集連絡を行った要員からの応募データを前記記憶部に記憶すると、採用要員を表す採用データを生成する採用データ生成ステップをさらに行う請求項５に記載の方法。
7. 前記サーバは、前記募集連絡を行った要員による閲覧を受け付けたことを表す閲覧確認データを前記要員端末から受信すると、前記閲覧確認データを前記記憶部に記憶する閲覧確認データ記憶ステップをさらに行う請求項５に記載の方法。
8. 前記管理者端末は、管理者の要求を受け付けると、前記サーバによって前記記憶部に記憶された前記応募データ及び前記閲覧確認データを表示する応募・閲覧状況表示ステップをさらに行う請求項７に記載の方法。
9. 前記管理者端末は、管理者の要求の受け付けると、前記想定スケジュールデータ、前記希望スケジュールデータ及び前記仮決定スケジュールデータの作成状況を表すスケジュール作成状況データを前記表示部に表示するスケジュール作成状況表示ステップをさらに行う請求項１から８のいずれかに記載の方法。
10. サーバ、管理者端末、及び要員端末が通信ネットワークを介して接続され、前記管理者端末で複数の要員の勤務スケジュールを管理するプログラムであって、
    前記サーバが備えるコンピュータに、
    事業所における作業量に関する作業量統計データに応じて、前記複数の要員に関する勤務の想定スケジュールを表す想定スケジュールデータを生成して記憶部に記憶する想定スケジュールデータ生成ステップと、
    前記要員端末からの要求に応じて前記想定スケジュールデータを前記要員端末に送信する想定スケジュールデータ送信ステップと、
    所定期間を指定して前記要員端末から要員毎にその勤務の希望スケジュールを表す希望スケジュールデータの受け付けを開始し、要員毎の希望スケジュールを表す希望スケジュールデータを前記要員端末から受信して記憶部に記憶する希望スケジュールデータ受信ステップと、を実行させ、
    前記管理者端末が備えるコンピュータに、
    前記所定期間の経過後、前記サーバから前記想定スケジュールデータと前記希望スケジュールデータとを受けて、前記想定スケジュールデータと前記希望スケジュールデータとに基づいて要員毎の勤務に係る仮決定スケジュールを表す仮決定スケジュールデータを生成する仮決定スケジュールデータ生成ステップと、
    前記想定スケジュールデータによって示される時間帯毎の必要人数から、前記仮決定スケジュールデータによって示される配置予定の要員数に要員毎の処理効率を乗じた値を減じて、当該時間帯毎の要員の不足量を示す不足量データを生成する不足量データ生成ステップと、
    前記不足量データを表示部に表示する不足量データ表示ステップと、を実行させるプログラム。

Images