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

Abstract

【課題】 本発明では、処理待ち案件がどのフェーズにおける処理待ちなのかを識別可能にし、更に、処理待ち案件が過去に処理した案件である場合には、過去に処理した案件であることを識別可能にすることにより、処理担当者が案件の処理を効率的に行えるようにする。また、同一の処理担当者が再度、案件の処理を行った場合に、案件を効率的に処理できる仕組みを提供する。【解決手段】 処理担当者へ処理依頼がされた案件が、処理担当者がどの役割で承認する案件なのかを識別可能にするために、処理依頼された案件を表示する処理待ち案件一覧の各案件に対し、役割を表示する。更に、処理担当者へ処理依頼がされた案件が、過去に当該処理担当者が処理を行った案件である場合、過去に承認を行った時点の役割とその承認日時を表示する。また、処理待ち案件表示画面の案件を処理待ち案件表示画面より承認を可能とする承認ボタンの機能を表示制御する。【選択図】図４

Description

本発明は、同一担当者が複数のアクティビティに割り当てられ、それらのアクティビティを順番に処理する場合、また、同一担当者が割り当てられたアクティビティを再度処理する場合に、処理すべき案件の、役割の違いなどをわかりやすく表示する機能、或いは、案件を処理しやすくする機能を備えるワークフローシステムに関する。

ワークフロー処理において、異なる処理を同一人物が行うことが可能である処理フローが定義されている場合、同一人物が処理を行うことが可能であるため、効率化させたいということがある。

例えば、引き続き次の処理を行う場合の効率化の工夫として、案件一覧から次の処理のために処理画面を起動するのではなく、前回の処理に引き続き次の案件の処理画面を連続して表示をすることを行うことがある。

特開２００３−０３０３８８

特許文献１には、同一担当者が連続するノードに割り当てられたアクティビティを効率的に処理するワークフローシステムが記載されている。

ワークフロー処理の処理アクティビティにおいて、連続処理待機時間という値を保持させることによって、そのアクティビティが連続処理待機時間内に、次の処理担当者を決定でき、次の処理を前回の処理担当者が連続して処理可能である場合に、次の処理を連続して処理することを可能にしている。

すなわち、次の連続処理が今回の処理に引き続いて処理可能である場合、その連続して処理する画面を表示することを可能にしている。

また、次の処理を前回の処理担当者が連続して処理可能で無い場合には、次の処理を行う処理担当者の選択を受け付けることを行っている。このように、連続処理が可能である場合には、今回の処理に引き続き、次の処理が連続して処理が行える仕組みを提供している。

しかしながら、特許文献１においては、連続して承認可能な場合に、処理担当者に対し、連続処理をしやすく次ぎの処理画面を表示してあげているのであって、このような機能を使用せず、処理待ち案件一覧から処理すべき案件の処理画面を起動することによって処理を行うワークフローシステムにおいて案件の処理が進められる場合、処理担当となっている連続承認を行うことが可能な案件が、現在どの処理位置における承認フェーズなのかを把握できるようにしているわけではない。また、連続承認を可能としているプロセス定義をもとに起案がされた案件であっても、連続承認にならない案件も存在する。

例えば、連続して承認がされるプロセス定義をもとに起案がされる案件の例としては次のものがある。ある組織部門の配下に、異なる下位の部門ある場合、例えばある部の配下に１課、２課となる部門が存在する場合、の組織において、その部門の部長がＡ氏であって、かつ、その配下にあたる１課の課長Ａ氏が兼務し、２課の課長はＢ氏であったとする。

この組織において「申請者→課長承認→部長承認→・・・」という承認経路が定義されているものとする。この承認経路の場合、１課から申請された案件については、Ａ氏が課長として一度承認し、部長として連続して承認することになる。しかし、２課から申請された案件については、Ｂ氏が課長承認し、Ａ氏が部長として初めて承認することになる。

この場合、処理担当者の承認待ち案件としては、１課の課長として承認する場合と、部の部長として承認する場合の２つの案件のケースがあり、部の部長として承認をする場合である場合、既に１課の課長として承認している場合には、既に内容を見て承認しているため、課長承認に連続する部長承認を効率よく行えるようにしたいということになる。

逆に、自分が課長の役割を兼任していない２課からの承認依頼が行われた案件（別の課長からの承認依頼が行われた案件）については、自分が過去に処理を一度も行っていないため、注意をして内容を確認してから承認をしたいということになる。

このように、連続処理が関連するプロセスで起案する案件においては、一度処理が行った状態のものとそうでないものが混在し、更に、一度処理を行ったものであっても自分が処理を行った案件であるため、連続して処理を行う案件と、他人が処理を行った案件であるため、初めて処理を行うことになる案件が存在するということになる。

上記のような状態にある、同一の処理担当者に連続処理に関係する案件が、多数存在した場合に、処理待ち一覧で処理をすべき案件の情報を、案件番号、案件名、処理日時、等、案件が起案された時の案件が持つ情報しか表示せず、この案件がどの処理フェーズなのかを案件一覧より案件の処理画面を一つずつ開いて初めて確認可能としているのであれば、案件の処理自体の効率化を図ることが出来ない。

そこで、本発明の目的は上記課題を鑑み、処理待ち案件一覧の表示（処理待ち案件表示画面）において、処理待ち案件がどのフェーズにおける処理待ちなのかを識別可能にし、更に、処理待ち案件が過去に処理した案件である場合には、過去に処理した案件であることを識別可能にすることにより、処理担当者が案件の処理を効率的に行えるようにする仕組みを提供することを目的とする。また、同一の処理担当者が再度、案件の処理を行った場合に、案件を効率的に処理できる仕組みを提供することを目的とする。

本発明は、同一の処理担当者が再度処理を行うことによって処理を進めることを可能とするワークフローシステムにおいて、前記ワークフローシステムにおいて申請された案件の処理を行う単位であるアクティビティごとの処理の状況を処理履歴として記憶する処理履歴記憶手段と、前記案件の処理担当者の処理待ちの状態である案件を前記処理履歴記憶手段より抽出する処理待ち案件抽出手段と、前記処理待ち案件抽出手段によって抽出した処理待ちの状態の案件を前記処理担当者の処理待ち案件表示画面において表示する表示手段と、前記処理待ち案件抽出手段により抽出された処理待ちの状態の案件が、処理担当者が過去に処理してから、当該処理担当者の処理待ちの状態となるまでの間に、差戻しがされたか否かによって、前記処理待ちの状態の案件を、前記表示手段により表示する前記処理待ち案件表示画面において前記処理待ちの状態の案件を承認することを可能とする承認ボタンを表示制御する承認ボタン表示制御手段とを備えることを特徴とする。

本発明によれば、処理待ち案件一覧の表示（処理待ち案件表示画面）において、処理待ち案件がどのフェーズにおける処理待ちなのかを識別可能にし、更に、処理待ち案件が過去に処理した案件である場合には、過去に処理した案件であることを識別可能にすることにより、処理担当者が案件の処理を効率的に行えるようにする仕組みを提供することが可能となる。また、同一の処理担当者が再度、案件の処理を行った場合に、案件を効率的に処理できる仕組みを提供することが可能となる。

本発明の実施形態におけるワークフローシステムの構成の一例を示す図である。 本発明の実施形態における各種端末のハードウェア構成の一例を示す図である。 本発明の実施形態における機能構成図の一例を示す図である。 本発明の実施形態における処理待ち案件一覧（処理待ち案件表示画面）の作成の処理に関するフローである。 本発明の実施形態における定義情報と案件情報の関係を示す図である。 本発明の実施形態における組織情報を構成するデータテーブルと組織図の一例を示す図である。 本発明の実施形態における定義情報を構成するデータテーブルとプロセス定義の一例を示す図である。 本発明の実施形態における案件情報を構成するデータテーブルと案件の処理履歴図の一例を示す図である。 本発明の実施形態における処理待ち一覧の画面と従来の処理待ち一覧の画面の一例を示す図である。 本発明の実施形態における処理待ち案件表示画面の作成の処理に関するフローである。 本発明の実施形態における組織情報を構成するデータテーブルと組織図の一例を示す図である。 本発明の実施形態における定義情報を構成するデータテーブルとプロセス定義の一例を示す図である。 本発明の実施形態における案件の情報を構成するデータテーブルの一例を示す図である。 本発明の実施形態における案件の処理履歴図の一例を示す図である。 本発明の実施形態における処理待ち案件表示画面の一例を示す図である。 本発明の実施形態における過去に承認した案件に対し処理待ち一覧で「承認」ボタンの機能を表示可能とする日数について管理するデータテーブの一例を示す図である。 本発明の実施形態におけるワークフローシステムの構成の一例を示す図である。 本発明の実施形態におけるプロセス定義の一例を示す図である。 本発明の実施形態における案件の情報を構成するデータテーブルの一例を示す図である。 本発明の実施形態における案件の処理履歴図の一例を示す図である。 本発明の実施形態における処理待ち案件表示画面の一例を示す図である。 本発明の実施形態におけるアクティビティテールの一例を示す図である。 本発明の実施形態における定義情報と案件情報の関係を示す図である。 本発明の実施形態における処理待ち案件表示画面より案件の処理を受け付ける処理に関するフローである。 本発明の実施形態における処理待ち案件表示画面より案件の処理を受け付けた時の処理待ち一覧の画面の一例を示す図である。 本発明の実施形態における案件の情報を構成するデータテーブルの一例を示す図である。

以下、図面を参照して、本発明の実施形態を詳細に説明する。
図１は、本実施形態が適用されるワークフローシステムの概略構成を示す図である。

図１において、ワークフローシステムは少なくとも１つのワークフローサーバ１０１とワークフロークライアント１０２がネットワークを介して接続されている。本実施例においては、ワークフロークライアント１０２は複数台で構成されている。

ユーザは、たとえばウェブブラウザやクライアントソフトウェアなどを利用して、ワークフロークライアント１０２から、ワークフローサーバ１０１に対して、ワークフロー進行の要求などを行う。

ワークフローサーバ１０１は、ワークフロークライアント１０２からの要求に応じた処理、案件の管理をおこない、必要があればワークフロークライアント１０２に対して結果などを送信する。ワークフローサーバ１０１とワークフロークライアント１０２の間の通信は、通常のＨＴＴＰのリクエストでもよいし、ＳＯＡＰなどを利用したウェブサービスのリクエストでもよい。

図２は、本発明の実施形態におけるワークフローサーバ１０１とワークフロークライアント１０２のハードウェア構成を示す図である。

図２において、ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、各サーバーあるいは各クライアントの後述する各種機能を実現するためのプログラムが記憶されている。
ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。

入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、特に、サーバーやクライアント等の端末では、キーボード、マウス等のポインティングデバイスが挙げられる。
出力コントローラ２０６は、出力部２１０の表示を制御する。この出力部２１０としては、例えば、ＣＲＴや液晶ディスプレイ等が挙げられる。

外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。加えて、各サーバーあるいは各クライアントの各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ２１１としては、ハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。
通信Ｉ／Ｆコントローラ２０８は、ネットワーク２１３を介して外部機器との通信制御処理を実行する。

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

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

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

