JP2006099728A - 共同アプリケーションにおけるワークフローの関連付け - Google Patents

Abstract

【課題】 ワークフローを開発および管理する方法を開示する。
【解決手段】 この方法は、ワークフローテンプレートおよび／または事前にプログラムされたコンポーネントからワークフローを開発できるようにし、ワークフローをスケジュールに関連付け、ワークフローを複数のタスクおよび複数の人間対人間または人間対コンピュータの対話ポイントとしてモデル化し、ワークフローの内部状態を永続的に記憶する。この方法は、ワークフローの開発、パッケージング、インストール、展開、有効化、関連付け、インスタンス化、および終了を制御するための、コンピュータによって実施されるフォームを採用する。
【選択図】 図２

Description

本発明はコンピュータソフトウェアに関し、より詳細にはワークフローの再利用に関する。

プロジェクトタスクの実行を管理する必要性は、人々が協力して作業する限り存在する。簡単だが典型的なタスク管理プロセスが、図１に示されている。ブロック１００から１３２によって表される行為は、準備のステップとみなすことができ、ブロック１３６から１４４によって表される行為は、プロジェクトの進行中の管理におけるステップとみなすことができる。まずは１００において、プロジェクト用の１つの目標または目標のセットが定義される。次に１０４において、目標を達成する完了日が設定される。次いで１０８において、完了日までに目標を達成するために実行しなければならないタスクのリストが作成される。また１１２では、タスクを実行できる参加者のリストが作成される。参加可能な参加者を前提として各タスクにどれぐらい時間がかかるかの見積もりを１１６において作成することが好ましい。タスク間の依存関係、すなわち１つまたは複数のどのタスクが完了してからでないと別のタスクを開始できないかを１２０において作成することも好ましい。１２４において、参加者がタスクの実行に参加できる時間帯を指摘することもできる。１２８では、前のステップからの情報を使用して、プロジェクト用のタスクのスケジュールが作成される。１３２では、タスクが必ず正しく時間どおりに完了するように、タスクのスケジュール内にマイルストーンすなわちチェックポイントが設置される。ブロック１３６では、プロジェクト自体の作業が開始し、タスクが実行され、経過が追跡される。１４０では、マイルストーンごとに設定された時間になると、関連するタスクおよびプロジェクト全体のステータスが評価される。１４４において、すべてのタスクが完了し、すべてのマイルストーンが満たされると、プロジェクトの目標は達成される。

図１に示されている前述の直線的なタスク管理プロセスは、プロセスのステップが再編成、結合、または削除される場合や、新しいステップが挿入される場合、何人かの参加者が他のタスクによって中断を強いられる場合、プロジェクト上の作業が進む間にプロジェクトの要件および目標が変わる場合、ならびにプロセスを調節しなければならない場合のような複雑な要素を無視している。タスク管理をさらにいっそう混乱させていることに、コンピューティングデバイスおよびコンピュータソフトウェアが組織にとって幅広く利用可能になるまで、タスクの計画、管理、および経過の追跡は、情報のリスト、チャート、図、および他の視覚表示を手動で作成および更新することによって行われていた。このような管理のツールは、手書きまたはタイプされることが多く、容易には修正できない。コンピュータに基づく意思伝達、すなわち電子メールが利用可能になるまで、タスクの実行を担当する参加者への連絡は、経過の追跡が困難で信頼性を欠くことが多い口頭でのやり取りや、時間のかかる手書きのメモの形態を取っていた。

タスク管理の歴史における発展の次なる段階は、コンピューティングデバイスおよびコンピュータソフトウェアによって可能となった。計画、リスト化、作図、チャート化、および通信に伴う雑務の多くは、コンピュータソフトウェアツールを力任せに適用することによってスピードアップされ、容易になった。しかしこれらの雑務は、依然として雑務や参加者の間での連携をほとんど行わずに実行されていた。これらの雑務の連携を図る試みの大半は、コンピュータプログラミングを少なからず伴い、高度なトレーニングを受けたコンピュータプログラマの時間、労力、およびコストを必要とするものであった。コンピュータソフトウェアツールを使用して、ビジネスプロセスの少なくともいくつかの部分を自動化することによって、ビジネスプロセス全体を通じた作業の流れについて考えることが容易になった。したがってコンピュータソフトウェアツールの開発は、所与のビジネスプロセスから、ビジネスプロセス全体を流れる「ワークフロー」へと焦点を移してきた。

ワークフローはビジネスプロセスではないことに留意されたい。ワークフローとは、ビジネスプロセス全体を通じて作業がどのように流れるかを抽象化したものである。たとえば、ドキュメントを承認するためのあるビジネスプロセスを仮定すると、ワークフローは、承認プロセスの各参加者が特定のドキュメントを受け取り、承認するのに伴い、承認プロセス全体を通じてそのドキュメントの経過を追跡するように作成することができる。この「ワークフロー」という抽象的な概念は、コンピュータプログラムにおいてモデル化され、ビジネスプロセス全体を通じたワークフローをサポートするためのコンピュータソフトウェアが、「ワークフロー」として知られるようになった。以降では、「ワークフロー」という用語は、このようなソフトウェアモデル、すなわちビジネスプロセス全体を通じて作業がどのように流れるかをサポートするソフトウェアプログラムを指すものとする。

ワークフローによって、個人および／または部署の間における作業の流れを定義し、経過を追跡することができる。たしかにワークフローはタスク管理に伴う多くの雑務を自動化することができるが、ワークフローの圧倒的な価値は、ワークフローによってタスク管理につきものの多くの雑務の間に提供される連携の中に存在する。より実務的には、ワークフローはビジネスタスクの自動化を補助し、適時適切な情報を適切な当事者へ電子的に回送する。参加者には、作業の保留が自動的に通知される。マネージャは、システムを介して迅速に承認を回送することができる。ワークフローは、決定および行為の依存関係および順序を含むプロジェクト内の作業の流れのグラフィカルな表示を提供することもできる。

ワークフローがタスク管理を著しく改善することに疑いの余地はない。しかしワークフローの開発は、高度なトレーニングを受けたコンピュータプログラマの高価な労働力を必要とし、ワークフローの展開は、相当な労力およびコストを必要とする。ワークフローは相互に類似していることが多いにもかかわらず、従来技術によるワークフローの開発および展開ツールのために、１つのプロジェクト用に開発されたワークフローを別のプロジェクトに適用することが困難または不可能となっている。必要とされているのは、１つのワークフローを複数のプロジェクト用に再利用することによって、１つのワークフローの開発に要した労力およびコストを多くのワークフローで償却する方法である。本発明は、１つのプロジェクト用に開発されたワークフローの構造およびメタデータを他のプロジェクトに関連付けるための方法および装置を提供することによって、ワークフローを再利用することを対象としている。

本発明の態様によれば、ワークフローテンプレートを使用してワークフローを作成するための、コンピュータ可読メディアを含む方法および装置が提供される。ワークフローテンプレートを使用することによって、この方法および装置は、１つのプロジェクト用に開発されたワークフローの構造およびメタデータを他のプロジェクトに関連付けることができる。ワークフローは、値をパラメータに割り当てること、新しいパラメータを挿入すること、既存のパラメータを無効にすること、既存の機能を有効にすること、既存の機能を無効にすること、および／またはコンピュータによって実施されるフォームを挿入することによって、スケジュールに関連付けられる。スケジュールへのワークフローの関連付けは、コンピュータによって実施されるフォームを表示するグラフィカルユーザインターフェースを介して制御される。

本発明の一態様によれば、ワークフローテンプレートを使用してワークフローが開発される。このテンプレートによって、事前にプログラムされたワークフローコンポーネントを挿入および／または削除することができ、ワークフローコンポーネント内のパラメータに値を割り当てることができ、新しいパラメータをワークフローコンポーネントに挿入することができ、ワークフローコンポーネント内に既に存在するパラメータを無効にできることが好ましい。開発されたワークフローは、好ましくはパラメータに値を割り当てること、新しいパラメータを挿入すること、および／または既存のパラメータを無効にすること、ならびにワークフローおよび関連データを永続的なストアに保存することによって、インストール用にパッケージされる。ワークフローは、インストール、展開、および／または有効にできることが好ましい。ワークフローは、インスタンス化および／または終了することができる。

本発明のさらに別の態様によれば、インスタンス化され、黙認(acquiescence)の状態に達したワークフローは無効にすることができ、ワークフローの内部状態について記述するパラメータ値は任意の長さの時間にわたって永続的に保存することができ、この永続的に保存されたパラメータ値を使用してワークフローを復元し、再び有効にすることができる。

本発明の他の態様によれば、ワークフローテンプレートを開発し、ワークフローテンプレートおよび／または事前にプログラムされたワークフローコンポーネントを使用することによって、既存のワークフローの構造およびメタデータが再利用される。ワークフローは、複数の人間対人間および／または人間対コンピュータの対話ポイントとしてモデル化される。対話ポイントは、任意の順序で存在することができる。ワークフローは、複数のタスクから構成することができる。１つのタスクは、入力データの有無を問わず、単一のユーザによって完了することができる。複数のタスクは、入力データの有無を問わず、単一のマネージャによって完了することができる。タスクは、１人または複数のユーザに割り当てること、１人または複数のユーザに委任すること、および／または１人または複数のユーザに転送することができる。ワークフロー内のタスクは、サードパーティによって開発された、コンピュータによって実施されるフォームを使用して定義することができる。ワークフローを開発すること、ワークフローをパッケージすること、ワークフローをインストールすること、ワークフローを展開すること、ワークフローを有効にすること、ワークフローをスケジュールに関連付けること、ワークフローをインスタンス化すること、およびワークフローを終了することは、コンピュータによって実施されるフォームを表示するグラフィカルユーザインターフェースを介して制御される。

前述の説明から容易に理解できるように、本発明は、１つのプロジェクト用に開発されたワークフローの構造およびメタデータを他のプロジェクトに関連付けることによって、既存のワークフローの構造およびメタデータを再利用するための方法および装置を提供する。

