Integração sem projeto infinito/2026: primeiro corredor, primeiro ganho

A palavra “integração” em comércio exterior carrega um peso desproporcional. O Head de Comex quer conectar sistemas. O TI ouve “refazer o ERP”. A Diretoria vê 18 meses de projeto, orçamento incerto e resultado distante. O resultado previsível: a decisão é adiada. E a operação continua rodando com planilhas, e-mails e redigitação — esperando o “momento certo” que nunca chega.

O FollowNet One (e.Mix) dá visibilidade ponta a ponta à cadeia de importação e exportação — da PO ao recebimento na planta. Automatiza consultas em portais governamentais, tracking com armadores e comunicação com parceiros em uma única interface. Neste artigo mostramos como começar a integração pelo menor recorte possível — um corredor, um parceiro, um módulo — e escalar a partir do primeiro resultado.

• O problema: integração percebida como projeto de 12+ meses que paralisa a decisão
• O custo/risco: cada mês de adiamento é mais um mês de planilhas, redigitação e desvios invisíveis
• O mecanismo: integração por eventos + escopo mínimo no primeiro corredor + escala progressiva
• Como começar: escolher 1 corredor, configurar 1 módulo, rodar por 30 dias e medir

O mito do “projeto grande” — por que integração não precisa ser tudo ou nada

A maioria dos projetos de integração que não saem do papel compartilham o mesmo erro: escopo ambicioso demais no dia 1. Conectar todos os corredores, todos os parceiros, todos os módulos, todos os ERPs. O projeto de 3 meses vira 12. O de 12 vira “em andamento”.

A alternativa é inverter a lógica. Em vez de desenhar a arquitetura completa e implementar de uma vez, comece pelo corredor com maior volume ou maior dor. Configure o mínimo necessário para gerar visibilidade nesse corredor. Rode por 30 dias. Meça. Depois expanda.

Em análises de cenários que realizamos em operações industriais, os pontos sensíveis mais documentados são: gestão em planilhas, redigitação de dados em sistemas diferentes, consultas manuais em portais governamentais e dependência de parceiros para obter status. Cada um desses pontos é resolvível de forma incremental — sem “refazer o ERP”.

Integração no Comex não precisa ser tudo ou nada — precisa ser um corredor, um resultado e uma decisão de escalar baseada em evidência.

O playbook de 7 dias — do zero ao primeiro corredor funcionando

Dia 1-2 — Escolha o corredor e o escopo mínimo

Critério de escolha do corredor: maior volume de embarques OU maior incidência de problemas (atrasos, demurrage, retrabalho). Não escolha o corredor mais complexo — escolha o que gera mais dor.

Escopo mínimo para o primeiro corredor:

• Tracking automatizado com armadores (elimina consulta manual)
• GRID operacional com os campos essenciais (elimina planilha de FUP)
• Alertas de demurrage (D-7 e D-3)
• 1 dashboard com faróis por etapa

Esse escopo cobre 80% da dor com 20% do esforço.

Dia 3-4 — Configure e migre os processos ativos

Não espere a virada do mês. Migre os processos em andamento do corredor escolhido para o sistema. Configure os campos do GRID, as regras de alerta e os faróis do dashboard.

Dica prática: a carga de dados (importação de planilhas existentes) acelera a migração. Não redigite — importe.

Dia 5-6 — Treine o time no corredor piloto

O treinamento não é sobre o sistema inteiro. É sobre o fluxo específico do corredor piloto: “abri o GRID → vi o alerta → tomei a ação → registrei a evidência”. Foco em execução, não em funcionalidades.

Dia 7 — Rode o primeiro dia real e registre aprendizados

O primeiro dia com o corredor no sistema vai revelar ajustes necessários: campos que faltam, alertas que precisam de calibração, etapas que não ficaram claras. Registre tudo. Ajuste na semana seguinte.

O que acontece nos 30 dias seguintes

O corredor piloto roda sozinho por 30 dias. Nesse período, três coisas acontecem:

Semana 1-2: O time se adapta. As consultas manuais param. Os alertas começam a funcionar. Surgem ajustes finos (campo extra, regra de alerta com limiar diferente). Normal.

Semana 3-4: Os primeiros indicadores aparecem: tempo médio por etapa, desvios mais frequentes, processos parados sem dono. O gestor começa a usar o dashboard para decisão — não apenas para visualização.

