A escala empresarial almacenes de muestra.

Perfil de la empresa

Aviso de empresa ficticia: «AYA» es una empresa enteramente ficticia, creada únicamente con fines de demostración. No está afiliada, respaldada ni destinada a representar a AXA SA, AXA Hong Kong and Macau ni a ninguna aseguradora real.

AYA es una aseguradora compuesta de Hong Kong — Life & Savings, Health (incluido VHIS y beneficios para empleados) y General Insurance — distribuida por agentes vinculados, bancaseguros, brokers, la app Aria by AYA y socios de e-wallet embebidos. La sede está en Quarry Bay, con un centro de asesoría en Central, AYA Medical Centre en Tsim Sha Tsui, una sucursal en Macao y una oficina comercial GBA en Qianhai.

El negocio cubre fábrica de producto, suscripción clase Magnum, PAS dividido (vida en Ingenium, GI en Guidewire), cobro de primas FPS, comisión Varicent, FNOL auto/viaje 24×7, siniestros de salud FINEOS, cesión de reaseguro, valoración Prophet IFRS 17 y diarios SAP S/4 — con un alza de siniestros GI en temporada de tifones (junio–octubre) y un pico de viaje CNY / motor northbound en canales digitales y de agencia.

Entidades de muestra: La tabla inferior muestra entidades de negocio representativas y sus sistemas de origen; el EDW completo incluye entidades, subtipos y tablas especializadas adicionales (p. ej. Prophet BEL/CSM, cesiones de tratado, visitas de centro médico, redlines CLM) en las 60 tablas bronce. En V2, LifePolicy y GiPolicy las clases de dominio impulsan las columnas QuoteToBindToPremium y FnolToPay.

Modelo de dominio OOP

AyaEnterpriseSimulation secuencia el día; los objetos de dominio poseen la lógica de emisión.

QuoteToBindToPremium es la columna de nuevo negocio; FnolToPay es la columna de siniestros. LifePolicy.execute_lifecycle() recorre cotización → UW Magnum → emisión Ingenium → cobro FPS → comisión → GL. GiPolicy.execute_lifecycle() recorre cotización → bind PolicyCenter → factura BillingCenter → FNOL same-day opcional en ClaimCenter. AyaPortfolio.publish_foundation() masteriza productos, agentes, oficinas y tomadores antes de que corran las pólizas.

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]
          

Cadena de valor quote-to-claim

Desde la fábrica de producto, a través de distribución, bind, cobro, siniestros y cierre financiero.

Vista de muestra: Esto ilustra la cadena de valor primaria a través del ecosistema AYA; el EDW generado completo incluye los 39 sistemas de origen con integraciones interfuncionales, visitas cashless del centro médico y contabilidad de tratados no mostrados aquí.

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

Organización funcional por departamento

HQ AYA Tower Quarry Bay y funciones de reporte directo con sistemas de origen representativos.

Estructura organizativa de muestra: Esto muestra las líneas de reporting primarias; la organización AYA completa incluye distritos de agencia adicionales, equipos de Macao y GBA, y funciones de shared services en las 39 integraciones de proveedor.

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]
          

Etapas de madurez del EDW

Catálogo stage agrupa tablas desde la base hasta lo corporativo.

Desglose de muestra mostrado: Esta es una franja representativa del inventario completo de 60 tablas distribuido en capas de madurez; la distribución real refleja el linaje de datos completo desde la base hasta las tablas de oro corporativas.

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
          

Entidades centrales de negocio

Relaciones lógicas y claves de ancla. Producto (product_code) y póliza (policy_number) son la columna; los siniestros se unen vía FNOL y números de siniestro.

Diagrama de muestra: Este diagrama de relaciones de entidades muestra el modelo lógico central; el EDW generado completo contiene 60 tablas de bronce en 39 sistemas de proveedor con tablas de detalle adicionales y ramas de linaje. Las instancias de entidad llevan entity_refs en cada evento emitido para pruebas de joinability.

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
          

Paisaje de sistemas de origen

39 prefijos de proveedor, 60 tablas bronce.

