Sienge | Guia de Arquitetura

arquitetura sienge dados governanca

Guia de arquitetura do ERP Sienge para uso do time Anouk no projeto Colliers × Costal. Consolida: (1) conhecimento específico da implantação Costal, (2) documentação pública da plataforma, (3) nota técnica arquitetural do Blaschek sobre CRM × ERP, (4) mapeamento de como os 26 agentes Costal se conectam. Não substitui documentação oficial — serve como ponto único de entrada para o time. Trilogia conceitual Blaschek (27/04) — leitura paralela: Visão Integrada do ERP (módulos + entidades + ecossistema TO-BE) · Catálogo de Sistemas (todos os sistemas da construtora, não só Sienge) · Matriz Sistema × Processo × Dados (governança e linhagem do dado).

1. O que é o Sienge

Sienge é o ERP especializado em construção civil e incorporação, desenvolvido pela Softplan desde 1990. Cobre a cadeia completa de uma construtora: do orçamento e compras ao controle de obra, vendas, contratos, financeiro e contabilidade. Opera 100% via web, com acesso por desktop e mobile.

No projeto Colliers × Costal, o Sienge é:

[decisão] ERP transacional único da Costal (confirmado em 2026-01-28) — tudo que o Sienge não cobrir será construído ao redor dele, nunca em paralelo (decisoes)
[premissa] Em implantação desde 2026-04-08 Projeto de implantação postergado por 2 semanas, com tarefas em atraso (informação Igor), condução direta pela Costal com parceiro Gescon. Proposta para liderança técnica de Marcos Eduardo, em análise pelo Board. Decisão prevista para 2026-04-27 (sienge-sistema)
[premissa] Sistema padrão, sem customização de código — apenas configuração de parâmetros dentro do menu nativo
[premissa] Multi-tenant via subdomínio — cada tenant é isolado lógico (ver §4.3)

Posicionamento no stack: Sienge é sistema de registro e execução (termo do Blaschek); a formação de receita (CRM, leads, propostas) vive em sistemas especializados que conversam com o Sienge por APIs e eventos — não é função dele. Ver nota técnica Blaschek §3.2.

2. Módulos — arquitetura funcional

O Sienge é composto por 10 módulos integrados. Abaixo a visão funcional e as relações principais.

graph TB
    subgraph CORE["Núcleo transacional"]
        ENG[Engenharia<br/>Orçamento · Cronograma<br/>Diário de obra · Custos]
        SUP[Suprimentos<br/>Compras · Estoque<br/>Contratos · Medições]
        FIN[Financeiro<br/>Contas Pagar · Receber<br/>Caixa · Bancos]
        CONT[Contabilidade<br/>e Fiscal<br/>NFe · SPED]
    end

    subgraph COM["Comercial e pós-venda"]
        COMM[Comercial<br/>Prospects · Contratos<br/>Unidades · Comissão]
        PORT[Portais<br/>Cliente · Corretor<br/>Fornecedor]
    end

    subgraph SUPPORT["Apoio e governança"]
        CAD[Cadastros / Apoio<br/>Pessoas · Produtos<br/>Centros de custo]
        SEG[Segurança<br/>Usuários · Permissões<br/>Alçadas]
        QUAL[Gestão<br/>de Qualidade]
        ATIV[Gestão<br/>de Ativos]
    end

    subgraph BI["Analítico"]
        SUPD[Suporte à Decisão<br/>Gerenciais · Dashboards]
    end

    ENG -->|orçamento| SUP
    SUP -->|ordem de pagamento| FIN
    COMM -->|contratos de venda| FIN
    FIN -->|lançamentos| CONT
    SEG -.-|perfis| ENG
    SEG -.-|perfis| SUP
    SEG -.-|perfis| FIN
    SEG -.-|perfis| COMM
    CAD -.-|cadastros base| ENG
    CAD -.-|cadastros base| SUP
    CAD -.-|cadastros base| COMM
    ENG --> SUPD
    SUP --> SUPD
    FIN --> SUPD
    COMM --> SUPD
    PORT -.-|self-service| COMM
    PORT -.-|self-service| SUP
    QUAL -.-|checklists| ENG
    ATIV -.-|equipamentos| ENG

    style CORE fill:#e8f4f8,stroke:#2e75b6
    style COM fill:#fff4e8,stroke:#c65911
    style SUPPORT fill:#f0f0f0,stroke:#595959
    style BI fill:#e8f5e8,stroke:#2e7d32

Módulos em uma linha (contextualizados para Costal)

Módulo	O que faz	Status Costal
Engenharia (ENG)	Orçamento, cronograma, diário de obra, apropriação	✅ Em implantação — custos unitários, E-custos, importações
Suprimentos (SUP)	Compras, estoque, contratos de terceiros, medições	✅ Em implantação — compras, contratos/medições terceiros e receitas
Financeiro (FIN)	Contas a pagar/receber, caixa, bancos, fluxo de caixa	✅ Em implantação — Contas a Pagar I, Contas a Receber I, Caixa e Bancos
Comercial	Prospects, propostas, contratos de venda, unidades, comissão	⏸️ Parcial — Costal usa Excel para orçamentação comercial; só a linha de base final entra no Sienge
Contabilidade e Fiscal	Lançamentos contábeis, NFe entrada, SPED	✅ Em implantação — Conecta Contabilidade + NFe produto recepção
Suporte à Decisão (GER)	Dashboards e relatórios gerenciais	✅ Em implantação — GER Financeiro e GER Suprimentos
Portais	Autoatendimento para cliente, corretor, fornecedor	❌ Não previsto no primeiro ciclo
Cadastros / Apoio (CAD)	Cadastros base (pessoas, produtos, centros de custo)	✅ Em implantação (pré-requisito para outros módulos)
Segurança (SEG)	Usuários, permissões, alçadas (até 5 níveis)	✅ Em implantação — Costal precisa de 3 níveis de alçada
Gestão de Qualidade	Checklists, não-conformidades, auditorias	❌ Fora do escopo inicial
Gestão de Ativos	Controle de equipamentos e frota	❌ Fora do escopo inicial

Fora do Sienge (por decisão Costal): orçamento comercial (Excel), folha de pagamento (Paycom — parceiro terceiro), prospecção (Sales Impact), marketing (agência), jurídico (escritório externo). Ver sienge-sistema §Fora do escopo.

3. Fluxo de dados — cadeia de valor

O Sienge integra módulos numa cadeia orçamento → execução → realização → contabilização. Entender esse fluxo é pré-requisito para qualquer integração ou modelagem no Data Lake.

flowchart LR
    START([Obra ou empreendimento])

    subgraph ENG_FLOW["ENG — Planejamento técnico"]
        ORC[Orçamento<br/>Excel da Costal]
        LB[Linha de base<br/>no Sienge]
        CRON[Cronograma<br/>físico-financeiro]
        ORC -->|upload manual| LB
        LB --> CRON
    end

    subgraph SUP_FLOW["SUP — Execução de compras"]
        SC[Solicitação<br/>de compra]
        PC[Pedido<br/>de compra]
        CONT_SUP[Contrato com<br/>terceiro]
        MED[Medição]
        NF[NFe entrada<br/>recepção]
        SC --> PC
        PC --> NF
        CONT_SUP --> MED
    end

    subgraph FIN_FLOW["FIN — Realização financeira"]
        CP[Contas a<br/>Pagar]
        CR[Contas a<br/>Receber]
        CXB[Caixa e<br/>Bancos]
        CP --> CXB
        CR --> CXB
    end

    subgraph COMM_FLOW["Comercial — Receita"]
        PROSP[Prospect]
        PROP[Proposta]
        CONT_VENDA[Contrato<br/>de venda]
        PROSP --> PROP
        PROP --> CONT_VENDA
    end

    subgraph FISCAL["Contabilidade / Fiscal"]
        LANC[Lançamentos<br/>contábeis]
        SPED[SPED fiscal<br/>e contábil]
        LANC --> SPED
    end

    subgraph ANALYTICS["GER + Data Lake"]
        GER[Suporte à Decisão<br/>Gerenciais nativos]
        LAKE[(Data Lake<br/>Databricks)]
    end

    START --> ORC
    CRON --> SC
    NF --> CP
    MED --> CP
    CONT_VENDA --> CR
    CP --> LANC
    CR --> LANC
    CXB --> LANC
    GER -.-|extração| LAKE
    CP -.-|API / webhook| LAKE
    CR -.-|API / webhook| LAKE
    CONT_VENDA -.-|API / webhook| LAKE
    MED -.-|API / webhook| LAKE
    NF -.-|API / webhook| LAKE

    style ENG_FLOW fill:#e8f4f8
    style SUP_FLOW fill:#fff4e8
    style FIN_FLOW fill:#fef0f0
    style COMM_FLOW fill:#f5f0ff
    style FISCAL fill:#f0f8e8
    style ANALYTICS fill:#fafafa,stroke-dasharray: 5 5

Pontos-chave do fluxo

