Spec | Orçamentação Costal — AS-IS v2.1

costal orcamentacao atlas spec

Autor: Pedro Villa + Antônio Pavanelli Versão: AS-IS v2.1 (consolidada após discovery 28/04 + revisão Igor 03/05 + revisão complementar Igor 05/05) Status: AS-IS validado com owners (Leandro operacional + Igor MD) — TO-BE pendente DP-1 Empresa: costal Owner Costal: Leandro Delecrodio (Gerente de Orçamentos) · Igor Reginato (MD — homologa o processo-alvo) Owner Anouk: Antônio Pavanelli (arquiteto de orçamentação)

Este documento substitui em valor o prep histórico de discovery. Consolida achados da 04 com Leandro, da 05 e da 05. Base para o TO-BE da Onda 1.

Mudanças v2 → v2.1 (resumo)

A revisão complementar de Igor 05/05 acrescenta 7 inputs estruturais:

§6.2 (NOVO) — GAPs e sobreposições de escopo entre fornecedores como ponto crítico de falha
§7.2 (NOVO) — Tabelas paramétricas combinadas com fornecedores-chave (evolução do disparo precoce)
§10.6 (NOVO) — Modelo de capacidade orçamentária — driver Meta de faturamento / Taxa de conversão = Volume a orçar + taxonomia bidimensional de complexidade
§10.7 (NOVO) — Codinome “Relay” para o agente irmão (DP-1 sinalizando Opção B)
§10.8 (NOVO) — Industrialização da dor D1 — esteira especializada em vez de processo artesanal
§10.9 (NOVO) — Take-off CAD/BIM como análise híbrida com etapa predecessora opcional
§10.10 (NOVO) — Rastreabilidade obrigatória de inputs, diálogos e premissas

Igor também propôs convenção de notação :warning: para destacar pendências (decisão pendente / hipótese / gap de informação) — aplicar em todas as specs.

Mudanças v1 → v2 (resumo)

A v2 adiciona seis blocos estruturais trazidos por Igor 03/05 que ampliam — não substituem — a fotografia operacional do Leandro:

§2a (NOVO) — Pacote mínimo de entrada: leitura/consolidação de premissas em paralelo ao take-off (memorial, marcos contratuais, condições de pagamento, vendor list, restrições, condições locais).
§6.1 (NOVO) — Princípio Costal: não compartilhar quantitativo interno com fornecedores. Disparar somente o pacote documental do cliente.
§9 (REESCRITO) — Cronograma 4 camadas (hard logic / soft logic / simulação / contingências) — substitui o modelo “ABC + sequenciamento de precedências”.
§9a (NOVO) — Validação dual: Scope Match + Análise de Riscos como etapas formais, não checagens informais.
§9b (NOVO) — Saída/Proposta canônica em 3 blocos (escopo, condições, exclusões) + estudos VE + savings projetados.
§10.5 (NOVO) — Acoplamento estrutural Orçamentos × Suprimentos × Obras como condição organizacional do Atlas.
§14 (REPOSICIONADO) — Change Orders saem do escopo nominal de Orçamentação → fluxo adjacente sob gerente de contrato (DP-3).
§15 (NOVO) — Telemetria e gestão de capacidade da área de orçamentos como bloco operacional próprio.

A §1 (contexto) ganha nova leitura estratégica: fragmentação Excel é janela de desenho fundacional, não passivo.

1. Definição do produto e contexto Costal

A Orçamentação Costal é o processo de transformação de um pedido heterogêneo (RFP, edital, projeto executivo, memorial, head count, ou texto livre) em uma proposta comercial com preço, cronograma e plano de ataque, capaz de competir em concorrências privadas.

Contexto da transição:

A Costal está em transição da Colliers — orçamentos historicamente foram feitos pela Colliers; Ricardo Betancourt está pressionando para que a operação seja migrada para dentro da Costal.
Hoje há R$ 300M+ em pipeline de orçamentos ativos.
Equipe atual: 2 orçamentistas — Leandro Delecrodio + Lucas, com pretensão de trazer mais 1.
Não existe gerente de construção na Costal ainda — rito interno de revisão é só com time comercial (Taiane).
Não existe pessoal de planejamento na Costal ainda — cronograma executivo + curva S definitiva ficam como pendência futura, pós-kickoff de obra.
Planilha-padrão Costal não existe — Leandro e Lucas trabalham com planilhas herdadas. Decisão deliberada de aguardar Sienge + IA antes de criar a planilha definitiva.

Mercado: Costal opera em iniciativa privada — SINAPI/TCPO/CUB são referência distante, não fonte de preço. Em obra pública (não atendida pela Costal), a tabela trava preço unitário; ajuste vem nas quantidades. Em iniciativa privada, sempre valor de mercado.

Leitura estratégica (Igor 03/05): a fragmentação atual em Excel não é desvio operacional, é janela fundacional. A Costal ainda não está presa a um legado rígido — existe espaço real para criar o padrão de excelência desde a origem, em vez de remendar uma prática consolidada. Sequência canônica do desenho: método → governança → entradas/saídas → critérios de validação → rastreabilidade → camada ferramental.

Estado	Conteúdo
Atual	Fragmentação e ausência de padrão único
Risco	Variabilidade, retrabalho, baixa rastreabilidade
Oportunidade	Desenhar o padrão-alvo já alinhado ao processo, dados e automação
Próximo passo	Transformar princípios em método canônico de orçamentação Costal

2. Tipos de entrada do orçamento

A entrada não é homogênea — afeta diretamente o esforço de levantamento e a presença de parâmetros (especificação técnica).

Tipo de entrada	Frequência	Implicação
Projeto executivo + memorial + caderno de encargos	Recorrente em RFPs grandes	Levantamento mais rápido (já tem legenda + quantidades)
Projeto BIM ou “quase-BIM” (com legenda completa)	Aumentando	Take-off facilitado
CAD apenas	Recorrente	Levantamento manual demorado
PDF de planta	Recorrente	Levantamento manual demorado
Memorial / head count + Word descrevendo necessidades	Recorrente em escritório corporativo	Costal monta test fit interno (Letícia) antes de orçar
”Estudo de massa” (1.600 m², escritório para 300 pessoas)	Existe	Leandro vira arquiteto — define materiais ele mesmo
”Papel de pão” / texto livre	Existe	Leandro define quase tudo

Convenção crítica de especificação técnica: todo item vai no Excel com formato "<material>, <marca>, <modelo>, ou equivalente técnico". Permite trocar fornecedor/marca em obra mantendo a especificação técnica, sem o item se transformar (piso vinílico → porcelanato).

Test fit interno: quando entrada é incompleta, Letícia (área comercial Costal) desenha plantinha base; Leandro orça em cima.

2a. Pacote mínimo de entrada — leitura/consolidação de premissas (NOVO Igor 03/05)

