JP4839086B2

JP4839086B2 - ワークフロー管理システム

Info

Publication number: JP4839086B2
Application number: JP2006003497A
Authority: JP
Inventors: 薫前田; 鈴木　　剛; ホルツハラルド; ロスタニンオーレグ
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2006-01-11
Filing date: 2006-01-11
Publication date: 2011-12-14
Anticipated expiration: 2026-01-11
Also published as: EP1818866A1; CN101000669B; US20070174342A1; US8219431B2; CN101000669A; JP2007188142A

Description

本発明は、組織をまたがる共同作業に適したワークフロー管理システムに関する。

図１は従来のワークフローモデルの例を示す図である。図１において、（ａ）は固定型のワークフローモデルの例を示したものであり、タスクＴ１〜Ｔ５で構成されるフロー全体はワークフロー定義として詳細部まで実行前に定義され、各タスク間の順序関係（矢印付きの実線で示す）も定義時に決定される。そして、実行時には、タスクの数および構成は変更しない。

実行者の割り当てとしては、事前にワークフロー定義がデザインされ、実行者はロールとして定義されており、行うべき作業内容は定義されている。実行時には、ロールに対応して人が割り当てられる。また、割り当てられた実行者にはメール等で通知が行われ、新たな実行者側では承諾・拒否を選択できる。

図１（ｂ）はＡＫＷ（Agile Knowledge Workflow）と呼ばれるワークフローモデルの例を示したものであり、子タスクの追加・削除によって、実行しながら部分的に詳細化（サブタスクへの再帰的分割）を行い、タスク間の親子関係、順序関係、入出力文書の依存性に基づくフロー制御を行っていくものである（参考：http://www.dfki.de/frodo/taskman/）。例えば、タスクＴ１と親子関係にあるタスクＴ２〜Ｔ４のうち、実行時にタスクＴ３をタスクＴ５、Ｔ６に詳細化するものである。タスク間の実行順序は親子関係および明示的な順序関係（先行タスク関係）によって決定される。図において矢印付きの破線は順序関係を示している。

実行者の割り当てとしては、実行時に子タスクが追加され、実行者が割り当てられる。実行者には作業の概要またはゴールだけが与えられ、実行者がさらに詳細化を行いながら作業を遂行する。また、割り当てられた実行者にはメール等で通知が行われ、新たな実行者側では承諾・拒否を選択できる。

（ａ）に示した固定型のワークフローモデルは、フロー全体を事前に詳細化できる典型的な業務に適している。（ｂ）に示したＡＫＷのワークフローモデルは、事前の子細なプロセス分析・モデル化が難しいような柔軟性の高い仕事に適している。

なお、出願人は出願時点までに本発明に関連する公開された先行技術文献を発見することができなかった。よって、先行技術文献情報を開示していない。

上述したように、従来より固定型のワークフローモデルとＡＫＷのワークフローモデルとが存在していたが、共同研究や問題解決等の詳細手順が定式化されていない業務を組織をまたがって共同作業する場合、次のような問題点が指摘されていた。

第１に、このような業務はワークフロー定義の詳細について事前に合意しておくことが困難であり、必要スキルを予見できず、事前の「ロール」定義ができないため、固定型のワークフローモデルを採用することは困難であった。この点については、ＡＫＷのワークフローモデルは適しているといえる。

第２に、作業の詳細手順を共同作業するパートナーに開示したくない場合があるが、固定型のワークフローモデルおよびＡＫＷのワークフローモデルともに情報の隠蔽は行えないという問題があった。隠蔽したい情報の例としては、次のようなものがある。

・具体的な実行者（内部の人事情報）
・子タスクの構成（専門知識・作業のノウハウが反映される）
・子タスクの日程実績（納期前に必死で間に合わせたのか、作業に余裕があったのか等の情報、実作業工数）
・子タスクで必要とした中間成果物、参考資料等の内部資料
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、ＡＫＷ等のワークフローモデルをベースとしつつ、組織をまたがる共同作業に適したワークフロー管理システムを提供することにある。

上記の課題を解決するため、本発明にあっては、請求項１に記載されるように、階層的に細分化される複数のタスクから構成されるワークフローを管理するシステムであって、依頼元のユーザの操作する入力手段から依頼対象のタスクの指定を受け付けるタスク受付手段と、上記依頼元のユーザの操作する入力手段から依頼先の指定を受け付ける依頼先受付手段と、指定されたタスクのデータを記憶手段から取得して複製することでモニタタスクを作成し、当該モニタタスクのデータに含まれるタスク状態を依頼中に設定し、上記依頼対象のタスクのデータに含まれるタスク状態を依頼中に設定するモニタタスク作成手段と、上記依頼対象のタスクおよびその子タスクのデータに含まれる所有者を、指定された依頼先に変更する所有者変更手段と、依頼先のユーザの操作する入力手段から依頼の承諾を受け付ける承諾受付手段と、承諾された上記依頼対象のタスクのデータに含まれるタスク状態を実行可能に変更し、上記モニタタスクのデータに含まれるタスク状態を完了待ちに変更し、上記依頼対象のタスクの子タスクおよび親タスクのデータに含まれるアクセス権を、承諾した依頼先に変更する承諾処理手段とを備えるワークフロー管理システムを要旨としている。

