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

Abstract

【課題】組織の上位階層を改編した場合であっても柔軟に対応することを可能とする。
【解決手段】組織テーブル記録部２４は、組織における上位の各構成者に対応する情報をそれぞれ格納するレコードを含む第１のテーブルと、前記組織における下位の各構成者に対応する情報をそれぞれ格納するレコードを含む第２のテーブルを記録する。承認ルート決定処理部２７は、前記第２のテーブル内に承認権限を有する者が存在しない場合に、申請者の第３の識別子を抽出し、抽出された前記第３の識別子を前記第３の識別子として格納している少なくとも１つのレコードを前記第１のテーブルから検索することにより、申請に対する承認権限を有する少なくとも１人の者を特定する。
【選択図】図２

Description

本発明は、組織における申請及び承認に関する業務の管理を行うための業務管理装置に関し、さらに、業務管理方法及び業務管理プログラムに関する。

従来より、組織における申請及び承認に関する業務の管理を行うための業務管理装置が用いられている。
しかしながら、従来の業務管理装置においては、人事異動、組織変更等により承認権限を有する者の変更が生じた場合に、柔軟に対応することができなかった。

このような問題に鑑み、本出願人は、人事異動等が生じた場合であっても、柔軟に対応することができる業務管理装置を提案した（下記の特許文献１参照）。
特許第３８１８４４９号公報

上記の特許文献１記載の技術によれば、第１のテーブルが、複数の構成者又は第１群のノードの組織における序列を表す第２の識別子であって、複数の構成者の中の任意の者の第２の識別子の末尾から所定の長さの値を少なくとも１回削除する演算を行うことにより複数の構成者の中の任意の者の組織上において上位であり且つ申請に対する承認権限を有する少なくとも１人の者に相当する第１群のノードの中の少なくとも１つのノードの第２の識別子を得ることができる第２の識別子を格納することとしており、この第２の識別子を利用することにより、申請等を行った構成者の組織上において上位であり且つ申請に対する承認権限を有する者を特定することができる。これにより、人事異動等が生じた場合であっても、柔軟に対応することができる。

しかしながら、上記の特許文献１記載の技術では、第１のテーブルのうち組織における上位階層において第２の識別子を変更すると、その配下の全構成者に関するレコードを更新する必要がある。例えば、「東京本社営業部」内で最終的な承認権限を有する者（営業部長）に対応する第２の識別子として「０００２」が付与されていた場合には、特許文献１記載の技術では「０００２」に所定の長さの値を少なくとも１回付加したものが東京本社営業部の次長以下の全構成者に付与される。この場合に「東京本社営業部」を「東京本社第１営業部」と「東京本社第２営業部」に分割するなどの組織再編を行うと、それぞれの部内で最終的な承認権限を有する者（第１営業部長、第２営業部長）に対応する第２の識別子をそれぞれ設定する必要があるため、その配下の全構成者について第２の識別子を更新する必要があり、作業が煩雑となる恐れがある。

そこで、本発明は、組織の上位階層を改編した場合であっても柔軟に対応することを可能とする業務管理装置を提供することを目的とする。また、本発明は、そのような業務管理方法及び業務管理プログラムを提供することを目的とする。

以上の課題を解決するため、本発明に係る業務管理装置は、組織における申請及び承認に関する業務の管理を行うための装置であって、
複数の構成者により構成される組織における上位の各構成者に対応する情報をそれぞれ格納するレコードを含む第１のテーブル及び前記組織における下位の各構成者に対応する情報をそれぞれ格納するレコードを含む第２のテーブルであって、各レコードが、前記複数の構成者を一意に特定する第１の識別子を格納する第１のフィールドと、前記複数の構成者の前記第１又は第２のテーブル内における序列を表す第２の識別子であって、前記第１又は第２のテーブル内の任意の者の前記第２の識別子の末尾に所定の長さの値を少なくとも１回付加したものを前記第１又は第２のテーブル内の任意の者の配下の者に相当する前記第２の識別子とした前記第２の識別子を格納する第２のフィールドと、前記複数の構成者の関連を表す第３の識別子を格納する第３のフィールドとを有する前記第１及び第２のテーブルを記録する第１及び第２の記録手段と、
申請に関する第３のテーブルであって、前記複数の構成者の中の申請を行った者を一意に特定する前記第１の識別子を格納するフィールドを少なくとも有する前記第３のテーブルを記録する第３の記録手段と、
前記第３のテーブルの処理対象のレコード内の前記第１の識別子に基づいて前記第２のテーブルを検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請を行った者の前記第２の識別子を抽出し、抽出された前記第２の識別子の末尾から前記所定の長さの値を少なくとも１回削除することにより得られた少なくとも１つの値を前記第２の識別子として格納している少なくとも１つの上位レコードを前記第２のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも１人の者を特定する第１の処理手段と、
前記第２のテーブル内に承認権限を有する者が存在しない場合に、前記第２のテーブル内の前記申請を行った者に対応するレコード内又は前記上位レコード内の前記第３の識別子を抽出し、抽出された前記第３の識別子を前記第３の識別子として格納している少なくとも１つのレコードを前記第１のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも１人の者を特定する第２の処理手段とを具備する。

