JP6112146B2 - ワークフローサーバ、ワークフローサーバの制御方法、およびプログラム - Google Patents

Description

本発明は、ワークフローシステムにおける未処理案件の処理の催促を行う宛先を決定する機能に関する。

ワークフローシステムにおいて、ある処理担当者へ案件の処理依頼がされたとしても、その処理担当者の処理が行われず案件が処理担当者において滞留すると、ワークフローシステム全体の処理自体が遅延することとなる。このような処理の遅延を防ぐために、ワークフローシステムにおいて処理担当者に処理の依頼を行うと同時に、メールの機能を利用し処理依頼を通知するということが行われている。

また、予め決められた処理期限を指定しておき、処理期限が迫ってきても処理が行われていない場合に、処理担当者に対して処理を喚起するメールを送信する、或いは、所定の管理者へメールで処理状況を通知するということを行うことが可能である。

特開２００３−１０８７２６号公報

例えば、特許文献１では、予め処理期限を設定しておき、その処理期限までに処理がされていない場合は、処理の依頼を処理担当者へメールで通知することにより、未処理の案件への対応を促すことを行っている。また、期限が予め決まっている官公庁に対する手続が行なわれていない場合、処理が的確に行われるようにその業務を管理する管理者へメールで通知するワークフローシステムが開示されている。

ある期限を基準としてメールで処理担当者へ未処理の案件を通知することによって、処理を促すことが出来るため、適切な処理期限の設定によっては、処理のし忘れや、ワークフローシステム全体における作業自体が遅延することを防ぐことが可能となる。

しかしながら、特許文献１のメールによる処理依頼の通知の方法によると、処理担当者に対しては通知がされるが、例えば、処理担当者の上司など、処理担当者以外の関連のある人にも通知することは行っていない。このため、処理担当者の処理状況を組織として把握する容易ではない。

また、処理担当者のワークフローシステムにおけるこれまでの処理の作業時間に応じて、処理の催促の通知する時期決定する、あるいは、通知する頻度を決定するといったことは行われていない。このため、処理期限を固定にしてしまうと、処理が遅い人にとっては、早い人よりも早めに通知する、あるいは、通知する回数を増やす、ということが行われていないため、精度良く処理の遅延を防ぐことが出来ない。

そこで、本発明の目的は上記課題を鑑み、ワークフローシステムにおいて、案件の処理の進み具合に応じて、催促を配信するその後の処理担当者に滞留時間を通知して、現在滞留させている処理担当者の状況を把握させることを目的とする。

本発明は、案件が複数の処理担当者によって処理され、前記案件の処理の催促を促すことを可能とするワークフローシステムのワークフローサーバであって、未処理の案件に対して処理の催促を行った回数をカウントするカウント手段と、前記カウント手段でカウントした前記回数に応じて、前記催促を配信する宛先を決定する宛先決定手段と、前記宛先決定手段で決定される宛先に、前記催促を前記宛先に配信するための配信制御を行う配信制御手段と、前記未処理の案件を現在保持する処理担当者が案件の処理を滞留した時間を算出する算出手段と、を備え、前記宛先決定手段で決定する宛先は、前記未処理の案件を現在保持する処理担当者以外の、前記処理担当者よりも上位ロールの処理担当者であり、前記配信制御手段が、前記処理担当者の前記未処理の案件の処理の催促を前記処理担当者よりも上位ロールの処理担当者に配信する場合には、前記算出した未処理の案件を現在保持する処理担当者が案件の処理を滞留した時間を含めて配信することを特徴とする。

本発明によれば、ワークフローシステムにおいて、案件の処理の進み具合に応じて、催促を配信するその後の処理担当者に滞留時間を通知して、現在滞留させている処理担当者の状況を把握させることが可能となる。

本発明の実施形態のシステム構成の一例を示す図である。 本発明の実施形態のワークフローシステムにおける、クライアント端末、ワークフローサーバ、メールサーバ、管理者端末のハードウェア構成の一例を示す図である。 本発明の実施形態の機能構成の一例を示す図である。 本発明の実施形態における催促メール配信処理のメイン処理を示すフローチャートである。 本発明の実施形態における催促メール配信処理の初回メール配信タイミング取得処理を示すフローチャートである。 本発明の実施形態における催促メール配信処理の催促メール配信間隔取得処理を示すフローチャートである。 本発明の実施形態における催促メール配信処理の宛先設定及びメール配信処理を示すフローチャートである。 本発明の実施形態におけるワークフローを処理する組織の一例を示す図である。 本発明の実施形態における案件管理テーブルが格納するデータの一例を示す図である。 本発明の実施形態におけるメール配信管理テーブルが格納するデータの一例を示す図である。 本発明の実施形態における処理履歴テーブルが格納するデータの一例を示す図である。 本発明の実施形態におけるワークフローユーザ情報が格納するデータの一例を示す図である。 本発明の実施形態における初回メール配信タイミング管理テーブルが格納するデータの一例を示す図である。 本発明の実施形態における催促メール配信間隔管理テーブルが格納するデータの一例を示す図である。 本発明の実施形態における宛先管理テーブルが格納するデータの一例を示す図である。 本発明の実施形態におけるロール管理テーブルが格納するデータの一例を示す図である。 本発明の実施形態における配信される催促メールの一例を示すイメージ図である。 本発明の第２のメール配信方法の実施形態における催促メール配信処理の宛先設定及びメール配信処理を示すフローチャートである。 本発明の第２のメール配信方法の実施形態における配信される催促メールの一例を示すイメージ図である。 本発明の実施形態における配信される催促メールの一例を示すイメージ図である。 本発明の実施形態における催促メール配信処理の宛先設定及びメール配信処理を示すフローチャートである。 本発明の実施形態における催促が行われる案件に紐づくプロセス定義の一例を示す図である。 本発明の実施形態における案件に紐づくプロセス定義で定義されている処理担当者を決定するために使用する組織の一例を示す図である。 本発明の実施形態における宛先管理テーブルが格納するデータの一例を示す図である。 本発明の実施形態における宛先管理テーブルが格納するデータの一例を示す図である。 本発明の実施形態における催促メール配信処理のメイン処理を示すフローチャートである。 本発明の実施形態における催促メール配信処理の宛先設定及びメール配信処理を示すフローチャートである。 本発明の実施形態における宛先管理テーブルが格納するデータの一例を示す図である。 本発明の実施形態における配信される催促メールの一例を示すイメージ図である。 本発明の実施形態における配信される催促メールの一例を示すイメージ図である。 本発明の実施形態における催促メール配信処理の宛先設定及びメール配信処理を示すフローチャートである。 本発明の実施形態における催促メール配信処理の宛先設定及びメール配信処理を示すフローチャートである。 本発明の実施形態における案件期限管理テーブルが格納するデータの一例を示す図である。 本発明の実施形態における催促メール配信処理の宛先設定及びメール配信処理を示すフローチャートである。 本発明の実施形態における宛先管理テーブルが格納するデータの一例を示す図である。 本発明の実施形態における配信される催促メールの一例を示すイメージ図である。 本発明の実施形態における催促メール配信処理の宛先設定及びメール配信処理を示すフローチャートである。 本発明の実施形態における追加宛先管理テーブルが格納するデータの一例を示す図である。

図１は、本発明の一実施形態を示すワークフローシステムの全体構成を示すシステム構成図である。

図１に示すように、本実施形態のワークフローシステムは、クライアント端末１０１、クライアント端末１０２、ワークフローサーバ１０３、メールサーバ１０４、管理端末１０５がネットワーク１００を通じて接続されている。

ユーザは、例えばウェブブラウザやクライアントソフトウェアなどを利用して、クライアント端末１０１（１０２）において案件の起案を行う、或いは、案件の承認を行うことによって、ワークフローサーバ１０３に対して、案件に対してワークフロー上の処理がしかるべき処理担当者においてなされるようにするため、ワークフローの進行の要求などを行う。

ワークフローサーバ１０３は、クライアント端末１０１（１０２）からのワークフローを進行させるために必要となる要求を受け付け、受け付けた処理（例えば、起案、承認などの処理）に応じて、案件がしかるべき次の処理担当者によって処理が行われるようにする。

ワークフローサーバ１０３によって、しかるべき次の処理担当者に処理が行われるように処理がされた案件は、次の処理担当者によってクライアント端末１０１（１０２）において作業が可能になる。また、ワークフローサーバ１０３より、次の処理担当者へ案件の処理依頼を、メールサーバ１０４を介してメールによって通知することを可能とする。

メールサーバ１０４は、ワークフローサーバ１０３からの指定された催促配信内容、配信する宛先の情報を受け取り、処理担当者が案件の処理を行うクライアント端末１０１（１０２）に対して、メール配信を行う。なお、本発明における１実施形態としてメールにより催促を行うことを例として挙げているため、メールサーバ１０４を構成としていれているが、あくまで一例であって、催促を行う手段としては、メール以外のメッセージ通知システムを用いても良いこととする。

管理端末１０５からは、案件をしかるべき処理担当者へ処理依頼が行えるようにするための、案件の処理担当者のルールを設定したプロセスや、ワークフローシステムを使用する処理担当者（ユーザ）、処理担当者（ユーザ）が所属する組織、あるいは、処理担当者（ユーザ）に紐付く役割（ロール）、或いは、ワークフローシステムを運営するために必要となる情報を登録、管理することを可能とする。また、処理担当者（ユーザ）に対し配送処理を行った場合にメールで処理担当者（ユーザ）に対し通知を行うための設定（例えば、メールを配信するか否か、メールの配信のタイミング、配信の文面等の設定）の登録、管理を行うことも可能とする。

次に、図２において、本発明の実施形態におけるハードウェア構成の一例を示す図について説明を行う。

図２は、図１に示したクライアント端末１０１、クライアント端末１０２、ワークフローサーバ１０３、メールサーバ１０４、管理端末１０５のハードウェア構成の一例を示す図である。

ＣＰＵ２０１は、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。

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

ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＡＭ２０３にロードして、プログラムを実行することで各種動作を実現するものである。

また、入力コントローラ（入力Ｃ）２０５は、キーボード２０９や不図示のマウス等のポインティングデバイスからの入力を制御する。

ビデオコントローラ（ＶＣ）２０６は、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。表示器はＣＲＴだけでなく、液晶ディスプレイでも構わない。これらは必要に応じて管理者が使用するものである。本発明には直接関係があるものではない。

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

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

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

本発明を実現するためのプログラムは外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。

次に、図３において、本発明の実施形態における機能構成図について説明をする。

ワークフローサーバ１０３は、宛先決定部３１１、催促取得部３１２、配信制御部３１３、平均処理時間算出部３１４、初回催促配信時期決定部３１５、催促配信間隔決定部３１６、配送部３１７からなる。

宛先決定部３１１は、未処理の案件が所定の時間処理されていない状態である場合に、案件の処理担当者、あるいは、処理担当者以外のユーザへ、催促を配信するための宛先を決定する。また、その宛先は、催促の回数、または、催促を行った時の案件の滞留時間に応じて異なるようにする。

催促取得部３１２は、未処理の案件が所定の時間処理されていない状態である場合に、案件の処理担当者、あるいは、処理担当者以外のユーザへ、催促を配信するための催促を取得する。

配信制御部３１３は、催促取得部３１２によって取得した催促を、宛先決定部３１１で決定した催促の宛先へ配信する。なお、催促の回数に応じて、催促を行う宛先を異なるようにする場合、初回催促配信時期決定部３１５において決定する初回に催促を配信する時期、催促配信間隔決定部３１６で決定する２回目以降に催促を配信する間隔、に応じて、メールを配信するタイミングを制御する。また、メールの配信回数に応じて、宛先決定部３１１で決定する催促の宛先を異なるように制御する。また、案件の滞留時間に応じて催促を行う宛先を異なるようにする場合は、案件が処理担当者の処理待ち状態になってから経過した時間を滞留時間算出部３１８によって算出し、滞留時間に応じて宛先決定部３１１で決定する催促の宛先を異なるように制御する。

平均処理時間算出部３１４は、案件の処理担当者が、案件の処理依頼を受け付けてから実際に処理を行った時間までの平均所要時間を算出する。

初回催促配信時期決定部３１５は、催促の回数に応じて、催促を行う宛先を異なるようにする場合、未処理の案件が所定の時間処理されていない状態である場合に、案件の処理担当者、あるいは、処理担当者以外のユーザへ、案件の処理依頼を受け付けてから初回の催促を行う時期を決定する。

催促配信間隔決定部３１６は、催促の回数に応じて、催促を行う宛先を異なるようにする場合、未処理の案件が所定の時間処理されていない状態である場合に、案件の処理担当者、あるいは、処理担当者以外のユーザへ、初回の催促を行った後、２回目以降の催促を行う間隔を決定する。

配送部３１７は、クライアント端末１０１の処理部３０２により、案件の処理が行われたことを受付、次の処理担当者に対し案件の情報を配送する。

滞留時間算出部３１８は、配送部３１７により処理担当者に配送された案件が、配送されてから処理担当者の処理待ち状態になってからの経過時間を算出する。

メールサーバ１０４は、メール配信部３２１からなる。メール配信部３２１は、ワークフローサーバ１０３の配信制御部３１３によって配信された、催促取得部３１２で取得された催促と、宛先決定部３１１で指定された宛先の情報を受け取り、クライアント端末１０１、クライアント端末１０２へ対し、催促を配信する。

クライアント端末１０１、クライアント端末１０２は、受信部３０１、処理部３０２からなる。

受信部３０１は、メールサーバ１０４によって配信された催促を受け付ける。

処理部３０２は、案件の処理を行い、次の処理担当者に対し案件の情報を配送する要求をワークフローサーバ１０３に対し行う。

管理端末１０５は、管理部３３１からなる。管理部３３１は、宛先決定部３１１で宛先を決定するために必要となる宛先情報のテーブル、催促取得部３１２で催促を取得するために必要となる催促の内容が登録されるテーブル、初回催促配信時期決定部３１５において初回に催促を配信する時期を決定するために必要となるテーブル、催促配信間隔決定部３１６で２回目以降に催促を配信する間隔を決定するために必要となるテーブルの情報、を管理する。