また、請求項２に記載されるように、請求項１に記載のワークフロー管理システムにおいて、上記依頼が拒否された場合に上記依頼対象のタスクのタスク状態を拒否に変更し、上記モニタタスクのタスク状態を不可視に設定し、上記依頼対象のタスクおよびその子タスクの所有者を、上記依頼元に変更する依頼拒否処理手段を備えるようにすることができる。

また、請求項３に記載されるように、請求項１または２のいずれか一項に記載のワークフロー管理システムにおいて、上記依頼対象のタスクが完了した場合に、上記依頼対象のタスクの属性を上記モニタタスクにコピーし、上記モニタタスクのタスク状態を完了に変更するタスク属性変更手段を備えるようにすることができる。

また、請求項４に記載されるように、請求項１乃至３のいずれか一項に記載のワークフロー管理システムにおいて、依頼の承諾／許否、依頼タスクの完了／削除、日付の変更のいずれかが行われた場合に依頼元に通知メールを送信するメール送信手段を備えるようにすることができる。

また、請求項５に記載されるように、請求項１乃至４のいずれか一項に記載のワークフロー管理システムにおいて、上記タスク受付手段は、タスク一覧画面のタスク一覧からタスク依頼ボタンが押下されたタスクを依頼対象のタスクとして受け付けるようにすることができる。

また、請求項６に記載されるように、請求項１乃至５のいずれか一項に記載のワークフロー管理システムにおいて、上記依頼先受付手段は、依頼先選択画面のユーザ一覧から依頼先選択ボタンが押下されたユーザを依頼先として受け付けるようにすることができる。

また、請求項７に記載されるように、請求項１乃至６のいずれか一項に記載のワークフロー管理システムにおいて、上記承諾受付手段は、タスク一覧画面もしくはタスク詳細画面から承諾ボタンが押下された場合に依頼の承諾を受け付け、拒否ボタンが押下された場合に依頼の拒否を受け付けるようにすることができる。

また、請求項８〜１４に記載されるように、ワークフロー管理方法として構成することができる。

本発明のワークフロー管理システムにあっては、ＡＫＷ等のワークフローモデルをベースとしつつ、組織をまたがる共同作業に適したワークフロー管理システムを提供することができる。

以下、本発明の好適な実施形態につき説明する。

＜システム構成＞
図２は本発明の一実施形態にかかるワークフロー管理システムの構成例を示す図である。図２において、ワークフロー管理システムは、ネットワーク上に配置される管理サーバ１００と、依頼者Ｕ１により操作されネットワークを介して管理サーバ１００に接続可能なブラウザ２０１およびメールリーダ３０１と、請負者Ｕ２により操作されネットワークを介して管理サーバ１００に接続可能なブラウザ２０２およびメールリーダ３０２とを備えている。

管理サーバ１００は、ブラウザ２０１、２０２とのフロントエンドとなるタスク管理ツール１０１と、ワークフロー制御を行うワークフローエンジン１０２、各種のＤＢ（Data Base）１０８〜１１０と、メール通知を行うＳＭＴＰ（Simple Mail Transfer Protocol）サーバ１１１とを備えている。

ＤＢとしては、ワークフローを構成するタスクと依頼タスクのモニタリングを行うモニタタスクとの対応関係を管理するタスク−モニタ関連表１０８と、タスク情報を管理するタスクＤＢ１０９と、実行者の組織データを管理する組織ＤＢ１１０とを備えている。

ワークフローエンジン１０２は、ＳＭＴＰサーバ１１１に対して通知メールを生成する通知メール生成部１０３と、タスク−モニタ関連表１０８を管理するタスク−モニタ関連表管理部１０４と、タスクの属性を管理するタスク属性管理部１０５と、タスクのアクセス権を管理するアクセス権管理部１０６と、組織データを管理する組織データ管理部１０７とを備えている。

図３はタスクＤＢ１０９で管理されるタスクのデータ構造例を示す図であり、属性名として、タスクＩＤ、タスク名、親タスクＩＤ、子タスクＩＤ、先行タスクＩＤ、タスク状態、タスク所有者、納期、完了日、新規タスク、関連情報アイテムＩＤ、モニタタスクか
依頼タスクか、タスク−モニタ関連ＩＤ、コメント、読取アクセス権保持者等を含んでいる。