ここで、前記第１の処理手段は、前記申請を行った者の前記第２の識別子の末尾から所定の長さの値を削除することにより得られた値を前記第２の識別子として格納しているレコードが、前記第２のテーブルに複数存在する場合に、当該複数存在するレコードのうち前記第３の識別子が前記申請を行った者の前記第３の識別子と一致するレコードを前記第２のテーブルから検索することにより、承認権限を有する者を特定することが望ましい。

また、本発明に係る業務管理方法は、上記業務管理装置の各部にて実行される処理と同様の処理手順を備えた方法であり、本発明に係る業務管理プログラムは、上記業務管理装置の各部にて実行される処理と同様の処理手順をコンピュータに実行させるプログラムである。

上記構成によれば、組織の上位階層を改編した場合であっても、柔軟に対応することができる。

＜１．業務管理装置の構成＞
以下、図面に基づいて本発明の実施の形態について説明する。
図１は、本発明の第一の実施形態に係る業務管理装置を用いたシステムを示す図である。本実施形態は、本発明を企業における申請及び承認業務を管理するシステムに適用したものである。図１に示すように、システム１０は、本発明の一実施形態としてのサーバ１と、クライアント端末１１〜１ｎとを具備しており、これらは、ネットワークを介して相互に接続されている。
図２は、図１のサーバ１の構成を示す図である。図２に示すように、サーバ１は、申請テーブル記録部２１と、従業員テーブル記録部２２と、承認者テーブル記録部２３と、組織テーブル記録部２４と、役職テーブル記録部２５と、申請データ作成処理部２６と、承認ルート決定処理部２７と、承認・却下処理部２８と、承認ルート作成・更新処理部２９とを具備する。

＜１−１．申請テーブル＞
図３は、申請テーブル記録部２１に記録される申請テーブル（第３のテーブル。第１及び第２のテーブルについては後述。）の一例を示す図である。図３に示すように、申請テーブルは、申請の内容に関する情報及び承認状況に関する情報を格納するフィールドを有する。申請の内容に関する情報は、伝票名（例えば、休暇届、直行届等）、実施日（例えば、休暇日、直行日等）、申請者を一意に特定するユーザＩＤ（第１の識別子）を含む。また、承認状況に関する情報は、第１承認（例えば、課長承認等）、第２承認（例えば、部長承認等）、…と、全ての承認が完了したか否かを示す完了フラグとを含む。図３に示す申請テーブル内のレコードは、ユーザＩＤが「Ｔａｋａｄａ」である従業員が２００３年５月１日に休暇を取得するための申請に係るレコードであり、この申請は未だ承認を受けていないことを表している。

＜１−２．従業員テーブル＞
再び図２を参照すると、従業員テーブル記録部２２は、従業員（組織の構成者）に関するデータを格納する従業員テーブルを記録する。
図４は、従業員テーブルの一例を示す図である。図４に示すように、従業員テーブルは、従業員を一意に特定するユーザＩＤ、従業員を一意に特定する従業員番号、及び、従業員の氏名を格納するフィールドを有している。

＜１−３．承認者テーブル＞
再び図２を参照すると、承認者テーブル記録部２３は、承認権限を有する者に関するデータを格納する承認者テーブルを記録する。
図５は、承認者テーブルの一例を示す図である。図５に示すように、承認者テーブルは、承認権限を有する者に相当するノードの名称、承認権限を有する者に相当するノードを一意に特定するユーザＩＤ、及び、承認権限を有する者としての従業員のユーザＩＤを格納するフィールドを有している。なお、図５に示す承認者テーブルにおいて、「完了箱」という名称を有するノードは、承認が完了した申請データを管理又は処理する権限を有する者（例えば、企業等の総務課長、総務部長、人事課長、人事部長等）に相当する。本実施形態においては、具体的には、承認が完了した申請データを管理又は処理する権限を有する者は、ユーザＩＤが「Ｔａｒｏ」である従業員（ここでは、氏名「総務 太郎」（図４参照））と、ユーザＩＤが「Ｊｉｒｏ」である従業員（ここでは、氏名「総務 次郎」（図４参照））である。

＜１−４．組織テーブル＞
再び図２を参照すると、組織テーブル記録部２４は、組織に関するデータを格納する組織テーブルを記録する。
図６は、上位の組織テーブル（第１のテーブル）の一例を示す図であり、図７は、下位の組織テーブル（第２のテーブル）の一例を示す図である。上位の組織テーブルには組織における上位のノード又は従業員のデータが格納され、下位の組織テーブルには上位の組織テーブルにデータの格納されていない下位のノード又は従業員のデータが格納されている。図６及び図７に示すように、各組織テーブルは、レコード番号（Ｎｏ．）、改定日、ユーザＩＤ（第１の識別子）、当該レコードの組織上における区分である組織区分、組織所属名、氏名、組織序列番号（第２の識別子）及びリンクＧＵＩＤ（Globally Unique Identifier；第３の識別子）を格納するフィールドを有している。