また、ワークフローシステムの処理担当者が所属する、組織情報（部門ＩＤ、ユーザＩＤ、ロールＩＤ）や、案件の処理を行う処理担当者と処理の順序のルールであるプロセスの定義を行いワークフローシステムにおいて案件が処理されるように管理する。

次に、本発明の実施例において使用する組織図と各種テーブルについて説明を行う。なお、このテーブルについては、ワークフローサーバ１０３上に構成しても良いし、他のデータベースサーバにおいて構成しても良いこととする。

図８のワークフロー組織情報８００は、ワークフローの案件を処理するために処理担当者を決定するために必要となる組織情報を示す図である。図８の８０１から８０４は、部門に紐付く部門コードである。なお、図８の８０１から８０４で図示する箇所は、１組織単位であり、その全体を階層構造で図８は図示している。各８０１から８０４の横には、その組織に所属するユーザ（ワークフローシステムでいう処理担当者）とそのユーザに紐付くロール（課長、部長等の役割）記載しておくこととする。例えば、８０５は、部門ＩＤがＫ００２に所属するユーザ（大田：ＵＳＥＲ００２）であって、ロールは、「一般ロール：ｉｐｐａｎ」が紐付いているユーザであることを示す。その他の部門に所属するユーザについても同様であるため他のユーザについては説明を省略する。

図９の案件管理テーブル９００は、ワークフローシステムにおいて起案された案件が現在どの処理担当者に対して処理依頼がかかっているのか、現在の案件状態を管理するテーブルである。業務ＩＤ９０１は、起案された案件の業務を特定するためのＩＤが登録される。案件ＩＤ９０２は、起案された案件を特定するためのＩＤが登録される。ユーザＩＤ９０３は、案件ＩＤ９０２を処理する現在の処理担当者が登録される。部門ＩＤ９０４は、ユーザＩＤ９０３のユーザが所属する部署の部門ＩＤが登録される。処理依頼日時９０５は、案件ＩＤ９０２の処理依頼がユーザＩＤ９０３に行われた日時が登録される。

図１０のメール配信管理テーブル１０００は、処理担当者に対し未処理の案件に関する処理の催促を行うためにメール配信を行うための、配信スタートのタイミング、メールの配信間隔、メールの配信回数、メールの配信日時、を管理するテーブルである。業務ＩＤ１００１は、起案された案件の業務を特定するためのＩＤが登録される。案件ＩＤ１００２は、起案された案件を特定するためのＩＤが登録される。ユーザＩＤ１００３は、案件ＩＤ１００２を処理する現在の処理担当者が登録される。配信スタートタイミング１００４は、案件ＩＤ１００２の処理が未処理の場合に初回のメール配信を行うタイミングが登録される。配信間隔１００５は、案件ＩＤ１００２の処理に初回のメール配信が行われた後に、さらに未処理状態が続いた場合に２回目以降にメール配信を行うための間隔が登録される。配信回数１００６は、メールが配信された回数が登録される。
メール配信日時１００７は、メールが配信された日時が登録される。

図１１の処理履歴テーブル１１００は、処理担当者ごとに案件の処理依頼を受けた日時と実際に案件の処理を行った日時を管理するテーブルである。業務ＩＤ１１０１は、起案された案件の業務を特定するためのＩＤが登録される。案件ＩＤ１１０２は、起案された案件を特定するためのＩＤが登録される。ユーザＩＤ１１０３は、案件ＩＤ１１０２を処理した処理担当者が登録される。処理依頼日時１１０４は、案件ＩＤ１１０２の案件が、ユーザＩＤ１１０３の処理担当者に処理依頼された日時が登録される。処理実行日時１１０５は、案件ＩＤ１１０２をユーザＩＤ１１０３の処理担当者が、実際に処理した日時が登録される。処理時間１１０６は、処理依頼日時１１０４から処理実行日時１１０５までの時間が登録される。

図１２のワークフローユーザ情報テーブル１２００は、ワークフローシステムにおいて案件を処理する処理担当者におけるメールアドレスを管理するテーブルである。ユーザＩＤ１２０１は、処理担当者のユーザＩＤが登録される。ユーザ名１２０２は、ユーザＩＤ１２０１に紐付くユーザ名が登録される。メールアドレス１２０３は、ユーザＩＤ１２０１に紐付くメールアドレスが登録される。

図１３の初回メール配信タイミング管理テーブル１３００は、処理担当者に処理依頼がされていて未処理の案件がある場合に、処理依頼を受けてから初回に処理の催促メールを配信するまでの時間を管理するテーブルである。業務ＩＤ１３０１は、起案された案件の業務を特定するためのＩＤが登録される。判定基準１３０２は、初回の催促のメールを配信するための基準が登録される。配信スタートタイミング１３０３は、案件の処理依頼を受けてから催促のメールを配信するまでの時間が登録される。すなわち、配信制御手段によって未処理の案件の処理担当者へ催促を最初に配信する時期は、処理担当者の平均処理時間に応じて異なるようにすることとする。なお、案件の処理担当者の平均処理時間が他の処理担当者の平均処理時間よりも長い場合は、他の処理担当者よりも、最初に配信する催促を早く配信するように値を設定しても良いこととする。
デフォルト使用フラグ１３０４は、配信スタートタイミングを利用するためにデフォルトのレコードとするための値を登録しておく項目である。

図１４の催促メール配信間隔管理テーブル１４００は、処理担当者に初回に処理の催促メールが配信されながらも未処理状態が続いた場合に、２回目以降にメールを配信する間隔を管理するテーブルである。業務ＩＤ１４０１は、起案された案件の業務を特定するためのＩＤが登録される。判定基準１４０２は、２回目以降の催促のメールを配信するために基準が登録される。配信間隔１４０３は、２回目以降の催促のメールを配信する間隔の時間が登録される。すなわち、最初に配信する催促が宛先に配信されてから、催促を、第１の宛先である案件の処理担当者が処理を行うまで定期的に配信する催促の配信間隔は、第１の宛先となる処理担当者の、案件が処理待ち状態となってから処理がなされたまでの時間の平均処理時間の長さに応じて異なるようにすることとする。なお、配信間隔は、案件の処理担当者の平均処理時間が他の処理担当者の平均処理時間よりも長い場合は、他の処理担当者よりも、短くすることを行っても良いこととする。デフォルト使用フラグ１３０４は、配信間隔を利用するためにデフォルトのレコードとするための値を登録しておく項目である。

なお図１３と図１４においては、実施例においては、業務単位で配信スタートタイミング、配信間隔を管理しているが、これはあくまでも一例であって、業務単位で管理しないでシステム全体で同一の管理を行う構成であっても良いこととする。

図１５の宛先管理テーブル１５００は、催促のメールを配信する場合に必要となる、宛先とメッセージを催促が行われた回数ごとに管理するテーブルである。業務ＩＤ１５０１は、起案された案件の業務を特定するためのＩＤが登録される。回数１５０２は、催促が行われる（１回目、２回目等の）回数が登録される。宛先ロールのルール１５０３は、催促のメールを処理担当者本人以外に配信する宛先のロールのルールが登録される。なお、値が無い場合は、処理担当者本人のみへ本人用メッセージ１５０４で指定されたメッセージを配信することになる。本人用メッセージ１５０４は、処理担当者本人に配信する催促のメッセージが登録される。本人以外用メッセージ１５０５は、処理担当者本人以外に配信する催促のメッセージが登録される。なお、本実施例においては、宛先決定手段は、未処理の案件の処理担当者の宛先に配信された催促の回数が増えることに応じて、催促を配信する処理担当者ではないユーザの宛先を増やすこととする。

図１６のロール管理テーブル１６００は、図１５の宛先ロールのルールで指定されたロールを実際の処理担当者のロールを基準に相対的に管理したテーブルである。基点役割１６０１は、処理担当者のロールが登録される。１つ上の上位役割１６０２は、処理担当者のロールに対する１つ上の上位役割が登録される。２つ上の上位役割１６０３は、処理担当者のロールに対する２つ上の上位役割が登録される。３つ上の上位役割１６０４は、処理担当者のロールに対する３つ上の上位役割が登録される。なお、図１５の宛先ロールのルール１５０３に登録されている値を元に、図１６の１つ上の上位役割１６０２、２つ上の上位役割１６０３、３つ上の上位役割１６０４を参照することにより実際の催促メールの宛先となるユーザのロールの値を処理担当者ごとに抽出できるようにする。

図２３のワークフロー組織情報２３００は、ワークフローの案件を処理するために処理担当者を決定するために必要となる組織情報を示す図である。図２３の２３０１から２３０６で図示する箇所は、部門に紐付く部門ＩＤを記載している。なお、図２３の２３０１から２３０６で図示する箇所は、１組織単位であり、その全体を階層構造で図２３は図示している。各２３０１から２３０６の横には、その組織に所属するユーザ（ワークフローシステムでいう処理担当者）とそのユーザに紐付くロール（課長、部長等の役割）記載しておくこととする。例えば、２３０７は、部門ＩＤがＫ００１に所属するユーザ（山田：ＵＳＥＲ０１０）であって、ロールは、「課長ロール：ｋａｃｈｏ」が紐付いているユーザであることを示す。その他の部門に所属するユーザについても同様であるため他のユーザについては説明を省略する。

図２４の宛先管理テーブル２４００は、催促のメールを配信する場合に必要となる、宛先とメッセージを、催促が行われた回数ごとに管理するテーブルである。業務ＩＤ２４０１は、起案された案件の業務を特定するためのＩＤが登録される。回数２４０２は、催促が行われる（１回目、２回目等の）回数が登録される。宛先のルール２４０３は、催促のメールを処理担当者本人以外に配信する宛先のルールが、案件に紐づくプロセス定義に指定されている処理担当者の情報より登録される。なお、値が無い場合は、処理担当者本人のみへ本人用メッセージ２４０４で指定されたメッセージを配信することになる。本人用メッセージ２４０４は、処理担当者本人に配信する催促のメッセージが登録される。本人以外用メッセージ２４０５は、処理担当者本人以外に配信する催促のメッセージが登録される。

図２５の宛先管理テーブル２５００は、催促のメールを配信する場合に必要となる、宛先とメッセージを、催促が行われた回数ごとに管理するテーブルである。業務ＩＤ２５０１は、起案された案件の業務を特定するためのＩＤが登録される。回数２５０２は、催促が行われる（１回目、２回目等の）回数が登録される。宛先のルール２５０３は、催促のメールを処理担当者本人以外に配信する宛先のルールが、案件に紐づくプロセス定義のアクティビティの位置情報より登録される。なお、値が無い場合は、処理担当者本人のみへ本人用メッセージ２５０４で指定されたメッセージを配信することになる。本人用メッセージ２５０４は、処理担当者本人に配信する催促のメッセージが登録される。本人以外用のメッセージ２５０５は、処理担当者本人以外に配信する催促のメッセージが登録される。

図２８の宛先管理テーブル２８００は、催促のメールを配信する場合に必要となる、宛先とメッセージを、案件の処理待ち状態になってから経過した時間ごとに管理するテーブルである。業務ＩＤ２８０１は、起案された案件の業務を特定するためのＩＤが登録される。経過時間２８０２は、催促を行うための経過時間の範囲が登録される。宛先ロールのルール２８０３は、催促のメールを処理担当者本人以外に配信する宛先ロールのルールが登録される。なお、値が無い場合は、処理担当者本人のみへ本人用メッセージ２４０４で指定されたメッセージを配信することになる。本人用メッセージ２８０４は、処理担当者本人に配信する催促のメッセージが登録される。本人以外用メッセージ２８０５は、処理担当者本人以外に配信する催促のメッセージが登録される。

図３３の案件期限管理テーブル３３００は、案件の処理期限を管理するテーブルである。案件ＩＤ３３０１は、申請された案件の案件ＩＤが登録される。案件の処理期限３３０２は、案件がワークフローにおいて最終の処理がなされるべき期限が登録される。なお、この期限については、案件の申請者が申請時に設定する方法、ワークフローの管理者が申請される案件に紐づく業務単位で期限を設定する方法、等によって行うことを可能とする。また、この方法については限定しない。

図３５の宛先管理テーブル３５００は、催促のメールを配信する場合に必要となる、宛先とメッセージを、催促が行われた回数ごとに管理するテーブルである。業務ＩＤ３５０１は、起案された案件の業務を特定するためのＩＤが登録される。回数３５０２は、催促が行われる（１回目、２回目等の）回数が登録される。宛先ロールのルール３５０３は、催促のメールを処理担当者本人以外に配信する宛先のロールのルールが登録される。なお、値が無い場合は、処理担当者本人のみへ本人用メッセージ３５０４で指定されたメッセージを配信することになる。本人用メッセージ３５０４は、処理担当者本人に配信する催促のメッセージが登録される。本人以外用メッセージ３５０５は、処理担当者本人以外に配信する催促のメッセージが登録される。

図３８の追加宛先管理テーブル３８００は、案件の処理期限までの残り時間が、案件の平均処理時間を切っている場合に催促を送る場合に、追加の宛先を取得するための宛先ロールのルールを管理するテーブルである。すなわち、催促を送る時から案件の処理期限までの時間が、第１の宛先に関する処理済みの案件の平均処理時間よりも短い場合に、催促を送信する所定の送信先を記憶する。また、追加の宛先に送る催促のメッセージも管理する。業務ＩＤ３８０１は、起案された案件の業務を特定するためのＩＤが登録される。回数３８０２は、催促が行われる（１回目、２回目等の）回数が登録される。宛先ロールのルール３８０３は、催促のメールを処理担当者本人以外に配信する宛先のロールのルールが登録される。本人以外用メッセージ３８０４は、処理担当者本人以外に配信する催促のメッセージが登録される。
＜第１の実施形態＞

次に、以下、図４〜７を参照して、第１の実施形態における本発明の催促メール配信処理について説明する。第１の実施形態では、催促を送る回数に応じて、催促を送る対象者を決定する方法において、本人以外に催促を送る対象者は、案件の処理担当者が所属する組織の情報から決定する実施形態について説明する。なお、図４、５、６は全てワークフローサーバ１０３のＣＰＵ２０１の処理であることとする。また図７においては、ステップＳ７１１、７１４はメールサーバ１０４のＣＰＵ２０１、ステップＳ７１２、７１３は、クライアント端末１０１のＣＰＵ２０１、ステップＳ７１５、７１６は、クライアント端末１０２のＣＰＵ２０１の処理であることとし、それ以外の処理はワークフローサーバ１０３のＣＰＵ２０１の処理とする。

