Integração de sistemas: por que ERP e CRM não conversam

07 ago Integração de sistemas: por que ERP e CRM não conversam

A integração de sistemas costuma entrar na pauta no dia em que alguém descobre que o mesmo cliente tem três nomes diferentes dentro da empresa: um no ERP, outro no CRM, um terceiro na ferramenta de atendimento. O pedido existe, a negociação existe, o chamado existe — só não existe um lugar onde os três se encontrem. A partir daí, boa parte do trabalho de gestão vira conciliação manual de planilha, e a operação passa a consumir hora de gente cara para responder pergunta que o sistema deveria responder sozinho.

Este texto trata da encanação. Por que o dado trava na fronteira entre um sistema e outro, quais modelos de integração existem e para que serve cada um, que decisões precisam estar tomadas antes de qualquer conexão técnica, e como saber, depois que tudo está no ar, se a integração continua entregando o que prometeu. Não é um texto sobre qual plataforma comprar: é sobre o que você tem de resolver independentemente da plataforma escolhida.

Se a sua empresa ainda está definindo quais ferramentas vai usar, a discussão anterior a esta é como escolher o stack certo para o estágio da sua empresa. Se o stack já está definido e o problema é que ele não se fala, siga aqui.

O que é integração de sistemas — e o que costuma ser vendido com esse nome

Integrar significa que um dado nasce em um sistema e chega ao outro com o significado preservado, sem ninguém redigitar. Tudo que não cumpre essas duas condições é outra coisa.

Não é integração exportar uma planilha e subir à mão, mesmo que a exportação seja agendada e o upload seja rápido. Também não é integração manter os dois sistemas abertos em abas diferentes para o operador comparar. E não é integração ter um painel que lê os dois bancos ao mesmo tempo sem saber que o cliente de um é o mesmo cliente do outro: nesse caso você não integrou nada, apenas empilhou dois relatórios na mesma tela. Por fim, ter API disponível não significa estar integrado — a API é a porta, não a passagem.

Ajuda pensar em três camadas empilhadas. A primeira é o transporte: como o dado viaja fisicamente de um lado para o outro. A segunda é a semântica: o que cada campo significa nos dois sistemas, e se os dois significados são compatíveis. A terceira é a identidade: como o sistema de destino sabe que aquele registro que chegou é o mesmo registro que ele já tem.

Projetos de integração raramente morrem no transporte; eles morrem na semântica e na identidade. O transporte é a parte que o fornecedor entrega rápido e demonstra bonito. As outras duas exigem decisão de negócio, e decisão de negócio ninguém consegue terceirizar.

Por que o dado não atravessa: as causas que mais aparecem

Quando o gestor diz que os sistemas não conversam, quase sempre o problema é um destes.

• Não existe chave comum entre as bases. O CNPJ está preenchido no ERP e vazio em metade dos registros do CRM, e o e-mail foi adotado como chave por comodidade — só que e-mail muda de dono, se repete entre contatos da mesma empresa e às vezes é o do vendedor.
• O cadastro pode ser criado em dois lugares ao mesmo tempo, sem que nenhum dos dois seja o dono. Aí o mesmo cliente entra duas vezes, com grafias diferentes, e cada sistema acha que está certo.
• Os campos são livres onde deveriam ser controlados. Um vendedor digita São Paulo, outro escreve SP, um terceiro escreve com letra minúscula e sem acento. Para o humano é a mesma coisa; para a integração são três valores distintos.
• Os sistemas modelam o negócio de formas diferentes. No CRM a unidade é a oportunidade, no ERP é o pedido, no atendimento é o chamado. Não existe correspondência de um para um entre eles, e forçar essa correspondência gera número errado nas duas pontas.
• Parte do processo acontece fora de qualquer sistema. O desconto combinado por mensagem, o prazo alterado por telefone, a exceção autorizada verbalmente. Integração nenhuma transporta o que nunca foi registrado.
• Existe um sistema legado que só oferece exportação em arquivo, em horário fixo. Isso não impede a integração, mas define o tipo de integração possível — e ninguém pode prometer tempo real por cima dele.

Note que quatro dessas seis causas são de processo e cadastro, não de tecnologia. Por isso o diagnóstico honesto costuma começar longe do código.

Os modelos de integração e quando cada um serve

