JP2005292957A

JP2005292957A - 承認システム、承認方法、およびコンピュータプログラム

Info

Publication number: JP2005292957A
Application number: JP2004103861A
Authority: JP
Inventors: Kinji Kawamura; 錦二川村; Yasuyuki Sato; 保幸佐藤
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2004-03-31
Filing date: 2004-03-31
Publication date: 2005-10-20

Abstract

【課題】現認制での申請および承認を従来よりも簡単に行えるようにする。
【解決手段】承認システム１００に、承認者となるべき承認担当者を記憶するデータベースと、勤務に関する事項を承認すべき旨の申請を受け付ける申請受付部１４と、承認担当者が使用する表示装置に、受け付けられた申請に係る未承認の勤務に関する事項のうち、その承認担当者が承認者となるべき事項とともに、他の承認担当者が承認者となるべきでありかつ承認すべき期限を過ぎた事項、他の承認担当者が承認者となるべきでありかつ期限が所定の時間にまで迫っている事項、または離席中である他の承認担当者が承認者となるべき事項、を示す一覧画面を表示させるための画面データを送信する管理職画面送信部１６と、一覧画面に示される事項の中から承認担当者が承認した事項の指定を受け付ける承認受付部１７と、指定された事項を示す承認済事項情報を記憶するデータベースと、を設ける。
【選択図】図３

Description

本発明は、勤務に関する事項などを申請しおよび承認するためのシステムおよび方法に関する。

金融機関、機密情報を取り扱う職場、高額な製品を取り扱う職場、および危険を伴う作業を行う職場などでは、従業員の勤務の状況を厳密に把握しなければならない。これらの職場では、他の企業に比べて、不正や事故などを未然に防止することが強く要求されるからである。

そこで、このような職場では、従業員が予定通りに勤務していることを責任者が目で見てチェック（現認）したり、残業する場合は必ず事前に責任者の承認を得るように従業員に求めたりしている。そのために、出勤時刻および退勤時刻などを記載するための出勤台帳の用紙または残業申請用の用紙を従業員に配付している。そして、責任者は、毎日、従業員の勤務状態を現認してから、その従業員の提出された出勤台帳の用紙に捺印して承認を与えている。また、残業する必要があるか否かを判断してから、提出された残業申請用の用紙に捺印して承認を与えている。

ところで、特許文献１に記載されるように、勤務に関する事項を申請しおよび承認するためのシステムが提案されている。係るシステムによると、従業員は出勤時刻および退勤時刻の入力や残業申請の入力を自分の端末装置によって行うことができ、責任者は従業員が入力（申請）した内容について自分の端末装置によって承認を与えることができる。
特開２００３−６３９６号公報

しかし、前述のような、勤務状況を現認しまたは残業を事前に申請し承認しなければならない職場では、特許文献１に記載されるシステムを採用しても、従業員および責任者にとって、次のような不都合が残る
例えば、承認を担当する者が毎日変わる場合（いわゆる、当番制の場合）または通常の責任者が欠勤した場合などは、従業員は、どの責任者に対して申請を行えばよいのかを調べなければならいので、面倒である。また、責任者は、従業員の勤務状況を現認しなければならないし、残業申請にすぐに目を通さなければならないので、少しの時間だけ離席することすら難しい場合がある。よって、自分が行うべき他の業務の効率が落ちることがあるし、精神的な負担にもなる。離席する前に、自分宛ての申請の事項を他の責任者に承認してもらうことも考えられるが、そうすると、他の責任者にその申請のデータを転送しなければならないので面倒である。

本発明は、このような問題点に鑑み、現認制を採用する職場などにおいて、従来よりも簡単に申請および承認を行うことができるようにすることを目的とする。

本発明に係る承認システムは、作業に関する事項を承認するための承認システムであって、前記事項の属性ごとに承認者となるべき承認担当者を記憶する承認担当者記憶手段と、前記事項を承認すべき旨の申請を受け付ける申請受付手段と、前記承認担当者が使用する表示装置に、受け付けられた前記申請に係る未承認の前記事項のうち、当該承認担当者が承認者となるべき事項とともに、他の承認担当者が承認者となるべきでありかつ承認すべき期限を過ぎた事項、他の承認担当者が承認者となるべきでありかつ前記期限が所定の時間にまで迫っている事項、または離席中である他の承認担当者が承認者となるべき事項、を示す一覧画面を表示させるための表示制御手段と、前記一覧画面に示される前記事項の中から前記承認担当者が承認した事項を指定する承認指定手段と、指定された前記事項を示す承認済事項情報を記憶する承認済事項記憶手段と、を有することを特徴とする。

前記承認システムは、前記事項として、例えば、勤務に関する事項を承認するために用いられる。この場合は、前記承認担当者記憶手段は、グループごとに、当該グループに所属する従業員の前記事項の承認者となるべき承認担当者を記憶する。前記申請受付手段は、従業員から前記申請を受け付ける。

なお、本発明において、「グループ」とは、企業または役所などにおける、１人または複数人の従業員の集まりを意味し、例えば、本支店、部、課、係、または班などが該当する。

本発明によると、現認制を採用する職場などにおいて従来よりも簡単に申請および承認を行うことができる。

図１は承認システム１００の全体的な構成の例を示す図、図２は企業Ａの部署の構成の例を示す図、図３はホスト１、従業員用端末装置２、および管理職用端末装置３の機能的構成の例を示す図である。

本発明に係る承認システム１００は、図１に示すように、ホスト１、従業員用端末装置２、管理職用端末装置３、および通信回線４などによって構成される。ホスト１と従業員用端末装置２および管理職用端末装置３とは、通信回線４を介して互いに接続されている。通信回線４として、インターネット、ＬＡＮ（Local Area Network）、専用線、または公衆回線などが用いられる。

この承認システム１００は、企業または役所などの団体の従業員の勤務などに関する事項の申請および承認を行うために用いられる。例えば、従業員からの休暇、残業、時間外出勤、出張などの勤務に関する事項の申請がなされた場合に、使用者または所定の管理職に従事する者（以下、「管理職員」と記載する。）が承認を行うために用いられる。

以下、本店および複数の支店を有しかつ次の（１）〜（５）の原則を採用する企業Ａにおいて承認システム１００が用いられる場合を例に説明する。
（１）従業員は、出勤したら速やかに出勤時刻（始業時刻）およびその日の退勤の予定の時刻（終業時刻）を申請しなければならない。（２）従業員は、残業、時差出勤、および出張などのように通常とは異なる時間帯または形態で勤務を行う場合および休暇を取る場合は、事前にその旨を申請しなければならない。（３）承認を与える作業は、申請をした従業員と同じ部に属する管理職員が日替わりで担当する。（４）承認は、従業員の勤務状態を確認した上で与えなければならない。（５）承認を与える作業は毎日決められた時刻までに行わなければならない。

