JPH07319961A - 情報処理システムおよび情報処理システムの作業の流れ管理方法 - Google Patents

Abstract

(57)【要約】 【目的】 情報を媒介にして連携する複数の作業工程か
らなる作業について、複数の作業工程の順序と、各作業
工程の処理内容を定めて、作業を支援する情報処理シス
テムにおいて、ルーティングを柔軟に、かつ、動的に決
定する。 【構成】 各作業工程に対して、その作業工程の仕事の
開始の際に、必要な情報の固まりを与えると共に、当該
作業工程からその作業工程の処理結果が前記情報の固ま
りに含められたものを得るようにする。作業工程の担当
者と、システムとの間でやり取りする情報の固まりの中
に、当該作業工程の後続の作業工程に作業を開始させる
か否かを決定するための情報のフィールドを追加するル
ーティング前処理手段３２を設ける。作業工程の担当者
からの情報の固まり中の、前記情報フィールドの内容に
基づいて、後続の作業工程に仕事を開始させるか否かを
決定するようにするルーティング後処理手段３３を設け
る。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】この発明は、情報を媒介にして連
携する複数の作業工程からなる作業について、複数の作
業工程の順序と、各作業工程の処理内容を定め、各作業
工程の間での情報の受け渡しなど、作業の処理を支援す
る情報処理システムおよび、この情報処理システムの作
業の流れ管理方法に関する。

【０００２】

【従来の技術】従来から、業務処理の効率化を図るため
に、コンピュータによる、いわゆるオフィスオートメー
ション化が提案されている。しかし、従来は、業務処理
においては、個々の作業処理自体についての自動化が行
なわれているだけであった。つまり、作業間の連携の部
分については、従来のオフィスオートメーションでは考
慮されていなかった。

【０００３】この作業間の連携部分を自動化して業務処
理のトータルな効率化や迅速化を図ろうとするものとし
て、ワークフロー・オートメーションが提案されてい
る。ワークフロー・オートメーションにおいては、作業
対象となる情報を媒介にして連携する複数の作業工程は
ワークフローと呼ばれ、このワークフローを自動化する
ための支援システムはワークフローシステムと呼ばれ
る。

【０００４】ワークフローシステムは、ネットワーク化
された分散処理環境などの処理環境において、業務処理
における複数のユーザ間の情報の受け渡しと、情報を受
けてから次の作業工程に渡すまでの間に処理すべき作業
などのルールを、予め設計、定義することにより業務処
理を自動化する情報処理システムである。

【０００５】このワークフローシステムは、次のような
処理機能で構成される。 業務処理の流れ、各業務におけるルールを定義するた
めの編集機能 テンプレート（定義されたワークフロー）を管理する
機能 処理すべき情報が配達されたことをユーザに知らせる
通知機能 配達された情報を管理するデータベース機能 設定された業務の流れ、ルールに従って情報を次の作
業工程に渡すルーティング機能 作業の状況を管理するための進捗管理機能 実行中のワークフローの維持管理を行なうためのシス
テム管理機能。

【０００６】このワークフローシステムの概要は、日経
ＢＰ社発行の雑誌「日経情報ストラテジー」 １９９３
年８月号、マイケル・Ｄ・カーン、安田誠寄稿、「ワー
クフロー管理技術とその可能性」Ｐ１２３〜Ｐ１３０に
記載されている。

【０００７】ワークフローが定義された場合、そのワー
クフローの仕事の流れ（フロー）はグラフ構造によって
表現される。図４７は、この定義されたワークフローの
流れの一例である。

【０００８】図４７において、それぞれ四角で囲まれた
各ノードは、作業の単位である作業工程（以下ステップ
と呼ぶ）を表している。各アーク（矢印）は仕事の流れ
（つながり、作業の順番や因果関係）を定義しており、
あるステップの後ろにステップがあるということは、前
のステップが完了しないと、後ろのステップは開始でき
ないことを意味する。逆に、前のステップが完了する
と、自動的に後ろのステップが開始するということを意
味する。

【０００９】ワークフローでは、各ステップでの実際の
作業は人間が行なうが、以上のような作業の流れの管理
は全てワークフローシステムが行なう。すなわち、ワー
クフローシステムは、定義されたワークフローを元に、
各ステップの作業が終了すると、適宜、次のステップの
作業を開始するようにして、作業全体の流れを管理す
る。

【００１０】上記のように、あるステップが完了した場
合に別のステップを開始するような機能をルーティング
機能と呼ぶ。あるステップの作業が終了したときに、後
続のステップの作業を開始させることをそのステップに
対してルーティングを行なうといい、後続のステップに
仕事を流さない場合はルーティングを行なわないとい
う。上述した文献には、このルーティングの方法の詳細
については、記述されてない。

【００１１】

【発明が解決しようとする課題】ところで、図４７に示
すような、すべてのステップの後ろに一つしかステップ
がない状況では、ルーティングは単純であり、前のステ
ップが終了したとき、自動的に次のステップに仕事を流
して、作業を開始させればよい。しかし、そのようなワ
ークフローでは単純な業務処理しか定義できず、通常
は、図４８に示すように、フローの途中に、分岐が設け
られたり、また、分岐されたステップが再び合流するよ
うなワークフローが定義されることが多々ある。

【００１２】このような複雑なワークフローにおいて
は、ルーティングを後続のステップに対してどのように
行なうかを決定する必要がある。すなわち、複数のステ
ップに分岐される場合においては、ルーティングの態様
としては、 後続の複数ステップのすべてにルーティングを行なう
方法 後続の複数ステップの内の一つにのみ、ルーティング
を行なう方法 後続の複数のステップの内の複数のステップにルーテ
ィングを行なう方法 などがある。

【００１３】図４７に示したような単純なワークフロー
でのルーティングは、前ステップの処理の終了通知後
に、ワークフローシステムが自動的に行なうことができ
るが、図４８に示したような分岐のステップにワークフ
ローシステムによってルーティングを行なわせる場合に
は、ルーティングを行なうか行なわないかを容易に決定
できる方策が望まれる。

【００１４】その方策の一例として、例えばワークフロ
ー起動時に、分岐後の複数ステップのどのステップにル
ーティングを行なうかをあらかじめ決めておく方法が考
えられる。しかし、このように、あらかじめルーティン
グの仕方を決定しておく画一的な方法では、前ステップ
でのユーザの処理結果などのユーザの要求に応じてルー
ティングを変えるなどの柔軟な決定を行なうことができ
ない。

【００１５】また、ワークフローシステムにルーティン
グを決定させるのではなく、前ステップのユーザが、分
岐後のステップについてのルーティングを決定すること
ができれば、非常に便利であるが、従来、そのための方
策は提供されていない。

【００１６】この発明の第１の目的は、分岐を含む複雑
なワークフローであっても、ルーティングの決定を容易
に行なうことができる情報処理システムを提供すること
である。また、ルーティングを作業結果やユーザの要求
に応じて柔軟に行なうようにすることができる情報処理
システムを提供する点にある。

【００１７】次に、上述のような分岐を有するワークフ
ローの場合には、合流のステップでの作業の開始の決め
方が問題になる。

【００１８】すなわち、図４７のような後続ステップが
一つの場合のワークフローのときには、前ステップの完
了の通知があれば、後ステップのルーティングを即座に
行って仕事を開始させることができるが、図４８のよう
な分岐の場合においては、上述のように、分岐後のすべ
てのステップの作業が行なわれる場合と、一部のステッ
プのみ、作業が行なわれる場合があるため、前のステッ
プのすべての終了を待って後ステップの仕事を開始させ
るという単純な方法でルーティングを行なうことができ
ない。作業が行なわれないステップでは、そのステップ
が完了するということはないからである。

【００１９】この発明の第２の目的は、以上のような分
岐後のルーティングに柔軟性を持たせた場合であって
も、合流の処理を確実に行なうことができるようにした
情報処理システムを提供することである。

【００２０】この発明の第３の目的は、作業担当者を定
めず機械が自動的に作業を実行する作業工程を設けるこ
とが可能にして、ワークフローによる作業を効率的に実
行することができるようにすることである。

【００２１】この発明の第４の目的は、複雑なワークフ
ローであっても、比較的容易に定義することが可能であ
り、かつ、その作業の流れの管理も簡易化することがで
きる作業の流れ管理方法を提供することである。

【００２２】

【課題を解決するための手段】上記課題を解決するた
め、請求項１の発明（以下第１の発明という）による情
報処理システムは、後述の実施例の参照符号を対応させ
ると、順序だって処理すべき作業を、複数個の作業工程
に分け、その複数個の作業工程の順序と、各作業工程の
処理内容を定めて、前記作業を支援する情報処理システ
ムであって、前記各作業工程に対して、必要な情報の固
まりを与えると共に、当該作業工程からその作業工程の
処理結果が前記情報の固まりに含められたものを得るよ
うにする情報処理システムにおいて、前記作業工程との
間でやり取りする前記情報の固まりの中に、当該作業工
程の後続の作業工程に作業を行なわせるか否かを決定す
るための情報のフィールドを追加する追加手段（３２）
と、前記作業工程からの前記情報の固まり中の、前記追
加された情報フィールドの内容に基づいて、後続の作業
工程に仕事を行なわせるか否かを決定するルーティング
手段（３３）とを設けたことを特徴とする。

【００２３】また、請求項２の発明（以下、第２の発明
という）による情報処理システムは、順序だって処理す
べき作業を、複数個の作業工程に分け、その複数個の作
業工程の順序と、各作業工程の処理内容を定めて、前記
作業を支援する情報処理システムであって、前記各作業
工程に対して、必要な情報の固まりを与えると共に、当
該作業工程からその作業工程の処理結果が前記情報の固
まりに含められたものを得るようにする情報処理システ
ムにおいて、前記作業工程に対して与える必要な情報の
固まりの中に、当該作業工程に直接的につながる複数個
の後続の作業工程のそれぞれに対して、その作業を行な
わせるか否かを決定するための情報フィールドを追加す
る追加手段（３２）と、前記作業工程についてあらかじ
め定義された約束事を実行することにより、前記追加さ
れた情報フィールドに、当該作業工程に直接的につなが
る複数個の後続の作業工程のそれぞれについて、その作
業を行なわせるか否かの情報を記述するルール評価手段
と、前記作業工程からの前記情報の固まり中の、前記情
報フィールドの内容に基づいて、前記後続の作業工程の
それぞれに対して仕事を行なわせるか否かを決定するル
ーティング手段（３３）とを設けたことを特徴とする。

【００２４】さらに、請求項３の発明（以下、第３の発
明という）による情報処理システムは、順序だって処理
すべき作業を、複数個の作業工程に分け、その複数個の
作業工程の順序と、各作業工程の処理内容を定めて、前
記作業を支援する情報処理システムであって、前記各作
業工程に対して、必要な情報の固まりを与えると共に、
当該作業工程からその作業工程の処理結果が前記情報の
固まりに含められたものを得るようにする情報処理シス
テムにおいて、前記作業工程の作業の終了時に、当該作
業工程からの前記情報の固まりに含まれる情報を用い
て、当該作業工程に直接的につながる複数個の後続の作
業工程のそれぞれへの移行に関してあらかじめ定義され
た約束事を実行するルール評価手段（３４）と、このル
ール評価手段の評価結果により、後続の作業工程のそれ
ぞれに対して仕事を開始させるか否かを決定するルーテ
ィング手段（３３）とを備えることを特徴とする。

【００２５】また、請求項４の発明（以下、第４の発明
という）の情報処理システムは、順序だって処理すべき
作業を、複数個の作業工程に分け、その複数個の作業工
程の順序と、各作業工程の処理内容を定めて、前記作業
を支援する情報処理システムであって、各作業工程の終
了状態を、作業終了となったことを示す作業終了状態
と、作業が開始されずに前記連携する複数の作業工程か
らなる流れから切り離されたことを示す切り離し状態と
で管理する作業工程の状態管理手段（３１）と、前記作
業工程の前の作業工程の状態のすべてが、前記作業終了
状態あるいは前記切り離し状態になったときに、当該作
業工程に作業を開始させるための処理を行なうルーティ
ング手段（３３）とを備えることを特徴とする。

【００２６】また、請求項５の発明（以下、第５の発明
という）の情報処理システムは、順序だって処理すべき
作業を、複数個の作業工程に分け、その複数個の作業工
程の順序と、各作業工程の処理内容を定めて、前記作業
を支援する情報処理システムであって、各作業工程の状
態を、作業の開始準備ができている状態を表す待機状態
と、作業を実行している状態を表す実行状態と、作業を
終了した状態を表す終了状態とで管理する作業工程の状
態管理手段（３１）と、前記作業工程が、担当ユーザに
より作業が実行される通常作業工程か、前記情報処理シ
ステム内において作業が実行される自動実行作業工程か
を判別する判別手段と、この判別手段での判別の結果、
前記通常作業工程であると判別されたときには、前記作
業工程の状態管理手段での状態データが前記待機状態に
なった作業工程の担当者に通知をした後、当該作業工程
の状態を実行状態にし、前記担当ユーザからの作業終了
の通知を受けて当該作業工程の状態を終了状態にし、前
記判別手段での判別の結果、前記自動実行作業工程であ
ると判別されたときには、当該自動実行作業工程の状態
が前記待機状態になったときに、前記実行状態に移行さ
せ、作業が終了したときには、前記自動実行作業工程の
状態を終了状態に移行させる作業工程管理手段とを備え
ることを特徴とする。

【００２７】また、請求項６の発明（以下、第６の発明
という）は、順序だって処理すべき作業を、複数個の作
業工程に分け、その複数個の作業工程の順序と、各作業
工程の処理内容を定めて定義し、各作業工程の作業が終
了すると、次の作業工程の作業を開始するように管理す
ることにより、前記作業を支援する情報処理システムの
作業の流れ管理方法において、前記定義された作業の流
れの内の適宜の作業工程において、その作業工程の作業
を細分化した作業の単位と、その細分化した作業の単位
の前後のつながりとで定義したサブフローを起動し、こ
のサブフローによる作業が完了したときに、前記サブフ
ローを起動をした作業工程は、終了できるようにしたこ
とを特徴とする。