図４はタスク−モニタ関連表１０８のデータ構造例を示す図であり、属性名として、タスク−モニタ関連ＩＤ、依頼タスクＩＤ、モニタタスクＩＤ、依頼元ユーザ、請負ユーザ、請負承諾でメール通知、請負拒否でメール通知、完了でメール通知、削除でメール通知、日付変更でメール通知等を含んでいる。

＜タスク依頼の概念＞
図５はタスク依頼の概念を示す図である。図５において、（ａ）はタスク依頼前の状態を示し、（ｂ）はタスク依頼後の状態を示している。

（ａ）に示すように、タスク依頼前においてタスクＴ１〜Ｔ１０は所有者がユーザＡであり、ユーザＡのみがアクセス可能であったとして、タスクＴ７をユーザＡからユーザＢに依頼するものとする。

この場合、（ｂ）に示すように、タスクＴ７およびその子タスクＴ９、Ｔ１０を所有者の変更によりユーザＢのみがアクセスできるようにするとともに、タスクＴ７の状態をモニタリングするモニタタスクＭＴを作成し、モニタタスクＭＴは依頼元のユーザＡのみがアクセスできるようにする。また、依頼タスクＴ７の先行タスクおよび祖先タスクであるタスクＴ１、Ｔ３、Ｔ４、Ｔ６についてはユーザＡ、Ｂともアクセスできるようにする。

こうすることで、ユーザＡは依頼タスクＴ７の完了等を把握できるとともに、タスクＴ７を実行するユーザＢは必要情報を先行タスクおよび祖先タスクから得ながら詳細情報をユーザＡに隠蔽することが可能となる。

＜依頼者側の処理＞
図６は依頼者側におけるタスク一覧画面の作成の処理例を示すシーケンス図である。図６において、依頼者Ｕ１のブラウザ２０１から管理サーバ１００のタスク管理ツール１０１にタスク一覧要求が行われると（ステップＳ１０１）、タスク管理ツール１０１はワークフローエンジン１０２からタスク情報を取得する（ステップＳ１０２、Ｓ１０３）。

次いで、タスク管理ツール１０１はタスク一覧画面を作成し（ステップＳ１０４）、タスクを一覧に表示する（ステップＳ１０５）。そして、タスク管理ツール１０１はブラウザ２０１にタスク一覧画面のデータを送信し表示させる（ステップＳ１０６）。

図７は図６におけるタスクを一覧に表示（ステップＳ１０５）する処理例を示すフローチャートである。図７において、idの指定によりタスクを一覧に表示する処理を開始すると（ステップＳ１１１）、指定されたidがタスクＩＤであるタスクを取得する（ステップＳ１１２）。

次いで、タスク状態が不可視であるか否か判断し（ステップＳ１１３）、不可視である場合は処理を終了する（ステップＳ１２１）。

不可視でない場合はタスク名、納期等の書誌情報を表示し（ステップＳ１１４）、祖先タスクに依頼中タスクがあるか否か判断し（ステップＳ１１５）、ある場合は処理を終了する（ステップＳ１２１）。

依頼中タスクがない場合は、続いてモニタタスクであるか否か判断し（ステップＳ１１６）、モニタタスクである場合はモニタタスクを表す矢印アイコンを表示する（ステップＳ１１７）。

次いで、タスク状態が依頼中であるか否か判断し（ステップＳ１１８）、依頼中でなければ、サブタスク追加、タスク削除、タスク依頼の操作ボタンを表示し（ステップＳ１１９）、処理を終了する（ステップＳ１２１）。

依頼中であればタスク依頼の承認・拒否ボタンを表示し（ステップＳ１２０）、処理を終了する（ステップＳ１２１）。

図８はタスク一覧画面４０１の例を示す図であり、タスク一覧４０２の右端にタスク依頼ボタン４０３が表示された状態を示している。

図９はタスク依頼の処理例を示すシーケンス図である。図９において、依頼者Ｕ１がブラウザ２０１上のタスク一覧画面でタスク依頼ボタンを押下すると、その旨がタスク管理ツール１０１に伝えられる（ステップＳ１３１）。タスク管理ツール１０１はワークフローエンジン１０２から依頼先の候補となる組織情報を取得し（ステップＳ１３２、Ｓ１３３）、ブラウザ２０１にタスク名、組織情報を含んだ依頼先選択画面を表示させる（ステップＳ１３４）。

依頼者Ｕ１がブラウザ２０１上の依頼先選択画面から依頼先を決定すると（ステップＳ１３５）、タスク管理ツール１０１はワークフローエンジン１０２にタスク依頼リクエストを行う（ステップＳ１３６）。ワークフローエンジン１０２はモニタタスクを作成し（ステップＳ１３７）、モニタタスクＩＤをタスク管理ツール１０１に返し（ステップＳ１３８）、タスク管理ツール１０１はブラウザ２０１に結果を通知する（ステップＳ１３９）。

