Objetivo
Garantir que todo produto tenha cadastro completo no ERP — tanto dados declarativos (vindos do Dir. Científico) quanto dados validados (vindos da operação) — antes de ser liberado para venda. Este processo é o mecanismo que transforma informação desestruturada em cadastro estruturado.
Posição no fluxo
Este processo é transversal — pode ser acionado a qualquer momento, por qualquer área. Ele alimenta a Entrada de Produto no Portfólio (fases 2-4 dependem da completude) e é retroalimentado por ocorrências de cadastro-incompleto vindas do dia a dia.
Quando acontece
Três gatilhos principais: evento anunciado (produtos precisam estar cadastrados antes), produto novo decidido pelo Dir. Científico, ou flag de incompletude levantado por qualquer área (Atendente não achou dado, Operação contestou cadastro, Farm. Triagista encontrou inconsistência). O processo também é disparado organicamente — cada vez que alguém precisa de um dado que não está no cadastro, esse dado é candidato a ser perseguido.
Dois tipos de dados
O cadastro de produto no ERP tem duas categorias com fontes e fluxos diferentes. Entender essa distinção é fundamental para saber quem perseguir quando algo falta.
Dados declarativos
Vêm do Dir. Científico ou por inferência da Interface ERP. Podem ser afirmados sem teste. A Interface é quem extrai, estrutura e registra.
Campos: composição pretendida, indicação principal, público-alvo (profissional e paciente), tratamentos associados, produtos similares/substitutos no portfólio, benefícios-chave, contraindicações conhecidas, contexto de apresentação, evento associado, posicionamento, forma farmacêutica pretendida, cold chain (declarado).
Dados validados
Dependem de teste ou processo da operação. Só existem após interação real com a matéria-prima. Farm. Qualidade é quem produz; Interface é quem registra no ERP.
Campos: fornecedor aprovado, lote disponível, orientações farmacotécnicas (solubilidade, estabilidade, pH), concentração viável confirmada, condições de armazenamento confirmadas, validade real, adaptações feitas.
Como funciona
Fase 1 — Detecção de incompletude
Alguém percebe que falta dado. Pode ser a Interface (ao receber input do Dir. Científico), o Atendente (ao tentar vender e não encontrar informação), ou a Operação (ao tentar produzir e encontrar inconsistência).
- Quem detecta: Qualquer papel
- O que faz: Sinaliza a Interface ERP com o que falta (campo específico, não “está incompleto”). A Interface registra o flag de incompletude.
- Entregável: Flag de incompletude com campos faltantes identificados.
Fase 2 — Decomposição e diagnóstico
A Interface recebe o input disponível (do Dir. Científico, de ocorrências, de perguntas do Atendimento), decompõe em dados estruturados, e mapeia contra os campos esperados.
- Quem executa: Interface ERP
- O que faz: Extrai dados do input (qualquer formato: áudio, PDF, conversa). Compara com a lista de campos esperados. Produz diagnóstico: o que já tem, o que veio agora, o que falta.
- Entregável: Lista de campos preenchidos vs. faltantes.
Fase 3 — Perseguição de dados faltantes
A Interface volta ao Dir. Científico com perguntas específicas. Nunca “me fala mais”, sempre “falta público-alvo e contraindicações — quem é o paciente ideal e quando NÃO usar?“. O Dir. Científico responde desestruturado (áudio, mensagem, conversa). A Interface estrutura. Repete até completar.
Em paralelo, se o produto é novo e precisa de dados validados, Farm. Qualidade testa a matéria-prima (via Administrativo que compra).
- Quem executa: Interface ERP (declarativos) + Farm. Qualidade (validados)
- Entregável: Campos declarativos e validados completos.
Fase 4 — Registro e aprovação
Interface preenche o cadastro no ERP. Operação contesta ou aprova. Atendimento é informado de que o produto está disponível/atualizado.
- O que muda (ERP): Campos preenchidos, produto liberado para venda.
- Entregável: Cadastro completo e aprovado.
Resumo RACI
| Fase | R (Executa) | A (Presta contas) | C (Consulta) | I (Informado) |
|---|---|---|---|---|
| 1. Detectar incompletude | Qualquer papel | Interface ERP | — | — |
| 2. Decomposição e diagnóstico | Interface ERP | Interface ERP | Dir. Científico (fonte) | — |
| 3. Perseguição (declarativos) | Interface ERP | Interface ERP | Dir. Científico | — |
| 3. Perseguição (validados) | Farm. Qualidade | Farm. Qualidade | Interface ERP | Administrativo |
| 4. Registro e aprovação | Interface ERP | Interface ERP | Farm. Qualidade | Atendente |
Regras de decisão e escalação
-
Confiança por default no portfólio existente. Produtos já cadastrados operam com confiança. Atendente confia no cadastro até encontrar lacuna explícita. A regularização retroativa acontece organicamente — cada ocorrência de
cadastro-incompletoprioriza qual produto precisa de atenção. Não fazemos varredura proativa. -
Farm. Qualidade adapta mas não veta. Se a adaptação descaracterizar o produto, escala de volta ao Dir. Científico para decisão.
-
Tempo de resposta do Dir. Científico é indefinido. Sem SLA formal. Se a Interface não conseguir resposta em tempo hábil, registra como pendente e sinaliza o que falta. Não travar o resto do processo.
Checklist de completude
Este checklist cresce organicamente. Cada vez que uma ocorrência revelar campo que deveria estar no cadastro mas não estava, adicionar aqui com referência à ocorrência.
Declarativos
- Composição pretendida
- Indicação principal
- Público-alvo (profissional)
- Público-alvo (paciente)
- Tratamentos associados
- Produtos similares/substitutos
- Benefícios-chave
- Contraindicações conhecidas
- Contexto de apresentação
- Evento associado
- Posicionamento
- Forma farmacêutica pretendida
- Cold chain (declarado)
Validados
- Fornecedor aprovado
- Lote disponível
- Orientações farmacotécnicas
- Concentração viável confirmada
- Condições de armazenamento
- Validade real
- Adaptações feitas
Relação com outros processos
- Alimenta: entrada-produto-portfolio (fases 2-4 dependem da completude)
- Retroalimentado por: Ocorrências tipo
cadastro-incompleto-declarativoecadastro-incompleto-validado— cada ocorrência pode adicionar campos ao checklist - Fraqueza conhecida (Gap 13): A Interface hoje identifica incompletudes por experiência, sem checklist formal validado. Um workshop envolvendo Dir. Científico (relevância técnica), Atendimento (necessidade dia a dia) e Interface (o que o ERP aceita) refinaria o checklist — ainda não foi feito.
Histórico de evolução
| Data | Mudança | Motivação |
|---|---|---|
| 2026-03-31 | Criação do documento com base na seção “Completude de cadastro” do CLAUDE.md | 2026-03-31-processos-sem-raci |
| 2026-04-01 | Reestruturado: narrativa por fase, distinção explícita entre detecção/decomposição/perseguição, Gap 13 referenciado | Sessão de arquitetura com João |