JP2002099686A - ワークフローシステム、情報処理装置、ワークフロー定義方法、記憶媒体、およびプログラム伝送装置 - Google Patents

Abstract

(57)【要約】 【課題】 例えば回覧経路が部門毎に異なる複数部門の
回覧等、複雑なワークフローを単純な定義によって実現
する。 【解決手段】 ネットワークに接続され、担当者の間で
ワークフローを実行するための操作用コンピュータ端末
２０と、扱われる処理の単位であるノードに対して複数
の経路を多重化するためのプロジェクト変数を指定して
ワークフローを設計する設計用コンピュータ端末１０
と、設計されたワークフローを管理すると共に、ノード
に割り当てられた処理であるアクティビティに対応して
操作用コンピュータ端末２０にアクセスするワークフロ
ーサーバ３０とを備えたワークフローシステム。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、オフィスにおける
ワークフローの改善に係り、特に、動的に経路を変更で
きるワークフローシステム等に関する。

【０００２】

【従来の技術】オフィスにおける事務処理の効率化、フ
ァイルキャビネットのスペースコストの問題、環境問題
等から、伝票処理を電子化して、ペーパーレスな帳票処
理システムを構築することの必要性が提唱されて久し
い。しかしながら、実際の伝票処理は複雑であり、更に
例外処理に対する対応の問題などから、ペーパーレスな
帳票処理システムは、未だ十分に普及されているとは言
い得ない。また、多数の伝票を電子化するために、伝票
定義や経路定義の簡単さが要求され、現実にフィットし
た承認システムとするための柔軟な経路指定の機能が要
求されている。

【０００３】ここで、ワークフローシステムに関する従
来技術として、例えば、特開平１０−４９６０３号公
報、特開平１０−１７７６１０号公報、特開平５−２１
６７３６号公報が存在する。この特開平１０−４９６０
３号公報には、異なるプロセス間の回覧、即ち、プロセ
スＡからプロセスＢへデータを回覧する場合に、プロセ
スＡで定義されるデータはプロセスＢでは読み取ること
ができないように設定することで、秘密事項の漏洩を防
ぐ技術について開示されている。また、特開平１０−１
７７６１０号公報には、複数の担当者における処理を規
定して各担当者間でデータを受け渡すワークフローシス
テムにて、次の担当者に処理を割り付ける前に規定され
たデータ変換を実行することで、各担当者にその業務処
理の内容に応じて形式の異なる文書を送る等、業務処理
の簡素化を図る技術について示されている。また、特開
平５−２１６７３６号公報には、電子化された文書(伝
票)の処理先が文書や発行者によって異なる場合に、組
織を表現するディレクトリを参照することによって、処
理すべき文書に依存した経路ルールと送付先を決定する
技術について開示されている。

【０００４】

【発明が解決しようとする課題】このように、従来のワ
ークフローシステムでは、データの値によって回覧経路
を動的に変更するために、個々の担当者をデータ参照に
より決定するような経路や、固定された外部のワークフ
ロー定義を指定するような経路の定義は可能であった。
しかしながら、担当部門を動的に指定するような業務は
一般的ではあるものの、それぞれの部門内での回覧経路
が部門毎に異なる場合や、その最大回覧部門数を考慮し
たワークフローを定義する必要があった。

【０００５】また、担当者レベルの動的経路や、固定さ
れた外部経路と条件分岐を用いたワークフロー定義で
は、最大回覧部門数が大きくなればなるほど、その経路
は複雑で巨大なものとなってしまい、フロー条件の組み
合わせを考慮すると、正しい定義をすることさえ困難と
なる。例えば、ワークフローシステムの一つである電子
帳票承認システムにおいて、稟議を回す場合に、多くの
部門を並列に回し、全ての部門の承認をもって次の承認
に進むケースがよくある。ところが、部門によって承認
のパターンは様々な上に、案件によってどの部門に回す
かが異なり、例えば、最大、数十部門を回す伝票も現わ
れている。

【０００６】更に、従来、文字や数値によるデータを定
義し、そのデータの値を参照または設定するようなアク
ティビティを実現する画面を開発する場合に、専用の開
発ツールなどを用いて画面入力項目とデータ名とを関連
付ける作業が行われていた。しかしながら、例えば、上
述のように数十部門を回すような伝票、および承認経路
を設計する場合に、最大数の部門を想定してワークフロ
ーを設計する必要がある。そのため、その設計画面が巨
大かつ複雑となり、ユーザオペレーションが複雑になる
だけではなく、組織変更に対応するための設計変更のコ
ストが多大となっていた。また、指定した担当者によっ
て経路を切り替えるような複雑な動的変更をワークフロ
ーに加えるためには、専用のプログラムを開発し、ワー
クフローの途中で実行させる必要があった。

【０００７】本発明は、以上のような技術的課題を解決
するためになされたものであって、その目的とするとこ
ろは、例えば回覧経路が部門毎に異なる複数部門の回覧
等、複雑なワークフローを、単純な定義によって実現す
ることにある。また他の目的は、ワークフローの途中で
実行させるような専用のプログラムを開発しない場合で
あっても、複雑な経路パターンの組み合わせに対応させ
ることにある。

【０００８】

【課題を解決するための手段】かかる目的のもと、本発
明は、経路定義において、ノードとしてプロジェクト変
数を指定させることで、ダイナミックにサブ経路を変更
する仕組みを実現しており、また、プロジェクト変数に
配列型の変数を指定させることで、同期タイプの並列経
路を１つのノードで多重化して扱うことを可能としてい
る。即ち、本発明は、複数のコンピュータ端末が接続さ
れるネットワークにおいて、ワークフローに従ってコン
ピュータ端末を利用する担当者の間でデータの受け渡し
を行うワークフローシステムであって、担当者に割り当
てられる処理であるノードとこのノードの処理順を決定
するためのパスとを定めたワークフロー定義およびこの
ワークフロー定義で参照されるデータ定義からなるプロ
ジェクトを作成してワークフローを設計する設計手段
と、作成されたプロジェクトを記憶する記憶手段と、記
憶されたプロジェクトを用いてワークフローの業務単位
であるプロセスを作成して担当者に対して処理を割り当
てる管理手段とを備えたことを特徴としている。

【０００９】ここで、このデータ定義では、データとし
てプロジェクト型およびその配列が定義されることを特
徴としている。また、この設計手段は、配列の個々の要
素が異なる種類のプロジェクトを扱ってワークフローを
設計することを特徴とすれば、複雑な定義からなるワー
クフローを、プロジェクトを用いた極めてシンプルな定
義によって提供できる点で好ましい。

【００１０】他の観点から把えると、本発明が適用され
るワークフローシステムでは、ネットワークに接続さ
れ、担当者の間でワークフローを実行するための操作用
コンピュータ端末と、扱われる処理の単位であるノード
に対して複数のプロセスを多重化するためのプロジェク
ト変数を指定してワークフローを設計する設計用コンピ
ュータ端末と、設計されたワークフローを管理すると共
に、ノードに割り当てられた処理であるアクティビティ
に対応して操作用コンピュータ端末にアクセスするワー
クフローサーバとを備えたことを特徴している。ここで
「プロセス」とは、ワークフローの業務単位であり、例え
ば、「８月業務報告」と「９月業務報告」とは異なるプロセ
スであるが、同じ「業務報告」というプロジェクトとな
る。従って、この場合、経路パターンは同じであるが、
データの内容が異なってくる。これは、同じプロジェク
トで異なるプロセスの例だが、ノードで多重化されるプ
ロセスは、異なるプロジェクトの異なるプロセスであっ
ても良い。

