JP6582467B2 - プログラム、ワークフローシステム及び処理方法 - Google Patents

Description

本発明は、案件の閲覧可否を柔軟に決定するワークフローシステム、ワークフローシステムの処理方法、およびプログラムに関する。

ワークフローシステムにおいて、過去に処理した案件を検索・閲覧する機能（以下、トラッキング）がある。トラッキングは、自分が関わった案件の進行状況や最終結果を確認したり、類似の案件の申請・承認時に参照したりするために利用される。

一般的にトラッキング可能な案件とは、そのユーザが申請・承認などの意思決定処理をおこなった案件であり、ユーザが異動などにより、その案件とは無関係な立場になったとしても、継続して検索・閲覧が可能である。

しかし、ワークフローシステム上で処理される業務の特性によっては、現在その業務に無関係なユーザがその業務に紐づく案件を検索・閲覧が行えることがセキュリティ上のリスクとなる可能性がある。例えば、稟議書などはユーザが個人として申請処理を行うものではなく、所管部門の担当者として申請を行うものであり、承認処理も所管部門の担当者として行われるものであり、ユーザが個人として行うものではない。

それにもかかわらず、当該ユーザが、業務の所管部門から所管外部門への異動後も、その業務に紐づく案件を検索・閲覧できることは、セキュリティ的に望ましくない。また、所管部門に異動してきたユーザが、業務に紐づく過去案件を検索・閲覧出来ないことは業務の継続に著しい不便が発生する場合がある。

また、人事関連の業務においては、申請者はあくまで個人として申請を行うが、承認は所管部門の担当者が行う、というように業務の特性によって、どのユーザに検索・閲覧を許すべきかは異なる。

特開２００８−２９９４６０

上記特許文献１の方法では、帳票の種類に応じてアクセスルールを定義し、回覧されてきた承認ルート（経路）に応じてアクセス権を自動的に決定している。上記アクセスルールにおいてある帳票が個人に紐付かないものと定義されていれば、異動後は閲覧できなくすることを実現している。

しかしながら、この方法では、組織変更が発生した際に個人に紐付かない案件は突然閲覧が不可となってしまい、組織変更直後の引き継ぎの時期において不便や混乱を引き起こす場合が考えられる。

そこで、本発明の目的は、ワークフローシステムにおいて、案件の閲覧可否を柔軟に制御する仕組みを提供することである。

本発明は、業務プロセスを有するワークフローシステムで実行可能なプログラムであって、前記ワークフローシステムを、閲覧可否に用いられるユーザの所属部門を定義したユーザ定義情報を複数管理するユーザ部門管理手段と、前記ユーザから前記業務プロセスの案件の閲覧の要求を受け付ける閲覧要求受付手段と、前記閲覧要求受付手段で閲覧要求を受け付けた案件が処理中であるかを判断する案件状態判断手段と、前記案件状態判断手段により前記案件が処理中と判断された場合、該案件の申請時に用いたユーザ定義情報により、該案件の閲覧可否を制御する制御手段として機能させることを特徴とする。

本発明によれば、ワークフローシステムにおいて、案件の閲覧可否を柔軟に制御する仕組みを提供することができる。

本発明のワークフローシステムの構成の一例を示す図 本発明の情報処理装置１０１およびサーバ１０２のハードウェア構成の一例を示す図 本発明の情報処理装置１０１およびサーバ１０２のソフトウェア構成の一例を示すブロック図 閲覧管理反映処理の一例を示すフローチャート 案件の閲覧可否判定処理の一例を示すフローチャート サーバ１０２で管理する組織およびユーザを管理するテーブルの一例を示す図 組織と所属するユーザの関係を示す図 サーバ１０２で管理する承認ルート、案件および処理履歴を管理するテーブルの一例を示す図 トラッキングモードを設定する画面およびトラッキングモードを管理するテーブルの一例を示す図 閲覧不可画面の一例を示す図

以下、本発明の実施の形態を、図面を参照して詳細に説明する。

図１は、本発明のワークフローシステム１００の構成の一例を示すシステム構成図である。情報処理装置１０１とサーバ１０２は、ネットワーク１０４を介して接続されている。情報処理装置１０１は、デスクトップＰＣ、ノートＰＣ、タブレットＰＣ、スマートフォン、携帯電話などの端末である。また、サーバ１０２にはデータベース１０３が接続され、ワークフロー処理に必要なデータの供給を行う構成となっている。なお、本発明においてはサーバ１０２およびデータベース１０３およびそれに類するサーバ群がどのような構成をとっていても構わない。

以下、図２を用いて、図１に示した情報処理装置１０１、サーバ１０２のハードウェア構成について説明する。

２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。

２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。

また、２０５は入力コントローラで、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。２０６はビデオコントローラで、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。なお、図２では、ＣＲＴ２１０と記載しているが、表示器はＣＲＴだけでなく、液晶ディスプレイ等の他の表示器であってもよい。これらは必要に応じて管理者が使用するものである。

２０７はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶する外部記憶装置（ハードディスク（ＨＤ））や、フレキシブルディスク（ＦＤ）、ソリッドステートドライブ（ＳＳＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