Sistemas de muestra mostrados: El diagrama inferior ilustra sistemas de proveedor representativos; el conjunto de datos generado completo incluye los 39 sistemas con su linaje de tablas y puntos de integración en el relleno histórico y los streams en vivo. Los manifiestos de sistemas de origen compartidos en kb/source_systems/ se reutilizan entre industrias — AYA añade aya_product, aya_agency, aya_digital, y aya_health como sistemas internos específicos de la industria, más un PAS dividido (Guidewire + Ingenium).

Cada tabla sigue la {source_system_}__{entity} convención de nomenclatura (p. ej. aya_product__product, guidewire_cc__claim), conservando la forma de columnas nativa del proveedor y las claves foráneas del esquema de exportación real de cada producto. VibeBI infiere la conformidad de datos maestros al promover registros a plata y oro.

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
          

Flujo de datos de extremo a extremo

Simulación OOP V2 → bronce en ClickHouse; semántica VibeBI → plata → oro en la misma instancia.

Ruta OOP: kb/industries/aya/ define la columna vertebral de operaciones y el modelo de entidades; AyaEnterpriseSimulation secuencia los ciclos de vida de dominio; SourceSystem los adaptadores exportan filas nativas del proveedor hacia 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
          

Ciclo de bronce en vivo

./live-v2-aya — ciclo de 60s mediante AyaEnterpriseSimulation.generate().

Frecuencia en vivo: Cada tick ejecuta QuoteToBindToPremium y FnolToPay — los objetos de dominio emiten cotizaciones, decisiones UW, binds PAS, cobros FPS, comisiones, FNOL y líneas GL correlacionados; los ticks en vivo de hoy emiten solo eventos hasta Hong Kong as_of para que cotizaciones, FNOL, FPS y diarios crezcan a lo largo del día. La escala varía por tick (base 5 por defecto). Rellene cualquier tramo de historial que necesite (--days N en el script en vivo o la 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
          

Grafos de eventos quote-to-bind y FNOL

Máquinas de estados QuoteToBindToPremium y FnolToPay — cada transición es un método de dominio que emite filas de proveedor.

Columna vertebral del proceso: Definido en kb/industries/aya/process_model.yaml. Los modos de llegada tardía (lag de emisión PAS, clearing FPS, lote de comisiones, FNOL nocturno, bordereau de reaseguro) y los modos de excepción (UW refer/rechazo, caducidad de prima, siniestro denegado, liquidación parcial) se ramifican de los mismos ciclos de vida de entidad en lugar de inserciones aleatorias independientes.

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]
          

Categorías de tablas de bronce

El mismo sobre de linaje en cada tabla; la categoría impulsa el comportamiento en vivo.

Categorías de muestra: Las 60 tablas de bronce siguen este patrón de tres categorías (snapshot, transacción, evento) con metadatos y seguimiento de estado consistentes; el diagrama ilustra el patrón usado en todo el almacén.

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
          

Perfil de la empresa

Aviso de empresa ficticia: «Smire» es una empresa enteramente ficticia, creada únicamente con fines de demostración. No está afiliada a Swire Properties Limited, Swire Pacific Limited ni a ninguna inmobiliaria real, no está respaldada por ellas ni pretende representarlas.

Smire Properties es un landlord de uso mixto de Hong Kong con sede en Smire Tower, Quarry Bay — campus de oficinas Grade A (Eastgate Place, Harbour Place), malls (Harbourplaza, Peakgate Outlets, Eastgate Li), residencial y hoteles Harbour House, más retail estilo Taikoo Li en Mainland en Pekín, Shanghái, Cantón y Chengdu.

El libro cubre ofertas de leasing hacia leases Yardi y rent rolls diarios, renta base más turnover rent retail del POS de mall, cobro HK FPS / CNY, journals NOI de SAP S/4, BMS casi en tiempo real, eventos de badge Nedap, aparcamiento y afluencia de mall 11:00–22:00 HKT, más GAV/NAV Argus, comps estilo CoStar, draws de CAPEX de desarrollo y occupancy/ADR/RevPAR hotelero — con un oleada de trading mall CNY que eleva la afluencia de Harbourplaza y Eastgate Li, el turnover rent y los cobros FPS.

Entidades de muestra: La tabla siguiente muestra entidades de negocio representativas y sus sistemas de origen; el EDW completo incluye entidades, subtipos y tablas especializadas adicionales (p. ej. medidores ESG, draws de CAPEX, ocupación hotelera, redlines CLM) en las 60 tablas bronce. En V2, Lease y Tenant las clases de dominio impulsan las spines LeaseToCollect y MallTradingDay.

