Data 360 プロビジョニング

Salesforce Data 360は、Hyperforce上に構築されたデータ プラットフォームで、Salesforceと外部データを、すべての顧客またはアカウントの明確で完全、かつ信頼できる全方位的なビューに統合します。

合併や買収、地域の業務、職務の分離、または歴史的な理由により、多くの場合、企業は複数の Salesforce 組織を運営しています。アーキテクトは Data 360 に関するいくつかの決定を行う必要がありますが、これらはすべてガバナンス、コンプライアンス、コスト、レイテンシ、および AI と組織間プラットフォームの機能を拡張する組織の能力に影響します。

このガイドでは、Data 360 を使用してプロビジョニングに関する意思決定を行うためのフレームワークについて説明します。

• 単一ホーム組織と複数組織構成の選択

• 複数の独立した Data 360 インスタンスのプロビジョニング

  • Data Cloud One を使用して 1 つのインスタンスで組織を統合する

  • Data 360 組織間のデータ共有を使用する独立した Data 360 インスタンス間のコラボレーション

Data 360 は、Data 360 ライセンスを受け取る本番組織で自動的にプロビジョニングされます。Data Cloud One は、1 つのホーム組織で Data 360 インスタンスをホストし、他の Salesforce 組織はコンパニオン組織として接続できる Salesforce の複数組織接続アーキテクチャです。Data 360 ライセンスを保持し、Data 360 ホーム組織となる組織の選択は、長期的な影響を伴う重要なアーキテクチャ上の決定です。

Salesforce Data 360 のプロビジョニング方法は、アーキテクチャに関する基本的な決定事項です。これにより、企業がどのように顧客データを統合し、ガバナンスを適用し、重要なプラットフォーム機能(特にAI、Agentforce、組織全体の分析)を有効にするかが決まります。組織のクラスターを 1 つの Data 360 に固定することで、統合データモデル、一元化されたガバナンスが提供され、全社的な AI 対応が可能になります。コンパニオン組織は、データがローカルにあるかのように共有メタデータと機能にアクセスできます。一方、規制、コンプライアンス、自律性の要件によって一元化が妨げられる場合は、複数の独立した Data 360 インスタンスが適しています。Data 360 組織間のデータ共有により、これらのインスタンス間で選択的なゼロコピーコラボレーションが可能になります。

この決定は、データガバナンスを制御するユーザー、データが存在する場所、プラットフォーム機能の有効化方法、将来のインテグレーションと AI イニシアチブのスムーズな拡張に影響します。現在 Data 360 を使用していない組織でも、今後 Data 360 アクセスを追加する戦略を立てることで、アーキテクチャを将来にわたって保証することが重要です。営業担当、サービス担当、マーケティング、コマース担当、業種、および Agentforce 全体で Salesforce の機能が Data 360 上に構築されることが増えています。これらのプラットフォーム機能を使用する組織は、独自の Data 360 をプロビジョニングするか、共有の Data 360 をコンパニオン組織として接続する必要があります。

このガイドは、アーキテクトがシンプルさ、エンタープライズ全体の一貫性、コンプライアンス、拡張性のバランスを取るプロビジョニング戦略を設計するのに役立ちます。これにより、組織は自信を持って Data 360 を Customer 360、AI、クロスプラットフォームのイノベーションに活用できます。このガイドを使用して、Data 360 が必要な組織と、Data Cloud One を使用するか、Data 360 組織間でデータ共有を使用するかを判断します。この戦略により、Data 360 中心の未来に向けた強固な基盤が確立されます。

• **すべての組織は、Data 360インスタンスへのアクセスを計画する必要があります。**各組織は、Data 360 ホーム組織をホストするか、Data Cloud One を介して接続されたコンパニオン組織である必要があります。

• **組織ごとではなく、企業全体を考慮します。**単独で、事業ごとの意思決定は避けてください。理想的には、エンタープライズアーキテクチャまたはデータガバナンス協議会が、プロビジョニング戦略について共同で決定するべきです。広範な統合データセットに依存する将来の AI およびアナリティクスのニーズを常に予測してください。

