申請された案件についてのワークフロー処理を行う情報処理装置であって、第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する第一の案件抽出手段と、前記第一の案件抽出手段により抽出された案件から、前記第一のユーザーが処理するアクティビティより前のアクティビティの処理をする第二のユーザーに対して催促をする案件を受け付ける第一の受付手段と、前記第一の受付手段により受け付けた案件について、前記第一のユーザーが処理するアクティビティより前に当該案件のアクティビティの処理をすべき前記第二のユーザーに対して、当該案件のアクティビティの処理を行うことを催促する第一の催促手段とを備えることを特徴とする情報処理装置。前記第二のユーザーは、前記第一のユーザーが処理するアクティビティに至るまでの各アクティビティの処理をすべき各ユーザーを含み、前記第一の催促手段は、前記第一のユーザーが処理するアクティビティに至るまでの各アクティビティの処理をすべき第二のユーザーに対して、当該案件のアクティビティの処理を行うことをそれぞれ催促することを特徴とする請求項1に記載の情報処理装置。前記第一の催促手段は、前記第二のユーザーに対して催促を行う場合、当該第二のユーザーが処理するアクティビティの次のアクティビティの処理を行うことになるユーザーからの催促であるとして催促を行うことを特徴とする請求項1または2に記載の情報処理装置。ワークフローの流れにおいて前記案件の処理が否決または差し戻されることにより、前記第一の催促手段による催促が必要なくなった場合、前記第一のユーザーに対してその旨を通知する第二の通知手段を更に備えることを特徴とする請求項1乃至3の何れか1項に記載の情報処理装置。前記第一の催促手段による催促の対象となる最後の前記第二のユーザーにより前記案件のアクティビティの処理がなされた場合、その旨を通知する第一の通知手段を更に備えることと特徴とする請求項1乃至4の何れか1項に記載の情報処理装置。前記第一のユーザーが処理すべきアクティビティを含む案件を抽出する第二の案件抽出手段と、前記第二の案件抽出手段により抽出された案件から、前記第一のユーザーが処理するアクティビティより後のアクティビティの処理をする第三のユーザーに対して催促をする案件を受け付ける第二の受付手段と、前記第一の受付手段により受け付けた案件について、前記第一のユーザーが処理すべきアクティビティより後に当該案件のアクティビティの処理をする前記第三のユーザーに対して、当該案件のアクティビティの処理を行うことを催促する第二の催促手段とを更に備えることを特徴とする請求項1乃至5の何れか1項に記載の情報処理装置。前記第一の催促手段は、前記第一のユーザーが処理するアクティビティより前に当該案件のアクティビティの処理をすべき前記第二のユーザーに対して催促を行い、当該第一のユーザーが処理するアクティビティより後に当該案件のアクティビティの処理をする前記第三のユーザーに対しては催促を行わず、前記第二の催促手段は、前記第一のユーザーが処理すべきアクティビティより後に当該案件のアクティビティの処理をするすべての前記第三のユーザーに対して催促を行うことを特徴とする請求項6に記載の情報処理装置。申請された案件についてのワークフロー処理を行う情報処理装置であって、第一のユーザーからなされる案件表示の要求を受け付ける要求受付手段と、前記要求受付手段により受け付けた要求の内容に応じて、前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する要求であるか、前記第一のユーザーが処理すべきアクティビティを含む案件を抽出する要求であるかを判定する判定手段と、前記判定手段による判定の結果、前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する要求であると判定された場合、前記第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出し、前記第一のユーザーが処理すべきアクティビティを含む案件を抽出する要求であると判定された場合、前記第一のユーザーが処理すべきアクティビティを含む案件を抽出する案件抽出手段とを備えることを特徴とする情報処理装置。前記第一または第二の催促手段、もしくは前記第一または第二の通知手段は、電子メールにより催促、もしくは通知することを特徴とする請求項1乃至8の何れか1項に記載の情報処理装置。クライアント端末と、申請された案件についてのワークフロー処理を行う情報処理装置とがネットワークを介して通信可能な情報処理システムであって、第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する第一の案件抽出手段と、前記第一の案件抽出手段により抽出された案件から、前記第一のユーザーが処理するアクティビティより前のアクティビティの処理をする第二のユーザーに対して催促をする案件を受け付ける第一の受付手段と、前記第一の受付手段により受け付けた案件について、前記第一のユーザーが処理するアクティビティより前に当該案件のアクティビティの処理をすべき前記第二のユーザーに対して、当該案件のアクティビティの処理を行うことを催促する第一の催促手段とを備えることを特徴とする情報処理システム。申請された案件についてのワークフロー処理を行う情報処理装置における情報処理方法であって、第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する第一の案件抽出ステップと、前記第一の案件抽出ステップにより抽出された案件から、前記第一のユーザーが処理するアクティビティより前のアクティビティの処理をする第二のユーザーに対して催促をする案件を受け付ける第一の受付ステップと、前記第一の受付ステップにより受け付けた案件について、前記第一のユーザーが処理するアクティビティより前に当該案件のアクティビティの処理をすべき前記第二のユーザーに対して、当該案件のアクティビティの処理を行うことを催促する第一の催促ステップとを備えることを特徴とする情報処理方法。申請された案件についてのワークフロー処理を行う情報処理装置において実行可能なプログラムであって、第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する第一の案件抽出手段、前記第一の案件抽出手段により抽出された案件から、前記第一のユーザーが処理するアクティビティより前のアクティビティの処理をする第二のユーザーに対して催促をする案件を受け付ける第一の受付手段、前記第一の受付手段により受け付けた案件について、前記第一のユーザーが処理するアクティビティより前に当該案件のアクティビティの処理をすべき前記第二のユーザーに対して、当該案件のアクティビティの処理を行うことを催促する第一の催促手段として前記情報処理装置を機能させることを特徴とするプログラム。請求項12に記載のコンピュータプログラムをコンピュータ読み取り可能に記憶した記録媒体。しかしながら、特許文献1に記載の技術のように、スキップし、最終的にプロセスに参加するという方法では、ユーザーがプロセスに参加する順序が変わってしまうため、意図した意思決定の手順がなされないという問題点が生じることとなる。そのため、ユーザーがプロセスに参加する順序を変えることなく、プロセスの完了に費やす時間を短縮化する方法が求められる。ところで、処理待ちのまま滞留している場合、承認者は、操作そのものを忘れていることが多い。そのため、停滞中のアクティビティを例えば、ワークフロー処理の流れにおける後ろの承認者から、その停滞しているアクティビティの承認者に対して催促することができれば、ユーザーがプロセスに参加する順序を変えることなく、プロセスの完了に費やす時間を短縮化することが可能となる。一方、申請者あるいは承認者が、自分より後ろの承認者に対して、本プロセスを早く進めるための催促をすることができれば、同様にユーザーがプロセスに参加する順序を変えることなく、プロセスの完了に費やす時間を短縮化することが可能となる。そこで、本発明は、上記課題を解決するものであり、ワークフロー処理の流れにおいて、後ろのアクティビティの承認を行うユーザーから前のアクティビティの承認を行うユーザーに対して催促することができるワークフローシステムを提供することを目的とする。本発明は、申請された案件についてのワークフロー処理を行う情報処理装置であって、第一のユーザーからの要求に応じて、当該第一のユーザーが処理をする予定となっているアクティビティを含む案件を抽出する第一の案件抽出手段と、前記第一の案件抽出手段により抽出された案件から、前記第一のユーザーが処理するアクティビティより前のアクティビティの処理をする第二のユーザーに対して催促をする案件の選択を受け付ける第一の選択受付手段と、前記第一の選択受付手段により選択を受け付けた案件について、前記第一のユーザーが処理するアクティビティより前に当該案件のアクティビティの処理をすべき前記第二のユーザーに対して、当該案件のアクティビティの処理を行うことを催促する第一の催促手段とを備えることを特徴とする。本発明によれば、ワークフロー処理の流れにおいて、後ろのアクティビティの承認を行うユーザーから前のアクティビティの承認を行うユーザーに対して催促することができるワークフローシステムを提供することが可能となる。以下、図面を参照して、本発明の詳細を説明する。図1は、本実施形態が適用されるワークフローシステムの概略構成を示す図である。実施形態におけるワークフローシステムは、ワークフロー及び伝票設計用コンピュータ端末ワークフロー及び伝票設計用端末400、業務を遂行する処理者担当者に対応して設けられたワークフロー操作用コンピュータ端末ワークフロー操作用端末300、ワークフローを実行するための各種テーブル、各種プログラムを格納するワークフローサーバ情報処理装置200を備えている。これらワークフロー及び伝票設計用端末400、ワークフロー操作用端末300、ワークフローサーバ200は、それぞれネットワーク500に接続され運用されている。ワークフロー及び伝票設計用端末400は、伝票デザイナプログラム401及びシステム管理プログラム402を有し、ワークフローシステムにて使用する伝票の定義体の作成及びワークフローシステムで利用する各種定義情報の作成を行う。例えば、ワークフロー及び伝票設計用端末400は、ワークフローサーバ200に部門テーブル、業務テーブル等を登録することができる。このワークフロー及び伝票設計用端末400は、これらの作業を行うために、自己の識別情報を入力することによりワークフローサーバ200に接続することが可能になる。ワークフロー操作用端末300は、ワークフロー操作用端末300上で実行されるWebブラウザ301を用いて、伝票に関するアクセス情報をワークフローサーバ200に対してHTTPで送信し、その結果を受信するものであり、その際に、発生する表示計算処理は、Java登録商標アプレット302等を利用することにより実行する。なお、このワークフロー操作用端末300は、予め指定された所定の業務を行う担当者例えば、起票者、課長、部長等に配置されている。ワークフローサーバ200は、ワークフローシステムに関する情報後述する図5の組織情報、各種伝票情報後述する図7の定義情報、ジョブ情報を格納するRDBMSRelationalDataBaseManagementSystem205、ワークフロー操作用端末300よりの要求を受け付けて要求を実行するためのHTTPサーバ201、サーブレットエンジン202、ワークフロープログラム203、ワークフロー通知機能を実現するSMTPサーバ204にて構成されている。以下、図2を参照して、図1に示したワークフローサーバ200、ワークフロー操作用端末300、ワークフロー及び伝票設計用端末400に適用可能なコンピュータのハードウェア構成について説明する。図2は、図1に示したワークフローサーバ200、ワークフロー操作用端末300、ワークフロー及び伝票設計用端末400に適用可能なコンピュータのハードウェア構成の一例を示すブロック図である。図2において、101はCPUで、ROM103又はハードディスクHDその他の記憶装置、例えば、フレキシブルディスク、CD-ROM、DVD-ROM等どのような記憶装置であってもよい104に格納されたプログラムをRAM102上にロードして実行することにより、コンピュータ全体を制御する。RAM102は、CPU101の作業領域として使用される。108は通信インタフェースで、通信ネットワーク500への接続を可能とする。106は入力装置で、キーボードやマウス等のポインティングデバイス等に相当する。107は表示装置で、CRT、LCD等で構成される。なお、図1に示したワークフローサーバ200のRDBMS205は、ワークフローサーバ200のHD104内に構築されている。また、ワークフローサーバ200のHTTPサーバ201、サーブレットエンジン202、ワークフロープログラム203、SMTPサーバ204は、ワークフローサーバ200のCPU101が、HD104に格納されるプログラムをRAM102上にロードして実行することにより、実現される。また、図1に示したワークフロー操作用端末300のWebブラウザ301は、ワークフロー操作用端末300のCPU101が、HD104に格納されるプログラムをRAM102上にロードして実行することにより、実現される。さらに、図1に示したワークフロー操作用端末300のJava登録商標アプレット302は、ワークフロー操作用端末300のCPU101が、ワークフローサーバ200よりダウンロードされたプログラムをWebブラウザ301上で実行することにより、実現される。また、図1に示したワークフロー及び伝票設計用端末400の伝票デザイナプログラム401、システム管理プログラム402は、ワークフロー及び伝票設計用端末400のCPU101が、HD104に格納されるプログラムをRAM102上にロードして実行することにより、実現される。図3は、アクティビティとトランジションの関係を示す図である。アクティビティとは、ワークフローを構成する処理工程を指すものである。トランジションとは、アクティビティとアクティビティとの処理の順序を規定するものである。図3の例では、アクティビティとして、申請アクティビティ301、ユーザー実行アクティビティ302~304、終了アクティビティ305が存在する。それぞれのアクティビティは、トランジション306~309によりそれぞれ順序が規定されている。図4は、分岐がある場合のアクティビティとトランジションの一例を示す図である。申請アクティビティ401と条件分岐アクティビティ402がトランジションにより順序が規定されている。この例では、条件分岐の条件式として、申請金額が30万円を下回る場合と申請金額が30万円以上の場合とで分岐する。申請金額が30万円を下回る場合は、ユーザー実行アクティビティ403へトランジションが続き、更に、ユーザー実行アクティビティ404へと順序を辿る。一方、申請金額が30万円以上の場合は、ユーザー実行アクティビティ405へトランジションが続き、更に、ユーザー実行アクティビティ406へと順序を辿る。そして、ユーザー実行アクティビティ404とユーザー実行アクティビティ406とは、合流アクティビティ407で合流する。その後、ユーザー実行アクティビティ408、終了アクティビティ409の順序で処理が終了する。なお、本実施の形態におけるワークフローシステムにおいては、条件分岐は新規申請時に決まるものとしている。図5は、組織情報を構成するテーブルの一例を示す図である。組織情報は、部門テーブル501、ロールテーブル502、ユーザーテーブル503、ポジションテーブル504から構成される。部門501は、部門ID、部門名、レベル番号、親部門IDを含む。ロール502は、ロールID、ロール名を含む。ユーザー503は、ユーザーID、氏名、メールアドレス、パスワードを含む。ポジション504は、ユーザーID、ロールID、部門IDを含む。なお、ポジションとは、ユーザーが所属する部門とロールの組のことをいう。図6に、組織情報の具体例を示す。組織情報の各テーブルの具体例とそれを組織票として図表化した例を示す。この例では、部門テーブル601の通り、観音株式会社、営業部、管理部、営業1課、営業2課という組織が存在している。また、ユーザーテーブル603の通り、観音太郎、観音花子、観音金太郎、観音次郎というユーザーが存在し、それぞれが一般職、課長、部長、経理担当といった役割を持っているロールテーブル602とポジションテーブル604より。図7は、定義情報とジョブ情報の関係を示す図である。定義情報71は、ワークフローにおける業務を定義する情報であり、設計者が予め定義するものである。なお、図中の1とは、1対多の関係にあることを示している。業務711に対して、プロセス712、フォーム713、ユニット714、スキーマ715が、紐付いている。また、プロセス712に対して、アクティビティ716、トランジション717が紐付いている。更に、ジョブ情報72の案件721と紐付いている。ジョブ情報72とは、ワークフローにおいて起案されたジョブに関する定義情報である。案件721に対して、ワークアイテム722、入力内容723、催促724が紐付いている。なお、定義情報71は、従来からあるものである。また、ジョブ情報72のうち、案件721、ワークアイテム722、入力内容723は、従来からあるものであるが、催促724は、本発明を実施するために新たに加わった定義である。図8は、定義情報の一例を示すデータテーブルである。この定義情報は、図6の組織情報の例を前提としている。業務81において、業務ID、業務名が定義され、この例では、業務IDとしてGID001、業務名として購入申請書が定義されている。また、プロセス82において、業務ID、プロセスID、申請可能部門IDが定義され、この例では、業務IDGID001、プロセスIDPID001、申請可能部門IDB001が定義されている。アクティビティ83において、プロセスID、アクティビティID、担当者ID、担当ロールID、担当部門ID、属性、差戻し先、フォームIDが定義される。ここでは、複数のレコードが定義される。なお、アクティビティの担当部門には申請者の部門と同じという指定が可能である。この場合、担当部門に申請者の部門を指定したのと同じ動作をする。最後に、この業務名購入申請書についてのアクティビティを図示したものを85へ示す。図9は、ワークアイテムの例を示す図である。この図は、図6~8の例を前提としている。この例では、図8の初期状態から観音花子が承認した後のワークアイテムの変化を示している。観音花子が承認することで、それまで予定であった観音金太郎の状態が、処理待ちに変化したことが分かる。図10は、ジョブ情報の一例を示すデータテーブルである。このジョブ情報は、図6の組織情報の例、図7の定義情報の例を前提にしている。新規案件が起案されると、案件101に、プロセスID、案件ID、申請部門ID、申請ロールIDが登録される。また、ワークアイテム102には、案件ID、アクティビティID、担当者ID、状態が登録される。この例では、案件ID0000001は、アクティビティIDact000は、処理済みで、アクティビティIDact001は、処理待ちであることを示している。次に催促103について説明する。これは、本発明の実施の形態を実現するために新たに設けたデータテーブルである。起案された案件について催促機能が利用されることにより催促103に、案件ID、催促実行者ID、催促実行アクティビティID、催促開始アクティビティID、催促終了アクティビティID、属性が登録される。案件ID0000001のレコードは、申請者が申請時に催促した例を示し、案件ID0000002のレコードは、経理担当が差戻し時に催促した例を示している。また、この業務名購入申請書についてのアクティビティを図示したものを104へ示す。また、ワークアイテムと催促を図示したものを105へ示す。105の前から催促の例では、案件0000001について、申請者の観音太郎がact001からact004まで前から催促する例を示している。申請者が催促する場合、申請者は、この案件自体を速やかに終わらせることを目的に催促するため、案件の最後の承認者まで催促がなされることとなる。また、105の後ろから催促の例では、案件0000002について、経理担当者である観音次郎がact002からact003まで後ろから催促する例を示している。後ろのアクティビティのユーザーが自分より前のアクティビティのユーザーに対して催促をする場合、自分のアクティビティにおける自分の処理を早く終わらせることを目的に催促するため、自分より後ろのアクティビティのユーザーに対しては催促をしない。例えば、後ろのアクティビティのユーザーが長期休暇に入る前に、そのユーザーが処理すべき予定の案件を、前のアクティビティのユーザーに対して催促することで、休み前に処理を終わらせることが可能となる。なお、この例では、最後の処理者である観音次郎が後ろから前に催促をする例となっているが、例えば、観音金太郎が観音太郎に催促をした場合、その次の観音花子に対して催促を行うが、観音次郎に対しては催促を行わない。観音金太郎は、後ろのユーザーである観音次郎に対して催促をしていないからである。もし観音金太郎が観音次郎に対して催促を行いたい場合は、前から催促をすることで実現可能となる。次に、図11に申請する際のワークフローシステムにおける処理の流れを説明する。本フローチャートは、ユーザーがワークフロー操作用端末を操作して、操作に応じた処理をワークフローサーバが行うものである。まず、最初にワークフロー操作用端末は、ユーザー操作に応じてワークフローサーバへのログイン画面を表示装置へ表示させる1101。そして、入力された認証情報をワークフローサーバへ送信する。1102において、ワークフローサーバは、認証を行ってユーザーを特定し、当該ユーザーが申請可能な業務を取得する。図12に、ワークフローサーバにおける申請可能な業務を取得するフローチャートを示す。1201において、ワークフローサーバは、申請者のポジションを取得する。ログインユーザーIDインプット情報を元に、ポジション情報図5の504を参照する。ここで、ポジションとは、ユーザーが所属する部門とロールの組ことをいう。例えば、図6の観音太郎の場合、組織情報から、ポジションは、営業一課一般となり、観音花子の場合、所属ポジションは、営業1課課長と営業2課課長となる。1202において、ワークフローサーバは、申請可能な業務を取得する。業務ごとに、起票者のポジションで申請可能かどうかを調べ申請可能な業務の一覧を作成する。すべての業務毎に、図7のプロセス定義を参照し、プロセス定義712の申請可能な部門IDで指定される部門またはその下位部門に、申請者が所属する場合、申請可能な業務と判定する。例えば、プロセス定義の申請可能な部門IDが、図6の営業部の場合、営業部、営業1課、営業2課に所属するユーザーは申請可能と判定する。図13にワークフローサーバが取得した申請可能な業務をワークフロー操作用端末の表示装置へ表示した例を示す。ユーザーは、起案ボタンを押下することにより業務の申請を選択することができる。インプット情報は、ログインユーザーIDとなる。1103において、ワークフロー操作用端末は、ユーザーによる申請業務の選択を受け付ける。そして、ワークフローサーバへ選択された申請業務を通知する。1104において、ワークフローサーバは、起案時の役割を求める。ここでの処理の流れは、図12に占めるワークフローサーバにおける申請可能な業務を取得するフローチャートと同じであるが、差異点として、インプット情報が、ログインユーザーIDと業務IDである点と、1202の処理が異なる。具体的には、1202において、ワークフローサーバは、申請可能なポジションの一覧を作成する。ユーザーが指定した業務インプット情報の業務IDで、図7のプロセス定義を参照し、プロセス定義712の申請可能な部門IDで指定される部門またはその下位部門に、申請者が所属する場合、申請可能なポジションと判定する。例えば、ログインユーザーのポジションが図6の営業1課課長と営業2課課長で、プロセス定義の申請可能な部門IDが、図6の営業1課の場合、申請可能なポジションは営業1課課長と判定する。1105において、ワークフローサーバは、起案時の役割が複数あるかを判定する。Yesの場合、1106へ進み、Noの場合、1108へ進む。1106において、ワークフロー操作用端末は、ワークフローサーバから取得した役割選択画面を表示する。1107において、ワークフロー操作用端末は、ユーザーから役割選択を受け付ける。そして、ワークフローサーバへ選択された役割を通知する。図14に役割を選択する画面の一例を示す。この例は、神奈川奈々子が部長と課長とを兼任していて、そのどちらで起案するかを選択する画面を示している。1108において、ワークフロー操作用端末は、ワークフローサーバから取得した申請画面を表示する。図15に申請画面の一例を示す。ユーザーは、この画面に必要事項を入力することとなる。1109において、ワークフロー操作用端末は、申請内容催促有無の入力を受け付ける。そして、ワークフローサーバへ入力された各種内容を通知する。1110において、ワークフローサーバは、配送処理新規申請を行う。なお、配送処理の説明については後に説明する。以上により、例えば、図8に示すように、新規案件が起票された状態となる。次に、図16に再申請、承認、差戻、否決する際のワークフローシステムにおける処理の流れを説明する。本フローチャートは、ユーザーがワークフロー操作用端末を操作して、操作に応じた処理をワークフローサーバが行うものである。まず、最初にワークフロー操作用端末は、ユーザー操作に応じてワークフローサーバへのログイン画面を表示装置へ表示させる1601。そして、入力された認証情報をワークフローサーバへ送信する。1602において、ワークフローサーバは、処理待ち一覧をワークフロー操作用端末へ送信し、ワークフロー操作用端末は、処理待ち一覧を表示する。図17にワークフローサーバにおける処理待ち一覧を取得するフローチャートを示す。なお、処理待ち一覧とは、ログインユーザーが現在処理すべき案件を確認するための一覧のことをいう。ここでのインプット情報は、ログインユーザーIDである。1701において、ワークフローサーバは、処理待ち案件の一覧を作成する。すべてのワークアイテム722の中から以下の条件にすべて当てはまるワークアイテムの一覧を作成する。1ワークアイテムの状態が処理待ちである2ワークアイテムの担当者IDがログインユーザーIDインプット情報と同じ例えば、図10で、観音花子課長が処理待ち一覧を開いた場合、ワークアイテム102から上記条件に合うものを求めると次が該当する。案件ID0000001、アクティビティIDact001、担当者IDU001、状態処理待ち1702から1707まで、処理待ち案件の件数繰り返す。また、1703から1706まで、催促の数だけ繰り返す。ここで、ワークアイテムの案件IDを元に、催促情報図7の724を参照し、その催促について繰り返す。例えば、図10で、観音花子課長が処理待ち一覧を開いた場合、催促は次が該当する。案件ID0000001、催促実行者IDU000、催促実行アクティビティIDact000、催促開始アクティビティIDact001、催促終了アクティビティIDact004、属性前から1704において、ワークフローサーバは、案件に催促があるかを判定する。Yesの場合、1705へ進み、Noの場合、1706へ進む。なお、催促が、以下の条件に当てはまれば、そのワークアイテムを催促ありとみなす。ワークアイテムのアクティビティ図7の722、716が、催促図7の724の催促開始と催促終了の間にあれば催促ありと判定する催促開始≦配送先≦催促終了。例えば、図10で、観音花子課長が処理待ち一覧を開いた場合、催促は上記条件に該当するため、催促ありとみなす。図18に処理待ち一覧の画面の例を示す。ここでは、1801に催促についての状態が表示される。この例では、案件IDS000000007は、催促あり、案件IDS000000006と、案件IDS000000002は、何もない通常の処理待ち案件であることを示している。ここで、催促ありとは、その案件を処理する催促がなされている案件であることを示している。本実施の形態では、催促自体は、電子メール等により通知されるので、ユーザーは、その通知により催促されている案件の存在を知る。この画面では、その催促されている案件がどれであるかを一覧から見分けることができる。1603において、ワークフロー操作用端末は、ユーザーから選択された処理する案件をワークフローサーバへ送信する。1604において、ワークフローサーバは、案件詳細画面をワークフロー操作用端末へ送信し、ワークフロー操作用端末は、案件詳細画面を表示する。図19に案件詳細画面の例を示す。1605において、ワークフロー操作用端末は、ユーザー操作による申請内容の編集催促有無の入力を受け付け、ワークフローサーバに内容を通知する。1606において、ワークフローサーバは、配送処理再申請、承認、差戻、否決を行う。なお、配送処理の説明については後に説明する。以上により、再申請、承認、差戻、否決がなされる。次に、図20に前から催促する際のワークフローシステムにおける処理の流れを説明する。本フローチャートは、ユーザーがワークフロー操作用端末を操作して、操作に応じた処理をワークフローサーバが行うものである。まず、最初にワークフロー操作用端末は、ユーザー操作に応じてワークフローサーバへのログイン画面を表示装置へ表示させる2001。そして、入力された認証情報をワークフローサーバへ送信する。2002において、ワークフローサーバは、案件進捗画面をワークフロー操作用端末へ送信し、ワークフロー操作用端末は、案件進捗画面を表示する。案件進捗一覧とは、ログインユーザーが処理した処理済みの案件を確認するための一覧である図31の3101。なお、案件進捗画面に表示する処理待ち案件一覧を取得する処理の流れは、図17に示す処理待ち一覧を取得するフローチャートにおいて処理待ちを処理済みと置き換えることにより対応する。同様にインプット情報は、ログインユーザーIDである。ワークフローサーバは、すべてのワークアイテム図7の722の中から次の条件にすべて当てはまるワークアイテムの一覧を作成する。1ワークアイテムの状態が処理済みである2ワークアイテムの担当者IDがログインユーザーIDインプット情報と同じ例えば、図10で、観音太郎申請者が案件進捗一覧を開いた場合、ワークアイテム図10の102から上記条件に合うものを求めると以下が該当する。案件ID0000001、アクティビティIDact000、担当者IDU000、状態処理済み案件ID0000002、アクティビティIDact000、担当者IDU000、状態処理済みまた、ワークアイテムの案件IDを元に、催促情報図7の724を参照し、その催促について繰り返す。例えば、図10で、観音太郎申請者が案件進捗一覧を開いた場合、催促は以下が該当する。案件0000001についての催促案件ID0000001、催促実行者IDU000、催促実行アクティビティIDact000、催促開始アクティビティIDact001、催促終了アクティビティIDact004、属性前から案件0000002についての催促案件ID0000002、催促実行者IDU003、催促実行アクティビティIDact003、催促開始アクティビティIDact002、催促終了アクティビティIDact003、属性後ろから催促が、以下の条件に1つでも該当すれば、そのワークアイテムを催促ありとみなす。1催促実行者IDがログインユーザーIDと等しい2ワークアイテムのアクティビティIDが、催促の催促開始と催促終了の間にあれば催促ありと判定する催促開始≦ログインユーザーが処理したアクティビティ≦催促終了例えば、図10で、観音太郎申請者が案件進捗一覧を開いた場合、案件0000001についての催促は、催促実行者ID=ログインユーザーとなるため、条件に該当し、催促ありと判定する。また、案件0000002についての催促は、条件に該当しないため催促なしと判定する。2003において、ワークフロー操作用端末は、ユーザーによる催促する案件の選択を受け付け、ワークフローサーバへ通知する。2004において、ワークフローサーバは、催促処理前からを行う。なお、催促処理については後に説明する。以上により、前からの催促をすることができるようになる。また、図21に後ろから催促する際のワークフローシステムにおける処理の流れを説明する。本フローチャートは、ユーザーがワークフロー操作用端末を操作して、操作に応じた処理をワークフローサーバが行うものである。まず、最初にワークフロー操作用端末は、ユーザー操作に応じてワークフローサーバへのログイン画面を表示装置へ表示させる2101。そして、入力された認証情報をワークフローサーバへ送信する。2102において、ワークフローサーバは、予定案件一覧をワークフロー操作用端末へ送信し、ワークフロー操作用端末は、予定案件一覧を表示する。予定案件一覧とは、ログインユーザーが将来、処理する予定の案件を確認するための一覧である図31の3102。ユーザーは、例えば、近々、出張するような事情がある場合、出張前にその案件の処理を行うべく、自分より前の承認ユーザーに対して催促をするといった使い方ができる。なお、予定案件一覧に表示する予定案件一覧を取得する処理の流れは、図17に示す処理待ち一覧を取得するフローチャートにおいて処理待ちを処理済みと置き換えることにより対応する。同様にインプット情報は、ログインユーザーIDである。すべてのワークアイテム図7の722の中から次の条件にすべて当てはまるワークアイテムの一覧を作成する。1ワークアイテムの状態が予定である2ワークアイテムの担当者IDがログインユーザーIDインプット情報と同じ例えば、図10で、観音次郎経理担当が予定案件一覧を開いた場合、ワークアイテム図10の102から上記条件に合うものを求めると以下が該当する。案件ID0000001、アクティビティIDact003、担当者IDU003、状態予定案件ID0000002、アクティビティIDact003、担当者IDU003、状態予定ワークアイテムの案件IDを元に、催促情報図7の724を参照し、その催促について繰り返す。例えば、図10で、観音次郎経理担当が案件進捗一覧を開いた場合、催促は以下が該当する。案件0000001についての催促案件ID0000001、催促実行者IDU000、催促実行アクティビティIDact000、催促開始アクティビティIDact001、催促終了アクティビティIDact004、属性前から案件0000002についての催促案件ID0000002、催促実行者IDU003、催促実行アクティビティIDact003、催促開始アクティビティIDact002、催促終了アクティビティIDact003、属性後ろから催促が、以下の条件に1つでも該当すれば、そのワークアイテムを催促ありとみなす。1催促実行者IDがログインユーザーIDと等しい2状態が処理待ちのワークアイテム図7の722に対応するアクティビティが、催促図7の724の催促開始と催促終了の間にあれば催促ありと判定する催促開始≦現在の処理待ちアクティビティ≦催促終了例えば、図10で、観音次郎経理担当が案件進捗一覧を開いた場合、案件0000001について催促実行者IDU000は、ログインユーザーIDU003と一致しない。条件が処理待ちのワークアイテムは案件ID0000001、アクティビティIDact001、担当者IDU001、状態処理待ちアクティビティIDact001は、催促開始act001と催促終了act004の間に該当するので、催促ありと判定する。また、案件0000002についての催促は、催促実行者IDU003は、ログインユーザーIDU003と一致するため、催促ありと判定する。2103において、ワークフロー操作用端末は、ユーザーによる催促する案件の選択を受け付け、ワークフローサーバへ通知する。ここで、ユーザーが、予定の案件を選択した場合、現在処理待ちとなっている承認ユーザーが特定されて画面に表示される図32。対応する案件IDと図10に示すワークアイテム102の状態において処理待ちとなっている担当者が対象として特定されることとなる。そして、ユーザーにより催促の指示がなされることによりその指示がワークフローサーバへ送信される。催促の指示がなされることにより、催促処理が実行されるが、処理の詳細は後述する。また、ユーザーが案件を選択することなく、予め定めた条件に合致する予定案件がある場合や全ての予定案件について、ユーザーの操作を介することなく、直ちに催促の処理を行う実施の形態をとることも可能である。更に、選択した案件を、選択をしたユーザーか催促をするアクティビティの承認者の次の承認者からの催促であるかを選択することを可能とする。図30は、催促するユーザーを選択する画面である。3001にチェックを入れることにより催促をするアクティビティの承認者の次の承認者からの催促を選択することができる。これにより、図8のアクティビティにおいて、経理担当者が課長に催促をした場合であっても、課長に対しては、部長から催促があったように通知がなされる。これは、通常、ワークフロー処理の流れにおいて、自分の直後の承認者は分かっていても、次の次など、離れた先の承認者を知らないことが多いため、直後の承認者により催促がされたように見せることで実効性のある催促を実現することができる。なお、チェックが入れられた場合、後の処理で、催促実行者のIDを置き換える必要があるため、ここでは、置き換え情報としてメモリに一時的に記憶しておく。2104において、ワークフローサーバは、催促処理後ろからを行う。なお、催促処理については後に説明する。以上により、後ろからの催促をすることができるようになる。続いて、図33にその他のワークフローシステムにおける処理の流れを説明する。本フローチャートは、ユーザーがワークフロー操作用端末を操作して、操作に応じた処理をワークフローサーバが行うものである。まず、最初にワークフロー操作用端末は、ユーザー操作に応じてワークフローサーバへのログイン画面を表示装置へ表示させる3301。そして、入力された認証情報をワークフローサーバへ送信する。3302において、ワークフローサーバは、案件選択画面をワークフロー操作用端末へ送信し、ワークフロー操作用端末は、案件選択画面を表示する。案件選択画面の一例を図34に示す。この案件選択画面からユーザーは、処理待ち案件を一覧表示する場合3401、催促ありの処理待ち案件を一覧表示する場合3402、処理予定の案件を一覧表示する場合3403の3つの一覧表示を選択することができる。処理待ち案件を一覧表示する場合は、通常の画面であって、ログインユーザーの処理待ちとなっている案件の一覧を確認することができる画面である。催促ありの処理待ち案件を一覧表示する場合は、ログインユーザーの処理待ちとなっている案件でかつ、その案件に催促がある案件の一覧を確認することができる画面である。催促がある案件を優先的に処理する場合等に有効な画面となる。処理予定の案件を一覧表示する場合は、ログインユーザーが将来処理することとなる案件の一覧を確認することができる画面である。催促をすべき案件を抽出する場合等に有効な画面となる。3303において、ワークフロー操作用端末は、ユーザー操作に応じてワークフローサーバへ選択された画面の種類を判定して、その判定結果をワークフローサーバへ送信する。3304において、ワークフローサーバは、処理待ち案件一覧を表示する処理を行い、その一覧画面情報をワークフロー操作端末へ送信する。ワークフロー操作端末では、一覧画面情報を用いて、画面に一覧を表示する。なお、処理待ち案件一覧に表示する処理待ち案件一覧を取得する処理の流れは、図17に示す処理待ち一覧を取得するフローチャートにおける1701~1702の処理により実現可能である。3305において、ワークフローサーバは、催促あり処理待ち案件一覧を表示する処理を行い、その一覧画面情報をワークフロー操作端末へ送信する。ワークフロー操作端末では、一覧画面情報を用いて、画面に一覧を表示する図31の3103。なお、催促あり処理待ち案件一覧に表示する催促あり処理待ち案件一覧を取得する処理の流れは、図17に示す処理待ち一覧を取得するフローチャートの処理により実現可能である。3306において、ワークフローサーバは、予定案件一覧を表示する処理を行い、その一覧画面情報をワークフロー操作端末へ送信する。ワークフロー操作端末では、一覧画面情報を用いて、画面に一覧を表示する図31の3102。なお、予定案件一覧に表示する予定案件一覧を取得する処理の流れは、図17に示す処理待ち一覧を取得するフローチャートにおいて処理待ちを予定と置き換えることにより対応する。3307において、ワークフロー操作端末は、表示された一覧画面からユーザーによりから案件の選択を受け付ける。3308において、ワークフロー操作端末は、選択された案件に対して催促の操作がなされたかを判定する。Yesの場合、3310へ進み、Noの場合、3309へ進む。具体的には、一覧画面のメニュー等から催促する項目の選択がなされたかにより判定を行う。また、その際は、催促を行うユーザーの指定を受け付けて、ワークフローサーバへ指定を行う。なお、催促を行うユーザーの抽出方法は、上述した通りであるため説明を省略する。また、催促には前からと後ろかの2つあり、その種類もワークフローサーバへ通知される。3309において、ワークフローサーバは、ワークフロー操作端末からなされた指示に応じて配送処理を行う。この配送処理は従来の配送処理と同じである。3310において、ワークフローサーバは、催促処理を行う。催促処理前から、後ろかは、上述した通りなので説明を省略する。以上、その他のワークフローシステムにおける処理の流れを説明した。次に、ワークフローシステムにおける配送処理の流れを説明する。図22は、ワークフローシステムにおける配送処理の流れを示すフローチャートである。本処理はワークフローサーバにおいて処理がなされる。ここでは、インプット情報として、ログインユーザーID、申請部門ID、申請ロールID、業務ID、プロセスID、ワークアイテムID、入力内容、催促有無あり、なし、処理区分新規申請、再申請、承認、差戻、否決が入力されるものとする。2201において、ワークフローサーバは、処理区分を判定する。新規申請の場合、2204へ進み、その他の場合、2202へ進む。例えば、承認者が案件詳細画面図19で、承認のボタンを押せば処理区分は承認となる。同様に差戻のボタンを押せば差戻となり、否決のボタンを押せば否決となる。新規申請と、再申請は、呼出元フローが異なる図11の1110、図16の1606。2202において、ワークフローサーバは、処理待ちワークアイテムを削除する。再申請、承認、差戻、否決を行ったアクティビティに対応する処理待ちのワークアイテムを削除する。例えば、図10の案件0000001は観音花子の処理待ちの状態である。この状態で、観音花子が承認した場合、承認を行ったアクティビティはact001であり、対応するワークアイテムで処理待ちのものを削除する。2203において、ワークフローサーバは、入力内容の更新を行う。エンドユーザーが入力した内容で、入力内容を更新する。2204において、ワークフローサーバは、案件の新規作成を行う。案件ID:新規発番、業務ID:インプット情報の業務ID、申請部門ID:インプット情報の申請部門ID、申請ロールID:インプット情報の申請ロールID2205において、ワークフローサーバは、エンドユーザーが入力した内容で、入力内容を新規作成する。2206において、ワークフローサーバは、処理済ワークアイテム作成を行う=処理を行ったアクティビティに対応する処理済みのワークアイテムを作成する。例えば、図10の案件0000001は観音花子の処理待ちである。この状態で、観音花子が承認した場合、承認を行ったアクティビティはact001であり、対応するワークアイテムで処理済みのものを作成する。例えば、例観音太郎が新規申請した場合には、申請を行ったアクティビティはact000であり、対応するワークアイテムで処理済みのものを作成する。2207において、ワークフローサーバは、処理区分を判定する。否決の場合、2222へ進み、その他の場合、2208へ進む。2208において、ワークフローサーバは、処理区分を判定する。差戻の場合、2210へ進み、その他の場合、2209へ進む。2209において、ワークフローサーバは、配送先アクティビティを求める。例えば、図8で観音太郎が申請した場合、処理を行ったアクティビティはact000であり、配送先のアクティビティはact001となる。また、観音花子課長が承認した場合は、処理を行ったアクティビティはact001であり、配送先のアクティビティはact002となる。また、観音金太郎部長が承認した場合は、処理を行ったアクティビティはact002であり、配送先のアクティビティはact003となる。また、観音次郎経理担当が承認した場合は、処理を行ったアクティビティはact003であり、配送先のアクティビティはact004となる。ここでの処理の詳細を、図23に示す。図23は、ワークフローサーバにおける次のユーザー実行アクティビティを求める処理の流れを示すフローチャートである。インプット情報として、案件IDと入力アクティビティIDが入力される。2301において、ワークフローサーバは、対象アクティビティの属性を判定する。分岐条件の場合、2303へ進み、その他の場合、2302へ進む。2302において、ワークフローサーバは、次のアクティビティを求める。例えば、図10の104でact003の次はact004である。2303において、ワークフローサーバは、次のアクティビティを求める。条件分岐から伸びているすべてのトランジションの条件の中から成立するものを見つけ、そのトランジションにつながるアクティビティを次のアクティビティとする。例えば、図4で、402の次は、条件によって、403か405になる。2304において、ワークフローサーバは、次のアクティビティの属性を判定する。終了の場合、2307へ進み、ユーザー実行の場合、2406へ進み、その他の場合、2305へ進む。2305において、ワークフローサーバは、次のアクティビティを対象に繰り返し処理を行うために、2301へ戻る。2306において、ワークフローサーバは、次のアクティビティを返す。2307において、ワークフローサーバは、終了アクティビティを返す。一方、2210において、ワークフローサーバは、不要となった催促を削除する。次の以下の条件にすべて当てはまる催促を削除し、催促実行者にメール通知する。1前からの催促である2催促の開始よりも前申請側に差し戻された差戻し先アクティビティ<催促開始アクティビティ2211において、ワークフローサーバは、配送先アクティビティの属性が終了であるかどうかを判定する。Yesの場合、2212へ進み、Noの場合、2219へ進む。例えば、処理区分が新規申請再申請承認の場合には。2212で配送先を求めている。差戻の場合には、処理を行ったアクティビティの差戻し先図7の716が配送先となる。2212において、ワークフローサーバは、処理待ワークアイテムを作成する。この処理の詳細な処理の流れを、図24を用いて説明する。ここで、インプット情報は、案件IDと配送先アクティビティIDである。2401において、ワークフローサーバは、該当者を求める。そして、2402から2404において、該当者の数だけ繰り返し処理し、2403において、ワークアイテムの作成を行うワークアイテムID:新規発番、アクティビティID:配送先アクティビティのID、担当者ID:該当者のID、状態:処理待。2401における詳細な処理の流れを、図25を用いて説明する。ここで、インプット情報は、案件IDとアクティビティIDである。2501において、ワークフローサーバは、ユーザー指定がされているかを判定するユーザー指定がされているとは、アクティビティの担当者ID図7の716が指定されていることである。Yesの場合、2505へ進み、Noの場合、2502へ進む。2502において、ワークフローサーバは、ロールのみの指定であるかを判定するロールのみ指定であるとは、アクティビティの担当部門ID図7の716に申請部門と同じと指定することである。Yesの場合、2503へ進み、Noの場合、2504へ進む。例えば、図8でアクティビティact002は、ロールのみが指定されている。2503において、ワークフローサーバは、部門ロールの該当者を求める。部門には案件インプット情報の申請部門ID図7の721を指定し、ロールにはアクティビティの担当ロールを指定する。最後に、該当者を返して処理を終了する。2504において、ワークフローサーバは、部門ロールの該当者を求める。部門にはアクティビティの担当部門を指定し、ロールにはアクティビティの担当ロールを指定する。最後に、該当者を返して処理を終了する。この処理の詳細な処理の流れを、図26を用いて説明する。ここで、インプット情報は、部門IDとロールIDである。2601において、ワークフローサーバは、該当者があるかを判定する。Yesの場合、2602に進み、Noの場合、2603へ進む。例えば、図6で、営業1課C001、課長R001に該当するユーザーが存在するか判定する場合、ポジション図6の604を参照し、部門が営業1課C001で、ロールが課長R001に該当するレコードは次の通りである。ユーザーIDU001、ロールIDR001、部門IDC001この情報から該当者は、U001の観音花子となる。2602において、ワークフローサーバは、該当者を返して処理を終了する。2603において、ワークフローサーバは、上位部門で繰り返し、2601へ戻る。部門の親部門を求める。部門の親部門図5の501を参照して求める。例えば、図6で、営業1課C001の親部門は、図6の601より、営業部B001となる。なお、親部門がない場合=最上位部門のときは、異常系なのでここでは除外している。2505において、ワークフローサーバは、ユーザーIDを返し処理を終了する。ユーザーが指定されているケースで、該当者は、指定されたユーザーそのものである。次に、2213において、ワークフローサーバは、予定ワークアイテムを作成する。この処理の詳細な処理の流れを、図27を用いて説明する。ここで、インプット情報は、案件IDとアクティビティID申請またはユーザー実行アクティビティである。2701において、ワークフローサーバは、アクティビティインプット情報の属性が何であるかを判定する。終了の場合、終了し、ユーザー実行の場合、2702へ進み、条件分岐の場合、2707へ進み、合流の場合、2709へ進む。2702において、ワークフローサーバは、既に作成済みかどうかを判定する。Yesの場合、2709へ進み、Noの場合、2703へ進む。具体的には、対象のアクティビティに予定のワークアイテムがあるかどうかを調べる。2703において、ワークフローサーバは、対象アクティビティの該当者を求める。なお、この処理の詳細は、図25および図26の処理と同じであるため説明を省略する。そして、2704から2706において、ワークフローサーバは、該当者の数だけ繰り返し処理し、2705において、予定ワークアイテムの作成を行う案件ID:インプット情報の案件ID、アクティビティID:配送先アクティビティのID、担当者ID:該当者のID、状態:予定。また、2707において、ワークフローサーバは、分岐条件の判定を行う。条件分岐から伸びているすべてのトランジションの条件の中から成立するものを見つける。なお、成立するものがないケースや、複数成立してしまう場合は異常系なのでここでは除外する。2708において、ワークフローサーバは、予定ワークアイテムを削除する。条件が成立しないトランジション以降、対応する合流までのすべてのアクティビティに対応する予定のワークアイテムを削除する。また、削除したワークアイテムから作成した催促を削除する。そして、削除した催促の作成者へメール通知する。例えば、図4のプロセスで、金額を10万円で申請後、差し戻され、再申請時に40万円で申請するようなケースで403、404の予定のワークアイテムを削除する。2709において、ワークフローサーバは、次のアクティビティで繰り返し、2701へ戻る。次に、2214において、ワークフローサーバは、催促があるかを判定する。Yesの場合、2216へ進み、Noの場合、2215へ進む。2215において、ワークフローサーバは、承認依頼メールを送信する。この詳細な処理の流れを、図28を用いて説明する。ここで、インプット情報は、ログインユーザーIDと案件IDと配送先アクティビティIDである。2801において、ワークフローサーバは、承認依頼の文面を作成する。業務名は、案件IDを元に、定義情報図7の業務から求める。例えば、件名:承認依頼が届きました、本文:購入精算書0000001の承認依頼が届きましたなどとする。この承認依頼のメールは、ワークアイテム102で処理待ちとなっているユーザーに送信するものである。2802から2807まで、ワークフローサーバは、催促の数だけ繰り返す。例えば、図10で案件IDが0000001の案件を、観音花子課長が承認した場合、催促は、案件IDインプット情報を元に、催促テーブル図10の103から求める。この処理は、承認依頼メールに、この案件に催促があることを示すための処理である。2803において、ワークフローサーバは、催促をつけるかを判定する。Yesの場合、2804へ進み、Noの場合、2807へ進む。ここでは、配送先アクティビティが、催促図7の724の催促開始と催促終了の間にあれば催促ありと判定する催促開始≦配送先≦催促終了。例えば、図10で案件IDが0000001の案件を、観音花子課長が承認した場合、配送先はact002、催促の開始はact001、終了はact004であるため催促ありと判定する。2804において、ワークフローサーバは、催促者を変更するかを判定する。Yesの場合、2805へ進み、Noの場合、2806へ進む。ここでは、催促図7の724の催促者変更の有無が有ならば変更すると判定する。2805において、ワークフローサーバは、催促の文面を追加する。ここで、催促者の氏名は、催促実行者IDを元に、組織情報図5のユーザー503から求める文面例:観音太郎様より催促されています。。2806において、ワークフローサーバは、催促の文面を追加する。ここで、配送先アクティビティを元に、次のユーザー実行アクティビティを求め図23、そのアクティビティの該当者を求める図25。そして、その該当者を元に、組織情報図5のユーザー503から催促者の氏名を求める文面例:観音金太郎様より催促されています。。2808において、ワークフローサーバは、メールを送信する。ここでは、配送先アクティビティの該当者を求め図25、その該当者にメールを送信する。文面は2801、2805、2806で作成したものである。メール例件名:承認依頼が届きました。本文:購入精算書0000001の承認依頼が届きました。観音太郎様より催促されています。。以上、図28を用いて、承認依頼メールを送信する一例を示したが、下記のような実施の形態もある。1承認依頼メールとは別に催促メールを送信する実施の形態。これにより、催促を独立したメールで送信することにより、催促対象となっているユーザーに催促を促すことができる。2後ろから催促の場合、処理待ちユーザーに催促をすると同時に、処理待ちユーザーから催促をしたユーザーに至るアクティビティのユーザー予定ユーザーに催促をする実施の形態。これにより、ワークフローの流れの中で、処理待ちユーザーとなる毎に、そのユーザーに催促をする場合に比べ、予定となっているユーザーに対しても催促をすることになるため、予め催促を知らしめることが可能となる。次に、2216において、ワークフローサーバは、処理区分を判定する。差戻の場合、2218へ進み、その他の場合、2217へ進む。2217において、ワークフローサーバは、催促を新規に作成する。案件IDとして、案件IDインプット情報、催促実行者IDとして、ログインユーザーIDインプット情報、催促実行アクティビティIDとして、ワークアイテムIDインプット情報に対応するアクティビティID、催促開始アクティビティIDとして、配送先のアクティビティ、催促終了アクティビティIDとして、終了アクティビティ、属性として、前から、催促者変更の有無として、無。2918において、ワークフローサーバは、催促を新規に作成する。案件IDとして、案件IDインプット情報、催促実行者IDとして、ログインユーザーIDインプット情報、催促実行アクティビティIDとして、ワークアイテムIDインプット情報に対応するアクティビティID、催促開始アクティビティIDとして、配送先のアクティビティ、催促終了アクティビティIDとして、ワークアイテムIDインプット情報に対応するアクティビティID、属性として、後ろから、催促者変更の有無として、無。次に、2219において、ワークフローサーバは、申請者にメール通知を行う。ここでは、案件が最終承認されたことを申請者に通知する。申請者は、申請アクティビティ図7に対応するワークアイテム図7の担当者IDから求め、メールアドレスは、ユーザーIDを元に、組織情報図5のユーザーから求める。業務名は、案件IDを元に、定義情報図7の業務から求める。最終承認メール例件名:購入精算書が最終承認されました。本文:購入精算書0000001が最終承認されました。。2220において、ワークフローサーバは、催促実行者にメールを通知する。ここでは、案件が最終承認されたことを催促実行者に通知する。催促実行者は、催促図7の催促実行者IDから求め、メールアドレスは組織情報図5のユーザーから求める。メール例件名:催促していた購入精算書が最終承認されました。本文:催促していた購入精算書0000001が最終承認されました。。2221において、ワークフローサーバは、案件の催促を削除する。ここでは、案件の催促をすべて削除する。例えば、案件ID0000001の案件を最終承認した場合、催促テーブル図7で案件IDが0000001のレコードをすべて削除する。また、2222において、ワークフローサーバは、申請者にメール通知を行う。ここでは、案件が否決されたことを申請者に通知する。申請者は、申請アクティビティ図7に対応するワークアイテム図7の担当者IDから求め、メールアドレスは、ユーザーIDを元に、組織情報図5のユーザーから求める。業務名は、案件IDを元に、定義情報図7の業務から求める。否決メール例件名:購入精算書が否決されました。本文:購入精算書0000001が否決されました。。2223において、ワークフローサーバは、催促実行者にメールを通知する。ここでは、案件が否決されたことを催促実行者に通知する。催促実行者は、催促図7の催促実行者IDから求め、メールアドレスは組織情報図5のユーザーから求める。否決メール例件名:催促していた購入精算書が否決されました。本文:催促していた購入精算書0000001が否決されました。。2224において、ワークフローサーバは、案件の催促を削除する。ここでは、案件の催促をすべて削除する。例えば、案件ID0000001の案件を否決した場合、催促テーブル図7で案件IDが0000001のレコードをすべて削除する。以上、ワークフローシステムにおける配送処理の流れを説明した。次に、催促処理2004、2104、3110の流れを、図29を用いて説明する。図29は、ワークフローシステムにおける催促処理の流れを示すフローチャートである。ここで、インプット情報は、ログインユーザーID、案件ID、処理待のアクティビティID、ワークアイテムIDログインユーザーが担当のワークアイテム、催促の向き催促実行者の置き換えの有無である。2901において、ワークフローサーバは、メール文面を作成する。催促者の氏名は、催促実行者の置き換えの有無インプット情報が無ならば、ログインユーザーIDを元に、組織情報図5のユーザー503から求め、催促実行者の置き換えの有無が有ならば、催促者の氏名は処理待ちのワークアイテムを元に、次のユーザー実行アクティビティを求め図23、そのアクティビティの該当者を求める図25。そして、その該当者を元に、組織情報図5のユーザー503から催促者の氏名を求める。メール例件名:催促が届きました。本文:観音太郎様より、購入精算書0000001の催促が届きました。。2902から2907において、ワークフローサーバは、催促の数だけ繰り返す。2903において、ワークフローサーバは、処理待ちユーザーへの催促であるかを判定する。Yesの場合、2904へ進み、Noの場合、2907へ進む。処理待のアクティビティが、催促開始と催促終了の間かにより判定する。2904において、ワークフローサーバは、催促者を変更するかを判定する。Yesの場合、2906へ進み、Noの場合、2905へ進む。ここで、催促者を変更するかどうかの判定は、催促図7の催促者変更の有無が有ならば変更すると判定する。2905において、ワークフローサーバは、催促の文面を追加する。ここでは、催促者の氏名は、催促実行者IDを元に、組織情報図5のユーザー503から求める文面例:観音太郎様より催促されています。。2906において、ワークフローサーバは、催促の文面を追加する。ここで、処理待ちのワークアイテムを元に、次のユーザー実行アクティビティを求め図23、そのアクティビティの該当者を求める図25。そして、その該当者を元に、組織情報図5のユーザー503から催促者の氏名を求める文面例:観音金太郎様より催促されています。。2908において、ワークフローサーバは、メールを送信する。ここでは、宛先は処理待のアクティビティIDインプット情報の担当者である。2909において、ワークフローサーバは、催促の向きを判定する。前からの場合、2910へ進み、後ろからの場合、2911へ進む。2910において、ワークフローサーバは、催促の作成を行う。ここでは、催促を新規に作成する。案件IDとして、案件IDインプット情報、催促実行者IDとして、ログインユーザーIDインプット情報、催促実行アクティビティIDとして、ワークアイテムIDインプット情報に対応するアクティビティID、催促開始アクティビティIDとして、処理待のアクティビティ、催促終了アクティビティIDとして、終了アクティビティ、属性として、前から、催促者変更の有無として、無。2911において、ワークフローサーバは、催促の作成を行う。ここでは、催促リストの要素を新規に作成する。案件IDとして、案件IDインプット情報、催促実行者IDとして、ログインユーザーIDインプット情報、催促実行アクティビティIDとして、ワークアイテムIDインプット情報に対応するアクティビティID、催促開始アクティビティIDとして、処理待のアクティビティ、催促終了アクティビティIDとして、ワークアイテムIDインプット情報に対応するアクティビティID、属性として、後ろから、催促者変更の有無として、催促者変更の有無インプット情報。以上、催促処理2004、2104の流れを説明した。上述した通り、本発明によれば、ワークフロー処理の流れにおいて、後ろのアクティビティの承認を行うユーザーから前のアクティビティの承認を行うユーザーに対して催促することができるワークフローシステムを提供することが可能となる。例えば、後ろのアクティビティの承認を行うユーザーが、休暇により不在となる前に、自分が承認を行うユーザーとして設定されているプロセスにおいて、前のアクティビティの承認を行うユーザーに対して催促をすることで、休暇前にそのプロセスの承認処理を終わらせることが可能となる。そのため、期限が迫っているプロセスを速やかに終わらせようとする場合などに、特に有用な機能である。また、ワークフロー処理の流れにおいて、後ろのアクティビティの承認者に対して催促することができるワークフローシステムを提供することが可能となる。以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。また、本発明におけるプログラムは、本発明に示すフローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体はコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは各装置の処理方法ごとのプログラムであってもよい。以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータまたはCPUやMPUが記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、CD-ROM、CD-R、DVD-ROM、磁気テープ、不揮発性のメモリカード、ROM、EEPROM、シリコンディスク、ソリッドステートドライブ等を用いることができる。また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているOSオペレーティングシステム等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。また、本発明は、複数の機器から構成されるシステムに適用しても、1つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。