図４は、催促メール配信処理のメインの処理である。なお、本処理は１０分単位で処理を繰り返すことを前提とする。

ステップＳ４０１では、案件管理テーブル９００を参照し、案件の件数を取得する。取得した案件数分以下ステップＳ４０２からステップＳ４０９までの処理を繰り返す。

ステップＳ４０２では、案件管理テーブル９００を参照し、案件情報である、業務ＩＤ９０１、案件ＩＤ９０２、ユーザＩＤ９０３、部門ＩＤ９０４、処理依頼日時９０５の各項目を取得して、ステップＳ４０３へ処理を進める。

なお、本処理の説明を行うにあたって、ステップＳ４０２においては、図９の９０８のレコードの、業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５の値を取得することによって、ステップＳ４０３以降の処理の説明を行うこととする。

ステップＳ４０３では、処理中の案件に対して、本処理が初回の処理かどうかを判定する。メール配信管理テーブル１０００を参照し、ステップ４０２で取得した値である、業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、をもとに対象となるレコードを取得する。その際、レコードの取得できなかった場合（ステップＳ４０３でＮＯの場合）、初回処理とみなしてステップＳ４０４へ処理を進める。レコードの取得が出来た場合（ステップＳ４０３でＹＥＳの場合）は２回目以降の処理とみなしてステップＳ４０８へ処理を進める。例として挙げている、図９の９０８のレコードの場合、業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、の値で、メール配信管理テーブル１０００を参照すると、メール配信管理テーブル１０００の１０１０のレコードが存在することとなるため、ステップＳ４０８へ処理を進める。また、該当の１０１０のレコードの配信回数１００６が１となっているが、これは、過去にメールの配信が１回行われているという意味となる。

ステップＳ４０４では、案件に紐付いたユーザの処理速度の算出を行う。ステップＳ４０２で取得した、ユーザＩＤ９０３＝ＵＳＥＲ００１、をもとに、図１１の処理履歴テーブル１１００を参照し、例えば、処理依頼日時１１０４と処理実行日時１１０５が現在日付から１ヶ月以内に存在する該当のレコードを取得する。そのレコードの各処理時間１１０６を取得し、取得された処理時間１１０６の平均値を算出後、その値をユーザの平均処理時間として保持して、ステップＳ４０５へ処理を進める。例えば、例として挙げている、図９の９０８のレコードの業務ＩＤ９０１＝Ｇ００２、ユーザＩＤ９０３＝ＵＳＥＲ００１をもとに処理履歴テーブル１１００を参照すると、１１１０、１１１１、１１１２のレコードが対象となり、これら全てが処理依頼日時１１０４と処理実行日時１１０５が現在日付から１ヶ月以内に存在すると仮定すると、この場合、平均処理時間の値は１２時間となる。

なお、現在日付から１ヶ月以内という期間設定を行っているが、これに限定されることはなく、期間は任意に設定しても、すなわち、平均処理時間は、過去一定の期間（任意の期間）において算出することとしても、あるいは、過去の全ての処理履歴を対象とする場合は、その期間を設定しても良いこととする。また、処理履歴の対象範囲をユーザＩＤに紐付く全ての案件から抽出してもよいし、ユーザＩＤに紐付く中でも、処理対象となっている案件と同じ業務の過去の処理履歴から処理履歴を算出しても良いこととする。すなわち、平均処理時間は、ワークフローシステム単位、または、ワークフローシステムで起案可能な業務の業務単位において処理担当者ごとにおいて算出しても良いこととする。

ステップＳ４０５では、初回に配信するメールの配信タイミングを取得する処理を行う。取得方法については図５の初回メール配信タイミング取得処理において説明する。

ステップＳ４０６では、２回目以降に配信するメールの配信間隔を取得する処理を行う。取得方法については図６の催促メール配信間隔取得処理において説明する。

ステップＳ４０７では、初回のメール配信処理としてメールの配信回数を設定する。そのため、対象案件におけるメールの配信回数を０に設定して、ステップＳ４０９に処理を進める。

一方、ステップＳ４０８では、２回目以降の処理としてメールの配信回数を設定する。図９の９０８のレコードの場合、業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、の値で、メール配信管理テーブル１０００を参照すると、メール配信管理テーブル１０００の１０１０のレコードが該当のレコードとなり、そのレコードの配信回数１００６の値の１を取得し、配信回数を１とする。その後ステップＳ４０９へ処理を進める。

ステップＳ４０９では、配信回数に応じた催促メールの宛先設定とメールの配信処理を行う。処理内容については、図７の催促メール配信処理の宛先設定及びメール配信の処理において説明する。

図５では、処理の担当者に配信する初回の催促メールについて、案件の処理依頼を受けてからどのぐらいのタイミングで配信するかを、案件に紐付いたユーザの平均処理時間に合わせて決定する初回メール配信タイミング取得処理について説明をする。

ステップＳ５０１では、初回メール配信のタイミングにデフォルト値を使用するかどうかを示したフラグをテーブルから取得する。初回メール配信タイミング管理テーブル１３００を参照し、まず、業務ＩＤ１３０１がｄｅｆａｕｌｔの値であるレコード（１３０５）のデフォルト使用フラグ１３０４の値を取得して、ステップＳ５０２へ処理を進める。なお、デフォルト使用フラグ１３０４の値がＦＡＬＳＥの場合は、このレコードの配信スタートタイミング１３０３の値は使わず、ＴＲＵＥの場合は、このレコードの配信スタートタイミング１３０３の値を使うということになる。

ステップＳ５０２では、初回メール配信のタイミングにデフォルト値を使用するかどうか判定を行う。ステップＳ５０１で取得したデフォルト使用フラグ１３０４がＴＲＵＥの場合（ステップＳ５０２でＹＥＳの場合）はデフォルトのタイミングを使用するものとして、ステップＳ５０３へ処理を進める。デフォルト使用フラグ１３０４がＦＡＬＳＥの場合（ステップＳ５０２でＮＯの場合）は処理速度に応じた設定値を使用するものとして、ステップＳ５０４へ処理を進める。

ステップＳ５０３では、初回メール配信のタイミングにデフォルトの値を使用するものとして、初回メール配信タイミング管理テーブル１３００を参照し、業務ＩＤ１３０１がｄｅｆａｕｌｔのレコードの配信スタートタイミング１３０３の値を取得する。例えば図１３の場合、配信スタートタイミング１３０３は２４時間後ということになる。

一方、ステップＳ５０４では、処理速度に応じた設定値を使用することになるため、ステップ４０２で取得した業務ＩＤ９０１＝Ｇ００２を元に、初回メール配信タイミング管理テーブル１３００を参照し、該当するレコード（１３０６）の判定基準１３０２とステップＳ４０４で取得した処理速度を用いて、該当する配信スタートタイミング１３０３を取得する。例えば、図９の９０８の案件の処理担当者となるユーザＩＤの平均処理時間が、ステップＳ４０４において算出した平均処理時間は１２時間であるため、図１３の該当のレコード（１３０６）の判定基準１３０２の条件に合致するため、配信スタートタイミング１３０３の１７時間を配信スタートタイミングとして取得する。すなわち、第１の宛先となる処理担当者の、案件が処理待ち状態となってから処理がなされたまでの時間の平均処理時間に応じて、催促を前記宛先に最初に配信する時期を異なるようにすることが可能になる。

図６では、処理の担当者に繰り返し配信する２回目以降の催促メールについて、どれぐらいの間隔で繰り返して配信するのか、案件に紐付いたユーザの平均処理時間に合わせて取得する処理を記載する。

ステップＳ６０１では、配信間隔にデフォルト値を使用するかどうかを示したフラグをテーブルから取得する。催促メール配信間隔管理テーブル１４００を参照し、業務ＩＤ１４０１がｄｅｆａｕｌｔの値であるレコード（１４０５）のデフォルト使用フラグ１４０４の値を取得して、ステップＳ６０２へ処理を進める。なお、デフォルト使用フラグ１４０４の値がＦＡＬＳＥの場合は、このレコードの配信間隔１４０３の値は使わず、ＴＲＵＥの場合は、このレコードの配信間隔１４０３の値を使うということになる。

ステップＳ６０２では、配信間隔にデフォルト値を使用するかどうかの判定を行う。ステップＳ６０１で取得したデフォルト使用フラグ１４０４の値がＴＲＵＥの場合（ステップＳ６０２でＹＥＳの場合）は、デフォルトのタイミングを使用するものとして、ステップＳ６０３へ処理を進める。デフォルト使用フラグ１４０４の値がＦＡＬＳＥの場合（ステップＳ６０２でＮＯの場合）は処理速度に応じた設定値を使用するものとして、ステップＳ６０４へ処理を進める。

ステップＳ６０３では、配信間隔にデフォルトの値を使用するものとして、催促メール配信間隔管理テーブル１４００を参照し、業務ＩＤ１４０１がｄｅｆａｕｌｔのレコード（１４０５）の配信間隔１４０３の値を取得する。例えば図１４の場合、配信間隔１４０３は１２時間後ということになる。

一方、ステップＳ６０４では、処理速度に応じた設定値を使用することになるため、ステップ４０２で取得した業務ＩＤ９０１＝Ｇ００２を元に、催促メール配信間隔管理テーブル１４００を参照し、該当するレコード（１４０６）の判定基準１４０２とステップＳ４０４で取得した処理速度を用いて、該当する配信間隔１４０３を取得する。例えば、図９の９０８の案件の処理担当者となるユーザＩＤの平均処理時間が、ステップＳ４０４において算出した平均処理時間が、は１２時間であるため、図１４の該当のレコード（１４０６）の判定基準１４０２の条件に合致するため、配信間隔１４０３の６時間を配信間隔として取得する。

すなわち、第１の宛先となる処理担当者の、案件が処理待ち状態となってから処理がなされたまでの時間の平均処理時間の長さに応じて、定期的に配信する催促の配信間隔を異なるように催促を配信可能であることとする。

図７では、処理中の案件の催促メールの配信回数に応じて、宛先とメッセージの設定を行い、配信可能時刻になった場合に、メールを配信する処理について記載する。

ステップＳ７０１では、処理中の案件のメール配信が未実施か否かを判定する。具体的には、ステップＳ４０７または、ステップＳ４０８で取得した配信回数が０である場合、メール配信は未実施とみなしてステップＳ７０２へ処理を進める。ステップＳ４０７または、ステップＳ４０８で取得した配信回数が０でない場合、メール配信実施済みとみなしてステップＳ７０３へ処理を進める。

例えば、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）の場合、ステップＳ４０８で配信回数は１回として取得しているため、メール配信は実施済みとなり、ステップＳ７０３へ処理を進める。

ステップＳ７０２では、メール配信未実施なので、現在日時が、処理依頼日と配信スタートタイミングで取得した時間から算出したメール配信予定日時に達しているかどうか判定する。ステップＳ４０２で取得した処理依頼日時９０５とステップＳ５０４またはステップＳ５０３で取得した配信スタートタイミングを加算して、その日時が現在日時を過ぎている場合（ステップＳ７０２でＹＥＳの場合）、既にメール配信予定日時になったとみなして、ステップＳ７０４へ処理を進める。その日時が現在日時を過ぎていない場合（ステップＳ７０２でＮＯの場合）、まだメール配信予定日時になっていないとみなして、ステップＳ７１０へ処理を進める。

例えば、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）の場合、その処理依頼日時９０５に配信間隔スタートタイミングの値（図１０の１０１０の配信スタートタイミング１００４の値が１７時間後であるため１７時間）を足すと、２０１４／５／２２ １５：３０：０５＋１７時間＝２０１４／５／２３ ０８：３０：０５となる。その結果が、現在日時より過ぎている場合、ステップＳ７０４に処理を進める。また、その結果が現在日時より過ぎていないと場合は、ステップＳ７１０へ処理を進める。

一方、ステップＳ７０３では、メール配信が２回目以降なので、現在日時が、前回のメール配信日時と取得した配信間隔によって算出したメール配信予定日時に達しているかどうか判定する。

例えば、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）の場合、ステップ４０２で取得した、業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１をもとにメール配信管理テーブル１０００を参照して、対象となるレコード（１０１０）のメール配信日時１００７と配信間隔１００５を取得する。メール配信日時１００７と配信間隔１００５（ステップＳ６０４またはステップＳ６０３で取得した配信間隔はステップＳ７１０でメール配信管理テーブル１０００の配信間隔１００５に登録されている）を加算して、その日時が現在日時を過ぎている場合（ステップＳ７０３でＹＥＳの場合）、既にメール配信予定日時になったとみなして、ステップＳ７０４へ処理を進める。ただし、その日時が現在日時を過ぎていない場合（ステップＳ７０３でＮＯの場合）、まだメール配信予定日時になっていないとみなして、本処理を終了する。図９の９０８のレコードの場合、メール配信管理テーブル１０００の１０１０のレコードが対応するレコードとなり、その、メール配信日時１００７に配信間隔１００５を足すと、２０１４／５／２３ ０８：３０：０５＋６時間＝２０１４／５／２３ １４：３０：０５となる。その結果が、現在日時を過ぎている場合は、ステップＳ７０４に処理を進める。また、その結果が現在日時を過ぎていない場合、本処理を終了する。

