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

合併や買収、地域の業務、職務の分離、または歴史的な理由により、多くの場合、企業は複数の Salesforce 組織を運営しています。アーキテクトは、1 つの自宅組織と複数組織のどちらを設定するかだけでなく、複数の独立した Data 360 インスタンスをプロビジョニングするか、Data Cloud One を使用して 1 つのインスタンスで組織を統合するか、Data 360 間のデータ共有 (Data 360 と Data 360 のデータ共有) を使用して独立した Data 360 インスタンス間でコラボレーションするかも決定する必要があります。これらの選択は、ガバナンス、コンプライアンス、コスト、レイテンシ、および組織の AI および組織間プラットフォーム機能の拡張能力に影響します。

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 アクセスを追加する戦略を立てることで、アーキテクチャを将来に備えることが重要になる場合があります。Sales、Service、Marketing、Commerce、Industries、AgentforceにわたるSalesforceの機能は、Data 360上に構築されることが増えています。これらのプラットフォーム機能を使用する組織は、独自の Data 360 をプロビジョニングするか、共有の Data 360 にコンパニオン組織として接続する必要があります。

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

Data Cloud One と Data 360 組織間のデータ共有のどちらを選択するか、またはどの組織をホーム組織として指定するかなど、すべてのプロビジョニングの選択は、次の横断的な考慮事項に照らして評価する必要があります。

• プロビジョニングはライセンスに関連付けられます。Data 360 は Data 360 ライセンスを購入した組織にプロビジョニングされ、リージョンはプロビジョニング時のその組織のロケーションによって決まります。
• Data 360を今すぐ必要でなくても計画することで、選択肢をオープンにできます。後でAgentforceなどのプラットフォーム機能を強化するためにData 360を実装する場合、今すぐ下す決定によってそのプロセスをスムーズに進めることができます。
• 単一組織の顧客:既存の本番組織で Data 360 をプロビジョニングして、最短で価値を実現できます。
• 複数組織ユーザー:作成する Data 360 インスタンスの数をできるだけ少なくして複雑さを最小限に抑えます。理想的には、Data Cloud One 設定を使用します。
• 複数のData 360インスタンスは、コンプライアンス、レジデンシー、または組織の自律性によって必要とされる場合にのみ使用してください。このような場合は、Data 360 組織間のデータ共有を使用して安全なコラボレーションを実現します。
• コピー データ ソースなし：さまざまなパブリッククラウドおよび Zero Copy データソースでサポートされるリージョンに注意してください。また、これらのデータソースへの接続にセキュリティ体制のプライベートコネクトが必要かどうか、および地域内接続と地域間接続のどちらがサポートされるかも判断します。
• ガバナンスと自律性が中心となる概念です。Data 360を一元管理するか(Center of Excellenceモデル)、または個々の基幹業務で個別に管理される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 をプロビジョニングするか、新しい専用組織を作成してホーム組織として機能させるかです。

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

• 長所:

  • 最もシンプルなパス 360 は、CRM データがすでに存在する場所でプロビジョニングされます。
  • ローカルの営業、サービス、マーケティングデータにすぐにアクセスできます。
  • 追加のインテグレーションは必要ありません。
  • 管理するライセンスと環境が少ない。
  • 早期導入、パイロット、本番での使用事例を加速します。

• 短所:

  • 既存の組織のガバナンスまたは技術的負債を継承する可能性がある。
  • 「メイン組織」が 1 つも存在しない場合、1 つを選択すると所有権に関する議論が生じる可能性があります。
  • 組織の場所に関連するパフォーマンス。企業全体のレジデンシーのニーズと一致しない場合があります。
  • 複数のビジネスユニットで異なる組織を使用している場合、ローカルプロビジョニングを Data Cloud One と組み合わせないと断片化が発生する可能性があります。

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

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

• 長所:

  • 継承された組織の複雑さがなく、ガバナンスを一から構築できます。
  • 複数の基幹業務の一元管理。
  • コンプライアンスのニーズに基づいて地域を柔軟に選択できます。
  • 1 つのビジネスユニットに縛られず、中立的な「共有サービス」組織として機能します。
  • 将来の Data Cloud One アーキテクチャ (複数のコンパニオン組織がある自宅組織) に合わせて設定します。

