JPH07141421A - 汎用のプロセス作成ブロックを使用したコンピュータ利用のプロセス制御システム - Google Patents

Abstract

(57)【要約】 【目的】ポリシーの解釈及びアクションの変更を別個に
且つ容易に行い、他のコードに影響を与えることなく各
アクションに関連のコードを容易に修正する。 【構成】プロセスの各状態を表わすために原始的プロセ
ス作成ブロックが利用され、それをコンピュータ利用の
クラス・オブジェクトとして使ってそのオブジェクトか
らすべてのプロセス状態を抽出する。プロセス作成ブロ
ックは汎用のアクション・セットを有し、それによって
制御がプロセス状態間で移行可能にする。各状態に対す
る汎用の遷移は、プロセスにおける順方向（次の状態）
又は逆方向（前の状態）への作業項目の相対的流れを表
わし、、或は同じ状態内でのループ動作を表わす。シス
テム全体にわたって同じモデルを使って各状態を定義す
ることにより、改良された簡単なユーザ・インターフェ
ースが与えられる。更に、汎用のアクションは自動化さ
れたレポーティング機能及びプロセス特性マトリクスの
作成を容易にする。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、プロセス管理に関する
ものであり、特に、人間指向のプロセスをモデル化し、
管理するためのコンピュータ利用のシステム及び方法に
関するものである。

【０００２】

【従来の技術】プロセスを自動化するための現在の方法
の中には、或る種の作業項目が種々の状態及び所有者を
介して移行する時、それを追跡するものがある。通常、
定形的な状態自動化としてプロセスを表わすために、状
態遷移図（ＳＴＤ）が使用される。自動化されたアクシ
ョンは、１つの状態から他の状態に制御の流れをシフト
するプロセス制御システムに連結されたコンピュータ・
プログラムに組み込まれる。

【０００３】更に詳しくいえば、これら状態遷移図で
は、状態はノードによって表わされ、制御の流れ（例え
ば、遷移）は或るノードから他のノードに向けられた弧
形によって表わされる。各状態及び各遷移は名称をつけ
られ、如何なる状態も他のＳＴＤの合成であると考える
ことができる。この場合、親遷移図の状態からの及びそ
の状態への遷移は、子遷移図では端末遷移のように見え
る。その真の効果は、ＳＴＤが十分に表現に富んでいる
ということであり、如何なる複雑なプロセスもこのよう
な従来技術の方法によって表わすことができるというこ
とである。代表的なこのようなＳＴＤを図１２および図
１３で見ることができる。

【０００４】このようなシステムに関する１つの問題点
は、各状態に対して一貫性がないため、前述のように定
義されたプロセスは、記述し、学習し、自動化し、修正
し、測定し、比較することが更に困難であるということ
である。例えば、各遷移はそれぞれ異なって名称をつけ
られてユーザ・インターフェースを形成し、例えば、関
連のメニューは一貫性がなく、作るのが難しい。

【０００５】１つの代表的な従来のシステムは、ＵＥＳ
社のＫＩシェルである。このシステムでは、状態及び遷
移は、各遷移が別々にラベル付けされるという一般的な
方法のように与えられる。各状態は、フレーム、即ち、
その状態で生ずるコードの記述によって表わされる。種
々のアクションがフレームに挿入され、然る後、遷移に
付加可能である。フレームは、起こり得る各アクション
及び遷移がコード化され、その結果、各状態に対して多
くのポリシーを生じさせる。以下で更に明らかとなるよ
うな多くの欠点がこのような通常の方法と関連してい
る。例えば、この方法で生成されたメニューの内容は、
各遷移に与えられるカストマイズされたラベルに依存し
ており、それによって、そのプロセスにおける種々の状
態と関連したメニューが異なって見える。更に、このよ
うなシステムは、各メニューがそれ自身のカスタム遷移
をリストしなければならず、従って、各メニューは遷移
を異ならせ、作業項目の数及び名称を異ならせなければ
ならないので、自動化されたメニュー生成器を組みこむ
ことを困難または不可能にしている。一方、好ましいシ
ステムでは、メニューはプロセス状態に関係なく同じに
見える。

【０００６】ＫＩシェルは、状態を独特の形成ブロック
にしていない標準的状態遷移図と関連する問題を示して
いる。伝統的な状態遷移方法論は、それぞれが明瞭にラ
ベル付けされ且つ１フレームのコードを表わす状態と関
連した遷移に焦点を合わせている。そのようなシステム
では、コードは各状態を定義するように書かれなければ
ならず、アクションはその状態から選ばれなければなら
ず、そしてその書かれたコードはそのようなアクション
それぞれに対して何が生じたかを定義しなければならな
いのみならず、それら遷移を処理しなければならない。
プロセス・ポリシー（即ち、状態の変化が生ずるのを可
能にする条件）に関するコードと状態の変化を生じさせ
るコードとの混合に関連した大きな問題点は、それがポ
リシー・アクションと変化のアクションとを別々に理解
するのを困難にしているということである。更に、それ
は、プロセス又は状態変化のコードを、他のコードに影
響を与えることなく修正するのを困難にしている。更
に、他の遷移が同じポリシーを持つが異なった変化アク
ションを持つ場合、両方とも全体としては両方の遷移に
対して別個にコード化されねばならない。これらの真の
影響は、コードの可読性および再利用性が損なわれるこ
とである。

【０００７】更に望ましくないことは、従来のシステム
がそのシステムにおける各状態を定義する統一したモデ
ルを与えていないことによるものである。これらの中に
は、プロセスを効率的に記述し且つコンピュータ利用の
プロセス管理システムを使用することの難しさ、プロセ
ス測定およびデータ変換技法を更に使い易くし、プロセ
スとプロジェクトとの更に十分な一致を促進するテクノ
ロジを与え、そして、プロセスと関連の自動化されたツ
ールの作成を促進する能力を与えることに関する従来の
システムの欠陥がある。

【０００８】

【発明が解決しようとする課題】従って、本発明の目的
は、ポリシーを理解し、アクションを別個に変更し、且
つ、他のコードに影響を与えることなく関連のコードを
修正することが容易なコンピュータ利用のプロセス・モ
デル化のためのシステム及び方法を提供することにあ
る。

【０００９】本発明のもう１つの目的は、プロセスを記
述するそのようなコードの可読性及び再利用性を改良す
ることにある。

【００１０】本発明の更にもう１つの目的は、プロセス
を使い易く、学習し易く、記述し易くするコンピュータ
利用のプロセス管理システムを提供することにある。

【００１１】本発明の更にもう１つの目的は、複雑性が
変化する任意のプロセスをモデル化するための汎用のプ
ロセス・モデル化システム及び方法を提供することにあ
る。

【００１２】本発明の更にもう１つの目的は、データの
測定及び変換が容易になるプロセスのコンピュータ利用
のモデルを提供することにある。

【００１３】本発明の更にもう１つの目的は、プロセス
とプロジェクトの比較を容易に且つ効率的にするプロセ
ス管理のための汎用のシステム及び方法を提供すること
にある。

