JP2006072884A - 業務案件処理システム - Google Patents

Abstract

【課題】
複数の個別手続を有する業務案件に対する各個別手続の進捗状況を業務案件毎に整理して業務案件全体の進捗状況として認識可能に表示する業務案件処理システムを提供する。
【解決手段】
各個別手続における申請者の入力処理による入力データを受け付ける入力データ受付部３と、最初に実行される入力処理の入力データにより特定される業務案件に対して、当該業務案件の所定の属性に基づいて１または複数の個別手続を抽出する個別手続抽出部４と、業務案件の各個別手続の進捗状況を入力データに基づいて抽出する進捗管理部５と、業務案件毎に各個別手続を纏めて一覧表示するとともに、進捗管理部５が抽出した進捗状況を一覧表示された個別手続と対応付けて表示する画面データを作成し、所定のコンピュータ端末９に出力する業務案件進捗出力部６と、を備える。
【選択図】 図１

Description

本発明は、申請者による入力処理を各別に伴う１または複数の個別手続を有する業務案件に対する進捗管理をコンピュータ処理により実行する業務案件処理システムに関する。

この種の業務案件処理システムとしては、企業内における物品購入や出張申請等の各種申請業務において、決裁文書の文書作成、回覧、及び、承認等をコンピュータシステム上で行うワークフローシステムが普及している。

例えば、下記特許文献１に開示されているワークフローシステムでは、申請者が決裁文書を作成し、当該決裁文書を回覧処理手段により予め決められた決裁ルートに従って回覧し、決裁処理を行う。決裁ルートは起案処理部において作成された属性情報によって決定され、次の回覧者には通知部から電子メール等によって、処理すべき決裁文書の存在することが通知される仕組みになっている。

決裁処理すべき案件の存在することを通知された上司（決裁権限のある承認者）は、その決裁文書の内容を確認し、承認或いは否認の決裁を行う。承認された決裁文書は次の回覧者に回送され、否認された決裁文書は申請者に戻される。

また、申請した決裁文書の進捗状況については、決裁ルートの情報とともに画面表示されるのが一般的であり、申請者は決裁申請した案件の進捗状況を当該表示画面において確認することができる。下記特許文献２に、決裁文書の進捗状況を示す画面表示例が開示されている。

尚、申請業務において上述のように決裁文書を作成して回覧する方法の他、定型的な申請においては、申請者のコンピュータ端末上の入力画面から入力された所定の情報を受け付け、その入力情報のみを回覧していく方法もある。
特開平０８−２０４３７５号公報 特開平１０−１９３９９３号公報

通常、物品購入等の１つの業務案件が完了するまでに、起案、見積、発注、検収等の個別手続が順番に発生し、夫々の個別手続において、申請処理や１または複数の決裁処理が必要となる。しかしながら、従来のワークフローシステムにおける進捗状況の画面表示では、これらの個別手続を独立した案件として扱い、各個別手続の進捗状況を、個別独立して表示していた。

かかる個別案件毎の進捗状況の表示は、例えば、家族異動届等の１回の申請処理で終了する業務案件に対しては、十分であるものの、上述の物品購入等のように複数の個別手続（起案、見積、発注、検収等）を伴う業務案件では、業務案件が複数同時に進行する場合等において、各業務案件の夫々の個別手続が個別に表示されるため、必ずしも分かり易い表示とはなっていなかった。例えば、図９に示すように、進捗状況表示画面には、購入申請（起案）、見積申請、発注申請、検収申請の進捗状況が夫々バラバラに表示されることになり、１つの購買案件として把握し難い。また、複数の購買案件を申請した場合に、夫々の購買案件の各個別手続の進捗状況が混在して表示されるため、一層見難い表示となっていた。特に、汎用的なワークフローシステムの場合、取り扱う業務案件が、購買案件の他、出張申請等の様々な申請案件が混在するため、一連の個別手続の状況を把握するのが困難であった。

また、購買案件の場合、その購買対象の購入金額等の属性によって、必要とする手続等の申請ルートが異なるのが一般的である。例えば、１００万円以下の購買はマネージャー決裁で、それ以上の購買案件は組織長決裁等のように決裁ルートが異なったり、１万円以下の購買案件については見積申請が不要である等の必要とする手続が異なったりする場合がある。申請者は、購買対象の属性等によって異なる申請ルールを覚えていないことが多く、次に為すべき手続が分からない場合が多い。そのため、一部のワークフローシステムでは、申請者に対して次に為すべき手続について電子メール等により通知することを行っているが、人事異動等による電子メール送信先の変更や、申請ルールの変更に伴う通知内容の変更等、システム上のメンテナンス負荷が大きいため、個別案件毎に指示内容を記載したきめ細かな通知を行うことは、実用上困難であった。

本発明は、上述の問題点に鑑みてなされたもので、その目的は、複数の個別手続を有する業務案件に対する各個別手続の進捗状況を業務案件毎に整理して業務案件全体の進捗状況として認識可能に表示する業務案件処理システムを提供する点にある。

この課題を解決するための本発明に係る業務案件処理システムの第一の特徴構成は、申請者による入力処理を各別に伴う１または複数の一連の個別手続を有する業務案件に対する進捗管理をコンピュータ処理により実行する業務案件処理システムであって、前記各個別手続における前記入力処理による入力データを受け付ける入力データ受付部と、最初に実行される前記入力処理の前記入力データにより特定される前記業務案件に対して、当該業務案件の所定の属性に基づいて前記１または複数の個別手続を抽出する個別手続抽出部と、前記業務案件の前記各個別手続の進捗状況を前記入力データに基づいて抽出する進捗管理部と、前記業務案件毎に前記各個別手続を纏めて一覧表示するとともに、前記進捗管理部が抽出した進捗状況を一覧表示された前記個別手続と対応付けて表示する画面データを作成し、所定のコンピュータ端末に出力する業務案件進捗出力部と、を備えてなる点にある。