本発明の前述の態様および付随する利点の多くは、以降の詳細な説明を添付の図面と併せて参照することによってよりよく理解するほど、より容易にその真価を認識できるであろう。

本発明の実施形態は、１つのプロジェクト用に開発されたワークフローの構造およびメタデータを他のプロジェクトに関連付け、ワークフローおよびワークフローテンプレートを開発して使用するための、コンピュータ可読メディアを含む、コンピュータによって実施される方法および装置（ツール）を提供する。ワークフローは、直接またはワークフローテンプレートを使用して作成することができる。説明の最初の部分は、ワークフローの定義と、ワークフローがどのようにして直接作成されるかの説明を対象としている。ワークフローテンプレートと、ワークフローテンプレートを使用したワークフローの作成については、その後で説明する。

ワークフローは、（ａ）ビジネスプロセスの手続き的なステップ、（ｂ）ビジネスプロセスの各ステップに関与する人物、（ｃ）ビジネスプロセスの各ステップで要求される入力情報および出力情報、ならびに（ｄ）ビジネスプロセスの各ステップで必要とされるツールなど、ビジネスプロセスに関する情報を含む。当業者なら容易に理解することだが、ワークフローは、こうした典型的なタイプの情報に加えて他のタイプの情報を含むこともできる。

本発明の典型的な一実施形態では、ワークフローが基づくモデルは、人間のワークフロー、すなわち通常はワークフローライフサイクルにおける人間の対話ポイントに関連付けられているイベントおよびアイテムを忠実にモデル化したものである。このようなワークフローのモデル化によって、人間／ワークフローの対話中における予測困難なイベント、たとえば休暇、疾病、プロセス内のステップを失念することなどが提示される。考察を容易にするために、ワークフローと対話する人間をワークフローに関するその役割によって次のように呼ぶ。（ａ）ワークフローを作成して制御する人を所有者、（ｂ）ワークフローおよび／またはワークフローコンポーネントの全体または一部を設計して実装する人を開発者、（ｃ）ワークフローによって制御される１つまたは複数の行為に参加する人を参加者と呼ぶ。行為は、検討、修正、および承認を含むが、これらには限定されない。「役割」が重複可能なことは明白である。たとえば所有者は、開発者および／または参加者を兼ねる場合もある。ワークフローからの入力に応答するエンティティが「行為者」である。行為者は、参加者である場合もあり、コンピューティングデバイスである場合もある。人間の行為者は、グラフィカルユーザインターフェースフォーム（ＧＵＩフォーム）を使用して、本発明の実施形態と対話することが好ましい。ＧＵＩフォームは、アプリケーション、ウェブページ、または同様のグラフィカルユーザインターフェースコンポーネント内のウィンドウとすることができ、これによって人間の行為者は、ビューに入り、選択を行い、および／または情報を入力することができる。

たとえば本発明の典型的な実施形態、すなわちワークフローを開発して使用するための方法および装置は、Ｍｉｃｒｏｓｏｆｔ（登録商標）ＳｈａｒｅＰｏｉｎｔ（商標）Ｐｏｒｔａｌ Ｓｅｒｖｅｒ（ＳｈａｒｅＰｏｉｎｔ）などのコラボレーティブなコンピュータアプリケーション内でサポートすることができるが、これには限定されない。ＳｈａｒｅＰｏｉｎｔは、さまざまなネットワーク化されたコンピューティングデバイスおよびネットワーク化されたコンピューティングシステムからの情報を１つのソフトウェアエンティティに統合して、便利なポータル展開および管理を提供する拡張可能なポータルサーバである。ポータルはウェブサイトなどのサイトであり、インターネットなどのネットワークへのゲートウェイとして機能することを当業者なら理解するであろう。ウェブサイトポータルは、リンク、コンテンツ、およびサービスの集合体であり、ニュース、天気、娯楽、商用サイト、チャットルームなど、ユーザが興味を抱きそうな情報へユーザを導くように設計されている。Ｙａｈｏｏ！、Ｅｘｃｉｔｅ、ＭＳＮ．ｃｏｍ、およびＮｅｔｓｃａｐｅ ＮｅｔＣｅｎｔｅｒは、ポータルの例である。ＳｈａｒｅＰｏｉｎｔによって提供されるサービスを総称して、Ｗｉｎｄｏｗｓ（登録商標）ＳｈａｒｅＰｏｉｎｔ（商標）Ｓｅｒｖｉｃｅｓ（ＷＳＳ）と呼ぶ。ＷＳＳと対話するために使用されるＧＵＩフォームをＷＳＳフォームと呼ぶ。

本発明の典型的な実施形態は、ＳｈａｒｅＰｏｉｎｔサービスとして動作する。ＳｈａｒｅＰｏｉｎｔサービスは、コラボレーションおよび情報共有を提供し、また他のソフトウェアアプリケーションとの統合を提供することもできる。図２は、本発明の典型的な実施形態をサポートするＳｈａｒｅＰｏｉｎｔの主要なコンポーネントと、そうした主要なコンポーネントの間の関係を示すブロック図である。示されている主要なコンポーネントは、アプリケーション１５６、Ｗｉｎｄｏｗｓ（登録商標）ＳｈａｒｅＰｏｉｎｔ Ｓｅｒｖｉｃｅｓ Ｗｏｒｋｆｌｏｗ Ｏｂｊｅｃｔ Ｍｏｄｅｌ（ＷＳＳ Ｗｏｒｋｆｌｏｗ ＯＭ）１５８、およびＷｉｎｄｏｗｓ（登録商標）Ｗｏｒｋｆｌｏｗ Ｓｅｒｖｉｃｅｓ内のワークフローエンジンなどのワークフローエンジン１７０を含む。「オブジェクトモデル」は、アプリケーションプログラミングインターフェース（ＡＰＩ）と、ＡＰＩによって使用されるデータ構造、すなわちＡＰＩに書き込まれた関数に渡され、その関数から戻されるデータ構造とを含む。ＷＳＳ Ｗｏｒｋｆｌｏｗ ＯＭ１５８は、Ｗｉｎｄｏｗｓ（登録商標）ＳｈａｒｅＰｏｉｎｔ Ｓｅｒｖｉｃｅｓ Ｗｏｒｋｆｌｏｗ ＡＰＩと、Ｗｉｎｄｏｗｓ（登録商標）ＳｈａｒｅＰｏｉｎｔ Ｓｅｒｖｉｃｅｓ Ｗｏｒｋｆｌｏｗ ＡＰＩによって使用されるデータ構造を含む。アプリケーション１５６は、ワークフロー対応型またはワークフロー非対応型とすることができる。ワークフロー対応型アプリケーション１５０は、ワークフローに特有の機能を含むアプリケーションである。ワークフロー非対応型アプリケーション１５４は、サービスとしてのワークフローとの対話はできるが、ワークフローに特有の機能は含まないアプリケーションである。

ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８は、ワークフロー状況情報１６２をワークフローエンジン１７０へ渡す際に経由するインターフェースである。ワークフローエンジン１７０はワークフローを実行し、スケジューリング、意思伝達、データの永続性、役割の定義、およびタスクの経過の追跡に関するサポートをワークフローに提供する。ワークフローは、命令１６６を作成させることができる。ワークフローエンジン１７０は、ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８を介してアプリケーションにワークフロー命令１６６を渡す。アプリケーション１５６は、ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８と対話して、ＳｈａｒｅＰｏｉｎｔサービスにアクセスすることに留意されたい。ワークフローは、ＳｈａｒｅＰｏｉｎｔサービスであるため、ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８を介してアクセスされる。したがってアプリケーション１５６は、ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８を介してワークフローにアクセスすることができる。またワークフローは、ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８とは直接対話しないことにも留意されたい。ワークフローエンジン１７０が、ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８と対話して、ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８へのインターフェースをワークフローに提供する。

ワークフローはワークフローエンジンと対話し、ワークフローエンジンはＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８と対話する。たとえば参加者は、ワークフローの状況を変更することを意図するアクションをアプリケーション１５６内で実行することができる。アプリケーション１５６は、ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８にメッセージを渡す。このメッセージは、ワークフローを識別し、ワークフローの状況の変更を指定する情報を含む。ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８は、アプリケーションからのメッセージをワークフロー状況情報１６２に変換し、そのワークフロー状況情報１６２をワークフローエンジン１７０に渡す。ワークフローエンジン１７０は、ワークフローエンジン１７０が実行されているワークフローの中から意図するワークフローを選択し、アプリケーション１５６からのメッセージ内で指定されているワークフローにワークフロー状況情報１６２を渡す。

ワークフローエンジン１７０は、ワークフロースケジュールに沿ってワークフローを進めることによって、ワークフローを実行する。ワークフロースケジュールは、タスク、ワークフロー論理、およびさまざまなメタデータを含むデータ構造である。本発明の典型的な一実施形態では、Ｗｉｎｄｏｗｓ（登録商標）Ｗｏｒｋｆｌｏｗ Ｓｅｒｖｉｃｅｓ内で実行するのに適しており、かつＷＳＳワークフローに関連付けられているＷＳＳワークフロースケジュールは、ワークフローのタスクおよび論理を含むＸＭＬ構造である。このようなＷＳＳワークフロースケジュールは、ウェブサイトなどの適切なサイトにインストールされたワークフローパッケージ内にＸＭＬファイルとして保存することができる。

