特許 6167138 ワークフロー情報管理装置及びそのプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6167138

(24)【登録日】2017年6月30日

(45)【発行日】2017年7月19日

(54)【発明の名称】ワークフロー情報管理装置及びそのプログラム

(51)【国際特許分類】

   G06Q 10/06 20120101AFI20170710BHJP

【ＦＩ】

   G06Q10/06

【請求項の数】2

【全頁数】17

(21)【出願番号】特願2015-131168(P2015-131168)

(22)【出願日】2015年6月30日

(65)【公開番号】特開2017-16307(P2017-16307A)

(43)【公開日】2017年1月19日

【審査請求日】2015年6月30日

【審判番号】不服2016-4613(P2016-4613/J1)

【審判請求日】2016年3月30日

【早期審査対象出願】

(73)【特許権者】

【識別番号】598049322

【氏名又は名称】株式会社三菱東京ＵＦＪ銀行

(74)【代理人】

【識別番号】110000408

【氏名又は名称】特許業務法人高橋・林アンドパートナーズ

(72)【発明者】

【氏名】武井 優

【合議体】

【審判長】 金子 幸一

【審判官】 佐藤 智康

【審判官】 貝塚 涼

(56)【参考文献】

【文献】 特開２０１２−１３８０１４（ＪＰ，Ａ）

【文献】 特開２００６−１７２３７７（ＪＰ，Ａ）

【文献】 特開２００２−２４５００（ＪＰ，Ａ）

【文献】 特開２００３−３３７８７６（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

G06Q 10/00-50/34

(57)【特許請求の範囲】

【請求項1】

画面上の情報入力領域に関連付けて複数個のノードが規定されるノード群の該複数個のノードと、該複数個のノードが該画面上の情報入力領域に対する更新をすることが可能な状態か否かを示す更新権限情報とが各々対応付けて記憶される記憶部と、
前記ノードが、前記画面上の情報入力領域に対する更新をすることが不能な状態となるような事象が生じた後、所定の期間、前記ノードが前記画面上の情報入力領域に対する更新をすることが可能な状態を維持し、前記所定の期間の経過後に、前記ノードが前記画面上の情報入力領域に対する更新をすることが不能な状態に変更し、前記ノードからの前記画面上の情報入力領域に対する更新要求を拒絶する制御部と、を備え、
前記制御部は、前記事象が生じた場合に、前記事象が生じる前から前記ノードと同一の属性情報に対応付けられる別のノードを前記ノード群に包含させることを特徴とする
情報管理装置。

【請求項2】

コンピュータを、
画面上の情報入力領域に関連付けて複数個のノードが規定されるノード群の該複数個のノードと、該複数個のノードが該画面上の情報入力領域に対する更新をすることが可能な状態か否かを示す更新権限情報とが各々対応付けて記憶される記憶部と、
前記ノードが、前記画面上の情報入力領域に対する更新をすることが不能な状態となるような事象が生じた後、所定の期間、前記ノードが前記画面上の情報入力領域に対する更新をすることが可能な状態を維持し、前記所定の期間の経過後に、前記ノードが前記画面上の情報入力領域に対する更新をすることが不能な状態に変更し、前記ノードからの前記画面上の情報入力領域に対する更新要求を拒絶する制御部と、を備え、
前記制御部は、前記事象が生じた場合に、前記事象が生じる前から前記ノードと同一の属性情報に対応付けられる別のノードを前記ノード群に包含させることを特徴とする
情報管理装置として機能させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ワークフロー情報管理装置及びそのプログラムに関する。

【背景技術】

【0002】

会社などの組織においては、例えば、ある社員が出張を希望する場合には、その社員は、出張前に、出張申請、出張にかかる交通費の申請、出張先との接待交際費の申請などをして、出張後には、出張報告、実際にかかった交通費や接待交際費の報告などをするのが一般的である。また、その出張が成功して、新規に顧客を獲得できることになる場合には、新規顧客の登録申請をすることもある。このような申請や報告をする社員は、自身が所属する部門の上長に、これらの申請や報告をするのが一般的である。その後、所定の経路（審査・承認経路）を経て最終的に総務や管理部門の承認を得て、手続きが完了することになる。ここでは、わかりやすさの観点から、会社を用いて説明するが、組織は会社に限られるものではなく、公共団体などであってもよい。

【0003】

ところで、このような申請や報告は、紙媒体で行われることもあるものの、近年のコンピュータ技術の発展に伴って、コンピュータを用いて、システム上で行われることもある。このような申請や報告の提出経路をシステム上で実現するものとして、いわゆるワークフローシステムが知られている。

【0004】

ワークフローシステムでは、組織変更や社員の異動があった場合、変更や異動を機械的に行うことが一般的である。すなわち、例えば、２０１５年３月３１日まで、営業第１部１１課の課長であったＢが、２０１５年４月１日付けで、営業第１部１３課の課長に異動し、同日付けで営業第１部第１４課の課長であったＫが営業第１部１１課の課長となった場合、システム上でも、この異動が反映される。そのため、２０１５年４月１日以降は、営業第１部１１課の一般社員Ａの申請や報告に対する審査・承認は、まず課長Ｋが行うというワークフローとなる。このようなシステムは、実際の異動と合致しているというメリットがある。

【0005】

他方、営業第１部１１課の一般社員Ａが、営業第１部１１課の課長Ｂが異動する前に、申請を行っていたにもかかわらず、課長Ｂがその審査・承認をすることなく、営業第１部１３課に異動し、新たにＫが営業第１部１１課の課長となった場合には、ワークフローが実際の異動と合致していると不都合な場合もある。そこで、データの申請時に運用している組織情報に基づく組織構成に従った申請データの提出経路を確定する機能を実現するワークフロー処理プログラムが提案されている（例えば、特許文献１）。

【0006】