上記（３）のように、現認者を日替わりで担当する制度は、一般に、「当番制」などと呼ばれる。また、上記（４）のように勤務状態を確認して承認を与える制度は、一般に、「現認制」または「現認承認制」などと呼ばれる。以下、承認を与える者のことを「現認者」または「現認承認者」と記載する。また、その日に現認者を担当する者すなわち当番に当たっている者を「現認担当者」と記載する。

上記（５）の決められた時刻を、以下、「承認期限時刻」と記載する。本実施形態では、午前９時および午後４時が承認期限時刻として定められているものとする。

現認担当者に当たった管理職員すなわち現認担当者は、上記（３）で述べたように自分の部に所属する従業員からの申請に対して承認を与える。しかし、他の部の従業員からの申請に対しては承認を与えることができない。また、現認担当者は、部を構成するグループごとに１人または複数人、日替わりで割り当てられる。現認担当者は、原則として自分の当たったグループの従業員からの申請に対する承認のみを行えばよいが、その部に属する他のグループの現認担当者が承認の作業を行うことができない場合は代わりに承認を行わなければならない。現認担当者に当たっていない（つまり、当番でない）管理職員は、いずれのグループの従業員からの申請に対しても、承認を与えることはできない。

例えば、図２に示すように、第一ないし第三グループによって構成される営業部では、各グループに毎日１人または複数人ずつの現認担当者が割り当てられる。第一グループの現認担当者は、通常は第一グループの従業員についてのみ承認を行えばよいが、第二または第三のグループの現認担当者が承認の作業を行うことができない場合または承認を忘れている場合などは、代わりに各グループの従業員の申請について承認を行わなければならない。ただし、管理部など他の部の従業員について承認の作業を行うことはできない。

図１に戻って、ホスト１は、企業Ａの本店などに設置されており、企業Ａの人事および総務などに関する処理を統括して行う。ホスト１には、図３に示すようなスケジュール更新部１１、現認者当番決定部１２、従業員画面送信部１３、申請受付部１４、承認対象者判別部１５、管理職画面送信部１６、承認受付部１７、およびデータベース管理部１Ｄなどの機能を実現するためのプログラムおよびデータがインストールされている。

従業員用端末装置２および管理職用端末装置３は、企業Ａの本店および各支店に少なくとも１台ずつ設置されている。従業員用端末装置２は、従業員が勤務などに関する申請を行うために用いられる。管理職用端末装置３は、管理職員が従業員からの申請の内容を承認しまたは却下するために用いられる。

従業員用端末装置２には、図３に示すような表示制御部２１および勤務申請部２２などの機能を実現するためのプログラムおよびデータがインストールされている。管理職用端末装置３には、表示制御部３１および承認指令部３２などの機能を実現するためのプログラムおよびデータがインストールされている。従業員用端末装置２および管理職用端末装置３として、パーソナルコンピュータ、ワークステーション、ＰＤＡ（Personal Digital Assistant）、または携帯電話端末などが用いられる。なお、１台の端末装置に表示制御部２１、勤務申請部２２、表示制御部３１、および承認指令部３２のためのプログラムおよびデータをインストールしておき、その端末装置を従業員用端末装置２としても管理職用端末装置３としても使用できるようにしてもよい。

以下、図３の各部の処理内容などについて説明する。図４はデータベース管理部１Ｄの構成の例を示す図、図５は従業員マスタ８１の例を示す図、図６は人事異動マスタ８２の例を示す図、図７はスケジュールマスタ８３の例を示す図、図８は管理職初期画面ＨＧ１の例を示す図である。

図３のデータベース管理部１Ｄは、図４に示すように、人事データベースＤＢ１、現認者データベースＤＢ２、および勤務データベースＤＢ３などを記憶し管理する。

人事データベースＤＢ１は、従業員マスタ８１および人事異動マスタ８２などによって構成される。従業員マスタ８１は、図５に示すように、管理職員を含むすべての従業員の社員番号、氏名、配属部署（部およびグループなど）、および役職などに関する情報が記録されている。人事異動マスタ８２は、図６に示すように、人事異動、休職、退職、入社などの人事関係の動きの予定についての情報が格納されている。従業員マスタ８１および人事異動マスタ８２の内容は、人事担当の従業員によって入力される。

現認者データベースＤＢ２は、スケジュールマスタ８３および現認者割当マスタ８４などによって構成される。

スケジュールマスタ８３は、現認者となり得る資格を有する管理職員ごとに設けられ、図７に示すように管理職員の日ごとの行動予定（スケジュール）を示す情報が記憶される。スケジュールマスタ８３の内容は、次のようにして更新される。

管理職員は、管理職用端末装置３に自分の社員番号およびパスワードを入力して承認システム１００にログオンする。すると、図３の管理職画面送信部１６は、図８に示すような管理職初期画面ＨＧ１を表示するための画面データをその管理職用端末装置３に送信する。なお、管理職用端末装置３のディスプレイに表示する他の画面（図１２、図１３、図２４参照）の画面データも、管理職画面送信部１６によって管理職用端末装置３に送信される。

管理職用端末装置３の表示制御部３１は、受信した画面データに基づいて管理職初期画面ＨＧ１をディスプレイに表示する。ここで、スケジュールボタンＢＮ１１がクリックされると、スケジュールマスタ８３を編集するための画面を表示する。管理職員は、この画面を見ながら自分の行動予定を編集する。

スケジュール更新部１１は、編集された内容のデータを管理職用端末装置３より受信し、そのデータに基づいてその管理職員のスケジュールマスタ８３を更新する。

図９は現認者割当マスタ８４のフィールドの構成の例を示す図、図１０は現認当番月次割当処理の流れの例を説明するフローチャート、図１１は現認当番入替処理の流れの例を説明するフローチャート、図１２は現認者管理画面ＨＧ２の例を示す図、図１３は当番変更画面ＨＧ３の例を示す図、図１４は在席フラグ更新処理の例を示す図である。

図４の現認者割当マスタ８４は、図９に示すように、１ヶ月間の現認者の当番の割当に関する情報および与えた承認の実績に関する情報などを記憶する。企業Ａの１つの部に対して１月ごとに１つの現認者割当マスタ８４が設けられている。

この現認者割当マスタ８４は、図９（ａ）に示すようなフィールド（項目）からなる。「所属」のフィールドには、部を識別する識別情報が格納される。「勤務年月」には、その年度および月度（以下、両者を併せて「年月度」と記載することがある。）を示す数値が格納される。

「日付ＮＮ」は、その年月度に属する日数と同じ個数だけあり、各日を示す数値（つまり、１〜３１のいずれかの日付）が格納される。例えば、企業Ａが月度の初日を「１日」と定めている場合は、各「日付ＮＮ」には、上から順番に「１」、「２」、…、「３１」が格納される。

