JP2017072975A - 保険基幹システム - Google Patents

Abstract

【課題】保険の基幹システムに関し、基幹業務の効率向上、サービス提供時間の拡大、契約成立に要する時間の短縮や手間の削減等を実現できる技術を提供する。【解決手段】保険基幹システムは、基幹業務に関する処理をオンライン処理として行うオンライン処理部を備え、オンライン処理部は、保険会社の業務員端末、顧客端末、連係システムから、基幹業務に関する情報または処理要求をオンラインで受け付けて受信する処理要求受付部と、情報または処理要求に応じた業務処理を実行する業務処理部と、業務処理で読み書きするＤＢデータと、を含み、業務処理部は、保険契約の申し込み情報を確認する申込確認部と、保険料払い込みの入金情報を確認する入金確認部と、確認の結果及び契約成立条件に基づいて、保険契約の成立を判定する条件判定部と、成立の場合、保険契約の計上処理を行う計上部と、を有する。【選択図】図２

Description

本発明は、情報処理サービス技術に関する。また、本発明は、保険の基幹システムに関する。

損保や生保等の保険に関するサービスを提供する情報処理システムとして、基幹システムがある。基幹システムは、保険会社の保険商品の販売や契約等の基幹業務を支援する。保険会社の業務員等は、基幹システムを使用し、保険契約者となる顧客との間で、契約管理等の業務を行う。例えば、業務員は、顧客から依頼を受け、保険の見積り、契約申し込み確認、保険料払い込み入金確認、取り付け書類確認等を行い、契約成立に伴い、証券を発行する。また、業務員は、保険金支払い、継続や異動の管理、事故管理、等を行う。ＩＴベンダ等の事業者は、基幹システムを開発及び運用する。保険会社と顧客との間のチャネルとしては、実店舗、Ｗｅｂ、電話等がある。基幹システムは、Ｗｅｂシステムやコールセンタシステムと連係する。

近年では、保険会社と顧客との間でインターネット及びＷｅｂを介して直接的に保険の販売及び契約等が可能であるダイレクト型の保険及びそのサービスが増加している。顧客は、顧客端末からＷｅｂ経由で基幹システムにアクセスし、顧客端末に表示されるＷｅｂページ画面を通じて保険契約申し込み等を行う。

保険の基幹システム及び契約処理に係わる先行技術例として、特開平７−２００６７４号公報（特許文献１）が挙げられる。特許文献１には、保険契約処理方法として、保険申込書から保険契約内容を取得し、保険加入の可否を判断し、可の場合には保険証券を出力する旨が記載されている。

特開平７−２００６７４号公報

保険会社は、サービス品質や顧客満足度の向上等のため、ダイレクト型の保険を含め、特徴的な様々な保険を開発及び提供する。保険会社は、各種の保険を顧客に販売する契約管理等を含む基幹業務を効率的に実現したい。即ち、効率的な基幹業務を実現できる基幹システムが求められている。

また、保険会社は、ダイレクト型の保険の場合を含め、顧客に対するサービス提供時間を拡大し、できれば２４時間のサービス継続稼動を実現したい。それが実現できれば、顧客は、常時にサービスを受けることができ便利であり、Ｗｅｂ等を通じて自分に合う保険を速やかに契約でき、事故等の場合にも速やかに補償を受けることができる。

顧客から保険会社への保険料の払い込み方法、及び対応する決済手段としては、クレジットカード、銀行、コンビニ等が挙げられる。顧客及び業務員としては、保険契約申し込み及び保険料払い込み等の手続きにおいて、少ない手間で速やかな契約を実現したい。また、速やかな契約ができれば、保険始期日、即ち補償が開始される日を早い日にすることができる。

しかし、従来の基幹システムは、システム設計として、バッチ処理方式を採用している。従来の基幹システムは、契約管理等の業務機能に係わる処理、例えば保険料払い込みの入金確認処理を、オンライン処理停止が必要な夜間バッチ処理等で行っている。例えば顧客が当日昼間に申し込み及び払い込み等をしたとしても、翌日以降の夜間バッチ処理で入金確認処理や計上処理等が行われる。よって、契約成立等は、少なくとも翌日以降になり、当日即時の契約は実現できない。

本発明の目的は、保険の基幹システムに関し、基幹業務の効率向上、サービス提供時間の拡大、契約成立に要する時間の短縮や手間の削減等を実現できる技術を提供することである。

本発明のうち代表的な実施の形態は、保険基幹システムであって、以下に示す構成を有することを特徴とする。

一実施の形態の保険基幹システムは、保険会社の保険商品の契約管理を含む基幹業務を支援する情報処理を行う保険基幹システムであって、前記基幹業務に関する処理をオンライン処理として行うオンライン処理部を備え、前記オンライン処理部は、前記保険会社の業務員端末、顧客端末、または連係システムから、前記基幹業務に関する情報または処理要求をオンラインで受け付けて受信する処理要求受付部と、前記情報または処理要求に応じた業務処理を実行する業務処理部と、前記業務処理で読み書きするＤＢデータと、を含み、前記業務処理部は、保険契約の申し込み情報を確認する申込確認部と、保険料払い込みの入金情報を確認する入金確認部と、前記申し込み情報及び入金情報の確認の結果、及び契約成立条件に基づいて、保険契約の成立を判定する条件判定部と、前記成立の場合、保険契約の計上処理を行う計上部と、を有する。

本発明のうち代表的な実施の形態によれば、保険の基幹システムに関し、基幹業務の効率向上、サービス提供時間の拡大、契約成立に要する時間の短縮や手間の削減等を実現できる。

本発明の一実施の形態の保険基幹システムを含む、保険システムの構成を示す図である。 本発明の一実施の形態の保険基幹システムの構成を示す図である。 一実施の形態における、日時管理情報の構成例を示す図である。 一実施の形態における、条件設定情報の構成例を示す図である。 一実施の形態における、基幹システムの画面例を示す図である。 一実施の形態における、業務処理フロー例を示す図である。 一実施の形態における、センターカット処理機能の構成を示す図である。 一実施の形態における、前処理機能の構成及び具体例を示す図である。 一実施の形態における、後処理機能の構成及び具体例を示す図である。 一実施の形態における、センターカット処理及び前処理を含む動作の具体例を時系列で示す図である。 一実施の形態における、センターカット処理及び後処理を含む動作の具体例を時系列で示す図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において同一部には原則として同一符号を付し、その繰り返しの説明は省略する。

図１〜図１１を用いて、本発明の一実施の形態の保険基幹システムについて説明する。本実施の形態の保険基幹システムは、適用例として、ダイレクト型の損害保険を含む保険を販売する保険会社の基幹システムとする。

［保険システム］
図１は、本実施の形態の保険基幹システム１を含む、保険システムの構成を示す。保険システムは、保険基幹システム１、保険会社の業務員端末２、顧客端末３、コールセンタの業務員端末４、決済システム５、他連係システム６を有する。これらの各システムや端末は、インターネット７や電話網８等の通信網に接続され、相互に通信可能である。

保険基幹システム１は、保険会社の基幹業務を支援する情報処理を行うシステムである。保険基幹システム１は、サーバ装置やＤＢ等のハードウェア及びソフトウェアを含む、サーバシステム等により構成される。ＩＴベンダ等の事業者は、保険基幹システム１を開発及び運用し、保険会社にサービスとして提供する。

業務員端末２は、保険会社の業務員が使用する端末である。保険会社の業務員は、業務員端末２から、インターネット５等の通信網を介して保険基幹システム１にアクセスし、利用する。業務員は、保険基幹システム１が提供するサービスを利用して、顧客との保険契約等に係わる業務を行う。業務員は、保険見積りから契約成立、継続や異動等の管理を含め、顧客単位の契約情報を管理する。保険会社は、業務員端末２の他にサーバ等を含む情報システムを有してもよい。なお、保険会社は、代理店等を含め、複数の会社や部署により構成される場合を含む。

顧客端末３は、保険契約者となる顧客が使用する端末である。顧客は、保険契約等の際、顧客端末３から、インターネット７等の通信網を介して、保険基幹システム１または保険会社の情報システムにアクセスする。あるいは、顧客は、顧客端末３から、電話網８を介して、コールセンタにアクセスする。また、顧客は、保険料払い込み等の決済の際には、決済システム５を利用する。顧客端末３が決済機能を備える場合には、顧客端末３から決済システム５や保険基幹システム１にアクセスしてもよい。

コールセンタの業務員端末４は、コールセンタシステムにおいて業務員が使用する端末である。コールセンタは、保険会社と連係する。業務員は、インバウンド業務の場合、電話網８を通じて顧客から電話を受け、問合せ等に応答する。業務員は、業務員端末４から、インターネット７等を介して保険基幹システム１にアクセスする。業務員は、業務員端末４の画面に表示される情報を見ながら、対象の顧客を特定し、契約等を特定し、その状態に応じて応答を行う。アウトバウンド業務の場合、業務員は、業務員端末４の画面を見ながら、対象の顧客及び契約等を特定し、顧客へ電話を行う。

業務員端末２、顧客端末３、業務員端末４の例としては、ＰＣやスマートフォンや専用端末等の各種の計算機が挙げられる。

保険会社と顧客との間におけるチャネルとして、Ｗｅｂチャネルや電話チャネルを含む。保険会社は、Ｗｅｂチャネルでは、インターネット７を介し、Ｗｅｂページ画面を含むサービスを提供する。保険会社は、電話チャネルでは、電話網８を介して、コールセンタによるサービスを提供する。ダイレクト型の保険の場合、顧客は、顧客端末３から、インターネット７及びＷｅｂを介し、保険基幹システム１に直接的にアクセスし、保険基幹システム１は、Ｗｅｂページ画面を含むサービスを提供する。顧客は、保険会社に、各チャネルを通じて、保険見積り、契約申し込み、保険料払い込み、継続や異動の連絡、事故連絡等を行う。それに対し、保険会社は、顧客に、各チャネルを通じて、応答を行う。

決済システム５は、決済サービスを提供するシステムであり、保険会社及び保険基幹システム１と連係する。顧客と保険会社との間で、保険料の払い込み方法に対応した決済手段として、クレジットカード、銀行、コンビニ等が挙げられる。決済システム５は、クレジットカード会社のシステム、銀行のシステム、コンビニのシステム等が挙げられる。

決済システム５は、例えば顧客からの保険料払い込みを受け付ける。決済システム５は、決済処理として、顧客の口座から保険料払い込みの金額を出金し、保険会社の口座に保険料払い込みの金額を入金する。決済システム５は、その入金情報を含む決済情報を、保険基幹システム１に送信する。また、決済システム５は、例えば保険会社からの保険金支払いを受け付ける。決済システム５は、決済処理として、保険会社の口座から保険金支払いの金額を出金し、顧客の口座に保険金支払いの金額を入金する。決済システム５は、その出金情報を含む決済情報を、保険基幹システム１に送信する。

他連係システム６は、保険契約に係わる書類の発行や作成を行うシステム等が挙げられる。例えば、ある自動車損保の契約の場合、取り付け書類として、車検証コピー等が必要とされる。例えば軽自動車の新規申し込みや中断証明の利用時にも、所定の取り付け書類が必要とされる。また、ある生保の契約の場合、保険証コピー等が必要とされる。他連係システム６として、取り付け書類またはそのデータを扱うシステムがある。

また、他連係システム６は、保険契約に係わる所定の審査を行うシステムが挙げられる。例えば、ある保険の契約の場合、契約者となる顧客について、所定の審査が必要であり、その審査結果として所定の基準を満たすことが必要である。他連係システム６として、所定の審査を行い、その審査結果の書類またはそのデータを扱うシステムがある。