ステップＳ７０４では、処理中の案件の催促メール配信回数に応じて、宛先のロールのルールとメッセージの取得を行う。図９の９０８のレコードの業務ＩＤ９０１＝Ｇ００２をもとに、宛先管理テーブル１５００を参照して、業務ＩＤ１５０１が同じレコードの中より、回数１５０２に、ステップＳ４０７またはステップＳ４０８で取得した配信回数に１加算した値と同じ値の回数が保持されたレコードを取得する。例えば、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）の場合、現在のところメール配信管理テーブル１０００の配信回数は１であるため、業務ＩＤ１５０１がＧ００２で、回数１５０２は２の値のレコードを取得する（図１５の１５１０）。次に、そのレコードの宛先ロールのルール１５０３、本人用メッセージ１５０４、本人以外用メッセージ１５０５を取得する。取得されたレコード（図１５の１５１０）の場合、宛先ロールのルール１５０３は、「１つ上の上位役割、２つ上の上位役割」、本人用メッセージ１５０４は、「２回目催促：処理してください」、本人以外用メッセージ１５０５は「［ユーザ名］さんが１度目の催促を無視して［案件名］の処理をしていません。処理がされるように連絡してください。」、の値を取得する。その後、ステップＳ７０５に処理を進める。すなわち、未処理の案件の処理担当者の宛先に配信される処理の催促の回数に応じて、催促を配信する宛先を決定する（宛先決定手段）。宛先は、処理担当者、または、処理担当者と前記処理担当者ではないユーザのいずれかの宛先である。また、宛先決定手段で決定される宛先に対する催促を取得する（催促取得手段）。また、前記宛先決定手段で決定される宛先に、催促を宛先に配信するための配信制御を行う（配信制御手段）。

ステップＳ７０５では、ステップＳ７０４で取得した宛先ロールのルール１５０３に該当するユーザが、ワークフローの組織上のどのユーザに当たるのか解決し、ステップＳ７０４で取得した本人以外用メッセージ１５０５を送る人を特定する。

まず、宛先ロールのルール１５０３における、処理担当者の「１つ上の上位役割（２つ上の上位役割、３つ上位の役割）」については、処理担当者によって相対的に変わってくるため、役割の実際の値を特定するために、ロール管理テーブル１６００に図示する、各ロールに対応した上位役割を参照し取得する。例えば、処理者のロールがＵＳＥＲ００１（図１８の８０７）の場合、基点役割１６０１がｉｐｐａｎ（１６１０）を参照し、１つ上の上位役割１６０２は、ｋａｃｈｏ（１６０２）となる。また、処理者のロールがＵＳＥＲ０１０（図１８の８０８）の場合、基点役割１６０１がｋａｃｈｏ（１６２０）を参照し、１つ上の上位役割１６０２は、ｂｕｃｈｏ（１６０２）となる。すなわち、宛先決定手段によって決定される処理担当者ではないユーザは、処理担当者に指定された役割よりも上位の役割であることとする。

次に、その役割を持つものを、本実施例においては、ワークフローの処理担当者が所属する図８の組織の同一組織系列の部門から特定する方法によって特定することとする。例えば、図８、ワークフロー組織情報８００のＵＳＥＲ００１（８０７）のユーザの所属する組織は、本部００１、部００１、課００１のそれぞれの階層に割り当てられた組織コードを連結すると、ＨＢ００１Ｂ００１Ｋ００１で示すことが出来る。次に、同一系列階層においてＵＳＥＲ００１のロール（ｉｐｐａｎ）の１つ上の上位役割（ｋａｃｈｏ）のユーザがいないかを判定する。ＵＳＥＲ００１（８０７）の場合、まず同階層にｋａｃｈｏの役割をもつＵＳＥＲ０１０が存在するため、ＵＳＥＲ０１０（８０８）の山田を同一系列階層において１つ上の上位役割のユーザとして特定することが出来る。また、図８のＵＳＥＲ０１０が処理担当者である場合、ＵＳＥＲ０１０が所属する組織は、本部００１、部００１、課００１のそれぞれの階層に割り当てられた組織コードを連結すると、ＨＢ００１Ｂ００１Ｋ００１で示すことが出来る。次に、同一系列階層においてＵＳＥＲ０１０のロール（ｋａｃｈｏ）の１つ上の上位役割のユーザがいないかを判定する。ＵＳＥＲ０１０（８０８）の場合、１つ上の上位役割のｂｕｃｈｏの役割をもつ人がいるかを判定する。この場合同階層にはいないため、次に、１つ上の階層である、ＨＢ００１Ｂ００１の組織にｂｕｃｈｏの役割をもつユーザがいるかを探索する。この組織にはＵＳＥＲ０２０（８０９）が存在するため、ＵＳＥＲ０２０（８０９）の井上が同一系列階層において１つ上の上位役割を持つユーザとして特定することが出来る。すなわち、宛先決定手段によって決定される処理担当者ではないユーザは、処理担当者が所属する組織の同系列の階層に所属するユーザであることとする。

例えば、図９の９０８のレコードの場合、ユーザＩＤ９０３がＵＳＥＲ００１、部門ＩＤ９０４がＫ００１の値をもとに、ステップＳ７０４において、図１５の１５１０のレコードが取得できているため、宛先ロールのルール１５０３の値は、「１つ上の上位役割、２つ上の上位役割」となる。

ユーザＩＤ９０３のＵＳＥＲ００１は図８においてロールがｉｐｐａｎであるため、１つ上の上位役割は、図１６を参照するとｋａｃｈｏとなる。また、２つ上の上位役割は、図１６を参照するとｂｕｃｈｏとなる。ユーザＩＤ９０３のＵＳＥＲ００１は、図８の８０３に示す組織コードがＫ００１に所属しているため、同一組織系列の階層におけるｋａｃｈｏは、ＵＳＥＲ０１０（８０８）の山田となる。また、同一組織系列の階層におけるｂｕｃｈｏは、ＵＳＥＲ０２０（８０９）の井上となる。したがって、この２人を本人以外用メッセージ１５０５を配信する人として特定することが出来る。

なお、本実施例においては、処理担当者以外に催促を配信するユーザを処理担当者の上位役割を持つユーザから取得するようにしているが、処理担当者との関係において上位の役割でなくてもよく、ある特定の役割のユーザから取得できるようにしても良いこととする。すなわち、宛先決定手段によって決定される処理担当者ではないユーザは、特定の役割を持つユーザであることとする。

また、本実施例においても説明したとおり、処理担当者以外に催促を配信するユーザを処理担当者の上位役割を持つユーザから取得するようにしているが、このユーザは、処理担当者が処理をする案件のプロセス定義上の処理担当者となっていなくても良いということである。すなわち、宛先決定手段によって決定される処理担当者ではないユーザは、処理担当者が処理する案件のプロセスの処理担当者ではなくても良いこととする。

なお、催促を送る宛先となる、処理待ち状態の案件を処理する予定を現在保持する処理担当者を第１の宛先とし、処理担当者以外に催促を送るユーザを第２の宛先と呼んでも良いこととする。

ステップＳ７０６では、ステップＳ７０５でメール配信対象として取得したワークフローのユーザ情報のメールアドレスを取得する。図１２のワークフローユーザ情報テーブル１２００を参照して、ステップＳ４０２で取得したユーザＩＤ９０３とステップＳ７０５で取得したユーザＩＤのそれぞれ対応するユーザＩＤ１２０１のメールアドレス１２０３を取得する。すなわち、催促は処理担当者へ配信される催促メールであり、宛先は催促メール配信するためのメールアドレスであることとする。

例えば、ステップＳ４０２で取得したユーザＩＤがＵＳＥＲ００１で、ステップＳ７０５で取得したユーザＩＤがＵＳＥＲ０１０、ＵＳＥＲ０２０である場合、ＵＳＥＲ００１＠ｃｏ．ｊｐを本人用メッセージ１５０４の宛先として取得し、ＵＳＥＲ０１０＠ｃｏ．ｊｐとＵＳＥＲ０２０＠ｃｏ．ｊｐを本人以外用メッセージ１５０５の宛先として取得する。

ステップＳ７０７では、処理を遅延しているユーザ本人（第１の宛先）に、ステップＳ７０４で取得した、本人用メッセージ１５０４と、ステップＳ７０６で取得した、図９のレコード（９０８）の処理担当者（第１の宛先）であるＵＳＥＲ００１のメールアドレスの情報を利用してメールサーバ１０４に対しメールの配信の依頼を行う。すなわち、催促取得手段で取得された催促を宛先に配信するための配信制御を行う（配信制御手段）。

ステップＳ７０８では本人以外のユーザに催促メールを配信する必要があるか、宛先ロールのルールの有無で判定する。ステップＳ７０４で取得した宛先ロールのルール１５０３に値が設定されている場合（ステップＳ７０８においてＹＥＳの場合）、本人以外への催促メールを配信する必要があるとみなして、ステップＳ７０９へ処理を進める。ステップＳ７０４で取得した宛先ロールのルール１５０３に値が設定されていなかった場合（ステップＳ７０８においてＮＯの場合）、本人以外への催促メールを配信する必要がないとみなして、ステップＳ７１０へ処理を進める。すなわち、宛先決定手段は、メールの配信回数が所定回数を下回るときは処理担当者ではないユーザの宛先設定しないこととする（図１５、１５０６の宛先ロールのルール１５０３）。

図９の９０８のレコードの現在の状態においては、ステップＳ７０４では、宛先ロールのルール１５０３の値として「１つ上の上位役割、２つ上の上位役割」を取得しているため、ステップＳ７０９へ処理を進める。

ステップＳ７０９では、処理を遅延しているユーザ本人以外（第２の宛先）にステップＳ７０４で取得した、本人以外用メッセージ１５０５と、ステップＳ７０６で取得した、図９のレコード（９０８）の処理担当者であるＵＳＥＲ００１以外のメールアドレスの情報（第２の宛先）を利用してメールサーバ１０４に対しメールの配信の依頼を行う。

ステップＳ７１０は、ステップ４０２で取得した業務ＩＤ９０１、案件ＩＤ９０２、ユーザＩＤ９０３をキーとしてメール配信管理テーブル１０００登録処理または更新処理を行う。

登録処理となるのは、図７のメール配信の処理が案件に対して最初に行われた場合、すなわち、最初にステップＳ７０２でＮＯとなることで図７の処理が行われた場合、である。この場合、業務ＩＤ１００１へはステップＳ４０２で取得した業務ＩＤ９０１の値、案件ＩＤ１００２へはステップＳ４０２で取得した案件ＩＤ９０２、ユーザＩＤ１００３へはステップＳ４０２で取得したユーザＩＤ９０３の値、配信スタートタイミング１００４へはステップＳ５０３またはステップＳ５０４で取得した値、配信間隔１００５へはステップＳ６０３またはステップＳ６０４で取得した値、配信回数はステップＳ７１０の処理よりも前の処理において取得された配信回数の値、を設定し登録する。

更新処理となる場合は、催促メールが配信場合である。この場合、業務ＩＤ１００１、案件ＩＤ１００２、ユーザＩＤ１００３をキーとする、処理対象となっている案件に該当するレコードは既に登録されているため、業務ＩＤ１００１、案件ＩＤ１００２、ユーザＩＤ１００３をキーとして、配信回数１００６、メール配信日時１００７を更新する。配信回数１００６へは、ステップＳ４０５で取得した配信回数に１を加算した値で、メール配信日時１００７へは、メールが配信された時刻の値で、更新する。

例えば、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）の場合、初回の登録の場合、業務ＩＤ１００１へはＧ００２、案件ＩＤ１００２へはＡ００４、ユーザＩＤ１００３へはＵＳＥＲ００１、配信スタートタイミング１００４へは１７時間後、配信間隔１００５へは６時間、配信回数へは０回、を値として設定し登録することになる。また登録後、１回目のメール配信がされた後は、配信回数１００６へは１、メール配信日時１００７へはメールの配信日時、を値として設定し該当のレコードを更新する（図１０の１０１０）ことになる。

ステップＳ７１１において、メールサーバ１０４は、ステップＳ７０７においてワークフローサーバ１０３によって配信依頼を受けたメールの情報をもとに、クライアント端末１０１に対し、メールを配信する。

ステップＳ７１２において、クライアント端末１０１は、ステップＳ７１１でメールサーバ１０４より配信されたメールを受信する。

ステップＳ７１３において、クライアント端末１０１は、ステップＳ７１２においてクライアント端末１０１が受信したメールを表示画面において、表示する。なお、メールのイメージとしては、図１７の１７１０に図示するようになる。メールの宛先にはステップＳ７０６で取得したＵＳＥＲ００１のメールアドレスであるＵＳＥＲ００１＠ｃｏ．ｊｐが設定される（１７１１）。また、ステップＳ７０４で、本人用メッセージ１５０４として、「２回目催促：処理して下さい。」を取得しているため、その文言がメール本文に記載される（１７１２）。

ステップＳ７１４において、メールサーバ１０４は、ステップＳ７０９においてワークフローサーバ１０３によって配信依頼を受けたメールの情報をもとに、クライアント端末１０２に対し、メールを配信する。

ステップＳ７１５において、クライアント端末１０２は、ステップＳ７１４で配信されたメールを受信する。ステップＳ７０６で取得したメールアドレスによって配信されるクアライアント端末の数分の宛先分クライアント端末において、配信されたメールを受信する。

ステップＳ７１６において、クライアント端末１０２は、ステップＳ７１５でクライアント端末１０２が受信したメールを表示画面において、表示する。

なお、メールのイメージとしては、図１７に図示するようになる。ステップＳ７０４で、本人以外用メッセージ１５０５として、「［ユーザ名］さんが１度目の催促を無視して［案件名］の処理をしていません。処理がされるように連絡してください。」を取得しているため、［ユーザ名］の部分には、処理対象として説明を行っている図９、９０８のレコードのユーザＩＤ９０３の値＝ＵＳＥＲ００１の値を入れ、［案件名］の部分には、処理対象として説明を行っている図９、９０８のレコードの案件ＩＤ９０２の値＝Ａ００４を代入してメッセージを作成している（１７２２、１７３２）。また、メールの宛先にはステップＳ７０６で取得した、処理対象として説明を行っている図９、９０８のレコードのユーザＩＤ９０３であるＵＳＥＲ００１、の１つ上の役割（ｋａｃｈｏ）を持つユーザ（ＵＳＥＲ０１０）に紐付くメールアドレスであるＵＳＥＲ０１０＠ｃｏ．ｊｐと、の２つ上の役割（ｂｕｃｈｏ）を持つユーザ（ＵＳＥＲ０２０）に紐付くメールアドレスであるＵＳＥＲ０２０＠ｃｏ．ｊｐと、が設定される（１７２１、１７３１）。