ワークフローサーバ１０１は、処理履歴記憶部３０１、案件抽出部３０２、表示部３０３、役割表示部３０４、過去処理識別表示部３０５、処理部３０６、一括処理部３０７からなる。

処理履歴記憶部３０１は、ワークフローシステムにおいて申請された案件の、各処理単位における処理済や処理待ちの状況を配送履歴として記憶する。

案件抽出部３０２は、案件の処理担当者の、前記異なる処理それぞれにおける処理待ちの案件を処理履歴記憶部３０１より抽出する。

表示部３０３は、案件抽出部３０２によって抽出した案件を処理担当者の処理待ち案件一覧画面（処理待ち案件表示画面）において表示する。

役割表示部３０４は、表示部３０３によって処理待ち案件一覧画面（処理待ち案件表示画面）に表示された案件に対し、処理担当者が当該案件を処理すべき役割を表示する。

過去処理識別表示部３０５は、役割表示部３０４によって役割を表示した処理待ち案件一覧画面（処理待ち案件表示画面）において表示される案件の、過去の処理担当者が、当該案件の処理担当者と同一である場合、過去に処理したことを識別可能に、過去に承認した時点の役割と過去に承認した承認日時を表示する。

処理部３０６は、ワークフロークライアント１０２の表示部３１１に表示がされた処理待ち案件一覧（処理待ち案件表示画面）において表示されている案件のうち、過去に承認したことがある案件の処理画面を開かず承認することをワークフロークライアント１０２の処理部３１２より受け付け、処理を行う。

一括処理部３０７は、ワークフロークライアント１０２の表示部３１１に表示がされた処理待ち案件一覧（処理待ち案件表示画面）において表示されている案件のうち、過去に承認したことがある複数案件の処理画面を開かず一括して承認することをワークフロークライアント１０２の処理部３１２より受け付け、処理を行う。

ワークフロークライアント１０２は、表示部３１１と処理部３１２からなる。

表示部３１１は、ワークフローサーバ１０１の表示部３０３によって表示処理が行われた処理担当者の処理待ち案件一覧画面（処理待ち案件表示画面）を表示する。

処理部３１２は、表示部３１１で表示がされている処理待ち案件一覧画面（処理待ち案件表示画面）の案件に対する処理を受け付け、ワークフローサーバ１０１に処理依頼を行う。

続いて、本発明のワークフローの処理が行われるにあって必要となる前提条件を図５から図９において、説明を行う。

図５は、ワークフローの設計情報である定義情報と、実際にその定義情報を利用して申請がされた案件である案件情報の関係を示す図である。

定義情報５００は、ワークフローにおける業務を定義する情報であり、設計者が予め定義するものであり、本実施例においては、業務５０１、プロセス５０２、アクティビティ５０３からなるようにする。

業務５０１は、ワークフローにおいて申請を行うために必要となるアプリケーションの設計情報の単位であって、業務ＩＤと業務名で識別可能にすることとする。

プロセス５０２は、ワークフローで申請される業務５０１に対する、処理のルートの規則を定義したものであって、１つの業務に対し、申請部門ごとに複数のプロセスを定義可能であるため、プロセス５０２は、プロセスＩＤ、業務ＩＤ、申請可能ＩＤでどのようなプロセスであるかを識別可能であることとする。

アクティビティ５０３は、プロセス５０２で定義される処理のルートにおけるそれぞれの処理単位の定義であり、例えば、承認を行うための１つのアクティビティ設定例としては、処理担当者が所属する部門ＩＤ、処理担当者の役割ＩＤ、等を設定することによってアクティビティの定義を行うこととする。なお、アクティビティ５０３はプロセス５０２の定義に対して紐付き、アクティビティＩＤと、プロセスＩＤとの組み合わせで紐付けが識別可能であることとする。またアクティビティ処理の順番である番号と、担当ロールの情報ももつこととする。

なお、図中の「１」と「＊」は、１対多の関係にあることを示す。例えば、業務５０１に対しては、複数のプロセス５０２を紐付けることが可能である。また、１つのプロセス５０２は、複数のアクティビティ５０３が構成されるということである。更に、１つのプロセス５０２を基に申請されたワークフローにおける案件データである案件情報５１０の案件５１１と紐付くこととなる。

案件情報５１０とは、ワークフローにおいて申請された案件に関する情報であり案件５１１と処理履歴５１２からなる。

案件５１１は、業務５０１を基に申請がされたワークフローシステムにおける案件データのことを指し、案件ＩＤ、案件が申請された業務に紐付くプロセスＩＤ、また、案件を申請した申請者を特定可能にするために、申請者が所属する申請部門ＩＤと申請ロールＩＤの情報を持つこととする。

処理履歴５１２は、１つの案件５１１に対して複数存在するものであって、案件の処理履歴データのことを指す。この処理履歴データである処理履歴５１２は、申請された案件を識別するための案件ＩＤ、その案件が処理された、プロセス５０２の中における位置の情報であるアクティビティＩＤ、案件の処理を行った処理担当者の担当者ＩＤ、案件の処理状況を示す状態、案件の処理が行われた日時である処理日の情報を持つこととする。

図６は、本発明のワークフローの処理が行われるにあたって使用される組織情報を説明するための図である。

組織情報は、部門テーブル６１１、ロールテーブル６１２、ユーザテーブル６１３の情報の組み合わせることによって組織情報テーブル６１４を構成することにより作成されることとする。

部門テーブル６１１は、組織を識別するための情報である、部門ＩＤ、部門名、組織６２１に示すように、組織を階層型で表現した場合に組織階層のレベルを示す番号であるレベル番号、自分の部門ＩＤの階層より１つ上の階層の部門ＩＤを示す親部門ＩＤの情報から構成することとする。

ロールテーブル６１２は、ワークフローで申請や承認等の処理を行うユーザに紐付くロールＩＤとその役割の名称を示すロール名から構成することとする。

ユーザテーブル６１３は、ワークフローで申請や承認等の処理を行うユーザのユーザＩＤ、それに紐付く氏名、メールアドレス、パスワードから構成することとする。

これらの情報をもとに、組織情報テーブル６１４は作成されることとする。

組織情報テーブル６１４は、どの組織に誰がどの役割で所属しているのか、についての情報を登録しておくテーブルであって、ワークフローで申請や承認等の処理を行うユーザのユーザＩＤ、そのユーザに紐付く役割を識別するためのロールＩＤ、また、そのユーザが所属する部門ＩＤの情報から構成されることとする。

なお、組織情報テーブル６１４を階層構造で表現した組織図で図示した例を、組織６２１を用いて説明する。例えば、ユーザＩＤがＵ０００の木屋野一郎は、組織情報テーブル６１４においては、所属する部門ＩＤは、Ｂ００１とＣ００１となる。また、部門ＩＤがＢ００１である場合は、ロールＩＤはＲ００２であって、部門ＩＤがＣ００１である場合は、ロールＩＤはＲ００１となっている。この情報を、階層型の組織図で、木屋野一郎が所属する部署と、部署に応じた役割を図示すると、部門ＩＤがＢ００１に、ロールＩＤがＲ００２で所属をしている状況は６２１−１として、部門ＩＤがＣ００１に、ロールＩＤがＲ００１で所属をしている状況は６２１−２として図示することが可能となる。

図７は、図５の定義情報５００の業務５０１、プロセス５０２、アクティビティ５０３の情報をテーブル構造で説明する図である。

なお、図７の各テーブル構造は、図６の組織情報テーブル６１４または、組織６２１の情報を使用することを前提として説明をする。

業務テーブル７０１は、業務５０１の情報をテーブル構造で説明した図である。業務テーブル７０１には、ワークフローにおいて申請がされる案件のアプリケーションの設計情報の情報が登録され、設計情報（アプリケーション情報）を識別する業務ＩＤ、その設計情報の名称である業務名、の情報からなる。

一例として、業務ＩＤとして「ＧＩＤ００１」、業務名として「交通費精算」が登録されていることとする。

プロセステーブル７０２は、プロセス５０２の情報をテーブル構造で説明した図である。プロセステーブル７０２には、案件が申請される業務に紐付くプロセス定義の情報が登録され、プロセスを識別可能にするプロセスＩＤ、プロセスＩＤに紐付く業務ＩＤ、そのプロセスＩＤで定義されたプロセスにおいて申請可能な部門の情報である申請可能部門ＩＤ、の情報からなる。

一例として、プロセスＩＤとして「ＰＩＤ００１」、業務ＩＤとして「ＧＩＤ００１」、申請可能部門ＩＤとして「Ｂ００１」が登録されていることとする。なお、「Ｂ００１」で指定された場合、「Ｂ００１」の配下の部門である「Ｃ００１」と「Ｃ００２」から案件が申請できることとする。

アクティビティテーブル７０３は、アクティビティ５０３の情報をテーブル構造で説明した図である。アクティビティテーブル７０３には、案件が誰にどの順番で処理されるのかを定義したプロセス定義の各処理の処理担当者の情報が登録される。各アクティビティを識別するためのアクティビティＩＤ、アクティビティがどのプロセスのものであるかを識別可能にするプロセスＩＤ、アクティビティの処理の順序を管理する番号、担当ロールＩＤ、の情報からなる。

プロセス定義７０４は、プロセステーブル７０２とアクティビティテーブル７０３の情報をもとに、実際のプロセスを分かりやすく図示したものである。

プロセスＩＤがＰＩＤ０００１のプロセスは、アクティビティテーブル７０３の番号で指定されている順番の通り、０番目のアクティビティは、担当ロールが無しになっているため、申請可能部門がＢ０００１配下に所属される誰もが案件を申請できることなる（７０４−１）。

次の７０４−２のアクティビティは、アクティビティテーブル７０３の番号が１番目のアクティビティを図示したものであって、担当ロールがＲ００１で指定されている。

次の７０４−３のアクティビティは、アクティビティテーブル７０３の番号が２番目のアクティビティを図示したものであって、担当ロールがＲ００２で指定されている。

このプロセス定義の例は、部門ＩＤについては指定がされていなくて、担当ロールのみをアクティビティに設定するプロセス定義である。この場合、処理担当者の決定は、申請された部署の部門ＩＤと同じ部門ＩＤの組織の中において、指定された担当ロールを所持する処理担当者がいないかを判定し、存在しない場合は、その部門ＩＤと同じ系列の上位組織をたどっていき、指定された担当者ロールを所持する処理担当者がいないかを確認し、存在した場合は、その処理担当が案件の処理を行うユーザとなることとする。

つまり、７０４−２は、ロールテーブル６１２の情報より、課長（Ｒ００１）、部長（Ｒ００２）に処理依頼が行われることになるが、申請された部署の所属組織から同じ系列の組織階層を上位階層へたどっていき、課長や部長の役割のユーザが存在する時に、そのユーザに対して処理依頼がいくという動作であることとする。

例えば、組織６２１に示すように、木屋野三郎が申請をＣ００１から行ったとすると、課長が同一部門ＩＤの組織にいるため、次の７０４−２の処理担当者は木屋野一郎になり、さらに次の７０４−３の処理担当者はＢ００１の組織にいるためＢ００１に所属する木屋野一郎が処理を行うこととなる。

