JP2008059369A - ワークフロー管理システム、ワークフロー管理方法、ワークフロー管理プログラムおよび記録媒体 - Google Patents

Abstract

【課題】プロジェクトの進捗管理を正確かつ容易に行うことができるワークフロー管理システム、ワークフロー管理方法、ワークフロー管理プログラムおよび記録媒体を提供することを目的とする。
【解決手段】階層的に細分化された複数のタスクから成るワークフローを管理するワークフロー管理システム１００であって、タスク情報を格納している格納手段１２０と、格納手段１２０からタスク情報を取得し、タスク情報に含まれる複数のタスクの構造，複数のタスク間の依存関係，複数のタスクの状態及びスケジュールの情報からワークフローのクリティカルパスを算出する算出手段１１０と、算出手段が算出したクリティカルパスを画面上に表示させる表示制御手段１０１とを備えたことにより上記課題を解決する。
【選択図】図１

Description

本発明は、ワークフロー管理システム、ワークフロー管理方法、ワークフロー管理プログラムおよび記録媒体に係り、特に階層的に細分化された複数のタスクから成るワークフローを管理するワークフロー管理システム、ワークフロー管理方法、ワークフロー管理プログラムおよび記録媒体に関する。

近年、ＷＢＳ（Ｗｏｒｋ Ｂｒｅａｋｄｏｗｎ Ｓｔｒｕｃｔｕｒｅ）をベースにした例えばＭＳ Ｐｒｏｊｅｃｔ（登録商標）などのプロジェクト管理ツールが知られるようになった。

ここでプロジェクトとは、ある目的を実現するために一定期間チームを組み、活動するものを言う。また、ＷＢＳとは作業分解図等のことであり、プロジェクトに含まれる全ての作業をタスクとして拾い出して、その内容を明確化していく手法であり、作業計画の基本となる。

ここでは、ＭＳ Ｐｒｏｊｅｃｔ（登録商標）を従来のプロジェクト管理ツールの一例として説明する。例えばＭＳ Ｐｒｏｊｅｃｔ（登録商標）では、プロジェクトの工程をプロセス（ワークフロー）により管理する。また、プロセス（ワークフロー）ではプロジェクトの工程をタスクにより管理する。

プロジェクトの工程をタスクにより管理するＭＳ Ｐｒｏｊｅｃｔ（登録商標）では各タスクの開始・終了予定日時、見積り工数、実際の開始・終了日時などを管理することによりプロジェクトの進捗・リソース（担当者）を管理するために用いられる。

ＭＳ Ｐｒｏｊｅｃｔ（登録商標）の主な機能としては、ＷＢＳによるタスクの階層化がある。ただし、ＭＳ Ｐｒｏｊｅｃｔ（登録商標）はタスクの親子関係がない。親タスクは実体がなく、包含タスクのみの存在である。

また、ＭＳ Ｐｒｏｊｅｃｔ（登録商標）の主な機能としては、先行タスクによるタスクの依存関係の管理がある。また、ＭＳ Ｐｒｏｊｅｃｔ（登録商標）の主な機能としては、タスクの期間、開始日、終了日、リソースによるスケジュール、計画管理がある。

また、ＭＳ Ｐｒｏｊｅｃｔ（登録商標）の主な機能としては、作業実績の入力による進捗管理がある。また、ＭＳ Ｐｒｏｊｅｃｔ（登録商標）の主な機能としては、クリティカルパスによるプロジェクトの管理（余剰日数０のタスクをクリティカルタスクとして認識し、クリティカルパスを自動的に計算する。）がある。更にＭＳ Ｐｒｏｊｅｃｔ（登録商標）の主な機能としては、ガンチャート、ＰＡＲＴチャートによる工程のビジュアル化がある。

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

従来のプロジェクト管理ツールでは、タスクの期間、開始日、終了日、先行タスク、リソースなどのタスク情報を厳密に管理することにより、工程の管理が可能となる。現実にはプロジェクトの進行中にタスクを追加したり、リソース（担当者）が変更になることがあり、それらを反映しようとすると、意図しない様々な矛盾が発生したりして、プロジェクト管理ツールを上手く利用することが難しかった。

そこで、本出願人は、柔軟にプロジェクトを変更可能とする為に、新たなプロジェクト管理ツール（ワークフロー管理システム）を提案し、特許出願を行っている（例えば特願２００６−３４９７、特願２００６−３５００参照）。

特願２００６−３４９７及び特願２００６−３５００に記載されているワークフロー管理システムでは、ＡＫＷ（Ａｇｉｌｅ Ｋｎｏｗｌｅｄｇｅ Ｗｏｒｋｆｌｏｗ）技術を用いることで、タスクの変更を容易化している。つまり、特願２００６−３４９７及び特願２００６−３５００に記載されているワークフロー管理システムでは、プロジェクトの頻繁な変更が許されている。

しかしながら、新たなワークフロー管理システムではプロジェクトの頻繁な変更を許したため、プロジェクトの進捗管理が困難になるという課題が発生した。具体的に、管理者はプロジェクトの進捗管理において、クリティカルパスを見つけることが難しくなり、クリティカルパスから遅延リスクを正確かつ迅速に検出することが困難となった。

