# Loja Dataprev (DEME): caso de uso e sizing preliminar de Professional Services

**Versão:** 3.2 · **Data-base:** 16/10/2026 · **Finalidade:** decisão de pré-venda e preparação de discovery/SOW
**Classificação da estimativa:** envelope de capacidade com prazo fixo, confiança **média-baixa**

> **Resposta executiva.** A Loja DEME é uma jornada B2B de celebração contratual, não o Marketplace PAT e não um e-commerce com pagamento. Para cumprir o limite de **três meses**, o MVP deixa de tentar implementar as 49 referências anteriormente agrupadas e passa a ser um **MVP operacional assistido de COMPREV**, com prazo fixo de 12 semanas e envelope de **2.400–3.000 horas de PS**, referência de **2.700 horas**. Ele entrega o alicerce reutilizável, catálogo, identidade condicionada à prontidão do Gov.br, cadastro PJ, configuração e preço de um produto, dossiê, documentos, minuta e acompanhamento. Assinatura, PNCP, ERP e provisionamento usam operação assistida e evidência controlada até suas integrações serem automatizadas em evoluções separadas. Quantum Leap organiza a entrega AI-native; Claude Code/CLI, Cursor e Vibe Coding aceleram produção sob revisão humana, mas não eliminam decisões jurídicas, acessos, APIs, UAT ou controles de produção.

## 1. O que foi verificado

