Infraestrutura de rede para ERP cloud em fábrica: o que dimensionar

Quarenta operadoras a fechar turno em simultâneo. O módulo financeiro a gerar o SAF-T. Uma ligação de fibra de 100 Mbps que, no papel, parecia mais do que suficiente. Em onze minutos, os terminais de chão-de-fábrica congelaram e a fábrica parou. A culpa não era do ERP MULTI. Era da rede — e ninguém a tinha dimensionado para este momento.

Este cenário repete-se sistematicamente em fábricas portuguesas que migram para ERP cloud sem rever a infraestrutura de rede. O que se segue não é um manual genérico de networking. É o que vemos em obra — o que falha, por que falha, e o que fazer antes de a produção parar.

A tese que ninguém quer ouvir: a rede é o ERP

Quando um ERP cloud falha numa fábrica, a primeira chamada vai ao fornecedor de software. A segunda vai ao ISP. A terceira — raramente necessária, porque o problema já foi "resolvido" com um reboot — devia ir ao arquiteto de rede. Mas esse papel não existe na maioria das PME industriais portuguesas.

Um ERP cloud não é uma aplicação web. É um conjunto de serviços distribuídos que dependem de latência controlada, largura de banda garantida e segmentação de tráfego. Tratar a ligação à internet como o único vetor de dimensionamento é o erro mais caro — e o mais comum.

A rede não suporta o ERP. A rede é o ERP. Quando a rede falha, o ERP falha. Quando a rede é lenta, o ERP é lento. Não há software que compense má infraestrutura.

O que tornou isto urgente agora: a transição de ERP on-premise para cloud — acelerada pela pressão regulatória do SAF-T em produção industrial, pela necessidade de acesso remoto pós-pandemia e pelos incentivos PT2030 — colocou fábricas com infraestrutura de rede dos anos 2000 a depender de serviços que exigem rede dos anos 2020. O desfasamento é estrutural. E o contexto de ameaça agravou-o: em 2024, o CERT.PT registou 2 758 incidentes de cibersegurança em Portugal, um aumento de 36% face a 2023, com cerca de 78% a ocorrer em entidades privadas (CNCS, 2024). As fábricas não são exceção — são alvo preferencial precisamente porque a infraestrutura de segurança é mais frágil do que em setores regulados.

O que mudou: da LAN local à dependência de WAN

ERP on-premise vs. ERP cloud: o que a rede passa a fazer

Num ERP on-premise, o tráfego crítico circula na LAN local. A latência é de 1–2 ms. O servidor está no mesmo edifício — ou no mesmo corredor. Num ERP cloud, esse tráfego atravessa a WAN, o ISP, o backbone do fornecedor de cloud e volta. Mesmo com um data center em Lisboa ou no Porto, a latência realista é de 15–40 ms em condições normais. Sob carga, pode triplicar.

Para operações de consulta — um comercial a ver stock, um gestor a abrir um dashboard Qlik Sense — 40 ms é imperceptível. Para operações transacionais em tempo real — um terminal KORA Productivity a registar apontamentos de produção a cada 30 segundos, com 60 terminais em simultâneo — 40 ms acumula e torna-se visível. Com jitter (variação de latência), torna-se insuportável.

O pico que ninguém calcula

O erro de dimensionamento mais frequente que vemos: calcular a largura de banda para o utilizador médio, não para o pico simultâneo. Numa fábrica têxtil com 80 operadoras, o fecho de turno das 17h00 gera um pico de 60–70 transações simultâneas em menos de 5 minutos. Se o dimensionamento foi feito para 20 utilizadores concorrentes, a rede colapsa precisamente quando a pressão operacional é máxima.

Há um detalhe que os manuais não referem: o pior momento não é o fecho de turno isolado. É o fecho de turno que coincide com o SAF-T mensal e com um backup que ficou pendente da noite anterior. Os três processos disputam a mesma ligação sem qualquer priorização. É neste cruzamento — não no dia normal — que a rede cede. E é exatamente este cruzamento que o dimensionamento médio ignora.

Não existe um perfil único de tráfego, mas há padrões reconhecíveis. Os apontamentos de MES em tempo real geram muitas transações pequenas e de alta frequência, sensíveis a latência e jitter. A gestão de armazém com a KORA Inventory Suite produz tráfego em rajada, dependente de Wi-Fi industrial com cobertura garantida. A financeira e o reporting criam operações pesadas mas pontuais — o SAF-T mensal, o fecho de mês, os relatórios BI são picos previsíveis mas intensos. A videoconferência e o acesso remoto contendem com o tráfego ERP se não houver QoS configurado. Os backups e a replicação, sem priorização, consomem largura de banda em momentos críticos.