Existe mais de um jeito de ligar dois sistemas, e a escolha errada aparece só depois, quando o terceiro e o quarto sistema entram.

A integração ponto a ponto liga um sistema diretamente ao outro. É a mais rápida de começar e a mais barata no primeiro projeto. O problema é o crescimento: cada nova ferramenta multiplica o número de conexões a manter, e uma mudança em um sistema quebra várias pontas ao mesmo tempo. Vale quando você tem poucos sistemas e não pretende ter muitos.

A camada intermediária — barramento, plataforma de integração, orquestrador, o nome varia — coloca um ponto central entre as ferramentas. Custa mais para montar e exige quem cuide dela, mas padroniza tratamento de erro, log e transformação de campo em um lugar só. Vale a partir do momento em que a empresa tem vários sistemas relevantes e planeja trocar algum deles sem refazer tudo.

A integração por arquivo em lote move blocos de registro em janelas definidas. É perfeitamente aceitável quando o processo tolera atraso, como fechamento contábil ou carga para análise. É má escolha quando alguém precisa do dado para atender o cliente que está na linha agora.

A integração por evento faz o sistema de origem avisar quando algo muda, em vez de o sistema de destino ficar perguntando. Reduz carga e chega mais perto do tempo real, mas exige tratamento cuidadoso de repetição e de ordem: o mesmo aviso pode chegar duas vezes ou fora de sequência, e o destino precisa aguentar isso sem duplicar registro.

Há ainda a replicação para um repositório analítico, aquele em que os dados de vários sistemas são copiados para uma base voltada a análise. É importante não confundir: isso alimenta painel, não alimenta processo. Serve para responder perguntas, não para fazer o pedido chegar ao faturamento. Se a sua dor é decisão, esse caminho ajuda; se a sua dor é operação travada, ele não resolve sozinho. O tema aparece com mais profundidade em marketing, atendimento e BI conectados no mesmo fluxo.

Para escolher entre eles, quatro perguntas resolvem quase tudo. Quanto atraso o processo tolera de verdade, medido pelo prejuízo real de esperar? O fluxo é de mão única ou os dois sistemas podem alterar o mesmo dado? Qual o volume esperado no pico, não na média? E o que acontece com o negócio se essa conexão ficar fora do ar — alguém deixa de vender, de faturar, de atender?

As decisões que vêm antes de qualquer integração de sistemas

Estas decisões são de negócio. Se você delegá-las ao fornecedor, ele vai decidir por você, e vai decidir pelo que é mais fácil de programar.

• Defina o sistema-fonte de cada entidade, uma por uma: cliente, produto, preço, pedido, contrato. Uma entidade, um dono. Onde houver dois donos, haverá conflito diário.
• Escreva o que acontece quando os dois lados divergem. O sistema-fonte sobrescreve, o registro fica retido para revisão humana, ou a alteração é rejeitada? Não existe resposta universal, mas existe resposta obrigatória.
• Escolha a chave de identificação e diga quem garante o preenchimento dela. Defina também o destino do registro que chega sem chave: ele entra numa fila de exceção com responsável ou é descartado com aviso.
• Monte um dicionário mínimo dos campos que atravessam, com o significado de cada um e a lista de valores aceitos. Esse documento é o que impede a discussão de acabar em “mas para mim status ativo quer dizer outra coisa”.
• Determine a direção do fluxo campo a campo, não sistema a sistema. É comum o cadastro fluir num sentido e o dado financeiro no sentido oposto, e tratar tudo em bloco cria sobrescrita indesejada.
• Decida o que fazer com o histórico. A integração carrega o passado ou passa a valer só para o que é novo? Se carrega, qual o critério de corte e quem valida a carga inicial?
• Nomeie quem é acionado quando a integração falha e em quanto tempo, por escrito, com nome de pessoa e canal. Falha sem dono vira falha permanente.

Empresas que chegam a este ponto sem um mapa claro de entidades e responsáveis costumam ganhar mais montando primeiro a serviço de estrutura de dados da Better Consultoria do que contratando conexões avulsas.

Como saber se a integração continua funcionando depois de entrar no ar

Integração não é entregável, é serviço contínuo. Ela envelhece: o fornecedor da outra ponta muda a API, alguém cria um campo novo na tela, um usuário passa a usar um status de um jeito que ninguém previu.

