JP5154798B2 - 構造化ワークフローシステム及びコンピュータプログラム - Google Patents

Description

［関連出願の相互参照］
この出願は、２００３年５月７日出願の「コラボレーションプロセスエンジンでアドホック（ad hoc）ワークフローの構造化プロセスを含むエンドユーザ指向ワークフローアプローチ」とタイトルを付けられた同時継続出願中のＵＳ仮特許出願番号６０／４６９，０５１からの優先権を主張し、その出願は、ここにあらゆる目的のための参照により組み入れられる。

人間及び／又はコンピュータ・アプリケーションが、いっしょに作用して、共通の目標又は適合性のある目標を達成する時はいつでも、コラボレーション（collaboration）が生じる。過去２０年の間、組織と個人の多くは、分散したチームの電子的なコラボレーションを、高い生産性を成し遂げ、そして、その生産物の品質を改良する１つの方法とみなした。様々なコラボレーション技術は、電子通信、協調（coordination）、コンテンツ共有の領域において、ソリューション（solution）を提供するために持ち込まれた。しかし、電子的コラボレーションの保障を十分に実現する包括的なソリューションは、依然として見つかりにくいゴールである。

非同期コラボレーションをサポート（support）するソフトウェアシステムを開発する従来の試みは、ＣＳＣＷ（Computer Supported Cooperative Work（コンピュータサポートによる共同作業））における研究プロジェクトによってなされた。そのような研究の試みが、例えば、ロータスノーツのような、市場に進出する製品と言う結果となる一方で、これらの初期のグループウェア製品は、既存の電子メール及び図書管理ソリューションに対するわずかな改良しか提供できていない。１９９０年代後半においては、基本構想は、ウェブブラウザによって導入された非同期及び同期コラボレーション用初期ツールに表われ、そして、そのような経路により、それらのツールは、多くの人々の仕事のやり方に大きな衝撃を与えた。

今日、チーム・コラボレーションをサポートする技術とツールは、ソフトウェア産業における多くの製品領域に導入されている。グルーブ（groove）やネットミーティング（NetMeeting）のような、新しいウェブベースのグループウェアは、共同作業（joint activity）ツール（例えば、音楽通信、インスタントメッセージ、コンテンツ共有ツール等）を提供することによって基本的なウェブブラウザの能力を拡張している。従来のグループウェア・ベンダーは、電子プレゼンテーションや、電子会議などのより特別なコラボレーションアクティビティ（collaboration activity）をサポートするソフトウェア製品（例えば、ロータス・セームタイム（Lotus Sametime）やクイックプレース（QuickPlace））を提供する。スタンドアローン・ワークフローシステム（Standalone workflow system）、及び、ＥＡＩプラットフォーム（例えば、ビトリア（Vitria）、ＴＩＢＣＯ、ＢＥＡ）とＥＲＰシステム（例えば、ＳＡＰ）に組み込まれたワークフローエンジンは、所定のコラボレーションアクティビティの効率的な調整を既にサポートし、そして、反復的な及びアドホック（Ad hoc）／オプション（option）的なコラボレーションアクティビティの組合せをサポートするための柔軟なワークフローを紹介し始めている。企業規模のコンテンツ管理サーバ（例えば、ドキュメンタム（Documentum）、Vignette、OpenMarket、BroadVision、FileNET）のベンダーは、電子的コラボレーションのための基本的なツールを含む新製品を紹介している。最後に、コラボレーション設計用のコラボレーション領域特化型ツール、学習、及び、製品データ管理は、徐々に新しいユーザを獲得し、新市場に参加している。

コラボレーションのサポートを目標とする製品の展望と技術の数は、拡張されており、そして、コラボレーション技術は、改良されている。しかし、現状のコラボレーション・ツールの展望は***されており、ネットワーク・インフラは、画面やアプリケーション共有のための基本ツールのような、幾つかのコラボレーション・ツールを、現状のところ効果的にサポートすることが出来ない。コラボレーション・ツールの展望の***は、様々な理由により、これらの技術は、完璧なコラボレーション・ソリューションを単独で提供できていない。異なる技術と製品は、異なる機能とツールのサブセット（subset）を提供する。さらに、提供されるツールの大多数は、一般的な目的であるので、例えば情報収集（intelligence gathering）のために、アプリケーション特有のツールとインタフェースを発展させる必要がある。

現状の技術がサポートできる拡張性、ひいては、分散した電子的チームのサイズは、著しく変化する。特に、共同作業をサポートする多くのグループウェアツールは、小さなグループ（即ち、１０人以下の小さなチーム）用にのみ適切である。他方では、よく発展している技術、例えば、コンテンツやワークフロー管理用システムは、本質的なグループウェアツールを欠いている。

