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

Abstract

【課題】保険の基幹システムに関して、保険会社毎に効率的な基幹業務を実現でき、開発及び運用等のコストが低くできる技術を提供する。【解決手段】保険基幹システムは、複数の保険会社及び複数の保険商品に関する基幹業務の情報処理を行い、保険会社の業務員端末または顧客端末から基幹業務に関する処理要求を受信する要求受信部と、処理要求に対応した業務機能により処理を実行する業務機能部と、ＤＢデータを管理するＤＢ部とを備える。業務機能部は、対象の保険会社及び保険商品に応じて、要素の組合せにより、業務機能の処理を構成する。要素は、複数の保険会社及び複数の保険商品で、共通の処理を行う共通機能要素と、一部が異なる処理を行う一部共通機能要素と、個別に異なる処理を行う個別機能要素と、を有する。ＤＢデータは、共通データ項目と個別データ項目とを有する。【選択図】図２

Description

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

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

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

保険の基幹システムに係わる先行技術例として、特開２００３−１０８７７０号公報（特許文献１）が挙げられる。特許文献１には、保険商品販売管理システムとして、保険契約申し込みに関して、金融機関で管理する顧客単位の顧客管理番号と保険会社で管理する契約単位の契約番号とを対応付けて記憶し、従来の管理体系を変更せずに管理を行う旨が記載されている。

特開２００３−１０８７７０号公報

複数の各々の保険会社は、サービス品質や顧客満足度の向上等のため、ダイレクト型の保険を含め、特徴的な様々な保険商品を開発及び販売する。各保険会社は、扱う保険商品の違い等により、基幹システムの業務機能やＤＢデータが異なる。保険の性質上、業務内容や扱う情報は複雑である。

各保険会社は、自社の各種の保険を顧客に販売する契約管理等を含む基幹業務を効率的に実現したい。顧客は、Ｗｅｂ等を通じて自分に合う保険を速やかに契約したい。保険会社毎に効率的な基幹業務を実現できる基幹システムが求められている。

各保険会社は、法的制度改定の場合も含め、保険の追加や変更等、保険商品の改定がよく発生する。保険商品の改定の際には、それに合わせ、基幹システムの業務機能やＤＢデータについても改修が必要になる。

しかし、従来、事業者は、保険会社毎に個別に最適化した基幹システムを開発及び運用している。各社の基幹システムは、業務機能のプログラムやＤＢデータ等の構成が異なり、自社単独利用が前提の実装となっている。事業者は、各社の改定等の要求に応じて、基幹システム毎に個別に改修の対応が必要であり、改修の度に構成が複雑になる傾向がある。

そのため、事業者は、各社の基幹システムの開発及び運用等のコストが高く、改修に長期間及び高コストを要する。頻繁な改定がある場合にも短期間及び低コストで改修の対応が可能な基幹システムが求められている。

本発明の目的は、保険の基幹システムに関して、複数の各々の保険会社毎に効率的な基幹業務を実現でき、開発及び運用等のコストが低く、改定の場合にも短期間及び低コストで改修の対応が可能な技術を提供することである。

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

一実施の形態の保険基幹システムは、保険会社の保険商品に関する基幹業務の情報処理を行う保険基幹システムであって、前記基幹業務は、複数の保険会社及び複数の保険商品に関する基幹業務を含み、前記保険会社の業務員端末または顧客端末から、前記基幹業務に関する処理要求を受信する要求受信部と、複数の業務機能を含み、前記処理要求に対応した前記業務機能により処理を実行して処理結果を応答する業務機能部と、前記業務機能の処理で読み書きするＤＢデータを管理するＤＢ部と、を備え、前記業務機能部は、前記業務機能の処理毎に、対象の前記保険会社及び前記保険商品に応じて、１つ以上の要素を呼び出し、当該要素の組合せにより、当該業務機能の処理を構成し、前記要素は、前記複数の保険会社及び前記複数の保険商品で共通である処理を行う共通機能要素と、前記複数の保険会社及び前記複数の保険商品で一部が共通、一部が個別に異なる処理を行い、当該一部が個別に異なる処理をパラメータで制御する、一部共通機能要素と、前記複数の保険会社及び前記複数の保険商品で個別に異なる処理を行う個別機能要素と、を有し、前記ＤＢデータは、前記複数の保険会社及び前記複数の保険商品で共通である共通データ項目と、前記複数の保険会社及び前記複数の保険商品で個別に異なる個別データ項目と、を有する。

本発明のうち代表的な実施の形態によれば、保険の基幹システムに関して、複数の各々の保険会社毎に効率的な基幹業務を実現でき、開発及び運用等のコストが低く、改定の場合にも短期間及び低コストで改修の対応が可能である。

本発明の一実施の形態の保険基幹システムを含む、保険システムの構成を示す図である。 本発明の一実施の形態の保険基幹システムの構成を示す図である。 一実施の形態における、システム設計概念を示す図である。 一実施の形態における、保険会社からみた基幹システムの構成、及び業務機能の構成例を示す図である。 一実施の形態における、保険会社からみた基幹システムの構成、及び業務機能やＤＢデータの構成例を示す図である。 一実施の形態における、個別設定情報の第１の構成例を示す図である。 一実施の形態における、個別設定情報の第２の構成例を示す図である。 一実施の形態における、保険基幹システムの画面例を示す図である。 一実施の形態における、業務機能の第１の処理例を示す図である。 一実施の形態における、業務機能の第２の処理例を示す図である。 一実施の形態における、商品改定に伴うシステム改修例を示す図である。

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

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

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

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

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

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

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

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

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

決済システム５は、決済サービスを提供するシステムであり、保険会社及び保険基幹システム１と連係する。顧客と保険会社との間で、保険料の払い込み方法に対応した決済手段として、クレジットカード、銀行、コンビニ等が挙げられる。決済システム５は、クレジットカード会社のシステム、銀行のシステム、コンビニのシステム等が挙げられる。決済システム５は、例えば顧客からの保険料払い込みを受け付ける。決済システム５は、決済処理として、顧客の口座から保険料払い込みの金額を出金し、保険会社の口座に保険料払い込みの金額を入金する。決済システム５は、その入金情報を含む決済情報を、保険基幹システム１に送信する。また、決済システム５は、例えば保険会社からの保険金支払いを受け付ける。決済システム５は、決済処理として、保険会社の口座から保険金支払いの金額を出金し、顧客の口座に保険金支払いの金額を入金する。決済システム５は、その出金情報を含む決済情報を、保険基幹システム１に送信する。

他連係システム６は、必須ではないが、保険契約に係わる所定の審査を行うシステムや、保険契約に係わる書類の発行や作成を行うシステム等が挙げられる。

保険基幹システム１は、Ｗｅｂサーバ部１１０、業務機能処理部１２０、ＤＢ部１３０を有する。

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

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

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

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

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

