Infraestrutura de TI industrial: guia para diretores de operações

Numa confecção perto de Famalicão, às 23h40 do último dia útil do mês, o servidor que corre o ERP está a 100% de CPU há quarenta minutos. A responsável administrativa quer fechar a faturação para comunicar o SAF-T. O terminal de picking no armazém deixou de responder. E o único que sabe reiniciar a máquina — o "informático" que também trata das impressoras e do Wi-Fi da cantina — está de férias no Algarve, com o telemóvel em silêncio. Esta cena repete-se em centenas de fábricas do Norte todos os meses.

A tese deste guia é simples e incómoda: a maioria das PME industriais portuguesas não tem um problema de software — tem um problema de infraestrutura que o software vai amplificar. Compra-se um ERP novo, moderno, para correr numa fundação de 2011: um servidor sem redundância, um backup que ninguém testou, uma rede que cai quando entra a segunda linha de produção. O ERP não falha. A base debaixo dele é que nunca foi desenhada para aguentar.

Vamos percorrer o assunto sem eufemismos de brochura. O que é infraestrutura, onde ela cede primeiro, quanto custa o silêncio, que modelos existem e como decidir por dimensão de empresa. E, sobretudo, o que fazer nos próximos noventa dias sem parar a produção nem gastar o orçamento todo de uma vez.

1. O problema operacional real

Infraestrutura de TI industrial não é um tema abstrato de departamento de sistemas. É a diferença entre expedir uma encomenda da Inditex à hora marcada ou pagar penalização por atraso. É o dye house do Vale do Ave que precisa de rastrear o lote de tingimento para responder a uma auditoria de sustentabilidade da marca cliente — e descobre que os dados estão espalhados por três folhas de Excel e a memória do encarregado.

Quem passa tempo dentro destas fábricas percebe uma coisa depressa: o problema quase nunca se apresenta como "a infraestrutura está má". Apresenta-se como sintomas dispersos que ninguém liga entre si. O ERP está lento. Os terminais falham. O backup demora. O comercial não vê o stock em tempo real. Cada sintoma é tratado isoladamente, muitas vezes com um penso rápido, até que um dia todos chegam ao mesmo tempo — e é sempre no pior momento possível.

Onde dói primeiro: o fecho de mês

O fecho contabilístico e a comunicação do SAF-T mensal são o teste de esforço involuntário de qualquer infraestrutura. Quando o ERP arrasta porque o armazenamento é um disco mecânico partilhado com o servidor de ficheiros, quando o backup nocturno corre ao mesmo tempo que a faturação, quando a rede satura porque a linha de produção e a administração partilham o mesmo segmento — é aí que a fragilidade se manifesta. Não em dia normal. No pior dia possível.

O que agrava o fecho de mês na indústria é que ele não é só contabilístico. Numa confecção subcontratada, o fecho cruza-se com o apuramento da produção do mês — quantas peças saíram de cada operação, quanto tempo demorou cada fase, que subcontratados foram faturados. Se a captura de produção corre na mesma máquina que a contabilidade e ambas disputam o mesmo disco à mesma hora, o resultado é previsível. O sistema não cai porque está mal escrito. Cai porque foi posto a fazer duas coisas pesadas ao mesmo tempo numa fundação dimensionada para uma.

Há um detalhe que muitos gestores desconhecem: a lentidão do fecho raramente é problema de CPU. É problema de I/O — de leitura e escrita em disco. Um servidor com processador moderno e um disco mecânico de 2015 vai arrastar exatamente da mesma forma. Trocar o armazenamento de disco mecânico para SSD ou NVMe é, muitas vezes, a intervenção de maior impacto por euro investido. Não é glamorosa. Mas transforma um fecho de duas horas num fecho de vinte minutos.

O calendário do calçado não perdoa

Em Felgueiras, uma coleção de amostras tem entre 800 e 1200 SKUs, cruzados em três eixos — cor, tamanho e forma. Os compradores internacionais visitam duas vezes por ano (homem em agosto, mulher em fevereiro). Se o sistema de gestão de amostras e a base de dados de artigos estiverem a correr numa infraestrutura que não escala, o pico de trabalho que antecede essas visitas transforma-se numa maratona de horas extra e erros de picking. A APICCAPS documenta há anos a complexidade do produto português — é essa complexidade que a infraestrutura tem de suportar sem estalar.

A matemática dos SKUs é implacável. Uma amostra base em quinze cores, oito tamanhos e três larguras gera 360 combinações a partir de uma única referência. Multiplique por algumas centenas de modelos e tem uma base de dados de artigos com dezenas de milhares de linhas ativas só para uma coleção. Um ERP generalista modela isto como se fossem produtos independentes — e afoga-se. Um ERP vertical de calçado gere a matriz cor-tamanho-forma como estrutura nativa, mas continua a precisar de uma base de dados que responda em milissegundos quando o comercial abre a ficha do artigo com o comprador alemão sentado à frente dele.