Modelo de dominio OOP

SmireEnterpriseSimulation secuencia el día; los objetos de dominio poseen la lógica de emisión.

LeaseToCollect es la spine de leasing; MallTradingDay es la spine de ops retail. Lease.execute_lifecycle() recorre oferta → lease y rent roll Yardi → factura (base más turnover rent) → cobro FPS → journal NOI. Tenant.publish() masteriza Yardi y Salesforce antes de que corran los leases. SmirePortfolio.publish_foundation() masteriza primero properties, buildings, unidades alquilables y sitios.

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
          

Cadena de valor lease-to-collect

Del master de portafolio al close de finanzas, vía leasing, trading de mall y ops de activos.

Vista de muestra: Esto ilustra la cadena de valor primaria a través del ecosistema Smire; el EDW generado completo incluye los 39 sistemas de origen con integraciones transversales, RevPAR hotelero y CAPEX de desarrollo no mostrados aquí.

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

Organización funcional por departamento

HQ Smire Tower Quarry Bay y funciones de reporte directo con sistemas de origen representativos.

Estructura organizativa de muestra: Esto muestra las líneas de reporting primarias; la organización Smire completa incluye oficinas adicionales de property management, equipos de mall en Mainland y funciones de shared services en las 39 integraciones de proveedor.

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]
          

Etapas de madurez del EDW

Catálogo stage agrupa tablas desde la base hasta lo corporativo.

Desglose de muestra mostrado: Esta es una franja representativa del inventario completo de 60 tablas distribuido en capas de madurez; la distribución real refleja el linaje de datos completo desde la base hasta las tablas de oro corporativas.

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
          

Entidades centrales de negocio

Relaciones lógicas y claves ancla. Propiedad (property_code) y unidad (unit_id) son la spine; los leases hacen join vía lease_id y FPS vía factura.

Diagrama de muestra: Este diagrama de relaciones de entidades muestra el modelo lógico central; el EDW generado completo contiene 60 tablas de bronce en 39 sistemas de proveedor con tablas de detalle adicionales y ramas de linaje. Las instancias de entidad llevan entity_refs en cada evento emitido para pruebas de joinability.

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
          

Paisaje de sistemas de origen

39 prefijos de proveedor, 60 tablas bronce.

Sistemas de muestra mostrados: El diagrama inferior ilustra sistemas de proveedor representativos; el conjunto de datos generado completo incluye los 39 sistemas con su linaje de tablas y puntos de integración en el relleno histórico y los streams en vivo. Los manifiestos de sistemas de origen compartidos en kb/source_systems/ se reutilizan entre industrias — Smire añade smire_portfolio, smire_leasing, smire_mall, y smire_hotel como sistemas internos específicos de la industria, más Yardi Voyager y Argus.

Cada tabla sigue la {source_system_}__{entity} convención de nomenclatura (p. ej. smire_portfolio__unit, yardi_voyager__lease), conservando la forma de columnas nativa del proveedor y las claves foráneas del esquema de exportación real de cada producto. VibeBI infiere la conformidad de datos maestros al promover registros a plata y oro.

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
          

Flujo de datos de extremo a extremo

Simulación OOP V2 → bronce en ClickHouse; semántica VibeBI → plata → oro en la misma instancia.

Ruta OOP: kb/industries/smire/ define la columna vertebral de operaciones y el modelo de entidades; SmireEnterpriseSimulation secuencia los ciclos de vida de dominio; SourceSystem los adaptadores exportan filas nativas del proveedor hacia 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
          

Ciclo de bronce en vivo

./live-v2-smire — ciclo de 60s mediante SmireEnterpriseSimulation.generate().

