JP2002063324A - 集中業務処理装置および方法 - Google Patents

Abstract

(57)【要約】 【課題】 ワークフローシステムの外部から案件を参照
したり、制御する。 【解決手段】 業務フローシステム２０の業務プロセス
には、請求案件情報の代わりに案件特定情報が流され
る。処理対象になる請求案件情報は、業務フローシステ
ム２０から外出し形式で設けられた業務支援データベー
ス２４に格納される。また、請求案件の処理状況が、や
はり外出し形式の案件管理データ記録データベース２６
に格納される。業務プロセスの各ノードでは、案件特定
情報がワークリストサーバ３０のワークリスト送受信箱
に入れられる。これを受けて、アプリケーションサーバ
２８の処理アクティビティが、データベース２４、２６
を対象として、該当ノードの処理を行なう。業務フロー
システムには案件特定情報を流し、処理対象の情報は外
出しデータベースに収めたので、特殊なワークフローシ
ステムを用意せずとも、処理中の案件の参照や制御が容
易にできる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、多数の顧客と契約
関係をもつ企業等に用いられ、契約変更等の業務手続を
処理する集中業務処理装置に関する。本発明は典型的に
は生命保険の業務処理に利用される。

【０００２】

【従来の技術】生命保険契約には、顧客のライフサイク
ルに対応した長い期間にわたって継続するという特色が
ある。この長期間の契約の間には、支払や契約変更など
に関する各種の多様な手続が発生する。こうした契約中
の手続を保全手続という。

【０００３】生命保険会社は多数の顧客を有しており、
大きな生命保険会社の場合、数百万から一千万といった
数の契約をもっている。それら多数の契約で生じる多様
な保全手続の請求案件を確実かつ効率よく処理すること
が求められる。

【０００４】従来の保全手続業務システムの一例では、
業務処理拠点としての支部が全国に分散配置される。各
地域の支部の上に支社が配置され、そして全国の支社が
本社に統括される。これら支部、支社および本社は、分
散系クライアントサーバ型オンラインシステムを利用し
て情報を共有するものの、手続請求案件の書類は物流ベ
ースで回送、処理されている。

【０００５】具体的には、顧客の請求書類は支部で受け
つけられる。支部は、一部の保全手続を処理する権限を
もつ。残りの保全手続の請求書類は、支部から支社へと
物流により回送される。支社は、支部より広範囲の権限
をもつものの、すべての書類の処理はできない。そこ
で、支社でも一部の書類が処理され、残りの書類は本社
に回送される。また、特殊な案件や複雑な案件は、支部
および支社で確実な処理方法を判断できないので、やは
り本社に回送される。

【０００６】本社では、基本的にすべての案件の処理が
可能である。しかし物流で送られてきた書類の中には、
不備のある書類もある。その場合、請求書類は本社から
支社を経て支部へと回送される。そして支部は、顧客と
の応対により書類の不備を解消し、書類を再度本社へ回
送する。

【０００７】

【発明が解決しようとする課題】上記従来のシステムで
は、書類の物流を前提としつつ、処理能力を部分的に支
部および支社に与える分散型システムを採用している。
この分散型システムにより、一部の手続についてのリー
ドタイム短縮が図られている。しかしながら、本社で処
理される請求書類については、請求書類を物流で輸送し
ているために、処理に時間がかかってしまう。そして書
類の不備が本社で発見された場合には、さらに、本社−
支部間の書類往復時間が必要となる。これらの処理時間
は極力短縮することが望まれる。

【０００８】また、請求書類の物流を前提とするシステ
ムでは、書類が回送されるたびに、授受確認および担当
者への仕分けが必要であり、これらハンドリング作業を
極力減らすことが望まれる。

【０００９】さらに、書類物流によるタイムラグの間
に、オンライン情報システム側で、契約のマスターファ
イルが更新される可能性がある。そのため、書類受付の
都度、契約内容を照会するためにオンラインシステムへ
のパンチ入力が必要である。こうした作業負担も軽減す
ることが望ましい。

【００１０】また、書類物流の不利の解消に加えて、業
務処理システムには環境変化に対応する能力が高いこと
が求められる。募集チャネルの拡大、新しい金融商品等
の将来の対応を考慮すると、現行業務のみならず、業務
処理の追加や変更などにも柔軟に対応できるシステムの
提供が望まれる。

【００１１】また、上述したように、保険会社は多数の
保有契約に関して多様な保全手続を行なう。そのため、
書類物流による不利の解消も含めて、１件あたりの業務
・維持コストを削減することが強く望まれる。この点
は、新商品の低ローディング化という流れのうえでも望
まれる。

【００１２】さらに、業務を支部および支社に分散する
形態では、全国に配置される業務職員に対する教育の負
担が大きく、教育コストも大きいという不利があり、こ
うした不利の解消も求められる。

【００１３】このような各種の要求に応えるためには、
データ伝送技術を利用して業務処理を集中化することが
考えられる。請求案件がデータ伝送により多数の拠点か
ら集中業務処理装置に集められて集中的に処理される。

【００１４】コンピュータを用いて業務処理を機械的に
効率よく行なうシステムとしては、ワークフローシステ
ムが知られており、このワークフローシステムを生命保
険会社の保全手続に適用することも考えられる。この場
合、ワークフローシステム内には業務手続のプロセスが
定義される。請求案件のデータは、ワークフローシステ
ムに投入され、ワークフローシステム内で業務プロセス
に沿って請求案件の処理が進められ、処理結果がワーク
フローシステムから出力される。

【００１５】しかし、ワークフローシステムでは、投入
された請求案件のデータに対して請求案件の属性とは無
関係にシステム内で管理番号が採番され、そしてワーク
フローシステムは請求案件のデータを、バイナリデータ
などのかたちでデータタイプを意識することなくシステ
ム内部に抱き込んでしまう。そのため、生命保険の保全
手続のような業務処理に従来一般のワークフローシステ
ムをそのまま適用すると不都合が生じる場合もある。

【００１６】例えば、請求案件の処理中に、拠点から処
理状況が問い合されることがある。しかし、ワークフロ
ーシステムは、投入された請求案件のデータをバイナリ
データなどのかたちで内部に抱き込んでしまう。したが
って、ワークフローシステムは多数の案件の一元管理を
しているものの、個々の請求案件を迅速に検索すること
が困難であり、その結果、拠点からの問合せなどに容易
に対応できない。

【００１７】また、生命保険などでは、長期間の契約を
通じて多様な保全手続が行なわれるので、一の顧客から
複数の請求書類を受け付けることもある。このようなと
き、複数の案件間でデータを共有化したり、処理結果を
引き継ぐ必要が生じることがある。しかし、従来のワー
クフローシステムは、元々、個々の案件を独立して定型
的なプロセスに流すことによって効率的な業務処理を実
現するシステムであり、案件間でのデータ共有などは基
本的には想定していない。したがって上述のような保全
手続で生じる要求には応えにくい。

【００１８】また、請求案件の処理中に、中断等の案件
制御が必要になることがある。しかし、請求案件のデー
タがワークフローシステム内に抱き込まれているため、
システム外部から処理中の案件を制御することが容易で
ない。案件制御を実現しようとすると、案件制御機能を
もつ特別なプロセスをシステム内に設計しなければなら
ない。

【００１９】また、保全手続は複数段階の処理を経る。
各段階の処理の履歴を保存し、統計的に分析すること
は、業務処理のさらなる効率改善のために有用と考えら
れる。しかし、従来のワークフローシステムでは、プロ
セス上の各段階の業務的要素の強い数値、例えば点検漏
れや不備の件数、発生率を採取することができない。

【００２０】上述した各種の要求に応えるために、ワー
クフローシステム自体を大幅に改造し、システム内に特
別なプロセスを設計することも考えられる。しかし、ワ
ークフローシステム自体は極力そのまま利用しつつ、案
件照会機能等を備えることができれば、システムを簡素
化でき、ワークフローシステムのバージョンアップ、機
能拡張や業務処理内容の変更に対する柔軟性も期待でき
る。

【００２１】本発明は上記課題に鑑みてなされたもので
あり、その目的は、ワークフローシステムを利用して業
務処理を行なう装置であって、処理中の案件の照会など
が容易にできる装置を提供することにある。

【００２２】

【課題を解決するための手段】（１）本発明の集中業務
処理装置は、多数の顧客と契約関係をもつ企業等に用い
られ、契約変更等の業務手続の請求案件を処理する。上
記目的を達成するため、本発明の装置は、業務手続を遂
行するための処理を規定する処理ノードを含む業務プロ
セス機能を備え、個々の請求案件を特定する案件特定情
報を前記業務プロセスに沿って進行させる業務フローシ
ステムと、前記業務フローシステムから外出し形式で設
けられ、処理対象になる請求案件情報を格納する業務支
援データベースと、前記業務フローシステムから外出し
形式で設けられ、各請求案件の業務プロセス上での状況
を管理する案件管理データ記録データベースと、前記処
理ノードに位置する案件特定情報が示す請求案件に関し
て、前記処理ノードで規定される処理を前記業務支援デ
ータベースおよび前記案件管理データ記録データベース
に対して行なうアプリケーションである処理アクティビ
ティを備えるアプリケーションサーバと、を含み、前記
業務フローシステムは、前記処理アクティビティによる
処理が終了した請求案件の案件特定情報を、現在の処理
ノードから次の処理ノードへと進める。

【００２３】上述のように、本発明によれば、業務フロ
ーシステム（ワークフローシステム）には、請求案件情
報そのものではなく、請求案件を特定する案件特定情報
が流される。請求案件情報と請求案件の処理状況の情報
は、それぞれ、業務フローシステムから外出し形式で設
けられた業務支援データベースおよび案件管理データ記
録データベースに格納される。そして、業務プロセス上
の各処理ノードでの処理は、これら外出しタイプのデー
タベースに対して行なわれる。

【００２４】業務プロセスに沿った案件特定情報の移動
には、ワークリストサーバが好適に用いられる。ワーク
リストサーバは、業務プロセスの各ノードに対応するワ
ークリスト送受信箱を有する。案件特定情報は、業務プ
ロセス上のある処理ノードに到達すると、その処理ノー
ドに対応するワークリスト送受信箱に入れられる。これ
を受けて、アプリケーションサーバの処理アクティビテ
ィが、送受信箱内の案件特定情報に示される請求案件に
関して、該当する処理ノードで規定される処理を行な
う。この処理は、上記外出し形式のデータベースに対し
て行なわれる。処理アクティビティによる処理が終了す
ると、業務フローシステムが、案件特定情報を業務プロ
セス上の次のノードへと進める。

【００２５】このように本発明によれば、ワークリスト
サーバを利用して、ワークフローシステムには案件特定
情報を流しておき、実際の請求案件の処理は、外出し形
式の業務支援データベースに対して行なわれる。請求案
件の処理中であっても、案件の検索や照会、制御は、ワ
ークフローシステム外のコンポーネントであるデータベ
ース等に対して行なえばよい。したがって、ワークフロ
ーシステムを利用しつつ、処理中の請求案件の検索、照
会や制御が容易にできる。

【００２６】（２）好ましくは、本発明の装置は拠点案
件状況照会手段を含む。この照会手段は、顧客から業務
手続の請求案件を受け付ける拠点に配備され前記集中業
務処理装置と通信可能に接続された端末装置からの照会
請求に応答して、業務支援データベース及び前記案件管
理データ記録データベースに格納された請求案件の状況
情報を照会する。照会結果は前記端末装置に送信され
る。本発明によれば、外出し形式の案件管理データ記録
データベースを利用して、拠点からの処理状況の問い合
わせに容易に応えられる。

【００２７】好ましくは、前記拠点案件状況照会手段
は、前記業務プロセスと同様の形態の拠点案件状況照会
プロセスとして前記業務フローシステムに備えられてお
り、前記業務フローシステムは、前記端末装置から前記
照会請求が送られてきたときに、前記拠点案件状況照会
プロセスを起動する。本発明によれば、ワークフローシ
ステムに拠点案件状況照会プロセスが定義され、このプ
ロセスが起動されると、該当案件の状況が業務支援デー
タベース及び案件管理データ記録データベースから求め
られる。したがって、業務処理に使うワークフローシス
テムを状況照会にも適用することにより、簡素なシステ
ムで機械的に状況照会ができる。