２０８は通信Ｉ／Ｆコントローラで、ネットワーク（例えば、図１に示したＬＡＮ４００）を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

本発明を実現するための後述する各種プログラムは、外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイル及び各種情報テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明も後述する。

図３は、本発明の情報処理装置１０１およびサーバ１０２のソフトウェア構成の一例である。

ワークフローシステム１００は、案件業務管理部３０１、組織情報管理部３０２、処理履歴管理部３０３、閲覧可否管理部３０４、閲覧可否決定部３０５、画面出力部３０６、閲覧管理反映部３０７、基準日ユーザ部門取得部３０８を備える。

案件業務管理部３０１は、案件の識別情報と業務プロセスの識別情報とを対応付けて管理する機能部である。

組織情報管理部３０２は、ユーザの識別情報とユーザが属する部門の識別情報とを対応付けて組織情報として管理する機能部である。

処理履歴管理部３０３は、案件の識別情報と、案件に対して処理を行ったユーザの識別情報と、組織情報管理部３０２から取得したユーザが処理を行った時に属する部門の識別情報とを対応付けて管理する機能部である。

閲覧可否管理部３０４は、処理履歴管理部３０３に管理されているどの情報に従って案件の閲覧可否を決定するかを、案件に対応する業務プロセスの識別情報と対応付けて管理する機能部である。

閲覧可否決定部３０５は、閲覧可否管理部３０４に管理されている案件の閲覧可否を決定する情報に従って、案件の閲覧可否を決定する機能部である。

処理履歴管理部３０３は、案件に対するユーザの処理内容を更に対応付けて管理する機能部である。

閲覧可否管理部３０４は、処理履歴管理部３０３に管理されているどの情報に従って案件の閲覧可否を決定するかを、処理内容の種類毎に管理する機能部である。

閲覧可否決定部３０５は、処理履歴管理部３０３に管理されている情報のうち、処理内容が閲覧可否管理部３０４に管理されている処理内容に該当する情報を検索対象にして、案件の閲覧可否を決定する機能部である。

組織情報管理部３０２は、ユーザが属するロールの識別情報を更に対応付けて管理する機能部である。

処理履歴管理部３０３は、組織情報管理部３０２から取得したユーザが処理を行った時に属するロールの識別情報を更に対応付けて管理する機能部である。

画面出力部３０６は、閲覧可否管理部３０４に管理されている情報を入力または変更する画面を出力する機能部である。

閲覧管理反映部３０７は、画面出力部により出力した画面で受け付けた入力または変更された情報を、閲覧可否管理部３０４に反映する機能部である。

組織情報管理部３０２は、有効期間を更に対応付けて管理する機能部である。

案件業務管理部３０１は、組織情報管理部３０２を参照する基準日を更に対応づけて管理する機能部である。

基準日ユーザ部門取得部３０８は、案件業務管理部３０１で管理されている基準日を用いて、組織情報管理部３０２から案件の閲覧を要求したユーザが基準日に属する部門の識別情報を取得する機能部である。

閲覧可否決定部３０５は、処理履歴管理部３０３に案件の識別情報と、基準日ユーザ部門取得部３０８により取得された案件の閲覧を要求したユーザが基準日に属する部門の識別情報とを含む情報が管理されているか否かに従って案件の閲覧可否を決定する機能部である。

図６は、組織に関するテーブルである。なお、この実施形態における「組織」とは、部門の構造、部門に属するユーザおよびそのロールの全てを指す言葉として使用する。

部門テーブル６１０は、組織を構成する部門の構造を表すテーブルであり、「開始日」「終了日」「部門ＩＤ」「親部門ＩＤ」のデータを記憶する。つまり、過去および現在の組織情報を記憶するテーブルである。

ユーザ部門テーブル６２０は、ユーザと部門の関連を表すテーブルであり、「開始日」「終了日」「ユーザＩＤ」「部門ＩＤ」「ロールＩＤ」のデータを記憶する。過去および現在にユーザが属する部門とロールを引き出すことができるテーブルである。すなわち、ユーザ部門テーブル６２０は、ユーザの識別情報と当該ユーザが属する部門の識別情報とを対応付けて組織情報として管理する手段の一例を示す機能部である。また、ユーザ部門テーブル６２０は、ユーザが属するロールの識別情報を更に対応付けて管理する手段の一例を示す機能部である。また、ユーザ部門テーブル６２０は、有効期間を更に対応付けて管理する手段の一例を示す機能部である。

部門テーブル６１０とユーザ部門テーブル６２０は、「開始日」を部門およびユーザ部門のバージョン記号として履歴情報を保持するテーブルであり、「開始日」を指定することで、そのバージョンの組織情報およびユーザ部門情報を抽出することができる。また、任意の日付を検索条件として指定し、その日付が「開始日」「終了日」の間に含まれるレコードを抽出することで、任意の日付時点での組織情報およびユーザ部門情報を取得することができる。なお、部門テーブル６１０とユーザ部門テーブル６２０は、各バージョン時点の情報をすべて保持する形態としたが、前バージョンから変更のあった差分レコードのみを保持するなど他の形態であってもよい。

図７は、図６の部門テーブル６１０とユーザ部門テーブル６２０が示す、組織を構成する部門とユーザの関連を図で表したものである。
図８は、案件に関するテーブルである。