A época conta ainda mais nesta indústria. Nas semanas anteriores a agosto e fevereiro, o trabalho concentra-se de tal forma que a infraestrutura passa por dois ou três meses de utilização normal comprimidos em quinze dias. Quem dimensiona a máquina para o consumo médio anual descobre, precisamente nessas semanas, que a média mente. A infraestrutura desenha-se para o pico, não para a média — e no calçado o pico é conhecido com um ano de antecedência. Não há desculpa para ser apanhado de surpresa.

O têxtil e a rastreabilidade que a marca exige

No têxtil do Vale do Ave — Famalicão, Guimarães, Barcelos, Vizela — a pressão mudou de natureza. Já não é só preço e prazo. As marcas cliente, alinhadas com a Estratégia da UE para os Têxteis Sustentáveis e Circulares, começam a exigir rastreabilidade de lote: de que fio veio esta malha, em que banho foi tingida, com que corantes, com que consumo de água e energia. Isto não é um requisito de marketing. É um requisito de dados que a infraestrutura tem de sustentar.

Uma fábrica de acabamentos que não consegue associar cada rolo expedido ao lote de tingimento e às respetivas condições de processo está a competir com uma mão atada atrás das costas. A rastreabilidade exige captura de dados no momento em que o processo acontece — no acabamento, na estamparia, na confeção — e um sistema que os guarde de forma íntegra e recuperável durante anos. Quando a auditoria chega, a resposta tem de estar num ecrã, não na cabeça do encarregado que entretanto se reformou.

O chefe de armazém e o rádio

Há uma verdade operacional que os fornecedores de software raramente admitem: o chefe de armazém de um centro de distribuição no corredor Lousada/Paços de Ferreira vai lutar contra qualquer rollout que o tire do rádio mais de duas horas. E tem razão. Um upgrade de infraestrutura mal planeado — que obriga a parar o WMS durante o horário de expedição — custa mais em encomendas atrasadas do que todo o projeto de modernização poupa num ano.

Este é o ponto onde muitos projetos de infraestrutura descarrilam: são desenhados por quem olha para o diagrama de rede e ignora o diagrama de operações. A janela de manutenção não é uma variável técnica — é uma variável de negócio. Numa distribuição alimentar com expedição das 6h às 14h, a janela real de intervenção pode ser das 15h às 5h, e mesmo assim há reposições noturnas. Quem planeia uma migração sem cartografar o calendário de expedição está a planear um conflito. A boa notícia é que a virtualização e a replicação permitem hoje migrar sistemas com paragens de minutos, não de horas — desde que o projeto seja desenhado com essa restrição desde o início.

A infraestrutura não falha quando está tudo calmo. Falha no fecho de mês, na véspera da visita dos compradores, no pico de expedição de sexta-feira. Desenhe-a para o pior dia, não para o dia médio.

2. O que é exatamente infraestrutura de TI para empresas industriais em Portugal

Infraestrutura de TI é o conjunto de recursos físicos e lógicos que sustentam as aplicações do negócio: servidores, armazenamento, rede, virtualização, sistemas operativos, backup, cibersegurança e os serviços de suporte que mantêm tudo isto de pé. Num contexto industrial, acresce uma camada que o escritório não tem: os terminais de chão-de-fábrica, os leitores de código de barras, as balanças ligadas ao ERP, os sensores de máquina, os PDA de picking.

A distinção entre infraestrutura de escritório e infraestrutura industrial é mais funda do que parece. Um escritório tolera que o sistema esteja lento cinco minutos — as pessoas esperam, tomam um café, voltam. Uma linha de produção com captura de tempos não tolera. Se o terminal não regista a operação no momento em que ela acontece, ou o operador para e espera (perde-se produção), ou continua e o registo perde-se (perde-se rastreabilidade). A infraestrutura industrial vive sob a tirania do tempo real de uma forma que o back-office não conhece.

As sete camadas que interessam

Uma fábrica não precisa de conhecer todas as camadas de um datacenter empresarial. Precisa de dominar sete decisões:

• Computação — onde correm o ERP e as aplicações: servidor físico, cluster virtualizado, cloud privada ou pública.
• Armazenamento — a diferença entre um disco mecânico e SSD/NVMe é a diferença entre um fecho de mês de duas horas ou de vinte minutos.
• Rede — a espinha dorsal que liga escritório, produção e armazém; o ponto único de falha mais subestimado.
• Continuidade — backup, replicação e o plano de recuperação que quase ninguém testa até precisar.
• Segurança — perímetro, segmentação, gestão de identidades e proteção contra ransomware.
• Chão-de-fábrica — a camada operacional (terminais, IoT industrial, captura de produção) que distingue infraestrutura industrial de infraestrutura de escritório.
• Suporte e governo — quem mantém isto, com que SLA, com que documentação.