製品ワークフローシステム（production workflow system）が知られている。幾つかのワークフローシステムにおいては、ワークフローは、インスタンス（instance）の中に構造化されており、かつ、大きな構造化ワークフローシステムでは、数千のワークフローインスタンスが、日々処理されている。ワークフローは、構造化されない手法で実行も可能である。例えば、電子メール、チャット、電話などである。前者は、大きなグループを調整（coordination）するために優れ、後者は、無形式で、小さなグループのコラボレーションでうまく機能する。

構造化ワークフローは、追跡性（trackable）とテスト性があるという長所がある。アナリスト（analyst）が、プロセス（process）がどう進行されるかを後で決定することができ、他の実績データ（performance data）及び行われるべき作業を明確に示すデータを識別することができるということにおいて、構造化ワークフローは、追跡性がある。他方では、構造化されていないワークフローは、これらの利点を有さず、アナリストは、手動により電子メールやノート等をレビュー（review）することが必要であり、復旧可能な形式で保存されない無形式のインタラクション（interaction）と通信により情報を取得できない。

構造化ワークフローにおける設定変更可能なワークフローエンジンは、所定の方法でワークアイテム（work item）を実行し、スケジュール化する機構を提供する。エンドユーザは、彼らの判断力（discretion）を使用して、ワークアイテムプロセス、又は、所定プロセスからの逸脱（deviation）のために、自身の「ローカル（local）」プロセスと「ローカル（local）」ルール（rule）を定義する。設定変更可能なワークフローエンジンは、サーバにインストールされ、ワークフローとビジネスプロセスを体系化し、そこで、エンドユーザは、ルールを設定し、かつ、ローカル・ワークフロー構造の部分としてワークフローを定義することにより、新しいワークアイテムのためのプロセスステップを定義する。これらのルール及びワークフローを定義することによって、将来の新しいワークアイテムの更なるステップを処理することが自動化される。

ここに述べられた改良ワークフローエンジンと共に、あるプロセスのフェーズにおいて不完全なステップが識別され、さらに知的に処理される。管理者は、現状のフェーズから、次のフェーズへと移行するためにワークフローエンジンを導くとき、ワークフローエンジンは、管理者にワークアイテムをそのまま持ち越す（又はそれを自動的にする）ことを許すことで不完全アイテムを処理する。エンドユーザ・コンサルテーション（consultation）は、持ち越し決定の中に含まれる。持ち越されたワークアイテムは、並列アクティビティ（parallel activity）として次フェーズに加えられる。

ワークフローエンジンは、タスク間の制御フロー依存関係（control flow dependencies）を強制し、実行する処理を行う。このようにして、ワークフローエンジンは、全体的に構造化されていない作業から、部分的に又は完全に構造化された作業への円滑な移行を提供する。ワークフローエンジンが意味論的に相関性のあるワークアイテム／タスクに遭遇するとき、そのプロセスエンジンは、これらのワークアイテム／タスクは、同じプロセスインスタンスに属することを仮定する。

ここに開示される本発明の本質と利点の更なる理解は、本明細書の残る部分と添付図面の参照によって明確となるだろう。

構造化ワークフローシステムにおいて、プロジェクトは、プロセスの組で定義され、各プロセスは、複数のステップ、タスク、トリガ、及び／又は、アクション（ワークアイテム）を有する。ワークフローエンジンは、定義された方法で、そのワークアイテムを実行し、スケジュールする機構を提供する。

幾つかのグループウェアアプリケーションは、プロジェクト・タスクを定義することを可能とするが、ユーザに共同でタスク情報をただ保存しただけであり、タスク実行オーダー、又は、処理される他の制御フロー依存関係用を制御することを行わず、これらのタスクがタスク所有者に割当てられることを確認するだけである。例えば、多くのグループウェアアプリケーションは、「Ｙより大きい値であるＸの場合のみ、タスクＡの後にタスクＢを実行。他の全てのケースでは、タスクＡの後にすぐにタスクＣを実行」等のような、ワークフローを扱うことは出来なかった。

この必要性に対処するため、ワークフローエンジンは、タスク間の制御フロー依存関係を強制し、かつ、実行する処理を行い、このようにして、全体的に構造化されていないワークから、ほぼ構造化された、或いは、完全に構造化されたワークへの滑らかな移行を提供する。ワークフローエンジンが意味論的に相関のあるワークアイテム／タスクに遭遇するとき、プロセスエンジンは、これらのワークアイテム／タスクは、同じプロセスインスタンスに従属すると仮定する。明確に提示された制御フロー依存関係が無い場合、プロセスエンジンは、全ては、並列タスク（parallel task）を表すと仮定する。エンドユーザが、例えば、これらタスクの幾つか又は全ての注文を、定義するとき、プロセス定義の新ヴァージョンは、これらの制御フロー依存関係をはっきりと反映することによって生成される。