保険基幹システム１は、Ｗｅｂサーバ部１１０、業務機能部１２０、ＤＢ部１３０を有する。また、Ｗｅｂサーバ部１１０、業務機能部１２０、ＤＢ部１３０の上に、オンライン処理部１０が構成されている。オンライン処理部１０は、センターカットＤＢ１４０等を管理する。

Ｗｅｂサーバ部１１０は、画面提供部１１１を含む要求受信部である。Ｗｅｂサーバ部１１０は、インターネット７等を通じて、保険会社の業務員端末２、顧客端末３、コールセンタの業務員端末４、決済システム５、他連携システム６から、基幹業務の処理要求に関するアクセスを受け付ける。Ｗｅｂサーバ部１１０は、複数のチャネルやシステムを含めてアクセスを統合的に受け付けて、アクセスに関するトランザクションを制御する。

なお、保険基幹システム１は、Ｗｅｂサーバ部１１０の前段に、アクセスを統合的に受け付けてトランザクションを制御する中継部を設け、Ｗｅｂサーバ部１１０と連係する構成でもよい。

画面提供部１１１は、業務メニュー項目を表示する画面等を提供する。画面提供部１１１は、アクセス元の保険会社や顧客に応じた画面を提供する。画面提供部１１１は、保険会社の業務員端末２からのアクセスを受けた場合、その保険会社の基幹業務に対応した画面を構成するためのＷｅｂページを送信する。業務員端末２は、受信したＷｅｂページにより画面を表示する。画面提供部１１１は、顧客端末３からのアクセスを受けた場合、その顧客端末３に対応した画面を構成するためのＷｅｂページを送信する。画面提供部１１１は、業務員端末４からのアクセスを受けた場合、そのコールセンタの業務に対応した画面を構成するためのＷｅｂページを送信する。

業務機能部１２０は、保険会社の基幹業務における契約管理、決済管理、事故管理等を含む、各種の業務に対応した業務機能を提供し、業務機能毎の処理を実行する。業務機能部１２０は、Ｗｅｂサーバ部１１０を通じて受信した処理要求に応じて、ＤＢ部１３０のＤＢデータを読み書きしながら、業務機能毎の処理を実行する。業務機能部１２０は、複数のアプリケーションサーバ等で構成される。業務機能部１２０は、プロセッサによるプログラム処理により業務機能を実現する。

各業務機能は、他の１つ以上の業務機能を呼び出して処理を行わせることができる。業務機能は、呼び出し元からの処理要求に基づいて、所定の情報を入力し、所定の処理を行い、処理結果情報を出力し、呼び出し元へ応答する。

業務機能部１２０は、トランザクション制御機能を持ち、業務機能毎の処理をトランザクション処理として行う。全ての業務機能は、初期処理として、業務機能の排他制御論理が実装されている。業務機能部１２０は、例えば顧客情報を更新する第１の業務機能の第１のトランザクション処理を実行する際には、顧客情報を更新する他の第２の業務機能の第２のトランザクション処理を保留させる。トランザクション制御機能により、ＤＢデータの整合性が確保され、複数のチャネルに対応可能である。

ＤＢ部１３０は、ストレージやＤＢサーバ等により構成され、基幹業務に係わる各種のＤＢデータを管理する。ＤＢデータは、後述のセンターカット処理機能を含むシステム設計に対応させたデータ構造を有する。ＤＢ部１３０は、管理するＤＢデータとして、顧客情報１３１、契約情報１３２、見積申込情報１３３、証券データ１３４、決済情報１３５、事故情報１３６、フォロー情報１３７、等がある。

［ＤＢデータ例］
ＤＢ部１３０のＤＢデータの内容例は以下である。図１の顧客情報１３１は、顧客単位の情報として、氏名、住所、電話番号、等がある。契約情報１３２は、顧客単位の保険契約情報であり、保険種目、保険会社ＩＤ、保険ＩＤ、保険期間、払い込み方法、等がある。保険種目は、自動車、火災、傷害、賠償責任、等がある。見積申込情報１３３は、顧客単位の保険の見積り及び契約申し込み等に関する管理情報である。

自動車損保の場合に、契約情報１３２や見積申込情報１３３に持つ項目の例としては、証券番号、契約者氏名、契約者住所、契約者電話番号、保険会社ＩＤ、代理店コード、保険種目、保険ＩＤ、契約日、保険始期日、保険期間、払い込み方法、被保険者、車両、型式、用途車種、車両所有者、走行距離、車両保険種類、保険料、保険金額、免責金額、特約条項、割引、事故履歴、等がある。

証券データ１３４は、保険証券等を印刷出力するための管理データである。決済情報１３５は、保険料の入金情報、保険金の出金情報、等の決済に関する管理情報である。事故情報１３６は、顧客単位の自動車事故等に関する管理情報である。フォロー情報１３７は、顧客及び業務員へのフォローのための管理情報である。ＤＢデータとしては、その他、商品マスタ、住所マスタ、コンタクト情報、等がある。

［業務］
保険基幹システム１において適用可能である基幹業務として、契約管理、決済管理、事故管理、帳票管理、等の業務を含む。本実施の形態では主に契約管理業務の場合で説明するが、他の業務についても同様に適用可能である。以下、業務の例を説明する。

契約管理は、顧客情報管理、契約情報管理、コンタクト管理等を含む。契約管理は、資料請求、保険見積り、契約申し込み、保険料払い込み入金確認、取り付け書類確認、審査結果確認、継続や異動の管理を含む。契約管理は、保険に応じた保険対象や補償内容の確認を含む。決済管理は、保険料の払い込みの請求、入金及び収納の管理、保険金の出金の管理を含む。決済管理は、クレジットカード、銀行、コンビニ等の各決済手段に連係する管理を含む。事故管理は、事故連絡受け付け、事故情報登録等の管理を含む。

顧客と保険会社の業務員との間における保険契約の手続き、及びそれに対応する契約管理業務の例について、概略的なワークフローを以下に示す。

（１）顧客は、保険会社の業務員にコンタクトし、資料の請求や相談を行う。業務員は、顧客に資料を提供し、保険商品等を説明する。（２）顧客は、保険の見積りを依頼する。業務員は、保険の見積りを作成する。顧客は、見積りの内容を確認する。ダイレクト型の保険の場合、Ｗｅｂページ画面で、保険見積りに必要な情報が入力される。

（３）顧客は、見積りの内容に基づいて、保険契約申し込みを行う。業務員は、申し込み意思等を確認する。業務員は、保険契約申し込み書を作成する。顧客は、保険契約申し込み書の必要項目に記載し、署名等を行う。ダイレクト型の保険の場合、Ｗｅｂページ画面で、保険契約申し込み情報が入力される。（４）また、顧客は、保険契約申し込みに伴い、保険料の払い込みを行う。例えば、顧客は、銀行等の決済手段を用いて、初年度の保険料の払い込みを行う。

（５）業務員は、保険契約申し込み書の内容を確認する。業務員は、各項目の記載が正しいかチェックする。また、業務員は、所定の取り付け書類が揃っているかチェックする。また、業務員は、所定の審査で基準を満たしているか等をチェックする。（６）また、業務員は、顧客から決済手段を通じて払い込まれた保険料の入金を確認し収納する。業務員は、正しい入金がされたかチェックする。

（７）業務員は、（５）や（６）のチェック結果に基づいて、規定の条件を満たす場合、保険契約を成立させる。規定の条件は、正しい申し込み情報、正しい保険料の入金等である。業務員は、保険契約申し込み書に基づいて、顧客毎の顧客情報や契約情報をＤＢに登録する。その後、業務員は、保険証券等を作成し、契約者へ送付する。また、業務員は、保険料に関する月次等の計上情報を作成する。

コールセンタ経由で自動車損保の見積り及び申し込みを行う場合のワークフローは以下である。（１）業務員は、顧客から入電を受ける。業務員は、顧客情報を確認し、顧客情報から契約情報を確認する。（２）業務員は、見積りに必要な事項の情報の入力や確認を行う。業務員は、例えば車両情報を検索して確認する。（３）業務員は、必要な事項の情報に基づいて、保険料を含む見積りを作成する。（４）業務員は、見積り結果を顧客へ応答し、その情報を保存する。（５）見積り結果に同意の場合、申し込みへ移る。業務員は、申し込みに必要な事項の情報の入力や確認を行い、それらの情報を登録する。（６）続いて、保険料払い込みの手続きを行う場合、業務員は、払い込み方法等、払い込みに必要な事項の情報を入力または確認し、払い込み先の情報を顧客へ通知する。（７）業務員は、コンタクト情報を登録して終了する。

［保険基幹システム］
図２は、本実施の形態の保険基幹システム１を中心としたシステム構成を示す。保険基幹システム１、顧客端末３、及び業務員端末２等の各部は、連係システム９を介して相互に接続される。連係システム９は、図１の各チャネル、コールセンタ、決済システム５、他連係システム６を含む部分をまとめて示す。図２では、ダイレクト型の損保の場合に対応して顧客端末３から保険基幹システム１に直接的にアクセスする例を示す。これに限らず、顧客からの依頼に基づいて保険会社の業務員端末２から保険基幹システム１にアクセスする場合も同様である。

オンライン処理部１０は、センターカット処理部１１、前処理部１２、後処理部１３、処理要求受付部２０、確認部３０、契約成立条件判定部４０、保険契約計上部５０、証券作成部６０、フォロー部７０、日時管理部８０、設定部９０を有する。

オンライン処理部１０は、従来の基幹システムのオンライン処理停止が必要なバッチ処理を排除して、２４時間のサービス継続稼動のオンライン処理を実現する処理部である。業務機能部１２０の各業務機能は、必要に応じて、センターカット処理部１１、前処理部１２、及び後処理部１３の処理を呼び出す。

処理要求受付部２０は、外部の顧客端末３や業務員端末２や連係システム９から、あるいはオンライン処理部１０の内部から、各種の処理要求や情報を受け付けて受信する。処理要求受付部２０は、業務機能毎の受付部を含む。図２の例では、処理要求受付部２０は、契約申込受付部２１、保険料払込入金受付部２２、取付書類受付部２３を含む。

契約申込受付部２１は、顧客端末３や業務員端末２から、保険契約申し込み情報またはそれに対応した処理要求２０１を受信する。例えば、顧客は、顧客端末３の保険契約申し込み用のＷｅｂページ画面で、保険契約申し込み情報を入力する。契約申込受付部２１は、その保険契約申し込み情報を受信する。

保険料払込入金受付部２２は、顧客から決済システム５を介して保険料の払い込みが行われる場合に対応する、入金情報を含む決済情報、またはそれに対応する処理要求２０２を受信する。保険料払込入金受付部２２は、例えばオンライン処理部１０の内部から、入金確認処理のための処理要求を受信する。また、保険料払込入金受付部２２は、外部の決済システム５から、払い込みに対応した入金情報を受信する。入金情報は、払い込み元、払い込み先、払い込み日時、入金金額、等の情報を含む。

取付書類受付部２３は、保険契約に係わる取り付け書類に関するデータ、またはそれに対応する処理要求２０３を受信する。例えば顧客は、顧客端末３から取り付け書類のデータを入力し、保険基幹システム１へ送信する。あるいは、顧客は、取り付け書類を保険会社へ郵送し、業務員は、業務員端末２から取り付け書類のデータを入力し、保険基幹システム１へ送信する。あるいは、連係システム９は、顧客からの依頼に基づいて、取り付け書類を保険会社へ郵送するか、取り付け書類のデータを保険基幹システム１へ送信する。

図示しないが、処理要求受付部２０に審査結果受付部を有する。審査結果受付部は、保険契約に係わる審査がある場合の処理を行う。連係システム９は、審査結果の書類を、保険会社へ郵送する。業務員は、業務員端末２から審査結果情報を入力し、保険基幹システム１へ送信する。あるいは、連係システム９は、審査結果情報を保険基幹システム１へ送信する。審査結果受付部は、審査結果情報またはそれに対応する処理要求を受信する。

