Sincronização CRM–ERP: porque falha o registo de cliente

Pergunte a um diretor comercial quantos clientes a empresa tem e faça depois a mesma pergunta ao diretor financeiro. Na maioria das empresas mid-market as respostas divergem, às vezes com uma diferença percentual de dois dígitos. Nenhum dos dois está a mentir e nenhum é descuidado. Estão a contar coisas diferentes em sistemas diferentes, e não existe qualquer mecanismo para as reconciliar.

Esta é a condição normal de uma empresa que opera um CRM e um ERP implementados em momentos diferentes e por razões diferentes. Parece um problema de dados e é por isso que costuma ser tratado com um exercício de desduplicação: uma limpeza que consome seis semanas e se degrada em menos de dois trimestres, porque nada mudou na forma como os registos são criados.

A sincronização entre um CRM e um ERP falha por uma razão conceptual, não técnica. Os dois sistemas não entendem o mesmo por «cliente». Até que isso seja resolvido de forma explícita, campo a campo, qualquer integração entre eles é um mecanismo para propagar a discordância com rapidez.

Porque é que isto importa

Os custos visíveis são irritantes, mas suportáveis: registos duplicados, faturas emitidas à entidade errada, comerciais a propor preços que a área financeira não vai honrar, limites de crédito invisíveis para quem assume os compromissos.

O custo estrutural é pior. Quando o CRM e o ERP discordam quanto aos clientes, qualquer número derivado de um ou do outro passa a ser contestável. O pipeline não pode ser reconciliado com o rédito, pelo que a previsão se torna uma negociação em vez de um cálculo. A rentabilidade por cliente não pode ser calculada, porque o custo está num sistema e o histórico da relação no outro. A análise de abandono não é fiável porque a unidade de análise é ambígua. A empresa acaba com duas versões da sua própria realidade comercial e com uma equipa de gestão que, intuitivamente, desvaloriza ambas.

Existe também uma dimensão de conformidade. Ao abrigo do RGPD, um pedido de acesso ou de apagamento por parte de um titular dos dados tem de ser satisfeito em todos os sistemas que contenham dados pessoais. Se não conseguir afirmar com fiabilidade que uma pessoa no CRM e um contacto no ERP são o mesmo indivíduo, também não consegue satisfazer o pedido com fiabilidade, e isso é uma exposição de governação de dados, não um simples incómodo.

Num relance: as decisões que determinam se a sincronização funciona

O padrão da coluna da direita é o método na íntegra: para cada campo, um sistema é o seu proprietário e o outro apresenta-o. Quando dois sistemas podem escrever o mesmo campo, não construiu uma integração: construiu uma corrida.

O que funciona e sobre o que convém ser honesto

O que funciona:

Propriedade ao nível do campo, por escrito. Não ao nível do sistema. «O ERP é o master» não é um desenho, porque a área comercial é legitimamente proprietária dos dados de contacto e a área financeira é legitimamente proprietária das condições de crédito. Produza a tabela acima para os seus próprios dados e faça com que ambos os diretores a assinem.

Uma chave partilhada e imutável. Um sistema emite um identificador, o outro guarda-o e este nunca muda: nem quando a empresa é renomeada, reestruturada ou adquirida. A correspondência por nome, e-mail ou número fiscal funciona para a maioria dos registos e falha exatamente naqueles que mais importam.

Validação no momento da criação. Evitar um duplicado na introdução não custa praticamente nada. Removê-lo depois custa a uma pessoa um dia de trabalho e produz muitas vezes um terceiro registo. A validação do formato do identificador fiscal por país, os avisos de correspondência aproximada na criação e os campos obrigatórios no sistema proprietário travam o problema na origem.

Governação de dados assistida por agentes. Um agente de master data (dados de referência) que monitorize a divergência em ambos os sistemas, aplique regras de fusão deterministas onde não haja ambiguidade e encaminhe a ambiguidade genuína para um responsável identificado pelo nome, com ambos os registos lado a lado, mantém limpo um conjunto de dados já limpo. É esta a diferença entre um projeto de desduplicação e uma solução a sério.

Apresentação apenas de leitura do que não lhe pertence. A área comercial deve ver o limite de crédito. A área comercial não deve poder alterá-lo. A maioria dos problemas de confiança entre a área financeira e a comercial nas empresas mid-market é uma falha de desenho de permissões e não um problema comportamental.

