JP5983807B2 - 情報処理装置、情報処理方法、情報処理システム、プログラム、記録媒体 - Google Patents

Description

本発明は、ワークフローシステムにおいて、プロセスの完了に費やす時間を短縮化することを可能とする技術に関する。

ワークフローシステムにおいて、新たな申請が起案されることにより一つのプロセスが生成される。

このプロセスは、あらかじめ設計された経路上の承認者の承認を受けることによりワークフロー処理が流れ、最終的にプロセスが終了する。

ここで、従来から、経路上の承認者により承認を待つ状態となることにより、ワークフロー処理の流れが停滞するという問題があった。

これに対して、例えば、特許文献１には、ワークフローの実行時にワークフロー上の停滞を自動あるいは手動にてスキップする技術、および、ワークフローの途中でスキップされた担当者も、最終的にはそのプロセスに参加することができる技術が開示されている。

特開２００２−２５４２１４号公報

しかしながら、特許文献１に記載の技術のように、スキップし、最終的にプロセスに参加するという方法では、ユーザーがプロセスに参加する順序が変わってしまうため、意図した意思決定の手順がなされないという問題点が生じることとなる。そのため、ユーザーがプロセスに参加する順序を変えることなく、プロセスの完了に費やす時間を短縮化する方法が求められる。

ところで、処理待ちのまま滞留している場合、承認者は、操作そのものを忘れていることが多い。そのため、停滞中のアクティビティを例えば、ワークフロー処理の流れにおける後ろの承認者から、その停滞しているアクティビティの承認者に対して催促することができれば、ユーザーがプロセスに参加する順序を変えることなく、プロセスの完了に費やす時間を短縮化することが可能となる。一方、申請者あるいは承認者が、自分より後ろの承認者に対して、本プロセスを早く進めるための催促をすることができれば、同様にユーザーがプロセスに参加する順序を変えることなく、プロセスの完了に費やす時間を短縮化することが可能となる。

そこで、本発明は、上記課題を解決するものであり、ワークフロー処理の流れにおいて、後ろのアクティビティの承認を行うユーザーから前のアクティビティの承認を行うユーザーに対して催促することができるワークフローシステムを提供することを目的とする。

申請された案件についてのワークフロー処理を行う情報処理装置であって、前記案件の各アクティビティに対応する担当者および状態を記憶する案件状態記憶手段と、第一のユーザーからなされる案件表示の要求を受け付ける要求受付手段と、前記要求受付手段により受け付けた要求が、前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する要求であるか、前記第一のユーザーが処理すべきアクティビティにある案件を抽出する要求であるかを判定する判定手段と、前記判定手段による判定の結果、前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する要求であると判定された場合、前記案件状態記憶手段に記憶された案件状態に応じて前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出し、該抽出した「前記第一のユーザーが処理をする予定となっている案件」を表示し、一方、前記第一のユーザーが処理すべきアクティビティにある案件を抽出する要求であると判定された場合、前記案件状態記憶手段に記憶された案件状態に応じて前記第一のユーザーが処理すべきアクティビティを含む案件を抽出し、抽出した「前記第一のユーザーが処理すべきアクティビティにある案件」を表示する案件抽出手段とを備えることを特徴とする。

本発明によれば、ワークフロー処理の流れにおいて、後ろのアクティビティの承認を行うユーザーから前のアクティビティの承認を行うユーザーに対して催促することができるワークフローシステムを提供することが可能となる。

ワークフローシステムの概略構成を示す図 コンピュータのハードウェア構成の一例を示すブロック図 アクティビティとトランジションの関係を示す図 分岐がある場合のアクティビティとトランジションの一例を示す図 組織情報を構成するテーブルの一例を示す図 組織情報の具体例 定義情報とジョブ情報の関係を示す図 定義情報の一例を示すデータテーブル ワークアイテムの例を示す図 ジョブ情報の一例を示すデータテーブル 申請する際のワークフローシステムにおける処理の流れ ワークフローサーバにおける申請可能な業務を取得するフローチャート ワークフローサーバが取得した申請可能な業務をワークフロー操作用端末 の表示装置へ表示した例 役割を選択する画面の一例 申請画面の一例 再申請、承認、差戻、否決する際のワークフローシステムにおける処理の 流れ ワークフローサーバにおける処理待ち一覧を取得するフローチャート 処理待ち一覧の画面の例 案件詳細画面の例 前から催促する際のワークフローシステムにおける処理の流れ 後ろから催促する際のワークフローシステムにおける処理の流れ ワークフローシステムにおける配送処理の流れを示すフローチャート ワークフローサーバにおける次のユーザー実行アクティビティを求める処 理の流れを示すフローチャート 処理待ワークアイテムを作成する詳細な処理の流れ 該当者を求める処理の流れ 部門＆ロールの該当者を求める処理の流れ 予定ワークアイテムを作成する処理の流れ 承認依頼メールを送信する処理の流れ 催促処理の流れ 催促するユーザーを選択する画面 各種案件一覧の具体例示す図 選択した案件で催促を行う画面の一例 その他のワークフローシステムにおける処理の流れ 案件選択画面の一例

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

図１は、本実施形態が適用されるワークフローシステムの概略構成を示す図である。

実施形態におけるワークフローシステムは、ワークフロー及び伝票設計用コンピュータ端末（ワークフロー及び伝票設計用端末）４００、業務を遂行する処理者（担当者）に対応して設けられたワークフロー操作用コンピュータ端末（ワークフロー操作用端末）３００、ワークフローを実行するための各種テーブル、各種プログラムを格納するワークフローサーバ（情報処理装置）２００を備えている。

これらワークフロー及び伝票設計用端末４００、ワークフロー操作用端末３００、ワークフローサーバ２００は、それぞれネットワーク５００に接続され運用されている。

ワークフロー及び伝票設計用端末４００は、伝票デザイナプログラム４０１及びシステム管理プログラム４０２を有し、ワークフローシステムにて使用する伝票の定義体の作成及びワークフローシステムで利用する各種定義情報の作成を行う。例えば、ワークフロー及び伝票設計用端末４００は、ワークフローサーバ２００に部門テーブル、業務テーブル等を登録することができる。このワークフロー及び伝票設計用端末４００は、これらの作業を行うために、自己の識別情報を入力することによりワークフローサーバ２００に接続することが可能になる。

ワークフロー操作用端末３００は、ワークフロー操作用端末３００上で実行されるＷｅｂブラウザ３０１を用いて、伝票に関するアクセス情報をワークフローサーバ２００に対してＨＴＴＰで送信し、その結果を受信するものであり、その際に、発生する表示・計算処理は、Ｊａｖａ（登録商標）アプレット３０２等を利用することにより実行する。なお、このワークフロー操作用端末３００は、予め指定された所定の業務を行う担当者（例えば、起票者、課長、部長等）に配置されている。

ワークフローサーバ２００は、ワークフローシステムに関する情報（後述する図５の組織情報）、各種伝票情報（後述する図７の定義情報、ジョブ情報）を格納するＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）２０５、ワークフロー操作用端末３００よりの要求を受け付けて要求を実行するためのＨＴＴＰサーバ２０１、サーブレットエンジン２０２、ワークフロープログラム２０３、ワークフロー通知機能を実現するＳＭＴＰサーバ２０４にて構成されている。

以下、図２を参照して、図１に示したワークフローサーバ２００、ワークフロー操作用端末３００、ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成について説明する。

図２は、図１に示したワークフローサーバ２００、ワークフロー操作用端末３００、ワークフロー及び伝票設計用端末４００に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。

図２において、１０１はＣＰＵで、ＲＯＭ１０３又はハードディスク（ＨＤ）（その他の記憶装置、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ等どのような記憶装置であってもよい）１０４に格納されたプログラムをＲＡＭ１０２上にロードして実行することにより、コンピュータ全体を制御する。ＲＡＭ１０２は、ＣＰＵ１０１の作業領域として使用される。

１０８は通信インタフェースで、通信ネットワーク５００への接続を可能とする。１０６は入力装置で、キーボードやマウス等のポインティングデバイス等に相当する。１０７は表示装置で、ＣＲＴ、ＬＣＤ等で構成される。

なお、図１に示したワークフローサーバ２００のＲＤＢＭＳ２０５は、ワークフローサーバ２００のＨＤ１０４内に構築されている。また、ワークフローサーバ２００のＨＴＴＰサーバ２０１、サーブレットエンジン２０２、ワークフロープログラム２０３、ＳＭＴＰサーバ２０４は、ワークフローサーバ２００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。

また、図１に示したワークフロー操作用端末３００のＷｅｂブラウザ３０１は、ワークフロー操作用端末３００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。

さらに、図１に示したワークフロー操作用端末３００のＪａｖａ（登録商標）アプレット３０２は、ワークフロー操作用端末３００のＣＰＵ１０１が、ワークフローサーバ２００よりダウンロードされたプログラムをＷｅｂブラウザ３０１上で実行することにより、実現される。

