JP2002189842A

JP2002189842A - ワークフロー管理制御システムとその方法並びにワークフロー管理制御プログラムを記録した記録媒体

Info

Publication number: JP2002189842A
Application number: JP2000386078A
Authority: JP
Inventors: Naoki Nakao; 直樹中尾; Takashi Inoue; 貴司井上; Tadashi Kotani; 忠司小谷; Yukio Akiyama; 幸生秋山
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2000-12-19
Filing date: 2000-12-19
Publication date: 2002-07-05
Anticipated expiration: 2020-12-19
Also published as: JP3667230B2

Abstract

(57)【要約】【課題】個別にプロセス定義をしなくても、多様化す
るワークフローの自動的な管理と制御を可能にする手法
を確立する。【解決手段】ワークフローのデータ種別を状態変数と
し、データ種別毎の進捗状態を記録する手段と、オーダ
内容に従った目標となる状態を記録する手段と、状態を
目標の状態に近づける基本フローを選択する手段と、基
本フローを実行又は実行指示できる権限者に依頼する手
段と、状態が目標状態に到達したか否かを判断する手段
等を具備する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コンピュータある
いはコンピュータネットワークを利用して、ワークフロ
ーを管理制御するための技術分野に関する。

【０００２】

【従来の技術】ワークフローとは一般に仕事の流れをい
い、会社内での決済や工場での製造などの複数の担当
（部門）をまたがる仕事の場合、資材調達や工事手配な
どの複数の会社をまたがる仕事の場合には必ず存在する
ものである。従来はこのような仕事の流れを伝票をまわ
すことで管理又は制御している。

【０００３】例えば受注生産で商品を製造する工場で
は、営業部門がお客様から受注する際、工場に納品可能
な日時を問い合わせると、工場では部品の在庫調査、作
業者の手配などから納品できる日時を特定する必要があ
るが、備品の種類によって管理する担当やデータベース
が異なることがあったり、作業者の管理を別担当が行っ
ている場合もある。この場合に在庫調査、作業者の手配
をする担当が数カ所に分かれることとなり、すべての担
当からの結果が判明しなければ営業担当者はお客様に正
確な納品日を回答することができない。また、商品の種
類が増えると、必要な部品の種類が増えるだけではな
く、商品毎に組合せが異なったり、作業者のスキルを考
慮した手配も必要となってくる。別な例としては、通信
サービスをお客様が申し込む際に、通信事業者は所外の
ケーブル設備に空き設備はあるのか、装置に空きはある
のか等を確認する。しかし、通信関係の設備は膨大な量
があるため、所外ケーブルのデータベースと装置関係の
データベースとは別々に構築されており、一般的にはそ
れらのデータベースを維持管理する担当（部門）も異な
る。したがって、空きの確認をするためには複数の担当
（部門）へ問い合わせる必要がある。また、近年の通信
サービスや通信設備の多様化によって、確認する内容も
多様化が要求されている。

【０００４】一方で、ワークフロー管理を目的としたシ
ステム、ソフトウェアの実用化も進められており、いく
つかの製品がある。代表的な製品では、ビジュアルなプ
ロセス定義機能などを有しており、ユーザインターフェ
ースの優しさなどが実現してきている。しかし、商品や
サービスが多様化し、部品の調査、作業者の手配、設備
の確認などの項目が多様化してくれば、プロセス定義の
数も増加せざるをえない。また、これらの製品ではプロ
セス定義のしやすさは実現してきているが、自動的なワ
ークフロー制御までを実現するには至っていない。特に
エラー処理までを考慮すると、分岐の数も膨大となり定
義を完成させることには多くの労力が必要となる。

【０００５】

【発明が解決しようとする課題】本発明の目的は、コン
ピュータやコンピュータネットワークによりワークフロ
ーを管理制御するにあたり、個別にプロセス定義をしな
くても多様化するワークフローの自動的な管理と制御を
可能とする技術を確立することにある。

【０００６】

【課題を解決するための手段】本発明は、ワークフロー
を管理制御するにあたり、オーダを実行していく段階で
設計情報等が登録されていくデータ項目を、同時に登録
される複数のデータ項目は１つのデータ種別として扱
い、データ種別毎に進捗状況を管理することでワークフ
ローを管理する。また、データ種別はオーダの進捗を知
るための状態変数として扱い、データ種別毎の進捗を数
値化した状態によって全体の進捗を把握することを可能
にしている。さらに、特定のデータ種別の値を変更でき
る仕事の単位を基本フローとして登録しておくことと、
基本フローを実行又は実行指示できる権限を有する者を
権限種別やエリア種別から特定できるよう登録しておく
ことによって、把握された状態を目標の状態に近づけて
いくことを可能にしている。

【０００７】現在の進捗を状態として把握し、オーダが
正常に終了した時の状態を目標の状態とすることで状態
を変えなければならないデータ種別が把握でき、当該デ
ータ種別を変更できる基本フローを選択することができ
る。この選択にあたって処理に順番がある場合等には、
基本フローを実行するために必要なデータが既知となっ
ているか否かの判断工程を加えることで処理の順番管理
も可能となる。また、基本フローの処理や選択のプロセ
スでエラーが生じることもあり、エラー発生原因を状態
から把握することで適切な権限を有する者にエラー発生
を通知することが可能となる。さらに、基本フローを実
行するためには実行できる権限者を見つける必要があ
り、権限はエリアによって異なる場合もある。そこで、
権限種別とエリア種別とを組み合わせて実行権限を有す
る者を選択し、基本フローの実行を依頼することでワー
クフローを進めることができる。

【０００８】このように、進捗状態の把握、基本フロー
と実行権限の管理によって、ワークフロー制御を行う上
でエラー処理を含めた一連の流れを定義（プロセス定
義）する必要が無くなり、新たなワークフローが必要と
なった場合にも状態変数の追加、基本フローの追加、実
行種別の追加で対応できる点が従来技術と異なる。

【０００９】

【発明の実施の形態】以下、本発明の一実施の形態につ
いて図面により説明する。図１は本発明によるワークフ
ロー管理制御システムの一実施例の全体システム構成を
示した図である。図中、１０は本システムの主要部のワ
ークフロー制御サーバであり、制御モジュール１１と権
限情報データベース（ＤＢ）１２を具備している。２１
は営業部門の操作端末であり、営業所等に設置される端
末や営業マン等が携帯する端末等を指している。３０は
リソースＡ運用管理サーバで、リソースＡ処理モジュー
ル３１とリソースＡ情報ＤＢ３２を具備し、また、４０
はリソースＢ運用管理サーバで、リソースＢ処理モジュ
ール４１とリソースＢ情報ＤＢ４２を具備している。５
１はリソース運用管理部門の操作端末、５２はリソース
運用管理部門のリソースＣ情報管理システム（ＤＢ）又
は管理表である。なお、このリソースＣ情報管理ＤＢ又
は管理表は一例であり、管理対象が異なれば管理表等は
異なり、又、管理対象が増加すれば管理表等も増加す
る。６０はリソースＡ工事管理サーバであり、リソース
Ａ稼働手配モジュール６１と作業者情報ＤＢ６２を具備
している。７１はリソース工事管理部門の操作端末であ
る。

