ワークフローシステム、制御方法およびプログラム。
【課題】伝票毎に一括承認時のルールを登録し、各伝票の承認時に一括承認が可能であるか、個別承認が必要であるかを判断することにより、柔軟な一括承認の処理制御を行うとともに、個別承認が必要な伝票に対しては、確実に処理者に承認を促すことを可能にするワークフローシステムを提供する。
【解決手段】ユーザは各業務（伝票）毎に一括承認のルールを予め設定登録しておく。
承認者が業務の承認処理をする時に一括承認を行いたい業務を選択して、一括承認が可能な業務であるかどうかを、前記予め登録してあるルールに則して判定する。判定の結果、当該ルールに合致して一括承認が可能である業務である場合には、選択した業務の一括承認処理を実行する。
当該ルールに合致していない、つまり一括承認の対象ではない業務がある場合には、個別で承認画面を開き、承認者に対して個別承認を促す。
【解決手段】ユーザは各業務（伝票）毎に一括承認のルールを予め設定登録しておく。
承認者が業務の承認処理をする時に一括承認を行いたい業務を選択して、一括承認が可能な業務であるかどうかを、前記予め登録してあるルールに則して判定する。判定の結果、当該ルールに合致して一括承認が可能である業務である場合には、選択した業務の一括承認処理を実行する。
当該ルールに合致していない、つまり一括承認の対象ではない業務がある場合には、個別で承認画面を開き、承認者に対して個別承認を促す。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の処理待ち案件を一括で承認するワークフローシステムに関するものである。
【背景技術】
【０００２】
従来、ワークフローシステムにおいては、予め定められた手順に従って、業務の流れの制御を自動化し、業務を行う作業者を支援するシステムとして構成される。
【０００３】
本発明では各種申請書、起案書、伝票、申告書、出勤簿などを業務と言い、業務を起案申請したものを案件と言い、まだ処理されていない（＝承認されていない）案件を処理待ち案件と言う。
【０００４】
近年、ワークフローシステムの一機能として、承認者に処理待ち案件の承認依頼が複数存在する場合、承認者の手間を軽減する為に個別に処理待ち案件を開くことなく纏めて一括で承認することを可能にしている。（本明細書において、この処理を案件の『一括承認』と呼び、また、案件を一つづつ個別に処理することを『個別承認』と呼ぶこととする。）
【０００５】
例えば、ある部署の複数のユーザが各々購入申請書を起案申請した場合、予め定められた手順に従って上長である承認者へ承認依頼が順次届くことになるが、場合によっては同種の承認依頼が大量に発生する為、個別に処理待ち案件を開いて申請内容を確認していては承認者の負担が増し、作業を円滑に進めることが困難になる。その為、一括承認対象として複数の処理待ち案件を同時に選択して承認処理を行うことができる機能が提供されている。
【０００６】
本発明と技術分野の類似する特許文献１として、承認者へ同時に大量に承認依頼が発生し、業務が停滞することを解消するための特開２００２−１３２７５９号公報がある。ここでは、承認対象の文書データに認証情報を付加して承認後の文書データを生成し、認証情報が付加された複数の文書データを合成した一括承認用データを表示した後にその一括承認用データ全体に対する認証情報を付加するので、複数案件の電子文書の一括した閲覧及び承認を行うことが可能となる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００２−１３２７５９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上述した従来のワークフローシステムにおける一括承認機能であるが、現行の機能では、一括承認対象として選択された処理待ち案件の場合でも、案件内の業務項目の状態によっては一括承認対象外とし、個別承認対象に切り替えるといった業務要件があった場合に柔軟に対応することができない。
【０００９】
例えば、ある部署の複数のユーザが各々購入申請書を起案申請した案件に対して、上長である承認者が、一括承認対象として同時に選択して承認処理を行った場合、購入金額の総額が１００，０００円未満の案件の場合には承認者の指示通りに一括承認として処理するが、１００，０００円以上の案件の場合には一括承認対象外として個別承認対象とする、といった業務要件には現行の機能では対応できない。
【００１０】
上記特許文献１の特開２００２−１３２７５９号公報では、一括承認対象の処理待ち案件を一括閲覧表示して、承認者が内容を確認の上で承認処理を行うことを対象としている。このため、本来の一括承認処理の目的である、わざわざ個別に内容を表示確認する必要のないような複数の処理待ち案件に対して一括で承認処理を行えるということが不可能である。
【００１１】
本発明の目的は、各業務を承認する際に、一括承認が可能であるか、個別承認が必要であるかを適切に判断して、一括承認と個別承認とを各業務により適切に実行させることで、処理者が各業務の承認を簡単に行うことを可能にする仕組みを提供することである。
【課題を解決するための手段】
【００１２】
ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールを記憶するサーバとがネットワークを介して接続しているワークフローシステムであって、前記ユーザの申請により起票された伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報を記憶する記憶手段と、前記記憶手段により記憶された前記伝票のうち、未処理の伝票を抽出する抽出手段と、前記抽出手段により抽出された前記未処理の伝票を表示する表示手段と、前記表示手段により表示された前記未処理の伝票のうち、一括承認する対象の伝票として複数の伝票をユーザに選択させる選択手段と、前記選択手段により一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定する判定手段と、前記判定手段により一括承認が可能であると判定された伝票に対して、前記伝票毎に承認画面を表示することなく一括承認処理を行う一括承認手段と、前記判定手段により一括承認が可能ではないと判定された伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行う個別承認手段とを備えることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、各業務を承認する際に、一括承認が可能であるか、個別承認が必要であるかを適切に判断して、一括承認と個別承認とを各業務により適切に実行させることで、処理者が各業務の承認を簡単に行うことを可能にする。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態におけるワークフローシステムの構成の一例である。
【図２】本発明の実施形態における各種端末のハードウエア構成である。
【図３】一括承認ルールの編集画面の一例である。
【図３Ｂ】一括承認ルール編集時のフローチャートである。
【図４】ワークフローの第一例である。
【図５】ワークフローの第二例である。
【図６】ワークフローにおける一括承認時の処理イメージである。
【図７】ＷＥＢ画面の一例である。
【図８】処理待ち案件一覧画面の一例である。
【図９】起案申請画面の一例である。
【図１０】処理待ち案件画面の一例である。
【図１１】処理待ち案件一覧画面表示時のフローチャートである。
【図１２】一括承認時のフローチャートである。
【図１３】一括承認ルールの登録形式の一例である。
【図１４】業務設計データと案件データのデータ構造の一例である。
【図１５】連続承認時のフローチャートである。
【発明を実施するための形態】
【００１５】
（第一の実施例）
以下、図面を参照して、本発明の実施形態を詳細に説明する。
図１は、本発明の実施形態におけるワークフローシステムの構成を示す図である。
【００１６】
図１において、ワークフローシステムは少なくとも１つのワークフローサーバ（以下、ＷＦサーバー）１０１とワークフロークライアント１０２がネットワークを介して接続されている。本実施例においては、ワークフロークライアント１０２は複数台で構成されている。
【００１７】
ユーザは、たとえばウェブブラウザやクライアントソフトウェアなどを利用して、ワークフロークライアント１０２から、ワークフローサーバ１０１に対して、ワークフロー進行の要求などを行う。
【００１８】
ワークフローサーバ１０１は、ワークフロークライアント１０２からの要求に応じた処理、案件の管理をおこない、必要があればワークフロークライアント１０２に対して結果などを送信する。ワークフローサーバ１０１とワークフロークライアント１０２の間の通信は、通常のＨＴＴＰのリクエストでもよいし、ＳＯＡＰなどを利用したウェブサービスのリクエストでもよい。
図２は、本発明の実施形態における各種端末のハードウエア構成を示す図である。
【００１９】
図２において、ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、各サーバあるいは各クライアントの後述する各種機能を実現するためのプログラムが記憶されている。
ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。
【００２０】
入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、特に、サーバやクライアント等の端末では、キーボード、マウス等のポインティングデバイスが挙げられる。
【００２１】
外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。加えて、各サーバあるいは各クライアントの各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ２１１としては、ハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。
通信Ｉ／Ｆコントローラ２０８は、ネットワーク２１３を介して外部機器との通信制御処理を実行する。
【００２２】
本発明を実現するためのプログラム２１２は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。
【００２３】
図３は、本発明の実施形態におけるワークフローシステムにおいて、一括承認時の各種ルールを登録・更新する為の編集画面の一例である。
図３において、一括承認ルールは、比較演算子３０１〜定数３０５までを用いて作成される。
一括承認ルールは、左辺、条件式、右辺の３つの構成要素から成る。
以下、前記一括承認ルールの編集画面（図３）を説明する。
【００２４】
比較演算子３０１は、〜〜前記一括承認ルールの構成要素である条件式を表わし、左辺および右辺を表すの比較を行う為に使用する。比較演算子３０１は、左辺と右辺の一致を意味する「＝」、左辺と右辺の不一致を意味する「！＝」、左辺が右辺に比べ小を意味する「＜」、左辺が右辺に比べ大を意味する「＞」、左辺が右辺以下を意味する「＜＝」、左辺が右辺以上を意味する「＞＝」の５つの選択肢から成る。
【００２５】
判定演算子３０２は、前記一括承認ルールの構成要素である条件式を表わし、左辺がＮＵＬＬか否かを判定する為に使用する〜〜を表す。判定演算子３０２は、左辺がＮＵＬＬであることを意味する「ＩＳ ＮＵＬＬ」、左辺がＮＵＬＬでないことを意味する「ＩＳ ＮＯＴ ＮＵＬＬ」の２つの選択肢から成る。（本明細書では、値自体が存在しない状態をＮＵＬＬと呼ぶこととする）
【００２６】
論理演算子３０３は、〜〜前記一括承認ルールを複数登録する場合に、登録した各ルールを論理積または論理和で組み合わせる為に使用するを表す。論理演算子３０３は、論理積を意味する「＆＆」、論理和を意味する「｜｜」の２つの選択肢から成る。
【００２７】
業務項目３０４は、〜〜前記一括承認ルールの構成要素である左辺を表わし、当該業務内に存在するいづれかの項目を選択する為に使用するを表す。業務項目３０４は、当該業務内の項目選択を意味する「業務項目」の１つの選択肢から成る。
【００２８】
定数３０５は、〜〜前記一括承認ルールの構成要素である右辺を表わし、左辺と比較した具体的な値を設定する為に使用するを表す。定数３０５は、文字列型定数を意味する「文字列」、数値型定数を意味する「数値」、日時型定数を意味する「日時」、真偽値型定数を意味する「真偽値」の４つの選択肢から成る。
テキストエリア３０６は、設定した前記一括承認ルールの表示エリアである。
ＯＫボタン３０７は、設定した前記一括承認ルールを保存する為に使用する。
キャンセルボタン３０８は、設定した前記一括承認ルールを取り消す為に使用する。
【００２９】
業務項目一覧画面３０９は、業務項目３０４を選択した場合に表示される。業務項目一覧画面３０９は、当該業務項目の一覧情報が表示され、任意の１項目が選択可能である。
【００３０】
チェックボックス３１０は、当該業務に対して一括承認許可を制御する為に使用する。チェックボックス３１０にチェックが設定された場合、当該業務に対しては一括承認自体が不可扱いとなる。
【００３１】
業務名３１１は、当該業務の名称を表す。
一括承認ルールの作成手順の一例を図３Ｂのフローチャートと併せて示す。
【００３２】
まず、一括承認ルールの構成要素：左辺が未設定の場合、左辺の設定を行う（図３ＢのＳ３０１）。業務項目３０４より項目ボタンを選択後、テキストエリア３０６を選択すると、業務項目一覧画面３０９が表示される。業務項目は、文字、数値、日付、真偽値、文書、添付など、いずれかの属性から成る。業務項目一覧画面３０９より項目を選択すると、一括承認ルールの構成要素の一つである左辺として設定され、テキストエリア３０６に表示される。（図３の３０６における、「項目名：購入金額」がそれに当たる。）
【００３３】
次に、一括承認ルールの構成要素：条件式が未設定の場合、条件式の設定を行う（図３ＢのＳ３０２）。比較演算子３０１或いは判定演算子３０２より任意の演算子ボタンを選択後、テキストエリア３０６を選択すると、一括承認ルールの構成要素の一つである条件式として設定され、テキストエリア３０６に表示される。（図３の３０６における、「＞＝」がそれに当たる。）
【００３４】
最後に、一括承認ルールの構成要素：右辺が未設定の場合、右辺の設定を行う（図３ＢのＳ３０３）。定数３０５より任意の属性ボタンを選択後、テキストエリア３０６を選択すると入力欄が表示されるので、任意の文字、数値、日時、真偽値を入力すると、一括承認ルールの構成要素の一つである右辺として設定され、テキストエリア３０６に表示される。（図３の３０６における「３００００」がそれに当たる。）
【００３５】
なお、一括承認ルールを複数設定したい場合は、一つ目のルールを設定後、論理演算子３０３より＆＆（＝ＡＮＤ）或いは｜｜（＝ＯＲ）を選択後（図３ＢのＳ３０４）、テキストエリア３０６を選択すると二つ目のルールが設定可能な状態となる（図３の３０６には不図示）。
【００３６】
最後に、一括承認ルールの編集が終わったら、確定処理を行う（図３ＢのＳ３０５、Ｓ３０６）。ＯＫボタン３０７を選択することで、一括承認ルールの編集が完了となり、キャンセルボタン３０８を選択することで、一括承認ルールの編集を取り消す。
一括承認ルールがデータベースにどのようなデータ形式で登録されるかは、後述する図１３で示す。
【００３７】
図１３は、本発明の実施形態におけるワークフローシステムにおいて、一括承認ルールの登録データ形式の一例である。
【００３８】
図１３において、一括承認ルールはＸＭＬ形式でデータベースに登録される。その際、一括承認ルールは業務毎に設定されるものなので、業務設計データに紐づく形で一括承認ルールは登録されている。業務設計データと一括承認ルールの関係性を示すデータ構造については、後述する図１４で示す。
【００３９】
図１４は、本発明の実施形態におけるワークフローシステムにおいて、業務設計データと案件データのデータ構造を示す図である。
【００４０】
図１４において、業務設計データ１４２０は、業務定義１４２１と経路定義１４２２とフォーム定義１４２３と項目定義１４２４を含む。業務定義１４２１は、業務設計データ１４２０を特定するための定義情報を保持する。また、業務定義１４２１は、業務設計の１つを特定するための情報として、業務ＩＤおよび、業務バージョン番号を保持する。また、業務定義１４２１は、業務名と、一括承認ルールを保持する。一括承認ルールは、図１３で先述した通り、ＸＭＬ形式で登録される。
【００４１】
経路定義１４２２は、ワークフローの流れの定義情報を保持する。フォーム定義１４２３は、ワークフローを操作するユーザーが直接操作する画面の定義情報を保持する。項目定義１４２４は、案件データ１４１０が、保持するべきデータの型や長さなどのデータ定義情報を保持する。
【００４２】
案件データ１４１０は、案件親データ１４１１と案件子データ１４１２を含む。案件親データ１４１１は、案件データ１４１０を特定するためのデータ情報を保持する。案件子データ１４１２は、案件データ１４１０の実データを保持する。
次に、図４および図５を用いて本発明の実施形態における一般的なワークフローの例について説明する。
図４は、従来のワークフローの第一例である。
図４においては、備品購入申請書の例として、購入希望申請者が各々起票申請を行う。（工程１）
【００４３】
本発明の実施例において、ワークフローの処理者はワークフロークライアント１０２より起票申請や承認の処理を行うが、ワークフロークライアント１０２では起票申請や承認の指示処理を行っているのみであり、実際には、ワークフローサーバー１０１において各処理が行われる。
【００４４】
申請者が起票申請を行うと、申請者の、上長である課長（工程２）、部長の承認を経て（工程３）主管部門の処理者が処理を行い（工程４）、主管部門長が最終承認を行う（工程５）流れを示している。
【００４５】
この場合、工程２〜工程５については、各案件に対して一つづつ承認作業を行う個別承認或いは一括承認が可能である（一括承認の場合は、別途一括承認ルールが適用され、承認或いは未承認が判定される）。
図５は、従来のワークフローの第二例である。
【００４６】
図５においては、起案書の例として、購入希望者が各々起票申請を行い（工程１）、上長である課長（工程２）、複数の合議者が同時並行に合議投票を行い（工程３）、役員の承認後（工程４）に主管部門長が最終承認を行う（工程５）流れを示している。
【００４７】
ここで言う、合議投票とは〜〜申請者より起案申請された案件に対して、複数の関係者が同意するか否かの意思表明を意味している。
【００４８】
この場合図５に示すワークフローの工程２、工程４、工程５については、個別承認或いは一括承認が可能であるが（一括承認の場合は、別途一括承認ルールが適用され、承認或いは未承認が判定される）、工程３については個別承認及び一括承認は不可能であり、合議投票（賛成、反対）のみが可能である。
【００４９】
図６は、本発明の実施形態におけるワークフローシステムにおいて、ワークフローにおける一括承認時の処理イメージである。先述したように一括承認とは、承認者に処理待ち案件の承認依頼が複数存在する場合、承認者の手間を軽減する為に個別に処理待ち案件を開くことなく纏めて一括で承認する処理方法を言う。
図６においては、一括承認ルール６０１を「購入金額＜３０，０００円」に設定したと仮定する。
【００５０】
一括承認の例６０２の中で、申請者１〜５が備品購入申請書を各々起票申請した場合、次の承認者１（課長）へ申請書（１）〜（５）に対する承認依頼が通知される。図６の実施例において夫々、申請者１「２００００円」、申請者２「３００００円」、申請者３「２５０００円」、申請者４「１００００円」、申請者５「４００００円」の案件を起票している。承認者１（課長）は、申請書（１）〜（５）の内容に目を通し、それぞれ個別に承認を行う。
【００５１】
次の承認者２（部長）は、承認依頼が通知された申請書（１）〜（５）に対して、内容に目を通すことなく一括での承認を行おうとする。その際、申請書（１）〜（５）それぞれに対して、一括承認ルール６０１が適用され一括承認対象とするか否かを判定される。
【００５２】
一括承認ルール６０１の設定内容の場合、申請書（１）については承認処理が行われ、申請書（２）については案件画面が開き個別承認が促される。個別承認後、申請書（３）、（４）については承認処理が行われ、申請書（５）については再び案件画面が開き個別承認が促される、といった流れになる。
【００５３】
図７は、本発明の実施形態におけるワークフローシステムにおいて、後述する処理待ち案件一覧画面（図８）の起動元となるＷＥＢ画面の一例である。
【００５４】
図７においては、ログインユーザ情報７０１で、当該ワークフローシステムにログインしたユーザ情報が表示される。
【００５５】
業務一覧７０２では、当該ワークフローシステムにログイン中のユーザが起案申請可能な業務の一覧が表示される。起案ボタン７０３を選択することで、後述する起案画面（図９）が起動する。
【００５６】
メニューの処理待ち案件一覧リンクボタン７０４はリンク形式（？）であり、このリンクを選択することで、後述する処理待ち案件一覧画面（図８）を起動することが可能である。
【００５７】
図８は、本発明の実施形態におけるワークフローシステムにおいて、先述した図７の７０４にある、「処理待ち案件一覧」ボタンを押下された時に起動するＷＥＢ画面（図７）より起動された処理待ち案件一覧画面の一例である。
【００５８】
図８においては、処理待ち案件一覧画面は、マイクロソフト社の推進するリッチクライアント方式「スマート・クライアント」技術から構成され、サーバとの通信はＸＭＬ ＷＥＢサービスを用いて行われる。
【００５９】
対象ユーザ選択ボタン８０１は、当該ワークフローシステムにログイン中のユーザと、委任関係となる委任元ユーザの情報がドロップダウン形式で表示される（図８の処理待ち案件一覧画面の初期表示時は、ログインユーザが選択されている状態）。
【００６０】
対象ユーザ選択ボタン８０１で別の委任元ユーザを選択後、一覧表示ボタン８０２が選択されると、選択した委任元ユーザに紐づく処理待ち案件一覧データが明細部に表示される。
【００６１】
絞込条件ボタン８０３は、明細部に表示されている処理待ち案件一覧データをある条件に基づいて絞り込む為の条件指定部である。絞込条件ボタン８０３に条件指定後、絞込ボタン８０４を選択すると絞込された結果が明細部に表示される。この絞込機能については、サーバとのＸＭＬ ＷＥＢサービス通信は行われない。あくまで、クライアント内部で保持している処理待ち案件一覧データを、クライアント内部で絞り込む形となる。
元に戻すボタン８０５は、絞込条件ボタン８０３で絞り込んだ結果を取り消すためのボタンである。
リセットボタン８０６は、条件部をクリアする。
【００６２】
明細部８０７は、処理待ち案件一覧データを表示エリアする領域である（図８の処理待ち案件一覧画面の初期表示時は、ログインユーザに紐づく処理待ち案件一覧が表示されている状態）。
【００６３】
明細部８０７の左端に位置するチェックボックスは一括承認対象とする為の入力部である（図８の処理待ち案件一覧画面の初期表示時は、すべてのチェックボックスが未選択状態）。
【００６４】
一括承認対象としたい処理待ち案件のチェックボックスにチェックを入れ、一括承認ボタン８０９を選択することで、個別に処理待ち案件画面を起動することなく一括での承認が行われる。
【００６５】
非チェックボックス８０８にチェックボックスが表示されていない処理待ち案件は、合議投票を要する処理待ち案件の為、チェックボックスが非表示の状態となっている。
【００６６】
また、明細部８０７より任意の処理待ち案件を選択後、案件を開くボタン８１０を選択すると、後述の選択した処理待ち案件画面（図１０）が起動される。
【００６７】
承認操作を行うと、次の処理待ち案件画面（図１０）が起動されるといった具合に、承認操作が行われる度に順次、連続的に案件画面が起動することで、承認者の作業負担を軽減する。
【００６８】
図９は、本発明の実施形態におけるワークフローシステムにおいて、図７の起案ボタン７０３が押下されたことにより先述したＷＥＢ画面（図７）より起動された起案画面の一例である。図９の起案画面は購入申請書が起動された場合の一例である。
【００６９】
図９においては、起案画面は、マイクロソフト社の推進するリッチクライアント方式「スマート・クライアント」技術から構成され、サーバとの通信はＸＭＬ ＷＥＢサービスを用いて行われる。
【００７０】
申請者は、各業務の申請書を起動し、必要事項を入力後、申請ボタン９０１を選択することで、申請操作が完了する。
【００７１】
図１０は、本発明の実施形態におけるワークフローシステムにおいて、図８の案件を開くボタン８１０が押下されたことにより先述した処理待ち案件一覧画面（図８）より起動された処理待ち案件画面の一例である。
【００７２】
図１０においては、処理待ち案件画面は、マイクロソフト社の推進するリッチクライアント方式「スマート・クライアント」技術から構成され、サーバとの通信はＸＭＬ ＷＥＢサービスを用いて行われる。
【００７３】
承認者は、画面上の当該処理待ち案件に対して内容を確認の上、差戻ボタン１００１、否決ボタン１００２、承認ボタン１００３のいずれかを押下することにより、該当する処理を実施する。また、連続承認メニュー１００４は、処理待ち案件画面が自動的に順次起動する『連続承認』モードを切り替える為に使用する。
【００７４】
連続承認メニュー１００４は、当該案件の処理が完了すると次の処理待ち案件画面が自動的に起動する『連続モード』、当該案件の処理が完了すると次の処理待ち案件画面が自動的に起動しない『単一モード』の２つの選択肢から成る。
【００７５】
当該案件を処理した後、次の処理待ち案件画面を自動的に起動したくない場合、つまり処理待ち案件に対する処理を終えたい場合には、連続承認メニューより単一モードを選択することで実現可能となる。
【００７６】
図１１は、本発明の実施形態におけるワークフローシステムにおいて、処理待ち案件一覧画面表示時のフローチャートである。
【００７７】
図１１においては、まず、Ｓ１１０２において、Ｓ１１０１のＷＥＢ画面（図７）より処理待ち案件一覧リンクボタン７０４を押下することで、Ｓ１１０３へ処理を進める。
【００７８】
Ｓ１１０３において、スマートクライアントアプリをＷＦサーバ１０１よりダウンロードし、Ｓ１１０４でスマートクライアントアプリが起動される。
【００７９】
Ｓ１１０５〜Ｓ１１１２までは処理待ち案件一覧画面（図８）を表示する為に必要なデータ取得及び画面編集の処理となる。
【００８０】
Ｓ１１０５で、図８の対象ユーザ選択ボタン８０１が押下されると、をドロップダウン形式で表示する為のデータをＷＦサーバ１０１より取得する。ＷＦサーバー１０１はデータベース中に不図示の案件一覧データベースを保持しており、そのうち、未処理（処理待ち）のステータスとなっている案件を抽出して、ワークフロークライアント１０２に送信する。
【００８１】
Ｓ１１０６で、図８の明細部８０７で表示する為の処理待ち案件一覧データをＷＦサーバ１０１より取得する。
Ｓ１１０７で、Ｓ１１０６で取得した処理待ち案件一覧画面（図８）を表示する。
【００８２】
Ｓ１１０９で、処理待ち案件が合議投票を要する案件の場合、明細部８０７の一括承認対象とする為の入力部であるチェックボックス（図８の８０８）は非表示とする（Ｓ１１１０）。
【００８３】
逆に、処理待ち案件が合議投票を要さない案件の場合、明細部８０７の一括承認対象とする為の入力部であるチェックボックス（図８の８０８）は表示とする（Ｓ１１１１）。
【００８４】
この処理によれば、合議投票を要する処理待ち案件に対して、誤って一括承認の対象としてしまうことを予め防ぐことが可能になる。
Ｓ１１１２では、次の処理待ち案件の編集に移り、処理待ち案件表示画面が表示される。（Ｓ１１１３）
【００８５】
図１２は、本発明の実施形態におけるワークフローシステムにおいて、一括承認時のフローチャートである。
【００８６】
図１２においては、まず、Ｓ１２０２において、Ｓ１２０１の処理待ち案件一覧画面（図８）で一括承認対象となる案件が選択されているか否かを判定する。
【００８７】
Ｓ１２０１で、一括承認対象となる案件が選択されていない場合は、Ｓ１２１６でエラーメッセージを表示する。選択有りの場合は、Ｓ１２０３〜Ｓ１２０８まで、選択された一括承認対象の処理待ち案件の処理が行われる。Ｓ１２０４で、選択された処理待ち案件を１件分の案件ＩＤがＷＦサーバ１０１へ送信される。
Ｓ１２０９でＷＦサーバ１０１は受け取った案件ＩＤを元にその案件の詳細データをＤＢより取得する。
【００８８】
その後、Ｓ１２１０で、一括承認ルール編集画面（図３）で登録された一括承認ルールをＤＢより取得し、Ｓ１２１１で、一括承認ルールの登録があったか否かの判定を行う。登録が無い場合は、無条件で一括承認対象外とみなし、Ｓ１２１４で、対象の処理待ち案件を未承認とする処理を行う。
【００８９】
登録が有る場合は、Ｓ１２１３で、対象の処理待ち案件が一括承認ルールに合致するか否かの判定を行う。
【００９０】
一括承認ルールに合致する場合は、Ｓ１２１３の承認処理に入り、一括承認ルールに合致しない場合は、Ｓ１２１４の未承認扱いとする。Ｓ１２１５において、承認結果（承認、未承認）をクライアント側へ返却する。
【００９１】
クライアント側では、Ｓ１２０５で、対象の処理待ち案件が一括承認として承認されたか否かを判定し、一括承認として承認されなかった場合は、Ｓ１２０６で、対象の処理待ち案件画面（図１０）を起動して承認者へ個別承認を促す。Ｓ１２０７で、承認者が処理待ち案件の内容を確認の上で個別承認を行うと、Ｓ１２０８で、全ての処理待ち案件の処理が終了したかどうかを判定し、未処理の案件が残っている場合にはＳ１２０６に戻り、次の処理待ち案件画面が自動的に表示されて、個別承認処理を繰り返し行う、という流れになる。
【００９２】
なお、図１２のフローチャートには不図示であるが、次の処理待ち案件の処理の承認画面が自動的に開かれずに、一つ一つ個別で開くような処理にする場合には、Ｓ１２０４に戻って、１つずつ案件ＩＤをサーバに送るような処理にしてもよい。
【００９３】
本処理によれば、一括承認対象として選択した業務について、一括承認が可能かどうかの判断を一度に行い、予め登録されていたルールにより一括承認対象であると判断された業務については、一括承認を行い、一括承認の対象ではない業務については個別承認画面を開き、処理が終わると連続して次の個別承認対象業務の承認画面が開くような処理になるため、簡単に承認者は各
【００９４】
以上、本発明の第一の実施例によれば、各業務を承認する際に、一括承認が可能であるか、個別承認が必要であるかを適切に判断して、一括承認と個別承認とを各業務により適切に実行させることで、処理者が各業務の承認を簡単に行うことを可能にする。
【００９５】
例えば、承認者が複数の処理待ち案件を選択して一括承認処理を行った場合に、上記登録ルールに合致する処理待ち案件については承認者の指示通りに一括承認対象として処理し、上記の登録ルールに合致しない処理待ち案件については一括承認処理の対象とはせず、個別に画面表示を行い承認者へ個別での承認処理を促すといった処理を行う。
【００９６】
また、上記登録ルールが未登録の業務については、承認者が複数の処理待ち案件を選択して一括承認処理を行った場合には、従来通り、選択されたすべての処理待ち案件が一括承認対象として処理され、さらに、当該業務に対する一括承認自体を不可とする設定が為されていた場合には、たとえ承認者が一括承認処理を行ったとしても、選択された処理待ち案件すべてが個別承認の対象として処理されるようにする。
（第二の実施例）
【００９７】
前記第一の実施例では、図８の処理待ち案件一覧表示画面にて、一括承認したい処理待ち案件を明細部８０７のチェックボックスよりチェックを入れ、一括承認ボタン８０９を選択することで一括承認が行われる処理について説明した。（実際には、前記一括承認ルールを参照して、一括承認対象とするか個別承認対象とするかの判断処理が別途発生する。）
【００９８】
一方で、図８の処理待ち案件一覧表示画面にて、明細部８０７より任意の処理待ち案件の対象データをダブルクリックするか、対象データを選択状態にして案件を開くボタン８１０を選択することで、選択された処理待ち案件が個別承認対象として画面起動される。当該案件を処理する（＝承認、否認、合議投票、差戻しなど）と、当該案件が自動的に閉じられ、次の処理待ち案件が個別承認対象として自動的に画面起動される。
【００９９】
このように、処理待ち案件が存在する間、案件を処理する毎に自動的に次の処理待ち案件が起動する処理を、本明細書において、『連続承認』と呼ぶこととする。
図８の処理待ち案件一覧表示画面が起動するまでのフローチャートは、先述した図１１の通りである。
【０１００】
図１５は、本発明の実施形態におけるワークフローシステムにおいて、連続承認時のフローチャートである。
【０１０１】
図１５においては、まず、Ｓ１５０１の処理待ち案件一覧画面（図８）にて、任意の処理待ち案件の対象データを選択する（ダブルクリック、案件を開くボタンなど）ことで、選択した処理待ち案件の案件ＩＤがＷＦサーバ１０１へ送信される（Ｓ１５０２）。
【０１０２】
Ｓ１５１３で、ＷＦサーバ１０１側では、クライアントより受け取った案件ＩＤを元に案件データをデータベースから取得し、クライアント側へ返却する（Ｓ１５１４）。
【０１０３】
クライアント側では、Ｓ１５１４でサーバーより送信された案件データを元に、Ｓ１５０３で処理待ち案件画面（図１０）をオープンする。承認者は、Ｓ１５０３の処理待ち案件画面（図１０）に対して、Ｓ１５０４のワークフロー操作（図１０の処理待ち案件画面中の承認、否認、差戻しボタン１００１〜１００３による処理や合議投票など）を行うことで、当該処理待ち案件に対する処理を実行する。処理が完了すると当該処理待ち案件画面がクローズされる。
【０１０４】
Ｓ１５０６では、処理待ち案件が存在するかどうかを判定し、次の処理待ち案件画面が存在している間はＳ１５０２のＩＤ送信処理に戻り、連続承認モードとなる。
【０１０５】
この際、Ｓ１５０３の処理待ち案件画面（図１０）にて、連続承認モードの中断が選択されている場合（図１０の１００４の連続承認モード選択で、単一承認が選択されている場合）、当該処理待ち案件に対するワークフロー操作後、次の処理待ち案件画面がオープンすることはなく、連続承認が終了する。
【０１０６】
本発明の第二の実施例によれば、処理待ち案件の内容を個別に確認して処理を行いたいといった場合に、承認者が処理待ち案件を一つ一つ開く手間を省き、自動的に順次、処理待ちの案件を開き個別承認を促すことを可能にするワークフローシステムを提供する。
【０１０７】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１０８】
また、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。
【０１０９】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【０１１０】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１１】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１２】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１１３】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０１１４】
１０１ ワークフローサーバ
１０２ ワークフロークライアント
１０３２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ ＲＯＭ
２０４ システムバス
２０５ 入力コントローラ
２０６ 出力コントローラ
２０７ 外部メモリコントローラ
２０８ 通信Ｉ／Ｆコントローラ
２０９ 入力部
２１０ 出力部
２１１ 外部メモリ
２１２ 外部プログラム
３０１ 一括承認ルール：条件式となる比較演算子のボタン群
３０２ 一括承認ルール：条件式となる判定演算子のボタン群
３０３ 一括承認ルール：条件式となる論理演算子のボタン群
３０４ 一括承認ルール：左辺となる業務項目ボタン
３０５ 一括承認ルール：右辺となる定数のボタン群
３０６ 一括承認ルールの表示エリア
３０７ 一括承認ルールの登録を確定する為のボタン
３０８ 一括承認ルールの登録を取り消す為のボタン
３０９ 業務項目ボタン３０４を選択すると表示される業務項目の一覧画面
３１０ 当該業務に対して一括承認自体を不可とする為のチェックボックス
３１１ 一括承認ルールを登録する際の当該業務名の表示エリア
５０１ 合議工程
６０１ 一括承認ルールの具体例
６０２ 一括承認ルール適用時の、一括承認フロー
７０１ ワークフローシステムにログインしたユーザー情報
７０２ ワークフローシステムにログインしたユーザーが起案可能な業務の一覧
７０３ 特定の業務を起案する為のボタン
７０４ 処理待ち案件の一覧画面を起動する為のリンク
８０１ ログイン中のユーザと、委任元ユーザの情報がリスト表示されるドロップダウン
８０２ 処理待ち案件一覧データを明細部表示させる為のボタン
８０３ 処理待ち案件一覧データをある条件に基づいて絞り込む為の条件指定部
８０４ ８０３に条件指定後、絞込結果を明細部に表示させる為のボタン
８０５ ８０４で絞り込んだ結果を取り消す為のボタン
８０６ 条件部をクリアする為のボタン
８０７ 処理待ち案件一覧データを表示エリア
８０８ 合議投票を要する処理待ち案件（チェックボックス非表示）
８０９ 明細部のチェックボックスでチェックした処理待ち案件を一括承認する為のボタン
８１０ 明細部で選択状態にした処理待ち案件を個別に開く為のボタン
８１１ 処理待ち案件一覧表示画面を閉じる為のボタン
９０１ 申請者が起案した内容を申請する為のボタン
１００１ 処理待ち案件を差し戻す為のボタン
１００２ 処理待ち案件を否決する為のボタン
１００３ 処理待ち案件を承認する為のボタン
１００４ 連続承認モードを切り替える為のメニュー
１４１０ 当該ワークフローシステムにおける案件情報
１４１１ 案件情報に占める案件親データ
１４１２ 案件情報に占める案件子データ
１４２０ 当該ワークフローシステムにおける業務設計情報
１４２１ 業務設計情報に占める業務定義
１４２２ 業務設計情報に占める経路定義
１４２３ 業務設計情報に占めるフォーム定義
１４２４ 業務設計情報に占める項目定義
【技術分野】
【０００１】
本発明は、複数の処理待ち案件を一括で承認するワークフローシステムに関するものである。
【背景技術】
【０００２】
従来、ワークフローシステムにおいては、予め定められた手順に従って、業務の流れの制御を自動化し、業務を行う作業者を支援するシステムとして構成される。
【０００３】
本発明では各種申請書、起案書、伝票、申告書、出勤簿などを業務と言い、業務を起案申請したものを案件と言い、まだ処理されていない（＝承認されていない）案件を処理待ち案件と言う。
【０００４】
近年、ワークフローシステムの一機能として、承認者に処理待ち案件の承認依頼が複数存在する場合、承認者の手間を軽減する為に個別に処理待ち案件を開くことなく纏めて一括で承認することを可能にしている。（本明細書において、この処理を案件の『一括承認』と呼び、また、案件を一つづつ個別に処理することを『個別承認』と呼ぶこととする。）
【０００５】
例えば、ある部署の複数のユーザが各々購入申請書を起案申請した場合、予め定められた手順に従って上長である承認者へ承認依頼が順次届くことになるが、場合によっては同種の承認依頼が大量に発生する為、個別に処理待ち案件を開いて申請内容を確認していては承認者の負担が増し、作業を円滑に進めることが困難になる。その為、一括承認対象として複数の処理待ち案件を同時に選択して承認処理を行うことができる機能が提供されている。
【０００６】
本発明と技術分野の類似する特許文献１として、承認者へ同時に大量に承認依頼が発生し、業務が停滞することを解消するための特開２００２−１３２７５９号公報がある。ここでは、承認対象の文書データに認証情報を付加して承認後の文書データを生成し、認証情報が付加された複数の文書データを合成した一括承認用データを表示した後にその一括承認用データ全体に対する認証情報を付加するので、複数案件の電子文書の一括した閲覧及び承認を行うことが可能となる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００２−１３２７５９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
上述した従来のワークフローシステムにおける一括承認機能であるが、現行の機能では、一括承認対象として選択された処理待ち案件の場合でも、案件内の業務項目の状態によっては一括承認対象外とし、個別承認対象に切り替えるといった業務要件があった場合に柔軟に対応することができない。
【０００９】
例えば、ある部署の複数のユーザが各々購入申請書を起案申請した案件に対して、上長である承認者が、一括承認対象として同時に選択して承認処理を行った場合、購入金額の総額が１００，０００円未満の案件の場合には承認者の指示通りに一括承認として処理するが、１００，０００円以上の案件の場合には一括承認対象外として個別承認対象とする、といった業務要件には現行の機能では対応できない。
【００１０】
上記特許文献１の特開２００２−１３２７５９号公報では、一括承認対象の処理待ち案件を一括閲覧表示して、承認者が内容を確認の上で承認処理を行うことを対象としている。このため、本来の一括承認処理の目的である、わざわざ個別に内容を表示確認する必要のないような複数の処理待ち案件に対して一括で承認処理を行えるということが不可能である。
【００１１】
本発明の目的は、各業務を承認する際に、一括承認が可能であるか、個別承認が必要であるかを適切に判断して、一括承認と個別承認とを各業務により適切に実行させることで、処理者が各業務の承認を簡単に行うことを可能にする仕組みを提供することである。
【課題を解決するための手段】
【００１２】
ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールを記憶するサーバとがネットワークを介して接続しているワークフローシステムであって、前記ユーザの申請により起票された伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報を記憶する記憶手段と、前記記憶手段により記憶された前記伝票のうち、未処理の伝票を抽出する抽出手段と、前記抽出手段により抽出された前記未処理の伝票を表示する表示手段と、前記表示手段により表示された前記未処理の伝票のうち、一括承認する対象の伝票として複数の伝票をユーザに選択させる選択手段と、前記選択手段により一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定する判定手段と、前記判定手段により一括承認が可能であると判定された伝票に対して、前記伝票毎に承認画面を表示することなく一括承認処理を行う一括承認手段と、前記判定手段により一括承認が可能ではないと判定された伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行う個別承認手段とを備えることを特徴とする。
【発明の効果】
【００１３】
本発明によれば、各業務を承認する際に、一括承認が可能であるか、個別承認が必要であるかを適切に判断して、一括承認と個別承認とを各業務により適切に実行させることで、処理者が各業務の承認を簡単に行うことを可能にする。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施形態におけるワークフローシステムの構成の一例である。
【図２】本発明の実施形態における各種端末のハードウエア構成である。
【図３】一括承認ルールの編集画面の一例である。
【図３Ｂ】一括承認ルール編集時のフローチャートである。
【図４】ワークフローの第一例である。
【図５】ワークフローの第二例である。
【図６】ワークフローにおける一括承認時の処理イメージである。
【図７】ＷＥＢ画面の一例である。
【図８】処理待ち案件一覧画面の一例である。
【図９】起案申請画面の一例である。
【図１０】処理待ち案件画面の一例である。
【図１１】処理待ち案件一覧画面表示時のフローチャートである。
【図１２】一括承認時のフローチャートである。
【図１３】一括承認ルールの登録形式の一例である。
【図１４】業務設計データと案件データのデータ構造の一例である。
【図１５】連続承認時のフローチャートである。
【発明を実施するための形態】
【００１５】
（第一の実施例）
以下、図面を参照して、本発明の実施形態を詳細に説明する。
図１は、本発明の実施形態におけるワークフローシステムの構成を示す図である。
【００１６】
図１において、ワークフローシステムは少なくとも１つのワークフローサーバ（以下、ＷＦサーバー）１０１とワークフロークライアント１０２がネットワークを介して接続されている。本実施例においては、ワークフロークライアント１０２は複数台で構成されている。
【００１７】
ユーザは、たとえばウェブブラウザやクライアントソフトウェアなどを利用して、ワークフロークライアント１０２から、ワークフローサーバ１０１に対して、ワークフロー進行の要求などを行う。
【００１８】
ワークフローサーバ１０１は、ワークフロークライアント１０２からの要求に応じた処理、案件の管理をおこない、必要があればワークフロークライアント１０２に対して結果などを送信する。ワークフローサーバ１０１とワークフロークライアント１０２の間の通信は、通常のＨＴＴＰのリクエストでもよいし、ＳＯＡＰなどを利用したウェブサービスのリクエストでもよい。
図２は、本発明の実施形態における各種端末のハードウエア構成を示す図である。
【００１９】
図２において、ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。また、ＲＯＭ２０３あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるオペレーティングシステム（ＯＳ）や、各サーバあるいは各クライアントの後述する各種機能を実現するためのプログラムが記憶されている。
ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア、一時待避領域等として機能する。
【００２０】
入力コントローラ２０５は、入力部２０９からの入力を制御する。この入力部２０９としては、特に、サーバやクライアント等の端末では、キーボード、マウス等のポインティングデバイスが挙げられる。
【００２１】
外部メモリコントローラ２０７は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ２１１へのアクセスを制御する。加えて、各サーバあるいは各クライアントの各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ２１１としては、ハードディスク（ＨＤ）やフロッピー（登録商標）ディスク（ＦＤ）、ＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）、スマートメディア等が挙げられる。
通信Ｉ／Ｆコントローラ２０８は、ネットワーク２１３を介して外部機器との通信制御処理を実行する。
【００２２】
本発明を実現するためのプログラム２１２は外部メモリ２１１に記録されており、必要に応じてＲＡＭ２０２にロードされることによりＣＰＵ２０１によって実行されるものである。
【００２３】
図３は、本発明の実施形態におけるワークフローシステムにおいて、一括承認時の各種ルールを登録・更新する為の編集画面の一例である。
図３において、一括承認ルールは、比較演算子３０１〜定数３０５までを用いて作成される。
一括承認ルールは、左辺、条件式、右辺の３つの構成要素から成る。
以下、前記一括承認ルールの編集画面（図３）を説明する。
【００２４】
比較演算子３０１は、〜〜前記一括承認ルールの構成要素である条件式を表わし、左辺および右辺を表すの比較を行う為に使用する。比較演算子３０１は、左辺と右辺の一致を意味する「＝」、左辺と右辺の不一致を意味する「！＝」、左辺が右辺に比べ小を意味する「＜」、左辺が右辺に比べ大を意味する「＞」、左辺が右辺以下を意味する「＜＝」、左辺が右辺以上を意味する「＞＝」の５つの選択肢から成る。
【００２５】
判定演算子３０２は、前記一括承認ルールの構成要素である条件式を表わし、左辺がＮＵＬＬか否かを判定する為に使用する〜〜を表す。判定演算子３０２は、左辺がＮＵＬＬであることを意味する「ＩＳ ＮＵＬＬ」、左辺がＮＵＬＬでないことを意味する「ＩＳ ＮＯＴ ＮＵＬＬ」の２つの選択肢から成る。（本明細書では、値自体が存在しない状態をＮＵＬＬと呼ぶこととする）
【００２６】
論理演算子３０３は、〜〜前記一括承認ルールを複数登録する場合に、登録した各ルールを論理積または論理和で組み合わせる為に使用するを表す。論理演算子３０３は、論理積を意味する「＆＆」、論理和を意味する「｜｜」の２つの選択肢から成る。
【００２７】
業務項目３０４は、〜〜前記一括承認ルールの構成要素である左辺を表わし、当該業務内に存在するいづれかの項目を選択する為に使用するを表す。業務項目３０４は、当該業務内の項目選択を意味する「業務項目」の１つの選択肢から成る。
【００２８】
定数３０５は、〜〜前記一括承認ルールの構成要素である右辺を表わし、左辺と比較した具体的な値を設定する為に使用するを表す。定数３０５は、文字列型定数を意味する「文字列」、数値型定数を意味する「数値」、日時型定数を意味する「日時」、真偽値型定数を意味する「真偽値」の４つの選択肢から成る。
テキストエリア３０６は、設定した前記一括承認ルールの表示エリアである。
ＯＫボタン３０７は、設定した前記一括承認ルールを保存する為に使用する。
キャンセルボタン３０８は、設定した前記一括承認ルールを取り消す為に使用する。
【００２９】
業務項目一覧画面３０９は、業務項目３０４を選択した場合に表示される。業務項目一覧画面３０９は、当該業務項目の一覧情報が表示され、任意の１項目が選択可能である。
【００３０】
チェックボックス３１０は、当該業務に対して一括承認許可を制御する為に使用する。チェックボックス３１０にチェックが設定された場合、当該業務に対しては一括承認自体が不可扱いとなる。
【００３１】
業務名３１１は、当該業務の名称を表す。
一括承認ルールの作成手順の一例を図３Ｂのフローチャートと併せて示す。
【００３２】
まず、一括承認ルールの構成要素：左辺が未設定の場合、左辺の設定を行う（図３ＢのＳ３０１）。業務項目３０４より項目ボタンを選択後、テキストエリア３０６を選択すると、業務項目一覧画面３０９が表示される。業務項目は、文字、数値、日付、真偽値、文書、添付など、いずれかの属性から成る。業務項目一覧画面３０９より項目を選択すると、一括承認ルールの構成要素の一つである左辺として設定され、テキストエリア３０６に表示される。（図３の３０６における、「項目名：購入金額」がそれに当たる。）
【００３３】
次に、一括承認ルールの構成要素：条件式が未設定の場合、条件式の設定を行う（図３ＢのＳ３０２）。比較演算子３０１或いは判定演算子３０２より任意の演算子ボタンを選択後、テキストエリア３０６を選択すると、一括承認ルールの構成要素の一つである条件式として設定され、テキストエリア３０６に表示される。（図３の３０６における、「＞＝」がそれに当たる。）
【００３４】
最後に、一括承認ルールの構成要素：右辺が未設定の場合、右辺の設定を行う（図３ＢのＳ３０３）。定数３０５より任意の属性ボタンを選択後、テキストエリア３０６を選択すると入力欄が表示されるので、任意の文字、数値、日時、真偽値を入力すると、一括承認ルールの構成要素の一つである右辺として設定され、テキストエリア３０６に表示される。（図３の３０６における「３００００」がそれに当たる。）
【００３５】
なお、一括承認ルールを複数設定したい場合は、一つ目のルールを設定後、論理演算子３０３より＆＆（＝ＡＮＤ）或いは｜｜（＝ＯＲ）を選択後（図３ＢのＳ３０４）、テキストエリア３０６を選択すると二つ目のルールが設定可能な状態となる（図３の３０６には不図示）。
【００３６】
最後に、一括承認ルールの編集が終わったら、確定処理を行う（図３ＢのＳ３０５、Ｓ３０６）。ＯＫボタン３０７を選択することで、一括承認ルールの編集が完了となり、キャンセルボタン３０８を選択することで、一括承認ルールの編集を取り消す。
一括承認ルールがデータベースにどのようなデータ形式で登録されるかは、後述する図１３で示す。
【００３７】
図１３は、本発明の実施形態におけるワークフローシステムにおいて、一括承認ルールの登録データ形式の一例である。
【００３８】
図１３において、一括承認ルールはＸＭＬ形式でデータベースに登録される。その際、一括承認ルールは業務毎に設定されるものなので、業務設計データに紐づく形で一括承認ルールは登録されている。業務設計データと一括承認ルールの関係性を示すデータ構造については、後述する図１４で示す。
【００３９】
図１４は、本発明の実施形態におけるワークフローシステムにおいて、業務設計データと案件データのデータ構造を示す図である。
【００４０】
図１４において、業務設計データ１４２０は、業務定義１４２１と経路定義１４２２とフォーム定義１４２３と項目定義１４２４を含む。業務定義１４２１は、業務設計データ１４２０を特定するための定義情報を保持する。また、業務定義１４２１は、業務設計の１つを特定するための情報として、業務ＩＤおよび、業務バージョン番号を保持する。また、業務定義１４２１は、業務名と、一括承認ルールを保持する。一括承認ルールは、図１３で先述した通り、ＸＭＬ形式で登録される。
【００４１】
経路定義１４２２は、ワークフローの流れの定義情報を保持する。フォーム定義１４２３は、ワークフローを操作するユーザーが直接操作する画面の定義情報を保持する。項目定義１４２４は、案件データ１４１０が、保持するべきデータの型や長さなどのデータ定義情報を保持する。
【００４２】
案件データ１４１０は、案件親データ１４１１と案件子データ１４１２を含む。案件親データ１４１１は、案件データ１４１０を特定するためのデータ情報を保持する。案件子データ１４１２は、案件データ１４１０の実データを保持する。
次に、図４および図５を用いて本発明の実施形態における一般的なワークフローの例について説明する。
図４は、従来のワークフローの第一例である。
図４においては、備品購入申請書の例として、購入希望申請者が各々起票申請を行う。（工程１）
【００４３】
本発明の実施例において、ワークフローの処理者はワークフロークライアント１０２より起票申請や承認の処理を行うが、ワークフロークライアント１０２では起票申請や承認の指示処理を行っているのみであり、実際には、ワークフローサーバー１０１において各処理が行われる。
【００４４】
申請者が起票申請を行うと、申請者の、上長である課長（工程２）、部長の承認を経て（工程３）主管部門の処理者が処理を行い（工程４）、主管部門長が最終承認を行う（工程５）流れを示している。
【００４５】
この場合、工程２〜工程５については、各案件に対して一つづつ承認作業を行う個別承認或いは一括承認が可能である（一括承認の場合は、別途一括承認ルールが適用され、承認或いは未承認が判定される）。
図５は、従来のワークフローの第二例である。
【００４６】
図５においては、起案書の例として、購入希望者が各々起票申請を行い（工程１）、上長である課長（工程２）、複数の合議者が同時並行に合議投票を行い（工程３）、役員の承認後（工程４）に主管部門長が最終承認を行う（工程５）流れを示している。
【００４７】
ここで言う、合議投票とは〜〜申請者より起案申請された案件に対して、複数の関係者が同意するか否かの意思表明を意味している。
【００４８】
この場合図５に示すワークフローの工程２、工程４、工程５については、個別承認或いは一括承認が可能であるが（一括承認の場合は、別途一括承認ルールが適用され、承認或いは未承認が判定される）、工程３については個別承認及び一括承認は不可能であり、合議投票（賛成、反対）のみが可能である。
【００４９】
図６は、本発明の実施形態におけるワークフローシステムにおいて、ワークフローにおける一括承認時の処理イメージである。先述したように一括承認とは、承認者に処理待ち案件の承認依頼が複数存在する場合、承認者の手間を軽減する為に個別に処理待ち案件を開くことなく纏めて一括で承認する処理方法を言う。
図６においては、一括承認ルール６０１を「購入金額＜３０，０００円」に設定したと仮定する。
【００５０】
一括承認の例６０２の中で、申請者１〜５が備品購入申請書を各々起票申請した場合、次の承認者１（課長）へ申請書（１）〜（５）に対する承認依頼が通知される。図６の実施例において夫々、申請者１「２００００円」、申請者２「３００００円」、申請者３「２５０００円」、申請者４「１００００円」、申請者５「４００００円」の案件を起票している。承認者１（課長）は、申請書（１）〜（５）の内容に目を通し、それぞれ個別に承認を行う。
【００５１】
次の承認者２（部長）は、承認依頼が通知された申請書（１）〜（５）に対して、内容に目を通すことなく一括での承認を行おうとする。その際、申請書（１）〜（５）それぞれに対して、一括承認ルール６０１が適用され一括承認対象とするか否かを判定される。
【００５２】
一括承認ルール６０１の設定内容の場合、申請書（１）については承認処理が行われ、申請書（２）については案件画面が開き個別承認が促される。個別承認後、申請書（３）、（４）については承認処理が行われ、申請書（５）については再び案件画面が開き個別承認が促される、といった流れになる。
【００５３】
図７は、本発明の実施形態におけるワークフローシステムにおいて、後述する処理待ち案件一覧画面（図８）の起動元となるＷＥＢ画面の一例である。
【００５４】
図７においては、ログインユーザ情報７０１で、当該ワークフローシステムにログインしたユーザ情報が表示される。
【００５５】
業務一覧７０２では、当該ワークフローシステムにログイン中のユーザが起案申請可能な業務の一覧が表示される。起案ボタン７０３を選択することで、後述する起案画面（図９）が起動する。
【００５６】
メニューの処理待ち案件一覧リンクボタン７０４はリンク形式（？）であり、このリンクを選択することで、後述する処理待ち案件一覧画面（図８）を起動することが可能である。
【００５７】
図８は、本発明の実施形態におけるワークフローシステムにおいて、先述した図７の７０４にある、「処理待ち案件一覧」ボタンを押下された時に起動するＷＥＢ画面（図７）より起動された処理待ち案件一覧画面の一例である。
【００５８】
図８においては、処理待ち案件一覧画面は、マイクロソフト社の推進するリッチクライアント方式「スマート・クライアント」技術から構成され、サーバとの通信はＸＭＬ ＷＥＢサービスを用いて行われる。
【００５９】
対象ユーザ選択ボタン８０１は、当該ワークフローシステムにログイン中のユーザと、委任関係となる委任元ユーザの情報がドロップダウン形式で表示される（図８の処理待ち案件一覧画面の初期表示時は、ログインユーザが選択されている状態）。
【００６０】
対象ユーザ選択ボタン８０１で別の委任元ユーザを選択後、一覧表示ボタン８０２が選択されると、選択した委任元ユーザに紐づく処理待ち案件一覧データが明細部に表示される。
【００６１】
絞込条件ボタン８０３は、明細部に表示されている処理待ち案件一覧データをある条件に基づいて絞り込む為の条件指定部である。絞込条件ボタン８０３に条件指定後、絞込ボタン８０４を選択すると絞込された結果が明細部に表示される。この絞込機能については、サーバとのＸＭＬ ＷＥＢサービス通信は行われない。あくまで、クライアント内部で保持している処理待ち案件一覧データを、クライアント内部で絞り込む形となる。
元に戻すボタン８０５は、絞込条件ボタン８０３で絞り込んだ結果を取り消すためのボタンである。
リセットボタン８０６は、条件部をクリアする。
【００６２】
明細部８０７は、処理待ち案件一覧データを表示エリアする領域である（図８の処理待ち案件一覧画面の初期表示時は、ログインユーザに紐づく処理待ち案件一覧が表示されている状態）。
【００６３】
明細部８０７の左端に位置するチェックボックスは一括承認対象とする為の入力部である（図８の処理待ち案件一覧画面の初期表示時は、すべてのチェックボックスが未選択状態）。
【００６４】
一括承認対象としたい処理待ち案件のチェックボックスにチェックを入れ、一括承認ボタン８０９を選択することで、個別に処理待ち案件画面を起動することなく一括での承認が行われる。
【００６５】
非チェックボックス８０８にチェックボックスが表示されていない処理待ち案件は、合議投票を要する処理待ち案件の為、チェックボックスが非表示の状態となっている。
【００６６】
また、明細部８０７より任意の処理待ち案件を選択後、案件を開くボタン８１０を選択すると、後述の選択した処理待ち案件画面（図１０）が起動される。
【００６７】
承認操作を行うと、次の処理待ち案件画面（図１０）が起動されるといった具合に、承認操作が行われる度に順次、連続的に案件画面が起動することで、承認者の作業負担を軽減する。
【００６８】
図９は、本発明の実施形態におけるワークフローシステムにおいて、図７の起案ボタン７０３が押下されたことにより先述したＷＥＢ画面（図７）より起動された起案画面の一例である。図９の起案画面は購入申請書が起動された場合の一例である。
【００６９】
図９においては、起案画面は、マイクロソフト社の推進するリッチクライアント方式「スマート・クライアント」技術から構成され、サーバとの通信はＸＭＬ ＷＥＢサービスを用いて行われる。
【００７０】
申請者は、各業務の申請書を起動し、必要事項を入力後、申請ボタン９０１を選択することで、申請操作が完了する。
【００７１】
図１０は、本発明の実施形態におけるワークフローシステムにおいて、図８の案件を開くボタン８１０が押下されたことにより先述した処理待ち案件一覧画面（図８）より起動された処理待ち案件画面の一例である。
【００７２】
図１０においては、処理待ち案件画面は、マイクロソフト社の推進するリッチクライアント方式「スマート・クライアント」技術から構成され、サーバとの通信はＸＭＬ ＷＥＢサービスを用いて行われる。
【００７３】
承認者は、画面上の当該処理待ち案件に対して内容を確認の上、差戻ボタン１００１、否決ボタン１００２、承認ボタン１００３のいずれかを押下することにより、該当する処理を実施する。また、連続承認メニュー１００４は、処理待ち案件画面が自動的に順次起動する『連続承認』モードを切り替える為に使用する。
【００７４】
連続承認メニュー１００４は、当該案件の処理が完了すると次の処理待ち案件画面が自動的に起動する『連続モード』、当該案件の処理が完了すると次の処理待ち案件画面が自動的に起動しない『単一モード』の２つの選択肢から成る。
【００７５】
当該案件を処理した後、次の処理待ち案件画面を自動的に起動したくない場合、つまり処理待ち案件に対する処理を終えたい場合には、連続承認メニューより単一モードを選択することで実現可能となる。
【００７６】
図１１は、本発明の実施形態におけるワークフローシステムにおいて、処理待ち案件一覧画面表示時のフローチャートである。
【００７７】
図１１においては、まず、Ｓ１１０２において、Ｓ１１０１のＷＥＢ画面（図７）より処理待ち案件一覧リンクボタン７０４を押下することで、Ｓ１１０３へ処理を進める。
【００７８】
Ｓ１１０３において、スマートクライアントアプリをＷＦサーバ１０１よりダウンロードし、Ｓ１１０４でスマートクライアントアプリが起動される。
【００７９】
Ｓ１１０５〜Ｓ１１１２までは処理待ち案件一覧画面（図８）を表示する為に必要なデータ取得及び画面編集の処理となる。
【００８０】
Ｓ１１０５で、図８の対象ユーザ選択ボタン８０１が押下されると、をドロップダウン形式で表示する為のデータをＷＦサーバ１０１より取得する。ＷＦサーバー１０１はデータベース中に不図示の案件一覧データベースを保持しており、そのうち、未処理（処理待ち）のステータスとなっている案件を抽出して、ワークフロークライアント１０２に送信する。
【００８１】
Ｓ１１０６で、図８の明細部８０７で表示する為の処理待ち案件一覧データをＷＦサーバ１０１より取得する。
Ｓ１１０７で、Ｓ１１０６で取得した処理待ち案件一覧画面（図８）を表示する。
【００８２】
Ｓ１１０９で、処理待ち案件が合議投票を要する案件の場合、明細部８０７の一括承認対象とする為の入力部であるチェックボックス（図８の８０８）は非表示とする（Ｓ１１１０）。
【００８３】
逆に、処理待ち案件が合議投票を要さない案件の場合、明細部８０７の一括承認対象とする為の入力部であるチェックボックス（図８の８０８）は表示とする（Ｓ１１１１）。
【００８４】
この処理によれば、合議投票を要する処理待ち案件に対して、誤って一括承認の対象としてしまうことを予め防ぐことが可能になる。
Ｓ１１１２では、次の処理待ち案件の編集に移り、処理待ち案件表示画面が表示される。（Ｓ１１１３）
【００８５】
図１２は、本発明の実施形態におけるワークフローシステムにおいて、一括承認時のフローチャートである。
【００８６】
図１２においては、まず、Ｓ１２０２において、Ｓ１２０１の処理待ち案件一覧画面（図８）で一括承認対象となる案件が選択されているか否かを判定する。
【００８７】
Ｓ１２０１で、一括承認対象となる案件が選択されていない場合は、Ｓ１２１６でエラーメッセージを表示する。選択有りの場合は、Ｓ１２０３〜Ｓ１２０８まで、選択された一括承認対象の処理待ち案件の処理が行われる。Ｓ１２０４で、選択された処理待ち案件を１件分の案件ＩＤがＷＦサーバ１０１へ送信される。
Ｓ１２０９でＷＦサーバ１０１は受け取った案件ＩＤを元にその案件の詳細データをＤＢより取得する。
【００８８】
その後、Ｓ１２１０で、一括承認ルール編集画面（図３）で登録された一括承認ルールをＤＢより取得し、Ｓ１２１１で、一括承認ルールの登録があったか否かの判定を行う。登録が無い場合は、無条件で一括承認対象外とみなし、Ｓ１２１４で、対象の処理待ち案件を未承認とする処理を行う。
【００８９】
登録が有る場合は、Ｓ１２１３で、対象の処理待ち案件が一括承認ルールに合致するか否かの判定を行う。
【００９０】
一括承認ルールに合致する場合は、Ｓ１２１３の承認処理に入り、一括承認ルールに合致しない場合は、Ｓ１２１４の未承認扱いとする。Ｓ１２１５において、承認結果（承認、未承認）をクライアント側へ返却する。
【００９１】
クライアント側では、Ｓ１２０５で、対象の処理待ち案件が一括承認として承認されたか否かを判定し、一括承認として承認されなかった場合は、Ｓ１２０６で、対象の処理待ち案件画面（図１０）を起動して承認者へ個別承認を促す。Ｓ１２０７で、承認者が処理待ち案件の内容を確認の上で個別承認を行うと、Ｓ１２０８で、全ての処理待ち案件の処理が終了したかどうかを判定し、未処理の案件が残っている場合にはＳ１２０６に戻り、次の処理待ち案件画面が自動的に表示されて、個別承認処理を繰り返し行う、という流れになる。
【００９２】
なお、図１２のフローチャートには不図示であるが、次の処理待ち案件の処理の承認画面が自動的に開かれずに、一つ一つ個別で開くような処理にする場合には、Ｓ１２０４に戻って、１つずつ案件ＩＤをサーバに送るような処理にしてもよい。
【００９３】
本処理によれば、一括承認対象として選択した業務について、一括承認が可能かどうかの判断を一度に行い、予め登録されていたルールにより一括承認対象であると判断された業務については、一括承認を行い、一括承認の対象ではない業務については個別承認画面を開き、処理が終わると連続して次の個別承認対象業務の承認画面が開くような処理になるため、簡単に承認者は各
【００９４】
以上、本発明の第一の実施例によれば、各業務を承認する際に、一括承認が可能であるか、個別承認が必要であるかを適切に判断して、一括承認と個別承認とを各業務により適切に実行させることで、処理者が各業務の承認を簡単に行うことを可能にする。
【００９５】
例えば、承認者が複数の処理待ち案件を選択して一括承認処理を行った場合に、上記登録ルールに合致する処理待ち案件については承認者の指示通りに一括承認対象として処理し、上記の登録ルールに合致しない処理待ち案件については一括承認処理の対象とはせず、個別に画面表示を行い承認者へ個別での承認処理を促すといった処理を行う。
【００９６】
また、上記登録ルールが未登録の業務については、承認者が複数の処理待ち案件を選択して一括承認処理を行った場合には、従来通り、選択されたすべての処理待ち案件が一括承認対象として処理され、さらに、当該業務に対する一括承認自体を不可とする設定が為されていた場合には、たとえ承認者が一括承認処理を行ったとしても、選択された処理待ち案件すべてが個別承認の対象として処理されるようにする。
（第二の実施例）
【００９７】
前記第一の実施例では、図８の処理待ち案件一覧表示画面にて、一括承認したい処理待ち案件を明細部８０７のチェックボックスよりチェックを入れ、一括承認ボタン８０９を選択することで一括承認が行われる処理について説明した。（実際には、前記一括承認ルールを参照して、一括承認対象とするか個別承認対象とするかの判断処理が別途発生する。）
【００９８】
一方で、図８の処理待ち案件一覧表示画面にて、明細部８０７より任意の処理待ち案件の対象データをダブルクリックするか、対象データを選択状態にして案件を開くボタン８１０を選択することで、選択された処理待ち案件が個別承認対象として画面起動される。当該案件を処理する（＝承認、否認、合議投票、差戻しなど）と、当該案件が自動的に閉じられ、次の処理待ち案件が個別承認対象として自動的に画面起動される。
【００９９】
このように、処理待ち案件が存在する間、案件を処理する毎に自動的に次の処理待ち案件が起動する処理を、本明細書において、『連続承認』と呼ぶこととする。
図８の処理待ち案件一覧表示画面が起動するまでのフローチャートは、先述した図１１の通りである。
【０１００】
図１５は、本発明の実施形態におけるワークフローシステムにおいて、連続承認時のフローチャートである。
【０１０１】
図１５においては、まず、Ｓ１５０１の処理待ち案件一覧画面（図８）にて、任意の処理待ち案件の対象データを選択する（ダブルクリック、案件を開くボタンなど）ことで、選択した処理待ち案件の案件ＩＤがＷＦサーバ１０１へ送信される（Ｓ１５０２）。
【０１０２】
Ｓ１５１３で、ＷＦサーバ１０１側では、クライアントより受け取った案件ＩＤを元に案件データをデータベースから取得し、クライアント側へ返却する（Ｓ１５１４）。
【０１０３】
クライアント側では、Ｓ１５１４でサーバーより送信された案件データを元に、Ｓ１５０３で処理待ち案件画面（図１０）をオープンする。承認者は、Ｓ１５０３の処理待ち案件画面（図１０）に対して、Ｓ１５０４のワークフロー操作（図１０の処理待ち案件画面中の承認、否認、差戻しボタン１００１〜１００３による処理や合議投票など）を行うことで、当該処理待ち案件に対する処理を実行する。処理が完了すると当該処理待ち案件画面がクローズされる。
【０１０４】
Ｓ１５０６では、処理待ち案件が存在するかどうかを判定し、次の処理待ち案件画面が存在している間はＳ１５０２のＩＤ送信処理に戻り、連続承認モードとなる。
【０１０５】
この際、Ｓ１５０３の処理待ち案件画面（図１０）にて、連続承認モードの中断が選択されている場合（図１０の１００４の連続承認モード選択で、単一承認が選択されている場合）、当該処理待ち案件に対するワークフロー操作後、次の処理待ち案件画面がオープンすることはなく、連続承認が終了する。
【０１０６】
本発明の第二の実施例によれば、処理待ち案件の内容を個別に確認して処理を行いたいといった場合に、承認者が処理待ち案件を一つ一つ開く手間を省き、自動的に順次、処理待ちの案件を開き個別承認を促すことを可能にするワークフローシステムを提供する。
【０１０７】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１０８】
また、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。
【０１０９】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【０１１０】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１１】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１１２】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１１３】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０１１４】
１０１ ワークフローサーバ
１０２ ワークフロークライアント
１０３２０１ ＣＰＵ
２０２ ＲＡＭ
２０３ ＲＯＭ
２０４ システムバス
２０５ 入力コントローラ
２０６ 出力コントローラ
２０７ 外部メモリコントローラ
２０８ 通信Ｉ／Ｆコントローラ
２０９ 入力部
２１０ 出力部
２１１ 外部メモリ
２１２ 外部プログラム
３０１ 一括承認ルール：条件式となる比較演算子のボタン群
３０２ 一括承認ルール：条件式となる判定演算子のボタン群
３０３ 一括承認ルール：条件式となる論理演算子のボタン群
３０４ 一括承認ルール：左辺となる業務項目ボタン
３０５ 一括承認ルール：右辺となる定数のボタン群
３０６ 一括承認ルールの表示エリア
３０７ 一括承認ルールの登録を確定する為のボタン
３０８ 一括承認ルールの登録を取り消す為のボタン
３０９ 業務項目ボタン３０４を選択すると表示される業務項目の一覧画面
３１０ 当該業務に対して一括承認自体を不可とする為のチェックボックス
３１１ 一括承認ルールを登録する際の当該業務名の表示エリア
５０１ 合議工程
６０１ 一括承認ルールの具体例
６０２ 一括承認ルール適用時の、一括承認フロー
７０１ ワークフローシステムにログインしたユーザー情報
７０２ ワークフローシステムにログインしたユーザーが起案可能な業務の一覧
７０３ 特定の業務を起案する為のボタン
７０４ 処理待ち案件の一覧画面を起動する為のリンク
８０１ ログイン中のユーザと、委任元ユーザの情報がリスト表示されるドロップダウン
８０２ 処理待ち案件一覧データを明細部表示させる為のボタン
８０３ 処理待ち案件一覧データをある条件に基づいて絞り込む為の条件指定部
８０４ ８０３に条件指定後、絞込結果を明細部に表示させる為のボタン
８０５ ８０４で絞り込んだ結果を取り消す為のボタン
８０６ 条件部をクリアする為のボタン
８０７ 処理待ち案件一覧データを表示エリア
８０８ 合議投票を要する処理待ち案件（チェックボックス非表示）
８０９ 明細部のチェックボックスでチェックした処理待ち案件を一括承認する為のボタン
８１０ 明細部で選択状態にした処理待ち案件を個別に開く為のボタン
８１１ 処理待ち案件一覧表示画面を閉じる為のボタン
９０１ 申請者が起案した内容を申請する為のボタン
１００１ 処理待ち案件を差し戻す為のボタン
１００２ 処理待ち案件を否決する為のボタン
１００３ 処理待ち案件を承認する為のボタン
１００４ 連続承認モードを切り替える為のメニュー
１４１０ 当該ワークフローシステムにおける案件情報
１４１１ 案件情報に占める案件親データ
１４１２ 案件情報に占める案件子データ
１４２０ 当該ワークフローシステムにおける業務設計情報
１４２１ 業務設計情報に占める業務定義
１４２２ 業務設計情報に占める経路定義
１４２３ 業務設計情報に占めるフォーム定義
１４２４ 業務設計情報に占める項目定義
【特許請求の範囲】
【請求項１】
ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールを記憶するサーバとがネットワークを介して接続しているワークフローシステムであって、
前記ユーザの申請により起票された伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報を記憶する記憶手段と、
前記記憶手段により記憶された前記伝票のうち、未処理の伝票を抽出する抽出手段と、
前記抽出手段により抽出された前記未処理の伝票を表示する表示手段と、
前記表示手段により表示された前記未処理の伝票のうち、一括承認する対象の伝票として複数の伝票をユーザに選択させる選択手段と、
前記選択手段により一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定する判定手段と、
前記判定手段により一括承認が可能であると判定された伝票に対して、前記伝票毎に承認画面を表示することなく一括承認処理を行う一括承認手段と、
前記判定手段により一括承認が可能ではないと判定された伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行う個別承認手段とを備えることを特徴とするワークフローシステム。
【請求項２】
前記伝票毎に承認画面を表示することなく一括して承認処理を行うための一括承認ルールを登録する登録手段とを備え、
前記判定手段は、前記登録手段により登録された前記一括承認ルールを用いることにより、
前記選択手段により一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定することを特徴とする請求項１に記載のワークフローシステム。
【請求項３】
ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールを記憶するサーバとがネットワークを介して接続しているワークフローシステムであって、
前記ユーザの申請により起票された伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報を記憶する記憶手段と、
前記記憶手段により記憶された前記伝票のうち、未処理の伝票を抽出する抽出手段と、
前記抽出手段により抽出された前記未処理の伝票を表示する表示手段と、
前記表示手段により表示された前記未処理の伝票のうち、承認処理を行う伝票をユーザに選択させる第二の選択手段と、
前記第二の選択手段により選択された前記伝票の承認処理を行った後、前記未処理の伝票を承認するための承認画面を連続して自動的に表示することで承認処理を行う連続承認手段とを備えることを特徴とするワークフローシステム。
【請求項４】
前記登録手段により前記一括承認をするためのルールが登録されていない場合、前記選択手段でユーザにより選択された前記複数の伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行うことを特徴とする請求項１または２に記載のワークフローシステム。
【請求項５】
前記登録手段により一括承認を行わない旨のルールが設定された場合、前記選択手段でユーザにより選択された前記複数の伝票に対して、前記伝票毎に承認画面を表示することでユーザに個別承認をさせることを特徴とする請求項１、２または４のいずれか１項に記載のワークフローシステム。
【請求項６】
前記登録手段は、前記伝票毎に一括承認をする複数のルールを登録可能であることを特徴とする請求項１、２、４または５のいずれか１項に記載のワークフローシステム。
【請求項７】
前記登録手段は、前記伝票毎に一括承認をしないルールを設定することが可能であることを特徴とする請求項１、２、４、５または６のいずれか１項に記載のワークフローシステム。
【請求項８】
前記ユーザにより起票された伝票のうち合議投票の処理を要する伝票に対して、前記選択手段により前記一括承認の対象として選択させないことを特徴とする１、２、４、５、６または７のいずれか１項に記載のワークフローシステム。
【請求項９】
ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールと、前記伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報とを記憶するサーバとがネットワークを介して接続しているワークフローシステムの制御方法であって、
前記ワークフローシステムの抽出手段が、前記伝票のうち、未処理の伝票を抽出する抽出ステップと、
前記ワークフローシステムの表示手段が、前記抽出ステップにより抽出された前記未処理の伝票を表示する表示ステップと、
前記ワークフローシステムの選択手段が、前記表示ステップにより表示された前記未処理の伝票のうち、一括承認する対象の伝票として複数の伝票をユーザに選択させる選択ステップと、
前記ワークフローシステムの判定手段が、前記選択ステップにより一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定する判定ステップと、
前記ワークフローシステムの一括承認手段が、前記判定ステップにより一括承認が可能であると判定された伝票に対して、前記伝票毎に承認画面を表示することなく一括承認処理を行う一括承認ステップと、
前記ワークフローシステムの個別承認手段が、前記判定ステップにより一括承認が可能ではないと判定された伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行う個別承認ステップとを特徴とする制御方法。
【請求項１０】
ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールを記憶するサーバとがネットワークを介して接続しているワークフローシステムとして機能させるプログラムであって、
前記ユーザの申請により起票された伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報を記憶する記憶手段と、
前記記憶手段により記憶された前記伝票のうち、未処理の伝票を抽出する抽出手段と、
前記抽出手段により抽出された前記未処理の伝票を表示する表示手段と、
前記表示手段により表示された前記未処理の伝票のうち、一括承認する対象の伝票として複数の伝票をユーザに選択させる選択手段と、
前記選択手段により一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定する判定手段と、
前記判定手段により一括承認が可能であると判定された伝票に対して、前記伝票毎に承認画面を表示することなく一括承認処理を行う一括承認手段と、
前記判定手段により一括承認が可能ではないと判定された伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行う個別承認手段とを備えることを特徴とするプログラム。
【請求項１】
ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールを記憶するサーバとがネットワークを介して接続しているワークフローシステムであって、
前記ユーザの申請により起票された伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報を記憶する記憶手段と、
前記記憶手段により記憶された前記伝票のうち、未処理の伝票を抽出する抽出手段と、
前記抽出手段により抽出された前記未処理の伝票を表示する表示手段と、
前記表示手段により表示された前記未処理の伝票のうち、一括承認する対象の伝票として複数の伝票をユーザに選択させる選択手段と、
前記選択手段により一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定する判定手段と、
前記判定手段により一括承認が可能であると判定された伝票に対して、前記伝票毎に承認画面を表示することなく一括承認処理を行う一括承認手段と、
前記判定手段により一括承認が可能ではないと判定された伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行う個別承認手段とを備えることを特徴とするワークフローシステム。
【請求項２】
前記伝票毎に承認画面を表示することなく一括して承認処理を行うための一括承認ルールを登録する登録手段とを備え、
前記判定手段は、前記登録手段により登録された前記一括承認ルールを用いることにより、
前記選択手段により一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定することを特徴とする請求項１に記載のワークフローシステム。
【請求項３】
ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールを記憶するサーバとがネットワークを介して接続しているワークフローシステムであって、
前記ユーザの申請により起票された伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報を記憶する記憶手段と、
前記記憶手段により記憶された前記伝票のうち、未処理の伝票を抽出する抽出手段と、
前記抽出手段により抽出された前記未処理の伝票を表示する表示手段と、
前記表示手段により表示された前記未処理の伝票のうち、承認処理を行う伝票をユーザに選択させる第二の選択手段と、
前記第二の選択手段により選択された前記伝票の承認処理を行った後、前記未処理の伝票を承認するための承認画面を連続して自動的に表示することで承認処理を行う連続承認手段とを備えることを特徴とするワークフローシステム。
【請求項４】
前記登録手段により前記一括承認をするためのルールが登録されていない場合、前記選択手段でユーザにより選択された前記複数の伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行うことを特徴とする請求項１または２に記載のワークフローシステム。
【請求項５】
前記登録手段により一括承認を行わない旨のルールが設定された場合、前記選択手段でユーザにより選択された前記複数の伝票に対して、前記伝票毎に承認画面を表示することでユーザに個別承認をさせることを特徴とする請求項１、２または４のいずれか１項に記載のワークフローシステム。
【請求項６】
前記登録手段は、前記伝票毎に一括承認をする複数のルールを登録可能であることを特徴とする請求項１、２、４または５のいずれか１項に記載のワークフローシステム。
【請求項７】
前記登録手段は、前記伝票毎に一括承認をしないルールを設定することが可能であることを特徴とする請求項１、２、４、５または６のいずれか１項に記載のワークフローシステム。
【請求項８】
前記ユーザにより起票された伝票のうち合議投票の処理を要する伝票に対して、前記選択手段により前記一括承認の対象として選択させないことを特徴とする１、２、４、５、６または７のいずれか１項に記載のワークフローシステム。
【請求項９】
ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールと、前記伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報とを記憶するサーバとがネットワークを介して接続しているワークフローシステムの制御方法であって、
前記ワークフローシステムの抽出手段が、前記伝票のうち、未処理の伝票を抽出する抽出ステップと、
前記ワークフローシステムの表示手段が、前記抽出ステップにより抽出された前記未処理の伝票を表示する表示ステップと、
前記ワークフローシステムの選択手段が、前記表示ステップにより表示された前記未処理の伝票のうち、一括承認する対象の伝票として複数の伝票をユーザに選択させる選択ステップと、
前記ワークフローシステムの判定手段が、前記選択ステップにより一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定する判定ステップと、
前記ワークフローシステムの一括承認手段が、前記判定ステップにより一括承認が可能であると判定された伝票に対して、前記伝票毎に承認画面を表示することなく一括承認処理を行う一括承認ステップと、
前記ワークフローシステムの個別承認手段が、前記判定ステップにより一括承認が可能ではないと判定された伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行う個別承認ステップとを特徴とする制御方法。
【請求項１０】
ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールを記憶するサーバとがネットワークを介して接続しているワークフローシステムとして機能させるプログラムであって、
前記ユーザの申請により起票された伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報を記憶する記憶手段と、
前記記憶手段により記憶された前記伝票のうち、未処理の伝票を抽出する抽出手段と、
前記抽出手段により抽出された前記未処理の伝票を表示する表示手段と、
前記表示手段により表示された前記未処理の伝票のうち、一括承認する対象の伝票として複数の伝票をユーザに選択させる選択手段と、
前記選択手段により一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定する判定手段と、
前記判定手段により一括承認が可能であると判定された伝票に対して、前記伝票毎に承認画面を表示することなく一括承認処理を行う一括承認手段と、
前記判定手段により一括承認が可能ではないと判定された伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行う個別承認手段とを備えることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図３Ｂ】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図３Ｂ】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１１−１４６０７６（Ｐ２０１１−１４６０７６Ａ）
【公開日】平成２３年７月２８日（２０１１．７．２８）
【国際特許分類】
【出願番号】特願２０１１−１００３７３（Ｐ２０１１−１００３７３）
【出願日】平成２３年４月２８日（２０１１．４．２８）
【分割の表示】特願２００９−１８１８４５（Ｐ２００９−１８１８４５）の分割
【原出願日】平成２１年８月４日（２００９．８．４）
【出願人】（３０１０１５９５６）キヤノンソフトウェア株式会社 (364)
【公開日】平成２３年７月２８日（２０１１．７．２８）
【国際特許分類】
【出願日】平成２３年４月２８日（２０１１．４．２８）
【分割の表示】特願２００９−１８１８４５（Ｐ２００９−１８１８４５）の分割
【原出願日】平成２１年８月４日（２００９．８．４）
【出願人】（３０１０１５９５６）キヤノンソフトウェア株式会社 (364)
[ Back to top ]