JP2005018389A - 業務管理装置及び方法並びに業務管理プログラム - Google Patents

Abstract

【課題】人事異動等が生じた場合であっても柔軟に対応できる業務管理装置等を提供する。
【解決手段】申請テーブルを記録する申請テーブル記録部２１と、従業員テーブルを記録する従業員テーブル２２と、承認者テーブルを記録する承認者テーブル記録部２３と、組織テーブルを記録する組織テーブル記録部２４と、役職テーブルを記録する役職テーブル記録部２５と、申請データを作成して申請テーブル記録部２１に記録させる申請データ作成処理部２６と、申請を承認すべき従業員を決定する承認ルート決定処理部２７と、従業員からの指示に応じて承認又は却下を表すデータを申請テーブルに書き込む承認・却下処理部２８と、従業員からの指示に応じて承認者テーブル又は組織テーブルを作成又は更新する承認ルート作成・更新処理部２９とを具備する。
【選択図】 図２

Description

【０００１】
【発明の属する技術分野】
本発明は、組織における申請及び承認に関する業務の管理を行うための業務管理装置に関し、さらに、業務管理方法及び業務管理プログラムに関する。
【０００２】
【従来の技術】
従来より、組織における申請及び承認に関する業務の管理を行うための業務管理装置が用いられている。
しかしながら、従来の業務管理装置においては、人事異動、組織変更等により承認権限を有する者の変更が生じた場合に、柔軟に対応することができなかった。
【０００３】
【発明が解決しようとする課題】
そこで、上記の点に鑑み、本発明は、人事異動等が生じた場合であっても、柔軟に対応することができる業務管理装置を提供することを目的とする。また、本発明は、そのような業務管理方法及び業務管理プログラムを提供することを目的とする。
【０００４】
【課題を解決するための手段】
以上の課題を解決するため、本発明に係る業務管理装置は、組織における申請及び承認に関する業務の管理を行うための装置であって、組織を構成する複数の構成者及び承認権限を有する複数の者に相当する第１群のノードに関する情報をそれぞれ格納する複数のレコードを含む第１のテーブルであって、各レコードが、複数の構成者又は第１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、複数の構成者又は第１群のノードの組織における序列を表す第２の識別子であって、第２の識別子に対して所定の演算を施すことにより複数の構成者の申請に対する承認権限を有する複数の者に相当する第１群のノードを特定することが可能な第２の識別子を格納する第２のフィールドとを有する第１のテーブルを記録する第１の記録手段と、第１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、第１群のノードに係る承認権限を有する者としての複数の構成者を一意に特定する第１の識別子を格納する第２のフィールドとを有する第２のテーブルを記録する第２の記録手段と、申請に関する第３のテーブルであって、複数の構成者の中の申請を行った者を一意に特定する第１の識別子を格納する第１のフィールドと、当該申請に対する承認が得られたか否かを表す複数のデータをそれぞれ格納する第２群のフィールドとを有する第３のテーブルを記録する第３の記録手段と、第３のテーブル内の第１の識別子に基づいて第１のテーブルを検索することにより第２の識別子を抽出し、抽出された第２の識別子に所定の演算を施すことにより得られた値を第２の識別子として有するレコードを第１のテーブルから検索することにより第１の識別子を抽出し、抽出された第１の識別子に基づいて第２のテーブルを検索することにより、承認権限を有する者としての複数の構成者を特定する第１の処理手段と、第１の処理手段によって特定された承認権限を有する者としての複数の構成者からの承認又は却下の指示に応じて、申請が承認されたこと又は却下されたことを表す複数の値を第３のテーブル内の第２群のフィールドに書き込む第２の処理手段とを具備する。
【０００５】
ここで、第１のテーブルが、組織内の複数の部署に相当する第２群のノードに関する情報をそれぞれ格納する複数のレコードを更に含むこととしても良いし、レコード内の情報が有効となった日又は有効となる日を表すデータを格納するフィールドを更に有することとしても良い。
また、第３のテーブルが、申請に関する情報を入力した日又は申請に係る事案が行われた日若しくは行われる日を表すデータを格納するフィールドを更に有することとしても良い。
【０００６】
また、第１のテーブル内の各レコードが、複数の構成者又は第１群若しくは第２群のノードの組織上における上位の複数の構成者又は第１群若しくは第２群のノードの第２の識別子の末尾に所定の長さを有する値を付加した値を第２の識別子として格納することとしても良い。このとき、第１の処理手段が行う所定の演算が、第２の識別子の末尾から所定の長さの値を削除する演算であることとしても良い。さらに、第１の処理手段が、第２の識別子の末尾から所定の長さの値を削除する演算を順次繰り返すこととしても良い。
【０００７】
また、本発明に係る業務管理方法は、組織における申請及び承認に関する業務の管理を行うための方法であって、組織を構成する複数の構成者及び承認権限を有する複数の者に相当する第１群のノードに関する情報をそれぞれ格納する複数のレコードを含む第１のテーブルであって、各レコードが、複数の構成者又は第１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、複数の構成者又は第１群のノードの組織における序列を表す第２の識別子であって、第２の識別子に対して所定の演算を施すことにより複数の構成者の申請に対する承認権限を有する複数の者に相当する第１群のノードを特定することが可能な第２の識別子を格納する第２のフィールドとを有する第１のテーブルを記録するステップ（ａ）と、第１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、第１群のノードに係る承認権限を有する者としての複数の構成者を一意に特定する第１の識別子を格納する第２のフィールドとを有する第２のテーブルを記録するステップ（ｂ）と、申請に関する第３のテーブルであって、複数の構成者の中の申請を行った者を一意に特定する第１の識別子を格納する第１のフィールドと、当該申請に対する承認が得られたか否かを表す複数のデータをそれぞれ格納する第２群のフィールドとを有する第３のテーブルを記録するステップ（ｃ）と、第３のテーブル内の第１の識別子に基づいて第１のテーブルを検索することにより第２の識別子を抽出するステップ（ｄ）と、抽出された第２の識別子に所定の演算を施すことにより得られた値を第２の識別子として有するレコードを第１のテーブルから検索することにより第１の識別子を抽出するステップ（ｅ）と、ステップ（ｅ）にて抽出された第１の識別子に基づいて第２のテーブルを検索することにより、承認権限を有する者としての複数の構成者を特定するステップ（ｆ）と、ステップ（ｆ）にて特定された承認権限を有する者としての複数の構成者からの承認又は却下の指示に応じて、申請が承認されたこと又は却下されたことを表す複数の値を第３のテーブル内の第２群のフィールドに書き込むステップ（ｇ）とを具備する。
【０００８】
ここで、第１のテーブルが、組織内の複数の部署に相当する第２群のノードに関する情報をそれぞれ格納する複数のレコードを更に含むこととしても良いし、レコード内の情報が有効となった日又は有効となる日を表すデータを格納するフィールドを更に有することとしても良い。
また、第３のテーブルが、申請に関する情報を入力した日又は申請に係る事案が行われた日若しくは行われる日を表すデータを格納するフィールドを更に有することとしても良い。
【０００９】
また、第１のテーブル内の各レコードが、複数の構成者又は第１群若しくは第２群のノードの組織上における上位の複数の構成者又は第１群若しくは第２群のノードの第２の識別子の末尾に所定の長さを有する値を付加した値を第２の識別子として格納することとしても良い。このとき、所定の演算が、第２の識別子の末尾から所定の長さの値を削除する演算であることとしても良い。
また、ステップ（ｅ）〜ステップ（ｇ）を順次繰り返すステップ（ｈ）を更に具備することとしても良い。
【００１０】
さらに、本発明に係る業務管理プログラムは、組織における申請及び承認に関する業務の管理を行うためのプログラムであって、組織を構成する複数の構成者及び承認権限を有する複数の者に相当する第１群のノードに関する情報をそれぞれ格納する複数のレコードを含む第１のテーブルであって、各レコードが、複数の構成者又は第１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、複数の構成者又は第１群のノードの組織における序列を表す第２の識別子であって、第２の識別子に対して所定の演算を施すことにより複数の構成者の申請に対する承認権限を有する複数の者に相当する第１群のノードを特定することが可能な第２の識別子を格納する第２のフィールドとを有する第１のテーブルを記録する手順（ａ）と、第１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、第１群のノードに係る承認権限を有する者としての複数の構成者を一意に特定する第１の識別子を格納する第２のフィールドとを有する第２のテーブルを記録する手順（ｂ）と、申請に関する第３のテーブルであって、複数の構成者の中の申請を行った者を一意に特定する第１の識別子を格納する第１のフィールドと、当該申請に対する承認が得られたか否かを表す複数のデータをそれぞれ格納する第２群のフィールドとを有する第３のテーブルを記録する手順（ｃ）と、第３のテーブル内の第１の識別子に基づいて第１のテーブルを検索することにより第２の識別子を抽出する手順（ｄ）と、抽出された第２の識別子に所定の演算を施すことにより得られた値を第２の識別子として有するレコードを第１のテーブルから検索することにより第１の識別子を抽出する手順（ｅ）と、手順（ｅ）にて抽出された第１の識別子に基づいて第２のテーブルを検索することにより、承認権限を有する者としての複数の構成者を特定する手順（ｆ）と、手順（ｆ）にて特定された承認権限を有する者としての複数の構成者からの承認又は却下の指示に応じて、申請が承認されたこと又は却下されたことを表す複数の値を第３のテーブル内の第２群のフィールドに書き込む手順（ｇ）とをＣＰＵに実行させる。
【００１１】
ここで、第１のテーブルが、組織内の複数の部署に相当する第２群のノードに関する情報をそれぞれ格納する複数のレコードを更に含むこととしても良いし、レコード内の情報が有効となった日又は有効となる日を表すデータを格納するフィールドを更に有することとしても良い。
また、第３のテーブルが、申請に関する情報を入力した日又は申請に係る事案が行われた日若しくは行われる日を表すデータを格納するフィールドを更に有することとしても良い。
【００１２】
また、第１のテーブル内の各レコードが、複数の構成者又は第１群若しくは第２群のノードの組織上における上位の複数の構成者又は第１群若しくは第２群のノードの第２の識別子の末尾に所定の長さを有する値を付加した値を第２の識別子として格納することとしても良い。このとき、所定の演算が、第２の識別子の末尾から所定の長さの値を削除する演算であることとしても良い。
また、手順（ｅ）〜手順（ｇ）を繰り返す手順（ｈ）を更に具備することとしても良い。
【００１３】
上記構成によれば、人事異動等が生じた場合であっても、柔軟に対応することができる。
【００１４】
【発明の実施の形態】
以下、図面に基づいて本発明の実施の形態について説明する。
図１は、本発明の一実施形態に係る業務管理装置を用いたシステムを示す図である。本実施形態は、本発明を企業における申請及び承認業務を管理するシステムに適用したものである。図１に示すように、システム１０は、本発明の一実施形態としてのサーバ１と、クライアント端末１１〜１ｎとを具備しており、これらは、ネットワークを介して相互に接続されている。
図２は、図１のサーバ１の構成を示す図である。図２に示すように、サーバ１は、申請テーブル記録部２１と、従業員テーブル記録部２２と、承認者テーブル記録部２３と、組織テーブル記録部２４と、役職テーブル記録部２５と、申請データ作成処理部２６と、承認ルート決定処理部２７と、承認・却下処理部２８と、承認ルート作成・更新処理部２９とを具備する。
【００１５】
図３は、申請テーブル記録部２１に記録される申請テーブルの一例を示す図である。図３に示すように、申請テーブルは、申請の内容に関する情報及び承認状況に関する情報を格納するフィールドを有する。申請の内容に関する情報は、伝票名（例えば、休暇届、直行届等）、実施日（例えば、休暇日、直行日等）、申請者を一意に特定するユーザＩＤを含む。また、承認状況に関する情報は、第１承認（例えば、課長承認等）、第２承認（例えば、部長承認等）、…と、全ての承認が完了したか否かを示す完了フラグとを含む。図３に示す申請テーブル内のレコードは、ユーザＩＤが「Ｔａｋａｄａ」である従業員が２００３年５月１日に休暇を取得するための申請に係るレコードであり、この申請は未だ承認を受けていないことを表している。
【００１６】
再び図２を参照すると、従業員テーブル記録部２２は、従業員に関するデータを格納する従業員テーブルを記録する。図４は、従業員テーブルの一例を示す図である。図４に示すように、従業員テーブルは、従業員を一意に特定するユーザＩＤ、従業員を一意に特定する従業員番号、及び、従業員の氏名を格納するフィールドを有している。
【００１７】
再び図２を参照すると、承認者テーブル記録部２３は、承認権限を有する者に関するデータを格納する承認者テーブルを記録する。図５は、承認者テーブルの一例を示す図である。図５に示すように、承認者テーブルは、承認権限を有する者に相当するノードの名称、承認権限を有する者に相当するノードを一意に特定するユーザＩＤ、及び、承認権限を有する者としての従業員のユーザＩＤを格納するフィールドを有している。なお、図５に示す承認者テーブルにおいて、「完了箱」という名称を有するノードは、承認が完了した申請データを管理又は処理する権限を有する者（例えば、企業等の総務課長、総務部長、人事課長、人事部長等）に相当する。本実施形態においては、具体的には、承認が完了した申請データを管理又は処理する権限を有する者は、ユーザＩＤが「Ｔａｒｏ」である従業員（ここでは、氏名「総務 太郎」（図４参照））と、ユーザＩＤが「Ｊｉｒｏ」である従業員（ここでは、氏名「総務 次郎」（図４参照））である。
【００１８】
再び図２を参照すると、組織テーブル記録部２４は、組織に関するデータを格納する組織テーブルを記録する。図６は、組織テーブルの一例を示す図である。図６に示すように、組織テーブルは、レコード番号（Ｎｏ．）、改定日、ユーザＩＤ、当該レコードの組織上における区分である組織区分、組織所属名、氏名、及び、組織序列番号を格納するフィールドを有している。
【００１９】
図６に示す組織テーブルにおいて、改定日とは、当該レコードに格納されているデータが有効となった日又は有効となる日を表す。
組織区分は、１〜３までの値を取り得る。ここで、組織区分「１」は、当該レコードが部署に相当するノードに関するレコードであることを表す。また、組織区分「２」は、当該レコードが承認権限を有する者に相当するノードに関するレコードであることを表し、組織区分「３」は、当該レコードが従業員に関するレコードであることを表す。
【００２０】
組織序列番号は、部署に相当するノード、承認権限を有する者に相当するノード、又は、従業員（以下、「従業員等」という）の組織上における序列（位置付け）を表す番号である。本実施形態においては、組織序列番号は、４ｎ（ｎは、自然数）桁の数であり、或る従業員等の組織序列番号は、当該従業員等の直近上位の従業員等の組織序列番号の末尾に４桁の数を付加した番号となっている。例えば、図６に示す組織テーブルにおいて、第１レコード（組織所属名「東京本社」）には、組織序列番号「０００１」が格納されており、第１レコードによって表されるノードの下位に位置するノードとしての第２レコード（組織所属名「東京本社」、氏名「完了箱」）には、第１レコード内の組織序列番号「０００１」の末尾に「０００１」を付加した組織序列番号「０００１０００１」が格納されている。また、例えば、従業員「高田 由美子」（第１４レコードに相当）の直近上位の従業員等は、第１４レコード内の組織序列番号「０００１０００１０００１０００２０００２０００２０００１０００２０００２」の末尾４桁を削除した値「０００１０００１０００１０００２０００２０００２０００１０００２」を組織序列番号として格納しているレコード（ここでは、第１２レコード）によって表される従業員等（ここでは、承認権限を有する者に相当するノード「営業部１課１Ｇ承認者」）となる。
【００２１】
再び図２を参照すると、役職テーブル記録部２５は、従業員の役職に関するデータを格納する役職テーブルを記録する。図７は、役職テーブルの一例を示す図である。図７に示すように、役職テーブルは、ユーザＩＤ、当該レコードが有効となった日又は有効となる日を表す改定日、及び、役職を格納するフィールドを有している。図７においては、例えば、ユーザＩＤが「Ｔａｒｏ」である従業員（本実施形態においては、氏名「総務 太郎」（図４参照））は、１９８３年４月１日に一般従業員となり、１９９３年４月１日に総務課長となり、１９９８年４月１日に総務部長となったことを表している。
【００２２】
再び図２を参照すると、申請データ作成処理部２６は、クライアント端末１１〜１ｎを使用する従業員からの要求に応じて、申請データを作成し、申請テーブル記録部２１に記録させる。
承認ルート決定処理部２７は、申請テーブル記録部２１に記録されている申請テーブル内の申請データに係る申請を承認すべき従業員を決定する処理を行う。
【００２３】
承認・却下処理部２８は、承認ルート決定処理部２７によって決定された従業員からの指示に応じて承認又は却下処理を行う。
承認ルート作成・更新処理部２９は、承認者テーブル又は組織テーブルの作成又は更新処理を行う。
【００２４】
図２に示す申請データ作成処理部２６、承認ルート決定処理部２７、承認・却下処理部２８、及び、承認ルート作成・更新処理部２９は、ＣＰＵとソフトウェア（プログラム）で構成することができる。このプログラムと、申請テーブル、従業員テーブル、承認者テーブル、組織テーブル、及び、役職テーブルは、ハードディスク、フレキシブルディスク、ＭＯ、ＭＴ、ＲＡＭ、ＣＤ−ＲＯＭ、又は、ＤＶＤ−ＲＯＭ等の記録媒体に記録することができる。
【００２５】
図８は、サーバ１の申請データ作成処理の概要を示すフローチャートである。以下、サーバ１の申請データ作成処理について、図８を参照しながら説明する。ここでは、従業員「高田 由美子」が、休暇届に係る申請データを作成するものとする。
まず、クライアント端末（ここでは、クライアント端末１１とする）を使用している従業員（ここでは、「高田 由美子」）が、申請の内容に関する情報（ここでは、伝票名「休暇届」及び休暇を取得することを所望する日「２００３／０５／０１」）を入力し、サーバ１の申請データ作成処理部２６が、この条件を受信する（ステップＳ１０１）。
【００２６】
次に、申請データ作成処理部２６は、伝票名「休暇届」、実施日「２００３／０５／０１」、ユーザＩＤ「Ｔａｋａｄａ」を有する申請データを作成し（図３参照）、申請テーブル記録部２１に記録させる（ステップＳ１０２）。
【００２７】
図９は、サーバ１の承認・却下処理の概要を示すフローチャートである。以下、サーバ１の承認・却下処理について、図９を参照しながら説明する。
まず、承認ルート決定処理部２７が、申請データ記録部２１に記録されている申請テーブル内のレコード（図３参照）内のユーザＩＤ（ここでは、「Ｔａｋａｄａ」）を抽出する（ステップＳ２０１）。
【００２８】
次に、承認ルート決定処理部２７は、組織テーブル記録部２４に記録されている組織テーブル（図６参照）の中から、ステップＳ２０１にて抽出されたユーザＩＤ（ここでは、「Ｔａｋａｄａ」）を格納しているレコードを検索し、当該レコード内の組織序列番号（ここでは、「０００１０００１０００１０００２０００２０００２０００１０００２０００２」）を抽出する（ステップＳ２０２）。なお、このとき、ステップＳ２０１にて抽出されたユーザＩＤを格納しているレコードが複数存在している場合には、システム日付において有効なレコードを選択する。
そして、承認ルート決定処理部２７は、ステップＳ２０２にて抽出された組織序列番号（ここでは、「０００１０００１０００１０００２０００２０００２０００１０００２０００２」）の下位４桁を削除した値（ここでは、「０００１０００１０００１０００２０００２０００２０００１０００２」）を算出する（ステップＳ２０３）。
【００２９】
次に、承認ルート決定処理部２７は、組織テーブル記録部２４に記録されている組織テーブル（図６参照）の中から、ステップＳ２０３にて算出された値（ここでは、「０００１０００１０００１０００２０００２０００２０００１０００２」）を組織序列番号として格納しているレコード（ここでは、第１２レコード）を検索し、当該レコード内のユーザＩＤ（ここでは、「Ｅｉｇｙｏ＿Ｂ＿１Ｋ＿１Ｇ」）を抽出する（ステップＳ２０４）。なお、このとき、ステップＳ２０３にて算出された値を組織序列番号として格納しているレコードが複数存在している場合には、システム日付において有効なレコードを選択する。
そして、承認ルート決定処理部２７は、承認者テーブル記録部２３に記録されている承認者テーブル（図５参照）の中から、ステップＳ２０４にて抽出されたユーザＩＤ（ここでは、「Ｅｉｇｙｏ＿Ｂ＿１Ｋ＿１Ｇ」）を承認権限を有する者に相当するノードのユーザＩＤとして格納しているレコード（ここでは、第５レコード）を検索し、当該レコードに格納されている承認権限を有する者としての従業員のユーザＩＤ（ここでは、「Ｍｏｒｉ」）を抽出する（ステップＳ２０５）。なお、このとき、ステップＳ２０４にて抽出されたユーザＩＤを格納しているレコードが複数存在している場合には、システム日付において有効なレコードを選択する。これにより、申請データ（図３参照）に対する承認又は却下処理を最初に行うべき従業員（ここでは、ユーザＩＤ「Ｍｏｒｉ」、氏名「森 祐司」である従業員）を決定することができる。承認ルート決定処理部２７は、このユーザＩＤを承認・却下処理部２８に出力する。
【００３０】
次に、承認・却下処理部２８は、ステップＳ２０５にて抽出されたユーザＩＤ（ここでは、「Ｍｏｒｉ」）を有する従業員（ここでは、「森 祐司」）が使用するクライアント端末（ここでは、クライアント端末１２とする）に、申請データの内容を表示させる（ステップＳ２０６）。
そして、承認・却下処理部２８は、ステップＳ２０５にて抽出されたユーザＩＤを有する従業員（ここでは、「森 祐司」）からの指示に応じて（ここでは、従業員「森 祐司」は、承認する旨の指示を入力するものとする）、申請データ内の複数の承認欄の中の１つの承認欄（ここでは、第１承認欄）の値を書き換える（ステップＳ２０７）。図１０は、書き換え後の申請データを表す図である。
【００３１】
次に、承認ルート決定処理部２７は、全ての承認が完了しているか否かをチェックし、全ての承認が完了していると判断した場合には処理を終了し、そうでない場合には、処理をステップＳ２０３に戻す（ステップＳ２０８）。
【００３２】
図１１は、サーバ１の承認ルート作成・更新処理の概要を示すフローチャートである。以下、サーバ１の承認ルート作成・更新処理について、図１１を参照しながら説明する。
承認ルート作成・更新処理部２９は、クライアント端末（ここでは、クライアント端末１３とする）を使用している従業員から、承認権限を有する者としての従業員の追加、削除、又は、変更を行うためのデータを受け取り、承認者テーブル記録部２３に記録されている承認者テーブル又は組織テーブル記録部２４に記録されている組織テーブルの作成又は更新を行う（ステップＳ３０１）。
【００３３】
このように、本実施形態においては、組織に関する情報、承認権限を有する者に関する情報、及び、申請に関する情報を分離して、組織テーブル、承認者テーブル、及び、申請テーブル内にそれぞれ格納することにより、各テーブル内の情報の更新を容易にすることができ、人事異動等が生じた場合であっても柔軟に対応することができる。
【００３４】
【発明の効果】
以上述べた様に、本発明によれば、人事異動等が生じた場合であっても、柔軟に対応することができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係る業務管理装置を用いたシステムの構成を示す図である。
【図２】図１のサーバ１の構成を示す図である。
【図３】図２の申請テーブル記録部２１に記録される申請テーブルの一例を示す図である。
【図４】図２の従業員テーブル記録部２２に記録される従業員テーブルの一例を示す図である。
【図５】図２の承認者テーブル記録部２３に記録される承認者テーブルの一例を示す図である。
【図６】図２の組織テーブル記録部２４に記録される組織テーブルの一例を示す図である。
【図７】図２の役職テーブル記録部２５に記録される役職テーブルの一例を示す図である。
【図８】図１のサーバ１の申請データ作成処理を示すフローチャートである。
【図９】図１のサーバ１の承認・却下処理を示すフローチャートである。
【図１０】図２の申請テーブル記録部２１に記録される申請テーブルの一例を示す図である。
【図１１】図１のサーバ１の承認ルート作成・更新処理を示すフローチャートである。
【符号の説明】
１ サーバ
１０ システム
１１〜１ｎ クライアント端末
２１ 申請テーブル記録部
２２ 従業員テーブル記録部
２３ 承認者テーブル記録部
２４ 組織テーブル記録部
２５ 役職テーブル記録部
２６ 申請データ作成処理部
２７ 承認ルート決定処理部
２８ 承認・却下処理部
２９ 承認ルート作成・更新処理部

