Resposta direta
A contratação deve exigir uma regra de deduplicação escrita, testável e vinculada ao aceite. Isso significa definir o identificador que manda no cadastro, registrar a regra por escrito, testar com dados da operação e condicionar o pagamento ao comportamento observado. Sem isso, o fornecedor entrega tela e integração, mas a decisão sobre o que é o mesmo registro continua sem dono. O contrato precisa indicar quem responde pela regra, como a correção é auditada e o que acontece quando dois registros legítimos apontam para a mesma pessoa ou organização.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata a deduplicação como cláusula e teste de aceite, com foco nos casos ambíguos e na responsabilidade pela exceção.
A regra precisa ser escrita antes da assinatura
Um fornecedor pode dizer que o sistema já trata duplicidade sem revelar o critério. A proposta precisa declarar quais campos identificam a mesma entidade, em que ordem, com que tolerância e o que ocorre quando falta informação. Também precisa dizer se a comparação é exata ou por semelhança, e quem decide nos casos em que o sistema apenas sinaliza.
Essa regra deve virar anexo do contrato, com responsável, versão e prazo de comunicação quando mudar. Sem isso, a lógica de cadastro fica embutida no produto e muda sem negociação. O contrato não precisa descrever cada campo, mas precisa fixar o comportamento exigido, o processo de alteração e o direito de testar antes de aceitar.
O aceite usa casos da operação, não demonstração
A validação comercial costuma mostrar o fluxo ideal. O aceite precisa usar casos da operação, sem dados pessoais identificáveis: telefone compartilhado por familiares, empresa com nome fantasia alterado, e-mail reaproveitado, cadastro incompleto e homônimos. Cada caso deve ter resultado esperado por escrito, incluindo quando o sistema deve apenas sinalizar e quando pode unir.
O teste cobre entrada manual, importação e integração, porque a regra pode ser aplicada em um caminho e não em outro. A fila de exceções e a trilha de auditoria fazem parte do aceite: sem elas, a correção não é rastreável. O pagamento pode ficar condicionado ao comportamento observado, não à existência da funcionalidade na tela.
O que a regra não resolve
Deduplicação não cria uma verdade única quando as áreas discordam sobre o dado correto. Também não resolve identificadores compartilhados, como telefone de família ou de central, nem cadastros que são parecidos e pertencem a pessoas diferentes. Toda comparação por semelhança erra para os dois lados; o contrato reduz a ambiguidade, mas não a elimina.
A regra também não substitui dono do dado, limpeza histórica, política de retenção e consentimento. Se a operação não tem uma chave minimamente confiável nem alguém responsável por decidir exceções, contratar deduplicação é prematuro. Nesse caso, o primeiro entregável é definir quem responde pelo cadastro e como as decisões são registradas.
Recurso prático
Checklist para negociar a regra de deduplicação
- Lista dos campos que identificam a mesma pessoa, empresa ou ativo, com a ordem de prevalência entre eles.
- Regra escrita para campos vazios, abreviações, troca de e-mail, alteração de nome e telefone compartilhado.
- Definição do que o sistema faz sozinho, do que apenas sinaliza e de quem decide a fusão.
- Conjunto de casos reais anonimizados, com resultado esperado e critério de aceite acordados antes da assinatura.
- Teste dos três caminhos de entrada: digitação, importação em lote e integração entre sistemas.
- Exigência de fila de exceções, histórico de fusões e possibilidade de desfazer uma união indevida.
- Cláusula de versão da regra, comunicação de mudanças e responsável técnico e operacional pelo cadastro.
- Condição de pagamento ligada ao teste de aceite, não à declaração de que a função existe.
O erro mais comum é aceitar a demonstração da tela e não testar importação e integração, justamente onde a regra precisa valer do mesmo jeito.
Conceitos usados nesta página
- Trilha de auditoria — Trilha de auditoria é o conjunto de registros que permite reconstruir quem fez o quê, quando e com qual dado — inclusive depois que o resultado já foi usado.
Sobre o que está escrito aqui
Conceitos relacionados: regra de deduplicação · chave de identificação · caso de aceite · fila de exceções · trilha de auditoria. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Integrações, sistemas e qualidade de dados — Página central do tema
- Sincronização entre sistemas: o que decidir a… — sistemas desconectados
- Falhas silenciosas em integrações: como perce… — falhas silenciosas
Páginas relacionadas
O mesmo problema em outro objetivo
- Cadastro sem regra de deduplicação: como medir o problema — Diagnosticar
- Cadastro sem regra de deduplicação: comparar caminhos — Comparar alternativas
- Cadastro sem regra de deduplicação: o que medir — Explicar medição
- Cadastro sem deduplicação: definir a regra antes do bloqueio — Orientar implementação
Outras leituras em Integrações, sistemas e qualidade de dados
- Cadastro sem chave única: o que exigir na contratação — O que exigir de um fornecedor de cadastro sem chave única: critérios de avaliação, responsabilidade sobre duplicidade e o que medir antes de assinar.
- Cliente duplicado entre áreas: quando vale contratar solução — O que avaliar antes de contratar solução para cliente duplicado entre áreas, o que é decisão de dado e o que é decisão de responsabilidade.
- Falhas silenciosas: fluxo para conter e sanar o dado — Critérios para organizar a custódia, triagem e correção retroativa de inconsistências operacionais que passam despercebidas pelos sistemas.
- Reconciliação: o que definir antes de contratar — O que definir em escopo, responsável, critério de aceite e prazo de correção antes de contratar reconciliação entre sistemas.
- Correção direta no banco de produção: o que comparar — Compara edição manual no banco, script versionado e correção na origem, com critério de responsabilidade, reversibilidade e registro do que foi alterado.