À escala empresarial armazéns de amostra.

Perfil da empresa

Aviso de empresa fictícia: «AYA» é uma empresa inteiramente fictícia, criada apenas para fins de demonstração. Não está afiliada, endossada nem destinada a representar a AXA SA, a AXA Hong Kong and Macau ou qualquer seguradora real.

AYA é uma seguradora composta de Hong Kong — Life & Savings, Health (incluindo VHIS e benefícios de colaboradores) e General Insurance — distribuída por agentes vinculados, bancassurance, brokers, a app Aria by AYA e parceiros de e-wallet embedded. A HQ fica em Quarry Bay, com um centro de aconselhamento em Central, AYA Medical Centre em Tsim Sha Tsui, uma sucursal em Macau e um escritório comercial GBA em Qianhai.

O negócio cobre fábrica de produto, underwriting classe Magnum, PAS dividido (vida em Ingenium, GI em Guidewire), cobrança de prémios FPS, comissão Varicent, FNOL auto/viagem 24×7, sinistros de saúde FINEOS, cessão de resseguro, avaliação Prophet IFRS 17 e diários SAP S/4 — com um subida de sinistros GI na época de tufões (junho–outubro) e um pico de viagem CNY / motor northbound nos canais digitais e de agência.

Entidades de amostra: A tabela abaixo mostra entidades de negócio representativas e os respetivos sistemas de origem; o EDW completo inclui entidades, subtipos e tabelas especializadas adicionais (p. ex. Prophet BEL/CSM, cessões de tratado, visitas de centro médico, redlines CLM) em todas as 60 tabelas bronze. Em V2, LifePolicy e GiPolicy as classes de domínio impulsionam as espinhas QuoteToBindToPremium e FnolToPay.

Modelo de domínio OOP

AyaEnterpriseSimulation sequencia o dia; os objetos de domínio são donos da lógica de emissão.

QuoteToBindToPremium é a espinha de new business; FnolToPay é a espinha de sinistros. LifePolicy.execute_lifecycle() percorre cotação → UW Magnum → emissão Ingenium → cobrança FPS → comissão → GL. GiPolicy.execute_lifecycle() percorre cotação → bind PolicyCenter → fatura BillingCenter → FNOL same-day opcional no ClaimCenter. AyaPortfolio.publish_foundation() masteriza produtos, agentes, escritórios e tomadores antes de as apólices correrem.

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]
          

Cadeia de valor quote-to-claim

Da fábrica de produto, através de distribuição, bind, cobrança, sinistros e fecho financeiro.

Vista de amostra: Isto ilustra a cadeia de valor primária através do ecossistema AYA; o EDW gerado completo inclui os 39 sistemas de origem, com integrações transversais, visitas cashless do centro médico e contabilidade de tratados não mostrados aqui.

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

Organização funcional por departamento

HQ AYA Tower Quarry Bay e funções de reporte direto com sistemas de origem representativos.

Estrutura organizacional de amostra: Isto mostra as linhas de reporte primárias; a organização AYA completa inclui distritos de agência adicionais, equipas de Macau e GBA, e funções de shared services em todas as 39 integrações de fornecedor.

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]
          

Estádios de maturidade do EDW

Catálogo stage agrupa tabelas desde a fundação até ao corporativo.

Desagregação de amostra apresentada: Isto é um recorte representativo do inventário completo de 60 tabelas, distribuído pelas camadas de maturidade; a distribuição real reflete a linhagem completa de dados desde a fundação até às tabelas gold 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 nucleares do negócio

Relações lógicas e chaves âncora. Produto (product_code) e apólice (policy_number) são a espinha; os sinistros ligam via FNOL e números de sinistro.

Diagrama de amostra: Este diagrama de relação de entidades mostra o modelo lógico nuclear; o EDW gerado completo contém 60 tabelas bronze em 39 sistemas de fornecedor com tabelas de detalhe adicionais e ramos de linhagem. As instâncias de entidade transportam entity_refs em cada evento emitido, para testes 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
          

Paisagem de sistemas de origem

39 prefixos de fornecedor, 60 tabelas bronze.