ＤＢ部１３０は、ストレージやＤＢサーバ等により構成され、基幹業務に係わる各種のＤＢデータを管理する。ＤＢ部１３０は、管理するＤＢデータとして、顧客情報１３１、契約情報１３２、見積申込情報１３３、決済情報１３４、事故情報１３５、保険対象情報１３０ａ、補償内容情報１３０ｂ、等がある。

［保険基幹システム］
図２は、保険基幹システム１の構成を示す。各保険会社は、保険基幹システム１を共同利用及び部分利用する。各保険会社は、業務員端末２から保険基幹システム１にアクセスし、自社の基幹システムとして利用する。保険基幹システム１は、複数の各々の保険会社及び顧客からのアクセスを受ける。複数の各々の保険会社は、販売する保険商品、必要な業務機能、及びＤＢデータ等において、共通の部分と個別に異なる部分とがある。

図２では、複数の保険会社の例として、保険会社Ａ，Ｂ，Ｃを示し、対応する業務員端末２Ａ，２Ｂ，２Ｃを示す。また、各保険会社の顧客の例として、顧客Ａ，Ｂ，Ｃを示し、対応する顧客端末３Ａ，３Ｂ，３Ｃを示す。

Ｗｅｂサーバ部１１０の画面提供部１１１は、各社の業務員端末３や顧客端末２からのアクセスに対し、アクセス元の保険会社や顧客に応じた内容として共通項目や個別項目を含む画面を提供する。共通項目は、各社で共通の業務等に関する項目であり、個別項目は、各社で個別の業務等に関する項目である。

業務機能部１２０は、業務機能１０、要素制御部２０、及び要素３０を有する。業務機能１０は、複数の業務機能を含む。複数の業務機能は、図２の例では、業務機能１１，１２，１３を示す。業務機能１１は、「見積り」処理を行う「業務機能＃１」である。業務機能１２は、「規定チェック」処理を行う「業務機能＃２」である。業務機能１３は、「保険料計算」処理を行う「業務機能＃３」である。「＃１」等は識別番号を示す。

業務機能１０は、Ｗｅｂサーバ部１１０を通じて呼び出され、処理要求を入力する。業務機能１０は、呼び出し元からの処理要求に基づいて、所定の情報を入力し、所定の処理を行い、処理結果情報を出力し、呼び出し元へ応答する。業務機能は、他の１つ以上の業務機能を呼び出して処理を行わせることができる。

要素制御部２０は、複数のコントローラを有する。コントローラは、業務機能毎に一対一で関係付けられた要素制御部である。コントローラは、業務機能のサービス処理を構成するために、要素３０における１つ以上の要素の組合せの制御処理を行う。コントローラは、１つ以上の要素を呼び出して、各要素に処理を行わせ、各要素の処理結果をまとめる。図２の例では、コントローラとして、業務機能１１のコントローラ２１、業務機能１２のコントローラ２２、業務機能１３のコントローラ２３を示す。

要素３０は、複数の要素を有する。要素３０は、大別して、共通機能要素３１、一部共通機能要素３２、個別機能要素３３を有する。共通機能要素３１は、共通機能を構成する要素であり、共通処理を行う。一部共通機能要素３２は、一部共通機能を構成する要素であり、一部共通処理を行う。個別機能要素３３は、個別機能を構成する要素であり、個別処理を行う。図２の例では、共通機能要素３１として、要素３１１，３１２を示し、一部共通機能要素３２として、要素３２１，３２２を示し、個別機能要素３３として、要素３３１，３３２を示す。

業務機能１０の例として、保険会社、保険種目、保険商品、保険始期日、保険満期日等を判定する各業務機能を有する。例えば保険種目判定を行う業務機能は、Ｗｅｂサーバ部１１０からの処理要求及びアクセス元の保険会社の情報等に応じて、その保険会社が扱う対象の保健種目、例えば自動車損保を判定し、自動車損保の業務機能を呼び出す。呼び出された自動車損保の業務機能は、その保険会社が扱う対象の保険始期日毎の自動車損保、例えば保険Ｘ１を判定し、その保険Ｘ１に対応した１つ以上の業務機能を呼び出す。呼び出された業務機能は、コントローラにより、自身のサービス処理を実現するための複数の要素の組合せを呼び出す。例えばある業務機能は、保険対象情報の処理を行う要素や、補償内容情報の処理を行う要素を呼び出す。各業務機能は、要素毎の処理結果に基づいた自身の処理結果情報を、呼び出し元の業務機能へ応答する。

ＤＢ部１３０は、複数のＤＢデータを含む。ＤＢデータの例は、図１の通りである。業務機能部１１０の要素３０は、要素毎に、ＤＢ部１３０の処理対象のＤＢデータにアクセスして読み書きを行う。

保険基幹システム１は、更に、管理部６０、個別設定情報７０を有する。管理部６０は、管理機能を実現し、保険基幹システム１の保守運用管理や設定等の処理を行う。管理者は、端末から管理部６０にアクセスする。管理部６０は、管理用のＷｅｂページを提供する。管理者の端末は、そのＷｅｂページによる管理用の画面を表示する。この画面は、保険基幹システム１の業務機能やＤＢデータの構成を表示する。管理者は、画面で、業務機能やＤＢデータに関する確認や設定の作業が可能である。管理者は、例えば保険会社の商品改定の際、依頼に基づいて、システム改修作業を行う。管理者は、保険の追加や削除、項目の変更等に合わせて、業務機能及びＤＢデータの内容の変更作業を行う。

個別設定情報７０は、保険会社毎に個別の設定情報である。管理者は、管理部６０を通じて、画面で、個別設定情報７０の内容の設定や確認が可能である。個別設定情報７０は、保険会社毎及び保険商品毎に、どの業務機能やＤＢデータを使用するか、どの要素の組合せを使用するか等が設定される。また、個別設定情報７０は、一部共通機能要素３２におけるパラメータ制御を用いた詳細処理の内容が設定可能である。コントローラは、個別設定情報７０の設定、及び対象の保険会社及び保険商品に応じて、要素の組合せをＯＮ／ＯＦＦで制御する。

［システム設計概念］
図３は、本実施の形態の保険基幹システム１における、システム設計概念を示す。まず、従来の基幹システムは、各社で個別に最適化された業務機能のソフトウェアの構成や、各社で個別のＤＢデータを有する構成である。

本実施の形態では、複数の保険会社の基幹システムにおいて、業務機能やＤＢデータに関して、各社や各保険で共通する、各社や各商品に依存しない部分と、各社や各保険で個別に異なる、各社や各商品に依存する部分とを整理及び分離する。