Monitore a fila e o erro, não só o sucesso. Um painel que mostra quantos registros passaram é inútil se não mostra quantos falharam e por quê. O registro que falhou precisa ficar visível, nomeado e recuperável — não pode simplesmente sumir.

Faça reconciliação periódica: conte os registros dos dois lados no mesmo recorte e compare. Divergência é normal em alguma medida; divergência sem explicação e sem responsável é que é problema. Combine desde o início quem olha esse número e o que ele faz quando a diferença cresce.

Crie alerta de silêncio. Se nenhuma mensagem chegou desde ontem, isso pode significar que não houve movimento — ou que a conexão caiu e ninguém percebeu. Sistema que só avisa quando dá erro não avisa quando para de tentar.

Teste com os registros que quebram, não com o caso feliz. Cliente estrangeiro sem CNPJ, pedido cancelado depois de faturado, cadastro que muda de razão social, devolução parcial, item com unidade de medida diferente da usual. É nesses que a integração revela o que não foi combinado.

E garanta que o erro seja legível para quem não é da TI. Se apenas o time técnico enxerga a falha, quem descobre o problema é o cliente, por telefone.

Os erros que condenam a integração e o que perguntar ao fornecedor

Alguns erros aparecem com tanta regularidade que valem como alerta antecipado.

• Integrar antes de limpar o cadastro apenas distribui a sujeira mais rápido, e agora com aparência de sistema confiável.
• Deixar o fornecedor definir regra de negócio faz a empresa herdar decisões que ninguém do negócio tomou.
• Tratar a integração como projeto com data de fim, sem dono depois da entrega, garante que a primeira mudança de API vire incidente.
• Aceitar a entrega sem a documentação do mapeamento de campos deixa você refém: quando quebrar, ninguém sabe o que era para acontecer.
• Automatizar um processo que ninguém desenhou apenas acelera a bagunça que já existia. A discussão sobre desenhar antes de automatizar aparece em RevOps na prática, integrando marketing, vendas e atendimento.

Na conversa comercial, faça perguntas que exigem resposta verificável. Pergunte quantos projetos de integração daquele fornecedor seguem em uso um ano depois da entrega, e peça para falar com um desses clientes. Pergunte quem fica com a documentação do mapeamento e em que formato ela é entregue. Pergunte o que acontece quando a API de um terceiro muda: quem detecta, quem corrige e quem paga. Pergunte como o erro é apresentado a quem não é técnico. Pergunte de quem é a credencial de acesso aos sistemas e o que acontece com ela se o contrato terminar. E peça o plano de reversão: se a integração precisar ser desligada, como a operação continua funcionando enquanto isso.

Checklist antes de aprovar o projeto de integração de sistemas

Leve esta lista para a reunião de aprovação e só assine com todas respondidas por escrito.

• Cada entidade relevante tem um sistema-fonte declarado, e ninguém discorda dele.
• Existe uma chave de identificação definida, com responsável pelo preenchimento e um destino combinado para o registro sem chave.
• O dicionário de campos que atravessam está escrito, com significado e valores aceitos acordados pelas áreas.
• A regra de conflito está definida por campo, incluindo o que fica para revisão humana.
• O modelo de integração escolhido corresponde à latência que o processo realmente exige, e não à que soa melhor na apresentação.
• Há monitoramento de erro e de silêncio, com destinatário nomeado para o alerta.
• Existe rotina de reconciliação, com dono e periodicidade combinados.
• A documentação do mapeamento faz parte do escopo da entrega, não é cortesia.
• Está claro quem sustenta a integração depois que o projeto acaba, e sob que condições.
• Existe plano de reversão descrito, e alguém já leu esse plano em voz alta na reunião.

Próximo passo

Se a sua operação hoje depende de alguém conciliar planilha para saber o que aconteceu, o problema raramente se resolve comprando mais uma ferramenta. Ele se resolve decidindo quem é dono de cada dado, o que cada campo significa e como o erro aparece para quem precisa agir.

A Better Consultoria trabalha exatamente nesse ponto: desenhar o ecossistema de plataformas do estágio em que a empresa está, definir a estrutura de dados que sustenta a integração e acompanhar o que acontece depois que tudo entra no ar. Se você quer sair do diagnóstico e entrar na decisão, vale agendar uma conversa com a Better Consultoria levando a lista acima com as respostas que você já tem — e, principalmente, com as que ainda faltam.