Projetos de tecnologia na indústria raramente atrasam na parte que todo mundo imagina. A tela fica pronta, o fluxo funciona, a equipe aprova o protótipo. O cronograma começa a escorregar quando o projeto encosta no ERP — e aí ninguém sabe explicar direito por quê.
Os ERPs mudam — Protheus, Sankhya, Senior ou um sistema próprio escrito há vinte anos —, mas os motivos que travam o projeto se repetem. E quase nenhum deles é técnico no sentido estrito: são decisões que deveriam ter sido tomadas antes de a primeira linha de código existir.
1. Ninguém definiu quem é o dono de cada dado
Essa é a origem da maior parte dos problemas. Quando o e-commerce, o portal do cliente ou o app de vendas passa a exibir preço, estoque e limite de crédito, esses números passam a existir em dois lugares. Se ninguém decidiu qual dos dois manda, os dois vão divergir — é questão de tempo.
A definição precisa ser explícita, campo a campo: o ERP é a fonte da verdade para preço, saldo e crédito; o novo sistema é dono da sessão do usuário, do carrinho e do comportamento de navegação. Sem esse acordo escrito, cada divergência vira uma discussão sobre quem está errado, em vez de um ajuste simples.
2. "O ERP tem API" nem sempre significa o que parece
É comum ouvir que a integração será tranquila porque o ERP tem API. Só que "ter API" cobre realidades muito diferentes: pode ser um webservice moderno e documentado, um conjunto de rotinas que devolve XML no formato de 2011, uma pasta onde o sistema deposita arquivos de texto, ou uma view no banco que alguém liberou sem o fornecedor saber.
Cada um desses cenários muda prazo e custo. Vale conferir, antes de assinar: existe documentação atualizada? A API cobre todas as operações necessárias — inclusive gravar pedido, e não só ler cadastro? Ela suporta o volume de consultas que o novo canal vai gerar num dia de pico?
3. Confundir o que precisa ser tempo real com o que pode esperar
Consultar o ERP a cada clique é caro e costuma derrubar a performance — inclusive a do próprio ERP, que continua rodando a operação enquanto isso. Por outro lado, replicar tudo e sincronizar de madrugada faz o cliente comprar item que acabou.
O equilíbrio vem de classificar cada informação:
- Tempo real, sempre: limite de crédito, títulos em aberto, saldo no momento de fechar o pedido
- Atualização frequente: saldo de estoque exibido na vitrine, com margem de segurança
- Replicação com folga: descrição, foto, ficha técnica, categoria
Essa classificação é uma decisão de negócio, não de TI — quem define a margem de segurança do estoque é quem responde por venda e por ruptura.
4. As customizações que o ERP acumulou ao longo dos anos
Todo ERP com mais de uma década de casa tem camadas de customização: aquele campo que virou outra coisa, a rotina que a antiga analista escreveu, a regra de desconto que só existe em uma tela específica.
Nada disso está documentado, e quase sempre aparece no meio do projeto. É o motivo mais comum de replanejamento. Uma sondagem antes da proposta — puxando os campos que serão realmente usados e conferindo o que eles contêm hoje — evita a maior parte dessas surpresas.
5. O fornecedor do ERP também faz parte do projeto
Este ponto costuma passar despercebido no planejamento. Quem desenvolve o novo sistema precisa de acessos, ambientes e, às vezes, de ajustes do lado do ERP — e quem cuida do ERP tem a própria agenda, com outros clientes sendo atendidos em paralelo.
Não é um problema: é uma dependência que precisa aparecer no cronograma e no orçamento. Quando as horas do fornecedor do ERP já estão previstas e existe uma pessoa nomeada dos dois lados, essa etapa costuma fluir bem. Combinar isso antes do kick-off é o que evita a espera lá na frente.
Na prática, todo projeto de integração tem três partes na mesa: a empresa, quem constrói o novo sistema e quem mantém o ERP. Ignorar a terceira é o que transforma duas semanas de trabalho em dois meses de espera.
6. O cadastro que existe não é o cadastro que serve
No ERP, o produto precisa apenas de código, descrição e preço para faturar. Num canal digital, ele precisa de nome legível, foto, medidas, categoria, atributos e texto de apoio.
Por isso é comum descobrir, no meio do projeto, que a descrição cadastrada é CX PARAF SEXT 1/2 ZINC e que não existe foto de metade do catálogo. Isso não é falha do ERP — ele nunca precisou disso. Mas é trabalho real, geralmente da equipe do cliente, e precisa entrar no cronograma desde o começo, com responsável e prazo.
7. Não existe ambiente de homologação
Muitas indústrias rodam o ERP só em produção. Sem uma cópia para testes, cada validação de integração corre o risco de gerar pedido, movimentar estoque ou emitir nota de verdade.
Levantar isso no início costuma ser barato; descobrir na véspera do go-live, não. Vale perguntar já na fase de proposta se existe ambiente de homologação, quão atualizado ele está e quem pode recriá-lo.
O que perguntar antes de assinar
Seis perguntas que antecipam quase todo o risco de uma integração:
- Quais dados o novo sistema vai exibir, e qual sistema é dono de cada um deles?
- A API do ERP cobre leitura e gravação de tudo que o projeto precisa? Existe documentação?
- Quais informações precisam ser tempo real e qual defasagem é aceitável nas demais?
- Existe ambiente de homologação do ERP? Está atualizado?
- Quem, no fornecedor do ERP, será o ponto focal — e essas horas estão previstas?
- Quem, do lado da empresa, é responsável por enriquecer o cadastro, e em que prazo?
Se a proposta que você recebeu não responde a essas perguntas, o prazo dela é uma estimativa otimista — não um compromisso.
Mapear antes de escolher
A escolha da tecnologia é a última decisão, não a primeira. Antes dela vem o desenho de quais dados atravessam a fronteira entre os sistemas, em que direção, com que frequência e sob a responsabilidade de quem. Esse mapa é o que separa uma estimativa confiável de um orçamento que vai ser revisto três vezes.
Foi assim que integramos a nossa plataforma de e-commerce ao ERP da Olist: primeiro o desenho de quem é dono de cada informação, depois o código. É o mesmo caminho para qualquer ERP.
Esse levantamento é o que fazemos no Discovery, um diagnóstico gratuito de 30 minutos. E quando o projeto exige desenvolvimento sob medida, ele já nasce com essas fronteiras definidas — que é o que mantém prazo e custo de pé.