(57)【要約】【課題】組織ＤＢの設定やルート設定をまったく必要としないワークフローシステムを提供する。【解決手段】ワークフローシステムにおいて、プロセス定義をおこなうプロセス定義部３と、そのプロセス定義に基づいて最初の指示書を作成する初期指示書作成部４と、その指示書を画面上に表示する指示書表示部５と、表示された指示書を用いて処理内容を入力する処理内容入力部６と、その処理内容入力部６により入力された処理内容に応じて次の指示書を作成する次指示書作成部７とを備え、前記処理内容としてアクションおよび宛先を含み、前記処理内容入力部６内に、とりうるアクションの候補からアクションを選択させるアクション選択部９と、とりうる宛先の候補から宛先を選択させるか新規に宛先を入力させる宛先入力部１０とを備えた。【選択図】      図１
2004334379.tif 000002
【特許請求の範囲】
【請求項１】
プロセス定義をおこなうプロセス定義手段と、該プロセス定義に基づいて最初の指示書を作成する初期指示書作成手段と、前記最初の指示書を画面上に表示する指示書表示手段と、表示された指示書を用いて処理内容入力手段により入力された処理内容に応じて次の指示書を作成する次指示書作成手段とを備えたワークフローシステムにおいて、前記処理内容としてアクションおよび宛先を含み、前記処理内容入力手段内にとりうるアクションの候補からアクションを選択させるアクション選択手段と、とりうる宛先の候補から宛先を選択させるか新規に宛先を入力させる宛先入力手段とを備えたことを特徴とするワークフローシステム。
【請求項２】
請求項１記載のワークフローシステムにおいて、前記プロセス定義に自然言語で書かれた処理手順説明を含み、前記初期指示書作成手段および次指示書作成手段はその処理手順説明を指示書内に記載する構成であることを特徴とするワークフローシステム。
【請求項３】
請求項１または請求項２記載のワークフローシステムにおいて、前記処理内容としてコメントを含み、前記次指示書作成手段は入力されたコメントを次指示書内に記載する構成であることを特徴とするワークフローシステム。
【請求項４】
請求項１、請求項２、または請求項３記載のワークフローシステムにおいて、前記処理内容として依頼アクションを含み、前記処理内容入力手段内に、とりうる依頼アクションの候補から依頼アクションを選択させる依頼アクション選択手段を備え、該依頼アクション選択手段を介して選択された依頼アクションを前記次指示書作成手段が次指示書内に記載するアクションの第１候補とする構成であることを特徴とするワークフローシステム。
【請求項５】
請求項１乃至請求項４のいずれか１項に記載のワークフローシステムにおいて、入力された処理内容のすべてまたは一部とともに、その処理内容を入力した利用者を示す利用者情報と、そのときの時刻を前記指示書内に履歴として記録する構成にしたことを特徴とするワークフローシステム。
【請求項６】
請求項１乃至請求項５のいずれか１項に記載のワークフローシステムにおいて、入力された処理内容のすべてまたは一部、処理している利用者を示す利用者情報、およびそのときの時刻を前記指示書とは別の履歴記録手段に履歴として記録する構成にしたことを特徴とするワークフローシステム。
【請求項７】
請求項６記載のワークフローシステムにおいて、前記宛先選択手段内に、とりうる宛先の候補を記録された履歴を用いて作成する宛先候補作成手段を備えたことを特徴とするワークフローシステム。
【請求項８】
請求項６または請求項７記載のワークフローシステムにおいて、前記依頼アクション選択手段内に、とりうる依頼アクションの候補を記録された履歴を用いて作成する依頼アクション候補作成手段を備えたことを特徴とするワークフローシステム。
【請求項９】
情報処理装置上で実行されるプログラムにおいて、請求項１乃至請求項８のいずれか１項に記載のワークフローシステムによったワークフローを実行させるようにプログラミングされていることを特徴とするプログラム。
【請求項１０】
プログラムを記憶した記憶媒体において、請求項９記載のプログラムを記憶したことを特徴とする記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えばパーソナルコンピュータや専用の情報処理装置などを用いて構成されるクライアント・サーバ構成のシステム上で、人から人へ文書や帳票などを流すワークフローシステムに関する。
【０００２】
【従来の技術】
例えば発行者から審査者へ、さらに承認者へと、文書や帳票などを流すワークフローシステムでは、一般にプロセス定義（フローのルート設定など）と組織データベース（ＤＢ）の設定を必要とする。そのため、ワークフローシステムを導入し、運用を開始するまでにある程度以上のコスト（設定作業）がかかる。また、設定がすんだあとでも、例外的な状況（担当者不在など）や組織の変更などが起こるたびにプロセス定義を変更したり、組織ＤＢを改変したりといった保守作業が発生する。
そのため、特開平８−１０１８１７号公報に示された「ワークフロー支援システム」では、前記したプロセス定義における利用者の負担を軽くすることを図って、プロセス定義においてワークフローのためのルールを選択させ、そのルールに関連付けられた条件に従ってワークフローの実行順序を自動的に組み立て、組み立てたワークフローを順次実行する。
また、特開２０００−２５９７３６公報に示された「ワークフロー次作業者動的決定方法」では、起票者の次作業者の決定ルールを参照して次作業者を動的に決定可能なように次作業として起票者の上司職位の公式役割名を登録するか、またはオフィスＩＤを生成して実ユーザー名とともに公式役割名を登録し、次の作業者に作業が移る際に公式役割名を作業者に変更することにより、人事異動により利用者の上司関係に変更があってもワークフローの未着手データについては次作業者を最新の状態で（最新の組織ＤＢで）決定できるようにする。
また、特開平１０−１７７６０８号公報に示された「ワークフローシステム」では、却下や委譲など例外的な状況については、プロセス定義とは別個に定義しておき、例外パターンにより別に定義されている次担当者へ流す。
【特許文献１】特開平８−１０１８１７号公報
【特許文献２】特開２０００−２５９７３６公報
【特許文献３】特開平１０−１７７６０８号公報
【０００３】
【発明が解決しようとする課題】
一般に、ワークフローというと、プロセス定義と組織データベース（ＤＢ）の設定を必要とする。そのため、ワークフローシステムを導入し、運用を開始するまでにある程度以上のコストがかかる。また、設定がすんだあとでも、例外的な状況（担当者不在など）や組織の変更などが起こるたびにプロセス定義を変更したり、組織ＤＢを改変したりといったわずらわしい保守作業が発生する。前記した特開平８−１０１８１７号公報に示された従来技術でも、ルールを設定する必要があるし、ルールの保守および組織ＤＢの保守は必要である。
また、特開２０００−２５９７３６公報に示された従来技術でも、組織ＤＢの保守が必要であるし、特開平１０−１７７６０８号公報に示された従来技術では、例外処理には対応しやすいが、例外でない場合のプロセス定義の保守および組織ＤＢの保守が必要な点は同じである。
本発明の目的は、このような従来技術の問題を解決することにあり、具体的には、組織ＤＢの設定やルート設定をまったく必要としないワークフローシステムを提供することにある。
【０００４】
【課題を解決するための手段】
前記の課題を解決するために、請求項１記載の発明では、プロセス定義をおこなうプロセス定義手段と、そのプロセス定義に基づいて最初の指示書を作成する初期指示書作成手段と、その指示書を画面上に表示する指示書表示手段と、表示された指示書を用いて処理内容入力手段により入力された処理内容に応じて次の指示書を作成する次指示書作成手段とを備えたワークフローシステムにおいて、前記処理内容としてアクションおよび宛先を含み、前記処理内容入力手段内に、とりうるアクションの候補からアクションを選択させるアクション選択手段と、とりうる宛先の候補から宛先を選択させるか新規に宛先を入力させる宛先入力手段とを備えた。
また、請求項２記載の発明では、請求項１記載の発明において、前記プロセス定義に自然言語で書かれた処理手順説明を含み、前記初期指示書作成手段および次指示書作成手段はその処理手順説明を指示書内に記載する構成にした。
また、請求項３記載の発明では、請求項１または請求項２記載の発明において、前記処理内容としてコメントを含み、前記次指示書作成手段は入力されたコメントを次指示書内に記載する構成にした。
また、請求項４記載の発明では、請求項１、請求項２、または請求項３記載の発明において、前記処理内容として依頼アクションを含み、前記処理内容入力手段内に、とりうる依頼アクションの候補から依頼アクションを選択させる依頼アクション選択手段を備え、その依頼アクション選択手段を介して選択された依頼アクションを前記次指示書作成手段が次指示書内に記載するアクションの第１候補とする構成にした。
また、請求項５記載の発明では、請求項１乃至請求項４のいずれか１項に記載の発明において、入力された処理内容のすべてまたは一部とともに、その処理内容を入力した利用者を示す利用者情報とそのときの時刻を前記指示書内に履歴として記録する構成にした。
【０００５】
また、請求項６記載の発明では、請求項１乃至請求項５のいずれか１項に記載の発明において、入力された処理内容のすべてまたは一部、処理している利用者を示す利用者情報、およびそのときの時刻を前記指示書とは別の履歴記録手段に履歴として記録する構成にした。
また、請求項７記載の発明では、請求項６記載の発明において、前記宛先選択手段内に、とりうる宛先の候補を記録された履歴を用いて作成する宛先候補作成手段を備えた。
また、請求項８記載の発明では、請求項６または請求項７記載の発明において、前記依頼アクション選択手段内に、とりうる依頼アクションの候補を記録された履歴を用いて作成する依頼アクション候補作成手段を備えた。
また、請求項９記載の発明では、情報処理装置上で実行されるプログラムにおいて、請求項１乃至請求項８のいずれか１項に記載のワークフローシステムによったワークフローを実行させるようにプログラミングされている構成にした。
また、請求項１０記載の発明では、プログラムを記憶した記憶媒体において、請求項９記載のプログラムを記憶した。
【０００６】
【発明の実施の形態】
本発明のワークフローシステムでは、現在（ワークフロー中の現時点）の担当者が次の担当者や処理内容を指定する。例えば、アクション、宛先、依頼アクションなどを指定するのである。この際、ルート（文書などを人から人へ流す順路）はワークフローの指示書に言葉で書く。なぜなら、システムに教えられなくても、普通は自分の上司が誰なのかはわかっているはずだからである。
さらに、前記した指定を簡単におこなえるように、システム側が過去の履歴を参照し、「アクション」の種別に応じて宛先や依頼アクションを提示するとともに、提示した宛先や依頼アクションを次の宛先（担当者）およびアクションのデフォルトにする。例えば、現担当者が、アクションとして、「発行」を選択したとする。そうすると、過去に「発行」を実行した履歴を調べ、そのときに宛先として指定した人および依頼アクションのうち、最新のものから順に選択肢を提示する。これにより、利用者（現担当者）は選ぶだけで指定が終了する。最初は履歴がないのでうまくいかないが、ある程度処理がたまってくると、デフォルトの状態で処理が可能になってくる。
なお、本発明のワークフローシステムでは組織ＤＢを持たないので、そのための保守作業が不要であるし、厳密なルート設定を必要としないので、例外的な状況にも柔軟に対応でき、プロセス定義の保守もほとんどいらない。
【０００７】
以下、図面により本発明の実施の形態を詳細に説明する。
図１は本発明の第１の実施例を示すワークフローシステムの構成ブロック図である。なお、この実施例では、ネットワークに接続された端末装置から複数の利用者が操作することを想定している。
図示したように、この実施例のワークフローシステムは、ワークフローサーバ１と複数の端末装置２から構成され、ワークフローサーバ１は、ネットワークを介した利用者の指示により起動されてプロセス定義を作成するプロセス定義部３、そのプロセス定義を元に最初の指示書を作成する初期指示書作成部４、作成されたその指示書を端末装置２に表示させる指示書表示部５、表示された指示書に従って利用者に処理内容を入力させる処理内容入力部６、入力された処理内容に従って次の指示書を作成する次指示書作成部７、およびメールのアドレス帳８などを備えている。入力される処理内容はアクションと宛先で、そのため、前記処理内容入力部６は、アクションを選択・入力させるアクション選択部９、および宛先を入力させる宛先入力部１０を備える。
宛先については宛先候補作成部１１により候補が作成され、利用者はそのなかから選ぶだけで入力が可能になる。なお、この実施例では、請求項１記載のプロセス定義手段、初期指示書作成手段、指示書表示手段、処理内容入力手段、次指示書作成手段、アクション選択手段、および宛先入力手段が、それぞれその順に、プロセス定義部３、初期指示書作成部４、指示書表示部５、処理内容入力部６、次指示書作成部７、アクション選択部９、および宛先入力部１０により実現される。
【０００８】
次に、図１に従って典型的な動作について説明する。なお、端末装置２は、ＷＷＷブラウザなどが動作するＷＷＷクライアント装置とする。一方、ワークフローサーバ１はＷＷＷサーバであり、その環境で動作するＣＧＩと呼ばれるプログラムを有するものとする。但し、これは一例であり、Ｓｅｒｖｅｌｅｔなどのプログラムが動作するサーバ・クライアントシステム、または専用のサーバ・クライアントシステムであってもよい。
図２に、プロセス定義部３によりネットワークを介して利用者に提示されたプロセス定義の入力画面を示す。この入力画面はＨＴＭＬと呼ばれる文書形式によって容易に作成できるものであり、詳細は省略する。ＷＷＷクライアント装置側で、空欄に文字を書き込み、設定ボタンを押すことによりサーバ側に情報を与えることができる。これはＨＴＭＬ文書におけるＦＯＲＭタグによって達成される仕組みであり、ＷＷＷにおいて広く用いられているやりかたである。
この入力画面で、利用者は、プロセスの名前と説明、および処理手順をそれぞれ自然言語で人が解読できる内容で入力する。入力例を図３に示す。このように、自然言語で記述するので（複雑なルート設定などを従来のようにプログラムやフロー図で記述しない）、機械可読になるように気を使う必要もなく、容易にプロセス定義を記述することができる。また、例外的な処理を全て網羅する必要もなく、非常に簡単である。さらに、役職の名前（例えば係長や課長）と実際の人名を結びつけるための組織ＤＢも全く不要である。
利用者が図３に示した設定ボタンを押すと、プロセス定義部３はネットワークを介して入力された文字データを取得し、その文字データを元にプロセス定義を以下の手順で作成する。
ＳＴＥＰ１．１  名前欄の入力データをプロセス定義の名前の値とする。
ＳＴＥＰ１．２  説明欄の入力データをプロセス定義の説明の値とする。
ＳＴＥＰ１．３  処理手順欄の入力データをプロセス定義の処理手順の値とする。
こうして作成されたプロセス定義の例を図４に示す。従来のワークフローシステムでは、この段階で複雑なルート設定や例外処理を記述しなければならなかったが、この実施例では、以上のように自然言語で説明すればよく、非常に簡単である。
プロセス定義部３は作成したプロセス定義をワークフローサーバ１内の２次記憶装置であるハードディスク記憶装置などの記憶域に保管する。
【０００９】
プロセス定義が作成され、利用者（仮に「佐藤一郎」さんとする）がプロセス定義に書かれたプロセスを開始する場合は、まず、端末装置２からプロセス開始の指示を与える。これにより、その指示が初期指示書作成部４に伝わり、初期指示書作成部４が起動され、その初期指示書作成部４が指示書を作成する。指示書とは、現在の（そのときの）作業者に対して何をすべきかを記述した文書である。指示書の例を図５に示す。指示書の作成手順は次のようになる。
ＳＴＥＰ２．１  タイトルとして、プロセス定義の名前を指示書の先頭に出力する。
ＳＴＥＰ２．２  説明として、プロセス定義の説明を指示書に追加する。
ＳＴＥＰ２．３  処理手順として、プロセス定義の処理手順を指示書に追加する。
ＳＴＥＰ２．４  アクションの作成（後述）
ＳＴＥＰ２．５  宛先欄を指示書に追加する。ここは空欄とする。
ＳＴＥＰ２．６  添付文書欄を指示書に作成する。
ＳＴＥＰ２．７  実行ボタンを指示書に追加する。
【００１０】
次に、ＳＴＥＰ２．４のアクションの作成について説明する。
ここでは、アクションテーブルを用いてアクションを指示書に追加する。アクションは、最初に実行すべきアクションである。まず、アクションテーブルとして図６のようなものを事前に用意しておく。アクションテーブルには、アクションが書かれている。図６において、アクション名は、アクションの名前そのもので、アクション番号は単なるアクションのＩＤ（識別番号）である。テーブル中の「状態」には、「初期」と「途中」があり、「初期」は、プロセスの開始時におこなわれるアクションであることを表す。「途中」はプロセスの開始時以外にもおこなわれる。ＳＴＥＰ２．４の詳細は次のようになる。
ＳＴＥＰ２．４．１  アクションテーブルから「状態＝初期」のアクションを見つけ出す。複数ある場合には最初に見つけたものでよい。
ＳＴＥＰ２．４．２  見つけたアクションのアクション名を指示書に追加する。この例では、最初のアクションは「発行」となる。
利用者は、この指示書を読み、特に処理手順の説明を読み、いかなる処理をおこなえばいいかを知ることができる。この例では、自分は発行者であり、必要とするアクションは「発行」で、次にまわす相手は自分の上司である係長であり、係長にお願いすべき事柄は「審査」であることがわかる。通常、自分の上司の名前が誰かは知っているはずであり、係長→鈴木太郎といった対応付けはシステムがおこなわなくても利用者により可能である。よって、利用者が上司の宛先を入力することができる。
従来は、この処理手順は、システムで自動実行されるようにプログラム化されていたので、組織の変更や人事異動があった場合に、組織ＤＢやプログラムを変更しなければならないとか、不慮の病欠の場合の承認者のスキップなど、例外的な処理ができないとか、人間が読むことを想定して書かれていないので、どのように処理されるか、処理している本人も把握できないとかいった問題があったが、この実施例のワークフローシステムではこのような問題が解決される。
指示書が作成されると、指示書表示部５がその指示書を当該利用者の端末装置（ＷＷＷクライアント装置）２へ送り、その端末装置２においてその指示書が表示される。
【００１１】
次に、処理内容入力部６がこのときの実際の処理内容を入力させる。利用者が表示された指示書に書き込む形で処理内容を入力するのである。表示された指示書記載の処理内容のままでよければ、特に変える必要はない。変えたい場合には、欄横の▼ボタンを押す（図５参照）。例えばアクション欄の▼ボタンが押された場合は次のようになる。
まず、処理内容入力部６が、図６に示したアクションテーブルのアクションをそのまま全てアクションの候補・選択肢として、図７に示したような小さな画面をポップアップし、利用者にポインティングデバイスなどによりそのうちのひとつを選択させる。これは次のような手順になる。
ＳＴＥＰ３  利用者がアクション欄（図５参照）のボタンを押すことによりネットワークを介してアクション選択部９が起動する。
ＳＴＥＰ３．１  アクション選択部９はアクションテーブルから全てのアクション名を読み込む。
ＳＴＥＰ３．２  アクション選択部９はそのアクション名を端末装置２へ送り、その端末装置２において順番に選択肢として表示させる。
宛先欄の▼ボタンが押された場合には、宛先入力部１０により宛先が入力される。これは次のようになる。
ＳＴＥＰ４．１  当該個人（このときの作業者）のメールのアドレス帳や人事ＤＢなどから組織の人間の情報を取得する。
ＳＴＥＰ４．２  ネットワークを介して当該端末装置２へ送り、その端末装置２において順番に選択肢として表示させる。
このようにして、小さなポップアップ画面を利用者に提示し、選択させる。この画面を図８に示す。この例では、宛先をフルネームで表示したが、メールのアドレス帳などの場合にはメールアドレスだけが記載されている場合がある。この場合、別の人事ＤＢを用いて名前に変更してもよいし、また、メールアドレスのまま表示してもよい（次の担当者が自分宛ての指示書を選択できればよいので、どう表示するかは本質的ではない）。
さらに、添付文書欄には、このプロセスの対象物件に係る文書やファイルを添付することができる。これにより、購入すべき商品の仕様やカタログ、見積書などを添付し、ワークフローの処理をおこなうことができる。
【００１２】
利用者は、このようにして処理内容を入力した後、実行ボタンを押す。そうすると、次指示書作成部７が、その処理内容を元にそこで示された宛先に出す新たな指示書を作成する。作成された指示書の例を図９に示す。これは次の手順で作成される。
ＳＴＥＰ５．１  説明欄および処理手順欄に、初期指示書作成のときと同様にプロセス定義からそのまま引き継いで書く。
ＳＴＥＰ５．２  アクション欄は空にする。
ＳＴＥＰ５．３  宛先も空にする。
ＳＴＥＰ５．４  添付文書に、前担当者が入力した添付文書をそのまま引き継ぐ。
ＳＴＥＰ５．５  指示書内に履歴として、このとき入力された前工程（ここでは初期指示書）の処理内容のすべてまたは一部、このときの利用者を示す利用者情報、およびこのときの時刻を追加記録する（利用者はこの指示書内の履歴を見ることにより、過去の全ての処理内容を知ることができる）。
このように、次指示書作成部７により、次の担当者向けの指示書が作成され、これは、システムの２次記憶域（例えばハードディスク記憶装置の記憶域）に保管される。このとき、電子メールなどにより、次担当者に新しい指示書ができたことを伝えてもよい。この場合、次担当者は即座に、自分の担当の指示書の処理をおこなうことができる。電子メールなどにより連絡していない場合は、次担当者が定期的にシステムにアクセスすることにより、自分宛ての指示書を見つけることができる。
【００１３】
さて、次の担当者である山田与助（係長）は、自分宛ての指示書を見つけると、指示書表示部５を介してその指示書を自端末装置２に送らせ、表示させる。そして、これを見て、ワークフロー上の次の処理をおこなう。発行時の処理と同じように、指示書に記載されている処理手順説明などを見て適切な処理をおこなうことができるのである。
続いて、宛先やこの工程のアクションについては▼ボタンを押して、前記した「発行」の場合と同様に処理する。
こうして、次々に次指示書作成→処理内容入力→次指示書作成という繰り返しがおこなわれ、ワークフローが実行される。
このように、第１の実施例によれば、プロセス定義で記述した自然言語文の処理手順をそのまま指示書内に表示することができ、したがって、人間向けの説明と情報処理装置向けの説明（ルート設定など）の２種類を記述する必要がなく、人間向けの説明だけ記述すればよい。また、作業者（担当者）は、処理手順を見ながら適切な処理をおこなうことができ、これにより、例外時の柔軟な対応が可能である。処理手順に複雑な条件があっても、複雑なプログラミングの必要がなく、プロセスの定義者から実際の担当者に手順を伝えることができる。また、処理の履歴が指示書内に記録されるので、現在の担当者は、今処理している指示書だけを見て、それまでの処理の概要を容易に知ることができる。
【００１４】
次に、本発明の第２の実施例について説明する。なお、この実施例の構成ブロック図は図１に示した第１の実施例と同じであるので、説明を省略する。また、プロセス定義部３の機能も第１の実施例と同じであるので、説明を省略し、プロセス定義が作成されたあとから説明する。
そういうわけで、そのプロセス定義の作成後だが、まず、利用者（仮に「佐藤一郎」さんとする）が端末装置２においてプロセス定義に書かれたプロセスを開始する指示を入力する。これにより、端末装置２はプロセス開始の指示をワークフローサーバ１内の初期指示書作成部４に伝え、初期指示書作成部４が起動され、その初期指示書作成部４が指示書を作成する。指示書は、そのときそのときの作業者に対して何をすべきかを記述した文書である。指示書の例を図１０に示す。
指示書の作成手順は次のようになる。
ＳＴＥＰ２．１  タイトルとして、プロセス定義の名前を指示書の先頭に出力する。
ＳＴＥＰ２．２  説明として、プロセス定義の説明を指示書に追加する。
ＳＴＥＰ２．３  処理手順として、プロセス定義の処理手順を指示書に追加する。
ＳＴＥＰ２．４  アクションを作成する（詳細は第１の実施例と同じである）。
ＳＴＥＰ２．５  宛先欄を指示書に追加する。ここは空欄とする。
ＳＴＥＰ２．６  コメント欄を指示書に追加する。ここも空欄とする。
ＳＴＥＰ２．７  添付文書欄を指示書に追加する。
ＳＴＥＰ２．８  実行ボタンを指示書に追加する。
こうして、指示書が作成されると、次に、指示書表示部５がその指示書を利用者の端末装置２へ送り、指示書が表示される。
【００１５】
次に、利用者が処理内容入力部６によりこのときの実際の処理内容を入力する。利用者は表示された指示書に書き込む形で処理内容を入力するのである。情報がそのままでよければ、特に変える必要はない。変えたい場合には、欄横の▼ボタンを押す。例えばアクション欄の▼ボタンが押された場合は、図６に示したアクションテーブルのアクションをそのまま全てのアクションの候補・選択肢として小さな画面図（図７参照）をポップアップし、利用者はポインティングデバイスなどによりそのうちのひとつを選択する。これは次のような手順になる。
ＳＴＥＰ３  利用者がアクション欄のボタンを押すことによりアクション選択部９が起動する。
ＳＴＥＰ３．１  アクションテーブルから全てのアクション名を読み込む。
ＳＴＥＰ３．２  順番に選択肢として表示する。
宛先欄の▼ボタンが押された場合には、宛先入力部１０により、宛先が入力される。これは次のようになる。
ＳＴＥＰ４．１  当該個人（このときの作業者）のメールのアドレス帳や人事ＤＢなどから組織の人間の情報を取得する。
ＳＴＥＰ４．２  順番に選択肢として表示する。
このようにして、小さなポップアップ画面を利用者に提示し、選択させる。この画面は図８のようになる。なお、この例では宛先をフルネームで表示したが、メールのアドレス帳などの場合にはメールアドレスだけが記載されている場合があるので、別の人事ＤＢを用いて名前に変更してもよいし、また、メールアドレスのまま表示してもよい。
コメント欄には、次担当者（宛先）に伝えたい任意のことがらを自然言語で記述する。これを使って、ここに例外的な対応を依頼することができる。例えば、コメントに「１２月３０日までに処理が終わらないと、希望の商品は絶版になります。また、課長は１２月２９日まで出張中です。」と書くことにより、次担当者の係長に対し課長をスキップするなどの処理を示唆できる。
さらに、添付ファイル欄には、このプロセスの対象物件に係る文書やファイルを添付することができる。これにより、購入すべき商品の仕様やカタログ、見積書などを添付し、ワークフローの処理をおこなうことができる。
【００１６】
利用者は、このように処理内容を入力した後、実行ボタンを押す。これにより、次指示書作成部７が新たな指示書を作成する。作成された指示書の例を図１１に示す。これは次の手順で作成される。
ＳＴＥＰ５．１  初期指示書作成のときと同様に、説明欄および処理手順欄にプロセス定義からそのまま引き継いで書く。
ＳＴＥＰ５．２  直前のコメントに、前担当者（佐藤一郎）の入力した処理内容を書く。
ＳＴＥＰ５．３  アクション欄は空にする。
ＳＴＥＰ５．４  宛先も空にする。
ＳＴＥＰ５．５  コメント欄も空にする。
ＳＴＥＰ５．６  添付文書に、前担当者が入力した添付文書をそのまま引き継ぐ。
ＳＴＥＰ５．７  指示書内に履歴としてそのとき入力された前回の処理内容を追加する。利用者はこの指示書内の履歴を見ることにより、過去の全ての処理内容を知ることができる。こうして、次指示書作成部７により、次の担当者向けの指示書が作成され、これは２次記憶域に保管される。
このとき、電子メールなどにより次担当者に新しい指示書ができたことを伝えてもよい。この場合、次担当者は即座に、自分の担当の指示書の処理をおこなうことができる。電子メールなどにより連絡していない場合は、次担当者が定期的にシステムにアクセスすることにより、自分宛ての指示書を見つけることができる。そして、次の担当者である山田与助（係長）は、自分宛ての指示書を見つけると、指示書表示部５により自端末装置２へ送らせ、表示させる。そして、これを見て、ワークフロー上の次の処理をおこなう。この処理は、発行時の処理と同じであるが、この実施例では、処理手順説明だけでなくコメントも見て、適切な処理をおこなうことができる。
こうして、次々に次指示書作成→処理内容入力→次指示書作成という繰り返しがおこなわれ、ワークフローが実行される。
このように、第２の実施例によれば、前担当者からのコメントが指示書中の直前のコメントや履歴に表示されるので、前担当者からの複雑な要求も理解することができ、適切な処理をおこなうことができる。また、プロセス定義時には存在しなかった突発的、例外的な事象に対しても柔軟な対応が可能になる。
【００１７】
次に、本発明の第３の実施例について説明する。
図１２に、この実施例の構成ブロック図を示す。図示したように、この実施例では、図１に示した第１の実施例の構成に対して依頼アクション選択部１２が追加されており、依頼アクション選択部１２内には依頼アクション候補作成部１３を含む。また、処理内容には依頼アクションが含まれる。なお、この実施例では、請求項４記載の依頼アクション選択手段が依頼アクション選択部１２により実現される。図１２において、プロセス定義部３は第１の実施例と動作が同じであるので、以下、プロセス定義が作成されたあとからこの実施例の動作を説明する。
そういうわけで、プロセス定義が作成されたあとだが、利用者（仮に「佐藤一郎」さんとする）が端末装置２においてプロセス定義に書かれたプロセスを開始する指示を入力する。これにより、端末装置２はプロセス開始の指示をワークフローサーバ１内の初期指示書作成部４に伝え、初期指示書作成部４が起動され、その初期指示書作成部４が指示書を作成する。指示書の例を図１３に示す。指示書の作成手順は次のようになる。
ＳＴＥＰ２．１  タイトルとして、プロセス定義の名前を指示書の先頭に出力する。
ＳＴＥＰ２．２  説明として、プロセス定義の説明を指示書に追加する。
ＳＴＥＰ２．３  処理手順として、プロセス定義の処理手順を指示書に追加する。
ＳＴＥＰ２．４  アクションの作成をおこなう（詳細は第１の実施例と同じである）。
ＳＴＥＰ２．５  依頼アクション欄を追加する。ただし空欄にしておく。
ＳＴＥＰ２．６  宛先欄を指示書に追加する。ここは空欄とする。
ＳＴＥＰ２．７  コメント欄を指示書に追加する。ここも空欄とする。
ＳＴＥＰ２．８  添付文書欄を指示書に追加する。
ＳＴＥＰ２．９  実行ボタンを指示書に追加する。
こうして、指示書が作成されると、指示書表示部５がその指示書を利用者の端末装置２へ送り、表示させる。
【００１８】
その後、処理内容入力部６ａにより利用者がそのときの実際の処理内容を入力する。利用者は表示された指示書に書き込む形で処理内容を入力するのである。情報がそのままでよければ、特に変える必要はない。変えたい場合には、欄横の▼ボタンを押す。例えばそのときの実際のアクションを変更するために利用者がアクション欄の▼ボタンを押した場合は次のようになる。
まず、アクションテーブルのアクションをそのまま全てのアクションの候補・選択肢とし、図７に示したような小さな画面をポップアップする。そして、利用者にポインティングデバイスなどによりそのうちのひとつを選択させる。これは次のような手順になる。
ＳＴＥＰ３  利用者がアクション欄のボタンを押すことによりアクション選択部９が起動する。
ＳＴＥＰ３．１  アクションテーブルから全てのアクション名を読み込む。
ＳＴＥＰ３．２  順番に選択肢として表示する。
また、宛先欄の▼ボタンが押された場合には、宛先入力部１０により宛先が入力される。これは次のようになる。
ＳＴＥＰ４．１  当該個人のメールのアドレス帳や人事ＤＢなどから組織の人間の情報を取得する。
ＳＴＥＰ４．２  順番に選択肢として表示する。図８に示したような小さなポップアップ画面を利用者に提示し、選択させるのである。
また、次担当者に依頼するアクションを入力する場合は、利用者が依頼アクション欄の▼ボタンを押し、依頼アクション選択部１２により次担当者に対する依頼アクションを選択するが、そのときは、まず依頼アクション候補作成部１３が依頼アクションの候補を生成する。これは、アクション選択部９と全く同様の処理であり、次のようになる。
ＳＴＥＰ５  利用者が依頼アクション欄のボタンを押すことにより依頼アクション選択部１２が起動される。
ＳＴＥＰ５．１  アクションテーブルから全てのアクション名を読み込む。
ＳＴＥＰ５．２  順番に選択肢として表示する。これにより、利用者は必要に応じて依頼アクションを選択することができる。
コメント欄には、次担当者（宛先）に伝えたい任意のことがらを自然言語で記述する。これを使って、ここに例外的な対応を依頼することができる。例えば、コメントに「１２月３０日までに処理が終わらないと、希望の商品は絶版になります。また課長は１２月２９日まで出張中です。」と書くことで、次担当者の係長に対し、課長をスキップするなどの処理を示唆できる。
さらに、添付ファイル欄には、このプロセスの対象物件と係る文書やファイルを添付することができる。これにより、購入すべき商品の仕様やカタログ、見積書などを添付し、ワークフローの処理をおこなうことができる。
【００１９】
利用者は、このように処理内容を入力した後、実行ボタンを押す。すると、次指示書作成部７が新たな指示書を作成する。作成された指示書の例を図１４に示す。これは次の手順で作成される。
ＳＴＥＰ６．１  説明欄および処理手順欄に、初期指示書作成のときと同様にプロセス定義からそのまま引き継いで書く。
ＳＴＥＰ６．２  直前のコメントに、前担当者（佐藤一郎）の入力した処理内容を書く。
ＳＴＥＰ６．３  アクション欄は、前担当者の入力した依頼アクションを書く。
ＳＴＥＰ６．４  宛先は空にする。
ＳＴＥＰ６．５  依頼アクション欄は空欄とする。
ＳＴＥＰ６．６  コメント欄も空にする。
ＳＴＥＰ６．７  添付文書に、前担当者が入力した添付文書をそのまま引き継ぐ。
ＳＴＥＰ６．８  指示書内に、履歴として前回の処理内容を追加する。利用者はこの指示書内の履歴を見ることにより過去の全ての処理内容を知ることができる。
このように、次指示書作成部７により、次の担当者向けの指示書が作成され、これはこのワークフローシステムの２次記憶域に保管される。このとき、電子メールなどにより次担当者に新しい指示書ができたことを伝えてもよい。この場合、次担当者は即座に自分の担当の指示書の処理をおこなうことができる。なお、電子メールなどにより連絡していない場合は、次担当者が定期的にシステムにアクセスすることにより自分宛ての指示書を見つけることができる。
こうして、次の担当者である山田与助（係長）は、自分宛ての指示書を見つけると、その指示書を指示書表示部５により端末装置２へ送らせ、表示させる。そして、その指示書を見てワークフロー上の次の処理をおこなう。この処理は、発行時の処理と同じである。コメントや処理手順説明を見て、適切な処理をおこなうことができる。また、宛先や依頼アクションを記載するが、それには▼ボタンを押すことにより履歴を用いて候補を作成し、選択させる。
こうして、次々に次指示書作成→処理内容入力→次指示書作成という繰り返しがおこなわれ、ワークフローが実行される。なお、この際は、次指示書の直前のコメントには、直前の指示書のコメント欄のコメントを書く。依頼アクションがなしになった時点でこのワークフローは終了する。
このように、第３の実施例によれば、次の担当者へ依頼する依頼アクションを現在（現時点）の担当者が指定できるので、次の担当者は何が要求されているかを明確に知ることができ、要求された処理（アクション）を簡単な操作で即座におこなうことができる。また、そのアクションがやりたいことと異なる場合には別のアクションを選択することもできる。
【００２０】
図１５は本発明の第４の実施例を示すワークフローシステムの構成ブロック図である。図示したように、この実施例では、第３の実施例の構成に対して、メールのアドレス帳８の代わりに履歴記録部１４および履歴データベース１５を備えている。そして、宛先候補作成部１１は履歴記録部１４により記録された履歴データベース１５を用いて宛先候補を作成する。なお、この実施例では、請求項６記載の履歴記録手段、請求項７記載の宛先候補作成手段がそれぞれ履歴記録部１４および宛先候補作成部１１により実現される。以下、この実施例の動作を第３の実施例と異なる部分についてのみ説明する。
前記したように、第３の実施例では、初期指示書作成において宛先欄を空としたが、この実施例では履歴を用いて宛先を書く。つまり、初期指示書の作成手順は以下のようになる。
ＳＴＥＰ２．１  タイトルとして、プロセス定義の名前を指示書の先頭に出力する。
ＳＴＥＰ２．２  説明として、プロセス定義の説明を指示書に追加する。
ＳＴＥＰ２．３  処理手順として、プロセス定義の処理手順を指示書に追加する。
ＳＴＥＰ２．４  アクションの作成をおこなう。詳細は第１の実施例と同じである。
ＳＴＥＰ２．５  依頼アクション欄を追加する。ただし空欄にしておく。
ＳＴＥＰ２．６  宛先欄を指示書に追加する。履歴から宛先を求めて書く。
ＳＴＥＰ２．７  コメント欄を指示書に追加する。ここも空欄とする。
ＳＴＥＰ２．８  添付文書欄を指示書に追加する。
ＳＴＥＰ２．９  実行ボタンを指示書に追加する。
【００２１】
ＳＴＥＰ２．６において、前記したように宛先は履歴を用いて作成するが、その履歴は過去の処理内容を履歴記録部１４がそのときの利用者を示すユーザー情報（利用者情報）および記録時刻とともに記録したものであり、記録時刻順に並んでいる。図１６に例を示す。
このなかから、発行者である佐藤一郎が過去に「発行」した履歴で使われた「宛先」のうち最新のものを見つける。この例では、時刻１１／１９  ０９：５５：２７のものが見つかり、このときの宛先は鈴木太郎である。これを指示書の宛先とするのである。もし見つからなければ、指示書の宛先欄は空欄となる。履歴自体がまだ何もない場合にも空欄となる。手順としては次のようになる。
ＳＴＥＰ２．６．１  履歴から現担当者が過去に「発行＝（ＳＴＥＰ２．４で求められたアクション）」した履歴で使われた「宛先」のうち最新のものを探す。
ＳＴＥＰ２．６．２  見つかったら、これを宛先とする。
ＳＴＥＰ２．６．３  見つからなかったら、空欄とする。
このようにして作られた指示書の例を図１７に示す。
次に、初期指示書が表示され、宛先欄の▼ボタンが押された場合について説明する。
第３の実施例では、メールのアドレス帳などから宛先の候補を作成したが、この実施例では、履歴から作成する。つまり、次のようになる。
ＳＴＥＰ４．１．１  履歴からそのときの利用者が発行者で、アクションが現在選択されているアクションのものを探し、見つかったアクション（複数の場合あり）を時刻の新しい順にならべ、第１の候補とする。
ＳＴＥＰ４．１．２  履歴の全ての宛先欄に書かれた利用者を集め、第１の候補の中にあるものを除き、時刻の新しい順に並べる。これを第２の候補とする。
ＳＴＥＰ４．１．３  この２つの候補をひとつにして、最終的な宛先の候補ができる。
ＳＴＥＰ４．２  これに「その他」という文字列を追加し、順番に選択肢として表示する。
ＳＴＥＰ４を具体例で説明すると、まずＳＴＥＰ４．１．１では、履歴からそのときの利用者が発行者（佐藤一郎）で、アクションが現在選択されているアクション（発行）のものを探す。この例では、２つ見つかり、そのときの宛先（どちらも鈴木太郎）が、第１の候補となる。次に、ＳＴＥＰ４．１．２において、履歴の全ての宛先欄に書かれた利用者を集め、第１の候補のなかにあるものを除き、時刻の新しい順に並べる。これが第２の候補になる。この例では、「山田与助、小川勝男、田中次郎」となる。そして、ＳＴＥＰ４．１．３ではこの２つの候補をひとつにして最終的な宛先の候補ができる。ＳＴＥＰ４．２ではこれに「その他」を追加し、小さなポップアップ画面を利用者に提示し、選択させる。この画面を図１８に示す。ここで、利用者が「その他」を選択した場合、別のテキスト入力画面が現われ、任意の宛先名を入力することができる。
【００２２】
次に、利用者が処理内容を入力し、実行ボタンを押したときについて説明する。
第３の実施例では、次指示書作成部７により新たな指示書が作成されたが、この実施例ではその前に履歴記憶部１４が処理内容を履歴として記録する。図１９に更新された履歴を示す。このように、２次記憶域上にある履歴データベース１５に処理内容を単純に追加していくだけでよい。
こうして、履歴を更新した後、次指示書作成部７は新たな指示書を作成する。作成された指示書の例を図２０に示す。これはほほ第３の実施例と同様の手順で次のように作成される。
ＳＴＥＰ６．１  説明欄および処理手順欄に、初期指示書作成のときと同様にプロセス定義からそのまま引き継いで書く。
ＳＴＥＰ６．２  直前のコメントに前担当者（佐藤一郎）の入力した処理内容を書く。
ＳＴＥＰ６．３  アクション欄には前担当者の入力した依頼アクションを書く。
ＳＴＥＰ６．４  宛先は履歴を用いて作る。
ＳＴＥＰ６．５  依頼アクション欄は空欄とする。
ＳＴＥＰ６．６  コメント欄も空にする。
ＳＴＥＰ６．７  添付文書欄は前担当者が入力した添付文書をそのまま引き継ぐ。
ＳＴＥＰ６．８  指示書内に履歴として前回の処理内容を追加する。利用者はこの指示書内の履歴を見ることにより過去の全ての処理内容を知ることができる。
なお、前記ＳＴＥＰ６．４はこの実施例における初期指示書作成の場合と全く同じようにおこなわれる。
こうして、次々に次指示書作成→処理内容入力→次指示書作成という繰り返しが行なわれ、ワークフローが実行される。
このように、第４の実施例によれば、履歴が履歴データベースに格納されるので、履歴データベースを見るだけで、全体の処理の進行状況を把握することができるし、履歴を用いて作成した宛先の候補を提示し、そのなかから自動的に選ぶことができるので、ほとんどの場合宛先の選択が不要で、さらに変更が必要なときにも少ない手順で適切な宛先を選択することが可能である。
【００２３】
図２１は本発明の第５の実施例を示すワークフローシステムの構成ブロック図である。この実施例のワークフローシステムは第４の実施例と比べ、依頼アクション候補作成部１３ａが履歴データベース１５を用いる点で異なる。なお、この実施例では、請求項８記載の依頼アクション候補作成手段が依頼アクション候補作成部１３ａにより実現される。以下、第４の実施例と異なる動作をする部分についてのみ説明する。
その異なる部分だが、第４の実施例では、初期指示書作成において、依頼アクション欄は空であったが、この実施例では履歴を用いて書き込む。つまり、以下のようになる。
ＳＴＥＰ２．１  タイトルとして、プロセス定義の名前を指示書の先頭に出力する。
ＳＴＥＰ２．２  説明として、プロセス定義の説明を指示書に追加する。
ＳＴＥＰ２．３  処理手順として、プロセス定義の処理手順を指示書に追加する。
ＳＴＥＰ２．４  アクションの作成をおこなう。詳細は第１の実施例と同じである。
ＳＴＥＰ２．５  依頼アクション欄を追加する。履歴のなかからデフォルトの依頼アクションを求めて書く。
ＳＴＥＰ２．６  宛先欄を指示書に追加する。履歴のなから宛先を求めて書く。
ＳＴＥＰ２．７  コメント欄を指示書に追加する。ここは空欄とする。
ＳＴＥＰ２．８  添付文書欄を指示書に追加する。
ＳＴＥＰ２．９  実行ボタンを指示書に追加する。
また、前記ＳＴＥＰ２．５の詳細処理手順は次のようになる。
ＳＴＥＰ２．５．１  履歴のなかからこのときの利用者が発行者でアクションが現在選択されているアクションのものを探す。
ＳＴＥＰ２．５．２  ひとつだけならそれを、複数見つかれば時刻の一番新しい依頼アクションをデフォルトの依頼アクションとする。
ＳＴＥＰ２．５．３  ひとつも見つからなければ、デフォルトの依頼アクションは空とする。
この手順によって、履歴のなかから時刻１１／１９  ０９：５５：２７のものが見つかり、デフォルトの依頼アクションは審査になる。よって、指示書の依頼アクションは「審査」となる。このようにして作られた指示書の例を図２２に示す。
【００２４】
次に、依頼アクション欄の▼ボタンが押された場合について説明する。
このとき、第４の実施例では、アクションテーブルを用いて依頼アクションを作成したが、この実施例では、履歴を用いて作成する。つまり、次のようになる。
まず、依頼アクション候補作成部１３ａが依頼アクションの候補を生成するに当たり、履歴のなかから、利用者が発行者（佐藤一郎）でアクションが現在選択されているアクション（発行）のものを探す。この例では、２つ見つかり、そのときの依頼アクション（どちらも審査）が、第１の候補となる。複数あれば、これを時刻の新しい順に並べる。次に、アクションテーブルのアクションのうち第１の候補にあるものを除き、任意の順に並べる。これを第２の候補とする。この２つの候補をひとつにして最終的な依頼アクションの候補ができる。これを小さなポップアップ画面で利用者に提示し、選択させる。処理手順は次のようになる。
ＳＴＥＰ５  利用者が依頼アクション欄のボタンを押すことで依頼アクション選択部１２が起動する。
ＳＴＥＰ５．１  履歴のなかから、利用者が発行者でアクションが現在選択されているアクションのものを探す。
ＳＴＥＰ５．２  複数見つかれば時刻の順に並べ、第１の候補とする。
ＳＴＥＰ５．３  アクションテーブルのアクションのうち第１の候補に含まれないものを第２の候補とする。
ＳＴＥＰ５．４  第１の候補と第２の候補を合わせてひとつにし、依頼アクションの候補とする。
ＳＴＥＰ５．５  順番に選択肢として表示する。
こうしてできた依頼アクションの選択画面を図２３に示す。これにより、利用者は必要に応じて依頼アクションを選択しなおすことができる。
【００２５】
図２４は次指示書作成部７によって作られた指示書の一例である。これはほほ第３の実施例と同様の手順で作成されるが、以下においてＳＴＥＰ６．５のみが異なる。つまり、次のようになる。
ＳＴＥＰ６．１  説明欄および処理手順欄に、初期指示書作成のときと同様にプロセス定義からそのまま引き継いで書く。
ＳＴＥＰ６．２  直前のコメントに、前担当者（佐藤一郎）の入力した処理内容を書く。
ＳＴＥＰ６．３  アクション欄は前担当者の入力した依頼アクションを書く。
ＳＴＥＰ６．４  宛先は履歴を用いて作る。
ＳＴＥＰ６．５  依頼アクション欄も履歴を用いて作る。
ＳＴＥＰ６．６  コメント欄は空にする。
ＳＴＥＰ６．７  添付文書欄は前担当者が入力した添付文書をそのまま引き継ぐ。
ＳＴＥＰ６．８  指示書内に履歴として前回の処理内容を追加する。利用者はこの指示書内の履歴を見ることにより過去の全ての処理内容を知ることができる。
前記ＳＴＥＰ６．５の動作はこの実施例の初期指示書作成の場合と全く同じである。
以下、第４の実施例の場合と同様に、次々に次指示書作成→処理内容入力→次指示書作成という繰り返しがおこなわれ、ワークフローが実行される。
このように、第５の実施例によれば、履歴を用いて作成した依頼アクションの候補を探し、そのなかから自動的に選ぶことができるので、ほとんどの場合、依頼アクションの選択が不要で、さらに変更が必要なときにも少ない手順で適切な依頼アクションを選択することが可能になる。
【００２６】
図２５は本発明の各実施例のワークフローをハードウェアとソフトウェアから成る情報処理装置により実現する構成図である。図示したような構成で、前記した各実施例のワークフローを実行させるようにプログラミングされたワークフロープログラムをあらかじめＣＤ−ＲＯＭ２５など着脱可能な記録媒体に書き込んでおき、このＣＤ−ＲＯＭ２５をＣＤ−ＲＯＭドライブ２４のような媒体駆動装置を搭載した情報処理装置に装着して、そのワークフロープログラムをメモリ２２またはハードディスク２３のような記憶装置に格納し（図２５はハードディスク２３に格納する例）、そのプログラムに従ってＣＰＵ２１がワークフローを実行する。
この場合、記録媒体から読み出されたプログラムが前記各実施例に示した本発明のワークフローの特徴を実現することになり、そのプログラムおよびそのプログラムを記録した記録媒体も本発明を構成することになる。なお、記録媒体としては半導体媒体（例えば、ＲＯＭや不揮発性メモリカードなど）、光媒体（例えばＤＶＤ、ＭＯ、ＭＤ、ＣＤ−Ｒなど）、磁気媒体（例えば磁気テープやフレキシブルディスクなど）のいずれであってもよい。
なお、本発明の構成としては、ロードしたプログラムを実行することにより前記した各実施例のワークフローを実現する構成だけでなく、そのプログラムに従ってオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部をおこない、その処理によって前記したワークフローを実現する構成も含まれる。
また、前記した各実施例のワークフローを実現するプログラムが機能拡張ボードや機能拡張ユニットに備わるメモリにロードされ、そのプログラムに従ってその機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部をおこない、その処理により前記した各実施例のワークフローを実現する場合も含まれる。
さらに、前記したプログラムをサーバコンピュータの磁気ディスクなどの記憶装置に格納しておき、通信網で接続された利用者のパーソナルコンピュータなど情報処理装置へダウンロードの形式で頒布する場合、このサーバコンピュータの記憶装置も本発明のプログラムを記憶した記録媒体として含まれる。
【００２７】
【発明の効果】
以上説明したように、本発明によれば、請求項１記載の発明では、プロセス定義をおこない、そのプロセス定義に基づいて指示書を作成し、その指示書を画面上に表示し、表示された指示書を用いて処理内容入力手段により入力された処理内容に応じて次の指示書を作成する際、その処理内容のアクションおよび宛先については、とりうるアクションの候補からアクションを選択させ、とりうる宛先の候補から宛先を選択させるか新規に宛先を入力させることができるので、組織ＤＢの設定やルート設定をまったく必要とせず、利用者の負担を軽くすることができる。
また、請求項２記載の発明では、請求項１記載の発明において、プロセス定義に自然言語で書かれた処理手順説明を含み、その処理手順説明が指示書内に記載されるので、人間向けの説明と情報処理装置向けの説明の２種類を記述する必要がないし、作業者（担当者）は、その処理手順を見ながら適切な処理をおこなうことができ、これにより、例外時の柔軟な対応が可能になる。また、処理手順に複雑な条件があっても、複雑なプログラミングの必要がなく、プロセスの定義者から実際の担当者に手順を伝えることができる。
また、請求項３記載の発明では、請求項１または請求項２記載の発明において、処理内容としてコメントを含み、入力されたコメントが次指示書内に記載されるので、前担当者からの複雑な要求も理解することができ、したがって、適切な処理をおこなうことができるし、プロセス定義時には存在しなかった突発的、例外的な事象に対しても柔軟な対応が可能になる。
また、請求項４記載の発明では、請求項１、請求項２、または請求項３記載の発明において、処理内容として依頼アクションを含み、とりうる依頼アクションの候補から依頼アクションを選択させ、選択された依頼アクションを次指示書内に記載することができるので、次の担当者は何が要求されているかを明確に知ることができ、要求された処理（アクション）を簡単な操作で即座におこなうことができる。
【００２８】
また、請求項５記載の発明では、請求項１乃至請求項４のいずれか１項に記載の発明において、入力された処理内容のすべてまたは一部とともに、その処理内容を入力した利用者を示す利用者情報とそのときの時刻が指示書内に履歴として記録されるので、現在の担当者は、今処理している指示書だけを見て、それまでの処理の概要を容易に知ることができる。
また、請求項６記載の発明では、請求項１乃至請求項５のいずれか１項に記載の発明において、入力された処理内容のすべてまたは一部、処理している利用者を示す利用者情報、およびそのときの時刻を指示書とは別の履歴記録手段に履歴として記録することができるので、履歴データベースを見るだけで、全体の処理の進行状況を把握することができる。
また、請求項７記載の発明では、請求項６記載の発明において、とりうる宛先の候補を記録された履歴を用いて作成することができるので、その宛先候補のなかから宛先を自動的に選ぶことができ、そのほとんどの場合、宛先の選択が不要であり、さらに、変更が必要なときにも少ない手順で適切な宛先を選択することができる。
また、請求項８記載の発明では、請求項６または請求項７記載の発明において、とりうる依頼アクションの候補を記録された履歴を用いて作成することができるので、作成した依頼アクションの候補のなかから自動的に依頼アクションを選ぶことができ、ほとんどの場合、依頼アクションの選択が不要であり、さらに、変更が必要なときにも少ない手順で適切な依頼アクションを選択することができる。
また、請求項９記載の発明では、請求項１乃至請求項８のいずれか１項に記載のワークフローシステムによったワークフローを実行させるようにプログラミングされているプログラムを情報処理装置上で実行させることができるので、情報処理装置を用いて請求項１乃至請求項８のいずれか１項に記載の発明の効果を得ることができる。
また、請求項１０記載の発明では、請求項９記載のプログラムを着脱可能な記憶媒体に記憶することができるので、その記憶媒体をこれまで請求項１乃至請求項８のいずれか１項に記載の発明によったワークフローをおこなえなかったパーソナルコンピュータなど情報処理装置に装着することにより、そのような情報処理装置においても請求項１乃至請求項８のいずれか１項に記載の発明の効果を得ることができる。
【図面の簡単な説明】
【図１】本発明の第１の実施例を示すワークフローシステムの構成ブロック図である。
【図２】本発明の第１の実施例を示すワークフローシステム要部の画面図である。
【図３】本発明の第１の実施例を示すワークフローシステム要部の他の画面図である。
【図４】本発明の第１の実施例を示すワークフローシステム要部の説明図である。
【図５】本発明の第１の実施例を示すワークフローシステム要部の他の説明図である。
【図６】本発明の第１の実施例を示すワークフローシステム要部のデータ構成図である。
【図７】本発明の第１の実施例を示すワークフローシステム要部の他の画面図である。
【図８】本発明の第１の実施例を示すワークフローシステム要部の他の画面図である。
【図９】本発明の第１の実施例を示すワークフローシステム要部の他の説明図である。
【図１０】本発明の第２の実施例を示すワークフローシステム要部の説明図である。
【図１１】本発明の第２の実施例を示すワークフローシステム要部の他の説明図である。
【図１２】本発明の第３の実施例を示すワークフローシステムの構成ブロック図である。
【図１３】本発明の第３の実施例を示すワークフローシステム要部の説明図である。
【図１４】本発明の第３の実施例を示すワークフローシステム要部の他の説明図である。
【図１５】本発明の第４の実施例を示すワークフローシステムの構成ブロック図である。
【図１６】本発明の第４の実施例を示すワークフローシステム要部のデータ構成図である。
【図１７】本発明の第４の実施例を示すワークフローシステム要部の説明図である。
【図１８】本発明の第４の実施例を示すワークフローシステム要部の画面図である。
【図１９】本発明の第４の実施例を示すワークフローシステム要部の他のデータ構成図である。
【図２０】本発明の第４の実施例を示すワークフローシステム要部の他の説明図である。
【図２１】本発明の第５の実施例を示すワークフローシステムの構成ブロック図である。
【図２２】本発明の第５の実施例を示すワークフローシステム要部の説明図である。
【図２３】本発明の第５の実施例を示すワークフローシステム要部の画面図である。
【図２４】本発明の第５の実施例を示すワークフローシステム要部の他の説明図である。
【図２５】本発明の各実施例のワークフローシステムを示すハードウェアおよびソフトウェアの構成図である。
【符号の説明】
１  ワークフローサーバ、２  端末装置、３  プロセス定義部、４  初期指示書作成部、５  指示書表示部、６  処理内容入力部、７  次指示書作成部、８  アドレス帳、９  アクション選択部、１０  宛先入力部、１１  宛先候補作成部、１２  依頼アクション選択部、１３  依頼アクション候補選択部、１４  履歴記録部、１５  履歴データベース
【図１】
2004334379.tif 000003
【図２】
2004334379.tif 000004
【図３】
2004334379.tif 000005
【図４】
2004334379.tif 000006
【図５】
2004334379.tif 000007
【図６】
2004334379.tif 000008
【図７】
2004334379.tif 000009
【図８】
2004334379.tif 000010
【図９】
2004334379.tif 000011
【図１０】
2004334379.tif 000012
【図１１】
2004334379.tif 000013
【図１２】
2004334379.tif 000014
【図１３】
2004334379.tif 000015
【図１４】
2004334379.tif 000016
【図１５】
2004334379.tif 000017
【図１６】
2004334379.tif 000018
【図１７】
2004334379.tif 000019
【図１８】
2004334379.tif 000020
【図１９】
2004334379.tif 000021
【図２０】
2004334379.tif 000022
【図２１】
2004334379.tif 000023
【図２２】
2004334379.tif 000024
【図２３】
2004334379.tif 000025
【図２４】
2004334379.tif 000026
【図２５】
2004334379.tif 000027