【００２８】好ましくは、前記案件特定情報は案件管理
番号を含み、案件管理番号は、前記拠点端末が請求案件
を処理した処理日および前記拠点端末の属する拠点を特
定する業務単位コードを含み、前記業務支援データベー
スおよび前記案件管理データ記録データベースは前記案
件管理番号に関連づけて各案件の情報を管理し、前記拠
点案件照会手段は、前記端末装置から送られてきた照会
請求に含まれる案件管理番号に基づいて、対応する案件
の状況を照会する。本発明によれば、拠点と共有化しや
すい案件管理番号が特別に設定され、案件の管理や拠点
からの照会に用いられる。通常のワークフローシステム
では、システム内で請求案件が管理できれば十分である
ので、請求案件の属性とは無関係にシステム内で処理番
号の採番が行なわれる。この場合、拠点からの案件照会
請求に対して、該当案件の検索を容易に行なうことが困
難である。これに対し、本態様によれば、上述の適切な
案件管理番号を用いることにより、拠点から集中業務処
理への案件照会の処理が容易に行なえる。

【００２９】また本発明では、前記案件特定情報は証券
番号を含み、前記業務支援データベースおよび前記案件
管理データ記録データベースは前記証券番号に関連づけ
て各案件の情報を管理し、前記拠点案件照会手段は、前
記端末装置から送られてきた照会請求に含まれる証券番
号に基づいて、対応する案件の状況を照会してもよい。
本発明によっても、ワークフローシステムが請求案件の
属性に無関係につくる処理番号を用いるのではなく、証
券番号を用いた結果、拠点から集中事務処理への案件照
会の処理が容易である。

【００３０】ここで、同じ証券番号に対応する幾つかの
請求案件が存在することがあり、証券番号は唯一の請求
案件を特定することはできない。しかし、複数の請求案
件が照会されるといっても、その数は比較的少ない。一
方、証券番号は、状況照会の検索キーとしては非常に使
いやすい。本発明では、唯一の請求案件は特定できない
ものの、十分に少ない数を特定し、かつ、検索用に便利
である証券番号を用いることで、案件照会を容易にして
いる。

【００３１】（３）好ましくは、本発明の装置は別案件
照会手段を含む。別案件照会手段は、一の顧客に関して
複数の請求案件が取得されたときに、一の請求案件の処
理中に、別の請求案件の情報を前記業務支援データベー
スから参照する。例えば、複数の請求案件が印鑑証明書
や戸籍謄本といった付属書類を必要とすることがある。
このようなとき、本発明の別案件照会手段によれば、業
務支援データベースがワークフローシステムの外部にあ
ることを利用して、別案件の付属書類を参照できる。し
たがって、付属書類のデータを重複してもつ必要がな
い。このように、本発明によれば、データベースを外出
しにしたので、案件間のデータの参照、それによるデー
タの共有化や引継ぎができる。

【００３２】（４）好ましくは、本発明の装置は案件制
御手段を含む。案件制御手段は、前記ワークリストサー
バのワークリスト送受信箱に保持される請求案件を対象
とした案件制御処理によって、業務プロセス上の処理中
の請求案件を制御する。本発明によれば、案件処理中は
案件特定情報がワークリスト送受信箱に入れられること
を利用して、処理中であっても案件の制御がワークフロ
ーシステムの外部から容易に行なえる。案件制御は例え
ば中断である。

【００３３】本発明の装置は、前記業務フローシステム
とのインターフェース機能をもち、顧客からの請求案件
に対応する業務プロセス機能を前記業務フローシステム
に起動させるディスパッチャを含み、前記案件制御手段
は、さらに、前記ディスパッチャが保持する請求案件を
対象とした案件制御処理によって、業務プロセスでの処
理前の請求案件を制御してもよい。本発明によれば、デ
ィスパッチャに位置する処理開始前の案件も制御でき
る。

【００３４】本発明の装置は、前記業務プロセスに沿っ
た処理中に請求処理の不備が発見された不備請求案件を
管理する不備管理部を含み、前記案件制御手段は、さら
に、前記不備管理部が管理する不備請求案件を対象とし
た案件制御処理によって、不備管理中の請求案件を制御
する。本発明によれば、不備発生により業務フローから
外されている案件に対する制御もできる。

【００３５】好ましくは、前記案件制御手段は、前記ワ
ークリストサーバ、前記ディスパッチャおよび前記不備
管理部に対して、制御対象の請求案件を示す案件制御要
求を送り、前記ワークリストサーバ、前記ディスパッチ
ャおよび前記不備管理部は、案件制御要求に示される請
求案件を保持する場合に、その請求案件を案件制御要求
に従って処理する。本発明によれば、請求案件が装置内
のワークリストサーバ、ディスパッチャおよび不備管理
部のどこにいたとしても、案件制御を適切に機械的に行
なえる。すなわち、制御対象の案件が、これら構成のど
こかで自動的に制御要求通りに処理される。

【００３６】（５）好ましくは、前記業務支援データベ
ースは、各請求案件情報を、前記業務プロセスの完了後
も所定の一次保存期間にわたって保存する。本発明の装
置は、さらに履歴保存部を含み、履歴保存部は、前記一
次保存期間の経過後、前記一次保存期間より長い所定の
二次保存期間にわたり、前記請求案件情報から抽出され
た処理履歴情報を保存する。本発明によれば、外出し形
式のデータベースを用いて請求案件を処理しているの
で、請求案件の情報を容易に保存でき、さらに必要なデ
ータを抽出して長期間保持しておくこともできる。

【００３７】（６）本発明の態様は、上述した集中業務
処理装置には限定されない。例えば、本発明の別の態様
は、上記集中業務処理装置と拠点に配備された端末装置
を含むシステムである。また本発明の別の態様は、業務
処理方法でもよく、その方法を実現するプログラムを格
納した記録媒体でもよい。

【００３８】

【発明の実施の形態】以下、発明の実施の形態を通じて
本発明を説明するが、以下の実施形態はクレームにかか
る発明を限定するものではなく、又実施形態の中で説明
されている特徴の組み合わせの全てが発明の解決手段に
必須であるとは限らない。

【００３９】図１は、集中業務処理システム１の全体構
成を示している。本実施の形態では、生命保険会社の保
全業務に本発明が適用される。保全業務とは、前述した
ように、支払や契約変更など、契約に関連して発生する
手続の業務をいう。ただし、本発明が保全業務以外の業
務、例えば新規契約業務（顧客とのコンタクト（募集訪
問に関する業務など）および関連する承諾プロセスに適
用されてもよい。また本発明が生命保険以外の業務処理
に適用されてもよい。

【００４０】図１に示すように、集中業務処理装置１０
は、センタ集配サーバ１２を介して拠点端末装置１４と
接続されている。拠点端末装置１４は、全国に分散配置
された生命保険会社の支部等の手続受付窓口に配備され
ている。手続受付窓口は、顧客から保全手続の請求書類
を、印鑑証明や戸籍謄本などの必要付属書類とともに受
け取る。拠点端末装置１４は、書類読取り装置としての
スキャナを有する。請求書類（および付属書類）はスキ
ャナによりイメージデータに変換される。さらに、書類
に記入された文字等は、文字認識機能を用いてコード化
される。これらイメージデータおよびコードデータは、
請求案件情報としてセンタ集配サーバ１２に送られる。
センタ集配サーバ１２は、請求案件情報を集中業務処理
装置１０に受け渡す。集中業務処理装置１０は、受け取
った請求案件情報に基づいた業務処理を行なう。

【００４１】拠点端末装置１４は、営業員等により携帯
される携帯端末でもよい。携帯端末は、支部を経由して
センタと通信してもよく、支部を経由せずにセンタと通
信してもよい。

【００４２】また集中業務処理装置１０は、ホストゲー
トウエイサーバ１６を介して、マスターファイルを格納
するホストシステム１８と接続されている。ホストシス
テム１８は、全部の契約のマスターファイルを保管して
いる。集中業務処理装置１０により業務処理が行なわれ
ると、業務処理にしたがってマスターファイルが書きか
えられる。

【００４３】図２は、集中業務処理装置１０の構成を示
している。業務フローシステム２０は、いわゆるワーク
フローシステム（ワークフローエンジン、ワークフロー
システム本体）の応用である。業務フローシステム２０
には各種の業務プロセスが定義されており、これにより
業務フローシステム２０は各種の業務プロセス機能を備
える。これら業務プロセスのそれぞれは異なる請求案件
に対応している。

【００４４】各業務プロセスは、図示のように複数のノ
ード（四角形）で構成される。業務プロセスに沿って各
ノードの処理を順次実行することにより、請求案件の処
理が達成される。ただし、業務フローシステム２０は、
実際に請求案件情報を処理するのではなく、業務プロセ
スに沿って処理を進行させる役割を持つ。この点につい
ては後述する。

【００４５】ディスパッチャ２２はプロセス起動手段に
相当し、集中業務処理装置１０の外部インターフェース
機能の一部である。ディスパッチャ２２は、業務フロー
システム２０とのインターフェース機能をもつ。ディス
パッチャ２２は、請求案件が取得されたときに、その請
求案件に対応する業務プロセスを業務フローシステム２
２に起動させる。

【００４６】業務支援データベース２４は請求案件情報
を格納している。業務支援データベース２４は、業務フ
ローシステム２０から外出し形式で、つまり別体に設け
られている。請求案件情報は、拠点から送られてきた情
報である。上述のように、請求案件情報は、請求書類の
イメージデータと、イメージデータから得られたコード
データを含む。業務プロセスの各ノードでは、業務支援
データベース２４の請求案件情報が処理対象になる。

【００４７】案件管理データ記録データベース２６は、
各種請求案件の業務プロセス上での状況を管理する。す
なわち、請求案件が業務プロセスのどこまで進んでお
り、どのような状態にあるか、といった情報を管理す
る。この機能の実現のため、案件管理データ記録データ
ベース２６は、装置内の各構成から出力される案件の情
報や状態変化のイベントのデータを受けとって格納す
る。案件管理データ記録データベース２６も、業務支援
データベース２４と同様、業務フローシステム２０から
外出し形式で設けられている。

【００４８】アプリケーションサーバ２８は、業務プロ
セスの各ノードで用いられるアプリケーションソフトを
有している。各ノードでの必要に応じて適当なアプリケ
ーションがクライアント端末等に提供される。

【００４９】ワークリストサーバ３０は、いわゆるメー
ルボックスの機能をもつ。ワークリストサーバ３０は、
業務フローシステム２０と、その外側に位置するアプリ
ケーションサーバ２８との間での、案件に関する情報の
受け渡しに利用される。業務プロセスのノードからノー
ドへの請求案件の移行は、ワークリストサーバ３０を介
して実現される。

【００５０】集中業務処理装置１０はさらに入力支援部
３２、認証・権限管理部３４、案件管理ツール３６、運
用管理部３８を有する。入力支援部３２は、各作業者に
よる入力作業を支援するためのインターフェースを提供
する。認証・権限管理部３４は、各作業者の認証資格や
作業権限を管理する。案件管理ツール３６は、処理中の
案件に対して中断、取消等の割込制御を行なう。運用管
理部３８は、装置内の各部にプログラムを配布したり、
システムの稼働状態を確認するなどの機能をもつ。

【００５１】また集中業務処理装置１０は外部インター
フェース部４０を有する。外部インターフェース部４０
は、前述のディスパッチャ２２のほかに、拠点通知部４
２、不備管理部４４、印刷サーバ４６、ホスト連動サー
バ４８およびホスト・既存運用システムファイル転送部
５０を含む。

【００５２】拠点通知部４２は、センタ集配サーバ１２
を経由し、拠点端末装置１４に対して各種の情報を通知
する。案件照会の応答情報も拠点通知部４２により通知
される。

【００５３】不備管理部４４は、業務プロセスにて請求
書類の不備が発見されたとき、その不備および不備解消
のための情報を管理する。不備を通知する情報が拠点端
末装置１４に送られ、拠点端末１４から不備を解消した
書類のデータを受け取る。