Diagnóstico: o AS-IS v1 começa em take-off. Falta a etapa formal de leitura e consolidação de premissas e restrições, que deve rodar em paralelo ao take-off — não como checagem tardia.

Pacote mínimo que precisa entrar formalmente:

Categoria	Conteúdo
Documental	Memorial descritivo · documentos de especificação do projeto · documentos de especificação do cliente
Contratual	Marcos contratuais / prazos · condições de pagamento · garantias · faturamento direto
Operacional	Restrições de projeto · vendor list / fornecedores homologados · condições locais de execução
Comercial	Premissas comerciais · logísticas · operacionais

Por que importa (impactos diretos):

custo financeiro
custo logístico
custo operacional
seleção de materiais e soluções
estratégia de suprimentos
risco de execução
aderência ao que o cliente realmente exige

Sem isso, o orçamento sai com 80+ hipóteses implícitas que viram discussão contratual depois. É a etapa que sustenta a §9a (Scope Match) e a §10.5 (acoplamento Orç × Sup × Obras).

→ Implicação Atlas: Atlas precisa de memorial estruturado para leitura semântica. Hoje o memorial é texto livre — pré-requisito a destravar (G-047).

3. Fluxo as-is consolidado

flowchart TB
    subgraph ENTRADA["1 — Entrada heterogênea"]
        A1[RFP completa<br/>com BIM] -.- A2[CAD/PDF<br/>sem BIM] -.- A3[Memorial +<br/>head count] -.- A4[Estudo de massa<br/>texto livre]
    end

    subgraph TF["1b — Test fit interno (quando aplicável)"]
        TF1["Letícia desenha<br/>plantinha base"]
    end

    subgraph LEV["2 — Levantamento (gargalo #1)"]
        L1["Take-off manual<br/>Excel + medições"]
        L2[2 dias escritório<br/>3 dias galpão]
    end

    subgraph CPU["3 — Composição de preço"]
        C1["Categoria comum<br/>(drywall, pintura)<br/>preço de cabeça"]
        C2["Categoria específica<br/>(elétrica, AC)<br/>cota fornecedor"]
        C3["Categoria detalhada<br/>(louças, luminária, mobiliário)"]
        C4["Categoria home center<br/>(item baixo volume)<br/>preço site -10%"]
    end

    subgraph FOR["4 — Cotação fornecedores (gargalo #2)"]
        F1["E-mail padrão<br/>cópia oculta<br/>Excel anexo"]
        F2["~300 e-mails / orçamento<br/>(60 itens × 5 fornec)"]
        F3[3 cotações ideal<br/>às vezes 1-2]
        F4[Cobrança via WhatsApp/<br/>telefone — passa o dia]
    end

    subgraph EQ["5 — Equalização (gargalo #3 — sensível)"]
        E1[Fornecedor preenche<br/>NOSSO Excel ✅]
        E2["Fornecedor manda<br/>modelo dele estruturado<br/>(piso vinílico, divisória)"]
        E3["Fornecedor decompõe<br/>por componente<br/>(luminária, mobiliário) ❌"]
        E4["Briga: cara, sua proposta<br/>vai no concorrente"]
    end

    subgraph BDI["6 — BDI + Cronograma + Proposta técnica"]
        B1["BDI 36% cheio<br/>18% c/ faturamento<br/>(em ajuste Costal)"]
        B2[Cronograma macro<br/>Excel · datas início/fim]
        B3[Proposta técnica<br/>PowerPoint · 1-2 dias]
        B4["Custo financeiro<br/>(prazo pgto cliente)"]
    end

    subgraph VAL["7 — Revisão interna"]
        V1[Time comercial<br/>NÃO há gerente construção]
    end

    subgraph CLI["8 — Proposta cliente"]
        Cl1[Formato cliente<br/>se exigir RFP]
        Cl2[Revisões 1, 2, 3, 4...<br/>cliente baixa escopo<br/>p/ chegar à verba]
    end

    subgraph KICK["9 — Kickoff de obra (após vitória)"]
        K1["Pessoal de obra +<br/>planejamento entram"]
        K2[Cronograma executivo<br/>curva S definitiva<br/>forma pgto]
    end

    ENTRADA --> TF
    ENTRADA --> LEV
    TF --> LEV
    LEV --> CPU
    CPU --> FOR
    FOR --> EQ
    EQ --> BDI
    BDI --> VAL
    VAL --> CLI
    CLI --> KICK

    style EQ fill:#ffe8e8,stroke:#c00
    style LEV fill:#fff4e8,stroke:#c65911
    style FOR fill:#fff4e8,stroke:#c65911

4. Tempos consolidados (validados 28/04)

Etapa	Duração apertada	Duração ideal
Levantamento (escritório 1.600 m²)	13h em 1 dia (intensivo)	2 dias
Levantamento (galpão / edificação)	+1 dia	3 dias
Composição de preço	(paralelo)	—
Cotação fornecedor (envio + recepção)	2 dias	4-5 dias
Equalização	1 dia	1 dia
BDI (Excel automático)	meio-dia	meio-dia
Cronograma macro	meio-dia	1 dia
Proposta técnica (PowerPoint)	1 dia	1-2 dias
Validação paramétrica	(já no Excel)	—
Revisão comercial Costal	(rápido)	—
Total	1 semana (apertado)	2 semanas (bom)

A equipe sempre paralela múltiplos orçamentos (2 orçamentistas + 1 a contratar).

5. Stack tecnológico AS-IS

5.1 Visão de sistemas

flowchart TB
    subgraph INPUT["Inputs heterogêneos"]
      RFP[RFP / Edital]
      BIM["Projeto BIM<br/>(quando vem)"]
      CAD[CAD / PDF]
      MEM[Memorial / Word]
    end

    subgraph TOOLS["Ferramentas atuais"]
      EX[Excel<br/>planilha mestre orçamentista]
      PPT[PowerPoint<br/>proposta técnica]
      EM[E-mail Outlook]
      WPP[WhatsApp]
      TEL[Telefone]
    end

    subgraph EXTREF["Referências externas (eventual)"]
      SIN["SINAPI/TCPO/CUB<br/>(referência distante,<br/>não fonte de preço)"]
      HC["Home center<br/>Tigre etc.<br/>(direto no site)"]
    end

    subgraph REPO["Repositório atual"]
      RCO["Rede Colliers<br/>pasta cliente ×<br/>categoria × fornecedor"]
    end

    subgraph FUT["Pendentes (definição IA + Sienge)"]
      PCO["Planilha padrão Costal<br/>(NÃO criada ainda)"]
      SIE[Sienge — linha de base<br/>após vitória]
    end

    INPUT --> EX
    EX --> EM
    EM --> WPP
    WPP --> TEL
    EX <-.-> EXTREF
    EX --> PPT
    EX --> RCO
    EX -.->|após vitória<br/>quando tiver| SIE

5.2 Detalhamento