【００２８】

【作用】第１の発明の構成においては、追加手段により
各作業工程とシステムとの間でやり取りされる情報の固
まりの中に、当該作業工程の後続の作業工程に作業を行
なわすか否かを決定するための情報フィールドが追加さ
れる。例えば、当該作業工程の後続の作業工程が複数個
あれば、各作業工程に対応してその数だけ上記の情報フ
ィールドが追加される。

【００２９】ルーティング手段は、当該作業工程の後続
の各作業工程についての上記の追加された情報フィール
ドの内容を参照して、それぞれの後続の作業工程への仕
事の受け渡しを行なうか否かの決定を行なう。

【００３０】このように、追加された情報フィールドを
用いて、後続の作業工程が分岐の場合であっても、当該
後続の作業工程に対してルーティングを行なうか否かを
容易に決定することができる。追加された情報フィール
ドに、作業工程の担当者が、当該作業工程の後続の作業
工程に仕事の受け渡しを行なうか否かの情報を記述した
場合には、作業工程の担当者により後続の作業工程に関
してルーティングを行なうか否かの指定ができる。つま
り、前作業工程の担当者により後作業工程に対するルー
ティングを指示することが可能となり、作業担当者の要
求を反映した柔軟なルーティングを行なうことができ
る。

【００３１】また、第２の発明の構成においては、ルー
ル評価手段は、作業工程についてあらかじめ定義された
約束事（以下、ルールという）を実行して評価し、その
評価結果として、後の作業工程に対するルーティングの
指示情報を、前記の情報フィールドに記入する。ルーテ
ィング手段は、この情報フィールドの内容に従って、そ
れぞれの後続の作業工程に仕事の受け渡しを行なうか否
かの決定を行なう。これにより、あらかじめシステムに
定義されたルールに従って後続の作業工程のルーティン
グが決定される。

【００３２】また、第３の発明の構成においては、ある
作業工程から、その後続の作業工程への仕事の受け渡し
に関するルールが定義されており、このルールが、作業
工程からの前記情報の固まりに含まれる情報を用いて実
行され、ルール評価手段で評価される。そして、ルーテ
ィング手段は、その評価結果により、ルーティングを決
定する。

【００３３】例えば、見積もり金額の額に応じて後続の
作業工程にどのようにルーティングを行なうかのルール
が定義されている場合には、作業工程からの情報の固ま
りに含まれるその見積もり金額が参照されて、前記のル
ールが実行され、その結果に応じて後の作業工程のうち
のどの作業工程に作業を開始させるが決定される。

【００３４】したがって、前の作業工程の作業結果など
を参照して、情報処理システムが、後の作業工程に対す
るルーティングを決定することができ、ワークフローの
実行中に、その作業状況に応じて動的、かつ、柔軟にル
ーティングの決定を行なうことができる。

【００３５】また、第４の発明の構成においては、連携
する複数の作業工程の流れから切り離された状態の切り
離し状態が作業工程の状態として状態管理手段で管理さ
れる。例えばルーティングが行なわれず、仕事が行なわ
れないことが決定した作業工程の状態が、この切り離し
状態となる。

【００３６】例えば分岐後の合流のように前作業工程が
複数個存在している場合には、前作業工程のすべてが終
了しないと合流の作業工程は仕事を開始することができ
ない。この場合に、前作業工程の一部にルーティングが
行なわれない作業工程があると、その作業工程は作業終
了状態にならないから、そのままでは合流の作業工程は
仕事を開始することができなくなる。

【００３７】第４の発明においては、状態管理手段はル
ーティングが行なわれない作業工程は切り離し状態と
し、これを終了状態として管理する。このため、ルーテ
ィング手段は、すべての前作業工程が作業終了状態ある
いは切り離し状態となったときは、合流の作業工程のす
べての前作業工程が終了したとすることができるので、
当該合流の作業工程にルーティングを行なう。

【００３８】このように、前作業工程に分岐の作業工程
があった場合において、一部の作業工程が実行されなか
ったときにも、分岐後の合流の作業工程において何等支
障を生じることなくルーティングを行なうことができ
る。

【００３９】第５の発明の情報処理システムにおいて
は、判別手段で、次の作業工程が通常作業工程であると
判別されたときには、作業工程管理手段は、状態管理手
段の状態データから上記の作業工程が待機状態になった
ことを検知すると、その作業工程の担当者に通知をす
る。すると当該担当者は作業開始の合図を送ってくるの
で、作業工程管理手段は、状態管理手段のその作業工程
の状態データを実行状態にする。当該作業工程の作業が
終了すると、担当者は、作業終了の通知を送ってくるの
で、この作業終了の通知を受けて、作業工程管理手段
は、状態管理手段の当該作業工程の状態データを終了状
態にする。以上のようにして作業工程の状態の遷移を管
理して、あらかじめ定められた順序に従って実行される
複数の作業工程からなるワークフローの流れを管理す
る。

【００４０】そして、第５の発明においては、担当ユー
ザによって作業が実行される通常作業工程の他に、自己
の情報処理システムの管理下にある自動実行作業工程が
設けられる。作業工程管理手段は、判別手段で次の作業
工程がこの自動実行作業工程であると判別されたときに
は、状態管理手段の状態データから当該作業工程が待機
状態になったと検知したときに、担当ユーザーに対する
通知の処理を省略して、当該作業工程の状態データを即
座に実行状態に移行させ、作業を実行させる。また、作
業が終了したときには、作業終了の通知を待たずに即座
に状態データを終了状態に移行させる。

【００４１】したがって、担当ユーザによらず、情報処
理システム自身あるいはその管理下にあるハードウエア
が自動実行作業工程を実行し、その自動実行作業工程の
終了後、次の作業工程に移行することが可能となる。す
なわち、人間よりも機械の方が向いている作業をワーク
フロー中に定義して自動的に実行させることが可能にな
る。

【００４２】第６の発明の情報処理システムの作業の流
れ管理方法においては、ワークフロー中の適宜の作業工
程において、サブフローが起動される。そして、このサ
ブフローによる作業がすべて完了となった後に、このサ
ブフローが起動された作業工程が作業終了可能となる。
したがって、ワークフローの作業の流れを階層的に定義
および動作させることができ、詳細で規模の大きいワー
クフローのみで運用する場合に比べて、より柔軟に対応
する運用をすることができる作業の流れ管理方法を構築
することができる。

【００４３】

【実施例】以下、この発明による情報処理システムの一
実施例を、図を参照しながら説明する。

【００４４】図２は、この例の情報処理システムの全体
の概要を示すもので、その機能をブロックとして示した
ものである。この情報処理システムは、前述したワーク
フローシステムの構成を有するものであって、システム
部１０と、ユーザインターフェース部２０とからなって
おり、ワークフローを管理して支援すると共に、各作業
工程（以下、作業工程をステップと呼ぶ）の担当者によ
る処理を支援するための作業環境を提供する役割も有す
る。

【００４５】システム部１０は、ファイル管理装置を内
蔵する例えばサーバー装置の構成とすることができる。
また、ユーザインターフェース部２０は、例えばワーク
ステーションなどの情報処理端末装置により構成するこ
とができ、そのディスプレイに各作業段階の作業環境を
表示することができる。ユーザインターフェース部２０
は、複数の担当者が共通の１個を共有して使用するよう
に構成することもできるし、担当者毎に設ける構成とす
ることもできる。そして、システム部１０とユーザイン
ターフェース部２０とを、例えばＬＡＮなどのネットワ
ークにより接続して、分散処理環境を構築することがで
きる。なお、システム部１０とユーザインターフェース
部２０とを同一の装置において構成することもできる。

【００４６】システム部１０は、テンプレート管理部１
１と、ルーティング管理部１２と、通知管理部１３と、
進捗情報管理部１４と、ユーザ管理部１５と、システム
管理部１６と、参照情報管理部１７とを備える。また、
ユーザインターフェース部２０は、編集部２１と、通知
部２２と、進捗管理部２３と、インターフェースコント
ロール部２４とを備える。

【００４７】ユーザインターフェース部２０の編集部２
１では、ユーザにより設定入力された業務処理の流れ、
各業務におけるルールによりワークフローを定義する。
システム部１０のテンプレート管理部１１は、定義され
たワークフロー（テンプレート）を管理する。

【００４８】システム部１０のルーティング管理部１２
は、後で詳細に説明するように、設定された業務の流
れ、ステップの担当者（ユーザ）による指定、あらかじ
め定義されたルールにしたがって、このルーティングを
行なう。

【００４９】システム部１０の通知管理部１３は、処理
すべき情報の配達の、ユーザ（担当者）への通知を管理
する。ユーザへの通知は、ユーザインターフェース部２
０の通知部２２が行なう。

【００５０】システム部１０の進捗情報管理部１４は、
作業の状況、作業の履歴を管理するための情報を管理す
る。ユーザインターフェース部２０の進捗管理部２３
は、この情報を用いて作業の状況を管理する。

【００５１】ユーザ管理部１５は、各ステップを担当す
るユーザを管理する。システム管理部１６は、システム
部１０の全体を管理する。参照情報管理部１７は、各ス
テップの担当者に与える、作業に必要な情報を管理す
る。

【００５２】［ワークフローシステムによるワークフロ
ーの流れの管理の概要］この例のワークフローシステム
においては、定義されたワークフローの各ステップを、
以下のような５つの状態により、その遷移状態を管理す
る。

【００５３】ステップがまだ作業を開始することがで
きない開始不可状態（以下、この状態を「ｎｏｔ ｒｅ
ａｄｙ」という） ステップの開始準備ができており、担当者の仕事の開
始を待っている待機状態（以下、この状態を「ｒｅａｄ
ｙ」という） 担当者が作業をしている実行状態（以下、この状態を
「ｒｕｎ」という） 担当者が作業を終了した作業終了状態（以下、この状
態を「ｃｏｍｐｌｅｔｅ」という） ルーティングが行なわれず、ワークフローから切り離
された切り離し状態（以下、この状態を「ｉｓｏｌａｔ
ｅ」という） の５種である。

【００５４】後述するように、あるステップの後続のア
ークが複数個存在、すなわち、複数のステップに分岐が
なされているときに、ルーティングが行なわれないステ
ップがあるとき、そのルーティングが行なわれないステ
ップが「ｉｓｏｌａｔｅ」の状態になる。

【００５５】以上のステップの状態遷移に応じてワーク
フローシステムは、基本的には、次のような動作を行な
い、この動作が各ステップに対して繰り返されることに
より、ワークフローは進行する。

【００５６】初期状態では、各ステップは、「ｎｏｔ
ｒｅａｄｙ」の状態にされている。ワークフローの起動
が行なわれると、最初のステップが「ｒｅａｄｙ」にさ
れる。また、後述するように、前ステップが終了したと
き（「ｃｏｍｐｌｅｔｅ」および「ｉｓｏｌａｔｅ」の
状態になったとき）に、ルーティング管理部により決定
された次のステップの状態が「ｒｅａｄｙ」とされる。

【００５７】ステップが「ｒｅａｄｙ」になると、担当
者に対して通知を行なうことにより作業の開始を促す。
担当者が開始の合図をワークフローシステムに対して行
なうと、ステップの状態は「ｒｕｎ」となる。このと
き、ワークフローシステムから担当者に対して、作業を
行なうために必要な情報をひとまとめにしたデータの固
まりを送り返す。このデータの固まりは、作業を行なう
ために必要な情報の実体と、その参照情報からなり、こ
れを以下パケットと呼ぶ。

【００５８】担当者が指定された作業を終了すると、作
業内容を反映させたパケットとともに、ワークフローシ
ステムに対し、完了の合図を送る。この時、ステップの
状態は「ｃｏｍｐｌｅｔｅ」となる。

【００５９】ワークフローシステムは各ステップが終了
した時に、次に実行されるステップを決定し、当該ステ
ップに対して、ルーティングを行なう。具体的には、当
該ステップの状態を「ｒｅａｄｙ」にすることによっ
て、担当者に通知を送り、ワークフローを進行させる。

【００６０】［ルーティングの方法の概要］上述したよ
うに、あるステップが終了すると次に実行されるステッ
プがルーティング機能により決定される。この場合にお
いて、前述もしたように、当該終了したステップに対し
て、後続のステップが、分岐のように複数のステップが
ある場合には、そのうちのどれを開始するのか、あるい
は全て開始しなければならないのかを決定しなければな
らない。この例においては、以下に説明するようにし
て、ワークフローの実行時に動的にしかも柔軟にルーテ
ィングが決定される。

【００６１】（１）担当者によるルーティングの指定方
法 ルーティングの指定方法のひとつとして、この例では、
ワークフロー中に分岐がある場合、分岐の手前のステッ
プの担当者により、次のステップを指定させる方法を用
いる。すなわち、この方法においては、ステップの担当
者には、次ステップの候補が示され、担当者は、そのう
ちルーティングを行なわせたいステップを選ぶ。

【００６２】これを実現するために、この例において
は、パケットにルーティング情報とよばれる情報のフィ
ールドを追加する。ルーティング情報には、例えばその
ステップの後続のステップの名前と真理値がペアになっ
て含まれている。あるいは、ルーティング情報には、後
続のアーク（例えばステップ１からステップ２のアーク
であればステップ１−２のように表現）と、その真理値
のペアが記述される。

【００６３】真理値の値はシステムによって初期化され
るが、ステップの担当者は、このルーティング情報の真
理値を変更することができる。値が「真」であることは
ルーティングが行なわれることを意味し、値が「偽」で
あることはルーティングが行なわれないことを意味す
る。

【００６４】システムによって初期化された値は、担当
者がルーティング情報を何も変更しなかった場合のデフ
ォルトの値となる。担当者は送られてきたルーティング
情報を参考に、目的を達成するために最も良いと判断さ
れるように真理値を変える。具体的にはルーティングを
行ないたいステップに対しては対応するルーティング情
報の真理値を「真」にし、ルーティングを行ないたくな
いステップに対してはルーティング情報の対応する真理
値を「偽」にする。これにより、ワークフローの実行中
にルーティングをステップの担当ユーザの指示により柔
軟かつ動的に決定することが可能となる。

