保険データモデルについて知る
学習の目的
この単元を完了すると、次のことができるようになります。
- エンティティリレーションダイアグラムの表記について説明する。
- データモデルを確認する際の主な考慮事項を理解する。
前提条件
このモジュール始める前に、推奨される前提条件を検討して、学習に向けて万全の準備をしておきましょう。
推奨
次のモジュールを完了する
- Services Cloud のデータモデリング: オブジェクト、項目、リレーションを使用して、ファイナンシャルサービスデータを構造化する方法を理解します。
はじめに
保険会社の従業員は、エージェント、保険契約者、クライアントとその資産のために提供する補償内容を追跡する必要があり、多忙を極めています。保険業は保険をかけるべき対象があるため、複雑な事業です。何事においても、勝手な推測をすることも、当然のことと思い込むこともあってはなりません。実際、ビジネスのありとあらゆる側面を記録して追跡する必要があります。お金だけでなく、人の命そのものがかかっているからです。だからこそ、考え抜かれた包括的な保険データモデルが不可欠な成功要因となるのです。
保険データモデル
このモジュールでは、保険データモデルを使用することで、ビジネスに関連する重要な情報、および営業担当やサービス担当などの重要なユーザーの活動を追跡する能力を高める方法を学習します。
保険データモデルを使用すると、保険契約と請求の概要に関連するすべての情報を Salesforce に取り込めるため、保険契約者の全体像を把握することができます。このダイアグラムでは、保険契約者とエージェントがさまざまな理由で保険会社のコールセンターに問い合わせることあるため、顧客データは正確で包括的である必要があります。たとえば、見積の取得についてサポートが必要であったり、補償内容についての質問があったりすることがあります。Salesforce Customer 360 では、電話、テキスト、チャットなどによる保険契約者やエージェントからの問い合わせを解決するために必要なすべての情報がエージェントに提供されます。その舞台裏で、このすべてを可能にしているのが保険データモデルです。
Salesforce のパートナーや顧客との組み込みコラボレーションである保険データモデルには、データを整理する Salesforce の機能が標準装備されています。そのため、あらゆる規模の保険会社が、クライアント、営業担当、サービスエージェントとつながることができます。また、独立系の保険代理店やブローカーが顧客に代わって保険契約と請求を追跡する場合にも役立ちます。
データモデルは、いろいろな食品が保管されている巨大な食料棚に喩えることができます。データモデルの食料棚の特長は、あらゆる食材が整然と並んでいることです。そのため、何かが必要なときに、どこをどのように探せばよいのかわからないということがありません。だれもがこのような食料棚が欲しいと思うことでしょう。
保険データモデルが登場する前は、システム管理者は食料棚の整理に数か月の時間と膨大な IT リソースを注ぎ込まなければなりませんでした。活用できる標準的な手段がなく、似たようなデータアーキテクチャをゼロから手作業で作成するしかなかったためです。保険データモデルの登場により、システム管理者は従来の Salesforce のデプロイに要する時間の半分で立ち上げ実行できるようになりました。驚くべきことです。
保険データモデルについては、次の単元でさらに詳しく説明します。現時点では、このデータモデルでは、Salesforce の標準オブジェクトと保険の標準オブジェクトを使用して、あらゆる種類のつながりが追跡されるということを覚えておいてください。Salesforce ではこうしたつながりが整理され、追跡可能であるため、必要な情報を簡単に見つけることができます。
たとえば、特定の世帯に関連するすべての保険契約を統合したビューが必要だとします。保険データモデルを使用すると、このビューを簡単に作成できます。
それだけではありません。保険データモデルでは、クライアントの保険料支払履歴と保険契約に対して行われたすべての請求も追跡されます。車両保険の販売資格者全員を知りたいですか? 事故現場の目撃者に何が起こったか知りたいですか? 保険データモデルを使用すれば、このすべて、さらにはこれ以上のことも把握できます。
このモデルでは、標準のオブジェクトと項目が用意されていますが、異なるデータセット間のリレーションも定義できます。このモデルは画一的なデータモデルではありません。その代わり、柔軟性が高く、ビジネス要件に基づいて大小さまざまな企業を管理することができます。保険データモデルは複数のクラウドで実装できます。そのため、Financial Services Cloud と Health Cloud の両方で、同様の優れた柔軟なソリューションを利用することが可能です。
保険データモデルを一見すると、少し圧倒されてしまうかもしれません。そこで、デジタルトランスフォーメーションのジャーニーの最適化に取り組んでいる全米規模の保険会社、Cumulus Insurance のスタッフを追ってみましょう。
Cumulus Insurance は、グループ健康保険や自動車保険など、さまざまな保険を提供しています。商業保険会社であるため、Cumulus は Financial Services Cloud を使用してビジネスをサポートしています。これは、導入シナリオのほんの一例です。
エンティティリレーションダイアグラムの表記
エンティティリレーションダイアグラム (ERD) またはモデルとは、情報システムを目に見える形で表現したものです。ERD には、システム内の人、オブジェクト、場所、概念、イベント間のリレーションが示されています。このダイアグラムは論理モデルであり、必ずしも正確な基礎となるデータモデルを反映しているとは限りません。ERD では一貫した形状と表記が使用されます。それでは、いくつかのコアコンポーネントを定義しましょう。
エンティティ
このアイコンはエンティティを表します。
角が丸いボックスはダイアグラム内のエンティティを表します。エンティティボックスには、エンティティの 1 つ以上の属性をリストすることもできます。
サブタイプ
このアイコンはサブタイプを表します。
エンティティのサブタイプは、スーパータイプエンティティ内で表現されるその出現のサブセットです。サブタイプエンティティによって、各サブタイプに固有の属性とリレーションが定義されます。
1 回以上
このアイコンは 1 回以上の出現を表します。
クロウズフットは、分岐した端にある 1 つ以上のエンティティの出現が、もう一方の端にあるそれぞれの出現に関連する可能性があることを示します。
1 回のみ
このアイコンは 1 回のみの出現を表します。
一方の端にクロウズフットがない場合は、その端にある 1 回のみのエンティティの出現が、もう一方の端にある各エンティティの出現に関連する可能性があることを示します。
再帰的なリレーション
このアイコンは再帰的なリレーションを表します。
再帰的なリレーションとは、同じエンティティが 2 回出現した場合のリレーションです。あるエンティティとそのエンティティ自体を結ぶ曲線状のリレーション線は、再帰的なリレーションを表します。この線には、一方の端に「子である」ことを表すクロウズフットがあり、クロウズフットがない方の端は「親である」ことを意味します。
ユーザーとキーのリレーション
このアイコンはユーザーとキーのリレーションを表します。
リレーションのクロウズフットの端にある縦棒は、その側のエンティティのユーザープライマリキーに参加していることを意味します。ユーザーとキーの必須リレーションは、間違いなく最も強いリレーションです。
主な考慮事項
データモデルオブジェクトは、さまざまな方法で互いに関連付けられています。オブジェクトはデータを含むデータベーステーブルを表します。レコードは、次の例に示すように、オブジェクトやデータベーステーブルの行の特定の出現を表します。
| オブジェクト |
|
|---|---|
|
レコード 1 |
レコード 1 属性 |
|
レコード 2 |
レコード 2 属性 |
注意すべき重要な点は、すべてのシナリオですべての関連付けが必要なわけではないということです。ビジネスの規模、実行する操作、取り扱う商品やサービスの種類によって異なります。Cumulus のビジネスアーキテクトは、Cumulus に最適なオブジェクトの関連付けを選択することで、保険業務の柔軟性を確保できます。
アーキテクトは、データモデルに取り掛かる前にいくつかの点を検討します。
- 包括性: 保険契約には、保険契約者だけでなく、多くの関係者が存在します。保険契約では、交通事故の目撃者など、たまたまそこに居合わせた傍観者さえ、その対象になる可能性があります。つまり、データモデルはすべての保険シナリオに対応するものでなければならないということです。
- 360 度ビュー: Cumulus のエージェントは、ビジネスを組織的に成長させ、業務で成果を出すための方法を必要としています。データモデルは、エージェントが 360 度の角度から保険契約者情報を確認できるものである必要があります。そこから得られるインサイトによって、エージェントはアップセルとクロスセルの商談などを促進することができます。
- アジャイル: データモデルでは、人々がどのようにリスク補償に関わっているかについて、その複雑な方法が考慮される必要があります。場合によっては、クライアントがある資産には保険をかけたいが、他の資産にはかけたくないということがあります。すべての資産に保険がかけられている場合でも、特定の資産に対して、同じ保険契約で異なる種別の補償を希望する場合もあります。
- 顧客中心: 保険営業エージェントにとって、クライアントの人生における大切なイベントと結びつけて保険の勧誘を行えることほど、価値のあることはありません。まさに、これが Salesforce Insurance ソリューションに秘められた力です。このような機能を活用することで、クライアントのライフイベントの詳細をエージェントにシームレスに提供し、新規ビジネスの可能性を最大限に高めることができます。
重大なタスクが目の前にあることを認識した Cumulus は、Salesforce の保険データモデルの使用を開始するにあたり、優秀なコンサルタントである Justus Pardo に依頼しました。
Cumulus では、商品の背後にあるアーキテクチャがあまりに複雑で整理されていないため、現在使用している従来のシステムに新しい商品を適応させたり、提供したりすることに苦労しています。また、商品、保険契約、プロセスの作成と変更を行うために、大勢の開発者を必要としています。
Cumulus は、Justus がデータのクラスターを整理して、集約的に機能させることができると期待しています。また、この保険データモデルを使用すれば、Justus が Cumulus、営業エージェント、サービス担当の業務効率を最大限に高めることができると確信しています。ひょっとしたら、Cumulus が新しい業界リーダーになるかもしれません。