すなわち、催促を第１の宛先と第２の宛先に送信する場合、第１の宛先を第１の宛先に送信する催促の宛先へ、第２の宛先を第２の宛先に送信する催促の宛先へそれぞれ設定することにより、第１の宛先に送信する催促と第２の宛先に送信する催促を個別に配信可能であることとする。

なお、図９の９０８のレコードにおける１回目の催促メールは、宛先管理テーブル１５００の１５０９のレコードを元に配信を依頼するため、処理担当者本人用の催促メールは図２０の２０１０となり、処理担当者本人以外のユーザへ配信される催促メールは２０２０のみとなる。

続いて、本発明の第１の実施形態における、案件の処理期限がある場合の催促の配信の方法について説明を行う。これまでの説明では、どの案件も、案件に対する催促を行う宛先については、配信の回数に応じた宛先を、宛先管理テーブル１５００よりの宛先のルールを取得することにより決定していた。したがって、初回に催促を送る場合には、どのような案件でも必ず、初回（回数の値が１）に設定されている宛先に対して催促が送られることになる。これから説明する方法は、案件に処理の期限が設定されていることが前提であるとし、催促を配信する時に、案件の処理期限までの時間が、処理担当者の案件の平均処理時間をきっていて、かつ、かつ、現在保持する配信回数に対応する、案件を処理すべき処理担当者以外の宛先、が宛先管理テーブルから取得できなかった場合に、初回に催促の送信を送る宛先を、宛先管理テーブルより決定される初回の宛先ではなく、次の２回目に決定される宛先に催促を送信するという方法である。なお、宛先管理テーブルに、初回に催促が送られる宛先は、案件を処理すべき処理担当者のみの設定であって、２回目以降に催促が送られる宛先は、案件を処理すべき処理担当者以外の宛先が設定されていることを前提とする。

なお、この方法について図３４を用いて説明を行う。なお、図３４においては、第１の実施形態の図７の同様の処理となる処理が存在し、その処理については、図７と、同じステップの番号を付与することとする。また、第１の実施形態の図７の処理と同様の動作をするものについては、説明を省略し、異なる動作となる処理について説明を行う。また、図３４の処理は、第１の実施形態の図４のステップＳ４０９のメール配信処理であることとする。

図３４の、ステップＳ３４０１、ステップＳ３４０２、ステップＳ３４０３はワークフローサーバ１０３のＣＰＵ２０１の処理とする。

ステップＳ３４０１において、案件の処理期限までの残り時間が、ユーザの平均処理時間をきり、かつ、現在保持する配信回数に対応する、案件を処理すべき処理担当者以外の宛先、が宛先管理テーブルから取得できたか否かを判断する。

ステップＳ３４０１において、案件の処理期限までの残り時間がユーザの平均処理時間をきり、かつ、現在保持する配信回数に対応する、案件を処理すべき処理担当者以外の宛先、が宛先管理テーブルから取得できた場合は、ステップＳ７０４へ処理を進める。ステップＳ３４０１において、案件の処理期限までの残り時間がユーザの平均処理時間をきり、かつ、現在保持する配信回数に対応する、案件を処理すべき処理担当者以外の宛先、が宛先管理テーブルから取得できなかった場合は、ステップＳ３４０２へ処理を進める。

なお、処理期限までの残り時間と平均処理時間の比較は、具体的には、図３３の案件期限管理テーブル３３００から取得した案件の処理期限までの時間と、対象案件の処理担当者の平均処理時間と比較することで行う。

例えば、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）の案件の処理期限を、図３３の案件期限管理テーブル３３００から、案件ＩＤ＝Ａ００４の値をもとに検索すると、案件ＩＤ３３０１が「Ａ００１」のレコードの案件の処理期限３３０２は、「２０１４／０５／２２ ２３：５９：５９」であるため（図３３、３３１０）、期限は、２０１４／０５／２２ ２３：５９：５９となる（処理期限取得手段）。

また、図９の９０８のレコード（案件）の処理担当者である「ＵＳＥＲ００１」の、業務ＩＤが「Ｇ００２」における案件の平均処理時間が、図１１の処理履歴テーブル１１００より１２時間であるとする。

ステップＳ３４０１が行われた時刻（メール配信を行う直前の時刻）が、「２０１４／０５／２２ １５：３１：００」だとすると、その時刻から、「２０１４／０５／２２ ２３：５９：５９」までの時間は、８時間２８分５９秒となる。この時間を、平均処理時間である１２時間と比較すると、既に、案件の処理期限までの残り時間が、ユーザの平均処理時間をきっていることになる。

次に、現在保持する配信回数に対応する、案件を処理すべき処理担当者以外の宛先、が宛先管理テーブルから取得できたか否かの確認については、以下の通り確認を行う。例えば、初回の催促の配信において、すなわち、配信回数がステップＳ３４０１の段階で「１」である場合、宛先管理テーブル３５００においては、例えば、業務ＩＤ３５０１がＧ００２で、回数３５０２は「１」の値のレコードを取得したとする（図３５の３５０９）。取得されたレコード（図３５の３５０９）の宛先ロールのルール３５０３は値が存在しないため、この場合、案件を処理すべき処理担当者以外の他の宛先を取得することができない、ということになる。

このような場合は、案件の処理期限までの残り時間がユーザの平均処理時間をきり、かつ、現在保持する配信回数に対応する、案件を処理すべき処理担当者、ではない宛先、が宛先管理テーブルから取得できていないため、ステップＳ３４０２へ処理を進める。

なお、案件の処理期限までの残り時間がユーザの平均処理時間をきっていたとしても、例えば、取得されたレコード（図３５の３５０９）の宛先ロールのルール３５０３に、他の宛先となる値が存在した場合は、案件を処理すべき処理担当者以外の他の宛先を取得できているため、ステップＳ３４０１はＮＯとなり、ステップＳ３４０２の処理は行わず、現在保持する配信回数のままステップＳ７０４の処理へ進める。

ステップＳ３４０２において、対象案件が現在保持する配信回数の値に「１」を加算して、ステップＳ７０４に処理を進める。

その他、図３４の他の処理については、図７の同一ステップと同じ動作とする。なお、図３４のステップＳ３４０３のメール配信管理テーブルへの更新の値については、以下の通りとする。

ステップＳ３４０３は、ステップ４０２で取得した業務ＩＤ９０１、案件ＩＤ９０２、ユーザＩＤ９０３をキーとしてメール配信管理テーブル１０００登録処理または更新処理を行う。

登録処理となるのは、図３４の処理が案件に対して最初に行われた場合（すなわち最初の処理において、ステップＳ７０２でＮＯとなった場合）である。この場合、業務ＩＤ１００１へはステップＳ４０２で取得した業務ＩＤ９０１の値、案件ＩＤ１００２へはステップＳ４０２で取得した案件ＩＤ９０２、ユーザＩＤ１００３へはステップＳ４０２で取得したユーザＩＤ９０３の値、配信スタートタイミング１００４へはステップＳ５０３またはステップＳ５０４で取得した値、配信間隔１００５へはステップＳ６０３またはステップＳ６０４で取得した値、配信回数１００６へは現在保持する配信回数の値、すなわち「０」を設定し登録する。

更新処理となる場合は、催促（メール）が配信された場合である。この場合、業務ＩＤ１００１、案件ＩＤ１００２、ユーザＩＤ１００３をキーとする、処理対象となっている案件に該当するレコードは既に登録されているため、業務ＩＤ１００１、案件ＩＤ１００２、ユーザＩＤ１００３をキーとして、配信回数１００６、メール配信日時１００７を更新する。配信回数１００６へは、ステップＳ３４０１がＹＥＳでステップＳ３４０２の処理が行われた場合は、現在保持する配信回数から１マイナスした値で、ステップＳ３４０１がＮＯでステップＳ３４０２の処理が行われなかった場合は、現在保持する配信回数の値で更新する。メール配信日時１００７へはメールが配信された時刻の値で、更新する。

例えば、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）において図３４の処理において、ステップＳ３４０１がＹＥＳでステップＳ３４０２の処理が行われた場合、初回の登録の場合、業務ＩＤ１００１へはＧ００２、案件ＩＤ１００２へはＡ００４、ユーザＩＤ１００３へはＵＳＥＲ００１、配信スタートタイミングへ１００４へは、例えば、１７時間、配信間隔１００５へは、例えば、６時間、配信回数へは０回、を値として設定し登録することになる。また登録後、１回目の催促（メール）が配信された後は、配信回数１００６へは１、メール配信日時１００７へはメールの配信日時、を値として設定し該当のレコードを更新する（図１０の１０１０）ことになる。

なお、図３４の催促（メール）の配信の処理は、本人以外に催促を送る対象者を、案件の処理担当者が所属する組織の情報から決定することにより、催促を配信する処理であるが、本人以外に催促を送る対象者は、後述する第２の実施形態における催促の配信において宛先を決定する方法、すなわち、案件のプロセス定義（案件の処理フローの定義）の情報から決定する方法を用いることによって決定しても良いこととする。

次に、図３４において催促の配信処理が行われた際の、催促のイメージについて説明をする。

まず、図３４のステップＳ７０４における、処理中の案件の催促メール配信回数に応じて、宛先のロールのルールとメッセージを取得する処理について説明をする。図９の９０８のレコードの業務ＩＤ９０１＝Ｇ００２をもとに、図３５の宛先管理テーブル３５００を参照して、業務ＩＤ３５０１が同じレコードの中より、回数３５０２に、ステップＳ３４０１までに取得された配信回数の値に、さらに「１」を加算した値と同じ値の回数が保持されたレコードを取得する。

例えば、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）の場合に、図７の処理において、初めて、ステップＳ７０２、ステップＳ３４０１でＹＥＳ、の処理を通った場合に、ステップＳ３４０２で配信回数に「１」が加算され、さらに、ステップＳ７０４において、その配信回数にさらに「１」を加算するため、配信回数は「２」となる。

すなわち、初回の催促の配信において、宛先管理テーブル３５００においては、業務ＩＤ３５０１がＧ００２で、回数３５０２は「２」の値のレコードを取得する（図３５の３５１０）。

次に、そのレコードの宛先ロールのルール３５０３、本人用メッセージ３５０４、本人以外用メッセージ３５０５を取得する。取得されたレコード（図３５の３５１０）の場合、宛先ロールのルール３５０３は、「１つ上の上位役割」、本人用メッセージ３５０４は、「［Ａ］回目催促：処理してください。」、本人以外用メッセージ３５０５は、「［ユーザ名］さんが［Ａ度目の警告を無視して］、［案件名］の処理をしていません。処理がされるように連絡してください。」、の値を取得する。

なお、本人用メッセージ３５０４の［Ａ］へは、現在保持する配信回数の値から１マイナスした値を代入する。なお、本人以外用メッセージ３５０５の［Ａ度目の警告を無視して］は、初回である場合は、本人の警告は未だ送られていないため、この文言は不要になるため、図３４、ステップＳ３４０２の処理が行われた場合は削除してよいこととする。なお、図３４、ステップＳ３４０２の処理が行われなかった場合（初回、２回目もされない場合）は、初回の催促となる、３５０９の初回の本人用メッセージ３５０４の［Ａ］の部分に現在保持する配信回数の値を入れ、催促を作成する。また、２回目の催促となる、３５１０の本人以外用メッセージ３５０５の［Ａ度目の警告を無視して］のＡの部分へは、現在保持する配信回数の値を入れて、催促を作成する。

これらの取得した情報をもとに送られる、初回に配信される催促のイメージ図は、図３６に示すとおりになる。

まず、処理担当者の宛先に送られる催促のイメージは、図３６の３６１０に図示するようになる。メールの宛先には図３４、ステップＳ７０６で取得したＵＳＥＲ００１のメールアドレスであるＵＳＥＲ００１＠ｃｏ．ｊｐが設定される（３６１１）。また、図３４、ステップＳ７０４で、本人用メッセージ３５０４として、「［Ａ］回目催促：処理してください。」を取得しているが、この［Ａ］へは最新の配信回数の値から１をマイナスした値を代入し、その文言がメール本文に記載する。例えば、最新の配信回数が「２」であるとしても、実際の催促が配信される回数は１回目のため「１」を代入した催促の本文を記載する（３６１２）。

次に、処理担当者以外の宛先に送られる催促のイメージは、図３６の３６２０に図示するようになる。

図３４のステップＳ７０４で、本人以外用メッセージ３５０５として、「［ユーザ名］さんが［Ａ度目の警告を無視して］、［案件名］の処理をしていません。処理がされるように連絡してください。」を取得している。このため、［ユーザ名］の部分には、処理対象として説明を行っている図９、９０８のレコードのユーザＩＤ９０３の値＝ＵＳＥＲ００１の値を入れる。［Ａ度目の警告を無視して］の部分は、１回目の配信である場合は、過去に処理担当者へは催促が送られていないためこの文言は不要であるため、削除を行う。［案件名］の部分には、処理対象として説明を行っている図９、９０８のレコードの案件ＩＤ９０２の値＝Ａ００４を代入してメッセージを作成している（３６２２）。また、メールの宛先にはステップＳ７０６で取得した、処理対象として説明を行っている図９、９０８のレコードのユーザＩＤ９０３であるＵＳＥＲ００１、の１つ上の役割（ｋａｃｈｏ）を持つユーザ（ＵＳＥＲ０１０）に紐付くメールアドレスであるＵＳＥＲ０１０＠ｃｏ．ｊｐが設定される（３６２１）。

以上の処理により、案件の処理期限が差し迫っている場合、宛先管理テーブルにおいて、例えば、初回には案件の処理担当者にしか催促が送られない設定がされていたとしても（図３５、３５０９）、以上の方法により、初回から宛先管理テーブルにおいて、２回目以降に催促を送信する宛先の設定（図２５、３５１０）を取得することにより、処理担当者とそれ以外の宛先に対しても、催促を送ることが可能になる。この方法によって、案件の期限が差し迫っている場合には、より、強力な催促を行うことによって、処理の遅延を防ぐことが可能になる。なお、初回以降に催促を送る宛先は、案件を処理すべき処理担当者の宛先となっていて、２回目以降に、初回とは別の宛先に送るようにしている例を挙げて説明を行ってきたが、２回目以降の宛先は回数ごとに増やす、あるいは、回数ごとに宛先は増やさないが宛先がそれぞれの回で異なるようにしても良い。宛先管理テーブルへの、催促を送る回における宛先の設定は自由にできることとする。