上記第一の特徴構成によれば、１または複数の一連の個別手続を有する業務案件に対する申請者からの入力処理によって入力データが送信されると、入力データ受付部が当該入力データを受け付け、例えば、付属の記憶装置内に格納する。ここで、個別手続抽出部は、入力データ受付部が受け付けた入力データが、業務案件において最初に実行される入力処理による入力データである場合は、当該入力データによって特定の業務案件が起案されたと認識して、当該業務案件の所定の属性に対応する１または複数の一連の個別手続を抽出する。これにより、同じ業務案件に属する各個別案件相互の対応付けがなされる。進捗管理部は、当該業務案件の或る個別手続における入力処理による入力データを受け付けると、当該個別手続における進捗状況の変化を認識できるとともに、他の個別手続における進捗状況に変化の無いことを認識できる。従って、進捗管理部は、何れか１つの個別手続の入力データに基づいて当該業務案件全体の進捗状況を抽出することができる。つまり、従来のワークフローシステムであれば管理対象の案件として扱われなかった入力処理前の個別手続（例えば、購買申請直後の起案段階における発注手続等）が、入力処理前であっても管理対象となり、入力処理前としてその進捗状況が判断されることになる。業務案件進捗出力部は、上記要領で進捗管理部が抽出した各個別手続の進捗を業務案件毎に纏めて一覧表示される個別手続に対応付けて表示する画面データを、例えば、申請者のコンピュータ端末に出力することができるので、申請者は、当該コンピュータ端末の表示画面に表示される業務案件毎に纏められた一覧表示画面上で、自らの起案した業務案件で必要となる１または複数の個別手続を認識できるとともに、起案した業務案件の進捗状況を、処理中の個別手続についてだけではなく、業務案件全体での進捗状況を把握することができる。

本発明に係る業務案件処理システムの第二の特徴構成は、上記第一の特徴構成に加えて、前記業務案件進捗出力部は、前記個別手続が複数存在する場合に、当該複数の個別手続の処理順に並べて各進捗状況を表示する点にある。

上記第二の特徴構成によれば、業務案件毎の個別手続が処理順に並べられ一覧表示されるので、当該一覧表示画面上で処理済または処理中の個別手続の進捗状況が表示されることにより、次に処理すべき未処理状態の個別手続を容易に認識できる。

本発明に係る業務案件処理システムの第三の特徴構成は、上記何れかの特徴構成に加えて、前記業務案件進捗出力部は、前記画面データを、前記各個別手続に係る複数の進捗状況を相互に識別可能なアイコンを用いて表示可能に作成する点にある。

上記第三の特徴構成によれば、アイコンによって小さい表示面積で簡潔に複数の進捗状況を相互に識別可能に表示できるため、限られた表示面積内で、多くの業務案件を各個別手続の進捗状況とともに分かりやすく一覧表示することができる。

本発明に係る業務案件処理システムの第四の特徴構成は、上記第三の特徴構成に加えて、前記申請者の使用するコンピュータ端末の表示画面上に前記画面データに基づいて表示された前記アイコンは、前記表示画面上でクリックされることにより、前記アイコンに対応する前記業務案件及び前記個別手続の前記アイコンが示す進捗状況に応じた閲覧または入力画面の表示要求を出力するように構成されている点にある。

上記第四の特徴構成によれば、申請者は表示画面上の各個別案件の進捗状況を示すアイコンをクリックするだけの簡単な操作で、当該進捗状況に応じた閲覧または入力画面の表示要求を本発明システムに対して出力することができるので、本発明システム側から、申請者の使用するコンピュータ端末に対して、進捗状況に応じた閲覧または入力画面用の画面データを送信することができ、申請者は当該画面データを上記コンピュータ端末上で、閲覧または入力画面として表示させることができ、所定の閲覧または入力操作が可能となる。

本発明に係る業務案件処理システムの第五の特徴構成は、上記何れかの特徴構成に加えて、前記進捗管理部は、前記個別手続の１つが完了した場合に、後続の個別手続が存在するか否かを判定し、後続の個別手続が存在する場合に、当該後続の個別手続の進捗状況を前記入力処理の実行待ち状態として抽出する点にある。

更に、本発明に係る業務案件処理システムの第六の特徴構成は、上記第五の特徴構成に加えて、前記業務案件進捗出力部は、一覧表示する前記業務案件の前記個別手続の中に、進捗状況が前記実行待ち状態である個別手続が存在する場合に、当該個別手続の進捗状況を識別可能に表示する点にある。

上記第五または第六の特徴構成によれば、申請者のコンピュータ端末の表示画面上に表示される業務案件毎に纏められた一覧表示画面上で、入力処理の実行待ち状態にある進捗状況を、当該進捗状況にある個別手続に対応付けて表示されるため、申請者は、入力処理の実行待ち状態にある個別手続の存在と、その個別手続きが何であるかを当該一覧表示画面上で認識することができる。特に、第六の特徴構成によれば、従来のワークフローシステムの場合には、入力処理の実行待ち状態にある個別手続は直接の管理対象の案件として扱われなかったため、申請者への通知を電子メール等によって別処理で行う必要があったところ、電子メール等の別の伝達媒体によらず、申請者に対して、当該一覧表示画面上で入力処理の実行待ち状態にある個別手続の特定とその存在の通知を行うことができる。

本発明に係る業務案件処理システム（以下、単に「本発明システム」と称す。）の実施の形態を図面に基づいて説明する。

本発明システムは、申請者による入力処理を各別に伴う１または複数の一連の個別手続を有する業務案件に対する進捗管理をコンピュータ処理により実行する業務案件処理システムである。本実施形態では、進捗管理の対象となる業務案件として、企業における購買案件を想定する。購買案件は、物品やサービスの購買に係る起案（購買申請）・見積・発注・検収等の一連の個別手続における申請・決裁処理を１案件として統合したものであり、購買案件の属性によって、複数の購買形式に分類される。

