JP6118879B2 - 情報管理装置及びプログラム - Google Patents

Description

本発明は、情報管理装置及びプログラムに関する。より詳細には、ワークフロー制御を行う技術に関する。

オフィスにおける文書の回覧業務の効率を向上させる情報管理システムの一つとして、ワークフローシステムがある。一般にワークフロー管理システムとは、コンピュータによって電子化された申請書や通知書を予め定めた作業手順（決裁ルート）に従って集配信し、決裁処理を行うことによって、稟議・報告書・届出申請の承認手続きを電子化し、業務のスピード向上、業務効率化、内部統制強化をコンピュータシステムによって達成するものである。

従来の紙ベースでの決裁では、決裁文書を起案していたため、多くの場合、他人が起案した決裁文書を参照したり、再利用したりすることができず、様式の統一も困難であった。また、起案後は、起案者が決裁文書を決裁者に直接手渡しするなどして回覧していたため、決裁処理にも時間を要した。

企業、官庁等においては、環境保護等の観点から、業務の電子化によるペーパレス化が期待されている。現在までに文書を電子化し、ネットワーク上で回覧・決裁を行うワークフローシステムとして、複数の作業者が関わる業務の流れをあらかじめ用意しておけば、その流れにしたがって処理が進むシステムは提供されている。

しかし、決裁等を伴う業務処理は、ときに迅速性を求められたり、ときには紙ならではの処理が行われたりすることがあり、電子化が困難な部分は多い。

たとえば特許文献１には、従業員に対して出張旅費を支給する事務のような定型的な業務処理を行うシステムが記載されている。また、特許文献２には、ワークフローを登録する作業を簡易化するワークフロー案件投入方法が記載されている。

業務の効率化の観点から、より利便性の高いワークフローシステムが切望されている。

特開平１１−３４５２７０号公報 特許第３９１６１９９号

そこで、本発明は業務の効率化の観点から、より利便性の高いワークフロー制御用情報管理装置及びプログラムを提供することを目的の一とする。

また本発明は、個別に取引全般について再度報告を行わせる必要のないワークフロー制御用情報管理装置及びプログラムを提供することを目的の一とする。また、新たなワークフローを再申請する必要がないワークフロー制御用情報管理装置及びプログラムを提供することを目的の一とする。

また本発明は、要報告ワークフローを通常の申請と一括して期限管理することのできる
ワークフロー制御用情報管理装置及びプログラムを提供することを目的の一とする。

また本発明は、当初規定されたワークフローのノード以外のノードによる更新要求に対応するワークフロー制御用情報管理装置及びプログラムを提供することを目的の一とする。

また本発明は、承認者不在時における緊急の代理承認行為に対応することができ、承認が完了するまでワークフローが滞ることを低減させるワークフロー制御用情報管理装置及びプログラムを提供することを目的の一とする。

本発明の一実施形態によると、申請情報と、該申請情報に関連付けて複数個のノードが順序付けられて規定されるノード群とが記憶される記憶部と、前記ノード群に含まれるノードのうち現在更新可能なノードより前記申請情報に対する更新が確定された場合には、前記ノード群のうち次の順位に規定されるノードによる該申請情報に対する更新を可能な状態とする制御部と、を備え、前記制御部は、前記現在更新可能なノードによる更新が前記申請情報の確定を拒絶する更新である場合には、前記申請情報と前記ノード群とを関連付けたまま複製し、前記申請情報に関連付けられる新たな情報を該複製された申請情報に入力可能とすることを特徴とする情報管理装置が提供される。

本発明の一実施形態によると、コンピュータを、申請情報と、該申請情報に関連付けて複数個のノードが順序付けられて規定されるノード群とが記憶される記憶部と、前記ノード群に含まれるノードのうち現在更新可能なノードより前記申請情報に対する更新が確定された場合には、前記ノード群のうち次の順位に規定されるノードによる該申請情報に対する更新を可能な状態とする制御部と、を備え、前記制御部は、前記ノード群の終端の前記ノードによる更新が前記申請情報の確定を拒絶する更新である場合には、前記ノード群と前記申請情報とを関連付けたまま複製し、前記申請情報に関連付けられる新たな情報を該複製された申請情報に入力可能とすることを特徴とする情報管理装置として機能させるプログラムが提供される。

