JPH11154189A

JPH11154189A - 状態監視型ワークフローの制御方法及びシステム

Info

Publication number: JPH11154189A
Application number: JP9321213A
Authority: JP
Inventors: Toshihiko Mori; 俊彦森; Nobuko Soga; 伸子曽我; Naofumi Hosoda; 直文細田; Shuji Soga; 修治曽我; Taro Yakabe; 太郎矢加部
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 1997-11-21
Filing date: 1997-11-21
Publication date: 1999-06-08
Also published as: AU9324598A; EP0924631A2; CN1218233A; KR19990045469A; CA2254235A1; TW495689B; EP0924631A3; AU709424B2

Abstract

(57)【要約】【課題】企業内の業務処理及び企業間取引についてワ
ークフロー制御を行うに際して必要となるデータ送付は
ワークフロー制御システム側が行い、ユーザアプリケー
ションや担当者にデータ送付を意識させない。【解決手段】ロールエージェント部１２２は、ユーザ
アプリケーション１１１の処理完了を検知し、ロールル
ール定義ＤＢ１２１を参照して部門内のワークフロー制
御を行う。またビジネスエージェント部１２３もこのユ
ーザアプリケーション１１１の処理完了を検知し、ビジ
ネスルール定義ＤＢ１１８を参照して部門間に亘るワー
クフロー制御を行い、次の処理をすべき部門が他企業で
あればアクセスエージェント部１２７にデータ送付依頼
をする。アクセスエージェント部１２７は、アクセスル
ール定義ＤＢ１２６を参照して宛先の企業に対してアク
ション・ノーティスを発行する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、電子計算機を利用
するワークフロー制御方法及びワークフロー制御を実行
する計算機システムに係わり、特に企業内の業務処理に
ついてのワークフロー制御に加えて、企業間の取引業務
についてのワークフロー制御を行う方法及びシステムに
関する。

【０００２】

【従来の技術】一般に企業内における業務処理は、複数
の作業工程のシーケンスから構成される業務処理プロセ
スを経て遂行されることが多い。ある作業工程から次の
作業工程には、伝票、帳票等を通じて次々にデータが受
け渡され、一連の作業プロセスが遂行される。電子計算
機を利用するワークフローシステムでは、伝票や帳票を
単位とする情報は電子計算機の記憶装置に格納され、ネ
ットワークを介するデータ伝送によって次の作業を行う
担当者に渡される。例えば日経情報ストラテジー１９９
４年７月号Ｐ６６−Ｐ７６（日経ＢＰ社）は、この種の
ワークフローシステムを開示する。

【０００３】これに対し企業間取引は、取引を行う企業
間でそれぞれの企業が業務処理を行った結果である伝
票、帳票がやり取りされる。従って企業間取引は、企業
内の業務処理がある企業から別の企業に亘って延伸され
たものとみることができる。電子計算機を利用してこの
ような企業間取引を行うシステムの１つとしてＥＤＩ
（Electronic Data Interchange）による企業間取引シ
ステムがある。これはあらかじめ取引を行う２社間で契
約を交わし、そこで決められたフォーマット、データ形
式及びその他ルールに基づいて伝票、帳票の形でデータ
のやり取りを行うものである。つまり企業内において定
められている業務処理ルールに相当するものを取引する
相手ごとに決め、そのルールによって取引を行ってい
る。例えば北澤博著「ＥＤＩ入門」（ソフトリサーチセ
ンター、１９９１年）は、この種のＥＤＩ技術を開示す
る。

【０００４】

【発明が解決しようとする課題】従来のＥＤＩによる企
業間取引システムは、企業ごとに取引ルールを決めてい
るため、取引相手ごとにそのルールに応じて取引方法を
変えなければならず、取引の内容によって処理方法を変
えなければならない事態が発生する。典型的な例として
発注処理を挙げると、発注する企業内においては発注
後、入荷検品、買掛計上と業務プロセスが遷移していく
が、企業間取引での業務プロセスでは、発注後、発注を
受けた企業が受注処理を行うことになる。さらに発注先
はその発注内容によりいつも同じであるとは限らない。
発注内容によってデータの送付先、送付方法が大きく変
わってくる場合がある。しかし先にも述べたように企業
間取引システムでは取引先の企業ごとにルールが異なる
ため、同一の処理手順によって処理することは難しく、
その発注内容に合わせて臨機応変にデータ伝達方法や送
付先を変更するというシステムの実現は極めて難しいと
いう問題があった。

【０００５】本発明の目的は、企業内業務処理か企業間
取引であるかを問わず、原則として部門間や企業間で必
要となるデータ送付はワークフロー制御システム側が行
い、ユーザアプリケーションや業務処理担当者にこのよ
うなデータ送付を意識させないようにすることにある。

【０００６】

【課題を解決するための手段】本発明のワークフロー制
御方法は、案件データに関する業務処理の終了を検知し
たとき、この案件データのデータ入力状態に従って部門
内のワークフロー・シーケンスの中で次に処理すべき担
当者を規定する部門内のワークフロールールに基づいて
次の担当者が処理すべき案件状態か否かを判定し、次の
担当者が処理すべき案件状態に達していれば次の担当者
にアクション・ノーティスを発行し、この案件データに
関する業務処理の終了を検知したとき、案件データのデ
ータ入力状態に従って部門間に亘るワークフロー・シー
ケンスの中で次に処理すべき部門を規定する部門間のワ
ークフロールールに基づいて次の部門が処理すべき案件
状態か否かを判定し、次の部門が処理すべき案件状態に
達していれば次の部門に対してアクション・ノーティス
を発行し、次の部門に対するアクション・ノーティスを
受けて部門内のワークフロールールに基づいて上記の部
門内ワークフロー制御を行うことを特徴とする。

【０００７】また本発明のワークフロー制御システム
は、部門内のワークフローを制御する第１のエージェン
ト手段と、部門間のワークフローを制御する第２のエー
ジェント手段と、第２のエージェント手段と他の第２の
エージェント手段との間のデータ転送を行う第３のエー
ジェント手段とを有するシステムを特徴とする。

【０００８】第１のエージェント手段は、案件データに
関する業務処理の終了を検知したとき、この案件データ
のデータ入力状態に従って部門内のワークフロー・シー
ケンスの中で次に処理すべき担当者を規定する部門内の
ワークフロールールに基づいて次の担当者が処理すべき
案件状態か否かを判定し、次の担当者が処理すべき案件
状態に達していれば次の担当者にアクション・ノーティ
スを発行する手段と、次の部門に対するアクション・ノ
ーティスを受けて部門内のワークフロールールに基づい
て上記の部門内ワークフロー制御を行う手段とを有す
る。

【０００９】第２のエージェント手段は、この案件デー
タに関する業務処理の終了を検知したとき、この案件デ
ータのデータ入力状態に従って部門間に亘るワークフロ
ー・シーケンスの中で次に処理すべき部門を規定する部
門間のワークフロールールに基づいて次の部門が処理す
べき案件状態か否かを判定し、次の部門が処理すべき案
件状態に達している場合に次の部門が管理下の部門に属
するか管理外の部門に属するかを判定し、管理下の部門
に属する場合には管理下の第１のエージェント手段に対
してアクション・ノーティスを発行し、管理外の部門に
属する場合には第３のエージェント手段へデータ送付依
頼を行う手段と、第３のエージェント手段からアクショ
ン・ノーティスを受け取って宛先となる第１のエージェ
ント手段に対してアクション・ノーティスを発行する手
段とを有する。