• 短所:

  • 顧客は、Data 360 をプロビジョニングする新しい Salesforce 組織のライセンスを取得する必要があります。
  • Data Cloud One コンパニオン接続を介して組織を Data 360 に接続するには、追加のインテグレーションが必要です。
  • 管理オーバーヘッド (ユーザー管理、セキュリティ、ID) を追加する場合があります。
  • 既存の本番組織のプロビジョニングと比較して、タイム トゥ バリューが遅い。

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

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

単一組織環境

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

複数組織環境

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

新しい専用の自宅組織を検討するケース

組織に強力な 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 クラスターでは、1 つの Salesforce 組織が Data 360 インスタンスをホストするホーム組織として指定されます。他の Salesforce 組織はコンパニオン組織として接続し、ホーム組織の Data 360 の統合データとメタデータを使用します。

1. データ取り込みと統合 (自宅組織)
   
   • すべてのデータ取り込み設定 (Salesforce CRM、外部ソース、ストリーミング、バッチ) は、ホーム組織からのみ実行されます。
   • ホーム組織に関連付けられたData 360テナントは、ID解決、ハーモナイゼーション、モデリング、信頼できるCustomer 360プロファイルへの統合を実行します。
   • Data 360 の管理、ガバナンスポリシー、タギング、マスキングは、ホーム組織から一元的に適用されます。
2. データスペースアーキテクチャ
   
   • ホーム組織からデータはデータスペースに整理され、データスペースはデータ、メタデータ、プロセスの論理コンテナとして機能します。
   • 企業は、ブランド、地域、または事業部門のデータスペースを作成できます。
   • データスペース共有:ホーム組織では、特定のデータスペースがコンパニオン組織と選択的に共有されます。これにより、関連するデータ (および関連付けられたメタデータ) のみが適切な組織に転送されます。
3. メタデータ共有
   コンパニオン組織は、DMO(データ モデル オブジェクト)、統合プロファイル スキーマ、計算済みインサイト、セグメントなどのメタデータ定義をホーム組織から受け取ります。これらは、コンパニオン組織内ではローカルアセットのようにネイティブに表示されますが、実際にはホーム組織にリンクされています。
4. Jobs to Be Done in Home Orgg vs.コンパニオン組織
機能へのアクセスは、ホーム組織とコンパニオン組織で異なります。コンパニオン組織では、データの取り込みや統合ができず、取り込み、モデリング、統合はホーム組織に依存します。コンパニオン組織は Data 360 データにアクセスして Data 360 プラットフォーム機能を強化し、共有された信頼できるデータの上にローカルインサイト、セグメント、フローを作成できます。将来のビジョンでは、有効化機能にもアクセスできます。

機能	ホーム組織	コンパニオン組織
Connect 設定コネクタ、データストリームの作成、データの取り込みまたは統合	✅	❌
調和と統合 データ変換と ID 解決の構築および実行	✅	❌
データスペースと権限によるデータの保護のガバナンス	✅	✅
セグメントと予測 セグメント、インサイト、Einstein Studioモデルの構築	✅	✅
Activate Everywhere Activations、データアクション	✅	✅
プラットフォーム機能プロンプトビルダー、フロー、レポート、強化など	✅	✅
Data 360対応機能 Prospecting Center、Sales CloudおよびService Cloudの機能、Agentforceなど	✅	✅

5. プラットフォーム機能パリティ
   ユーザーとビルダーの観点では、メタデータが共有されると、Salesforce Platform 機能の使用に関してホーム組織とコンパニオン組織でいくつかの機能の違いが生じます。サポートされる機能のリストは、「Data 360 Features on Companion Orgs (コンパニオン組織の Data 360 機能)」を参照してください。
   
   • Salesforce Platformの機能(フロー、レポート、プロンプトビルダー、ダッシュボード、その他のプラットフォーム固有のツールなど)は、メタデータが使用可能になると、ホーム組織とコンパニオン組織の両方で機能します。
   • Agentforce、Prospecting Center、Sales Cloud Einstein機能、Service Cloud AI機能などのData 360を利用する機能も、自宅組織とコンパニオン組織の両方でシームレスに動作します。一部の機能は完全な互換性を達成するまでに時間がかかる可能性がありますが、全体的な目標は、Data 360 に依存するすべてのクロスクラウド機能について、ホーム組織とコンパニオン組織で同等の機能を実現することです。
