Leonardo Peron5 min de leitura
Quem pergunta "o que é integração de ERP" costuma receber respostas diferentes na mesma reunião. Uma pessoa entende relatório, outra entende exportar planilha, outra entende trocar de sistema. As três descrevem coisas que existem e nenhuma delas é integração — e a confusão sai cara, porque o projeto é orçado com um significado e cobrado com outro.
A definição, sem enfeite
Integrar o ERP é fazer com que ele e outro sistema mantenham o mesmo dado sem ninguém redigitar. O pedido nasce na loja e aparece no ERP; o saldo é decidido no ERP e chega ao canal de venda; a nota emitida volta para o sistema que precisa dela.
A parte que a frase esconde é a interessante. Manter o mesmo dado em dois lugares exige decidir quem decide: qual dos dois lados é a autoridade sobre cada informação e qual apenas guarda cópia. Sem essa decisão não existe integração, existem dois sistemas se sobrescrevendo em turnos — o assunto de quem é o dono do cadastro.
Exige também decidir o que acontece quando a troca falha, porque ela vai falhar. Um projeto de integração é, na maior parte do tempo, o desenho de o que fazer quando o outro lado não responde e quando os dois lados discordam.
O que integração não é
Não é relatório. Relatório é leitura: alguém pede um recorte do dado e o sistema devolve para uma pessoa olhar. Ninguém escreve nada do outro lado, e por isso relatório não precisa de regra de conflito, de repetição segura, nem de fila. É um problema muito menor, fica pronto rápido e cria a expectativa errada sobre o resto.
Não é exportar planilha. A exportação move dado, o que a faz parecer integração de longe. Falta tudo o que não é o transporte: saber se o arquivo foi lido, o que fazer quando ele chega duas vezes, corrigir um registro sem alguém refazer o caminho à mão. Planilha entre sistemas é uma pessoa disfarçada de rotina.
Não é trocar de ERP. É a confusão mais cara das três: as duas resolvem sintomas parecidos com ordens de grandeza diferentes de risco. A comparação entre integrar ou trocar o ERP existe para separar as duas decisões antes de alguém assumir a errada.
Os três formatos que aparecem na prática
Arquivo. Um sistema grava um arquivo numa pasta ou num servidor de transferência, e o outro lê de tempos em tempos. É o formato mais antigo e o mais universal: sistema que não tem mais nada tem isso. O custo é o atraso, que é o intervalo entre as rodadas, e a cegueira — o lado que gravou não sabe se o outro leu, e o lado que leu não sabe se o arquivo está completo ou ainda está sendo escrito.
API. O sistema expõe operações que o outro chama sob demanda, com resposta imediata e erro nomeado quando algo dá errado. É o formato que permite reagir no momento em que o fato acontece, sozinho ou combinado com aviso de mudança — a escolha entre esperar o aviso e ir buscar é o tema de webhook ou consulta periódica. Quando existe API, ela ganha das outras duas, e a discussão passa a ser sobre o que ela expõe e o que ela não expõe.
Banco direto. Ler, e às vezes escrever, nas tabelas do ERP. Parece o mais barato dos três: o dado está ali, sem intermediário, sem cota, sem espera.
Por que o terceiro é o que mais dói depois
O banco de um ERP não é um contrato — é a implementação dele. Ninguém prometeu que aquela tabela vai continuar existindo, nem que aquela coluna vai continuar significando a mesma coisa. Uma atualização de versão renomeia, divide ou reaproveita campo, e a integração descobre isso em produção, sem erro claro, com dado errado em vez de dado ausente.
A leitura já tem esse problema. A escrita tem um pior: o ERP aplica regra ao gravar — imposto, saldo, histórico, validação de estado. Escrevendo direto na tabela, tudo isso é pulado. O resultado é um registro que existe no banco e que o sistema considera impossível, e o defeito aparece longe da causa, num fechamento, meses depois.
Vale como último recurso, com escrita fora de cogitação e com cada atualização do ERP tratada como risco a reavaliar. O que não vale é escolher esse caminho por ser o mais rápido de começar.
As perguntas que definem o escopo
Antes de orçar qualquer integração, estas respostas mudam mais o projeto do que a escolha da tecnologia. Escreva-as, e escreva com quem opera:
- Quais entidades atravessam a fronteira? Produto, preço, saldo, cliente, pedido, status, documento fiscal, financeiro. Cada uma é um projeto pequeno com regra própria, e é a quantidade delas que dita o tamanho — não a quantidade de sistemas.
- Em que direção cada uma anda, e quem é o dono? Campo a campo, o suficiente para caber numa tabela como a do de-para. O mapeador de de-para serve para começar essa planilha hoje.
- Qual atraso é aceitável em cada uma? Saldo em campanha e cadastro de fornecedor não toleram a mesma espera, e tratar tudo na mesma frequência custa caro sem melhorar nada.
- O que acontece quando falha? Onde o que não passou fica visível, quem olha, e como reprocessar sem duplicar.
- Quem decide as regras de negócio e quem opera isso depois? As duas respostas são de pessoas, não de software, e são as que mais mexem no prazo.
Uma integração descrita por essas cinco respostas já é um escopo. Descrita como "ligar o ERP na loja", é um pedido de orçamento que ninguém responde com honestidade — e o levantamento começa exatamente por elas.