実生活シナリオでは、予期しないアクティビティ又は頻繁な実行注文変更に適用し、一方で、構造化ワークフローシステムの利益を除かない必要がある。エンドユーザは、これらの変更をうまくこなすことが要求される。しばしば、エンドユーザは、仲間とのさらなるコンサルティング、又は、幾つかの他のステップを実行することを行わずに、これらのワーク（アイテム）を実行することは出来ないということを実感する。ここに述べられるワークフローシステムは、これに適用し、なぜなら、エンドユーザは自らの判断力を使用し、自らの所有する「ローカル（local）」プロセス及びワークアイテムを処理するための「ローカル」ルールを定義し、又は、所与のプロセスを逸脱させるからである。

実装においては、設定変更可能なワークフローエンジンが提供される。その設定変更可能なワークフローエンジンは、サーバにインストールされて、ワークフロー及びビジネスプロセスを組織し、そこでは、エンドユーザは、ルールを設定し、かつ、ローカルワークフローアイテムの部分としてワークフローを定義することによって、新しいワークフローアイテムのための処理ステップを定義することが出来る。これらのルール及びワークフローを定義することによって、将来の新しいワークアイテムの更なる処理ステップは、自動化される。ローカルワークフロー構造のための入力は、様々にサポートされるワークリスト（worklist）サーバシステムから生じるワークアイテムである。プロセスを定義し、インスタンス化することに加えて、そのプロセスが実行中に、プロセス定義は、プロセス関係者によって修正可能である。プロセス修正の例は、アクティビティの挿入／修正／削除、プロセスステップ（process step）のバイパス化、及び、グローバルワークフロー（global workflow）において予期されない他の、又は、付加的なプロセス関係者のインタラクション（ルーティングを介して、等）を含む。

設定変更可能なワークフローシステム１００の一例は、図１に示される。そこに例示されるように、ユーザは、ワークフロークライアント１０４を介してワークフローサーバ１０２にインタラクト（interact）する。他の図に示されるように、多くの異なるワークフロークライアントが可能である。ワークフローサーバ１０２とのインタラクション（interaction）においては、ユーザはタスクを見ることができ、タスクの状態を変更等（未決から終了、削除、移動、廃止等）できる。タスク、状態情報、及び、ワークフロープロセスで必要なもしくは使用される他データは、ストレージ１０６に保存される。標準ワークフローは、ストレージ１０８に保存され、典型的に、管理システム１１０によって提供されるが、外部ワークフローシステム１２４によっても提供可能である。

これらのコンポネント（component）を使用して、ユーザは、構造化手法でタスクを実行することができ、ワークフローシステム１００によって進捗を追跡可能である。ユーザは、エンドユーザ特定フローを取り扱うために、ローカルワークフローを欲し又は必要とするとき、そのユーザは、ローカルワークフローを入力するためにワークフロークライアント１０４を使用する。ワークフローサーバ１０２（例えば、そこでプロセスエンジン１０３によって）は、ローカルワークアイテムを、他の影響を与えるユーザに広めるが、ワークフローは、ユーザ毎にワークフローサーバ１０２によってストレージ１２０に保存される。始めに、ユーザ用の幾つかの構造（structure）を提供するために、管理システム１１０によってストレージ１２２に保存されるテンプレートは、ワークフローサーバ１０２と連結しても良い。

ある実施例では、図１に示すストレージエリアは、はっきりと識別できないが、データベースや他のデータやファイルストレージのような、共通ストレージエリアの単なる異なる割当である。他の変形例や、組織もあり得る。例えば、ワークフローシステムは、ポータルサーバに統合されても良い。

図２は、別の可能性ある配置又はシステム一覧を図解する。ここで図解されるように、ユーザは、１つ以上のワークフロークライアント、例えば、ＵＳ特許−［ＵＳ特許出願−これに添えて同日付出願；代理人整理番号０１７９００−００３６１０ＵＳ］でより詳細に述べられる全体ワークリスト（「ＵＷＬ」）、そしてＵＷＬは、全ての目的のためにここに参照により組み込まれる。ワークフロークライアントは、ワークフローサーバのＪＡＶＡ（登録商標）ワークフローサービスＡＰＩレイヤとインタラクトし、そのＡＰＩレイヤは、次に、示されるようなワークフローオブジェクト、データ、及び、他の構造とインタラクトするコアレイヤ（core layer）とインタラクトする。

図３は、ポータルアプリケーションとしてサポートされるワークフローコンポネントを図解する。

エンドユーザがローカル状況に適応させるためにプロセス定義を修正する場合、ワークフローエンジンは、プロセス定義の新ヴァージョン作成用テンプレートジェネレータを含む。新テンプレートヴァージョン作成後、プロセスインスタンスのランタイム（run time）情報は、新しいプロセス定義に統合される。このようにして、プロセスインスタンスにおける次のアクティビティは、プロセス定義の新ヴァージョンに、すぐに従う。