承認ルートテーブル８１０は、業務プロセス毎に承認者の「ロールＩＤ」を決定するテーブルである。例えば、業務ＩＤ＝ＲＩＮ０１の業務プロセスは、申請された（承認ルートレコード８１１）後、課長によって承認され（承認ルートレコード８１２）、部長によって最終承認されて完了する（承認ルートレコード８１３）。

案件テーブル８２０は、「業務ＩＤ」「案件ＩＤ」「案件名」「起案日」などの案件情報と共に、案件の承認をいつの時点の組織で行うかを示す「組織バージョン」、案件の状態を示す「ステータス」を保持している。「組織バージョン」には、申請処理時点の組織バージョンが記録され、当該案件はそのバージョンの組織情報を参照して承認者の決定などを行う。組織変更後に、新しい組織情報に従って案件の承認者を決定するには、ワークフローシステムの管理画面（不図示）を用いて、案件の「組織バージョン」を新しいバージョンに更新することで可能となる。

すなわち、案件テーブル８２０は、案件の識別情報と業務プロセスの識別情報とを対応付けて管理する手段の一例を示す機能部である。、また、案件テーブル８２０は、ユーザ部門テーブル６２０を参照する基準日を更に対応づけて管理手段の一例を示す機能部である。

なお、この実施形態においては、案件テーブル８２０に「組織バージョン」を持ち、その「組織バージョン」の組織情報を参照して承認者を決定するとしたが、これに限定するものではなく、案件テーブル８２０の「申請日」時点での組織情報を参照して承認者を決定するとしてもよい。

処理履歴テーブル８３０は、申請や承認など案件に対して行われた処理の履歴を記録したテーブルである。処理履歴には、案件に対して行った処理「アクティビティ」と共に、処理を行ったユーザの「ユーザＩＤ」、ユーザの「部門ＩＤ」および「ロールＩＤ」を記録する。これにより、案件に対して、どのユーザがどの部門のどの役割（ロール）で処理を行ったかがわかる。

すなわち、処理履歴テーブル８３０は、案件の識別情報と、当該案件に対して処理を行ったユーザの識別情報と、当該ユーザが当該処理を行った時に属する部門の識別情報とを対応付けて管理する手段の一例を示す機能部である。また、処理履歴テーブル８３０は、案件に対するユーザの処理内容を更に対応付けて管理する手段の一例を示す機能部である。また、処理履歴テーブル８３０は、ユーザ部門テーブル６２０から取得した当該ユーザが当該処理を行った時に属するロールの識別情報を更に対応付けて管理する手段の一例を示す機能部である。

案件テーブル８２０と処理履歴テーブル８３０の例では、業務ＩＤ＝ＲＩＮ０１（企画稟議書）に紐づく案件ＩＤ＝００１の案件は、１月１０日に部門Ｂの課員であるＡｎｄｙにより申請され（案件レコード８２１、処理履歴レコード８３１）、課長Ｄａｎｉｅｌによって承認され（処理履歴レコード８３２）、ステータス＝処理中（案件レコード８２１）の状態である。

また、業務ＩＤ＝ＲＩＮ０１（企画稟議書）に紐づく案件ＩＤ＝００２の案件は、１月１０日に部門Ｂの課員であるＡｎｄｙにより申請され（処理履歴レコード８３３）、課長Ｄａｎｉｅｌによって承認され（処理履歴レコード８３４）、部長Ｅｒｉｃによって最終承認され（処理履歴レコード８３５）、ステータス＝完了（案件レコード８２２）の状態である。

次に、図４を用いて、本実施形態における閲覧管理反映処理について説明する。

ステップＳ４０１において、情報処理装置１０１のＣＰＵ２０１は、ワークフローシステムのメニュー画面（不図示）から、業務プロセスの閲覧管理を行うためのトラッキングモード設定画面をサーバ１０２に要求する。

ステップＳ４０２において、サーバ１０２のＣＰＵ２０１は、情報処理装置１０１からのトラッキングモード設定画面の要求を受け付ける。

ステップＳ４０３において、サーバ１０２のＣＰＵ２０１は、トラッキングモード情報を取得する。具体的には、サーバ１０２の外部メモリ２１１またはデータベースサーバの外部メモリ２１１に記憶されているトラッキングモードテーブル９１０から、各業務のトラッキングモードを取得する。

ステップＳ４０４において、サーバ１０２のＣＰＵ２０１は、ステップＳ４０３にて取得したトラッキングモード情報を用いて、トラッキングモード設定画面情報を生成する。

ステップＳ４０５において、サーバ１０２のＣＰＵ２０１は、ステップＳ４０４にて生成したトラッキングモード設定画面情報を情報処理装置１０１に送信する。

ステップＳ４０６において、情報処理装置１０１のＣＰＵ２０１は、トラッキングモード設定画面情報を受信する。