確認部３０は、処理要求受付部２０で受け付けた処理要求に応じた確認処理を行い、確認結果情報を、契約成立条件判定部４０やフォロー部７０へ出力する。確認部３０は、業務機能毎の処理部を含む。図２の例では、確認部３０は、契約申込確認部３１、入金確認部３２、取付書類確認部３３を含む。

契約申込確認部３１は、契約申込受付部２１からの保険契約申し込み情報や処理要求に基づいて、保険契約申し込み情報の確認処理を行う。契約申込確認部３１は、保険契約申し込み情報について、保険毎に記載が必要な項目の有無等を確認し、必要な項目毎に、記載の正誤等、不備が無いかチェックする。契約申込確認部３１は、確認の結果、保険契約申し込み情報の正しさを確認した場合には、そのことを示す情報（ＯＫ）を出力し、正しさを確認できない場合、不備がある場合には、そのことを示す情報（ＮＧ）や不備の詳細情報を出力する。契約申込確認部３１は、契約申込確認結果を、ＤＢ部１３０の見積申込情報１３３に格納する。

入金確認部３２は、保険料払込入金受付部２２からの入金情報や処理要求に基づいて、保険料払い込み入金の確認処理を行う。入金確認部３２は、入金情報について、所定の期日までに入金されているか否か、及び入金金額が正しいか等を確認し、入金の忘れや誤り等の不備が無いかチェックする。入金確認部３２は、所定の期日までに正しい金額が入金されていことを確認した場合には、それを示す情報（ＯＫ）を出力し、そうでない場合には、それを示す情報（ＮＧ）や不備の詳細情報を出力する。入金確認部３２は、契約申し込み時に登録された保険料の金額と、入金情報で示す実際に入金された金額とをマッチングし、合致するかを判断し、合致しない場合には、過不足、差額等を判断する。入金確認部３２は、入金確認結果を、ＤＢ部１３０の決済情報１３５に格納する。

取付書類確認部３３は、取付書類受付部２３からの取付書類データや処理要求に基づいて、取り付け書類の確認処理を行う。取付書類確認部３３は、保険に応じて必要とされる取り付け書類の有無、及び取り付け書類の内容を確認し、必要な全ての取り付け書類が正しい内容で揃っているかチェックする。取付書類確認部３３は、必要な取り付け書類が全て揃っていることを確認した場合には、それを示す情報（ＯＫ）を出力し、そうでない場合には、それを示す情報（ＮＧ）や不備の詳細情報を出力する。取付書類確認部３３は、取付書類確認結果を、ＤＢ部１３０の見積申込情報１３３に格納する。

図示しないが、確認部３０に審査結果受付部を有する。審査結果受付部は、審査結果受付部からの審査結果情報や処理要求に基づいて、審査結果の確認処理を行う。審査結果確認部は、保険に応じた審査の有無、審査結果で所定の基準を満たしているか等を確認する。審査結果確認部は、審査がある場合の審査結果で所定の基準を満たしていることを確認した場合には、それを示す情報（ＯＫ）を出力し、そうでない場合には、それを示す情報（ＮＧ）や不備の詳細情報を出力する。審査結果確認部は、審査結果確認結果を、ＤＢ部１３０の見積申込情報１３３に格納する。

契約成立条件判定部４０は、処理要求に応じた確認部３０での確認結果情報を入力し、確認結果情報及び条件設定情報９１に基づいて、保険契約の成立に係わる条件を確認及び判定する。契約成立条件判定部４０は、条件設定情報９１で示す保険契約条件に従い、確認結果情報で示す結果（ＯＫ／ＮＧ）を確認する。保険契約条件は、保険会社の保険商品に応じて、どのような条件を満たす場合に契約を成立させるかについての定義情報である。契約成立条件判定部４０は、当該確認結果が条件を満たす場合、それを示す情報（ＯＫ）を判定結果として出力し、満たさない場合には、それを示す情報（ＮＧ）を判定結果として出力する。契約成立条件判定部４０は、判定結果情報を、保険契約計上部５０、証券作成部６０、フォロー部７０等へ出力する。

保険契約計上部５０は、契約成立条件判定部４０の判定結果情報に基づいて、顧客との保険契約を成立させ、成立に応じて計上する処理を行う。保険契約計上部５０は、判定結果情報が、保険に応じた条件を満たす結果（ＯＫ）である場合、当該保険契約を成立させる。保険契約計上部４０は、成立の場合、ＤＢ部１３０の契約情報１３３に、当該顧客及び保険に関する契約情報を格納する。なお、契約成立条件判定部４０と保険契約計上部５０とが１つに統合されてもよい。

保険契約計上部５０は、始期日設定部５１を含む。始期日設定部５１は、保険契約成立の際、日時管理情報８１及び条件設定情報９１に基づいて、保険始期日を設定する。日時管理情報８１は、申込確認日時、入金確認日時、等の各種の日時情報を含む。条件設定情報９１は、始期日条件を含む。始期日条件は、保険会社の保険商品に応じて、どのような論理や日時に基づいて保険始期日を決定するかについての定義情報である。始期日設定部５１は、決定した保険始期日を、日時管理情報８１や契約情報１３２に格納する。

証券作成部６０は、保険契約成立に伴い、保険証券の印刷のための証券データを作成し、ＤＢ部１３０の証券データ１３４に格納する。

フォロー部５０は、確認部３０の確認結果情報や、契約成立条件判定部４０の判定結果情報を入力し、自動的に連係してフォロー処理を行う。フォロー処理は、顧客や業務員に対し、催促や督促を含むフォローを、各種の手段を用いて行う処理である。フォローの各種の手段は、メール、電話、Ｗｅｂ、帳票、等を含む。フォロー部５０は、確認結果情報や判定結果情報がＮＧである場合、即ち、保険契約申し込み情報や入金や取り付け書類に不備がある場合等に、不備の詳細に応じたフォロー処理を実行する。フォロー処理は、フォロー処理の内容の定義情報に基づいて行われる。

フォロー部５０は、フォロー処理において、フォロー情報２０４を、顧客端末３、または保険会社の業務員の業務員端末２やコールセンタの業務員の業務員端末４へ、所定の手段で送信する。フォロー部５０は、例えば、保険契約申し込み情報や入金や取り付け書類に不備がある場合、顧客端末３へ、不備の解消のための催促を含むフォロー情報２０４を送信する。あるいは、フォロー部５０は、業務員端末２へ、指示を含むフォロー情報２０４を送信する。業務員は、指示に従い、顧客へ、所定の手段で、催促を含むフォローを行う。顧客または業務員は、フォローに従い、不備の解消を行う。

フォローの例は、保険契約申し込み情報の記載の漏れや誤りの項目に関する修正の催促、保険料払い込みが期日までに未入金の場合の入金催促、入金金額が誤りで金額不足の場合の差額追加入金催促、必要な取り付け書類が期日までに未受領の場合の催促等がある。

フォロー処理の例として、入金確認部３２から確認結果情報として未入金あるいは入金金額誤りの旨の情報（ＮＧ）が出力された場合、フォロー部７０は、催促の指示を含むフォロー情報２０４を、例えばコールセンタの業務員の業務員端末４へ送信する。業務員端末４の画面には、フォロー情報２０４の内容として、催促の指示、対象の顧客の状態、電話番号、日時管理情報８１の内容、等が表示される。業務員は、フォロー情報２０４に従い、顧客に電話し、正しい入金を催促する作業を行い、その結果を画面で登録する。

フォロー部７０は、保険会社やコールセンタの業務員へのフォロー情報２０４を含むＷｅｂページ画面を提供する。業務員は、その画面で、フォロー情報２０４の内容を確認しながら、フォロー作業を効率的に行うことができる。フォロー部７０は、フォロー情報２０４や、画面で登録されたフォロー結果等を、ＤＢ部１３０のフォロー情報１３７に格納する。

日時管理部８０は、日時管理情報８１を管理する。日時管理部８０は、センターカット処理部１１、前処理部１２、後処理部１３等と連携し、所定の業務機能の処理が実行された日時や、顧客や業務員が所定の動作をした日時を、年月日時分秒単位で、日時管理情報８１に記録する。

日時管理部８０は、日時管理情報８１の内容を含むＷｅｂページ画面を提供する。顧客または業務員は、端末の画面で、日時管理情報８１の内容である各種の日時を参照可能である。

設定部９０は、保険基幹システム１の管理者の操作に基づいて、条件設定情報９１を含む設定情報を設定する。条件設定情報９１は、後述の図４、図６の契約成立条件及び始期日条件を含む。契約成立条件は、契約成立条件判定部３０での条件判定処理の際に用いられる。始期日条件は、始期日設定部５１での始期日設定処理の際に用いられる。業務機能は、対象の保険会社の保険商品に応じて、条件設定情報９１の設定を適用する。管理者は、予め、設定部９０を用いて条件設定情報９１等の設定情報を設定する。

管理者は、端末から設定部９０にアクセスする。設定部９０は、設定用のＷｅｂページを提供する。管理者の端末は、そのＷｅｂページによる設定用の画面を表示する。この画面は、条件設定情報９１の内容を表示する。管理者は、画面で、条件設定情報９１の確認や設定の作業が可能である。管理者は、例えば保険会社からの依頼に基づいて、保険商品の追加や変更等に応じて、条件設定情報９１の内容を設定する。

［日時管理情報］
図３は、日時管理情報８１の構成例を示す。図３の日時管理情報８１の表は、列として、顧客ＩＤ、保険ＩＤ、状態、日時を有する。「顧客ＩＤ」は、顧客の識別情報である。「保険ＩＤ」は、保険商品の識別情報である。「状態」は、当該顧客及び保険に係わる状態を示す値であり、「日時」の記録に応じて定まる値であり、例えば「契約済み」、「未契約、入金待ち」等である。「日時」は、各動作に対応して記録される日時であり、年月日時分秒単位の日時である。本例では、日時として、（ａ）「契約申込日時」、（ｂ）「申込確認日時」、（ｃ）「保険料払込日時」、（ｄ）「入金確認日時」、（ｅ）「取付書類受領日時」、（ｆ）「取付書類確認日時」、（ｇ）「契約成立日時」、（ｆ）「保険始期日日時」、等がある。

日時管理部８０は、顧客からの保険契約申し込み情報を契約申込受付部２１で受信した日時を、（ａ）の「契約申込日時」として記録する。日時管理部８０は、当該保険契約申し込み情報の正しさを契約申込確認部３１で確認した日時を、（ｂ）の「申込確認日時」として記録する。日時管理部８０は、保険料払込入金受付部２２で受信した入金情報等に基づいて、顧客からの保険料払い込みに対応した日時を、（ｃ）の「保険料払込日時」として記録する。日時管理部８０は、当該入金の正しさを入金確認部３２で確認した日時を、（ｄ）の入金確認日時として記録する。日時管理部８０は、取付書類受付部２３での受信に基づいて、顧客からの取り付け書類を受領した日時を、（ｅ）の「取付書類受領日時」として記録する。日時管理部８０は、取り付け書類の正しさを取付書類確認部３３で確認した日時を、（ｆ）の「取付書類確認日時」として記録する。

日時管理部８０は、契約成立条件判定部３０で契約成立と判定した日時を、（ｇ）の「契約成立日時」として記録する。日時管理部８０は、始期日設定部５１で設定した保険始期日の日時を、（ｆ）の「保険始期日日時」として記録する。