• **ガバナンスとオーナーシップ / 所有権を早期に計画します。**Data 360 を一元管理するか (Center of Excellence モデル)、事業部門に委任するかを決定します。システム管理者、セキュリティチーム、コンプライアンスリードの役割を定義します。オーナーシップが不明瞭であると問題が発生する可能性があるため、あいまいさを避けてください。

• **プロビジョニングはライセンスに関連付けられています。**Data 360 ライセンスを購入した組織によって、Data 360 がプロビジョニングされる場所が決まり、その組織の場所によって地域が決まります。

• **データソースのサポートに関する考慮事項を理解します。**さまざまなパブリッククラウドおよびゼロコピーデータソースでサポートされるリージョンに注意してください。また、これらのデータソースへの接続にセキュリティ体制のプライベートコネクトが必要かどうか、および地域内接続と地域間接続のどちらがサポートされるかも判断します。

• **単一組織または複数組織のいずれを使用しているかに基づいてプロビジョニングします。**単一組織の顧客は、既存の本番組織で Data 360 をプロビジョニングして、最短で価値を実現できます。複数組織のユーザーの場合、作成する Data 360 インスタンスの数をできるだけ少なくして複雑さを最小限に抑えます。理想的なのは、Data Cloud One 設定を使用することです。

• 複数の Data 360 インスタンスは、必要な場合にのみ使用**してください。**複数のインスタンスは、コンプライアンス、レジデンシー、または組織の自律性によって必要とされる場合にのみ使用してください。このような場合は、Data 360 組織間のデータ共有を使用して安全なコラボレーションを実現します。

• **Data 360 組織間のデータ共有は、カスタム ETL パイプラインではなくコラボレーション用に設定します。**データ共有を介して特定のオブジェクト (DMO、計算済みインサイト、セグメント) を共有します。タグは共有されず、消費はソース組織に請求されます。

• **短期的なショートカットは避けてください。**長期計画なしで概念実証（POC）のために複数の Data 360 組織をスピンアップしないでください。パイロットと早期展開を企業全体のプロビジョニング戦略に合わせます。

すべてのプロビジョニングの選択肢（Data Cloud One、Data 360 組織間のデータ共有、またはホーム組織の指定）を、次の横断的な考慮事項に照らして評価します。

Data 360 プロビジョニングの決定が必要なメジャーユースケースは 3 つあります。

• Home 組織の選択
• 複数組織戦略の適用
• Data 360 組織間でのデータの共有

Data 360 ライセンスを購入すると、そのライセンスに関連付けられた Salesforce 組織に Data 360 インスタンスがプロビジョニングされます。この組織は Data 360 ホーム組織と呼ばれます。ホーム組織は Data 360 インスタンスのアンカーです。これには次の内容が含まれます。

• Data 360 ストレージおよびコンピューティングの管理 (プロビジョニング時に選択したリージョン)。

• 管理、ガバナンス、セキュリティポリシーの適用

• データの取り込み、ハーモナイゼーション、ID解決、セグメンテーション、有効化のパフォーマンス

マルチ組織のシナリオでは、ホーム組織で他の Salesforce 「コンパニオン」組織の中央 Data 360 インスタンスを管理します。

ホーム組織:

• Data 360 インスタンスの地理的位置を決定します。

• Data 360 インスタンスの所有者と管理者を決定します。Data 360 ホーム組織の管理者は、Data 360 に取り込まれたすべてのデータにアクセスできます。

• Data Cloud One 設定でコンパニオン組織の接続を制御します。

• 企業データ戦略の基盤を設定します。後で変更するのは難しく、混乱を伴います。

Data 360 ホーム組織についての詳細は、「Data 360 Integration Patterns and Practices」を参照してください。

最初の大きな決定は、既存の本番組織で Data 360 をプロビジョニングするか、ホーム組織として機能する新しい専用組織を作成するかです。

オプション A: 既存の組織での Data 360 のプロビジョニング