図８は、図５の案件情報５１０の案件５１１、処理履歴５１２の情報をテーブル構造で説明する図である。

なお、図８の各テーブル構造は、図６の組織情報テーブル６１４または、組織６２１の情報、また、図７の業務テーブル７０１、プロセステーブル７０２、アクティビティテーブル７０３、プロセス定義７０４の情報を使用することを前提として説明をする。

図８の案件テーブル８０１は、案件５１１の情報をテーブル構造で説明した図である。案件テーブル８０１には、ワークフローにおいて申請がされた案件のデータの情報が登録される。

申請がされた案件の業務に紐付くプロセスＩＤ、新規案件が申請されると申請を識別ために付与される案件ＩＤ、案件を申請したユーザが所属する申請部門ＩＤ、案件を申請したユーザに紐付く申請ロールＩＤの情報からなる。

一例として、プロセスＩＤが「ＰＩＤ００１」でプロセス定義がされた業務ＩＤ「ＧＩＤ００１」（ワークフローにおいては申請するための業務）が、申請可能部門ＩＤとして「Ｃ００１」に所属する、申請ロールＩＤが「Ｒ０００」のユーザによって申請がされた、案件ＩＤが「０００００００１」のデータが登録されていることとする。

図８の処理履歴テーブル８０２は、処理履歴５１２の情報をテーブル構造で説明した図である。処理履歴テーブル８０２には、申請された案件が処理された処理履歴のデータをプロセス定義における各アクビティ単位で保持するテーブルである。

案件ＩＤは、申請がされた案件を識別するためのＩＤが登録され、アクティビティＩＤには、その案件が処理されたアクティビティの情報が登録され、担当者ＩＤには、処理を行った処理担当者のユーザＩＤが登録され、状態へは、処理済や処理待ちなど案件の状態が登録され、処理日は、案件に対する承認等の実際の処理が行われた日時が登録される。

例えば、案件ＩＤが０００００００１の案件については、組織情報テーブル６１４のユーザＩＤがＵ００２の申請者によって申請がされ、アクティビティａｃｔ００１において、組織情報テーブル６１４のユーザＩＤがＵ０００の処理担当者による処理待ち状態となっている。

案件ＩＤが０００００００２の案件については、組織情報テーブル６１４のユーザＩＤがＵ００２によって、申請され、アクティビティａｃｔ００１において、組織情報テーブル６１４のユーザＩＤがＵ０００の処理担当者によって承認が行われ（課長の役割で承認が行われ）、のユーザＩＤがＵ０００の処理担当者による処理待ち状態（部長の役割での処理待ち状態）となっている。

案件ＩＤが０００００００３の案件については、組織情報テーブル６１４のユーザＩＤがＵ００３の申請者によって申請がされ、アクティビティａｃｔ００１において、組織情報テーブル６１４のユーザＩＤがＵ００１の処理担当者によって承認が行われ（課長の役割で承認が行われ）、のユーザＩＤがＵ０００の処理担当者による処理待ち状態（部長の役割での処理待ち状態）となっている。

なお、処理履歴８０３は、処理履歴テーブル８０２の処理履歴の状況を各案件（案件ＩＤ＝０００００００１、案件ＩＤ＝０００００００２、案件ＩＤ＝０００００００３）ごとに図示した図である。

図９は、ワークフローで申請がされた案件で、処理担当者へ処理依頼がされた案件の一覧を表示する処理待ち案件表示画面の一例を示す図である。なお、図９の９００は、従来の処理待ち案件表示画面の一例であり、図９の９２０は、本発明における処理待ち案件表示画面の一例とする。なおそれぞれにおいて表示をしている処理待ち案件のデータは、処理履歴テーブル８０２において、担当者ＩＤがＵ０００（部門ＩＤ＝Ｂ００１、ロールＩＤ＝Ｒ００２の木屋野一郎）の状態が処理待ちになっている案件（案件ＩＤ＝０００００００１、案件ＩＤ＝００００００２、案件ＩＤ＝００００００３）であることとする。

続いて、従来の処理待ち案件表示画面９００の各表示項目について説明を行う。

操作９０１は、案件を処理するため操作するための機能を表示する箇所である。例えば、９０１においては、案件を開くための「開く」という機能が表示される。状態９０２は、処理履歴テーブル８０２の「状態」の値を表示する。案件名９０３は、案件が申請された業務の名称を表示する。案件番号９０４は、処理履歴テーブル８０２の「案件ＩＤ」の値を表示する。タイトル９０５は、申請画面で申請者より記入処理を受け付けた、申請の簡単な内容（どのような申請内容かを記載した内容）の値を表示する。受信日９０６は、処理履歴テーブル８０２の「処理日」の値を表示する。

申請部門９０７は、処理履歴テーブル８０２に紐付く、案件テーブル８０１の申請部門ＩＤ（紐付けは「案件ＩＤ」で行う）を基に、部門テーブル６１１の「部門名」を抽出し、表示する。

申請者９０８は、処理履歴テーブル８０２に存在するレコードのうち、処理待ち案件一覧（処理待ち案件表示画面）に表示する案件と、同一の「案件ＩＤ」を持ち、かつ「アクティビティＩＤ」が申請アクティビティのレコードの「担当者ＩＤ」の値をまず抽出する。さらにその担当者ＩＤの値をもとに、ユーザテーブル６１３を検索し、「氏名」の情報を表示する。

９０９は、表示されている案件を選択状態にするためのチェックボックスである。９１０は、９０９で選択状態にされた案件に関して、処理画面を開かずに案件の処理を可能とするための一括承認機能のボタンである。

続いて、本発明における処理待ち案件表示画面９２０の各表示項目について説明を行う。

なお、状態９２２は状態９０２、案件名９２３は案件名９０３、案件番号９２４は案件番号９０４、タイトル９２５はタイトル９０５、受信日９２７は受信日９０６、申請部門９２８は申請部門９０７、申請者９２９は申請者９０８、９３１は９０９、９３２は９１０と同様の表示内容であるため、説明は省略し、ここでは、操作９２１、あなたの役割９２６、備考９３０、９３３（過去に承認した案件の一括承認）について説明を行う。

操作９２１は、案件を処理するため操作するための機能を表示する箇所である。例えば、９２０においては、案件を開くための「開く」という機能の他に、「承認」という機能が表示される。この詳細については後述する。

あなたの役割９２６は、処理担当者が表示されている案件をどの役割における処理待ち状態であるかを識別可能に処理担当者の役割を表示する。この詳細については後述する。

備考９３０は、処理担当者が案件を既に承認を行っている場合に、どの役割でいつ承認を行ったかを識別可能に表示する。この詳細については、後述する。

９３３は、過去に一度承認を行った案件に関して処理画面を開かずに案件の承認を可能とするための過去に承認した案件の一括承認の機能を有するボタンである。なお、ボタン押下時に、過去に承認が行われているものに関して一括承認を行えるようにしても良いこととする。

また、同じく９３３のボタンの押下を受け付けた場合、過去に一度承認が行われている案件を選択状態にし、ユーザからの選択の有無の切り替えを受け付けた後に、一括承認を行えるようにしても良いこととする。

また、同じく９３３のボタンの押下を受け付けた場合、９３１が選択状態にされた案件が過去に承認が行われているものかを判定して、過去に承認が行われているものに関して一括承認を行えるようにしても良いこととする。

すなわち、過去に承認した案件と、９３３のボタンが押下された場合、少なくとも９３１が選択状態にされた案件については、過去に承認された案件であることを確認したうえで一括承認がなされるようにするということである。
＜第１の実施形態＞

続いて、図４を参照して、本実施形態のワークフローシステムにおける処理待ち一覧（図９の９２０）を表示する処理について説明する。

ワークフローシステムにおける処理担当者はログイン画面（不図示）に処理担当者自身のユーザＩＤとパスワードを入力しシステムの利用を開始することとする。尚、取得したユーザＩＤはＲＡＭ２０２に記憶され、後述のＳ４０１、Ｓ４０４の処理で利用される。

また、処理担当者がワークフロークライアントの「処理待ち一覧」ボタン（不図示）を押下すると、本処理がワークフローサーバ１０１のＣＰＵ２０１にて実施され、処理待ち一覧（図９の９２０）がワークフロークライアントに表示されることとする。

ステップＳ４０１では、処理履歴テーブル８０２を参照し、「状態」が「処理待ち」で、かつ、「担当者ＩＤ」が、処理担当者がシステムの利用を開始する際に入力したユーザＩＤと一致するものを抽出する。

例えば、本処理においては、処理履歴テーブル８０２のうち、状態が「処理待ち」であって、担当者ＩＤが、Ｕ０００のデータを抽出することとする。

抽出した各処理待ちのデータについて、後述のＳ４０２からＳ４０６のステップを繰り返し実施する。

ステップＳ４０２は、処理待ち一覧の図９の９２２から９２５、９２７から９２９の各項目の値を表示するステップである。各項目の値については、図９の各項目の説明でした方法で値を取得する。

ステップＳ４０３は、本発明における処理待ち案件表示画面９２０の各案件の役割９２６に表示を行う役割名を求めるステップである。

処理履歴テーブル８０２の「アクティビティＩＤ」を元に、アクティビティテーブル７０３を参照し、処理担当者指定として指定されている「担当ロールＩＤ」を求める。更に、「担当ロールＩＤ」より、ロールテーブル６１２を参照し、「ロール名」を求める。この「ロール名」を本発明における処理待ち案件表示画面９２０の９２６に表示をする。

例えば、処理履歴テーブル８０２の案件ＩＤ＝０００００００１（担当者ＩＤが「Ｕ０００」で状態が「処理待ち」）のレコードは、アクティビティＩＤがａｃｔ００１であり、そのアクティビティＩＤより、担当ロールＩＤを求めると、Ｒ００１となる。そのロール名（役割）をロールテーブル６１２から求めるとロール名として「課長」が求められ、あなたの役割９２６には、「課長」が表示される。

処理履歴テーブル８０２の案件ＩＤ＝０００００００２（担当者ＩＤが「Ｕ０００」で状態が「処理待ち」）のレコードは、アクティビティＩＤがａｃｔ００２であり、そのアクティビティＩＤより、担当ロールＩＤを求めると、Ｒ００２となる。そのロール名（役割）をロールテーブル６１２から求めるとロール名として「部長」が求められ、あなたの役割９２６には、「部長」が表示される。

処理履歴テーブル８０２の案件ＩＤ＝０００００００３（担当者ＩＤが「Ｕ０００」で状態が「処理待ち」）のレコードも、前述した、案件ＩＤ＝０００００００２の案件で表示される役割と同じである。

ステップＳ４０４は、利用者が過去に承認したかを判定するステップである。