ワークフロースケジュールに沿って進行する間、ワークフローはドキュメントおよびリスト上で動作する場合が多い。ＳｈａｒｅＰｏｉｎｔのコンテキストでは、ドキュメントとは、アプリケーションによって作成された作業の任意の自己完結した断片であり、永続的に保存する場合は一意のファイル名を与えられ、これによって検索することができる。ＳｈａｒｅＰｏｉｎｔのコンテキストでは、リストとは、リレーショナルスキーマ用に明確に定義されたフィールドタイプを抽出したものである。リストは、１つまたは複数のドキュメントを含むことができる。リレーショナルスキーマと同様に、リストはある種の独特な特徴を有し、これによって１つのリストは別のリストから区別される。リストの特定のグループは、「プロファイル」を使用することによって、複数のリストから選択することができる。プロファイルとは、希望のリストの特徴を備えたフィルタである。１つのリストに適用される関数は、プロファイルを複数のリストに適用した結果として生じるリストに適用することもできる。より具体的な種類のリストはドキュメントライブラリと呼ばれ、ドキュメントを含むことができるだけでなく、ドキュメントに関するデータおよびドキュメント内に含まれるデータを検索してフィルタにかけることが容易になるような方法でドキュメントを整理することもできる。たとえばワークフロードキュメントは、そのドキュメントが１人または複数の参加者によって承認されることを必要とする。ドキュメントのバージョンは、ワークフローライフサイクルの過程で作成、キャンセル、修正などを行うことができる。このようなドキュメントに関連付けられたワークフローは、こうした行為を管理し、経過を追跡する。

ワークフローは通常、ワークフロー定義として開始する。ワークフロー定義とは、Ｗｉｎｄｏｗｓ（登録商標）Ｗｏｒｋｆｌｏｗ Ｓｅｒｖｉｃｅｓワークフロースケジュールと、ワークフローを完全に指定するのに必要なサポートコードのファイルおよびフォームとを含むソフトウェアのインストール可能なパッケージである。具体的なワークフローは、ワークフロー定義がワークフローの関連付けおよびワークフローのパラメータ化のプロセスを経た場合に作成される。ワークフローの関連付けとは、ワークフローをリストまたはプロファイル上で利用できるようにするプロセスである。ワークフローのパラメータ化とは、参加者、締め切り、回送順序などのパラメータのセットを収集し、ワークフローに提示するプロセスである。いくつかのパラメータ化は、ワークフローがリストまたはプロファイルに関連付けられた場合に生じる。いくつかのパラメータ化は、ワークフローが開始された場合に生じる。ワークフローの設計者、すなわちワークフローの開発者またはワークフローの所有者は、どのパラメータを含むか、そしてそれらの値をいつ要求するかを決定する。

ワークフローは、開始から終了まで行為者からの入力を必要とせずに実行することもできるが、ワークフローを進める上で行為者からの何らかの外部入力が必要となる可能性の方が高い。行為者、すなわち参加者およびコンピューティングデバイスは、ワークフローエンジン、すなわちＷｉｎｄｏｗｓ（登録商標）Ｗｏｒｋｆｌｏｗ Ｓｅｒｖｉｃｅｓ上で実行されるワークフローに対して、ワークフロー内の特定の間隔を置いた明確に定義されたポイントにおいて、外部入力を提供することができる。このようなポイントは「タスク」と呼ばれる。概念的には、タスクは、始まり、終わり、およびステータス情報などの関連付けられたメタデータを有する作業の単位とみなすことができる。各ワークフローは、タスクリストのセットを含む。各ワークフローは、そのタスクをタスクリストに記憶する。

ワークフローは、リスト（ドキュメントライブラリは一種のリストである）またはコンテンツタイプに関連付けることができる。ワークフローの関連付けの設定は、リストのプロパティとして保存される。これらの設定は、リストがコピーされた場合も維持される。これらの設定は、ライブラリがコピーされた場合も維持される。

本発明のＷＳＳの実施形態では、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅ ＩｎｆｏＰａｔｈ（商標）やＭｉｃｒｏｓｏｆｔ Ｖｉｓｕａｌ Ｓｔｕｄｉｏ（商標）などのアプリケーションを使用してタスクを定義することができ、あるいは独立系ソフトウェアベンダ（ＩＳＶ）によって開発されたカスタムデータ収集フォーム、すなわちＧＵＩフォームまたはＷＳＳフォームを使用してタスクを定義することもできる。タスクは参加者によって完了される。たとえば参加者は、タスク用のリンクをクリックして、そのタスク用のフォームを表示することができる。参加者は、そのフォームにデータを入力し、そのフォームの「ステータス」が「完了」であることを示すチェックボックスを選択するなどして、そのフォームが完了していることを何らかの形で示す。そのフォームを提供するアプリケーション１５６は、ステータス情報をＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８に渡し、ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８は、そのステータス情報をワークフロー状況情報１６２としてワークフローエンジン１７０に渡す。ワークフローエンジン１７０はこの情報を受け取り、ワークフロー命令１６６を返して、タスクが完了していることをワークフローの所有者に通知する。同様のプロセスにおいて、ワークフローの所有者、すなわちプロジェクトのマネージャは、同様の要件を有するタスクのセットを選択し、それらを完了または承認済みとしてマークすることによって、複数のタスクを完了することができる。

本発明の典型的な実施形態は、「ＴｏＤｏ」と呼ばれる特定の種類のＷＳＳタスクを使用する。ＴｏＤｏとは、行為者によって達成されるタスクである。ＴｏＤｏは、完了、キャンセル、または委任することができる。１つのＴｏＤｏは、他のＴｏＤｏと同調して適切なアクションを実行し、このアクションによって、１つまたは複数の適切なメッセージがワークフローエンジン１７０に送信される。ワークフローは、ＴｏＤｏを作成して、これを一連の行為者に宛てることによって、外部入力を要求するプロセスを開始する。ＴｏＤｏは、ＷＳＳタスクの一種であるため、ＷＳＳタスクリストへ挿入し、行為者に割り当てることができる。ＴｏＤｏは拡張可能であり、ワークフローエンジン内で実行されるスケジュール内の特定のポイントにおいてワークフローによって必要とされるデータを表す任意のスキーマを有することができる。ＴｏＤｏは、他の行為者に委任または転送することができる。必要とする入力データがない場合、ＴｏＤｏはすぐに完了することができる。ＴｏＤｏを完了する上で参加者からのデータが必要とされる場合、そのデータは、参加者にフォームを提示することによって収集される。そのデータは、フォームに入力された後、ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８に提示され、次いでＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８は、ワークフロー状況情報１６２をワークフローエンジン１７０に提示する。

情報は、ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８からワークフローエンジン１７０へメッセージとして渡される。典型的な実施形態では、メッセージのタイプは、起動、送信、および受信を含む。メッセージは、ＷＳＳ内の「保存」イベントによって作成される。たとえばワークフローエンジン内でのワークフローの状況推移の一環として、ワークフロースケジュールは、ワークフロータスクを作成し、「保存」イベントの引き受けを指定すること、すなわち、どのソフトウェアオブジェクトが「保存」イベントを通知されるかを指定することができる。ワークフローエンジン内のワークフロースケジュールによるワークフロータスクの作成は、ＷＳＳ内でＴｏＤｏを作成し、適切なＴｏＤｏイベントを登録するアクションへと変換される。本発明の典型的な一実施形態では、参加者がフォームを提出して、ＴｏＤｏを完了すると、ＴｏＤｏは、下記のアクションを実行させる要求を提示することによって、サポートするデータベース内で「保存」イベントを実行する。

１．データベースとのやり取りを行い、分類されていないイベントを使用して、ＴｏＤｏに関するメタデータをフェッチする。
２．プレイベントハンドラを実行し、アクセス制御リスト（ＡＣＬ）チェックを実施する。
３．要求のペイロードを保存し、イベントキューのペイロードを構築する。データベースサーバは、「保存」オペレーションによってデータベース内に生じる変更を計算する。中間層で行われたフィルタリングに基づいて、データベースサーバは、分類されていないイベントのセットを、適切な分類されたイベントの特定のセットへと絞り込む。
４．データベースと別のやり取りを行い、「保存」トランザクションを実行する。「保存」トランザクション内で下記のアクションを実行する。
ａ．データベース内で「保存」を行う。
ｂ．オペレーション用に分類されたイベントを作成し、イベントキューに組み込む。
ｃ．ワークフロースケジュールをロックする。
ｄ．ワークフロースケジュールを順番に並べ、この順番に並べたワークフロースケジュールをトランザクションの結果として返す。
５．ワークフロースケジュールが首尾よく得られると、中間層で「保存後」イベントを非同期的に送達する。

他の何らかのマシン上の他の何らかのプロセスがワークフロースケジュールをロックしていた可能性がある場合、アイテム４．ｃにおいてワークフロースケジュールのロックに失敗することがあり、この場合、ワークフロースケジュールは順番に並べられて返され、トランザクションは終了するが、「保存後」イベントは送達されない。適応性のあるタイミングスキームに基づいて、この「保存後」イベントは、ワークフロースケジュールをロックできる時点で送達される。ＴｏＤｏは、完了すると、前述と同様のプロセスを使用して削除することができる。このようなＴｏＤｏの削除によって、ＷＳＳ Ｗｏｒｋｆｌｏｗ ＯＭは、ＴｏＤｏと、そのＴｏＤｏ上の適切な引き受けを削除する。

ワークフローがＴｏＤｏを作成すると、そのＴｏＤｏと、ワークフローエンジン１７０内で実行され、そのワークフローに関連付けられているスケジュールとの間に１つまたは複数のリンクが確立される。ＴｏＤｏは、そのＴｏＤｏにデータを提示するために使用されるフォームによって作成されているイベントの１つまたは複数を登録する。参加者がフォームの１つまたは複数のフィールドにデータを入力すると、イベントが作成される。ＴｏＤｏはイベントを検出し、提示されたデータを処理し、その処理したデータをワークフロー対応型アプリケーション１５０またはワークフロー非対応型アプリケーション１５４に渡す。ワークフローは、ワークフロー命令１６６に応答することができる。典型的な命令は、ＴｏＤｏを更新することである。ＴｏＤｏを更新する場合、複数の一貫性検査が実行される。すべての検査に合格すると、非同期的なイベントは、ＴｏＤｏを開始したスケジュールへ送達するためにキューに組み込まれる。一貫性検査は、同期化、セキュリティ、およびデータの妥当性に関する検査を含むが、これらには限定されない。データベースの一貫性を維持するために、非同期的なイベントのキューへの組み込みは、ＴｏＤｏに対する更新と同じトランザクション内で生じる。イベントがワークフロースケジュールへの送達用としてキューに組み込まれると、更新を提示した参加者は、更新が首尾よく送達された旨を通知される。