ステップＳ４０７において、情報処理装置１０１のＣＰＵ２０１は、ステップＳ４０６にて受信したトラッキングモード設定画面情報を用いて、ＣＲＴ２１０にトラッキングモードエディタ画面９００（図９）を表示する。トラッキングモードエディタ画面９００は、トラッキングモードを表示および設定する画面の一例である。トラッキングモードエディタ画面９００には、「業務ＩＤ」「業務名」「申請履歴トラッキングモード」「承認履歴トラッキングモード」が表示されている。すなわち、ステップＳ４０７は、トラッキングモードテーブル９１０に管理されている情報を入力または変更する画面を出力する処理の一例を示すステップである。

トラッキングモードの値は、案件の処理履歴のどの情報に従って閲覧可否を決定するかを示したものである。具体的には、トラッキングモードの値には、「ユーザ」や「部門とロール」が設定される。トラッキングモードは、トラッキングモードエディタ画面９００を用いて、業務毎に設定を行う。トラッキングモードエディタ画面９００で設定された値は、トラッキングモードテーブル９１０に記憶される。

すなわち、トラッキングモードテーブル９１０は、処理履歴テーブル８３０に管理されているどの情報に従って案件の閲覧可否を決定するかを、当該案件に対応する業務プロセスの識別情報と対応付けて管理する手段の一例を示す機能部である。また、トラッキングモードテーブル９１０は、処理履歴テーブル８３０に管理されているどの情報に従って案件の閲覧可否を決定するかを、処理内容の種類毎に管理する手段の一例を示す機能部である。

なお、この実施形態においては、トラッキングモードエディタ画面９００を用いてトラッキングモードの設定を行うとしたが、これに限定するものではなく、設定ファイルなどに含まれる情報をトラッキングモードの設定値にするとしてもよい。

また、申請履歴トラッキングモードとは、この業務ＩＤに紐づく案件についての履歴情報から、申請処理を行ったユーザが閲覧可能とする場合に「ユーザ」、申請処理を行ったユーザの属する部門に属するユーザが閲覧可能とする場合に「部門」、申請処理を行ったユーザの属する部門かつロールのユーザが閲覧可能とする場合に「部門＋ロール」を設定する。

同様に、承認履歴トラッキングモードとは、この業務ＩＤに紐づく案件の履歴情報から、承認処理を行ったユーザが閲覧可能とする場合に「ユーザ」、承認処理を行ったユーザの属する部門に属するユーザが閲覧可能とする場合に「部門」、承認処理を行ったユーザの属する部門かつロールのユーザが閲覧可能とする場合に「部門＋ロール」を設定する。

なお、この実施形態においては、トラッキングモードを「申請履歴」「承認履歴」の２種類としたが、この２種類に限定するものではなく、例えば、申請前にドラフトとして保存する処理の履歴である「保存履歴」、最終承認者の承認処理の履歴である「最終承認履歴」、承認者による却下処理の履歴である「却下履歴」のように別の種類を設けたり、個々のアクティビティ毎に細分して設定したりするとしてもよい。

ステップＳ４０８において、情報処理装置１０１のＣＰＵ２０１は、ステップＳ４０７にて表示されたトラッキングモードエディタ画面９００へのユーザからの入力情報を受け付ける。具体的には、トラッキングモードエディタ画面９００における、申請履歴のトラッキングモードと承認履歴のトラッキングモードの設定変更を受け付ける。つまり、トラッキングモードエディタ画面９００の申請履歴のトラッキングモードと承認履歴のトラッキングモードの値は、ユーザによって変更することができる。

なお、この実施形態においては、トラッキングモードに設定できる値を「ユーザ」「部門」「部門＋ロール」としたが、これに限定するものではなく、承認者と同じロール（役職）のユーザが承認者の属する部門と無関係に閲覧可能とする「ロール」、特定部門に属する特定ユーザを閲覧可能とする「ユーザ＋部門」、特定ロールの特定ユーザを閲覧可能とする「ユーザ＋ロール」、承認者とその代理設定者が閲覧可能とする「ユーザ＋代理者」などの設定をするとしてもよい。

ステップＳ４０９において、情報処理装置１０１のＣＰＵ２０１は、ステップＳ４０８にて受け付けたトラッキングモードの入力情報をサーバ１０２に送信する。

ステップＳ４１０において、サーバ１０２のＣＰＵ２０１は、情報処理装置１０１から送信されたトラッキングモードの入力情報を受信する。

ステップＳ４１１において、サーバ１０２のＣＰＵ２０１は、ステップＳ４１０にて受信したトラッキングモードの入力情報をトラッキングモード情報に反映する。具体的には、トラッキングモードの入力情報を、サーバ１０２の外部メモリ２１１またはデータベースサーバの外部メモリ２１１に記憶されているトラッキングモードテーブル９１０に反映する。すなわち、ステップＳ４１１は、トラッキングモードエディタ画面９００で受け付けた入力または変更された情報を、トラッキングモードテーブル９１０に反映する処理の一例を示すステップである。

次に、図５を用いて、本実施形態における案件の閲覧可否判定処理について説明する。

