À l'échelle entreprise entrepôts d'exemple.

Profil société

Avis société fictive : « AYA » est une entreprise entièrement fictive, créée uniquement à des fins de démonstration. Elle n'est pas affiliée à AXA SA, AXA Hong Kong and Macau, ni à aucune compagnie d'assurance réelle, n'est pas approuvée par elles et n'est pas destinée à les représenter.

AYA est un assureur composite de Hong Kong — Life & Savings, Health (y compris VHIS et avantages salariés) et General Insurance — distribué via agents liés, bancassurance, courtiers, l'application Aria by AYA et des partenaires e-wallet embarqués. Le siège est à Quarry Bay, avec un centre de conseil à Central, l'AYA Medical Centre à Tsim Sha Tsui, une succursale à Macao et un bureau commercial GBA à Qianhai.

L'activité couvre l'usine produit, la souscription classe Magnum, un PAS scindé (vie sur Ingenium, IARD sur Guidewire), l'encaissement de primes FPS, la commission Varicent, le FNOL auto/voyage 24×7, les sinistres santé FINEOS, la cession de réassurance, la valorisation Prophet IFRS 17 et les journaux SAP S/4 — avec un hausse des sinistres IARD en saison des typhons (juin–octobre) et un pic voyage CNY / motorisation northbound sur les canaux digitaux et agence.

Entités d'exemple : Le tableau ci-dessous montre des entités métier représentatives et leurs systèmes source ; l'EDW complet inclut des entités, sous-types et tables spécialisées supplémentaires (p. ex. Prophet BEL/CSM, cessions de traités, visites de centre médical, redlines CLM) sur les 60 tables bronze. En V2, LifePolicy et GiPolicy les classes de domaine pilotent les épines QuoteToBindToPremium et FnolToPay.

Modèle de domaine OOP

AyaEnterpriseSimulation enchaîne la journée ; les objets de domaine possèdent la logique d'émission.

QuoteToBindToPremium est l'épine new business ; FnolToPay est l'épine sinistres. LifePolicy.execute_lifecycle() parcourt devis → UW Magnum → émission Ingenium → encaissement FPS → commission → GL. GiPolicy.execute_lifecycle() parcourt devis → bind PolicyCenter → facture BillingCenter → FNOL same-day optionnel sur ClaimCenter. AyaPortfolio.publish_foundation() maîtrise produits, agents, bureaux et souscripteurs avant l'exécution des polices.

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]
          

Chaîne de valeur quote-to-claim

De l'usine produit à la distribution, au bind, à l'encaissement, aux sinistres et à la clôture finance.

Vue d'exemple : Ceci illustre la chaîne de valeur principale à travers l'écosystème AYA ; l'EDW généré complet inclut les 39 systèmes source avec intégrations transverses, visites cashless du centre médical et comptabilité de traités non représentées ici.

%%{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
          

Organisation fonctionnelle par département

Siège AYA Tower Quarry Bay et fonctions en report direct avec des systèmes source représentatifs.

Structure d'org d'exemple : Ceci montre les lignes de reporting primaires ; l'organisation AYA complète inclut des districts d'agence supplémentaires, des équipes Macao et GBA, et des fonctions de shared services sur les 39 intégrations fournisseur.

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]
          

Stades de maturité EDW

Catalogue stage regroupe les tables, des fondations jusqu'au corporate.

Répartition d'exemple affichée : Ceci est une coupe représentative de l'inventaire complet de 60 tables réparti sur les couches de maturité ; la distribution réelle reflète le lignage de données complet, des fondations jusqu'aux tables gold corporate.

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
          

Entités métier cœur

Relations logiques et clés d'ancrage. Produit (product_code) et police (policy_number) forment l'épine ; les sinistres joignent via FNOL et numéros de sinistre.

Diagramme d'exemple : Ce diagramme de relations d'entités montre le modèle logique cœur ; l'EDW généré complet contient 60 tables bronze sur 39 systèmes fournisseur avec des tables de détail supplémentaires et des branches de lignage. Les instances d'entités portent entity_refs sur chaque événement émis pour tester la joignabilité.

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
          

Paysage des systèmes source

39 préfixes fournisseur, 60 tables bronze.

Systèmes d'exemple affichés : Le schéma ci-dessous illustre des systèmes fournisseur représentatifs ; le jeu de données généré complet inclut les 39 systèmes avec leur lignage de tables et points d'intégration sur le backfill d'historique et les flux live. Les manifests de systèmes source partagés dans kb/source_systems/ sont réutilisés entre secteurs — AYA ajoute aya_product, aya_agency, aya_digital, et aya_health comme systèmes internes spécifiques au secteur, plus un PAS scindé (Guidewire + Ingenium).

Chaque table suit la {source_system_}__{entity} convention de nommage (p. ex. aya_product__product, guidewire_cc__claim), en préservant la forme de colonnes native du fournisseur et les clés étrangères du schéma d'export réel de chaque produit. VibeBI infère la conformation des données de référence lorsqu'il promeut les enregistrements vers silver et gold.

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
          

Flux de données de bout en bout

Simulation OOP V2 → bronze dans ClickHouse ; sémantique VibeBI → silver → gold sur la même instance.

Chemin OOP : kb/industries/aya/ définit l'épine dorsale opérationnelle et le modèle d'entités ; AyaEnterpriseSimulation enchaîne les cycles de vie de domaine ; SourceSystem les adaptateurs exportent des lignes natives fournisseur dans 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
          

Cycle bronze en direct

./live-v2-aya — tick de 60 s via AyaEnterpriseSimulation.generate().