Claims (21)

1. 組織における申請及び承認に関する業務の管理を行うための装置であって、
   組織を構成する複数の構成者及び承認権限を有する複数の者に相当する第１群のノードに関する情報をそれぞれ格納する複数のレコードを含む第１のテーブルであって、各レコードが、前記複数の構成者又は前記第１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、前記複数の構成者又は前記第１群のノードの組織における序列を表す第２の識別子であって、前記第２の識別子に対して所定の演算を施すことにより前記複数の構成者の申請に対する承認権限を有する複数の者に相当する前記第１群のノードを特定することが可能な前記第２の識別子を格納する第２のフィールドとを有する前記第１のテーブルを記録する第１の記録手段と、
   前記第１群のノードを一意に特定する前記第１の識別子を格納する第１のフィールドと、前記第１群のノードに係る承認権限を有する者としての前記複数の構成者を一意に特定する前記第１の識別子を格納する第２のフィールドとを有する第２のテーブルを記録する第２の記録手段と、
   申請に関する第３のテーブルであって、前記複数の構成者の中の申請を行った者を一意に特定する前記第１の識別子を格納する第１のフィールドと、当該申請に対する承認が得られたか否かを表す複数のデータをそれぞれ格納する第２群のフィールドとを有する前記第３のテーブルを記録する第３の記録手段と、
   前記第３のテーブル内の前記第１の識別子に基づいて前記第１のテーブルを検索することにより前記第２の識別子を抽出し、抽出された前記第２の識別子に前記所定の演算を施すことにより得られた値を前記第２の識別子として有するレコードを前記第１のテーブルから検索することにより前記第１の識別子を抽出し、抽出された前記第１の識別子に基づいて前記第２のテーブルを検索することにより、承認権限を有する者としての前記複数の構成者を特定する第１の処理手段と、
   前記第１の処理手段によって特定された承認権限を有する者としての前記複数の構成者からの承認又は却下の指示に応じて、申請が承認されたこと又は却下されたことを表す複数の値を前記第３のテーブル内の前記第２群のフィールドに書き込む第２の処理手段と、を具備する業務管理装置。