「日付ＮＮ」のすぐ下の「現認者Ｎ内容」は、図９（ｂ）に示すような複数のフィールドからなるフィールド群である。このフィールド群は、その部におけるその「日付ＮＮ」の日の現認担当者（当番）の人数分だけ設けられる。例えば、営業部の各グループ（図２参照）の現認担当者が１人ずつである場合は３つの「現認者Ｎ内容」が設けられる。

「個人番号ＮＮ」および「氏名ＮＮ」には、現認担当者を識別する番号（例えば、社員番号）および氏名が格納される。「グループＮＮ」には、その現認担当者が担当するグループを識別するグループ番号が格納される。「状態ＦＮＮ」は、その現認担当者の現在の状態（在席しているか離席しているかなど）を示すフラグである。以下、係るフラグを「在席状態フラグ」と記載する。在席状態フラグが示す値については、後に説明する。「最終承認時間ＮＮ」には、その現認担当者がその日に最後に承認を行った時刻が格納される。「最終承認状況ＮＮ」には、最後に承認を行った際の状況（事前承認の有無、事後承認の有無、または未承認の件数など）を示す情報が格納される。

翌月度の現認者割当マスタ８４は、図３の現認者当番決定部１２によって、図１０に示すような手順で毎月所定の日（例えば、翌月度が始まる日の２週間前）に生成される。ここでは、営業部の現認者割当マスタ８４を生成する場合を例に説明する。

現認者当番決定部１２は、従業員マスタ８１（図５参照）より、営業部に所属しかつ現認者となり得る管理職員を抽出する（図１０の＃１０１〜＃１０３）。例えば、課長以上副部長以下の役職を持つ管理職員が現認者になると定められている場合は、これらの管理職員を抽出する。

このとき、人事異動マスタ８２（図６参照）を参照し、翌月度から営業部に配属される、現認者となり得る管理職員も抽出しておく。また、当月度の最終日までに他の部に異動し、休職し、または退職するものは除外しておく。

抽出された管理職員を、ステップ＃１０４〜＃１０８のようにして、翌月度の各日の当番（現認担当者）に割り当てる。すなわち、まず、抽出された管理職員の人数を、一日に必要な現認担当者の人数で割る（＃１０４）。これにより、各管理職員が現認担当者になるインターバル（日の間隔）が求められる。例えば、抽出された管理職員が１０人で、営業部全体で３人の現認担当者が必要である場合は、３．３日つまり３〜４日の間隔で当番が回ってくることになる。

求められた間隔で当番が回るように、抽出された管理職員を各日に振り分ける（＃１０５）。ただし、当番に当たった日にその管理職員が休暇を取る予定であり、またはその日の承認期限時刻に企業Ａにいない予定の場合などは（＃１０６でＹｅｓ）、他の管理職員を割り当てる（＃１０７）。また、翌月度の途中で他の部に異動し、休職し、または退職する管理職員は、その日以降は当番に当たらないように調整する。休暇および異動などの予定は、スケジュールマスタ８３および人事異動マスタ８２などを参照して知ることができる。

また、当月度および翌月度のそれぞれの現認者割当マスタ８４は、必要に応じて、図１１に示すような手順で定期的に（例えば、毎日所定の時刻に１回）更新される。ここでは、営業部の現認者割当マスタ８４を更新する場合を例に説明する。

図３の現認者当番決定部１２は、人事異動マスタ８２、スケジュールマスタ８３、および更新対象の現認者割当マスタ８４を読み込む（＃２０１〜＃２０３）。人事異動マスタ８２に基づいて、営業部に関する新たな人事異動の予定が発生したか否かを判別する（＃２０４）。人事異動の予定が発生した場合は（＃２０４でＹｅｓ）、営業部の当月度または翌月度の現認者割当マスタ８４を更新する（＃２０５）。例えば、異動などによって営業部を離れる管理職員がいる場合は、その管理職員の当番の日に既存の管理職員を割り当てる。または、入れ替わりで入部する新任の管理職員がいる場合は、その管理職員をその日の現認担当者（当番）として割り当てる。

スケジュールマスタ８３に基づいて、当番の日に出張または休暇などの予定が新たに加わった管理職員がいないかどうか判別する（＃２０６）。そのような管理職員がいて当番の変更が必要な場合は（＃２０６でＹｅｓ）、その管理職員を別の日に当番に当たっている他の管理職員と入れ替えるなどして調整を行う（＃２０７）。

人事異動や予定の変更などがなければ（＃２０４でＮｏかつ＃２０６でＮｏ）、現認者割当マスタ８４の更新は行われない。

他の部の当番の割当ておよび更新も、上記と同様の方法によって行う。なお、当番を割り当てる方法および更新する方法は、他の公知の方法を用いてもよい。

現認者割当マスタ８４は、次のようにして、管理職員が操作して変更することもできる。当番の変更を行いたい管理職員は、管理職用端末装置３に表示されている管理職初期画面ＨＧ１（図８参照）より現認者管理ボタンＢＮ１２をクリックする。すると、管理職用端末装置３のディスプレイには、図１２に示すような現認者管理画面ＨＧ２が表示される。ここで、管理職員は、現認者管理画面ＨＧ２の中のカレンダの中から変更したい日をクリックする。

すると、図３の現認者当番決定部１２によってその日の当番に当たっている管理職員が現認者割当マスタ８４から検索され、管理職用端末装置３のディスプレイには、図１３のような、当番の一覧を有する当番変更画面ＨＧ３が表示される。管理職員は、変更の対象の管理職員の行を選択し、削除ボタンＢＮ２２をクリックする。さらに、空欄になった行を選択して追加ボタンＢＮ２１をクリックすると、現認者となり得る管理職員の一覧が表示されるので、新たな当番を選択する。これにより、選択された管理職員の名前などがその行に追加される。そして、登録ボタンＢＮ２３をクリックする。現認者当番決定部１２は、このような操作の内容に応じて、現認者割当マスタ８４を更新する。

なお、一日当たりの現認担当者の人数を変更することもできる。この場合は、図１２の現認者管理画面ＨＧ２のテキストボックスＴＸ２１〜ＴＸ２３に、変更後の人数を入力すればよい。その後、現認者当番決定部１２は、前述の図１０のフローチャートなどの手順で、変更後の人数の現認担当者が各日に割り当てられるように現認者割当マスタ８４を更新しまたは作成し直す。

現認者割当マスタ８４（図９（ｂ）参照）の各「状態ＦＮＮ」（在席状態フラグ）のうち当日の現認担当者の「状態ＦＮＮ」は、定期的に（例えば、数分ごとに）、図１４に示すような手順で更新される。