【００１１】ここで、このプロジェクト変数は、ノード
とこのノードの処理順を決定するためのパスとを定めた
ワークフロー定義およびこのワークフロー定義で参照さ
れるデータ定義とを用いて指定されることを特徴とすれ
ば、例えば、経路やフィールド定義といったリソースを
決定する際に有用となる。また、このプロジェクト変数
は、自己を識別するための定義ＩＤを属性として定義さ
れ、このワークフローサーバは、この定義ＩＤを用いて
プロジェクト変数に関する情報を記憶することを特徴と
すれば、プロジェクトで別のプロジェクトの経路やフィ
ールドといったリソースを再利用する際にも、プロジェ
クトを一意に選定できる点で好ましい。更に、操作用コ
ンピュータ端末は、割り当てられた処理の実行後にアク
ティビティの終了をワークフローサーバに通知し、ワー
クフローサーバは、ワークフローによる全てのアクティ
ビティを終了した後にプロセスを完了することを特徴と
している。

【００１２】一方、本発明は、ワークフローを実行する
複数のコンピュータ端末に対してネットワークを介して
接続されるワークフローサーバ等の情報処理装置であっ
て、複数のノードとそれらを結ぶパスとで構成されたワ
ークフロー定義およびこのワークフロー定義で参照され
るデータ定義を含めたプロジェクトを、このプロジェク
トを一意に定める定義ＩＤを用いて管理するプロジェク
ト管理手段と、管理されるこのプロジェクトを用いてワ
ークフローの業務単位であるプロセスを管理するプロセ
ス管理手段と、管理されるプロセスに基づいてコンピュ
ータ端末に対してアクセスするユーザ管理手段とを備え
たことを特徴としている。

【００１３】また、本発明は、ネットワークに接続され
た複数のコンピュータ端末によるワークフローを定義す
るコンピュータ端末等からなる情報処理装置であって、
ワークフローの実行担当者に対して割り当てられる業務
であるノードを選定し、ノードの処理順を決めるパスを
つないでワークフロー定義を決定するワークフロー定義
決定手段と、選定されたノードの実行ユーザを定義する
と共に、パスが有効となる条件を定義するデータ定義手
段と、決定されたワークフロー定義および定義されたデ
ータ定義に対し、これらを特定できる情報として、例え
ば、ワークフロー定義とデータ定義とをまとめた単位で
あるプロジェクトに対して、これを一意に特定できる定
義ＩＤを付加して登録させる登録指示手段とを備えたこ
とを特徴としている。

【００１４】更に、本発明は、ネットワークに接続され
た複数のコンピュータ端末によるワークフローを定義す
るためのワークフロー定義方法であって、ワークフロー
の実行担当者に対して割り当てられる業務であるノード
を選定し、選定されるノードの１つとしてプロセス、経
路パターンおよびデータセットを多重化するためのプロ
ジェクト配列型ノードを選定し、選定されるノードおよ
び選定されるプロジェクト配列型ノードを経路を用いて
連結し、選定されるプロジェクト配列型ノードに、例え
ば、配列されるプロジェクトを選定することを特徴とし
ている。

【００１５】ここで、このプロジェクトは、複数のノー
ドとそれらを結ぶパスで構成されたワークフロー定義、
およびワークフローの業務単位であるプロセスで設定お
よび参照できるデータの定義であるデータ定義をまとめ
た単位であることを特徴とすることができる。また、こ
の選定されるプロジェクトは、配列の個々の要素が異な
る種類のプロジェクトであることを特徴とすれば、配列
型の変数を指定させることで、並列経路を１つのノード
で多重化することができる点で好ましい。

【００１６】他の観点から把えると、本発明は、ネット
ワークに接続された複数のコンピュータ端末にて実行さ
れるワークフロー定義方法であって、データセットと経
路とを統一して扱えるプロジェクト型変数からなるノー
ドをワークフローの１つのノードとして導入し、プロジ
ェクト型変数を配列として指定することで、同期的に分
岐される複数の子プロセス(サブプロセス)を１つのノー
ドとして扱うことを特徴としている。ここで、このプロ
ジェクト型変数には、明示的な設定がない場合に適用さ
れるプロトタイプを設定することを特徴とすることがで
きる。また、ここで用いられる「子プロセス(サブプロセ
ス)」は、例えば、経路パターンとデータセットの両方を
意味するものとすることができる。

【００１７】一方、本発明は、コンピュータに実行させ
るプログラムをコンピュータの入力手段が読取可能に記
憶した記憶媒体であって、このプログラムは、ワークフ
ローの実行担当者に対して割り当てられる業務であるノ
ードを選定する処理と、このノードの１つとしてプロセ
ス、経路パターンおよびデータセットを多重化するため
のプロジェクト配列型ノードを選定する処理と、このノ
ードおよびプロジェクト配列型ノードを経路を用いて接
続する処理と、プロジェクト配列型ノードに配列される
プロジェクトを選定する処理とをコンピュータに実行さ
せることを特徴としている。

【００１８】また、他の記憶媒体に格納されるプログラ
ムでは、データセットと経路とを統一して扱えるプロジ
ェクト型変数からなるノードをワークフローの１つのノ
ードとして導入する処理と、プロジェクト型変数を配列
として指定することで、同期的に分岐される複数の子プ
ロセスを１つのノードとして扱う処理とをコンピュータ
に実行させることを特徴としている。これらの記憶媒体
としては、例えば、ＣＤ−ＲＯＭ等の媒体が該当する。

【００１９】更に、本発明が適用されるプログラム伝送
装置は、コンピュータに、ワークフローの実行担当者に
対して割り当てられる業務であるノードを選定する処理
と、選定されるノードの１つとしてプロセス、経路パタ
ーンおよびデータセットを多重化するためのプロジェク
ト配列型ノードを選定する処理と、ノードおよびプロジ
ェクト配列型ノードを経路を用いて接続する処理と、プ
ロジェクト配列型ノードに配列されるプロジェクトを選
定する処理とを実行させるプログラムを記憶する記憶手
段と、この記憶手段からプログラムを読み出してプログ
ラムを送信する送信手段とを備えている。

【００２０】更にまた、本発明が適用されるプログラム
伝送装置は、コンピュータに、データセットと経路とを
統一して扱えるプロジェクト型変数からなるノードをワ
ークフローの１つのノードとして導入する処理と、プロ
ジェクト型変数を配列として指定することで、同期的に
分岐される複数の子プロセスを１つのノードとして扱う
処理とを実行させるプログラムを記憶する記憶手段と、
この記憶手段からプログラムを読み出して送信する送信
手段とを備えることを特徴としている。

【００２１】

【発明の実施の形態】以下、添付図面に示す実施の形態
に基づいてこの発明を詳細に説明する。まず、具体的な
説明に入る前に、本実施の形態にて用いられる主要な用
語について以下に列挙して説明する。 ・ワークフロー定義 複数のノードとそれらを結ぶパスで構成された定義。 ・ノード ワークフロー定義で扱う処理定義の単位。実際の処理者
とデータ入力画面が割り当てられる。 ・データ定義 プロセスで設定および参照できるデータの定義。データ
の名称、型、配列かどうかを定義する。型には、文字列
型や数値型がある。 ・データ属性定義 データが保持する値を制限する属性の定義で、データ定
義の一部である。文字型データに対する属性には文字数
の制限などが、数値型データに対する属性には範囲指定
などがある。 ・プロジェクト ワークフロー定義とデータ定義をまとめた単位。プロセ
ス定義と等価である。プロジェクトは定義ＩＤで識別さ
れ、プロジェクトが決定されると、そのワークフロー定
義とデータ定義も決定される。 ・プロセス ワークフローの業務単位。プロジェクトを具現化したも
の。プロセスは、その元となるプロジェクトのワークフ
ロー定義で示される経路パターンに沿って業務が流れ
る。また、データ定義で示されるデータセットは、個々
のプロセスで異なる内容を記憶する。 ・アクティビティ ノードに割り当てられた処理。処理者が割り当てられて
いれば、担当者の処理になる。