ステップＳ５０１において、サーバ１０２のＣＰＵ２０１は、情報処理装置１０１から案件閲覧リクエストを受信する。なお、案件閲覧リクエストには、閲覧をリクエストする案件ＩＤが含まれている。具体的には、承認者の使用する情報処理装置１０１のＣＲＴ２１０に、ある案件についての承認依頼メール（不図示）が表示されており、そのメール本文中にある案件へのリンクを押下した場合、情報処理装置１０１からサーバ１０２に対して、この案件についての閲覧リクエストが送信される。なお、案件閲覧リクエストを行ったユーザのユーザＩＤは、案件閲覧リクエストに含まれるセッションＩＤやクッキー情報などを用いて特定する。

また、その他の例としては、案件一覧画面（不図示）に表示されている案件詳細画面へのリンクや、案件詳細画面（不図示）に表示されている他案件の詳細画面へのリンクをユーザが押下した場合、情報処理装置１０１からサーバ１０２に対して、押下した案件についての閲覧リクエストが送信される。

ステップＳ５０２において、サーバ１０２のＣＰＵ２０１は、ステップＳ５０１にて受信した閲覧リクエストの案件の情報を取得し、ＲＡＭ２０３に記憶する。具体的には、閲覧リクエストに含まれる案件ＩＤを特定し、特定された案件ＩＤを検索キーにして、案件テーブル８２０から案件レコードを取得する。

ステップＳ５０３において、サーバ１０２のＣＰＵ２０１は、ステップＳ５０２にて取得した案件のトラッキングモードを取得する。具体的には、トラッキングモードテーブル９１０から、ステップＳ５０２にて取得した案件レコードの業務ＩＤを検索キーにして、トラッキングモードレコードを取得する。

ステップＳ５０４〜ステップＳ５０９は、ステップＳ５０３にて取得したトラッキングモードレコードのトラッキングモードの数だけ繰り返す。この実施形態においては、トラッキングモードを「申請履歴」「承認履歴」の２種類としたため、まず「申請履歴」についてステップＳ５０４〜ステップＳ５０９を実行した後、次に「承認履歴」についてステップＳ５０４〜ステップＳ５０９を実行する。

なお、「申請履歴」についてのステップＳ５０８にて「ある」と判定された場合、または「申請履歴」についてのステップＳ５０９にて「ある」と判定された場合、「承認履歴」についてのステップＳ５０４〜ステップＳ５０９は実行しない。つまり、この実施形態においては、「申請履歴」「承認履歴」のどちらかに条件を満たす履歴情報が存在した場合、案件の閲覧を許可し、「申請履歴」「承認履歴」の両方とも条件を満たす履歴情報が存在しなかった場合、閲覧を許可しない。

ステップＳ５０４において、サーバ１０２のＣＰＵ２０１は、ステップＳ５０３にて取得したトラッキングモードレコードの「申請履歴」または「承認履歴」のトラッキングモードの値を判定し、トラッキングモードの値が「部門」または「部門＋ロール」の場合はステップＳ５０５に進み、「ユーザ」の場合はステップＳ５０９に進む。

ステップＳ５０５において、サーバ１０２のＣＰＵ２０１は、ステップＳ５０２にて取得した案件レコードのステータスの値を判定し、ステータスの値が「処理中」の場合はステップＳ５０６に進み、「完了」の場合はステップＳ５０７に進む。

ステップＳ５０６において、サーバ１０２のＣＰＵ２０１は、ユーザ部門テーブル６２０から閲覧リクエストユーザの案件の組織バージョン時の部門とロールを取得する。具体的には、ステップＳ５０１にて特定した案件閲覧リクエストを行ったユーザのユーザＩＤとステップＳ５０２にて取得した案件レコードの組織バージョン値とを検索キーにして、ユーザ部門テーブル６２０を検索し、案件の組織バージョンに対応するリクエストユーザの部門とロールを取得する。

すなわち、ステップＳ５０６は、案件テーブル８２０で管理されている基準日を用いて、ユーザ部門テーブル６２０から当該案件の閲覧を要求したユーザが前記基準日に属する部門の識別情報を取得する処理の一例を示すステップである。

例えば、ユーザＩＤ＝Ａｎｄｙから、ステータス＝処理中である案件ＩＤ＝００１の案件（図８の案件レコード８２１）について、閲覧リクエストを受信した場合、案件ＩＤ＝００１の組織バージョンは１月１日版であるため、ユーザＩＤ＝Ａｎｄｙと開始日＝１／１とを検索キーにして、ユーザ部門テーブル６２０を検索し、ヒットしたユーザ部門レコード６２１（図６）から部門ＩＤ＝ＢとロールＩＤ＝課員を取得する。つまり、この案件の組織バージョン時点でＡｎｄｙが属していた部門とロールを取得するということである。

なお、この実施形態においては、案件の「組織バージョン」に対応するリクエストユーザの部門とロールを取得するとしたが、これに限定するものではなく、案件の「申請日」に対応するリクエストユーザの部門とロールを取得するとしてもよい。つまり、案件のステータスが「処理中」の場合は、案件の承認が行われる部門に関連するユーザに対して閲覧を許可するということである。

以上により、処理中の案件については過去の組織情報を基準に閲覧可否を判定することが案件毎に設定できるため、組織変更が発生した際にユーザ個人に紐付かない案件が突然閲覧が不可となってしまい、組織変更直後の引き継ぎの時期において不便や混乱を引き起こすことがなくなる。そのため、組織変更に伴い閲覧権限がなくなる不便さを解消することができる。

