JP2003203148A - 情報処理システム - Google Patents

Abstract

(57)【要約】 【課題】 ワークフローの作業の流れを階層的に定義お
よび動作させることができ、柔軟な運用を行なえる情報
処理システムを提供する。 【解決手段】 順序だって処理すべき作業を、複数個の
作業工程に分け、その複数個の作業工程の順序と、各作
業工程の処理内容とを定めて定義し、各作業工程の作業
が終了して終了状態になったときに、次の作業工程の作
業を開始するように管理することにより、作業を支援す
る情報処理システムである。定義された作業の流れの内
の所定の作業工程において、当該作業工程の作業を細分
化した作業の単位と、その細分化した作業の単位の前後
のつながりとからなるサブフローを定義する。起動手段
は、情報処理システムからの所定の作業工程の開始指示
に基づきサブフローを起動する。サブフローによる作業
が完了したときに、所定の作業工程を終了状態として、
情報処理システムに通知する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、情報を媒介にし
て連携する複数の作業工程からなる作業について、複数
の作業工程の順序と、各作業工程の処理内容を定め、各
作業工程の間での情報の受け渡しなど、作業の処理を支
援する情報処理システムに関する。

【０００２】

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

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

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

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

【０００６】このワークフローシステムの概要は、後述
の非特許文献１に記載されている。

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

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

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

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

【００１１】

【非特許文献１】日経ＢＰ社発行の雑誌「日経情報スト
ラテジー」、１９９３年８月号、マイケル・Ｄ・カー
ン、安田誠寄稿、「ワークフロー管理技術とその可能
性」Ｐ１２３〜Ｐ１３０。

【００１２】

【発明が解決しようとする課題】ところで、図４７にお
いて四角で囲まれた各ノードを構成する作業工程に対し
ては、通常は、一つの単位作業が割り当てられる。この
ため、複雑で規模の大きい業務処理についてワークフロ
ーを定義するときには、ワークフローが非常に複雑にな
ってしまう。

【００１３】例えば業務内容が階層的な構造を有してい
て、下位の業務が終了しないときには、上位の業務が開
始できないような場合であっても、下位の業務および上
位の業務を、それぞれ単位作業からなるノードを構成す
る作業工程に分け、それらの作業工程について、ワーク
フローを定義するようにする場合には、階層関係の考慮
をしつつ、ワークフローを定義しなければならず、厄介
であるとともに、ワークフローの運用が詳細に定義され
たものに限定されて、柔軟性にかけてしまうという問題
がある。

【００１４】この発明は、上記の点にかんがみ、ワーク
フローの作業の流れを階層的に定義および動作させるこ
とができ、柔軟な運用を行なえる情報処理システムを提
供することを目的とする。

【００１５】

【課題を解決するための手段】上記課題を解決するた
め、この発明は、順序だって処理すべき作業を、複数個
の作業工程に分け、その複数個の作業工程の順序と、各
作業工程の処理内容とを定めて定義し、各作業工程の作
業が終了して終了状態になったときに、次の作業工程の
作業を開始するように管理することにより、前記作業を
支援する情報処理システムにおいて、前記定義された作
業の流れの内の所定の作業工程において、当該作業工程
の作業を細分化した作業の単位と、その細分化した作業
の単位の前後のつながりとからなるサブフローが定義さ
れている場合に、前記情報処理システムからの前記所定
の作業工程の開始指示に基づき前記サブフローを起動す
る起動手段と、前記起動手段により起動されたサブフロ
ーによる作業が完了したときに、前記所定の作業工程を
終了状態として、前記情報処理システムに通知する手段
と、を備えることを特徴とする。

【００１６】

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

【００１７】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００９５】前述したように、ステップ１の状態が「ｒ
ｅａｄｙ」になった後、担当者から作業開始の合図が来
ると、上述の図８のような内容の最初のパケットが、ス
テップ１の担当者に送られる。

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

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

【００９８】ステップ１の作業が終了したときのパケッ
トの例を図９に示す。この図９のパケットでは、ステッ
プ１の担当者によって、ステップ３にルーティングを行
なわないように指示されている。

【００９９】なお、パケットの情報フィールドの欄の
内、「担当者」や「Ｄａｔｅ」などのワークフローシス
テムが用いる欄は、担当者が勝手に変えることはできな
いように構成されている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０２２６】

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

【図面の簡単な説明】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【符号の説明】

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

Claims (3)

【特許請求の範囲】
1. 【請求項１】順序だって処理すべき作業を、複数個の作
   業工程に分け、その複数個の作業工程の順序と、各作業
   工程の処理内容とを定めて定義し、各作業工程の作業が
   終了して終了状態になったときに、次の作業工程の作業
   を開始するように管理することにより、前記作業を支援
   する情報処理システムにおいて、 前記定義された作業の流れの内の所定の作業工程におい
   て、当該作業工程の作業を細分化した作業の単位と、そ
   の細分化した作業の単位の前後のつながりとからなるサ
   ブフローが定義されている場合に、前記情報処理システ
   ムからの前記所定の作業工程の開始指示に基づき前記サ
   ブフローを起動する起動手段と、 前記起動手段により起動されたサブフローによる作業が
   完了したときに、前記所定の作業工程を終了状態とし
   て、前記情報処理システムに通知する手段と、を備える
   ことを特徴とする情報処理システム。
2. 【請求項２】請求項１に記載の情報処理システムにおい
   て、 前記所定の作業工程に対して定義されている前記サブフ
   ローが複数個である場合には、当該複数のサブフローに
   よる作業が全て完了したときに、前記所定の作業工程を
   終了状態として、前記情報処理システムに通知すること
   を特徴とする情報処理システム。
3. 【請求項３】請求項１または請求項２に記載の情報処理
   システムにおいて、 前記サブフローは、機械が作業を実行する自動実行ステ
   ップのみで構成されていることを特徴とする情報処理シ
   ステム。