顧客/サプライヤー・データモデルの考察

顧客/サプライヤー・データモデルの考察
Trading Community Architecture を題材に
2021年6月24日
小野沢博文
DAMA日本支部データモデリング分科会

2 Copyright © 2021, Hirofumi Onozawa
Chief Customer Architect
Oracle Corporation
Speaker
Hirofumi Onozawa

顧客とサプライヤー、組織と個人、取引先の組織階層と従業員、関連企業等、商取引への参加者を統一的に表現
するデータモデルを、Trading Community Architecture(TCA) を題材に考察します。
TCAは、E-Business Suite や ERP Cloud、Sales Cloud といった Oracle の様々なアプリケーションで共通に採
用されているデータアーキテクチャですが、製品に関係なく議論できるように、本日はその背景にある課題認識と設計思想
を中心にお話します。
本日の主旨
Copyright © 2021, Hirofumi Onozawa
3

本日の主旨
1. Trading Community Architecture(TCA)とは
2. 従来のデータモデルの課題
3. 柔軟で拡張性の高いデータモデルとは
4. TCAのデータモデル
5. アプリケーションとデータモデルの関係
まとめ（Key Takeaways）
参考資料
目次
4

5
1. Trading Community Architecture(TCA)とは

• オラクルの様々なアプリケーションで共通に採用されている取引共同体(Trading Community)データアーキテクチャ
 顧客、サプライヤー、従業員とそれらの関係を表現・管理
 顧客とサプライヤー、法人と個人をバラバラに表現するのではなく、商取引への参加者として統一的に表現
 データモデル、データマネジメントのベストプラクティス、およびツール群（データ品質管理、データインポート、API
等）から構成される（本プレゼンテーションではデータモデルだけを扱う）
Trading Community Architecture(TCA)とは
6
Customer
Data Hub
CRM Service Financials Procurement SCM
Single Source of Truth(SSOT)
Trading Community Architecture
E-Business Suite (オンプレミス)
Customer
Data
Management
Sales Service Financials Procurement SCM
Single Source of Truth(SSOT)
Trading Community Architecture
Fusion Applications (SaaS)
共通の概念データモデル

7
2. 従来のデータモデルの課題

課題1: 取引関係内の役割の異なるプレイヤーを個別にモデル化
• 顧客とサプライヤー
 A社が顧客でありサプライヤーである場合、それぞれの間にリンクのない別々のエンティティとして表現
• あるいは異なるアプリケーションやデータベースで管理
 A社が顧客でありサプライヤーであるという情報が、担当者の暗黙知に留まり、企業内で活用されない
 A社の基礎情報は同一であるにもかかわらず、別々に入力されて管理される
• データ不整合の発生により迅速・正確な判断や取引先へのアプローチができない
従来のデータモデルの課題
8
販売システム
アプリケーション
A社
調達システム
A社
顧客情報サプライヤー情報
• A社が顧客でありサプライヤーであるという情報が社内で共有されない
あるいは属人的にしか共有されない
• A社の基礎情報を重複して入力・管理

課題2: 取引関係内の種類の異なるプレイヤーを個別にモデル化
• B2BとB2C
 B2Bモデルではしばしば個人を詳細に表現できない
• 例えば、取引先企業の役員をターゲットに富裕
層顧客を開拓したいが、役員の詳細情報がない
 B2Cモデルではしばしば組織階層を表現できない
• 例えば、ある企業のA支店をB2Cの大口顧客と
して獲得できたので、他の支店にも同様にアプ
ローチすべきだが、他支店の情報がない
 B2BとB2Cでアプリケーションを重複して開発・保守
 個人と組織の違いを正確に捉えて、両者をサポート