【００２２】次に、本実施の形態における具体的な説明
に入る。本実施の形態の理解を容易にするために、ま
ず、適用事例を用いて説明する。図１８(ａ),(ｂ)は、
ワークフロー設計者および伝票起票者による操作の一例
を示した図であり、本実施の形態が適用される単純な例
を示している。同じ経路パターンの多重化の場合、図１
８(ａ)に示すように、ワークフローの設計者は、あるノ
ードの設定としてプロジェクト型の配列変数ＰＲＪ[ ]
を参照するように指定する。ここに、ＰＲＪのプロトタ
イプ属性(明示的な設定がない場合に採用されるもの)と
して、プロジェクトの定義ＩＤ“bumon_prj”を設定す
る。図１８(ａ)に示される「Project＝Field(ID)＋サブ
経路：bumon」の表現では、「プロジェクト型データを
参照するノードでは、そのアクティビティとして、参照
されたプロジェクトの定義を使って子プロセスを生成・
実行している。また、同じbumonというプロジェクトを
使った子プロセスを生成・実行する場合でも、各子プロ
セスのＩＤという名前のデータを別々に設定すること
で、異なるユーザ(もしくは部門)に回覧できる。」とい
う意味を示している。

【００２３】図１８(ｂ)に示すように、伝票を起票する
ユーザは、その時点にてダイナミックに承認すべき部門
のＩＤ(soumu,keiri,eigyou)を入力する。図１８(ｂ)に
示すＩＮＰＵＴタグによって、これらは変数ＰＲＪの各
配列要素における変数ＩＤに関連付けられている。デー
タ値が代入される場合、プロジェクトのプロトタイプ属
性としてbumon_prjが設定されているので、このノード
のアクティビティとしてプロジェクト定義ＩＤ(bumon_p
rj)のプロジェクトを使って作成された子プロセスが設
定され、この子プロセス内のデータである変数ＩＤに値
が設定される。業務処理として、伝票が処理されると
き、このノードの設定はプロジェクト型の配列を参照す
るよう設定されていることから、配列要素の数だけ子プ
ロセスが生成され、並列に処理される。経路は、プロジ
ェクトbumon_prjで定義されたものが利用され、先頭の
ノード設定がデータ参照指定でＩＤという名前のデータ
を参照するように設定されているので、それぞれＩＤ＝
“soumu”、ＩＤ＝“keiri”、ＩＤ＝“eigyou”が評価
される。そして、それぞれの部門に送付され、その部門
での担当者が承認をする。これによって、一連のワーク
フローを実現することが可能となる。

【００２４】一方、異なる経路パターンの多重化の場
合、ワークフロー設計者は、同様に、あるノードの設定
としてプロジェクト型の配列変数ＰＲＪ[ ]を参照する
ように指定する。次に、伝票を起票するユーザは、その
時点でダイナミックに承認すべき部門用のプロジェクト
の定義ＩＤ(soumu_prj,keiri_prj,eigyou_prj)を入力す
る。ＩＮＰＵＴタグによって、これらは変数ＰＲＪの各
配列要素に別々のプロジェクトとして設定される。この
伝票が処理されるとき、このノードではプロジェクト型
の配列を参照するように設定されていることから、配列
要素の数だけ子プロセスが生成され、並列に処理され
る。このとき、それぞれ異なるプロジェクトＩＤ(soumu
_prj,keiri_prj,eigyou_prj)が評価され、異なる種類の
子プロセスが設定される。経路は、それぞれのプロジェ
クトで定義されたものが利用され、別々の経路を用いて
それぞれの部門に送付されて、その部門での担当者が承
認する。各子プロセスは、同期されて次のノードに進
む。このようにして、異なる経路パターンを多重化した
ワークフローが実現される。尚、ここで示したフローの
本質的な経路設計を含む親プロジェクトは、同じ経路パ
ターンの多重化の場合と異なる経路パターンの多重化の
場合で同じとすることが可能である。

【００２５】このように、本実施の形態では、ワークフ
ロー定義やデータ定義、表示形式、関連プログラムなど
の複数のリソースから構成されるアプリケーションの構
成単位をプロジェクトと呼び、このプロジェクトという
概念において、ワークフロー定義内のノードなどの要素
やデータ定義で定義された変数名といったリソースの名
前空間を一意に決定するために、プロジェクト名等から
なるプロジェクトＩＤを採用している。また、このプロ
ジェクトで、別のプロジェクトのワークフロー定義やデ
ータ定義といったリソースを再利用するために、プロジ
ェクト型のデータという概念を導入している。ワークフ
ロー定義上のノードの設定としてこのプロジェクト型デ
ータを参照するように指定することで、いわゆる「子プ
ロセス」を実現している。更に、プロジェクト型データ
を配列型と定義することで、並列な子プロセスを実現し
ている。これらの概念によって、子プロセスや子プロセ
ス内のデータに対して柔軟な制御が可能となる。

【００２６】次に、本実施の形態を全体システム構成か
ら順に詳述していく。図１は、本実施の形態が適用され
たワークフローシステムの概略構成を示す図である。本
実施の形態におけるワークフローシステムは、ワークフ
ローの設計のための設計用コンピュータ端末１０、業務
を遂行する担当者に対応して設けられたワークフローの
操作用コンピュータ端末２０、ワークフローを実行する
ための各種プログラムが格納されるワークフローサーバ
３０とを備えている。この設計用コンピュータ端末１
０、操作用コンピュータ端末２０、およびワークフロー
サーバ３０は、それぞれ接続されてネットワークを形成
している。

【００２７】設計用コンピュータ端末１０は、ワークフ
ローの設計機能が導入されており、業務処理をワークフ
ローシステムで実現するための定義機能を備えている。
業務処理の定義を行うユーザは、この設計用コンピュー
タ端末１０を用いて業務処理手順をワークフローシステ
ムに定義する。操作用コンピュータ端末２０は、予め指
定された業務を実行する機能があり、複数の業務担当者
が操作できるように配置されている。

【００２８】設計者は、設計用コンピュータ端末１０を
用いて、自己の識別情報を入力してワークフローシステ
ムに接続する。また、設計者は、ワークフロー設計機能
を用いて、対象業務における処理の流れと処理で用いら
れるデータ構造とを設計する。図２(ａ),(ｂ)は、対象
業務における処理の流れを示したプロジェクト(プロセ
ス定義)を示した図であり、図２(ａ)はワークフロー定
義の一例を示し、図２(ｂ)はこのワークフロー定義で参
照されるデータ定義の一例を示している。図２(ａ)にお
いて、丸印はノードと呼ばれ、担当者(業務担当者)に割
り当てられる業務を示している。矢印はパスと呼ばれ、
業務処理の順番、即ち、処理の繋がりを示している。本
実施の形態では、全てのノードにて単一のデータ定義が
参照され、各処理間で必要となるデータの受け渡しも矢
印で示されるパスに従うと仮定している。しかしなが
ら、複数のデータ定義が存在し、異なるデータの受け渡
しがパスで定義されていても構わない。図２(ｂ)では、
ユーザＩＤ(UserＩＤ)、名前(Name)として“String(文
字列型)”が定義され、アドレス(Address)として“Stri
ng[]”、Ageとして“Integer(数値型)”が定義されてい
る。

【００２９】設計用コンピュータ端末１０を用いている
設計者は、設計ツールを用いてノードを並べ、処理順を
決めるためにパスを繋いでいく。ノードおよびパスに対
して、その属性を規定することができる。ノードの属性
としては、ノードの名前および担当者となる実行ユーザ
を定義する。実行ユーザの割り当てタイプには、ユーザ
ＩＤを直接入力する直接指定、他の処理ユーザとの関係
(例えば、ノードＡ(NodeＡ)の処理ユーザの上司など)で
示した関係指定、および、図２(ｂ)で示したようなデー
タ定義で定義されるデータの値を処理ユーザとするデー
タ参照指定がある。パスの属性としては、そのパスが有
効となる条件を定義する。このようにして設計用コンピ
ュータ端末１０にて作成されたプロジェクトは、ワーク
フローサーバ３０に登録される。このとき、プロジェク
トを一意に特定することができる定義ＩＤが付加されて
登録される。プロジェクトから作成される個々の業務フ
ローがプロセスであり、このプロセスを形成する担当者
ごとの処理がアクティビティとなる。