本実施の形態の保険基幹システム１は、複数の保険会社の基幹システムの業務機能に関して、各社や各保険で共通の機能と個別の機能とを整理及び分離し、共通業務機能及び個別業務機能として構成する。各社の業務機能の多くの部分は共通にでき、共通業務機能として構成される。各社及び各保険で共通にできない個別に異なる部分については、個別業務機能として構成される。共通業務機能は、各社や各保険で共通及び普遍的な業務機能である。個別業務機能は、各社や各保険で個別及び可変的な業務機能である。

本実施の形態の保険基幹システム１は、コンポーネント設計を採用し、業務機能をコンポーネントの組合せにより構成する。以下、コンポーネントを要素ともいう。要素は、共通機能要素３１、一部共通機能要素３２、個別機能要素３３に整理及び分離される。

保険基幹システム１は、各保険会社の業務員端末２や顧客端末３からのアクセスに対し、その保険会社や顧客に合わせた業務機能のサービス処理を、要素の組合せにより構成する。共通業務機能及び個別業務機能は、要求された都度、要素の組合せにより構成される。個別業務機能のサービス処理は、共通業務機能のサービス処理を経由して呼び出される。画面提供、上位の業務、下位の業務、ＤＢアクセス等のレイヤ毎に、業務機能は、共通、一部共通、個別の要素の組合せにより実装される。

共通機能要素３１に対応した共通機能は、共通アプリケーションにより実現され、その論理や計算式は、各社や各保険で共通に定められる。各社及び各保険で概ね共通の業務として、契約管理、決済管理、事故管理等がある。これらの業務に対応した業務機能は、主に共通機能により構成できる。共通機能は、保険種目判定等を行う上位の業務機能や、ＤＢデータアクセス論理を実装した業務機能等がある。共通機能は、共通のマスタ情報を管理する機能、共通の保険対象情報や補償内容情報を管理する機能等がある。

一部共通機能要素３２に対応した一部共通機能は、アプリケーションのパラメータ制御により実現される。各社や各保険で一部が共通、一部が個別に異なる場合に、一部共通機能を用いて実現できる。一部共通機能では、各社や各保険で、基本の論理やルールや計算式を共通とし、その論理等に対してパラメータとして与える値を可変とする。各社や各保険に応じて一部異なる固有の要件を、パラメータの値として個別に設定可能である。

各社及び各保険で一部が異なるデータとして、保険対象情報や補償内容情報があり、それらの情報を処理する業務がある。これらの業務に対応する業務機能を、一部共通機能により構成できる。保険対象として、例えば車両や建物等があり、補償内容として、例えば保険金額、支払日額、上限日数等がある。それらの情報は各社や各保険で差異がある。それらの差異は、一部共通機能のパラメータ、または個別機能により実装できる。また、それらの差異は、個別データ項目として管理できる。

一部共通機能は、例えば各社の保険に応じた規定チェックを行う機能がある。予め、複数の保険会社及び複数の保険に対応できる複数のチェック項目が用意される。一部共通機能は、パラメータ制御に応じて、対象の保険に該当するチェック項目のチェック処理を行う。また、一部共通機能は、各社の保険に応じた保険料計算を行う機能がある。予め、複数の保険会社及び複数の保険に対応できる計算式が用意される。一部共通機能は、パラメータ制御に応じて、計算式に対象の保険に応じた変数の値を入力して保険料を計算する。

規定チェック項目は、保険対象や補償内容に関する項目を含み、その他、割引に関する項目、等級に関する項目、事故有係数に関する項目、車両に関する項目、前契約情報に関する項目、等が挙げられる。

個別機能要素３３に対応した個別機能として、各社や各保険に依存して固有の部分、一部共通機能のパラメータ制御では実現できない要件については、個別機能を用いて実現できる。各社及び各保険に応じて個別の業務として、固有の保険対象や補償内容を持つ特徴的な保険に関する規定チェックや保険料計算を行う業務が挙げられる。これらの個別の業務は、個別機能により構成できる。

共通機能要素３１及び一部共通機能３２については各社に共通部品として提供される。一部共通機能３２のパラメータについては各社の個別設定情報７０の設定で制御可能である。個別機能要素３３については、各社に個別開発の個別部品として提供される。

また、本実施の形態の保険基幹システム１は、複数の保険会社の基幹システムのＤＢデータに関して、各社や各保険で共通のデータと個別のデータとを整理及び分離し、共通データ項目及び個別データ項目として構成する。

従来のＤＢデータは、各社で個別に最適化された、保険会社毎の複数のＤＢにおいて、重複するデータ項目があり、正規化されていない。例えば、見積情報と契約情報において、同一のデータ項目が重複して保持されている。重複するデータ項目は、各種のステータスやフラグを含む。

それに対し、本実施の形態の保険基幹システム１は、ＤＢ部１３０の複数のＤＢデータにおいて、重複するデータ項目を持たないように、正規化され、共通データ項目及び個別データ項目として構成される。共通データ項目は、各社や各保険で共通にできる、保険商品等に依存しないデータ項目である。契約管理等に係わる多くのデータ項目は、共通データ項目として一元管理される。

個別データ項目は、各社や各保険で個別に異なる、保険商品等に依存するデータ項目である。保険対象情報や補償内容情報は、保険商品毎に異なる情報であり、個別データ項目として管理できる。業務機能は、各社や各保険に応じた個別データ項目を参照する。

また、ＤＢ部１３０で管理するデータ項目の単位に合わせて、その単位に対するデータアクセス論理を実装した業務機能が設けられる。ＤＢデータとして例えば車両情報が管理される場合、業務機能として、車両情報を処理する業務機能と、車両情報にアクセスする業務機能とが設けられる。

上記業務機能及びＤＢデータの設計により、ＤＢデータの整合性が確保され、業務機能間及びＤＢデータ間での影響関係が小さくなり、システム改修が容易になる。

フロントエンドサービスについては、Ｗｅｂやコールセンタ等のチャネルが提供される。フロントエンドサービスの設計では、各社や各保険で個別の論理や、個別の画面ビューを含むグラフィカル・ユーザ・インタフェース等が構成される。事業者は、各社で個別にこの部分の開発またはカスタマイズを行う。

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

契約情報１３２は、保険種目毎及び保険商品毎に個別のデータ項目を含む表と、保険種目や保険商品に依らずに共通のデータ項目を含む表と、を有する。見積申込情報１３３は、顧客単位の保険の見積り及び契約申し込み等に関する管理情報である。契約情報１３２や見積申込情報１３３等は、従来とはデータ構造が異なり、属性毎に分離されている。

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

決済情報１３５は、保険料の入金情報や、保険金の出金情報、等の決済に関する管理情報である。事故情報１３６は、顧客単位の自動車事故等に関する管理情報である。

ＤＢ部１３０の共通データとして、その他、商品マスタ、住所マスタ等がある。商品マスタは、保険会社ＩＤ、代理店コード、保険種目、保険ＩＤ、商品名、等の情報を含む。ＤＢデータは、その他、コンタクト情報、フォロー情報、書類管理情報、等がある。