【００５４】印刷サーバ４６は、請求案件情報等の印刷
処理を管理する。ホスト連動サーバ４８は、ホストゲー
トウエイサーバ１６を介したホストシステム１８との連
動を実現する。この機能により、ホスト１８のマスター
ファイルが参照され、請求案件の処理結果がマスターフ
ァイルに反映される。ホスト・既存運用システムファイ
ル転送部５０は入力支援やシステム構成定義などのデー
タ転送機能を有する。

【００５５】その他の構成として、集中業務処理装置１
０は、ＯＳ等の基本ソフト５２および運用基本ソフト５
４をもつ。また、作業者が操作するクライアント端末の
ための構成として、アプリケーションクライアント５
６、クライアント基盤５８およびＯＳ等の基本ソフト６
０が用意されている。図１には示されないが、多数の作
業者、すなわち多数のクライアント端末により業務作業
が行なわれる。

【００５６】次に、図３を参照し、業務フローシステム
２０、ディスパッチャ２２、業務支援データベース２
４、案件管理データ記録ベース２６、アプリケーション
サーバ２８およびワークリストサーバ３０の機能と関係
を説明する。

【００５７】図３には、業務フローシステム２０に関連
して典型的な業務プロセスの一例が示されている。業務
プロセスは、振分（ホスト照会）ノード、点検ノード、
二次点検ノード、認証ノードおよびホスト処理（マスタ
ーファイル更新）ノードを有する。振分ノードおよびホ
スト処理ノードでは業務処理装置により機械的（自動）
処理が行われる。点検ノード、二次点検ノードおよび認
証ノードでは、担当者が端末装置を操作して業務処理を
行う。

【００５８】振分ノードでは、拠点から入手した請求案
件情報（コードデータ）を基に、ホストシステムに対す
るオンライン照会が自動的に行われ、マスターファイル
から業務処理に必要なデータが取り込まれる。また、図
では省略されているが、プロセス中の適当なノードへと
請求案件を振り分ける処理が行われる。点検ノードでは
基本的点検作業が行なわれる。基本的点検作業は、請求
書イメージと入力項目との照合、必要書類の点検などで
ある。二次点検では、点検者の修正入力に対する相互点
検（内部牽制的な意味合い）、認証では、高額支払など
の手続内容に応じた要件の確認および決済が行われる。
ホスト処理は最終的な更新処理であり、ホストシステム
に格納されたマスタファイルに対して自動的（機械的）
な更新処理が行われる。

【００５９】図３の業務プロセスに対応する請求案件が
センタ集配サーバ１２から集中業務処理装置１０に提供
されたとする。このとき、ディスパッチャ２２は、請求
案件を識別し、その請求案件に対応する図３の業務プロ
セスを業務フローシステム２０に起動させる。

【００６０】業務プロセスが起動すると、業務フローシ
ステム２０は、処理すべき請求案件を、最初のノードで
ある振分ノードに進める。請求案件が、プッシュ形式で
ワークリストサーバ３０のワークリスト送受信箱に入れ
られる。

【００６１】ここで、請求案件情報（イメージおよびコ
ード）自体は、業務支援データベース２４に格納されて
おり、業務プロセス上では動かない。業務プロセス上を
移動するのは、主として請求案件を特定するための情報
である。そこで、本実施の形態では、プロセスに沿って
ノードおよびワークリストサーバを移動する情報を、案
件特定情報と呼ぶ。

【００６２】案件特定情報が最初のワークリストサーバ
に入ったことを受けて、アプリケーションサーバ２８で
は、アプリケーションである振分アクティビティが機能
する。請求案件に対応するマスタファイルが、ホストシ
ステム１８に対して照会され、必要なデータが取り込ま
れ、業務支援データベース２４の請求案件情報に与えら
れる。この処理は上述のように自動的に行われる。

【００６３】振分ノードの処理が終わると、処理の終了
が分かるように、ワークリストサーバ内の情報が振分ア
クティビティにより書き換えられる。例えば、処理終了
を示すフラグが立てられたり、マークが付けられる（後
のノードでも同様）。これに応えて、業務フローシステ
ム２０は、案件特定情報を、振分ノードのワークリスト
送受信箱から、点検ノードのワークリスト送受信箱へと
移動させる。

【００６４】点検ノードの作業担当者は、クライアント
端末を操作して、ワークリスト送受信箱内の案件特定情
報により特定される請求案件を点検する。これは、アプ
リケーションサーバ２８から提供されるアプリケーショ
ンを用いた点検アクティビティにより実現される。点検
処理は、業務支援データベース２４内の請求案件情報を
用いて行なわれる。また、点検が行なわれたことを示す
情報は、請求案件の状況情報として、案件管理データ記
録データベース２６に記録される。

【００６５】業務フローシステム２０は、点検ノードの
ワークリスト送受信箱内にある請求案件の処理が終了す
ると、請求案件特定情報を、点検ノードのワークリスト
送受信箱から、二次点検ノードのワークリスト送受信箱
へと移動させる。これにより業務プロセスが二次点検ノ
ードへと移行する。

【００６６】二次点検ノードおよび認証ノードでも、点
検ノードと同様に、外出しの業務支援データベース２４
および案件管理データ記録ベース２６に対して、アプリ
ケーションサーバ２８のアプリケーションを用いた処理
が行なわれる。ただし、各ノードでは、異なる作業担当
者により作業が行なわれる。

【００６７】認証ノードの処理が完了すると、案件特定
情報は、ホスト処理ノードのワークリスト送受信箱へと
移される。これに応えて、アプリケーションサーバ２８
側でホスト処理アクティビティが機能する。ホストシス
テム１８にアクセスして、請求案件の処理結果をマスタ
ーファイルに反映する更新処理が行われる。業務フロー
システム２０は、ホスト処理の送受信箱内にある案件の
処理が終了すると、その案件についての業務プロセスを
終了させる。

【００６８】以上、図３を参照して、本実施の形態にお
ける基本的な業務処理の流れを説明した。

【００６９】なお、案件特定情報とともに、請求日時等
の幾つかの情報がプロセス上を移動してもよい。これら
情報は、ワークリスト送受信箱の内容を表示するときな
どに便利に用いられる。

【００７０】また、図３の業務プロセスは、業務フロー
システム２０に用意された複数の業務プロセスの一つで
ある。本実施の形態では、図４に示す各種の業務プロセ
スが用意されている。これらの中には、図３に示される
ように振分、点検、二次点検、認証およびホスト処理で
構成されるものもあり、それ以外のノードをもつものも
ある。また、図４に示されるように、業務プロセスは、
支払、契約変更および汎用に大別される。汎用は、集中
処理装置または拠点からの要求により案件内容を照会す
るため等、業務を特定しないプロセスである。その他、
これら業務プロセスのほかに、後述するように、複合処
理案件および同時処理案件を判定するための判定プロセ
スが業務フローシステム２０に用意されている。

【００７１】また、集中業務処理装置１０には、全国の
支社から次々と多数の請求案件が送られ、それら請求案
件に対応する業務プロセスが起動される。したがって、
図３の業務プロセス上を幾つもの請求案件が移動してい
く。

【００７２】図５は、集中業務処理装置１０で用いられ
る業務処理作業用の画面の一例である（図面では、請求
書類のイメージ等は部分的に省略および簡略化されてい
る、以下同じ）。図５には、図３の点検ノードで端末上
に表示される画面が示されている。画面の左半部には、
顧客により記入された請求書類のイメージが表示されて
いる。また画面の右半部には、イメージデータから文字
認識機能により読み取られたコードデータ、および、そ
のデータを基にホストシステムのマスタ−ファイルを照
会した結果が表示される。点検作業者は、両者を見比べ
て相違の有無を点検する。

【００７３】図６は、図３の一部を抜き出すとともに一
般化した図面である。図６を参照し、本発明の基本的な
原理とその利点を説明する。

【００７４】まず、従来一般のワークフローシステムを
生命保険の保全手続に適用することを考える。生命保険
会社では、多様な保全手続が大量に処理される。そし
て、処理中の案件の状況を拠点から照会されることがあ
り、また、処理中の案件を中断するといったような案件
制御が必要になる。しかし、従来のワークフローシステ
ムをそのまま適用しても、以下に説明するように、この
ような事情に容易に対応できない。

【００７５】すなわち、従来のワークフローシステムで
は、処理対象のデータ自体がワークフローシステムに投
入される。ワークフローシステムでは、投入された請求
案件のデータに対して請求案件の属性とは無関係にシス
テム内で管理番号が採番され、そしてワークフローシス
テムは請求案件のデータを、バイナリデータなどのかた
ちでデータタイプを意識することなくシステム内部に取
り込む。そしてワークフローシステムは、取り込んだ請
求案件データを、定義されたプロセスに沿って移動させ
る。ワークフローシステムはブラックボックスのような
一面をもっており、処理対象のデータはシステム内に抱
き込まれ、処理結果がシステムから出力される。したが
って、ワークフローシステム内の処理中のデータを迅速
に外部から参照したり、制御することが困難である。

【００７６】一方、図６（および図３）に示されるよう
に、本発明のシステムでは、業務フローシステム２０の
業務プロセスには、請求案件情報そのものではなく、請
求案件を特定する案件特定情報が流される。請求案件情
報は、業務フローシステム２０から外出し形式で設けら
れた業務支援データベース２４に格納される。また、請
求案件の処理状況の情報も、業務フローシステム２０か
ら外出し形式で設けられた案件管理データ記録データベ
ース２６に格納される。そして、業務プロセス上の各処
理ノードでの処理は、これら外出しタイプのデータベー
スに対して行なわれる。

【００７７】業務プロセスに沿った案件特定情報の移動
には、ワークリストサーバ３０が好適に用いられてい
る。ワークリストサーバ３０は、業務プロセスの各ノー
ドに対応するワークリスト送受信箱を有する。案件特定
情報は、業務プロセス上のある処理ノードに到達する
と、その処理ノードに対応するワークリスト送受信箱に
入れられる。ワークリスト送受信箱内のリストに案件特
定情報が書き加えられる。

【００７８】これを受けて、アプリケーションサーバ２
８の処理アクティビティが、送受信箱内の案件特定情報
に示される請求案件に関して、該当する処理ノードで規
定される処理を行なう。

【００７９】図６に例示するように、案件特定情報Ａ
が、処理ノードＢに対応するワークリスト送受信箱Ｃの
ワークリストに書き加えられたとする。処理ノードＣを
担当する作業者は、クライアント端末を操作して、処理
アクティビティＤを利用している。ワークリストへの案
件特定情報Ａの追加を受けて、処理アクティビティＤを
用いた処理が作業者により行なわれる。

【００８０】このとき、処理アクティビティＤは、案件
特定情報Ａにより、処理対象の請求案件を特定する。こ
の請求案件の情報は業務支援データベース２４に、処理
状況情報は案件管理記録データベース２６に格納されて
いる。処理アクティビティＤは、これらのデータベース
を対象として上述の点検等の処理を行なう。

【００８１】処理アクティビティＤは、請求案件の処理
が終了すると、処理終了を示す情報をワークリスト送受
信箱内のワークリストに書き込む。この情報は、案件特
定情報Ａの部分に書き込まれる。これを受けて、業務フ
ローシステム２０は、案件特定情報Ａをワークリストか
ら抜き取り、次の処理ノードのワークリスト送受信箱へ
と送る。

【００８２】このように本発明によれば、ワークリスト
サーバを好適に利用して、ワークフローシステムには案
件特定情報が流される。実際の請求案件の処理は、外出
し形式のデータベースに対して行なわれる。請求案件の
処理中であっても、案件の検索や照会、制御は外出しの
データベースやワークリストサーバといった幾つかのコ
ンポーネントに対して行なえばよい。したがって、ワー
クフローシステムを利用しつつ、処理中の請求案件の検
索、照会や制御が容易にできる。ワークフローシステム
に特別に参照機能を備えるといったようなワークフロー
システム自体の変更が極力抑えられており、従来のワー
クフローシステムを応用した簡単な構成により、案件の
照会や制御が可能となる。