【００１０】ワークフロー制御サーバ１０の制御モジュ
ール１１、各管理サーバ３０、４０、６０のリソース処
理モジュールやリソース稼働手配モジュール３１、４
１、６１及び各操作端末２１、５１、７１は、通信ネッ
トワーク８０で結ばれる。該通信ネットワーク８０は、
ローカルなネットワークや広域のネットワークを含むだ
けでなく、システム構成によっては、同一コンピュータ
内でのプロセス間通信まで含む概念を指している。

【００１１】ここで、リソースとは一般的な概念である
人・物・金を意味する。しかし、図１中では理解を容易
にするため、リソースＡとは物（設備）に限定してお
り、人を指す表現としてリソースＡ稼働（リソースＡの
工事をする人の稼働という意味）としている。このよう
にリソースを物（設備）に限らない表現としては、例え
ばリソースＡの工事をする人をリソースＤと表現するこ
ともできる。しかし、理解の容易さを考慮しリソースＤ
と表現するよりもリソースＡ稼働と表現している。図１
のシステム例では、リソースＡとリソースＢの運用管理
は自動化され、リソースＣの運用管理は未自動化又は自
動化が不可能であることを示している。同様に、リソー
スＡ工事の管理も自動化され、それ以外のリソース工事
の管理は未自動化又は自動化が不可能であることを示し
ている。

【００１２】図２はワークフロー制御サーバ１０の一実
施例の機能ブロック図を示したものである。制御モジュ
ール１１は、ワークフローの管理・制御を行う制御部１
１０、記録部１１１及び通信部１１２を具備する。記録
部１１１は状態シート記録部１１１１、基本フロー記録
部１１１２、オーダー情報記録部１１１３を具備する。
権限情報ＤＢ１２は権限情報テーブル１２１、エリア種
類テーブル１２２、実行権限テーブル１２３を具備す
る。

【００１３】図３は制御部１１０の全体的処理フローを
示したものである。図３に示すように、制御部１１０の
処理は認証・オーダ登録処理３０１、基本フロー選択処
理３０２、手配処理３０３、判断処理３０４に大別され
る。また、基本フロー選択処理３０２は基本フロー選択
３０２−１とエラー処理３０２−２に大別される。図３
の処理フローについては、後で具体例でもって詳しく説
明する。

【００１４】図４は状態シートの一例である。状態シー
ト４００とは、オーダの進捗状態を示すものであり、現
実にはポインタによって指定される状態を格納するメモ
リの場合やデータベース内のファイルの場合を含んで、
情報を保持・変更できる記録・読み取り機能を有する媒
体を指している。ここでは、制御モジュール１１の記録
部１１１中の状態シート記録部１１１１に格納されると
する。一般に状態シート記録部１１１１には、複数の状
態シートが格納され、同時に並列的処理が可能である。
図４において、状態シート４００には、現在の状態を示
す状態の値（状態変数）が複数格納されている。また、
図４においては、目標値も格納されている例が示されて
いるが、目標値は、例えばオーダ情報記録部等に格納す
る方法もあり得る。

【００１５】状態シート４００はオーダの登録によって
生成され、オーダの削除（完了の場合や取消の場合があ
る）によって消滅する。状態シート中のデータ種別と
は、いくつかのデータ項目の総称である。たとえば、リ
ソースＡを特定する場合に複数のデータ項目が必要な場
合が多く、これら複数のデータ項目の集合を示すもので
ある。具体的な例としては、光ファイバ心線を特定する
場合には、何番ケーブルの何番心線というように、少な
くとも２つのデータ項目（この場合はケーブル番号と心
線番号）が必要である。ここでは、状態変数は、「０」
は情報なし（未了状態）、「１」は情報登録（完了状
態）、「２」は情報仮登録（待機状態）、「３」はエラ
ー情報登録（エラー状態）とする。

【００１６】図５は基本フローの一例である。基本フロ
ーは、原則として独立事象である処理毎のフローを示
し、実施例では、記録部１１１の基本フロー記録部１１
１２に保存されている。制御部１１０は、後述するよう
に、状態シート５００の進捗状態に応じて、基本フロー
内から所望フローを選択し、状態値を目標値に近づける
処理を行う。独立事象とは他の処理とは無依存に処理を
すすめることができることを意味しており、複数のリソ
ース処理が関連し合う様な場合には複数のフローが一体
となって基本フローを構成する。例えば、リソースＡの
設計は他のリソースの設計とは独立に行うことができる
とすれば、図５中のように、リソースＡの設計のみで１
つの基本フローとなる。一方、リソースＢとリソースＣ
の設計をするために相互に連携させながら設計する必要
がある場合には、図５中のリソースＢ、Ｃ設計フローの
ような基本フローが考えられる。後述の具体的処理例で
は、図１中のリソースＡの設計は独立であり、リソース
ＢとリソースＣの設計は相互に関連する前提で説明す
る。また、頻繁に使う定型のフローは、基本フローとし
て扱うことも可能である。

【００１７】各基本フローには、対応する必須の入力項
目と出力項目を示す入出力項目テーブルが用意される。
図６に入出力項目テーブルの一例を示す。入出力項目テ
ーブルは、基本フローとともに記録部１１１の基本フロ
ー記録部１１１２に予め記録され、後述するように、制
御部１１０は該入出力項目テーブルを参照して実行すべ
き基本フローの順番を決定する。

【００１８】図７は制御モジュール１１の記録部１１１
のオーダ情報記録部１１１３に記録されるオーダ情報７
００の一例である。

【００１９】図８は権限情報ＤＢ１２内の権限種別テー
ブル１２１、エリア種別テーブル１２２、実行権限テー
ブル１２３の一例である。後述するように、制御部１１
では、オーダの手配を行う際、権限種別テーブル１２１
及びエリア種別テーブル１２２の権限種別を組み合わせ
て、実行権限テーブル１２３から基本フローの実行権限
を有する者を選択する。