Sistemas de amostra apresentados: O diagrama abaixo ilustra sistemas de fornecedor representativos; o conjunto de dados gerado completo inclui os 39 sistemas com linhagem de tabelas e pontos de integração no backfill de histórico e nos streams em tempo real. Os manifests de sistemas de origem partilhados em kb/source_systems/ são reutilizados entre indústrias — a AYA acrescenta aya_product, aya_agency, aya_digital, e aya_health como sistemas internos específicos da indústria, mais um PAS dividido (Guidewire + Ingenium).

Cada tabela segue a {source_system_}__{entity} convenção de nomenclatura (p.ex. aya_product__product, guidewire_cc__claim), preservando a forma nativa das colunas do fornecedor e as chaves estrangeiras do esquema de exportação real de cada produto. O VibeBI infere a conformidade dos dados mestres quando promove os registos para silver e 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
          

Fluxo de dados de ponta a ponta

Sim OOP V2 → bronze em ClickHouse; semântica VibeBI → silver → gold na mesma instância.

Percurso OOP: kb/industries/aya/ define a espinha dorsal das operações e o modelo de entidades; AyaEnterpriseSimulation sequencia os ciclos de vida de domínio; SourceSystem os adapters exportam linhas nativas do fornecedor para 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 bronze em tempo real

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

Frequência em tempo real: Cada tick executa QuoteToBindToPremium e FnolToPay — os objetos de domínio emitem cotações, decisões UW, binds PAS, cobranças FPS, comissões, FNOL e linhas GL correlacionados; os ticks live de hoje emitem apenas eventos até Hong Kong as_of para que cotações, FNOL, FPS e diários cresçam ao longo do dia. A escala varia por tick (base 5 por omissão). Faça backfill de qualquer intervalo de histórico de que precise (--days N no script live ou na 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 e FNOL

State machines QuoteToBindToPremium e FnolToPay — cada transição é um método de domínio que emite linhas de fornecedor.

Espinha dorsal do processo: Definido em kb/industries/aya/process_model.yaml. Os modos de chegada tardia (lag de emissão PAS, clearing FPS, lote de comissões, FNOL noturno, bordereau de resseguro) e os modos de exceção (UW refer/recusa, lapse de prémio, sinistro recusado, liquidação parcial) ramificam dos mesmos ciclos de vida da entidade em vez de inserções aleatórias independentes.

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]
          

Categorias de tabelas bronze

O mesmo envelope de linhagem em cada tabela; a categoria determina o comportamento live.

Categorias de amostra: Todas as 60 tabelas bronze seguem este padrão de três categorias (snapshot, transação, evento), com metadados consistentes e acompanhamento de estado; o diagrama ilustra o padrão usado em todo o armazém.

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 da empresa

Aviso de empresa fictícia: «Smire» é uma empresa inteiramente fictícia, criada apenas para fins de demonstração. Não é afiliada da Swire Properties Limited, da Swire Pacific Limited nem de qualquer imobiliária real, não é por elas endossada e não se destina a representá-las.

Smire Properties é um landlord de uso misto de Hong Kong com sede na Smire Tower, Quarry Bay — campi de escritórios Grade A (Eastgate Place, Harbour Place), malls (Harbourplaza, Peakgate Outlets, Eastgate Li), residencial e hotéis Harbour House, mais retalho estilo Taikoo Li no Interior em Pequim, Xangai, Cantão e Chengdu.

O livro cobre ofertas de leasing para leases Yardi e rent rolls diários, renda base mais renda de volume retalhista do POS de mall, cobrança HK FPS / CNY, journals NOI SAP S/4, BMS quase em tempo real, eventos de badge Nedap, parque e footfall de mall 11:00–22:00 HKT, mais GAV/NAV Argus, comps estilo CoStar, draws de CAPEX de development e occupancy/ADR/RevPAR hoteleiro — com um surto de trading mall CNY que eleva o footfall de Harbourplaza e Eastgate Li, a renda de volume e as cobranças FPS.

Entidades de amostra: A tabela abaixo mostra entidades de negócio representativas e os respetivos sistemas de origem; o EDW completo inclui entidades, subtipos e tabelas especializadas adicionais (p. ex. medidores ESG, draws de CAPEX, ocupação hoteleira, redlines CLM) em todas as 60 tabelas bronze. Em V2, Lease e Tenant as classes de domínio impulsionam as spines LeaseToCollect e MallTradingDay.