最適な用途: 1 つの Salesforce 組織を使用しているお客様、またはほとんどのビジネスプロセスを実行する主要な一元化された組織をすでに使用している複数組織のお客様。

• 長所:

  • 最もシンプルなパス: Data 360 は CRM データが存在する場所でプロビジョニングされます。

  • ローカルの営業、サービス、マーケティングデータにすぐにアクセスできます。

  • 追加のインテグレーションは必要ありません。

  • 管理するライセンスと環境が少ない。

  • 早期導入、パイロット、および本番ユースケースを加速します。

• 短所:

  • 既存の組織のガバナンスまたは技術的負債を継承できます。

  • 「メイン組織」が 1 つも存在しない場合、1 つを選択すると所有権に関する議論が生じる可能性があります。

  • パフォーマンスは組織の場所に依存します。企業全体のレジデンシーのニーズと一致しない場合があります。

  • 複数のビジネスユニットで異なる組織を使用している場合、ローカルプロビジョニングを Data Cloud One と組み合わせないと断片化が発生する可能性があります。

例:

1 つの Salesforce 組織を持つ SaaS 会社は、顧客のサブスクリプションデータとサポートデータを統合するために、その組織に Data 360 をプロビジョニングします。

オプション B: 新しい専用組織での Data 360 のプロビジョニング

最適な用途: 1つの主要な組織で連携できない複数のSalesforce組織を使用しているお客様、または強力なCenter of Excellence(CoE)モデルを使用している企業。

• 長所:

  • 継承された組織の複雑さがなく、ガバナンスがクリーンな状態から始められます。

  • 複数の事業分野にまたがる一元管理。

  • コンプライアンスのニーズに基づいて地域を柔軟に選択できます。

  • 1 つのビジネスユニットに縛られず、中立的な「共有サービス」組織として機能します。

  • 将来の Data Cloud One アーキテクチャ (複数のコンパニオン組織があるホーム組織) に合わせて設定します。

• 短所:

  • 顧客は、Data 360 をプロビジョニングする新しい Salesforce 組織のライセンスを取得する必要があります。

  • Data Cloud One コンパニオン接続を介して組織を Data 360 に接続するには、追加のインテグレーションが必要です。

  • 管理オーバーヘッド (ユーザー管理、セキュリティ、ID) を追加する場合があります。

  • 既存の本番組織（Production Org）のプロビジョニングと比較して、タイム トゥ バリューが遅い。

例:

ある多国籍金融サービス会社は、Data 360 をプロビジョニングするための専用のホーム組織を作成します。 すべてのビジネスユニット組織 (リテール、ウェルス、コマースバンキング) は、Data Cloud One を介してコンパニオン組織として接続します。

決定基準

原則として、既存のメジャー Org をホーム Org として使用することで、初期作業を最小限に抑え、導入の加速を図ります。長期的なガバナンスまたはコンプライアンス戦略上必要な場合にのみ、新しい専用のホーム Org を作成します。新しい専用のホーム組織を作成することは、Center of Excellence (COE) を使用する大規模企業にとって一般的な選択肢です。

単一組織環境

既存の本番組織で Data 360 をプロビジョニングします。これにより、シンプルさと即時の価値が最大化されます。不要なインテグレーションのオーバーヘッドを回避できます。

複数 Org 環境

ホーム組織として機能させるには、主要な組織 (通常はビジネスの大半を実行する組織、または一元化された CRM として機能する組織) を 1 つ選択します。これにより、複雑さが軽減され、設定作業を最小限に抑え、Data 360 の価値をすばやく実感できます。既存のメジャー Org を使用すると、新しい環境の管理にかかるコストとインテグレーション作業も回避できます。

新しい専用のホーム Org を検討する場合

ホーム組織を作成すると、柔軟性と中立性が確保されますが、タイム トゥ バリューは遅くなります。

• 組織に強力な Center of Excellence (CoE) があり、ビジネスユニット組織から独立したガバナンスが必要な場合。
• コンプライアンスや組織の制約のために適切な既存の組織が 1 つもない場合。