まず、現認者割当マスタ８４を読み込み（図１４の＃３０１）、その現認者割当マスタ８４に示される当日の現認担当者のスケジュールマスタ８３を読み込む（＃３０２）。現在の時刻が承認期限時刻の所定の時間（例えば、１０分）以上前である場合は（＃３０３でＹｅｓ）、現在、現認担当者が在席しているか離席しているかをスケジュールマスタ８３に基づいて判別する（＃３０４）。例えば、その時刻の予定が「在席」である場合は、在席していると判別する。また、その時刻の予定が企業Ａの他の支店への出張である場合など、管理職用端末装置３を操作し得る状況にある場合も、在席していると判別する。会議または他社への出張である場合など、管理職用端末装置３を操作することができない状況にある場合は、離席していると判別する。

現認担当者が離席していると判別された場合は（＃３０４でＮｏ）、その現認担当者が承認期限時刻までに在席する予定であるか否か（つまり、従業員用端末装置２を操作し得る状況になるか否か）を判別する（＃３０５）。在席する予定である場合は（＃３０５でＹｅｓ）、その現認担当者の在席状態フラグ（「状態ＦＮＮ」のフィールド）に「Ｃ」を格納する（＃３０６）。在席する予定でない場合は（＃３０５でＮｏ）、「Ｄ」を格納する（＃３０７）。

現認担当者が在席している場合は（＃３０４でＹｅｓ）、その現認担当者の在席状態フラグの値を消去する（＃３０８）。

現在の時刻が承認期限時刻を過ぎている場合は（＃３０３でＮｏ、＃３０９でＹｅｓ）、各現認担当者の在席状態フラグに「Ａ」を格納する（＃３１０）。承認期限時刻まで５分を切っている場合は（＃３１１でＹｅｓ）、「Ｂ」を格納する（＃３１２）。承認期限時刻まで５分以上あるが１０分を切っている場合は（＃３１３でＹｅｓ）、「Ｃ」を格納する（＃３１４）。

このようにして在席状態フラグに格納される「Ａ」〜「Ｄ」は、その現認担当者の代わりに承認の作業を行うべきか否かを注意するように促す警告のレベルを示すものである。この警告は、後に説明するように、同じ日に当番に当たっている他の現認担当者に対して与えられるものである。Ａ、Ｂ、Ｃ、Ｄの順に警告の度合いが高い。

図１５は勤務状況マスタ８５のフィールドの構成の例を示す図、図１６は申請に関する内容を格納するフィールドの構成の例を示す図、図１７は申請処理の流れの例を説明するフローチャート、図１８は従業員初期画面ＨＧ４の例を示す図、図１９は申請入力画面ＨＧ５の例を示す図、図２０はプルダウンメニューＭＮ５の例を示す図である。

図４の勤務データベースＤＢ３は、勤務状況マスタ８５および勤務検印マスタ８６などによって構成される。勤務状況マスタ８５は、勤務に関する申請の情報が記憶される。１人の従業員に対して１月ごとに１つの勤務状況マスタ８５が与えられている。

勤務状況マスタ８５は、図１５に示すようなフィールド（項目）からなる。「申請者個人番号」のフィールドには、その従業員の社員番号が格納される。項番が「１」、「２」、「４」〜「２６」、および「２４５」〜「２４７」のフィールドには、その勤務状況マスタ８５の管理のための情報が格納される。

「申Ｎ内容」は、図１６に示すような複数のフィールドからなるフィールド群である。このフィールド群は、その月の日数分（２８ないし３１組）だけ設けられている。「申Ｎ勤務年月」には、その日の属する年月度（年度および月度）を示す数値が格納される。「申Ｎ日付」および「申Ｎ曜日」は、それぞれ、その日の日付および曜日が格納される。

項番「３０」の「申Ｎ勤務状況ＣＮＮ」には、その日の勤務に関する状況（通常出勤、時差出勤、欠勤、出張など）を示すコードが格納される。項番「３１」〜「３４」に属するフィールドには、その従業員のその日の始業時刻および終業時刻、労働時間、および時間外労働、休日出勤の振替え休日（代休）などに関する情報が格納される。

項番「３０」〜「３４」の内容は、従業員本人からの申請に基づいている。つまり、従業員が従業員用端末装置２を操作して入力する。申請は、その日以前に予め行う場合と翌日以降に行う場合とがある。以下、前者を「事前申請」と記載し、後者を「事後申請」と記載する。

前に（２）で述べたように、従業員は、申請は原則として事前申請によって行わなければならない。しかし、予定通りに残業を終えられなかった場合などのように、事前申請の内容通りに勤務ができないこともあり得る。このような場合は、従業員は、事後申請を行って、現認担当者から承認を得なければならない。以下、このように、勤務の実績について事後に承認を行うことを「事後承認」と記載する。また、当日以前に関する事項（つまり、予定）について事前に承認を行うことを「事前承認」と記載する。

勤務状況マスタ８５の内容は、図１７に示すような手順で入力される。従業員は、従業員用端末装置２に自分の社員番号およびパスワードを入力して承認システム１００にログオンし、従業員用端末装置２のディスプレイに図１８の従業員初期画面ＨＧ４を表示させる。なお、従業員初期画面ＨＧ４を表示するための画面データは、図３の従業員画面送信部１３によって従業員用端末装置２に送信される。従業員用端末装置２の表示制御部２１は、受信した画面データに基づいて画面をディスプレイに表示する処理を行う。他の画面（図１９、図２５参照）についても同様である。

申請入力ボタンＢＮ４１がクリックされると、従業員画面送信部１３は、その従業員の勤務状況マスタ８５などに基づいて図１９のような申請入力画面ＨＧ５を表示するための画面データを生成し、その画面データをその従業員用端末装置２に送信する（図１７の＃４０１）。

従業員は、申請入力画面ＨＧ５を見ながら次のような操作を行って、自分の勤務に関する申請を入力する。

通常の始業時刻通りに出勤し、かつ、残業を行わずに通常の終業時刻通りに退勤する場合は、従業員は、出勤後、申請入力画面ＨＧ５の中のその日に対応する行を選択し、「始業時刻」および「終業時刻」にそれぞれ通常の始業時刻および始業時刻を入力する。そして、その行の左方にある「更新」の文字をクリックしてから、保存ボタンＢＮ５１をクリックする。これにより、その日の勤務に関する申請の入力が完了する。なお、その日について休暇または時差出勤などの事前申請をしていない場合は、申請入力画面ＨＧ５を開いたときに、「始業時刻」および「終業時刻」にはそれぞれ通常の始業時刻および始業時刻がデフォルト値として自動入力されている。よって、この場合は、従業員は、その日の「始業時刻」および「終業時刻」が正しいことを確認して保存ボタンＢＮ５１をクリックするだけでよい。

その日に残業を行う予定がある場合は、従業員は、「終業時刻」に残業を終える予定の時刻を入力し、保存ボタンＢＮ５１などをクリックする。これにより、出勤した旨および残業をしたい旨の申請の入力が完了する。