処理履歴テーブル８０２の中で、以下（１）〜（３）の条件にすべて該当する案件の「レコードが存在する場合、その案件のレコードは過去に承認したと判定することとする。
（１）処理履歴テーブル８０２の案件ＩＤが、ステップＳ４０１で処理履歴テーブル８０２より抽出した案件の案件ＩＤと一致
（２）処理履歴テーブル８０２の担当者ＩＤが、ワークフローシステムへログインを開始するときに、処理担当者が入力したユーザＩＤと一致
（３）処理履歴テーブルの８０２の状態が処理済みである

ステップＳ４０４で、処理対象の案件が過去に承認した案件ではないと判定した場合、ステップＳ４０５で、図９の操作９２１に、「開く」ボタンのみを表示する処理を行う。

例えば、ステップＳ４０１で抽出したレコードの中の、案件ＩＤが０００００００１と０００００００３のレコードには、担当者ＩＤが「Ｕ０００」であって、状態が「処理済み」のレコードが存在しないため、このレコードを本発明における処理待ち案件表示画面９２０に表示する場合は、操作９２１に「開く」のボタンを表示する。なお、ここではボタンとしているが、ボタンではなくリンクが張られるようにしても良いこととする。

ステップＳ４０４で、処理対象の案件が過去に承認した案件であると判定した場合、ステップＳ４０６で、図９の操作９２１に、「開く」と「承認する」ボタンを表示する処理を行う。

例えば、ステップＳ４０１で抽出したレコードの中の、案件ＩＤが０００００００２のレコードには、担当者ＩＤが「Ｕ０００」であって、状態が「処理済み」のレコードが存在しているため、このレコードを本発明における処理待ち案件表示画面９２０に表示する場合は、操作９２１に「開く」と「承認する」のボタンを表示する。なお、ここではボタンとしているが、ボタンではなくリンクが張られるようにしても良いこととする。

更に、図９の備考９３０において、過去に承認した役割と過去に承認した日時が分かるコメントを表示する。

例えば、図９の９５１ではとして、「課長として２０１４／０６／３０に承認した案件です」と表示している。

「課長として２０１４／０６／３０に承認した案件です」の文言のうち、「課長」の部分は、処理担当者が処理したときのロールの名称が表示されているのであって、ステップＳ４０４で抽出した処理履歴のレコードより、ステップＳ４０３と同様の手順で求め、その値を表示する。

また、２０１４／０６／３０の部分は、処理担当者が処理した日付が表示されているのであって、ステップＳ４０４で処理履歴のレコードより、処理日を求め、その値を表示する。

例えば、ステップＳ４０１で抽出したレコードの中の、案件ＩＤが０００００００２のレコードには、担当者ＩＤが「Ｕ０００」であって、状態が「処理済み」のレコードが存在しているため、このレコードを本発明における処理待ち案件表示画面９２０に表示する場合は、備考９３０に「課長として６／３０に承認した案件です」のコメントを表示する。

なお、ステップＳ４０４で抽出した処理履歴テーブルのレコードが同一案件の中で複数の存在する場合、すなわち、同一案件で過去に２度以上承認している場合、それぞれについて過去に承認した役割と過去に承認した承認日時を表示してもよいし（不図示）、直近の１件のみ過去に承認した役割と過去に承認した承認日時を表示（不図示）してもよいこととする。

なお、実際の処理待ち一覧を表示する処理では、上記だけでなく他の情報の取得や、情報をワークフロークライアントに転送し、表示する手段が必要であるが、それらは従来の技術を利用することとする。

以上の処理により、処理待ち案件一覧（処理待ち案件表示画面）の表示において、処理待ち案件がどのフェーズにおける処理待ちなのかを識別可能にし、更に、処理待ち案件が過去に処理した案件である場合には、過去に処理した案件であることを識別可能にすることにより、処理担当者が案件の処理を効率的に行えるようにする仕組みを提供することが可能となる

また、過去に図９の本発明における処理待ち案件表示画面９２０においては、９３３の過去に承認した案件の一括承認を行うことを可能とするためのボタンの押下を受け付けた場合、過去に承認が行われているものに関して一括処理を行えるようにしても良いこととする。

また、同じく９３３のボタンの押下を受け付けた場合、過去に一度承認が行われている案件を選択状態にし、ユーザからの選択の有無の切り替えを受け付けた後に、一括承認を行えるようにしても良いこととする。

また、同じく９３３のボタンの押下を受け付けた場合、９３１が選択状態にされた案件が過去に承認が行われているものかを判定して、過去に承認が行われているものに関して一括承認を行えるようにしても良いこととする。

すなわち、９３３のボタンが押下された場合、少なくとも９３１が選択状態にされた案件については、過去に承認された案件であることを確認したうえで一括承認がなされるようにするということである。

なお、本実施例においては、処理担当者が処理待ち案件一覧（処理待ち案件表示画面）に表示される案件を過去に処理した場合、前回処理したケースを挙げて説明を行ったが、過去というのは前回に限定されなくても良いこととする。例えば、前回は別の処理担当者が処理を行って、その前の処理単位（アクティビティ）において処理担当者が処理を行ったことがあるというケースも、本発明が適応可能であることとする。

続いて、図２４の処理図を用いて、図９の処理待ち案件表示画面２５００において、案件の処理担当者が、承認ボタン９５０や、一括承認ボタン（９３３）を押下したときの動作について説明を行う。なお、本処理は、ワークフローサーバ１０１のＣＰＵ２０１において実行されるものとする。

ステップＳ２４０１において、処理待ち案件表示画面２５００において、承認ボタン９５０、又は、過去に承認した案件の一括承認ボタン９３３（以下、一括承認ボタン９３３とする）の押下を受け付ける。

ステップＳ２４０２において、処理待ち案件表示画面２５００において、承認ボタン９５０、又は、一括承認ボタン９３３、のどちらが押下されたかを判定する。

ステップＳ２４０２において、図２５の承認ボタン９５０が押下されたと判定した場合は、ステップＳ２４０３へ処理を進め、ステップＳ２４０２において、図２５の一括承認ボタン９３３が押下されたと判定した場合は、ステップＳ２４０４へ処理を進める。

ステップＳ２４０３において、図２５の承認ボタン９５０の押下を受け付けた案件の処理を行う。そして、処理担当者が処理したアクティビティにおける処理は処理済みの状態とし、次のアクティビティが存在する場合は、案件の次の処理担当者（次の処理を行うアクティビティ）において処理待ちの状態とする。

図２５の案件番号９２４が０００００００２の案件を例にとって説明をする。

図２５の処理待ち案件表示画面２５００は、処理待ち案件表示画面より案件の処理を受け付けた時の処理待ち案件表示画面の一例を示す図である。

なお、図２５の９２１〜９３３、９５０の各機能、各項目は、図９の本発明における処理待ち案件表示画面９２０において同一の番号がふられている機能、項目と同じものであるとする。そのため各機能、各項目の詳細な説明については省略する。

なお、図２５の案件番号６２４が０００００００２の案件は、図９の案件番号９２４が０００００００２の案件と同じ案件であることとする。そのため、紐づくプロセス定義は、プロセス定義７０４であるとし、処理履歴についても、処理履歴テーブル８００の「案件ＩＤ」が０００００００２で管理されている処理履歴と同じである前提とする。

図２５の案件番号９２４が０００００００２の案件は、処理履歴テーブル８０２の処理履歴の管理においては、「アクティビティＩＤ」がａｃｔ００２のレコードにおいて、「状態」が処理待ちとなっているが、「担当者ＩＤ」がＵ０００の処理担当者によって、図２５の承認ボタン９５０の押下の処理を受け付けると、「案件ＩＤ」が０００００００２、「アクティビティＩＤ」がａｃｔ００２のレコードの「状態」は処理済みとなる。

また、図２５の案件番号６２４が０００００００２の案件は次のアクティビティによる処理がプロセス定義上存在しないため、処理が終了したということになり、処理待ち案件表示画面２５００には、表示されなくなる。

ステップＳ２４０４において、承認ボタン９５０が付与されている案件、すなわち、処理担当者が過去に承認を行っていて、連続して承認を行える状態の案件、を処理待ち案件表示画面２５００の画面より一括で処理を行う。

そして、処理担当者が処理した各案件のアクティビティにおける処理は処理済みの状態とし、次のアクティビティが存在する場合は、各案件の次の処理担当者（次の処理を行うアクティビティ）において処理待ちの状態とする。

図２５の案件番号６２４が０００００００２、００００００１０、００００００１１の案件を例にとって説明をする。

なお、図２５の案件番号６２４が００００００１０と、００００００１１の案件は、本処理の説明のために用意した案件であるが、図２５の案件番号６２４が０００００００２の案件と同じ業務において起案がされた案件であり、同じアクティビティで処理待ちとなっている案件であることとする。そのため、紐づくプロセス定義は、プロセス定義７０４であるとする。

なお、処理履歴については、処理履歴テーブル２６００の「案件ＩＤ」が０００００００２で管理されている処理履歴と同じである前提とする。なお、処理履歴テーブル２６００の「案件ＩＤ」が０００００００２で管理されている処理履歴は、処理履歴テーブル８００の「案件ＩＤ」が０００００００２で管理されている処理履歴と同じであることとする。また、図２６の処理履歴テーブル２６００は図８の処理履歴テーブル８０２、とテーブルの構造については同一であることとする。そのため詳細な説明は省略する。

図２５の案件番号９２４が０００００００２、００００００１０、００００００１１の案件は、処理履歴テーブル２６００の処理履歴の管理においては、それぞれ「アクティビティＩＤ」がａｃｔ００２のレコードにおいて、「状態」が処理待ちとなっているが、「担当者ＩＤ」がＵ０００の処理担当者によって、図２５の一括承認ボタン９３３の押下の処理を受け付けると、「案件ＩＤ」が０００００００２、００００００１０、００００００１１、における、「アクティビティＩＤ」がａｃｔ００２のレコードの「状態」は処理済みとなる。

また、図２５の案件番号６２４が０００００００２、００００００１０、００００００１１の案件は次のアクティビティによる処理がプロセス定義上存在しないため、処理が終了したということになり、処理待ち案件表示画面２５００には、表示されなくなる。

なお、一括承認ボタン９３３が押下された場合に、過去に承認を行った、全ての承認ボタン９５０が付与されている案件を自動的に承認するのではなく、承認ボタン９５０が付与されている案件の中において、一括承認を受け付ける案件の選択を９３１にチェックを入れることで受け付けることによって、９３１にチェックが入っている案件のみを一括承認できるようにしても良いこととする。

また、一括承認ボタン９３３が押下された場合に、予め９３１にチェックを入れておいた案件が、過去に承認を行っているかを判定した上で、一括承認ができるようにしても良いこととする。

すなわち、一括承認ボタン９３３が押下された場合、少なくとも９３１が選択状態にされた案件については、過去に承認された案件であることを確認したうえで一括承認がなされるようにするということである。

以上で、図２４の処理図の説明を終了する。
＜第２の実施形態＞

続いて、第２の実施形態について説明を行う。図４による第１の実施形態の処理待ち案件表示画面の表示においては、図４のステップＳ４０４で、処理対象の案件が過去に承認した案件であると判定した場合、ステップＳ４０６で、図９の操作９２１に、「開く」のボタンの横に、「承認する」ボタンを表示する処理を行っているが、処理履歴テーブル８０２において、過去に処理担当者が案件の処理を行った場合であれば、必ず表示をするようにしている。