また、図１に示したワークフロー及び伝票設計用端末４００の伝票デザイナプログラム４０１、システム管理プログラム４０２は、ワークフロー及び伝票設計用端末４００のＣＰＵ１０１が、ＨＤ１０４に格納されるプログラムをＲＡＭ１０２上にロードして実行することにより、実現される。

図３は、アクティビティとトランジションの関係を示す図である。

アクティビティとは、ワークフローを構成する処理工程を指すものである。トランジションとは、アクティビティとアクティビティとの処理の順序を規定するものである。

図３の例では、アクティビティとして、申請アクティビティ３０１、ユーザー実行アクティビティ３０２〜３０４、終了アクティビティ３０５が存在する。それぞれのアクティビティは、トランジション３０６〜３０９によりそれぞれ順序が規定されている。

図４は、分岐がある場合のアクティビティとトランジションの一例を示す図である。

申請アクティビティ４０１と条件分岐アクティビティ４０２がトランジションにより順序が規定されている。

この例では、条件分岐の条件式として、申請金額が３０万円を下回る場合と申請金額が３０万円以上の場合とで分岐する。

申請金額が３０万円を下回る場合は、ユーザー実行アクティビティ４０３へトランジションが続き、更に、ユーザー実行アクティビティ４０４へと順序を辿る。一方、申請金額が３０万円以上の場合は、ユーザー実行アクティビティ４０５へトランジションが続き、更に、ユーザー実行アクティビティ４０６へと順序を辿る。

そして、ユーザー実行アクティビティ４０４とユーザー実行アクティビティ４０６とは、合流アクティビティ４０７で合流する。

その後、ユーザー実行アクティビティ４０８、終了アクティビティ４０９の順序で処理が終了する。

なお、本実施の形態におけるワークフローシステムにおいては、条件分岐は新規申請時に決まるものとしている。

図５は、組織情報を構成するテーブルの一例を示す図である。

組織情報は、部門テーブル５０１、ロールテーブル５０２、ユーザーテーブル５０３、ポジションテーブル５０４から構成される。

部門５０１は、（部門ＩＤ、部門名、レベル番号、親部門ＩＤ）を含む。ロール５０２は、（ロールＩＤ、ロール名）を含む。ユーザー５０３は、（ユーザーＩＤ、氏名、メールアドレス、パスワード）を含む。ポジション５０４は、（ユーザーＩＤ、ロールＩＤ、部門ＩＤ）を含む。なお、ポジションとは、ユーザーが所属する部門とロールの組のことをいう。

図６に、組織情報の具体例を示す。

組織情報の各テーブルの具体例とそれを組織票として図表化した例を示す。

この例では、部門テーブル６０１の通り、「観音株式会社」、「営業部」、「管理部」、「営業１課」、「営業２課」という組織が存在している。また、ユーザーテーブル６０３の通り、「観音太郎」、「観音花子」、「観音金太郎」、「観音次郎」というユーザーが存在し、それぞれが「一般職」、「課長」、「部長」、「経理担当」といった役割を持っている（ロールテーブル６０２とポジションテーブル６０４より）。

図７は、定義情報とジョブ情報の関係を示す図である。

定義情報７１は、ワークフローにおける業務を定義する情報であり、設計者が予め定義するものである。なお、図中の「１」と「＊」は、１対多の関係にあることを示している。

業務７１１に対して、プロセス７１２、フォーム７１３、ユニット７１４、スキーマ７１５が、紐付いている。また、プロセス７１２に対して、アクティビティ７１６、トランジション７１７が紐付いている。更に、ジョブ情報７２の案件７２１と紐付いている。
ジョブ情報７２とは、ワークフローにおいて起案されたジョブに関する定義情報である。案件７２１に対して、ワークアイテム７２２、入力内容７２３、催促７２４が紐付いている。

なお、定義情報７１は、従来からあるものである。また、ジョブ情報７２のうち、案件７２１、ワークアイテム７２２、入力内容７２３は、従来からあるものであるが、催促７２４は、本発明を実施するために新たに加わった定義である。

図８は、定義情報の一例を示すデータテーブルである。

この定義情報は、図６の組織情報の例を前提としている。

業務８１において、業務ＩＤ、業務名が定義され、この例では、業務ＩＤとして「ＧＩＤ００１」、業務名として「購入申請書」が定義されている。

また、プロセス８２において、業務ＩＤ、プロセスＩＤ、申請可能部門ＩＤが定義され、この例では、業務ＩＤ「ＧＩＤ００１」、プロセスＩＤ「ＰＩＤ００１」、申請可能部門ＩＤ「Ｂ００１」が定義されている。

アクティビティ８３において、プロセスＩＤ、アクティビティＩＤ、担当者ＩＤ、担当ロールＩＤ、担当部門ＩＤ、属性、差戻し先、フォームＩＤが定義される。ここでは、複数のレコードが定義される。

なお、アクティビティの担当部門には「申請者の部門と同じ」という指定が可能である。この場合、担当部門に申請者の部門を指定したのと同じ動作をする。

最後に、この業務名「購入申請書」についてのアクティビティを図示したものを８５へ示す。

図９は、ワークアイテムの例を示す図である。

この図は、図６〜８の例を前提としている。

この例では、図８の初期状態から観音花子が承認した後のワークアイテムの変化を示している。

観音花子が承認することで、それまで「予定」であった観音金太郎の状態が、「処理待ち」に変化したことが分かる。

図１０は、ジョブ情報の一例を示すデータテーブルである。

このジョブ情報は、図６の組織情報の例、図７の定義情報の例を前提にしている。

新規案件が起案されると、案件１０１に、プロセスＩＤ、案件ＩＤ、申請部門ＩＤ、申請ロールＩＤが登録される。

また、ワークアイテム１０２には、案件ＩＤ、アクティビティＩＤ、担当者ＩＤ、状態が登録される。この例では、案件ＩＤ「００００００１」は、アクティビティＩＤ「ａｃｔ０００」は、処理済みで、アクティビティＩＤ「ａｃｔ００１」は、処理待ちであることを示している。

次に催促１０３について説明する。これは、本発明の実施の形態を実現するために新たに設けたデータテーブルである。起案された案件について催促機能が利用されることにより催促１０３に、案件ＩＤ、催促実行者ＩＤ、催促実行（アクティビティＩＤ）、催促開始（アクティビティＩＤ）、催促終了（アクティビティＩＤ）、属性が登録される。案件ＩＤ「００００００１」のレコードは、申請者が申請時に催促した例を示し、案件ＩＤ「００００００２」のレコードは、経理担当が差戻し時に催促した例を示している。

また、この業務名「購入申請書」についてのアクティビティを図示したものを１０４へ示す。また、ワークアイテムと催促を図示したものを１０５へ示す。

１０５の前から催促の例では、案件「００００００１」について、申請者の「観音太郎」が「ａｃｔ００１」から「ａｃｔ００４」まで前から催促する例を示している。申請者が催促する場合、申請者は、この案件自体を速やかに終わらせることを目的に催促するため、案件の最後の承認者まで催促がなされることとなる。

また、１０５の後ろから催促の例では、案件「００００００２」について、経理担当者である「観音次郎」が「ａｃｔ００２」から「ａｃｔ００３」まで後ろから催促する例を示している。後ろのアクティビティのユーザーが自分より前のアクティビティのユーザーに対して催促をする場合、自分のアクティビティにおける自分の処理を早く終わらせることを目的に催促するため、自分より後ろのアクティビティのユーザーに対しては催促をしない。例えば、後ろのアクティビティのユーザーが長期休暇に入る前に、そのユーザーが処理すべき予定の案件を、前のアクティビティのユーザーに対して催促することで、休み前に処理を終わらせることが可能となる。

なお、この例では、最後の処理者である「観音次郎」が後ろから前に催促をする例となっているが、例えば、「観音金太郎」が「観音太郎」に催促をした場合、その次の「観音花子」に対して催促を行うが、「観音次郎」に対しては催促を行わない。「観音金太郎」は、後ろのユーザーである「観音次郎」に対して催促をしていないからである。もし「観音金太郎」が「観音次郎」に対して催促を行いたい場合は、前から催促をすることで実現可能となる。

次に、図１１に申請する際のワークフローシステムにおける処理の流れを説明する。

本フローチャートは、ユーザーがワークフロー操作用端末を操作して、操作に応じた処理をワークフローサーバが行うものである。

まず、最初にワークフロー操作用端末は、ユーザー操作に応じてワークフローサーバへのログイン画面を表示装置へ表示させる（１１０１）。そして、入力された認証情報をワークフローサーバへ送信する。

１１０２において、ワークフローサーバは、認証を行ってユーザーを特定し、当該ユーザーが申請可能な業務を取得する。