[fato] Pedido de compra em SUP gera automaticamente lançamento em FIN/Contas a Pagar — integração nativa.
[fato] Contrato de venda em Comercial gera automaticamente título em FIN/Contas a Receber.
[premissa] Orçamento comercial da Costal nasce em Excel e a linha de base final é carregada manualmente no Sienge — por decisão deliberada, Sienge não é a ferramenta de orçação (sienge-sistema).
[fato] Medições de contratos de terceiros alimentam Contas a Pagar; medições de contratos de receita alimentam Contas a Receber.
[fato] Todos os módulos transacionais alimentam Contabilidade e Fiscal, que geram SPED.
[hipótese] Cadeia SUP → FIN → Contabilidade é a principal fonte de dados para o Data Lake no primeiro ciclo — validar com Gescon + Gabriel.

4. Capacidades de integração técnica

O Sienge expõe 3 tipos de interface para integração, documentados em https://api.sienge.com.br/docs/.

4.1 APIs REST (transacional)

Uso: operações transacionais, baixo volume, leitura/escrita síncrona
Exemplos de recursos: credores, unidades, solicitações de compra, movimento de estoque, contratos
Autenticação: Basic Auth com usuário e senha de API (não é a mesma credencial de acesso à plataforma — criada no Portal de Integrações do Sienge)
Formato: JSON / HTTP standard
Quando usar: CRUD pontual, sincronização de pequenos lotes

4.2 APIs BULK (grande volume)

Uso: extração em massa, payloads grandes, para alimentar data lake e BI
Formato: JSON (batch) ou arquivo
Quando usar: cargas históricas, snapshots diários, reconciliações

4.3 Webhooks (event-driven)

Sienge envia notificações push via HTTP POST quando eventos pré-registrados ocorrem. Essencial para manter agentes e data lake em near real-time.

Headers importantes (documentação oficial):

Header	Significado
`x-sienge-tenant`	Subdomínio do tenant que originou a notificação (multi-tenant)
`x-sienge-event`	Tipo do evento (ex: `SALES_CONTRACT_ISSUED`)
`x-sienge-hook-id`	Identificador do registro do hook
`x-sienge-id`	Identificador único do evento — usar para idempotência

Famílias de eventos conhecidos (lista não-exaustiva):

PURCHASE_ORDER_GENERATED_FROM_NEGOCIATION, PURCHASE_ORDER_ITEM_MODIFIED
SALES_CONTRACT_UPDATED, SALES_CONTRACT_REMOVED, SALES_CONTRACT_ISSUED, SALES_CONTRACT_CANCELED
PROPERTY_RENTAL_UPDATED, PROPERTY_RENTAL_EXCLUDED, PROPERTY_RENTAL_CANCELLED, PROPERTY_RENTAL_TERMINATED
CONSTRUCTION_DAILY_REPORT_TYPE_UPDATED, CONSTRUCTION_DAILY_REPORT_TYPE_DELETED
Notificação de aprovação/reprovação de parcelas de Contas a Pagar
Notificação de autorização/desautorização de Contratos e Medições

Lista completa: https://api.sienge.com.br/docs/general-hooks-types.html.

Requisitos operacionais para webhooks:

Endpoint HTTPS público que aceita POST e responde 2xx rápido (<5s recomendado)
Idempotência baseada em x-sienge-id (salvar os IDs processados e rejeitar duplicados)
Retry/DLQ do lado do consumidor — Sienge tenta reenviar mas não é fila durável
Validação do x-sienge-tenant para roteamento multi-tenant (CTS vs Costal)

5. Caminhos de integração para agentes

Os 26 agentes Costal (catálogo) interagem com o Sienge em 3 camadas: leitura de dados (via API/Lake), escrita transacional (API REST) e reação a eventos (webhooks). Nenhum agente escreve direto no banco do Sienge — tudo passa pela API.