Cada camada tem o seu ponto de rutura típico. Na computação, é a falta de redundância — um servidor único que, ao morrer, leva tudo consigo. No armazenamento, é o disco lento e o espaço que se esgota sem aviso. Na rede, é o switch de 100 euros comprado há dez anos que agrega tráfego crítico. Na continuidade, é o backup que corre mas nunca foi restaurado. Na segurança, é o acesso remoto sem autenticação multifator. No chão-de-fábrica, é o Wi-Fi que não cobre o fundo do armazém. No suporte, é a dependência de uma única pessoa. Conhecer estes pontos é meio caminho para os corrigir.

Uma breve história do servidor na cave

Durante duas décadas, a PME industrial portuguesa correu tudo num servidor físico na cave ou numa sala mal ventilada ao lado da contabilidade. Funcionava — até deixar de funcionar. A virtualização (VMware, Hyper-V, Proxmox) veio permitir consolidar várias máquinas num só hardware e recuperar mais depressa de avarias. A cloud veio a seguir, mas não substituiu tudo: a fábrica tem latências, integrações locais e ligações a equipamento físico que nem sempre casam bem com um datacenter a 1500 km. O modelo que ganhou na indústria portuguesa é o híbrido — e explicamos porquê na secção 4.

Vale a pena perceber o que a virtualização mudou de verdade, porque muitas fábricas ainda correm sistemas como se estivéssemos em 2008. Antes, cada aplicação exigia o seu servidor físico: um para o ERP, um para o correio, um para os ficheiros, um para a base de dados. Quatro máquinas, quatro pontos de avaria, quatro fontes de alimentação a consumir energia. Com a virtualização, essas quatro máquinas passam a ser quatro máquinas virtuais dentro de um ou dois hospedeiros físicos redundantes. Se um hospedeiro avaria, as máquinas virtuais arrancam no outro em minutos. É a diferença entre um dia parado à espera de peças e uma interrupção de que ninguém dá conta.

A cloud acrescentou uma segunda revolução: a capacidade de não possuir o hardware de todo. Mas a indústria aprendeu, à sua custa, que nem tudo deve subir para a cloud. Um sistema de captura de produção que fala com terminais no chão-de-fábrica não ganha nada em correr num datacenter distante — pelo contrário, ganha latência e dependência da fibra. O que ganha em cloud é o backup, a recuperação de desastre, e as aplicações de escritório que toda a gente acede de qualquer lado. Daí o híbrido: cada carga de trabalho no sítio que faz sentido para ela.

Termos que vai encontrar em qualquer proposta

RTO (Recovery Time Objective) e RPO (Recovery Point Objective) — quanto tempo pode a operação estar parada e quantos dados pode perder. SLA — o compromisso de disponibilidade e resposta do fornecedor. Alta disponibilidade — arquitetura sem ponto único de falha. Estes três conceitos decidem mais projetos do que qualquer marca de hardware. Se um fornecedor não fala em RTO/RPO logo na primeira reunião, está a vender-lhe caixas, não continuidade.

Convém traduzir estes acrónimos para linguagem de fábrica, porque é aí que ganham peso. RTO é a resposta à pergunta: "se o servidor morre às 9h de segunda, a que horas voltamos a faturar e a expedir?". RPO é a resposta a: "quando recuperarmos, de que momento são os dados — de ontem à noite, de há uma hora, de há cinco minutos?". Uma fábrica que faz backup uma vez por dia tem, na melhor das hipóteses, um RPO de 24 horas: em caso de desastre, perde um dia inteiro de registos de produção, encomendas e faturas. Para muitas operações, isso é inaceitável — e a solução (replicação mais frequente) existe e não é cara.

3. O panorama em Portugal hoje

Portugal tem um tecido industrial denso no Norte e Centro — têxtil e vestuário no Vale do Ave, calçado em Felgueiras e S. João da Madeira, moldes na Marinha Grande, cerâmica em Aveiro. É um tecido de PME familiares, muitas com margens apertadas e uma dependência crítica de sistemas que raramente foram desenhados para a escala atual.

Este perfil tem uma consequência direta na forma como se decide sobre infraestrutura. As decisões concentram-se num trio: CEO, CFO e o responsável de TI. O CEO pensa em crescimento e continuidade do negócio. O CFO pensa em CAPEX contra OPEX e em previsibilidade de custo. E o responsável de TI — muitas vezes um autodidata com quinze anos de conhecimento profundo do negócio e nenhuma formação formal — pensa em não ser acordado às 3h da manhã. Qualquer proposta de infraestrutura que não fale a estas três linguagens ao mesmo tempo morre na sala de reuniões.

A ameaça já não é hipotética

Em 2024, o CERT.PT registou 2.758 incidentes de cibersegurança em Portugal, um aumento de 36% face a 2023, e cerca de 78% ocorreram em entidades privadas (Fonte: CNCS, 2024). Não é um problema de "grandes empresas de Lisboa". O relatório DBIR da Verizon de 2025 é ainda mais claro sobre quem apanha: nas pequenas e médias empresas, o ransomware esteve presente em 88% das violações analisadas, contra 39% nas grandes organizações. A PME industrial é o alvo desproporcionado — precisamente porque tem dados valiosos e defesas fracas.