イベントは、複数の理由からワークフローへ非同期的に送達される場合がある。１つの理由は、一実施形態ではスケジュールのインスタンスを１つしか認めることができず、そのスケジュールのそのインスタンスは、単一の、任意の、中間層のマシン上で実行することしか認められないことである。１台の中間層のマシン上に到達する新しいイベントを、別の中間層のマシン上で実行されているスケジュールのインスタンスへ回送することは可能だが、このようなメカニズムによって設計全体に対して不必要な複雑さが加わる。したがってスケジュールがアクティブな実行状態にある場合に、実行中のスケジュールへ新しいイベントを送達する回送メカニズムが存在しないと仮定すると、ワークフローイベントは、後で消費するためにキューに組み込まなければならない。そのそれぞれのワークフロースケジュールによって消費されるのを待っている保留中のイベントがキュー内に存在すると、それらのイベントをキューから外すメカニズムを設計しなければならない。スケジュールがイベントを消費できるかどうかを同期的に問い合わせるのは効率が悪いため、キューから外すプロセスは非同期的に処理される。イベント送達用の非同期的にキューから外すメカニズムに依存することは、名目上のコード実行パスと、例外的なコードパス、すなわちイベントの送達および消費が完了できず、後で再試行しなければならない場合との双方において、単一のコードパスを使用できることも意味している。必要に応じて、イベントキューはデータベース内のテーブルとすることもでき、メモリ内に保持する必要はないことに留意されたい。これによって、設計に堅牢性が加わり、壊滅的なシステム障害が防止される。

イベントは、そのイベントを所有するワークフローが実行状態へとブートしたら、そのワークフローによって直接キューから外されることが好ましい。ワークフローは、稼動すると、そのワークフロー用に設計されたイベントをイベントキューから先入れ先出し順に取り出すことによって、そのイベントを消費する。ワークフロー用に設計されたイベントスタック上のイベントは、スケジュールに沿ってワークフローを最後まで推し進め、最終的にスケジュールを完了させる。

本明細書に記載された典型的な実施形態では、ＷＳＳは、ワークフローエンジン、すなわちＷｉｎｄｏｗｓ（登録商標）Ｗｏｒｋｆｌｏｗ Ｓｅｒｖｉｃｅｓをホストし、ワークフローの状況に対する永続的な記憶を提供する。ワークフローが実行されて完了に至るまでの間には、ワークフローの状況を永続的に記憶できるポイントがある。ワークフローの状況は、ワークフローの開発者によってスケジュール内で明確に定義されたポイント、または黙認のポイントで取り込み、永続的に記憶することができる。黙認のポイントとは、ワークフローが黙認の状態に入るポイント、すなわち有用な作業や対話がまったく発生しない時間である。基本的にワークフローは、何かが起こるのを不確定な長い時間にわたって待っている。そのような状況が検出されると、ワークフローはトランザクションポイントを設定する。トランザクションポイントにおいて、ワークフローは、ワークフローの内部状態について記述するデータを収集し、その内部状態のデータを対応するスケジュールと共にデータベース内に永続的に記憶する。このトランザクションと共に、他のスキーマ管理を行うこともできる。スケジュールのワークフローの状況は、順番に並べられた形でバイナリまたはＸＭＬのいずれかで記憶することができる。トランザクションポイントでは、ワークフローを「休止」状態に置くことができる。ワークフローの休止状態とは、ワークフロースケジュールが、データベース内で持続されているスタティックストレージ以外のコンピューティングリソースをまったく消費しない状態である。たとえば、ＴｏＤｏタスクを完了させる上ですべてのワークフロースレッドがブロックされ、そのワークフローへ送達される保留中のイベントがまったくない場合、そのワークフローの排他的ロックが解除され、そのワークフローは休止状態へ移行することができる。アクティブなプロセスは、自分の所属するワークフローを呼び覚ます必要があるイベントを探して、イベントキューを継続的にモニタすることが好ましい。このようなワークフローが識別されると、適切な中間層のマシンが、そのワークフロー用のホストとして指定される。そのワークフロー用のバイナリコードおよび状況情報が、永続ストレージからそのホストマシンにロードされる。ワークフローは、実行状態へとブートされる。

プロジェクトのマネージャ、すなわちワークフローの所有者が、ＳｈａｒｅＰｏｉｎｔなどのコラボレーティブなアプリケーション内で実行される本発明の実施形態をどのように使用して、プロジェクトを管理するためのワークフローを作成するかに関する前述の説明は、ワークフローに関する上記の説明によって裏付けられる。まずは、ワークフローの開発者がワークフロー定義を開発する。開発者はワークフロー定義をパッケージして、そのワークフロー定義をサーバ上にインストールし、これによってワークフローの所有者は、そのワークフロー定義にアクセスできるようになる。次いで所有者は、そのワークフロー定義を展開する、すなわち特定のプロジェクト用に使用するためにそのワークフロー定義をコピーする。所有者は、その展開したワークフロー定義を有効にし、すなわちアクティブにし、その展開したワークフロー定義をプロジェクト用のドキュメントのセットに関連付け、その展開したワークフロー定義をインスタンス化する、すなわちプロジェクト用のワークフローを作成する。最後に所有者は、そのプロジェクト用のワークフローを開始する。その後ワークフローが終了するまで、参加者は、ＧＵＩフォームを使用することによってワークフローと対話して、そのプロジェクト用のタスクを完了し、所有者は、ＧＵＩフォームを使用して、進行などをチェックする。このプロセスは「ワークフローライフサイクル」と呼ばれ、図３の流れ図によって示され、これについては以降で詳しく説明する。

図３に示されているように、ワークフローのライフサイクルは、８つのステージから構成される。各ステージの簡単な定義を次に述べ、各ステージの詳細については、その後に説明する。第１のステージは、開発ステージ２００である。開発ステージでは、ワークフローが定義され、ワークフローを含む部分や要素が作成される。第２のステージは、パッケージングステージ２０４である。パッケージングステージでは、開発ステージで作成された部分や要素を使用して、ワークフロー自体がセットアップされる。ワークフローのセットアップは通常、開発ステージ２００が完了した後で行われるが、Ｍｉｃｒｏｓｏｆｔ ＦｒｏｎｔＰａｇｅ（ｃ）のようないくつかのコンピュータアプリケーションでは、開発ステージ２００の最中にワークフローを編集することができる。第３のステージは、インストールステージ２０８である。インストールステージでは、ワークフローパッケージがサーバ上にロードされる。第４のステージは、展開ステージ２１２である。展開ステージでは、ワークフローの定義がサーバ上にインストールされ、ワークフローの参加者が、そのワークフローに関連付けられる。第５のステージは、有効化ステージ２１６である。有効化ステージでは、ワークフローの所有者はワークフロー内の機能をオンにし、これによって他者（参加者）は、そのワークフローを見ることができる。第６のステージは、関連付けステージ２２０である。関連付けステージでは、所有者はワークフローをドキュメントライブラリおよび／またはリストに関連付ける。第７のステージは、インスタンス化ステージ２２４である。インスタンス化ステージでは、ワークフローのパラメータ値が設定され、ワークフローが開始される。第８の最終ステージは、終了ステージ２２８である。終了ステージは、ワークフロー内のタスクのすべてが完了した場合、またはワークフローがキャンセルされた場合に発生する。

各ステージの詳細な説明を理解する際の補助として、ワークフローの例を使用する。ビデオ編集ツールの開発に関わるプロジェクト上で作業している参加者のグループによって、典型的なワークフローが使用される。

開発ステージ２００では、ワークフローまたはワークフローテンプレートを含む部分が、ワークフローの開発者またはワークフローの所有者によって、開発および／または集約される。開発ステージではワークフローの開発者が主要な役割を果たすため、開発ステージ２００ではワークフローの開発者しか言及されていない。開発および／または集約される部分は、（ａ）ワークフロースケジュール、（ｂ）ワークフローによって使用されるデータのビュー、またはワークフローに関連するデータのビュー、（ｃ）ワークフローをサポートする、コンピュータによって実施されるフォーム、および（ｄ）ワークフローに関するメタデータを含むが、これらには限定されない。開発および／または集約される部分は、Ｍｉｃｒｏｓｏｆｔ Ｖｉｓｕａｌ Ｓｔｕｄｉｏ（ｃ）やＭｉｃｒｏｓｏｆｔ ＦｒｏｎｔＰａｇｅ（ｃ）のようなコンピュータアプリケーションを使用して作成することができる。開発ステージ２００では、ワークフロー定義内の各部分ごとに、その部分と、ＳｈａｒｅＰｏｉｎｔ、および／またはクライアントコンピューティングデバイス上で実行されるＭｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅ（ｃ）のようなアプリケーションとの間で対話をセットアップすることができる。

開発および／または集約される部分は、前述のように直接作成することもできるが、ワークフローテンプレートを使用してワークフローを作成する方がより有利である。ワークフローテンプレートをコピーし、そのワークフローテンプレートのコピーを修正して、希望の新しいワークフローへと変更することによって、ワークフローテンプレートからワークフローを作成する。ワークフローテンプレートによって、１つのプロジェクト用に開発されたワークフローの構造およびメタデータを他のプロジェクトに関連付けることができる。ワークフローテンプレートはＧＵＩフォームではなく、むしろＧＵＩフォームを使用して修正されるワークフローコンポーネントのセットであることに留意されたい。

図４Ａは、ワークフローの部分や要素が直接またはワークフローテンプレートを使用して開発および集約される典型的な順序を示す流れ図である。ワークフローを直接開発する場合、それぞれの部分や要素は、その部分や要素のタイプによって決定されるデフォルト値を使用して作成される。ワークフローテンプレートを使用してワークフローを開発する場合、部分や要素のほとんどを利用することができ、新しいワークフローの要件を満たすように修正するだけですむ可能性が高い。図４Ａを参照すると、２４０においてワークフローのトップレベルのスケジュールが定義される。次いで２４４において、ワークフローを定義するデータおよびメタデータのビューが定義される。２４８では、ワークフローのスケジュール、ビュー、およびメタデータに関する情報を提示および収集するように設計されたフォームテンプレートが、スケジュール、ビュー、およびメタデータをサポートするためのフォームを設計する上で使用するために、開発者に提示される。次いで２５２では、必要に応じて、カスタムコンピュータコードが作成される。最後に２５６において、ワークフローのタスクがいつどのようにして経過を追跡されるかが定義される。