本発明の一実施形態によると、申請情報と、該申請情報に関連付けて複数個のノードが順序付けられて規定されるノード群とが記憶される第１記憶部と、前記ノードの属性情報が該ノードに関連付けられて各々記憶される第２記憶部と、前記ノード群に含まれないノードからの前記申請情報に対する更新要求を受けた場合には現在更新可能ノードと該更新要求をしたノードの前記属性情報を参照し、該更新要求をしたノードが前記現在更新可能なノードと同一位相の前記属性情報を持つ場合には、該更新要求をしたノードを該現在更新可能なノードに変更して前記申請情報を更新可能な状態とする制御部と、を備える情報管理装置が提供される。

本発明の一実施形態によると、申請情報と、該申請情報に関連付けて複数個のノードが順序付けられて規定されるノード群とが記憶される第１記憶部と、前記ノードの属性情報が該ノードに関連付けられて各々記憶される第２記憶部と、前記ノード群に含まれないノードから前記ノード群の構成ノードとするよう要求を受けた場合には現在更新可能ノードと該要求をしたノードの前記属性情報を参照し、該要求をしたノードが予め前記ノード群に規定されたノードと同一位相の前記属性情報を持つ場合には、該要求をしたノードを現在更新可能なノードに変更して前記ノード群を再構成する制御部と、を備える情報管理装置が提供される。

本発明の一実施形態によると、コンピュータを、申請情報と、該申請情報に関する複数個のノードが順序付けられて規定されるノード群とが記憶される第１記憶部と、前記ノードの属性情報が該ノードに関連付けられて各々記憶される第２記憶部と、前記ノード群に
含まれないノードからの前記申請情報に対する更新要求を受けた場合には現在更新可能ノードと該更新要求をしたノードの前記属性情報を参照し、該更新要求をしたノードが現在更新可能なノードと同一位相の前記属性情報を持つ場合には、該現在更新可能なノードを該更新要求をしたノードに変更して前記申請情報を更新可能な状態とする制御部と、を備える情報管理装置として機能させるプログラムが提供される。

本発明の一実施形態によると、コンピュータを、申請情報と、該申請情報に関する複数個のノードが順序付けられて規定されるノード群とが記憶される第１記憶部と、前記ノードの属性情報が該ノードに関連付けられて各々記憶される第２記憶部と、前記ノード群に含まれないノードから前記ノード群の構成ノードとするよう要求を受けた場合には予め前記ノード群に規定されたノードと該要求をしたノードの前記属性情報を参照し、該要求をしたノードが前記予め前記ノード群に規定されたノードと同一位相の前記属性情報を持つ場合には、現在更新可能なノードを該要求をしたノードに変更する制御部と、を備える情報管理装置として機能させるプログラムが提供される。

本発明の一実施形態によれば、より利便性の高い情報管理装置及びプログラムを提供することができる。

本発明の一実施形態によれば、個別に取引全般について再度報告を行わせる必要のない情報管理装置及びプログラムを提供することができる。また、本発明の一実施形態によれば、新たなワークフローを再申請する必要がない情報管理装置及びプログラムを提供することができる。

本発明の一実施形態によれば、要報告ワークフローを通常の申請と一括して期限管理することのできる情報管理装置及びプログラムを提供することができる。

本発明の一実施形態によれば、当初規定されたワークフローのノード以外のノードによる更新要求に対応する情報管理装置及びプログラムを提供することができる。

本発明の一実施形態によれば、承認者不在時における緊急の代理承認行為に対応することができ、承認が完了するまでワークフローが滞ることを低減させる情報管理装置及びプログラムを提供することができる。