【００１４】本発明の更にもう１つの目的は、プロセス
を駆動し、そのプロセスからデータを収集し、ステータ
ス及びサマリー・レポートを作成し、プロセスの質及び
最適化を先行学習に従って改良する自動化したツールを
作るためにコンピュータ利用のプロセス・モデルで使用
するシステム及び方法の改良を促進することにある。

【００１５】

【課題を解決するための手段】プロセスの各状態を表わ
すために１つの原始的なプロセス作成ブロックが利用さ
れ、すべてのプロセス状態が取り出されるコンピュータ
利用のクラス・オブジェクトとして実施される。その作
成ブロックは、制御を１つの状態に転送し得る汎用のア
クション・セットを有する。各状態に対するそのような
汎用の遷移は、次の又は前の状態への、順方向又は逆方
向の作業項目の相対的な流れを記述するか、或は、同じ
状態内でのルーピングを記述する。そのシステムを通し
て一定のモデルでもって各状態を定義することにより同
じアクション・セットを所与の状態に入れたり、その状
態から出させたりすることによって、改良且つ簡略化さ
れたユーザ・インターフェイスが与えられる。更にその
汎用のアクションは、自動化されたレポート機能を促進
し且つプロセス品質マトリックスの作成を容易にする。

【００１６】

【実施例】図１は、本発明のコンピュータ利用の汎用プ
ロセス制御システムの基本モジュールを概略的に示すも
のであり、それは報告モジュール１２を制御する制御モ
ジュール１０、ユーザ・インターフェース・モジュール
１４、記憶モジュール１６より成る。そのような各モジ
ュールは、以下では、それらの相互作用と同様に更に詳
細に説明される。

【００１７】しかし、まず、本発明の利益を生ずるプロ
セス作成ブロックの基本的概念を、図２に関連して説明
する。ついでながら、図１のシステムは、以下に示す説
明および流れ図に従って、図１のモジュールを含むよう
にプログラムされた汎用ディジタル・コンピュータによ
り実施可能であることは勿論である。

【００１８】図２に戻ると、任意のプロセスの模型を作
成するために繰り返し使用された図２のような原始的汎
用作成ブロックを準備することが本発明のキーである。
本発明は他の形式のプロセス作成ブロックを許容するも
のであることおよび図２に示されたものに限定されるべ
きでないことは勿論である。本発明の基本的思想は、ブ
ロックが、どんな形式にせよ、再使用されるという汎用
プロセス作成ブロックの概念である。以下で、更に明瞭
になるように、図２の汎用プロセス作成ブロックと関連
したいくつかの主要機構がある。

【００１９】まず、そのような方法は、プロセス・モデ
ル作成者がその作成ブロックを利用してプロセスの状態
を表わすのを可能にすることによって、種々の状態がお
もちゃのように連結可能となる。１つのプロセスをモデ
ル化するために利用された図２の各作成ブロックと関連
して、汎用の予め選択された遷移のセットがある。それ
は、リターン１８、スケジュール２４（同じ状態にとど
まる）、プロセス状態２０から出るコンプリート２４の
ような次の状態への移行を制御するものである。これら
遷移に対する名称の意味は後述するが、それら名称およ
び選択されたそのような遷移の数は、所与の状態と関連
したそのような遷移の集合が各状態に対して繰り返され
るという主要概念ほど重要ではない。この概念は、シス
テムによりプロセスの詳細な品質測定を与える能力、そ
して、プロセス遷移の標準化によって生ずるそのプロセ
スの任意のレベルにおけるプロセス・サマリを与える能
力を可能にするというような後述する数多くの利益を生
ずる。この形式の作成ブロックにより与えられるその他
の有益な特徴は、後で明らかになるような理由で、例え
ば、図５および図７で示されるように、明瞭にするため
に、遷移のラベルが除去可能になるということである。

【００２０】現時点では、この例では、３つの汎用タイ
プの遷移、即ち、プロセスの流れを前の状態に戻させる
リターン１８、その流れを次の状態にさせるコンプリー
ト２４、そして、スケジュール２２と表わされたような
ループ状態（そのプロセスにおける順方向の進行を表わ
そうとするものではない）が設けられているといえば十
分であろう。それが遷移の絶対数よりももっと重要な同
じセットの遷移の名称であることを説明するための次の
記述では、この特定のモデル化された説明上のプロセス
特有の理由のために、ループまたは反復遷移２２は、実
際には、３つのアクション、即ち、スケジュール・アク
ション、アサイン・アクション、ドゥ・アクション、に
細分されていることについての説明を行う。それにもか
かわらず、これらのアクション項目は、流れを他のプロ
セス状態にするリターン・アクション１８およびコンプ
リート・アクション２４から明らかなように、それらが
現在のプロセス状態で反復するという画一的な特性を示
す。図２の多数の作成ブロックを遷移の矢印により相互
接続することによって、このような各遷移でコミュニケ
ーションが生ずることが明らかに意図されていること
は、図７のプロセス図のような前述の説明上のプロセス
図のいて注目されるところである。

【００２１】スケジューリングを表わすことを意図した
スケジュール・アクションに加えて、場合によっては、
アサイン・アクションを生ずる個人の責任ではないアク
ションを再割当てする必要があった所有権の問題を生ず
ることが、いくつかのプロセスのモデル化でわかった。
同様に、或る実際のプロセスのモデル化において、所与
の状態に関して作業が実際に行われる単なるスケジュー
リング以上のものを意味するために、ドゥ・アクション
を加えることが有用であることがわかった。

【００２２】更に図２を参照すると、現在のプロセス状
態２０は、作成ブロックが記述に利用されるという所与
の状態に対して生ずる主要な処理を概説する。それは、
人間指向のプロセスにおける人間のようなその状態と関
連したアクションに責任のあるエンティティを識別し、
入口および出口の基準を記述し、質の標準を設定する。
上述のように、コンプリート変換は、プロセスを次の状
態に移行させ、他のエンティティまたは人間への割当て
を生じさせる。リターン遷移１８は、プロセスを前の状
態に戻すものであり、例えば、プロセスの割当て誤りが
あった場合に利用される。スケジュール・アクション２
２はプロセスの状態を変化させず、次の状態変化が生じ
そうな時をスケジュールするのに使用され、必要に応じ
て再スケジュールするのを可能にする。

【００２３】再び、図１を参照すると、ユーザ・インタ
ーフェイス・モジュール１４はユーザが図１のシステム
に及びその逆に相互作用するのを可能にする。制御モジ
ュールまたはサブシステム１０はいくつかの機能を備え
ている。それは、ユーザがオブジェクトを選択して、汎
用のライフ・サイクル・アクションの１つまたは前述の
ような遷移のセットの１つを選択するのを可能にする。
更に、制御モジュールは、オブジェクトの所有者のうち
の現在の所有者に対するユーザの有効化の機能を与え、
選択されたアクションまたは遷移の刷新を可能にし（ユ
ーザが有効化される場合）、そして、オブジェクトの活
動記録ログの維持を含む取られたアクションに従って、
ユーザ、チーム、オブジェクト・データの状態を更新す
る。

