Projeto
3 meses
12 semanas após o kickoff · MVP na S8 e Evolução 1 na S12
01 · Resposta executiva
Fundação em produção em 8 semanas. Projeto concluído em 12.
O plano anterior levava cerca de 8 meses porque tratava a bilhetagem como um sistema completo: piloto separado, provisionamento automatizado, três ondas de APIs e dois ciclos de faturamento ao vivo. Para caber em 3 meses, o projeto entrega primeiro a fundação, que responde à pergunta do DERC: qual contrato e qual autorização amparam cada chamada. O que automatiza processos que já funcionam à mão vira evolução. A construção com Quantum Leap reduz as horas em cerca de 32%, mas o prazo só se sustenta se o ambiente on-prem, os acessos e os consentimentos estiverem resolvidos antes do kickoff.
Esforço de PS
1.640 h
provável com Quantum Leap · faixa 1.220–2.560 h
MVP em produção
S8
1.280 h prováveis · faixa 960–2.000 h
Ganho com Quantum Leap
≈32%
nas horas, contra 2.410 h no modelo tradicional · MVP em 8 semanas, não 12
APIs no API DaaS
≈20
lista aberta; 23 citadas em 07/10
Contratos multicliente
≈2.200
declarado em 07/10; a parcela API DaaS não foi informada
Receita sem apuração
≈R$ 100 mi
por ano, declarado no workshop · não auditado
vCores MuleSoft
14 + 8
produção + pré já contratados, compartilhados com UNA e PAT
O que o MVP precisa provar: cada chamada cobrável ligada ao contrato e à autorização corretos, os totais conferidos com a origem em dois meses já faturados e o consumo sem vínculo listado todos os dias. É essa evidência que permite à DEGN adotar a medição nova.
Recomendação: pré-flight de três semanas na pré-venda (prova de valor, consentimentos, acessos e amostra do WSO2), kickoff com o modelo Quantum Leap aprovado, MVP em produção na S8 e Evolução 1 até a S12. O prazo é fixo e o escopo é variável: se o MVP atrasar, a Evolução 1 encolhe e a data de 3 meses se mantém. Provisionamento, nova Loja, SEI e tempo real ficam para depois, por módulo.
02 · Análise crítica
A prioridade está clara. As regras e as responsabilidades ainda precisam ser definidas.
Leitura cruzada do documento de fluxo de 13/10, da reunião de 15/10, do workshop de 07 e 08/10, do licenciamento MuleSoft vigente, do sizing da Loja e do playbook Quantum Leap. Fatos sustentados ficam separados de hipóteses e de declarações não verificadas.
O que sustenta a demanda
- APIs primeiro e Loja em paralelo: prioridade reiterada no workshop e em 15/10.
- Painel Oracle em produção e WSO2 como gateway: há onde publicar e de onde capturar.
- Caso real e verificável: o INSS autoriza AGU e CNJ a consumir por ele, e o rastreio hoje é manual.
- Licenças MuleSoft on-prem já contratadas: vCores, API Manager e Flex Gateway.
O que pode comprometer a entrega
- Qualidade da origem: o WSO2 “não entrega o dado corretamente”, e o modelo de cobrança mudou quatro vezes.
- Operação e governança do MuleSoft on-prem sem dono definido.
- Regras do modelo de negócio não formalizadas para apuração automática.
- Prazo de 3 meses com ambiente on-prem, acessos e consentimentos ainda por preparar.
O que ainda precisa de resposta
- Volume de chamadas por mês, pico e número de credenciais.
- A quem se fatura o consumo delegado.
- Plano de controle (híbrido ou PCE) e vCores disponíveis.
- Fonte dos contratos enquanto a nova Loja não existir.
- Consentimento para uso de IA e elegibilidade ao Quantum Leap.
Oito pontos críticos
Cada ponto traz a evidência e a consequência prática para o desenho, o escopo ou a comunicação com a Dataprev.
O problema é atribuição, não contagem.
O WSO2 já conta chamadas e o painel Oracle está em produção. Falta o elo entre credencial, órgão, autorização e contrato: hoje o DERC descobre que a AGU está consumindo, procura o ofício do INSS e faz o vínculo à mão (15/10). O modelo de cobrança já foi alterado quatro vezes sem resolver (07/10).
O que fazerComeçar pelo registro de contratos, autorizações e credenciais e pela regra de apuração. Sem corrigir os vínculos do cadastro, a troca de ferramenta mantém o problema.
Primeiro, conferir se os dados de origem são confiáveis.
Em 07/10, o WSO2 foi descrito como uma ferramenta que contabiliza transações sem entregar o dado corretamente. Não se sabe qual interface de captura está disponível (analytics, logs de acesso ou a base do painel) nem a versão do WSO2.
O que fazerNo pré-flight, teste de completude com uma amostra. No MVP, dois meses fechados reprocessados e comparados com log de acesso, analytics e painel.
MuleSoft on-premises é premissa, não detalhe de instalação.
O plano de controle deste caso não está definido. A capacidade contratada (14 vCores de produção e 8 de pré-produção) é compartilhada com UNA e PAT. Em 04/10 não havia posição sobre quem absorve a governança do MuleSoft; em 08/10, acesso a servidores, treinamento e suporte ficaram pendentes.
O que fazerPré-flight (G0) antes do kickoff, com RACI de operação assinado e vCores reservados. Em 3 meses não há folga para preparar o ambiente durante o projeto.
Trocar o WSO2 é o caminho mais caro para provar valor.
São cerca de 20 APIs em produção, com credenciais e consumidores ativos. Colocar o Flex Gateway no caminho exige migrar clientes e consome o pacote de 100 milhões de chamadas, sem volume conhecido. Em 15/10, a própria Dataprev pediu integração com o WSO2.
O que fazerCoexistência no MVP e nas evoluções. Flex Gateway só para APIs novas, como a do CadÚnico, na E4. A prova é a reconciliação lado a lado.
Consumo delegado é decisão comercial antes de ser requisito técnico.
Hoje o INSS é faturado pelo próprio consumo, não pelo da AGU e do CNJ que ele autoriza (15/10). Com o CadÚnico, o MDS poderá autorizar bancas de concurso e concessionárias de energia para a tarifa social: o padrão vai crescer.
O que fazerO MVP não depende dessa decisão: separa o consumo delegado e mantém a cobrança atual até DERC, Jurídica e DEGN decidirem a quem se fatura e se há limite por autorização. O sistema atribui; não decide quem paga.
A frente é independente, mas o gatilho está na Loja.
O documento parte do contrato celebrado no novo marketplace, que ainda não existe. Hoje a loja roda em ServiceNow e a DEGN recebe uma planilha diária que serve de base ao faturamento.
O que fazerNo MVP, alimentar o registro pela fonte atual (Protheus, planilha ou ServiceNow), por meio de uma planilha controlada. Integrar a nova Loja na E3, sem bloquear a bilhetagem.
Loja e DaaS precisam de uma fronteira comum de tarifação e faturamento.
A Loja e este backoffice são projetos separados, executados em paralelo. Billing é uma opção da Loja (B1–B3: 1.800–3.100 h), enquanto este plano mede no MuleSoft on-prem e entrega ao Protheus. A possível sobreposição está na tarifação, franquias, extratos e interfaces, não na necessidade de capturar e atribuir o uso.
O que fazerValidar com Mattei, Marcelo/Elvis, DEME/DERC e DEGN quem mede, tarifa, fatura e retorna pagamentos. Preservar o MVP independente da nova Loja; decidir a fronteira antes dos SOWs. Ver cenários e de/para de sizing e arquitetura no Lucidchart.
Três meses cabem se o MVP for a fundação, não o sistema completo.
O plano anterior somava 34 semanas: piloto separado, três ondas, provisionamento e dois ciclos de faturamento ao vivo. A meta agora é de no máximo 3 meses. Em on-prem, o que trava o calendário não é a construção: são ambiente, acessos, decisões e ciclos de faturamento.
O que fazerFundação em produção na S8 e Evolução 1 até a S12, com prazo fixo e escopo variável. Provisionamento e integrações viram evoluções posteriores. Ambiente e consentimentos se resolvem no pré-flight, antes do kickoff.
Riscos de execução
| Risco | Probabilidade | Impacto | Mitigação |
|---|---|---|---|
| Infraestrutura e acessos on-prem tardios | Alta | Alto | Pré-flight antes do kickoff; desenvolvimento local desde a S0; a Evolução 1 absorve até quatro semanas de atraso. |
| Decisões da Dataprev acima de 48 horas | Alta | Alto | SLA de decisão no kickoff, demonstração diária com o PO e, se persistir, Plano B AI-Augmented. |
| Consentimento de IA ou elegibilidade ao Quantum Leap negados | Média | Alto | Pedido pelo Program Lead no pré-flight; Plano B com MVP na S10. |
| Capacidade MuleSoft compartilhada com UNA e PAT | Média | Alto | Reserva de vCores no pré-flight; teste de carga com volume real na S6. |
| Origem WSO2 incompleta ou incorreta | Média | Alto | Teste de completude com amostra no pré-flight; logs de acesso como alternativa. |
| Histórico do WSO2 insuficiente para o paralelo retroativo | Média | Médio | Confirmar a retenção no pré-flight; sem histórico, o paralelo passa a ser ao vivo e a adoção oficial vai para depois da S12. |
| Regras de apuração ambíguas | Alta | Médio | Regra v1 decidida até o G1, versionada e aprovada por Produto e DEGN; o MVP mantém a cobrança atual do consumo delegado. |
| Escopo crescendo durante o build | Alta | Médio | Intent ledger com hash de escopo; pedido novo entra como evolução, com aprovação própria. |
| Protheus ainda em revitalização | Média | Médio | Medição por arquivo no MVP e na E1; API na E4. |
| Disponibilidade de especialistas Dataprev | Média | Alto | Agenda fixa por gate com WSO2, Oracle e DEGN, definida no pré-flight. |
| Recesso de fim de ano | Alta se o kickoff for em novembro | Médio | Congelar o calendário no recesso, contando 12 semanas úteis, ou fazer o kickoff em janeiro. |
| Sobreposição de escopo e sizing entre Loja e DaaS | Média | Alto | Um responsável por medição, rating, invoice e interfaces; alinhar os dois SOWs. Simular antes de contratar. |
03 · Caso de uso
Atribuir, medir e apurar o consumo de cada contrato.
O MVP cobre a Fase 5 do documento de fluxo (bilhetagem e medição). A automação técnica da Fase 4 (provisionamento) é a Evolução 2. As fases 1 a 3 pertencem à Loja. O registro identifica quem fez a chamada, qual contrato permite esse uso e se há uma autorização válida.
Resultado de negócio: toda chamada cobrável às APIs DaaS é atribuída a um contrato e, quando houver, à autorização da controladora. A medição mensal chega à DEGN com as regras de negócio aplicadas e os totais conferidos com a origem, sem depender de buscas manuais. Consumo sem vínculo aparece numa lista diária para Segurança e DERC.
Três tipos de consumo
O painel precisa deixar claro quem consome pelo próprio contrato, quem tem autorização e quem está sem vínculo válido.
Consumo direto
O contratante consome pelo próprio contrato.
Exemplo: o INSS chamando as APIs contratadas com a sua credencial.
Apura contra a cota e o modelo de negócio do contrato vigente.
Consumo delegado
Órgão sem contrato, amparado por autorização.
Exemplo: AGU e CNJ autorizados pelo INSS. No futuro, bancas e concessionárias autorizadas pelo MDS no CadÚnico.
Exige autorização vigente e registrada, vincula ao contrato de referência e segue a regra comercial que a Dataprev definir.
Consumo sem vínculo
Credencial ativa sem contrato nem autorização.
É a pergunta de segurança de 15/10: quem está consumindo sem ter celebrado com a Dataprev?
Alerta Segurança e DERC e fica fora da apuração até a regularização.
Atores
Cliente
Contratante
Órgão com contrato API DaaS. Pode ser também controlador do dado, como o INSS.
Terceiro
Controladora do dado
Autoriza o acesso de terceiros às APIs com seus dados. Cada uma tem rito próprio; o CG SIRC, por exemplo, exige termo e ofício.
Terceiro
Órgão autorizado
Consome sem contrato direto, amparado por autorização vigente. Hoje AGU e CNJ; no futuro, bancas e concessionárias.
Dataprev
DERC · Relacionamento
Valida documentos e autorizações. Hoje vincula manualmente consumo a contrato.
Dataprev
Time de Produto API DaaS
Apura o consumo conforme o modelo de negócio e a proposta comercial.
Dataprev
DEGN
Cadastra o contrato, recebe a medição e encaminha ao faturamento no Protheus.
Dataprev
Infraestrutura e operação
Operam LDAP, Pronto, WSO2, Oracle e o runtime MuleSoft on-premises.
Dataprev
Segurança
Recebe e trata alertas de consumo sem vínculo. Papel proposto, a confirmar.
Fluxo principal em nove etapas
As três primeiras etapas preparam o cadastro. As demais acompanham as chamadas e o fechamento do período. Os alertas seguem em paralelo. Para o cliente, a chamada à API continua como hoje.
Contrato registradoInstrumento, CNPJ, APIs, pacote e vigência.
Autorização registradaControladora, beneficiário, escopo e evidência.
Credencial vinculadaLDAP e WSO2 ligados a CNPJ e contrato.
Chamada à APIGateway atual, sem mudança para o cliente.
Registro de usoMetadados sem payload, lidos em lote do WSO2.
CorrelaçãoDireto, delegado ou sem vínculo.
ApuraçãoRegra vigente do modelo de negócio.
Extrato e painelPor contrato, órgão e API.
Medição à DEGNFechamento reconciliado e auditável.
AlertasConsumo sem vínculo no MVP; vencimento e cota na E1.
01
GatilhoContrato celebrado na loja atual ou na nova Loja e cadastrado pela DEGN.
O sistema fazCria ou atualiza o contrato no registro com a referência do Protheus, APIs habilitadas, pacote e vigência.
Tecnologia
MuleSoft System APIOracleProtheusPlanilha controlada no MVP
02
GatilhoControladora autoriza por ofício, SEI, e-mail ou, quando aceitar, pela plataforma.
O sistema fazO DERC registra beneficiário, APIs, finalidade, vigência e evidência, por planilha controlada no MVP. Estados: aprovada, com ressalvas, reprovada, revogada.
Tecnologia
Carga validadaOracleTela · E3SEI · E3
03
GatilhoProvisionamento do acesso, hoje feito por chamado.
O sistema fazNo MVP, a credencial criada por chamado entra no registro, ligada ao CNPJ, ao contrato e, se houver, à autorização. Na E2, o provisionamento passa a ser automático.
Tecnologia
MuleSoft Process API · E2LDAPProntoWSO2
04
GatilhoO órgão chama a API com a sua credencial.
O sistema fazO gateway autentica e roteia como hoje. A apuração ocorre fora do caminho da chamada; o impacto da leitura é medido no pré-flight.
Tecnologia
WSO2APIs DaaS
05
GatilhoJanela de leitura, diária no MVP.
O sistema fazLê do WSO2 a credencial, a API, a data, a hora e o status de cada chamada, sem payload nem dado do cidadão, de forma idempotente.
Tecnologia
Analytics ou logs do WSO2MuleSoft batchFila on-prem · E4
06
GatilhoRegistro de uso lido.
O sistema fazEnriquece com o contrato e a autorização vigentes na data da chamada e classifica o consumo em direto, delegado ou sem vínculo.
Tecnologia
MuleSoft Process APIOracle
07
GatilhoFechamento do período.
O sistema fazAplica a versão vigente do modelo de negócio e grava a versão da regra e a memória de cálculo.
Tecnologia
MuleSoft batchDataWeaveOracle
08
GatilhoApuração concluída.
O sistema fazPublica visões por contrato, órgão, API e tipo de consumo no painel e gera o extrato em PDF e CSV.
Tecnologia
Painel OracleMuleSoft Experience API
09
GatilhoAprovação do Time de Produto.
O sistema fazGera a medição para a DEGN no formato atual, uma única vez por período e com reconciliação. No MVP, o arquivo segue após aprovação; na E1, o envio é agendado; na E4, passa a ser por API, depois da revitalização do Protheus.
Tecnologia
MuleSoft System APIProtheusDEGN
Exceções que o desenho precisa tratar
- Consumo sem vínculo: alerta à Segurança e ao DERC; fora da apuração até a regularização.
- Autorização vencida ou revogada: o consumo posterior passa a ser sem vínculo; aviso antes do vencimento a partir da E1.
- Credencial compartilhada entre órgãos: bloqueia a atribuição automática e segue para tratamento manual.
- Chamada com erro: o modelo de negócio define quais status são cobráveis.
- Registro duplicado ou atrasado: idempotência e reprocessamento do período, sem reescrever fechamento aprovado.
- Mudança de pacote no meio do período (caso SEFAZ-SP): apuração pela vigência de cada pacote, com regra a confirmar.
- Contestação da medição: memória de cálculo e trilha por registro de uso.
- Runtime indisponível: o lote é reprocessado a partir da origem, e a API do cliente continua respondendo.
Fronteira com a Loja, fase a fase do documento
Mapeamento das 5 fases do documento de 13/10 entre as duas frentes. O que é compartilhado deve ser construído uma vez, como System API no MuleSoft, e consumido pelas duas.
Fase 1 · Relacionamento
Interesse e orientaçãoPágina do produtoDocumentação técnica integrada
Fase 2 · Proposta
Formulário inicialAnexos em templatesProposta assinada automaticamenteAutorização da controladora no registro
Fase 3 · Contrato
Minuta e conferênciaAssinatura por tabela de competênciaEvidência PNCPEnvio do contrato ao ERP
Fase 4 · Provisionamento
Conta LDAP via Pronto · E2Credenciais e perfis · E2Liberação no WSO2 · E2Marco de disponibilidade e data ao ERP · E2Comunicação ao clienteOfício à controladora via SEI · E3
Fase 5 · Bilhetagem
Vínculo do contrato ao painelConsumo por contrato e autorizaçãoRegistro e acompanhamentoApuração pelo modelo de negócioMedição à DEGN
KPIs e métricas de sucesso
As fontes não trazem metas homologadas. A reconciliação retroativa do MVP mede a linha de base, e os alvos são fixados com DERC e DEGN no G3.
Cobertura de atribuição
chamadas cobráveis com contrato ou autorização ÷ chamadas cobráveisAlvo final de 100%, com as exceções tratadas e explicadas.
Fonte: uso classificadoConsumo sem vínculo
credenciais ativas sem contrato nem autorização vigenteCada caso com dono e prazo; nenhum sem explicação no fechamento.
Fonte: alertas e registroDivergência de reconciliação
|registros na origem − registros apurados| ÷ registros na origemPor período e por API. A divergência precisa ser explicada, não apenas pequena.
Fonte: origem WSO2 × registroFechamento da medição
dias úteis entre o fim do mês e o envio à DEGNLinha de base no MVP, comparada ao processo atual com planilha.
Fonte: trilha de fechamentoConsumo cobrável identificado
consumo cobrável apurado ÷ consumo faturado no processo atualSepara direto e delegado. É diagnóstico do valor declarado, não meta de receita.
Fonte: apuração × faturamentoProvisionamento no prazo
credenciais liberadas no prazo ÷ contratos aptosDo contrato com evidência PNCP até o marco “API disponível para consumo”.
Fonte: eventos de provisionamento04 · Solicitações e requisitos
O que foi pedido, por quem, e em qual entrega.
As solicitações vêm do documento de 13/10, da reunião de 15/10 e do workshop. Cada uma foi classificada entre o MVP, a Evolução 1 (ainda dentro dos 3 meses) e as evoluções posteriores, pelo critério aceito em 15/10: menor esforço e maior impacto primeiro, exceções raras em processo manual.
| Quem | Solicitação | Leitura crítica | Entrega |
|---|---|---|---|
| Rafael PortinhoDERC · 13 e 15/10 | Vincular o contrato ao painel de bilhetagem e associar o consumo ao contrato e à autorização da controladora. | Núcleo da demanda. O item 32 do documento foi ajustado em 15/10 para incluir a autorização. | MVP B01 a B08 |
| Rafael Portinho15/10 | Ver os órgãos que consomem sem contrato, amparados em autorização. | É controle de segurança, além de receita. Cresce com o CadÚnico. | MVP classificação e lista diária (B05, B10) |
| Rafael Portinho15/10 | API DaaS como produto único, aberto a novas APIs, com autorização configurável por API. | Coerente com o conceito de API Group. Exige marcar, por API, se há controladora e qual rito ela segue. | MVP no registro (B01, B02); vitrine na Loja (E3) |
| Rafael Portinho15/10 | Pacotes diferentes ao longo do tempo e combinações no mesmo contrato, como no caso SEFAZ-SP. | Hildegard propôs manter como exceção manual se for raro. Falta a frequência real. | MVP pacotes por vigência; E1 combinações, com ajuste manual até lá |
| Rafael e ThiagoDERC e DEME · 15/10 | Automatizar LDAP via Pronto, credenciais, liberação no WSO2 e comunicação ao cliente. | Hoje é manual e funciona. Depende de APIs do Pronto e da administração do WSO2. | E2 após os 3 meses (B11) |
| Rafael Portinho15/10 | Informar ao ERP a data de disponibilização com confirmação do cliente, dispensando o TEP. | Simplifica a operação; precisa do aceite da área de contratos. | E2 (B12) |
| José Francisco Neto (Chico)15/10 | Prever integração com o SEI dos órgãos para ofícios de autorização. | A maioria das controladoras não deve autorizar pela plataforma; o MTE é a exceção conhecida. | MVP guarda a evidência; E3 integra o SEI (B14) |
| Chico15/10 | Incluir a bilhetagem de IA, cobrada por tokens. | Rafael informou que a área de IA já tem bilhetador e modelo de negócio publicado. | Fora arquitetura preparada (B17) |
| Chico e Francisco Sales15/10 | Provar que a solução Salesforce bilheta melhor que o WSO2 e se integra a ele. | A prova útil é atribuição reconciliada, não substituição do gateway. | Prova de valor no pré-flight; MVP reconciliação retroativa |
| Hildegard BarbosaDEME · 15/10 | A ferramenta atende o padrão; exceções raras ficam manuais. | É o critério que faz o MVP caber em 3 meses sem perder rastreabilidade. | Aplicado no recorte do MVP |
| Michelle CostaSalesforce · 15/10 | Piloto com licenças de cortesia instalado na Dataprev. | Em on-prem, licença não basta: infraestrutura, acesso e operação vêm antes. No plano novo, o piloto é o próprio MVP. | Pré-flight (G0) antes do kickoff |
| Workshop07/10 | Relatório de consumo como primeira saída útil e alertas para contratos pequenos, de R$ 200 a R$ 300. | Entrega valor antes da automação total do faturamento. | MVP extrato (B07); E1 alertas de cota (B10) |
| Workshop07/10 | Piloto funcionando até o fim de outubro. | Não cabe em on-prem. Cabem a devolutiva de arquitetura em 22/10 e a prova de valor no início de novembro. | MVP em produção 8 semanas após o kickoff |
Requisitos funcionais
| ID | Requisito | Entrega | Critério de aceite resumido |
|---|---|---|---|
| B01 | Registro de contratos API DaaSInstrumento, CNPJ, modelo de negócio, APIs, pacotes por vigência e referência ao Protheus. | MVP | Cada contrato ativo tem uma única referência ao Protheus; o pacote vigente é consultável por data. |
| B02 | Registro de autorizaçõesControladora, beneficiário, APIs, finalidade, vigência, evidência e estado. | MVP | Nenhum consumo delegado é apurado sem autorização vigente com evidência. No MVP, o cadastro chega por planilha controlada. |
| B03 | Vínculo de credenciaisConta LDAP e aplicação no WSO2 ligadas a CNPJ, contrato e autorização. | MVP | Todas as credenciais ativas têm vínculo ou aparecem como sem vínculo. |
| B04 | Leitura do usoCredencial, API, data, hora e status, sem payload, lidos em lote do WSO2, de forma completa e idempotente. | MVP | A soma lida confere com a origem em dois meses fechados; divergências explicadas. |
| B05 | Classificação do consumoDireto, delegado autorizado ou sem vínculo. | MVP | Reproduz o caso INSS, AGU e CNJ validado pelo DERC. |
| B06 | Apuração pelo modelo de negócioUnidade cobrável, status cobráveis e pacotes por vigência no MVP. Combinações no mesmo contrato e mudança no meio do período na E1. | MVP E1 | Confere com o cálculo manual do Time de Produto nos meses reprocessados. |
| B07 | Extrato por contratoContratante, órgãos autorizados e consumo por API e período, em PDF e CSV. | MVP | DERC e DEGN aceitam o extrato como insumo de cobrança. |
| B08 | Publicação no painel OracleVisões por contrato, órgão, API e tipo de consumo. | MVP | O painel separa consumo direto, delegado e sem vínculo. |
| B09 | Medição para a DEGNArquivo no formato atual no MVP; envio agendado, com aprovação e reenvio controlado, na E1; API na E4. | MVP E1 | Uma medição por período, com trilha; a DEGN usa o arquivo sem retrabalho. |
| B10 | AlertasConsumo sem vínculo em lista diária no MVP. Vencimento de autorização ou contrato e cota perto do limite na E1. | MVP E1 | Consumo sem vínculo listado no dia útil seguinte. |
| B11 | Provisionamento automatizadoChamado no Pronto, conta LDAP, perfis, liberação no WSO2 e comunicação ao cliente. | E2 | Contrato com evidência PNCP gera credencial vinculada sem digitação manual. |
| B12 | Marco de disponibilidade“API disponível para consumo” com confirmação do cliente, informado ao ERP. | E2 | A data chega à DEGN com evidência do aceite, sem TEP. |
| B13 | API para a nova LojaContrato celebrado entra no registro; a Loja mostra status e consumo ao cliente e oferece o cadastro em tela. | E3 | Contrato celebrado na Loja aparece no registro sem planilha. |
| B14 | Integração com o SEIOfícios de autorização e comunicação à controladora. | E3 | Ofício recebido no SEI vira autorização pendente de validação. |
| B15 | Autorização pela plataformaAprovar, devolver com ressalvas ou reprovar, como no Crédito do Trabalhador (MTE). | E3 | Controladoras aderentes decidem sem ofício manual. Provável entrega da Loja. |
| B16 | Gateway MuleSoft para APIs novasFlex Gateway com contratos de aplicação e SLA. | E4 | Uma API nova operando com a mesma apuração e o mesmo registro. |
| B17 | Unidade de consumo de IATokens por meio do proxy de modelos apresentado no workshop. | Fora | Somente com caso de negócio próprio; a área de IA já tem bilhetador. |
Requisitos não funcionais
Soberania e privacidade
Cadastro, uso e apuração no data center, em Oracle. Uso registrado sem payload, sem CPF e sem dado do cidadão. Retenção definida com o encarregado de dados.
Fora do caminho da chamada
No MVP, a leitura é em lote e fica fora do caminho da chamada. A captura por eventos entra na E4. O impacto da leitura no WSO2 é medido no pré-flight.
Completude e auditoria
Reconciliação por período com a origem, reprocessamento idempotente e trilha imutável de autorizações, regras e apurações.
Capacidade
Dimensionada pelo pico real de chamadas, com teste de carga na S6, antes da entrada em produção.
Operação on-prem
Monitoramento, alertas e guias de operação no data center, sem depender de recursos exclusivos de nuvem para funcionar.
Segurança
mTLS entre componentes, cofre de segredos, menor privilégio, segregação de ambientes e trilha de acesso ao registro.
O documento de 13/10 repete o número 31 e salta os itens 18 e 19. Por isso os requisitos usam IDs próprios (B01 a B17).
05 · Core e evoluções
O que é alicerce entra no MVP. O resto pode esperar sem retrabalho.
Um item é alicerce quando atende a pelo menos um de quatro critérios. Os demais automatizam algo que hoje funciona à mão, dependem de sistemas ainda em mudança ou de decisões em aberto. Esses entram como evoluções, cada uma com aprovação própria.
Sustenta o resto
Sem ele, nenhuma evolução funciona. É o caso do registro de contratos, autorizações e credenciais.
Responde à pergunta do DERC
Quem consome, por qual contrato ou autorização, e quem consome sem vínculo.
Muda a medição da DEGN
Altera o número que vai para o faturamento e por isso precisa ser reconciliado com a origem.
É caro mudar depois
Modelo de dados, chaves de vínculo, versão da regra e trilha. Errar aqui gera retrabalho em todas as evoluções.
Alicerce: o que o MVP entrega
| ID | Componente | Por que é alicerce | Requisitos |
|---|---|---|---|
| C1 | Registro mestre com vigência | Contratos, pacotes, autorizações e credenciais com início e fim. Todas as evoluções leem daqui. | B01, B02, B03 |
| C2 | Leitura do uso em lote | Sem o uso completo não há apuração. Ler em lote evita depender de um broker novo nos 3 meses. | B04 |
| C3 | Classificação do consumo | Direto, delegado ou sem vínculo: é a pergunta de 15/10. | B05 |
| C4 | Apuração com regra versionada | O modelo de cobrança já mudou quatro vezes. Cada apuração grava a versão da regra usada. | B06 |
| C5 | Extrato e painel | Primeira saída útil pedida no workshop, publicada no painel que já existe. | B07, B08 |
| C6 | Arquivo de medição da DEGN | Substitui a montagem manual da planilha, no formato que a DEGN já recebe. | B09 |
| C7 | Lista de consumo sem vínculo | Controle de segurança de custo baixo, porque sai da própria classificação. | B10 |
| C8 | Reconciliação e trilha | Sem conferência com a origem, a medição nova não substitui a atual. | Não funcional |
| C9 | Operação mínima on-prem | Pipeline, monitoramento e guia de operação para a Dataprev sustentar o que entrou em produção. | Não funcional |
Decisões de fundação, que precisam estar certas já no MVP
- Modelo de dados com vigência em contratos, pacotes e autorizações, para que pacotes ao longo do tempo não exijam refazer o registro.
- Chave de vínculo única e auditável entre credencial, CNPJ, contrato e autorização.
- Regra de apuração versionada, aplicada pela data da chamada.
- Reprocessamento idempotente por período, sem reescrever fechamento aprovado.
- Especificação da API de consulta publicada desde o MVP, para a nova Loja consumir na E3 sem retrabalho.
- Uso registrado sem payload nem dado do cidadão, como regra de LGPD.
O que fica manual durante o MVP
São processos que já funcionam hoje, com volume baixo. Mantê-los manuais por alguns meses custa menos do que automatizá-los dentro dos 3 meses.
| Processo | Durante o MVP | Automatiza em |
|---|---|---|
| Cadastro de contratos e autorizações | Planilha controlada, validada na carga, com a evidência anexada ao registro. | E3 com a nova Loja, sem construir tela descartável |
| Provisionamento de acesso | Chamado no Pronto, como hoje; a credencial criada entra na planilha controlada. | E2 |
| Envio da medição à DEGN | Arquivo gerado pelo MVP e enviado após aprovação do Time de Produto. | E1 |
| Combinações de pacotes no mesmo contrato | Ajuste manual registrado, com justificativa. | E1 |
| Alertas de vencimento e de cota | Consulta no painel. | E1 |
| Ofícios das controladoras | Recebidos como hoje; o registro guarda a evidência. | E3 com o SEI |
Evoluções faseadas
Medição assistida
Alertas de vencimento e de cota, pacotes combinados e mudança no meio do período, envio agendado à DEGN, primeiro ciclo ao vivo em paralelo e transferência à Dataprev.
ValorA DEGN adota a medição nova.
Provisionamento automatizado
Pronto, LDAP, credenciais, liberação no WSO2, comunicação ao cliente e marco de disponibilidade ao ERP, sem TEP.
ValorContrato vira credencial vinculada sem digitação.
Loja e canais
Contrato celebrado na Loja entra no registro, o cliente vê o consumo, o DERC cadastra em tela, o SEI traz os ofícios e controladoras aderentes autorizam pela plataforma.
ValorFim da planilha controlada.
Tempo real e APIs novas
Captura por eventos em fila on-prem, alertas no mesmo minuto, Flex Gateway para APIs novas como a do CadÚnico e Protheus por API depois da revitalização.
ValorControle de cota em tempo real.
Fora do plano: bilhetagem de IA por tokens. A área de IA já tem bilhetador; o tema só entra com caso de negócio próprio.
06 · MuleSoft on-premises
Em 3 meses, o ambiente on-prem precisa estar pronto antes do kickoff.
Com o runtime no data center da Dataprev, o dado de consumo não sai do perímetro, o que é coerente com a soberania exigida pela empresa. Em troca, infraestrutura, operação, capacidade e parte dos recursos que existem na nuvem passam a ser responsabilidade da Dataprev e do projeto.
Plano de controle
Híbrido: runtimes nos servidores da Dataprev, gerenciados pelo Anypoint em nuvem; metadados e métricas operacionais trafegam para fora. PCE: plano de controle instalado no data center, com o conjunto de recursos da versão contratada. O modelo vigente para este caso não consta nas fontes.
Capacidade
O pacote MuleSoft da UNA inclui 14 vCores de produção (Titanium), 8 de pré-produção, API Manager, Governance e Flex Gateway com 100 milhões de chamadas. UNA e PAT já usam essa base, e o PAT sinalizou preocupação com o barramento compartilhado. A reserva de vCores precisa sair no pré-flight, e o teste de carga com volume real acontece na S6, antes da produção.
Gateway
Colocar o Flex Gateway na frente das APIs DaaS consome o pacote de chamadas licenciado e exige migrar credenciais. Sem o volume anual das APIs, não se sabe se cabe. No MVP e nas evoluções E1 a E3, o WSO2 continua no caminho da chamada.
Mensagens e estado no data center
CloudHub, Anypoint MQ e Object Store v2 ficam fora do desenho, porque tirariam mensagens ou estado do perímetro. Persistência e cache usam Oracle e o object store persistente do próprio runtime. O MVP lê o uso em lote e não depende de broker; a fila on-prem só entra na E4.
Operação e governança
Em 04/10 ainda não havia posição sobre como a Dataprev absorverá a governança do MuleSoft. Em 08/10, acesso aos servidores, treinamento, suporte e responsáveis pela operação ficaram pendentes. Sem RACI assinado, o MVP não entra em produção.
Acesso do time de PS
VPN, contas nominais, ambientes, rede até WSO2 e Oracle, certificados e janela de mudança. LDAP e Pronto só entram na E2. Em on-prem, isso costuma ocupar as primeiras semanas. Em 3 meses não há folga para isso: precisa estar resolvido no pré-flight, antes do kickoff.
Checklist on-prem por prazo
Antes do kickoff · pré-flight (G0)
- Modelo de plano de controle e versão do runtime confirmados.
- vCores reservados para a bilhetagem em pré-produção e produção.
- Contas, VPN e perfis do time de PS; cofre de credenciais.
- Amostra do uso no WSO2, sem dado pessoal, e confirmação de dois meses de histórico.
- Esquema Oracle e DBA responsável pelo registro e pelo painel.
- RACI de operação, monitoramento e suporte do runtime.
- Consentimento por escrito para uso de IA no projeto.
- Licença de cortesia, se houver: itens, prazo e aprovação.
Até a S3 · pré-produção
- Servidores ou cluster de pré-produção com o runtime instalado.
- Rede liberada até WSO2, Oracle e painel.
- Pipeline de implantação no fluxo interno de aprovação.
Até a S7 · produção
- Produção dimensionada pelo teste de carga da S6.
- Janela de mudança reservada para a S8.
- Requisitos de LGPD e retenção do uso aprovados.
Cortesia não resolve infraestrutura. O workshop discutiu uma cortesia temporária de MuleSoft on-prem, com prazo entre dois e seis meses conforme o registro consultado. Ela cobre licença. Servidores, rede, operação e mudança continuam sendo da Dataprev e precisam estar prontos nos prazos ao lado. O MVP não depende de broker, LDAP, Pronto nem Protheus; esses acessos só são necessários nas evoluções.
07 · Arquitetura proposta
O WSO2 atende às chamadas. O MuleSoft organiza a bilhetagem.
Proposta lógica para discussão e validação com a Dataprev. O WSO2 continua atendendo às APIs. Em um fluxo separado, o MuleSoft lê o uso em lote, consulta contratos e autorizações, aplica as regras de apuração e publica o resultado no painel Oracle existente. A captura por eventos (E4) e a nova Loja (E3) entram como evoluções, sem mudar o registro nem a apuração.
Da chamada à apuração, dentro do data center
As setas mostram dois caminhos: a chamada segue para a API; o registro de uso vai, em lote, para a bilhetagem. Os números remetem à explicação abaixo.
Chamada e dados
Processamento MuleSoft
Registro e painel Oracle
Componente a definir
- 5 · Sistemas de apoio
- Protheus e DEGN recebem a medição, por arquivo no MVP e por API na E4. No MVP, uma planilha controlada alimenta contratos e autorizações. LDAP e Pronto entram com o provisionamento automatizado, na E2. A integração com o SEI fica para a E3.
- 6 e 7 · Equipes Dataprev
- O DERC mantém as autorizações pela planilha controlada no MVP e por tela na E3. Produto e DEGN acompanham extratos e apuração no painel. Segurança recebe a lista diária de consumo sem vínculo. A solução registra as evidências e mantém a trilha dessas ações.
- 8 · Nova Loja e novas APIsE3 e E4
- A nova Loja Salesforce envia os contratos e consulta o consumo pela camada Experience. O Flex Gateway é uma opção para APIs novas, sujeita à validação de capacidade e licença. Ter um consumidor autorizado não exige, por si só, trocar o gateway da API.
- 9 · Gestão do ambienteDecidir no G0
- O plano de controle Anypoint pode ficar na nuvem, no modelo híbrido, ou no data center, com PCE. Essa escolha ainda está aberta. A proposta limita o envio externo a informações operacionais autorizadas; contratos, registros de uso e apuração permanecem na Dataprev.
- 1Chamada à API. O contratante ou órgão autorizado usa sua credencial no WSO2. O gateway atende às APIs DaaS como hoje.
- 2Captura do uso. No MVP, o MuleSoft lê em lote o analytics ou os logs do WSO2, sem o conteúdo da chamada (payload). A fonte exata é confirmada no pré-flight. Na E4, a leitura passa a ser por fila no data center, quase em tempo real.
- 3Consulta e registro. O MuleSoft consulta contratos, autorizações e credenciais no registro Oracle e grava o uso classificado e a apuração.
- 4Publicação dos resultados. O MuleSoft publica a apuração e o extrato no painel Oracle que já está em produção.
- 5Integrações de apoio. No MVP, arquivo de medição para a DEGN e carga validada de contratos. Provisionamento em LDAP, Pronto e WSO2 na E2; SEI na E3; Protheus por API na E4.
- 6Validação pelo DERC. A equipe mantém as autorizações pela planilha controlada no MVP e pela camada Experience na E3. As evidências ficam no registro Oracle.
- 7Acompanhamento. Produto e DEGN consultam extratos e apuração; Segurança acompanha os alertas de consumo sem vínculo.
- 8Integração com a nova Loja. Na E3, o contrato celebrado alimenta o registro e o cliente passa a consultar o consumo na Loja.
- 9Gestão do runtime. O plano de controle administra o ambiente. Sua localização depende da escolha entre híbrido e PCE.
Como as três camadas do MuleSoft se dividem
- Experience · acesso
- No MVP, entrega o extrato por contrato ao painel. Na E3, ganha o cadastro de autorizações em tela e atende à nova Loja.
- Process · regras
- Relaciona o uso ao contrato, classifica o consumo, aplica a regra de negócio e reconcilia os totais com a origem. A coordenação do provisionamento entra na E2.
- System · conexões
- No MVP, conecta o WSO2 (leitura em lote), o Oracle e a carga de contratos. LDAP e Pronto entram na E2, SEI na E3, fila e Protheus por API na E4.
Princípios do desenho
Protheus como referência do contrato
O Protheus continua sendo a fonte oficial do contrato. O registro guarda a visão operacional das APIs (credenciais, autorizações, pacotes) e referencia o ID do Protheus.
Origem reconciliável
Todo registro apurado é rastreável até a origem. Reprocessar um período produz o mesmo resultado e não reescreve fechamento aprovado.
Regra versionada
O modelo de negócio é aplicado pela vigência. Cada apuração grava a versão da regra usada, o que sustenta contestações e auditoria.
Opções avaliadas
| Opção | Como funciona | A favor | Contra | Leitura |
|---|---|---|---|---|
| A · Coexistência com WSO2recomendada | WSO2 segue como gateway; MuleSoft on-prem lê o uso, correlaciona, apura e publica. | Nenhuma migração de consumidor; ataca a causa; usa licenças já contratadas; cabe em 3 meses. | Depende da qualidade e da fonte de uso do WSO2. | MVP e evoluções |
| B · MuleSoft como gateway | Flex Gateway on-prem na frente das APIs DaaS, com contratos de aplicação e SLA. | Registro de uso sob controle do projeto; políticas nativas de cota. | Migração de credenciais e clientes; consome o pacote de 100 milhões de chamadas; risco operacional alto; não cabe em 3 meses. | APIs novas na E4 |
| C · Registro no Salesforce | Contratos e autorizações na org da nova Loja; consumo segue on-prem. | Interface pronta para o DERC; reaproveita a Frente 1. | Acopla o MVP à licença e ao cronograma da Loja; exige sincronização nos dois sentidos. | Avaliar na E3 |
08 · Plano em 3 meses
Prazo fixo, escopo variável. A Evolução 1 é a reserva do prazo.
O pré-flight acontece na pré-venda, sem horas de PS, e decide se o projeto começa. O MVP entra em produção na S8. A Evolução 1 ocupa as quatro semanas finais e absorve atrasos: se o MVP escorregar, ela encolhe, e a data de 3 meses não muda. As evoluções posteriores têm aprovação própria.
Pré-venda e prontidão
Prova de valor feita com vibe coding sobre dados sintéticos, escopo e intents rascunhados com o Scopezilla, Go/No-Go do Quantum Leap, consentimentos, acessos, amostra do WSO2 e pedidos de ambiente.
SaídaG0 · kickoff aprovado.
Fundação em produção
Registro mestre, leitura em lote, classificação, apuração versionada, extrato no painel, arquivo da DEGN e lista de consumo sem vínculo, para todas as APIs DaaS. Dois meses já faturados são reprocessados e reconciliados antes do go-live.
SaídaG4 · MVP em produção.
Medição assistida
Alertas de vencimento e de cota, pacotes combinados, envio agendado à DEGN, primeiro ciclo ao vivo em paralelo e transferência ao time de integração da Dataprev.
SaídaG5 · DEGN aceita a medição nova.
Evoluções por módulo
E2 provisionamento, E3 Loja e canais, E4 tempo real e APIs novas. Cada módulo tem caso de negócio, estimativa e aceite próprios.
SaídaAceite por módulo.
Como o prazo cai de 34 para 12 semanas
Só a fundação nos 3 meses
O MVP leva apenas o que é alicerce. Provisionamento, nova Loja, SEI e tempo real saem do prazo e viram módulos.
O MVP é o piloto
Não há piloto separado em pré-produção. A primeira entrega já vai para produção, com reconciliação antes do go-live.
Paralelo retroativo
Em vez de esperar dois ciclos de faturamento ao vivo, o MVP reprocessa dois meses já faturados e compara com a medição atual. Depende do histórico do WSO2.
Leitura em lote
Sem broker novo no MVP. A dependência de infraestrutura fica restrita a runtime, Oracle e rede.
Quantum Leap
Agentes geram fluxos, DataWeave, testes, scripts e documentação; o time revisa e aprova. Cerca de 32% menos horas e MVP em 8 semanas, não 12.
Pré-flight na pré-venda
Acessos, consentimentos, amostra de dados e pedidos de ambiente saem antes do kickoff. Em on-prem, é isso que costuma consumir o primeiro mês.
O que não comprime: provisão de servidores, janelas de mudança, curadoria dos contratos, decisões de regra e aceite da DEGN. Se a produção on-prem não estiver pronta na S7, o go-live do MVP desliza junto, e a Evolução 1 encolhe na mesma medida.
09 · Quantum Leap e IA
Agentes constroem. O time define, revisa e responde pelo resultado.
Quantum Leap é o playbook de execução de Professional Services para entrega AI-native: agentes fazem a construção, e as pessoas definem intents, validam o que foi gerado e governam o que não pode ser automatizado. Ele opera dentro das fases e dos gates do MVG, e MuleSoft está no escopo do programa. Claude Code (CLI), Cursor e vibe coding entram como ferramentas, cada uma com uso definido.
Intents no lugar de histórias
Os requisitos do MVP e da E1 viram cerca de 15 intents, cada um com resultado, restrições, critério de pronto e limites. É o que o agente executa e o que a Dataprev aceita.
Repositório de engajamento
Intent ledger, decisões e progresso ficam no repositório. O hash de escopo e a detecção de desvio protegem o MVP: pedido novo entra como evolução, não é absorvido.
Demonstração diária
Todo dia de build termina com software funcionando para o PO do DERC. O caso INSS, AGU e CNJ classificado aparece já na S3, com dados sintéticos.
Uma pessoa aprova cada artefato
Aprovar, refinar, rejeitar ou escalar. Código gerado passa pelos mesmos testes, revisões e pipeline. “O agente construiu” não é defesa.
Onde a IA entra neste projeto
| Atividade | Ferramenta | O que a IA faz | O que fica com a pessoa |
|---|---|---|---|
| Escopo e intentspré-flight | Scopezilla, NotebookLM, Claude | Minera as transcrições de 07, 08 e 15/10 e o documento de 13/10; rascunha escopo, riscos e intents. O Scopezilla é ferramenta de pré-venda. | BSA e Intent Architect fecham escopo, critérios de aceite e limites. |
| Prova de valorpré-flight | Cursor, vibe coding | Protótipo navegável com dados sintéticos: os três tipos de consumo, a classificação e um extrato. | Marcelo valida a narrativa. O protótipo não vai para produção. |
| APIs e fluxos MuleSoftS1 a S8 | Claude Code, Cursor | Especificações OAS, fluxos, DataWeave, conectores e pipeline de build. | Agent Orchestrator revisa padrões API-led, segurança e desempenho. |
| Registro Oracle e cargaS1 a S4 | Claude Code | DDL, visões do painel e scripts de saneamento e cruzamento das planilhas de contratos. | DBA da Dataprev aprova; o DERC faz a curadoria dos vínculos. |
| Testes e reconciliaçãoS3 a S12 | Claude Code | MUnit e casos de teste a partir dos intents, gerador de dados sintéticos e scripts de comparação entre origem e apuração. | Logic Validator classifica as divergências; a DEGN aceita. |
| Operação e documentaçãotodo o projeto | Claude Code, Cursor | Guias de operação, registros de decisão, notas de release e status semanal a partir do repositório. | Program Lead e especialista on-prem validam. |
Vibe coding serve para protótipos, dados sintéticos e ferramentas internas de conferência. O que vai para o ambiente da Dataprev passa por revisão, MUnit e pipeline, como qualquer outro código.
Onde a IA não acelera
- Provisão de servidores, rede e janelas de mudança no data center.
- VPN, contas e acessos do time.
- Curadoria de contratos e autorizações pelo DERC.
- Decisões comerciais, como a cobrança do consumo delegado.
- Aceite da DEGN e aprovações de Segurança e LGPD.
- Ciclo de faturamento ao vivo, que segue o calendário do mês.
Por isso o plano quase não reduz as horas dessas frentes.
Condições para operar em Quantum Leap
- Consentimento por escrito da Dataprev para uso de IA no projeto, conduzido pelo Program Lead. Restrições de setor público sinalizadas logo no início.
- Dados reais não entram nas ferramentas de IA: os agentes trabalham com código, especificações e dados sintéticos ou anonimizados. Contratos e uso ficam no perímetro.
- Claude Code somente na versão hospedada em AWS Bedrock, como exige o programa.
- Patrocinador na demonstração diária, de 30 a 45 minutos ao fim do dia, e decisões da Dataprev em 24 a 48 horas.
- Escopo do MVP fechado no início do build, com controle de mudança.
- Elegibilidade: o Quantum Leap está em piloto, com engajamentos selecionados. Confirmar com o programa se a Dataprev entra.
- Time com as oito verificações de prontidão feitas, incluindo a licença do MeshMesh, que leva dias.
Ganho usado no plano: a meta do programa é reduzir de 35% a 40% o tempo até o valor, e os ganhos ainda estão em validação no piloto. Este plano aplica cerca de 32% nas horas e 33% no calendário do MVP, concentrados nas frentes de construção, teste e documentação. O build do MVP, de cerca de 6 semanas, fica no limite inferior da faixa indicada pelo programa (6 a 24 semanas); por isso os intents começam no pré-flight.
Plano B: se o pré-flight reprovar o modelo (sem consentimento, decisões acima de 48 horas ou patrocinador ausente das demonstrações), o projeto segue AI-Augmented, com as mesmas ferramentas e revisões semanais. O MVP passa para a S10, e a Evolução 1 se reduz a alertas e envio à DEGN. Os cenários estão na estimativa.
10 · Professional Services e recursos
Pod de quatro pessoas no MVP. Duas a três na Evolução 1.
Levantamento de PS para os 3 meses, com os papéis do Quantum Leap. As horas são de PS MuleSoft e Salesforce; o esforço da Dataprev e de terceiros fica fora delas.
Quantum Leap com o time Dataprev junto
PS conduz o MVP e a E1 em modelo AI-native, se o pré-flight aprovar. O time de integração da Dataprev acompanha desde a S0 e assume a sustentação na E1. Nas evoluções posteriores, os três modelos do workshop (PS integral, PS com integrador, integrador com acompanhamento) podem ser testados por módulo.
Financiamento
O workshop citou bolsões de serviços profissionais pré-aprovados por linha de serviço e contrato. Confirmar se cobrem esta frente antes de abrir nova contratação. O Quantum Leap prevê preço fixo por resultado; confirmar a linguagem de SOW disponível antes de oferecer esse formato.
Quem conduz até o SOW
Marcelo Silva desenha a arquitetura do MVP, com Elvis Rocha na volta das férias. Michelle Costa conduz a relação e a agenda com Francisco Sales. Juliane Lopes consolida horas, volumetria e o rascunho dos intents.
| Papel Quantum Leap | Papel tradicional | Responsabilidade | MVP | E1 | Total |
|---|---|---|---|---|---|
| PL · Program Lead | Engagement Manager | Compromisso de entrega, gates, consentimentos e relação com o patrocinador. | 110 h | 40 h | 150 h |
| IA · Intent Architect | MuleSoft Solution Architect | Autor dos intents, arquitetura, segurança e cadeia de validação. | 230 h | 60 h | 290 h |
| AO · Agent Orchestrator | Technical Architect MuleSoft | Conduz os agentes, revisa o código gerado e lidera a parte técnica. | 290 h | 90 h | 380 h |
| Trusted Guide de integração | Integration Developer MuleSoft | Dirige e revisa a construção de APIs, lote, apuração e carga. | 220 h | 80 h | 300 h |
| Especialista de plataforma on-prem | Mesmo papel | Runtime, pipeline, observabilidade e hardening com a infraestrutura da Dataprev. | 160 h | 20 h | 180 h |
| BSA · regras de bilhetagem | Mesmo papel | Modelo de negócio, autorizações, exceções e critérios de aceite dos intents. | 130 h | 30 h | 160 h |
| LV · Logic Validator | QA e reconciliação | Testes, reconciliação retroativa e evidências ligadas aos intents. | 140 h | 40 h | 180 h |
| Total provável | 1.280 h | 360 h | 1.640 h |
MVP
≈4 FTE em 8 semanas
1.280 horas, considerando 40 horas por semana. Arquitetura e plataforma em tempo parcial; orquestração e integração em dedicação integral.
Evolução 1
≈2 a 3 FTE em 4 semanas
360 horas. O pico está no ciclo ao vivo e na transferência à Dataprev.
Evoluções posteriores
Por módulo
Cada evolução com pod próprio, dimensionado no caso de negócio.
Recursos da Dataprev, fora das horas de PS
| Papel Dataprev | Dedicação estimada | Quando |
|---|---|---|
| PO da bilhetagem (DERC) | 50% e demonstração diária | S0 a S12, com decisão em até 48 horas. |
| Patrocinador executivo | Demonstrações diárias; semanais no Plano B | Todo o projeto e todos os gates. |
| Time de Produto API DaaS | Sob demanda, com SLA de decisão | Regra v1 até a S2; validação da apuração da S5 à S7. |
| DEGN | Validações nos marcos | Reconciliação retroativa (S6 e S7) e ciclo ao vivo (S8 a S12). |
| Infraestrutura e operação MuleSoft on-prem | Uma pessoa, 50% a 70% | Do pré-flight à S8: pré-produção até a S3 e produção até a S7. |
| Administração do WSO2 | 30% | Do pré-flight à S5: amostra, interface de leitura e histórico. |
| DBA Oracle e responsável pelo painel | 30% | S0 a S8: registro, visões e carga. |
| Segurança e LGPD | Gates | Pré-flight (acessos e consentimento de IA), G1 e G4. |
| Time de integração Dataprev | Uma a duas pessoas | Desde a S0, para assumir a sustentação na E1. |
Essas dedicações são premissas para executar o plano. O dimensionamento da equipe Dataprev ainda precisa ser validado.
11 · Estimativa
De 2.810 para 1.640 horas. Escopo e modo de entrega explicam a diferença.
A estimativa soma o esforço de cada frente de trabalho, em horas de PS, primeiro no modelo tradicional e depois com o fator do Quantum Leap. O cenário base supõe dados utilizáveis do WSO2, ambiente pronto e decisões rápidas. O conservador supõe ajustes na leitura, regras pouco claras e menor disponibilidade dos especialistas.
Da estimativa anterior ao plano de 3 meses
Horas prováveis de PS. As barras laranja são reduções; as demais, totais.
| Entrega | Tradicional | Base | Provável | Conservador | Prazo |
|---|---|---|---|---|---|
| MVP · fundação | 1.820 h | 960 h | 1.280 h | 2.000 h | S0 a S8 |
| Evolução 1 · medição assistida | 590 h | 260 h | 360 h | 560 h | S8 a S12 |
| Projeto em 3 meses | 2.410 h | 1.220 h | 1.640 h | 2.560 h | 12 semanas |
| Evoluções posteriores (E2 a E4) | Não estimado | 650 h | 950 h | 1.540 h | Por módulo |
Base, provável e conservador já consideram o Quantum Leap. A coluna tradicional mostra o provável sem agentes na construção.
Cenários de entrega
| Cenário | Condição | MVP em produção | Escopo nos 3 meses | Horas prováveis |
|---|---|---|---|---|
| AI-native · Quantum Leaprecomendado | Pré-flight aprovado: consentimento, patrocinador nas demonstrações e decisões em 48 horas. | S8 | MVP e Evolução 1 completa | 1.640 h |
| AI-Augmented · Plano B | Mesmas ferramentas, sem o modelo completo; revisões semanais. | S10 | MVP e parte da E1 (alertas e envio à DEGN) | ≈1.800 h |
| Tradicional | Sem agentes na construção. | S12 | Só o MVP, sem reserva de prazo | 1.820 h |
Base dos dois projetos: Loja 2.700 h + DaaS 1.640 h = 4.340 h de referência para os pacotes atuais independentes. Não são substitutos de mesmo escopo. A conexão técnica E3 acrescenta 130 h centrais na simulação; a expansão comercial da Loja permanece à parte. Memória única do de/para.
Se Billing for escolhido: até 175 h centrais de apuração DaaS são potencialmente substituíveis, somente antes de executar e após prova de aderência. Medição, correlação e operação permanecem. A ingestão de 300 h centrais já está no B2 simulado: definir quem executa sem somar novamente no Mule. Nenhuma hora de ERP ou provisionamento sai automaticamente da Loja.
Frentes de trabalho do MVP
| Frente de trabalho | Tradicional | Base | Provável | Conservador | O que a IA acelera |
|---|
Frentes de trabalho da Evolução 1
| Frente de trabalho | Tradicional | Base | Provável | Conservador | O que a IA acelera |
|---|
Evoluções posteriores, por módulo
| Módulo | Base | Provável | Conservador |
|---|
Premissas, exclusões e gatilhos de reestimativa
Premissas
- Pré-flight concluído antes do kickoff (G0).
- WSO2 com interface de leitura utilizável e pelo menos dois meses de histórico.
- Regra de apuração v1 decidida até a S2.
- Registro em Oracle da Dataprev, com DBA disponível.
- Medição por arquivo, no formato atual da DEGN.
- vCores reservados no pré-flight.
- Decisões da Dataprev em até 48 horas.
- Consentimento de IA e modelo Quantum Leap aprovados.
Exclusões
- Licenças, infraestrutura e operação contínua.
- Troca do WSO2 nas APIs atuais.
- Faturamento, boleto e cobrança, que seguem no Protheus e na DEGN.
- Jornada de contratação (fases 1 a 3), que pertence à Loja.
- Saneamento ilimitado de contratos e autorizações antigos.
- Evoluções E2 a E4, estimadas à parte.
- Bilhetagem de IA por tokens.
Reestimar se
- O volume exigir cluster novo ou expansão relevante de vCores.
- A origem WSO2 for inutilizável e o gateway precisar ser instrumentado.
- O PCE precisar ser instalado do zero para este caso.
- O histórico do WSO2 não permitir o paralelo retroativo.
- O consumo delegado exigir contratos próprios ou novo rito jurídico.
- O modelo Quantum Leap não for aprovado (ver cenários).
12 · Cronograma
MVP na semana 8. Projeto encerrado na semana 12.
Escala em semanas a partir do kickoff (S0), cenário provável com Quantum Leap. O pré-flight ocupa as três semanas anteriores, na pré-venda. As evoluções posteriores aparecem hachuradas e dependem de aprovação própria. Se o kickoff for em novembro, o recesso de fim de ano cai no meio do build: ou o calendário congela no recesso, contando 12 semanas úteis, ou o kickoff passa para janeiro.
| Gate | Quando | Decisão de saída |
|---|---|---|
| G0 · Pré-flight aprovado | Antes da S0 | Go/No-Go do Quantum Leap, consentimentos, acessos, amostra do WSO2, vCores reservados e pedidos de ambiente feitos. |
| G1 · Intents e arquitetura | S2 | Intent ledger do MVP aprovado, arquitetura assinada e regra de apuração v1 decidida. |
| G2 · Build aceito | S6 | Todos os intents do MVP demonstrados e aceitos pelo PO; teste de carga feito. |
| G3 · UAT e reconciliação | S7 | Dois meses já faturados reprocessados, divergências explicadas e UAT confirmado. |
| G4 · MVP em produção | S8 | Go/No-Go formal, notas de release e lista de consumo sem vínculo rodando. |
| G5 · Fim do projeto | S12 | E1 em produção, ciclo ao vivo aceito pela DEGN e pacote de transferência aceito. |
Os gates seguem as fases do MVG: pré-flight, preparação e desenho, build, teste, implantação e adoção. No Quantum Leap, a UAT confirma o que as demonstrações diárias já mostraram; um defeito de desenho que só apareça na UAT é tratado como falha do método.
13 · Decisões e próximos passos
Dezessete decisões. A maioria precisa sair antes do kickoff.
Plataforma on-prem · até o kickoff
- O MuleSoft deste caso usa plano de controle em nuvem (híbrido) ou PCE? Qual versão do runtime e quais ambientes?
- Quem opera, monitora e sustenta o runtime on-prem, e quem governa o MuleSoft na Dataprev?
- Quantos vCores dos 14 de produção e 8 de pré-produção podem ser reservados, e qual é o volume mensal e o pico das APIs DaaS?
- A pré-produção fica pronta até a S3 e a produção até a S7? Quem executa as mudanças?
Dados e fontes · até o kickoff
- Qual é a versão do WSO2 e qual interface de leitura está disponível? A contagem na origem está correta?
- Quantos meses de histórico o WSO2 guarda, e a DEGN tem o faturado desses meses para o paralelo retroativo?
- Qual é o modelo de dados do painel Oracle e quem o mantém?
- Enquanto a nova Loja não existir, qual é a fonte de contratos (Protheus, planilha diária ou ServiceNow), e onde estão as autorizações vigentes e suas evidências?
- Cada credencial pertence a um único CNPJ, ou há credenciais compartilhadas?
Regras de negócio · até a S2
- Qual é a unidade cobrável e quais status de resposta são cobrados?
- A quem se fatura o consumo delegado, e há limite por autorização? Até a decisão, o MVP mantém a cobrança atual.
- Como se apura a mudança de pacote no meio do período?
- Qual divergência é aceitável no G3, e em que formato a DEGN recebe a medição hoje?
Quantum Leap e contratação · antes do SOW
- A Dataprev autoriza por escrito o uso de ferramentas de IA no projeto, com dados reais mantidos no perímetro?
- Quem é o patrocinador nas demonstrações diárias, e qual é o SLA de decisão?
- O programa Quantum Leap aceita a Dataprev como engajamento do piloto, ou o projeto segue AI-Augmented?
- Haverá cortesia de licença? O PS será financiado por bolsão existente ou por nova contratação, e o preço fixo por resultado é uma opção?
Próximos passos com data
16/10 · 14h30
Recap interno de bilhetagem (Michelle, Juliane e Marcelo): alinhar esta leitura, o plano de 3 meses e a posição frente à Opção B da Loja.
19 ou 20/10
Luiz Gabriel retoma com Yudi a proposta da Loja: deixar explícito que a medição de API está nesta frente.
Até 22/10 · proposto
Rascunho do escopo e dos intents do MVP com o Scopezilla, a partir das transcrições de 07, 08 e 15/10 e do documento de 13/10 (Juliane).
22/10 · quinta
Devolutiva da arquitetura do MVP (Marcelo; Elvis em férias), com o plano de 3 meses e o checklist de pré-flight.
Até 24/10 · proposto
Confirmar com o programa Quantum Leap a elegibilidade da Dataprev e definir o Program Lead que conduz os consentimentos.
A agendar
Reunião com Francisco Sales e Rafael Portinho (Michelle): apresentar o plano de 3 meses e pedir as respostas de plataforma, dados e patrocínio.
Início de novembro
Prova de valor concluída e decisão sobre kickoff, cortesia e financiamento do PS.
14 · Rastreabilidade
Fontes e limites desta análise.
Limites da leitura: o resumo automático do Granola atribui a próxima agenda a Saulo; a transcrição e o e-mail indicam Francisco Sales, a confirmar. R$ 100 milhões por ano, 2.200 contratos e 23 APIs são falas do workshop, não dados auditados. O volume de chamadas não aparece em nenhuma fonte. Os ganhos do Quantum Leap são metas de um programa ainda em piloto, não resultados medidos neste tipo de projeto; por isso o plano usa um fator conservador e o Plano B mostra o efeito sem ele. A estimativa deve ser recalibrada no G1 (S2), sem conversão em preço sem rate card e sempre separando PS, esforço da Dataprev, licenças e terceiros.