さらに、図３４の案件の処理期限までの残り時間が、案件の平均処理時間をきった場合の、催促を送る宛先の取得の処理は、図３７の方法で行っても良いこととする。

図３７においては、第１の実施形態の図７の同様の処理となる処理が存在し、その処理については、図７と、同じステップの番号を付与することとする。また、第１の実施形態の図７の処理と同様の動作をするものについては、説明を省略し、異なる動作となる処理について説明を行う。また、図３７の処理は、第１の実施形態の図４のステップＳ４０９のメール配信処理であることとする。

図３７の、ステップＳ３７０１、ステップＳ３７０２はワークフローサーバ１０３のＣＰＵ２０１の処理とする。

図３７での処理は、案件の処理期限までの残り時間が案件の処理担当者の平均処理時間を切っている場合に（ステップＳ３７０１でＹＥＳの場合）、宛先管理テーブルから取得した、回数に応じた本来の催促を送るべき宛先と、追加宛先管理テーブルで設定されている、同じ回数に応じた催促を送るべき宛先を比較することによって行う。比較した結果、追加宛先管理テーブルから取得した宛先が、宛先管理テーブルから取得した宛先に含まれている場合（存在する場合）は、そのまま催促を送る宛先を宛先管理テーブルから取得した宛先で送るようにするが、追加宛先管理テーブルから取得した宛先が、宛先管理テーブルから取得した宛先に含まれていない場合は、追加宛先管理テーブルから取得した宛先を追加することにより催促を送信する、という方法である。

ステップＳ３７０１において、案件の処理期限までの残り時間が、ユーザの平均処理時間をきっているか否かを判断する。

例えば、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）の案件の処理期限を、図３３の案件期限管理テーブル３３００から、案件ＩＤ＝Ａ００４の値をもとに検索すると、案件ＩＤ３３０１が「Ａ００１」のレコードの案件の処理期限３３０２は、「２０１４／０５／２２ ２３：５９：５９」であるため（図３３、３３１０）、期限は、２０１４／０５／２２ ２３：５９：５９となる（処理期限取得手段）。

また、図９の９０８のレコード（案件）の処理担当者である「ＵＳＥＲ００１」の、業務ＩＤが「Ｇ００２」における案件の平均処理時間が、図１１の処理履歴テーブル１１００より１２時間であるとする。

ステップＳ３７０１が行われた時刻（メール配信を行う直前の時刻）が、「２０１４／０５／２２ １５：３１：００」だとすると、その時刻から、「２０１４／０５／２２ ２３：５９：５９」までの時間は、８時間２８分５９秒となる。この時間を、平均処理時間である１２時間と比較すると、既に、案件の処理期限までの残り時間が、ユーザの平均処理時間をきっていることになる。この場合、ステップＳ３７０２へ処理を進める。一方、案件の処理期限までの残り時間が、ユーザの平均処理時間をきっていない場合は、ステップＳ７０４へ処理を進める。

ステップＳ３７０２において、現在保持する配信回数に１プラスした配信回数対応する、案件を処理すべき処理担当者以外の宛先、が宛先管理テーブルと、追加宛先管理テーブルから取得する。

まず、宛先管理テーブル１５００より、宛先を取得する方法を説明する。例えば、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）の場合、現在、メール配信管理テーブル１０００の配信回数が０である場合、その値に１プラスした値である「１」を配信回数の値として、業務ＩＤ１５０１がＧ００２で、回数１５０２は１の値のレコードを取得する（図１５の１５０９）。

このとき宛先は、宛先ロールのルール１５０３より、「１つ上の上位役割」が取得できる。

また、そのレコードの、本人用メッセージ１５０４は、「初回催促：処理してください。」、本人以外用メッセージ１５０５は「［ユーザ名］さんが［案件名］の処理をしていません。処理がされるように連絡してください。」、の値を取得する。

次に、追加宛先管理テーブル３８００より、宛先を取得する方法を説明する。例えば、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）の場合、現在、メール配信管理テーブル１０００の配信回数が０である場合、その値に１プラスした値である「１」を配信回数の値として、業務ＩＤ３８０１がＧ００２で、回数３８０２は１の値のレコードを取得する（図３８の３８０９）。

このとき、宛先ロールのルール３８０３より、「１つ上の上位役割」が取得できる。

また、そのレコードの、本人以外用メッセージ３８０４は「［ユーザ名］さんが［案件名］の処理をしていません。処理がされるように連絡してください。」、の値を取得する。

図９、９０８の案件の場合は、宛先ロールのルール３８０３より、「１つ上の上位役割」が取得できていて、本人以外の宛先として、本人からみて１つ上の上位役割を組織上保持する人（宛先）へ催促が送るためのルールが取得できていて、このルール自体は、宛先管理テーブルの宛先ロールのルール１５０３においても、「１つ上の上位役割」が取得できているため、そのまま宛先管理テーブルで取得した宛先ロールのルールに従って、宛先を取得し、その宛先に催促を送るようにする。また、催促のメッセージの本文についても、宛先管理テーブル１５００から取得した本人用メッセージ１５０４を使用することによって催促を送るようにする。

これにより、宛先管理テーブルより取得した催促の宛先に、追加宛先管理テーブルで取得した催促の宛先が含まれている場合は、宛先管理テーブルから取得した宛先へ、宛先管理テーブルから取得した催促のメッセージのテンプレートを使用することにより、催促を送ることとする。

すなわち、催促を送る時から案件の処理期限までの時間が、第１の宛先に関する処理済みの案件の平均処理時間よりも短い場合、かつ、現在保持する配信回数に対応する、催促が本来送られるべき宛先の中に、所定の送信先が含まれている場合、回数に対応して本来送られる宛先に催促を送信する。

しかし、例えば、図９の９０６のレコード（業務ＩＤ９０１＝Ｇ００１、案件ＩＤ９０２＝Ａ００１、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２１ １０：１０：１０）において、ステップＳ３７０１において処理期限までの残り時間が平均処理時間をきったケースがあったとした場合、ステップＳ３７０２においては、次のように催促を送る宛先を取得する。

まず、宛先管理テーブル１５００より、宛先を取得する方法を説明する。現在、メール配信管理テーブル１０００の配信回数が０である場合、その値に１プラスした値である「１」を配信回数の値として、業務ＩＤ１５０１がＧ００１で、回数１５０２は１の値のレコードを取得する（図１５の１５０６）。

このレコードにおいては、宛先ロールのルール１５０３は値が存在しないため、宛先ロールのルールの値が取得できない。なお、本人用メッセージ１５０４として、「初回催促：処理してください。」の値を取得する。

同じく、追加宛先管理テーブル３８００より、宛先を取得する方法を説明する。例えば、図９の９０６のレコード（業務ＩＤ９０１＝Ｇ００１、案件ＩＤ９０２＝Ａ００１、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２１ １０：１０：１０）の場合、現在、メール配信管理テーブル１０００の配信回数が０であるとすると、その値に１プラスした値である「１」を配信回数の値として、業務ＩＤ３８０１がＧ００１で、回数３８０２は１の値のレコードを取得する（図３８の３８０６）。

このとき、宛先ロールのルール３８０３より、「１つ上の上位役割」が取得できる。

また、そのレコードの、本人以外用メッセージ３８０４は「［ユーザ名］さんが［案件名］の処理をしていません。処理がされるように連絡してください。」、の値を取得する。

この方法により、案件を処理すべき処理担当者の宛先以外の宛先として、本人からみて「１つ上の上位役割」を組織上保持する人を特定することによって、案件を処理すべき処理担当者の宛先とは別の宛先に催促を送ることが可能となる。また、案件を処理すべき処理担当者の宛先とは別の宛先には、同時に取得した本人以外用メッセージの催促の文面を使って催促を送っても良いこととする。

このように、宛先管理テーブル１５００からは、本人以外の宛先を取得するための、宛先ロールのルール１５０３の値が取得できなかったが、追加宛先管理テーブル３８００からは、宛先ロールのルール３８０３より、本人以外の宛先である「１つ上の上位役割」を取得できた。そのため、このような場合は、催促の宛先に、案件を処理すべき本人の宛先以外にも、追加宛先管理テーブル３８００から取得した宛先ロールのルールで取得する処理担当者を、催促を送る宛先として追加することとする。また、本人以外用メッセージ３８０４の催促のメッセージのテンプレートを利用して催促を送ることも可能であるとする。

これにより、宛先管理テーブルより取得した催促の宛先に、追加宛先管理テーブルで取得した催促の宛先が含まれていない場合は、追加宛先管理テーブルで取得した催促の宛先を、催促の宛先に追加することによって、催促を送ることとする。また、追加宛先管理テーブルから取得した催促のメッセージのテンプレートを使用して催促を送ることも可能とする。

すなわち、催促を送る時から前記案件の処理期限までの時間が、第１の宛先に関する処理済みの案件の平均処理時間よりも短い場合、催促を所定の送信先に送信可能とする。また、催促を送る時から案件の処理期限までの時間が、第１の宛先に関する処理済みの案件の平均処理時間よりも短い場合、かつ、現在保持する配信回数に対応する、催促が本来送られるべき宛先の中に、所定の送信先が含まれていない場合、催促を所定の送信先に送信可能とする。

なお、図３７の処理で作成される催促のイメージは、図７の処理において既に説明を行っているため説明は省略する。また、図１０のメール配信管理テーブル１０００へのデータの登録についても、図７の処理と同様であるため説明は省略する。

次に、本発明における第１の実施形態における第２のメール配信方法の実施形態について説明をする。第１の実施形態の図７の催促の配信処理では、ワークフローサーバ１０３は催促メールを処理担当者と、処理担当者以外のユーザのそれぞれに対して別メールを作成しているが、１つのメールを作成する第２のメール配信方法の実施形態について図１８を用いて説明を行う。すなわち、宛先決定手段によって決定される処理担当者と処理担当者ではないユーザの宛先に配信される催促メールは、１つのメールでまとめて配信可能であることとする。

なお、図１８は、第１の実施形態の処理フローの図７を第２のメール配信方法の実施形態としたものであって、第１の実施形態の図７を呼ぶ図４、また、図７の前処理である図５、図６については、第２の実施形態においても同様とするため説明は省略することとする。また、図１８のステップＳ１８０１からステップＳ１８０６は、図７のステップＳ７０１からステップＳ７０６と同様であるため、また、ステップＳ７１０はステップＳ１８０８と同様であるため、説明は省略する。

なお、図１８においては、ステップＳ１８０９はメールサーバ１０４のＣＰＵ２０１、ステップＳ１８１０、１８１１は、クライアント端末１０１のＣＰＵ２０１、ステップＳ１８１２、１８１３は、クライアント端末１０２のＣＰＵ２０１の処理であることとし、それ以外の処理はワークフローサーバ１０３のＣＰＵ２０１の処理とする。

ステップＳ１８０７では、ステップＳ１８０４で取得した、本人用メッセージ１５０４、本人以外用メッセージ１５０５と、ステップＳ１８０６で取得した、図９のレコード（９０８）の処理担当者であるＵＳＥＲ００１とＵＳＥＲ００１以外に配信するユーザのメールアドレスの情報を利用して、１つのメールで催促メールの配信が完了するようにメールサーバ１０４に対しメールの配信の依頼を行う。

なお、ステップＳ１８０７の処理が終了した後は、ステップＳ１８０９へ処理を進めるが、同時にステップＳ１８０８へ処理も進める。ステップＳ１８０８へは、処理担当者に対して催促メールの配信を行った結果をメール配信管理テーブル１０００に更新しておくため、処理を進める。

ステップＳ１８０９において、メールサーバ１０４は、ステップＳ１８０７においてワークフローサーバ１０３によって配信依頼を受けたメールの情報をもとに、クライアント端末１０１とクライアント端末１０２に対し、メールを配信する。なお、処理担当者以外のユーザが宛先ロールのルール１５０３で取得できていない場合は、クライアント端末１０２へはメールは配信されることはない。

ステップＳ１８１０、ステップＳ１８１２において、クライアント端末１０１とクライアント端末１０２は、ステップＳ１８０９でメールサーバ１０４より配信されたメールを受信する。

ステップＳ１８１１、ステップＳ１８１３において、クライアント端末１０１あるいはクライアント端末１０２は、ステップＳ１８１０、ステップＳ１８１２において、クライアント端末１０１とクライアント端末１０２が受信したメールを表示画面において、表示する。なお、メールのイメージとしては、図１９の１９００に図示するようになる。メールのＴＯの宛先にはステップＳ１８０６で取得したＵＳＥＲ００１のメールアドレスであるＵＳＥＲ００１＠ｃｏ．ｊｐが設定される（１９０１）。また、ステップＳ１８０４で、本人用メッセージ１５０４として、「２回目催促：処理して下さい。」を取得しているため、その文言がメール本文に記載される（１９０２）。

また、メールのＣＣの宛先にはステップＳ１８０６で取得したＵＳＥＲ０１０とＵＳＥＲ０２０のメールアドレスであるＵＳＥＲ０１０＠ｃｏ．ｊｐ、ＵＳＥＲ０２０＠ｃｏ．ｊｐが設定される（１９０４）。すなわち、宛先決定手段によって決定される処理担当者と処理担当者ではないユーザの宛先を１つのメールにおけるメールアドレスの設定先を異なるようにしている。また、ステップＳ１８０４で、本人用メッセージ１５０４として、「［ユーザ名］さんが１度目の催促を無視して［案件名］の処理をしていません。処理がされるように連絡してください。」を取得しているため、［ユーザ名］の部分には、処理対象として説明を行っている図９、９０８のレコードのユーザＩＤ９０３の値＝ＵＳＥＲ００１の値を入れ、［案件名］の部分には、処理対象として説明を行っている図９、９０８のレコードの案件ＩＤ９０２の値＝Ａ００４を代入してメッセージを作成している（１９０３）。

