(57)【特許請求の範囲】
【請求項１】
種々の操作端末やリソース管理サーバと通信ネットワークを介して結ばれ、ワークフローを管理制御するワークフロー管理制御装置であって、
ワークフローのデータ種別を状態変数とし、データ種別毎に現在の状態と目標となる状態を記録してワークフローの進捗状態を示す状態シートを格納した状態シート格納手段と、処理毎の基本フローを格納した基本フロー格納手段と、ワークフローのオーダ情報を格納したオーダ情報格納手段と、各種の権限情報を格納した権限情報格納手段と、ワークフローの管理・制御を行う制御手段とを具備し、
前記制御手段は、
操作端末を介して入力されるワークフローのオーダ情報を前記オーダ情報格納手段に登録すると共に、該オーダ情報をもとに状態シートを作成し、データ種別毎に目標となる状態と初期状態としての現在の状態を設定して前記状態シート格納手段に格納する処理機能と、
前記状態シートの現在の状態を目標の状態に近づける基本フローを前記基本フロー格納手段から選択する処理機能と、
前記権限格納手段の権限情報をもとに、前記選択された基本フローを実行又は実行指示できるリソース管理サーバ又は操作端末に実行または実行指示を依頼し、その処理結果をもとに前記状態シートの現在の状態を更新する処理機能と、
前記状態シートの現在の状態と目標の状態を比較して、現在の状態が目標の状態に到達したか否か判断する処理機能とを有する、
ことを特徴とするワークフロー管理制御装置。
【請求項２】
前記基本フロー格納手段の基本フローは、必須の入力項目と出力項目とを示す入出力項目テーブルを具備し、前記制御手段の基本フローを選択する処理機能は、状態シートの１つ又は複数の現在の状態を目標の状態に変更できる基本フローの中から、当該基本フローに対応する入出力項目テーブルにもとづき、入力項目が既知のデータで足りる基本フローを選択することを特徴とする請求項１記載のワークフロー管理制御装置。
【請求項３】
前記制御手段は、選択することができる基本フローがない場合に、基本フローの処理結果にエラーがないときにはオーダ情報登録者の操作端末に通知し、基本フロー処理結果にエラーがあるときには基本フローを実行又は実行指示できる前記依頼したリソース管理サーバ又は操作端末に通知するエラー処理機能を更に具備することを特徴とする請求項１もしくは２記載のワークフロー管理制御装置。
【請求項４】
前記権限情報格納手段は、権限種別テーブル、エリア種別テーブル、実行権限テーブルを具備し、前記制御手段の基本フローの実行又は実行指示を依頼する処理機能は、権限種別、エリア種別を組み合わせて、基本フローを実行または実行指示できる管理サーバまたは操作端末を選択することを特徴とする請求項１、２、３のいずれか１項に記載のワークフロー管理制御装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、コンピュータあるいはコンピュータネットワークを利用して、ワークフローを管理制御するための技術分野に関する。
【０００２】
【従来の技術】
ワークフローとは一般に仕事の流れをいい、会社内での決済や工場での製造などの複数の担当（部門）をまたがる仕事の場合、資材調達や工事手配などの複数の会社をまたがる仕事の場合には必ず存在するものである。従来はこのような仕事の流れを伝票をまわすことで管理又は制御している。
【０００３】
例えば受注生産で商品を製造する工場では、営業部門がお客様から受注する際、工場に納品可能な日時を問い合わせると、工場では部品の在庫調査、作業者の手配などから納品できる日時を特定する必要があるが、備品の種類によって管理する担当やデータベースが異なることがあったり、作業者の管理を別担当が行っている場合もある。この場合に在庫調査、作業者の手配をする担当が数カ所に分かれることとなり、すべての担当からの結果が判明しなければ営業担当者はお客様に正確な納品日を回答することができない。また、商品の種類が増えると、必要な部品の種類が増えるだけではなく、商品毎に組合せが異なったり、作業者のスキルを考慮した手配も必要となってくる。別な例としては、通信サービスをお客様が申し込む際に、通信事業者は所外のケーブル設備に空き設備はあるのか、装置に空きはあるのか等を確認する。しかし、通信関係の設備は膨大な量があるため、所外ケーブルのデータベースと装置関係のデータベースとは別々に構築されており、一般的にはそれらのデータベースを維持管理する担当（部門）も異なる。したがって、空きの確認をするためには複数の担当（部門）へ問い合わせる必要がある。また、近年の通信サービスや通信設備の多様化によって、確認する内容も多様化が要求されている。
【０００４】
一方で、ワークフロー管理を目的としたシステム、ソフトウェアの実用化も進められており、いくつかの製品がある。代表的な製品では、ビジュアルなプロセス定義機能などを有しており、ユーザインターフェースの優しさなどが実現してきている。しかし、商品やサービスが多様化し、部品の調査、作業者の手配、設備の確認などの項目が多様化してくれば、プロセス定義の数も増加せざるをえない。また、これらの製品ではプロセス定義のしやすさは実現してきているが、自動的なワークフロー制御までを実現するには至っていない。特にエラー処理までを考慮すると、分岐の数も膨大となり定義を完成させることには多くの労力が必要となる。
【０００５】
【発明が解決しようとする課題】
本発明の目的は、コンピュータやコンピュータネットワークによりワークフローを管理制御するにあたり、個別にプロセス定義をしなくても多様化するワークフローの自動的な管理と制御を可能とする技術を確立することにある。
【０００６】
【課題を解決するための手段】
本発明は、ワークフローを管理制御するにあたり、オーダを実行していく段階で設計情報等が登録されていくデータ項目を、同時に登録される複数のデータ項目は１つのデータ種別として扱い、データ種別毎に進捗状況を管理することでワークフローを管理する。また、データ種別はオーダの進捗を知るための状態変数として扱い、データ種別毎の進捗を数値化した状態によって全体の進捗を把握することを可能にしている。さらに、特定のデータ種別の値を変更できる仕事の単位を基本フローとして登録しておくことと、基本フローを実行又は実行指示できる権限を有する者を権限種別やエリア種別から特定できるよう登録しておくことによって、把握された状態を目標の状態に近づけていくことを可能にしている。
【０００７】
現在の進捗を状態として把握し、オーダが正常に終了した時の状態を目標の状態とすることで状態を変えなければならないデータ種別が把握でき、当該データ種別を変更できる基本フローを選択することができる。この選択にあたって処理に順番がある場合等には、基本フローを実行するために必要なデータが既知となっているか否かの判断工程を加えることで処理の順番管理も可能となる。また、基本フローの処理や選択のプロセスでエラーが生じることもあり、エラー発生原因を状態から把握することで適切な権限を有する者にエラー発生を通知することが可能となる。さらに、基本フローを実行するためには実行できる権限者を見つける必要があり、権限はエリアによって異なる場合もある。そこで、権限種別とエリア種別とを組み合わせて実行権限を有する者を選択し、基本フローの実行を依頼することでワークフローを進めることができる。
【０００８】
このように、進捗状態の把握、基本フローと実行権限の管理によって、ワークフロー制御を行う上でエラー処理を含めた一連の流れを定義（プロセス定義）する必要が無くなり、新たなワークフローが必要となった場合にも状態変数の追加、基本フローの追加、実行種別の追加で対応できる点が従来技術と異なる。
【０００９】
【発明の実施の形態】
以下、本発明の一実施の形態について図面により説明する。
図１は本発明によるワークフロー管理制御システムの一実施例の全体システム構成を示した図である。図中、１０は本システムの主要部のワークフロー制御サーバであり、制御モジュール１１と権限情報データベース（ＤＢ）１２を具備している。２１は営業部門の操作端末であり、営業所等に設置される端末や営業マン等が携帯する端末等を指している。３０はリソースＡ運用管理サーバで、リソースＡ処理モジュール３１とリソースＡ情報ＤＢ３２を具備し、また、４０はリソースＢ運用管理サーバで、リソースＢ処理モジュール４１とリソースＢ情報ＤＢ４２を具備している。５１はリソース運用管理部門の操作端末、５２はリソース運用管理部門のリソースＣ情報管理システム（ＤＢ）又は管理表である。なお、このリソースＣ情報管理ＤＢ又は管理表は一例であり、管理対象が異なれば管理表等は異なり、又、管理対象が増加すれば管理表等も増加する。６０はリソースＡ工事管理サーバであり、リソースＡ稼働手配モジュール６１と作業者情報ＤＢ６２を具備している。７１はリソース工事管理部門の操作端末である。
【００１０】
ワークフロー制御サーバ１０の制御モジュール１１、各管理サーバ３０、４０、６０のリソース処理モジュールやリソース稼働手配モジュール３１、４１、６１及び各操作端末２１、５１、７１は、通信ネットワーク８０で結ばれる。該通信ネットワーク８０は、ローカルなネットワークや広域のネットワークを含むだけでなく、システム構成によっては、同一コンピュータ内でのプロセス間通信まで含む概念を指している。
【００１１】
ここで、リソースとは一般的な概念である人・物・金を意味する。しかし、図１中では理解を容易にするため、リソースＡとは物（設備）に限定しており、人を指す表現としてリソースＡ稼働（リソースＡの工事をする人の稼働という意味）としている。このようにリソースを物（設備）に限らない表現としては、例えばリソースＡの工事をする人をリソースＤと表現することもできる。しかし、理解の容易さを考慮しリソースＤと表現するよりもリソースＡ稼働と表現している。図１のシステム例では、リソースＡとリソースＢの運用管理は自動化され、リソースＣの運用管理は未自動化又は自動化が不可能であることを示している。同様に、リソースＡ工事の管理も自動化され、それ以外のリソース工事の管理は未自動化又は自動化が不可能であることを示している。
【００１２】
図２はワークフロー制御サーバ１０の一実施例の機能ブロック図を示したものである。制御モジュール１１は、ワークフローの管理・制御を行う制御部１１０、記録部１１１及び通信部１１２を具備する。記録部１１１は状態シート記録部１１１１、基本フロー記録部１１１２、オーダー情報記録部１１１３を具備する。権限情報ＤＢ１２は権限情報テーブル１２１、エリア種類テーブル１２２、実行権限テーブル１２３を具備する。
【００１３】
図３は制御部１１０の全体的処理フローを示したものである。図３に示すように、制御部１１０の処理は認証・オーダ登録処理３０１、基本フロー選択処理３０２、手配処理３０３、判断処理３０４に大別される。また、基本フロー選択処理３０２は基本フロー選択３０２−１とエラー処理３０２−２に大別される。図３の処理フローについては、後で具体例でもって詳しく説明する。
【００１４】
図４は状態シートの一例である。状態シート４００とは、オーダの進捗状態を示すものであり、現実にはポインタによって指定される状態を格納するメモリの場合やデータベース内のファイルの場合を含んで、情報を保持・変更できる記録・読み取り機能を有する媒体を指している。ここでは、制御モジュール１１の記録部１１１中の状態シート記録部１１１１に格納されるとする。一般に状態シート記録部１１１１には、複数の状態シートが格納され、同時に並列的処理が可能である。図４において、状態シート４００には、現在の状態を示す状態の値（状態変数）が複数格納されている。また、図４においては、目標値も格納されている例が示されているが、目標値は、例えばオーダ情報記録部等に格納する方法もあり得る。
【００１５】
状態シート４００はオーダの登録によって生成され、オーダの削除（完了の場合や取消の場合がある）によって消滅する。状態シート中のデータ種別とは、いくつかのデータ項目の総称である。たとえば、リソースＡを特定する場合に複数のデータ項目が必要な場合が多く、これら複数のデータ項目の集合を示すものである。具体的な例としては、光ファイバ心線を特定する場合には、何番ケーブルの何番心線というように、少なくとも２つのデータ項目（この場合はケーブル番号と心線番号）が必要である。ここでは、状態変数は、「０」は情報なし（未了状態）、「１」は情報登録（完了状態）、「２」は情報仮登録（待機状態）、
「３」はエラー情報登録（エラー状態）とする。
【００１６】
図５は基本フローの一例である。基本フローは、原則として独立事象である処理毎のフローを示し、実施例では、記録部１１１の基本フロー記録部１１１２に保存されている。制御部１１０は、後述するように、状態シート５００の進捗状態に応じて、基本フロー内から所望フローを選択し、状態値を目標値に近づける処理を行う。独立事象とは他の処理とは無依存に処理をすすめることができることを意味しており、複数のリソース処理が関連し合う様な場合には複数のフローが一体となって基本フローを構成する。例えば、リソースＡの設計は他のリソースの設計とは独立に行うことができるとすれば、図５中のように、リソースＡの設計のみで１つの基本フローとなる。一方、リソースＢとリソースＣの設計をするために相互に連携させながら設計する必要がある場合には、図５中のリソースＢ、Ｃ設計フローのような基本フローが考えられる。後述の具体的処理例では、図１中のリソースＡの設計は独立であり、リソースＢとリソースＣの設計は相互に関連する前提で説明する。また、頻繁に使う定型のフローは、基本フローとして扱うことも可能である。
【００１７】
各基本フローには、対応する必須の入力項目と出力項目を示す入出力項目テーブルが用意される。図６に入出力項目テーブルの一例を示す。入出力項目テーブルは、基本フローとともに記録部１１１の基本フロー記録部１１１２に予め記録され、後述するように、制御部１１０は該入出力項目テーブルを参照して実行すべき基本フローの順番を決定する。
【００１８】
図７は制御モジュール１１の記録部１１１のオーダ情報記録部１１１３に記録されるオーダ情報７００の一例である。
【００１９】
図８は権限情報ＤＢ１２内の権限種別テーブル１２１、エリア種別テーブル１２２、実行権限テーブル１２３の一例である。後述するように、制御部１１では、オーダの手配を行う際、権限種別テーブル１２１及びエリア種別テーブル１２２の権限種別を組み合わせて、実行権限テーブル１２３から基本フローの実行権限を有する者を選択する。
【００２０】
次に、制御モジュール１１の制御部１１０での処理について、図３の処理フローにもとづき具体例により詳述する。なお、オーダ情報は図７の内容とする。
【００２１】
〔処理例１〕
図１に示した構成例で、リソースＡ、リソースＢ、リソースＣの設計と工事を必要とするオーダ（注文）があった場合の、状態シートの状態遷移の例を図９に示す。以下に、図３の処理フローにより図９に示すような状態遷移となることを説明する。
【００２２】
制御モジュール１１の制御部１１０の最初の処理は、図３の認証・オーダ登録処理３０１である。認証・オーダ登録処理３０１は、オーダを受けた者（例えば、Ａ太郎）が、例えば操作端末２１などからシステムにアクセスしてパスワードなどとともにオーダの内容等を入力してきた場合、該オーダを受けた者の認証等のセキュリティーチェックを行い、その後に、オーダの内容に関する基本データを登録する処理である。ここで、基本データとは図７のオーダ情報の例で示すと、受付日時、お客様番号、お客様名、お客様住所、サービス名、サービス開始予定日、投入者名とオーダ内容の対象リソース欄、オーダ欄のデータが該当する。ただし、すべての基本データを投入する必要があるわけではない。受付日時や投入者名もシステムで自動的に設定でき得る。さらに、オーダ内容の対象リソース欄、オーダ欄は、投入者に分かりやすいＨＭＩ（ヒューマン・マシン・インターフェース）で投入した内容からシステムが自動的に設定することもでき得る。このように基礎データ作成が終了すると、オーダ情報が記録部１１１のオーダ情報記録部１１１３に登録されると共に、状態シート番号が付与され、状態シートが作成されて、状態シート記録部１１１１に記録される。図９（ａ）はこの状態を示している。
【００２３】
次に、制御部１１０は、図３の基本フロー選択処理３０２に進む。基本フロー選択処理３０２は正常時の基本フロー選択３０２−１とエラー発生時のエラー処理３０２−２に分かれるが、ここでは、正常時の基本フロー選択３０２−１について説明する。この処理では、図５に示した基本フローの中で状態の値を目標値に近づける基本フローを選択する。具体的には、制御部１１０は、状態シートの状態の値と目標値とを確認し、１つ又は複数の状態値を目標値に変更できる基本フローの中から、図６に示したような基本フローに対応する必須の入力項目と出力項目のテーブル（入出力項目テーブル）にもとづき、入力項目が既知のデータで足りる基本フローを選択する。ここで、既知のデータには制御モジュール１１が翻訳することができるため既知と同等のデータも含まれる。例えば、サービス名によってリソースの必要数が決まっており、予め記録されていたサービス名とリソースの必要数とを対応させるテーブルから必要数が分かるような場合である。また、２以上の基本フローが実行可能な場合には、どの基本フローを選定してもかまわない。さらに、リソースＢとリソースＣの設計の様に互いに関連している複数の状態を変更する場合には、関連する複数の状態を変更できる基本フローを選択する。
【００２４】
図７のオーダ情報の例では、図９（ａ）の段階で、リソースＡ設計フローの入力項目はすべて既知であるのに対し、リソースＢ、Ｃ設計フロー、リソースＡ工事フローではリソースＡ番号が未知であり、リソースＢ工事フローではリソースＢ番号が、リソースＣ工事フローではリソースＣ番号が未知である。したがって、まずリソースＡ設計フローを選択することとなる。
【００２５】
次に、制御部１１０は、エラーの発生がない場合、図３の手配処理３０３に進む。手配処理３０３では、リソース処理モジュールやリソース運用管理部門などへのオーダの手配を行う。この時、権限情報ＤＢ１２を使用して、実行権限者を選択する。ここでは、図８に示した権限種別情報ＤＢ１２の各テーブルの場合を例に説明する。
【００２６】
図８中の権限種別テーブル１２１の「Ｒ」はリード（Ｒｅａｄ）を示し、データを読む権限を有する意味である。また、「ＲＷ」はリード・アンド・ライト
（Ｒｅａｄ  ａｎｄ  Ｗｒｉｔｅ）を示し、データを読む権限と書き込む権限を有する意味である。本例では、オーダの内容はリソースＡ設計であるから、データ（設計の結果）を書き込む権限を有する必要があり、権限種別が「ア」「イ」に相当する担当者が実行又は処理モジュールに実行を指示できる。また、図８中のエリア種別テーブル１２２は、エリアのグループ分けを行うテーブルである。運用管理の対象となるリソースが広範囲に渡る場合には、エリアを区切って運用管理することがあるため、同じ担当者でもエリア毎に保有する権限が異なることとなる。そこで、エリア種別テーブル１２２によって幾つかのエリアをグループ分けしている。エリア種別テーブル中の「○○エリア」とは、支店名、営業所名等の場合や市町村名のような住所の場合などがあり得るが、特に地理的な表現方法を限定しない意味である。図７のオーダ情報の例中のお客様住所である「東京都千代田区・・・」が「○○エリア」に該当するとすれば、エリア種別は「▲１▼」が適用される。ここで、実行権限テーブル１２３において、権限種別「ア」又は「イ」、適用エリア種別「▲１▼」の担当者はＡ太郎とＢ花子であり、どちらかがリソースＡ設計を実施または実施指示できる。本例においては、Ａ太郎が受付者であり、基本データを投入したオーダ投入者でもあるため、Ａ太郎を実行権限者と選択する。Ａ太郎が基本データ投入後にオーダの実施を指示することにより、図１の構成では、リソースＡ運用管理サーバ３０がリソースＡ設計を自動的に行い、その結果を制御モジュール１１の制御部１１０が受け取り、図７中のオーダ内容にリソースＡ情報の結果を書き込む。このような処理によって、状態シートは、図９（ｂ）のリソースＡ設計結果登録後の状態に変化する。
【００２７】
図９（ｂ）は、正常に基本フローが終了した場合であるが、リソースＡ設計フローが失敗する場合は次のようになる。リソースＡ運用管理サーバ３０はリソースＡ設計のオーダを受けると、リソースＡ処理モジュール３１がリソースＡ情報ＤＢ３２を参照してリソースＡの在庫を調べる。この在庫情報が不足している場合、設計を実行できない場合がある。このような場合には、制御部１１０は、リソースＡ運用管理サーバ３０からエラー情報を受け取り、状態シートのリソースＡデータの状態をエラー状態に変更する。
【００２８】
次に、制御部１１０は図３の判断処理３０４に進む。判断処理３０４では、状態シートの状態の値が目標の値と比較し、一致する場合は終了となり、制御部１１０は投入者に終了したことを送信する。状態シートの状態の値に目標の値と異なるものがあるときには、基本フロー選択処理３０２へ戻る。図９（ｂ）の状態遷移の例では、リソースＡ設計結果登録後の状態なので、基本フロー選択処理３０２へ戻ることとなる。
【００２９】
ここで、基本フロー選択処理３０２でのエラー処理３０２−２について説明する。基本フロー選択処理でエラーが発生する原因は、入力項目のすべてが既知である基本フローが存在しない場合、選択できる基本フローによって変更できるデータ種別の状態がすべてエラー状態となっている場合があり得る。
【００３０】
まず、入力項目のすべてが既知である基本フローが存在しない場合は、制御部１１０は投入者に対してエラーメッセージを送信する。これは、投入者の入力データが不足しているために発生するエラーだからである。例えばお客様住所が入力されないまま、図７のオーダを指示した場合には、リソースＡ設計を行うことができないため、Ａ太郎に対してエラーメッセージが送信されることになる。ここで、このような入力データ不足に対応する方法として、オーダ入力時に入力データの不足がないことを確認する方法もある。この確認のためには、オーダ内容と入力データ項目とを対応付ける表を用いることが考えられる。
【００３１】
次に、選択できる基本フローによって変更できるデータ種別の状態がすべてエラー状態となっている場合には、制御部１１０は通信部１１２を介して管理サーバ（ここでは、リソース運用管理サーバ）に実行指示をした担当者にエラーメッセージを送信する。実行指示をした担当者が操作端末から処理結果を入力し、状態を完了状態に変更できれば、再度基本フロー選択処理３０２へ戻ることとなる。ここで、エラーメッセージが複数の実行指示者に送信される場合もあるが、このような状況はエラー状態となっているデータ種別の状態を変更する処理が独立の場合に発生し得る。この場合には、複数の実行指示者に同時にエラーメッセージを送信し、すべての実行指示者からの入力を待って処理を進める方法と、実行指示者へのエラーメッセージ送信、実行指示者からの入力を１人づつ行う方法とがある。
【００３２】
ところが、実行指示をした担当者にも状態を完了状態にできない場合や完了状態にするために時間を要する場合もある。このような場合には、実行指示者が操作端末からエラー情報を入力し、制御部１１０がエラーメッセージを投入者に送信することでオーダが実行不能であることを知らせる。例えば十分なリソースＡ情報がリソースＡ情報ＤＢ３２に登録されていないまま、図７のオーダを指示した場合には、リソースＡ設計を行うことができないため、Ａ太郎に対してエラーメッセージが送信されることになる。Ａ太郎はリソースＡ情報の登録を行う必要があるが、情報の登録作業に時間を要する場合にはエラー情報を操作端末から入力する。この場合にはＡ太郎が投入者でもあるが、投入者としてのＡ太郎へエラーメッセージが送信され、Ａ太郎はオーダの取消、保留等の判断をすることとなる。オーダの取消とは、記録部１１１のオーダ情報記録部１１１３に記録されているオーダ情報を取り消してしまい、生成した状態シートを消滅させることを意味する。このような取消の場合には、すでに完了状態となっているデータ種別の状態を元に戻すため、関連したサーバに情報ＤＢへの登録の取消依頼や実行又は実行指示者に対して電子メール、ＦＡＸ等の通信手段又は本システムにログインしたときに取消を表示する手段によって通知する。このような処理が終了すると、実際にオーダ情報と状態シートを消滅させる。オーダの保留とは、オーダ情報や状態シートは保持するが、ワークフロー制御を停止させることを意味する。
【００３３】
図９の状態遷移の説明に戻る。状態シートは図９（ｂ）のリソースＡ設計結果登録後の状態となっており、図３の処理フローでは基本フロー選択処理３０２に戻っている。この段階では、リソースＡ番号も既知となっているので、入力項目がすべて既知のデータであるのは、リソースＣ設計フロー又はリソースＢ、Ｃ設計フローの２つがある。状態シートの目標値と状態値の比較をすると、リソースＣデータのみでなくリソースＢデータも変更する必要があるので、リソースＢ、Ｃ設計フローを優先して選択する。本説明の前提としているように、リソースＢとリソースＣの設計が互いに関連するため、２種類のリソースを一連の処理で設計するためである。また、リソースＣ設計フローやリソースＢ設計フローが存在する理由は、リソースＣのみやリソースＢのみの設計オーダもあり得るからである。このような場合は、状態シートの状態値と目標値の違いが、リソースＣデータのみ又はリソースＢデータのみとなるため、容易に基本フローの選択ができる。
【００３４】
次に、図３の手配処理３０２の２回目を実行する。ここでは、図５のリソースＢ、Ｃ設計フローに従って、まず、リソースＣ設計、仮登録の処理を行う。前回と同様に、図８に示した権限情報ＤＢ１２の各テーブル１２１、１２２、１２３を参照する処理から説明する。オーダの内容はリソースＣ設計であるから、データ（設計の結果）を書き込む権限を有する必要があり、権限種別テーブル１２１より、権限種別が「イ」に相当する担当者が実行又は処理モジュールに実行を指示できる。また、図７のオーダ情報の例中のお客様住所である「東京都千代田区・・・」が「○○エリア」に該当する前提で説明しているので、エリア種別テーブル１２２中のエリア種別は「▲１▼」が適用される。そこで、実行権限テーブル１２３で、権限種別「イ」、適用エリア種別「▲１▼」の担当者であるＢ花子が実行又は実行指示することとなる。そこで、制御部１１０は、Ｂ花子に対して設計、仮登録を電子メール、ＦＡＸ等の通信手段又はＢ花子が本システムにログインしたときに依頼を表示する手段によって依頼する。ここでは、図１の構成例に従っているので、リソースＣの設計等の処理をするリソースＣ運用管理サーバは存在せず、リソースＣ情報管理システム（ＤＢ）又は管理表５２の情報からＢ花子が設計をする。設計結果は操作端末５１から入力され、制御部１１０が、これを通信部１１２を介して受信し、記録部１１１に仮登録する。ここで、仮登録には１つの候補を仮登録する方法と複数の候補を仮登録する方法がある。また、複数の候補を仮登録する場合には優先順位を付加することもあり得る。このような処理によって、状態シートは図９（ｃ）に示すリソースＣ設計結果仮登録後の状態に変化する。
【００３５】
上述の説明は正常にリソースＣ設計、仮登録処理が終了した場合であるが、失敗した場合には、制御部１１０は、エラー情報を通信部１１２を介して受信することにより、状態シート２０のリソースＣデータの状態をエラー状態に変更し、その後のリソースＢ、Ｃ設計、仮登録フローは行わず、図３の判断処理３０４へ進む。
【００３６】
正常にリソースＣ設計、仮登録処理が終了した場合、図３の手配処理３０３が継続し、リソースＢ設計、登録の処理に進む。ここで、オーダの内容はリソースＢ設計であるから、データ（設計の結果）を書き込む権限を有する必要がある。図８の権限種別テーブル１２１より、権限種別が「ア」又は「イ」に相当する担当者が実行又は処理モジュールに実行を指示できる。また、図７のオーダ情報の例中のお客様住所である「東京都千代田区・・・」が「○○エリア」に該当する前提で説明しているので、エリア種別テーブル１２２中のエリア種別は「▲１▼」が適用される。そこで、実行権限テーブル１２３で、権限種別「ア」又は「イ」、適用エリア種別「▲１▼」の担当者であるＡ太郎又はＢ花子が実行又は実行指示することとなる。
【００３７】
ここで、Ａ太郎は投入者であり、Ｂ花子が基本フローのリソースＣの設計、登録も担当しているので、どちらが実行又は実行指示を行うのかが問題になる。今回の例では、リソースＢ運用管理サーバ４０が存在するので、Ａ太郎が基本データ投入後にリソースＢ設計の実行を指示していれば、リソースＣ設計結果が仮登録されると、制御部１１０から自動的にリソースＢ運用管理サーバ４０に対して設計、登録の指示が送信される。
【００３８】
もし、Ａ太郎が実行を指示していなかった場合には、制御部１１０はＡ太郎及びＢ花子に対して設計、仮登録を依頼する。依頼の方法には、前述のように電子メール、ＦＡＸ等の通信手段又は本システムにログインしたときに依頼を表示する手段がある。その他にＢ花子に対しては、Ｂ花子がリソースＣの設計、仮登録の依頼を受けるときに同時に依頼をする手段又はＢ花子が仮登録を終了させたときに操作端末５１へ表示する手段もある。そして、Ｂ花子が実行指示を行うこととなる。
【００３９】
リソースＢの設計では大きく分けて２通りの方法がある。１つ目は制御部１１０が記録部１１１に仮登録されているリソースＣ番号を１つ選んだ上で、リソースＢ処理モジュール４１に設計を指示する方法である。この場合に、リソースＢ運用管理サーバ４０は与えられたリソースＡ番号とリソースＣ番号の組合せを実現できるリソースＢが存在すれば、そのリソースＢの中から必要数を選びリソースＢの設計結果とし、与えられたリソースＣ番号をリソースＣの設計結果とする。また、与えられたリソースＡ番号とリソースＣ番号の組合せを実現できるリソースＢが存在しなければ、エラー情報を制御部１１０に送信する。エラー情報を受けた制御部１１０は、記録部１１１に仮登録されている他のリソースＣ番号を１つ選び、リソースＢ処理モジュール４１に設計を指示する。このように繰り返し、リソースＡ番号とリソースＣ番号の組合せを実現できるリソースＢが存在すれば、そのリソースＢの中から必要数を選びリソースＢの設計結果とし、与えられたリソースＣ番号をリソースＣの設計結果とする。仮登録されたリソースＣ番号のすべてでエラーとなった場合には、制御部１１０はリソースＢ設計は失敗したものと判断する。
【００４０】
２つ目は制御部１１０が記録部１１１に仮登録されているすべてのリソースＣ番号を送信し、リソースＢ処理モジュール４１に設計を指示する方法である。この方法ではリソースＢ運用管理サーバ４０が、与えられたリソースＡ番号と複数のリソースＣ番号の中から組合せを実現できるリソースＢ番号とリソースＣ番号を選び、リソースＢ、リソースＣの設計結果とする。組合せが存在しない場合には、リソースＢ運用管理サーバ４０は設計失敗と判断し、エラー情報を制御部１１０に送信する。
【００４１】
正常に終了した場合には、リソースＢの設計結果は記録部１１１のオーダ情報記録部１１１３に登録される。このような処理によって、状態シートは、図９
（ｄ）に示すリソースＢ設計結果登録後の状態に変化する。
【００４２】
また、制御部１１０はリソースＣ設計、確定の処理に進み、リソースＣの設計者であるＢ花子に選ばれたリソースＣ番号を電子メール、ＦＡＸ等の通信手段又はＢ花子が本システムにログインしたときに依頼を表示する手段によって知らせる。Ｂ花子がリソースＣの選定結果を確認することで、リソースＣ番号が記録部１１１のオーダ情報記録部１１１３に登録される。このような処理によって、状態シートは、図９（ｄ）に示すリソースＣ設計結果確定後の状態に変化する。
【００４３】
このようにして、図３の判断処理３０４に再び進む。設計に失敗した場合には、状態シートのリソースＢデータ、リソースＣデータの状態をエラー状態とし、リソースＣの仮登録を削除した上で、判断処理３０４へ進む。ここで、正常に進んでいる場合、図９（ｅ）の状態遷移の例ではリソースＣ設計結果確定後の状態なので、基本フロー選択処理３０２へ戻ることとなる。なお、エラー状態が含まれる場合にも、状態シートの状態の値が目標の値と一致しないため、基本フロー選択処理３０２へ戻ることとなる。
【００４４】
再度、図３の基本フロー選択処理３０２について説明する。まず、制御部１１０は状態シートの状態の値と目標値とを確認し、１つ又は複数の状態値を目標値に変更できる基本フローの中から、入力項目が既知のデータで足りる基本フローを選択する。また、２以上の基本フローが実行可能な場合には、どの基本フローを選定してもかまわない。図９（ｄ）の状態では、リソースＡ番号、リソースＢ番号、リソースＣ番号共に既知であるから、リソースＡ工事フロー、リソースＢ工事フロー、リソースＣ工事フローのいずれでも選択できる。ここでは、リソースＡ工事フローを選択したとする。なお、リソースＢ工事フロー、リソースＣ工事フローを選択したとしても、以下の説明の順序が変更されるだけである。また、このようにどの基本フローが選択されても良い場合には、並列に基本フローを進める方法もあり得る。さらには、順番に行う場合にも優先順位を別データとして設定できるようにする方法もあり得る。
【００４５】
次に、図３の手配処理３０３に進む。ここでは、図５のリソースＡ工事フローに従って処理を行う。オーダの内容はリソースＡ工事であるから、データ（工事稼働手配の結果）を書き込む権限を有する必要があり、図８に示した権限種別テーブル１２１から権限種別が「ウ」に相当する担当者が実行又は処理モジュールに実行を指示できる。また、図７のオーダ情報の例中のお客様住所である「東京都千代田区・・・」が「○○エリア」に該当する前提で説明しているので、エリア種別テーブル１２２中のエリア種別は「▲１▼」が適用される。そこで、実行権限テーブル１２３で、権限種別「ウ」、適用エリア種別「▲１▼」の担当者であるＣ一郎が実行又は実行指示することとなる。制御部１１０は、Ｃ一郎に対してリソースＡ稼働手配を電子メール、ＦＡＸ等の通信手段又はＣ一郎が本システムにログインしたときに依頼を表示する手段によって依頼する。ここでは図１の構成例に従っているので、リソースＡ稼働の手配をするリソースＡ工事管理サーバ６０がＣ一郎の実行指示に従って稼働手配をする。そして、リソースＡ工事管理サーバ６０は、工事者の手配が正常に終了すれば結果を制御部１１０に送信し、記録部１１１のオーダ情報記録部１１１３にリソースＡ稼働データが登録される。このような処理によって、状態シートは、図９（ｆ）に示すリソースＡ工事手配完了後の状態に変化する。なお、工事者の手配ができなかった場合には、リソースＡ工事管理サーバ６０はエラー情報を制御部１１０に送信し、状態シートのリソースＡ稼働データの状態はエラー状態となる。
【００４６】
次に、再び図３の判断処理３０４に進むが、正常・エラーのどちらの場合も再度基本フロー選択処理３０２に戻ることになる。
【００４７】
基本フロー選択処理３０２では、上述の通りリソースＢ工事フローとリソースＣ工事フローとが選択可能である。ここでは、リソースＢ工事フローが選択されたとする。
【００４８】
次に、再度、図３の手配処理３０３となり、リソースＢ稼働手配の処理を行う。ここで、権限種別テーブル１２１から、権限種別が「エ」に相当する担当者が実行又は処理モジュールに実行を指示できる。また、前回同様にエリア種別テーブル１２２中のエリア種別は「▲１▼」が適用される。そこで、実行権限テーブル１２３で、権限種別「エ」、適用エリア種別「▲１▼」の担当者であるＤ次郎が実行又は実行指示することとなる。制御部１１０は、Ｄ次郎に対してリソースＢ稼働手配を電子メール、ＦＡＸ等の通信手段又はＤ次郎が本システムにログインしたときに依頼を表示する手段によって依頼する。図１の構成例では、リソースＢ稼働手配をするリソースＢ工事管理サーバは存在しないので、Ｄ次郎が稼働手配をする。結果は操作端末７１から入力され、制御部１１０にて記録部１１１のオーダ情報記録部１１１３に登録され、状態シートはリソースＢ工事手配完了後の状態に変化する。
【００４９】
その後、図３の判断処理３０４、基本フロー選択処理３０２を経て、手配処理３０３となり、同様にリソースＣ稼働手配の処理がＤ次郎によって行われ、正常に記録部１１１のオーダ情報記録部１１１３に登録されると、状態シートは、図９（ｇ）に示すリソースＢ、Ｃ工事手配完了後の状態となる。この場合、図３の判断処理３０４フローに進むと、状態シートは状態の値と目標の値とがすべて一致しており、処理終了となる。
【００５０】
〔処理例２〕
図１に示した構成例で、リソースＡの設計と工事を必要とするオーダ（注文）があった場合の、状態シートの状態遷移の例を図１０に示す。以下に、図３の処理フローにより、図１０に示すような状態遷移となることを説明する。
【００５１】
制御モジュール１１の税制御部１１０の最初の処理は、認証・オーダ登録処理３０１であり、オーダを受けた者（例えば、Ａ太郎）がシステムにアクセスして、パスワードおよびオーダの内容等を入力してきた場合、該オーダを受けた者の認証等のセキュリティーチェックを行った後に、オーダの内容に関する基本データを記録部１１１のオーダ情報記録部１１１３に登録する。この処理は前述の図９の場合と基本的に同じであるが、異なるのは、オーダの内容がリソースＡの設計と工事のみであることである。このようにオーダが限定される場合には、図１０（ａ）の基礎データ投入後に示すように、オーダ内容にあわせて目標値が設定された状態シートが作成される。なお、状態シートは、本処理では関与しないリソースＢデータ以降のデータ種別部分を省略したものを作成することでもよい。
【００５２】
次に、図３の基本フロー選択処理３０２に進む。この処理では、前述の場合と同様に、図５に示している基本フローの中でどのフローを行うのかを選択する。各基本フローには対応する必須の入力項目と出力項目のテーブル（入出力項目テーブル）が図６のように用意されている。まず、制御部１１０は状態シートの状態の値と目標値とを確認し、１つ又は複数の状態値を目標値に変更できる基本フローの中から、入力項目が既知のデータで足りる基本フローを選択する。ここで、オーダの無いデータ種別の目標値は「０」になっているため、オーダと関係のない基本フローは選定されない。図１０（ａ）の状態では、リソースＢやＣの目標値は「０」であり、状態値と一致しているからリソースＢ、Ｃに関する基本フローは選定されない。また、リソースＡ設計フローの入力項目はすべて既知であるのに対し、リソースＡ工事フローではリソースＡ番号が未知であるため、まず、リソースＡ設計フローを選択することとなる。
【００５３】
次に、図３の手配処理３０３に進む。この処理では、リソース処理モジュールやリソース運用管理部門などへのオーダの手配を行う。ここでも、図８に示した権限情報ＤＢ１２のテーブル１２１、１２２、１２３を用いて説明する。オーダの内容はリソースＡ設計であるから、データ（設計の結果）を書き込む権限を有する必要があり、権限種別テーブル１２１中の権限種別が「ア」「イ」に相当する担当者が実行又は処理モジュールに実行を指示できる。また、図７のオーダ情報の例中のお客様住所である「東京都千代田区・・・」が「○○エリア」に該当する前提で説明しているので、エリア種別テーブル１２２中のエリア種別は「▲１▼」が適用される。そこで、実行権限テーブル１２３で、権限種別「ア」又は「イ」、適用エリア種別「▲１▼」の担当者はＡ太郎とＢ花子であり、どちらかがリソースＡ設計を実施または実施指示できる。本説明においては、Ａ太郎が受付者であり、基本データを投入したオーダ投入者でもあるため、Ａ太郎が基本データ投入後にオーダの実施を指示することにより、リソースＡ運用管理サーバ３０がリソースＡ設計を自動的に行い、制御部１１０が、その結果を通信部１１２を通して受信し、オーダ情報記録部１１１３の図７中のオーダ内容にリソースＡ情報の結果を書き込む。このような処理によって、状態シートは、１０図（ｂ）に示すリソースＡ設計結果登録後の状態に変化する。
【００５４】
次に、図３の判断処理３０４に進む。正常に進んでいる場合、図１０の状態遷移の例では、状態シートは図１０（ｂ）のリソースＡ設計結果登録後の状態なので、基本フロー選択処理３０２へ戻ることとなる。なお、エラー状態が含まれる場合にも、基本フロー選択処理３０２へ戻ることとなる。
【００５５】
再度、図３の基本フロー選択処理３０２について説明する。まず、制御部１１０は状態シートの状態の値と目標値とを確認し、１つ又は複数の状態値を目標値に変更できる基本フローの中から、入力項目が既知のデータで足りる基本フローを選択する。図１０（ｂ）の状態は、リソースＡ稼働データのみが目標値と異なる状態であるからリソースＡ工事フローが選択される。
【００５６】
次に、再び図３の手配処理３０３となる。この処理では、図５のリソースＡ工事フローに従って処理を行う。オーダの内容はリソースＡ工事であるから、データ（工事稼働手配の結果）を書き込む権限を有する必要があり、図８に示した権限種別テーブル１２１から権限種別が「ウ」に相当する担当者が実行又は処理モジュールに実行を指示できる。また、図７のオーダ情報の例中のお客様住所である「東京都千代田区・・・」が「○○エリア」に該当する前提で説明しているので、エリア種別テーブル１２２中のエリア種別は「▲１▼」が適用される。そこで、実行権限テーブル１２３で、権限種別「ウ」、適用エリア種別「▲１▼」の担当者であるＣ一郎が実行又は実行指示することとなる。制御部１１０は、Ｃ一郎に対してリソースＡ稼働手配を電子メール、ＦＡＸ等の通信手段又はＣ一郎が本システムにログインしたときに依頼を表示する手段によって依頼する。本説明では図１の構成例に従っているので、リソースＡ稼働の手配をするリソースＡ工事管理サーバ６０がＣ一郎の実行指示に従って稼働手配をする。リソースＡ工事管理サーバ６０は、工事者の手配が正常に終了すれば結果を制御部１１０に送信し、制御部１１０は、記録部１１１のオーダ情報記録部１１１３にリソースＡ稼働データを登録する。このような処理によって、状態シートは、図１０（ｃ）に示すリソースＡ工事手配完了後の状態に変化する。
【００５７】
次に、図３の判断処理３０４に進む。この場合、状態シートは状態の値と目標の値とがすべて一致しているため、処理終了となる。
【００５８】
〔処理例３〕
図１に示した構成例で、リソースＡ、Ｂ、Ｃの設計のみを必要とするオーダ
（注文）があった場合の、状態シートの状態遷移の例を図１１に示す。この処理例では、図９に従って説明した最初の処理例１において、図９（ｅ）のリソースＣ設計結果確定後の状態になると、状態シートは目標値と状態値がすべて一致するため、処理終了となる。
【００５９】
〔処理例４〕
図１に示した構成例で、リソースＡ、Ｂ、Ｃのデータを参照するオーダの場合の、状態シートの状態遷移の例を図１２に示す。この処理例場合、前述の処理例３と異なるのは、参照のみであるためデータを登録する必要はなく、図７の権限種別テーブルで「Ｒ」の権限を有していれば可能なことである。
【００６０】
最初の処理は、図３の認証・オーダ登録処理３０１であるが、参照したい者がシステムにアクセスし、認証等のセキュリティーチェックの後に、参照にあたってのキー情報を入力する処理となる。キー情報とは、図６の入出力項目テーブルの入力項目が該当する。例えば、リソース代表番号やリソースＡ番号などである。ここで、リソース代表番号とは、リソースの組合せに対して付与された番号の意味である。例えば、前述の設計のオーダにおいてリソースＡ、Ｂ、Ｃの組合せが決まったが、このような組合せに対して付与される番号である。このリソース代表番号によって、関連するリソースの組合せの管理が容易になることが期待できる。参照するためのキー情報の入力で十分であるため、図８の権限種別テーブル１２１の例では、実施者として登録されている者は全員参照する権限を有している。参照する権限を有する者がキー情報を入力すると、制御部１１０にて、前述と例と同様にオーダ情報が記録部１１１のオーダ情報記録部１１１３に登録されると共に、状態シートが作成される。この状態が図１２のキー情報登録後であり、基本データは状態の値、目標の値とも「０」になっている。その後の状態遷移は、前述の例と基本的に同様である。
【００６１】
参照の場合には、リソースの運用管理サーバへのアクセス権が多くの参照者に許可されるため、設計にくらてべリアルタイム性の向上が得られる。
【００６２】
〔処理例５〕
図１に示した構成例で、リソースＡ、Ｂ、Ｃの廃止の設計と工事とを必要とするオーダ（注文）があった場合の、状態シートの状態遷移の例を図１３に示す。このようなオーダはお客様からサービスの停止を依頼された場合等に発生する。
【００６３】
この場合の最初の処理は、オーダを受けた者（例えば、Ａ太郎）がシステムにアクセスし、これを受げて制御部１１０が認証等のセキュリティーチェックの後にオーダの内容に関する基本データを記録部１１１のオーダ情報記録部１１１３に登録する処理であり、前述の図９、図１０、図１１の場合と同じである。廃止の設計とは、実際には現在使用中のリソースを参照するという点で図１２の場合と似ている。しかし、設備の状態を変更し、データベースの書き換えが必要なため、図７の権限種別テーブルで「ＲＷ」の権限を有していなければならない。次に、リソースＡ、Ｂ、Ｃの廃止の設計として参照を行うこととなるが、手順は図１２と同じである。また、リソースＡ、Ｂ、Ｃに対する工事手配の手順は図９で説明した工事手配の手順と同じである。このような処理によって、図１３に示す状態遷移となり、オーダは終了する。
【００６４】
以上、本発明の一実施の形態について説明したが、本発明はこれに限られるものでないことは云うまでもない。また、図３に示したような処理手順は、ワークフロー管理制御用プログラムとしてコンピュータで実行可能な言語で記述し、コンピュータが読み取り可能な記録媒体（ＦＤ、ＣＤ−ＲＯＭ、ＭＤなど）に記録して提供することが可能である。このワークフロー管理制御用プログラムをワークフロー制御サーバにインストールすることにより、所期の機能が実現する。
【００６５】
【発明の効果】
以上説明したように、本発明によれば、状態シートによってオーダ内容を目標状態として、現在の進捗を状態として管理し、状態を変更する最小単位を基本フローとして定義することで、各基本フローの入出力テーブルから現在の状態から目標状態に近づける基本フローを選定することを可能とし、権限情報ＤＢによって実行又は実行指示ができる権限者を探し、依頼をすることで、ワークフローの制御を自動的に行うことを可能とする効果がある。また、ワークフロー制御の自動化により、複雑かつ膨大なワークフローのプロセス定義を不要とする効果がある。
【図面の簡単な説明】
【図１】本発明の一実施形態の全体的システム構成を示す図である。
【図２】本発明の一実施形態のワークフロー制御サーバの機能ブロック図である。
【図３】本発明の一実施形態の処理フローを示す図である。
【図４】本発明の一実施形態の状態シートを示す図である。
【図５】本発明の一実施形態で記録されている基本フローを示す図である。
【図６】本発明の一実施形態で記録されている基本フローの入出力項目テーブルを示す図である。
【図７】本発明の一実施形態で記録されているオーダ情報の例を示す図である。
【図８】本発明の一実施形態で記録されている権限種別テーブルの例を示す図である。
【図９】本発明のによる処理例１での状態シートの状態遷移を示す図である。
【図１０】本発明による処理例２での状態シートの状態遷移を示す図である。
【図１１】本発明による処理例３での状態シートの状態遷移を示す図である。
【図１２】本発明による処理例４での状態シートの状態遷移を示す図である。
【図１３】本発明による処理例５での状態シートの状態遷移を示す図である。
【符号の説明】
１０    ワークフロー制御サーバ
１１    制御モジュール
１２    権限情報ＤＢ
２１、５１、７１    操作端末
３０、４０    リソース運用管理サーバ
６０    リソース工事管理サーバ
１１０    制御部
１１１    記録部
１１１１  状態シート記録部
１１１２  基本フロー記録部
１１１３  オーダ情報記録部
１１２    通信部
１２１    権限種別テーブル
１２２  エリア種別テーブル
１２３  実行権限テーブル
４００  状態シート
【図１】
0003667230.tif 000002
【図２】
0003667230.tif 000003
【図３】
0003667230.tif 000004
【図４】
0003667230.tif 000005
【図５】
0003667230.tif 000006
【図６】
0003667230.tif 000007
【図７】
0003667230.tif 000008
【図８】
0003667230.tif 000009
【図９】
0003667230.tif 000010
【図１０】
0003667230.tif 000011
【図１１】
0003667230.tif 000012
【図１２】
0003667230.tif 000013
【図１３】
0003667230.tif 000014