ＤＢ部１３０は、各社及び各保険で個別のデータとして、図１の保険対象情報１３０ａや補償内容情報１３０ｂを含み、これらは個別データ項目として構成できる。保険対象情報１３０ａや補償内容情報１３０ｂを処理する論理については、一部共通機能や個別機能により構成できる。例えば自動車損保や火災損保等の損保の場合、商品の差異として以下がある。まず、共通データ項目として構成できる項目としては、契約者情報、保険期間、払い込み方法等が挙げられる。これらを処理する論理は共通業務機能として構成できる。

保険対象情報１３０ａとしては、例えば自動車損保の場合、車両に関する事項として、車名、型式、初年度登録年月、ナンバー、車台番号、車検満了日、車両所有者、エアバッグ、使用目的、年間予定走行距離、等がある。また、火災損保の場合、対象または収容する建物、対象の所在地、構造、用法、構造級別、耐火基準、面積、建築年月、等がある。

補償内容情報１３０ｂとしては、例えば自動車損保の場合、保険種類毎の保険金額や免責金額、年齢条件、各種の特約、等がある。自動車損保の保険種類は、対人賠償、対物賠償、搭乗者傷害、人身傷害、車両保険等がある。補償内容情報としては、火災損保の場合、損害保険金、費用保険金、保険種類毎の保険金額、基本契約や地震契約、等がある。火災損保の保険種類は、建物、家財等がある。

保険対象情報１３０ａ及び補償内容情報１３０ｂは、各社や各保険に応じて様々に異なる場合がある。リスク細分型保険では、例えば等級や走行距離を用いて保険料を算定する。各社は、固有の項目を用いた特徴的な保険を提供する。保険基幹システム１は、各社の特徴的な保険の保険対象情報１３０ａ及び補償内容情報１３０ｂを、個別データ項目及び個別業務機能により管理する。

［保険会社の基幹システム］
図４及び図５は、保険基幹システム１を、１つの保険会社、例えば保険会社Ａからみた場合の基幹システムとしての構成を示す。図４は、特に業務機能の構成例を示す。本例では、保険会社Ａの業務員が、顧客からの依頼に応じて、業務員端末２Ａから保険基幹システム１にアクセスする場合を示す。なお、ダイレクト型の損保に関して、顧客が顧客端末３から直接的に保険基幹システム１にアクセスする場合も、図４と同様に可能である。保険会社Ａは、販売する保険商品として、保険Ｘ１，Ｘ２等を有する。業務員は、保険Ｘ１に関する契約の業務の際、業務員端末２Ａから保険基幹システム１にアクセスする。

Ｗｅｂサーバ部１１０は、インターネット７を通じて、業務員端末２Ａから保険会社Ａ及び保険Ｘ１に関するアクセスを受けると、保険会社Ａ及び保険Ｘ１に合わせた画面のためのＷｅｂページを送信する。業務員端末２Ａは、そのＷｅｂページによる画面を表示する。この画面は、各社で共通の業務メニュー項目を含む。業務員は、保険Ｘ１に関する見積りを行う場合、画面の業務メニュー項目の中から、「見積り」項目を選択する。Ｗｅｂサーバ部１１０は、保険会社Ａ及び保険Ｘ１に関する「見積り」項目に対応した、業務機能部１２０の業務機能１１へ、処理要求を送信する。

業務機能部１２０の「見積り」項目に対応した業務機能１１は、処理要求を受信し、「見積り」のサービス処理を行う。業務機能１１は、共通である所定の開始処理を行った後、コントローラ２１により、当該サービス処理を構成するための要素の組合せを呼び出す。コントローラ２１は、個別設定情報７０における保険会社Ａの保険Ｘ１に関する設定に基づいて、要素３０の各要素をＯＮ／ＯＦＦして、当該要素の組合せを呼び出す。本例では、コントローラ２１は、共通機能要素３１のうちの要素３１１、一部共通機能要素３２のうちの要素３２１、個別機能要素３３のうちの要素３３１を呼び出す。

要素３１１は、見積り依頼の共通機能における例えば前回見積り取得の共通機能を構成する要素である。要素３２１は、自動車損保の規定チェックを行う一部共通機能を構成する要素である。要素３３１は、保険Ｘ１の固有の規定チェックを行う個別機能を構成する要素である。要素３１１等により、共通業務機能が構成される。要素３２１及び要素３３１等により、保険会社Ａ及び保険Ｘ１に対応した個別業務機能が構成される。

共通機能要素３１は、他の要素の例として、Ｗｅｂページ画面を通じて見積りための情報を入力する要素や、Ｗｅｂページ画面へ見積り情報を出力する要素、等がある。一部共通機能要素３２は、他の要素の例として、他の保険種目の規定チェックを行う要素や、保険種目毎に保険料計算を行う要素等がある。個別機能要素３３は、他の要素の例として、他の保険の固有の規定チェックを行う要素や、他の保険の固有の保険料計算を行う要素等がある。

図５は、図４に続いて、業務機能やＤＢデータの構成例を示す。業務機能部１２０の業務機能は、要素毎及び対象ＤＢデータ毎に、データアクセス論理の業務機能を通じて、ＤＢ部１３０の対象ＤＢデータを読み書きする。ＤＢデータへのアクセスの際には排他制御処理が行われる。

要素３１１は、ＯＮの場合、各社で共通の処理として、見積り依頼における前回見積り取得処理を行う。要素３１１は、顧客情報１３１や見積申込情報１３３を参照し、対象の顧客の前回の見積り案のデータを取得する。なお、初回の見積りで前回の見積り案のデータが無い場合、要素３１１はＯＦＦにされる。

要素３２１は、ＯＮの場合、各自動車損保で一部共通の処理として、所定の複数のチェック項目における項目毎にチェック処理を行う。要素３２１は、個別設定情報７０の保険会社Ａの保険Ｘ１に関する設定に応じて、複数のチェック項目のうち、当該保険Ｘ１に該当する項目を適用（ＯＮ）、該当しない項目を非適用（ＯＦＦ）として切り替え、ＯＮの項目についてチェック処理を行う。要素３２１は、見積申込情報１３３を参照し、規定チェック処理を行い、規定チェック結果を保存する。規定チェック処理は、保険対象及び補償内容に係わる項目のチェック処理を含む。ＯＮのチェック項目は、対象の保険会社及び保険における保険対象情報や補償内容情報に応じて定まる。

要素３３１は、保険Ｘ１の固有の規定チェック処理として、例えば保険Ｘ１の保険料の計算に必要な変数の１つである変数ｙ１のチェック処理を行う。変数ｙ１は、保険対象や補償内容に係わる項目である。要素３３１は、見積申込情報１３３、保険対象情報１３０ａ、補償内容情報１３０ｂ等を参照して、変数ｙ１のチェック処理を行い、チェック処理結果を保存する。