ステップＳ５０７において、サーバ１０２のＣＰＵ２０１は、ユーザ部門テーブル６２０から閲覧リクエストユーザが現在属する部門とロールを取得する。具体的には、ステップＳ５０１にて特定した案件閲覧リクエストを行ったユーザのユーザＩＤと現在日付を検索キーにして、ユーザ部門テーブル６２０を検索し、案件閲覧リクエストを行ったユーザが現在属する部門とロールを取得する。なお、この実施形態において、日付を検索キーにしたユーザ部門テーブル６２０の検索とは、ユーザ部門テーブル６２０の開始日と終了日の間に現在日付が含まれるレコードを検索することを意味する。

以上により、完了した案件については現在の組織情報を基準に閲覧可否を判定することが案件毎に設定できるため、業務の所管部門から所管外部門への異動したユーザについて、その業務に紐づく案件の検索・閲覧を制限することができる。そのため、異動に伴うセキュリティ上のリスクを軽減することができる。

例えば、ユーザＩＤ＝Ａｎｄｙから、ステータス＝完了である案件ＩＤ＝００２の案件（図８の案件レコード８２２）について、閲覧リクエストを受信した場合、ユーザＩＤ＝Ａｎｄｙと現在日付（ここでは、７／１０とする）とを検索キーにして、ユーザ部門テーブル６２０を検索し、ヒットしたユーザ部門レコード６２２（図６）から部門ＩＤ＝ＡとロールＩＤ＝課員を取得する。つまり、Ａｎｄｙが現在属している部門とロールを取得するということである。

ステップＳ５０８において、サーバ１０２のＣＰＵ２０１は、申請処理または承認処理の履歴情報に閲覧リクエストユーザの部門（＋ロール）に一致するレコードの有無を判定し、ある場合はステップＳ５１０に進み、ない＆ここまで「申請履歴」についての判定を行っていた場合はステップＳ５０４に戻って「承認履歴」についての判定を開始し、ない＆ここまで「承認履歴」についての判定を行っていた場合はステップＳ５１１に進む。

すなわち、ステップＳ５０８は、トラッキングモードテーブル９１０に管理されている案件の閲覧可否を決定する情報に従って、当該案件の閲覧可否を決定する処理の一例を示すステップである。また、ステップＳ５０８は、トラッキングモードテーブル９１０に管理されている情報のうち、処理内容がトラッキングモードテーブル９１０に管理されている処理内容に該当する情報を検索対象にして、当該案件の閲覧可否を決定する処理の一例を示すステップである。また、ステップＳ５０８は、処理履歴テーブル８３０に当該案件の識別情報と、当該案件の閲覧を要求したユーザが基準日に属する部門の識別情報とを含む情報が管理されているか否かに従って当該案件の閲覧可否を決定する処理の一例を示すステップである。

なお、ここで、トラッキングモードの値が「部門」の場合は、閲覧リクエストユーザの部門に一致するレコードの有無を判定し、トラッキングモードの値が「部門＋ロール」の場合は、閲覧リクエストユーザの部門＋ロールに一致するレコードの有無を判定する。

具体的には、「申請履歴」についての判定を行っている場合、案件ＩＤ＝ステップＳ５０２にて特定された案件ＩＤ、アクティビティ＝申請、部門ＩＤ＝ステップＳ５０６またはステップＳ５０７にて特定された部門ＩＤ、ロールＩＤ＝ステップＳ５０６またはステップＳ５０７にて特定されたロールＩＤを検索キーにして処理履歴テーブル８３０を検索し、ヒットするレコードの有無を判定する。

例えば、案件ＩＤ＝００１の案件について、「申請履歴」についての判定を行っている場合、かつステップＳ５０６にて部門ＩＤ＝ＢとロールＩＤ＝課員を取得した場合、案件ＩＤ＝００１、アクティビティ＝申請、部門ＩＤ＝Ｂ、ロールＩＤ＝課員を検索キーにして処理履歴テーブル８３０を検索し、ヒットするレコードの有無を判定する。この場合、処理履歴レコード８３１がヒットする。

また、案件ＩＤ＝００２の案件について、「申請履歴」についての判定を行っている場合、かつステップＳ５０６にて部門ＩＤ＝ＡとロールＩＤ＝課員を取得した場合、案件ＩＤ＝００２、アクティビティ＝申請、部門ＩＤ＝Ａ、ロールＩＤ＝課員を検索キーにして処理履歴テーブル８３０を検索し、ヒットするレコードの有無を判定する。この場合、ヒットするレコードは無い。

なお、この実施形態においては、ステップＳ５０８における一致の判定は完全一致としたが、これに限定するものではなく、部門やロールの包含関係（上位部門は下位部門を含む、ロールが他のロールを含むなど）を考慮した判定を行ってもよい。

ステップＳ５０９において、サーバ１０２のＣＰＵ２０１は、申請処理または承認処理の履歴情報に閲覧リクエストユーザのユーザＩＤに一致するレコードの有無を判定し、ある場合はステップＳ５１０に進み、ない＆ここまで「申請履歴」についての判定を行っていた場合はステップＳ５０４に戻って「承認履歴」についての判定を開始し、ない＆ここまで「承認履歴」についての判定を行っていた場合はステップＳ５１１に進む。

