JP5232608B2 - 業務管理装置及び方法並びに業務管理プログラム - Google Patents
業務管理装置及び方法並びに業務管理プログラム Download PDFInfo
- Publication number
- JP5232608B2 JP5232608B2 JP2008296948A JP2008296948A JP5232608B2 JP 5232608 B2 JP5232608 B2 JP 5232608B2 JP 2008296948 A JP2008296948 A JP 2008296948A JP 2008296948 A JP2008296948 A JP 2008296948A JP 5232608 B2 JP5232608 B2 JP 5232608B2
- Authority
- JP
- Japan
- Prior art keywords
- identifier
- record
- person
- application
- organization
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
しかしながら、従来の業務管理装置においては、人事異動、組織変更等により承認権限を有する者の変更が生じた場合に、柔軟に対応することができなかった。
複数の構成者により構成される組織における上位の各構成者に対応する情報をそれぞれ格納するレコードを含む第1のテーブル及び前記組織における下位の各構成者に対応する情報をそれぞれ格納するレコードを含む第2のテーブルであって、各レコードが、前記複数の構成者を一意に特定する第1の識別子を格納する第1のフィールドと、前記複数の構成者の前記第1又は第2のテーブル内における序列を表す第2の識別子であって、前記第1又は第2のテーブル内の任意の者の前記第2の識別子の末尾に所定の長さの値を少なくとも1回付加したものを前記第1又は第2のテーブル内の任意の者の配下の者に相当する前記第2の識別子とした前記第2の識別子を格納する第2のフィールドと、前記複数の構成者の関連を表す第3の識別子を格納する第3のフィールドとを有する前記第1及び第2のテーブルを記録する第1及び第2の記録手段と、
申請に関する第3のテーブルであって、前記複数の構成者の中の申請を行った者を一意に特定する前記第1の識別子を格納するフィールドを少なくとも有する前記第3のテーブルを記録する第3の記録手段と、
前記第3のテーブルの処理対象のレコード内の前記第1の識別子に基づいて前記第2のテーブルを検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請を行った者の前記第2の識別子を抽出し、抽出された前記第2の識別子の末尾から前記所定の長さの値を少なくとも1回削除することにより得られた少なくとも1つの値を前記第2の識別子として格納している少なくとも1つの上位レコードを前記第2のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも1人の者を特定する第1の処理手段と、
前記第2のテーブル内に承認権限を有する者が存在しない場合に、前記第2のテーブル内の前記申請を行った者に対応するレコード内又は前記上位レコード内の前記第3の識別子を抽出し、抽出された前記第3の識別子を前記第3の識別子として格納している少なくとも1つのレコードを前記第1のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも1人の者を特定する第2の処理手段とを具備する。
以下、図面に基づいて本発明の実施の形態について説明する。
図1は、本発明の第一の実施形態に係る業務管理装置を用いたシステムを示す図である。本実施形態は、本発明を企業における申請及び承認業務を管理するシステムに適用したものである。図1に示すように、システム10は、本発明の一実施形態としてのサーバ1と、クライアント端末11〜1nとを具備しており、これらは、ネットワークを介して相互に接続されている。
図2は、図1のサーバ1の構成を示す図である。図2に示すように、サーバ1は、申請テーブル記録部21と、従業員テーブル記録部22と、承認者テーブル記録部23と、組織テーブル記録部24と、役職テーブル記録部25と、申請データ作成処理部26と、承認ルート決定処理部27と、承認・却下処理部28と、承認ルート作成・更新処理部29とを具備する。
図3は、申請テーブル記録部21に記録される申請テーブル(第3のテーブル。第1及び第2のテーブルについては後述。)の一例を示す図である。図3に示すように、申請テーブルは、申請の内容に関する情報及び承認状況に関する情報を格納するフィールドを有する。申請の内容に関する情報は、伝票名(例えば、休暇届、直行届等)、実施日(例えば、休暇日、直行日等)、申請者を一意に特定するユーザID(第1の識別子)を含む。また、承認状況に関する情報は、第1承認(例えば、課長承認等)、第2承認(例えば、部長承認等)、…と、全ての承認が完了したか否かを示す完了フラグとを含む。図3に示す申請テーブル内のレコードは、ユーザIDが「Takada」である従業員が2003年5月1日に休暇を取得するための申請に係るレコードであり、この申請は未だ承認を受けていないことを表している。
再び図2を参照すると、従業員テーブル記録部22は、従業員(組織の構成者)に関するデータを格納する従業員テーブルを記録する。
図4は、従業員テーブルの一例を示す図である。図4に示すように、従業員テーブルは、従業員を一意に特定するユーザID、従業員を一意に特定する従業員番号、及び、従業員の氏名を格納するフィールドを有している。
再び図2を参照すると、承認者テーブル記録部23は、承認権限を有する者に関するデータを格納する承認者テーブルを記録する。
図5は、承認者テーブルの一例を示す図である。図5に示すように、承認者テーブルは、承認権限を有する者に相当するノードの名称、承認権限を有する者に相当するノードを一意に特定するユーザID、及び、承認権限を有する者としての従業員のユーザIDを格納するフィールドを有している。なお、図5に示す承認者テーブルにおいて、「完了箱」という名称を有するノードは、承認が完了した申請データを管理又は処理する権限を有する者(例えば、企業等の総務課長、総務部長、人事課長、人事部長等)に相当する。本実施形態においては、具体的には、承認が完了した申請データを管理又は処理する権限を有する者は、ユーザIDが「Taro」である従業員(ここでは、氏名「総務 太郎」(図4参照))と、ユーザIDが「Jiro」である従業員(ここでは、氏名「総務 次郎」(図4参照))である。
再び図2を参照すると、組織テーブル記録部24は、組織に関するデータを格納する組織テーブルを記録する。
図6は、上位の組織テーブル(第1のテーブル)の一例を示す図であり、図7は、下位の組織テーブル(第2のテーブル)の一例を示す図である。上位の組織テーブルには組織における上位のノード又は従業員のデータが格納され、下位の組織テーブルには上位の組織テーブルにデータの格納されていない下位のノード又は従業員のデータが格納されている。図6及び図7に示すように、各組織テーブルは、レコード番号(No.)、改定日、ユーザID(第1の識別子)、当該レコードの組織上における区分である組織区分、組織所属名、氏名、組織序列番号(第2の識別子)及びリンクGUID(Globally Unique Identifier;第3の識別子)を格納するフィールドを有している。
組織区分は、1〜3までの値を取り得る。ここで、組織区分「1」は、当該レコードが部署に相当するノードに関するレコードであることを表す。また、組織区分「2」は、当該レコードが承認権限を有する者に相当するノードに関するレコードであることを表し、組織区分「3」は、当該レコードが従業員に関するレコードであることを表す。
例えば、図6に示す組織テーブルにおいて、第1レコード(組織所属名「東京本社」)には、組織序列番号「0001」が格納されており、第1レコードによって表されるノードの下位に位置するノードとしての第2レコード(組織所属名「東京本社」、氏名「完了箱」)には、第1レコード内の組織序列番号「0001」の末尾に「0001」を付加した組織序列番号「00010001」が格納されている。
また、例えば、従業員「武田 秀雄」(第6レコードに相当)の直近上位の従業員等は、第6レコード内の組織序列番号
「00010001000100020001」
の末尾4桁を削除した値
「0001000100010002」
を組織序列番号として格納しているレコード(ここでは、第5レコード)によって表される従業員等(ここでは、承認権限を有する者に相当するノード「営業部承認者」)となる。
例えば、図6に示す上位の組織テーブルにおいて、第9レコードには、当該上位の組織テーブルにおける唯一のリンクGUID
「7058a6fd−c8e0−4a45−bbf5−0036c2d14ce7」
が格納されている。このリンクGUIDは、第9レコードに相当する従業員等の配下の従業員等を示す第10レコード〜第15レコード(図7に示す下位の組織テーブル)に付与された共通のリンクGUIDと共通である。
また例えば、図6に示す上位の組織テーブルにおいて、第18レコードには、当該上位の組織テーブルにおける唯一のリンクGUID
「8058a6fd−c8e0−4a46−cbf5−0036c2d14ce8」
が格納されている。このリンクGUIDは、第18レコードに相当する従業員等の配下の従業員等を示す第19レコード〜第24レコード(図7に示す下位の組織テーブル)に付与された共通のリンクGUIDと共通である。
「00010001」
の末尾4桁を削除した値
「0001」
を組織序列番号として格納しているレコードは、下位の組織テーブル内に複数(第10レコードと第19レコード)存在する。この場合は第11レコード内のリンクGUIDを参照し、これと同一のリンクGUIDを有する上位レコード(ここでは、第10レコード)によって表される従業員等(ここでは、部署に相当するノード「営業部1課1G」)が、第11レコードの直近上位の従業員等となる。
「0001」
の末尾4桁を削除するとすべての桁がなくなってしまう。この場合は第10レコード内のリンクGUIDを参照し、これと同一のリンクGUIDを有するレコードを上位の組織テーブルから探す。ここでは、第10レコード内のリンクGUIDと同一のリンクGUIDが、上位の組織テーブルの第9レコードに存在するので、第9レコードによって表される従業員等(ここでは、承認権限を有する者に相当するノード「営業部1課承認者」)が、第10レコードの直近上位の従業員等となる。
再び図2を参照すると、役職テーブル記録部25は、従業員の役職に関するデータを格納する役職テーブルを記録する。
図8は、役職テーブルの一例を示す図である。図8に示すように、役職テーブルは、ユーザID、当該レコードが有効となった日又は有効となる日を表す改定日、及び、役職を格納するフィールドを有している。図8においては、例えば、ユーザIDが「Taro」である従業員(本実施形態においては、氏名「総務 太郎」(図4参照))は、1983年4月1日に一般従業員となり、1993年4月1日に総務課長となり、1998年4月1日に総務部長となったことを表している。
再び図2を参照すると、申請データ作成処理部26は、クライアント端末11〜1nを使用する従業員からの要求に応じて、申請データを作成し、申請テーブル記録部21に記録させる。
承認ルート決定処理部27は、申請テーブル記録部21に記録されている申請テーブル内の申請データに係る申請を承認すべき従業員を決定する処理を行う。
承認ルート作成・更新処理部29は、承認者テーブル又は組織テーブルの作成又は更新処理を行う。
図9は、サーバ1の申請データ作成処理の概要を示すフローチャートである。以下、サーバ1の申請データ作成処理について、図9を参照しながら説明する。ここでは、従業員「高田 由美子」が、休暇届に係る申請データを作成するものとする。
まず、クライアント端末(ここでは、クライアント端末11とする)を使用している従業員(ここでは、「高田 由美子」)が、申請の内容に関する情報(ここでは、伝票名「休暇届」及び休暇を取得することを所望する日「2003/05/01」)を入力し、サーバ1の申請データ作成処理部26が、この条件を受信する(ステップS101)。
図10は、サーバ1の承認・却下処理の概要を示すフローチャートである。以下、サーバ1の承認・却下処理について、図10を参照しながら説明する。
まず、承認ルート決定処理部27が、申請テーブル記録部21に記録されている申請テーブル内の処理対象のレコード(図3参照)内のユーザID(ここでは、「Takada」)を抽出する(ステップS201)。
次に、承認ルート決定処理部27は、組織テーブル記録部24に記録されている組織テーブル(図6及び図7参照)の中から、ステップS201にて抽出されたユーザID(ここでは、「Takada」)を格納しているレコード(ここでは、図7の第14レコード)を検索し、当該レコード内の組織序列番号、ここでは、
「000100020002」
を抽出する(ステップS202)。なお、このとき、ステップS201にて抽出されたユーザIDを格納しているレコードが複数存在している場合には、システム日付において有効なレコードを選択する。
そして、承認ルート決定処理部27は、ステップS202にて抽出された組織序列番号、ここでは、
「000100020002」
の末尾から所定の長さの値を少なくとも1回削除した値(末尾4桁を削除した値)、ここでは、
「00010002」
を算出する(ステップS203)。
なお、組織序列番号の末尾から所定の長さの値を削除した値をステップS203で算出する代わりに、予め組織序列番号の末尾から所定の長さの値を削除した値を算出しておき、この値を組織テーブル内の別のフィールドに格納しておいたものを、ステップS203で単に読み出すこととしても良い。
次に、承認ルート決定処理部27は、ステップS202で該当レコードが検索された組織テーブル(ここでは図7に示す下位の組織テーブル)の中に、ステップS203にて算出された値、ここでは、
「00010002」
を組織序列番号として格納しているレコードがあるか否かを判定する(ステップS204)。
下位の組織テーブルには、
「00010002」
を組織序列番号として格納しているレコードとして第12レコードと第21レコードが存在する(ステップS204:Y)。そこで、第14レコード内のリンクGUIDを参照し、これと同一のリンクGUIDを有するレコード(ここでは、第12レコード)を特定する(ステップS205)。なお、このとき、ステップS203にて算出された値を組織序列番号として格納しており、且つ同一のリンクGUIDを有するレコードが複数存在している場合には、システム日付において有効なレコードを選択する。
次に、ステップS205にて特定されたレコード内のユーザIDが0であるか否かを判定する(ステップS206)。ここで、特定された第12レコード内のユーザID(ここでは、「Eigyo_B_1K_1G」)は0ではないので(ステップS206:N)、承認ルート決定処理部27は、特定されたレコード内のユーザID(ここでは、「Eigyo_B_1K_1G」)を「承認権限を有する者に相当するノードのユーザID」として格納しているレコードを、承認者テーブル記録部23に記録されている承認者テーブル(図5参照)の中から検索し(ここでは、第5レコードがヒットする)、当該レコードに格納されている「承認権限を有する者としての従業員のユーザID」(ここでは、「Mori」)を抽出する(ステップS207)。なお、このとき、ステップS204にて抽出されたユーザIDを格納しているレコードが複数存在している場合には、システム日付において有効なレコードを選択する。これにより、申請データ(図3参照)に対する承認又は却下処理を最初に行うべき従業員(ここでは、ユーザID「Mori」、氏名「森 祐司」である従業員)を決定することができる。承認ルート決定処理部27は、このユーザIDを承認・却下処理部28に出力する。
次に、承認・却下処理部28は、ステップS205にて抽出されたユーザID(ここでは、「Mori」)を有する従業員(ここでは、「森 祐司」)が使用するクライアント端末(ここでは、クライアント端末12とする)に、申請データの内容を表示させる(ステップS208)。
そして、承認・却下処理部28は、ステップS205にて抽出されたユーザIDを有する従業員(ここでは、「森 祐司」)からの指示に応じて(ここでは、従業員「森 祐司」は、承認する旨の指示を入力するものとする)、申請データ内の複数の承認欄の中の1つの承認欄(ここでは、第1承認欄)の値を書き換える(ステップS209)。
図11は、書き換え後の申請データを表す図である。
次に、承認ルート決定処理部27は、全ての承認が完了しているか否かをチェックし、全ての承認が完了していると判断した場合には処理を終了し、そうでない場合には、処理をステップS203に戻す(ステップS210)。
例えば、図3の申請データが上司2名の承認を必要としている場合、従業員「森 祐司」の承認のみでは全ての承認が完了していないので、組織序列番号を更に4桁削除して(ステップS203)、
「0001」
を得る。そして、この「0001」を組織序列番号として格納しているレコードを探し(ステップS204)、同一のリンクGUIDを有する上位レコード(ここでは、第10レコード)を特定する(ステップS205)。
このとき、特定された第10レコード内のユーザIDが0である(部署に相当するノードである)ので(ステップS206:Y)、処理をステップS203に戻し、組織序列番号を更に4桁削除する。すると、組織序列番号のすべての桁がなくなるので、該当するレコードを探しても見つからない(ステップS204:N)。そこで、第10レコード内のリンクGUIDを参照し、これと同一のリンクGUIDを有するレコード(ここでは、第9レコード)を上位の組織テーブルの中から特定する(ステップS211)。
これにより、特定されたレコード内のユーザID(ここでは、「Eigyo_B_1K」)を「承認権限を有する者に相当するノードのユーザID」として格納しているレコードを、承認者テーブル(図5参照)の中から検索し(ここでは、第4レコードがヒットする)、当該レコードに格納されている「承認権限を有する者としての従業員のユーザID」(ここでは、「Mizutani」)を抽出することができる(ステップS207)。
なお、上位の組織テーブルにおいてリンクGUIDを付与された別々のレコードの配下の従業員等を、下位の組織テーブルとして別々のテーブルに分けて格納した場合には、ステップS205の処理において同一のリンクGUIDを探すまでもなく、各々の下位の組織テーブル内で承認権限を有する従業員等を一意に特定することができる。この場合、下位の組織テーブルにおいては、組織序列番号として削除演算の最小単位(ここでは4桁)の値しかもっていないレコード(ここでは、第10レコード、第15レコード、第19レコード、第24レコード)にだけリンクGUIDを付与すればよく、それ以外のレコードにはリンクGUIDを付与する必要はない。
図12は、サーバ1の承認ルート作成・更新処理の概要を示すフローチャートである。以下、サーバ1の承認ルート作成・更新処理について、図12を参照しながら説明する。
承認ルート作成・更新処理部29は、クライアント端末(ここでは、クライアント端末13とする)を使用している従業員から、承認権限を有する者としての従業員の追加、削除、又は、変更を行うためのデータを受け取り、承認者テーブル記録部23に記録されている承認者テーブル又は組織テーブル記録部24に記録されている組織テーブルの作成又は更新を行う(ステップS301)。
図13及び図14は、本発明の第二の実施形態に係る業務管理装置における組織テーブルの一例を示す図である。「改定日」と「ユーザID」の欄は第一の実施形態における図6及び図7と同様であるので、第二の実施形態では図示を省略している。本実施形態の組織テーブルには、第3の識別子として「リンク先GUID」と「リンク元GUID」を記録するフィールドが設けられている。更に、図14に示すように、下位の組織テーブルより更に下位の組織テーブルを有している。上記「更に下位の組織テーブル」では、上記「下位の組織テーブル」で付与された組織序列番号を先頭に含まない組織序列番号が付与されている。
「9058a6fd−c8e0−4a47−dbf5−0036c2d14ce9」
が格納されている。そして、このリンク元GUIDと同じ値が、上記「下位の組織テーブル」の第12レコードに、リンク先GUIDとして格納されている。
同様に、上記「下位の組織テーブル」には、共通のリンク元GUID
「7058a6fd−c8e0−4a45−bbf5−0036c2d14ce7」
が格納されている。そして、このリンク元GUIDと同じ値が、図13に示す「上位の組織テーブル」の第9レコードに、リンク先GUIDとして格納されている。
「00010001」
の末尾4桁を削除(S203)した
「0001」
を組織序列番号として有する上位レコード(第24レコード)からリンク元GUID
「9058a6fd−c8e0−4a47−dbf5−0036c2d14ce9」
を抽出し、このリンク元GUIDと同一のリンク先GUIDを有するレコード(上記「下位の組織テーブル」の第12レコード)を特定する(S211)ことにより、特定される。
「7058a6fd−c8e0−4a45−bbf5−0036c2d14ce7」
を必要とする場合が考えられる。本実施形態において「リンク先GUID」と「リンク元GUID」を記録するフィールドを別々に設けたのはこのためである。
本実施形態のシステム設計時には組織序列番号の最大桁数を決める必要があるが、本実施形態では、下位の組織テーブルより更に下位の組織テーブルを設けることができるので、組織序列番号の最大桁数の制約を受けることなく組織の階層数を設定したり後日変更したりすることができる。
10 システム
11〜1n クライアント端末
21 申請テーブル記録部
22 従業員テーブル記録部
23 承認者テーブル記録部
24 組織テーブル記録部
25 役職テーブル記録部
26 申請データ作成処理部
27 承認ルート決定処理部
28 承認・却下処理部
29 承認ルート作成・更新処理部
Claims (4)
- 組織における申請及び承認に関する業務の管理を行うための装置であって、
複数の構成者により構成される組織における上位の各構成者に対応する情報をそれぞれ格納するレコードを含む第1のテーブル及び前記組織における下位の各構成者に対応する情報をそれぞれ格納するレコードを含む第2のテーブルであって、各レコードが、前記複数の構成者を一意に特定する第1の識別子を格納する第1のフィールドと、前記複数の構成者の前記第1又は第2のテーブル内における序列を表す第2の識別子であって、前記第1又は第2のテーブル内の任意の者の前記第2の識別子の末尾に所定の長さの値を少なくとも1回付加したものを前記第1又は第2のテーブル内の任意の者の配下の者に相当する前記第2の識別子とした前記第2の識別子を格納する第2のフィールドと、前記複数の構成者の関連を表す第3の識別子を格納する第3のフィールドとを有する前記第1及び第2のテーブルを記録する第1及び第2の記録手段と、
申請に関する第3のテーブルであって、前記複数の構成者の中の申請を行った者を一意に特定する前記第1の識別子を格納するフィールドを少なくとも有する前記第3のテーブルを記録する第3の記録手段と、
前記第3のテーブルの処理対象のレコード内の前記第1の識別子に基づいて前記第2のテーブルを検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請を行った者の前記第2の識別子を抽出し、抽出された前記第2の識別子の末尾から前記所定の長さの値を少なくとも1回削除することにより得られた少なくとも1つの値を前記第2の識別子として格納している少なくとも1つの上位レコードを前記第2のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも1人の者を特定する第1の処理手段と、
前記第2のテーブル内に承認権限を有する者が存在しない場合に、前記第2のテーブル内の前記申請を行った者に対応するレコード内又は前記上位レコード内の前記第3の識別子を抽出し、抽出された前記第3の識別子を前記第3の識別子として格納している少なくとも1つのレコードを前記第1のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも1人の者を特定する第2の処理手段と、
を具備する業務管理装置。 - 前記第1の処理手段は、前記申請を行った者の前記第2の識別子の末尾から所定の長さの値を削除することにより得られた値を前記第2の識別子として格納しているレコードが、前記第2のテーブルに複数存在する場合に、当該複数存在するレコードのうち前記第3の識別子が前記申請を行った者の前記第3の識別子と一致するレコードを前記第2のテーブルから検索することにより、承認権限を有する者を特定する、請求項1記載の業務管理装置。
- 組織における申請及び承認に関する業務の管理を行うための方法であって、
複数の構成者により構成される組織における上位の各構成者に対応する情報をそれぞれ格納するレコードを含む第1のテーブル及び前記組織における下位の各構成者に対応する情報をそれぞれ格納するレコードを含む第2のテーブルであって、各レコードが、前記複数の構成者を一意に特定する第1の識別子を格納する第1のフィールドと、前記複数の構成者の前記第1又は第2のテーブル内における序列を表す第2の識別子であって、前記第1又は第2のテーブル内の任意の者の前記第2の識別子の末尾に所定の長さの値を少なくとも1回付加したものを前記第1又は第2のテーブル内の任意の者の配下の者に相当する前記第2の識別子とした前記第2の識別子を格納する第2のフィールドと、前記複数の構成者の関連を表す第3の識別子を格納する第3のフィールドとを有する前記第1及び第2のテーブルを記録するステップ(a)と、
申請に関する第3のテーブルであって、前記複数の構成者の中の申請を行った者を一意に特定する前記第1の識別子を格納するフィールドを少なくとも有する前記第3のテーブルを記録するステップ(b)と、
前記第3のテーブルの処理対象のレコード内の前記第1の識別子に基づいて前記第2のテーブルを検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請を行った者の前記第2の識別子を抽出するステップ(c)と、
ステップ(c)にて抽出された前記第2の識別子の末尾から前記所定の長さの値を少なくとも1回削除することにより得られた少なくとも1つの値を前記第2の識別子として格納している少なくとも1つの上位レコードを前記第2のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも1人の者を特定するステップ(d)と、
前記第2のテーブル内に承認権限を有する者が存在しない場合に、前記第2のテーブル内の前記申請を行った者に対応するレコード内又は前記上位レコード内の前記第3の識別子を抽出し、抽出された前記第3の識別子を前記第3の識別子として格納している少なくとも1つのレコードを前記第1のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも1人の者を特定するステップ(e)と、
をコンピュータに実行させる業務管理方法。 - 組織における申請及び承認に関する業務の管理を行うためのプログラムであって、
複数の構成者により構成される組織における上位の各構成者に対応する情報をそれぞれ格納するレコードを含む第1のテーブル及び前記組織における下位の各構成者に対応する情報をそれぞれ格納するレコードを含む第2のテーブルであって、各レコードが、前記複数の構成者を一意に特定する第1の識別子を格納する第1のフィールドと、前記複数の構成者の前記第1又は第2のテーブル内における序列を表す第2の識別子であって、前記第1又は第2のテーブル内の任意の者の前記第2の識別子の末尾に所定の長さの値を少なくとも1回付加したものを前記第1又は第2のテーブル内の任意の者の配下の者に相当する前記第2の識別子とした前記第2の識別子を格納する第2のフィールドと、前記複数の構成者の関連を表す第3の識別子を格納する第3のフィールドとを有する前記第1及び第2のテーブルを記録する手順(a)と、
申請に関する第3のテーブルであって、前記複数の構成者の中の申請を行った者を一意に特定する前記第1の識別子を格納するフィールドを少なくとも有する前記第3のテーブルを記録する手順(b)と、
前記第3のテーブルの処理対象のレコード内の前記第1の識別子に基づいて前記第2のテーブルを検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請を行った者の前記第2の識別子を抽出する手順(c)と、
手順(c)にて抽出された前記第2の識別子の末尾から前記所定の長さの値を少なくとも1回削除することにより得られた少なくとも1つの値を前記第2の識別子として格納している少なくとも1つの上位レコードを前記第2のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも1人の者を特定する手順(d)と、
前記第2のテーブル内に承認権限を有する者が存在しない場合に、前記第2のテーブル内の前記申請を行った者に対応するレコード内又は前記上位レコード内の前記第3の識別子を抽出し、抽出された前記第3の識別子を前記第3の識別子として格納している少なくとも1つのレコードを前記第1のテーブルから検索することにより、前記複数の構成者の中の前記処理対象のレコードに係る申請に対する承認権限を有する少なくとも1人の者を特定する手順(e)と、
をコンピュータに実行させるための業務管理プログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008296948A JP5232608B2 (ja) | 2008-11-20 | 2008-11-20 | 業務管理装置及び方法並びに業務管理プログラム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2008296948A JP5232608B2 (ja) | 2008-11-20 | 2008-11-20 | 業務管理装置及び方法並びに業務管理プログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2010122969A JP2010122969A (ja) | 2010-06-03 |
JP5232608B2 true JP5232608B2 (ja) | 2013-07-10 |
Family
ID=42324244
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008296948A Active JP5232608B2 (ja) | 2008-11-20 | 2008-11-20 | 業務管理装置及び方法並びに業務管理プログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5232608B2 (ja) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112084196B (zh) * | 2020-09-11 | 2023-10-17 | 武汉一格空间科技有限公司 | 一种流程化数据处理方法及系统 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH11250152A (ja) * | 1998-02-27 | 1999-09-17 | Osk:Kk | 電子承認システムおよび電子承認システムのためのプログラムを記録した記録媒体 |
JP3818449B2 (ja) * | 2003-06-26 | 2006-09-06 | 株式会社オービック | 業務管理装置及び方法並びに業務管理プログラム |
JP5075647B2 (ja) * | 2008-01-11 | 2012-11-21 | 株式会社オービック | 業務管理装置及び方法及びプログラム |
-
2008
- 2008-11-20 JP JP2008296948A patent/JP5232608B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
JP2010122969A (ja) | 2010-06-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP2007172280A (ja) | アクセス権管理方法、装置及びプログラム | |
JP5782636B2 (ja) | 情報匿名化システム、情報損失判定方法、及び情報損失判定プログラム | |
JP2000163303A (ja) | ディレクトリデータ変換方法、ディレクトリデータ変換プログラムが記憶された記憶媒体、およびディレクトリ変換サーバ | |
JP4954682B2 (ja) | 業務管理装置、業務管理方法、及び、業務管理プログラム | |
US20120320090A1 (en) | Polygon dissection in a geographic information system | |
JP5232608B2 (ja) | 業務管理装置及び方法並びに業務管理プログラム | |
JP2009187341A (ja) | 情報処理プログラム及び情報処理装置 | |
JP7279524B2 (ja) | データ管理プログラム、データ管理方法およびデータ管理システム | |
JP3818449B2 (ja) | 業務管理装置及び方法並びに業務管理プログラム | |
JP5075647B2 (ja) | 業務管理装置及び方法及びプログラム | |
JP4772368B2 (ja) | ビジネスプロセス例外処理生成支援装置およびプログラム | |
JP2009193470A (ja) | 電子承認ワークフローシステム | |
JP5063447B2 (ja) | コンテンツ管理装置及び方法及びプログラム | |
JP5884925B2 (ja) | 管理支援装置、管理支援方法及び管理支援プログラム | |
JP2010170208A (ja) | 権限管理システム | |
JPWO2007105512A1 (ja) | 回送データ管理システム | |
JP6229997B2 (ja) | データ管理システム及びプログラム | |
JP4805491B2 (ja) | 辞書管理プログラム及びコンピュータシステム | |
JP2011070369A (ja) | データベース統合装置およびデータベース統合方法 | |
JP2013171495A (ja) | データ管理装置、データ管理方法及びデータ管理プログラム | |
CN109508324B (zh) | 一种基于对象存储组件的超大文件管理方法及系统 | |
JP5074818B2 (ja) | 会議記録管理装置及び方法 | |
JP2008287663A (ja) | リソース管理装置 | |
JP2023064364A (ja) | 文書管理装置、文書管理システム、文書管理方法、およびプログラム | |
JP2009053821A (ja) | データベース処理システム、データベースシステム、データベース処理方法及び、プログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20111117 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20130218 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20130226 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130325 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20160329 Year of fee payment: 3 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5232608 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |