集中業務処理システム、集中業務処理装置および方法
【課題】 業務処理を迅速化し、コストを低減する。一の顧客から複数の請求案件を受け付けたとき、それらの案件を適切に処理する。
【解決手段】 拠点端末装置１４は、顧客からの請求案件を電子データのかたちで集中業務処理装置１０に送る。集中業務処理装置１０の業務フローシステム２０は複数の業務プロセス機能を備える。ディスパッチャ２２は、請求案件に対応する業務プロセス機能を業務フローシステム２０に起動させる。業務フローシステム２０には複合同時判定プロセスが備えられている。この判定プロセスは、一の顧客から複数の請求案件を受け付けたとき、それらが複合処理案件または同時処理案件か否かを判定する。複合処理案件については、一の請求案件の後に別の請求案件が処理される。同時処理案件については、複数案件が同時に併行して処理される。電話確認等は、同期処理ノードを利用してまとめて行われる。
【解決手段】 拠点端末装置１４は、顧客からの請求案件を電子データのかたちで集中業務処理装置１０に送る。集中業務処理装置１０の業務フローシステム２０は複数の業務プロセス機能を備える。ディスパッチャ２２は、請求案件に対応する業務プロセス機能を業務フローシステム２０に起動させる。業務フローシステム２０には複合同時判定プロセスが備えられている。この判定プロセスは、一の顧客から複数の請求案件を受け付けたとき、それらが複合処理案件または同時処理案件か否かを判定する。複合処理案件については、一の請求案件の後に別の請求案件が処理される。同時処理案件については、複数案件が同時に併行して処理される。電話確認等は、同期処理ノードを利用してまとめて行われる。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明は、多数の顧客と契約関係をもつ企業等に用いられ、契約変更等の業務手続を処理する集中業務処理システムに関する。本発明は典型的には生命保険の業務処理に利用される。
【０００２】
【従来の技術】生命保険契約には、顧客のライフサイクルに対応した長い期間にわたって継続するという特色がある。この長期間の契約の間には、支払や契約変更などに関する各種の多様な手続が発生する。こうした契約中の手続を保全手続という。
【０００３】生命保険会社は多数の顧客を有しており、大きな生命保険会社の場合、数百万から一千万といった数の契約をもっている。それら多数の契約で生じる多様な保全手続の請求案件を確実かつ効率よく処理することが求められる。
【０００４】従来の保全手続業務システムの一例では、業務処理拠点としての支部が全国に分散配置される。各地域の支部の上に支社が配置され、そして全国の支社が本社に統括される。これら支部、支社および本社は、分散系クライアントサーバ型オンラインシステムを利用して情報を共有するものの、手続請求案件の書類は物流ベースで回送、処理されている。
【０００５】具体的には、顧客の請求書類は支部で受けつけられる。支部は、一部の保全手続を処理する権限をもつ。残りの保全手続の請求書類は、支部から支社へと物流により回送される。支社は、支部より広範囲の権限をもつものの、すべての書類の処理はできない。そこで、支社でも一部の書類が処理され、残りの書類は本社に回送される。また、特殊な案件や複雑な案件は、支部および支社で確実な処理方法を判断できないので、やはり本社に回送される。
【０００６】本社では、基本的にすべての案件の処理が可能である。しかし物流で送られてきた書類の中には、不備のある書類もある。その場合、請求書類は本社から支社を経て支部へと回送される。そして支部は、顧客との応対により書類の不備を解消し、書類を再度本社へ回送する。
【０００７】
【発明が解決しようとする課題】上記従来のシステムでは、書類の物流を前提としつつ、処理能力を部分的に支部および支社に与える分散型システムを採用している。この分散型システムにより、一部の手続についてのリードタイム短縮が図られている。しかしながら、本社で処理される請求書類については、請求書類を物流で輸送しているために、処理に時間がかかってしまう。そして書類の不備が本社で発見された場合には、さらに、本社−支部間の書類往復時間が必要となる。これらの処理時間は極力短縮することが望まれる。
【０００８】また、請求書類の物流を前提とするシステムでは、書類が回送されるたびに、授受確認および担当者への仕分けが必要であり、これらハンドリング作業を極力減らすことが望まれる。
【０００９】さらに、書類物流によるタイムラグの間に、オンライン情報システム側で、契約のマスターファイルが更新される可能性がある。そのため、書類受付の都度、契約内容を照会するためにオンラインシステムへのパンチ入力が必要である。こうした作業負担も軽減することが望ましい。
【００１０】また、書類物流の不利の解消に加えて、業務処理システムには環境変化に対応する能力が高いことが求められる。募集チャネルの拡大、新しい金融商品等の将来の対応を考慮すると、現行業務のみならず、業務処理の追加や変更などにも柔軟に対応できるシステムの提供が望まれる。
【００１１】また、上述したように、保険会社は多数の保有契約に関して多様な保全手続を行なう。そのため、書類物流による不利の解消も含めて、１件あたりの業務・維持コストを削減することが強く望まれる。この点は、新商品の低ローディング化という流れのうえでも望まれる。
【００１２】さらに、業務を支部および支社に分散する形態では、全国に配置される業務職員に対する教育の負担が大きく、教育コストも大きいという不利がある。
【００１３】本発明の更なる課題として、以下に説明するように、一の顧客から一度に複数の請求書類を受けつけたときの業務処理の改善が求められる。
【００１４】生命保険などでは、長期間の契約を通じて多様な保全手続が行なわれるので、一の顧客から複数の請求書類を受け付けることもある。これには、一つの契約に対して複数の請求書類が受け付けられる場合はもちろんのこと、複数の契約に対して複数の請求書類が受けつけられることもある。後者は、例えば家族を構成する複数人の契約についての請求書類を受けつける場合である。複数の請求書類の同時受付頻度は、約２０％に達すると考えられる。
【００１５】このような手続は、顧客にとって見れば、生命保険会社との間の単一の手続に見える。しかし実際には、複数の請求にそれぞれ対応する複数の保全手続が行なわれる。複数の保全手続の中には、業務処理上の順序性が要求されるものもある。すなわち、一の手続を行なってから出ないと、次の手続を行なうべきでないことがある。こうした必要順序に従った手続の確実性を向上することが望まれる。
【００１６】また保全手続においては、顧客に対する電話確認が行なわれ、また保全手続の処理結果が通知される。複数の保全手続がばらばらに処理されると、上記の確認および通知もばらばらに行なわれる。顧客は、一回の請求に関連して、何度も電話確認に対応したり、何度も通知を受けとることになる。確認や通知をまとめて行なうことができれば、顧客の手間を減らして顧客サービスを向上することができ、業務処理側の手間も減らせると考えられる。このような機能を、多数の契約と多様な保全業務を管理する条件下で実現することが望まれる。
【００１７】本発明は上記課題に鑑みてなされたものであり、その目的は、従来の書類物流の不利を解消し、柔軟性が高く、業務処理コストも低減できる技術を提供することにある。
【００１８】また本発明の別の目的は、一の顧客からの複数の請求書類に対する業務処理を改善できる技術を提供することにある。
【００１９】本発明の目的は特許請求の範囲における独立項に記載の特徴の組み合わせにより達成される。また従属項は本発明の更なる有利な具体例を規定する。
【００２０】
【課題を解決するための手段】（１）本発明のある態様は、多数の顧客と契約関係をもつ企業等に用いられ、契約変更等の業務手続を処理する集中業務処理システムに関する。集中業務処理システムは、顧客から業務手続の請求案件を受け付ける複数の拠点に配備され、請求案件のデータを送信する端末装置と、前記複数の拠点から請求案件を受け取って集中的に処理する集中業務処理装置と、を含む。前記集中業務処理装置は、各種の請求案件にそれぞれ対応する複数の業務プロセス機能を備え、顧客からの業務手続の請求案件に対応する業務プロセスに沿って請求案件の処理を進行させる業務フローシステムと、前記業務フローシステムとのインターフェース機能をもち、前記請求案件に対応する業務プロセス機能を前記業務フローシステムに起動させるプロセス起動手段と、を含む。
【００２１】本発明によれば、請求案件の書類はデータのかたちで集中業務処理装置へと送られる。したがって書類の物流に伴う制約から解放され、手続を迅速化でき、書類の受渡しに伴うハンドリング業務も削減できる。また書類の不備を早期に発見でき、不備への対応も早められる。
【００２２】また本発明によれば、集中業務処理システムには、各種の請求案件にそれぞれ対応する業務プロセス機能をもった業務フローシステムが設けられる。手続の新設、追加、変更などに対しては、業務プロセス機能の新設、追加、変更などにより対処できる。したがって、業務処理の変化に柔軟に対応することができる。
【００２３】また本発明によれば、上述の物流の削減と、それに関連する業務の削減、さらには、予め用意した複数の業務プロセス機能を選択的に用いる効率的な業務処理により、業務コストを削減できる。
【００２４】さらに本発明によれば、集中事務側という局所化した環境で業務作業人員による作業が行われ、それら人員の教育も行われるようなシステムを構成可能である。高度な教育、作業を簡素化、標準化されたかたちで実現するように図れる。
【００２５】なお、好ましくは、拠点の端末装置は、顧客から受け付けた請求書類を、スキャナー等の読み取り装置を用いて電子化する。請求書類のイメージデータを集中業務処理装置に送ることにより、書類の原形を用いた各種の処理を集中業務処理装置で実行できる。特に、生命保険等の請求書類には、印鑑の押印と自筆の署名が求められる。イメージデータを用いることにより、これらの原形が必要な構成部分に対して、集中業務処理装置で照合等の適切な処理ができる。
【００２６】また、拠点の端末装置は、例えば会社の支部等に固定的に配置されるコンピュータ装置であるが、これに限定はされない。端末装置は、例えば携帯端末でもよく、携帯端末は、支部等を介して、あるいは集中業務処理装置と直接的に通信する。また拠点と集中業務処理装置の通信には、専用オンラインシステムが用いられてもよく、またインターネットなどが用いられてもよい。
【００２７】また、本発明において、処理対象の業務は、例えば生命保険会社の保全手続に関する業務である。また処理対象の業務は、新規契約募集（募集訪問を含む）および承諾プロセスなどでもよい。処理対象の業務はこれらに限定されない。
【００２８】（２）本発明の一態様の集中業務処理システムは複合処理判定手段を含む。複合処理判定手段は、一の顧客に関して複数の請求案件が取得されたときに、それら複数の請求案件が、一の請求案件の終了後に別の請求案件を処理すべき複合処理案件に該当するか否かを判定する。
【００２９】好ましくは、前記複合処理判定手段は、前記業務プロセスと同様の形態の複合判定プロセスとして用意されている。前記プロセス起動手段は、一の顧客に関して複数の請求案件が取得されたときに前記複合判定プロセスを起動し、さらに前記複合判定プロセスの判定結果に従い、複合処理案件に対応する複数の業務プロセスを、一の業務プロセスの終了後に次の業務プロセスが行なわれるように順次起動することにより、複合処理案件の適正順序処理を実現する。
【００３０】好ましくは、前記プロセス起動手段は、一の顧客に関して一の請求案件が取得されたときにはその請求案件に対応する業務プロセスを直接的に起動し、一の顧客に関して複数の請求案件が取得されたときには前記複合判定プロセスを起動する。
【００３１】本発明によれば、複合処理案件、すなわち、決まった順番で処理されるべき複数の請求案件が受けつけられたことを自動的に判定できる。そして、複合処理案件は関連づけられて実行、管理される。これにより、複合処理案件を必要な順番に従って確実に処理できる。
【００３２】また本発明では、複数の請求案件に対応する複数の業務プロセスを順番に起動し、それらを直列に連結することにより、複合処理案件を処理する。こうした構成とは対照的に、複合処理案件に対応する専用の長いプロセスを用意する構成も考えられる。しかし、請求案件の処理に変更が生じた場合、単独案件用の業務プロセスに加えて、複合処理案件のプロセスもすべて変更しなければならない。本発明の場合は、連結方式を採用しているので、一つの案件に関して処理の変更が生じた場合、対応する業務プロセスのみを変更すればよい。したがってシステムの保守性がよい、という利点が得られる。
【００３３】また、本発明では、複合処理案件を判定する手段を、業務プロセスと同様の形態で構成し、ワークフローシステムの応用である業務フローシステムの一部としている。そして、取得された請求案件の数に応じて、業務プロセスを起動したり、判定プロセスを起動したりと、業務フローシステムのプロセス起動を切りかえる。したがって、業務フローシステムの高い柔軟性を利用して複合処理案件に適切に対処できる。
【００３４】（３）本発明の好ましい一態様では、前記複数の業務プロセスの各々は、対応する請求案件の処理を達成するための複数の処理ノードで構成されている。前記複合処理案件に対応する業務プロセスは、前記複数の処理ノードの終わりに次案件起動ノードを有する。前記業務フローシステムは、複合処理案件に対応する一の業務プロセスが前記次案件起動ノードに到達すると、複合処理案件に対応する次の業務プロセスを起動する。
【００３５】前記複数の処理ノードは、顧客に対する電話確認ノードを含んでもよい。好ましくは、前記電話確認ノードでは、複合処理案件として現処理中の請求案件の後段で処理される請求案件の内容を確認でき、現処理中の請求案件と後段の請求案件の電話確認をまとめて行う。
【００３６】本発明によれば、業務プロセスの終わりに次案件起動ノードが設置されている。業務プロセスが次案件機能ノードに達すると、複合処理対象の次の案件が求められ、その案件のための業務プロセスが起動される。したがって、ワークフローシステムの技術を基礎として、そのプロセスに次案件機能ノードを設けるという簡素な構成により、複数プロセスを連結して、複合処理案件の適正順序処理を実現できる。
【００３７】また本発明によれば、業務プロセスの電話確認ノードにて、現処理中の電話確認とともに、後続処理される案件の電話確認も行うことができる。すなわち、順番に時期をずらして処理される複合処理案件において、電話確認については同時処理を実現できる。顧客にとってみれば、１回の請求に対する電話確認をまとめて受けられるので、電話応対の手間が減る。したがって顧客に対するサービス性の向上が図れる。また業務処理側の手間の削減も図れる。特に、本発明では、前側の案件で後続案件を確認しているので、同時電話確認を早い段階で行うことができ、この点でもサービス性を向上できる。
【００３８】また本発明のシステムは、好ましくは、前記電話確認ノードでの電話確認が不成功のとき、電話確認ノードの処理を待機後に再び実行させることにより、前記現処理中の請求案件と後段の請求案件の電話確認を再び同時に実行させる。これにより、複合処理案件における同時電話確認の利点を確実に生かせる。
【００３９】（４）本発明の一態様の集中業務処理システムは同時処理判定手段を含む。同時処理判定手段は、一の顧客に関して複数の請求案件が取得されたときに、それら複数の請求案件が、同時に併行して処理されるべき同時処理案件に該当するか否かを判定する。
【００４０】好ましくは、前記同時処理判定手段は、前記業務プロセスと同様の形態の同時判定プロセスとして用意されている。前記プロセス起動手段は、一の顧客に関して複数の請求案件が取得されたときに前記同時判定プロセスを起動し、さらに前記同時判定プロセスの判定結果に従い、同時処理案件に対応する複数の業務プロセスを起動する。前記業務フローシステムは、それら業務プロセスの少なくとも一部の処理タイミングを同期させる。
【００４１】好ましくは、前記プロセス起動手段は、一の顧客に関して一の請求案件が取得されたときにはその請求案件に対応する業務プロセスを直接的に起動し、一の顧客に関して複数の請求案件が取得されたときには前記同時判定プロセスを起動する。
【００４２】本発明によれば、同時処理案件、すなわち、同時に併行して処理されるべき複数の請求案件が受けつけられたことを自動的に判定できる。同時処理案件は関連づけられて実行、管理される。そして、業務フローシステムにより、それら業務プロセスの少なくとも一部の処理タイミングが同期するように、業務プロセスが進行される。処理タイミングの同期は、例えば電話確認および顧客への通知に関して行われる。このように、本発明によれば、同時処理案件を効率良く短期間で処理できる。処理タイミングの同期によって顧客の手間を削減してサービス性を向上し、業務処理側の手間の削減も図れる。
【００４３】また本発明では、複数の請求案件に対応する複数の業務プロセスを一斉に進行させることにより、同時処理案件を処理する。こうした構成とは対照的に、同時処理案件に対応する専用の併行処理プロセスを用意する構成も考えられる。しかし、請求案件の処理に変更が生じた場合、単独案件用の業務プロセスに加えて、同時処理案件のプロセスもすべて変更しなければならない。本発明の場合は、一つの業務プロセスを単独処理に用いたり、他のプロセスとの同時処理に用いており、つまり、業務プロセスの使い分けている。したがって、一つの案件に関して処理の変更が生じた場合、対応する業務プロセスのみを変更すればよく、システムの保守性がよい、という利点が得られる。
【００４４】また、本発明では、同時処理案件を判定する手段を、業務プロセスと同様の形態で構成し、ワークフローシステムの応用である業務フローシステムの一部としている。そして、取得された請求案件の数に応じて、業務プロセスを起動したり、判定プロセスを起動したりと、業務フローシステムのプロセス起動を切りかえる。したがって、業務フローシステムの高い柔軟性を利用して同時処理案件に適切に対処できる。
【００４５】（５）本発明の好ましい一態様では、前記複数の業務プロセスの各々は、対応する請求案件の処理を達成するための複数の処理ノードで構成されている。前記同時処理案件に対応する業務プロセスは、複数の処理ノードの中に同期処理ノードを有する。前記業務フローシステムは、同時処理案件に対応する複数の業務プロセスを併行して進行させるときに同期処理ノードの処理タイミングを同期させる。
【００４６】前記同期処理ノードは、顧客に対する電話確認ノードを含んでもよい。本システムは、前記電話確認ノードでの電話確認が不成功のとき、前記複数の業務プロセスにおける電話確認ノードの処理を再び同時に実行させてもよい。
【００４７】また前記同期処理ノードは、顧客宛の手続処理結果の発送に関する処理ノードを含んでもよい。
【００４８】本発明によれば、同期処理案件のための複数の業務プロセスを併行して進行するとき、それら業務プロセスに設けられた同期処理ノードが利用される。例えば、顧客に対する電話確認を、複数の業務プロセスで同時に行なうことができる。また顧客に対する処理結果通知を、複数の業務プロセスで同時に発行できる。本発明によれば、このような同期処理を確実に管理して実現でき、これにより、顧客の手間を減らして顧客サービスの向上を図り、また業務処理側の手間の削減も図れる。
【００４９】また本発明によれば、電話確認ノードでの電話確認が不成功のとき、複数の業務プロセスにおける電話確認ノードの処理を再び同時に実行させる。所定の再確認時刻や確認間隔を設定してもよい。例えば、顧客が不在の場合でも、再度同時確認ができる。したがって、本発明の同期処理ノードの利点を確実に生かせる。
（６）本発明の一態様の集中業務処理システムは複合同時判定手段を含む。複合同時判定手段は、一の顧客に関して複数の請求案件が取得されたときに、それら複数の請求案件が、一の請求案件の後に別の請求案件を処理すべき複合処理案件に該当するか否か、および、同時に併行して処理されるべき同時処理案件に該当するか否か、を判定する。
【００５０】好ましくは、前記複合同時処理判定手段は、複数の請求案件の組合せを、同時処理案件、複合処理案件およびその他に仕分けするための複合同時判定テーブルを用いる。
【００５１】好ましくは、前記複合同時処理判定手段は、前記業務プロセスと同様の形態の複合同時判定プロセスとして用意されている。前記プロセス起動手段は、一の顧客に関して複数の請求案件が取得されたときに前記複合判定プロセスを起動する。さらに前記プロセス起動手段は、前記複合同時判定プロセスの判定結果に基づいて、前記複数の請求案件が複合処理案件である場合には、それら請求案件に対応する複数の業務プロセスを、一の業務プロセスの終了後に次の業務プロセスが行なわれるように順次起動する。また前記プロセス起動手段は、前記複数の請求案件が同時処理案件である場合には、それら請求案件に対応する複数の業務プロセスを併行処理されるように起動する。
【００５２】好ましくは、前記プロセス起動手段は、一の顧客に関して一の請求案件が取得されたときにはその請求案件に対応する業務プロセスを直接的に起動し、一の顧客に関して複数の請求案件が取得されたときには前記複合同時判定プロセスを起動する。
【００５３】本発明によれば、上述した複合処理案件および同時処理案件の機能が一つのシステムに組み込まれる。したがって、それらの機能が両方とも得られる。
【００５４】また本発明では、複合同時判定テーブルを用いて、複合処理案件、同時処理案件およびその他の案件を判別する。新種の保全手続が設定されたような場合でも、そうした新種の手続に対して、テーブルの変更によって柔軟に対応できる。
【００５５】（７）本発明は、上述した集中業務処理システムの態様には限定されない。本発明の別の態様は、例えば、集中業務処理装置、集中業務処理方法、またはその方法を実現するプログラムを記録した媒体である。
【００５６】なお上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションも又発明となりうる。
【００５７】
【発明の実施の形態】以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態はクレームにかかる発明を限定するものではなく、又実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
【００５８】図１は、集中業務処理システム１の全体構成を示している。本実施の形態では、生命保険会社の保全業務に本発明が適用される。保全業務とは、前述したように、支払や契約変更など、契約に関連して発生する手続の業務をいう。ただし、本発明が保全業務以外の業務、例えば新規契約業務（顧客とのコンタクト（募集訪問に関する業務など）および関連する承諾プロセスに適用されてもよい。また本発明が生命保険以外の業務処理に適用されてもよい。
【００５９】図１に示すように、集中業務処理装置１０は、センタ集配サーバ１２を介して拠点端末装置１４と接続されている。拠点端末装置１４は、全国に分散配置された生命保険会社の支部等の手続受付窓口に配備されている。手続受付窓口は、顧客から保全手続の請求書類を受け取る。拠点端末装置１４は、書類読取り装置としてのスキャナを有する。請求書類はスキャナによりイメージデータに変換される。さらに、書類に記入された文字等は、文字認識機能を用いてコード化される。これらイメージデータおよびコードデータは、請求案件情報としてセンタ集配サーバ１２に送られる。センタ集配サーバ１２は、請求案件情報を集中業務処理装置１０に受け渡す。集中業務処理装置１０は、受け取った請求案件情報に基づいた業務処理を行なう。
【００６０】拠点端末装置１４は、営業員等により携帯される携帯端末でもよい。携帯端末は、支部を経由してセンタと通信してもよく、支部を経由せずにセンタと通信してもよい。
【００６１】また集中業務処理装置１０は、ホストゲートウエイサーバ１６を介して、マスターファイルを格納するホストシステム１８と接続されている。ホストシステム１８は、全部の契約のマスターファイルを保管している。集中業務処理装置１０により業務処理が行なわれると、業務処理にしたがってマスターファイルが書きかえられる。
【００６２】図２は、集中業務処理装置１０の構成を示している。業務フローシステム２０は、いわゆるワークフローシステム（ワークフローエンジン、ワークフローシステム本体）の応用である。業務フローシステム２０には各種の業務プロセスが定義されており、これにより業務フローシステム２０は各種の業務プロセス機能を備える。これら業務プロセスのそれぞれは特定の請求案件に対応している。
【００６３】各業務プロセスは、図示のように複数のノード（四角形）で構成される。業務プロセスに沿って各ノードの処理を順次実行することにより、請求案件の処理が達成される。ただし、業務フローシステム２０は、実際に請求案件情報を処理するのではなく、業務プロセスに沿って処理を進行させる役割を持つ。この点については後述する。
【００６４】ディスパッチャ２２は、本発明のプロセス起動手段に相当し、集中業務処理装置１０の外部インターフェース機能の一部である。ディスパッチャ２２は、業務フローシステム２０とのインターフェース機能をもつ。ディスパッチャ２２は、請求案件が取得されたときに、その請求案件に対応する業務プロセスを業務フローシステム２２に起動させる。
【００６５】業務支援データベース２４は請求案件情報を格納している。業務支援データベース２４は、業務フローシステム２０から外出し形式で、つまり別体に設けられている。請求案件情報は、拠点から送られてきた情報である。上述のように、請求案件情報は、請求書類のイメージデータと、イメージデータから得られたコードデータを含む。業務プロセスの各ノードでは、業務支援データベース２４の請求案件情報が処理対象になる。
【００６６】案件管理データ記録データベース２６は、各種請求案件の業務プロセス上での状況を管理する。すなわち、請求案件が業務プロセスのどこまで進んでおり、どのような状態にあるか、といった情報を管理する。案件管理データ記録データベース２６も、業務支援データベース２４と同様、業務フローシステム２０から外出し形式で設けられている。
【００６７】アプリケーションサーバ２８は、業務プロセスの各ノードで用いられるアプリケーションソフトを有している。各ノードでの必要に応じて適当なアプリケーションがクライアント端末等に提供される。
【００６８】ワークリストサーバ３０は、いわゆるメールボックスの機能をもつ。ワークリストサーバ３０は、業務フローシステム２０と、その外側に位置するアプリケーションサーバ２８との間での、案件に関する情報の受け渡しに利用される。業務プロセスのノードからノードへの請求案件の移行は、ワークリストサーバ３０を介して実現される。
【００６９】図３は、業務フローシステム２０、ディスパッチャ２２、業務支援データベース２４、案件管理データ記録ベース２６、アプリケーションサーバ２８およびワークリストサーバ３０の機能と関係を示す。
【００７０】図３には、業務フローシステム２０に関連して典型的な業務プロセスの一例が示されている。業務プロセスは、振分（ホスト照会）ノード、点検ノード、二次点検ノード、認証ノードおよびホスト処理（マスターファイル更新）ノードを有する。振分ノードおよびホスト処理ノードでは業務処理装置により機械的（自動）処理が行われる。点検ノード、二次点検ノードおよび認証ノードでは、担当者が端末装置を操作して業務処理を行う。
【００７１】振分ノードでは、拠点から入手した請求案件情報（コードデータ）を基に、ホストシステムに対するオンライン照会が自動的に行われ、マスターファイルから業務処理に必要なデータが取り込まれる。また、図では省略されているが、プロセス中の適当なノードへと請求案件を振り分ける処理が行われる。点検ノードでは基本的点検作業が行なわれる。基本的点検作業は、請求書イメージと入力項目との照合、必要書類の点検などである。二次点検では、点検者の修正入力に対する相互点検（内部牽制的な意味合い）、認証では、高額支払などの手続内容に応じた要件の確認および決済が行われる。ホスト処理は最終的な更新処理であり、ホストシステムに格納されたマスタファイルに対して自動的（機械的）な更新処理が行われる。
【００７２】図３の業務プロセスに対応する請求案件がセンタ集配サーバ１２から集中業務処理装置１０に提供されたとする。このとき、ディスパッチャ２２は、請求案件を識別し、その請求案件に対応する図３の業務プロセスを業務フローシステム２０に起動させる。
【００７３】業務プロセスが起動すると、業務フローシステム２０は、処理すべき請求案件を、最初のノードである振分ノードに進める。請求案件が、プッシュ形式でワークリストサーバ３０のワークリスト送受信箱に入れられる。
【００７４】ここで、請求案件情報（イメージおよびコード）自体は、業務支援データベース２４に格納されており、業務プロセス上では動かない。業務プロセス上を移動するのは、主として請求案件を特定するための情報である。そこで、本実施の形態では、プロセスに沿ってノードおよびワークリストサーバを移動する情報を、案件特定情報と呼ぶ。
【００７５】案件特定情報が最初のワークリストサーバに入ったことを受けて、アプリケーションサーバ２８では、アプリケーションである振分アクティビティが機能する。請求案件に対応するマスタファイルが、ホストシステム１８に対して照会され、必要なデータが取り込まれ、業務支援データベース２４の請求案件情報に与えられる。この処理は上述のように自動的に行われる。
【００７６】振分ノードの処理が終わると、処理の終了が分かるように、ワークリストサーバ内の情報が振分アクティビティにより書き換えられる。例えば、処理終了を示すフラグが立てられたり、マークが付けられる（後のノードでも同様）。これに応えて、業務フローシステム２０は、案件特定情報を、振分ノードのワークリスト送受信箱から、点検ノードのワークリスト送受信箱へと移動させる。
【００７７】点検ノードの作業担当者は、クライアント端末を操作して、ワークリスト送受信箱内の請求特定情報により特定される請求案件を点検する。これは、アプリケーションサーバ２８から提供されるアプリケーションを用いた点検アクティビティにより実現される。点検処理は、業務支援データベース２４内の請求案件情報を用いて行なわれる。また、点検が行なわれたことを示す情報は、請求案件の状況情報として、案件管理データ記録データベース２６に記録される。
【００７８】業務フローシステム２０は、点検ノードのワークリスト送受信箱内にある請求案件の処理が終了すると、請求案件特定情報を、点検ノードのワークリスト送受信箱から、二次点検ノードのワークリスト送受信箱へと移動させる。これにより業務プロセスが二次点検ノードへと移行する。
【００７９】二次点検ノードおよび認証ノードでも、点検ノードと同様に、外出しの業務支援データベース２４および案件管理データ記録ベース２６に対して、アプリケーションサーバ２８のアプリケーションを用いた処理が行なわれる。ただし、各ノードでは、異なる作業担当者により作業が行なわれる。
【００８０】認証ノードの処理が完了すると、案件特定情報は、ホスト処理ノードのワークリスト送受信箱へと移される。これに応えて、アプリケーションサーバ２８側でホスト処理アクティビティが機能する。ホストシステム１８にアクセスして、請求案件の処理結果をマスターファイルに反映する更新処理が行われる。業務フローシステム２０は、ホスト処理の送受信箱内にある案件の処理が終了すると、その案件についての業務プロセスを終了させる。
【００８１】以上、図３を参照して、本実施の形態における基本的な業務処理の流れを説明した。
【００８２】ここで、一般的なワークフローシステムでは、処理対象の情報が業務プロセス上を移動する。そのため、ワークフローシステム内の案件を外から参照したり、案件を外から制御することは困難であり、そのような処理を実現するためにはワークフローシステムの大幅な変更等が必要である。
【００８３】これに対し、本実施の形態では、ワークフローシステム上は、案件特定情報が移動していく。実際に処理される案件情報は、ワークフローシステムの外の業務支援データベースにいる。そして、案件情報の処理も、ワークフローシステムの外のアプリケーションサーバで行われる。これにより、ワークフローシステムのプロセス途中における案件情報の参照や制御、案件間の情報共有化を、簡単な構成で実現している。
【００８４】上記の利点を得るために、本実施の形態では、ワークリストサーバが好適に利用されている。プロセス上の各ノードで、案件特定情報がワークフローシステムからワークリスト送受信箱に入れられる。アプリケーションサーバは、送受信箱を見て、ワークフローシステム外部で、該当ノードの必要な処理を行う。処理が終わると、案件特定情報がワークフローシステムに戻され、次のノードに進められる。すなわち、ワークリストサーバにより、案件特定情報を介して、ワークフローシステムとアプリケーションサーバの案件受け渡しが実現されている。
【００８５】なお、案件特定情報とともに、請求日時等の幾つかの情報がプロセス上を移動してもよい。これら情報は、ワークリスト送受信箱の内容を表示するときなどに便利に用いられる。
【００８６】また、図３の業務プロセスは、業務フローシステム２０に用意された複数の業務プロセスの一つである。本実施の形態では、図４に示す各種の業務プロセスが用意されている。これらの中には、図３に示されるように振分、点検、二次点検、認証およびホスト処理で構成されるものもあり、それ以外のノードをもつものもある。また、図４に示されるように、業務プロセスは、支払、契約変更および汎用に大別される。汎用は、集中処理装置または拠点からの要求により案件内容を照会するため等、業務を特定しないプロセスである。その他、これら業務プロセスのほかに、後述するように、複合処理案件および同時処理案件を判定するための判定プロセスが業務フローシステム２０に用意されている。
【００８７】また、集中業務処理装置１０には、全国の支社から次々と多数の請求案件が送られ、それら請求案件に対応する業務プロセスが起動される。したがって、図３の業務プロセス上を幾つもの請求案件が移動していく。
【００８８】図５は、集中業務処理装置１０で用いられる業務処理作業用の画面の一例である（図面では、請求書類のイメージ等は部分的に省略および簡略化されている、以下同じ）。図５には、図３の点検ノードで端末上に表示される画面が示されている。画面の左半部には、顧客により記入された請求書類のイメージが表示されている。また画面の右半部には、イメージデータから文字認識機能により読み取られたコードデータ、および、そのデータを基にホストシステムのマスタ−ファイルを照会した結果が表示される。点検作業者は、両者を見比べて相違の有無を点検する。
【００８９】図１の説明に戻り、集中業務処理装置１０はさらに入力支援部３２、認証・権限管理部３４、案件管理ツール３６、運用管理部３８を有する。入力支援部３２は、各作業者による入力作業を支援するためのインターフェースを提供する。認証・権限管理部３４は、各作業者の認証資格や作業権限を管理する。案件管理ツール３６は、処理中の案件に対して中断、取消等の割込制御を行なう。運用管理部３８は、装置内の各部にプログラムを配布したり、システムの稼働状態を確認するなどの機能をもつ。
【００９０】また集中業務処理装置１０は外部インターフェース部４０を有する。外部インターフェース部４０は、前述のディスパッチャ２２のほかに、拠点通知部４２、不備管理部４４、印刷サーバ４６、ホスト連動サーバ４８およびホスト・既存運用システムファイル転送部５０を含む。
【００９１】拠点通知部４２は、センタ集配サーバ１２を経由し、拠点端末装置１４に対して各種の情報を通知する。案件照会の応答情報も拠点通知部４２により通知される。
【００９２】不備管理部４４は、業務プロセスにて請求書類の不備が発見されたとき、その不備および不備解消のための情報を管理する。不備を通知する情報が拠点端末装置１４に送られ、拠点端末１４から不備を解消した書類のデータを受け取る。
【００９３】印刷サーバ４６は、請求案件情報等の印刷処理を管理する。ホスト連動サーバ４８は、ホストゲートウエイサーバ１６を介したホストシステム１８との連動を実現する。この機能により、ホスト１８のマスターファイルが参照され、請求案件の処理結果がマスターファイルに反映される。ホスト・既存運用システムファイル転送部５０は入力支援やシステム構成定義などのデータ転送機能を有する。
【００９４】その他の構成として、集中業務処理装置１０は、ＯＳ等の基本ソフト５２および運用基本ソフト５４をもつ。また、作業者が操作するクライアント端末のための構成として、アプリケーションクライアント５６、クライアント基盤５８およびＯＳ等の基本ソフト６０が用意されている。図１には示されないが、多数の作業者、すなわち多数のクライアント端末により業務作業が行なわれる。
【００９５】次に、本実施の形態に特徴的な、複合処理案件および同時処理案件を処理する機能について説明する。
【００９６】一の顧客から複数の請求書類が受けつけられることがあり、そうした複数案件の中には、複合処理案件および同時処理案件が含まれる。複合処理案件とは、互いに依存関係があって決められた順序に従って処理されるべき複数案件であり、すなわち、一の請求案件の後に別の請求案件を処理すべき複数案件である。また同時処理案件は、依存関係のない複数案件であって、業務効率の観点からも同時に併行して処理されるべき複数案件である。本システムは、以下に説明するように、通常のワークフロー製品には実装されていない、こうした複合処理案件および同時処理案件を関連付けて実行、管理する機能を備える。
【００９７】図６は、複合処理案件および同時処理案件を自動的に判別するための複合同時判定プロセスを示す。この複合同時判定プロセスは、上述した業務プロセス群と同様の形態を有し、業務フローシステム２０に備えられている。
【００９８】ディスパッチャ２２は、一の顧客に関して一の請求案件が取得されたときには（単独案件）、その請求案件に対応する業務プロセスを直接的に起動する。一方、ディスパッチャ２２は、一の顧客に関して複数の請求案件が取得されたときには、図６の複合同時判定プロセスを起動する。
【００９９】なお、複数の請求案件には、同じ契約に関する複数案件と、別契約に関する複数案件が含まれる。後者は、例えば、顧客本人の契約変更手続と、その家族の契約の変更手続である。
【０１００】図６の複合同時判定プロセスでは、一顧客の複数請求は、まず機械判定ノードに進められ、機械判定ノードのワークリスト送受信箱に入れられる。アプリケーションサーバ２８から提供される機械判定アクティビティは、複合同時判定テーブルを用いて、複数請求案件が(i)複合処理案件、(ii)同時処理案件および(iii)その他の例外案件のいずれに属するかを判定する。判定処理では、証券番号、処理コードなどの請求案件を特定する情報が用いて判定テーブルが参照される。
【０１０１】機械判定アクティビテイは、判定結果を業務支援データベース２４に記録する。業務支援データベース２４には管理フォルダが設けられる。この管理フォルダを用いて、互いに複合関係および同時関係にある案件が紐付け管理される。管理フォルダには、案件管理番号、証券番号、業務コード、複合同時区分、同時状況区分、複合状況区分、複合順序、フォルダ番号などのデータを書き込むことができる。
【０１０２】図７〜図９は、複合同時判定テーブルの例を示している。図７は、複合処理案件に分類されるべき請求案件の組合せを示し、図８は、同時処理案件に分類されるべき請求案件の組合せを示し、図９は、例外案件に分類されるべき請求案件の組合せを示している。例外には、特殊な案件（組合せ）が含まれ、同じ請求書類の二重投入のような入力ミスも含まれる。
【０１０３】図７〜図９のそれぞれにおいて、「同一契約」と「別契約」の２つのテーブルが示されている。「同一契約」とは、同じ契約に対する複数の請求案件であり、「別契約」とは、それぞれ別の契約に対する複数の請求案件であり、例えば顧客本人の契約と家族の契約についての請求案件である。
【０１０４】また、図７〜図９では、２つの案件の組合せについての判定テーブルが示されている。これに対し、３つ以上の案件の組合せについても判定可能なようにテーブルを構成してもよい。また、３つ以上の案件の組合せに関する判断は、後述する人判定に委ねられてもよい。
【０１０５】また実際のシステムでは、複合同時判定テーブルは、図７〜図９のうちの２種類のテーブルで構成することも好適である。好ましくは、複合同時判定テーブルが、図７の複合判定テーブルと図９の例外判定テーブルにより構成される。これらテーブルに入らない案件の組合せは同時処理案件と判断される。
【０１０６】さらに、上記の２種類のテーブルは、３つ以上の案件組合せの判定に際しては以下のように用いられてよい。３以上の案件から任意の２案件のペアをつくる。すべてのペアが図７および図９に該当しないとき、全案件を同時処理対象とする。そうでない場合は、人判定等を適用に用いて、複合または例外処理とする。
【０１０７】図６に戻り、機械判定アクティビティの処理が終了すると、業務フローシステム２０は、請求案件（請求案件のセット）の案件特定情報をワークフロー起動ノードへと進め、ワークフロー機能ノードのワークリスト送受信箱へと請求案件を入れる。また、一部の特定の請求案件は、機械判定ノードから人判定ノードへと進められる。
【０１０８】人判定ノードに進む請求案件は、複合または同時と判定された請求案件であって、名義変更等の特定の人判定処理を含む案件である。人判定に進むべき請求案件も予め定められている。
【０１０９】人判定ノードでは、作業者により複合・同時判定が行われる。ここでは、人判定アクティビティにより、作業者に対して、請求案件がどのように処理されるべきか（複合・同時）が問い合わされる。作業者が端末を使って判定を入力する。入力された判定に従って案件管理フォルダが作成される。機械判定ノードで複合または同時と判定された案件であっても、例外案件にまわされることもある。
【０１１０】また、３つ以上の請求案件が取得されたときには、同一契約の案件と別契約の案件とが混在する場合がある。例えば、顧客本人の一契約に対する２つの請求案件および顧客の家族の契約に対する１つの請求案件といった組合せが考えられる。このような混在型の請求案件も人判定ノードに送られる。人判定ノードでは、作業者により複数の請求案件が適当に分割され、分割後に複合、同時等の判定が加えられる。
【０１１１】上記の人判定ノードの処理が終了した請求案件は、業務フローシステム２０によりワークフロー起動ノードへと進められる。請求案件がワークフロー起動ノードに進んでワークリスト送受信箱に入ると、ワークフロー起動アクティビティにより、ディスッチャ２２に対して、請求案件に対応する業務プロセスの起動が指示される。
【０１１２】ディスパッチャ２２は、起動指示を受けて、請求案件の組合せに対応する複数の業務プロセスを起動する。起動の際、ワークフロー起動アクティビテイにより業務支援データベース２４の案件管理フォルダに格納された複合、同時判定結果が参照される。
【０１１３】請求案件の組合せが複合処理案件に該当する場合、予め定められた適正順序に従って処理が行われるように、すなわち一の業務プロセスの終了後に次の業務プロセスが行なわれるように、ディスパッチャ２２は、各業務フロー内のワークフロー起動アクティビティの指示に基づく、複数の業務プロセスを順次起動する。また請求案件の組合せが同時処理案件に該当する場合、ディスパッチャ２２は、それら請求案件に対応する複数の業務プロセスを一斉に起動する。
【０１１４】また、請求案件の組合せが例外案件に該当する場合は、汎用例外プロセスが起動される。そして、請求案件の書類が、印刷サーバによって、本社担当課のプリンタに印刷される。本社担当課では手作業で請求書類を処理のうえ、該当プロセス（汎用例外）の完了入力を行う（一度案件をワークフローの外に出し、処理済後差し戻す）。
【０１１５】図１０は、複合処理の流れを示している。まず、ディスパッチャ２２により、複合順序の一つ目の業務プロセスが起動され、業務フローシステム２０により業務プロセスが進行される。業務プロセスの最後の部分には、次案件起動ノードが設けられている。この起動ノードは、請求案件が複合処理案件に該当するときに機能する。次案件起動ノードでは、業務支援データベース２４が参照され、処理中の請求案件と関連づけられた別の案件が求められる。これにより、複合順序上で次に処理されるべき案件が求められる。そしてディスパッチャ２２により次の案件に対応する業務プロセスが起動される。
【０１１６】複合処理されるべき最後の案件の処理が進み、その案件の処理が次案件起動ノードに達したとする。このとき、業務支援データベース２４の案件管理フォルダが参照され、すべての複合処理が終了したことが判定される。これにより複合処理案件の処理が終了する。
【０１１７】なお、本実施の形態では、基本的にすべての業務プロセスの終わりに次案件起動ノードが設定されている。また、各業務プロセスは、単独案件の処理と、複合処理案件の処理と、後述する同時処理案件の処理とで共用される。しかし、次案件起動ノードは、請求案件が複合処理対象のときのみ機能する。すなわち、業務プロセスが他の業務プロセスと直列連結されるときのみ機能する。そこで、複合処理以外の説明および図面では、次案件起動ノードは省略されている。
【０１１８】図１１は、同時処理の流れを示している。同時処理では、ディスパッチャ２２は、複数の業務プロセスを一斉に起動させる。業務フローシステム２０は、それら業務プロセスを併行して進行させる。
【０１１９】業務プロセス上には同期処理ノードが定められている。同期処理ノードは、請求案件が同時処理案件に該当するときに機能する。同期処理ノードは、例えば、電話確認ノード、ホスト処理ノード、不備通知ノード、顧客宛結果発送ノードなどである。
【０１２０】同期処理ノードに到達する前は、複数の業務プロセスはばらばらに進行しており、それらは互いにずれていてよい。同期処理ノードでは、併行処理されている複数の請求案件の待ち合わせにより、複数の業務プロセスにおける同期処理ノードの処理タイミングが同期する。例えば、顧客に対する電話確認が、複数の請求案件に関してまとめて行われる。待合せは、後述するように、同期処理ノードの前に設けられた待合せノードを用いて実現される。
【０１２１】同期処理ノードを過ぎると、また、複数の処理が併行して行われる。業務プロセスには複数の同期処理ノードが設定されていてもよい。この場合、次の同期処理ノードで、再び待ち合わせ、同期処理が行われる。
【０１２２】次に、図１２は、同時処理の流れをより具体的に示している。図１２を用いて複数プロセスの待合せについて説明する。また、同期処理案件の数が３以上である場合において、一部の案件のみが、同じ同期処理ノードをもつ場合がある。この場合の処理も図１２に示されている。
【０１２３】図１２では、同時処理される３本の業務プロセスが示されている。上側の２本の業務プロセスには電話確認ノードが設定され、電話確認ノードの前段に電話確認待合せノードが設定されている。一方、一番下の業務プロセスには電話確認ノードは設定されていない。また、３本のプロセス全部に、ホスト処理ノードが設定され、かつ、ホスト処理ノードの前段に同期待合せノードが設定されている。上記の電話確認ノードおよびホスト処理ノードは、同期処理ノードの一形態である。
【０１２４】図１２の処理では、一つの請求案件が電話確認待合せノードに到達すると、業務支援データベース２４の案件管理フォルダを参照して、同時処理される請求案件の本数Ｎ（＝３）が参照される。電話確認待合せノードおよび同期待合せノードに達した案件数の合計が、同時処理本数Ｎに達したとき、同期完了と判定される。上側の２本の業務プロセスにおいて、請求案件が電話確認ノードへと進められる。これにより２つの案件の電話確認が同時に行われる。
【０１２５】電話確認が終わると、請求案件は同時待合せノードへと進む。これにより、３本の業務プロセスの請求案件が同期待合せノードへ到達する。待合せが完了したので、３つの請求案件はホスト処理ノードへと進む。これにより、ホスト処理が、３つのプロセスで同期したタイミングで行われる。
【０１２６】このように、本実施の形態では、業務プロセスに待合せノードを設けるという比較的簡単な構成により、併行処理される複数のプロセスの一部タイミングを確実に同期させることができる。そして、一部のプロセスが該当する同期処理（図１２では電話確認ノード）をもたない場合でも、別の待合せノードを利用して、同期処理を適切に行える。
【０１２７】なお、本実施の形態では、各業務プロセスは、単独案件の処理と、複合処理案件の処理と、同時処理案件の処理に共用される。しかし、待合せノード（同時待合せノードおよび電話確認待合せノード）は、請求案件が同時処理対象のときのみ機能する。そこで、同時処理以外の説明および図面では、待合せノードは省略されている。
【０１２８】次に、複合処理における同時電話確認について説明する。複合処理案件については、前述したように、複数の業務プロセスが順次実行される。複数の業務プロセスが電話確認ノードをもつ場合、それら電話確認ノードのそれぞれで電話確認が行われ、その結果、顧客に対して複数回の電話確認が行われる。しかし、電話確認はまとめて行う方が、顧客の手間を削減するうえで望ましい。そこで、本実施の形態では、以下のようにして、複合処理においても同時電話確認を実現している。
【０１２９】図１３は、複合処理における同時電話確認を示している。図１３には、現処理中の案件の業務プロセスが示されている。現処理中の案件は、複合処理対象として関連づけられた複数案件のうちの一番目の案件である。
【０１３０】請求案件が電話確認ノードに到達すると、前述したように案件特定情報がワークリスト送受信箱に入れられる。アプリケーションサーバ２８の電話確認アクティビティにより、請求案件が取り出され、処理される。クライアント端末に電話確認用の画面が表示され、担当者に電話確認が促される。
【０１３１】ここで、電話確認アクティビティは、業務支援データベース２４を参照して、現処理中の案件と関連付けられた案件、すなわち、現処理中の案件の後段で処理される案件を確認する。３つ以上の案件が関連づけられている場合、すべての後続案件が確認される。そして、電話確認アクティビティは、後段の各案件の内容が電話確認を必要とするか否かを判定する。後続案件の電話確認が必要な場合、電話確認用の端末画面には、現処理中の案件に加えて、後続案件が示される。画面上には、電話確認内容が表示される。また必要に応じて、例えば担当者の指示により、後続案件の情報が画面表示される。
【０１３２】担当者は、複数案件が表示された画面をみて、それら案件の電話確認をまとめて行う。担当者が電話確認結果を入力すると、確認結果は業務支援データベース２４に記録される。もちろん、現処理中の案件情報と、後続案件情報の両方について、確認結果が記録される。また、電話確認の履歴が、案件管理データ記録データベース２６に記録される。
【０１３３】電話確認が終了すると、業務フローシステム２０は請求案件を次ノードへ進める。請求案件が次案件起動ノードへ達すると、ディスパッチャ２２に起動が指示される。ディスパッチャ２２は、次の請求案件に対応する業務プロセスを起動する。
【０１３４】後段の業務プロセスでは、電話確認はすでに終了していることを業務支援データベースを利用して引き継ぐ。そこで、電話確認ノードをパスして、業務フローシステム２０は請求案件を次ノードへ進める。これにより、電話確認が省略される。
【０１３５】以上のように、本実施の形態では、複合処理においても同時処理を実現できる。顧客にとってみれば、１回の請求に対する電話確認をまとめて受けられるので、電話応対の手間が減る。したがって顧客に対するサービス性の向上が図れる。また業務処理側の手間の削減も図れる。
【０１３６】図１４〜図１６は、複合、同時処理案件の処理の際に作業者端末に表示される画面の例を示している。図１４は、ある請求案件の点検画面である。表示された請求案件が別の案件と紐付けられている（複合または同時処理案件である）ときは、図１４の画面右上に示されるように、「同時」または「複合」ボタンが表示される。図１４の例では「同時」ボタンが表示される。
【０１３７】作業者が「同時ボタン」をクリックすると、図１５に示すように、同時処理されている別の案件を示すボタンが表示される（画面右上、矢印マーク）。図１５には一つのボタンが示されているが、同時処理件数が３以上の場合には、その件数に応じた数のボタンが表示される。
【０１３８】作業者が、同時案件のボタンをクリックすると、図１６に示すように、クリックされた案件の請求書イメージが表示される。複合、同時案件では、書類（印鑑証明など）を共有することがあるので、別案件の書類イメージを参照できることは、業務作業にとって有用である。
【０１３９】図１７は、同時処理において表示される同期電話確認用の画面の例を示している。図示のように、同時に電話確認を行うべき案件のリストが表示される。
【０１４０】図１８は、複合、同時案件のデータを印刷したときのヘッダ用紙の例を示している。図示のように、複合、同時として紐付けられた関連案件の情報がまとめてヘッダ用紙に印刷される。
【０１４１】本システムでは、上述の他、複合同時の関連案件については、管理情報、案件内容、付属書類、進捗状況を参照できるように構成する。
【０１４２】次に、業務プロセスにおける電話確認処理、特にそのリコール機能についてさらに説明する。本集中業務処理装置は、顧客本人宛の電話連絡の確実な遂行を支援する。
【０１４３】図１９は、電話確認処理の一例である。ここでは単独案件が処理される。点検ノードでの点検処理が終了した請求案件は、単独電話確認ノードへと進められる。ただし、電話確認が不要な案件は、直接ホスト処理ノードへと進められる。
【０１４４】単独電話確認ノードでは、作業担当者が、端末画面の表示を見て、顧客に対して電話確認を行う。例えば支払関連の保全手続では、本人の意志が電話で確認される。電話確認が終了した案件は、認証ノードを経て、ホスト処理ノードへと進められる。
【０１４５】顧客が不在であった場合などには、請求案件は電話確認待機ノードへ進められる。電話確認待機ノードでは、リコール（再電話）予定時刻が設定される。予定時刻の代わりに、リコールまでの期間が設定されてもよい。リコール時刻が到来すると、請求案件は再び単独電話確認ノードへ進められる。これにより、電話連絡指示が担当者の端末画面に表示される。担当者は、画面の指示に従って電話確認を行う。
【０１４６】このように、本実施の形態では、リコール予定をシステム側で一元管理することにより、電話漏れ等を確実に防止でき、確実な電話確認が可能となる。
【０１４７】また、電話確認待機ノードへ移行するときは、電話確認の応対データが業務支援データベース２４に保存される。例えば、顧客が不在である場合に、顧客の家族との対話内容が記録される。再確認の電話連絡指示を表示するときは、応対データも表示される。これにより、担当者不在等の理由で他の担当者が再確認を行う場合でも、応対経緯に基づいた適切な電話確認が可能となる。
【０１４８】図２０は、電話確認において端末に表示される画面の例である。図示のように、電話確認未完了の場合には、リコール時刻が設定され、さらに応対履歴が記録される。
【０１４９】図２１は、電話確認処理のもう一つの例であり、ここでは同時処理案件が処理される。同時処理対象の複数の案件のうちで、電話確認が不要な案件は、点検ノードから直接同期待合せノードへと送られる。一方、電話確認が必要な案件は、電話確認待合せノードへと送られる。
【０１５０】電話確認待合せノードでは、同期電話確認のための待合せが行われる。このとき、電話確認が不要な案件が同時処理対象に混じっている可能性を考慮して、以下の処理が行われる。まず同時処理対象の案件数Ｎが取得される。そして、電話確認待合せードと同時待合せノードに位置する案件数の合計が、上記処理対象案件数Ｎに達したとき、同期完了と判定される。要するに、同期処理対象の全案件が電話確認待合せノードか同時待合せノードに達したときに、同期完了と判断される。
【０１５１】同期が完了すると、請求案件が電話確認待合せノードから同期電話確認ノードへと移される。担当者の端末画面に電話連絡指示が表示される。この指示には、同時処理される複数案件が示される。この指示に従って担当者により、複数の案件の電話確認がまとめて行われる。このとき、関連案件の詳細情報、付属情報も担当者の指示に従って画面で参照される。
【０１５２】電話確認が完了すると、請求案件は認証ノードを経て同時待合せノードへと移される。同時待合せノードにて、同時処理対象の全案件がそろうと、それら案件はホスト処理ノードまたは不備通知ノードへと移される。そしてここでも待合せノードによる待合せの結果として同期処理が行われる。
【０１５３】一方、同時電話確認が未完了の場合（顧客不在など）、確認対象の案件が電話確認待機ノードへと移される。待機ノードの処理は基本的に単独案件の場合と同様である。すなわち、リコール予定時刻が設定され、かつ、応対経緯が記録される。そしてリコール予定時刻が到来すると、請求案件は電話確認待合せノードへと移され、これにより再び同期電話確認が行われる。上述より明らかなように、このループでは複数の案件が一緒に移動される。
【０１５４】このように、本実施の形態では、同時処理案件について、複数の電話確認をまとめて行うことができる。一部の案件の電話確認が不要な場合でも、同時待合せノードを設けた簡素な構成により、同期確認を確実に行える。
【０１５５】次に、複合処理におけるリコール機能について説明する。複合処理においても、図１９に示したリコール処理が行われる。すなわち、電話確認ノードでの電話確認が未完了の場合、請求案件は電話確認待機ノードへ進められる。電話確認待機ノードでは、リコール（再電話）予定時刻が設定される。リコール時刻が到来すると、請求案件は再び単独電話確認ノードへ進められ、電話確認が再び行われる。
【０１５６】ここで、本実施の形態では前述したように複合処理において、一番目の請求案件のプロセス上で、一番目の案件および後続案件の電話確認がまとめて行われる。この同時確認は、リコールの際にも行われる。すなわち、待機ノードの後の電話確認ノードでも、現処理中の案件と後続案件の情報が、電話確認用の端末画面に表示される。それら案件の電話確認が担当者により行われる。
【０１５７】以上、本発明の好適な実施の形態を説明した。
【０１５８】本実施の形態によれば、その基本的な利点として、請求案件の書類がデータ（電子データ等）のかたちで集中業務処理装置へと送られるので、書類の物流に伴う制約から解放される。これにより、手続を迅速化でき、書類の受渡しに伴うハンドリング業務も削減できる。また書類の不備を早期に発見でき、不備への対応も早められる。
【０１５９】また本実施の形態によれば、各種の請求案件にそれぞれ対応する業務プロセス機能をもった業務フローシステムが設けられる。手続の新設、追加、変更などに対しては、業務プロセス機能の新設、追加、変更などにより対処できる。したがって、業務処理の変化に柔軟に対応することができる。
【０１６０】また本実施の形態によれば、上述の物流の削減と、それに関連する業務の削減、さらには、予め用意した複数の業務プロセス機能を選択的に用いる効率的な業務処理により、業務コストを削減できる。
【０１６１】さらに本実施の形態によれば、集中事務側という局所化した環境で業務作業人員による作業が行われ、それら人員の教育も行われるようなシステムを構成可能である。高度な教育、作業を簡素化、標準化されたかたちで実現するように図れる。
【０１６２】また本実施の形態によれば、複合処理案件および同時処理案件を自動的に判定でき、それら案件を関連付けて適切に処理および管理できる（ただし、複合処理案件および同時処理案件の一方を自動判定して、上述の実施形態に示されるように処理する構成も、本発明の範囲に含まれてよい）。
【０１６３】本実施の形態では、複合処理案件および同時処理案件のために専用の業務プロセスを用意していない。代わりに、複数の業務プロセスを直列および並列に連結することにより、複合、同時処理案件のための業務プロセスが実現される。ある請求案件の業務処理を変更するときは、対応する業務プロセスを変更してやればよい。複合処理や同時処理のための専用プロセスの変更といった作業は不要である。したがって、業務処理の変更に柔軟に対応でき、システムの保守性がよい、という利点が得られる。
【０１６４】また、本実施の形態では、複合処理案件および同時処理案件を判定する手段を、業務プロセスと同様の形態で構成し、ワークフローシステムの応用である業務フローシステムの一部としている。そして、取得された請求案件の数に応じて、業務プロセスを起動したり、判定プロセスを起動したりと、業務フローシステムのプロセス起動を切りかえる。したがって、業務フローシステムの高い柔軟性を利用して複合処理案件および同時処理案件に適切に対処できる。
【０１６５】また本実施の形態では、複合同時判定テーブルを用いて、複合処理案件、同時処理案件およびその他の案件を判別する。新種の保全手続が設定されたような場合でも、そうした新種の手続に対して、テーブルの変更によって柔軟に対応できる。
【０１６６】ここで、実際の請求案件件数を分析した結果を参照すると、全件数の５／６程度は、単独案件である。残りの約１／６の請求案件は、他の案件と一緒に一の顧客から受け付けられる。こうした複数案件の組合せの殆どが、複合同時判定テーブルを用いて、複合処理案件か同時処理案件へと自動的に振り分けられる。人判定に回される案件は少数である。例外に分類されてハンドリング処理される案件も少数である。本実施の形態によれば、業務フローシステムを利用して大部分の案件を処理することができ、業務処理効率を向上できる。
【０１６７】また本実施の形態によれば、業務プロセスの終わりに設置された次案件起動ノードが利用される。ワークフローシステムの技術を基礎として、そのプロセスに次案件機能ノードを設けるという簡素な構成により、複数プロセスを連結して、複合処理案件の適正順序処理を実現できる。
【０１６８】また実施の形態によれば、同時処理案件のための複数の業務プロセスを併行して進行するとき、それら業務プロセスに同期処理ノードが利用される。同期処理ノードは、例えば電話確認ノードである。同期処理ノードを利用して、同期処理を確実に管理して実現でき、これにより、顧客の手間を減らして顧客サービスの向上を図り、また業務作業側の手間の削減も図れる。
【０１６９】また本実施の形態によれば、電話確認ノードでの電話確認が不成功のとき、リコール時刻を設定し、電話確認ノードの処理を再び同時に実行させる。したがって同期処理の利点を確実に生かせる。
【０１７０】また本実施の形態によれば、複合処理において、後続案件の確認処理を導入したことにより、複数の案件の電話確認をまとめて行える。顧客の手間が省けるのでサービス性の向上が図れる。また業務処理側の手間の削減も図れる。特に、前側の案件で後続案件を確認しているので、同時電話確認を早い段階で行えるので、この点でもサービス性を向上できる。
【０１７１】さらに本実施の形態によれば、複合処理においても、電話確認が不成功のときに、同時電話確認を再度行うことができる。これにより、複合処理案件における同時電話確認の利点を確実に生かせる。
【０１７２】以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更又は改良を加えることができる。その様な変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【０１７３】
【発明の効果】上記説明から明らかなように、本発明によれば、業務手続を迅速化し、業務処理コストを削減できる。また、業務処理の変更に対して柔軟に対応できるシステムを提供できる。また、複合処理案件や同時処理案件を適切に処理できるシステムを提供できる。
【図面の簡単な説明】
【図１】本発明の実施の形態における集中業務処理システムを示す図である。
【図２】図１の集中業務処理装置の構成を示す図である。
【図３】業務フローシステムおよび関連構成の機能を示す図である。
【図４】業務フローシステムに定義された業務プロセスを示す図である。
【図５】図２の集中業務処理装置で作業者端末に表示される画面の例である。
【図６】複合同時判定プロセスを示す図である。
【図７】複合同時判定プロセスで用いられる複合同時判定テーブル、特に複合判定テーブルを示す図である。
【図８】複合同時判定プロセスで用いられる複合同時判定テーブル、特に同時判定テーブルを示す図である。
【図９】複合同時判定プロセスで用いられる複合同時判定テーブル、特に例外判定テーブルを示す図である。
【図１０】複合処理の流れの例を示す図である。
【図１１】同時処理の流れの例を示す図である。
【図１２】同時処理の流れの例を示す図である。
【図１３】複合処理における同時電話確認機能を示す図である。
【図１４】同時処理において作業者端末に表示される画面の例を示す図である。
【図１５】同時処理において作業者端末に表示される画面の例を示す図である。
【図１６】同時処理において作業者端末に表示される画面の例を示す図である。
【図１７】同時処理において作業者端末に表示される画面の例を示す図である。
【図１８】同時処理案件をプリンタから出力したときのヘッダ用紙を示す図である。
【図１９】単独案件の電話確認処理を示す図である。
【図２０】電話確認処理で作業者端末に表示される画面の例を示す図である。
【図２１】同時処理案件の電話確認処理を示す図である。
【符号の説明】
１０ 集中業務処理装置
１４ 顧客端末装置
１８ ホストシステム
２０ 業務フローシステム
２２ ディスパッチャ
２４ 業務支援データベース
２６ 案件管理データ記録データベース
２８ アプリケーションサーバ
３０ ワークリストサーバ
【０００１】
【発明の属する技術分野】本発明は、多数の顧客と契約関係をもつ企業等に用いられ、契約変更等の業務手続を処理する集中業務処理システムに関する。本発明は典型的には生命保険の業務処理に利用される。
【０００２】
【従来の技術】生命保険契約には、顧客のライフサイクルに対応した長い期間にわたって継続するという特色がある。この長期間の契約の間には、支払や契約変更などに関する各種の多様な手続が発生する。こうした契約中の手続を保全手続という。
【０００３】生命保険会社は多数の顧客を有しており、大きな生命保険会社の場合、数百万から一千万といった数の契約をもっている。それら多数の契約で生じる多様な保全手続の請求案件を確実かつ効率よく処理することが求められる。
【０００４】従来の保全手続業務システムの一例では、業務処理拠点としての支部が全国に分散配置される。各地域の支部の上に支社が配置され、そして全国の支社が本社に統括される。これら支部、支社および本社は、分散系クライアントサーバ型オンラインシステムを利用して情報を共有するものの、手続請求案件の書類は物流ベースで回送、処理されている。
【０００５】具体的には、顧客の請求書類は支部で受けつけられる。支部は、一部の保全手続を処理する権限をもつ。残りの保全手続の請求書類は、支部から支社へと物流により回送される。支社は、支部より広範囲の権限をもつものの、すべての書類の処理はできない。そこで、支社でも一部の書類が処理され、残りの書類は本社に回送される。また、特殊な案件や複雑な案件は、支部および支社で確実な処理方法を判断できないので、やはり本社に回送される。
【０００６】本社では、基本的にすべての案件の処理が可能である。しかし物流で送られてきた書類の中には、不備のある書類もある。その場合、請求書類は本社から支社を経て支部へと回送される。そして支部は、顧客との応対により書類の不備を解消し、書類を再度本社へ回送する。
【０００７】
【発明が解決しようとする課題】上記従来のシステムでは、書類の物流を前提としつつ、処理能力を部分的に支部および支社に与える分散型システムを採用している。この分散型システムにより、一部の手続についてのリードタイム短縮が図られている。しかしながら、本社で処理される請求書類については、請求書類を物流で輸送しているために、処理に時間がかかってしまう。そして書類の不備が本社で発見された場合には、さらに、本社−支部間の書類往復時間が必要となる。これらの処理時間は極力短縮することが望まれる。
【０００８】また、請求書類の物流を前提とするシステムでは、書類が回送されるたびに、授受確認および担当者への仕分けが必要であり、これらハンドリング作業を極力減らすことが望まれる。
【０００９】さらに、書類物流によるタイムラグの間に、オンライン情報システム側で、契約のマスターファイルが更新される可能性がある。そのため、書類受付の都度、契約内容を照会するためにオンラインシステムへのパンチ入力が必要である。こうした作業負担も軽減することが望ましい。
【００１０】また、書類物流の不利の解消に加えて、業務処理システムには環境変化に対応する能力が高いことが求められる。募集チャネルの拡大、新しい金融商品等の将来の対応を考慮すると、現行業務のみならず、業務処理の追加や変更などにも柔軟に対応できるシステムの提供が望まれる。
【００１１】また、上述したように、保険会社は多数の保有契約に関して多様な保全手続を行なう。そのため、書類物流による不利の解消も含めて、１件あたりの業務・維持コストを削減することが強く望まれる。この点は、新商品の低ローディング化という流れのうえでも望まれる。
【００１２】さらに、業務を支部および支社に分散する形態では、全国に配置される業務職員に対する教育の負担が大きく、教育コストも大きいという不利がある。
【００１３】本発明の更なる課題として、以下に説明するように、一の顧客から一度に複数の請求書類を受けつけたときの業務処理の改善が求められる。
【００１４】生命保険などでは、長期間の契約を通じて多様な保全手続が行なわれるので、一の顧客から複数の請求書類を受け付けることもある。これには、一つの契約に対して複数の請求書類が受け付けられる場合はもちろんのこと、複数の契約に対して複数の請求書類が受けつけられることもある。後者は、例えば家族を構成する複数人の契約についての請求書類を受けつける場合である。複数の請求書類の同時受付頻度は、約２０％に達すると考えられる。
【００１５】このような手続は、顧客にとって見れば、生命保険会社との間の単一の手続に見える。しかし実際には、複数の請求にそれぞれ対応する複数の保全手続が行なわれる。複数の保全手続の中には、業務処理上の順序性が要求されるものもある。すなわち、一の手続を行なってから出ないと、次の手続を行なうべきでないことがある。こうした必要順序に従った手続の確実性を向上することが望まれる。
【００１６】また保全手続においては、顧客に対する電話確認が行なわれ、また保全手続の処理結果が通知される。複数の保全手続がばらばらに処理されると、上記の確認および通知もばらばらに行なわれる。顧客は、一回の請求に関連して、何度も電話確認に対応したり、何度も通知を受けとることになる。確認や通知をまとめて行なうことができれば、顧客の手間を減らして顧客サービスを向上することができ、業務処理側の手間も減らせると考えられる。このような機能を、多数の契約と多様な保全業務を管理する条件下で実現することが望まれる。
【００１７】本発明は上記課題に鑑みてなされたものであり、その目的は、従来の書類物流の不利を解消し、柔軟性が高く、業務処理コストも低減できる技術を提供することにある。
【００１８】また本発明の別の目的は、一の顧客からの複数の請求書類に対する業務処理を改善できる技術を提供することにある。
【００１９】本発明の目的は特許請求の範囲における独立項に記載の特徴の組み合わせにより達成される。また従属項は本発明の更なる有利な具体例を規定する。
【００２０】
【課題を解決するための手段】（１）本発明のある態様は、多数の顧客と契約関係をもつ企業等に用いられ、契約変更等の業務手続を処理する集中業務処理システムに関する。集中業務処理システムは、顧客から業務手続の請求案件を受け付ける複数の拠点に配備され、請求案件のデータを送信する端末装置と、前記複数の拠点から請求案件を受け取って集中的に処理する集中業務処理装置と、を含む。前記集中業務処理装置は、各種の請求案件にそれぞれ対応する複数の業務プロセス機能を備え、顧客からの業務手続の請求案件に対応する業務プロセスに沿って請求案件の処理を進行させる業務フローシステムと、前記業務フローシステムとのインターフェース機能をもち、前記請求案件に対応する業務プロセス機能を前記業務フローシステムに起動させるプロセス起動手段と、を含む。
【００２１】本発明によれば、請求案件の書類はデータのかたちで集中業務処理装置へと送られる。したがって書類の物流に伴う制約から解放され、手続を迅速化でき、書類の受渡しに伴うハンドリング業務も削減できる。また書類の不備を早期に発見でき、不備への対応も早められる。
【００２２】また本発明によれば、集中業務処理システムには、各種の請求案件にそれぞれ対応する業務プロセス機能をもった業務フローシステムが設けられる。手続の新設、追加、変更などに対しては、業務プロセス機能の新設、追加、変更などにより対処できる。したがって、業務処理の変化に柔軟に対応することができる。
【００２３】また本発明によれば、上述の物流の削減と、それに関連する業務の削減、さらには、予め用意した複数の業務プロセス機能を選択的に用いる効率的な業務処理により、業務コストを削減できる。
【００２４】さらに本発明によれば、集中事務側という局所化した環境で業務作業人員による作業が行われ、それら人員の教育も行われるようなシステムを構成可能である。高度な教育、作業を簡素化、標準化されたかたちで実現するように図れる。
【００２５】なお、好ましくは、拠点の端末装置は、顧客から受け付けた請求書類を、スキャナー等の読み取り装置を用いて電子化する。請求書類のイメージデータを集中業務処理装置に送ることにより、書類の原形を用いた各種の処理を集中業務処理装置で実行できる。特に、生命保険等の請求書類には、印鑑の押印と自筆の署名が求められる。イメージデータを用いることにより、これらの原形が必要な構成部分に対して、集中業務処理装置で照合等の適切な処理ができる。
【００２６】また、拠点の端末装置は、例えば会社の支部等に固定的に配置されるコンピュータ装置であるが、これに限定はされない。端末装置は、例えば携帯端末でもよく、携帯端末は、支部等を介して、あるいは集中業務処理装置と直接的に通信する。また拠点と集中業務処理装置の通信には、専用オンラインシステムが用いられてもよく、またインターネットなどが用いられてもよい。
【００２７】また、本発明において、処理対象の業務は、例えば生命保険会社の保全手続に関する業務である。また処理対象の業務は、新規契約募集（募集訪問を含む）および承諾プロセスなどでもよい。処理対象の業務はこれらに限定されない。
【００２８】（２）本発明の一態様の集中業務処理システムは複合処理判定手段を含む。複合処理判定手段は、一の顧客に関して複数の請求案件が取得されたときに、それら複数の請求案件が、一の請求案件の終了後に別の請求案件を処理すべき複合処理案件に該当するか否かを判定する。
【００２９】好ましくは、前記複合処理判定手段は、前記業務プロセスと同様の形態の複合判定プロセスとして用意されている。前記プロセス起動手段は、一の顧客に関して複数の請求案件が取得されたときに前記複合判定プロセスを起動し、さらに前記複合判定プロセスの判定結果に従い、複合処理案件に対応する複数の業務プロセスを、一の業務プロセスの終了後に次の業務プロセスが行なわれるように順次起動することにより、複合処理案件の適正順序処理を実現する。
【００３０】好ましくは、前記プロセス起動手段は、一の顧客に関して一の請求案件が取得されたときにはその請求案件に対応する業務プロセスを直接的に起動し、一の顧客に関して複数の請求案件が取得されたときには前記複合判定プロセスを起動する。
【００３１】本発明によれば、複合処理案件、すなわち、決まった順番で処理されるべき複数の請求案件が受けつけられたことを自動的に判定できる。そして、複合処理案件は関連づけられて実行、管理される。これにより、複合処理案件を必要な順番に従って確実に処理できる。
【００３２】また本発明では、複数の請求案件に対応する複数の業務プロセスを順番に起動し、それらを直列に連結することにより、複合処理案件を処理する。こうした構成とは対照的に、複合処理案件に対応する専用の長いプロセスを用意する構成も考えられる。しかし、請求案件の処理に変更が生じた場合、単独案件用の業務プロセスに加えて、複合処理案件のプロセスもすべて変更しなければならない。本発明の場合は、連結方式を採用しているので、一つの案件に関して処理の変更が生じた場合、対応する業務プロセスのみを変更すればよい。したがってシステムの保守性がよい、という利点が得られる。
【００３３】また、本発明では、複合処理案件を判定する手段を、業務プロセスと同様の形態で構成し、ワークフローシステムの応用である業務フローシステムの一部としている。そして、取得された請求案件の数に応じて、業務プロセスを起動したり、判定プロセスを起動したりと、業務フローシステムのプロセス起動を切りかえる。したがって、業務フローシステムの高い柔軟性を利用して複合処理案件に適切に対処できる。
【００３４】（３）本発明の好ましい一態様では、前記複数の業務プロセスの各々は、対応する請求案件の処理を達成するための複数の処理ノードで構成されている。前記複合処理案件に対応する業務プロセスは、前記複数の処理ノードの終わりに次案件起動ノードを有する。前記業務フローシステムは、複合処理案件に対応する一の業務プロセスが前記次案件起動ノードに到達すると、複合処理案件に対応する次の業務プロセスを起動する。
【００３５】前記複数の処理ノードは、顧客に対する電話確認ノードを含んでもよい。好ましくは、前記電話確認ノードでは、複合処理案件として現処理中の請求案件の後段で処理される請求案件の内容を確認でき、現処理中の請求案件と後段の請求案件の電話確認をまとめて行う。
【００３６】本発明によれば、業務プロセスの終わりに次案件起動ノードが設置されている。業務プロセスが次案件機能ノードに達すると、複合処理対象の次の案件が求められ、その案件のための業務プロセスが起動される。したがって、ワークフローシステムの技術を基礎として、そのプロセスに次案件機能ノードを設けるという簡素な構成により、複数プロセスを連結して、複合処理案件の適正順序処理を実現できる。
【００３７】また本発明によれば、業務プロセスの電話確認ノードにて、現処理中の電話確認とともに、後続処理される案件の電話確認も行うことができる。すなわち、順番に時期をずらして処理される複合処理案件において、電話確認については同時処理を実現できる。顧客にとってみれば、１回の請求に対する電話確認をまとめて受けられるので、電話応対の手間が減る。したがって顧客に対するサービス性の向上が図れる。また業務処理側の手間の削減も図れる。特に、本発明では、前側の案件で後続案件を確認しているので、同時電話確認を早い段階で行うことができ、この点でもサービス性を向上できる。
【００３８】また本発明のシステムは、好ましくは、前記電話確認ノードでの電話確認が不成功のとき、電話確認ノードの処理を待機後に再び実行させることにより、前記現処理中の請求案件と後段の請求案件の電話確認を再び同時に実行させる。これにより、複合処理案件における同時電話確認の利点を確実に生かせる。
【００３９】（４）本発明の一態様の集中業務処理システムは同時処理判定手段を含む。同時処理判定手段は、一の顧客に関して複数の請求案件が取得されたときに、それら複数の請求案件が、同時に併行して処理されるべき同時処理案件に該当するか否かを判定する。
【００４０】好ましくは、前記同時処理判定手段は、前記業務プロセスと同様の形態の同時判定プロセスとして用意されている。前記プロセス起動手段は、一の顧客に関して複数の請求案件が取得されたときに前記同時判定プロセスを起動し、さらに前記同時判定プロセスの判定結果に従い、同時処理案件に対応する複数の業務プロセスを起動する。前記業務フローシステムは、それら業務プロセスの少なくとも一部の処理タイミングを同期させる。
【００４１】好ましくは、前記プロセス起動手段は、一の顧客に関して一の請求案件が取得されたときにはその請求案件に対応する業務プロセスを直接的に起動し、一の顧客に関して複数の請求案件が取得されたときには前記同時判定プロセスを起動する。
【００４２】本発明によれば、同時処理案件、すなわち、同時に併行して処理されるべき複数の請求案件が受けつけられたことを自動的に判定できる。同時処理案件は関連づけられて実行、管理される。そして、業務フローシステムにより、それら業務プロセスの少なくとも一部の処理タイミングが同期するように、業務プロセスが進行される。処理タイミングの同期は、例えば電話確認および顧客への通知に関して行われる。このように、本発明によれば、同時処理案件を効率良く短期間で処理できる。処理タイミングの同期によって顧客の手間を削減してサービス性を向上し、業務処理側の手間の削減も図れる。
【００４３】また本発明では、複数の請求案件に対応する複数の業務プロセスを一斉に進行させることにより、同時処理案件を処理する。こうした構成とは対照的に、同時処理案件に対応する専用の併行処理プロセスを用意する構成も考えられる。しかし、請求案件の処理に変更が生じた場合、単独案件用の業務プロセスに加えて、同時処理案件のプロセスもすべて変更しなければならない。本発明の場合は、一つの業務プロセスを単独処理に用いたり、他のプロセスとの同時処理に用いており、つまり、業務プロセスの使い分けている。したがって、一つの案件に関して処理の変更が生じた場合、対応する業務プロセスのみを変更すればよく、システムの保守性がよい、という利点が得られる。
【００４４】また、本発明では、同時処理案件を判定する手段を、業務プロセスと同様の形態で構成し、ワークフローシステムの応用である業務フローシステムの一部としている。そして、取得された請求案件の数に応じて、業務プロセスを起動したり、判定プロセスを起動したりと、業務フローシステムのプロセス起動を切りかえる。したがって、業務フローシステムの高い柔軟性を利用して同時処理案件に適切に対処できる。
【００４５】（５）本発明の好ましい一態様では、前記複数の業務プロセスの各々は、対応する請求案件の処理を達成するための複数の処理ノードで構成されている。前記同時処理案件に対応する業務プロセスは、複数の処理ノードの中に同期処理ノードを有する。前記業務フローシステムは、同時処理案件に対応する複数の業務プロセスを併行して進行させるときに同期処理ノードの処理タイミングを同期させる。
【００４６】前記同期処理ノードは、顧客に対する電話確認ノードを含んでもよい。本システムは、前記電話確認ノードでの電話確認が不成功のとき、前記複数の業務プロセスにおける電話確認ノードの処理を再び同時に実行させてもよい。
【００４７】また前記同期処理ノードは、顧客宛の手続処理結果の発送に関する処理ノードを含んでもよい。
【００４８】本発明によれば、同期処理案件のための複数の業務プロセスを併行して進行するとき、それら業務プロセスに設けられた同期処理ノードが利用される。例えば、顧客に対する電話確認を、複数の業務プロセスで同時に行なうことができる。また顧客に対する処理結果通知を、複数の業務プロセスで同時に発行できる。本発明によれば、このような同期処理を確実に管理して実現でき、これにより、顧客の手間を減らして顧客サービスの向上を図り、また業務処理側の手間の削減も図れる。
【００４９】また本発明によれば、電話確認ノードでの電話確認が不成功のとき、複数の業務プロセスにおける電話確認ノードの処理を再び同時に実行させる。所定の再確認時刻や確認間隔を設定してもよい。例えば、顧客が不在の場合でも、再度同時確認ができる。したがって、本発明の同期処理ノードの利点を確実に生かせる。
（６）本発明の一態様の集中業務処理システムは複合同時判定手段を含む。複合同時判定手段は、一の顧客に関して複数の請求案件が取得されたときに、それら複数の請求案件が、一の請求案件の後に別の請求案件を処理すべき複合処理案件に該当するか否か、および、同時に併行して処理されるべき同時処理案件に該当するか否か、を判定する。
【００５０】好ましくは、前記複合同時処理判定手段は、複数の請求案件の組合せを、同時処理案件、複合処理案件およびその他に仕分けするための複合同時判定テーブルを用いる。
【００５１】好ましくは、前記複合同時処理判定手段は、前記業務プロセスと同様の形態の複合同時判定プロセスとして用意されている。前記プロセス起動手段は、一の顧客に関して複数の請求案件が取得されたときに前記複合判定プロセスを起動する。さらに前記プロセス起動手段は、前記複合同時判定プロセスの判定結果に基づいて、前記複数の請求案件が複合処理案件である場合には、それら請求案件に対応する複数の業務プロセスを、一の業務プロセスの終了後に次の業務プロセスが行なわれるように順次起動する。また前記プロセス起動手段は、前記複数の請求案件が同時処理案件である場合には、それら請求案件に対応する複数の業務プロセスを併行処理されるように起動する。
【００５２】好ましくは、前記プロセス起動手段は、一の顧客に関して一の請求案件が取得されたときにはその請求案件に対応する業務プロセスを直接的に起動し、一の顧客に関して複数の請求案件が取得されたときには前記複合同時判定プロセスを起動する。
【００５３】本発明によれば、上述した複合処理案件および同時処理案件の機能が一つのシステムに組み込まれる。したがって、それらの機能が両方とも得られる。
【００５４】また本発明では、複合同時判定テーブルを用いて、複合処理案件、同時処理案件およびその他の案件を判別する。新種の保全手続が設定されたような場合でも、そうした新種の手続に対して、テーブルの変更によって柔軟に対応できる。
【００５５】（７）本発明は、上述した集中業務処理システムの態様には限定されない。本発明の別の態様は、例えば、集中業務処理装置、集中業務処理方法、またはその方法を実現するプログラムを記録した媒体である。
【００５６】なお上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションも又発明となりうる。
【００５７】
【発明の実施の形態】以下、発明の実施の形態を通じて本発明を説明するが、以下の実施形態はクレームにかかる発明を限定するものではなく、又実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。
【００５８】図１は、集中業務処理システム１の全体構成を示している。本実施の形態では、生命保険会社の保全業務に本発明が適用される。保全業務とは、前述したように、支払や契約変更など、契約に関連して発生する手続の業務をいう。ただし、本発明が保全業務以外の業務、例えば新規契約業務（顧客とのコンタクト（募集訪問に関する業務など）および関連する承諾プロセスに適用されてもよい。また本発明が生命保険以外の業務処理に適用されてもよい。
【００５９】図１に示すように、集中業務処理装置１０は、センタ集配サーバ１２を介して拠点端末装置１４と接続されている。拠点端末装置１４は、全国に分散配置された生命保険会社の支部等の手続受付窓口に配備されている。手続受付窓口は、顧客から保全手続の請求書類を受け取る。拠点端末装置１４は、書類読取り装置としてのスキャナを有する。請求書類はスキャナによりイメージデータに変換される。さらに、書類に記入された文字等は、文字認識機能を用いてコード化される。これらイメージデータおよびコードデータは、請求案件情報としてセンタ集配サーバ１２に送られる。センタ集配サーバ１２は、請求案件情報を集中業務処理装置１０に受け渡す。集中業務処理装置１０は、受け取った請求案件情報に基づいた業務処理を行なう。
【００６０】拠点端末装置１４は、営業員等により携帯される携帯端末でもよい。携帯端末は、支部を経由してセンタと通信してもよく、支部を経由せずにセンタと通信してもよい。
【００６１】また集中業務処理装置１０は、ホストゲートウエイサーバ１６を介して、マスターファイルを格納するホストシステム１８と接続されている。ホストシステム１８は、全部の契約のマスターファイルを保管している。集中業務処理装置１０により業務処理が行なわれると、業務処理にしたがってマスターファイルが書きかえられる。
【００６２】図２は、集中業務処理装置１０の構成を示している。業務フローシステム２０は、いわゆるワークフローシステム（ワークフローエンジン、ワークフローシステム本体）の応用である。業務フローシステム２０には各種の業務プロセスが定義されており、これにより業務フローシステム２０は各種の業務プロセス機能を備える。これら業務プロセスのそれぞれは特定の請求案件に対応している。
【００６３】各業務プロセスは、図示のように複数のノード（四角形）で構成される。業務プロセスに沿って各ノードの処理を順次実行することにより、請求案件の処理が達成される。ただし、業務フローシステム２０は、実際に請求案件情報を処理するのではなく、業務プロセスに沿って処理を進行させる役割を持つ。この点については後述する。
【００６４】ディスパッチャ２２は、本発明のプロセス起動手段に相当し、集中業務処理装置１０の外部インターフェース機能の一部である。ディスパッチャ２２は、業務フローシステム２０とのインターフェース機能をもつ。ディスパッチャ２２は、請求案件が取得されたときに、その請求案件に対応する業務プロセスを業務フローシステム２２に起動させる。
【００６５】業務支援データベース２４は請求案件情報を格納している。業務支援データベース２４は、業務フローシステム２０から外出し形式で、つまり別体に設けられている。請求案件情報は、拠点から送られてきた情報である。上述のように、請求案件情報は、請求書類のイメージデータと、イメージデータから得られたコードデータを含む。業務プロセスの各ノードでは、業務支援データベース２４の請求案件情報が処理対象になる。
【００６６】案件管理データ記録データベース２６は、各種請求案件の業務プロセス上での状況を管理する。すなわち、請求案件が業務プロセスのどこまで進んでおり、どのような状態にあるか、といった情報を管理する。案件管理データ記録データベース２６も、業務支援データベース２４と同様、業務フローシステム２０から外出し形式で設けられている。
【００６７】アプリケーションサーバ２８は、業務プロセスの各ノードで用いられるアプリケーションソフトを有している。各ノードでの必要に応じて適当なアプリケーションがクライアント端末等に提供される。
【００６８】ワークリストサーバ３０は、いわゆるメールボックスの機能をもつ。ワークリストサーバ３０は、業務フローシステム２０と、その外側に位置するアプリケーションサーバ２８との間での、案件に関する情報の受け渡しに利用される。業務プロセスのノードからノードへの請求案件の移行は、ワークリストサーバ３０を介して実現される。
【００６９】図３は、業務フローシステム２０、ディスパッチャ２２、業務支援データベース２４、案件管理データ記録ベース２６、アプリケーションサーバ２８およびワークリストサーバ３０の機能と関係を示す。
【００７０】図３には、業務フローシステム２０に関連して典型的な業務プロセスの一例が示されている。業務プロセスは、振分（ホスト照会）ノード、点検ノード、二次点検ノード、認証ノードおよびホスト処理（マスターファイル更新）ノードを有する。振分ノードおよびホスト処理ノードでは業務処理装置により機械的（自動）処理が行われる。点検ノード、二次点検ノードおよび認証ノードでは、担当者が端末装置を操作して業務処理を行う。
【００７１】振分ノードでは、拠点から入手した請求案件情報（コードデータ）を基に、ホストシステムに対するオンライン照会が自動的に行われ、マスターファイルから業務処理に必要なデータが取り込まれる。また、図では省略されているが、プロセス中の適当なノードへと請求案件を振り分ける処理が行われる。点検ノードでは基本的点検作業が行なわれる。基本的点検作業は、請求書イメージと入力項目との照合、必要書類の点検などである。二次点検では、点検者の修正入力に対する相互点検（内部牽制的な意味合い）、認証では、高額支払などの手続内容に応じた要件の確認および決済が行われる。ホスト処理は最終的な更新処理であり、ホストシステムに格納されたマスタファイルに対して自動的（機械的）な更新処理が行われる。
【００７２】図３の業務プロセスに対応する請求案件がセンタ集配サーバ１２から集中業務処理装置１０に提供されたとする。このとき、ディスパッチャ２２は、請求案件を識別し、その請求案件に対応する図３の業務プロセスを業務フローシステム２０に起動させる。
【００７３】業務プロセスが起動すると、業務フローシステム２０は、処理すべき請求案件を、最初のノードである振分ノードに進める。請求案件が、プッシュ形式でワークリストサーバ３０のワークリスト送受信箱に入れられる。
【００７４】ここで、請求案件情報（イメージおよびコード）自体は、業務支援データベース２４に格納されており、業務プロセス上では動かない。業務プロセス上を移動するのは、主として請求案件を特定するための情報である。そこで、本実施の形態では、プロセスに沿ってノードおよびワークリストサーバを移動する情報を、案件特定情報と呼ぶ。
【００７５】案件特定情報が最初のワークリストサーバに入ったことを受けて、アプリケーションサーバ２８では、アプリケーションである振分アクティビティが機能する。請求案件に対応するマスタファイルが、ホストシステム１８に対して照会され、必要なデータが取り込まれ、業務支援データベース２４の請求案件情報に与えられる。この処理は上述のように自動的に行われる。
【００７６】振分ノードの処理が終わると、処理の終了が分かるように、ワークリストサーバ内の情報が振分アクティビティにより書き換えられる。例えば、処理終了を示すフラグが立てられたり、マークが付けられる（後のノードでも同様）。これに応えて、業務フローシステム２０は、案件特定情報を、振分ノードのワークリスト送受信箱から、点検ノードのワークリスト送受信箱へと移動させる。
【００７７】点検ノードの作業担当者は、クライアント端末を操作して、ワークリスト送受信箱内の請求特定情報により特定される請求案件を点検する。これは、アプリケーションサーバ２８から提供されるアプリケーションを用いた点検アクティビティにより実現される。点検処理は、業務支援データベース２４内の請求案件情報を用いて行なわれる。また、点検が行なわれたことを示す情報は、請求案件の状況情報として、案件管理データ記録データベース２６に記録される。
【００７８】業務フローシステム２０は、点検ノードのワークリスト送受信箱内にある請求案件の処理が終了すると、請求案件特定情報を、点検ノードのワークリスト送受信箱から、二次点検ノードのワークリスト送受信箱へと移動させる。これにより業務プロセスが二次点検ノードへと移行する。
【００７９】二次点検ノードおよび認証ノードでも、点検ノードと同様に、外出しの業務支援データベース２４および案件管理データ記録ベース２６に対して、アプリケーションサーバ２８のアプリケーションを用いた処理が行なわれる。ただし、各ノードでは、異なる作業担当者により作業が行なわれる。
【００８０】認証ノードの処理が完了すると、案件特定情報は、ホスト処理ノードのワークリスト送受信箱へと移される。これに応えて、アプリケーションサーバ２８側でホスト処理アクティビティが機能する。ホストシステム１８にアクセスして、請求案件の処理結果をマスターファイルに反映する更新処理が行われる。業務フローシステム２０は、ホスト処理の送受信箱内にある案件の処理が終了すると、その案件についての業務プロセスを終了させる。
【００８１】以上、図３を参照して、本実施の形態における基本的な業務処理の流れを説明した。
【００８２】ここで、一般的なワークフローシステムでは、処理対象の情報が業務プロセス上を移動する。そのため、ワークフローシステム内の案件を外から参照したり、案件を外から制御することは困難であり、そのような処理を実現するためにはワークフローシステムの大幅な変更等が必要である。
【００８３】これに対し、本実施の形態では、ワークフローシステム上は、案件特定情報が移動していく。実際に処理される案件情報は、ワークフローシステムの外の業務支援データベースにいる。そして、案件情報の処理も、ワークフローシステムの外のアプリケーションサーバで行われる。これにより、ワークフローシステムのプロセス途中における案件情報の参照や制御、案件間の情報共有化を、簡単な構成で実現している。
【００８４】上記の利点を得るために、本実施の形態では、ワークリストサーバが好適に利用されている。プロセス上の各ノードで、案件特定情報がワークフローシステムからワークリスト送受信箱に入れられる。アプリケーションサーバは、送受信箱を見て、ワークフローシステム外部で、該当ノードの必要な処理を行う。処理が終わると、案件特定情報がワークフローシステムに戻され、次のノードに進められる。すなわち、ワークリストサーバにより、案件特定情報を介して、ワークフローシステムとアプリケーションサーバの案件受け渡しが実現されている。
【００８５】なお、案件特定情報とともに、請求日時等の幾つかの情報がプロセス上を移動してもよい。これら情報は、ワークリスト送受信箱の内容を表示するときなどに便利に用いられる。
【００８６】また、図３の業務プロセスは、業務フローシステム２０に用意された複数の業務プロセスの一つである。本実施の形態では、図４に示す各種の業務プロセスが用意されている。これらの中には、図３に示されるように振分、点検、二次点検、認証およびホスト処理で構成されるものもあり、それ以外のノードをもつものもある。また、図４に示されるように、業務プロセスは、支払、契約変更および汎用に大別される。汎用は、集中処理装置または拠点からの要求により案件内容を照会するため等、業務を特定しないプロセスである。その他、これら業務プロセスのほかに、後述するように、複合処理案件および同時処理案件を判定するための判定プロセスが業務フローシステム２０に用意されている。
【００８７】また、集中業務処理装置１０には、全国の支社から次々と多数の請求案件が送られ、それら請求案件に対応する業務プロセスが起動される。したがって、図３の業務プロセス上を幾つもの請求案件が移動していく。
【００８８】図５は、集中業務処理装置１０で用いられる業務処理作業用の画面の一例である（図面では、請求書類のイメージ等は部分的に省略および簡略化されている、以下同じ）。図５には、図３の点検ノードで端末上に表示される画面が示されている。画面の左半部には、顧客により記入された請求書類のイメージが表示されている。また画面の右半部には、イメージデータから文字認識機能により読み取られたコードデータ、および、そのデータを基にホストシステムのマスタ−ファイルを照会した結果が表示される。点検作業者は、両者を見比べて相違の有無を点検する。
【００８９】図１の説明に戻り、集中業務処理装置１０はさらに入力支援部３２、認証・権限管理部３４、案件管理ツール３６、運用管理部３８を有する。入力支援部３２は、各作業者による入力作業を支援するためのインターフェースを提供する。認証・権限管理部３４は、各作業者の認証資格や作業権限を管理する。案件管理ツール３６は、処理中の案件に対して中断、取消等の割込制御を行なう。運用管理部３８は、装置内の各部にプログラムを配布したり、システムの稼働状態を確認するなどの機能をもつ。
【００９０】また集中業務処理装置１０は外部インターフェース部４０を有する。外部インターフェース部４０は、前述のディスパッチャ２２のほかに、拠点通知部４２、不備管理部４４、印刷サーバ４６、ホスト連動サーバ４８およびホスト・既存運用システムファイル転送部５０を含む。
【００９１】拠点通知部４２は、センタ集配サーバ１２を経由し、拠点端末装置１４に対して各種の情報を通知する。案件照会の応答情報も拠点通知部４２により通知される。
【００９２】不備管理部４４は、業務プロセスにて請求書類の不備が発見されたとき、その不備および不備解消のための情報を管理する。不備を通知する情報が拠点端末装置１４に送られ、拠点端末１４から不備を解消した書類のデータを受け取る。
【００９３】印刷サーバ４６は、請求案件情報等の印刷処理を管理する。ホスト連動サーバ４８は、ホストゲートウエイサーバ１６を介したホストシステム１８との連動を実現する。この機能により、ホスト１８のマスターファイルが参照され、請求案件の処理結果がマスターファイルに反映される。ホスト・既存運用システムファイル転送部５０は入力支援やシステム構成定義などのデータ転送機能を有する。
【００９４】その他の構成として、集中業務処理装置１０は、ＯＳ等の基本ソフト５２および運用基本ソフト５４をもつ。また、作業者が操作するクライアント端末のための構成として、アプリケーションクライアント５６、クライアント基盤５８およびＯＳ等の基本ソフト６０が用意されている。図１には示されないが、多数の作業者、すなわち多数のクライアント端末により業務作業が行なわれる。
【００９５】次に、本実施の形態に特徴的な、複合処理案件および同時処理案件を処理する機能について説明する。
【００９６】一の顧客から複数の請求書類が受けつけられることがあり、そうした複数案件の中には、複合処理案件および同時処理案件が含まれる。複合処理案件とは、互いに依存関係があって決められた順序に従って処理されるべき複数案件であり、すなわち、一の請求案件の後に別の請求案件を処理すべき複数案件である。また同時処理案件は、依存関係のない複数案件であって、業務効率の観点からも同時に併行して処理されるべき複数案件である。本システムは、以下に説明するように、通常のワークフロー製品には実装されていない、こうした複合処理案件および同時処理案件を関連付けて実行、管理する機能を備える。
【００９７】図６は、複合処理案件および同時処理案件を自動的に判別するための複合同時判定プロセスを示す。この複合同時判定プロセスは、上述した業務プロセス群と同様の形態を有し、業務フローシステム２０に備えられている。
【００９８】ディスパッチャ２２は、一の顧客に関して一の請求案件が取得されたときには（単独案件）、その請求案件に対応する業務プロセスを直接的に起動する。一方、ディスパッチャ２２は、一の顧客に関して複数の請求案件が取得されたときには、図６の複合同時判定プロセスを起動する。
【００９９】なお、複数の請求案件には、同じ契約に関する複数案件と、別契約に関する複数案件が含まれる。後者は、例えば、顧客本人の契約変更手続と、その家族の契約の変更手続である。
【０１００】図６の複合同時判定プロセスでは、一顧客の複数請求は、まず機械判定ノードに進められ、機械判定ノードのワークリスト送受信箱に入れられる。アプリケーションサーバ２８から提供される機械判定アクティビティは、複合同時判定テーブルを用いて、複数請求案件が(i)複合処理案件、(ii)同時処理案件および(iii)その他の例外案件のいずれに属するかを判定する。判定処理では、証券番号、処理コードなどの請求案件を特定する情報が用いて判定テーブルが参照される。
【０１０１】機械判定アクティビテイは、判定結果を業務支援データベース２４に記録する。業務支援データベース２４には管理フォルダが設けられる。この管理フォルダを用いて、互いに複合関係および同時関係にある案件が紐付け管理される。管理フォルダには、案件管理番号、証券番号、業務コード、複合同時区分、同時状況区分、複合状況区分、複合順序、フォルダ番号などのデータを書き込むことができる。
【０１０２】図７〜図９は、複合同時判定テーブルの例を示している。図７は、複合処理案件に分類されるべき請求案件の組合せを示し、図８は、同時処理案件に分類されるべき請求案件の組合せを示し、図９は、例外案件に分類されるべき請求案件の組合せを示している。例外には、特殊な案件（組合せ）が含まれ、同じ請求書類の二重投入のような入力ミスも含まれる。
【０１０３】図７〜図９のそれぞれにおいて、「同一契約」と「別契約」の２つのテーブルが示されている。「同一契約」とは、同じ契約に対する複数の請求案件であり、「別契約」とは、それぞれ別の契約に対する複数の請求案件であり、例えば顧客本人の契約と家族の契約についての請求案件である。
【０１０４】また、図７〜図９では、２つの案件の組合せについての判定テーブルが示されている。これに対し、３つ以上の案件の組合せについても判定可能なようにテーブルを構成してもよい。また、３つ以上の案件の組合せに関する判断は、後述する人判定に委ねられてもよい。
【０１０５】また実際のシステムでは、複合同時判定テーブルは、図７〜図９のうちの２種類のテーブルで構成することも好適である。好ましくは、複合同時判定テーブルが、図７の複合判定テーブルと図９の例外判定テーブルにより構成される。これらテーブルに入らない案件の組合せは同時処理案件と判断される。
【０１０６】さらに、上記の２種類のテーブルは、３つ以上の案件組合せの判定に際しては以下のように用いられてよい。３以上の案件から任意の２案件のペアをつくる。すべてのペアが図７および図９に該当しないとき、全案件を同時処理対象とする。そうでない場合は、人判定等を適用に用いて、複合または例外処理とする。
【０１０７】図６に戻り、機械判定アクティビティの処理が終了すると、業務フローシステム２０は、請求案件（請求案件のセット）の案件特定情報をワークフロー起動ノードへと進め、ワークフロー機能ノードのワークリスト送受信箱へと請求案件を入れる。また、一部の特定の請求案件は、機械判定ノードから人判定ノードへと進められる。
【０１０８】人判定ノードに進む請求案件は、複合または同時と判定された請求案件であって、名義変更等の特定の人判定処理を含む案件である。人判定に進むべき請求案件も予め定められている。
【０１０９】人判定ノードでは、作業者により複合・同時判定が行われる。ここでは、人判定アクティビティにより、作業者に対して、請求案件がどのように処理されるべきか（複合・同時）が問い合わされる。作業者が端末を使って判定を入力する。入力された判定に従って案件管理フォルダが作成される。機械判定ノードで複合または同時と判定された案件であっても、例外案件にまわされることもある。
【０１１０】また、３つ以上の請求案件が取得されたときには、同一契約の案件と別契約の案件とが混在する場合がある。例えば、顧客本人の一契約に対する２つの請求案件および顧客の家族の契約に対する１つの請求案件といった組合せが考えられる。このような混在型の請求案件も人判定ノードに送られる。人判定ノードでは、作業者により複数の請求案件が適当に分割され、分割後に複合、同時等の判定が加えられる。
【０１１１】上記の人判定ノードの処理が終了した請求案件は、業務フローシステム２０によりワークフロー起動ノードへと進められる。請求案件がワークフロー起動ノードに進んでワークリスト送受信箱に入ると、ワークフロー起動アクティビティにより、ディスッチャ２２に対して、請求案件に対応する業務プロセスの起動が指示される。
【０１１２】ディスパッチャ２２は、起動指示を受けて、請求案件の組合せに対応する複数の業務プロセスを起動する。起動の際、ワークフロー起動アクティビテイにより業務支援データベース２４の案件管理フォルダに格納された複合、同時判定結果が参照される。
【０１１３】請求案件の組合せが複合処理案件に該当する場合、予め定められた適正順序に従って処理が行われるように、すなわち一の業務プロセスの終了後に次の業務プロセスが行なわれるように、ディスパッチャ２２は、各業務フロー内のワークフロー起動アクティビティの指示に基づく、複数の業務プロセスを順次起動する。また請求案件の組合せが同時処理案件に該当する場合、ディスパッチャ２２は、それら請求案件に対応する複数の業務プロセスを一斉に起動する。
【０１１４】また、請求案件の組合せが例外案件に該当する場合は、汎用例外プロセスが起動される。そして、請求案件の書類が、印刷サーバによって、本社担当課のプリンタに印刷される。本社担当課では手作業で請求書類を処理のうえ、該当プロセス（汎用例外）の完了入力を行う（一度案件をワークフローの外に出し、処理済後差し戻す）。
【０１１５】図１０は、複合処理の流れを示している。まず、ディスパッチャ２２により、複合順序の一つ目の業務プロセスが起動され、業務フローシステム２０により業務プロセスが進行される。業務プロセスの最後の部分には、次案件起動ノードが設けられている。この起動ノードは、請求案件が複合処理案件に該当するときに機能する。次案件起動ノードでは、業務支援データベース２４が参照され、処理中の請求案件と関連づけられた別の案件が求められる。これにより、複合順序上で次に処理されるべき案件が求められる。そしてディスパッチャ２２により次の案件に対応する業務プロセスが起動される。
【０１１６】複合処理されるべき最後の案件の処理が進み、その案件の処理が次案件起動ノードに達したとする。このとき、業務支援データベース２４の案件管理フォルダが参照され、すべての複合処理が終了したことが判定される。これにより複合処理案件の処理が終了する。
【０１１７】なお、本実施の形態では、基本的にすべての業務プロセスの終わりに次案件起動ノードが設定されている。また、各業務プロセスは、単独案件の処理と、複合処理案件の処理と、後述する同時処理案件の処理とで共用される。しかし、次案件起動ノードは、請求案件が複合処理対象のときのみ機能する。すなわち、業務プロセスが他の業務プロセスと直列連結されるときのみ機能する。そこで、複合処理以外の説明および図面では、次案件起動ノードは省略されている。
【０１１８】図１１は、同時処理の流れを示している。同時処理では、ディスパッチャ２２は、複数の業務プロセスを一斉に起動させる。業務フローシステム２０は、それら業務プロセスを併行して進行させる。
【０１１９】業務プロセス上には同期処理ノードが定められている。同期処理ノードは、請求案件が同時処理案件に該当するときに機能する。同期処理ノードは、例えば、電話確認ノード、ホスト処理ノード、不備通知ノード、顧客宛結果発送ノードなどである。
【０１２０】同期処理ノードに到達する前は、複数の業務プロセスはばらばらに進行しており、それらは互いにずれていてよい。同期処理ノードでは、併行処理されている複数の請求案件の待ち合わせにより、複数の業務プロセスにおける同期処理ノードの処理タイミングが同期する。例えば、顧客に対する電話確認が、複数の請求案件に関してまとめて行われる。待合せは、後述するように、同期処理ノードの前に設けられた待合せノードを用いて実現される。
【０１２１】同期処理ノードを過ぎると、また、複数の処理が併行して行われる。業務プロセスには複数の同期処理ノードが設定されていてもよい。この場合、次の同期処理ノードで、再び待ち合わせ、同期処理が行われる。
【０１２２】次に、図１２は、同時処理の流れをより具体的に示している。図１２を用いて複数プロセスの待合せについて説明する。また、同期処理案件の数が３以上である場合において、一部の案件のみが、同じ同期処理ノードをもつ場合がある。この場合の処理も図１２に示されている。
【０１２３】図１２では、同時処理される３本の業務プロセスが示されている。上側の２本の業務プロセスには電話確認ノードが設定され、電話確認ノードの前段に電話確認待合せノードが設定されている。一方、一番下の業務プロセスには電話確認ノードは設定されていない。また、３本のプロセス全部に、ホスト処理ノードが設定され、かつ、ホスト処理ノードの前段に同期待合せノードが設定されている。上記の電話確認ノードおよびホスト処理ノードは、同期処理ノードの一形態である。
【０１２４】図１２の処理では、一つの請求案件が電話確認待合せノードに到達すると、業務支援データベース２４の案件管理フォルダを参照して、同時処理される請求案件の本数Ｎ（＝３）が参照される。電話確認待合せノードおよび同期待合せノードに達した案件数の合計が、同時処理本数Ｎに達したとき、同期完了と判定される。上側の２本の業務プロセスにおいて、請求案件が電話確認ノードへと進められる。これにより２つの案件の電話確認が同時に行われる。
【０１２５】電話確認が終わると、請求案件は同時待合せノードへと進む。これにより、３本の業務プロセスの請求案件が同期待合せノードへ到達する。待合せが完了したので、３つの請求案件はホスト処理ノードへと進む。これにより、ホスト処理が、３つのプロセスで同期したタイミングで行われる。
【０１２６】このように、本実施の形態では、業務プロセスに待合せノードを設けるという比較的簡単な構成により、併行処理される複数のプロセスの一部タイミングを確実に同期させることができる。そして、一部のプロセスが該当する同期処理（図１２では電話確認ノード）をもたない場合でも、別の待合せノードを利用して、同期処理を適切に行える。
【０１２７】なお、本実施の形態では、各業務プロセスは、単独案件の処理と、複合処理案件の処理と、同時処理案件の処理に共用される。しかし、待合せノード（同時待合せノードおよび電話確認待合せノード）は、請求案件が同時処理対象のときのみ機能する。そこで、同時処理以外の説明および図面では、待合せノードは省略されている。
【０１２８】次に、複合処理における同時電話確認について説明する。複合処理案件については、前述したように、複数の業務プロセスが順次実行される。複数の業務プロセスが電話確認ノードをもつ場合、それら電話確認ノードのそれぞれで電話確認が行われ、その結果、顧客に対して複数回の電話確認が行われる。しかし、電話確認はまとめて行う方が、顧客の手間を削減するうえで望ましい。そこで、本実施の形態では、以下のようにして、複合処理においても同時電話確認を実現している。
【０１２９】図１３は、複合処理における同時電話確認を示している。図１３には、現処理中の案件の業務プロセスが示されている。現処理中の案件は、複合処理対象として関連づけられた複数案件のうちの一番目の案件である。
【０１３０】請求案件が電話確認ノードに到達すると、前述したように案件特定情報がワークリスト送受信箱に入れられる。アプリケーションサーバ２８の電話確認アクティビティにより、請求案件が取り出され、処理される。クライアント端末に電話確認用の画面が表示され、担当者に電話確認が促される。
【０１３１】ここで、電話確認アクティビティは、業務支援データベース２４を参照して、現処理中の案件と関連付けられた案件、すなわち、現処理中の案件の後段で処理される案件を確認する。３つ以上の案件が関連づけられている場合、すべての後続案件が確認される。そして、電話確認アクティビティは、後段の各案件の内容が電話確認を必要とするか否かを判定する。後続案件の電話確認が必要な場合、電話確認用の端末画面には、現処理中の案件に加えて、後続案件が示される。画面上には、電話確認内容が表示される。また必要に応じて、例えば担当者の指示により、後続案件の情報が画面表示される。
【０１３２】担当者は、複数案件が表示された画面をみて、それら案件の電話確認をまとめて行う。担当者が電話確認結果を入力すると、確認結果は業務支援データベース２４に記録される。もちろん、現処理中の案件情報と、後続案件情報の両方について、確認結果が記録される。また、電話確認の履歴が、案件管理データ記録データベース２６に記録される。
【０１３３】電話確認が終了すると、業務フローシステム２０は請求案件を次ノードへ進める。請求案件が次案件起動ノードへ達すると、ディスパッチャ２２に起動が指示される。ディスパッチャ２２は、次の請求案件に対応する業務プロセスを起動する。
【０１３４】後段の業務プロセスでは、電話確認はすでに終了していることを業務支援データベースを利用して引き継ぐ。そこで、電話確認ノードをパスして、業務フローシステム２０は請求案件を次ノードへ進める。これにより、電話確認が省略される。
【０１３５】以上のように、本実施の形態では、複合処理においても同時処理を実現できる。顧客にとってみれば、１回の請求に対する電話確認をまとめて受けられるので、電話応対の手間が減る。したがって顧客に対するサービス性の向上が図れる。また業務処理側の手間の削減も図れる。
【０１３６】図１４〜図１６は、複合、同時処理案件の処理の際に作業者端末に表示される画面の例を示している。図１４は、ある請求案件の点検画面である。表示された請求案件が別の案件と紐付けられている（複合または同時処理案件である）ときは、図１４の画面右上に示されるように、「同時」または「複合」ボタンが表示される。図１４の例では「同時」ボタンが表示される。
【０１３７】作業者が「同時ボタン」をクリックすると、図１５に示すように、同時処理されている別の案件を示すボタンが表示される（画面右上、矢印マーク）。図１５には一つのボタンが示されているが、同時処理件数が３以上の場合には、その件数に応じた数のボタンが表示される。
【０１３８】作業者が、同時案件のボタンをクリックすると、図１６に示すように、クリックされた案件の請求書イメージが表示される。複合、同時案件では、書類（印鑑証明など）を共有することがあるので、別案件の書類イメージを参照できることは、業務作業にとって有用である。
【０１３９】図１７は、同時処理において表示される同期電話確認用の画面の例を示している。図示のように、同時に電話確認を行うべき案件のリストが表示される。
【０１４０】図１８は、複合、同時案件のデータを印刷したときのヘッダ用紙の例を示している。図示のように、複合、同時として紐付けられた関連案件の情報がまとめてヘッダ用紙に印刷される。
【０１４１】本システムでは、上述の他、複合同時の関連案件については、管理情報、案件内容、付属書類、進捗状況を参照できるように構成する。
【０１４２】次に、業務プロセスにおける電話確認処理、特にそのリコール機能についてさらに説明する。本集中業務処理装置は、顧客本人宛の電話連絡の確実な遂行を支援する。
【０１４３】図１９は、電話確認処理の一例である。ここでは単独案件が処理される。点検ノードでの点検処理が終了した請求案件は、単独電話確認ノードへと進められる。ただし、電話確認が不要な案件は、直接ホスト処理ノードへと進められる。
【０１４４】単独電話確認ノードでは、作業担当者が、端末画面の表示を見て、顧客に対して電話確認を行う。例えば支払関連の保全手続では、本人の意志が電話で確認される。電話確認が終了した案件は、認証ノードを経て、ホスト処理ノードへと進められる。
【０１４５】顧客が不在であった場合などには、請求案件は電話確認待機ノードへ進められる。電話確認待機ノードでは、リコール（再電話）予定時刻が設定される。予定時刻の代わりに、リコールまでの期間が設定されてもよい。リコール時刻が到来すると、請求案件は再び単独電話確認ノードへ進められる。これにより、電話連絡指示が担当者の端末画面に表示される。担当者は、画面の指示に従って電話確認を行う。
【０１４６】このように、本実施の形態では、リコール予定をシステム側で一元管理することにより、電話漏れ等を確実に防止でき、確実な電話確認が可能となる。
【０１４７】また、電話確認待機ノードへ移行するときは、電話確認の応対データが業務支援データベース２４に保存される。例えば、顧客が不在である場合に、顧客の家族との対話内容が記録される。再確認の電話連絡指示を表示するときは、応対データも表示される。これにより、担当者不在等の理由で他の担当者が再確認を行う場合でも、応対経緯に基づいた適切な電話確認が可能となる。
【０１４８】図２０は、電話確認において端末に表示される画面の例である。図示のように、電話確認未完了の場合には、リコール時刻が設定され、さらに応対履歴が記録される。
【０１４９】図２１は、電話確認処理のもう一つの例であり、ここでは同時処理案件が処理される。同時処理対象の複数の案件のうちで、電話確認が不要な案件は、点検ノードから直接同期待合せノードへと送られる。一方、電話確認が必要な案件は、電話確認待合せノードへと送られる。
【０１５０】電話確認待合せノードでは、同期電話確認のための待合せが行われる。このとき、電話確認が不要な案件が同時処理対象に混じっている可能性を考慮して、以下の処理が行われる。まず同時処理対象の案件数Ｎが取得される。そして、電話確認待合せードと同時待合せノードに位置する案件数の合計が、上記処理対象案件数Ｎに達したとき、同期完了と判定される。要するに、同期処理対象の全案件が電話確認待合せノードか同時待合せノードに達したときに、同期完了と判断される。
【０１５１】同期が完了すると、請求案件が電話確認待合せノードから同期電話確認ノードへと移される。担当者の端末画面に電話連絡指示が表示される。この指示には、同時処理される複数案件が示される。この指示に従って担当者により、複数の案件の電話確認がまとめて行われる。このとき、関連案件の詳細情報、付属情報も担当者の指示に従って画面で参照される。
【０１５２】電話確認が完了すると、請求案件は認証ノードを経て同時待合せノードへと移される。同時待合せノードにて、同時処理対象の全案件がそろうと、それら案件はホスト処理ノードまたは不備通知ノードへと移される。そしてここでも待合せノードによる待合せの結果として同期処理が行われる。
【０１５３】一方、同時電話確認が未完了の場合（顧客不在など）、確認対象の案件が電話確認待機ノードへと移される。待機ノードの処理は基本的に単独案件の場合と同様である。すなわち、リコール予定時刻が設定され、かつ、応対経緯が記録される。そしてリコール予定時刻が到来すると、請求案件は電話確認待合せノードへと移され、これにより再び同期電話確認が行われる。上述より明らかなように、このループでは複数の案件が一緒に移動される。
【０１５４】このように、本実施の形態では、同時処理案件について、複数の電話確認をまとめて行うことができる。一部の案件の電話確認が不要な場合でも、同時待合せノードを設けた簡素な構成により、同期確認を確実に行える。
【０１５５】次に、複合処理におけるリコール機能について説明する。複合処理においても、図１９に示したリコール処理が行われる。すなわち、電話確認ノードでの電話確認が未完了の場合、請求案件は電話確認待機ノードへ進められる。電話確認待機ノードでは、リコール（再電話）予定時刻が設定される。リコール時刻が到来すると、請求案件は再び単独電話確認ノードへ進められ、電話確認が再び行われる。
【０１５６】ここで、本実施の形態では前述したように複合処理において、一番目の請求案件のプロセス上で、一番目の案件および後続案件の電話確認がまとめて行われる。この同時確認は、リコールの際にも行われる。すなわち、待機ノードの後の電話確認ノードでも、現処理中の案件と後続案件の情報が、電話確認用の端末画面に表示される。それら案件の電話確認が担当者により行われる。
【０１５７】以上、本発明の好適な実施の形態を説明した。
【０１５８】本実施の形態によれば、その基本的な利点として、請求案件の書類がデータ（電子データ等）のかたちで集中業務処理装置へと送られるので、書類の物流に伴う制約から解放される。これにより、手続を迅速化でき、書類の受渡しに伴うハンドリング業務も削減できる。また書類の不備を早期に発見でき、不備への対応も早められる。
【０１５９】また本実施の形態によれば、各種の請求案件にそれぞれ対応する業務プロセス機能をもった業務フローシステムが設けられる。手続の新設、追加、変更などに対しては、業務プロセス機能の新設、追加、変更などにより対処できる。したがって、業務処理の変化に柔軟に対応することができる。
【０１６０】また本実施の形態によれば、上述の物流の削減と、それに関連する業務の削減、さらには、予め用意した複数の業務プロセス機能を選択的に用いる効率的な業務処理により、業務コストを削減できる。
【０１６１】さらに本実施の形態によれば、集中事務側という局所化した環境で業務作業人員による作業が行われ、それら人員の教育も行われるようなシステムを構成可能である。高度な教育、作業を簡素化、標準化されたかたちで実現するように図れる。
【０１６２】また本実施の形態によれば、複合処理案件および同時処理案件を自動的に判定でき、それら案件を関連付けて適切に処理および管理できる（ただし、複合処理案件および同時処理案件の一方を自動判定して、上述の実施形態に示されるように処理する構成も、本発明の範囲に含まれてよい）。
【０１６３】本実施の形態では、複合処理案件および同時処理案件のために専用の業務プロセスを用意していない。代わりに、複数の業務プロセスを直列および並列に連結することにより、複合、同時処理案件のための業務プロセスが実現される。ある請求案件の業務処理を変更するときは、対応する業務プロセスを変更してやればよい。複合処理や同時処理のための専用プロセスの変更といった作業は不要である。したがって、業務処理の変更に柔軟に対応でき、システムの保守性がよい、という利点が得られる。
【０１６４】また、本実施の形態では、複合処理案件および同時処理案件を判定する手段を、業務プロセスと同様の形態で構成し、ワークフローシステムの応用である業務フローシステムの一部としている。そして、取得された請求案件の数に応じて、業務プロセスを起動したり、判定プロセスを起動したりと、業務フローシステムのプロセス起動を切りかえる。したがって、業務フローシステムの高い柔軟性を利用して複合処理案件および同時処理案件に適切に対処できる。
【０１６５】また本実施の形態では、複合同時判定テーブルを用いて、複合処理案件、同時処理案件およびその他の案件を判別する。新種の保全手続が設定されたような場合でも、そうした新種の手続に対して、テーブルの変更によって柔軟に対応できる。
【０１６６】ここで、実際の請求案件件数を分析した結果を参照すると、全件数の５／６程度は、単独案件である。残りの約１／６の請求案件は、他の案件と一緒に一の顧客から受け付けられる。こうした複数案件の組合せの殆どが、複合同時判定テーブルを用いて、複合処理案件か同時処理案件へと自動的に振り分けられる。人判定に回される案件は少数である。例外に分類されてハンドリング処理される案件も少数である。本実施の形態によれば、業務フローシステムを利用して大部分の案件を処理することができ、業務処理効率を向上できる。
【０１６７】また本実施の形態によれば、業務プロセスの終わりに設置された次案件起動ノードが利用される。ワークフローシステムの技術を基礎として、そのプロセスに次案件機能ノードを設けるという簡素な構成により、複数プロセスを連結して、複合処理案件の適正順序処理を実現できる。
【０１６８】また実施の形態によれば、同時処理案件のための複数の業務プロセスを併行して進行するとき、それら業務プロセスに同期処理ノードが利用される。同期処理ノードは、例えば電話確認ノードである。同期処理ノードを利用して、同期処理を確実に管理して実現でき、これにより、顧客の手間を減らして顧客サービスの向上を図り、また業務作業側の手間の削減も図れる。
【０１６９】また本実施の形態によれば、電話確認ノードでの電話確認が不成功のとき、リコール時刻を設定し、電話確認ノードの処理を再び同時に実行させる。したがって同期処理の利点を確実に生かせる。
【０１７０】また本実施の形態によれば、複合処理において、後続案件の確認処理を導入したことにより、複数の案件の電話確認をまとめて行える。顧客の手間が省けるのでサービス性の向上が図れる。また業務処理側の手間の削減も図れる。特に、前側の案件で後続案件を確認しているので、同時電話確認を早い段階で行えるので、この点でもサービス性を向上できる。
【０１７１】さらに本実施の形態によれば、複合処理においても、電話確認が不成功のときに、同時電話確認を再度行うことができる。これにより、複合処理案件における同時電話確認の利点を確実に生かせる。
【０１７２】以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更又は改良を加えることができる。その様な変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。
【０１７３】
【発明の効果】上記説明から明らかなように、本発明によれば、業務手続を迅速化し、業務処理コストを削減できる。また、業務処理の変更に対して柔軟に対応できるシステムを提供できる。また、複合処理案件や同時処理案件を適切に処理できるシステムを提供できる。
【図面の簡単な説明】
【図１】本発明の実施の形態における集中業務処理システムを示す図である。
【図２】図１の集中業務処理装置の構成を示す図である。
【図３】業務フローシステムおよび関連構成の機能を示す図である。
【図４】業務フローシステムに定義された業務プロセスを示す図である。
【図５】図２の集中業務処理装置で作業者端末に表示される画面の例である。
【図６】複合同時判定プロセスを示す図である。
【図７】複合同時判定プロセスで用いられる複合同時判定テーブル、特に複合判定テーブルを示す図である。
【図８】複合同時判定プロセスで用いられる複合同時判定テーブル、特に同時判定テーブルを示す図である。
【図９】複合同時判定プロセスで用いられる複合同時判定テーブル、特に例外判定テーブルを示す図である。
【図１０】複合処理の流れの例を示す図である。
【図１１】同時処理の流れの例を示す図である。
【図１２】同時処理の流れの例を示す図である。
【図１３】複合処理における同時電話確認機能を示す図である。
【図１４】同時処理において作業者端末に表示される画面の例を示す図である。
【図１５】同時処理において作業者端末に表示される画面の例を示す図である。
【図１６】同時処理において作業者端末に表示される画面の例を示す図である。
【図１７】同時処理において作業者端末に表示される画面の例を示す図である。
【図１８】同時処理案件をプリンタから出力したときのヘッダ用紙を示す図である。
【図１９】単独案件の電話確認処理を示す図である。
【図２０】電話確認処理で作業者端末に表示される画面の例を示す図である。
【図２１】同時処理案件の電話確認処理を示す図である。
【符号の説明】
１０ 集中業務処理装置
１４ 顧客端末装置
１８ ホストシステム
２０ 業務フローシステム
２２ ディスパッチャ
２４ 業務支援データベース
２６ 案件管理データ記録データベース
２８ アプリケーションサーバ
３０ ワークリストサーバ
【特許請求の範囲】
【請求項１】 多数の顧客と契約関係をもつ企業等に用いられ、契約変更等の業務手続を処理する集中業務処理システムであって、顧客から業務手続の請求案件を受け付ける複数の拠点に配備され、請求案件のデータを送信する端末装置と、前記複数の拠点から請求案件を受け取って集中的に処理する集中業務処理装置と、を含み、前記集中業務処理装置は、各種の請求案件にそれぞれ対応する複数の業務プロセス機能を備え、顧客からの業務手続の請求案件に対応する業務プロセスに沿って請求案件の処理を進行させる業務フローシステムと、前記業務フローシステムとのインターフェース機能をもち、前記請求案件に対応する業務プロセス機能を前記業務フローシステムに起動させるプロセス起動手段と、を含むことを特徴とする集中業務処理システム。
【請求項２】 請求項１に記載の集中業務処理システムにおいて、一の顧客に関して複数の請求案件が取得されたときに、それら複数の請求案件が、一の請求案件の終了後に別の請求案件を処理すべき複合処理案件に該当するか否かを判定する複合処理判定手段を含むことを特徴とする集中業務処理システム。
【請求項３】 請求項２に記載の集中業務処理システムにおいて、前記複合処理判定手段は、前記業務プロセスと同様の形態の複合判定プロセスとして用意されており、前記プロセス起動手段は、一の顧客に関して複数の請求案件が取得されたときに前記複合判定プロセスを起動し、さらに前記複合判定プロセスの判定結果に従い、複合処理案件に対応する複数の業務プロセスを、一の業務プロセスの終了後に次の業務プロセスが行なわれるように順次起動することにより、複合処理案件の適正順序処理を実現することを特徴とする集中業務処理システム。
【請求項４】 請求項３に記載の集中業務処理システムにおいて、前記プロセス起動手段は、一の顧客に関して一の請求案件が取得されたときにはその請求案件に対応する業務プロセスを直接的に起動し、一の顧客に関して複数の請求案件が取得されたときには前記複合判定プロセスを起動することを特徴とする集中業務処理システム。
【請求項５】 請求項３に記載の集中業務処理システムにおいて、前記複数の業務プロセスの各々は、対応する請求案件の処理を達成するための複数の処理ノードで構成されており、前記複合処理案件に対応する業務プロセスは、前記複数の処理ノードの終わりに次案件起動ノードを有し、前記業務フローシステムは、複合処理案件に対応する一の業務プロセスが前記次案件起動ノードに到達すると、複合処理案件に対応する次の業務プロセスを起動することを特徴とする集中業務処理システム。
【請求項６】 請求項５に記載の集中業務処理システムにおいて、前記複数の処理ノードは、顧客に対する電話確認ノードを含むことを特徴とする集中業務処理システム。
【請求項７】 請求項６に記載の集中業務処理システムにおいて、前記電話確認ノードでは、複合処理案件として現処理中の請求案件の後段で処理される請求案件の内容を確認でき、現処理中の請求案件と後段の請求案件の電話確認をまとめて行えることを特徴とする集中業務処理システム。
【請求項８】 請求項７に記載の集中業務処理システムにおいて、前記電話確認ノードでの電話確認が不成功のとき、電話確認ノードの処理を待機後に再び実行させることにより、前記現処理中の請求案件と後段の請求案件の電話確認を再び同時に実行させることを特徴とする集中業務処理システム。
【請求項９】 請求項１に記載の集中業務処理システムにおいて、一の顧客に関して複数の請求案件が取得されたときに、それら複数の請求案件が、同時に併行して処理されるべき同時処理案件に該当するか否かを判定する同時処理判定手段を含むことを特徴とする集中業務処理システム。
【請求項１０】 請求項９に記載の集中業務処理システムにおいて、前記同時処理判定手段は、前記業務プロセスと同様の形態の同時判定プロセスとして用意されており、前記プロセス起動手段は、一の顧客に関して複数の請求案件が取得されたときに前記同時判定プロセスを起動し、さらに前記同時判定プロセスの判定結果に従い、同時処理案件に対応する複数の業務プロセスを起動し、前記業務フローシステムは、それら業務プロセスの少なくとも一部の処理タイミングを同期させることを特徴とする集中業務処理システム。
【請求項１１】 請求項１０に記載の集中業務処理システムにおいて、前記プロセス起動手段は、一の顧客に関して一の請求案件が取得されたときにはその請求案件に対応する業務プロセスを直接的に起動し、一の顧客に関して複数の請求案件が取得されたときには前記同時判定プロセスを起動することを特徴とする集中業務処理システム。
【請求項１２】 請求項１０に記載の集中業務処理システムにおいて、前記複数の業務プロセスの各々は、対応する請求案件の処理を達成するための複数の処理ノードで構成されており、前記同時処理案件に対応する業務プロセスは、複数の処理ノードの中に同期処理ノードを有し、前記業務フローシステムは、同時処理案件に対応する複数の業務プロセスを併行して進行させるときに同期処理ノードの処理タイミングを同期させることを特徴とする集中業務処理システム。
【請求項１３】 請求項１２に記載の集中業務処理システムにおいて、前記同期処理ノードは、顧客に対する電話確認ノードを含むことを特徴とする集中業務処理システム。
【請求項１４】 請求項１３に記載の集中業務処理システムにおいて、前記電話確認ノードでの電話確認が不成功のとき、前記複数の業務プロセスにおける電話確認ノードの処理を再び同時に実行させることを特徴とする集中業務処理システム。
【請求項１５】 請求項１２に記載の集中業務処理システムにおいて、前記同期処理ノードは、顧客宛の手続処理結果の発送に関する処理ノードを含むことを特徴とする集中業務処理システム。
【請求項１６】 請求項１に記載の集中業務処理システムにおいて、一の顧客に関して複数の請求案件が取得されたときに、それら複数の請求案件が、一の請求案件の後に別の請求案件を処理すべき複合処理案件に該当するか否か、および、同時に併行して処理されるべき同時処理案件に該当するか否か、を判定する複合同時処理判定手段を含むことを特徴とする集中業務処理システム。
【請求項１７】 請求項１６に記載の集中業務処理システムにおいて、前記複合同時処理判定手段は、複数の請求案件の組合せを、同時処理案件、複合処理案件およびその他に仕分けするための複合同時判定テーブルを用いることを特徴とする集中業務処理システム。
【請求項１８】 請求項１６に記載の集中業務処理システムにおいて、前記複合同時処理判定手段は、前記業務プロセスと同様の形態の複合同時判定プロセスとして用意されており、前記プロセス起動手段は、一の顧客に関して複数の請求案件が取得されたときに前記複合判定プロセスを起動し、さらに前記プロセス起動手段は、前記複合同時判定プロセスの判定結果に基づいて、前記複数の請求案件が複合処理案件である場合には、それら請求案件に対応する複数の業務プロセスを、一の業務プロセスの終了後に次の業務プロセスが行なわれるように順次起動し、前記複数の請求案件が同時処理案件である場合には、それら請求案件に対応する複数の業務プロセスを併行処理されるように起動することを特徴とする集中業務処理システム。
【請求項１９】 請求項１８に記載の集中業務処理システムにおいて、前記プロセス起動手段は、一の顧客に関して一の請求案件が取得されたときにはその請求案件に対応する業務プロセスを直接的に起動し、一の顧客に関して複数の請求案件が取得されたときには前記複合同時判定プロセスを起動することを特徴とする集中業務処理システム。
【請求項２０】 多数の顧客と契約関係をもつ企業等に用いられ、契約変更等の業務手続を処理する集中業務処理装置であって、各種の請求案件にそれぞれ対応する複数の業務プロセス機能を備えており、顧客から業務手続の請求案件を受け付ける複数の拠点に配備された端末装置から、請求案件のデータが送信されてきたとき、受け取った請求案件に対応する業務プロセスに沿って請求案件の処理を進行させる業務フローシステムと、前記業務フローシステムとのインターフェース機能をもち、前記請求案件に対応する業務プロセス機能を前記業務フローシステムに起動させるプロセス起動手段と、を含むことを特徴とする集中業務処理装置。
【請求項２１】 多数の顧客と契約関係をもつ企業等に用いられ、契約変更等の業務手続を処理する集中業務処理方法であって、顧客から業務手続の請求案件を受け付ける複数の拠点に配備された端末装置から、請求案件のデータを収集するステップと、予め用意された各種の請求案件にそれぞれ対応する複数の業務プロセスの中から、顧客の請求案件に対応する業務プロセスを選択して起動するステップと、起動された業務プロセスに沿って請求案件の処理を進行させるステップと、を含むことを特徴とする集中業務処理方法。
【請求項２２】 コンピュータにて実行可能なプログラムを格納した記録媒体であって、前記プログラムは、多数の顧客と契約関係をもつ企業等において契約変更等の業務手続を処理するためのプログラムであり、前記プログラムは、顧客から業務手続の請求案件のデータが取得されたとき、予め用意された各種の請求案件にそれぞれ対応する複数の業務プロセスの中から、顧客の請求案件に対応する業務プロセスを選択して起動するステップと、起動された業務プロセスに沿って請求案件の処理を進行させるステップと、を前記コンピュータに実行せしめることを特徴とする、コンピュータにて読取可能な記録媒体。
【請求項１】 多数の顧客と契約関係をもつ企業等に用いられ、契約変更等の業務手続を処理する集中業務処理システムであって、顧客から業務手続の請求案件を受け付ける複数の拠点に配備され、請求案件のデータを送信する端末装置と、前記複数の拠点から請求案件を受け取って集中的に処理する集中業務処理装置と、を含み、前記集中業務処理装置は、各種の請求案件にそれぞれ対応する複数の業務プロセス機能を備え、顧客からの業務手続の請求案件に対応する業務プロセスに沿って請求案件の処理を進行させる業務フローシステムと、前記業務フローシステムとのインターフェース機能をもち、前記請求案件に対応する業務プロセス機能を前記業務フローシステムに起動させるプロセス起動手段と、を含むことを特徴とする集中業務処理システム。
【請求項２】 請求項１に記載の集中業務処理システムにおいて、一の顧客に関して複数の請求案件が取得されたときに、それら複数の請求案件が、一の請求案件の終了後に別の請求案件を処理すべき複合処理案件に該当するか否かを判定する複合処理判定手段を含むことを特徴とする集中業務処理システム。
【請求項３】 請求項２に記載の集中業務処理システムにおいて、前記複合処理判定手段は、前記業務プロセスと同様の形態の複合判定プロセスとして用意されており、前記プロセス起動手段は、一の顧客に関して複数の請求案件が取得されたときに前記複合判定プロセスを起動し、さらに前記複合判定プロセスの判定結果に従い、複合処理案件に対応する複数の業務プロセスを、一の業務プロセスの終了後に次の業務プロセスが行なわれるように順次起動することにより、複合処理案件の適正順序処理を実現することを特徴とする集中業務処理システム。
【請求項４】 請求項３に記載の集中業務処理システムにおいて、前記プロセス起動手段は、一の顧客に関して一の請求案件が取得されたときにはその請求案件に対応する業務プロセスを直接的に起動し、一の顧客に関して複数の請求案件が取得されたときには前記複合判定プロセスを起動することを特徴とする集中業務処理システム。
【請求項５】 請求項３に記載の集中業務処理システムにおいて、前記複数の業務プロセスの各々は、対応する請求案件の処理を達成するための複数の処理ノードで構成されており、前記複合処理案件に対応する業務プロセスは、前記複数の処理ノードの終わりに次案件起動ノードを有し、前記業務フローシステムは、複合処理案件に対応する一の業務プロセスが前記次案件起動ノードに到達すると、複合処理案件に対応する次の業務プロセスを起動することを特徴とする集中業務処理システム。
【請求項６】 請求項５に記載の集中業務処理システムにおいて、前記複数の処理ノードは、顧客に対する電話確認ノードを含むことを特徴とする集中業務処理システム。
【請求項７】 請求項６に記載の集中業務処理システムにおいて、前記電話確認ノードでは、複合処理案件として現処理中の請求案件の後段で処理される請求案件の内容を確認でき、現処理中の請求案件と後段の請求案件の電話確認をまとめて行えることを特徴とする集中業務処理システム。
【請求項８】 請求項７に記載の集中業務処理システムにおいて、前記電話確認ノードでの電話確認が不成功のとき、電話確認ノードの処理を待機後に再び実行させることにより、前記現処理中の請求案件と後段の請求案件の電話確認を再び同時に実行させることを特徴とする集中業務処理システム。
【請求項９】 請求項１に記載の集中業務処理システムにおいて、一の顧客に関して複数の請求案件が取得されたときに、それら複数の請求案件が、同時に併行して処理されるべき同時処理案件に該当するか否かを判定する同時処理判定手段を含むことを特徴とする集中業務処理システム。
【請求項１０】 請求項９に記載の集中業務処理システムにおいて、前記同時処理判定手段は、前記業務プロセスと同様の形態の同時判定プロセスとして用意されており、前記プロセス起動手段は、一の顧客に関して複数の請求案件が取得されたときに前記同時判定プロセスを起動し、さらに前記同時判定プロセスの判定結果に従い、同時処理案件に対応する複数の業務プロセスを起動し、前記業務フローシステムは、それら業務プロセスの少なくとも一部の処理タイミングを同期させることを特徴とする集中業務処理システム。
【請求項１１】 請求項１０に記載の集中業務処理システムにおいて、前記プロセス起動手段は、一の顧客に関して一の請求案件が取得されたときにはその請求案件に対応する業務プロセスを直接的に起動し、一の顧客に関して複数の請求案件が取得されたときには前記同時判定プロセスを起動することを特徴とする集中業務処理システム。
【請求項１２】 請求項１０に記載の集中業務処理システムにおいて、前記複数の業務プロセスの各々は、対応する請求案件の処理を達成するための複数の処理ノードで構成されており、前記同時処理案件に対応する業務プロセスは、複数の処理ノードの中に同期処理ノードを有し、前記業務フローシステムは、同時処理案件に対応する複数の業務プロセスを併行して進行させるときに同期処理ノードの処理タイミングを同期させることを特徴とする集中業務処理システム。
【請求項１３】 請求項１２に記載の集中業務処理システムにおいて、前記同期処理ノードは、顧客に対する電話確認ノードを含むことを特徴とする集中業務処理システム。
【請求項１４】 請求項１３に記載の集中業務処理システムにおいて、前記電話確認ノードでの電話確認が不成功のとき、前記複数の業務プロセスにおける電話確認ノードの処理を再び同時に実行させることを特徴とする集中業務処理システム。
【請求項１５】 請求項１２に記載の集中業務処理システムにおいて、前記同期処理ノードは、顧客宛の手続処理結果の発送に関する処理ノードを含むことを特徴とする集中業務処理システム。
【請求項１６】 請求項１に記載の集中業務処理システムにおいて、一の顧客に関して複数の請求案件が取得されたときに、それら複数の請求案件が、一の請求案件の後に別の請求案件を処理すべき複合処理案件に該当するか否か、および、同時に併行して処理されるべき同時処理案件に該当するか否か、を判定する複合同時処理判定手段を含むことを特徴とする集中業務処理システム。
【請求項１７】 請求項１６に記載の集中業務処理システムにおいて、前記複合同時処理判定手段は、複数の請求案件の組合せを、同時処理案件、複合処理案件およびその他に仕分けするための複合同時判定テーブルを用いることを特徴とする集中業務処理システム。
【請求項１８】 請求項１６に記載の集中業務処理システムにおいて、前記複合同時処理判定手段は、前記業務プロセスと同様の形態の複合同時判定プロセスとして用意されており、前記プロセス起動手段は、一の顧客に関して複数の請求案件が取得されたときに前記複合判定プロセスを起動し、さらに前記プロセス起動手段は、前記複合同時判定プロセスの判定結果に基づいて、前記複数の請求案件が複合処理案件である場合には、それら請求案件に対応する複数の業務プロセスを、一の業務プロセスの終了後に次の業務プロセスが行なわれるように順次起動し、前記複数の請求案件が同時処理案件である場合には、それら請求案件に対応する複数の業務プロセスを併行処理されるように起動することを特徴とする集中業務処理システム。
【請求項１９】 請求項１８に記載の集中業務処理システムにおいて、前記プロセス起動手段は、一の顧客に関して一の請求案件が取得されたときにはその請求案件に対応する業務プロセスを直接的に起動し、一の顧客に関して複数の請求案件が取得されたときには前記複合同時判定プロセスを起動することを特徴とする集中業務処理システム。
【請求項２０】 多数の顧客と契約関係をもつ企業等に用いられ、契約変更等の業務手続を処理する集中業務処理装置であって、各種の請求案件にそれぞれ対応する複数の業務プロセス機能を備えており、顧客から業務手続の請求案件を受け付ける複数の拠点に配備された端末装置から、請求案件のデータが送信されてきたとき、受け取った請求案件に対応する業務プロセスに沿って請求案件の処理を進行させる業務フローシステムと、前記業務フローシステムとのインターフェース機能をもち、前記請求案件に対応する業務プロセス機能を前記業務フローシステムに起動させるプロセス起動手段と、を含むことを特徴とする集中業務処理装置。
【請求項２１】 多数の顧客と契約関係をもつ企業等に用いられ、契約変更等の業務手続を処理する集中業務処理方法であって、顧客から業務手続の請求案件を受け付ける複数の拠点に配備された端末装置から、請求案件のデータを収集するステップと、予め用意された各種の請求案件にそれぞれ対応する複数の業務プロセスの中から、顧客の請求案件に対応する業務プロセスを選択して起動するステップと、起動された業務プロセスに沿って請求案件の処理を進行させるステップと、を含むことを特徴とする集中業務処理方法。
【請求項２２】 コンピュータにて実行可能なプログラムを格納した記録媒体であって、前記プログラムは、多数の顧客と契約関係をもつ企業等において契約変更等の業務手続を処理するためのプログラムであり、前記プログラムは、顧客から業務手続の請求案件のデータが取得されたとき、予め用意された各種の請求案件にそれぞれ対応する複数の業務プロセスの中から、顧客の請求案件に対応する業務プロセスを選択して起動するステップと、起動された業務プロセスに沿って請求案件の処理を進行させるステップと、を前記コンピュータに実行せしめることを特徴とする、コンピュータにて読取可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図１２】
【図５】
【図６】
【図７】
【図１０】
【図８】
【図９】
【図１１】
【図１３】
【図１９】
【図２１】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２０】
【図２】
【図３】
【図４】
【図１２】
【図５】
【図６】
【図７】
【図１０】
【図８】
【図９】
【図１１】
【図１３】
【図１９】
【図２１】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２０】
【公開番号】特開２００２−４９７４５（Ｐ２００２−４９７４５Ａ）
【公開日】平成１４年２月１５日（２００２．２．１５）
【国際特許分類】
【出願番号】特願２０００−２３４６８３（Ｐ２０００−２３４６８３）
【出願日】平成１２年８月２日（２０００．８．２）
【出願人】（５０００６１３４９）住友生命保険相互会社 (2)
【Ｆターム（参考）】
【公開日】平成１４年２月１５日（２００２．２．１５）
【国際特許分類】
【出願日】平成１２年８月２日（２０００．８．２）
【出願人】（５０００６１３４９）住友生命保険相互会社 (2)
【Ｆターム（参考）】
[ Back to top ]