上に述べた２つの申請の例から分かるように、本実施形態の企業Ａでは、一日全体の勤務の予定または実績を一纏めにして申請がなされる。よって、出勤後にその日の勤務に関する申請を行うと、実績（つまり出勤した時刻）と予定（つまり仕事の終了予定時刻）とが１組になる。このように実績および予定の両方を含む申請を、本実施形態の承認システム１００では、事前申請として取り扱う。

残業が予定通りの時刻に終わらなかった場合は、従業員は、退勤前または翌日以降に、その残業を行った日の「終業時刻」を訂正し、保存ボタンＢＮ５１などをクリックする。これにより、その残業を行った日の勤務に関する事後申請の入力が完了する。

出張、休暇、会議などの予定は、「勤務状況」に入力する。図２０のプルダウンメニューＭＮ５の中からその日の勤務状況または勤務形態に合った選択肢を選択することによって入力することができる。

このようにして申請入力画面ＨＧ５で入力された内容は、その従業員の社員番号と対応付けられて、申請情報７１としてホスト１に送信される。

ホスト１において、図３の申請受付部１４が申請情報７１を受信すると（図１７の＃４０２）、その申請情報７１に示される社員番号に対応する（つまり、申請者である従業員の）勤務状況マスタ８５を、勤務データベースＤＢ３より検索する（＃４０３）。そして、申請情報７１の内容を、その勤務状況マスタ８５の所定のフィールドに登録する（＃４０４でＮｏ、＃４０５）。

ただし、既にそのフィールドに申請内容が格納されている場合は（＃４０４でＹｅｓ）、その古い申請内容を削除し、今回の申請情報７１の内容を格納する（＃４０６）。この場合は、その日に関する申請を訂正したと考えられるので、その申請に対応する勤務検印マスタ８６をリセットすることによって、既に与えられている承認の取消を行う（＃４０７）。これについては、後に説明する。

図２１は勤務検印マスタ８６の例を示す図、図２２は承認処理の流れの例を説明するフローチャート、図２３は画面データ生成処理の流れの例を説明するフローチャート、図２４は承認画面ＨＧ６の例を示す図である。

図４の勤務検印マスタ８６は、図２１に示すようなフィールド（項目）からなり、勤務の申請に対する承認に関する情報が記憶される。１つの申請に対して１つの勤務検印マスタ８６が与えられる。つまり、１人の従業員に対して１日１つの勤務検印マスタ８６が設けられている。

「個人番号」のフィールドには、申請者である従業員の社員番号が格納される。「勤務年月」および「日付ＮＮ」には、それぞれ、その申請に係る日の属する年月度および日付が格納される。「申請に係る日」とは、申請を行った日ではなく、何日の勤務に関する申請であるか、を意味する。例えば、３月２０日に休暇を取る旨の事前申請を３月１０日に行った場合の「申請に係る日」は「３月２０日」である。

項番「５」〜「１５」のフィールドには、その申請に対して与えられた承認に関する情報が格納される。これらのフィールドのうち、「事前承認ＦＮＮ」は事前承認の有無などを示すフラグであり、事前承認がなされた場合に「１」が格納される。つまり、「事前承認ＦＮＮ」は、従来の紙の台帳における検印欄に相当する。なお、承認することを保留された場合は「２」が格納される。同様に、「事後承認ＦＮＮ」は事後承認の有無を示すフラグである。他のフィールドには、事前承認または事後承認を行った管理職員の社員番号、姓、または日付時刻などが格納される。

勤務検印マスタ８６は、図２２に示すような手順で更新される。管理職員は、管理職用端末装置３を操作して承認システム１００にログオンし、管理職初期画面ＨＧ１（図８参照）の承認作業ボタンＢＮ１３をクリックする。すると、図３の管理職画面送信部１６は、その管理職員の所属する部の現認者割当マスタ８４を読み込み（＃５０１）、その管理職員がその日の現認担当者（当番）であるか否かを判別する（＃５０２）。現認担当者でない場合は（＃５０２でＮｏ）、その日は承認を行うことができないので、その旨のメッセージを表示して処理を終了する。現認担当者である場合は（＃５０２でＹｅｓ）、図２３に示すような手順で、承認の作業用の画面である承認画面ＨＧ６（図２４参照）を表示するための画面データを生成する（＃５０３）。

承認対象者判別部１５は、現認者割当マスタ８４などに基づいて、その日にその管理職員（現認担当者）の担当するグループに所属する従業員（以下、「自グループ従業員」と記載する。）および他の現認担当者の担当するグループに所属する従業員（以下、「他グループ従業員」と記載する。）とを判別し、これらの従業員からの申請のうち、事後承認が得られていないもののデータを各従業員の勤務状況マスタ８５より抽出する（図２３の＃６０１）。事後承認の有無は、各申請に対応する勤務検印マスタ８６（図２１参照）の「事後承認ＦＮＮ」に示されている。なお、事前承認または事後承認が保留されている場合は、その日はその申請のデータを抽出せずに、翌日以降に抽出するようにしてもよい。この場合は、その「事前承認ＦＮＮ」および「事後承認ＦＮＮ」を、その日の最後のバッチ処理の際にリセットするのが望ましい。または、しばらくしてから抽出されるようにするために、数時間後にリセットしてもよい。

抽出した申請のうち自グループ従業員からの申請の内容を記載した未承認リストＬＴ６（図２４参照）を生成する（＃６０２）。未承認リストＬＴ６の背景色には、白色または淡色を用いる。自グループ従業員の社員番号および氏名などの文字色には、黒色を用いる。

他グループ従業員からの未承認の申請については、その他グループ従業員を担当する現認担当者の在席状態フラグの値に応じて色付けして未承認リストＬＴ６に追加する。在席状態フラグが「Ａ」の場合は（＃６０３でＹｅｓ、＃６０４でＹｅｓ）、その他グループ従業員を、行の背景色または文字色のいずれか一方を赤色にして追加する（＃６０５）。「Ｂ」の場合は（＃６０６でＹｅｓ）、黄色にして追加する（＃６０７）。「Ｃ」の場合は（＃６０８でＹｅｓ）、青色にして追加する（＃６０９）。「Ｄ」の場合は（＃６０８でＮｏ）、自グループ従業員と同じ背景色および文字色を用いて追加し、未承認リストＬＴ６の下に「○○○さんは離席中で現在のところ、承認操作されていません。」というような注意を促すメッセージを付加する（＃６１０）。

在席状態フラグが「Ａ」〜「Ｄ」のいずれの値をも示さない場合は（＃６０３でＮｏ）、自グループ従業員と同じ背景色および文字色を用いて未承認リストＬＴ６に追加する（＃６１１）。または、承認期限時刻までに承認すべき現認担当者が戻ってくる時間的な余裕があるので、追加しないようにしてもよい。このようにして図２４のような承認画面ＨＧ６の画面データが生成される。