図１２に、ワークフローサーバにおける申請可能な業務を取得するフローチャートを示す。

１２０１において、ワークフローサーバは、申請者のポジションを取得する。ログインユーザーＩＤ（インプット情報）を元に、ポジション情報（図５の５０４）を参照する。ここで、ポジションとは、ユーザーが所属する部門とロールの組ことをいう。例えば、図６の「観音太郎」の場合、組織情報から、ポジションは、営業一課・一般となり、「観音花子」の場合、所属ポジションは、営業１課・課長と営業２課・課長となる。

１２０２において、ワークフローサーバは、申請可能な業務を取得する。業務ごとに、起票者のポジションで申請可能かどうかを調べ申請可能な業務の一覧を作成する。すべての業務毎に、図７のプロセス定義を参照し、プロセス定義７１２の申請可能な部門ＩＤで指定される部門またはその下位部門に、申請者が所属する場合、申請可能な業務と判定する。例えば、プロセス定義の申請可能な部門ＩＤが、図６の営業部の場合、営業部、営業１課、営業２課に所属するユーザーは申請可能と判定する。

図１３にワークフローサーバが取得した申請可能な業務をワークフロー操作用端末の表示装置へ表示した例を示す。ユーザーは、「起案」ボタンを押下することにより業務の申請を選択することができる。

インプット情報は、ログインユーザーＩＤとなる。

１１０３において、ワークフロー操作用端末は、ユーザーによる申請業務の選択を受け付ける。そして、ワークフローサーバへ選択された申請業務を通知する。

１１０４において、ワークフローサーバは、起案時の役割を求める。

ここでの処理の流れは、図１２に占めるワークフローサーバにおける申請可能な業務を取得するフローチャートと同じであるが、差異点として、インプット情報が、ログインユーザーＩＤと業務ＩＤである点と、１２０２の処理が異なる。具体的には、１２０２において、ワークフローサーバは、申請可能なポジションの一覧を作成する。ユーザーが指定した業務（インプット情報の業務ＩＤ）で、図７のプロセス定義を参照し、プロセス定義（７１２）の申請可能な部門ＩＤで指定される部門またはその下位部門に、申請者が所属する場合、申請可能なポジションと判定する。例えば、ログインユーザーのポジションが図６の営業１課・課長と営業２課・課長で、プロセス定義の申請可能な部門ＩＤが、図６の営業１課の場合、申請可能なポジションは営業１課・課長と判定する。

１１０５において、ワークフローサーバは、起案時の役割が複数あるかを判定する。Ｙｅｓの場合、１１０６へ進み、Ｎｏの場合、１１０８へ進む。

１１０６において、ワークフロー操作用端末は、ワークフローサーバから取得した役割選択画面を表示する。

１１０７において、ワークフロー操作用端末は、ユーザーから役割選択を受け付ける。そして、ワークフローサーバへ選択された役割を通知する。図１４に役割を選択する画面の一例を示す。この例は、「神奈川 奈々子」が部長と課長とを兼任していて、そのどちらで起案するかを選択する画面を示している。

１１０８において、ワークフロー操作用端末は、ワークフローサーバから取得した申請画面を表示する。図１５に申請画面の一例を示す。ユーザーは、この画面に必要事項を入力することとなる。

１１０９において、ワークフロー操作用端末は、申請内容・催促有無の入力を受け付ける。そして、ワークフローサーバへ入力された各種内容を通知する。

１１１０において、ワークフローサーバは、配送処理（新規申請）を行う。

なお、配送処理の説明については後に説明する。

以上により、例えば、図８に示すように、新規案件が起票された状態となる。

次に、図１６に再申請、承認、差戻、否決する際のワークフローシステムにおける処理の流れを説明する。

本フローチャートは、ユーザーがワークフロー操作用端末を操作して、操作に応じた処理をワークフローサーバが行うものである。

まず、最初にワークフロー操作用端末は、ユーザー操作に応じてワークフローサーバへのログイン画面を表示装置へ表示させる（１６０１）。そして、入力された認証情報をワークフローサーバへ送信する。

１６０２において、ワークフローサーバは、処理待ち一覧をワークフロー操作用端末へ送信し、ワークフロー操作用端末は、処理待ち一覧を表示する。

図１７にワークフローサーバにおける処理待ち一覧を取得するフローチャートを示す。なお、処理待ち一覧とは、ログインユーザーが現在処理すべき案件を確認するための一覧のことをいう。

ここでのインプット情報は、ログインユーザーＩＤである。

１７０１において、ワークフローサーバは、処理待ち案件の一覧を作成する。

すべてのワークアイテム（７２２）の中から以下の条件にすべて当てはまるワークアイテムの一覧を作成する。
（１）ワークアイテムの状態が「処理待ち」である
（２）ワークアイテムの担当者ＩＤがログインユーザーＩＤ（インプット情報）と同じ
例えば、図１０で、観音花子（課長）が処理待ち一覧を開いた場合、ワークアイテム１０２から上記条件に合うものを求めると次が該当する。
・案件ＩＤ「００００００１」、アクティビティＩＤ「ａｃｔ００１」、担当者ＩＤ「Ｕ００１」、状態「処理待ち」
１７０２から１７０７まで、処理待ち案件の件数繰り返す。

また、１７０３から１７０６まで、催促の数だけ繰り返す。ここで、ワークアイテムの案件ＩＤを元に、催促情報（図７の７２４）を参照し、その催促について繰り返す。例えば、図１０で、観音花子（課長）が処理待ち一覧を開いた場合、催促は次が該当する。
・案件ＩＤ「００００００１」、催促実行者ＩＤ「Ｕ０００」、催促実行（アクティビティＩＤ）「ａｃｔ０００」、催促開始（アクティビティＩＤ）「ａｃｔ００１」、催促終了（アクティビティＩＤ）「ａｃｔ００４」、属性「前から」
１７０４において、ワークフローサーバは、案件に催促があるかを判定する。Ｙｅｓの場合、１７０５へ進み、Ｎｏの場合、１７０６へ進む。なお、催促が、以下の条件に当てはまれば、そのワークアイテムを催促ありとみなす。ワークアイテムのアクティビティ（図７の７２２、７１６）が、催促（図７の７２４）の催促開始と催促終了の間にあれば催促ありと判定する（催促開始≦配送先≦催促終了）。例えば、図１０で、観音花子（課長）が処理待ち一覧を開いた場合、催促は上記条件に該当するため、催促ありとみなす。

図１８に処理待ち一覧の画面の例を示す。ここでは、１８０１に催促についての状態が表示される。この例では、案件ＩＤ「Ｓ００００００００７」は、「催促あり」、案件ＩＤ「Ｓ００００００００６」と、案件ＩＤ「Ｓ００００００００２」は、何もない通常の処理待ち案件であることを示している。

ここで、「催促あり」とは、その案件を処理する催促がなされている案件であることを示している。本実施の形態では、催促自体は、電子メール等により通知されるので、ユーザーは、その通知により催促されている案件の存在を知る。この画面では、その催促されている案件がどれであるかを一覧から見分けることができる。

１６０３において、ワークフロー操作用端末は、ユーザーから選択された処理する案件をワークフローサーバへ送信する。

１６０４において、ワークフローサーバは、案件詳細画面をワークフロー操作用端末へ送信し、ワークフロー操作用端末は、案件詳細画面を表示する。

図１９に案件詳細画面の例を示す。

１６０５において、ワークフロー操作用端末は、ユーザー操作による申請内容の編集・催促有無の入力を受け付け、ワークフローサーバに内容を通知する。

１６０６において、ワークフローサーバは、配送処理（再申請、承認、差戻、否決）を行う。なお、配送処理の説明については後に説明する。

以上により、再申請、承認、差戻、否決がなされる。

次に、図２０に前から催促する際のワークフローシステムにおける処理の流れを説明する。

本フローチャートは、ユーザーがワークフロー操作用端末を操作して、操作に応じた処理をワークフローサーバが行うものである。

まず、最初にワークフロー操作用端末は、ユーザー操作に応じてワークフローサーバへのログイン画面を表示装置へ表示させる（２００１）。そして、入力された認証情報をワークフローサーバへ送信する。

２００２において、ワークフローサーバは、案件進捗画面をワークフロー操作用端末へ送信し、ワークフロー操作用端末は、案件進捗画面を表示する。案件進捗一覧とは、ログインユーザーが処理した処理済みの案件を確認するための一覧である（図３１の３１０１）。

なお、案件進捗画面に表示する処理待ち案件一覧を取得する処理の流れは、図１７に示す処理待ち一覧を取得するフローチャートにおいて「処理待ち」を「処理済み」と置き換えることにより対応する。