本実施形態では、一例として、３種類の購買形式を想定し、夫々を、「資材購買」、「担当購買」、及び、「経理支出」とする。「資材購買」は、例えば、購買対象物品等の購買価額が１００万円以上で、企業の資材部門が、起案（購買申請）、見積、発注、検収を担当する案件である。「担当購買」は、例えば、購買対象物品の購買価額が１００万円未満で、購買対象物品等の利用部門の担当者が、起案、見積、発注、検収を担当する案件である。また、購買価額や購買対象物品やサービスの品目等の購買案件の属性によっては、見積の不要な場合がある。「経理支出」は、「資材購買」や「担当購買」の対象外の物品等の購入に係る案件で、既に担当者の決裁権限内で発注済のものを、１回の入力処理で購入依頼から検収依頼を兼ねて申請し、請求書ベースで処理する案件である。尚、購買形式は、上記３種類に限定されるものではない。

本発明システム１は、図１に示すように、企業内で発生する複数の購買案件に対する各個別手続の入力処理（担当者による申請入力、承認者による承認または否認入力）を受け付けて、各入力処理の入力データ及び購買案件の進捗状況等を管理するサーバコンピュータ２上に、入力データ受付部３、個別手続抽出部４、進捗管理部５、業務案件進捗出力部６、及び、案件データ記憶部７を備えて構成される。そして、サーバ２は、ＬＡＮ等のコンピュータネットワーク８を介して、複数のクライアント端末９とデータ送受信可能に接続しており、クライアント端末９は、サーバ２の入力データ受付部３及び業務案件進捗出力部６が出力する画面データや要求する入力データに対する入出力処理のユーザインターフェイスとして位置付けられ、各個別手続の入力処理や購買案件の進捗状況の閲覧に供せられる。クライアント端末９は、予めインストールされている一般的なブラウザソフトウェアを起動して、サーバ２から受信した様々な画面データの表示を行う。

入力データ受付部３は、起案（購買申請）・見積・発注・検収等の各個別手続におけるクライアント端末９上での担当者（以下、適宜「申請者」と称す。）による申請処理または承認者（決裁権限者）による決裁処理等の入力処理で生成された入力データを、ネットワーク８を介して受け付け、サーバ２に内蔵または外付けの記憶装置の所定の記憶領域に形成されている案件データ記憶部７に格納する。また、入力データ受付部３は、入力データを受け付ける前処理として、クライアント端末９からの要求に基づいて、クライアント端末９上で上記入力処理を行うための入力画面のＷＥＢ形式の画面データを生成し、クライアント端末９に送信する。そして、クライアント端末９では、受信した画面データをインストール済みのブラウザソフトウェアを起動して画面表示させ、表示された入力画面上の入力項目の枠内に、マウスやキーボード等の入力装置を操作して、入力データの入力を行い、入力された入力データがサーバ２に対して一括して送信される。入力画面は、起案（購買申請）・見積・発注・検収等の各個別手続によって異なり、また、申請処理と決裁処理の入力処理の違いによっても異なる。例えば、購買申請の申請処理では、入力画面は、図２に例示するような「購入依頼書」の作成画面となる。

個別手続抽出部４は、最初に実行される入力処理、つまり、起案（購買申請）の個別手続における申請処理で入力され、入力データ受付部３で受け付けられた入力データにより、新規の購買案件の入力がなされたことを認識し、当該入力データに基づいて、当該新規の購買案件の購買形式を特定し、特定した購買形式を含む当該購買案件の属性に対応する１または複数の個別手続を抽出する。個別手続の抽出は、例えば、予め購買形式毎の購買案件の属性と個別手続の関係を設定したテーブルに基づいて実行される。従って、「資材購買」または「担当購買」に該当する購買案件では、「購買申請手続」・「発注手続」・「検収手続」、または、「購買申請手続」・「見積手続」・「発注手続」・「検収手続」の３または４の個別手続が抽出され、「経理支出」に該当する購買案件では、「経理支出手続」が個別手続として１つだけ抽出される。購買案件毎に抽出された個別手続は、後述の進捗管理部５の進捗管理対象として登録される。また、入力データ受付部３で受け付けられた入力データは、購買案件と個別手続を識別可能にして案件データ記憶部７に正式に格納される。

進捗管理部５は、購買案件毎に、抽出された各個別手続の進捗状況を入力データ受付部３で受け付けられた入力データに基づいて抽出する。進捗管理部５は、進捗状況として、「未作成」、「作成中」、「申請中」、及び、「決裁済」の４状態がある。進捗状況の「未作成」は、「資材購買」または「担当購買」に該当する購買案件における「見積手続」・「発注手続」・「検収手続」の内の、申請者による入力処理の行われていない未処理の状態である。特に、処理順が１つ手前の個別手続の進捗状況が「決裁済」の個別手続の場合は、進捗管理部５は、入力処理の実行待ち状態にある「未作成」（「未作成＋要入力」）と認識する。尚、「資材購買」と「担当購買」の「起案（購入申請）」及び「経理支出」の「経理支出手続」は、最初の個別手続或いは単独の個別手続であるため、購買案件として認識された時点で、進捗状況が「作成中」または「申請中」となっており、進捗状況の「未作成」は実質的に存在しない。進捗状況の「作成中」は、各個別手続における申請者の入力処理（申請処理）により入力データが案件データ記憶部７に記憶された状態の内、当該入力処理が未完の状態である。進捗状況の「申請中」は、各個別手続における申請者の入力処理（申請処理）により入力データが案件データ記憶部７に記憶された状態の内、当該入力処理が完了しており、１または複数の承認者による決裁処理前または決裁処理中の状態である。進捗管理部５は、申請処理の入力データによって、入力処理が完了しているか否かを判断して、「作成中」と「申請中」の区別を行う。進捗状況の「決裁済」は、各個別手続における全ての承認者の入力処理（決裁処理）による入力データ（承認の決裁を示すデータ）が案件データ記憶部７に記憶された状態である。進捗管理部５は、決裁処理の入力データによって、承認の決裁を示すデータが含まれている場合に、「決裁済」と判定する。「見積手続」・「発注手続」・「検収手続」の３つの個別手続の進捗状況の初期状態は、全て「未作成」であるので、「未作成」、「作成中」、「申請中」、「決裁済」の順、または、「未作成」、「申請中」、「決裁済」の順に推移する。「購入申請」については、最初に認識される進捗状況が、「作成中」または「申請中」であるので、「作成中」、「申請中」、「決裁済」の順、または、「申請中」、「決裁済」の順に推移する。１回の入力処理で申請処理の入力データの入力が完了する場合は、「作成中」の進捗状況は認識されない。

