Integração de sistemas: como fazer ERP, CRM e planilhas conversarem

Integração de sistemas é fazer os programas da empresa trocarem dados sozinhos: o pedido da loja virtual entra no ERP, o lead do site aparece no CRM, a nota emitida volta para o vendedor, sem ninguém copiando de uma tela para outra. Serve para qualquer empresa que já tem dois ou mais sistemas e uma pessoa (ou várias) fazendo a ponte entre eles na mão.

O sinal de que falta integração costuma ser discreto: a planilha de pedidos atualizada toda manhã, o PDF de pedido de compra redigitado no ERP, o vendedor que liga para o financeiro para saber se o cliente está em dia. Tudo funciona, até a pessoa que faz sair de férias.

Integrar bem depende menos da tecnologia e mais de decisões tomadas antes do primeiro código: quem manda em cada dado, como cada campo vira o campo do outro sistema, com que frequência o dado passa e o que acontece quando falha.

Quanto custa o dado redigitado

O custo de digitar a mesma informação duas vezes não aparece em nenhuma linha do orçamento, porque está diluído no salário de quem faz. Ele tem quatro partes, e o tempo é a menor delas.

• Tempo: minutos por registro, multiplicados pelo volume. Um exemplo de conta: 4 minutos para passar cada pedido da loja para o ERP, 60 pedidos por dia, dão 4 horas diárias de uma pessoa só nisso.
• Erro: dígito trocado no CNPJ, preço da tabela antiga, cliente cadastrado duas vezes. O erro aparece depois, na nota rejeitada ou no boleto que volta.
• Atraso: o dado só chega ao segundo sistema quando alguém tem tempo de passar. Nesse intervalo, a loja vende o que o estoque já não tem e o vendedor dá desconto a quem está inadimplente.
• Dependência de pessoa: o processo mora na cabeça de quem faz. Quando essa pessoa falta, a ponte cai.

Essa conta, feita com os números da sua operação, decide se vale integrar e por qual fluxo começar. O raciocínio é o mesmo de priorizar quais processos automatizar primeiro: frequência, volume, regra clara, custo do erro e dependência de sistemas.

Fonte única de verdade: qual sistema manda em cada dado

Fonte única de verdade quer dizer que, para cada tipo de dado, existe um sistema dono: o único lugar onde aquele dado nasce ou é corrigido. Os outros recebem cópia e não editam. Quando dois sistemas podem alterar o mesmo campo, cedo ou tarde eles discordam, e ninguém sabe qual versão vale.

Uma divisão comum numa empresa que vende por loja virtual e por equipe comercial:

A tabela da sua empresa vai ser outra. O que importa é que ela exista por escrito antes da integração e diga, para cada dado, onde ele é corrigido quando está errado.

Quando a sincronização precisa ir nos dois sentidos, a divisão é feita por campo, e não por registro: o telefone de contato pode ter o CRM como dono, enquanto a razão social continua no ERP.

Como fazer o mapeamento de campos

Mapeamento de campos é a tabela de-para que diz, campo a campo, como a informação de um sistema vira a do outro. É o trabalho menos visível e o que mais consome tempo. Os tropeços mais comuns:

• Nomes que parecem iguais e não são: "Nome da empresa" no CRM costuma ser o nome fantasia, e o ERP exige razão social para emitir nota.
• Formatos: CPF e CNPJ com ou sem pontuação, telefone com ou sem código do país, data brasileira ou internacional, valor com vírgula ou ponto.
• Listas fechadas: o status "Ganho" do CRM precisa virar "Pedido aprovado" no ERP, e o "Pix" da loja precisa bater com um código de forma de pagamento do ERP.
• Unidade: a loja vende por unidade, o ERP controla por caixa com 12.
• Campo obrigatório que não existe na origem: o ERP exige NCM (a classificação fiscal da mercadoria), CFOP (o código da natureza da operação) ou inscrição estadual, e o formulário do site nunca pediu. Alguém precisa decidir de onde vem esse valor, ou o registro trava.

Além dos campos, defina a chave de ligação: um identificador que conecta o mesmo registro nos dois lados. O mais seguro é gravar no ERP o código do cliente no CRM, e vice-versa. Ligar registros pelo nome ou pelo e-mail funciona até aparecer o primeiro cliente com dois e-mails ou duas filiais com o mesmo nome.

O de-para é mantido junto com a integração: forma de pagamento nova no ERP muda os dois no mesmo dia.

Tempo real ou em lote: quando usar cada um

Sincronização em tempo real significa que o dado passa para o outro sistema no momento em que acontece, normalmente por um aviso automático (webhook) ou por uma chamada de API disparada pelo evento. Sincronização em lote significa juntar os registros e mandar de uma vez, em intervalos fixos: a cada 15 minutos, a cada hora, toda madrugada.

Tempo real não é sempre melhor. Depende de o sistema de origem saber avisar, gera mais chamadas (e quase toda API limita quantas você pode fazer por minuto) e exige o destino no ar quando o aviso chega. O lote é mais simples de operar e de reprocessar.

As integrações que dão menos trabalho combinam os dois: o evento chega em tempo real e, uma vez por dia, uma rotina compara os dois lados (quantidade de pedidos, soma dos valores) e aponta o que ficou para trás. A diferença entre API e webhook, e quando cada um cabe, está detalhada em API, webhook ou plataforma de integração.

O que fazer quando a integração falha

Toda integração falha em algum momento: a API do ERP sai do ar durante o backup, o produto vendido não tem cadastro, o CNPJ veio com dígito errado. A qualidade dela se mede pelo que acontece nesse momento. Três mecanismos resolvem a maior parte dos casos.