Sistema	Status	Notas
Excel	Sistema central	Planilha-mestre do orçamentista; faz BDI automático; tem comparações por m² embutidas
PowerPoint	Proposta técnica (plano de ataque)	1-2 dias para montar; “nenhum cliente lê, mas tem que mandar”
E-mail Outlook	Disparo a fornecedor	~300 e-mails por orçamento (60 itens × 5 fornec); cópia oculta
WhatsApp + telefone	Cobrança ativa de fornecedor	”Passo o dia cobrando” — propostas chegam às 11 da noite
Rede Colliers (SharePoint)	Repositório de propostas	Pasta cliente → subpasta categoria → subpasta fornecedor com Excel + PDF de e-mail
SINAPI/TCPO/CUB	Referência distante	Não usado em iniciativa privada — “vai faltar dinheiro para entregar a obra”
Home center (Tigre etc.)	Fonte de preço para itens baixos	Direto no site, com 10% de desconto
Planilha-padrão Costal	NÃO existe	Decisão deliberada de aguardar Sienge + IA antes de criar
Sienge	Não está em uso ainda para orçamento	Em parametrização; entrará como linha de base pós-vitória
Power BI	N/A	Não usado em orçamentação Costal hoje
MS Project / Primavera	Não usado	Cronograma macro vai em Excel

5.3 Repositório de propostas (estrutura validada)

[Rede Colliers (SharePoint)]
└── Pasta do cliente
    ├── (subpastas diversas)
    └── Propostas dos fornecedores
        ├── Luminária
        │   ├── Promolose
        │   │   ├── proposta.xlsx
        │   │   └── e-mail.pdf
        │   ├── Lume Center
        │   └── Interlite
        ├── Ar-condicionado
        ├── Mobiliário
        └── (...)

Implicação para Data Lake: ingestão estruturada por cliente × categoria × fornecedor é viável; desafio é parsing semântico do conteúdo das propostas (cada fornecedor com seu formato).

6. Tipologia de fornecedores e equalização ⚠ TEMA SENSÍVEL

A equalização de propostas tem complexidade desproporcional ao restante do processo.

Categoria	Comportamento	Esforço de equalização
Comportados (piso vinílico, divisória industrial)	Mandam preço por m² no formato deles, mas correlacionado	Baixo — copia/cola direto
Disciplinados	Preenchem o Excel-padrão Costal	Zero — copia/cola direto
”Briga recorrente” (luminária, mobiliário)	Decompõem o produto em componentes (corpo + lâmpada + reator + plug; tampo + pé + caixa de conectividade + divisor frontal)	Alto — meio-dia para equalizar 1 proposta
Louças/metais	Repetem o mesmo item em múltiplas linhas (1 vaso por banheiro × N banheiros × N andares)	Médio — 50 folhas para 5 preços
Home center direto (Tigre etc.)	Lendo o site	Baixíssimo — preço online com 10% desconto

Estratégia atual de Leandro contra fornecedores indisciplinados:

Reunião antes da 1ª proposta para alinhar formato.
Se mandar fora do padrão: “eu pego sua proposta e jogo fora” — usa preço do concorrente do cara, eventualmente ajusta para chegar ao valor.
Negociação caso a caso para forçar planilha-padrão.

Por que isso é sensível arquiteturalmente:

Equalização não é commodity — exige conhecimento de produto + lógica de agrupamento + relacionamento com fornecedor + precificação do home center como benchmark.
É onde Leandro extrai diferencial competitivo — “se o agente faz isso bem, libero metade do meu dia”.
Risco de tratamento simplificado — equalização não é “comparar 3 valores e pegar o menor”; envolve normalização semântica de escopo + decisão sobre uso de preço do concorrente.

🔓 Decisão de projeto pendente (Pedro): este achado motivou uma reflexão de arquitetura — possível desmembramento de um agente dedicado a fornecedores e equalização, separado do Atlas. Ver §10.

6.1 Princípio Costal — não compartilhar quantitativo interno (Igor 03/05)

“Não nos comprometemos enviando levantamento de quantitativos para os fornecedores, pois assumiríamos em nome deles o risco de eventuais levantamentos errados.”

Regra operacional: o que enviamos ao fornecedor é o pacote documental que recebemos do cliente — memorial, especificações, restrições. O fornecedor faz o próprio levantamento.

Nosso quantitativo interno serve a um propósito específico: linha de base de comparação durante a equalização. Identificamos desvios entre o nosso quantitativo e o do fornecedor — não o impomos.

Implicações:

Atlas (módulo de disparo a fornecedor): NÃO pode vazar o take-off interno. Disparo automatizado envia somente o pacote documental do cliente.
Cobertura de risco: transferimos o risco de levantamento errado ao fornecedor; Costal preserva sua linha de base interna como controle.
Ligação com §2a: o pacote documental do cliente precisa estar consolidado e estruturado para envio. Reforça a importância da etapa formal de leitura.

→ Promove a: R-022 (Atlas vazar quantitativo interno é risco operacional crítico).

6.2 GAPs e sobreposições de escopo entre fornecedores (NOVO Igor 05/05)

Lições aprendidas trazidas por Igor: muitos orçamentos falham por falhas de interface entre escopos cotados.

Problema clássico — GAPs (mais comum):

“O fornecedor do ar-condicionado orça os equipamentos e os serviços, mas não a alimentação elétrica entre o quadro elétrico e os equipamentos. O fornecedor de elétrica orça os quadros e cabos, mas não orça a interligação dos equipamentos de ar-condicionado, alegando que não mexe com ar-condicionado e que não quer assumir riscos relacionados ao funcionamento.”

Resultado: o GAP não pode ser repassado ao cliente (que comprou solução turn-key) — a Costal arca com o custo. Ponto cego clássico que destrói margem.

Problema menos comum mas relevante — Sobreposições:

“Duas empresas para executar a mesma coisa. Apesar de ser possível negociar isso durante a execução, temos eventuais riscos de litígios por redução de escopo contratual, mas o principal ponto é apresentarmos um preço para o cliente de um escopo superestimado por sobreposição de partes do escopo.”

Resultado: preço inflado → menos competitivo + risco de litígio na execução por redução de escopo.

Implicações Atlas:

Detector de GAPs — cruzar memorial técnico × somatório dos escopos cotados; alertar interfaces órfãs (alimentação elétrica de HVAC, estruturação metálica vs civil, drywall vs forro, marcação vs piso, etc.)
Detector de sobreposições — mesmo serviço/material aparecendo em 2+ propostas → flag de superprecificação
Scope Match (§9a.1) reforçado — cobrir explicitamente interfaces técnicas, não só escopo macro
Catálogo de interfaces críticas (paramétrico, evolui obra a obra) — cada tipologia tem interfaces-padrão que historicamente apresentam GAPs

Princípio: “Toda fragmentação de escopo traz ganho de especialização da mão-de-obra e know-how das empresas, mas trás pontos de interface, onde os GAPs aparecem.”