【００１０】第３のエージェント手段は、第２のエージ
ェント手段からデータ送付依頼を受け取って次の部門を
管理する第２のエージェント手段を決定し、決定した第
２のエージェント手段に対してアクション・ノーティス
を送付する手段を有する。

【００１１】上記次の部門は一般用語で表現される機能
部門であり、第２のエージェント手段は、この機能部門
が自分の管理下の機能部門か管理外の機能部門かを判断
するだけでよい。また第３のエージェント手段からアク
ション・ノーティスとともに宛先の機能部門を受けたと
き、この機能部門は管理下の機能部門であるから、テー
ブルを参照して宛先となる第１のエージェント手段を決
定する。また第３のエージェント手段は、宛先の機能部
門を受け取り、テーブルを参照して宛先となる第２のエ
ージェント手段に関する識別子を判断するだけでよい。
さらに第３のエージェント手段が参照するテーブルとし
て案件データの内容を条件として対応する宛先を設定す
るようなテーブルにすれば、第３のエージェント手段
は、案件データの内容とこのテーブル上の案件データの
条件とを突き合わせて宛先を決定することができる。ま
た第２のエージェント手段が参照するテーブルについて
も同様に案件データの内容を条件として対応する宛先を
設定するようなテーブルにすれば、第２のエージェント
手段は、案件データの内容とこのテーブル上の案件デー
タの条件とを突き合わせて宛先を決定することができ
る。

【００１２】以上述べたように、ワークフロー制御シス
テムが案件データの内容から自動的にデータ送付先を判
断してデータ送付を行うので、ユーザアプリケーション
や業務処理担当者がデータ送付について意識しなくとも
企業内の部門間及び企業間のデータ送付が行われ、複数
企業間に亘るワークフローが正確かつ効率的に制御され
ることになる。なおデータ送付方法が変更になつたとき
には、第２のエージェント手段が管理するワークフロー
ルールを変更すればよく、データ送付先が変更になつた
ときには、第２のエージェント手段及び第３のエージェ
ント手段がデータ送付先を決定するとき参照するテーブ
ルを変更すればよい。

【００１３】

【発明の実施の形態】以下本発明の一実施形態について
図面を用いて説明する。

【００１４】図１は、システム構成の例を概略的に示す
図である。図１でＡ社、Ｂ社１０４及びＣ社１０５は企
業間取引に参加する企業であり、プロバイダ１０６はど
の企業にも属さない事業者である。Ａ社はＸ部門１０
１、Ｙ部門１０２及びＺ部門１０３によって構成され
る。ここでＸ部門１０１、Ｙ部門１０２、Ｚ部門１０
３、Ｂ社１０４、Ｃ社１０５及びプロバイダ１０６は、
各々部門、企業又は事業者の管理する計算機システムを
表すものとする。Ａ社の同一所在地にあるＸ部門１０１
とＹ部門１０２とはＬＡＮ１０７によって接続され、Ｘ
部門１０１，Ｙ部門１０２と別所在地にあるＺ部門１０
３とはＬＡＮ１０７及びネットワーク１０８を介して接
続される。Ａ社のＸ部門１０１、Ｙ部門１０２とＢ社１
０４とはプロバイダ１０６及びネットワーク１０９を介
して接続される。またＡ社のＸ部門１０１、Ｙ部門１０
２とＣ社１０５とはプロバイダ１０６及びネットワーク
１１０を介して接続される。ネットワーク１０８，１０
９及び１１０は、ＬＡＮ以外の専用線、ＷＡＮ、インタ
ーネットなどのネットワークである。Ｘ部門１０１とＹ
部門１０２との通信にはプロバイダ１０６が介入しない
が、Ｘ部門１０１，Ｙ部門１０２とＺ部門１０３、Ｂ社
１０４又はＣ社１０５との通信にはプロバイダ１０６が
介入する。

【００１５】図２は、図１のシステム構成を展開して示
す構成図である。Ａ社のＸ部門１０１には、ユーザアプ
リケーション１１１、ロールエージェント部１２２及び
ロールルール定義データベース（ＤＢ）１２１を格納す
る少なくとも１台の計算機から成る計算機システムを設
置する。Ａ社のＹ部門１０２にも同様にユーザアプリケ
ーション１１１、ロールエージェント部１２２及びロー
ルルール定義データベース（ＤＢ）１２１を格納する少
なくとも１台の計算機から成る計算機システムを設置す
る。またＸ部門１０１及びＹ部門１０２が共有する計算
機システムとして、ビジネスエージェント部１２３、ビ
ジネスルール定義ＤＢ１１８及び業務データベース（Ｄ
Ｂ）１１２を格納する少なくとも１台の計算機から成る
計算機システムを設置する。Ｂ社１０４の計算機システ
ムは、ユーザアプリケーション１１１、ロールエージェ
ント部１２２、ロールルール定義ＤＢ１２１、ビジネス
エージェント部１２３及びビジネスルール定義ＤＢ１１
８を格納し、Ａ社の業務ＤＢ１１２を共有する。図示し
ないＡ社のＺ部門１０３の計算機システムも、Ｂ社１０
４と同様にユーザアプリケーション１１１、ロールエー
ジェント部１２２、ロールルール定義ＤＢ１２１、ビジ
ネスエージェント部１２３及びビジネスルール定義ＤＢ
１１８を格納し、業務ＤＢ１１２を共有する。Ｃ社１０
５の計算機システムは、ユーザアプリケーション１１
１、ロールエージェント部１２２、ロールルール定義Ｄ
Ｂ１２１、ビジネスエージェント部１２３及びビジネス
ルール定義ＤＢ１１８を格納するが、Ａ社の業務ＤＢ１
１２を共有せず、業務ＤＢ１１２にアクセスできない。
プロバイダ１０６の計算機システムは、アクセスルール
定義ＤＢ１２６、アクセスエージェント部１２７及びネ
ットワークスイッチング部１２８を格納する。

【００１６】業務ＤＢ１１２は、アクセス可能なユーザ
アプリケーション１１１によってアクセスされ、業務処
理の結果を案件データの形で格納する。ロールルール定
義ＤＢ１２１は、部門内ワークフロールール１１９及び
ロールテーブル１２０によって構成される。部門内ワー
クフロールール１１９は、部門内のワークフローのシー
ケンスとロールによって表現される作業担当を規定す
る。ロールテーブル１２０は、ロールと実際の担当者と
の対応を規定する。ロールエージェント部１２２は、ビ
ジネスエージェント部１２３からアクション・ノーティ
ス（Ａ／Ｎ）を受けたとき、部門内ワークフロールール
１１９及びロールテーブル１２０を参照して次に業務処
理を行う担当者を決定し、その担当者のユーザアプリケ
ーション１１１にＡ／Ｎを発行する。またユーザアプリ
ケーション１１１から処理完了通知を受けたとき、ロー
ルエージェント部１２２は、部門内ワークフロールール
１１９を参照して案件状態を次に進めるか否かを判定
し、次に進めるときにはロールテーブル１２０を参照し
て次の担当者のユーザアプリケーション１１１にＡ／Ｎ
を発行する。すなわちロールエージェント部１２２は、
Ｘ部門１０１、Ｙ部門１０２、Ｚ部門１０３など各部門
内のワークフロー制御を行う。