業務案件進捗出力部６は、申請者の使用するクライアント端末９からの要求、或いは、進捗状況の内部更新処理の結果に基づいて、クライアント端末９上で、申請者が起案した処理中の購買案件を、購買案件毎に各個別手続の存在と進捗状況を纏めて一覧表示するＷＥＢ形式の画面データを作成し、該画面データをクライアント端末９に送信する。購買案件の一覧表示画面は、例えば、図３に示すような表形式で構成される。即ち、一覧表示画面の各行に、１件の購買案件の１または複数の個別手続の存在とその進捗状況を示すアイコンが表示される。具体的には、各行の左側より、案件の通し番号、購買形式、案件名、申請者所属、申請者名（購買依頼者名）、購買申請手続の進捗を示すアイコン、見積手続の進捗を示すアイコン、発注手続の進捗を示すアイコン、検収手続の進捗を示すアイコン、経理支出手続の進捗を示すアイコンが表示される。尚、購買形式が「資材購買」または「担当購買」に該当する購買案件では、個別手続抽出部４によって抽出された「購買申請手続」・「発注手続」・「検収手続」、または、「購買申請手続」・「見積手続」・「発注手続」・「検収手続」の各進捗を示すアイコンが個別手続の処理順に並べて表示され、「経理支出」に該当する購買案件では、「経理支出手続」の進捗を示すアイコンが独立して表示される。また、各アイコンは、「未作成」、「作成中」、「申請中」、及び、「決裁済」の４状態に対応するものが使用される。尚、本実施形態では、「未作成」のアイコンは、進捗管理部５が入力処理の実行待ち状態にある「未作成」（「未作成＋要入力」）と認識した場合にのみ表示される。この結果、当該一覧表示画面を見た申請者は、「未作成」のアイコンの存在によって、当該アイコンが表示されている個別手続に対応する入力処理を行う必要のあることを認識することができる。

また、上記一覧表示画面に表示された各アイコンは、クライアント端末９の表示画面上でクリックされることにより、各アイコンに対応する購買案件及び個別手続の進捗状況に応じた閲覧または入力画面の表示要求が、サーバ２に送信されるように構成されている。例えば、「購買申請手続」の進捗状況が「作成中」である場合、その対応するアイコンをクリックすると、作成中の購入依頼書（図２参照）が自動的に画面表示される。また、別の例では、「発注手続」の進捗状況が「決裁済」で、「検収手続」の進捗状況が「未作成」の場合、当該「未作成」のアイコンをクリックすると、新規の検収書の入力画面が自動的に画面表示される。

更に、業務案件進捗出力部６は、承認者の使用するクライアント端末９からの要求に基づいて、クライアント端末９上で、承認者の決裁権限下にある申請者が起案した購買案件であって、当該承認者の決裁処理を必要とする全ての決裁待ち購買案件を纏めて一覧表示するＷＥＢ形式の画面データを作成し、該画面データをクライアント端末９に送信する。

案件データ記憶部７は、サーバ２に内蔵または外付けの磁気記憶装置等の不揮発性の記憶装置の所定の記憶領域に形成され、起案（購買申請）、見積、発注、検収、経理支出等の各個別手続における入力処理（申請処理と決裁処理）において、クライアント端末９上で生成され、サーバ２に送信された入力データを記憶保存する。具体的には、購買申請手続における購入依頼書の入力内容と決裁内容、見積手続における見積依頼書の入力内容と決裁内容、発注手続における発注書の入力内容と決裁内容、検収手続における検収書の入力内容と確認内容と決裁内容が、各別に保存される。

クライアント端末９は、申請者が、起案（購買申請）・見積・発注・検収等の各個別手続における申請処理（入力処理）を行うためのコンピュータ端末であり、また、承認者が申請された各個別手続に対する決裁処理（入力処理）を行うためのコンピュータ端末であり、一般的なパーソナルコンピュータ等の汎用コンピュータで構成される。また、各クライアント端末９は、サーバ２から出力される各種のＷＥＢ形式の画面データを受信し、表示画面上に表示させるための汎用のブラウザソフトウェアがインストールされている。

以上、本発明システム１の入力データ受付部３、個別手続抽出部４、進捗管理部５、及び、業務案件進捗出力部６は、サーバ２上でプログラム処理及び必要に応じてハードウェア手段を用いて実行することにより実現される。

次に、本発明システム１を用いて、申請者が「担当購買」に該当する購買案件について、起案（購買申請）・見積・発注・検収等の各個別手続を順番に処理していく場合の、本発明システム１とクライアント端末９における各処理について説明する。先ず、図４を参照して、購買申請手続における申請者の入力処理（申請処理）について説明する。

申請者は、クライアント端末９から本発明システム１を起動し、購買案件の一覧表示画面（図３参照）の出力要求を本発明システム１に送信する（ステップ＃１０）。尚、本発明システム１の起動に当たっては、本発明システム１から申請者の本人確認のためのＩＤとパスワードの入力要求がなされ、当該ＩＤとパスワードを本発明システム１に送信することで、上記出力要求が実行される。

本発明システム１の業務案件進捗出力部６は、上記出力要求に応答して、上記出力要求の受信時点における申請者の起案した処理中の購買案件の一覧表示画面の画面データを案件データ記憶部７に保存されている入力データを基に作成し、クライアント端末９に出力する（ステップ＃２０）。