→ Promove a: Atlas (capacidades novas — Detector de GAPs, Detector de Sobreposições), §9a.1 reforçada, R-025 (GAP) e R-026 (sobreposição).

7. Política de cotação e número mínimo

Regra	Valor
Cotações ideais por disciplina	3-5
Cotações típicas conseguidas	1-3
Itens curva A / críticos	Sempre buscar mínimo 3
Itens commodity (drywall, pintura)	Aceitável trabalhar com preço de cabeça (varia <5% no ano)
Tempo dado a fornecedor	2 dias (apertado) a 5 dias (ideal)
Cobrança ativa	E-mail + WhatsApp + telefone — começa cedo no dia do prazo
Recepção fora do prazo	Aceitável se houver revisão comercial pendente
Proposta ao cliente sem 100% de cotação?	Não — a proposta vai 100% preenchida; Leandro liga, formaliza por telefone, ajusta na planilha

7.1 Disparo precoce a fornecedores — regra operacional (Igor 03/05)

Princípio canônico: Dependência de terceiro = acionamento prioritário e paralelo.

Aplica especialmente a:

fornecedores estratégicos
parceiros especializados
pacotes técnicos com cotação externa obrigatória (HVAC, terraplanagem, instalações elétricas pesadas)
serviços e materiais fora da lógica puramente paramétrica

Por que precisa ser paralelo, não tardio:

comprime tempo total de orçamento
antecipa gargalos de resposta externa
aumenta janela de análise crítica das propostas recebidas
permite equalização mais qualificada
aumenta segurança e competitividade do envio final

Ligação com §6.1: como Costal não compartilha quantitativo interno, o disparo cedo do pacote documental do cliente para parceiros é ainda mais crítico — o tempo de levantamento do fornecedor corre em paralelo ao nosso, não em série.

→ Implicação Atlas: módulo de disparo precisa identificar dependência crítica de terceiro (paramétrico × especial — §10.2) e priorizar o envio do pacote documental antes mesmo do fechamento do quantitativo interno.

7.2 Tabelas paramétricas combinadas com fornecedores-chave (NOVO Igor 05/05)

Evolução natural do disparo precoce. Em vez de cotar a cada orçamento, combinar previamente tabelas com fornecedores-chave.

Igor: “Quanto a suprimentos, um grande ganho que temos em desenvolver parceiros e fornecedores-chave é combinarmos (previamente) tabelas de preços, sejam estes unitários ou paramétricos vinculados a área/volume/comprimento/etc. De tal maneira que reduza consideravelmente a necessidade de acessos aos fornecedores.”

Tipos de tabela:

Tipo	Exemplo
Unitárias	Preço por unidade fixa (R $/ m^{2} d e d ry w a ll, R$ /m³ de concreto FCK 25)
Paramétricas	Preço como função de variável (R $/ m^{2} + R$ /m de pé-direito; R $/ l o t e + R$ /peça acima de N)
Por escopo combinado	Pacote técnico fechado (HVAC para piso de N m² com X torres, fornecimento + serviço + comissionamento)

Implicações Atlas:

Capacidade nativa — Atlas pré-popula cotação a partir de tabelas combinadas com fornecedores-chave
Disparo seletivo — só dispara cotação para fornecedores fora da tabela ou para itens fora do range paramétrico
Validação periódica — tabelas precisam de revisão (semestral? anual? gatilho de variação?)
Governança das tabelas — quem mantém? quem revisa? armazenamento canônico?

→ Promove a: spec §10 (Atlas — capacidade), nova decisão pendente (governança das tabelas paramétricas), G-050 (mecanismo de manutenção de tabelas).

8. BDI, encargos e custo financeiro (Costal — em ajuste)

Item	Valor atual	Status
BDI cheio (sem faturamento direto)	~36%	Em ajuste; pendente validação contábil Conecta
Imposto com faturamento direto	~18%	Em ajuste; pendente validação contábil Conecta
Custo financeiro	Linha separada na proposta	Aplicado quando prazo pgto cliente > duração obra
Indiretos	Bloco próprio na planilha	Canteiro, equipe, documentação
Diretos	Bloco próprio na planilha	Demolição → acabamento

8.1 Drivers do BDI ajustado por contexto (Igor 03/05)

O BDI não é margem fixa. A formação do preço de venda deve considerar:

Driver	Como impacta
Localização do projeto	Logística de canteiro · disponibilidade e custo de MDO local · custo de transporte
Condições de pagamento	Faturamento direto reduz carga tributária · prazo cliente vs prazo fornecedor cria custo financeiro · garantias exigidas reduzem caixa
Macro schedule / marcos contratuais	Período de mobilização fixo · custo de manter equipe parada entre marcos · multas por atraso
Apetite Costal pelo cliente/projeto	Validação estratégica — Costal ajusta para ser mais ou menos competitiva caso a caso (§10a)

→ Implicação Atlas: o cálculo do BDI no agente precisa receber esses drivers como input, não como tabela estática.

8.2 Aprovação comercial e Engenharia de Valor paralela (Igor 03/05)

Dois pontos que precisam virar etapas formais, não checagens informais:

1. Validação estratégica do preço final (sempre):

Apetite pelo cliente/projeto (relacionamento, pipeline, cliente estratégico vs oportunista)
Riscos do contrato
Momento de demanda interna (capacidade ociosa × pleno emprego)
Resultado: Costal ajusta para ser mais ou menos competitiva caso a caso

2. Engenharia de Valor (VE) / Reengenharia paralela:

“É muito comum que as especificações de projetos passadas pelos clientes normalmente não caibam no budget do projeto. Então, os clientes sempre solicitam ou gostam de receber estudos paralelos de revisão de especificação de materiais, faseamento do projeto, revisão de condições comerciais e tributárias (faturamento direto, por exemplo), a fim de otimizarmos os custos do projeto e conseguir encaixar, ou se aproximar ao máximo do budget.”

VE não é afterthought — roda em paralelo ao orçamento padrão. A proposta final apresenta:

versão padrão (especificação original)
cenários VE com savings projetados
recomendação Costal sobre quais sugestões embutir no preço final

→ Implicação Atlas: suporte a trilha paralela de VE é capacidade nativa, não plugin. Atlas gera os dois cenários e marca explicitamente o que foi/não foi embutido na proposta final.

9. Cronograma — 4 camadas (REESCRITO Igor 03/05)

Abandona-se o modelo “Curva ABC + sequenciamento de precedências” como base do cronograma.

Adota-se modelagem de 4 camadas:

Camada	Conteúdo	Exemplo
Hard logic	Precedências obrigatórias por restrição física, técnica ou contratual	3º andar antes do 4º · milestone contratual de entrega de fachada · sequenciamento mandatório de elétrica antes de gesso
Soft logic	Priorização estratégica — o que queremos fazer primeiro. Foco em serviços de alta margem (não maior volume — maior margem). Critérios de medição abrem oportunidades.	Demolição alta margem em paralelo · executar serviços bem medidos antes
Simulação de cenários	Crashing (mais MDO), fast tracking (paralelismo), combinações de alocação de recursos	Adicionar 2ª equipe em frente crítica · paralelizar acabamento entre andares
Contingências e contexto operacional	Clima, tipo de serviço, janela operacional, riscos probabilísticos	Terraplanagem em janeiro (chuva) vs julho · serviços externos em períodos secos