【００２０】次に、制御モジュール１１の制御部１１０
での処理について、図３の処理フローにもとづき具体例
により詳述する。なお、オーダ情報は図７の内容とす
る。

【００２１】〔処理例１〕図１に示した構成例で、リソ
ースＡ、リソースＢ、リソースＣの設計と工事を必要と
するオーダ（注文）があった場合の、状態シートの状態
遷移の例を図９に示す。以下に、図３の処理フローによ
り図９に示すような状態遷移となることを説明する。

【００２２】制御モジュール１１の制御部１１０の最初
の処理は、図３の認証・オーダ登録処理３０１である。
認証・オーダ登録処理３０１は、オーダを受けた者（例
えば、Ａ太郎）が、例えば操作端末２１などからシステ
ムにアクセスしてパスワードなどとともにオーダの内容
等を入力してきた場合、該オーダを受けた者の認証等の
セキュリティーチェックを行い、その後に、オーダの内
容に関する基本データを登録する処理である。ここで、
基本データとは図７のオーダ情報の例で示すと、受付日
時、お客様番号、お客様名、お客様住所、サービス名、
サービス開始予定日、投入者名とオーダ内容の対象リソ
ース欄、オーダ欄のデータが該当する。ただし、すべて
の基本データを投入する必要があるわけではない。受付
日時や投入者名もシステムで自動的に設定でき得る。さ
らに、オーダ内容の対象リソース欄、オーダ欄は、投入
者に分かりやすいＨＭＩ（ヒューマン・マシン・インタ
ーフェース）で投入した内容からシステムが自動的に設
定することもでき得る。このように基礎データ作成が終
了すると、オーダ情報が記録部１１１のオーダ情報記録
部１１１３に登録されると共に、状態シート番号が付与
され、状態シートが作成されて、状態シート記録部１１
１１に記録される。図９（ａ）はこの状態を示してい
る。

【００２３】次に、制御部１１０は、図３の基本フロー
選択処理３０２に進む。基本フロー選択処理３０２は正
常時の基本フロー選択３０２−１とエラー発生時のエラ
ー処理３０２−２に分かれるが、ここでは、正常時の基
本フロー選択３０２−１について説明する。この処理で
は、図５に示した基本フローの中で状態の値を目標値に
近づける基本フローを選択する。具体的には、制御部１
１０は、状態シートの状態の値と目標値とを確認し、１
つ又は複数の状態値を目標値に変更できる基本フローの
中から、図６に示したような基本フローに対応する必須
の入力項目と出力項目のテーブル（入出力項目テーブ
ル）にもとづき、入力項目が既知のデータで足りる基本
フローを選択する。ここで、既知のデータには制御モジ
ュール１１が翻訳することができるため既知と同等のデ
ータも含まれる。例えば、サービス名によってリソース
の必要数が決まっており、予め記録されていたサービス
名とリソースの必要数とを対応させるテーブルから必要
数が分かるような場合である。また、２以上の基本フロ
ーが実行可能な場合には、どの基本フローを選定しても
かまわない。さらに、リソースＢとリソースＣの設計の
様に互いに関連している複数の状態を変更する場合に
は、関連する複数の状態を変更できる基本フローを選択
する。

【００２４】図７のオーダ情報の例では、図９（ａ）の
段階で、リソースＡ設計フローの入力項目はすべて既知
であるのに対し、リソースＢ、Ｃ設計フロー、リソース
Ａ工事フローではリソースＡ番号が未知であり、リソー
スＢ工事フローではリソースＢ番号が、リソースＣ工事
フローではリソースＣ番号が未知である。したがって、
まずリソースＡ設計フローを選択することとなる。

【００２５】次に、制御部１１０は、エラーの発生がな
い場合、図３の手配処理３０３に進む。手配処理３０３
では、リソース処理モジュールやリソース運用管理部門
などへのオーダの手配を行う。この時、権限情報ＤＢ１
２を使用して、実行権限者を選択する。ここでは、図８
に示した権限種別情報ＤＢ１２の各テーブルの場合を例
に説明する。

【００２６】図８中の権限種別テーブル１２１の「Ｒ」
はリード（Ｒｅａｄ）を示し、データを読む権限を有す
る意味である。また、「ＲＷ」はリード・アンド・ライ
ト（ＲｅａｄａｎｄＷｒｉｔｅ）を示し、データを
読む権限と書き込む権限を有する意味である。本例で
は、オーダの内容はリソースＡ設計であるから、データ
（設計の結果）を書き込む権限を有する必要があり、権
限種別が「ア」「イ」に相当する担当者が実行又は処理
モジュールに実行を指示できる。また、図８中のエリア
種別テーブル１２２は、エリアのグループ分けを行うテ
ーブルである。運用管理の対象となるリソースが広範囲
に渡る場合には、エリアを区切って運用管理することが
あるため、同じ担当者でもエリア毎に保有する権限が異
なることとなる。そこで、エリア種別テーブル１２２に
よって幾つかのエリアをグループ分けしている。エリア
種別テーブル中の「○○エリア」とは、支店名、営業所
名等の場合や市町村名のような住所の場合などがあり得
るが、特に地理的な表現方法を限定しない意味である。
図７のオーダ情報の例中のお客様住所である「東京都千
代田区・・・」が「○○エリア」に該当するとすれば、
エリア種別は「」が適用される。ここで、実行権限テ
ーブル１２３において、権限種別「ア」又は「イ」、適
用エリア種別「」の担当者はＡ太郎とＢ花子であり、
どちらかがリソースＡ設計を実施または実施指示でき
る。本例においては、Ａ太郎が受付者であり、基本デー
タを投入したオーダ投入者でもあるため、Ａ太郎を実行
権限者と選択する。Ａ太郎が基本データ投入後にオーダ
の実施を指示することにより、図１の構成では、リソー
スＡ運用管理サーバ３０がリソースＡ設計を自動的に行
い、その結果を制御モジュール１１の制御部１１０が受
け取り、図７中のオーダ内容にリソースＡ情報の結果を
書き込む。このような処理によって、状態シートは、図
９（ｂ）のリソースＡ設計結果登録後の状態に変化す
る。

【００２７】図９（ｂ）は、正常に基本フローが終了し
た場合であるが、リソースＡ設計フローが失敗する場合
は次のようになる。リソースＡ運用管理サーバ３０はリ
ソースＡ設計のオーダを受けると、リソースＡ処理モジ
ュール３１がリソースＡ情報ＤＢ３２を参照してリソー
スＡの在庫を調べる。この在庫情報が不足している場
合、設計を実行できない場合がある。このような場合に
は、制御部１１０は、リソースＡ運用管理サーバ３０か
らエラー情報を受け取り、状態シートのリソースＡデー
タの状態をエラー状態に変更する。