特許文献１に開示されたワークフロー処理プログラムによれば、社員の異動（異なる部署への移動）を含む組織変更前後の組織情報（旧組織情報、新組織情報）をデータベース化し、文書データ、書類データ、伝票データ等のデータの申請時に、その時点で申請者に有効な組織情報（データの申請時に運用している組織情報）の組織構成に従ったデータの提出経路（審査・承認経路）を自動的に算出設定している。そのため、社員は、社員の異動を含む組織変更があった場合でも、これを意識することがないというメリットがある。

【0007】

しかし、データの申請時に運用していた組織情報に基づく組織構成に従った申請データの提出経路を確定してしまうと、望ましくない場合もある。すなわち、例えば、「旅費・立替金清算」や「報告書」といった過去の事象を清算する申請においては、変更後の組織情報から決定された承認者では信憑性の確認が難しく組織変更前の組織情報から決定された承認者に決済されるのが望ましいと考えられるが、他方、「購入要求」や「開催通知」といった今後の事象を届け出る申請については、組織変更後の組織情報から決定された承認者に決済されるのが望ましい。特許文献１に開示された技術では、申請された時点が基準となるので、「購入要求」のような今後の事象を届け出る申請であっても、旧組織の承認者が決裁することになってしまうのである。そこで、特許文献２に開示されたワークフローシステムでは、ワークフローサーバーが、申請者からの承認要求に応じて、承認予定者を、申請日時点での組織情報及び承認要求時点での組織情報に基づいて複数特定し、特定される複数の承認予定者を申請者に通知し、承認時に複数の承認予定者からいずれかを承認者として選択させる構成を有することにより、例えば、申請日での課長Ｂと承認時での課長Ｋが異なる場合には、２人を次に承認する予定の候補者として抽出し、申請者は、２人のうちからいずれかを承認者として選択可能になる。これにより、申請者Ａは、今後の事象を届け出る申請について、組織変更後の組織情報から決定された承認者（課長Ｋ）に決済を受けることができる。

【先行技術文献】

【特許文献】

【0008】

【特許文献1】特開２００６−３３８１４０号公報

【特許文献2】特開２００８−２６９６５４号公報

【発明の概要】

【発明が解決しようとする課題】

【0009】

しかしながら、申請者Ａが、今後の事象を届け出る申請について、組織変更後の組織情報から決定された承認者（課長Ｋ）を選択してしまうと不都合な場合もある。すなわち、異動後すぐに課長Ｋが体調を崩して休暇をとらざるを得なくなった場合には、申請者Ａが課長Ｋの休暇を知る前に課長Ｋを選択して承認要求をしてしまうと、課長Ｋが復帰してからでないと承認をできなくなり、申請者Ａの承認要求が迅速に処理されないといった問題が生じることがある。また、Ａの申請内容によっては、そもそも、旧組織の課長Ｂが審査・承認を行っても、新組織の課長Ｋが審査・承認を行ってもどちらでもよい場合もある。この場合に、申請者Ａが旧組織の課長Ｂか新組織の課長Ｋかのいずれかを選択して承認要求をしてしまった場合に、選択された課長が休暇などで承認をするのが遅くなる場合もある。さらには、承認要求がなされなければ、いつまで経っても、承認者として、旧部署の上長を選択できることになってしまうが、いつまでもこのような選択をできると、旧部署の上長は、旧部署からいつまでも解放されないといった問題が生じる。

【0010】

本発明は、上記のような従来技術に伴う課題を解決しようとするものであって、その目的とするところは、実際の異動と合致したワークフローを構築しつつ、より柔軟な審査・承認を行うことができるワークフロー情報管理装置を提供するところにある。

【課題を解決するための手段】

【0011】

本発明の一実施形態によると、画面上の情報入力領域に関連付けて複数個のノードが規定されるノード群の該複数個のノードと、該複数個のノードが該画面上の情報入力領域に対する更新をすることが可能な状態か否かを示す属性情報とが各々対応付けて記憶される記憶部と、前記ノードが、前記画面上の情報入力領域に対する更新をすることが不能な状態となるような事象が生じた後、所定の期間、前記ノードが前記画面上の情報入力領域に対する更新をすることが可能な状態を維持し、前記所定の期間の経過後に、前記ノードが前記画面上の情報入力領域に対する更新をすることが不能な状態に変更し、前記ノードからの前記画面上の情報入力領域に対する更新要求を拒絶する制御部と、を備えた情報管理装置を提供することができる。

【0012】

別の好ましい態様において、前記制御部は、前記事象が生じた場合に、該ノードと同一の属性情報に対応付けられる別のノードを前記ノード群に包含させてもよい。

【0013】

別の好ましい態様において、コンピュータを、画面上の情報入力領域に関連付けて複数個のノードが規定されるノード群の該複数個のノードと、該複数個のノードが該画面上の情報入力領域に対する更新をすることが可能な状態か否かを示す属性情報とが各々対応付けて記憶される記憶部と、前記ノードが、前記画面上の情報入力領域に対する更新をすることが不能な状態となるような事象が生じた後、所定の期間、前記ノードが前記画面上の情報入力領域に対する更新をすることが可能な状態を維持し、前記所定の期間の経過後に、前記ノードが前記画面上の情報入力領域に対する更新をすることが不能な状態に変更し、前記ノードからの前記画面上の情報入力領域に対する更新要求を拒絶する制御部と、を備えた情報管理装置として機能させるプログラムを提供することができる。

【0014】

別の好ましい態様において、ノードと、該ノードが第１範囲と該第１範囲以外の第２範囲のいずれに属するかを示す属性情報とが各々対応付けて記憶される記憶部と、前記第１範囲に属するノードが、前記第１範囲から前記第２範囲に移動した後、所定の期間、前記第２範囲に移動したノードが前記第１範囲に関する画面上の情報入力領域に対する更新をすることが可能な状態を維持し、前記所定の期間の経過後に、前記第２範囲に移動したノードが前記第１範囲に関する画面上の情報入力領域に対する更新をすることが不能な状態に変更し、前記第２範囲に移動したノードからの前記第１範囲に関する画面上の情報入力領域に対する更新要求を拒絶する制御部と、を備えた情報管理装置を提供することができる。