Frecuencia en vivo: Cada tick ejecuta LeaseToCollect y MallTradingDay — los objetos de dominio emiten ofertas, leases, facturas, cobros FPS, POS de mall, afluencia, eventos de badge y líneas GL correlacionados; los ticks en vivo de hoy emiten solo eventos hasta Hong Kong as_of para que rent rolls, trading de mall, BMS y journals crezcan a lo largo del día. La escala varía por tick (base 5 por defecto). Haga backfill de cualquier tramo de historial que necesite (--days N en el script en vivo o la 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
          

Grafos de eventos lease-to-collect y de activos

Máquinas de estado LeaseToCollect y OperateAsset — cada transición es un método de dominio que emite filas de proveedor.

Columna vertebral del proceso: Definido en kb/industries/smire/process_model.yaml. Los modos de llegada tardía (lag de clearing FPS, retraso de posting GL, BMS nocturno, lag de work-order) y los modos de excepción (vacancia, morosidad, acceso denegado, alarma de planta) se ramifican de los mismos ciclos de vida de entidad en lugar de inserts aleatorios independientes.

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]
          

Categorías de tablas de bronce

El mismo sobre de linaje en cada tabla; la categoría impulsa el comportamiento en vivo.

Categorías de muestra: Las 60 tablas de bronce siguen este patrón de tres categorías (snapshot, transacción, evento) con metadatos y seguimiento de estado consistentes; el diagrama ilustra el patrón usado en todo el almacén.

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
          

Perfil de la empresa

Aviso de empresa ficticia: «Hilson» es una empresa enteramente ficticia, creada únicamente con fines de demostración. No está afiliada a Hilton Inc., Hyatt Hotels Corporation ni a ninguna empresa hotelera real, ni está respaldada por ellas, ni pretende representarlas.

Hilson Hospitality Group es un operador hotelero global con ~680 propiedades en 18 marcas — desde banderas de lujo (nivel Waldorf, nivel Conrad) pasando por full-service (Hilson, nivel DoubleTree) hasta select-service y estancias prolongadas. Cada propiedad opera un PMS Opera on-premise y un CRS central Amadeus, atendiendo una mezcla de huéspedes de ocio transitorio, corporativos negociados y de grupos/convenciones.

El negocio abarca fidelización (Hilson Honors con millones de miembros), ventas de grupos y convenciones (pipeline de salesforce, bloques de habitaciones CPQ), puntos de alimentos y bebidas (POS MICROS Simphony), informes a propietarios/franquicias (estados de Oracle Fusion) y funciones corporativas — generando unas 1.900 reservas PMS y 1.750 encabezados de folio en un día hábil típico, con una oleada de viajes de verano (junio–agosto) que eleva la ocupación, el ADR, el gasto de F&B y la actividad de fidelización en todas las propiedades.

Entidades de muestra: La tabla siguiente muestra entidades de negocio representativas y sus sistemas de origen; el EDW completo incluye entidades adicionales, subtipos y tablas especializadas (p. ej., eventos de canal OTA, restricciones de planes tarifarios, acuerdos legales de franquicia, redlines de deal-desk) en las 62 tablas de bronce. En V2, StayReservation y las clases de dominio relacionadas emiten filas de PMS, CRS, folio y fidelización a través de adaptadores del sistema de origen a medida que avanza el ciclo de vida de la estancia.

Modelo de dominio OOP

HilsonEnterpriseSimulation secuencia el día; los objetos de dominio poseen la lógica de emisión.

ReservationToLoyaltyAndOwnerReporting es la columna vertebral primaria del proceso. StayReservation.execute_lifecycle() recorre reserva → sincronización PMS → cargos de folio → pago → puntos de fidelización → snapshot de ocupación → estado del propietario → GL. HilsonPortfolio.publish_foundation() consolida marcas, propiedades y miembros Honors antes de que corran las reservas.

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]
          

Cadena de valor de huésped y propiedad

Desde el maestro de marca y propiedad hasta distribución, estancia, liquidación e informes al propietario.

Vista de muestra: Esto ilustra la cadena de valor primaria a través del ecosistema Hilson; el EDW generado completo incluye los 31 sistemas de origen con integraciones interfuncionales, flujos de ingresos secundarios y flujos del ciclo de vida de fidelización no mostrados aquí.

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

Organización funcional por departamento

Sede empresarial y funciones de reporte directo con sistemas de origen representativos.

Estructura organizativa de muestra: Esto muestra las líneas de reporte primarias; la organización completa de Hilson incluye dirección regional adicional, equipos específicos de marca y funciones de servicios compartidos en las 31 integraciones de proveedor.

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]
          

Etapas de madurez del EDW

Catálogo stage agrupa tablas desde la base hasta lo corporativo.