A razão pela qual as PME são alvo preferencial não é mistério nenhum. Os atacantes não escolhem a dedo — automatizam. Varrem a internet à procura de sistemas expostos, portas de acesso remoto abertas, servidores por atualizar. Uma PME industrial com um servidor de acesso remoto sem autenticação multifator é exatamente o tipo de porta que os varrimentos automáticos encontram todos os dias. E, ao contrário de uma grande empresa com equipa de segurança dedicada, a PME muitas vezes só descobre a intrusão quando os ficheiros já estão cifrados e aparece o pedido de resgate no ecrã.

O custo de não fazer nada

O relatório da IBM de 2024 fixou o custo médio global de uma violação de dados num recorde de 4,88 milhões de dólares, mais 10% do que em 2023. Para uma PME portuguesa esse número parece de outro planeta — mas a matemática relevante não é o custo médio global. É o custo de estar cinco dias sem faturar, sem expedir, sem responder aos clientes que já ameaçam mudar de fornecedor. Uma confecção subcontratada para uma casa mãe internacional que não expede a tempo não perde uma encomenda: perde a relação.

Faça a conta à sua própria escala. Uma fábrica que fatura, digamos, um determinado valor por dia útil, e que fica cinco dias parada, perde cinco vezes esse valor em receita — mas isso é o menos. Perde os prazos contratuais com marcas que têm cláusulas de penalização. Perde a confiança de um comprador que agora tem de explicar à sua própria cadeia por que razão a encomenda portuguesa não chegou. E ganha uma reputação de fornecedor de risco que demora anos a apagar. O ransomware que cifra o servidor não destrói só dados. Destrói a posição competitiva que a fábrica construiu ao longo de décadas.

A pergunta não é "vamos ser atacados?". É "quando formos, quanto tempo ficamos parados e quanto disso conseguimos recuperar?". Se não sabe a resposta em horas e em número de dias de dados, não tem infraestrutura — tem sorte.

A escassez de quem sabe fazer isto

Há um problema estrutural por trás de tudo: o défice global de profissionais de cibersegurança chegou a cerca de 4,76 milhões de pessoas em 2024, mais 19% do que em 2023 (Fonte: ISC2, 2024). Traduzido para o terreno português: a PME industrial não consegue contratar nem reter um engenheiro de sistemas sénior a competir com salários de Lisboa ou do estrangeiro. Por isso o "informático" da fábrica acumula funções que deviam ser de três pessoas — e por isso o modelo de infraestrutura gerida por parceiro faz cada vez mais sentido para quem tem menos de 100 colaboradores.

O problema agrava-se pela geografia. Um engenheiro de sistemas com dez anos de experiência tem hoje, à distância de um clique, ofertas remotas de empresas estrangeiras a pagar em euros de outra ordem de grandeza. A fábrica de Felgueiras ou de Barcelos compete não com o vizinho, mas com o mercado europeu inteiro. Reter esse talento internamente é caro e frágil — se a pessoa sai, sai com ela o conhecimento todo. Externalizar a competência para um parceiro que a distribui por vários clientes é, para muitas PME, a única forma economicamente viável de ter acesso a competência sénior sem a pagar a tempo inteiro.

O financiamento existe — mas tem ritmo próprio

Portugal tem instrumentos de financiamento que cobrem parte destes investimentos: PRR, PT2030, COMPETE 2030 e Norte 2030 têm linhas para digitalização e transição digital das PME. Na prática, o que se aprova com mais facilidade são projetos com objetivos claros e mensuráveis — modernização de sistemas produtivos, cibersegurança, digitalização de processos. O que fica preso são candidaturas vagas, mal fundamentadas nos relatórios técnicos, ou que não demonstram o impacto operacional do investimento.

A lição de quem já passou por vários ciclos de candidaturas é simples: o financiamento não deve conduzir a decisão técnica. A decisão técnica deve conduzir a candidatura. Desenhar uma arquitetura só porque há um aviso aberto é a forma mais rápida de acabar com hardware subutilizado que a fábrica não precisava. Primeiro decida o que a operação exige. Depois procure o instrumento que financia essa decisão. Nunca ao contrário.

4. Os modelos de implementação

Há quatro modelos que uma PME industrial portuguesa realmente considera. Não são religiões. São trade-offs de custo, controlo, risco e competências disponíveis.

On-premise tradicional

Tudo corre em servidores da própria empresa, nas suas instalações. Máximo controlo, latência mínima para os equipamentos de produção, e a fatura mensal é previsível. Em troca: o capital investido em hardware fica preso, a redundância custa caro (é preciso comprar tudo a dobrar) e a responsabilidade de manter, atualizar e proteger é interna. Faz sentido para fábricas com forte dependência de integrações locais e uma equipa técnica capaz.