【００３０】各担当者は、操作用コンピュータ端末２０
を用い、自己の識別情報を入力してワークフローシステ
ムに接続する。担当者は、図２(ａ)に示したようなワー
クフロー定義を参照して、新たにプロセスを作成した
り、自分に割り当てられているアクティビティを表示し
て、指定されている処理を実行する。各担当者の処理
は、図２(ａ)のワークフロー定義の１つであるノードに
対応している。担当者の処理が終了すると、ワークフロ
ー定義のパスに従って次の担当者の処理が割り当てられ
る。

【００３１】図３は、ワークフローサーバ３０の概略構
成を示した説明図である。本実施の形態におけるワーク
フローサーバ３０は、管理手段として、プロジェクト管
理プログラム３１、プロセス管理プログラム３２、クラ
イアント要求管理プログラム３３、およびユーザ管理プ
ログラム３４を備えている。また、記憶手段として、ワ
ークフロー定義記憶部３５、データ定義記憶部３６、プ
ロセス記憶部３７、ワークフロー状況記憶部３８、およ
びユーザ情報記憶部３９を備えているが、これらの記憶
手段はネットワーク内のどこに存在していても構わな
い。

【００３２】プロジェクト管理プログラム３１は、設計
用コンピュータ端末１０にて設計者が定義したプロジェ
クトのワークフロー定義とデータ定義とに関するデータ
をワークフロー定義記憶部３５およびデータ定義記憶部
３６に保存して管理する。それぞれのプロジェクトは、
定義ＩＤによって識別されている。新たな定義の登録、
および既に存在している定義の修正は、全てプロジェク
ト管理プログラム３１を通じて、定義ＩＤを用いて管理
する。また、担当者が新規プロセスを作成する際には、
その担当者が作成できるプロセスの一覧を、プロジェク
ト管理プログラム３１がワークフロー定義記憶部３５と
データ定義記憶部３６とに格納されたデータを用いて作
成する。

【００３３】プロセス管理プログラム３２は、プロジェ
クトの定義を用いて作成されたプロセスの管理を行う。
プロセスは、定義ＩＤと、同じ定義から作成された複数
のプロセスを識別するためのプロセスＩＤとを有し、こ
の定義ＩＤとプロセスＩＤとの組み合わせで管理されて
いる。また、プロセス記憶部３７には、現在実行中のア
クティビティ、アクティビティを実行している若しくは
実行すべき担当者(実行ユーザを含む)、プロセスで用い
られているデータが保管されている。これらの情報をも
とに、アクティビティの終了時に次の担当者の割り当て
が行われる。プロセス管理プログラム３２は、プロセス
の作成、アクティビティの割り当て、プロセスの完了と
いったイベントが発生する度に、その状況をワークフロ
ー状況記憶部３８に書き込んでいる。

【００３４】クライアント要求管理プログラム３３は、
操作用コンピュータ端末２０を用いる担当者の要求を受
け付ける機能を有している。また、担当者に現在、割り
当てられている(実行ユーザが担当者になっている)アク
ティビティの一覧を提供したり、担当者のアクティビテ
ィ終了要求を受け付ける機能を備えている。また、ワー
クフロー状況記憶部３８に残された情報を用いてプロセ
スの処理状況を提供している。

【００３５】ユーザ管理プログラム３４は、ワークフロ
ーシステムに参加できる担当者のコントロールを行って
いる。そのために、ユーザ情報をユーザ情報記憶部３９
に登録しておき、必要に応じてアクセスしている。新た
なユーザが操作用コンピュータ端末２０を用いてシステ
ムに接続しようとする場合には、ユーザの入力したＩＤ
およびパスワードのチェックが行われる。また、ユーザ
情報記憶部３９には、ユーザの属する組織や、組織の階
層構造、ユーザの上司関係、ユーザの権限区分等の情報
が保存されている。これらの情報は、プロセス管理が次
のアクティビティに対して担当者を割り当てる際に参照
される。参照される情報は、例えば、図２(ａ)に示され
るようなワークフロー定義のノードの属性によって異な
っている。

【００３６】次に、本実施の形態におけるワークフロー
システムの動作について説明する。図４(ａ),(ｂ)は、
登録済みプロジェクトの一例を示した図である。ここで
は、プロジェクト「定義Ａ」と、プロジェクト「定義Ｂ」と
が事前に登録されていると仮定している。それぞれのプ
ロジェクトは、前述したように、ワークフロー定義とデ
ータ定義とをまとめた単位として登録されている。図４
(ａ)に示すプロジェクト「定義Ａ」では、それを用いたプ
ロセスを開始すると、まずノードＡ(NodeＡ)に対応した
アクティビティの担当者が、プロセスのデータUserＩＤ
に代入されている人に割り当てられる。そのアクティビ
ティが終了すると、ノードＢ(NodeＢ)に対応したアクテ
ィビティが、ノードＡのアクティビティを実行したユー
ザの上司に割り当てられる。

【００３７】図４(ｂ)に示すプロジェクト「定義Ｂ」にお
いて、それを用いたプロセスを開始すると、まずノード
Ａ(NodeＡ)に対応したアクティビティの担当者が、プロ
セスのデータUserＩＤに代入されている人に割り当てら
れる。そのアクティビティが終了すると、ノードＣ(Nod
eＣ)のアクティビティの担当者が、プロセスのデータRe
viewer(検閲者)に代入されている人に割り当てられる。
更に、ノードＢ(NodeＢ)に対応したアクティビティの担
当者は、ノードＡのアクティビティを実行したユーザの
上司に割り当てられる。尚、プロジェクト「定義Ａ」は定
義ＩＤとして“定義Ａ”を、プロジェクト「定義Ｂ」は定
義ＩＤとして“定義Ｂ”を、それぞれ有している。

【００３８】図５は、本実施の形態にて採用されたプロ
セス定義方法によって作成される定義の一例を示した図
である。ここでは、まず、設計者が、図５に示す定義を
設計用コンピュータ端末１０の設計ツールを用いて作成
する。この例では、通常のノード５１および通常のノー
ド５２との間に、プロジェクト配列型ノード５３が設け
られている。図５のプロジェクト「定義Ｃ」のワークフロ
ー定義におけるノードＢ(NodeＢ)と、データ定義におけ
るDepts が本実施の形態で採用される定義方法である。
ノードＢのユーザ割り当ては、従来の定義と同じように
データ参照となっているが、参照するデータのタイプは
プロジェクト型の配列と定義されている。

【００３９】このプロジェクト型の配列の要素には他の
プロジェクトから作成されたプロセスがその値として代
入される。但し、このDeptsはプロトタイプ属性として
“定義Ａ”が与えられているため、明示的な定義ＩＤの
設定がなければプロジェクト“定義Ａ”のプロセスが代
入されることを示している。これらの定義から、このノ
ードＢにおけるアクティビティが有効になると、プロジ
ェクト型データDeptsが指すプロセスで置き換えられる
ことを意味し、また配列で定義されている場合は、複数
の別プロセスを同時にこのアクティビティとして開始す
ることを意味している。定義されたプロジェクトはワー
クフローサーバ３０に送られ、プロジェクト管理プログ
ラム３１を経てワークフロー定義記憶部３５とデータ定
義記憶部３６とに保存される。ここでは、定義ＩＤとし
て“定義Ｃ”を与えて保存したと仮定する。

【００４０】本実施の形態におけるワークフローシステ
ムにて、例えば、担当者Ａが新規の業務フローとして図
５のプロジェクト「定義Ｃ」を用いて新たなプロセスを作
成する場合、新規作成要求がワークフローサーバ３０の
クライアント要求管理プログラム３３に送られる。要求
を受け取ったクライアント要求管理プログラム３３は、
プロセス管理プログラム３２に新規プロセスの作成を要
求する。そして、プロセス記憶部３７内に、定義ＩＤと
して“定義Ｃ”が、プロセスＩＤとして“Ｃ００１”が
設定され、新たなプロセスとして作成されて保存され
る。