他の要素の例として、一部共通機能要素３２における保険料計算を行う要素の場合、例えば自動車損保の保険料、またはその算定のための料率を、所定の論理や計算式で計算する。この計算式は、各社の自動車損保で共通であり、この計算式の変数には、各社の自動車損保毎の値が入力される。

［個別設定情報（１）］
図６は、個別設定情報７０の第１の構成例を示す。図６の個別設定情報７０は、保険会社、保険種目、及び保険商品毎の、一部共通機能及び個別機能に関する設定例を示す。共通機能についての設定例は省略する。図６の表は、列として、保険会社、保険種目、保険商品を含む。「保険会社」列は、保険会社ＩＤを示し、保険会社Ａ，Ｂ，Ｃの例を示す。「保険種目」列は、保険種目の例として「自動車損保」や「火災損保」の例を示す。「保険商品」列は、保険ＩＤを示し、保険Ｘ１，Ｘ２等の例を示す。また、図６の表は、列として、（ａ）一部共通規定チェック、（ｂ）個別規定チェック、（ｃ）一部共通保険料計算、（ｄ）個別保険料計算処理、を含む。（ａ）は、一部共通機能要素３２の例である第１の規定チェック処理を行う要素に関するＯＮ／ＯＦＦの設定を示す。同様に、（ｂ）は、個別機能要素３３の例である第２の規定チェック処理、（ｃ）は、一部共通機能要素３２の例である第１の保険料計算処理、（ｄ）は、個別機能要素３３の例である第２の保険料計算処理、に関する設定を示す。

本例では、保険会社Ａは、保険種目として「自動車損保」、「火災損保」等がある。その「自動車損保」の保険商品として、保険Ｘ１，Ｘ２等がある。保険Ｚ１は、商品改定時に追加される保険の例を示す。第１行の保険Ｘ１において、（ａ）の処理がＯＮ、（ｂ）の処理がＯＮ、（ｃ）の処理がＯＮ、（ｄ）の処理がＯＦＦである。（ａ）の処理では、図５のように保険Ｘ１に応じて必要なチェック項目をＯＮとした規定チェック処理が行われる。（ｂ）の処理では、図５のように保険Ｘ１に固有の変数ｙ１のチェック処理が行われる。（ｃ）の処理では、計算式として関数Ｆ１｛ｘ１，ｙ１｝を用いて保険料計算処理が行われる。変数ｘ１，ｙ１には、保険Ｘ１に応じた値が入力される。同様に、保険Ｘ２や他の保険種目の保険Ｘ３等についても、各要素の処理のＯＮ／ＯＦＦが設定される。

別の保険会社Ｂについて、「自動車損保」の保険商品として、保険Ｙ１，Ｙ２等がある。保険Ｙ１は、保険Ｘ１と同様に、（ａ）の処理がＯＮ、（ｂ）の処理がＯＦＦ、（ｃ）の処理がＯＮ、（ｄ）の処理がＯＦＦである。（ａ）の処理では、保険Ｙ１に応じた必要なチェック項目をＯＮとした規定チェック処理が行われる。（ｃ）の処理では、計算式として関数Ｆ１｛ｘ１，ｙ１｝を用いて保険料計算処理が行われる。変数ｘ１，ｙ１には、保険Ｙ１に応じた値が入力される。同様に、保険会社Ｃ等についても、各要素の処理のＯＮ／ＯＦＦが設定される。

商品改定で追加された「自動車損保」の保険Ｚ１は、（ａ）の処理がＯＮ、（ｂ）の処理がＯＮ、（ｃ）の処理がＯＦＦ、（ｄ）の処理がＯＮである。（ａ）の処理では、保険Ｚ１に応じた必要なチェック項目をＯＮとした規定チェック処理が行われる。また、（ｂ）の処理では、保険Ｚ１に固有のチェック項目のチェック処理、例えば固有の変数ｚ１のチェック処理が行われる。（ｄ）の処理では、計算式として関数Ｆ２｛ｘ１，ｙ１，ｚ１｝を用いて保険料計算処理が行われる。変数ｘ１，ｙ１，ｚ１には、保険Ｚ１に応じた値が入力される。関数Ｆ２は、関数Ｆ１に対して変数ｚ１が追加された固有の計算式である。

［個別設定情報（２）］
図７は、個別設定情報７０の第２の構成例を示す。図７の個別設定情報７０は、保険会社Ａの保険Ｘ１に関する「見積り」業務機能に関する、要素の組合せの定義情報を示す。図７の表は、列として、業務機能、要素、処理、詳細、適用を有する。「業務機能」列は、業務機能の識別情報を示し、図４の「見積り」に対応した「業務機能＃１」である業務機能１１等を示す。「要素」列は、要素の識別情報である要素ＩＤを示す。「処理」列は、要素が行う処理を示す。「詳細」列は、処理の詳細として、チェック項目や計算式を示す。「適用」列は、当該行の要素の処理を適用するか否かをＯＮ／ＯＦＦで示す。

第１行〜第１７行は、「見積り」の「業務機能＃１」に関する設定例である。第１行は、共通機能要素３１の例として、「共通＃１」である図４の要素３１１を示し、「前回見積り取得」処理を行う。要素３１１は「ＯＦＦ」に設定されている。第４行〜第９行は、一部共通機能要素３２の例として、「一部共通＃１」である図４の要素３２１を示し、「規定チェック」処理を行う。第４行〜第９行の「詳細」は、チェック項目として、「等級」、「事故件数」、「事故有件数」、「前年共済」、「保険金額上限」、「型式」、「仕様別」、「走行距離」等がある。例えば第４の項目である「前年共済」が「ＯＦＦ」に設定されている。

第１０行は、一部共通機能要素３２の例として、「一部共通＃２」である要素の例を示す。この要素は、「保険料計算」処理を行う要素であり、計算式として関数Ｆ１｛ｘ１，ｙ１｝であり、「ＯＮ」に設定されている。

第１３行は、個別機能要素３３の例として、「個別＃１」である図４の要素３３１の例を示す。この要素３３１は、「規定チェック」処理を行う要素であり、チェック項目として変数ｙ１であり、「ＯＮ」に設定されている。第１４行は、商品改定時の個別機能要素３３の追加の例を示し、「個別＃２」である要素の例を示す。この要素は、「規定チェック」処理を行う要素であり、チェック項目として変数ｚ１であり、「ＯＦＦ」に設定されている。第１５行は、商品改定時の個別機能要素３３の追加の例として、「個別＃３」である要素の例を示す。この要素は、「保険料計算」処理を行う要素であり、計算式として関数Ｆ２｛ｘ１，ｙ１，ｚ１｝であり、「ＯＦＦ」に設定されている。

［画面例］
図８は、保険基幹システム１によりユーザに提供する画面例を示す。図８は、（Ａ）〜（Ｃ）の画面がある。自動車損保の場合で、ユーザが保険会社の業務員である例を示す。

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