開発ステージ２００では、ワークフローの開発者が前述のステップを完了できるようにフォームが提供される。図４Ｂは、ワークフローを設計するための典型的なＧＵＩフォーム２３９である。このＧＵＩフォーム内のフィールド２４１は、ワークフロー内のステップの名前を入力するために提供されている。ワークフローの典型的なステップ２４３が、フォームの右側に表示されている。この典型的なステップは、「送信して承認を求める」および「ベンダを選択する」である。「送信して承認を求める」のステップは、２つの下位基準、すなわち「マネージャ側で承認する」および「制御側で承認する」を有する。図４Ｂでは、編集用に選択されているステップは「送信して承認を求める」であることがハイライトによって示されている。「送信して承認を求める」のステップをクリックすると、ステップ名（図示せず）がフィールド２４１内に表示される。「送信して承認を求める」のステップは、ドロップダウンメニューの表示フィールド２４５内で「レギュラーステップ」と指定されている。他のタイプの指定も、ドロップダウンメニュー内に含まれる。ワークフロー内では、ステップの条件と、その条件が満たされた場合に発生するアクションとを設定することができる。

図４Ｂに示されている典型的なワークフローの「送信して承認を求める」のステップでは、２つの条件が、それぞれ関連付けられたアクションと共に示されている。第１の条件は「金額が１０００ドル以下の場合」であり、この第１の条件が満たされた場合に発生するアクションは、「現時点でのドキュメントをマネージャへ割り当てて、承認を求め、次いでサブステップ「マネージャ側で承認する」を実行する」である。第２の条件は「金額が１０００ドルを上回る場合」であり、この第２の条件が満たされた場合に発生するアクションは、「現時点でのドキュメントを制御側へ割り当てて、承認を求め、次いでサブステップ「制御側で承認する」を実行する」である。この２つの「アクション」は、図４Ｂの右側に示されている前述の２つの下位基準、「マネージャ側で承認する」および「制御側で承認する」に対応していることに留意されたい。

図４Ｂに示されている条件およびアクション内の特定の語に下線が引かれていることに留意されたい。本明細書で説明されている本発明の典型的な実施形態では、下線の語を変更することができる。下線の条件およびアクションは、たとえばワークフローを作成するために使用されるワークフローテンプレートの一部であるＧＵＩフォームにおいて提供することができる。ＧＵＩフォーム２３９の最下部には、開発者が（ａ）ワークフローをチェックできる「ワークフローをチェックする」、（ｂ）ワークフローの編集をキャンセルできる「キャンセル」、（ｃ）前のステップへ戻ることができる「戻る」、（ｄ）次のステップへ進むことができる「次へ」、および（ｅ）ワークフローの編集を終了できる「終了」の各ボタンが提供されている。

「条件付き分岐を追加する」２４９を選択することによって、追加の条件付き分岐を作成することができる。「条件付き分岐を追加する」２４９を選択すると、条件およびアクション２４７の新しいブロックが、既存の条件付き分岐の後に挿入される。条件およびアクションのブロック内の各コンポーネントのタイプは、ドロップダウンメニューを使用して選択することができる。たとえば条件およびアクション２４７のブロックの左側では、ドロップダウンメニューから「条件を設定する」および「アクション」が選択されている。条件およびアクション２４７のブロックの右側では、条件「金額が１０００ドル以下の場合」がドロップダウンメニューから選択されており、条件「金額が１０００ドルを上回る場合」も同様に選択されている。

開発ステージ２００においてサポートされる別の行為は、ワークフローをドキュメントライブラリに関連付けることである。図４Ｃは、ワークフローをドキュメントライブラリに関連付けるための典型的なＧＵＩフォーム２５１を示している。ＧＵＩフォーム２５１は、「ワークフローの定義」、「名前とステータスのメニュー」、および「開始条件」という３つのセクションを含んでおり、そのタイトルは、ワークフローをドキュメントライブラリに関連付けることに関わる３つの行為を反映している。「ワークフローの定義」のセクションは、ワークフローの開発者にワークフローテンプレートのリストを提示する。「ドキュメントの承認」、「ドキュメントの検討」、「ドキュメントの回覧」、「マネージャによる承認」、「チームによる検討」、「個人的なドキュメントの検討」、および「リソースの調達」という典型的なワークフローライブラリ関連付けテンプレートが表示されている。ワークフローの開発者は、ワークフローライブラリ関連付けテンプレートのリストから１つのワークフローライブラリ関連付けテンプレートを選択することができる。あるいはリストが適切なテンプレートを含んでいない場合、ワークフローの開発者は「ワークフローを作成・・・」を選択することができ、これによってワークフローの開発者は、新しいワークフローライブラリ関連付けテンプレートを作成することができる。「名前とステータスのメニュー」のセクションによって、ワークフローの開発者は、ワークフローとライブラリの関連付け用に一意の名前を作成することができる。その名前は通常、以前に選択されたワークフローライブラリ関連付けテンプレートに基づく。「名前とステータスのメニュー」のセクションはまた、ラジオボタンを含み、これによって開発者は、ドキュメントライブラリに関連付けられているワークフロー用のメニューアイテムをステータスメニューに追加することができる。「開始条件」のセクションによって、開発者は、新たに作成されたワークフローとライブラリの関連付け用に１つまたは複数の開始条件を選択することができる。考えられる開始条件は、「このワークフローをアイテムまたはフォルダから手動で開始できるようにする」、「新しいアイテムまたはフォルダが作成されたときに、このワークフローを自動的に開始する」、および「アイテムまたはフォルダが変更されたときは、常にこのワークフローを自動的に開始する」である。

本明細書に記載されている本発明の典型的な実施形態では、開発ステージ２００においてワークフローが作成された後、そのワークフローをカスタマイズすることができる。ワークフローをカスタマイズするためのＧＵＩフォーム２５３の一例が、図４Ｄに示されている。図示されたカスタマイズされているＧＵＩフォーム２５３は、図４Ｄの左側にステップのシーケンスとして示されている４つの質問、すなわち（１）承認用に回送しますか、あるいはフィードバックを集約しますか、（２）ワークフローに参加するのは誰ですか、（３）ワークフローをどのように進めますか、（４）ワークフローをどのように終了しますか、をワークフローの開発者に提示している。これらの「質問」の１つを選択すると、関連するパネルが図４ＤのＧＵＩフォームの右側に現れる。図４Ｄに示されている例では、ワークフローの開発者は、第１のステップ「承認用に回送しますか、あるいはフィードバックを集約しますか」を選択している。このステップは、「ドキュメントを回送して、承認を求める」および「ドキュメントを回送して、フィードバックとコメントを求める」という２つの選択肢を有するパネルを開き、そのそれぞれは２つの下位選択肢を有する。選択肢「ドキュメントを回送して、承認を求める」の下位選択肢は、「再提出を認める」および「編集を制限する」である。「編集を制限する」は、変更を禁止する「変更禁止（読み取り専用）」という名のコントロールチェックボックスを有する。選択肢「ドキュメントを回送して、フィードバックとコメントを求める」の下位選択肢は、「参加者ごとにこのドキュメントの新しいコピーを作成する」および「参加者が互いのコピーを見られるようにする」である。

図４Ｄに示されている例では、ワークフローの開発者は「ドキュメントを回送して、承認を求める」を選択している。ワークフローの開発者はまた、修正したドキュメントの再提出を参加者に認めること（再提出を認める）、および元のドキュメントの編集を制限すること（編集を制限する）を選択している。

図３で前述したように、開発ステージの後、ワークフローはパッケージングステージ２０４においてパッケージされる。典型的なパッケージングステージのステップが、図５Ａに示されている。パッケージングステージ２０４のステップは、ワークフローの開発者またはワークフローの所有者によって実行することができるが、説明を簡単にするために、以降の考察では、このステップはワークフローの所有者によって実行されるものと仮定する。ワークフローの所有者は、はじめに２７０において、ワークフローのコンポーネントを識別することによって、パッケージを定義する。

図５Ｂは、典型的なワークフローパッケージ３２０のトップレベルのコンポーネントのブロック図である。示されている典型的なワークフローパッケージ３２０は、製造チームによる検討３２４、マーケティンググループによる検討３２８、および法務グループによる検討３３２という３つのトップレベルのコンポーネントを含んでおり、ワークフローパッケージは、これと同じ指定か異なる指定かを問わず、より多くのトップレベルのコンポーネントまたはより少ないトップレベルのコンポーネントを含むことができるものと理解されたい。典型的なトップレベルのコンポーネントのそれぞれは、ワークフローの参加者のさまざまなグループに関連付けられている。たとえばマーケティンググループによる検討のコンポーネントは、ワークフローが経過を追跡しているプロジェクトに関与しているマーケティンググループの参加者に関連付けられている。トップレベルのコンポーネントのそれぞれは、役割、タスク、およびマイルストーンのリストを含むものとして示されているが、これらのリストの数および内容は代表的なものであり、限定と解釈すべきではないことを理解されたい。すなわちトップレベルのコンポーネントは、より多くのリストまたはより少ないリストを含むことができ、リストは、役割、タスク、およびマイルストーンとすることもできるし、あるいはそれ以外のものとすることもできる。