Opções técnicas reais: ligação WAN

Fibra dedicada, fibra partilhada e SD-WAN

Para a maioria das fábricas portuguesas com 50–200 colaboradores, a combinação prática é fibra dedicada como ligação primária e 4G/5G como failover, gerida por um dispositivo SD-WAN. A fibra partilhada como ligação única é um risco operacional — não uma poupança.

O argumento do SD-WAN que os vendedores não explicam

SD-WAN não aumenta a largura de banda disponível. Agrega e gere múltiplas ligações com inteligência de roteamento. Se as duas ligações subjacentes forem de má qualidade, o SD-WAN distribui o tráfego entre duas ligações más. A qualidade da ligação física é insubstituível.

SD-WAN é um multiplicador. Se a base é fraca, multiplica fraqueza. Configure primeiro as ligações físicas; depois ponha inteligência em cima.

Arquitetura interna: LAN, segmentação e Wi-Fi industrial

Segmentação de rede por função

Numa fábrica com ERP cloud, a rede interna precisa de separar pelo menos quatro domínios de tráfego. A rede de produção/OT — terminais de chão-de-fábrica, PLCs, sensores, sistemas MES — deve estar isolada da rede corporativa por firewall ou VLAN com ACLs estritas. A rede corporativa cobre PCs de escritório, ERP, email e videoconferência, com acesso à internet filtrado. A rede de armazém serve leitores de código de barras, terminais de picking e impressoras de etiquetas, dependente de Wi-Fi industrial com cobertura garantida. A rede de gestão — switches, APs, firewalls, servidores de monitorização — tem acesso restrito a administradores.

Esta segmentação não é apenas boa prática de segurança. É um requisito da Diretiva NIS2 (Diretiva (UE) 2022/2555, transposta em Portugal pelo Decreto-Lei n.º 65/2025) para empresas de setores críticos, incluindo a indústria. A separação entre redes OT e IT é explicitamente referenciada nos controlos técnicos NIS2. O artigo NIS2 em profundidade: controlos técnicos para a fábrica portuguesa detalha o enquadramento regulatório.

QoS: priorizar o que importa

Quality of Service é o mecanismo que garante que o tráfego ERP não compete em igualdade com o streaming de vídeo de um colaborador em pausa. Configure filas de prioridade no router de saída e nos switches core. Prioridade máxima para tráfego ERP (identificado por IP de destino do servidor cloud ou por porta/protocolo), VoIP e terminais de produção. Prioridade média para email, acesso remoto e videoconferência gerida. Prioridade baixa para backups, atualizações de software e tráfego não classificado.

Sem QoS, um backup nocturno que começa às 22h e ainda está a correr às 8h da manhã pode consumir 40–60% da largura de banda disponível durante o arranque do turno. Este é o tipo de problema que o IT só descobre quando o chefe de produção liga a reclamar — e que nunca aparece nos relatórios de incidentes porque "o sistema resolveu-se sozinho" ao fim de meia hora.

Wi-Fi industrial: o detalhe que os projectos ignoram

Wi-Fi de escritório e Wi-Fi industrial são produtos diferentes. Num armazém de 5 000 m² com racks metálicas, empilhadores em movimento e 30 terminais de picking, um access point doméstico ou de escritório é inadequado. Os requisitos mínimos para Wi-Fi industrial em ambiente de armazém ou chão-de-fábrica: access points certificados para ambientes industriais (IP54 ou superior em zonas húmidas ou com pó); roaming rápido entre APs com handoff abaixo dos 50 ms, crítico para terminais em movimento; dual-band com separação de tráfego; controlador centralizado para gestão de canal e potência; e survey de cobertura antes da instalação — não depois.

Uma fábrica de calçado em Felgueiras com 800–1 200 SKUs e três eixos de variação (cor, tamanho, modelo) a gerir stock em tempo real precisa de Wi-Fi sem zonas mortas. Uma zona morta num corredor de picking não é inconveniente — é uma paragem de processo.

Dimensionamento: a fórmula que funciona na prática

Calcular a largura de banda necessária