また、ワークフローエンジン１０２は依頼タスクの所有者を変更し（ステップＳ１４０）、ＳＭＴＰサーバ１１１に通知メールの送信を要求する（ステップＳ１４１）。ＳＭＴＰサーバ１１１は請負者Ｕ２のメールリーダ３０２にメールを配信する（ステップＳ１４２）。

図１０は依頼先選択画面４１１の例を示す図であり、依頼先選択ボタン４１２と、タスク情報４１３と、メール通知条件設定チェックボックス４１４と、依頼先決定ボタン４１５とが表示された状態を示している。

図１１は依頼前におけるタスクのデータ例を示す図であり、図１２は依頼前におけるタスク構造例を示す図である。ここでの依頼タスクは、図１２における太枠で示したタスクＩＤが「10010」のタスクであるものとする。

図１３は図９におけるモニタタスクの作成（ステップＳ１３７）の処理例を示すフローチャートである。図１３において、モニタタスクの作成を開始すると（ステップＳ１５１）、依頼タスクを複製して新規タスクを作成し、モニタタスクとする（ステップＳ１５２）。

次いで、モニタタスクにタスクＩＤを新規に割り当て（ステップＳ１５３）、モニタタスクの属性を変更する（ステップＳ１５４）。すなわち、タスク状態を依頼中とし、モニタタスクかをtrueとし、子タスクＩＤリストをnullとし、先行タスクＩＤをnullとする。

次いで、依頼タスクの属性を変更する（ステップＳ１５５）。すなわち、タスク状態を依頼中とし、依頼タスクかをtrueとし、新規をtrueとする。

次いで、タスク-モニタ関連表オブジェクトを作成し（ステップＳ１５６）、関連表の属性を依頼先選択画面の入力情報から設定し（ステップＳ１５７）、依頼タスクとモニタタスクに関連表ＩＤを設定し（ステップＳ１５８）、処理を終了する（ステップＳ１５９）。

図１４は図９における所有者の変更（ステップＳ１４０）の処理例を示すフローチャートである。図１４において、所有者の変更の処理を開始すると（ステップＳ１６１）、idで指定されたタスクのタスク所有者を指定されたownerとし（ステップＳ１６２）、childrenに子タスクＩＤのリストを入れる（ステップＳ１６３）。

次いで、childrenが空リストであるか否か判断し（ステップＳ１６４）、空リストでない場合はchildrenの最初の要素をcidに入れ、残りのリストをchildrenに入れる（ステップＳ１６５）。そして、所有者の変更の処理を自己再帰的に呼び出し（ステップＳ１６６）、childrenが空リストであるか否かの判断（ステップＳ１６４）に戻る。childrenが空リストとなった場合は処理を終了する（ステップＳ１６７）。

図１５は依頼後におけるタスクのデータ例を示す図であり、（ａ）は依頼されたタスクのデータを示し、（ｂ）はモニタタスクのデータを示している。それぞれ、網掛けで示した部分が変更されている。

また、図１６は依頼後におけるタスク構造例を示す図であり、依頼タスク（タスクＩＤ：10010）とその子タスク（タスクＩＤ：10011、10012）の所有者が変更されるとともに、モニタタスク（タスクＩＤ：10032）が作成され、依頼タスク（タスクＩＤ：10010）とモニタタスク（タスクＩＤ：10032）は亀甲形で示したタスク−モニタ関連表のオブジェクト（タスク−モニタ関連ＩＤ：1011）により関連付けられる。

図１７は依頼後の依頼者側におけるタスク一覧画面４２１の例を示す図であり、依頼タスクにつき、モニタタスクであることを示す表示４２２と依頼中状態であることの表示４２３とが付された状態を示している。

図１８は依頼済タスク一覧画面４３１の例を示す図であり、モニタタスクだけを選択して一覧表示したものである。

＜請負者側の処理＞
図１９は請負者側におけるタスク一覧画面５０１およびタスク詳細画面５０５の例を示す図であり、（ａ）に示すように、タスク一覧画面５０１のタスク一覧５０２には、依頼タスクにつき承諾ボタン５０３と許否ボタン５０４とが表示される。また、（ｂ）に示すように、タスク詳細画面５０５にも承諾ボタン５０６と許否ボタン５０７とが表示されるとともに、依頼中状態であることの表示５０８が付される。

図２０は依頼承諾の処理例を示すシーケンス図である。図２０において、請負者Ｕ２がブラウザ２０２上のタスク一覧画面から依頼承諾ボタンを押下すると（ステップＳ２０１）、タスク管理ツール１０１はワークフローエンジン１０２に依頼承諾リクエストを行う（ステップＳ２０２）。

ワークフローエンジン１０２は、依頼の承諾の一環として、タスク属性の変更を行い（ステップＳ２０３）、続いて、アクセス権の変更を行う（ステップＳ２０４）。そして、ワークフローエンジン１０２はタスク管理ツール１０１に対して更新後のタスク属性を通知し（ステップＳ２０５）、タスク管理ツール１０１はブラウザ２０２に結果を表示させる（ステップＳ２０６）。