［条件設定情報］
図４は、条件設定情報９１の構成例を示す。図４の条件設定情報９１の表は、列として、保険ＩＤ、契約成立条件、始期日条件を有する。条件設定情報９１は、保険会社の保険商品毎に、契約成立条件、始期日条件が設定されている。「契約成立条件」列は、保険ＩＤで示す保険商品についての、契約成立のために必要な条件の定義情報が設定されている。この定義情報は、保険契約申し込み情報の条件、保険料払い込み入金の条件、取り付け書類の条件、審査結果の条件、等を含む。「始期日条件」列は、保険ＩＤで示す保険商品についての、保険始期日を設定する際に適用する定義情報が設定されている。この定義情報は、保険始期日を決定する際の基準となる日時や、日時の管理単位を含む。

本例では、第１行の保険Ｘ１は、契約成立の条件Ｊ１として、保険契約申し込み情報の条件、保険料払い込み入金の条件を含む。この条件Ｊ１は、取り付け書類の条件としては取り付け書類が無いことを含み、審査結果の条件としては審査が無いことを含む。即ち、保険Ｘ１については、条件Ｊ１として、保険契約申し込み情報と入金との２つの要素について正しさが確認された場合に契約成立となる。契約成立条件判定部３０は、契約申込確認部３１及び入金確認部３２からの確認結果情報に基づいて、条件Ｊ１を満たすか判定し、条件Ｊ１を満たす場合、契約成立と判定する。日時管理部８０は、契約成立条件判定部３０で条件Ｊ１を満たした日時を図３の（ｇ）の「契約成立日時」として記録する。

また、第１行の保険Ｘ１は、始期日条件として、「条件Ｊ１を満たした日時、日単位」である。これは従来通りに１日単位で設定する例である。始期日設定部５１は、始期日条件に従い、条件Ｊ１を満たした「契約成立日時」を用いて、日単位で、即ち時分秒を切り落として年月日の部分を用いて、保険始期日を決定する。日時管理部８０は、始期日設定部５１で決定した保険始期日を、図３の（ｈ）の「保険始期日日時」に記録する。

第２行の保険Ｘ２は、同様に、契約成立の条件Ｊ２が設定されている。この条件Ｊ２は、取り付け書類の条件として、取り付け書類が有ること、及びその取り付け書類の情報を含む。即ち、保険Ｘ２については、条件Ｊ２として、保険契約申し込み情報と入金と取り付け書類との３つの要素について正しさが確認された場合に契約成立となる。始期日条件としては、「条件Ｊ２を満たした日時、時分単位」である。始期日設定部５１は、始期日条件に従い、条件Ｊ２を満たした「契約成立日時」を用いて、時分単位で、即ち秒のみを切り落として年月日時分の部分を用いて、保険始期日を決定する。

業務員は、保険基幹システム１により設定された保険始期日を画面で確認し、問題が無ければ確定し、問題があれば修正することができる。

契約成立条件や始期日条件は、上記例に限らず、他の設定も可能である。例えば、契約成立条件として、審査結果が有る場合の条件を含む場合には、４つの要素について正しさが確認された場合に契約成立となる。例えば、始期日条件として、「入金が確認された日時」等も設定可能である。

保険始期日について、従来よりも詳細に、「保険始期日日時」として、時分秒単位で情報管理し、時分秒単位で設定可能である。保険商品の設計として、時分秒単位の保険始期日を持たせることが可能である。また、本実施の形態の保険基幹システム１では、各種の日時を時分秒単位で情報管理し画面で確認可能とすることにより、基幹業務の効率を向上できる。

［画面例］
図５は、保険基幹システム１がユーザに提供する画面例を示す。本例では、自動車損保の場合で、ユーザが保険会社の業務員であり、契約管理に係わる画面例を示す。図５は、（Ａ）〜（Ｅ）の画面を有する。

（Ａ）の画面は、上位階層で表示される業務メニュー項目画面である。この画面は、契約管理等の業務のメニュー項目を含む。業務メニュー項目の例として、「資料請求」、「見積・申込」、「継続」、「異動」、「契約照会」、「入金」、「解約」、「フォロー」、「顧客管理」等がある。業務員は、顧客との保険契約申し込みの手続きの際に、顧客の保険の見積りや契約申し込みを行う場合、（Ａ）の画面で、「見積・申込」項目を選択する。これにより、（Ｂ）の「見積・申込」項目画面へ移る。画面の項目毎に、業務機能の処理や項目画面が関係付けられている。

（Ｂ）の「見積・申込」項目画面で、「見積・申込」業務を構成する複数の項目がフローで表示される。（Ｂ）の例では、項目として、「顧客登録」、「見積り（見積り作成）」、「申込確認」、「入金確認」、「取付書類確認」、「審査結果確認」等がある。業務員は、顧客の保険の契約申し込みを行う場合、（Ｂ）の画面で「申込確認」項目を選択する。これにより、（Ｃ）の「申込確認」項目画面へ移る。また、業務員は、顧客の保険料払い込み入金確認を行う場合、（Ｂ）の画面で「入金確認」項目を選択する。これにより、（Ｄ）の「入金確認」項目画面へ移る。

（Ｃ）の「申込確認」項目画面で、「申込確認」業務を構成する複数の項目がフローで表示される。（Ｃ）の例では、項目として、「保険契約申し込み情報確認」等がある。業務員は、保険契約申し込み情報の入力やその内容の確認を行う場合、（Ｃ）の画面で「保険契約申し込み情報確認」項目を選択する。

（Ｄ）の「入金確認」項目画面で、「入金確認」業務を構成する複数の項目がフローで表示される。（Ｄ）の例では、項目として、「保険料払込入金情報確認」等がある。業務員は、保険料払い込み入金情報の確認を行う場合、（Ｃ）の画面で「保険料払込入金情報確認」項目を選択する。これにより、（Ｅ）の画面へ移る。

（Ｅ）の「保険料払込入金確認」項目画面は、入金確認の作業のために詳細情報を表示する例を示す。この画面は、詳細情報として、図３の日時管理情報８１に基づいて作成された情報を表示する。この詳細情報は、顧客ＩＤ、保険ＩＤ、状態、フラグ、動作及び日時等を含む。「フラグ」列は、「動作及び日時」列の動作が済んでいるか否かのフラグを示す。業務員は、画面で詳細情報を見て、顧客の状態や、各動作の日時を確認できるので、業務を効率的に行うことができる。本例では、顧客Ｕ２は、保険Ｘ２に関して、契約申し込みは済んでいるが、保険料払い込みの入金は未だ行われていない状態であり、「状態」列は「未契約、入金待ち」である。

また、（Ｅ）の画面には、顧客の状態に対応させて、「フォロー」ボタンが表示される。例えば顧客Ｕ２の「状態」が「未契約、入金待ち」であることに対応して、「フォロー（入金催促）」ボタンが表示される。業務員は、このボタンの操作により、入金催促のフォローを、顧客Ｕ２に対して速やかに行うことができる。この際、フォロー部５０はフォロー処理を行う。

［業務処理フロー例］
図６は、図２の保険基幹システム１のオンライン処理部１０における業務処理フロー例を示す。ある保険会社Ａの保険Ｘ２に関する顧客との保険契約の際の業務処理の場合で、オンライン即時処理とセンターカット処理を含む場合を示す。なお、以下、オンライン即時処理を、即時処理ともいう。

顧客の動作の発生順序の例として、（１）契約申し込み、（２）保険料払い込み入金、（３）取り付け書類送付、である。上記顧客の動作に対応した、処理要求の発生順序の例として、（１）申込処理要求６０１、（２）入金処理要求６０２、（３）取付書類処理要求６０３、である。

上記（１）で、顧客は、保険Ｘ２に関する契約申し込みを行う場合、例えば顧客端末３の画面で保険契約申し込み情報を入力する。あるいは、業務員は、顧客へ保険契約申し込み書類を郵送し、顧客からの保険契約申し込み書類に応じて、業務員端末２の画面で保険契約申し込み情報を入力する。顧客端末３または業務員端末２は、保険契約申し込み情報及びそれに対応する申込処理要求６０１を保険基幹システム１に送信する。申し込みの際には、顧客が選択した払い込み方法等が保険契約申し込み情報の一部として登録される。また、申し込みの際には、保険会社から顧客へ、払い込み先情報が発行される。例えば銀行振り込みの場合、振り込み先の口座情報が通知される。例えばコンビニ払いの場合、一意の番号やＩＤを含む払込票が発行される。また、申し込みの際には、保険会社から顧客へ、必要な取り付け書類等が通知される。

上記（２）で、顧客は、保険Ｘ２に関する保険料払い込みを行う場合、申し込み時に登録した払い込み方法に対応した決済手段を通じて払い込みを行う。払い込みを受けた決済システム５は、入金情報を含む決済情報及びそれに対応した入金処理要求６０２を、保険基幹システム１に送信する。払い込みの保険料は、契約時の年払いの初年保険料や、契約継続時の保険料である。

決済手段がクレジットカード払いの場合には以下である。顧客は、クレジットカードで決済を行う。クレジットカード会社のシステムは、決済処理を行い、決済情報を保険基幹システム１へ送信する。

決済手段が銀行振り込みの場合には以下である。顧客は、銀行やＡＴＭで保険料を振り込む。銀行のシステムは、決済処理を行い、決済情報を保険基幹システム１へ送信する。

決済手段がコンビニ払いの場合には以下である。顧客は、払込票を用いて、コンビニで保険料の払い込みを行う。払込票に記載の番号等に基づいて、コンビニのシステムは、銀行等のシステムに連携し、決済処理が行われる。銀行等のシステムは、その決済情報を保険基幹システム１へ送信する。

上記（３）で、顧客は、保険Ｘ２に関する取り付け書類を送付する場合、例えば取り付け書類を保険会社へ郵送する。保険会社の業務員は、顧客からの取り付け書類に基づいて、業務員端末２で、取り付け書類データを入力する。業務員端末２は、取り付け書類データ及びそれに対応する取付書類処理要求６０３を保険基幹システム１へ送信する。

図６は、ステップＳ１〜Ｓ１３で示す処理や動作を有する。以下、ステップＳ１〜Ｓ１３について順に説明する。

（Ｓ１，Ｓ２，Ｓ３） まず、Ｓ１で、処理要求受付部２０における契約申込受付部２１は、申込処理要求６０１を受け付けて受信する契約申込受付処理を行う。契約申込受付部２１は、申込処理要求６０１に対応した契約申込処理を、例えば即時処理対象とする。Ｓ２で、契約申込受付部２１は、契約申込確認部３１へ、契約申込処理を即時処理で実行するように処理要求を送信する。Ｓ３で、契約申込確認部３１は、処理要求に従い、契約申込処理を即時処理により実行する。契約申込確認部３１は、保険契約申し込み情報を見積申込情報１３３に格納する。契約申込確認部３１は、契約申込処理の確認結果情報（ＯＫ／ＮＧ）を出力する。上記即時処理の際には、後述の前処理部１２や後処理部１３が呼び出される。

（Ｓ４，Ｓ５，Ｓ６） 次に、Ｓ４で、保険料払込入金受付部２２は、入金処理要求６０２を受け付けて受信する保険料払込入金受付処理を行う。保険料払込入金受付部２２は、入金処理要求６０２に対応した入金確認処理を、例えばセンターカット処理対象とする。Ｓ５で、保険料払込入金受付部２２は、入金確認部３２へ、入金確認処理をセンターカット処理で実行するように処理要求を送信する。Ｓ６で、入金確認部３２は、入金確認処理をセンターカット処理により実行する。入金確認部３２は、入金情報を決済情報１３５に格納する。入金確認部３２は、保険料払込入金確認処理の確認結果情報を出力する。上記センターカット処理の際には、後述のセンターカット処理部１１が呼び出される。