Curva S físico-financeira: ferramenta de otimização de margem, caixa e risco — não apenas de prazo.

Aspecto	AS-IS Costal	TO-BE (alvo Atlas)
Ferramenta atual	Excel — macroitens correlacionados aos itens de custo	Atlas + base histórica (multi-camada)
Granularidade atual	Macro (datas início/fim por bloco)	Multi-camada com simulação
Disclaimer atual	”Macrograma preliminar — cronograma executivo após kickoff”	Mantém — cronograma executivo só pós-kickoff
Curva S	Só se cliente pedir	Atlas gera por padrão (margem + caixa + risco)
Curva ABC	Não construída	Componente de soft logic — derivada
Cronograma executivo	Pendente — depende de pessoal de planejamento (não existe Costal)	Mantido pendente — fora do escopo Atlas inicial

→ Implicação Atlas: capacidade de cronograma é simulação multi-camada, não geração linear. Atlas combina hard logic (do contrato + memorial), soft logic (de margem por serviço — vem do histórico), simulação (parametrizável pelo orçamentista) e contingências (de base climática/operacional).

9a. Validação dual — Scope Match + Análise de Riscos (NOVO Igor 03/05)

Hoje os dois aparecem como checagens informais. Igor exige que virem etapas formais — sem elas, o processo termina só com “preço fechado”, sem governança da proposta.

9a.1 Scope Match

Verifica se o orçamento contempla integralmente o que o cliente requisitou. Cobre:

escopo técnico
memoriais e especificações
exigências contratuais
premissas comerciais relevantes
interfaces e exclusões

Objetivo: evitar tanto gap de escopo quanto falsa sensação de cobertura.

9a.2 Análise de Riscos

Etapa estruturada que explicita:

Tratamento	Pergunta
Assumido	Quais riscos estamos assumindo?
Transferido	Quais riscos estamos transferindo (ao fornecedor, à seguradora, ao cliente)?
Mitigado	Quais riscos estamos mitigando? Como?
Aberto	Quais riscos permanecem abertos e com qual tratamento explícito?

Categorias obrigatórias:

contratuais com cliente
técnicos e executivos
de fornecedores e parceiros
financeiros e de pagamento
securitários
logísticos
estratégicos/comerciais

Análise das propostas além do paramétrico: identificar “pegadinhas” ou desvios consideráveis entre propostas — nem sempre a mais barata é a melhor ou mais completa.

9a.3 Saída esperada da validação dual

“Esses dois blocos fortalecem muito a governança da proposta, porque evitam que o processo termine só com ‘preço fechado’. Ele termina com aderência de escopo validada, riscos identificados e tratados, premissas explícitas, proposta mais defensável técnica e comercialmente.”

→ Implicação Atlas: Scope Match e Análise de Riscos são gates explícitos antes da consolidação da proposta — não selos opcionais.

9b. Saída/Proposta canônica — 3 blocos centrais + VE + savings (NOVO Igor 03/05)

Hoje: consolidação manual da proposta é gargalo real (“muitas revisões para garantir de que não há erros”). Oportunidade declarada por Igor: automatizar ao máximo a consolidação, para que informações críticas sejam importadas e validadas por máquina antes da validação humana.

9b.1 Os 3 blocos centrais que toda proposta precisa explicitar

Bloco	Conteúdo
1. O que está sendo orçado	Escopo técnico · memoriais aderentes · exigências contratuais cobertas · interfaces explicitadas
2. Em quais condições	Premissas comerciais · condições de pagamento · prazos · responsabilidades das partes · faturamento (direto ou não) · garantias
3. O que NÃO está sendo considerado	Exclusões transparentes · itens não considerados · interfaces fora do escopo

9b.2 Adicionalmente

Estudos de VE/reengenharia realizados
Quais sugestões de VE foram embutidas no preço final e quais não foram
Savings projetados (acionamento formal: alteração ±0,5% da margem projetada)
Riscos e condicionantes (saída da §9a.2)
Proposta/apresentação pronta para cliente

9b.3 Princípio (analogia seguradora)

“Tudo aquilo que não estiver claramente descrito neste contrato, não faz parte dele.”

Se um item, condição ou premissa não está explícita na proposta, está fora do contrato.

→ Implicação Atlas: módulo de consolidação automatizada importa de cada bloco upstream (entrada, take-off, equalização, BDI, cronograma, VE, validação dual) e gera o pacote final em formato cliente. Validação humana opera sobre saída revisada por máquina.

10. Proposta arquitetural: Atlas + Data Lake + Sienge — revisada pós-discovery

10.1 Princípios mantidos do prep

Atlas é o agente de orçamentação, não substitui o humano
Atlas escreve no Sienge a linha de base final após vitória
Atlas lê histórico do Data Lake — preços realizados, performance de fornecedor, padrões da empresa
Cada iteração e ajuste humano é registrado para rastreabilidade

10.2 Capacidades validadas com Leandro

Capacidade	Validação	Comentário
Disparo automático de e-mails padrão por categoria	✅	“300 e-mails por orçamento — agente faz isso fácil”
Cobrança automática (e-mail/WhatsApp) com follow-up	✅	“também tem demanda de cobrar fornecedor”
Recepção e organização de propostas em pasta canônica	✅	Estrutura cliente × categoria × fornecedor já existe
Validação paramétrica (custo/m²)	✅ (já existe no Excel)	Agente formaliza/automatiza
Sugestão de CPUs	⚠	Iniciativa privada não orça por SINAPI; Atlas precisa de histórico empresa + benchmark de mercado
Equalização semântica	⚠ COMPLEXO	Quando fornecedor não respeita formato, exige modelagem semântica + códigos por marca (Deca AP51)
Identificação de produto por código	❓	Depende de qualidade do texto do fornecedor
Take-off automático de CAD/BIM	❓	Não testado em profundidade; depende de qualidade do projeto recebido
Aprendizado paramétrico cross-obra	❓	Costal greenfield — base se forma obra a obra

10.3 Decisão pendente: Atlas único × Atlas + agente de fornecedor (DP-1)

A complexidade da equalização sugere reflexão sobre escopo do Atlas. Pedro registrou em 28/04 que esta decisão de projeto será tomada depois.

Opção	Descrição
A	Atlas único — engloba ingestão, levantamento, CPUs, fornecedores, equalização, BDI, cronograma. Risco: módulo de fornecedor fica raso ou monolítico.
B	Atlas + agente dedicado a fornecedores (codinome a definir) — Atlas faz orçamento; agente irmão faz contato + equalização + benchmark + relacionamento. Atlas consome o output do agente irmão.
C	Atlas + módulo “fornecedor” — separação lógica dentro do Atlas mas mesmo agente físico.