【００２８】次に、制御部１１０は図３の判断処理３０
４に進む。判断処理３０４では、状態シートの状態の値
が目標の値と比較し、一致する場合は終了となり、制御
部１１０は投入者に終了したことを送信する。状態シー
トの状態の値に目標の値と異なるものがあるときには、
基本フロー選択処理３０２へ戻る。図９（ｂ）の状態遷
移の例では、リソースＡ設計結果登録後の状態なので、
基本フロー選択処理３０２へ戻ることとなる。

【００２９】ここで、基本フロー選択処理３０２でのエ
ラー処理３０２−２について説明する。基本フロー選択
処理でエラーが発生する原因は、入力項目のすべてが既
知である基本フローが存在しない場合、選択できる基本
フローによって変更できるデータ種別の状態がすべてエ
ラー状態となっている場合があり得る。

【００３０】まず、入力項目のすべてが既知である基本
フローが存在しない場合は、制御部１１０は投入者に対
してエラーメッセージを送信する。これは、投入者の入
力データが不足しているために発生するエラーだからで
ある。例えばお客様住所が入力されないまま、図７のオ
ーダを指示した場合には、リソースＡ設計を行うことが
できないため、Ａ太郎に対してエラーメッセージが送信
されることになる。ここで、このような入力データ不足
に対応する方法として、オーダ入力時に入力データの不
足がないことを確認する方法もある。この確認のために
は、オーダ内容と入力データ項目とを対応付ける表を用
いることが考えられる。

【００３１】次に、選択できる基本フローによって変更
できるデータ種別の状態がすべてエラー状態となってい
る場合には、制御部１１０は通信部１１２を介して管理
サーバ（ここでは、リソース運用管理サーバ）に実行指
示をした担当者にエラーメッセージを送信する。実行指
示をした担当者が操作端末から処理結果を入力し、状態
を完了状態に変更できれば、再度基本フロー選択処理３
０２へ戻ることとなる。ここで、エラーメッセージが複
数の実行指示者に送信される場合もあるが、このような
状況はエラー状態となっているデータ種別の状態を変更
する処理が独立の場合に発生し得る。この場合には、複
数の実行指示者に同時にエラーメッセージを送信し、す
べての実行指示者からの入力を待って処理を進める方法
と、実行指示者へのエラーメッセージ送信、実行指示者
からの入力を１人づつ行う方法とがある。

【００３２】ところが、実行指示をした担当者にも状態
を完了状態にできない場合や完了状態にするために時間
を要する場合もある。このような場合には、実行指示者
が操作端末からエラー情報を入力し、制御部１１０がエ
ラーメッセージを投入者に送信することでオーダが実行
不能であることを知らせる。例えば十分なリソースＡ情
報がリソースＡ情報ＤＢ３２に登録されていないまま、
図７のオーダを指示した場合には、リソースＡ設計を行
うことができないため、Ａ太郎に対してエラーメッセー
ジが送信されることになる。Ａ太郎はリソースＡ情報の
登録を行う必要があるが、情報の登録作業に時間を要す
る場合にはエラー情報を操作端末から入力する。この場
合にはＡ太郎が投入者でもあるが、投入者としてのＡ太
郎へエラーメッセージが送信され、Ａ太郎はオーダの取
消、保留等の判断をすることとなる。オーダの取消と
は、記録部１１１のオーダ情報記録部１１１３に記録さ
れているオーダ情報を取り消してしまい、生成した状態
シートを消滅させることを意味する。このような取消の
場合には、すでに完了状態となっているデータ種別の状
態を元に戻すため、関連したサーバに情報ＤＢへの登録
の取消依頼や実行又は実行指示者に対して電子メール、
ＦＡＸ等の通信手段又は本システムにログインしたとき
に取消を表示する手段によって通知する。このような処
理が終了すると、実際にオーダ情報と状態シートを消滅
させる。オーダの保留とは、オーダ情報や状態シートは
保持するが、ワークフロー制御を停止させることを意味
する。

【００３３】図９の状態遷移の説明に戻る。状態シート
は図９（ｂ）のリソースＡ設計結果登録後の状態となっ
ており、図３の処理フローでは基本フロー選択処理３０
２に戻っている。この段階では、リソースＡ番号も既知
となっているので、入力項目がすべて既知のデータであ
るのは、リソースＣ設計フロー又はリソースＢ、Ｃ設計
フローの２つがある。状態シートの目標値と状態値の比
較をすると、リソースＣデータのみでなくリソースＢデ
ータも変更する必要があるので、リソースＢ、Ｃ設計フ
ローを優先して選択する。本説明の前提としているよう
に、リソースＢとリソースＣの設計が互いに関連するた
め、２種類のリソースを一連の処理で設計するためであ
る。また、リソースＣ設計フローやリソースＢ設計フロ
ーが存在する理由は、リソースＣのみやリソースＢのみ
の設計オーダもあり得るからである。このような場合
は、状態シートの状態値と目標値の違いが、リソースＣ
データのみ又はリソースＢデータのみとなるため、容易
に基本フローの選択ができる。

【００３４】次に、図３の手配処理３０２の２回目を実
行する。ここでは、図５のリソースＢ、Ｃ設計フローに
従って、まず、リソースＣ設計、仮登録の処理を行う。
前回と同様に、図８に示した権限情報ＤＢ１２の各テー
ブル１２１、１２２、１２３を参照する処理から説明す
る。オーダの内容はリソースＣ設計であるから、データ
（設計の結果）を書き込む権限を有する必要があり、権
限種別テーブル１２１より、権限種別が「イ」に相当す
る担当者が実行又は処理モジュールに実行を指示でき
る。また、図７のオーダ情報の例中のお客様住所である
「東京都千代田区・・・」が「○○エリア」に該当する
前提で説明しているので、エリア種別テーブル１２２中
のエリア種別は「」が適用される。そこで、実行権限
テーブル１２３で、権限種別「イ」、適用エリア種別
「」の担当者であるＢ花子が実行又は実行指示するこ
ととなる。そこで、制御部１１０は、Ｂ花子に対して設
計、仮登録を電子メール、ＦＡＸ等の通信手段又はＢ花
子が本システムにログインしたときに依頼を表示する手
段によって依頼する。ここでは、図１の構成例に従って
いるので、リソースＣの設計等の処理をするリソースＣ
運用管理サーバは存在せず、リソースＣ情報管理システ
ム（ＤＢ）又は管理表５２の情報からＢ花子が設計をす
る。設計結果は操作端末５１から入力され、制御部１１
０が、これを通信部１１２を介して受信し、記録部１１
１に仮登録する。ここで、仮登録には１つの候補を仮登
録する方法と複数の候補を仮登録する方法がある。ま
た、複数の候補を仮登録する場合には優先順位を付加す
ることもあり得る。このような処理によって、状態シー
トは図９（ｃ）に示すリソースＣ設計結果仮登録後の状
態に変化する。