【００４１】図６は、プロセス記憶部３７における状態
の一例を示した図である。プロセス記憶部３７内におけ
る個々のプロセスは、定義ＩＤとプロセスＩＤとの組み
合わせで識別されるため、この識別表現として“定義
Ｃ：Ｃ００１”のように記述される。また、このプロセ
スの開始要求も同様にクライアント要求管理プログラム
３３を経てプロセス管理プログラム３２に送られ、アク
ティビティとして“NodeＡ”が、実行ユーザとして“担
当者Ａ”が設定される。

【００４２】図６に示す状態で、担当者Ａが操作用コン
ピュータ端末２０を用いてワークフローシステムに接続
すると、実行ユーザとして自分に割り当てられた“定義
Ｃ：Ｃ００１”におけるアクティビティ“NodeＡ”を知
ることができる。担当者Ａが更に端末からこのアクティ
ビティの開始を要求すると、関連付けられたプログラム
が起動され、担当者Ａは処理画面を得ることができる。

【００４３】図７は、担当者が得るワークフロー操作の
処理画面の一例を示した図であり、図８は、クライアン
ト要求管理プログラム３３に送られるデータを示した図
である。ここでは、代入先データ名毎に対応する設定値
が定められている。図７に示す処理画面には、プロジェ
クト「定義Ｃ」のデータ定義で定義されたデータ構造に対
するデータ入力域が設けられている。この図７の例で
は、ラベル「名前：」および「課題：」で示されるテキスト
入力域が、図８に示すように、それぞれプロジェクト
「定義Ｃ」のデータ構造における代入先データ名“Name”
および“Subject”に関連付けられている。また、図７
に示す「回覧先：」というラベルで示されたテーブルの
１行目の１カラム目が、図８に示す“Depts[1]”に関連
付けられ、２カラム目が“Depts[2].UserID”というデ
ータ名に関連付けられている。２行目以降も同様に“De
pts[n]”と“Depts[n].UserID”というデータ名に関連
付けられている。但し、図５にて説明したように、この
例では、プロトタイプ属性として“定義Ａ”が与えられ
ているため、明示的な定義ＩＤの設定がない“Depts
[1]”および“Depts[2]”では、プロジェクト“定義
Ａ”のプロセスが代入される。担当者Ａがこの操作画面
で図７に示すように入力して処理を確定した場合、その
情報は、図８に示すような形式でワークフローサーバ３
０のクライアント要求管理プログラム３３に送られる。

【００４４】図９は、クライアント要求管理プログラム
３３にて実行されるデータ設定の評価手順を示すフロー
チャートである。ここでは、図７で示した入力画面にお
ける「回覧先：」の１行目のデータ設定を例にとって説
明する。ここでは、予め入力画面で入力項目に割り当て
られた代入先データ名は、“Depts[1].UserID”であ
り、入力された値“総務”が設定値となる。これは図８
の３行目に相当する設定項目である。

【００４５】まず、クライアント要求管理プログラム３
３がこの値を設定する要求を受け取ると、現在のプロセ
ス“定義Ｃ：Ｃ００１”を「親プロセス」として評価ロジ
ックが呼び出される(ステップ１０１)。そして、「評価
データ名」に代入先データ名の最初のデータ名部分を設
定し(ステップ１０２)、「INDEX」に代入先データ名にお
ける最初のデータ名の配列添え字部分を設定し(ステッ
プ１０３)、「残りフレーズ」に代入先データ名から評価
データ名とINDEXを除いた部分を設定する(ステップ１０
４)。ここでは、代入先データ名が“Depts[1].UserID”
であることから、「評価データ名」として“Depts”、「IN
DEX」として“[1]”、「残りフレーズ」として“UserID”
が得られる。

【００４６】次に、親プロセスにおいて、評価データ名
のデータが定義されているか否かが判断される(ステッ
プ１０５)。定義されていない場合には、データ定義で
定義されていないデータに値を設定しようとしたものと
して、エラーとなる(ステップ１０６)。ステップ１０５
にて定義されている場合には、「評価データ」に親プロセ
ス内で評価データ名を持つデータが設定される(ステッ
プ１０７)。このプロセスのプロジェクト「定義Ｃ」のデ
ータ定義では“Depts”が定義されていることから、そ
の値が「評価データ」とされる。

【００４７】次に、評価データの型がプロジェクト型か
否かが判断される(ステップ１０８)。プロジェクト型で
はない場合には、評価データのINDEX要素に設定値が代
入される(ステップ１０９)。プロジェクト型である場合
には、残りフレーズが空ではないか否かが判断される
(ステップ１１０)。前述した例では、ステップ１０６の
「評価データ」である“Depts”は、「定義Ｃ」のデータ定
義において“Project[]”と定義されているので、プロ
ジェクト型の配列であることがわかる。また、「残りフ
レーズ」には“UserID”が設定されているため空ではな
い。

【００４８】ステップ１１０にて、「残りフレーズ」が空
ではない場合には、「評価データ」がまだプロセスを指し
ていないか否かが判断される(ステップ１１１)。この例
で「評価データ」がプロセスを指しているかどうかを確認
すると、図６で“定義Ｃ：Ｃ００１”のデータを見れ
ば、この状態ではまだプロセスは指していないことが解
かるので、プロトタイプ属性の確認に移る。即ち、評価
データにプロトタイプ属性が定義されているか否かが判
断される(ステップ１１２)。定義されていない場合に
は、プロトタイプ属性が定義されていないデータの内部
データに対し、定義ＩＤを設定しないで直接、アクセス
しようとしたものとして、エラーとなる(ステップ１１
５)。この例では、「評価データ」である“Depts”は、
「定義Ｃ」のデータ定義においてプロトタイプ属性が“定
義Ａ”と定義されている。そこで、定義ＩＤにプロトタ
イプ属性を設定し、プロセスを作成し、また、評価デー
タのINDEX要素が作成したプロセスを指すように設定す
る(ステップ１１３)。即ち、定義ＩＤが“定義Ａ”であ
るプロジェクトからプロセスが作成され、プロセス記憶
部３７の中に、“定義Ａ”および“Ａ００１”を識別子
として有するプロセスが保存される。また、「評価デー
タ」の「INDEX」要素である“Depts[1]”には、そのプロセ
スを指すように“定義Ａ：Ａ００１”が設定される。

【００４９】次に、親プロセスに「評価データ」の「INDE
X」要素が指すプロセスを設定し、代入先データ名に残り
のフレーズを設定する(ステップ１１４)。この例では、
「親プロセス」を「評価データ」の「INDEX」要素“Depts
[1]”が指すプロセス“定義Ａ：Ａ００１”に設定し、
「代入先データ名」に「残りフレーズ」“UserID”を設定す
る。その後、ステップ１０２にジャンプする。ステップ
１１１にて、評価データがプロセスを指している場合に
は、直接、ステップ１１４へ移行する。

【００５０】更に評価を進めると、「評価データ名」とし
て“UserID”が得られ(ステップ１０２)、「INDEX」とし
て“”（空文字）が得られ(ステップ１０３)、「残りフ
レーズ」として“”（空文字）が得られる(ステップ１０
４)。このプロセスのプロジェクト「定義Ａ」のデータ定
義では“UserID”が定義されているので(ステップ１０
５)、その値を「評価データ」とする(ステップ１０７)。
この「評価データ」の「INDEX」要素である“UserID”は、
「定義Ａ」のデータ定義において“String”と定義されて
いるので文字型であってプロジェクト型ではないことが
わかる(ステップ１０８)。したがって、最終的に「親プ
ロセス」か否かを示すプロセス“定義Ａ：Ａ００１”の
データ“UserID”に、設定値“総務”が設定される(ス
テップ１０９)。

【００５１】ステップ１１０にて、残りフレーズが空で
ある場合には、「評価データ」がまだプロセスを指してい
ないか否かが判断され(ステップ１１６)、指していない
場合には、定義ＩＤに設定値を設定し、プロセスを作成
し、「評価データ」の「INDEX」要素が作成したプロセスを
指すように設定する(ステップ１１７)。ステップ１１６
にてプロセスを指している場合に、「評価データ」の定義
ＩＤが設定値と等しい場合には(ステップ１１８)、既に
設定されている定義ＩＤとは異なる定義ＩＤを設定しよ
うとしたものとしてエラーとなる。

