Resposta direta
A chave de ligação deve ser contratada como item de escopo, não como parte invisível da integração. A proposta precisa nomear o campo que identifica a mesma entidade nas duas bases, o tratamento dos registros sem correspondência, quem decide nos casos ambíguos e como o resultado será conferido. Sem esse detalhamento, o projeto entrega rotinas e telas, mas a operação continua conciliando registro por registro. O contrato deve incluir amostra real para teste, aceite por registro e rotina de manutenção da chave quando um dos cadastros mudar.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata a chave de ligação como item contratual: escopo, decisão de ambiguidade, aceite por registro e manutenção.
Onde a correspondência se perde
Dois sistemas podem descrever a mesma entidade com campos diferentes e nenhum deles confiável. O cliente existe no comercial com nome e telefone; na cobrança, com razão social e código interno. O CPF aparece em uma base e falta na outra. O CNPJ tem formatos distintos. O código do produto muda quando a tabela é revisada.
Nesse cenário, a integração funciona e ainda assim não liga nada. Cada área encontra o registro por caminhos próprios e a conciliação vira trabalho manual. A chave de ligação é o campo ou a regra que produz essa correspondência de forma repetível, com registro de quem decidiu nos casos duvidosos.
O que a proposta precisa nomear
A contratação começa pela definição do atributo de ligação. Pode ser um documento, um código já existente ou uma combinação de campos. Se nenhum atributo isolado for suficiente, a proposta deve explicitar a regra de combinação e o grau de confiança aceito para cada caso.
Depois vêm amostra, aceite e manutenção. A amostra diz quais registros serão usados no teste e quem os fornece. O aceite descreve a conferência registro a registro, não a entrega da rotina. A manutenção define quem atualiza a chave quando um dos sistemas passa por mudança de cadastro. Sem esses pontos, o escopo fica aberto.
O limite da chave de ligação
A chave não corrige a qualidade dos cadastros de origem. Se o documento está errado, duplicado ou ausente nas duas bases, a ligação reproduz o erro com mais alcance. Também não substitui a decisão de negócio sobre qual registro é o correto quando as fontes divergem.
Em bases pequenas ou com pouca sobreposição, a ligação automática pode não se pagar. Nesses casos, uma rotina de conferência periódica com responsável nomeado resolve melhor do que um projeto de correspondência. A chave organiza o que já existe; ela não cria o dado que falta.
Recurso prático
O que pedir na proposta e o que a resposta revela
| Ponto do escopo | Resposta que indica trabalho real |
|---|---|
| Campo que identifica a mesma entidade nas duas bases | Nomeia os campos e diz o que fazer quando nenhum deles é confiável |
| Registros sem correspondência | Separa o que fica pendente, quem decide e onde a decisão é registrada |
| Amostra para teste | Define quais registros serão usados, de quais períodos e quem fornece |
| Critério de aceite | Descreve a conferência registro a registro, não a entrega da rotina |
| Depois da entrega | Diz quem atualiza a chave quando um dos sistemas muda de cadastro |
O erro mais comum é aceitar 'fazemos a integração' como resposta. A chave de ligação é decisão sobre dado e responsabilidade; sem esse nome no escopo, a proposta descreve conexão, não correspondência.
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: chave de ligação · cadastro mestre · correspondência entre registros · registro sem correspondência · critério de aceite. 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
- Cadastros sem chave em comum: onde a ligação se perde — Diagnosticar
- Chave ausente: como ligar cadastros sem identificador comum — Organizar um processo
- Cadastros sem chave comum: o que cada ligação exige — Comparar alternativas
- Chave de ligação ausente: o que medir antes de corrigir — Explicar medição
- Chave de ligação ausente: como construir a ponte — 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.
- Migração contratada: o que a proposta não cobre — O que precisa estar definido em escopo, aceite e responsabilidade para contratar uma migração de dados, e o que a proposta costuma deixar em aberto.
- Cliente duplicado entre áreas: como medir a sobreposição — Define o que conta como cliente duplicado, qual base serve de referência e como acompanhar a sobreposição entre áreas ao longo do tempo
- 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.
- Migração sem critério de aceite: como medir se o dado chegou — O que contar e comparar numa migração para saber se o dado saiu da origem, chegou ao destino e continua sendo usado depois do corte.