Inteligência de Mercado Colliers | AS-IS vs. TO-BE

colliers inteligencia-mercado spec arquitetura

Análise comparativa estruturada do que existe hoje (AS-IS) vs. o que propomos (TO-BE), baseada na análise da planilha modelo recebida em 25/04. Esta é a peça que sustenta a sessão de validação com Leandro Braga em 30/04 17:00. Para o detalhe campo-a-campo, ver dicionário de dados. Para a visão arquitetural geral, ver spec.

Veredito geral

“Modelo simples, tudo em Excel, com muita oportunidade de melhoria e automação” — Pedro Villa, 25/04.

A planilha confirma o diagnóstico. Mais grave: o modelo de dados em si tem 27 problemas estruturais identificáveis a olho nu, antes mesmo de discutir tecnologia. Excel é o sintoma; o problema é a ausência de modelagem disciplinada. Migrar para Lakehouse sem corrigir o modelo é trocar de prateleira mantendo o estrago.

Ao mesmo tempo, o conteúdo da base é riquíssimo — 10 anos de histórico, ligações com SiiLa, Buildings, CVM (via ticker), métricas de mercado granulares. O ativo de informação é real. A oportunidade é proporcional ao tamanho do problema.

Mapa de problemas

Categoria 1 — Denormalização e duplicação

ID	Problema	Localização	Impacto
D1	Campos do imóvel (Tipo, Mercado, Nome, Região, Classe, Data_Entrega, STATUS) repetidos em CADA linha de BASE	BASE OFFICE cols B-H, BASE LOGÍSTICA cols B-H	Mudança de nome do imóvel = update em N linhas; risco de inconsistência
D11	Nome, Região, IDs externos repetidos em CONTROLE	CONTROLE OFFICE cols B,C,H,I; CONTROLE LOGÍSTICA cols B,J,K	Operação humana de manter sincronia; alto risco de drift

Causa raiz: Excel não impõe foreign keys; copiar e colar foi mais fácil que criar relação.

Custo estimado hoje: quando o nome de um empreendimento muda (ex: “Ebony Tower” passa a ter um sub-rótulo), o operador precisa lembrar de atualizar o nome em 30 linhas trimestrais × 10 anos = ~1200 linhas só para um imóvel.

Categoria 2 — Inconsistência de schema cross-segmento

ID	Problema	Office	Logística	Severidade
D13	Nome da PK do imóvel	`ID`	`ID_Novo`	Alta
D17	Convenção lat/long	`Lat`/`long`	`Latitude`/`Longitude`	Média
D18	Schemas FICHA divergentes	tem `Vagas`, `Ar_Condicionado`, `Distância_SP`	tem `Docas`, `Sprinklers`, `Distância_Capital`, `Eficiência_Logística`	Aceitável (parcial)
D23	Nome da PK em CONTROLE	`ID`	`ID_Novo`	Alta
D24	Headers em CONTROLE	`Telefone`, `E-mail`, `Contato`	`Pesquisa_Telefone`, `Pesquisa_Email`, `Pesquisa_Responsável`	Alta
D27	Office tem `Ticker fundo` + `Saída prevista` em CONTROLE; Logística não	sim	não	Média (perda de info)

Causa raiz: evolução orgânica da planilha — Office e Logística cresceram em paralelo, sem governança de schema unificado.

Custo estimado hoje: qualquer query, dashboard ou agente que precise atravessar os dois segmentos depende de N condicionais por nome de campo. Inviabiliza views Gold pan-segmento sem retrabalho manual.

Categoria 3 — Falta de chave estrangeira (CRÍTICO)

ID	Problema	Localização	Impacto
D6	VENDA OFFICE.ID está em faixa diferente (68149) e não liga a FICHA TÉCNICA OFFICE.ID (500048)	VENDA OFFICE.A	Match impossível por chave; precisa fuzzy por nome+endereço
D19	VENDA LOGÍSTICA não tem ID nenhum	VENDA LOGÍSTICA	Match obrigatoriamente por texto livre — quebra silenciosamente

Causa raiz: transações de mercado vêm de fontes externas (notícias, relatórios, fundos) com nomenclatura própria. Reconciliação manual nunca foi formalizada.

Custo estimado hoje: análises de cap rate por imóvel, histórico de transações por proprietário, série temporal de preços por ativo — tudo isso depende de match texto-livre. A informação existe e está perdida.

Categoria 4 — Derivados armazenados como dados

ID	Problema	Onde	Comentário
D5	Absorção e Devolução são deriváveis de `Ocupante` vs. `Ocupante_Devolução`	BASE OFFICE cols O,P; BASE LOGÍSTICA cols S,T	Cálculo simples (delta) virou input manual
D9	`Preço (R$/m²)` armazenado em VENDA OFFICE	VENDA OFFICE.M	É calculável: `Preҫo` ÷ `Área Privativa Transacionada`
D15	`Preço Ponderado` em BASE LOGÍSTICA hardcoded em 0	BASE LOGÍSTICA.AC	Cálculo derivado feito (provavelmente) no Power BI; aqui aparece como dado