2. 前記第１のテーブルが、組織内の複数の部署に相当する第２群のノードに関する情報をそれぞれ格納する複数のレコードを更に含む、請求項１記載の業務管理装置。
3. 前記第１のテーブルが、レコード内の情報が有効となった日又は有効となる日を表すデータを格納するフィールドを更に有する、請求項１又は２記載の業務管理装置。
4. 前記第３のテーブルが、申請に関する情報を入力した日又は申請に係る事案が行われた日若しくは行われる日を表すデータを格納するフィールドを更に有する、請求項１〜３のいずれか１項に記載の業務管理装置。
5. 前記第１のテーブル内の各レコードが、前記複数の構成者又は前記第１群若しくは第２群のノードの組織上における上位の前記複数の構成者又は前記第１群若しくは第２群のノードの前記第２の識別子の末尾に所定の長さを有する値を付加した値を前記第２の識別子として格納する、請求項１〜４のいずれか１項に記載の業務管理装置。
6. 前記第１の処理手段が行う前記所定の演算が、前記第２の識別子の末尾から前記所定の長さの値を削除する演算である、請求項５記載の業務管理装置。
7. 前記第１の処理手段が、前記第２の識別子の末尾から前記所定の長さの値を削除する演算を順次繰り返す、請求項６記載の業務管理装置。
8. 組織における申請及び承認に関する業務の管理を行うための方法であって、
   組織を構成する複数の構成者及び承認権限を有する複数の者に相当する第１群のノードに関する情報をそれぞれ格納する複数のレコードを含む第１のテーブルであって、各レコードが、前記複数の構成者又は前記第１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、前記複数の構成者又は前記第１群のノードの組織における序列を表す第２の識別子であって、前記第２の識別子に対して所定の演算を施すことにより前記複数の構成者の申請に対する承認権限を有する複数の者に相当する前記第１群のノードを特定することが可能な前記第２の識別子を格納する第２のフィールドとを有する前記第１のテーブルを記録するステップ（ａ）と、
   前記第１群のノードを一意に特定する前記第１の識別子を格納する第１のフィールドと、前記第１群のノードに係る承認権限を有する者としての前記複数の構成者を一意に特定する前記第１の識別子を格納する第２のフィールドとを有する第２のテーブルを記録するステップ（ｂ）と、
   申請に関する第３のテーブルであって、前記複数の構成者の中の申請を行った者を一意に特定する前記第１の識別子を格納する第１のフィールドと、当該申請に対する承認が得られたか否かを表す複数のデータをそれぞれ格納する第２群のフィールドとを有する前記第３のテーブルを記録するステップ（ｃ）と、
   前記第３のテーブル内の前記第１の識別子に基づいて前記第１のテーブルを検索することにより前記第２の識別子を抽出するステップ（ｄ）と、
   抽出された前記第２の識別子に前記所定の演算を施すことにより得られた値を前記第２の識別子として有するレコードを前記第１のテーブルから検索することにより前記第１の識別子を抽出するステップ（ｅ）と、
   ステップ（ｅ）にて抽出された前記第１の識別子に基づいて前記第２のテーブルを検索することにより、承認権限を有する者としての前記複数の構成者を特定するステップ（ｆ）と、
   ステップ（ｆ）にて特定された承認権限を有する者としての前記複数の構成者からの承認又は却下の指示に応じて、申請が承認されたこと又は却下されたことを表す複数の値を前記第３のテーブル内の前記第２群のフィールドに書き込むステップ（ｇ）と、を具備する業務管理方法。