また、ワークフローエンジン１０２はＳＭＴＰサーバ１１１に通知メール送信を要求し（ステップＳ２０７）、ＳＭＴＰサーバ１１１は依頼者Ｕ１のメールリーダ３０１にメールを配信する（ステップＳ２０８）。

図２１は依頼承諾前におけるタスクのデータ例を示す図であり、（ａ）は依頼されたタスクのデータを示し、（ｂ）はモニタタスクのデータを示している。また、図２２は依頼承諾前におけるタスク構造例を示す図である。

図２３は依頼の承諾の処理例を示すフローチャートである。図２３において、依頼の承諾の処理を開始すると（ステップＳ２１１）、依頼タスクの関連表ＩＤから関連表を取得し（ステップＳ２１２）、関連表のモニタタスクＩＤからモニタタスクを取得する（ステップＳ２１３）。そして、依頼タスクの属性変更を行う（ステップＳ２１４）。すなわち、タスク状態を実行可能とし、新規をfalseにする。また、モニタタスクの属性変更を行い、タスク状態を完了待ちとする（ステップＳ２１５）。

次いで、アクセス権変更を行い（ステップＳ２１６）、承諾時通知が要求されているか否か判断し（ステップＳ２１７）、要求されている場合には依頼者にメール通知を行い（ステップＳ２１８）、処理を終了する（ステップＳ２１９）。

図２４はアクセス権の変更の処理例を示すフローチャートであり、（ａ）はアクセス権変更の処理、（ｂ）は（ａ）において行われる先行タスクのアクセス権設定の処理を示している。

図２４（ａ）において、idおよびuserの指定によりアクセス権変更の処理を開始すると（ステップＳ２２１）、指定されたidがタスクＩＤであるタスクを取得する（ステップＳ２２２）。

次いで、childrenに子タスクＩＤのリストを入れ（ステップＳ２２３）、childrenが空リストであるか否か判断する（ステップＳ２２４）。childrenが空リストでない場合はchildrenの最初の要素をcidに入れ、残りのリストをchildrenに入れ（ステップＳ２２５）、先行タスクのアクセス権設定を行い（ステップＳ２２６）、childrenが空リストであるか否かの判断（ステップＳ２２４）に戻る。

childrenが空リストとなった場合は、親タスクＩＤがnullであるか否か判断し（ステップＳ２２７）、nullでない場合は親タスクＩＤをidに入れ（ステップＳ２２８）、タスクＩＤがidであるタスクを取得し（ステップＳ２２９）、読取権保持者にuserを追加し（ステップＳ２３０）、先行タスクのアクセス権設定を行い（ステップＳ２３１）、親タスクＩＤがnullであるか否かの判断（ステップＳ２２７）に戻る。親タスクＩＤがnullとなった場合は処理を終了する（ステップＳ２３２）。

図２４（ｂ）において、idおよびuserの指定により先行タスクのアクセス権設定の処理を開始すると（ステップＳ２４１）、指定されたidがタスクＩＤであるタスクを取得し（ステップＳ２４２）、先行タスクＩＤリストをpredsに入れ（ステップＳ２４３）、predsが空リストであるか否か判断する（ステップＳ２４４）。predsが空リストでない場合はpredsの最初の要素をpredidに入れ、残りのリストをpredsに入れ（ステップＳ２４５）、タスクＩＤがpredidであるタスクを取得し（ステップＳ２４６）、pred_taskの読取権保持者にuserを追加し（ステップＳ２４７）、predsが空リストであるか否かの判断（ステップＳ２４４）に戻る。predsが空リストとなった場合は処理を終了する（ステップＳ２４８）。

図２５は依頼承諾後におけるタスクのデータ例を示す図であり、（ａ）は依頼されたタスクのデータを示し、（ｂ）はモニタタスクのデータを示している。それぞれ、網掛けで示した部分が変更されている。

また、図２６は依頼承諾後におけるタスク構造例を示す図であり、先行タスクおよび祖先タスクのアクセス許可として、タスク（タスクＩＤ：9810、10003、7121、9822）に対し、承諾者に対する読取アクセス権が追加される。

図２７は依頼承諾後の請負者側におけるタスク一覧画面５１１の例を示す図である。

図２８は依頼拒否の処理例を示すシーケンス図である。図２８において、請負者Ｕ２がブラウザ２０２上のタスク一覧画面から依頼許否ボタンを押下すると（ステップＳ２５１）、タスク管理ツール１０１はワークフローエンジン１０２に依頼許否リクエストを行う（ステップＳ２５２）。

ワークフローエンジン１０２は、依頼の許否の一環として、タスク属性の変更を行い（ステップＳ２５３）、続いて、所有者の変更を行う（ステップＳ２５４）。そして、ワークフローエンジン１０２はタスク管理ツール１０１に対して処理完了を通知し（ステップＳ２５５）、タスク管理ツール１０１はブラウザ２０２に結果を表示させる（ステップＳ２５６）。