クライアント端末９は、受信した購買案件の一覧表示画面の画面データを処理して表示画面上に出力表示する（ステップ＃１１）。申請者は、新規に購買案件を起案するために、購買案件の一覧表示画面（図３参照）上に表示された「新規作成」ボタンをクリックし、引き続き、購買形式を選択するウィンドウが表示されると、「担当購買」ボタンをクリックして、担当購買の購買申請手続における申請者の入力処理画面の出力要求を本発明システム１に送信する（ステップ＃１２）。ここで、購買申請手続における申請者の入力処理画面は、図２に例示する「購入依頼書」の作成画面である。

本発明システム１の入力データ受付部３は、上記出力要求に応答して、上記入力処理画面の画面データを生成し、クライアント端末９に送信する（ステップ＃２１）。

クライアント端末９は、受信した入力処理画面の画面データを処理して表示画面上に出力表示し、表示された入力処理画面上の入力項目の枠内に、マウスやキーボード等の入力装置を操作して、入力データの入力を行う（ステップ＃１３）。全ての入力項目を入力が完了すると、入力処理画面上の「申請」ボタンをクリックすると、全ての入力データが本発明システム１に送信される（ステップ＃１４）。尚、本説明では、１回の入力処理で全ての入力項目の入力が完了する場合を想定する。

本発明システム１の入力データ受付部３は、上記入力データを受信し、一時的に入力データを保存する（ステップ＃２２）。

個別手続抽出部４は、上記購買申請手続の申請処理の入力データにより、新規購買案件が起案されたことを認識し、新規の購買案件番号を採番する。引き続き、上記入力データの購買形式と購買品目と購買価額等の購買案件の属性情報から必要な個別手続を抽出する（ステップ＃２３）。例えば、本ケースの説明では、「購買申請手続」、「発注手続」、「検収手続」の３つの個別手続が抽出される場合を想定する。

入力データ受付部３は、上記ステップ＃２３に引き続き、採番された購買案件番号に基づいて、一時的に保存した入力データを正式に、新規の購買案件の購買申請手続の申請処理の入力データ、つまり、購入依頼書データとして、案件データ記憶部７に登録する（ステップ＃２４）。

引き続き、進捗管理部５が、入力データに基づいて、抽出された各個別手続の進捗状況を抽出する（ステップ＃２５）。ここでは、購買申請手続の申請処理の入力データの全ての入力項目の入力が完了しているので、進捗管理部５は、購買申請手続については、「申請中」と判定し、他の抽出された個別手続については、「未作成」と判定する。この場合、購買申請手続の進捗状況が「申請中」であるので、次の発注手続（本ケースでは、見積手続が抽出されなかった場合を想定）は、まだ処理を開始できないため、入力処理の実行待ち状態にない単なる「未作成」状態である。

引き続き、業務案件進捗出力部６が、進捗管理部５による進捗状況の更新、及び、申請者のクライアント端末９と接続状態であることを認識して、図５に示すように、既存の処理中の購買案件に、当該新規の購買案件を１行目に追加した新たな購買案件の一覧表示画面の画面データを生成し、クライアント端末９に送信する（ステップ＃２６）。

クライアント端末９は、受信した購買案件の一覧表示画面の画面データを処理して表示画面上に出力表示する（ステップ＃１５）。申請者は、更新された購買案件の一覧表示画面から、新規に起案した購買案件が正式に登録され、購買申請手続の進捗状態が「申請中」となっていることを確認できる。

尚、上記ステップ＃１３において、１回の入力処理で全ての入力項目の入力が完了しない場合は、入力処理画面上の「保存」ボタンをクリックして、入力処理を中断することができる。この場合、入力された範囲の入力データが本発明システム１に送信される（ステップ＃１４）。

以降、本発明システム１では、ステップ＃２２〜＃２４の処理が実行される。但し、ステップ＃２３において、個別手続を抽出するのに必要な購買案件の属性情報が全て入力されていない場合は、個別手続の抽出処理は行われない。

また、ステップ＃２５において、購買申請手続の申請処理の入力データの全ての入力項目の入力が完了していないので、進捗管理部５は、購買申請手続については、「作成中」と判定し、他の抽出された個別手続については、「未作成」と判定する。従って、ステップ＃２６で作成され、ステップ＃１５で処理される画面データの購買案件の一覧表示画面での、新規購買案件の購買申請手続の進捗状況は「作成中」となる。

ここで、申請者が、一覧表示画面上の当該「作成中」のアイコンをクリックすると、本発明システム１に対して、案件データ記憶部７に保存されている作成中の入力処理画面（購入依頼書）の出力要求を送信する。そして、本発明システム１の入力データ受付部３が、上記出力要求に応答して、案件データ記憶部７に保存されている作成中の入力データを読み出し、上記入力処理画面の画面データを再生し、クライアント端末９に送信する。

同様に、ステップ＃１１で表示された一覧表示画面上に、「作成中」のアイコンが表示されている場合においても、当該「作成中」のアイコンをクリックすると、上記と同様の処理が実行される。

以上の要領で、クライアント端末９の表示画面上に作成中の入力処理画面（購入依頼書）が表示されると、申請者は引き続いて、未入力の入力項目について入力を行い、入力データを完成させることができる。

進捗管理部５は、新規購買案件の購買申請手続の進捗状況が「申請中」であると判定すると、当該購買案件の属性情報（申請者の所属、階級、購買価額等）に応じて、必要な決裁ルートを所定のルールに基づいて抽出し、次の決裁処理の承認者を抽出して、「申請中」の個別手続について、承認者毎の進捗管理を行い、全ての承認者について承認の決裁がなされた時点で、当該個別手続の進捗状況を「決裁済」と判定する。以下、各承認者の個別手続に対する決裁処理（入力処理）について、図６を参照して説明する。以下の説明では、個別手続が購買申請の場合を想定する。

