Orçamentação de Obra | Preparação para Discovery

spec orcamentacao discovery costal

Prep para a sessão Antônio × Leandro (jan — a confirmar a data). Três blocos: (1) processo tradicional padrão-mercado para referência, (2) proposta Atlas+Lake+Sienge para discutir, (3) Q&A cirúrgico para a conversa. Este doc será revisado e substituído pelo discovery final após a sessão. Aqui são hipóteses e perguntas estruturadas — não afirmações definitivas.


0. Contexto e objetivo

Leandro Delecródio é Gerente de Orçamentos da Costal/Colliers com mais de R$ 300M em orçamentos em andamento (alinhamento 20-04). O processo é inteiramente em Excel, sem metodologia padronizada. Orçamentação é apontada por Igor como “a maior dor estratégica da empresa” (kickoff 17-04).

Objetivo desta discovery: mapear o processo atual com precisão suficiente para:

  1. Desenhar o agente Atlas com inputs/outputs concretos (Atlas)
  2. Decidir o que vai para o Sienge e o que fica em camadas especializadas
  3. Entender a estrutura de dados históricos disponível para treinar modelos paramétricos
  4. Validar o princípio de Igor: “orçar em Excel durante o comercial, carregar linha de base final no Sienge”

Premissas de entrada (da Costal, já registradas):

  • [fato] Dois orçamentistas com métodos distintos — isto é gap e uma oportunidade de padronização
  • [fato] Sienge não é a ferramenta de orçação — só controle de budget pós-fechamento
  • [fato] R$ 300M+ em pipeline de orçamentos ativos
  • [hipótese Igor, kickoff] 99% do tempo do orçamentista é gasto em levantamento e mapeamento de requisitos, não em custos unitários
  • [hipótese Igor] Equipe típica para orçamento grande: 5 engenheiros + 3 técnicos de segurança
  • [hipótese Igor] Validação paramétrica contra histórico identifica erros reais hoje feitos manualmente

1. Cadeia de valor do orçamento de obra (alto nível)

flowchart LR
    A[Projeto recebido<br/>cliente/RFP] --> B[Leitura e<br/>compreensão]
    B --> C[Levantamento de<br/>quantitativos]
    C --> D[Composição de<br/>preços unitários]
    D --> E[Equalização de<br/>propostas fornecedores]
    E --> F[BDI e encargos<br/>sociais]
    F --> G[Cronograma físico<br/>e financeiro]
    G --> H[Validação<br/>paramétrica]
    H --> I[Aprovação<br/>comercial]
    I --> J[Proposta ao<br/>cliente]
    J -->|se vencer| K[Linha de base<br/>no ERP Sienge]
    K --> L[Controle de<br/>execução]

Essa é a cadeia ideal. Na prática, cada construtora tem variações — o objetivo da discovery é mapear a variação específica do Leandro.


2. Processo tradicional (referência — como é feito no mercado)

2.1 Fluxo detalhado