【0015】

別の好ましい態様において、コンピュータを、ノードと、該ノードが第１範囲と該第１範囲以外の第２範囲の何れに属するかを示す属性情報とが各々対応付けて記憶される記憶部と、前記第１範囲に属するノードが、前記第１範囲から前記第２範囲に移動した後、所定の期間、前記第２範囲に移動したノードが前記第１範囲に関する画面上の情報入力領域に対する更新をすることが可能な状態を維持し、前記所定の期間の経過後に、前記第２範囲に移動したノードが前記第１範囲に関する画面上の情報入力領域に対する更新をすることが不能な状態に変更し、前記第２範囲に移動したノードからの前記第１範囲に関する画面上の情報入力領域に対する更新要求を拒絶する制御部と、を備えた情報管理装置として機能させるプログラムを提供することができる。

【発明の効果】

【0016】

本発明によれば、実際の異動と合致したワークフローを構築しつつ、より柔軟な審査・承認を行うことができるワークフロー情報管理装置を提供することができる。

【図面の簡単な説明】

【0017】

【図1】本発明の一実施形態に係るワークフロー情報管理装置の構成の一例を示すブロック図である。

【図2】図１に示した人事情報記憶部内のデータ構成の一例を示す図である。

【図3】図１に示した承認権限情報記憶部内のデータ構成の一例を示す図である。

【図4】図１に示した承認経路情報記憶部内のデータ構成の一例を示す図である。

【図5】図１に示した申請情報記憶部内のデータ構成の一例を示す図である。

【図6】本発明の一実施形態に係るワークフロー情報管理装置を適用可能なワークフローシステムにおける承認権限制御処理手順の一例を示すフローチャートである。

【図7】組織変更前の旧組織の承認経路の一部を示すブロック図である。

【図8】組織変更後の新組織の承認経路の一部を示すブロック図である。

【図9】人事情報変更情報の一例を示す図である。

【図10】組織変更後の新組織における人事情報記憶部内のデータ構成の一例を示す図である。

【図11】組織変更後の新組織における承認権限情報記憶部内のデータ構成の一例を示す図である。

【図12】組織変更後の新組織における承認経路及び承認経路に対応する承認者を示すブロック図である。

【図13】組織変更後の新組織において承認権限が重複する場合のアクセス画面の一例を示す図である。

【図14】組織変更後の新組織において承認権限が重複する場合の承認画面の一例を示す図である。

【発明を実施するための形態】

【0018】

以下、本発明の一実施形態について、図面を参照しながら詳細に説明する。以下に示す実施形態は本発明の実施形態の一例であって、本発明はこれらの実施形態に限定されるものではない。なお、本実施形態で参照する図面において、同一部分または同様な機能を有する部分には同一の符号または類似の符号（数字の後にＡ、Ｂなどを付しただけの符号）を付し、その繰り返しの説明は省略する場合がある。また、「〜記憶部」に格納されるデータの値は、実際には「０」「１」であっても、わかりやすさの観点から、データが意味する内容として表現する。

【0019】

＜第１実施形態＞
［ワークフロー情報管理装置の構成］
図１を用いて、ワークフロー情報管理装置１の概要を説明する。図１は、本発明の一実施形態に係るワークフロー情報管理装置の構成の一例を示すブロック図である。ワークフロー情報管理装置１は、通信制御部３０、制御部４０及び記憶部５０を含む。ワークフロー情報管理装置１は、接続するユーザ端末２０ａ、２０ｂ及び２０ｃそれぞれがネットワーク２７を介して接続する。なお、ユーザ端末の区別が不要な場合には、「ユーザ端末２０」と表記する。ユーザ端末２０は、申請者が使用する場合には、申請者端末として機能し、承認者が使用する場合には、承認者端末として機能する。ワークフロー情報管理装置１は、接続するユーザ端末２０（申請者端末）の申請者に対して所定のワークフローに基づく申請機能を提供し、ユーザ端末２０（承認者端末）の承認者に申請者からの申請に対する承認機能を提供する。

【0020】

ここで、ネットワーク２７は、例えば、ＬＡＮ（ローカルエリアネットワーク）やインターネット等のネットワークであり、無線／有線回線、専用回線等を問わず、ユーザ端末２０がワークフロー情報管理装置１に接続可能なネットワーク環境が適用される。

【0021】

また、ユーザ端末２０は、多機能携帯電話、携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）等の移動通信端末装置、パーソナルコンピュータなどの通信機能及び演算機能を備えた情報処理端末装置等が含まれる。また、ワークフロー情報管理装置１が提供する画面を表示する表示制御機能としてブラウザを備え、ＣＰＵ、メモリ及びワークフロー情報管理装置１との間の通信制御を遂行する通信制御部３０等を含む。さらに、マウスやキーボード、タッチパネル等の操作入力装置及び表示装置を備えることができる。

【0022】

記憶部５０は、人事情報記憶部５１、承認権限情報記憶部５３、承認経路情報記憶部５５及び申請情報記憶部５７を含む。それぞれについての詳細な説明は、後述する。

【0023】

制御部４０は、人事情報制御部４１、承認権限制御部４３、承認経路制御部４５及び申請情報制御部４７を含む。「〜制御部」として説明するものは、例えば、それぞれの機能を実行するプログラムであるが、これに限定されるものではない。外部サーバからプログラムを実行して、それぞれの機能を実現する場合の機能ブロックであってもよい。プログラムは、ＣＰＵ（図示せず）によって読み出され実行される。

【0024】