【００１７】ビジネスルール定義ＤＢ１１８は、案件状
態遷移基準テーブル１１３、実行可能アクションテーブ
ル１１４、論理ロールノード定義テーブル１１５、担当
ビジネスエージェントテーブル１１６及び部署定義テー
ブル１１７から構成される。案件状態遷移基準テーブル
１１３は、ワークフローが部門間に亘るようなシーケン
スの制御を行うための案件の状態遷移ルールを規定す
る。実行可能アクションテーブル１１４は、各案件状態
に遷移したときのとるべきアクションを規定し、論理ロ
ールノード定義テーブル１１５はそのアクションを実行
する論理ロールノードを規定する。論理ロールノードは
部門の名称であり、機能部門を意味する一般用語で表現
する部門名称である。担当ビジネスエージェントテーブ
ル１１６は、各論理ロールノードが当該ビジネスエージ
ェント部１２３の管理下に属するのか、管理外のものか
を規定する。部署定義テーブル１１７は、管理下の論理
ロールノードに対応して現実の担当部署の名称を規定す
る。ビジネスエージェント部１２３は、ユーザアプリケ
ーション１１１から処理完了通知を受けたとき、案件状
態遷移基準テーブル１１３を参照して案件状態が遷移し
たか否かを判定する。案件状態が遷移していれば、実行
可能アクションテーブル１１４及び論理ロールノード定
義テーブル１１５を参照して次に実行すべきアクション
とその論理ロールノードを決定し、担当ビジネスエージ
ェントテーブル１１６を参照してこの論理ロールノード
が自分の管理下の部門に該当するか否かを判定する。自
分の管理下の論理ロールノードであれば、部署定義テー
ブル１１７を参照して現実に作業を行う部署の名称を取
得してその部署を管理するロールエージェント部１２２
へＡ／Ｎを送付する。論理ロールノードが管理外の部門
であれば、アクセスエージェント部１２７へデータ送付
依頼を行う。またアクセスエージェント部１２７を介し
て別のビジネスエージェント部１２３からＡ／Ｎ発行依
頼を受けたとき、部署定義テーブル１１７を参照して指
定された論理ロールノードに対応する現実の部署名を取
得し、その部署を管理するロールエージェント部１２２
へＡ／Ｎを送付する。上記のようにビジネスエージェン
ト部１２３は、自分の管理下のロールエージェント部１
２２を起動するとともに、Ｘ部門１０１，Ｙ部門１０２
からＺ部門１０３、Ｘ部門１０１，Ｙ部門１０２からＢ
社１０４のように他の部門や企業に亘るようなワークフ
ローについて論理ロールノードという機能部門名に基づ
いてワークフロー制御を行う。

【００１８】アクセスルール定義ＤＢ１２６は、送付先
特定テーブル１２４及びアクセスルール格納テーブル１
２５から構成される。送付先特定テーブル１２４は、論
理ロールノードに対応する物理ロールノードを規定す
る。ここでいう物理ロールノードとは、Ｚ部門１０３、
Ｂ社１０４、Ｃ社１０５のようにビジネスエージェント
部１２３を有する事業所又は企業の識別子を指す。アク
セスルール格納テーブル１２５は、各物理ロールノード
から他の物理ロールノードへデータ送信するときの通信
プロトコル、セキュリティ方式などを規定する。アクセ
スエージェント部１２７は、ビジネスエージェント部１
２３からデータ送付依頼を受け取り、送付先特定テーブ
ル１２４を参照して指定された論理ロールノードに対応
するデータ送付先の物理ロールノードを決定する。また
業務ＤＢ１１２にアクセスできない物理ロールノードか
ら送付依頼を受けたとき、受け取った案件のデータ項目
値によって業務ＤＢ１１２を更新する。またデータ送付
先が業務ＤＢ１１２にアクセスできない物理ロールノー
ドであれば、業務ＤＢ１１２から取得した案件のデータ
項目値を添付する。ネットワークスイッチング部１２８
は、アクセスエージェント部１２７からデータ送付依頼
を受け取り、アクセスルール格納テーブル１２５を参照
してデータの加工を行ってからネットワークを介して指
定された物理ロールノードへデータ送付する。上記のよ
うにアクセスエージェント部１２７は、論理ロールノー
ドを対応する物理ロールノードに変換し、物理ロールノ
ードから他の物理ロールノードに対して行うデータ送信
の橋渡しを行う。

【００１９】Ｂ社１０４及びＣ社１０５もそれぞれ専用
又は他社と共用するプロバイダ１０６を有する。Ｂ社１
０４，Ｃ社１０５側のプロバイダ１０６は、Ａ社から送
られたデータをアクセスエージェント部１２７で受信
し、ネットワークスイッチング部１２８でデータ復元及
び暗号データの復号化をしてそれぞれＢ社１０４及びＣ
社１０５に渡す。Ｂ社１０４又はＣ社１０５からＡ社へ
送られるデータは、Ｂ社１０４，Ｃ社１０５側のプロバ
イダ１０６に格納されるアクセスエージェント部１２
７、ネットワークスイッチング部１２８、ネットワー
ク、Ａ社側のアクセスエージェント部１２７、及びネッ
トワークスイッチング部１２８という経路をたどってＡ
社のＸ部門１０１，Ｙ部門１０２を管理するビジネスエ
ージェント部１２３に渡される。Ａ社のＸ部門１０１，
Ｙ部門１０２とＡ社側のプロバイダ１０６並びにＢ社１
０４，Ｃ社１０５とそのプロバイダ１０６との間のセキ
ュリティは確保されており、データ転送に当ってデータ
の加工をしないものとする。

【００２０】ユーザアプリケーション１１１はクライア
ントのような計算機に格納されるプログラムである。ロ
ールエージェント部１２２、ビジネスエージェント部１
２３、アクセスエージェント部１２７及びネットワーク
スイッチング部１２８は、サーバのような計算機に格納
されるプログラムである。ロールルール定義ＤＢ１２
１、ビジネスルール定義ＤＢ１１８、業務ＤＢ１１２及
びアクセスルール定義ＤＢ１２６は、サーバのような計
算機に接続される記憶装置上に格納される。ビジネスエ
ージェント部１２３及びアクセスエージェント部１２７
のプログラムをそれぞれ記憶媒体に格納し計算機に接続
される駆動装置を介して又はネットワークを介するプロ
グラム伝送によつて計算機の主記憶装置に読み込んで実
行することが可能である。

【００２１】図３は、業務ＤＢ１１２に格納されている
１つの案件データの例を示す図である。１つの案件デー
タは、案件番号２０、発注先２１、合計金額２２、受注
サイン２３及び案件状態２４を含み、発注される商品ご
とに品目名２５、発注数量２６、発注金額２７、納期２
８及び決裁サイン２９の各データ項目を有する。合計金
額２２は、この案件のすべての品目について発注金額２
７を合計したもので、自動的に計算されるデータ項目で
ある。案件状態２４は、この案件についてのワークフロ
ーのシーケンス中で現在のステータスを示す。受注サイ
ン２３は受注が確定したことを示すサインである。決裁
サイン２９は、管理者が決裁したことを示すサインであ
る。図で「未入力」と記載されているデータ項目は、ま
だデータが入力されていないことを示す。また案件状態
２４が示す各状態に対応してその状態で各論理ロールノ
ードが案件番号２０から決裁サイン２９まで各データ項
目にアクセス可能か否かを示すテーブルを有する。「参
照可」はデータの参照のみ可能なことを示し、「参照不
可」は参照を許可しないことを示し、「更新可」はデー
タ入力又はデータ更新が可能なことを示す。