O on-premise carrega um custo escondido que raramente entra na conta inicial: o ciclo de vida do hardware. Um servidor tem uma vida útil de cinco a sete anos. Ao fim desse tempo, o suporte do fabricante termina, as peças ficam caras e escassas, e o risco de avaria dispara. Muitas fábricas correm hoje sistemas críticos em hardware que já passou dessa fronteira — não porque decidiram, mas porque "está a funcionar" e ninguém quis mexer. Funciona até ao dia em que não funciona, e nesse dia descobre-se que não há peça de substituição e que a máquina nova demora semanas a chegar e a configurar.

Cloud pública

Servidores alugados a um hiperescalador (Azure, AWS, Google). Escala instantânea, sem investimento inicial em hardware, redundância incluída no serviço. As contrapartidas: a fatura cresce com o consumo e pode surpreender, a latência para equipamento de chão-de-fábrica pode ser um problema, e a dependência da ligação à internet torna-se crítica. Uma quebra de fibra na zona industrial deixa a fábrica sem ERP.

A surpresa na fatura é um risco real e subestimado. A cloud pública cobra por consumo — computação, armazenamento, tráfego de saída de dados. Uma migração mal dimensionada, ou uma aplicação que gera muito tráfego, pode transformar uma fatura estimada em algo bem mais pesado. E a dependência da internet é o calcanhar de Aquiles em contexto industrial: muitas zonas industriais do Norte não têm redundância de fibra, e uma escavadora que corta o cabo na estrada deixa a fábrica inteira sem acesso aos seus próprios sistemas. Quem escolhe cloud pública para cargas críticas precisa de uma segunda ligação de internet, de operador diferente, e isso raramente entra no cálculo inicial.

Cloud privada / datacenter gerido

A infraestrutura corre num datacenter de um parceiro, dedicada à empresa, com SLA contratado. Combina a previsibilidade do on-premise com a resiliência de um datacenter profissional (energia redundante, refrigeração, segurança física, ligações múltiplas). É o modelo que resolve o problema da equipa interna pequena — a competência está do lado do fornecedor.

O que um datacenter profissional oferece e uma sala técnica de fábrica quase nunca tem: energia com gerador e UPS que aguentam uma falha da rede elétrica sem uma interrupção, refrigeração dimensionada para funcionar 24 horas por dia sem sobreaquecer, deteção e supressão de incêndio, controlo de acesso físico, e múltiplas ligações de internet de operadores diferentes. Replicar isto numa fábrica custaria uma fortuna e exigiria manutenção contínua. Alugar o espaço e o SLA num datacenter — como o que a INFOS opera — distribui esse custo por muitos clientes e torna-o acessível a uma PME.

Híbrido

O que a maioria das fábricas portuguesas acaba por adotar: sistemas críticos de baixa latência ficam perto da produção, o backup e a recuperação de desastre vão para a cloud ou datacenter, e as aplicações de escritório movem-se conforme faz sentido. É pragmático e é defensável.

O híbrido bem desenhado resolve o dilema central da infraestrutura industrial: os sistemas que falam com o chão-de-fábrica precisam de estar perto, e os sistemas que garantem a continuidade precisam de estar longe. A captura de produção do KORA Productivity corre localmente, junto aos terminais, com latência mínima. A cópia de segurança desses dados replica-se para um datacenter distante, protegida de um incêndio ou inundação nas instalações. As aplicações de escritório e o portal B2B que os clientes acedem podem viver na cloud, sempre disponíveis. Cada peça no seu sítio ótimo.

Não existe o modelo certo em abstrato. Existe o modelo certo para a sua latência de produção, a sua equipa interna e a sua tolerância a estar parado. Quem lhe vende "cloud sempre" ou "on-premise sempre" está a vender a sua própria conveniência.

5. Como avaliar se a sua empresa precisa de intervir

A intervenção na infraestrutura raramente começa por convicção. Começa por um susto — um servidor que morreu, um ataque que passou, um fecho de mês que não fechou. O objetivo é decidir antes do susto. Este diagnóstico dá-lhe a base.

Sinais de que a fundação está a ceder

• O ERP fica lento previsivelmente nos mesmos momentos (fecho, picos de expedição, entrada de encomendas em massa).
• O backup existe mas ninguém se lembra da última vez que foi restaurado com sucesso num teste.
• Uma só pessoa sabe reiniciar os sistemas e essa pessoa tira férias como toda a gente.
• A rede da produção e a do escritório são a mesma, sem segmentação.
• Os terminais de chão-de-fábrica correm num Wi-Fi que cai quando entra a segunda linha.
• Não sabe dizer, em horas, quanto tempo demoraria a repor a operação após uma avaria total.
• O hardware dos servidores críticos já passou dos cinco anos e não tem contrato de suporte ativo.
• Há aplicações a correr em sistemas operativos fora de suporte do fabricante.

Se marcou três ou mais destes pontos, não tem uma questão de "se" — tem uma questão de "quando". Cada um destes sinais é, por si só, um risco gerível. Juntos, compõem uma infraestrutura que está a pedir para falhar no pior momento. A boa notícia é que quase todos têm correção relativamente rápida e barata — o difícil é decidir olhar antes de o problema decidir por si.

Passo a passo do diagnóstico de infraestrutura

