Sistemas que não conversam entre si: quando integrar é melhor do que substituir

Se sua equipe precisa copiar a mesma informação de um sistema para outro, provavelmente existe um problema de integração. O ERP pode funcionar. O comercial pode funcionar. O chão de fábrica, o financeiro ou o laboratório também. Cada ferramenta, isolada, até atende o que foi contratada para fazer.

O desgaste aparece no meio do caminho: a mesma nota é digitada duas vezes; o pedido sai de um sistema e entra em outro por planilha; o fechamento do dia só acontece depois que alguém “consolida” arquivos. A operação não sofre por ausência de software. Sofre porque os sistemas não conversam.

Nesse cenário, a tentação recorrente é substituir tudo por um pacote único. Às vezes isso se justifica. Com frequência, porém, os sistemas atuais ainda servem bem às suas áreas — e o que falta é uma camada que faça a informação circular com regra, rastreio e menos retrabalho.

O decisor raramente chega pedindo “middleware” ou “API”. Chega descrevendo o dia a dia. Os sinais abaixo costumam aparecer juntos:

Sistemas desconectados quase nunca nascem de uma decisão única e consciente. Acumulam-se. O ERP veio em um ciclo de investimento. O CRM, em outro. Um sistema de chão de fábrica ou de laboratório foi fornecido junto com o equipamento. Um legado interno continua porque a operação depende dele. Cada área escolheu o que resolvia a dor daquele momento.

O resultado é um conjunto heterogêneo: bancos de dados diferentes, formatos de código diferentes, janelas de disponibilidade diferentes. Muitos produtos de mercado expõem pouca ou nenhuma interface estável. Sistemas antigos foram feitos para tela e relatório, não para conversar com outro software. Sem um contrato claro de dados, a “integração” vira arquivo compartilhado e combinado informal.

Há ainda o fator organizacional. TI, operação e cada gerência enxergam o próprio sistema como território. Integrar exige decidir quem é a fonte da verdade para cliente, pedido, estoque ou apontamento. Enquanto essa decisão não existe, a planilha ocupa o vazio — e o vazio cresce.

Diante de sistemas que não conversam, as empresas costumam oscilar entre quatro caminhos. Nenhum é universalmente certo; o erro é escolher por impaciência.

O primeiro é manter o manual: continuar exportando, digitando e consolidando. É o caminho de menor decisão imediata e de maior custo invisível — tempo de gente boa gasto em transporte de dado, além de divergência crônica.

O segundo é substituir o conjunto por um sistema único. Faz sentido quando as ferramentas atuais já não representam o processo, ou quando a customização de um pacote se aproxima do esforço de construir o que a operação realmente precisa. Essa decisão, porém, é outra conversa: quando vale sistema sob medida em vez de software pronto. Trocar tudo para “eliminar integração” frequentemente só desloca o problema.

O terceiro é integrar o que já existe. Na prática, isso pode significar APIs para que um sistema publique e o outro consuma eventos de negócio; sincronização periódica ou quase contínua entre cadastros; uma camada intermediária (middleware) quando há vários pontos, filas e necessidade de tolerar queda de um dos lados; leitura controlada de banco quando o sistema legado não oferece interface; e automação da troca que hoje depende de arquivo e de pessoa.

O quarto é um híbrido responsável: encapsular o legado, integrar o que é estável e substituir apenas o módulo que realmente emperra. Integração e modernização não são opostos. Muitas vezes a integração é o primeiro passo para não ficar refém de um único sistema antigo.

A integração de sistemas tende a ser o caminho mais racional quando os sistemas atuais ainda resolvem bem o trabalho de cada área, e a dor está no fluxo entre eles. Se o ERP fatura corretamente, o sistema operacional controla a regra da ponta e o problema é os dois não se falarem, substituir um deles só para “ficar tudo no mesmo lugar” costuma ser desproporcional.

Também faz sentido integrar quando a operação não pode parar para um projeto de troca total; quando há regras de negócio já consolidadas nas ferramentas existentes; quando o legado ainda é a fonte de verdade de um cadastro crítico; e quando a empresa precisa de rastreio da troca — quem enviou o quê, quando, e o que falhou — em vez de um e-mail com planilha anexa.

Em um exemplo hipotético, uma indústria usa um ERP de mercado para fiscal e estoque, um sistema interno para a regra de produção e uma planilha para reconciliar os dois no fim do turno. Se os dois sistemas atendem suas funções, o ganho está em sincronizar pedido, apontamento e saldo com regra e auditoria — não em reescrever o ERP nem o chão de fábrica de uma vez.

Integrar não é o reflexo certo em todo cenário. Se um dos sistemas já não representa o processo, encapsulá-lo apenas prolonga um fluxo ruim. Se a ferramenta exige contornos permanentes — planilhas, macros, cadastros paralelos — o problema pode ser adequação do software à operação, não apenas a falta de conector.

Também é frágil insistir em integração quando o sistema antigo não oferece interface viável, o banco é opaco e qualquer leitura ameaça a estabilidade da produção. Nesses casos, o diagnóstico pode indicar encapsulamento cuidadoso, ou modernização de um módulo, antes de uma sincronização ambiciosa.

Se a “integração” desejada for apenas copiar tudo para todo lado, sem dono da verdade, o projeto cria divergência automatizada: os mesmos erros, mais rápidos. Integração exige regra. Sem regra, é melhor não ligar os sistemas.

O risco mais comum é chamar de integração o que é só um arquivo em pasta compartilhada. Esse arranjo quebra quando alguém muda uma coluna, um acento ou o horário do job. Não há fila, não há retratação clara, não há dono do erro.

Outro risco é sincronizar sem definir a fonte da verdade. Cliente alterado nos dois lados, pedido reenviado, estoque corrigido duas vezes: o conector vira gerador de conflito. Integração séria trata idempotência, duplicidade e exceção — não apenas o “caminho feliz”.

Há ainda o acoplamento ponta a ponta: um sistema chama o outro em horário de pico e os dois travam juntos. Uma camada intermediária existe, quando faz sentido, justamente para desacoplar, registrar e retentar. Por fim, integrar sem observabilidade deixa a operação cega: o dado “não chegou” e ninguém sabe se o envio falhou, o destino recusou ou a regra de conversão descartou o registro.

A PROLS parte do fluxo real, não do catálogo de conectores. O primeiro passo é entender quais informações cruzam fronteiras hoje, quem as move, onde divergem e o que a operação não pode perder. Só então se discute API, banco, fila ou sincronização.

Na prática, o trabalho costuma incluir inventário das interfaces existentes (e das que não existem), definição de contratos de dados, escolha da origem da verdade para cada entidade, e uma camada de integração que suporte falha temporária de um dos lados. Sistemas legados entram no desenho como são — com encapsulamento e APIs quando isso reduz risco — em vez de serem tratados como obstáculo a ser apagado no primeiro dia.

O objetivo não é “unificar tudo num único software”. É fazer as ferramentas da empresa operarem como um conjunto coerente, com menos digitação duplicada e com rastreio da troca. Se o seu caso é este, o caminho natural é a integração de sistemas. Se a dúvida for se algum dos sistemas sequer deveria continuar existindo, o ponto de partida é outro: a adequação da ferramenta ao processo, não o conector.