(57)【要約】【課題】より使い勝手の良いワークフローシステムを提供する【解決手段】本発明の一実施形態に係る情報管理装置は、レコードに対して更新処理要求が可能なノードが順序付けられて規定される記憶部と、前記記憶部に規定される順序に従って前記ノードの更新処理要求権限を移転させる権限移転部と、複数の前記レコードを相互に関連付ける関連付部と、前記関連付部によって相互に関連付けられた複数のレコードのうちの１個のレコードに対する、前記ノードによる更新処理要求により、前記相互に関連付けられた複数のレコードの全てに対して更新処理をする更新処理部と、を備えてもよい。【選択図】図１
2017072906.tif 000002
【特許請求の範囲】
【請求項１】
レコードに対して更新処理要求が可能なノードが順序付けられて規定される記憶部と、
前記記憶部に規定される順序に従って前記ノードの更新処理要求権限を移転させる権限移転部と、
複数の前記レコードを相互に関連付ける関連付部と、
前記関連付部によって相互に関連付けられた複数のレコードのうちの１個のレコードに対する、前記ノードによる更新処理要求により、前記相互に関連付けられた複数のレコードの全てに対して更新処理をする更新処理部と、
を備える情報管理装置。
【請求項２】
前記関連付部は、前記ノードによる関連付け命令によって、複数の前記レコードを相互に関連付けることを特徴とする請求項１に記載の情報管理装置。
【請求項３】
前記関連付部によって相互に関連付けられた複数のレコードの関連付けを解消する関連付解消部をさらに備えることを特徴とする請求項１に記載の情報管理装置。
【請求項４】
前記関連付解消部は、前記ノードによる関連付解消命令によって、前記関連付部によって相互に関連付けられた複数のレコードの関連付けを解消することを特徴とする請求項３に記載の情報管理装置。
【請求項５】
前記関連付解消部は、前記更新処理部における更新処理がされた後に、前記複数のレコードの関連付けを解消し、
前記記憶部は、前記関連付けが解消された個別のレコードをそれぞれ記憶することを特徴とする請求項３に記載の情報管理装置。
【請求項６】
複数の前記レコードを相互に関連付ける際に、関連付ける該複数のレコードを一意に特定する識別子を生成する識別子生成部をさらに備える、請求項１に記載の情報管理装置。
【請求項７】
前記識別子は、前記複数のレコードが相互に関連付けられた時刻と前記ノードの識別子とに基づいて生成される請求項６に記載の情報管理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワークフロー情報管理装置に関する。
【背景技術】
【０００２】
会社などの組織においては、例えば、ある社員が出張を希望する場合には、その社員は、出張前に、出張申請、出張にかかる交通費の申請、出張先との接待交際費の申請などをして、出張後には、出張報告、実際にかかった交通費や接待交際費の報告などをするのが一般的である。また、その出張が成功して、新規に顧客を獲得できることになる場合には、新規顧客の登録申請をすることもある。このような申請や報告をする社員は、自身が所属する部門の上長に、これらの申請や報告をするのが一般的である。その後、所定の経路（審査・承認経路）を経て最終的に総務や管理部門の承認を得て、手続きが完了することになる。ここでは、わかりやすさの観点から、会社を用いて説明するが、組織は会社に限られるものではなく、公共団体などであってもよい。
【０００３】
このような申請や報告は、紙媒体で行われることもあるものの、近年のコンピュータ技術の発展に伴って、コンピュータを用いて、システム上で行われることもある。このような申請や報告の提出経路をシステム上で実現するものとして、いわゆるワークフローシステムが知られている。
【０００４】
ところで、ワークフローシステムでは、上記のような申請や報告が個別になされ、審査・承認をする上長は一つ一つ個別に審査・承認をする必要があることから、作業が煩雑であるという問題があった。このような問題を解決するために、特許文献１では、承認対象の文書データに認証情報を付加して承認後の文書データを生成し、認証情報が付加された複数の文書データを合成した一括承認用データを形成した上で表示した後にその一括承認用データ全体に対する認証情報を付加することによって、複数案件の電子文書の一括した閲覧及び承認を行うことが可能となる技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−１３２７５９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来技術では、図１０に示すように、個々の電子文書が承認者の元に回覧されて初めて一括承認用データに纏められたり、個々の電子文書を一括した上で承認した後の文書データを新しい文書データとして文書テーブルに格納されたりするなど使い勝手が悪いという問題がある。
【０００７】
本発明は、上記のような従来技術に伴う課題を解決しようとするものであって、その目的とするところは、より使い勝手の良いワークフローシステムを提供するところにある。
【課題を解決するための手段】
【０００８】
本発明の一実施形態によると、レコードに対して更新処理要求が可能なノードが順序付けられて規定される記憶部と、前記記憶部に規定される順序に従って前記ノードの更新処理要求権限を移転させる権限移転部と、複数の前記レコードを相互に関連付ける関連付部と、前記関連付部によって相互に関連付けられた複数のレコードのうちの１個のレコードに対する、前記ノードによる更新処理要求により、前記相互に関連付けられた複数のレコードの全てに対して更新処理をする更新処理部と、を備える情報管理装置を提供することができる。
【０００９】
前記関連付部は、前記ノードによる関連付け命令によって、複数の前記レコードを相互に関連付けてもよい。
【００１０】
前記関連付部によって相互に関連付けられた複数のレコードの関連付けを解消する関連付解消部をさらに備える情報管理装置が提供されてもよい。
【００１１】
前記関連付解消部は、前記ノードによる関連付解消命令によって、前記関連付部によって相互に関連付けられた複数のレコードの関連付けを解消してもよい。
【００１２】
前記関連付解消部は、前記更新処理部における更新処理がされた後に、前記複数のレコードの関連付けを解消し、前記記憶部は、前記関連付けが解消された個別のレコードをそれぞれ記憶してもよい。
【００１３】
複数の前記レコードを相互に関連付ける際に、関連付ける該複数のレコードを一意に特定する識別子を生成する識別子生成部をさらに備える情報管理装置が提供されてもよい。
【００１４】
前記識別子は、前記複数のレコードが相互に関連付けられた時刻と前記ノードの識別子とに基づいて生成されてもよい。
【発明の効果】
【００１５】
本発明によれば、より使い勝手の良いワークフローシステムを提供することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態に係る情報管理装置の構成の一例を示すブロック図である。
【図２】図１に示した承認経路情報記憶部内のデータ構成の一例を示す図である。
【図３】図１に示した申請情報記憶部内のデータ構成の一例を示す図である。
【図４】本発明の一実施形態に係る複数の申請情報のまとめ方を示す概略図である。
【図５】本発明の一実施形態に係る複数の申請書類の回付セットの設定・解除をする一覧画面の一例を示す図である。
【図６】本発明の一実施形態に係る回付セットの最適化を説明するための概略図である。
【図７】本発明の一実施形態に係る回付セットの最適化を説明するためのフローチャート図である。
【図８】本発明の一実施形態に係る複数の申請書類の回付セットの解除ができる画面の一例を示す図である。
【図９】本発明の一実施形態に係る情報管理装置の構成の一例を示すブロック図である。
【図１０】従来の文書承認システムの概要を示す図である。
【発明を実施するための形態】
【００１７】
以下、本発明の一実施形態について、図面を参照しながら詳細に説明する。以下に示す実施形態は本発明の実施形態の一例であって、本発明はこれらの実施形態に限定されるものではない。なお、本実施形態で参照する図面において、同一部分または同様な機能を有する部分には同一の符号または類似の符号（数字の後にＡ、Ｂなどを付しただけの符号）を付し、その繰り返しの説明は省略する場合がある。また、「〜記憶部」に格納されるデータの値は、実際には「０」「１」であっても、わかりやすさの観点から、データが意味する内容として表現する。
【００１８】
＜第１実施形態＞
［情報管理装置の構成］
図１を用いて、情報管理装置１の概要を説明する。図１は、本発明の一実施形態に係る情報管理装置の構成の一例を示すブロック図である。情報管理装置１は、通信制御部３０、制御部４０及び記憶部５０を含む。情報管理装置１は、接続するユーザ端末２０ａ、２０ｂ及び２０ｃそれぞれがネットワーク２７を介して接続する。なお、ユーザ端末の区別が不要な場合には、「ユーザ端末２０」と表記する。ユーザ端末２０は、申請者が使用する場合には、申請者端末として機能し、承認者が使用する場合には、承認者端末として機能する。情報管理装置１は、接続するユーザ端末２０（申請者端末）の申請者に対して所定のワークフローに基づく申請機能を提供し、ユーザ端末２０（承認者端末）の承認者に申請者からの申請に対する承認機能を提供する。
【００１９】
ここで、ネットワーク２７は、例えば、ＬＡＮ（ローカルエリアネットワーク）やインターネット等のネットワークであり、無線／有線回線、専用回線等を問わず、ユーザ端末２０が情報管理装置１に接続可能なネットワーク環境が適用される。
【００２０】
また、ユーザ端末２０は、多機能携帯電話、携帯電話やＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）等の移動通信端末装置、パーソナルコンピュータなどの通信機能及び演算機能を備えた情報処理端末装置等が含まれる。また、情報管理装置１が提供する画面を表示する表示制御機能としてブラウザを備え、ＣＰＵ、メモリ及びワークフロー情報管理装置１との間の通信制御を遂行する通信制御部３０等を含む。さらに、マウスやキーボード、タッチパネル等の操作入力装置及び表示装置を備えることができる。
【００２１】
記憶部５０は、人事情報記憶部５１、承認経路情報記憶部５５及び申請情報記憶部５７を含む。
【００２２】
［人事情報記憶部内のデータ構成］
人事情報記憶部５１内のデータ構成を説明する。ここで、人事情報とは、例えば、会社などの組織を構成する構成員の所属や役職などを示す情報である。また、会社の構成員は正社員であっても、パート従業員であっても、派遣社員であってもよく、制限はない。社員には所属や役職などに応じた権限が認められる。例えば、課長には、課員の申請した交通費清算の決裁権限が認められたり、総務部に所属する部員は、社員が社外秘の資料を社外に持ち出す際の持ち出し申請の承認をする権限が認められたりする。また、この権限が認められる有効期間は、基本的には、社員が所属する部署の役職に就いている期間となる。
【００２３】
人事情報は、例えば、ユーザＩＤ、氏名、社員番号、入社日、組織ＩＤ、組織名（「部署」ということもある。）、役職ＩＤ、役職名、開始日、終了日、自宅電話番号及び自宅住所などを含むが、これらに限定されるものではなく、支社名などを含んでもよい。ここで、開始日とは、当該組織の当該役職を開始した日のことを意味し、終了日とは、当該組織の当該役職を終了した日のことを意味する。
【００２４】
［承認経路情報記憶部内のデータ構成］
図２を用いて、承認経路情報記憶部５５内のデータ構成を説明する。図２は、図１に示した承認経路情報記憶部内のデータ構成の一例を示す図である。この例では、営業第１部の承認経路情報が示されている。営業第１部は、１１課、１２課、１３課及び１４課で構成され、それぞれの課員は、それぞれの課長に申請し、それぞれの課長が承認すると、営業第１部の部長が承認するかどうかを審査することになる。営業第１部の部長から破線が伸びて、経理部につながっている。これは、営業第１部の部長で承認が終わる場合と営業第１部の部長の承認では終わらず、経理部の部長の承認まで必要な場合とがあることを意味する。例えば、出張報告レポートの申請であれば、営業第１部の部長の承認までで足りるが、交通費のような経費に関わる申請であれば、経理部の部長の承認まで必要となる。
【００２５】
ここで、「ノード」とは、データベースのレコードやファイルへアクセスするアクセス端子をいう。本実施例では、「ノード」は、課員、課長、部長などの社員を意味する。また、データベースのレコードは、一例として、社員の申請情報である。データベースのレコードに対して更新を行うことは、例えば、社員の申請情報を回付、承認、否認、修正することである。したがって、課員等のノードは、社員の申請情報等のデータベースのレコードに対して、回付処理要求等の更新処理要求をすることができる。ここで、「更新処理要求をすることができる」という意味は、無制限に更新処理要求をすることができるという意味ではなく、更新処理権限を有しているときに更新処理要求をすることができるという意味にすぎない。例えば、課員が交通費の申請を回付した場合、更新処理要求権限は、課長に移転し、課員は、当該交通費の申請情報に対しては、更新処理要求をすることができなくなる。
【００２６】
［申請情報記憶部内のデータ構成］
図３を用いて、申請情報記憶部５７内のデータ構成を説明する。図３は、図１に示した申請情報記憶部内のデータ構成の一例を示す図である。申請情報は、例えば、図３に示すように、申請番号５７１、申請日５７２、申請者５７３、組織名５７４、申請項目５７５、承認経路５７６、入力データ５７７、申請内容５７８を含むが、これらに限定されるものではない。入力データ５７７欄には、例えば、交通費であれば、実際にかかった交通費を入力することになる。
【００２７】
［制御部の構成］
制御部４０は、権限移転部４１、関連付部４３、更新処理部４５及び関連付解消部４７を含む。
【００２８】
［権限移転部］
権限移転部４１は、承認経路情報記憶部５５に規定される順序に従って、課員等のノードの更新処理要求権限を移転させる。例えば、課員が交通費の申請を回付した場合、権限移転部４１は、当該申請情報に対する更新処理要求権限を、課員から課長に移転させる。
【００２９】
［関連付部］
関連付部４３は、複数のレコードを相互に関連付ける。関連付部４３は、例えば、複数の交通費の申請情報を一つにまとめる。ここで、図４及び図５を用いて、複数の申請情報のまとめ方について説明する。図４は、本発明の一実施形態に係る複数の申請情報のまとめ方を示す概略図である。関連付部４３は、ノードによる関連付け命令によって、複数のレコードを相互に関連付ける。具体的には、課員Ａが複数の申請情報を一つにまとめる命令を出すことによって、関連付部４３は、複数の申請情報を一つにまとめる。関連付け命令をすることができるのは、課員に限定されるものではなく、ノードであれば、課長や部長であってもよい。例えば、課員Ａが個別に申請した申請情報を課長Ｉが、一つにまとめて承認し、部長Ｋに回付したい場合には、課長Ｉが複数の申請情報を一つにまとめる命令を出すことによって、関連付部４３は、複数の申請情報を一つにまとめることになる。また、他の例では、営業第１部１１課の課員Ａ、課員Ｂがそれぞれ単数または複数の申請をして、１１課の課長Ｉが、課員Ａ、課員Ｂの申請を一つにまとめて承認し、部長Ｋに回付したい場合には、課長Ｉが複数の申請情報を一つにまとめる命令を出すことによって、関連付部４３は、複数の申請情報を一つにまとめることになる。
【００３０】
図５は、本発明の一実施形態に係る複数の申請書類の回付セットの設定・解除をする一覧画面の一例を示す図である。図５に示すように、画面には、同時回付の設定の有無６０１、詳細６０３、業務名６０５、ステータス６０７、回付先部署６０９、回付先６１１、回付先氏名６１３、項目１欄６１５、項目２欄６１７、重要欄６１９、同時回付欄６２１を含むが、これらに限定されるものではない。課員等のノードが、同時回付の設定アイコン６２３を押すと同時回付にするかどうかを設定することができる。図５に示すように、業務名「ＭＭＣ−０００００１」は、同時回付欄６２１に「●」がある。これは、同時回付の設定が既にされていることを意味する。ここで、同時回付される一つにまとめられた申請を回付セットと呼ぶ。
【００３１】
本実施形態によれば、最終承認者に限らず、申請者、中間承認者、最終承認者のいずれもが複数の申請情報を一つにまとめる命令を出すことによって、関連付部４３は、複数の申請情報を一つにまとめることができる。そのため、最終承認者に回付される時点で初めて文書が一括になる従来技術とは異なり、より使い勝手の良いワークフローシステムを提供することができるという効果を奏する。
【００３２】
関連付部４３は、ノードによる関連付け命令によらずに、所定の条件を満たす場合は、自動的に複数のレコードを相互に関連付けてもよい。具体的には、同じ申請者からの申請であること、同じ申請日であること、同じ申請項目であること、同じ組織名であること、同じ承認経路であること等を条件として、関連付部４３は、自動的に複数の申請情報を一つにまとめてもよい。また、これらの条件を複数組み合わせて条件としても良い。具体的には、同じ組織名であること、同じ申請項目であることの２つの条件を組み合わせて、２つの条件を満たす場合に、関連付部４３は、自動的に複数の申請情報を一つにまとめてもよい。
【００３３】
例えば、図３に示すように、申請情報には、申請日５７２、申請者５７３、組織名５７４、申請項目５７５、承認経路５７６が含まれる。これらの情報から、同じ申請者からの申請であるかどうか、同じ申請日であるかどうか、同じ申請項目であるかどうか、同じ組織名であるかどうか、同じ承認経路であるかどうかが判断される。
【００３４】
他方、同じ申請者からの申請であること、同じ申請日であること、同じ申請項目であること、同じ組織名であること、同じ承認経路であること等の条件を満たしたとしても、一つにまとめる対象とならない申請があってもよい。例えば、申請情報の重要欄（図示せず）にチェックを入れると、一つにまとめる対象とならない申請となるように設定してもよい。
【００３５】
本実施形態によれば、基本的には、同じ申請者からの申請であること、同じ申請日であること、同じ申請項目であること、同じ組織名であること、同じ承認経路であること等を条件として、関連付部４３は、自動的に複数の申請情報を一つにまとめることができる。そのため、申請者、中間承認者、最終承認者等が複数の申請情報を一つにまとめるという手間も生じないという効果を奏する。
【００３６】
もっとも、課員等のノードによる関連付け命令による場合でも自動的に関連付けされる場合でも、まとめる数が多すぎると、中間承認者や最終承認者が一度に審査・承認する申請情報が多すぎることになり、かえって、煩雑になるという事態が生じ得る。そこで、このような事態を回避するために、まとめる数の上限を設定してもよい。例えば、申請情報を一つにまとめる上限の数を１０個とした場合、１０個を超える場合には、関連付部４３は、ノードによる関連付け命令があっても、１０個を超える申請情報については一つにまとめない。
【００３７】
また、回付セットに含まれる申請情報が多すぎると、中間承認者や最終承認者が個々の申請を確認するのに注意が散漫になってしまうことが有りうる。そこで、重要な申請や回付セットに含まれる申請の中で他とは異なる異質な情報を有する申請については、注意を喚起するようにしてもよい。例えば、申請情報を一つにまとめる上限の数を１０個として、一つにまとめた申請がすべて交通費の清算の申請であったとき、制御部４０が、すべての申請情報から金額が一番大きい申請については、注意喚起の表示をしてもよい。注意喚起の表示方法としては、対象となる申請の表示位置や角度、色などを他の申請とは変えてもよいが、これらに限定されるものではなく、ユーザの視覚に訴える要素があればよい。
【００３８】
［優先順位づけによる回付セットの最適化］
図６及び図７を用いて、優先順位を設定し、かつ、一つにまとめる数の上限を設定した場合に、回付セットを最適化する仕組みについて説明する。図６は、本発明の一実施形態に係る回付セットの最適化を説明するための概略図である。例えば、上記所定の条件のうち、一つの回付セットにまとめる際の優先順位の１番目が「同じ組織名であること」、２番目が「同じ申請項目であること」、３番目が「同じ申請者からの申請であること」、４番目が「同じ申請日であること」で、一つにまとめる数の上限が５個であるとする。２０１５年９月３０日、営業第１部１１課の課員Ａが交通費の清算の申請を４個行い、同じ営業第１部１１課の課員Ｂが交通費の清算の申請を１個行った場合、図６（ａ）に示すように、「同じ組織名であること」「同じ申請項目であること」「同じ申請日であること」の条件を満たし、中間承認者である１１課の課長Ｉの元で、これらの５個の申請が一つの回付セットにまとめられ、記憶部５０に記憶される。
【００３９】
この状態で、課長Ｉが同日にこの回付セットを審査することなく、２０１５年１０月１日、課員Ａが交通費の清算の申請を１個行った場合、当該回付セットが最適化されることになる。すなわち、一つの回付セットにまとめる際の優先順位の３番目が「同じ申請者からの申請であること」、４番目が「同じ申請日であること」であることから、２０１５年９月３０日の課員Ｂによる交通費の清算の申請よりも２０１５年１０月１日の課員Ａによる交通費の清算の申請の方が、優先順位が高い。そこで、一度は一つにまとめられた回付セットが解消され、課員Ａによる交通費の清算の申請５個が改めて一つの回付セットにまとめられ、課員Ｂによる交通費の申請１個は、１個の申請と扱われるか、他に回付セットにまとめられる申請があれば、それらと一つの回付セットにまとめられる。
【００４０】
図７を用いて、具体的に説明する。図７は、本発明の一実施形態に係る回付セットの最適化を説明するためのフローチャート図である。まず、制御部４０は、新たな申請があるかどうかを確認し（Ｓ１０２）、新たな申請が確認されなければ（Ｓ１０２でＮｏの場合）、新たな申請が確認されるまでループする。他方、制御部４０が新たな申請があることを確認した場合（Ｓ１０２でＹｅｓの場合）には、制御部４０は、記憶部５０にステータス６０７が「作成中」の回付セットがあるかどうかを確認する（Ｓ１０３）。記憶部５０にステータス６０７が「作成中」の回付セットがある場合（Ｓ１０３でＹｅｓの場合）には、制御部４０は、当該回付セットに含まれる申請の個数が、上限として設定された個数を超えているかどうかを確認する（Ｓ１０４）。そして、当該回付セットに含まれる申請の個数が、上限として設定された個数を超えていない場合（Ｓ１０４でＮｏの場合）には、制御部４０は、新たな申請が既存の回付セットの所定の条件を満たすかどうかを確認する（Ｓ１０５ｂ）。例えば、上限として設定された個数が５個である場合に、既存の回付セットとして、２０１５年９月３０日の課員Ａによる交通費の清算の申請４個があるときに、同日、新たに課員Ｂによる交通費の清算の申請１個がなされた場合、「同じ組織名であること」「同じ申請項目であること」「同じ申請日であること」の条件を満たし（所定の条件として、例えば、３つの条件を満たすこと）、関連付部４３は、２０１５年９月３０日の課員Ａによる交通費の清算の申請４個の既存の回付セットに課員Ｂによる交通費の清算の申請１個を加えた回付セットを生成する（Ｓ１０６ｂ）。
【００４１】
他方、回付セットに含まれる申請の個数が、上限として設定された個数を超える場合（Ｓ１０４でＹｅｓの場合）には、制御部４０は、新たな申請の申請情報から、組織名、申請項目、申請者、申請日に関する情報を抽出した上で、設定された優先順位にしたがって、記憶部５０を走査する。例えば、上の例の場合、まず、制御部４０は、新たな申請の申請情報から、組織名が営業第１部１１課、申請項目が交通費、申請者が課員Ａ、申請日が２０１５年１０月１日であることを抽出する。そして、制御部４０は、組織名、申請項目、申請者の順に記憶部５０を走査すると、２０１５年９月３０日に課員Ａにより申請された交通費の清算の申請４個と同日に課員Ｂにより申請された交通費の清算の申請１個がまとめられた既存の回付セットを抽出することになる。続けて、制御部４０は、新たな申請の申請情報と抽出された回付セットに含まれる個別の申請の申請情報を抽出・比較し、新たな申請の方が回付セットに含まれるいずれかの個別の申請よりも優先順位が高いと判断した場合には、関連付解消部４７は、既存の回付セットを解消する。例えば、既存の回付セットは、２０１５年９月３０日に課員Ａにより申請された交通費の清算の申請４個と同日に課員Ｂにより申請された交通費の清算の申請１個がまとめられた回付セットである。この場合において、一つの回付セットにまとめる際の優先順位の１番目が「同じ組織名であること」、２番目が「同じ申請項目であること」、３番目が「同じ申請者からの申請であること」、４番目が「同じ申請日であること」であるときには、２０１５年１０月１日に課員Ａにより申請された交通費の清算の申請１個は、２０１５年９月３０日に課員Ｂにより申請された交通費の清算の申請１個よりも、優先順位が高いと判断される（Ｓ１０５ａでＹｅｓ）。この場合（Ｓ１０５ａでＹｅｓの場合）には、関連付解消部４７は、２０１５年９月３０日に課員Ａにより申請された交通費の清算の申請４個と同日に課員Ｂにより申請された交通費の清算の申請１個がまとめられた既存の回付セットを解消する。そして、関連付部４３は、図６（ｂ）に示すように、２０１５年９月３０日の課員Ａによる交通費の清算の申請４個と２０１５年１０月１日の課員Ａによる交通費の清算の申請１個とを回付セットにする（Ｓ１０６ａ）。
【００４２】
もっとも、記憶部５０にステータス６０７が「作成中」の回付セットがない場合（Ｓ１０３でＮｏの場合）、新たな申請が既存の回付セットの所定の条件を満たさない場合（Ｓ１０５ｂでＮｏの場合）、新たな申請の方が既存の回付セットに含まれるいずれの個別の申請よりも優先順位が低い場合（Ｓ１０５ａでＮｏの場合）には、制御部４０は、新たな申請が既存の個別の申請との関係で所定の条件を満たすかどうかを確認し（Ｓ１０６ｃ）、所定の条件を満たす場合（Ｓ１０６ｃでＹｅｓの場合）には、関連付部４３は、新たな申請と既存の個別の申請との回付セットを生成し（Ｓ１０７）、そうでない場合（Ｓ１０６ｃでＮｏの場合）には、記憶部５０は、回付セットにすることなく個別の申請のままで記憶する（Ｓ１０８）。
【００４３】
本実施形態によれば、複数の申請のまとめと解消を動的に行うことにより、回付セットを最適化することができるという効果を奏する。
【００４４】
［更新処理部］
更新処理部４５は、関連付部４３によって相互に関連付けられた複数のレコードのうちの１個のレコードに対する、ノードによる更新処理要求により、相互に関連付けられた複数のレコードの全てに対して更新処理をする。例えば、課員Ａが複数の申請を一つにまとめる命令を出して、関連付部４３が複数の申請を一つにまとめた後、更新処理部４５は、課員Ａが複数の申請のうちの１個の申請に対して課長Ｉに回付処理をするよう要求することによって、一つにまとめた申請のすべてに対して回付処理をする。１個の申請に対する回付処理要求によって、一つにまとめた申請のすべてに対して回付処理が行われることを同時回付と呼ぶ。また、例えば、更新処理部４５は、部長Ｋが関連付部４３が複数の申請を一つにまとめた申請のうちの１個の申請に対して最終承認処理をするよう要求することによって、一つにまとめた申請のすべてに対して承認をする。
【００４５】
本実施形態によれば、上記のとおり、最終承認者に限らず、申請者、中間承認者、最終承認者のいずれもが複数の申請情報を一つにまとめる命令を出すことによって、関連付部４３は、複数の申請情報を一つにまとめることができる。そのため、申請者や中間承認者が複数の申請情報を一つにまとめた場合には、これらの者が次の承認者に回付する際には、まとまった複数の申請情報のうちの１個の申請情報に対して、回付処理要求をすることによって、まとまった複数の申請情報のすべてが回付されることになる。したがって、一括で回付できるという効果を奏する。
【００４６】
［関連付解消部］
関連付解消部４７は、関連付部４３によって相互に関連付けられた複数のレコードの関連付けを解消する。例えば、関連付解消部４７は、関連付部４３によって一つにまとめられた複数の申請情報のうち、まとめを解消して個別の申請に戻したい申請について、まとめを解消する。
【００４７】
図８を用いて、まとめの解消について説明する。図８は、本発明の一実施形態に係る複数の申請書類の回付セットの解除ができる画面の一例を示す図である。図５の同時欄６２１に「●」が入っている箇所をクリックすると、図８の同時回付一覧の画面を表示される。
【００４８】
関連付解消部４７は、ノードによる関連付解消命令によって、関連付部４３によって相互に関連付けられた複数のレコードの関連付けを解消する。例えば、関連付解消部４７は、課長Ｉによる関連付解消命令によって、一つにまとめられた複数の申請のまとめを解消する。まとめの解消は、すべての申請のまとめを個別の申請に解消してもよいし、すべての申請のうち一部の申請のまとめだけを解消してもよい。図８に示すように、業務名「ＭＭＣ−０００１３１」から「ＭＭＣ−０００１３８」の８個の申請が一つにまとまっている場合、業務名「ＭＭＣ−０００１３２」を回付セットから解除するために、解除欄６３１にチェックを入れて、解除アイコンを押すと、業務名「ＭＭＣ−０００１３２」は、回付セットから解除される。他方、業務名「ＭＭＣ−０００１３１」から「ＭＭＣ−０００１３８」の８個に対応する解除欄６３１にチェックを入れて、解除アイコンを押すと、すべての申請のまとめが個別の申請に解消される。
【００４９】
本実施形態によれば、一度は一つにまとめられた申請であっても、まとめられていることが不適切な申請であると判断した課長等のノードが、当該不適切な申請に対して関連付解消命令をすることによって、まとまりから解消することができ、より柔軟なまとめ方をすることができるという効果を奏する。最終承認者が、例えば、一つにまとめられた８個の申請のうち、７個の申請を承認とし、１個の申請を否認したい場合には、否認したい１個の申請だけ、関連付解消命令をすることによって、関連付けを解消し、７個の申請を一括承認することができる。この場合であっても、最終承認者は、申請者や中間承認者に申請のすべてを差し戻す必要がなく、最終承認者だけで処理を完結することができるという効果を奏する。
【００５０】
関連付解消部４７は、ノードによる関連付解消命令によらずに、自動的に相互に関連付けられた複数のレコードの関連付けを解消してもよい。例えば、最終承認者が一つにまとめられた複数の申請のうちの１個の申請に対して、承認処理を要求して、承認処理がされた後に、複数の申請のセットが解消される。そして、記憶部５０は、個別の申請がそれぞれ承認された状態を記憶することになる。
【００５１】
従来技術の場合、個々の電子文書を一括した上で承認した後の文書データを新しい文書データとして、文書テーブルに格納する。そのため、個々の文書を検索したいときに、不要な文書もまとめて検索結果に出力されてしまうため、個別の文書の追跡が煩雑になる。他方、本実施形態によれば、従来技術と異なり、最終承認者による承認後、関連付解消部は複数の申請のセットを自動的に解消し、記憶部は個別の申請がそれぞれ承認された状態を記憶する。そのため、承認後に個別の申請を検索したいときに、個別の申請毎に検索することができ、個別の申請を追跡することが容易であるという効果を奏する。
【００５２】
＜第２実施形態＞
図９を用いて、情報管理装置１Ａの概要を説明する。図９は、本発明の一実施形態に係る情報管理装置の構成の一例を示すブロック図である。本実施形態は、第１実施形態と概ね同じである。そこで、重複する点についての説明は省略し、異なる点についてのみ詳細な説明をする。本実施形態は、第１実施形態と異なり、識別子生成部４９を含む。
【００５３】
識別子生成部４９は、複数のレコードを相互に関連付ける際に、関連付ける複数のレコードを一意に特定する識別子を生成する。例えば、識別子生成部４９は、関連付部４３が複数の申請を一つにまとめる際に、一つにまとめる複数の申請を特定する識別子、すなわち、回付セットを特定する一意の識別子（ＩＤ）を生成する。このＩＤを回付セットＩＤと呼ぶ。
【００５４】
識別子は、複数のレコードが相互に関連付けられた時刻とノードの識別子とに基づいて生成される。具体的には、回付セットＩＤは、回付セット作成時に基点となる申請のＩＤ、ログインユーザのＩＤ、現在時刻の３つの情報を組み合わせて自動で生成されるが、この３つの情報に限定されるものではなく、ログインユーザの氏名情報などであってもよい。ノードは、データベースのレコードやファイルへアクセスするアクセス端子であるが、レコードやファイルへのアクセスは、プログラムにより行われていることから、ノードは、特定の情報処理をするためのプログラムともいうことができる。そうすると、ノードの識別子としては、プログラムＩＤなどであってもよい。
【００５５】
本実施形態でも、第１実施形態と同様に、より使い勝手の良いワークフローシステムを提供することができるという効果、申請者、中間承認者、最終承認者等が複数の申請情報を一つにまとめるという手間も生じないという効果、一括で回付できるという効果、より柔軟なまとめ方をすることができるという効果、最終承認者は、申請者や中間承認者に申請のすべてを差し戻す必要がなく、最終承認者だけで処理を完結することができるという効果、承認後に個別の申請を検索したいときに、個別の申請毎に検索することができ、個別の申請を追跡することが容易であるという効果を奏する。
【００５６】
本実施形態によれば、回付セットＩＤが付されることにより、回付セットを一意に特定できるという効果を奏する。
【００５７】
なお、本発明は上記の実施形態に限られたものではなく、趣旨を逸脱しない範囲で適宜変更することが可能である。
【符号の説明】
【００５８】
１、１Ａ：情報管理装置  ２０：ユーザ端末  ２７：ネットワーク
３０：通信制御部  ４０：制御部  ４１：権限移転部
４３：関連付部  ４５：更新処理部  ４７：関連付解消部
５０：記憶部  ５１：人事情報記憶部  ５５：承認経路情報記憶部  
５７：申請情報記憶部  ６０：仕掛・回付一覧  ６３：同時回付一覧
５７１：申請番号  ５７２：申請日  ５７３：申請者  ５７５：申請項目
５７７：入力データ  ５７８：申請内容
６０１：同時回付の設定の有無６０１  ６０３：詳細  ６０５：業務名
６０７：ステータス  ６０９：回付先部署６０９  ６１１：回付先６１１
６１３：回付先氏名  ６１５：項目１欄  ６１７：項目２欄
６１９：重要欄  ６２１：同時回付欄  ６２３：同時回付の設定アイコン
６２５：同時回付の解除アイコン  ６３１：解除欄  ６３３：表示明細
６３５：詳細欄  ６３７：業務名  ６３９：ステータス
６４１：担当者部署  ６４３：役職  ６４５：担当者氏名
【図１】
2017072906.tif 000003
【図２】
2017072906.tif 000004
【図３】
2017072906.tif 000005
【図４】
2017072906.tif 000006
【図５】
2017072906.tif 000007
【図６】
2017072906.tif 000008
【図７】
2017072906.tif 000009
【図８】
2017072906.tif 000010
【図９】
2017072906.tif 000011
【図１０】
2017072906.tif 000012
【手続補正書】
【提出日】平成29年2月21日(2017.2.21)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
レコードに対して更新処理要求が可能なノードが順序付けられて規定される記憶部と、
前記記憶部に規定される順序に従って前記ノードの更新処理要求権限を移転させる権限移転部と、
複数の前記レコードを相互に関連付ける関連付部と、
前記関連付部によって相互に関連付けられた複数のレコードのうちの１個のレコードに対する、前記ノードによる更新処理要求により、前記相互に関連付けられた複数のレコードの全てに対して更新処理をする更新処理部と、
を備える情報管理装置。
【請求項２】
前記関連付部は、前記ノードによる関連付け命令によって、複数の前記レコードを相互に関連付けることを特徴とする請求項１に記載の情報管理装置。
【請求項３】
前記関連付部によって相互に関連付けられた複数のレコードの関連付けを解消する関連付解消部をさらに備えることを特徴とする請求項１に記載の情報管理装置。
【請求項４】
前記関連付解消部は、前記ノードによる関連付解消命令によって、前記関連付部によって相互に関連付けられた複数のレコードの関連付けを解消することを特徴とする請求項３に記載の情報管理装置。
【請求項５】
前記関連付解消部は、前記更新処理部における更新処理がされた後に、前記複数のレコードの関連付けを解消し、
前記記憶部は、前記関連付けが解消された個別のレコードをそれぞれ記憶することを特徴とする請求項３に記載の情報管理装置。
【請求項６】
複数の前記レコードを相互に関連付ける際に、関連付ける該複数のレコードを一意に特定する識別子を生成する識別子生成部をさらに備える、請求項１に記載の情報管理装置。
【請求項７】
前記識別子は、前記複数のレコードが相互に関連付けられた時刻と前記ノードの識別子とに基づいて生成される請求項６に記載の情報管理装置。
【請求項８】
レコードに対して更新処理要求が可能なノードが順序付けられて規定される記憶部と、
前記記憶部に規定される順序に従って前記ノードの更新処理要求権限を移転させる権限移転部と、
前記権限移転部が前記ノードの更新処理要求権限を移転させた後に、複数の前記レコードを相互に関連付ける関連付部と、
前記関連付部によって相互に関連付けられた複数のレコードのうちの１個のレコードに対する、前記ノードによる更新処理要求により、前記相互に関連付けられた複数のレコードの全てに対して更新処理をする更新処理部と、
を備える情報管理装置。
【請求項９】
レコードに対して更新処理要求が可能なノードが順序付けられて規定される記憶部と、
前記記憶部に規定される順序に従って前記ノードの更新処理要求権限を移転させる権限移転部と、
複数の前記レコードを相互に関連付ける関連付部と、
前記関連付部によって相互に関連付けられた複数のレコードのうちの１個のレコードに対する、前記ノードによる更新処理要求により、前記相互に関連付けられた複数のレコードの全てに対して更新処理をする更新処理部と、を備え、
前記レコードは、申請日、申請者、組織名又は申請項目のいずれか一つの情報を含み、
前記関連付部は、前記複数のレコードに含まれる前記情報がそれぞれ同じである場合に、当該複数のレコードを相互に関連付けることを特徴とする情報管理装置。
【請求項１０】
レコードに対して更新処理要求が可能なノードが順序付けられて規定される記憶部と、
前記記憶部に規定される順序に従って前記ノードの更新処理要求権限を移転させる権限移転部と、
複数の前記レコードを相互に関連付けてレコード群にする関連付部と、
前記レコード群に含まれるレコードの数が閾値を超えるかどうかを判断する制御部と、
前記レコード群に含まれる１個のレコードに対する、前記ノードによる更新処理要求により、前記レコード群に含まれる全てのレコードに対して更新処理をする更新処理部と、
前記レコード群の関連付けを解消する関連付解消部と、を備え、
第１レコードを取得した場合で、前記制御部が、前記第１レコードの数と前記レコード群に含まれる前記レコードの数の和が前記閾値を超えると判断し、前記レコード群に含まれる第２レコードが前記第１レコードよりも関連付けの優先順位が低いと判断するときは、前記関連付解消部は、前記レコード群の関連付けを解消し、前記関連付部は、前記関連付けを解消した前記レコード群と前記第１レコードのうち関連付けの優先順位が高い前記閾値の数の前記レコードを相互に関連付けることを特徴とする、情報管理装置。