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

Description

【０００１】
【発明の属する技術分野】
この発明は、情報を媒介にして連携する複数の作業工程からなる作業について、複数の作業工程の順序と、各作業工程の処理内容を定め、各作業工程の間での情報の受け渡しなど、作業の処理を支援する情報処理システムに関する。
【０００２】
【従来の技術】
従来から、業務処理の効率化を図るために、コンピュータによる、いわゆるオフィスオートメーション化が提案されている。しかし、従来は、業務処理においては、個々の作業処理自体についての自動化が行なわれているだけであった。つまり、作業間の連携の部分については、従来のオフィスオートメーションでは考慮されていなかった。
【０００３】
この作業間の連携部分を自動化して業務処理のトータルな効率化や迅速化を図ろうとするものとして、ワークフロー・オートメーションが提案されている。ワークフロー・オートメーションにおいては、作業対象となる情報を媒介にして連携する複数の作業工程はワークフローと呼ばれ、このワークフローを自動化するための支援システムはワークフローシステムと呼ばれる。
【０００４】
ワークフローシステムは、ネットワーク化された分散処理環境などの処理環境において、業務処理における複数のユーザ間の情報の受け渡しと、情報を受けてから次の作業工程に渡すまでの間に処理すべき作業などのルールを、予め設計、定義することにより業務処理を自動化する情報処理システムである。
【０００５】
このワークフローシステムは、次のような処理機能で構成される。
▲１▼業務処理の流れ、各業務におけるルールを定義するための編集機能
▲２▼テンプレート（定義されたワークフロー）を管理する機能
▲３▼処理すべき情報が配達されたことをユーザに知らせる通知機能
▲４▼配達された情報を管理するデータベース機能
▲５▼設定された業務の流れ、ルールに従って情報を次の作業工程に渡すルーティング機能
▲６▼作業の状況を管理するための進捗管理機能
▲７▼実行中のワークフローの維持管理を行なうためのシステム管理機能。
【０００６】
このワークフローシステムの概要は、後述の非特許文献１に記載されている。
【０００７】
ワークフローが定義された場合、そのワークフローの仕事の流れ（フロー）はグラフ構造によって表現される。図４７は、この定義されたワークフローの流れの一例である。
【０００８】
図４７において、それぞれ四角で囲まれた各ノードは、作業の単位である作業工程（以下ステップと呼ぶ）を表している。各アーク（矢印）は仕事の流れ（つながり、作業の順番や因果関係）を定義しており、あるステップの後ろにステップがあるということは、前のステップが完了しないと、後ろのステップは開始できないことを意味する。逆に、前のステップが完了すると、自動的に後ろのステップが開始するということを意味する。
【０００９】
ワークフローでは、各ステップでの実際の作業は人間が行なうが、以上のような作業の流れの管理は全てワークフローシステムが行なう。すなわち、ワークフローシステムは、定義されたワークフローを元に、各ステップの作業が終了すると、適宜、次のステップの作業を開始するようにして、作業全体の流れを管理する。
【００１０】
上記のように、あるステップが完了した場合に別のステップを開始するような機能をルーティング機能と呼ぶ。あるステップの作業が終了したときに、後続のステップの作業を開始させることをそのステップに対してルーティングを行なうといい、後続のステップに仕事を流さない場合はルーティングを行なわないという。上述した文献には、このルーティングの方法の詳細については、記述されてない。
【００１１】
【非特許文献１】
日経ＢＰ社発行の雑誌「日経情報ストラテジー」、１９９３年８月号、マイケル・Ｄ・カーン、安田誠寄稿、「ワークフロー管理技術とその可能性」Ｐ１２３〜Ｐ１３０。
【００１２】
【発明が解決しようとする課題】
ところで、図４７において四角で囲まれた各ノードを構成する作業工程に対しては、通常は、一つの単位作業が割り当てられる。このため、複雑で規模の大きい業務処理についてワークフローを定義するときには、ワークフローが非常に複雑になってしまう。
【００１３】
例えば業務内容が階層的な構造を有していて、下位の業務が終了しないときには、上位の業務が開始できないような場合であっても、下位の業務および上位の業務を、それぞれ単位作業からなるノードを構成する作業工程に分け、それらの作業工程について、ワークフローを定義するようにする場合には、階層関係の考慮をしつつ、ワークフローを定義しなければならず、厄介であるとともに、ワークフローの運用が詳細に定義されたものに限定されて、柔軟性にかけてしまうという問題がある。
【００１４】
この発明は、上記の点にかんがみ、ワークフローの作業の流れを階層的に定義および動作させることができ、柔軟な運用を行なえる情報処理システムを提供することを目的とする。
【００１５】
【課題を解決するための手段】
上記課題を解決するため、この発明による情報処理システムは、
順序立てて処理すべき作業が複数個の作業工程に分けられ、その複数個の作業工程の順序と、各作業工程の処理内容とを記憶する記憶手段と、
前記作業工程の開始通知および前記作業工程の終了通知を受け取る通知管理手段と、
前記通知管理手段を通じた前記作業工程の開始通知および前記作業工程の終了通知と、前記記憶手段に記憶された前記複数個の作業工程の順序にしたがって次に開始させる次作業工程を決定するルーティング管理手段と、
を備える情報処理システムにおいて、
前記ルーティング管理手段は、
前記次作業工程に、当該次作業工程の作業を細分化した作業の単位と、その細分化した作業の単位の前後のつながりとからなるサブフローが結び付けられて定義されていると判断したときに、前記通知管理手段を通じた前記開始通知に基づき前記サブフローを起動するサブフロー起動手段と、
前記サブフロー起動手段により起動されたサブフローが結び付けられて定義されている前記次作業工程の前記終了通知を前記通知管理手段を通じて受けたときに、前記サブフローが実行中であるか否かを判別し、実行中でなく終了していると判別したときに、前記次作業工程を決定する処理を行なうルーティング手段と、
を備えることを特徴とする。
【００１６】
【作用】
この発明の情報処理システムにおいては、ワークフロー中の適宜の作業工程において、サブフローが起動される。そして、このサブフローによる作業がすべて完了となった後に、このサブフローが起動された作業工程が作業終了可能となる。したがって、ワークフローの作業の流れを階層的に定義および動作させることができ、詳細で規模の大きいワークフローのみで運用する場合に比べて、より柔軟に対応する運用をすることができる作業の流れ管理方法を構築することができる。
【００１７】
【発明の実施の形態】
以下、この発明による情報処理システムの一実施形態を、図を参照しながら説明する。
【００１８】
図２は、この例の情報処理システムの全体の概要を示すもので、その機能をブロックとして示したものである。この情報処理システムは、前述したワークフローシステムの構成を有するものであって、システム部１０と、ユーザインターフェース部２０とからなっており、ワークフローを管理して支援すると共に、各作業工程（以下、作業工程をステップと呼ぶ）の担当者による処理を支援するための作業環境を提供する役割も有する。
【００１９】
システム部１０は、ファイル管理装置を内蔵する例えばサーバー装置の構成とすることができる。また、ユーザインターフェース部２０は、例えばワークステーションなどの情報処理端末装置により構成することができ、そのディスプレイに各作業段階の作業環境を表示することができる。ユーザインターフェース部２０は、複数の担当者が共通の１個を共有して使用するように構成することもできるし、担当者毎に設ける構成とすることもできる。そして、システム部１０とユーザインターフェース部２０とを、例えばＬＡＮなどのネットワークにより接続して、分散処理環境を構築することができる。なお、システム部１０とユーザインターフェース部２０とを同一の装置において構成することもできる。
【００２０】
システム部１０は、テンプレート管理部１１と、ルーティング管理部１２と、通知管理部１３と、進捗情報管理部１４と、ユーザ管理部１５と、システム管理部１６と、参照情報管理部１７とを備える。また、ユーザインターフェース部２０は、編集部２１と、通知部２２と、進捗管理部２３と、インターフェースコントロール部２４とを備える。
【００２１】
ユーザインターフェース部２０の編集部２１では、ユーザにより設定入力された業務処理の流れ、各業務におけるルールによりワークフローを定義する。システム部１０のテンプレート管理部１１は、定義されたワークフロー（テンプレート）を管理する。
【００２２】
システム部１０のルーティング管理部１２は、後で詳細に説明するように、設定された業務の流れ、ステップの担当者（ユーザ）による指定、あらかじめ定義されたルールにしたがって、このルーティングを行なう。
【００２３】
システム部１０の通知管理部１３は、処理すべき情報の配達の、ユーザ（担当者）への通知を管理する。ユーザへの通知は、ユーザインターフェース部２０の通知部２２が行なう。
【００２４】
システム部１０の進捗情報管理部１４は、作業の状況、作業の履歴を管理するための情報を管理する。ユーザインターフェース部２０の進捗管理部２３は、この情報を用いて作業の状況を管理する。
【００２５】
ユーザ管理部１５は、各ステップを担当するユーザを管理する。システム管理部１６は、システム部１０の全体を管理する。参照情報管理部１７は、各ステップの担当者に与える、作業に必要な情報を管理する。
【００２６】
［ワークフローシステムによるワークフローの流れの管理の概要］
この例のワークフローシステムにおいては、定義されたワークフローの各ステップを、以下のような５つの状態により、その遷移状態を管理する。
【００２７】
▲１▼ステップがまだ作業を開始することができない開始不可状態（以下、この状態を「ｎｏｔ ｒｅａｄｙ」という）
▲２▼ステップの開始準備ができており、担当者の仕事の開始を待っている待機状態（以下、この状態を「ｒｅａｄｙ」という）
▲３▼担当者が作業をしている実行状態（以下、この状態を「ｒｕｎ」という）
▲４▼担当者が作業を終了した作業終了状態（以下、この状態を「ｃｏｍｐｌｅｔｅ」という）
▲５▼ルーティングが行なわれず、ワークフローから切り離された切り離し状態（以下、この状態を「ｉｓｏｌａｔｅ」という）
の５種である。
【００２８】
後述するように、あるステップの後続のアークが複数個存在、すなわち、複数のステップに分岐がなされているときに、ルーティングが行なわれないステップがあるとき、そのルーティングが行なわれないステップが「ｉｓｏｌａｔｅ」の状態になる。
【００２９】
以上のステップの状態遷移に応じてワークフローシステムは、基本的には、次のような動作を行ない、この動作が各ステップに対して繰り返されることにより、ワークフローは進行する。
【００３０】
初期状態では、各ステップは、「ｎｏｔ ｒｅａｄｙ」の状態にされている。ワークフローの起動が行なわれると、最初のステップが「ｒｅａｄｙ」にされる。また、後述するように、前ステップが終了したとき（「ｃｏｍｐｌｅｔｅ」および「ｉｓｏｌａｔｅ」の状態になったとき）に、ルーティング管理部により決定された次のステップの状態が「ｒｅａｄｙ」とされる。
【００３１】
ステップが「ｒｅａｄｙ」になると、担当者に対して通知を行なうことにより作業の開始を促す。担当者が開始の合図をワークフローシステムに対して行なうと、ステップの状態は「ｒｕｎ」となる。このとき、ワークフローシステムから担当者に対して、作業を行なうために必要な情報をひとまとめにしたデータの塊を送り返す。このデータの塊は、作業を行なうために必要な情報の実体と、その参照情報からなり、これを以下パケットと呼ぶ。
【００３２】
担当者が指定された作業を終了すると、作業内容を反映させたパケットとともに、ワークフローシステムに対し、完了の合図を送る。この時、ステップの状態は「ｃｏｍｐｌｅｔｅ」となる。
【００３３】
ワークフローシステムは各ステップが終了した時に、次に実行されるステップを決定し、当該ステップに対して、ルーティングを行なう。具体的には、当該ステップの状態を「ｒｅａｄｙ」にすることによって、担当者に通知を送り、ワークフローを進行させる。
【００３４】
［ルーティングの方法の概要］
上述したように、あるステップが終了すると次に実行されるステップがルーティング機能により決定される。この場合において、前述もしたように、当該終了したステップに対して、後続のステップが、分岐のように複数のステップがある場合には、そのうちのどれを開始するのか、あるいは全て開始しなければならないのかを決定しなければならない。この例においては、以下に説明するようにして、ワークフローの実行時に動的にしかも柔軟にルーティングが決定される。
【００３５】
（１）担当者によるルーティングの指定方法
ルーティングの指定方法のひとつとして、この例では、ワークフロー中に分岐がある場合、分岐の手前のステップの担当者により、次のステップを指定させる方法を用いる。すなわち、この方法においては、ステップの担当者には、次ステップの候補が示され、担当者は、そのうちルーティングを行なわせたいステップを選ぶ。
【００３６】
これを実現するために、この例においては、パケットにルーティング情報とよばれる情報のフィールドを追加する。ルーティング情報には、例えばそのステップの後続のステップの名前と真理値がペアになって含まれている。あるいは、ルーティング情報には、後続のアーク（例えばステップ１からステップ２のアークであればステップ１−２のように表現）と、その真理値のペアが記述される。
【００３７】
真理値の値はシステムによって初期化されるが、ステップの担当者は、このルーティング情報の真理値を変更することができる。値が「真」であることはルーティングが行なわれることを意味し、値が「偽」であることはルーティングが行なわれないことを意味する。
【００３８】
システムによって初期化された値は、担当者がルーティング情報を何も変更しなかった場合のデフォルトの値となる。担当者は送られてきたルーティング情報を参考に、目的を達成するために最も良いと判断されるように真理値を変える。具体的にはルーティングを行ないたいステップに対しては対応するルーティング情報の真理値を「真」にし、ルーティングを行ないたくないステップに対してはルーティング情報の対応する真理値を「偽」にする。これにより、ワークフローの実行中にルーティングをステップの担当ユーザの指示により柔軟かつ動的に決定することが可能となる。
【００３９】
変更されたルーティング情報はパケットに含まれ、作業完了の合図とともに、ワークフローシステムに送り返される。システムはパケット中のルーティング情報を参照し、後続のステップに対応する真理値を調べ、「真」であるステップに対してはルーティングを行ない、「偽」であるステップに対しては、ルーティングを行なわない。
【００４０】
（２）ワークフローシステムによるルーティングの指定方法
分岐の際のルーティングの決定は、場合によって担当者ではなく、ワークフローシステムによって自動的に行って欲しい場合もある。しかし、ワークフローシステムも何の情報もなしにルーティングは決定することはできない。そこで、この例では、前のステップの作業結果の情報を用いると共に、あらかじめ定義したルールなどの「約束事」を用いることによって、ワークフローシステムによるこの場合のルーティングの決定を実現する。この方法は、担当者に直接ルーティングは指定させたくないが、担当者が下した別の判断を材料にルーティングを決定する際に便利である。
【００４１】
このワークフローシステムによるルーティングの指定方法の一つとしては、前述したルーティング情報フィールドを用いずにルーティングの決定を行なう方法がある。例えばルールのみを用いてルーティングを決定する方法である。すなわち、ルールなどの約束事の実行（評価）の結果、ルーティングを行なうと決定したときには、真理値として「真」を、ルーティングを行なわないと決定したときには、真理値として「偽」を、それぞれ評価結果として得る。そして、その評価結果を用いて、ワークフローシステムは、次の作業工程に対してルーティングを行なうか否かの決定をする。
【００４２】
ワークフローシステムによるルーティングの指定方法の他の方法としては、ルールを用いてルーティング情報フィールドの内容を記述するようにする方法がある。この方法によれば、前述した担当者によるルーティングの決定方法と、このワークフローシステムによる自動のルーティングの決定方法とのいずれであっても、ルーティング情報フィールドの内容を参照することによりルーティングを決定することができるので、ルーティングの決定のためのソフトウエアを簡略化できる。
【００４３】
［ルーティング決定方法の第１の例の説明］
以下に説明する第１の例は、ルーティング情報フィールドを用いて担当者が後続の作業工程に対してルーティングを行うか否かの指定を行えるようにすると共に、ルーティング情報フィールドを用いずにルールのみによりワークフローシステムがルーティングを決定することができるようにした例である。
【００４４】
この第１の例の場合には、ワークフローの定義を行なう時に、定義者は、ワークフローシステムに自動的にルーティングを決めて欲しいステップに対してルールを記述する。実際的には、あるステップＡの後が分岐であった場合、そのステップＡの後続のすべてのアークに対してルールを記述する。
【００４５】
例えば、あるステップＡの担当者が出した見積りの金額によって、その次のステップを自動的に選ぶ場合の例を説明する。この場合、ルールとしては、例えば見積もり金額Ｓが所定の基準値Ｒより大きい場合には、後続の例えば２分岐のステップＢ、Ｃの内のステップＢにのみルーティングを行ない、見積もり金額Ｓが所定の基準値Ｒより小さい場合には、後続の複数ステップの内のステップＣにのみルーティングを行なうように定義したものを設定しておく。
【００４６】
ステップＡの担当者に渡すパケットには、担当者が見積もり金額を記述するための情報フィールドが追加される。担当者が終了の合図をワークフローシステムに送ってからワークフローシステムがルーティングの処理を開始するまでの間に、前述のように定義されたルールによって、パケットの情報中の見積もり金額Ｓが評価され、ルーティングが決定される。
【００４７】
＜機能ブロック図の説明＞
図１は、この第１の例の場合の情報処理システムにおけるワークフローの流れの管理に関する部分の機能のブロック図である。
【００４８】
テンプレート管理部１１は、定義されたワークフローに関するデータを、記憶部１１Ｍに記憶する。定義されたワークフローの仕事の流れは、前述したように、作業の単位であるステップと、各ステップ間をつなぐアーク（矢印）とからなるグラフ構造によって表現される。したがって、ワークフローに関するデータは、ワークフローがどのような複数のステップからなっているかを示すステップテーブルと、アークに関するデータであるステップの実行順序のテーブルとで構成することができる。
【００４９】
また、前述したように、分岐のときのアークであって、当該分岐におけるルーティングをワークフローシステムによって決定させるときには、各アークに前述したようなルールが定義され、テンプレート管理部１１の記憶部１１Ｍに記憶される。
【００５０】
ルーティング管理部１２は、この場合、機能的には、ステップ状態管理部３１と、ルーティング前処理部３２と、ルーティング後処理部３３と、ルール評価部３４と、パケット管理部３５とを備える。
【００５１】
ルーティング前処理部３２は、次ステップの担当者に渡すパケットにルーティング情報フィールドや見積もりなどのルーティングのために必要な付加情報フィールドを追加する処理を行なう。
【００５２】
また、ルーティング後処理部３３は、実際のルーティングの決定を行なう。ルーティング後処理部３３は、分岐のときのようにルールがアークについていれば、そのルールの評価をルール評価部３４に対して要求する。ルール評価部３４は、テンプレート管理部１１に記憶されているアーク毎のルールを実行してその評価結果をルーティング後処理部３３に返す。
【００５３】
ステップ状態管理部３１が、テンプレート管理部１１に登録されている定義されたワークフローの各ステップの状態を、前述の５種の状態により管理して、ワークフローの流れを管理する。このステップ状態管理部３１は、定義されたワークフローの各ステップの状態データの記憶部３１Ｍを備える。前述もしたように、初期時には、各ステップの状態は「ｎｏｔ ｒｅａｄｙ」となっている。
【００５４】
ステップ状態管理部３１は、ステップの状態が「ｎｏｔ ｒｅａｄｙ」から「ｒｅａｄｙ」になるときに、ルーティング前処理部３２に処理要求を出す。ワークフローの開始時においては、担当者によるワークフローの起動要求を受けたとき、最初のステップの状態が「ｎｏｔ ｒｅａｄｙ」から「ｒｅａｄｙ」になる。また、ワークフローの実行中は、ステップ状態管理部３１は、ルーティング後処理部３３からの要求によって、ルーティングを行なうステップの状態を、「ｎｏｔ ｒｅａｄｙ」から「ｒｅａｄｙ」にし、ルーティングを行なわないステップの状態を「ｉｓｏｌａｔｅ」にする。
【００５５】
ステップが「ｎｏｔ ｒｅａｄｙ」から「ｒｅａｄｙ」になるとき、ステップ状態管理部３１は、通知管理部１３に通知要求を出す。通知管理部１３は、次ステップの担当者に対して通知を行なって担当者の作業の開始を促す。
【００５６】
この通知に対して担当者が開始の合図をワークフローシステムに対して行なうと、この合図を通知管理部１３が受け、ステップ状態管理部３１にその旨を知らせる。ステップ状態管理部３１は、これに応じてステップの状態を「ｒｅａｄｙ」から「ｒｕｎ」にする。
【００５７】
そして、ステップ状態管理部３１は、パケット管理部３５にパケット送信要求を出して、このパケット管理部３５より、担当者が作業を行なうために必要な情報をひとまとめにしたデータの塊であるパケットを担当者に対して送る。このパケットには、ルーティング前処理部３２により付加されたルーティング情報や、その他のルーティングに必要な情報のフィールドが含まれている。
【００５８】
パケットは参照情報管理部１７により管理され、参照情報管理部１７は、このパケットの記憶部１７Ｍを有する。パケット管理部３５は、参照情報管理部１７に管理されている情報を用いて次にルーティングするパケットを形成する。また、ユーザから得たパケットを一時的に蓄え、そのルーティングに必要な情報フィールドのデータをルーティング後処理部３３に送る。
【００５９】
前述したように、ルーティング前処理部３２は、パケット管理部３５がパケットを担当者に送る前に、前述したルーティング情報や見積もりの情報などのフィールドを、当該担当者に送るパケットに追加する処理を行なう。
【００６０】
担当者は、ワークフローシステムから配達されたパケットを元に作業を実行する。また、担当者は、パケットに追加された情報フィールドに、必要な情報、例えば後続のステップに関するルーティング情報の真理値や、ルール評価のための材料となる情報を記述する。
【００６１】
指定された作業を終了すると、担当者は、適宜、必要な情報を記述したルーティング情報や作業結果の情報を含む、担当者の作業内容を反映させたパケットとともに、ワークフローシステムに対し、完了の合図を送る。このとき、ステップ状態管理部３１は、当該ステップの状態を「ｒｕｎ」から「ｃｏｍｐｌｅｔｅ」とする。
【００６２】
ステップ状態管理部３１は、ステップの状態が「ｒｕｎ」から「ｃｏｍｐｌｅｔｅ」になるときに、ルーティング後処理部３３に処理要求を出す。ルーティング後処理部３３は、実際のルーティングの決定を行なう。すなわち、ルーティング情報が付加されていれば、それに基づいて次にルーティングを行なうステップを決定し、ステップ状態管理部３１に通知する。また、当該ステップの後続のアークについてルールが定義されていれば、ルーティングのための情報中の前記ルール評価の材料となる情報フィールドの値をルール評価部３４に送って、このルール評価部３４に評価要求を出す。
【００６３】
ルール評価部３４は、テンプレート管理部１１のワークフローデータ中のあらかじめ定義されたルールを用いて評価を実行し、その結果をルーティング後処理部３３に送る。ルーティング後処理部３３は、このルール評価部３４からの評価結果に基づいてルーティングを行なうステップを決定し、ステップ状態管理部３１に通知する。
【００６４】
ステップ状態管理部３１は、ルーティング後処理部３３からの通知によりルーティングを行なうステップの状態を、「ｎｏｔ ｒｅａｄｙ」から「ｒｅａｄｙ」にする。また、ルーティングを行なわないステップの状態を、「ｎｏｔ ｒｅａｄｙ」から「ｉｓｏｌａｔｅ」にする。以下、上述と同様の処理を繰り返して、ワークフローを進行させ、後続のステップがなくなるとワークフローの処理を終了する。
【００６５】
＜ルーティング前処理部３２の動作の具体例＞
図３は、前述したルーティング前処理部３２で実行される処理ルーチンＳ０の一例を示すフローチャートである。
【００６６】
ステップの状態が「ｎｏｔ ｒｅａｄｙ」から「ｒｅａｄｙ」になると、ステップ状態管理部３１から処理要求が到来して図３のルーティング前処理ルーチンＳ０が開始し、現在のステップ（「ｒｅａｄｙ」の状態になったステップ）の後続アークのすべてを、ワークフローデータを参照して探す。また、その他の必要な情報フィールドを追加する（処理Ｓ１）。
【００６７】
次に、そのステップに送るパケットに、後続アークの数だけルーティング情報フィールドを追加する（処理Ｓ２）。次に、前記後続アークの属性情報を調べ（処理Ｓ４）、ワークフローシステムにより設定されているデフォルトのルーティング情報があるか否か判別し（判断Ｓ５）、デフォルトのルーティング情報が存在すれば、そのルーティング情報で、前記追加したルーティング情報フィールドを初期化する（処理Ｓ６）。
【００６８】
判断Ｓ５でデフォルトのルーティング情報がないと判断された場合、あるいは、処理Ｓ６の処理が終了した後には、ステップＳ３に進んで、前記後続のアークのすべてのアークについて処理Ｓ４〜Ｓ６の処理が終了したか否か判断し、終了していなければ、処理Ｓ４〜Ｓ６を繰り返し、すべてのアークについての処理が終了したときには、このルーティング前処理ルーチンは終了となる。
【００６９】
＜ルーティング後処理部３３の動作の具体例＞
図４は、前述したルーティング後処理部３３で実行される処理の一例を示すフローチャートである。ステップの状態が「ｒｕｎ」から「ｃｏｍｐｌｅｔｅ」になるときに、ステップ状態管理部３１から処理要求が到来して図４のルーティング後処理ルーチンＳ１０が開始する。
【００７０】
まず、状態が「ｒｕｎ」から「ｃｏｍｐｌｅｔｅ」になった現在のステップ（以下、このステップを現在ステップＰＳと称する）の後続のステップの処理は、終了しているか否か、つまり処理が終了していない後続ステップがあるか否か判断し（判断Ｓ１１）、処理が終了していない後続のステップがなければこのルーチンＳ１０を終了する。
【００７１】
現在ステップＰＳに対して処理が終了していない後続のステップ（以下、このステップを後続ステップＢＳと称する）が存在する場合には、その後続ステップＢＳに至るアークにルールが定義されているか否か判断する（判断Ｓ１２）。ルールが定義されていれば、ルール評価部３４に対してルール評価処理の要求を出すと共に、現在ステップＰＳからのパケット中のルール評価のためのルーティング情報フィールドの情報を送って、ルール評価を実行させる（処理Ｓ１３）。その後、判断Ｓ１４に進む。
【００７２】
そして、判断Ｓ１４では、そのルール評価結果を受けて、その後続ステップＢＳにルーティングを行なうか否か判断する。また、判断Ｓ１２でアークにルールが定義されていないと判断されたときには、そのまま判断Ｓ１４に進んで、ルーティング情報フィールドのアークに関する真理値を参照して、その後続ステップＢＳにルーティングを行なうか否か判断する。
【００７３】
判断Ｓ１４で、ルーティングを行なうと判断したときには、判断Ｓ１５に進み、ルーティングを行おうとする後続ステップＢＳにアークによってつながっている前ステップが複数あることを想定して、その前ステップはすべて終了となっているか否か判断する。この判断Ｓ１５での前ステップの終了の判断は、前ステップが「ｃｏｍｐｌｅｔｅ」の状態になっているか、あるいは「ｉｓｏｌａｔｅ」の状態になっているかによって行なう。
【００７４】
判断Ｓ１５で、すべての前ステップが終了していると判断されたときには、当該後続ステップＢＳの状態を「ｎｏｔ ｒｅａｄｙ」から「ｒｅａｄｙ」に変更する要求をステップ状態管理部３１に出し、判断Ｓ１１に戻って、現在ステップＰＳの他の後続ステップＢＳに関する上述の処理を行なう。
【００７５】
また、判断Ｓ１５において、ルーティングを行おうとする後続ステップＢＳの前記複数の前ステップのうちの一部が終了となっていないと判断されたときには、当該後続ステップＢＳの状態を「ｎｏｔ ｒｅａｄｙ」から「ｒｅａｄｙ」にする要求は出さずに、この後続ステップＢＳに関してスタートフラグを立てる（処理Ｓ１７）。そして、判断Ｓ１１に戻って、前記現在ステップＰＳの他の後続ステップＢＳに関して上述の処理を行なう。
【００７６】
また、判断Ｓ１４において、後続ステップＢＳに対してルーティングを行なわないと判断された場合には、判断Ｓ１８に進み、ルーティングを行なわない当該後続ステップＢＳの前ステップはすべて終了となっているか否か判断する。この判断Ｓ１８での前ステップの終了の判断も、前述と同様に、前ステップが「ｃｏｍｐｌｅｔｅ」の状態になっているか、あるいは「ｉｓｏｌａｔｅ」の状態になっているかによって行なう。
【００７７】
判断Ｓ１８において、ルーティングを行なわない後続ステップＢＳの前の複数のステップのうちの一部が終了となっていないと判断されたときには、そのまま判断Ｓ１１に戻って、前記現在ステップＰＳの他の後続ステップＢＳに関して上述の処理を行なう。
【００７８】
また、判断Ｓ１８において、ルーティングを行なわない後続ステップＢＳの前のステップがすべて終了であると判断されたときには、判断Ｓ１９に進み、当該後続ステップＢＳにスタートフラグが立っているか否か判断する。スタートフラグが立っていれば、処理Ｓ１６に進み、当該後続ステップＢＳの状態を「ｒｅａｄｙ」とし、判断Ｓ１１に戻る。
【００７９】
すなわち、判断Ｓ１９において、スタートフラグが立っている状態は、現在ステップからはルーティングを行なわない後続ステップＢＳに、現在ステップと異なる他のステップからのルーティングが行なわれることが決定されていて、そのルーティングが待ちの状態になっていることを示している。そして、当該後続ステップＢＳの前ステップはすべて終了であると判断Ｓ１８で既に判断されているので、当該後続ステップへのルーティングが可能になる。このため、処理Ｓ１６に進んで、「ｒｅａｄｙ」の状態となる。
【００８０】
また、判断Ｓ１９において、スタートフラグが立っていないと判断されたときには、処理Ｓ２０に進み、当該後続ステップＢＳの状態を「ｉｓｏｌａｔｅ」にする。次に、処理Ｓ２１に進み、当該後続のステップＢＳの後続のステップに移行してそのステップに対して処理Ｓ１８から処理Ｓ２０までの処理を行なう。こうして、「ｉｓｏｌａｔｅ」の状態になったステップの後続のステップについて、処理Ｓ１８から処理Ｓ２０までの処理を再帰的に行なう。その後、判断Ｓ１１に戻る。
【００８１】
＜第１の例が適用されたワークフローの具体例＞
ワークフローの第１の具体例として、以下、図面作成処理のフローの場合の例について説明する。
【００８２】
図５は、図面作成処理のフローの例を有向グラフにより現したものである。この例の図面作成処理のワークフローは、ステップ番号１のステップ（以下、ステップ１という）が「図面の作成」、ステップ番号２（以下、ステップ２という）と、ステップ番号３（以下、ステップ３という）とが「図面の検査」、ステップ番号４（以下、ステップ４という）が「図面の承認」の４つのステップからなり、ステップ１からステップ２またはステップ１からステップ３に分岐し、ステップ２およびステップ３からステップ４に合流するものとして定義されている。
【００８３】
この例の場合、テンプレート管理部１１で管理される、定義されたワークフロー（テンプレート）に関するデータは、図６に示すような、ワークフローがどのような複数のステップからなっているかを示すステップテーブルＳＴと、図７に示すような、ステップの実行順序の情報である実行順序テーブルＯＴとからなる。実行順序テーブルＯＴには、ステップ識別子としてのステップ番号を用いて前後のステップが記述されることによりアークが記述されることになる。なお、実行順序テーブルＯＴにおいて、ステップ番号「０」は、開始のステップ、ステップ番号「ＮＵＬＬ」は、終了のステップを示している。
【００８４】
この例の場合には、複数個のワークフローを同時に管理することを想定しているためステップテーブルＳＴと、実行順序テーブルＯＴには、ワークフロー識別子が付与されており、このワークフロー識別子により、いずれのワークフローであるかが一意に識別される。図の例のワークフロー識別子「１０００」は、図面作成処理のワークフローを示している。
【００８５】
この例の説明において、ステップ番号は各ステップの識別子となる。また、ステップ名は、各ステップで行なう作業内容を示す作業名である。担当者の欄には、各ステップの作業を実行するユーザ名が記述される。ユーザの代わりに、営業部門、設計部門などの担当部門が担当者として設定される場合や、図面作成者、検査者、承認者などの作業を実行する役割者名が記述される場合もある。担当ユーザ名の代わりに担当部門名や、役割者名が担当者の欄に記述される場合には、ユーザ管理部１５で管理されている、個々のユーザと担当部門との対応や、個々のユーザと役割者名との対応に応じて実際に担当するユーザ名が決定される。
【００８６】
前述したように、ワークフローを流れるデータを管理するために、パケットにワークフローを実行するための必要な様々な情報を含めて、各ステップから次ステップへと渡される。
【００８７】
ワークフローにおけるパケットの流れと、その内容の変化と、パケットの情報フィールドを用いたルーティングの決定の仕方の例を、この例の図面作成のワークフローを用いて以下に説明する。
【００８８】
（１）担当者によるルーティングの決定の場合
まず、ステップ１の担当者が、その後続のステップ２、３にどのようにルーティングするかを決定する場合について説明する。
【００８９】
まず、起動者によってワークフローが起動される。起動する際に、起動者は、最初のステップの担当者宛てのメッセージがあれば、その通信文を書く。
【００９０】
図８は、ステップ１が開始されるときに作成され、ステップ１の担当者に送られるパケットの内容の例であり、フィールド名と、そのフィールド値からなる。フィールド名「担当者」「作業名」「概要」の欄のフィールド値は、ワークフローを定義したときに定義されている値であり、ワークフローシステムがワークフローデータから転記する。
【００９１】
フィールド名「コメント」の欄はワークフローを起動した者が、最初のステップの担当者宛ての通信欄として使用することができる。１回、ワークフローが起動されると、この「コメント」の欄は、前の担当者から次の担当者への連絡用に使われる。
【００９２】
フィールド名「Ｄａｔｅ」「Ｃｕｒｒｅｎｔ Ｓｔｅｐ」の欄のフィールド値は、それぞれ当該パケットが送信された日付と、送信の宛先のステップ番号であり、ワークフローシステムが自動的に追加する。
【００９３】
そして、ワークフローシステムは、起動者によるワークフローの起動を受けて、ステップ１の状態を「ｒｅａｄｙ」にしたとき、前述したルーティング前処理を実行する。このルーティング前処理では、ステップ１の下流に、ステップ２とステップ３の二つのステップがあるため、ルーティングのための二つのフィールド「ｓｔｅｐ−１−２」「ｓｔｅｐ−１−３」を付加し、デフォルトのフィールド値として「真（図ではｔｒｕｅと示した。以下同じ）」を挿入する。
【００９４】
フィールド「ｓｔｅｐ−１−２」は、ステップ１からステップ２へのアークを示し、フィールド「ｓｔｅｐ−１−３」は、ステップ１からステップ３へのアークを示している。なお、前述もしたように、フィールド値の「真」は、ルーティングを行なうことを意味しており、「偽（図ではｆａｌｓｅと示す。以下同じ）」はルーティングを行なわないことを意味している。
【００９５】
前述したように、ステップ１の状態が「ｒｅａｄｙ」になった後、担当者から作業開始の合図が来ると、上述の図８のような内容の最初のパケットが、ステップ１の担当者に送られる。
【００９６】
ステップ１の担当者は、受け取ったパケットの中身を見て、自分の仕事が図面作成であることを知り、図面作成の作業を行なう。作成した図面は、担当者がパケットに追加する。担当者は、また、必要に応じて次ステップの担当者に宛てたメッセージをパケットの「コメント」の欄に挿入する。
【００９７】
また、ステップ１の担当者は、パケット内のルーティングの情報フィールドである二つのフィールド「ｓｔｅｐ−１−２」「ｓｔｅｐ−１−３」のフィールド値を書き換えることにより、後続の二つの検査のステップ２とステップ３に対するルーティングを決定することができる。この例では、デフォルトのフィールド値は、「真」であるので、フィールド値を書き換えることは、ルーティングを行なわないことを指示することに等しい。
【００９８】
ステップ１の作業が終了したときのパケットの例を図９に示す。この図９のパケットでは、ステップ１の担当者によって、ステップ３にルーティングを行なわないように指示されている。
【００９９】
なお、パケットの情報フィールドの欄の内、「担当者」や「Ｄａｔｅ」などのワークフローシステムが用いる欄は、担当者が勝手に変えることはできないように構成されている。
【０１００】
ステップ１が終了すると、その終了の合図と共に、図９のパケットがワークフローシステムに返送されてくる。このパケットを受けると、ワークフローシステムは、前述したように、ルーティング後処理を開始する。
【０１０１】
すなわち、ワークフローシステムは、受け取ったパケットの中身を検査し、ルーティングの情報を用いて後続のステップに対するルーティングを行なうか否かの決定を行なう。この例の場合には、フィールド「ｓｔｅｐ−１−２」の値が「真」であるので、ステップ２にはルーティングを行なう。しかし、フィールド「ｓｔｅｐ−１−３」は「偽」であるので、ステップ３にはルーティングを行なわない。そして、ステップ２には、ルーティングを行なうので、その状態を「ｒｅａｄｙ」にする。また、ステップ３には、ルーティングを行なわないので、その状態を「ｉｓｏｌａｔｅ」にする。
【０１０２】
そして、ルーティングを行なうステップ２にパケットを送るために、ワークフローシステムは、「担当者」「作業名」「概要」などのフィールドの値を入れ替え、また、ルーティング前処理を行って、フィールド「ｓｔｅｐ−２−３」をパケットに付加し、そのフィールド値としてデフォルトの「真」を挿入し、そのパケットをステップ２の担当者に宛てて送る。ただし、このフィールド「ｓｔｅｐ−２−３」のように、後続のステップが一つしかない場合には、そのデフォルトのフィールド値は、「担当者」や「Ｄａｔｅ」などの欄と同様に、担当者が勝手に書き換えることができないように構成されている。
【０１０３】
ステップ２の担当者は、受け取ったパケットの中身を見て、自分の仕事が図面検査であることを知り、図面検査の作業を行なう。検査後の図面は、担当者がパケットに戻す。担当者は、また、必要に応じて次ステップの担当者に宛てたメッセージをパケットの「コメント」の欄に挿入する。
【０１０４】
そして、ステップ２の作業が終了すると、終了の合図と共に、前記パケットがワークフローシステムに戻される。ワークフローシステムは、終了の合図によって、ステップ２の状態を「ｒｕｎ」から「ｃｏｍｐｌｅｔｅ」にする。そして、ルーティング後処理を行ない、パケットのルーティング情報フィールド「ｓｔｅｐ−２−３」の値が「真」であることから、ステップ４にルーティングを行なうことを決定するが、ステップ４には、前ステップとして、ステップ３の存在するので、ステップ２の状態だけでなく、ステップ３の状態をも参照する。このとき、ステップ３の状態は「ｉｓｏｌａｔｅ」になっているので、ステップ２の状態「ｃｏｍｐｌｅｔｅ」と合わせて、ステップ４の前ステップのすべてが終了したと判断して、前述と同様にしてステップ４にルーティングを実行する。
【０１０５】
（２）アークに付いたルールによるルーティングの決定の場合
この例の場合、ワークフローの定義時に、分岐のときのアークに対してルールを記述しておく。このルールの例を図１０および図１１に示す。図１０は、ステップ１からステップ２へのアークに付いているルールの例であり、「ステップ１で計算された見積もり金額が１００００円を越えた場合には、ステップ２にルーティングを行ない、ステップ３にはルーティングを行なわない、１００００円以下の場合には、ステップ３にルーティングを行ない、ステップ２にはルーティングを行なわない」という内容である。
【０１０６】
また、図１１は、ステップ１からステップ３へのアークに付いているルールの例であり、「ステップ１で計算された見積もり金額が１００００円以下である場合には、ステップ２にルーティングを行ない、ステップ３にはルーティングを行なわない、１００００円を越えた場合には、ステップ３にルーティングを行ない、ステップ２にはルーティングを行なわない」という内容である。
【０１０７】
この例の場合には、ステップ１にルーティングが行なわれるときに、ルーティング前処理により、そのステップ１の担当者に送られるパケットには、図１２に示すように、ステップ１からステップ２へのアークおよびステップ１からステップ３へのアークに関するルーティング情報フィールド「ｓｔｅｐ−１−２」「ｓｔｅｐ−１−３」に加えて、「見積もり」のフィールドが追加される。
【０１０８】
ステップ１の担当者は、前述したようにして、図面作成の作業を行なうと共に、見積もり金額を計算し、その金額をパケットの「見積もり」のフィールドに、そのフィールド値として挿入する。例えば担当者は見積もり金額を「１２０００円」と決定した場合、その値「１２０００」をフィールド「見積もり」の値として挿入する。この場合のステップ１の終了時のパケットの例を図１３に示す。
【０１０９】
ステップ１の担当者が作業を終了し、その合図をしたとき、図１３のパケットがワークフローシステムに返送される。これを受けて、ワークフローシステムは、ルーティング後処理を開始する。この場合、ステップ１の後続のアークには、ルールが付いているので、パケットに追加されているルーティング情報の真理値を確認する代わりに、返送されてきた図１３のパケットのフィールド「見積もり」の値を用いて、ステップ１に後続のアークに付いているルールをすべて評価し、その評価結果によりルーティングを決定する。
【０１１０】
前述したように、ルールの評価は、ルール評価部３４で行なわれる。まず、ステップ１からステップ２へのアークに付いているルールが評価される。この例の場合には、パケットのフィールド「見積もり」の値が「１２０００」であるため、評価結果は「真」となる。したがって、ステップ２には、ルーティングが行なわれる。
【０１１１】
次に、同様にして、ステップ１からステップ３に向かうアークに付いているルールの評価が行なわれる。この例の場合には、パケットのフィールド「見積もり」の値が「１２０００」であるため、評価結果は「偽」となる。したがって、ステップ３には、ルーティングが行なわれない。
【０１１２】
以上のようにして、あらかじめアークに対して定義されたルールを用いることにより、前のステップの作業結果に応じて後のステップに対するルーティングをワークフローシステムが動的に決定することができる。この場合には、ルーティング情報フィールドを参照する必要はない。
【０１１３】
なお、以上の実施例では、ルールがアークに付いている場合に、パケットに含まれるルーティング情報フィールドに対してルールを優先としてルーティングを行なったが、ステップの担当者がルーティング情報フィールドの真理値を変更したときには、当該担当者により設定変更されたルーティング情報フィールドをルールに優先するようにしてもよい。
【０１１４】
［ルーティング決定方法の第２の例］
上述した第１の例においては、ワークフローシステムによるルーティングの指定方法はアークについて定義したルールを、ルーティング後処理において評価してルーティングを決定するようにしたが、第２の例においては、ステップの状態などについてルールを定義して、そのルールの評価結果として得られるルーティングに関する真理値を、システムがルーティング情報フィールドに書き込むようにする。
【０１１５】
この第２の例の場合には、ルーティング後処理においては、ルールの評価を行なう必要がないので、ルーティング後処理のルーチンは、図１４のルーチンＳ１００に示すように、図４のルーティング後処理のルーチンＳ１０において、判断Ｓ１２と、処理Ｓ１３とを省略し、判断Ｓ１１の判断結果が「ＮＯ」の場合には、判断Ｓ１４に進むようにしたものとすることができ、ルーティング後処理のソフトウエアを簡略化できる。
【０１１６】
なお、第１の例においても、アークについて記述されているルールを、ルーティング後処理の前に必ず実行し、ルールの評価結果により、ルーティング情報フィールドの真理値を書き換えるようにしておくことにより、ルーティング後処理のソフトウエアを簡略化できる。
【０１１７】
［第２の例が適用されたワークフローの具体例］
第２の例が適用されたワークフローの具体例として、以下、設計変更処理のフローの場合の例について説明する。
【０１１８】
以下に説明するワークフローの実施例においては、ステップの状態について定義されたルールにより、ルーティングを決定するための情報の生成を行ない、後述する自動実行ステップによりルーティング情報フィールドに、ルーティングを行なうか否かを決定するための真理値を記入するようにしている。
【０１１９】
＜自動実行ステップ＞
この第２の例においては、ワークフロー中の作業の中には、人間よりも機械の方が向いている作業も存在することにかんがみ、特に担当ユーザを定めずに、自動的に作業の実行を行なうステップを創設する。以下、このタイプのステップを自動実行ステップと呼び、これと担当ユーザが実行するタイプの通常のステップとを区別する必要があるときは、担当ユーザが実行するステップを通常ステップと呼ぶことにする。
【０１２０】
自動実行ステップの作業は、この例ではワークフローシステム内で行なう作業として定義される。ワークフローシステムは、自動実行ステップの状態が「ｒｅａｄｙ」になった時には通知を出さず、即座に「ｒｕｎ」の状態へと移行させる。そして、予め定義された作業をワークフローシステム内で自動的に実行し、それが終了すると自動的に「ｃｏｍｐｌｅｔｅ」の状態として、次ステップに対するルーティングを行なう。
【０１２１】
なお、ワークフローシステム自身ではなく、ワークフローシステムの管理下にあるハードウエアに仕事をさせるようにしてもよい。
【０１２２】
人間が担当しない作業であっても、ワークフローシステム内ではない、あるいは、ワークフローシステムの管理下ではない他のシステムに作業の実行をさせるステップも考えられる。しかし、その場合には、当該ステップの作業を実行するシステムを担当者として、他のシステムを割り当てれば、通常ステップとして扱うことができる。すなわち、この場合、当該他のシステムは、ワークフローシステムから通知を受けると、即座に作業の開始の合図を送って作業を開始し、作業が終了すると終了の通知をワークフローシステムに送るように、ソフトウエアにより処理する。このようにすることにより、人間以外の機械を担当者として、ワークフローシステム外のネットワーク上に設定することもできる。
【０１２３】
＜サブフロー＞
また、この第２の例では、複雑で、規模の大きいワークフローを、より柔軟に、かつ、様々な局面に対応することができるようにするために、ワークフローを階層的に動作させることができるようにしている。
【０１２４】
すなわち、ワークフローを上位のメインフローと、その下位のサブフローとから構成する。サブフローは、メインフローの内の適宜の一つのステップに結び付いたものであって、その結び付いたステップの作業を細分化した複数のステップと、その複数のステップ間の前後のつながりをアークで定義したものである。サブフローが一つのステップに結び付いているということは、その結び付かれているステップは、サブフローが終了しないと終了できないことを意味している。
【０１２５】
サブフローは、一つのステップに対して、複数個、定義することもでき、その場合には、すべてのサブフローが終了しないと、それら複数のサブフローが結びついているステップは終了できない。
【０１２６】
この例の場合には、サブフローが結び付いているステップが「ｒｕｎ」の状態になったときに、そのステップの担当者が、自分の作業をより詳細化し、その作業を実行するために相応しいと思われるサブフローを新たに定義して、起動する。サブフローの典型例をあらかじめ登録しておき、その中から起動するサブフローを、ステップの担当者が選ぶようにすることもできる。
【０１２７】
サブフローの各ステップは、すべて通常ステップで構成することもできるし、サブフローのすべてのステップを自動実行ステップで構成することもできる。また、サブフローの一部を自動実行ステップで構成することも、もちろんできる。
【０１２８】
また、サブフローをあらかじめ定義しておき、このサブフローが結び付いているステップが「ｒｅａｄｙ」の状態になったら、自動的にサブフローを起動するようにすることもできる。その場合に、起動するサブフローは複数個あってもよい。また、当該複数個のサブフローのすべてを自動実行ステップで構成した場合には、一つのステップに対して自動で起動され、処理が自動で実行される複数の作業を容易に定義することが可能になる。
【０１２９】
このように、ステップの担当者がサブフローを定義して起動し、そのサブフローが終了しない限り、当該ステップが終了することができないようにすることにより、メインのワークフロー中には、当該サブフローが結び付いているステップの代わりに、そのサブフローの内容を詳細に定義する必要がなくなり、ワークフローの管理が容易になる。
【０１３０】
＜設計変更プロセスと、そのワークフロー＞
まず、この例の設計変更プロセスについて説明する。典型的な設計変更のプロセスは、例えば以下の手順のように行なわれる。
【０１３１】
１．設計変更の要求
２．要求の受け付け
３．変更のレビュー
４．実施の可否
５．設計変更
６．承認
７．配布。
【０１３２】
まず始めに設計変更の要求が上がる。これは必ずしも設計部門で起こるとは限らない。設計変更の詳細は文書化されて、設計部門の設計変更担当の窓口へと送られる。
【０１３３】
設計部門の窓口で設計変更の要求を受け取ると、その変更を実際に行なうかどうかを決定しなければならない。窓口では変更を行なうかどうかを判断するためのレビュワーを決定し、各レビュワーに対して、該当する図面と変更内容を伝え、実際に変更を行なうかどうかを決定して欲しい旨の依頼をする。
【０１３４】
各レビュワーは送られてきた図面と変更内容を吟味し、実際に変更を行なうかどうかを決定し、集計を行なう担当者に結果を報告する。集計を行なう担当者は各レビュワーから送られてきた結果を元に、実際に変更を行なうか行なわないかを決定する。通常は多数決もしくは全員一致により、変更が決定される。
【０１３５】
変更が行なわれないことが決定したら該当図面と変更要求内容を設計部門に送付し、実際の設計変更を依頼する。また、設計変更を行うことが決定したら該当図面と変更要求内容を設計部門に送付し、実際の設計変更を依頼する。
【０１３６】
設計部門では、該当図面と設計変更要求を受け取ると、設計変更を行なう担当者を決め、実際の設計変更を行なう。
【０１３７】
設計変更が終了すると、変更された図面と要求内容とともに、変更された内容などを記述した書面が添付され、設計部門長宛に送られる。設計部門長は送られてきた図面を承認する。承認を受けた図面は関係各部門に配布される。
【０１３８】
以上のような設計変更プロセスを定義したワークフローの例を図１５を示す。各ステップの機能は以下のように、ワークフローの定義者により定義されている。
【０１３９】
「開始」のステップはワークフローの開始を表す。実際の業務と照らし合わせると、設計変更の要求を上げることに当たる。なお、「開始」のステップは、自動実行ステップの一種である。
【０１４０】
「要求受け付け」のステップは、設計変更を設計部門の窓口の担当者（事務局）が受け取ることを表す。ここで、受け付けられた設計変更の要求に対し、窓口の担当者は該当する図面を添付し、各レビュワーに配布する。
【０１４１】
「レビュー（１）」、「レビュー（２）」、「レビュー（３）」のステップは、それぞれ、設計部門において設計変更を行なうかどうかを判断するためのレビューを行なうステップである。ここでは各レビュワーは送られてきた図面と設計変更の要求を照らし合わせ、実際に設計変更を行なうか、行なわないかを、それぞれ決定する。
【０１４２】
「受理？」のステップは、各レビュワーの結論を集計し、実際に設計変更を行なうか行なわないかの決定を下す。この例では、この「受理？」のステップは、自動実行ステップで、ワークフローシステムが自動的に各レビュワーの結論を集計し、予め設定された規則にそって、設計変更要求を受理するかどうかを決定する。設計変更要求が受理された場合は「設計変更」のステップへと進む。受理されなかった場合は「要求却下」のステップへ進む。
【０１４３】
「要求却下」のステップは、設計変更要求が受理されなかった場合に事後処理を行なうステップである。
【０１４４】
「設計変更」のステップは、実際の設計変更を行なうステップであり、設計部門の担当者に送られる。実際の設計変更は、別のワークフロー、すなわち、サブフローを起動し、より詳細に作業を進めるようにしている。
【０１４５】
「承認」のステップは、設計変更された図面を承認するためのステップである。設計部門長が図面をチェックし、承認印を図面にいれる。
【０１４６】
「設計変更配布」のステップは、変更された図面を関係部門に配布するためのステップである。
【０１４７】
上述したワークフローの定義は、ワークフローシステムの編集機能により行われる。このワークフローの定義時の作業は大きく分けて、
▲１▼ステップの作成
▲２▼ステップの接続
▲３▼ルールの記述
の３つがある。各ステップの作成は各種属性、すなわち、ステップが通常ステップか、自動実行ステップかを表す「タイプ」、ステップの作業内容を示す「名前」、「担当者」（この例では、担当部門）のほか、ルールの設定も含む。この例における各ステップの初期属性値（定義時の属性値）を、図１６から図２６までに示す。
【０１４８】
各ステップを作成したら、流れにそって、前後のステップを接続していく。このステップの作成、接続の作業を繰り返すことによって、ワークフロー全体を作成する。
【０１４９】
必要に応じて、各ステップにはルールを記述する。ルールは、前述したようにアークについて定義することもできるし、また、ステップの各状態ごとに付けることもできる。
【０１５０】
この例では、「レビュー（１）」、「レビュー（２）」、「レビュー（３）」のステップの状態「ｒｕｎ」のルールで、パケットに「投票（＄ｖｏｔｅ）」という名前のブール（ｂｏｏｌｅａｎ）型の変数「投票結果」（後述する図４２参照）のフィールドを追加する。この「レビュー（１）」、「レビュー（２）」、「レビュー（３）」のステップの状態「ｒｕｎ」のルールを図２７に示す。各ステップ「レビュー（１）」、「レビュー（２）」、「レビュー（３）」の担当者は、その変数「投票結果」のフィールドの欄を埋める。
【０１５１】
ワークフローシステムは、各ステップ「レビュー（１）」、「レビュー（２）」、「レビュー（３）」の状態「ｃｏｍｐｌｅｔｅ」のルールでこれの集計を行なう。この「レビュー（１）」、「レビュー（２）」、「レビュー（３）」のステップの状態「ｃｏｍｐｌｅｔｅ」のルールを図２８に示す。ワークフローシステムは、集計を行なった結果を元に、自動実行ステップである次のステップ「受理？」でルーティングを決定する。
【０１５２】
ステップ「受理？」で実行される内容は、図２０において、属性「スクリプト」に示されている。図２０の例の場合の「スクリプト」の内容は、「投票数が２以上のときには、ステップ「設計変更」にルーティングを行い、ステップ「要求却下」にはルーティングを行わず、投票数が２以上でなければ、ステップ「設計変更」にはルーティングを行わず、ステップ「要求却下」にルーティングを行なう」というものである。
【０１５３】
以上のようにしてワークフローの定義を終了したらワークフローの開始を宣言する。ワークフローの開始とは具体的には、定義したワークフローのワークフローシステムへの登録、登録されたワークフローの開始の２段階である。
【０１５４】
図２９にワークフローの定義から起動までの起動者の処理の流れ図を示す。 まず、始めに、あらかじめ登録されている既存のワークフローを検索し（手順Ｓ２１）、その中に、行おうとする業務に適応しているワークフローがあるか否か判断する（手順Ｓ２２）。適応しているワークフローがあれば、そのワークフローが修正の必要があるか否か判断し（手順Ｓ２３）、修正の必要があれば、その修正を行う（手順Ｓ２４）。そして、修正が終了した後、あるいは、修正の必要がなければそのまま、ワークフローをワークフローシステムに登録する（手順Ｓ２５）。
【０１５５】
また、手順Ｓ２２で、あらかじめ登録されている既存のワークフローに、望みのワークフローがなかったときには、新しいワークフローを定義し（手順Ｓ２６）、このワークフローをワークフローシステムに登録する（手順Ｓ２５）。
【０１５６】
以上のようにしてワークフローシステムにワークフローが登録されると、ワークフローシステムは、自動的にワークフローの開始の作業に移る。まず始めに、必要な初期化を行ない、先頭のステップの作業を開始する。
【０１５７】
図３０は、初期化の際のワークフローシステムの処理ルーチンＳ３０の一例のフローチャートである。すなわち、まず、定義されたワークフローのすべてのステップの状態を、「ｎｏｔ ｒｅａｄｙ」に初期化する（処理Ｓ３１）。次に、最初のステップを探し（処理Ｓ３２）、その最初のステップの状態を「ｒｅａｄｙ」にして、この処理ルーチンＳ３０を終了する。
【０１５８】
こうして、ステップの状態が「ｎｏｔ ｒｅａｄｙ」から「ｒｅａｄｙ」になるとき、ワークフローシステムは、状態「ｒｅａｄｙ」時の処理ルーチンＳ４０を実行する。図３１に、この処理ルーチンＳ４０の一例のフローチャートを示す。
【０１５９】
まず、「ｒｅａｄｙ」の状態になったステップについて、「ｒｅａｄｙ」においてのルールがあればそれを実行する（処理Ｓ４１）。ルールの実行が済んだら、当該ステップは自動実行ステップか否か判断し（判断Ｓ４２）、自動実行ステップでなく、通常ステップであれば、その担当者に対して、通知を送って（処理Ｓ４３）、この処理ルーチン４０を終了する。
【０１６０】
また、判断Ｓ４２での判断の結果、自動実行ステップであると判断されたときには、処理Ｓ４４に移って、通知をすることなくステップの状態を「ｒｕｎ」にして、この処理ルーチン４０を終了する。
【０１６１】
「ｒｅａｄｙ」になったステップが通常ステップの場合には、前記通知に対して担当者が作業の開始を宣言するとステップは「ｒｕｎ」の状態となる。自動実行ステップの場合には、前述のように、「ｒｅａｄｙ」から即座に「ｒｕｎ」の状態になる。ステップの状態が「ｒｕｎ」になると、ワークフローシステムは、状態「ｒｕｎ」時の処理ルーチンＳ５０を実行する。図３２は、この処理ルーチンＳ５０の一例のフローチャートである。
【０１６２】
まず、担当者に送るパケットを作成する（処理Ｓ５１）。そして、当該ステップに「ｒｕｎ」状態についてのルールがあれば、それを実行する（処理Ｓ５２）。ルールの実行が済んだら、当該ステップは自動実行ステップか否か判断し（判断Ｓ５３）、自動実行ステップでなく、通常ステップであれば、その担当者に対して、パケットを送って（処理Ｓ５４）、この処理ルーチン５０を終了する。
【０１６３】
また、判断Ｓ５３での判断の結果、自動実行ステップであると判断されたときには、処理Ｓ５５に移って、パケットを送ることなくステップの状態を「ｃｏｍｐｌｅｔｅ」にして、この処理ルーチン５０を終了する。
【０１６４】
ステップが通常ステップの場合には、担当者が終了を宣言すると「ｃｏｍｐｌｅｔｅ」状態になるが、サブフローが当該ステップで実行中は、担当者が終了宣言をしても、ステップの状態は「ｃｏｍｐｌｅｔｅ」にはならない。自動実行ステップの場合には、前述のように、自動実行の作業が終了すると、ワークフローシステム自身が「ｒｕｎ」から「ｃｏｍｐｌｅｔｅ」の状態に移行させる。ステップの状態が「ｃｏｍｐｌｅｔｅ」になるとき、ワークフローシステムは、状態「ｃｏｍｐｌｅｔｅ」に関する処理ルーチンＳ６０を実行する。図３３は、この処理ルーチンＳ６０の一例のフローチャートである。
【０１６５】
まず、サブフローが実行中か否か判断し（処理Ｓ６１）、実行中であればこのルーチンＳ６０をそのまま終了する。前述したように、サブフローが当該ステップで起動されているときには、当該ステップに結び付いているすべてのサブフローが終了しないと当該ステップは、終了できないからである。
【０１６６】
サブフローがすべて終了しているときには、処理Ｓ６２に進んで、当該ステップの状態「ｃｏｍｐｌｅｔｅ」についてルールが定義されていればそのルールを実行する。ルールの実行が済んだら、当該ステップは自動実行ステップか否か判断し（判断Ｓ６３）、自動実行ステップでなく、通常ステップであれば、前述したルーティング（ルーティング後処理およびルーティング前処理）を行い（処理Ｓ６４）、この処理ルーチン６０を終了する。
【０１６７】
また、判断Ｓ６３での判断の結果、自動実行ステップであると判断されたときには、処理Ｓ６５に移って、定義されているスクリプトを実行した後、処理Ｓ６４に移行してルーティングを行った後、この処理ルーチンＳ６０を終了する。以下、最後のステップの作業が終了するまで、以上と同様に繰り返す。
【０１６８】
次に、前述した設計変更のワークフローの例を用いてさらに詳細に説明する。
【０１６９】
＜ワークフローの開始＞
まず始めに、ワークフローの定義者がワークフローシステムに対して、定義したワークフローの登録を行なう。もしくはワークフローは予め定義されており、定義者とは異なる者によりワークフローが登録されることもある。
【０１７０】
この例では、予め定義されていたワークフローを用いて定義者とは異なる者がワークフローをワークフローシステムに登録したものとする。この登録した者は、実際的には設計変更の依頼を行なう人である。この設計変更の依頼者はワークフローの最初の担当者に対して、メッセージを送ることができる。この機能は通常の電子メールに類似の機能である。この例では、ワークフローの起動者は最初のステップの担当者（ここでは「要求受け付け」の担当者、すなわち事務局）に対して、
“部品Ｘの幅を１ｍｍ大きくして欲しいのですが。”
というメッセージを送ったものとする。
【０１７１】
登録が行なわれると、ワークフローシステムは初期化の作業を行なう。図１６〜図２６に示したように、定義されたばかりのステップは状態をもたないが、この初期化により、全てのステップの状態は「ｎｏｔ ｒｅａｄｙ」にされる（例えば図３４参照）。
【０１７２】
ワークフローシステムの初期化が終了すると、先頭のステップが開始される。この例の場合、先頭のステップは「開始」である。「開始」のステップが開始されるということはすなわち、「開始」のステップが「ｒｅａｄｙ」状態になるということである（図３５）。
【０１７３】
ステップが「ｒｅａｄｙ」状態になると、通常、ワークフローシステムはステップの担当者に通知を送る。しかし、「開始」は特殊なステップ（自動実行ステップの一種）であるために、通知は送られず、即座に「ｒｕｎ」状態へと移行する。（図３６）。
【０１７４】
自動実行ステップであれば、この「ｒｕｎ」状態への移行により、定義時に指定された動作を行うのであるが、「開始」は開始を合図するための特殊なステップであるために、この定義がない。したがって、ここでは、何もせずに「ｃｏｍｐｌｅｔｅ」の状態へと移行する（図３７）。
【０１７５】
ステップ「開始」の状態が「ｃｏｍｐｌｅｔｅ」になると、ワークフローシステムはルーティングを開始する。この場合、後続のステップは「要求受け付け」のみであるために、特別なことは行なわず、ステップ「要求受け付け」に対して、ルーティングが行なわれる。
【０１７６】
ステップ「要求受け付け」が「ｒｅａｄｙ」状態になると、このステップの担当者に対して通知が送られる。担当者は、例えば電子メールを読むような感覚で通知を受け取る。この通知の例を図３８に示す。
【０１７７】
この通知を受け取った担当者が開始の合図をワークフローシステムに対して送ると、ワークフローシステムからそのステップの作業を行なうために必要な情報などを織り込んだパケット（図３９参照）が送り返される。このパケットには、後続の３つのステップ「レビュー（１）」「レビュー（２）」「レビュー（３）」へのルーティングを決定するためのルーティング情報が付加されている。
【０１７８】
担当者はパケットの中の情報を元に要求された作業を行なう。ステップ「要求受け付け」の作業は要求内容を確認し、設計変更を依頼された部品の図面を集め、設計部門のレビュー担当者に対して、レビューを依頼することである。この作業に関する記述は予めワークフローを定義した定義者によって定義されており、前記通知のなかの、図３８の例では「Ｄｅｓｃｒｉｐｔｉｏｎ：」フィールドに、作業内容として織り込まれている。通知には、この他に、ワークフローの起動者からのメッセージが、図３８に示すように、「Ｃｏｍｍｅｎｔ：」フィールドに含まれている。
【０１７９】
「要求受け付け」の担当者は、「Ｄｅｓｃｒｉｐｔｉｏｎ：」フィールドと、「Ｃｏｍｍｅｎｔ：」フィールドのふたつの記述を元に、必要な図面を集め、パケットに添付する。ここでは設計変更の要求は部品Ｘについてなので、担当者は部品Ｘの図面を探し出しパケットに加える。
【０１８０】
次にレビューを担当する担当者を決める。この例ではレビュー担当者は３人定義されている。通常は全員の投票によってレビューが行なわれるため、ステップ「要求受け付け」の担当者に送られるパケットに含まれているルーティング情報の各レビュワーに対応する真理値の値は、ワークフローシステムにより全て「真（ｔｒｕｅ）」に初期化されている。
【０１８１】
今、例えばステップ「要求受け付け」の担当者が、特にレビュワーの変更の必要がないと判断した場合には、ルーティング情報の真理値は変更しない。このため、パケットのルーティング情報は、変更されずに、システムに送り返される。また、このとき、担当者は各レビュワーに送るコメントを記述し、パケットに含める。この例の場合の作業終了結果のパケットは図４０に示すようなものとなる。
【０１８２】
ワークフローシステムは、このパケットを受け取ると、ルーティング情報をチェックする。この例では、ルーティング情報の中身は全て「真」であるため、全ての後続のステップに対してルーティングが行なわれる。
【０１８３】
「レビュー（１）」が「ｒｅａｄｙ」状態になると「レビュー（１）」の担当者に対して、通知が送られる。この通知には「要求受け付け」の担当者が記入したコメントが書かれている（図４１参照）。
【０１８４】
「レビュー（１）」の担当者は、この通知を読み、開始を宣言する。このとき、「レビュー（１）」のステップには、図２７に例示したように、ルールが定義されているため、パケットを担当者に送信する前に、ワークフローシステムはそのルールを実行する。その結果、担当者に送られるパケットには、図４２に示すように、投票用のフィールド「投票結果」が追加される。
【０１８５】
ルールの実行が終わると、ワークフローシステムより図４２に示したパケットが送られる。このパケットの中には「要求受け付け」の担当者が追加した図面が含まれている。また、ステップ「レビュー（１）」の後ろにはひとつしかステップがないため、ルーティング情報は空になっている。すなわち、ステップ「レビュー（１）」の担当者はルーティングを指示することはできない。
【０１８６】
ステップ「レビュー（１）」の担当者は、ステップ「要求受け付け」の担当者からのコメントに従い、送られてきた図面と設計変更要求をチェックし、実際に設計変更を行なうべきか、行なわないべきかを決め、パケットの投票用のフィールド「投票結果」に自分の判断をｙｅｓ／ｎｏ形式で記入する。例えば、ステップ「レビュー（１）」の担当者が「ｙｅｓ」と投票し、所定のコメントを記述したとすると、パケットは、図４３に示すようなものとなる。
【０１８７】
こうして作業が終了したステップ「レビュー（１）」の担当者は、自分の意見を含めたパケット（図４３）とともに、作業の完了をワークフローシステムに通知する。この時、ステップ「レビュー（２）」とステップ「レビュー（３）」が、まだ終了していない場合には、ワークフローシステムは、ルーティング後処理において、次のステップ「受理？」について、スタートフラグを立てるだけで処理を終了する。
【０１８８】
また、このとき、ステップ「レビュー（１）」には、図２８に例示したように、「ｃｏｍｐｌｅｔｅ」時のルールも定義されているため、これが実行される。実行された結果、「投票結果」のフィールドが「ｙｅｓ」であるため、「＄ｖｏｔｅ」という変数がインクリメントされる。この結果「＄ｖｏｔｅ」という変数の値は１となる。
【０１８９】
ステップ「レビュー（２）」の動作は、ステップ「レビュー（１）」と同様である。ただし、この例では、ステップ「レビュー（２）」の担当者は設計変更に非同意で、投票用のフィールド「投票結果」に「ｎｏ」と記入し、コメントを付加したとする。このステップ「レビュー（２）」の終了時のパケットの例を図４４に示す。
【０１９０】
作業が終了したステップ「レビュー（２）」の担当者は、自分の意見を含めたパケット（図４４）とともに、作業の完了をワークフローシステムに通知する。ここで、未だ、ステップ「レビュー（３）」が終了していないとすると、ワークフローシステムは、図１４に示したルーティング後処理の処理ルーチンＳ１００において、「受理？」ステップのスタートフラグを立てる（実際にはすでに立っているが）だけで処理を終了する。
【０１９１】
また、ステップ「レビュー（２）」の「ｃｏｍｐｌｅｔｅ」時のルールが実行されるが、「投票結果」のフィールドが「ｎｏ」であるため、変数「＄ｖｏｔｅ」はインクリメントされず、その値は１のままである。
【０１９２】
ステップ「レビュー（３）」の動作も、ステップ「レビュー（１）」と同様である。ただし、この例では、ステップ「レビュー（３）」では担当者は設計変更に同意で、投票用のフィールド「投票結果」に「ｙｅｓ」を記入し、コメントを付加したものとする。
【０１９３】
作業が終了すると、ステップ「レビュー（３）」の担当者は、自分の意見を含めたパケットとともに、作業の完了をワークフローシステムに通知する。ここで、全てのレビューが終了したため、「受理？」ステップは作業を開始することが可能となる。すなわち、ワークフローシステムは、ルーティング後処理において、「受理？」ステップはスタートフラグが立っているため、状態「ｉｓｏｌａｔｅ」とはせずに、「ｒｅａｄｙ」状態とする。
【０１９４】
また、ステップ「レビュー（３）」の「ｃｏｍｐｌｅｔｅ」時のルールが実行される。ここでは、「投票結果」のフィールド値が「ｙｅｓ」であったため、変数「＄ｖｏｔｅ」はインクリメントされ、値は２となる。
【０１９５】
ステップ「受理？」は、この例では、自動実行ステップである。この例では、図２０に例示したように、上流の３つのステップ「レビュー（１）」「レビュー（２）」「レビュー（３）」の投票結果を集計し、その結果によってルーティングを変更するためのスクリプトが予め定義してある。
【０１９６】
前述したように、ここで定義されているスクリプトは、上流の各レビュワーから返された投票結果を集計し、多数決を行なうもので、設計変更を行なうことに対し、「ｙｅｓ」が勝った場合は、ステップ「要求却下」にはルーティングを行なわずに、ステップ「設計変更」にルーティングを行ない、逆に「ｎｏ」が勝った場合は、ステップ「要求却下」にルーティングを行ない、ステップ「設計変更」にルーティングを行なわないという内容である。
【０１９７】
具体的には、各レビュワーのステップの状態「ｃｏｍｐｌｅｔｅ」時に実行されたルールにより設定された変数「＄ｖｏｔｅ」の値を参照し、２以上であればステップ「設計変更」に対するルーティング情報フィールドの真理値を「真」とし、ステップ「要求却下」に対するルーティング情報フィールドの真理値を「偽」とする。逆に、変数「＄ｖｏｔｅ」の値が２未満の場合は、ステップ「設計変更」に対するルーティング情報フィールドの真理値を「偽」とし、ステップ「要求却下」に対するルーティング情報フィールドの真理値を「真」とする。
【０１９８】
この例の場合は、変数「＄ｖｏｔｅ」の値は２であるために、ステップ「設計変更」に対するルーティング情報フィールドの真理値が「真」とされ、ステップ「要求却下」の真理値は「偽」とされる。
【０１９９】
スクリプトの実行が終了すると、ステップ「受理？」は、終了し、「ｃｏｍｐｌｅｔｅ」の状態になる。すると、図１４に示したルーティング後処理のルーチンＳ１００が実行され、ルーティング情報フィールドの真理値が参照されることにより、ステップ「受理？」のスクリプト通りのルーティング結果が得られる。すなわち、この例の場合には、ステップ「設計変更」は「ｒｅａｄｙ」状態となり、ステップ「要求却下」は「ｉｓｏｌａｔｅ」状態となる。
【０２００】
この例の場合、ステップ「設計変更」の担当者は自分の作業をより詳細化し、サブフローを起動する。すなわち、設計変更の担当者は要求されている設計変更を行なうためにもっともふさわしいと思われるワークフローを選び、または、新たに定義し、それを現在動いているワークフローのサブフローとして起動する。このサブフローが終了しない限り、「設計変更」ステップは終了することができない。
【０２０１】
このサブフローの例を図４５に示す。この例のサブフローは、すべて通常ステップからなり、最初のステップは、設計変更のための「仕様作成」のステップであり、担当者は、設計リーダーである。次のステップは、実際に設計図を作成する「設計」のステップであり、担当者は設計者である。次のステップは、最後のステップであり、設計者の作成した設計図の検査する「検図」のステップである。
【０２０２】
このサブフローも、上述したワークフローと、まったく同様にして作業が行われてゆく。このサブフローの管理も、同じワークフローシステムで行ってもよいが、別のワークフローシステムにより、サブフローの実行管理を行わせるようにすることも、もちろんできる。サブフローの最後のステップが終了して、その最後のステップの担当者から作業終了の合図があったときに、これが結び付いているステップ「設計変更」を、担当者が終了として、ワークフローシステムにその通知をすることができる。なお、サブフローが複数個、ステップについて定義された場合には、すべてのサブフローが終了するまで、当該サブフローが結び付いているステップは作業を終了とすることができない。
【０２０３】
この例の場合には、ステップ「設計変更」の担当者は、自分が起動したサブフローが終了すると、サブフローにおいて実際に変更された図面をパケットに戻し、作業を終了する。
【０２０４】
ステップ「設計変更」の次のステップ「承認」では、変更された図面の承認を行なう。具体的には変更された図面に承認印を押す。
【０２０５】
次のステップ「設計変更配布」では、この実施例においては、「設計変更」と同様サブフローを起動する。こうすることにより、どのような配布形態をとるか柔軟に決定することができる。
【０２０６】
図４６に、この例のステップ「設計変更配布」について定義されたサブフローの例を示す。この例のサブフローは、３つの自動実行ステップが、並行に実行されるワークフローである。自動実行ステップ「出図」は、例えばプリンタにより設計変更図面を印刷させて図面を出力させるものであり、自動実行ステップ「保管」は、設計変更図面をファイルに格納しておくものであり、自動実行ステップ「ＦＡＸ」は、ファクシミリ装置によって、設計変更図面を所定の宛先に配送するものである。
【０２０７】
このように、あるステップで起動されるサブフローのすべてを、自動実行ステップで構成することによって、定型業務を大幅に改善することができる。
【０２０８】
この例のワークフローシステムは、これらの作業のためのハードウエアとしてのプリンタ、ファイリング装置、ファクシミリ装置を内蔵している。もっとも、ＬＡＮなどのネットワークを通じて、それぞれのハードウエアに対してワークフローシステムより処理要求を出して、処理を行わせるようにすることも勿論できる。
【０２０９】
この場合、ステップ「設計変更配布」が「ｒｅａｄｙ」状態になると、即座に「ｒｕｎ」状態となり、図４６のサブフローが起動されると、自動的に３つの自動実行ステップ「出図」「保管」「ＦＡＸ」が開始して、それぞれの作業を自動的に行う。
【０２１０】
そして、すべての自動実行ステップの作業の終了を待って、ステップ「設計変更配布」の担当者「事務局」が終了の通知を出すと、このステップ「設計変更配布」の状態は「ｃｏｍｐｌｅｔｅ」になる。一方、ステップ「要求却下」は、前述したように、「ｉｓｏｌａｔｅ」になっているので、以上で、設計変更のワークフローは、終了する。
【０２１１】
なお、「受理？」のステップで、ステップ「設計変更」にはルーティングは行なわないと決定されたときには、ステップ「設計変更」の状態は、「ｉｓｏｌａｔｅ」の状態になり、かつ、図１４のルーティング後処理のルーチンＳ１００の処理Ｓ２１として説明されているように、その後続のステップ「承認」、ステップ「設計変更配布」について、再帰的に「ｉｓｏｌａｔｅ」の状態に移行させる処理を行なう。
【０２１２】
したがって、ステップ「要求却下」の作業が終了して状態「ｃｏｍｐｌｅｔｅ」になったとき、ステップ「設計変更配布」の状態は、「ｉｓｏｌａｔｅ」になっているので、設計変更のワークフローは終了する。
【０２１３】
上述のように、この例の設計変更のワークフローにおいては、ステップ「要求受け付け」の担当者は、パケットに付加されているルーティング情報のフィールドの真理値を変更することができ、その変更により、その後続のステップ「レビュー（１）」「レビュー（２）」「レビュー（３）」のそれぞれに対してルーティングを行うか否かを決定することが可能である。ただし、上述の例では、ステップ「レビュー（１）」「レビュー（２）」「レビュー（３）」のすべてにルーティングを行うと担当者が決定したので、担当者によるルーティング情報の変更は行われず、デフォルトの真理値「真」はそのままとされた。
【０２１４】
また、この例の設計変更のワークフローにおいては、ステップ「受理？」を自動実行ステップで構成し、その作業内容をあらかじめ定義したスクリプトにより、ステップ「レビュー（１）」「レビュー（２）」「レビュー（３）」の担当者が、その状態「ｒｕｎ」のルールで追加された投票用のフィールド「投票結果」に記入した投票結果を集計し、その結果によって下流のステップのルーティングを決定することができる。すなわち、前ステップの担当者が行った作業内容に基づいて演算を行うなどの比較的複雑なルーティングの決定が可能になる。
【０２１５】
また、「設計変更」のステップでは、担当者が自分の作業をより詳細化し、サブフローを起動して作業を実行するようにしたので、親のワークフロー中には、設計変更のプロセスを詳細に記述する必要がない。そして、担当者が起動するサブフローを定義することができるので、ワークフローの作業の流れを柔軟に設計することができる。
【０２１６】
さらに、上述の例のステップ「設計変更配布」のように、ステップをすべて自動実行ステップからなるサブフローで構成することにより、定型業務の作業負荷を大幅に改善することができる。
【０２１７】
また、前述もしたように、ルールは、各作業工程の状態や、自動実行ステップの処理内容（スクリプト）として定義されていて、各ステップの状態において実行されるので、第１の実施例の場合のように、ルーティング後処理においてルールを実行する必要がない。そして、図１４に示したようなルーティング後処理の実行により、担当者によるルーティングの決定と、ワークフローシステムによるルーティングの決定とを、行なうことができる。
【０２１８】
なお、サブフローが結び付く親ワークフローのステップを自動実行ステップで構成し、その自動実行ステップで行う作業をソフトウエアで実行させると共に、そのソフトウエアによってサブフローを定義して、自動的にサブフローを起動させるようにすれば、親ワークフローの前記自動実行ステップにルーティングが行われたとき、サブフローが自動的に起動されてその作業が開始され、担当者がサブフローを起動する必要がない。
【０２１９】
なお、以上の例では、自動実行ステップでルーティング情報フィールドの真理値を書き換えて、後続のステップのルーティングを決定するようにしたが、ステップの状態が「ｒｅａｄｙ」「ｒｕｎ」「ｃｏｍｐｌｅｔｅ」になったときに実行されるルールによりパケットのルーティング情報フィールドの書き換えを行なうようにすることもできる。
【０２２０】
以上説明したように、第１の例のルーティング決定方法によれば、各作業工程に対して与える作業に必要な情報の塊の中に、その作業工程の後続の作業工程に作業を開始させるか否かを決定するための付加情報フィールドを追加し、この追加された付加情報フィールドの内容を用いて後続の作業工程に作業を開始させるか否かを決定するようにしたので、作業の分岐があったときに、分岐後のいずれの作業工程に仕事を開始させるかを容易に決定することができる。
【０２２１】
また、前記の後続の作業工程に作業を開始させるか否かを決定するために追加された付加情報フィールドには、作業工程の担当者が記入することができるので、後続の作業工程に仕事を開始させるか否かの決定に、作業担当者の要求を反映することができ、仕事の流れを作業担当者の要求に応じて柔軟に変更することができる。
【０２２２】
また、第２の例のルーティング決定方法によれば、作業工程について定義されたルールが実行されて、その結果により、前記付加情報フィールドに後続の作業工程に作業を実行させるか否かの情報が記述され、その付加情報フィールドの記述に従ってルーティングが決定されるので、情報処理システム自身が作業工程の作業結果を反映したルーティングの決定をすることができる。しかも、ルーティングのための付加情報フィールドの内容を参照するのは、担当者による場合も同じであり、ルーティングの決定のためのソフトウエアを簡略化することができる。
【０２２３】
また、上述の例によれば、あらかじめ定義された約束事などにより前の作業工程の処理結果の評価を行って、後続の作業工程に仕事を開始させるか否かを決定することが可能となり、作業工程における作業結果を、作業の流れ管理に反映させることができる。例えば作業工程で計算された見積もりに応じて後続の作業の流れを変更したりすることができる。この場合には、ルーティングのための特別の情報フィールドを参照する必要がない。
【０２２４】
また、上述の例によれば、分岐の作業工程があるときに、仕事が開始されなかった作業工程は、作業の流れから切り離されたことを示す切り離し状態として、その作業工程の終了状態を管理するようにしたので、分岐後の合流が支障なく、行なわれる。
【０２２５】
また、上述の例によれば、担当者を定めずに機械に作業を実行させる自動実行作業工程を定義し、この自動実行作業工程も、他の通常の担当者が定められる作業工程と同様に状態管理するようにしたので、この自動実行作業工程をワークフローの中に適宜挿入することができ、作業の効率化を計ることができる。
【０２２６】
【発明の効果】
以上説明したように、この発明によれば、各作業工程の担当者は、当該作業工程においてサブフローを定義して起動することができるので、作業の流れの定義時に各作業工程を詳細に定義する必要はない。また、サブフローを用いることにより、すべての作業工程を詳細に定義する場合に比べて、より柔軟に様々な局面に対して対応することが可能になる。
【図面の簡単な説明】
【図１】この発明による情報処理システムの一実施形態の要部の機能ブロック図である。
【図２】この発明による情報処理システムの一実施形態の概要を示すブロック図である。
【図３】この発明による情報処理システムの一実施形態における処理動作の例のフローチャートである。
【図４】この発明による情報処理システムの実施形態における処理動作の例のフローチャートである。
【図５】この発明による情報処理システムの実施形態が適用される作業の流れの例を示す図である。
【図６】図５の例の作業の流れを構成する各ステップに関するデータの例を示す図である。
【図７】図５の例の作業の流れを構成する各ステップのつながりを表すデータの例を示す図である。
【図８】図５の例のステップ１の担当者に送られるデータの塊の例を示す図である。
【図９】図５の例のステップ１の担当者からの作業結果のデータの塊の例を示す図である。
【図１０】図５の例のステップ１からステップ２へのつながりについて定義されたルールの例を示す図である。
【図１１】図５の例のステップ１からステップ３へのつながりについて定義されたルールの例を示す図である。
【図１２】図５の例のステップ１の担当者に送られるデータの塊の他の例を示す図である。
【図１３】図５の例のステップ１の担当者からの作業結果のデータの塊の他の例を示す図である。
【図１４】この発明による情報処理システムの実施形態における処理動作の例のフローチャートである。
【図１５】この発明による情報処理システムの実施形態が適用される作業の流れの例を示す図である。
【図１６】図１５の例のステップ「開始」の定義時の属性値の例を示す図である。
【図１７】図１５の例のステップ「要求受け付け」の定義時の属性値の例を示す図である。
【図１８】図１５の例のステップ「レビュー（１）」の定義時の属性値の例を示す図である。
【図１９】図１５の例のステップ「レビュー（２）」の定義時の属性値の例を示す図である。
【図２０】図１５の例のステップ「レビュー（３）」の定義時の属性値の例を示す図である。
【図２１】図１５の例のステップ「受理？」の定義時の属性値の例を示す図である。
【図２２】図１５の例のステップ「設計変更」の定義時の属性値の例を示す図である。
【図２３】図１５の例のステップ「承認」の定義時の属性値の例を示す図である。
【図２４】図１５の例のステップ「設計変更配布」の定義時の属性値の例を示す図である。
【図２５】図１５の例のステップ「要求却下」の定義時の属性値の例を示す図である。
【図２６】図１５の例のステップ「終了」の定義時の属性値の例を示す図である。
【図２７】図１５の例のステップ「レビュー（１）」の状態「ｒｕｎ」のときのルールの例を示す図である。
【図２８】図１５の例のステップ「レビュー（１）」の状態「ｃｏｍｐｌｅｔｅ」のときのルールの例を示す図である。
【図２９】この発明による情報処理システムの実施形態におけるワークフローの定義時の処理の流れの例を示すフローチャートである。
【図３０】この発明による情報処理システムの実施形態におけるワークフローの初期化処理の流れの例を示すフローチャートである。
【図３１】この発明による情報処理システムの実施形態において、ステップの状態が「ｒｅａｄｙ」になったときの処理の流れの例を示すフローチャートである。
【図３２】この発明による情報処理システムの実施形態において、ステップの状態が「ｒｕｎ」になったときの処理の流れの例を示すフローチャートである。
【図３３】この発明による情報処理システムの実施形態において、ステップの状態が「ｃｏｍｐｌｅｔｅ」になったときの処理の流れの例を示すフローチャートである。
【図３４】図１５の例のステップ「開始」の登録時の属性値の例を示す図である。
【図３５】図１５の例のステップ「開始」の開始時の属性値の例を示す図である。
【図３６】図１５の例のステップ「開始」の状態「ｒｕｎ」時の属性値の例を示す図である。
【図３７】図１５の例のステップ「開始」の状態「ｃｏｍｐｌｅｔｅ」時の属性値の例を示す図である。
【図３８】図１５の例のステップ「要求受け付け」の担当者に対する通知の例を示す図である。
【図３９】図１５の例のステップ「要求受け付け」の開始の際に、担当者に対して与えられる情報の塊の例を示す図である。
【図４０】図１５の例のステップ「要求受け付け」の担当者から、その終了時に送られてくる情報の塊の例を示す図である。
【図４１】図１５の例のステップ「レビュー（１）」の担当者に対する通知の例を示す図である。
【図４２】図１５の例のステップ「レビュー（１）」の開始の際に、担当者に対して与えられる情報の塊の例を示す図である。
【図４３】図１５の例のステップ「レビュー（１）」の担当者から、その終了時に送られてくる情報の塊の例を示す図である。
【図４４】図１５の例のステップ「レビュー（２）」の担当者から、その終了時に送られてくる情報の塊の例を示す図である。
【図４５】図１５の例のステップ「設計変更」において起動されるサブフローの例を示す図である。
【図４６】図１５の例のステップ「設計変更配布」において起動されるサブフローの例を示す図である。
【図４７】ワークフローの一例を示す図である。
【符号の説明】
１０ ユーザインターフェース部
１１ テンプレート管理部
１２ ルーティング管理部
１３ 通知管理部
１４ 進捗情報管理部
１５ ユーザ管理部
１７ 参照情報管理部
２０ システム部
２１ 編集部
２２ 通知部
３１ ステップ状態管理部
３１Ｍ ステップ状態メモリ
３２ ルーティング前処理部
３３ ルーティング後処理部
３４ ルール評価部