［人事情報記憶部内のデータ構成］
図２を用いて、人事情報記憶部５１内のデータ構成を説明する。図２は、図１に示した人事情報記憶部内のデータ構成の一例を示す図である。ここで、人事情報とは、例えば、会社などの組織を構成する構成員の所属や役職などを示す情報である。また、会社の構成員は正社員であっても、パート従業員であっても、派遣社員であってもよく、制限はない。社員には所属や役職などに応じた権限が認められる。例えば、課長には、課員の申請した交通費清算の決裁権限が認められたり、総務部に所属する部員は、社員が社外秘の資料を社外に持ち出す際の持ち出し申請の承認をする権限が認められたりする。また、この権限が認められる有効期間は、基本的には、社員が所属する部署の役職に就いている期間となる。

【0025】

人事情報は、例えば、図２に示すように、ユーザＩＤ５１１、氏名５１２、社員番号５１３、入社日５１４、組織ＩＤ５１５、組織名（「部署」ということもある。）５１６、役職ＩＤ５１７、役職名５１８、開始日５１９、終了日５２０、自宅電話番号５２１及び自宅住所５２２を含むが、これらに限定されるものではなく、支社名などを含んでもよい。ここで、開始日とは、当該組織の当該役職を開始した日のことを意味し、終了日とは、当該組織の当該役職を終了した日のことを意味する。図２をみると、例えば、氏名Ｋは、営業第１部第１４課の課長を２０１３年４月１日から開始し、現在までその状態が続いていることがわかる。

【0026】

［承認権限情報記憶部内のデータ構成］
図３を用いて、承認権限情報記憶部５３内のデータ構成を説明する。図３は、図１に示した承認権限情報記憶部内のデータ構成の一例を示す図である。承認権限情報は、例えば、図３に示すように、ユーザＩＤ５３１、氏名５３２、社員番号５３３、組織名５３４、役職ＩＤ５３５、申請番号５３６、承認権限の有無５３７、有効期限５３８を含むが、これらに限定されるものではない。

【0027】

承認権限とは、所属する組織の情報にアクセスし、申請者の申請に対して、審査・承認する権限をいう。例えば、社員Ａは、営業第１部１１課に所属する担当（役職ＩＤがＴ）であるから、申請者になることはできるが、審査・承認する権限は有さない。そのため、社員Ａの承認権限の有無５３７欄は、「×（なし）」となっている。もっとも、社員Ａは、営業第１部１１課の情報にアクセスすること自体はできるし、例えば、交通費の申請などをすることはできる。他方、社員Ｋは、課長（役職ＩＤがＫ）であるから、審査・承認する権限を有する。そのため、社員Ｋの承認権限の有無５３７欄は、「○（あり）」となっている。

【0028】

ここで、「ノード」とは、データベースのレコードやファイルへアクセスするアクセス端子をいい、「ノード群」とは、ノードの集まりをいう。本実施例では、「ノード」は、課員、課長、部長などの社員を意味し、「ノード群」とは、社員の集まりを意味する。課員である申請者が申請をして、課長が審査・承認し、次に、部長が審査・承認をする場合、課長と部長は、承認画面（図１４参照）の入力領域に関連付けて複数個のノードが規定されるノード群に該当する。また、「属性情報」とは、社員の組織における属性を示す情報をいう。例えば、社員の所属する組織名５３４、役職ＩＤ５３５、「属性情報」に該当するが、これに限定されるものではない。承認権限の有無５３７は、申請者の申請に対して承認をすることが可能か否かを示す情報であるから、社員の組織における属性を示す情報といえ、「属性情報」に該当する。「画面上の情報入力領域」は、例えば、図１４に示す承認画面における承認アイコン４２４やコメント欄４３２である。「画面上の情報入力領域に対する更新」は、例えば、承認アイコン４２４をクリックすることやコメント欄４３２に入力することである。承認権限の有無５３７は、承認権限を有すると、申請者の申請情報に対して承認アイコン４３４をクリックすることによって、承認することができることから、「画面上の情報入力領域に対する更新をすることが可能な状態か否かを示す更新権限情報」に該当する。また、図３の承認権限の有無５３７欄に示すように、例えば、「ノード」であるＫは、申請番号ｓ２０１５０１＊＊に対する承認権限を有するから、「画面上の情報入力領域に対する更新をすることが可能な状態か否かを示す更新権限情報」と「対応付け」られているといえる。

【0029】

また、有効期限とは、承認権限を有する期限をいう。ここで、例えば、社員Ｋは、営業第１部１４課の課長（役職ＩＤがＫ）であるため、承認権限を有するところ、社員Ｋの承認権限の有効期限は、「９９９９／３／３１」となっている。この「９９９９／３／３１」は、社員Ｋの承認権限が継続することを便宜上９９９９年３月３１日としているにすぎない。社員Ｋが異動すれば、この有効期限の値は、変更される。

【0030】

［承認経路情報記憶部内のデータ構成］
図４を用いて、承認経路情報記憶部５５内のデータ構成を説明する。図４は、図１に示した承認経路情報記憶部内のデータ構成の一例を示す図である。この例では、営業第１部の承認経路情報が示されている。営業第１部は、１１課、１２課、１３課及び１４課で構成され、それぞれの課員は、それぞれの課長に申請し、それぞれの課長が承認すると、営業第１部の部長が承認するかどうかを審査することになる。営業第１部の部長から破線が伸びて、経理部につながっている。これは、営業第１部の部長で承認が終わる場合と営業第１部の部長の承認では終わらず、経理部の部長の承認まで必要な場合とがあることを意味する。例えば、出張報告レポートの申請であれば、営業第１部の部長の承認までで足りるが、交通費のような経費に関わる申請であれば、経理部の部長の承認まで必要となる。

【0031】