【００６５】変更されたルーティング情報はパケットに
含まれ、作業完了の合図とともに、ワークフローシステ
ムに送り返される。システムはパケット中のルーティン
グ情報を参照し、後続のステップに対応する真理値を調
べ、「真」であるステップに対してはルーティングを行
ない、「偽」であるステップに対しては、ルーティング
を行なわない。

【００６６】（２）ワークフローシステムによるルーテ
ィングの指定方法 分岐の際のルーティングの決定は、場合によって担当者
ではなく、ワークフローシステムによって自動的に行っ
て欲しい場合もある。しかし、ワークフローシステムも
何の情報もなしにルーティングは決定することはできな
い。そこで、この例では、前のステップの作業結果の情
報を用いると共に、あらかじめ定義したルールなどの
「約束事」を用いることによって、ワークフローシステ
ムによるこの場合のルーティングの決定を実現する。こ
の方法は、担当者に直接ルーティングは指定させたくな
いが、担当者が下した別の判断を材料にルーティングを
決定する際に便利である。

【００６７】このワークフローシステムによるルーティ
ングの指定方法の一つとしては、前述したルーティング
情報フィールドを用いずにルーティングの決定を行なう
方法がある。例えばルールのみを用いてルーティングを
決定する方法である。すなわち、ルールなどの約束事の
実行（評価）の結果、ルーティングを行なうと決定した
ときには、真理値として「真」を、ルーティングを行な
わないと決定したときには、真理値として「偽」を、そ
れぞれ評価結果として得る。そして、その評価結果を用
いて、ワークフローシステムは、次の作業工程に対して
ルーティングを行なうか否かの決定をする。

【００６８】ワークフローシステムによるルーティング
の指定方法の他の方法としては、ルールを用いてルーテ
ィング情報フィールドの内容を記述するようにする方法
がある。この方法によれば、前述した担当者によるルー
ティングの決定方法と、このワークフローシステムによ
る自動のルーティングの決定方法とのいずれであって
も、ルーティング情報フィールドの内容を参照すること
によりルーティングを決定することができるので、ルー
ティングの決定のためのソフトウエアを簡略化できる。

【００６９】［第１の実施例の説明］以下に説明する第
１の実施例は、ルーティング情報フィールドを用いて担
当者が後続の作業工程に対してルーティングを行うか否
かの指定を行えるようにすると共に、ルーティング情報
フィールドを用いずにルールのみによりワークフローシ
ステムがルーティングを決定することができるようにし
た例である。

【００７０】この第１の実施例の場合には、ワークフロ
ーの定義を行なう時に、定義者は、ワークフローシステ
ムに自動的にルーティングを決めて欲しいステップに対
してルールを記述する。実際的には、あるステップＡの
後が分岐であった場合、そのステップＡの後続のすべて
のアークに対してルールを記述する。

【００７１】例えば、あるステップＡの担当者が出した
見積りの金額によって、その次のステップを自動的に選
ぶ場合の例を説明する。この場合、ルールとしては、例
えば見積もり金額Ｓが所定の基準値Ｒより大きい場合に
は、後続の例えば２分岐のステップＢ、Ｃの内のステッ
プＢにのみルーティングを行ない、見積もり金額Ｓが所
定の基準値Ｒより小さい場合には、後続の複数ステップ
の内のステップＣにのみルーティングを行なうように定
義したものを設定しておく。

【００７２】ステップＡの担当者に渡すパケットには、
担当者が見積もり金額を記述するための情報フィールド
が追加される。担当者が終了の合図をワークフローシス
テムに送ってからワークフローシステムがルーティング
の処理を開始するまでの間に、前述のように定義された
ルールによって、パケットの情報中の見積もり金額Ｓが
評価され、ルーティングが決定される。

【００７３】＜機能ブロック図の説明＞図１は、この第
１の実施例の情報処理システムにおけるワークフローの
流れの管理に関する部分の機能のブロック図である。

【００７４】テンプレート管理部１１は、定義されたワ
ークフローに関するデータを、記憶部１１Ｍに記憶す
る。定義されたワークフローの仕事の流れは、前述した
ように、作業の単位であるステップと、各ステップ間を
つなぐアーク（矢印）とからなるグラフ構造によって表
現される。したがって、ワークフローに関するデータ
は、ワークフローがどのような複数のステップからなっ
ているかを示すステップテーブルと、アークに関するデ
ータであるステップの実行順序のテーブルとで構成する
ことができる。

【００７５】また、前述したように、分岐のときのアー
クであって、当該分岐におけるルーティングをワークフ
ローシステムによって決定させるときには、各アークに
前述したようなルールが定義され、テンプレート管理部
１１の記憶部１１Ｍに記憶される。

【００７６】ルーティング管理部１２は、この場合、機
能的には、ステップ状態管理部３１と、ルーティング前
処理部３２と、ルーティング後処理部３３と、ルール評
価部３４と、パケット管理部３５とを備える。

【００７７】ルーティング前処理部３２は、次ステップ
の担当者に渡すパケットにルーティング情報フィールド
や見積もりなどのルーティングのために必要な情報フィ
ールドを追加する処理を行なう。

【００７８】また、ルーティング後処理部３３は、実際
のルーティングの決定を行なう。ルーティング後処理部
３３は、分岐のときのようにルールがアークについてい
れば、そのルールの評価をルール評価部３４に対して要
求する。ルール評価部３４は、テンプレート管理部１１
に記憶されているアーク毎のルールを実行してその評価
結果をルーティング後処理部３３に返す。

【００７９】ステップ状態管理部３１が、テンプレート
管理部１１に登録されている定義されたワークフローの
各ステップの状態を、前述の５種の状態により管理し
て、ワークフローの流れを管理する。このステップ状態
管理部３１は、定義されたワークフローの各ステップの
状態データの記憶部３１Ｍを備える。前述もしたよう
に、初期時には、各ステップの状態は「ｎｏｔ ｒｅａ
ｄｙ」となっている。

【００８０】ステップ状態管理部３１は、ステップの状
態が「ｎｏｔ ｒｅａｄｙ」から「ｒｅａｄｙ」になる
ときに、ルーティング前処理部３２に処理要求を出す。
ワークフローの開始時においては、担当者によるワーク
フローの起動要求を受けたとき、最初のステップの状態
が「ｎｏｔ ｒｅａｄｙ」から「ｒｅａｄｙ」になる。
また、ワークフローの実行中は、ステップ状態管理部３
１は、ルーティング後処理部３３からの要求によって、
ルーティングを行なうステップの状態を、「ｎｏｔ ｒ
ｅａｄｙ」から「ｒｅａｄｙ」にし、ルーティングを行
なわないステップの状態を「ｉｓｏｌａｔｅ」にする。

【００８１】ステップが「ｎｏｔ ｒｅａｄｙ」から
「ｒｅａｄｙ」になるとき、ステップ状態管理部３１
は、通知管理部１３に通知要求を出す。通知管理部１３
は、次ステップの担当者に対して通知を行なって担当者
の作業の開始を促す。

【００８２】この通知に対して担当者が開始の合図をワ
ークフローシステムに対して行なうと、この合図を通知
管理部１３が受け、ステップ状態管理部３１にその旨を
知らせる。ステップ状態管理部３１は、これに応じてス
テップの状態を「ｒｅａｄｙ」から「ｒｕｎ」にする。

【００８３】そして、ステップ状態管理部３１は、パケ
ット管理部３５にパケット送信要求を出して、このパケ
ット管理部３５より、担当者が作業を行なうために必要
な情報をひとまとめにしたデータの固まりであるパケッ
トを担当者に対して送る。このパケットには、ルーティ
ング前処理部３２により付加されたルーティング情報
や、その他のルーティングに必要な情報のフィールドが
含まれている。

【００８４】パケットは参照情報管理部１７により管理
され、参照情報管理部１７は、このパケットの記憶部１
７Ｍを有する。パケット管理部３５は、参照情報管理部
１７に管理されている情報を用いて次にルーティングす
るパケットを形成する。また、ユーザから得たパケット
を一時的に蓄え、そのルーティングに必要な情報フィー
ルドのデータをルーティング後処理部３３に送る。

【００８５】前述したように、ルーティング前処理部３
２は、パケット管理部３５がパケットを担当者に送る前
に、前述したルーティング情報や見積もりの情報などの
フィールドを、当該担当者に送るパケットに追加する処
理を行なう。

【００８６】担当者は、ワークフローシステムから配達
されたパケットを元に作業を実行する。また、担当者
は、パケットに追加された情報フィールドに、必要な情
報、例えば後続のステップに関するルーティング情報の
真理値や、ルール評価のための材料となる情報を記述す
る。

【００８７】指定された作業を終了すると、担当者は、
適宜、必要な情報を記述したルーティング情報や作業結
果の情報を含む、担当者の作業内容を反映させたパケッ
トとともに、ワークフローシステムに対し、完了の合図
を送る。このとき、ステップ状態管理部３１は、当該ス
テップの状態を「ｒｕｎ」から「ｃｏｍｐｌｅｔｅ」と
する。

【００８８】ステップ状態管理部３１は、ステップの状
態が「ｒｕｎ」から「ｃｏｍｐｌｅｔｅ」になるとき
に、ルーティング後処理部３３に処理要求を出す。ルー
ティング後処理部３３は、実際のルーティングの決定を
行なう。すなわち、ルーティング情報が付加されていれ
ば、それに基づいて次にルーティングを行なうステップ
を決定し、ステップ状態管理部３１に通知する。また、
当該ステップの後続のアークについてルールが定義され
ていれば、ルーティングのための情報中の前記ルール評
価の材料となる情報フィールドの値をルール評価部３４
に送って、このルール評価部３４に評価要求を出す。

【００８９】ルール評価部３４は、テンプレート管理部
１１のワークフローデータ中のあらかじめ定義されたル
ールを用いて評価を実行し、その結果をルーティング後
処理部３３に送る。ルーティング後処理部３３は、この
ルール評価部３４からの評価結果に基づいてルーティン
グを行なうステップを決定し、ステップ状態管理部３１
に通知する。

【００９０】ステップ状態管理部３１は、ルーティング
後処理部３３からの通知によりルーティングを行なうス
テップの状態を、「ｎｏｔ ｒｅａｄｙ」から「ｒｅａ
ｄｙ」にする。また、ルーティングを行なわないステッ
プの状態を、「ｎｏｔ ｒｅａｄｙ」から「ｉｓｏｌａ
ｔｅ」にする。以下、上述と同様の処理を繰り返して、
ワークフローを進行させ、後続のステップがなくなると
ワークフローの処理を終了する。

【００９１】＜ルーティング前処理部３２の動作の具体
例＞図３は、前述したルーティング前処理部３２で実行
される処理ルーチンＳ０の一例を示すフローチャートで
ある。

【００９２】ステップの状態が「ｎｏｔ ｒｅａｄｙ」
から「ｒｅａｄｙ」になると、ステップ状態管理部３１
から処理要求が到来して図３のルーティング前処理ルー
チンＳ０が開始し、現在のステップ（「ｒｅａｄｙ」の
状態になったステップ）の後続アークのすべてを、ワー
クフローデータを参照して探す。また、その他の必要な
情報フィールドを追加する（処理Ｓ１）。

【００９３】次に、そのステップに送るパケットに、後
続アークの数だけルーティング情報フィールドを追加す
る（処理Ｓ２）。次に、前記後続アークの属性情報を調
べ（処理Ｓ４）、ワークフローシステムにより設定され
ているデフォルトのルーティング情報があるか否か判別
し（判断Ｓ５）、デフォルトのルーティング情報が存在
すれば、そのルーティング情報で、前記追加したルーテ
ィング情報フィールドを初期化する（処理Ｓ６）。

【００９４】判断Ｓ５でデフォルトのルーティング情報
がないと判断された場合、あるいは、処理Ｓ６の処理が
終了した後には、ステップＳ３に進んで、前記後続のア
ークのすべてのアークについて処理Ｓ４〜Ｓ６の処理が
終了したか否か判断し、終了していなければ、処理Ｓ４
〜Ｓ６を繰り返し、すべてのアークについての処理が終
了したときには、このルーティング前処理ルーチンは終
了となる。

【００９５】＜ルーティング後処理部３３の動作の具体
例＞図４は、前述したルーティング後処理部３３で実行
される処理の一例を示すフローチャートである。ステッ
プの状態が「ｒｕｎ」から「ｃｏｍｐｌｅｔｅ」になる
ときに、ステップ状態管理部３１から処理要求が到来し
て図４のルーティング後処理ルーチンＳ１０が開始す
る。

【００９６】まず、状態が「ｒｕｎ」から「ｃｏｍｐｌ
ｅｔｅ」になった現在のステップ（以下、このステップ
を現在ステップＰＳと称する）の後続のステップの処理
は、終了しているか否か、つまり処理が終了していない
後続ステップがあるか否か判断し（判断Ｓ１１）、処理
が終了していない後続のステップがなければこのルーチ
ンＳ１０を終了する。

【００９７】現在ステップＰＳに対して処理が終了して
いない後続のステップ（以下、このステップを後続ステ
ップＢＳと称する）が存在する場合には、その後続ステ
ップＢＳに至るアークにルールが定義されているか否か
判断する（判断Ｓ１２）。ルールが定義されていれば、
ルール評価部３４に対してルール評価処理の要求を出す
と共に、現在ステップＰＳからのパケット中のルール評
価のためのルーティング情報フィールドの情報を送っ
て、ルール評価を実行させる（処理Ｓ１３）。その後、
判断Ｓ１４に進む。

【００９８】そして、判断Ｓ１４では、そのルール評価
結果を受けて、その後続ステップＢＳにルーティングを
行なうか否か判断する。また、判断Ｓ１２でアークにル
ールが定義されていないと判断されたときには、そのま
ま判断Ｓ１４に進んで、ルーティング情報フィールドの
アークに関する真理値を参照して、その後続ステップＢ
Ｓにルーティングを行なうか否か判断する。