【００８３】次に、上記のデータベースをワークフロー
システム外部に設けたシステムを応用する幾つかの実施
形態を説明する。

【００８４】 [１−１] 案件状況照会（ワークフロー端末）

【００８５】本実施の形態では、集中業務処理装置１０
内のクライアント端末により案件状況が照会される。こ
の機能は、図１の案件管理ツール３６により実現され
る。

【００８６】図７は、案件管理ツールによりクライアン
ト端末に提示されるメニュー画面を示している。案件状
況を照会するときは、案件検索が選択される。

【００８７】図８は、案件検索が選択されたときに表示
される画面である。案件検索では、検索キーとして案件
管理番号が用いられる。端末操作者により、照会すべき
案件の管理番号が入力される。

【００８８】ここで、案件管理番号は、本発明の案件特
定情報の一形態である。案件管理番号は、以下の請求案
件の３つの属性を合成したものである。すなわち、案件
管理番号は、（１）拠点端末の処理日、（２）事務単位
コード（申請組織、業務単位コードの一形態）および
（３）処理番号で構成される。処理日は、基本的には請
求案件を受け付けて電子データに変換し、集中業務処理
装置へ送った日である。事務単位コードは、請求案件を
受け付けた拠点を特定するコードである。事務単位コー
ドの上位３桁は部門、支社を特定し、下位４桁は配下の
組織を特定する。処理番号は、（１）の処理日における
処理順番（連番、何番目に処理されたか）である。

【００８９】本実施の形態では、業務支援データベース
２４および案件管理データ記録データベース２６をはじ
め、システム全体において、請求案件は上記案件管理番
号によって管理される。

【００９０】図９は、案件検索が選択されたときに表示
されるもう一つの画面である。ここでは、検索キーとし
て証券番号が用いられる。端末操作者により、照会すべ
き案件の証券番号が入力される。

【００９１】図１０は、案件管理番号または証券番号が
入力されたときに表示される画面である。案件管理ツー
ル３６は、案件管理番号または証券番号に基づいて、案
件管理データ記録データベース２６を検索し、該当案件
の状況情報を取得し、クライアント端末の画面上に提示
する。

【００９２】図１１は、案件管理ツール３６により提供
されるもう一つの画面である。この画面は、図７のメニ
ュー画面で「未処理案件一覧」が選択されたときに表示
される。案件管理ツール３６は、案件管理データ記録デ
ータベース２６内から未処理案件を検索する。検索され
た案件のリストが作成され、画面に表示される。その
他、図７のメニュー画面中には、「保留案件一覧」「機
会ノード状況一覧」および「中断案件一覧」といったボ
タンが設定されている。これらのボタンが操作されたと
きも、案件管理ツール３６により該当案件が検索され、
リストが表示される。

【００９３】[１−２] 拠点案件状況照会（拠点端末）

【００９４】本実施の形態では、案件状況が拠点端末に
より照会される。本実施形態によれば、ワークフロー環
境をもたない端末からでも容易かつ迅速に案件状況を照
会できる。

【００９５】拠点に対して顧客から案件処理の進捗状況
が問い合わされたとする。拠点では端末装置１４が操作
され、案件状況照会画面が表示される。この照会画面に
て、案件管理番号（証券番号でもよい、以下同じ）が入
力される。端末装置１４は、案件管理番号を含む案件状
況照会請求を、センタ集配サーバ１２を介して集中業務
処理装置１０へと送る。この案件状況照会請求の送信
は、通常の保全手続における請求案件の送信と同様に行
なわれる。

【００９６】集中業務処理装置１０は、案件状況照会請
求を取得すると、該当案件の状況を案件管理データ記録
データベース２６より検索し、端末装置１４へ送り返
す。本実施形態では、以下に説明するように、この検索
処理に、業務フローシステム２０を活用する。

【００９７】拠点から送られた案件状況照会請求は、集
中事務処理装置１０のディスパッチャ２２により取得さ
れる。ディスパッチャ２２は、案件状況照会請求を取得
すると、業務フローシステム２０に拠点案件状況照会プ
ロセスを起動させる。

【００９８】図１２は拠点案件状況照会プロセスを示し
ている。このプロセスは、他の業務処理用のプロセスと
同様に業務フローシステム１０内に予め定義されている
（図４においては、拠点案件状況照会プロセスは「汎
用」に分類されている）。

【００９９】拠点案件状況照会プロセスによる処理動作
は、他の業務処理用のプロセスと同じである。すなわ
ち、ワークリストサーバおよびアプリケーションサーバ
が機能する。

【０１００】図１２のプロセスが起動されると、案件管
理番号がプロセス上を移動する。案件管理番号は振分ノ
ード（全プロセス共通に設定）を経て、ログ検索処理ノ
ードに到達し、該当するワークリスト送受信箱に入れら
れる。これを受けて、アプリケーションサーバのログ検
索処理アクティビティ（図示せず）が業務支援データベ
ース２４、案件管理データ記録データベース２６から、
案件管理番号で特定される案件の状況を検索する。

【０１０１】本実施の形態では、案件状況を含む案件情
報が業務支援データベース２４に、処理の過程で発生し
たログ情報が案件管理データ記録データベース２６に記
録されている。ログ検索処理アクティビティは、業務支
援データベース２４、案件管理データ記録データベース
２６を検索することによって案件状況を取得する。取得
された状況情報は、外部インターフェース部４０の拠点
通知部４２へと送られる。そして状況情報は、拠点通知
部４２からセンタ集配サーバ１２を介して端末装置１４
へと送られる。

【０１０２】ログ検索処理アクティビティは、照会処理
が終了すると、その旨をワークリストサーバに書き込
む。これを受けて、業務フローシステム２０が案件特定
情報をワークフロー終了処理ノードへ進め、ここでの処
理により拠点案件状況照会プロセスが終了する。

【０１０３】以上に説明したように、本実施形態によれ
ば、外出し形式の業務支援データベース、案件管理デー
タ記録データベースを利用して、集中事務処理装置内だ
けでなく、拠点からの処理状況の問合せに容易に応えら
れる。

【０１０４】また本実施の形態によれば、ワークフロー
システムに拠点案件状況照会プロセスが定義され、この
プロセスが起動されると、該当案件の状況が業務支援デ
ータベース、案件管理データ記録データベースから求め
られる。業務処理に使うワークフローシステムを状況照
会にも適用することにより、簡素なシステムで機械的に
状況照会ができる。

【０１０５】また本実施の形態では、検索キーが全シス
テムにてユニークであり、かつ、検索キーは、拠点の処
理日や、拠点を特定する業務単位コード、証券番号とい
った業務の基本となるコードに基づいてつくられてい
る。このような拠点および集中業務センタで把握しやす
い番号を用いているので、集中業務処理センタでの自発
的な案件状況照会、および、拠点からの電話問合せによ
る集中業務処理センタでの案件状況照会に迅速に対応で
き、さらには拠点からの照会も容易である。

【０１０６】ここで、通常のワークフローシステムで
は、システム内で請求案件が管理できれば十分であるの
で、請求案件の属性とは無関係にシステム内で処理番号
の採番が勝手に行なわれる。この場合、拠点からの案件
照会請求に対して、該当案件の検索を容易に行なうこと
が困難である。これに対し、本発明によれば、上述の適
切な案件管理番号を用いることにより、案件照会の処理
が容易に行なえる。

【０１０７】さらに、証券番号については、同じ証券番
号に対応する幾つかの請求案件が存在することがあり、
証券番号は唯一の請求案件を特定することはできない。
しかし、複数の請求案件が照会されるといっても、その
数は比較的少ない。一方、証券番号は、状況照会の検索
キーとしては非常に使いやすい。本発明では、唯一の請
求案件は特定できないものの、十分に少ない数を特定
し、かつ、検索用に便利である証券番号を用いること
で、案件照会を容易にしている。

【０１０８】[２] 案件間の情報参照（情報共有化）

【０１０９】本実施の形態では、業務支援データベース
がワークフローシステムの外部に設けられていることを
利用して、複数の案件間での情報の共有化を実現する。
この機能は、複合処理案件や同時処理案件の処理に好適
に適用される（ただし限定はされない）。 ＜複合処理案件および同時処理案件の処理の概要＞

【０１１０】ここではまず、複合処理案件および同時処
理案件について説明する。一の顧客から複数の請求書類
が受けつけられることがあり、そうした複数案件の中に
は、複合処理案件および同時処理案件が含まれる。複合
処理案件とは、互いに依存関係があって決められた順序
に従って処理されるべき複数案件であり、すなわち、一
の請求案件の後に別の請求案件を処理すべき複数案件で
ある。また同時処理案件は、依存関係のない複数案件で
あって、業務効率の観点からも同時に併行して処理され
るべき複数案件である。本システムは、以下に説明する
ように、通常のワークフロー製品には実装されていな
い、こうした複合処理案件および同時処理案件を関連付
けて実行、管理する機能を備える。

【０１１１】図１３は、複合処理案件および同時処理案
件を自動的に判別するための複合同時判定プロセスを示
す。この複合同時判定プロセスは、上述した業務プロセ
ス群と同様の形態を有し、業務フローシステム２０に備
えられている。

【０１１２】ディスパッチャ２２は、一の顧客に関して
一の請求案件が取得されたときには（単独案件）、その
請求案件に対応する業務プロセスを直接的に起動する。
一方、ディスパッチャ２２は、一の顧客に関して複数の
請求案件が取得されたときには、図１３の複合同時判定
プロセスを起動する。

【０１１３】なお、複数の請求案件には、同じ契約に関
する複数案件と、別契約に関する複数案件が含まれる。
後者は、例えば、顧客本人の契約変更手続と、その家族
の契約の変更手続である。

【０１１４】図１３の複合同時判定プロセスでは、一顧
客の複数請求は、まず機械判定ノードに進められ、機械
判定ノードのワークリスト送受信箱に入れられる。アプ
リケーションサーバ２８から提供される機械判定アクテ
ィビティは、複合同時判定テーブルを用いて、複数請求
案件が(i)複合処理案件、(ii)同時処理案件および(iii)
その他の例外案件のいずれに属するかを判定する。判定
処理では、証券番号、処理コードなどの請求案件を特定
する情報が用いて判定テーブルが参照される。

【０１１５】機械判定アクティビテイは、判定結果を業
務支援データベース２４に記録する。業務支援データベ
ース２４には管理フォルダが設けられる。この管理フォ
ルダを用いて、互いに複合関係および同時関係にある案
件が紐付け管理される。管理フォルダには、案件管理番
号、証券番号、業務コード、複合同時区分、同時状況区
分、複合状況区分、複合順序、フォルダ番号などのデー
タを書き込むことができる。

【０１１６】図１４〜図１６は、複合同時判定テーブル
の例を示している。図１４は、複合処理案件に分類され
るべき請求案件の組合せを示し、図１５は、同時処理案
件に分類されるべき請求案件の組合せを示し、図１６
は、例外案件に分類されるべき請求案件の組合せを示し
ている。例外には、特殊な案件（組合せ）が含まれ、同
じ請求書類の二重投入のような入力ミスも含まれる。

【０１１７】図１４〜図１６のそれぞれにおいて、「同
一契約」と「別契約」の２つのテーブルが示されてい
る。「同一契約」とは、同じ契約に対する複数の請求案
件であり、「別契約」とは、それぞれ別の契約に対する
複数の請求案件であり、例えば顧客本人の契約と家族の
契約についての請求案件である。

【０１１８】また、図１４〜図１６では、２つの案件の
組合せについての判定テーブルが示されている。これに
対し、３つ以上の案件の組合せについても判定可能なよ
うにテーブルを構成してもよい。また、３つ以上の案件
の組合せに関する判断は、後述する人判定に委ねられて
もよい。

【０１１９】また実際のシステムでは、複合同時判定テ
ーブルは、図１４〜図１６のうちの２種類のテーブルで
構成することも好適である。好ましくは、複合同時判定
テーブルが、図１４の複合判定テーブルと図１６の例外
判定テーブルにより構成される。これらテーブルに入ら
ない案件の組合せは同時処理案件と判断される。