本発明は、上記の点に鑑みなされたもので、プロジェクトの進捗管理を正確かつ容易に行うことができるワークフロー管理システム、ワークフロー管理方法、ワークフロー管理プログラムおよび記録媒体を提供することを目的とする。

上記課題を解決する為、本発明は、階層的に細分化された複数のタスクから成るワークフローを管理するワークフロー管理システムであって、タスク情報を格納している格納手段と、前記格納手段からタスク情報を取得し、そのタスク情報に含まれる前記複数のタスクの構造，前記複数のタスク間の依存関係，前記複数のタスクの状態及びスケジュールの情報から前記ワークフローのクリティカルパスを算出する算出手段と、前記算出手段が算出した前記クリティカルパスを画面上に表示させる表示制御手段とを備えたことを特徴とする。

なお、本発明の構成要素、表現または構成要素の任意の組合せを、方法、装置、システム、コンピュータプログラム、記録媒体、データ構造などに適用したものも本発明の態様として有効である。

本発明によれば、プロジェクトの進捗管理を正確かつ容易に行うことができるワークフロー管理システム、ワークフロー管理方法、ワークフロー管理プログラムおよび記録媒体を提供可能である。

次に、本発明を実施するための最良の形態を、以下の実施例に基づき図面を参照しつつ説明していく。

＜システム構成＞
図１は本発明によるワークフロー管理システムの一実施例のシステム構成図である。図１のワークフロー管理システム１００は、ＧＵＩ提供部１０１と、ワークフローエンジン１１０と、データベース（Ｄａｔａｂａｓｅｓ）１２０と、Ｅメールサブシステム（Ｅｍａｉｌ ｓｕｂｓｙｓｔｅｍ）１３０とを有する。

ＧＵＩ提供部１０１はワークフロー管理システム１００を使用するユーザＵの操作するユーザ用端末（図示せず）に対して、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）を提供する。

ワークフローエンジン１１０は、既存のタスクモデルおよび／もしくはタスクインスタンスからの再利用により動的にワークフローモデルを生成し実行する。データベース１２０は、各種情報を体系的に管理する。また、ＥメールサブシステムはＥメールに関する各種処理を行う。

ＧＵＩ提供部１０１は、レンダリングエンジン１０２，入出力制御部１０３，プロセスチャート生成部１０４を有する。レンダリングエンジン１０２は表示画面を描画する。入出力制御部１０３はユーザＵの操作するユーザ用端末との間で情報のやり取りを行う。プロセスチャート生成部１０４はプロセスチャートを生成する。

ワークフローエンジン１１０は、検索エンジン１１１，タスク制御部１１２，ワークフロー記録部１１６を備えている。検索エンジン１１１はＤＢ１２０に対して各種の検索を実行する。タスク制御部１１２はワークフローを構成するタスクの制御を行う。ワークフロー記録部１１６はデータベース１２０を参照し、ユーザＵの操作するユーザ用端末との間のワークフロー管理システム１００の動作を監視してワークフローの作業記録を後述する作業記録ＤＢ１２４に対して行う。

タスク制御部１１２は、タスク作成部１１３，タスク実行部１１４，推測エンジン１１５を有する。タスク作成部１１３は、タスクを作成する。タスク実行部１１４は、作成されたタスクを実行する。推測エンジン１１５は、作業記録ＤＢ１２４の情報を元にユーザＵの現在のタスクを推測し、関連する情報をデータベース１２０から検索する。

データベース１２０は、関連情報ＤＢ１２１，タスクモデルＤＢ１２２，タスクインスタンスＤＢ１２３，作業記録ＤＢ１２４，組織情報ＤＢ１２５を有する。関連情報ＤＢ１２１はワークフローの実行に際して参考にされる関連情報を格納する。タスクモデルＤＢ１２２は予め管理者等によって抽象化されたタスクモデルを格納する。

タスクインスタンスＤＢ１２３は、過去のタスクインスタンスを格納する。作業記録ＤＢ１２４は、ワークフローの作業記録を格納する。また、組織情報ＤＢ１２５は企業等の組織情報を格納する。なお、タスクモデルＤＢ１２２およびタスクインスタンスＤＢ１２３は関連情報ＤＢ１２１に登録された情報とのリンクを持つ。

動作概要として、ユーザＵはユーザ用端末からＧＵＩ提供部１０１の入出力制御部１０３を通じてワークフローエンジン１１０を操作し、ワークフローの作成、実行、ワークフローモデルの作成、関連情報の登録、及び、これらとワークフローインスタンス、ワークフローモデルとのリンク等の作業を行う。

ワークフローの作成に際し、ワークフローエンジン１１０の検索エンジン１１１は各種の検索をデータベース１２０に対して実行する。また、ワークフローエンジン１１０のタスク制御部１１２は、タスクモデルＤＢ１２２およびタスクインスタンスＤＢ１２３を使用し、ユーザＵの指示等に基づいてタスクを制御する。

タスク制御部１１２のタスク作成部１１３は、ユーザＵの指示に従ってデータベース１２０の情報を元にタスクの作成、情報のリンク付け等の作業を行う。タスク実行部１１４は、ユーザＵの指示に従ってタスクインスタンスＤＢ１２３の情報を利用し、実際のタスク情報の更新を行う。タスクの実行は、ワークフロー管理システム側から見ればタスク情報の更新である。