本発明の一実施形態に係る情報管理装置の構成図である。 本発明の一実施形態に係るワークフローテーブル２００のデータ構成図である。 本発明の一実施形態に係る更新権限情報記憶部５３内のデータ構成図である。 本発明の一実施形態に係る情報管理方法のフローチャートである。 本発明の一実施形態に係るユーザ端末２０ａの画面情報の模式図である。 本発明の一実施形態に係るユーザ端末２０ｂの画面情報の模式図である。 本発明の一実施形態に係るユーザ端末２０ｂの画面情報の模式図である。 本発明の一実施形態に係るワークフローテーブル２０１のデータ構成図である。 本発明の一実施形態に係る情報管理装置１１０の構成図である。 本発明の一実施形態に係る属性情報記憶部１５９内のデータ構成図である。 本発明の一実施形態に係る情報管理方法のフローチャートである。 本発明の一実施形態に係るノード群を示す構成図である。 本発明の一実施形態に係るノード群を示す構成図である。 本発明の一実施形態に係る情報管理方法のフローチャートである。

以下、本発明の一実施形態における情報管理装置及びプログラムについて、図面を参照しながら詳細に説明する。以下に示す実施形態は本発明の実施形態の一例であって、本発明はこれらの実施形態に限定されるものではない。

（第１実施形態）
本発明の第１実施形態における情報管理装置及びプログラムについて、図面を参照しながら詳細に説明する。まず、図１は本実施形態に係る情報管理装置の構成を示す図である。

前提として、ワークフローシステムにおいて、ある申請について申請者が決裁者に対して決裁（承認）を要求した場合において、申請者の申請に対して承認を与えつつ、同申請内容について、一定の期限を定めて同申請内容に対応する報告義務を課す場合がある。本明細書では、このような報告義務を、「要報告」と言う。

しかし、一般的に、ワークフローは、そもそもネットワーク上で単に回覧・決裁を行うものであり、従来技術においてワークフローを承認すると、そのフローは消えてしまっていた。したがって、ワークフローシステムでは、一定の報告期限を定め、同申請の内容報告義務を課すことができないという問題がある。個別に取引全般について再度報告を行わせるのでは、ワークフローで一括管理できず、不便である。さらに、申請者に対してワークフローで再度「要報告となった件について報告する」という申請をさせなければならないのは不便である。

ここで、特許文献１は、各ワークフローの業務ごとに特化したアプリケーションプログラムを作成することによるコスト増大を防ぐべく、ワークフローへ投入するために必要な情報を格納するＷＦ投入情報記憶手段と、アプリケーションが固有に持つデータを格納するＡＰ情報記憶手段と、ＷＦ投入情報とＡＰ情報とを関連づけそれらを補足するための案件属性マップ定義情報記憶手段を用意する。そして、これらの情報に基づいて、どのような業務に対しても、自動的にワークフローシステムに案件を投入する汎用的な案件自動投入装置を用いて、自動的な案件投入を行なう、という発明を開示する。しかし、特許文献１では、あくまで業務ごとに案件投入部分を作らなくても自動的に案件を投入することが可能となるに過ぎない。再度報告をする場合には、再報告用ワークフローを立てねばならないことに変わりはなく、面倒である。

特許文献２には、一実施形態として、「旅行命令書の入力内容は、旅行命令権者１５の承認がないと変更ができないようにしているので、旅行命令権者１５の承認後は、経理担当でも勝手に編集できないようにするため、編集権限を上述したマシンからサーバ１に変更することにしている。この場合、旅行命令書の入力内容に不備があれば、上記承認処理プログラムにおいて否認されるので、出張者１１に再申請してもらうことになる。」との構成が開示されている。しかし、特許文献２では再申請が必要となってしまい面倒である。

［情報管理装置］
図１を参照して本発明の一実施形態に係る情報管理装置１０を説明する。情報管理装置１０には、通信制御部３０、制御部４０、記憶部５０が存在する。情報管理装置１０は、ユーザ端末２０ａ、２０ｂ、２０ｃに、ネットワーク２７を介して接続され、相互に通信
可能となっている。なお、ネットワーク２７としては、有線無線を問わない接続方法によるインターネットや、イーサネット（登録商標）等を利用したローカルエリアネットワーク等の公知のネットワーク接続方法を用いることができる。