【０１２０】さらに、上記の２種類のテーブルは、３つ
以上の案件組合せの判定に際しては以下のように用いら
れてよい。３以上の案件から任意の２案件のペアをつく
る。すべてのペアが図１４および図１６に該当しないと
き、全案件を同時処理対象とする。そうでない場合は、
人判定等を適用に用いて、複合または例外処理とする。

【０１２１】図１３に戻り、機械判定アクティビティの
処理が終了すると、業務フローシステム２０は、請求案
件（請求案件のセット）の案件特定情報をワークフロー
起動ノードへと進め、ワークフロー機能ノードのワーク
リスト送受信箱へと請求案件を入れる。また、一部の特
定の請求案件は、機械判定ノードから人判定ノードへと
進められる。

【０１２２】人判定ノードに進む請求案件は、複合また
は同時と判定された請求案件であって、名義変更等の特
定の人判定処理を含む案件である。人判定に進むべき請
求案件も予め定められている。

【０１２３】人判定ノードでは、作業者により複合・同
時判定が行われる。ここでは、人判定アクティビティに
より、作業者に対して、請求案件がどのように処理され
るべきか（複合・同時）が問い合わされる。作業者が端
末を使って判定を入力する。入力された判定に従って案
件管理フォルダが作成される。機械判定ノードで複合ま
たは同時と判定された案件であっても、例外案件にまわ
されることもある。

【０１２４】また、３つ以上の請求案件が取得されたと
きには、同一契約の案件と別契約の案件とが混在する場
合がある。例えば、顧客本人の一契約に対する２つの請
求案件および顧客の家族の契約に対する１つの請求案件
といった組合せが考えられる。このような混在型の請求
案件も人判定ノードに送られる。人判定ノードでは、作
業者により複数の請求案件が適当に分割され、分割後に
複合、同時等の判定が加えられる。

【０１２５】上記の人判定ノードの処理が終了した請求
案件は、業務フローシステム２０によりワークフロー起
動ノードへと進められる。請求案件がワークフロー起動
ノードに進んでワークリスト送受信箱に入ると、ワーク
フロー起動アクティビティにより、ディスッチャ２２に
対して、請求案件に対応する業務プロセスの起動が指示
される。

【０１２６】ディスパッチャ２２は、起動指示を受け
て、請求案件の組合せに対応する複数の業務プロセスを
起動する。起動の際、ワークフロー起動アクティビテイ
により業務支援データベース２４の案件管理フォルダに
格納された複合、同時判定結果が参照される。

【０１２７】請求案件の組合せが複合処理案件に該当す
る場合、予め定められた適正順序に従って処理が行われ
るように、すなわち一の業務プロセスの終了後に次の業
務プロセスが行なわれるように、ディスパッチャ２２
は、各業務フロー内のワークフロー起動アクティビティ
の指示に基づき、複数の業務プロセスを順次起動する。
また請求案件の組合せが同時処理案件に該当する場合、
ディスパッチャ２２は、それら請求案件に対応する複数
の業務プロセスを一斉に起動する。

【０１２８】また、請求案件の組合せが例外案件に該当
する場合は、汎用例外プロセスが起動される。そして、
請求案件の書類が、印刷サーバによって、本社担当課の
プリンタに印刷される。本社担当課では手作業で請求書
類を処理のうえ、該当プロセス（汎用例外）の完了入力
を行う（一度案件をワークフローの外に出し、処理済後
差し戻す）。

【０１２９】図１７は、複合処理の流れを示している。
まず、ディスパッチャ２２により、複合順序の一つ目の
業務プロセスが起動され、業務フローシステム２０によ
り業務プロセスが進行される。業務プロセスの最後の部
分には、次案件起動ノードが設けられている。この起動
ノードは、請求案件が複合処理案件に該当するときに機
能する。次案件起動ノードでは、業務支援データベース
２４が参照され、処理中の請求案件と関連づけられた別
の案件が求められる。これにより、複合順序上で次に処
理されるべき案件が求められる。そしてディスパッチャ
２２により次の案件に対応する業務プロセスが起動され
る。

【０１３０】複合処理されるべき最後の案件の処理が進
み、その案件の処理が次案件起動ノードに達したとす
る。このとき、業務支援データベース２４の案件管理フ
ォルダが参照され、すべての複合処理が終了したことが
判定される。これにより複合処理案件の処理が終了す
る。

【０１３１】なお、本実施の形態では、基本的にすべて
の業務プロセスの終わりに次案件起動ノードが設定され
ている。また、各業務プロセスは、単独案件の処理と、
複合処理案件の処理と、後述する同時処理案件の処理と
で共用される。しかし、次案件起動ノードは、請求案件
が複合処理対象のときのみ機能する。すなわち、業務プ
ロセスが他の業務プロセスと直列連結されるときのみ機
能する。そこで、複合処理以外の説明および図面では、
次案件起動ノードは省略されている。

【０１３２】図１８は、同時処理の流れを示している。
同時処理では、ディスパッチャ２２は、複数の業務プロ
セスを一斉に起動させる。業務フローシステム２０は、
それら業務プロセスを併行して進行させる。

【０１３３】業務プロセス上には同期処理ノードが定め
られている。同期処理ノードは、請求案件が同時処理案
件に該当するときに機能する。同期処理ノードは、例え
ば、電話確認ノード、ホスト処理ノード、不備通知ノー
ド、顧客宛結果発送ノードなどである。

【０１３４】同期処理ノードに到達する前は、複数の業
務プロセスはばらばらに進行しており、それらは互いに
ずれていてよい。同期処理ノードでは、併行処理されて
いる複数の請求案件の待ち合わせにより、複数の業務プ
ロセスにおける同期処理ノードの処理タイミングが同期
する。例えば、顧客に対する電話確認が、複数の請求案
件に関してまとめて行われる。待合せは、後述するよう
に、同期処理ノードの前に設けられた待合せノードを用
いて実現される。

【０１３５】同期処理ノードを過ぎると、再び複数の処
理が併行して行われる。業務プロセスには複数の同期処
理ノードが設定されていてもよい。この場合、次の同期
処理ノードで、再び待ち合わせ、同期処理が行われる。

【０１３６】次に、図１９は、同時処理の流れをより具
体的に示している。図１９を用いて複数プロセスの待合
せについて説明する。また、同期処理案件の数が３以上
である場合において、一部の案件のみが、同じ同期処理
ノードをもつ場合がある。この場合の処理も図１９に示
されている。

【０１３７】図１９では、同時処理される３本の業務プ
ロセスが示されている。上側の２本の業務プロセスには
電話確認ノードが設定され、電話確認ノードの前段に電
話確認待合せノードが設定されている。一方、一番下の
業務プロセスには電話確認ノードは設定されていない。
また、３本のプロセス全部に、ホスト処理ノードが設定
され、かつ、ホスト処理ノードの前段に同期待合せノー
ドが設定されている。上記の電話確認ノードおよびホス
ト処理ノードは、同期処理ノードの一形態である。

【０１３８】図１９の処理では、一つの請求案件が電話
確認待合せノードに到達すると、業務支援データベース
２４の案件管理フォルダを参照して、同時処理される請
求案件の本数Ｎ（＝３）が参照される。電話確認待合せ
ノードおよび同期待合せノードに達した案件数の合計
が、同時処理本数Ｎに達したとき、同期完了と判定され
る。上側の２本の業務プロセスにおいて、請求案件が電
話確認ノードへと進められる。これにより２つの案件の
電話確認が同時に行われる。

【０１３９】電話確認が終わると、請求案件は同時待合
せノードへと進む。これにより、３本の業務プロセスの
請求案件が同期待合せノードへ到達する。待合せが完了
したので、３つの請求案件はホスト処理ノードへと進
む。これにより、ホスト処理が、３つのプロセスで同期
したタイミングで行われる。

【０１４０】このように、本実施の形態では、業務プロ
セスに待合せノードを設けるという比較的簡単な構成に
より、併行処理される複数のプロセスの一部タイミング
を確実に同期させることができる。そして、一部のプロ
セスが該当する同期処理（図１９では電話確認ノード）
をもたない場合でも、別の待合せノードを利用して、同
期処理を適切に行える。

【０１４１】なお、本実施の形態では、各業務プロセス
は、単独案件の処理と、複合処理案件の処理と、同時処
理案件の処理に共用される。しかし、待合せノード（同
時待合せノードおよび電話確認待合せノード）は、請求
案件が同時処理対象のときのみ機能する。そこで、同時
処理以外の説明および図面では、待合せノードは省略さ
れている。

【０１４２】＜案件間情報参照機能＞

【０１４３】以上に本システムによる複合処理案件およ
び同時処理案件の処理について説明した。次に、これら
複数案件の処理に好適に用いられる案件間情報参照機能
を説明する。

【０１４４】従来の通常のワークフローシステムでは、
案件情報はワークフローシステム内に取り込まれてお
り、ある案件の処理プロセスでは、別の案件固有の情報
は参照できない。一方、本実施形態では、案件情報が外
出し形式の業務支援データベースに格納されている。し
たがって、ある案件の処理プロセスでも、業務支援デー
タベースにアクセスすることによって、別の案件の情報
を参照できる。本実施の形態では、この別案件参照機能
が、アプリケーションサーバのアプリケーション（処理
アクティビティ）に備えられている。

【０１４５】図２０〜図２２は、複合、同時処理案件の
処理の際に作業者端末に表示される画面の例を示してい
る。これらの図面を用いて別案件参照機能を説明する。

【０１４６】図２０は、ある請求案件の点検画面であ
る。表示された請求案件が別の案件と紐付けられている
（複合または同時処理案件である）ときは、図２０の画
面右上に示されるように、「同時」または「複合」ボタ
ンが表示される。図２０の例では「同時」ボタンが表示
される。

【０１４７】作業者が「同時ボタン」をクリックする
と、図２１に示すように、同時処理されている別の案件
を示すボタンが表示される（画面右上、矢印マーク）。
図２１には一つのボタンが示されているが、同時処理件
数が３以上の場合には、その件数に応じた数のボタンが
表示される。

【０１４８】作業者が、同時案件のボタンをクリックす
ると、図２２に示すように、クリックされた案件の請求
書イメージが表示される。さらなるボタン操作により、
請求書の付属書類も表示される。

【０１４９】上記のように、本実施の形態では、別案件
の情報を参照できるので、案件間の情報を共有化でき
る。共有化が有効な情報は、例えば、印鑑証明書および
戸籍謄本などの付属書類である。拠点端末では、このよ
うな付属書類を、複合同時案件の一つとともに、スキャ
ナで電子化する。業務支援データベースでは、付属書類
の電子データは、一の請求案件にもたせておく。他の請
求案件の業務プロセスではも、アプリケーションサーバ
の処理アクティビティ（例えば上記点検アクティビテ
ィ）は、参照機能を利用して上記の付属書類を参照す
る。これにより案件間の情報共有化が実現される。そし
て、端末でのスキャナ読取作業の重複を回避でき、さら
に、業務支援データベースのデータの重複を回避でき
る。

【０１５０】また例えば、複合処理案件の中には、「契
約変更（保障の増額）」と「契約変更（保障の減額）」
といった組合せがある。この場合、顧客は、一方の保険
の保障額を増やす代わりに、他方の保険の保障額を減ら
すことを意図している。しかし、保障の増額は、保険会
社にとっての危険率の増加を招くので、承諾判断を必要
とする。保障の増額が承諾されないのに、他方の保険の
補償額が減らされると、顧客の意図に反してしまう。

【０１５１】このような場合に、本実施の形態では、先
行する案件（第１順位）の処理過程で、後続案件（第２
順位）の情報が参照できる。上記の例では、現在処理中
の先行案件の非承諾という結果を受け、先行案件の段階
で後続案件の請求内容（保障減額）を確認のうえ、後続
案件の実行可否の判断、処理および顧客への再確認など
ができ、したがって上記のような顧客の意図に反する手
続が回避できる。この例に示されるように、本発明によ
れば、複数案件の内容を考慮した判断が必要な場合に
も、案件間の情報の参照により、適切な処理ができる。