【００９９】判断Ｓ１４で、ルーティングを行なうと判
断したときには、判断Ｓ１５に進み、ルーティングを行
おうとする後続ステップＢＳにアークによってつながっ
ている前ステップが複数あることを想定して、その前ス
テップはすべて終了となっているか否か判断する。この
判断Ｓ１５での前ステップの終了の判断は、前ステップ
が「ｃｏｍｐｌｅｔｅ」の状態になっているか、あるい
は「ｉｓｏｌａｔｅ」の状態になっているかによって行
なう。

【０１００】判断Ｓ１５で、すべての前ステップが終了
していると判断されたときには、当該後続ステップＢＳ
の状態を「ｎｏｔ ｒｅａｄｙ」から「ｒｅａｄｙ」に
変更する要求をステップ状態管理部３１に出し、判断Ｓ
１１に戻って、現在ステップＰＳの他の後続ステップＢ
Ｓに関する上述の処理を行なう。

【０１０１】また、判断Ｓ１５において、ルーティング
を行おうとする後続ステップＢＳの前記複数の前ステッ
プのうちの一部が終了となっていないと判断されたとき
には、当該後続ステップＢＳの状態を「ｎｏｔ ｒｅａ
ｄｙ」から「ｒｅａｄｙ」にする要求は出さずに、この
後続ステップＢＳに関してスタートフラグを立てる（処
理Ｓ１７）。そして、判断Ｓ１１に戻って、前記現在ス
テップＰＳの他の後続ステップＢＳに関して上述の処理
を行なう。

【０１０２】また、判断Ｓ１４において、後続ステップ
ＢＳに対してルーティングを行なわないと判断された場
合には、判断Ｓ１８に進み、ルーティングを行なわない
当該後続ステップＢＳの前ステップはすべて終了となっ
ているか否か判断する。この判断Ｓ１８での前ステップ
の終了の判断も、前述と同様に、前ステップが「ｃｏｍ
ｐｌｅｔｅ」の状態になっているか、あるいは「ｉｓｏ
ｌａｔｅ」の状態になっているかによって行なう。

【０１０３】判断Ｓ１８において、ルーティングを行な
わない後続ステップＢＳの前の複数のステップのうちの
一部が終了となっていないと判断されたときには、その
まま判断Ｓ１１に戻って、前記現在ステップＰＳの他の
後続ステップＢＳに関して上述の処理を行なう。

【０１０４】また、判断Ｓ１８において、ルーティング
を行なわない後続ステップＢＳの前のステップがすべて
終了であると判断されたときには、判断Ｓ１９に進み、
当該後続ステップＢＳにスタートフラグが立っているか
否か判断する。スタートフラグが立っていれば、処理Ｓ
１６に進み、当該後続ステップＢＳの状態を「ｒｅａｄ
ｙ」とし、判断Ｓ１１に戻る。

【０１０５】すなわち、判断Ｓ１９において、スタート
フラグが立っている状態は、現在ステップからはルーテ
ィングを行なわない後続ステップＢＳに、現在ステップ
と異なる他のステップからのルーティングが行なわれる
ことが決定されていて、そのルーティングが待ちの状態
になっていることを示している。そして、当該後続ステ
ップＢＳの前ステップはすべて終了であると判断Ｓ１８
で既に判断されているので、当該後続ステップへのルー
ティングが可能になる。このため、処理Ｓ１６に進ん
で、「ｒｅａｄｙ」の状態となる。

【０１０６】また、判断Ｓ１９において、スタートフラ
グが立っていないと判断されたときには、処理Ｓ２０に
進み、当該後続ステップＢＳの状態を「ｉｓｏｌａｔ
ｅ」にする。次に、処理Ｓ２１に進み、当該後続のステ
ップＢＳの後続のステップに移行してそのステップに対
して処理Ｓ１８から処理Ｓ２０までの処理を行なう。こ
うして、「ｉｓｏｌａｔｅ」の状態になったステップの
後続のステップについて、処理Ｓ１８から処理Ｓ２０ま
での処理を再帰的に行なう。その後、判断Ｓ１１に戻
る。

【０１０７】＜第１の実施例が適用されたワークフロー
の具体例＞ワークフローの第１の具体例として、以下、
図面作成処理のフローの場合の例について説明する。

【０１０８】図５は、図面作成処理のフローの例を有向
グラフにより現したものである。この例の図面作成処理
のワークフローは、ステップ番号１のステップ（以下、
ステップ１という）が「図面の作成」、ステップ番号２
（以下、ステップ２という）と、ステップ番号３（以
下、ステップ３という）とが「図面の検査」、ステップ
番号４（以下、ステップ４という）が「図面の承認」の
４つのステップからなり、ステップ１からステップ２ま
たはステップ１からステップ３に分岐し、ステップ２お
よびステップ３からステップ４に合流するものとして定
義されている。

【０１０９】この例の場合、テンプレート管理部１１で
管理される、定義されたワークフロー（テンプレート）
に関するデータは、図６に示すような、ワークフローが
どのような複数のステップからなっているかを示すステ
ップテーブルＳＴと、図７に示すような、ステップの実
行順序の情報である実行順序テーブルＯＴとからなる。
実行順序テーブルＯＴには、ステップ識別子としてのス
テップ番号を用いて前後のステップが記述されることに
よりアークが記述されることになる。なお、実行順序テ
ーブルＯＴにおいて、ステップ番号「０」は、開始のス
テップ、ステップ番号「ＮＵＬＬ」は、終了のステップ
を示している。

【０１１０】この例の場合には、複数個のワークフロー
を同時に管理することを想定しているためステップテー
ブルＳＴと、実行順序テーブルＯＴには、ワークフロー
識別子が付与されており、このワークフロー識別子によ
り、いずれのワークフローであるかが一意に識別され
る。図の例のワークフロー識別子「１０００」は、図面
作成処理のワークフローを示している。

【０１１１】この例の説明において、ステップ番号は各
ステップの識別子となる。また、ステップ名は、各ステ
ップで行なう作業内容を示す作業名である。担当者の欄
には、各ステップの作業を実行するユーザ名が記述され
る。ユーザの代わりに、営業部門、設計部門などの担当
部門が担当者として設定される場合や、図面作成者、検
査者、承認者などの作業を実行する役割者名が記述され
る場合もある。担当ユーザ名の代わりに担当部門名や、
役割者名が担当者の欄に記述される場合には、ユーザ管
理部１５で管理されている、個々のユーザと担当部門と
の対応や、個々のユーザと役割者名との対応に応じて実
際に担当するユーザ名が決定される。

【０１１２】前述したように、ワークフローを流れるデ
ータを管理するために、パケットにワークフローを実行
するための必要な様々な情報を含めて、各ステップから
次ステップへと渡される。

【０１１３】ワークフローにおけるパケットの流れと、
その内容の変化と、パケットの情報フィールドを用いた
ルーティングの決定の仕方の例を、この例の図面作成の
ワークフローを用いて以下に説明する。

【０１１４】（１）担当者によるルーティングの決定の
場合 まず、ステップ１の担当者が、その後続のステップ２、
３にどのようにルーティングするかを決定する場合につ
いて説明する。

【０１１５】まず、起動者によってワークフローが起動
される。起動する際に、起動者は、最初のステップの担
当者宛てのメッセージがあれば、その通信文を書く。

【０１１６】図８は、ステップ１が開始されるときに作
成され、ステップ１の担当者に送られるパケットの内容
の例であり、フィールド名と、そのフィールド値からな
る。フィールド名「担当者」「作業名」「概要」の欄の
フィールド値は、ワークフローを定義したときに定義さ
れている値であり、ワークフローシステムがワークフロ
ーデータから転記する。

【０１１７】フィールド名「コメント」の欄はワークフ
ローを起動した者が、最初のステップの担当者宛ての通
信欄として使用することができる。１回、ワークフロー
が起動されると、この「コメント」の欄は、前の担当者
から次の担当者への連絡用に使われる。

【０１１８】フィールド名「Ｄａｔｅ」「Ｃｕｒｒｅｎ
ｔ Ｓｔｅｐ」の欄のフィールド値は、それぞれ当該パ
ケットが送信された日付と、送信の宛先のステップ番号
であり、ワークフローシステムが自動的に追加する。

【０１１９】そして、ワークフローシステムは、起動者
によるワークフローの起動を受けて、ステップ１の状態
を「ｒｅａｄｙ」にしたとき、前述したルーティング前
処理を実行する。このルーティング前処理では、ステッ
プ１の下流に、ステップ２とステップ３の二つのステッ
プがあるため、ルーティングのための二つのフィールド
「ｓｔｅｐ−１−２」「ｓｔｅｐ−１−３」を付加し、
デフォルトのフィールド値として「真（図ではｔｒｕｅ
と示した。以下同じ）」を挿入する。

【０１２０】フィールド「ｓｔｅｐ−１−２」は、ステ
ップ１からステップ２へのアークを示し、フィールド
「ｓｔｅｐ−１−３」は、ステップ１からステップ３へ
のアークを示している。なお、前述もしたように、フィ
ールド値の「真」は、ルーティングを行なうことを意味
しており、「偽（図ではｆａｌｓｅと示す。以下同
じ）」はルーティングを行なわないことを意味してい
る。

【０１２１】前述したように、ステップ１の状態が「ｒ
ｅａｄｙ」になった後、担当者から作業開始の合図が来
ると、上述の図８のような内容の最初のパケットが、ス
テップ１の担当者に送られる。ステップ１の担当者は、
受け取ったパケットの中身を見て、自分の仕事が図面作
成であることを知り、図面作成の作業を行なう。作成し
た図面は、担当者がパケットに追加する。担当者は、ま
た、必要に応じて次ステップの担当者に宛てたメッセー
ジをパケットの「コメント」の欄に挿入する。

【０１２２】また、ステップ１の担当者は、パケット内
のルーティングの情報フィールドである二つのフィール
ド「ｓｔｅｐ−１−２」「ｓｔｅｐ−１−３」のフィー
ルド値を書き換えることにより、後続の二つの検査のス
テップ２とステップ３に対するルーティングを決定する
ことができる。この例では、デフォルトのフィールド値
は、「真」であるので、フィールド値を書き換えること
は、ルーティングを行なわないことを指示することに等
しい。

【０１２３】ステップ１の作業が終了したときのパケッ
トの例を図９に示す。この図９のパケットでは、ステッ
プ１の担当者によって、ステップ３にルーティングを行
なわないように指示されている。なお、パケットの情報
フィールドの欄の内、「担当者」や「Ｄａｔｅ」などの
ワークフローシステムが用いる欄は、担当者が勝手に変
えることはできないように構成されている。

【０１２４】ステップ１が終了すると、その終了の合図
と共に、図９のパケットがワークフローシステムに返送
されてくる。このパケットを受けると、ワークフローシ
ステムは、前述したように、ルーティング後処理を開始
する。

【０１２５】すなわち、ワークフローシステムは、受け
取ったパケットの中身を検査し、ルーティングの情報を
用いて後続のステップに対するルーティングを行なうか
否かの決定を行なう。この例の場合には、フィールド
「ｓｔｅｐ−１−２」の値が「真」であるので、ステッ
プ２にはルーティングを行なう。しかし、フィールド
「ｓｔｅｐ−１−３」は「偽」であるので、ステップ３
にはルーティングを行なわない。そして、ステップ２に
は、ルーティングを行なうので、その状態を「ｒｅａｄ
ｙ」にする。また、ステップ３には、ルーティングを行
なわないので、その状態を「ｉｓｏｌａｔｅ」にする。

【０１２６】そして、ルーティングを行なうステップ２
にパケットを送るために、ワークフローシステムは、
「担当者」「作業名」「概要」などのフィールドの値を
入れ替え、また、ルーティング前処理を行って、フィー
ルド「ｓｔｅｐ−２−３」をパケットに付加し、そのフ
ィールド値としてデフォルトの「真」を挿入し、そのパ
ケットをステップ２の担当者に宛てて送る。ただし、こ
のフィールド「ｓｔｅｐ−２−３」のように、後続のス
テップが一つしかない場合には、そのデフォルトのフィ
ールド値は、「担当者」や「Ｄａｔｅ」などの欄と同様
に、担当者が勝手に書き換えることができないように構
成されている。

【０１２７】ステップ２の担当者は、受け取ったパケッ
トの中身を見て、自分の仕事が図面検査であることを知
り、図面検査の作業を行なう。検査後の図面は、担当者
がパケットに戻す。担当者は、また、必要に応じて次ス
テップの担当者に宛てたメッセージをパケットの「コメ
ント」の欄に挿入する。

【０１２８】そして、ステップ２の作業が終了すると、
終了の合図と共に、前記パケットがワークフローシステ
ムに戻される。ワークフローシステムは、終了の合図に
よって、ステップ２の状態を「ｒｕｎ」から「ｃｏｍｐ
ｌｅｔｅ」にする。そして、ルーティング後処理を行な
い、パケットのルーティング情報フィールド「ｓｔｅｐ
−２−３」の値が「真」であることから、ステップ４に
ルーティングを行なうことを決定するが、ステップ４に
は、前ステップとして、ステップ３の存在するので、ス
テップ２の状態だけでなく、ステップ３の状態をも参照
する。このとき、ステップ３の状態は「ｉｓｏｌａｔ
ｅ」になっているので、ステップ２の状態「ｃｏｍｐｌ
ｅｔｅ」と合わせて、ステップ４の前ステップのすべて
が終了したと判断して、前述と同様にしてステップ４に
ルーティングを実行する。

【０１２９】（２）アークに付いたルールによるルーテ
ィングの決定の場合 この例の場合、ワークフローの定義時に、分岐のときの
アークに対してルールを記述しておく。このルールの例
を図１０および図１１に示す。図１０は、ステップ１か
らステップ２へのアークに付いているルールの例であ
り、「ステップ１で計算された見積もり金額が１０００
０円を越えた場合には、ステップ２にルーティングを行
ない、ステップ３にはルーティングを行なわない、１０
０００円以下の場合には、ステップ３にルーティングを
行ない、ステップ２にはルーティングを行なわない」と
いう内容である。