推測エンジン１１５は、作業記録ＤＢ１２４の情報を元にユーザＵの現在のタスクを推測し、関連する情報をデータベース１２０から検索する。また、ワークフロー記録部１１６は、ユーザＵとワークフロー管理システム１００の動作を監視し、ワークフローの作業記録を作業記録ＤＢ１２４に格納する。

なお、ワークフロー管理システム１００は例えばパーソナルコンピュータ（ＰＣ）等で実現されるものである。以下に示した各実施例の動作処理は特に明記しない限り、ＣＰＵがＲＯＭやハードディスク装置等に記憶されたプログラムに従い、ＲＡＭ等のメインメモリをワークエリアとして使用して実行、処理される。

以下では、図１のワークフロー管理システム１００において、プロジェクトの進捗管理を正確かつ容易に行うことができる実施例１〜３について説明する。本発明によるワークフロー管理システム１００では、プロジェクトの頻繁な変更を許しつつも、プロジェクトの進捗管理を正確かつ容易に行うことができる。

まず、本発明によるワークフロー管理システム１００は、ＷＢＳにおいて、任意のタスクに子タスクを作成可能とする。また、本発明によるワークフロー管理システム１００は親タスクもタスクの実体を持てるものとする。

また、本発明によるワークフロー管理システム１００は、親タスクと子タスクとの時間的依存関係を撤廃し、親タスク及び子タスクにそれぞれ任意の開始日、終了日又は期間を保持する。ただし、本発明によるワークフロー管理システム１００は、親タスクが子タスクよりも前に開始し、後で終了する。また、本発明によるワークフロー管理システム１００は親タスク及び子タスクを独立して、また、並行して実行できる。

また、本発明によるワークフロー管理システム１００は、ＷＢＳにおけるタスクの親子関係とは別に、タスクの順序関係を保持する。この順序関係は、前述したＭＳ Ｐｒｏｊｅｃｔ（登録商標）の先行タスクと同様である。

また、本発明によるワークフロー管理システム１００は、各タスクの進捗度を残日数あるいは割合によりユーザが設定できる。また、本発明によるワークフロー管理システム１００は、タスクの順序関係と期間とを元に、プロジェクトのクリティカルパスを後述するように発見する。ユーザは、クリティカルパスを参照することにより、プロジェクトの進捗管理が可能である。

また、本発明によるワークフロー管理システム１００は、クリティカルパスに含まれるタスクをクリティカルタスクとして一覧表示し、それらクリティカルタスクの進捗を管理する。また、本発明によるワークフロー管理システム１００は、クリティカルタスクがサブタスクを含む場合、サブタスクの進捗を元にクリティカルタスクの進捗を計算する。

また、本発明によるワークフロー管理システム１００は、クリティカルパスにおいて遅延リスクが検出された場合に、ユーザ用端末の画面上又はＥメールなどでユーザに遅延リスクが高まったことを通知できる。

図２は、ワークフロー管理システムにおけるクリティカルパス表示処理を表した一例のシーケンス図である。なお、図２中のブラウザ２０１はユーザ用端末に搭載される。ステップＳ２０１に進み、ユーザ用端末に搭載されているブラウザ２０１はユーザからの要求に基づき、ワークフロー管理システム１００のＧＵＩ提供部１０１にクリティカルパス表示要求を行う。

ステップＳ２０２に進み、ＧＵＩ提供部１０１はユーザが選択したプロジェクトを指定して、クリティカルパス表示要求に基づき、推測エンジン１１５にクリティカルパス計算要求を行う。ステップＳ２０３に進み、推測エンジン１１５はクリティカルパス計算要求に基づき、クリティカルパス計算に必要なタスク構造・依存関係情報をタスクインスタンスＤＢ１２３に要求する。

タスクインスタンスＤＢ１２３は例えばタスク構造・依存関係情報を図３及び図４のようなテーブルスキーマにより格納している。図３は、タスクテーブルの一例の構成図である。図４は、タスクシーケンステーブルの一例の構成図である。

図３のタスクテーブルは、タスクＩＤ，タスク名，タスクの記述，タスクの状態，開始予定日，終了予定日，残日数および親タスクＩＤを含む構成である。また、図４のタスクシーケンステーブルはタスクシーケンスＩＤ，開始タスクＩＤおよび終了タスクＩＤを含む構成である。

例えばタスク構造・依存関係情報は、図３のタスクテーブル及び図４のタスクシーケンステーブルから取得できる。ステップＳ２０４に進み、推測エンジン１１５はタスクインスタンスＤＢ１２３からタスク構造・依存関係情報を受信する。

ステップＳ２０５に進み、推測エンジン１１５は続いてクリティカルパス計算に必要なタスク状態情報をタスクインスタンスＤＢ１２３に要求する。例えばタスク状態情報は図３のタスクテーブルから取得できる。ステップＳ２０６に進み、推測エンジン１１５はタスクインスタンスＤＢ１２３からタスク状態情報を受信する。