図６及び図７に示す組織テーブルにおいて、改定日とは、当該レコードに格納されているデータが有効となった日又は有効となる日を表す。
組織区分は、１〜３までの値を取り得る。ここで、組織区分「１」は、当該レコードが部署に相当するノードに関するレコードであることを表す。また、組織区分「２」は、当該レコードが承認権限を有する者に相当するノードに関するレコードであることを表し、組織区分「３」は、当該レコードが従業員に関するレコードであることを表す。

組織序列番号は、部署に相当するノード、承認権限を有する者に相当するノード、又は、従業員（以下、「従業員等」という）の組織上における序列（位置付け）を表す番号である。本実施形態においては、組織序列番号は、４ｎ（ｎは、自然数）桁の数であり、或る従業員等の組織序列番号は、当該従業員等の直近上位の従業員等の組織序列番号の末尾に４桁の数を付加した番号となっている。
例えば、図６に示す組織テーブルにおいて、第１レコード（組織所属名「東京本社」）には、組織序列番号「０００１」が格納されており、第１レコードによって表されるノードの下位に位置するノードとしての第２レコード（組織所属名「東京本社」、氏名「完了箱」）には、第１レコード内の組織序列番号「０００１」の末尾に「０００１」を付加した組織序列番号「０００１０００１」が格納されている。
また、例えば、従業員「武田 秀雄」（第６レコードに相当）の直近上位の従業員等は、第６レコード内の組織序列番号
「０００１０００１０００１０００２０００１」
の末尾４桁を削除した値
「０００１０００１０００１０００２」
を組織序列番号として格納しているレコード（ここでは、第５レコード）によって表される従業員等（ここでは、承認権限を有する者に相当するノード「営業部承認者」）となる。

組織序列番号は、直近上位の従業員等の組織序列番号の末尾に４桁の数を付加して生成されているが、これには例外がある。例外となるのは、下位の組織テーブルにレコードが記録されている従業員等（例えば第１０レコード、第１５レコード）の直近上位の従業員等のレコード（第９レコード）が上位の組織テーブルに記録されている場合である。この場合、当該下位の組織テーブルにレコードが記録されている従業員等の組織序列番号は、直近上位の従業員等の組織序列番号を先頭に含まない、新たな４桁の数（例えば第１０レコードの「０００１」、第１５レコードの「０００２」など）として生成されている。

リンクＧＵＩＤは、サーバ１内においてユニークに生成される識別子であり、上位及び下位の組織テーブルの各レコード間の関連を表している。
例えば、図６に示す上位の組織テーブルにおいて、第９レコードには、当該上位の組織テーブルにおける唯一のリンクＧＵＩＤ
「７０５８ａ６ｆｄ−ｃ８ｅ０−４ａ４５−ｂｂｆ５−００３６ｃ２ｄ１４ｃｅ７」
が格納されている。このリンクＧＵＩＤは、第９レコードに相当する従業員等の配下の従業員等を示す第１０レコード〜第１５レコード（図７に示す下位の組織テーブル）に付与された共通のリンクＧＵＩＤと共通である。
また例えば、図６に示す上位の組織テーブルにおいて、第１８レコードには、当該上位の組織テーブルにおける唯一のリンクＧＵＩＤ
「８０５８ａ６ｆｄ−ｃ８ｅ０−４ａ４６−ｃｂｆ５−００３６ｃ２ｄ１４ｃｅ８」
が格納されている。このリンクＧＵＩＤは、第１８レコードに相当する従業員等の配下の従業員等を示す第１９レコード〜第２４レコード（図７に示す下位の組織テーブル）に付与された共通のリンクＧＵＩＤと共通である。

ここで例えば、従業員「森 祐司」（第１１レコードに相当）の直近上位の従業員等を探す場合、第１１レコード内の組織序列番号
「０００１０００１」
の末尾４桁を削除した値
「０００１」
を組織序列番号として格納しているレコードは、下位の組織テーブル内に複数（第１０レコードと第１９レコード）存在する。この場合は第１１レコード内のリンクＧＵＩＤを参照し、これと同一のリンクＧＵＩＤを有する上位レコード（ここでは、第１０レコード）によって表される従業員等（ここでは、部署に相当するノード「営業部１課１Ｇ」）が、第１１レコードの直近上位の従業員等となる。