多くの場合、企業は複数の Salesforce 組織を運用していますが、これは特別なケースではなく、通常です。2024 年 2 月の時点で、約 19,000 人の Salesforce ユーザーがすでに複数の Salesforce 組織を運用しています。

なぜこのようなことが起こるのでしょうか？

• 買収および合併: 新しく買収された企業は、独自のSalesforceインスタンスを持ち込みます。
• **地域業務:**EU、北米、アジア太平洋など、多くの場合、データレジデンシー法を満たすために別々の組織を使用します。
• 機能の分離: Retail Banking、Wealth Management、Insuranceなど、さまざまなビジネスユニットが、自律性のために独自の組織を維持します。
• 規制またはセキュリティの分離: 特定の業界では、コンプライアンス上の理由で論理的に異なる組織に義務付けられています。
• 歴史的または技術的な理由: 時間の経過とともに、顧客は複数の組織を有機的に蓄積します。

それぞれの理由は個別に意味を持ちますが、それらが組み合わさってデータが断片化します。統合レイヤーを使用しない場合、各組織には顧客の部分的なビューのみが表示されます。

アーキテクチャの課題: コンプライアンス、ガバナンス、自律性の要件を尊重しながら、組織全体のデータを 1 つの情報源に統合する方法は?

Data Cloud One は、複数の Salesforce 組織で 1 つの Data 360 インスタンスを共有できる Salesforce の複数組織接続アーキテクチャです。これは、複数の Salesforce 組織を使用する企業に推奨されるパターンです。

Data Cloud One クラスターでは、Data 360 インスタンスをホストするホーム組織として 1 つの Salesforce 組織が指定されます。他の Salesforce 組織はコンパニオン組織として接続し、ホーム組織の Data 360 の統合データとメタデータを使用します。

Data Cloud One のしくみ

• データ取り込みと統合 (ホーム組織)

  • すべてのデータ取り込み設定 (Salesforce CRM、外部ソース、ストリーミング、バッチ) は、ホーム組織からのみ実行されます。

  • ホーム組織に関連付けられたData 360テナントは、ID解決、ハーモナイゼーション、モデリング、信頼できるお客様のプロファイルへの統合を実行します。

  • Data 360 の管理、ガバナンスポリシー、タギング、マスキングは、ホーム組織から一元的に適用されます。

• データスペースアーキテクチャ

  • ホーム組織からデータはデータスペースに整理され、データスペースはデータ、メタデータ、プロセスの論理コンテナとして機能します。

  • 企業は、ブランド、地域、または事業部門のデータスペースを作成できます。

  • データスペース共有: ホーム組織から、特定のデータスペースがコンパニオン組織と選択的に共有されます。これにより、関連するデータ (および関連付けられたメタデータ) のみが適切な組織に転送されます。

• メタデータ共有

  コンパニオン組織は、ホーム組織から、データモデルオブジェクト (DMO)、統合プロファイルスキーマ、計算済みインサイト、セグメントなどのメタデータ定義を受け取ります。これらは、ローカルアセットのようにコンパニオン組織内にネイティブに表示されますが、ホーム組織にリンクされています。

• ホーム組織とコンパニオン組織の機能 機能へのアクセスは、ホーム組織とコンパニオン組織で異なります。コンパニオン組織はデータの取り込みや統合ができず、取り込み、モデリング、統合はホーム組織に依存します。コンパニオン組織は Data 360 データにアクセスして Data 360 プラットフォーム機能を強化し、共有された信頼できるデータの上にローカルインサイト、セグメント、フローを作成できます。将来のビジョンでは、有効化機能にもアクセスできます。