する必要がある
• 企業の場合、組織階層や会計情報等が必要
• 個人の場合、個人的関心や家族関係等も必要
9
法人顧客
役員
富裕層顧客の開拓のために役員
の個人的関心や家族関係を把
握したいが、B2Bモデルでは役職
と氏名ぐらいしか管理できない
A支店
(個人顧客として管理)
B支店
(個人顧客として管理)
A支店で大口取引があったので、他
の支店にもアプローチしたいが、B2C
モデルではA支店とB支店は無関係
の個人顧客として管理されており、
紐づけられていない
システム上は
関係を把握できない

課題3: 直接の取引先だけをモデル化
• サプライチェーン全体を把握できない
• 原材料調達→生産→流通→使用・維持→廃棄・リサイクルといったライフサイクル全体のカーボンフットプリントをトレー
スできない
→ 従来のデータモデルでは対応できないため、SCMやカーボンフットプリント等の目的ごとにデータモデルを導入
→ その結果、データがサイロ化
• パートナーの顧客や、顧客の顧客等の関係を把握できない
10
販売システム
顧客
調達システム
サプライヤー
顧客情報サプライヤー情報
原材料調達
SCMシステム
生産物流・流通販売
サプライチェーン参加者情報
原材料生産者サプライヤー物流事業者卸売事業者小売事業者
• 従来の販売システムや調達システムのデータモデルでは、サプライチェーン全体を把握できないため、
SCM専用のデータモデルを新たに導入
• その結果、データ・サイロがまた1つ増える

経営統合経営統合
課題4: 取引先の複数の関係の管理やバージョン管理ができない
• 取引先の関係についての異なるニーズに対応できない
 バックオフィス部門は、与信チェックや反社チェックのために取引先の資本関係を把握したい
 営業部門は、パートナーと顧客の商流を把握したい
• 過去の取引先の関係に遡ったデータ分析ができない
11
ABC
ホールディングス
バックオフィス部門のビュー
ABC銀行 ABC証券
ABC銀行
システムズ
ABC証券
システムズ
ABC
システムズ
資本関係
2021.5.31以前 2021.5.31以前
2021.6.1以降
営業部門のビュー
ABC銀行 ABC証券
ABC
システムズ
販売関係（商流）
パートナー
B社
資本関係資本関係
資本関係
パートナー
A社
ABC
ホールディングス
• 与信や反社チェックに
資本関係を利用 • エンドユーザまでの商流を把握したい
• 過去に遡って分析

12
3. 柔軟で拡張性の高いデータモデルとは

• 柔軟で拡張性の高いモデルが必要
 複雑で変化の激しい現実の取引関係を表現するためには、固定的な関係しか扱えないデータモデルやではなく、
柔軟で拡張性の高いデータモデルが必要
• 利用企業のポリシーや環境に適合できる柔軟性
• 新たなビジネスモデルや要件を追加できる拡張性
• 柔軟で拡張性の高いモデルとは
① 取引先エンティティと取引関係を分離
② 取引先エンティティと自社との関係だけでなく、自社が含まれていない取引先エンティティ間の関係も表現
③ 取引先に対する複数の関係を表現
④ B2BとB2Cのいずれにも対応
⑤ 取引関係や組織階層をバージョン管理
どのようなデータモデルが求められるのか
13

① 取引先エンティティと取引関係を分離
• 取引関係に参加する組織や個人を表現する取引先エンティティ（Party）と、自社との取引関係を分離
• 例えば、A社に商品を販売する場合、自社とは関係なく存在するA社に固有な属性はA社のPartyエンティティに格納
し、自社とA社の販売関係の情報は別のエンティティ（Customer Account）に格納する
• これにより、
 見込み客が顧客になった場合や、サプライヤーである企業に商品を販売した場合に、同一のPartyエンティティで
対応可能
 データモデルを変更することなく、新たな取引関係を表現することができる
 自社との取引関係を切り離して取引先の企業や個人を客観的に表現することができる