制御部４０には、承認経路情報制御部４５と、申請情報制御部４７とが含まれる。図１では、これに加えてフラグ情報制御部４１と、更新権限制御部４３とが記載されているが、これは必須の構成ではない。「〜制御部」として説明するものは、夫々ＣＰＵによって対応するプログラムが読みだされ、ＣＰＵによって実行される各機能を意味する。

記憶部５０には、承認経路情報記憶部５５と、申請情報記憶部５７とが含まれる。図１では、これに加えてフラグ情報記憶部５１と、更新権限情報記憶部５３とが記載されているが、これは必須の構成ではない。

申請情報記憶部５７に、ユーザ端末２０ａの画面上の情報入力領域から入力された申請情報がネットワーク２７を通じ情報管理装置１０の通信制御部に送信され、ＣＰＵ（図示省略）によって記憶される。また、承認経路情報記憶部５５に、入力された情報に関連付けられた承認経路情報がＣＰＵ（図示省略）によって記憶される。

ここで、申請情報とは、申請者が決裁を要求する文書の電子的な情報である。申請情報には、申請者の社員番号、申請の種類を意味する申請種別、申請者が入力するテキストデータである申請内容が含まれるが、これに限定されず、たとえば申請時に添付する領収書や契約書といったファイルが含まれていてもよい。

承認経路情報とは、各申請情報に対応する複数の決裁者の順序を意味する。申請経路情報は、申請情報ごとに手動で定められてもよいが、社員名簿や更新権限情報といったデータベースから読みだされた情報から決裁権限を判定して定められてもよいものである。このように、申請情報に関連づけられて、複数の決裁者の順序である承認経路情報が承認経路情報記憶部５５に記憶されている。

ここで、申請者である課員が申請をして、決裁者である課長が審査・承認し、次に、次順位の決裁者である部長が審査・承認する構造をツリー構造とみると、課員、課長及び部長は、ツリー構造の個々の要素と見ることができる。そのため、課員、課長や部長といった各社員は、それぞれ「ノード」、と呼ぶことができる。また、複数のノードの順序が規定されている情報を、「ノード群」と呼ぶこともできる。

フラグ情報は、前述した要報告の義務の有無を判別できるようにするためにフラグ情報制御部が、付すものである。本実施形態では、要報告の義務が付されていないワークフローである場合には０の符号が、要報告の義務が付されている場合には１の符号が付される。フラグ情報制御部は、上記符号から要報告の義務が存在するかどうかを判別し、要報告の義務が存在する場合には、要報告の義務が存在することを、ネットワークを通じて接続されるユーザ端末２０の画面に表示させることができる。更新権限情報については後述する。

［ユーザ端末］
ユーザ端末２０は、ユーザが入出力するためのクライアント端末であり、パーソナルコンピュータやワークステーション等にワークフローを利用するためのアプリケーション又はＷｅｂ環境と、通信機能と、演算機能と、を備えた情報処理端末装置等が挙げられる。また、情報管理装置１０が提供する画面を表示する表示制御機能としてブラウザを備え、ＣＰＵ、メモリ及び情報管理装置１０との間の通信制御を遂行する通信制御部等を含む。さらにキーボード等の操作入力装置及びディスプレイ等の表示装置を備えることができる。

ユーザ端末の画面上には、ワークフローを利用するためのアプリケーション又はＷｅｂ環境によって、申請情報等を入力するための入力フィールドが展開される。申請者は操作入力装置を用いて、入力フィールドに所定事項を記入することができる。たとえば、社員番号として「440440」、決裁種別として「交通費」、申請情報として「交通費は10万円です。よろしくお願いします。」、期限として「４月１０日」を入力することができる。

［情報の構成］
図２〜３を使用して、ワークフロー情報の構成等について説明する。