【００５２】図１０は、図８に示される全てのデータを
評価した結果として、プロセス記憶部３７にて得られる
状態の一例を示した図である。ここでは、プロジェクト
を識別するための定義ＩＤ、プロセスＩＤ、親プロセ
ス、アクティビティ、実行ユーザ、データ、子プロセス
数の各項目に対して、対応する評価結果を得ることがで
きる。例えば、担当者Ａがアクティビティの処理を終了
したとき、終了要求がワークフローサーバ３０のクライ
アント要求管理プログラム３３に送られる。クライアン
ト要求管理プログラム３３は、プロセス管理プログラム
３２を呼び出し、“定義Ｃ：Ｃ００１”のプロセスをプ
ロセス記憶部３７から取り出し、プロジェクト「定義Ｃ」
のワークフロー定義をワークフロー定義記憶部３５から
取り出してフロー評価を行う。

【００５３】図１１は、本実施の形態におけるフロー評
価手順を示したフローチャートである。このフロー評価
手順では、図１０に示すようなプロセス記録部３７の状
態から、まず、子プロセス数が０か否かが判断され (ス
テップ２０１)、０でない場合には、評価手順の処理は
終了する。子プロセス数が０である場合には、アクティ
ビティ名を取得する(ステップ２０２)。ここで、アクテ
ィビティ名が空か否かが判断され(ステップ２０３)、空
でない場合には、アクティビティ名を起点とするパスを
ワークフロー定義記憶部３５から検索する(ステップ２
０４)。

【００５４】次に、アクティビティ名を起点とするパス
が存在しているか否かが判断され(ステップ２０５)、存
在していない場合には、完了処理が実行されて(ステッ
プ２０６)、処理が終了する。アクティビティ名を起点
とするパスが存在する場合には、パスの終点ノードに指
定されているノードをフロー定義から検索し(ステップ
２０７)、検索されたノードの指定内容により実行ユー
ザＩＤを特定する(ステップ２０８)。ステップ２０３で
アクティビティ名が空である場合には、ワークフロー定
義記憶部３５から先頭になるアクティビティ名を検索し
(ステップ２０９)、ステップ２０８に移行する。このス
テップ２０８の後に、ノードをプロセスのアクティビテ
ィに、特定したユーザＩＤを実行ユーザＩＤにセットす
る(ステップ２１０)。そして、マッチした経路がまだあ
るか否かが判断され(ステップ２１１)、まだある場合に
は、プロセスを複製して(ステップ２１２)、ステップ２
０７に戻り、マッチした経路がない場合には、フロー評
価手順の処理が終了する。

【００５５】図１２は、本実施の形態における実行ユー
ザ割り当て手順を示したフローチャートである。まず、
割り当てタイプを取得し(ステップ３０１)、直接指定か
否かが判断される(ステップ３０２)。直接指定である場
合には、定義で指定されたユーザを取り出し(ステップ
３０３)、実行ユーザ割り当て手順の処理が終了する。
直接指定でない場合には、関係指定か否かで手順が異な
る(ステップ３０４)。関係指定である場合には、指定さ
れた関係を取り出し(ステップ３０５)、関係を使ってユ
ーザ情報を検索し(ステップ３０６)、関係を満たすユー
ザを取得して(ステップ３０７)、実行ユーザ割り当て手
順の処理が終了する。

【００５６】ステップ３０４で関係指定でない場合に
は、データ参照か否かが判断され(ステップ３０８)、デ
ータ参照でない場合には、実行ユーザ割り当て手順の処
理が終了する。データ参照である場合には、指定された
データの型をチェックするが(ステップ３０９)、データ
の型がプロジェクト型であるか否かでその後の処理が異
なる(ステップ３１０)。即ち、プロジェクト型である場
合には、データで示される子プロセスを取得し(ステッ
プ３１１)、子プロセス数にデータの要素数(開始する子
プロセスの数)を代入する(ステップ３１２)。そして、
全ての子プロセスに対してフロー評価を行ってプロセス
を開始して(ステップ３１３)、一連の処理が終了する。
一方、プロジェクト型でない場合には、データ値を取り
出し(ステップ３１４)、データ値をユーザとして(ステ
ップ３１５)、実行ユーザ割り当て手順の処理が終了す
る。

【００５７】図１３は、本実施の形態における完了処理
の手順を示したフローチャートである。完了処理では、
まず、プロセスのアクティビティをクリアし(ステップ
４０１)、実行ユーザをクリアする(ステップ４０２)。
次に、親プロセスを持つ子プロセスかどうかがチェック
され(ステップ４０３、ステップ４０４)、子プロセスで
ある場合には、親プロセスの子プロセスカウントを１つ
減らし(ステップ４０５)、親プロセスのフロー評価を実
行する(ステップ４０６)。最後に、プロセス記憶部３７
から情報を削除して(ステップ４０７)、完了処理が終了
する。子プロセスでない場合には、そのままプロセス記
憶部３７から情報を削除して(ステップ４０７)、完了処
理が終了する。

【００５８】図１４は、図１１、図１２、図１３に示し
た処理を実行することによるプロセス記憶部３７の状態
を示した図である。図１１〜図１３の処理によって、図
１０の状態が図１４に示すように変更されている。この
図１４に示す状態では、子プロセス“定義Ａ:Ａ００
１”が“総務”というユーザＩＤを持った担当者に、子
プロセス“定義Ａ:Ａ００２”が“経理”というユーザ
ＩＤを持った担当者に、子プロセス“定義Ｂ:Ｃ００
１”が“営業”というユーザＩＤを持った担当者に、そ
れぞれ割り当てられている。即ち、３つの子プロセスが
並列に実行されている。割り当てられたユーザが本実施
の形態におけるワークフローシステムに接続すると、自
分が実行ユーザになっているアクティビティが存在する
ことが分かり、それを実行することが可能となる。ま
た、例えば、“総務”というユーザＩＤを持った担当者
がそのアクティビティを終了すると、プロセス“定義
Ａ:Ａ００１”は、その上司に割り当てられる。

【００５９】図１５は、今までの例における全体のプロ
セスフローを示した図である。このプロセスフローで
は、図５にて示したプロジェクト「定義Ｃ」において、ノ
ードＢ(NodeＢ)のアクティビティが有効になり、プロジ
ェクト型データDepts[1]〜[3]が指すプロセスで置き換
えられている。即ち、定義Ａの２つの経路と定義Ｂの経
路とからなる並列経路が、１つのノードで多重化して扱
われており、通常のノード５１と５２との間に、３つの
サブ経路からなるノード類５４を実行させることができ
る。

【００６０】図１６は、図７に示した「回覧先：」のデー
タとして、他のデータを指定した場合を示している。図
８にて説明した場合と同様に、この図１６に示されるデ
ータは、クライアント要求管理プログラム３３に送られ
る。ここでは、Depts[1]からDepts[4]まで、プロジェク
ト配列型のデータとして扱われる。また、Depts[1]およ
びDepts[2]は“定義Ｂ”、Depts[3]およびDepts[4]は
“定義Ａ”と設定され、Depts[1].UserIDからDepts[4].
UserIDまで、User１〜User４が設定されている。

【００６１】図１７は、「回覧先：」として図１６を指定
した場合の全体のプロセスフローを示した図である。こ
こでは、図５にて示したプロジェクト「定義Ｃ」におい
て、ノードＢ(NodeＢ)のアクティビティが有効になり、
プロジェクト型データDepts[1]〜[4]が指すプロセスで
置き換えられている。即ち、定義Ａの２つの経路と定義
Ｂの２つ経路とからなる並列経路が、１つのノードで多
重化して扱われており、通常のノード５１と５２との間
に、４つのサブ経路からなるノード類５５を実行させる
ことができる。