（Ｓ７，Ｓ８，Ｓ９） 次に、Ｓ７で、取付書類受付部２３は、取付書類処理要求６０３を受け付けて受信する取付書類受付処理を行う。取付書類受付部２３は、取付書類処理要求６０３に対応した取付書類確認処理を、例えば即時処理対象とする。Ｓ８で、取付書類受付部２３は、取付書類確認部３３へ、取付書類確認処理を即時処理で実行するように処理要求を送信する。Ｓ９で、取付書類確認部３２は、取付書類確認処理を即時処理により実行する。取付書類確認部３２は、取付書類データを見積申込情報１３３に格納する。取付書類確認部３２は、取付書類確認処理の確認結果情報を出力する。上記即時処理の際には、後述の前処理部１２や後処理部１３が呼び出される。

（Ｓ１０） Ｓ１０で、契約成立条件判定部４０は、確認部３０からの確認結果情報を用いて、条件設定情報９１の契約成立条件９１Ａに基づいて、契約成立条件判定処理を行う。契約成立条件判定部４０は、契約成立条件判定処理の判定結果情報（ＯＫ／ＮＧ）を出力する。本例では、図４のように、契約成立条件９１Ａには、保険Ｘ２に関して、申し込み、入金、及び取り付け書類の３つの要素の確認を必要とする条件Ｊ２が設定されている。契約成立条件判定部４０は、Ｓ３，Ｓ６，Ｓ９の確認結果情報が全てＯＫである場合、条件を満たすと判定し、その旨の情報（ＯＫ）を出力する。

（Ｓ１１） Ｓ１１で、保険契約計上部６０は、Ｓ１０の判定結果情報に基づいて、保険契約計上処理を行い、処理結果を契約情報１３２に格納する。保険契約計上部６０は、Ｓ１０の判定結果情報がＯＫである場合、保険Ｘ２に関する契約成立と判定する。また、始期日設定部５１は、始期日条件９１Ｂにおける保険Ｘ２に関する条件に基づいて、始期日設定処理を行う。始期日設定部５１は、保険始期日を契約情報１３２に格納する。

なお、Ｓ１〜Ｓ１１の各処理では、前述の日時管理部８０により各日時が日時管理情報８１に記録される。

（Ｓ１２） 証券作成部６０は、Ｓ１０の判定結果情報がＯＫである場合、証券作成処理を行い、作成した証券データをＤＢ部１３０の証券データ１３４に格納する。証券作成処理についても、即時処理対象またはセンターカット処理対象とすることが可能である。

（Ｓ１３） フォロー部７０は、Ｓ１０の判定結果情報がＮＧである場合、定義情報に基づいて、フォロー処理を行い、フォロー情報等をＤＢ部１３０のフォロー情報１３７に格納する。

［オンライン処理部］
次に、オンライン処理部１０におけるセンターカット処理機能等について説明する。従来の基幹システムは、オンラインバッチ処理方式を採用しており、オンライン処理停止が必要な夜間バッチ処理を行う。夜間バッチ処理は、日付繰り越し後、営業開始前まで、例えば０時から８時までの時間に行われている。

一方、本実施の形態の保険基幹システム１は、２４時間のサービス継続稼動を実現するため、システム設計として、オンライン即時処理方式を採用し、機能として、（１）センターカット処理機能、（２）前処理機能、（３）後処理機能、を有する。センターカット処理部１１は、センターカット処理機能を実現する。前処理部１２は、前処理機能を実現する。後処理部１３は、後処理機能を実現する。

これらの機能は、オンライン処理における業務機能の各処理の順序関係を保証し、ＤＢデータの整合性を確保する。オンライン処理部１０は、処理順序関係の定義情報に基づいて、各処理をトランザクション処理として実行する。センターカット処理は、即時処理との影響関係が少なくなるように、１件毎にトランザクション処理として、所定の順序関係及び排他制御に基づいて順次に実行される。センターカット処理は、即時処理の状況に応じて実際にいつ実行されたとしても、本来処理を実行する予定日時で実行された場合の結果と同様の結果が保証される。

オンライン処理部１０における処理概要は以下の通りである。

（１）オンライン処理部１０は、処理要求受付部２０により、外部または内部からの処理要求及びそれに伴う情報をオンラインで受信する。処理要求受付部２０は、処理要求に対応した業務機能を呼び出す。

（２）オンライン処理部１０における業務機能は、処理要求の処理が、センターカット処理対象であるか、即時処理対象であるかを確認または判断する。本実施の形態では、業務機能は、センターカット処理部１１を呼び出す。センターカット処理部１１は、処理順序関係の定義情報、またはスケジュールデータに基づいて、処理要求の処理が、センターカット処理対象であるか、即時処理対象であるかを確認または判断する。

スケジュールデータは、業務機能の各処理の実行に関するスケジュールを管理する情報であり、センターカットＤＢ１４０内に管理されている。処理順序関係の定義情報は、業務機能の各種の処理を実行する際に守るべき順序関係の定義情報である。

（３）オンライン処理部１０は、処理要求の処理がセンターカット処理対象であるか即時処理対象であるかに応じて、センターカット処理部１１、前処理部１２、後処理部１３に処理を行わせる。オンライン処理部１０は、処理要求の処理がセンターカット処理対象である場合、センターカット処理部１１にセンターカット処理を行わせる。オンライン処理部１０は、処理要求の処理が即時処理対象である場合、前処理部１２、及び後処理部１３に処理を行わせる。

（４）処理要求の処理をセンターカット処理とする場合、センターカット処理部１１は、センターカットＤＢ１４０内に、センターカット処理の予約情報を登録し、センターカット処理の実行開始の予定日時を含むスケジュールを登録する。

（５）処理要求の処理を即時処理とする場合、前処理部１２は、状況に応じて、予約済みのセンターカット処理を先に前処理として実行し、その次に即時処理を実行する。

（６）処理要求の処理を即時処理とする場合、後処理部１３は、状況に応じて、先に即時処理を実行し、その次に予約済みのセンターカット処理を後処理として実行する。

なお、処理順序関係の定義情報の実装については、各業務機能のプログラム内での実装でもよいし、処理順序関係の定義情報の表が管理され、各業務機能がその表を参照する形態でもよい。また、予め、保険基幹システム１の定義情報の１つとして、処理要求の処理毎に、センターカット処理対象であるか即時処理対象であるか等が設定されてもよい。管理者は、設定部９０を通じて、定義情報を設定可能である。例えば、保険料払い込みの入金確認処理について、クレジットカード払いの場合には即時処理対象、コンビニ払いの場合にはセンターカット処理対象、等と設定可能である。

［センターカット処理機能］
図７は、センターカット処理部１１を中心とした構成を示す。図７を用いて、センターカット処理機能について説明する。図７中には、ステップS701〜S705を併せて示す。

まず、オンライン処理部１０は、処理要求受付部２０によりオンラインで処理要求等を受信する。S701で、処理要求受付部２０は、処理要求等に応じた業務機能の処理に対応して、センターカット処理部１１を呼び出す。

センターカット処理部１１は、予約登録部１１Ａ、センターカットＤＢ１４０、スケジューラ部１１Ｂ、センターカット部１１Ｃを有する。センターカットＤＢ１４０は、センターカット処理に係わるデータを格納するＤＢであり、予約登録データ１４１、スケジュールデータ１４２を含む。

予約登録部１１Ａは、センターカット処理に係わる予約登録処理を行う。予約登録部１１Ａは、まず、S702で、処理要求に応じて、センターカットＤＢ１４０のスケジュールデータ１４２のスケジュール状況を参照し、当該処理要求の処理をセンターカット処理対象とするかどうかを判断する。予約登録部１１Ａは、当該処理要求の処理をセンターカット処理対象とする場合、S703で、当該処理要求の処理に関するセンターカット処理の予約情報を、センターカットＤＢ１４０の予約登録データ１４１に登録する。この予約情報は、センターカット処理としてどのような処理を実行すべきかの情報である。なお、センターカットＤＢ１４０にセンターカット処理が予約登録された時点では、そのセンターカット処理は未実行であり、ＤＢ部１３０のマスタＤＢには未反映である。

スケジューラ部１１Ｂは、センターカット処理に関するスケジュールを設定及び管理する処理を行う。S704で、スケジューラ部１１Ｂは、予約登録部１１Ａによるセンターカット処理の予約情報の登録に伴い、当該センターカット処理の実行のスケジュールを設定する。スケジューラ部１１Ｂは、予約登録データ１４１の予約情報に基づいて、センターカット処理を実行開始させる予定日時を含むスケジュールを決定し、その予定日時を含むスケジュール情報を、スケジュールデータ１４２に格納する。予約登録データ１４１の予約情報と、スケジュールデータ１４２のスケジュール情報とは、内容が関係付けられて管理される。

スケジューラ部１１Ｂは、必要なセンターカット処理の件数や、予約済みのスケジュール等に応じて、センターカット処理の予定日時を含むスケジュールを調整する。スケジューラ部１１Ｂは、定義情報に基づいて、処理要求に応じた予定日時を設定する。スケジューラ部１１Ｂは、例えば入金の決済手段の都合に応じて、予定日時を設定する。スケジューラ部１１Ｂは、例えばコンビニ払いの場合に決済情報の取得に要する日数を考慮して、予定日時を設定する。

なお、センターカット処理部１１は、センターカットＤＢ１４０の予約登録データ１４１の予約情報を、所定の期間、保持する。これにより、少なくとも、当日及び翌日に処理すべきセンターカット処理の予約情報が保持される。

センターカット部１１Ｃは、S705で、スケジュールデータ１４２のスケジュールの予定日時に従い、予約登録データ１４１に予約登録されているセンターカット処理を自動的に実行する。センターカット部１１Ｃは、ＤＢ部１３０のＤＢデータ７０１を読み書きしながら、センターカット処理をトランザクション処理として実行する。ＤＢデータ７０１は、実行する処理に対応したデータである。

予約登録されたセンターカット処理は、予定日時を含む所定の期間内において実行される。予約登録されたセンターカット処理は、予定日時よりも前に、後述の前処理として前倒しで実行される場合がある。予約登録されたセンターカット処理は、予定日時での実行結果がエラーである場合、予定日時よりも後に、後述の後処理として実行される場合がある。予約登録されたセンターカット処理は、所定の期間内であれば、いつ実行されたとしても、当初の予定日時で実行された場合と同様の結果が保証される。

［前処理機能］
図８は、前処理部１２を中心とした構成を示す。図８を用いて、センターカット処理機能と前処理機能との連係動作について説明する。センターカット処理部１１の構成は図７と同様である。

前処理部１２は、処理要求に応じて即時処理を実行する際、予約済みで未実行状態のセンターカット処理を「前処理」として行うべきか判断し、行うべき場合には当該センターカット処理を前処理として実行させ、次に即時処理を実行させる。前処理部１２は、即時処理とセンターカット処理との順序関係を保証し、ＤＢデータの整合性を確保する。

前処理部１２は、予約確認部１２Ａ、前処理判断部１２Ｂ、センターカット処理制御部１２Ｃ、即時処理制御部１２Ｄを有する。

予約確認部１２Ａは、処理要求受付部２０の処理要求に応じて、センターカットＤＢ１４０の予約登録データ１４１の予約情報や、スケジュールデータ１４２のスケジュール情報を参照し、センターカット処理の予約の有無や予定日時等を確認する。

前処理判断部１２Ｂは、予約確認部１２Ａの予約確認結果、及び処理順序関係の定義情報に基づいて、即時処理対象の処理要求の処理よりも先に、予約済みの未実行状態のセンターカット処理を前処理として実行すべきかを判断する。