【００３５】上述の説明は正常にリソースＣ設計、仮登
録処理が終了した場合であるが、失敗した場合には、制
御部１１０は、エラー情報を通信部１１２を介して受信
することにより、状態シート２０のリソースＣデータの
状態をエラー状態に変更し、その後のリソースＢ、Ｃ設
計、仮登録フローは行わず、図３の判断処理３０４へ進
む。

【００３６】正常にリソースＣ設計、仮登録処理が終了
した場合、図３の手配処理３０３が継続し、リソースＢ
設計、登録の処理に進む。ここで、オーダの内容はリソ
ースＢ設計であるから、データ（設計の結果）を書き込
む権限を有する必要がある。図８の権限種別テーブル１
２１より、権限種別が「ア」又は「イ」に相当する担当
者が実行又は処理モジュールに実行を指示できる。ま
た、図７のオーダ情報の例中のお客様住所である「東京
都千代田区・・・」が「○○エリア」に該当する前提で
説明しているので、エリア種別テーブル１２２中のエリ
ア種別は「」が適用される。そこで、実行権限テーブ
ル１２３で、権限種別「ア」又は「イ」、適用エリア種
別「」の担当者であるＡ太郎又はＢ花子が実行又は実
行指示することとなる。

【００３７】ここで、Ａ太郎は投入者であり、Ｂ花子が
基本フローのリソースＣの設計、登録も担当しているの
で、どちらが実行又は実行指示を行うのかが問題にな
る。今回の例では、リソースＢ運用管理サーバ４０が存
在するので、Ａ太郎が基本データ投入後にリソースＢ設
計の実行を指示していれば、リソースＣ設計結果が仮登
録されると、制御部１１０から自動的にリソースＢ運用
管理サーバ４０に対して設計、登録の指示が送信され
る。

【００３８】もし、Ａ太郎が実行を指示していなかった
場合には、制御部１１０はＡ太郎及びＢ花子に対して設
計、仮登録を依頼する。依頼の方法には、前述のように
電子メール、ＦＡＸ等の通信手段又は本システムにログ
インしたときに依頼を表示する手段がある。その他にＢ
花子に対しては、Ｂ花子がリソースＣの設計、仮登録の
依頼を受けるときに同時に依頼をする手段又はＢ花子が
仮登録を終了させたときに操作端末５１へ表示する手段
もある。そして、Ｂ花子が実行指示を行うこととなる。

【００３９】リソースＢの設計では大きく分けて２通り
の方法がある。１つ目は制御部１１０が記録部１１１に
仮登録されているリソースＣ番号を１つ選んだ上で、リ
ソースＢ処理モジュール４１に設計を指示する方法であ
る。この場合に、リソースＢ運用管理サーバ４０は与え
られたリソースＡ番号とリソースＣ番号の組合せを実現
できるリソースＢが存在すれば、そのリソースＢの中か
ら必要数を選びリソースＢの設計結果とし、与えられた
リソースＣ番号をリソースＣの設計結果とする。また、
与えられたリソースＡ番号とリソースＣ番号の組合せを
実現できるリソースＢが存在しなければ、エラー情報を
制御部１１０に送信する。エラー情報を受けた制御部１
１０は、記録部１１１に仮登録されている他のリソース
Ｃ番号を１つ選び、リソースＢ処理モジュール４１に設
計を指示する。このように繰り返し、リソースＡ番号と
リソースＣ番号の組合せを実現できるリソースＢが存在
すれば、そのリソースＢの中から必要数を選びリソース
Ｂの設計結果とし、与えられたリソースＣ番号をリソー
スＣの設計結果とする。仮登録されたリソースＣ番号の
すべてでエラーとなった場合には、制御部１１０はリソ
ースＢ設計は失敗したものと判断する。

【００４０】２つ目は制御部１１０が記録部１１１に仮
登録されているすべてのリソースＣ番号を送信し、リソ
ースＢ処理モジュール４１に設計を指示する方法であ
る。この方法ではリソースＢ運用管理サーバ４０が、与
えられたリソースＡ番号と複数のリソースＣ番号の中か
ら組合せを実現できるリソースＢ番号とリソースＣ番号
を選び、リソースＢ、リソースＣの設計結果とする。組
合せが存在しない場合には、リソースＢ運用管理サーバ
４０は設計失敗と判断し、エラー情報を制御部１１０に
送信する。

【００４１】正常に終了した場合には、リソースＢの設
計結果は記録部１１１のオーダ情報記録部１１１３に登
録される。このような処理によって、状態シートは、図
９（ｄ）に示すリソースＢ設計結果登録後の状態に変化
する。

【００４２】また、制御部１１０はリソースＣ設計、確
定の処理に進み、リソースＣの設計者であるＢ花子に選
ばれたリソースＣ番号を電子メール、ＦＡＸ等の通信手
段又はＢ花子が本システムにログインしたときに依頼を
表示する手段によって知らせる。Ｂ花子がリソースＣの
選定結果を確認することで、リソースＣ番号が記録部１
１１のオーダ情報記録部１１１３に登録される。このよ
うな処理によって、状態シートは、図９（ｄ）に示すリ
ソースＣ設計結果確定後の状態に変化する。

【００４３】このようにして、図３の判断処理３０４に
再び進む。設計に失敗した場合には、状態シートのリソ
ースＢデータ、リソースＣデータの状態をエラー状態と
し、リソースＣの仮登録を削除した上で、判断処理３０
４へ進む。ここで、正常に進んでいる場合、図９（ｅ）
の状態遷移の例ではリソースＣ設計結果確定後の状態な
ので、基本フロー選択処理３０２へ戻ることとなる。な
お、エラー状態が含まれる場合にも、状態シートの状態
の値が目標の値と一致しないため、基本フロー選択処理
３０２へ戻ることとなる。