承認経路制御部４５（図１を参照）は、ユーザ端末２０からの承認経路変更情報の入力があると、承認経路情報記憶部５５内のデータを書き換える。例えば、コンプライアンスの強化のために、変更前は、営業第１部の部長の承認で足りていた申請が、変更後は、経理部の部長の承認まで必要になる場合には、このような承認経路変更情報が、ユーザ端末２０から承認経路制御部４５に入力され、データが書き換えられる。

【0032】

［申請情報記憶部内のデータ構成］
図５を用いて、申請情報記憶部５７内のデータ構成を説明する。図５は、図１に示した申請情報記憶部内のデータ構成の一例を示す図である。申請情報は、例えば、図５に示すように、申請番号５７１、申請日５７２、申請者５７３、組織名５７４、申請項目５７５、承認経路５７６、入力データ５７７、申請内容５７８を含むが、これらに限定されるものではない。入力データ５７７欄には、例えば、交通費であれば、実際にかかった交通費を入力することになる。

【0033】

図６は、本発明の一実施形態に係るワークフロー情報管理装置を適用可能なワークフローシステムにおける承認権限制御処理手順の一例を示すフローチャートである。ここでは、図７から図８のように組織変更になった場合、例えば、社員Ｂが旧部署の営業第１部１１課の課長から新部署の営業第１部１３課の課長となった場合について、承認権限の変更処理を説明する。まず、人事情報変更情報（図９参照）の「更新区分」の少なくとも１つが「更新」となっているかどうかを確認する（Ｓ１０１）。具体的には、ユーザ端末２０からワークフロー情報管理装置１に人事情報変更情報のデータが入力された場合に、人事情報制御部４１が、この入力された情報の更新区分１１１のデータが「更新」となっていることを判定する。図９に示すように、社員Ｂについては、「更新」と判定される。人事情報変更情報の更新区分が「更新」ではない場合には、旧部署への承認権限を維持する必要がない。そこで、この場合（Ｓ１０１でＮｏの場合）には、承認権限変更処理は、終了となる。

【0034】

次に、人事情報変更情報の「更新区分」が「更新」となっている場合（Ｓ１０１でＹｅｓの場合）には、新部署の承認権限を有するように変更するとともに、旧部署の承認権限を有する状態を維持する処理を行う（Ｓ１０２）。具体的には、ユーザ端末２０からワークフロー情報管理装置１に人事情報変更情報のデータが入力され、変更前の役職ＩＤが「Ｋ」である場合には、承認権限制御部４３は、変更前の組織の役職の承認権限を所定の期間維持するように処理するとともに、変更後の役職ＩＤを確認して、その役職ＩＤに対応する承認権限に変更する。例えば、社員Ｂが旧部署の営業第１部１１課の課長で、新部署の営業第１部１３課の課長となった場合には、社員Ｂの承認権限については、新部署である営業第１部１３課の承認権限を有するように変更されるとともに、旧部署である営業第１部１１課の承認権限も維持される。もっとも、社員Ｂの旧部署である営業第１部１１課の承認権限は、所定の期間に限定される。本明細書では、旧組織から新組織に異動したにもかかわらず、所定の期間、旧組織の承認権限が認められることを、「所定期間ルール」と呼ぶ。

【0035】

次に、旧部署の承認が可能である所定の期間が経過したかどうかを確認する（Ｓ１０３）。具体的には、承認権限制御部４３が承認権限の変更を行ったときの時刻から所定の期間が経過するまでタイマーなどで期間を計測することによって確認する。所定の期間が経過していない場合（Ｓ１０３でＮｏの場合）には、このステップがＹｅｓとなるまで繰り返す。

【0036】

所定の期間が経過した場合（Ｓ１０３でＹｅｓの場合）には、期間延長の申請があるかどうかを確認する（Ｓ１０４）。具体的には、期間延長の申請は、例えば、ユーザ端末２０から申請が行われるので、その申請データがあるかどうかで確認する。ここで、期間延長の申請は、当初設定された所定の期間で引継ぎを行うことができない場合に行われる。期間延長がある場合（Ｓ１０４でＹｅｓの場合）には、再度所定の期間（この場合は、延長期間）が経過したかどうかを確認する（Ｓ１０３）。この期間が経過していた場合（Ｓ１０３でＹｅｓの場合）には、再度期間延長の申請があるかを確認する（Ｓ１０４）。なお、期間延長の申請回数は、制限があっても制限がなくてもどちらでもよい。

【0037】

期間延長がない場合（Ｓ１０４でＮｏの場合）には、旧部署の承認権限を失う（Ｓ１０５）。これにより、承認権限変更処理は、終了となる。

【0038】

［人事情報変更情報］
図７から図９を用いて、人事情報変更情報について説明する。図７は、組織変更前の旧組織の承認経路の一部を示すブロック図である。図８は、組織変更後の新組織の承認経路の一部を示すブロック図である。図９は、人事情報変更情報の一例を示す図である。組織変更前の旧組織では、図７が示すように、営業第１部１１課の承認経路は、社員Ａが申請し、１１課の課長Ｂがこれを審査・承認し、営業第１部の部長Ｃがさらに審査・承認し、経理部門へと続く。同様に、営業第１部１２課の承認経路は、社員Ｂが申請し、１２課の課長Ｅがこれを審査・承認し、営業第１部の部長Ｃがさらに審査・承認し、経理部門へと続く。営業第１部１３課、１４課についても、営業第１部１１課、１２課と同様である。他方、組織変更後の新組織では、図８が示すように、営業第１部１１課の承認経路は、社員Ａが申請し、１１課の課長Ｋがこれを審査・承認し、営業第１部の部長Ｃがさらに審査・承認し、経理部門へと続く。営業第１部１２課、１３課、１４課についても、営業第１部１１課と同様である。図７及び図８をみると、営業第１部１１課の課長であったＢが、営業第１部１３課の課長に異動し、営業第１部１３課の課長であったＨが、営業第１部１４課の課長に異動し、営業第１部１４課の課長であったＫが、営業第１部１１課の課長に異動していることがわかる。他方、営業第１部１２課の課長Ｅは異動していないことがわかる。