そのため、第２の実施形態においては、これから処理を行おうとする処理担当者が過去に案件の処理を行っていたとしても、その後の工程の処理担当者により、処理を再度行わせるために差し戻し等の処理が行われて、再度、処理依頼が来た場合には、処理待ち一覧の案件においては、「承認する」のボタンの表示を行わないようにする、実施形態について説明を行う。

また、一定の期間過ぎた場合において、処理待ち一覧の案件においては、「承認する」のボタンの表示を行わないようにする、実施形態についても説明を行う。

まず始めに、第２の実施形態のワークフローの処理が行われるにあって必要となる前提条件を図１１から図１４において、説明を行う。

図１１は、第２の実施形態のワークフローの処理が行われるにあたって使用される組織情報を説明するための図である。なお、図１１の部門テーブル１１１１は図６の部門テーブル６１１、図１１のロールテーブル１１１２は図６のロールテーブル６１２、図１１のユーザテーブル１１１３は図６のユーザテーブル６１３、図１１の組織情報テーブル１１１４は図６の組織情報テーブル６１４とテーブルの構造については同一であることとする。そのため詳細な説明は省略する。

なお、図１１の組織１１２１は、組織情報テーブル１１１４を階層構造で表現した組織図であり、図６の組織６２１と同様な構造となる。なお、第２の実施形態においては、組織情報テーブル１１１４に、ユーザＩＤ＝Ｕ００４、ロールＩＤ＝Ｒ００３、部門ＩＤ＝Ａ００１に所属するユーザである木屋野勘太郎を追加したため、これにともない、ユーザＩＤがＵ００４の木屋野勘太郎が、部門ＩＤがＡ００１に、ロールＩＤがＲ００４で所属をしている状況を、組織１１２１の中の、１１２１で図示する階層で図示することとする。

図１２は、第１の実施形態における図５の定義情報５００の業務５０１、プロセス５０２、アクティビティ５０３の情報をテーブル構造で説明可能な図である。また、図１２の業務テーブル１２０１は図７の業務テーブル７０１、図１２のプロセステーブル１２０２は図７のプロセステーブル７０２、図１２のアクティビティテーブル１２０３は図７のアクティビティテーブル７０３、とテーブルの構造については同一であることとする。そのため詳細な説明は省略する。

なお、図１２のプロセス定義１２０４は、プロセステーブル１２０２とアクティビティテーブル１２０３の情報をもとに、実際のプロセスを分かりやすく図示したものであり、図７のプロセス定義７０４と同様な構造となる。なお、図１２のプロセス定義１２０４−１は図７のプロセス定義７０４の７０４−１、図１２のプロセス定義１２０４−２は図７のプロセス定義７０４の７０４−２は、図１２のプロセス定義１２０４−３は図７のプロセス定義７０４の７０４−３、の設定値と同じこととする。

なお、第２の実施形態においては、アクティビティテーブル１２０３において、番号が３番目のアクティビティを追加する。そのため、図１２の１２０４−４のアクティビティに図示するように、担当ロールがＲ００４の社長で処理を行うアクティビティが追加されることになる。

図１３は、第１の実施形態における図５の案件情報５１０の案件５１１、処理履歴５１２の情報をテーブル構造で説明する図である。また、図１３の案件テーブル１３０１は図８の案件テーブル８０１、図１３の処理履歴テーブル１３０２は図８の処理履歴テーブル８０２、とテーブルの構造については同一であることとする。そのため詳細な説明は省略する。

図１４の、処理履歴１４００は、処理履歴テーブル１３０２の処理履歴の状況を、案件ＩＤ＝０００００００４、案件ＩＤ＝０００００００５、に関して図示した図である。

図１５の処理待ち案件表示画面１５００は、ワークフローで申請がされた案件で、処理担当者へ処理依頼がされた案件の一覧を表示する処理待ち案件表示画面の一例を示す図である。

なお、図１５の９２１〜９３３、９５０の各機能、各項目は、第１の実施形態の図９の本発明における処理待ち案件表示画面９２０において同一の番号がふられている機能、項目と同じものであるとする。そのため各機能、各項目の詳細な説明については省略する。なお、図１５の９５２、９５３のボタンは、案件の内容確認を確認するための処理画面を開くための機能を有する。

図１６の表示日数管理テーブル１６００は、過去に承認した案件に対し処理待ち一覧で「承認」ボタンの機能を表示可能とする日数について管理するテーブルであり、表示日数１６０１によりその日数を管理する。なお、表示日数管理テーブル１６１０は、表示日数管理テーブル１６００と同じテーブルである。表示日数１６１１も、表示日数１６０１と同じ項目であることとする。

続いて、図１０を用いて、本実施形態のワークフローシステムにおける処理待ち一覧である、図１５の処理待ち案件表示画面１５００を表示する第２の実施形態の処理について説明する。

ワークフローシステムにおける処理担当者はログイン画面（不図示）に処理担当者自身のユーザＩＤとパスワードを入力しシステムの利用を開始することとする。

また、処理担当者がワークフロークライアントの「処理待ち一覧」ボタン（不図示）を押下すると、本処理がワークフローサーバ１０１のＣＰＵ２０１にて実施され、処理待ち一覧（図１５の処理待ち案件表示画面１５００）がワークフロークライアントに表示されることとする。

ステップＳ１００１では、処理履歴テーブル１３０２を参照し、「状態」が「処理待ち」で、かつ、「担当者ＩＤ」が、処理担当者がシステムの利用を開始する際に入力したユーザＩＤと一致するものを抽出する。

例えば、本処理においては、処理履歴テーブル１３０２のうち、状態が「処理待ち」であって、担当者ＩＤが、Ｕ０００のデータを抽出することとする。

抽出した各処理待ちのデータについて、後述のＳ１００２からＳ１００９のステップを繰り返し実施する。

ステップＳ１００２は、処理待ち一覧の図１５の９２２から９２５、９２７から９２９の各
項目の値を表示するステップである。各項目の値については、第１の実施形態の図９の各項目の説明でした方法で値を取得する方法と同様であることとする。そのため、説明は省略する。

ステップＳ１００３は、処理待ち案件表示画面１５００の各案件の役割９２６に表示を行う役割名を求めるステップである。なお、本ステップについては、第１の実施形態のステップＳ４０３と同様の処理と同様であるため、説明は省略する。

ステップＳ１００４は、利用者が過去に承認したかを判定するステップである。

処理履歴テーブル１３０２の中で、以下（１）〜（３）の条件にすべて該当する案件の「レコードが存在する場合、その案件のレコードは過去に承認したと判定することとする。
（１）処理履歴テーブル１３０２の案件ＩＤが、ステップＳ１００１で処理履歴テーブル１３０２より抽出した案件の案件ＩＤと一致
（２）処理履歴テーブル１３０２の担当者ＩＤが、ワークフローシステムへログインを開始するときに、処理担当者が入力したユーザＩＤと一致
（３）処理履歴テーブル１３０２の状態が処理済みである

ステップＳ１００４で、処理対象の案件が過去に承認した案件ではないと判定した場合、ステップＳ１００９で、図１５の操作９２１に、「開く」ボタンを表示する処理を行う。

例えば、第１の実施形態と同様に、ステップＳ１００１で抽出したレコードの中の、案件ＩＤが０００００００１と０００００００３のレコードには、担当者ＩＤが「Ｕ０００」であって、状態が「処理済み」のレコードが存在しないため、このレコードを処理待ち案件表示画面１５００に表示する場合は、操作９２１に「開く」のボタンを表示する。なお、ここではボタンとしているが、ボタンではなくリンクが張られるようにしても良いこととする。

ステップＳ１００４で、処理対象の案件が過去に承認した案件であると判定した場合、ステップＳ１００５へ処理を進める。

ステップＳ１００５は、処理対象の案件が、差し戻しされ、かつ、差し戻しよりも後に、処理待ちの処理担当者が承認している、処理履歴が存在するか否かを判定する。

すなわち、案件において過去に承認した履歴が存在するが、その後の工程から、いずれかの工程に対し差し戻しされ処理履歴があり、かつ、その差し戻しされた処理履歴よりも後に処理担当者が承認しているかを判定するステップである。

例えば、ステップＳ１００１で処理履歴テーブル１３０２より抽出したレコードの中の、案件ＩＤが０００００００４のレコードには、担当者ＩＤが「Ｕ０００」であって、状態が「処理済み」のレコードである、１３１０、１３１１のレコードが存在しているため、ステップＳ１００４では、処理対象の案件が過去に承認した案件であると判定し、ステップＳ１００５へ処理を進める。

案件ＩＤが０００００００４に関しては、状態が「処理済み（差戻し）」となっている、１３１２のレコードが存在している。しかし、担当者ＩＤが「Ｕ０００」であって、状態が「処理済み（承認）」のレコードは、１３１２よりも後に発生する処理履歴には存在しない。すなわち、ステップＳ１００５において、処理対象の案件が、差し戻しされ、かつ、差し戻しよりも後に、処理待ちの処理担当者が承認している、処理履歴が存在しない（ステップＳ１００５においてＮＯ）と判定し、ステップＳ１００９へ処理を進める。

ステップＳ１００９においては、ステップＳ１００９の処理を通る案件を、処理待ち一覧から処理画面を開くことにより確認できるようにするための、図１５の操作９２１に図示する「開く」ボタンを表示する処理を行う。なお、ここではボタンとしているが、ボタンではなくリンクが張られるようにしても良いこととする。

以上により、これから処理を行おうとする処理担当者が過去に案件の処理を行っていたとしても、その後の工程の処理担当者により、処理を再度行わせるためにいずれかの工程に対し差戻しの処理が行われて、再度、処理依頼が来た場合には、処理待ち一覧の案件においては、「承認」のボタンの表示をせず、「開く」ボタンのみを表示をすることにより、案件の申請内容を処理画面において確認を行ってから処理を行うことが可能になる。すなわち、単純に、過去に処理を行った履歴が存在した場合に、「承認」ボタンを表示することを回避することが可能となる。

ステップＳ１００５において、処理対象の案件が、差し戻しされ、かつ、差し戻しよりも後に、処理待ちの処理担当者が承認している、処理履歴が存在する（ステップＳ１００５においてＹＥＳ）と判定した場合、ステップＳ１００６へ処理を進める。

例えば、ステップＳ１００１で処理履歴テーブル１３０２より抽出したレコードの中の、案件ＩＤが０００００００５のレコードには、担当者ＩＤが「Ｕ０００」であって、状態が「処理済み」のレコードである、１３１３、１３１４、１３１６のレコードが存在しているため、ステップＳ１００４では、処理対象の案件が過去に承認した案件であると判定し、ステップＳ１００５へ処理を進める。