Desglose de muestra mostrado: Esta es una franja representativa del inventario completo de 62 tablas distribuido en capas de madurez; la distribución real refleja el linaje de datos completo desde la base hasta las tablas de oro corporativas.

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
          

Entidades centrales de negocio

Relaciones lógicas y claves ancla. Propiedad (hotel_code) es la columna vertebral; identidad del huésped mediante Honors y tablas de estancia.

Diagrama de muestra: Este diagrama de relaciones de entidades muestra el modelo lógico central; el EDW generado completo contiene 62 tablas de bronce en 31 sistemas de proveedor con miles de tablas de detalle adicionales y ramas de linaje.

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
          

Paisaje de sistemas de origen

31 prefijos de proveedor, 62 tablas de bronce.

Sistemas de muestra mostrados: El diagrama siguiente ilustra sistemas de proveedor representativos; el conjunto de datos generado completo incluye los 31 sistemas con su linaje de tablas completo y puntos de integración a lo largo del relleno histórico y los flujos en vivo.

Cada tabla sigue la {source_system_}__{entity} convención de nomenclatura (p. ej. oracle_opera__reservation, hilson_loyalty__member), conservando la forma de columnas nativa del proveedor y las claves foráneas del esquema de exportación real de cada producto. VibeBI infiere la conformidad de datos maestros al promover registros a plata y oro.

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
          

Flujo de datos de extremo a extremo

Simulación OOP V2 → bronce en ClickHouse; semántica VibeBI → plata → oro en la misma instancia.

Ruta OOP: kb/industries/hilson/ define la columna vertebral de operaciones y el modelo de entidades; HilsonEnterpriseSimulation secuencia los ciclos de vida de dominio; SourceSystem los adaptadores exportan filas nativas del proveedor hacia 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
          

Ciclo de bronce en vivo

./live-v2-hilson — ciclo de 60s mediante HilsonEnterpriseSimulation.generate().

Frecuencia en vivo: Cada ciclo ejecuta la máquina de estados de reserva a fidelización — los objetos de dominio emiten filas correlacionadas de CRS, PMS, folio, F&B, pagos, fidelización y GL; la escala varía por ciclo (base predeterminada 5). Rellene el tramo de historia que necesite (--days N); Hilson incluye detección de huecos en la tabla ancla de reservas.

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
          

Grafo de eventos de estancia del huésped

Máquina de estados ReservationToLoyaltyAndOwnerReporting — cada transición emite filas de proveedor.

Columna vertebral del proceso: Definido en kb/industries/hilson/process_model.yaml. Los modos de excepción (no-shows, chargebacks, upgrades de habitación) se ramifican desde el mismo ciclo de vida de entidad, no desde inserciones aleatorias independientes.

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]
          

Categorías de tablas de bronce

El mismo sobre de linaje en cada tabla; la categoría controla la actualización en vivo frente al append en micro-lotes.

Categorías de muestra: Las 62 tablas de bronce siguen este patrón de tres categorías (snapshot, transacción, evento) con metadatos y seguimiento de estado consistentes; el diagrama ilustra el patrón usado en todo el almacén.

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
          

Perfil de la empresa

Aviso de empresa ficticia: «Cathea» es una empresa enteramente ficticia, creada únicamente con fines de demostración. No está afiliada a Cathay Pacific Airways Limited, Cathay Pacific Group ni a ninguna aerolínea real, no está respaldada por ellas ni pretende representarlas.

Cathea Pacific es una aerolínea hub de Hong Kong con sede en Cathea City, Chek Lap Kok — pasajeros premium (HP), carga aérea y Cathea Cargo Terminal, LCC Peak Express (PX) y fletes Air Harbour Express (AH), más el lifestyle Pacific Miles. La red está temporizada en HKG: rotaciones de largo radio A350/777, oleadas nocturnas 747-8F y saltos regionales A321neo.

El día corre pedido NDC → PNR clase Altéa y e-ticket de prefijo 168 → captura de tarjeta Adyen → check-in DCS y scans de equipaje → OFP Navblue, duty de crew AIMS y MVT SITA (incluido cargo nocturno 01:00–05:00 HKT) → accrual Pacific Miles y rating Accelya → journals SAP S/4. La carga recorre reserva Cargospot → AWB → aceptación de terminal → scan ULD → movimiento → trucking OTM → cobro FPS — con un alza de viaje CNY / IRROPS tifón que dispara el load factor de Peak Express, los scans de equipaje y las waitlists de carga.