図２２に戻って、図３の管理職画面送信部１６は、生成された画面データをその管理職員の管理職用端末装置３に送信する（＃５０４）。すると、その管理職用端末装置３のディスプレイには、承認画面ＨＧ６が表示される。なお、事前申請が既に与えられている申請の「事前申請」のチェックボタンは、オンになっている。

管理職員は、承認画面ＨＧ６を見て申請の内容を確認し、次のようにして承認を与える作業を行う。出勤した旨の申請である場合は、その従業員が社内にいることを確認（現認）して、その申請の行の「事前承認」のチェックボタンをクリックする。翌日以降（つまり予定）に関する申請に対して承認を与える場合は、その申請の行の「事前承認」のチェックボタンをクリックする。その日より前（つまり実績）に関する申請に対して承認を与える場合は、「事後承認」のチェックボタンをクリックする。すべての申請に対して事前承認または事後承認を与える場合は、事前一括承認ボタンＢＮ６２または事後一括承認ボタンＢＮ６３をクリックしてもよい。承認を保留する場合は「保留」のチェックボタンをクリックする。

承認の作業が終わったら、登録ボタンＢＮ６１をクリックする。すると、承認指令部３２は、これらの承認の内容を承認情報７２としてホスト１に送信し、承認を反映するための処理を実行するように指令する。

ホスト１の承認受付部１７は、承認情報７２を受信すると（＃５０５）、その承認情報７２に基づいて、データベース管理部１Ｄに対して、現認担当者が承認した事項を指定し、各申請に対応する勤務検印マスタ８６を更新するように指令する（＃５０６）。このようにして、勤務検印マスタ８６が更新される。

図２５は照会画面ＨＧ７の例を示す図である。図３の従業員画面送信部１３は、従業員初期画面ＨＧ４（図１８参照）の照会ボタンＢＮ４２がクリックされた場合は、ログオンしている従業員の勤務状況マスタ８５に基づいて図２５に示すような照会画面ＨＧ７の画面データを生成し、その従業員の従業員用端末装置２に送信する。

管理職画面送信部１６は、管理職初期画面ＨＧ１（図８参照）の申請入力ボタンＢＮ１４がクリックされた場合は、管理職者の勤務に関する事項を申請するための画面の画面データを送信する。その画面の構成は、図１９の申請入力画面ＨＧ５の構成と同じである。申請を受け付ける処理は、従業員の場合と同じである。照会ボタンＢＮ１５がクリックされた場合は、その管理職者の勤務状況などを示す照会画面ＨＧ７の画面データを送信する。また、その管理職者の配下にいる従業員が指定された場合は、その従業員の照会画面ＨＧ７の画面データを送信する。

図２６はホスト１の全体的な処理の流れの例を説明するフローチャートである。次に、ホスト１の一日の処理の流れについて、フローチャートを参照して説明する。

従業員は、出勤するとすぐに、その日の出勤時刻および退勤予定時刻などの勤務に関する申請を行う。このとき、ホスト１は、図１７で説明したような手順で、申請を受け付けるための処理を実行する（＃１）。

現認担当者（当番）に当たっている管理職員は、午前の承認期限時刻までに、蓄積されている、自分の担当するグループの従業員からの未承認の申請に対して承認を与える。未承認の申請として、ステップ＃１で受け付けられたその日の勤務に関する事前申請、前日の午後の承認処理以降に受け付けられた出張または休暇などの事前申請、前日またはそれ以前の日の残業が予定通りに終わらなかった場合にその旨を報告するための事後申請、および前日に保留された事前申請または事後申請などが蓄積されている。このとき、ホスト１は、図２２などで説明したような手順で、承認を記録するための処理を実行する（＃２）。なお、その管理職員は、同じ部に所属する他グループの現認担当者が承認の作業を行うことができない場合は、他グループについて承認の作業を代行する。その管理職員が承認の作業を行うことができない場合は、他の現認担当者が承認の作業を代行してくれる。

ホスト１は、ステップ＃１〜＃６の処理と並行して、定期的に（例えば、数分ごとに）、現認担当者の状態をチェックする（＃３）。係る処理は、図１４で説明したような手順で行われる。または、図２４の承認画面ＨＧ６の画面データを生成する際にチェックするようにしてもよい。そうすれば、現認担当者の、より新しい状態を知ることができる。

一旦承認を受けた従業員が急に残業をしなければならなくなったとする（＃４でＹｅｓ）。この場合は、その従業員は、その旨の申請（再申請）を行う。このとき、ホスト１は、図１７で説明したような手順で、前の申請の内容を今回の再申請の内容に書き換えるとともに、前の申請に対して与えていた承認を取り消す処理を実行する（＃５）。

現認担当者は、午後の承認期限時刻までに、再申請に対して承認を与える。このとき、ホスト１は、図２２で説明したような手順で、再度承認を記録するための処理を実行する（＃６）。また、従業員は、翌日以降の出張または休暇などの申請を、午前の承認処理以降に行うことがある（＃４でＹｅｓ）。ホスト１は、係る申請も、再申請とともに処理する（＃５、＃６）。

ホスト１は、一日の最後にバッチ処理を実行する（＃７）。この際に、必要に応じて、図１０で説明した現認担当者（当番）を割り当てる処理および図１１で説明した現認担当者を変更する処理などを実行する。なお、上に述べたように、残業が申請通りの時刻に終わらなかった場合は、従業員は翌日に事後申請を行い、翌日の現認担当者はその事後申請に対して事後承認を与える。

本実施形態によると、現認担当者の承認画面ＨＧ６（図２４参照）には、自分の担当するグループの申請内容とともに、他の現認担当者の未承認の申請の内容が承認期限時刻までの残り時間に応じて赤色、黄色、および青色などによって強調表示される。したがって、一部の現認担当者が離席しているときでも、在籍中の現認担当者は、離席中の現認担当者の担当すべき未承認の申請の内容を容易に把握し、承認を代行すべきか否かを容易に判断することができる。よって、現認制を採用する企業などにおいて、管理職員などの責任者は、従来よりも簡単に承認の処理を行うことができる。

また、従業員は、誰が承認担当者であるかを意識せずに、申請を行うことができる。よって、当番制を採用する企業などにおいて、従業員は、従来よりも簡単に申請の処理を行うことができる。

本実施形態では、承認担当者が在席しているか離席しているかを、スケジュールマスタ８３に基づいて判別したが、公知のシステムによって判別するようにしてもよい。例えば、タイムカードシステムまたは入退出用のセキュリティシステムなどを用いて判別してもよい。すなわち、企業Ａの施設に入場する際に承認担当者が自分の社員カードをカードリーダに読ませたタイミングで「在席中」と判別し、退場する際に社員カードをカードリーダに読ませたタイミングで「離席中」と判別するようにしてもよい。または、スケジュールマスタ８３とこれらのシステムとを組み合わせもよい。そして、例えば、企業Ａの施設にいる場合であっても会議の予定が入っている場合は「離席中」と判別するようにしてもよい。