flowchart TB
    subgraph SIENGE["Sienge (SaaS cloud, multi-tenant)"]
        SIENGE_DB[(Banco Sienge)]
        SIENGE_API[API REST + BULK]
        SIENGE_HOOKS[Webhooks]
        SIENGE_DB --- SIENGE_API
        SIENGE_DB --> SIENGE_HOOKS
    end

    subgraph PLATFORM["Plataforma de dados Costal"]
        CONN[Conectores<br/>de ingestão]
        LAKE[(Data Lakehouse<br/>Databricks)]
        SEMANTIC[Camada semântica<br/>Gold tables]
        CATALOG[Catálogo + MDM]
        CONN --> LAKE
        LAKE --> SEMANTIC
        CATALOG -.-> LAKE
    end

    subgraph ORCHESTRATION["Orquestração e serviços"]
        GATEWAY[API Gateway]
        BUS[Barramento<br/>de eventos]
        BPM[BPM /<br/>Workflow]
    end

    subgraph AGENTS["Agentes Costal"]
        A_COMM["Comerciais<br/>Gate, Guardian,<br/>Hunter, Pulse"]
        A_ORC["Orçamentação<br/>Atlas, Draft"]
        A_LEG["Legal<br/>Integrity, Sentinel"]
        A_PLAN["Planejamento<br/>Compass, Hit, Viz"]
        A_EXEC["Execução<br/>Check, Safewatch,<br/>Trace, Visor"]
        A_SUP["Suprimentos<br/>Logflow, Source, Stock"]
        A_FIN["Financeiro<br/>Apex, King, Payroll"]
        A_HR["Pessoas/Sust.<br/>Eco, Grower, Scout,<br/>Vita, Warranty"]
    end

    SIENGE_API <-->|leitura/escrita| GATEWAY
    SIENGE_HOOKS -->|eventos| BUS
    CONN <-->|pull diário/bulk| SIENGE_API
    CONN <-->|pull event-driven| SIENGE_HOOKS

    BUS -.->|notifica| A_FIN
    BUS -.->|notifica| A_SUP
    BUS -.->|notifica| A_COMM

    A_FIN -->|escreve transações| GATEWAY
    A_SUP -->|PO, solicitações| GATEWAY
    A_COMM -->|propostas, contratos| GATEWAY

    A_ORC -.->|lê dados históricos| SEMANTIC
    A_PLAN -.->|lê cronograma| SEMANTIC
    A_EXEC -.->|lê medições| SEMANTIC
    A_LEG -.->|lê contratos| SEMANTIC
    A_HR -.->|lê pessoas| SEMANTIC

    BPM -.->|gatilhos| BUS

    style SIENGE fill:#e8f4f8,stroke:#2e75b6
    style PLATFORM fill:#e8f5e8,stroke:#2e7d32
    style ORCHESTRATION fill:#fff4e8,stroke:#c65911
    style AGENTS fill:#f5f0ff,stroke:#6b4e8d

Padrões de integração recomendados

Padrão	Quando usar	Exemplo concreto
Read-only via Lake	Agentes analíticos que não precisam de dado em real-time	Atlas lê histórico de orçamentos + preços unitários do Lake para treinar modelo paramétrico
Read via API REST	Dado quente (últimas 24h) não disponível no Lake ainda	King consulta saldo de Contas a Pagar via API antes de propor aprovação
Write via API REST	Agente cria/atualiza registro no Sienge	Source cria solicitação de compra; Atlas cria orçamento (linha de base); Guardian atualiza interação com cliente
React a webhook	Agente precisa agir quando algo acontece no Sienge	Sentinel reage a `SALES_CONTRACT_ISSUED` para auditoria legal; Trace reage a `CONSTRUCTION_DAILY_REPORT_*`
Escrita async via fila	Operações que podem esperar (não bloqueantes)	Payroll consolida apropriações de mão-de-obra em batch noturno

Mapeamento agente × módulo Sienge (primeira passada)

Agente (Onda)	Áreas funcionais	Módulos Sienge tocados	Operação típica
Atlas (1)	Orçamentação	ENG, SUP (preços)	Read histórico, write linha de base
Draft (1)	Propostas técnico-comerciais	Comercial, ENG	Read orçamento, gera documento externo
Sentinel (1)	Legal	Comercial (contratos)	Webhook `SALES_CONTRACT_*`, leitura
Trace (1)	Comunicação	Todos (cross-cutting)	Webhooks cross-módulo
Hunter (1)	Prospecção	(Fora do Sienge — Sales Impact)	Não toca Sienge na Onda 1
Hit (2)	Planejamento	ENG (cronograma)	Read + write ajustes
Visor (2)	Controle de obras	ENG (diário de obra), SUP (medições)	Webhook `CONSTRUCTION_DAILY_REPORT_*`
King (2)	Financeiro	FIN, GER	Read saldos, webhook aprovações
Source (2)	Compras	SUP	Write solicitações, webhook `PURCHASE_ORDER_*`
Gate (2)	Viabilidade	ENG + FIN + Comercial	Read cross-módulo
Guardian (2)	Account management	Comercial	Leitura de contratos, interações
Compass, Viz, Check, Safewatch (Onda 2-3)	Planejamento + execução	ENG, SUP, Qualidade (futuro)	Cada um com seu padrão
Apex, Payroll (3)	Financeiro + folha	FIN; folha em Paycom	Payroll não toca Sienge direto — Paycom → FIN
Logflow, Stock (3)	Logística + estoque	SUP	Read + write movimentos
Eco, Grower, Scout, Vita, Warranty (3)	Pessoas/sustentabilidade	CAD, Comercial (pós-venda)	Variável — a detalhar