Custo estimado hoje: quando o operador esquece de atualizar a coluna derivada após uma correção, a base entra em estado inconsistente sem warning.

Categoria 5 — Conceitos sobrepostos e mal modelados

ID	Problema	Onde	Comentário
D4	4 colunas de “papel comercial”: `Proprietário_Grupo`, `Administração`, `Comercialização`, `Empresa_Locacao`	BASE OFFICE T,V,W,X; BASE LOGÍSTICA X,Z,AA,AD	Papéis confusos e nem sempre exclusivos. Não há tabela de empresas com papéis tipados.
D10	CONTROLE mistura CRM mini (contatos) com status de pesquisa	CONTROLE OFFICE D-G + J-L	Dois conceitos distintos numa mesma tabela
D16	`Região` e `Região_Geográfica` lado a lado em BASE LOGÍSTICA	cols E e AB	Duas hierarquias geográficas; relação não documentada

Causa raiz: tabela única “espalhada” tenta capturar tudo sem normalizar entidades.

Categoria 6 — Tipos misturados / formatos frágeis

ID	Problema	Onde	Comentário
D2	`CONJUNTO` mistura número (sala) e texto (“Andar inteiro”)	BASE OFFICE.J	Tipo misto
D3	`Trimestre` em formato “YYYY NT”	BASE.*	Não-ordenável lexicograficamente
D14	`Módulo` mistura “All” (galpão inteiro) com códigos M.NN	BASE LOGÍSTICA.J	Semânticas diferentes na mesma coluna
D20	Cap Rate em decimal (0.0926) ou percentual (11.73)	VENDA OFFICE vs VENDA LOGÍSTICA	Sem normalização de unidade

Categoria 7 — Erros tipográficos em headers

ID	Problema	Onde	Comentário
D7	`Preҫo` com `Ҫ` cirílico (U+04AA) em vez de `Ç` latino	VENDA OFFICE.I	Quebra busca/regex/scripting
D21	`Preҫo` cirílico de novo + nome diferente do Office	VENDA LOGÍSTICA.L,P	Mesma armadilha duplicada
D25	`Região\|Cidade` com pipe (`\|`) no nome do header	CONTROLE LOGÍSTICA.H	Quebra exportações CSV/Markdown/SQL
D26	`Melhor forma de contato` com espaço final	CONTROLE LOGÍSTICA.O	Bug invisível em joins por nome de coluna

Custo estimado hoje: scripts e ETLs que filtram por “Preço” não encontram nada. Operadores recém-chegados acham que a coluna está vazia. Bug silencioso.

Categoria 8 — Sem schema validation

Sem tipos formais, sem enums declarados, sem ranges. Toda validação depende da memória do operador. Dependendo de qualquer pessoa entrar e digitar valor errado, a base degrada. Não há automação de qualidade.

Mapa de oportunidades

A planilha também revelou oportunidades concretas que reforçam (ou expandem) a spec original:

Op 1 — Integração SiiLa e Buildings já tem chave

ID_SiiLa e ID_Buildings estão em ambas as FICHAS. Nem precisamos fazer reconciliação fuzzy: a chave existe.

Implicação: ETL para enriquecimento com SiiLa e Buildings é trivial. Pode entrar na primeira onda de Silver.

Op 2 — Ticker de fundos imobiliários já mapeado (Office)

CONTROLE OFFICE tem Ticker fundo e Saída prevista. Esse é o link para CVM/B3/relatórios gerenciais.

Implicação: integração com a base de fundos imobiliários (já em curso) tem chave nativa para Office. Para Logística, adicionar campo equivalente é one-shot.

Op 3 — Eficiência Logística é métrica derivada óbvia

Em FICHA TÉCNICA LOGÍSTICA, Eficiência_Logística = 0.78 (ABL/Área Total). Métrica simples, derivável.

Implicação: padronizar uma família de métricas derivadas (eficiência, ocupação trimestral, absorção líquida, vacância) é exercício mecânico. Pode virar feature engineering canônica em Silver.

Op 4 — Saída prevista é informação ouro de prospecção

Saída prevista em CONTROLE OFFICE captura a previsão de fim de contrato — exatamente o input que alimenta a “cauda longa comercial” mencionada pelo Braga (ele quer prospectar quem vai sair em 3 anos).

Implicação: este campo, hoje informal e em texto livre, deveria virar coluna estrutural com data + confiança. Vira input direto para um agente de prospecção (reuso do Hunter da Onda 1 Costal).

Op 5 — Ocupante anonimizado revela disciplina de privacidade