【００４４】再度、図３の基本フロー選択処理３０２に
ついて説明する。まず、制御部１１０は状態シートの状
態の値と目標値とを確認し、１つ又は複数の状態値を目
標値に変更できる基本フローの中から、入力項目が既知
のデータで足りる基本フローを選択する。また、２以上
の基本フローが実行可能な場合には、どの基本フローを
選定してもかまわない。図９（ｄ）の状態では、リソー
スＡ番号、リソースＢ番号、リソースＣ番号共に既知で
あるから、リソースＡ工事フロー、リソースＢ工事フロ
ー、リソースＣ工事フローのいずれでも選択できる。こ
こでは、リソースＡ工事フローを選択したとする。な
お、リソースＢ工事フロー、リソースＣ工事フローを選
択したとしても、以下の説明の順序が変更されるだけで
ある。また、このようにどの基本フローが選択されても
良い場合には、並列に基本フローを進める方法もあり得
る。さらには、順番に行う場合にも優先順位を別データ
として設定できるようにする方法もあり得る。

【００４５】次に、図３の手配処理３０３に進む。ここ
では、図５のリソースＡ工事フローに従って処理を行
う。オーダの内容はリソースＡ工事であるから、データ
（工事稼働手配の結果）を書き込む権限を有する必要が
あり、図８に示した権限種別テーブル１２１から権限種
別が「ウ」に相当する担当者が実行又は処理モジュール
に実行を指示できる。また、図７のオーダ情報の例中の
お客様住所である「東京都千代田区・・・」が「○○エ
リア」に該当する前提で説明しているので、エリア種別
テーブル１２２中のエリア種別は「」が適用される。
そこで、実行権限テーブル１２３で、権限種別「ウ」、
適用エリア種別「」の担当者であるＣ一郎が実行又は
実行指示することとなる。制御部１１０は、Ｃ一郎に対
してリソースＡ稼働手配を電子メール、ＦＡＸ等の通信
手段又はＣ一郎が本システムにログインしたときに依頼
を表示する手段によって依頼する。ここでは図１の構成
例に従っているので、リソースＡ稼働の手配をするリソ
ースＡ工事管理サーバ６０がＣ一郎の実行指示に従って
稼働手配をする。そして、リソースＡ工事管理サーバ６
０は、工事者の手配が正常に終了すれば結果を制御部１
１０に送信し、記録部１１１のオーダ情報記録部１１１
３にリソースＡ稼働データが登録される。このような処
理によって、状態シートは、図９（ｆ）に示すリソース
Ａ工事手配完了後の状態に変化する。なお、工事者の手
配ができなかった場合には、リソースＡ工事管理サーバ
６０はエラー情報を制御部１１０に送信し、状態シート
のリソースＡ稼働データの状態はエラー状態となる。

【００４６】次に、再び図３の判断処理３０４に進む
が、正常・エラーのどちらの場合も再度基本フロー選択
処理３０２に戻ることになる。

【００４７】基本フロー選択処理３０２では、上述の通
りリソースＢ工事フローとリソースＣ工事フローとが選
択可能である。ここでは、リソースＢ工事フローが選択
されたとする。

【００４８】次に、再度、図３の手配処理３０３とな
り、リソースＢ稼働手配の処理を行う。ここで、権限種
別テーブル１２１から、権限種別が「エ」に相当する担
当者が実行又は処理モジュールに実行を指示できる。ま
た、前回同様にエリア種別テーブル１２２中のエリア種
別は「」が適用される。そこで、実行権限テーブル１
２３で、権限種別「エ」、適用エリア種別「」の担当
者であるＤ次郎が実行又は実行指示することとなる。制
御部１１０は、Ｄ次郎に対してリソースＢ稼働手配を電
子メール、ＦＡＸ等の通信手段又はＤ次郎が本システム
にログインしたときに依頼を表示する手段によって依頼
する。図１の構成例では、リソースＢ稼働手配をするリ
ソースＢ工事管理サーバは存在しないので、Ｄ次郎が稼
働手配をする。結果は操作端末７１から入力され、制御
部１１０にて記録部１１１のオーダ情報記録部１１１３
に登録され、状態シートはリソースＢ工事手配完了後の
状態に変化する。

【００４９】その後、図３の判断処理３０４、基本フロ
ー選択処理３０２を経て、手配処理３０３となり、同様
にリソースＣ稼働手配の処理がＤ次郎によって行われ、
正常に記録部１１１のオーダ情報記録部１１１３に登録
されると、状態シートは、図９（ｇ）に示すリソース
Ｂ、Ｃ工事手配完了後の状態となる。この場合、図３の
判断処理３０４フローに進むと、状態シートは状態の値
と目標の値とがすべて一致しており、処理終了となる。

【００５０】〔処理例２〕図１に示した構成例で、リソ
ースＡの設計と工事を必要とするオーダ（注文）があっ
た場合の、状態シートの状態遷移の例を図１０に示す。
以下に、図３の処理フローにより、図１０に示すような
状態遷移となることを説明する。

【００５１】制御モジュール１１の税制御部１１０の最
初の処理は、認証・オーダ登録処理３０１であり、オー
ダを受けた者（例えば、Ａ太郎）がシステムにアクセス
して、パスワードおよびオーダの内容等を入力してきた
場合、該オーダを受けた者の認証等のセキュリティーチ
ェックを行った後に、オーダの内容に関する基本データ
を記録部１１１のオーダ情報記録部１１１３に登録す
る。この処理は前述の図９の場合と基本的に同じである
が、異なるのは、オーダの内容がリソースＡの設計と工
事のみであることである。このようにオーダが限定され
る場合には、図１０（ａ）の基礎データ投入後に示すよ
うに、オーダ内容にあわせて目標値が設定された状態シ
ートが作成される。なお、状態シートは、本処理では関
与しないリソースＢデータ以降のデータ種別部分を省略
したものを作成することでもよい。

【００５２】次に、図３の基本フロー選択処理３０２に
進む。この処理では、前述の場合と同様に、図５に示し
ている基本フローの中でどのフローを行うのかを選択す
る。各基本フローには対応する必須の入力項目と出力項
目のテーブル（入出力項目テーブル）が図６のように用
意されている。まず、制御部１１０は状態シートの状態
の値と目標値とを確認し、１つ又は複数の状態値を目標
値に変更できる基本フローの中から、入力項目が既知の
データで足りる基本フローを選択する。ここで、オーダ
の無いデータ種別の目標値は「０」になっているため、
オーダと関係のない基本フローは選定されない。図１０
（ａ）の状態では、リソースＢやＣの目標値は「０」で
あり、状態値と一致しているからリソースＢ、Ｃに関す
る基本フローは選定されない。また、リソースＡ設計フ
ローの入力項目はすべて既知であるのに対し、リソース
Ａ工事フローではリソースＡ番号が未知であるため、ま
ず、リソースＡ設計フローを選択することとなる。