【０１３０】また、図１１は、ステップ１からステップ
３へのアークに付いているルールの例であり、「ステッ
プ１で計算された見積もり金額が１００００円以下であ
る場合には、ステップ２にルーティングを行ない、ステ
ップ３にはルーティングを行なわない、１００００円を
越えた場合には、ステップ３にルーティングを行ない、
ステップ２にはルーティングを行なわない」という内容
である。

【０１３１】この例の場合には、ステップ１にルーティ
ングが行なわれるときに、ルーティング前処理により、
そのステップ１の担当者に送られるパケットには、図１
２に示すように、ステップ１からステップ２へのアーク
およびステップ１からステップ３へのアークに関するル
ーティング情報フィールド「ｓｔｅｐ−１−２」「ｓｔ
ｅｐ−１−３」に加えて、「見積もり」のフィールドが
追加される。

【０１３２】ステップ１の担当者は、前述したようにし
て、図面作成の作業を行なうと共に、見積もり金額を計
算し、その金額をパケットの「見積もり」のフィールド
に、そのフィールド値として挿入する。例えば担当者は
見積もり金額を「１２０００円」と決定した場合、その
値「１２０００」をフィールド「見積もり」の値として
挿入する。この場合のステップ１の終了時のパケットの
例を図１３に示す。

【０１３３】ステップ１の担当者が作業を終了し、その
合図をしたとき、図１３のパケットがワークフローシス
テムに返送される。これを受けて、ワークフローシステ
ムは、ルーティング後処理を開始する。この場合、ステ
ップ１の後続のアークには、ルールが付いているので、
パケットに追加されているルーティング情報の真理値を
確認する代わりに、返送されてきた図１３のパケットの
フィールド「見積もり」の値を用いて、ステップ１に後
続のアークに付いているルールをすべて評価し、その評
価結果によりルーティングを決定する。

【０１３４】前述したように、ルールの評価は、ルール
評価部３４で行なわれる。まず、ステップ１からステッ
プ２へのアークに付いているルールが評価される。この
例の場合には、パケットのフィールド「見積もり」の値
が「１２０００」であるため、評価結果は「真」とな
る。したがって、ステップ２には、ルーティングが行な
われる。

【０１３５】次に、同様にして、ステップ１からステッ
プ３に向かうアークに付いているルールの評価が行なわ
れる。この例の場合には、パケットのフィールド「見積
もり」の値が「１２０００」であるため、評価結果は
「偽」となる。したがって、ステップ３には、ルーティ
ングが行なわれない。

【０１３６】以上のようにして、あらかじめアークに対
して定義されたルールを用いることにより、前のステッ
プの作業結果に応じて後のステップに対するルーティン
グをワークフローシステムが動的に決定することができ
る。この場合には、ルーティング情報フィールドを参照
する必要はない。

【０１３７】なお、以上の実施例では、ルールがアーク
に付いている場合に、パケットに含まれるルーティング
情報フィールドに対してルールを優先としてルーティン
グを行なったが、ステップの担当者がルーティング情報
フィールドの真理値を変更したときには、当該担当者に
より設定変更されたルーティング情報フィールドをルー
ルに優先するようにしてもよい。

【０１３８】［この発明の情報処理システムの第２の実
施例］上述した第１の実施例においては、ワークフロー
システムによるルーティングの指定方法はアークについ
て定義したルールを、ルーティング後処理において評価
してルーティングを決定するようにしたが、第２の実施
例においては、ステップの状態などについてルールを定
義して、そのルールの評価結果として得られるルーティ
ングに関する真理値を、システムがルーティング情報フ
ィールドに書き込むようにする。

【０１３９】この第２の実施例の場合には、ルーティン
グ後処理においては、ルールの評価を行なう必要がない
ので、ルーティング後処理のルーチンは、図１４のルー
チンＳ１００に示すように、図４のルーティング後処理
のルーチンＳ１０において、判断Ｓ１２と、処理Ｓ１３
とを省略し、判断Ｓ１１の判断結果が「ＮＯ」の場合に
は、判断Ｓ１４に進むようにしたものとすることがで
き、ルーティング後処理のソフトウエアを簡略化でき
る。

【０１４０】なお、第１の実施例においても、アークに
ついて記述されているルールを、ルーティング後処理の
前に必ず実行し、ルールの評価結果により、ルーティン
グ情報フィールドの真理値を書き換えるようにしておく
ことにより、ルーティング後処理のソフトウエアを簡略
化できる。

【０１４１】［第２の実施例が適用されたワークフロー
の具体例］第２の実施例が適用されたワークフローの具
体例として、以下、設計変更処理のフローの場合の例に
ついて説明する。

【０１４２】以下に説明するワークフローの実施例にお
いては、ステップの状態について定義されたルールによ
り、ルーティングを決定するための情報の生成を行な
い、後述する自動実行ステップによりルーティング情報
フィールドに、ルーティングを行なうか否かを決定する
ための真理値を記入するようにしている。

【０１４３】＜自動実行ステップ＞この第２の実施例に
おいては、ワークフロー中の作業の中には、人間よりも
機械の方が向いている作業も存在することにかんがみ、
特に担当ユーザを定めずに、自動的に作業の実行を行な
うステップを創設する。以下、このタイプのステップを
自動実行ステップと呼び、これと担当ユーザが実行する
タイプの通常のステップとを区別する必要があるとき
は、担当ユーザが実行するステップを通常ステップと呼
ぶことにする。

【０１４４】自動実行ステップの作業は、この例ではワ
ークフローシステム内で行なう作業として定義される。
ワークフローシステムは、自動実行ステップの状態が
「ｒｅａｄｙ」になった時には通知を出さず、即座に
「ｒｕｎ」の状態へと移行させる。そして、予め定義さ
れた作業をワークフローシステム内で自動的に実行し、
それが終了すると自動的に「ｃｏｍｐｌｅｔｅ」の状態
として、次ステップに対するルーティングを行なう。

【０１４５】なお、ワークフローシステム自身ではな
く、ワークフローシステムの管理下にあるハードウエア
に仕事をさせるようにしてもよい。

【０１４６】人間が担当しない作業であっても、ワーク
フローシステム内ではない、あるいは、ワークフローシ
ステムの管理下ではない他のシステムに作業の実行をさ
せるステップも考えられる。しかし、その場合には、当
該ステップの作業を実行するシステムを担当者として、
他のシステムを割り当てれば、通常ステップとして扱う
ことができる。すなわち、この場合、当該他のシステム
は、ワークフローシステムから通知を受けると、即座に
作業の開始の合図を送って作業を開始し、作業が終了す
ると終了の通知をワークフローシステムに送るように、
ソフトウエアにより処理する。このようにすることによ
り、人間以外の機械を担当者として、ワークフローシス
テム外のネットワーク上に設定することもできる。

【０１４７】＜サブフロー＞また、この第２の実施例で
は、複雑で、規模の大きいワークフローを、より柔軟
に、かつ、様々な局面に対応することができるようにす
るために、ワークフローを階層的に動作させることがで
きるようにしている。

【０１４８】すなわち、ワークフローを上位のメインフ
ローと、その下位のサブフローとから構成する。サブフ
ローは、メインフローの内の適宜の一つのステップに結
び付いたものであって、その結び付いたステップの作業
を細分化した複数のステップと、その複数のステップ間
の前後のつながりをアークで定義したものである。サブ
フローが一つのステップに結び付いているということ
は、その結び付かれているステップは、サブフローが終
了しないと終了できないことを意味している。

【０１４９】サブフローは、一つのステップに対して、
複数個、定義することもでき、その場合には、すべての
サブフローが終了しないと、それら複数のサブフローが
結びついているステップは終了できない。

【０１５０】この例の場合には、サブフローが結び付い
ているステップが「ｒｕｎ」の状態になったときに、そ
のステップの担当者が、自分の作業をより詳細化し、そ
の作業を実行するために相応しいと思われるサブフロー
を新たに定義して、起動する。サブフローの典型例をあ
らかじめ登録しておき、その中から起動するサブフロー
を、ステップの担当者が選ぶようにすることもできる。

【０１５１】サブフローの各ステップは、すべて通常ス
テップで構成することもできるし、サブフローのすべて
のステップを自動実行ステップで構成することもでき
る。また、サブフローの一部を自動実行ステップで構成
することも、もちろんできる。

【０１５２】また、サブフローをあらかじめ定義してお
き、このサブフローが結び付いているステップが「ｒｅ
ａｄｙ」の状態になったら、自動的にサブフローを起動
するようにすることもできる。その場合に、起動するサ
ブフローは複数個あってもよい。また、当該複数個のサ
ブフローのすべてを自動実行ステップで構成した場合に
は、一つのステップに対して自動で起動され、処理が自
動で実行される複数の作業を容易に定義することが可能
になる。

【０１５３】このように、ステップの担当者がサブフロ
ーを定義して起動し、そのサブフローが終了しない限
り、当該ステップが終了することができないようにする
ことにより、メインのワークフロー中には、当該サブフ
ローが結び付いているステップの代わりに、そのサブフ
ローの内容を詳細に定義する必要がなくなり、ワークフ
ローの管理が容易になる。

【０１５４】＜設計変更プロセスと、そのワークフロー
＞まず、この例の設計変更プロセスについて説明する。
典型的な設計変更のプロセスは、例えば以下の手順のよ
うに行なわれる。

【０１５５】１．設計変更の要求 ２．要求の受け付け ３．変更のレビュー ４．実施の可否 ５．設計変更 ６．承認 ７．配布。

【０１５６】まず始めに設計変更の要求が上がる。これ
は必ずしも設計部門で起こるとは限らない。設計変更の
詳細は文書化されて、設計部門の設計変更担当の窓口へ
と送られる。

【０１５７】設計部門の窓口で設計変更の要求を受け取
ると、その変更を実際に行なうかどうかを決定しなけれ
ばならない。窓口では変更を行なうかどうかを判断する
ためのレビュワーを決定し、各レビュワーに対して、該
当する図面と変更内容を伝え、実際に変更を行なうかど
うかを決定して欲しい旨の依頼をする。

【０１５８】各レビュワーは送られてきた図面と変更内
容を吟味し、実際に変更を行なうかどうかを決定し、集
計を行なう担当者に結果を報告する。集計を行なう担当
者は各レビュワーから送られてきた結果を元に、実際に
変更を行なうか行なわないかを決定する。通常は多数決
もしくは全員一致により、変更が決定される。

【０１５９】変更が行なわれないことが決定したら該当
図面と変更要求内容を設計部門に送付し、実際の設計変
更を依頼する。また、設計変更を行うことが決定したら
該当図面と変更要求内容を設計部門に送付し、実際の設
計変更を依頼する。

【０１６０】設計部門では、該当図面と設計変更要求を
受け取ると、設計変更を行なう担当者を決め、実際の設
計変更を行なう。

【０１６１】設計変更が終了すると、変更された図面と
要求内容とともに、変更された内容などを記述した書面
が添付され、設計部門長宛に送られる。設計部門長は送
られてきた図面を承認する。承認を受けた図面は関係各
部門に配布される。

【０１６２】以上のような設計変更プロセスを定義した
ワークフローの例を図１５を示す。各ステップの機能は
以下のように、ワークフローの定義者により定義されて
いる。

【０１６３】「開始」のステップはワークフローの開始
を表す。実際の業務と照らし合わせると、設計変更の要
求を上げることに当たる。なお、「開始」のステップ
は、自動実行ステップの一種である。

【０１６４】「要求受け付け」のステップは、設計変更
を設計部門の窓口の担当者（事務局）が受け取ることを
表す。ここで、受け付けられた設計変更の要求に対し、
窓口の担当者は該当する図面を添付し、各レビュワーに
配布する。

【０１６５】「レビュー（１）」、「レビュー
（２）」、「レビュー（３）」のステップは、それぞ
れ、設計部門において設計変更を行なうかどうかを判断
するためのレビューを行なうステップである。ここでは
各レビュワーは送られてきた図面と設計変更の要求を照
らし合わせ、実際に設計変更を行なうか、行なわないか
を、それぞれ決定する。

【０１６６】「受理？」のステップは、各レビュワーの
結論を集計し、実際に設計変更を行なうか行なわないか
の決定を下す。この例では、この「受理？」のステップ
は、自動実行ステップで、ワークフローシステムが自動
的に各レビュワーの結論を集計し、予め設定された規則
にそって、設計変更要求を受理するかどうかを決定す
る。設計変更要求が受理された場合は「設計変更」のス
テップへと進む。受理されなかった場合は「要求却下」
のステップへ進む。

【０１６７】「要求却下」のステップは、設計変更要求
が受理されなかった場合に事後処理を行なうステップで
ある。

【０１６８】「設計変更」のステップは、実際の設計変
更を行なうステップであり、設計部門の担当者に送られ
る。実際の設計変更は、別のワークフロー、すなわち、
サブフローを起動し、より詳細に作業を進めるようにし
ている。

【０１６９】「承認」のステップは、設計変更された図
面を承認するためのステップである。設計部門長が図面
をチェックし、承認印を図面にいれる。

【０１７０】「設計変更配布」のステップは、変更され
た図面を関係部門に配布するためのステップである。

【０１７１】上述したワークフローの定義は、ワークフ
ローシステムの編集機能により行われる。このワークフ
ローの定義時の作業は大きく分けて、 ステップの作成 ステップの接続 ルールの記述 の３つがある。各ステップの作成は各種属性、すなわ
ち、ステップが通常ステップか、自動実行ステップかを
表す「タイプ」、ステップの作業内容を示す「名前」、
「担当者」（この例では、担当部門）のほか、ルールの
設定も含む。この例における各ステップの初期属性値
（定義時の属性値）を、図１６から図２６までに示す。

【０１７２】各ステップを作成したら、流れにそって、
前後のステップを接続していく。このステップの作成、
接続の作業を繰り返すことによって、ワークフロー全体
を作成する。

【０１７３】必要に応じて、各ステップにはルールを記
述する。ルールは、前述したようにアークについて定義
することもできるし、また、ステップの各状態ごとに付
けることもできる。