同様にインプット情報は、ログインユーザーＩＤである。ワークフローサーバは、すべてのワークアイテム（図７の７２２）の中から次の条件にすべて当てはまるワークアイテムの一覧を作成する。
（１）ワークアイテムの状態が「処理済み」である
（２）ワークアイテムの担当者ＩＤがログインユーザーＩＤ（インプット情報）と同じ
例えば、図１０で、観音太郎（申請者）が案件進捗一覧を開いた場合、ワークアイテム（図１０の１０２）から上記条件に合うものを求めると以下が該当する。
・案件ＩＤ「００００００１」、アクティビティＩＤ「ａｃｔ０００」、担当者ＩＤ「Ｕ０００」、状態「処理済み」
・案件ＩＤ「００００００２」、アクティビティＩＤ「ａｃｔ０００」、担当者ＩＤ「Ｕ０００」、状態「処理済み」

また、ワークアイテムの案件ＩＤを元に、催促情報（図７の７２４）を参照し、その催促について繰り返す。例えば、図１０で、観音太郎（申請者）が案件進捗一覧を開いた場合、催促は以下が該当する。
（案件００００００１についての催促）
案件ＩＤ「００００００１」、催促実行者ＩＤ「Ｕ０００」、催促実行（アクティビティＩＤ）「ａｃｔ０００」、催促開始（アクティビティＩＤ）「ａｃｔ００１」、催促終了（アクティビティＩＤ）「ａｃｔ００４」、属性「前から」
（案件００００００２についての催促）
案件ＩＤ「００００００２」、催促実行者ＩＤ「Ｕ００３」、催促実行（アクティビティＩＤ）「ａｃｔ００３」、催促開始（アクティビティＩＤ）「ａｃｔ００２」、催促終了（アクティビティＩＤ）「ａｃｔ００３」、属性「後ろから」

催促が、以下の条件に１つでも該当すれば、そのワークアイテムを催促ありとみなす。（１）催促実行者ＩＤがログインユーザーＩＤと等しい
（２）ワークアイテムのアクティビティＩＤが、催促の催促開始と催促終了の間にあれば催促ありと判定する（催促開始≦ログインユーザーが処理したアクティビティ≦催促終了）
例えば、図１０で、観音太郎（申請者）が案件進捗一覧を開いた場合、案件００００００１についての催促は、催促実行者ＩＤ＝ログインユーザーとなるため、条件に該当し、催促ありと判定する。また、案件００００００２についての催促は、条件に該当しないため催促なしと判定する。

２００３において、ワークフロー操作用端末は、ユーザーによる催促する案件の選択を受け付け、ワークフローサーバへ通知する。

２００４において、ワークフローサーバは、催促処理（前から）を行う。なお、催促処理については後に説明する。

以上により、前からの催促をすることができるようになる。

また、図２１に後ろから催促する際のワークフローシステムにおける処理の流れを説明する。

本フローチャートは、ユーザーがワークフロー操作用端末を操作して、操作に応じた処理をワークフローサーバが行うものである。

まず、最初にワークフロー操作用端末は、ユーザー操作に応じてワークフローサーバへのログイン画面を表示装置へ表示させる（２１０１）。そして、入力された認証情報をワークフローサーバへ送信する。

２１０２において、ワークフローサーバは、予定案件一覧をワークフロー操作用端末へ送信し、ワークフロー操作用端末は、予定案件一覧を表示する。予定案件一覧とは、ログインユーザーが将来、処理する予定の案件を確認するための一覧である（図３１の３１０２）。ユーザーは、例えば、近々、出張するような事情がある場合、出張前にその案件の処理を行うべく、自分より前の承認ユーザーに対して催促をするといった使い方ができる。

なお、予定案件一覧に表示する予定案件一覧を取得する処理の流れは、図１７に示す処理待ち一覧を取得するフローチャートにおいて「処理待ち」を「処理済み」と置き換えることにより対応する。

同様にインプット情報は、ログインユーザーＩＤである。
すべてのワークアイテム（図７の７２２）の中から次の条件にすべて当てはまるワークアイテムの一覧を作成する。
（１）ワークアイテムの状態が「予定」である
（２）ワークアイテムの担当者ＩＤがログインユーザーＩＤ（インプット情報）と同じ
例えば、図１０で、観音次郎（経理担当）が予定案件一覧を開いた場合、ワークアイテム（図１０の１０２）から上記条件に合うものを求めると以下が該当する。
・案件ＩＤ「００００００１」、アクティビティＩＤ「ａｃｔ００３」、担当者ＩＤ「Ｕ００３」、状態「予定」
・案件ＩＤ「００００００２」、アクティビティＩＤ「ａｃｔ００３」、担当者ＩＤ「Ｕ００３」、状態「予定」

ワークアイテムの案件ＩＤを元に、催促情報（図７の７２４）を参照し、その催促について繰り返す。例えば、図１０で、観音次郎（経理担当）が案件進捗一覧を開いた場合、催促は以下が該当する。
（案件００００００１についての催促）
案件ＩＤ「００００００１」、催促実行者ＩＤ「Ｕ０００」、催促実行（アクティビティＩＤ）「ａｃｔ０００」、催促開始（アクティビティＩＤ）「ａｃｔ００１」、催促終了（アクティビティＩＤ）「ａｃｔ００４」、属性「前から」
（案件００００００２についての催促）
案件ＩＤ「００００００２」、催促実行者ＩＤ「Ｕ００３」、催促実行（アクティビティＩＤ）「ａｃｔ００３」、催促開始（アクティビティＩＤ）「ａｃｔ００２」、催促終了（アクティビティＩＤ）「ａｃｔ００３」、属性「後ろから」

催促が、以下の条件に１つでも該当すれば、そのワークアイテムを催促ありとみなす。（１）催促実行者ＩＤがログインユーザーＩＤと等しい
（２）状態が「処理待ち」のワークアイテム（図７の７２２）に対応するアクティビティが、催促（図７の７２４）の催促開始と催促終了の間にあれば催促ありと判定する（催促開始≦現在の処理待ちアクティビティ≦催促終了）
例えば、図１０で、観音次郎（経理担当）が案件進捗一覧を開いた場合、案件００００００１について催促実行者ＩＤ（Ｕ０００）は、ログインユーザーＩＤ（Ｕ００３）と一致しない。条件が「処理待ち」のワークアイテムは
・案件ＩＤ「００００００１」、アクティビティＩＤ「ａｃｔ００１」、担当者ＩＤ「Ｕ００１」、状態「処理待ち」
アクティビティＩＤ（ａｃｔ００１）は、催促開始（ａｃｔ００１）と催促終了（ａｃｔ００４）の間に該当するので、催促ありと判定する。

また、案件００００００２についての催促は、催促実行者ＩＤ（Ｕ００３）は、ログインユーザーＩＤ（Ｕ００３）と一致するため、催促ありと判定する。

２１０３において、ワークフロー操作用端末は、ユーザーによる催促する案件の選択を受け付け、ワークフローサーバへ通知する。

ここで、ユーザーが、「予定」の案件を選択した場合、現在処理待ちとなっている承認ユーザーが特定されて画面に表示される（図３２）。対応する案件ＩＤと図１０に示すワークアイテム１０２の状態において「処理待ち」となっている担当者が対象として特定されることとなる。そして、ユーザーにより催促の指示がなされることによりその指示がワークフローサーバへ送信される。催促の指示がなされることにより、催促処理が実行されるが、処理の詳細は後述する。

また、ユーザーが案件を選択することなく、予め定めた条件に合致する「予定」案件がある場合や全ての「予定」案件について、ユーザーの操作を介することなく、直ちに催促の処理を行う実施の形態をとることも可能である。

更に、選択した案件を、「選択をしたユーザー」か「催促をするアクティビティの承認者の次の承認者」からの催促であるかを選択することを可能とする。図３０は、催促するユーザーを選択する画面である。３００１にチェックを入れることにより「催促をするアクティビティの承認者の次の承認者」からの催促を選択することができる。これにより、図８のアクティビティにおいて、「経理担当者」が「課長」に催促をした場合であっても、「課長」に対しては、「部長」から催促があったように通知がなされる。これは、通常、ワークフロー処理の流れにおいて、自分の直後の承認者は分かっていても、次の次など、離れた先の承認者を知らないことが多いため、直後の承認者により催促がされたように見せることで実効性のある催促を実現することができる。なお、チェックが入れられた場合、後の処理で、催促実行者のＩＤを置き換える必要があるため、ここでは、置き換え情報としてメモリに一時的に記憶しておく。

２１０４において、ワークフローサーバは、催促処理（後ろから）を行う。なお、催促処理については後に説明する。

以上により、後ろからの催促をすることができるようになる。

続いて、図３３にその他のワークフローシステムにおける処理の流れを説明する。

本フローチャートは、ユーザーがワークフロー操作用端末を操作して、操作に応じた処理をワークフローサーバが行うものである。

まず、最初にワークフロー操作用端末は、ユーザー操作に応じてワークフローサーバへのログイン画面を表示装置へ表示させる（３３０１）。そして、入力された認証情報をワークフローサーバへ送信する。