また、案件ＩＤが０００００００５に関しては、状態が「処理済み（差戻し）」となっている、１３１５のレコードが存在している。かつ、担当者ＩＤが「Ｕ０００」であって、状態が「処理済み（承認）」のレコードは、状態が「処理済み（承認）」である１３１６のレコードが、１３１５よりも後に発生する処理履歴に存在する。すなわち、ステップＳ１００５において、処理対象の案件が、差し戻しされ、かつ、差し戻しよりも後に、処理待ちの処理担当者が承認している、処理履歴が存在する（ステップＳ１００５においてＹＥＳ）と判定し、ステップＳ１００６へ処理を進める。

ステップＳ１００６は、処理対象の案件が、承認依頼から、一定時間経過しているか否かを判定する。図１６の、表示日数管理テーブル１６００は、過去に承認した案件に対し処理待ち一覧で「承認」ボタンの機能を表示可能とする日数について管理するテーブルであり、表示日数１６０１によりその日数を管理する。例えば、図１６の表示日数管理テーブル１６００においては、その日数は、７日間と設定されている。

処理待状態である、案件ＩＤが０００００００５の案件を処理担当者の処理待ち案件表示画面で表示をした日付が「２０１５／７／１４」であったとすると、１３１７のレコードが、状態＝「処理待ち」として作成された時点、すなわち、１３１６のレコードが、状態＝「処理済み（承認）」となった時点である「２０１５／７／４」から、「２０１５／７／１４」までの間は１０日間ということになり、表示日数管理テーブル１６００で管理される表示日数１６０１を超えているため、処理待ち一覧においては「承認ボタン」は表示しない。

なお、過去に承認した案件に対し処理待ち案件表示画面で「承認」ボタンの機能を表示可能とする日数が、表示日数管理テーブル１６１０（表示日数管理テーブル１６００と同様のテーブル）において、表示日数１６１１において、１２日間と登録されている場合の、処理待状態である、案件ＩＤが０００００００５の処理待ち案件表示画面における承認ボタンの表示について説明する。

処理待状態である、案件ＩＤが０００００００５の案件を処理担当者の処理待ち一覧で表示をした日付が「２０１５／７／１４」であったとすると、１３１７のレコードが、状態＝「処理待ち」として作成された時点、すなわち、１３１６のレコードが、状態＝「処理済み（承認）」となった時点である「２０１５／７／４」から、「２０１５／７／１４」までの間は１０日間ということになるため、表示日数管理テーブル１６１０で管理される表示日数１６１１を超えていないため、処理待ち一覧においては「承認」ボタンは表示する。

ステップＳ１００７においては、ステップＳ１００７の処理を通る案件を、処理待ち一覧から処理画面を開かなくても承認できるようにするための、図１５の操作９２１に図示する「承認」ボタンを表示する処理を行う。すなわち、抽出した処理待ちの状態の案件が、処理担当者が直近の過去に処理してから、当該処理担当者の処理待ちの状態となるまでの間に、差戻しされたか否かによって、処理待ち案件表示画面における処理待ちの状態の案件を承認することを可能とする承認ボタンの表示制御を行う。

例えば、案件ＩＤが「０００００００５」の案件は、図１５の案件９６１で図示すように、承認ボタン９５０が処理待ち案件表示画面において表示される。なお、ここではボタンとしているが、ボタンではなくリンクが張られるようにしても良いこととする。

ステップＳ１００８において、図１５の備考９３０において、過去に承認した役割と過去に承認した日時が分かるコメントを表示する。

例えば、図１５の案件ＩＤが「０００００００５」の案件９６１は、図１５の９７０に図示するように、「課長として２０１４／０７／０４に承認した案件です」と表示している。

「課長として２０１４／０７／０４に承認した案件です」の文言のうち、「課長」の部分は、処理担当者が過去に処理した１３１６のレコードに紐づくロールの名称が表示される。なお、紐づくとは、処理を行ったアクティビティにおける役割ということである。すなわち、処理担当者が処理したときのロールの名称が表示される。

方法としては、処理履歴テーブル１３０２の１３１６のレコードの「アクティビティＩＤ」を元に、アクティビティテーブル１２０３を参照し、処理担当者指定として指定されている「担当ロールＩＤ」を求める。更に、「担当ロールＩＤ」より、ロールテーブル１１１２を参照し、「ロール名」を求める。この「ロール名」を図１５の９３０で表示する文面に使用する。

例えば、処理履歴テーブル１３０２の案件ＩＤ＝０００００００５（担当者ＩＤが「Ｕ０００」で状態が「処理待ち（承認）」）の１３１６のレコードは、アクティビティＩＤがａｃｔ００１であり、そのアクティビティＩＤより、担当ロールＩＤをアクティビティテーブル１２０３より求めると、Ｒ００１となる。そのロール名（役割）をロールテーブル１１１２から求めるとロール名として「課長」が求められ、それを表示する。

また、２０１４／０７／０４の部分は、処理履歴上、差戻しが行われた後に、再度、処理担当者が過去に処理した日付すなわち、１３１６のレコードの処理日の値を表示する。

ステップＳ１００８の処理が終了したあとは、処理待ち一覧から処理画面を開くことにより確認できるようにするための、図１５の操作９２１に図示する「開く」ボタンも表示するため、ステップＳ１００９の処理を行う。

例えば、案件ＩＤが「０００００００４」の案件においては、図１５の案件９６０で図示すように、図１５の開くボタン９５２が処理待ち案件表示画面において表示する。

また、案件ＩＤが「０００００００５」の案件においては、図１５の案件９６１で図示すように、図１５の開くボタン９５３が処理待ち案件表示画面において表示する。

なお、これらの「開く」や、「承認」の機能は、ボタンにより実現するとしているが、ボタンではなくリンクが張られるようにしても良いこととする。

なお、第２の実施形態におけるステップＳ１００６の分岐は、第１の実施形態のステップＳ４０６の前の処理入れても良いこととする。この場合の、ステップＳ１００６において、処理対象の案件が、承認依頼から、一定時間経過している場合、ステップＳ４０５へ処理を進め、処理対象の案件が、承認依頼から、一定時間経過していない場合は、ステップＳ４０６へ処理を進めることとする。

以上により、処理担当者が直近の過去に処理を行った時点から、再度処理を行う時点までの間に、差戻しの処理が存在した状態で、再度、当該処理担当者へ案件の処理依頼が来た場合、当該処理担当者は処理画面において対象の案件の内容を確認してから案件の処理を行うことが可能になる。

また、差戻しの処理が、処理担当者の直近の過去に処理を行った時点から、再度処理を行う時点までの間に存在しない場合は、直近に処理を行った処理案件の内容を処理画面において確認を行うことなく、処理待ち案件表示画面から処理を行うことが可能になる。

更に、過去に処理を行っていたとしても、処理待ち状態となってから一定時間経過した案件に対しては、処理待ち一覧においてにおいて、承認ボタンの表示を行わないため、必ず案件の内容を処理画面において確認をしながら処理を行うことが可能になる。
＜第３の実施形態＞

続いて、第３の実施形態について説明を行う。第３の実施形態においては、ワークフローのプロセス定義における特定のアクティビティに対し、処理待ち一覧から「承認」を行うことを可能としている場合の処理待ち一覧の「承認ボタン」の機能について説明を行う。なお、実施形態の処理の内容としては、ワークフローのプロセス定義におけるあるアクティビティの処理担当者が、他のアクティビティの処理担当者へ案件を差戻したことがあり、再度、処理待ち一覧から「承認」を行うことを可能とするアクティビティの処理担当者へ案件の承認依頼が来た場合、処理待ち一覧に「承認ボタン」を表示しないようにする、という内容になる。

また、第２の実施形態と同じく、一定の期間過ぎた場合において、処理待ち一覧の案件においては、「承認する」のボタンの表示を行わないようにする。

まず始めに、第３の実施形態のワークフローの処理が行われるにあたって必要となる前提条件について説明を行う。

第３の実施形態のワークフローの処理が行われるにあたって使用される組織情報は、第２の実施形態で使用している、図１１の部門テーブル１１１１、ロールテーブル１１１２、ユーザテーブル１１１３、組織情報テーブル１１１４を使用することとする。

また、第３の実施形態のワークフローの処理が行われ案件が生成されるための必要となるテーブルの情報は、第２の実施形態で使用している、図１２の業務テーブル１２０１、図１２のプロセステーブル１２０２、を使用することとする。

なお、第１の実施形態において、図７のアクティビティテーブル７０３、第２の実施形態において、図１２のアクティビティテーブル１２０３として使用しているテーブルの情報は、第３の実施形態においては、図２２のアクティビティテーブル２２００を使用することとする。

図２２のアクティビティテーブル２２００は、図２３のアクティビティ２３０３の情報をテーブル構造で説明した図である。

なお、図２３は、ワークフローの設計情報である定義情報と、実際にその定義情報を利用して申請がされた案件である案件情報の関係を示す図である。なお、図２３の業務２３０１は図５の業務５０１、図２３のプロセス２３０２は図５のプロセス５０２は、図２３の案件２３１１は図５の案件５１１、図２３の処理履歴２３１２は図５の処理履歴５１２と定義は同一であることとする。したがって、詳細についての説明は、省略する。

また、図２３のアクティビティ２３０３については、図２３のアクティビティ２３０３のアクティビティＩＤは図５のアクティビティ５０３のアクティビティＩＤ、図２３のアクティビティ２３０３のプロセスＩＤは図５のアクティビティ５０３のプロセスＩＤ、図２３のアクティビティ２３０３の番号は図５のアクティビティ５０３の番号、図２３のアクティビティ２３０３の担当ロールＩＤは図５のアクティビティ５０３の担当ロールＩＤ、と同じであるとする。

なお、図２３のアクティビティ２３０３の承認ボタン機能は、図２１の処理待ち案件表示画面２１００に示す、ワークフローにおける処理待ち状態となっている案件の一覧を表示するにおいて一覧画面において、案件を、９５２の「開く」ボタンを押下し、処理理画面を開いて内容を確認しながら承認を行うのではなく、案件を選択状態にし、９５０の「承認」ボタンを押下することによって承認を行うことを可能とするための許可フラグを管理する。

アクティビティテーブル２２００は、案件が誰にどの順番で処理されるのかを定義したプロセス定義の各処理の処理担当者の情報が登録される。また、アクティビティテーブル２２００のアクティビティＩＤは、アクティビティテーブル７０３のアクティビティＩＤ、アクティビティテーブル２２００のプロセスＩＤは、アクティビティテーブル７０３のプロセスＩＤ、アクティビティテーブル２２００の番号は、アクティビティテーブル７０３の番号、アクティビティテーブル２２００の担当ロールＩＤは、アクティビティテーブル７０３の担当ロールＩＤ、と同じ項目であることとする。なお、第３の実施形態においては、新たに、承認ボタン機能という項目を保持することとする。

承認ボタン機能とは、図２１の処理待ち案件表示画面２１００に示す、ワークフローにおける処理待ち状態となっている案件の一覧を表示するにおいて一覧画面において、案件を、９５２の「開く」ボタンを押下し、処理理画面を開いて内容を確認しながら承認を行うのではなく、選択した案件を、９５０の「承認」ボタンを押下することによって承認を行うことを可能とするための許可フラグを管理する。