Modelo de domínio OOP

SmireEnterpriseSimulation sequencia o dia; os objetos de domínio são donos da lógica de emissão.

LeaseToCollect é a spine de leasing; MallTradingDay é a spine de ops retail. Lease.execute_lifecycle() percorre oferta → lease e rent roll Yardi → fatura (base mais renda de volume) → cobrança FPS → journal NOI. Tenant.publish() masteriza Yardi e Salesforce antes de os leases correrem. SmirePortfolio.publish_foundation() masteriza primeiro properties, buildings, unidades locáveis e 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
          

Cadeia de valor lease-to-collect

Do master de portefólio ao close financeiro, via leasing, trading de mall e ops de ativos.

Vista de amostra: Isto ilustra a cadeia de valor primária através do ecossistema Smire; o EDW gerado completo inclui os 39 sistemas de origem com integrações transversais, RevPAR hoteleiro e CAPEX de development não mostrados aqui.

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

Organização funcional por departamento

HQ Smire Tower Quarry Bay e funções de reporte direto com sistemas de origem representativos.

Estrutura organizacional de amostra: Isto mostra as linhas de reporting primárias; a organização Smire completa inclui escritórios adicionais de property management, equipas de mall no Interior e funções de shared services nas 39 integrações de fornecedor.

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]
          

Estádios de maturidade do EDW

Catálogo stage agrupa tabelas desde a fundação até ao corporativo.

Desagregação de amostra apresentada: Isto é um recorte representativo do inventário completo de 60 tabelas, distribuído pelas camadas de maturidade; a distribuição real reflete a linhagem completa de dados desde a fundação até às tabelas gold 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 nucleares do negócio

Relações lógicas e chaves âncora. Unidade (property_code) e unidade (unit_id) são a spine; os leases fazem join via lease_id e FPS via fatura.

Diagrama de amostra: Este diagrama de relação de entidades mostra o modelo lógico nuclear; o EDW gerado completo contém 60 tabelas bronze em 39 sistemas de fornecedor com tabelas de detalhe adicionais e ramos de linhagem. As instâncias de entidade transportam entity_refs em cada evento emitido, para testes 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
          

Paisagem de sistemas de origem

39 prefixos de fornecedor, 60 tabelas bronze.

Sistemas de amostra apresentados: O diagrama abaixo ilustra sistemas de fornecedor representativos; o conjunto de dados gerado completo inclui os 39 sistemas com linhagem de tabelas e pontos de integração no backfill de histórico e nos streams em tempo real. Os manifests de sistemas de origem partilhados em kb/source_systems/ são reutilizados entre indústrias — a Smire acrescenta smire_portfolio, smire_leasing, smire_mall, e smire_hotel como sistemas internos específicos da indústria, mais Yardi Voyager e Argus.

Cada tabela segue a {source_system_}__{entity} convenção de nomenclatura (p.ex. smire_portfolio__unit, yardi_voyager__lease), preservando a forma nativa das colunas do fornecedor e as chaves estrangeiras do esquema de exportação real de cada produto. O VibeBI infere a conformidade dos dados mestres quando promove os registos para silver e 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
          

Fluxo de dados de ponta a ponta

Sim OOP V2 → bronze em ClickHouse; semântica VibeBI → silver → gold na mesma instância.

Percurso OOP: kb/industries/smire/ define a espinha dorsal das operações e o modelo de entidades; SmireEnterpriseSimulation sequencia os ciclos de vida de domínio; SourceSystem os adapters exportam linhas nativas do fornecedor para 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 bronze em tempo real

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