３３０２において、ワークフローサーバは、案件選択画面をワークフロー操作用端末へ送信し、ワークフロー操作用端末は、案件選択画面を表示する。

案件選択画面の一例を図３４に示す。この案件選択画面からユーザーは、「処理待ち案件を一覧表示する場合（３４０１）」、「催促ありの処理待ち案件を一覧表示する場合（３４０２）」、「処理予定の案件を一覧表示する場合（３４０３）」の３つの一覧表示を選択することができる。

「処理待ち案件を一覧表示する場合」は、通常の画面であって、ログインユーザーの処理待ちとなっている案件の一覧を確認することができる画面である。

「催促ありの処理待ち案件を一覧表示する場合」は、ログインユーザーの処理待ちとなっている案件でかつ、その案件に催促がある案件の一覧を確認することができる画面である。催促がある案件を優先的に処理する場合等に有効な画面となる。

「処理予定の案件を一覧表示する場合」は、ログインユーザーが将来処理することとなる案件の一覧を確認することができる画面である。催促をすべき案件を抽出する場合等に有効な画面となる。

３３０３において、ワークフロー操作用端末は、ユーザー操作に応じてワークフローサーバへ選択された画面の種類を判定して、その判定結果をワークフローサーバへ送信する。

３３０４において、ワークフローサーバは、処理待ち案件一覧を表示する処理を行い、その一覧画面情報をワークフロー操作端末へ送信する。ワークフロー操作端末では、一覧画面情報を用いて、画面に一覧を表示する。

なお、処理待ち案件一覧に表示する処理待ち案件一覧を取得する処理の流れは、図１７に示す処理待ち一覧を取得するフローチャートにおける１７０１〜１７０２の処理により実現可能である。

３３０５において、ワークフローサーバは、催促あり処理待ち案件一覧を表示する処理を行い、その一覧画面情報をワークフロー操作端末へ送信する。ワークフロー操作端末では、一覧画面情報を用いて、画面に一覧を表示する（図３１の３１０３）。

なお、催促あり処理待ち案件一覧に表示する催促あり処理待ち案件一覧を取得する処理の流れは、図１７に示す処理待ち一覧を取得するフローチャートの処理により実現可能である。

３３０６において、ワークフローサーバは、予定案件一覧を表示する処理を行い、その一覧画面情報をワークフロー操作端末へ送信する。ワークフロー操作端末では、一覧画面情報を用いて、画面に一覧を表示する（図３１の３１０２）。

なお、予定案件一覧に表示する予定案件一覧を取得する処理の流れは、図１７に示す処理待ち一覧を取得するフローチャートにおいて「処理待ち」を「予定」と置き換えることにより対応する。

３３０７において、ワークフロー操作端末は、表示された一覧画面からユーザーによりから案件の選択を受け付ける。

３３０８において、ワークフロー操作端末は、選択された案件に対して「催促」の操作がなされたかを判定する。Ｙｅｓの場合、３３１０へ進み、Ｎｏの場合、３３０９へ進む。具体的には、一覧画面のメニュー等から「催促」する項目の選択がなされたかにより判定を行う。また、その際は、催促を行うユーザーの指定を受け付けて、ワークフローサーバへ指定を行う。なお、催促を行うユーザーの抽出方法は、上述した通りであるため説明を省略する。また、催促には「前から」と「後ろか」の２つあり、その種類もワークフローサーバへ通知される。

３３０９において、ワークフローサーバは、ワークフロー操作端末からなされた指示に応じて配送処理を行う。この配送処理は従来の配送処理と同じである。

３３１０において、ワークフローサーバは、催促処理を行う。催促処理（前から、後ろか）は、上述した通りなので説明を省略する。

以上、その他のワークフローシステムにおける処理の流れを説明した。

次に、ワークフローシステムにおける配送処理の流れを説明する。

図２２は、ワークフローシステムにおける配送処理の流れを示すフローチャートである。本処理はワークフローサーバにおいて処理がなされる。

ここでは、インプット情報として、ログインユーザーＩＤ、申請部門ＩＤ、申請ロールＩＤ、業務ＩＤ、プロセスＩＤ、ワークアイテムＩＤ、入力内容、催促有無（「あり」、「なし」）、処理区分（「新規申請」、「再申請」、「承認」、「差戻」、「否決」）が入力されるものとする。

２２０１において、ワークフローサーバは、処理区分を判定する。新規申請の場合、２２０４へ進み、その他の場合、２２０２へ進む。例えば、承認者が案件詳細画面（図１９）で、承認のボタンを押せば処理区分は承認となる。同様に差戻のボタンを押せば差戻となり、否決のボタンを押せば否決となる。新規申請と、再申請は、呼出元フローが異なる（図１１の１１１０、図１６の１６０６）。

２２０２において、ワークフローサーバは、「処理待ち」ワークアイテムを削除する。再申請、承認、差戻、否決を行ったアクティビティに対応する「処理待ち」のワークアイテムを削除する。例えば、図１０の案件００００００１は観音花子の処理待ちの状態である。この状態で、観音花子が承認した場合、承認を行ったアクティビティはａｃｔ００１であり、対応するワークアイテムで「処理待ち」のものを削除する。

２２０３において、ワークフローサーバは、入力内容の更新を行う。エンドユーザーが入力した内容で、入力内容を更新する。

２２０４において、ワークフローサーバは、案件の新規作成を行う。（案件ＩＤ：新規発番、業務ＩＤ：インプット情報の「業務ＩＤ」、申請部門ＩＤ：インプット情報の「申請部門ＩＤ」、申請ロールＩＤ：インプット情報の「申請ロールＩＤ」）
２２０５において、ワークフローサーバは、エンドユーザーが入力した内容で、入力内容を新規作成する。

２２０６において、ワークフローサーバは、「処理済」ワークアイテム作成を行う（＝処理を行ったアクティビティに対応する「処理済み」のワークアイテムを作成する。）
例えば、図１０の案件００００００１は観音花子の処理待ちである。この状態で、観音花子が承認した場合、承認を行ったアクティビティはａｃｔ００１であり、対応するワークアイテムで「処理済み」のものを作成する。

例えば、例観音太郎が新規申請した場合には、申請を行ったアクティビティはａｃｔ０００であり、対応するワークアイテムで「処理済み」のものを作成する。

２２０７において、ワークフローサーバは、処理区分を判定する。否決の場合、２２２２へ進み、その他の場合、２２０８へ進む。

２２０８において、ワークフローサーバは、処理区分を判定する。差戻の場合、２２１０へ進み、その他の場合、２２０９へ進む。

２２０９において、ワークフローサーバは、配送先アクティビティを求める。

例えば、図８で観音太郎が申請した場合、処理を行ったアクティビティはａｃｔ０００であり、配送先のアクティビティはａｃｔ００１となる。また、観音花子（課長）が承認した場合は、処理を行ったアクティビティはａｃｔ００１であり、配送先のアクティビティはａｃｔ００２となる。また、観音金太郎（部長）が承認した場合は、処理を行ったアクティビティはａｃｔ００２であり、配送先のアクティビティはａｃｔ００３となる。また、観音次郎（経理担当）が承認した場合は、処理を行ったアクティビティはａｃｔ００３であり、配送先のアクティビティはａｃｔ００４となる。

ここでの処理の詳細を、図２３に示す。

図２３は、ワークフローサーバにおける次のユーザー実行アクティビティを求める処理の流れを示すフローチャートである。

インプット情報として、案件ＩＤと入力アクティビティＩＤが入力される。

２３０１において、ワークフローサーバは、対象アクティビティの属性を判定する。分岐条件の場合、２３０３へ進み、その他の場合、２３０２へ進む。

２３０２において、ワークフローサーバは、次のアクティビティを求める。例えば、図１０の１０４でａｃｔ００３の次はａｃｔ００４である。

２３０３において、ワークフローサーバは、次のアクティビティを求める。条件分岐から伸びているすべてのトランジションの条件の中から成立するものを見つけ、そのトランジションにつながるアクティビティを次のアクティビティとする。例えば、図４で、４０２の次は、条件によって、４０３か４０５になる。

２３０４において、ワークフローサーバは、次のアクティビティの属性を判定する。終了の場合、２３０７へ進み、ユーザー実行の場合、２４０６へ進み、その他の場合、２３０５へ進む。

２３０５において、ワークフローサーバは、次のアクティビティを対象に繰り返し処理を行うために、２３０１へ戻る。

２３０６において、ワークフローサーバは、次のアクティビティを返す。

２３０７において、ワークフローサーバは、終了アクティビティを返す。