• プラットフォーム機能パリティ ユーザーとビルダーの観点では、メタデータが共有されると、Salesforce Platform 機能の使用に関して自宅組織とコンパニオン組織でいくつかの機能の違いが生じます。サポートされている機能のリストは、「Data 360 Features on Companion org (コンパニオン組織の Data 360 機能)」を参照してください。

  • Salesforce Platformの機能(フロー、レポート、プロンプトビルダー、ダッシュボード、その他のプラットフォーム固有のツールなど)は、メタデータが使用可能になると、自宅組織とコンパニオン組織の両方で機能します。

  • Agentforce、見込み調査センター、Sales Cloud Einstein 機能、Service Cloud AI 機能などの Data 360 を活用した機能も、ホーム組織とコンパニオン組織の両方でシームレスに動作します。一部の機能は完全な互換性を達成するまでに時間がかかる可能性がありますが、全体的な目標は、Data 360 に依存するすべてのクロスクラウド機能について自宅組織とコンパニオン組織で同等の機能を実現することです。

• 消費モデル コンパニオン組織のすべてのアクティビティ(クエリ、セグメントの実行、Data 360トリガー フロー、AIの使用状況、Einstein Trust Layerのログ記録など)では、ホーム組織のData 360クレジットが使用されます。消費は一方向です。クレジットは一元化され、請求され、ホーム組織のクレジット割り当てに対して追跡されます。ただし、ドリル ダウンすると、各個人組織が Digital Wallet で使用したクレジット数を確認できます。

• 設計原則: 横方向の構築 Data 360 の水平構造は、主に Data Cloud One を介して実装される基本的な設計原則であり、1 つの Data Cloud インスタンスを複数の別々の Salesforce CRM 組織にまたがることができます。目標は、新しくリリースされたすべての機能が、追加の設定なしでホーム組織とコンパニオン組織の両方で動作することです。この機能により、Data Cloud One は単なるデータアーキテクチャの選択肢ではなく、今後の Salesforce Platform の基盤要素となります。

複数の組織を持つ企業は、エコシステム内で Data 360 を配置する方法と場所を選択する必要があります。各組織で独立した Data 360 組織をプロビジョニングするのか、Data Cloud One を使用して 1 つのホーム組織で組織を統合するのか?

オプション A: 複数の独立した Data 360 組織

各 Salesforce 組織は、独自の Data 360 インスタンスをプロビジョニングします。

長所:

• 自律性: 各ビジネスユニットまたは地域が独自の Data 360 を制御します。

• 各組織内のシンプル化: ガバナンス、セキュリティ、カスタマイズがローカライズされています。

• 法令順守: 厳格な規制の分離が必要な場合 (データが国境を越えてはならない場合など) に役立ちます。

短所:

• **データ サイロ:**組織間でプロファイルを統合することはできません。

• 高いコスト: インスタンスごとにライセンス、管理、インテグレーションが必要です。顧客は複数の異なる組織で同じソースデータを複数回取り込むことになります。

• 重複作業: IDの解決、セグメンテーション、強化を各Data 360インスタンスで繰り返す必要があります。

オプション B: 1 つの共有 Data 360 (Data Cloud One クラスタ)

1 つの Data 360 がホーム組織にプロビジョニングされ、他の Salesforce 組織がコンパニオン組織として接続されます。

長所:

• Single Source of Truth (SSOT): すべての組織で統合データモデルが共有されます。

• コスト効率: 1 つの Data 360 ライセンスとインフラストラクチャのみを管理します。

• 統合ガバナンス: ポリシー、セキュリティ、およびコンプライアンスの管理を一元的に適用します。

• 組織間強化: コンパニオン組織間でハーモナイズされたプロファイル、インサイト、セグメントにアクセスできます。

• AIの準備状況:エンタープライズ全体のデータセットにより、AIモデルのトレーニングと有効化を改善できます。

• **将来性:**新しいコンパニオン組織の追加は、新しいData 360組織を必要としないため簡単です。

短所:

• **追加の準備:**1 つの Data 360 では、組織間接続を計画する必要があります。

• レイテンシの考慮事項: さまざまな地域のコンパニオン組織ではクエリが遅くなる場合があります。

• 複雑なガバナンス: 組織ごとにカスタマイズのニーズが異なる場合、詳細なガバナンスが複雑になる可能性があります。

オプション C: 複数の Data Cloud One クラスタ