多くのワークフローにおいては、プロセスは、フェーズに分けて体系化され、そこで、１つのフェーズにおける各ワークアイテムは、そのフェーズの最後及び次フェーズの開始前に完成することが期待される。幾つかの従来のワークフローシステムは、次フェーズは、現状フェーズでの全ワークアイテムを終了させた後に開始されるという要求を強制し、しかし一方で、他システムは、フェーズ変更を考慮にいれ、そこでは、現状フェーズの全作業中アイテム（open item）は、完成もしくは廃止としてマークされ、それから次に、次フェーズに移行する。両方のアプローチには制限がある。なぜなら、それらは、十分な柔軟性が無いか、潜在的に必要な追跡を喪失しているかのどちらかである。

アドホック・ワークフローエンジンは、ユーザが他のツールを使用してそのアドホックワークフローを作成するために、他のアプリケーションとの途切れのない統合を有する。アドホックワークフローは、委任、置換、段階的拡大、ステップ後のスケジューリング等、及び、並列化（parallelization）等のさらに複雑な操作、代替（alternative）の使用、条件付操作等、の単純なルールを含める。ユーザが、ローカル操作のために必要と考える非公式なワークフローを自由に作成する一方で、システム管理者は、そのユーザのワークフローをいくらか構造化するためのテンプレートを与える。従って、ユーザは、要求ステップの骨格的概略に基づいて、多数のテンプレートの中から選択することを選ぶ。ワークフローは、取るべきステップ、作成すべき通知、及び他のワークアイテムを含める。アドホックエンジンは、リソースの最も効果的な使用のためにＳＡＰ（登録商標）のＮｅｔＷｅａｖｅｒプラットフォーム上で実装されても良い。

ここで述べられた改良されたワークフローエンジンと共に、プロセスのあるフェーズでの不完全なステップは、識別され、より統合的に処理される。管理者が現状フェーズから次フェーズへ移行するようにワークフローエンジンを導くとき、そのワークフローエンジンは、管理者がワークアイテムを持ち越すことを管理者に許すことで（又はそれを自動で行うことで）不完全なアイテムを処理する。エンドユーザ・コンサルテーションは、その持ち越し決定の中に含まれる。その持ち越しされたワークアイテムは、並列アクティビティとして、次フェーズへ加えられる。

１つのワークフローエンジンは、ここで述べられたように、ＪＡＶＡ（登録商標）で開発され、ＳＡＰ（登録商標）のウェブアプリケーションサーバＷｅｂＡＳ６．２０及び６．３０で起動する。それは、ナレッジマネージメント・アプリケーション（ＫＭ）での図書管理及びユーザ管理エンジン（ＵＭＥ）でのユーザそれ自身の管理のための容易に設定変更可能な承認プロセスを含める。特定の実施においては、ワークフローエンジンは、ポータルにおける全体ワークリスト（ＵＷＬ：Universal Worklist）を可能にする。

本発明の実施形態は、アドホックプロセスを構造化手法で処理することができる。ユーザ間の各インタラクションは、それに関係する暗黙もしくは明快な形式がある。例えば、「こんにちわ」で始まる、及び、「さようなら」で終わる電話機での会話、電子メールは、定義された手順と形式を有するが、構造化されていない情報伝達である。

これらプロセスの多くをサポートする柔軟なエンジンは、ユーザに有益である。アドホックプロセス管理を成功させるために、従来のワークフローに関係する多くの原理は、強調されるべきではない。例えば、ワークフローは、従来的な管理者中心であるが、エンドユーザは、典型的にアドホックプロセスを実行する。このようにして、管理者は、プロセスを定義し、そして、エンドユーザは、柔軟性の無いワークフロープロセスに関与する。これは、ユーザインタラクションに関連する非常に変わり易いプロセスを扱うために効果的な手段ではない。

アドホックプロセス管理は、ユーザが、ワークフロープロセスを定義することを許可し、そこで、ユーザは、管理者と参加者両方になり、プロセスを開始し、プロセスを変更し、ステップを完成し、ユーザが開始し又は参加するプロセスの状態を監視する。ここで述べられるアドホックプロセス管理システムの実施例は、関与するアクションとステップに接続することが可能なサービスを提供する。従来の構造化された機構を補足することで、ユーザは、アドホック・サブプロセス、及び、プロセス内のアドホック・サブプロセスを加えることが出来る。