センターカット処理制御部１２Ｃは、前処理判断部１２Ｂの判断結果に基づいて、センターカット処理を前処理として実行させる場合、当該センターカット処理を前処理として実行させる制御処理を行う。本実施の形態では、この制御処理として、センターカット処理制御部１２Ｃは、スケジューラ部１１Ｂへ、制御指示を送信する。スケジューラ部１１Ｂは、制御指示に従い、センターカット部１１Ｃに、センターカット処理を前処理として実行させる。センターカット部１１Ｃは、センターカット処理を実行する。これに伴い、スケジューラ部１１Ｂは、スケジュールデータ１４２の内容を更新する。スケジューラ部１１Ｂは、スケジュールデータ１４２の当初の予定日時のセンターカット処理を前処理として実行済みであることやその結果を示す情報を登録する。

即時処理制御部１２Ｄは、前処理判断部１２Ｂの判断結果に基づいて、センターカット処理の次に即時処理を実行させる制御処理を行う。本実施の形態では、この制御処理として、即時処理制御部１２Ｄは、オンライン処理部１０内の対応する処理部に制御指示を送信する。その処理部は、制御指示に従い、処理要求に対応した即時処理を実行する。

［前処理機能 第１の例］
図８を用いて、前処理が発生する場合の第１の具体例を説明する。図８では、オンライン処理部１０の処理要求受付部２０として、図２の保険料払込受付部２２、取付書類受付部２３を示す。図８では、ある保険会社Ａの保険Ｘ２に関する契約申し込みの例とする。保険Ｘ２は、契約成立条件として、契約申し込み情報、入金、取り付け書類の３つの要素の確認が必要である。顧客の動作として、順に、（１）契約申し込み、（２）保険料払い込み、（３）取り付け書類送付、とする。

（１）の動作は、例えばある日の昼間、顧客からＷｅｂを通じて保険Ｘ２の契約申し込みが行われ、保険契約申し込み情報が入力される動作である。その際、払い込み方法としてコンビニ払いが指定され、払込票が発行されている。（２）の動作は、顧客から保険Ｘ２の契約申し込みに伴って必要である保険料の払い込みがコンビニ払いで行われる動作である。コンビニのシステムは、払い込みを受け、銀行のシステム等と連係して、決済処理を行い、入金情報を保険基幹システム１に送信する。（３）の動作は、顧客から保険Ｘ２の契約に必要である取り付け書類、例えば車検証コピーが、保険会社Ａへ郵送される動作である。保険会社Ａの業務員は、取り付け書類のデータを業務員端末３で入力する。業務員端末３は、取り付け書類データを保険基幹システム１へ送信する。

図８では、前提として、（１）の動作に対応した申込処理要求に応じた申込確認処理が即時処理で既に行われているとする。この即時処理では、正しい保険契約申し込み情報を入力及び確認済みである。

図８中のステップS801〜S803，S811〜S815について順に説明する。

（S801） 上記前提に基づいて、まず、入金処理要求８０１が発生している。入金処理要求８０１は、（２）の動作に対応するために、入金確認部３２に入金確認処理を行わせる要求であり、センターカット処理対象である。保険料払込入金受付部２２は、入金処理要求８０１を受信する。保険料払込入金受付部２２は、入金処理要求８０１を、入金確認部３２に送信する。入金確認部３２は、センターカット処理部１１を呼び出す。

（S802） センターカット処理部１１は、予約登録部１１Ａにより、スケジュールデータ１４２を参照し、入金処理要求８０１の入金確認処理をセンターカット処理対象とするかを判断する。本例では、払い込み方法がコンビニ払いであるため、入金確認処理をセンターカット処理対象とする。予約登録部１１Ａは、入金確認処理のセンターカット処理の予約情報を、予約登録データ１４１に登録する。

（S803） スケジューラ部１１Ｂは、入金確認処理のセンターカット処理の予定日時を含むスケジュール情報を、スケジュールデータ１４２に登録する。スケジューラ部１１Ｂは、コンビニ払いの日時や、決済システム５の都合を考慮して、予定日時を設定する。

（S811） 一方、S801の入金処理要求８０１の受信よりも後の時点で、取付書類処理要求８０２が発生している。取付書類処理要求８０２は、（３）の動作に対応するために、取付書類確認部３３に取付書類確認処理を行わせる要求であり、即時処理対象である。取付書類受付部２３は、外部からオンラインで取付書類処理要求８０２を受信する。取付書類受付部２３は、例えば業務員端末２から取り付け書類データを伴う取付書類処理要求８０２を受信する。取付書類受付部２３は、取付書類処理要求８０２を、取付書類確認部３３に送信する。取付書類確認部３３は、前処理部１２を呼び出す。なお、ここでは後処理部１３を呼び出す場合の処理は省略する。

（S812） 前処理部１２のセンターカット予約確認部１２Ａは、センターカットＤＢ１４０の予約登録データ１４１の予約情報やスケジュールデータ１４２を参照し、センターカット処理の予約の有無、予定日時等を確認する。本例では、S801〜S803によって入金確認処理のセンターカット処理の予約情報が登録済みである。

（S813） 前処理判断部１２Ｂは、S812の予約確認結果に基づいて、即時処理対象である取付書類確認処理よりも先に、予約済みのセンターカット処理ある入金確認処理を前処理として実行すべきか判断する。本例では、入金確認処理を前処理として実行すべきと判断される。

（S814） センターカット処理制御部１２Ｃは、S813の判断結果に基づいて、入金確認処理のセンターカット処理を前処理として実行させる。センターカット処理制御部１２Ｃは、スケジューラ部１１Ｂへ、制御指示を送信する。スケジューラ部１１Ｂは、制御指示に従い、センターカット部１１Ｃに入金確認処理のセンターカット処理を実行させる。センターカット部１１Ｃは、入金確認処理を行い、ＤＢ部１３０の決済情報１３５に入金情報を格納する。スケジューラ部１１Ｂは、スケジュールデータ１４２の内容を更新する。

（S815） 即時処理制御部１２Ｄは、S813の判断結果に基づいて、センターカット処理の次に即時処理を実行させる。即時処理制御部１２Ｄは、オンライン処理部１０内の対応する処理部である取付書類確認部３３に制御指示を送信する。取付書類確認部３３は、制御指示に従い、入金確認処理の次に取付書類確認処理を実行する。取付書類確認部３３は、ＤＢ部１３０の見積申込情報１３３に取付書類データを格納する。

［前処理機能 第２の例］
同じく図８に基づいて、前処理に関する第２の具体例を以下に説明する。以下、第１の具体例とは異なる部分を説明する。本例では、顧客から保険会社への動作として、まず、第１の異動の連絡がＷｅｂチャネルを通じて発生し、次に、第２の異動の連絡が電話チャネルを通じて発生したとする。２つの動作に対応して、保険基幹システム１では、処理要求として、第1の異動処理要求、第２の異動処理要求が順に発生する。第１の異動処理要求は、Ｗｅｂチャネルに対応して、センターカット処理対象とし、第２の異動処理要求は、電話チャネルに対応して、即時処理対象とする。業務機能部１２０は、業務機能の１つとして、異動処理を行う業務機能を含む。オンライン処理部１０は、異動処理を即時処理やセンターカット処理により行う処理部を含む。

（１） 処理要求受付部は、顧客から例えばＷｅｂチャネル経由でオンラインで第１の異動処理要求を受信する。第１の異動処理要求における異動は、例えば自動車損保に関する車両入れ替え実施時の契約情報の変更である。第１の異動処理要求は、異動情報として車両入れ替え情報を伴う。また、第１の異動処理要求は、この要求を受け付けた日時を異動要求受付日時として伴う。処理要求受付部は、第１の異動処理要求に従い、異動処理を行う業務機能に、異動処理を行わせる。

（２） 異動処理を行う業務機能に対応したセンターカット処理部１１は、第１の異動処理のセンターカット処理の予約情報や、予定日時を含むスケジュール情報を、センターカットＤＢ１４０内に登録する。

（３） 一方、第１の異動処理要求の受信よりも後の時点、例えば数秒後の時点で、第２の異動処理要求が発生したとする。処理要求受付部は、同じ顧客から電話チャネル経由でオンラインで第２の異動処理要求を受信する。第２の異動処理要求は、第１の異動処理要求の異動情報である車両入れ替え情報に加え、異なる異動情報として、住所変更情報を伴うとする。また、第２の異動処理要求は、この要求を受け付けた日時を異動要求受付日時として伴う。

（４） 異動処理を行う業務機能に対応した前処理部１２は、センターカットＤＢ１４０を参照し、センターカット処理の予約の有無や予定日時等を確認する。本例では、第１の異動処理のセンターカット処理の予約情報が登録済みである。

（５） 前処理部１２は、予約確認結果に基づいて、即時処理対象である第２の異動処理よりも先に、予約済みのセンターカット処理である第１の異動処理を前処理として実行すべきか判断する。本例では、前処理部１２は、定義情報及び異動要求受付日時に基づいて、第１の異動処理のセンターカット処理を前処理として実行すべきと判断される。

（６） 前処理部１２は、判断結果に基づいて、第１の異動処理のセンターカット処理を前処理として実行させる。センターカット部１１Ｃは、ＤＢ部１３０の契約情報１３２に、顧客の異動情報である車両入れ替え情報を反映する。

（７） 前処理部１２は、判断結果に基づいて、前処理の次に即時処理を実行させる。対応する処理部は、ＤＢ部１３０の顧客情報１３１に、異動情報である住所変更情報を反映する。

［後処理機能］
図９は、後処理部１３を中心とした構成を示す。図９を用いて、後処理機能とセンターカット処理機能との連係動作について説明する。

後処理部１３は、処理要求に応じて即時処理を行う際、予約済みで実行結果がエラー状態のセンターカット処理について、先に即時処理を実行した次に「後処理」として実行すべきか判断し、実行すべき場合、当該センターカット処理を後処理として実行させる。後処理機能は、前処理機能と同様に、即時処理とセンターカット処理との順序関係を保証し、ＤＢデータの整合性を確保する。

後処理部１３は、予約確認部１３Ａ、後処理確認部１３Ｂ、即時処理制御部１３Ｃ、センターカット処理制御部１３Ｄを有する。

処理要求受付部は、処理要求を受信し、即時処理対象の処理である場合、後処理部１２を呼び出す。なお、ここでは前処理部１２を呼び出す場合の処理は省略する。

後処理部１３の予約確認部１３Ａは、センターカットＤＢ１４０の予約登録データ１４１の予約情報やスケジュールデータ１４２を参照し、センターカット処理の予約の有無や、その予定日時や、実行結果のエラーの有無、等を確認する。予約済みのセンターカット処理における予定日時での実行結果がエラーとなっている場合、以下の処理が行われる。

後処理判断部１３Ｂは、確認結果、及び処理順序関係の定義情報等に基づいて、即時処理対象の処理の次にセンターカット処理を後処理として実行すべきか判断する。

即時処理制御部１３Ｃは、判断結果に基づいて、先に即時処理を実行させる制御処理を行う。本実施の形態では、制御処理として、即時処理制御部１２Ｃは、オンライン処理部１０内の対応する処理部に、制御指示を送信する。対応する処理部は、処理要求に対応した即時処理を実行する。

センターカット処理制御部１３Ｄは、判断結果に基づいて、即時処理の次にセンターカット処理を実行させる制御処理を行う。本実施の形態では、制御処理として、センターカット処理制御部１３Ｄは、スケジューラ部１１Ｂへ、制御指示を送信する。スケジューラ部１１Ｂは、制御指示に従い、センターカット部１１Ｃに、センターカット処理を実行させる。センターカット部１１Ｃは、センターカット処理を実行する。これに伴い、スケジューラ部１１Ｂは、スケジュールデータ１４２の内容を更新する。