図５Ａに戻ると、２７０においてパッケージを定義した後、ワークフローの所有者は、２７２でワークフロースケジュールをパッケージに挿入する。次いで２７４では、ワークフローの所有者は、ワークフローに含まれることになるタスクのタイプをパッケージに挿入する。その後２７６において、ワークフローの所有者は、参加者がワークフローと対話する上で必要となるフォームをパッケージに挿入する。次いで２７８において、ワークフローの所有者は、ワークフローが操作する必要のあるリソースをパッケージに挿入する。そして２８０において、ワークフローの所有者は、ワークフローに関するメタデータをパッケージのマニフェストに追加する。パッケージのマニフェストとは、パッケージのコンテンツに関する詳細な説明である。パッケージのマニフェストは、パッケージ内の名前、バージョン、タイプ、およびリソース、ならびに他のパッケージとの依存関係について記述するメタデータを含む。マニフェストによって、パッケージは自己記述的になり、容易に展開することができる。最後に２８２において、ワークフローの所有者はパッケージを利用可能にする。図５Ａに示されているステップ、特に挿入ステップは、図５Ａにおいて前述したシーケンス以外のさまざまなシーケンスで達成できることは明らかである。本発明の一実施形態では、パッケージは、１つまたは複数のＭｉｃｒｏｓｏｆｔ（登録商標） ．ＮＥＴ（商標）アセンブリとすることができる。Ｍｉｃｒｏｓｏｆｔ（登録商標） ．ＮＥＴ（商標）アセンブリは、安全な方法で共有できるコードライブラリである。

ワークフローは、パッケージされた後、インストールステージ２０８（図３）に入る。図６は、ワークフローパッケージをどのようにしてインストールできるかを示す典型的な流れ図である。３５０において、ワークフローの所有者は、ワークフローパッケージをグローバルアセンブリキュッシュ（ＧＡＣ）のバイナリコードフォルダに配置する。たとえばパッケージを「ＧＡＣ／バイナリフォルダ」内に配置することができ、ワークフローパッケージを機能リストに追加することができる。次いで３５４では、ワークフローの所有者は、ＳｈａｒｅＰｏｉｎｔなどの適切なプログラムを介してワークフローを利用可能にする。図６に示されている例では、ワークフローは「製品の検討」と名付けられている。

ワークフローは、インストールされた後、展開ステージ２１２（図３）に入る。図７Ａは、展開ステージ２１２内で発生する行為を示す典型的な流れ図である。ブロック４００において、所有者は、インストールされた複数のワークフローフォームから１つの適切なワークフローフォームを選択する。１つの適切なワークフローフォームは、スケジュールと、ワークフローによって管理されているプロジェクトの１つの側面に関与するタスクの経過を追跡するのに必要なコンポーネントのすべてまたは大半とを含む。ブロック４０４では、この適切なワークフローテンプレートを使用して、このワークフローによって管理されるプロジェクト専用のワークフローを作成する。たとえば「製品の検討」という名のワークフローをテンプレートとして使用して、「ビデオ編集製品の検討」という名の新しいワークフローを定義することができる。図７Ｂは、このようなワークフローを作成するのに適した典型的なＧＵＩフォーム４１０を示している。この典型的なＧＵＩフォーム４１０は、「ワークフローの定義」、「名前とステータスのメニュー」、および「開始条件」という３つのセクションを含む。「ワークフローの定義」のセクションによって、所有者は、インストールされた複数のワークフローから１つのワークフローの定義、すなわちそこから１つのワークフローの定義を借用できる既存のワークフローを選択することができる。その既存のワークフローは、テンプレートとして使用される。たとえば図７Ｂでは、所有者は、「回送して承認を求める」または「ドキュメントの回覧」のワークフローテンプレートを選択することができる。上記の２つのワークフローテンプレートの１つを選択することによって、所有者は、ワークフローを、「ビデオ編集プロジェクト」などのプロジェクトに関連付けられたドキュメントを含むドキュメントライブラリに関連付ける。これで、このワークフローは、そのプロジェクトのドキュメントライブラリ内の全ドキュメントの経過を追跡できるようになった。「名前とステータスのメニュー」のセクションでは、所有者は、そのワークフロー用の一意の名前を入力し、この名前は、ドキュメントライブラリ内のリストアイテムおよびフォルダ上に表示されることになる。またラジオボタンもあり、これによってユーザは、このワークフロー用のメニューアイテムをステータスメニューに追加することができる。「開始条件」のセクションでは、所有者は、必要なワークフローのパラメータ値がすべて設定された場合にワークフローを開始させる条件を設定する。「このワークフローをアイテムまたはフォルダから手動で開始できるようにする」、「新しいアイテムまたはフォルダが作成されたときに、このワークフローを自動的に開始する」、および「アイテムまたはフォルダが変更されたときは、常にこのワークフローを自動的に開始する」という開始条件から、少なくとも１つの、また場合によっては複数の条件を選択することができる。図７Ａのブロック４０８は、展開ステージ２１２の最終ステップを示しており、ここでは、参加者はワークフローに、この例では「ビデオ編集製品の検討」のワークフローに関連付けられる。

ドキュメントライブラリは、複数のプロジェクトに関与することができ、したがって複数のワークフローに関連付けることができる。図７Ｃは、ドキュメントライブラリに関連付けられたワークフローを追加または削除するための典型的なＧＵＩフォーム４１２である。また図７Ｃに示されている典型的なＧＵＩフォームによって、ワークフローの設定を表示し、ワークフローの実行順序を変更することもできる。より具体的には、図７ＣのＧＵＩフォーム４１２は、１つのドキュメントライブラリに関連付けられたワークフローの数を表示し、他のＧＵＩフォームを選択するための制御を提供して、ワークフローをドキュメントライブラリに関連付け、ドキュメントライブラリから１つまたは複数のワークフローの関連付けを解除し、関連付けられたワークフローの実行順序を変更する。

図７Ｄは、ワークフロー内のタスクを設定するための典型的なＧＵＩフォーム４１４である。このＧＵＩフォームは、ワークフロー内のすべてのタスク、ワークフロー内のログオンしているユーザに割り当てられたタスク、ワークフロー内のその日が締め切りであるタスク、ワークフロー内のアクティブタスク(active task)、およびワークフロー内の割り当て先別のタスク、というワークフロー内のタスクに関する５つのビュー４１６を提供する。ビューペイン４１８では、選択されたビュー４１６に基づいて、各タスクのタイトル、割り当てられた参加者、ステータス、優先度、締め切り、および進捗率が提示される。お気に入りのリンクの一覧にワークフローを追加し、参加者がワークフロー内で何かを行わなければならない場合にアラートを提示し、ワークフローの情報をスプレッドシートにエクスポートし、ワークフロー上のレポートの設定および配列を変更するために、制御４２０が提供される。

図７Ｅは、ドキュメントライブラリに関連付けられたワークフローのパラメータ値を変更するための典型的なＧＵＩフォーム４２２である。ＧＵＩフォーム４２２は、「参加者と回送順序」、「締め切り」、「通知オプション」、および「承認条件」という４つのセクションに分割されている。「参加者と回送順序」のセクションでは、参加者をアドレス帳から選択し、参加者のリストへ追加して、ワークフローに関連付けられたドキュメントライブラリへ関連付けることができる。ドキュメントライブラリをすべての参加者へ同時に回送するか、またはドキュメントライブラリを各参加者へリストに記載されている順に回送するかを選択することができる。「締め切り」のセクションでは、承認を完了しなければならない日時を入力することができる。「通知オプション」のセクションでは、タスクが参加者に割り当てられたときに各参加者にその旨を通知するよう選択することができ、またワークフローが完了したときにワークフローの所有者にその旨を通知するよう選択することもできる。「承認条件」のセクションでは、「すべての参加者がドキュメントを承認した場合」、「１人の参加者がドキュメントを承認した場合」、「過半数の参加者がドキュメントを承認した場合」、および「締め切りを過ぎた場合」、という承認を表す条件から１つまたは複数を選択することができる。

ワークフローは、展開された後、有効化ステージ２１６（図３）に入る。図８は、有効化ステージ２１６内で発生する行為を示す典型的な流れ図である。ブロック５００において、所有者は、どのワークフロー対応型ツールが参加者によって使用されるかを識別する。参加者によって使用されるワークフロー対応型ツールは、ワークフローに直接アクセスするために挿入されたメニューアイテムや他の制御を有することができる。ブロック５０４では、所有者は、それぞれのワークフロー対応型ツール内のワークフロー選択制御をオンにする。たとえば所有者は、それぞれのワークフロー対応型ツール内の「ビデオ編集ツール製品の検討」のワークフロー選択機能をオンにする。

ワークフローは、有効化された後、関連付けステージ２２０（図３）に入る。関連付けステージ２２０において発生する関連付けの行為は、ワークフローをコンテンツタイプまたはリストに関連付けることである。関連付けられたワークフローとは、ドキュメントライブラリまたはリストをそのドキュメントライブラリまたはリストのユーザにとって利用可能にするために、そのドキュメントライブラリまたはリストに関連付けられているワークフローである。

コンテンツタイプとは、他のコンテンツタイプまたはリスト（ドキュメントライブラリは一種のリストである）に適用できる設定の集合である。たとえば仕様向けのコンテンツタイプは、仕様の作成者、仕様の実装者、および仕様ドキュメントの仕様エリアを入力するためのドキュメントライブラリリスト上のメタデータの列を定義する場合がある。仕様のコンテンツタイプは、このコンテンツタイプの新しいドキュメントを作成する際に使用するデフォルトのドキュメントテンプレートを含む場合がある。仕様のコンテンツタイプがドキュメントライブラリに追加されると、その設定がドキュメントライブラリにコピーされ、ドキュメントライブラリのユーザは、そのコンテンツタイプのアイテムまたはドキュメントをドキュメントライブラリに保存することができる。複数のコンテンツタイプを同一のリストまたはドキュメントライブラリに追加できること、およびコンテンツタイプは他のコンテンツタイプにも追加できることに留意されたい。ワークフローの関連付けは、コンテンツタイプに追加できる設定の一種である。たとえば仕様の承認のワークフローの関連付けを仕様のコンテンツタイプに追加すると、そのワークフローの関連付けは、その仕様のコンテンツタイプの追加先のリストにコピーされる。その後、仕様のコンテンツタイプ上のワークフローの関連付けに変更を加えた場合、その変更は、そのコンテンツタイプから受け継ぐドキュメントライブラリに押し下げることができ、これによってサイトの管理者は、１つの場所でワークフローの設定を行い、その設定を他の複数の場所に広めることができる。