柔軟で拡張性の高いデータモデルとは
14
Party
自社との関係を切り離したA社の
Single Source of Truth
(SSOT)
見込み客
Opportunity
案件情報
Dun & Bradstreet
等のサードパーティデータ
の取り込み
Party
自社との関係を切り離したA社の
Single Source of Truth
(SSOT)
顧客
Opportunity
案件情報
Customer Account
販売関係情報
受注し、見込み客が
顧客に昇格

② 自社との関係だけでなく、自社が含まれていない取引先エンティティ間の関係も表現
• 例えば、自社とは直接取引のないサプライチェーン参加企業の化石燃料使用状況を把握することで、ライフサイクル全
体のカーボンフットプリントをモニターする
• 自社と取引関係のない子会社も含めて取引先企業の組織階層を把握する
• 顧客（パートナー）の顧客を把握することで、直接の取引関係はないが自社製品のエンドユーザを把握する
15
Party
ABCホールディングス
自社が含まれていない取引先エンティティ間の関係も表現
Party
ABC銀行
Party
ABC銀行システムズ
Party
ABC証券
Party
パートナーA社
資本関係
（組織階層）
販売関係
（商流）
自社
販売関係
（商流）
販売関係
（商流）

③ 取引先に対する複数の関係を表現
• 例えば、自社の複数部門が同一の取引先と異なる条件で取り引きしている場合
• あるいは、同一の取引先と商品やサービスによって異なる条件で取り引きしている場合
16
Party
顧客A社
Customer Account
取引条件X
Customer Account
取引条件Y
自社
X部門
Y部門

④ B2BとB2Cのいずれにも対応
• 法人顧客と個人顧客を統一的に扱いつつ、それぞれで管理すべき情報をきちんと管理する
• 法人（組織）固有の情報
 会計情報、組織階層、従業員（雇用関係）等々
• 個人固有の情報
 生年月日、個人的関心、家族関係等々
17
Party
Party
ABC銀行
Party
ABC証券
資本関係（組織階層）
Organization Profile
法人固有の情報
法人顧客
Party
鈴木太郎
雇用関係
個人顧客
Party
山田はな（母）
Party
山田二郎（本人）
Party
山田さつき（妹）
家族関係
Person Profile
個人固有の情報
Party
山田一郎（父）
Person Profile
Person Profile
Organization Profile
法人固有の情報
CEO

⑤ 取引関係や組織階層をバージョン管理
• バージョン管理によって、過去の取引関係や組織階層を把握、または予定されている変更をスケジュール
18
Party
ABC銀行
Party
ABC銀行システムズ
終了日: 2021.5.31
Party Relationship
終了日: 2021.5.31
Party
ABCシステムズ
開始日: 2021.6.1
Party
Party Relationship
開始日: 2021.6.1
Party Relationship

19
4. TCAのデータモデル

• Party
• Party Relationship
• Customer Account
• Supplier
• Party Site
TCA を構成する主要エンティティ
20

組織と個人を表すエンティティ
• 組織（法人顧客、持ち株会社、子会社、支店、部署等）、個人（個人顧客、従業員等）
• 共通する属性はPartyエンティティに格納し、固有の属性は、それぞれOrganization ProfileエンティティとPerson
Profileエンティティに格納する
 OR(Object-Relational)マッピングにおけるクラステーブル継承（または垂直分割）→ 次ページ参照
• 顧客、サプライヤー、従業員等の当該Partyエンティティの役割（用途）は、Party Usage Assignmentエンティ
ティに記述する
Party
21

PartyのサブタイプOrganizationとPersonをどのように表現するか
• David HayとLen SilverstonのPartyパターン
 組織と個人を統一的に扱うスーパータイプ
（汎化）としてPartyを導入
サブタイプ（特化）の表現方法
22
• リレーショナルモデルでサブタイプを表現するための
OR(Object-Relational)マッピング手法
 シングルテーブル継承（統合）
• 1つの汎用的なテーブルで全てのサブタイプを表現
• HibernateやRuby on Railsで採用
 クラステーブル継承（垂直分割）