【０１７４】この例では、「レビュー（１）」、「レビ
ュー（２）」、「レビュー（３）」のステップの状態
「ｒｕｎ」のルールで、パケットに「投票（＄ｖｏｔ
ｅ）」という名前のブール（ｂｏｏｌｅａｎ）型の変数
「投票結果」（後述する図４２参照）のフィールドを追
加する。この「レビュー（１）」、「レビュー
（２）」、「レビュー（３）」のステップの状態「ｒｕ
ｎ」のルールを図２７に示す。各ステップ「レビュー
（１）」、「レビュー（２）」、「レビュー（３）」の
担当者は、その変数「投票結果」のフィールドの欄を埋
める。

【０１７５】ワークフローシステムは、各ステップ「レ
ビュー（１）」、「レビュー（２）」、「レビュー
（３）」の状態「ｃｏｍｐｌｅｔｅ」のルールでこれの
集計を行なう。この「レビュー（１）」、「レビュー
（２）」、「レビュー（３）」のステップの状態「ｃｏ
ｍｐｌｅｔｅ」のルールを図２８に示す。ワークフロー
システムは、集計を行なった結果を元に、自動実行ステ
ップである次のステップ「受理？」でルーティングを決
定する。

【０１７６】ステップ「受理？」で実行される内容は、
図２０において、属性「スクリプト」に示されている。
図２０の例の場合の「スクリプト」の内容は、「投票数
が２以上のときには、ステップ「設計変更」にルーティ
ングを行い、ステップ「要求却下」にはルーティングを
行わなず、投票数が２以上でなければ、ステップ「設計
変更」にはルーティングを行わず、ステップ「要求却
下」にルーティングを行なう」というものである。

【０１７７】以上のようにしてワークフローの定義を終
了したらワークフローの開始を宣言する。ワークフロー
の開始とは具体的には、定義したワークフローのワーク
フローシステムへの登録、登録されたワークフローの開
始の２段階である。

【０１７８】図２９にワークフローの定義から起動まで
の起動者の処理の流れ図を示す。まず、始めに、あらか
じめ登録されている既存のワークフローを検索し（手順
Ｓ２１）、その中に、行おうとする業務に適応している
ワークフローがあるか否か判断する（手順Ｓ２２）。適
応しているワークフローがあれば、そのワークフローが
修正の必要があるか否か判断し（手順Ｓ２３）、修正の
必要があれば、その修正を行う（手順Ｓ２４）。そし
て、修正が終了した後、あるいは、修正の必要がなけれ
ばそのまま、ワークフローをワークフローシステムに登
録する（手順Ｓ２５）。

【０１７９】また、手順Ｓ２２で、あらかじめ登録され
ている既存のワークフローに、望みのワークフローがな
かったときには、新しいワークフローを定義し（手順Ｓ
２６）、このワークフローをワークフローシステムに登
録する（手順Ｓ２５）。

【０１８０】以上のようにしてワークフローシステムに
ワークフローが登録されると、ワークフローシステム
は、自動的にワークフローの開始の作業に移る。まず始
めに、必要な初期化を行ない、先頭のステップの作業を
開始する。

【０１８１】図３０は、初期化の際のワークフローシス
テムの処理ルーチンＳ３０の一例のフローチャートであ
る。すなわち、まず、定義されたワークフローのすべて
のステップの状態を、「ｎｏｔ ｒｅａｄｙ」に初期化
する（処理Ｓ３１）。次に、最初のステップを探し（処
理Ｓ３２）、その最初のステップの状態を「ｒｅａｄ
ｙ」にして、この処理ルーチンＳ３０を終了する。

【０１８２】こうして、ステップの状態が「ｎｏｔ ｒ
ｅａｄｙ」から「ｒｅａｄｙ」になるとき、ワークフロ
ーシステムは、状態「ｒｅａｄｙ」時の処理ルーチンＳ
４０を実行する。図３１に、この処理ルーチンＳ４０の
一例のフローチャートを示す。

【０１８３】まず、「ｒｅａｄｙ」の状態になったステ
ップについて、「ｒｅａｄｙ」においてのルールがあれ
ばそれを実行する（処理Ｓ４１）。ルールの実行が済ん
だら、当該ステップは自動実行ステップか否か判断し
（判断Ｓ４２）、自動実行ステップでなく、通常ステッ
プであれば、その担当者に対して、通知を送って（処理
Ｓ４３）、この処理ルーチン４０を終了する。

【０１８４】また、判断Ｓ４２での判断の結果、自動実
行ステップであると判断されたときには、処理Ｓ４４に
移って、通知をすることなくステップの状態を「ｒｕ
ｎ」にして、この処理ルーチン４０を終了する。

【０１８５】「ｒｅａｄｙ」になったステップが通常ス
テップの場合には、前記通知に対して担当者が作業の開
始を宣言するとステップは「ｒｕｎ」の状態となる。自
動実行ステップの場合には、前述のように、「ｒｅａｄ
ｙ」から即座に「ｒｕｎ」の状態になる。ステップの状
態が「ｒｕｎ」になると、ワークフローシステムは、状
態「ｒｕｎ」時の処理ルーチンＳ５０を実行する。図３
２は、この処理ルーチンＳ５０の一例のフローチャート
である。

【０１８６】まず、担当者に送るパケットを作成する
（処理Ｓ５１）。そして、当該ステップに「ｒｕｎ」状
態についてのルールがあれば、それを実行する（処理Ｓ
５２）。ルールの実行が済んだら、当該ステップは自動
実行ステップか否か判断し（判断Ｓ５３）、自動実行ス
テップでなく、通常ステップであれば、その担当者に対
して、パケットを送って（処理Ｓ５４）、この処理ルー
チン５０を終了する。

【０１８７】また、判断Ｓ５３での判断の結果、自動実
行ステップであると判断されたときには、処理Ｓ５５に
移って、パケットを送ることなくステップの状態を「ｃ
ｏｍｐｌｅｔｅ」にして、この処理ルーチン５０を終了
する。

【０１８８】ステップが通常ステップの場合には、担当
者が終了を宣言すると「ｃｏｍｐｌｅｔｅ」状態になる
が、サブフローが当該ステップで実行中は、担当者が終
了宣言をしても、ステップの状態は「ｃｏｍｐｌｅｔ
ｅ」にはならない。自動実行ステップの場合には、前述
のように、自動実行の作業が終了すると、ワークフロー
システム自身が「ｒｕｎ」から「ｃｏｍｐｌｅｔｅ」の
状態に移行させる。ステップの状態が「ｃｏｍｐｌｅｔ
ｅ」になるとき、ワークフローシステムは、状態「ｃｏ
ｍｐｌｅｔｅ」に関する処理ルーチンＳ６０を実行す
る。図３３は、この処理ルーチンＳ６０の一例のフロー
チャートである。

【０１８９】まず、サブフローが実行中か否か判断し
（処理Ｓ６１）、実行中であればこのルーチンＳ６０を
そのまま終了する。前述したように、サブフローが当該
ステップで起動されているときには、当該ステップに結
び付いているすべてのサブフローが終了しないと当該ス
テップは、終了できないからである。

【０１９０】サブフローがすべて終了しているときに
は、処理Ｓ６２に進んで、当該ステップの状態「ｃｏｍ
ｐｌｅｔｅ」についてルールが定義されていればそのル
ールを実行する。ルールの実行が済んだら、当該ステッ
プは自動実行ステップか否か判断し（判断Ｓ６３）、自
動実行ステップでなく、通常ステップであれば、前述し
たルーティング（ルーティング後処理およびルーティン
グ前処理）を行い（処理Ｓ６４）、この処理ルーチン６
０を終了する。

【０１９１】また、判断Ｓ６３での判断の結果、自動実
行ステップであると判断されたときには、処理Ｓ６５に
移って、定義されているスクリプトを実行した後、処理
Ｓ６４に移行してルーティングを行った後、この処理ル
ーチンＳ６０を終了する。以下、最後のステップの作業
が終了するまで、以上と同様に繰り返す。

【０１９２】次に、前述した設計変更のワークフローの
例を用いてさらに詳細に説明する。

【０１９３】＜ワークフローの開始＞まず始めに、ワー
クフローの定義者がワークフローシステムに対して、定
義したワークフローの登録を行なう。もしくはワークフ
ローは予め定義されており、定義者とは異なる者により
ワークフローが登録されることもある。

【０１９４】この例では、予め定義されていたワークフ
ローを用いて定義者とは異なる者がワークフローをワー
クフローシステムに登録したものとする。この登録した
者は、実際的には設計変更の依頼を行なう人である。こ
の設計変更の依頼者はワークフローの最初の担当者に対
して、メッセージを送ることができる。この機能は通常
の電子メールに類似の機能である。この例では、ワーク
フローの起動者は最初のステップの担当者（ここでは
「要求受け付け」の担当者、すなわち事務局）に対し
て、“部品Ｘの幅を１ｍｍ大きくして欲しいのです
が。”というメッセージを送ったものとする。

【０１９５】登録が行なわれると、ワークフローシステ
ムは初期化の作業を行なう。図１６〜図２６に示したよ
うに、定義されたばかりのステップは状態をもたない
が、この初期化により、全てのステップの状態は「ｎｏ
ｔ ｒｅａｄｙ」にされる（例えば図３４参照）。

【０１９６】ワークフローシステムの初期化が終了する
と、先頭のステップが開始される。この例の場合、先頭
のステップは「開始」である。「開始」のステップが開
始されるということはすなわち、「開始」のステップが
「ｒｅａｄｙ」状態になるということである（図３
５）。

【０１９７】ステップが「ｒｅａｄｙ」状態になると、
通常、ワークフローシステムはステップの担当者に通知
を送る。しかし、「開始」は特殊なステップ（自動実行
ステップの一種）であるために、通知は送られず、即座
に「ｒｕｎ」状態へと移行する。（図３６）。

【０１９８】自動実行ステップであれば、この「ｒｕ
ｎ」状態への移行により、定義時に指定された動作を行
うのであるが、「開始」は開始を合図するための特殊な
ステップであるために、この定義がない。したがって、
ここでは、何もせずに「ｃｏｍｐｌｅｔｅ」の状態へと
移行する（図３７）。

【０１９９】ステップ「開始」の状態が「ｃｏｍｐｌｅ
ｔｅ」になると、ワークフローシステムはルーティング
を開始する。この場合、後続のステップは「要求受け付
け」のみであるために、特別なことは行なわず、ステッ
プ「要求受け付け」に対して、ルーティングが行なわれ
る。

【０２００】ステップ「要求受け付け」が「ｒｅａｄ
ｙ」状態になると、このステップの担当者に対して通知
が送られる。担当者は、例えば電子メールを読むような
感覚で通知を受け取る。この通知の例を図３８に示す。

【０２０１】この通知を受け取った担当者が開始の合図
をワークフローシステムに対して送ると、ワークフロー
システムからそのステップの作業を行なうために必要な
情報などを織り込んだパケット（図３９参照）が送り返
される。このパケットには、後続の３つのステップ「レ
ビュー（１）」「レビュー（２）」「レビュー（３）」
へのルーティングを決定するためのルーティング情報が
付加されている。

【０２０２】担当者はパケットの中の情報を元に要求さ
れた作業を行なう。ステップ「要求受け付け」の作業は
要求内容を確認し、設計変更を依頼された部品の図面を
集め、設計部門のレビュー担当者に対して、レビューを
依頼することである。この作業に関する記述は予めワー
クフローを定義した定義者によって定義されており、前
記通知のなかの、図３８の例では「Ｄｅｓｃｒｉｐｔｉ
ｏｎ：」フィールドに、作業内容として織り込まれてい
る。通知には、この他に、ワークフローの起動者からの
メッセージが、図３８に示すように、「Ｃｏｍｍｅｎ
ｔ：」フィールドに含まれている。

【０２０３】「要求受け付け」の担当者は、「Ｄｅｓｃ
ｒｉｐｔｉｏｎ：」フィールドと、「Ｃｏｍｍｅｎ
ｔ：」フィールドのふたつの記述を元に、必要な図面を
集め、パケットに添付する。ここでは設計変更の要求は
部品Ｘについてなので、担当者は部品Ｘの図面を探し出
しパケットに加える。

【０２０４】次にレビューを担当する担当者を決める。
この例ではレビュー担当者は３人定義されている。通常
は全員の投票によってレビューが行なわれるため、ステ
ップ「要求受け付け」の担当者に送られるパケットに含
まれているルーティング情報の各レビュワーに対応する
真理値の値は、ワークフローシステムにより全て「真
（ｔｒｕｅ）」に初期化されている。

【０２０５】今、例えばステップ「要求受け付け」の担
当者が、特にレビュワーの変更の必要がないと判断した
場合には、ルーティング情報の真理値は変更しない。こ
のため、パケットのルーティング情報は、変更されず
に、システムに送り返される。また、このとき、担当者
は各レビュワーに送るコメントを記述し、パケットに含
める。この例の場合の作業終了結果のパケットは図４０
に示すようなものとなる。

【０２０６】ワークフローシステムは、このパケットを
受け取ると、ルーティング情報をチェックする。この例
では、ルーティング情報の中身は全て「真」であるた
め、全ての後続のステップに対してルーティングが行な
われる。

【０２０７】「レビュー（１）」が「ｒｅａｄｙ」状態
になると「レビュー（１）」の担当者に対して、通知が
送られる。この通知には「要求受け付け」の担当者が記
入したコメントが書かれている（図４１参照）。

【０２０８】「レビュー（１）」の担当者は、この通知
を読み、開始を宣言する。このとき、「レビュー
（１）」のステップには、図２７に例示したように、ル
ールが定義されているため、パケットを担当者に送信す
る前に、ワークフローシステムはそのルールを実行す
る。その結果、担当者に送られるパケットには、図４２
に示すように、投票用のフィールド「投票結果」が追加
される。

【０２０９】ルールの実行が終わると、ワークフローシ
ステムより図４２に示したパケットが送られる。このパ
ケットの中には「要求受け付け」の担当者が追加した図
面が含まれている。また、ステップ「レビュー（１）」
の後ろにはひとつしかステップがないため、ルーティン
グ情報は空になっている。すなわち、ステップ「レビュ
ー（１）」の担当者はルーティングを指示することはで
きない。