ステップＳ２０７に進み、推測エンジン１１５は後述するようにクリティカルパス計算を行う。ステップＳ２０８に進み、推測エンジン１１５はクリティカルパスの計算結果をＧＵＩ提供部１０１に送信する。

ステップＳ２０９に進み、ＧＵＩ提供部１０１は、表示情報を生成する為に必要なタスク構造・依存関係情報をタスクインスタンスＤＢ１２３に要求する。ステップＳ２１０に進み、ＧＵＩ提供部１０１はタスクインスタンスＤＢ１２３からタスク構造・依存関係情報を受信する。

ステップＳ２１１に進み、ＧＵＩ提供部１０１はクリティカルパスの計算結果及びタスク構造・依存関係情報から表示情報を生成する。ステップＳ２１２に進み、ＧＵＩ１０１は生成した表示情報をブラウザ２０１に送信し、後述するようなクリティカルパスが表された画面をブラウザ２０１に表示させる。

なお、本発明によるワークフロー管理システム１００は、タスクの追加又は分割，タスクの遅延又は短縮などが生じた場合、クリティカルパスの再計算を行う。ここではタスクの追加処理を例として説明する。

図５は、ワークフロー管理システムにおけるタスクの追加処理を表した一例のシーケンス図である。なお、図２中のブラウザ２０１はユーザ用端末に搭載される。

ステップＳ５０１に進み、ユーザ用端末に搭載されているブラウザ２０１はユーザからの要求に基づき、ユーザが選択したプロジェクトを指定して、ワークフロー管理システム１００のＧＵＩ提供部１０１にタスク追加要求を行う。

ステップＳ５０２に進み、ＧＵＩ提供部１０１はタスク追加要求に基づき、タスク作成部１１３にタスク作成要求を行う。ステップＳ５０３に進み、タスク作成部１１３はタスク作成要求に基づき、推測エンジン１１５にタスク追加前のクリティカルパス計算要求を行う。ステップＳ５０４に進み、推測エンジン１１５はタスク追加前のクリティカルパス計算要求に基づき、クリティカルパス計算に必要なタスク構造・依存関係情報をタスクインスタンスＤＢ１２３に要求する。ステップＳ５０５に進み、推測エンジン１１５はタスクインスタンスＤＢ１２３からタスク構造・依存関係情報を受信する。

ステップＳ５０６に進み、推測エンジン１１５はクリティカルパス計算に必要なタスク状態情報をタスクインスタンスＤＢ１２３に要求する。ステップＳ５０７に進み、推測エンジン１１５はタスクインスタンスＤＢ１２３からタスク状態情報を受信する。

ステップＳ５０８に進み、推測エンジン１１５は後述するようにクリティカルパス計算を行う。ステップＳ５０９に進み、推測エンジン１１５はクリティカルパスの計算結果をタスク作成部１１３に送信する。

タスク追加前のクリティカルパスの計算結果を受信すると、タスク作成部１１３はステップＳ５１０に進み、タスクインスタンスＤＢ１２３へのタスク登録・タスク構造更新を要求する。そして、ステップＳ５１１に進み、タスク作成部１１３はタスクインスタンスＤＢ１２３へのタスク登録・タスク構造更新の結果をタスクインスタンスＤＢ１２３から受信する。

ステップＳ５１２に進み、タスク作成部１１３は推測エンジン１１５にタスク追加後のクリティカルパス計算要求を行う。ステップＳ５１３に進み、推測エンジン１１５はタスク追加後のクリティカルパス計算要求に基づき、クリティカルパス計算に必要なタスク構造・依存関係情報をタスクインスタンスＤＢ１２３に要求する。推測エンジン１１５はステップＳ５１４に進み、タスクインスタンスＤＢ１２３からタスク構造・依存関係情報を受信する。

ステップＳ５１５に進み、推測エンジン１１５はクリティカルパス計算に必要なタスク状態情報をタスクインスタンスＤＢ１２３に要求する。ステップＳ５１６に進み、推測エンジン１１５はタスクインスタンスＤＢ１２３からタスク状態情報を受信する。

ステップＳ５１７に進み、推測エンジン１１５は後述するようにクリティカルパス計算を行う。ステップＳ５１８に進み、推測エンジン１１５はクリティカルパスの計算結果をタスク作成部１１３に送信する。

タスク追加後のクリティカルパスの計算結果を受信すると、タスク作成部１１３はステップＳ５１９に進み、タスク追加前及びタスク追加後のクリティカルパスを比較し、遅延が発生するタスクを抽出する。ステップＳ５２０に進み、タスク作成部１１３はステップＳ５１９で抽出した遅延が発生するタスクの担当者にメールで通知する旨、Ｅメールサブシステム１３０に要求する。Ｅメールサブシステム１３０は、必要な情報をデータベース１２０から取得し、遅延が発生するタスクの担当者に、タスクの遅延発生をＥメールで通知する。

また、ステップＳ５２１に進み、タスク作成部１１３はタスク作成要求に対する応答をＧＵＩ提供部１０１に対して行う。さらに、ステップＳ５２２に進み、ＧＵＩ提供部１０１はタスク追加要求に対する応答をブラウザ２０１に対して行う。なお、図２のシーケンス図と同様に、図５のシーケンス図はタスク追加後のクリティカルパス及び遅延が発生するタスクが表された画面をブラウザ２０１に表示させるようにしてもよい。