【００２２】図４は、部門内ワークフロールール１１９
のデータ例を示す図であり、各案件状態に対応してデー
タを入力するロールと入力すべきデータ項目を示してい
る。品目名、発注数量、発注金額、発注先および納期
は、図３に示す案件がもつデータ項目に対応するもので
ある。品目名と発注数量が入力されたとき、状態１に移
る。担当者が品目名、発注数量、発注金額、発注先及び
納期の各データを入力し、合計金額が計算によって入力
されると、状態２に移る。係長の決裁が入力されたと
き、発注金額又は合計金額が１００万円以上のときには
状態３に移り、そうでなければワークフローは終了す
る。状態３のステータスで課長の決裁が入力されたと
き、発注金額又は合計金額が３００万円以上のときには
状態４に移り、そうでなければワークフローは終了す
る。このテーブルで「入力」はその案件状態でデータ入
力が必要なことを示し、「−」はデータ入力がないこと
を示す。区分の列に「必須」とあるのは、ワークフロー
のシーケンスの中でその状態を通過しなければならない
ことを示し、そうでない場合には条件によってそのシー
ケンスが実行されることを示す。

【００２３】図５は、ロールテーブル１２０のデータ例
を示す図である。ロールテーブル１２０は、各ロールご
とに個人名と担当する商品又は管理する個人名の範囲を
登録する。

【００２４】図６は、ロールエージェント部１２２の処
理の流れを示すフローチャートであり、特にロールエー
ジェント部１２２がビジネスエージェント部１２３から
Ａ／Ｎ発行指示を受けて該当するユーザアプリケーショ
ン１１１にＡ／Ｎを発行する処理の流れを示す。ロール
エージェント部１２２は、ビジネスエージェント部１２
３からＡ／Ｎ発行指示を受ける（ステップ３１）。この
Ａ／Ｎ発行指示は、案件番号２０を含んでいる。ロール
エージェント部１２２は、業務ＤＢ１１２を参照して指
定された案件番号の案件を取り出し（ステップ３２）、
その案件状態２４に従って部門内ワークフロールール１
１９を参照して次のロールを判断し（ステップ３３）、
ロールテーブル１２０を参照して当該案件の条件に適合
する次の担当者の個人名を決定する（ステップ３４）。
そしてその担当者のユーザアプリケーション１１１に対
してＡ／Ｎを発行する（ステップ３５）。なお担当者と
ユーザアプリケーション１１１とは図示しないテーブル
によって対応づけられるものとする。

【００２５】ロールエージェント部１２２がビジネスエ
ージェント部１２３からＡ／Ｎ発行指示を受けたとき、
案件はその部門内の処理を開始する状態である。例えば
図３に示すように案件番号２０以外には品目名２５及び
発注数量２６のみが入力されている状態である。

【００２６】図７は、ロールエージェント部１２２の処
理の流れを示すフローチャートであり、特にロールエー
ジェント部１２２がユーザアプリケーション１１１から
処理完了通知を受けて同一部門内の他のユーザアプリケ
ーション１１１にＡ／Ｎを発行する処理の流れを示す。
ユーザアプリケーション１１１が案件の処理を終え、業
務ＤＢ１１２への書き込みを終了すると、その旨をロー
ルエージェント部１２２に通知し、ロールエージェント
部１２２はこの完了通知を受け取る（ステップ４１）。
この完了通知は案件番号２０を含んでいる。ロールエー
ジェント部１２２は、業務ＤＢ１１２を参照して指定さ
れた案件番号の案件を取り出し、その案件に対応する部
門内ワークフロールール１１９を参照する（ステップ４
２）。案件のデータ入力状態が部門内ワークフロールー
ル１１９のデータ入力状態を満足せず、現在の案件状態
の処理終了と判断されなければ（ステップ４３Ｎ）、処
理を終了する。現在の案件状態の処理終了と判断されれ
ば（ステップ４３Ｙ）、次の案件状態の処理をする担当
者が部門内ワークフロールールに定義されているか否か
を判定する（ステップ４４）。部門内に次の担当者がい
なければ（ステップ４４Ｎ）、処理を終了する。次の担
当者がいれば（ステップ４４Ｙ）、案件状態２４を次の
状態に更新する（ステップ４５）。次にロールテーブル
１２０を参照して次の案件状態のロールに該当する担当
者を決定し（ステップ４６）、その担当者のユーザアプ
リケーション１１１にＡ／Ｎを発行する（ステップ４
７）。

【００２７】ユーザアプリケーション１１１及びロール
エージェント部１２２が業務ＤＢ１１２にアクセスでき
ない場合には、ロールエージェント部１２２はビジネス
エージェント部１２３からＡ／Ｎ発行指示のほかにロー
カルファイルの名称を受け取るのでステップ３２ではこ
のローカルファイルから指定された案件を取り出して、
以下上記のようにステップ３３、ステップ３４及びステ
ップ３５を実行する。なお新規の案件の案件状態２４に
は初期状態など部門内で案件の処理を開始するときの案
件状態を設定する。決定したユーザアプリケーション１
１１へ受け取ったローカルファイルの名称を付加したＡ
／Ｎを送信する。またユーザアプリケーション１１１か
らローカルファイルの名称を有する完了通知を受けたと
き、ロールエージェント部１２２はステップ４２で指定
されたローカルファイルから指定された案件を取り出し
て、以下上記のようにステップ４２〜４７を実行する。
ステップ４７では決定した担当者のユーザアプリケーシ
ョン１１１へローカルファイルの名称を指定したＡ／Ｎ
を発行する。

【００２８】図８は、案件状態遷移基準テーブル１１３
のデータ例を示す図である。案件状態遷移基準テーブル
１１３は、案件状態を遷移させる条件を定義するテーブ
ルであり、特にある部門から他の部門へまたはある部門
から他の企業へアクションを起こす契機となる案件状態
と状態遷移の条件を定義する。この例で「入力」は、そ
の案件状態でデータが入力されるデータ項目を示し、デ
ータが確定でない限り後の案件状態でそのデータを修正
することが可能である。また「×」は、その案件状態で
はデータ入力できないデータ項目を示す。「入力可」は
その案件状態でデータ入力可能であるが、後の案件状態
でデータ入力してもよいデータ項目を示す。「−」は前
の案件状態ですでにデータが確定しているデータ項目を
示す。例えば「トリガー」の項目に示すように、「発注
処理待ち」の状態で案件番号、品目名、発注数量及び納
期が入力されれば、次の案件状態に遷移する。また「発
注処理中」の状態で決裁サインが入力されれば、次の案
件状態に遷移する。また「受注確認待ち」で受注サイン
が入力されれば、すべてのデータ項目が確定し、次の案
件状態に遷移する。

【００２９】図９は、実行可能アクションテーブル１１
４のデータ例を示す図である。実行可能アクションテー
ブル１１４は、案件状態遷移基準テーブル１１３によっ
て定義される案件状態となったとき実行可能なアクショ
ンを定義する。

【００３０】図１０は、論理ロールノード定義テーブル
１１５のデータ例を示す図である。論理ロールノード定
義テーブル１１５は、アクションを実行する論理ロール
ノードを定義する。論理ロールノードは部門の名称を一
般用語で表現するものであるが、ここでいう部門は機能
部門を意味し、一般にＸ部門１０１、Ｙ部門１０２、Ｂ
社１０４のように事業所や企業のような物理的なノード
とは一致しない。