［構造化アプローチを使用したアドホックワークフロー及びコラボレーション］
ユーザであるディルク、クリスチャン、マシュー、シリル、そして、ティムは、白書（white paper）を書く責任のあるチームの全チーム員であるとする。従来においては、既存を修正するためのプロセス又は中央機構（central mechanism）が無いので、これは、たくさんの電子メール及びその電子メールを介した連続的なステータス管理を要求する。ここで述べられるようなシステムは、ユーザに調整ワーク（coordination work）に対する多くの異なるタスクを実行することを許し、そして、進行中ワークについて効果的に連絡することを許す。アドホックプロセス管理エンジンは、ここで述べられるように、ユーザに、ユーザが実行するワーク回りに、ユーザワークプロセスを体系化することを許す。

図４は、設定変更可能なワークフローの形態を図解する。図４Ａの例では、管理者的ユーザ「シリル」は、ワークフローを発生させ、特定の図書レビュー（review）プロセスのための標準ワークフローとしてそのワークフローを提供する。管理者としてのユーザ「シリル」は、そのプロセスを設定し、そこで、クリスチャンは、図書リストをレビューし、それから、ディルク、それからティム、それからマシューがレビューする。管理者として、シリルは、矢印３０２、３０４によって示される命令を変えることができる。図４Ｂに示されるように、シリルは、そのレビューをコラボレーションルーム３１０に割り当てる。コラボレーションルーム３１０は、体系的な構築概念（construct）であり、そこでは、タスクは１人に割り当てられず、そのコラボレーションルームに関係する１人以上によってなされる。図４Ｂに示されるように、幾人かのユーザは、そのルームの外側におり、そして、他のユーザは、そのルームの内側に居る。図４Ｃに図解されるように、エンドユーザ（「ディルク」又は他の認可されたユーザ）は、そのプロセスフローを、アドホックワークフローに変えることができ、そしてアドホックワークフローは、ユーザ開始（user-initiated）であるが、構造化ワークフローシステムによってまだ取り扱われる。

ここで述べられたようなワークフローエンジンは、エンドユーザが統合された手法でワークフローとグループウェアを操作できるように、ワークフローとグループウェア間のギャップに橋渡しをする。ナレッジマネージメント（「ＫＭ」）システムは、典型的に、しばしばこれらのタスクに割り当てられた個人によってとられる手動プロセスステップであるワークの数々を意味する。ワークフローアイテムは、しばしば、異なって取り扱われる。例えば、自動化プロセス、又は、識別された個人に割り当てられる個人のどちらかによる将来のワークの数々の定義、１人以上の組、又は、ランタイムのように割り当て後に決定された役割のように、異なって取り扱われる。ワークフローアイテムは、典型的に、制御フローに組み込まれる。

ワークアイテムは、（ナレッジマネージメントタスクに類似する）手動ステップ又はワークアイテムオーナがアプリケーション画面でデータを入れ、そして、アプリケーションボタンを押下するようになっているコンピュータ化されたステップを表す。ワークフロー・ワークアイテムは、ワークフローシステムによって１人又は組のユーザに割り当てられたワークの一部を表す。ワークアイテムは、明らかに（ワークフロー定義によって開始される）ワークフローインスタンスに属し、かつ、ワーク定義への参照を維持する。ワークアイテムは、しばしば、検索、フィルタリング、及び、転送、実行、再提出等のような手動操作が可能なＵＷＬのようなデバイスを介してエンドユーザにアクセス可能である。

ここで述べられる幾つかのワークフローエンジンにおいては、ＫＭタスク及びワークフロー・ワークアイテムは、ユーザの観点から統合される。図１に表されるモデルにおいて、ＫＭタスクは、ＫＭレポジトリー・フレームワーク（ＲＦ）に保存される一方で、ワークフローアイテム及びワークフローアクティビティは、直接的にデータベースに保存される。性能の理由のために、データベースは、ワークフローアイテムデータ用が好ましい。例えば、エンドユーザによってＵＷＬから発行された問合せは、高い性能要求に合わなければならず、その高いパフォーマンス要求は、ＲＦによって簡単に合うことはできない。他方、ストレージとしてＲＦを用いることで、添付サービス、申込サービス、ヴァージョン管理サービス、検索エンジン等のような多くのＫＭインフラサービスは容易に使用可能である。

ＫＭタスクとワークアイテムの中の一貫性を維持するために、相互に登録されたコールバック（callback）が使用される。ＫＭタスクがワークフローの外で開始されるときはいつでも、ワークアイテムは作成される。ＫＭタスクが、即座に開始されないワークフローの外で定義されるときはいつでも、ワークフローアイテムは作成されない。しかし、このタスクがワークフローテンプレートにおかれるとき、ワークフローアクティビティは、ＫＭタスクを参照して作成される。次に、そのワークフローエンジンが、まだＫＭタスクと関係しないワークアイテムの作成を要求するときはどんなときでも、ＫＭタスクは作成される。