［ワークフローテーブル］
図２は、ワークフローテーブル２００を示したものである。ワークフローテーブル２００は、現在更新可能ノード（表中の「現在」）、ステータス状況（表中の「状況」）、当該申請に関する上長（決裁者）の経路（表中の「決裁経路情報」）、申請者の氏名（表中の「申請者」）、申請情報の内容（表中の「申請内容」）、要報告の義務が付されているかを判別するための情報（表中の「フラグ」）、複製によって生成されたワークフローである場合に、その親がどのようなワークフローであるのかを示す親データ（表中の「親」）を記憶するテーブル領域となっている。フローＩＤ１０１は、現在更新可能ノードは部長であり、部長の決裁待ちになっている。状況欄には課長が既に承認の決裁をしたことを示す「課長〇」とのデータが書き込まれている。他方、フローＩＤ１０２は、現在更新可能ノードは課長で、まだ誰も決裁していないので、状況は空欄になっている。

なお、本明細書において「更新」とは、記憶部に記憶されている情報が変化することを意味する。たとえば、更新の一態様として、申請情報の改変、申請情報の承認、申請情報の却下、申請情報の条件付き承認、申請情報の条件付き却下等を含む。

そして、現在更新可能ノードとは、その時点において、申請内容に対する更新をすることが可能なノードを意味する。たとえば、課長が既に承認の決裁をした場合で、次順位の決裁者が部長である場合には、現在更新可能ノードは部長である。

フローＩＤ１０１で特定されるワークフローの決裁者は、課長、部長、社長が決裁者である。したがって、決裁経路情報として課長、部長、社長が記憶されている。申請者氏名は、申請者欄に記憶されているＡであり、申請情報の内容は、「新件をＸ社に発注します」とある。フラグには０が記憶されているから、要報告の義務が課されていないワークフローであることが分かる。また、親の欄に記憶がないことから、親ワークフローが存在しないこと、複製によって生成されたものではないこと等がわかる。本実施形態ではフラグは要報告事項があるかどうかを示す２進数のデータであるが、かならずしも２進数に限定されるものではない。また、期限欄にはワークフローの期限が記憶される。原則として、ワークフローの期限とは、当該ワークフローの処理の期限を意味する。ワークフローの処理期限とは、当該ワークフローが予定されていたすべての決裁者の決裁を得る期限である。他方、当該ワークフローに要報告の義務が課せられている場合には、ワークフローの期限とは、報告の期限を意味する。

［更新権限情報記憶部 更新権限情報］
図３を用いて、更新権限情報記憶部５３内のデータ構成を説明する。図３は、図１に示した更新権限情報記憶部内のデータ構成の一例を示す図である。更新権限情報には、ユーザＩＤ、氏名、社員番号、役職、更新可能文書レベル等が含まれるが、これらに限定されるものではない。更新可能文書レベルとは、ある決裁者が申請情報を決済することのできる文書のレベル（文書レベル）を数値化したものである。文書レベルは、たとえば機密性
が高い文書を５、機密性が低い情報を１として、５段階で表すことができ、当該文書の機密レベルを数値化したものである。

［動作の流れ］
図４は本実施形態における決裁手順のフローチャートである。また、図５〜７は、ユーザ端末２０ａ、ユーザ端末２０ｂの画面情報の模式図である、これを図番順に追って見ていくことで、ワークフローの使用方法が分かるようになっている。また、図８〜９は、本実施形態において先に説明したワークフローテーブル２００の内容がどのように変更されるかを説明するものである。

まず、図５では、ユーザ端末２０ａの画面に表示されている入力フィールドが示されている。入力フィールドには、申請者の社員番号を入力する領域と、決裁種別を選択する領域と、申請内容を入力する領域とが存在する。申請者は、ユーザ端末２０ａに接続された操作入力装置を使用して、社員番号を入力し、決裁種別を選択し、ユーザ端末２０ａの画面上に展開された入力フィールドに申請内容を入力する。

ここでは、フローＩＤ１０１を例にとる。申請者はＡ、内容は「新件をＸ社に発注します。」である。

申請者によって入力された申請内容は、ネットワーク２７を通じ情報管理装置１０の通信制御部に送信され、制御部４０がデータを処理した上で、記憶部５０の申請情報記憶部５７に書き込む。

記憶部５０に記憶された申請情報は、次順位のノードが使用するユーザ端末２０ｂの要求によって、ユーザ端末２０ｂの表示領域に表示される。