A amostra veio com ocupantes “A”, “B”, “C” — Leandro tem disciplina de proteção de dado. Indica maturidade de governança.

Implicação: adicionar coluna Ocupante_anon (mascarada) ao lado de Ocupante real, com vista controlada por papel, é prática que ele já adota mentalmente. Formaliza fácil.

Op 6 — Histórico de Ocupante_Devolução é poderoso

A coluna Ocupante_Devolução no BASE captura quem ocupava no trimestre anterior. Isso já é uma série temporal de movimentação por subdivisão.

Implicação: essa série, se canonizada, gera de graça: tempo médio de permanência por classe/região, taxa de turnover por proprietário, padrões de saída por segmento.

Op 7 — Universo “B/C” é greenfield

Confirmado: a base só monitora alto padrão. Galpões pequenos, prédios médios, monousuários — fora do radar. Universo B/C é provavelmente 5–10× maior.

Implicação: ingestão de fontes externas (anúncios, fundos médios, CVM bairros menos cobertos) pode multiplicar volume × N sem refazer modelo — desde que o modelo seja unificado por segmento e admita ingestão automática.

Op 8 — Power BI consome direto do Excel

Hoje o Power BI lê do Excel. Migrar para Gold significa apenas trocar a fonte do Power BI — sem refazer dashboard. Refator transparente para o usuário final.

Implicação: cronograma pode ser conservador (manter Excel como fonte espelho durante a transição), garantindo zero downtime no produto comercial.

Modelo TO-BE proposto

Princípio: 3 camadas + segmentos preservados em Bronze, unificados em Silver

graph TB
    subgraph "Bronze — fiel ao Excel atual"
        B_O_BASE[base_office_bronze<br/>shape original]
        B_O_FICHA[ficha_office_bronze]
        B_O_VENDA[venda_office_bronze]
        B_O_CTRL[controle_office_bronze]
        B_L_BASE[base_logistica_bronze<br/>shape original]
        B_L_FICHA[ficha_logistica_bronze]
        B_L_VENDA[venda_logistica_bronze]
        B_L_CTRL[controle_logistica_bronze]
    end

    subgraph "Silver — modelo canônico unificado"
        S_IMOVEL[imovel<br/>PK: id_imovel]
        S_SUB[subdivisao<br/>FK: id_imovel<br/>tipo: andar_conjunto / galpao_modulo]
        S_OCUP[ocupacao<br/>FK: id_subdivisao + trimestre<br/>histórico temporal]
        S_EMP[empresa<br/>PK: id_empresa<br/>papéis: ocupante/proprietario/admin/comercializadora]
        S_TRANS[transacao<br/>FK: id_imovel<br/>tipo: venda / locacao]
        S_FONTE[fonte_pesquisa<br/>contatos + status]
        S_EXT_SIILA[ext_siila]
        S_EXT_BLD[ext_buildings]
        S_EXT_FII[ext_fundos_cvm]
    end

    subgraph "Gold — views para consumo"
        G_PBI[painel_mercado<br/>preserva shape Power BI atual]
        G_BATALHA[batalha_imoveis]
        G_PROSPECTOS[prospectos_caudalonga<br/>via saida_prevista]
        G_SINAIS[sinais_externos<br/>Receita + CAGED + CVM]
    end

    B_O_FICHA --> S_IMOVEL
    B_L_FICHA --> S_IMOVEL
    B_O_BASE --> S_SUB & S_OCUP
    B_L_BASE --> S_SUB & S_OCUP
    B_O_VENDA --> S_TRANS
    B_L_VENDA --> S_TRANS
    B_O_CTRL --> S_FONTE & S_EXT_FII
    B_L_CTRL --> S_FONTE

    S_EXT_SIILA --> S_IMOVEL
    S_EXT_BLD --> S_IMOVEL
    S_EXT_FII --> S_IMOVEL

    S_IMOVEL & S_SUB & S_OCUP & S_EMP & S_TRANS --> G_PBI & G_BATALHA & G_PROSPECTOS & G_SINAIS

Decisões de modelagem (a validar com Braga)