Frequência em tempo real: Cada tick executa LeaseToCollect e MallTradingDay — os objetos de domínio emitem ofertas, leases, faturas, cobranças FPS, POS de mall, footfall, eventos de badge e linhas GL correlacionados; os ticks live de hoje emitem apenas eventos até Hong Kong as_of para que rent rolls, trading de mall, BMS e journals cresçam ao longo do dia. A escala varia por tick (base 5 por omissão). Faça backfill de qualquer intervalo de histórico de que precise (--days N no script live ou na 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 e de ativos

Máquinas de estado LeaseToCollect e OperateAsset — cada transição é um método de domínio que emite linhas de fornecedor.

Espinha dorsal do processo: Definido em kb/industries/smire/process_model.yaml. Os modos de late-arrival (lag de clearing FPS, atraso de posting GL, BMS noturno, lag de work-order) e os modos de exceção (vacância, mora, acesso negado, alarme de planta) ramificam-se dos mesmos ciclos de vida da entidade em vez de inserts aleatórios independentes.

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]
          

Categorias de tabelas bronze

O mesmo envelope de linhagem em cada tabela; a categoria determina o comportamento live.

Categorias de amostra: Todas as 60 tabelas bronze seguem este padrão de três categorias (snapshot, transação, evento), com metadados consistentes e acompanhamento de estado; o diagrama ilustra o padrão usado em todo o armazém.

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 da empresa

Aviso de empresa fictícia: «Hilson» é uma empresa inteiramente fictícia, criada apenas para fins de demonstração. Não está afiliada, endossada, nem se destina a representar a Hilton Inc., a Hyatt Hotels Corporation ou qualquer empresa real de hotelaria.

Hilson Hospitality Group é um operador hoteleiro global com ~680 unidades em 18 marcas — desde bandeiras de luxo (nível Waldorf, nível Conrad), passando por full-service (Hilson, nível DoubleTree), até select-service e extended-stay. Cada unidade corre um Opera PMS on-premise e um CRS Amadeus central, servindo um mix de hóspedes de lazer transitório, corporativo negociado e grupos/convenções.

O negócio abrange loyalty (Hilson Honors com milhões de membros), vendas de grupos e convenções (pipeline Salesforce, blocos de quartos CPQ), pontos de food & beverage (POS MICROS Simphony), reporte a proprietário/franchise (extratos Oracle Fusion) e funções corporativas — gerando cerca de 1.900 reservas PMS e 1.750 cabeçalhos de folio num dia útil típico, com um pico de viagens de verão (junho–agosto) que eleva a ocupação, o ADR, o gasto de F&B e a atividade de loyalty em todas as unidades.

Entidades de amostra: A tabela abaixo mostra entidades de negócio representativas e os seus sistemas de origem; o EDW completo inclui entidades adicionais, subtipos e tabelas especializadas (p.ex. eventos de canal OTA, restrições de rate-plan, acordos legais de franchise, redlines de deal-desk) em todas as 62 tabelas bronze. Na V2, StayReservation e as classes de domínio relacionadas emitem linhas PMS, CRS, folio e loyalty através de adapters dos sistemas de origem à medida que o ciclo de vida da estadia avança.

Modelo de domínio OOP

HilsonEnterpriseSimulation sequencia o dia; os objetos de domínio são donos da lógica de emissão.

ReservationToLoyaltyAndOwnerReporting é a espinha dorsal primária do processo. StayReservation.execute_lifecycle() percorre reserva → sync PMS → encargos de folio → pagamento → pontos de loyalty → snapshot de ocupação → extrato do proprietário → GL. HilsonPortfolio.publish_foundation() masteriza marcas, unidades e membros Honors antes de as reservas correrem.

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]
          

Cadeia de valor de hóspede e unidade

Do mestre de marca e de unidade, passando por distribuição, estadia, liquidação e reporte ao proprietário.

Vista de amostra: Isto ilustra a cadeia de valor primária através do ecossistema Hilson; o EDW gerado completo inclui os 31 sistemas de origem, com integrações transversais, fluxos de receita secundários e fluxos de ciclo de vida de loyalty não mostrados aqui.

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

Organização funcional por departamento

Sede empresarial e funções de reporte direto, com sistemas de origem representativos.

Estrutura organizacional de amostra: Isto mostra as linhas de reporte primárias; a organização Hilson completa inclui gestão regional adicional, equipas específicas de marca e funções de shared-services em todas as 31 integrações de fornecedor.

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]
          

Estádios de maturidade do EDW

