(57)【要約】【課題】システム負荷を増加することなくフレキシブルな処理変更に対応できる業務処理システムを提供することを目的とする。【解決手段】業務処理システムにおいて、業務案件の所定の処理の次の処理のルートを定める書類ルートＤＢ３５６と、業務案件の処理とその処理を実行する処理権限者との関係付けをする書類作成権限ＤＢ３５３と、所定の業務案件の１つの処理を受理すると、書類ルートＤＢ３５６により次の処理を判定し、書類作成権限ＤＢ３５３により次の処理を実行する処理権限者を判定し、所定の業務案件と処理権限者とを関連づけて、案件状態保持ＤＢ３５５に記憶する案件状態判定部３１２と、を有する。このような構成によれば、業務案件の処理を一連の流れとせず、該当する業務案件の次の処理を実行できる処理権限者の候補者を管理しているので、業務処理の手順が変更になっても、フレキシブルに対応することができる。【選択図】図２
2008059185.tif 000002
【特許請求の範囲】
【請求項１】
複数の業務案件の処理状態を管理する記憶部を備え、複数の処理から構成される前記業務案件をそれぞれ管理する業務処理システムであって、
業務案件の所定の処理の次の処理のルートを定める処理ルート情報と、
業務案件の処理とその処理を実行する処理権限者との関係付けをする処理権限者情報と、
所定の業務案件のいずれかの処理を受理すると、この受理した処理と前記処理ルート情報とにより当該業務案件の次の処理を判定し、この判定した次の処理と前記処理権限者情報とにより次の処理を実行する処理権限者を判定し、当該業務案件に関連付けて前記判定した処理権限者を前記記憶部に記憶させて処理状態を更新する案件状態判定部と、を有する
ことを特徴とする業務処理システム。
【請求項２】
所定の処理権限者に該当する業務案件が要求された際、前記記憶部を検索し前記所定の処理権限者に該当する業務案件を抽出する業務案件抽出部を有する
ことを特徴とする請求項１に記載の業務処理システム。
【請求項３】
複数の業務案件の処理状態を管理する記憶部を備え、複数の処理から構成される前記業務案件をそれぞれ管理する業務処理システムの業務処理方法であって、
前記業務処理システムは、処理ルート情報と、処理権限者情報と、案件状態判定部とを備え、
前記処理ルート情報は、業務案件の所定の処理の次の処理のルートを定め、
前記処理権限者情報は、業務案件の処理とその処理を実行する処理権限者との関係付けをし、
前記案件状態判定部は、所定の業務案件のいずれかの処理を受理すると、この受理した処理と前記処理ルート情報とにより当該業務案件の次の処理を判定し、この判定した次の処理と前記処理権限者情報とにより次の処理を実行する処理権限者を判定し、当該業務案件に関連付けて前記判定した処理権限者を前記記憶部に記憶させて処理状態を更新する
ことを特徴とする業務処理方法。
【請求項４】
前記業務処理システムは、業務案件抽出部を備え、
業務案件抽出部は、所定の処理権限者に該当する業務案件が要求された際、前記記憶部を検索し前記所定の処理権限者に該当する業務案件を抽出する
ことを特徴とする請求項３に記載の業務処理方法。
【請求項５】
業務案件の所定の処理の次の処理のルートを定める処理ルート情報と業務案件の処理とその処理を実行する処理権限者との関係付けをする処理権限者情報とを記憶し、複数の業務案件の処理状態を管理する記憶部を備え、複数の処理から構成される前記業務案件をそれぞれ管理する業務処理システムの業務処理プログラムであって、
コンピュータに、
所定の業務案件のいずれかの処理を受理すると、この受理した処理と前記処理ルート情報とにより当該業務案件の次の処理を判定し、この判定した次の処理と前記処理権限者情報とにより次の処理を実行する処理権限者を判定し、当該業務案件に関連付けて前記判定した処理権限者を前記記憶部に記憶させて処理状態を更新する案件状態判定機能を
実現させるための業務処理プログラム。
【請求項６】
コンピュータに、
所定の処理権限者に該当する業務案件が要求された際、前記記憶部を検索し前記所定の処理権限者に該当する業務案件を抽出する業務案件抽出機能を
実現させるための請求項５に記載の業務処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の書類が関与する一連の端末処理を分担して処理する業務処理システムに関し、特に一連の端末処理手順に変更が多い業務に対応する業務処理システム、業務処理方法、及び業務処理プログラムに関する。
【背景技術】
【０００２】
従来の一連の分担処理により業務処理を実行する業務システムを支援する業務処理分担システムでは、通常ワークフロー形式の分担処理が用いられ、複数の書類を作成する複数の担当について、処理内容及び処理順序を予めルートとして設定し、該ルートに基づいて必要な書類を次担当に送付する方式（次担当送付方式）が取られている。
【０００３】
また、業務割当管理方式として、継続不可となった処理を代替的に処理する別の処理ノードを選定する手段を設けて、処理途中から新たなルートを設定することが開示されている（例えば、特許文献１参照）。
【特許文献１】特開２００２−７３６８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
前記次担当送付方式では、ルートの途中で処理が継続できない事象が発生した場合、予め設定した代替ルートに遷移するのが一般的で、そのため１つの案件について複数の処理ルートを設定する必要があり、ルート格納のための記憶媒体が大量に必要になる問題があった。
【０００５】
また、特許文献１に記載されている業務割当管理方式では、継続不可となった事象が発生する度に割当てテーブルを参照して継続可能な端末を選定する処理が発生する。このため、大量の案件を扱い、かつ、一連の業務処理に割り込みが入り処理手順を変更することの多い業務システムにおいては、前記再選定処理がシステム上大きな負荷になってしまい、処理速度が低下するという問題があった。
【０００６】
本発明は、前記の課題を解決するための発明であって、大量かつ処理変更の多い業務処理システムにおいて、システム負荷を増加することなくフレキシブルな処理変更に対応できる業務処理システム、業務処理方法、及び業務処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
前記目的を達成するため、複数の業務案件の処理状態を管理する記憶部を備え、複数の処理から構成される業務案件をそれぞれ管理する業務処理システムであって、業務案件の所定の処理の次の処理のルートを定める処理ルート情報（例えば、書類ルートＤＢ３５６）と、業務案件の処理とその処理を実行する処理権限者との関係付けをする処理権限者情報（例えば、書類作成権限ＤＢ３５３）と、所定の業務案件のいずれかの処理を受理すると、この受理した処理と処理ルート情報とにより当該業務案件の次の処理を判定し、この判定した次の処理と処理権限者情報とにより次の処理を実行する処理権限者を判定し、当該業務案件に関連付けて判定した処理権限者を記憶部に記憶させて処理状態を更新する案件状態判定部（例えば、案件状態判定部３１２）と、を有することを特徴とする。このような構成によれば、業務案件の処理を「一連の流れ」とせず、該当する業務案件の次の処理を実行できる処理権限者の候補者を管理しているので、業務処理の手順が変更になっても、フレキシブルに対応することができる。
【０００８】
また、業務案件の案件内容を管理する案件保持データベース（以下、データベースをＤＢという。）に案件毎の処理ルートを設定せず、業務案件の次の処理内容と処理権限者との関連付けを保持する案件状態保持ＤＢを別に設けている。案件状態保持ＤＢには、案件の状態のみを格納し、前処理が完了したタイミングで、案件状態判定部の機能により「次の処理の処理権限者（複数可）」情報を作成し、案件状態保持ＤＢに格納する。
【０００９】
人が仕事を要求する際に、その仕事要求者の処理権限の属性と案件状態保持ＤＢの情報とを突合せ、処理可能であるか否かを判定する。案件状態保持ＤＢにて、予め処理可能者を絞っておくため、仕事要求者への仕事一覧を抽出するのが高速にできる。なお、案件保持ＤＢ、案件状態保持ＤＢは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）文書ＤＢとするのが好ましい。
【発明の効果】
【００１０】
本発明によれば、大量かつ処理変更の多い業務処理システムにおいて、システム負荷を増加することなくフレキシブルな処理変更に対応できる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施形態について図面を参照して説明する。
図１は、業務処理システムの構成を示すブロック図である。業務処理システムは、申請人端末１０と、担当者端末２０と、サーバ３０とを有している。申請人は、申請人端末１０を利用して申請し、申請された申込書は、サーバ３０に登録される。業務処理の担当者は、担当者端末２０を利用して、サーバ３０に登録された申込書に対して業務処理する。業務処理の対象としては、団体申請、補助金申請、特許申請など各種のものが考えられる。例えば、団体申請の例としては、市役所あるいは区役所などが、社会教育活動やスポーツ活動を行っているグループやサークル、団体が、社会教育関係の施設や学校施設などを利用しやすくなるようにするなど、団体活動を援助するために、団体登録の制度がある。補助金申請としては、国、市役所などから委託を受けた業務に対して、業務内容の実績書類とともに、補助金を申請する制度がある。ここでは、申請人が申請した申込書を、業務処理担当者である予備審査担当者が予備審査し、予備審査完了後、業務処理担当者である本審査担当者が本審査担当する業務処理を業務処理の例として、以下説明する。
【００１２】
申請人端末１０は、処理部１１、通信部１２、出力部１３、入力部１４、及び記憶部１５を有している。担当者端末２０は、処理部２１、通信部２２、出力部２３、入力部２４、及び記憶部２５を有している。また、サーバ３０は、処理部３１、通信部３２、出力部３３、入力部３４、及び記憶部３５を有している。入力部１４，２４，３４は、データや命令などを入力するために用いられるものであり、キーボードやマウスなどで構成される。出力部１３，２３，３３は、端末を利用する人に対して、メッセージなどを表示するために用いられるものであり、ＣＲＴ（Ｃａｔｈｏｄｅ  Ｒａｙ  Ｔｕｂｅ）や液晶ディスプレイなどで構成される。処理部１１，２１，３１は、記憶部１５，２５，３５に格納されたプログラムを実行することで、各構成要素（例えば、通信部１２，２２，３２、入力部１４，２４，３４）を統括的に制御し、様々な演算処理を行う。記憶部１５，２５，３５は、プログラムやデータを永続的に記憶するために用いられるものであり、ハードディスクなどで構成される。通信部１２，２２，３２は、ネットワーク４０を介して、データのやり取りを行うためのインタフェースである。
【００１３】
図２は、サーバのソフトウェア機能を示す機能構成図である。サーバ３０の処理部３１では、申請人又は業務処理担当者が処理した結果を案件保持ＤＢ３５４に格納する処理結果格納部３１１と、業務の案件の状態を判定し案件状態保持ＤＢ３５５に格納する案件状態判定部３１２と、申請人又は業務処理担当者が、処理の状態を把握し処理待ちの仕事の一覧を作成する仕事一覧作成部３１３とを備えている。
【００１４】
記憶部３５には、業務処理担当者のデータベースである担当者ＤＢ３５１と、申請人のデータベースである申請人ＤＢ３５２と、各書類について仕事を行う権利の役職を定義するデータベースである書類作成権限ＤＢ（処理権限者情報）３５３と、業務処理の案件および提出された書類のデータデースである案件保持ＤＢ３５４と、業務の案件の状態を保持するデータベースである案件状態保持ＤＢ３５５と、業務処理の提出される各書類のルートの関係を示すデータベースである書類ルートＤＢ（処理ルート情報）３５６とを有している。各データベースの構造は、図３〜図８にて説明する。
【００１５】
図３は、書類ルートＤＢに記憶される書類ルートを示す説明図である。書類ルートＤＢ３５６には、提出された書類と、次に提出される書類との関係が記憶されている。申請人が、申込書Ｄ０１を提出すると、次に提出される書類として、申込書Ｄ０１の予備審査が合格であったときの予備審査完了書Ｄ３１、申込書Ｄ０１が不備であった場合に申請人に修正依頼するときの修正依頼書Ｄ３５、申込書Ｄ０１の申請内容の変更を届け出るときの変更届け書Ｄ１１、又は申込書Ｄ０１の申請そのものを差し戻すときの差し戻し書Ｄ２１がある。予備審査完了書Ｄ３１が提出されると、次に提出される書類として、申請書内容についての本審査完了書Ｄ３２、又は申込書Ｄ０１が不備であった場合に申請人に修正依頼するときの本審査修正依頼書Ｄ３３がある。本審査修正依頼書Ｄ３３が提出されると、次に提出される書類として、申請人による修正書Ｄ３４がある。修正書Ｄ３４が提出されると、次に提出される書類として、本審査修正依頼書Ｄ３３、又は本審査完了書Ｄ３２がある。
【００１６】
同様に、修正依頼書Ｄ３５が提出されると、次に提出される書類として、申請人による修正書Ｄ３６がある。修正書Ｄ３６が提出されると、次に提出される書類として、予備審査完了書Ｄ３１、修正依頼書Ｄ３５、変更届け書Ｄ１１、又は差し戻し書Ｄ２１がある。
【００１７】
変更届け書Ｄ１１が提出されると、次に提出される書類として、変更届け書Ｄ１１を受理したときの変更届け完了書Ｄ１２、又は変更届け書Ｄ１１が不備であった場合に申請人に修正依頼するときの修正依頼書Ｄ１３がある。修正依頼書Ｄ１３が提出されると、次に提出される書類として、申請人による修正書Ｄ１４がある。修正書Ｄ１４が提出されると、次に提出される書類として、変更届け完了書Ｄ１２、又は修正依頼書Ｄ１３がある。
【００１８】
また、差し戻し書Ｄ２１が提出されると、次に提出される書類として、差し戻し書Ｄ２１を受理したときの差し戻し完了書Ｄ２２、又は差し戻し書Ｄ２１が不備であった場合に申請人に修正依頼するときの修正依頼書Ｄ２３がある。修正依頼書Ｄ２３が提出されると、次に提出される書類として、申請人による修正書Ｄ２４がある。修正書Ｄ２４が提出されると、次に提出される書類として、差し戻し完了書Ｄ２２、又は修正依頼書Ｄ２３がある。
【００１９】
このように、書類ルートＤＢ３５６には、ひとつの書類が提出されると、次に提出されるべき書類のルート（すなわち、処理ルート）が記憶されている。なお、予備審査とは、申請人の氏名、住所、申請人たる資格の有無、申請料の有無などを審査することをいう。また、本審査とは、申請内容が、申請基準内容を満たしているか否かを審査することをいう。
【００２０】
図４は、担当者ＤＢに記憶される担当者情報テーブルを示す説明図である。担当者ＤＢ３５１には、業務処理を行う担当者の担当者ＩＤ３５１ａ、役職３５１ｂ、氏名３５１ｃ、所属コード３５１ｄが記憶されている。具体的には、担当者ＩＤが１００１の担当者は、予備審査担当者であり、氏名がＴ１０１、所属コードがＡ００１であり、担当者ＩＤが１００２の担当者は、予備審査担当者であり、氏名がＴ１０２、所属コードがＢ００１である。また、担当者ＩＤが２００１の担当者は、本審査担当者であり、氏名がＴ２０１、所属コードがＣ００１であり、担当者ＩＤが２００２の担当者は、本審査担当者であり、氏名がＴ２０２、所属コードがＤ００１である。業務案件は、大量の案件が同時並行的に審査されるために、各役職（予備審査担当者又は本審査担当者）に対し、複数の担当者が登録されている。これにより、担当者は、担当者端末２０から、ネットワーク４０を介して、サーバ３０に対して、予備審査完了書Ｄ３１、本審査完了書Ｄ３２、修正依頼書Ｄ３５，Ｄ１３，Ｄ２３、本審査修正依頼書Ｄ３３を、所定のログイン認証を得て、提出することができる。
【００２１】
図５は、申請人ＤＢに記憶される申請人情報テーブルを示す説明図である。申請人ＤＢ３５２には、申請を行う申請人の申請人ＩＤ３５２ａ、役職３５２ｂ、氏名３５２ｃ、連絡先３５２ｄが記憶されている。具体的には、申請人ＩＤが２００６０１０１の申請人は、役職が申請人であり、氏名がＣ００１、連絡先の電話番号が０３−１２３４−５６７８である。また、申請人ＩＤが２００６０１０２の申請人は、役職が申請人であり、氏名がＣ００２、連絡先の電話番号が０６−４３２１−８７６５である。申請人は、予め申請できる申請人として登録されており、申請人ＤＢ３５２に登録されている。これにより、申請人は、申請人端末１０から、ネットワーク４０を介して、サーバ３０に対して、申込書Ｄ０１、修正書Ｄ３４，Ｄ３６，Ｄ１４，Ｄ２４、変更届け書Ｄ１１、差し戻し書Ｄ２１を、所定のログイン認証を得て、提出することができる。
【００２２】
図６は、書類作成権限ＤＢに記憶される書類作成権限情報テーブルを示す説明図である。書類作成権限ＤＢ３５３には、書類名３５３ａ、及び仕事を行う権利のある役職３５３ｂが記憶されている。具体的には、申込書Ｄ０１、変更届け書Ｄ１１、差し戻し書Ｄ２１、及び修正書Ｄ３６，Ｄ３４，Ｄ１４，Ｄ２４は、申請人が作成する書類である。修正依頼書Ｄ３５、変更届け完了書Ｄ１２、及び差し戻し完了書Ｄ２２は、予備審査担当者が作成する書類である。本審査修正依頼書Ｄ３３、及び本審査完了書Ｄ３２は、本審査担当者が作成する書類である。これにより、作成する書類が決まれば、仕事を行う権利のある役職を決定することができ、また、仕事を行う権利のある役職がきまれば、仕事として処理すべき書類を決定することができる。
【００２３】
図７は、案件保持ＤＢに記憶される案件の書類構造を示す説明図である。案件保持ＤＢ３５４には、申請人端末１０及び担当者端末２０から提出された書類が案件毎に記憶されている。案件保持ＤＢ３５４は、ＸＭＬ文書ＤＢである。具体的には、申請人が申込書Ｄ０１を提出すると、「申込書．ｘｍｌ」が、案件保持ＤＢ３５４に記憶される。そののち、「変更届け書．ｘｍｌ」が、提出されると、親書類（図３の書類ルートによって定義されている一つ前の書類）へのリンクとして、「申込書．ｘｍｌ」の識別子ＩＤ１と、先頭書類へのリンクとして「申込書．ｘｍｌ」の識別子ＩＤ１とが、提出された書類に追加されて記憶される。同様に、予備審査担当者が、「予備審査完了書．ｘｍｌ」を提出すると、親書類へのリンクとして、「申込書．ｘｍｌ」の識別子ＩＤ１と、先頭書類へのリンクとして「申込書．ｘｍｌ」の識別子ＩＤ１とが、提出された書類に追加されて記憶される。さらに、本審査担当者が、「本審査完了書．ｘｍｌ」を提出すると、親書類へのリンクとして、「予備審査完了書．ｘｍｌ」の識別子ＩＤ２と、先頭書類へのリンクとして「申込書．ｘｍｌ」の識別子ＩＤ１とが、提出された書類に追加されて記憶される。このように、ひとつの案件に対して、書類ルートに沿って複数の書類が関連付けられて記憶されているので、各案件に対して、提出されている書類の状態を容易に検索することができる。
【００２４】
図８は、案件状態保持ＤＢに記憶される仕事を行う権利のある役職情報テーブルを示す説明図である。案件状態保持ＤＢ３５５には、案件毎の次に仕事を行う権利のある役職が記憶されており、すなわち、案件３５５ａ、及び仕事を行う権利のある役職３５５ｂが記憶されている。具体的には、案件Ａの次に仕事を行う権利のある役職は、申請人及び予備審査担当者であり、案件Ｂの次に仕事を行う権利のある役職は、申請人及び予備審査担当者である。また、本テーブルを参照することにより、仕事を行う権利のある役職が決まれば、該当する案件を検索することができる。なお、申請人には、複数の申請人がいるため、申請人毎（例えば、申請人ＩＤ）により識別されて記憶されている。
【００２５】
次に、各処理について、図９〜図１１を参照して説明する。
図９は、処理結果格納部の処理を示すフローチャートである。処理結果格納部３１１は、書類を受信すると、書類を案件毎に関連付けて案件保持ＤＢ３５４に記憶し、書類を受理したことを案件状態判定部３１２へ送信する機能を有する。すなわち、処理結果格納部３１１は、書類を受信すると（ステップＳ１０１）、その書類が申込書Ｄ０１（先頭書類）か否かを判定する（ステップＳ１０２）。申込書の場合には（ステップＳ１０２，Ｙｅｓ）、案件状態保持ＤＢ３５５に登録する（ステップＳ１０４）。受信された書類には、年月日を含む時刻情報（タイムスタンプ）が付加されて記憶される。タイムスタンプより、各書類の申請日時が登録され、タイムスタンプが申請手続きの手続き期間の管理に利用される。登録完了後、案件状態判定部３１２に書類を送信する（ステップＳ１０５）。その後、書類の受信待ち状態となる。
【００２６】
ステップＳ１０２において、受信した書類が申込書Ｄ０１（先頭書類）でない場合には（ステップＳ１０２，Ｎｏ）、書類を申込書及び親書類へ関連付ける（ステップＳ１０３）。具体的には、図７に示した親書類へのリンク及び先頭書類へのリンクを、受信した書類に追加する。関連付け後、ステップＳ１０４へ進む。なお、処理結果格納部３１１は、大量の案件を処理するため、１つのＣＰＵで高速処理してもよいし、また、複数のＣＰＵによって、複数の案件を同時処理してもよい。
【００２７】
図１０は、案件状態判定部の処理を示すフローチャートである。案件状態判定部３１２は、受信した書類からその案件の処理可能な役職を判定し、案件状態保持ＤＢ３５５を更新する機能を有する。すなわち、案件状態判定部３１２は、処理結果格納部３１１から書類を受信すると（ステップＳ２０１）、受信した書類から、先頭書類の識別番号（例えば、図７のＩＤ１）及び書類名（例えば、予備審査完了書Ｄ３１）を抽出する（ステップＳ２０２）。案件状態判定部３１２は、ステップＳ２０２で抽出した先頭書類の識別番号をキーに、当該案件について提出された書類群を全て抽出し、書類ルートＤＢ３５６に記憶される書類ルートと提出された書類群（受信した書類を含む）とを突き合せることで、次に作成する書類名を検索し、決定する（ステップＳ２０３）。具体的には、図３において、予備審査完了書Ｄ３１を受信した場合には、次に作成する書類名は本審査完了書Ｄ３２及び本審査修正依頼書Ｄ３３となる。次に、案件状態判定部３１２は、書類作成権限ＤＢ３５３から、仕事を行う権利のある役職を判定する（ステップＳ２０４）。具体的には、図６において、本審査完了書Ｄ３２及び本審査修正依頼書Ｄ３３に対する仕事を行う権利のある役職は、ともに本審査担当者である。案件状態判定部３１２は、役職の判定結果を、案件状態保持ＤＢ３５５へ送信する（ステップＳ２０５）。そして、案件状態保持ＤＢ３５５を最新の状態に更新する（ステップＳ２０６）。具体的には、図８において、案件Ａ（図７のＩＤ１に対応）の仕事を行う権利の役職が、申請人及び予備審査担当者から、本審査担当者へ変更される。このように、案件状態判定部３１２は、書類を受信毎に、対象案件の仕事を行う権利のある役職を、最新の状態に更新することができる。
【００２８】
図１１は、仕事一覧作成部の処理を示すフローチャートである。仕事一覧作成部３１３は、仕事を要求する人の役職を判定し、案件状態保持ＤＢ３５５から役職に応じた案件を抽出し、仕事一覧を端末に表示する機能である。ここでは、予備審査担当者を例にして説明する。
【００２９】
予備審査担当者は、担当者端末２０から、担当者ＩＤを入力して、仕事一覧の要求をサーバ３０に対して要求する（ステップＳ３０１）。すると、仕事一覧作成部３１３は、図４に示す担当者ＤＢ３５１から、担当者ＩＤの役職を判定する（ステップＳ３０２）。具体的には、担当者ＩＤ１００１であると、予備審査担当者であると判定できる。役職の判定ができた場合（ステップＳ３０２，Ｙｅｓ）、案件状態保持ＤＢ３５５から該当する役職の担当者が仕事を行う権利のある案件を抽出する（ステップＳ３０３）。具体的には、図８において、予備審査担当者は、案件Ａ及び案件Ｂである。仕事一覧作成部３１３は、抽出した案件を、担当者端末２０の出力部２３に仕事一覧として表示する（ステップＳ３０４）。なお、ステップＳ３０２において、役職が判定できない場合（ステップＳ３０２，Ｎｏ）、担当者端末の出力部２３に、該当する役職でないことを通知する（ステップＳ３０５）。
【００３０】
図１２は、仕事一覧画面の一例を示す説明図である。担当者端末２０の出力部２３には、仕事一覧画面５０が表示され、担当者は、担当者ＩＤ欄５１とパスワード欄５２に入力し、要求ボタン５６を押下すると、氏名欄５３及び役職欄５４に、担当者ＩＤ１００１に該当する氏名Ｔ１０１及び役職である予備審査担当者が表示される。また、案件リスト欄５５には、抽出された案件が出力される。担当者は、仕事一覧の中から処理する案件のチェックボックス５５ａを選択し、選択ボタン５７を押下すると、担当する案件を確保することができる。なお、選択した内容を取り消す場合には、取消しボタン５８を押下するとよい。案件が担当者によって確保されると、他の担当者の仕事一覧には表示されなくなる。確保された案件であるか否かを管理するために、案件状態保持ＤＢ３５５に専用のフラグを追加してもよい。
【００３１】
本発明の業務処理システムについて、具体的例をあげてさらに説明する。
本発明は、案件毎に対して、ワークフローに対して書類の束が送達されるモデルでなく、円卓上に案件が固定され、仕事を行う権利のある人が、案件の状態によって遷移してゆくモデルである。ここでは、以下「円卓モデル」という。
【００３２】
１つの「円卓」には、１つの案件が存在している。円卓上の案件と他の案件には関連性はない。しかし、該当する役職の人はどの円卓の案件でも仕事を行う可能性をもっている。「遷移」とは、ある案件の状態において仕事可能な役職の人が円卓の周りに集合し、案件の状態が変化する（書類が追加される）と、次の書類を作成する役職の人を予め決定しておき、該当する役職の人が仕事を要求したときに円卓の周りに集合することをいう。
【００３３】
以下、円卓モデルを用いて各処理について、図１３〜図１５を参照して説明する。
図１３は、案件Ｘの円卓モデルの遷移を示す説明図である。１つの案件の例として、案件Ｘに対して、円卓６０が置かれ、円卓の状態が変化した場合の状態が示されている。円卓６０の状態１は、申請人Ａにより申込書が提出され、次に仕事を行う権利のある役職が呼ばれた状態を示している。図３の書類ルートに示すように、申込書Ｄ０１の次の書類は、予備審査完了書Ｄ３１、修正依頼書Ｄ３５、変更届け書Ｄ１１、及び差し戻し書Ｄ２１が該当する。各書類の仕事を行う権利のある役職は、図６から求められる。予備審査完了書Ｄ３１、修正依頼書Ｄ３５は、予備審査担当者であり、変更届け書Ｄ１１、及び差し戻し書Ｄ２１は、申請人である。このため、状態１の円卓６０には、申請人Ａと予備審査担当者が呼ばれている。
【００３４】
状態２の円卓６０は、予備審査担当者が仕事を要求し、仕事を確保した状態である。状態２は、円卓６０上に書類の追加はないが、担当者が決定されたので、予備審査担当者が確定した状態である。図においては、確定した役職には、ハッチングして記載している。他の予備審査担当者は、仕事一覧を要求しても、案件Ｘは仕事一覧には含まれない。これは、案件Ｘについて複数の担当者の決定を禁止するための処理である。
【００３５】
状態３の円卓６０は、担当した予備審査担当者が、予備審査完了書を提出し、次に仕事を行う権利のある役職の人が呼ばれた状態を示している。図３の書類ルートに示すように、予備審査完了書Ｄ３１の次の書類は、本審査完了書Ｄ３２及び本審査修正依頼書Ｄ３３である。各書類の仕事を行う権利のある役職は、図６から、本審査担当者と決定される。このため、状態３の円卓６０には、本審査担当者が呼ばれている。なお、ここでは、申請人Ａは、審査中においても、変更届け書Ｄ１１及び差し戻し書Ｄ２１を提出することができるものとしている。
【００３６】
このように、各案件について、円卓上に書類が提出されたり、仕事の担当者が確定されることにより、円卓上の書類内容及び円卓に集合する役職の人の状態を最新の状態にすることができる。
【００３７】
図１４は、案件保持ＤＢ、案件状態保持ＤＢ、及び仕事一覧要求者との関係を示す説明図である。図１４に示すように、案件保持ＤＢ３５４の状態及び仕事一覧要求者については、円卓モデルを使用して説明する。図１４（ａ）は、案件Ａの円卓６１に申込書が提出された状態であり、図１４（ｂ）は、案件Ａの円卓６１に修正依頼書が追加された状態であり、図１４（ｃ）は、案件Ａの円卓６１に修正書がさらに追加された状態である。
【００３８】
図１４（ａ）に示すように、申込書が提出されると、案件保持ＤＢ３５４には、新規の案件として、案件Ａの円卓６１が準備され、申込書が記憶される。案件状態保持ＤＢ３５５には、案件Ａの仕事を行う権利のある役職として、予備審査担当者及び申請人が記憶される。仕事一覧を要求できる人は、円卓６１の周りに申請人と予備審査担当者が集められる。
【００３９】
図１４（ｂ）に示すように、修正依頼書が追加されると、案件保持ＤＢ３５４には、案件Ａの円卓６１に、修正依頼書が申込書と関連付けられて記憶される。案件状態保持ＤＢ３５５には、案件Ａの仕事を行う権利のある役職として、申請人が記憶される。仕事一覧を要求できる人は、円卓６１の周りに申請人だけが集められる。
【００４０】
図１４（ｃ）に示すように、さらに修正書が追加されると、案件保持ＤＢ３５４には、案件Ａの円卓６１に、修正書が申込書及び修正依頼書と関連付けられて記憶される。案件状態保持ＤＢ３５５には、案件Ａの仕事を行う権利のある役職として、申請人と予備審査担当者が記憶される。仕事一覧を要求できる人は、円卓６１の周りに申請人と予備審査担当者が集められる。
【００４１】
このように、書類が提出及び追加されると、処理結果格納部３１１が、案件保持ＤＢ３５４を最新の状態にし、案件状態判定部３１２が、案件状態保持ＤＢ３５５の状態を最新の状態にすることができる。仕事一覧要求者は、仕事一覧作成部３１３により、該当する案件の一覧を検索・閲覧し、仕事を確定することができる。
【００４２】
図１５は、担当者などが仕事を要求するときに該当案件を示す説明図である。通常、案件保持ＤＢ３５４には、大量の案件が保持されており、担当者などが仕事を要求するとき、仕事一覧作成部３１３は、該当する案件を高速で検索する必要がある。案件としては、案件Ａの円卓６１、案件Ｂの円卓６２、・・・・、案件Ｘの円卓６０がある。案件Ａの円卓６１は、申請人Ａにより申込書が提出された状態であり、申請人Ａと予備審査担当者が円卓６１の周りに集められている。案件Ｂの円卓６２は、申請人Ｂに申込書が提出された状態であり、すでに予備審査担当者が確定している。案件Ｘの円卓６０は、申請人Ａによって、申込書が提出され、予備審査完了書も追加された状態であり、申請人Ａと本審査担当者が円卓６０の周りに集められている。このような各案件の状態において、担当者が仕事を要求した場合について説明する。
【００４３】
仕事を要求する人としては、申請人（例えば、申請人Ａ、申請人Ｂ）と、予備審査担当者（例えば、予備審査担当者Ａ、予備審査担当者Ｂ）と、本審査担当者（例えば、本審査担当者Ａ、本審査担当者Ｂ）が該当する。申請人Ａは、仕事一覧を要求すると、案件Ａと案件Ｘが対象案件となる。申請人Ｂは、仕事一覧を要求すると、案件Ｂが対象案件となる。予備審査担当者Ａは、仕事一覧を要求すると、案件Ａが対象案件となる。予備審査担当者Ｂも、仕事一覧を要求すると、案件Ａが対象案件となる。本審査担当者Ａは、仕事一覧を要求すると、案件Ｘが対象案件となる。本審査担当者Ｂも、仕事一覧を要求すると、案件Ｘが対象案件となる。なお、案件Ｂは、すでに担当する予備審査担当者が確定しているため、予備審査担当者Ａ及び予備審査担当者Ｂの対象案件とならない。
【００４４】
このように、仕事を要求する人が、検索要求する前に、最新の円卓状態が、処理結果格納部３１１により案件保持ＤＢ３５４に及び案件状態判定部３１２により案件状態保持ＤＢ３５５に格納されているため、仕事一覧作成部３１３は、高速で対象案件を検索することができる。
【００４５】
本実施形態によれば、業務処理システムは、業務案件の所定の処理の次の処理のルートを定める処理ルート情報（例えば、書類ルートＤＢ３５６）と、業務案件の処理とその処理を実行する処理権限者との関係付けをする処理権限者情報（例えば、書類作成権限ＤＢ３５３）と、所定の業務案件の１つの処理を受理すると、処理ルートにより次の処理を判定し、処理権限者情報により次の処理を実行する処理権限者を判定し、所定の業務案件と処理権限者とを関連づけて記憶部に記憶し処理状態を更新する案件状態判定部（例えば、案件状態判定部３１２）と、を有しているので、システム負荷を増加することなくフレキシブルな処理変更に対応できる。
【００４６】
また、業務処理システムは、所定の処理権限者に該当する業務案件が要求された際、記憶部を検索し所定の処理権限者に該当する業務案件を抽出する業務案件抽出部（例えば、仕事一覧作成部３１３）を有しているので、人が仕事を要求した場合に、高速に要求者の所属権限に対応する業務案件を抽出し、仕事一覧を作成することができる。
【００４７】
本発明の特徴を以下に示す。
（１）大量の案件を扱う業務処理のワークフロー処理において、案件に対応する膨大な数の処理ルートを予め設定・格納する必要がなく、ハード資源を節約できる。
（２）処理ルートの再計算処理を不要とし、次の処理可能者のみを計算することで、システム全体の処理を高速化でき、大量の案件に対応できる。
（３）前記方法をとることにより、フレキシブルな処理変更に対応できる柔軟なワークフローシステムを構築できる。
（４）案件の状態を前処理が終了した際に事前に計算し、人の仕事要求を非同期に計算することで、効率の良い仕事の振分けを行なうことができる。
【００４８】
以上述べた実施形態においては、申請人が申請した申込書を、業務処理担当者である予備審査担当者が予備審査し、予備審査完了後、業務処理担当者である本審査担当者が本審査担当する業務処理を業務処理の例として説明した。本発明は、業務処理のワークフローを固定化するものでない。具体的には、審査方法の変更として、本審査変更後、さらに上位の審査が追加されたとしても、本発明は、フレキシブルに対応することができる。例えば、委員会審査が追加されたとすると、図３に示す書類ルートＤＢ３５６に、本審査の完了書Ｄ３２の次の提出する書類案件を追加する。図４に示す担当者ＤＢ３５１に、委員会審査担当者を追加し、図６に示す書類作成権限ＤＢ３５３に、追加される書類と、その仕事を行う権利のある役職である委員会審査担当者を追加するのみである。このように、業務処理のルート変更、担当者変更、その仕事を行う権利のある役職の変更などがあっても、容易に対応することができる。
【図面の簡単な説明】
【００４９】
【図１】業務処理システムの構成を示すブロック図である。
【図２】サーバのソフトウェア機能を示す機能構成図である。
【図３】書類ルートＤＢに記憶される書類ルートを示す説明図である。
【図４】担当者ＤＢに記憶される担当者情報テーブルを示す説明図である。
【図５】申請人ＤＢに記憶される申請人情報テーブルを示す説明図である。
【図６】書類作成権限ＤＢに記憶される書類作成権限情報テーブルを示す説明図である。
【図７】案件保持ＤＢに記憶される案件の書類構造を示す説明図である。
【図８】案件状態保持ＤＢに記憶される仕事を行う権利のある役職情報テーブルを示す説明図である。
【図９】処理結果格納部の処理を示すフローチャートである。
【図１０】案件状態判定部の処理を示すフローチャートである。
【図１１】仕事一覧作成部の処理を示すフローチャートである。
【図１２】仕事一覧画面の一例を示す説明図である。
【図１３】案件Ｘの円卓モデルの遷移を示す説明図である。
【図１４】案件保持ＤＢ、案件状態保持ＤＢ、及び仕事一覧要求者との関係を示す説明図である。
【図１５】担当者などが仕事を要求するときに該当案件を示す説明図である。
【符号の説明】
【００５０】
１０    申請人端末
２０    担当者端末
３０    サーバ
３１    処理部
３１１    処理結果格納部
３１２    案件状態判定部
３１３    仕事一覧作成部
３５    記憶部
３５１    担当者ＤＢ
３５２    申請人ＤＢ
３５３    書類作成権限ＤＢ
３５４    案件保持ＤＢ
３５５    案件状態保持ＤＢ
３５６    書類ルートＤＢ
４０  ネットワーク
５０  仕事一覧画面
６０，６１，６２  円卓
Ｄ０１    申込書
Ｄ１１    変更届け書
Ｄ１２    変更届け完了書
Ｄ１３，Ｄ２３，Ｄ３５    修正依頼書
Ｄ１４，Ｄ２４，Ｄ３４，Ｄ３６    修正書
Ｄ２１    差し戻し書
Ｄ２２    差し戻し完了書
Ｄ３１    予備審査完了書
Ｄ３２    本審査完了書
Ｄ３３    本審査修正依頼書
【図１】
2008059185.tif 000003
【図２】
2008059185.tif 000004
【図３】
2008059185.tif 000005
【図４】
2008059185.tif 000006
【図５】
2008059185.tif 000007
【図６】
2008059185.tif 000008
【図７】
2008059185.tif 000009
【図８】
2008059185.tif 000010
【図９】
2008059185.tif 000011
【図１０】
2008059185.tif 000012
【図１１】
2008059185.tif 000013
【図１２】
2008059185.tif 000014
【図１３】
2008059185.tif 000015
【図１４】
2008059185.tif 000016
【図１５】
2008059185.tif 000017