【0039】

人事情報変更情報は、例えば、図９に示すように、更新区分１１１、変更前の組織ＩＤ１１２ａ、変更前の組織名１１３ａ、変更前の役職ＩＤ１１４ａ、変更前の役職名１１５ａ、変更後の組織ＩＤ１１２ｂ、変更後の組織名１１３ｂ、変更後の役職ＩＤ１１４ｂ、変更後の役職名１１５ｂ、ユーザＩＤ１１６、氏名１１７、期日１１８を含むが、これらに限定されるものではない。

【0040】

ここで、更新区分は、人事情報の変更の種類を意味する。変更の種類としては、「更新」「削除」「新規」があるが、これらに限定されるものではない。「更新」は、組織変更前と変更後の値がそれぞれ入力され、しかも、変更前と変更後の値が異なる状態を意味する。「削除」は、変更前においては、値が入力されていたものの、変更後においては、値が入力されない状態を意味する。例えば、社員が退職した場合や他の会社に出向した場合などが「削除」に該当する。「新規」は、変更前においては、値が入力されていなかったものの、変更後においては、値が入力される状態を意味する。例えば、新入社員が入社した場合などが「新規」に該当する。図９では、組織変更前と変更後の値がそれぞれ入力され、しかも、変更前と変更後の値が異なる状態であるから、更新区分は、すべて「更新」となっている。また、期日１１８は、異動の日付を意味する。図９をみると、社員Ｂらが、２０１５年４月１日付けで異動していることがわかる。

【0041】

図９では、人事情報変更情報として、変更前の組織ＩＤ、組織名、役職ＩＤ、役職名を含んでいるが、変更前の情報は、既に人事情報記憶部５１に記憶されていることから、人事情報変更情報に含まなくてもよい。

【0042】

次に、図１０を用いて、人事情報変更情報のデータがユーザ端末２０から入力された場合に、人事情報記憶部４１のデータ領域がどのように変更されるかを説明する。図１０は、組織変更後の新組織における人事情報記憶部内のデータ構成の一例を示す図である。人事情報変更情報のデータが、ユーザ端末２０から入力されると、人事情報制御部４１が人事情報記憶部５１に格納されている人事情報のデータを書き加える。人事情報変更情報のデータには、ユーザＩＤ１１６や氏名１１７といったデータがあることから、社員一人一人を特定することができる。人事情報記憶部５１内のユーザＩＤ５１１や氏名５１２と人事情報変更情報のユーザＩＤ１１６や氏名１１７とが一致すれば、同一の社員である。氏名の場合には、同姓同名の人物がいる場合も考えられることから、ユーザＩＤで同一の社員かどうかを判定するのが好ましいが、同姓同名の人物がいない場合には、氏名で同一の社員かどうかを判定してもよい。

【0043】

同一の社員であると判定できたら、変更後のデータを所定の領域に書き込む。例えば、ユーザＩＤが「ｕ５１０２２」のＫの場合、人事情報変更情報の期日１１８に「２０１５／４／１」を意味する値が入力されているので、営業第１部１１課の課長の開始日５１９の欄には「２０１５／４／１」を意味する値が入力される。他方、営業第１部１４課の課長の終了日５２０の欄には、「２０１５／３／３１」を意味する値が入力される。これは、Ｋが営業第１部１４課の課長であったのが、２０１５年３月３１日までであったことを意味する。「２０１５／３／３１」を意味する値は、「２０１５／４／１」を意味する値から、１日分減算することで求めることができる。

【0044】

次に、図１１を用いて、承認権限情報がどのように変更されるかを説明する。図１１は、組織変更後の新組織における承認権限情報記憶部内のデータ構成の一例を示す図である。ユーザ端末２０からワークフロー情報管理装置１に人事情報変更情報のデータが入力され、変更前の役職ＩＤが「Ｋ」である場合には、承認権限制御部４３は、変更前の組織の役職の承認権限を所定の期間維持するように処理するとともに、変更後の役職ＩＤを確認して、その役職ＩＤに対応する承認権限に変更する。例えば、社員Ｋの営業第１部１４課の承認権限は、２０１５年４月１０日まで維持され、社員Ｋの営業第１部１１課の承認権限は、９９９９年３月３１日までに変更される。ここで、社員Ｂは、２０１５年４月１０日まで、営業第１部１１課の承認権限を有する。そのため、社員Ｂは、２０１５年４月１０まで、社員Ｋと同一部署である営業第１部１１課の承認権限を有する。

【0045】

ここで、画面上の情報入力領域とは、ある画面上の情報を入力することのできる領域を意味し、例えば、後記図１４の承認画面のコメント欄４３２であるが、これに限定されるものではなく、承認アイコン４３４や却下アイコン４３５やファイル添付欄４３３であってもよい。また、「更新」とは、記憶部に記憶されている情報が変化することを意味し、例えば、後記図１４の承認画面のコメント欄４３２にコメントを入力することであるが、これに限定されるものではなく、承認アイコン４３４のクリックや却下アイコン４３５のクリック、ファイル添付欄４３３へのファイル添付であってもよい。また、図１３及び図１４に示す営業第１部１３課の課長Ｂが差し戻しアイコン４３６をクリックし、申請者Ｇが、再度、申請内容を書き加えて申請した場合も、記憶部に記憶されている申請情報が変化することから、「更新」に該当する。画面上の情報入力領域に対する更新をすることが不能な状態とは、ある画面上の情報を入力することのできる領域に情報を入力することができず、記憶部に記憶されている情報が変化することが不能な状態を意味し、例えば、承認画面のコメント欄４３２へのコメントを入力することができず、記憶部に記憶されている情報が変化することが不能な状態である。そして、このような状態となるような事象とは、社員が組織変更前の組織から当該組織に所属しなくなった事象をいい、会社の合併や事業譲渡といった事象も含む。例えば、人事情報変更情報がワークフロー情報管理装置１に入力され、人事情報記憶部５１の組織ＩＤ５１５にデータが書き加えられたときであるが、これに限定されるものではなく、人事情報記憶部５１の組織名５１６にデータが書き加えられたときなどであってもよい。

