(57)【要約】【課題】組織に拘らないプロジェクトにおける申請及び承認に関する業務の管理を行うことが可能な業務管理装置等を提供する。【解決手段】サーバ１は、帳票データテンプレート記録部２０と、帳票データ記録部２１と、従業員テーブル記録部２２と、承認者テーブル記録部２３と、組織における承認ルートに関する情報を格納した組織序列テーブル及び組織に拘らないプロジェクトにおける承認ルートに関する情報を格納したプロジェクト序列テーブルを記録する序列テーブル記録部２４と、役職テーブル記録部２５と、帳票データ作成処理部２６と、組織序列テーブル又はプロジェクト序列テーブルを参照して承認ルートを決定する承認ルート決定処理部２７と、承認・却下処理部２８と、承認ルート作成・更新処理部２９とを具備する。【選択図】図２
2008130006.tif 000002
【特許請求の範囲】
【請求項１】
申請及び承認に関する業務の管理を行うための装置であって、
組織を構成する複数の構成者及び組織における承認権限を有する複数の者に相当する１群のノードに関する情報をそれぞれ格納する複数のレコードを含む組織序列テーブルであって、各レコードが、前記組織を構成する複数の構成者又は前記組織における承認権限を有する複数の者に相当する１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、前記組織を構成する複数の構成者又は前記組織における承認権限を有する複数の者に相当する１群のノードの組織における序列を表す第２の識別子であって、前記組織を構成する複数の構成者の中の任意の者の前記第２の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより、前記組織を構成する複数の構成者の中の任意の者の組織上において上位であり且つ組織における申請に対する承認権限を有する少なくとも１人の者に相当する前記組織における承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードの前記第２の識別子を得ることが可能な前記第２の識別子を格納する第２のフィールドとを有する前記組織序列テーブルと、前記組織を構成する複数の構成者の内の組織に拘らないプロジェクトを構成する複数の構成者及びプロジェクトにおける承認権限を有する複数の者に相当する１群のノードに関する情報をそれぞれ格納する複数のレコードを含むプロジェクト序列テーブルであって、各レコードが、前記プロジェクトを構成する複数の構成者又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードを一意に特定する前記第１の識別子を格納する第１のフィールドと、前記プロジェクトを構成する複数の構成者又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードのプロジェクトにおける序列を表す第３の識別子であって、前記プロジェクトを構成する複数の構成者の中の任意の者の前記第３の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより、前記プロジェクトを構成する複数の構成者の中の任意の者のプロジェクトにおいて上位であり且つプロジェクトにおける申請に対する承認権限を有する少なくとも１人の者に相当する前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードの前記第３の識別子を得ることが可能な前記第３の識別子を格納する第２のフィールドとを有する前記プロジェクト序列テーブルと、を記録する序列テーブル記録部と、
前記組織における承認権限を有する複数の者に相当する１群のノード又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードを一意に特定する前記第１の識別子を格納する第１のフィールドと、前記組織における承認権限を有する複数の者に相当する１群のノードに係る者としての前記組織を構成する複数の構成者又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードに係る者としての前記プロジェクトを構成する複数の構成者を一意に特定する前記第１の識別子を格納する第２のフィールドとを有する承認者テーブルを記録する承認者テーブル記録部と、
申請に関するデータであって、前記組織を構成する複数の構成者の中の申請を行った者又は前記プロジェクトを構成する複数の構成者の中の申請を行った者を一意に特定する前記第１の識別子を格納する第１のフィールドと、当該申請が組織における申請であるか又はプロジェクトにおける申請であるかを識別するための第４の識別子を格納する第２のフィールドと、当該申請に対する承認が得られたか否かを表す複数のデータをそれぞれ格納する１群のフィールドとを有する前記申請に関するデータを記録する申請データ記録部と、
前記申請に関するデータ内の前記第４の識別子に基づいて前記組織序列テーブル又は前記プロジェクト序列テーブルを読み出し、前記申請に関するデータ内の前記第１の識別子に基づいて、前記申請に関するデータ内の前記第４の識別子に基づいて読み出した前記組織序列テーブル又は前記プロジェクト序列テーブルを検索することにより、前記組織を構成する複数の構成者の中の前記申請に関するデータに係る申請を行った者又は前記プロジェクトを構成する複数の構成者の中の前記申請に関するデータに係る申請を行った者の前記第２の識別子を抽出し、抽出された前記第２の識別子の末尾から前記所定の長さの値を少なくとも１回削除する演算を行うことにより得られた少なくとも１つの値を前記第２の識別子として格納している少なくとも１つのレコードを前記申請に関するデータ内の前記第４の識別子に基づいて読み出した前記組織序列テーブル又は前記プロジェクト序列テーブルから検索することにより、前記申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者に相当する前記組織における承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノード又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードを特定する少なくとも１つの前記第１の識別子を抽出し、抽出された少なくとも１つの前記第１の識別子に基づいて前記承認者テーブルを検索することにより、前記組織を構成する複数の構成者の中の前記申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者又は前記プロジェクトを構成する複数の構成者の中の前記申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者を特定する第１の処理手段と、
前記第１の処理手段によって特定された前記組織を構成する複数の構成者の中の前記申請データに係る申請に対する承認権限を有する少なくとも１人の者又は前記プロジェクトを構成する複数の構成者の中の前記申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者からの承認又は却下の指示に応じて、申請が承認されたこと又は却下されたことを表す少なくとも１つのデータを前記申請に関するデータ内の前記１群のフィールドに書き込む第２の処理手段と、
を具備する業務管理装置。
【請求項２】
前記序列テーブル記録部が、組織に拘らない複数のプロジェクトに関する情報をそれぞれ格納する複数のプロジェクト序列テーブルを記録する、請求項１記載の業務管理装置。
【請求項３】
申請及び承認に関する業務の管理を行うための方法であって、
組織を構成する複数の構成者及び組織における承認権限を有する複数の者に相当する１群のノードに関する情報をそれぞれ格納する複数のレコードを含む組織序列テーブルであって、各レコードが、前記組織を構成する複数の構成者又は前記組織における承認権限を有する複数の者に相当する１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、前記組織を構成する複数の構成者又は前記組織における承認権限を有する複数の者に相当する１群のノードの組織における序列を表す第２の識別子であって、前記組織を構成する複数の構成者の中の任意の者の前記第２の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより、前記組織を構成する複数の構成者の中の任意の者の組織上において上位であり且つ組織における申請に対する承認権限を有する少なくとも１人の者に相当する前記組織における承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードの前記第２の識別子を得ることが可能な前記第２の識別子を格納する第２のフィールドとを有する前記組織序列テーブルと、前記組織を構成する複数の構成者の内の組織に拘らないプロジェクトを構成する複数の構成者及びプロジェクトにおける承認権限を有する複数の者に相当する１群のノードに関する情報をそれぞれ格納する複数のレコードを含むプロジェクト序列テーブルであって、各レコードが、前記プロジェクトを構成する複数の構成者又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードを一意に特定する前記第１の識別子を格納する第１のフィールドと、前記プロジェクトを構成する複数の構成者又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードのプロジェクトにおける序列を表す第３の識別子であって、前記プロジェクトを構成する複数の構成者の中の任意の者の前記第３の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより、前記プロジェクトを構成する複数の構成者の中の任意の者のプロジェクトにおいて上位であり且つプロジェクトにおける申請に対する承認権限を有する少なくとも１人の者に相当する前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードの前記第３の識別子を得ることが可能な前記第３の識別子を格納する第２のフィールドとを有する前記プロジェクト序列テーブルと、を記録するステップ（ａ）と、
前記組織における承認権限を有する複数の者に相当する１群のノード又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードを一意に特定する前記第１の識別子を格納する第１のフィールドと、前記組織における承認権限を有する複数の者に相当する１群のノードに係る者としての前記組織を構成する複数の構成者又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードに係る者としての前記プロジェクトを構成する複数の構成者を一意に特定する前記第１の識別子を格納する第２のフィールドとを有する承認者テーブルを記録するステップ（ｂ）と、
申請に関するデータであって、前記組織を構成する複数の構成者の中の申請を行った者又は前記プロジェクトを構成する複数の構成者の中の申請を行った者を一意に特定する前記第１の識別子を格納する第１のフィールドと、当該申請が組織における申請であるか又はプロジェクトにおける申請であるかを識別するための第４の識別子を格納する第２のフィールドと、当該申請に対する承認が得られたか否かを表す複数のデータをそれぞれ格納する１群のフィールドとを有する前記申請に関するデータを記録するステップ（ｃ）と、
前記申請に関するデータ内の前記第４の識別子に基づいて、前記組織序列テーブル又は前記プロジェクト序列テーブルを読み出すステップ（ｄ）と、
前記申請に関するデータ内の前記第１の識別子に基づいて、ステップ（ｄ）にて読み出した前記組織序列テーブル又は前記プロジェクト序列テーブルを検索することにより、前記組織を構成する複数の構成者の中の前記申請に関するデータに係る申請を行った者又は前記プロジェクトを構成する複数の構成者の中の前記申請に関するデータに係る申請を行った者の前記第２の識別子を抽出するステップ（ｅ）と、
ステップ（ｅ）にて抽出された前記第２の識別子の末尾から前記所定の長さの値を少なくとも１回削除する演算を行うことにより得られた少なくとも１つの値を前記第２の識別子として格納している少なくとも１つのレコードをステップ（ｄ）にて読み出した前記組織序列テーブル又は前記プロジェクト序列テーブルから検索することにより、前記申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者に相当する前記組織における承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノード又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードを特定する少なくとも１つの前記第１の識別子を抽出するステップ（ｆ）と、
ステップ（ｆ）にて抽出された少なくとも１つの前記第１の識別子に基づいて前記承認者テーブルを検索することにより、前記組織を構成する複数の構成者の中の前記申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者又は前記プロジェクトにおける承認権限を有する複数の者の中の前記申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者を特定するステップ（ｇ）と、
ステップ（ｇ）にて特定された前記組織を構成する複数の構成者の中の前記申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者又は前記プロジェクトにおける承認権限を有する複数の者の中の前記申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者からの承認又は却下の指示に応じて、申請が承認されたこと又は却下されたことを表す少なくとも１つのデータを前記申請に関するデータ内の前記１群のフィールドに書き込むステップ（ｈ）と、
を具備する業務管理方法。
【請求項４】
ステップ（ａ）が、組織に拘らない複数のプロジェクトに関する情報をそれぞれ格納する複数のプロジェクト序列テーブルを記録するステップである、請求項３記載の業務管理方法。
【請求項５】
申請及び承認に関する業務の管理を行うためのプログラムであって、
組織を構成する複数の構成者及び組織における承認権限を有する複数の者に相当する１群のノードに関する情報をそれぞれ格納する複数のレコードを含む組織序列テーブルであって、各レコードが、前記組織を構成する複数の構成者又は前記組織における承認権限を有する複数の者に相当する１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、前記組織を構成する複数の構成者又は前記組織における承認権限を有する複数の者に相当する１群のノードの組織における序列を表す第２の識別子であって、前記組織を構成する複数の構成者の中の任意の者の前記第２の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより、前記組織を構成する複数の構成者の中の任意の者の組織上において上位であり且つ組織における申請に対する承認権限を有する少なくとも１人の者に相当する前記組織における承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードの前記第２の識別子を得ることが可能な前記第２の識別子を格納する第２のフィールドとを有する前記組織序列テーブルと、前記組織を構成する複数の構成者の内の組織に拘らないプロジェクトを構成する複数の構成者及びプロジェクトにおける承認権限を有する複数の者に相当する１群のノードに関する情報をそれぞれ格納する複数のレコードを含むプロジェクト序列テーブルであって、各レコードが、前記プロジェクトを構成する複数の構成者又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードを一意に特定する前記第１の識別子を格納する第１のフィールドと、前記プロジェクトを構成する複数の構成者又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードのプロジェクトにおける序列を表す第３の識別子であって、前記プロジェクトを構成する複数の構成者の中の任意の者の前記第３の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより、前記プロジェクトを構成する複数の構成者の中の任意の者のプロジェクトにおいて上位であり且つプロジェクトにおける申請に対する承認権限を有する少なくとも１人の者に相当する前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードの前記第３の識別子を得ることが可能な前記第３の識別子を格納する第２のフィールドとを有する前記プロジェクト序列テーブルと、を記録する手順（ａ）と、
前記組織における承認権限を有する複数の者に相当する１群のノード又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードを一意に特定する前記第１の識別子を格納する第１のフィールドと、前記組織における承認権限を有する複数の者に相当する１群のノードに係る者としての前記組織を構成する複数の構成者又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードに係る者としての前記プロジェクトを構成する複数の構成者を一意に特定する前記第１の識別子を格納する第２のフィールドとを有する承認者テーブルを記録する手順（ｂ）と、
申請に関するデータであって、前記組織を構成する複数の構成者の中の申請を行った者又は前記プロジェクトを構成する複数の構成者の中の申請を行った者を一意に特定する前記第１の識別子を格納する第１のフィールドと、当該申請が組織における申請であるか又はプロジェクトにおける申請であるかを識別するための第４の識別子を格納する第２のフィールドと、当該申請に対する承認が得られたか否かを表す複数のデータをそれぞれ格納する１群のフィールドとを有する前記申請に関するデータを記録する手順（ｃ）と、
前記申請に関するデータ内の前記第４の識別子に基づいて、前記組織序列テーブル又は前記プロジェクト序列テーブルを読み出す手順（ｄ）と、
前記申請に関するデータ内の前記第１の識別子に基づいて、手順（ｄ）にて読み出した前記組織序列テーブル又は前記プロジェクト序列テーブルを検索することにより、前記組織を構成する複数の構成者の中の前記申請に関するデータに係る申請を行った者又は前記プロジェクトを構成する複数の構成者の中の前記申請に関するデータに係る申請を行った者の前記第２の識別子を抽出する手順（ｅ）と、
手順（ｅ）にて抽出された前記第２の識別子の末尾から前記所定の長さの値を少なくとも１回削除する演算を行うことにより得られた少なくとも１つの値を前記第２の識別子として格納している少なくとも１つのレコードを手順（ｄ）にて読み出した前記組織序列テーブル又は前記プロジェクト序列テーブルから検索することにより、前記申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者に相当する前記組織における承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノード又は前記プロジェクトにおける承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードを特定する少なくとも１つの前記第１の識別子を抽出する手順（ｆ）と、
手順（ｆ）にて抽出された少なくとも１つの前記第１の識別子に基づいて前記承認者テーブルを検索することにより、前記組織を構成する複数の構成者の中の前記申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者又は前記プロジェクトにおける承認権限を有する複数の者の中の前記申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者を特定する手順（ｇ）と、
手順（ｇ）にて特定された前記組織を構成する複数の構成者の中の前記申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者又は前記プロジェクトにおける承認権限を有する複数の者の中の前記申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者からの承認又は却下の指示に応じて、申請が承認されたこと又は却下されたことを表す少なくとも１つのデータを前記申請に関するデータ内の前記１群のフィールドに書き込む手順（ｈ）と、
をＣＰＵに実行させるための業務管理プログラム。
【請求項６】
手順（ａ）が、組織に拘らない複数のプロジェクトに関する情報をそれぞれ格納する複数のプロジェクト序列テーブルを記録する手順である、請求項５記載の業務管理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、申請及び承認に関する業務の管理を行うための業務管理装置に関し、さらに、業務管理方法及び業務管理プログラムに関する。
【背景技術】
【０００２】
近年、組織における申請及び承認に関する業務の管理を行うための業務管理装置において、人事異動、組織変更等により承認権限を有する者の変更が生じた場合に、柔軟に対応することが求められている。このような状況に鑑み、本出願人は、人事異動等が生じた場合に柔軟に対応することが可能な業務管理装置を提案した（例えば、下記の特許文献１参照）。
【０００３】
ところで、企業等における承認のルートは、一般に、組織の下位から上位へ向かうというルートとなる。しかしながら、承認のルートが必ずしも組織の下位から上位へ向かうルートとなるとは限らない場合がある。例えば、組織に拘らない組織横断的なプロジェクトが設立された場合には、そのようなプロジェクトにおける承認のルートは、組織の下位から上位へ向かうルートとはならず、組織に拘らないルートになる。また、組織においては承認権限を付与されていない一般従業員等が、プロジェクトにおいては承認権限を付与される場合等があり得る。
【０００４】
しかしながら、従来の業務管理装置においては、上記のような組織横断的なプロジェクトにおける申請及び承認に関する業務の管理を行うことができなかった。
【特許文献１】特許第３８１８４４９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
そこで、上記の点に鑑み、本発明は、組織における申請及び承認に関する業務の管理を行うことができるとともに、組織に拘らないプロジェクトにおける申請及び承認に関する業務の管理をも行うことができる業務管理装置を提供することを目的とする。また、本発明は、そのような業務管理方法及び業務管理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
以上の課題を解決するため、本発明に係る業務管理装置は、申請及び承認に関する業務の管理を行うための装置であって、組織を構成する複数の構成者及び組織における承認権限を有する複数の者に相当する１群のノードに関する情報をそれぞれ格納する複数のレコードを含む組織序列テーブルであって、各レコードが、組織を構成する複数の構成者又は組織における承認権限を有する複数の者に相当する１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、組織を構成する複数の構成者又は組織における承認権限を有する複数の者に相当する１群のノードの組織における序列を表す第２の識別子であって、組織を構成する複数の構成者の中の任意の者の第２の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより、組織を構成する複数の構成者の中の任意の者の組織上において上位であり且つ組織における申請に対する承認権限を有する少なくとも１人の者に相当する組織における承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードの第２の識別子を得ることが可能な第２の識別子を格納する第２のフィールドとを有する組織序列テーブルと、組織を構成する複数の構成者の内の組織に拘らないプロジェクトを構成する複数の構成者及びプロジェクトにおける承認権限を有する複数の者に相当する１群のノードに関する情報をそれぞれ格納する複数のレコードを含むプロジェクト序列テーブルであって、各レコードが、プロジェクトを構成する複数の構成者又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、プロジェクトを構成する複数の構成者又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードのプロジェクトにおける序列を表す第３の識別子であって、プロジェクトを構成する複数の構成者の中の任意の者の第３の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより、プロジェクトを構成する複数の構成者の中の任意の者のプロジェクトにおいて上位であり且つプロジェクトにおける申請に対する承認権限を有する少なくとも１人の者に相当するプロジェクトにおける承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードの第３の識別子を得ることが可能な第３の識別子を格納する第２のフィールドとを有するプロジェクト序列テーブルと、を記録する序列テーブル記録部と、組織における承認権限を有する複数の者に相当する１群のノード又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、組織における承認権限を有する複数の者に相当する１群のノードに係る者としての組織を構成する複数の構成者又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードに係る者としてのプロジェクトを構成する複数の構成者を一意に特定する第１の識別子を格納する第２のフィールドとを有する承認者テーブルを記録する承認者テーブル記録部と、申請に関するデータであって、組織を構成する複数の構成者の中の申請を行った者又はプロジェクトを構成する複数の構成者の中の申請を行った者を一意に特定する第１の識別子を格納する第１のフィールドと、当該申請が組織における申請であるか又はプロジェクトにおける申請であるかを識別するための第４の識別子を格納する第２のフィールドと、当該申請に対する承認が得られたか否かを表す複数のデータをそれぞれ格納する１群のフィールドとを有する申請に関するデータを記録する申請データ記録部と、申請に関するデータ内の第４の識別子に基づいて組織序列テーブル又はプロジェクト序列テーブルを読み出し、申請に関するデータ内の第１の識別子に基づいて、申請に関するデータ内の第４の識別子に基づいて読み出した組織序列テーブル又はプロジェクト序列テーブルを検索することにより、組織を構成する複数の構成者の中の申請に関するデータに係る申請を行った者又はプロジェクトを構成する複数の構成者の中の申請に関するデータに係る申請を行った者の第２の識別子を抽出し、抽出された第２の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより得られた少なくとも１つの値を第２の識別子として格納している少なくとも１つのレコードを申請に関するデータ内の第４の識別子に基づいて読み出した組織序列テーブル又はプロジェクト序列テーブルから検索することにより、申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者に相当する組織における承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノード又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードを特定する少なくとも１つの第１の識別子を抽出し、抽出された少なくとも１つの第１の識別子に基づいて承認者テーブルを検索することにより、組織を構成する複数の構成者の中の申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者又はプロジェクトを構成する複数の構成者の中の申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者を特定する第１の処理手段と、第１の処理手段によって特定された組織を構成する複数の構成者の中の申請データに係る申請に対する承認権限を有する少なくとも１人の者又はプロジェクトを構成する複数の構成者の中の申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者からの承認又は却下の指示に応じて、申請が承認されたこと又は却下されたことを表す少なくとも１つのデータを申請に関するデータ内の１群のフィールドに書き込む第２の処理手段とを具備する。
【０００７】
ここで、序列テーブル記録部が、組織に拘らない複数のプロジェクトに関する情報をそれぞれ格納する複数のプロジェクト序列テーブルを記録するようにしても良い。
【０００８】
また、本発明に係る業務管理方法は、申請及び承認に関する業務の管理を行うための方法であって、組織を構成する複数の構成者及び組織における承認権限を有する複数の者に相当する１群のノードに関する情報をそれぞれ格納する複数のレコードを含む組織序列テーブルであって、各レコードが、組織を構成する複数の構成者又は組織における承認権限を有する複数の者に相当する１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、組織を構成する複数の構成者又は組織における承認権限を有する複数の者に相当する１群のノードの組織における序列を表す第２の識別子であって、組織を構成する複数の構成者の中の任意の者の第２の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより、組織を構成する複数の構成者の中の任意の者の組織上において上位であり且つ組織における申請に対する承認権限を有する少なくとも１人の者に相当する組織における承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードの第２の識別子を得ることが可能な第２の識別子を格納する第２のフィールドとを有する組織序列テーブルと、組織を構成する複数の構成者の内の組織に拘らないプロジェクトを構成する複数の構成者及びプロジェクトにおける承認権限を有する複数の者に相当する１群のノードに関する情報をそれぞれ格納する複数のレコードを含むプロジェクト序列テーブルであって、各レコードが、プロジェクトを構成する複数の構成者又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、プロジェクトを構成する複数の構成者又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードのプロジェクトにおける序列を表す第３の識別子であって、プロジェクトを構成する複数の構成者の中の任意の者の第３の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより、プロジェクトを構成する複数の構成者の中の任意の者のプロジェクトにおいて上位であり且つプロジェクトにおける申請に対する承認権限を有する少なくとも１人の者に相当するプロジェクトにおける承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードの第３の識別子を得ることが可能な第３の識別子を格納する第２のフィールドとを有するプロジェクト序列テーブルと、を記録するステップ（ａ）と、組織における承認権限を有する複数の者に相当する１群のノード又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、組織における承認権限を有する複数の者に相当する１群のノードに係る者としての組織を構成する複数の構成者又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードに係る者としてのプロジェクトを構成する複数の構成者を一意に特定する第１の識別子を格納する第２のフィールドとを有する承認者テーブルを記録するステップ（ｂ）と、申請に関するデータであって、組織を構成する複数の構成者の中の申請を行った者又はプロジェクトを構成する複数の構成者の中の申請を行った者を一意に特定する第１の識別子を格納する第１のフィールドと、当該申請が組織における申請であるか又はプロジェクトにおける申請であるかを識別するための第４の識別子を格納する第２のフィールドと、当該申請に対する承認が得られたか否かを表す複数のデータをそれぞれ格納する１群のフィールドとを有する申請に関するデータを記録するステップ（ｃ）と、申請に関するデータ内の第４の識別子に基づいて、組織序列テーブル又はプロジェクト序列テーブルを読み出すステップ（ｄ）と、申請に関するデータ内の第１の識別子に基づいて、ステップ（ｄ）にて読み出した組織序列テーブル又はプロジェクト序列テーブルを検索することにより、組織を構成する複数の構成者の中の申請に関するデータに係る申請を行った者又はプロジェクトを構成する複数の構成者の中の申請に関するデータに係る申請を行った者の第２の識別子を抽出するステップ（ｅ）と、ステップ（ｅ）にて抽出された第２の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより得られた少なくとも１つの値を第２の識別子として格納している少なくとも１つのレコードをステップ（ｄ）にて読み出した組織序列テーブル又はプロジェクト序列テーブルから検索することにより、申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者に相当する組織における承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノード又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードを特定する少なくとも１つの第１の識別子を抽出するステップ（ｆ）と、ステップ（ｆ）にて抽出された少なくとも１つの第１の識別子に基づいて承認者テーブルを検索することにより、組織を構成する複数の構成者の中の申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者又はプロジェクトにおける承認権限を有する複数の者の中の申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者を特定するステップ（ｇ）と、ステップ（ｇ）にて特定された組織を構成する複数の構成者の中の申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者又はプロジェクトにおける承認権限を有する複数の者の中の申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者からの承認又は却下の指示に応じて、申請が承認されたこと又は却下されたことを表す少なくとも１つのデータを申請に関するデータ内の前記１群のフィールドに書き込むステップ（ｈ）とを具備する。
【０００９】
ここで、ステップ（ａ）が、組織に拘らない複数のプロジェクトに関する情報をそれぞれ格納する複数のプロジェクト序列テーブルを記録するステップであることとしても良い。
【００１０】
さらに、本発明に係る業務管理プログラムは、申請及び承認に関する業務の管理を行うためのプログラムであって、組織を構成する複数の構成者及び組織における承認権限を有する複数の者に相当する１群のノードに関する情報をそれぞれ格納する複数のレコードを含む組織序列テーブルであって、各レコードが、組織を構成する複数の構成者又は組織における承認権限を有する複数の者に相当する１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、組織を構成する複数の構成者又は組織における承認権限を有する複数の者に相当する１群のノードの組織における序列を表す第２の識別子であって、組織を構成する複数の構成者の中の任意の者の第２の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより、組織を構成する複数の構成者の中の任意の者の組織上において上位であり且つ組織における申請に対する承認権限を有する少なくとも１人の者に相当する組織における承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードの第２の識別子を得ることが可能な第２の識別子を格納する第２のフィールドとを有する組織序列テーブルと、組織を構成する複数の構成者の内の組織に拘らないプロジェクトを構成する複数の構成者及びプロジェクトにおける承認権限を有する複数の者に相当する１群のノードに関する情報をそれぞれ格納する複数のレコードを含むプロジェクト序列テーブルであって、各レコードが、プロジェクトを構成する複数の構成者又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、プロジェクトを構成する複数の構成者又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードのプロジェクトにおける序列を表す第３の識別子であって、プロジェクトを構成する複数の構成者の中の任意の者の第３の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより、プロジェクトを構成する複数の構成者の中の任意の者のプロジェクトにおいて上位であり且つプロジェクトにおける申請に対する承認権限を有する少なくとも１人の者に相当するプロジェクトにおける承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードの第３の識別子を得ることが可能な第３の識別子を格納する第２のフィールドとを有するプロジェクト序列テーブルと、を記録する手順（ａ）と、組織における承認権限を有する複数の者に相当する１群のノード又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、組織における承認権限を有する複数の者に相当する１群のノードに係る者としての組織を構成する複数の構成者又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードに係る者としてのプロジェクトを構成する複数の構成者を一意に特定する第１の識別子を格納する第２のフィールドとを有する承認者テーブルを記録する手順（ｂ）と、申請に関するデータであって、組織を構成する複数の構成者の中の申請を行った者又はプロジェクトを構成する複数の構成者の中の申請を行った者を一意に特定する第１の識別子を格納する第１のフィールドと、当該申請が組織における申請であるか又はプロジェクトにおける申請であるかを識別するための第４の識別子を格納する第２のフィールドと、当該申請に対する承認が得られたか否かを表す複数のデータをそれぞれ格納する１群のフィールドとを有する申請に関するデータを記録する手順（ｃ）と、申請に関するデータ内の第４の識別子に基づいて、組織序列テーブル又はプロジェクト序列テーブルを読み出す手順（ｄ）と、申請に関するデータ内の第１の識別子に基づいて、手順（ｄ）にて読み出した組織序列テーブル又はプロジェクト序列テーブルを検索することにより、組織を構成する複数の構成者の中の申請に関するデータに係る申請を行った者又はプロジェクトを構成する複数の構成者の中の申請に関するデータに係る申請を行った者の第２の識別子を抽出する手順（ｅ）と、手順（ｅ）にて抽出された第２の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより得られた少なくとも１つの値を第２の識別子として格納している少なくとも１つのレコードを手順（ｄ）にて読み出した組織序列テーブル又はプロジェクト序列テーブルから検索することにより、申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者に相当する組織における承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノード又はプロジェクトにおける承認権限を有する複数の者に相当する１群のノードの中の少なくとも１つのノードを特定する少なくとも１つの第１の識別子を抽出する手順（ｆ）と、手順（ｆ）にて抽出された少なくとも１つの第１の識別子に基づいて承認者テーブルを検索することにより、組織を構成する複数の構成者の中の申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者又はプロジェクトにおける承認権限を有する複数の者の中の申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者を特定する手順（ｇ）と、手順（ｇ）にて特定された組織を構成する複数の構成者の中の申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者又はプロジェクトにおける承認権限を有する複数の者の中の申請に関するデータに係る申請に対する承認権限を有する少なくとも１人の者からの承認又は却下の指示に応じて、申請が承認されたこと又は却下されたことを表す少なくとも１つのデータを申請に関するデータ内の１群のフィールドに書き込む手順（ｈ）とをＣＰＵに実行させる。
【００１１】
ここで、手順（ａ）が、組織に拘らない複数のプロジェクトに関する情報をそれぞれ格納する複数のプロジェクト序列テーブルを記録する手順であることとしても良い。
【発明の効果】
【００１２】
本発明によれば、組織における申請及び承認に関する業務の管理を行うことができるとともに、組織に拘らないプロジェクトにおける申請及び承認に関する業務の管理をも行うことが可能となる。
【発明を実施するための最良の形態】
【００１３】
以下、図面に基づいて本発明の実施の形態について説明する。
図１は、本発明の一実施形態に係る業務管理装置を用いたシステムを示す図である。本実施形態は、本発明を企業における申請及び承認業務を管理するシステムに適用したものである。図１に示すように、システム１０は、本発明の一実施形態としてのサーバ１と、クライアント端末１１〜１ｎとを具備しており、これらは、ネットワークを介して相互に接続されている。
【００１４】
図２は、図１のサーバ１の構成を示す図である。図２に示すように、サーバ１は、帳票データテンプレート記録部２０と、帳票データ記録部２１と、従業員テーブル記録部２２と、承認者テーブル記録部２３と、序列テーブル記録部２４と、役職テーブル記録部２５と、帳票データ作成処理部２６と、承認ルート決定処理部２７と、承認・却下処理部２８と、承認ルート作成・更新処理部２９とを具備する。
【００１５】
序列テーブル記録部２４は、組織における承認ルートに関する情報を格納した組織序列テーブルと、組織に拘らないプロジェクトにおける承認ルートに関する情報を格納したプロジェクト序列テーブルとを記録している。ここでは、序列テーブル記録部２４は、プロジェクトにおける承認ルートに関する情報を格納したプロジェクト序列テーブルとして、組織に拘らないＡプロジェクトというプロジェクトにおける承認ルートに関する情報を格納したＡプロジェクト序列テーブル、及び組織に拘らないＢプロジェクトというプロジェクトにおける承認ルートに関する情報を格納したＢプロジェクト序列テーブルという２つのプロジェクト序列テーブルを記録しているものとする。また、組織序列テーブル、Ａプロジェクト序列テーブル、及び、Ｂプロジェクト序列テーブルには、一意に特定するための識別子として序列テーブルＩＤ「１」、「２」、及び、「３」が、それぞれ割り当てられているものとする。なお、これらの序列テーブルの詳細な内容については、後述する。
【００１６】
図３は、帳票データテンプレート記録部２０に記録される帳票データテンプレートの一例を示す図である。図３に示すように、帳票データテンプレートは、申請の内容に関する情報及び承認状況に関する情報を格納するフィールドを有する。申請の内容に関する情報は、帳票名（例えば、休暇届、組織における物品購入届（以下、単に「物品購入届」という）、Ａプロジェクトにおける物品購入届（以下、単に「Ａプロジェクト物品購入届」という）、Ｂプロジェクトにおける物品購入届（以下、単に「Ｂプロジェクト物品購入届」という）等）、序列テーブル記録部２４に記録されている複数の序列テーブルの内の当該帳票の承認に使用される序列テーブルを一意に特定する使用序列テーブルＩＤ、申請者を一意に特定するユーザＩＤ、実施日（例えば、休暇申請日、休暇取得日、物品購入申請日、物品購入発注日等）等を含む。また、承認状況に関する情報は、第１承認（例えば、課長承認等）、第２承認（例えば、部長承認等）、…と、全ての承認が完了したか否かを示す完了フラグとを含む。
【００１７】
例えば、「休暇届」、及び「物品購入届」は、組織における承認が行われるべき帳票である。そのため、「休暇届」、及び「物品購入届」の帳票データテンプレートには、使用序列テーブルＩＤとして「１」（先に触れた組織序列テーブルに対応）が格納されている。また、「Ａプロジェクト物品購入届」は、Ａプロジェクトにおける承認が行われるべき帳票である。そのため、「Ａプロジェクト物品購入届」の帳票データテンプレートには、使用序列テーブルＩＤとして「２」（先に触れたＡプロジェクト序列テーブルに対応）が格納されている。さらに、「Ｂプロジェクト物品購入届」は、Ｂプロジェクトにおける承認が行われるべき帳票である。そのため、「Ｂプロジェクト物品購入届」の帳票データテンプレートには、使用序列テーブルＩＤとして「３」（先に触れたＢプロジェクト序列テーブルに対応）が格納されている。
【００１８】
再び図２を参照すると、従業員テーブル記録部２２は、従業員に関するデータを格納する従業員テーブルを記録する。
図４は、従業員テーブルの一例を示す図である。図４に示すように、従業員テーブルは、従業員を一意に特定するユーザＩＤ、パスワード、従業員を一意に特定する従業員番号、及び、従業員の氏名を格納するフィールドを有している。
【００１９】
再び図２を参照すると、承認者テーブル記録部２３は、組織及びプロジェクトにおける承認権限を有する者に関するデータを格納する承認者テーブルを記録する。
図５は、承認者テーブルの一例を示す図である。図５に示すように、承認者テーブルは、組織及びプロジェクトにおける承認権限を有する者に相当するノードの名称、組織及びプロジェクトにおける承認権限を有する者に相当するノードを一意に特定するユーザＩＤ、及び、組織及びプロジェクトにおける承認権限を有する者としての従業員のユーザＩＤを格納するフィールドを有している。なお、図５に示す承認者テーブルにおいて、「完了箱」という名称を有するノードは、組織における承認が完了した帳票データを管理又は処理する権限を有する者（例えば、総務課長、人事課長等）に相当する。また、「Ａプロジェクト完了箱」は、Ａプロジェクトにおける承認が完了した帳票データを管理又は処理する権限を有する者に相当する。さらに、「Ｂプロジェクト完了箱」は、Ｂプロジェクトにおける承認が完了した帳票データを管理又は処理する権限を有する者に相当する。
【００２０】
本実施形態においては、組織における承認が完了した帳票データを管理又は処理する権限を有する者は、ユーザＩＤが「Ｔａｒｏ」である従業員（ここでは、氏名「総務  太郎」（図４参照））と、ユーザＩＤが「Ｊｉｒｏ」である従業員（ここでは、氏名「総務  次郎」（図４参照））である。また、Ａプロジェクトにおける承認が完了した帳票データを管理又は処理する権限を有する者は、ユーザＩＤが「Ｓａｋｕｍａ」である従業員（ここでは、氏名「佐久間  幸二」（図４参照））である。さらに、Ｂプロジェクトにおける承認が完了した帳票データを管理又は処理する権限を有する者は、ユーザＩＤが「Ｎａｇａｔａ」である従業員（ここでは、氏名「永田  亮」（図４参照））である。
【００２１】
再び図２を参照すると、序列テーブル記録部２４は、組織序列テーブル、及びプロジェクト序列テーブルを記録する。
図６は、組織序列テーブルの一例を示す図である。図６に示すように、組織序列テーブルは、レコード番号（Ｎｏ．）、改定日、ユーザＩＤ、当該レコードの組織上における区分である組織区分、組織所属名、氏名、及び、組織序列番号を格納するフィールドを有している。
【００２２】
図６に示す組織序列テーブルにおいて、改定日とは、当該レコードに格納されているデータが有効となった日又は有効となる日を表す。
組織区分は、１〜３までの値を取り得る。ここで、組織区分「１」は、当該レコードが部署に相当するノードに関するレコードであることを表す。また、組織区分「２」は、当該レコードが承認権限を有する者に相当するノードに関するレコードであることを表し、組織区分「３」は、当該レコードが従業員に関するレコードであることを表す。
【００２３】
組織序列番号は、部署に相当するノード、組織における承認権限を有する者に相当するノード、又は、従業員（以下、「従業員等」という）の組織上における序列（位置付け）を表す番号である。本実施形態においては、組織序列番号は、４ｎ（ｎは、自然数）桁の数であり、或る従業員等の組織序列番号は、当該従業員等の直近上位の従業員等の組織序列番号の末尾に４桁の数を付加した番号となっている。例えば、図６に示す組織序列テーブルにおいて、第１レコード（組織所属名「東京本社」）には、組織序列番号「０００１」が格納されており、第１レコードによって表されるノードの下位に位置するノードとしての第２レコード（組織所属名「東京本社」、氏名「完了箱」）には、第１レコード内の組織序列番号「０００１」の末尾に「０００１」を付加した組織序列番号「０００１０００１」が格納されている。また、例えば、従業員「高田  由美子」（第１４レコードに相当）の直近上位の従業員等は、第１４レコード内の組織序列番号「０００１０００１０００１０００２０００２０００２０００１０００２０００２」の末尾４桁を削除した値「０００１０００１０００１０００２０００２０００２０００１０００２」を組織序列番号として格納しているレコード（ここでは、第１２レコード）によって表される従業員等（ここでは、組織における承認権限を有する者に相当するノード「営業部１課１Ｇ承認者」）となる。
【００２４】
図７は、Ａプロジェクト序列テーブルの一例を示す図である。図７に示すように、Ａプロジェクト序列テーブルは、レコード番号（Ｎｏ．）、改定日、ユーザＩＤ、当該レコードのＡプロジェクト上における区分、所属名、氏名、及び、Ａプロジェクト序列番号を格納するフィールドを有している。
図７に示すＡプロジェクト序列テーブルにおいて、改定日等は、組織序列テーブルと同様である。
【００２５】
Ａプロジェクト序列番号は、Ａプロジェクトに相当するノード、Ａプロジェクトにおける承認権限を有する者に相当するノード、又は、Ａプロジェクトを構成する従業員（以下、「Ａプロジェクト構成員等」という）のＡプロジェクト上における序列（位置付け）を表す番号である。本実施形態においては、Ａプロジェクト序列番号は、４ｎ（ｎは、自然数）桁の数であり、或るＡプロジェクト構成員等のＡプロジェクト序列番号は、当該Ａプロジェクト構成員等の直近上位のＡプロジェクト構成員等のＡプロジェクト序列番号の末尾に４桁の数を付加した番号となっている。例えば、図７に示すＡプロジェクト序列テーブルにおいて、第１レコード（組織所属名「東京本社」）には、Ａプロジェクト序列番号「０００１」が格納されており、第１レコードによって表されるノードの下位に位置するノードとしての第２レコード（組織所属名「東京本社」、氏名「Ａプロジェクト完了箱」）には、第１レコード内のＡプロジェクト序列番号「０００１」の末尾に「０００２」を付加したＡプロジェクト序列番号「０００１０００２」が格納されている。また、例えば、従業員「高田  由美子」（第６レコードに相当）の直近上位のＡプロジェクト構成員等は、第６レコード内のＡプロジェクト序列番号「０００１０００２０００１０００２０００１」の末尾４桁を削除した値「０００１０００２０００１０００２」をＡプロジェクト序列番号として格納しているレコード（ここでは、第５レコード）によって表されるＡプロジェクト構成員等（ここでは、Ａプロジェクトにおける承認権限を有する者に相当するノード「Ａプロジェクト承認者」）となる。
【００２６】
図８は、Ｂプロジェクト序列テーブルの一例を示す図である。図８に示すように、Ｂプロジェクト序列テーブルは、レコード番号（Ｎｏ．）、改定日、ユーザＩＤ、当該レコードのＢプロジェクト上における区分、所属名、氏名、及び、Ｂプロジェクト序列番号を格納するフィールドを有している。
図８に示すＢプロジェクト序列テーブルにおいて、改定日等は、組織序列テーブルと同様である。
【００２７】
Ｂプロジェクト序列番号は、Ｂプロジェクトに相当するノード、Ｂプロジェクトにおける承認権限を有する者に相当するノード、又は、Ｂプロジェクトを構成する従業員（以下、「Ｂプロジェクト構成員等」という）のＢプロジェクト上における序列（位置付け）を表す番号である。本実施形態においては、Ｂプロジェクト序列番号は、４ｎ（ｎは、自然数）桁の数であり、或るＢプロジェクト構成員等のＢプロジェクト序列番号は、当該Ｂプロジェクト構成員等の直近上位のＢプロジェクト構成員等のＢプロジェクト序列番号の末尾に４桁の数を付加した番号となっている。例えば、図８に示すＢプロジェクト序列テーブルにおいて、第１レコード（組織所属名「東京本社」）には、Ｂプロジェクト序列番号「０００１」が格納されており、第１レコードによって表されるノードの下位に位置するノードとしての第２レコード（組織所属名「東京本社」、氏名「Ｂプロジェクト完了箱」）には、第１レコード内のＢプロジェクト序列番号「０００１」の末尾に「０００３」を付加したＢプロジェクト序列番号「０００１０００３」が格納されている。また、例えば、従業員「佐久間  幸二」（第６レコードに相当）の直近上位のＢプロジェクト構成員等は、第６レコード内のＢプロジェクト序列番号「０００１０００３０００１０００２０００１」の末尾４桁を削除した値「０００１０００３０００１０００２」をＢプロジェクト序列番号として格納しているレコード（ここでは、第５レコード）によって表されるＢプロジェクト構成員等（ここでは、Ｂプロジェクトにおける承認権限を有する者に相当するノード「Ｂプロジェクト承認者」）となる。
【００２８】
再び図２を参照すると、役職テーブル記録部２５は、従業員の役職に関するデータを格納する役職テーブルを記録する。
図９は、役職テーブルの一例を示す図である。図９に示すように、役職テーブルは、ユーザＩＤ、当該レコードが有効となった日又は有効となる日を表す改定日、及び、役職を格納するフィールドを有している。図９においては、例えば、ユーザＩＤが「Ｔａｒｏ」である従業員（本実施形態においては、氏名「総務  太郎」（図４参照））は、１９８３年４月１日に一般従業員となり、１９９３年４月１日に総務課長となり、１９９８年４月１日に総務部長となったことを表している。
【００２９】
再び図２を参照すると、帳票データ作成処理部２６は、クライアント端末１１〜１ｎを使用する従業員からの要求に応じて、帳票データを作成し、帳票データ記録部２１に記録させる。
承認ルート決定処理部２７は、帳票データ記録部２１に記録されている帳票データに係る申請を承認すべき従業員を決定する処理を行う。
【００３０】
承認・却下処理部２８は、承認ルート決定処理部２７によって決定された従業員からの指示に応じて承認又は却下処理を行う。
承認ルート作成・更新処理部２９は、帳票データテンプレート、従業員テーブル、承認者テーブル、序列テーブル、又は、役職テーブルの作成又は更新処理を行う。
【００３１】
図２に示す帳票データ作成処理部２６、承認ルート決定処理部２７、承認・却下処理部２８、及び、承認ルート作成・更新処理部２９は、ＣＰＵとソフトウェア（プログラム）で構成することができる。このプログラムと、帳票データテンプレート、帳票データ、従業員テーブル、承認者テーブル、序列テーブル、及び、役職テーブルは、ハードディスク、フレキシブルディスク、ＭＯ、ＭＴ、ＲＡＭ、ＣＤ−ＲＯＭ、又は、ＤＶＤ−ＲＯＭ等の記録媒体に記録することができる。
【００３２】
図１０は、サーバ１の帳票データ作成処理の概要を示すフローチャートである。以下、サーバ１の帳票データ作成処理について、図１０を参照しながら説明する。
まず、サーバ１の帳票データ作成処理部２６は、ユーザが使用しているクライアント端末からユーザＩＤ、及びパスワードを受け付けるログイン処理を行う（ステップＳ１０１）。なお、ユーザＩＤ、及び／又はパスワードに代えて、指紋画像等を用いるようにしても良い。
【００３３】
次に、帳票データ作成処理部２６は、ログインしたユーザが起票可能な帳票をクライアント端末に一覧表示させる（ステップＳ１０２）。
【００３４】
具体的には、例えば、従業員「高田  由美子」（ユーザＩＤ「Ｔａｋａｄａ」）がログインした場合には、帳票データ作成処理部２６は、従業員「高田  由美子」のユーザＩＤ「Ｔａｋａｄａ」をキーとして組織序列テーブル、Ａプロジェクト序列テーブル、及び、Ｂプロジェクト序列テーブルを検索する。本実施形態においては、ユーザＩＤ「Ｔａｋａｄａ」が、序列テーブルＩＤが「１」である組織序列テーブル、及び序列テーブルＩＤが「２」であるＡプロジェクト序列テーブルに含まれている。そこで、帳票データ作成処理部２６は、帳票データテンプレートの中の使用序列テーブルＩＤとして「１」、又は「２」を含む帳票（本実施形態においては、「休暇届」（使用序列テーブルＩＤ「１」）、「物品購入届」（使用序列テーブルＩＤ「１」）、及び、「Ａプロジェクト物品購入届」（使用序列テーブルＩＤ「２」）を、クライアント端末に一覧表示させる。
【００３５】
また、例えば、従業員「佐久間  幸二」（ユーザＩＤ「Ｓａｋｕｍａ」）がログインした場合には、帳票データ作成処理部２６は、従業員「佐久間  幸二」のユーザＩＤ「Ｓａｋｕｍａ」をキーとして組織序列テーブル、Ａプロジェクト序列テーブル、及び、Ｂプロジェクト序列テーブルを検索する。本実施形態においては、ユーザＩＤ「Ｓａｋｕｍａ」が、序列テーブルＩＤが「１」である組織序列テーブル、序列テーブルＩＤが「２」であるＡプロジェクト序列テーブル、及び、序列テーブルＩＤが「３」であるＢプロジェクト序列テーブルに含まれている。そこで、帳票データ作成処理部２６は、帳票データテンプレートの中の使用序列テーブルＩＤとして「１」、「２」、又は、「３」を含む帳票（本実施形態においては、「休暇届」（使用序列テーブルＩＤ「１」）、「物品購入届」（使用序列テーブルＩＤ「１」）、「Ａプロジェクト物品購入届」（使用序列テーブルＩＤ「２」）、及び、「Ｂプロジェクト物品購入届」（使用序列テーブルＩＤ「３」）を、クライアント端末に一覧表示させる。
【００３６】
ログインしたユーザは、このようにして一覧表示された帳票の中から、所望の帳票を選択することが出来る。また、ログインしたユーザは、自らが起票出来ない帳票が表示されないので、そのような自らが起票出来ない帳票を選択することは出来ない。例えば、従業員「高田  由美子」（ユーザＩＤ「Ｔａｋａｄａ」）がログインした場合には、ユーザＩＤ「Ｔａｋａｄａ」がＢプロジェクト序列テーブル（図８参照）に含まれていないので、「Ｂプロジェクト物品購入届」を選択することは出来ない。
【００３７】
次に、帳票データ作成処理部２６は、ログインしたユーザが選択した帳票の起票画面を、クライアント端末に表示させる（ステップＳ１０３）。ログインしたユーザは、この起票画面において、起票に必要な情報（例えば、「休暇届」の起票の場合には、休暇申請日、休暇取得日等、「物品購入届」の起票の場合には、物品購入申請日、物品購入発注日、物品名、数量、価格、購入先等）を入力する。
【００３８】
そして、帳票データ作成処理部２６は、ログインしたユーザが入力した情報を含む帳票データを作成し、帳票データ記録部２１に記録させる（ステップＳ１０４）。
【００３９】
図１１は、帳票データ記録部２１に記録された帳票データの一例を示す図である。図１１は、従業員「高田  由美子」（ユーザＩＤ「Ｔａｋａｄａ」）が「休暇届」、「物品購入届」、及び、「Ａプロジェクト物品購入届」を申請したこと、及び従業員「佐久間  幸二」（ユーザＩＤ「Ｓａｋｕｍａ」）が「Ｂプロジェクト物品購入届」を申請したことを示している。
【００４０】
図１２は、サーバ１の承認・却下処理の概要を示すフローチャートである。以下、サーバ１の承認・却下処理について、図１２を参照しながら説明する。
まず、承認ルート決定処理部２７が、帳票データ記録部２１に記録されている帳票データの内の承認未完了の帳票データのいずれかを処理対象とし、その処理対象の帳票データ内の使用序列テーブルＩＤ及び申請者のユーザＩＤを抽出する（ステップＳ２０１）。ここでは、図１１に示されている従業員「高田  由美子」（ユーザＩＤ「Ｔａｋａｄａ」）が申請した「休暇届」を処理対象とした場合を例として説明する。
【００４１】
次に、承認ルート決定処理部２７は、ステップＳ２０１にて抽出した使用序列テーブルＩＤ（ここでは、「１」）に対応する序列テーブル（ここでは、組織序列テーブル（図６））を序列テーブル記録部２４から読み出す（ステップＳ２０２）。
【００４２】
次に、承認ルート決定処理部２７は、ステップＳ２０２にて読み出した序列テーブル（ここでは、組織序列テーブル（図６））の中から、ステップＳ２０１にて抽出したユーザＩＤ（ここでは、「Ｔａｋａｄａ」）を格納しているレコード（ここでは、第１４レコード）を検索し、当該レコード内の序列番号（ここでは、「０００１０００１０００１０００２０００２０００２０００１０００２０００２」）を抽出する（ステップＳ２０３）。なお、このとき、ステップＳ２０１にて抽出されたユーザＩＤを格納しているレコードが複数存在している場合には、システム日付において有効なレコードを選択する。
【００４３】
そして、承認ルート決定処理部２７は、序列番号（ここでは、「０００１０００１０００１０００２０００２０００２０００１０００２０００２」）の下位４桁を削除した値（ここでは、「０００１０００１０００１０００２０００２０００２０００１０００２」）を算出する（ステップＳ２０４）。
【００４４】
次に、承認ルート決定処理部２７は、ステップＳ２０２にて読み出した序列テーブル（ここでは、組織序列テーブル（図６））の中から、ステップＳ２０４にて算出された値（ここでは、「０００１０００１０００１０００２０００２０００２０００１０００２」）を序列番号として格納しているレコード（ここでは、第１２レコード）を検索し、当該レコード内のユーザＩＤ（ここでは、「Ｅｉｇｙｏ＿Ｂ＿１Ｋ＿１Ｇ」）を抽出する（ステップＳ２０５）。なお、このとき、ステップＳ２０４にて算出された値を序列番号として格納しているレコードが複数存在している場合には、システム日付において有効なレコードを選択する。
【００４５】
そして、承認ルート決定処理部２７は、承認者テーブル記録部２３に記録されている承認者テーブル（図５参照）の中から、ステップＳ２０５にて抽出されたユーザＩＤ（ここでは、「Ｅｉｇｙｏ＿Ｂ＿１Ｋ＿１Ｇ」）を承認権限を有する者に相当するノードのユーザＩＤとして格納しているレコード（ここでは、第５レコード）を検索し、当該レコードに格納されている承認権限を有する者としての従業員のユーザＩＤ（ここでは、「Ｍｏｒｉ」）を抽出する（ステップＳ２０６）。なお、このとき、ステップＳ２０５にて抽出されたユーザＩＤを格納しているレコードが複数存在している場合には、システム日付において有効なレコードを選択する。これにより、処理対象である帳票データ（図１１の「休暇届」参照）に対する承認又は却下処理を最初に行うべき従業員（ここでは、ユーザＩＤ「Ｍｏｒｉ」、氏名「森  祐司」である従業員）を決定することができる。承認ルート決定処理部２７は、このユーザＩＤを承認・却下処理部２８に出力する。
【００４６】
次に、承認・却下処理部２８は、ステップＳ２０６にて抽出されたユーザＩＤ（ここでは、「Ｍｏｒｉ」）を有する従業員（ここでは、「森  祐司」）が使用するクライアント端末に、帳票データ（ここでは、「休暇届」）の内容を表示させる（ステップＳ２０７）。
そして、承認・却下処理部２８は、ステップＳ２０６にて抽出されたユーザＩＤを有する従業員（ここでは、「森  祐司」）からの指示に応じて（ここでは、従業員「森  祐司」は、承認する旨の指示を入力するものとする）、帳票データ内の複数の承認欄の中の１つの承認欄（ここでは、第１承認欄）の値を書き換える（ステップＳ２０８）。
【００４７】
次に、承認ルート決定処理部２７は、処理対象の帳票データに対する全ての承認が完了しているか否かをチェックし、処理対象の帳票データに対する全ての承認が完了していると判断した場合には処理をステップＳ２１０に移し、そうでない場合には、処理をステップＳ２０４に戻す（ステップＳ２０９）。
【００４８】
承認ルート決定処理部２７は、処理対象の帳票データに対する全ての承認が完了していると判断した場合には、処理対象の帳票データの承認完了フラグを「未完了」から「完了」に書き換える（ステップＳ２１０）。
サーバ１は、このようにして、処理対象の帳票データに関する承認処理を行うことができる。
【００４９】
なお、上記においては、図１１の「休暇届」（使用序列テーブルＩＤ「１」）を処理対象の帳票データとした場合について説明したが、図１１の「Ａプロジェクト物品購入届」（使用序列テーブルＩＤ「２」）を処理対象の帳票データとした場合も、上記と同様に承認処理を行うことができる。その場合には、組織序列テーブル（序列テーブルＩＤ「１」、図６参照）に代えて、Ａプロジェクト序列テーブル（序列テーブルＩＤ「２」、図７参照）を使用することになる。以下、図１１の「Ａプロジェクト物品購入届」（使用序列テーブルＩＤ「２」）を処理対象の帳票データとした場合におけるサーバ１の動作について、説明する。
【００５０】
まず、承認ルート決定処理部２７が、図１１の「Ａプロジェクト物品購入届」内の使用序列テーブルＩＤ「２」及び申請者のユーザＩＤ「Ｔａｋａｄａ」を抽出する（ステップＳ２０１参照）。
【００５１】
次に、承認ルート決定処理部２７は、抽出した使用序列テーブルＩＤ「２」に対応するＡプロジェクト序列テーブル（図７）を序列テーブル記録部２４から読み出す（ステップＳ２０２参照）。
【００５２】
次に、承認ルート決定処理部２７は、Ａプロジェクト序列テーブル（図７）の中から、ユーザＩＤ「Ｔａｋａｄａ」を格納しているレコード（ここでは、第６レコード）を検索し、当該レコード内の序列番号「０００１０００２０００１０００２０００１」を抽出する（ステップＳ２０３参照）。
【００５３】
そして、承認ルート決定処理部２７は、序列番号「０００１０００２０００１０００２０００１」の下位４桁を削除した値「０００１０００２０００１０００２」を算出する（ステップＳ２０４参照）。
【００５４】
次に、承認ルート決定処理部２７は、Ａプロジェクト序列テーブル（図７）の中から、算出された値「０００１０００２０００１０００２」を序列番号として格納しているレコード（ここでは、第５レコード）を検索し、当該レコード内のユーザＩＤ「Ａ＿Ｐｒｏｊ」を抽出する（ステップＳ２０５参照）。
【００５５】
そして、承認ルート決定処理部２７は、承認者テーブル記録部２３に記録されている承認者テーブル（図５参照）の中から、ユーザＩＤ「Ａ＿Ｐｒｏｊ」を承認権限を有する者に相当するノードのユーザＩＤとして格納しているレコード（ここでは、第７レコード）を検索し、当該レコードに格納されている承認権限を有する者としての従業員のユーザＩＤ「Ｓａｋｕｍａ」を抽出する（ステップＳ２０６参照）。
【００５６】
次に、承認・却下処理部２８は、ユーザＩＤ「Ｓａｋｕｍａ」を有する従業員「佐久間  幸二」が使用するクライアント端末に、「Ａプロジェクト物品購入届」の帳票データの内容を表示させる（ステップＳ２０７参照）。
そして、承認・却下処理部２８は、ユーザＩＤ「Ｓａｋｕｍａ」を有する従業員「佐久間  幸二」からの指示に応じて（ここでは、従業員「佐久間  幸二」は、承認する旨の指示を入力するものとする）、帳票データ内の複数の承認欄の中の１つの承認欄（ここでは、第１承認欄）の値を書き換える（ステップＳ２０８参照）。
サーバ１は、このような処理を繰り返すことで、図１１の「Ａプロジェクト物品購入届」の帳票データに関する承認処理を行うことができる。
【００５７】
また、図１１の「Ｂプロジェクト物品購入届」（使用序列テーブルＩＤ「３」）を処理対象の帳票データとした場合も、上記と同様に承認処理を行うことができる。その場合には、Ｂプロジェクト序列テーブル（序列テーブルＩＤ「３」、図８参照）を使用することになる。以下、図１１の「Ｂプロジェクト物品購入届」（使用序列テーブルＩＤ「３」）を処理対象の帳票データとした場合におけるサーバ１の動作について、説明する。
【００５８】
まず、承認ルート決定処理部２７が、図１１の「Ｂプロジェクト物品購入届」内の使用序列テーブルＩＤ「３」及び申請者のユーザＩＤ「Ｓａｋｕｍａ」を抽出する（ステップＳ２０１参照）。
【００５９】
次に、承認ルート決定処理部２７は、抽出した使用序列テーブルＩＤ「３」に対応するＢプロジェクト序列テーブル（図８）を序列テーブル記録部２４から読み出す（ステップＳ２０２参照）。
【００６０】
次に、承認ルート決定処理部２７は、Ｂプロジェクト序列テーブル（図８）の中から、ユーザＩＤ「Ｓａｋｕｍａ」を格納しているレコード（ここでは、第６レコード）を検索し、当該レコード内の序列番号「０００１０００３０００１０００２０００１」を抽出する（ステップＳ２０３参照）。
【００６１】
そして、承認ルート決定処理部２７は、序列番号「０００１０００３０００１０００２０００１」の下位４桁を削除した値「０００１０００３０００１０００２」を算出する（ステップＳ２０４参照）。
【００６２】
次に、承認ルート決定処理部２７は、Ｂプロジェクト序列テーブル（図８）の中から、算出された値「０００１０００３０００１０００２」を序列番号として格納しているレコード（ここでは、第５レコード）を検索し、当該レコード内のユーザＩＤ「Ｂ＿Ｐｒｏｊ」を抽出する（ステップＳ２０５参照）。
【００６３】
そして、承認ルート決定処理部２７は、承認者テーブル記録部２３に記録されている承認者テーブル（図５参照）の中から、ユーザＩＤ「Ｂ＿Ｐｒｏｊ」を承認権限を有する者に相当するノードのユーザＩＤとして格納しているレコード（ここでは、第９レコード）を検索し、当該レコードに格納されている承認権限を有する者としての従業員のユーザＩＤ「Ｎａｇａｔａ」を抽出する（ステップＳ２０６参照）。
【００６４】
次に、承認・却下処理部２８は、ユーザＩＤ「Ｎａｇａｔａ」を有する従業員「永田  亮」が使用するクライアント端末に、「Ｂプロジェクト物品購入届」の帳票データの内容を表示させる（ステップＳ２０７参照）。
そして、承認・却下処理部２８は、ユーザＩＤ「Ｎａｇａｔａ」を有する従業員「永田  亮」からの指示に応じて（ここでは、従業員「永田  亮」は、承認する旨の指示を入力するものとする）、帳票データ内の複数の承認欄の中の１つの承認欄（ここでは、第１承認欄）の値を書き換える（ステップＳ２０８参照）。
サーバ１は、このような処理を繰り返すことで、図１１の「Ｂプロジェクト物品購入届」の帳票データに関する承認処理を行うことができる。
【００６５】
図１３は、サーバ１の承認ルート作成・更新処理の概要を示すフローチャートである。以下、サーバ１の承認ルート作成・更新処理について、図１３を参照しながら説明する。
承認ルート作成・更新処理部２９は、クライアント端末を使用している従業員から、組織、Ａプロジェクト、又は、Ｂプロジェクトにおける承認権限を有する者としての従業員の追加、削除、又は、変更を行うためのデータを受け取り、承認者テーブル記録部２３に記録されている承認者テーブル、序列テーブル記録部２４に記録されている組織序列テーブル、Ａプロジェクト序列テーブル、又は、Ｂプロジェクト序列テーブルの作成又は更新を行う（ステップＳ３０１）。
【００６６】
このように、本実施形態によれば、組織に関する情報、組織、Ａプロジェクト、及び、Ｂプロジェクトにおける承認権限を有する者に関する情報、並びに、申請に関する情報を分離して、序列テーブル、承認者テーブル、及び、帳票データ内にそれぞれ格納することにより、各テーブル内の情報の更新を容易にすることができ、人事異動等が生じた場合であっても柔軟に対応することができる。
【００６７】
また、本実施形態によれば、組織における承認ルートと、組織に拘らないプロジェクトにおける承認ルートとを別個に実現することができる。
【００６８】
さらに、本実施形態によれば、組織においては承認権限を有していない一般従業員等が、プロジェクトにおいては承認権限を有する場合にも対処することができる。例えば、承認者テーブル（図５）及び組織序列テーブル（図６）を参照すると、一般従業員「佐久間  幸二」（ユーザＩＤ「Ｓａｋｕｍａ」）は、組織（営業部１課１Ｇ）においては承認権限を有していない。しかし、先に説明したように、従業員「佐久間  幸二」（ユーザＩＤ「Ｓａｋｕｍａ」）は、Ａプロジェクトにおいては承認権限を有する。このように、本実施形態によれば、組織においては承認権限を有していない一般従業員等が、プロジェクトにおいては承認権限を有する場合にも対処可能である。
【産業上の利用可能性】
【００６９】
本発明は、申請及び承認に関する業務の管理を行うための業務管理装置、業務管理方法、及び、業務管理プログラムにおいて利用可能である。
【図面の簡単な説明】
【００７０】
【図１】本発明の一実施形態に係る業務管理装置を用いたシステムの構成を示す図である。
【図２】図１のサーバ１の構成を示す図である。
【図３】図２の帳票データテンプレート記録部２０に記録される帳票データテンプレートの一例を示す図である。
【図４】図２の従業員テーブル記録部２２に記録される従業員テーブルの一例を示す図である。
【図５】図２の承認者テーブル記録部２３に記録される承認者テーブルの一例を示す図である。
【図６】図２の序列テーブル記録部２４に記録される組織序列テーブルの一例を示す図である。
【図７】図２の序列テーブル記録部２４に記録されるＡプロジェクト序列テーブルの一例を示す図である。
【図８】図２の序列テーブル記録部２４に記録されるＢプロジェクト序列テーブルの一例を示す図である。
【図９】図２の役職テーブル記録部２５に記録される役職テーブルの一例を示す図である。
【図１０】図１のサーバ１の帳票データ作成処理を示すフローチャートである。
【図１１】図２の帳票データ記録部２１に記録される帳票データの一例を示す図である。
【図１２】図１のサーバ１の承認・却下処理を示すフローチャートである。
【図１３】図１のサーバ１の承認ルート作成・更新処理を示すフローチャートである。
【符号の説明】
【００７１】
１  サーバ
１０  システム
１１〜１ｎ  クライアント端末
２０  帳票データテンプレート記録部
２１  帳票データ記録部
２２  従業員テーブル記録部
２３  承認者テーブル記録部
２４  序列テーブル記録部
２５  役職テーブル記録部
２６  帳票データ作成処理部
２７  承認ルート決定処理部
２８  承認・却下処理部
２９  承認ルート作成・更新処理部
【図１】
2008130006.tif 000003
【図２】
2008130006.tif 000004
【図３】
2008130006.tif 000005
【図４】
2008130006.tif 000006
【図５】
2008130006.tif 000007
【図６】
2008130006.tif 000008
【図７】
2008130006.tif 000009
【図８】
2008130006.tif 000010
【図９】
2008130006.tif 000011
【図１０】
2008130006.tif 000012
【図１１】
2008130006.tif 000013
【図１２】
2008130006.tif 000014
【図１３】
2008130006.tif 000015