9. 前記第１のテーブルが、組織内の複数の部署に相当する第２群のノードに関する情報をそれぞれ格納する複数のレコードを更に含む、請求項８記載の業務管理方法。
10. 前記第１のテーブルが、レコード内の情報が有効となった日又は有効となる日を表すデータを格納するフィールドを更に有する、請求項８又は９記載の業務管理方法。
11. 前記第３のテーブルが、申請に関する情報を入力した日又は申請に係る事案が行われた日若しくは行われる日を表すデータを格納するフィールドを更に有する、請求項８〜１０のいずれか１項に記載の業務管理方法。
12. 前記第１のテーブル内の各レコードが、前記複数の構成者又は前記第１群若しくは第２群のノードの組織上における上位の前記複数の構成者又は前記第１群若しくは第２群のノードの前記第２の識別子の末尾に所定の長さを有する値を付加した値を前記第２の識別子として格納する、請求項８〜１１のいずれか１項に記載の業務管理方法。
13. 前記所定の演算が、前記第２の識別子の末尾から前記所定の長さの値を削除する演算である、請求項１２記載の業務管理方法。
14. ステップ（ｅ）〜ステップ（ｇ）を繰り返すステップ（ｈ）を更に具備する、請求項１３記載の業務管理方法。
15. 組織における申請及び承認に関する業務の管理を行うためのプログラムであって、
    組織を構成する複数の構成者及び承認権限を有する複数の者に相当する第１群のノードに関する情報をそれぞれ格納する複数のレコードを含む第１のテーブルであって、各レコードが、前記複数の構成者又は前記第１群のノードを一意に特定する第１の識別子を格納する第１のフィールドと、前記複数の構成者又は前記第１群のノードの組織における序列を表す第２の識別子であって、前記第２の識別子に対して所定の演算を施すことにより前記複数の構成者の申請に対する承認権限を有する複数の者に相当する前記第１群のノードを特定することが可能な前記第２の識別子を格納する第２のフィールドとを有する前記第１のテーブルを記録する手順（ａ）と、
    前記第１群のノードを一意に特定する前記第１の識別子を格納する第１のフィールドと、前記第１群のノードに係る承認権限を有する者としての前記複数の構成者を一意に特定する前記第１の識別子を格納する第２のフィールドとを有する第２のテーブルを記録する手順（ｂ）と、
    申請に関する第３のテーブルであって、前記複数の構成者の中の申請を行った者を一意に特定する前記第１の識別子を格納する第１のフィールドと、当該申請に対する承認が得られたか否かを表す複数のデータをそれぞれ格納する第２群のフィールドとを有する前記第３のテーブルを記録する手順（ｃ）と、
    前記第３のテーブル内の前記第１の識別子に基づいて前記第１のテーブルを検索することにより前記第２の識別子を抽出する手順（ｄ）と、
    抽出された前記第２の識別子に前記所定の演算を施すことにより得られた値を前記第２の識別子として有するレコードを前記第１のテーブルから検索することにより前記第１の識別子を抽出する手順（ｅ）と、
    手順（ｅ）にて抽出された前記第１の識別子に基づいて前記第２のテーブルを検索することにより、承認権限を有する者としての前記複数の構成者を特定する手順（ｆ）と、
    手順（ｆ）にて特定された承認権限を有する者としての前記複数の構成者からの承認又は却下の指示に応じて、申請が承認されたこと又は却下されたことを表す複数の値を前記第３のテーブル内の前記第２群のフィールドに書き込む手順（ｇ）と、をＣＰＵに実行させるための業務管理プログラム。