6. 消費モデル
   すべてのコンパニオン組織のアクティビティ(クエリ、セグメントの実行、Data 360トリガー フロー、AIの使用状況、Einstein Trust Layerのログ記録など)では、ホーム組織のData 360クレジットが使用されます。消費は一方向に流れます。クレジットは一元化され、請求され、自宅組織のクレジット割り当てに対して追跡されます。ただし、ドリル ダウンすると、各個人組織が Digital Wallet で使用したクレジット数を確認できます。
7. 設計原則:横方向の構築
   Data Cloud One は、Sandbox によく似た Salesforce Platform の水平構造として設計されています。目標は、Salesforce がリリースするすべての新機能が、追加の設定なしで自宅組織とコンパニオン組織の両方で機能することです。これにより、Data Cloud One は単なるデータアーキテクチャの選択肢ではなく、今後の Salesforce Platform の基盤要素となります。

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

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

長所:

• 自治:各ビジネスユニットまたは地域が独自の Data 360 を制御します。
• 各組織内のシンプルさ:ガバナンス、セキュリティ、カスタマイズはローカライズされています。
• 法令順守:厳格な規制の分離が必要な場合 (データが国境を越えてはならない場合など) に便利です。

短所:

• **データ サイロ:**Customer 360 は組織全体で実現できません。
• コストの増加:各インスタンスには、ライセンス、管理、インテグレーションが必要です。顧客は、複数の異なる組織で完全な C360 ビューを実現するために、同じソースデータを複数回取り込むことになります。
• **重複作業:**各 Data 360 で ID 解決、セグメンテーション、強化を繰り返す必要があります。

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

長所:

• **SSOT(Single Source of Truth):**すべての組織で同じ統合データモデルを共有します。
• **コスト効率：**管理する Data 360 ライセンスとインフラストラクチャは 1 つのみです。
• **統合ガバナンス:**ポリシー、セキュリティ、およびコンプライアンス管理が一元的に適用されます。
• **組織間強化：**コンパニオン組織は、ハーモナイズプロファイル、インサイト、セグメントにアクセスできます。
• **AIの準備状況:**企業全体のデータセットにより、AI モデルのトレーニングと有効化を改善できます。
• **将来への対応:**新しいコンパニオン組織の追加は簡単で、新しい Data 360 は必要ありません。

短所:

• **追加の準備:**組織間接続の計画が必要です。
• **レイテンシに関する考慮事項:**異なる地域のコンパニオン組織では、クエリに時間がかかる場合があります。
• **複雑なガバナンス：**組織ごとにカスタマイズのニーズが大きく異なる場合、きめ細かなガバナンスが複雑になる可能性があります。

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

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

**優先パターン:**Data Cloud One

デフォルトでは、複数組織企業の接続されたコンパニオン組織を含む 1 つの自宅組織になります。
これにより、企業全体のCustomer 360が作成され、ガバナンスがシンプルになり、コストが最適化されます。

複数の Data 360 を使用する場合:

コンプライアンス、レジデンシー、または組織の自主性によって厳密に要求される場合のみ。たとえば、規制のためにヨーロッパの業務を米国の業務から完全に分離する必要がある場合などです。

Data Cloud One でホーム組織を選択する方法:

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

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

一般原則:

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

Data Cloud One はほとんどの企業にとって推奨される方法ですが、複数の 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 などの機能は、それぞれローカル インスタンスで独立して動作します。共有は自動的に行われません。特定のオブジェクトに対してのみコラボレーションするには、意図的なデータ共有を作成する必要があります。

地域のコンプライアンス：
ある多国籍小売業者は、EU と米国の 1 つの Data 360 をプロビジョニングしています。Data 360-to-Data 360 データ共有では、未加工データをローカルに残したまま、米国��社と共有するためのインサイト (ロイヤルティ KPI など) を集計できます。

ビジネス・ユニットのコラボレーション：
ある複合企業が小売と保険で別々の Data 360 を実行しているとします。Data 360 間のデータ共有により、ユーザーは移動やコピーを行うことなく、1 つの信頼できるデータソースにアクセスできます。Data 360 組織間のデータ共有により、保険組織は対象を絞ったクロスセルキャンペーンで小売の「High Value Customer」セグメントを受け取ります。

M&A:
親会社が独自の Data 360 を持つ子会社を買収します。2 つのインスタンスを管理する場合、短期のデータサイロを保持することで、データセキュリティと SSOT の整合性が維持されます。同時に、2 つの Data 360 インスタンス間でデータを共有することで、移行中に必要なコラボレーションが可能になります。