Claims (4)

1. 順序立てて処理すべき作業が複数個の作業工程に分けられ、その複数個の作業工程の順序と、各作業工程の処理内容とを記憶する記憶手段と、
   前記作業工程の開始通知および前記作業工程の終了通知を受け取る通知管理手段と、
   前記通知管理手段を通じた前記作業工程の開始通知および前記作業工程の終了通知と、前記記憶手段に記憶された前記複数個の作業工程の順序にしたがって次に開始させる次作業工程を決定するルーティング管理手段と、
   を備える情報処理システムにおいて、
   前記ルーティング管理手段は、
   前記次作業工程に、当該次作業工程の作業を細分化した作業の単位と、その細分化した作業の単位の前後のつながりとからなるサブフローが結び付けられて定義されていると判断したときに、前記通知管理手段を通じた前記開始通知に基づき前記サブフローを起動するサブフロー起動手段と、
   前記サブフロー起動手段により起動されたサブフローが結び付けられて定義されている前記次作業工程の前記終了通知を前記通知管理手段を通じて受けたときに、前記サブフローが実行中であるか否かを判別し、実行中でなく終了していると判別したときに、前記次作業工程を決定する処理を行なうルーティング手段と、
   を備えることを特徴とする情報処理システム。
2. 請求項１に記載の情報処理システムにおいて、
   前記ルーティング手段は、
   前記次作業工程に結び付けられて定義されている前記サブフローが複数個である場合には、前記複数のサブフローによる作業が全て完了したときに、前記次作業工程を決定する処理を行なう
   ことを特徴とする情報処理システム。