Catálogo stage agrupa tabelas desde a fundação até ao corporativo.

Desagregação de amostra apresentada: Isto é um recorte representativo do inventário completo de 62 tabelas, distribuído pelas camadas de maturidade; a distribuição real reflete a linhagem completa de dados desde a fundação até às tabelas gold 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 nucleares do negócio

Relações lógicas e chaves âncora. Unidade (hotel_code) é a espinha dorsal; identidade do hóspede via Honors e tabelas de estadia.

Diagrama de amostra: Este diagrama de relação de entidades mostra o modelo lógico nuclear; o EDW gerado completo contém 62 tabelas bronze em 31 sistemas de fornecedor com milhares de tabelas de detalhe adicionais e ramos de linhagem.

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
          

Paisagem de sistemas de origem

31 prefixos de fornecedor, 62 tabelas bronze.

Sistemas de amostra apresentados: O diagrama abaixo ilustra sistemas de fornecedor representativos; o conjunto de dados gerado completo inclui os 31 sistemas, com a linhagem completa de tabelas e os pontos de integração ao longo do preenchimento histórico e dos streams live.

Cada tabela segue a {source_system_}__{entity} convenção de nomenclatura (p.ex. oracle_opera__reservation, hilson_loyalty__member), preservando a forma nativa das colunas do fornecedor e as chaves estrangeiras do esquema de exportação real de cada produto. O VibeBI infere a conformidade dos dados mestres quando promove os registos para silver e 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
          

Fluxo de dados de ponta a ponta

Sim OOP V2 → bronze em ClickHouse; semântica VibeBI → silver → gold na mesma instância.

Percurso OOP: kb/industries/hilson/ define a espinha dorsal das operações e o modelo de entidades; HilsonEnterpriseSimulation sequencia os ciclos de vida de domínio; SourceSystem os adapters exportam linhas nativas do fornecedor para 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 bronze em tempo real

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

Frequência em tempo real: Cada ciclo corre a máquina de estados de reserva-para-loyalty — os objetos de domínio emitem linhas correlacionadas de CRS, PMS, folio, F&B, pagamento, loyalty e GL; a escala varia por ciclo (base predefinida 5). Preencha qualquer intervalo de histórico de que precise (--days N); o Hilson inclui deteção de lacunas na tabela âncora 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 da estadia do hóspede

Máquina de estados ReservationToLoyaltyAndOwnerReporting — cada transição emite linhas de fornecedor.

Espinha dorsal do processo: Definido em kb/industries/hilson/process_model.yaml. Os modos de exceção (no-shows, chargebacks, upgrades de quarto) ramificam-se a partir do mesmo ciclo de vida da entidade, em vez de inserções aleatórias independentes.

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]
          

Categorias de tabelas bronze

O mesmo envelope de linhagem em cada tabela; a categoria controla atualização live vs. append em micro-lote.

Categorias de amostra: Todas as 62 tabelas bronze seguem este padrão de três categorias (snapshot, transação, evento), com metadados consistentes e acompanhamento de estado; o diagrama ilustra o padrão usado em todo o armazém.

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 da empresa

Aviso de empresa fictícia: «Cathea» é uma empresa inteiramente fictícia, criada apenas para fins de demonstração. Não é afiliada da Cathay Pacific Airways Limited, da Cathay Pacific Group nem de qualquer companhia aérea real, não é por elas endossada e não se destina a representá-las.

Cathea Pacific é uma transportadora hub de Hong Kong com sede em Cathea City, Chek Lap Kok — passageiros premium (HP), carga aérea e Cathea Cargo Terminal, LCC Peak Express (PX) e freighters Air Harbour Express (AH), mais o lifestyle Pacific Miles. A rede é temporizada em HKG: rotações long-haul A350/777, ondas noturnas 747-8F e hops regionais A321neo.

O dia corre encomenda NDC → PNR classe Altéa e e-ticket de prefixo 168 → captura de cartão Adyen → check-in DCS e scans de bagagem → OFP Navblue, duty de crew AIMS e MVT SITA (incluindo carga noturna 01:00–05:00 HKT) → accrual Pacific Miles e rating Accelya → journals SAP S/4. A carga percorre reserva Cargospot → AWB → aceitação de terminal → scan ULD → movement → trucking OTM → cobrança FPS — com um subida de viagem CNY / IRROPS tufão que dispara o load factor da Peak Express, os scans de bagagem e as waitlists de carga.