また、プロセス定義については、図１８のプロセス定義１８００を使用することとする。図１８の１８０４−１のアクティビティは図１２の１２０４−１のアクティビティ定義、図１８の１８０４−２のアクティビティは図１２の１２０４−２のアクティビティ定義、のアクティビティ定義、と同じこととする。

なお、図１８の１８０４−３のアクティビティ定義は、処理担当者の指定は、担当ロールが「部長」であり、ここまでは、図１２の１２０４−３のアクティビティ定義と同じであるとするが、第３の実施形態において、「承認ボタン機能可」という属性を持たせることにする。この「承認ボタン機能可」の属性は、アクティビティテーブル２２００の該当するアクティビティＩＤの、承認ボタン機能が「可」に設定されていることにより、保持することになる。例えば、プロセス定義１８００の１８０４−３のアクティビティの場合、アクティビティテーブル２２００においては、アクティビティＩＤが「ａｃｔ００２」のレコードが該当するアクティビティの情報であり、そのレコードの承認ボタン機能が「可」に設定されていることにより、そのような属性を保持することになる。

また、アクティビティテーブル１２０３において、番号が４番目のアクティビティを追加する。そのため、図１８の１８０４−４のアクティビティに図示するように、担当ロールがＲ００３の社長で処理を行うアクティビティが追加されることになる。

第３の実施形態において、ワークフローにおいて申請がされた案件のデータの情報を登録するために必要となるテーブルの情報は、第２の実施形態で使用している、図１３の案件テーブル１３０１、を使用することとする。

図１９は、第１の実施形態における、処理履歴５１２の情報をテーブル構造で説明する図である。また、図１９の処理履歴テーブル１９００は図８の処理履歴テーブル８０２、とテーブルの構造については同一であることとする。そのため詳細な説明は省略する。

図２０の、処理履歴２０００は、処理履歴テーブル１９００の処理履歴の状況を各案件（案件ＩＤ＝０００００００４、案件ＩＤ＝０００００００５）ごとに図示した図である。

図２１の処理待ち案件表示画面２１００は、ワークフローで申請がされた案件で、処理担当者へ処理依頼がされた案件の一覧を表示する処理待ち案件表示画面の一例を示す図である。

なお、図２１の９２１〜９３３、９５０の各機能、各項目は、第１の実施形態の図９の本発明における処理待ち案件表示画面９２０において同一の番号がふられている機能、項目と同じものであるとする。そのため各機能、各項目の詳細な説明については省略する。なお、図２１の９５２、９５３のボタンは、案件の内容確認を確認するための処理画面を開くための機能を有する。

続いて、図１７を用いて、本実施形態のワークフローシステムにおける処理待ち一覧である、図２１の処理待ち案件表示画面２１００を表示する第３の実施形態の処理について説明する。

ワークフローシステムにおける処理担当者はログイン画面（不図示）に処理担当者自身のユーザＩＤとパスワードを入力しシステムの利用を開始することとする。

また、処理担当者がワークフロークライアントの「処理待ち一覧」ボタン（不図示）を押下すると、本処理がワークフローサーバ１０１のＣＰＵ２０１にて実施され、処理待ち一覧（図２１の処理待ち案件表示画面２１００）がワークフロークライアントに表示されることとする。

ステップＳ１７０１では、処理履歴テーブル１９００を参照し、「状態」が「処理待ち」で、かつ、「担当者ＩＤ」が、処理担当者がシステムの利用を開始する際に入力したユーザＩＤと一致するものを抽出する。

例えば、本処理においては、処理履歴テーブル１９００のうち、状態が「処理待ち」であって、担当者ＩＤが、Ｕ０００のデータを抽出することとする。

抽出した各処理待ちのデータについて、後述のＳ１７０２からＳ１７１０のステップを繰り返し実施する。

ステップＳ１７０２は、図２１、処理待ち案件表示画面２１００の９２２から９２５、９２７から９２９の各項目の値を表示するステップである。各項目の値については、第１の実施形態の図９の各項目の説明でした方法で値を取得する方法と同様であることとする。

ステップＳ１７０３は、処理待ち案件表示画面２１００の各案件の役割９２６に表示を行う役割名を求めるステップである。なお、本ステップについては、第１の実施形態のステップＳ４０３の処理と同様であるため、説明は省略する。

ステップＳ１７０４は、処理対象の処理待ち案件に紐づくアクティビティに、承認ボタン機能が使用可能な設定がされているか否かを判定する。ステップＳ１７０４で、処理対象の処理待ち案件に紐づくアクティビティに、承認ボタン機能が使用可能な設定がされている場合（ステップＳ１７０４でＹＥＳの場合）は、ステップＳ１７０５へ処理を進め、処理対象の処理待ち案件に紐づくアクティビティに、承認ボタン機能が使用可能な設定がされていない場合（ステップＳ１７０４でＮＯの場合）は、ステップＳ１７１０へ処理を進める。

例えば、本実施形態においてワークフローの起案が、図１８のプロセス定義１８００をもとに動作しているものとすると、１８１０−３のａｃｔ００２のアクティビティは、処理担当者の指定は、部長の役割が指定されていて、さらに、「承認ボタン機能」が可となっているため、承認ボタン機能が使用可能な設定がされていることになる。なお、この情報は、本実施形態で使用されるプロセス定義の各処理（アクティビティ）の処理担当者の情報を、アクティビティ単位でアクティビティテーブル２２００の承認ボタン機能の項目において情報を管理するが、アクティビティＩＤ＝ａｃｔ００２の場合、承認ボタン機能は「可」となっているため、このアクティビティにおいて案件が処理待ちの状態となった場合は、処理待ち一覧において表示がされる処理待ちの案件に対して、承認ボタン機能を付加することになる。なお、この承認ボタン機能が「不可」になっている場合は、処理待ち一覧において表示がされる処理待ちの案件に対してこの機能は付加されない。

ステップＳ１７０５は、利用者が過去に承認したかを判定するステップである。

処理履歴テーブル１９００の中で、以下（１）〜（３）の条件にすべて該当する案件の「レコードが存在する場合、その案件のレコードは過去に承認したと判定することとする。
（１）処理履歴テーブル１９００の案件ＩＤが、ステップＳ１７０１で処理履歴テーブル１９００より抽出した案件の案件ＩＤと一致
（２）処理履歴テーブル１９００の担当者ＩＤが、ワークフローシステムへログインを開始するときに、処理担当者が入力したユーザＩＤと一致
（３）処理履歴テーブル１９００の状態が処理済みである

ステップＳ１７０５で、処理対象の案件が過去に承認した案件であると判定した場合（ステップＳ１７０５でＹＥＳの場合）、ステップＳ１７０６へ処理を進める。ステップＳ１７０５で、処理対象の案件が過去に承認していない案件であると判定した場合（ステップＳ１７０５でＮＯの場合）、ステップＳ１７０７へ処理を進める。

例えば、ステップＳ１７０１で処理履歴テーブル１９００より抽出したレコードの中に、案件ＩＤが「０００００００４」、担当者ＩＤが「Ｕ０００」、状態が「処理待ち」の１９１０のレコードが存在するが、案件ＩＤが「０００００００４」、担当者ＩＤが「Ｕ０００」、状態が「処理済み」のレコードは、１９１１、１９１２の２件のレコードが存在する。このため、１９１０の処理履歴の状態（アクティビティＩＤが「ａｃｔ００２」において状態が「処理待ち」）においては、案件ＩＤが「０００００００４」の案件は過去に承認した案件であると判定する。

ステップＳ１７０６において、処理対象の案件が、差し戻しされた処理履歴が存在するか否かを判定する。ステップＳ１７０６において、処理対象の案件が、差し戻しされた処理履歴が存在すると判定した場合（ステップＳ１７０６においてＹＥＳ）、ステップＳ１７１０へ処理を進める。ステップＳ１７０６において、処理対象の案件が、差し戻しされた処理履歴が存在しないと判定した場合（ステップＳ１７０６においてＮＯ）、ステップＳ１７０７へ処理を進める。

なお、本処理の説明においては、差し戻しされた処理履歴の存在の確認は、過去に処理を行ったとされる処理履歴の中より処理された日時が一番近いものから、処理待ちの状態の履歴のまでの履歴中に存在するか否かによって確認することとする。なお、別の方法として、差し戻しされた処理履歴の存在の確認を、全ての処理履歴において存在するか否かを確認する方法をとっても良いこととする。

例えば、案件ＩＤが「０００００００４」は、アクティビティＩＤが「ａｃｔ００２」において状態が「処理待ち」になっていて、この処理を行うのは、担当者ＩＤが「Ｕ０００」であることが、１９１０の処理履歴のレコードより分かるが、この担当者ＩＤが「Ｕ０００」が過去に承認を行った履歴としては、案件ＩＤが「０００００００４」、担当者ＩＤが「Ｕ０００」、状態が「処理済み」の１９１１と、１９１２のレコードが存在する。この中において、過去に処理を行ったとされる処理履歴の中より処理された日時が近いものは、１９１２のレコードになる。この１９１２のレコードから、状態が「処理待ち」の１９１０のレコードまでの間において、差戻しされた履歴は、１９１３のレコードとして存在する（案件ＩＤが「０００００００４」、アクティビティＩＤが「ａｃｔ００３」担当者ＩＤが「Ｕ００４」、状態が「処理済み（差戻し）」）。

したがって、ステップＳ１７０６において、処理対象の案件が、差し戻しされた処理履歴が存在すると判定したため、ステップＳ１７１０へ処理を進める。

続いて、ステップＳ１７０６において、処理対象の案件が、差し戻しされた処理履歴が存在しないと判定する案件の処理履歴のケースについて説明を行う。

例えば、ステップＳ１７０１で処理履歴テーブル１９００より抽出したレコードの中に、案件ＩＤが「０００００００５」、担当者ＩＤが「Ｕ０００」、状態が「処理待ち」の１９２０のレコードが存在するが、案件ＩＤが「０００００００５」、担当者ＩＤが「Ｕ０００」、状態が「処理済み」のレコードは、１９２１、１９２２、１９２３の３件のレコードが存在する。このため、１９２０の処理履歴の状態（アクティビティＩＤが「ａｃｔ００２」において状態が「処理待ち」）においては、案件ＩＤが「０００００００５」の案件は過去に承認した案件であると、ステップＳ１７０５において、判定する。

続いて、この場合における、ステップＳ１７０６における処理対象の案件が、差し戻しされた処理履歴が存在しないと判定するか否かの判定について説明を行う。

例えば、案件ＩＤが「０００００００５」は、アクティビティＩＤが「ａｃｔ００２」において状態が「処理待ち」になっていて、この処理を行うのは、担当者ＩＤが「Ｕ０００」であることが、１９２０の処理履歴のレコードより分かるが、この担当者ＩＤが「Ｕ０００」が過去に承認を行った履歴としては、案件ＩＤが「０００００００４」、担当者ＩＤが「Ｕ０００」、状態が「処理済み」の１９２１、１９２２、１９２３の３つのレコードが存在する。この中において、過去に処理を行ったとされる処理履歴の中より処理された日時が近いものは、１９２３のレコードになる。