flowchart TB
    subgraph ENTRADA["Entrada"]
        RFP[RFP / Edital /<br/>Projeto executivo]
        CAD[Plantas<br/>CAD/BIM]
        MEM[Memorial<br/>descritivo]
        CADPROJ[Caderno<br/>de encargos]
    end

    subgraph LEVANT["Levantamento"]
        LQ[Take-off<br/>quantitativos]
        BIM[Extração<br/>BIM/CAD]
        MAN[Medição<br/>manual]
        LQ --> BIM
        LQ --> MAN
    end

    subgraph COMP["Composição de preços"]
        CPU[CPU<br/>Composição de<br/>Preço Unitário]
        REF[Referências<br/>SINAPI · TCPO · CUB<br/>Histórico empresa]
        COT[Cotações<br/>fornecedor]
        CPU --> REF
        CPU --> COT
    end

    subgraph EQUAL["Equalização"]
        E3[Mínimo<br/>3 cotações]
        NORM[Normalização<br/>de escopo]
        ESC[Escolha<br/>vencedor]
        E3 --> NORM
        NORM --> ESC
    end

    subgraph INDIR["Indiretos + BDI"]
        ENC[Encargos<br/>sociais]
        BDI[BDI<br/>administração · lucro<br/>impostos · risco]
        MOB[Mobilização<br/>e canteiro]
    end

    subgraph CRON["Cronograma"]
        CURVAS[Curva ABC<br/>insumos]
        CURVAB[Curva S<br/>físico-financeira]
        PREC[Sequenciamento<br/>precedências]
        CURVAS --> CURVAB
        PREC --> CURVAB
    end

    subgraph VALIDA["Validação"]
        PARAM[Análise<br/>paramétrica<br/>vs histórico]
        REV[Revisão<br/>pares]
        APROV[Aprovação<br/>gerente → diretor]
        PARAM --> REV
        REV --> APROV
    end

    subgraph SAIDA["Saída"]
        PROPSPA[Proposta<br/>comercial]
        LB[Linha de base<br/>Sienge pós-vitória]
    end

    ENTRADA --> LEVANT
    LEVANT --> COMP
    COMP --> EQUAL
    EQUAL --> INDIR
    INDIR --> CRON
    CRON --> VALIDA
    VALIDA --> SAIDA

    style ENTRADA fill:#f0f0f0
    style SAIDA fill:#e8f5e8

2.2 Etapas com detalhe de como é feito em construtora padrão

#EtapaFerramentas típicasAtividade humanaDuração típica
1Recepção do projetoE-mail, SharePoint, Google DriveGerente de orçamentos recebe edital, distribui aos engenheiros, organiza pastashoras
2Leitura do projetoPDF Readers, CAD viewer, BIM viewerEngenheiro lê memorial, caderno de encargos; identifica escopo, premissas, restriçõesdias
3Take-off (levantamento)CAD manual, Revit/Navisworks (BIM), ExcelQuantificar m², m³, kg, unidades por serviço. Se tem BIM, extração é mais rápida; se não, manualsemanas — maior gargalo
4Composição de preços unitários (CPU)Excel + SINAPI/TCPO/CUB + histórico internoPara cada serviço, compor custo: material + mão-de-obra + equipamento + encargosdias
5Cotação com fornecedoresE-mail, WhatsApp, ExcelSolicitar 3+ cotações por item relevante; acompanhar retornosemana(s)
6Equalização de propostasExcelNormalizar propostas em escopo comum (nem sempre cotam a mesma coisa); escolher vencedordias
7BDI e encargos sociaisExcel (planilha própria)Calcular admin, lucro, risco, impostos; aplicar encargos sobre mão-de-obrahoras
8Cronograma físico-financeiroMS Project ou Primavera; Excel para Curva SSequenciar, calcular curva ABC de insumos, curva Sdias
9Validação paramétricaExcel + histórico internoComparar custo/m², % indiretos, desvio de composições vs obras similareshoras — quando é feita
10Revisão e aprovaçãoReunião + planilhaGerente de orçamentos revisa com gerente de construção; alçada final variadias
11Consolidação propostaExcel + Word/PDFGerar proposta executiva do cliente1-2 dias
12Upload ao ERP (se vitória)Sienge comercial/engenhariaSó a linha de base final carregada no ERP para controlehoras

2.3 Pontos de dor típicos (hipóteses a validar com Leandro)

Baseado em kickoff Igor + padrão de mercado:

DorDescriçãoEvidência
Take-off demoradoQuantitativos manuais consomem semanas”99% do tempo em levantamento” — Igor
Fragmentação em ExcelCada orçamento é uma planilha própria; sem template firme”dois orçamentistas com métodos distintos”
Equalização subjetivaComparar propostas com escopos diferentes exige normalização manualKickoff: “3 cotações para ar-condicionado” exemplo
Paramétrico manual ou inexistenteValidação contra histórico raramente sistemáticaIgor: “já identifiquei erros reais ao cruzar com histórico”
Change orders sub-orçadosCustos indiretos de alterações de escopo não capturadosNubank R$ 30M com 200+ change orders
Rastreabilidade fracaNão se sabe “quem decidiu o quê” no orçamento final
Fechamento com 80+ hipótesesMuita decisão implícita que depois vira discussão contratual
Dados históricos dispersosCada obra em planilha separada; sem base única para análise paramétrica
Retrabalho entre comercial e engenhariaComercial altera premissas; orçamento tem que refazer
Conversão de formatosCada cliente quer padrão diferente — retrabalhoIgor: “a grande dor dos orçamentistas”

2.4 Papéis envolvidos (tipicamente)

PapelResponsabilidade
Gerente de orçamentos (Leandro)Distribui, coordena, revisa, aprova
Engenheiro orçamentista (2+)Take-off, CPUs, equalização
Técnico de segurançaEstimativa de EPI, encargos de SST
Comprador / suprimentosCotação com fornecedores
PlanejadorCronograma, curva S
Gerente de construçãoRevisão técnica, plausibilidade operacional
Diretor / sócioAprovação final (acima de threshold)

3. Proposta: Atlas + Data Lake + Sienge

3.1 Princípio arquitetural

O processo tradicional é linear e baseado em planilhas soltas. A proposta Atlas é iterativa, baseada em dados e integrada ao Sienge no final.

  • Formação do orçamento → Excel + Atlas (IA paramétrica + histórico)
  • Formalização → linha de base no Sienge (mantém governança financeira, suprimentos, contratos)
  • Governança → Data Lake captura cada iteração, cada decisão, cada alteração → rastreabilidade total

Alinhado com a nota Blaschek (Arquitetura CRM+IA) §3.2: “Formação da receita → CRM; Formalização e execução → ERP”. Aplicado à orçamentação: “Formação do custo → Atlas; Formalização → Sienge”.

3.2 Arquitetura proposta

flowchart TB
    subgraph INPUT["Entrada de dados"]
        PROJ[Projeto<br/>CAD/BIM]
        MEM[Memorial]
        CLIENTE[Requisitos<br/>cliente]
    end

    subgraph ATLAS["Atlas — Agente de Orçamentação"]
        READ[Leitura<br/>semântica<br/>memorial + caderno]
        TAKE[Assistência<br/>take-off<br/>CAD/BIM parse]
        PARAM[Análise<br/>paramétrica<br/>vs histórico]
        CPU_IA[CPUs<br/>auto-sugeridas<br/>SINAPI + histórico]
        EQUAL_IA[Equalização<br/>cotações<br/>normaliza escopo]
        BDI_IA[BDI<br/>ajustado<br/>contexto obra]
        CRON_IA[Cronograma<br/>sugerido<br/>padrões empresa]
        ALERT[Alertas<br/>de risco<br/>desvio &gt; X%]
        READ --> TAKE
        TAKE --> CPU_IA
        CPU_IA --> EQUAL_IA
        EQUAL_IA --> BDI_IA
        BDI_IA --> CRON_IA
        PARAM -.-|cross-check| CPU_IA
        PARAM -.-|cross-check| BDI_IA
        ALERT -.-> PARAM
    end

    subgraph HUMAN["Humano no loop"]
        LEANDRO[Leandro:<br/>revisa, ajusta,<br/>aprova]
        ENG[Engenheiros:<br/>validação técnica]
    end

    subgraph LAKE["Data Lake Costal"]
        HIST[Base de orçamentos<br/>históricos]
        PRECOS[Preços unitários<br/>realizados]
        FORN[Perfil de<br/>fornecedores]
        MET[Métricas paramétricas<br/>por tipologia]
        HIST --> MET
        PRECOS --> MET
        FORN --> MET
    end

    subgraph SIENGE["Sienge"]
        LB[Linha de base<br/>ENG + Comercial]
        SUP_SC[Solicitações<br/>de compra]
        FIN_CP[Controle<br/>financeiro]
        CONT[Contratos<br/>terceiros]
    end

    subgraph OUTPUT["Saídas"]
        PROP[Proposta<br/>ao cliente]
        DASH[Dashboard<br/>tempo-real<br/>obra]
    end

    INPUT --> ATLAS
    LAKE -.->|contexto| ATLAS
    ATLAS --> HUMAN
    HUMAN -->|decisão| ATLAS
    HUMAN --> PROP
    PROP -->|se vence| LB
    LB --> SUP_SC
    LB --> FIN_CP
    LB --> CONT
    SIENGE -->|execução real| LAKE
    LAKE --> DASH

    style ATLAS fill:#f5f0ff,stroke:#6b4e8d
    style LAKE fill:#e8f5e8,stroke:#2e7d32
    style SIENGE fill:#e8f4f8,stroke:#2e75b6
    style HUMAN fill:#fff4e8,stroke:#c65911

3.3 Capacidades do Atlas (mapeamento por etapa)

Etapa tradicionalCapacidade AtlasGanho esperado
Leitura projetoLeitura semântica do memorial + caderno de encargos; extrai escopo e requisitosReduz leitura de dias para horas
Take-off (gargalo!)Parsing de CAD/BIM quando disponível; checklist assistido para manualReduz semanas para dias
CPUsSugestão baseada em SINAPI + histórico empresa + contexto da obraElimina busca manual; reduz erros de referência
CotaçõesEnvio automatizado, captação por e-mail/WhatsApp, trackingReduz follow-up manual
EqualizaçãoNormalização de escopo via LLM (compara cotações de escopo diferente)Reduz viés de comparação manual
BDICálculo com contexto (risco da obra, prazo, margem esperada)Reduz erros + decisão baseada em dados
CronogramaPadrões de empresa + benchmark históricoReduz tempo de montagem
Validação paramétricaAutomática — compara custo/m², % indiretos, desvios vs históricoDetecta erros que hoje passam (ver Igor: “já identifiquei erros reais”)
RastreabilidadeTodo ajuste humano registrado com quem, quando, por queAuditoria total + reaproveitamento
Change ordersDetecta alteração de escopo → recalcula impacto indiretoCaptura os 80% que são perdidos hoje

3.4 Integração com Sienge (contrato técnico)

  • Atlas escreve no Sienge (via API REST): linha de base final quando orçamento é vencedor
  • Atlas lê do Sienge (via API + Data Lake): preços unitários realizados de obras anteriores, performance de fornecedores, padrões de encargos da empresa
  • Atlas reage a webhooks do Sienge: PURCHASE_ORDER_* → atualiza baseline de preços reais no Lake; SALES_CONTRACT_ISSUED → ativa modo “obra em execução”

Ver detalhes em sienge §5 (mapeamento agente × módulo).

3.5 Ganhos esperados (quantitativos a validar com Leandro)

MétricaHoje (hipótese)Com Atlas (hipótese)Método de medição
Tempo médio de orçamento (obra média)X semanasX/2 a X/3 semanasComparação pre/pós
Margem de erro paramétrico (desvio vs real)?< 5%Cruzamento orçado × realizado (Lake)
% cotações equalizadas proativamente?> 80%Atlas logs
Change orders previstas (capturadas no orçamento inicial)?> 70% dos > R$ 10kMétrica cross-obra
Reuso de CPUs históricasbaixoaltoContagem de sugestões aceitas

3.6 Pré-requisitos (o que Atlas precisa para funcionar bem)

  1. Dados históricos ingeridos no Lake — pelo menos 10-20 orçamentos antigos (mesmo que imperfeitos, o modelo paramétrico precisa base)
  2. Primeiros módulos Sienge em produção — ENG + SUP + FIN precisam estar rodando para fechar o loop de execução → Lake
  3. Acesso API Sienge — confirmado pela Gescon (ver G-009)
  4. Padronização mínima de memorial — Atlas consome memorial estruturado; se memorial é “texto livre sem seções”, leitura semântica fica frágil
  5. Buy-in do Leandro e dos engenheiros — sem envolvimento deles no design, Atlas nasce morto