ガバナンス、コンプライアンス、その他のビジネス要件により、すべての組織をクラスター化することが現実的でない場合があります。そのため、企業が複数の Data 360 組織を運用し、それぞれが別のコンパニオン組織のクラスターのホーム組織であるハイブリッドソリューションを実装することが必要になる場合があります。

例:

ある多国籍企業では、ヨーロッパ、米国、アジアなど、さまざまな地域に Salesforce 組織があります。地域のデータレジデンシー規制に準拠するため、各地域ごとに 1 つの Data 360 をプロビジョニングします。

決定基準

推奨パターン: Data Cloud One

複数の組織にまたがるガバナンスを簡素化し、コストを最適化するには、接続されたコンパニオン組織と共に 1 つのホーム組織を使用します。

複数のData 360組織を使用する場合: コンプライアンス、レジデンシー、または組織の自律性によって厳密に必要とされる場合のみ、複数のData 360組織を使用します(規制のためにヨーロッパの業務を米国の業務から完全に分離する必要がある場合など)。

Data Cloud One でのホーム組織の選択方法: まず、主要な組織の 1 つ (通常はほとんどのビジネスが実行されている組織) を検討します。Data 360 をプロビジョニングすることで、複雑さを最小限に抑え、早期の価値を最大化できます。

適切な既存の組織がない場合にのみ、COE チームが管理する専用のホーム組織を作成することを検討してください。

一般原則:

マルチ組織環境では、Data 360 組織の数を最小限に抑えます。Data Cloud One をデフォルトパターンとして選択すると、重複が減り、AI の準備が有効になり、ガバナンスが簡素化されます。

Data Cloud One はほとんどの企業にとって推奨される方法ですが、次のような複数の Data 360 インスタンスをプロビジョニングする必要があるシナリオもあります。

• **地域のコンプライアンス。**ある多国籍リテーラーは、EU と米国にそれぞれ 1 つの Data 360 をプロビジョニングしています。Data 360-to-Data 360 データ共有により、ローカルデータからインサイトを作成し、そのインサイトを米国本社と共有できます。
• **ビジネスユニットのコラボレーション。**ある複合企業では、リテールと保険で別々の Data 360 組織を運営しています。Data 360 組織間のデータ共有により、ユーザーは移動やコピーを行うことなく、1 つの信頼できるデータソースにアクセスできます。Data 360 組織間のデータ共有により、保険組織はターゲットを絞ったクロスセルキャンペーン用にリテールの「価値の高い顧客」セグメントを受け取ります。
• **合併と買収。**親会社が、独自の Data 360 を持つ子会社を買収します。2 つのインスタンスを管理するにあたり、短期データサイロを維持することで、データセキュリティと SSOT の整合性が保たれます。同時に、2 つの Data 360 インスタンス間でデータを共有することで、移行中に必要なコラボレーションが可能になります。
• **フェデレーテッド・エグゼクティブダッシュボード。**複数の大陸にまたがる多国籍企業では、各リージョンごとに個々の Data 360 組織がプロビジョニングされます。エグゼクティブは、四半期ごとのパフォーマンスのフェデレーテッド・ビューを求めています。各リージョンの Data 360 は、集計された計算済みインサイトを「エグゼクティブ組織」と共有し、企業全体のレポートを可能にします。

複数の Data 360 組織が存在する場合、それらの統合は自動的には行われません。Data 360 to Data 360 データ共有により、重複やカスタムパイプラインなしで Data 360 インスタンス間で特定のオブジェクトを共有できます。これは、Data 360 組織全体でのコラボレーションのために設計されたゼロコピーメタデータ共有メカニズムです。

• 各 Data 360 は、独自のホーム組織でプロビジョニングされます。

• 管理者は、データ共有 (共有する特定のオブジェクトのグループ) を作成できます。

• 選択したデータへのアクセスは対象組織の Data 360 と共有され、オブジェクトはローカルで定義されたかのように表示されます。共有されるのはアクセス権のみで、基盤となるデータはソース Data 360 に残ります。

• タグは共有されません。使用できるのは未加工オブジェクトのみです。対象組織は、必要に応じてガバナンス、運用、AI タグを再適用する必要があります。