Fréquence en direct : Chaque tick exécute QuoteToBindToPremium et FnolToPay — les objets de domaine émettent des devis, décisions UW, binds PAS, encaissements FPS, commissions, FNOL et lignes GL corrélés ; les ticks live d'aujourd'hui n'émettent que les événements jusqu'à Hong Kong as_of afin que devis, FNOL, FPS et journaux croissent dans la journée. L'échelle varie par tick (base 5 par défaut). Remplissez toute plage d'historique dont vous avez besoin (--days N sur le script live ou le 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
          

Graphes d'événements quote-to-bind et FNOL

Machines d'états QuoteToBindToPremium et FnolToPay — chaque transition est une méthode de domaine qui émet des lignes fournisseur.

Épine processuelle : Défini dans kb/industries/aya/process_model.yaml. Les modes d'arrivée tardive (lag d'émission PAS, compensation FPS, lot de commissions, FNOL de nuit, bordereau de réassurance) et les modes d'exception (référé/refus UW, laps de prime, sinistre refusé, règlement partiel) partent des mêmes cycles de vie d'entité plutôt que d'insertions aléatoires indépendantes.

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]
          

Catégories de tables bronze

Même enveloppe de lignage sur chaque table ; la catégorie pilote le comportement live.

Catégories d'exemple : Les 60 tables bronze suivent ce schéma à trois catégories (snapshot, transaction, événement) avec des métadonnées et un suivi d'état cohérents ; le diagramme illustre le motif utilisé dans tout l'entrepôt.

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
          

Profil société

Avis société fictive : « Smire » est une entreprise entièrement fictive, créée uniquement à des fins de démonstration. Elle n'est affiliée à Swire Properties Limited, Swire Pacific Limited, ni à aucune société immobilière réelle, n'est pas approuvée par elles et n'est pas destinée à les représenter.

Smire Properties est un bailleur mixed-use de Hong Kong, dont le siège est à Smire Tower, Quarry Bay — campus de bureaux Grade A (Eastgate Place, Harbour Place), malls (Harbourplaza, Peakgate Outlets, Eastgate Li), résidentiel et hôtels Harbour House, plus du retail style Taikoo Li en Chine continentale à Pékin, Shanghai, Canton et Chengdu.

Le livre couvre les offres de leasing vers baux Yardi et rent rolls quotidiennes, loyer de base plus loyer sur CA retail issu du POS mall, encaissement HK FPS / CNY, journaux NOI SAP S/4, GTB quasi temps réel, événements badge Nedap, parking et fréquentation mall 11:00–22:00 HKT, plus GAV/NAV Argus, comps style CoStar, tirages CAPEX de développement et occupancy/ADR/RevPAR hôteliers — avec un pic d’activité mall CNY qui relève la fréquentation de Harbourplaza et Eastgate Li, le loyer sur CA et les encaissements FPS.

Entités d'exemple : Le tableau ci-dessous montre des entités métier représentatives et leurs systèmes source ; l’EDW complet inclut des entités, sous-types et tables spécialisées supplémentaires (p. ex. compteurs ESG, tirages CAPEX, occupation hôtelière, redlines CLM) sur les 60 tables bronze. En V2, Lease et Tenant les classes de domaine pilotent les épines LeaseToCollect et MallTradingDay.

Modèle de domaine OOP

SmireEnterpriseSimulation enchaîne la journée ; les objets de domaine possèdent la logique d'émission.

LeaseToCollect est l’épine leasing ; MallTradingDay est l’épine ops retail. Lease.execute_lifecycle() enchaîne offre → bail et rent roll Yardi → facture (base plus loyer sur CA) → encaissement FPS → journal NOI. Tenant.publish() maîtrise Yardi et Salesforce avant que les baux ne s’exécutent. SmirePortfolio.publish_foundation() maîtrise d’abord properties, buildings, unités louables et sites.

flowchart LR
  PORT[SmirePortfolio.publish_foundation]
  TNT[Tenant.publish]
  LS[Lease.execute_lifecycle]
  PORT --> TNT
  TNT --> LS
  LS --> OFF[leasing offer]
  OFF --> YAR[Yardi lease / invoice]
  YAR --> FPS[FPS collect]
  FPS --> GL[SAP S/4 NOI]
  PORT --> MALL[Mall POS + footfall]
  MALL --> YAR
          

Chaîne de valeur lease-to-collect

Du master portefeuille au close finance, via leasing, trading mall et ops d’actifs.

Vue d'exemple : Ceci illustre la chaîne de valeur principale à travers l’écosystème Smire ; l’EDW généré complet inclut les 39 systèmes source avec intégrations transverses, RevPAR hôtelier et CAPEX de développement non représentés ici.

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
  subgraph portfolio["Portfolio"]
    direction TB
    PORT[smire_portfolio]
    SCM[oracle_scm]
    PORT ~~~ SCM
  end
  subgraph lease["Lease & collect"]
    direction TB
    OFF[smire_leasing]
    YAR[yardi_voyager]
    FPS[fps]
    OFF ~~~ YAR
    YAR ~~~ FPS
  end
  subgraph ops["Operate asset"]
    direction TB
    MALL[smire_mall]
    BMS[honeywell_bms]
    AEOS[nedap_aeos]
    MALL ~~~ BMS
    BMS ~~~ AEOS
  end
  subgraph value["Value & hotels"]
    direction TB
    ARG[argus_enterprise]
    HOT[smire_hotel]
    DEV[smire_dev]
    ARG ~~~ HOT
    HOT ~~~ DEV
  end
  subgraph close["NOI close"]
    direction TB
    S4[sap_s4]
    CST[costar_analytics]
    S4 ~~~ CST
  end
  portfolio --> lease --> ops --> value --> close
          

Organisation fonctionnelle par département

Siège Smire Tower Quarry Bay et fonctions en report direct avec des systèmes source représentatifs.

Structure d'org d'exemple : Ceci montre les lignes de reporting primaires ; l’organisation Smire complète inclut des bureaux de property management supplémentaires, des équipes mall en Chine continentale et des fonctions de shared services sur les 39 intégrations fournisseur.

