Resposta direta
O tratamento se contrata por regra, não por ferramenta. Antes de assinar, é preciso fechar o domínio de valores de cada campo: o que é aceito, o que é rejeitado e como o valor fora do padrão é convertido. A regra exige um responsável nomeado, que decide os casos que ela não cobre, e um critério de aceite verificável em registros reais da operação, não em apresentação. Contrato sem amostra transfere o problema para depois da entrada em produção, quando a correção custa mais e já contamina relatório, cobrança e atendimento.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata o campo divergente como item de contrato, com domínio acordado, responsável nomeado e amostra de aceite, em vez de ajuste técnico deixado para depois da assinatura.
O que a regra precisa cobrir
Campo divergente raramente é falha de digitação. Em geral são domínios diferentes: uma área grava o estado por sigla e outra por nome; um canal aceita telefone com máscara e outro sem. A contratação precisa dizer qual valor é canônico e como o restante é convertido, não apenas que haverá padronização.
Também é preciso definir o destino do valor que não converte. Rejeitar na entrada, aceitar com sinalização ou manter em quarentena até decisão. Cada escolha muda quem trata o problema e em que momento o erro aparece para o negócio.
Responsável e critério de aceite
Sem dono nomeado, a conversão vira discussão entre áreas a cada caso novo. O responsável não decide tudo; decide o que a regra não cobre, com o critério usado registrado, para que a próxima ocorrência não volte à estaca zero.
O aceite precisa ser verificável em registros reais. Uma amostra das bases atuais, com os casos difíceis incluídos, mostra se o tratamento funciona antes da assinatura. Planilha de exemplo montada pelo fornecedor não serve como prova.
O que a regra não resolve
Padronizar campo não corrige origem. Se a divergência nasce de cadastro sem validação na entrada, o mesmo problema retorna pela porta dos fundos. A regra de conversão trata o sintoma enquanto a entrada continuar aberta.
Também não há conversão confiável quando o campo carrega significado ambíguo de negócio, como um código que duas áreas interpretam de formas distintas. Nesse caso o problema é de definição, não de formatação, e nenhum tratamento técnico resolve antes do acordo entre as áreas.
Recurso prático
Da divergência de campo ao critério de aceite
- Listar os campos que já chegam divergentes: estado, telefone, data, documento e unidade de medida.
- Registrar os formatos e valores em uso em cada sistema, com exemplos reais coletados das bases atuais.
- Definir o domínio aceito, o valor canônico e a regra de conversão para o que estiver fora dele.
- Nomear quem decide os casos ambíguos quando a regra não cobre, e onde essa decisão fica registrada.
- Escrever o critério de aceite com uma amostra de registros reais que o fornecedor converte antes da assinatura.
- Delimitar o que fica fora do escopo: campo sem regra acordada segue como está e é tratado em fase separada.
O erro mais comum é aceitar a promessa de padronização automática sem amostra. Conversão de campo depende do domínio acordado, e domínio não se testa em demonstração, apenas em registros reais da operação.
Conceitos usados nesta página
- Critério de aceite — Critério de aceite é a condição objetiva que define quando uma entrega, tarefa ou automação é considerada concluída — verificável por quem recebe, não por quem produziu.
Sobre o que está escrito aqui
Conceitos relacionados: domínio de valores · regra de conversão · responsável pelo dado · critério de aceite · amostra de registros reais. 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
- Campos preenchidos sem padrão: como mapear a dispersão — Diagnosticar
- Campo preenchido de formas diferentes: o que padronizar — Organizar um processo
- Campos com grafias diferentes: como escolher a correção — Comparar alternativas
- Campo preenchido de formas diferentes: como medir — Explicar medição
- Campo com formatos diferentes: onde normalizar — Orientar implementação
Outras leituras em Integrações, sistemas e qualidade de dados
- 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.
- 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.
- Contratar arquitetura: o que fica definido e por quem — O que precisa estar definido em um contrato de arquitetura: decisão, entregável, responsável e critério de aceite, antes de comparar propostas.
- Base de dados sem dono: o que comparar antes de decidir — Compara três arranjos para base sem dono definido: manter centralizado, nomear responsável ou dividir a guarda. Critérios, custos e limites de cada opção.
- Valor sem unidade: o que registrar antes de somar — O que definir no registro, na conversão e na conferência de valores sem unidade para que a soma entre sistemas faça sentido.