完全シミュレーションされた EDW 5 つ — Amazing(オムニチャネル Eコマース)、Hilson(グローバルホテルグループ)、P&C(CPG 製造)、HKBC(香港ユニバーサルバンク)、AYA(香港コンポジット保険) — 現実的なベンダーネイティブスキーマ、ClickHouse のメダリオン対応ブロンズ、ライブイベントストリーム。VibeBI でセマンティックレイヤ、ディメンショナルモデリング、セルフサービス分析を試すために作られています。
架空企業に関する注記: 「Amazing」はデモ専用の完全な架空企業です。Amazon.com, Inc. や実在の企業と提携・後援・代理するものではありません。
Amazing はグローバルなオムニチャネル小売業者で、自社在庫、第三者セラーのマーケットプレイス、Prime サブスクリプションを通じて数千万の商品を販売します。顧客は Web ストア、モバイルアプリ、実店舗で買い物し、注文は世界のフルフィルメントセンターとドロップシップ供給網から履行されます。
事業は消費者向けコマースに加え、広告、金融サービス、B2B 卸売部門にまたがります。典型的な平日で約 2,800 の注文ヘッダーと 4,200 明細を生成し、 Prime Day 需要急増(7月11〜13日)が、小売、Web、マーケティング、マーケットプレイスチャネルに及びます。
サンプルエンティティ: 下表は代表的な事業エンティティとソースシステムです。完全な EDW には追加エンティティ、サブタイプ、専用テーブル(例:返品、サブスクリプション、レコメンデーション、物流追跡)が 79 のブロンズテーブル全体に含まれます。V2 では、各エンティティはライフサイクルメソッドを所有し、次を通じて行を出力するドメインクラスです: SourceSystem アダプターであり、中央の手続き型ジェネレーターではありません。
| エンティティ | ソースシステム | テーブル例 |
|---|---|---|
| 顧客(CRM) | salesforce | account · contact · address |
| Prime/サブスクリプション | zuora | prime_membership · subscription_event |
| SKU/製品 | akeneo_pim | sku · category · brand |
| 注文(OMS) | manhattan_oms | order_header · order_line · return_authorization |
| ウェアハウス(WMS) | manhattan_wms | stock_balance · movement |
| 決済 | stripe | payment · refund |
| GL/COA | sap_s4 | gl_account · journal_line |
| サポート/VoC | zendesk · qualtrics | ticket · nps_response |
AmazingEnterpriseSimulation が一日を順序づけ、ドメインオブジェクトが出力ロジックを所有します。
OrderToCash が主要なプロセスの背骨です。 CommerceOrder.execute_lifecycle() はステートマシン — 取込、決済、ピック/パック、請求、GL — を歩き、各ステップが次を呼び出します: runtime.record(system, object, payload) 適切なベンダーアダプター上で。ポートフォリオのブートストラップ(AmazingPortfolio.publish_foundation())が、注文実行前に CRM アカウント、PIM の SKU、フルフィルメントノードをマスタ化します。
| ドメインエンティティ | ナチュラルキー | ライフサイクルメソッド |
|---|---|---|
CustomerAccount | sf_account_id | CRM アカウントは Salesforce でマスタ化 |
ProductSku | sku, asin | PIM 公開 → OMS/WMS 連携 |
FulfillmentNode | facility_code | 在庫ノード登録 |
CommerceOrder | order_number | capture() → authorize_payment() → fulfill() → invoice() → post_gl() |
AccountingDocument | invoice_id, belnr | 均衡した請求書+仕訳転記 |
flowchart LR
PORT[AmazingPortfolio.publish_foundation]
ORD[CommerceOrder.execute_lifecycle]
PORT --> ORD
ORD --> CAP[capture in OMS]
CAP --> PAY[authorize in Stripe]
PAY --> FUL[pick/pack in WMS]
FUL --> INV[invoice in Oracle Billing]
INV --> GL[post journal in SAP S/4]
能力レイヤーは左から右。矢印は主な流れです。
サンプルビュー: これは組織を横断する主要なバリューチェーンです。生成される完全な EDW には、ここに示していない横断統合と二次データフローを含む 46 のソースシステムすべてがあります。
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph cust["Customer & growth"]
direction TB
SF[salesforce]
ZU[zuora Prime]
HS[hubspot]
GA[analytics]
SF ~~~ ZU
ZU ~~~ HS
HS ~~~ GA
end
subgraph product["Product"]
direction TB
PIM[akeneo_pim]
ADS[amazon_ads]
PIM ~~~ ADS
end
subgraph commerce["Commerce"]
direction TB
OMS[manhattan_oms]
STR[stripe]
SC[seller_central]
OMS ~~~ STR
STR ~~~ SC
end
subgraph supply["Supply chain"]
direction TB
ARIBA[sap_ariba]
WMS[manhattan_wms]
OTM[oracle_otm]
ARIBA ~~~ WMS
WMS ~~~ OTM
end
subgraph corp["Corporate"]
direction TB
WD[workday]
S4[sap_s4]
WD ~~~ S4
end
cust --> product --> commerce --> supply --> corp
企業本社と直属機能、代表的なソースシステム付き。
サンプル組織構造: これは主要な報告ラインです。Amazing EC 組織全体には、46 のベンダー統合を横断する追加チーム、サブ部門、マトリクス役割があります。
flowchart TB
CEO[Amazing EC]
CEO --> COM[Commerce]
CEO --> MKT[Marketing]
CEO --> SC[Supply chain]
CEO --> FIN[Finance]
CEO --> HR[HR]
CEO --> OPS[Operations]
CEO --> LEG[Legal & security]
カタログ stage がテーブルを基盤からコーポレートまでグループ化します。
サンプル内訳: これは成熟レイヤーに分散した 79 テーブル全体の代表スライスです。実際の分布は、基盤からコーポレートゴールドテーブルまでの完全なデータリネージを反映します。
flowchart LR F["foundation
~21 tables"] C["commercial
~11 tables"] R["revenue
~15 tables"] O["operations
~14 tables"] CO["corporate
~18 tables"] F --> C --> R --> O F -.-> CO R -.-> CO
論理関係とアンカーキー。ブロンズの値はソースごとに異なり、VibeBI のシルバーが適合させるまで統一されません。
サンプル図: このエンティティ関係図は中核の論理モデルです。生成される完全な EDW には 79 のブロンズテーブル にわたって 46 のベンダーシステム 数千の追加詳細テーブルとリネージ分岐付き。V2 のエンティティインスタンスは次を持ちます: entity_refs 出力されるすべてのイベントに付与し、結合可能性を検証します。
erDiagram
CUSTOMER ||--o{ ORDER : places
CUSTOMER ||--o{ SUBSCRIPTION : prime
CUSTOMER ||--o{ PAYMENT : pays
PRODUCT ||--o{ ORDER_LINE : contains
ORDER ||--|{ ORDER_LINE : lines
ORDER ||--o{ RETURN : may
ORDER ||--o{ SHIPMENT : fulfills
SELLER ||--o{ ORDER_LINE : fulfills
SUPPLIER ||--o{ PO : issues
LOCATION ||--o{ INVENTORY : stocks
46 のベンダー接頭辞、79 のブロンズテーブル。
表示しているサンプルシステム: 下図は代表的なベンダーシステムを示します。生成データセット全体には 46 システムすべてが含まれ、履歴バックフィルとライブストリームを横断する完全なテーブルリネージと統合点があります。
各テーブルは次に従います: {source_system_}__{entity} 命名規則(例: salesforce__account, manhattan_oms__order_header)。各製品の実エクスポートスキーマに基づくベンダー固有の列形状と外部キーを維持します。VibeBI はレコードをシルバーとゴールドへ昇格する際にマスタデータの適合を推論します。
flowchart TB
subgraph foundation["Foundation"]
direction TB
f1["salesforce · workday
akeneo_pim · zuora"]
end
subgraph commercial["Commercial"]
direction TB
c1["hubspot · marketo
amazon_ads · cpq"]
end
subgraph revenue["Revenue"]
direction TB
r1["manhattan_oms · stripe
oracle_billing"]
end
subgraph operations["Operations"]
direction TB
o1["manhattan_wms · sap_ariba
oracle_otm"]
end
subgraph corporate["Corporate"]
direction TB
co1["sap_s4 · adp
servicenow · okta"]
end
foundation --> commercial --> revenue --> operations
foundation --> corporate
V2 OOP シミュレーション → ClickHouse のブロンズ。VibeBI セマンティクス → シルバー → ゴールドは同一インスタンス上。
OOP パス: kb/industries/amazing/ がオペレーションの背骨とエンティティモデルを定義します。 AmazingEnterpriseSimulation がドメインライフサイクルを順序づけます。 SourceSystem アダプターがベンダー固有の行を次へエクスポートします: amazing_v2.
flowchart LR
subgraph kb["kb/industries/amazing"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/amazing"]
ORCH[AmazingEnterpriseSimulation]
DOM["CommerceOrder.execute_lifecycle()
CustomerAccount · ProductSku …"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse amazing_v2
79 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-amazing — 60秒ティックの実行: AmazingEnterpriseSimulation.generate().
ライブ頻度: 各ティックは営業日の OrderToCash ステートマシンを実行します。ドメインオブジェクトが相関した OMS、決済、WMS、請求、GL 行を出力します。規模はティックごとに変動します(既定ベース 5)。必要な履歴期間をバックフィルできます(--days N ライブスクリプトまたは CLI 上)。
flowchart LR
START([60s tick]) --> SIM[AmazingEnterpriseSimulation.generate]
SIM --> FOUND[Portfolio.publish_foundation]
FOUND --> ORD[CommerceOrder lifecycles]
ORD --> EVT[SourceSystem events]
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
OrderToCash ステートマシン — 各遷移はベンダー行を出力するドメインメソッドです。
プロセスの背骨: 定義場所: kb/industries/amazing/process_model.yaml。遅延到着モード(決済 webhook 遅延、WMS スキャン遅延)と例外モード(部分返金、分割出荷)は、同じエンティティライフサイクル上の代替経路としてモデル化しています。
flowchart LR
CRE[created] --> AUTH[authorized]
AUTH --> ALLOC[allocated]
ALLOC --> PICK[picked]
PICK --> PACK[packed]
PACK --> INV[invoiced]
INV --> POST[posted]
AUTH -.->|payment_failure| FAIL[payment_failed]
PACK -.->|split| SPLIT[partial_shipment]
すべてのテーブルに同じリネージ封筒。分類がライブ動作を駆動します。
サンプル分類: 79 のブロンズテーブルすべてが、この三分類パターン(スナップショット、トランザクション、イベント)に沿い、一貫したメタデータと状態追跡を持ちます。図はウェアハウス全体で使うパターンを示しています。
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["Master / dimension"]
S2[Daily full refresh]
end
subgraph txn["transaction"]
direction TB
T1["Orders · payments · POs"]
T2[Append each tick]
end
subgraph evt["event"]
direction TB
E1["Sessions · movements"]
E2[Append each tick]
end
BRONZE[("amazing_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
架空企業に関する注記: 「Hilson」はデモ専用の完全な架空企業です。Hilton Inc.、Hyatt Hotels Corporation、その他実在のホスピタリティ企業と提携・後援・代理するものではありません。
Hilson Hospitality Group は約 680 施設・18 ブランドを持つグローバルホテルオペレーターです。ラグジュアリー旗艦(Waldorf 級、Conrad 級)からフルサービス(Hilson、DoubleTree 級)、セレクトサービス、長期滞在層まで。各施設はオンプレミスの Opera PMS と中央 Amadeus CRS を運用し、一時レジャー、法人契約、団体/コンベンションのゲストに対応します。
事業はロイヤルティ(数百万人規模の Hilson Honors)、団体・コンベンション営業(Salesforce パイプライン、CPQ ルームブロック)、F&B 店舗(MICROS Simphony POS)、オーナー/フランチャイズ報告(Oracle Fusion 計算書)、コーポレート機能にまたがります。典型的な平日で約 1,900 の PMS 予約と 1,750 のフォリオヘッダーを生成し、 夏季旅行需要急増 (6〜8月)により、全施設で稼働率、ADR、F&B 消費、ロイヤルティ活動が上昇します。
サンプルエンティティ: 下表は代表的な事業エンティティとソースシステムです。完全な EDW には追加エンティティ、サブタイプ、専用テーブル(例:OTA チャネルイベント、料金プラン制限、フランチャイズ契約、ディールデスク・レッドライン)が 62 のブロンズテーブル全体に含まれます。V2 では、 StayReservation および関連ドメインクラスが、滞在ライフサイクルの進行に合わせて PMS、CRS、フォリオ、ロイヤルティの行をソースシステムアダプター経由で出力します。
| エンティティ | ソースシステム | テーブル例 |
|---|---|---|
| 施設マスタ | oracle_opera | property · room_type · occupancy_snapshot |
| ブランド/CRS | hilson_brand · amadeus_hosp | brand · property_profile |
| ロイヤルティ会員 | hilson_loyalty | member · point_transaction · redemption |
| 予約(PMS/CRS) | oracle_opera · amadeus_hosp | reservation · reservation_change_event |
| フォリオ/請求 | oracle_opera | folio_header · folio_charge |
| F&B 店舗 | micros_simphony | check_header · check_line |
| 決済 | adyen | payment · refund |
| 団体営業 | salesforce · salesforce_cpq | account · opportunity · quote |
| ハウスキーピング | oracle_opera | room_status_event · housekeeping_task |
| オーナー/GL | oracle_fusion · sap_s4 | owner_statement · journal_line |
| ゲスト体験 | medallia · zendesk | stay_survey · guest_case |
HilsonEnterpriseSimulation が一日を順序づけ、ドメインオブジェクトが出力ロジックを所有します。
ReservationToLoyaltyAndOwnerReporting が主要なプロセスの背骨です。 StayReservation.execute_lifecycle() は予約 → PMS 同期 → フォリオ課金 → 決済 → ロイヤルティポイント → 稼働スナップショット → オーナー計算書 → GL と進みます。 HilsonPortfolio.publish_foundation() が予約実行前にブランド、施設、Honors 会員をマスタ化します。
| ドメインエンティティ | ナチュラルキー | ライフサイクルメソッド |
|---|---|---|
Brand | brand_code | ブランド階層は hilson_brand でマスタ化 |
Property | hotel_code | Opera/CRS の施設+客室在庫 |
GuestMember | honors_member_id | 予約と滞在を横断するロイヤルティプロファイル |
StayReservation | crs_confirmation_no | book() → sync_pms() → open_folio() → settle() → award_points() |
PropertyOccupancy | hotel_code、日付 | 日次 ADR/RevPAR スナップショット |
PropertyFinance | owner_statement_id | オーナー計算書+均衡した GL 転記 |
flowchart LR
PORT[HilsonPortfolio.publish_foundation]
STAY[StayReservation.execute_lifecycle]
PORT --> STAY
STAY --> BOOK[CRS booking]
BOOK --> PMS[PMS sync]
PMS --> FOL[folio charges]
FOL --> PAY[Adyen settlement]
PAY --> LOY[Honors points]
LOY --> OWN[owner statement + GL]
ブランドと施設マスタから、流通、滞在、精算、オーナー報告まで。
サンプルビュー: これは Hilson エコシステムを通る主要なバリューチェーンです。生成される完全な EDW には、ここに示していない横断統合、二次収益、ロイヤルティライフサイクルフローを含む 31 のソースシステムすべてがあります。
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph master["Brand & property master"]
direction TB
BR[hilson_brand]
PROP[oracle_opera property]
RMS[ideas_rms rate plans]
BR ~~~ PROP
PROP ~~~ RMS
end
subgraph dist["Distribution & booking"]
direction TB
AMA[amadeus_hosp CRS]
SM[siteminder OTA]
AMA ~~~ SM
end
subgraph stay["Stay & revenue"]
direction TB
RES[oracle_opera reservation]
FOL[folio header / charges]
SIM[micros_simphony F&B]
PAY[adyen payments]
end
subgraph loy["Loyalty & VoC"]
direction TB
HON[hilson_loyalty member]
MED[medallia · qualtrics]
HON ~~~ MED
end
subgraph corp["Owner & corporate"]
direction TB
OWN[oracle_fusion owner stmt]
SAP[sap_s4 GL]
GRP[salesforce group sales]
OWN ~~~ SAP
SAP ~~~ GRP
end
master --> dist --> stay --> loy
stay --> corp
企業本社と直属機能、代表的なソースシステム付き。
サンプル組織構造: これは主要な報告ラインです。Hilson 組織全体には、31 のベンダー統合を横断する追加の地域マネジメント、ブランド固有チーム、シェアードサービス機能があります。
flowchart TB
CEO[Hilson Hospitality Group]
CEO --> BRAND[Brand & marketing]
CEO --> DIST[Distribution & revenue mgmt]
CEO --> PROP[Property operations]
CEO --> SALES[Group sales]
CEO --> LOY[Loyalty program]
CEO --> FIN[Finance & owner reporting]
CEO --> HR[Human resources]
CEO --> GX[Guest experience]
CEO --> LEG[IT / security / legal]
カタログ stage がテーブルを基盤からコーポレートまでグループ化します。
サンプル内訳: これは成熟レイヤーに分散した 62 テーブル全体の代表スライスです。実際の分布は、基盤からコーポレートゴールドテーブルまでの完全なデータリネージを反映します。
flowchart LR F["foundation
~15 tables"] C["commercial
~7 tables"] GR["guest_revenue
~17 tables"] PO["property_ops
~7 tables"] CO["corporate
~16 tables"] F --> C --> GR --> PO F -.-> CO GR -.-> CO
論理関係とアンカーキー。施設(hotel_code)が背骨です。ゲスト識別は Honors と滞在テーブル経由です。
サンプル図: このエンティティ関係図は中核の論理モデルです。生成される完全な EDW には 62 のブロンズテーブル にわたって 31 のベンダーシステム 数千の追加詳細テーブルとリネージ分岐付き。
erDiagram
PROPERTY ||--o{ RESERVATION : hosts
PROPERTY ||--o{ RATE_PLAN : offers
BRAND ||--o{ PROPERTY : flags
MEMBER ||--o{ RESERVATION : books
MEMBER ||--o{ POINT_TXN : earns
MEMBER ||--o{ REDEMPTION : redeems
RESERVATION ||--|| FOLIO : bills
FOLIO ||--o{ FOLIO_CHARGE : lines
RESERVATION ||--o{ FNB_CHECK : posts
CORP_ACCOUNT ||--o{ OPPORTUNITY : pursues
SUPPLIER ||--o{ PO : supplies
PROPERTY ||--o{ WORK_ORDER : maintains
31 のベンダー接頭辞、62 のブロンズテーブル。
表示しているサンプルシステム: 下図は代表的なベンダーシステムを示します。生成データセット全体には 31 システムすべてが含まれ、履歴バックフィルとライブストリームを横断する完全なテーブルリネージと統合点があります。
各テーブルは次に従います: {source_system_}__{entity} 命名規則(例: oracle_opera__reservation, hilson_loyalty__member)。各製品の実エクスポートスキーマに基づくベンダー固有の列形状と外部キーを維持します。VibeBI はレコードをシルバーとゴールドへ昇格する際にマスタデータの適合を推論します。
flowchart TB
subgraph foundation["Foundation"]
direction TB
f1["hilson_brand · oracle_opera property · room_type"]
f2["amadeus_hosp · ideas_rms · hilson_loyalty member"]
f3["salesforce account · workday · sap_s4 · coupa supplier"]
end
subgraph commercial["Commercial"]
direction TB
c1["salesforce pipeline · CPQ · hubspot · marketo"]
end
subgraph guest_rev["Guest revenue"]
direction TB
g1["oracle_opera reservation · folio · events"]
g2["amadeus_hosp · siteminder · micros_simphony"]
g3["adyen · loyalty points · oracle_fusion owner"]
end
subgraph prop_ops["Property ops"]
direction TB
p1["housekeeping · occupancy · ibm_maximo · coupa PO"]
end
subgraph corporate["Corporate"]
direction TB
co1["sap_s4 journals · adp · ukg · anaplan"]
co2["medallia · qualtrics · zendesk · concur"]
co3["servicenow · okta · splunk · ironclad · onetrust"]
end
foundation --> commercial --> guest_rev --> prop_ops
foundation --> corporate
guest_rev --> corporate
V2 OOP シミュレーション → ClickHouse のブロンズ。VibeBI セマンティクス → シルバー → ゴールドは同一インスタンス上。
OOP パス: kb/industries/hilson/ がオペレーションの背骨とエンティティモデルを定義します。 HilsonEnterpriseSimulation がドメインライフサイクルを順序づけます。 SourceSystem アダプターがベンダー固有の行を次へエクスポートします: hilson_v2.
flowchart LR
subgraph kb["kb/industries/hilson"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/hilson"]
ORCH[HilsonEnterpriseSimulation]
DOM["StayReservation.execute_lifecycle()
Property · GuestMember …"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse hilson_v2
62 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-hilson — 60秒ティックの実行: HilsonEnterpriseSimulation.generate().
ライブ頻度: 各ティックは予約からロイヤルティまでのステートマシンを実行します。ドメインオブジェクトが相関した CRS、PMS、フォリオ、F&B、決済、ロイヤルティ、GL 行を出力します。規模はティックごとに変動します(既定ベース 5)。必要な履歴期間をバックフィルできます(--days N)。Hilson では予約アンカーテーブルのギャップ検出も含みます。
flowchart LR
START([60s tick]) --> SIM[HilsonEnterpriseSimulation.generate]
SIM --> FOUND[Portfolio.publish_foundation]
FOUND --> STAY[StayReservation lifecycles]
STAY --> EVT[SourceSystem events]
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
ReservationToLoyaltyAndOwnerReporting ステートマシン — 各遷移がベンダー行を出力します。
プロセスの背骨: 定義場所: kb/industries/hilson/process_model.yaml。例外モード(ノーショー、チャージバック、部屋アップグレード)は独立したランダム挿入ではなく、同じエンティティライフサイクルから分岐します。
flowchart LR
BOOK[booked] --> SYNC[synced_to_pms]
SYNC --> CHKIN[checked_in]
CHKIN --> HOUSE[in_house]
HOUSE --> CHKOUT[checked_out]
CHKOUT --> SET[settled]
SET --> PTS[points_posted]
PTS --> OCC[occupancy_snapshotted]
OCC --> OWN[owner_reported]
OWN --> GL[posted_to_gl]
SYNC -.->|no_show| NS[no_show]
SET -.->|chargeback| CB[chargeback]
すべてのテーブルに同じリネージ封筒。分類がライブリフレッシュかマイクロバッチ追記かを制御します。
サンプル分類: 62 のブロンズテーブルすべてが、この三分類パターン(スナップショット、トランザクション、イベント)に沿い、一貫したメタデータと状態追跡を持ちます。図はウェアハウス全体で使うパターンを示しています。
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["Property · brand · member masters"]
S2[Daily full refresh]
end
subgraph txn["transaction"]
direction TB
T1["Reservations · folios · payments"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["HK · OTA · surveys · access"]
E2[Append each live tick]
end
BRONZE[("hilson_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
架空企業に関する注記: 「P&C」はデモ専用の完全な架空企業です。The Procter & Gamble Company や実在の CPG メーカーと提携・後援・代理するものではありません。
P&C はグローバルな消費財メーカー兼マーケターです。日用品をマスリテール、クラブ、グロサリー、Eコマース経由で約 180 か国に販売する B2B2C モデルです。5 つの Sector Business Unit(SBU)が Fabric & Home Care、Baby/Feminine/Family Care、Beauty、Health Care、Grooming にまたがり、約 12 のフラッグシップブランド(TidalWave、ComfortWrap、BrightSmile、EdgePro ほか)、8 工場と 3 つの地域配送センターを持ちます。
事業は需要計画、原材料調達、MES 生産、品質リリース、完成品流通、小売顧客注文、トレードマーケティング、財務にまたがります。各シミュレーション日に相関した MES 作業指示、Ariba PO、OMS ヘッダー、OTM 出荷、SAP 仕訳行を生成し、 Spring Clean 需要急増 (3〜4月)により、北米と EMEA でファブリック/ホームケア需要、工場スループット、小売向けセルインが上昇します。
サンプルエンティティ: 下表は代表的な事業エンティティとソースシステムです。完全な EDW には追加エンティティ、サブタイプ、専用テーブル(例:IoT センサー読取、保全作業指示、トレードプロモーション、CLM レッドライン)が 60 のブロンズテーブル全体に含まれます。V2 では、 ProductionBatch および CustomerOrder ドメインクラスが MakeToShipToSell の背骨を駆動します。
| エンティティ | ソースシステム | テーブル例 |
|---|---|---|
| SBU/ブランド階層 | pc_brand | brand · category |
| 完成品 SKU | akeneo_pim | sku · brand · category |
| 工場/DC マスタ | oracle_scm | warehouse · office |
| 需要予測 | blueyonder | forecast_daily |
| 原材料 PO | sap_ariba | purchase_order · purchase_order_line |
| 生産バッチ | siemens_mes | work_order |
| 品質リリース | mastercontrol | quality_incident |
| 完成品在庫 | manhattan_wms | stock_balance · movement · pick_pack_event |
| 小売顧客注文 | manhattan_oms | order_header · order_line |
| 出荷 | oracle_otm | shipment · shipment_tracking_event |
| 小売アカウント | salesforce | account · opportunity · sales_activity |
| GL/COA | sap_s4 | journal_entry · journal_line |
PcEnterpriseSimulation が一日を順序づけ、ドメインオブジェクトが出力ロジックを所有します。
MakeToShipToSell が主要なプロセスの背骨です。 ProductionBatch.execute_lifecycle() は予測 → 調達 → 生産 → QC リリース → 完成品と進みます。 CustomerOrder.execute_lifecycle() は OMS 取込 → WMS 履行 → OTM 出荷と進みます。 PcPortfolio.publish_foundation() がバッチと注文の実行前に SBU、ブランド、工場、SKU、小売アカウントをマスタ化します。サービスオブジェクト(PlantOperations, CommercialProgram, FinanceAndCorporate)が、補完するコーポレートおよびマーケティング行を出力します。
| ドメインエンティティ | ナチュラルキー | ライフサイクルメソッド |
|---|---|---|
Brand | brand_code | pc_brand+PIM の SBU/カテゴリ階層 |
ProductSku | sku, material_number | PIM 公開 → MES 品目連携 |
Plant | facility_code | 製造工場または DC の登録 |
ProductionBatch | work_order_id | forecast_demand() → procure_materials() → run_production() → release_quality() → receive_finished_goods() |
RetailCustomer | sf_account_id | Salesforce の取引アカウント |
CustomerOrder | order_number | place_order() → fulfill() → ship() |
Supplier | ariba_supplier_id | 調達マスタ+請求書連携 |
flowchart LR
PORT[PcPortfolio.publish_foundation]
BATCH[ProductionBatch.execute_lifecycle]
ORDER[CustomerOrder.execute_lifecycle]
PORT --> BATCH
PORT --> ORDER
BATCH --> FCST[BlueYonder forecast]
FCST --> PO[Ariba PO]
PO --> MES[SIEMENS MES work order]
MES --> QC[MasterControl release]
QC --> WMS[WMS finished goods]
ORDER --> OMS[OMS order]
OMS --> SHIP[OTM shipment]
SHIP --> GL[SAP S/4 journal]
ブランドポートフォリオから、計画、製造、物流、販売、コーポレート決算まで。
サンプルビュー: これは P&C エコシステムを横断する主要なバリューチェーンです。生成される完全な EDW には、ここに示していない横断統合、工場 IoT テレメトリ、トレードマーケティングフローを含む 34 のソースシステムすべてがあります。
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph portfolio["Portfolio & R&D"]
direction TB
PCB[pc_brand SBU ladder]
PIM[akeneo_pim SKU]
PCB ~~~ PIM
end
subgraph plan["Plan & procure"]
direction TB
BY[blueyonder forecast]
ARB[sap_ariba PO]
BY ~~~ ARB
end
subgraph make["Make & quality"]
direction TB
MES[siemens_mes work order]
MC[mastercontrol QC]
MES ~~~ MC
end
subgraph move["Store & ship"]
direction TB
WMS[manhattan_wms inventory]
OTM[oracle_otm TMS]
WMS ~~~ OTM
end
subgraph sell["Sell to retail"]
direction TB
SF[salesforce trade]
OMS[manhattan_oms orders]
SF ~~~ OMS
end
subgraph corp["Corporate"]
direction TB
WD[workday]
S4[sap_s4 GL]
WD ~~~ S4
end
portfolio --> plan --> make --> move --> sell --> corp
シンシナティのグローバル本社と直属機能、代表的なソースシステム付き。
サンプル組織構造: これは主要な報告ラインです。P&C 組織全体には、34 のベンダー統合を横断する地域 SBU チーム、工場マネージャー、シェアードサービス機能があります。
flowchart TB
CEO[P&C Global]
CEO --> SBU[SBU portfolio & R&D]
CEO --> MFG[Supply chain & manufacturing]
CEO --> COMM[Commercial & retail sales]
CEO --> MKT[Marketing & brand]
CEO --> FIN[Finance & controller]
CEO --> HR[Human resources]
CEO --> QUAL[Quality & regulatory]
CEO --> LEG[IT / legal / security]
カタログ stage がテーブルを基盤からコーポレートまでグループ化します。
サンプル内訳: これは成熟レイヤーに分散した 60 テーブル全体の代表スライスです。実際の分布は、基盤からコーポレートゴールドテーブルまでの完全なデータリネージを反映します。
flowchart LR F["foundation
~13 tables"] SC["supply_chain
~10 tables"] D["distribution
~6 tables"] C["commercial
~16 tables"] CO["corporate
~15 tables"] F --> SC --> D --> C F -.-> CO C -.-> CO
論理関係とアンカーキー。ブランド(brand_code)と工場(facility_code)が背骨です。品目番号が PIM と MES を結びます。
サンプル図: このエンティティ関係図は中核の論理モデルです。生成される完全な EDW には 60 のブロンズテーブル にわたって 34 のベンダーシステム 追加の詳細テーブルとリネージ分岐付き。エンティティインスタンスは次を持ちます: entity_refs 出力されるすべてのイベントに付与し、結合可能性を検証します。
erDiagram
BRAND ||--o{ PRODUCT : owns
PRODUCT ||--o{ PRODUCTION_BATCH : produces
PLANT ||--o{ PRODUCTION_BATCH : runs
SUPPLIER ||--o{ PO : supplies
PRODUCTION_BATCH ||--o{ PO : triggers
PLANT ||--o{ INVENTORY : stocks
RETAIL_CUSTOMER ||--o{ CUSTOMER_ORDER : places
PRODUCT ||--o{ ORDER_LINE : contains
CUSTOMER_ORDER ||--|{ ORDER_LINE : lines
CUSTOMER_ORDER ||--o{ SHIPMENT : ships
CUSTOMER_ORDER ||--o{ JOURNAL : posts
34 のベンダー接頭辞、60 のブロンズテーブル。
表示しているサンプルシステム: 下図は代表的なベンダーシステムを示します。生成データセット全体には 34 システムすべてが含まれ、履歴バックフィルとライブストリームを横断する完全なテーブルリネージと統合点があります。共有ソースシステムマニフェストは次にあります: kb/source_systems/ は業界をまたいで再利用されます。P&C は次を追加します: pc_brand 業界固有の社内システムとして。
各テーブルは次に従います: {source_system_}__{entity} 命名規則(例: pc_brand__brand, siemens_mes__work_order)。各製品の実エクスポートスキーマに基づくベンダー固有の列形状と外部キーを維持します。VibeBI はレコードをシルバーとゴールドへ昇格する際にマスタデータの適合を推論します。
flowchart TB
subgraph foundation["Foundation"]
direction TB
f1["pc_brand · akeneo_pim
oracle_scm · workday"]
f2["sap_s4 dimensions"]
end
subgraph supply_chain["Supply chain"]
direction TB
s1["blueyonder · sap_ariba
siemens_mes · mastercontrol"]
s2["ibm_maximo · aws_iot"]
end
subgraph distribution["Distribution"]
direction TB
d1["manhattan_wms
oracle_otm"]
end
subgraph commercial["Commercial"]
direction TB
c1["salesforce · manhattan_oms
hubspot · marketo"]
c2["google_analytics · qualtrics · zendesk"]
end
subgraph corporate["Corporate"]
direction TB
co1["sap_s4 journals · coupa
adp · ukg · concur"]
co2["servicenow · okta · splunk
ironclad · onetrust · greenhouse"]
end
foundation --> supply_chain --> distribution --> commercial
foundation --> corporate
commercial --> corporate
V2 OOP シミュレーション → ClickHouse のブロンズ。VibeBI セマンティクス → シルバー → ゴールドは同一インスタンス上。
OOP パス: kb/industries/pnc/ がオペレーションの背骨とエンティティモデルを定義します。 PcEnterpriseSimulation がドメインライフサイクルを順序づけます。 SourceSystem アダプターがベンダー固有の行を次へエクスポートします: pnc_v2.
flowchart LR
subgraph kb["kb/industries/pnc"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/pnc"]
ORCH[PcEnterpriseSimulation]
DOM["ProductionBatch · CustomerOrder
execute_lifecycle()"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse pnc_v2
60 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-pnc — 60秒ティックの実行: PcEnterpriseSimulation.generate().
ライブ頻度: 各ティックは MakeToShipToSell ステートマシンを実行します。ドメインオブジェクトが生産バッチと小売顧客注文ごとに相関した forecast、PO、MES、WMS、OMS、OTM、GL 行を出力します。規模はティックごとに変動します(既定ベース 5)。必要な履歴期間をバックフィルできます(--days N ライブスクリプトまたは CLI 上)。
flowchart LR
START([60s tick]) --> SIM[PcEnterpriseSimulation.generate]
SIM --> FOUND[PcPortfolio.publish_foundation]
FOUND --> BATCH[ProductionBatch lifecycles]
FOUND --> ORDER[CustomerOrder lifecycles]
BATCH --> CORP[PlantOps + Finance + Commercial]
ORDER --> CORP
CORP --> EVT[SourceSystem events]
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
MakeToShipToSell ステートマシン — 各遷移はベンダー行を出力するドメインメソッドです。
プロセスの背骨: 定義場所: kb/industries/pnc/process_model.yaml。例外モード(バッチ廃棄、品質保留、部分出荷、サプライヤー遅延)は独立したランダム挿入ではなく、同じエンティティライフサイクルから分岐します。
flowchart LR
FCST[forecasted] --> PROC[materials_procured]
PROC --> PROD[production_started]
PROD --> QC[quality_released]
QC --> FG[finished_goods_received]
FG --> ORD[customer_ordered]
ORD --> FUL[fulfilled]
FUL --> SHIP[shipped]
SHIP --> GL[posted_to_gl]
PROD -.->|scrap| SCRAP[batch_scrap]
QC -.->|hold| HOLD[quality_hold]
FUL -.->|short| PART[partial_shipment]
すべてのテーブルに同じリネージ封筒。分類がライブ動作を駆動します。
サンプル分類: 60 のブロンズテーブルすべてが、この三分類パターン(スナップショット、トランザクション、イベント)に沿い、一貫したメタデータと状態追跡を持ちます。図はウェアハウス全体で使うパターンを示しています。
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["Brand · plant · SKU masters"]
S2[Daily foundation refresh]
end
subgraph txn["transaction"]
direction TB
T1["POs · work orders · OMS · GL"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["IoT · WMS movement · OTM tracking"]
E2[Append each live tick]
end
BRONZE[("pnc_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
架空企業に関する注記: 「HKBC」はデモ目的のみで作成された完全な架空企業です。HSBC Holdings plc、The Hongkong and Shanghai Banking Corporation Limited、または実在の銀行と提携・後援・表象するものではありません。
HKBC (Hong Kong Banking Corporation)はセントラルに本拠を置く香港のユニバーサルバンクで、Wealth and Personal Banking、Commercial Banking、Global Banking and Markets を展開します。HKD 預金を受け入れ、HIBOR 住宅ローンと無担保与信を組成し、カードを発行し、24×7 の Faster Payment System と PearlPay(PayMe クラス)レールを運用し、グレーターベイエリア貿易をファイナンスし、7.75–7.85 の兌換バンド内で USD/HKD および CNH の FX を計上します。
帳簿は香港島・九龍・新界の約 10 支店に加え、前海 GBA ホールセールデスクとロンドンのマーケッツデスクにまたがります。各シミュレーション日に相関した FPS 入金、カードオーソリ、CHATS/SWIFT 送金、コア複式記帳、AML アラート、SAP 仕訳を生成し、 旧正月 / 第 1 四半期タックスローン急増 PearlPay の P2P 量、FPS 収納、個人ローン組成を押し上げます。
サンプルエンティティ: 下表は代表的な業務エンティティとソースシステムです。完全な EDW には、60 のブロンズテーブル全体にわたる追加エンティティ、サブタイプ、専用テーブル(AML ケース、ECL 引当、証券注文、ファシリティの赤入れなど)が含まれます。V2 では FpsPayment および関連ドメインクラスが PayToPostToBalance の背骨を駆動します。
| エンティティ | ソースシステム | テーブル例 |
|---|---|---|
| 支店 / デスク | hkbc_core | branch |
| 商品カタログ | hkbc_core | product |
| 顧客(CIF) | hkbc_core · salesforce | customer · account · contact |
| 預金 / 貸出口座 | hkbc_core | account · posting · deposit_balance |
| FPS / CHATS / SWIFT | hkicl_fps · hkicl_chats · swift | proxy · payment · rtgs_payment · message |
| カード | fiserv_visionplus | card · authorization · clearing_transaction |
| PearlPay ウォレット | hkbc_pay | wallet · wallet_payment |
| 貿易金融 | hkbc_trade | documentary_credit · guarantee |
| FX / マーケット | murex · bloomberg | fx_trade · position · fx_rate |
| AML / 信用リスク | nice_actimize · moodys_risk | aml_alert · case · credit_facility · ecl_provision |
| ウェルスディーリング | hkbc_wealth | holding · securities_order |
| GL/COA | sap_s4 | journal_entry · journal_line |
HkbcEnterpriseSimulation が一日を順序づけ、ドメインオブジェクトが出力ロジックを所有します。
PayToPostToBalance が主要なプロセスの背骨です。 FpsPayment.execute_lifecycle() (および PearlPay・カード・CHATS・SWIFT の対となるクラス)は、レール電文 → コア複式記帳 → 任意の AML アラート → EOD 預金残高 → GL と進みます。 HkbcPortfolio.publish_foundation() 支払実行前に支店、商品、CIF 顧客、口座をマスターします。サービスオブジェクトが CMB 貿易、GBM FX、ウェルス、リスク、コーポレート行を放出します。
| ドメインエンティティ | ナチュラルキー | ライフサイクルメソッド |
|---|---|---|
Branch | branch_code | hkbc_core でマスターされた支店 / ホールセールデスク |
Product | product_code | CASA・住宅ローン・カード・ウォレット・貿易・FX カタログ |
Customer | customer_id | CIF + KYC セグメント;Salesforce の CRM ミラー |
Account | account_id | publish() → post_pair() 均衡元帳 |
FpsPayment | payment_id | execute_lifecycle() → レール → 記帳 → AML |
DocumentaryCredit | lc_id | CMB LC / 保証発行 |
FxTrade | trade_id | Murex チケット → USD/HKD ポジション |
flowchart LR
PORT[HkbcPortfolio.publish_foundation]
PAY[FpsPayment.execute_lifecycle]
PORT --> PAY
PAY --> RAIL[FPS / PearlPay / card / CHATS / SWIFT]
RAIL --> CORE[post_pair in hkbc_core]
CORE --> AML[Actimize AML]
CORE --> EOD[EOD deposit balance]
EOD --> GL[SAP S/4 journal]
CIF と商品マスターからレール、コア記帳、リスク、財務クローズまで。
サンプルビュー: これは HKBC エコシステムを通る主要なバリューチェーンです。生成される完全な EDW には、ここに示していない横断統合、ウェルスディーリング、GBA 貿易回廊を含む 32 のソースシステムすべてがあります。
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph master["CIF & product master"]
direction TB
CORE[hkbc_core CIF / account]
SF[salesforce]
CORE ~~~ SF
end
subgraph rails["Payments rails"]
direction TB
FPS[hkicl_fps]
PP[hkbc_pay PearlPay]
CARD[fiserv_visionplus]
CHATS[hkicl_chats · swift]
end
subgraph book["Core & risk"]
direction TB
POST[hkbc_core posting]
AML[nice_actimize]
ECL[moodys_risk]
POST ~~~ AML
AML ~~~ ECL
end
subgraph franchise["CMB · GBM · WPB"]
direction TB
TRD[hkbc_trade]
FX[murex]
WLT[hkbc_wealth]
TRD ~~~ FX
FX ~~~ WLT
end
subgraph corp["Corporate"]
direction TB
WD[workday]
S4[sap_s4 GL]
WD ~~~ S4
end
master --> rails --> book --> franchise --> corp
Harbourview Tower 本社と直属機能、代表的なソースシステム付き。
サンプル組織構造: これは主要な報告ラインです。完全な HKBC 組織には、32 のベンダー統合全体にわたる追加の地区支店、GBA デスク、シェアードサービス機能が含まれます。
flowchart TB
CEO[HKBC Hong Kong]
CEO --> WPB[Wealth & Personal Banking]
CEO --> CMB[Commercial Banking]
CEO --> GBM[Global Banking & Markets]
CEO --> RISK[Risk & AML]
CEO --> FIN[Finance & ALM]
CEO --> HR[Human resources]
CEO --> OPS[Operations & branches]
CEO --> LEG[IT / legal / security]
カタログ stage がテーブルを基盤からコーポレートまでグループ化します。
サンプル内訳: これは成熟レイヤーに分散した 60 テーブル全体の代表スライスです。実際の分布は、基盤からコーポレートゴールドテーブルまでの完全なデータリネージを反映します。
flowchart LR F["foundation
~13 tables"] P["payments
~11 tables"] M["markets & risk
~12 tables"] C["commercial
~6 tables"] CO["corporate
~18 tables"] F --> P --> M --> C F -.-> CO P -.-> CO
論理関係とアンカーキー。顧客(customer_id) と口座 (account_id) が背骨です。支払いは次で結合します source_txn_id.
サンプル図: このエンティティ関係図は中核の論理モデルです。生成される完全な EDW には 60 のブロンズテーブル にわたって ベンダーシステム 32 追加の詳細テーブルとリネージ分岐付き。エンティティインスタンスは次を持ちます: entity_refs 出力されるすべてのイベントに付与し、結合可能性を検証します。
erDiagram
CUSTOMER ||--o{ ACCOUNT : holds
PRODUCT ||--o{ ACCOUNT : defines
BRANCH ||--o{ ACCOUNT : books
ACCOUNT ||--o{ PAYMENT : pays
ACCOUNT ||--o{ POSTING : ledgers
ACCOUNT ||--o{ DEPOSIT_BALANCE : snapshots
PAYMENT ||--o{ AML_ALERT : screens
COMMERCIAL_CLIENT ||--o{ TRADE_CREDIT : finances
ACCOUNT ||--o{ FX_TRADE : hedges
ACCOUNT ||--o{ WEALTH_ORDER : deals
ベンダー接頭辞 32、ブロンズテーブル 60。
表示しているサンプルシステム: 下図は代表的なベンダーシステムです。生成される完全データセットには、履歴バックフィルとライブストリーム全体のテーブルリネージと統合点を含む 32 システムすべてがあります。共有ソースシステムマニフェストは kb/source_systems/ は業界横断で再利用されます — HKBC が追加する hkbc_core, hkbc_pay, hkbc_trade、および hkbc_wealth を業界固有の内部システムとして加え、さらに香港マーケットレールを使います。
各テーブルは次に従います: {source_system_}__{entity} 命名規則(例: hkbc_core__account, hkicl_fps__payment)。各製品の実エクスポートスキーマに基づくベンダー固有の列形状と外部キーを維持します。VibeBI はレコードをシルバーとゴールドへ昇格する際にマスタデータの適合を推論します。
flowchart TB
subgraph foundation["Foundation"]
direction TB
f1["hkbc_core branch · product · CIF · account"]
f2["salesforce · workday · sap_s4 dimensions"]
end
subgraph payments["Payments"]
direction TB
p1["hkicl_fps · hkbc_pay · fiserv_visionplus"]
p2["hkicl_chats · swift · core posting"]
end
subgraph markets["Markets & risk"]
direction TB
m1["murex · bloomberg · hkbc_trade · hkbc_wealth"]
m2["nice_actimize · moodys_risk"]
end
subgraph commercial["Commercial"]
direction TB
c1["salesforce pipeline · hubspot · marketo"]
end
subgraph corporate["Corporate"]
direction TB
co1["sap_s4 journals · anaplan · adp · ukg"]
co2["genesys · zendesk · servicenow · okta"]
co3["splunk · ironclad · onetrust · greenhouse"]
end
foundation --> payments --> markets --> commercial
foundation --> corporate
payments --> corporate
V2 OOP シミュレーション → ClickHouse のブロンズ。VibeBI セマンティクス → シルバー → ゴールドは同一インスタンス上。
OOP パス: kb/industries/hkbc/ がオペレーションの背骨とエンティティモデルを定義します。 HkbcEnterpriseSimulation がドメインライフサイクルを順序づけます。 SourceSystem アダプターがベンダー固有の行を次へエクスポートします: hkbc_v2.
flowchart LR
subgraph kb["kb/industries/hkbc"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/hkbc"]
ORCH[HkbcEnterpriseSimulation]
DOM["FpsPayment.execute_lifecycle()
Account · Customer · FxTrade …"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse hkbc_v2
60 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-hkbc — 60秒ティックの実行: HkbcEnterpriseSimulation.generate().
ライブ頻度: 各ティックは PayToPostToBalance ステートマシンを実行します。ドメインオブジェクトが相関した FPS、PearlPay、カード、CHATS、SWIFT、コア記帳、AML、GL 行を放出します。本日のライブティックは香港の as_of 支払いテープが日中に伸びます。スケールはティックごとに変わります(既定ベース 5)。必要な履歴スパンはバックフィルできます(--days N ライブスクリプトまたは CLI 上)。
flowchart LR
START([60s tick]) --> SIM[HkbcEnterpriseSimulation.generate]
SIM --> FOUND[Portfolio.publish_foundation]
FOUND --> PAY[Payment lifecycles]
FOUND --> MKT[Trade · FX · wealth · risk]
PAY --> EVT[SourceSystem events]
MKT --> EVT
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
PayToPostToBalance ステートマシン — 各遷移はベンダー行を放出するドメインメソッドです。
プロセスの背骨: 定義場所: kb/industries/hkbc/process_model.yaml. 遅延到着モード(SWIFT ack ラグ、オーソリ後のカードクリアリング、AML ケースラグ、GL バッチ遅延)と例外モード(FPS リジェクト、カード拒否、AML ホールド、残高不足、LC ディスクレ)は、独立したランダム挿入ではなく同一エンティティのライフサイクルから分岐します。
flowchart LR
OPEN[account_opened] --> INIT[payment_initiated]
INIT --> POST[core_posted]
POST --> AML[aml_screened]
AML --> CLR[cleared]
CLR --> BAL[balance_snapshot]
BAL --> GL[posted_to_gl]
INIT -.->|fps_reject| REJ[fps_rejected]
INIT -.->|card_decline| DEC[card_declined]
POST -.->|aml_hold| HOLD[aml_hold]
すべてのテーブルに同じリネージ封筒。分類がライブ動作を駆動します。
サンプル分類: 60 のブロンズテーブルすべてが、この三分類パターン(スナップショット、トランザクション、イベント)に沿い、一貫したメタデータと状態追跡を持ちます。図はウェアハウス全体で使うパターンを示しています。
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["CIF · product · branch · account"]
S2[Daily foundation refresh]
end
subgraph txn["transaction"]
direction TB
T1["Payments · postings · LC · FX · GL"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["AML · card auth · access · NPS"]
E2[Append each live tick]
end
BRONZE[("hkbc_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
架空企業に関する注記: 「AYA」はデモ目的のみで作成された完全な架空企業です。AXA SA、AXA Hong Kong and Macau、または実在の保険会社と提携・後援・表象するものではありません。
AYA は香港のコンポジット保険会社です。Life & Savings、Health(VHIS と従業員福利を含む)、General Insurance を、専属エージェント、バンカシュランス、ブローカー、Aria by AYA アプリ、組み込み e ウォレットパートナー経由で販売します。本社はクオリーベイ、セントラルにアドバイザリーセンター、尖沙咀に AYA Medical Centre、マカオ支店、前海 GBA 営業所があります。
事業は商品ファクトリー、Magnum クラス引受、分割 PAS(生命は Ingenium クラス、損害は Guidewire)、FPS 保険料収納、Varicent コミッション、24×7 自動車/旅行 FNOL、FINEOS 医療クレーム、再保険出再、Prophet IFRS 17 評価、SAP S/4 仕訳にまたがり、 台風シーズンの損害保険クレーム増 (6–10 月)およびデジタル/代理店チャネル全体の旧正月旅行・北上自動車保険スパイク。
サンプルエンティティ: 下表は代表的な業務エンティティとソースシステムです。完全な EDW には、60 のブロンズテーブル全体にわたる追加エンティティ、サブタイプ、専用テーブル(Prophet BEL/CSM、特約出再、医療センター来院、CLM 赤入れなど)が含まれます。V2 では LifePolicy および GiPolicy ドメインクラスが QuoteToBindToPremium と FnolToPay の背骨を駆動します。
| エンティティ | ソースシステム | テーブル例 |
|---|---|---|
| 種目 / 商品 | aya_product | line_of_business · product |
| IA 免許エージェント | aya_agency | agent |
| 契約者 | salesforce | account · contact · address |
| デジタル見積 / FNOL | aya_digital | session · quote · claim_submission |
| 生命 / 医療契約 | dxc_ingenium · swissre_magnum | policy · coverage · premium · decision |
| 損害保険契約 / 請求 | guidewire_pc · guidewire_bc | policy · coverage · invoice |
| 損害保険クレーム | guidewire_cc | claim · claim_transaction |
| 医療クレーム / クリニック | fineos · aya_health | health_claim · clinic_visit |
| 保険料 / クレーム資金 | fps | payment |
| コミッション | varicent | commission |
| 再保険 | sap_fs_ri | cession |
| 運用 / 評価 | bloomberg_aim · prophet | holding · trade · valuation |
| GL / IFRS 17 | sap_s4 | journal_entry · journal_line |
AyaEnterpriseSimulation が一日を順序づけ、ドメインオブジェクトが出力ロジックを所有します。
QuoteToBindToPremium は新契約の背骨です。 FnolToPay はクレームの背骨です。 LifePolicy.execute_lifecycle() 見積 → Magnum UW → Ingenium 発行 → FPS 収納 → コミッション → GL と進みます。 GiPolicy.execute_lifecycle() 見積 → PolicyCenter 成約 → BillingCenter 請求 → ClaimCenter の任意同日 FNOL と進みます。 AyaPortfolio.publish_foundation() 契約実行前に商品、エージェント、オフィス、契約者をマスターします。
| ドメインエンティティ | ナチュラルキー | ライフサイクルメソッド |
|---|---|---|
InsuranceProduct | product_code | aya_product の生命 / 医療 / 損害タリフ |
Agent | agent_id | IA ライセンス登録 + Salesforce プロデューサー |
Policyholder | sf_account_id | マス / HNW / SME / 雇用主 CRM |
LifePolicy | policy_number | publish_quote() → UW → 成約 → 収納 → コミッション → GL |
GiPolicy | policy_number | publish_quote() → 成約 → 請求 → open_claim() |
HealthClaim | claim_number | クリニック来院 → FINEOS → FPS 支払 |
flowchart LR
PORT[AyaPortfolio.publish_foundation]
LIFE[LifePolicy.execute_lifecycle]
GI[GiPolicy.execute_lifecycle]
PORT --> LIFE
PORT --> GI
LIFE --> Q[Aria quote]
Q --> UW[Magnum UW]
UW --> PAS[Ingenium / PolicyCenter]
PAS --> FPS[FPS collect]
GI --> FNOL[ClaimCenter FNOL]
FNOL --> RI[reinsurance cession]
FPS --> GL[SAP S/4 IFRS 17]
商品ファクトリーから販売、成約、収納、クレーム、財務クローズまで。
サンプルビュー: これは AYA エコシステムを通る主要なバリューチェーンです。生成される完全な EDW には、ここに示していない横断統合、医療センターのキャッシュレス来院、特約会計を含む 39 のソースシステムすべてがあります。
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph factory["Product & distribution"]
direction TB
PRD[aya_product]
AG[aya_agency]
DIG[aya_digital Aria]
PRD ~~~ AG
AG ~~~ DIG
end
subgraph bind["Underwrite & bind"]
direction TB
MAG[swissre_magnum]
LIFE[dxc_ingenium]
PC[guidewire_pc]
MAG ~~~ LIFE
LIFE ~~~ PC
end
subgraph cash["Collect & commission"]
direction TB
BC[guidewire_bc]
FPS[fps]
VAR[varicent]
BC ~~~ FPS
FPS ~~~ VAR
end
subgraph claims["Claims & health"]
direction TB
CC[guidewire_cc]
FN[fineos]
CLIN[aya_health]
CC ~~~ FN
FN ~~~ CLIN
end
subgraph corp["Investments & close"]
direction TB
AIM[bloomberg_aim]
PR[prophet]
S4[sap_s4]
AIM ~~~ PR
PR ~~~ S4
end
factory --> bind --> cash --> claims --> corp
AYA Tower クオリーベイ本社と直属機能、代表的なソースシステム付き。
サンプル組織構造: これは主要な報告ラインです。完全な AYA 組織には、39 のベンダー統合全体にわたる追加の代理店地区、マカオおよび GBA チーム、シェアードサービス機能が含まれます。
flowchart TB
CEO[AYA Hong Kong]
CEO --> LIFE[Life & Savings]
CEO --> HLTH[Health & Employee Benefits]
CEO --> GI[General Insurance]
CEO --> DIST[Agency / banca / digital]
CEO --> CLM[Claims]
CEO --> FIN[Finance & actuarial]
CEO --> HR[Human resources]
CEO --> LEG[IT / legal / security]
カタログ stage がテーブルを基盤からコーポレートまでグループ化します。
サンプル内訳: これは成熟レイヤーに分散した 60 テーブル全体の代表スライスです。実際の分布は、基盤からコーポレートゴールドテーブルまでの完全なデータリネージを反映します。
flowchart LR F["foundation
~12 tables"] D["distribution
~10 tables"] P["policy & premium
~9 tables"] C["claims
~6 tables"] CO["finance & corporate
~23 tables"] F --> D --> P --> C F -.-> CO P -.-> CO
論理関係とアンカーキー。商品(product_code) と契約 (policy_number) が背骨です。クレームは FNOL と請求番号で結合します。
サンプル図: このエンティティ関係図は中核の論理モデルです。生成される完全な EDW には 60 のブロンズテーブル にわたって ベンダーシステム 39 追加の詳細テーブルとリネージ分岐付き。エンティティインスタンスは次を持ちます: entity_refs 出力されるすべてのイベントに付与し、結合可能性を検証します。
erDiagram
PRODUCT ||--o{ LIFE_POLICY : tariffs
PRODUCT ||--o{ GI_POLICY : tariffs
AGENT ||--o{ LIFE_POLICY : sells
AGENT ||--o{ GI_POLICY : sells
POLICYHOLDER ||--o{ LIFE_POLICY : owns
POLICYHOLDER ||--o{ GI_POLICY : owns
LIFE_POLICY ||--o{ HEALTH_CLAIM : incurs
GI_POLICY ||--o{ GI_CLAIM : notifies
GI_POLICY ||--o{ INVOICE : bills
LIFE_POLICY ||--o{ PREMIUM : collects
GI_CLAIM ||--o{ CESSION : cedes
ベンダー接頭辞 39、ブロンズテーブル 60。
表示しているサンプルシステム: 下図は代表的なベンダーシステムです。生成される完全データセットには、履歴バックフィルとライブストリーム全体のテーブルリネージと統合点を含む 39 システムすべてがあります。共有ソースシステムマニフェストは kb/source_systems/ は業界横断で再利用されます — AYA が追加する aya_product, aya_agency, aya_digital、および aya_health を業界固有の内部システムとして加え、さらに分割 PAS(Guidewire + Ingenium)を使います。
各テーブルは次に従います: {source_system_}__{entity} 命名規則(例: aya_product__product, guidewire_cc__claim)。各製品の実エクスポートスキーマに基づくベンダー固有の列形状と外部キーを維持します。VibeBI はレコードをシルバーとゴールドへ昇格する際にマスタデータの適合を推論します。
flowchart TB
subgraph foundation["Foundation"]
direction TB
f1["aya_product · aya_agency · oracle_scm"]
f2["salesforce · workday · sap_s4 dimensions"]
end
subgraph distribution["Distribution"]
direction TB
d1["aya_digital · salesforce_cpq"]
d2["hubspot · marketo · google_analytics"]
end
subgraph policy["Policy & premium"]
direction TB
p1["swissre_magnum · dxc_ingenium"]
p2["guidewire_pc · guidewire_bc · fps · varicent"]
end
subgraph claims["Claims"]
direction TB
c1["guidewire_cc · fineos · aya_health · sap_fs_ri"]
end
subgraph corporate["Finance & corporate"]
direction TB
co1["prophet · bloomberg_aim · sap_s4 journals"]
co2["anaplan · adp · ukg · concur · coupa"]
co3["servicenow · okta · splunk · ironclad · onetrust"]
end
foundation --> distribution --> policy --> claims
foundation --> corporate
policy --> corporate
V2 OOP シミュレーション → ClickHouse のブロンズ。VibeBI セマンティクス → シルバー → ゴールドは同一インスタンス上。
OOP パス: kb/industries/aya/ がオペレーションの背骨とエンティティモデルを定義します。 AyaEnterpriseSimulation がドメインライフサイクルを順序づけます。 SourceSystem アダプターがベンダー固有の行を次へエクスポートします: aya_v2.
flowchart LR
subgraph kb["kb/industries/aya"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/aya"]
ORCH[AyaEnterpriseSimulation]
DOM["LifePolicy · GiPolicy
execute_lifecycle()"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse aya_v2
60 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-aya — 60秒ティックの実行: AyaEnterpriseSimulation.generate().
ライブ頻度: 各ティックは QuoteToBindToPremium と FnolToPay を実行します。ドメインオブジェクトが相関した見積、UW 決定、PAS 成約、FPS 収納、コミッション、FNOL、GL 行を放出します。本日のライブティックは香港の as_of 見積、FNOL、FPS、仕訳が日中に伸びます。スケールはティックごとに変わります(既定ベース 5)。必要な履歴スパンはバックフィルできます(--days N ライブスクリプトまたは CLI 上)。
flowchart LR
START([60s tick]) --> SIM[AyaEnterpriseSimulation.generate]
SIM --> FOUND[Portfolio.publish_foundation]
FOUND --> LIFE[LifePolicy lifecycles]
FOUND --> GI[GiPolicy lifecycles]
LIFE --> CORP[Health + investments + finance]
GI --> CORP
CORP --> EVT[SourceSystem events]
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
QuoteToBindToPremium と FnolToPay のステートマシン — 各遷移はベンダー行を放出するドメインメソッドです。
プロセスの背骨: 定義場所: kb/industries/aya/process_model.yaml. 遅延到着モード(PAS 発行ラグ、FPS クリアリング、コミッションバッチ、夜間 FNOL、再保険ボルデロー)と例外モード(UW リファー/謝絶、保険料失効、請求否認、一部支払)は、独立したランダム挿入ではなく同一エンティティのライフサイクルから分岐します。
flowchart LR
Q[quoted] --> UW[underwritten]
UW --> BIND[bound]
BIND --> BILL[billed]
BILL --> COL[collected]
COL --> COMM[commissioned]
COMM --> GL[posted_to_gl]
UW -.->|uw_decline| DEC[declined]
BILL -.->|lapse| LAPSE[premium_lapse]
flowchart LR
FNOL[fnol_submitted] --> OPEN[claim_opened]
OPEN --> RSV[reserved]
RSV --> PAY[paid]
PAY --> CLOSE[closed]
OPEN -.->|denied| DENY[claim_denied]
PAY -.->|partial| PART[partial_settlement]
すべてのテーブルに同じリネージ封筒。分類がライブ動作を駆動します。
サンプル分類: 60 のブロンズテーブルすべてが、この三分類パターン(スナップショット、トランザクション、イベント)に沿い、一貫したメタデータと状態追跡を持ちます。図はウェアハウス全体で使うパターンを示しています。
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["Product · agent · policyholder masters"]
S2[Daily foundation refresh]
end
subgraph txn["transaction"]
direction TB
T1["Policies · premiums · claims · GL"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["Digital sessions · FNOL · clinic visits"]
E2[Append each live tick]
end
BRONZE[("aya_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
デスクトップアプリ、サーバー、SimEDW サンプルデータをダウンロードし、午後のうちに最初のガバナンス済みウェアハウス構築を進められます。