Entidades de muestra: La tabla siguiente muestra entidades de negocio representativas y sus sistemas de origen; el EDW completo incluye entidades, subtipos y tablas especializadas adicionales (p. ej. fuel uplifts, work orders TRAX, scans ULD, accruals de loyalty) en las 60 tablas bronce. En V2, Pnr y AirWaybill las clases de dominio impulsan las spines OfferToFlyToRevenue y BookToDeliverCargo.

Modelo de dominio OOP

CatheaEnterpriseSimulation secuencia el día; los objetos de dominio poseen la lógica de emisión.

OfferToFlyToRevenue es la spine de pasajeros; BookToDeliverCargo es la spine de carga. Pnr.execute_lifecycle() recorre pedido NDC → PNR y e-ticket Altéa → captura Adyen → check-in DCS → cupón volado → Pacific Miles → Accelya → GL. AirWaybill.execute_lifecycle() recorre reserva Cargospot → AWB → aceptación CHT → ULD → movimiento SITA → trucking OTM → cobro FPS. CatheaPortfolio.publish_foundation() masteriza aeronaves, rutas, estaciones y vuelos temporizados en HKG antes de que corran PNR y AWB.

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]
          

Cadena de valor offer-to-fly y cargo

Del master de red al close de finanzas, vía pasajeros, carga y ops.

Vista de muestra: Esto ilustra la cadena de valor primaria a través del ecosistema Cathea; el EDW generado completo incluye los 40 sistemas de origen con integraciones transversales, oleadas de carga nocturna y MRO TRAX no mostrados aquí.

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

Organización funcional por departamento

HQ Cathea City Chek Lap Kok y funciones de reporte directo con sistemas de origen representativos.

Estructura organizativa de muestra: Esto muestra las líneas de reporting primarias; la organización Cathea completa incluye outstations adicionales, desks de carga GBA y funciones de shared services en las 40 integraciones de proveedor.

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]
          

Etapas de madurez del EDW

Catálogo stage agrupa tablas desde la base hasta lo corporativo.

Desglose de muestra mostrado: Esta es una franja representativa del inventario completo de 60 tablas distribuido en capas de madurez; la distribución real refleja el linaje de datos completo desde la base hasta las tablas de oro corporativas.

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
          

Entidades centrales de negocio

Relaciones lógicas y claves de anclaje. Vuelo (flight_id) y PNR (pnr_locator) son la spine de pasajeros; AWB (awb_number) une el cargo vía booking y FPS.

Diagrama de muestra: Este diagrama de relaciones de entidades muestra el modelo lógico central; el EDW generado completo contiene 60 tablas de bronce en 40 sistemas de proveedor con tablas de detalle adicionales y ramas de linaje. Las instancias de entidad llevan entity_refs en cada evento emitido para pruebas de joinability.

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
          

Paisaje de sistemas de origen

40 prefijos de proveedor, 60 tablas bronce.

Sistemas de muestra mostrados: El diagrama siguiente ilustra sistemas de proveedor representativos; el conjunto generado completo incluye los 40 sistemas con su linaje de tablas y puntos de integración en el backfill de historial y los streams en vivo. Los manifiestos de sistemas de origen compartidos en kb/source_systems/ se reutilizan entre industrias — Cathea añade cathea_network, cathea_ndc, cathea_cht, y cathea_loyalty como sistemas internos específicos de la industria, más el PSS Altéa y Cargospot.

Cada tabla sigue la {source_system_}__{entity} convención de nomenclatura (p. ej. cathea_network__flight, amadeus_altea__pnr), conservando la forma de columnas nativa del proveedor y las claves foráneas del esquema de exportación real de cada producto. VibeBI infiere la conformidad de datos maestros al promover registros a plata y oro.

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
          

Flujo de datos de extremo a extremo

Simulación OOP V2 → bronce en ClickHouse; semántica VibeBI → plata → oro en la misma instancia.

Ruta OOP: kb/industries/cathea/ define la columna vertebral de operaciones y el modelo de entidades; CatheaEnterpriseSimulation secuencia los ciclos de vida de dominio; SourceSystem los adaptadores exportan filas nativas del proveedor hacia 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
          