Não existe uma fórmula universal, mas existe um método estruturado. Identifique os utilizadores concorrentes reais no pico — não o total de colaboradores, mas quantos acedem ao ERP em simultâneo no momento de maior carga. Estime o consumo por tipo de operação: transações ERP (baixo volume, alta frequência) versus relatórios BI (alto volume, baixa frequência) versus uploads de ficheiros (alto volume, pontual). Adicione tráfego de fundo — backups, atualizações, monitorização, videoconferência. Aplique um fator de sobrecarga de 2x–3x sobre o calculado: a rede não deve operar habitualmente acima de 50% da capacidade máxima. Picos de 80% são aceitáveis; picos de 100% geram perdas de pacotes. Defina o requisito de latência: para ERP cloud com terminais de produção em tempo real, o objetivo é menos de 50 ms end-to-end e menos de 20 ms de jitter. Meça — não assuma.

Matriz de decisão por dimensão de fábrica

Segurança de rede: o que o NIS2 exige e o que as fábricas ignoram

A superfície de ataque aumentou com o ERP cloud

Quando o ERP estava on-premise, o vetor de ataque principal era a rede interna. Com o ERP cloud, adicionam-se: a ligação WAN, as credenciais de acesso ao portal cloud, as APIs de integração com parceiros e os terminais móveis. Cada um destes vectores é uma porta. E as PME industriais são o alvo desproporcionado: segundo o Verizon Data Breach Investigations Report 2025, o ransomware esteve presente em 88% das violações de dados em pequenas e médias empresas, contra 39% nas grandes organizações.

A razão é simples: as PME têm a mesma exposição digital das grandes empresas — ERP cloud, acesso remoto, integrações com clientes e fornecedores — mas uma fracção dos recursos de segurança. A fábrica de confeção no Vale do Ave não é menos apetecível do que um banco. É mais fácil de comprometer.

Controlos mínimos de rede para ERP cloud em ambiente industrial

Firewall de nova geração (NGFW) com inspeção de tráfego aplicacional — não apenas filtragem por porta/IP. VPN com autenticação multifactor (MFA) para todos os acessos remotos ao ERP, incluindo o IT que acede de casa ao fim de semana. Segmentação OT/IT com firewall entre os dois domínios — não apenas uma VLAN sem ACLs. DNS filtering para bloquear domínios maliciosos antes de estabelecer ligação. Monitorização de tráfego com alertas de anomalia: um terminal de produção que começa a fazer pedidos DNS para domínios externos é um sinal de comprometimento, não um problema de rede.

Para a abordagem de zero trust em redes industriais, o artigo Cibersegurança industrial: zero trust em redes OT de fábricas portuguesas detalha a implementação prática. Para a gestão de vulnerabilidades em ambiente OT, veja NIS2 em profundidade: gestão de patches e vulnerabilidades em ambiente OT.

O risco específico do acesso remoto ao ERP

O acesso remoto ao ERP — o diretor financeiro a fechar o mês de casa, o IT a fazer suporte ao sábado — é o vector de comprometimento mais frequente em PME industriais. A combinação de credenciais fracas, ausência de MFA e acesso direto ao ERP via RDP ou VPN sem segmentação cria uma exposição que qualquer atacante com acesso à dark web pode explorar por menos de 50 euros.

Configure acesso remoto com VPN com MFA obrigatório, sessões com timeout automático, registo de auditoria de todos os acessos, e princípio de menor privilégio. O utilizador que acede remotamente não precisa de acesso a todos os módulos do ERP — e se as suas credenciais forem comprometidas, o atacante também não deve ter.

O que funciona na prática: três padrões observados

Padrão 1 — Separar redes antes de migrar

Uma fábrica têxtil do cluster de Guimarães, com cerca de 120 colaboradores e produção de malhas para marcas europeias, investiu 8–10 semanas na segmentação da rede interna antes de tocar no ERP. Separou a rede de produção — terminais de apontamento, máquinas com PLC — da rede corporativa. Instalou uma firewall entre os dois segmentos. Só depois migrou. O tráfego de produção nunca competiu com o tráfego financeiro. O tempo de resposta dos terminais manteve-se estável mesmo durante o fecho mensal com SAF-T.

O erro que esta sequência evita é o mais comum: migrar o ERP primeiro, descobrir os problemas de rede em produção, e tentar resolver a segmentação com a fábrica a funcionar — o que obriga a janelas de manutenção negociadas com o chefe de produção, que não quer saber de IT às 6h da manhã.

Padrão 2 — Wi-Fi mal planeado num armazém de distribuição