一方、２２１０において、ワークフローサーバは、不要となった催促を削除する。次の以下の条件にすべて当てはまる催促を削除し、催促実行者にメール通知する。
（１）「前から」の催促である
（２）催促の開始よりも前（申請側）に差し戻された（差戻し先アクティビティ＜催促開始アクティビティ）
２２１１において、ワークフローサーバは、配送先アクティビティの属性が「終了」であるかどうかを判定する。Ｙｅｓの場合、２２１２へ進み、Ｎｏの場合、２２１９へ進む。
例えば、処理区分が「新規申請」「再申請」「承認」の場合には。２２１２で配送先を求めている。「差戻」の場合には、処理を行ったアクティビティの差戻し先（図７の７１６）が配送先となる。

２２１２において、ワークフローサーバは、処理待ワークアイテムを作成する。この処理の詳細な処理の流れを、図２４を用いて説明する。

ここで、インプット情報は、案件ＩＤと配送先アクティビティＩＤである。

２４０１において、ワークフローサーバは、該当者を求める。そして、２４０２から２４０４において、該当者の数だけ繰り返し処理し、２４０３において、ワークアイテムの作成を行う（ワークアイテムＩＤ：新規発番、アクティビティＩＤ：配送先アクティビティのＩＤ、担当者ＩＤ：該当者のＩＤ、状態：「処理待」）。

２４０１における詳細な処理の流れを、図２５を用いて説明する。

ここで、インプット情報は、案件ＩＤとアクティビティＩＤである。

２５０１において、ワークフローサーバは、ユーザー指定がされているかを判定する（ユーザー指定がされているとは、アクティビティの担当者ＩＤ（図７の７１６）が指定されていることである）。Ｙｅｓの場合、２５０５へ進み、Ｎｏの場合、２５０２へ進む。

２５０２において、ワークフローサーバは、ロールのみの指定であるかを判定する（ロールのみ指定であるとは、アクティビティの担当部門ＩＤ（図７の７１６）に「申請部門と同じ」と指定することである）。Ｙｅｓの場合、２５０３へ進み、Ｎｏの場合、２５０４へ進む。例えば、図８でアクティビティａｃｔ００２は、ロールのみが指定されている。

２５０３において、ワークフローサーバは、部門＆ロールの該当者を求める。部門には案件（インプット情報）の申請部門ＩＤ（図７の７２１）を指定し、ロールにはアクティビティの担当ロールを指定する。最後に、該当者を返して処理を終了する。

２５０４において、ワークフローサーバは、部門＆ロールの該当者を求める。
部門にはアクティビティの担当部門を指定し、ロールにはアクティビティの担当ロールを指定する。最後に、該当者を返して処理を終了する。

この処理の詳細な処理の流れを、図２６を用いて説明する。

ここで、インプット情報は、部門ＩＤとロールＩＤである。

２６０１において、ワークフローサーバは、該当者があるかを判定する。Ｙｅｓの場合、２６０２に進み、Ｎｏの場合、２６０３へ進む。

例えば、図６で、営業１課（Ｃ００１）、課長（Ｒ００１）に該当するユーザーが存在するか判定する場合、ポジション（図６の６０４）を参照し、部門が営業１課（Ｃ００１）で、ロールが課長（Ｒ００１）に該当するレコードは次の通りである。
・ユーザーＩＤ「Ｕ００１」、ロールＩＤ「Ｒ００１」、部門ＩＤ「Ｃ００１」
この情報から該当者は、Ｕ００１の観音花子となる。

２６０２において、ワークフローサーバは、該当者を返して処理を終了する。

２６０３において、ワークフローサーバは、上位部門で繰り返し、２６０１へ戻る。部門の親部門を求める。部門の親部門（図５の５０１）を参照して求める。例えば、図６で、営業１課（Ｃ００１）の親部門は、図６の６０１より、営業部（Ｂ００１）となる。なお、親部門がない場合（＝最上位部門のとき）は、異常系なのでここでは除外している。

２５０５において、ワークフローサーバは、ユーザーＩＤを返し処理を終了する。ユーザーが指定されているケースで、該当者は、指定されたユーザーそのものである。

次に、２２１３において、ワークフローサーバは、予定ワークアイテムを作成する。この処理の詳細な処理の流れを、図２７を用いて説明する。

ここで、インプット情報は、案件ＩＤとアクティビティＩＤ（申請またはユーザー実行アクティビティ）である。

２７０１において、ワークフローサーバは、アクティビティ（インプット情報）の属性が何であるかを判定する。「終了」の場合、終了し、「ユーザー実行」の場合、２７０２へ進み、「条件分岐」の場合、２７０７へ進み、「合流」の場合、２７０９へ進む。

２７０２において、ワークフローサーバは、既に作成済みかどうかを判定する。Ｙｅｓの場合、２７０９へ進み、Ｎｏの場合、２７０３へ進む。具体的には、対象のアクティビティに「予定」のワークアイテムがあるかどうかを調べる。

２７０３において、ワークフローサーバは、対象アクティビティの該当者を求める。なお、この処理の詳細は、図２５および図２６の処理と同じであるため説明を省略する。

そして、２７０４から２７０６において、ワークフローサーバは、該当者の数だけ繰り返し処理し、２７０５において、「予定」ワークアイテムの作成を行う（案件ＩＤ：インプット情報の案件ＩＤ、アクティビティＩＤ：配送先アクティビティのＩＤ、担当者ＩＤ：該当者のＩＤ、状態：「予定」）。

また、２７０７において、ワークフローサーバは、分岐条件の判定を行う。条件分岐から伸びているすべてのトランジションの条件の中から成立するものを見つける。なお、成立するものがないケースや、複数成立してしまう場合は異常系なのでここでは除外する。

２７０８において、ワークフローサーバは、「予定」ワークアイテムを削除する。条件が成立しないトランジション以降、対応する合流までのすべてのアクティビティに対応する「予定」のワークアイテムを削除する。また、削除したワークアイテムから作成した催促を削除する。そして、削除した催促の作成者へメール通知する。例えば、図４のプロセスで、金額を１０万円で申請後、差し戻され、再申請時に４０万円で申請するようなケースで４０３、４０４の予定のワークアイテムを削除する。

２７０９において、ワークフローサーバは、次のアクティビティで繰り返し、２７０１へ戻る。

次に、２２１４において、ワークフローサーバは、催促があるかを判定する。Ｙｅｓの場合、２２１６へ進み、Ｎｏの場合、２２１５へ進む。

２２１５において、ワークフローサーバは、承認依頼メールを送信する。この詳細な処理の流れを、図２８を用いて説明する。

ここで、インプット情報は、「ログインユーザーＩＤ」と「案件ＩＤ」と「配送先アクティビティＩＤ」である。

２８０１において、ワークフローサーバは、承認依頼の文面を作成する。業務名は、案件ＩＤを元に、定義情報（図７）の業務から求める。例えば、「件名：承認依頼が届きました」、「本文：購入精算書（００００００１）の承認依頼が届きました」などとする。この承認依頼のメールは、ワークアイテム１０２で「処理待ち」となっているユーザーに送信するものである。

２８０２から２８０７まで、ワークフローサーバは、催促の数だけ繰り返す。例えば、図１０で案件ＩＤが００００００１の案件を、観音花子（課長）が承認した場合、催促は、案件ＩＤ（インプット情報）を元に、催促テーブル（図１０の１０３）から求める。この処理は、承認依頼メールに、この案件に催促があることを示すための処理である。

２８０３において、ワークフローサーバは、催促をつけるかを判定する。Ｙｅｓの場合、２８０４へ進み、Ｎｏの場合、２８０７へ進む。ここでは、配送先アクティビティが、催促（図７の７２４）の催促開始と催促終了の間にあれば催促ありと判定する（催促開始≦配送先≦催促終了）。例えば、図１０で案件ＩＤが００００００１の案件を、観音花子（課長）が承認した場合、配送先はａｃｔ００２、催促の開始はａｃｔ００１、終了はａｃｔ００４であるため催促ありと判定する。

２８０４において、ワークフローサーバは、催促者を変更するかを判定する。Ｙｅｓの場合、２８０５へ進み、Ｎｏの場合、２８０６へ進む。ここでは、催促（図７の７２４）の催促者変更の有無が有ならば変更すると判定する。

２８０５において、ワークフローサーバは、催促の文面を追加する。ここで、催促者の氏名は、催促実行者ＩＤを元に、組織情報（図５）のユーザー（５０３）から求める（文面例：観音太郎様より催促されています。）。

２８０６において、ワークフローサーバは、催促の文面を追加する。ここで、配送先アクティビティを元に、次のユーザー実行アクティビティを求め（図２３）、そのアクティビティの該当者を求める（図２５）。そして、その該当者を元に、組織情報（図５）のユーザー（５０３）から催促者の氏名を求める（文面例：観音金太郎様より催促されています。）。

２８０８において、ワークフローサーバは、メールを送信する。ここでは、配送先アクティビティの該当者を求め（図２５）、その該当者にメールを送信する。文面は２８０１、２８０５、２８０６で作成したものである。