図９Ａは、ワークフローをどのようにしてコンテンツタイプに関連付けるかを示す典型的な流れ図である。このような関連付けの利点は、コンテンツタイプまたはコンテンツタイプの特徴に基づくことができるタスクが存在できることである。はじめに５２０において、コンテンツタイプを選択する。次いで５２４において、コンテンツタイプをワークフローに関連付ける。この時点で関連付けは行われたが、この関連付けの中にはドキュメントが全くないため、あまり有用ではない。この関連付けにドキュメントを追加する準備として、５２８においてドキュメントライブラリを作成する。次いで５３２において、コンテンツタイプをドキュメントライブラリに追加する。ブロック５３６では、適切なコンテンツタイプのドキュメントのリストなどのアイテムが利用可能な場合、そのアイテムをドキュメントライブラリに追加することができる。ブロック５３６で利用可能な別のオプションは、適切なコンテンツタイプのリストを作成し、そのリストに適切なコンテンツタイプのドキュメントを追加し、そのリストをドキュメントライブラリに追加することである。ブロック５３６における第３のオプションは、適切なコンテンツタイプの空のリストをドキュメントライブラリに追加し、そのリストに適切なコンテンツタイプのドキュメントを追加することである。最後に５４０において、アイテムまたはドキュメント上でワークフローを開始する。

図９Ｂは、異質なドキュメントライブラリ、すなわち複数のコンテンツタイプを認めるドキュメントライブラリにワークフローをどのようにして関連付けるかを示す典型的な流れ図である。このような関連付けの利点は、コンテンツタイプに帰属しない共通の特徴に基づくタスクが存在できることである。はじめに５４４において、ドキュメントライブラリを選択する。次いで５４８において、ドキュメントライブラリ全体またはライブラリ内の１つまたは複数のリストにワークフローを関連付ける。図９Ａのブロック５３６において利用可能な３つのオプションは、図９Ｂのブロック５５２においても利用可能である。最後にブロック５４０と同様、ブロック５５６に示されているように、アイテムまたはドキュメント上でワークフローを開始する。

ワークフローの関連付けは、ワークフローの関連付けフォームという特定の種類のＧＵＩフォームを使用することによって達成することもできる。このようなフォームを使用して、リストまたはプロファイルマネージャからワークフローのパラメータおよび制約を収集する。ワークフローの関連付けフォームは、サーバ上にインストールされてサイトまたはサイトの集合上で有効にされるワークフローパッケージ内で定義される。

ワークフローは、関連付けられた後、インスタンス化ステージ２２４（図３）に入り、ここではワークフローは、そのワークフローが経過を追跡するプロジェクトの特定の要件にさらに適合される。ワークフローは、そのワークフローによって経過を追跡されるプロジェクトに適合された後、ワークフローの参加者にとって利用可能にされる。図１０Ａは、「ビデオ編集ツールのプロジェクト」という名の典型的なプロジェクト用のインスタンス化ステージ２２４内で発生する行為を示す典型的な流れ図である。ブロック６００において、ワークフローテンプレート内の一般的なパラメータに、「ビデオ編集ツールのプロジェクト」に特有の値を割り当てる。ブロック６０４では、「ビデオ編集ツールのプロジェクト」に特有のカスタムパラメータと、そのカスタムパラメータ用のデフォルト値をワークフローに追加する。ブロック６０８では、「ビデオ編集ツールのプロジェクト」用のワークフローを開始する、すなわち起動する。起動は明示的に行うことができる。たとえば、参加者はドキュメントを提出して承認を求めることができ、これによって、そのドキュメントを承認するためのワークフローを明示的に起動することができる。起動は自動的に行うこともできる。たとえば経費報告用に必要なドキュメントが、その経費報告に関連付けられたドキュメントライブラリに追加されると、その経費報告ドキュメントを承認するためのワークフローを自動的に起動することができる。両方の例では、必要とされるタイプのワークフロースケジュールをインスタンス化するようワークフローエンジンに指示する特別なイベントハンドラを呼び出すイベントが、ＷＳＳサブシステム内で作成される。ワークフローの作成をトリガする所有者または参加者は、スケジュール内に記載された変数になる特定のパラメータを入力するよう促される。所有者または参加者を促すために使用されるフォームの作成は、展開の時点でワークフローの定義から利用可能にされたメタデータに基づく。

ワークフローを開始すると、そのワークフローに関連付けられているスケジュールが起動し、ワークフローエンジン１７０（図２）内で実行される。ここまでもある程度は説明したが、スケジュールがワークフローエンジン内で実行されると、参加者に割り当てられたそのスケジュール内のタスクによって、ワークフロー命令１６６がＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８に送信される。ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ１５８は、そのようなワークフロー命令１６６をメッセージへと変換し、そのメッセージはアプリケーション１５６に送信される。アプリケーション１５６は、そうしたメッセージを受信すると、タスクに関する情報をＧＵＩフォーム内に提示する。たとえば図１０Ｂに示されている典型的なＧＵＩフォーム６１４は、締め切りを過ぎたワークフロータスクに関する情報のビューを提供する。図１０Ｂに示されている典型的なＧＵＩフォーム６１６は、ワークフロー内の全タスクに関する情報の総括を含む。この総括は、アクティブタスクの総数、締め切りを過ぎたタスクの総数、およびタスクが締め切りを過ぎた平均日数を含む。各参加者に割り当てられたタスクに関する情報の列が提供される。列内の一番上の項目は、参加者の名前、締め切りを過ぎた平均日数、およびタスクの進捗率を示している。列内の残りの各項目は、割り当てられた各タスクが締め切りを過ぎた日数、タスクの進捗率、タスクの名前、およびタスクの締め切りを示している。

図１０Ｃは、ワークフローの所有者が、ワークフロー内の複数の週にわたるアクティブ案件すなわちタスクの総括を表示するために呼び出すことができる典型的なＧＵＩフォーム６１８である。この典型的なＧＵＩフォームは、ワークフロー内のすべてのアクティブタスクの総括６２０を示しており、これは、アクティブタスクの総数、１週間あたりのアクティブタスクの平均数、１人あたりのアクティブタスクの平均数、および１人あたりのアクティブタスクの最大数を含む。図１０Ｃに示されている典型的なＧＵＩフォーム６１８はまた、報告対象期間内の各週ごとの情報の行を提供する。各行の最初の項目は、対象期間内の１週間の開始日と、その週内のアクティブタスクの平均数を示している。行内の残りの各項目は、参加者の名前、その参加者に割り当てられているアクティブタスクの数、その参加者が責任を負う第１締め切りおよび最終締め切り、ならびにタスクの進捗率を示している。

ワークフローの所有者は、図１０Ｄに示されている典型的なＧＵＩフォーム６２２を使用して、ワークフローに関するさまざまなレポートを作成することができる。図１０Ｄに示されている典型的なＧＵＩフォーム６２２は、「仕様の検討に関するレポート」および「経費の承認に関するレポート」という２種類のレポートを提供している。仕様の検討に関するレポートは、「締め切りを過ぎたタスクを担当者別に表示」、「優先度の高いアクティブタスクを担当者別に表示」、「アクティブタスクを担当者別に表示」、「アクティブタスクをアイテム別に表示」、「締め切りを過ぎたワークフローを締め切り別に表示」、「締め切りを過ぎたワークフローを作成者別に表示」、および「完了ワークフローを作成者別に表示」を含む。経費の承認に関するレポートは、「締め切りを過ぎたタスクを担当者別に表示」、「優先度の高いアクティブタスクを担当者別に表示」、「アクティブタスクを担当者別に表示」、「アクティブタスクをアイテム別に表示」、「締め切りを過ぎたワークフローを締め切り別に表示」、「締め切りを過ぎたワークフローを作成者別に表示」、「締め切りを過ぎたワークフローを経費金額別に表示」、「完了ワークフローを作成者別に表示」、および「完了ワークフローを経費金額別に表示」を含む。

図３に示されている典型的なワークフローのライフサイクルでは、最後のステージは終了ステージ２２８である。図１１Ａは、ワークフローをどのようにして終了できるかを示す典型的な流れ図である。ワークフロー内のタスクが完了した場合と、定期的な時間間隔を置いて、ワークフローが完了しているかどうかを７００でチェックする。ワークフローが完了している場合、そのワークフロー状況は、７０８においてＳｈａｒｅＰｏｉｎｔから削除される。ワークフローは完了していないが、７０４において、そのワークフローに関連付けられているドキュメントまたはリストが削除されている場合、そのワークフローは、７０８においてＳｈａｒｅＰｏｉｎｔから削除される。ドキュメントまたはリストが削除されていない場合、プロセスはワークフロー完了テスト７００へ戻る。

ワークフローが削除されたかどうかにかかわらず、７１２においてＳｈａｒｅＰｏｉｎｔは、ユーザによって設定可能な日数、たとえば９０日間待機し、これによってワークフローの所有者は、ワークフローを削除するか、または再開することができる。９０日たってもワークフローが再開されない場合、そのワークフロータスクは、７１６においてＳｈａｒｅＰｏｉｎｔから削除され、もはや経過は追跡されない。図１１Ｂは、ワークフローの終了を可能にする典型的なＧＵＩフォームである。このＧＵＩフォームは、ワークフローのタイトルと、そのワークフローのインスタンスの数を表示する。所有者は、ワークフローの新しいインスタンスを作成できるようにすることを選択するか、ワークフローの実行中のインスタンスを削除せずに新しいワークフローインスタンスの作成を制限することを選択するか、またはワークフローの実行中のインスタンスをすべて削除することができる。ワークフロータスクリストは、自分にいくつのワークフローが関連付けられているかを把握する使用カウンタを有する。カウントがゼロではないワークフロータスクリストを削除しようとすると、そのワークフロータスクリストはまだ使用中である旨の警告が出される。