1. Inventarie o que tem. Liste todos os servidores, a idade do hardware, os sistemas operativos e as versões. Um Windows Server fora de suporte é uma porta aberta e um risco de conformidade. Este levantamento demora dois dias e revela quase sempre uma surpresa desagradável.
2. Meça o RTO e o RPO reais. Faça a pergunta a sério: se o servidor principal morrer agora, quantas horas até estarmos a faturar de novo, e quantas horas de dados perdemos? Se ninguém sabe, tem o seu primeiro problema identificado.
3. Teste o backup a sério. Não confie no relatório verde do software. Restaure um ficheiro, uma base de dados, uma máquina virtual num ambiente isolado. Um backup que nunca foi restaurado é uma hipótese, não uma garantia.
4. Mapeie os pontos únicos de falha. Percorra a cadeia: se cair este switch, este servidor, esta ligação — o que para? Marque cada ponto onde uma única avaria interrompe a operação. Esses são os seus alvos prioritários.
5. Avalie a segmentação e o acesso. A produção fala com a contabilidade na mesma rede? Quantas pessoas têm acesso de administrador? Há autenticação multifator no acesso remoto? Cada resposta errada é uma correção rápida com impacto alto.
6. Cruze com o calendário do negócio. Sobreponha os riscos ao calendário real — fecho de mês, visitas de compradores, campanhas. Uma vulnerabilidade que coincide com o pico anual vale por dez que caem em época morta.

Este exercício não precisa de consultor externo para começar. Precisa de duas tardes e de honestidade. Quando quiser levar mais fundo, a engenharia de sistemas alinhada à estratégia é o passo seguinte lógico.

Traduzir o diagnóstico em prioridades

O diagnóstico produz uma lista de problemas. A parte difícil é ordená-los. A regra que funciona no terreno: priorize primeiro pelo cruzamento de probabilidade de falha com impacto na operação. Um backup que nunca foi testado tem probabilidade alta de falhar quando precisar e impacto máximo — vai para o topo. Um switch antigo num ponto secundário da rede pode esperar. Esta matriz simples evita o erro clássico de gastar o orçamento no problema mais visível em vez do mais perigoso.

6. O que escolher e porquê — decisão por dimensão de empresa

A dimensão da empresa e a complexidade da operação decidem quase tudo. Não é o setor — é o número de colaboradores, o número de sistemas críticos e a existência (ou não) de equipa técnica interna.

Até 50 colaboradores

Raramente têm equipa de sistemas dedicada. O "informático" acumula funções. Aqui, o modelo de datacenter gerido ou cloud privada com SLA resolve o problema estrutural: a competência que não se consegue contratar aluga-se ao parceiro. O erro mais comum nesta escala é comprar um servidor caro e deixá-lo sem contrato de suporte — quando avaria, descobre-se que ninguém tem responsabilidade contratual de o repor.

Nesta escala, a prioridade absoluta é a continuidade com responsabilidade contratada. Não interessa quantas funcionalidades tem o sistema se, quando ele parar, não houver ninguém obrigado a repô-lo num prazo definido. A pergunta a fazer a qualquer fornecedor é direta: "se isto morrer numa sexta-feira à tarde, quem responde e em quanto tempo?". Se a resposta for "vemos o que se pode fazer", procure outro fornecedor. Uma fábrica com menos de 50 pessoas não sobrevive a dias parada à espera de boa vontade.

50 a 150 colaboradores

Já têm um ou dois técnicos internos — normalmente heróis autodidatas com quinze anos de conhecimento do negócio e zero formação formal. Estas pessoas são o ativo mais subvalorizado da empresa e o seu maior ponto único de falha. O modelo híbrido faz sentido: o técnico interno gere o dia-a-dia e a operação; o parceiro externo garante a continuidade, a segurança e a arquitetura. A relação certa entre os dois é onde os projetos vivem ou morrem.

O erro nesta faixa é tratar o técnico interno e o parceiro externo como concorrentes. Não são. O técnico interno conhece o negócio de uma forma que nenhum parceiro externo conhecerá — sabe que a linha de tingimento não pode parar às quintas porque é quando entra o lote grande, sabe que o comercial X precisa do relatório às segundas. O parceiro externo traz a competência de arquitetura, segurança e continuidade que a fábrica não consegue contratar a tempo inteiro. Juntos, cobrem o que nenhum cobre sozinho. Separá-los ou pô-los a competir é desperdiçar os dois. É também nesta dimensão que faz sentido consolidar informação de gestão num BI como o Qlik Sense, para que a decisão deixe de depender de relatórios manuais.

Acima de 150 colaboradores

Complexidade que justifica arquitetura formal, ambientes separados de desenvolvimento/teste/produção, e possivelmente um ERP low-code de maior escala como o QAD Adaptive ERP quando os processos são muito específicos. A esta dimensão, a infraestrutura deixa de ser suporte e passa a ser vantagem competitiva — ou lastro.