（Ｂ）の「見積・申込」項目画面で、「見積・申込」業務を構成する複数の項目がフローで表示される。（Ｂ）の例では、共通項目として、「顧客登録」、「見積り（見積り作成）」、「申込意思確認」、「決済」等の項目がある。業務員は、見積り作成を行う場合、（Ｂ）の画面で「見積り」項目を選択する。これにより、（Ｃ）の「見積り」項目画面へ移る。

（Ｃ）の「見積り」項目画面で、「見積り」業務を構成する複数の項目がフローで表示される。（Ｃ）の例では、共通項目として、「見積り依頼」、「見積り保存」等の項目がある。業務員は、見積り依頼を行う場合、（Ｃ）の画面で「見積り依頼」項目を選択する。これにより、「見積り依頼」に対応した業務機能の処理が実行され、その結果が画面に表示される。画面の項目毎に、業務機能が関係付けられている。

業務員は、画面で順に提示される項目や説明に従い、見積り等の契約管理の業務のために必要な情報を入力し、出力情報を確認する。保険基幹システム１は、画面を通じて入力された情報やＤＢデータを取得し、例えば見積り情報を作成し、見積申込情報１３３に保存し、画面に見積り情報を表示する。見積り情報は、保険対象や補償内容の情報を含む。業務員は、画面で、見積り情報の内容を確認し、続いて契約申し込みへ進む場合、（Ｂ）の画面で「申込意思確認」項目の選択により、「申込意思確認」項目画面へ移る。

［処理例（１）］
図９は、業務機能の処理例として、図８の「見積り」項目画面で、保険会社Ａの保険Ｘ１に関する「見積り依頼」項目が選択された場合の、業務機能１１による処理例を示す。「見積り」業務処理フローは、順に、「見積り依頼」業務処理、「見積り保存」業務処理を有する。「見積り依頼」業務処理は、図４の「見積り」に対応した「業務機能＃１」である業務機能１１のコントローラ２１により制御された「見積り」サービス処理として実現される。コントローラ２１は、「見積り」サービス処理において、規定の処理フローを実行する。規定の処理フローは、順にステップＳ１〜Ｓ４を有する。コントローラ２１は、規定の処理フローに従い、要素３０のうちステップ毎の処理に対応した要素を呼び出す。

コントローラ２１は、個別設定情報７０における保険会社Ａ及び保険Ｘ１に即したパラメータ設定に応じて、必要な要素やその詳細処理をＯＮ／ＯＦＦで制御する。処理対象に関係無い要素や詳細処理についてはＯＦＦにされ、動作しないので、業務機能間の影響が少なく、効率的である。

Ｓ１では、前回見積り取得処理が行われ、Ｓ２では、一部共通の規定チェック処理が行われ、Ｓ３では、個別の規定チェック処理が行われ、Ｓ４では、一部共通の保険料計算処理が行われる。

Ｓ１では、共通機能要素３１のうちの要素３１１を用いて、前回見積り取得処理が行われる。本例では、顧客が初回の見積りを行う場合とし、前回の見積り情報は無い。よって、コントローラ２１は、Ｓ１で、要素３１１をＯＦＦにする。

Ｓ２では、一部共通機能要素３２のうちの要素３２１を用いて、自動車損保の規定チェック処理が行われる。保険Ｘ１は自動車損保であるため、コントローラ２１は、要素３２１をＯＮとして呼び出す。コントローラ２１は、図６及び図７のような保険会社Ａの保険Ｘ１に関する個別設定情報７０の設定に基づいて、規定チェック処理の詳細を制御する。コントローラ２１は、複数のチェック項目のうち項目＃１〜＃３等をＯＮとし、項目＃４等をＯＦＦとし、ＯＮの項目についてチェック処理を行う。

Ｓ３では、個別機能要素３３のうちの要素３３１を用いて、保険Ｘ１に対応した個別の規定チェック処理が行われる。コントローラ２１は、個別設定情報７０に基づいて、要素３２２をＯＮとして呼び出す。要素３３１は、保険Ｘ１の保険料の見積りの計算のために必要な変数ｙ１に関するチェックまたは計算の処理を行う。変数ｙ１は、例えば、保険Ｘ１に固有の保険対象や補償内容の情報である。

Ｓ４では、一部共通機能要素３２のうちの要素３２２を用いて、保険Ｘ１に対応した保険料計算処理が行われる。コントローラ２１は、個別設定情報７０に基づいて、要素３２２をＯＮとして呼び出す。要素３２２は、計算式として関数Ｆ１｛ｘ１，ｙ１｝を用いて、保険Ｘ１の保険料を計算する。変数ｘ１は、各社、各保険で共通である。変数ｙ１は、各保険で異なる値が入力され、本例ではＳ３で得た保険Ｘ１に固有の値が入力される。

コントローラ２１は、図９の「見積り」サービス処理の結果、保険Ｘ１の見積りの保険料を含む情報を得る。業務機能１１は、所定の終了処理を行い、呼び出し元に応答する。次の「見積り保存」業務処理では、対応するコントローラにより、保険Ｘ１の見積りの保険料を含む見積り案情報を見積申込情報１３３内に保存する処理が制御される。

他の保険会社Ｂの保険Ｙ１の場合、例えば一部共通機能要素３２では、保険会社Ｂの保険Ｙ１に応じてＯＮにされたチェック項目のチェック処理が行われ、保険会社Ｂの保険Ｙ１に応じた変数の値を計算式に入力して保険料計算処理が行われる。

［処理例（２）］
図１０は、業務機能の別の処理例として、商品改定時に保険会社Ａの保険Ｚ１が追加された場合で「見積り依頼」項目が選択された場合の、業務機能１１による処理例を示す。保険Ｚ１は、保険Ｘ１と同様に自動車損保であるが、各社の自動車損保とは異なる固有の保険対象や補償内容を持つとする。

「見積り」業務処理フローの「見積り依頼」業務処理において、業務機能１１のコントローラ２１は、「見積り」サービス処理において、規定の処理フローを実行する。規定の処理フローは、順にステップＳ１１〜Ｓ１４を有する。コントローラ２１は、規定の処理フローに従い、要素３０のうち各ステップの処理に対応した要素を呼び出す。

Ｓ１１では、前回見積り取得処理が行われ、Ｓ１２では、一部共通の規定チェック処理が行われ、Ｓ１３では、個別の規定チェック処理が行われ、Ｓ１４では、個別の保険料計算処理が行われる。

Ｓ１１は、図９のＳ１と同様の処理である。Ｓ１２では、図９のＳ２と同様に、一部共通機能要素３２のうちの要素３２１を用いて、自動車損保の規定チェック処理が行われる。コントローラ２１は、要素３２１をＯＮとして呼び出し、保険Ｚ１に関する設定に応じて、規定チェック処理の詳細を制御する。