Ciclo de bronce en vivo

./live-v2-cathea — ciclo de 60s mediante CatheaEnterpriseSimulation.generate().

Frecuencia en vivo: Cada tick ejecuta OfferToFlyToRevenue y BookToDeliverCargo — los objetos de dominio emiten pedidos NDC, PNR, boletos, scans DCS, AWB de carga, movimientos SITA, cobros FPS y líneas GL correlacionados; los ticks en vivo de hoy emiten solo eventos hasta Hong Kong as_of para que check-ins, scans de equipaje, carga nocturna y journals crezcan a lo largo del día. La escala varía por tick (base 5 por defecto). Haga backfill de cualquier tramo de historial que necesite (--days N en el script en vivo o la 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
          

Grafos de eventos offer-to-fly y cargo

Máquinas de estado OfferToFlyToRevenue y BookToDeliverCargo — cada transición es un método de dominio que emite filas de proveedor.

Columna vertebral del proceso: Definido en kb/industries/cathea/process_model.yaml. Los modos de llegada tardía (lag de scan DCS, lag MVT, lag de batch RA, retraso de posting GL) y los modos de excepción (no-show, retraso IRROPS, rechazo de tarjeta, short shipment, waitlist de capacidad) se ramifican de los mismos ciclos de vida de entidad en lugar de inserts aleatorios independientes.

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]
          

Categorías de tablas de bronce

El mismo sobre de linaje en cada tabla; la categoría impulsa el comportamiento en vivo.

Categorías de muestra: Las 60 tablas de bronce siguen este patrón de tres categorías (snapshot, transacción, evento) con metadatos y seguimiento de estado consistentes; el diagrama ilustra el patrón usado en todo el almacén.

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
          

Perfil de la empresa

Aviso de empresa ficticia: «P&C» es una empresa enteramente ficticia, creada únicamente con fines de demostración. No está afiliada a The Procter & Gamble Company ni a ningún fabricante de CPG real, ni está respaldada por ellos, ni pretende representarlos.

P&C es un fabricante-comercializador global de bienes de consumo empaquetados — un modelo B2B2C que vende productos de uso diario a través de canales de gran distribución, club, supermercado y comercio electrónico en ~180 países. Cinco unidades de negocio sectoriales (SBU) cubren Cuidado de telas y del hogar, Cuidado infantil/femenino/familiar, Belleza, Salud y Aseo personal, con ~12 marcas insignia (TidalWave, ComfortWrap, BrightSmile, EdgePro y otras) y ocho plantas de fabricación más tres centros de distribución regionales.

El negocio abarca planificación de demanda, compras de materia prima, producción MES, liberación de calidad, distribución de productos terminados, pedidos de clientes minoristas, trade marketing y finanzas — generando órdenes de trabajo MES correlacionadas, PO de Ariba, encabezados OMS, envíos OTM y líneas de diario SAP en cada día de simulación, con una Oleada de Spring Clean (marzo–abril) que eleva la demanda de cuidado de telas y del hogar, el rendimiento de planta y el sell-in minorista en Norteamérica y EMEA.

Entidades de muestra: La tabla siguiente muestra entidades de negocio representativas y sus sistemas de origen; el EDW completo incluye entidades adicionales, subtipos y tablas especializadas (p. ej., lecturas de sensores IoT, órdenes de trabajo de mantenimiento, promociones comerciales, redlines de CLM) en las 60 tablas de bronce. En V2, ProductionBatch y CustomerOrder las clases de dominio impulsan la columna MakeToShipToSell.

Modelo de dominio OOP

PcEnterpriseSimulation secuencia el día; los objetos de dominio poseen la lógica de emisión.

MakeToShipToSell es la columna vertebral primaria del proceso. ProductionBatch.execute_lifecycle() recorre pronóstico → comprar → producir → liberación QC → productos terminados; CustomerOrder.execute_lifecycle() recorre captura OMS → cumplimiento WMS → envío OTM. PcPortfolio.publish_foundation() consolida SBU, marcas, plantas, SKU y cuentas minoristas antes de que corran los lotes y los pedidos. Los objetos de servicio (PlantOperations, CommercialProgram, FinanceAndCorporate) emiten filas corporativas y de marketing de apoyo.

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]
          