【００６２】以上、本実施の形態における処理をまとめ
ると、本実施の形態では、データ定義で定義できるデー
タとして、プロジェクト型およびその配列を定義できる
ようにしている。また、プロジェクト型データは、属性
として、プロトタイプ属性と呼ばれる、事前指定プロジ
ェクトの定義ＩＤを指定することができる。プロセスを
作成すると、そのプロセスが定義されているプロジェク
トのデータ定義に従ってデータセットが作成されプロセ
ス記憶部３７に記憶される。このようにして作成された
データには、各ノードに関連付けられた画面を通して値
を設定することができる。

【００６３】プロジェクト型として定義されたデータに
は前述したように定義ＩＤが添えられている。プロジェ
クトの定義ＩＤを指定すると、そのデータには指定した
プロジェクトのデータ定義に従った新たなデータセット
が作成され、その後はその新たなデータを設定および参
照することができる。特にプロジェクトの定義ＩＤを指
定しなくても、プロトタイプ属性に定義ＩＤが設定され
ている場合は、そのプロトタイプ属性であるプロジェク
トのデータ定義に従ったデータを初めて参照または設定
した時点で自動的にデータセットを作成することが可能
となる。従って、明示的に定義ＩＤを指定する必要はな
い。また、配列データの場合には、必要な要素数だけプ
ロジェクトの定義ＩＤを指定することで、1つのデータ
で複数のプロジェクトのデータを扱うことが可能とな
る。この配列データにおいてもプロトタイプ属性が設定
されている場合は、値を初めて参照・設定した時点で、
その配列要素に対して自動的にデータセットが作成され
る。

【００６４】プロセス作成直後、もしくはアクティビテ
ィが終了すると、ワークフロー定義に従って次に有効と
なるノードを見つけ出す。この有効となるノードに個別
の担当者が割り当てられている場合には、その担当者に
処理を割り当てる。また、ノードにデータを参照するよ
う定義されていた場合は、そのデータが指し示す値を使
って担当者を識別し、その担当者が処理を割り当てる。
ただし、そのノードがプロジェクト型のデータを参照す
るよう定義されている場合は、そのデータが指し示す別
のワークフロー定義から子プロセスを作成し、この子プ
ロセス自体をこのノードのアクティビティとする。この
とき、実際の処理担当者は、子プロセスの先頭ノードを
評価して決定することが可能となる。更に、そのノード
がプロジェクト型のデータを配列として記憶している場
合には、その配列の要素すべてに対して子プロセスを作
成し、その子プロセス自体をこのノードのアクティビテ
ィとすることができる。この配列を参照して作成された
子プロセス群は、そのすべての子プロセスの完了をもっ
て、親プロセスにおけるノードのアクティビティの終了
とされる。

【００６５】このように、本実施の形態によれば、経路
定義において、ノードとしてプロジェクト変数を指定さ
せることで、ダイナミックにサブ経路を変更することが
可能となる。また、そのプロジェクト変数に配列型の変
数を指定させることで、同期タイプの並列経路を１つの
ノードで多重化して扱うことができる。言い換えれば、
本質的な経路定義では、ノードとして唯一プロジェクト
変数を指定するだけなので、ユーザオペレーションを極
めてシンプルにすることができ、組織変更などに簡単に
対応することが可能となる。また、担当者である起票者
が伝票上で承認先部門を指定するだけで、複数部門に並
列に承認依頼ができる稟議用の伝票等の設計が容易とな
る。

【００６６】尚、本実施の形態にて説明したワークフロ
ーを実行するプログラムは、記憶媒体に格納されて販売
等に供されるが、この記憶媒体としては、これらの処理
を実行するためのソフトウェアが格納された、例えばＣ
Ｄ−ＲＯＭ等の媒体が代表的なものである。また、プロ
グラムをネット等を介してダウンロードする態様では、
プログラムの伝送装置における媒体や、ダウンロードし
た後のハードディスク等の記憶媒体も含まれることは言
うまでもない。これらの記憶媒体に格納されたプログラ
ムは、入力手段としての、例えばＣＤ−ＲＯＭドライバ
によって読み取られることが可能である。また、プログ
ラムの伝送装置では、例えば、インターネットに接続さ
れたコンピュータ端末からのダウンロード要求に応じ
て、本実施の形態を実現可能なプログラムを供給できる
インターフェイス手段(送信手段)を備えていれば良い。

【００６７】

【発明の効果】以上説明したように、本発明によれば、
複雑なワークフロー設計を単純な定義によって実現する
ことが可能となる。

【図面の簡単な説明】

【図１】 本実施の形態が適用されたワークフローシス
テムの概略構成を示す図である。

【図２】 (ａ),(ｂ)は、対象業務における処理の流れ
を示したプロジェクト(プロセス定義)を示した図であ
る。

【図３】 ワークフローサーバ３０の概略構成を示した
説明図である。

【図４】 (ａ),(ｂ)は、登録済みプロジェクトの一例
を示した図である。

【図５】 本実施の形態にて採用されたプロセス定義方
法によって作成される定義の一例を示した図である。

【図６】 プロセス記憶部３７における状態の一例を示
した図である。

【図７】 担当者が得るワークフロー操作の処理画面の
一例を示した図である。

【図８】 クライアント要求管理プログラム３３に送ら
れるデータを示した図である。

【図９】 クライアント要求管理プログラム３３にて実
行されるデータ設定の評価手順を示すフローチャートで
ある。

【図１０】 図８に示される全てのデータを評価した結
果として、プロセス記憶部３７にて得られる状態の一例
を示した図である。

【図１１】 本実施の形態におけるフロー評価手順を示
したフローチャートである。

【図１２】 本実施の形態における実行ユーザ割り当て
手順を示したフローチャートである。

【図１３】 本実施の形態における完了処理の手順を示
したフローチャートである。

【図１４】 図１１、図１２、図１３に示した処理を実
行することによるプロセス記憶部３７の状態を示した図
である。

【図１５】 全体のプロセスフローを示した図である。

【図１６】 図７に示した「回覧先：」のデータとして、
他のデータを指定した場合を示した図である。

【図１７】 「回覧先：」として図１６を指定した場合の
全体のプロセスフローを示した図である。

【図１８】 (ａ),(ｂ)は、ワークフロー設計者および
伝票起票者による操作の一例を示した図である。

【符号の説明】 １０…設計用コンピュータ端末、２０…操作用コンピュ
ータ端末、３０…ワークフローサーバ、３１…プロジェ
クト管理プログラム、３２…プロセス管理プログラム、
３３…クライアント要求管理プログラム、３４…ユーザ
管理プログラム、３５…ワークフロー定義記憶部、３６
…データ定義記憶部、３７…プロセス記憶部、３８…ワ
ークフロー状況記憶部、３９…ユーザ情報記憶部