Após 30 dias: Reunião de resultado. Comparar: quantas consultas manuais foram eliminadas? Quantos alertas de demurrage dispararam antes do vencimento? Qual o tempo médio de desembaraço no corredor piloto vs. antes?

Com esses dados, a decisão de expandir para o segundo corredor é baseada em evidência — não em expectativa.

Bloco salvável — Checklist do primeiro corredor

• Corredor escolhido: _____ (ex.: China → Santos FCL)
• Critério de escolha: _____ (volume / dor / custo)
• Escopo mínimo definido: tracking + GRID + alertas demurrage + dashboard
• Processos ativos migrados (carga de dados)
• GRID configurado com campos essenciais
• Regras de alerta calibradas (D-7, D-3, aging 3 dias)
• Dashboard com faróis por etapa criado
• Time treinado no fluxo do corredor piloto
• Data de início do piloto: _____
• Data da reunião de resultado (D+30): _____
• KPIs para medir: consultas manuais eliminadas, alertas úteis, tempo médio por etapa

Prova em campo — “primeiro GRID, 3 meses, já sentiu a diferença”

Resultado percebido em 3 meses a partir do primeiro GRID de uma grande conta — evolução progressiva

Antes: Múltiplos sistemas, intervenientes no processo (Siscarga, CCT, Mercante), trabalho manual para cruzar informações
Depois: “Quando a gente concluiu o primeiro GRID de uma grande conta, em 3 meses a gente já sentiu a diferença.” Funcionalidades são muitas — “trabalho a 4 mãos”, expansão contínua.

Vídeo: https://youtu.be/jEmbRrfwu60?t=338
Antonio Dantas — Managing Director — Crane Worldwide Logistics

Antonio resume a lógica de forma direta: começou pelo primeiro GRID de uma grande conta. Em 3 meses, a diferença já era perceptível. E complementa: “Não para. A gente ainda tá olhando como pode agregar mais, como pode maximizar. As funcionalidades que o sistema tem são muitas. E é um trabalho a 4 mãos.” O ponto-chave: não tentou integrar tudo de uma vez. Começou por um recorte, validou o resultado, e agora expande progressivamente — sem “projeto infinito”.

Ação prática — comece esta semana

Esta semana: defina o corredor piloto usando o critério de maior volume ou maior dor. Liste os processos ativos nesse corredor.

Semana que vem: configure o escopo mínimo (tracking + GRID + alertas + dashboard). Migre os processos ativos via carga de dados.

Em 30 dias: faça a reunião de resultado. Compare antes vs. depois. Decida o segundo corredor.

• Owner: Head de Comex + TI/ERP Owner (co-responsáveis pelo piloto)
• Cadência: check diário na primeira semana, semanal depois, reunião de resultado em D+30
• KPI farol: nº de consultas manuais eliminadas + nº de alertas úteis por semana
• Primeiro recorte: corredor com maior volume ou maior custo de desvio

Conclusão — 1 corredor, 1 resultado, depois escala

Plano resumido:

1. Escolher 1 corredor (maior volume ou maior dor) e definir escopo mínimo
2. Configurar em 7 dias: tracking + GRID + alertas + dashboard
3. Rodar 30 dias, medir, e decidir expansão com base em evidência

Resultado esperado: em 30 dias, o corredor piloto opera sem planilhas de FUP, com tracking automatizado e alertas de demurrage funcionando. Em 90 dias — como a Crane experimentou — a diferença é evidente e a decisão de expandir é natural.

Risco de não agir: a cada mês de adiamento, a operação acumula mais redigitação, mais consultas manuais e mais desvios invisíveis. O “projeto grande” continua sendo adiado. E os custos de não integrar continuam sendo pagos — silenciosamente, todo mês.

Leia também: — resultados reais de implementação progressiva

• Por que o “Go-Live” é apenas o começo — a metodologia de melhoria contínua pós-implantação
• Demurrage de contêiner: o que é e como evitar — um dos primeiros custos eliminados no corredor piloto
• Por que seu ERP legado não é desculpa para adiar a automação — quebrando o mito da integração completa

📖 Leia o guia completo: Planilha vs. sistema no Comex: guia completo