Mapeamento inicial e incompleto. Cada agente deve ter sua spec detalhada (catálogo) com o padrão de integração preciso antes do go-live.

6. Multi-tenant e isolamento

O Sienge é multi-tenant via subdomínio — cada empresa é um tenant lógico isolado.

[fato] A implantação Costal começa na entidade CTS (Colliers Technical Services); quando o CNPJ da Costal sair, vira tenant separado (sienge-sistema)
[fato] Webhooks carregam x-sienge-tenant — consumidor precisa rotear baseado nesse header
[fato] API Basic Auth usa credencial específica por tenant
[premissa] Tenant CTS e Tenant Costal compartilharão alguns cadastros mestre (fornecedores, plano de contas base) — modelar no Data Lake como chave composta (tenant, id)

Isso casa com a decisão multi-tenant da arquitetura geral do projeto: plataforma deve suportar replicação para LatAm sem refactor (decisoes #7).

7. Princípios arquiteturais adotados (da nota Blaschek)

A nota técnica do Blaschek (2026-04_blaschek_arquitetura-sienge-crm) define 5 princípios arquiteturais para o ecossistema Costal × Sienge:

Especialização de sistemas — Sienge é registro e execução; CRM (quando chegar) é relacionamento e gestão comercial
Formação vs formalização da receita — leads, oportunidades e pipeline em CRM; contrato, recebível e comissão em Sienge
Desacoplamento via serviços — integrações CRM↔ERP via APIs e eventos, nunca ponto-a-ponto
Centralidade dos dados — visão unificada no Data Lake; cada domínio tem uma fonte oficial declarada
Governança e auditabilidade — rastreabilidade de decisões + controle sobre ações automatizadas por IA

A arquitetura de referência do Blaschek tem 7 camadas: Experiência/Relacionamento, Orquestração/Serviços, Sistemas Transacionais, Plataforma de Dados, Inteligência Artificial, Governança/Segurança, Observabilidade. O Sienge vive na camada 3 (Sistemas Transacionais).

8. Riscos e gaps conhecidos

Item	Referência	Impacto
R-001 Implantação Sienge avançar sem processo validado	riscos	Alto × Alta
R-002 Dados legados Colliers (~500 projetos) não acessíveis a tempo para alimentar Lake	riscos	Alto × Média
G-007 Inventário completo de sistemas Colliers + Costal (inclui APIs Sienge)	gaps	Alto
D-006 Cronograma Sienge abr→out 2026 condiciona go-live dos agentes	dependencias	Sistema
D-007 Go-live Onda 1 de agentes depende de blueprint + Lake + acesso API Sienge	dependencias	Sistema
[gap] Confirmação com Gescon/Carlos sobre versão da API disponível para CTS/Costal	—	owner: Gabriel
[gap] Definição do primeiro webhook ao vivo (piloto) e endpoint consumidor	—	owner: Gabriel + Michael
[gap] Estratégia de ingestão inicial: REST pull vs BULK snapshot vs webhook	—	owner: Gabriel

9. Próximos passos para o time

Gabriel — validar catálogo de APIs disponíveis na versão contratada pela Costal com Gescon (Carlos)
Gabriel + Michael — decidir primeiro módulo a ser espelhado no Data Lake (candidato: FIN Contas a Pagar, por ter maior cadência de dados e webhook conhecido)
Antônio — no discovery de orçamentação (Leandro), mapear exatamente quais campos do Excel da Costal alimentam a linha de base do Sienge (entrada para Atlas)
Rafael — confirmar cronograma Gescon e identificar marcos de go-live por módulo (input para dependencias.md e roadmap-board)
Blaschek — revisar e aprovar o mapeamento agente × módulo do §5 desta página, calibrando com o modelo global de dados

10. Documentação e referências externas

Oficiais do Sienge (Softplan)

Contextuais do projeto

Nota técnica Blaschek — Arquitetura com CRM e IA — fundamento estratégico
Mapeamento operacional Sienge Costal — decisões de escopo e configuração
Cronograma de implantação Gescon
Ata — definição de papéis Sienge 17-04
Data Lakehouse · Conectores · Governança técnica
Arquitetura empresarial Blaschek
Modelo global de dados (12 domínios)

Ver também

Mantido pela equipe Anouk. Revisar quando marcos do cronograma Sienge mudarem ou quando novos módulos entrarem em escopo.

Colliers × Costal — Interno

Explorador

Sienge — Guia de Arquitetura para o Time Anouk