Ｓ１３では、個別機能要素３３のうちの要素３３２を用いて、保険Ｚ１に対応した個別の規定チェック処理が行われる。コントローラ２１は、個別設定情報７０に基づいて、要素３３２をＯＮとして呼び出す。要素３３２は、保険Ｚ１の保険料の見積りの計算のために必要な変数ｚ１に関するチェックまたは計算の処理を行う。変数ｚ１は、例えば、保険Ｚ１に固有の保険対象や補償内容の情報である。

Ｓ１４では、個別機能要素３３のうちの要素３３３を用いて、保険Ｚ１に対応した保険料計算処理が行われる。コントローラ２１は、個別設定情報７０に基づいて、要素３３３をＯＮとして呼び出す。要素３３３は、保険Ｚ１に固有の計算式として関数Ｆ２｛ｘ１，ｙ１，ｚ１｝を用いて、保険Ｚ１の保険料を計算する。変数ｚ１には、Ｓ１３で得た保険Ｚ１に固有の値が入力される。コントローラ２１は、図１０の「見積り」サービス処理の結果、保険Ｚ１の見積りの保険料を含む情報を得る。

［システム改修］
図１１は、商品改定に伴う保険基幹システム１の改修の例として、業務機能及び個別データを追加する例を示す。図１１の一点鎖線の左側に、改修前の保険基幹システム１の構成を示す。改修前の構成は、保険会社Ａの保険Ｘ１や保険会社Ｂの保険Ｙ１に関する「見積り」項目に対応する「業務機能＃１」である業務機能１１の例を示す。改修前の構成に対し、例えば保険会社Ａの保険Ｚ１が追加される。図１１の一点鎖線の右側に、改修後の構成で追加された部分として、保険Ｚ１の「見積り」項目に対応した業務機能等を示す。

改修前の構成において、業務機能１１のコントローラ２１は、保険会社Ａの保険Ｘ１に関する「見積り」項目が選択されると、所定の開始処理を行い、要素の組合せを制御する。まず、共通機能要素３１において、要素Ｃ１等を有する。要素Ｃ１は、各保険に依らない共通処理を行う。一部共通機能要素３２において、要素Ｃ２等を有する。要素Ｃ２は、各社の保険に応じた一部共通処理を行う。要素Ｃ２は、保険Ｘ１に関しては「処理＃２Ｘ」を行い、保険Ｙ１に関しては「処理＃２Ｙ」を行う。個別機能要素３３において、要素Ｃ３Ｘ，Ｃ３Ｙ等を有する。要素Ｃ３Ｘは、保険Ｘ１に対応した「処理＃３Ｘ」を行う。要素Ｃ３Ｙは、保険Ｙ１に対応した「処理＃３Ｙ」を行う。

ＤＢ部１３０は、ＤＢデータとして、共通データ項目１３０Ａ、個別データ項目１３０Ｂを有する。各要素は、共通データ項目１３０Ａや個別データ項目１３０Ｂを読み書きする。例えば要素Ｃ３Ｘは、保険Ｘ１に応じた個別データ項目１３０Ｂを読み書きする。

システム改修の前後において、個別設定情報７０に、保険Ｚ１に関する設定が追加される。共通機能３１には変更が無い。一部共通機能要素３２については、保険Ｚ１に対応した「処理＃２Ｚ」として規定チェック処理等が追加される。要素Ｃ２は、設定に基づいて、「処理＃２Ｚ」を行う。個別機能要素３３については、保険Ｚ１の保険料計算の「処理＃３Ｚ」を行う要素Ｃ３Ｚが追加される。また、ＤＢデータについては、保険Ｚ１の保険料計算のために必要な固有の保険対象や補償内容に関する個別データ項目１３０Ｃが追加されている。

従来の基幹システムでは、商品改定で例えば新規の保険が追加の場合、既存の業務機能の複数のプログラムに対し、追加の保険のための処理論理をｉｆ文で追加する等の対応が行われている。業務機能間の関係が複雑であるため、この対応は、改修箇所が多岐にわたり、高コストである。

一方、本実施の形態の保険基幹システム１は、コンポーネント設計等を採用しているため、図１１のように商品改定に伴うシステム改修の際、業務機能及びＤＢデータ間の影響関係が小さく、既存の業務機能及びＤＢデータの改修を最低限にできる。改修作業は、新規商品追加の場合、既存の業務機能やデータ項目で共通の部分をそのままとし、追加商品に固有の部分に対応した個別要素や個別データ項目の追加、一部共通機能要素のパラメータ変更等で済む。改修作業は、既存の商品の内容変更の場合、既存の業務機能やデータ項目の該当部分を削除または変更し、必要に応じて個別要素や個別データ項目の追加、一部共通機能要素のパラメータ変更等で済む。

即ち、本実施の形態は、従来よりも短期間及び低コストでシステム改修が可能である。本実施の形態は、各社が商品改定を行いたい場合に、保険基幹システム１のサービス稼動停止を最小限としながら、改定部分を速やかに反映することができる。各社は、顧客への特徴的な保険のサービスを速やかに開始できる。本実施の形態は、新規の保険会社の基幹システムの立ち上げや、既存の保険会社の基幹システムからの移行の場合にも、速やかに対応ができる。

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

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

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

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

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

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

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

他の基幹業務の例として、保険会社の業務員における保険契約成立後の保険金支払いの場合の概略的なワークフローは以下である。（１）事故連絡の受け付け、及び契約情報の確認、（２）保険金請求の説明、（３）請求に必要な書類の案内及び受け付け、（４）損害調査、（５）保険金支払い説明、（６）保険金支払い。

上記ワークフローは、複数の保険会社及び複数の保険で概ね共通である。保険基幹システム１は、上記共通の部分を、共通業務機能や共通データ項目により構成し、非共通の部分を、一部共通機能や個別機能、個別データ項目により構成する。

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

［効果等］
以上説明したように、本実施の形態の保険基幹システム１によれば、複数の各々の保険会社毎に効率的な基幹業務を実現でき、開発及び運用等のコストが低く、改定の場合にも短期間及び低コストで改修の対応が可能である。

本実施の形態の保険基幹システム１は、既存の業務機能やＤＢデータの構成を見直し、共通業務機能及び個別業務機能、共通データ項目及び個別データ項目として統合し、予め今後の商品改定に伴うシステム改修の効率化を想定したシステム設計を有する。また、本実施の形態の保険基幹システム１は、Ｗｅｂチャネルを通じたダイレクト型の保険の販売を含む、複数のチャネルに効率的に対応できるシステム設計を有する。

［他の実施の形態］
他の実施の形態の保険基幹システムとして、以下が挙げられる。他の実施の形態として、生保の基幹システムの場合にも同様に適用可能である。