flowchart TB
  CEO[Smire Properties]
  CEO --> OFF[Office]
  CEO --> RET[Retail]
  CEO --> RES[Residential]
  CEO --> HOT[Hotels]
  CEO --> DEV[Development]
  CEO --> FIN[Finance]
  CEO --> HR[Human resources]
  CEO --> LEG[IT / legal / security]
          

Stades de maturité EDW

Catalogue stage regroupe les tables, des fondations jusqu'au corporate.

Répartition d'exemple affichée : Ceci est une coupe représentative de l'inventaire complet de 60 tables réparti sur les couches de maturité ; la distribution réelle reflète le lignage de données complet, des fondations jusqu'aux tables gold corporate.

flowchart LR
  F["portfolio
~10 tables"]
  L["leasing
~8 tables"]
  O["operations
~10 tables"]
  V["valuation
~8 tables"]
  CO["corporate
~24 tables"]
  F --> L --> O --> V
  F -.-> CO
  L -.-> CO
          

Entités métier cœur

Relations logiques et clés d'ancrage. Établissement (property_code) et unité (unit_id) forment l’épine ; les baux joignent via lease_id et FPS via facture.

Diagramme d'exemple : Ce diagramme de relations d'entités montre le modèle logique cœur ; l'EDW généré complet contient 60 tables bronze sur 39 systèmes fournisseur avec des tables de détail supplémentaires et des branches de lignage. Les instances d'entités portent entity_refs sur chaque événement émis pour tester la joignabilité.

erDiagram
  PROPERTY ||--o{ BUILDING : contains
  BUILDING ||--o{ UNIT : lets
  UNIT ||--o{ LEASE : occupies
  TENANT ||--o{ LEASE : signs
  LEASE ||--o{ INVOICE : bills
  INVOICE ||--o{ FPS_PAYMENT : collects
  TENANT ||--o{ MALL_SALE : trades
  PROPERTY ||--o{ VALUATION : values
          

Paysage des systèmes source

39 préfixes fournisseur, 60 tables bronze.

Systèmes d'exemple affichés : Le schéma ci-dessous illustre des systèmes fournisseur représentatifs ; le jeu de données généré complet inclut les 39 systèmes avec leur lignage de tables et points d'intégration sur le backfill d'historique et les flux live. Les manifests de systèmes source partagés dans kb/source_systems/ sont réutilisés entre secteurs — Smire ajoute smire_portfolio, smire_leasing, smire_mall, et smire_hotel comme systèmes internes spécifiques au secteur, plus Yardi Voyager et Argus.

Chaque table suit la {source_system_}__{entity} convention de nommage (p. ex. smire_portfolio__unit, yardi_voyager__lease), en préservant la forme de colonnes native du fournisseur et les clés étrangères du schéma d'export réel de chaque produit. VibeBI infère la conformation des données de référence lorsqu'il promeut les enregistrements vers silver et gold.

flowchart TB
  subgraph foundation["Portfolio"]
    direction TB
    f1["smire_portfolio property · building · unit"]
    f2["oracle_scm · salesforce · workday · sap_s4 dimensions"]
  end
  subgraph leasing["Leasing"]
    direction TB
    l1["smire_leasing · yardi_voyager · fps"]
  end
  subgraph operations["Operations"]
    direction TB
    o1["smire_mall · honeywell_bms · nedap_aeos · smire_park"]
    o2["smire_hotel · smire_esg · smire_loyalty"]
  end
  subgraph valuation["Valuation"]
    direction TB
    v1["argus_enterprise · costar_analytics · smire_dev · smire_residential"]
  end
  subgraph corporate["Corporate"]
    direction TB
    co1["sap_s4 journals · anaplan · adp · ukg · concur"]
    co2["hubspot · marketo · zendesk · servicenow · okta"]
    co3["splunk · ironclad · onetrust · greenhouse"]
  end
  foundation --> leasing --> operations --> valuation
  foundation --> corporate
  leasing --> corporate
          

Flux de données de bout en bout

Simulation OOP V2 → bronze dans ClickHouse ; sémantique VibeBI → silver → gold sur la même instance.

Chemin OOP : kb/industries/smire/ définit l'épine dorsale opérationnelle et le modèle d'entités ; SmireEnterpriseSimulation enchaîne les cycles de vie de domaine ; SourceSystem les adaptateurs exportent des lignes natives fournisseur dans smire_v2.

flowchart LR
  subgraph kb["kb/industries/smire"]
    SPINE[entity + process models]
  end
  subgraph sim["sim/industries/smire"]
    ORCH[SmireEnterpriseSimulation]
    DOM["Lease.execute_lifecycle()
Tenant · Property · Unit"]
  end
  subgraph simedw["SimEDW V2"]
    ADP[SourceSystem adapters]
    CHB[("ClickHouse smire_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
          

Cycle bronze en direct

./live-v2-smire — tick de 60 s via SmireEnterpriseSimulation.generate().

Fréquence en direct : Chaque tick exécute LeaseToCollect et MallTradingDay — les objets de domaine émettent des offres, baux, factures, encaissements FPS, POS mall, fréquentation, événements badge et lignes GL corrélés ; les ticks live d’aujourd’hui n’émettent que les événements jusqu’à Hong Kong as_of afin que rent rolls, trading mall, GTB et journaux croissent dans la journée. L’échelle varie par tick (base 5 par défaut). Rechargez toute période d’historique dont vous avez besoin (--days N sur le script live ou le CLI).

flowchart LR
  START([60s tick]) --> SIM[SmireEnterpriseSimulation.generate]
  SIM --> FOUND[Portfolio.publish_foundation]
  FOUND --> TNT[Tenant.publish]
  TNT --> LS[Lease lifecycles]
  FOUND --> OPS[Mall · BMS · hotel]
  LS --> CORP[NOI + valuation + finance]
  OPS --> CORP
  CORP --> EVT[SourceSystem events]
  EVT --> BRZ[Append bronze rows]
  BRZ --> WAIT[Sleep] --> START
          

Graphes d’événements lease-to-collect et actifs

Machines d’état LeaseToCollect et OperateAsset — chaque transition est une méthode de domaine qui émet des lignes fournisseur.

Épine processuelle : Défini dans kb/industries/smire/process_model.yaml. Les modes d’arrivée tardive (lag de clearing FPS, délai de posting GL, BMS de nuit, lag de work-order) et les modes d’exception (vacance, impayés, accès refusé, alarme technique) partent des mêmes cycles de vie d’entité plutôt que d’inserts aléatoires indépendants.

flowchart LR
  OFF[offered] --> LS[leased]
  LS --> OCC[occupied]
  OCC --> INV[invoiced]
  INV --> COL[collected]
  COL --> GL[posted_to_gl]
  LS -.->|vacancy| VAC[vacancy]
  INV -.->|arrears| ARR[arrears]
          

flowchart LR
  MTR[metered] --> ACC[accessed]
  ACC --> WO[work_ordered]
  WO --> VAL[valued]
  ACC -.->|denied| DEN[access_denied]
  MTR -.->|alarm| ALM[plant_alarm]
          

Catégories de tables bronze

Même enveloppe de lignage sur chaque table ; la catégorie pilote le comportement live.

Catégories d'exemple : Les 60 tables bronze suivent ce schéma à trois catégories (snapshot, transaction, événement) avec des métadonnées et un suivi d'état cohérents ; le diagramme illustre le motif utilisé dans tout l'entrepôt.

flowchart LR
  subgraph snap["snapshot"]
    direction TB
    S1["Property · unit · tenant masters"]
    S2[Daily foundation refresh]
  end
  subgraph txn["transaction"]
    direction TB
    T1["Leases · invoices · FPS · GL"]
    T2[Append each live tick]
  end
  subgraph evt["event"]
    direction TB
    E1["Footfall · badge · BMS · park"]
    E2[Append each live tick]
  end
  BRONZE[("smire_v2 bronze row")]
  snap --> BRONZE
  txn --> BRONZE
  evt --> BRONZE
          

Profil société

Avis société fictive : « Hilson » est une société entièrement fictive, créée uniquement à des fins de démonstration. Elle n'est ni affiliée à Hilton Inc. ni à Hyatt Hotels Corporation, ni cautionnée par elles, et n'est pas destinée à représenter Hilton Inc., Hyatt Hotels Corporation, ni aucune société d'hospitalité réelle.

Hilson Hospitality Group est un opérateur hôtelier mondial avec ~680 établissements sur 18 marques — des drapeaux luxe (niveau Waldorf, niveau Conrad) au full-service (Hilson, niveau DoubleTree) jusqu'aux paliers select-service et extended-stay. Chaque établissement exploite un Opera PMS on-premise et un Amadeus CRS central, au service d'un mix de clients loisirs en transient, corporate négocié, et groupes/conventions.

L'activité couvre la fidélité (Hilson Honors avec des millions de membres), les ventes groupes et conventions (pipeline salesforce, blocs de chambres CPQ), les points de vente food & beverage (MICROS Simphony POS), le reporting propriétaire/franchise (relevés Oracle Fusion), et les fonctions corporate — générant environ 1 900 réservations PMS et 1 750 en-têtes de folio un jour ouvré typique, avec un pic de voyages d'été (juin–août) qui fait progresser l'occupation, l'ADR, les dépenses F&B et l'activité fidélité sur l'ensemble des établissements.

Entités d'exemple : Le tableau ci-dessous présente des entités métier représentatives et leurs systèmes source ; l'EDW complet inclut des entités supplémentaires, des sous-types et des tables spécialisées (p. ex. événements de canaux OTA, restrictions de plans tarifaires, accords juridiques de franchise, redlines deal-desk) sur l'ensemble des 62 tables bronze. En V2, StayReservation et les classes de domaine associées émettent des lignes PMS, CRS, folio et fidélité via des adaptateurs de systèmes source à mesure que le cycle de vie du séjour progresse.

Modèle de domaine OOP

HilsonEnterpriseSimulation enchaîne la journée ; les objets de domaine possèdent la logique d'émission.

ReservationToLoyaltyAndOwnerReporting est l'épine dorsale processuelle principale. StayReservation.execute_lifecycle() parcourt réservation → sync PMS → charges folio → paiement → points fidélité → snapshot d'occupation → relevé propriétaire → GL. HilsonPortfolio.publish_foundation() maîtrise les marques, les établissements et les membres Honors avant l'exécution des réservations.

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]
          

Chaîne de valeur client et établissement

De la maîtrise marque et établissement jusqu'à la distribution, le séjour, le règlement et le reporting propriétaire.

Vue d'exemple : Ceci illustre la chaîne de valeur principale à travers l'écosystème Hilson ; l'EDW généré complet inclut les 31 systèmes source avec intégrations transverses, flux de revenus secondaires et cycles de vie fidélité non représentés ici.

%%{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
          

Organisation fonctionnelle par département

Siège d'entreprise et fonctions en report direct, avec des systèmes source représentatifs.

Structure d'org d'exemple : Ceci montre les lignes de reporting principales ; l'organisation Hilson complète inclut un management régional supplémentaire, des équipes spécifiques aux marques et des fonctions de services partagés sur les 31 intégrations fournisseurs.

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]
          

Stades de maturité EDW

Catalogue stage regroupe les tables, des fondations jusqu'au corporate.

Répartition d'exemple affichée : Ceci est une coupe représentative de l'inventaire complet de 62 tables réparti sur les couches de maturité ; la distribution réelle reflète le lignage de données complet, des fondations jusqu'aux tables gold corporate.

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
          

Entités métier cœur

Relations logiques et clés d'ancrage. Établissement (hotel_code) est l'épine dorsale ; identité client via Honors et les tables de séjour.

Diagramme d'exemple : Ce diagramme de relations d'entités montre le modèle logique cœur ; l'EDW généré complet contient 62 tables bronze sur 31 systèmes fournisseurs avec des milliers de tables de détail supplémentaires et de branches de lignage.

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
          

Paysage des systèmes source

31 préfixes fournisseurs, 62 tables bronze.

Systèmes d'exemple affichés : Le diagramme ci-dessous illustre des systèmes fournisseurs représentatifs ; le jeu de données généré complet inclut les 31 systèmes avec leur lignage de tables complet et leurs points d'intégration sur le backfill historique et les flux live.

Chaque table suit la {source_system_}__{entity} convention de nommage (p. ex. oracle_opera__reservation, hilson_loyalty__member), en préservant la forme de colonnes native du fournisseur et les clés étrangères du schéma d'export réel de chaque produit. VibeBI infère la conformation des données de référence lorsqu'il promeut les enregistrements vers silver et gold.

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
          

Flux de données de bout en bout

Simulation OOP V2 → bronze dans ClickHouse ; sémantique VibeBI → silver → gold sur la même instance.

Chemin OOP : kb/industries/hilson/ définit l'épine dorsale opérationnelle et le modèle d'entités ; HilsonEnterpriseSimulation enchaîne les cycles de vie de domaine ; SourceSystem les adaptateurs exportent des lignes natives fournisseur dans 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
          

Cycle bronze en direct

./live-v2-hilson — tick de 60 s via HilsonEnterpriseSimulation.generate().

Fréquence en direct : Chaque tick exécute la machine à états réservation-vers-fidélité — les objets de domaine émettent des lignes corrélées CRS, PMS, folio, F&B, paiement, fidélité et GL ; l'échelle varie par tick (base par défaut 5). Reconstituez n'importe quelle profondeur d'historique dont vous avez besoin (--days N) ; Hilson inclut la détection de lacunes sur la table d'ancrage des réservations.

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
          

Graphe d'événements de séjour

Machine à états ReservationToLoyaltyAndOwnerReporting — chaque transition émet des lignes fournisseur.

Épine processuelle : Défini dans kb/industries/hilson/process_model.yaml. Les modes d'exception (no-shows, rétrofacturations, surclassements de chambre) se ramifient à partir du même cycle de vie d'entité, plutôt que d'insertions aléatoires indépendantes.

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]
          

Catégories de tables bronze

Même enveloppe de lignage sur chaque table ; la catégorie pilote le rafraîchissement live vs l'append en micro-batch.

Catégories d'exemple : Les 62 tables bronze suivent ce schéma à trois catégories (snapshot, transaction, événement) avec des métadonnées et un suivi d'état cohérents ; le diagramme illustre le motif utilisé dans tout l'entrepôt.

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
          

Profil société

Avis société fictive : « Cathea » est une entreprise entièrement fictive, créée uniquement à des fins de démonstration. Elle n'est affiliée à Cathay Pacific Airways Limited, Cathay Pacific Group, ni à aucune compagnie aérienne réelle, n'est pas approuvée par elles et n'est pas destinée à les représenter.

Cathea Pacific est une compagnie de hub de Hong Kong, dont le siège est à Cathea City, Chek Lap Kok — passager premium (HP), fret aérien et Cathea Cargo Terminal, LCC Peak Express (PX) et cargo Air Harbour Express (AH), plus le lifestyle Pacific Miles. Le réseau est calé sur HKG : rotations long-courrier A350/777, vagues nocturnes 747-8F et sauts régionaux A321neo.

La journée enchaîne commande NDC → PNR classe Altéa et e-ticket préfixe 168 → capture carte Adyen → enregistrement DCS et scans bagages → OFP Navblue, duty équipage AIMS et MVT SITA (y compris cargo de nuit 01:00–05:00 HKT) → accrual Pacific Miles et rating Accelya → journaux SAP S/4. Le cargo suit réservation Cargospot → LTA → acceptation terminal → scan ULD → mouvement → trucking OTM → encaissement FPS — avec un hausse voyage CNY / IRROPS typhon qui fait spiker le load factor Peak Express, les scans bagages et les waitlists cargo.

Entités d'exemple : Le tableau ci-dessous montre des entités métier représentatives et leurs systèmes source ; l’EDW complet inclut des entités, sous-types et tables spécialisées supplémentaires (p. ex. fuel uplifts, work orders TRAX, scans ULD, accruals loyalty) sur les 60 tables bronze. En V2, Pnr et AirWaybill les classes de domaine pilotent les épines OfferToFlyToRevenue et BookToDeliverCargo.

Modèle de domaine OOP

CatheaEnterpriseSimulation enchaîne la journée ; les objets de domaine possèdent la logique d'émission.

OfferToFlyToRevenue est l’épine passager ; BookToDeliverCargo est l’épine cargo. Pnr.execute_lifecycle() enchaîne commande NDC → PNR et e-ticket Altéa → capture Adyen → enregistrement DCS → coupon volé → Pacific Miles → Accelya → GL. AirWaybill.execute_lifecycle() enchaîne réservation Cargospot → LTA → acceptation CHT → ULD → mouvement SITA → trucking OTM → encaissement FPS. CatheaPortfolio.publish_foundation() maîtrise avions, routes, stations et vols calés sur HKG avant que les PNR et LTA ne s’exécutent.

flowchart LR
  PORT[CatheaPortfolio.publish_foundation]
  PNR[Pnr.execute_lifecycle]
  AWB[AirWaybill.execute_lifecycle]
  PORT --> PNR
  PORT --> AWB
  PNR --> NDC[NDC order]
  NDC --> PSS[Altéa PNR / ticket]
  PSS --> DCS[DCS check-in]
  DCS --> GL[SAP S/4 journal]
  AWB --> CS[Cargospot AWB]
  CS --> CHT[CHT + ULD]
  CHT --> FPS[FPS collect]
          

Chaîne de valeur offer-to-fly et cargo

Du master réseau au close finance, via passager, cargo et ops.

Vue d'exemple : Ceci illustre la chaîne de valeur principale à travers l’écosystème Cathea ; l’EDW généré complet inclut les 40 systèmes source avec intégrations transverses, vagues cargo de nuit et MRO TRAX non représentés ici.

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
  subgraph network["Network"]
    direction TB
    NET[cathea_network]
    SCM[oracle_scm station]
    NET ~~~ SCM
  end
  subgraph fly["Offer to fly"]
    direction TB
    NDC[cathea_ndc]
    PSS[amadeus_altea]
    DCS[amadeus_dcs]
    ADY[adyen]
    NDC ~~~ PSS
    PSS ~~~ DCS
  end
  subgraph cargo["Cargo"]
    direction TB
    CS[champ_cargospot]
    CHT[cathea_cht]
    OTM[oracle_otm]
    FPS[fps]
    CS ~~~ CHT
    CHT ~~~ OTM
  end
  subgraph ops["Ops"]
    direction TB
    NAV[navblue]
    AIMS[aims_crew]
    SITA[sita_typeb]
    NAV ~~~ AIMS
    AIMS ~~~ SITA
  end
  subgraph close["Revenue & close"]
    direction TB
    PM[cathea_loyalty]
    RA[accelya_ra]
    S4[sap_s4]
    PM ~~~ RA
    RA ~~~ S4
  end
  network --> fly --> cargo --> ops --> close
          

Organisation fonctionnelle par département

Siège Cathea City Chek Lap Kok et fonctions en report direct avec des systèmes source représentatifs.

Structure d'org d'exemple : Ceci montre les lignes de reporting primaires ; l’organisation Cathea complète inclut des outstations supplémentaires, des desks cargo GBA et des fonctions de shared services sur les 40 intégrations fournisseur.

flowchart TB
  CEO[Cathea Pacific]
  CEO --> PREM[Premium Travel]
  CEO --> CARGO[Cargo & Logistics]
  CEO --> LCC[Peak Express LCC]
  CEO --> LIFE[Pacific Miles]
  CEO --> OPS[Flight ops]
  CEO --> FIN[Finance]
  CEO --> HR[Human resources]
  CEO --> LEG[IT / legal / security]
          

Stades de maturité EDW

Catalogue stage regroupe les tables, des fondations jusqu'au corporate.

Répartition d'exemple affichée : Ceci est une coupe représentative de l'inventaire complet de 60 tables réparti sur les couches de maturité ; la distribution réelle reflète le lignage de données complet, des fondations jusqu'aux tables gold corporate.

flowchart LR
  F["network
~8 tables"]
  P["passenger
~10 tables"]
  C["cargo
~8 tables"]
  O["operations
~6 tables"]
  CO["corporate
~28 tables"]
  F --> P --> C --> O
  F -.-> CO
  C -.-> CO
          

Entités métier cœur

Relations logiques et clés d’ancrage. Vol (flight_id) et PNR (pnr_locator) forment l’épine passager ; AWB (awb_number) relie le cargo via booking et FPS.

Diagramme d'exemple : Ce diagramme de relations d'entités montre le modèle logique cœur ; l'EDW généré complet contient 60 tables bronze sur 40 systèmes fournisseurs avec des tables de détail supplémentaires et des branches de lignage. Les instances d'entités portent entity_refs sur chaque événement émis pour tester la joignabilité.

erDiagram
  AIRCRAFT ||--o{ FLIGHT : operates
  ROUTE ||--o{ FLIGHT : schedules
  FLIGHT ||--o{ PNR : carries
  PNR ||--o{ TICKET : issues
  TICKET ||--o{ CHECKIN : boards
  FLIGHT ||--o{ AWB : uplifts
  AWB ||--o{ FPS_PAYMENT : collects
  PNR ||--o{ LOYALTY_ACCRUAL : earns
          

Paysage des systèmes source

40 préfixes fournisseur, 60 tables bronze.

Systèmes d'exemple affichés : Le diagramme ci-dessous illustre des systèmes fournisseurs représentatifs ; le jeu de données généré complet inclut les 40 systèmes avec leur lignage de tables et leurs points d’intégration sur le backfill d’historique et les flux live. Les manifestes de systèmes source partagés dans kb/source_systems/ sont réutilisés entre secteurs — Cathea ajoute cathea_network, cathea_ndc, cathea_cht, et cathea_loyalty comme systèmes internes spécifiques au secteur, plus le PSS Altéa et Cargospot.

Chaque table suit la {source_system_}__{entity} convention de nommage (p. ex. cathea_network__flight, amadeus_altea__pnr), en préservant la forme de colonnes native du fournisseur et les clés étrangères du schéma d'export réel de chaque produit. VibeBI infère la conformation des données de référence lorsqu'il promeut les enregistrements vers silver et gold.

flowchart TB
  subgraph foundation["Network"]
    direction TB
    f1["cathea_network aircraft · route · flight"]
    f2["oracle_scm · salesforce · workday · sap_s4 dimensions"]
  end
  subgraph passenger["Passenger"]
    direction TB
    p1["cathea_ndc · amadeus_altea · amadeus_dcs"]
    p2["adyen · cathea_loyalty"]
  end
  subgraph cargo["Cargo"]
    direction TB
    c1["champ_cargospot · cathea_cht · oracle_otm · fps"]
  end
  subgraph operations["Operations"]
    direction TB
    o1["navblue · aims_crew · sita_typeb · trax_mro · cathea_fuel"]
  end
  subgraph corporate["Corporate"]
    direction TB
    co1["accelya_ra · sap_s4 journals · anaplan · adp · ukg"]
    co2["hubspot · marketo · zendesk · servicenow · okta"]
    co3["splunk · ironclad · onetrust · greenhouse"]
  end
  foundation --> passenger --> cargo --> operations
  foundation --> corporate
  cargo --> corporate
          

Flux de données de bout en bout

Simulation OOP V2 → bronze dans ClickHouse ; sémantique VibeBI → silver → gold sur la même instance.

Chemin OOP : kb/industries/cathea/ définit l'épine dorsale opérationnelle et le modèle d'entités ; CatheaEnterpriseSimulation enchaîne les cycles de vie de domaine ; SourceSystem les adaptateurs exportent des lignes natives fournisseur dans cathea_v2.

flowchart LR
  subgraph kb["kb/industries/cathea"]
    SPINE[entity + process models]
  end
  subgraph sim["sim/industries/cathea"]
    ORCH[CatheaEnterpriseSimulation]
    DOM["Pnr · AirWaybill
execute_lifecycle()"]
  end
  subgraph simedw["SimEDW V2"]
    ADP[SourceSystem adapters]
    CHB[("ClickHouse cathea_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
          

Cycle bronze en direct

./live-v2-cathea — tick de 60 s via CatheaEnterpriseSimulation.generate().

Fréquence en direct : Chaque tick exécute OfferToFlyToRevenue et BookToDeliverCargo — les objets de domaine émettent des commandes NDC, PNR, billets, scans DCS, LTA cargo, mouvements SITA, encaissements FPS et lignes GL corrélés ; les ticks live d’aujourd’hui n’émettent que les événements jusqu’à Hong Kong as_of afin que check-in, scans bagages, cargo de nuit et journaux croissent dans la journée. L’échelle varie par tick (base 5 par défaut). Rechargez toute période d’historique dont vous avez besoin (--days N sur le script live ou le CLI).

flowchart LR
  START([60s tick]) --> SIM[CatheaEnterpriseSimulation.generate]
  SIM --> FOUND[Portfolio.publish_foundation]
  FOUND --> PNR[Pnr lifecycles]
  FOUND --> AWB[AirWaybill lifecycles]
  PNR --> CORP[Loyalty + RA + finance]
  AWB --> CORP
  CORP --> EVT[SourceSystem events]
  EVT --> BRZ[Append bronze rows]
  BRZ --> WAIT[Sleep] --> START
          

Graphes d’événements offer-to-fly et cargo

Machines d’état OfferToFlyToRevenue et BookToDeliverCargo — chaque transition est une méthode de domaine qui émet des lignes fournisseur.

Épine processuelle : Défini dans kb/industries/cathea/process_model.yaml. Les modes d’arrivée tardive (lag scan DCS, lag MVT, lag batch RA, délai de posting GL) et les modes d’exception (no-show, retard IRROPS, refus carte, short shipment, waitlist capacité) partent des mêmes cycles de vie d’entité plutôt que d’inserts aléatoires indépendants.

flowchart LR
  OFF[offered] --> PNR[pnr_created]
  PNR --> TKT[ticketed]
  TKT --> CKIN[checked_in]
  CKIN --> BRD[boarded]
  BRD --> FLN[flown]
  FLN --> ACC[accrued]
  ACC --> RA[rated]
  RA --> GL[posted_to_gl]
  TKT -.->|card_refuse| REF[card_refused]
  CKIN -.->|no_show| NS[no_show]
          

flowchart LR
  BK[booked] --> AWB[awb_issued]
  AWB --> ACC[accepted]
  ACC --> ULD[uld_built]
  ULD --> DEP[departed]
  DEP --> TRK[trucked]
  TRK --> DLV[delivered]
  DLV --> COL[collected]
  COL --> GL[posted_to_gl]
  BK -.->|waitlist| WL[capacity_waitlist]
  ACC -.->|short| SH[short_shipment]
          

Catégories de tables bronze

Même enveloppe de lignage sur chaque table ; la catégorie pilote le comportement live.

Catégories d'exemple : Les 60 tables bronze suivent ce schéma à trois catégories (snapshot, transaction, événement) avec des métadonnées et un suivi d'état cohérents ; le diagramme illustre le motif utilisé dans tout l'entrepôt.

flowchart LR
  subgraph snap["snapshot"]
    direction TB
    S1["Aircraft · route · station · loyalty masters"]
    S2[Daily foundation refresh]
  end
  subgraph txn["transaction"]
    direction TB
    T1["PNRs · tickets · AWBs · FPS · GL"]
    T2[Append each live tick]
  end
  subgraph evt["event"]
    direction TB
    E1["DCS scans · SITA MVT · bag events"]
    E2[Append each live tick]
  end
  BRONZE[("cathea_v2 bronze row")]
  snap --> BRONZE
  txn --> BRONZE
  evt --> BRONZE
          

Profil société

Avis société fictive : « P&C » est une société entièrement fictive, créée uniquement à des fins de démonstration. Elle n'est ni affiliée à The Procter & Gamble Company ni cautionnée par elle, et n'est pas destinée à représenter The Procter & Gamble Company ni aucun fabricant CPG réel.

P&C est un fabricant-marketeur mondial de biens de consommation courante — un modèle B2B2C vendant des produits d'usage quotidien via le mass retail, le club, l'épicerie et les canaux e-commerce dans ~180 pays. Cinq Sector Business Units (SBU) couvrent Fabric & Home Care, Baby/Feminine/Family Care, Beauty, Health Care et Grooming, avec ~12 marques phares (TidalWave, ComfortWrap, BrightSmile, EdgePro, et d'autres) et huit usines de fabrication plus trois centres de distribution régionaux.

L'activité couvre la planification de la demande, l'approvisionnement en matières premières, la production MES, la libération qualité, la distribution de produits finis, les commandes clients retail, le trade marketing et la finance — générant des ordres de travail MES corrélés, des PO Ariba, des en-têtes OMS, des expéditions OTM et des lignes de journal SAP à chaque jour de simulation, avec un Pic Spring Clean (mars–avril) qui stimule la demande fabric/home care, le débit usine et le sell-in retail en Amérique du Nord et en EMEA.

Entités d'exemple : Le tableau ci-dessous présente des entités métier représentatives et leurs systèmes source ; l'EDW complet inclut des entités supplémentaires, des sous-types et des tables spécialisées (p. ex. lectures de capteurs IoT, ordres de travail de maintenance, promotions trade, redlines CLM) sur l'ensemble des 60 tables bronze. En V2, ProductionBatch et CustomerOrder les classes de domaine animent l'épine MakeToShipToSell.

Modèle de domaine OOP

PcEnterpriseSimulation enchaîne la journée ; les objets de domaine possèdent la logique d'émission.

MakeToShipToSell est l'épine dorsale processuelle principale. ProductionBatch.execute_lifecycle() parcourt forecast → procurement → production → libération QC → produits finis ; CustomerOrder.execute_lifecycle() parcourt capture OMS → fulfillment WMS → expédition OTM. PcPortfolio.publish_foundation() maîtrise les SBU, marques, usines, SKU et comptes retail avant l'exécution des lots et des commandes. Les objets de service (PlantOperations, CommercialProgram, FinanceAndCorporate) émettent les lignes corporate et marketing de support.

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]
          

Chaîne de valeur make-to-ship

Du portefeuille de marques au plan, make, move, sell et clôture corporate.

Vue d'exemple : Ceci illustre la chaîne de valeur principale à travers l'écosystème P&C ; l'EDW généré complet inclut les 34 systèmes source avec intégrations transverses, télémétrie IoT d'usine et flux de trade marketing non représentés ici.

%%{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
          

Organisation fonctionnelle par département

Siège mondial Cincinnati et fonctions en report direct, avec des systèmes source représentatifs.

Structure d'org d'exemple : Ceci montre les lignes de reporting principales ; l'organisation P&C complète inclut des équipes SBU régionales, des responsables d'usine et des fonctions de services partagés sur les 34 intégrations fournisseurs.

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]
          

Stades de maturité EDW

Catalogue stage regroupe les tables, des fondations jusqu'au corporate.

Répartition d'exemple affichée : Ceci est une coupe représentative de l'inventaire complet de 60 tables réparti sur les couches de maturité ; la distribution réelle reflète le lignage de données complet, des fondations jusqu'aux tables gold corporate.

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
          

Entités métier cœur

Relations logiques et clés d'ancrage. Marque (brand_code) et usine (facility_code) forment l'épine dorsale ; les numéros matière relient le PIM au MES.

Diagramme d'exemple : Ce diagramme de relations d'entités montre le modèle logique cœur ; l'EDW généré complet contient 60 tables bronze sur 34 systèmes fournisseurs avec des tables de détail supplémentaires et des branches de lignage. Les instances d'entités portent entity_refs sur chaque événement émis pour tester la joignabilité.

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
          

Paysage des systèmes source

34 préfixes fournisseurs, 60 tables bronze.

Systèmes d'exemple affichés : Le diagramme ci-dessous illustre des systèmes fournisseurs représentatifs ; le jeu de données généré complet inclut les 34 systèmes avec leur lignage de tables complet et leurs points d'intégration sur le backfill historique et les flux live. Les manifestes de systèmes source partagés dans kb/source_systems/ sont réutilisés d'un secteur à l'autre — P&C ajoute pc_brand comme système interne spécifique au secteur.

Chaque table suit la {source_system_}__{entity} convention de nommage (p. ex. pc_brand__brand, siemens_mes__work_order), en préservant la forme de colonnes native du fournisseur et les clés étrangères du schéma d'export réel de chaque produit. VibeBI infère la conformation des données de référence lorsqu'il promeut les enregistrements vers silver et gold.

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
          

Flux de données de bout en bout

Simulation OOP V2 → bronze dans ClickHouse ; sémantique VibeBI → silver → gold sur la même instance.

Chemin OOP : kb/industries/pnc/ définit l'épine dorsale opérationnelle et le modèle d'entités ; PcEnterpriseSimulation enchaîne les cycles de vie de domaine ; SourceSystem les adaptateurs exportent des lignes natives fournisseur dans 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
          

Cycle bronze en direct

./live-v2-pnc — tick de 60 s via PcEnterpriseSimulation.generate().

Fréquence en direct : Chaque tick exécute la machine à états MakeToShipToSell — les objets de domaine émettent des lignes corrélées de forecast, PO, MES, WMS, OMS, OTM et GL par lot de production et commande client retail ; l'échelle varie par tick (base par défaut 5). Reconstituez n'importe quelle profondeur d'historique dont vous avez besoin (--days N sur le script live ou le 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
          

Graphe d'événements make-to-ship

Machine à états MakeToShipToSell — chaque transition est une méthode de domaine émettant des lignes fournisseur.

Épine processuelle : Défini dans kb/industries/pnc/process_model.yaml. Les modes d'exception (rebut de lot, blocage qualité, expédition partielle, retard fournisseur) se ramifient à partir des mêmes cycles de vie d'entités, plutôt que d'insertions aléatoires indépendantes.

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]
          

Catégories de tables bronze

Même enveloppe de lignage sur chaque table ; la catégorie pilote le comportement live.

Catégories d'exemple : Les 60 tables bronze suivent ce schéma à trois catégories (snapshot, transaction, événement) avec des métadonnées et un suivi d'état cohérents ; le diagramme illustre le motif utilisé dans tout l'entrepôt.

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