Um operador de distribuição alimentar com armazém de 15 000 m² no corredor Lousada–Paços de Ferreira instalou Wi-Fi com base num orçamento de número de APs, sem survey de cobertura. O resultado foi previsível: zonas mortas nos corredores de picking mais afastados, terminais a perder ligação durante o roaming entre APs, e o chefe de armazém a reclamar que "o sistema está sempre a cair". O sistema não estava a cair. A rede estava.

A boa prática é survey de cobertura com ferramenta de heat mapping antes da instalação, dimensionamento por densidade de utilizadores (não por área), e teste de roaming com terminais em movimento antes do go-live. Um terminal de picking que perde ligação a meio de uma operação não gera apenas frustração — gera erros de stock que custam mais do que o survey que não foi feito.

Padrão 3 — SD-WAN com failover automático numa fábrica de calçado

Uma fábrica de calçado em Felgueiras, com produção para compradores internacionais que visitam duas vezes por ano, implementou SD-WAN com fibra dedicada como primária e 5G como secundária. A política de failover é automática — se a fibra cair, o tráfego ERP migra para 5G em menos de 30 segundos, sem intervenção humana.

A ligação de backup não é um custo de segurança. É um seguro de produção. Calcule o custo de uma paragem de 4 horas no pior momento possível — depois compare com o custo mensal de um cartão SIM empresarial com dados ilimitados.

O ROI desta redundância calcula-se facilmente: uma paragem de 2 horas durante o fecho de uma encomenda de exportação tem um custo operacional e reputacional que supera o custo anual da ligação secundária. O comprador internacional não espera pela fibra.

Como medir o sucesso pós-implementação

Métricas de rede que o IT deve monitorizar continuamente

Latência end-to-end ao servidor ERP cloud: objetivo abaixo de 50 ms no P95 — não na média, no 95.º percentil, porque é o pico que destrói a experiência. Jitter abaixo de 20 ms: jitter elevado é mais destrutivo do que latência alta para transações frequentes. Packet loss: objetivo zero em condições normais; qualquer perda acima de 0,1% em tráfego ERP é um sinal de problema, não de variação normal. Utilização da largura de banda: alerta quando ultrapassa 70% durante mais de 5 minutos consecutivos. Disponibilidade da ligação primária: objetivo 99,9% mensal, equivalente a menos de 44 minutos de indisponibilidade por mês. Tempo de failover: teste mensal — quanto tempo demora a ligação secundária a assumir o tráfego e se o ERP recupera as sessões ou exige novo login.

O teste que ninguém faz mas devia fazer

Simule uma falha da ligação primária durante um período de baixa carga — uma tarde de quinta-feira, não uma segunda-feira de manhã. Verifique se o failover funciona, quanto tempo demora, se os utilizadores percebem, e se o ERP recupera as sessões ou exige novo login. Documente o resultado. Repita trimestralmente. Para um plano estruturado de testes de resiliência, o artigo Disaster recovery em fábrica: o que testar antes de precisar mesmo detalha a metodologia.

Cinco passos para começar esta semana

1. Audite a ligação atual: meça latência, jitter e packet loss para o servidor ERP cloud durante o pico de carga — fecho de turno ou fecho de mês. Use ping contínuo, traceroute e iPerf. Compare com os objetivos acima. Se não tem estes dados, não tem diagnóstico.
2. Mapeie o tráfego por tipo: identifique todos os sistemas que partilham a ligação WAN — ERP, backups, videoconferência, câmeras IP, atualizações automáticas. Quantifique o consumo de cada um. O backup que ninguém sabia que estava configurado para correr de manhã é o suspeito mais frequente.
3. Configure QoS no router de saída: priorize o tráfego ERP e de produção. Limite o tráfego de backup a 20% da largura de banda durante o horário de produção. Esta configuração, por si só, resolve uma fracção significativa dos problemas de desempenho sem qualquer investimento em hardware.
4. Segmente a rede interna: separe pelo menos a rede de produção/OT da rede corporativa. Se não tem firewall entre os dois segmentos, este é o investimento mais urgente — antes de qualquer upgrade de largura de banda e antes de qualquer discussão sobre NIS2.
5. Instale monitorização contínua: um sistema de alertas que notifique o IT quando a latência ultrapassa 80 ms ou a utilização da largura de banda ultrapassa 70% durante mais de 5 minutos. Não descubra os problemas pelos utilizadores — descubra-os antes. O chefe de armazém não deve ser o sistema de monitorização da rede.