他の実施の形態として、事業者による１つの保険基幹システム１の開発及び運用に基づいて、実装として保険会社毎にサーバシステム等を分離して構成し、保険会社毎に別々のサーバシステム等による基幹システムにアクセスして利用する形態も可能である。

他の実施の形態として、旧基幹システムと新基幹システムである保険基幹システム１との併用も可能である。保険基幹システム１のＷｅｂサーバ部１３０は、外部からアクセスを受けると、新旧のいずれのシステムや業務機能を利用するか判断し、判断に応じてアクセス先を分ける。Ｗｅｂサーバ部１３０は、アクセスが、例えば旧基幹システムのみで保持している非移行の保険の情報を参照する処理要求である場合、旧基幹システムへアクセスさせる。Ｗｅｂサーバ部１３０は、アクセスが、保険基幹システム１に移行済みの保険の情報に対する処理要求である場合、自身で当該アクセスを受領する。これにより、旧システムから新システムへの移行を効率的に実現できる。

以上、本発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されず、その要旨を逸脱しない範囲で種々変更可能である。

本発明は、保険分野のサービスに利用可能である。

１…保険基幹システム、２，２Ａ，２Ｂ，２Ｃ…業務員端末、３，３Ａ，３Ｂ，３Ｃ…顧客端末、４…業務員端末、５…決済システム、６…他連係システム、７…インターネット、８…電話網、１０，１１，１２，１３…業務機能、２０…要素制御部、２１，２２，２３…コントローラ、３０，３１１，３１２，３２１，３２２，３３１，３３２…要素、３１…共通機能要素、３２…一部共通機能要素、３３…個別機能要素、６０…管理部、７０…個別設定情報、１１０…Ｗｅｂサーバ部、１１１…画面提供部、１２０…業務機能部、１３０…ＤＢ部。

Claims (10)

1. 保険会社の保険商品に関する基幹業務の情報処理を行う保険基幹システムであって、
   前記基幹業務は、複数の保険会社及び複数の保険商品に関する基幹業務を含み、
   前記保険会社の業務員端末または顧客端末から、前記基幹業務に関する処理要求を受信する要求受信部と、
   複数の業務機能を含み、前記処理要求に対応した前記業務機能により処理を実行して処理結果を応答する業務機能部と、
   前記業務機能の処理で読み書きするＤＢデータを管理するＤＢ部と、
   を備え、
   前記業務機能部は、前記業務機能の処理毎に、対象の前記保険会社及び前記保険商品に応じて、１つ以上の要素を呼び出し、当該要素の組合せにより、当該業務機能の処理を構成し、
   前記要素は、
   前記複数の保険会社及び前記複数の保険商品で共通である処理を行う共通機能要素と、
   前記複数の保険会社及び前記複数の保険商品で一部が共通、一部が個別に異なる処理を行い、当該一部が個別に異なる処理についてはパラメータで制御される、一部共通機能要素と、
   前記複数の保険会社及び前記複数の保険商品で個別に異なる処理を行う個別機能要素と、
   を有し、
   前記ＤＢデータは、
   前記複数の保険会社及び前記複数の保険商品で共通である共通データ項目と、
   前記複数の保険会社及び前記複数の保険商品で個別に異なる個別データ項目と、
   を有する、保険基幹システム。
2. 請求項１記載の保険基幹システムにおいて、
   管理部を有し、
   前記管理部は、管理者の操作に基づいて、前記保険会社毎及び前記保険商品毎に個別に異なる前記業務機能及び前記ＤＢデータについての設定を個別設定情報に管理し、
   前記業務機能部は、前記個別設定情報に基づいて、前記対象の前記保険会社及び前記保険商品に応じて、前記業務機能の処理毎の前記要素の組合せを制御し、前記一部共通機能要素の前記パラメータを制御する、
   保険基幹システム。
3. 請求項１記載の保険基幹システムにおいて、
   前記要求受信部は、
   Ｗｅｂを通じて前記保険会社の業務員端末または前記顧客端末からの前記処理要求のアクセスを受けるＷｅｂサーバと、
   アクセス元の前記保険会社の業務員端末または前記顧客端末に応じた、業務メニュー項目を含むＷｅｂページ画面を提供する画面提供部と、
   を含む、保険基幹システム。
4. 請求項１記載の保険基幹システムにおいて、
   前記要求受信部は、
   電話を通じて顧客との応答を行うコールセンタの業務員端末から前記基幹業務に関する処理要求のアクセスを受けるＷｅｂサーバと、
   アクセス元の前記コールセンタの業務員端末に応じた、業務メニュー項目を含むＷｅｂページ画面を提供する画面提供部と、
   を含む、
   保険基幹システム。
5. 請求項１記載の保険基幹システムにおいて、
   前記ＤＢデータは、前記個別データ項目として、前記保険商品に係わる保険対象情報及び補償内容情報を含み、
   前記一部共通機能要素は、前記一部が個別に異なる処理として、前記保険対象情報または前記補償内容情報の処理を行い、
   前記個別機能要素は、前記個別に異なる処理として、前記保険対象情報または前記補償内容情報の処理を行う、
   保険基幹システム。
6. 請求項１記載の保険基幹システムにおいて、
   前記保険商品は、損害保険を含み、
   前記損害保険の保険種目は、自動車、火災、傷害、賠償責任を含む、
   保険基幹システム。
7. 請求項１記載の保険基幹システムにおいて、
   前記基幹業務は、契約管理、決済管理、及び事故管理を含む、
   保険基幹システム。
8. 請求項１記載の保険基幹システムにおいて、
   前記基幹業務は、契約管理を含み、
   前記契約管理は、顧客情報管理、保険見積り、契約申し込み、保険料払い込み入金、継続、異動の管理を含む、
   保険基幹システム。
9. 請求項１記載の保険基幹システムにおいて、
   前記一部共通機能要素は、前記保険商品の規定チェック処理を行う第１の要素を含み、
   前記個別機能要素は、前記保険商品の規定チェック処理を行う第２の要素を含み、
   前記第１の要素は、複数のチェック項目のうち、前記パラメータに基づいて前記対象の前記保険会社及び前記保険商品に応じたチェック項目のチェック処理を行い、
   前記第２の要素は、前記対象の前記保険会社及び前記保険商品に応じた固有のチェック項目のチェック処理を行う、
   保険基幹システム。
10. 請求項１記載の保険基幹システムにおいて、
    前記一部共通機能要素は、前記保険商品の保険料計算処理を行う第１の要素を含み、
    前記個別機能要素は、前記保険商品の保険料計算処理を行う第２の要素を含み、
    前記第１の要素は、第１の計算式において、前記パラメータに基づいて前記対象の前記保険会社及び前記保険商品に応じた変数の値を入力して保険料を計算し、
    前記第２の要素は、第２の計算式において、前記対象の前記保険会社及び前記保険商品に応じた固有の変数の値を入力して保険料を計算する、
    保険基幹システム。

Images