次に部署に相当するノード「営業部１課１Ｇ」（第１０レコードに相当）の直近上位の従業員等を探す場合、第１０レコード内の組織序列番号
「０００１」
の末尾４桁を削除するとすべての桁がなくなってしまう。この場合は第１０レコード内のリンクＧＵＩＤを参照し、これと同一のリンクＧＵＩＤを有するレコードを上位の組織テーブルから探す。ここでは、第１０レコード内のリンクＧＵＩＤと同一のリンクＧＵＩＤが、上位の組織テーブルの第９レコードに存在するので、第９レコードによって表される従業員等（ここでは、承認権限を有する者に相当するノード「営業部１課承認者」）が、第１０レコードの直近上位の従業員等となる。

なお、サーバ１内においてユニークに生成される識別子であれば、ＧＵＩＤに代えてＵＵＩＤ（Universally Unique IDentifier）など他の識別子を用いても良い。

＜１−５．役職テーブル＞
再び図２を参照すると、役職テーブル記録部２５は、従業員の役職に関するデータを格納する役職テーブルを記録する。
図８は、役職テーブルの一例を示す図である。図８に示すように、役職テーブルは、ユーザＩＤ、当該レコードが有効となった日又は有効となる日を表す改定日、及び、役職を格納するフィールドを有している。図８においては、例えば、ユーザＩＤが「Ｔａｒｏ」である従業員（本実施形態においては、氏名「総務 太郎」（図４参照））は、１９８３年４月１日に一般従業員となり、１９９３年４月１日に総務課長となり、１９９８年４月１日に総務部長となったことを表している。

＜１−６．各種処理部＞
再び図２を参照すると、申請データ作成処理部２６は、クライアント端末１１〜１ｎを使用する従業員からの要求に応じて、申請データを作成し、申請テーブル記録部２１に記録させる。
承認ルート決定処理部２７は、申請テーブル記録部２１に記録されている申請テーブル内の申請データに係る申請を承認すべき従業員を決定する処理を行う。

承認・却下処理部２８は、承認ルート決定処理部２７によって決定された従業員からの指示に応じて承認又は却下処理を行う。
承認ルート作成・更新処理部２９は、承認者テーブル又は組織テーブルの作成又は更新処理を行う。

図２に示す申請データ作成処理部２６、承認ルート決定処理部２７、承認・却下処理部２８、及び、承認ルート作成・更新処理部２９は、ＣＰＵとソフトウェア（プログラム）で構成することができる。このプログラムと、申請テーブル、従業員テーブル、承認者テーブル、組織テーブル、及び、役職テーブルは、ハードディスク、フレキシブルディスク、ＭＯ、ＭＴ、ＲＡＭ、ＣＤ−ＲＯＭ、又は、ＤＶＤ−ＲＯＭ等の記録媒体に記録することができる。

＜２．申請データ作成処理＞
図９は、サーバ１の申請データ作成処理の概要を示すフローチャートである。以下、サーバ１の申請データ作成処理について、図９を参照しながら説明する。ここでは、従業員「高田 由美子」が、休暇届に係る申請データを作成するものとする。
まず、クライアント端末（ここでは、クライアント端末１１とする）を使用している従業員（ここでは、「高田 由美子」）が、申請の内容に関する情報（ここでは、伝票名「休暇届」及び休暇を取得することを所望する日「２００３／０５／０１」）を入力し、サーバ１の申請データ作成処理部２６が、この条件を受信する（ステップＳ１０１）。

次に、申請データ作成処理部２６は、伝票名「休暇届」、実施日「２００３／０５／０１」、ユーザＩＤ「Ｔａｋａｄａ」を有する申請データを作成し（図３参照）、申請テーブル記録部２１に記録させる（ステップＳ１０２）。

＜３．承認・却下処理＞
図１０は、サーバ１の承認・却下処理の概要を示すフローチャートである。以下、サーバ１の承認・却下処理について、図１０を参照しながら説明する。

＜３−１．Ｓ２０１＞
まず、承認ルート決定処理部２７が、申請テーブル記録部２１に記録されている申請テーブル内の処理対象のレコード（図３参照）内のユーザＩＤ（ここでは、「Ｔａｋａｄａ」）を抽出する（ステップＳ２０１）。

＜３−２．Ｓ２０２＞
次に、承認ルート決定処理部２７は、組織テーブル記録部２４に記録されている組織テーブル（図６及び図７参照）の中から、ステップＳ２０１にて抽出されたユーザＩＤ（ここでは、「Ｔａｋａｄａ」）を格納しているレコード（ここでは、図７の第１４レコード）を検索し、当該レコード内の組織序列番号、ここでは、
「０００１０００２０００２」
を抽出する（ステップＳ２０２）。なお、このとき、ステップＳ２０１にて抽出されたユーザＩＤを格納しているレコードが複数存在している場合には、システム日付において有効なレコードを選択する。

＜３−３．Ｓ２０３＞
そして、承認ルート決定処理部２７は、ステップＳ２０２にて抽出された組織序列番号、ここでは、
「０００１０００２０００２」
の末尾から所定の長さの値を少なくとも１回削除した値（末尾４桁を削除した値）、ここでは、
「０００１０００２」
を算出する（ステップＳ２０３）。
なお、組織序列番号の末尾から所定の長さの値を削除した値をステップＳ２０３で算出する代わりに、予め組織序列番号の末尾から所定の長さの値を削除した値を算出しておき、この値を組織テーブル内の別のフィールドに格納しておいたものを、ステップＳ２０３で単に読み出すこととしても良い。