統合エグゼクティブ・ダッシュボード：
大陸にまたがる多国籍の広がりでは、地域ごとに個々の Data 360 がプロビジョニングされます。エグゼクティブは、四半期パフォーマンスの統合ビューを求めています。各地域の Data 360 は、集計された計算済みインサイトを「エグゼクティブ組織」と共有し、企業全体のレポートを可能にします。

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

• カスタムパイプラインを作成したりデータを複製したりするのではなく、Data 360 組織間でデータ共有を使用してコラボレーションします。
• データ共有を作成して対象組織に付与することで、特定のオブジェクト (DMO、計算済みインサイト、セグメント) を共有します。
• タグは共有されないことに注意してください。受け取り側組織はタグ (ガバナンス、分類、AI 強化など) を再適用する必要があります。

Data 360 組織間のデータ共有を使用する場合:

• 一元化を妨げる規制要件を満たす。
• ビジネスユニットの自律性を維持しながら、選択的なコラボレーションを実現する。
• 複数の地域で統合エグゼクティブダッシュボードを提供する。
• 統合がすぐには実現できない M&A シナリオの橋渡しをします。

慎重に設計

共有は意図的でオブジェクト固有である必要があります。「過剰な共有」を避ける — データ共有をビジネスとコンプライアンスのニーズに合わせます。Data 360-to-Data 360 データ共有は、 Data Cloud One の代替戦略としてではなく、統合戦略として扱います。

1. すべての組織が Data 360 へのアクセスを計画する必要がある
   
   • 今後、Sales Cloud、Service Cloud、Agentforceなど、Salesforce Platformのすべての機能にData 360接続が必要になります。各組織は、Data 360 ホーム組織をホストするか、Data Cloud One を介して接続されたコンパニオン組織である必要があります。
2. 組織ごとではなく、企業全体で考える
   
   • 単独での一方的な部門別意思決定は避けます。
   • プロビジョニングは、エンタープライズアーキテクチャまたはデータガバナンス協議会でまとめて決定することをお勧めします。広範な統合データセットに依存する将来の AI および分析のニーズを常に予測します。
3. データサイロの最小化
   
   • 既存のメジャー組織で Data 360 をプロビジョニングすると、シンプルかつ迅速になります。
   • マルチ組織環境では、Data Cloud One が 1 つの Data 360 の下に組織を統合するデフォルトのパターンです。
   • コンプライアンス、レジデンシー、または組織の自律性のために厳密に必要とされる場合にのみ、複数の Data 360 をプロビジョニングします。
4. 複数の Data 360 を実行する必要がある場合は慎重に設計してください
   
   • カスタム ETL パイプラインではなく、コラボレーション用に Data 360 組織間のデータ共有を設定します。
   • データ共有を介して特定のオブジェクト (DMO、計算済みインサイト、セグメント) を共有します。
   • タグは共有されず、消費はソース組織に請求されます。
5. ガバナンスと所有権を早期に計画する
   
   • Data 360 を一元管理するか (Center of Excellence モデル)、基幹業務に委任するかを決定します。管理者、セキュリティチーム、コンプライアンスリードの役割を定義します。
   • あいまいさを避ける: 所有者が不明瞭であることがよくある摩擦の原因です。
6. 短期的なショートカットの回避
   
   • 長期計画なしで POC 用に複数の Data 360 をスピンアップしないでください。後で統合作業が中断されます。
   • 代わりに、パイロットと早期リリースを企業全体のプロビジョニング戦略に合わせます。

Salesforce Platform は、顧客セグメンテーションから AI エージェントのグラウンディングまで、すべての機能がデータ 360 ファーストモデルに依存するように進化しているため、これらのプロビジョニングの選択は非常に重要です。今日の意思決定により、企業が顧客データをどの程度効果的に統合できるか、新しい Salesforce 機能をどの程度迅速に採用できるか、ビジネス全体で AI をどの程度自信を持って拡張できるかの基盤が構築されます。成功するためには、慎重にプロビジョニングし、重複を最小限に抑え、コンプライアンス要件に準拠し、慎重に管理し、長期的な視点で考える必要があります。最終的に、Data 360 のプロビジョニングは、データ、AI、CRM を 1 つの統合されたプラットフォームとして連携させるための最初のステップです。

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

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