【００２４】図１のレポーティング・サブシステム、即
ち、モジュール１２は、状態毎のオブジェクトのサマリ
ーを含む、チーム、ロール、ユーザ、オブジェクト・タ
イプまたは個々のオブジェクトによるオブジェクト・ス
テータス・レポートの自動的生成を可能にする。更に、
それは、ライフ・サイクル活動記録の概要を含む同じグ
ループ分けによるオブジェクト活動記録の自動的生成を
与え、必要に応じて、ユーザ定義の他のレポートを与え
る。

【００２５】図３は図１の記憶モジュール１６を構成す
るサブモジュールを示し、ユーザ・リポジトリ２６、チ
ーム／ロール・リポジトリ３６、オブジェクト・リポジ
トリ２８、プロセス・リポジトリ３０より成ることがわ
かるであろう。

【００２６】ユーザ・リポジトリ２６は、システムの個
々のアクタについての情報を維持するために設けられ
る。それらアクタの各々は、次のような関連の構成要
素、即ち、そのユーザがメンバであるチーム／ロールの
リストおよびそのユーザが現在の所有者であるオブジェ
クトのリストを含む（しかし、これらに限定されるもの
ではない）。

【００２７】チーム／ロール・リポジトリ３６は、その
システムのグループまたはサブグループについての情報
を維持するために設けられる。それらグループの各々
は、次のような関連の構成要素、即ち、そのロールがメ
ンバであるチーム／ロールのリスト、このチーム／ロー
ルのメンバのリスト、そのチーム／ロールのいずれのメ
ンバも法律上の所有者である考えられるオブジェクトの
リストを含む（しかし、これらに限定されるものではな
い）。

【００２８】オブジェクト・リポジトリ２８は、そのプ
ロセスまたはシステムにある多くの相異なる種類のオブ
ジェクトの情報を維持するために設けられる。それらオ
ブジェクトの各々は、次のような関連の構成要素、即
ち、所有者（チーム、ロール、個人でよい）、そのオブ
ジェクトのライフ・サイクル・アクションまたは遷移を
管理するプロセス、そのプロセスにおける現在の状態、
ライフ・サイクルの活動記録を含む（しかし、これらに
限定されるものではない）。

【００２９】プロセス・リポジトリ３０は、そのシステ
ムにおける種々のオブジェクトのライフ・サイクルに関
する情報を維持するためのものである。モデル化される
べき１つのプロセスにおける諸プロセスは、現在の状態
から次の状態への遷移を含む状態を含んでいる。このよ
うなプロセス３０は、アサイン・アクション、スケジュ
ール・アクション、ドゥ・アクションに関するすべての
状態に対して１つの実施デフォルト・コードで、そし
て、コンプリート・アクション、リターン・アクション
または遷移に関するすべての状態のすべての遷移に対し
てデフォルト・コードで関連付けられている。前述のよ
うに、図２の作成ブロックは、コンプリート、スケジュ
ール、リターンを示しているけれども、そのモデルは拡
張性を認めるものである。

【００３０】状態３２は、それぞれの各状態に対して、
アサイン・コード、スケジュール・コード、ドゥ・コー
ドを、そして、それぞれの状態からのすべての遷移に対
して、デフォルトのコンプリート・コードおよびリター
ン・コードを持っている。結局、遷移３４は、特定の各
遷移に対してコンプリート・コードおよびリターン・コ
ードを含み、実質的には、プロセスの流れを順方向また
は逆方向に動かすアクションである。前述のように、こ
のような制御アクション（アサイン、スケジュール、ド
ゥ、コンプリート、リターン）の名称は、モデル化され
るそのプロセスの各状態に関して模写されるであろう機
能の汎用セットおよびそれらに対する名称を与えること
が本発明の１つの特徴であるので、特定のアクションの
選択のように任意である。

【００３１】図３を再び参照すると、プロセス・リポジ
トリ３０は、前述のように、次のような構成要素と関連
した情報を含んでいる。即ち、それら構成要素は、その
プロセス内の有効な状態のリスト（所有者が新しい所有
者を割当てた時に取られるべきユーザ指定のアクショ
ン、所有者がオブジェクトの次の状態変化をスケジュー
ルする時に取られるべきユーザ指定のアクション、所有
者がこのオブジェクトに対する現在の状態の作業を行う
時に取られるべきユーザ指定のアクションを含むが、そ
れらに限定されない）、有効な初期状態のリスト、最終
状態のリスト、遷移のリスト（移動元状態、移動先状
態、移動元状態から移動先状態にそのライフ・サイクル
において順方向にオブジェクトを移動する時に取られる
べきユーザ指定のアクション、移動先状態から移動元状
態にそのライフ・サイクルにおいてオブジェクトを逆に
移動する時に取られるべきユーザ指定のアクション、そ
の状態で特別に指定変更されない場合にそのプロセスに
おける任意の状態に対する有効な次の状態のリストを戻
すユーザ指定の機能、その状態で特別に指定変更されな
い場合にそのプロセスにおける任意の状態に対する有効
な次の所有者のリストを戻すユーザ指定の機能、その状
態で特別に指定変更されない場合にそのプロセスにおけ
る任意の状態に対するオブジェクトの状態変更するため
に取られるユーザ指定のアクションを含むが、それらに
限定されない）である。

【００３２】図４を参照すると、ユーザ・インターフェ
ース・モジュール１４により自動的に生成された説明上
のメニュー、即ち、スクリーン３８が示される。従っ
て、それは、考察中の特定のプロセスをモデル化してい
るインテグレータによりコード化する必要のないもので
ある。図４において注目すべき重要なことは、スクリー
ン３８のデスク・トップ・メタファ上に示される作業項
目Ａ ４０によって表わされたオブジェクトのような各
オブジェクトが、それが追従し得るプロセスに関係な
く、制御アクションの同じ基本セットをサポートし、そ
れによって従来技術のシステムよりも学習し易くすると
いうことである。

【００３３】説明の便宜上、図４で参照番号４１として
示された作業項目Ｃは、遭遇することある問題解決プロ
セスを説明するために設けられている。この作業項目Ｃ
を選択することによって、制御アクションの関連セット
４２、即ち、スケジュール４４、アサイン４４、リター
ン４８、ドゥ５０、コンプリート５２が現れ、制御モジ
ュールにおいて説明した機能をユーザが作動するのを可
能にする。スクリーン３８のそのような任意の作業項目
（例えば、作業項目Ａ）を作動する際にこれと同じセッ
トの汎用制御アクション４４〜５２が現れるということ
は、本発明の重要な特徴であり、図１２における従来技
術のものと比べた場合のこのシステムの使用の容易性の
もとになっている。従って、どんな作業項目をユーザが
選択しようとも、それを選択する特定のモデル化された
プロセスに関係なく、本発明は、画一的なユーザ・イン
ターフェース及びメニューで、画一的な汎用制御アクシ
ョン４２が自動的に生成されて現れるのを可能にする。
換言すれば、ユーザが任意のオブジェクト４０を選択し
てそのメニューをプルダウンする時、同じ５つのアクシ
ョン４２が現れる。これは、各遷移に異なる名前を付け
ることによりユーザ・インターフェース及びメニュー・
システムの形成及び使用を困難なものにしている従来技
術のモデルとは対称的である。