A consolidação original reuniu cinco tipos de fonte: materiais locais, Slack, Granola, agendas/anexos do Google Calendar e Gmail. Em 16/10/2026, a planilha [Dataprev-Marketplace-DV-Analise-Salesforce-v1-2026-10-14.xlsx](https://docs.google.com/spreadsheets/d/1fezEIawcPwjUX_7E5wKuhxuJmptpCQiN/edit?rtpof=true) foi lida integralmente, incluindo as abas **Análise**, **Resumo**, **Perguntas ao cliente**, **Necessidades (NE)** e **Legenda**. Divergências foram mantidas como decisões pendentes.

### 1.1 Fatos sustentados por mais de uma fonte

- A área responsável é a **DEME, Departamento de Monitoramento e Estratégia Comercial**.
- A Loja atual está em ServiceNow e seu excesso de customização foi apontado como origem de instabilidade e alto custo de mudança.
- A demonstração de 01/10 mostrou **B2B Commerce + Revenue Cloud**: catálogo anônimo, configuração de UNA, cotação, minuta e preparação do envio para assinatura. O fluxo completo de assinatura não foi executado.
- **COMPREV** foi o recorte inicial da demonstração, não o escopo total.
- Foram informados **11 produtos** em 01/10; o levantamento anterior descreve somente nove. Os dois produtos adicionais ainda não têm regras documentadas nas fontes consultadas.
- A base inicial é de **30 usuários internos** e cerca de **11.000 pessoas cadastradas** envolvidas em contratações. Esse total não representa usuários ativos simultâneos, instituições ou contratos.
- A projeção informada é de aproximadamente **500 novas contratações ainda em 2026**, pico de recontratações em 2027 igual ou superior ao de 2022 e, depois, cerca de **250 contratações/ano**.
- O **TOTVS/Protheus é a fonte oficial dos contratos e o responsável pelo faturamento**. A Loja conduz a celebração e sincroniza seu resultado; não deve virar uma segunda fonte oficial.
- Usuários internos usam **Microsoft AD**. Para usuários externos, **Gov.br** é o alvo, mas autenticação não comprova poderes de representação.
- O pós-contrato rotineiro de medição e boleto deve migrar para outra solução. O retorno à Loja tende a ser eventual, para aditivo ou cancelamento.
- O modelo comercial preferido é valor mensal previsível de sustentação/licenciamento; mínimo de contratos e cobrança por contratação não foram aceitos como premissas.

### 1.2 O que a planilha acrescenta

- **73 itens:** 56 funcionais, 10 não funcionais, 6 integrações e 1 processo.
- **72 itens ativos:** somente FN10.02, gestão contratual com fatura, RAS e consumo, está riscado no DV v1.1.
- **42 itens críticos**, 9 muito importantes, 4 desejáveis, 1 com prioridade mista e 17 sem classificação de exigência.
- **53 itens classificados como “Atende”**, 11 “Atende parcialmente”, 8 “A validar”, nenhum “Não atende” e 1 fora de escopo. Cobertura significa viabilidade com configuração, código, integração ou parceiro; não significa disponibilidade imediata.
- **Somente 1 item é classificado como nativo sem configuração relevante**. Há 39 de configuração, 22 de configuração com customização, 9 de customização, 1 de parceiro e 1 fora de escopo.
- **41 itens ainda não estão claros:** 21 ambíguos e 20 com informação faltante. A frente de integração concentra 12 dos 20 itens sem informação.
- O processo oficial possui **22 estados**, com expirações, rejeições, revisão humana, PNCP e liberação de acesso.
- O DV explicita regras que não estavam decompostas no sizing anterior: carrinho multiproduto, invalidação de produtos em contratações abertas, validação de e-mail, níveis Gov.br, múltiplos papéis e signatários, grupos autorizadores externos, duas assinaturas Dataprev, lembretes a cada 5 dias, expiração em 30 dias, três tentativas de validação e máquina de estados.

### 1.3 Separação obrigatória: Loja DEME ≠ Marketplace PAT

| Aspecto | Loja DEME | Marketplace PAT |
|---|---|---|
| Propósito | Catálogo e celebração contratual B2B | Plataforma do Programa de Alimentação do Trabalhador |
| Área/cliente | DEME/Dataprev | MTE/Dataprev |
| Unidade de negócio | Dossiê de contratação e termo | Transações e ecossistema PAT |
| Volumetria válida aqui | 30 internos; ~11 mil cadastrados; projeções de contratos | **Não reutilizar** 20–50 milhões de eventos/dia |
| Arquitetura de referência | Commerce + Revenue + integrações | Arquitetura própria do PAT |

Usar volume, licença ou sizing do PAT na Loja DEME produziria uma estimativa materialmente incorreta.

### 1.4 O que não foi comprovado

- Não existe nas fontes consultadas um sizing formal de PS em horas, composição, duração ou valor.
- A meta de “2–3 meses” não é viável para as 49 referências anteriormente agrupadas, mas pode orientar um MVP menor, assistido e de um único produto.
- “Mais de 80% nativo” e “todos os requisitos nativos” são leituras preliminares, não uma homologação de aderência.
- Revenue Cloud não inclui automaticamente toda a base CRM necessária. Sales Cloud, DRO, acessos externos e demais SKUs precisam de validação comercial.
- Nova org dedicada no Brasil é o direcionamento interno, mas provisionamento, instância e região ainda precisam de confirmação.
- MuleSoft on-premises é padrão transversal da Dataprev; os contratos de API, conectividade e responsabilidades específicos da Loja ainda não estão definidos.
- A planilha não contém horas, produtividade histórica, preços ou cronograma aprovado. A classificação de cobertura não deve ser convertida diretamente em “percentual nativo”.
- As metas não funcionais de 5 segundos, 30 segundos, 5 minutos e 80% de acurácia estão no DV, mas a própria planilha as classifica como “A validar” total ou parcialmente.

### 1.5 O que Quantum Leap muda e o que não muda

Os materiais oficiais descrevem Quantum Leap como o playbook de execução AI-native de Professional Services. A unidade de trabalho passa a ser o **Intent Statement**; agentes produzem configuração, código, testes e documentação; especialistas humanos aprovam, refinam, rejeitam ou escalam cada saída. O repositório registra intents, decisões, escopo e evidências, e cada dia de construção termina com demonstração de software funcional.

O programa declara como objetivo agregado uma redução de **35–40% no time-to-value**, não uma redução garantida de horas para qualquer projeto. O FAQ informa que projetos grandes devem ser divididos em uma sequência de engagements bem delimitados e que a faixa atualmente adequada é de 6–24 semanas de build.

Para aplicar o modelo à Loja DEME, são condições de entrada:

- consentimento para uso das ferramentas de IA com dados e org do cliente;
- Quantum Leap, Claude Code/CLI no ambiente aprovado, Cursor e demais conectores prontos antes do build;
- sponsor e responsáveis presentes em demonstrações diárias de 30–45 minutos;
- decisões e esclarecimentos da Dataprev em até 24–48 horas;
- escopo protegido por intents, critérios verificáveis, ledger e controle formal de mudança;
- revisão humana de toda configuração, código, teste e documento produzido por IA;
- CI/CD, segurança, rastreabilidade e gates MVG mantidos sem redução;
- UAT usada para confirmar o que foi demonstrado durante o build, e não para descobrir requisitos.

Vibe Coding pode apoiar protótipos e scaffolding. Nenhum artefato gerado por esse método deve chegar à produção sem revisão, teste, rastreabilidade e aprovação de um Trusted Guide. Os ganhos de Quantum Leap, Claude e Cursor se sobrepõem; não se deve multiplicar percentuais de aceleração entre ferramentas.

## 2. Caso de uso

### 2.1 Objetivo

Permitir que representantes de instituições encontrem produtos Dataprev, configurem condições comerciais, comprovem identidade e representação, percorram validações e aprovações públicas, assinem o instrumento e recebam confirmação de contratação e acesso, preservando o ERP como fonte oficial do contrato e do faturamento.

### 2.2 Atores

- **Representante/solicitante da instituição:** consulta, configura, envia documentos e acompanha o dossiê.
- **Signatário da instituição:** assina conforme competência comprovada.
- **Autorizador externo/detentor do dado:** participa somente quando o produto e a base legal exigirem.
- **Analista DEME:** trata exceções, revisões e pendências.
- **Aprovadores e dois signatários Dataprev:** aprovam e assinam conforme tabela de competência.
- **Jurídica Dataprev:** define rito, assinatura, PNCP e tratamento de prazo/cancelamento.
- **ERP/TOTVS:** recebe o contrato/ato final e permanece fonte oficial.
- **Sistema do produto:** recebe o pedido de provisionamento e retorna o resultado.

### 2.3 Jornada principal

1. **Catálogo público:** visitante consulta produtos sem login. O Modelo de Negócio pode ser visível, mas o download deve ser restrito a autenticados e registrado.
2. **Identidade:** representante entra por Gov.br, valida o e-mail e tem o nível da conta consultado; usuário interno usa Microsoft AD, conforme resposta de 06/10, embora o DV cite Gov.br também para internos.
3. **Instituição, pessoas e papéis:** a Loja consulta CNISPJ, cadastra entidade, signatários, fiscais e usuários, e comprova vínculos e poderes. Gov.br Prata/Ouro é exigido para signatários no DV.
4. **Configuração e preço:** usuário seleciona um ou mais produtos, sempre com quantidade 1 por produto, configura componentes/capacidades e vê o total recalculado.
5. **Documentos:** sistema solicita evidências por produto e ente, aplica validações e, após três tentativas inconclusivas, cria tarefa de revisão humana.
6. **Autorizações externas:** quando aplicável, todos os membros do grupo são notificados e a primeira decisão encerra o item. Rejeição retorna para ajustes; aprovação gera PDF comprobatório.
7. **Minuta:** regras, biblioteca de cláusulas, anexos e dotação orçamentária, quando aplicável, geram uma versão imutável igual à que será assinada.
8. **Assinaturas:** cliente assina primeiro e dois representantes Dataprev assinam conforme tabela de competência. Há lembrete a cada 5 dias e expiração em 30 dias.
9. **PNCP:** para ente sujeito ao art. 94, o rito controla comprovante, validação automática, três tentativas, revisão humana e prazo interno de 30 dias com lembretes a cada 5 dias.
10. **ERP e provisionamento:** envio idempotente ao TOTVS é confirmado; DRO ou Flow aciona cada produto, recebe sucesso/erro e movimenta o dossiê até Produção.

### 2.4 Exceções mínimas

- desistência pelo cliente;
- documentação ilegível, divergente ou não validada após tentativas automáticas;
- representante sem poder comprovado;
- autorização externa rejeitada ou expirada;
- minuta devolvida para ajuste;
- prazo de assinatura expirado;
- assinatura parcial ou integração indisponível;
- comprovante PNCP ausente, rejeitado ou fora do prazo;
- falha ou duplicidade no envio ao ERP;
- falha de provisionamento e compensação/reprocessamento;
- cancelamento administrativo.

### 2.5 Regras públicas que não podem ser simplificadas

- Login, comprovação de representação, aprovação e assinatura são capacidades distintas.
- Administração direta pode exigir dotação orçamentária; a regra depende do tipo de ente e instrumento.
- COMPREV exige habilitação perante a SPREV. Não se deve afirmar autorização adicional do INSS sem validação.
- Batimento SIRC possui autorização explícita do INSS.
- PNCP não é etapa universal: é condição de eficácia quando o art. 94 da Lei 14.133 se aplica.
- ICP-Brasil/A3 não está decidida. A modalidade de assinatura precisa de posicionamento jurídico escrito.

## 3. Requisitos e aceite

### 3.1 Capacidades funcionais

| ID | Capacidade | MVP 12 semanas | Evoluções | Critério de aceite resumido |
|---|---|:---:|:---:|---|
| C01 | Catálogo público e pesquisa | core, COMPREV | ✓ | Produto piloto visível sem autenticação, com versão e vigência |
| C02 | Gov.br externo e AD interno | condicional | ✓ | Gov.br entra somente com acesso e consentimento até o Gate 0; sem isso, lançamento é piloto restrito |
| C03 | Cadastro de PJ e representação | core assistido | ✓ | Instituição, pessoas e poderes registrados; conferência pode ser manual |
| C04 | Configuração, preço e cotação | core, COMPREV | ✓ | Regra COMPREV reproduz os exemplos homologados |
| C05 | Documentos e revisão humana | core manual | ✓ | Evidências versionadas e fila de revisão; IA documental fica para evolução |
| C06 | Aprovações e competência | fluxo mínimo | ✓ | Aprovação DEME simples e histórico imutável; grupos externos ficam para evolução |
| C07 | Minuta e cláusulas | 1 template | ✓ | Um modelo jurídico aprovado é preenchido e versionado |
| C08 | Assinaturas | evidência manual | ✓ | Assinatura ocorre fora da Loja; documento assinado retorna ao dossiê |
| C09 | PNCP condicional | evidência manual | ✓ | Aplicabilidade e comprovante são registrados; automação fica para evolução |
| C10 | Envio ao TOTVS | handoff controlado | ✓ | Pacote estruturado, protocolo e confirmação manual, sem integração em produção |
| C11 | Provisionamento | handoff controlado | ✓ | Pedido e retorno registrados manualmente; APIs ficam para evolução |
| C12 | Aditivo e distrato | não | ✓ | Novo termo aprovado/assinado e sincronizado sem mudar a fonte oficial |
| C13 | Reenquadramento COMPREV | não | ✓ | Regras anuais e impactos contratuais homologados |
| C14 | Contrato exclusivo | não | ✓ | Jornada própria, sem forçar carrinho/configurador de prateleira |
| C15 | Migração e histórico | não | ✓ | Escopo, qualidade, reconciliação e retenção aceitos |
| C16 | Atendimento/Service Cloud | opcional | opcional | Caso separado; não é pré-requisito automático do núcleo |

### 3.2 Não funcionais mínimos

- LGPD, classificação, minimização, retenção e descarte documentados.
- Criptografia em trânsito e repouso; segregação de perfis e menor privilégio.
- Auditoria ponta a ponta do dossiê, documentos, decisões e integrações.
- Idempotência, retentativas controladas, dead-letter/reprocessamento e correlação.
- Metas de disponibilidade, RTO/RPO, latência e capacidade homologadas antes do teste de desempenho.
- Acessibilidade WCAG 2.2 AA para as jornadas externas.
- Observabilidade com logs, métricas, alertas e runbooks.
- Critérios de DevSecOps, análise de vulnerabilidade, rollback e segregação de ambientes.

#### Metas do DV v1.1 que exigem homologação

| ID | Meta declarada | Tratamento no sizing |
|---|---|---|
| RNF02 | página exibida em até 5 s | teste de desempenho e definição de condições normais |
| RNF03 | interação de tela em até 5 s | separar ação local de operação dependente de integração |
| RNF04 | e-mail enviado em até 30 s | medir saída da plataforma, não entrega na caixa |
| RNF05 | validação documental em até 5 min | PoC com documentos reais e processamento assíncrono |
| RNF06 | acurácia documental mínima de 80% | conjunto de referência, fórmula e revisão humana |
| RNF07 | intercâmbio entre produtos em até 5 s | aplicar a chamadas síncronas; definir SLA assíncrono |
| RNF08 | resposta do chatbot em até 30 s | somente na evolução de atendimento, com teste de Agentforce |
| RNF09 | até 10 analistas simultâneos | carga interna baixa; licenças e perfis a confirmar |
| RNF10 | pelo menos 50 contratações/mês | compatível com a ordem de grandeza informada; testar picos |

### 3.3 Matriz de decisão

| Capacidade | Estado | Evidência e tratamento |
|---|---|---|
| B2B Commerce como vitrine | Confirmado na demo | Catálogo anônimo, carrinho e integração com Revenue foram demonstrados; produção ainda exige homologação |
| Revenue Cloud para configuração, cotação e minuta | Confirmado na demo | UNA, cotação e minuta foram exibidas em 01/10 |
| Microsoft AD interno | Confirmado | Resposta por email de 06/10 |
| Gov.br externo | Hipótese-alvo | Requisito recorrente; habilitação, nível de confiança e desenho de integração pendentes |
| IA documental atual | Confirmado, interface pendente | A Dataprev informou validação de documento e similaridade; fornecedor, API, acurácia e reuso não foram informados |
| Assinatura integrada | Decisão pendente | A demo apenas preparou o envio; provedor, Gov.br e ICP-Brasil exigem decisão jurídica e técnica |
| PNCP condicional | Confirmado como regra, solução pendente | Aplicação depende do art. 94; publicação, consulta, comprovante e operação precisam de desenho |
| TOTVS/Protheus como fonte oficial | Confirmado | Contratos e faturamento permanecem no ERP; payload, estados e reconciliação estão pendentes |
| Provisionamento dos produtos | Confirmado como necessidade | APIs, SLAs e padrão dos 11 produtos ainda precisam de inventário |
| Observabilidade ponta a ponta | Hipótese de solução PS | Controle proposto para sustentar integrações e exceções; metas precisam de aceite Dataprev |
| Nova org dedicada no Brasil | Decisão pendente | Direcionamento interno registrado; provisionamento, instância e região não foram confirmados |
| Service Cloud/Agentforce | Fora do MVP; ativo no DV | NE16 possui 4 requisitos críticos vigentes, em conflito com o faseamento discutido. Entra na evolução E5 |
| Contratos exclusivos | Fora do MVP | Incluídos na evolução E6, após desenho próprio |
| Pessoa física | Fora do MVP; ativa no DV | NE15 possui 2 requisitos críticos vigentes, em conflito com a fala inicial de “somente PJ”. Entra na evolução E4 e exige decisão antes de habilitar Person Account |
| Medição, boleto, Billing e pagamento | Fora do baseline | Medição e boleto devem migrar; pagamento não fez parte da demo; impacto opcional estimado separadamente |
| Agentforce e Slack | Fora do baseline | Não são dependências da celebração contratual confirmada |

### 3.4 Métricas da entrega AI-native

| Métrica | Definição | Uso |
|---|---|---|
| Lead time por intent | tempo entre intent aprovado e demonstração aceita | medir mediana e P90 por semana |
| Aceite na primeira demonstração | intents aceitos sem refinamento ÷ intents demonstrados | avaliar precisão da Intent Definition |
| Taxa e horas de refinamento | ciclos e horas adicionais por intent | separar falha do agente, ambiguidade e mudança |
| Design gaps em UAT | defeitos cuja causa é requisito ou desenho ausente | meta proposta de zero críticos |
| SLA de decisão | decisões respondidas em até 48 h ÷ decisões solicitadas | verificar prontidão do cliente |
| Scope drift | intents alterados após scope hash sem change control | meta proposta de zero |
| Defeitos escapados | defeitos encontrados após aceite ou em produção | manter severidade crítica em zero |
| Throughput aceito | intents aceitos por semana, ponderados por tamanho | calibrar os ROMs das evoluções |

## 4. Fronteira de sistemas

| Sistema/capacidade | Responsabilidade proposta | Decisão pendente |
|---|---|---|
| B2B Commerce | vitrine pública, catálogo e experiência de prateleira | composição final com Experience Cloud |
| Revenue Cloud | configuração, preço, cotação e geração de documentos | SKU base, DRO e aderência de ciclo de vida |
| Revenue Cloud Billing | ordem, subscription, recorrência, consumo e invoice em evolução opcional | add-on do Sales; fonte oficial, licenças e fronteira com TOTVS |
| Contas a Receber Dataprev | confirmação de pagamento e situação financeira | interface com Billing somente se essa evolução for aprovada |
| Salesforce Platform | dossiê, aprovações, filas, auditoria e exceções | modelo de acesso externo e volume real |
| Gov.br | identidade externa e, eventualmente, canal de assinatura | habilitação, nível de confiança e modalidade |
| Microsoft AD | identidade interna | grupos, federação e ciclo de acesso |
| Solução de assinatura | assinaturas e evidências | Gov.br, DocuSign, ICP-Brasil ou combinação |
| PNCP | publicação/consulta de evidência quando aplicável | API, responsabilidade operacional e tratamento jurídico |
| TOTVS/Protheus | fonte oficial do contrato e faturamento | payloads, estados, SLAs, erro e reconciliação |
| Produtos Dataprev | provisionamento/desprovisionamento | inventário de APIs e padrão por produto |
| IA documental atual | validação preliminar de documentos | fornecedor, API, acurácia, custo e reuso |
| MuleSoft | mediação e governança de integrações | runtime, rede, ownership e capacidade disponível |

### 4.1 Leitura da “Opção B: Salesforce Marketplace + Revenue + Medição”

O desenho recebido em 15/10/2026 é tratado como **alternativa de arquitetura**, não como escopo aprovado. A conversa com Guilherme Mattei em 16/10 detalhou o caminho padrão e as principais exclusões. A separação útil fica em quatro raias:

- **Marketplace:** catálogo, carrinho, login e checkout;
- **Salesforce Sales + Revenue:** configuração, precificação, elegibilidade, contrato, alteração e recorrência;
- **Billing:** ordem, subscription, recorrência, consumo, invoice e régua de cobrança;
- **Legado:** contas a receber e contabilidade.

Catálogo, login, configuração, preço, elegibilidade, contrato e minuta continuam no núcleo Revenue do plano. **Revenue Cloud Billing é um add-on do Sales**, com acesso por permission set, e permanece fora do MVP. Se for aprovado, o processo padrão começa depois da assinatura: a ordem cria a subscription, configurada como recorrente ou recorrente + consumo.

O recorrente exige ao menos configuração, templates de invoice e e-mails. Consumo exige wallet, que registra vendido e consumido, e ingestão em lote. Para a volumetria indicada, Bulk API pode ser tecnicamente suficiente, mas mapeamento de campos, qualidade, reconciliação e operação precisam ser estimados. O relatório padrão pode ser CSV. A régua de cobrança é uma frente própria, e o status de pagamento precisa vir do **Contas a Receber**, pois Billing não sabe sozinho quem pagou.

Antes de habilitar invoices em Salesforce, a Dataprev precisa decidir a fonte oficial. O material anterior informa TOTVS/Protheus como responsável por contratos e faturamento; gerar invoice também no Salesforce sem essa decisão criaria duplicidade e risco de reconciliação.

#### Sizing opcional de Billing

| Slice opcional | Inclui | Prazo | ROM de PS |
|---|---|---:|---:|
| B1 · Recorrência padrão | ordem, subscription, recorrência, invoice, templates de invoice/e-mail e dashboards padrão | 4–6 semanas | 600–1.000 h |
| B2 · Consumo | wallet, modelo de consumo, carga batch via ETL/Bulk API, mapeamento, reconciliação e CSV padrão | 4–6 semanas | 700–1.200 h |
| B3 · Cobrança e pagamento | régua de cobrança, ações por vencimento, integração de status com Contas a Receber e testes | 4–6 semanas | 500–900 h |
| **Programa Billing completo** | **B1 + B2 + B3, reestimados após decisão de arquitetura** | **engagements separados** | **1.800–3.100 h** |

**Exclusões confirmadas para esse ROM:** gateway de pagamento; contas e relatórios de GL; dashboards customizados, que exigiriam licenças Tableau; integração com Service; mudanças no ERP/Contas a Receber; licenças Salesforce, Tableau, ETL e terceiros. GL pode envolver grande quantidade de contas mesmo com configuração unitária simples.


### 4.2 Convergência Loja + DaaS: ponto de atenção e de/para de sizing

São **dois projetos em paralelo**, com prioridades e MVPs distintos. A Loja contrata; DaaS captura e qualifica o consumo; a tarifação e a emissão de invoice precisam de um responsável por contrato e competência. Adotar Billing pode substituir tarefas de rating ainda não construídas, mas não elimina medição, correlação, autorizações ou operação on-prem. Integrações compartilhadas têm um owner e entram uma vez nos dois SOWs.

A **memória consolidada** está no [material da Loja, seção Loja + DaaS](./dataprev-loja-deme-sizing-ps.html#convergencia-sizing), referenciada pelo material DaaS, e nos [dados estruturados da simulação](./assets/dataprev-loja-daas-cenarios.json). A [arquitetura Lucidchart v2](https://lucid.app/lucidchart/64ba1910-5854-4b50-9483-72b606abd62e/edit) mostra fluxo e fronteiras (páginas 1–3) e evidências dos times (página 6).

**Simulação, não proposta:** pacotes acumulados com escopos e momentos diferentes; não representam entrega integrada em 12 semanas. Referências existentes: Loja 2.400/2.700/3.000 h; DaaS, incluindo E1, 1.220/1.640/2.560 h. Billing usa 1.800/2.450/3.100 h; o central é ponto médio dos ROMs, não estimativa provável de Mattei.

| Cenário | Loja + Billing opcional | DaaS | Complementos | Total central PS | Δ vs. S0 | Faixa simulada |
|---|---:|---:|---:|---:|---:|---:|
| S0 · MVPs independentes | 2.700 h | 1.640 h | 0 h | **4.340 h** | referência | 3.620–5.560 h |
| S1 · Conexão sem Billing | 2.700 h | 1.640 h | 130 h | **4.470 h** | +130 h (+3,0%) | 3.710–5.760 h |
| S2 · Billing desde o desenho | 5.150 h | 1.465 h | 470 h | **7.085 h** | +2.745 h (+63,2%) | 5.605–9.070 h |
| S3 · Billing após o DaaS | 5.150 h | 1.640 h | 710 h | **7.500 h** | +3.160 h (+72,8%) | 5.890–9.720 h |

- **S0:** MVP COMPREV assistido e DaaS atual, independentes; 2.700 + 1.640 = 4.340 h.
- **S1:** apenas conexão técnica E3 DaaS (130 h centrais); 4.340 + 130 = 4.470 h. Protheus continua faturando.
- **S2:** Billing completo decidido antes da construção; 4.340 + 2.450 + 130 + 180 + 160 − 175 = 7.085 h. Retiram-se apenas tarefas comprovadamente substituídas e ainda não executadas.
- **S3:** Billing depois do DaaS entregue; 4.340 + 2.450 + 130 + 180 + 160 + 240 = 7.500 h. As 175 h já construídas permanecem no acumulado.

**De onde vem a diferença:** 110 h de apuração/memória no MVP DaaS + 65 h de pacotes/mudança no período na E1 = até 175 h centrais substituíveis (faixa 125–290 h). A simulação considera substituição integral condicionada à aderência nativa; se nenhuma hora puder sair, S2 será 7.260 h. S3 excede S2 em 415 h (175 h construídas antes da substituição + 240 h de transição), 5,9% de S2. Não é prova de economia total com Billing, que adiciona funcionalidades.

| Incremento ou alocação | Mínimo / central / máximo | Tratamento |
|---|---:|---|
| Conexão Loja–DaaS, E3 | 90 / 130 / 200 h | ROM técnico existente, não expansão comercial da Loja |
| Invoice Billing → Protheus | 120 / 180 / 260 h | nova hipótese de interface; sem alterações internas no ERP |
| Aceite integrado entre projetos | 100 / 160 / 240 h | nova hipótese de testes; não repete testes próprios dos projetos |
| Migração posterior e corte | 160 / 240 / 360 h | nova hipótese, somente em S3 |
| B2: configuração de consumo, wallet e rating | 400 / 550 / 700 h | alocação hipotética dentro de B2 |
| B2: ingestão Mule → Billing | 230 / 300 / 370 h | já incluída em B2; não adicionar novamente ao DaaS |
| B2: extrato padrão CSV | 70 / 100 / 130 h | completa B2 = 700 / 950 / 1.200 h |

B1 = 600/800/1.000 h, B2 = 700/950/1.200 h e B3 = 500/700/900 h. B3 inclui retorno do Contas a Receber. A interface adicional de 180 h é a saída da invoice para o ERP, não outro retorno de pagamento. Se o time Mule executar a ingestão B2, transferir as horas e o aceite entre as frentes sem mudar o total. As faixas são somas de hipóteses por linha, não intervalos estatísticos; as horas novas não são cotações dos especialistas.

**Limites comuns:** expansão comercial COMPREV → família API DaaS, demais evoluções da Loja, provisionamento E2 DaaS, SEI, tempo real, licenças, esforço Dataprev e mudanças internas no ERP ficam fora. Assim, estes totais não são orçamento integral da jornada futura. A média de horas não determina prazo ou alocação simultânea.

**Gate antes dos SOWs:** DEME/DERC/Produto/DEGN definem consumidor, pagador, regras e emissor; Mattei e Marcelo/Elvis validam rating, ingestão, residência de dados e corte; PS das duas frentes mantém um backlog comum com owner, horas e aceite por entregável. O avanço de uma frente não deve presumir a disponibilidade da outra.

**Fontes privadas conferidas em 16/10:** [Mattei: ingestão e mapeamento](https://salesforce.enterprise.slack.com/archives/D0C0G5750JH/p1792181292929009), [pagamento via Contas a Receber](https://salesforce.enterprise.slack.com/archives/D0C0G5750JH/p1792181518984459), [Billing e Service como opções](https://salesforce.enterprise.slack.com/archives/C0C3DPMPWJD/p1791468337750179) e [preocupação transversal de Juliane](https://salesforce.enterprise.slack.com/archives/C0C9T5011RT/p1792184703849909). A arquitetura e a distribuição de horas seguem propostas internas, sem aceite cliente.

## 5. Plano de MVP e evoluções

### 5.1 MVP em 12 semanas: COMPREV operacional assistido

O MVP não é uma versão comprimida do Documento de Visão completo. Ele é uma primeira release produtiva, limitada a **COMPREV**, que estabelece o alicerce e digitaliza o percurso até um handoff controlado. A data é fixa; se uma dependência externa não estiver pronta, a automação correspondente sai da release e permanece como operação assistida.

**Resultados incluídos:**

1. org, repositório, CI/CD, perfis, logs, dados de referência e controles Quantum Leap prontos;
2. catálogo público com COMPREV, conteúdo versionado e início de contratação;
3. identidade externa Gov.br somente se a habilitação estiver pronta no Gate 0; AD interno e piloto restrito são alternativas de contingência;
4. cadastro de pessoa jurídica, representantes e papéis, com conferência assistida;
5. configuração e preço COMPREV com quantidade 1, grupo oficial e exemplos homologados;
6. dossiê, upload de documentos, fila de revisão humana, histórico e estados essenciais;
7. um template de minuta aprovado, preenchido e versionado;
8. registro de aprovação, assinatura externa e PNCP por upload de evidência;
9. pacote estruturado para TOTVS e provisionamento, com protocolo e confirmação manual;
10. segurança, acessibilidade da jornada entregue, UAT, produção, runbook, treinamento e hypercare.

**Não incluídos no MVP:** carrinho multiproduto, 11 produtos, IA documental, grupos autorizadores externos, assinatura integrada, automação PNCP, APIs produtivas de TOTVS e produtos, todos os 22 estados detalhados, contratos exclusivos, aditivo, distrato, reenquadramento, pessoa física, migração ampla, Service Cloud, Agentforce, CSM, medição, Billing, pagamento e Slack.

### 5.2 Alicerces que não podem ser descartáveis

| Alicerce | Decisão de desenho para o MVP | Como habilita as evoluções |
|---|---|---|
| Modelo canônico | instituição, pessoa, papel, produto, dossiê, documento, decisão, evidência e evento de integração | evita remodelar dados ao adicionar produtos e atos |
| Regras por metadados | preço, elegibilidade, documentos, template e transições parametrizados | reduz código específico por produto |
| Motor de estados | estados essenciais e histórico imutável, com transições configuráveis | recebe os 22 estados sem reescrever a jornada |
| Identidade desacoplada | autenticação separada de representação e competência | permite Gov.br, AD e futuras modalidades |
| Documentos e evidências | arquivos versionados, classificação e revisão manual | permite conectar Document AI e assinatura depois |
| Camada de integração | contratos, correlação, idempotência, outbox, retentativa e adaptadores | substitui handoffs manuais por APIs sem alterar o domínio |
| DevSecOps e observabilidade | pipeline, testes, análise de segurança, logs e alertas desde o primeiro deploy | mantém velocidade sem perder governança |
| Repositório Quantum Leap | intents, critérios, decisões, scope hash e evidências de validação | preserva rastreabilidade e mede throughput real |

### 5.3 Evoluções como engagements de até três meses

| Onda | Resultado | Duração indicativa | Envelope inicial de PS |
|---|---|---:|---:|
| E1 · Fechamento automatizado | Document AI, assinatura, PNCP, TOTVS e um provisionamento ponta a ponta | 8–10 semanas | 1.800–2.400 h |
| E2 · Expansão de produtos | 2–3 produtos por onda, carrinho, novas famílias de preço, documentos e autorizadores | 6–8 semanas por onda | 1.200–1.800 h |
| E3 · Ciclo contratual | aditivo, reajuste, renovação, suspensão, restabelecimento, distrato e reenquadramento | 8–10 semanas | 1.500–2.200 h |
| E4 · Pessoa física | Person Account, CNISPF, consentimento, papéis e regras próprias | 6–8 semanas | 800–1.200 h |
| E5 · Atendimento inteligente | Service Cloud, Agentforce, CSM, pesquisa e handoff para atendimento | 8–10 semanas | 1.200–1.800 h |
| E6 · Exclusivos e histórico | contratos exclusivos, migração e consulta ao legado | 8–12 semanas | 1.400–2.200 h |
| E7 · Billing opcional | recorrência, consumo e cobrança em três slices independentes | 4–6 semanas por slice | 1.800–3.100 h no programa |

Os envelopes das evoluções são ROMs independentes e não devem ser somados como proposta. Cada onda recebe novo conjunto de intents e nova estimativa usando a velocidade, taxa de refinamento e defeitos observados no MVP.

## 6. Sizing de Professional Services

### 6.1 Método

- prazo contratual fixo de 12 semanas, com escopo protegido;
- envelope de capacidade, não promessa de absorção de escopo;
- horas usadas para planejamento interno de capacidade; o compromisso comercial deve ser expresso por outcomes e critérios de aceite;
- Quantum Leap operando dentro dos gates MVG;
- artefatos gerados por agentes e aprovados por Trusted Guides;
- demonstrações diárias de software funcional e decisões em 24–48 horas;
- UAT de confirmação, precedida por validação contínua;
- integrações indisponíveis substituídas por handoff controlado, sem simular automação inexistente;
- ausência de prontidão desloca escopo, não a data.

### 6.2 Envelope do MVP

| Workstream | Mínimo | Referência | Limite | Resultado |
|---|---:|---:|---:|---|
| Pre-flight Quantum Leap e Intent Definition | 180 | 210 | 240 | ferramentas, consentimentos, intents e critérios |
| Arquitetura, segurança e DevOps | 270 | 300 | 330 | org, pipeline, modelo e guardrails |
| Catálogo e configuração COMPREV | 260 | 300 | 330 | vitrine e produto piloto |
| Identidade, PJ e papéis | 230 | 260 | 300 | acesso e cadastro assistido |
| Dossiê, documentos e estados | 330 | 360 | 390 | processo mínimo auditável |
| Preço, cotação e minuta | 250 | 280 | 320 | regra COMPREV e um template |
| Handoffs e esqueleto de integração | 190 | 220 | 250 | contratos, pacote e confirmação |
| QA, UAT, segurança e acessibilidade | 290 | 320 | 350 | evidência de qualidade |
| Release, adoção e hypercare | 200 | 220 | 230 | produção e operação inicial |
| Programa e governança | 200 | 230 | 260 | gates, riscos, decisões e mudança |
| **Total** | **2.400** | **2.700** | **3.000** | **12 semanas fixas** |

Com 160 h por profissional/mês, o envelope corresponde a **5,0–6,25 FTE médios** durante três meses; a referência de 2.700 h equivale a **5,6 FTE**. O time terá mais pessoas que FTEs porque especialistas atuam parcialmente.

### 6.3 Composição de referência por papel

| Papel Quantum Leap / PS | Horas |
|---|---:|
| Program Lead | 280 |
| Intent/Solution Architect | 440 |
| Agent Orchestrator/Technical Architect | 400 |
| Trusted Guide Commerce/Revenue | 480 |
| Trusted Guide Platform/Integration | 480 |
| Logic Validator/QA | 360 |
| UX/Adoption | 100 |
| DevOps/Security | 160 |
| **Total** | **2.700** |

### 6.4 Esforço Dataprev e condições de produtividade

Fora das horas de PS, a Dataprev precisa prover:

- sponsor com 30–45 minutos por dia para demonstração e decisão;
- PO/DEME com 80% de dedicação durante as 12 semanas;
- Jurídica, segurança, identidade, COMPREV e TOTVS com SLA de resposta de 24–48 horas;
- 4–6 usuários de negócio para validação contínua e UAT;
- org, licenças, acessos, dados sintéticos, template e exemplos de preço antes do build;
- consentimento formal para as ferramentas de IA e tratamento de dados;
- responsáveis por produção, cutover, operação assistida e aceite.

Sem essas condições, o engagement deixa de ser aderente ao modelo AI-native descrito pelo Quantum Leap. A resposta correta é reduzir escopo ou mudar o modelo de entrega, não assumir produtividade não comprovada.

## 7. Premissas, exclusões e gatilhos de reestimativa

### Premissas

- nova org, licenças, repositório e ferramentas Quantum Leap disponíveis antes do build;
- consentimentos de IA, ambientes de teste e dados sintéticos fornecidos no Gate 0;
- um template jurídico COMPREV e exemplos de preço aprovados;
- operação assistida aprovada para assinatura, PNCP, TOTVS e provisionamento;
- contratos de interface preparados para futura mediação via MuleSoft;
- MVP limitado ao COMPREV e aos estados essenciais;
- português do Brasil e uma única pessoa jurídica Dataprev contratada.

### Exclusões

- preço de licenças, consumo e serviços de terceiros;
- sustentação após hypercare;
- reconstrução do ERP/TOTVS;
- gestão financeira, cobrança, boleto e medição;
- pagamentos;
- IA documental, assinatura integrada, PNCP automatizado, integração produtiva com TOTVS e provisionamento por API;
- demais produtos e carrinho multiproduto;
- pessoa física e CNISPF no MVP, incluídos somente em evolução própria;
- chatbot, Agentforce, Service Cloud e CSM no MVP, incluídos somente em evolução própria;
- Slack em ambos os cenários;
- saneamento ilimitado de dados legados;
- operação jurídica/manual da Dataprev.

### Reestimar se ocorrer

- assinatura integrada, ICP-Brasil/A3 ou múltiplos provedores;
- qualquer produto além de COMPREV ou novo modelo de preço no MVP;
- integração produtiva com TOTVS, PNCP, IA ou produtos;
- inclusão de contratos exclusivos no MVP;
- migração de dossiês/contratos ativos;
- requisitos de residência, segurança ou disponibilidade não previstos;
- antecipação de Service Cloud ou pessoa física para o MVP;
- pagamento, medição ou boleto;
- mudança da fonte oficial de contratos.

## 8. Decisões necessárias antes de SOW

1. A DEME confirma COMPREV como único produto do MVP de 12 semanas?
2. A Loja celebra contratos exclusivos? Em qual onda?
3. Qual é a solução de assinatura e a exigência de ICP-Brasil?
4. Como se comprova representação e poder de assinatura após o login Gov.br?
5. Para cada produto, quem autoriza, quais documentos e qual base legal?
6. Quando PNCP se aplica, quem publica, quem valida e o que acontece no prazo expirado?
7. Quais objetos, estados, payloads, SLAs e idempotência o TOTVS suporta?
8. Quais dos 11 produtos possuem APIs de provisionamento e sandbox?
9. A IA documental atual tem API, SLA, acurácia e licença reutilizáveis?
10. Billing será usado? Se sim, Salesforce ou TOTVS será a fonte oficial de invoice e faturamento?
11. Qual é a origem, frequência, volume e mapeamento do consumo, e como o Contas a Receber devolverá o status de pagamento?
12. Quais ambientes, região, conectividade e capacidade MuleSoft/ETL estão disponíveis?
13. Quais SKUs foram aprovados: CRM base, Revenue, Commerce, Billing, DRO, acessos externos e eventuais add-ons? Tableau permanece fora?
14. Quais volumes de visitantes, MAU, sessões, documentos e chamadas devem orientar desempenho, e quais dados/contratos serão migrados?
15. Quem aceita cada capability, participa da demonstração diária e decide em até 24–48 horas?

A aba “Perguntas ao cliente” possui **41 linhas**. Antes do SOW, as 15 decisões acima devem ser respondidas com atenção especial a: semântica de quantidades e faixas; preço para visitante; invalidação de produto em carrinho/dossiê; credenciamento Gov.br; papéis por produto; definição de validação documental; reclassificação de entidade; anexos contratuais; login dos autorizadores; primeira resposta do grupo; reutilização após expiração; assinatura Gov.br/A3; decisão humana antes do distrato PNCP; APIs de CNISPJ, ERP e produtos; índice de reajuste; reenquadramento; PF; CSM; e fórmula dos NFRs.

## 9. Gates recomendados

- **Gate 0, prontidão, antes do kickoff:** COMPREV, org, licenças, consentimentos, sponsor, template e responsáveis confirmados.
- **Gate 1, intents aprovados, fim da semana 2:** roadmap, arquitetura, critérios, operação assistida e scope hash aprovados.
- **Gate 2, fundação demonstrável, fim da semana 4:** pipeline, segurança, catálogo, identidade contingenciada e modelo canônico funcionando.
- **Gate 3, jornada funcional, fim da semana 8:** COMPREV percorre dossiê, documentos, preço e minuta em ambiente de teste.
- **Gate 4, UAT confirmatória, fim da semana 10:** critérios demonstrados continuamente e aceite sem design gaps críticos.
- **Gate 5, produção, semana 11:** go/no-go, cutover e operação assistida aprovados.
- **Gate 6, encerramento, semana 12:** hypercare, handoff, métricas e backlog priorizado das evoluções.

## 10. Registro de evidências e rastreabilidade

| Fonte | Evidência utilizada | Peso/limite |
|---|---|---|
| [Planilha DV v1.1, 14/10/2026](https://docs.google.com/spreadsheets/d/1fezEIawcPwjUX_7E5wKuhxuJmptpCQiN/edit?rtpof=true) | 73 itens, cobertura, forma de atendimento, confiança, 41 perguntas, NFRs e 22 estados | fonte primária da decomposição; não contém horas nem aceite cliente |
| [Quantum Leap Pilot Enablement Hub](https://salesforce.enterprise.slack.com/docs/T2E6RHTM0/F0BBGC6JJAH) | playbook AI-native, papéis, intents, gates, readiness, demonstrações diárias e critérios de recuo | exige consentimento, ferramentas prontas e governança MVG |
| [Quantum Leap FAQ](https://salesforce.enterprise.slack.com/docs/T2E6RHTM0/F0B3HK09X8D) | alvo de 35–40% de redução no time-to-value, human-in-the-loop, faixa de 6–24 semanas e programas grandes em engagements sequenciais | meta de programa, não garantia específica para a Loja |
| [Command Center DEME](./dataprev-marketplace-deme-bsa.html) | requisitos NE1–NE16, contradições, arquitetura e respostas de 06/10 | consolidação local; não é SOW |
| [Apresentação do caso](./dataprev-marketplace-deme-apresentacao.html) | narrativa da demo e jornada | material executivo |
| [Arquitetura Dataprev](./assets/dataprev-arquitetura.json) | Loja como capacidade “em desenho” | contexto transversal |
| [Future State PS](./Future-State/dataprev-futurestate-ps.html) | nova org, riscos de multi-org e ausência de sizing | visão interna |
| Slack privado `DTP - Loja - Revenue - interno` (`C0B0HLHP153`) | Revenue Cloud Advanced + DRO; COMPREV para a demo | decisão interna, não compromisso cliente |
| [DM com Guilherme Mattei, 16/10/2026](https://salesforce.enterprise.slack.com/archives/D0C0G5750JH) | Billing como add-on; ordem/subscription; recorrência; wallet e Bulk API; régua; integração com Contas a Receber; exclusão de gateway, GL, Tableau customizado e Service | orientação de especialista Revenue; depende de decisão e aceite Dataprev |
| Slack, DM de 05/10 | Service Cloud como expansão possível | não incluir no baseline |
| Granola, reuniões de 31/08, 14/09, 15/09 e 01/10 | dor atual, desenho, demo e pendências | transcrições/notas; fala não equivale a aprovação |
| Google Calendar, eventos “Marketplace/Loja” e anexos Gemini | datas, participantes, agenda e materiais anexos | PAT foi segregado da DEME |
| [Gmail: Questionamentos Marketplace](https://mail.google.com/mail/u/0/#all/1a0fe426705bca32) | usuários, volumes, IA atual, AD, pós-contrato e modelo comercial | respostas de negócio; volumes são projeções |
| Gmail, mensagem de 13/10 sobre workshop | APIs/marketplace seguem frente própria e precisam de detalhamento | reforça necessidade de discovery |

## 11. Recomendação

Contratar um **MVP operacional assistido de COMPREV por 12 semanas**, com envelope de **2.400–3.000 horas** e referência de **2.700 horas de PS**. Proteger a data por meio de intents e retirar automações cuja prontidão não seja comprovada no gate correspondente. Executar assinatura, PNCP, TOTVS e provisionamento inicialmente como handoffs controlados, preservando contratos e estruturas para automação posterior. Tratar cada evolução como engagement independente de no máximo três meses e recalibrar seu esforço com métricas reais do MVP. Se Billing for priorizado, decidir primeiro a fonte oficial de invoice/faturamento e contratar B1, B2 e B3 separadamente. Não converter os envelopes em preço sem rate card, licenças, consentimentos, responsabilidades da Dataprev e critérios de aceite.