Sobre o que convém ser honesto:

Alguém perde. A propriedade ao nível do campo significa dizer a um departamento que já não pode editar algo que sempre editou. É aqui que estes projetos falham na realidade, não na configuração. Exige um patrocinador com autoridade sobre ambas as partes.

Os dados históricos não vão reconciliar na totalidade. Uma parte dos seus registos existentes não pode ser correspondida com confiança, e forçar a correspondência gera erros piores do que deixá-los separados. Defina um limiar de confiança, resolva acima dele, coloque em quarentena o que ficar abaixo e aceite um pequeno remanescente permanente.

A sincronização bidirecional é mais cara do que parece e muitas vezes desnecessária. Uma vez definida a propriedade ao nível do campo, a maioria dos campos flui numa só direção. Os campos genuinamente bidirecionais são raros e cada um exige lógica de resolução de conflitos. Desenhe unidirecional por omissão.

«Ganha a última escrita» é a decisão de não decidir. É o comportamento por omissão em muitas ferramentas e está quase sempre errado, porque significa que prevalece a edição mais recente independentemente de quem tinha autoridade.

O tempo real não é sempre o requisito. Um cliente novo deve chegar ao ERP com rapidez. Uma alteração de classificação setorial não precisa de se propagar em menos de um segundo. A sincronização uniforme em tempo real gera carga e modos de falha sem qualquer benefício.

Quadro de decisão: desenhar a integração

Percorra por ordem. Pare na primeira correspondência.

1. Tem uma definição documentada e acordada do que é um cliente em cada sistema?
Se não, comece aqui, antes de qualquer trabalho técnico. Defina se uma conta do CRM corresponde a um cliente do ERP, se grupos e subsidiárias são modelados e onde se situa a entidade de faturação. É um exercício de dois workshops e tudo o que vem a seguir depende dele.

2. Tem uma chave partilhada e imutável?
Se não, estabeleça uma antes de sincronizar o que seja. Decida que sistema a emite, preencha-a retroativamente nos registos existentes e torne-a não editável. Lógica de correspondência sem chave é um arranjo temporário que se torna permanente.

3. Atribuiu a propriedade ao nível do campo, com a aprovação da direção comercial e da direção financeira?
Se não, produza essa tabela e obtenha o acordo. Sem ela, a sua integração vai codificar o pressuposto que o programador tivesse na cabeça.

4. Continuam a ser criados duplicados na introdução?
Se sim, corrija a criação antes de limpar o histórico. Validação, avisos de correspondência aproximada e campos obrigatórios no sistema proprietário. Limpar um conjunto de dados que continua a gerar duplicados é uma subscrição e não um projeto.

5. Tem uma acumulação de registos sem correspondência ou duplicados?
Agora limpe-a, com um limiar de confiança, um registo de auditoria e uma quarentena para o remanescente ambíguo. Não antes do passo 4.

6. Sobra algo genuinamente bidirecional depois dos passos 1–3?
Para cada campo desses, especifique a regra de conflito de forma explícita: que sistema ganha, ou se o conflito é encaminhado para uma pessoa. Se não conseguir articular a regra, o campo não está pronto para ser bidirecional.

7. Está tudo isto no lugar e os registos continuam a divergir?
Tem uma lacuna de governação de dados e não de desenho. Atribua um proprietário de dados identificado pelo nome, instrumente a divergência como uma métrica visível e implemente monitorização baseada em agentes para detetar o desvio em dias em vez de trimestres.

Custo e esforço indicativos

Pressupõe um CRM, uma instância de ERP e um volume de registos mid-market. Várias instâncias de CRM depois de uma aquisição, ou uma base de clientes acima de algumas centenas de milhares de registos, alteram estes valores de forma material. Peça um orçamento para uma estimativa delimitada.

Perguntas frequentes

Que sistema deve ser o master?
Nenhum, no seu conjunto. A pergunta está mal formulada. A propriedade do master data pertence ao nível do campo: o ERP é proprietário dos atributos financeiros, fiscais e legais; o CRM, dos atributos de relação e de interação; a identidade pertence ao sistema que criar o registo primeiro, segundo uma regra que defina. Qualquer resposta do tipo «o sistema X é o master» será violada em menos de um mês por uma necessidade de negócio legítima.