承認者は、クライアント端末９から本発明システム１を起動し、決裁待ちの購買案件の一覧表示画面の出力要求を本発明システム１に送信する（ステップ＃３０）。尚、本発明システム１の起動に当たっては、本発明システム１から承認者の本人確認のためのＩＤとパスワードの入力要求がなされ、当該ＩＤとパスワードを本発明システム１に送信することで、当該承認者に対する決裁待ちの購買案件に対する上記出力要求が実行される。

本発明システム１の業務案件進捗出力部６は、上記出力要求に応答して、上記出力要求の受信時点における承認者が決裁すべき何れかの個別手続の進捗状況が「申請中」となっている決裁待ちの購買案件を、案件データ記憶部７を検索して抽出し、抽出した全ての購買案件を案件別に一覧表示する一覧表示画面（決裁伺画面、図７参照）の画面データをクライアント端末９に出力する（ステップ＃４０）。

クライアント端末９は、受信した決裁待ち購買案件の一覧表示画面（決裁伺画面、図７参照）の画面データを処理して表示画面上に出力表示する（ステップ＃３１）。図７に示すように、決裁伺画面は、１件の決裁待ち購買案件が１行に表形式で表示される。初期画面では、何れかの個別手続（購入申請、見積、発注、検収、経理支出）が決裁待ち状態（申請中）の購買案件が全て列挙される。尚、承認者は、個別手続、申請者、日付等を絞り込み条件或いは並べ替え条件として、一覧表示画面を再構成することができる。承認者は、決裁待ち購買案件を案件別に決裁するために、決裁伺画面の購買案件の案件名をクリックすると、本発明システム１に対して、案件データ記憶部７に保存されている当該購買案件の進捗状況が「申請中」となっている個別案件の決裁処理用の入力処理画面（例えば、購入依頼書）の出力要求を送信する（ステップ＃３２）。そして、本発明システム１の入力データ受付部３が、上記出力要求に応答して、案件データ記憶部７に保存されている申請中の入力データを読み出し、上記入力処理画面の画面データを再生し、クライアント端末９に送信する（ステップ＃４１）。

クライアント端末９は、受信した入力処理画面（例えば、購入依頼書）の画面データを処理して表示画面上に出力表示し、表示された入力処理画面上の決済処理用の入力項目の枠内に、マウスやキーボード等の入力装置を操作して、入力データ（否認や差戻しの場合の理由等）の入力を行い、入力処理画面上の「承認」、「否認」または「差戻し」の何れかのボタンをクリックすると、クリックしたボタンに対応した「承認」、「否認」または「差戻し」も入力データの一部として、本発明システム１に送信される（ステップ＃３３）。

本発明システム１の入力データ受付部３は、上記入力データを受信し、案件データ記憶部７に登録する（ステップ＃４２）。

引き続き、進捗管理部５が、上記入力データに基づいて、当該購買案件の「申請中」となっている個別手続の進捗状況を更新する（ステップ＃４３）。具体的には、上記入力データ中の「承認」、「否認」または「差戻し」を識別し、「承認」であれば進捗状況を「決裁済」に更新し、「差戻し」であれば進捗状況を「未作成」に戻す。また、「否認」の場合は、当該購買案件の登録を削除する。

更に、進捗状況を「決裁済」に更新した場合には、その「決裁済」に更新された個別手続が、「購買申請手続」、「見積手続」または「発注手続」の何れかである場合は、個別手続抽出部４が抽出した後続の個別手続の進捗状況を入力処理の実行待ち状態にある「未作成」（「未作成＋要入力」）と認識する。本ケースでは、当該購買案件は、「購買申請手続」、「発注手続」、「検収手続」の３つの個別手続が抽出されているので、「購買申請手続」と「発注手続」の進捗状況が、夫々「決裁済」と実行待ち状態にある「未作成」（「未作成＋要入力」）に更新される。

引き続き、業務案件進捗出力部６が、進捗管理部５による進捗状況の更新、及び、申請者のクライアント端末９と接続状態であることを認識して、既存の処理中の決裁待ち購買案件から、当該決裁処理済の購買案件を削除した新たな決裁待ち購買案件の一覧表示画面の画面データを生成し、クライアント端末９に送信する（ステップ＃４４）。尚、上記一覧表示画面上に、決裁待ち購買案件と決裁済み購買案件の両方を、決裁待ちと決裁済みの両状態を識別可能に表示している場合は、当該状態が決裁待ちから決裁済みに変更となって表示される。

クライアント端末９は、受信した一覧表示画面の画面データを処理して表示画面上に出力表示する（ステップ＃３４）。承認者は、引き続き決裁処理を行う場合は、更新された決裁待ち購買案件の一覧表示画面上で、上記ステップ＃３２の処理を行い、本発明システム１は、ステップ＃４１〜＃４４の処理を繰り返す。

次に、図８を参照して、本発明システム１を用いて、発注手続における申請者の入力処理（申請処理）について説明する。

申請者は、クライアント端末９から本発明システム１を起動し、購買案件の一覧表示画面（図３参照）の出力要求を本発明システム１に送信する（ステップ＃５０）。尚、本発明システム１の起動に当たっては、本発明システム１から申請者の本人確認のためのＩＤとパスワードの入力要求がなされ、当該ＩＤとパスワードを本発明システム１に送信することで、上記出力要求が実行される。

本発明システム１の業務案件進捗出力部６は、上記出力要求に応答して、上記出力要求の受信時点における申請者の起案した処理中の購買案件の一覧表示画面の画面データを案件データ記憶部７に保存されている入力データを基に作成し、クライアント端末９に出力する（ステップ＃６０）。

クライアント端末９は、受信した購買案件の一覧表示画面の画面データを処理して表示画面上に出力表示する（ステップ＃５１）。申請者は、既に起案済みの購買案件の発注手続の入力処理を行うために、購買案件の一覧表示画面（図３参照）上に表示された発注手続の進捗状況が入力処理の実行待ち状態にある「未作成」（「未作成＋要入力」）のアイコンをクリックして、担当購買の発注手続における申請者の入力処理画面の出力要求を本発明システム１に送信する（ステップ＃５２）。ここで、発注手続における申請者の入力処理画面は、「発注依頼書」の作成画面である。