また、ワークフローエンジン１０２はＳＭＴＰサーバ１１１に通知メール送信を要求し（ステップＳ２５７）、ＳＭＴＰサーバ１１１は依頼者Ｕ１のメールリーダ３０１にメールを配信する（ステップＳ２５８）。

図２９は依頼拒否前におけるタスクのデータ例を示す図であり、（ａ）は依頼されたタスクのデータを示し、（ｂ）はモニタタスクのデータを示している。また、図３０は依頼拒否前におけるタスク構造例を示す図である。

図３１は依頼の拒否の処理例を示すフローチャートである。図３１において、依頼の拒否の処理を開始すると（ステップＳ２６１）、依頼タスクの関連表ＩＤから関連表を取得し（ステップＳ２６２）、関連表のモニタタスクＩＤからモニタタスクを取得し（ステップＳ２６３）、依頼タスクの属性変更を行う（ステップＳ２６４）。すなわち、タスク状態を拒否とし、新規をfalseとし、依頼タスクかをfalseとし、タスク-モニタ関連表ＩＤをnullとする。

次いで、モニタタスクの属性変更によりタスク状態を不可視とし（ステップＳ２６５）、所有者の変更を行い（ステップＳ２６６）、許否時通知が要求されているか否か判断し（ステップＳ２６７）、要求されている場合には依頼者にメール通知を行い（ステップＳ２６８）、処理を終了する（ステップＳ２６９）。

図３２は依頼拒否後におけるタスクのデータ例を示す図であり、（ａ）は依頼されたタスクのデータを示し、（ｂ）はモニタタスクのデータを示している。それぞれ、網掛けで示した部分が変更されている。

また、図３３は依頼拒否後におけるタスク構造例を示す図であり、許否されたタスク（タスクＩＤ：10010）とその子タスク（タスクＩＤ：10011、10012）の所有者が元の依頼者に変更され、モニタタスク（タスクＩＤ：10032）は不可視となる。

図３４は依頼タスク完了および属性変更の処理例を示すシーケンス図である。図３４において、請負者Ｕ２がブラウザ２０２上のタスク一覧画面からタスク完了を入力すると（ステップＳ２７１）、タスク管理ツール１０１はワークフローエンジン１０２にタスク属性変更リクエストを行う（ステップＳ２７２）。

ワークフローエンジン１０２は、タスク属性の変更を行い（ステップＳ２７３）、タスク管理ツール１０１に対して更新後の属性値を通知し（ステップＳ２７４）、タスク管理ツール１０１はブラウザ２０２に結果を表示させる（ステップＳ２７５）。

また、ワークフローエンジン１０２は状態変更後の処理を行い（ステップＳ２７６）、ＳＭＴＰサーバ１１１に通知メール送信を要求し（ステップＳ２７７）、ＳＭＴＰサーバ１１１は依頼者Ｕ１のメールリーダ３０１にメールを配信する（ステップＳ２７８）。

図３５はタスクの状態変更後の処理例を示すフローチャートである。図３５において、状態変更後の処理を開始すると（ステップＳ２８１）、依頼タスクであるか否か判断し（ステップＳ２８２）、依頼タスクでない場合は処理を終了する（ステップＳ２９０）。

依頼タスクである場合は、依頼タスクの関連表ＩＤから関連表を取得し（ステップＳ２８３）、関連表のモニタタスクＩＤからモニタタスクを取得し（ステップＳ２８４）、依頼タスクの属性（納期、完了日、コメント）をモニタタスクにコピーする（ステップＳ２８５）。

次いで、通知対象の属性変更であるか否か判断し（ステップＳ２８６）、通知対象の属性変更である場合は依頼者にメール通知を行う（ステップＳ２８７）。

次いで、依頼タスクは完了したか否か判断し（ステップＳ２８８）、完了している場合はモニタタスクの属性変更によりタスク状態を完了とし（ステップＳ２８９）、処理を終了する（ステップＳ２９０）。

図３６は依頼タスク完了後におけるタスクのデータ例を示す図であり、（ａ）は依頼されたタスクのデータを示し、（ｂ）はモニタタスクのデータを示している。（ａ）のタスクのデータのうち網掛けで示した部分がモニタタスクのデータに複製されている。

＜モニタリングを実現する他の手法例＞
上述した実施形態ではモニタタスクにより依頼タスクのモニタリングを行う場合について説明したが、モニタタスクを作成せずに同一オブジェクトのアクセス権のみによって制御することもできる。この場合、下位タスクついて読取／編集権を設定し、タスクの依頼時または承諾時にアクセス権を設定（依頼者は依頼タスクをread-onlyに設定し、依頼者は下位タスクのアクセスができないように設定）することで、依頼タスクのモニタリングを行うことができる。