Podemos simplesmente usar o identificador fiscal como chave?
É um atributo de correspondência útil e uma chave primária fraca. Os identificadores fiscais mudam com as reestruturações, não existem para alguns tipos de cliente, aparecem em formatos inconsistentes e são partilhados entre entidades em algumas estruturas de grupo. Valide contra ele; não dependa dele.

Como tratamos um cliente que é uma conta no CRM e cinco entidades de faturação no ERP?
De forma explícita, no passo 1. É o desalinhamento estrutural mais frequente que encontramos e tem de ser modelado deliberadamente, normalmente como uma hierarquia no CRM mapeada para uma estrutura pai-filho no ERP, com regras claras sobre que nível é proprietário do crédito e que nível recebe as faturas. Deixado sem definição, produz contas duplicadas e faturas mal encaminhadas indefinidamente.

Um agente de IA vai resolver o nosso problema de duplicados?
Vai manter limpo um conjunto de dados limpo e reduzir de forma material o custo humano da governação de dados, o que é um benefício considerável. Não vai substituir o trabalho de definição: um agente que aplique regras de fusão derivadas de uma definição de cliente ambígua produzirá sistematicamente fusões ambíguas.

Quanto tempo até vermos o benefício?
A validação na criação e a prevenção de duplicados produzem melhoria visível em semanas. A reconciliação completa do pipeline com o rédito leva tipicamente dois a três trimestres, porque exige a acumulação histórica liquidada e um período de operação limpa antes de se poder confiar nos números.

Com que rapidez é que isto pode realmente ser implementado?
Mais rápido do que a maioria das equipas espera para a própria camada de sincronização — um parceiro de implementação certificado como Stacksync pode ter a sincronização bidirecional CRM-ERP em tempo real a funcionar em semanas, não em trimestres. A parte mais difícil e lenta é quase sempre o trabalho de definição acima: acordar a propriedade de cada campo, modelar o desajuste hierárquico e definir as regras de validação. Se começar pela plataforma não obtém nenhum dos dois benefícios; se começar pelas definições, a implementação da plataforma passa a ser a parte rápida.

Fecho — Próximos passos

Os projetos de sincronização CRM–ERP desapontam porque são encomendados como integrações e são, na verdade, exercícios de governação de dados. A integração são poucas semanas de trabalho depois de tomadas as decisões, e é nas decisões que estão tanto a dificuldade como o valor.

Se quiser saber a dimensão do seu problema antes de se comprometer com o que seja: extraia uma contagem de clientes de cada sistema e tente fazer a correspondência pelo identificador fiscal. A dimensão do remanescente sem correspondência é o seu projeto. Na maioria das empresas mid-market é maior do que qualquer dos dois diretores espera.

Sobre o autor

Bruno Galo é o fundador da Atypical Tech, uma consultora NetSuite que serve clientes mid-market em toda a Ibéria. Especializa-se em ligar sistemas CRM e ERP para fluxos order-to-cash sem atritos, e em construir pipelines automatizados de gestão de encomendas que eliminam a introdução manual de dados entre as equipas comercial e financeira. Como partner oficial de implementação da Stacksync, Bruno desenha e implementa agentes de IA em plataformas de integração para tratar o escalamento de exceções, o processamento documental e a reconciliação, transformando fluxos de encomendas fragmentados em sistemas fiáveis que se monitorizam a si próprios.

LinkedIn: https://www.linkedin.com/in/brunogd

Fontes

Os URL são ao nível do editor e devem ser verificados antes da publicação.

• Oracle NetSuite, documentação de registos de cliente e de entidade — https://docs.oracle.com/en/cloud/saas/netsuite/
• DAMA International, Data Management Body of Knowledge (DMBOK) — princípios de gestão de master data — https://www.dama.org
• Comissão Europeia, Regulamento Geral sobre a Proteção de Dados da UE — direitos do titular dos dados em todos os sistemas — https://commission.europa.eu/law/law-topic/data-protection_en
• Agencia Tributaria (Espanha), validação e regras de formato do NIF — https://sede.agenciatributaria.gob.es
• Autoridade Tributária e Aduaneira (Portugal), informação sobre NIF/NIPC — https://info.portaldasfinancas.gov.pt
• Experiência da Atypical Tech em projetos de integração de CRM e ERP mid-market na Ibéria
• Stacksync, blog da plataforma de integração e sincronização em tempo real — https://www.stacksync.com/blog