Cadena de valor de fabricación a envío

Desde el portafolio de marcas hasta planificar, fabricar, mover, vender y el cierre corporativo.

Vista de muestra: Esto ilustra la cadena de valor primaria a través del ecosistema P&C; el EDW generado completo incluye los 34 sistemas de origen con integraciones interfuncionales, telemetría IoT de planta y flujos de trade marketing no mostrados aquí.

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

Organización funcional por departamento

Sede global en Cincinnati y funciones de reporte directo con sistemas de origen representativos.

Estructura organizativa de muestra: Esto muestra las líneas de reporte primarias; la organización completa de P&C incluye equipos regionales de SBU, gerentes de planta y funciones de servicios compartidos en las 34 integraciones de proveedor.

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]
          

Etapas de madurez del EDW

Catálogo stage agrupa tablas desde la base hasta lo corporativo.

Desglose de muestra mostrado: Esta es una franja representativa del inventario completo de 60 tablas distribuido en capas de madurez; la distribución real refleja el linaje de datos completo desde la base hasta las tablas de oro corporativas.

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
          

Entidades centrales de negocio

Relaciones lógicas y claves ancla. Marca (brand_code) y planta (facility_code) son la columna vertebral; los números de material vinculan PIM con MES.

Diagrama de muestra: Este diagrama de relaciones de entidades muestra el modelo lógico central; el EDW generado completo contiene 60 tablas de bronce en 34 sistemas de proveedor con tablas de detalle adicionales y ramas de linaje. Las instancias de entidad llevan entity_refs en cada evento emitido para pruebas de joinability.

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
          

Paisaje de sistemas de origen

34 prefijos de proveedor, 60 tablas de bronce.

Sistemas de muestra mostrados: El diagrama siguiente ilustra sistemas de proveedor representativos; el conjunto de datos generado completo incluye los 34 sistemas con su linaje de tablas completo y puntos de integración a lo largo del relleno histórico y los flujos en vivo. Los manifiestos compartidos de sistemas de origen en kb/source_systems/ se reutilizan entre industrias — P&C añade pc_brand como un sistema interno específico de la industria.

Cada tabla sigue la {source_system_}__{entity} convención de nomenclatura (p. ej. pc_brand__brand, siemens_mes__work_order), conservando la forma de columnas nativa del proveedor y las claves foráneas del esquema de exportación real de cada producto. VibeBI infiere la conformidad de datos maestros al promover registros a plata y oro.

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
          

Flujo de datos de extremo a extremo

Simulación OOP V2 → bronce en ClickHouse; semántica VibeBI → plata → oro en la misma instancia.

Ruta OOP: kb/industries/pnc/ define la columna vertebral de operaciones y el modelo de entidades; PcEnterpriseSimulation secuencia los ciclos de vida de dominio; SourceSystem los adaptadores exportan filas nativas del proveedor hacia 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
          

Ciclo de bronce en vivo

./live-v2-pnc — ciclo de 60s mediante PcEnterpriseSimulation.generate().

Frecuencia en vivo: Cada ciclo ejecuta la máquina de estados MakeToShipToSell — los objetos de dominio emiten filas correlacionadas de pronóstico, PO, MES, WMS, OMS, OTM y GL por lote de producción y pedido de cliente minorista; la escala varía por ciclo (base predeterminada 5). Rellene el tramo de historia que necesite (--days N en el script en vivo o la 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
          

Grafo de eventos de fabricación a envío

Máquina de estados MakeToShipToSell — cada transición es un método de dominio que emite filas de proveedor.

Columna vertebral del proceso: Definido en kb/industries/pnc/process_model.yaml. Los modos de excepción (scrap de lote, retención de calidad, envío parcial, retraso de proveedor) se ramifican desde los mismos ciclos de vida de entidad, no desde inserciones aleatorias independientes.

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]
          

Categorías de tablas de bronce

El mismo sobre de linaje en cada tabla; la categoría impulsa el comportamiento en vivo.

Categorías de muestra: Las 60 tablas de bronce siguen este patrón de tres categorías (snapshot, transacción, evento) con metadatos y seguimiento de estado consistentes; el diagrama ilustra el patrón usado en todo el almacén.

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