次に、クリティカルパス計算処理について説明する。図６はＷＢＳによるタスクの階層化を表した一例のイメージ図である。図６の「プロジェクトＡ」は「タスク１」〜「タスク７」で構成されている。

「タスク３」及び「タスク４」は「タスク２」の子タスクである。「タスク６」は「タスク５」の子タスクである。「タスク７」は「タスク６」の子タスクである。図６の「プロジェクトＡ」の場合、各タスクの開始、終了日に以下の制限がある。

例えば「タスク２」は「タスク３」及び「タスク４」よりも前に開始し、後で終了しなければならない。「タスク５」は「タスク６」及び「タスク７」よりも前に開始し、後で終了しなければならない。「タスク６」は「タスク７」よりも前に開始し、後で終了しなければならない。

図６の「プロジェクトＡ」では、「タスク１」→「タスク３」→「タスク６」の順序関係が規定されているものとする。本実施例では、この順序関係をタスクシーケンスと呼んでいる。図６の「プロジェクトＡ」では、以下の手順でクリティカルパスを発見する。

まず、推測エンジン１１５は、順序関係が定義されているタスク、タスクシーケンスについて、以下のようにクリティカルパスを計算する。なお、開始予定日，終了予定日及び期間には、「終了予定日−開始予定日＞期間」の関係がある。

推測エンジン１１５は、タスクシーケンスを構成している「タスク１」の終了予定日と「タスク３」の開始予定日とを比較する。「タスク３」の開始予定日が「タスク１」の終了予定日より前の場合、推測エンジン１１５は「タスク３」の開始予定日を「タスク１」の終了予定日に変更する。

次に、推測エンジン１１５は、タスクシーケンスを構成している「タスク３」の終了予定日と「タスク６」の開始予定日とを比較する。ここで「タスク６」の開始予定日が「タスク３」の終了予定日より前の場合、推測エンジン１１５は「タスク６」の開始予定日を「タスク３」の終了予定日に変更する。

このように、推測エンジン１１５は、「タスク１」→「タスク３」→「タスク６」の順序関係から成るタスクシーケンスの終了予定日を「タスク６」の終了予定日に変更する。

次に、推測エンジン１１５は親子関係がある「タスク２」の終了予定日と「タスク３」の終了予定日とを比較する。ここで「タスク２」の終了予定日が「タスク３」の終了予定日より前の場合、推測エンジン１１５は「タスク２」の終了予定日を「タスク３」の終了予定日に変更する。

推測エンジン１１５は、親子関係がある「タスク５」の終了予定日と「タスク６」の終了予定日とを比較する。ここで「タスク５」の終了予定日が「タスク６」の終了予定日より前の場合、推測エンジン１１５は「タスク５」の終了予定日を「タスク６」の終了予定日に変更する。

推測エンジン１１５は、上記の手順で計算したタスクシーケンス，「タスク２」又は「タスク５」の終了予定日を比べ、最後に終了するタスク又はタスクシーケンスをクリティカルパスとする。

タスクシーケンスの終了予定日は、例えば図７のフローチャートに示す手順により導出される。ステップＳ７０１に進み、推測エンジン１１５は「タスク１」→「タスク３」→「タスク６」の順序関係から成るタスクシーケンスから最初のタスクである「タスク１」を選択し、現在のタスクとする。

ステップＳ７０２に進み、推測エンジン１１５はタスクシーケンスに現在のタスク「タスク１」の次のタスクがあるか否かを判定する。タスクシーケンスに現在のタスク「タスク１」の次のタスク「タスク３」があるので、推測エンジン１１５はステップＳ７０３に進み、現在のタスクの終了予定日（ｔ１）より次のタスクの開始予定日（ｔ２）が前か否かを判定する。

現在のタスク「タスク１」の終了予定日（ｔ１）より次のタスク「タスク３」の開始予定日（ｔ２）が前であれば、推測エンジン１１５はステップＳ７０４に進み、次のタスクである「タスク３」の開始予定日を現在のタスクである「タスク１」の終了予定日の日付で更新したあと、ステップＳ７０５に進む。なお、現在のタスク「タスク１」の終了予定日（ｔ１）より次のタスク「タスク３」の開始予定日（ｔ２）が前でなければ、推測エンジン１１５はステップＳ７０５に進む。

ステップＳ７０５では、推測エンジン１１５が、次のタスクである「タスク３」を選択して現在のタスクとしたあと、ステップＳ７０２に戻る。ステップＳ７０２では、推測エンジン１１５が、タスクシーケンスに現在のタスク「タスク３」の次のタスクがあるか否かを判定する。推測エンジン１１５は、タスクシーケンスに現在のタスク「タスク３」の次のタスク「タスク６」があるので、ステップＳ７０３に進み、現在のタスクの終了予定日（ｔ１）より次のタスクの開始予定日（ｔ２）が前か否かを判定する。