Entidades de amostra: A tabela abaixo mostra entidades de negócio representativas e os respetivos sistemas de origem; o EDW completo inclui entidades, subtipos e tabelas especializadas adicionais (p. ex. fuel uplifts, work orders TRAX, scans ULD, accruals de loyalty) em todas as 60 tabelas bronze. Em V2, Pnr e AirWaybill as classes de domínio impulsionam as spines OfferToFlyToRevenue e BookToDeliverCargo.

Modelo de domínio OOP

CatheaEnterpriseSimulation sequencia o dia; os objetos de domínio são donos da lógica de emissão.

OfferToFlyToRevenue é a spine de passageiros; BookToDeliverCargo é a spine de carga. Pnr.execute_lifecycle() percorre encomenda NDC → PNR e e-ticket Altéa → captura Adyen → check-in DCS → cupão voado → Pacific Miles → Accelya → GL. AirWaybill.execute_lifecycle() percorre reserva Cargospot → AWB → aceitação CHT → ULD → movement SITA → trucking OTM → cobrança FPS. CatheaPortfolio.publish_foundation() masteriza aeronaves, rotas, estações e voos temporizados em HKG antes de os PNR e AWB correrem.

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]
          

Cadeia de valor offer-to-fly e cargo

Do master de rede ao close financeiro, via passageiros, carga e ops.

Vista de amostra: Isto ilustra a cadeia de valor primária através do ecossistema Cathea; o EDW gerado completo inclui os 40 sistemas de origem com integrações transversais, ondas de carga noturna e MRO TRAX não mostrados aqui.

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

Organização funcional por departamento

HQ Cathea City Chek Lap Kok e funções de reporte direto com sistemas de origem representativos.

Estrutura organizacional de amostra: Isto mostra as linhas de reporting primárias; a organização Cathea completa inclui outstations adicionais, desks de carga GBA e funções de shared services nas 40 integrações de fornecedor.

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]
          

Estádios de maturidade do EDW

Catálogo stage agrupa tabelas desde a fundação até ao corporativo.

Desagregação de amostra apresentada: Isto é um recorte representativo do inventário completo de 60 tabelas, distribuído pelas camadas de maturidade; a distribuição real reflete a linhagem completa de dados desde a fundação até às tabelas gold 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 nucleares do negócio

Relações lógicas e chaves de âncora. Voo (flight_id) e PNR (pnr_locator) são a spine de passageiros; AWB (awb_number) liga o cargo via booking e FPS.

Diagrama de amostra: Este diagrama de relação de entidades mostra o modelo lógico nuclear; o EDW gerado completo contém 60 tabelas bronze em 40 sistemas de fornecedor com tabelas de detalhe adicionais e ramos de linhagem. As instâncias de entidade transportam entity_refs em cada evento emitido, para testes 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
          

Paisagem de sistemas de origem

40 prefixos de fornecedor, 60 tabelas bronze.

Sistemas de amostra apresentados: O diagrama abaixo ilustra sistemas de fornecedor representativos; o conjunto gerado completo inclui os 40 sistemas com linhagem de tabelas e pontos de integração no backfill de histórico e nos streams live. Os manifestos de sistemas de origem partilhados em kb/source_systems/ são reutilizados entre indústrias — a Cathea acrescenta cathea_network, cathea_ndc, cathea_cht, e cathea_loyalty como sistemas internos específicos da indústria, mais o PSS Altéa e o Cargospot.

Cada tabela segue a {source_system_}__{entity} convenção de nomenclatura (p.ex. cathea_network__flight, amadeus_altea__pnr), preservando a forma nativa das colunas do fornecedor e as chaves estrangeiras do esquema de exportação real de cada produto. O VibeBI infere a conformidade dos dados mestres quando promove os registos para silver e 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
          

Fluxo de dados de ponta a ponta

Sim OOP V2 → bronze em ClickHouse; semântica VibeBI → silver → gold na mesma instância.

