Poucas frases no mundo de TI são tão perigosas quanto "só precisamos integrar os dois sistemas". O que soa como uma tarefa de semanas frequentemente vira um projeto de 6 meses que consome o dobro do orçamento, atrasa o go-live de outras iniciativas e gera dados inconsistentes nos dois sistemas.
Integração de sistemas é provavelmente o tipo de projeto de TI com maior taxa de atraso e estouro de orçamento no Brasil. E raramente por razões técnicas — quase sempre por falta de planejamento e gestão adequados.
Por que integração é mais complexa do que parece
Quando gestores pedem para "integrar o ERP com o e-commerce", a imagem mental é de dois sistemas que passam a conversar. A realidade é bem diferente:
- Cada sistema tem seu próprio modelo de dados — um "pedido" no ERP não é exatamente o mesmo que um "pedido" no e-commerce
- Os dois sistemas podem ter regras de negócio conflitantes — qual prevalece quando há divergência?
- Timing é crítico — quando um pedido é criado no e-commerce, quando o ERP precisa saber disso? Imediatamente? Em batch de hora em hora?
- O que acontece quando um sistema está fora do ar? O dado se perde? Fica na fila? Quem monitora?
- Como tratar duplicações? Se a mesma mensagem chegar duas vezes, o pedido é criado duas vezes?
Cada um desses pontos é uma decisão de negócio que precisa ser respondida antes de uma linha de código ser escrita. E em projetos mal planejados, essas decisões são tomadas no meio do desenvolvimento — quando mudar custa muito mais.
Os 4 erros que garantem fracasso
1. Tratar integração como projeto técnico, não de negócio
O erro mais frequente: a área de TI lidera o projeto sozinha, sem envolvimento das áreas de negócio que operam os sistemas. Aí o sistema integrado fica tecnicamente funcional mas operacionalmente inútil — porque o fluxo modelado não é o fluxo real da empresa.
Integração bem-sucedida exige que as pessoas que usam o ERP, que operam o e-commerce e que gerenciam o estoque participem ativamente do mapeamento de processos — antes do desenvolvimento.
2. Não mapear o "caminho feliz" E os casos de exceção
Todo mundo pensa no fluxo normal: pedido aprovado no e-commerce → atualiza estoque no ERP → emite nota fiscal. O problema está nas exceções: pedido aprovado mas pagamento estorna depois, produto esgota no meio do processamento, nota fiscal rejeitada pela SEFAZ, endereço inválido para o transportador. Em e-commerce de volume, essas exceções acontecem todo dia.
Integrações que não tratam exceções geram inconsistência de dados — e inconsistência de dados é inimiga do negócio (estoque errado, pedido duplicado, nota fiscal com dado errado).
3. Integrar diretamente, sem camada de mensageria
A integração ponto a ponto mais simples: sistema A chama diretamente a API do sistema B. Funciona bem em ambientes de baixo volume com alta disponibilidade. Em produção real, ambos os sistemas têm janelas de manutenção, picos de carga e falhas ocasionais. Quando o sistema B está fora do ar no momento em que o sistema A tenta enviar um pedido, o que acontece? O pedido se perde?
Integrações robustas usam uma camada de mensageria (fila assíncrona) entre os sistemas, garantindo que nenhum evento seja perdido mesmo que o destino esteja temporariamente indisponível.
4. Não definir ownership dos dados
Quando dois sistemas compartilham dados do cliente (nome, endereço, CPF), quem é a "fonte da verdade"? Se o cliente atualiza o endereço no e-commerce, o ERP é atualizado automaticamente? E se atualizar no ERP, sincroniza de volta? O que acontece se os dois forem atualizados ao mesmo tempo com dados diferentes?
Sem uma decisão explícita sobre qual sistema é master de cada tipo de dado, as integrações criam conflito de dados que vira problema operacional crônico.
O que uma integração bem planejada parece
Antes de qualquer linha de código, um projeto de integração bem conduzido entrega:
- Mapa de sistemas e fluxos: quais sistemas participam, quais dados trafegam, em qual direção e com qual frequência
- Dicionário de dados: como cada campo de um sistema corresponde ao campo do outro — incluindo transformações necessárias
- Catálogo de eventos: lista de todos os eventos que disparam integração (pedido criado, pagamento aprovado, estoque alterado, etc.)
- Tratamento de exceções: o que acontece em cada cenário de falha — retry automático, alerta manual, rollback
- Decisão de master data: qual sistema é autoridade para cada tipo de dado
- Plano de monitoramento: como a equipe vai saber que a integração está falhando silenciosamente
Esse trabalho de discovery e design leva de 2 a 4 semanas dependendo da complexidade. Parece lento no começo — mas economiza meses de retrabalho depois.
Tipos de integração e quando usar cada um
| Tipo | Como funciona | Quando usar | Quando evitar |
|---|---|---|---|
| API REST síncrona | Sistema A chama API do B e espera resposta | Volume baixo, resposta imediata necessária | Alto volume, B pode ficar indisponível |
| Webhook | B notifica A quando algo acontece | Eventos em tempo real com baixo volume | Sem garantia de entrega, volume alto |
| Fila de mensagens (RabbitMQ, SQS) | A publica evento, B consome quando pode | Alto volume, tolerância a latência, resiliência | Quando resposta síncrona é obrigatória |
| ETL / Batch | Sincronização periódica de dados | Relatórios, BI, dados que não precisam ser real-time | Operações transacionais em tempo real |
| iPaaS (Zapier, Make) | Plataforma low-code conecta APIs | Integrações simples, não críticas, baixo volume | Integração crítica de negócio, alto volume |
Como monitorar uma integração em produção
Uma integração que ninguém monitora é uma bomba-relógio. Os problemas silenciosos — mensagem que não chegou, dado que ficou inconsistente, fila que parou de processar — podem passar semanas sem ser detectados, gerando inconsistência acumulada.
Um plano mínimo de monitoramento inclui:
- Alertas quando a fila de mensagens acumula (indica que o consumidor parou)
- Log de cada evento com status (processado, falhou, em retry)
- Dashboard de taxa de erro por fluxo
- Processo de reconciliação periódica (comparar dados entre os sistemas para detectar divergências)
Checklist para o gestor antes de aprovar um projeto de integração
- ☐ O mapeamento de todos os fluxos (incluindo exceções) foi documentado?
- ☐ As áreas de negócio que operam os sistemas participaram do design?
- ☐ A decisão de master data foi tomada e registrada?
- ☐ O plano de monitoramento está no escopo?
- ☐ O ambiente de homologação vai espelhar a produção (incluindo volumes)?
- ☐ O plano de rollback em caso de falha foi definido?
- ☐ Há prazo e responsável para o plano de reconciliação de dados?
Tem um projeto de integração que não está indo bem?
Fazemos diagnóstico de integrações problemáticas e planejamento de integrações novas — com foco em resiliência, monitoramento e consistência de dados. Temos experiência com gateways de pagamento, marketplaces, ERPs e APIs bancárias.
Falar sobre integração →