制御部４０は、次順位のノードによる更新権限をワークフローに応じてワークフローテーブル２００で確認し、権限が存在すると認められる場合には、更新権限が認められる。

図４のフローチャートは、更新権限が認められたユーザ（上長）が決裁をする際のフローチャートである。このフローチャートは、決裁承認画面（図７）が表示されることを引き金として開始する。

上長は図７に示す表示された申請種別の申請内容を確認して承認するかどうかを決める。承認ボタンが押されず却下ボタンが押されると（Ｓ１０１；ＮＯ）、却下となる（Ｓ１０８）。要報告承認ボタンが押されると（Ｓ１０１；ＹＥＳ、Ｓ１０２；ＹＥＳ）、回ってきたワークフローの申請情報及び承認経路情報を複製し、さらに、フラグ情報制御部４１は複製されたワークフローにフラグを付加する（Ｓ１０３）。そして、要報告となったため複製されたワークフローは申請者Ａに差し戻される（Ｓ１０４）。単純承認ボタンが押されると（Ｓ１０１；ＹＥＳ、Ｓ１０２；ＮＯ）、次の決裁者がいるかどうかをワークフローテーブル２００で確認し、いなければ（Ｓ１０５；ＮＯ）、ワークフローは全体として承認されて確定されるし、次の決裁者がいれば（Ｓ１０５；ＹＥＳ）、次の決裁者に回る。

本実施形態では、ノード群の終端である現在の更新可能ノードは、「要報告」ボタンを押すことで申請情報の確定を拒絶する更新をすることができる。本実施形態では、要報告は「要報告付承認」としたが、「要報告付却下」として構成してもよい。

なお、要報告の際には、要報告付き承認を押した上長は、「Ｘ社の資産状況と評判を報告すること。」といったメッセージを新たな情報として画面上の入力フィールドから記入す
ることができる。記入された新たな情報は、申請情報制御部４７によって、申請情報記憶部５７に記憶される。ワークフローテーブル２００上では、申請情報欄に記憶されることになる。もっとも、これに限定されず、たとえばワークフローテーブル２００に「新たな情報」という欄を設けて、この箇所に記憶するようにしてもよい。

また、要報告の際には、要報告の義務の期限を設定することができる。設定された期限は、申請情報制御部４７によって申請情報記憶部５７に記憶される。ワークフローテーブル２００の欄に記載される（図８）。図８では報告期限は１２月１４日となっている。

申請情報及び承認経路情報が複製されるときには、申請情報と承認経路情報とが関連付けられたまま複製される。そうすると、更新可能ノードの同一性を保持したまま当該ワークフローが複製されることになる。したがって、再度申請者がワークフロー作成を申請することなく、決裁者の「要報告付承認」又は「要報告付却下」によって、自動的に更新可能ノードの同一性を保持したまま要報告付ワークフローを生成できる。

本発明の一実施形態によれば、より利便性の高い情報管理装置及びプログラムを提供することができる。

本発明の一実施形態によれば、個別に取引全般について再度報告を行わせる必要のない情報管理装置及びプログラムを提供することができる。また、本発明の一実施形態によれば、新たなワークフローを再申請する必要がない情報管理装置及びプログラムを提供することができる。

本発明の一実施形態によれば、要報告ワークフローを通常の申請と一括して期限管理することのできる情報管理装置及びプログラムを提供することができる。

（第２実施形態）
本発明の一実施形態に係る情報管理装置について、図９〜１４を用いて説明を行う。本実施形態の特徴は、当初規定されていなかった更新可能ノードによる承認及び却下を可能とする点にある。第２実施形態には大別して２つのパターンがある。１つは、あるノードが自らを更新可能ノードとするように要求（更新要求）するパターンである。これは図１１を使用して説明する。もう１つは、あるノードが自らをノード群に入れるよう要求（決裁権限を付与するように要求）するパターンである。これは図１４を使用して説明する。

第２実施形態における第１の記憶部１５０と制御部１４０とは、それぞれ第１実施形態の記憶部５０と制御部４０と、共通するため、詳細な説明は省略する。