【００３１】図１１は、担当ビジネスエージェントテー
ブル１１６のデータ例を示す図である。担当ビジネスエ
ージェントテーブル１１６は、論理ロールノード定義テ
ーブル１１５によつて定義される論理ロールノードに対
応して担当するエージェントを定義する。担当エージェ
ントは、当該担当ビジネスエージェントテーブル１１６
を管理するビジネスエージェント部１２３か又はアクセ
スエージェント部１２７を定義する。当該ビジネスエー
ジェント部１２３の管理外である自社部門又は他社部門
はアクセスエージェント部１２７が担当する。

【００３２】図１２は、部署定義テーブル１１７のデー
タ例を示す図である。部署定義テーブル１１７は、当該
ビジネスエージェント部１２３の管理する論理ロールノ
ード（機能部門）の識別子に対応して現実の担当部門の
識別子とその担当部門を選択する条件を定義する。なお
選択条件は、案件データの内容から判定し得るものとす
る。また担当部門は、いずれかのロールエージェント部
１２２の管理下にあるから担当部門に関係するロールエ
ージェント部１２２の識別子（またはロールエージェン
ト部１２２が所在するサーバの識別子）を付加すると、
部署定義テーブル１１７を参照することによって目的の
ロールエージェント部１２２とその管理下の部署名を特
定できる。

【００３３】図１３は、ビジネスエージェント部１２３
の処理の流れを示すフローチャートであり、特にビジネ
スエージェント部１２３がユーザアプリケーション１１
１から処理完了通知を受けて他の部門へＡ／Ｎを発行す
る処理の流れを示す。ビジネスエージェント部１２３
は、ユーザアプリケーション１１１から案件番号２０を
含む処理完了通知を受け取ると（ステップ５１）、業務
ＤＢ１１２を参照して指定された案件番号の案件を取り
出し、その案件に対応する案件状態遷移基準テーブル１
１３を参照する（ステップ５２）。現在の案件状態２４
に対応する案件状態遷移基準テーブル１１３上の案件状
態のデータ入力条件を突き合わせ、案件の状態を遷移す
べきか否か判定する（ステップ５３）。案件状態遷移の
条件を満足しなければ（ステップ５３Ｎ）、処理を終了
する。案件状態遷移の条件を満足するとき（ステップ５
３Ｙ）、案件状態２４を次の状態に更新する（ステップ
５４）。次にこの条件に対応する実行可能アクションテ
ーブル１１４を参照して、実行可能なアクションを読み
取り、論理ロールノード定義テーブル１１５を参照して
次に処理を行う論理ロールノードを読み取る（ステップ
５５）。次に担当ビジネスエージェントテーブル１１６
を参照して次に処理を行う論理ロールノードを担当する
エージェント部を判断する（ステップ５６）。担当エー
ジェント部が自分であれば（ステップ５７Ｙ）、部署定
義テーブル１１７を参照して現実の担当部門を決定する
（ステップ５８）。担当部門に条件がある場合には、案
件データを参照して条件に合致する担当部門を決める。
次に決定した部門のロールエージェント部１２２へＡ／
Ｎを送付する（ステップ５９）。担当エージェント部が
自分でなければ（ステップ５７Ｎ）、アクセスエージェ
ント部１２７へデータ送付依頼を行う（ステップ６
０）。このデータ送付依頼は、案件番号２０、データ送
付先の論理ロールノードを含んでいる。

【００３４】上記のようにユーザアプリケーション１１
１は、部門内のワークフロー・シーケンスを制御すると
ともに部門間のワークフロー・シーケンスを制御するた
めに、ロールエージェント部１２２とビジネスエージェ
ント部１２３の両方に完了報告を送る。なお業務処理の
シーケンスが必ずしも直列ではなく、ある部門内の処理
が完結していなくても別部門での業務処理を先行して始
められる可能性がある。例えば図４に示すワークフロー
・シーケンスの例の場合、発注金額が１００万円以上の
品目については課長レベルのサインがなければ部門内の
処理は完結しないが、その他の品目については主任レベ
ルの決裁サインがあれば処理が完結する。このように部
門内の処理が完結した部分に関して他部門が先行して引
き取り、処理を行うことが可能である。

【００３５】ユーザアプリケーション１１１及びビジネ
スエージェント部１２３が業務ＤＢ１１２にアクセスで
きない場合には、ビジネスエージェント部１２３は、ユ
ーザアプリケーション１１１から案件番号２０と当該案
件を格納するローカルファイルの名称を受け取る。次に
指定されたローカルファイルから指定された案件データ
を取り出し、現在の案件状態２４に対応する案件状態遷
移基準テーブル１１３上の案件状態のデータ入力条件を
突き合わせ、案件の状態を遷移すべきか否か判定する。
状態遷移しない場合には、処理を終了する。案件の状態
を遷移すべき場合には、論理ロールノード定義テーブル
１１５を参照して次に処理を行う論理ロールノードと処
理完了した論理ロールノードを読み取り、ステップ５６
及びステップ５７を実行する。担当エージェント部が自
分であれば、ステップ５８を実行し、決定した部門のロ
ールエージェント部１２２へ当該ローカルファイル名称
を付加したＡ／Ｎを送付する。担当エージェント部が自
分でなければ、アクセスエージェント部１２７へデータ
送付依頼を行う。このデータ送付依頼は、案件番号２
０、データ送付先の論理ロールノード、処理完了した論
理ロールノード、当該案件に含まれるデータ項目名とそ
のインスタンス値、及び次に遷移すべき案件状態２４の
値を含んでいる。

【００３６】図１４は、ビジネスエージェント部１２３
の処理の流れを示すフローチャートであり、特にビジネ
スエージェント部１２３が他のビジネスエージェント部
１２３からＡ／Ｎ発行依頼を受けて該当する部門へＡ／
Ｎを発行する処理を示す。ビジネスエージェント部１２
３は、アクセスエージェント部１２７とネットワークス
イッチング部１２８を介して他のビジネスエージェント
部１２３からＡ／Ｎ発行依頼を受け取る（ステップ６
１）。このＡ／Ｎ発行依頼は、案件番号２０とデータ送
付先の論理ロールノードを含んでいる。次に業務ＤＢ１
１２を参照して指定された案件番号の案件を取り出し
（ステップ６２）、部署定義テーブル１１７を参照して
論理ロールノードに対応する現実の担当部門を決定する
（ステップ６３）。担当部門に条件がある場合には、案
件データを参照して条件に合致する担当部門を決める。
最後に決定した部門を管理するロールエージェント部１
２２へＡ／Ｎを送付する（ステップ６４）。このＡ／Ｎ
は案件の案件番号２０を含んでいる。

【００３７】ユーザアプリケーション１１１及びビジネ
スエージェント部１２３が業務ＤＢ１１２にアクセスで
きない場合には、ビジネスエージェント部１２３は別の
ビジネスエージェント部１２３から案件番号２０とデー
タ送付先の論理ロールノードのほかにデータ項目名とそ
のインスタンス値を受け取る。ビジネスエージェント部
１２３は指定された案件番号をもつ案件が新規の案件で
あればローカルファイル上にこの案件番号をもつ案件デ
ータを追加する。すでにローカルファイルに登録された
案件であれば、受け取ったデータによってファイル中の
案件データを更新する。次に上記のようにステップ６３
及びステップ６４を実行する。決定した部門のロールエ
ージェント部１２２へローカルファイルの名称を付加し
たＡ／Ｎを送付する。

【００３８】図１５は、送付先特定テーブル１２４のデ
ータ例を示す図である。送付先特定テーブル１２４は、
論理ロールノードに対応する物理ロールノードとその物
理ロールノードを選択する条件を定義する。物理ロール
ノードの宛先は、その物理ロールノードを管理するビジ
ネスエージェント部１２３が所在するサーバ（ホスト）
が該当する。従ってそのビジネスエージェント部１２３
に関する識別子又はそのサーバの識別子を定義してもよ
い。なお物理ロールノードの選択条件は、案件データの
内容から判定し得るものとする。

