Resposta direta
A contratação, depois de um erro descoberto pelo cliente, precisa nomear quem monitora a sincronização, qual evidência comprova a falha, em quanto tempo a correção começa e quem comunica o cliente. Também é preciso separar dois fatos: o erro existiu e ninguém interno o viu, e o cliente o viu primeiro. A avaliação do fornecedor passa por três perguntas: ele mantém registro de reconciliação, assume a responsabilidade de detectar a falha, e entrega histórico para reconstruir o dado? Sem esses pontos, cada erro vira discussão sobre culpa e não sobre correção.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata o erro já descoberto pelo cliente como problema de contrato e de responsabilidade, não de detecção.
A falha que o cliente viu primeiro
Quando o cliente encontra a divergência, o problema deixa de ser técnico e passa a ser de responsabilidade. A pergunta relevante não é por que o dado errou, mas por que ninguém interno percebeu antes. Isso indica que a operação não tem rotina de conferência, ou que ela existe e ninguém lê o resultado.
Registrar o caso com data, campo, sistema de origem e valor esperado evita que a discussão se perca em memória. Sem esse registro, cada parte reconstrói a história a seu favor e a correção atrasa.
Critérios de contratação e de cobrança
Antes de contratar, importa saber se o fornecedor mantém registro de reconciliação, com que frequência compara as bases e o que faz quando os números não batem. A pergunta prática é quem detecta a falha e em quanto tempo.
O contrato precisa fixar três pontos: prazo para iniciar a correção depois do aviso, evidência aceita para comprovar o erro e quem comunica o cliente. Sem isso, a cobrança depende de boa vontade, e o custo de descobrir a falha fica com quem foi afetado.
O que isso não resolve
Contrato e cláusula não corrigem dado nem substituem processo. Se a causa é cadastro duplicado, regra de negócio divergente ou campo sem dono, o erro volta, ainda que a correção contratual funcione.
Também não se pode assumir que a próxima falha será detectada internamente. Definir monitoramento reduz o intervalo entre o erro e a percepção, mas não elimina a chance de o cliente ver primeiro. Esse limite precisa estar claro para as duas partes.
Recurso prático
Roteiro para tratar erro de sincronização descoberto pelo cliente
- Registrar o caso com data, campo divergente, sistema de origem e valor esperado pelo cliente.
- Levantar a trilha: quem alterou o dado, quando, por qual rotina, e se havia conferência registrada.
- Separar o que é dado errado, o que é regra de negócio divergente e o que é falha de sincronização.
- Definir a responsabilidade de cada parte: quem monitora, quem corrige e quem comunica o cliente.
- Corrigir o dado visível e a rotina que permitiu a divergência, não apenas o primeiro.
- Revisar o contrato: cláusula de monitoramento, prazo de correção, evidência exigida e canal de aviso ao cliente.
O erro mais comum é corrigir o dado que o cliente viu e não a rotina que gerou a divergência. O segundo é assinar sem definir quem monitora a sincronização, o que deixa a detecção a cargo de quem é afetado.
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: reconciliação de bases · trilha de auditoria · acordo de nível de serviço · responsabilidade sobre o dado · registro de divergência. 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
- Planilha paralela: como transferir a rotina p… — planilha que virou sistema paralelo
- Planilha paralela: como medir o peso na operação — planilha que virou sistema paralelo
Páginas relacionadas
O mesmo problema em outro objetivo
- Erro de sincronização achado pelo cliente: o que reconstruir — Diagnosticar
- Erro de sincronização visto pelo cliente: por onde começar — Organizar um processo
- Erro de sincronização visto pelo cliente: o que comparar — Comparar alternativas
- Erro que o cliente encontra: como medir a sincronização — Explicar medição
- Cliente achou erro de sincronização: como tratar na operação — Orientar implementação
Outras leituras em Integrações, sistemas e qualidade de dados
- Exportações manuais: o que exigir na contratação de apoio — Parâmetros para contratação de apoio em exportações manuais de dados entre sistemas, focando em conferência, responsabilidade por erros e custo real.
- Falhas silenciosas: o que exigir na contratação de suporte — Critérios técnicos e contratuais para contratar suporte e sustentação de integrações focado na identificação ativa de falhas silenciosas.
- Relatório montado à mão: como estruturar o fechamento — Critérios operacionais para definir corte de datas, fontes de dados e responsabilidades em relatórios periódicos consolidados manualmente.
- Arquitetura de integração: o que comparar antes de decidir — A página compara arquiteturas de integração por onde mora a regra, quem responde pelo dado, reversibilidade e custo de mudança ao longo do tempo.
- Cadastro sem regra de deduplicação: o que exigir no contrato — O que negociar, testar e aceitar na regra de deduplicação de um sistema de cadastro, incluindo o que o fornecedor declara e o que fica fora do escopo.