［後処理機能 第１の例］
図９を用いて、後処理が発生する場合の第１の具体例を説明する。図９では、オンライン処理部１０において、図２の証券作成部６０、保険料払込入金受付部２２、入金確認部３２を示す。図９では、ある保険会社Ａの保険Ｘ１に関する契約申し込みの例とする。保険Ｘ１は、契約成立条件として、契約申し込み情報、入金、の２つの要素の確認が必要である。顧客の動作として、順に、（１）契約申し込み、（２）保険料払い込み、とする。（１）の動作は、例えばある日の昼間、顧客からＷｅｂを通じて保険Ｘ１の契約申し込みが行われ、保険契約申し込み情報が入力される動作である。この際、払い込み方法としてクレジットカード払いが指定される。（２）の動作は、顧客から保険Ｘ１の契約申し込みに伴って必要である保険料の払い込みが、クレジットカード払いで行われる。クレジットカード会社のシステムは、払い込みを受け、決済処理を行い、入金情報を保険基幹システム１に送信する。

図９では、前提として、（１）の動作に対応した申込処理要求に応じた申込確認処理が即時処理で既に行われているとする。この即時処理では、正しい保険契約申し込み情報を入力及び確認済みである。

図９中のステップS901〜S904，S911〜S915について順に説明する。

（S901） まず、証券作成処理要求９０１が発生している。オンライン処理部１０は、（１）の動作に対応した契約申し込み情報の確認済みに基づいて、予め先に、証券作成処理に関する証券作成処理要求９０１を発生させている。証券作成部６０は、証券作成処理要求９０１を受信し、センターカット処理部１０を呼び出す。

（S902） 予約登録部１１Ａは、証券作成処理要求９０１に基づいて、スケジュールデータ１４２を確認し、証券作成処理をセンターカット処理対象とする。予約登録部１１Ａは、証券作成処理のセンターカット処理の予約情報を予約登録データ１４１に登録する。

（S903） スケジューラ部１１Ｂは、証券作成処理のセンターカット処理の予定日時を含むスケジュール情報をスケジュールデータ１４２に格納する。

（S904） センターカット部１１Ｃは、センターカットＤＢ１４０の予約情報及びスケジュール情報に従い、予定日時に、証券作成処理のセンターカット処理を実行する。しかし、この予定日時での実行の時点で、顧客による払い込みが行われておらず、入金情報を受信しておらず、入金確認済みではないとする。この場合、まだ契約が成立せず、証券を作成すべきではないので、センターカット部１１Ｃは、このセンターカット処理の実行結果をエラーにする。センターカット部１１Ｃは、予定日時でのセンターカット処理である証券作成処理の実行結果がエラーである旨の情報を、センターカットＤＢ１４０内のスケジュールデータ１４２内に記録する。

（S911） 一方、証券作成処理要求９０１及び上記センターカット処理の予定日時よりも後の時点で、入金処理要求９０２が発生している。保険料払込受付部２２は、外部の決済システム５からオンラインで入金処理要求９０２を受信する。入金処理要求９０２は、入金情報を含む決済情報を伴う。入金処理要求９０２は即時処理対象である。保険料払込受付部２２は、入金処理要求９０２を入金確認部３２に送信する。入金確認部３２は、後処理部１３を呼び出す。なお、ここでは前処理部１２を呼び出す場合の処理は省略する。

（S912） 後処理部１３のセンターカット予約確認部１３Ａは、センターカットＤＢ１４０の予約登録データ１４１の予約情報やスケジュールデータ１４２を参照し、センターカット処理の予約の有無、予定日時、実行結果のエラーの有無、等を確認する。本例では、S901〜S904によって、予約済みの証券作成処理のセンターカット処理における予定日時での実行がエラーとなっている。

（S913） 後処理判断部１３Ｂは、S912の確認結果、及び処理順序関係の定義情報等に基づいて、即時処理対象である入金確認処理の次に、実行結果がエラーのセンターカット処理である証券作成処理を後処理として実行すべきか判断する。本例では、入金確認処理の次に証券作成処理を後処理として実行すべきと判断される。

（S914） 即時処理制御部１３Ｃは、S913の判断結果に基づいて、先に即時処理である入金確認処理を実行させる制御処理を行う。即時処理制御部１２Ｃは、オンライン処理部１０内の対応する処理部である入金確認部３２に、制御指示を送信する。入金確認部３２は、即時処理として入金確認処理を実行する。入金確認部３２は、ＤＢ部１３０の決済情報１３５に入金情報を格納する。

（S915） センターカット処理制御部１３Ｄは、S913の判断結果に基づいて、次にセンターカット処理である証券作成処理を実行させる制御処理を行う。センターカット処理制御部１３Ｄは、スケジューラ部１１Ｂへ、制御指示を送信する。スケジューラ部１１Ｂは、制御指示に従い、センターカット部１１Ｃに、証券作成処理のセンターカット処理を実行させる。センターカット部１１Ｃは、証券作成処理のセンターカット処理を実行する。センターカット部１１Ｃは、作成した証券データを、ＤＢ部１３０の証券データ１３４に格納する。この証券作成処理では、入金確認済みであり、契約成立しているため、実行結果が成功となる。これに伴い、スケジューラ部１１Ｂは、スケジュールデータ１４２の内容を更新する。スケジューラ部１１Ｂは、予約済みで実行結果がエラーであったセンターカット処理について、実行結果を成功として更新する。

［前処理を含む具体例の時系列図］
図１０は、図８の前処理機能及び第１の具体例に対応した、センターカット処理及び前処理を含む動作の具体例を時系列で示す。横軸は時間である。縦方向には、順に、（ａ）顧客動作及び決済手段動作、（ｂ）即時処理、（ｃ）センターカット処理、（ｄ）前処理を示す。（ａ）の顧客動作は、依頼を受けた業務員の動作とした場合も同様である。

（１） まず時点ｔ１で、（ａ）の顧客動作の例として、顧客は、保険契約申し込みを例えばＷｅｂチャネル経由で行う。同じ時点ｔ１で、（ｂ）で、オンライン処理部１０は、保険契約申し込みに対応した申込確認処理を即時処理で行う。ＤＢ部１３０の見積申込情報１３３には、その顧客の保険契約申し込み情報が格納される。

（２） 次に時点ｔ２で、（ａ）で、顧客は、時点ｔ１の申し込みと対応した、保険料払い込みを、所定の決済手段、例えばコンビニ払いで行う。なお、払い込み方法及び決済手段に応じて、保険基幹システム１が入金情報を得るまでに、所定の時間を要する。例えばクレジットカードの場合、即日で決済可能であり、当日すぐに入金情報が得られる。コンビニ払いの場合、例えば翌日や３営業日等の時間を要する。

（３） 時点ｔ３で、（ａ）で、決済システム５は、時点ｔ２の払い込みの動作に対応して、決済処理を行い、入金情報を含む決済情報を、保険基幹システム１に送信する。同じ時点ｔ３で、（ｂ）で、オンライン処理部１０の保険料払込入金受付部２２は、その入金情報を受信する。保険料払込入金受付部２２は、入金処理要求を、入金確認部３２へ送信する。この入金処理要求はセンターカット処理対象である。入金確認部３２は、センターカット処理部１１を呼び出す。

時点ｔ３で、（ｃ）で、センターカット処理部１１は、入金確認処理のセンターカット処理を予約登録し、スケジュールデータ１４２に予定日時を設定する。この予定日時は、例えば時点ｔ８とする。その後、仮に即時処理が発生しない場合、時点ｔ８の予定日時の通り、入金確認処理のセンターカット処理８１０が自動実行される。

（４） ここで、時点ｔ８よりも前の時点、例えば時点ｔ４で、（ａ）で、取り付け書類の送付が発生したとする。業務員は、取り付け書類のデータを業務員端末２で入力する。時点ｔ４で、（ｂ）で、オンライン処理部１０の取付書類受付部２３は、取付書類処理要求を受信し、取付書類確認部３３へ送信する。取付書類処理要求は、即時処理対象である。取付書類確認部３３は、前処理部１２を呼び出す。前処理部１２は、時点ｔ４で、（ｄ）で、センターカット処理の予約を確認する。本例では、時点ｔ３で、入金確認処理のセンターカット処理が予約済みである。前処理部１２は、先に入金確認処理を前処理として実行すべきと判断し、時点ｔ４で、入金確認処理のセンターカット処理の前処理８１１を実行開始させる。

これにより、（ｃ）に示す予定日時である時点ｔ８のセンターカット処理８１０は、前倒しされ、（ｄ）に示す前処理８１１として実行される。本例では、時点ｔ４の入金確認処理の結果、正しい入金が確認されたとする。日時管理部８０は、日時管理情報８１に、入金確認日時を記録する。

（５） 次に、時点ｔ５で、前処理部１２は、前処理８１１の終了に続き、取付書類確認処理の即時処理８１２を実行開始させる。本例では、この取付書類確認処理で、正しい取り付け書類が揃っていることが確認される。日時管理部８０は、日時管理情報８１に、取付書類確認日時を記録する。

（６） オンライン処理部１０は、時点ｔ４で前処理８１１が実行され、時点ｔ５で取付書類確認処理８１２が実行されたので、時点ｔ６で、契約成立条件判定部４０により契約成立条件判定処理８１３を実行する。本例では、保険Ｘ２に関する契約成立条件を満たす。よって、保険契約計上処理部５０は、契約を成立させる。始期日設定部５１は、始期日条件及び日時管理情報８１に基づいて、保険始期日を設定する。始期日設定部５１は、保険契約申し込み情報、入金、取り付け書類の確認に関する全ての条件を満たした契約成立日時を用いて、保険始期日を設定する。ＤＢ部１３０の契約情報１３２には、対応する顧客の保険契約情報が格納される。

（７） 時点ｔ６の契約成立条件確認処理８１３の結果、条件を満たし、契約が成立した場合、時点ｔ７では、続いて連携する処理として、証券作成部６０による証券作成処理８１４が実行される。

（８） 時点ｔ６の契約成立条件確認処理８１３の結果、条件を満たさず、契約が成立しない場合、時点ｔ７では、続いて連携する処理として、証券作成処理８１４ではなく、フォロー部７０によるフォロー処理が実行される。

上記例のように、本実施の形態は、センターカット処理機能や前処理機能を用いて、契約申し込み、保険料払い込み入金、及び取り付け書類等を確認し、契約成立条件を判定し、証券作成やフォローを行う処理を、連係して自動的に実行する。特に、取り付け書類の確認処理の即時処理に伴って、コンビニ払いの入金確認処理のセンターカット処理が前処理として実行される。これにより、速やかに保険契約を成立させることができ、効率的にフォロー作業を行うことができる。従来の基幹システムの場合、バッチ処理方式であるため、昼間に契約申し込みや取り付け書類の確認がオンラインで完了しても、コンビニ払いの入金確認処理は翌日以降の夜間バッチ処理で行われるので、契約成立が遅れる。一方、本実施の形態では、契約成立条件を満たす時点で速やかに契約成立が可能である。

［後処理を含む具体例の時系列図］
図１１は、図９の後処理機能及び第１の具体例に対応した、センターカット処理及び後処理を含む動作の具体例を時系列で示す。縦方向には、順に、（ａ）顧客動作及び決済手段動作、（ｂ）即時処理、（ｃ）センターカット処理、（ｄ）後処理を示す。

（１） 時点ｔ１で、（ａ）の顧客動作として、保険契約申し込みが行われる。（ｂ）で、申込確認処理が即時処理で行われる。

（２） 時点ｔ２で、（ｂ）で、オンライン処理部１０は、証券作成処理要求を発行し、証券作成部６０は、証券作成処理要求を受信し、センターカット処理部１１を呼び出す。センターカット処理部１１は、証券作成処理のセンターカット処理を予約登録する。このセンターカット処理の予定日時は、時点ｔ３であるとする。

