Nenhuma empresa decide ter oito planilhas paralelas ao ERP. Elas aparecem uma a uma, cada uma resolvendo um problema legítimo, e um ano depois ninguém sabe mais qual número é o certo.
Os três sintomas de que falta integração
Não é preciso diagnóstico para reconhecê-los. Se dois dos três estão presentes, o problema já custa dinheiro:
- Redigitação. Alguém lê um número de um lugar e digita em outro. Cada redigitação é uma chance de erro e um atraso, e normalmente ocupa uma pessoa boa fazendo trabalho que não precisa existir.
- Números que não batem. A produção diz uma coisa, o ERP diz outra, a diretoria recebe uma terceira. A reunião gasta a primeira meia hora decidindo qual número é o verdadeiro, em vez de decidindo o que fazer.
- Informação que chega tarde. O relatório de ontem no meio da manhã de hoje. Quando o dado chega, a decisão que ele deveria orientar já foi tomada no escuro.
O terceiro é o mais caro e o menos visível, porque o custo não aparece em lugar nenhum da contabilidade. Ele aparece como margem que vazou numa ordem que seguiu errada por um turno inteiro.
Integrar não é trocar o ERP
A conclusão apressada quando a operação trava é que o ERP é ruim e precisa ser substituído. Na maior parte das vezes isso é caro, demorado e desnecessário — e a troca recria o mesmo problema dois anos depois, porque a causa raramente era o ERP.
ERPs são bons no que foram feitos para fazer: financeiro, fiscal, estoque, compras, faturamento. Eles são genéricos por natureza, porque precisam servir a milhares de empresas diferentes. O que eles não cobrem bem é justamente o que a sua empresa faz de específico — a forma como você programa a produção, apura o custo de uma ordem, controla a qualidade de um lote, acompanha uma obra ou uma frota. Esse pedaço específico não é falha do ERP; é o limite do conceito.
A estratégia que funciona é manter o ERP como base de registro e construir em volta dele o que falta, conectado. O ERP continua sendo a verdade do fiscal e do financeiro; o sistema específico passa a ser a verdade da operação; e os dois trocam dados sem ninguém no meio digitando.
Os quatro caminhos técnicos
A escolha não é de gosto — ela é ditada pelo que o fornecedor do ERP libera e pelo tipo de dado. Em ordem de preferência:
| Caminho | Quando é o certo | O que custa |
|---|---|---|
| API | O ERP expõe serviços documentados. É o caminho mais estável: sobrevive a atualizações do fornecedor e respeita as regras de negócio do próprio ERP. | Depende de o fornecedor liberar — e às vezes cobrar por — o acesso. |
| Banco de dados | Não há API, mas há acesso de leitura ao banco. Serve bem para extrair dado; para escrever, é arriscado, porque passa por cima das validações do sistema. | Quebra quando o fornecedor muda o modelo de dados numa atualização. |
| Arquivo | Troca por CSV, XML ou layout posicional em intervalos definidos. Menos elegante e perfeitamente adequado para dado que não precisa ser instantâneo. | Tem latência por desenho e exige tratamento de falha e reprocessamento. |
| Automação de interface (RPA) | Último recurso, quando não há API, nem banco, nem arquivo — um robô opera a tela como um humano operaria. | Frágil: qualquer mudança de layout quebra. Serve como ponte temporária, não como arquitetura. |
Vale insistir no último: RPA é ponte, não destino. Ele resolve rápido e cria uma dependência que ninguém documenta. Quando for a única opção, trate como provisório e registre por que foi necessário.
Quando o sistema é legado
Sistema legado é aquele que ainda sustenta a operação e ninguém quer tocar — normalmente porque quem o construiu não está mais na empresa, a documentação não existe e ele funciona. Às vezes o fornecedor sumiu. Às vezes ele roda numa tecnologia que ninguém mais domina.
A tentação é reescrever tudo. É a decisão mais arriscada disponível: reescrever um sistema que ninguém entende por completo significa descobrir as regras de negócio esquecidas uma a uma, em produção. O caminho mais seguro é diferente:
- Cercar antes de substituir. Construir o novo em volta, lendo os dados do legado, sem mexer nele.
- Mover por pedaço. Uma função por vez, com o legado ainda no ar como rede de segurança.
- Documentar enquanto move. Cada regra descoberta vira documentação — é o único momento em que alguém está olhando para ela.
- Desligar só quando nada mais depender. E confirmar isso medindo, não perguntando.
A parte que não é técnica (e costuma ser a difícil)
Integração fracassa mais por acordo do que por tecnologia. Três perguntas precisam ter dono antes da primeira linha de código:
- Qual sistema manda em cada dado? Se o cadastro de cliente existe em dois lugares, um dos dois precisa ser o oficial. Sem essa definição, a integração propaga divergência mais rápido do que a redigitação propagava.
- O que fazer quando os dois discordam? Sobrescreve, rejeita, ou avisa alguém? Essa regra precisa ser decidida por quem responde pelo processo, não pelo desenvolvedor.
- Quem é avisado quando falha? Integração cai — rede, atualização, dado fora do padrão. O problema não é cair; é cair em silêncio e ninguém perceber por três dias.
Há ainda um item que não é técnico nem contratual: o cadastro. Boa parte dos projetos de integração descobre, na primeira semana, que o mesmo cliente está gravado de quatro jeitos diferentes. Limpar cadastro é chato, não tem glamour nenhum e é pré-requisito real.
Por onde começar
Não por todos os sistemas. Escolha um processo, de ponta a ponta — do pedido à entrega, da ordem ao faturamento, da requisição à compra — e integre esse. Um processo inteiro funcionando prova o caminho, gera resultado visível e ensina o que a próxima integração vai encontrar. Integrar dez sistemas pela metade não entrega nada.
O critério de escolha do primeiro processo é simples: aquele em que a redigitação é maior e o erro dói mais.
Como a Origami Lab trabalha isso
Começamos pelo diagnóstico dentro da operação — de duas a quatro semanas mapeando o processo real, não o desenhado, e mostrando onde o dado para. Depois priorizamos por retorno, desenhamos com quem executa, construímos em ciclos curtos com entregas quinzenais e acompanhamos até a sua equipe conduzir sozinha. O ERP continua sendo o ERP; nós construímos e conectamos o que falta em volta dele.
Quando o que falta não existe no mercado, o assunto vira desenvolvimento sob medida. E quando o projeto tem incerteza técnica de verdade, parte dele pode se enquadrar na Lei do Bem — o que muda a conta do investimento.
Uma aplicação dessa abordagem é a unificação de produtos digitais em uma plataforma. Em um projeto de plataforma digital, o trabalho conectou jornadas, acesso e contratação de serviços, com integração de contas e planos ao sistema legado.