具体的には、「申請履歴」についての判定を行っている場合、案件ＩＤ＝ステップＳ５０２にて特定された案件ＩＤ、アクティビティ＝申請、ユーザＩＤ＝ステップＳ５０１にて特定した案件閲覧リクエストを行ったユーザのユーザＩＤを検索キーにして処理履歴テーブル８３０を検索し、ヒットするレコードの有無を判定する。

例えば、案件ＩＤ＝００３（図８の８２３）の案件について、「承認履歴」についての判定を行っている場合、かつ案件閲覧リクエストを行ったユーザのユーザＩＤ＝Ｅｒｉｃの場合、案件ＩＤ＝００３、アクティビティ＝承認、ユーザＩＤ＝Ｅｒｉｃを検索キーにして処理履歴テーブル８３０を検索し、ヒットするレコードの有無を判定する。

ステップＳ５１０において、サーバ１０２のＣＰＵ２０１は、案件の閲覧を許可すると捉え、案件画面情報を生成する。案件画面情報には、ステップＳ５０２にて取得した案件情報、処理履歴テーブル８３０から取得した当該案件に関する承認履歴情報等が含まれ、ワークフローシステムがＷｅｂアプリケーションの場合、ＨＴＭＬ等の形式で画面情報を生成する。

ステップＳ５１１において、サーバ１０２のＣＰＵ２０１は、案件の閲覧を許可しないと捉え、閲覧不可画面情報を生成する。閲覧不可画面情報は、図１０のように、閲覧不可であることが示す情報を含む。

ステップＳ５１２において、サーバ１０２のＣＰＵ２０１は、ステップＳ５１０またはステップＳ５１１で生成した画面情報を情報処理装置１０１に送信する。

以上で、図５の閲覧可否判定処理についての説明を終了する。

以上により、異動があった場合にも業務プロセスに応じて、案件の閲覧可否を柔軟に決定する仕組みを提供することができる。

次に図６〜図８を用いて、閲覧可否判定の具体例について説明する。

まず、１月時点の閲覧可否について説明する。部門Ｂの課員Ａｎｄｙによって申請された企画稟議書の案件００１、００２は、申請トラッキングモード＝「部門」（図９の９１１）であり、１月時点ではステータスが「処理中」であるため、案件の組織バージョン（１／１版）においてＡｎｄｙが属する部門ＢのユーザであるＡｎｄｙとＢｏｂによって閲覧リクエストが送信された場合、閲覧可能と判定される（図５のステップＳ５０４、ステップＳ５０５、ステップＳ５０６、ステップＳ５０８、ステップＳ５０９）。

次に、組織変更が行われた４月時点で、案件００１および００２はステータスが「処理中」であるため、案件の組織バージョンが１／１のまま変更されていなければ、ＡｎｄｙとＢｏｂに閲覧権限がある状態は継続する。つまり、４月の組織変更によって部門Ｂに属さなくなったＢｏｂについても閲覧可能であるため、引き継ぎをスムーズに行うことができる。

しかし、例えば５月に案件００１および００２の組織バージョンを４／１版に変更した場合、アクティビティが申請の処理履歴に基づき閲覧可と判定されるのは、４／１版の組織情報において部門Ｂの課員であるＡｎｄｙとＣｈｒｉｓ（ステップＳ５０８、ステップＳ５１０）であり、Ｂｏｂは閲覧不可（ステップＳ５０８、ステップＳ５１１）となる。

さらに、案件ＩＤ００２の案件については、６／１に最終承認が行われ案件のステータスが「完了」となるため、６月時点で閲覧可能なユーザは、その時点の組織情報において部門Ｂの課員であるＡｎｄｙとＣｈｒｉｓである（図５のステップＳ５０４、ステップＳ５０５、ステップＳ５０７、ステップＳ５０８、ステップＳ５０９、ステップＳ５１０）。

さらに、７／１に組織変更がありＡｎｄｙとＣｈｒｉｓが部門Ｂの課員でなくなった場合、完了していない案件００１については案件の組織バージョン（４／１版）において部門Ｂの課員であるＡｎｄｙとＣｈｒｉｓが閲覧可であり、完了した案件００２についてはその時点の組織情報において部門Ｂの課員でないＡｎｄｙとＣｈｒｉｓが閲覧不可と判定されることになる。

仮に、５月に行った案件の組織バージョン変更を行わなかった場合、ＡｎｄｙとＢｏｂは異動したとしても案件が完了するまで閲覧可であり、案件が完了した時点でその時に部門Ｂの課員であるユーザに閲覧権限が移ることになる。

なお、仮に、企画稟議書の申請履歴トラッキングモードを「ユーザ」とした場合、アクティビティが申請の処理履歴に基づき閲覧可と判定されるのは、異動の状況を問わずＡｎｄｙであることは言うまでもない（図５のステップＳ５０４、ステップＳ５０９、ステップＳ５１０）。

以上により、異動があった場合にも業務プロセスに応じて、案件の閲覧可否を柔軟に決定する仕組みを提供することができる。

