五座完整模擬 EDW——Amazing(全通路電商)、Hilson(全球飯店集團)、P&C(消費品製造)、HKBC(香港全能銀行)與 AYA(香港綜合保險公司)——具備擬真廠商原生綱要、ClickHouse 中可銜接獎章架構的銅層,以及即時事件串流。為在 VibeBI 上測試語義層、維度建模與自助分析而建。
虛構公司聲明: 「Amazing」為完全虛構的公司,僅供示範之用。與 Amazon.com, Inc. 或任何真實公司均無關係、未經其背書,亦非意圖代表之。
Amazing 是一家全球全通路零售商,銷售數千萬種商品,涵蓋自有第一方庫存、第三方賣家市集與 Prime 訂閱方案。顧客經網站店面、行動應用與實體零售點購物;訂單由全球履約中心與直送供應商網路履行。
業務涵蓋廣告、金融服務與 B2B 批發,與消費電商並存——典型平日約產生 2,800 筆訂單表頭與 4,200 筆明細,並有 Prime Day 需求高峰(7 月 11–13 日),橫跨零售、網站、行銷與市集通路。
範例實體: 下表顯示代表性業務實體及其來源系統;完整 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 |
| 客服/顧客心聲 | 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 電商組織另含其他團隊、子部門與矩陣角色,涵蓋全部 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 秒一次的 tick,透過 AmazingEnterpriseSimulation.generate().
即時頻率: 每個 tick 執行當日 OrderToCash 狀態機——領域物件產出相關的 OMS、付款、WMS、帳單與 GL 列;規模隨 tick 變化(預設基數 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 客房區塊)、餐飲據點(MICROS Simphony POS)、業主/加盟報表(Oracle Fusion 報表)與企業職能——典型平日約產生 1,900 筆 PMS 訂房與 1,750 筆帳單表頭,並有 夏季旅遊高峰 (6–8 月),拉升各物業住房率、ADR、餐飲消費與忠誠活動。
範例實體: 下表顯示代表性業務實體及其來源系統;完整 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 |
| 餐飲據點 | 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 秒一次的 tick,透過 HilsonEnterpriseSimulation.generate().
即時頻率: 每個 tick 執行訂房到忠誠狀態機——領域物件產出相關的 CRS、PMS、帳單、餐飲、付款、忠誠與 GL 列;規模隨 tick 變化(預設基數 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 或任何真實消費品製造商均無關係、未經其背書,亦非意圖代表之。
P&C 是一家全球消費品製造行銷商——B2B2C 模式,經量販、會員倉儲、雜貨與電商通路,在約 180 個國家銷售日常用品。五大事業部(SBU)涵蓋織物與居家護理、嬰兒/女性/家庭護理、美容、健康護理與美容保養,約 12 個旗艦品牌(TidalWave、ComfortWrap、BrightSmile、EdgePro 等),以及八座製造工廠與三座區域配送中心。
業務涵蓋需求規劃、原物料採購、MES 生產、品質放行、製成品配送、零售客戶訂單、通路行銷與財務——每個模擬日產出相關的 MES 工單、Ariba 採購單、OMS 表頭、OTM 出貨與 SAP 分錄,並有 春季大掃除高峰 (3–4 月),拉升北美與 EMEA 的織物/居家護理需求、工廠產能與通路進貨。
範例實體: 下表顯示代表性業務實體及其來源系統;完整 EDW 另含其他實體、子類型與專用資料表(例如物聯網感測讀數、維護工單、通路促銷、CLM 修訂)涵蓋全部 60 張銅層資料表。在 V2 中, ProductionBatch 與 CustomerOrder 領域類別驅動 MakeToShipToSell 主軸。
| 實體 | 來源系統 | 範例資料表 |
|---|---|---|
| SBU/品牌層級 | pc_brand | brand · category |
| 製成品 SKU | akeneo_pim | sku · brand · category |
| 工廠/配送中心主檔 | oracle_scm | warehouse · office |
| 需求預測 | blueyonder | forecast_daily |
| 原物料採購單 | 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() 走完預測 → 採購 → 生產 → 品管放行 → 製成品; 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 | 製造工廠或配送中心登錄 |
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 包含全部 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
全球總部 Cincinnati 與直屬職能,搭配代表性來源系統。
範例組織結構: 此圖顯示主要報告線;完整 P&C 組織另含區域 SBU 團隊、工廠經理與共享服務職能,涵蓋全部 34 項廠商整合。
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 秒一次的 tick,透過 PcEnterpriseSimulation.generate().
即時頻率: 每個 tick 執行 MakeToShipToSell 狀態機——領域物件依生產批次與零售客戶訂單產出相關的預測、PO、MES、WMS、OMS、OTM 與 GL 列;規模隨 tick 變化(預設基數 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」是僅為示範目的建立的完全虛構公司。它不隸屬、不獲匯豐控股、香港上海滙豐銀行有限公司或任何真實銀行背書,也不意在代表它們。
HKBC (Hong Kong Banking Corporation)是一家總部位於中環的香港全能銀行,涵蓋財富及個人銀行、商業銀行、環球銀行及市場。該特許經營吸收港元存款、發放 HIBOR 按揭與無擔保信貸、發卡、全天候運行更快支付系統與 PearlPay(PayMe 級)清算通道、為粵港澳大灣區貿易融資,並在 7.75–7.85 兌換波幅內記帳美元/港元及離岸人民幣外匯。
帳簿覆蓋港島、九龍與新界約 10 家分行,外加前海大灣區批發交易台與倫敦市場交易台——每個模擬日產生相關聯的 FPS 貸記、卡授權、CHATS/SWIFT 匯款、核心複式記帳、AML 預警與 SAP 分錄,並帶有 農曆新年/第一季稅務貸款高峰 推升 PearlPay 點對點量、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 |
| 外匯/市場 | 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 預警 → 日終存款餘額 → 總帳。 HkbcPortfolio.publish_foundation() 在支付執行前主資料化分行、產品、CIF 客戶與帳戶。服務物件發出商業銀行貿易、環球市場外匯、財富、風險與企業列。
| 領域實體 | 自然鍵 | 生命週期方法 |
|---|---|---|
Branch | branch_code | 在 hkbc_core 中主資料化的分行 / 批發交易台 |
Product | product_code | 往來/儲蓄、按揭、卡、錢包、貿易、外匯產品目錄 |
Customer | customer_id | CIF + KYC 分群;Salesforce 中的 CRM 鏡像 |
Account | account_id | publish() → post_pair() 平衡分錄 |
FpsPayment | payment_id | execute_lifecycle() → 清算通道 → 記帳 → AML |
DocumentaryCredit | lc_id | 商業銀行信用狀/保函簽發 |
FxTrade | trade_id | Murex 成交 → 美元/港元頭寸 |
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 包含全部 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 個廠商整合中的更多區域分行、大灣區交易台以及共享服務職能。
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 秒一次的 tick,透過 HkbcEnterpriseSimulation.generate().
即時頻率: 每個節拍執行 PayToPostToBalance 狀態機——領域物件發出相關聯的 FPS、PearlPay、卡、CHATS、SWIFT、核心記帳、AML 與總帳列;今日的即時節拍只發出截至香港 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 回執時滯、授權後的卡清算、AML 案件時滯、總帳批次延遲)與例外模式(FPS 拒絕、卡片拒付、AML 凍結、餘額不足、信用狀不符)從同一實體生命週期分支,而非獨立隨機插入。
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 香港及澳門或任何真實保險公司背書,也不意在代表它們。
AYA 是一家香港綜合保險公司——壽險及儲蓄、健康(含自願醫保與僱員福利)及一般保險——經專屬代理、銀保、經紀、Aria by AYA 數位應用與嵌入式電子錢包夥伴分銷。總部位於鰂魚涌,中環設顧問中心,尖沙咀設 AYA 醫療中心,另有澳門分公司與前海大灣區銷售辦事處。
業務涵蓋產品工廠、Magnum 級核保、拆分 PAS(壽險走 Ingenium 級、一般保險走 Guidewire)、FPS 保費收款、Varicent 佣金、全天候車險/旅遊 FNOL、FINEOS 健康理賠、再保險分出、Prophet IFRS 17 估值與 SAP S/4 分錄——並帶有 颱風季一般保險理賠上升 (六月至十月)以及數位與代理通路上的農曆新年旅遊/北上汽車險高峰。
範例實體: 下表展示代表性業務實體及其來源系統;完整 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 |
| 總帳/IFRS 17 | sap_s4 | journal_entry · journal_line |
AyaEnterpriseSimulation 串接當日;領域物件擁有產出邏輯。
QuoteToBindToPremium 是新業務主軸; FnolToPay 是理賠主軸。 LifePolicy.execute_lifecycle() 走報價 → Magnum 核保 → Ingenium 出單 → FPS 收款 → 佣金 → 總帳。 GiPolicy.execute_lifecycle() 走報價 → PolicyCenter 承保 → BillingCenter 帳單 → ClaimCenter 上可選的當日 FNOL。 AyaPortfolio.publish_foundation() 在保單執行前主資料化產品、代理人、職場與投保人。
| 領域實體 | 自然鍵 | 生命週期方法 |
|---|---|---|
InsuranceProduct | product_code | aya_product 中的壽險/健康/一般保險費率 |
Agent | agent_id | 保險業監管局牌照登記 + Salesforce 中介 |
Policyholder | sf_account_id | 大眾/高淨值/中小企/雇主 CRM |
LifePolicy | policy_number | publish_quote() → 核保 → 承保 → 收款 → 佣金 → 總帳 |
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 個廠商整合中的更多代理區域、澳門與大灣區團隊以及共享服務職能。
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 秒一次的 tick,透過 AyaEnterpriseSimulation.generate().
即時頻率: 每個節拍執行 QuoteToBindToPremium 與 FnolToPay——領域物件發出相關聯的報價、核保決定、PAS 承保、FPS 收款、佣金、FNOL 與總帳列;今日的即時節拍只發出截至香港 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、再保險帳單)與例外模式(核保轉介/拒保、保費失效、拒賠、部分給付)從同一實體生命週期分支,而非獨立隨機插入。
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