ＫＭタスク及びワークフローデータの一貫性を維持し、かつ、ＲＦ提供アダプタを介してワークアイテムをあらわにすることで、検索エンジンのようなポータルツールは、プロセスデータ上のエンドユーザフレンドリな問合せのために使用される。通常は、プロセスデータは、従来的な検索エンジンの影響を受けない。

図５は、コラボレーションルームでタスクを作成するユーザインタフェースの修正ヴァージョンを図解する。ここで留意すべきは、「スマートコラボレーション」である。そのボタンを用いて、ユーザは、既に構造化プロセスに入れられたタスクを配列できる。図６は、そのようなタスクを配列するために使用可能なユーザインタフェースの一例である。「セーブ」ボタンをクリックするとすぐに、ワークフローテンプレートが作成される。入れられた全ＫＭタスクは、ワークフローアクティビティとして取り扱われる。「プロセス開始」を押すと、発生したワークフローテンプレートが開始され、ワークフローインスタンスが生成される。各ＫＭタスク用のワークフローインスタンスの実行中に、対応するワークアイテムが作成される。このように、ＫＭタスクとワークフローワークアイテムの統合が達成される。

図７は、アイテムの２つの新しいアイテムカテゴリーが、「チームタスク」：「私のプロセス」、「全プロセス」の下にリストアップされるユーザインタフェースを図解する。これらの２つのエンティティは、「スマートコラボレーション」ボタンをクリックすることで構成されたプロセスをリストアップする。後者は、全ルーム参加者に利用可能である。これは、実際には、ユーザが、急いでタスクを構造化することを許す。

［ワークのアドホックプロセスに関する変形］
伝統的ワークフローシステムは、開発プロセスに熟練したプロセス管理者によって定義されるプロセスを実行することを許す。典型的に、これらのプロセスは、全く、念入りで、最適化され、そして、とても効率が良い。それらの目的は、ビジネスポリシーを実行し、そして、プロセスの一貫性のある実行を強制することである。これらの生産ワークフロープロセスは、典型的に、それらが配置される前に、完全にテストされる。

エンドユーザは、典型的に、会社のエンドユーザ以外の全ユーザが従わなければならないプロセスを定義するためのいかなる意図をも有しない。エンドユーザは、エンドユーザが定義するプロセスをテストするとき、十分な時間（又は全く時間が無い）を注ぎ込むことはない。彼らが、彼らのプロセスと共に問題に直面した場合、彼らは、稼働中に、それらを即座に変化できることを欲する。彼らは、彼らのプロセスを他の者と共に共有することを欲し、個人的なプロセスにおいてワークフロー参加者として他の人々を招待することを欲する。

ワークアイテムがレガシーワークフローシステムに由来する場合、それらのシステムは、典型的にワークアイテムを実行する標準的な方法から派生するいかなるサポートも提供しない。しかしながら、多くのケースにおいてそのようなワークアイテムを受け取るエンドユーザは、そのワークアイテムを実行する方法はわからない。通常、それらのワークアイテムの実行は、彼らの判断である。彼らは、彼らがある要求を承認するかしないかの前に、仲間と共に検討することを欲し、彼らは、ワークアイテムによって表されるサブタスクのために、仲間から承認を最初に得ることを欲するか、又は、彼らは、入ってくるワークアイテムを処理するための彼ら自身のルールを設定することを欲する。要約すれば、エンドユーザは、類似の将来の状況を効率的に処理するために、所与のプロセス経路から派生、又は、そのシステムの「学習能力」の点に関してこれらの状況をサポートするツールから恩恵を得る。

ユニバーサルワークリスト（ＵＷＬ）は、エンドユーザにとって主要なエントリーポイント（entry point）としての役目をする。ＵＷＬから、エンドユーザは、彼らの個人的なプロセスを定義できる。代替的なエンドユーザ・エントリーポイントは、ＳＡＰのルームポータルサービスのようなポータルである。ユーザがルームの一員であるなら、彼らは、ルームユーザインタフェースからプロセスを定義できる。デフォルトとして、これらのプロセス定義は、このルームの中でのみ見ることができる。

ワークフローエンジンは、ワークフローテンプレートの作成、維持、及び、展開のためのＡＰＩを提供する。このＡＰＩは、様々なツールから呼び出される。例えば、アプリケーションは、最後にワークフローＡＰＩをコールするプロセスを定義することを許すウィザードを提供する。グラフィカル・エディターは、ワークフロー定義を、グラフィックに構成するために使用される。

ワークフローエンジンは、実行中のワークフローテンプレートの変更をサポートする。エンドユーザは、ステップを加え、ステップの順番を変更し、そして、ワークフロープロセスの中でステップを修正することが出来る。ワークフロー定義が変更される度に、ワークフロー定義の新ヴァージョンが作成される。対応するワークフローインスタンスの次のステップが、更新ワークフロープロセス定義に既に付着する。