現在のタスク「タスク１」の終了予定日（ｔ１）より次のタスク「タスク３」の開始予定日（ｔ２）が前であれば、推測エンジン１１５はステップＳ７０４に進み、次のタスクである「タスク６」の開始予定日を現在のタスクである「タスク３」の終了予定日の日付で更新したあと、ステップＳ７０５に進む。なお、現在のタスク「タスク３」の終了予定日（ｔ１）より次のタスク「タスク６」の開始予定日（ｔ２）が前でなければ、推測エンジン１１５はステップＳ７０５に進む。

ステップＳ７０５では、推測エンジン１１５が、次のタスクである「タスク６」を選択して現在のタスクとしたあと、ステップＳ７０２に戻る。ステップＳ７０２では、推測エンジン１１５が、タスクシーケンスに現在のタスク「タスク６」の次のタスクがあるか否かを判定する。推測エンジン１１５は、タスクシーケンスに現在のタスク「タスク６」の次のタスクがないので、ステップＳ７０６に進み、現在のタスク「タスク６」の終了予定日をタスクシーケンスの終了予定日として採用し、処理を終了する。

また、子タスクを持つ親タスクの終了予定日は、例えば図８のフローチャートに示す手順により導出される。ステップＳ８０１に進み、推測エンジン１１５は「タスク１」→「タスク３」→「タスク６」の順序関係から成るタスクシーケンスの終了予定日の導出によってサブタスクの終了予定日が更新される。

ステップＳ８０２に進み、推測エンジン１１５は「プロジェクトＡ」を構成する全てのタスクについてステップＳ８０３の処理を実行する。ステップＳ８０３では、現在のタスクの子孫タスクの中で終了予定日が最も遅いタスクの終了予定日を現在のタスクの終了予定日とする。

なお、子タスクを持つ親タスクの進捗度は、親タスクと子タスクとの関係として以下の状況を考慮して管理する必要がある。まず、親タスクの開始予定日は子タスクの開始予定日よりも前になければならない。また、親タスクの終了予定日は子タスクの終了予定日よりも後になければならない。また、親タスクはタスク処理の実体を持っており、子タスクと独立して実行されなければならない。さらに、子タスクは任意に追加されなければならない。

例えば親タスクの進捗度は、親タスク及び全ての子タスクの進捗度の平均とすることができる。これにより、全てのタスクの進捗度をそれぞれ計算できる。また、クリティカルタスクの進捗度を参照することにより、プロジェクトのクリティカルパスにおける進捗度を見ることができる。タスクの進捗度は、各タスクの残日数を導入すれば、以下に示した式（１）によって計算することができる。

タスクの進捗度＝（期間−残日数）／期間・・・（１）
例えばユーザ用端末に搭載されているブラウザ２０１は、前述のように計算されたクリティカルパスに基づき、実施例１〜４のようなガンチャートを表示できる。

図９は、プロジェクトの開始予定日前（計画時）にブラウザが表示するガンチャートの一例のイメージ図である。図９のガンチャートでは、「クリティカルパス１」及び「クリティカルパス２」を表示している。例えば「クリティカルパス１」は、「タスク１」→「タスク３」→「タスク６」の順序関係から成るタスクシーケンスである。また、「クリティカルパス２」は、「タスク６」である。なお、図９等に示したガンチャートでは、１ヶ月が２０日（４週間）で表されている。なお、図９のガンチャートは、例えば図２のシーケンス図で表した処理を利用して作成される。

図１０は、プロジェクトの開始予定日後にブラウザが表示するガンチャートの一例のイメージ図である。図１０のガンチャートは、クリティカルパスで遅れが生じた場合を表している。具体的には、９月１日時点で「タスク３」の残日数が１５日（３週間）となっている。

つまり、クリティカルタスクである「タスク３」には１週間の遅れが生じ、終了日が１週間遅延する。また、「タスク３」の終了日が１週間遅延することで、「タスク６」の開始日及び終了日は１週間遅延する。さらに、「タスク６」の終了日が１週間遅延することにより、「タスク５」の終了日は１週間遅延する。その結果、クリティカルパスは１週間の遅れとなる。

ワークフロー管理システム１００では、クリティカルパスの遅れが生じると、その旨をプロジェクトの管理者や各タスクの担当者に、ブラウザ２０１やＥメールを利用して通知できる。なお、図１０のガンチャートは、例えば図５のシーケンス図で表した処理を利用して作成される。

図１１は、プロジェクトの開始予定日後にブラウザが表示するガンチャートの他の一例のイメージ図である。図１１のガンチャートでは、「タスク８」が追加された場合を表している。具体的には、９月１日時点で期間が３週間の「タスク８」がクリティカルタスクである「タスク３」のサブタスクとして追加されている。

このとき、「タスク８」の親タスクである「タスク３」は「タスク８」よりも先に終了できない為、１週間の遅れが生じ、終了日が１週間遅延する。また、「タスク３」の終了日が１週間遅延することで、「タスク６」の開始日及び終了日は１週間遅延する。

さらに、「タスク６」の終了日が１週間遅延することにより、「タスク５」の終了日は１週間遅延する。その結果、クリティカルパスは１週間の遅れとなる。

ワークフロー管理システム１００では、クリティカルパスの遅れが生じると、その旨をプロジェクトの管理者や各タスクの担当者に、ブラウザ２０１やＥメールを利用して通知できる。なお、図１１のガンチャートは、例えば図５のシーケンス図で表した処理を利用して作成される。