PK unificada id_imovel — string ou int sequencial; mapa de equivalência guarda os IDs herdados (Office=ID, Logística=ID_Novo/ID_Colliers).
subdivisao é polimórfica — uma única tabela com tipo enum (andar_conjunto para Office, galpao_modulo para Logística), atributos comuns (area, pe_direito, caracteristicas) e atributos específicos em colunas opcionais (docas, sprinklers para logística; tipo_estacionamento, vagas para office).
empresa como entidade própria — substitui as 4 colunas confusas (Proprietário, Administração, Comercialização, Empresa_Locacao). Tabela empresa_imovel_papel com FK + tipo enum + período de validade.
ocupacao é a série temporal canônica — uma linha por (subdivisao, trimestre). Absorção/Devolução/Vacância são derivados em Silver, não armazenados como input.
saida_prevista vira coluna estrutural — em ocupacao, com tipo date opcional + confianca enum (alta/média/baixa).
Métricas derivadas vivem em Silver — Preço Ponderado, Eficiência_Logística, Preço (R$/m²) calculadas, não armazenadas.
Cap Rate normalizado para decimal — convenção única (0.0926 ≡ 9,26%).
saida_prevista cobre ambos segmentos — não só Office.
Headers cirílicos eliminados — a entrada Bronze já normaliza nomes de coluna.
Fonte → entidade própria — Pesquisa_Empresa, Pesquisa_Responsável, Pesquisa_Telefone, Pesquisa_Email viram tabela fonte_pesquisa com FK para imóvel.

Diferença vs. ER inferido na spec inicial

A primeira versão da spec (24/04, antes do Excel chegar) propunha 5 entidades. Após análise da planilha real, são 9 entidades:

Entidade	Estava na v1?	Justificativa para incluir
imovel	sim	confirmada
subdivisao	sim (chamada `subdivisao` mesmo)	confirmada
ocupacao	sim	confirmada — agora granular por trimestre × subdivisão
empresa	sim	confirmada — tabela canônica para todos os papéis comerciais
transacao	sim	confirmada — venda + locação fechada
fonte_pesquisa	não	NOVA — captura o CONTROLE de cada empreendimento
ext_siila	não	NOVA — chaves já presentes na FICHA
ext_buildings	não	NOVA — chaves já presentes na FICHA
ext_fundos_cvm	não	NOVA — `Ticker fundo` em CONTROLE OFFICE liga direto a CVM

Ranking de oportunidades para a sessão 30/04

Para a sessão de validação com Braga, três decisões precisam ser tomadas (em ordem de impacto):

Decisão 1 — Unificar segmento ou preservar paralelo?

Opção A — Unificar Office + Logística no Silver com subdivisao polimórfica.

Pró: views Gold pan-segmento; queries únicas; reuso de agentes.
Contra: a estrutura física dos imóveis é genuinamente diferente (andar/conjunto vs. galpão/módulo); pode forçar abstração que confunde o operador.

Opção B — Preservar segmentos paralelos no Silver com schemas próprios + view unificada na Gold.

Pró: cada segmento mantém vocabulário próprio; menor curva.
Contra: duplica esforço; relatórios pan-segmento dependem de view manual.

Recomendação: A com subdivisao polimórfica. A diferença Office/Logística é capturada por tipo_subdivisao enum + atributos opcionais. Vale o investimento para destravar agentes que cruzam segmentos.

Decisão 2 — Como tratar transações sem chave estrangeira?

VENDA LOGÍSTICA não tem ID. Opções:

Opção A — Bootstrap: rodar fuzzy match (nome + endereço + cidade) por uma vez, gerar id_imovel_inferido, revisão humana de divergências. Daqui pra frente, id_imovel é obrigatório no input de novas transações.

Opção B — Aceitar perda histórica: do trimestre da migração em diante, nova disciplina; histórico fica como “linha solta” não-ligada ao cadastro de imóveis.

Recomendação: A. O esforço inicial de fuzzy match + revisão (~1 dia humano para algumas centenas de transações) destrava 10 anos de série temporal de cap rate por ativo. ROI altíssimo.

Decisão 3 — Onda 1 inclui qual escopo?

Hipótese-base (proposta):

Onda 1 (4–6 semanas pós-OK do Ricardo): Bronze + Silver para os 8 schemas atuais + dicionário formalizado + view Gold espelhando o Power BI atual (zero refator de dashboard).
Onda 2 (8–12 semanas): enriquecimento externo (SiiLa, Buildings, CVM via ticker, Receita, CAGED), feature engineering canônica (eficiência, absorção, vacância), interface de cadastro.
Onda 3 (12+ semanas): expansão para universo B/C, agentes proativos (Hunter, Trace), feature “batalha de imóveis”.

O que muda na spec principal

A spec geral precisa ser atualizada com:

ER real (9 entidades, não 5)
Lista das 27 dores observadas como inventário concreto (não hipóteses)
Inclusão de SiiLa, Buildings e CVM como integrações nativas (chave já existe)
Cronograma realista em 3 ondas
Reforço de risco operacional: quanto mais tempo o modelo atual fica em Excel, mais inconsistência se acumula
Ajuste de métrica de sucesso: incluir ”% de transações ligadas a imóvel via FK” como métrica de qualidade

Ver também

Análise por Pedro Villa em 2026-04-25, a partir da planilha modelo recebida em 25/04. Validação com Leandro Braga em 30/04 17:00.

Colliers × Costal — Interno

Explorador

Inteligência de Mercado Colliers — AS-IS vs. TO-BE