• スーパータイプのテーブルに共通属性を格納し、サブタイ
プごとのテーブルにサブタイプ固有の属性を格納
• TCAで採用
 具象テーブル継承（水平分割）
• サブタイプごとのテーブルに各サブタイプを表現
参考資料
• HayとLenのPartyモデルについては、それぞれ巻末参考資料(1-1)と (1-2)を参照
• シングルテーブル継承、クラステーブル継承、具象テーブル継承については(1-3)を参照
• 統合、垂直分割、水平分割については(1-4)を参照

2つのParty間の関係を表すエンティティ
• 関係の型（Relationship Type）は事前定義
（seeded）またはユーザ定義
 事前定義の例: D&B階層、本社・部門、雇用
• 関係の型では、以下を定義
 関係付けられるPartyのタイプとロール
• 一方が主語（Subject）で
他方が目的語（Object）
• 例えば、雇用関係（鈴木太郎はABC銀行の従業
員）の場合、
主語のタイプはPerson、ロールはEmployee
目的語のタイプはOrganization、ロールは
Employer
 階層型または非階層型
 非階層型の場合、循環が許されるか許されないか
Party Relationship
23
Party (Organization)
ABC銀行
Relationship
relationship_type: Employment
Party (Person)
鈴木太郎
Relationship Type
relationship type: Employment
relationship phrase: Employee Of
subject type: Person
object type: Organization
Employer (目的語)
Employee (主語)

2つのParty間の関係を表すエンティティ
Party Relationship
24

自社と顧客との販売関係を表すエンティティ
• Party（顧客としての組織または個人）と分離して、自社と顧客との販売関係を表現
• 取引条件等に応じて、1つのPartyインスタンス（組織または個人）に対して任意個のCustomer Accountインス
タンスを持つことができる
• 取り引き関連の様々なエンティティがCustomer Accountエンティティに紐付く（以下のER図のエンティティは一例）
Customer Account
25

自社とサプライヤーとの調達関係を表すエンティティ
• Party（サプライヤーとしての組織）と分離して、自社とサプライヤーとの調達関係を表現
• 取引条件等に応じて、1つのPartyインスタンス（組織）に対して任意個のSupplierインスタンスを持つことができる
• 取り引き関連の様々なエンティティがSupplierエンティティに紐付く（以下のER図のエンティティは一例）
Supplier
26

Partyとその住所を紐付けるエンティティ
• Party（組織または個人）と住所を分離
• Partyは任意個のParty Siteを持つ
 例えば、本社の住所と部門の住所、請求先
（bill-to）住所と商品送付先（ship-to）
住所
• 住所情報はLocationエンティティに格納され、
Party Siteから参照される
 複数のPartyインスタンスが１つのLocation
インスタンスを共有することが可能
 例えば、本社と子会社が同じ住所に存在する
場合や、家族が同じ住所に居住する場合
• 販売や調達等の目的に応じて、Party Siteは
Customer Account SiteやSupplier Siteか
ら参照される
Party Site
27

28
5. アプリケーションとデータモデルの関係

業務視点でのデータ操作と疎結合
• 汎用性の高いデータモデルは柔軟性と拡張性に優れている反面、アプリケーション開発者にとって必ずしも分かり易い
ものではない
 データモデルパターンを使用している場合には抽象度と複雑性が増すため、難易度がさらに高くなる
 データモデルの理解をアプリケーション開発者に一律に求めると、開発生産性の低下を招く
• このため、TCA ではアプリケーション開発者が複雑なテーブル構成を意識せずに、顧客、販売、調達といった業務視
点でデータを操作できるように、ビューとAPIを提供している（注）
• 利用者側でSaaSの機能拡張が必要な場合には、パッケージ・アプリケーションのテーブルを直接操作する従来型の密
結合カスタマイズではなく、APIを通じた疎結合アドオンとして機能を追加することで、SaaSのライフサイクルとアドオン・
アプリケーションのライフサイクルを分離する必要がある
（注） TCA に限らず、E-Business Suite と Fusion Applications のほとんどのデータモデルに対してビューとAPIが提供されている
ビューとAPIの提供
29