本実施形態では、第１の記憶部１５０のほかに、各ノードの属性情報が記憶される第２の記憶部である、属性情報記憶部１５９が存在してもよい。属性情報は、たとえば役職が挙げられるが、これに限定されず、専門分野、勤続年数、及び会社への貢献度等の、能力の指標となりうる情報（属性レベル）であってもよい。能力指標情報の計算方法としては、たとえば役職スコア、専門分野スコア、勤続年数スコア、会社への貢献度スコア等の各関係スコアに、一定の係数を乗じて加算することによって算出することができる。

［属性情報記憶部内のデータ構成］
図１０を用いて、属性情報記憶部１５９内のデータ構成を説明する。図１０は、図９に示した属性情報記憶部１５９内のデータ構成の一例を示す図である。

属性情報は、例えば、図１０のテーブルに示すように、ユーザＩＤ、氏名、役職、属性レベル、社員番号が含まれるが、これらに限定されるものではない。

本発明の第２実施形態においては、当初規定されていないノードによる決裁を可能とするために、当初規定されていないノードによる更新要求又は決裁権限付与の要求があった場合に、属性情報を参照し、属性情報が同一位相である場合に、ノード群の内容を変更することによって、当該申請に対する更新を許可し、又は決裁権限を付与する。ここで、同一位相であるとは、同一の役職である場合が挙げられる。たとえば、図１０においては、ユーザＩＤ２の課長Ｂと、ユーザＩＤ５の課長Ｙとは、いずれも役職が課長である点で共通するから、同一位相の属性情報を有するといえる。

本実施形態のうち、更新要求に関するフローチャートを図１１に示す。図１１のフローチャートは、ノード群に含まれないノードからの更新要求を引き金として開始する。Ｓ２０１は、ノード群の構成ノードかどうかを判定するステップである。ノード群の構成ノードである場合（Ｓ２０１；ＹＥＳ）の場合には、更新要求により申請が更新されるとなる（Ｓ２０５）。Ｓ２０２は、現在更新可能ノードと同一位相かどうかを判定するステップである。ノード群の構成ノードでない場合（Ｓ２０１；ＮＯ）であって、現在更新可能ノードと同一位相ではない場合（Ｓ２０２；ＮＯ）にはエラーとなる。ノード群の構成ノードでない場合（Ｓ２０１；ＮＯ）であって、現在更新可能ノードと同一位相である場合（Ｓ２０２；ＹＥＳ）には更新要求をしたノードが現在更新可能ノードになる。具体的には、図１２では、現在更新可能ノードは課長Ｂであり、ノード群には課長Ｂ、部長Ｃが規定されている。図１０において示し、上記ですでに説明した通り、課長Ｂと課長Ｙは同一位相である。したがって、課長Ｙが更新要求を行ったとすると、ノード群の構成ノードでない場合（Ｓ２０１；ＮＯ）であって、現在更新可能ノードと同一位相である場合（Ｓ２０２；ＹＥＳ）に当たるから、あらかじめノード群に規定されていた課長Ｂは課長Ｙに変更され、更新可能となる。変更される前後のノード群を示すのが、図１２である。課長Ｂ、部長Ｃというノード群２８０が、課長Ｙ、部長Ｃというノード群２８２に変更されていることが分かる。

同一位相の属性情報についての変形例として、交換を要求するノードである要求ノードの属性レベルが、被要求ノードの属性レベルと同じかそれよりも高い場合も、同一位相の属性情報を有すると判断することもできる。たとえば、ユーザＩＤ２の課長Ｂと、ユーザＩＤ６の次長Ｗは、課長Ｂの属性レベルが３で、次長Ｗの属性レベルが４である。そうすると、課長Ｂが現在更新可能ノード又はあらかじめ規定されたノード群に含まれるノードである場合に、次長Ｗが交換を要求した場合、交換することができる（図１３）。図１３では、課長Ｂ、部長Ｃというノード群２８０が、次長Ｗ、部長Ｃというノード群２８４に変更されていることが分かる。