Percurso OOP: kb/industries/cathea/ define a espinha dorsal das operações e o modelo de entidades; CatheaEnterpriseSimulation sequencia os ciclos de vida de domínio; SourceSystem os adapters exportam linhas nativas do fornecedor para 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 bronze em tempo real

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

Frequência em tempo real: Cada tick executa OfferToFlyToRevenue e BookToDeliverCargo — os objetos de domínio emitem encomendas NDC, PNR, bilhetes, scans DCS, AWB de carga, movements SITA, cobranças FPS e linhas GL correlacionados; os ticks live de hoje emitem apenas eventos até Hong Kong as_of para que check-ins, scans de bagagem, carga noturna e journals cresçam ao longo do dia. A escala varia por tick (base 5 por omissão). Faça backfill de qualquer intervalo de histórico de que precise (--days N no script live ou na 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 e cargo

Máquinas de estado OfferToFlyToRevenue e BookToDeliverCargo — cada transição é um método de domínio que emite linhas de fornecedor.

Espinha dorsal do processo: Definido em kb/industries/cathea/process_model.yaml. Os modos de late-arrival (lag de scan DCS, lag MVT, lag de batch RA, atraso de posting GL) e os modos de exceção (no-show, atraso IRROPS, recusa de cartão, short shipment, waitlist de capacidade) ramificam-se dos mesmos ciclos de vida da entidade em vez de inserts aleatórios independentes.

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]
          

Categorias de tabelas bronze

O mesmo envelope de linhagem em cada tabela; a categoria determina o comportamento live.

Categorias de amostra: Todas as 60 tabelas bronze seguem este padrão de três categorias (snapshot, transação, evento), com metadados consistentes e acompanhamento de estado; o diagrama ilustra o padrão usado em todo o armazém.

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 da empresa

Aviso de empresa fictícia: «P&C» é uma empresa inteiramente fictícia, criada apenas para fins de demonstração. Não está afiliada, endossada, nem se destina a representar The Procter & Gamble Company ou qualquer fabricante real de CPG.

P&C é um fabricante-marketer global de bens de consumo embalados — um modelo B2B2C que vende produtos de uso diário através de canais de grande retalho, club, mercearia e e-commerce em ~180 países. Cinco Sector Business Units (SBUs) abrangem Fabric & Home Care, Baby/Feminine/Family Care, Beauty, Health Care e Grooming, com ~12 marcas de referência (TidalWave, ComfortWrap, BrightSmile, EdgePro e outras) e oito fábricas mais três centros de distribuição regionais.

O negócio abrange planeamento da procura, procurement de matérias-primas, produção MES, libertação de qualidade, distribuição de produtos acabados, encomendas de clientes retalhistas, trade marketing e finanças — gerando ordens de trabalho MES correlacionadas, POs Ariba, cabeçalhos OMS, expedições OTM e linhas de diário SAP em cada dia de simulação, com um Pico Spring Clean (março–abril) que eleva a procura de cuidados de tecidos/lar, o débito das fábricas e o sell-in retalhista na América do Norte e na EMEA.

Entidades de amostra: A tabela abaixo mostra entidades de negócio representativas e os seus sistemas de origem; o EDW completo inclui entidades adicionais, subtipos e tabelas especializadas (p.ex. leituras de sensores IoT, ordens de manutenção, promoções comerciais, redlines CLM) em todas as 60 tabelas bronze. Na V2, ProductionBatch e CustomerOrder as classes de domínio impulsionam a espinha dorsal MakeToShipToSell.

Modelo de domínio OOP

PcEnterpriseSimulation sequencia o dia; os objetos de domínio são donos da lógica de emissão.

MakeToShipToSell é a espinha dorsal primária do processo. ProductionBatch.execute_lifecycle() percorre previsão → procurement → produção → libertação QC → produtos acabados; CustomerOrder.execute_lifecycle() percorre captura OMS → fulfillment WMS → expedição OTM. PcPortfolio.publish_foundation() masteriza SBUs, marcas, fábricas, SKUs e contas retalhistas antes de os lotes e as encomendas correrem. Objetos de serviço (PlantOperations, CommercialProgram, FinanceAndCorporate) emitem linhas de suporte corporativas e de marketing.

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]
          