【０１５２】図２３は、同時処理において表示される同
期電話確認用の画面の例を示している。図示のように、
同時に電話確認を行うべき案件のリストが表示される。
ここでも、別案件の情報参照機能を利用して、同時電話
確認のために、複数の案件の電話確認内容がリストで表
示されている。

【０１５３】また、本実施の形態の参照機能は、複合処
理案件における処理結果の引継ぎにも応用できる。この
引継ぎにより、以下に説明するように、同時処理案件と
同様の同時電話確認が複合処理案件でも可能となる。

【０１５４】複合処理案件については、前述したよう
に、複数の業務プロセスが順次実行される。複数の業務
プロセスが電話確認ノードをもつ場合、それら電話確認
ノードのそれぞれで電話確認が行われ、その結果、顧客
に対して複数回の電話確認が行われる。しかし、電話確
認はまとめて行う方が、顧客の手間を削減するうえで望
ましい。そこで、本実施の形態では、以下のようにし
て、複合処理においても同時電話確認を実現している。

【０１５５】図２４は、複合処理における同時電話確認
を示している。図２４には、現処理中の案件の業務プロ
セスが示されている。現処理中の案件は、複合処理対象
として関連づけられた複数案件のうちの一番目の案件で
ある。

【０１５６】請求案件が電話確認ノードに到達すると、
前述したように案件特定情報がワークリスト送受信箱に
入れられる。アプリケーションサーバ２８の電話確認ア
クティビティにより、請求案件が取り出され、処理され
る。クライアント端末に電話確認用の画面が表示され、
担当者に電話確認が促される。

【０１５７】ここで、電話確認アクティビティは、業務
支援データベース２４を参照して、現処理中の案件と関
連付けられた案件、すなわち、現処理中の案件の後段で
処理される案件を確認する。３つ以上の案件が関連づけ
られている場合は、すべての後続案件が確認される。後
続案件の電話確認が必要な場合、電話確認用の端末画面
には、現処理中の案件に加えて、後続案件が示される。
画面上には、電話確認内容が表示される。また必要に応
じて、例えば担当者の指示により、後続案件の情報が画
面表示される。

【０１５８】担当者は、複数案件が表示された画面をみ
て、それら案件の電話確認をまとめて行う。担当者が電
話確認結果を入力すると、確認結果は業務支援データベ
ース２４に記録される。もちろん、現処理中の案件情報
と、後続案件情報の両方について、確認結果が記録され
る。また、電話確認の履歴が、案件管理データ記録デー
タベース２６に記録される。

【０１５９】電話確認が終了すると、業務フローシステ
ム２０は請求案件を次ノードへ進める。請求案件が次案
件起動ノードへ達すると、ディスパッチャ２２に起動が
指示される。ディスパッチャ２２は、次の請求案件に対
応する業務プロセスを起動する。

【０１６０】後段の業務プロセスでは、電話確認はすで
に終了していることを業務支援データベースを利用して
引き継ぐ。そこで、電話確認ノードをパスして、業務フ
ローシステム２０は請求案件を次ノードへ進める。これ
により、電話確認が省略される。

【０１６１】以上のように、本実施の形態では、業務支
援データベースがワークフローシステムから外部に出さ
れているので、後続案件の内容を参照できる。その結
果、先行案件にて、後続案件の電話確認処理ができ、こ
の電話確認結果を後続案件に引き継ぐことができる。顧
客にとってみれば、１回の請求に対する電話確認をまと
めて受けられるので、電話応対の手間が減る。したがっ
て顧客に対するサービス性の向上が図れる。また業務処
理側の手間の削減も図れる。

【０１６２】図２５は、複合、同時案件のデータを印刷
したときのヘッダ用紙の例を示している。図示のよう
に、複合、同時として紐付けられた関連案件の情報がま
とめてヘッダ用紙に印刷される。ここでも、業務支援デ
ータベースを利用して関連案件の情報が参照されてい
る。

【０１６３】本システムでは、上述の他、複合同時の関
連案件については、管理情報、案件内容、進捗状況を参
照できるように構成する。

【０１６４】以上に説明したように、本発明によれば、
各案件情報をワ―クフロー内案件固有情報とせず、外出
しの業務支援データベースを構築したことで、案件間の
データの参照ができ、それによるデータの共有化や引継
ぎができる。そして、スキャナ読取りを省力化したり
（印鑑証明等の読取作業の削減）、コンピュータ資源を
節約したり（データの重複保存の回避）、顧客へのサー
ビスを向上したり（顧客の要望に確実に沿った処理）、
といったことができる。

【０１６５】[３] 案件制御

【０１６６】次に、本実施の形態のシステムにより実現
される案件制御機能を説明する。

【０１６７】生命保険の保全手続に集中処理システムを
適用する場合、一度受け付けた案件を、業務要件やシス
テム要件に基づき即座に制御（操作）できることが求め
られる。

【０１６８】例えば、拠点から発生する業務的な要件と
して、顧客からの依頼による案件の取下げや手続内容変
更、至急扱い（優先度変更、複合または同時処理からの
離脱）などがある。債権差押え通知により処理差止（案
件の取下げ）が必要になることもある。拠点での書類の
二重読取りや付属帳票添付漏れといった誤操作の取消な
どが必要になることもある。

【０１６９】集中事務処理センタ内で発生する業務的な
要件としては、担当者が規約の照会などのために一時的
に離席するときには、案件処理を保留する制御が必要で
ある。また、複合処理案件や同時処理案件中に、医的審
査を必要とする請求案件が含まれることがある。医的審
査が案件の進捗を阻害するような状況（処理完了に相当
な時間を要する状況）では、該当案件を残りの複合また
は同時処理案件から離脱（分割）させる制御が必要とな
る。さらには、業務プロセスの途中で、請求案件を例外
処理へ回送する必要が生じる場合もある。

【０１７０】案件制御が必要になるシステム要件として
は、業務処理装置内の一部アプリケーションの不具合に
よる各種データベースの誤更新などがある。

【０１７１】このように、生命保険の手続をシステム化
する場合、請求案件に対する制御機能を備えることが必
要である。しかし、通常のワークフローシステムでは、
保留、中断といった案件操作における自由度の高い制御
機能は備えていない。

【０１７２】案件制御のために、ワークフローシステム
内のプロセスを専用設計して特殊化することも考えられ
る。また、アプリケーションの不具合やシステム障害時
には、システム全体を適当な静止ポイントまで戻す対応
も考えられる。

【０１７３】ワークフローシステム側の案件制御専用設
計としては、例えば「途中終了」という制御のために、
プロセス上で終了が想定される全ノードの次にワークフ
ロー終了ノードを定義することが考えられる。また「保
留」という制御については、業務プロセスに「保留」専
用ノードを設け、プロセス中の全ノードと保留ノードの
ループ（行き来）を定義する、といった設計も考えられ
る。しかしこのような構成には、業務プロセス設計に余
計な作業負荷がかかることになる。

【０１７４】以上より、特殊設計や、システム全体の処
理を戻す操作は、極力避けることが望ましく、このよう
な背景の下、本実施形態では、特殊な設計を必要とせず
に、ワークフローシステムで処理中の案件の外部制御を
実現している。

【０１７５】図２６を参照すると、本実施の形態では、
案件制御機能が案件管理ツール３６（本発明の案件制御
手段として機能する）により実現される。案件管理ツー
ル３６は、案件制御要求をワークリストサーバ３０、デ
ィスパッチャ２２および不備管理部４２に送る。案件制
御要求には、制御対象の案件を特定する案件特定情報が
含まれる。本実施の形態では、前述したように、案件特
定情報として案件管理番号（拠点処理日＋業務単位コー
ド＋処理番号）が用いられる。ワークリストサーバ３
０、ディスパッチャ２２および不備管理部４２は、それ
ぞれ、案件制御要求に含まれる案件管理番号をもってい
るか否かを確認する。各構成は、該当する案件管理番号
をもっている場合、案件制御要求に示される制御を実行
する。該当する案件をもっていなければ、その旨を案件
管理ツール３６に伝える。

【０１７６】そして、業務支援データベース２４および
案件管理データ記録データベース２６のデータが更新さ
れ、すなわち、請求案件の制御状態および制御実行の記
録が書き込まれ、更新結果通知が案件管理ツール３６に
返される。なお、前述した案件管理ツール３６による業
務支援データベース２４および案件管理データ記録デー
タベース２６に対する案件状況照会も、図２６の構成を
利用して行われる。

【０１７７】本実施の形態では、ワークリストサーバ３
０は、業務フローシステム２０で処理中の請求案件を保
持している。したがって、ワークリストサーバ３０へ制
御要求を送ることにより、処理中の案件をワークリスト
サーバの外部から制御できる。このとき、ワークリスト
サーバ３０のワークリスト送受信箱では、リスト中の案
件特定情報に、制御状態を示すデータが加えられる。例
えば、中断制御では、リスト中の案件特定情報に、中断
を示すフラグが立てられる。

【０１７８】ワークリストサーバ３０は、制御対象の案
件特定情報をもっていない場合でも、業務フローシステ
ム２０に対して案件特定情報をもっているか否かを確認
する。これは、ワークリストサーバ３０がもつ業務フロ
ーシステム２０とのインターフェース機能により実現さ
れる。そして、業務フローシステム２０内での請求案件
の生死が確認される。

【０１７９】請求案件が業務フローシステム２０内で生
きているとする。業務フローシステム２０は、前述した
ように、請求案件の案件特定情報をノードからノードへ
と進める役割をもつ。したがって、業務フローシステム
２０内の案件は即座に次のノードに到着し、そのノード
に対応するワークリスト送受信箱へと入る。これを待ち
うけて、ワークリストサーバ３０は、案件制御要求に従
った処理を行なう。

【０１８０】一方、ディスパッチャ２２は、業務フロー
システム２０へ投入される前の未処理案件（処理開始
前）をもっている。ディスパッチャ２２へ案件制御要求
を送ることにより、処理開始前の案件も制御できる。

【０１８１】さらに、不備管理部４２は、処理中に業務
フローシステム２０の業務プロセスから外された案件を
もっている。このような処理中であるがワークリストサ
ーバにない案件も制御できる。

【０１８２】その他、案件処理の完了後も制御が必要に
なることがある。具体的には、処理完了後の案件取下げ
制御が挙げられる。このような制御では、業務支援デー
タベース２４内に保持されている案件の状態を書き換
え、案件管理データ記録データベース２６に制御記録を
追加すればよい。

【０１８３】図２７は、案件管理ツール３６がサポート
している案件制御の一覧を示している。各制御は、テー
ブル中に丸印が付けられた状態の案件に対して行なわれ
る。至急指定は、請求案件を至急扱いの対象に指定する
制御である。中断は、案件単位の一次停止である。途中
終了は、中断状態の案件を終了させる。例外回送は、あ
る業務プロセス上にて中断中の処理待ちの案件を、定型
外の人手処理として定義される汎用例外フローにまわ
す。再開は、中断状態の案件の処理再開である。取下げ
は、案件単位での請求案件のキャンセルである。離脱
は、複合または同時処理案件から一部案件を取り外す。
不備再送は、集中事務処理装置から拠点端末への不備通
知に失敗したときの不備通知再送処理である。不備取消
は、不備通知の取消である。保留解除は、操作者により
一時退避された案件の復帰である。図２８は、案件制御
における状態遷移図を示している。

【０１８４】図２７のテーブルには、保留解除が設定さ
れているものの、保留制御が含まれていない。保留制御
は、担当者の一時離席時の退避であるので、システム内
で頻繁に発生する。そこで、保留機能はアプリケーショ
ンサーバの各アプリケーション（アクティビティ）に備
えられている。

【０１８５】図２６を再び参照すると、案件管理ツール
３６は、案件制御要求をすべての構成に送らずに、必要
な構成に限定して送ればよい。例えば、中断要求は、デ
ィスパッチャ２２とワークリストサーバ３０に送られれ
ばよい。