メール例（件名：承認依頼が届きました。本文：購入精算書（００００００１）の承認依頼が届きました。観音太郎様より催促されています。）。

以上、図２８を用いて、承認依頼メールを送信する一例を示したが、下記のような実施の形態もある。
（１）承認依頼メールとは別に催促メールを送信する実施の形態。これにより、催促を独立したメールで送信することにより、催促対象となっているユーザーに催促を促すことができる。
（２）後ろから催促の場合、処理待ちユーザーに催促をすると同時に、処理待ちユーザーから催促をしたユーザーに至るアクティビティのユーザー（予定ユーザー）に催促をする実施の形態。これにより、ワークフローの流れの中で、処理待ちユーザーとなる毎に、そのユーザーに催促をする場合に比べ、予定となっているユーザーに対しても催促をすることになるため、予め催促を知らしめることが可能となる。

次に、２２１６において、ワークフローサーバは、処理区分を判定する。「差戻」の場合、２２１８へ進み、その他の場合、２２１７へ進む。

２２１７において、ワークフローサーバは、催促を新規に作成する。
・案件ＩＤとして、「案件ＩＤ（インプット情報）」、催促実行者ＩＤとして、「ログインユーザーＩＤ（インプット情報）」、催促実行（アクティビティＩＤ）として、「ワークアイテムＩＤ（インプット情報）に対応するアクティビティＩＤ」、催促開始（アクティビティＩＤ）として、「配送先のアクティビティ」、催促終了（アクティビティＩＤ）として、「終了アクティビティ」、属性として、「前から」、催促者変更の有無として、「無」。

２９１８において、ワークフローサーバは、催促を新規に作成する。
・案件ＩＤとして、「案件ＩＤ（インプット情報）」、催促実行者ＩＤとして、「ログインユーザーＩＤ（インプット情報）」、催促実行（アクティビティＩＤ）として、「ワークアイテムＩＤ（インプット情報）に対応するアクティビティＩＤ」、催促開始（アクティビティＩＤ）として、「配送先のアクティビティ」、催促終了（アクティビティＩＤ）として、「ワークアイテムＩＤ（インプット情報）に対応するアクティビティＩＤ」、属性として、「後ろから」、催促者変更の有無として、「無」。

次に、２２１９において、ワークフローサーバは、申請者にメール通知を行う。ここでは、案件が最終承認されたことを申請者に通知する。

申請者は、申請アクティビティ（図７）に対応するワークアイテム（図７）の担当者ＩＤから求め、メールアドレスは、ユーザーＩＤを元に、組織情報（図５）のユーザーから求める。業務名は、案件ＩＤを元に、定義情報（図７）の業務から求める。

最終承認メール例（件名：購入精算書が最終承認されました。本文：購入精算書（００００００１）が最終承認されました。）。

２２２０において、ワークフローサーバは、催促実行者にメールを通知する。ここでは、案件が最終承認されたことを催促実行者に通知する。

催促実行者は、催促（図７）の催促実行者ＩＤから求め、メールアドレスは組織情報（図５）のユーザーから求める。

メール例（件名：催促していた購入精算書が最終承認されました。本文：催促していた購入精算書（００００００１）が最終承認されました。）。

２２２１において、ワークフローサーバは、案件の催促を削除する。ここでは、案件の催促をすべて削除する。例えば、案件ＩＤ００００００１の案件を最終承認した場合、催促テーブル（図７）で案件ＩＤが００００００１のレコードをすべて削除する。

また、２２２２において、ワークフローサーバは、申請者にメール通知を行う。ここでは、案件が否決されたことを申請者に通知する。

申請者は、申請アクティビティ（図７）に対応するワークアイテム（図７）の担当者ＩＤから求め、メールアドレスは、ユーザーＩＤを元に、組織情報（図５）のユーザーから求める。業務名は、案件ＩＤを元に、定義情報（図７）の業務から求める。

否決メール例（件名：購入精算書が否決されました。本文：購入精算書（００００００１）が否決されました。）。

２２２３において、ワークフローサーバは、催促実行者にメールを通知する。ここでは、案件が否決されたことを催促実行者に通知する。

催促実行者は、催促（図７）の催促実行者ＩＤから求め、メールアドレスは組織情報（図５）のユーザーから求める。

否決メール例（件名：催促していた購入精算書が否決されました。本文：催促していた購入精算書（００００００１）が否決されました。）。

２２２４において、ワークフローサーバは、案件の催促を削除する。ここでは、案件の催促をすべて削除する。例えば、案件ＩＤ００００００１の案件を否決した場合、催促テーブル（図７）で案件ＩＤが００００００１のレコードをすべて削除する。

以上、ワークフローシステムにおける配送処理の流れを説明した。

次に、催促処理（２００４、２１０４、３１１０）の流れを、図２９を用いて説明する。

図２９は、ワークフローシステムにおける催促処理の流れを示すフローチャートである。

ここで、インプット情報は、「ログインユーザーＩＤ」、「案件ＩＤ」、「処理待のアクティビティＩＤ」、「ワークアイテムＩＤ（ログインユーザーが担当のワークアイテム）」、催促の向き」「催促実行者の置き換えの有無」である。

２９０１において、ワークフローサーバは、メール文面を作成する。催促者の氏名は、催促実行者の置き換えの有無（インプット情報）が無ならば、ログインユーザーＩＤを元に、組織情報（図５）のユーザー（５０３）から求め、催促実行者の置き換えの有無が有ならば、催促者の氏名は処理待ちのワークアイテムを元に、次のユーザー実行アクティビティを求め（図２３）、そのアクティビティの該当者を求める（図２５）。そして、その該当者を元に、組織情報（図５）のユーザー（５０３）から催促者の氏名を求める。メール例（件名：催促が届きました。本文：観音太郎様より、購入精算書（００００００１）の催促が届きました。）。

２９０２から２９０７において、ワークフローサーバは、催促の数だけ繰り返す。

２９０３において、ワークフローサーバは、処理待ちユーザーへの催促であるかを判定する。Ｙｅｓの場合、２９０４へ進み、Ｎｏの場合、２９０７へ進む。処理待のアクティビティが、催促開始と催促終了の間かにより判定する。

２９０４において、ワークフローサーバは、催促者を変更するかを判定する。Ｙｅｓの場合、２９０６へ進み、Ｎｏの場合、２９０５へ進む。ここで、催促者を変更するかどうかの判定は、催促（図７）の催促者変更の有無が有ならば変更すると判定する。

２９０５において、ワークフローサーバは、催促の文面を追加する。ここでは、催促者の氏名は、催促実行者ＩＤを元に、組織情報（図５）のユーザー（５０３）から求める（文面例：観音太郎様より催促されています。）。

２９０６において、ワークフローサーバは、催促の文面を追加する。ここで、処理待ちのワークアイテムを元に、次のユーザー実行アクティビティを求め（図２３）、そのアクティビティの該当者を求める（図２５）。そして、その該当者を元に、組織情報（図５）のユーザー（５０３）から催促者の氏名を求める（文面例：観音金太郎様より催促されています。）。

２９０８において、ワークフローサーバは、メールを送信する。ここでは、宛先は処理待のアクティビティＩＤ（インプット情報）の担当者である。

２９０９において、ワークフローサーバは、催促の向きを判定する。「前から」の場合、２９１０へ進み、「後ろから」の場合、２９１１へ進む。

２９１０において、ワークフローサーバは、催促の作成を行う。ここでは、催促を新規に作成する。
・案件ＩＤとして、「案件ＩＤ（インプット情報）」、催促実行者ＩＤとして、「ログインユーザーＩＤ（インプット情報）」、催促実行（アクティビティＩＤ）として、「ワークアイテムＩＤ（インプット情報）に対応するアクティビティＩＤ」、催促開始（アクティビティＩＤ）として、「処理待のアクティビティ」、催促終了（アクティビティＩＤ）として、「終了アクティビティ」、属性として、「前から」、催促者変更の有無として、「無」。

２９１１において、ワークフローサーバは、催促の作成を行う。ここでは、催促リストの要素を新規に作成する。
・案件ＩＤとして、「案件ＩＤ（インプット情報）」、催促実行者ＩＤとして、「ログインユーザーＩＤ（インプット情報）」、催促実行（アクティビティＩＤ）として、「ワークアイテムＩＤ（インプット情報）に対応するアクティビティＩＤ」、催促開始（アクティビティＩＤ）として、「処理待のアクティビティ」、催促終了（アクティビティＩＤ）として、「ワークアイテムＩＤ（インプット情報）に対応するアクティビティＩＤ」、属性として、「後ろから」、催促者変更の有無として、「催促者変更の有無（インプット情報）」。

以上、催促処理（２００４、２１０４）の流れを説明した。