3.7 Riscos e gaps conhecidos

  • [risco] Base histórica Costal é zero (greenfield) — Atlas vai precisar começar com padrões do mercado (SINAPI, TCPO) até formar base própria
  • [risco] Base histórica Colliers (~500 projetos) pode não estar acessível ou estruturada — R-002
  • [gap] Estrutura de memorial descritivo da Costal ainda não padronizada — dependência para leitura semântica
  • [gap] Integração CAD/BIM assume que projetos chegam nesses formatos — validar com Leandro se é realidade Costal
  • [dependência] D-007 — go-live Onda 1 (Atlas incluído) depende de blueprint + Lake + API Sienge

4. Diferenças-chave tradicional × proposta

DimensãoTradicionalCom Atlas
Onde o orçamento viveDezenas de planilhas Excel isoladasAmbiente único (Atlas) com histórico e Lake integrado
Fonte de custos unitáriosSINAPI + “memória do engenheiro”SINAPI + histórico empresa + benchmark automático
Validação paramétricaManual, raramente feitaAutomática em toda iteração
Rastreabilidade”Quem mudou o quê” se perdeCada ajuste humano registrado
Reuso de CPUsCada orçamento começa quase do zeroPadrões da casa sugeridos automaticamente
EqualizaçãoManual, subjetivaLLM normaliza escopo antes de comparar
Change ordersSó vistos quando acontecemPrevistos no fechamento inicial
Integração com execuçãoQuando muito, upload final ao ERPLoop completo: orçado → executado → aprendizado → próximo orçamento
Onde mora a fonte oficialExcel do orçamentistaSienge (linha de base) + Lake (iterações + histórico)

5. Q&A para a sessão com Leandro

Instrução para Antônio: usar como roteiro. As perguntas estão organizadas por bloco temático. Em cada bloco, começar pelas perguntas abertas e fechar com perguntas pontuais. Anotar respostas no template _templates/discovery-session.mdregistrar fato vs hipótese vs premissa vs gap explicitamente.

5.1 Bloco A — Processo atual (mapeamento)

  1. Como você descreveria, em 3-5 minutos, o processo completo de um orçamento — desde recebimento do projeto até entrega da proposta ao cliente? (pergunta aberta, deixar fluir)
  2. Qual é o tempo médio de fechamento de um orçamento hoje? Depende do porte? (pedir 3 exemplos recentes com prazo)
  3. Qual é a equipe típica envolvida em uma obra de porte médio (ex: R$ 30M)? Quantas pessoas por quanto tempo?
  4. Quais são os 3 artefatos principais que você produz para cada orçamento? (planilha mestre? proposta? memorial de cálculo?)
  5. Tem algum template de planilha padrão ou cada orçamentista faz o seu?
  6. Qual é a sequência típica das etapas? Quais fazem em paralelo, quais dependem umas das outras?

5.2 Bloco B — Ferramentas e dados

  1. Qual é a sua planilha mestre? Pode compartilhar uma anonimizada?
  2. Usam SINAPI, TCPO ou CUB? Qual é a tabela de preço mais consultada?
  3. Têm base histórica de orçamentos anteriores? Está organizada onde? (SharePoint? Drive? Cada um tem a sua?)
  4. Quantos orçamentos “fechados” (vitoriosos + perdidos) estão acessíveis para consulta hoje?
  5. Usam ferramenta de cronograma (MS Project, Primavera, Excel com curva S)?
  6. Têm uso de BIM ou take-off automatizado em algum projeto?
  7. Como é a ferramenta de cotação? E-mail? WhatsApp? Portal? Tem histórico dos fornecedores?

5.3 Bloco C — Pontos de dor

  1. Onde você sente que perde mais tempo no processo? (pedir para ranquear top 3)
  2. Qual é o erro mais comum que você identifica em revisões? (esquecer item do memorial? compor mal? referência errada?)
  3. Já aconteceu orçamento fechado que virou prejuízo? Qual foi a causa raiz identificada?
  4. Quando o cliente pede change order, como se faz a reprecificação? Essa reprecificação é consistente com a lógica do orçamento original?
  5. Vocês fazem validação paramétrica (ex: custo/m² vs obras anteriores)? Como?
  6. Tem caso em que descobriu erro depois ao comparar orçado × realizado? Exemplo concreto?