＜３−４．Ｓ２０４＞
次に、承認ルート決定処理部２７は、ステップＳ２０２で該当レコードが検索された組織テーブル（ここでは図７に示す下位の組織テーブル）の中に、ステップＳ２０３にて算出された値、ここでは、
「０００１０００２」
を組織序列番号として格納しているレコードがあるか否かを判定する（ステップＳ２０４）。

＜３−５．Ｓ２０５＞
下位の組織テーブルには、
「０００１０００２」
を組織序列番号として格納しているレコードとして第１２レコードと第２１レコードが存在する（ステップＳ２０４：Ｙ）。そこで、第１４レコード内のリンクＧＵＩＤを参照し、これと同一のリンクＧＵＩＤを有するレコード（ここでは、第１２レコード）を特定する（ステップＳ２０５）。なお、このとき、ステップＳ２０３にて算出された値を組織序列番号として格納しており、且つ同一のリンクＧＵＩＤを有するレコードが複数存在している場合には、システム日付において有効なレコードを選択する。

＜３−６．Ｓ２０６、Ｓ２０７＞
次に、ステップＳ２０５にて特定されたレコード内のユーザＩＤが０であるか否かを判定する（ステップＳ２０６）。ここで、特定された第１２レコード内のユーザＩＤ（ここでは、「Ｅｉｇｙｏ＿Ｂ＿１Ｋ＿１Ｇ」）は０ではないので（ステップＳ２０６：Ｎ）、承認ルート決定処理部２７は、特定されたレコード内のユーザＩＤ（ここでは、「Ｅｉｇｙｏ＿Ｂ＿１Ｋ＿１Ｇ」）を「承認権限を有する者に相当するノードのユーザＩＤ」として格納しているレコードを、承認者テーブル記録部２３に記録されている承認者テーブル（図５参照）の中から検索し（ここでは、第５レコードがヒットする）、当該レコードに格納されている「承認権限を有する者としての従業員のユーザＩＤ」（ここでは、「Ｍｏｒｉ」）を抽出する（ステップＳ２０７）。なお、このとき、ステップＳ２０４にて抽出されたユーザＩＤを格納しているレコードが複数存在している場合には、システム日付において有効なレコードを選択する。これにより、申請データ（図３参照）に対する承認又は却下処理を最初に行うべき従業員（ここでは、ユーザＩＤ「Ｍｏｒｉ」、氏名「森 祐司」である従業員）を決定することができる。承認ルート決定処理部２７は、このユーザＩＤを承認・却下処理部２８に出力する。

＜３−７．Ｓ２０８、Ｓ２０９＞
次に、承認・却下処理部２８は、ステップＳ２０５にて抽出されたユーザＩＤ（ここでは、「Ｍｏｒｉ」）を有する従業員（ここでは、「森 祐司」）が使用するクライアント端末（ここでは、クライアント端末１２とする）に、申請データの内容を表示させる（ステップＳ２０８）。
そして、承認・却下処理部２８は、ステップＳ２０５にて抽出されたユーザＩＤを有する従業員（ここでは、「森 祐司」）からの指示に応じて（ここでは、従業員「森 祐司」は、承認する旨の指示を入力するものとする）、申請データ内の複数の承認欄の中の１つの承認欄（ここでは、第１承認欄）の値を書き換える（ステップＳ２０９）。
図１１は、書き換え後の申請データを表す図である。

＜３−８．Ｓ２１０、Ｓ２１１＞
次に、承認ルート決定処理部２７は、全ての承認が完了しているか否かをチェックし、全ての承認が完了していると判断した場合には処理を終了し、そうでない場合には、処理をステップＳ２０３に戻す（ステップＳ２１０）。
例えば、図３の申請データが上司２名の承認を必要としている場合、従業員「森 祐司」の承認のみでは全ての承認が完了していないので、組織序列番号を更に４桁削除して（ステップＳ２０３）、
「０００１」
を得る。そして、この「０００１」を組織序列番号として格納しているレコードを探し（ステップＳ２０４）、同一のリンクＧＵＩＤを有する上位レコード（ここでは、第１０レコード）を特定する（ステップＳ２０５）。
このとき、特定された第１０レコード内のユーザＩＤが０である（部署に相当するノードである）ので（ステップＳ２０６：Ｙ）、処理をステップＳ２０３に戻し、組織序列番号を更に４桁削除する。すると、組織序列番号のすべての桁がなくなるので、該当するレコードを探しても見つからない（ステップＳ２０４：Ｎ）。そこで、第１０レコード内のリンクＧＵＩＤを参照し、これと同一のリンクＧＵＩＤを有するレコード（ここでは、第９レコード）を上位の組織テーブルの中から特定する（ステップＳ２１１）。
これにより、特定されたレコード内のユーザＩＤ（ここでは、「Ｅｉｇｙｏ＿Ｂ＿１Ｋ」）を「承認権限を有する者に相当するノードのユーザＩＤ」として格納しているレコードを、承認者テーブル（図５参照）の中から検索し（ここでは、第４レコードがヒットする）、当該レコードに格納されている「承認権限を有する者としての従業員のユーザＩＤ」（ここでは、「Ｍｉｚｕｔａｎｉ」）を抽出することができる（ステップＳ２０７）。