【０２１０】ステップ「レビュー（１）」の担当者は、
ステップ「要求受け付け」の担当者からのコメントに従
い、送られてきた図面と設計変更要求をチェックし、実
際に設計変更を行なうべきか行なわないべきかを決め、
パケットの投票用のフィールド「投票結果」に自分の判
断をｙｅｓ／ｎｏ形式で記入する。例えば、ステップ
「レビュー（１）」の担当者が「ｙｅｓ」と投票し、所
定のコメントを記述したとすると、パケットは、図４３
に示すようなものとなる。

【０２１１】こうして作業が終了したステップ「レビュ
ー（１）」の担当者は、自分の意見を含めたパケット
（図４３）とともに、作業の完了をワークフローシステ
ムに通知する。この時、ステップ「レビュー（２）」と
ステップ「レビュー（３）」が、まだ終了していない場
合には、ワークフローシステムは、ルーティング後処理
において、次のステップ「受理？」について、スタート
フラグを立てるだけで処理を終了する。

【０２１２】また、このとき、ステップ「レビュー
（１）」には、図２８に例示したように、「ｃｏｍｐｌ
ｅｔｅ」時のルールも定義されているため、これが実行
される。実行された結果、「投票結果」のフィールドが
「ｙｅｓ」であるため、「＄ｖｏｔｅ」という変数がイ
ンクリメントされる。この結果「＄ｖｏｔｅ」という変
数の値は１となる。

【０２１３】ステップ「レビュー（２）」の動作は、ス
テップ「レビュー（１）」と同様である。ただし、この
例では、ステップ「レビュー（２）」の担当者は設計変
更に非同意で、投票用のフィールド「投票結果」に「ｎ
ｏ」と記入し、コメントを付加したとする。このステッ
プ「レビュー（２）」の終了時のパケットの例を図４４
に示す。

【０２１４】作業が終了したステップ「レビュー
（２）」の担当者は、自分の意見を含めたパケット（図
４４）とともに、作業の完了をワークフローシステムに
通知する。ここで、未だ、ステップ「レビュー（３）」
が終了していないとすると、ワークフローシステムは、
図１４に示したルーティング後処理の処理ルーチンＳ１
００において、「受理？」ステップのスタートフラグを
立てる（実際にはすでに立っているが）だけで処理を終
了する。

【０２１５】また、ステップ「レビュー（２）」の「ｃ
ｏｍｐｌｅｔｅ」時のルールが実行されるが、「投票結
果」のフィールドが「ｎｏ」であるため、変数「＄ｖｏ
ｔｅ」はインクリメントされず、その値は１のままであ
る。

【０２１６】ステップ「レビュー（３）」の動作も、ス
テップ「レビュー（１）」と同様である。ただし、この
例では、ステップ「レビュー（３）」では担当者は設計
変更に同意で、投票用のフィールド「投票結果」に「ｙ
ｅｓ」を記入し、コメントを付加したものとする。

【０２１７】作業が終了すると、ステップ「レビュー
（３）」の担当者は、自分の意見を含めたパケットとと
もに、作業の完了をワークフローシステムに通知する。
ここで、全てのレビューが終了したため、「受理？」ス
テップは作業を開始することが可能となる。すなわち、
ワークフローシステムは、ルーティング後処理におい
て、「受理？」ステップはスタートフラグが立っている
ため、状態「ｉｓｏｌａｔｅ」とはせずに、「ｒｅａｄ
ｙ」状態とする。

【０２１８】また、ステップ「レビュー（３）」の「ｃ
ｏｍｐｌｅｔｅ」時のルールが実行される。ここでは、
「投票結果」のフィールド値が「ｙｅｓ」であったた
め、変数「＄ｖｏｔｅ」はインクリメントされ、値は２
となる。

【０２１９】ステップ「受理？」は、この例では、自動
実行ステップである。この例では、図２０に例示したよ
うに、上流の３つのステップ「レビュー（１）」「レビ
ュー（２）」「レビュー（３）」の投票結果を集計し、
その結果によってルーティングを変更するためのスクリ
プトが予め定義してある。

【０２２０】前述したように、ここで定義されているス
クリプトは、上流の各レビュワーから返された投票結果
を集計し、多数決を行なうもので、設計変更を行なうこ
とに対し、「ｙｅｓ」が勝った場合は、ステップ「要求
却下」にはルーティングを行なわずに、ステップ「設計
変更」にルーティングを行ない、逆に「ｎｏ」が勝った
場合は、ステップ「要求却下」にルーティングを行な
い、ステップ「設計変更」にルーティングを行なわない
という内容である。

【０２２１】具体的には、各レビュワーのステップの状
態「ｃｏｍｐｌｅｔｅ」時に実行されたルールにより設
定された変数「＄ｖｏｔｅ」の値を参照し、２以上であ
ればステップ「設計変更」に対するルーティング情報フ
ィールドの真理値を「真」とし、ステップ「要求却下」
に対するルーティング情報フィールドの真理値を「偽」
とする。逆に、変数「＄ｖｏｔｅ」の値が２未満の場合
は、ステップ「設計変更」に対するルーティング情報フ
ィールドの真理値を「偽」とし、ステップ「要求却下」
に対するルーティング情報フィールドの真理値を「真」
とする。

【０２２２】この例の場合は、変数「＄ｖｏｔｅ」の値
は２であるために、ステップ「設計変更」に対するルー
ティング情報フィールドの真理値が「真」とされ、ステ
ップ「要求却下」の真理値は「偽」とされる。

【０２２３】スクリプトの実行が終了すると、ステップ
「受理？」は、終了し、「ｃｏｍｐｌｅｔｅ」の状態に
なる。すると、図１４に示したルーティング後処理のル
ーチンＳ１００が実行され、ルーティング情報フィール
ドの真理値が参照されることにより、ステップ「受理
？」のスクリプト通りのルーティング結果が得られる。
すなわち、この例の場合には、ステップ「設計変更」は
「ｒｅａｄｙ」状態となり、ステップ「要求却下」は
「ｉｓｏｌａｔｅ」状態となる。

【０２２４】この例の場合、ステップ「設計変更」の担
当者は自分の作業をより詳細化し、サブフローを起動す
る。すなわち、設計変更の担当者は要求されている設計
変更を行なうためにもっともふさわしいと思われるワー
クフローを選び、または、新たに定義し、それを現在動
いているワークフローのサブフローとして起動する。こ
のサブフローが終了しない限り、「設計変更」ステップ
は終了することができない。

【０２２５】このサブフローの例を図４５に示す。この
例のサブフローは、すべて通常ステップからなり、最初
のステップは、設計変更のための「仕様作成」のステッ
プであり、担当者は、設計リーダーである。次のステッ
プは、実際に設計図を作成する「設計」のステップであ
り、担当者は設計者である。次のステップは、最後のス
テップであり、設計者の作成した設計図の検査する「検
図」のステップである。

【０２２６】このサブフローも、上述したワークフロー
と、まったく同様にして作業が行われてゆく。このサブ
フローの管理も、同じワークフローシステムで行っても
よいが、別のワークフローシステムにより、サブフロー
の実行管理を行わせるようにすることも、もちろんでき
る。サブフローの最後のステップが終了して、その最後
のステップの担当者から作業終了の合図があったとき
に、これが結び付いているステップ「設計変更」を、担
当者が終了として、ワークフローシステムにその通知を
することができる。なお、サブフローが複数個、ステッ
プについて定義された場合には、すべてのサブフローが
終了するまで、当該サブフローが結び付いているステッ
プは作業を終了とすることができない。

【０２２７】この例の場合には、ステップ「設計変更」
の担当者は、自分が起動したサブフローが終了すると、
サブフローにおいて実際に変更された図面をパケットに
戻し、作業を終了する。

【０２２８】ステップ「設計変更」の次のステップ「承
認」では、変更された図面の承認を行なう。具体的には
変更された図面に承認印を押す。

【０２２９】次のステップ「設計変更配布」では、この
実施例においては、「設計変更」と同様サブフローを起
動する。こうすることにより、どのような配布形態をと
るか柔軟に決定することができる。

【０２３０】図４６に、この例のステップ「設計変更配
布」について定義されたサブフローの例を示す。この例
のサブフローは、３つの自動実行ステップが、並行に実
行されるワークフローである。自動実行ステップ「出
図」は、例えばプリンタにより設計変更図面を印刷させ
て図面を出力させるものであり、自動実行ステップ「保
管」は、設計変更図面をファイルに格納しておくもので
あり、自動実行ステップ「ＦＡＸ」は、ファクシミリ装
置によって、設計変更図面を所定の宛先に配送するもの
である。

【０２３１】このように、あるステップで起動されるサ
ブフローのすべてを、自動実行ステップで構成すること
によって、定型業務を大幅に改善することができる。

【０２３２】この例のワークフローシステムは、これら
の作業のためのハードウエアとしてのプリンタ、ファイ
リング装置、ファクシミリ装置を内蔵している。もっと
も、ＬＡＮなどのネットワークを通じて、それぞれのハ
ードウエアに対してワークフローシステムより処理要求
を出して、処理を行わせるようにすることも勿論でき
る。

【０２３３】この場合、ステップ「設計変更配布」が
「ｒｅａｄｙ」状態になると、即座に「ｒｕｎ」状態と
なり、図４６のサブフローが起動されると、自動的に３
つの自動実行ステップ「出図」「保管」「ＦＡＸ」が開
始して、それぞれの作業を自動的に行う。

【０２３４】そして、すべての自動実行ステップの作業
の終了を待って、ステップ「設計変更配布」の担当者
「事務局」が終了の通知を出すと、このステップ「設計
変更配布」の状態は「ｃｏｍｐｌｅｔｅ」になる。一
方、ステップ「要求却下」は、前述したように、「ｉｓ
ｏｌａｔｅ」になっているので、以上で、設計変更のワ
ークフローは、終了する。

【０２３５】なお、「受理？」のステップで、ステップ
「設計変更」にはルーティングは行なわないと決定され
たときには、ステップ「設計変更」の状態は、「ｉｓｏ
ｌａｔｅ」の状態になり、かつ、図１４のルーティング
後処理のルーチンＳ１００の処理Ｓ２１として説明され
ているように、その後続のステップ「承認」、ステップ
「設計変更配布」について、再帰的に「ｉｓｏｌａｔ
ｅ」の状態に移行させる処理を行なう。

【０２３６】したがって、ステップ「要求却下」の作業
が終了して状態「ｃｏｍｐｌｅｔｅ」になったとき、ス
テップ「設計変更配布」の状態は、「ｉｓｏｌａｔｅ」
になっているので、設計変更のワークフローは終了す
る。

【０２３７】上述のように、この例の設計変更のワーク
フローにおいては、ステップ「要求受け付け」の担当者
は、パケットに付加されているルーティング情報のフィ
ールドの真理値を変更することができ、その変更によ
り、その後続のステップ「レビュー（１）」「レビュー
（２）」「レビュー（３）」のそれぞれに対してルーテ
ィングを行うか否かを決定することが可能である。ただ
し、上述の例では、ステップ「レビュー（１）」「レビ
ュー（２）」「レビュー（３）」のすべてにルーティン
グを行うと担当者が決定したので、担当者によるルーテ
ィング情報の変更は行われず、デフォルトの真理値
「真」はそのままとされた。

【０２３８】また、この例の設計変更のワークフローに
おいては、ステップ「受理？」を自動実行ステップで構
成し、その作業内容をあらかじめ定義したスクリプトに
より、ステップ「レビュー（１）」「レビュー（２）」
「レビュー（３）」の担当者が、その状態「ｒｕｎ」の
ルールで追加された投票用のフィールド「投票結果」に
記入した投票結果を集計し、その結果によって下流のス
テップのルーティングを決定することができる。すなわ
ち、前ステップの担当者が行った作業内容に基づいて演
算を行うなどの比較的複雑なルーティングの決定が可能
になる。

【０２３９】また、「設計変更」のステップでは、担当
者が自分の作業をより詳細化し、サブフローを起動して
作業を実行するようにしたので、親のワークフロー中に
は、設計変更のプロセスを詳細に記述する必要がない。
そして、担当者が起動するサブフローを定義することが
できるので、ワークフローの作業の流れを柔軟に設計す
ることができる。

【０２４０】さらに、上述の例のステップ「設計変更配
布」のように、ステップをすべて自動実行ステップから
なるサブフローで構成することにより、定型業務の作業
負荷を大幅に改善することができる。

【０２４１】また、前述もしたように、ルールは、各作
業工程の状態や、自動実行ステップの処理内容（スクリ
プト）として定義されていて、各ステップの状態におい
て実行されるので、第１の実施例の場合のように、ルー
ティング後処理においてルールを実行する必要がない。
そして、図１４に示したようなルーティング後処理の実
行により、担当者によるルーティングの決定と、ワーク
フローシステムによるルーティングの決定とを、行うこ
とができる。

【０２４２】なお、サブフローが結び付く親ワークフロ
ーのステップを自動実行ステップで構成し、その自動実
行ステップで行う作業をソフトウエアで実行させると共
に、そのソフトウエアによってサブフローを定義して、
自動的にサブフローを起動させるようにすれば、親ワー
クフローの前記自動実行ステップにルーティングが行わ
れたとき、サブフローが自動的に起動されてその作業が
開始され、担当者がサブフローを起動する必要がない。

【０２４３】なお、以上の例では、自動実行ステップで
ルーティング情報フィールドの真理値を書き換えて、後
続のステップのルーティングを決定するようにしたが、
ステップの状態が「ｒｅａｄｙ」「ｒｕｎ」「ｃｏｍｐ
ｌｅｔｅ」になったときに実行されるルールによりパケ
ットのルーティング情報フィールドの書き換えを行なう
ようにすることもできる。

【０２４４】

