SalesforceArchitectGroup#07_MDM_and_DataModeling

Transcript

1. マスターデータ管理とデータモデリング 認定 Data Architecture and Management デザイナー 2021/03/17（水） Salesforce Architects Meetup Osaka#07
2. 今回の対象： 認定 Data Architecture and Management デザイナー 本日の トピック 2
3. 今回の対象： 認定 Data Architecture and Management デザイナー http://tandc.salesforce.com/credentials 3
4. 認定 Data Architecture and Management デザイナー に求められるスキル・知識 4 Winter ’21 試験ガイドより
5. 試験範囲と出題割合 5
6. マスターデータ管理
7. マスターデータ管理(MDM)とは 7 [出典] https://www.talend.com/jp/resources/what-is-master-data-management/ • 一貫性のある「真の」最新データ(ゴールデンレコードとも言う)を常に使用し、 これに基づいて意思決定を行うプロセスのこと • 社内のあらゆるデータベースが利用すべき唯一絶対のデータのこと • データが溢れる現代のビジネス環境においては、MDMは最も複雑なビジネス の課題となることがある • さまざまなソースからデータを取り込み、検証済みのリアルタイム情報を提供 しなければならない • 異なるビジネスのシステムやプラットフォーム間でデータの共有を管理する • ノウハウ、ツール、戦略的パートナーシップの組み合わせが必要とされる
8. MDM はなぜ重要か 8 [出典] https://ladies-be-architects.com/study-group-xviii-master-data-management-with-vickie-jeffery-adrienne-cutcliffe • 信頼できる CRM 環境の提供に役立つから • 全体的なデータ品質の向上になるから • すべてのレコードの信頼できる唯一の情報源(Single Source of Truth)である から • データの単一ビューを可能にするから • レポートと分析のための正しいデータを提供するから
9. MDM がないと 9 データ品質の観点 • 複数の「真の」バージョンが存在してしまう • 複数のシステムとデータソースに散在する • データ重複となる • 各システムに渡って標準化されないデータとなる • 階層がなく意味あるまとまりにならない データガバナンスの観点 • データソースを決めるルールがない • 正しいバージョンを識別するためのルールがない • マッチングとマージのルールがない • 標準化のためのルールがない • 階層が定義されない [出典] https://ladies-be-architects.com/study-group-xviii-master-data-management-with-vickie-jeffery-adrienne-cutcliffe
10. とあるケース 10 基幹システム Sales Cloud 名刺管理 経理システム • どこがゴールデンレコードになるのでしょうか？ • どこからデータを入手する必要がありますか？ 東京商工リサーチ
11. 記録システム/信頼できる唯一の情報源 11 System of Record(SOR)/Single Source of Truth(SSOT) • 記録システムとは • 特定のデータ要素または情報の信頼できるデータソース • データオブジェクト全体またはデータオブジェクトの特定の属性が維持され るデータリポジトリ • 信頼できる唯一の情報源 • データオブジェクト全体の全体像を提供する信頼できるデータソース [出典] https://www.linkedin.com/pulse/difference-between-system-record-source-truth-santosh-kudva/
12. ビジネスプロセスで例示① 12 ビジネスプロセス [出典] https://www.linkedin.com/pulse/difference-between-system-record-source-truth-santosh-kudva/ 設計 製造 販売 出荷 記録システム 製品 ライフサイクル ERP CRM 出荷管理 属性 技術の属性 製品の属性 製造の属性 在庫の属性 構成の属性 価格の属性 物流の属性 梱包の属性 ビジネスプロセスのすべてのステップで、新しい属性を追加したり、既存の属 性を変更したりできる 単一のデータオブジェクトには、異なるシステムに格納された属性があり、ア イテムの全体像を提供する単一のシステムはない SOR≠SSOTの例
13. ビジネスプロセスで例示①解決策 13 [出典] https://www.linkedin.com/pulse/difference-between-system-record-source-truth-santosh-kudva/ 記録システム 製品 ライフサイクル ERP CRM 出荷管理 参照先システム BI データサイエンス データ統合 最良のオプションは、異なるアイテムの SOR からアイテム属性を収集して SSOT を作成すること SOR≠SSOTの例 信頼できる唯一の 情報源 アイテムマスタ
14. ビジネスプロセスで例示② 14 [出典] https://www.linkedin.com/pulse/difference-between-system-record-source-truth-santosh-kudva/ 製品 ライフサイクル 勘定科目表 CRM 出荷管理 ERP 勘定科目表は通常、小数のチームメンバーによって一元管理される データはすべての参照先システムやアプリケーションに公開される SOR＝SSOTの例
15. 信頼できる情報源が必要 15 ほとんどのユーザーは、複数のアプリケーションにまたがるビジネスプロセスに取 り組んでいるため、ビジネスユーザーからの期待は以下となる • すべての「信頼できる唯一の情報源」を明確に識別できること • すべての「信頼できる唯一の情報源」にアクセスするための単一のシステムがあ ること [出典] https://www.linkedin.com/pulse/difference-between-system-record-source-truth-santosh-kudva/
16. ガートナーの4つのアプローチを紹介 16 1. レジストリ型 • SOR が複数存在し、それらのデータを仮想統合したゴールデンレコードを マスターデータとする 2. 集約型 • 仮想統合ではなく、自らゴールデンレコードのデータベースを持つ • リアルタイムでのネットワークを確保する必要がある 3. 集権型 • SOR を各種システムが参照して利用する • データの更新はマスターデータを起点に行う 4. 共存型 • データベースを持ち、各システムからもマスターデータを変更できる方法 • 全社的なガバナンスの確立が前提条件となる • 利用ポリシーとプロセスを確立しておく [出典] https://www.sbbit.jp/article/cont1/35087
17. Salesforce での MDM 17 [出典] https://trailblazer.salesforce.com/sessions?eventId=a1Q4V00002DWxkY#/session/a2q4V0000032OhZQAU Customer 360 Truth 販売、サービス、マー ケティング、コマース などのデータを接続し て、顧客ごとに単一の ユニバーサル SalesforceID を作成
18. Customer 360 Truth 18 [出典] https://www.salesforce.com/news/press-releases/2019/11/19/salesforce-announces-customer-360-truth-a-single-source-of-truth-for-every-customer- across-the-worlds-1-crm-2/ • Customer 360 データマネージャ • 正規のデータモデルと各顧客を表すユニバーサルSalesforce IDを使用して、Salesforceおよ びその他のシステム全体で顧客のデータにアクセス、接続、および解決する機能を提供 • ※日本でのデータマネージャの各機能の提供時期および日本語での対応は未定 • 顧客のための Salesforce アイデンティティ • ログインエクスペリエンスの摩擦を取り除き、顧客と企業のすべてのWebサイト、eコマー スストア、モバイルアプリケーション、および接続された製品との間の単一の認証された安 全な関係を可能にする • Customer 360 オーディエンス • 電子メールアドレスやファーストパーティIDなどの既知のデータとWebサイトへのアクセス やデバイスIDなどの未知のデータにわたって統一された顧客プロファイルを構築 • プライバシーとデータガバナンス • 企業が顧客データの使用とプライバシー設定を収集して尊重し、Salesforceのすべてのデー タにデータ分類ラベルを適用できるようにする
19. MDM 統合 19 [出典] https://docs.mulesoft.com/jp/general/ MuleSoft Anypoint Platformを使用すると、アプリケーション、データ、または デバイスをアプリケーションネットワーク内の Customer 360 に接続する API を 簡単に構築して、真に完全な顧客ビューを作成できる、とある
20. データモデリング
21. Salesforce のデータモデル 21 [出典] https://developer.salesforce.com/docs/atlas.ja-jp.228.0.api.meta/api/data_model.htm SOAP API 開発者ガイド
22. Salesforce のデータモデル セールスアプリケーション 22 [出典] https://developer.salesforce.com/docs/atlas.ja-jp.228.0.api.meta/api/sforce_api_erd_majors.htm ER 図 オブジェクト 項目 リレーション カーディナリティ 自己参照 エンティティ アトリビュート(属性) リレーション カーディナリティ(多重度)
23. Salesforce のデータモデル プロファイルと権限 23 [出典] https://developer.salesforce.com/docs/atlas.ja-jp.228.0.api.meta/api/sforce_api_erd_majors.htm
24. ER 図のコネクタの理解 24 [出典] https://it-koala.com/entity-relationship-diagram-1897 1 ただ 1 つ 0 または 1 多 1 または多 0 または多 取引先 1件に対して、取引先責任者は 0件以上関連する 取引先責任者 1件に対して、取引先は 1件関連する 商談 1件に対して、見積は 0件以上関連する 見積 1件に対して、商談は必ず 1件のみ関連する IE (Information Engineering) 記法
25. 取引先と取引先責任者① 25 [出典] https://www.synergy-marketing.co.jp/cloud/synergylead/support/faq-what-is-person-account/ 個人取引先定義のレコードタイプで分けているだけなので、 通常の取引先：取引先責任者＝１：Nも入る 個人取引先 • 「取引先」を「取引先責任者」と同等に扱うことができる機能 • 個人取引先の場合「取引先＝取引先責任者」 • 使用用途として個人事業者や B to C • 有効化には Salesforce 社への連絡が必要
26. 取引先と取引先責任者② 26 [出典] https://www.terrasky.co.jp/blog/2016/160727_001724.php 取引先と取引先責任者の中間オブジェ クト 取引先責任者-to-複数取引先 • 個人と法人間のリレーションを作成できる機能 ユースケース • 個人が複数の会社で仕事をしているとき • ビジネス所有者が複数の会社を所有しているとき • コンサルタントが複数の組織の代理人を務めているとき
27. ER 図のツール 27 [出典] https://it-koala.com/entity-relationship-diagram-1897 • A5:SQL Mk-2 (フリー) • https://a5m2.mmatsubara.com/ • Cacoo (フリー) • https://cacoo.com/ja/ • astah* professional (有料) • https://astah.change-vision.com/ja/product/astah-professional.html