業務視点でのデータ操作と疎結合
ビューとAPIの提供
30
Party
Customer Account Supplier
テーブル
ビュー
API
Customer Supplier
Customer Supplier
アドオン
アドオン
SaaS (Fusion Applications)
REST または SOAP
APIを通じた疎結合アドオンとして
SaaSの機能拡張を実装することで、
SaaSのライフサイクルとアドオン・アプリ
ケーションのライフサイクルを分離する
PaaS
顧客、販売、調達といった業務視点で
データを操作できるように、ビューとAPIを
提供
Financials
Cloud
Sales Cloud
Procurement
Cloud
疎結合

31

• 従来のデータモデルの課題
 取引関係内の役割の異なるプレイヤーを個別にモデル化
 取引関係内の種類の異なるプレイヤーを個別にモデル化
 直接の取引先だけをモデル化
 取引先の複数の関係の管理やバージョン管理ができない
• 柔軟で拡張性の高いモデルとは
 取引先エンティティと取引関係を分離
 取引先エンティティと自社との関係だけでなく、自社が含まれていない取引先エンティティ間の関係も表現
 取引先に対する複数の関係を表現
 B2BとB2Cのいずれにも対応
 取引関係や組織階層をバージョン管理
• TCAの主要エンティティ
 Party、Party Relationship、Customer Account、Supplier、Party Site
• アプリケーションの観点
 業務視点でのデータ操作と疎結合
32

(1) データモデル・パターン、アーキテクチャ・パターン関連
(1-1) David C. Hay, Data Model Patterns: Conventions of Thought, Dorset House Publishing, 1996
(1-2) Len Silverston, The Data Model Resource Book Vol. 1: A Library of Universal Data Models for All
Enterprises, Wiley, 2001
(1-3) Martin Fowler, Patterns of Enterprise Application Architecture, Addison-Wesley, 2002
(1-4) Dirk Slama, Jason Garbis, Perry Russell, Enterprise CORBA, Prentice Hall, 1999
参考資料
33

(2) TCA、Fusion Applications関連
(2-1) Oracle Trading Community Architecture, Modeling Customer and Prospect Data – TCA Best
Practices
http://www.rhaptech.com/doc/TCA_Best_Practices.pdf
(2-2) Best Practices to Model Prospects, Customers, Suppliers, Partners in an Oracle Fusion Cloud
Implementation
https://www.ateam-oracle.com/best-practices-to-model-prospects-customers-suppliers-partners-in-an-oracle-
fusion-cloud-implementation
(2-3) Best Practices to Model Customer, Supplier, and Partner Hierarchies in Oracle Fusion Cloud
https://www.ateam-oracle.com/best-practices-to-model-customer-supplier-and-partner-hierarchies-in-fusion-
applications
(2-4) Tables and Views for Oracle CX Sales and B2B Service
https://docs.oracle.com/en/cloud/saas/sales/21b/oedms/index.html
(2-5) Tables and Views for Oracle Financials Cloud
https://docs.oracle.com/en/cloud/saas/financials/21b/oedmf/index.html
(2-6) Tables and Views for Oracle Procurement Cloud
https://docs.oracle.com/en/cloud/saas/procurement/21b/oedmp/index.html
最新リリースおよび上記以外のアプリケーションのデータモデルとAPIは、以下のリンクからたどれます
https://docs.oracle.com/en/cloud/saas/index.html
参考資料
34

顧客/サプライヤー・データモデルの考察

顧客/サプライヤー・データモデルの考察

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to 顧客/サプライヤー・データモデルの考察

Similar to 顧客/サプライヤー・データモデルの考察 (20)

顧客/サプライヤー・データモデルの考察