Integrar não é instalar um conector
A imagem comum de integração é a de ligar dois cabos: escolhe-se uma ferramenta, aponta-se um sistema para o outro e pronto. Projetos assim funcionam por algumas semanas e depois passam a produzir duplicidade, divergência e silêncio.
Integração é, antes de tudo, um acordo sobre a informação. Qual sistema manda em cada dado. Como um mesmo cliente é reconhecido nos dois lados. Nenhuma dessas perguntas é técnica, e todas precisam de resposta antes da primeira linha de código.
Etapa 1 — Inventário e mapa do dado
Liste todos os sistemas em uso, inclusive os que ninguém chama de sistema: a planilha do financeiro, o grupo de mensagens onde os pedidos chegam, o formulário do site. Para cada um, responda: quem usa, qual informação nasce ali e para onde ela precisa ir.
Depois desenhe o caminho atual de cada informação importante, marcando os trechos percorridos por pessoas. Esse desenho revela o que nenhuma reunião revela: alguém, em algum ponto, sustenta a integração da empresa com trabalho manual. Essa pessoa é o melhor informante do projeto e costuma ser a última consultada.
- Inclua os sistemas informais. A planilha-ponte é integração, só que frágil e sem monitoramento.
- Marque a frequência de cada trecho: tempo real, diário, semanal ou fechamento.
- Anote o volume: dez registros por dia e dez mil exigem soluções diferentes.
- Identifique onde a informação é alterada depois de criada — atualização é sempre mais difícil que criação.
Etapa 2 — A fonte da verdade
Para cada tipo de informação, um sistema manda. O cadastro do cliente vive no CRM ou no ERP? O preço praticado é o da tabela comercial ou o do sistema de faturamento? O estoque real é o do galpão ou o do e-commerce?
Essa decisão é de gestão, não de tecnologia, e sem ela a integração vira conflito permanente entre versões da mesma informação. Se dois sistemas podem alterar o mesmo campo, os dois vão alterar — e alguém terá que decidir, sob pressão, qual valor prevalece.
O padrão mais seguro é uma direção principal por tipo de dado, com escrita em um lado só. Quando a alteração nos dois sentidos for inevitável, escreva antes a regra de desempate.
Etapa 3 — A chave de identificação
Duas bases só se conectam se houver forma inequívoca de dizer que o registro de um lado é o mesmo do outro. Essa é a chave, e escolhê-la mal é a causa número um de duplicidade.
| Chave | Onde funciona bem | Onde falha |
|---|---|---|
| CNPJ ou CPF | Bases empresariais com cadastro fiscal completo | Cadastros incompletos, pessoas físicas sem documento informado, filiais com o mesmo CNPJ raiz |
| Contatos e leads de origem digital | Contatos que compartilham o mesmo e-mail corporativo ou trocam de endereço | |
| Código interno | Quando um dos sistemas já é a origem do cadastro | Quando os dois lados criam registro de forma independente |
| Nome e razão social | Nenhum caso — use apenas como apoio à conferência | Grafias diferentes, abreviações, acentuação e espaços produzem duplicidade em escala |
Na prática, o trabalho começa antes: é preciso limpar e deduplicar a base. Conectar duas bases sujas não resolve a sujeira — distribui a sujeira por todos os sistemas, e agora ela se propaga sozinha.
Etapa 4 — A via técnica
A escolha não é preferência: é consequência do que cada sistema permite e do volume envolvido. As opções, em ordem aproximada de robustez:
| Via | Quando usar | Cuidado principal |
|---|---|---|
| API REST | Quando o sistema oferece leitura e escrita documentadas. É o caminho padrão. | Limites de requisição e mudanças de versão da API |
| Webhook | Quando o sistema avisa sozinho ao acontecer algo. Reduz latência e carga. | Entrega duplicada e eventos perdidos exigem tratamento explícito |
| Banco de dados | Sistemas legados sem API, com acesso autorizado ao banco. | Segurança, desempenho e risco de quebra a cada atualização do fornecedor |
| Arquivo agendado | Sistemas que só exportam CSV ou XML em rotina. | Atraso inerente e necessidade de controlar arquivo repetido ou faltante |
| Plataforma de automação | Baixo volume, regras simples, poucos passos. | Custo por execução e limite de complexidade quando o fluxo cresce |
| Camada de integração própria | Muitos sistemas conectados entre si. | Exige manutenção e documentação, mas evita a teia de conexões ponto a ponto |
Tempo real ou em lote?
A resposta depende de uma pergunta simples: qual é o custo de a informação chegar com atraso? Se o cliente compra o que não existe porque o estoque do site é de ontem, a sincronização precisa ser próxima do tempo real. Se o relatório contábil é fechado no dia seguinte, um lote noturno resolve com menos complexidade.
Fazer tudo em tempo real costuma sair caro: cada fluxo instantâneo multiplica chamadas, amplia a exposição a falhas de rede e exige monitoramento mais fino. Reserve-o para o que muda uma decisão.
Etapa 5 — Falha, repetição e monitoramento
O pior cenário em integração não é a falha. É a falha silenciosa, que ninguém percebe por semanas, até o relatório do mês não bater e a reconstituição manual levar dias.
Toda integração séria prevê o erro desde o desenho: registrar cada execução, repetir a tentativa quando a falha for temporária, enfileirar o que não pôde ser processado e alertar alguém quando o problema persistir.
- Cada execução gera registro com data, volume processado e resultado.
- Falhas temporárias, como indisponibilidade de rede, são repetidas automaticamente.
- Registros que falham em definitivo vão para uma fila visível, não somem.
- Existe alerta com destinatário nomeado, não apenas um log que ninguém abre.
- Existe forma de reprocessar um período sem duplicar o que já foi enviado.
- Alguém olha o painel de execução com frequência definida.
Integração sem monitoramento não é integração: é uma aposta de que nada vai mudar nos dois sistemas pelos próximos anos.
O que dá errado com mais frequência
O primeiro erro é integrar antes de limpar. O segundo é não definir a fonte da verdade e descobrir isso quando dois valores divergem em uma reunião de diretoria. O terceiro é testar só com dados bonitos: a operação real tem o cliente sem endereço e o pedido com valor zerado, e é neles que o fluxo quebra.
O quarto é esquecer o histórico. A integração trata do que acontece a partir de agora, mas alguém vai perguntar pelos dados anteriores. Decida no início se haverá carga histórica e de que período.
O quinto é integrar um processo errado. Conectar dois sistemas apenas acelera o que já acontece — se o processo tem uma etapa desnecessária, ela passa a ser executada mais rápido e com menos gente prestando atenção. Vale revisar o que é automação de processos para separar as duas discussões.
Quando não integrar
Existem situações em que a recomendação correta é esperar — ignorá-las produz projetos descartados poucos meses depois de entregues.
- Quando um dos sistemas será substituído em breve. Espere a definição — integrar com o que vai sair é jogar dinheiro fora.
- Quando não há acordo interno sobre qual sistema é a fonte da verdade. Essa é uma pendência de gestão e nenhum fornecedor pode resolvê-la por você.
- Quando o volume é tão baixo que a manutenção da integração custa mais do que o trabalho manual que ela elimina.
- Quando a base está tão desorganizada que a limpeza é, na verdade, o projeto — e a integração é a etapa seguinte.
Um roteiro de primeiro projeto
Escolha um único fluxo, de preferência unidirecional, com volume relevante e dor reconhecida por todos. Defina a chave, defina a direção, construa, teste com dados reais e monitore antes de expandir.
Esse ciclo tem duas funções: eliminar um trabalho manual e ensinar à empresa como as decisões de integração são tomadas, para que o segundo fluxo custe menos discussão. Quando o desenho envolver muitos sistemas, avalie uma camada de integração em vez de somar ligações diretas que ninguém conseguirá manter.