【００３９】図１６は、アクセスルール格納テーブル１
２５のデータ例を示す図である。アクセスルール格納テ
ーブル１２５は、物理ロールノードごとに業務ＤＢ１１
２へのアクセスの可否を設定し、宛先の物理ロールノー
ドに対応してネットワークの種類、エンコード／デコー
ド方式およびセキュリティ方式を設定する。ネットワー
クの種類は、物理ネットワークの種類、通信プロトコル
等である。エンコード／デコード方式はデータ圧縮と復
元の方式、セキュリティ方式は暗号化の方式を設定す
る。ただしネットワークの種類や宛先の物理ロールノー
ドによって暗号化が不要であればその旨設定する。

【００４０】図１７は、アクセスエージェント部１２７
の処理の流れを示すフローチャートである。アクセスエ
ージェント部１２７は、ビジネスエージェント部１２３
からデータ送付依頼を受け取る（ステップ７１）。この
データ送付依頼は、案件番号２０とデータ送付先の論理
ロールノードを含んでいる。またデータ送付元の論理ロ
ールノードが業務ＤＢ１１２にアクセスできない部門の
場合には、さらに当該案件についてデータ項目名とその
インスタンス値、処理完了した論理ロールノード及び次
に遷移すべき案件状態２４の値を含んでいる。アクセス
エージェント部１２７は、業務ＤＢ１１２を参照して指
定された案件番号の案件を取り出し、受け取ったデータ
項目値によって業務ＤＢ１１２を更新する（ステップ７
２）。ただしこの更新は、業務ＤＢ１１２を参照して当
該案件の現在の案件状態２４に関してデータ送付元の論
理ロールノードが「更新可」のデータ項目に限られ、他
のデータ項目名があれば無視される。この更新を行った
後に当該案件の案件状態２４を受け取った案件状態２４
の値によつて更新する。次に送付先特定テーブル１２４
を参照してデータ送付先の論理ロールノードに対応する
宛先の物理ロールノードを特定する（ステップ７３）。
送付先に条件がある場合には、案件データを参照して条
件に合致する送付先を選択する。次に宛先の物理ロール
ノードが複数あるか否か判定する（ステップ７４）。宛
先の物理ロールノードが単一であれば（ステップ７４
Ｎ）、ステップ７７へ行く。宛先の物理ロールノードが
複数あれば（ステップ７４Ｙ）、案件の種類によって宛
先の物理ロールノードが単一であるべきか否かを判定す
る（ステップ７５）。宛先の物理ロールノードが複数あ
り得る場合には（ステップ７５Ｎ）、ステップ７７へ行
く。宛先の物理ロールノードが１つに限る場合には（ス
テップ７５Ｙ）、データ送付依頼を送ってきたビジネス
エージェント部１２３に対しエラー通知を送る（ステッ
プ７６）。このエラー通知は、ユーザアプリケーション
１１１へデータ送付先を単一指定するようＡ／Ｎを送る
よう依頼するものである。例えば図１５に示す送付先特
定テーブル１２４の例では、品目名がＶＴＲという条件
の下に物理ロールノードとしてＢ社とＣ社の２つが選択
されるので、案件が商品発注の場合にはエラーと判断さ
れる。しかし案件が見積り依頼の場合にはデータ送付先
が複数あってもよいのでエラーと判定しない。案件の種
類は、案件番号２０又は案件がもつデータ項目名（属性
名）から判断される。ステップ７７では、アクセスエー
ジェント部１２７は、宛先となる物理ロールノードにつ
いてアクセスルール格納テーブル１２５を参照し、宛先
の物理ロールノードは対象とする業務ＤＢ１１２にアク
セス可能か否かを判定する（ステップ７７）。データ送
付先が業務ＤＢ１１２にアクセスできない場合には（ス
テップ７７Ｎ）、業務ＤＢ１１２を参照して当該案件の
現在の案件状態２４に関してデータ送付先の論理ロール
ノードが「参照可」及び「更新可」のデータ項目名とそ
のインスタンス値を付加し、ネットワークスイッチング
部１２８へデータ送付依頼を行う（ステップ７８）。デ
ータ送付先が業務ＤＢ１１２にアクセス可能な場合には
（ステップ７７Ｙ）、ネットワークスイッチング部１２
８へデータ送付依頼を行う（ステップ７９）。これらの
データ送付依頼は、いずれも案件の案件番号２０、宛先
の論理ロールノード及び物理ロールノードを含んでい
る。

【００４１】図１８は、ネットワークスイッチング部１
２８の処理の流れを示すフローチャートである。ネット
ワークスイッチング部１２８は、アクセスエージェント
部１２７からデータ送付依頼を受け取り（ステップ８
１）、アクセスルール格納テーブル１２５を参照してデ
ータ送付先までのネットワークの種類等を決定する（ス
テップ８２）。そしてこの決定に従って送られてきたデ
ータの加工を行い、指定された物理ロールノードのビジ
ネスエージェント部１２３へＡ／Ｎ発行依頼を送付する
（ステップ８３）。

【００４２】なお、本発明の原則からは外れるが、この
ようにエージェント部によってデータ送付先を決定する
のではなく、作業工程の担当者がユーザアプリケーショ
ン１１１を介して送付先を指定することも可能である。
例えば発注や見積り処理を行うに際し、担当者がその依
頼先を指定する場合などがこれに相当する。この場合は
アクセスエージェント部１２７の判断よりもこの担当者
による指定が優先される。以下担当者がデータ送付先を
指定する場合の処理の流れについて説明する。

【００４３】まず担当者はユーザアプリケーション１１
１の誘導によって業務処理を行い、処理が終了したと
き、完了通知をロールエージェント部１２２とビジネス
エージェント部１２３に対し発行する。このときデータ
送付先を指定する。これを受けてロールエージェント部
１２２は上記したように部門内のワークフローを制御す
る。ビジネスエージェント部１２３は、ユーザアプリケ
ーション１１１から通知を受けて案件状態の遷移が起こ
ったかどうかを判断する。そして状態遷移が起こったと
判断した場合は、図示しないテーブルによって指定され
たデータ送付先が属する論理ロールノードを決定する。
次に担当ビジネスエージェントテーブル１１６を参照し
てどこのビジネスエージェントがこの論理ロールノード
を管轄しているかを判断する。それが自分であった場合
は、そのデータ送付先を管轄するロールエージェント部
１２２に対しＡ／Ｎを発行する。他部門もしくは社外の
場合は、アクセスエージェント部１２７に対してデータ
送付依頼を行う。ここでアクセスエージェント部１２７
は、送付先特定テーブル１２４を参照して論理ロールノ
ードに対応する物理的なデータ送付先を特定する代わり
に、ユーザアプリケーション１１１の指定するデータ送
付先を優先し、これを宛先の物理ロールノードとみな
す。その後、上記のようにそのデータ送付先の属する論
理ロールノードが業務ＤＢ１１２にアクセスできるかど
うかを判断し、必要ならば業務ＤＢ１１２上の案件のデ
ータ項目名とインスタンス値を付加してネットワークス
イッチング部１２８にデータ送付依頼を行う。そしてネ
ットワークスイッチング部１２８がデータの加工を行
い、指定されたデータ送付先へデータの送付を行う。