手動でワークフローを実行することに加えて、ユーザは、ワークアイテムのプロセスを自動化するルールを設定する。これらのルールは、ワークアイテム属性（例えば、作成日、ワークアイテムタイプ、ワークアイテムの作成者等）、関係するビジネスオブジェクト及びその属性（例えば、図書、図書の長さ、買い注文、買い注文の量等）、及び、従属するワークフローインスタンスの前後関係のような様々なデータソースを参照する。

［廃止されたアクティビティ／ワークアイテムの取扱い］
簡単にするために、ユーザインタラクションは、フェーズにおいて体系化されるプロセスをサポートするように設計されている。新フェーズが作成され、既に記入されたフェーズが削除される。タスクが、フェーズに入る。タスクをフェーズに割り当てることによって、タスクが実行されるべき注文（order）が定義される。フェーズに割り当てられる１つ以上のタスクがある場合、このフェーズにおける全タスクは、ワークフローエンジンによって並列に実行される。通常は、プロセスは、階層的に体系化される。即ち、プロセスは、典型的にそれら自身が処理されるアクティビティからなる。その階層に厳格に従うことが要求される場合、フェーズは、その先のフェーズが完了する場合にのみ開始される。

各フェーズのために、フェーズが実行され、終了する状況の詳細特性が定義される。他の利点の中に、これは、プロセスにおける代替ブランチ、又は、プロセスの加速した実行を定義することを許す。そのようなブランチが役に立つ一方、フェーズにおいて全アイテムが完璧であり、又は、移動され、及び、アイテムをほっておくことを確実にすることは、フェーズ終了を遅らせることのトレードオフを要求する。

現状のフェーズが完成しないが、次フェーズのプロセスを開始することが安全（又は時間制約のため要求される）な状況がある。これらのケースでは、現状フェーズの顕著なアクティビティは、「廃止」に変更される。しばらくしてから、誰もこれらの廃止アクティビティを思い出すことは無い。これは、全体プロセスの成功に有害な影響を有する。なぜなら、期待された提出物が得られないからである。

ここで述べたワークフローシステム及びスマートコラボレーションを用いて、廃止アクティビティを処理する所与の方法、又は、ワークアイテムが提供される。これらの状態を自動的に「廃止」に変更する代わりに、これらのアクティビティは、次フェーズ又は他フェーズに移動される。次のプロセスフェーズを開始したいエンドユーザは、ユーザダイアログで、このアクティビティに生じるものを示す各廃止アクティビティを入力する。未解決アクティビティを「廃止」に設定することは、オプションの１つである。他のオプションは、それら（又はそれらのうち幾つか）を、プロセスの他のフェーズへ割り当てる。このケースでは、これらのアクティビティの位置は、ユーザによって定義される。

次の２つの図をここで説明する。図８Ａは、階層的なプロセスを説明し、そこでは、幾つかのアクティビティ（アクティビティ１．１とアクティビティ１．２．１）は、既に終了されたものである。フェーズ１の他の幾つかのアクティビティ（アクティビティ１．２．２とアクティビティ１．３）は、まだ保留である。プロセスオーナ（process owner）がフェーズ２のプロセスを開始することを決める場合、彼女は、保留アクティビティに何をなすべきかを決定しなければならない。これは図８Ｂで示される。プロセスオーナは、アクティビティ１．２．２を、フェーズ２に移行することを決定し、そして、そのために、アクティビティ１．２もフェーズ２に移行する。さらに、彼女は、アクティビティ１．３を廃棄に設定する決定を行う。

新規ワークフローシステムが、述べられた。ワークフローエンジンの中核は、状態エンジンとして実行され得る。メモリ在中のワークフロー実行のために、移行ステッププロセッサが提供される。ルールを評価するために、基本ルールエンジンが提供される。ワークアイテムは作成され、ワークリストマネージャによって管理される。全体組織に拡大し、そして、適切なコラボレーションを提供するコラボレーションソリューションの特定の実施例は、柔軟なビジネスプロセスと、調整が衝突する場合のソリューション、ポリシーベースのチーム調整、リソースのための業務ルール、役割、ユーザ、及び、前後関係管理、ポリシーベースのアクセス、認識のプロビジョニング（provisioning）及びカスタマイズの監視、チームワークのための決定サポート、コラボレーションオントロジー、動的なチーム、ワークプレイス、ポリシー、プロセス生成、コラボレーション製品のためのサプライチェーンマネージメント、接合アクティビティや大きなチームのための拡張可能なツール、コラボレーション技術統合用のミドルウェア、及び／又は、特定のアプリケーション領域におけるチームワークをサポートするために開発されるツール（例えば、情報集約、危機管理、製品データ管理）を含む。