【０１８６】図２９は、中断処理を例にとって、案件制
御のシーケンスを示している。案件管理ツールは、中断
要求と案件管理番号を、プロキシサーバおよび制御系サ
ーバ（図２では省略、このシーケンスでは案件制御手段
の一部として機能）を介してディスパッチャに送る。デ
ィスパッチャは、該当案件をもっている場合、その案件
を中断状態にして、中断実行を案件管理ツールに伝え
る。該当案件をもっていない場合は、エラー通知が送り
返される。

【０１８７】ディスパッチャに該当案件がない場合、続
いて、制御系サーバからワークリストサーバ（ＷＬＳ）
へ、中断要求と案件管理番号が送られる。ただし、ディ
スパッチャで中断要求（リクエスト）が成功した場合に
は、ワークリストへは中断要求を投げない。

【０１８８】ワークリストサーバは、該当案件をもって
いれば、その案件を中断状態にする。さらに、ワークリ
ストサーバは、該当案件をもっていない場合でも、業務
フローシステム（ＣＥ、ワークフローシステム本体）に
対して、該当案件の生死を確認する。該当案件が業務フ
ローシステムで生きていれば、案件が業務フローシステ
ムからワークリストサーバに掃き出されるのをまって、
その案件を中断状態にする。ワークリストサーバは、中
断実行を制御系サーバに伝える。

【０１８９】ディスパッチャまたはワークリストサーバ
で中断のリクエストが成功した場合、制御系サーバは、
業務支援データベース（ＧＤＢ）に対して中断の指示を
送り、データベース内の該当案件の状態を中断に変更す
る。さらに制御系サーバは、案件管理データ記録データ
ベースに、中断処理のログを記録させる。この後、制御
系サーバは、業務支援データベースに対してコミットを
指示する。このコミットにより、データベースの更新が
完了する。制御系サーバからプロキシサーバを介して案
件管理ツールに中断完了が伝えられる。

【０１９０】図１０を再び参照する。図１０は、案件管
理ツールにより表示される案件詳細情報の画面である。
担当者は、案件制御を行なうため、まず、案件管理番号
を入力して、図１０の画面を端末に表示させる。図１０
の画面の下方には、案件制御のためのボタン「至急指
定」「中断」等が表示される。担当者は、所望の案件制
御のボタンを操作する。これを受けて、案件管理ツール
により上述の案件制御が行なわれる。また、案件制御の
うちの保留については、図５に示されるように、通常の
作業画面内に保留操作ボタンが表示される。

【０１９１】なお、作業者によって、利用可能な案件制
御を制限してもよい。この場合、図１０の画面中で、利
用可能な案件制御のボタンのみを表示することが好適で
ある（例えば、残りのボタンがグレーアウトされる）。

【０１９２】以上に本実施形態の案件制御機能を説明し
た。本実施の形態では、業務支援データベースや案件管
理データ記録データベースを業務フローシステムから切
り出して外部に構築している。そして、業務フローシス
テムとの接点、インターフェース部分にインフラプロダ
クトを構築している。すなわち、案件投入部分にはディ
スパッチャを設けている。また、業務フローシステムと
アプリケーションの案件受渡し部のインフラプロダクト
としてワークリストサーバを設けている。ワークフロー
サーバには案件の送達管理、送受信時のキュー（待ち行
列）機能をもたせている。このような構成を利用して、
個々の案件の進捗状況を業務運用に合せて制御してい
る。ワークフローシステムに特別なプロセス定義を設計
することなく、ワークリストサーバやディスパッチャを
利用して案件制御を可能としている。ワークリストサー
バにより、ワークフローシステムで処理中の案件も容易
に制御できる。

【０１９３】また本実施の形態では、案件データに対し
て外部からアクセス可能であるので、誤操作、アプリケ
ーションの不具合、システム障害といった事態が発生し
たときでも、該当案件のみを制御、復旧すればよい。シ
ステム全体を静止ポイントまで戻さなくてもすむ。

【０１９４】また本実施の形態では、案件管理ツールか
らワークリストサーバ、ディスパッチャ、不備管理部へ
と案件制御要求が投げられる。これらのどこに対象案件
がいたとしても、必要な制御が確実に行なえる。さら
に、システム全体で共通の案件管理番号を使っているの
で、案件がシステム内のどこに位置する場合でも、案件
制御が確実に行なえる。

【０１９５】なお、案件投入部のインフラプロダクトで
あるディスパッチャには、業務フロー単位、申請組織
（事務単位コード）単位での投入抑止制御や中断機能を
もたせることも好適である。

【０１９６】[４] 請求案件情報の保存

【０１９７】次に、案件処理の終了後の請求案件情報の
保存、管理について説明する。

【０１９８】本実施の形態では、請求案件情報が、ワー
クフローシステムの外部に設けられた業務支援データベ
ース２４に格納されている。請求案件情報は、請求書類
のイメージデータ、ホスト照会、処理結果、作業者コメ
ントなどを含んでいる。これらの情報は、業務プロセス
の終了後も、所定の一次保存期間、例えば３ヶ月間保存
される。これにより、サンプリングチェックなどの牽制
ができる。すなわち、保存されている請求案件情報がサ
ンプリングされ、その請求案件の処理過程が事後的に点
検される。案件処理方法に改善の余地がある場合には、
担当者に対する指導が行なわれる。このように、外出し
形式のデータベースに処理後のデータをそのまま保存し
ておくことで、業務改善に寄与することができる。

【０１９９】さらに本実施の形態では、上記の一次保存
期間の経過後、バッチ処理により、請求案件情報から、
処理履歴情報が抽出される。処理履歴情報は、案件管理
番号、証券番号、業務名、ホスト処理日付、業務フロー
完了日といった案件内容、さらには、業務プロセスの各
ノードでの処理日時や作業者である。これらは、ヒスト
リー管理部（本発明の履歴保存部、図示せず）に格納さ
れ、上記の一次保存期間より長い二次保存期間、例えば
７年間保持される。ヒストリー管理部には、必要に応じ
て、案件管理データ記録データベースのログ情報も移さ
れる。ヒストリー管理部の履歴情報は、業務実行決裁ロ
グとして長期間にわたり利用される。

【０２００】ヒストリー管理部の履歴情報は、ヒストリ
照会ツール（図示せず）により照会される。

【０２０１】図３０および図３１は、ヒストリ照会ツー
ルによって、クライアント端末に表示される画面を示し
ている。図３０では、履歴が残っている案件の一覧（ヒ
ストリー一覧）が表示される。一の案件が選択される
と、図３１に示すように、履歴の詳細（ヒストリー詳
細）が表示される。

【０２０２】図３２および図３３は、それぞれ、ヒスト
リー一覧およびヒストリー詳細を印刷した帳票を示して
いる。この印刷用のデータは、ヒストリ照会ツールから
印刷サーバ（図２、符号４６）に送られ、印刷サーバに
よりプリンタを用いた印刷が実行される。

【０２０３】以上のように、本実施の形態によれば、外
出し形式のデータベースを用いて請求案件を処理してい
るので、書類イメージなどを含む請求案件情報を容易に
保存でき、さらに必要なデータを抽出して長期間保持し
ておくこともできる。前者の情報を利用したサンプリン
グチェックによる牽制ができるとともに、後者の抽出デ
ータを業務実行決裁ログとして長期間利用できる。

【０２０４】以上、本発明を実施の形態を用いて説明し
たが、本発明の技術的範囲は上記実施の形態に記載の範
囲には限定されない。上記実施の形態に、多様な変更又
は改良を加えることができる。その様な変更又は改良を
加えた形態も本発明の技術的範囲に含まれ得ることが、
特許請求の範囲の記載から明らかである。

【０２０５】

【発明の効果】上記説明から明らかなように、本発明に
よれば、ワークフローシステムには請求案件を特定する
情報を流しておき、処理対象の情報は、ワークフローシ
ステムの外部のデータベースに格納する。こうした構成
により、既存のワークフローシステムを活用しつつ、す
なわち、ワークフローシステムの特別な改造をせずに、
処理中の案件の参照や制御などが容易に実現できる。そ
の結果、生命保険のような多種多用な業務処理、すなわ
ち、処理中の案件を参照したり、制御する必要がある業
務処理にも、ワークフローシステムを好適に適用するこ
とができる。

【図面の簡単な説明】

【図１】本発明の実施の形態における集中業務処理シス
テムを示す図である。

【図２】図１の集中業務処理装置の構成を示す図であ
る。

【図３】業務フローシステムおよび関連構成の機能を示
す図である。

【図４】業務フローシステムに定義された業務プロセス
を示す図である。

【図５】図２の集中業務処理装置で作業者端末に表示さ
れる画面の例である。

【図６】図３の一部を抜き出して本発明の特徴を示す図
である。

【図７】クライアント端末に表示される案件照会画面の
一例を示す図である。

【図８】クライアント端末に表示される案件照会画面の
一例を示す図である。

【図９】クライアント端末に表示される案件照会画面の
一例を示す図である。

【図１０】クライアント端末に表示される案件照会画面
の一例を示す図である。

【図１１】クライアント端末に表示される案件照会画面
の一例を示す図である。

【図１２】拠点案件状況照会プロセスを示す図である。

【図１３】複合同時判定プロセスを示す図である。

【図１４】複合同時判定プロセスで用いられる複合同時
判定テーブル、特に複合判定テーブルを示す図である。

【図１５】複合同時判定プロセスで用いられる複合同時
判定テーブル、特に同時判定テーブルを示す図である。

【図１６】複合同時判定プロセスで用いられる複合同時
判定テーブル、特に例外判定テーブルを示す図である。

【図１７】複合処理の流れの例を示す図である。

【図１８】同時処理の流れの例を示す図である。

【図１９】同時処理の流れの例を示す図である。

【図２０】同時処理において作業者端末に表示される画
面の例を示す図である。

【図２１】同時処理において作業者端末に表示される画
面の例を示す図である。

【図２２】同時処理において作業者端末に表示される画
面の例を示す図である。

【図２３】同時処理において作業者端末に表示される画
面の例を示す図である。

【図２４】複合処理における同時電話確認機能を示す図
である。

【図２５】同時処理案件をプリンタから出力したときの
ヘッダ用紙を示す図である。

【図２６】案件制御機能を示す図である。

【図２７】本実施形態の装置で用意されている案件制御
のテーブルを示す図である。

【図２８】案件制御による状態遷移を示す図である。

【図２９】案件制御のシーケンスを示す図である。

【図３０】履歴情報の一覧の表示画面を示す図である。

【図３１】一案件の詳細履歴を表示する画面を示す図で
ある。

【図３２】履歴情報の一覧の印刷帳票を示す図である。

【図３３】一案件の詳細履歴の印刷帳票を示す図であ
る。

【符号の説明】