Cadeia de valor make-to-ship

Do portefólio de marcas, passando por planear, produzir, mover, vender e fecho corporativo.

Vista de amostra: Isto ilustra a cadeia de valor primária no ecossistema P&C; o EDW gerado completo inclui os 34 sistemas de origem, com integrações transversais, telemetria IoT de fábrica e fluxos de trade marketing não mostrados aqui.

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

Organização funcional por departamento

Sede global em Cincinnati e funções de reporte direto, com sistemas de origem representativos.

Estrutura organizacional de amostra: Isto mostra as linhas de reporte primárias; a organização P&C completa inclui equipas regionais de SBU, gestores de fábrica e funções de shared-services em todas as 34 integrações de fornecedor.

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]
          

Estádios de maturidade do EDW

Catálogo stage agrupa tabelas desde a fundação até ao corporativo.

Desagregação de amostra apresentada: Isto é um recorte representativo do inventário completo de 60 tabelas, distribuído pelas camadas de maturidade; a distribuição real reflete a linhagem completa de dados desde a fundação até às tabelas gold 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 nucleares do negócio

Relações lógicas e chaves âncora. Marca (brand_code) e fábrica (facility_code) são a espinha dorsal; os números de material ligam o PIM ao MES.

Diagrama de amostra: Este diagrama de relação de entidades mostra o modelo lógico nuclear; o EDW gerado completo contém 60 tabelas bronze em 34 sistemas de fornecedor com tabelas de detalhe adicionais e ramos de linhagem. As instâncias de entidade transportam entity_refs em cada evento emitido, para testes 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
          

Paisagem de sistemas de origem

34 prefixos de fornecedor, 60 tabelas bronze.

Sistemas de amostra apresentados: O diagrama abaixo ilustra sistemas de fornecedor representativos; o conjunto de dados gerado completo inclui os 34 sistemas, com a linhagem completa de tabelas e os pontos de integração ao longo do preenchimento histórico e dos streams live. Manifests partilhados de sistemas de origem em kb/source_systems/ são reutilizados entre indústrias — o P&C acrescenta pc_brand como um sistema interno específico da indústria.

Cada tabela segue a {source_system_}__{entity} convenção de nomenclatura (p.ex. pc_brand__brand, siemens_mes__work_order), preservando a forma nativa das colunas do fornecedor e as chaves estrangeiras do esquema de exportação real de cada produto. O VibeBI infere a conformidade dos dados mestres quando promove os registos para silver e 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
          

Fluxo de dados de ponta a ponta

Sim OOP V2 → bronze em ClickHouse; semântica VibeBI → silver → gold na mesma instância.

Percurso OOP: kb/industries/pnc/ define a espinha dorsal das operações e o modelo de entidades; PcEnterpriseSimulation sequencia os ciclos de vida de domínio; SourceSystem os adapters exportam linhas nativas do fornecedor para 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 bronze em tempo real

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

Frequência em tempo real: Cada ciclo corre a máquina de estados MakeToShipToSell — os objetos de domínio emitem linhas correlacionadas de previsão, PO, MES, WMS, OMS, OTM e GL por lote de produção e encomenda de cliente retalhista; a escala varia por ciclo (base predefinida 5). Preencha qualquer intervalo de histórico de que precise (--days N no script live ou na 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 make-to-ship

Máquina de estados MakeToShipToSell — cada transição é um método de domínio que emite linhas de fornecedor.

Espinha dorsal do processo: Definido em kb/industries/pnc/process_model.yaml. Os modos de exceção (refugo de lote, retenção de qualidade, expedição parcial, atraso de fornecedor) ramificam-se a partir dos mesmos ciclos de vida das entidades, em vez de inserções aleatórias independentes.

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]
          

Categorias de tabelas bronze

O mesmo envelope de linhagem em cada tabela; a categoria determina o comportamento live.

Categorias de amostra: Todas as 60 tabelas bronze seguem este padrão de três categorias (snapshot, transação, evento), com metadados consistentes e acompanhamento de estado; o diagrama ilustra o padrão usado em todo o armazém.

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