【００４４】また企業間取引システムを構成する複数の
企業の中には、ビジネスエージェント部１２３を設けな
い企業が存在してもよい。このような企業は上記のよう
な企業間に亘るワークフロー制御を行うことはできない
が、他の企業からアクセスエージェント部１２７を経由
してデータ送付先及びデータ送付元を指定した案件デー
タを受け取り、アクセスエージェント部１２７を経由し
てデータ送信元の企業へ回答データを送付することが可
能である。

【００４５】なお図２に示す実施形態では、アクセスエ
ージェント部１２７、アクセスルール定義データベース
１２６及びネットワークスイッチング部１２８は、プロ
バイダ１０６としてＡ社の計算機システムから独立して
いるが、Ａ社のような企業のもつ計算機システムの中で
実現することも可能である。

【００４６】

【発明の効果】以上述べたように本発明によれば、シス
テムは企業内の業務処理についてワークフロー制御をす
るとともに企業間に亘るワークフロー制御をするが、企
業内又は企業間で必要となるデータ送付はワークフロー
制御システムが行うので、ユーザアプリケーション及び
業務処理担当者は原則としてこのようなデータ送付に関
知する必要がない。ワークフロー制御システムは、取引
内容に応じてデータ送付方法及びデータ送付先を決定
し、複数企業間に亘る信頼性が高く効率的なワークフロ
ー制御を実現する。またワークフロー制御システムは、
企業間に介在するネットワークの種類に応じて通信方式
を決定し、データの圧縮や暗号化を行うので、ユーザア
プリケーションはこのような通信方式、データ伝送時の
データの加工及びセキュリティの確保についても意識す
る必要がない。

【図面の簡単な説明】

【図１】システム構成の例を概略的に示す図である。

【図２】実施形態のシステムの構成要素を示す図であ
る。

【図３】業務データベース１１２に格納される１つの案
件データの例を示す図である。

【図４】部門内ワークフロールール１１９のデータ例を
示す図である。

【図５】ロールテーブル１２０のデータ例を示す図であ
る。

【図６】ビジネスエージェント部１２３からＡ／Ｎ発行
指示を受けたときのロールエージェント部１２２の処理
の流れを示すフローチャート例である。

【図７】ユーザアプリケーション１１１から処理完了通
知を受けたときのロールエージェント部１２２の処理の
流れを示すフローチャート例である。

【図８】案件状態遷移基準テーブル１１３のデータ例を
示す図である。

【図９】実行可能アクションテーブル１１４のデータ例
を示す図である。

【図１０】論理ロールノード定義テーブル１１５のデー
タ例を示す図である。

【図１１】担当ビジネスエージェントテーブル１１６の
データ例を示す図である。

【図１２】部署定義テーブル１１７のデータ例を示す図
である。

【図１３】ユーザアプリケーション１１１から処理完了
通知を受けたときのビジネスエージェント部１２３の処
理の流れを示すフローチャート例である。

【図１４】他のビジネスエージェント部１２３からＡ／
Ｎ発行依頼を受けたときのビジネスエージェント部１２
３の処理の流れを示すフローチャート例である。

【図１５】送付先特定テーブル１２４のデータ例を示す
図である。

【図１６】アクセスルール定義テーブル１２５のデータ
例を示す図である。

【図１７】アクセスエージェント部１２７の処理の流れ
を示すフローチャート例である。

【図１８】ネットワークスイッチング部１２８の処理の
流れを示すフローチャート例である。

【符号の説明】

１１１：ユーザアプリケーション、１１２：業務データ
ベース、１１３：案件状態遷移基準テーブル、１１４：
実行可能アクションテーブル、１１５：論理ロールノー
ド定義テーブル、１１６：担当ビジネスエージェントテ
ーブル、１１７：部署定義テーブル、１２２：ロールエ
ージェント部、１２３：ビジネスエージェント部、１２
４：送付先特定テーブル、１２５：アクセスルール格納
テーブル、１２７：アクセスエージェント部、１２８：
ネットワークスイッチング部

───────────────────────────────────────────────────── フロントページの続き (72)発明者細田直文神奈川県横浜市都筑区加賀原二丁目２番株式会社日立製作所ビジネスシステム開発センタ内 (72)発明者曽我修治神奈川県横浜市都筑区加賀原二丁目２番株式会社日立製作所ビジネスシステム開発センタ内 (72)発明者矢加部太郎神奈川県横浜市都筑区加賀原二丁目２番株式会社日立製作所ビジネスシステム開発センタ内

Claims

【特許請求の範囲】