【0046】

承認権限制御部４３が、社員が旧部署で承認権限を有すると判定した場合、具体的には、社員の役職ＩＤに「Ｋ」や「Ｂ」が入力されている場合、旧組織への承認権限の有効期限の値を、例えば「２０１５／４／１０」にするように処理する。ここで、「Ｋ」は課長を、「Ｂ」は部長を意味する。旧組織への承認権限の有効期限の値は、人事情報変更情報の期日１１８の値「２０１５／４／１」に、所定の期間の値を加算することによって求められる。所定の期間の値は、図９で示される人事情報変更情報に別の領域を設けて送信してもよいし、人事情報変更情報とは別の情報として、ユーザ端末２０で入力して送信してもよい。有効期限が経過すると、承認権限は失われる。ワークフロー情報管理装置１に内蔵されている時計機能か又は外付けで時計機能を有する装置と同期させることによって、有効期限が経過したかどうか判定できる。承認権限制御部４３が、有効期限が経過したと判定すると、承認権限を「×（なし）」を意味する値に書き換える。

【0047】

図１２は、組織変更後の新組織における承認経路及び承認経路に対応する承認者を示すブロック図である。組織変更後においても、承認経路自体は変更されない。すなわち、例えば、営業第１部１１課であれば、課員が申請し、営業第１部１１課の課長が審査・承認し、営業第１部の部長が審査・承認し、経理部門へと続く。他方、承認権限については、営業第１部１１課の課長として承認権限を有するのは、新課長であるＫと旧課長であるＢである。したがって、営業第１部１１課の社員Ａが申請をした場合、１１課の新課長Ｋと旧課長Ｂの両方が承認権限を有するので、審査・承認することができる。そして、新課長Ｋか旧課長Ｂのいずれかが承認をすれば、ワークフローは、次の決裁者である部長Ｃに流れる。

【0048】

本発明の実施形態によれば、旧組織の上長が旧組織への承認権限を有する期間は、旧組織の上長、新組織の上長の両方が審査・承認をすることができる。そのため、例えば、新組織の上長が組織変更後に休暇などで不在のときであっても、旧組織の上長が審査・承認することができるので、社員の申請を迅速に処理することができる。例えば、申請者Ａが結婚するために慶弔休暇を申請した場合、新課長Ｋであっても旧課長Ｂであっても、判断が変わることはない。そのため、いずれが承認してもよい。このような場合、新課長Ｋ、旧課長Ｂの両方が承認権限を有すれば、いずれかが承認すれば迅速な処理を行うことができるのである。したがって、本発明の実施形態によれば、実際の異動と合致したワークフローを構築しつつ、より柔軟な審査・承認を行うことができる。

【0049】

また、本発明の実施形態によれば、旧組織の上長の承認権限は、所定の期間に限定される。そのため、旧組織の上長が旧組織からいつまでも解放されないといった問題は生じない。

【0050】

また、申請情報の申請項目５７５（図５を参照）には、項目内容ごとに識別子が付されている。例えば、交通費であれば、「Ａ」という識別子が付されている。申請内容について、例えば、実際に使った交通費の清算の申請といった事後報告の申請、これから出張する場合の出張申請といった事前承認を必要とする申請に分類することができる。事後報告の申請であれば、一般的には、旧組織の上長が審査・承認を行うのが適している。他方、事前承認を必要とする申請であれば、新組織の上長が審査・承認を行うのが適している。この分類とは別に、例えば、旧組織の上長であっても新組織の上長であってもどちらが審査・承認してもよい場合がある。例えば、事前承認を必要とする申請であるが、慶弔休暇の取得の申請は、どちらが審査・承認してもよい。

【0051】

項目内容に付された識別子を元に、（１）旧組織の上長が審査・承認すべき項目、（２）新組織の上長が審査・承認すべき項目、（３）どちらが審査・承認してもよい項目に自動的に振り分けてもよい。例えば、「Ａ＿交通費」とあれば、（１）に振り分け、「Ｂ＿出張申請」であれば、（２）に振り分け、「Ｑ＿慶弔休暇申請」であれば、（３）に振り分けるように設定をしてもよい。このように振り分ければ、組織変更後であっても、適切かつ迅速な審査・承認を行うことができる。もっとも、この場合には、（１）に振り分けられた項目については、旧組織の上長には、承認権限に所定の期限があることから、期限内に審査・承認が適時行われるように、アラート機能を設けてもよい。

【0052】

また、項目内容に付された識別子を元に、承認権限の有効期限を変動させてもよい。例えば、申請内容が「Ｓ＿新規顧客との取引申請」である場合、内容的に時間を要することが多い。そのため、識別子が「Ｓ」である場合には、承認権限の有効期限を「１５日間」としてもよい。具体的には、承認権限制御部４３が、申請情報記憶部５７に格納された申請データの申請項目５７５欄に識別子が「Ｓ」であるデータが格納されていると判定した場合には、人事情報変更情報に設けた別の領域に所定の期間の値に増加分を加えてもよい。例えば、人事情報変更情報に設けた別の領域に所定の期間として、１０日間が入力されていた場合には、この１０日間に対して、増加分である５日間を加算するのである。あるいは、１０日間を意味する値が入力されていた領域に１５日間を意味する値に置き換えるだけでもよい。

【0053】