図１２は、プロジェクトの開始予定日後にブラウザが表示するガンチャートの他の一例のイメージ図である。図１２のガンチャートでは、「タスク３」の一部を「タスク８」として分割し、期間が短縮された場合を表している。

具体的には、８月１５日時点でクリティカルタスクである「タスク３」の一部を期間が２週間の「タスク８」として切り出し、その「タスク８」を「タスク３」のサブタスクとして追加したものである。このため、「タスク３」の期間は４週間から２週間に短縮されている。

このとき、「タスク６」は「タスク３」の終了直後に開始できるため、「タスク６」の開始日を２週間早めることができる。ワークフロー管理システム１００では、プロジェクトの管理者や「タスク６」の担当者に、「タスク６」のスケジュールを２週間前倒しできる旨をブラウザ２０１やＥメールを利用して通知し、計画の変更を促すことができる。

さらに、「タスク６」のスケジュールを２週間前倒しに変更した場合は、プロジェクトの管理者や「タスク５」の担当者に、スケジュールの変更可能範囲を通知し、計画の変更を促すことができる。

すると、「タスク１」→「タスク３」→「タスク６」の順序関係から成るタスクシーケンスはクリティカルパスでなくなる。クリティカルパスは、「タスク５」だけとなる。ワークフロー管理システム１００では、プロジェクトの管理者や「タスク５」の担当者に、その旨を通知できる。

（実施例１〜３のまとめ）
本発明によるワークフロー管理システム１００では、任意のタスクをプロジェクト実行中に容易にブレークダウンできる。また、本発明によるワークフロー管理システム１００では、実際の業務でタスクのブレークダウンとタスクの順序関係が別なケースがしばしば発生するが、それに対応できる。また、本発明によるワークフロー管理システム１００では、タスクの進行管理ができる。

また、本発明によるワークフロー管理システム１００では、プロジェクトの進捗において特に管理対象とすべきものを提示することで、枝葉末節にとらわれず、プロジェクトを適正に管理できる。また、複数のクリティカルタスクをタスクの順序関係を元に一連のクリティカルパスとしてみることで、複雑な状況でもプロジェクトの進捗を容易に見ることができる。

また、本発明によるワークフロー管理システム１００では、クリティカルタスクの進行管理と組み合わせることで、プロジェクトの進捗上の問題の発生を容易に発見できる。さらに、本発明によるワークフロー管理システム１００では、タスクを追加する度にクリティカルパスを自動計算することでタスクの進捗を常に最新のプロジェクトの状態に基づいて管理できる。

これにより、本発明によるワークフロー管理システム１００では、単にクリティカルパス上の進捗が遅れているときだけでなく、タスクを追加したときにもリアルタイムにプロジェクト全体の進捗に対するリスクを検出し、ユーザに提示することができる。

本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

本発明によるワークフロー管理システムの一実施例のシステム構成図である。 ワークフロー管理システムにおけるクリティカルパス表示処理を表した一例のシーケンス図である。 タスクテーブルの一例の構成図である。 タスクシーケンステーブルの一例の構成図である。 ワークフロー管理システムにおけるタスクの追加処理を表した一例のシーケンス図である。 ＷＢＳによるタスクの階層化を表した一例のイメージ図である。 タスクシーケンスの終了予定日を導出する処理の一例のフローチャートである。 子タスクを持つ親タスクの終了予定日を導出する処理の一例のフローチャートである。 プロジェクトの開始予定日前（計画時）にブラウザが表示するガンチャートの一例のイメージ図である。 プロジェクトの開始予定日後にブラウザが表示するガンチャートの一例のイメージ図である。 プロジェクトの開始予定日後にブラウザが表示するガンチャートの他の一例のイメージ図である。 プロジェクトの開始予定日後にブラウザが表示するガンチャートの他の一例のイメージ図である。

符号の説明

１００ ワークフロー管理システム
１０１ ＧＵＩ提供部
１０２ レンダリングエンジン
１０３ 入出力制御部
１０４ プロセスチャート生成部
１１０ ワークフローエンジン
１１１ 検索エンジン
１１２ タスク制御部
１１３ タスク作成部
１１４ タスク実行部
１１５ 推測エンジン
１１６ ワークフロー記録部
１２０ データベース
１２１ 関連情報ＤＢ
１２２ タスクモデルＤＢ
１２３ タスクインスタンスＤＢ
１２４ 作業記録ＤＢ
１２５ 組織情報ＤＢ
１３０ Ｅメールサブシステム
２０１ ブラウザ

Claims (19)

1. 階層的に細分化された複数のタスクから成るワークフローを管理するワークフロー管理システムであって、
   タスク情報を格納している格納手段と、
   前記格納手段からタスク情報を取得し、そのタスク情報に含まれる前記複数のタスクの構造，前記複数のタスク間の依存関係，前記複数のタスクの状態及びスケジュールの情報から前記ワークフローのクリティカルパスを算出する算出手段と、
   前記算出手段が算出した前記クリティカルパスを画面上に表示させる表示制御手段と
   を備えたことを特徴とするワークフロー管理システム。