なお、前述したモニタタスクにより依頼タスクのモニタリングを行う手法は、上記のアクセス権によって制御する手法に比べて次のようなメリットがある。
（１）依頼タスクの属性変更を隠蔽可能（完了時のみ反映）である。

・同一オブジェクトの場合は、逐次参照可能となってしまうことによる。

・属性単位のアクセス権設定でも可能だが煩雑である。
（２）依頼タスクに今後付加されるオブジェクト（子タスク・関連情報等）のアクセス権設定が単純である。

・上記例では追加される子タスクのアクセス権設定が難しいことによる。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

従来のワークフローモデルの例を示す図である。本発明の一実施形態にかかるワークフロー管理システムの構成例を示す図である。タスクのデータ構造例を示す図である。タスク−モニタ関連表のデータ構造例を示す図である。タスク依頼の概念を示す図である。依頼者側におけるタスク一覧画面の作成の処理例を示すシーケンス図である。タスクを一覧に表示する処理例を示すフローチャートである。タスク一覧画面の例を示す図である。タスク依頼の処理例を示すシーケンス図である。依頼先選択画面の例を示す図である。依頼前におけるタスクのデータ例を示す図である。依頼前におけるタスク構造例を示す図である。モニタタスクの作成の処理例を示すフローチャートである。所有者の変更の処理例を示すフローチャートである。依頼後におけるタスクのデータ例を示す図である。依頼後におけるタスク構造例を示す図である。依頼後の依頼者側におけるタスク一覧画面の例を示す図である。依頼済タスク一覧画面の例を示す図である。請負者側におけるタスク一覧画面およびタスク詳細画面の例を示す図である。依頼承諾の処理例を示すシーケンス図である。依頼承諾前におけるタスクのデータ例を示す図である。依頼承諾前におけるタスク構造例を示す図である。依頼の承諾の処理例を示すフローチャートである。アクセス権の変更の処理例を示すフローチャートである。依頼承諾後におけるタスクのデータ例を示す図である。依頼承諾後におけるタスク構造例を示す図である。依頼承諾後の請負者側におけるタスク一覧画面の例を示す図である。依頼拒否の処理例を示すシーケンス図である。依頼拒否前におけるタスクのデータ例を示す図である。依頼拒否前におけるタスク構造例を示す図である。依頼の拒否の処理例を示すフローチャートである。依頼拒否後におけるタスクのデータ例を示す図である。依頼拒否後におけるタスク構造例を示す図である。依頼タスク完了および属性変更の処理例を示すシーケンス図である。タスクの状態変更後の処理例を示すフローチャートである。依頼タスク完了後におけるタスクのデータ例を示す図である。

符号の説明

１００管理サーバ
１０１タスク管理ツール
１０２ワークフローエンジン
１０３通知メール生成部
１０４タスク−モニタ関連表管理部
１０５タスク属性管理部
１０６アクセス権管理部
１０７組織データ管理部
１０８タスク−モニタ関連表
１０９タスクＤＢ
１１０組織ＤＢ
１１１ＳＭＴＰサーバ
２０１ブラウザ
２０２ブラウザ
３０１メールリーダ
３０２メールリーダ
Ｕ１依頼者
Ｕ２請負者

Claims