【発明の効果】以上説明したように、第１の発明によれ
ば、各作業工程に対して与える作業に必要な情報の固ま
りの中に、その作業工程の後続の作業工程に作業を開始
させるか否かを決定するための情報フィールドを追加
し、この追加された情報フィールドの内容を用いて後続
の作業工程に作業を開始させるか否かを決定するように
したので、作業の分岐があったときに、分岐後のいずれ
の作業工程に仕事を開始させるかを容易に決定すること
ができる。

【０２４５】また、前記の後続の作業工程に作業を開始
させるか否かを決定するために追加された情報フィール
ドには、作業工程の担当者が記入することができるの
で、後続の作業工程に仕事を開始させるか否かの決定
に、作業担当者の要求を反映することができ、仕事の流
れを作業担当者の要求に応じて柔軟に変更することがで
きる。

【０２４６】また、第２の発明によれば、作業工程につ
いて定義されたルールが実行されて、その結果により、
前記情報フィールドに後続の作業工程に作業を実行させ
るか否かの情報が記述され、その情報フィールドの記述
に従ってルーティングが決定されるので、情報処理シス
テム自身が作業工程の作業結果を反映したルーティング
の決定をすることができる。しかも、ルーティングのた
めの情報フィールドの内容を参照するのは、担当者によ
る場合も同じであり、ルーティングの決定のためのソフ
トウエアを簡略化することができる。

【０２４７】また、第３の発明によれば、あらかじめ定
義された約束事などにより前の作業工程の処理結果の評
価を行って、後続の作業工程に仕事を開始させるか否か
を決定することが可能となり、作業工程における作業結
果を、作業の流れ管理に反映させることができる。例え
ば作業工程で計算された見積もりに応じて後続の作業の
流れを変更したりすることができる。この場合には、ル
ーティングのための特別の情報フィールドを参照する必
要がない。

【０２４８】また、第４の発明によれば、分岐の作業工
程があるときに、仕事が開始されなかった作業工程は、
作業の流れから切り離されたことを示す切り離し状態と
して、その作業工程の終了状態を管理するようにしたの
で、分岐後の合流が支障なく行える。

【０２４９】また、第５の発明によれば、担当者を定め
ずに機械に作業を実行させる自動実行作業工程を定義
し、この自動実行作業工程も、他の通常の担当者が定め
られる作業工程と同様に状態管理するようにしたので、
この自動実行作業工程をワークフローの中に適宜挿入す
ることができ、作業の効率化を計ることができる。

【０２５０】さらに、第６の発明によれば、各作業工程
の担当者は、当該作業工程においてサブフローを定義し
て起動することができるので、作業の流れの定義時に各
作業工程を詳細に定義する必要はない。また、サブフロ
ーを用いることにより、すべての作業工程を詳細に定義
する場合に比べて、より柔軟に様々な局面に対して対応
することが可能になる。

【図面の簡単な説明】

【図１】この発明による情報処理システムの一実施例の
要部の機能ブロック図である。

【図２】この発明による情報処理システムの一実施例の
概要を示すブロック図である。

【図３】この発明による情報処理システムの一実施例の
要部の処理動作の例のフローチャートである。

【図４】この発明による情報処理システムの第１の実施
例の要部の処理動作の例のフローチャートである。

【図５】この発明による情報処理システムの第１の実施
例が適用される作業の流れの例を示す図である。

【図６】図５の実施例の作業の流れを構成する各ステッ
プに関するデータの例を示す図である。

【図７】図５の実施例の作業の流れを構成する各ステッ
プのつながりを表すデータの例を示す図である。

【図８】図５の実施例のステップ１の担当者に送られる
データの固まりの例を示す図である。

【図９】図５の実施例のステップ１の担当者からの作業
結果のデータの固まりの例を示す図である。

【図１０】図５の実施例のステップ１からステップ２へ
のつながりについて定義されたルールの例を示す図であ
る。

【図１１】図５の実施例のステップ１からステップ３へ
のつながりについて定義されたルールの例を示す図であ
る。

【図１２】図５の実施例のステップ１の担当者に送られ
るデータの固まりの他の例を示す図である。

【図１３】図５の実施例のステップ１の担当者からの作
業結果のデータの固まりの他の例を示す図である。

【図１４】この発明による情報処理システムの第２の実
施例の要部の処理動作の例のフローチャートである。

【図１５】この発明による情報処理システムの第２の実
施例が適用される作業の流れの例を示す図である。

【図１６】図１５の実施例のステップ「開始」の定義時
の属性値の例を示す図である。

【図１７】図１５の実施例のステップ「要求受け付け」
の定義時の属性値の例を示す図である。

【図１８】図１５の実施例のステップ「レビュー
（１）」の定義時の属性値の例を示す図である。

【図１９】図１５の実施例のステップ「レビュー
（２）」の定義時の属性値の例を示す図である。

【図２０】図１５の実施例のステップ「レビュー
（３）」の定義時の属性値の例を示す図である。

【図２１】図１５の実施例のステップ「受理？」の定義
時の属性値の例を示す図である。

【図２２】図１５の実施例のステップ「設計変更」の定
義時の属性値の例を示す図である。

【図２３】図１５の実施例のステップ「承認」の定義時
の属性値の例を示す図である。

【図２４】図１５の実施例のステップ「設計変更配布」
の定義時の属性値の例を示す図である。

【図２５】図１５の実施例のステップ「要求却下」の定
義時の属性値の例を示す図である。

【図２６】図１５の実施例のステップ「終了」の定義時
の属性値の例を示す図である。

【図２７】図１５の実施例のステップ「レビュー
（１）」の状態「ｒｕｎ」のときのルールの例を示す図
である。

【図２８】図１５の実施例のステップ「レビュー
（１）」の状態「ｃｏｍｐｌｅｔｅ」のときのルールの
例を示す図である。

【図２９】この発明による情報処理システムにおけるワ
ークフローの定義時の処理の流れの例を示すフローチャ
ートである。

【図３０】この発明による情報処理システムにおけるワ
ークフローの初期化処理の流れの例を示すフローチャー
トである。

【図３１】この発明による情報処理システムにおいて、
ステップの状態が「ｒｅａｄｙ」になったときの処理の
流れの例を示すフローチャートである。

【図３２】この発明による情報処理システムにおいて、
ステップの状態が「ｒｕｎ」になったときの処理の流れ
の例を示すフローチャートである。

【図３３】この発明による情報処理システムにおいて、
ステップの状態が「ｃｏｍｐｌｅｔｅ」になったときの
処理の流れの例を示すフローチャートである。

【図３４】図１５の実施例のステップ「開始」の登録時
の属性値の例を示す図である。

【図３５】図１５の実施例のステップ「開始」の開始時
の属性値の例を示す図である。

【図３６】図１５の実施例のステップ「開始」の状態
「ｒｕｎ」時の属性値の例を示す図である。

【図３７】図１５の実施例のステップ「開始」の状態
「ｃｏｍｐｌｅｔｅ」時の属性値の例を示す図である。

【図３８】図１５の実施例のステップ「要求受け付け」
の担当者に対する通知の例を示す図である。

【図３９】図１５の実施例のステップ「要求受け付け」
の開始の際に、担当者に対して与えられる情報の固まり
の例を示す図である。

【図４０】図１５の実施例のステップ「要求受け付け」
の担当者から、その終了時に送られてくる情報の固まり
の例を示す図である。

【図４１】図１５の実施例のステップ「レビュー
（１）」の担当者に対する通知の例を示す図である。

【図４２】図１５の実施例のステップ「レビュー
（１）」の開始の際に、担当者に対して与えられる情報
の固まりの例を示す図である。

【図４３】図１５の実施例のステップ「レビュー
（１）」の担当者から、その終了時に送られてくる情報
の固まりの例を示す図である。

【図４４】図１５の実施例のステップ「レビュー
（２）」の担当者から、その終了時に送られてくる情報
の固まりの例を示す図である。

【図４５】図１５の実施例のステップ「設計変更」にお
いて起動されるサブフローの例を示す図である。

【図４６】図１５の実施例のステップ「設計変更配布」
において起動されるサブフローの例を示す図である。

【図４７】ワークフローの一例を示す図である。

【図４８】ワークフローの他の例を示す図である。

【符号の説明】

１０ ユーザインターフェース部 １１ テンプレート管理部 １２ ルーティング管理部 １３ 通知管理部 １４ 進捗情報管理部 １５ ユーザ管理部 １７ 参照情報管理部 ２０ システム部 ２１ 編集部 ２２ 通知部 ３１ ステップ状態管理部 ３１Ｍ ステップ状態メモリ ３２ ルーティング前処理部 ３３ ルーティング後処理部 ３４ ルール評価部

Claims (6)

【特許請求の範囲】
1. 【請求項１】順序だって処理すべき作業を、複数個の作
   業工程に分け、その複数個の作業工程の順序と、各作業
   工程の処理内容を定めて、前記作業を支援する情報処理
   システムであって、前記各作業工程に対して、必要な情
   報の固まりを与えると共に、当該作業工程からその作業
   工程の処理結果が前記情報の固まりに含められたものを
   得るようにする情報処理システムにおいて、 前記作業工程との間でやり取りする前記情報の固まりの
   中に、当該作業工程の後続の作業工程に作業を行なわせ
   るか否かを決定するための情報フィールドを追加する追
   加手段と、 前記作業工程からの前記情報の固まり中の、前記追加さ
   れた情報フィールドの内容に基づいて、後続の作業工程
   に仕事を行なわれるか否かを決定するルーティング手段
   とを設けたことを特徴とする情報処理システム。
2. 【請求項２】順序だって処理すべき作業を、複数個の作
   業工程に分け、その複数個の作業工程の順序と、各作業
   工程の処理内容を定めて、前記作業を支援する情報処理
   システムであって、前記各作業工程に対して、必要な情
   報の固まりを与えると共に、当該作業工程からその作業
   工程の処理結果が前記情報の固まりに含められたものを
   得るようにする情報処理システムにおいて、 前記作業工程に対して与える必要な情報の固まりの中
   に、当該作業工程に直接的につながる複数個の後続の作
   業工程のそれぞれに対して、その作業を行なわせるか否
   かを決定するための情報フィールドを追加する追加手段
   と、 前記作業工程について定義された約束事を実行すること
   により、前記追加された情報フィールドに、当該作業工
   程に直接的につながる複数個の後続の作業工程のそれぞ
   れについて、その作業を行なわせるか否かの情報を記述
   するルール評価手段と、 前記作業工程からの前記情報の固まり中の、前記追加さ
   れた情報フィールドの内容に基づいて、前記後続の作業
   工程のそれぞれに対して仕事を行なわせるか否かを決定
   するルーティング手段とを設けたことを特徴とする情報
   処理システム。
3. 【請求項３】順序だって処理すべき作業を、複数個の作
   業工程に分け、その複数個の作業工程の順序と、各作業
   工程の処理内容を定めて、前記作業を支援する情報処理
   システムであって、前記各作業工程に対して、必要な情
   報の固まりを与えると共に、当該作業工程からその作業
   工程の処理結果が前記情報の固まりに含められたものを
   得るようにする情報処理システムにおいて、 前記作業工程の作業の終了時に、当該作業工程からの前
   記情報の固まりに含まれる情報を用いて、当該作業工程
   に直接的につながる複数個の後続の作業工程のそれぞれ
   への移行に関してあらかじめ定義された約束事を実行す
   るルール評価手段と、 このルール評価手段の評価結果により、前記後続の作業
   工程のそれぞれに対して仕事を行なわせるか否かを決定
   するようにするルーティング手段とを設けたことを特徴
   とする情報処理システム。
4. 【請求項４】順序だって処理すべき作業を、複数個の作
   業工程に分け、その複数個の作業工程の順序と、各作業
   工程の処理内容を定めて、前記作業を支援する情報処理
   システムであって、 各作業工程の終了状態を、作業終了となったことを示す
   作業終了状態と、作業が開始されずに前記連携する複数
   の作業工程からなる流れから切り離されたことを示す切
   り離し状態とで管理する作業工程の状態管理手段と、 前記作業工程の前の作業工程の状態のすべてが、前記作
   業終了状態あるいは前記切り離し状態になったときに、
   当該作業工程に作業を開始させるための処理を行なうル
   ーティング手段とを備える情報処理システム。
5. 【請求項５】順序だって処理すべき作業を、複数個の作
   業工程に分け、その複数個の作業工程の順序と、各作業
   工程の処理内容を定めて、前記作業を支援する情報処理
   システムであって、 各作業工程の状態を、作業の開始準備ができている状態
   を表す待機状態と、作業を実行している状態を表す実行
   状態と、作業を終了した状態を表す終了状態とで管理す
   る作業工程の状態管理手段と、 前記作業工程が、担当ユーザにより作業が実行される通
   常作業工程か、前記情報処理システムの管理下において
   担当者なしで作業が実行される自動実行作業工程かを判
   別する判別手段と、 この判別手段での判別の結果、前記通常作業工程である
   と判別されたときには、前記作業工程の状態管理手段で
   の状態データが前記待機状態になった作業工程の担当者
   に通知をした後、当該作業工程の状態を実行状態にし、
   前記担当ユーザからの作業終了の通知を受けて当該作業
   工程の状態を終了状態にし、前記判別手段での判別の結
   果、前記自動実行作業工程であると判別されたときに
   は、当該自動実行作業工程の状態が前記待機状態になっ
   たときに、前記実行状態に移行させ、作業が終了したと
   きには、前記自動実行作業工程の状態を終了状態に移行
   させる作業工程管理手段とを備える情報処理システム。
6. 【請求項６】順序だって処理すべき作業を、複数個の作
   業工程に分け、その複数個の作業工程の順序と、各作業
   工程の処理内容を定めて定義し、各作業工程の作業が終
   了すると、次の作業工程の作業を開始するように管理す
   ることにより、前記作業を支援する情報処理システムの
   作業の流れ管理方法において、 前記定義された作業の流れの内の適宜の作業工程におい
   て、その作業工程の作業を細分化した作業の単位と、そ
   の細分化した作業の単位の前後のつながりとで定義した
   サブフローを起動し、このサブフローによる作業が完了
   したときに、前記サブフローを起動をした作業工程は、
   終了できるようにした情報処理システムの作業の流れ管
   理方法。