【００３４】図４に示されるように１つの作業項目が作
動される時、２つの付加的な選択が行われる。即ち、そ
れら選択はプロセス５４および活動５６であるが、本発
明がこれらに限定されるものではない。活動５６を選択
することは、図１のレポーティング・モジュール１２に
関して後述するように、活動概要報告書を作成する。上
述のように、他のアクション４４〜５２の内のどれかを
選択することは、制御モジュール１０において選択され
た特定な機能を作動する。最後に、プロセス５４を選択
することは、その結果として、そのオブジェクトまたは
作業項目（この例では、作業項目Ｃ）と関連した特定の
プロセスが図５に示されるようにスクリーン６０上に概
略的に描かれる。

【００３５】図５を更に詳細に参照すると、本発明は、
ここで開示した方法に従って、プロセスの定義に基き自
動的にこのプロセス図を作成するのを可能にする。説明
上のメニュー４４、７２を含むこのスクリーン６０は、
ユーザ・インターフェース・モジュール１４によって発
生され、従って、インテグレータによりコード化される
必要はない。これと関連したデータが、前述の記憶モジ
ュール１６からアクセスされる。汎用の作成ブロックを
使用するこの特徴は、従来技術のシステムよりも遥かに
容易に作業項目の新しいプロセスおよびタイプをカスト
マイズさせる。表示された特定のメニュー４４、７２
は、それぞれ、状態６４または遷移７４がそれぞれ選択
されたかどうかに依存する。スクリーン６０は、図２の
作成ブロックのモデルがプロセスの流れの図形表示を簡
単にする方法の代表的な説明である。順方向の遷移だけ
は示す必要がある。なぜならば、他のすべての遷移は仮
想のものであり、明瞭に描く必要がないためである。更
に、遷移のラベル付けは必要なく、それはこの考察中の
プロセスを指定しそして理解することを、従来技術のシ
ステムにおけるよりも容易にしている。

【００３６】或るユーザは、特定の作業項目（図４）に
対するユーザ・インターフェース・モジュールおける５
つのアクション４４〜５２を、その関連のプロセス（図
５）の概略説明を調べる必要なく遂行できるけれども、
本発明は、自動的に生成されるプロセスの全体的な流れ
を理解したい人のためにそのようなプロセス図、従っ
て、理解し易いプロセス図を与える。

【００３７】引き続き図５を参照すると、ユーザ入力収
集状態６４のような状態を選択する際に、ユーザ・イン
ターフェース・モジュール１４から５つのアクション４
４〜５２が発生され、現れる。使い易さの点で、汎用の
アクション・セットを持つことの利点は容易に明らかで
ある。アサイン・アクション４５をクリックすると、こ
のユーザ入力収集状態で新しい所有者を割当てる時に何
をすべきかが示される（勿論、それは、問題点識別状態
６２で新しい所有者を割当てる時にすべきこととは異な
ることもある）。従って、図２の作成ブロックで使用可
能にされた５つの遷移は、１つの遷移における逆方向の
流れを暗黙指定されるので順方向の流れだけを示す必要
があることを意味しており、そのプロセスの図および必
要なユーザ・アクションは、図１２の従来技術の場合よ
りもずっと明瞭である。アクション４４〜５２がどこに
現れようとも、それらアクションに関していつも同じで
あるので、アサイン・アクション４５は、その反復ルー
プ（図２のスケジュール２２のようなもの）を示す必要
さえないほどユーザを同じ状態に保持する。これはスケ
ジュール・アクションおよびドゥ・アクションに関して
もいえることである。

【００３８】図８を参照すると、図１の制御モジュール
１０の流れ図の更に詳細な説明が示される。このモジュ
ールは、図９および図１０に関連して詳細に示される継
承サブモジュール９２およびコンプリート遷移サブモジ
ュール９８を含む。後述するように、継承サブモジュー
ル９２およびコンプリート遷移サブモジュール９８のコ
ードを含むこの制御モジュール１０のコードはそのシス
テムによって与えられ、従って、インテグレータにより
コード化する必要がないので、コードの再使用性の特徴
を与えることに注目すべきである。

【００３９】更に詳しくいえば、本発明では、モデル化
されたプロセスが細分されて汎用の作成ブロックにさ
れ、コードが複数の汎用アクション（実施例では、５
つ）に分けられる。システムはそれらを自動的に結びつ
ける接着コードを与える。５つのアクションに対するコ
ードは個々のモジュールにあり、分離可能である。換言
すれば、割当てを行うためのコードをスケジュールを行
うためのコードと係わりあいにすることはできない。な
ぜならば、全体的には種々の問題点がそれらと関連付け
可能であるためである。割当てのためにコードを細分す
ることはスケジュール・コードへの変更にとって望まし
いことではない。コードを５つの汎用アクションに分け
ることによって、再使用性、プロセスの容易な理解およ
び隔離性の利点が得られ、そして、そのような再使用性
の結果、少ないコードしか書き込む必要がないようにし
ている。システムにより与えられる継承サブモジュール
処理コードおよびコンプリート遷移コードは、オブジェ
クトのプロセスの定義の一部分として記憶モジュール１
６で定義され、そして、実際のスケジュールまたはリタ
ーン・アクション等を行うよう作用する。

【００４０】制御モジュール１０の動作の説明におい
て、更に図８を参照すると、先ず、オブジェクトを呼び
出したユーザを決定し（８０）、そのユーザが正当なも
のであるかどうかをテストする（８２）。ユーザはシス
テムに対して定義されねばならず、従って、図３の記憶
モジュール１６におけるユーザ・ブロック２６に含まれ
なければならない。ユーザが正当でない場合、トランザ
クションは不許可にされる（８４）。次に、制御モジュ
ール１０は呼び出されるオブジェクトを決定し（８
６）、それが正当なオブジェクトであるかどうかをテス
トする（８８）。オブジェクトが正当なものであるため
には、ユーザは、その選択されたオブジエクトを所有す
るか、又は、正当なチームのメンバでなければならな
い。図３の記憶モジュール１６を参照すると、この情報
はチーム／ロール・サブモジュール３６に含まれ、そし
て、正当なオブジェクトが選択されない場合、トランザ
クションは不許可にされる（９０）。