階層的に細分化される複数のタスクから構成されるワークフローを管理するシステムであって、
依頼元のユーザの操作する入力手段から依頼対象のタスクの指定を受け付けるタスク受付手段と、
上記依頼元のユーザの操作する入力手段から依頼先の指定を受け付ける依頼先受付手段と、
指定されたタスクのデータを記憶手段から取得して複製することでモニタタスクを作成し、当該モニタタスクのデータに含まれるタスク状態を依頼中に設定し、上記依頼対象のタスクのデータに含まれるタスク状態を依頼中に設定するモニタタスク作成手段と、
上記依頼対象のタスクおよびその子タスクのデータに含まれる所有者を、指定された依頼先に変更する所有者変更手段と、
依頼先のユーザの操作する入力手段から依頼の承諾を受け付ける承諾受付手段と、
承諾された上記依頼対象のタスクのデータに含まれるタスク状態を実行可能に変更し、上記モニタタスクのデータに含まれるタスク状態を完了待ちに変更し、上記依頼対象のタスクの子タスクおよび親タスクのデータに含まれるアクセス権を、承諾した依頼先に変更する承諾処理手段と
を備えたことを特徴とするワークフロー管理システム。
請求項１に記載のワークフロー管理システムにおいて、
上記依頼が拒否された場合に上記依頼対象のタスクのタスク状態を拒否に変更し、上記モニタタスクのタスク状態を不可視に設定し、上記依頼対象のタスクおよびその子タスクの所有者を、上記依頼元に変更する依頼拒否処理手段
を備えたことを特徴とするワークフロー管理システム。
請求項１または２のいずれか一項に記載のワークフロー管理システムにおいて、
上記依頼対象のタスクが完了した場合に、上記依頼対象のタスクの属性を上記モニタタスクにコピーし、上記モニタタスクのタスク状態を完了に変更するタスク属性変更手段
を備えたことを特徴とするワークフロー管理システム。
請求項１乃至３のいずれか一項に記載のワークフロー管理システムにおいて、
依頼の承諾／許否、依頼タスクの完了／削除、日付の変更のいずれかが行われた場合に依頼元に通知メールを送信するメール送信手段
を備えたことを特徴とするワークフロー管理システム。
請求項１乃至４のいずれか一項に記載のワークフロー管理システムにおいて、
上記タスク受付手段は、タスク一覧画面のタスク一覧からタスク依頼ボタンが押下されたタスクを依頼対象のタスクとして受け付ける
ことを特徴とするワークフロー管理システム。
請求項１乃至５のいずれか一項に記載のワークフロー管理システムにおいて、
上記依頼先受付手段は、依頼先選択画面のユーザ一覧から依頼先選択ボタンが押下されたユーザを依頼先として受け付ける
ことを特徴とするワークフロー管理システム。
請求項１乃至６のいずれか一項に記載のワークフロー管理システムにおいて、
上記承諾受付手段は、タスク一覧画面もしくはタスク詳細画面から承諾ボタンが押下された場合に依頼の承諾を受け付け、拒否ボタンが押下された場合に依頼の拒否を受け付ける
ことを特徴とするワークフロー管理システム。
階層的に細分化される複数のタスクから構成されるワークフローを管理する方法であって、
ワークフローエンジンが、依頼元のユーザの操作する入力手段から依頼対象のタスクの指定を受け付けるタスク受付工程と、
上記ワークフローエンジンが、上記依頼元のユーザの操作する入力手段から依頼先の指定を受け付ける依頼先受付工程と、
上記ワークフローエンジンが、指定されたタスクのデータを記憶手段から取得して複製することでモニタタスクを作成し、当該モニタタスクのデータに含まれるタスク状態を依頼中に設定し、上記依頼対象のタスクのデータに含まれるタスク状態を依頼中に設定するモニタタスク作成工程と、
上記ワークフローエンジンが、上記依頼対象のタスクおよびその子タスクのデータに含まれる所有者を、指定された依頼先に変更する所有者変更工程と、
上記ワークフローエンジンが、依頼先のユーザの操作する入力手段から依頼先から依頼の承諾を受け付ける承諾受付工程と、
上記ワークフローエンジンが、承諾された上記依頼対象のタスクのデータに含まれるタスク状態を実行可能に変更し、上記モニタタスクのデータに含まれるタスク状態を完了待ちに変更し、上記依頼対象のタスクの子タスクおよび親タスクのデータに含まれるアクセス権を、承諾した依頼先に変更する承諾処理工程と
を備えたことを特徴とするワークフロー管理方法。
請求項８に記載のワークフロー管理方法において、
上記ワークフローエンジンが、上記依頼が拒否された場合に上記依頼対象のタスクのタスク状態を拒否に変更し、上記モニタタスクのタスク状態を不可視に設定し、上記依頼対象のタスクおよびその子タスクの所有者を、上記依頼元に変更する依頼拒否処理工程
を備えたことを特徴とするワークフロー管理方法。
請求項８または９のいずれか一項に記載のワークフロー管理方法において、
上記ワークフローエンジンが、上記依頼対象のタスクが完了した場合に、上記依頼対象のタスクの属性を上記モニタタスクにコピーし、上記モニタタスクのタスク状態を完了に変更するタスク属性変更工程
を備えたことを特徴とするワークフロー管理方法。
請求項８乃至１０のいずれか一項に記載のワークフロー管理方法において、
上記ワークフローエンジンが、依頼の承諾／許否、依頼タスクの完了／削除、日付の変更のいずれかが行われた場合に依頼元に通知メールを送信するメール送信工程
を備えたことを特徴とするワークフロー管理方法。
請求項８乃至１１のいずれか一項に記載のワークフロー管理方法において、
上記タスク受付工程は、タスク一覧画面のタスク一覧からタスク依頼ボタンが押下されたタスクを依頼対象のタスクとして受け付ける
ことを特徴とするワークフロー管理方法。
請求項８乃至１２のいずれか一項に記載のワークフロー管理方法において、
上記依頼先受付工程は、依頼先選択画面のユーザ一覧から依頼先選択ボタンが押下されたユーザを依頼先として受け付ける
ことを特徴とするワークフロー管理方法。
請求項８乃至１３のいずれか一項に記載のワークフロー管理方法において、
上記承諾受付工程は、タスク一覧画面もしくはタスク詳細画面から承諾ボタンが押下された場合に依頼の承諾を受け付け、拒否ボタンが押下された場合に依頼の拒否を受け付ける
ことを特徴とするワークフロー管理方法。