Quando decidir: após segunda rodada com Leandro (eventual deep-dive em equalização) e mapeamento da estrutura de pastas Colliers (Rafael × Michael).

10.4 Limites do escopo Atlas (validados)

Atlas termina no kickoff de obra — após vitória, modo “obra ativa” entra com pessoal de obra/planejamento
Aditivos pós-obra NÃO passam por Leandro — engenheiro de obra avalia direto com fornecedor; Leandro só planilha. Igor reforça: Change Orders ficam fora de Orçamentação como dono primário — fluxo adjacente sob gerente de contrato (§14, DP-3)
Cronograma executivo + curva S definitiva dependem de pessoal de planejamento Costal — fora do escopo Atlas inicial
Validação contábil de BDI (com Conecta) é responsabilidade do financeiro, não do agente

10.5 Acoplamento estrutural Orçamentos × Suprimentos × Obras (NOVO Igor 03/05)

Não é integração técnica — é condição organizacional para Atlas evoluir.

“A Costal precisa sair de um orçamento baseado apenas em benchmark e passar para um orçamento calibrado pela sua capacidade real de entrega.”

O ciclo canônico de aprendizado operacional:

orçamento estima
  → suprimentos confirma custo real
    → obras confirma produtividade real
      → lake consolida aprendizado
        → Atlas recalibra próximo orçamento

Suprimentos → Orçamentos (obrigatório):

valores fechados com fornecedores orçados
taxa de saving (orçado − fechado)
comportamento de fornecedores (lead times reais, condições comerciais, logística)
avaliação de fornecedores (qualidade × preço × prazo)

Obras → Orçamentos (obrigatório):

avaliação de fornecedores no campo
índices de produtividade reais
índices de perdas
índices de consumo
desvios de execução com causa-raiz

Cadência mínima (DP-4 pendente): parceria constante com conversa semanal ou mensal nas reuniões de liderança. Mecanismo formal de registro/padronização do aprendizado a definir (G-046).

Por que não é detalhe de integração:

Pré-requisito do Atlas é estrutural, não só técnico
Sem esse loop, Atlas vira referência de mercado externa — não inteligência operacional própria da Costal
A discovery de Suprimentos e a discovery de Obras passam a ser dependências do TO-BE de Orçamentação, não temas paralelos

→ Promove a: D-031 (Suprimentos discovery — feeds obrigatórios) · D-032 (Obras discovery — feeds obrigatórios) · DP-4 (cadência operacional formal).

10.6 Modelo de capacidade orçamentária (NOVO Igor 05/05)

Refutação ampliada de H10 (“equipe típica = 5 engenheiros + 3 técnicos segurança”):

Estado atual: 2 orçamentistas cobrindo o pacote inteiro
Reforço inicial planejado: 1 orçamentista MEP (instalações mecânicas, elétricas, hidráulicas)
Driver de dimensionamento: Meta de faturamento anual / Taxa de conversão = Volume total a ser orçado. Capacidade homem+máquina escala proporcionalmente.

Modelo bidimensional de complexidade:

Eixo	Variantes
Tipologia da obra	Logístico · Industrial · Infraestrutura · Saúde · Interiores Corporativos · Data Centers · etc.
Condição greenfield/retrofit	Greenfield · Retrofit ambiente desocupado · Retrofit ambiente ocupado
Disponibilidade de projeto	Com projetos · sem projetos
Disponibilidade de as built	Com as built · sem as built

Indicadores requeridos: HH por orçamento por combinação de eixos (galpão logístico greenfield com projetos × hospital retrofit ocupado sem as built — esforço fundamentalmente diferente).

→ Promove a: §15 (telemetria) — KPI matricial · DEFINICOES.md (taxonomia oficial) · spec §1 (contexto Costal).

10.7 Codinome “Relay” para o agente irmão (DP-1 sinalizando Opção B)

Igor 05/05 propôs codinome: “#Relay, o estagiário do Atlas (acho que esse é o agente pai)“.

Articulação do problema-alvo:

“Para termos um alto grau de eficiência, teremos que disponibilizar para os nossos parceiros e fornecedores-chave, algum tipo de recurso (agente) que também os ajude com este processo, pois a nossa dificuldade é exatamente a dificuldade deles com os seus respectivos fornecedores, valores, históricos, etc.”

Sinais que reforçam Opção B do DP-1:

Igor articula o problema-alvo do Relay com clareza (não só o que é, mas para que serve)
O agente seria transversal — atende fornecedores-chave Costal, Compras Costal independente da Colliers, potencialmente CREMS Property/Facilities
Hierarquia explícita — Atlas é o “agente pai”, Relay é o “estagiário” (subordinado)

Recomendação: acelerar fechamento de DP-1 — Opção B parece ter ganhado consenso do MD operacional.

→ Promove a: DP-1 (atualização forte para Opção B), atlas.md (header), nova task T-130.

10.8 Industrialização da dor D1 (Levantamento manual)

Igor 05/05 sobre dor D1 (2-3 dias intensivos por orçamento):

“Temos que entender processualmente: quem faz o levantamento? quem orça? quem fala com os parceiros e fornecedores? quem monta o orçamento? Pode ser que aqui encontramos a solução, deixando de ser um processo artesanal para tornar-se um processo mais industrializado, especializado… Ao meu ver, muito mais fácil de automatizar etapa a etapa.”

Implicação arquitetural: Atlas não é “um agente que faz o orçamento”. É uma esteira industrializada com:

Etapas especializadas — cada uma com input/output bem definidos
Inputs estruturados — entrada padronizada por etapa, nada de “arquivo solto”
Handoffs rastreáveis — quem entrega o quê, quando, com qual qualidade
Automação por microprocesso — cada etapa é um candidato independente a automação

Convite implícito: desmontar o “orçamentista” como unidade indivisível e separar por papel/atividade. Pode revelar que a unidade de automação é a etapa, não o orçamento.

→ Promove a: §3 (fluxo) e §10 (arquitetura Atlas) — modelagem por esteira; G-051 (mapear processualmente quem faz o quê).

10.9 Take-off CAD/BIM como análise híbrida (NOVO Igor 05/05)

Definição da capacidade que estava com ❓ na §10.2:

“Arquivos 2D não carregam consigo as propriedades do projeto em si… Já a modelagem 3D, teoricamente, possui propriedades… Mas isso nem sempre é uma verdade. Além disso, temos os problemas dos clashs (interferências de projetos), que podem impactar em termos de quantitativo, além de problemas de projetos. O orçamentista vai identificar tudo isso? Com absoluta certeza não, mas entendo que deve ser uma análise híbrida de homem + máquina, para termos um cruzamento e validação dos dados. Talvez até estudar uma etapa predecessora onde um projetista analise os projetos previamente e informe o orçamentista e o sistema o que pode e o que não pode ser considerado.”