A infraestrutura de rede para ERP cloud não é um projecto de IT. É uma condição de operação. Uma fábrica que migra o ERP para cloud sem rever a rede está a trocar um risco conhecido — servidor on-premise que falha dentro de casa — por um risco desconhecido: dependência de WAN não dimensionada que falha no pior momento e que ninguém sabe diagnosticar. O segundo é mais difícil de explicar ao CEO, mais difícil de resolver em produção, e mais caro quando o auditor da NIS2 bate à porta.

Fontes

• CNCS — Centro Nacional de Cibersegurança, Relatório Cibersegurança em Portugal — Riscos e Conflitos 2024, CERT.PT, 2024. Disponível em: cncs.gov.pt
• Verizon, Data Breach Investigations Report 2025, Verizon Communications, 2025. Disponível em: verizon.com/business/resources/reports/dbir
• Diretiva (UE) 2022/2555 do Parlamento Europeu e do Conselho (NIS2), Jornal Oficial da União Europeia, 27 de dezembro de 2022.
• Decreto-Lei n.º 65/2025, Diário da República, transposição da Diretiva NIS2 para o ordenamento jurídico português.
• IBM Security, Cost of a Data Breach Report 2024, IBM Corporation, 2024. Disponível em: ibm.com/reports/data-breach
• ENISA — European Union Agency for Cybersecurity, Good Practices for Security of IoT and Smart Infrastructures, ENISA, 2023. Disponível em: enisa.europa.eu

Perguntas frequentes

Qual é a diferença entre um ERP on-premise e um ERP cloud em termos de rede?

Num ERP on-premise, o tráfego crítico circula na LAN local com latência de 1–2 ms. Num ERP cloud, esse tráfego atravessa a WAN, o ISP e o backbone do fornecedor, com latência realista de 15–40 ms em condições normais. Sob carga, pode triplicar. Para operações transacionais em tempo real com múltiplos terminais, esta diferença torna-se crítica.

O que é o "pico que ninguém calcula" no dimensionamento de rede?

É o erro de calcular a largura de banda para o utilizador médio, não para o pico simultâneo. Numa fábrica, o fecho de turno gera 60–70 transações simultâneas em menos de 5 minutos. O pior cenário ocorre quando o fecho de turno coincide com o SAF-T mensal e um backup pendente — três processos disputam a mesma ligação sem priorização. É neste cruzamento que a rede cede.

Qual é a melhor opção de ligação WAN para uma fábrica com ERP cloud?

Para a maioria das fábricas portuguesas com 50–200 colaboradores, a combinação prática é fibra dedicada como ligação primária e 4G/5G como failover, gerida por um dispositivo SD-WAN. A fibra partilhada como ligação única é um risco operacional. A fibra dedicada oferece largura de banda garantida, latência controlada e SLA de 99,9%+.

O que é SD-WAN e como funciona com ERP cloud?

SD-WAN agrega e gere múltiplas ligações com inteligência de roteamento, não aumenta a largura de banda disponível. Se as ligações subjacentes forem de má qualidade, o SD-WAN distribui tráfego entre duas ligações más. É um multiplicador: se a base for fraca, multiplica fraqueza. Configure primeiro as ligações físicas; depois ponha inteligência em cima.

Por que é que a fibra partilhada (FTTH) é inadequada para ERP crítico?

A fibra partilhada oferece 100 Mbps–1 Gbps sem SLA garantido (best-effort). Não fornece latência controlada nem priorização de tráfego. Numa fábrica onde o ERP é crítico para a produção, o colapso da rede durante um pico simultâneo paralisa as operações. A fibra dedicada com SLA é a escolha segura.

Quais são os tipos de tráfego que competem pela rede numa fábrica com ERP cloud?

Os apontamentos de MES geram muitas transações pequenas sensíveis a latência. A gestão de armazém produz tráfego em rajada. A financeira cria operações pesadas mas pontuais (SAF-T, fecho de mês). Videoconferência e acesso remoto contendem com o tráfego ERP. Backups e replicação consomem largura de banda em momentos críticos. Sem QoS configurado, a priorização é impossível.

Qual é o impacto do jitter (variação de latência) num ERP cloud?

Para consultas (um comercial a ver stock), 40 ms de latência é imperceptível. Para operações transacionais em tempo real (um terminal a registar apontamentos a cada 30 segundos com 60 terminais simultâneos), 40 ms acumula e torna-se visível. Com jitter, torna-se insuportável e causa congelamento dos terminais.