権限管理システム、権限管理方法及び権限管理プログラム
【課題】申請についての決裁権限を的確に管理するための権限管理システム、権限管理方法及び権限管理プログラムを提供する。
【解決手段】申請管理サーバ２０の制御部２１は、本来の権限者が他の社員に権限を委譲するための権限委譲登録処理を実行する。決裁者登録処理においては、制御部２１は、カテゴリに基づいて権限者候補を抽出し、クライアント端末１０から、申請を行なう可能性がある社員が選択したデフォルト決裁者情報を取得し、決裁者登録データ記憶部２４に記録する。申請受付処理において、申請内容に基づいて、デフォルト決裁者を含めた決裁者候補を抽出するとともに、デフォルト決裁者の勤怠情報を取得する。そして、申請者は勤怠情報に基づいて決裁者を決定する。そして、制御部２１は、定期的に決裁依頼を送信する。急ぎの申請がある場合や決裁依頼内容の確認負荷が大きくなっている場合にも決裁者に対して通知する。
【解決手段】申請管理サーバ２０の制御部２１は、本来の権限者が他の社員に権限を委譲するための権限委譲登録処理を実行する。決裁者登録処理においては、制御部２１は、カテゴリに基づいて権限者候補を抽出し、クライアント端末１０から、申請を行なう可能性がある社員が選択したデフォルト決裁者情報を取得し、決裁者登録データ記憶部２４に記録する。申請受付処理において、申請内容に基づいて、デフォルト決裁者を含めた決裁者候補を抽出するとともに、デフォルト決裁者の勤怠情報を取得する。そして、申請者は勤怠情報に基づいて決裁者を決定する。そして、制御部２１は、定期的に決裁依頼を送信する。急ぎの申請がある場合や決裁依頼内容の確認負荷が大きくなっている場合にも決裁者に対して通知する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、申請についての決裁権限を管理するための権限管理システム、権限管理方法及び権限管理プログラムに関する。
【背景技術】
【０００２】
企業等の組織内における決裁処理において電子ワークフローシステムが利用されることがある。この電子ワークフローシステムにおいては、申請者により作成された各種申請が、ネットワークを介して電子的に回覧され、承認可否についての確認作業が行なわれている。しかし、内容を確認する必要がある申請が特定の権限者に集中した場合、確認作業の負荷が大きくなるとともに、決裁処理が遅れることがある。
【０００３】
そこで、決裁の権限者が他者に権限を委譲して決裁処理を分散することもある。そこで、文書の決裁者が、決裁権限を委譲する場合を考慮した電子文書回覧システムが検討されている（例えば、特許文献１参照）。この文献に記載された電子文書回覧システムにおいては、予め電子文書を回覧する決裁経路を設定しておく。電子文書の作成者が、文書作成後、決裁や決裁を依頼する回覧者または決裁者が選択された場合、権限委譲前の決裁者かどうか判断する。権限委譲前の決裁者である場合は、権限委譲前の決裁者であることを示す識別表示するとともに決裁経路に設定する。
【０００４】
また、組織改編等があった場合にも、電子ドキュメントを確実に管理するための文書管理装置も検討されている（例えば、特許文献２参照）。この文献に記載された文書管理装置は、電子ドキュメントを管理する場合、管理情報として、電子ドキュメントのＩＤに関連付けて権限者の情報を格納する。権限者は、電子ドキュメントの改版等の作業をすることができるようにする。人事異動等により、権限者が電子ドキュメントを管理する立場から離れた場合には、次の権限者に電子ドキュメントの管理権限を委譲する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−２１２７３号公報（第１頁、図２）
【特許文献２】国際公開第２００６／１３７１２４号公報（第１頁、図９）
【発明の概要】
【発明が解決しようとする課題】
【０００６】
権限を設定する場合、特許文献１に記載されているように、権限者本人のみが決裁することができる専決とする場合もある。しかし、専決とすると、この権限者が不在の場合には、決裁依頼内容の確認作業が遅れることもある。特に、決裁に期限が設けられている場合には、この期限を考慮して確認を行なう必要がある。そこで、負荷分散を図るために、権限委譲により複数の権限者（本来の権限者及び権限委譲を受けた権限者）が設定されることがある。また、本来の権限者が複数、存在している場合もある。この場合、決裁依頼内容を確認する権限者（決裁者）を特定する必要がある。また、複数の権限者が設定されている場合、申請者においても、各種申請の決裁者を選択したい場合がある。
【０００７】
更に、企業内においては、頻繁に人事異動が行なわれる場合もある。このような人事異動の中で、権限者が異動する場合にも、円滑に決裁を引き継げることが望ましい。
本発明は、上記課題を解決するためになされたものであり、申請についての決裁権限を的確に管理するための権限管理システム、権限管理方法及び権限管理プログラムを提供することにある。
【課題を解決するための手段】
【０００８】
上記問題点を解決するために、請求項１に記載の発明は、申請内容に対応した決裁権限を有する権限者と、その決裁権限の委譲先についての権限情報を記憶した権限管理情報記憶手段と、各申請について決裁を行なうデフォルト決裁者情報を記憶した決裁者登録情報記憶手段と、申請についての決裁を管理する制御手段とを備えた権限管理システムであって、前記制御手段が、クライアント端末からアクセスした権限者を認証し、前記権限者において申請内容に対応させて決裁権限を委譲できる委譲先候補者を特定して前記クライアント端末に出力する手段と、前記委譲先候補者の中で選択された利用者に対して、前記権限管理情報記憶手段において、前記申請内容の決裁権限が委譲された権限者として登録を行なう手段と、クライアント端末からアクセスした申請者を認証し、前記クライアント端末から取得した申請内容に基づいて、前記権限管理情報記憶手段において、決裁を行なうことができる権限者を特定し、決裁者候補として前記クライアント端末に出力する手段と、前記決裁者候補の中で選択された権限者を、前記申請内容についてのデフォルト決裁者として、前記決裁者登録情報記憶手段に登録する手段とを備えたことを要旨とする。
【０００９】
請求項２に記載の発明は、請求項１に記載の権限管理システムにおいて、各申請について決裁者が登録された申請管理情報を記憶する申請管理情報記憶手段を更に備え、前記制御手段は、各権限者の勤怠情報を記憶した勤怠管理システムに接続されており、前記制御手段が、クライアント端末からアクセスした申請者を認証し、前記クライアント端末から申請を取得した場合、前記決裁者登録情報記憶手段を用いてデフォルト決裁者を特定し、前記デフォルト決裁者の勤怠情報を前記勤怠管理システムから取得して、前記クライアント端末に出力し、前記クライアント端末から取得した決裁者情報を含めた申請管理情報を前記申請管理情報記憶手段に記録する手段を更に備えたことを要旨とする。
【００１０】
請求項３に記載の発明は、請求項２に記載の権限管理システムにおいて、前記制御手段が、前記勤怠情報により、前記デフォルト決裁者により決裁判断ができないと判定した場合、前記権限管理情報記憶手段に記録された他の権限者を、前記申請の決裁者として前記申請管理情報記憶手段に登録する手段を更に備えたことを要旨とする。
【００１１】
請求項４に記載の発明は、請求項３に記載の権限管理システムにおいて、前記勤怠情報において、申請の決裁期限までに前記デフォルト決裁者の出勤予定がない場合に、前記デフォルト決裁者により決裁判断ができないと判定することを要旨とする。
【００１２】
請求項５に記載の発明は、請求項２〜４のいずれか一つに記載の権限管理システムにおいて、前記制御手段が、前記申請内容に応じて、前記申請管理情報記憶手段に記録された申請の決裁者毎に、申請された決裁依頼内容を確認するための負荷を計算する手段と、前記負荷が基準値を超えた場合に、前記決裁者に対して申請があったことを通知する手段とを更に備えたことを要旨とする。
【００１３】
請求項６に記載の発明は、請求項１〜５のいずれか一つに記載の権限管理システムにおいて、前記制御手段が、委譲元の権限者についての異動情報を取得した場合には、前記権限管理情報記憶手段に記憶された権限者の権限に対して、有効期間として引継期間を設定する手段を更に備えたことを要旨とする。
【００１４】
請求項７に記載の発明は、請求項１〜６のいずれか一つに記載の権限管理システムにおいて、前記制御手段が、委譲元の権限者についての異動情報を取得した場合には、前記権限管理情報記憶手段に記憶された委譲元の権限者を、前記異動情報に基づいて新たな権限者に変更する手段を更に備えたことを要旨とする。
【００１５】
請求項８に記載の発明は、請求項１〜７のいずれか一つに記載の権限管理システムにおいて、前記制御手段が、委譲先の権限者についての異動情報を取得した場合には、前記権限管理情報記憶手段に記憶された委譲先の権限を抹消する手段を更に備えたことを要旨とする。
【００１６】
請求項９に記載の発明は、申請内容に対応した決裁権限を有する権限者と、その決裁権限の委譲先についての権限情報を記憶した権限管理情報記憶手段と、各申請について決裁を行なうデフォルト決裁者情報を記憶した決裁者登録情報記憶手段と、申請についての決裁を管理する制御手段とを備えた権限管理システムを用いて、申請を管理するための方法であって、前記制御手段が、クライアント端末からアクセスした権限者を認証し、前記権限者において申請内容に対応させて決裁権限を委譲できる委譲先候補者を特定して前記クライアント端末に出力する段階と、前記委譲先候補者の中で選択された利用者に対して、前記権限管理情報記憶手段において、前記申請内容の決裁権限が委譲された権限者として登録を行なう段階と、クライアント端末からアクセスした申請者を認証し、前記クライアント端末から取得した申請内容に基づいて、前記権限管理情報記憶手段において、決裁を行なうことができる権限者を特定し、決裁者候補として前記クライアント端末に出力する段階と、前記決裁者候補の中で選択された権限者を、前記申請内容についてのデフォルト決裁者として、前記決裁者登録情報記憶手段に登録する段階とを実行することを要旨とする。
【００１７】
請求項１０に記載の発明は、申請内容に対応した決裁権限を有する権限者と、その決裁権限の委譲先についての権限情報を記憶した権限管理情報記憶手段と、各申請について決裁を行なうデフォルト決裁者情報を記憶した決裁者登録情報記憶手段と、申請についての決裁を管理する制御手段とを備えた権限管理システムを用いて、申請を管理するためのプログラムであって、前記制御手段を、クライアント端末からアクセスした権限者を認証し、前記権限者において申請内容に対応させて決裁権限を委譲できる委譲先候補者を特定して前記クライアント端末に出力する手段、前記委譲先候補者の中で選択された利用者に対して、前記権限管理情報記憶手段において、前記申請内容の決裁権限が委譲された権限者として登録を行なう手段、クライアント端末からアクセスした申請者を認証し、前記クライアント端末から取得した申請内容に基づいて、前記権限管理情報記憶手段において、決裁を行なうことができる権限者を特定し、決裁者候補として前記クライアント端末に出力する手段、前記決裁者候補の中で選択された権限者を、前記申請内容についてのデフォルト決裁者として、前記決裁者登録情報記憶手段に登録する手段として機能させることを要旨とする。
【００１８】
（作用）
請求項１、９又は１０に記載の発明によれば、制御手段が、クライアント端末からアクセスした権限者を認証し、権限者において申請内容に対応させて決裁権限を委譲できる委譲先候補者を特定してクライアント端末に出力する。そして、委譲先候補者の中で選択された利用者に対して、権限管理情報記憶手段において、申請内容の決裁権限が委譲された権限者として登録を行なう。更に、クライアント端末からアクセスした申請者を認証し、クライアント端末から取得した申請内容に基づいて、権限管理情報記憶手段において、決裁を行なうことができる権限者を特定し、決裁者候補としてクライアント端末に出力する。そして、決裁者候補の中で選択された権限者を、申請内容についてのデフォルト決裁者として、決裁者登録情報記憶手段に登録する。これにより、権限の委譲先を設定し、申請者側で権限者候補の中から決裁者を選択することができる。
【００１９】
請求項２に記載の発明によれば、制御手段が、クライアント端末からアクセスした申請者を認証し、クライアント端末から申請を取得した場合、決裁者登録情報記憶手段を用いてデフォルト決裁者を特定する。そして、デフォルト決裁者の勤怠情報を勤怠管理システ
ムから取得して、クライアント端末に出力し、クライアント端末から取得した決裁者情報を含めた申請管理情報を申請管理情報記憶手段に記録する。これにより、決裁者の勤怠情報を考慮して、決裁者を決定することができることができる。
【００２０】
請求項３に記載の発明によれば、制御手段が、勤怠情報により、デフォルト決裁者により決裁判断ができないと判定した場合、権限管理情報記憶手段に記録された他の権限者を、申請の決裁者として申請管理情報記憶手段に登録する。これにより、勤怠情報に応じて他の権限者が決裁することができる。
【００２１】
請求項４に記載の発明によれば、勤怠情報において、申請の決裁期限までに前記デフォルト決裁者の出勤予定がない場合に、前記デフォルト決裁者により決裁判断ができないと判定する。一方、申請の決裁期限までにデフォルト決裁者が決裁判断不可と判定した場合には、権限管理情報記憶手段に記録された他の権限者を決裁者として登録する。これにより、決裁期限を考慮して決裁者を決定することができる。
【００２２】
請求項５に記載の発明によれば、制御手段が、申請内容に応じて、申請管理情報記憶手段に記録された申請の決裁者毎に、申請された決裁依頼内容を確認するための負荷を計算する。そして、負荷が基準値を超えた場合に、決裁者に対して申請があったことを通知する。決裁者に対して申請毎に通知を受けると、決裁者にとって煩雑になることがある。一方、多くの申請についてまとめて通知すると、確認作業の負荷が過大になることがある。そこで、決裁者の負荷を考慮して、所定の申請数にまとめて決裁依頼を通知することができる。
【００２３】
請求項６に記載の発明によれば、制御手段が、委譲元の権限者についての異動情報を取得した場合には、権限管理情報記憶手段に記憶された権限者の権限に対して、有効期間として引継期間を設定する。これにより、本来の権限者の人事異動があった場合にも、引き継ぎ期間を考慮して、権限管理を行なうことができる。
【００２４】
請求項７に記載の発明によれば、制御手段が、委譲元の権限者についての異動情報を取得した場合には、権限管理情報記憶手段に記憶された委譲元の権限者を、異動情報に基づいて新たな権限者に変更する。これにより、本来の権限者の人事異動があった場合にも、委譲された権限を維持することができる。
【００２５】
請求項８に記載の発明によれば、制御手段が、委譲先の権限者についての異動情報を取得した場合には、権限管理情報記憶手段に記憶された委譲先の権限を抹消する。これにより、委譲されていた権限を抹消することがきる。
【発明の効果】
【００２６】
本発明によれば、申請についての決裁権限を的確に管理することができる。
【図面の簡単な説明】
【００２７】
【図１】本発明の実施形態のシステム概略図。
【図２】本実施形態で用いるデータの説明図であって、（ａ）は組織表管理データ記憶部、（ｂ）は権限管理データ記憶部、（ｃ）は決裁者登録データ記憶部、（ｄ）は申請管理データ記憶部に記録されたデータの説明図。
【図３】本実施形態の処理手順の説明図。
【図４】本実施形態の処理手順の説明図。
【図５】本実施形態の処理手順の説明図。
【図６】本実施形態の処理手順の説明図。
【図７】本実施形態の処理手順の説明図。
【図８】他の実施形態の処理手順の説明図。
【図９】他の実施形態の処理手順の説明図。
【図１０】他の実施形態の処理手順の説明図。
【発明を実施するための形態】
【００２８】
以下、本発明を具体化した一実施形態を、図１〜図７に従って説明する。本実施形態では、組織（会社）内の構成員（社員）が提出した申請についての決裁を行なう権限を管理するために用いる権限管理システム、権限管理方法及び権限管理プログラムとして説明する。以下では、「利用者」は本システムの利用者であり、申請者、決裁者のいずれも含まれる。「申請者」は、申請を行なう者を示しており、権限者は決裁権限を有する者を示す。本来の権限者から権限を委譲された者も、権限者に含まれる。「決裁者」は、権限者の中で申請者によって選択されて、申請の決裁を行なう者を示す。
【００２９】
本実施形態では、図１に示すように、申請の決裁を行なう権限を管理するために、権限管理システムとしての申請管理サーバ２０を用いる。この申請管理サーバ２０は、ネットワークを介して、クライアント端末１０、人事管理サーバ３０、勤怠管理サーバ４０に接続される。
【００３０】
クライアント端末１０は、申請者や権限者（決裁者を含む）等の社員が用いるコンピュータ端末（申請者端末、権限者端末）である。申請者は、このクライアント端末１０を用いて、各種申請を作成する。権限者は、このクライアント端末１０を用いて、決裁依頼内容を確認する。そして、決裁者は、決裁依頼内容に基づいて、承認入力、差し戻し入力、却下入力等を行なう。このクライアント端末１０は、図示しないディスプレイ等から構成された表示部や、キーボードやポインティングデバイス等から構成された入力部を備える。
【００３１】
申請管理サーバ２０は、各種申請の権限管理処理や、申請者による申請処理、決裁者による決裁処理を支援するためのサーバコンピュータである。この申請管理サーバ２０は、制御部２１、組織表管理データ記憶部２２、権限管理情報記憶手段としての権限管理データ記憶部２３、決裁者登録情報記憶手段としての決裁者登録データ記憶部２４、申請管理情報記憶手段としての申請管理データ記憶部２５を備えている。
【００３２】
ここで、制御部２１は、ＣＰＵ、ＲＡＭ、ＲＯＭ（図示せず）等から構成された制御手段を備えており、後述する処理（利用者認証段階、委譲登録段階、決裁者登録段階、申請受付段階、決裁者決定段階、決裁管理段階、申請通知段階、異動管理段階等の各処理）を行なう。そして、制御部２１は、図１に示すように、権限管理プログラムの実行により、利用者認証手段２１１、委譲登録手段２１２、決裁者登録手段２１３、申請受付手段２１４、決裁者情報取得手段２１５、決裁管理手段２１６、申請通知手段２１７、異動管理手段２１８として機能する。
【００３３】
利用者認証手段２１１は、クライアント端末１０から利用者を認証する処理を実行する。この利用者認証手段２１１は、クライアント端末１０から、利用者の認証情報（社員コード及びパスワード）を取得する。更に、利用者認証手段２１１は、図示しない利用者管理データ記憶部から、各利用者の認証情報（社員コード及びパスワード）を取得する。そして、クライアント端末１０から取得した認証情報と比較することにより、アクセスした社員を特定する。
【００３４】
委譲登録手段２１２は、各種申請についての決裁権限の委譲を管理する処理を実行する。本実施形態では、後述するように、権限者が委譲する対象の社員を登録する場合の処理を支援する。
【００３５】
決裁者登録手段２１３は、各社員の申請を決裁する社員（決裁者）を登録する処理を実行する。本実施形態では、後述するように、申請を行なう可能性がある社員が、予め決裁者を登録する場合の処理を支援する。
【００３６】
申請受付手段２１４は、各社員からの申請を受け付ける処理を実行する。この申請受付手段２１４は、各種申請の申請内容に対して、この申請内容が属するカテゴリを関連付けたカテゴリ管理テーブルを備えている。本実施形態のカテゴリには、「人事」、「勤怠」、「費用」等があり、例えば、申請内容「休暇申請」は「勤怠」のカテゴリに属し、申請内容「旅費精算」は「費用」のカテゴリに属する。
【００３７】
決裁者情報取得手段２１５は、後述するように、各申請の申請者毎に記憶された決裁者に関する情報を取得する処理を実行する。
決裁管理手段２１６は、決裁者からの指示に基づいて、各申請についての決裁管理を行なう処理を実行する。
【００３８】
申請通知手段２１７は、申請があったことを各決裁者に通知する処理を実行する。申請通知手段２１７は、利用者管理データ記憶部から、各社員コードに関連付けた連絡先（例えば、メールアドレス）を取得する。また、申請通知手段２１７は、決裁者に対して、申請の有無を定期的に通知する定期通知時刻（例えば、毎日１５時）に関するデータを保持している。また、申請通知手段２１７は、決裁期限までの猶予期間の長さを評価するための猶予基準値に関するデータを保持している。更に、申請通知手段２１７は、申請内容毎に、決裁者が内容を確認するための負荷を評価した値（負荷加重値）を記録した負荷評価テーブルを保持している。そして、申請通知手段２１７は、決裁者の確認作業の負荷を評価するための負荷基準値に関するデータを保持している。
【００３９】
異動管理手段２１８は、人事異動を取得した場合に、権限者の登録を更新する処理を実行する。この異動管理手段２１８は、異動者に対して決裁を引き継ぐ期間を付与するために、引継ぎ日数に関するデータを保持している。
【００４０】
組織表管理データ記憶部２２は、図２（ａ）に示すように、この組織（会社）の構成員（社員）の所属組織を管理するための組織表管理レコード２２０を記憶する。この組織表管理レコード２２０は、人事管理により決定された組織表が登録された場合に記録される。この組織表管理レコード２２０は、社員コード、部署コード、役職コード、資格コードに関するデータを含んで構成される。
【００４１】
社員コードデータ領域には、各社員を特定するための識別子に関するデータが記録される。
部署コードデータ領域には、この社員が属する部署を特定するための識別子に関するデータが記録される。
【００４２】
役職コードデータ領域には、この組織における役割を特定するための識別子に関するデータが記録される。
資格コードデータ領域には、この社員の資格を特定するための識別子に関するデータが記録される。この資格により、この組織における申請の決裁権限を付与できる範囲を特定することができる。
【００４３】
権限管理データ記憶部２３は、図２（ｂ）に示すように、各組織における決裁権限を有する社員に関する権限管理レコード２３０を記憶する。この権限管理レコード２３０は、人事情報に基づいて役職や資格が登録された場合や、権限の委譲が登録された場合に記録
される。この権限管理レコード２３０は、本来権限者、部署コード、カテゴリ、委譲先、委譲条件、有効期間に関するデータを含んで構成される。
【００４４】
本来権限者データ領域には、本来の決裁権限を有する社員（委譲元の権限者）を特定するための識別子（社員コード）に関するデータが記録される。そして、この権限者が、他の社員に対して、権限を委譲することができる。
【００４５】
部署コードデータ領域には、この本来権限者が決裁権限を有している組織を特定するための識別子に関するデータが記録される。
カテゴリデータ領域には、この本来権限者が決裁権限を有している各種申請を含むカテゴリを特定するための識別子に関するデータが記録される。本実施形態では、カテゴリとして「人事」、「勤怠」、「費用」を用いる。
【００４６】
委譲先データ領域には、本来権限者によって権限が委譲された社員を特定するための識別子（社員コード）に関するデータが記録される。
委譲条件データ領域には、この権限委譲先において決裁を行なうことができる条件に関するデータが記録される。本実施形態では、委譲先において、常時決裁を許容する場合と、本来の決裁者が不在の場合のみ権限を委譲する場合とを識別するためのフラグ（常時委譲フラグ又は不在時委譲フラグ）が記録される。
有効期間データ領域には、本来権限者の権限の有効期間に関するデータが記録される。
【００４７】
決裁者登録データ記憶部２４は、図２（ｃ）に示すように、各社員からの申請の決裁者に関する決裁者登録レコード２４０を記憶する。この決裁者登録レコード２４０は、各社員によって、決裁者の登録処理が行なわれた場合に記録される。この決裁者登録レコード２４０は、社員コード、カテゴリ、決裁者に関するデータを含んで構成される。
【００４８】
社員コードデータ領域には、各種申請を行なう社員を特定するための識別子に関するデータが記録される。
カテゴリデータ領域には、申請の種類を特定するための識別子に関するデータが記録される。
【００４９】
決裁者データ領域には、このカテゴリにおいて、この社員の申請についての決裁を行なう決裁者（デフォルト決裁者）を特定するための識別子（社員コード）に関するデータが記録される。なお、デフォルト決裁者が登録されていない場合には、この決裁者データ領域は空欄となる。
【００５０】
申請管理データ記憶部２５は、図２（ｄ）に示すように、社員から受け付けた申請を管理するための申請管理レコード２５０を記憶する。この申請管理レコード２５０は、申請者のクライアント端末１０から申請を受け付けた場合に記録される。この申請管理レコード２５０は、申請受付コード、申請者、カテゴリ、決裁依頼内容、決裁期限、決裁者、ステータス、履歴に関するデータを含んで構成される。
【００５１】
申請受付コードデータ領域には、受け付けた各申請を特定するための識別子に関するデータが記録される。
申請者データ領域には、この申請を行なった社員（申請者）を特定するための識別子（社員コード）に関するデータが記録される。
【００５２】
カテゴリデータ領域には、この申請内容の種類を特定するための識別子に関するデータが記録される。
決裁依頼内容データ領域には、この申請内容や、この申請において決裁を依頼する内容
に関するデータが記録される。決裁者は、この内容を確認して承認要否を決定する。
【００５３】
決裁期限データ領域には、この申請についての決裁を行なう期限を特定するための識別子に関するデータが記録される。
決裁者データ領域には、この申請についての決裁を行なう社員（決裁者）を特定するための識別子に関するデータが記録される。
【００５４】
ステータスデータ領域には、この申請についての状況を特定するための識別子に関するデータが記録される。本実施形態においては、このステータスデータ領域には、「確認待ち」、「承認」、「差し戻し」、「却下」を示す各フラグが記録される。
【００５５】
履歴データ領域には、この申請についての履歴に関するデータが記録される。この履歴データ領域には、申請者や決裁者により所定の手続が行なわれた日付（年月日）や手続内容（申請、確認等）が記録される。
【００５６】
人事管理サーバ３０は、この会社の社員の人事情報を管理するコンピュータシステムである。この人事管理サーバ３０は、組織表情報や人事異動情報を提供する処理を実行する。この組織表情報は、社員コード、部署コード、役職コード、資格コードを含む。そして、組織表情報は、前述した組織表管理データ記憶部２２に記録される。人事異動情報は、発令日、異動日、異動者の社員コード、異動元及び異動先の部署コード、役職コードを含む。
【００５７】
勤怠管理サーバ４０は、各社員の勤怠情報を管理するコンピュータシステム（勤怠管理システム）である。この勤怠管理サーバ４０は、クライアント端末１０により登録された社員コード毎の勤務スケジュールを管理する。この勤務スケジュールにより、社員の勤務状況（在席状況、出勤予定、休暇予定、出張予定等）を特定することができる。
【００５８】
上記のように構成されたシステムを用いて、決裁権限や各種申請を管理する場合の処理手順について、図３〜図７を用いて説明する。ここでは、権限委譲登録処理、決裁者登録処理、申請受付処理、決裁者通知処理、異動管理処理の順番に説明する。
【００５９】
（権限委譲登録処理）
まず、図３を用いて、権限委譲登録処理を説明する。ここでは、本来の権限者が、クライアント端末１０を用いて、決裁権限の委譲を登録するために、申請管理サーバ２０にアクセスする。
【００６０】
この場合、申請管理サーバ２０の制御部２１は、利用者認証処理を実行する（ステップＳ１−１）。具体的には、制御部２１の利用者認証手段２１１は、クライアント端末１０のディスプレイに認証画面を出力する。利用者は、この認証画面において、社員コード及びパスワードを入力する。送信指示が入力された場合、クライアント端末１０は、認証要求を申請管理サーバ２０に送信する。この認証要求には、認証画面において入力された社員コード及びパスワードを含める。そして、利用者認証手段２１１は、クライアント端末１０から取得した社員コード及びパスワードを用いて、利用者認証を行なう。利用者認証ができなかった場合には、エラーメッセージをクライアント端末１０に送信する。
【００６１】
一方、利用者認証を完了した場合、利用者認証手段２１１は、組織表管理データ記憶部２２から、この社員コードが記録された組織表管理レコード２２０を取得し、この社員の部署コード及び資格コードを取得する。そして、利用者認証手段２１１は、資格コードに応じたメニュー画面をクライアント端末１０のディスプレイに出力する。資格コードにおいて権限を有する社員の場合には、メニュー画面に、権限委譲登録ボタン、権限者登録ボ
タン、申請ボタン、決裁処理ボタンを含める。一方、資格コードにおいて権限を有しない社員の場合には、メニュー画面に、決裁者登録ボタン、申請ボタンを含める。ここで、利用者（権限者）が、メニュー画面の権限委譲登録ボタンを選択する場合を想定する。この場合、クライアント端末１０は、権限委譲登録画面要求を申請管理サーバ２０に送信する。
【００６２】
権限委譲登録画面要求を受信した申請管理サーバ２０の制御部２１は、カテゴリの特定処理を実行する（ステップＳ１−２）。具体的には、制御部２１の委譲登録手段２１２は、権限管理データ記憶部２３から、認証された社員コードが本来権限者データ領域に記録されている権限管理レコード２３０を抽出する。そして、委譲登録手段２１２は、この権限管理レコード２３０に記録されているカテゴリを特定する。次に、委譲登録手段２１２は、特定したカテゴリを一覧表示させるためのカテゴリリストを作成する。そして、カテゴリリストにおいて、各カテゴリを選択可能にしたカテゴリ選択画面を生成し、クライアント端末１０のディスプレイに出力する。このカテゴリ選択画面には、各カテゴリを選択するための選択ボタンを含める。利用者は、カテゴリ選択画面において、権限を委譲するカテゴリを選択する。この場合、クライアント端末１０は、選択されたカテゴリについての選択情報を申請管理サーバ２０に送信する。
【００６３】
次に、申請管理サーバ２０の制御部２１は、カテゴリに基づいて委譲対象者候補の抽出処理を実行する（ステップＳ１−３）。具体的には、制御部２１の委譲登録手段２１２は、組織表管理データ記憶部２２から、この本来権限者が属する組織の社員の組織表管理レコード２２０を抽出する。そして、委譲登録手段２１２は、抽出した組織表管理レコード２２０を用いて、このカテゴリにおいて決裁権限を付与可能な資格コードが記録された社員（委譲先候補）の社員コードを特定する。
【００６４】
次に、申請管理サーバ２０の制御部２１は、委譲先候補の出力処理を実行する（ステップＳ１−４）。具体的には、制御部２１の委譲登録手段２１２は、特定した委譲先候補者を一覧表示した委譲先選択画面を生成し、クライアント端末１０のディスプレイに出力する。
【００６５】
次に、申請管理サーバ２０の制御部２１は、委譲先の取得処理を実行する（ステップＳ１−５）。具体的には、権限者は、委譲先選択画面において、権限を委譲する社員を選択する。更に、委譲先選択画面において、権限を委譲する場合の委譲条件（常時委譲又は不在時委譲）を選択する。そして、クライアント端末１０は、委譲先選択画面において選択された社員コード、委譲条件を含めた選択情報を申請管理サーバ２０に送信する。制御部２１の委譲登録手段２１２は、クライアント端末１０から、委譲先として選択された社員コード及び委譲条件を取得する。
【００６６】
次に、申請管理サーバ２０の制御部２１は、委譲対象者の登録処理を実行する（ステップＳ１−６）。具体的には、制御部２１の委譲登録手段２１２は、このカテゴリの権限管理レコード２３０に、クライアント端末１０から取得した委譲先の社員コード及び委譲条件を記録する。
【００６７】
（決裁者登録処理）
次に、図４を用いて、決裁者登録処理を説明する。ここでは、各種申請を行なう可能性がある社員が、クライアント端末１０を用いて、各種申請の決裁者を登録するために、申請管理サーバ２０にアクセスする。
【００６８】
この場合、申請管理サーバ２０の制御部２１は、ステップＳ１−１と同様に、利用者認証処理を実行する（ステップＳ２−１）。利用者認証を完了した場合、利用者認証手段２
１１は、メニュー画面をクライアント端末１０のディスプレイに出力する。ここでは、利用者は、メニュー画面における決裁者登録ボタンを選択する。この場合、クライアント端末１０は、決裁者登録画面要求を申請管理サーバ２０に送信する。
【００６９】
決裁者登録画面要求を受信した申請管理サーバ２０の制御部２１は、カテゴリの特定処理を実行する（ステップＳ２−２）。具体的には、制御部２１の決裁者登録手段２１３は、各種申請のカテゴリを一覧表示させるためのカテゴリリストを作成する。そして、カテゴリリストにおいて、各カテゴリを選択可能にしたカテゴリ選択画面を生成し、クライアント端末１０のディスプレイに出力する。利用者は、カテゴリ選択画面において、カテゴリを選択する。そして、クライアント端末１０は、選択されたカテゴリ情報を申請管理サーバ２０に送信する。
【００７０】
次に、申請管理サーバ２０の制御部２１は、カテゴリに基づいて権限者候補の抽出処理を実行する（ステップＳ２−３）。具体的には、制御部２１の決裁者登録手段２１３は、権限管理データ記憶部２３から、この利用者の属する部署コード、カテゴリが記録された権限管理レコード２３０を抽出する。そして、決裁者登録手段２１３は、この権限管理レコード２３０の本来権限者データ領域に記録されている社員コードを取得する。更に、決裁者登録手段２１３は、委譲条件データ領域に常時委譲フラグが記録されている権限管理レコード２３０の委譲先データ領域に記録されている社員コードを取得する。
【００７１】
次に、申請管理サーバ２０の制御部２１は、決裁者候補の出力処理を実行する（ステップＳ２−４）。具体的には、制御部２１の決裁者登録手段２１３は、先のステップにおいて権限管理レコード２３０から取得した社員コードを決裁者候補として一覧表示させるための候補者リストを作成する。そして、候補者リストにおいて各候補者を選択可能にした決裁者選択画面を生成し、クライアント端末１０のディスプレイに出力する。
【００７２】
次に、申請管理サーバ２０の制御部２１は、デフォルト決裁者の取得処理を実行する（ステップＳ２−５）。具体的には、利用者は、決裁者選択画面において、自分の申請について決裁を行なう決裁者（デフォルト決裁者）を選択する。クライアント端末１０は、決裁者選択画面において選択された決裁者の社員コード情報を申請管理サーバ２０に送信する。制御部２１の決裁者登録手段２１３は、クライアント端末１０から、デフォルト決裁者として選択された社員コードを取得する。
【００７３】
次に、申請管理サーバ２０の制御部２１は、デフォルト決裁者の登録処理を実行する（ステップＳ２−６）。具体的には、制御部２１の決裁者登録手段２１３は、この利用者の社員コード、カテゴリの決裁者登録レコード２４０の決裁者データ領域に、クライアント端末１０から取得したデフォルト決裁者の社員コードを記録する。
【００７４】
（申請受付処理）
次に、図５を用いて、申請受付処理を説明する。ここでは、各種申請を行なう社員（申請者）が、クライアント端末１０を用いて、各種申請を行なうために、申請管理サーバ２０にアクセスする。
【００７５】
この場合、申請管理サーバ２０の制御部２１は、ステップＳ１−１と同様に、利用者認証処理を実行する（ステップＳ３−１）。利用者認証を完了した場合、利用者認証手段２１１は、メニュー画面をクライアント端末１０のディスプレイに出力する。ここでは、利用者は、メニュー画面における申請ボタンを選択する。この場合、クライアント端末１０は、申請画面要求を申請管理サーバ２０に送信する。
【００７６】
次に、申請管理サーバ２０の制御部２１は、申請の受付処理を実行する（ステップＳ３
−２）。具体的には、制御部２１の申請受付手段２１４は、申請受付画面をクライアント端末１０のディスプレイに出力する。この申請受付画面には、申請内容を選択するための選択ボタンが設けられている。そして、利用者は、所望の申請内容についての選択ボタンを選択する。この場合、クライアント端末１０は、選択された申請内容についての受付画面要求を申請管理サーバ２０に送信する。
【００７７】
申請受付画面要求を受信した申請受付手段２１４は、選択された申請についての受付画面を、クライアント端末１０のディスプレイに出力する。この受付画面には、必要事項（決裁依頼内容）や決裁期限を入力するための各入力欄が設けられている。利用者は、この申請受付画面に必要事項を入力する。更に、決裁の期限を設ける場合には、申請受付画面において決裁期限を入力する。そして、クライアント端末１０は、入力された決裁依頼内容を申請管理サーバ２０に送信する。
【００７８】
次に、申請管理サーバ２０の制御部２１は、申請内容に基づいて決裁者候補の抽出処理を実行する（ステップＳ３−３）。具体的には、制御部２１の申請受付手段２１４は、カテゴリ管理テーブルを用いて、申請内容に対応するカテゴリを特定して、決裁者情報取得手段２１５に受け付けた申請を引き継ぐ。決裁者情報取得手段２１５は、決裁者登録データ記憶部２４から、申請者の社員コード及び申請のカテゴリが記録された決裁者登録レコード２４０を抽出する。そして、決裁者情報取得手段２１５は、この決裁者登録レコード２４０の決裁者データ領域に記録された社員コードを取得する。
【００７９】
更に、決裁者情報取得手段２１５は、権限管理データ記憶部２３を用いて、申請者が属する部署の部署コード及びカテゴリが記録された権限管理レコード２３０を抽出する。そして、決裁者情報取得手段２１５は、この権限管理レコード２３０から、本来権限者データ領域、委譲先データ領域に記録された社員コードを取得する。この社員コードにより、デフォルト決裁者の権限の有効性を確認し、他の権限者を特定することができる。
【００８０】
なお、権限管理レコード２３０の有効期限を経過している権限者は、決裁者候補の対象外として除外する。
また、決裁者登録レコード２４０の決裁者データ領域が空欄の場合には、デフォルト決裁者を特定できないので、すべての権限者を決裁者候補として特定する。このような決裁者登録レコード２４０を用いて申請を行なう場合には、決裁者情報取得手段２１５は、クライアント端末１０に対して決裁者登録処理の再実行を促す。
【００８１】
次に、申請管理サーバ２０の制御部２１は、デフォルト決裁者の勤怠情報の取得処理を実行する（ステップＳ３−４）。具体的には、制御部２１の決裁者情報取得手段２１５は、決裁者登録レコード２４０の決裁者データ領域に記録された社員コードについての勤務スケジュールを、勤怠管理サーバ４０から取得する。ここでは、当日以降の勤務スケジュールを取得する。
【００８２】
次に、申請管理サーバ２０の制御部２１は、勤怠情報に基づいて決裁者の特定処理を実行する（ステップＳ３−５）。具体的には、制御部２１の決裁者情報取得手段２１５は、デフォルト決裁者及び他の権限者を一覧表示させるための決裁者候補リストを作成する。そして、決裁者候補リストにおいて、各決裁者候補を選択可能にした決裁者選択画面を生成し、クライアント端末１０のディスプレイに出力する。この決裁者選択画面には、勤怠管理サーバ４０から取得した勤務スケジュールを含める。なお、本来権限者がデフォルト決裁者として登録されており、このデフォルト決裁者が不在（出張又は休暇）であって、委譲条件データ領域に不在時委譲フラグが記憶されている場合には、決裁者情報取得手段２１５は、委譲先の社員コードをデフォルト決裁者として出力する。
【００８３】
申請者は、デフォルト決裁者の勤務スケジュールにおいて決裁判断可能と判定した場合には、デフォルト決裁者を決裁者として特定する。一方、勤務スケジュールにおいて決裁判断不可と判定した場合には、他の権限者（本来権限者又は委譲先の社員）を決裁者として特定する。そして、クライアント端末１０は、申請者により選択された決裁者情報を申請管理サーバ２０に送信する。
【００８４】
決裁者情報を受信した申請管理サーバ２０の制御部２１は、申請の登録処理を実行する（ステップＳ３−６）。具体的には、制御部２１の申請受付手段２１４は、申請受付コードを付与し、申請者〜決裁期限を設定した申請管理レコード２５０を生成し、申請管理データ記憶部２５に記録する。この場合、ステータスデータ領域に「確認待ち」フラグ、履歴データ領域に申請年月日を記録する。
【００８５】
（決裁者通知処理）
次に、図６を用いて、決裁者通知処理を説明する。
まず、申請管理サーバ２０の制御部２１は、未決裁の申請があるかどうかについての判定処理を実行する（ステップＳ４−１）。具体的には、制御部２１の申請通知手段２１７は、申請管理データ記憶部２５において、ステータスデータ領域に「確認待ち」フラグが記録された申請管理レコード２５０を検索する。
【００８６】
ここで、申請が登録されていない場合（ステップＳ４−１において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、決裁者通知処理を終了する。
一方、申請が登録されている場合（ステップＳ４−１において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、定期通知時刻を経過しているかどうかについての判定処理を実行する（ステップＳ４−２）。具体的には、制御部２１の申請通知手段２１７は、現在時刻をシステムタイマから取得し、現在時刻と定期通知時刻とを比較することにより、定期通知時刻を経過しているかどうかを判定する。
【００８７】
定期通知時刻を経過している場合（ステップＳ４−２において「ＹＥＳ」の場合）、通知処理を実行する（ステップＳ４−３）。具体的には、制御部２１の申請通知手段２１７は、すべての申請管理レコード２５０に記録された各決裁者の連絡先を、利用者管理データ記憶部から取得する。そして、申請通知手段２１７は、確認待ちの申請があることを示したメッセージを含めた決裁依頼を送信する。この決裁依頼を受け取った決裁者は、申請管理サーバ２０にアクセスして、後述する決裁処理を行なう。
【００８８】
一方、定期通知時刻を経過していない場合（ステップＳ４−２において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、未決裁の申請がある決裁者毎に、以下の処理を繰り返して実行する。
【００８９】
ここでは、申請管理サーバ２０の制御部２１は、急ぎの申請があるかどうかについての判定処理を実行する（ステップＳ４−４）。具体的には、制御部２１の申請通知手段２１７は、この決裁者の申請管理レコード２５０において、決裁期限が最も近いレコードを特定する。そして、申請通知手段２１７は、この決裁期限までの猶予期間の長さを算出し、猶予基準値と比較する。ここで、決裁期限までの猶予期間の長さが猶予基準値以下の場合には、急ぎの申請があると判定する。
【００９０】
急ぎの申請があると判定した場合（ステップＳ４−４において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、通知処理を実行する（ステップＳ４−７）。具体的には、制御部２１の申請通知手段２１７は、この申請管理レコード２５０に記録された決裁者の連絡先を、利用者管理データ記憶部から取得する。そして、申請通知手段２１７は、確認待ちの申請があることを示したメッセージを含めた決裁依頼を送信する。
【００９１】
一方、急ぎの申請がないと判定した場合（ステップＳ４−４において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、決裁対象の申請について確認作業負荷の算出処理を実行する（ステップＳ４−５）。具体的には、制御部２１の申請通知手段２１７は、抽出した各申請管理レコード２５０の申請について、申請内容に応じた負荷加重値を負荷評価テーブルから取得する。そして、申請通知手段２１７は、各申請の負荷加重値を総和することにより、負荷総和値を算出する。
【００９２】
次に、申請管理サーバ２０の制御部２１は、確認作業の負荷総和値が負荷基準値以上かどうかについての判定処理を実行する（ステップＳ４−６）。具体的には、制御部２１の申請通知手段２１７は、算出した負荷総和値と負荷基準値とを比較することにより、確認作業の負荷総和値が負荷基準値以上かどうかを判定する。
【００９３】
確認作業の負荷総和値が負荷基準値以上の場合（ステップＳ４−６において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、通知処理を実行する（ステップＳ４−７）。
【００９４】
一方、確認作業の負荷総和値が負荷基準値未満の場合（ステップＳ４−６において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、この決裁者についての処理を終了する。そして、ステップＳ４−４〜Ｓ４−７の処理を、未決裁の申請管理レコード２５０の決裁者毎に繰り返す。
【００９５】
（決裁処理）
次に、決裁処理を説明する。ここでは、決裁依頼を受け取った決裁者が、クライアント端末１０を用いて、決裁依頼内容を確認して承認可否を判断するために、申請管理サーバ２０にアクセスする。
【００９６】
この場合、申請管理サーバ２０の制御部２１は、利用者認証処理を実行する。そして、利用者は、メニュー画面における決裁処理ボタンを選択する。この場合、クライアント端末１０は、決裁処理画面要求を申請管理サーバ２０に送信する。
【００９７】
決裁処理画面要求を受信した場合には、申請管理サーバ２０の制御部２１は、未決裁の申請の一覧表示処理を実行する。具体的には、制御部２１の決裁管理手段２１６は、申請管理データ記憶部２５から、この決裁者の社員コードが記録され、未確認の申請についての申請管理レコード２５０を抽出する。そして、決裁管理手段２１６は、抽出した申請管理レコード２５０に記録された決裁依頼内容を一覧表示させた決裁処理画面をクライアント端末１０のディスプレイに出力する。
【００９８】
決裁者は、クライアント端末１０を用いて、「承認」、「差し戻し」又は「却下」のいずれかを入力する。そして、制御部２１の決裁管理手段２１６は、クライアント端末１０から、申請についての確認結果通知を受信する。この確認結果通知には、「承認」、「差し戻し」又は「却下」のいずれかの指示を含める。
【００９９】
確認結果通知に「差し戻し」指示又は「却下」指示が含まれている場合、申請管理サーバ２０の制御部２１は、差し戻し処理又は却下処理を実行する。具体的には、制御部２１の決裁管理手段２１６は、申請管理レコード２５０に、ステータスとして「差し戻し」フラグ又は「却下」フラグを記録する。次に、決裁管理手段２１６は、この申請管理レコード２５０に記録された申請者の連絡先を利用者管理データ記憶部から取得する。そして、決裁管理手段２１６は、この連絡先に対して、申請が差し戻し又は却下されたことを知らせるメッセージを送信する。差し戻しの場合、申請者は、必要に応じて再申請を行なう。
【０１００】
一方、決裁結果通知に「承認」指示が含まれている場合、申請管理サーバ２０の制御部２１は、決裁結果の通知処理を実行する。具体的には、制御部２１の決裁管理手段２１６は、申請管理レコード２５０に、ステータスとして「承認」フラグを記録する。次に、決裁管理手段２１６は、この申請管理レコード２５０に記録された申請者の連絡先に対して、申請が決裁されたことを知らせるメッセージを送信する。
【０１０１】
（異動管理処理）
次に、図７を用いて、異動管理処理を説明する。
申請管理サーバ２０の制御部２１は、異動情報の取得処理を実行する（ステップＳ５−１）。具体的には、制御部２１の異動管理手段２１８は、人事管理サーバ３０から人事異動情報を取得する。この人事異動情報には、発令日、異動日、異動者の社員コード、異動元及び異動先の部署コード、役職コードを含む。
【０１０２】
次に、申請管理サーバ２０の制御部２１は、権限を委譲していた委譲元の異動者の検索処理を実行する（ステップＳ５−２）。具体的には、制御部２１の異動管理手段２１８は、権限管理レコード２３０の本来権限者データ領域に記録された社員コードを取得する。そして、異動管理手段２１８は、人事異動情報において、本来権限者（委譲元）の社員コードを検索する。
【０１０３】
次に、申請管理サーバ２０の制御部２１は、委譲元の異動があるかどうかについての判定処理を実行する（ステップＳ５−３）。具体的には、制御部２１の異動管理手段２１８は、人事異動情報の中に、本来権限者（委譲元）の社員コードが含まれている場合には、委譲元の異動があると判定する。
【０１０４】
委譲元の異動があると判定した場合（ステップＳ５−３において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、新権限者の登録処理を実行する（ステップＳ５−４）。具体的には、制御部２１の異動管理手段２１８は、人事異動情報において、この委譲元の部署を異動先とする社員であって、委譲元と同じ役職の社員を特定する。そして、異動管理手段２１８は、特定した社員コードを本来権限者データ領域に記録した権限管理レコード２３０を生成し、権限管理データ記憶部２３に記録する。この場合、部署コード、カテゴリ、委譲先の各データ領域には、この部署からの異動者の権限管理レコード２３０と同じデータを記録する。
【０１０５】
次に、申請管理サーバ２０の制御部２１は、異動者の権限の更新処理を実行する（ステップＳ５−５）。具体的には、制御部２１の異動管理手段２１８は、この部署からの異動者の異動日に引継ぎ日数を加算した有効期間を算出する。そして、異動管理手段２１８は、異動者の権限管理レコード２３０に有効期間を記録する。
【０１０６】
更に、異動管理手段２１８は、決裁者登録データ記憶部２４において、この異動者の社員コードが決裁者データ領域に記録された決裁者登録レコード２４０を検索する。そして、この決裁者登録レコード２４０を抽出した場合には、異動管理手段２１８は、決裁者データ領域に記録されている社員コードを削除する。
【０１０７】
次に、申請管理サーバ２０の制御部２１は、権限を委譲されていた委譲先の異動者の検索処理を実行する（ステップＳ５−６）。具体的には、制御部２１の異動管理手段２１８は、権限管理レコード２３０の委譲先データ領域に記録された社員コードを取得する。そして、異動管理手段２１８は、人事異動情報において、委譲先の社員コードを検索する。
【０１０８】
次に、申請管理サーバ２０の制御部２１は、委譲先の異動があるかどうかについての判
定処理を実行する（ステップＳ５−７）。具体的には、制御部２１の異動管理手段２１８は、人事異動情報の中に、委譲先の社員コードが含まれている場合には、委譲先の異動があると判定する。
【０１０９】
委譲先の異動がある場合（ステップＳ５−７において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、委譲先の権限の抹消処理を実行する（ステップＳ５−８）。具体的には、制御部２１の異動管理手段２１８は、権限管理レコード２３０の委譲先データ領域に記録されている社員コードを削除する。
【０１１０】
更に、異動管理手段２１８は、決裁者登録データ記憶部２４において、委譲先の社員コードが決裁者データ領域に記録されている決裁者登録レコード２４０を検索する。そして、この決裁者登録レコード２４０を抽出した場合には、異動管理手段２１８は、決裁者データ領域に記録されている社員コードを削除する。
【０１１１】
本実施形態によれば、以下のような効果を得ることができる。
（１）本実施形態では、権限委譲登録処理を実行する。この処理において、本来権限者や委譲先の社員コードを記録した権限管理レコード２３０が権限管理データ記憶部２３に登録される。これにより、本来の権限者から権限を委譲された社員を決裁者とすることができる。
【０１１２】
（２）本実施形態では、決裁者登録処理を実行する。この処理において、自分の決裁依頼内容を確認する決裁者を記録した決裁者登録レコード２４０が決裁者登録データ記憶部２４に登録される。これにより、申請を行なう可能性がある社員自身が、予め決裁者を登録しておくことができる。
【０１１３】
（３）本実施形態では、申請受付処理において、申請管理サーバ２０の制御部２１は、申請内容に基づいて決裁者候補の抽出処理（ステップＳ３−３）、デフォルト決裁者の勤怠情報の取得処理（ステップＳ３−４）を実行する。これにより、デフォルト決裁者による決裁判断の可否を判断することができる。
【０１１４】
そして、申請管理サーバ２０の制御部２１は、勤怠情報に基づいて決裁者の特定処理を実行する（ステップＳ３−５）。具体的には、制御部２１の決裁者情報取得手段２１５は、デフォルト決裁者及び他の権限者を一覧表示させるための決裁者候補リストを作成する。これにより、デフォルト決裁者による決裁判断が困難な場合には、他の権限者を決裁者として選択することができる。
【０１１５】
（４）本実施形態では、決裁者通知処理においては、申請が登録されている場合（ステップＳ４−１において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、定期通知時刻を経過しているかどうかについての判定処理を実行する（ステップＳ４−２）。そして、定期通知時刻を経過している場合（ステップＳ４−２において「ＹＥＳ」の場合）、通知処理を実行する（ステップＳ４−３）。これにより、申請があることを、定期的に決裁者に通知することができる。
【０１１６】
更に、申請管理サーバ２０の制御部２１は、急ぎの申請があるかどうかについての判定処理を実行する（ステップＳ４−４）。急ぎの申請があると判定した場合（ステップＳ４−４において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、通知処理を実行する（ステップＳ４−７）。これにより、急いで決裁判断をしなければならない申請について、迅速に対応することができる。
【０１１７】
更に、申請管理サーバ２０の制御部２１は、確認作業の負荷総和値が負荷基準値以上か
どうかについての判定処理を実行する（ステップＳ４−６）。確認作業の負荷総和値が負荷基準値以上の場合（ステップＳ４−６において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、通知処理を実行する（ステップＳ４−７）。これにより、まとめて通知することにより、決裁者にとっての煩雑さを抑制するとともに、確認作業の負荷が過大になる前に、決裁依頼を通知することができる。
【０１１８】
（５）本実施形態では、異動管理処理において、委譲元の異動があると判定した場合（ステップＳ５−３において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、新権限者の登録処理（ステップＳ５−４）、異動者の権限の更新処理（ステップＳ５−５）を実行する。これにより、本来の権限者が異動した場合にも、申請についての決裁を効率的に引き継ぐことができる。
【０１１９】
更に、委譲先の異動がある場合（ステップＳ５−７において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、権限を委譲されていた委譲先の権限の抹消処理を実行する（ステップＳ５−８）。これにより、人事異動に対して、的確な権限管理を行なうことができる。
【０１２０】
なお、上記各実施形態は以下のように変更してもよい。
・ 上記実施形態では、申請管理サーバ２０の制御部２１は、カテゴリに基づいて委譲対象者候補の抽出処理を実行する（ステップＳ１−３）。ここで、委譲登録手段２１２は、抽出した組織表管理レコード２２０を用いて、このカテゴリにおいて決裁権限を付与可能な資格コードが記録された社員（委譲先候補）の社員コードを特定する。この場合、決裁権限の付与可能な者の特定は、資格コードに基づくものに限定されるものではない。例えば、役職コードや、勤続年数等を用いることもできる。この場合には、委譲登録手段２１２に、決裁権限の付与可能条件を記録しておく。更に、組織表管理データ記憶部２２に、この付与可能条件を判定するための情報（例えば、勤続年数）を記憶しておく。
【０１２１】
・ 上記実施形態では、権限管理データ記憶部２３は、各組織における決裁権限を有する社員に関する権限管理レコード２３０を記憶する。この委譲条件データ領域には、委譲先において、常時決裁を許容する場合と、本来の決裁者が不在の場合のみ権限を委譲する場合とを識別するためのフラグ（常時委譲フラグ又は不在時委譲フラグ）が記録される。これに対して、委譲先の権限者が不在の場合には本来権限者が決裁することを委譲条件として設定できるようにしてもよい。
【０１２２】
・ 上記実施形態では、急ぎの申請があると判定した場合（ステップＳ４−４において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、通知処理を実行する（ステップＳ４−７）。ここで、所定の申請内容については、決裁期限を判断することなく、通知処理（ステップＳ４−７）を実行するようしてもよい。この場合には、即時の通知処理の対象となる申請内容を申請通知手段２１７に保持させておく。
【０１２３】
・ 上記実施形態では、申請管理サーバ２０の制御部２１は、決裁対象の申請について確認作業負荷の算出処理を実行する（ステップＳ４−５）。そして、申請管理サーバ２０の制御部２１は、確認作業の負荷総和値が負荷基準値以上かどうかについての判定処理を実行する（ステップＳ４−６）。ここで、負荷基準値を決裁者毎に決定するようにしてもよい。この場合には、権限者毎に負荷基準値を記録した負荷基準値データ記憶部を設ける。そして、決裁者毎に負荷総和値と負荷基準値とを比較して、判定処理を行なう。
【０１２４】
また、決裁者の状況に応じて、負荷基準値を変更するようにしてもよい。例えば、決裁者の勤怠情報を取得し、所定期間内に休暇や出張による不在情報が登録されている場合には、制御部２１が、所定の割合で負荷基準値を下げる処理を行なう。これにより、決裁者
が不在になる前に、申請があることを通知することができる。
【０１２５】
・ 上記実施形態では、申請受付処理において、申請管理サーバ２０の制御部２１は、勤怠情報に基づいて決裁者の特定処理を実行する（ステップＳ３−５）。具体的には、制御部２１の申請受付手段２１４は、勤怠管理サーバ４０から取得した勤務スケジュールをクライアント端末１０のディスプレイに出力する。そして、クライアント端末１０は、申請者により選択された決裁者情報を申請管理サーバ２０に送信する。これに代えて、申請管理サーバ２０が決裁者を決定するようにしてもよい。以下、権限者の勤怠情報に応じて、決裁者を決定する処理を、図８を用いて説明する。
【０１２６】
まず、申請管理サーバ２０の制御部２１は、利用者認証処理を実行する（ステップＳ６−１）。具体的には、制御部２１の利用者認証手段２１１は、ステップＳ１−１と同様に、利用者認証処理を実行する。
【０１２７】
次に、申請管理サーバ２０の制御部２１は、ステップＳ３−２〜Ｓ３−４と同様に、申請の受付処理（ステップＳ６−２）、申請内容に基づいて決裁者候補の抽出処理（ステップＳ６−３）、デフォルト決裁者の勤怠情報の取得処理（ステップＳ６−４）を実行する。
【０１２８】
次に、申請管理サーバ２０の制御部２１は、デフォルト決裁者が決裁判断可能かどうかについての判定処理を実行する（ステップＳ６−５）。具体的には、制御部２１の決裁者情報取得手段２１５は、取得した出勤予定と、申請画面に入力された決裁期限とを比較する。デフォルト決裁者の勤怠情報において、決裁期限までに出勤予定が記録されている場合には、決裁者情報取得手段２１５は、デフォルト決裁者により決裁判断可能と判定する。一方、デフォルト決裁者の勤怠情報において、決裁期限までに出勤予定が記録されていない場合には、デフォルト決裁者により決裁判断不可と判定する。
【０１２９】
デフォルト決裁者により決裁判断可能と判定した場合（ステップＳ６−５において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、デフォルト決裁者の設定処理を実行する（ステップＳ６−６）。具体的には、制御部２１の申請受付手段２１４は、デフォルト決裁者の社員コードを、申請管理レコード２５０の決裁者データ領域に記録する。
【０１３０】
一方、デフォルト決裁者により決裁判断不可と判定した場合（ステップＳ６−５において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、他の権限者の勤怠情報の取得処理を実行する（ステップＳ６−７）。具体的には、制御部２１の決裁者情報取得手段２１５は、権限管理データ記憶部２３を用いて、申請者が属する部署に属する社員であって、この申請のカテゴリについて決裁できる資格を有する他の社員を検索する。そして、決裁者情報取得手段２１５は、この社員の勤怠情報を勤怠管理サーバ４０から取得する。
【０１３１】
次に、申請管理サーバ２０の制御部２１は、他の権限者が決裁判断可能かどうかについての判定処理を実行する（ステップＳ６−８）。具体的には、制御部２１の決裁者情報取得手段２１５は、勤怠管理サーバ４０から取得した勤怠情報における出勤予定と決裁期限とを比較することにより、他の権限者が決裁判断可能かどうかを判定する。
【０１３２】
決裁期限までに出勤予定があり、他の権限者が決裁判断可能な場合（ステップＳ６−８において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、他の権限者の設定処理を実行する（ステップＳ６−９）。具体的には、制御部２１の申請受付手段２１４は、他の権限者の社員コードを、申請管理レコード２５０の決裁者データ領域に記録する。
【０１３３】
次に、申請管理サーバ２０の制御部２１は、申請の登録処理を実行する（ステップＳ６
−１０）。具体的には、制御部２１の申請受付手段２１４は、生成した申請管理レコード２５０を申請管理データ記憶部２５に記録する。
【０１３４】
一方、他の権限者においても決裁判断不可と判定した場合（ステップＳ６−８において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、申請者に対して注意喚起の出力処理を実行する（ステップＳ６−１１）。具体的には、制御部２１の申請受付手段２１４は、申請者のクライアント端末１０に対して、決裁期限までに申請を確認できる権限者がいないことを示すメッセージを出力する。このメッセージを確認した申請者は、他の権限者を探して決裁を依頼する。
これにより、勤怠情報に基づいて、決裁期限に間に合うように、申請についての決裁者を登録することができる。
【０１３５】
・ 上記実施形態では、申請受付処理において、申請管理サーバ２０の制御部２１は、勤怠情報に基づいて決裁者の特定処理を実行する（ステップＳ３−５）。これに加えて、社員の出勤予定が変更された場合に、この社員が決裁者となっている申請に対して注意喚起するようにしてもよい。出勤予定を変更した場合の対応処理を、図９を用いて説明する。
【０１３６】
ここでは、申請管理サーバ２０の制御部２１は、権限者の出勤予定変更情報の取得処理を実行する（ステップＳ７−１）。具体的には、制御部２１の決裁管理手段２１６は、勤怠管理サーバ４０から、新たに出張予定が登録された社員や、休暇予定が登録された社員についての勤怠情報を取得する。そして、決裁管理手段２１６は、出勤予定が変更された勤怠情報の中で、権限管理データ記憶部２３において権限者（本来権限者、委譲先の社員）として登録されている社員の勤怠情報を抽出する。
【０１３７】
次に、申請管理サーバ２０の制御部２１は、決裁者として登録されている申請の特定処理を実行する（ステップＳ７−２）。具体的には、制御部２１の決裁管理手段２１６は、申請管理データ記憶部２５において、出勤予定に変更があった権限者の社員コードが決裁者データ領域に記録された申請管理レコード２５０を検索する。
【０１３８】
決裁者として登録された申請管理レコード２５０を検出した場合には、申請毎に以下の処理を繰り返す。
ここでは、申請管理サーバ２０の制御部２１は、決裁期限内に決裁判断可能かどうかについての判定処理を実行する（ステップＳ７−３）。具体的には、制御部２１の決裁管理手段２１６は、勤怠管理サーバ４０から取得した出勤予定と、申請管理レコード２５０に登録された決裁期限とを比較する。この決裁者の勤怠情報において、決裁期限までに出勤予定が記録されている場合には、申請受付手段２１４は、登録された決裁者により決裁判断可能と判断する。一方、登録された決裁者の勤怠情報において、決裁期限までに出勤予定がなくなった場合には、この決裁者による決裁判断は不可と判断する。
【０１３９】
決裁期限内に決裁判断可能と判定した場合（ステップＳ７−３において「ＹＥＳ」の場合）、この申請についての処理を終了する。
一方、決裁期限内に決裁判断不可と判定した場合（ステップＳ７−３において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、ステップＳ６−７〜Ｓ６−８と同様に、他の権限者の勤怠情報の取得処理（ステップＳ７−４）、他の権限者が決裁判断可能かどうかについての判定処理（ステップＳ７−５）を実行する。
【０１４０】
他の権限者においても決裁判断不可と判定した場合（ステップＳ７−５において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、ステップＳ６−１１と同様に、申請者に対する注意喚起出力処理を実行する（ステップＳ７−６）。
【０１４１】
一方、他の権限者が決裁判断可能と判定した場合（ステップＳ７−５において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、他の権限者の設定処理を実行する（ステップＳ７−７）。具体的には、制御部２１の申請受付手段２１４は、他の権限者の社員コードを、申請管理レコード２５０の決裁者データ領域に記録する。
【０１４２】
次に、申請管理サーバ２０の制御部２１は、変更通知処理を実行する（ステップＳ７−８）。具体的には、制御部２１の申請受付手段２１４は、決裁者を変更したことを申請者の連絡先に通知する。
以上の処理を申請毎に繰り返す。
これにより、出勤予定の変更に応じて、的確な決裁者を設定することができる。
【０１４３】
・ 上記実施形態では、決裁者登録処理において、申請管理サーバ２０の制御部２１は、デフォルト決裁者の取得処理を実行する（ステップＳ２−５）。ここで、決裁実績に応じて、デフォルト決裁者を登録するようにしてもよい。この決裁者登録処理を、図１０を用いて説明する。
【０１４４】
ここでは、申請管理サーバ２０の制御部２１は、ステップＳ１−１と同様に、利用者認証処理を実行する（ステップＳ８−１）。
次に、申請管理サーバ２０の制御部２１は、ステップＳ２−２〜Ｓ２−３と同様に、カテゴリの特定処理（ステップＳ８−２）〜カテゴリに基づいて決裁者候補の抽出処理（ステップＳ８−３）を実行する。
【０１４５】
次に、申請管理サーバ２０の制御部２１は、申請状況に応じて決裁者候補の優先順位の決定処理を実行する（ステップＳ８−４）。具体的には、制御部２１の決裁者登録手段２１３は、特定した権限候補者の承認を行なった申請についての処理実績を取得する。ここでは、権限候補者の社員コードが記録されるとともに、「承認済」又は「差し戻し」のいずれかのフラグが記録された申請管理レコード２５０を、申請管理データ記憶部２５から抽出する。
【０１４６】
そして、決裁者登録手段２１３は、承認された申請数を総数で除算することにより、承認率を算出する。なお、申請から確認（承認又は差し戻し）までに要した時間を用いて優先順位を決めるようにしてもよい。この場合には、確認までの所要時間が短い決裁者候補に対して高い優先順位を設定する。
【０１４７】
次に、申請管理サーバ２０の制御部２１は、決裁者候補の出力処理を実行する（ステップＳ８−５）。具体的には、制御部２１の決裁者登録手段２１３は、取得した社員コードを決裁者候補として一覧表示させるための候補者リストを作成する。この候補者リストでは、各決裁者候補に対して承認率を含める。そして、候補者リストにおいて各候補者を選択可能にした決裁者選択画面を生成し、クライアント端末１０に送信する。
【０１４８】
次に、申請管理サーバ２０の制御部２１は、ステップＳ２−５〜Ｓ２−６と同様に、デフォルト決裁者の取得処理（ステップＳ８−６）、デフォルト決裁者の登録処理（ステップＳ８−７）を実行する。
これにより、申請を行なう社員は、申請状況を考慮して、的確なデフォルト決裁者を登録することができる。
【０１４９】
・ 上記実施形態では、所属部署の異動情報に基づいて異動管理処理を行なう。異動管理処理の対象となる異動情報は所属部署の異動に限定されるものではない。例えば、退職、休職、降格等の異動情報を取得して異動管理処理を行なうようにしてもよい。
【０１５０】
また、昇格や復職等の異動情報を取得して、権限委譲登録処理、決裁者登録処理を再実行するようにしてもよい。具体的には、昇格や復職等により、新たに決裁権限を付与可能な資格コードを有する委譲対象者候補が、組織表管理データ記憶部２２に登録される。申請管理サーバ２０の制御部２１は、組織表管理データ記憶部２２において、新たな委譲対象者候補の登録を検知した場合、権限委譲登録処理、決裁者登録処理を再実行する。この場合には、新たに委譲対象者候補が登録された組織を特定し、その組織の本来の権限者に対して、権限委譲登録処理の再実行を促すメッセージを送信する。また、新たな委譲対象者が登録された場合には、その委譲対象者が属する組織において、各種申請を行なう可能性がある社員に対して、権限委譲登録処理の再実行を促すメッセージを送信する。
【符号の説明】
【０１５１】
１０…クライアント端末、２０…申請管理サーバ、２１…制御部、２１１…利用者認証手段、２１２…委譲登録手段、２１３…決裁者登録手段、２１４…申請受付手段、２１５…決裁者情報取得手段、２１６…決裁管理手段、２１７…申請通知手段、２１８…異動管理手段、２２…組織表管理データ記憶部、２３…権限管理データ記憶部、２４…決裁者登録データ記憶部、２５…申請管理データ記憶部、３０…人事管理サーバ、４０…勤怠管理サーバ。
【技術分野】
【０００１】
本発明は、申請についての決裁権限を管理するための権限管理システム、権限管理方法及び権限管理プログラムに関する。
【背景技術】
【０００２】
企業等の組織内における決裁処理において電子ワークフローシステムが利用されることがある。この電子ワークフローシステムにおいては、申請者により作成された各種申請が、ネットワークを介して電子的に回覧され、承認可否についての確認作業が行なわれている。しかし、内容を確認する必要がある申請が特定の権限者に集中した場合、確認作業の負荷が大きくなるとともに、決裁処理が遅れることがある。
【０００３】
そこで、決裁の権限者が他者に権限を委譲して決裁処理を分散することもある。そこで、文書の決裁者が、決裁権限を委譲する場合を考慮した電子文書回覧システムが検討されている（例えば、特許文献１参照）。この文献に記載された電子文書回覧システムにおいては、予め電子文書を回覧する決裁経路を設定しておく。電子文書の作成者が、文書作成後、決裁や決裁を依頼する回覧者または決裁者が選択された場合、権限委譲前の決裁者かどうか判断する。権限委譲前の決裁者である場合は、権限委譲前の決裁者であることを示す識別表示するとともに決裁経路に設定する。
【０００４】
また、組織改編等があった場合にも、電子ドキュメントを確実に管理するための文書管理装置も検討されている（例えば、特許文献２参照）。この文献に記載された文書管理装置は、電子ドキュメントを管理する場合、管理情報として、電子ドキュメントのＩＤに関連付けて権限者の情報を格納する。権限者は、電子ドキュメントの改版等の作業をすることができるようにする。人事異動等により、権限者が電子ドキュメントを管理する立場から離れた場合には、次の権限者に電子ドキュメントの管理権限を委譲する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００４−２１２７３号公報（第１頁、図２）
【特許文献２】国際公開第２００６／１３７１２４号公報（第１頁、図９）
【発明の概要】
【発明が解決しようとする課題】
【０００６】
権限を設定する場合、特許文献１に記載されているように、権限者本人のみが決裁することができる専決とする場合もある。しかし、専決とすると、この権限者が不在の場合には、決裁依頼内容の確認作業が遅れることもある。特に、決裁に期限が設けられている場合には、この期限を考慮して確認を行なう必要がある。そこで、負荷分散を図るために、権限委譲により複数の権限者（本来の権限者及び権限委譲を受けた権限者）が設定されることがある。また、本来の権限者が複数、存在している場合もある。この場合、決裁依頼内容を確認する権限者（決裁者）を特定する必要がある。また、複数の権限者が設定されている場合、申請者においても、各種申請の決裁者を選択したい場合がある。
【０００７】
更に、企業内においては、頻繁に人事異動が行なわれる場合もある。このような人事異動の中で、権限者が異動する場合にも、円滑に決裁を引き継げることが望ましい。
本発明は、上記課題を解決するためになされたものであり、申請についての決裁権限を的確に管理するための権限管理システム、権限管理方法及び権限管理プログラムを提供することにある。
【課題を解決するための手段】
【０００８】
上記問題点を解決するために、請求項１に記載の発明は、申請内容に対応した決裁権限を有する権限者と、その決裁権限の委譲先についての権限情報を記憶した権限管理情報記憶手段と、各申請について決裁を行なうデフォルト決裁者情報を記憶した決裁者登録情報記憶手段と、申請についての決裁を管理する制御手段とを備えた権限管理システムであって、前記制御手段が、クライアント端末からアクセスした権限者を認証し、前記権限者において申請内容に対応させて決裁権限を委譲できる委譲先候補者を特定して前記クライアント端末に出力する手段と、前記委譲先候補者の中で選択された利用者に対して、前記権限管理情報記憶手段において、前記申請内容の決裁権限が委譲された権限者として登録を行なう手段と、クライアント端末からアクセスした申請者を認証し、前記クライアント端末から取得した申請内容に基づいて、前記権限管理情報記憶手段において、決裁を行なうことができる権限者を特定し、決裁者候補として前記クライアント端末に出力する手段と、前記決裁者候補の中で選択された権限者を、前記申請内容についてのデフォルト決裁者として、前記決裁者登録情報記憶手段に登録する手段とを備えたことを要旨とする。
【０００９】
請求項２に記載の発明は、請求項１に記載の権限管理システムにおいて、各申請について決裁者が登録された申請管理情報を記憶する申請管理情報記憶手段を更に備え、前記制御手段は、各権限者の勤怠情報を記憶した勤怠管理システムに接続されており、前記制御手段が、クライアント端末からアクセスした申請者を認証し、前記クライアント端末から申請を取得した場合、前記決裁者登録情報記憶手段を用いてデフォルト決裁者を特定し、前記デフォルト決裁者の勤怠情報を前記勤怠管理システムから取得して、前記クライアント端末に出力し、前記クライアント端末から取得した決裁者情報を含めた申請管理情報を前記申請管理情報記憶手段に記録する手段を更に備えたことを要旨とする。
【００１０】
請求項３に記載の発明は、請求項２に記載の権限管理システムにおいて、前記制御手段が、前記勤怠情報により、前記デフォルト決裁者により決裁判断ができないと判定した場合、前記権限管理情報記憶手段に記録された他の権限者を、前記申請の決裁者として前記申請管理情報記憶手段に登録する手段を更に備えたことを要旨とする。
【００１１】
請求項４に記載の発明は、請求項３に記載の権限管理システムにおいて、前記勤怠情報において、申請の決裁期限までに前記デフォルト決裁者の出勤予定がない場合に、前記デフォルト決裁者により決裁判断ができないと判定することを要旨とする。
【００１２】
請求項５に記載の発明は、請求項２〜４のいずれか一つに記載の権限管理システムにおいて、前記制御手段が、前記申請内容に応じて、前記申請管理情報記憶手段に記録された申請の決裁者毎に、申請された決裁依頼内容を確認するための負荷を計算する手段と、前記負荷が基準値を超えた場合に、前記決裁者に対して申請があったことを通知する手段とを更に備えたことを要旨とする。
【００１３】
請求項６に記載の発明は、請求項１〜５のいずれか一つに記載の権限管理システムにおいて、前記制御手段が、委譲元の権限者についての異動情報を取得した場合には、前記権限管理情報記憶手段に記憶された権限者の権限に対して、有効期間として引継期間を設定する手段を更に備えたことを要旨とする。
【００１４】
請求項７に記載の発明は、請求項１〜６のいずれか一つに記載の権限管理システムにおいて、前記制御手段が、委譲元の権限者についての異動情報を取得した場合には、前記権限管理情報記憶手段に記憶された委譲元の権限者を、前記異動情報に基づいて新たな権限者に変更する手段を更に備えたことを要旨とする。
【００１５】
請求項８に記載の発明は、請求項１〜７のいずれか一つに記載の権限管理システムにおいて、前記制御手段が、委譲先の権限者についての異動情報を取得した場合には、前記権限管理情報記憶手段に記憶された委譲先の権限を抹消する手段を更に備えたことを要旨とする。
【００１６】
請求項９に記載の発明は、申請内容に対応した決裁権限を有する権限者と、その決裁権限の委譲先についての権限情報を記憶した権限管理情報記憶手段と、各申請について決裁を行なうデフォルト決裁者情報を記憶した決裁者登録情報記憶手段と、申請についての決裁を管理する制御手段とを備えた権限管理システムを用いて、申請を管理するための方法であって、前記制御手段が、クライアント端末からアクセスした権限者を認証し、前記権限者において申請内容に対応させて決裁権限を委譲できる委譲先候補者を特定して前記クライアント端末に出力する段階と、前記委譲先候補者の中で選択された利用者に対して、前記権限管理情報記憶手段において、前記申請内容の決裁権限が委譲された権限者として登録を行なう段階と、クライアント端末からアクセスした申請者を認証し、前記クライアント端末から取得した申請内容に基づいて、前記権限管理情報記憶手段において、決裁を行なうことができる権限者を特定し、決裁者候補として前記クライアント端末に出力する段階と、前記決裁者候補の中で選択された権限者を、前記申請内容についてのデフォルト決裁者として、前記決裁者登録情報記憶手段に登録する段階とを実行することを要旨とする。
【００１７】
請求項１０に記載の発明は、申請内容に対応した決裁権限を有する権限者と、その決裁権限の委譲先についての権限情報を記憶した権限管理情報記憶手段と、各申請について決裁を行なうデフォルト決裁者情報を記憶した決裁者登録情報記憶手段と、申請についての決裁を管理する制御手段とを備えた権限管理システムを用いて、申請を管理するためのプログラムであって、前記制御手段を、クライアント端末からアクセスした権限者を認証し、前記権限者において申請内容に対応させて決裁権限を委譲できる委譲先候補者を特定して前記クライアント端末に出力する手段、前記委譲先候補者の中で選択された利用者に対して、前記権限管理情報記憶手段において、前記申請内容の決裁権限が委譲された権限者として登録を行なう手段、クライアント端末からアクセスした申請者を認証し、前記クライアント端末から取得した申請内容に基づいて、前記権限管理情報記憶手段において、決裁を行なうことができる権限者を特定し、決裁者候補として前記クライアント端末に出力する手段、前記決裁者候補の中で選択された権限者を、前記申請内容についてのデフォルト決裁者として、前記決裁者登録情報記憶手段に登録する手段として機能させることを要旨とする。
【００１８】
（作用）
請求項１、９又は１０に記載の発明によれば、制御手段が、クライアント端末からアクセスした権限者を認証し、権限者において申請内容に対応させて決裁権限を委譲できる委譲先候補者を特定してクライアント端末に出力する。そして、委譲先候補者の中で選択された利用者に対して、権限管理情報記憶手段において、申請内容の決裁権限が委譲された権限者として登録を行なう。更に、クライアント端末からアクセスした申請者を認証し、クライアント端末から取得した申請内容に基づいて、権限管理情報記憶手段において、決裁を行なうことができる権限者を特定し、決裁者候補としてクライアント端末に出力する。そして、決裁者候補の中で選択された権限者を、申請内容についてのデフォルト決裁者として、決裁者登録情報記憶手段に登録する。これにより、権限の委譲先を設定し、申請者側で権限者候補の中から決裁者を選択することができる。
【００１９】
請求項２に記載の発明によれば、制御手段が、クライアント端末からアクセスした申請者を認証し、クライアント端末から申請を取得した場合、決裁者登録情報記憶手段を用いてデフォルト決裁者を特定する。そして、デフォルト決裁者の勤怠情報を勤怠管理システ
ムから取得して、クライアント端末に出力し、クライアント端末から取得した決裁者情報を含めた申請管理情報を申請管理情報記憶手段に記録する。これにより、決裁者の勤怠情報を考慮して、決裁者を決定することができることができる。
【００２０】
請求項３に記載の発明によれば、制御手段が、勤怠情報により、デフォルト決裁者により決裁判断ができないと判定した場合、権限管理情報記憶手段に記録された他の権限者を、申請の決裁者として申請管理情報記憶手段に登録する。これにより、勤怠情報に応じて他の権限者が決裁することができる。
【００２１】
請求項４に記載の発明によれば、勤怠情報において、申請の決裁期限までに前記デフォルト決裁者の出勤予定がない場合に、前記デフォルト決裁者により決裁判断ができないと判定する。一方、申請の決裁期限までにデフォルト決裁者が決裁判断不可と判定した場合には、権限管理情報記憶手段に記録された他の権限者を決裁者として登録する。これにより、決裁期限を考慮して決裁者を決定することができる。
【００２２】
請求項５に記載の発明によれば、制御手段が、申請内容に応じて、申請管理情報記憶手段に記録された申請の決裁者毎に、申請された決裁依頼内容を確認するための負荷を計算する。そして、負荷が基準値を超えた場合に、決裁者に対して申請があったことを通知する。決裁者に対して申請毎に通知を受けると、決裁者にとって煩雑になることがある。一方、多くの申請についてまとめて通知すると、確認作業の負荷が過大になることがある。そこで、決裁者の負荷を考慮して、所定の申請数にまとめて決裁依頼を通知することができる。
【００２３】
請求項６に記載の発明によれば、制御手段が、委譲元の権限者についての異動情報を取得した場合には、権限管理情報記憶手段に記憶された権限者の権限に対して、有効期間として引継期間を設定する。これにより、本来の権限者の人事異動があった場合にも、引き継ぎ期間を考慮して、権限管理を行なうことができる。
【００２４】
請求項７に記載の発明によれば、制御手段が、委譲元の権限者についての異動情報を取得した場合には、権限管理情報記憶手段に記憶された委譲元の権限者を、異動情報に基づいて新たな権限者に変更する。これにより、本来の権限者の人事異動があった場合にも、委譲された権限を維持することができる。
【００２５】
請求項８に記載の発明によれば、制御手段が、委譲先の権限者についての異動情報を取得した場合には、権限管理情報記憶手段に記憶された委譲先の権限を抹消する。これにより、委譲されていた権限を抹消することがきる。
【発明の効果】
【００２６】
本発明によれば、申請についての決裁権限を的確に管理することができる。
【図面の簡単な説明】
【００２７】
【図１】本発明の実施形態のシステム概略図。
【図２】本実施形態で用いるデータの説明図であって、（ａ）は組織表管理データ記憶部、（ｂ）は権限管理データ記憶部、（ｃ）は決裁者登録データ記憶部、（ｄ）は申請管理データ記憶部に記録されたデータの説明図。
【図３】本実施形態の処理手順の説明図。
【図４】本実施形態の処理手順の説明図。
【図５】本実施形態の処理手順の説明図。
【図６】本実施形態の処理手順の説明図。
【図７】本実施形態の処理手順の説明図。
【図８】他の実施形態の処理手順の説明図。
【図９】他の実施形態の処理手順の説明図。
【図１０】他の実施形態の処理手順の説明図。
【発明を実施するための形態】
【００２８】
以下、本発明を具体化した一実施形態を、図１〜図７に従って説明する。本実施形態では、組織（会社）内の構成員（社員）が提出した申請についての決裁を行なう権限を管理するために用いる権限管理システム、権限管理方法及び権限管理プログラムとして説明する。以下では、「利用者」は本システムの利用者であり、申請者、決裁者のいずれも含まれる。「申請者」は、申請を行なう者を示しており、権限者は決裁権限を有する者を示す。本来の権限者から権限を委譲された者も、権限者に含まれる。「決裁者」は、権限者の中で申請者によって選択されて、申請の決裁を行なう者を示す。
【００２９】
本実施形態では、図１に示すように、申請の決裁を行なう権限を管理するために、権限管理システムとしての申請管理サーバ２０を用いる。この申請管理サーバ２０は、ネットワークを介して、クライアント端末１０、人事管理サーバ３０、勤怠管理サーバ４０に接続される。
【００３０】
クライアント端末１０は、申請者や権限者（決裁者を含む）等の社員が用いるコンピュータ端末（申請者端末、権限者端末）である。申請者は、このクライアント端末１０を用いて、各種申請を作成する。権限者は、このクライアント端末１０を用いて、決裁依頼内容を確認する。そして、決裁者は、決裁依頼内容に基づいて、承認入力、差し戻し入力、却下入力等を行なう。このクライアント端末１０は、図示しないディスプレイ等から構成された表示部や、キーボードやポインティングデバイス等から構成された入力部を備える。
【００３１】
申請管理サーバ２０は、各種申請の権限管理処理や、申請者による申請処理、決裁者による決裁処理を支援するためのサーバコンピュータである。この申請管理サーバ２０は、制御部２１、組織表管理データ記憶部２２、権限管理情報記憶手段としての権限管理データ記憶部２３、決裁者登録情報記憶手段としての決裁者登録データ記憶部２４、申請管理情報記憶手段としての申請管理データ記憶部２５を備えている。
【００３２】
ここで、制御部２１は、ＣＰＵ、ＲＡＭ、ＲＯＭ（図示せず）等から構成された制御手段を備えており、後述する処理（利用者認証段階、委譲登録段階、決裁者登録段階、申請受付段階、決裁者決定段階、決裁管理段階、申請通知段階、異動管理段階等の各処理）を行なう。そして、制御部２１は、図１に示すように、権限管理プログラムの実行により、利用者認証手段２１１、委譲登録手段２１２、決裁者登録手段２１３、申請受付手段２１４、決裁者情報取得手段２１５、決裁管理手段２１６、申請通知手段２１７、異動管理手段２１８として機能する。
【００３３】
利用者認証手段２１１は、クライアント端末１０から利用者を認証する処理を実行する。この利用者認証手段２１１は、クライアント端末１０から、利用者の認証情報（社員コード及びパスワード）を取得する。更に、利用者認証手段２１１は、図示しない利用者管理データ記憶部から、各利用者の認証情報（社員コード及びパスワード）を取得する。そして、クライアント端末１０から取得した認証情報と比較することにより、アクセスした社員を特定する。
【００３４】
委譲登録手段２１２は、各種申請についての決裁権限の委譲を管理する処理を実行する。本実施形態では、後述するように、権限者が委譲する対象の社員を登録する場合の処理を支援する。
【００３５】
決裁者登録手段２１３は、各社員の申請を決裁する社員（決裁者）を登録する処理を実行する。本実施形態では、後述するように、申請を行なう可能性がある社員が、予め決裁者を登録する場合の処理を支援する。
【００３６】
申請受付手段２１４は、各社員からの申請を受け付ける処理を実行する。この申請受付手段２１４は、各種申請の申請内容に対して、この申請内容が属するカテゴリを関連付けたカテゴリ管理テーブルを備えている。本実施形態のカテゴリには、「人事」、「勤怠」、「費用」等があり、例えば、申請内容「休暇申請」は「勤怠」のカテゴリに属し、申請内容「旅費精算」は「費用」のカテゴリに属する。
【００３７】
決裁者情報取得手段２１５は、後述するように、各申請の申請者毎に記憶された決裁者に関する情報を取得する処理を実行する。
決裁管理手段２１６は、決裁者からの指示に基づいて、各申請についての決裁管理を行なう処理を実行する。
【００３８】
申請通知手段２１７は、申請があったことを各決裁者に通知する処理を実行する。申請通知手段２１７は、利用者管理データ記憶部から、各社員コードに関連付けた連絡先（例えば、メールアドレス）を取得する。また、申請通知手段２１７は、決裁者に対して、申請の有無を定期的に通知する定期通知時刻（例えば、毎日１５時）に関するデータを保持している。また、申請通知手段２１７は、決裁期限までの猶予期間の長さを評価するための猶予基準値に関するデータを保持している。更に、申請通知手段２１７は、申請内容毎に、決裁者が内容を確認するための負荷を評価した値（負荷加重値）を記録した負荷評価テーブルを保持している。そして、申請通知手段２１７は、決裁者の確認作業の負荷を評価するための負荷基準値に関するデータを保持している。
【００３９】
異動管理手段２１８は、人事異動を取得した場合に、権限者の登録を更新する処理を実行する。この異動管理手段２１８は、異動者に対して決裁を引き継ぐ期間を付与するために、引継ぎ日数に関するデータを保持している。
【００４０】
組織表管理データ記憶部２２は、図２（ａ）に示すように、この組織（会社）の構成員（社員）の所属組織を管理するための組織表管理レコード２２０を記憶する。この組織表管理レコード２２０は、人事管理により決定された組織表が登録された場合に記録される。この組織表管理レコード２２０は、社員コード、部署コード、役職コード、資格コードに関するデータを含んで構成される。
【００４１】
社員コードデータ領域には、各社員を特定するための識別子に関するデータが記録される。
部署コードデータ領域には、この社員が属する部署を特定するための識別子に関するデータが記録される。
【００４２】
役職コードデータ領域には、この組織における役割を特定するための識別子に関するデータが記録される。
資格コードデータ領域には、この社員の資格を特定するための識別子に関するデータが記録される。この資格により、この組織における申請の決裁権限を付与できる範囲を特定することができる。
【００４３】
権限管理データ記憶部２３は、図２（ｂ）に示すように、各組織における決裁権限を有する社員に関する権限管理レコード２３０を記憶する。この権限管理レコード２３０は、人事情報に基づいて役職や資格が登録された場合や、権限の委譲が登録された場合に記録
される。この権限管理レコード２３０は、本来権限者、部署コード、カテゴリ、委譲先、委譲条件、有効期間に関するデータを含んで構成される。
【００４４】
本来権限者データ領域には、本来の決裁権限を有する社員（委譲元の権限者）を特定するための識別子（社員コード）に関するデータが記録される。そして、この権限者が、他の社員に対して、権限を委譲することができる。
【００４５】
部署コードデータ領域には、この本来権限者が決裁権限を有している組織を特定するための識別子に関するデータが記録される。
カテゴリデータ領域には、この本来権限者が決裁権限を有している各種申請を含むカテゴリを特定するための識別子に関するデータが記録される。本実施形態では、カテゴリとして「人事」、「勤怠」、「費用」を用いる。
【００４６】
委譲先データ領域には、本来権限者によって権限が委譲された社員を特定するための識別子（社員コード）に関するデータが記録される。
委譲条件データ領域には、この権限委譲先において決裁を行なうことができる条件に関するデータが記録される。本実施形態では、委譲先において、常時決裁を許容する場合と、本来の決裁者が不在の場合のみ権限を委譲する場合とを識別するためのフラグ（常時委譲フラグ又は不在時委譲フラグ）が記録される。
有効期間データ領域には、本来権限者の権限の有効期間に関するデータが記録される。
【００４７】
決裁者登録データ記憶部２４は、図２（ｃ）に示すように、各社員からの申請の決裁者に関する決裁者登録レコード２４０を記憶する。この決裁者登録レコード２４０は、各社員によって、決裁者の登録処理が行なわれた場合に記録される。この決裁者登録レコード２４０は、社員コード、カテゴリ、決裁者に関するデータを含んで構成される。
【００４８】
社員コードデータ領域には、各種申請を行なう社員を特定するための識別子に関するデータが記録される。
カテゴリデータ領域には、申請の種類を特定するための識別子に関するデータが記録される。
【００４９】
決裁者データ領域には、このカテゴリにおいて、この社員の申請についての決裁を行なう決裁者（デフォルト決裁者）を特定するための識別子（社員コード）に関するデータが記録される。なお、デフォルト決裁者が登録されていない場合には、この決裁者データ領域は空欄となる。
【００５０】
申請管理データ記憶部２５は、図２（ｄ）に示すように、社員から受け付けた申請を管理するための申請管理レコード２５０を記憶する。この申請管理レコード２５０は、申請者のクライアント端末１０から申請を受け付けた場合に記録される。この申請管理レコード２５０は、申請受付コード、申請者、カテゴリ、決裁依頼内容、決裁期限、決裁者、ステータス、履歴に関するデータを含んで構成される。
【００５１】
申請受付コードデータ領域には、受け付けた各申請を特定するための識別子に関するデータが記録される。
申請者データ領域には、この申請を行なった社員（申請者）を特定するための識別子（社員コード）に関するデータが記録される。
【００５２】
カテゴリデータ領域には、この申請内容の種類を特定するための識別子に関するデータが記録される。
決裁依頼内容データ領域には、この申請内容や、この申請において決裁を依頼する内容
に関するデータが記録される。決裁者は、この内容を確認して承認要否を決定する。
【００５３】
決裁期限データ領域には、この申請についての決裁を行なう期限を特定するための識別子に関するデータが記録される。
決裁者データ領域には、この申請についての決裁を行なう社員（決裁者）を特定するための識別子に関するデータが記録される。
【００５４】
ステータスデータ領域には、この申請についての状況を特定するための識別子に関するデータが記録される。本実施形態においては、このステータスデータ領域には、「確認待ち」、「承認」、「差し戻し」、「却下」を示す各フラグが記録される。
【００５５】
履歴データ領域には、この申請についての履歴に関するデータが記録される。この履歴データ領域には、申請者や決裁者により所定の手続が行なわれた日付（年月日）や手続内容（申請、確認等）が記録される。
【００５６】
人事管理サーバ３０は、この会社の社員の人事情報を管理するコンピュータシステムである。この人事管理サーバ３０は、組織表情報や人事異動情報を提供する処理を実行する。この組織表情報は、社員コード、部署コード、役職コード、資格コードを含む。そして、組織表情報は、前述した組織表管理データ記憶部２２に記録される。人事異動情報は、発令日、異動日、異動者の社員コード、異動元及び異動先の部署コード、役職コードを含む。
【００５７】
勤怠管理サーバ４０は、各社員の勤怠情報を管理するコンピュータシステム（勤怠管理システム）である。この勤怠管理サーバ４０は、クライアント端末１０により登録された社員コード毎の勤務スケジュールを管理する。この勤務スケジュールにより、社員の勤務状況（在席状況、出勤予定、休暇予定、出張予定等）を特定することができる。
【００５８】
上記のように構成されたシステムを用いて、決裁権限や各種申請を管理する場合の処理手順について、図３〜図７を用いて説明する。ここでは、権限委譲登録処理、決裁者登録処理、申請受付処理、決裁者通知処理、異動管理処理の順番に説明する。
【００５９】
（権限委譲登録処理）
まず、図３を用いて、権限委譲登録処理を説明する。ここでは、本来の権限者が、クライアント端末１０を用いて、決裁権限の委譲を登録するために、申請管理サーバ２０にアクセスする。
【００６０】
この場合、申請管理サーバ２０の制御部２１は、利用者認証処理を実行する（ステップＳ１−１）。具体的には、制御部２１の利用者認証手段２１１は、クライアント端末１０のディスプレイに認証画面を出力する。利用者は、この認証画面において、社員コード及びパスワードを入力する。送信指示が入力された場合、クライアント端末１０は、認証要求を申請管理サーバ２０に送信する。この認証要求には、認証画面において入力された社員コード及びパスワードを含める。そして、利用者認証手段２１１は、クライアント端末１０から取得した社員コード及びパスワードを用いて、利用者認証を行なう。利用者認証ができなかった場合には、エラーメッセージをクライアント端末１０に送信する。
【００６１】
一方、利用者認証を完了した場合、利用者認証手段２１１は、組織表管理データ記憶部２２から、この社員コードが記録された組織表管理レコード２２０を取得し、この社員の部署コード及び資格コードを取得する。そして、利用者認証手段２１１は、資格コードに応じたメニュー画面をクライアント端末１０のディスプレイに出力する。資格コードにおいて権限を有する社員の場合には、メニュー画面に、権限委譲登録ボタン、権限者登録ボ
タン、申請ボタン、決裁処理ボタンを含める。一方、資格コードにおいて権限を有しない社員の場合には、メニュー画面に、決裁者登録ボタン、申請ボタンを含める。ここで、利用者（権限者）が、メニュー画面の権限委譲登録ボタンを選択する場合を想定する。この場合、クライアント端末１０は、権限委譲登録画面要求を申請管理サーバ２０に送信する。
【００６２】
権限委譲登録画面要求を受信した申請管理サーバ２０の制御部２１は、カテゴリの特定処理を実行する（ステップＳ１−２）。具体的には、制御部２１の委譲登録手段２１２は、権限管理データ記憶部２３から、認証された社員コードが本来権限者データ領域に記録されている権限管理レコード２３０を抽出する。そして、委譲登録手段２１２は、この権限管理レコード２３０に記録されているカテゴリを特定する。次に、委譲登録手段２１２は、特定したカテゴリを一覧表示させるためのカテゴリリストを作成する。そして、カテゴリリストにおいて、各カテゴリを選択可能にしたカテゴリ選択画面を生成し、クライアント端末１０のディスプレイに出力する。このカテゴリ選択画面には、各カテゴリを選択するための選択ボタンを含める。利用者は、カテゴリ選択画面において、権限を委譲するカテゴリを選択する。この場合、クライアント端末１０は、選択されたカテゴリについての選択情報を申請管理サーバ２０に送信する。
【００６３】
次に、申請管理サーバ２０の制御部２１は、カテゴリに基づいて委譲対象者候補の抽出処理を実行する（ステップＳ１−３）。具体的には、制御部２１の委譲登録手段２１２は、組織表管理データ記憶部２２から、この本来権限者が属する組織の社員の組織表管理レコード２２０を抽出する。そして、委譲登録手段２１２は、抽出した組織表管理レコード２２０を用いて、このカテゴリにおいて決裁権限を付与可能な資格コードが記録された社員（委譲先候補）の社員コードを特定する。
【００６４】
次に、申請管理サーバ２０の制御部２１は、委譲先候補の出力処理を実行する（ステップＳ１−４）。具体的には、制御部２１の委譲登録手段２１２は、特定した委譲先候補者を一覧表示した委譲先選択画面を生成し、クライアント端末１０のディスプレイに出力する。
【００６５】
次に、申請管理サーバ２０の制御部２１は、委譲先の取得処理を実行する（ステップＳ１−５）。具体的には、権限者は、委譲先選択画面において、権限を委譲する社員を選択する。更に、委譲先選択画面において、権限を委譲する場合の委譲条件（常時委譲又は不在時委譲）を選択する。そして、クライアント端末１０は、委譲先選択画面において選択された社員コード、委譲条件を含めた選択情報を申請管理サーバ２０に送信する。制御部２１の委譲登録手段２１２は、クライアント端末１０から、委譲先として選択された社員コード及び委譲条件を取得する。
【００６６】
次に、申請管理サーバ２０の制御部２１は、委譲対象者の登録処理を実行する（ステップＳ１−６）。具体的には、制御部２１の委譲登録手段２１２は、このカテゴリの権限管理レコード２３０に、クライアント端末１０から取得した委譲先の社員コード及び委譲条件を記録する。
【００６７】
（決裁者登録処理）
次に、図４を用いて、決裁者登録処理を説明する。ここでは、各種申請を行なう可能性がある社員が、クライアント端末１０を用いて、各種申請の決裁者を登録するために、申請管理サーバ２０にアクセスする。
【００６８】
この場合、申請管理サーバ２０の制御部２１は、ステップＳ１−１と同様に、利用者認証処理を実行する（ステップＳ２−１）。利用者認証を完了した場合、利用者認証手段２
１１は、メニュー画面をクライアント端末１０のディスプレイに出力する。ここでは、利用者は、メニュー画面における決裁者登録ボタンを選択する。この場合、クライアント端末１０は、決裁者登録画面要求を申請管理サーバ２０に送信する。
【００６９】
決裁者登録画面要求を受信した申請管理サーバ２０の制御部２１は、カテゴリの特定処理を実行する（ステップＳ２−２）。具体的には、制御部２１の決裁者登録手段２１３は、各種申請のカテゴリを一覧表示させるためのカテゴリリストを作成する。そして、カテゴリリストにおいて、各カテゴリを選択可能にしたカテゴリ選択画面を生成し、クライアント端末１０のディスプレイに出力する。利用者は、カテゴリ選択画面において、カテゴリを選択する。そして、クライアント端末１０は、選択されたカテゴリ情報を申請管理サーバ２０に送信する。
【００７０】
次に、申請管理サーバ２０の制御部２１は、カテゴリに基づいて権限者候補の抽出処理を実行する（ステップＳ２−３）。具体的には、制御部２１の決裁者登録手段２１３は、権限管理データ記憶部２３から、この利用者の属する部署コード、カテゴリが記録された権限管理レコード２３０を抽出する。そして、決裁者登録手段２１３は、この権限管理レコード２３０の本来権限者データ領域に記録されている社員コードを取得する。更に、決裁者登録手段２１３は、委譲条件データ領域に常時委譲フラグが記録されている権限管理レコード２３０の委譲先データ領域に記録されている社員コードを取得する。
【００７１】
次に、申請管理サーバ２０の制御部２１は、決裁者候補の出力処理を実行する（ステップＳ２−４）。具体的には、制御部２１の決裁者登録手段２１３は、先のステップにおいて権限管理レコード２３０から取得した社員コードを決裁者候補として一覧表示させるための候補者リストを作成する。そして、候補者リストにおいて各候補者を選択可能にした決裁者選択画面を生成し、クライアント端末１０のディスプレイに出力する。
【００７２】
次に、申請管理サーバ２０の制御部２１は、デフォルト決裁者の取得処理を実行する（ステップＳ２−５）。具体的には、利用者は、決裁者選択画面において、自分の申請について決裁を行なう決裁者（デフォルト決裁者）を選択する。クライアント端末１０は、決裁者選択画面において選択された決裁者の社員コード情報を申請管理サーバ２０に送信する。制御部２１の決裁者登録手段２１３は、クライアント端末１０から、デフォルト決裁者として選択された社員コードを取得する。
【００７３】
次に、申請管理サーバ２０の制御部２１は、デフォルト決裁者の登録処理を実行する（ステップＳ２−６）。具体的には、制御部２１の決裁者登録手段２１３は、この利用者の社員コード、カテゴリの決裁者登録レコード２４０の決裁者データ領域に、クライアント端末１０から取得したデフォルト決裁者の社員コードを記録する。
【００７４】
（申請受付処理）
次に、図５を用いて、申請受付処理を説明する。ここでは、各種申請を行なう社員（申請者）が、クライアント端末１０を用いて、各種申請を行なうために、申請管理サーバ２０にアクセスする。
【００７５】
この場合、申請管理サーバ２０の制御部２１は、ステップＳ１−１と同様に、利用者認証処理を実行する（ステップＳ３−１）。利用者認証を完了した場合、利用者認証手段２１１は、メニュー画面をクライアント端末１０のディスプレイに出力する。ここでは、利用者は、メニュー画面における申請ボタンを選択する。この場合、クライアント端末１０は、申請画面要求を申請管理サーバ２０に送信する。
【００７６】
次に、申請管理サーバ２０の制御部２１は、申請の受付処理を実行する（ステップＳ３
−２）。具体的には、制御部２１の申請受付手段２１４は、申請受付画面をクライアント端末１０のディスプレイに出力する。この申請受付画面には、申請内容を選択するための選択ボタンが設けられている。そして、利用者は、所望の申請内容についての選択ボタンを選択する。この場合、クライアント端末１０は、選択された申請内容についての受付画面要求を申請管理サーバ２０に送信する。
【００７７】
申請受付画面要求を受信した申請受付手段２１４は、選択された申請についての受付画面を、クライアント端末１０のディスプレイに出力する。この受付画面には、必要事項（決裁依頼内容）や決裁期限を入力するための各入力欄が設けられている。利用者は、この申請受付画面に必要事項を入力する。更に、決裁の期限を設ける場合には、申請受付画面において決裁期限を入力する。そして、クライアント端末１０は、入力された決裁依頼内容を申請管理サーバ２０に送信する。
【００７８】
次に、申請管理サーバ２０の制御部２１は、申請内容に基づいて決裁者候補の抽出処理を実行する（ステップＳ３−３）。具体的には、制御部２１の申請受付手段２１４は、カテゴリ管理テーブルを用いて、申請内容に対応するカテゴリを特定して、決裁者情報取得手段２１５に受け付けた申請を引き継ぐ。決裁者情報取得手段２１５は、決裁者登録データ記憶部２４から、申請者の社員コード及び申請のカテゴリが記録された決裁者登録レコード２４０を抽出する。そして、決裁者情報取得手段２１５は、この決裁者登録レコード２４０の決裁者データ領域に記録された社員コードを取得する。
【００７９】
更に、決裁者情報取得手段２１５は、権限管理データ記憶部２３を用いて、申請者が属する部署の部署コード及びカテゴリが記録された権限管理レコード２３０を抽出する。そして、決裁者情報取得手段２１５は、この権限管理レコード２３０から、本来権限者データ領域、委譲先データ領域に記録された社員コードを取得する。この社員コードにより、デフォルト決裁者の権限の有効性を確認し、他の権限者を特定することができる。
【００８０】
なお、権限管理レコード２３０の有効期限を経過している権限者は、決裁者候補の対象外として除外する。
また、決裁者登録レコード２４０の決裁者データ領域が空欄の場合には、デフォルト決裁者を特定できないので、すべての権限者を決裁者候補として特定する。このような決裁者登録レコード２４０を用いて申請を行なう場合には、決裁者情報取得手段２１５は、クライアント端末１０に対して決裁者登録処理の再実行を促す。
【００８１】
次に、申請管理サーバ２０の制御部２１は、デフォルト決裁者の勤怠情報の取得処理を実行する（ステップＳ３−４）。具体的には、制御部２１の決裁者情報取得手段２１５は、決裁者登録レコード２４０の決裁者データ領域に記録された社員コードについての勤務スケジュールを、勤怠管理サーバ４０から取得する。ここでは、当日以降の勤務スケジュールを取得する。
【００８２】
次に、申請管理サーバ２０の制御部２１は、勤怠情報に基づいて決裁者の特定処理を実行する（ステップＳ３−５）。具体的には、制御部２１の決裁者情報取得手段２１５は、デフォルト決裁者及び他の権限者を一覧表示させるための決裁者候補リストを作成する。そして、決裁者候補リストにおいて、各決裁者候補を選択可能にした決裁者選択画面を生成し、クライアント端末１０のディスプレイに出力する。この決裁者選択画面には、勤怠管理サーバ４０から取得した勤務スケジュールを含める。なお、本来権限者がデフォルト決裁者として登録されており、このデフォルト決裁者が不在（出張又は休暇）であって、委譲条件データ領域に不在時委譲フラグが記憶されている場合には、決裁者情報取得手段２１５は、委譲先の社員コードをデフォルト決裁者として出力する。
【００８３】
申請者は、デフォルト決裁者の勤務スケジュールにおいて決裁判断可能と判定した場合には、デフォルト決裁者を決裁者として特定する。一方、勤務スケジュールにおいて決裁判断不可と判定した場合には、他の権限者（本来権限者又は委譲先の社員）を決裁者として特定する。そして、クライアント端末１０は、申請者により選択された決裁者情報を申請管理サーバ２０に送信する。
【００８４】
決裁者情報を受信した申請管理サーバ２０の制御部２１は、申請の登録処理を実行する（ステップＳ３−６）。具体的には、制御部２１の申請受付手段２１４は、申請受付コードを付与し、申請者〜決裁期限を設定した申請管理レコード２５０を生成し、申請管理データ記憶部２５に記録する。この場合、ステータスデータ領域に「確認待ち」フラグ、履歴データ領域に申請年月日を記録する。
【００８５】
（決裁者通知処理）
次に、図６を用いて、決裁者通知処理を説明する。
まず、申請管理サーバ２０の制御部２１は、未決裁の申請があるかどうかについての判定処理を実行する（ステップＳ４−１）。具体的には、制御部２１の申請通知手段２１７は、申請管理データ記憶部２５において、ステータスデータ領域に「確認待ち」フラグが記録された申請管理レコード２５０を検索する。
【００８６】
ここで、申請が登録されていない場合（ステップＳ４−１において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、決裁者通知処理を終了する。
一方、申請が登録されている場合（ステップＳ４−１において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、定期通知時刻を経過しているかどうかについての判定処理を実行する（ステップＳ４−２）。具体的には、制御部２１の申請通知手段２１７は、現在時刻をシステムタイマから取得し、現在時刻と定期通知時刻とを比較することにより、定期通知時刻を経過しているかどうかを判定する。
【００８７】
定期通知時刻を経過している場合（ステップＳ４−２において「ＹＥＳ」の場合）、通知処理を実行する（ステップＳ４−３）。具体的には、制御部２１の申請通知手段２１７は、すべての申請管理レコード２５０に記録された各決裁者の連絡先を、利用者管理データ記憶部から取得する。そして、申請通知手段２１７は、確認待ちの申請があることを示したメッセージを含めた決裁依頼を送信する。この決裁依頼を受け取った決裁者は、申請管理サーバ２０にアクセスして、後述する決裁処理を行なう。
【００８８】
一方、定期通知時刻を経過していない場合（ステップＳ４−２において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、未決裁の申請がある決裁者毎に、以下の処理を繰り返して実行する。
【００８９】
ここでは、申請管理サーバ２０の制御部２１は、急ぎの申請があるかどうかについての判定処理を実行する（ステップＳ４−４）。具体的には、制御部２１の申請通知手段２１７は、この決裁者の申請管理レコード２５０において、決裁期限が最も近いレコードを特定する。そして、申請通知手段２１７は、この決裁期限までの猶予期間の長さを算出し、猶予基準値と比較する。ここで、決裁期限までの猶予期間の長さが猶予基準値以下の場合には、急ぎの申請があると判定する。
【００９０】
急ぎの申請があると判定した場合（ステップＳ４−４において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、通知処理を実行する（ステップＳ４−７）。具体的には、制御部２１の申請通知手段２１７は、この申請管理レコード２５０に記録された決裁者の連絡先を、利用者管理データ記憶部から取得する。そして、申請通知手段２１７は、確認待ちの申請があることを示したメッセージを含めた決裁依頼を送信する。
【００９１】
一方、急ぎの申請がないと判定した場合（ステップＳ４−４において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、決裁対象の申請について確認作業負荷の算出処理を実行する（ステップＳ４−５）。具体的には、制御部２１の申請通知手段２１７は、抽出した各申請管理レコード２５０の申請について、申請内容に応じた負荷加重値を負荷評価テーブルから取得する。そして、申請通知手段２１７は、各申請の負荷加重値を総和することにより、負荷総和値を算出する。
【００９２】
次に、申請管理サーバ２０の制御部２１は、確認作業の負荷総和値が負荷基準値以上かどうかについての判定処理を実行する（ステップＳ４−６）。具体的には、制御部２１の申請通知手段２１７は、算出した負荷総和値と負荷基準値とを比較することにより、確認作業の負荷総和値が負荷基準値以上かどうかを判定する。
【００９３】
確認作業の負荷総和値が負荷基準値以上の場合（ステップＳ４−６において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、通知処理を実行する（ステップＳ４−７）。
【００９４】
一方、確認作業の負荷総和値が負荷基準値未満の場合（ステップＳ４−６において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、この決裁者についての処理を終了する。そして、ステップＳ４−４〜Ｓ４−７の処理を、未決裁の申請管理レコード２５０の決裁者毎に繰り返す。
【００９５】
（決裁処理）
次に、決裁処理を説明する。ここでは、決裁依頼を受け取った決裁者が、クライアント端末１０を用いて、決裁依頼内容を確認して承認可否を判断するために、申請管理サーバ２０にアクセスする。
【００９６】
この場合、申請管理サーバ２０の制御部２１は、利用者認証処理を実行する。そして、利用者は、メニュー画面における決裁処理ボタンを選択する。この場合、クライアント端末１０は、決裁処理画面要求を申請管理サーバ２０に送信する。
【００９７】
決裁処理画面要求を受信した場合には、申請管理サーバ２０の制御部２１は、未決裁の申請の一覧表示処理を実行する。具体的には、制御部２１の決裁管理手段２１６は、申請管理データ記憶部２５から、この決裁者の社員コードが記録され、未確認の申請についての申請管理レコード２５０を抽出する。そして、決裁管理手段２１６は、抽出した申請管理レコード２５０に記録された決裁依頼内容を一覧表示させた決裁処理画面をクライアント端末１０のディスプレイに出力する。
【００９８】
決裁者は、クライアント端末１０を用いて、「承認」、「差し戻し」又は「却下」のいずれかを入力する。そして、制御部２１の決裁管理手段２１６は、クライアント端末１０から、申請についての確認結果通知を受信する。この確認結果通知には、「承認」、「差し戻し」又は「却下」のいずれかの指示を含める。
【００９９】
確認結果通知に「差し戻し」指示又は「却下」指示が含まれている場合、申請管理サーバ２０の制御部２１は、差し戻し処理又は却下処理を実行する。具体的には、制御部２１の決裁管理手段２１６は、申請管理レコード２５０に、ステータスとして「差し戻し」フラグ又は「却下」フラグを記録する。次に、決裁管理手段２１６は、この申請管理レコード２５０に記録された申請者の連絡先を利用者管理データ記憶部から取得する。そして、決裁管理手段２１６は、この連絡先に対して、申請が差し戻し又は却下されたことを知らせるメッセージを送信する。差し戻しの場合、申請者は、必要に応じて再申請を行なう。
【０１００】
一方、決裁結果通知に「承認」指示が含まれている場合、申請管理サーバ２０の制御部２１は、決裁結果の通知処理を実行する。具体的には、制御部２１の決裁管理手段２１６は、申請管理レコード２５０に、ステータスとして「承認」フラグを記録する。次に、決裁管理手段２１６は、この申請管理レコード２５０に記録された申請者の連絡先に対して、申請が決裁されたことを知らせるメッセージを送信する。
【０１０１】
（異動管理処理）
次に、図７を用いて、異動管理処理を説明する。
申請管理サーバ２０の制御部２１は、異動情報の取得処理を実行する（ステップＳ５−１）。具体的には、制御部２１の異動管理手段２１８は、人事管理サーバ３０から人事異動情報を取得する。この人事異動情報には、発令日、異動日、異動者の社員コード、異動元及び異動先の部署コード、役職コードを含む。
【０１０２】
次に、申請管理サーバ２０の制御部２１は、権限を委譲していた委譲元の異動者の検索処理を実行する（ステップＳ５−２）。具体的には、制御部２１の異動管理手段２１８は、権限管理レコード２３０の本来権限者データ領域に記録された社員コードを取得する。そして、異動管理手段２１８は、人事異動情報において、本来権限者（委譲元）の社員コードを検索する。
【０１０３】
次に、申請管理サーバ２０の制御部２１は、委譲元の異動があるかどうかについての判定処理を実行する（ステップＳ５−３）。具体的には、制御部２１の異動管理手段２１８は、人事異動情報の中に、本来権限者（委譲元）の社員コードが含まれている場合には、委譲元の異動があると判定する。
【０１０４】
委譲元の異動があると判定した場合（ステップＳ５−３において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、新権限者の登録処理を実行する（ステップＳ５−４）。具体的には、制御部２１の異動管理手段２１８は、人事異動情報において、この委譲元の部署を異動先とする社員であって、委譲元と同じ役職の社員を特定する。そして、異動管理手段２１８は、特定した社員コードを本来権限者データ領域に記録した権限管理レコード２３０を生成し、権限管理データ記憶部２３に記録する。この場合、部署コード、カテゴリ、委譲先の各データ領域には、この部署からの異動者の権限管理レコード２３０と同じデータを記録する。
【０１０５】
次に、申請管理サーバ２０の制御部２１は、異動者の権限の更新処理を実行する（ステップＳ５−５）。具体的には、制御部２１の異動管理手段２１８は、この部署からの異動者の異動日に引継ぎ日数を加算した有効期間を算出する。そして、異動管理手段２１８は、異動者の権限管理レコード２３０に有効期間を記録する。
【０１０６】
更に、異動管理手段２１８は、決裁者登録データ記憶部２４において、この異動者の社員コードが決裁者データ領域に記録された決裁者登録レコード２４０を検索する。そして、この決裁者登録レコード２４０を抽出した場合には、異動管理手段２１８は、決裁者データ領域に記録されている社員コードを削除する。
【０１０７】
次に、申請管理サーバ２０の制御部２１は、権限を委譲されていた委譲先の異動者の検索処理を実行する（ステップＳ５−６）。具体的には、制御部２１の異動管理手段２１８は、権限管理レコード２３０の委譲先データ領域に記録された社員コードを取得する。そして、異動管理手段２１８は、人事異動情報において、委譲先の社員コードを検索する。
【０１０８】
次に、申請管理サーバ２０の制御部２１は、委譲先の異動があるかどうかについての判
定処理を実行する（ステップＳ５−７）。具体的には、制御部２１の異動管理手段２１８は、人事異動情報の中に、委譲先の社員コードが含まれている場合には、委譲先の異動があると判定する。
【０１０９】
委譲先の異動がある場合（ステップＳ５−７において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、委譲先の権限の抹消処理を実行する（ステップＳ５−８）。具体的には、制御部２１の異動管理手段２１８は、権限管理レコード２３０の委譲先データ領域に記録されている社員コードを削除する。
【０１１０】
更に、異動管理手段２１８は、決裁者登録データ記憶部２４において、委譲先の社員コードが決裁者データ領域に記録されている決裁者登録レコード２４０を検索する。そして、この決裁者登録レコード２４０を抽出した場合には、異動管理手段２１８は、決裁者データ領域に記録されている社員コードを削除する。
【０１１１】
本実施形態によれば、以下のような効果を得ることができる。
（１）本実施形態では、権限委譲登録処理を実行する。この処理において、本来権限者や委譲先の社員コードを記録した権限管理レコード２３０が権限管理データ記憶部２３に登録される。これにより、本来の権限者から権限を委譲された社員を決裁者とすることができる。
【０１１２】
（２）本実施形態では、決裁者登録処理を実行する。この処理において、自分の決裁依頼内容を確認する決裁者を記録した決裁者登録レコード２４０が決裁者登録データ記憶部２４に登録される。これにより、申請を行なう可能性がある社員自身が、予め決裁者を登録しておくことができる。
【０１１３】
（３）本実施形態では、申請受付処理において、申請管理サーバ２０の制御部２１は、申請内容に基づいて決裁者候補の抽出処理（ステップＳ３−３）、デフォルト決裁者の勤怠情報の取得処理（ステップＳ３−４）を実行する。これにより、デフォルト決裁者による決裁判断の可否を判断することができる。
【０１１４】
そして、申請管理サーバ２０の制御部２１は、勤怠情報に基づいて決裁者の特定処理を実行する（ステップＳ３−５）。具体的には、制御部２１の決裁者情報取得手段２１５は、デフォルト決裁者及び他の権限者を一覧表示させるための決裁者候補リストを作成する。これにより、デフォルト決裁者による決裁判断が困難な場合には、他の権限者を決裁者として選択することができる。
【０１１５】
（４）本実施形態では、決裁者通知処理においては、申請が登録されている場合（ステップＳ４−１において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、定期通知時刻を経過しているかどうかについての判定処理を実行する（ステップＳ４−２）。そして、定期通知時刻を経過している場合（ステップＳ４−２において「ＹＥＳ」の場合）、通知処理を実行する（ステップＳ４−３）。これにより、申請があることを、定期的に決裁者に通知することができる。
【０１１６】
更に、申請管理サーバ２０の制御部２１は、急ぎの申請があるかどうかについての判定処理を実行する（ステップＳ４−４）。急ぎの申請があると判定した場合（ステップＳ４−４において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、通知処理を実行する（ステップＳ４−７）。これにより、急いで決裁判断をしなければならない申請について、迅速に対応することができる。
【０１１７】
更に、申請管理サーバ２０の制御部２１は、確認作業の負荷総和値が負荷基準値以上か
どうかについての判定処理を実行する（ステップＳ４−６）。確認作業の負荷総和値が負荷基準値以上の場合（ステップＳ４−６において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、通知処理を実行する（ステップＳ４−７）。これにより、まとめて通知することにより、決裁者にとっての煩雑さを抑制するとともに、確認作業の負荷が過大になる前に、決裁依頼を通知することができる。
【０１１８】
（５）本実施形態では、異動管理処理において、委譲元の異動があると判定した場合（ステップＳ５−３において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、新権限者の登録処理（ステップＳ５−４）、異動者の権限の更新処理（ステップＳ５−５）を実行する。これにより、本来の権限者が異動した場合にも、申請についての決裁を効率的に引き継ぐことができる。
【０１１９】
更に、委譲先の異動がある場合（ステップＳ５−７において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、権限を委譲されていた委譲先の権限の抹消処理を実行する（ステップＳ５−８）。これにより、人事異動に対して、的確な権限管理を行なうことができる。
【０１２０】
なお、上記各実施形態は以下のように変更してもよい。
・ 上記実施形態では、申請管理サーバ２０の制御部２１は、カテゴリに基づいて委譲対象者候補の抽出処理を実行する（ステップＳ１−３）。ここで、委譲登録手段２１２は、抽出した組織表管理レコード２２０を用いて、このカテゴリにおいて決裁権限を付与可能な資格コードが記録された社員（委譲先候補）の社員コードを特定する。この場合、決裁権限の付与可能な者の特定は、資格コードに基づくものに限定されるものではない。例えば、役職コードや、勤続年数等を用いることもできる。この場合には、委譲登録手段２１２に、決裁権限の付与可能条件を記録しておく。更に、組織表管理データ記憶部２２に、この付与可能条件を判定するための情報（例えば、勤続年数）を記憶しておく。
【０１２１】
・ 上記実施形態では、権限管理データ記憶部２３は、各組織における決裁権限を有する社員に関する権限管理レコード２３０を記憶する。この委譲条件データ領域には、委譲先において、常時決裁を許容する場合と、本来の決裁者が不在の場合のみ権限を委譲する場合とを識別するためのフラグ（常時委譲フラグ又は不在時委譲フラグ）が記録される。これに対して、委譲先の権限者が不在の場合には本来権限者が決裁することを委譲条件として設定できるようにしてもよい。
【０１２２】
・ 上記実施形態では、急ぎの申請があると判定した場合（ステップＳ４−４において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、通知処理を実行する（ステップＳ４−７）。ここで、所定の申請内容については、決裁期限を判断することなく、通知処理（ステップＳ４−７）を実行するようしてもよい。この場合には、即時の通知処理の対象となる申請内容を申請通知手段２１７に保持させておく。
【０１２３】
・ 上記実施形態では、申請管理サーバ２０の制御部２１は、決裁対象の申請について確認作業負荷の算出処理を実行する（ステップＳ４−５）。そして、申請管理サーバ２０の制御部２１は、確認作業の負荷総和値が負荷基準値以上かどうかについての判定処理を実行する（ステップＳ４−６）。ここで、負荷基準値を決裁者毎に決定するようにしてもよい。この場合には、権限者毎に負荷基準値を記録した負荷基準値データ記憶部を設ける。そして、決裁者毎に負荷総和値と負荷基準値とを比較して、判定処理を行なう。
【０１２４】
また、決裁者の状況に応じて、負荷基準値を変更するようにしてもよい。例えば、決裁者の勤怠情報を取得し、所定期間内に休暇や出張による不在情報が登録されている場合には、制御部２１が、所定の割合で負荷基準値を下げる処理を行なう。これにより、決裁者
が不在になる前に、申請があることを通知することができる。
【０１２５】
・ 上記実施形態では、申請受付処理において、申請管理サーバ２０の制御部２１は、勤怠情報に基づいて決裁者の特定処理を実行する（ステップＳ３−５）。具体的には、制御部２１の申請受付手段２１４は、勤怠管理サーバ４０から取得した勤務スケジュールをクライアント端末１０のディスプレイに出力する。そして、クライアント端末１０は、申請者により選択された決裁者情報を申請管理サーバ２０に送信する。これに代えて、申請管理サーバ２０が決裁者を決定するようにしてもよい。以下、権限者の勤怠情報に応じて、決裁者を決定する処理を、図８を用いて説明する。
【０１２６】
まず、申請管理サーバ２０の制御部２１は、利用者認証処理を実行する（ステップＳ６−１）。具体的には、制御部２１の利用者認証手段２１１は、ステップＳ１−１と同様に、利用者認証処理を実行する。
【０１２７】
次に、申請管理サーバ２０の制御部２１は、ステップＳ３−２〜Ｓ３−４と同様に、申請の受付処理（ステップＳ６−２）、申請内容に基づいて決裁者候補の抽出処理（ステップＳ６−３）、デフォルト決裁者の勤怠情報の取得処理（ステップＳ６−４）を実行する。
【０１２８】
次に、申請管理サーバ２０の制御部２１は、デフォルト決裁者が決裁判断可能かどうかについての判定処理を実行する（ステップＳ６−５）。具体的には、制御部２１の決裁者情報取得手段２１５は、取得した出勤予定と、申請画面に入力された決裁期限とを比較する。デフォルト決裁者の勤怠情報において、決裁期限までに出勤予定が記録されている場合には、決裁者情報取得手段２１５は、デフォルト決裁者により決裁判断可能と判定する。一方、デフォルト決裁者の勤怠情報において、決裁期限までに出勤予定が記録されていない場合には、デフォルト決裁者により決裁判断不可と判定する。
【０１２９】
デフォルト決裁者により決裁判断可能と判定した場合（ステップＳ６−５において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、デフォルト決裁者の設定処理を実行する（ステップＳ６−６）。具体的には、制御部２１の申請受付手段２１４は、デフォルト決裁者の社員コードを、申請管理レコード２５０の決裁者データ領域に記録する。
【０１３０】
一方、デフォルト決裁者により決裁判断不可と判定した場合（ステップＳ６−５において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、他の権限者の勤怠情報の取得処理を実行する（ステップＳ６−７）。具体的には、制御部２１の決裁者情報取得手段２１５は、権限管理データ記憶部２３を用いて、申請者が属する部署に属する社員であって、この申請のカテゴリについて決裁できる資格を有する他の社員を検索する。そして、決裁者情報取得手段２１５は、この社員の勤怠情報を勤怠管理サーバ４０から取得する。
【０１３１】
次に、申請管理サーバ２０の制御部２１は、他の権限者が決裁判断可能かどうかについての判定処理を実行する（ステップＳ６−８）。具体的には、制御部２１の決裁者情報取得手段２１５は、勤怠管理サーバ４０から取得した勤怠情報における出勤予定と決裁期限とを比較することにより、他の権限者が決裁判断可能かどうかを判定する。
【０１３２】
決裁期限までに出勤予定があり、他の権限者が決裁判断可能な場合（ステップＳ６−８において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、他の権限者の設定処理を実行する（ステップＳ６−９）。具体的には、制御部２１の申請受付手段２１４は、他の権限者の社員コードを、申請管理レコード２５０の決裁者データ領域に記録する。
【０１３３】
次に、申請管理サーバ２０の制御部２１は、申請の登録処理を実行する（ステップＳ６
−１０）。具体的には、制御部２１の申請受付手段２１４は、生成した申請管理レコード２５０を申請管理データ記憶部２５に記録する。
【０１３４】
一方、他の権限者においても決裁判断不可と判定した場合（ステップＳ６−８において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、申請者に対して注意喚起の出力処理を実行する（ステップＳ６−１１）。具体的には、制御部２１の申請受付手段２１４は、申請者のクライアント端末１０に対して、決裁期限までに申請を確認できる権限者がいないことを示すメッセージを出力する。このメッセージを確認した申請者は、他の権限者を探して決裁を依頼する。
これにより、勤怠情報に基づいて、決裁期限に間に合うように、申請についての決裁者を登録することができる。
【０１３５】
・ 上記実施形態では、申請受付処理において、申請管理サーバ２０の制御部２１は、勤怠情報に基づいて決裁者の特定処理を実行する（ステップＳ３−５）。これに加えて、社員の出勤予定が変更された場合に、この社員が決裁者となっている申請に対して注意喚起するようにしてもよい。出勤予定を変更した場合の対応処理を、図９を用いて説明する。
【０１３６】
ここでは、申請管理サーバ２０の制御部２１は、権限者の出勤予定変更情報の取得処理を実行する（ステップＳ７−１）。具体的には、制御部２１の決裁管理手段２１６は、勤怠管理サーバ４０から、新たに出張予定が登録された社員や、休暇予定が登録された社員についての勤怠情報を取得する。そして、決裁管理手段２１６は、出勤予定が変更された勤怠情報の中で、権限管理データ記憶部２３において権限者（本来権限者、委譲先の社員）として登録されている社員の勤怠情報を抽出する。
【０１３７】
次に、申請管理サーバ２０の制御部２１は、決裁者として登録されている申請の特定処理を実行する（ステップＳ７−２）。具体的には、制御部２１の決裁管理手段２１６は、申請管理データ記憶部２５において、出勤予定に変更があった権限者の社員コードが決裁者データ領域に記録された申請管理レコード２５０を検索する。
【０１３８】
決裁者として登録された申請管理レコード２５０を検出した場合には、申請毎に以下の処理を繰り返す。
ここでは、申請管理サーバ２０の制御部２１は、決裁期限内に決裁判断可能かどうかについての判定処理を実行する（ステップＳ７−３）。具体的には、制御部２１の決裁管理手段２１６は、勤怠管理サーバ４０から取得した出勤予定と、申請管理レコード２５０に登録された決裁期限とを比較する。この決裁者の勤怠情報において、決裁期限までに出勤予定が記録されている場合には、申請受付手段２１４は、登録された決裁者により決裁判断可能と判断する。一方、登録された決裁者の勤怠情報において、決裁期限までに出勤予定がなくなった場合には、この決裁者による決裁判断は不可と判断する。
【０１３９】
決裁期限内に決裁判断可能と判定した場合（ステップＳ７−３において「ＹＥＳ」の場合）、この申請についての処理を終了する。
一方、決裁期限内に決裁判断不可と判定した場合（ステップＳ７−３において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、ステップＳ６−７〜Ｓ６−８と同様に、他の権限者の勤怠情報の取得処理（ステップＳ７−４）、他の権限者が決裁判断可能かどうかについての判定処理（ステップＳ７−５）を実行する。
【０１４０】
他の権限者においても決裁判断不可と判定した場合（ステップＳ７−５において「ＮＯ」の場合）、申請管理サーバ２０の制御部２１は、ステップＳ６−１１と同様に、申請者に対する注意喚起出力処理を実行する（ステップＳ７−６）。
【０１４１】
一方、他の権限者が決裁判断可能と判定した場合（ステップＳ７−５において「ＹＥＳ」の場合）、申請管理サーバ２０の制御部２１は、他の権限者の設定処理を実行する（ステップＳ７−７）。具体的には、制御部２１の申請受付手段２１４は、他の権限者の社員コードを、申請管理レコード２５０の決裁者データ領域に記録する。
【０１４２】
次に、申請管理サーバ２０の制御部２１は、変更通知処理を実行する（ステップＳ７−８）。具体的には、制御部２１の申請受付手段２１４は、決裁者を変更したことを申請者の連絡先に通知する。
以上の処理を申請毎に繰り返す。
これにより、出勤予定の変更に応じて、的確な決裁者を設定することができる。
【０１４３】
・ 上記実施形態では、決裁者登録処理において、申請管理サーバ２０の制御部２１は、デフォルト決裁者の取得処理を実行する（ステップＳ２−５）。ここで、決裁実績に応じて、デフォルト決裁者を登録するようにしてもよい。この決裁者登録処理を、図１０を用いて説明する。
【０１４４】
ここでは、申請管理サーバ２０の制御部２１は、ステップＳ１−１と同様に、利用者認証処理を実行する（ステップＳ８−１）。
次に、申請管理サーバ２０の制御部２１は、ステップＳ２−２〜Ｓ２−３と同様に、カテゴリの特定処理（ステップＳ８−２）〜カテゴリに基づいて決裁者候補の抽出処理（ステップＳ８−３）を実行する。
【０１４５】
次に、申請管理サーバ２０の制御部２１は、申請状況に応じて決裁者候補の優先順位の決定処理を実行する（ステップＳ８−４）。具体的には、制御部２１の決裁者登録手段２１３は、特定した権限候補者の承認を行なった申請についての処理実績を取得する。ここでは、権限候補者の社員コードが記録されるとともに、「承認済」又は「差し戻し」のいずれかのフラグが記録された申請管理レコード２５０を、申請管理データ記憶部２５から抽出する。
【０１４６】
そして、決裁者登録手段２１３は、承認された申請数を総数で除算することにより、承認率を算出する。なお、申請から確認（承認又は差し戻し）までに要した時間を用いて優先順位を決めるようにしてもよい。この場合には、確認までの所要時間が短い決裁者候補に対して高い優先順位を設定する。
【０１４７】
次に、申請管理サーバ２０の制御部２１は、決裁者候補の出力処理を実行する（ステップＳ８−５）。具体的には、制御部２１の決裁者登録手段２１３は、取得した社員コードを決裁者候補として一覧表示させるための候補者リストを作成する。この候補者リストでは、各決裁者候補に対して承認率を含める。そして、候補者リストにおいて各候補者を選択可能にした決裁者選択画面を生成し、クライアント端末１０に送信する。
【０１４８】
次に、申請管理サーバ２０の制御部２１は、ステップＳ２−５〜Ｓ２−６と同様に、デフォルト決裁者の取得処理（ステップＳ８−６）、デフォルト決裁者の登録処理（ステップＳ８−７）を実行する。
これにより、申請を行なう社員は、申請状況を考慮して、的確なデフォルト決裁者を登録することができる。
【０１４９】
・ 上記実施形態では、所属部署の異動情報に基づいて異動管理処理を行なう。異動管理処理の対象となる異動情報は所属部署の異動に限定されるものではない。例えば、退職、休職、降格等の異動情報を取得して異動管理処理を行なうようにしてもよい。
【０１５０】
また、昇格や復職等の異動情報を取得して、権限委譲登録処理、決裁者登録処理を再実行するようにしてもよい。具体的には、昇格や復職等により、新たに決裁権限を付与可能な資格コードを有する委譲対象者候補が、組織表管理データ記憶部２２に登録される。申請管理サーバ２０の制御部２１は、組織表管理データ記憶部２２において、新たな委譲対象者候補の登録を検知した場合、権限委譲登録処理、決裁者登録処理を再実行する。この場合には、新たに委譲対象者候補が登録された組織を特定し、その組織の本来の権限者に対して、権限委譲登録処理の再実行を促すメッセージを送信する。また、新たな委譲対象者が登録された場合には、その委譲対象者が属する組織において、各種申請を行なう可能性がある社員に対して、権限委譲登録処理の再実行を促すメッセージを送信する。
【符号の説明】
【０１５１】
１０…クライアント端末、２０…申請管理サーバ、２１…制御部、２１１…利用者認証手段、２１２…委譲登録手段、２１３…決裁者登録手段、２１４…申請受付手段、２１５…決裁者情報取得手段、２１６…決裁管理手段、２１７…申請通知手段、２１８…異動管理手段、２２…組織表管理データ記憶部、２３…権限管理データ記憶部、２４…決裁者登録データ記憶部、２５…申請管理データ記憶部、３０…人事管理サーバ、４０…勤怠管理サーバ。
【特許請求の範囲】
【請求項１】
申請内容に対応した決裁権限を有する権限者と、その決裁権限の委譲先についての権限情報を記憶した権限管理情報記憶手段と、
各申請について決裁を行なうデフォルト決裁者情報を記憶した決裁者登録情報記憶手段と、
申請についての決裁を管理する制御手段とを備えた権限管理システムであって、
前記制御手段が、
クライアント端末からアクセスした権限者を認証し、前記権限者において申請内容に対応させて決裁権限を委譲できる委譲先候補者を特定して前記クライアント端末に出力する手段と、
前記委譲先候補者の中で選択された利用者に対して、前記権限管理情報記憶手段において、前記申請内容の決裁権限が委譲された権限者として登録を行なう手段と、
クライアント端末からアクセスした申請者を認証し、前記クライアント端末から取得した申請内容に基づいて、前記権限管理情報記憶手段において、決裁を行なうことができる権限者を特定し、決裁者候補として前記クライアント端末に出力する手段と、
前記決裁者候補の中で選択された権限者を、前記申請内容についてのデフォルト決裁者として、前記決裁者登録情報記憶手段に登録する手段と
を備えたことを特徴とする権限管理システム。
【請求項２】
各申請について決裁者が登録された申請管理情報を記憶する申請管理情報記憶手段を更に備え、
前記制御手段は、各権限者の勤怠情報を記憶した勤怠管理システムに接続されており、
前記制御手段が、
クライアント端末からアクセスした申請者を認証し、前記クライアント端末から申請を取得した場合、前記決裁者登録情報記憶手段を用いてデフォルト決裁者を特定し、
前記デフォルト決裁者の勤怠情報を前記勤怠管理システムから取得して、前記クライアント端末に出力し、
前記クライアント端末から取得した決裁者情報を含めた申請管理情報を前記申請管理情報記憶手段に記録する手段を更に備えたことを特徴とする請求項１に記載の権限管理システム。
【請求項３】
前記制御手段が、前記勤怠情報により、前記デフォルト決裁者により決裁判断ができないと判定した場合、前記権限管理情報記憶手段に記録された他の権限者を、前記申請の決裁者として前記申請管理情報記憶手段に登録する手段を更に備えたことを特徴とする請求項２に記載の権限管理システム。
【請求項４】
前記勤怠情報において、申請の決裁期限までに前記デフォルト決裁者の出勤予定がない場合に、前記デフォルト決裁者により決裁判断ができないと判定することを特徴とする請求項３に記載の権限管理システム。
【請求項５】
前記制御手段が、
前記申請内容に応じて、前記申請管理情報記憶手段に記録された申請の決裁者毎に、申請された決裁依頼内容を確認するための負荷を計算する手段と、
前記負荷が基準値を超えた場合に、前記決裁者に対して申請があったことを通知する手段と
を更に備えたことを特徴とする請求項２〜４のいずれか一つに記載の権限管理システム。
【請求項６】
前記制御手段が、委譲元の権限者についての異動情報を取得した場合には、前記権限管理情報記憶手段に記憶された権限者の権限に対して、有効期間として引継期間を設定する
手段を更に備えたことを特徴とする請求項１〜５のいずれか一つに記載の権限管理システム。
【請求項７】
前記制御手段が、委譲元の権限者についての異動情報を取得した場合には、前記権限管理情報記憶手段に記憶された委譲元の権限者を、前記異動情報に基づいて新たな権限者に変更する手段を更に備えたことを特徴とする請求項１〜６のいずれか一つに記載の権限管理システム。
【請求項８】
前記制御手段が、委譲先の権限者についての異動情報を取得した場合には、前記権限管理情報記憶手段に記憶された委譲先の権限を抹消する手段を更に備えたことを特徴とする請求項１〜７のいずれか一つに記載の権限管理システム。
【請求項９】
申請内容に対応した決裁権限を有する権限者と、その決裁権限の委譲先についての権限情報を記憶した権限管理情報記憶手段と、
各申請について決裁を行なうデフォルト決裁者情報を記憶した決裁者登録情報記憶手段と、
申請についての決裁を管理する制御手段とを備えた権限管理システムを用いて、申請を管理するための方法であって、
前記制御手段が、
クライアント端末からアクセスした権限者を認証し、前記権限者において申請内容に対応させて決裁権限を委譲できる委譲先候補者を特定して前記クライアント端末に出力する段階と、
前記委譲先候補者の中で選択された利用者に対して、前記権限管理情報記憶手段において、前記申請内容の決裁権限が委譲された権限者として登録を行なう段階と、
クライアント端末からアクセスした申請者を認証し、前記クライアント端末から取得した申請内容に基づいて、前記権限管理情報記憶手段において、決裁を行なうことができる権限者を特定し、決裁者候補として前記クライアント端末に出力する段階と、
前記決裁者候補の中で選択された権限者を、前記申請内容についてのデフォルト決裁者として、前記決裁者登録情報記憶手段に登録する段階と
を実行することを特徴とする権限管理方法。
【請求項１０】
申請内容に対応した決裁権限を有する権限者と、その決裁権限の委譲先についての権限情報を記憶した権限管理情報記憶手段と、
各申請について決裁を行なうデフォルト決裁者情報を記憶した決裁者登録情報記憶手段と、
申請についての決裁を管理する制御手段とを備えた権限管理システムを用いて、申請を管理するためのプログラムであって、
前記制御手段を、
クライアント端末からアクセスした権限者を認証し、前記権限者において申請内容に対応させて決裁権限を委譲できる委譲先候補者を特定して前記クライアント端末に出力する手段、
前記委譲先候補者の中で選択された利用者に対して、前記権限管理情報記憶手段において、前記申請内容の決裁権限が委譲された権限者として登録を行なう手段、
クライアント端末からアクセスした申請者を認証し、前記クライアント端末から取得した申請内容に基づいて、前記権限管理情報記憶手段において、決裁を行なうことができる権限者を特定し、決裁者候補として前記クライアント端末に出力する手段、
前記決裁者候補の中で選択された権限者を、前記申請内容についてのデフォルト決裁者として、前記決裁者登録情報記憶手段に登録する手段
として機能させることを特徴とする権限管理プログラム。
【請求項１】
申請内容に対応した決裁権限を有する権限者と、その決裁権限の委譲先についての権限情報を記憶した権限管理情報記憶手段と、
各申請について決裁を行なうデフォルト決裁者情報を記憶した決裁者登録情報記憶手段と、
申請についての決裁を管理する制御手段とを備えた権限管理システムであって、
前記制御手段が、
クライアント端末からアクセスした権限者を認証し、前記権限者において申請内容に対応させて決裁権限を委譲できる委譲先候補者を特定して前記クライアント端末に出力する手段と、
前記委譲先候補者の中で選択された利用者に対して、前記権限管理情報記憶手段において、前記申請内容の決裁権限が委譲された権限者として登録を行なう手段と、
クライアント端末からアクセスした申請者を認証し、前記クライアント端末から取得した申請内容に基づいて、前記権限管理情報記憶手段において、決裁を行なうことができる権限者を特定し、決裁者候補として前記クライアント端末に出力する手段と、
前記決裁者候補の中で選択された権限者を、前記申請内容についてのデフォルト決裁者として、前記決裁者登録情報記憶手段に登録する手段と
を備えたことを特徴とする権限管理システム。
【請求項２】
各申請について決裁者が登録された申請管理情報を記憶する申請管理情報記憶手段を更に備え、
前記制御手段は、各権限者の勤怠情報を記憶した勤怠管理システムに接続されており、
前記制御手段が、
クライアント端末からアクセスした申請者を認証し、前記クライアント端末から申請を取得した場合、前記決裁者登録情報記憶手段を用いてデフォルト決裁者を特定し、
前記デフォルト決裁者の勤怠情報を前記勤怠管理システムから取得して、前記クライアント端末に出力し、
前記クライアント端末から取得した決裁者情報を含めた申請管理情報を前記申請管理情報記憶手段に記録する手段を更に備えたことを特徴とする請求項１に記載の権限管理システム。
【請求項３】
前記制御手段が、前記勤怠情報により、前記デフォルト決裁者により決裁判断ができないと判定した場合、前記権限管理情報記憶手段に記録された他の権限者を、前記申請の決裁者として前記申請管理情報記憶手段に登録する手段を更に備えたことを特徴とする請求項２に記載の権限管理システム。
【請求項４】
前記勤怠情報において、申請の決裁期限までに前記デフォルト決裁者の出勤予定がない場合に、前記デフォルト決裁者により決裁判断ができないと判定することを特徴とする請求項３に記載の権限管理システム。
【請求項５】
前記制御手段が、
前記申請内容に応じて、前記申請管理情報記憶手段に記録された申請の決裁者毎に、申請された決裁依頼内容を確認するための負荷を計算する手段と、
前記負荷が基準値を超えた場合に、前記決裁者に対して申請があったことを通知する手段と
を更に備えたことを特徴とする請求項２〜４のいずれか一つに記載の権限管理システム。
【請求項６】
前記制御手段が、委譲元の権限者についての異動情報を取得した場合には、前記権限管理情報記憶手段に記憶された権限者の権限に対して、有効期間として引継期間を設定する
手段を更に備えたことを特徴とする請求項１〜５のいずれか一つに記載の権限管理システム。
【請求項７】
前記制御手段が、委譲元の権限者についての異動情報を取得した場合には、前記権限管理情報記憶手段に記憶された委譲元の権限者を、前記異動情報に基づいて新たな権限者に変更する手段を更に備えたことを特徴とする請求項１〜６のいずれか一つに記載の権限管理システム。
【請求項８】
前記制御手段が、委譲先の権限者についての異動情報を取得した場合には、前記権限管理情報記憶手段に記憶された委譲先の権限を抹消する手段を更に備えたことを特徴とする請求項１〜７のいずれか一つに記載の権限管理システム。
【請求項９】
申請内容に対応した決裁権限を有する権限者と、その決裁権限の委譲先についての権限情報を記憶した権限管理情報記憶手段と、
各申請について決裁を行なうデフォルト決裁者情報を記憶した決裁者登録情報記憶手段と、
申請についての決裁を管理する制御手段とを備えた権限管理システムを用いて、申請を管理するための方法であって、
前記制御手段が、
クライアント端末からアクセスした権限者を認証し、前記権限者において申請内容に対応させて決裁権限を委譲できる委譲先候補者を特定して前記クライアント端末に出力する段階と、
前記委譲先候補者の中で選択された利用者に対して、前記権限管理情報記憶手段において、前記申請内容の決裁権限が委譲された権限者として登録を行なう段階と、
クライアント端末からアクセスした申請者を認証し、前記クライアント端末から取得した申請内容に基づいて、前記権限管理情報記憶手段において、決裁を行なうことができる権限者を特定し、決裁者候補として前記クライアント端末に出力する段階と、
前記決裁者候補の中で選択された権限者を、前記申請内容についてのデフォルト決裁者として、前記決裁者登録情報記憶手段に登録する段階と
を実行することを特徴とする権限管理方法。
【請求項１０】
申請内容に対応した決裁権限を有する権限者と、その決裁権限の委譲先についての権限情報を記憶した権限管理情報記憶手段と、
各申請について決裁を行なうデフォルト決裁者情報を記憶した決裁者登録情報記憶手段と、
申請についての決裁を管理する制御手段とを備えた権限管理システムを用いて、申請を管理するためのプログラムであって、
前記制御手段を、
クライアント端末からアクセスした権限者を認証し、前記権限者において申請内容に対応させて決裁権限を委譲できる委譲先候補者を特定して前記クライアント端末に出力する手段、
前記委譲先候補者の中で選択された利用者に対して、前記権限管理情報記憶手段において、前記申請内容の決裁権限が委譲された権限者として登録を行なう手段、
クライアント端末からアクセスした申請者を認証し、前記クライアント端末から取得した申請内容に基づいて、前記権限管理情報記憶手段において、決裁を行なうことができる権限者を特定し、決裁者候補として前記クライアント端末に出力する手段、
前記決裁者候補の中で選択された権限者を、前記申請内容についてのデフォルト決裁者として、前記決裁者登録情報記憶手段に登録する手段
として機能させることを特徴とする権限管理プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１２−１３８０１４（Ｐ２０１２−１３８０１４Ａ）
【公開日】平成２４年７月１９日（２０１２．７．１９）
【国際特許分類】
【出願番号】特願２０１０−２９１１４４（Ｐ２０１０−２９１１４４）
【出願日】平成２２年１２月２７日（２０１０．１２．２７）
【出願人】（５９２１３１９０６）みずほ情報総研株式会社 (187)
【公開日】平成２４年７月１９日（２０１２．７．１９）
【国際特許分類】
【出願日】平成２２年１２月２７日（２０１０．１２．２７）
【出願人】（５９２１３１９０６）みずほ情報総研株式会社 (187)
[ Back to top ]