また、処理中の案件については過去の組織情報を基準に閲覧可否を判定することが案件毎に設定できるため、組織変更が発生した際にユーザ個人に紐付かない案件が突然閲覧が不可となってしまい、組織変更直後の引き継ぎの時期において不便や混乱を引き起こすことがなくなる。そのため、組織変更に伴い閲覧権限がなくなる不便さを解消することができるようになる。

また、完了した案件については現在の組織情報を基準に閲覧可否を判定することが案件毎に設定できるため、業務の所管部門から所管外部門への異動したユーザについて、その業務に紐づく案件の検索・閲覧を制限することができる。そのため、異動に伴うセキュリティ上のリスクを軽減することができる。

以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読み出し、実行することによっても本発明の目的が達成されることは言うまでもない。

この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記録した記録媒体は本発明を構成することになる。

プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク等を用いることが出来る。

また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

また、本発明は、複数の機器から構成されるシステムに適用しても、ひとつの機器から成る装置に適用しても良い。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

上記プログラムの形態は、オブジェクトコード、インタプリタにより実行されるプログラムコード、ＯＳ（オペレーティングシステム）に供給されるスクリプトデータ等の形態から成ってもよい。

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１００ ワークフローシステム
１０１ 情報処理装置
１０２ サーバ
１０３ データベース
１０４ ネットワーク

Claims (9)

1. 業務プロセスを有するワークフローシステムで実行可能なプログラムであって、
   前記ワークフローシステムを、
   閲覧可否に用いられるユーザの所属部門を定義したユーザ定義情報を複数管理するユーザ部門管理手段と、
   前記ユーザから前記業務プロセスの案件の閲覧の要求を受け付ける閲覧要求受付手段と、
   前記閲覧要求受付手段で閲覧要求を受け付けた案件が処理中であるかを判断する案件状態判断手段と、
   前記案件状態判断手段により前記案件が処理中と判断された場合、該案件の申請時に用いたユーザ定義情報により、該案件の閲覧可否を制御する制御手段
   として機能させることを特徴とするプログラム。
2. 前記制御手段は、前記閲覧要求受付手段により案件の閲覧の要求を受け付けた際に、前記案件状態判断手段により前記案件が処理中でないと判断された場合、現在のユーザ定義情報により、該案件の閲覧可否を制御することを特徴とする請求項１に記載のプログラム。
3. 前記案件が処理中でないと判断される場合とは、該案件が完了している場合であることを特徴とする請求項２に記載のプログラム。
4. 前記ユーザ部門管理手段は、閲覧可否に用いられるユーザの所属部門のユーザ定義情報をバージョンで管理しており、
   前記制御手段は、前記案件の申請時のユーザ定義情報のバージョンにより、該案件の閲覧可否を制御することを特徴とする請求項１乃至３に記載のプログラム。
5. 前記申請時に用いたユーザ定義情報は前記案件の申請時の申請日におけるユーザ定義情報とすることを特徴とする請求項１又は４に記載のプログラム。
6. 前記業務プロセスの案件には、案件に関わったユーザが閲覧可能なユーザ閲覧案件と、案件を申請、承認した部門のユーザのみ閲覧可能な部門閲覧案件とを有し、
   前記閲覧要求受付手段で閲覧要求を受け付けた案件がユーザ閲覧案件か部門閲覧案件かを判断する案件判断手段として機能させ、
   前記案件判断手段により前記案件が部門閲覧案件と判断された場合、前記制御手段により、前記ユーザの該案件に対する閲覧可否を制御することを特徴とする請求項１乃至５に記載のプログラム。
7. 前記案件判断手段により前記案件がユーザ閲覧案件と判断された場合、前記制御手段は、前記閲覧要求受付手段により受け付けられたユーザが、該案件に関わっているかによって、該ユーザの該案件に対する閲覧可否を制御することを特徴とする請求項６に記載のプログラム。
8. 業務プロセスを有するワークフローシステムであって、
   閲覧可否に用いられるユーザの所属部門を定義したユーザ定義情報を複数管理するユーザ部門管理手段と、
   前記ユーザから前記業務プロセスの案件の閲覧の要求を受け付ける閲覧要求受付手段と、
   前記閲覧要求受付手段で閲覧要求を受け付けた案件が処理中であるかを判断する案件状態判断手段と、
   前記案件状態判断手段により前記案件が処理中と判断された場合、該案件の申請時に用いたユーザ定義情報により、該案件の閲覧可否を制御する制御手段と
   を備えることを特徴とするワークフローシステム。
9. 業務プロセスを有するワークフローシステムにおける処理方法であって、
   前記ワークフローシステムが、
   閲覧可否に用いられるユーザの所属部門を定義したユーザ定義情報を複数管理するユーザ部門管理ステップと、
   前記ユーザから前記業務プロセスの案件の閲覧の要求を受け付ける閲覧要求受付ステップと、
   前記閲覧要求受付ステップで閲覧要求を受け付けた案件が処理中であるかを判断する案件状態判断ステップと、
   前記案件状態判断ステップにより前記案件が処理中と判断された場合、該案件の申請時に用いたユーザ定義情報により、該案件の閲覧可否を制御する制御ステップと
   を実行することを特徴とする処理方法。

Images