フロントページの続き (72)発明者 津田 和幸 神奈川県大和市下鶴間1623番地14 日本ア イ・ビー・エム株式会社 大和事業所内 Ｆターム(参考） 5B049 AA02 BB00 FF07 GG04 GG07

Claims (20)

【特許請求の範囲】
1. 【請求項１】 複数のコンピュータ端末が接続されるネ
   ットワークにおいて、ワークフローに従って当該コンピ
   ュータ端末を利用する担当者の間で当該ネットワークを
   介したデータの受け渡しを行うワークフローシステムで
   あって、 前記担当者に割り当てられる処理であるノードと当該ノ
   ードの処理順を決定するためのパスとを定めたワークフ
   ロー定義および当該ワークフロー定義で参照されるデー
   タ定義からなるプロジェクトを作成して前記ワークフロ
   ーを設計する設計手段と、 前記設計手段により作成された前記プロジェクトを記憶
   する記憶手段と、 前記記憶手段に記憶された前記プロジェクトを用いて前
   記ワークフローの業務単位であるプロセスを作成して前
   記担当者に対して処理を割り当てる管理手段と、を備え
   たことを特徴とするワークフローシステム。
2. 【請求項２】 前記プロジェクトにおける前記データ定
   義では、データとしてプロジェクト型およびその配列が
   定義されることを特徴とする請求項１記載のワークフロ
   ーシステム。
3. 【請求項３】 前記設計手段は、配列の個々の要素が異
   なる種類のプロジェクトを扱って前記ワークフローを設
   計することを特徴とする請求項１記載のワークフローシ
   ステム。
4. 【請求項４】 ネットワークに接続され、担当者の間で
   ワークフローを実行するための操作用コンピュータ端末
   と、 扱われる処理の単位であるノードに対して複数のプロセ
   スを多重化するためのプロジェクト変数を指定して前記
   ワークフローを設計する設計用コンピュータ端末と、 前記設計用コンピュータ端末により設計された前記ワー
   クフローを管理すると共に、ノードに割り当てられた処
   理であるアクティビティに対応して前記操作用コンピュ
   ータ端末にアクセスするワークフローサーバと、を備え
   たことを特徴とするワークフローシステム。
5. 【請求項５】 前記設計用コンピュータ端末により設計
   されたワークフローにおけるプロジェクト変数は、前記
   ノードと当該ノードの処理順を決定するためのパスとを
   定めたワークフロー定義および当該ワークフロー定義で
   参照されるデータ定義とを用いて指定されることを特徴
   とする請求項４記載のワークフローシステム。
6. 【請求項６】 前記プロジェクト変数は、自己を識別す
   るための定義ＩＤを属性として定義され、 前記ワークフローサーバは、定義された前記定義ＩＤを
   用いて前記プロジェクト変数に関する情報を記憶するこ
   とを特徴とする請求項４記載のワークフローシステム。
7. 【請求項７】 前記操作用コンピュータ端末は、割り当
   てられた処理の実行後にアクティビティの終了を前記ワ
   ークフローサーバに通知し、 前記ワークフローサーバは、前記ワークフローによる全
   てのアクティビティを終了した後にプロセスを完了する
   ことを特徴とする請求項４記載のワークフローシステ
   ム。
8. 【請求項８】 ワークフローを実行する複数のコンピュ
   ータ端末に対してネットワークを介して接続される情報
   処理装置であって、 複数のノードとそれらを結ぶパスとで構成されたワーク
   フロー定義および当該ワークフロー定義で参照されるデ
   ータ定義を含めたプロジェクトを管理するプロジェクト
   管理手段と、 前記プロジェクト管理手段により管理される前記プロジ
   ェクトを用いて前記ワークフローの業務単位であるプロ
   セスを管理するプロセス管理手段と、 前記プロセス管理手段により管理される前記プロセスに
   基づいて前記コンピュータ端末に対してアクセスするユ
   ーザ管理手段と、を備えたことを特徴とする情報処理装
   置。
9. 【請求項９】 前記プロジェクト管理手段は、前記プロ
   ジェクトを一意に定める定義ＩＤを用いて当該プロジェ
   クトを管理することを特徴とする請求項８記載の情報処
   理装置。
10. 【請求項１０】 ネットワークに接続された複数のコン
    ピュータ端末によるワークフローを定義する情報処理装
    置であって、 ワークフローの実行担当者に対して割り当てられる業務
    であるノードを選定し、選定される当該ノードの処理順
    を決めるパスをつないでワークフロー定義を決定するワ
    ークフロー定義決定手段と、 前記ワークフロー定義決定手段により選定された前記ノ
    ードの実行ユーザを定義すると共に、前記パスが有効と
    なる条件を定義するデータ定義手段と、 前記ワークフロー定義決定手段により決定されたワーク
    フロー定義および前記データ定義手段により定義された
    データ定義に対し、これらを特定できる情報を付加して
    登録させる登録指示手段と、を備えたことを特徴とする
    情報処理装置。
11. 【請求項１１】 前記登録指示手段は、前記ワークフロ
    ー定義と前記データ定義とをまとめた単位であるプロジ
    ェクトに対して、当該プロジェクトを一意に特定できる
    定義ＩＤを付加して登録させることを特徴とする請求項
    １０記載の情報処理装置。
12. 【請求項１２】 ネットワークに接続された複数のコン
    ピュータ端末によるワークフローを定義するためのワー
    クフロー定義方法であって、 ワークフローの実行担当者に対して割り当てられる業務
    であるノードを選定し、 選定される前記ノードの１つとしてプロセスを多重化す
    るためのプロジェクト配列型ノードを選定し、 選定される前記ノードおよび選定される前記プロジェク
    ト配列型ノードを経路を用いて連結し、 選定される前記プロジェクト配列型ノードに配列される
    プロジェクトを選定することを特徴とするワークフロー
    定義方法。
13. 【請求項１３】 選定される前記プロジェクトは、配列
    の個々の要素が異なる種類のプロジェクトであることを
    特徴とする請求項１２記載のワークフロー定義方法。
14. 【請求項１４】 前記プロジェクトは、複数のノードと
    それらを結ぶパスで構成されたワークフロー定義、およ
    びワークフローの業務単位であるプロセスで設定および
    参照できるデータの定義であるデータ定義をまとめた単
    位であることを特徴とする請求項１２記載のワークフロ
    ー定義方法。
15. 【請求項１５】 ネットワークに接続された複数のコン
    ピュータ端末にて実行されるワークフロー定義方法であ
    って、 データセットと経路とを統一して扱えるプロジェクト型
    変数からなるノードをワークフローの１つのノードとし
    て導入し、 前記プロジェクト型変数を配列として指定することで、
    同期的に分岐される複数の子プロセスを１つのノードと
    して扱うことを特徴とするワークフロー定義方法。
16. 【請求項１６】 前記プロジェクト型変数に、明示的な
    設定がない場合に適用されるプロトタイプを設定するこ
    とを特徴とする請求項１５記載のワークフロー定義方
    法。
17. 【請求項１７】 コンピュータに実行させるプログラム
    を当該コンピュータの入力手段が読取可能に記憶した記
    憶媒体であって、 前記プログラムは、 ワークフローの実行担当者に対して割り当てられる業務
    であるノードを選定する処理と、 選定される前記ノードの１つとしてプロセスを多重化す
    るためのプロジェクト配列型ノードを選定する処理と、 前記ノードおよび前記プロジェクト配列型ノードを経路
    を用いて接続する処理と、 前記プロジェクト配列型ノードに配列されるプロジェク
    トを選定する処理と、を前記コンピュータに実行させる
    ことを特徴とする記憶媒体。
18. 【請求項１８】 コンピュータに実行させるプログラム
    を当該コンピュータの入力手段が読取可能に記憶した記
    憶媒体であって、 前記プログラムは、 データセットと経路とを統一して扱えるプロジェクト型
    変数からなるノードをワークフローの１つのノードとし
    て導入する処理と、 前記プロジェクト型変数を配列として指定することで、
    同期的に分岐される複数の子プロセスを１つのノードと
    して扱う処理と、を前記コンピュータに実行させること
    を特徴とする記憶媒体。
19. 【請求項１９】 コンピュータに、ワークフローの実行
    担当者に対して割り当てられる業務であるノードを選定
    する処理と、選定される当該ノードの１つとしてプロセ
    スを多重化するためのプロジェクト配列型ノードを選定
    する処理と、当該ノードおよび当該プロジェクト配列型
    ノードを経路を用いて接続する処理と、当該プロジェク
    ト配列型ノードに配列されるプロジェクトを選定する処
    理とを実行させるプログラムを記憶する記憶手段と、 前記記憶手段から前記プログラムを読み出して当該プロ
    グラムを送信する送信手段とを備えるプログラム伝送装
    置。
20. 【請求項２０】 コンピュータに、データセットと経路
    とを統一して扱えるプロジェクト型変数からなるノード
    をワークフローの１つのノードとして導入する処理と、
    前記プロジェクト型変数を配列として指定することで、
    同期的に分岐される複数の子プロセスを１つのノードと
    して扱う処理とを実行させるプログラムを記憶する記憶
    手段と、 前記記憶手段から前記プログラムを読み出して当該プロ
    グラムを送信する送信手段とを備えるプログラム伝送装
    置。