16. 前記第１のテーブルが、組織内の複数の部署に相当する第２群のノードに関する情報をそれぞれ格納する複数のレコードを更に含む、請求項１５記載の業務管理プログラム。
17. 前記第１のテーブルが、レコード内の情報が有効となった日又は有効となる日を表すデータを格納するフィールドを更に有する、請求項１５又は１６記載の業務管理プログラム。
18. 前記第３のテーブルが、申請に関する情報を入力した日又は申請に係る事案が行われた日若しくは行われる日を表すデータを格納するフィールドを更に有する、請求項１５〜１７のいずれか１項に記載の業務管理プログラム。
19. 前記第１のテーブル内の各レコードが、前記複数の構成者又は前記第１群若しくは第２群のノードの組織上における上位の前記複数の構成者又は前記第１群若しくは第２群のノードの前記第２の識別子の末尾に所定の長さを有する値を付加した値を前記第２の識別子として格納する、請求項１５〜１８のいずれか１項に記載の業務管理プログラム。
20. 前記所定の演算が、前記第２の識別子の末尾から前記所定の長さの値を削除する演算である、請求項１９記載の業務管理プログラム。
21. 手順（ｅ）〜手順（ｇ）を繰り返す手順（ｈ）を更に具備する、請求項２０記載の業務管理プログラム。

Images