Resposta direta
O erro apontado pelo cliente é um incidente, não uma dúvida isolada. O primeiro passo é registrar o dado reclamado, o horário, o sistema de origem e o sistema em que o cliente viu a divergência, e congelar mudanças no fluxo até entender o caminho percorrido. Em seguida, compara-se registro por registro, identificando o último ponto em que o dado ainda estava correto. A correção vai para a origem, não para a tela onde o cliente viu. Por fim, é preciso definir quem responde pelo dado, com que frequência ele é conferido e qual sinal avisa quando algo para de sincronizar. Sem isso, o mesmo erro volta com outro nome.
- Objetivo
- Orientar implementação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata o erro já exposto ao cliente como incidente, com linha do tempo, alcance do defeito e responsável pelo dado — as outras páginas do tema tratam a falha antes de ela chegar ao cliente.
O que a reclamação já revela sobre o fluxo
O erro chega pela reclamação, o que significa que a falha passou por todos os controles internos sem ser vista. Antes de corrigir, vale reconstruir a linha do tempo: qual campo, qual valor, em que momento, em qual sistema ele ainda estava certo e a partir de onde passou a divergir. Essa reconstrução separa dois casos diferentes: dado que nasceu errado e dado que se corrompeu no caminho.
Os primeiros registros costumam apontar o culpado errado, porque a tela em que o cliente viu o erro quase nunca é onde o erro começou. Guardar print, identificador do registro e horário de acesso evita discussão depois. Se o mesmo dado aparece certo em um sistema e errado em outro, o problema está na passagem entre eles, não no cadastro.
Correção na origem, não na tela do cliente
A correção precisa acontecer na origem. Ajustar apenas o registro visível resolve a reclamação de hoje e deixa o restante da base errado. Depois de corrigido, é preciso reprocessar o que já foi propagado e conferir se outros registros do mesmo lote têm o mesmo defeito. Um erro raramente vem sozinho.
Cada dado crítico precisa de um responsável nomeado e de uma rotina de conferência. A pergunta prática é simples: qual contagem, qual total ou qual campo, se divergir, faz alguém parar e olhar. Onde essa pergunta não existe, a próxima divergência também será descoberta pelo cliente.
O que essa condução não resolve
Essa condução não recupera decisões já tomadas com o dado errado: faturamento emitido, pedido enviado, cobrança feita. Também não substitui o desenho da integração. Se a regra de conversão entre os sistemas está indefinida, o erro volta na próxima carga, mesmo com a resposta ao cliente bem executada.
Ela também não serve quando a origem do dado é uma pessoa que digita diferente a cada dia; aí o problema é de padrão de entrada, não de sincronização. Em operações com muitos sistemas e histórico longo, reconciliar tudo pode custar mais que o prejuízo do erro. Nesse cenário, o critério é definir quais dados justificam conferência permanente e quais aceitam divergência tolerada.
Recurso prático
Roteiro de resposta a erro de sincronização apontado pelo cliente
- Abrir o incidente com identificador do registro, valor reclamado, horário da reclamação e sistema em que o cliente viu o erro.
- Levantar a linha do tempo do registro: em que sistema ele estava correto, em que ponto passou a divergir e qual processo rodou entre os dois momentos.
- Classificar a causa: entrada errada, regra de conversão, falha de propagação ou edição manual posterior.
- Corrigir na origem, reprocessar o que já foi propagado e listar outros registros do mesmo lote ou da mesma regra.
- Registrar o responsável pelo dado, a conferência recorrente e o sinal que deve avisar quando a sincronização parar.
O ponto mais ignorado é o alcance do erro: quase sempre o registro reclamado é apenas o primeiro visível, e a correção é feita nele enquanto os demais seguem errados.
Sobre o que está escrito aqui
Conceitos relacionados: linha do tempo do registro · reprocessamento de carga · responsável pelo dado · conferência recorrente · reconciliação entre sistemas. 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
- Planilhas divergentes: o que exigir na contra… — planilhas divergentes
- Cadastros duplicados: como desenhar o fluxo d… — cadastros duplicados
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
- Erro descoberto pelo cliente: o que avaliar antes de contratar — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Dados desatualizados: o que precisa estar em dia — A regra das três colunas — dado, frequência aceitável, responsável — e o erro de tratar tudo como crítico.
- 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.
- Campo com formatos diferentes: o que exigir no contrato — O que acordar ao contratar tratamento para campo preenchido de formas diferentes: regra única, responsável definido e critério de aceite verificável.
- Dois números para o mesmo indicador: qual usar na decisão — Forma de definir a fonte oficial de cada indicador, registrar o critério que a sustenta e tratar a divergência entre duas fontes com regra conhecida.
- Duas fontes para o mesmo número: qual delas decide — Compara os arranjos possíveis para definir a fonte de cada indicador e o que cada um exige em regra, dono e manutenção.