Acima dos 150 colaboradores, a dívida técnica acumulada torna-se o inimigo principal. Anos de decisões pontuais — um servidor aqui, uma integração ali, um sistema legado que ninguém quis substituir — compõem uma teia difícil de gerir e ainda mais difícil de proteger. A esta escala, o valor de uma arquitetura formal, com ambientes separados de desenvolvimento, teste e produção, deixa de ser luxo e passa a ser condição de sanidade. Testar uma alteração diretamente em produção, como se faz nas fábricas pequenas, torna-se um risco inaceitável quando cinco mil utilizadores dependem do sistema.

Independentemente da dimensão, a decisão beneficia de uma arquitetura de soluções desenhada antes de comprar hardware. Comprar caixas antes de desenhar a arquitetura é a forma mais cara de errar.

O tamanho da empresa não decide se precisa de boa infraestrutura — decide quem a deve gerir. Uma fábrica de 40 pessoas precisa da mesma resiliência que uma de 400; só não pode pagar uma equipa interna para a garantir.

7. Quadro regulatório e conformidade aplicável

A infraestrutura em Portugal não vive num vazio legal. Há obrigações que decidem parte das escolhas técnicas — e ignorá-las custa multas e, pior, credibilidade junto de clientes que auditam fornecedores.

Faturação e comunicação à AT

O DL 28/2019 e a Portaria 195/2020 fixam as regras de faturação eletrónica, ATCUD e comunicação mensal do SAF-T. Na prática, isto exige software certificado pela Autoridade Tributária e uma infraestrutura que garanta a integridade e a disponibilidade dos dados fiscais. Um servidor que perde a base de dados no dia 30 não é só um problema de TI — é um incumprimento fiscal.

A dimensão de infraestrutura desta obrigação é frequentemente ignorada. A certificação do software é condição necessária, mas não suficiente. De que serve ter software certificado se a base de dados que guarda os documentos fiscais não tem backup íntegro e recuperável? A AT exige que os registos existam, estejam completos e possam ser comunicados. Uma perda de dados que impeça a comunicação atempada do SAF-T é um problema fiscal, com as consequências que isso acarreta. A conformidade fiscal, no fundo, é também uma exigência de continuidade da infraestrutura.

NIS2 — a mudança que muitos ainda ignoram

A Diretiva NIS2 (Diretiva (UE) 2022/2555), transposta em Portugal pelo Decreto-Lei n.º 65/2025, alarga as obrigações de cibersegurança a médias e grandes empresas de 18 setores críticos, incluindo a indústria. Para muitas PME industriais que nunca se consideraram "infraestrutura crítica", isto muda o jogo: passam a ter de gerir riscos de segurança, notificar incidentes e responsabilizar a gestão de topo. A conformidade com a NIS2 começa exatamente no diagnóstico de infraestrutura que descrevemos na secção 5.

Um ponto da NIS2 que apanha muitos gestores de surpresa: a responsabilidade recai sobre a gestão de topo, não sobre o departamento de TI. O CEO e a administração podem ser diretamente responsabilizados pela falta de medidas de gestão de risco de cibersegurança. Isto retira a segurança do canto do "informático" e coloca-a na sala do conselho. E há um segundo ponto igualmente importante: a NIS2 estende as obrigações à cadeia de fornecimento. Uma empresa abrangida tem de avaliar a segurança dos seus fornecedores — o que significa que, mesmo que a sua fábrica não esteja diretamente abrangida, pode passar a ter de demonstrar segurança para continuar a fornecer um cliente que está.

RGPD, ISO 27001 e a cadeia de fornecimento

O RGPD e a Lei 58/2019 impõem proteção de dados pessoais — e uma fábrica gere dados de trabalhadores, clientes e fornecedores. As marcas internacionais que subcontratam confecção e calçado auditam cada vez mais os fornecedores em segurança de informação. Ter (ou trabalhar com um parceiro que tenha) certificação ISO 27001 e conformidade RGPD deixou de ser um luxo e passou a ser condição de acesso a certos clientes.

A gestão de dados de trabalhadores merece atenção especial na indústria, onde os sistemas de assiduidade, escalas e processamento salarial concentram dados pessoais sensíveis de dezenas ou centenas de pessoas. Uma solução de gestão de pessoas como o pplPortal tem de tratar esses dados em conformidade com o RGPD desde a arquitetura — não como remendo posterior. E quando essas soluções incorporam IA preditiva para rotatividade ou absentismo, entra em cena mais uma camada regulatória que convém antecipar.

A conformidade regulatória parece um custo até o dia em que um cliente internacional pede o relatório de segurança do seu fornecedor de TI. Nesse dia, é a diferença entre manter o contrato ou perdê-lo.

eIDAS, assinatura qualificada e IA

O regulamento eIDAS suporta a assinatura digital qualificada, cada vez mais usada em contratos e documentos oficiais — e integrável em fluxos de gestão documental. E para quem começa a usar inteligência artificial na operação, o AI Act (Regulamento UE 2024/1689) introduz classificação de risco que convém documentar cedo. O que registar antes de o AI Act apertar está descrito no nosso guia sobre governance de IA em PME industrial.