Modelo-alvo:

Camada	Quem
Etapa predecessora (opcional)	Projetista revisa projeto, identifica clashs, marca o que é considerável e o que não é
Take-off automatizado	Atlas extrai quantitativos do CAD/BIM
Validação humana	Orçamentista cruza, valida, ajusta

Princípio: automação cega de CAD/BIM gera dados ruins; cruzamento humano + máquina gera dados confiáveis. A etapa predecessora não é obrigatória, mas reduz ruído quando o projeto recebido tem qualidade duvidosa.

→ Promove a: §10.2 (refinar status da capacidade), G-048 (etapa predecessora — definir quando é ativada).

10.10 Rastreabilidade obrigatória de inputs, diálogos e premissas (NOVO Igor 05/05)

Igor 05/05:

“Um ponto muito importante aqui é o registro e rastreamento das informações de inputs para a orçamentação, bem como o tracking de todos os diálogos e premissas adotadas no orçamento. Garantindo rastreabilidade e que as premissas adotadas ou sejam sanadas as dúvidas durante as etapas de perguntas & respostas com os clientes (se existir) ou simplesmente serem incorporadas à proposta técnica-comercial, de tal maneira que fiquemos resguardados por eventuais interpretações tendenciosas a favor da outra parte (aposta aos interesses da Costal), seja esta parte o cliente ou o fornecedor.”

Capacidade nativa do Atlas — Rastreabilidade Total:

Inputs — todo arquivo recebido, com data/hora, fonte, autor
Diálogos — cada Q&A com cliente, com fornecedor, internamente
Premissas — cada decisão “vamos assumir X” registrada com quem decidiu, quando, com base em quê
Trilha decisória — todo ajuste humano sobre output do agente registrado
Auditoria contratual — em caso de litígio, possível reconstruir o porquê de cada cifra

Função protetiva: se cliente ou fornecedor tentar interpretar tendenciosamente algo após assinatura, a Costal tem trilha completa do que foi acordado/assumido.

→ Promove a: Atlas (capacidade nativa Rastreabilidade), §10.2 (capacidades), nova subseção do spec sobre arquitetura de auditoria.

11. Hipóteses do prep — validação consolidada

#	Hipótese do prep	Resultado
H1	Take-off é o maior gargalo	Validado — 2 dias para escritório, 3 para galpão
H2	Fragmentação em Excel sem template firme	Validado
H3	Equalização subjetiva por escopos diferentes	Validado e ampliado — meio-dia para 1 proposta de luminária/mobiliário
H4	Validação paramétrica manual ou inexistente	Refutado parcial — já existe no Excel
H5	Change orders sub-orçados	Não testado — aditivos pós-obra vão direto a engenheiro de obra
H6	Rastreabilidade fraca	Validado — pasta por cliente é estruturada; iterações dentro do Excel sem versionamento
H7	Dados históricos dispersos	Validado parcial — pasta por cliente é estruturada; zero histórico Costal (greenfield)
H8	Conversão de formatos por cliente	Validado
H9	”99% do tempo em levantamento” (Igor)	Refutado — 3 gargalos co-iguais: levantamento, equalização, disparo a fornecedor
H10	Equipe típica = 5 engenheiros + 3 técnicos segurança	Refutado — Costal tem 2 orçamentistas, fazem o pacote inteiro
H11	SINAPI/TCPO usado	Refutado — referência distante apenas
H12	Sienge não é ferramenta de orçação	Validado

12. Dores AS-IS identificadas

#	Dor	Severidade	Detalhe
D1	Levantamento manual	Crítica	2-3 dias intensivos por orçamento; sempre interrompido por WhatsApp interno/externo
D2	Equalização de fornecedor (luminária, mobiliário)	Crítica	Meio-dia por proposta quando fornecedor decompõe por componente
D3	Disparo + cobrança a fornecedor	Alta	~300 e-mails por orçamento + dia inteiro de cobrança WhatsApp/telefone
D4	Conversão para formato do cliente RFP	Alta	Linha-a-linha; somar/abrir itens; balancing de R $1.000 e m R$ 5M via “atingir meta”
D5	Múltiplos orçamentos em paralelo + interrupções	Alta	”Tô na reunião e o WhatsApp tá buscando 10 vezes”
D6	Zero histórico Costal	Média	Greenfield — paramétrico depende de mercado externo + acumulação obra a obra
D7	Planilha-padrão não-existente	Média	2 orçamentistas com planilhas distintas; aguardando Sienge + IA
D8	Cronograma executivo em standby	Média	Pessoal de planejamento ainda não existe na Costal
D9	BDI/impostos em ajuste	Média	Pendente validação contábil Conecta

13. Lacunas conhecidas (a resolver antes do TO-BE)

14. Próximos passos pós-AS-IS

#	Passo	Owner	Prazo
1	Atualizar agente Atlas com inputs/outputs concretos pós-discovery	Antônio + Pedro	esta-semana
2	Pedro envia link da wiki Quartz a Leandro Delecrodio para revisão	Pedro	esta-semana
3	Varredura na rede Colliers — estrutura de dados de propostas históricas	Rafael / Michael	sprint-semana-3
4	Decisão DP-1 — descolar agente de fornecedor do Atlas?	Pedro	sprint-semana-3 ou 4
5	Discovery complementar com Lucas (2º orçamentista)	Antônio / Rafael	sprint-semana-3 ou 4
6	Validar BDI/impostos com Conecta + financeiro Costal	Leandro / Marcos	sprint-semana-3
7	Coleta de planilhas-mestre + propostas Unimed/Sondotécnica/Aliar	Leandro / Antônio	sprint-semana-3
8	Spec TO-BE Orçamentação (com decisão DP-1 + arquitetura proposta)	Pedro / Antônio	2 semanas pós-DP-1
9	Eventual 2ª rodada com Leandro — deep-dive em equalização	Antônio	sprint-semana-4

14. Change Orders — fluxo adjacente, NÃO em Orçamentação (NOVO Igor 03/05)

“Change Orders não devem ficar primariamente em Orçamentos. A tendência mais coerente é ficarem sob gestão do gestor do contrato / operação em campo, com apoio de orçamentos, controles e agentes de validação.”

14.1 Por que sai de Orçamentação

Em campo existe:

maior velocidade de captura da mudança
melhor leitura do contexto real de execução
maior dinamismo para negociar e reagir

Mas isso traz trade-off real:

Ganho: agilidade e aderência à realidade da obra
Risco: despadronização, erro pontual, decisões locais com efeito sistêmico

Princípio: Change Order é oportunidade de upsell, mas também ponto clássico de geração de passivo invisível. O modelo precisa ser rápido, mas não cego.

14.2 Análise mínima obrigatória (sistêmica)

Toda Change Order obrigatoriamente cobre:

alteração de escopo
impacto em preço
impacto em prazo
impacto em suprimentos
impacto contratual
impacto em medições/faturamento
impacto em garantias, seguros e responsabilidades
risco de passivo oculto
risco de desgaste com cliente ou litígio

14.3 Fluxo próprio de Change Order

identificação em campo
  → registro estruturado da solicitação
    → avaliação técnica e de escopo
      → avaliação de custo e prazo
        → avaliação contratual e de risco
          → validação sistêmica
            → negociação/aprovação
              → incorporação formal ao contrato/baseline

14.4 Alçadas e responsáveis (Igor 03/05)

Etapa	Responsável
Captura da mudança	Gerente do contrato (solicitação cliente OU incompatibilidade/gap de projeto)
Análise de impacto (escopo/custo/prazo)	Gerente do contrato + Engenheiro de Planejamento/Custos
Risco contratual	Gerente do contrato + Engenheiro de Planejamento/Custos. Se necessário, envolver Head Construção + Head Orçamentos. Account manager sempre avisado
Aprovação interna	Estrutura de alçadas (a estruturar). Ponto de partida: gerente do contrato
Documento formal ao cliente	Account manager OU gerente do contrato — a definir (G-045)
Limite de autonomia do time de campo	A definir (G-044)
Quando Orçamentos retoma como dono	Demandado pelo gerente do contrato (volume, complexidade, falta de domínio) OU valor individual da CO muito grande → reanálise integral

14.5 Implicação arquitetural

Change Orders não compõem o escopo nominal do Atlas.
Eventualmente comportam um fluxo/agente próprio (a estruturar pós-DP-3).
Atlas pode ser acionado para reanálise quando CO ultrapassa thresholds (alto valor, alto impacto sistêmico).
O fluxo de CO é forte candidato a automação adjacente — captura estruturada em campo, análise de impacto multi-camada, validação por agente de governança.

→ Promove a: DP-3 (modelo-alvo Change Orders), G-044, G-045, T-122.

15. Telemetria e gestão de capacidade da área (NOVO Igor 03/05)

Bloco operacional próprio: o processo precisa gerar visibilidade sobre a capacidade de orçamentação, não só produzir orçamentos.

15.1 Métricas obrigatórias (operacionais)

Métrica	Granularidade	Por que importa
Calendário de orçamentos em andamento	área	Visão de pipeline ativo
Horas empregadas	por orçamento	Custo do orçamento; ROI por oportunidade
Esforço por etapa	por orçamento	Identifica gargalos reais
Correlação com m² orçado	tipologia	Benchmark interno por tipologia
Correlação com valor orçado	tipologia	Calibra esforço × ticket
Correlação com complexidade	pacote técnico	Decisão de aceitar/recusar oportunidades novas
Prazo disponível até envio ao cliente	por orçamento	Feasibility check — temos tempo?

15.2 Decisão comercial habilitada

A telemetria responde, em tempo real:

temos capacidade para assumir mais esse orçamento agora?
conseguiremos entregar com qualidade e competitividade no prazo?
esse tipo de orçamento consome esforço compatível com o retorno esperado?
onde estão os gargalos reais da operação de orçamento?

15.3 KPIs de gestão da área (Igor 18:32 BRT)

Volumes:

volumes orçados (R$, m²)
volumes orçados com parceiros-chave
volumes com fornecedores aleatórios
volumes de Engenharia de Valor

Performance:

desvio do orçamento (realizado − orçado)
lead time de orçamentação
lead time de aprovação
taxa de revisão orçamentária
ROI
custo do orçamento
índice de acuracidade dos orçamentos
previsão de fluxo de caixa

Por orçamento:

R$/m²
margem operacional
margem líquida

Para decisão comercial (aceitar/recusar):

margem operacional
margem líquida
ROI
Black Flag ou conjunto de Red Flags na análise de riscos

→ Implicação Atlas: módulo de telemetria operacional é capacidade nativa, não relatório derivado. Atlas alimenta o dashboard em tempo real à medida que orçamentos avançam.

16. Risco operacional

Concentração de conhecimento em Leandro: se Leandro sai antes da automação cobrir o pacote, Costal fica exposta. Mitigação: documentar o método dele (este spec é o primeiro passo).
Pressão temporal Costal: Ricardo Betancourt está pressionando para migrar orçamento da Colliers para Costal — Anouk não pode demorar. Se atrasar, Costal cria planilha-padrão por conta própria fora do desenho integrado.
Equalização tratada como commodity: se Atlas trata equalização superficialmente, perde a oportunidade de diferencial competitivo onde Leandro mais sente a dor.
Greenfield Costal: sem histórico próprio, modelo paramétrico depende de bases externas + acumulação obra a obra.
Vazamento de quantitativo interno (Igor 03/05): se Atlas envia o take-off Costal aos fornecedores, transfere o risco de levantamento de volta para a Costal. Mitigação: módulo de disparo dispara somente o pacote documental do cliente (R-022).
Atlas calibrado só por benchmark externo: sem feedback de Suprimentos (custo real fechado) e Obras (produtividade real), o modelo paramétrico vira referência de mercado — não inteligência operacional Costal. Mitigação: D-031, D-032 e DP-4 (acoplamento estrutural §10.5).
Change Orders como passivo invisível: se CO for tratada como ajuste pontual em campo sem governança mínima, gera passivo contratual oculto — ponto clássico identificado por Igor. Mitigação: DP-3 e §14.

17. Ver também

04 · transcrição
05 · consolidado bruto
Prep histórico de discovery (substituído por este spec)
Agente Atlas — Orçamentação
Agente Draft — Propostas técnico-comerciais
Leandro Delecrodio · Igor Reginato · Antônio Pavanelli
Guia Sienge
AE Costal
Kickoff operacional 17-04
decisoes.md §pendentes (DP-1, DP-3, DP-4)
riscos.md R-022 · dependencias.md D-030/D-031/D-032 · gaps.md G-044/G-045/G-046/G-047
Governança Corporativa Costal — referência primária para arquitetura. Diretrizes que fundamentam diretamente este spec: DIR-03 (Criação de Valor e Previsibilidade), DIR-04 (Gestão de Riscos), DIR-05 (Gestão de Projetos e Obras), DIR-07 (Seleção de Mercado, Clientes e Projetos), DIR-09 (Disciplina Financeira), DIR-10 (Margem, Rentabilidade e Retorno)

Spec evoluído para v2 por Pedro Villa em 2026-05-04, incorporando a revisão estrutural assíncrona de Igor Reginato em 03/05. AS-IS v1 validado com owner operacional (Leandro 28/04); v2 incorpora homologação MD (Igor) que impõe seis blocos estruturais e reposiciona Change Orders. TO-BE pendente DP-1, DP-3, DP-4 + coleta de artefatos canônicos.

Colliers × Costal — Interno

Explorador

Spec — Orçamentação Costal — AS-IS v2.1