１０ 集中業務処理装置 １４ 顧客端末装置 １８ ホストシステム ２０ 業務フローシステム ２２ ディスパッチャ ２４ 業務支援データベース ２６ 案件管理データ記録データベース ２８ アプリケーションサーバ ３０ ワークリストサーバ

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｇ０６Ｆ 19/00 ３００ Ｇ０６Ｆ 19/00 ３００Ｎ (72)発明者 赤祖父 正朋 大阪府大阪市北区中之島２丁目２番５号 住友生命保険相互会社内 (72)発明者 佐藤 壮緑 大阪府大阪市北区中之島２丁目２番５号 住友生命保険相互会社内 (72)発明者 浜本 浩一郎 大阪府大阪市北区中之島２丁目２番５号 住友生命保険相互会社内 Ｆターム(参考） 5B049 BB47 CC21 GG04 GG07 5B055 CA00 CB00 EE02

Claims (16)

【特許請求の範囲】
1. 【請求項１】 多数の顧客と契約関係をもつ企業等に用
   いられ、契約変更等の業務手続の請求案件を処理する集
   中業務処理装置であって、 業務手続を遂行するための処理を規定する処理ノードを
   含む業務プロセス機能を備え、個々の請求案件を特定す
   る案件特定情報を前記業務プロセスに沿って進行させる
   業務フローシステムと、 前記業務フローシステムから外出し形式で設けられ、処
   理対象になる請求案件情報を格納する業務支援データベ
   ースと、 前記業務フローシステムから外出し形式で設けられ、各
   請求案件の業務プロセス上での状況を管理する案件管理
   データ記録データベースと、 前記処理ノードに位置する案件特定情報が示す請求案件
   に関して、前記処理ノードで規定される処理を前記業務
   支援データベースおよび前記案件管理データ記録データ
   ベースに対して行なうアプリケーションである処理アク
   ティビティを備えるアプリケーションサーバと、 を含み、前記業務フローシステムは、前記処理アクティ
   ビティによる処理が終了した請求案件の案件特定情報
   を、現在の処理ノードから次の処理ノードへと進めるこ
   とを特徴とする集中業務処理装置。
2. 【請求項２】 多数の顧客と契約関係をもつ企業等に用
   いられ、契約変更等の業務手続の請求案件を処理する集
   中業務処理装置であって、 業務手続を遂行するための処理を規定する処理ノードを
   含む業務プロセス機能を備え、個々の請求案件を特定す
   る案件特定情報を前記業務プロセスに沿って進行させる
   業務フローシステムと、 前記業務フローシステムから外出し形式で設けられ、処
   理対象になる請求案件情報を格納する業務支援データベ
   ースと、 前記業務フローシステムから外出し形式で設けられ、各
   請求案件の業務プロセス上での状況を管理する案件管理
   データ記録データベースと、 前記業務プロセスの処理ノードに対応するワークリスト
   送受信箱を有し、前記処理ノードに到達した案件特定情
   報をワークリスト送受信箱に保持するワークリストサー
   バと、 前記ワークリスト送受信箱内の案件特定情報が示す請求
   案件に関して、前記処理ノードで規定される処理を前記
   業務支援データベースおよび前記案件管理データ記録デ
   ータベースに対して行なうアプリケーションである処理
   アクティビティを備えるアプリケーションサーバと、 を含み、前記業務フローシステムは、前記処理アクティ
   ビティによる処理が終了した請求案件の案件特定情報
   を、現在の処理ノードのワークリスト送受信箱から次の
   処理ノードのワークリスト送受信箱へと進めることを特
   徴とする集中業務処理装置。
3. 【請求項３】 請求項１または２に記載の集中業務処理
   装置において、 顧客から業務手続の請求案件を受け付ける拠点に配備さ
   れ前記集中業務処理装置と通信可能に接続された端末装
   置からの照会請求に応答して、前記案件管理データ記録
   データベースに格納された請求案件の状況情報を照会す
   る拠点案件状況照会手段を有し、照会結果が前記端末装
   置に送信されることを特徴とする集中業務処理装置。
4. 【請求項４】 請求項３に記載の集中業務処理装置にお
   いて、 前記拠点案件状況照会手段は、前記業務プロセスと同様
   の形態の拠点案件状況照会プロセスとして前記業務フロ
   ーシステムに備えられており、 前記業務フローシステムは、前記端末装置から前記照会
   請求が送られてきたときに、前記拠点案件状況照会プロ
   セスを起動することを特徴とする集中業務処理装置。
5. 【請求項５】 請求項３または４に記載の集中業務処理
   装置において、 前記案件特定情報は案件管理番号を含み、案件管理番号
   は、前記拠点端末が請求案件を処理した処理日および前
   記拠点端末の属する拠点を特定する業務単位コードを含
   み、 前記業務支援データベースおよび前記案件管理データ記
   録データベースは前記案件管理番号に関連づけて各案件
   の情報を管理し、 前記拠点案件照会手段は、前記端末装置から送られてき
   た照会請求に含まれる案件管理番号に基づいて、対応す
   る案件の状況を照会することを特徴とする集中業務処理
   装置。
6. 【請求項６】 請求項３または４に記載の集中業務処理
   装置において、 前記案件特定情報は証券番号を含み、 前記業務支援データベースおよび前記案件管理データ記
   録データベースは前記証券番号に関連づけて各案件の情
   報を管理し、 前記拠点案件照会手段は、前記端末装置から送られてき
   た照会請求に含まれる証券番号に基づいて、対応する案
   件の状況を照会することを特徴とする集中業務処理装
   置。
7. 【請求項７】 請求項１または２に記載の集中業務処理
   装置において、 一の顧客に関して複数の請求案件が取得されたときに、
   一の請求案件の処理中に、別の請求案件の情報を前記業
   務支援データベースから参照する別案件参照手段を含む
   ことを特徴とする集中業務処理装置。
8. 【請求項８】 請求項２に記載の集中業務処理装置にお
   いて、 前記ワークリストサーバのワークリスト送受信箱に保持
   される請求案件を対象とした案件制御処理によって、業
   務プロセス上の処理中の請求案件を制御する案件制御手
   段を含むことを特徴とする集中業務処理装置。
9. 【請求項９】 請求項８に記載の集中業務処理装置にお
   いて、 前記業務フローシステムとのインターフェース機能をも
   ち、顧客からの請求案件に対応する業務プロセス機能を
   前記業務フローシステムに起動させるディスパッチャを
   含み、 前記案件制御手段は、さらに、前記ディスパッチャが保
   持する請求案件を対象とした案件制御処理によって、業
   務プロセスでの処理前の請求案件を制御することを特徴
   とする集中業務処理装置。
10. 【請求項１０】 請求項９に記載の集中業務処理装置に
    おいて、 前記業務プロセスに沿った処理中に請求処理の不備が発
    見された不備請求案件を管理する不備管理部を含み、 前記案件制御手段は、さらに、前記不備管理部が管理す
    る不備請求案件を対象とした案件制御処理によって、不
    備管理中の請求案件を制御することを特徴とする集中業
    務処理装置。
11. 【請求項１１】 請求項１０に記載の集中業務処理装置
    において、 前記案件制御手段は、前記ワークリストサーバ、前記デ
    ィスパッチャおよび前記不備管理部に対して、制御対象
    の請求案件を示す案件制御要求を送り、 前記ワークリストサーバ、前記ディスパッチャおよび前
    記不備管理部は、案件制御要求に示される請求案件を保
    持する場合に、その請求案件を案件制御要求に従って処
    理することを特徴とする集中事務処理装置。
12. 【請求項１２】 請求項１または２に記載の集中業務処
    理装置において、 前記業務支援データベースは、各請求案件情報を、前記
    業務プロセスの完了後も所定の一次保存期間にわたって
    保存し、 さらに、前記一次保存期間の経過後、前記一次保存期間
    より長い所定の二次保存期間にわたり、前記請求案件情
    報から抽出された処理履歴情報を保存する履歴保存部を
    含むことを特徴とする集中業務処理装置。
13. 【請求項１３】 多数の顧客と契約関係をもつ企業等に
    用いられ、契約変更等の業務手続を処理する集中業務処
    理システムであって、 顧客から業務手続の請求案件を受け付ける複数の拠点に
    配備され、請求案件のデータを送信する端末装置と、 前記複数の拠点から請求案件を受け取って集中的に処理
    する集中業務処理装置と、 を含み、 前記集中業務処理装置は、 業務手続を遂行するための処理を規定する処理ノードを
    含む業務プロセス機能を備え、個々の請求案件を特定す
    る案件特定情報を前記業務プロセスに沿って進行させる
    業務フローシステムと、 前記業務フローシステムから外出し形式で設けられ、処
    理対象になる請求案件情報を格納する業務支援データベ
    ースと、 前記業務フローシステムから外出し形式で設けられ、各
    請求案件の業務プロセス上での状況を管理する案件管理
    データ記録データベースと、 前記処理ノードに位置する案件特定情報が示す請求案件
    に関して、前記処理ノードで規定される処理を前記業務
    支援データベースおよび前記案件管理データ記録データ
    ベースに対して行なうアプリケーションである処理アク
    ティビティを備えるアプリケーションサーバと、 を含み、前記業務フローシステムは、前記処理アクティ
    ビティによる処理が終了した請求案件の案件特定情報
    を、現在の処理ノードから次の処理ノードへと進めるこ
    とを特徴とする集中業務処理システム。
14. 【請求項１４】 多数の顧客と契約関係をもつ企業等に
    用いられ、契約変更等の業務手続を処理する集中業務処
    理システムであって、 顧客から業務手続の請求案件を受け付ける複数の拠点に
    配備され、請求案件のデータを送信する端末装置と、 前記複数の拠点から請求案件を受け取って集中的に処理
    する集中業務処理装置と、 を含み、 前記集中業務処理装置は、 業務手続を遂行するための処理を規定する処理ノードを
    含む業務プロセス機能を備え、個々の請求案件を特定す
    る案件特定情報を前記業務プロセスに沿って進行させる
    業務フローシステムと、 前記業務フローシステムから外出し形式で設けられ、処
    理対象になる請求案件情報を格納する業務支援データベ
    ースと、 前記業務フローシステムから外出し形式で設けられ、各
    請求案件の業務プロセス上での状況を管理する案件管理
    データ記録データベースと、 前記業務プロセスの処理ノードに対応するワークリスト
    送受信箱を有し、前記処理ノードに到達した案件特定情
    報をワークリスト送受信箱に保持するワークリストサー
    バと、 前記ワークリスト送受信箱内の案件特定情報が示す請求
    案件に関して、前記処理ノードで規定される処理を前記
    業務支援データベースおよび前記案件管理データ記録デ
    ータベースに対して行なうアプリケーションである処理
    アクティビティを備えるアプリケーションサーバと、 を含み、前記業務フローシステムは、前記処理アクティ
    ビティによる処理が終了した請求案件の案件特定情報
    を、現在の処理ノードのワークリスト送受信箱から次の
    処理ノードのワークリスト送受信箱へと進めることを特
    徴とする集中業務処理システム。
15. 【請求項１５】 多数の顧客と契約関係をもつ企業等に
    用いられ、契約変更等の業務手続を処理する集中業務処
    理方法であって、 業務手続を遂行するための処理を規定する処理ノードを
    含む業務プロセス機能を備える業務フローシステムに
    て、個々の請求案件を特定する案件特定情報を前記業務
    プロセスに沿って進行させるステップと、 前記業務プロセスの処理ノードに対応するワークリスト
    送受信箱へと、前記処理ノードに到達した案件特定情報
    を保持するステップと、 それぞれ前記業務フローシステムから外出し形式で設け
    られ、処理対象になる請求案件情報を格納する業務支援
    データベースおよび各請求案件の業務プロセス上での状
    況を管理する案件管理データ記録データベースに対し
    て、前記ワークリスト送受信箱内の案件特定情報が示す
    請求案件について、前記処理ノードで規定される処理を
    行なうステップと、 前記業務フローシステムを利用して、前記処理アクティ
    ビティによる処理が終了した請求案件の案件特定情報
    を、現在の処理ノードのワークリスト送受信箱から次の
    処理ノードのワークリスト送受信箱へと進めるステップ
    と、 を含むことを特徴とする集中業務処理方法。
16. 【請求項１６】 コンピュータにて実行可能なプログラ
    ムを格納した記録媒体であって、前記プログラムは、多
    数の顧客と契約関係をもつ企業等において契約変更等の
    業務手続を処理するためのプログラムであり、 業務手続を遂行するための処理を規定する処理ノードを
    含む業務プロセス機能を備える業務フローシステムに
    て、個々の請求案件を特定する案件特定情報を前記業務
    プロセスに沿って進行させるステップと、 前記業務プロセスの処理ノードに対応するワークリスト
    送受信箱へと、前記処理ノードに到達した案件特定情報
    を保持するステップと、 それぞれ前記業務フローシステムから外出し形式で設け
    られ、処理対象になる請求案件情報を格納する業務支援
    データベースおよび各請求案件の業務プロセス上での状
    況を管理する案件管理データ記録データベースに対し
    て、前記ワークリスト送受信箱内の案件特定情報が示す
    請求案件について、前記処理ノードで規定される処理を
    行なうステップと、 前記業務フローシステムを利用して、前記処理アクティ
    ビティによる処理が終了した請求案件の案件特定情報
    を、現在の処理ノードのワークリスト送受信箱から次の
    処理ノードのワークリスト送受信箱へと進めるステップ
    と、を前記コンピュータに実行せしめることを特徴とす
    る、コンピュータにて読取可能な記録媒体。