本発明の実施形態は、特定のワークフロー用のリアルタイムのステータスや、ワークフローのセットに関する集約された情報など、ワークフローに関するステータス情報を提供することができる。たとえば本発明の一実施形態は、ワークフロー内のアイテムに対する承認コメントを集約したデータ、特定のアイテムを承認した承認者名を集約したデータ、その時点でアクティブであり使用中であるワークフローのセット、あるいはビジネスプロセスのさまざまな態様向けの指標を提供することができる。

本発明の現時点で好ましい実施形態について記載および説明したが、本発明の趣旨および範囲から逸脱することなくさまざまな変更を実施できることが理解できるであろう。たとえばＳｈａｒｅＰｏｉｎｔのコンテキスト内では、ワークフローは、限定はしないが標準的なＭｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋのメッセージフォームを含む多くの種類のフォームに関連付けることができ、あるいはそうした多くの種類のフォームと共に動作することができる。またＳｈａｒｅＰｏｉｎｔのコンテキスト内では、本発明の一実施形態は、カスタムフィールドおよび他の制御を含むカスタムユーザインターフェースと共に動作することができる。前述の本発明の実施形態は、ＳｈａｒｅＰｏｉｎｔのコンテキストにおいてウェブサイトの開発および保守に関連するビジネスプロセス用に使用されるが、本発明は、他のコンテキストにおける他のタイプのビジネスプロセスにも適用できることが理解できるであろう。この点から、本発明は、ＳｈａｒｅＰｏｉｎｔとの関連以外でも実施できることが理解できるはずである。したがって添付の特許請求の範囲の範囲内であれば、本明細書に具体的に記載した以外の方法でも本発明を実施できることを理解されたい。

典型的な直線的なタスク管理プロセスを示す流れ図である。 本発明の典型的な実施形態をサポートするＳｈａｒｅＰｏｉｎｔの主要なコンポーネントを示すブロック図である。 ワークフローライフサイクルにおけるステージを示す流れ図である。 典型的なワークフローの開発を示す流れ図である。 ワークフローを設計するための典型的なグラフィカルユーザインターフェースを示す図である。 ワークフローテンプレートをドキュメントライブラリに関連付けるための典型的なグラフィカルユーザインターフェースを示す図である。 ワークフローをカスタマイズするための典型的なグラフィカルユーザインターフェースを示す図である。 典型的なワークフローがどのようにしてパッケージされるかを示す流れ図である。 典型的なワークフローパッケージのトップレベルのコンポーネントを示すブロック図である。 典型的なワークフローパッケージがどのようにしてインストールされるかを示す流れ図である。 典型的なワークフローがどのようにして展開されるかを示す流れ図である。 新しいワークフローを作成し、そのワークフローをドキュメントライブラリに関連付けるための典型的なグラフィカルユーザインターフェースを示す図である。 ドキュメントライブラリに関連付けられたワークフローを表示して選択するための典型的なグラフィカルユーザインターフェースを示す図である。 ワークフロー内のタスクを設定するための典型的なグラフィカルユーザインターフェースを示す図である。 ワークフローに関連付けられたドキュメントライブラリのパラメータ値を設定するための典型的なグラフィカルユーザインターフェースを示す図である。 典型的なワークフローをどのようにして有効にするかを示す流れ図である。 典型的なワークフローをどのようにしてコンテンツタイプに関連付けるかを示す流れ図である。 典型的なワークフローをどのようにしてドキュメントリストまたはライブラリに関連付けるかを示す流れ図である。 典型的なワークフローがどのようにしてインスタンス化されるかを示す流れ図である。 ワークフロー内の締め切りを過ぎたタスクを表示する典型的なグラフィカルユーザインターフェースを示す図である。 ワークフロー内のアクティブ案件を表示する典型的なグラフィカルユーザインターフェースを示す図である。 ワークフロー用の複数のレポートへのアクセスを提供する典型的なグラフィカルユーザインターフェースを示す図である。 典型的なワークフローをどのようにして終了するかを示す流れ図である。 ワークフローの終了を可能にする典型的なグラフィカルユーザインターフェースを示す図である。

符号の説明

１５０ ワークフロー対応型アプリケーション
１５４ ワークフロー非対応型アプリケーション
１５６ アプリケーション
１５８ ＷＩＮＤＯＷＳ（登録商標）ＳＨＡＲＥＰＯＩＮＴ ＳＥＲＶＩＣＥＳ ＷＯＲＫＦＬＯＷ ＯＢＪＥＣＴ ＭＯＤＥＬ（ＷＳＳ ＷＯＲＫＦＬＯＷ ＯＭ）
１６２ ワークフロー状況情報
１６６ ワークフロー命令
１７０ ワークフローエンジン

Claims (20)

1. ビジネスプロセス全体を通じて作業がどのように流れるか（すなわちワークフロー）をサポートするためのソフトウェアプログラムを作成する方法であって、
   （ａ）ユーザの入力に応答して、ワークフローを定義し、以前に開発されたテンプレートを使用して前記ワークフローをサポートするためのフォームを設計することと、
   （ｂ）前記ワークフローをサーバ上にインストールすることと、
   （ｃ）参加者を前記ワークフローに関連付けることと、
   （ｄ）前記ワークフローを有効化することと、
   （ｅ）前記ワークフローをドキュメントライブラリに関連付けることと
   を含むことを特徴とする方法。
2. ワークフローを定義し、以前に開発されたテンプレートを使用して前記ワークフローをサポートするためのフォームを設計することは、前記ワークフローのスケジュールおよびメタデータをサポートするフォームを設計することを含むことを特徴とする請求項１に記載の方法。
3. ワークフローを定義し、以前に開発されたテンプレートを使用して前記ワークフローをサポートするためのフォームを設計することは、どのようにして前記ワークフローの経過を追跡するかを定義することを含むことを特徴とする請求項２に記載の方法。
4. ワークフローを定義し、以前に開発されたテンプレートを使用して前記ワークフローをサポートするためのフォームを設計することは、前記ワークフローをパッケージすることを含むことを特徴とする請求項１に記載の方法。
5. 前記ワークフローをパッケージすることは、
   （ａ）ワークフロースケジュールをパッケージに挿入することと、
   （ｂ）タスクのタイプを前記パッケージに挿入することと、
   （ｃ）フォームを前記パッケージに挿入することと、
   （ｄ）リソースを前記パッケージに挿入することと、
   （ｅ）メタデータを前記パッケージのマニフェストに追加することと
   を含むことを特徴とする請求項４に記載の方法。
6. ユーザの入力に応答して前記ワークフローを開始することも含むことを特徴とする請求項１に記載の方法。
7. 前記ワークフローを終了することを含むことを特徴とする請求項１に記載の方法。
8. 前記ワークフローをドキュメントライブラリに関連付けることは、ドキュメントライブラリを作成することと、コンテンツタイプを作成して、ワークフローを前記コンテンツタイプに関連付けることと、そのコンテンツタイプを前記リストまたはドキュメントライブラリに追加することと、前記適切なコンテンツタイプのドキュメントを前記リストまたはドキュメントライブラリに追加することとを含むことを特徴とする請求項１に記載の方法。
9. ワークフローを管理するための、コンピュータによって実施される方法であって、
   （ａ）ワークフローを開発することと、
   （ｂ）前記ワークフローをパッケージすることと、
   （ｃ）前記ワークフローをサーバ上にインストールすることと、
   （ｄ）前記ワークフローを展開することと、
   （ｅ）前記ワークフローを有効化することと、
   （ｆ）前記ワークフローをスケジュールに関連付けることと、
   （ｇ）前記ワークフローをインスタンス化することと、
   （ｈ）前記ワークフローを終了することと
   を含むことを特徴とする方法。
10. 前記ワークフローを開発することは、
    （ａ）ワークフローテンプレートを使用して、パラメータを含むワークフローフォームを設計することと、
    （ｂ）前記ワークフローフォームの前記パラメータに値を割り当てることと
    を含むことを特徴とする請求項９に記載のコンピュータによって実施される方法。
11. 前記ワークフローは、参加者によって実行される複数のタスクを含むことを特徴とする請求項９に記載のコンピュータによって実施される方法。
12. 前記ワークフローは構造を有し、前記構造は宣言型言語によって記述されることを特徴とする請求項９に記載のコンピュータによって実施される方法。
13. 前記ワークフローの構造は、他のワークフローを作成する際に使用するために記憶されることを特徴とする請求項１１に記載のコンピュータによって実施される方法。
14. ワークフローを管理するための、コンピュータによって実施される方法において、
    （ａ）フォームを作成するのに適したテンプレートを含む事前にプログラムされたコンポーネントからワークフローを作成することであって、前記テンプレートはパラメータを含むことと、
    （ｂ）前記ワークフローフォームの前記パラメータに値を割り当てることと、
    （ｃ）前記ワークフローフォームをサーバ上にインストールすることと、
    （ｄ）参加者を前記ワークフローに関連付けることと
    を含むことを特徴とする方法。
15. 参加者による使用のために前記ワークフローフォームを有効化することを含むことを特徴とする請求項１４に記載のコンピュータによって実施される方法。
16. 前記ワークフローフォームをドキュメントライブラリに関連付けることを含むことを特徴とする請求項１４に記載のコンピュータによって実施される方法。
17. 前記ワークフローは、前記参加者に関連付けられている複数のタスクを含むことを特徴とする請求項１４に記載のコンピュータによって実施される方法。
18. 前記ワークフローはスケジュールを含み、前記タスクは前記スケジュールに従って前記参加者に関連付けられることを特徴とする請求項１４に記載のコンピュータによって実施される方法。
19. 前記ワークフローは、前記タスクの達成状況のレポートを作成することを特徴とする請求項１８に記載のコンピュータによって実施される方法。
20. 前記ワークフローは構造を有し、前記構造は宣言型言語によって記述されることを特徴とする請求項１４に記載のコンピュータによって実施される方法。
    

Images