• Data Cloud One では、複数のコンパニオン組織が 1 つの Data 360 インスタンスを共有します。一貫性を確保するために、Agentforce、Prospecting Center、Tableau Nextなどのプラットフォーム機能は、同じ基礎データで実行されます。

• Data 360 組織間でデータ共有を使用する場合、各組織に独自の Data 360 があります。 組織 A と組織 B の Agentforce などの機能は、それぞれローカルインスタンスで独立して動作します。共有は自動的に行われません。特定のオブジェクトについてのみコラボレーションするには、意図的なデータ共有を作成する必要があります。

エンタープライズに複数の Data 360 組織がある場合

• カスタムパイプラインを作成したりデータを複製したりするのではなく、Data 360 組織間でデータ共有を使用してコラボレーションします。

• データ共有を作成して対象組織に付与することで、特定のオブジェクト (DMO、計算済みインサイト、セグメント) を共有します。

• タグは共有されません。受信組織は、ガバナンス、分類、AI 強化のためにタグを再適用する必要があります。

Data 360 組織間でのデータ共有の使用

• 一元化を妨げる規制要件を満たす。

• ビジネスユニットの自律性を維持しながら、選択的なコラボレーションを実現する。

• 複数のリージョンにわたって、フェデレーテッドなエグゼクティブダッシュボードを提供する。

• 統合がすぐには実現できない M&A シナリオの橋渡しをします。

慎重に設計してください

Data 360-to-Data 360 データ共有は、Data Cloud One の置き換えではなく、統合戦略として扱います。

• オブジェクト固有の共有を使用します。
• 共有しすぎないようにします。
• データ共有をビジネスおよびコンプライアンスのニーズに合わせます。

Data 360 プロビジョニングのデータ戦略を計画することは、組織ごとではなく、企業全体で取り組む必要がある重要な長期的なアーキテクチャ上の決定事項です。この初期の戦略的選択によって、顧客データの統合方法、ガバナンスの適用方法、およびプラットフォームの不可欠な機能 (特に AI と分析) の組織全体の拡張性が決まります。ガバナンスとオーナーシップのモデルを事前に計画し、断片化や複雑さの増大につながる短期的なショートカットを回避します。

Customer 360とは?

Data 360 インテグレーションのパターンとプラクティス

Data 360 アーキテクチャ

Data 360 セキュリティアーキテクチャ

著者について

Kunal Goyal は Salesforce の製品管理ディレクターで、Data 360 内のマルチ組織アーキテクチャと拡張性の向上に取り組んでいます。2017 年からは、組織間コラボレーションとマルチテナントシステム設計を中心に複数のイニシアチブと製品を率いています。Kunal は、Data 360 のベストプラクティスアーキテクチャリードの 1 人で、Data Cloud One、設定、プロビジョニング、管理エクスペリエンスのプロダクト所有者です。

Erin Wagner Tidwell は、Data 360 のプリンシパルテクニカルライター兼コンテンツデザイナーです。 2013 年から Salesforce に勤務し、明確で一貫性のある正確な技術ドキュメントとアプリケーション内コミュニケーションを通じて、Data 360 を理解しやすく、使いやすくすることに取り組んでいます。

Yugandhar Bora は、Salesforce のソフトウェアエンジニアリングアーキテクトで、データおよびインテリジェンスアプリケーションプラットフォーム内のデータアーキテクチャを専門としています。データガバナンスと統合データモデルに焦点を絞ったエンタープライズアーキテクチャレビューボード (EARB) イニシアチブを主導しながら、自動化プラットフォームプロビジョニングソリューションに貢献しています。

Samarpan Jain は、Commerce Cloud、プラットフォームインテグレーション、組織間アーキテクチャを専門とする Salesforce のプリンシパルアーキテクトです。Salesforce で最も勤続年数が長い従業員の 1 人で、政府機関の顧客向けのデータレジデンシーコンプライアンスや Data 360 利用状況属性システムなどの重要なイニシアチブを主導しています。