本発明が特定の要素の組合せを用いて述べられる一方で、要素の他の組み合わせは、本発明開示範囲内であることが認識されるべきである。上述の記述は、説明されたが、限定するためのものではない。本発明の多くの変形は、開示内容をレビューする当業者にとって明確となる。本発明の範囲は、それ故、上述の記載を参照して決定されるべきでなく、全範囲又は均等な範囲にそって未決の請求項を参照して決定されるべきである。

本発明の実施例に基づく設定変更可能なワークフローシステムの例を説明する図である。 ワークフローシステムの別なあり得る構成又は図である。 ポータルアプリケーションとしてサポートされるワークフローコンポーネントを説明する図である。 図書レビュープロセス用の標準ワークフローを説明する図である。 ２人のユーザからなるコラボレーションルームへのタスク割り当てを示す図である。 エンドユーザによって修正されるプロセスを示す図である。 コラボレーションルームの中でタスクを作成するためのユーザインタフェースの修正版を説明する図である。 コラボレーションタスクを配列するために使用可能なユーザインタフェースの例を説明する図である。 エンドユーザが急いでタスクを構造化することを可能とするユーザインタフェースを説明する図である。 終了及び作業中ワークアイテムで階層的なプロセスを示す図である。 持ち越す項目でフェーズ変更となるワークアイテムの状態を説明する図である。

Claims (8)

1. プロセス用に作成されるワークアイテムを保存するストレージを備え、各ワークアイテムは、個人又は個人のグループであるアクターによって実行されるべきタスクを表すデータオブジェクトであり、前記ワークアイテムのうち少なくとも幾つかはワークアイテム間の制御フロー依存関係によって接続され、制御フロー依存関係が無いワークアイテムは並列に実行され、前記ストレージは、プロセス修正において入力されるワークアイテムであるローカルワークアイテムをさらに保存し、
   前記ワークアイテム及びローカルワークアイテムを処理するワークフローエンジンをさらに備え、
   前記プロセスのワークアイテムは複数フェーズに割り当てられ、
   現状フェーズが完了する前に現状フェーズを次フェーズへ変更する要求を受領したとき、前記現状フェーズにおける未完了ワークアイテムを、未完了ワークアイテム間の制御フロー依存関係を維持して、ユーザによって指定されたフェーズに移動する手段をさらに備える構造化ワークフローシステム。
2. 前記プロセスは人間により入力される請求項１に記載の構造化ワークフローシステム。
3. 前記アクターからの入力、及び、該アクターへの出力を処理する前記ワークフローエンジンと結合したポータルサーバをさらに備える請求項１に記載の構造化ワークフローシステム。
4. 前記アクターは、コラボレーションチームとして動作する複数のエンドユーザであり、少なくとも１つのワークアイテムは該コラボレーションチームのエンドユーザによってなされるべきワークを表す請求項１に記載の構造化ワークフローシステム。
5. 前記ストレージは、前記プロセス修正においてアクターにより生成されるプロセスをさらに保存する請求項１に記載の構造化ワークフローシステム。
6. ワークアイテムが複数フェーズに割り当てられたプロセスのワークフローを実行する部分として前記ワークアイテムを操作する構造化ワークフローシステムにおいて、前記ワークアイテムのうち少なくとも幾つかはワークアイテム間の制御フロー依存関係によって接続され、制御フロー依存関係が無いワークアイテムは並列に実行され、
   現状フェーズが完了する前に現状フェーズを次フェーズへ変更する要求を受領する入力手段と、
   前記現状フェーズを変更する要求に対して、現状フェーズにおける未完了ワークアイテムを、未完了ワークアイテム間の制御フロー依存関係を維持して、ユーザによって指定されたフェーズに移動する手段と、
   を備える構造化ワークフローシステム。
7. 前記プロセスは人間により入力される請求項６に記載の構造化ワークフローシステム。
8. ストレージからプロセスのワークフローを読み取る手段としてコンピュータを機能させ、前記ワークフローに含まれる複数のワークアイテムのうち少なくとも幾つかはワークアイテム間の制御フロー依存関係によって接続され、制御フロー依存関係が無いワークアイテムは並列に実行され、
   前記ワークフローを実行する手段、
   ユーザ定義のワークフローであるローカルワークフローによる修正に遭遇した場合、該ローカルワークフローによる修正を実行し、それから、前記ワークフローを再び実行する手段としてさらにコンピュータを機能させ、
   前記プロセスのワークアイテムは複数フェーズに割り当てられ、
   現状フェーズが完了する前に現状フェーズを次フェーズへ変更する要求を受領したとき、前記現状フェーズにおける未完了ワークアイテムを、未完了ワークアイテム間の制御フロー依存関係を維持して、ユーザによって指定されたフェーズに移動する手段としてさらにコンピュータを機能させるコンピュータプログラム。

Images