すなわち、催促を第１の宛先と第２の宛先に送信する場合、第１の宛先と第２の宛先である複数の宛先を、１つの単位である催促の宛先へ設定することにより、１つの単位である催促を複数の宛先に配信可能であることとする。

なお、１９０２と１９０３に図示しているようにメッセージをマージしているが、１９０１の処理担当者のみのメッセージである１９０２のみしても良いし、一度で一斉に配信するようの本文を別途用意しても良いこととする。

以上により、ワークフローシステムにおける未処理案件の処理担当者の宛先に対する催促の配信回数に応じて、催促を配信する宛先を異なるようにするため、処理担当者の処理状況を処理担当者以外が把握することが可能となる。これにより、催促が処理担当者以外にも通知されるため、処理担当者以外のユーザから処理担当者へ処理の依頼を指示することも可能となるため、処理の遅延をさらに防ぐ効果が見込まれる。また、平均処理時間に応じて催促を通知する時期と、催促の間隔も決定していることから、処理の遅延している箇所に対して集中的に催促を行うことが可能になる。これにより、一部の処理のみにおいて遅延が発生しないようにすることが可能となる。

なお、本実施例においては、メールによって処理担当者に対し未処理の案件の催促を行う例を説明したが、メールに限らず、メール以外のメッセージの通知処理によって処理担当者へ処理の催促を行っても良いこととする。
＜第２の実施形態＞

続いて、本発明における第２の実施形態について説明を行う。第１の実施形態では、催促を送る回数に応じて、催促を送る対象者を決定しているが、本人以外に催促を送る対象者は、案件の処理担当者が所属する組織の情報から決定している。この変形例として、第２の実施形態においては、催促を送る回数に応じて、催促を送る対象者を決定する方法において、本人以外に催促を送る対象者を、案件のプロセス定義（案件の処理フローの定義）の情報から決定する実施形態について説明をする。

なお、図４におけるステップＳ４０９以外の催促メール配信処理のメインの処理、図５の初回メール配信タイミング取得処理、図６の催促メール配信間隔取得処理については、第２の実施形態でも同様の処理として行われることとする。このため、第１の実施形態と同様で有るため、説明については、省略することとする。

また、ステップＳ４０９のメール配信処理については、第２の実施形態については、図２１をもとに説明をする。なお、図２１において、第１の実施形態の図７の処理と同様の動作をするものについては、説明を省略し、異なる動作となる処理について説明を行う。また、図２１において、第１の実施形態の図７の同様の処理となる処理については、同じステップの番号を付与することとする。

図２１の、ステップＳ２１０１、ステップＳ２１０２はワークフローサーバ１０３のＣＰＵ２０１の処理とする。

図２１のステップＳ２１０１では、処理中の案件の催促メール配信回数に応じて、宛先ルールとメッセージ（催促の内容）の取得を行う。図９の９０８のレコードの業務ＩＤ９０１＝Ｇ００２をもとに、宛先管理テーブル２４００を参照して、業務ＩＤ２４０１の値が同じレコードの中より、回数２４０２に、ステップＳ４０７またはステップＳ４０８で取得した配信回数に１加算した値と同じ値の回数が保持されたレコードを取得する。例えば、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）の場合、メール配信管理テーブル１０００の配信回数を１とすると、業務ＩＤ２４０１がＧ００２で、回数２４０２は２の値のレコードを取得する（図２４の２４１０）。次に、そのレコードの宛先ロールのルール２４０３、本人用メッセージ２４０４、本人以外用メッセージ２４０５を取得する。取得されたレコード（図２４の２４１０）の場合、宛先のルール２４０３は、「業務課 課長、業務部 部長」、本人用メッセージ２４０４は、「２回目催促：処理してください」、本人以外用メッセージ２４０５は「［ユーザ名］さんが１度目の催促を無視して［案件名］の処理をしていません。処理がされるように連絡してください。」、の値を取得する。

その後、ステップＳ２１０２に処理を進める。ステップＳ２１０２では、ステップＳ２１０１で取得した宛先のルール２４０３に該当するユーザが、ワークフローシステムにおける組織上のどのユーザに当たるのか解決し、ステップＳ２１０１で取得した本人以外用メッセージ２４０５を送る人を特定する。

まず、宛先のルール２４０３で記載されている宛先のルールより、ワークフロープロセス２２００に図示する、案件に紐づくプロセス定義を参照する。なお、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）の案件を起案するために、業務に紐づくプロセスは、図２２のプロセス定義が設定されているものとして説明をする。

例えば、取得されたレコード（図２４の２４１０）の場合、宛先のルール２４０３は、「業務課 課長、業務部 部長」となっている。この場合、まず図２２のワークフロープロセス２２００で図示するプロセス定義より、「業務課 課長」の処理担当者の指定がされているアクティビティを探しにいくこととする。このとき、図２２の２２０３のアクティビティが「業務課 課長」で処理担当者の指定がされているため、この処理担当者指定で決定する実際の処理担当者が１つ目の宛先となる。

次に、図２２のワークフロープロセス２２００で図示するプロセス定義より、「業務部 部長」で処理担当者の指定がされているアクティビティを探しにいくこととする。このとき、図２２の２２０４のアクティビティが「業務部 部長」で処理担当者の指定がされているため、この処理担当者指定で決定する実際の処理担当者が２つ目の宛先となる。

次に、それらの処理担当者指定で決定される宛先となるユーザを、本実施例においては、ワークフローの処理担当者が所属する図２３の組織から特定することとする。

まず、図２２、２２０３で処理担当者指定がされている「業務課 課長」は、「業務課」の組織に所属する、「課長」の役割を持つものという意味であるため、図２３においては、業務課（２３０３）＝Ｋ００１の、課長ロール（課長の役割）が割り当てられている、山田（２３０７）＝ＵＳＥＲ０１０が１つめの宛先となる。

次に、図２２、２２０４で処理担当者指定がされている「業務部 部長」は、「業務部」の組織に所属する、「部長」の役割を持つものという意味であるため、図２３においては、業務部（２３０２）＝Ｂ００１の、部長ロール（部長の役割）が割り当てられている、井上（２３０８）＝ＵＳＥＲ０２０が２つめの宛先となる。

なお、これらの宛先として決定したユーザへ、送付される催促のイメージは、２回目の催促の時は、第１の実施形態の図１７、図１９のイメージ図と同様になり、１回目の催促の時は、第１の実施形態の図２０のイメージ図と同様になる。なおこの催促の作成については第１の実施形態と同様であるため、この部分についての詳細な説明は省略する。

なお、第２の実施形態において、図１９のイメージ図で催促を配信する処理は、図３１で示す処理であるものとする。図３１において、第１の実施形態の図１８の同様の処理となるステップの処理については、図１８に記載のステップ番号と同じステップの番号を付与している。また、第２の実施形態の図２１と同様の処理となるステップの処理については、図２１に記載のステップ番号と同じステップの番号を付与している。このため、図３１の処理は、図１８と図２１の既に説明を行っている処理から成り立っているため、詳細な説明は省略する。

なお、図２４、宛先管理テーブル２４００の、２４１１のレコードをもとに宛先を決定した場合は次の通りになる。

例えば、取得されたレコード（図２４の２４１１）の場合、宛先のルール２４０３は、「業務部 部長、総務部 総務担当、経理部 経理担当」となっている。この場合、まず図２２のワークフロープロセス２２００で図示するプロセス定義より、「業務部 部長」の処理担当者の指定がされているアクティビティを探しにいくこととする。このとき、図２２の２２０４のアクティビティが「業務部 部長」で処理担当者の指定がされているため、この処理担当者指定で決定する実際の処理担当者が１つ目の宛先となる。

次に、図２２のワークフロープロセス２２００で図示するプロセス定義より、「総務部 総務担当」で処理担当者の指定がされているアクティビティを探しにいくこととする。このとき、図２２の２２０５のアクティビティが「総務部 総務担当」で処理担当者の指定がされているため、この処理担当者指定で決定する実際の処理担当者が２つ目の宛先となる。

さらに、図２２のワークフロープロセス２２００で図示するプロセス定義より、「経理部 経理担当」で処理担当者の指定がされているアクティビティを探しにいくこととする。このとき、図２２の２２０６のアクティビティが「経理部 経理担当」で処理担当者の指定がされているため、この処理担当者指定で決定する実際の処理担当者が３つ目の宛先となる。

次に、それらの処理担当者指定で決定される宛先となるユーザを、本実施例においては、ワークフローの処理担当者が所属する図２３の組織から特定することとする。

まず、図２２、２２０４で処理担当者指定がされている「業務部 部長」は、「業務部」の組織に所属する、「部長」の役割を持つものという意味であるため、図２３においては、業務部（２３０２）＝Ｂ００１の、部長ロール（部長の役割）が割り当てられている、井上（２３０８）＝ＵＳＥＲ０２０が１つめの宛先となる。

次に、図２２、２２０５で処理担当者指定がされている「総務部 総務担当」は、「総務部」の組織に所属する、「総務担当」の役割を持つものという意味であるため、図２３においては、総務部（２３０５）＝Ｃ００１の、総務担当ロール（総務担当の役割）が割り当てられている、林（２３１０）＝ＵＳＥＲ０３０が２つめの宛先となる。

さらに、図２２、２２０６で処理担当者指定がされている「経理部 経理担当」は、「経理部」の組織に所属する、「経理担当」の役割を持つものという意味であるため、図２３においては、経理部（２３０６）＝Ｄ００１の、経理担当ロール（経理担当の役割）が割り当てられている大田（２３１１）＝ＵＳＥＲ０４０が３つめの宛先となる。

なお、これらの宛先として決定したユーザへ送付される催促の作成についても、これまでの説明と同様であるため、この部分についての詳細な説明は省略する。また、その作成された結果のイメージ図についても説明は省略する。

以上の方法により、本人以外に催促を送る対象者を、案件のプロセス定義（案件の処理フローの定義）の情報、すなわちワークフローの業務に紐づくプロセス定義で指定されている処理担当者の指定の情報より、催促を送る回数に応じた催促を送る対象者を決定することが可能になる。

なお、プロセス定義で指定されている処理担当者の指定の情報ではなく、プロセス定義における、アクティビティの順番の情報を使用しても良いこととする。例えば、図２５の宛先管理テーブル２５００の宛先のルール２５０３においては、プロセス定義における処理担当者の指定情報ではなく、プロセス定義におけるアクティビティの位置を指定している。そして、この指定されたアクティビティにおいて設定されている処理担当者で特定されるユーザに対し催促を送ることになる。なお、この場合、処理待ちのユーザからのアクティビティの位置となるため、相対的なアクティビティの位置で特定される処理担当者に対し、処理待ちのユーザ以外の催促が送られることになる。なお、アクティビティの位置がプロセス定義のアクティビティの範囲を超えるような場合は、その宛先を決定することは不可能となるため、今回は、宛先に対し催促は送らないようにする。なお、決定できなかった宛先を別の方法で決定しても良いこととする。

この例における宛先の決定について、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）の案件を用い説明をする。なお、当該案件を起案するための業務に紐づくプロセスは、図２２のプロセス定義とする。

例えば、図９の９０８のレコードの案件が図２２の２２０２のユーザの処理待ち案件とした場合に、図２５の２５１０のレコードを使用して、本人以外の宛先を宛先のルール２５０３に従って取得することになった場合、宛先のルール２５０３に記載の通り、「１つ後のアクティビティ、２つ後のアクティビティ」となっている。

案件が、図２２のプロセス定義において処理されている場合、そのプロセスにおいて、業務担当から見て１つ後のアクティビティは図２２、２２０３の「業務課 課長」、２つ後のアクティビティは図２２、２２０４「業務部 部長」、となる。

次に、それらの処理担当者指定で決定される宛先となるユーザを、本実施例においては、ワークフローの処理担当者が所属する図２３の組織から特定することとする。

まず、図２２、２２０３で処理担当者指定がされている「業務課 課長」は、「業務課」の組織に所属する、「課長」の役割を持つものという意味であるため、図２３においては、業務課（２３０５）＝Ｋ００１の、課長ロール（課長の役割）が割り当てられている、山田（２３０７）＝ＵＳＥＲ０１０が１つめの宛先となる。

次に、図２２、２２０４で処理担当者指定がされている「業務部 部長」は、「業務部」の組織に所属する、「部長」の役割を持つものという意味であるため、図２３においては、業務部（２３０２）＝Ｂ００１の、部長ロール（部長の役割）が割り当てられている、井上（２３０８）＝ＵＳＥＲ０２０が２つめの宛先となる。

以上の方法により、本人以外に催促を送る対象者を、案件のプロセス定義（案件の処理フローの定義）の情報、すなわちワークフローの業務に紐づくプロセス定義で指定されている処理担当者の指定の情報より、催促を送る回数に応じた催促を送る対象者を決定することが可能になる。これにより、案件ごとにプロセスに紐づいた宛先に催促をさせることが出来る。
＜第３の実施形態＞

続いて、本発明における第３の実施形態について説明を行う。第１の実施形態では、催促を送る回数に応じて、催促を送る対象者を決定しているが、本人以外に催促を送る対象者は、案件の処理担当者が所属する組織の情報から決定している。この変形例として、第２の実施形態においては、催促を送る回数に応じて、催促を送る対象者を決定する方法において、本人以外に催促を送る対象者を、案件のプロセス定義（案件の処理フローの定義）の情報から決定している。

さらにこの変形例として、第３の実施形態においては、催促を送る対象者を、催促を送る回数に応じて決定するのではなく、案件の滞留時間に応じて決定する実施形態について図２６を用いて説明をする。

図２６は、催促メール配信処理のメインの処理である。なお、図２６の処理はワークフローサーバ１０３のＣＰＵ２０１の処理であることとする。

ステップＳ２６０１では、案件管理テーブル９００を参照し、案件の件数を取得する。

ステップＳ２６０２では、案件管理テーブル９００を参照し、催促配信対象となる案件の中から１件分の案件情報である、業務ＩＤ９０１、案件ＩＤ９０２、ユーザＩＤ９０３、部門ＩＤ９０４、処理依頼日時９０５の各項目を取得する。