3. 請求項１または請求項２に記載の情報処理システムにおいて、
   前記サブフローは、機械が作業を実行する自動実行ステップのみで構成されていることを特徴とする情報処理システム。
4. 順序立てて処理すべき作業が複数個の作業工程に分けられ、その複数個の作業工程の順序と、各作業工程の処理内容とを記憶する記憶手段と、
   前記作業工程の開始通知および前記作業工程の終了通知を受け取る通知管理手段と、
   前記通知管理手段を通じた前記作業工程の開始通知および前記作業工程の終了通知と、前記記憶手段に記憶された前記複数個の作業工程の順序にしたがって次に開始させる次作業工程を決定するルーティング管理手段と、
   を備える情報処理システムによる作業の流れ管理方法において、
   前記ルーティング管理手段は、
   前記次作業工程に、当該次作業工程の作業を細分化した作業の単位と、その細分化した作業の単位の前後のつながりとからなるサブフローが結び付けられて定義されていると判断したときに、前記通知管理手段を通じた前記開始通知に基づき前記サブフローを起動するサブフロー起動工程と、
   前記サブフロー起動工程で起動されたサブフローが結び付けられて定義されている前記次作業工程の前記終了通知を前記通知管理手段を通じて受けたときに、前記サブフローが実行中であるか否かを判別し、実行中でなく終了していると判別したときに、前記次作業工程を決定する処理を行なうルーティング工程と、
   を備えることを特徴とする情報処理システムによる作業の流れ管理方法。

Images