出勤時の申請を、タイムカードシステムまたは入退出用のセキュリティシステムを用いて行うようにしてもよい。例えば、出勤時に従業員が自分の社員カードをカードリーダに読ませたタイミングで自動的に申請（申請情報７１）がホスト１に送信されるようにしてもよい。

本実施形態では、現認担当者を１日ごとに交替したが、数日ごと、１週間ごと、または１ヵ月ごとに交替するようにしてもよい。

本発明は、勤務に関する事項の申請および承認以外の目的にも適用することができる。例えば、倉庫への製品の出入の作業についての申請および承認のためにも適用することができる。この場合は、製品のグループごとに現認担当者を割り当ててもよい。または製品の製造についての申請および承認のためにも適用することができる。この場合は、製造のステップごとに現認担当者を割り当ててもよい。

その他、承認システム１００、ホスト１、従業員用端末装置２、管理職用端末装置３の全体または各部の構成、処理内容、処理順序などは、本発明の趣旨に沿って適宜変更することができる。また、承認システム１００の運用形態は、承認システム１００を使用する職場の規則などに応じて適宜変更することができる。

以上説明した実施形態に関し、さらに以下の付記を開示する。
（付記１）作業に関する事項を承認するための承認システムであって、
前記事項の属性ごとに承認者となるべき承認担当者を記憶する承認担当者記憶手段と、
前記事項を承認すべき旨の申請を受け付ける申請受付手段と、
前記承認担当者が使用する表示装置に、受け付けられた前記申請に係る未承認の前記事項のうち、当該承認担当者が承認者となるべき事項とともに、他の承認担当者が承認者となるべきでありかつ承認すべき期限を過ぎた事項、他の承認担当者が承認者となるべきでありかつ前記期限が所定の時間にまで迫っている事項、または離席中である他の承認担当者が承認者となるべき事項、を示す一覧画面を表示させるための表示制御手段と、
前記一覧画面に示される前記事項の中から前記承認担当者が承認した事項を指定する承認指定手段と、
指定された前記事項を示す承認済事項情報を記憶する承認済事項記憶手段と、
を有することを特徴とする承認システム。
（付記２）勤務に関する事項を承認するための承認システムであって、
グループごとに、当該グループに所属する従業員の前記事項の承認者となるべき承認担当者を記憶する承認担当者記憶手段と、
従業員から前記事項を承認すべき旨の申請を受け付ける申請受付手段と、
前記承認担当者が使用する表示装置に、受け付けられた前記申請に係る未承認の前記事項のうち、当該承認担当者が承認者となるべき事項とともに、他の承認担当者が承認者となるべきでありかつ承認すべき期限を過ぎた事項、他の承認担当者が承認者となるべきでありかつ前記期限が所定の時間にまで迫っている事項、または離席中である他の承認担当者が承認者となるべきである事項、を示す一覧画面を表示させるための表示制御手段と、
前記一覧画面に示される前記事項の中から承認した事項を指定する承認指定手段と、
指定された前記事項を示す承認済事項情報を記憶する承認済事項記憶手段と、
を有することを特徴とする承認システム。
（付記３）前記表示制御手段は、前記承認担当者が使用する表示装置に、前記一覧画面を、当該承認担当者が承認者となるべき事項、他の承認担当者が承認者となるべきでありかつ承認すべき期限を過ぎた事項、および他の承認担当者が承認者となるべきでありかつ前記期限が所定の時間にまで迫っている事項を、互いに異なる属性のフォントまたは背景色を用いて表示する、
付記２記載の承認システム。
（付記４）前記承認済事項記憶手段は、訂正された、承認済の前記事項の前記申請が受け付けられた場合に、当該事項が未承認である旨を示すように前記承認済情報を更新する、
付記２または付記３記載の承認システム。
（付記５）承認者になる資格を有する者の予定情報を記憶する予定情報記憶手段と、
前記予定情報に基づいて所定の期間ごとの前記承認担当者を決定する承認者担当者決定手段と、を有し、
前記承認担当者記憶手段は、決定された前記所定の期間ごとの前記承認担当者を記憶する、
付記２ないし付記４のいずれかに記載の承認システム。
（付記６）勤務に関する事項を承認するための承認システムであって、
グループごとに、当該グループに所属する従業員の前記事項の承認者となるべき承認担当者を記憶する承認担当者記憶手段と、
前記事項を遂行することを承認すべき旨の申請である事前申請と前記事項が遂行されたことを承認すべき旨の申請である事後申請とを受け付ける申請受付手段と、
前記承認担当者が使用する表示装置に、受け付けられた前記事前申請に係る未承認の前記事項および前記事後申請に係る未承認の前記事項のうち、当該承認担当者が承認者となるべき事項とともに、他の承認担当者が承認者となるべきでありかつ承認すべき期限を過ぎた事項、他の承認担当者が承認者となるべきでありかつ前記期限が所定の時間にまで迫っている事項、または離席中である他の承認担当者が承認者となるべきである事項、を示す一覧画面を表示させるための表示制御手段と、
前記一覧画面に示される前記事前申請に係る前記事項および前記事後申請に係る前記事項の中から承認した事項を指定する承認指定手段と、
前記承認指定手段による指定結果に基づいて、遂行することが承認された前記事項および遂行されたことが承認された前記事項を示す承認済情報を記憶する承認済事項記憶手段と、
を有することを特徴とする承認システム。
（付記７）作業に関する事項を承認するための承認方法であって、
前記事項の属性ごとに承認者となるべき承認担当者を承認担当者記憶手段に記憶させておき、
前記事項を承認すべき旨の申請を受け付けるステップと、
前記承認担当者が使用する表示装置に、受け付けられた前記申請に係る未承認の前記事項のうち、当該承認担当者が承認者となるべき事項とともに、他の承認担当者が承認者となるべきでありかつ承認すべき期限を過ぎた事項、他の承認担当者が承認者となるべきでありかつ前記期限が所定の時間にまで迫っている事項、または離席中である他の承認担当者が承認者となるべき事項、を示す一覧画面を表示させるステップと、
前記一覧画面に示される前記事項の中から前記承認担当者が承認した事項を指定するのを受け付けるステップと、
前記承認担当者によって指定された前記事項を示す承認済事項情報を承認済事項記憶手段に記憶させるステップと、
を実行することを特徴とする承認方法。
（付記８）作業に関する事項を承認するためのコンピュータに用いられるコンピュータプログラムであって、
前記事項の属性ごとに承認者となるべき承認担当者を記憶する承認担当者記憶手段にアクセスする処理と、
前記事項を承認すべき旨の申請を受け付ける処理と、
前記承認担当者が使用する表示装置に、受け付けられた前記申請に係る未承認の前記事項のうち、当該承認担当者が承認者となるべき事項とともに、他の承認担当者が承認者となるべきでありかつ承認すべき期限を過ぎた事項、他の承認担当者が承認者となるべきでありかつ前記期限が所定の時間にまで迫っている事項、または離席中である他の承認担当者が承認者となるべき事項、を示す一覧画面を表示させるための処理と、
前記一覧画面に示される前記事項の中から前記承認担当者が承認した事項を指定するのを受け付ける処理と、
前記承認担当者によって指定された前記事項を示す承認済事項情報を承認済事項記憶手段に記憶させる処理と、
をコンピュータに実行させるためのコンピュータプログラム。