【００５３】次に、図３の手配処理３０３に進む。この
処理では、リソース処理モジュールやリソース運用管理
部門などへのオーダの手配を行う。ここでも、図８に示
した権限情報ＤＢ１２のテーブル１２１、１２２、１２
３を用いて説明する。オーダの内容はリソースＡ設計で
あるから、データ（設計の結果）を書き込む権限を有す
る必要があり、権限種別テーブル１２１中の権限種別が
「ア」「イ」に相当する担当者が実行又は処理モジュー
ルに実行を指示できる。また、図７のオーダ情報の例中
のお客様住所である「東京都千代田区・・・」が「○○
エリア」に該当する前提で説明しているので、エリア種
別テーブル１２２中のエリア種別は「」が適用され
る。そこで、実行権限テーブル１２３で、権限種別
「ア」又は「イ」、適用エリア種別「」の担当者はＡ
太郎とＢ花子であり、どちらかがリソースＡ設計を実施
または実施指示できる。本説明においては、Ａ太郎が受
付者であり、基本データを投入したオーダ投入者でもあ
るため、Ａ太郎が基本データ投入後にオーダの実施を指
示することにより、リソースＡ運用管理サーバ３０がリ
ソースＡ設計を自動的に行い、制御部１１０が、その結
果を通信部１１２を通して受信し、オーダ情報記録部１
１１３の図７中のオーダ内容にリソースＡ情報の結果を
書き込む。このような処理によって、状態シートは、１
０図（ｂ）に示すリソースＡ設計結果登録後の状態に変
化する。

【００５４】次に、図３の判断処理３０４に進む。正常
に進んでいる場合、図１０の状態遷移の例では、状態シ
ートは図１０（ｂ）のリソースＡ設計結果登録後の状態
なので、基本フロー選択処理３０２へ戻ることとなる。
なお、エラー状態が含まれる場合にも、基本フロー選択
処理３０２へ戻ることとなる。

【００５５】再度、図３の基本フロー選択処理３０２に
ついて説明する。まず、制御部１１０は状態シートの状
態の値と目標値とを確認し、１つ又は複数の状態値を目
標値に変更できる基本フローの中から、入力項目が既知
のデータで足りる基本フローを選択する。図１０（ｂ）
の状態は、リソースＡ稼働データのみが目標値と異なる
状態であるからリソースＡ工事フローが選択される。

【００５６】次に、再び図３の手配処理３０３となる。
この処理では、図５のリソースＡ工事フローに従って処
理を行う。オーダの内容はリソースＡ工事であるから、
データ（工事稼働手配の結果）を書き込む権限を有する
必要があり、図８に示した権限種別テーブル１２１から
権限種別が「ウ」に相当する担当者が実行又は処理モジ
ュールに実行を指示できる。また、図７のオーダ情報の
例中のお客様住所である「東京都千代田区・・・」が
「○○エリア」に該当する前提で説明しているので、エ
リア種別テーブル１２２中のエリア種別は「」が適用
される。そこで、実行権限テーブル１２３で、権限種別
「ウ」、適用エリア種別「」の担当者であるＣ一郎が
実行又は実行指示することとなる。制御部１１０は、Ｃ
一郎に対してリソースＡ稼働手配を電子メール、ＦＡＸ
等の通信手段又はＣ一郎が本システムにログインしたと
きに依頼を表示する手段によって依頼する。本説明では
図１の構成例に従っているので、リソースＡ稼働の手配
をするリソースＡ工事管理サーバ６０がＣ一郎の実行指
示に従って稼働手配をする。リソースＡ工事管理サーバ
６０は、工事者の手配が正常に終了すれば結果を制御部
１１０に送信し、制御部１１０は、記録部１１１のオー
ダ情報記録部１１１３にリソースＡ稼働データを登録す
る。このような処理によって、状態シートは、図１０
（ｃ）に示すリソースＡ工事手配完了後の状態に変化す
る。

【００５７】次に、図３の判断処理３０４に進む。この
場合、状態シートは状態の値と目標の値とがすべて一致
しているため、処理終了となる。

【００５８】〔処理例３〕図１に示した構成例で、リソ
ースＡ、Ｂ、Ｃの設計のみを必要とするオーダ（注文）
があった場合の、状態シートの状態遷移の例を図１１に
示す。この処理例では、図９に従って説明した最初の処
理例１において、図９（ｅ）のリソースＣ設計結果確定
後の状態になると、状態シートは目標値と状態値がすべ
て一致するため、処理終了となる。

【００５９】〔処理例４〕図１に示した構成例で、リソ
ースＡ、Ｂ、Ｃのデータを参照するオーダの場合の、状
態シートの状態遷移の例を図１２に示す。この処理例場
合、前述の処理例３と異なるのは、参照のみであるため
データを登録する必要はなく、図７の権限種別テーブル
で「Ｒ」の権限を有していれば可能なことである。

【００６０】最初の処理は、図３の認証・オーダ登録処
理３０１であるが、参照したい者がシステムにアクセス
し、認証等のセキュリティーチェックの後に、参照にあ
たってのキー情報を入力する処理となる。キー情報と
は、図６の入出力項目テーブルの入力項目が該当する。
例えば、リソース代表番号やリソースＡ番号などであ
る。ここで、リソース代表番号とは、リソースの組合せ
に対して付与された番号の意味である。例えば、前述の
設計のオーダにおいてリソースＡ、Ｂ、Ｃの組合せが決
まったが、このような組合せに対して付与される番号で
ある。このリソース代表番号によって、関連するリソー
スの組合せの管理が容易になることが期待できる。参照
するためのキー情報の入力で十分であるため、図８の権
限種別テーブル１２１の例では、実施者として登録され
ている者は全員参照する権限を有している。参照する権
限を有する者がキー情報を入力すると、制御部１１０に
て、前述と例と同様にオーダ情報が記録部１１１のオー
ダ情報記録部１１１３に登録されると共に、状態シート
が作成される。この状態が図１２のキー情報登録後であ
り、基本データは状態の値、目標の値とも「０」になっ
ている。その後の状態遷移は、前述の例と基本的に同様
である。

【００６１】参照の場合には、リソースの運用管理サー
バへのアクセス権が多くの参照者に許可されるため、設
計にくらてべリアルタイム性の向上が得られる。

【００６２】〔処理例５〕図１に示した構成例で、リソ
ースＡ、Ｂ、Ｃの廃止の設計と工事とを必要とするオー
ダ（注文）があった場合の、状態シートの状態遷移の例
を図１３に示す。このようなオーダはお客様からサービ
スの停止を依頼された場合等に発生する。

