(57)【要約】【課題】管理工数やリードタイムの大幅な削減を実現するワークフロー管理システムを提供すること。【解決手段】コンピュータを用いて作業のフローを管理するワークフロー管理システムを提供する。ワークフロー定義は、複数のタスクの作業内容及び作業順序を定義すると共に各タスクの実行状況を評価する評価式を定義する。各タスクの作業内容は、作業を実行するのに必要なデータ及び作業結果を示すデータとして可変の状態量を有するエンティティを用いて定義される。評価式は、エンティティの状態量が満たすべき所定の条件を定義している。タスクを実行する場合に、評価式を用いてエンティティの状態量の評価値を求めて状態量の適否を判定する。エンティティの状態量が所定の条件を満たしている場合には、次のタスクが実行される。【選択図】図１
2010039555.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータを用いて作業のフローを管理するワークフロー管理システムであって、
複数のタスクの作業内容及び作業順序と、各タスクの実行の前提条件及び各タスクの実行状況を評価する評価式とを定義するワークフロー定義が、メモリ上にデータとして記憶されており、
各タスクの作業内容は、作業を実行するのに必要なエンティティ及び作業結果に関するエンティティであって可変の状態量を有するエンティティを用いて定義されており、
前記評価式は、前記エンティティの状態量が満たすべき所定の条件を定義しており、
前記複数のタスクのいずれか１つのタスクを実行する場合に、タスクに関連するエンティティの状態量が所定の条件を満たしているかを監視するために前記メモリから前記評価式を抽出し、前記評価式を用いて前記エンティティの状態量の評価値を求めて状態量の適否を判定する評価式判定手段と、
タスクの実行又は外部からの通知により前記エンティティの状態量が変化した場合には、エンティティの状態量を変化後の状態量に更新する状態量更新手段と、
前記評価式と前記エンティティの関連付けを定義しており、前記評価式判定手段によって抽出された評価式に関連するエンティティの状態量の変化を監視し、状態量が変化したときに変化後の状態量を前記評価式判定手段に送信するエンティティセンサ手段と、
前記評価式判定手段により前記エンティティの状態量の適否を受け付け、前記エンティティの状態量が所定の条件を満たしている場合に、次のタスクの実行を開始させるフロー制御手段とを備えたワークフロー管理システム。
【請求項２】
前記フロー制御手段は、エンティティの状態量が所定の条件を満たしていない旨の判定を前記評価式判定手段から受信したときに、評価の対象となったエンティティと関連付けされたタスクを再度実行させることをさらに備えた請求項１に記載のワークフロー管理システム。
【請求項３】
前記エンティティの状態量に変化が生じた場合には、前記状態量の変化に伴う評価式の評価値の変化をタスク及び前記状態量の変化と共に評価式判定手段からデータとして受け付けてメモリに記憶する履歴管理手段をさらに備え、
前記フロー制御手段は、エンティティの状態量が所定の条件を満たしていない旨の判定を前記評価式判定手段から受信したときに、前記履歴管理手段によりタスクごとにデータとしてメモリに記憶されているエンティティの状態量の変化及び評価値の変化を参照し、再実行するタスクとして状態量及び評価値に変化が生じたタスクを指定する請求項１に記載のワークフロー管理システム。
【請求項４】
前記タスクの作業順序は、並列処理される複数のタスクが存在し、タスクを実行するのに必要とされるエンティティがタスク間で競合する場合に、前記エンティティを用いるタスクを実行するための優先順位が各タスクに対して割り付けられており、
前記フロー制御手段は、前記エンティティの状態量が所定の条件を満たしていると共に、前記優先順位を参照してタスクが実行可能な状態にある場合に、タスクの実行を開始させる請求項１から３のいずれか１つに記載のワークフロー管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば製造業などにおけるワークフローを管理するシステムに関し、特に、管理工数やリードタイムの大幅な削減を実現するワークフロー管理システムに関する。
【背景技術】
【０００２】
ワークフローとは、作業の一連の流れを標準化し、記述したものである。一般に各作業には担当者が設定されており、担当者として指定された人がその作業を行う。図１４に企業における物品購買のワークフローの一例を示す。ワークフロー管理システムとは、ワークフローに定義された順に作業が行えるように、定義された順に担当者に作業指示を出したり、必要な電子文書を準備して、作業が円滑に行えるようにするためのものである。特許文献１には、誰もが同じ作業方法を実行したり、準備について意識せずに作業を開始することができるようにすることを狙いとした、ワークフロー管理システムが開示されている。定義された各作業に対しては、成功と失敗が定義されており、作業終了時にどちらかの状態になる。また、図１５に示すように、失敗になった場合には、例外処理または補正処理（補償処理）を実行することができる。ここで、例外処理とは失敗の時だけ行われる特別な処理を指し、補正処理とは実行してきた内容を元に戻す復元処理のことを指す。
【０００３】
【特許文献１】特開２００８−６５５８０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、製造業における不具合のように、想定どおりにならない場合の原因と復旧処理が複雑になるような場合を記述することが困難である。そのため、記述が困難な状況が多い場合、ワークフロー管理システム上では、作業を完結できないことが多くなり、その結果、ワークフロー管理システムを利用せずに独自に作業などを行ってしまう可能性がある。そのような状況になると、ワークフローを使う大きなメリットである「作業の同一化による作業効率の向上」が望めなくなる可能性が高い。また、工数の情報が部分的にしか残らなくなるため、製造原価の計算など、工数実績を利用して算出するための情報としても利用価値が大幅に低減する可能性がある。
【０００５】
例えば、図１６に示すような金型製造におけるワークフローの例を考える。ここでは以下のような特徴のある作業工程をワークフロー化することを考える。
-  作業工程でデータだけでなく物理的物体が登場し、その種類が多岐にわたる。
-  作業のリソース（物理的物体や作業者などの人）が有限であり（かつ、無限であると見なせず）、作業間でのリソースの競合が頻繁に発生する。
-  物理的な変形や化学反応など、作業工程に現れるエンティティの変形、変化をともなう。
-  上記変化の状況によって、作業順序や作業内容を変更する必要がある。
【０００６】
このような作業工程は製造業では多く存在し、以下のような特徴がある。
-  一連の作業の流れは存在するが、一つ一つの工程を手順どおりにやっても求める結果が得られないことが多い。製造業であれば、温度や湿度などの環境、材質の不均一性、機械の個体差などの条件によって、同じ手順で行ったとしても、異なる結果が得られることが一般的である。そのような状況においては、一連の手順では定義されていない作業を追加したり、フローの一部あるいは全体を違う手順に変更する、などのことを行わないと、求める結果が得られず、不具合となって表れることになる。
-  作業の順序が仮に固定で定まってもリソースの競合やリソースの状態によって、（納期を満足するために）作業開始を調整したり、作業内容を変更したりする必要がある。
【０００７】
例えば、上述のような金型製造における作業工程をワークフロー化する場合を考える。金型製作における加工では、種々の加工工程をどのような順序で実行すれば金型部品が作成できるかどうか、ということは部品の形状を見て決定することができる。しかしながら、実際にはその工程どおりに流せば加工が完成する、ということは多くなく、測定しながらパラメータを変更した加工データを作成して再度加工する、手加工を加えるためのまったく異なる工程をはさむ、時には削り過ぎたものを修復する工程を入れる、などそのときの材料の削られ方や、実際に加工する加工機や工具の状況に応じて、臨機応変に作業を変更する必要性が生じる。
【０００８】
このような状況が頻繁に起こり、想定どおりにならない場合の原因と復旧処理が複雑になるような場合、従来のワークフローではその全体を記述することが困難である。現実世界では、作業が正常に完了してもその結果が想定どおりに得られるとは限らず、作業の成功/失敗とその成果物が想定どおりに生成されることに因果関係が薄い。そのため、作業内容とその成功、失敗のみを判断する従来のワークフロー管理システムを実行するだけでは、「作業は正常に進んだが結果的にできたものは欲しいものではない」状況が多く発生することになり、ワークフローどおりに実行することの意味が失われてしまう。
【０００９】
さらに他にも従来のワークフロー管理システムでは実現できない状況がある。すなわち、成果物が想定された状況と異なるとき、成果物の状態に従って対応処理を決定する必要があるが、ワークフローにはそれが記述できない。ワークフローには成果物の状態という概念が存在しないからである。また一般のワークフローでは、エラー時の処理は、例外処理、または補正処理に限られるが、例外処理では処理終了後の再開位置を自由に選ぶことはできず、補正処理ではもとに戻す処理しか選べないため、自由な手戻りを実現することはできない。成果物の状態ではなく、作業のフローとして記述する場合、すべてを（擬似的な）作業または分岐として記述し、それぞれの状況に応じて作業を再開する場所にフローをつなぐ必要があるが、それは問題が発生する作業の数：ｍと再開する作業の数：ｎに対してｍ×ｎ個のフローを記述することが必要となることになり、これは作業を詳細化するにしたがって、急激に増大する。
【００１０】
また、製造業における生産などの作業においては、生産用の機械、工具、ジグなど、人ではないリソースの競合が頻繁に起こるが、従来のシステムでは、それらのリソースの競合を考慮に入れることができないため、システム上は作業が可能と判断されているのに、実際には作業ができない状況が起こっていた。その結果、リソース待ちを人が判断する必要があり、生産性の向上に寄与していなかった。システムは作業が開始できない場合の理由が自動的には残らないため、製造業における生産活動において重要なリソースの最適化や生産予測を行うための十分な情報を提供できなかった。
【００１１】
また、ワークフローには作業担当者は定義されており、そこで必要なデータも定義されているが、そのデータは競合を考える必要がないと見なせるようなもの（ファイルや文書フォーマットなどのデータや、お金、印刷すればいくらでもできるような紙など）だけを扱っている。そのため、製造業などの作業工程で重要になる、有限個のものの空き状態などに応じて作業順序を入れ替えたり、作業内容を変えたりするようなことはそもそも考慮されていない。その結果、従来のワークフローを使って作業を表現すると、システムは作業が可能である、と認識していても、実際には（ものが競合しているなどで）作業ができない場合がある。このような状況では従来のワークフロー管理システムはほぼ無力であり、作業可能であるかどうかは結局人が判断する必要があり、生産性の向上にはつながっていなかった。
【００１２】
ここまで述べた上記事項に鑑み、本発明は、複雑で、定義された作業フローどおりに実行することが必ずしも正しい結果につながらず、複雑な手戻りを表現することが難しい、有限個しかないリソースを考慮していない、という問題を解決し、特に製造業において、製造工数の管理や生産予測の精度向上を実現することで、管理工数やリードタイムの大幅な削減を実現することを主たる目的とする。
【課題を解決するための手段】
【００１３】
本発明の第一の態様は、
コンピュータを用いて作業のフローを管理するワークフロー管理システムであって、
複数のタスクの作業内容及び作業順序と、各タスクの実行の前提条件及び各タスクの実行状況を評価する評価式とを定義するワークフロー定義が、メモリ上にデータとして記憶されており、
各タスクの作業内容は、作業を実行するのに必要なデータ及び作業結果に関連するデータとして可変の状態量を有するエンティティを用いて定義されており、
前記評価式は、前記エンティティの状態量が満たすべき所定の条件を定義しており、
前記複数のタスクのいずれか１つのタスクを実行する場合に、タスクに関連するエンティティの状態量が所定の条件を満たしているかを監視するために前記メモリから前記評価式を抽出し、前記評価式を用いて前記エンティティの状態量の評価値を求めて状態量の適否を判定する評価式判定手段と、
タスクの実行又は外部からの通知により前記エンティティの状態量が変化した場合には、エンティティの状態量を変化後の状態量に更新する状態量更新手段と、
前記評価式と前記エンティティの関連付けを定義しており、前記評価式判定手段によって抽出された評価式に関連するエンティティの状態量の変化を監視し、状態量が変化したときに変化後の状態量を前記評価式判定手段に送信するエンティティセンサ手段と、
前記評価式判定手段により前記エンティティの状態量の適否を受け付け、前記エンティティの状態量が所定の条件を満たしている場合に、次のタスクの実行を開始させるフロー制御手段とを備えたワークフロー管理システムである。
【００１４】
本発明の第二の態様は、前記第一の態様に係るワークフロー管理システムにおいて、前記フロー制御手段は、エンティティの状態量が所定の条件を満たしていない旨の判定を前記評価式判定手段から受信したときに、評価の対象となったエンティティと関連付けされたタスクを再度実行させることを特徴とするワークフロー管理システムである。
【００１５】
また、本発明の第三の態様は、前記第一の態様に係るワークフロー管理システムにおいて、前記エンティティの状態量に変化が生じた場合には、前記状態量の変化に伴う評価式の評価値の変化をタスク及び前記状態量の変化と共に評価式判定手段からデータとして受け付けてメモリに記憶する履歴管理手段をさらに備え、
前記フロー制御手段は、エンティティの状態量が所定の条件を満たしていない旨の判定を前記評価式判定手段から受信したときに、前記履歴管理手段によりタスクごとにデータとしてメモリに記憶されているエンティティの状態量の変化及び評価値の変化を参照し、再実行するタスクとして状態量及び評価値に変化が生じたタスクを指定することを特徴とするワークフロー管理システムである。
【００１６】
さらに、本発明の第四の態様は、前記第一乃至第三のいずれか一態様に係るワークフロー管理システムにおいて、前記タスクの作業順序は、並列処理される複数のタスクが存在し、タスクを実行するのに必要とされるエンティティがタスク間で競合する場合に、前記エンティティを用いるタスクを実行するための優先順位が各タスクに対して割り付けられており、
前記フロー制御手段は、前記エンティティの状態量が所定の条件を満たしていると共に、前記優先順位を参照してタスクが実行可能な状態にある場合に、タスクの実行を開始させることを特徴とするワークフロー管理システムである。
【００１７】
上記第一乃至第四の態様によれば、ワークフロー定義において、通常のワークフローで定義されるタスクの作業内容及び作業順序に加えて、タスクの作業内容を可変の状態量を有するエンティティを用いて定義し、エンティティの状態量の変化したときに、変化後のエンティティの状態量の適否を評価することにより、タスクが所望の結果を実現できているかどうかを随時判定しながら、フローを進行させることが可能となる。
また、上記第一乃至第四の態様によれば、ワークフロー定義においてエンティティとタスクを関連付けておくことにより、通常のフロー作業だけでなく、手戻りの作業箇所を特定し、手戻りをワークフローシステム上で実現することができる。
さらに、上記第一乃至第四の態様によれば、ワークフロー定義において、並列処理される複数のタスクが存在し、タスクを実行するのに必要とされるエンティティがタスク間で競合する場合に、作業順序として各タスクの優先度を定義しておくことにより、並列処理される複数のタスクの競合を回避することができる。
このように、上記第一乃至第四の態様によれば、ワークフローにおいて、例えば、定義された作業フローどおりに実行することが必ずしも正しい結果につながらない、複雑な手戻りを表現することが難しい、有限個しかないリソースを考慮していない、などといった従来の問題を解決することができる。
【発明の効果】
【００１８】
本発明によれば、特に製造業において、管理工数やリードタイムの大幅な削減を実現することが可能となる。
【発明を実施するための最良の形態】
【００１９】
以下に図面を参照して、本発明の実施の形態について説明する。ただし、以下の説明は、あくまでも本発明の例示にすぎず、以下の記載によって発明の技術的範囲が限定されるものではない。
【００２０】
[ワークフロー管理システムの構成]
本実施形態に係るワークフロー管理システム１００は、パーソナルコンピュータやワークステーションなどの一般的なコンピュータ端末及びその周辺機器、そして、このコンピュータ上で実行されるコンピュータプログラムから構成されている。コンピュータ周辺機器は、汎用のものであるため、本システムの中心的な役割を果たすのは、ワークフロー制御に係るソフトウェアの部分である。図１に、本実施形態に係るワークフロー管理システム１００の概略図を示す。
【００２１】
本実施形態に係るワークフロー管理システム１００は、一連の作業の流れを定義したワークフロー定義をコンピュータメモリ上にデータとして記憶しておき、本実施形態に係るソフトウェアであるワークフロー制御モジュールを用いてワークフローを生成すると共に、ワークフローを構成する各タスクを制御することにより実現される。
【００２２】
ワークフロー定義１１０は、従来技術において一般に定義されているように各タスクの作業順序及び各タスクの作業内容を定義することに加えて、タスクを開始し得る条件としての評価式とタスクの状態としてタスクが期待通りに行われたかどうかを判断するための評価式とをタスク毎に定義することができる。そして、これらの評価式は、タスクの各々を定義するために必要なエンティティと関連付けられてコンピュータに記憶されるものである。ここで言うエンティティは、タスクを実行するのに必要であって実行結果に影響を与える可変の入力データ及びタスク実行後の出力データとして定義される。すなわち、評価式は、タスクが実行可能な状態にあるかどうかを評価すると共にタスクの実行結果が適切かどうかを評価するために必要なエンティティと関連付けられている。このようなエンティティを評価式と関連付けて定義しておくことにより、エンティティの状態量の変化により、タスクが実行可能な状態にあるかどうかを評価式により定量的にコンピュータが判断する仕組みを作ることができる。また、エンティティの状態量の変化に伴ってタスクの実行結果が変化する場合に、そのタスクの実行結果が期待通りのものであるかどうかを評価式により定量的にコンピュータが判断する仕組みを作ることができる。特に、いわゆる熟練者でなければ通常は判断が難しいようなタスクの実行結果の不具合状態をこのようなエンティティ及び評価式により定義しておくことにより、フローの下流工程に進む前に望ましくないタスクの実行結果を抽出することができることになる。
【００２３】
また、金型製造などの上流工程と下流工程のタスク間でエンティティが複雑に関連してタスクに影響を与えている場合には、共通のエンティティを各タスクにおいて評価式と共に定義しておくことにより、タスクが下流工程に進んでしまった後でも上流工程のタスクに遡って再度タスクを実行し直すことに効率良く利用することができる。
【００２４】
評価式判定モジュール１２０は、ワークフロー定義において定義されている評価式を受付けて各評価式に必要なエンティティを抽出してメモリ又はデータベース等に登録する。そして、タスクを実行している間に、評価式判定モジュール１２０は、メモリやデータベース等に記憶されているエンティティ１４０の状態量が満たすべき所定の条件を定義した評価式によりその条件を満たされているかどうかを判定する。
【００２５】
アプリケーション１８０は、各タスクを実行するのに必要となる一連のコマンドのセットを有したソフトウェアである。また、アプリケーション１８０を実行したときに、そのタスクに関連するエンティティの状態量をデータベース等に登録することも行う。このように、アプリケーション１８０はエンティティの状態量がタスクの実行と共に常に更新されるように構成されている。したがって、あるタスクの実行の結果として得られるエンティティが後続のタスクの実行に影響を与えるものである場合には、このエンティティの状態量を随時更新しておくことにより、その後続のタスクにおける評価式による評価を最新の情報に基づいて行うことが可能となる。
【００２６】
エンティティセンサモジュール１３０は、アプリケーション１８０の実行に伴うエンティティの状態量の変化を監視し、エンティティの状態量が変化したときにその旨を評価式判定モジュール１２０に通知するモジュールである。
【００２７】
フロー制御モジュール１５０は、ワークフローの開始及び終了を制御すると共に、評価式によってタスクが所望の実行結果を生成していないと判断される場合に、評価式の評価に必要なエンティティと関連付けされたタスクを特定して、評価式の評価値が所定の条件を満たすまでエンティティの変化を待つようにそのタスクの実行を制御する。そのために、フロー制御モジュール１５０は、ワークフローが開始されると、ワークフロー定義１１０から各タスクを読み込み、各タスクの作業順序及び作業内容をエンティティと関連付けた上で、各タスク及びこれを実行するアプリケーションを含むデータとしてワークフロー１６０を生成する。そして、フロー制御モジュール１５０は、関連付けられたタスクとエンティティをさらに評価式と関連付けして、評価式判定モジュールから得られる評価式の評価値が所定の条件を満たしたときに、そのタスクを終了とするように制御する。
【００２８】
また、ワークフロー制御モジュール１５０は、評価式の評価値が所定の条件を満たすまで評価式による判定を繰り返しながらエンティティの変化を待つだけでなく、評価式の評価値が所定の条件を満たしていないときには、その評価式に関連するエンティティの状態量を変化させるべく、現在のタスクより上流の問題となるエンティティの状態量の変化に関連するタスクに手戻りするようにタスクの実行を制御する構成としてもよい。この場合、エンティティの状態量を変化させることにより所定の条件を満たすように評価値を変化させるために、上述のタスクとエンティティと評価式との関連付けに基づいて、現在のタスクより上流のどのタスクを再実行すべきかを定義した手戻りのための手戻りタスクをワークフロー定義１１０において定義しておく。このように、ワークフロー定義１１０を定義しておくことにより、ワークフロー制御モジュール１５０は、各タスクの開始及び終了を制御するだけでなく、タスクが不都合状態にある場合に、エンティティを変化させるべくそのタスクより上流の特定のタスクを手戻り作業として再度実行し、その後、エンティティの変化により、現在のタスクにおいて評価式の評価値が所定の条件を満たすまで待つように制御することができる。
【００２９】
タスク制御モジュール１７０は、ワークフロー制御モジュール１５０から、前タスクの終了と共に次のタスクの開始を通知されると、次のタスクを実行するためのアプリケーション１８０を起動させる。また、タスク制御モジュール１７０は、あるタスクを実行中に評価式の評価値が所定の条件を満たしていないという通知をワークフロー制御モジュール１７０から受信されたときには、その評価式に関連するエンティティの状態量を変化させるために、そのエンティティに関連する上流のタスクを実行させるようにアプリケーション１８０を起動させる。また、タスク制御モジュール１７０は、アプリケーション１８０からタスク終了の通知を受けると、ワークフローモジュール１５０にタスク終了通知を送る。
【００３０】
割付モジュール１９０は、タスク制御モジュール１７０がワークフロー制御モジュール１５０からタスクの実行開始を通知されているときに、そのタスクが物理的に実際に実行可能であるかどうかを判別するモジュールである。割付モジュール１９０は、実行しようとしているタスクが実際に実行可能であるかどうかの問い合わせをタスク制御モジュール１７０から受信し、実行可能であるか否かの結果をタスク制御モジュール１７０に送信する。より具体的な例として金型加工について言えば、切削等のタスクで利用される加工機が他のタスクで同時期に並行して使われる場合には、その加工機はある特定のタスクでしか使えないことを予め決めておく必要がある。上記の加工機などのエンティティが並列処理されるタスク間で競合しないように、エンティティが競合したときにはどのタスクを優先して実行させるかを予め定義しておく。すなわち、エンティティが同時期に用いられ得るタスクの各々に対して、タスクの優先順位を割り付けておく。このように定義しておくことにより、タスク制御モジュール１７０は、ワークフロー制御モジュール１５０からタスクの実行開始を通知されている状態で、実際にそのタスクが物理的に実行可能かどうかを決定することができる。
【００３１】
[ワークフロー、タスク、エンティティ及び評価式の例]
ここで、ワークフロー定義、タスク、及びエンティティについて簡単な具体例を用いて説明する。図２は、「荷台に荷物を５００ｋｇ以上１０００ｋｇ以下積んで、燃料が８割以上あるなら、トラックが車庫から発車する」という作業のワークフロー定義及びタスク定義を示している。この場合のタスクは、「荷物を運ぶ」、「荷物を荷台に載せる」、及び「トラック発車」の３つのタスクとして定義される。また、トラックというエンティティは２つの状態量を有しており、１つは「荷台の積載量」、もう１つは「燃料の量」である。
【００３２】
「荷物を運ぶ」というタスクの終了後の次のタスクは、「荷物を荷台に載せる」である。この「荷物を荷台に載せる」いうタスクの終了を評価するための評価式は、「トラックの荷台の積載量＞５００ｋｇ ＡＮＤ トラックの荷台の積載量＜１０００ｋｇ」である。上記のワークフロー制御モジュール１５０は、この評価式を満たしたときにだけ、タスク制御モジュール１７０に対して、「荷物を荷台に載せる」というタスクの終了通知をする。
【００３３】
一方、エンティティ「トラック」の状態量「燃料の量」に関する評価式がこの時点で満たされなければ、ワークフロー制御モジュール１５０は、次の「トラック発車」というタスクの開始を通知することができない。「トラック発車」というタスクの開始させることができるかどうかを評価するための評価式は、「トラックの燃料の量＞８０％」である。上記のワークフロー制御モジュール１５０は、エンティティ「トラック」の状態量「荷台の積載量」及び「燃料の量」に関する上記２つの評価式は満たされたときに、「トラック発車」のタスク開始をタスク制御モジュール１７０に通知する。
【００３４】
[ワークフローの制御フロー]
上記のようなワークフロー定義を用いてワークフローを制御するフローについて図３を参照しながら以下に説明する。ワークフロー制御モジュールは、ワークフローを生成し、ワークフローを構成する各タスクの実行の開始及び終了を制御するものである。
【００３５】
まず、コンピュータ上でユーザに促されて、ワークフロー制御モジュール１５０が起動される（ステップ３００）と、ワークフロー制御モジュールがワークフロー定義１１０にアクセスし、エンティティ及び評価式と共に定義されているタスクを読み込み、ワークフローの全体を生成する（ステップ３０１）。ワークフロー定義が読み込まれると、各フローがその実行結果に影響を与えるエンティティと関連付けられる（ステップ３０２）。ステップ３０１及び３０２により、ワークフローについて、各タスクの作業順序及び各タスクの作業内容がデータとして定義されると共に、各タスクにおけるエンティティの状態量と評価式とが関連付けてデータとして定義されていることになる。ワークフロー制御モジュール１５０は、タスク制御モジュール１７０に開始通知を送信する（ステップ３０３）。
【００３６】
一方、評価式判定モジュール１２０は、ワークフロー定義１１０にアクセスしてエンティティと共に定義されている評価式を読み込む（ステップ３０４）。評価式判定モジュール１２０は、その後、読み込んだ評価式を評価する際に必要なエンティティの状態を監視するエンティティセンサを登録する（ステップ３０５）。
【００３７】
タスク制御モジュール１７０は、次に実行すべきタスクの開始通知をワークフロー制御モジュール１５０から受信する（ステップ３１０）。また、後述するように、２つ目以降のタスクを実行しようとする段階では、前のタスクの終了の通知を受信すると共にそのタスクに関連する評価式が所定の条件を満たしていることの通知も受信する（ステップ３１０）。ステップ３１０で受信されるべき通知が全て受信されるまで待機し（ステップ３２０）、全ての通知が受信されると、割付モジュール１９０は、実行しようとしているタスクが実際に実行可能であるかどうかの問い合わせをタスク制御モジュール１７０から受信し、実行可能であるか否かの結果をタスク制御モジュール１７０に送信する（ステップ３３０）。具体的には、エンティティが並列処理されるタスク間で競合しないように、エンティティが競合したときには並列処理されるタスクのうち、どのタスクを優先して実行させるかを予め定義しておく。すなわち、そのエンティティに対する優先順位を並列処理され得る各タスクに割り付けておく。そして、割付モジュールは、その割り付けられた優先順位に基づいて、そのタスクが実行可能であるか否かの結果をタスク制御モジュールに送信する。タスク制御モジュール１７０は、割付モジュール１９０からそのタスクが実行可能であるという結果を受信すると、そのタスクに対応するアプリケーションを実行させる（ステップ３４０）。
【００３８】
次に、アプリケーション１８０は、タスクに対応するアプリケーションの実行によりエンティティの状態量に変化があったかどうかを監視する（ステップ３５０）。アプリケーションの実行によりエンティティの状態量が変化した場合には、その変化後のエンティティの状態量がデータベースに登録され、エンティティセンサモジュールがエンティティの変化を検出する（ステップ３５１）。なお、アプリケーションは、データベースから最新のエンティティが常にアプリケーションに入力されるように、また、アプリケーションの実行後のエンティティが変化したときにはそのエンティティがデータベースに更新データとして登録されるように作成されている。その後、評価式判定モジュール１２０は、変化後のエンティティの状態量を用いて評価式を評価する（ステップ３５２）。評価式判定モジュール１２０は、評価式の評価値が変化したどうかをチェックする（ステップ３５３）。評価値が変化しており所定の条件を満たしていると判定される場合には、ワークフロー制御モジュール１５０に評価値が変化した旨を通知する（ステップ３５４）と、ワークフロー制御モジュール１５０はその評価値が変化した旨をタスク制御モジュール１７０に通知する（ステップ３５５）。
【００３９】
一方、エンティティセンサモジュール１３０がエンティティの状態量を監視し、アプリケーションの実行によりエンティティの状態量が変化しない場合には、フロー制御モジュール１５０は、その旨を評価式判定モジュール１２０から受け付けて、アプリケーション終了の通知をタスク制御モジュール１７０に通知する（ステップ３６０）と、タスク制御モジュール１７０は、タスクの終了の通知をワークフロー制御モジュール１５０に通知する（ステップ３７０）。その後、ワークフロー制御モジュール１５０は、次のタスクが存在するかどうかをチェックする（ステップ３８０）。次のタスクが存在しない場合には、全フローを終了する。一方、次のタスクが存在する場合には、ワークフロー制御モジュール１５０は、ワークフロー定義に従って、タスク制御モジュールにそのタスクの終了を通知する（ステップ３８１）。
【００４０】
このように、本実施形態では、ワークフローにおける２つ目以降のタスクについて、ステップ３１０では、ステップ３０３、ステップ３５５及びステップ３８１によって、実行の対象となる対象タスクの開始通知、その対象タスクに関連する評価式が所定の条件を満たしている旨の通知、及びその対象タスクの前のタスクの終了通知の全てがなされるのを待ってから対象タスクの実行がなされるようになっている。したがって、実行の対象となるタスクが、他の並列に実行され得るタスクとの関係で本当に実行可能であるか、また、実行の対象となるタスクが、所望のエンティティの状態量を伴って実行されたかどうかを自動的に判別することが可能となり、そのタスクを再度実行するかまたはそのタスクを終了してもよいかを自動的に判断する仕組みを実現することが可能となる。すなわち、通常、タスクの結果に問題がない場合には、そのまま、次のタスクの実行がなされる。一方、従来の方法では不具合が生じているにもかかわらず看過されて次のタスクに進行してしまうことを回避するために、本実施形態では、その不具合が生じないようにするためのチェックリストをそのタスクに紐づく評価式として定義しておくと共にその評価式を評価するのに必要なエンティティを定義しておく。そして、このようにコンピュータ上に定義されたエンティティの状態量の変化及びその変化に伴う評価式の評価値の変化を監視し続ける。この点、エンティティと評価式がどのタスクと関連し得るかを予め特定しておくことが重要である。後述する形状の制御などを伴う金型加工などでは、複数の工程（タスク）に密接に関連するエンティティが存在するため、実行しているタスクにおけるエンティティの状態量の変化は、上流タスクの実行結果が必ずしも適切ではなかったことに伴う場合がある。このような場合には、適切にタスクを手戻りさせる仕組みを用意しておかなければ所望のワークフローの結果は得られない。上流タスクのエンティティの状態量の変化が下流タスクの実行結果に影響を与えているという実情を考慮すべきであり、本実施形態は、下流タスクのエンティティが変化したときに、そのタスクの実行状況を監視して、エンティティの状態量の評価結果から関連する上流タスクに手戻りして、エンティティの状態量を変化させて再度それ以降のタスクを実行させることによりタスクの不具合を解消させることを実現可能である。
【００４１】
[データベースとエンティティセンサモジュール]
図４は、データベース１４０を用いた場合のエンティティセンサモジュール４００の構成例を示したものである。データベースアクセスルーティング４１０は、エンティティセンサモジュール４００（図１の１３０に対応）の一部であり、アプリケーション１８０からエンティティの変更された状態量を受信すると、データベースに対するアクセスルーティングをデータベースアクセスモジュール４２０に提供すると共にエンティティの状態量の更新をデータベースアクセスモジュール４２０に要求する。データベースアクセスモジュール４２０は、エンティティセンサモジュール４００の一部としてデータベース１４０の挿入と削除と更新を行う。データベースアクセスモジュール４２０は、エンティティの挿入、削除及び更新のすべての処理を受け付ける。更新の処理を受けるたびに、データベースアクセスモジュール４２０は、評価式判定モジュール１２０に状態量の変更を通知する。挿入、削除の場合には対象となるエンティティが増減することになる。なお、データベースを利用しないことも可能であり、そのような構成も本実施形態で実現可能であることは容易に理解される。
【００４２】
[手戻り機能]
上述したように、ワークフロー制御モジュールは、評価式の評価値が所定の条件を満たしていないときには、その評価式に関連するエンティティの状態量を変化させるべく、現在のタスクより上流の問題となるエンティティの状態量の変化に関連するタスクに手戻りするようにタスクの実行を制御する構成とすることができる。
【００４３】
図５は、手戻りタスクを実行するときのフローを示したものである。タスク制御モジュールがアプリケーションの異常終了を把握する（ステップ５００）と、ワークフロー定義から、手戻り判断用のアプリケーションを実行する（ステップ５１０）。手戻り判断用のアプリケーションにより、システムが自動的に問題が起こっているエンティティを認識する（ステップ５２０）。これは、評価式判定モジュールからの問題がある場合の評価値を受け取ったフロー制御モジュールが、評価式に関連付けられているエンティティを認識することにより実現される。その後、そのエンティティがワークフロー生成時に登録されたフローを検索し、そのエンティティに関連するタスクを抽出する（ステップ５３０）。なお、評価式判定モジュールにおいてエンティティの状態量の評価値が変化したときに、そのエンティティの状態量の変化をタスク及びその評価式の評価値の変化と共にメモリなどの記憶手段に保存しておくことにより、手戻りすべきタスクの候補としてそのエンティティに関連するタスクを抽出することが容易になる。その後、検索により抽出されたタスクを再実行する（ステップ５４０）。再実行後は、問題が生じたタスクに直接戻るようなアプリケーションを用いてもよいし、再実行後のタスクの次に通常は実行されるタスクから順に再度実行するようなアプリケーションを用いてもよい。いずれにしても、フロー制御モジュール及びタスク制御モジュールを介して、このようなアプリケーションにアクセスしてこれを実行することにより手戻りタスクが実現可能となる。
【００４４】
[評価式の分解]
図６は、評価式判定モジュール１２０の構成例を示す。評価式判定モジュール１２０は、ワークフロー定義１１０から評価式の定義が入力されると、評価式の左辺及び右辺が単項になるように評価式を分解し、さらにツリー構造にする。一方、エンティティセンサモジュール１３０からエンティティが入力されると、エンティティの状態量を評価式の右辺に適用し、各評価式の評価をする。その後、各評価式の結果を結合し、具体的には、いずれかの評価式の評価値が所定の条件を満たしていない場合には、その旨と共に評価値がデータとしてフロー制御モジュール１５０に送信される。
【００４５】
[タスクの表記例]
図７は、従来技術によるタスクの表記例（ａ）及び本実施形態によるタスクの表記例（ｂ）を示したものである。たとえば、対象物の状態が２つあり、それが各タスクにおいて突発的に起こる可能性があり、それに応じてタスクＡまたはＢを行わなければならないような状況を考えると、従来技術では、図７（ａ）のように記述する必要があるが、本技術を利用した場合、図７（ｂ）のように記述可能となり、大幅な記述の簡略化が実現できる。
【実施例１】
【００４６】
ここで、本実施形態に係るワークフロー管理システム１００について一実施例を示す。
【００４７】
たとえば金型製造における加工工程においては、以下のような状況に対応する必要がある。
-  工具折損が起きた場合には、工具を交換する。
-  ワークに削り込みが起きた場合はワークを交換する。
-  削り残りがあった場合には、追加工する。
-  ＮＣに問題がある場合には、ＮＣ再作成する。
-  加工機が壊れた場合には、加工機メンテナンスをする。
-  すべて加工が終わったものの、うまく型を組むことができない。
そして、これらの状況は、複数が同時に起こることもあり得る。
【００４８】
図８は、金型部品作成の全体のワークフローを概念的に示したものである。金型部品作成フローとしては、まず、金型設計８００が行われ、次に、ＮＣ作成８１０が行われる。そして、実際に金型部品加工８２０が行われる。不具合が生じた場合に、例えばＮＣファイル８３０の作成に手戻りする。
【００４９】
ここでは、まず、金型部品加工タスクにおいて工具折損の不具合が生じた場合について説明する。
【００５０】
図９は、金型部品加工の詳細フローについて示したものである。また、図１０は、ワークフロー制御モジュールとして工具折損時のモジュールの実施例１０００を示したものである。また、図１１は、工具折損時に工具交換タスクを実行可能にするために初期的に処理されていなければならないフローを示したものである。また、図１２は、工具折損時のモジュールの処理のフローを示したものである。
【００５１】
図９から図１２を参照しながら、工具折損が生じた場合の処理のフローについて説明する。
【００５２】
１．まず、工具折損のフローが実行される前に、評価式抽出モジュール１０１０によってワークフロー定義１１０から評価式定義１０２０が抽出され（図１１のステップ１１００）、工具センサモジュール（エンティティセンサモジュール）１０５０が工具の状態量である監視すべき「折損状態」を読み取る。そして、データベース内の工具エンティティ１０６０の折損状態の監視を開始する（図１１のステップ１１１０）。
【００５３】
２．また、前提として、ワークフロー定義上、工具折損により実行されるフローは、開始ノードから実行されるフローよりも優先度が高く設定しておく（図１１のステップ１１２０）。
【００５４】
３．荒加工９１０（図９参照）を実行している最中に、加工機で工具折損が起こると、加工機からの工具折損エラー情報を受信した加工機制御モジュール１１００がデータベース内の工具エンティティ１０６０の「折損状態」を「正常」から「折損」に変更する（図１２のステップ１２００）。
【００５５】
４．荒加工９１０は工具が折損状態になったことにより、いったん保留（実行を中断）する。
【００５６】
５．上記２で行われた変更を監視している工具センサモジュール１０５０が工具の折損状態を状態量の変更として認識すると、工具センサモジュール１０５０は、工具折損９２０（図９参照）に対応する評価式の判定を実行するために、工具の状態量として折損状態を評価式判定モジュール１０３０に送る（図１２のステップ１２１０）。評価式判定モジュール１０３０は、評価式を判定し、評価式の評価値が変更し、工具折損の問題があることをフロー制御モジュール１０７０に通知する（図１２のステップ１２２０）。フロー制御モジュール１０７０は、ワークフロー定義に従って、工具折損タスク９２０を実行すると、工具折損タスク９２０は「工具折損があれば真」という条件である（図１２のステップ１２３０）ので、フロー制御モジュール１０７０は、フロー定義に従って、工具交換タスク９３０（図９参照）のタスク情報を発生させる（図１２のステップ１２４０）。
【００５７】
６．工具交換タスクが荒加工タスクより優先順位が高いというタスクの優先度に基づき、フロー制御モジュール１０７０は、工具交換９３０のタスクを工具交換指示アプリケーション１０９０により実行する（図１２のステップ１２５０）。すなわち、この場合、工具交換タスクが発生されると、工具交換タスクは荒加工タスクより優先順位が高いため、工具の割付は工具交換タスクに変更される。なお、これは、工具交換タスクの優先順位が荒加工タスクのそれより高いということが、予めワークフロー定義のタスクの作業順序において定義されていることにより実現することができる。この点、図１０には示されていないが、図１と同様に、フロー制御モジュール１０７０と工具交換アプリケーション１０９０との間にタスク制御モジュール及び割付モジュールを配置するように構成してもよい。このように配置されたタスク制御モジュール及び割付モジュールにより、荒加工タスクの実行中には荒加工タスクに対してなされていた工具エンティティの割付を優先度の高い工具交換タスクに変更し、工具交換タスクの実行の開始を可能にする構成とすることができる。
【００５８】
７．工具交換９３０が終了すると、タスク制御モジュール及び割付モジュールにより、工具交換タスクに割り付けられていた工具エンティティを荒加工タスクに割り付けるように変更され（図１２のステップ１２６０）、荒加工タスク９１０より優先度が高いタスクがなくなり、割付対象が復活するため、中断されていた荒加工タスク９１０の再開が可能となる（図１２のステップ１２７０）。
【実施例２】
【００５９】
次に、別の実施例として、金型部品加工タスクにおいてＮＣに不具合が生じた場合の本システムの構成について説明する。図１３は、ＮＣ不具合が生じた場合のシステムの構成例を示している。図１３を参照しながら、ＮＣ不具合が生じた場合の処理のフローについて説明する。
【００６０】
1. まず、このフローが実行される前に、評価式抽出モジュール１０１０によってワークフロー定義１１０から評価式定義１０２０が抽出される。そして、ＮＣファイルセンサモジュール１３１０が、評価式定義１０２０からＮＣファイル１３３０の状態量である「不具合状態」を監視することを読み取る。ＮＣファイルセンサモジュール１３１０は、データベース内のＮＣファイル１３３０の不具合状態を監視開始する。なお、ここでは、取り得る不具合状態は、「不具合がある」、「不具合がある可能性がある」及び「不具合がない」であるとする。
【００６１】
２．次に、データベース内のＮＣファイル１３３０の不具合状態が「不具合がある可能性がある」に変更される。これは、例えば、荒加工タスク中に加工機制御モジュール１１００で何か異常を認識されたときに、その加工で利用していたＮＣファイル１３３０の状態を「不具合がある可能性がある」に変更することで行われる。
【００６２】
３．ＮＣファイルセンサモジュール１３１０は、エンティティであるＮＣファイル１３３０の状態の変更を認識すると、評価式判定モジュール１０３０にＮＣファイル１３３０の変更後の状態量を送る。評価式判定モジュール１０３０は、ＮＣ不具合可能性９４０（図９参照）に対応する評価式を評価式定義１０２０から受け付けて、ＮＣファイル１３３０の変更後の状態量に関する評価式を判定し、ＮＣ不具合可能性９４０が真であることをフロー制御モジュール１０７０に通知する。フロー制御モジュール１０７０はワークフロー定義１１０に従って、ＮＣファイル確認タスクを発生させる。
【００６３】
４. 優先度に基づいて、ＮＣファイル確認タスクが実行される。なお、これは、ＮＣファイル確認タスクは荒加工タスクより優先順位が高いということが、予めワークフロー定義のタスクの作業順序において定義されていることにより実現することができる。
【００６４】
５．ＮＣファイル確認タスクでは、ＮＣファイル確認アプリケーション１３２０が実行される。
【００６５】
６．ＮＣファイル確認アプリケーション１３２０で、ＮＣファイルに不具合があることが確定すると、データベース内のＮＣファイル１３３０の不具合状態が「不具合がある」に変更される。
【００６６】
７．ここで、もとの荒加工を再開しようとするが、ＮＣファイルに不具合がある状態になっているので、割付の設定により再開できずキャンセルされる。
【００６７】
８．履歴管理モジュール１０８０は、エンティティの状態量に変更があった場合には、評価式判定モジュール１０３０から、随時、状態量の変更をタスク及びその評価式の評価値の変化と共に受信してメモリなどの記憶手段に保存することを管理している。フロー制御モジュール１０７０は、ＮＣファイルに不具合が生じたタスクを特定するために、履歴管理モジュール１０８０に問い合わせる。そして、フロー制御モジュール１０７０は、不具合が見つかったタスクから順次タスクを遡り、タスクと共に保存された評価式の評価値の変化を参照して、ＮＣファイルが正常な状態になった（この場合不具合がない状態になった）タスクを確認する。
【００６８】
９．履歴によりＮＣファイルが正常な状態になった工程はＮＣ作成タスクであることがわかるため、手戻り先としてＮＣ作成タスクが示唆される。
【００６９】
このように、履歴管理モジュールにより、エンティティの状態量の変更をタスク及びその評価式の評価値と共に管理しておくことにより、手戻り先を容易に特定することが可能になる。なお、この点、タスクとエンティティと評価式との関連付けに基づいて、現在のタスクより上流のどのタスクを再実行すべきかを定義した手戻りのための手戻りタスクをワークフロー定義において予め定義しておいてもよいことは上述した通りである。
【００７０】
以上、本発明の一実施形態及びその実施例を２例、説明してきたが、本発明は、上記の実施形態・実施例に限定されるものではなく、これに種々の変更を加え得るものであることは容易に理解される。そして、それらが特許請求の範囲の各請求項に記載した事項、及びそれと均等な事項の範囲内にある限り、当然に本発明の技術的範囲に含まれる。上記の実施形態・実施例は特定のワークフローにおける不具合等に対してのものであったが、これはあくまでも一例であり、本発明がこの特定の具体例に限定されるものではない。
【図面の簡単な説明】
【００７１】
【図１】本発明の一実施形態に係るワークフロー管理システムを示している。
【図２】作業のワークフロー定義及びタスク定義を示している。
【図３】本発明の一実施形態に係るワークフローを管理するフローを示している。
【図４】データベースを用いた場合のエンティティセンサモジュールの構成例を示している。
【図５】手戻りタスクを実行するときのフローを示している。
【図６】評価式判定モジュールの構成例を示している。
【図７】従来技術によるタスクの表記例（ａ）及び本実施形態によるタスクの表記例（ｂ）を示したものである。
【図８】金型部品作成の全体のワークフローを概念的に示している。
【図９】金型部品加工の詳細フローについて示している。
【図１０】ワークフロー制御モジュールの実施例として工具折損時のモジュールを示している。
【図１１】工具折損時に工具交換タスクを実行可能にするために初期的に処理されていなければならないフローを示している。
【図１２】工具折損時のモジュールの処理のフローを示している。
【図１３】ＮＣ不具合が生じた場合のシステムの構成例を示している。
【図１４】企業における物品購買のワークフローの従来例を示している。
【図１５】例外処理及び補正処理を用いたワークフローの従来例を示している。
【図１６】金型製造におけるワークフローの従来例を示している。
【符号の説明】
【００７２】
１００    ワークフロー管理システム
１１０    ワークフロー定義
１２０    評価式判定モジュール
１３０    エンティティセンサモジュール
１４０    エンティティ
１５０    フロー制御モジュール
１６０    ワークフロー
１７０    タスク制御モジュール
１８０    アプリケーション
１９０    割付モジュール
【図１】
2010039555.tif 000003
【図２】
2010039555.tif 000004
【図３】
2010039555.tif 000005
【図４】
2010039555.tif 000006
【図５】
2010039555.tif 000007
【図６】
2010039555.tif 000008
【図７】
2010039555.tif 000009
【図８】
2010039555.tif 000010
【図９】
2010039555.tif 000011
【図１０】
2010039555.tif 000012
【図１１】
2010039555.tif 000013
【図１２】
2010039555.tif 000014
【図１３】
2010039555.tif 000015
【図１４】
2010039555.tif 000016
【図１５】
2010039555.tif 000017
【図１６】
2010039555.tif 000018