【請求項１】電子計算機を利用するワークフロー制御方
法において、案件データに関する業務処理の終了を検知
したとき、該案件データのデータ入力状態に従って部門
内のワークフロー・シーケンスの中で次に処理すべき担
当者を規定する部門内のワクフロールールに基づいて次
の担当者が処理すべき案件状態か否かを判定し、次の担
当者が処理すべき案件状態に達していれば次の担当者に
アクション・ノーティスを発行し、該案件データに関する該業務処理の終了を検知したと
き、該案件データのデータ入力状態に従って部門間に亘
るワークフロー・シーケンスの中で次に処理すべき部門
を規定する部門間のワークフロールールに基づいて次の
部門が処理すべき案件状態か否かを判定し、次の部門が
処理すべき案件状態に達していれば次の部門に対してア
クション・ノーティスを発行し、次の部門に対するアクション・ノーティスを受けて部門
内の該ワークフロールールに基づいて上記の部門内ワー
クフロー制御を行うことを特徴とする状態監視型ワーク
フローの制御方法。
【請求項２】該次の部門は、一般用語で表現される機能
部門であり、該機能部門の識別子と現実に存在する部門
の識別子との対応を格納するテーブルを参照して該次の
部門の識別子を現実の部門の識別子に変換した後に次の
部門に対してアクション・ノーティスを発行することを
特徴とする請求項１記載の状態監視型ワークフロー制御
方法。
【請求項３】該テーブルは該案件データの内容に応じて
該機能部門に対応する実在部門が設定されたテーブルで
あり、該案件データの内容と該テーブルの案件データの
内容とを突き合わせて現実の部門を決定することを特徴
とする請求項２記載の状態監視型ワークフローの制御方
法。
【請求項４】該案件データは業務データベースに格納さ
れたデータであり、該次の部門が該データベースにアク
セス不可の場合には、該アクション・ノーティスととも
に該案件データに含まれるデータ項目名とそのインスタ
ンス値を該次の部門に送付することを特徴とする請求項
１記載の状態監視型ワークフローの制御方法。
【請求項５】電子計算機を利用してワークフロー制御を
行う計算機システムであり、部門内のワークフローを制
御する第１のエージェント手段と、部門間のワークフロ
ーを制御する第２のエージェント手段と、第２のエージ
ェント手段と他の第２のエージェント手段との間のデー
タ転送を行う第３のエージェント手段とを有するシステ
ムであって、第１のエージェント手段は、案件データに関する業務処
理の終了を検知したとき、該案件データのデータ入力状
態に従って部門内のワークフロー・シーケンスの中で次
に処理すべき担当者を規定する部門内のワークフロール
ールに基づいて次の担当者が処理すべき案件状態か否か
を判定し、次の担当者が処理すべき案件状態に達してい
れば次の担当者にアクション・ノーティスを発行する手
段と、次の部門に対するアクション・ノーティスを受け
て部門内の該ワークフロールールに基づいて上記の部門
内ワークフロー制御を行う手段とを有し、第２のエージェント手段は、該案件データに関する業務
処理の終了を検知したとき、該案件データのデータ入力
状態に従って部門間に亘るワークフロー・シーケンスの
中で次に処理すべき部門を規定する部門間のワークフロ
ールールに基づいて次の部門が処理すべき案件状態か否
かを判定し、次の部門が処理すべき案件状態に達してい
る場合に該次の部門が管理下の部門に属するか管理外の
部門に属するかを判定し、管理下の部門に属する場合に
は管理下の第１のエージェント手段に対してアクション
・ノーティスを発行し、管理外の部門に属する場合には
第３のエージェント手段へデータ送付依頼を行う手段
と、第３のエージェント手段からアクション・ノーティ
スを受け取って宛先となる第１のエージェント手段に対
してアクション・ノーティスを発行する手段とを有し、第３のエージェント手段は、第２のエージェント手段か
らデータ送付依頼を受け取って該次の部門を管理する第
２のエージェント手段を決定し、決定した第２のエージ
ェント手段に対してアクション・ノーティスを送付する
手段を有することを特徴とする状態監視型ワークフロー
を制御する計算機システム。
【請求項６】該次の部門は、一般用語で表現される機能
部門であり、第３のエージェント手段は、該機能部門の
識別子と第２のエージェント手段に関する識別子との対
応を格納する第３のテーブルを参照して第２のエージェ
ント手段から受け取った該次の部門の識別子を別の第２
のエージェント手段に関する識別子に変換した後に該別
の第２のエージェント手段に対してアクション・ノーテ
ィスを送付する手段を有し、該別の第２のエージェント
手段は、該機能部門の識別子と第１のエージェント手段
に関する識別子との対応を格納する第２のテーブルを参
照して第３のエージェント手段から受け取った該次の部
門の識別子を管理下の第１のエージェント手段に関する
識別子に変換した後に宛先となる第１のエージェント手
段に対してアクション・ノーティスを発行する手段を有
することを特徴とする請求項５記載の状態監視型ワーク
フローを制御する計算機システム。
【請求項７】第３のテーブルは該案件データの内容に応
じて該機能部門に対応する第２のエージェント手段に関
する識別子が設定されたテーブルであり、第２のテーブ
ルは該案件データの内容に応じて該機能部門に対応する
第１のエージェント手段に関する識別子が設定されたテ
ーブルであり、第３のエージェント手段は、該案件デー
タの内容と第３のテーブルの案件データの内容とを突き
合わせてアクション・ノーティスを送付する第２のエー
ジェント手段を決定する手段を有し、第２のエージェン
ト手段は、該案件データの内容と第２のテーブルの案件
データの内容とを突き合わせてアクション・ノーティス
を発行する第１のエージェント手段を決定する手段を有
することを特徴とする請求項６記載の状態監視型ワーク
フローを制御する計算機システム。
【請求項８】該案件データは業務データベースに格納さ
れたデータであり、第３のエージェント手段は、該次の
部門が該データベースにアクセス不可の場合には、該ア
クション・ノーティスとともに該案件データに含まれる
データ項目名とそのインスタンス値を該次の部門に送付
する手段を有することを特徴とする請求項５記載の状態
監視型ワークフローを制御する計算機システム。
【請求項９】コンピュータ読み取り可能な記憶媒体上に
実体化されるコンピュータプログラムであって、該プロ
グラムはコンピュータを利用してワークフロー制御を行
う計算機システムで実行されるプログラムであり、該計
算機システムは、部門内のワークフローを制御する第１
のエージェント手段と、部門間のワークフローを制御す
る第２のエージェント手段と、第２のエージェント手段
と他の第２のエージェント手段との間のデータ転送を行
う第３のエージェント手段とを有し、第１のエージェン
ト手段は、案件データに関する業務処理の終了を検知し
たとき、該案件データのデータ入力状態に従って部門内
のワークフロー・シーケンスの中で次に処理すべき担当
者を規定する部門内のワークフロールールに基づいて次
の担当者が処理すべき案件状態か否かを判定し、次の担
当者が処理すべき案件状態に達していれば次の担当者に
アクション・ノーティスを発行する手段と、次の部門に
対するアクション・ノーティスを受けて部門内の該ワー
クフロールールに基づいて上記の部門内ワークフロー制
御を行う手段とを有し、第３のエージェント手段は、第
２のエージェント手段からデータ送付依頼を受け取って
該次の部門を管理する第２のエージェント手段を決定
し、決定した第２のエージェント手段に対してアクショ
ン・ノーティスを送付する手段を有し、第２のエージェ
ント手段の処理を実行する該プログラムは以下のステッ
プを含む：（ａ）該案件データに関する業務処理の終了を検知した
とき、該案件データのデータ入力状態に従って部門間に
亘るワークフロー・シーケンスの中で次に処理すべき部
門を規定する部門間のワークフロールールに基づいて次
の部門が処理すべき案件状態か否かを判定し、（ｂ）次
の部門が処理すべき案件状態に達している場合に該次の
部門が管理下の部門に属するか管理外の部門に属するか
を判定し、管理下の部門に属する場合には管理下の第１
のエージェント手段に対してアクション・ノーティスを
発行し、管理外の部門に属する場合には第３のエージェ
ント手段へデータ送付依頼を行い、（ｃ）第３のエージ
ェント手段からアクション・ノーティスを受け取って宛
先となる第１のエージェント手段に対してアクション・
ノーティスを発行する。
【請求項１０】コンピュータ読み取り可能な記憶媒体上
に実体化されるコンピュータプログラムであって、該プ
ログラムはコンピュータを利用してワークフロー制御を
行う計算機システムで実行されるプログラムであり、該
計算機システムは、部門内のワークフローを制御する第
１のエージェント手段と、部門間のワークフローを制御
する第２のエージェント手段と、第２のエージェント手
段と他の第２のエージェント手段との間のデータ転送を
行う第３のエージェント手段とを有し、第１のエージェ
ント手段は、案件データに関する業務処理の終了を検知
したとき、該案件データのデータ入力状態に従って部門
内のワークフロー・シーケンスの中で次に処理すべき担
当者を規定する部門内のワークフロールールに基づいて
次の担当者が処理すべき案件状態か否かを判定し、次の
担当者が処理すべき案件状態に達していれば次の担当者
にアクション・ノーティスを発行する手段と、次の部門
に対するアクション・ノーティスを受けて部門内の該ワ
ークフロールールに基づいて上記の部門内ワークフロー
制御を行う手段とを有し、第２のエージェント手段は、
該案件データに関する業務処理の終了を検知したとき、
該案件データのデータ入力状態に従って部門間に亘るワ
ークフロー・シーケンスの中で次に処理すべき部門を規
定する部門間のワークフロールールに基づいて次の部門
が処理すべき案件状態か否かを判定し、次の部門が処理
すべき案件状態に達している場合に該次の部門が管理下
の部門に属するか管理外の部門に属するかを判定し、管
理下の部門に属する場合には管理下の第１のエージェン
ト手段に対してアクション・ノーティスを発行し、管理
外の部門に属する場合には第３のエージェント手段へデ
ータ送付依頼を行う手段と、第３のエージェント手段か
らアクション・ノーティスを受け取って宛先となる第１
のエージェント手段に対してアクション・ノーティスを
発行する手段とを有し、第３のエージェント手段の処理
を実行する該プログラムは以下のステップを含む：（ａ）第２のエージェント手段からデータ送付依頼を受
け取って該次の部門を管理する第２のエージェント手段
を決定し、（ｂ）決定した第２のエージェント手段に対
してアクション・ノーティスを送付する。