【００６３】この場合の最初の処理は、オーダを受けた
者（例えば、Ａ太郎）がシステムにアクセスし、これを
受げて制御部１１０が認証等のセキュリティーチェック
の後にオーダの内容に関する基本データを記録部１１１
のオーダ情報記録部１１１３に登録する処理であり、前
述の図９、図１０、図１１の場合と同じである。廃止の
設計とは、実際には現在使用中のリソースを参照すると
いう点で図１２の場合と似ている。しかし、設備の状態
を変更し、データベースの書き換えが必要なため、図７
の権限種別テーブルで「ＲＷ」の権限を有していなけれ
ばならない。次に、リソースＡ、Ｂ、Ｃの廃止の設計と
して参照を行うこととなるが、手順は図１２と同じであ
る。また、リソースＡ、Ｂ、Ｃに対する工事手配の手順
は図９で説明した工事手配の手順と同じである。このよ
うな処理によって、図１３に示す状態遷移となり、オー
ダは終了する。

【００６４】以上、本発明の一実施の形態について説明
したが、本発明はこれに限られるものでないことは云う
までもない。また、図３に示したような処理手順は、ワ
ークフロー管理制御用プログラムとしてコンピュータで
実行可能な言語で記述し、コンピュータが読み取り可能
な記録媒体（ＦＤ、ＣＤ−ＲＯＭ、ＭＤなど）に記録し
て提供することが可能である。このワークフロー管理制
御用プログラムをワークフロー制御サーバにインストー
ルすることにより、所期の機能が実現する。

【００６５】

【発明の効果】以上説明したように、本発明によれば、
状態シートによってオーダ内容を目標状態として、現在
の進捗を状態として管理し、状態を変更する最小単位を
基本フローとして定義することで、各基本フローの入出
力テーブルから現在の状態から目標状態に近づける基本
フローを選定することを可能とし、権限情報ＤＢによっ
て実行又は実行指示ができる権限者を探し、依頼をする
ことで、ワークフローの制御を自動的に行うことを可能
とする効果がある。また、ワークフロー制御の自動化に
より、複雑かつ膨大なワークフローのプロセス定義を不
要とする効果がある。

【図面の簡単な説明】

【図１】本発明の一実施形態の全体的システム構成を示
す図である。

【図２】本発明の一実施形態のワークフロー制御サーバ
の機能ブロック図である。

【図３】本発明の一実施形態の処理フローを示す図であ
る。

【図４】本発明の一実施形態の状態シートを示す図であ
る。

【図５】本発明の一実施形態で記録されている基本フロ
ーを示す図である。

【図６】本発明の一実施形態で記録されている基本フロ
ーの入出力項目テーブルを示す図である。

【図７】本発明の一実施形態で記録されているオーダ情
報の例を示す図である。

【図８】本発明の一実施形態で記録されている権限種別
テーブルの例を示す図である。

【図９】本発明のによる処理例１での状態シートの状態
遷移を示す図である。

【図１０】本発明による処理例２での状態シートの状態
遷移を示す図である。

【図１１】本発明による処理例３での状態シートの状態
遷移を示す図である。

【図１２】本発明による処理例４での状態シートの状態
遷移を示す図である。

【図１３】本発明による処理例５での状態シートの状態
遷移を示す図である。

【符号の説明】

１０ワークフロー制御サーバ１１制御モジュール１２権限情報ＤＢ２１、５１、７１操作端末３０、４０リソース運用管理サーバ６０リソース工事管理サーバ１１０制御部１１１記録部１１１１状態シート記録部１１１２基本フロー記録部１１１３オーダ情報記録部１１２通信部１２１権限種別テーブル１２２エリア種別テーブル１２３実行権限テーブル４００状態シート

───────────────────────────────────────────────────── フロントページの続き (72)発明者小谷忠司東京都千代田区大手町二丁目３番１号日本電信電話株式会社内 (72)発明者秋山幸生東京都千代田区大手町二丁目３番１号日本電信電話株式会社内

Claims

【特許請求の範囲】

【請求項１】ワークフローを管理制御するシステムで
あって、ワークフローのデータ種別を状態変数とし、デ
ータ種別毎の進捗状態を管理する機能と、オーダ内容に
従った目標となる状態を管理する機能と、状態を目標の
状態に近づける基本フローを選択する機能と、基本フロ
ーを実行又は実行指示できる権限者に依頼する機能と、
状態が目標状態に到達したか否かを判断する機能とを具
備することを特徴とするワークフロー管理制御システ
ム。
【請求項２】既知のデータ項目を基本フローの入力項
目と比較することによって基本フローを選択する機能を
具備することを特徴とする請求項１記載のワークフロー
管理制御システム。
【請求項３】選択することができる基本フローがない
場合に、基本フローの処理結果にエラーがないときには
オーダ登録者に通知し、基本フロー処理結果にエラーが
あるときには基本フローを実行又は実行指示できる権限
者に通知するエラー処理機能を具備することを特徴とす
る請求項１、２記載のワークフロー管理制御システム。
【請求項４】権限種別、エリア種別を組み合わせて基
本フローの実行権限を有する者を選択する機能を具備す
ることを特徴とする請求項１、２、３記載のワークフロ
ー管理制御システム。
【請求項５】ワークフローを管理制御する方法であっ
て、ワークフローのデータ種別を状態変数とし、データ種別
毎の進捗状態を記録する工程と、オーダ内容に従った目
標となる状態を記録する工程と、状態を目標の状態に近
づける基本フローを選択する工程と、基本フローを実行
又は実行指示できる権限者に依頼する工程と、状態が目
標状態に到達したか否かを判断する工程とを含むことを
特徴とするワークフロー管理制御方法。
【請求項６】既知のデータ項目を基本フローの入力項
目と比較することによって基本フローを選択する工程を
含むことを特徴とする請求項５記載のワークフロー管理
制御方法。
【請求項７】選択することができる基本フローがない
場合に、基本フローの処理結果にエラーがないときには
オーダ登録者に通知し、基本フロー処理結果にエラーが
あるときには基本フローを実行又は実行指示できる権限
者に通知するエラー処理工程を含むことを特徴とする請
求項５、６記載のワークフロー管理制御方法。
【請求項８】権限種別、エリア種別を組み合わせて基
本フローの実行権限を有する者を選定する工程を含むこ
とを特徴とする請求項５、６、７記載のワークフロー管
理制御方法。
【請求項９】プログラムを記録したコンピュータ読み
取り可能な記録媒体であって、請求項５〜８記載のワー
クフロー管理制御方法をコンピュータで実行させるため
のワークフロー管理制御プログラムを記録した記録媒
体。