Lei 93/2021 — o canal de denúncias que a infraestrutura tem de suportar

Empresas com 50 ou mais colaboradores estão obrigadas, pela Lei 93/2021, a ter um canal de denúncias interno que garanta a confidencialidade do denunciante. Isto tem uma dimensão de infraestrutura que passa despercebida: o canal tem de ser seguro, os dados têm de ser protegidos, e o acesso tem de ser controlado e registado. Uma solução mal implementada, num sistema partilhado sem segmentação de acesso, viola precisamente a confidencialidade que a lei exige garantir. Mais uma vez, a obrigação legal traduz-se em requisito técnico concreto.

8. Como a INFOS aborda isto

Trabalhamos há mais de três décadas dentro de fábricas portuguesas — têxtil, vestuário, calçado, distribuição, retalho, metal e plástico. Isso ensina uma coisa que os fornecedores generalistas não têm: a infraestrutura industrial não se separa das aplicações que corre. Um ERP MULTI vertical e a captura de produção em tempo real do KORA Productivity impõem requisitos concretos de latência, disponibilidade e integração com equipamento de chão-de-fábrica. Desenhar a infraestrutura sem conhecer estas aplicações é desenhar às cegas.

A nossa abordagem parte do negócio, não do hardware. Primeiro percebemos o calendário operacional — quando é o pico, quando é o fecho, quando chegam os compradores. Depois desenhamos a arquitetura que aguenta o pior dia, com opções de datacenter gerido, cibersegurança e continuidade que se ajustam à dimensão e à equipa interna da empresa. E ligamos a camada de decisão através

Perguntas frequentes

O que é infraestrutura de TI industrial?

Infraestrutura de TI industrial é o conjunto de servidores, armazenamento, rede e sistemas que suportam as operações de uma fábrica. Não é um tema abstrato — é a diferença entre expedir uma encomenda à hora marcada ou pagar penalização por atraso. Inclui desde o servidor que corre o ERP até à rede que liga os terminais de picking.

Por que é que o fecho de mês é tão crítico para a infraestrutura?

O fecho contabilístico e comunicação do SAF-T são um teste de esforço involuntário. Quando o ERP, backup nocturno e faturação correm simultaneamente, a infraestrutura frágil colapsa. Na indústria, o fecho cruza-se ainda com apuramento de produção — quantas peças saíram, quanto tempo demorou cada fase. Tudo disputa o mesmo disco à mesma hora.

Qual é a verdadeira causa da lentidão no fecho de mês?

Raramente é problema de CPU. É problema de I/O — leitura e escrita em disco. Um servidor com processador moderno e disco mecânico de 2015 arrasta da mesma forma. Trocar o armazenamento para SSD ou NVMe é muitas vezes a intervenção de maior impacto por euro investido, transformando um fecho de duas horas num fecho de vinte minutos.

Como é que a indústria do calçado enfrenta picos de procura?

Uma coleção de amostras tem entre 800 e 1200 SKUs cruzados em cor, tamanho e forma. Os compradores visitam duas vezes por ano (agosto e fevereiro). A infraestrutura passa por dois ou três meses de utilização comprimidos em quinze dias. Desenha-se para o pico, não para a média — e no calçado o pico é conhecido com um ano de antecedência.

O que exigem as marcas internacionais em termos de rastreabilidade?

As marcas cliente começam a exigir rastreabilidade de lote: de que fio veio a malha, em que banho foi tingida, com que corantes, consumo de água e energia. Isto não é requisito de marketing — é requisito de dados que a infraestrutura tem de sustentar. A pressão mudou de natureza: já não é só preço e prazo.

Como se manifesta um problema de infraestrutura deficiente?

Raramente como "a infraestrutura está má". Apresenta-se como sintomas dispersos: ERP lento, terminais que falham, backup demorado, stock não visível em tempo real. Cada sintoma é tratado isoladamente com pensos rápidos, até que um dia todos chegam ao mesmo tempo — sempre no pior momento possível.

Qual é o erro mais comum ao implementar um ERP?

Compra-se um ERP novo e moderno para correr numa fundação de 2011: servidor sem redundância, backup não testado, rede que cai quando entra a segunda linha de produção. O ERP não falha. A base debaixo dele é que nunca foi desenhada para aguentar. O problema não é de software — é de infraestrutura que o software vai amplificar.

Fontes

• Decreto-Lei n.º 133/2020, de 25 de dezembro — Regime de Comunicação de Dados de Faturação (SAF-T PT)
• Diretiva (UE) 2022/2555 (NIS2) — Segurança de Redes e Sistemas de Informação
• Norma ISO/IEC 27001:2022 — Sistemas de Gestão da Segurança da Informação
• Estratégia da UE para os Têxteis Sustentáveis e Circulares — Comissão Europeia, 2022
• APICCAPS — Associação Portuguesa dos Industriais de Calçado, Componentes e Matérias-Primas