本実施形態では、上位の組織テーブルの組織序列番号を先頭に含まない組織序列番号が下位の組織テーブルで付与されている。従って、組織改編、人事異動などに応じて、下位の組織テーブルの組織序列番号に影響を与えることなく上位の組織テーブルの組織序列番号を変更することができる。更に、上位の組織テーブルを例えば人事部員が更新する作業と、下位の組織テーブルを例えば営業部の管理者が更新する作業を同時に実行することができるので、承認ルートの設定権限を人事部等から営業部等の各部門に委譲することが容易となる。また、多数の階層からなる組織においても、組織テーブルの組織序列番号を小さな桁数に抑えることができる。

また本実施形態によれば、上位の組織テーブルにおいてリンクＧＵＩＤを付与された特定のレコードの配下の従業員等には、すべて共通のリンクＧＵＩＤが下位の組織テーブルにおいて付与されている。従って、上位の組織テーブルにおいてリンクＧＵＩＤを付与された別々のレコードの配下の従業員等を、下位の組織テーブルとして１つのテーブルにまとめた場合でも、ステップＳ２０５の処理により下位の組織テーブル内で承認権限を有する従業員等を一意に特定することができる。
なお、上位の組織テーブルにおいてリンクＧＵＩＤを付与された別々のレコードの配下の従業員等を、下位の組織テーブルとして別々のテーブルに分けて格納した場合には、ステップＳ２０５の処理において同一のリンクＧＵＩＤを探すまでもなく、各々の下位の組織テーブル内で承認権限を有する従業員等を一意に特定することができる。この場合、下位の組織テーブルにおいては、組織序列番号として削除演算の最小単位（ここでは４桁）の値しかもっていないレコード（ここでは、第１０レコード、第１５レコード、第１９レコード、第２４レコード）にだけリンクＧＵＩＤを付与すればよく、それ以外のレコードにはリンクＧＵＩＤを付与する必要はない。

＜４．承認ルート作成・更新処理＞
図１２は、サーバ１の承認ルート作成・更新処理の概要を示すフローチャートである。以下、サーバ１の承認ルート作成・更新処理について、図１２を参照しながら説明する。
承認ルート作成・更新処理部２９は、クライアント端末（ここでは、クライアント端末１３とする）を使用している従業員から、承認権限を有する者としての従業員の追加、削除、又は、変更を行うためのデータを受け取り、承認者テーブル記録部２３に記録されている承認者テーブル又は組織テーブル記録部２４に記録されている組織テーブルの作成又は更新を行う（ステップＳ３０１）。

＜５．第二の実施形態＞
図１３及び図１４は、本発明の第二の実施形態に係る業務管理装置における組織テーブルの一例を示す図である。「改定日」と「ユーザＩＤ」の欄は第一の実施形態における図６及び図７と同様であるので、第二の実施形態では図示を省略している。本実施形態の組織テーブルには、第３の識別子として「リンク先ＧＵＩＤ」と「リンク元ＧＵＩＤ」を記録するフィールドが設けられている。更に、図１４に示すように、下位の組織テーブルより更に下位の組織テーブルを有している。上記「更に下位の組織テーブル」では、上記「下位の組織テーブル」で付与された組織序列番号を先頭に含まない組織序列番号が付与されている。

上記「更に下位の組織テーブル」には、共通のリンク元ＧＵＩＤ
「９０５８ａ６ｆｄ−ｃ８ｅ０−４ａ４７−ｄｂｆ５−００３６ｃ２ｄ１４ｃｅ９」
が格納されている。そして、このリンク元ＧＵＩＤと同じ値が、上記「下位の組織テーブル」の第１２レコードに、リンク先ＧＵＩＤとして格納されている。
同様に、上記「下位の組織テーブル」には、共通のリンク元ＧＵＩＤ
「７０５８ａ６ｆｄ−ｃ８ｅ０−４ａ４５−ｂｂｆ５−００３６ｃ２ｄ１４ｃｅ７」
が格納されている。そして、このリンク元ＧＵＩＤと同じ値が、図１３に示す「上位の組織テーブル」の第９レコードに、リンク先ＧＵＩＤとして格納されている。