【００４１】一旦、正当なユーザおよびオブジェクトが
選択されると、ユーザは所望の機能を選択でき（９
２）、図４の作業項目Ｃのようなその機能と関連した作
業を行うことができる。この時点で、システムは、５つ
のアクション（図４の４４〜５２）の内のどれをユーザ
が遂行したいかに関するユーザからの判断を待ち、図９
の継承モジュール９２が実行される。ユーザ・インター
フェース・モジュールにより表示されたスクリーン３８
（図４）からその作業項目Ｃが選択されなかったと仮定
すると、図９の処理は、どのアクションが選択されたか
に依存するエントリと共に蒸発する。リターン５１また
はコンプリート５３が選択された場合、動作は図９の左
ブランチに入り、記憶モジュール１６から適当な遷移を
アクセスする（１００）。一方、アサイン４５、スケジ
ュール４７またはドゥ４９が選択された場合、動作は図
９の右ブランチのアクセス状態１０６に入り、システム
はこの状態情報を記憶モジュール１６から得る。この例
では、遷移アクションを説明するためにリターンおよび
コンプリートが利用されたが、同様の例で、スケジュー
ル、ドゥ、アサイン状態を説明できる。

【００４２】リターン・アクションが選択された場合、
これは、間違って、ユーザ入力収集状態６４にある時に
問題点がユーザに与えられたことを意味し、それは、訂
正（フィールドの完成等）のためにシステムが前の状態
における正しい所有者に戻ることが望ましいためであ
る。

【００４３】リターン機能が定義される問題点識別６２
とユーザ入力収集６４との間の遷移６３において、その
遷移で定義された機能が実行される（図９の１０４）。
その機能が定義されない場合、例えば、システムが状態
レベルをデフォルトされる場合（１０５）、システムは
ユーザ入力収集における状態をアクセスし（１０６）、
リターン機能がそこで定義されたかどうかを決定する
（１０８）。その答えがイエスである場合、その状態で
定義された機能が実行される（１１０）。その答えがノ
ーである場合、プロセスがアクセスされ（１１２）、そ
の機能がそのプロセスで定義されたかどうかが決定され
る（１１４）。それが決定された場合、その機能が実行
され（１１６）、それが決定されなかった場合、システ
ム・デフォルトが実行される（１１８）。

【００４４】或る条件のもとでリターンすることだけが
望ましいい場合、その条件をチェックするためにその対
応するアクションにおけるコードが与えられ、そして、
それが誤りである場合、トランザクションは不許可にさ
れる。従って、ポリシーがリターンおよびコンプリート
・アクションに組み込まれてもよい。従来技術に関連す
るこれの重要性は、状態全体に対して１つの大きなポリ
シーとなるのではなく、ポリシーが５つの要素に細分さ
れることである。換言すれば、それぞれのプロセスを通
して作業項目を移行することに関連した機能を細分する
ために論理的方法が与えられる。

【００４５】図８を再び参照すると、選択された機能が
ブロック９４でテストされて成功または失敗を表示しな
ければならない。それが成功しなかった場合、トランザ
クションは不許可にされるが（９６）、それが成功した
場合、図１０のコンプリート・トランザクション・モジ
ュール９８が実行される。

【００４６】１つのトランザクションが終了し、そのコ
ンプリート・トランザクション・モジュール９８が実行
される場合、ユーザの選択したアクションがチェックさ
れる（図１０のブロック１２０）。そのトランザクショ
ンが終了した時、システムにより与えられた付加コード
が存在するので、リターン・アクションが選択される場
合、状態は、前の状態および所有者に自動的に変更され
る（１２２）。ユーザがアサイン・アクションを選択し
た場合、システムは所有者をその指定されたものに自動
的に変更する（１２４）。ドゥ・アクションが選択され
た場合、このアクションはそのタスクに対する適当なツ
ールを呼び出すことが出来るけれども、プロセスに関す
る限り、システムが行うことは実質的に何もない。スケ
ジュールが選択された場合、ユーザが指定した期日が変
更され（１２６）、そして、最後に、コンプリートが選
択された場合、システムは、ユーザが指定した次の状態
／所有者に状態を変更する。

【００４７】図５は、次の状態・所有者のユーザ仕様が
必要となる理由を示すものである。ユーザが問題点識別
状態６２にあり、コンプリートを行うことを望んでいる
場合、システムは選択すべき２つの遷移６３、７４を表
わすメニューを与える。遷移７４は、例えば、終了時に
処理される重要でない問題点を表わし、一方、遷移６３
は、プロセス状態６４〜７０全体を通して移行する解決
の必要のある真の問題点を表わす。以上から、システム
がプロセスを通してユーザを逐次に且つ図形的に導くた
めの自動的メニューを作成し得ることに注目すべきであ
る。

【００４８】図５は、判断レビュー状態６８からの２つ
の遷移７４、７９を設け得るという本システムの更にも
う１つの作用を示す。遷移７４では、これは、作業済み
として扱い得る程の作業を本質的には必要としないとい
う判断を表わし、一方、遷移７９は、リターンまたはコ
ンプリート７２を必要とし、見張り配置状態７０に入っ
て、状態６８の判断が実際に行われることを保証する。

【００４９】前述のように、図８乃至図１０のコード
は、システムによって与えられ、そのシステムにおける
他の場所で再使用される。これはプロセス作成ブロック
に対して許された所定の動作セットのために可能とな
る。これは、多くのコードが何回も書替えられ、デバッ
グされ、コメントされ、テストされなければならない従
来のシステムとは対照的である。注目すべき更にもう１
つのポイントは、システムが記憶モジュール１６から状
態および遷移情報をアクセスする図９において、そのよ
うな情報が記憶モジュールからアクセスされ、どんな機
能が遂行されるべきかをシステムに教える。継承モジュ
ールはどこでその機能が定義されたかを決定し、適正に
実行する。制御モジュール１０と記憶モジュール１６と
の間の相互作用が始まるのはこの態様である。

【００５０】図１の最後のモジュールであるレポーティ
ング・モジュール１２を示す図１１を参照すると、プロ
セスを管理および最適化する場合に並びにプロセスの要
素を相互に且つ他のプロセスに比較する場合に利用され
る種々のレポートおよびマトリクスを生成することは、
図２のプロセス作成ブロック技術に起因した本発明の特
徴である。１つの実施態様では、ユーザ・インターフェ
ース・モジュール１４が、例えば、レポーティング・モ
ジュール１２と関連してマトリクス１３２を生成する。
従来技術では、プロセスに関する問題点を見つけるため
に、そのプロセスの製品における欠陥を発見した時に原
因分析を行う欠陥予防のための種々なシステムが利用可
能である。一方、本発明により与えられるマトリクス機
能は、以下で更に明らかになるように、プロセスの問題
領域に関する特別な問題指摘を行う必要なしに、そのプ
ロセスにおけるどこに問題領域があるかを指し示すこと
を可能にするものである。換言すれば、本発明に関連の
作成ブロックの結果として生成されたマトリクスは、た
とえそのプロセスのステージＸで特別な欠陥が発見され
なくても、例えば、ターンアラウンド時間を改良する必
要があるかどうかをユーザが決定するのを可能にする。
例えば、或る特定のプロセスでは、そのプロセスが動作
する方法を更に明瞭に理解するためには、複数の別個の
状態に分ける必要があることを示す所与の複雑な状態に
対して、非常に多くのドゥ動作があるということが起こ
り得る。沢山のドゥが生じた場合、そのプロセスを調べ
ること、或るものは不必要であり、または、その他のも
のは自動化可能であることに気付くであろう。