他方、次長Ｗが現在更新可能ノード又はあらかじめ規定されたノード群に含まれるノードである場合に、課長Ｂが交換を要求したとしても、属性レベル３は属性レベル４よりも小さいから交換をすることはできない。

本実施形態のもう１つのパターンである、あるノードが自らをノード群に入れるよう要求（決裁権限を付与するように要求）するパターン本実施形態のうち、決裁権限付与の要求に関するフローチャートを図１４に示す。図１４のフローチャートは、ノード群に含まれないノードからの決裁権限付与の要求を引き金として開始する。Ｓ３０１は、ノード群の構成ノードかどうかを判定するステップである。ノード群の構成ノードである場合（Ｓ３０１；ＹＥＳ）には、決裁権限付与の要求はエラーとなる（Ｓ３０５）。Ｓ３０２は、現在更新可能ノードと同一位相かどうかを判定するステップである。ノード群の構成ノードでない場合（Ｓ３０１；ＮＯ）であって、現在更新可能ノードと同一位相ではない場合（Ｓ３０２；ＮＯ）にはエラーとなる。ノード群の構成ノードでない場合（Ｓ３０１；ＮＯ）であって、現在更新可能ノードと同一位相である場合（Ｓ３０２；ＹＥＳ）には決裁
権限付与の要求をしたノードがノード群の構成ノードになる。

本発明の一実施形態によれば、より利便性の高いワークフロー制御用情報管理装置及びプログラムを提供することができる。

また本発明の一実施形態によれば、当初規定されたワークフローのノード以外のノードによる更新要求に対応するワークフロー制御用情報管理装置及びプログラムを提供することができる。

また本発明の一実施形態によれば、承認者不在時における緊急の代理承認行為に対応することができ、承認が完了するまでワークフローが滞ることを低減させるワークフロー制御用情報管理装置及びプログラムを提供することを目的の一とする。

１０：情報管理装置
２０：ユーザ端末
２７：ネットワーク
３０：通信制御部
４０：制御部
４１：フラグ情報制御部
４３：更新権限制御部
４５：承認経路情報制御部
４７：申請情報制御部
５０：記憶部
５１：フラグ情報記憶部
５３：更新権限情報記憶部
５５：承認経路情報記憶部
５７：申請情報記憶部
１１０：情報管理装置
１４０：制御部
１４１：フラグ情報制御部
１４３：更新権限制御部
１４５：承認経路情報制御部
１４７：申請情報制御部
１４９：属性情報制御部
１５０：記憶部
１５１：フラグ情報記憶部
１５３：更新権限情報記憶部
１５５：承認経路情報記憶部
１５７：申請情報記憶部
１５９：属性情報記憶部
２００、２０１：ワークフローテーブル
２８０、２８２、２８４：ノード群

Claims (2)

1. 記憶部に記憶されている情報と、該情報に関連付けて複数個の更新可能ノードが記憶される第１記憶部と、
   前記更新可能ノードの属性情報が該更新可能ノードに関連付けられて各々記憶される第２記憶部と、
   前記情報に関連付けて記憶されている更新可能ノードに含まれない更新可能ノードからの前記情報に対する更新要求を受けた場合には、現在更新可能ノードと該更新要求をしたノードの前記属性情報を参照し、該更新要求をしたノードが前記現在更新可能なノードと同一位相の属性を持つ場合には、該要求をしたノードを前記情報を更新可能な状態とする制御部と、
   を備える情報管理装置。
2. コンピュータを、
   記憶部に記憶されている情報と、該情報に関連付けて複数個の更新可能ノードが記憶される第１記憶部と、
   前記更新可能ノードの属性情報が該更新可能ノードに関連付けられて各々記憶される第２記憶部と、
   前記情報に関連付けて記憶されている更新可能ノードに含まれない更新可能ノードからの前記情報に対する更新要求を受けた場合には、現在更新可能ノードと該更新要求をしたノードの前記属性情報を参照し、該更新要求をしたノードが前記現在更新可能なノードと同一位相の属性を持つ場合には、該要求をしたノードを前記情報を更新可能な状態とする制御部と、
   を備える情報管理装置として機能させるプログラム。
   

Images