本実施形態においては、例えば従業員「田中 四郎」（上記「更に下位の組織テーブル」の第２５レコードに相当）の申請に対する承認権限を有する従業員等は、第２５レコードの組織序列番号
「０００１０００１」
の末尾４桁を削除（Ｓ２０３）した
「０００１」
を組織序列番号として有する上位レコード（第２４レコード）からリンク元ＧＵＩＤ
「９０５８ａ６ｆｄ−ｃ８ｅ０−４ａ４７−ｄｂｆ５−００３６ｃ２ｄ１４ｃｅ９」
を抽出し、このリンク元ＧＵＩＤと同一のリンク先ＧＵＩＤを有するレコード（上記「下位の組織テーブル」の第１２レコード）を特定する（Ｓ２１１）ことにより、特定される。

特定された上記「下位の組織テーブル」の第１２レコードは、更に上位の承認権限を判定するためにリンク元ＧＵＩＤ
「７０５８ａ６ｆｄ−ｃ８ｅ０−４ａ４５−ｂｂｆ５−００３６ｃ２ｄ１４ｃｅ７」
を必要とする場合が考えられる。本実施形態において「リンク先ＧＵＩＤ」と「リンク元ＧＵＩＤ」を記録するフィールドを別々に設けたのはこのためである。

本実施形態は、以上述べた点以外は、第一の実施形態と同様であるので説明を省略する。
本実施形態のシステム設計時には組織序列番号の最大桁数を決める必要があるが、本実施形態では、下位の組織テーブルより更に下位の組織テーブルを設けることができるので、組織序列番号の最大桁数の制約を受けることなく組織の階層数を設定したり後日変更したりすることができる。

本発明の第一の実施形態に係る業務管理装置を用いたシステムの構成を示す図である。 図１のサーバ１の構成を示す図である。 図２の申請テーブル記録部２１に記録される申請テーブル（第３のテーブル）の一例を示す図である。 図２の従業員テーブル記録部２２に記録される従業員テーブルの一例を示す図である。 図２の承認者テーブル記録部２３に記録される承認者テーブルの一例を示す図である。 図２の組織テーブル記録部２４に記録される組織テーブルのうち上位の組織テーブル（第１のテーブル）の一例を示す図である。 図２の組織テーブル記録部２４に記録される組織テーブルのうち下位の組織テーブル（第２のテーブル）の一例を示す図である。 図２の役職テーブル記録部２５に記録される役職テーブルの一例を示す図である。 図１のサーバ１の申請データ作成処理を示すフローチャートである。 図１のサーバ１の承認・却下処理を示すフローチャートである。 図２の申請テーブル記録部２１に記録される申請テーブル（書き換え後）の一例を示す図である。 図１のサーバ１の承認ルート作成・更新処理を示すフローチャートである。 本発明の第二の実施形態に係る業務管理装置における上位の組織テーブル（第１のテーブル）の一例を示す図である。 本発明の第二の実施形態に係る業務管理装置における下位の組織テーブル（第２のテーブル）の一例を示す図である。

符号の説明

１ サーバ
１０ システム
１１〜１ｎ クライアント端末
２１ 申請テーブル記録部
２２ 従業員テーブル記録部
２３ 承認者テーブル記録部
２４ 組織テーブル記録部
２５ 役職テーブル記録部
２６ 申請データ作成処理部
２７ 承認ルート決定処理部
２８ 承認・却下処理部
２９ 承認ルート作成・更新処理部

Claims (4)

1. 組織における申請及び承認に関する業務の管理を行うための装置であって、
   複数の構成者により構成される組織における上位の各構成者に対応する情報をそれぞれ格納するレコードを含む第１のテーブル及び前記組織における下位の各構成者に対応する情報をそれぞれ格納するレコードを含む第２のテーブルであって、各レコードが、前記複数の構成者を一意に特定する第１の識別子を格納する第１のフィールドと、前記複数の構成者の前記第１又は第２のテーブル内における序列を表す第２の識別子であって、前記第１又は第２のテーブル内の任意の者の前記第２の識別子の末尾に所定の長さの値を少なくとも１回付加したものを前記第１又は第２のテーブル内の任意の者の配下の者に相当する前記第２の識別子とした前記第２の識別子を格納する第２のフィールドと、前記複数の構成者の関連を表す第３の識別子を格納する第３のフィールドとを有する前記第１及び第２のテーブルを記録する第１及び第２の記録手段と、
   申請に関する第３のテーブルであって、前記複数の構成者の中の申請を行った者を一意に特定する前記第１の識別子を格納するフィールドを少なくとも有する前記第３のテーブルを記録する第３の記録手段と、
   前記第３のテーブルの処理対象のレコード内の前記第１の識別子に基づいて前記第２のテーブルを検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請を行った者の前記第２の識別子を抽出し、抽出された前記第２の識別子の末尾から前記所定の長さの値を少なくとも１回削除することにより得られた少なくとも１つの値を前記第２の識別子として格納している少なくとも１つの上位レコードを前記第２のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも１人の者を特定する第１の処理手段と、
   前記第２のテーブル内に承認権限を有する者が存在しない場合に、前記第２のテーブル内の前記申請を行った者に対応するレコード内又は前記上位レコード内の前記第３の識別子を抽出し、抽出された前記第３の識別子を前記第３の識別子として格納している少なくとも１つのレコードを前記第１のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも１人の者を特定する第２の処理手段と、
   を具備する業務管理装置。