上述した通り、本発明によれば、ワークフロー処理の流れにおいて、後ろのアクティビティの承認を行うユーザーから前のアクティビティの承認を行うユーザーに対して催促することができるワークフローシステムを提供することが可能となる。

例えば、後ろのアクティビティの承認を行うユーザーが、休暇により不在となる前に、自分が承認を行うユーザーとして設定されているプロセスにおいて、前のアクティビティの承認を行うユーザーに対して催促をすることで、休暇前にそのプロセスの承認処理を終わらせることが可能となる。そのため、期限が迫っているプロセスを速やかに終わらせようとする場合などに、特に有用な機能である。

また、ワークフロー処理の流れにおいて、後ろのアクティビティの承認者に対して催促することができるワークフローシステムを提供することが可能となる。

以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

また、本発明におけるプログラムは、本発明に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体はコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは各装置の処理方法ごとのプログラムであってもよい。

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

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

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

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

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

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

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

１０１ ＣＰＵ７
１０２ ＲＡＭ
１０３ ＲＯＭ
１０４ ＨＤ
１０６ 入力装置
１０７ 表示装置
１０８ 通信インタフェース

Claims (12)

1. 申請された案件についてのワークフロー処理を行う情報処理装置であって、
   前記案件の各アクティビティに対応する担当者および状態を記憶する案件状態記憶手段と、
   第一のユーザーからなされる案件表示の要求を受け付ける要求受付手段と、
   前記要求受付手段により受け付けた要求が、前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する要求であるか、前記第一のユーザーが処理すべきアクティビティにある案件を抽出する要求であるかを判定する判定手段と、
   前記判定手段による判定の結果、前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する要求であると判定された場合、前記案件状態記憶手段に記憶された案件状態に応じて前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出し、該抽出した「前記第一のユーザーが処理をする予定となっている案件」を表示し、一方、前記第一のユーザーが処理すべきアクティビティにある案件を抽出する要求であると判定された場合、前記案件状態記憶手段に記憶された案件状態に応じて前記第一のユーザーが処理すべきアクティビティを含む案件を抽出し、抽出した「前記第一のユーザーが処理すべきアクティビティにある案件」を表示する案件抽出手段と、を備えることを特徴とする情報処理装置。
2. 前記案件抽出手段により抽出された案件から、前記第一のユーザーが処理するアクティビティより前のアクティビティの処理をする第二のユーザーに対して催促をする案件を、前記案件抽出手段により抽出された案件の一覧情報が表示された表示画面を介して受け付ける第一の受付手段と、
   前記第一の受付手段により受け付けた案件について、前記第一のユーザーが処理するアクティビティより前に当該案件のアクティビティの処理をすべき前記第二のユーザーに対して、当該案件のアクティビティの処理を行うことを催促する第一の催促手段と
   を備えることを特徴とする請求項１記載の情報処理装置。
3. 前記第一の催促手段は、前記催促を開始するアクティビティと催促を終了するアクティビティを指定可能であり、前記指定された前記催促を開始するアクティビティと前記催促を終了するアクティビティの間のアクティビティに対して催促することを特徴とする請求項２記載の情報処理装置。
4. 前記第二のユーザーは、前記第一のユーザーが処理するアクティビティに至るまでの各アクティビティの処理をすべき各ユーザーを含み、
   前記第一の催促手段は、前記第一のユーザーが処理するアクティビティに至るまでの各アクティビティの処理をすべき第二のユーザーに対して、当該案件のアクティビティの処理を行うことをそれぞれ催促することを特徴とする請求項２または３記載の情報処理装置。
5. 前記第一の催促手段は、前記第二のユーザーに対して催促を行う場合、当該第二のユーザーが処理するアクティビティの次のアクティビティの処理を行うことになるユーザーからの催促であるとして催促を行うことを特徴とする請求項２乃至４の何れか１項に記載の情報処理装置。
6. ワークフローの流れにおいて前記案件の処理が否決または差し戻されることにより、前記第一の催促手段による催促が必要なくなった場合、前記第一のユーザーに対してその旨を通知する第二の通知手段を更に備えることを特徴とする請求項２乃至５の何れか１項に記載の情報処理装置。
7. 前記第一の催促手段による催促の対象となる最後の前記第二のユーザーにより前記案件のアクティビティの処理がなされた場合、その旨を通知する第一の通知手段を更に備えることと特徴とする請求項２乃至６の何れか１項に記載の情報処理装置。
8. 前記第一のユーザーが処理すべきアクティビティを含む案件を抽出する第二の案件抽出手段と、
   前記第二の案件抽出手段により抽出された案件から、前記第一のユーザーが処理するアクティビティより後のアクティビティの処理をする第三のユーザーに対して催促をする案件を受け付ける第二の受付手段と、
   前記第二の受付手段により受け付けた案件について、前記第一のユーザーが処理すべきアクティビティより後に当該案件のアクティビティの処理をする前記第三のユーザーに対して、当該案件のアクティビティの処理を行うことを催促する第二の催促手段とを更に備えることを特徴とする請求項２乃至７の何れか１項に記載の情報処理装置。
9. 前記第一の催促手段は、前記第一のユーザーが処理するアクティビティより前に当該案件のアクティビティの処理をすべき前記第二のユーザーに対して催促を行い、当該第一のユーザーが処理するアクティビティより後に当該案件のアクティビティの処理をする前記第三のユーザーに対しては催促を行わず、
   前記第二の催促手段は、前記第一のユーザーが処理すべきアクティビティより後に当該案件のアクティビティの処理をするすべての前記第三のユーザーに対して催促を行うことを特徴とする請求項８に記載の情報処理装置。
10. クライアント端末と、申請された案件についてのワークフロー処理を行う情報処理装置とがネットワークを介して通信可能な情報処理システムであって、
    前記案件の各アクティビティに対応する担当者および状態を記憶する案件状態記憶手段と、
    第一のユーザーからなされる案件表示の要求を受け付ける要求受付手段と、
    前記要求受付手段により受け付けた要求が、前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する要求であるか、前記第一のユーザーが処理すべきアクティビティにある案件を抽出する要求であるかを判定する判定手段と、
    前記判定手段による判定の結果、前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する要求であると判定された場合、前記案件状態記憶手段に記憶された案件状態に応じて前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出し、該抽出した「前記第一のユーザーが処理をする予定となっている案件」を表示し、一方、前記第一のユーザーが処理すべきアクティビティにある案件を抽出する要求であると判定された場合、前記案件状態記憶手段に記憶された案件状態に応じて前記第一のユーザーが処理すべきアクティビティを含む案件を抽出し、抽出した「前記第一のユーザーが処理すべきアクティビティにある案件」を表示する案件抽出手段と、を備えることを特徴とする情報処理システム。
11. 申請された案件についてのワークフロー処理を行う、前記案件の各アクティビティに対応する担当者および状態を記憶する案件状態記憶手段を備える情報処理装置における情報処理方法であって、
    第一のユーザーからなされる案件表示の要求を受け付ける要求受付ステップと、
    前記要求受付ステップにより受け付けた要求が、前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する要求であるか、前記第一のユーザーが処理すべきアクティビティにある案件を抽出する要求であるかを判定する判定ステップと、
    前記判定ステップによる判定の結果、前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する要求であると判定された場合、前記案件状態記憶手段に記憶された案件状態に応じて前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出し、該抽出した「前記第一のユーザーが処理をする予定となっている案件」を表示し、一方、前記第一のユーザーが処理すべきアクティビティにある案件を抽出する要求であると判定された場合、前記案件状態記憶手段に記憶された案件状態に応じて前記第一のユーザーが処理すべきアクティビティを含む案件を抽出し、抽出した「前記第一のユーザーが処理すべきアクティビティにある案件」を表示する案件抽出ステップと、を備えることを特徴とする情報処理方法。
12. 申請された案件についてのワークフロー処理を行う、前記案件の各アクティビティに対応する担当者および状態を記憶する案件状態記憶手段を備える情報処理装置において実行可能なプログラムであって、
    第一のユーザーからなされる案件表示の要求を受け付ける要求受付手段と、
    前記要求受付手段により受け付けた要求が、前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する要求であるか、前記第一のユーザーが処理すべきアクティビティにある案件を抽出する要求であるかを判定する判定手段と、
    前記判定手段による判定の結果、前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する要求であると判定された場合、前記案件状態記憶手段に記憶された案件状態に応じて前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出し、該抽出した「前記第一のユーザーが処理をする予定となっている案件」を表示し、一方、前記第一のユーザーが処理すべきアクティビティにある案件を抽出する要求であると判定された場合、前記案件状態記憶手段に記憶された案件状態に応じて前記第一のユーザーが処理すべきアクティビティを含む案件を抽出し、抽出した「前記第一のユーザーが処理すべきアクティビティにある案件」を表示する案件抽出手段と、を備えることを特徴とする情報処理装置を機能させることを特徴とするプログラム。

Images