図１３は、組織変更後の新組織において承認権限が重複する場合のアクセス画面の一例を示す図である。アクセス画面４２０には、営業第１部１３課へアクセスするためのアイコン４２１、営業第１部１１課へアクセスするためのアイコン４２２が表示されている。図１３に示すように、営業第１部１３課の課長Ｂは、新組織の営業第１部１３課の承認権限を有するとともに、旧組織の営業第１部１１課の承認権限も有していることがわかる。

【0054】

図１４を用いて、営業第１部１３課の課長Ｂが営業第１部１１課へアクセスするためのアイコン４２２をクリックして、営業第１部１１課へアクセスした場合について説明する。図１４は、組織変更後の新組織において承認権限が重複する場合の承認画面の一例を示す図である。課長Ｂが営業第１部１１課へアクセスすると、営業第１部１１課のワークフローを見ることができる。そして、課長の承認が必要な申請について、承認画面を開くと、図１４のような承認画面４３０が表示される。承認画面４３０には、申請情報の一部と申請内容４３１、コメント欄４３２、承認アイコン４３４、却下アイコン４３５が表示されるが、これに限定されるものではない。この承認画面を利用して、営業第１部１１課の旧課長Ｂは、新組織の営業第１部１３課の課長になった後も、所定の期間、旧組織の課員Ａの申請について、審査して、承認・却下の判断を行うことができる。この承認画面４３０は、コメントといった情報や承認や却下といった情報を入力することができる領域であるため、情報入力領域ということもできる。

【0055】

＜第２実施形態＞
本実施形態では、第１実施形態と異なり、承認経路が予め定められていない。この場合、申請者は、ある特定の範囲の社員を次の承認者として、例えば交通費の清算などの申請を行うことができる。特定の範囲は、例えば、同じ部でもよいし、同じ支社であってもよい。ここでは、特定の範囲を同じ支社であるとして説明する。ここで、Ｘ支社の社員Ａが申請をして、次承認者として、同じＸ支社の社員を選択する場合、人事情報記憶部５１にユーザごとに支社名情報（図示せず）が記憶されていることから、人事情報記憶部５１から社員Ａの所属する支社名と同じ支社名の社員を抽出して、次承認者として選択できるリストに表示してもよい。もっとも、このように申請者と同じ支社名の社員を抽出するのではなく、予め同じ支社に属する社員について、別に記憶部を設け、その記憶部から同じ支社名の社員を次承認者として選択できるリストに表示してもよい。

【0056】

次に、社員Ｋが特定の範囲であるＸ支社からその範囲以外の範囲（例えば、Ｙ支社）に異動（組織変更）した場合について説明する。例えば、社員Ｋが同じＸ支社内の営業１部１１課の課長から営業１部１３課の課長に異動したとしても、同じ支社内であるから、組織変更前後において、承認権限は異ならない。すなわち、社員Ｋには、所定期間ルールが適用されることはない。他方、組織変更によって、例えば、社員ＢがＸ支社の営業１部１３課の課長から、Ｙ支社の営業１部１２課の課長に異動したときは、同じ支社ではないことから、組織変更前後において、本来的には、承認権限は異なる。しかし、社員Ｂに、所定期間ルールが適用される結果、社員Ｂは、所定の期間、旧組織（Ｘ支社）の承認権限を有することになる。また、社員Ｂは、異動に伴い、Ｙ支社の承認権限も有することになる。

【0057】

本実施形態によれば、旧組織で承認権限を有した者が異動後も旧組織の承認権限を有する所定の期間は、旧組織で承認権限を有した者、新組織で承認権限を有する者の両方が審査・承認をすることができる。そのため、例えば、新組織で承認権限を有する者が休暇などで不在のときであっても、旧組織で承認権限を有した者が審査・承認することができるので、社員の申請を迅速に処理することができる。

【0058】

また、本実施形態によれば、旧組織で承認権限を有した者が旧組織への承認権限を有する期間は、所定の期間に限定される。そのため、旧組織で承認権限を有したものが旧組織からいつまでも解放されないといった問題は生じない。

【0059】

なお、本発明は上記の実施形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。

【符号の説明】

【0060】

１：ワークフロー情報管理装置 ２０：ユーザ端末 ２７：ネットワーク
３０：通信制御部 ４０：制御部 ４１：人事情報制御部
４３：承認権限制御部 ４５：承認経路制御部 ４７：申請情報制御部
５０：記憶部 ５１：人事情報記憶部 ５３：承認権限情報記憶部
５５：承認経路情報記憶部 ５７：申請情報記憶部
１１１：更新区分 １１２ａ：組織変更前の組織ＩＤ
１１３ａ：組織変更前の組織名 １１４ａ：組織変更前の役職ＩＤ
１１５ａ：組織変更前の役職名 １１２ｂ：組織変更後の組織ＩＤ
１１３ｂ：組織変更後の組織名 １１４ｂ：組織変更後の役職ＩＤ
１１５ｂ：組織変更後の役職名 １１６、５１１、５３１：ユーザＩＤ
１１７、５１２、５３２：氏名
１１８：期日 ４２０：アクセス画面
４２１：新組織へアクセスするためのアイコン
４２２：旧組織へアクセスするためのアイコン
４３０：承認画面 ４３１：申請内容 ４３２：コメント欄
４３３：ファイル添付欄 ４３４：承認アイコン ４３５：却下アイコン
４３６： 差し戻しアイコン ５１３、５３３：社員番号 ５１４：入社日
５１５：組織ＩＤ ５１６、５３４、５７４：組織名
５１７、５３５：役職ＩＤ ５１８：役職名 ５１９：開始日
５２０：終了日 ５２１：自宅電話番号 ５２２：自宅住所
５３６申請番号 ５３７：承認権限の有無 ５３８：有効期限
５７１：申請番号 ５７２：申請日 ５７３：申請者 ５７５：申請項目
５７７：入力データ ５７８：申請内容

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】