2. 前記第１の処理手段は、前記申請を行った者の前記第２の識別子の末尾から所定の長さの値を削除することにより得られた値を前記第２の識別子として格納しているレコードが、前記第２のテーブルに複数存在する場合に、当該複数存在するレコードのうち前記第３の識別子が前記申請を行った者の前記第３の識別子と一致するレコードを前記第２のテーブルから検索することにより、承認権限を有する者を特定する、請求項１記載の業務管理装置。
3. 組織における申請及び承認に関する業務の管理を行うための方法であって、
   複数の構成者により構成される組織における上位の各構成者に対応する情報をそれぞれ格納するレコードを含む第１のテーブル及び前記組織における下位の各構成者に対応する情報をそれぞれ格納するレコードを含む第２のテーブルであって、各レコードが、前記複数の構成者を一意に特定する第１の識別子を格納する第１のフィールドと、前記複数の構成者の前記第１又は第２のテーブル内における序列を表す第２の識別子であって、前記第１又は第２のテーブル内の任意の者の前記第２の識別子の末尾に所定の長さの値を少なくとも１回付加したものを前記第１又は第２のテーブル内の任意の者の配下の者に相当する前記第２の識別子とした前記第２の識別子を格納する第２のフィールドと、前記複数の構成者の関連を表す第３の識別子を格納する第３のフィールドとを有する前記第１及び第２のテーブルを記録するステップ（ａ）と、
   申請に関する第３のテーブルであって、前記複数の構成者の中の申請を行った者を一意に特定する前記第１の識別子を格納するフィールドを少なくとも有する前記第３のテーブルを記録するステップ（ｂ）と、
   前記第３のテーブルの処理対象のレコード内の前記第１の識別子に基づいて前記第２のテーブルを検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請を行った者の前記第２の識別子を抽出するステップ（ｃ）と、
   ステップ（ｃ）にて抽出された前記第２の識別子の末尾から前記所定の長さの値を少なくとも１回削除することにより得られた少なくとも１つの値を前記第２の識別子として格納している少なくとも１つの上位レコードを前記第２のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも１人の者を特定するステップ（ｄ）と、
   前記第２のテーブル内に承認権限を有する者が存在しない場合に、前記第２のテーブル内の前記申請を行った者に対応するレコード内又は前記上位レコード内の前記第３の識別子を抽出し、抽出された前記第３の識別子を前記第３の識別子として格納している少なくとも１つのレコードを前記第１のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも１人の者を特定するステップ（ｅ）と、
   をコンピュータに実行させる業務管理方法。
4. 組織における申請及び承認に関する業務の管理を行うためのプログラムであって、
   複数の構成者により構成される組織における上位の各構成者に対応する情報をそれぞれ格納するレコードを含む第１のテーブル及び前記組織における下位の各構成者に対応する情報をそれぞれ格納するレコードを含む第２のテーブルであって、各レコードが、前記複数の構成者を一意に特定する第１の識別子を格納する第１のフィールドと、前記複数の構成者の前記第１又は第２のテーブル内における序列を表す第２の識別子であって、前記第１又は第２のテーブル内の任意の者の前記第２の識別子の末尾に所定の長さの値を少なくとも１回付加したものを前記第１又は第２のテーブル内の任意の者の配下の者に相当する前記第２の識別子とした前記第２の識別子を格納する第２のフィールドと、前記複数の構成者の関連を表す第３の識別子を格納する第３のフィールドとを有する前記第１及び第２のテーブルを記録する手順（ａ）と、
   申請に関する第３のテーブルであって、前記複数の構成者の中の申請を行った者を一意に特定する前記第１の識別子を格納するフィールドを少なくとも有する前記第３のテーブルを記録する手順（ｂ）と、
   前記第３のテーブルの処理対象のレコード内の前記第１の識別子に基づいて前記第２のテーブルを検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請を行った者の前記第２の識別子を抽出する手順（ｃ）と、
   手順（ｃ）にて抽出された前記第２の識別子の末尾から前記所定の長さの値を少なくとも１回削除することにより得られた少なくとも１つの値を前記第２の識別子として格納している少なくとも１つの上位レコードを前記第２のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも１人の者を特定する手順（ｄ）と、
   前記第２のテーブル内に承認権限を有する者が存在しない場合に、前記第２のテーブル内の前記申請を行った者に対応するレコード内又は前記上位レコード内の前記第３の識別子を抽出し、抽出された前記第３の識別子を前記第３の識別子として格納している少なくとも１つのレコードを前記第１のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも１人の者を特定する手順（ｅ）と、
   をコンピュータに実行させるための業務管理プログラム。

Images