【００５１】図１１を更に詳しく参照すると、垂直方向
には、汎用のアクション・リストがこれと関連した１つ
の列で示され、同じ汎用のアクション・リストが次アク
ション１３４でもって水平方向に繰り返される。この同
じアクション項目の汎用集合体が各状態に関して図２の
プロセス作成ブロックにより利用されるため、これらア
クションと関連したデータ、特に、見積りの時間と成
果、サイクル、並びに、実際の時間と成果、サイクルを
追跡することによって、図１１に示された方法で次のア
クション１３４と最終アクション１３６とを比較するこ
とが可能となる。この集められた情報は、後述のよう
に、マトリクスの各交点が質に関して異なった理解を持
っているので、プロセスにおける連続した改良を生じさ
せるよう利用可能である。

【００５２】従って、プロセスは、状態相互間の一貫性
のため、図１１に示されたようなサマリー・データによ
って、他のプロセスと更に容易に比較可能である。デー
タは、プロジェクト毎に、または、プロジェクト内およ
びプロジェクト間で任意の状態セット毎に、要約可能で
あり、比較可能である（例えば、歴史的プロジェクトは
最近のものと比較可能であるし、設計状態はプロジェク
トにまたがって合計可能であり、開発状態等と比較可能
である）。

【００５３】参照番号１３８で表わされた最終アクショ
ン行のリターン・アクション行および次アクション列に
関連した交点のデータに焦点を合わせると（リターン・
アクションは現在の状態におけるアクションを置かれた
アクションである）、これは問題が後で識別されること
を表わす。これは、リターン・アクションに後続して他
のリターン・アクションが生じるものである。例えば、
過度な数のリターン・アクションも１３８において表わ
すことができる。これは、ユーザにコンプリート・アク
ションを実行させるというポリシーが弱過ぎ、ユーザ
を、移行すべきでない次の状態に移行させることを示唆
する。従って、過度なリターンが生じ得る場合には、各
遷移に新しいポリシーを加えてもよい。例えば、図５の
プロセスの例に関して、これは、解決法を決定する前に
よりよいユーザ入力を収集することを要求するようにポ
リシーを修正することを示唆する。

【００５４】本発明のシステムはどんな新しいポリシー
を生じさせるべきかを示すものではなく、どこにそのポ
リシーを置くべきかを示すものであることに注意すべき
である。本発明は、例えば、問題点識別状態６２から生
じてユーザ入力収集状態６４に流れるものの仕様を厳格
にするポリシーを捜すことを提案するものであり、ま
た、問題点識別状態６２に対するコンプリート・アクシ
ョンには新しいポリシーが置かれるべきことを提案する
ものである。本発明の直接的成果として修正されるよう
なプロセス制御システムは、ユーザが新しいポリシーの
必要条件すべてを満たしてしまうまで、ユーザが次の状
態に移行するのを許容しないであろう。換言すれば、そ
のシステムは、図１１のマトリクスの結果、必要条件が
まだ完成していない（或るオブジェクトにおけるフィー
ルドが完成していない）ことをコンプリート・アクショ
ンが示したために、次の状態への遷移が許されないとい
うことになるかもしれない。

【００５５】図１１を更に参照すると、本発明に従って
モデル化されたプロセスの最終アクションおよび次アク
ションに関するアサイン・アクションの交点（例えば、
アサインに後続してアサインが生じる）は、同様に、そ
のプロセスの質的な面を表わしている。特に、この交点
における過度なアクションは、反復移行１５０で作られ
た時間を減少させる必要性を示唆する。この交点は、何
も達成されない場合に使われる潜在的に大きなサイクル
・タイムを測定する。図１１の下部に、アクションと関
連した移行が逆方向のもの１４８、反復的なもの１５
０、１５２、または順方向のもの１５４、１５６である
かどうかを各アクションに関連して示されていること
も、ついでながら、注目されよう。過度な量のアサイン
・アクションが検出される場合、これは、リターン・ア
クション、ドゥ・アクション、または、スケジュール・
アクションを生じさせる必要なくアサイン・アクション
だけに更に多くのインテリジェンスを組み込むことによ
ってアドレス可能である。従って、更に詳しく言えば、
或る状態に達した時に誰がアクションを持ち得るかに関
するポリシー、例えば、ユーザが特定な人にアサイン・
アクションまたはコンプリート・アクションを割当てる
のを許容することを管理するポリシー、を備えたコード
をアサイン・アクションおよびコンプリート・アクショ
ンに加えてもよい。図５の説明上のプロセスに関する例
として、おそらく、管理者は判断レビュー状態６８を持
たなければならず、技術者は解決法決定状態６６を持た
なければならず、そして、顧客はユーザ入力収集状態６
４を持たなければならない。

【００５６】従って、アサイン・アクションが、例え
ば、図５の判断レビュー状態６８のもとで走る場合、そ
れは、そのプロセスが図１１のマトリクスに従って修正
された後に機能停止するかもしれない。従って、これ
は、ユーザが判断レビュー状態のもとで判断をレビュー
するチームの管理者でない時、そのユーザがそのアクシ
ョンを持つべき正しい人でないことを表わす。従って、
アサイン・アクションまたはコンプリート・アクション
に組み込まれたポリシーが適合しない場合、そのユーザ
は再割当てすることを許されないであろう。従って、そ
のユーザは、或る状態から他の状態にプロセスを移行す
ることができず、或は、これが許されない場合、同じ状
態で他の誰かに移行することができない。

【００５７】図１１およびそのマトリクスにより与えら
れる利点について説明を続けると、次アクションおよび
最終アクションにおけるスケジュール・アクションの交
点１４２（例えば、スケジュールに後続してスケジュー
ルが生じる）は、それがそのようなスケジューリングの
証拠を単に示すだけであって何ら計画機能を遂行しない
限り、プロセスの質を改良するという点では、おそら
く、本発明のシステムが最も有用でないケースである。
この交点に示される過度な実行またはサイクル・タイム
は、下手な見積りまたは計画、或は、優先順位の変更の
証拠であり、より良いスケジューリングを必要とするか
もしれない。しかし、それにもかかわらず、図４のイン
ターフェースがユーザに責任のある作業項目を表わして
いるので、或る意味では、本システムは計画およびスケ
ジューリングを手助けするものである。

【００５８】上述のように、図１１のマトリクスは、ア
サイン・アクションの過度な量の反復移行を最小にする
ために、更に、リターン・アクションに関連したこの逆
方向移行１４８を最小にするために利用可能である。し
かし、従来の欠陥ある管理および同様なシステムとは違
って、本発明によれば、ドゥ・アクションおよびコンプ
リート・アクションのような順方向に移行するアクショ
ンから逆方向に移行するアクションを、簡単に且つ自動
的態様で極めて容易に分離することが可能である。特
に、図１１のマトリクス・システムは、これら順方向移
行タイプのアクションおよびそれらを最適化する方法へ
の集中を促すものである。ドゥ・アクションの交点に関
しては、リターン・アクションが生じた時とは対照的
に、それが逆方向の移行を結果として生じる質の問題の
ためであったことを、ユーザは知っている。

