【実施例1】
【0019】
<実施例1の概念>
【0020】
図1は、実施例1のワークフロー管理システムの特徴のひとつであるプロセスの連鎖によるワークフローの定義の概念を表す図である。図中のひとつひとつの丸はプロセスを表しており、丸の中の番号は説明のためのプロセスの番号である。プロセス間の矢印はワークフローの進捗方向を表している。例えば、第3プロセスからは第4プロセスと第5プロセスへ進捗するルートがあり、また、案件を中止するルートもある。このように一つのプロセスから同時に複数のプロセスに進捗してもよい。またプロセス間の遷移はワークフローの進捗のみならず、第4プロセスから第1プロセスへの遷移のように既に通過したプロセスへの回帰であってもよい。このようなプロセス間の遷移は権限ある者がアクションを実行することにより実現される。
【0021】
このように、本発明のワークフロー管理システムは、仕事の流れを複数のプロセスに細分化し、ワークフローはそれら複数のプロセスが有機的に連鎖した集合体として定義される。このようにワークフローを多数の異なるプロセスの組合せとして定義することにより、どのようなワークフローでも自由に設計し、変更することが可能となる。
【0022】
図2は、一のプロセスの状態が遷移する様子を表す図である。プロセス内部では常に一の状態が選択されており、図の例では「新規」→「対応中」→「対応済み」→「完了」のように状態が遷移する。そしてそれぞれの遷移は権限ある者がアクションを実行することにより実現される。アクションによる遷移には、
図2のようにプロセス内部でその状態を遷移させるものと、
図1の矢印のように一のプロセスから別のプロセスへと遷移するものとがあり、さらにはこれら両方を同時に行うものがある。
【0023】
図3は、一のプロセスを定義するための構成を表す図である。図はプロセスの状態が「対応中」である場合における「アクション」と「ロール」の定義を表している。アクションとロールの定義は状態ごとに行われ、プロセスの状態が変わればこれらも異なる。図のアクション中、「対応を確認し、対応済みとする」とするアクションは、
図2で説明したようなプロセス内部でその状態の遷移をもたらすアクションである。また、「二次対応へエスカレーションする」とするアクションは
図1で説明した一のプロセスから別のプロセスへの遷移を伴うアクションである。「中止する」とするアクションは、
図1で説明した案件の中止をもたらすアクションである。
【0024】
図3はまた、「対応を確認し、対応済みとする」アクション及び「中止する」アクションはAさんのみが実行することができ、「二次対応へエスカレーションする」アクション及び「内容を訂正する」アクションはBさんのみが実行することができ、「保留とする」アクションは、Cさんのみが実行することができることを表している。このように、アクションごとに実行権限を有する者を定義することができる。もちろん、一のアクションを実行することができる者が複数定義されてよい。
【0025】
「二次対応へエスカレーションする」とあるアクションは別プロセスへと遷移するアクションである。例えば、当該プロセスがコールセンターによる顧客苦情処理という一次対応であって、サービスマンの現地派遣という二次対応を要請した場合がこれに該当する。当アクションはBさんのみが実行することができる。
【0026】
あるアクションを実行した場合に、反復実行される類型化された複数の処理を同時に行うことがある。例えば、「二次対応へエスカレーションする」アクションにおいては、二次プロセスを新規生成してワークフローを二次プロセスへ遷移させる処理を行うと同時に、一次プロセスの状態を「対応済み」とする処理を行ってもよい。このように、アクションを構成する要素となる類型化された処理を「アクション要素」と呼ぶ。本発明は、複数のアクション要素をユーザが自由に組み合わせてアクションを定義できることを特徴とする。
<実施例1の構成>
【0027】
図4は、実施例1のワークフロー管理システムの機能ブロック図である。実施例1のワークフロー管理システム0401は、利用者識別情報保持部0402と、プロセス定義保持部0403と、アクション要素保持部0404と、アクション定義受付部0405と、アクション実行部0406とを有する。利用者識別情報保持部には利用者情報0420が保持され、プロセス定義保持部には状態0411、アクション0412及びロール0413が保持される。これらの保持を行うことにより実質的にはプロセス0410を定義して保持することとなる。アクション要素保持部には一以上のアクション要素0430が保持される。
【0028】
実施例1のワークフロー管理システムは、「一以上のプロセスを含むワークフローを、権限ある利用者がプロセスをある状態から他の状態へと遷移させることにより進行させるワークフロー管理システム」である。ワークフローが一以上のプロセスを含むものであることは
図1で、プロセスの状態の遷移については
図2で既に説明した。
【0029】
「利用者識別情報保持部」は、利用者を識別するための利用者識別情報を保持する。利用者識別情報とは、典型的にはログインIDやパスワード等を指し、
図3にて説明したアクションの実行権限を判断する際等に利用される情報である。
【0030】
「プロセス定義保持部」は、「状態」と、「アクション」と、「ロール」を保持する。プロセスの状態については、
図2で説明した。アクションとは「状態に関連付けられた操作」であり、「ロール」とは「アクションの実行権限を得るために利用者識別情報が満たすべき条件である。」これらは
図3で説明した。状態、アクション及びロールはプロセスごとに保持される。そしてこのような定義が多数のプロセスについて保持されることにより、ワークフローの定義が構築される。
【0031】
このようにワークフローを定義するために、ワークフローを構成するための多数のプロセスが定義される。このようなプロセスの定義は定型化された業務の型を定義するものであるが、実際の業務においては同一のプロセスについて多数の案件が処理されシステムにインスタンスとして登録される。そのようなインスタンスを識別するためプロセス定義保持部はさらにインスタンス識別番号を保持するようにするとよい。
【0032】
「アクション要素保持部」は、前記アクションを構成する複数の操作であるアクション要素を保持する。繰り返しになるが、アクション要素とはアクションを構成する単位要素となる定型化された処理のことをいう。
図5は、アクション要素の具体例である。図のようにアクション要素は通常複数定義される。これらのうち、二番目の「関連案件を作成する」は
図3の「二次対応へエスカレーションする」の箇所で説明した二次プロセスの生成に使用される。八番目の「状態を更新する」は
図3の「対応を確認し、対応済みとする」の箇所で説明した状態の更新に使用されるものであって、「プロセスの状態を遷移させる」アクション要素である。
【0033】
「アクション定義受付部」は、前記アクション要素を構成要素としてアクションを定義するために、一以上のアクション要素の組合せの選択を受け付けてプロセス定義保持部に保持させる。
【0034】
図6は、アクション定義受付部がユーザからアクション要素の選択を受け付けるためのインタフェイスの一例である。図のインタフェイス0600は、コールセンターの苦情受付業務に係るプロセスの状態が対応中である場合に実行可能な「二次対応へエスカレーションする」アクションを定義するものである。アクションは必ず特定のプロセスの特定の状態に関連して定義される。図のプロセス名欄0601はプロセスを、状態欄0602はプロセスの状態を、アクション名欄0603は当該アクションのアクション名を指定するために使用される。
【0035】
アクション要素一覧0604は前記「二次対応へエスカレーションする」アクションを構成するものとして選択可能な全てのアクション要素のなかから既に選択したアクション要素のリストが表示される。そのような選択の方法としては、図のように追加ボタン0605をマウスポインタなどで押し下げると
図5のような選択可能なアクション要素の一覧が表示され、そのひとつをクリックするなどして選択すると前記アクション要素一覧に追加するといった構成等が考えられる。
【0036】
図にはないが、アクション要素一覧に含まれるアクション要素のそれぞれを実行する順番を指定するようにしてもよい。
【0037】
図の例では、「二次対応へエスカレーションする」を実行すると、第一に、「関連案件を作成する」アクション要素により、例えばサービスマンの現地派遣という新たなプロセスが生成され、第二に、「状態を更新する」アクション要素により、サービスセンタによる当プロセスの状態が「対応中」から「対応済み」に変更され、第三に、「コメントを作成する」アクション要素により、担当者が「サービスマンが現地対応中」といったコメントを作成でき、第四に、「メールを送信する」アクション要素により、サービスマンに対し現地での対応を指示するメールを送信することができる。これら一組の処理をひとつのアクションにて実行することができる。
【0038】
ロール一覧0606は、前記アクションを実行する権限を定義する。図では、実行権限のある担当者の名前の一覧となっているが、名前の代わりに実行権限のある者の役職名や肩書などであってもよい。
【0039】
「アクション実行部」は、「前記ロールと前記利用者識別情報を照合した結果当該利用者に当該アクションの実行権限があると認めた場合には、当該利用者から当該アクションの実行を受け付けて実行する。」アクション実行部は、利用者からアクションの実行について指示を受けたときは、まず当該利用者に当該アクションの実行権限があるかを判断する。具体的には、利用者のログインIDにより利用者を識別し、当該アクションのロールが権限ある者の名前リストである場合には利用者の名前がそのリストに含まれるかを、当該アクションのロールが権限ある者の肩書である場合には当該利用者がその肩書を有するかを、判断する。当該利用者に実行権限があると判断した場合には、アクションを構成するアクション要素を順番に又は同時に実行する。
【0040】
図7は、実施例1のワークフロー管理システムのハードウェア構成図である。ワークフロー管理システムは、各種演算処理及び検索処理を行うCPU0701と、プログラムやデータを保持するためのハードディスクドライブ装置、ROMなどの外部記憶装置0702と、プログラムやデータを一時的に記憶して保持するメモリ0703と、を備えている。また、通信回線を介して通信を行うための通信インタフェイス0704も備えている。そしてそれらがデータ通信経路であるシステムバス0705によって相互に接続され、情報の送受信や処理を行う。
【0041】
外部記憶装置に保持されたプログラムは必要に応じてメモリに読みだされ、CPUは当該プログラムをメモリに参照することで各種演算処理を実行する。また、このメモリにはそれぞれ複数のアドレスが割り当てられており、CPUの演算処理においては、そのアドレスを特定し格納されているデータにアクセスすることで、データを用いた演算処理を行うことが可能になっている。
【0042】
図8は、実施例1のワークフロー管理システムの実際の使用態様を表す図である。ワークフロー管理システム0801は、インターネットや社内LAN等の通信回線0802を介して多数のパーソナルコンピュータ0803に接続される。ワークフローを構成するプロセスを担当するユーザはそれぞれこれらパーソナルコンピュータをインタフェイスとしてワークフロー管理システムにログインし、ワークフローを進捗させる。
【0043】
このようなハードウェア構成や使用態様は他の実施例でも同様である。
【0044】
図9は、実施例1のワークフロー管理システムにおいてアクションの定義が行われる際の処理の流れを表すフロー図である。第一に、アクション要素保持部が、前記アクションを構成する複数の操作であるアクション要素を保持する(ステップ0901)。第二に、アクション定義受付部が、前記アクション要素を構成要素としてアクションを定義するために、一以上のアクション要素の組合せの選択を受け付けてプロセス定義保持部に保持させる(ステップ0902)。最後に、プロセス定義保持部が、プロセスの状態に関連付けられた操作であるアクションを保持する(ステップ0903)。
【0045】
図10は、実施例1のワークフロー管理システムにおいてアクションの実行が行われる際の処理の流れを表すフロー図である。第一に、利用者識別情報保持部が利用者を識別するための利用者識別情報を保持し(ステップ1001)、プロセス定義保持部が、アクションの実行権限を得るために利用者識別情報が満たすべき条件であるロールを保持する(ステップ1002)。第二に、アクション実行部がロールと利用者識別情報を照合し、利用者にアクションの実行権限があるかどうかを判断する(ステップ1003)。ステップ1003で利用者にアクションの実行権限があると判断された場合には、アクション実行部がアクションの実行を受け付けて実行する(ステップ1004)。
<実施例1の効果>
【0046】
実施例1のワークフロー管理システムによれば、様々な使用目的や使用方法に対応した汎用的なワークフロー管理システムが提供される。すなわち、当ワークフロー管理システムによれば、プロセスを有機的に制限なく連鎖させることによりワークフローを自由にデザインすることができる。また、予め用意されたアクション要素を組み合わせることによりプログラムの変更を行うことなく、プロセス内の状態の遷移の際の処理や、プロセス間の関係も自由に定義することができる。このように、実施例1のワークフロー管理システムによれば、使用目的毎に異なるワークフロー管理システムを導入する必要がなく、ひとつのシステムで多様な使用目的や、使用方法に対応することができる。
【実施例2】
【0047】
<実施例2の概念>
【0048】
実施例1のワークフロー管理システムは
図1におけるように一のプロセスから他のプロセスへの遷移が可能なものであった。このようなプロセス間の遷移は複雑なワークフローを定義するうえで重要なものである。例えば、ITサービス運用の分野においてベストプラクティスとして標準仕様となっているITIL(Information Technology Infrastructure Library)のサービスマネジメントは、「インシデント管理」、「問題管理」、「構成管理」、「変更管理」及び「リリース管理」の五つのプロセスにより構成されるが、ワークフロー管理システムを使用してこれを運用しようとする場合にはそれぞれのプロセス間で遷移可能とすることが求められる。そしてそのようなプロセス間の遷移は、前述のようにアクション要素を組み合わせることにより自由に定義可能であり、具体的には
図3の「二次対応へエスカレーションする」アクションのように一のプロセスから別のプロセスを生成することにより実現された。
【0049】
ところが実際の運用においては、一次プロセスから二次プロセスが生成されて一次プロセスがそのまま終了となることは少なく、二次プロセスが終了した後にはワークフローが一次プロセスに帰ってくることが珍しくない。例えば、前述したITILのサービスマネジメントでは、一次プロセスであるインシデント管理において発生したインシデントについて事業活動への影響が最小限となるよう迅速なサービスの復旧を行うと同時に、二次プロセスである問題管理においてインシデントの原因追究及び再発防止策の策定が行われる。二次プロセスである問題管理において原因解明や対応手段の策定が早急になされた場合には、一次プロセスのインシデント管理に直ちにその対応手段が利用されることがある。
【0050】
このように二次プロセスから一次プロセスへのワークフローの回帰を可能とするためには、一次プロセスから二次プロセスを生成する際に両プロセスを関連付けておくことが必要となる。実施例2のワークフロー管理システムは、このように関連するプロセスを紐づけすることにより、プロセス間におけるプロセスの進捗・回帰を容易としたワークフロー管理システムである。
<実施例2の構成>
【0051】
実施例2のワークフロー管理システムの機能ブロック図は
図4で説明した実施例1のワークフロー管理システムのそれと多くの部分で共通するので省略する。異なるのはプロセス0410を定義する情報として状態0411、アクション0412及びロール0413の他に「関連情報」が含まれることと、アクション要素0430とは、具体的には、(1)関連するプロセスを新たに生成するためのアクション要素と、(2)新たに生成されたプロセスとの関連を定義するための関連情報を前記プロセス定義保持部に記録するためのアクション要素とが含まれるものである点である。以下、実施例2のワークフロー管理システムに独自の構成を説明する。
【0052】
「プロセス定義保持部」は、他のプロセスとの関連である関連情報をさらに保持する。「関連情報」とは、他のプロセスとの関連を示す情報である。例えば、前述のITILの設例では一次プロセスである「インシデント管理」から「問題管理」が二次プロセスとして生成された。この場合、インシデント管理のインスタンスの関連情報としては、生成した問題管理のインスタンスのインスタンス識別番号を保持するなどする。
【0053】
「複数のアクション要素」は、関連するプロセスを新たに生成するためのアクション要素と、新たに生成されたプロセスとの関連を定義するための関連情報を前記プロセス定義保持部に記録するためのアクション要素とを含む。
【0054】
「関連するプロセスを新たに生成するためのアクション要素」とは、例えば、
図5で説明した「関連案件を作成する」アクション要素である。「新たに生成されたプロセスとの関連を定義するための関連情報を前記プロセス定義保持部に記録するためのアクション要素」は、例えば、前述のITILの設例において新たに生成された二次プロセスのインスタンスのインスタンス識別番号を生成元の一次プロセスのインスタンスの関連情報に記録するアクション要素のこと等をいう。この場合、生成元の一次プロセスのインスタンスのインスタンス識別番号を二次プロセスのインスタンスの関連情報として同時に記録してもよい。
<実施例2の効果>
【0055】
実施例2のワークフロー管理システムによれば、関連するプロセス間の遷移を自在に行うことができる。