本発明は、特に、現認制を採用する職場での従業員の勤怠管理のために好適に用いられる。

承認システムの全体的な構成の例を示す図である。企業Ａの部署の構成の例を示す図である。ホスト、従業員用端末装置、および管理職用端末装置の機能的構成の例を示す図である。データベース管理部の構成の例を示す図である。従業員マスタの例を示す図である。人事異動マスタの例を示す図である。スケジュールマスタの例を示す図である。管理職初期画面の例を示す図である。現認者割当マスタのフィールドの構成の例を示す図である。現認当番月次割当処理の流れの例を説明するフローチャートである。現認当番入替処理の流れの例を説明するフローチャートである。現認者管理画面の例を示す図である。当番変更画面の例を示す図である。在席フラグ更新処理の例を示す図である。勤務状況マスタのフィールドの構成の例を示す図である。申請に関する内容を格納するフィールドの構成の例を示す図である。申請処理の流れの例を説明するフローチャートである。従業員初期画面の例を示す図である。申請入力画面の例を示す図である。プルダウンメニューの例を示す図である。勤務検印マスタの例を示す図である。承認処理の流れの例を説明するフローチャートである。画面データ生成処理の流れの例を説明するフローチャートである。承認画面の例を示す図である。照会画面の例を示す図である。ホストの全体的な処理の流れの例を説明するフローチャートである。

符号の説明

１００承認システム
１４申請受付部（申請受付手段）
１６管理職画面送信部（表示制御手段）
１７承認受付部（承認指定手段）
７１申請情報
７２承認情報
８４現認者割当マスタ（承認担当者記憶手段）
８６勤務検印マスタ（承認済事項記憶手段）
ＨＧ６承認画面（一覧画面）

Claims

作業に関する事項を承認するための承認システムであって、
前記事項の属性ごとに承認者となるべき承認担当者を記憶する承認担当者記憶手段と、
前記事項を承認すべき旨の申請を受け付ける申請受付手段と、
前記承認担当者が使用する表示装置に、受け付けられた前記申請に係る未承認の前記事項のうち、当該承認担当者が承認者となるべき事項とともに、他の承認担当者が承認者となるべきでありかつ承認すべき期限を過ぎた事項、他の承認担当者が承認者となるべきでありかつ前記期限が所定の時間にまで迫っている事項、または離席中である他の承認担当者が承認者となるべき事項、を示す一覧画面を表示させるための表示制御手段と、
前記一覧画面に示される前記事項の中から前記承認担当者が承認した事項を指定する承認指定手段と、
指定された前記事項を示す承認済事項情報を記憶する承認済事項記憶手段と、
を有することを特徴とする承認システム。
勤務に関する事項を承認するための承認システムであって、
グループごとに、当該グループに所属する従業員の前記事項の承認者となるべき承認担当者を記憶する承認担当者記憶手段と、
従業員から前記事項を承認すべき旨の申請を受け付ける申請受付手段と、
前記承認担当者が使用する表示装置に、受け付けられた前記申請に係る未承認の前記事項のうち、当該承認担当者が承認者となるべき事項とともに、他の承認担当者が承認者となるべきでありかつ承認すべき期限を過ぎた事項、他の承認担当者が承認者となるべきでありかつ前記期限が所定の時間にまで迫っている事項、または離席中である他の承認担当者が承認者となるべきである事項、を示す一覧画面を表示させるための表示制御手段と、
前記一覧画面に示される前記事項の中から承認した事項を指定する承認指定手段と、
指定された前記事項を示す承認済事項情報を記憶する承認済事項記憶手段と、
を有することを特徴とする承認システム。
前記表示制御手段は、前記承認担当者が使用する表示装置に、前記一覧画面を、当該承認担当者が承認者となるべき事項、他の承認担当者が承認者となるべきでありかつ承認すべき期限を過ぎた事項、および他の承認担当者が承認者となるべきでありかつ前記期限が所定の時間にまで迫っている事項を、互いに異なる属性のフォントまたは背景色を用いて表示する、
請求項２記載の承認システム。
作業に関する事項を承認するための承認方法であって、
前記事項の属性ごとに承認者となるべき承認担当者を承認担当者記憶手段に記憶させておき、
前記事項を承認すべき旨の申請を受け付けるステップと、
前記承認担当者が使用する表示装置に、受け付けられた前記申請に係る未承認の前記事項のうち、当該承認担当者が承認者となるべき事項とともに、他の承認担当者が承認者となるべきでありかつ承認すべき期限を過ぎた事項、他の承認担当者が承認者となるべきでありかつ前記期限が所定の時間にまで迫っている事項、または離席中である他の承認担当者が承認者となるべき事項、を示す一覧画面を表示させるステップと、
前記一覧画面に示される前記事項の中から前記承認担当者が承認した事項を指定するのを受け付けるステップと、
前記承認担当者によって指定された前記事項を示す承認済事項情報を承認済事項記憶手段に記憶させるステップと、
を有することを特徴とする承認方法。
作業に関する事項を承認するためのコンピュータに用いられるコンピュータプログラムであって、
前記事項の属性ごとに承認者となるべき承認担当者を記憶する承認担当者記憶手段にアクセスする処理と、
前記事項を承認すべき旨の申請を受け付ける処理と、
前記承認担当者が使用する表示装置に、受け付けられた前記申請に係る未承認の前記事項のうち、当該承認担当者が承認者となるべき事項とともに、他の承認担当者が承認者となるべきでありかつ承認すべき期限を過ぎた事項、他の承認担当者が承認者となるべきでありかつ前記期限が所定の時間にまで迫っている事項、または離席中である他の承認担当者が承認者となるべき事項、を示す一覧画面を表示させるための処理と、
前記一覧画面に示される前記事項の中から前記承認担当者が承認した事項を指定するのを受け付ける処理と、
前記承認担当者によって指定された前記事項を示す承認済事項情報を承認済事項記憶手段に記憶させる処理と、
をコンピュータに実行させるためのコンピュータプログラム。