【００５９】交点１４４において過度な活動が示される
ドゥ・アクションを最初の取ることは、前述のように、
完了するのに長い時間を要する特に複雑な活動が生じ得
ることを表わす。これは、この特に複雑な状態を多数の
状態に分けることによってその状態で進行するものに関
して更に多くのコミュニケーションを与える必要性を示
唆する。それは、長い期間にわたって完成されるべき複
雑なタスクを正確にスケジュールする場合には特によい
かもしれないが、そのプロセスの顧客は、プロセスが正
確に進行しているかどうかに関して手がかりを持たな
い。従って、よりよいコミュニケーションを与えるため
には、ドゥ・アクションを過度に表示することは、いく
つかの複雑な状態を、追跡するに簡単なもっと細かい状
態に分解することが望ましいそのモデル化されたプロセ
ス内の位置を表わすことになるかもしれない。

【００６０】最後に、最終アクションおよび次アクショ
ンおけるコンプリート・アクションの交点１４６（例え
ば、コンプリートに後続してコンプリートを生じる）に
関して、これは除去ステップ１４６の可能性を表わす。

【００６１】いくつかのプロセスでは、或る個人が他の
個人に対するアクションを完了し、他の個人がトークン
・サインオフ以外に何もしない更に他の個人に対するア
クションを完了する場合、これはプロセスを遅らせる可
能性があり、不要なステップと思われる。単に承認のた
めに推移するアクション項目のポリシーが重要であるあ
る場合、そのようなポリシーはコンプリート・アクショ
ンに組み込み可能である。これは、リターン・アクショ
ンに関して過度な量のアクションを処理する従来例と同
じであり、その場合、遷移を進めて、例えば、不要なス
テップを取り除くようにコンプリート・アクションを修
正する。判断レビュー状態６８が実際には形式上のサイ
ンオフであった場合、図１１のマトリクスにより与えら
れたデータは、「盲判」というポリシーを解決決定状態
６６のコンプリート状態に作ることを示唆する。この場
合、コンプリート・アクションが行われる時、判断レビ
ュー状態６８は直ちに配置見張りに推移する。従って、
マトリクスにより示されたようにポリシーを固定するこ
とによって、不要なステップが除かれる。

【００６２】本発明におけるレポーティング・モジュー
ル１２は、機能が豊富である。図２のプロセス作成ブロ
ックおよび図１０のログ・トランザクション・ステップ
１３０のため、システムは、これら活動ログを走査する
自動レポーティング・メソッドを極めて容易に使用可能
にし、各状態（例えば、リターン、アサイン、スケジュ
ール、ドゥ、コンプリート）においてプロセスを得る方
法、次のアクションを決定するためにユーザが走らせた
アクション、トランザクションの開始から終了までに必
要な時間、増分的サイクル・カウント、作業項目に備え
て走らせた最終アクションから現在のアクションまでの
時間、サイクル・タイム等を自動的に決定する。換言す
れば、アクション項目の一般的識別のため、プロセス内
状態およびプロセス間状態の比較は容易に行うことが可
能になり、図１１のマトリクスの場合のようなシステム
・ユーザにとっても利用可能である。

【００６３】以上から、本発明の重要な特徴は、状態レ
ベルに対立する遷移レベルにおいて重要なプロセスの各
状態を記述するために反復して使用される汎用アクショ
ンの選択された汎用セットを提供することである、それ
によって、各状態に対して推移をこのようにラベリング
することによりシステム全体にわたって一様に各状態を
定義するのを容易にする。各プロセス作成ブロックを構
成するこれら説明上のドゥ、スケジュール、アサイン、
コンプリート、リターンという汎用の遷移は、１つの状
態に対して作用する。コンプリート・アクションは、そ
のプロセスにおける次の状態に移行するためのポリシー
およびアクションを記述し、リターン・アクションは、
そのプロセスにおける前の状態に移行するためのポリシ
ーおよびアクション記述し、アサイン・アクションは、
新しい所有者に移行するためのポリシーおよびアクショ
ンを記述し、スケジュール・アクションは、アクション
項目の予期した期日を変更するためのポリシーおよびア
クションを記述し、ドゥ・アクションは、状態自体の実
際の作業を遂行するためのポリシーおよびアクションを
記述する。

【００６４】本発明では、プロセス作成ブロックの重要
な特徴および同じ遷移を各アクションと関連付けること
により可能になったそれらアクションから構成されたマ
トリクスを設けることによって、多くの重要な恩恵が生
じる。

【００６５】まず、プロセス・ポリシー(例えば、状態
変化が起こり得る条件)が容易に分離可能であり、従っ
て、状態変化を生じさせるコードとの混乱がない。この
結果、ポリシーと変化アクションを分けて理解するのが
容易になり、ポリシーおよび変化アクションとも他のア
クションに影響を与えることなく修正することができ、
コードの可読性および再利用性が改良される。

【００６６】更に、アクションの汎用性のため、この結
果、ユーザ・インターフェースがプロセスを学習し、使
用し、記述することを容易にする。ユーザは、１つのプ
ロセス・モデルとその特定のプロセスに関係なく一組の
アクションを学習する必要があるだけである。これらア
クションは、どんな状態に入ろうとも同じであり、従っ
て、ユーザは、所与の状態における法的アクションを決
定するために複雑な状態・遷移マッピングを参照する必
要がない。更に、ユーザ・インターフェースによって、
もっと明瞭なプロセス図が与えられ、自動的に形成され
る。

【００６７】更に、本発明は、より容易な方法で、より
明瞭にプロセスを記述する能力を与えるものである。遷
移は、それが各状態にカストマイズされて一般的でない
標準的な状態遷移図と違って、ラベル付けする必要がな
い。本発明によれば、順方向の移行は最初の状態に戻っ
た状態と対にされると仮定されるので、プロセスの可視
表示では順方向を示す必要があるだけであり、そして、
各状態が同じ遷移を有するために他の遷移を示すことは
冗長である。

【００６８】更に、システムが、特定のプロセスを自動
化するインテグレータにより再使用可能な組込みコード
を与えそして状態の移行を管理する限り、本発明はプロ
セス制御の容易な自動化をあたえる。従って、前述のよ
うに、インテグレータはこれらポリシーを記録しないよ
うにすることもできる。

【００６９】更に、本発明は、そのレポーティング機能
に関しては、プロセスを測定しそしてそのプロセスにお
ける任意のレベルでデータを理解するための簡単な手段
を提供する。同じアクション・セットが所与の状態に入
ったり、出たりする。従って、例えば、同じアクション
から水平方向および垂直方向に２次元マトリクスを形成
することは容易になる。このようなマトリクスは、１つ
のプロジェクトに関する成果と時間を概説するのに及び
質を査定するのに利用可能であり、そして、マトリクス
の各交点が独特な質の連累を持っているので先行学習の
影響を受けて連続的にプロセスを改良する。