5.4 Bloco D — Stakeholders e aprovações

  1. Quem decide o quê num orçamento? Qual é a alçada típica (você, gerente de construção, Igor)?
  2. Qual é a cadência de revisões? Tem reunião semanal? O que é discutido?
  3. Como a área comercial interage com o orçamento? Eles alteram premissas? Isso gera retrabalho?
  4. Como a engenharia (gerente de construção) interage? Valida tecnicamente antes?

5.5 Bloco E — Dados históricos (crítico para Atlas)

  1. Dos 300M+ em orçamentos em andamento, quantos já foram concluídos (vitoriosos ou perdidos)?
  2. Tem rastro de orçado × realizado em alguma obra passada? (na Colliers talvez?)
  3. Seus CPUs favoritos estão num arquivo acessível ou são “na cabeça”?
  4. Fornecedores recorrentes têm histórico de cotação rastreável? (precificação anterior, perfil de atendimento)
  5. Você guarda memoriais de cálculo junto com o orçamento, ou só o resultado final?

5.6 Bloco F — Uso do Sienge (pós-orçamento)

  1. Hoje, quando vocês vencem um orçamento, o que exatamente é carregado no Sienge?
  2. Tem dificuldade em reconciliar orçamento (Excel) com estrutura do Sienge (centros de custo, itens de compra)?
  3. O controle de execução (real vs baseline) acontece onde? Sienge? Excel paralelo?
  4. Já sentiu a dor de não ter feedback do real ao orçamento (ex: “na verdade o concreto custou X, não Y que orçamos”)?

5.7 Bloco G — Oportunidades e visão

  1. Se você pudesse eliminar 1 tarefa manual do seu dia a dia, qual seria?
  2. O que um assistente de IA poderia fazer que te liberaria mais tempo?
  3. Você aceitaria receber sugestões automáticas de CPUs? Que nível de confiança teria?
  4. Se tivesse validação paramétrica automática sinalizando “seu orçamento está X% acima do padrão histórico para esta tipologia” — útil? Invasivo?
  5. O que não é para automatizar — qual decisão você sempre quer tomar humanamente?

5.8 Bloco H — Restrições e linhas vermelhas

  1. Tem clientes específicos (Nubank, outros) com requisitos de formato/padrão que são rígidos?
  2. Tem informação confidencial em orçamentos que não pode circular em sistemas externos (exceto o Sienge)?
  3. Tem algum processo de auditoria interna que o orçamento precisa passar?
  4. Qual é o pior cenário que você imagina se “automatizarmos errado”?

5.9 Bloco I — Agenda pós-discovery

  1. Disponibilidade para uma 2ª rodada caso precisemos aprofundar?
  2. Quem mais eu deveria conversar? (engenheiros orçamentistas, comprador, planejador)
  3. Pode compartilhar 1 orçamento fechado completo (anonimizado) como baseline?
  4. Tem alguém externo (consultor, outra construtora) que você admira o processo? (benchmark)

6. Follow-up e próximos passos

Após a sessão com Leandro:

  1. Antônio — preencher 02-costal/specs/discovery-orcamentacao.md (doc final) com achados, atualizando este prep como histórico
  2. Antônio — promover sinais para camadas canônicas (runbook)
  3. Gabriel + Antônio — atualizar o agente Atlas com inputs/outputs concretos e fontes de dados
  4. Pedro — decidir se a proposta Atlas entra no brief Q2 do board (hoje rascunho — pode virar case de referência)
  5. Rafael — agendar 2ª rodada com Leandro + conversas com engenheiros orçamentistas e comprador (se confirmado na sessão)

7. Ver também


Documento preparado por Pedro Villa + Axios em 2026-04-23. Revisão e execução por Antônio Pavanelli. Após a sessão com Leandro, virar discovery-orcamentacao.md com achados reais.