なお、この１９２３のレコードから、状態が「処理待ち」の１９２０のレコードまでの間において、差戻しされた履歴は存在しない。したがって、ステップＳ１７０６において、処理対象の案件が、差し戻しされた処理履歴が存在しないと判定したため、ステップＳ１７０７へ処理を進める。

ステップＳ１７０７においては、処理対象の案件が、承認依頼から、一定時間経過しているか否かを判定する。なお、処理は、第２の実施形態におけるステップＳ１００６の処理と同じ考え方による方法で行うものとするため、処理の詳細についての説明は省略する。

ステップＳ１７０７において、処理対象の案件が、承認依頼から、一定時間経過していると判定した場合、ステップＳ１７１０へ処理を進める。また、ステップＳ１７０７において、処理対象の案件が、承認依頼から、一定時間経過していないと判定した場合、ステップＳ１７０８へ処理を進める。

ステップＳ１７０８においては、ステップＳ１７０８の処理を通る案件を、処理待ち一覧から処理画面を開かなくても承認できるようにするための、図２１の操作９２１に図示する承認ボタンを表示する処理を行う。すなわち、抽出した処理待ちの状態の案件が、処理担当者が直近の過去に処理してから、当該処理担当者の処理待ちの状態となるまでの間に、差戻しされたか否かによって、処理待ち案件表示画面における処理待ちの状態の案件を承認することを可能とする承認ボタンの表示制御を行う。

例えば、案件ＩＤが「０００００００５」の案件は、図２１の案件９６１で図示すように、承認ボタン９５０が処理待ち案件表示画面において表示される。なお、ここではボタンとしているが、ボタンではなくリンクが張られるようにしても良いこととする。

ステップＳ１７０９において、図２１の備考９３０において、過去に承認した役割と過去に承認した日時が分かるコメントを表示する。

例えば、図２１の案件ＩＤが「０００００００５」の案件９６１は、図２１の９７０に図示するように、「課長として２０１４／０７／０４に承認した案件です」と表示している。

「課長として２０１５／０７／０４に承認した案件です」の文言のうち、「課長」の部分は、処理担当者が過去に処理した１９２３のレコードに紐づくロールの名称が表示される。なお、紐づく役割とは、処理を行ったアクティビティにおける役割ということである。すなわち、処理担当者が処理したときのロールの名称が表示される。

方法としては、処理履歴テーブル１９００の１９２３のレコードの「アクティビティＩＤ」を元に、アクティビティテーブル２２００を参照し、処理担当者指定として指定されている「担当ロールＩＤ」を求める。更に、「担当ロールＩＤ」より、ロールテーブル１１１２を参照し、「ロール名」を求める。

例えば、処理履歴テーブル１９００の案件ＩＤ＝０００００００５（担当者ＩＤが「Ｕ０００」で状態が「処理待ち（承認）」）の１９２３のレコードは、アクティビティＩＤがａｃｔ００１であり、そのアクティビティＩＤより、担当ロールＩＤをアクティビティテーブル１２０３より求めると、Ｒ００１となる。そのロール名（役割）をロールテーブル１１１２から求めるとロール名として「課長」が求められ、それを表示する。

また、２０１４／０７／０４の部分は、処理担当者が過去処理した日付すなわち、１９２３のレコードの処理日の値を表示する。

ステップＳ１７０９の処理が終了したあとは、処理待ち一覧から処理画面を開くことにより確認できるようにするための、図２１の操作９２１に図示する「開く」ボタンも表示するため、ステップＳ１７１０の処理を行う。

ステップＳ１７１０において、ステップＳ１７１０の処理を通る案件を、処理待ち一覧から処理画面を開くことにより確認できるようにするための、図２１の操作９２１に図示する「開く」ボタンを表示する処理を行う。

例えば、案件ＩＤが「０００００００４」の案件においては、図２１の案件９６０で図示すように、図２１の開くボタン９５２が処理待ち案件表示画面２１００において表示される。また、案件ＩＤが「０００００００５」の案件においては、図２１の案件９６１で図示すように、図２１の開くボタン９５３が処理待ち案件表示画面２１００において表示される。

なお、れらの「開く」や、「承認」の機能は、ここではボタンとしているが、ボタンではなくリンクが張られるようにしても良いこととする。

以上により、処理担当者が直近の過去に処理を行った時点から、再度処理を行う時点までの間に、差戻しの処理が存在した状態で、再度、当該処理担当者へ案件の処理依頼が来た場合、当該処理担当者は処理画面において対象の案件の内容を確認してから案件の処理を行うことが可能になる。

また、差戻しの処理が、処理担当者の直近の過去に処理を行った時点から、再度処理を行う時点までの間に存在しない場合は、直近に処理を行った処理案件の内容を処理画面において確認を行うことなく、処理待ち案件表示画面から処理を行うことが可能になる。

更に、過去に処理を行っていたとしても、処理待ち状態となってから一定時間経過した案件に対しては、処理待ち一覧においてにおいて、承認ボタンの表示を行わないため、必ず案件の内容を処理画面において確認をしながら処理を行うことが可能になる。

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

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

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

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

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

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

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

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

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

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

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

本発明は、同一の処理担当者により再度処理が行われるワークフローシステムにおいて、前記ワークフローシステムにおいて申請された案件の処理を行う単位であるアクティビティの単位で処理の状況を処理履歴として記憶する処理履歴記憶手段と、前記案件の処理担当者の処理待ちの状態である案件を前記処理履歴記憶手段より抽出する処理待ち案件抽出手段と、前記処理待ち案件抽出手段によって抽出した処理待ちの状態の案件を前記処理担当者の処理待ち案件表示画面において表示する表示処理手段と、前記表示処理手段により前記処理待ち案件表示画面において表示する前記処理待ち案件抽出手段によって抽出した処理待ちの状態の案件のうち、当該案件の処理担当者が過去に承認した案件を対象に、案件を処理する処理画面を開かず前記処理待ち案件表示画面において、承認することを可能とする承認手段とを備えることを特徴とする。

Claims (8)

1. 同一の処理担当者が再度処理を行うことによって処理を進めることを可能とするワークフローシステムにおいて、
   前記ワークフローシステムにおいて申請された案件の処理を行う単位であるアクティビティごとの処理の状況を処理履歴として記憶する処理履歴記憶手段と、
   前記案件の処理担当者の処理待ちの状態である案件を前記処理履歴記憶手段より抽出する処理待ち案件抽出手段と、
   前記処理待ち案件抽出手段によって抽出した処理待ちの状態の案件を前記処理担当者の処理待ち案件表示画面において表示する表示手段と、
   前記処理待ち案件抽出手段により抽出された処理待ちの状態の案件が、処理担当者が過去に処理してから、当該処理担当者の処理待ちの状態となるまでの間に、差戻しがされたか否かによって、前記処理待ちの状態の案件を、前記表示手段により表示する前記処理待ち案件表示画面において前記処理待ちの状態の案件を承認することを可能とする承認ボタンを表示制御する承認ボタン表示制御手段と
   を備えること
   を特徴とするワークフローシステム。
2. 前記承認ボタン表示制御手段は、前記処理待ち案件抽出手段により抽出した処理待ちの状態の案件が、処理担当者が直近の過去に処理してから、当該処理担当者の処理待ちの状態となるまでの間に、差戻しされたか否かによって、前記表示手段により表示する前記処理待ち案件表示画面において前記処理待ちの状態の案件を承認することを可能とする承認ボタンを表示制御する
   ことを特徴とする請求項１に記載のワークフローシステム。
3. 承認ボタン表示制御手段は、更に、処理担当者の処理待ち状態で前記承認ボタンを表示可能な案件が、前記処理待ちの状態になってから経過した時間に応じて前記承認ボタンを表示制御することを特徴とすること
   を特徴とする請求項１または２に記載のワークフローシステム。
4. 前記表示手段によって前記処理待ち案件表示画面に表示された案件に対し、前記処理担当者が当該案件を処理すべき役割を表示する役割表示手段と、
   前記表示手段によって前記処理待ち案件表示画面に表示された案件を、前記処理担当者が過去に処理したことがある場合に、当該処理担当者が前記処理待ちの状態の案件を過去に承認した時の役割と処理日時を識別可能に表示する過去処理識別表示手段と、
   を更に備える特徴とする請求項１に記載のワークフローシステム。
   を特徴とする請求項１乃至３のいずれか１項に記載のワークフローシステム。
5. 前記承認ボタン表示制御手段により前記処理待ち案件表示画面において承認ボタンが表示される複数の案件を一括して承認を行う一括承認手段
   を更に備えること
   を特徴とする請求項１乃至４いずれか１項に記載のワークフローシステム。
6. 前記一括承認手段は、前記承認ボタン表示制御手段により前記処理待ち案件表示画面において承認ボタンが表示される案件が複数ある場合、複数の当該案件より処理対象として選択された案件を一括して承認を行うことを可能とすること
   を特徴とする請求項５に記載のワークフローシステム。
7. ワークフローシステムにおいて申請された案件の処理を行う単位であるアクティビティごとの処理の状況を処理履歴として記憶する処理履歴記憶手段を有し、同一の処理担当者が再度処理を行うことによって処理を進めることを可能とするワークフローシステムの制御方法において、
   処理待ち案件抽出手段が、前記案件の処理担当者の処理待ちの状態である案件を前記処理履歴記憶手段より抽出する処理待ち案件抽出ステップと、
   表示手段が、前記処理待ち案件抽出ステップによって抽出した処理待ちの状態の案件を前記処理担当者の処理待ち案件表示画面において表示する表示ステップと、
   前記処理待ち案件抽出ステップにより抽出された処理待ちの状態の案件が、処理担当者が過去に処理してから、当該処理担当者の処理待ちの状態となるまでの間に、差戻しがされたか否かによって、前記処理待ちの状態の案件を、前記表示ステップにより表示する前記処理待ち案件表示画面において前記処理待ちの状態の案件を承認することを可能とする承認ボタンを表示制御する承認ボタン表示制御ステップと
   を含むこと
   を特徴とするワークフローシステムの制御方法。
8. ワークフローシステムにおいて申請された案件の処理を行う単位であるアクティビティごとの処理の状況を処理履歴として記憶する処理履歴記憶手段を有し、同一の処理担当者が再度処理を行うことによって処理を進めることを可能とするワークフローシステムにおいて実行可能なプログラムであって、
   前記案件の処理担当者の処理待ちの状態である案件を前記処理履歴記憶手段より抽出する処理待ち案件抽出手段と、
   前記処理待ち案件抽出手段によって抽出した処理待ちの状態の案件を前記処理担当者の処理待ち案件表示画面において表示する表示手段と、
   前記処理待ち案件抽出手段により抽出された処理待ちの状態の案件が、処理担当者が過去に処理してから、当該処理担当者の処理待ちの状態となるまでの間に、差戻しがされたか否かによって、前記処理待ちの状態の案件を、前記表示手段により表示する前記処理待ち案件表示画面において前記処理待ちの状態の案件を承認することを可能とする承認ボタンを表示制御する承認ボタン表示制御手段と
   として機能させることを特徴とするプログラム。

Images