【００７０】更に、本発明は、プロセスとプロジェクト
との間の状態の一貫性のため、同じ汎用のプロセス形成
ブロックを利用してプロセス及び前のプロセス・サマリ
を比較するための簡単な手段を与える。従って、プロジ
ェクト相互間のデータ、プロセスおよびプロジェクト内
の及びそれらの間の任意の状態セットが容易に比較可能
である。また、汎用の形成ブロックおよびシステムにお
けるインテリジェンスが状態およびその状態相互間のな
がれの方向内にある（連結の種類または遷移は逆になっ
ている）ため、如何に複雑なプロセスでも記述可能であ
る。従って、プロセスを駆動し、データを収集し、プロ
セス内の任意の状態またはレベルにおける上記マトリク
スのようなステータスおよびサマリ・レポートを自動的
に生成するための自動化されたツールを作ることは、更
に容易である。

【００７１】

【発明の効果】ポリシーを理解し、アクションを別々に
変更し、且つ、他のコードに影響を与えることなく、そ
のアクションと関連したコードを修正をすることを容易
にする。

【図面の簡単な説明】

【図１】本発明のコンピュータ利用のプロセス管理シス
テムを構成するコンポーネントの概略図である。

【図２】代表的なプロセス形成ブロックを示す図であ
る。

【図３】図１の記憶モジュールの更に詳細な図である。

【図４】図１のシステム構成におけるユーザ・インター
フェース・モジュールにより生成されたスクリーンの代
表的な例を示す図である。

【図５】図４の作業項目Ｃに対する問題点解決プロセス
を説明するユーザ・インターフェース・モジュールのス
クリーンに現れた概略図である。

【図６】図２のプロセス作成ブロック利用するプロセス
の流れ図である。

【図７】図２のプロセス作成ブロックの使用の結果生じ
た他のプロセスの流れ図であって、本発明のプロセス作
成ブロックの使用を通してそのような流れ図が簡略化さ
れる態様を示す図である。

【図８】図１の制御モジュールの機能を実施した詳細な
流れ図である。

【図９】図１及び図８の制御モジュールの継承モジュー
ルの実施態様を示す流れ図である。

【図１０】図１及び図８の制御モジュールのコンプリー
ト・トランザクション・モジュールの実施態様を示す流
れ図である。

【図１１】プロセス質管理で使用するための図２のプロ
セス形成ブロックの使って図１のレポーティング・モジ
ュールにより生成されたマトリクスを示す図である。

【図１２】図２のプロセス形成ブロックを使うことなく
生成された従来技術の代表的プロセスの流れ図の１部分
である。

【図１３】図２のプロセス形成ブロックを使うことなく
生成された従来技術の代表的プロセスの流れ図の残りの
部分である。

【符号の説明】

１０・・・制御モジュール １２・・・レポーティング・モジュール １４・・・ユーザ・インターフェース・モジュール １６・・・記憶モジュール ４４・・・メニュー ４５・・・アサイン・アクション ４７・・・スケジュール・アクション ４９・・・ドゥ・アクション ５１・・・リターン・アクション ５３・・・コンプリート・アクション ６２・・・問題点識別状態 ６３・・・遷移 ６４・・・ユーザ入力収集状態 ６６・・・解決法決定状態 ６８・・・判断レビュー状態 ７０・・・見張り配置状態 ７２・・・メニュー ７４・・・遷移 ７９・・・遷移

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジェフリ・マーチン・ハンブリック アメリカ合衆国テキサス州オースチン・チ ョワン・ウエイ ラウンド・ロック2502 (72)発明者 ジェロルド・マーチン・ヘイマン アメリカ合衆国テキサス州オースチン・ウ ッドチェスタ・レーン3709 (72)発明者 トレーシ・ウエルス・ポーター アメリカ合衆国テキサス州オースチン・ノ ッティ・パイン・コーブ9800

Claims (8)

【特許請求の範囲】
1. 【請求項１】コンピュータ利用のプロセス制御システム
   であって、 前記システムとのユーザ対話を登録するためのユーザ・
   インターフェース手段と、 アクター、グループ、オブジェクト及び該オブジェクト
   のライフ・サイクルを定義する情報を記憶するための記
   憶手段であって、汎用のプロセス形成ブロックから生成
   された遷移を記憶するための手段を含むものと、 前記ユーザ・インターフェース手段及び記憶手段に相互
   接続され、前記情報及びユーザ対話に応答してプロセス
   制御を実行するための制御手段と、 より成るシステム。
2. 【請求項２】前記プロセス形成ブロックは、前記遷移の
   各々に共通の予め選択された汎用アクションのセットを
   含むことを特徴とする請求項１に記載のシステム。
3. 【請求項３】前記汎用アクションは、少なくとも、リタ
   ーン・アクション、コンプリート・アクション及びスケ
   ジュール・アクションを含むことを特徴とする請求項２
   に記載のシステム。
4. 【請求項４】前記汎用アクションは、ドゥ・アクション
   及びアサイン・アクションを含むことを特徴とする請求
   項３に記載のシステム。
5. 【請求項５】ユーザ・インターフェースを有するコンピ
   ュータ利用のプロセス制御システムを介してナビゲート
   する時に使用するための方法であって、 プロセス及び状態遷移の汎用セットをモデル化する状態
   遷移図の第１状態を前記ユーザ・インターフェース上に
   表示するステップと、 前記状態遷移図の第２状態及び前記状態遷移の汎用セッ
   トを前記ユーザ・インターフェース上に表示するステッ
   プと、 より成る方法。
6. 【請求項６】前記第１状態及び第２状態に対する前記状
   態遷移の汎用セットは、リターン・アクション、スケジ
   ュール・アクション及びコンプリート・アクションより
   成るグループから選択されることを特徴とする請求項５
   に記載の方法。
7. 【請求項７】前記第１状態及び第２状態に対する前記状
   態遷移の汎用セットは、リターン・アクション、スケジ
   ュール・アクション、コンプリート・アクション、アサ
   イン・アクション及びドゥ・アクションより成るグルー
   プから選択されることを特徴とする請求項５に記載の方
   法。
8. 【請求項８】ユーザ・インターフェースを有するコンピ
   ュータ利用のプロセス制御システムにおいて使用し、該
   システムによるプロセスの管理の質を表わすための方法
   であって、 前記プロセスのモデルを前記システムに記憶するステッ
   プあって、該モデルの状態遷移図における複数の状態の
   各々が汎用のプロセス作成ブロックにより表わされるも
   のと、 前記システムの動作中、前記複数の状態の各々と関連し
   たトランザクションをログするステップと、 前記ログすることに応答して、前記プロセスにおける最
   後のアクション及び次のアクションの汎用遷移アクショ
   ンに関連するマトリクスを生成するステップと、 より成る方法。