例えば、１件分の案件情報の一例として、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）を取得するとする。取得した後は、ステップＳ２６０３へ処理を進める。

なお、ステップＳ２６０２とステップＳ２６０３については、ステップＳ２６０１で取得した案件件数分、繰り返し処理が行われることとする。

また、ステップＳ２６０３のメール配信処理については、第３の実施形態については、図２７をもとに説明をする。なお、図２７において、第１の実施形態の図７の処理と同様の動作をするものについては、説明を省略し、異なる動作となる処理について説明を行う。また、図２７において、第１の実施形態の図７の同様の処理となる処理については、同じステップの番号を付与することとする。

続いて、図２７において、処理中の案件の滞留時間に応じて、宛先とメッセージの設定を行い、催促を配信する処理について説明する。

本処理については、宛先ロールのルールと、本人用メッセージ、本人以外用のメッセージを取得する、ステップＳ２７０１から始まることとする。

なお、第１の実施形態と異なるのは、ステップＳ２７０１の宛先ロールのルールと本人用メッセージを取得する箇所の処理が、案件の滞留時間に応じて異なるようにしている箇所であるため、それ以外の、後続の処理は、ステップＳ７１０の処理が必要なくなる以外は、同様であるものとする。

図２７のステップＳ２７０１の処理はワークフローサーバ１０３のＣＰＵ２０１の処理であることとする。

ステップＳ２７０１において、案件が、処理担当者の処理待ち状態になってからの経過時間に応じて、宛先のロールのルールとメッセージの取得を行う。

例えば、図９の９０８のレコードの業務ＩＤ９０１＝Ｇ００２をもとに、宛先管理テーブル２８００を参照して、業務ＩＤ２８０１の値が同じレコードの中より、処理依頼日時９０５と現在日時までの時間が、経過時間２８０２の経過時間の条件に合致するレコードを取得する。

例えば、図９の９０８のレコード（業務ＩＤ９０１＝Ｇ００２、案件ＩＤ９０２＝Ａ００４、ユーザＩＤ９０３＝ＵＳＥＲ００１、部門ＩＤ９０４＝Ｋ００１、処理依頼日時９０５＝２０１４／０５／２２ １５：３０：０５）の場合、現在この処理が行われている時刻が、２０１４／０５／２３ １３：３０：０５とすると、この間の経過時間は２２時間であるため、業務ＩＤ２８０１がＧ００２で、経過時間２８０２の値が「１７＜経過時間≦２３」（１７時間よりも後から２３時間までの間の経過時間）のレコードを取得する（図２８の２８１０）。

次に、そのレコード宛先ロールのルール２８０３、本人用メッセージ２８０４、本人以外用メッセージ２８０５を取得する。取得されたレコード（図２８の２８１０）の場合、宛先ロールのルール２８０３は、「１つ上の上位役割、２つ上の上位役割」、本人用メッセージ２８０４は、「催促レベル２：処理してください」、本人以外用メッセージ２８０５は「催促レベル２：［ユーザ名］さんが［Ａ］時間［Ｂ］分、［案件名］の処理をしていません。処理がされるように連絡してください。」、の値を取得する。その後、図２７のステップＳ７０５に処理を進める。

すなわち、処理担当者に対して催促を送信する時、案件が処理担当者の処理待ち状態になってから経過した時間に応じて、催促を配信する宛先を決定する（宛先決定手段）。また、宛先決定手段で決定する宛先は、処理待ち状態の案件を処理する予定を現在保持する処理担当者である第１の宛先と、第１の宛先以外の案件の処理担当者である第２の宛先であることとする。

なお、図２７、ステップＳ７０５以降の、本人以外の宛先となるユーザの取得、本人と本人以外の宛先となるユーザのメールアドレス（宛先）の取得、催促の送信処理については、第１の実施形態の図７の同一ステップ名の処理と同様とするため、説明は省略するが、ステップＳ２７０１で取得した、本人用メッセージ２８０４と本人以外用メッセージ２８０５の催促の内容から作成される催促の例については、他の実施形態とは異なるため、図２９、図３０を用いて説明を行う。

処理を滞留している本人へ催促されるメールのイメージとしては、図２９の２９１０に図示するようになる。メールの宛先には、図２７のステップＳ７０６で取得した（実際に取得する値は、第１の実施形態で説明した値とする）ＵＳＥＲ００１のメールアドレスであるＵＳＥＲ００１＠ｃｏ．ｊｐが設定される（２９１１）。また、本人用メッセージ２８０４として、「催促レベル２：処理してください。」を取得しているため、その文言がメール本文に記載される（２９１２）。

処理を滞留している本人以外の宛先に催促されるメールのイメージとしては、図２９の２９２０、２９３０に図示するようになる。本人以外用メッセージ２８０５から取得した、「催促レベル２：［ユーザ名］さんが［Ａ］時間［Ｂ］分、［案件名］の処理をしていません。処理がされるように連絡してください。」のは、［ユーザ名］の部分には、処理対象として説明を行っている図９、９０８のレコードのユーザＩＤ９０３の値＝ＵＳＥＲ００１の値を入れる。

［Ａ］の部分には、処理担当者へ案件が処理待ちになった時点から、対象案件への催促の配信処理が行われた時点までの経過時間を計算し、その値を入れる。例えば、図９、９０８のレコードでは、処理依頼日時９０５が「２０１４／０５／２２ １５：３０：０５」であり、現在この処理が行われている時刻が、「２０１４／０５／２３ １３：３０：０５」である場合、案件が処理待ちになった時点から、対象案件への催促の配信処理が行われた時点までの経過時間は、２２時間であるため、［Ａ］の部分は「２２」の値が入る。なお、［Ｂ］の部分は、「０」の値が入る。なお、［Ｂ］の値が０の場合、図２９の２９２２に図示するように、［Ａ］の値までの経過時間の表示でもよいこととする。

［案件名］の部分には、処理対象として説明を行っている図９、９０８のレコードの案件ＩＤ９０２の値＝Ａ００４を代入してメッセージを作成している（２９２２、２９３２）。また、メールの宛先には図２７のステップＳ７０６で取得した（実際に取得する値は、第１の実施形態で説明した値とする）、処理対象として説明を行っている図９、９０８のレコードのユーザＩＤ９０３であるＵＳＥＲ００１、の１つ上の役割（ｋａｃｈｏ）を持つユーザ（ＵＳＥＲ０１０）に紐付くメールアドレスであるＵＳＥＲ０１０＠ｃｏ．ｊｐと、の２つ上の役割（ｂｕｃｈｏ）を持つユーザ（ＵＳＥＲ０２０）に紐付くメールアドレスであるＵＳＥＲ０２０＠ｃｏ．ｊｐと、が設定される（２９２１、２９３１）。

なお、第３の実施形態において、図３０のイメージ図のように、１つの催促で複数の宛先に催促を配信する処理は、図３２で示す処理であるものとする。図３２において、第１の実施形態の図１８の同様の処理となるステップの処理については、図１８に記載のステップ番号と同じステップの番号を付与している。なお、ステップＳ１８０８については、図３２には処理が存在しないものとする。また、第２の実施形態の図２７と同様の処理となるステップの処理については、図２７に記載のステップ番号と同じステップの番号を付与している。このため、図３２の処理は、図１８と図２７の既に説明を行っている処理から成り立っているため、詳細な説明は省略する。

これまで、図９、９０８の１件のみを対象として説明を行ったが、例えば、図９の他の案件に対して同時の催促処理が行われた場合、すなわち、「２０１４／０５／２３ １３：３０：０５」行われると、図９、９０６については、処理依頼日時９０５が、「２０１４／０５／２１ １０：１０：１０」であり、この間は、５１時間１９分５５秒であるため、図２８の宛先管理テーブル２８００より、業務ＩＤ２８０１がＧ００１で、経過時間２８０２の値が「３６≦経過時間」（経過時間が３６時間以上）のレコードが取得できる（図２８の２８０８）。

したがって、図９、９０６の案件の場合は、宛先ロールのルール２８０３には、「１つ上の役割、２つ上の役割」の値が存在しているため、本人の宛先と、本人以外の本人から見て組織上「１つ上の役割、２つ上の役割」をもつ宛先のユーザへ、催促が、本人用メッセージ２８０４と本人以外用メッセージ２８０５のメッセージで、２通、送られることになる。

次に、図９、９０７については、処理依頼日時９０５が、「２０１４／０５／２２ １２：４０：２２」であり、同じく催促の処理が行われた時刻が「２０１４／０５／２３ １３：３０：０５」とすると、この間は、１２時間４９分４３秒であるため、図２８の宛先管理テーブル２８００より、業務ＩＤ２８０１がＧ００１で、経過時間２８０２の値が「０≦経過時間＜２４」（経過時間が０以上２４時間未満）のレコードが取得できる（図２８の２８０６）。

したがって、この案件の場合は、宛先ロールのルール２８０３には、値が存在しないため、本人のみの宛先に、催促が本人用メッセージ２８０４のメッセージで、１通、送られることになる。

図９、９０８は、これまでの既に説明の通り、２通、送られることになる。

なお、第３の実施形態においては、催促を送る宛先は、第１の実施形態に記載の方法、すなわち、処理担当者を基準に決定する方法で、決定するとして説明を行ったが、第２の実施形態に記載の方法、すなわち、案件に紐づくプロセス定義のアクティビティに設定される処理担当者の情報、あるいは、アクティビティの位置の情報、の指定によって宛先を決定する方法で、決定しても良いこととする。

以上の方法により、一度の催促の処理で、案件に対して催促が送られる宛先が、案件の処理の滞留時間に応じて変えることが可能になる。

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

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

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

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

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

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

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

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

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

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

１００ ネットワーク
１０１ クライアント端末
１０２ クライアント端末
１０３ ワークフローサーバ
１０４ メールサーバ
１０５ 管理端末
２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ ＲＯＭ
２０４ システムバス
２０５ 入力コントローラ
２０６ 出力コントローラ
２０７ 外部メモリコントローラ
２０８ 通信Ｉ／Ｆコントローラ
２０９ 入力部
２１０ 出力部
２１１ 外部メモリ
２１２ プログラム

Claims (6)

1. 案件が複数の処理担当者によって処理され、前記案件の処理の催促を促すことを可能とするワークフローシステムのワークフローサーバであって、
   未処理の案件に対して処理の催促を行った回数をカウントするカウント手段と、
   前記カウント手段でカウントした前記回数に応じて、前記催促を配信する宛先を決定する宛先決定手段と、
   前記宛先決定手段で決定される宛先に、前記催促を前記宛先に配信するための配信制御を行う配信制御手段と、
   前記未処理の案件を現在保持する処理担当者が案件の処理を滞留した時間を算出する算出手段と、
   を備え、
   前記宛先決定手段で決定する宛先は、前記未処理の案件を現在保持する処理担当者以外の、前記処理担当者よりも上位ロールの処理担当者であり、
   前記配信制御手段が、前記処理担当者の前記未処理の案件の処理の催促を前記処理担当者よりも上位ロールの処理担当者に配信する場合には、前記算出した未処理の案件を現在保持する処理担当者が案件の処理を滞留した時間を含めて配信することを特徴とするワークフローサーバ。
2. 前記処理担当者の、案件が処理待ち状態となってから処理がなされたまでの時間の平均処理時間を算出する平均処理時間算出手段を更に備え、
   前記配信制御手段は、前記平均処理時間算出手段で算出した平均処理時間に応じて、前記催促を前記宛先に最初に配信する時期を異なるようにすることを特徴とする請求項１に記載のワークフローサーバ。
3. 前記配信制御手段は、初回に配信する前記催促が前記宛先に配信されてから、前記処理担当者が処理を行うまで配信する前記催促を定期的に配信する配信間隔を、前記平均処理時間に応じて異なるように前記催促を配信することを特徴とする請求項２に記載のワークフローサーバ。
4. 前記催促はメールであり、前記宛先は前記メールを配信するためのメールアドレスであることを特徴とする請求項１乃至３のいずれか１項に記載のワークフローサーバ。
5. 案件が複数の処理担当者によって処理され、前記案件の処理の催促を促すことを可能とするワークフローシステムのワークフローサーバの制御方法であって、
   カウント手段が、未処理の案件に対して処理の催促を行った回数をカウントするカウントステップと、
   宛先決定手段が、前記カウントステップでカウントした前記回数に応じて、前記催促を配信する宛先を決定する宛先決定ステップと、
   配信制御手段が、前記宛先決定ステップで決定される宛先に、前記催促を前記宛先に配信するための配信制御を行う配信制御ステップと、
   算出手段が、前記未処理の案件を現在保持する処理担当者が案件の処理を滞留した時間を算出する算出ステップと、
   を含み、
   前記宛先決定ステップで決定する宛先は、前記未処理の案件を現在保持する処理担当者以外の、前記処理担当者よりも上位ロールの処理担当者であり、
   前記配信制御ステップで、前記処理担当者の前記未処理の案件の処理の催促を前記処理担当者よりも上位ロールの処理担当者に配信する場合には、前記算出した未処理の案件を現在保持する処理担当者が案件の処理を滞留した時間を含めて配信することを特徴とする制御方法。
6. 案件が複数の処理担当者によって処理され、前記案件の処理の催促を促すことを可能とするワークフローシステムのワークフローサーバにおいて実行可能なプログラムであって、
   未処理の案件に対して処理の催促を行った回数をカウントするカウント手段と、
   前記カウント手段でカウントした前記回数に応じて、前記催促を配信する宛先を決定する宛先決定手段と、
   前記宛先決定手段で決定される宛先に、前記催促を前記宛先に配信するための配信制御を行う配信制御手段と、
   前記未処理の案件を現在保持する処理担当者が案件の処理を滞留した時間を算出する算出手段と、
   として機能させ、
   前記宛先決定手段で決定する宛先は、前記未処理の案件を現在保持する処理担当者以外の、前記処理担当者よりも上位ロールの処理担当者であり、
   前記配信制御手段が、前記処理担当者の前記未処理の案件の処理の催促を前記処理担当者よりも上位ロールの処理担当者に配信する場合には、前記算出した未処理の案件を現在保持する処理担当者が案件の処理を滞留した時間を含めて配信することを特徴とするプログラム。

Images