Resposta direta
Para identificar o mesmo cliente entre ERP, CRM e legado, a empresa precisa resolver identidade, não apenas comparar IDs. Cada sistema pode ter sua própria chave e versões diferentes de nome, documento, telefone e endereço. A reconciliação combina evidências, liga os registros equivalentes e preserva a origem de cada um.
- ID interno identifica o registro no sistema, não necessariamente a pessoa real.
- JOIN por CPF funciona apenas quando o documento está presente e consistente.
- JOIN por nome sofre com grafia, abreviação, ordem de termos e homônimos.
- Uma visão única pode existir sem substituir ERP, CRM e legado.
O mesmo cliente pode ter três IDs corretos
Um ERP pode identificar um cliente como 18452, o CRM como 903118 e o legado como 771. Cada ID está correto dentro do seu sistema. O problema aparece quando a empresa precisa saber se os três registros representam a mesma pessoa ou empresa.
Isso é diferente de escolher uma chave técnica. A pergunta é de identidade: quem é quem entre as bases?
Por que JOIN por CPF ou CNPJ falha
Documentos são excelentes âncoras quando estão corretos. Mas um JOIN só relaciona o que é comparável. Se o CPF está ausente no CRM, inválido no legado ou repetido por erro histórico, a consulta não resolve a entidade. O mesmo vale para CNPJ em bases empresariais.
Por isso, a reconciliação pode usar outros sinais. Os 8 critérios de deduplicação do MatchIQ combinam nome, endereço, telefone, documentos, nascimento e nome da mãe para localizar candidatos e manter a evidência de cada relação.
Por que JOIN por nome também não resolve
Nomes mudam de forma entre sistemas: acentos desaparecem, sobrenomes são abreviados, campos trocam de ordem e erros de digitação entram no cadastro. Pessoas diferentes também podem ter nomes idênticos. Comparação textual pura não separa esses dois problemas.
O MatchCode reduz variações ortográficas e fonéticas para apoiar a comparação, mas a decisão não precisa ficar apoiada apenas no nome. O contexto dos demais atributos aumenta ou reduz a evidência.
Reconciliação não é apagar diferenças
ERP e CRM podem ter valores diferentes porque foram atualizados em momentos distintos ou para finalidades diferentes. Uma visão reconciliada não precisa apagar essas diferenças. Ela pode preservar cada fonte, mostrar que os registros pertencem à mesma entidade e deixar a regra de referência para a governança do negócio.
Essa separação é importante porque identidade responde “quais registros pertencem à mesma entidade?”, enquanto MDM responde também “como essa entidade será governada entre os sistemas?”.
Um modelo prático de reconciliação entre sistemas
- Extrair os atributos necessários de cada fonte, sem exigir toda a base operacional.
- Medir qualidade de documentos, nomes, telefones, endereços e demais atributos de identidade.
- Normalizar o que for seguro, preservando o valor original.
- Aplicar critérios de identidade dentro e entre as bases.
- Classificar relações e ambiguidades, evitando fundir casos sem evidência suficiente.
- Manter a origem para que a empresa possa auditar o vínculo e definir suas próprias regras de referência.
Visão única não exige um banco único
É possível manter ERP, CRM e legados como sistemas de origem. Uma camada independente de identidade pode relacionar as chaves locais e formar uma visão reconciliada. Isso reduz a necessidade de começar o projeto substituindo sistemas ou criando uma grande base central.
Veja o guia de qualidade de dados para MDM para entender por que resolver identidade antes pode mudar a decisão arquitetural.
O que a TI deveria conseguir responder
- Quantos clientes do CRM já existem no ERP?
- Quantas versões do mesmo cliente existem dentro de cada sistema?
- Quais vínculos foram encontrados por documento e quais dependeram de outros atributos?
- Quais registros parecem relacionados, mas não têm evidência suficiente para serem tratados como a mesma entidade?
- Qual valor veio de qual sistema?
- É possível reproduzir e auditar a decisão?
Antes da integração, meça a base
Uma integração pode acelerar tanto os dados bons quanto as inconsistências. Por isso, o passo anterior é medir a situação real. O Raio X da Base analisa 100% dos registros fornecidos, sem amostragem, para mostrar duplicidades, conflitos e oportunidades de tratamento antes de definir a integração ou o MDM.
Veja também: Entity Resolution entre ERP, CRM e sistemas legados.
Perguntas frequentes
Como saber se dois registros são o mesmo cliente?
Combinando evidências como documentos válidos, nome, endereço, telefone e outros atributos, em vez de depender de uma única chave local.
Um JOIN por CPF resolve?
Somente quando o CPF está presente, válido e consistente nos sistemas envolvidos. Outros critérios são necessários para os casos fora desse cenário.
Preciso substituir ERP e CRM?
Não necessariamente. Os sistemas podem permanecer como fontes enquanto uma camada de identidade relaciona os registros.
Visão única é o mesmo que registro único?
Não. É possível ter uma visão reconciliada preservando múltiplos registros e suas origens.