2. 前記算出手段は、前記クリティカルパスに含まれるタスクをクリティカルタスクとして管理し、前記クリティカルタスクの進捗に基づいて前記ワークフローの進捗を算出することを特徴とする請求項１記載のワークフロー管理システム。
3. 前記表示制御手段は、前記ワークフローの進捗に遅延が検出されると、その旨を前記画面上に表示させることを特徴とする請求項１記載のワーフフロー管理システム。
4. 前記算出手段が前記ワークフローの進捗に遅延を検出すると、その旨をユーザ用端末に送信する送信手段を更に有することを特徴とする請求項１記載のワークフロー管理システム。
5. 前記複数のタスク間の依存関係は、各タスクの順序関係を表すことを特徴とする請求項１記載のワークフロー管理システム。
6. 前記格納手段に、前記複数のタスクの構造，前記複数のタスク間の依存関係，前記複数のタスクの状態及びスケジュールの情報を登録する登録手段を更に有し、
   前記算出手段は、前記格納手段に格納されている前記複数のタスクの構造，前記複数のタスク間の依存関係，前記複数のタスクの状態及びスケジュールの情報に変更があると前記クリティカルパスを算出し直すことを特徴とする請求項１記載のワークフロー管理システム。
7. 階層的に細分化された複数のタスクから成るワークフローを管理するワークフロー管理方法であって、
   タスク情報を格納している格納手段からタスク情報を取得する取得ステップと、
   そのタスク情報に含まれる前記複数のタスクの構造，前記複数のタスク間の依存関係，前記複数のタスクの状態及びスケジュールの情報から前記ワークフローのクリティカルパスを算出手段により算出する算出ステップと、
   前記算出手段が算出した前記クリティカルパスを表示制御手段により画面上に表示させる表示制御ステップと
   を備えたことを特徴とするワークフロー管理方法。
8. 前記算出ステップは、前記クリティカルパスに含まれるタスクをクリティカルタスクとして管理し、前記クリティカルタスクの進捗に基づいて前記ワークフローの進捗を算出することを特徴とする請求項７記載のワークフロー管理方法。
9. 前記表示制御ステップは、前記ワークフローの進捗に遅延が検出されると、その旨を前記画面上に表示させることを特徴とする請求項７記載のワーフフロー管理方法。
10. 前記算出ステップで前記ワークフローの進捗に遅延が検出されると、その旨を送信手段によりユーザ用端末に送信する送信ステップを更に有することを特徴とする請求項７記載のワークフロー管理方法。
11. 前記複数のタスク間の依存関係は、各タスクの順序関係を表すことを特徴とする請求項７記載のワークフロー管理方法。
12. 前記格納手段に、前記複数のタスクの構造，前記複数のタスク間の依存関係，前記複数のタスクの状態及びスケジュールの情報を登録手段により登録する登録ステップを更に有し、
    前記算出ステップは、前記格納手段に格納されている前記複数のタスクの構造，前記複数のタスク間の依存関係，前記複数のタスクの状態及びスケジュールの情報に変更があると前記クリティカルパスを算出し直すことを特徴とする請求項７記載のワークフロー管理方法。
13. 記憶装置，演算処理装置を含むコンピュータにおいて実行される階層的に細分化された複数のタスクから成るワークフローを管理するワークフロー管理システムであって、
    前記コンピュータを、
    タスク情報を格納している格納手段と、
    前記格納手段からタスク情報を取得し、そのタスク情報に含まれる前記複数のタスクの構造，前記複数のタスク間の依存関係，前記複数のタスクの状態及びスケジュールの情報から前記ワークフローのクリティカルパスを算出する算出手段と、
    前記算出手段が算出した前記クリティカルパスを画面上に表示させる表示制御手段と
    して機能させるためのワークフロー管理プログラム。
14. 前記算出手段は、前記クリティカルパスに含まれるタスクをクリティカルタスクとして管理し、前記クリティカルタスクの進捗に基づいて前記ワークフローの進捗を算出することを特徴とする請求項１３記載のワークフロー管理プログラム。
15. 前記表示制御手段は、前記ワークフローの進捗に遅延が検出されると、その旨を前記画面上に表示させることを特徴とする請求項１３記載のワーフフロー管理プログラム。
16. 前記算出手段が前記ワークフローの進捗に遅延を検出すると、その旨をユーザ用端末に送信する送信手段として更に機能させるための請求項１３記載のワークフロー管理プログラム。
17. 前記複数のタスク間の依存関係は、各タスクの順序関係を表すことを特徴とする請求項１３記載のワークフロー管理プログラム。
18. 前記格納手段に、前記複数のタスクの構造，前記複数のタスク間の依存関係，前記複数のタスクの状態及びスケジュールの情報を登録する登録手段として更に機能させ、
    前記算出手段は、前記格納手段に格納されている前記複数のタスクの構造，前記複数のタスク間の依存関係，前記複数のタスクの状態及びスケジュールの情報に変更があると前記クリティカルパスを算出し直すことを特徴とする請求項１３記載のワークフロー管理プログラム。
19. 請求項１３乃至１８何れか一項に記載されるワークフロー管理プログラムを記録したコンピュータ読み取り可能な記録媒体。

Images