本発明システム１の入力データ受付部３は、上記出力要求に応答して、上記入力処理画面の画面データを生成し、クライアント端末９に送信する（ステップ＃６１）。

クライアント端末９は、受信した入力処理画面の画面データを処理して表示画面上に出力表示し、表示された入力処理画面上の入力項目の枠内に、マウスやキーボード等の入力装置を操作して、入力データの入力を行う（ステップ＃５３）。全ての入力項目を入力が完了すると、入力処理画面上の「申請」ボタンをクリックすると、全ての入力データが本発明システム１に送信される（ステップ＃５４）。尚、本説明では、１回の入力処理で全ての入力項目の入力が完了する場合を想定する。

本発明システム１の入力データ受付部３は、上記入力データを受信し、発注手続の申請処理の入力データ、つまり、発注依頼書データとして、案件データ記憶部７に登録する（ステップ＃６２）。

引き続き、進捗管理部５が、入力データに基づいて、発注手続以降の各個別手続の進捗状況を更新する（ステップ＃６３）。ここでは、発注手続の申請処理の入力データの全ての入力項目の入力が完了しているので、進捗管理部５は、発注手続については、「申請中」と判定し、後続の検収手続については、「未作成」のままと判定する。この場合、発注手続の進捗状況が「申請中」であるので、次の検収手続は、まだ処理を開始できないため、入力処理の実行待ち状態にない単なる「未作成」状態である。

引き続き、業務案件進捗出力部６が、進捗管理部５による進捗状況の更新、及び、申請者のクライアント端末９と接続状態であることを認識して、当該購買案件の発注手続の進捗状況を「未作成」から「申請中」に更新した新たな購買案件の一覧表示画面の画面データを生成し、クライアント端末９に送信する（ステップ＃６４）。

クライアント端末９は、受信した購買案件の一覧表示画面の画面データを処理して表示画面上に出力表示する（ステップ＃５５）。申請者は、更新された購買案件の一覧表示画面から、発注手続の申請処理が正式に登録され、発注手続の進捗状態が「申請中」となっていることを確認できる。

尚、上記ステップ＃５３において、１回の入力処理で全ての入力項目の入力が完了しない場合は、入力処理画面上の「保存」ボタンをクリックして、入力処理を中断することができる。この場合、入力された範囲の入力データが本発明システム１に送信される（ステップ＃５４）。以降、本発明システム１では、ステップ＃６２〜＃６４の処理が実行される。しかし、ステップ＃６３及び＃６４の処理において、発注手続の申請処理の入力データの全ての入力項目の入力が完了していないので、進捗管理部５は、発注手続については、「作成中」と判定し、ステップ＃６４で作成され、ステップ＃５５で処理される画面データの購買案件の一覧表示画面での、発注手続の進捗状況は「作成中」となる。

申請者が「作成中」の発注依頼書の入力を完成させる処理は、「上述の作成中」の購入依頼書を完成させる処理と同じであるので、重複する説明は省略する。

進捗管理部５は、既存購買案件の発注手続の進捗状況が「申請中」であると判定すると、当該購買案件の属性情報（申請者の所属、階級、購買価額等）に応じて、必要な決裁ルートを所定のルールに基づいて抽出し、次の決裁処理の承認者を抽出して、「申請中」の発注手続について、承認者毎の進捗管理を行い、全ての承認者について承認の決裁がなされた時点で、当該発注手続の進捗状況を「決裁済」と判定する。以下、各承認者の個別手続に対する決裁処理（入力処理）については、図６を参照して説明した通りであるので、重複する説明は割愛する。

承認者による発注手続の入力処理（決裁処理）が完了すると、その決裁内容が「承認」の場合は、当該決裁処理の入力データに基づいて、進捗管理部５が、当該購買案件の「申請中」となっている発注手続の進捗状況を、「決裁済」に更新する。更に、進捗状況が「決裁済」に更新されると、「決裁済」に更新された個別手続が「発注手続」であるので、進捗管理部５は、その後続の検収手続の進捗状況を入力処理の実行待ち状態にある「未作成」（「未作成＋要入力」）と認識する。

以降の検収手続に対する申請者と承認者による各入力処理については、上述の他の個別手続（購買申請手続、発注手続）と同様であるので、重複する説明は省略する。以上の要領で検収手続の進捗状況が「決裁済」となると、以降の支払・経理処理は、例えば経理部門に引き継がれる。以降の支払・経理処理は、本発明システム１の管理対象外であるので、詳細な説明は割愛する。

また、購買形式が「経理支出」の購買案件の場合は、個別手続が経理支出手続だけであるので、上述の「担当購買」の購買案件についての購買申請手続に対する申請者と承認者による各入力処理に関する各処理が、経理支出手続に対する申請者と承認者による各入力処理に関する各処理について妥当するので、重複する説明は省略する。

以下に、別実施形態を説明する。

〈１〉上記実施形態では、本発明システム１は、検収手続までの処理を管理対象としていたが、それ以降の支払・経理処理も管理対象とする統合的な業務案件処理システムとして構成されていても構わない。

また、上記実施形態では、本発明システム１は、各個別手続の入力処理として、申請者による申請処理と承認者による決裁処理の２種類の入力処理を扱う場合を想定したが、進捗状況が「申請中」となった個別手続の決裁ルートに従ったワークフローの管理は、本発明システム１の進捗管理部５ではなく、別の管理システムで行っても構わない。