（３） 時点ｔ３で、（ｃ）で、予定日時に、証券作成処理のセンターカット処理９１０が実行される。しかし、入金確認済みではないため、センターカット処理９１０の実行結果がエラーとなる。

（４） 時点ｔ４で、（ａ）の顧客動作として、保険料払い込みが例えばクレジットカード払いで行われる。

（５） 時点ｔ５、決済システム５は、決済処理を行い、入金情報を送信する。保険料払込入金受付部２２は、入金情報を受信し、入金確認部３２に入金処理要求を送信する。（ｂ）で、入金確認部３２は、入金確認処理を即時処理で行う。入金確認部３２は、後処理部１３を呼び出す。（ｄ）で、後処理部１３は、入金確認処理の次に証券作成処理のセンターカット処理を後処理として行うと判断する。時点ｔ５で、後処理部１３は、先に入金確認処理の即時処理９１１を行わせる。その確認結果が正しい（ＯＫ）とする。

（７） 時点ｔ５で、入金確認処理の確認結果が正しい（ＯＫ）となったため、時点ｔ６では、（ｂ）で、契約成立条件判定部４０により契約成立条件判定処理９１２が行われ、条件を満たす判定結果となる。

（８） 時点ｔ６で条件を満たすため、時点ｔ７で、後処理部１３は、証券作成処理のセンターカット処理の後処理を行わせる。なお、即時処理９１１の結果、入金の正しさが確認できない場合、契約成立条件判定処理９１２で条件を満たさない判定結果となるので、時点ｔ７では、フォロー処理が行われる。

上記例では、特に、入金確認処理の即時処理に伴って、証券作成処理のセンターカット処理が後処理として実行される。これにより、速やかに、保険契約の成立と共に、証券の発行、印字が可能である。従来の基幹システムの場合、バッチ処理方式であるため、昼間にクレジットカード払いの入金確認等がオンラインで完了しても、証券作成処理は翌日以降の夜間バッチ処理で行われるので、証券の発行が遅れる。一方、本実施の形態では、契約成立に伴い速やかに証券の発行が可能である。

［効果等］
以上説明したように、本実施の形態の保険基幹システム１によれば、センターカット処理機能等を含むオンライン処理機能により、２４時間のサービス継続稼動を実現でき、保険会社における基幹業務の効率向上、サービス提供時間の拡大、保険会社及び顧客の契約成立に要する時間の短縮や手間の削減等を実現できる。

顧客は、複数のチャネル及び決済手段を通じて、常時に保険契約に係わるサービスを受けることができ、便利である。保険会社と顧客との間で、速やかに保険契約を成立させることができ、保険始期日を早い日時に設定でき、補償の開始の日時を早くすることができる。保険会社は、保険商品に応じた契約成立条件を設定できる。保険会社は、時分秒単位で保険始期日を設定及び管理することができる。保険会社は、管理上、顧客毎の状態及び日時を時分秒単位で細かく管理でき、業務効率を向上できる。

従来では、例えば顧客が自動車損保の契約を申し込んだ直後、保険料払い込みの入金が確認されるまでに時間がかかり、契約が成立するまでに時間がかかる。入金等が確認された後、１日単位で保険始期日が設定されている。仮にその間に事故が発生したとしても、契約成立前なので補償はされない。一方、本実施の形態では、保険料払い込みの入金が速やかに確認され、速やかに保険契約ができ、保険始期日が従来よりも早い日時に設定できるので、申し込み直後の事故の場合にも補償の対応が可能となる。

また、保険更新日等の直前の期間では、多数の顧客から契約の問合せや申し込みのアクセスが集中して発生しやすい。従来のバッチ処理方式の基幹システムでは、これに対して効率的な処理ができず、夜間バッチ処理では完了できない可能性がある。一方、本実施の形態では、オンライン処理停止が必要なバッチ処理を排除したので、多数のアクセスを効率的に処理できる。

また、従来の基幹システムは、Ｗｅｂシステムやコールセンタシステム毎にＤＢデータを保持する。基幹システムは、チャネル間でＤＢデータを連係する場合、バッチ処理を介在してＤＢ間のデータの反映を行う。しかし、バッチ処理を介在するので、即時にデータの反映はできず、翌日以降まで待つ場合がある。タイミングによっては、バッチ処理の未実行により、チャネル間でのＤＢ間のデータの反映が済んでおらず、データ間に不整合が生じている。即ち、従来、任意時点でチャネル間のデータ整合性を確保することはできない。一方、本実施の形態では、バッチ処理の排除により、任意時点でチャネル間のデータ整合性を確保することができる。

また、従来の基幹システムは、バッチ処理を介在することで、入金確認処理等に時間がかかる。業務員は、この時間が長くなるほど、フォロー作業に時間及び手間がかかる。例えば、業務員は、顧客に入金催促等のフォロー作業を行うが、その場合、最初に顧客が申し込みをした時点から時間が経過するほど、顧客とのコンタクト、例えば電話連絡等がつきにくくなる。これにより保険契約の成立が遅れてしまう。また、業務員は、チャネル間でのデータ内容の確認やフォロー等の追加的な作業が必要になり、手間が多い。一方、本実施の形態では、自動的に連係してフォロー処理を行う仕組みを有し、業務員のフォロー作業の効率を向上でき、保険契約の成立を早めることができる。

以上、本発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されず、その要旨を逸脱しない範囲で種々変更可能である。本実施の形態の保険基幹システムは、生保の基幹システムの場合にも同様に適用可能である。

１…保険基幹システム、２…業務員端末、３…顧客端末、４…業務員端末、５…決済システム、６…他連係システム、７…インターネット、８…電話網、９…連携システム、１０…オンライン処理部、１１…センターカット処理部、１２…前処理部、１３…後処理部、２０…処理要求受付部、２１…契約申込受付部、２２…保険料払込入金受付部、２３…取付書類受付部、３０…確認部、３１…契約申込確認部、３２…入金確認部、３３…取付書類確認部、４０…契約成立条件判定部、５０…保険契約計上部、５１…始期日設定部、６０…証券作成部、７０…フォロー部、８０…日時管理部、８１…日時管理情報、９０…設定部、９１…条件設定情報、１１０…Ｗｅｂサーバ部、１１１…画面提供部、１２０…業務機能部、１３０…ＤＢ部、１３１…顧客情報、１３２…契約情報、１３３…見積申込情報、１３４…証券データ、１３５…決済情報、１３６…事故情報、１３７…フォロー情報、１４０…センターカットＤＢ。

Claims (9)

1. 保険会社の保険商品の契約管理を含む基幹業務を支援する情報処理を行う保険基幹システムであって、
   前記基幹業務に関する処理をオンライン処理として行うオンライン処理部を備え、
   前記オンライン処理部は、
   前記保険会社の業務員端末、顧客端末、または連係システムから、前記基幹業務に関する情報または処理要求をオンラインで受け付けて受信する処理要求受付部と、
   前記情報または処理要求に応じた業務処理を実行する業務処理部と、
   前記業務処理で読み書きするＤＢデータと、
   を含み、
   前記業務処理部は、
   保険契約の申し込み情報を確認する申込確認部と、
   保険料払い込みの入金情報を確認する入金確認部と、
   前記申し込み情報及び前記入金情報の確認の結果、及び契約成立条件に基づいて、保険契約の成立を判定する条件判定部と、
   前記成立の場合、保険契約の計上処理を行う計上部と、
   を有する、保険基幹システム。
2. 請求項１記載の保険基幹システムにおいて、
   前記オンライン処理部は、
   センターカット処理を行うセンターカット処理部と、
   前処理を行う前処理部と、
   後処理を行う後処理部と、
   を含み、
   前記センターカット処理部は、前記業務処理がセンターカット処理対象である場合、前記業務処理のセンターカット処理の予約情報、及び予定日時を含むスケジュール情報を、センターカットＤＢに登録し、前記予定日時に前記センターカット処理を実行し、
   前記前処理部は、前記業務処理がオンライン即時処理の対象である場合、前記センターカットＤＢを確認し、予約済みで未実行の前記センターカット処理を、前記前処理として、前記オンライン即時処理よりも前に実行し、
   前記後処理部は、前記業務処理がオンライン即時処理の対象である場合、前記センターカットＤＢを確認し、予約済みで実行結果がエラーの前記センターカット処理を、前記後処理として、前記オンライン即時処理よりも後に実行する、
   保険基幹システム。
3. 請求項１記載の保険基幹システムにおいて、
   前記処理要求受付部は、前記業務員端末または前記顧客端末から、前記申し込み情報を受信し、前記連係システムから、前記入金情報を受信し、
   前記申込確認部は、前記申し込み情報の記載に不備が無く正しいか確認する処理、及び前記入金情報に不備が無く正しいか確認する処理を行い、
   前記条件判定部は、前記申し込み情報及び前記入金情報の正しさを確認した場合に前記成立と判定する、
   保険基幹システム。
4. 請求項１記載の保険基幹システムにおいて、
   前記処理要求受付部は、前記業務員端末、前記顧客端末、または前記連係システムから、前記保険契約に必要な取り付け書類に関するデータを受信し、
   前記業務処理部は、前記取り付け書類に不備が無く正しいか確認する取付書類確認部を有し、
   前記条件判定部は、前記申し込み情報、前記入金情報、及び前記取り付け書類の正しさを確認した場合に前記成立と判定する、
   保険基幹システム。
5. 請求項１記載の保険基幹システムにおいて、
   前記処理要求受付部は、前記業務員端末、前記顧客端末、または前記連係システムから、前記保険契約に必要な審査結果情報を受信し、
   前記業務処理部は、前記審査結果情報に不備が無く正しいか確認する審査結果確認部を有し、
   前記条件判定部は、前記申し込み情報、前記入金情報、及び前記審査結果の正しさを確認した場合に前記成立と判定する、
   保険基幹システム。
6. 請求項１記載の保険基幹システムにおいて、
   前記業務処理部は、保険証券の作成処理を行う証券作成部を有し、
   前記証券作成部は、前記成立の場合の前記計上処理に連係して、前記保険証券の作成処理を行う、
   保険基幹システム。
7. 請求項１記載の保険基幹システムにおいて、
   前記保険会社の業務員または顧客に対するフォロー処理を行うフォロー部を有し、
   前記条件判定部は、前記確認の結果、前記契約成立の条件を満たさない場合、不備の項目を含む確認結果情報を、前記フォロー部へ出力し、
   前記フォロー部は、前記確認結果情報に基づいて、前記不備の項目に応じたフォロー情報を、前記保険会社の業務員または顧客に送信する前記フォロー処理を行い、
   前記フォロー情報の送信手段は、メール、電話、Ｗｅｂ、または帳票の少なくとも１つを含む、
   保険基幹システム。
8. 請求項１記載の保険基幹システムにおいて、
   前記オンライン処理部は、日時管理部を有し、
   前記日時管理部は、前記情報または処理要求を受信した日時、前記契約成立の条件における前記申し込み情報及び前記入金情報を含む要素毎に正しさを確認した日時、前記成立の日時、を含む日時を、日時管理情報に記録し、
   前記日時管理情報を含む画面を、前記業務員端末または前記顧客端末に提供する、
   保険基幹システム。
9. 請求項８記載の保険基幹システムにおいて、
   前記計上部は、始期日設定部を有し、
   前記始期日設定部は、前記日時管理情報、及び前記保険商品毎の始期日条件に基づいて、前記成立に伴い、前記始期日を、年月日時分秒単位で設定し、
   前記始期日を含む画面を、前記業務員端末または前記顧客端末に提供する、
   保険基幹システム。

Images