Nova tentativa com espera crescente. Falha passageira (rede instável, serviço ocupado, tempo esgotado) costuma se resolver sozinha, então a integração tenta de novo com intervalos cada vez maiores, até um limite. A documentação de arquitetura da Microsoft descreve esse padrão de repetição e o cuidado central dele: repetir só é seguro quando a operação é idempotente.

Idempotência. Operação idempotente é a que, executada duas vezes, dá o mesmo resultado que executada uma: reenviar o pedido 10482 não cria um segundo pedido no ERP. O jeito comum é usar o número do pedido da loja como chave e verificar, antes de criar, se ele já entrou.

Fila de reprocessamento. Erro permanente não se resolve tentando de novo: produto sem cadastro falha na décima tentativa como na primeira. Depois de algumas tentativas, a mensagem sai do fluxo normal e vai para uma fila separada, com o motivo registrado. Na documentação da AWS, esse recurso aparece como fila de mensagens não entregues, usada justamente para isolar o que não foi processado e descobrir por quê. Alguém corrige a causa (cadastra o produto) e reenvia.

Para isso funcionar, falta o lado humano:

• um alerta que chega para uma pessoa com nome, e não para um e-mail genérico que ninguém lê;
• uma tela com as pendências, o motivo escrito em português e o botão de reenviar;
• um registro de cada envio (o que foi, quando, qual resposta), para saber se o pedido entrou sem abrir código.

Integração sem alerta falha em silêncio, e quem descobre primeiro é o cliente. Os princípios de monitoramento de sites e sistemas valem aqui: saber que parou, por quanto tempo e quem foi avisado.

Como integrar um sistema legado sem API

Sistema legado é o programa antigo que a empresa ainda usa e que não foi feito para conversar com outros. Não ter API (a porta de comunicação padronizada entre programas) só muda o caminho. Em ordem de preferência:

1. Tabela intermediária no banco de dados. Escrever direto nas tabelas do sistema pula as regras de negócio dele; o seguro é gravar numa tabela de entrada que o próprio sistema importa por rotina. Para leitura, uma consulta somente leitura (view) basta.
2. Troca de arquivos. Muitos ERPs antigos importam e exportam CSV, TXT em layout fixo ou XML. A integração deposita o arquivo numa pasta ou num servidor de arquivos (via SFTP) e recolhe o retorno. É mais lento, mas estável e fácil de auditar.
3. Relatórios agendados. Quando o sistema só exporta relatório, dá para ler o arquivo gerado e extrair os dados, enquanto o formato não mudar.
4. Automação de tela (RPA). Um robô de software que clica e digita como uma pessoa faria. É o último recurso: mudança de layout, janela de aviso ou lentidão quebram o fluxo, então ele entra sempre com conferência do resultado.

Converse com o fornecedor do sistema antes. Alguns contratos restringem acesso direto ao banco, e uma atualização de versão pode mudar as tabelas sem aviso. Se o legado virou o gargalo de tudo, o texto sobre sistema sob medida ou software pronto ajuda a pesar as opções.

Exemplos de integração: pedido, lead e nota fiscal

Pedido da loja virtual no ERP

O cliente paga e a loja dispara o aviso de pedido pago. A integração procura o cliente no ERP pelo CPF ou CNPJ e cria o cadastro se ele não existir. Converte cada item pelo SKU (o código do produto na loja) para o código interno, lança frete e desconto e cria o pedido. O ERP devolve o número interno, que volta para a loja com o novo status. As exceções previstas (SKU sem correspondência, cupom que o ERP não reconhece, endereço sem número) vão para a fila, cada uma com seu motivo.

Lead do site no CRM

O formulário do site cria o contato no CRM com a origem registrada (campanha, página, anúncio), verifica duplicidade por e-mail e telefone, distribui para o vendedor pela regra combinada e grava o consentimento dado no formulário. Esse último ponto não é detalhe: dado pessoal que trafega entre sistemas continua sob a LGPD, e estar em ordem com a LGPD em sites e sistemas inclui saber por onde ele passa.

Nota fiscal de volta para quem vende

A NF-e é um documento de existência apenas digital, emitido e armazenado eletronicamente. O ERP continua sendo o único emissor, e os outros sistemas recebem o que ele gerou: a chave de acesso, o XML autorizado e o PDF do DANFE (a representação impressa da nota). A loja muda o pedido para "faturado" e envia a nota ao cliente, o CRM registra a venda na ficha, e o XML segue para a contabilidade sem ninguém baixar e reenviar por e-mail.

Checklist antes de começar uma integração

• Os sistemas envolvidos, com versão, fornecedor e o tipo de acesso que cada um oferece: API, webhook, arquivo ou banco.
• A tabela de quem manda em cada dado, aprovada por quem usa os sistemas, e não só pela TI.
• O de-para de campos e de listas, com os campos obrigatórios resolvidos e a chave de ligação definida.
• A decisão de tempo real ou lote para cada fluxo, com o motivo anotado.
• Um plano de limpeza do cadastro: duplicados e registros incompletos travam a integração no primeiro dia.
• Quem recebe o alerta de falha e quem pode reprocessar.
• Um ambiente de homologação, para não testar em cima da operação.
• Uma amostra de dados reais com as exceções conhecidas: o pedido com dois endereços, a pessoa física que compra como empresa.
• Credenciais só da integração, com a permissão mínima, e não o login de um funcionário.

Com a lista em mãos, escolha um fluxo só, o que hoje consome mais redigitação, e coloque-o de pé do começo ao fim, com fila e alerta, antes de ligar o segundo. É assim que conduzimos a integração de sistemas na Locomotiva Tech: o fluxo nasce num ambiente isolado, é testado com o volume e as exceções reais da operação e entra em produção com um caminho de volta documentado, que desfaz a mudança em um comando se algo sair do esperado.