〈２〉上記実施形態では、業務案件進捗出力部６は、「未作成」のアイコンを、進捗管理部５が入力処理の実行待ち状態にある「未作成」（「未作成＋要入力」）と認識した場合にのみ、購買案件の一覧表示画面上に表示する場合を説明したが、「未作成」のアイコンを、入力処理の実行待ち状態にある「未作成Ａ」とそれ以外の「未作成Ｂ」の２種類を用意し、入力処理の実行待ち状態にない「未作成」状態の個別手続に対しても「未作成」のアイコンを表示するようにしても構わない。また、同じ「未作成」のアイコンを使用して、入力処理の実行待ち状態の場合に、当該「未作成」のアイコンを点滅表示させたり、色彩を変更したりして、入力処理の実行待ち状態であることを、申請者が認識し易くするのも好ましい。

更に、「申請中」の案件が承認者によって差戻しされた場合に、当該案件の進捗状況が「未作成」に戻るが、この場合に、「未作成」のアイコンを「差戻し」によって「未作成」になった「差戻し案件」であることが容易に識別できるように、当該「未作成」のアイコンを他の「未作成」状態と異なる表示形態（点滅表示、色彩変更等）とするのも好ましい。

〈３〉上記実施形態では、進捗管理部５は、新規購買案件の購買申請手続の進捗状況が「申請中」であると判定すると、当該購買案件の属性情報（申請者の所属、階級、購買価額等）に応じて、必要な決裁ルートを所定のルールに基づいて抽出し、次の決裁処理の承認者を抽出して、「申請中」の個別手続について、承認者毎の進捗管理を行う。そこで、業務案件進捗出力部６は、「申請中」の案件が決裁ルート上のどの承認者の段階にあるのかを識別可能に、「申請中」のアイコンの色彩を承認者別に変更する、「申請中」のアイコンのデザインを承認者別に変更する、或いは、「申請中」のアイコンの下または備考欄等に承認者を識別可能な情報を追加表示するのも好ましい。

〈４〉上記実施形態では、「資材購買」、「担当購買」、及び、「経理支出」の３種類の購買形式の購買案件に対して、「資材購買」と「担当購買」の購買案件が起案（購買申請）、見積、発注、検収の個別手続を備え、「経理支出」の購買案件は経理支出手続だけの個別手続を備える場合を想定して説明したが、本発明システム１による進捗管理対象となる業務案件は、上記想定の購買案件に限定されるものではなく、購買形式や個別手続は、上記実施形態以外のものであってもよく、また、業務案件も購買案件に限定されるものではない。

本発明に係る業務案件処理システムの一実施形態を示すブロック構成図 本発明に係る業務案件処理システムの一実施形態における購買申請手続の申請処理の入力画面例を示す図 本発明に係る業務案件処理システムの一実施形態における購買案件の一覧表示画面の一例を示す図 本発明に係る業務案件処理システムの一実施形態における購買申請手続に対する申請者の申請処理に伴う各部の処理手順を示すフローチャート 本発明に係る業務案件処理システムの一実施形態における購買申請手続に対する申請者の入力処理後の購買案件の一覧表示画面の一例を示す図 本発明に係る業務案件処理システムの一実施形態における承認者の決裁処理に伴う各部の処理手順を示すフローチャート 本発明に係る業務案件処理システムの一実施形態における決裁待ちの購買案件の一覧表示画面（決裁伺画面）の一例を示す図 本発明に係る業務案件処理システムの一実施形態における発注手続に対する申請者の申請処理に伴う各部の処理手順を示すフローチャート 従来のワークフローシステムにおける進捗状況の画面表示例を示す図

符号の説明

１： 本発明に係る業務案件処理システム
２： サーバコンピュータ
３： 入力データ受付部
４： 個別手続抽出部
５： 進捗管理部
６： 業務案件進捗出力部
７： 案件データ記憶部
８： コンピュータネットワーク（ＬＡＮ）
９： クライアント端末

Claims (6)

1. 申請者による入力処理を各別に伴う１または複数の一連の個別手続を有する業務案件に対する進捗管理をコンピュータ処理により実行する業務案件処理システムであって、
   前記各個別手続における前記入力処理による入力データを受け付ける入力データ受付部と、
   最初に実行される前記入力処理の前記入力データにより特定される前記業務案件に対して、当該業務案件の所定の属性に基づいて前記１または複数の個別手続を抽出する個別手続抽出部と、
   前記業務案件の前記各個別手続の進捗状況を前記入力データに基づいて抽出する進捗管理部と、
   前記業務案件毎に前記各個別手続を纏めて一覧表示するとともに、前記進捗管理部が抽出した進捗状況を一覧表示された前記個別手続と対応付けて表示する画面データを作成し、所定のコンピュータ端末に出力する業務案件進捗出力部と、
   を備えてなることを特徴とする業務案件処理システム。
2. 前記業務案件進捗出力部は、前記個別手続が複数存在する場合に、当該複数の個別手続の処理順に並べて各進捗状況を表示することを特徴とする請求項１に記載の業務案件処理システム。
3. 前記業務案件進捗出力部は、前記画面データを、前記各個別手続に係る複数の進捗状況を相互に識別可能なアイコンを用いて表示可能に作成することを特徴とする請求項１または２に記載の業務案件処理システム。
4. 前記申請者の使用するコンピュータ端末の表示画面上に前記画面データに基づいて表示された前記アイコンは、前記表示画面上でクリックされることにより、前記アイコンに対応する前記業務案件及び前記個別手続の前記アイコンが示す進捗状況に応じた閲覧または入力画面の表示要求を出力するように構成されていることを特徴とする請求項３に記載の業務案件処理システム。
5. 前記進捗管理部は、前記個別手続の１つが完了した場合に、後続の個別手続が存在するか否かを判定し、後続の個別手続が存在する場合に、当該後続の個別手続の進捗状況を前記入力処理の実行待ち状態として抽出することを特徴とする請求項１〜４の何れか１項に記載の業務案件処理システム。
6. 前記業務案件進捗出力部は、一覧表示する前記業務案件の前記個別手続の中に、進捗状況が前記実行待ち状態である個別手続が存在する場合に、当該個別手続の進捗状況を識別可能に表示する請求項５に記載の業務案件処理システム。

Images