Engenharia de sistemas: alinhar a infraestrutura a estrategia

Oitenta por cento das empresas industriais portuguesas que nos pedem para implementar um novo sistema têm o mesmo problema: a infraestrutura não falhou por falta de investimento. Falhou por falta de alinhamento. Compraram servidores sem saber o RTO do ERP. Migraram para cloud sem medir a latência da linha de produção. Renovaram switches sem perguntar ao chefe de armazém o que o paralisa. O resultado aparece sempre no mesmo momento: fim de mês, pico de faturação, ERP a abrandar, turno da tarde parado.

Este guia não é um levantamento neutro de boas práticas. É um argumento: a auditoria de infraestrutura só tem valor se começar pelos processos de negócio e trabalhar para trás — nunca o contrário. Cinco dimensões, um template de decisão, e pelo menos um erro que provavelmente já cometeu.

O que precisa antes de começar

Sem estes elementos em mão, o exercício produz listas bonitas que ninguém executa. Reúna-os antes de convocar qualquer reunião de auditoria.

Precisa do mapa dos processos críticos — produção, faturação, expedição, vendas — mesmo que seja um diagrama de blocos desenhado à mão. Precisa do inventário de sistemas atual: ERP, MES, WMS, BI, POS, portais, com versão e data do último upgrade. Precisa do contrato de SLA do fornecedor de infraestrutura ou datacenter — leia as cláusulas de disponibilidade e os valores de RTO/RPO contratados. E precisa do relatório do último incidente de TI com impacto operacional, mesmo que seja apenas um e-mail de suporte com hora de início e hora de resolução.

Junte ainda o orçamento de TI aprovado para o ano corrente separado por CAPEX e OPEX, a lista das obrigações regulatórias aplicáveis — NIS2, DL 28/2019, RGPD — e pelo menos um representante de cada área operacional disposto a responder a dez perguntas diretas. Sem a voz das operações, a auditoria fica a descrever a infraestrutura que o IT conhece, não a infraestrutura que o negócio precisa.

Dimensão 1 — Pessoas: quem decide e quem sofre

O erro mais comum que vemos em projectos INFOS não é técnico. É organizacional: a infraestrutura é desenhada pelo IT sem input das operações, e as operações nunca foram perguntadas sobre o que as paralisa.

Numa fábrica de confecção típica do Vale do Ave com 120 colaboradores, o responsável de IT gere sozinho servidores, ERP, rede Wi-Fi do chão de fábrica e helpdesk. Quando há um incidente às 7h da manhã no arranque do turno, a decisão de prioridade é dele — sem critério formal, sem matriz de escalonamento, sem ninguém a dizer-lhe qual processo custa mais por hora parado. O resultado concreto que vimos repetido: o sistema de ponto eletrónico fica em baixo durante 40 minutos porque o servidor de produção foi reiniciado primeiro. A decisão foi tecnicamente razoável. Operacionalmente, custou 40 minutos de registo manual em papel que ninguém depois conseguiu reconciliar.

A solução não é contratar mais IT. É definir uma matriz RACI mínima para incidentes de infraestrutura — três colunas chegam: sistema afetado, responsável técnico, responsável de negócio a notificar. Identifique os dois ou três processos cuja paragem custa mais por hora e nomeie um "dono de processo" para cada um: não é o IT, é a operação. Documente quem autoriza uma paragem planeada e com quanto tempo de antecedência. Verifique se o IT tem substituto para ausências — férias, baixa, saída. Numa empresa com um único técnico de IT, a ausência não planeada é, ela própria, um incidente de continuidade.

Dimensão 2 — Processos: mapear o que a infraestrutura tem de suportar

A infraestrutura não existe para "suportar o negócio" em abstracto. Existe para garantir que processos específicos correm dentro de parâmetros definidos. Se não tiver esses parâmetros escritos, qualquer decisão de infraestrutura é uma aposta disfarçada de investimento.

Para cada processo crítico, responda a quatro perguntas sem ambiguidade. Qual é o tempo máximo de indisponibilidade tolerável — o RTO? Qual é a perda máxima de dados tolerável — o RPO? Qual é o pico de carga previsível — fim de mês, fecho de coleção, Black Friday, arranque de turno? Que sistemas externos dependem deste processo — cliente, transportadora, AT, banco?

O detalhe que os manuais não referem: em empresas de calçado de Felgueiras com coleções de 800 a 1 200 SKUs, o pico de carga não é o fim de mês — é a semana anterior à visita dos compradores internacionais, quando toda a equipa comercial acede simultaneamente ao ERP para gerar fichas técnicas, listas de preços e disponibilidades. Se a infraestrutura foi dimensionada para carga média, essa semana é sempre um problema. Mapeie os picos reais do seu negócio, não os picos que o IT imagina.

Mapeie dependências entre sistemas — o ERP que alimenta o WMS que alimenta o POS. Identifique pontos únicos de falha: um servidor, uma ligação de rede, um fornecedor. Verifique se os backups são testados — não apenas executados. Restaure um ficheiro de teste trimestralmente, com cronómetro. Documente os procedimentos manuais de contingência para cada processo crítico: quando o sistema cai, a equipa não pode perder tempo a perceber o que fazer.

Dimensão 3 — Sistemas: o inventário que ninguém quer fazer

Audite o que existe antes de comprar o que falta. Em projectos de implementação de ERP MULTI em empresas industriais, é frequente descobrir sistemas em produção que ninguém sabia que ainda estavam ativos — um servidor de ficheiros com dados de 2014, um software de gestão de encomendas que foi "substituído" há três anos mas ainda recebe dados de um cliente antigo porque ninguém comunicou a mudança. Esses sistemas invisíveis são passivos de segurança e de conformidade.

Preencha uma linha por sistema. Qualquer célula vazia é um risco não gerido. Identifique sistemas sem suporte ativo do fornecedor — são passivos de segurança imediatos. Verifique licenciamento: software sem licença válida expõe a empresa a auditoria e a vulnerabilidades não corrigidas. Classifique cada sistema por criticidade — não todos são iguais e não devem receber o mesmo investimento de resiliência.

Dimensão 4 — Dados: o ativo que a infraestrutura tem de proteger

A infraestrutura não protege servidores. Protege dados. Se não sabe onde estão os dados críticos, não sabe o que está a proteger.

O custo médio global de uma violação de dados atingiu 4,88 milhões de dólares em 2024 — um aumento de 10% face a 2023 (IBM, 2024). Para uma PME industrial portuguesa, o impacto não é esse valor absoluto: é a paragem de produção, a perda de confiança do cliente internacional, e a exposição regulatória. Os números nacionais confirmam a tendência: o CERT.PT registou 2 758 incidentes de cibersegurança em Portugal em 2024, mais 36% do que em 2023, sendo que 78% ocorreram em entidades privadas (CNCS, 2024). E segundo o Verizon DBIR 2025, o ransomware esteve presente em 88% das violações de dados em PME — contra 39% nas grandes organizações. As pequenas e médias empresas são o alvo desproporcionado, precisamente porque a infraestrutura é mais simples de comprometer e a capacidade de resposta é menor.

A Diretiva NIS2, transposta em Portugal pelo Decreto-Lei n.º 65/2025, obriga médias e grandes empresas de setores críticos — incluindo a indústria — a implementar controlos de segurança documentados e a reportar incidentes. Ignorar isto não é uma opção de gestão: é uma exposição legal com coimas e responsabilidade de administradores.

Para alinhar dados e infraestrutura, classifique os dados por sensibilidade — dados de clientes, dados financeiros, dados de produção, dados de RH — e mapeie onde cada categoria está armazenada: servidor local, cloud, laptop de colaborador, pen drive. Verifique se o acesso a dados sensíveis está restrito por perfil. Confirme que os backups de dados críticos estão fora do site principal, seguindo a regra 3-2-1: três cópias, dois suportes diferentes, uma cópia offsite. Audite os logs de acesso — se não existem, é a primeira coisa a implementar, antes de qualquer outro controlo.

Para aprofundar os controlos técnicos de segurança aplicáveis à indústria, consulte o artigo sobre NIS2 na prática: controlos técnicos para fábricas portuguesas. Para perceber os riscos que passam despercebidos, leia os riscos silenciosos da cibersegurança na empresa.

Dimensão 5 — Conformidade: o que a lei já exige

A conformidade não é um projecto separado da infraestrutura. É um conjunto de requisitos que a infraestrutura tem de cumprir — e que, se ignorados, geram coimas, auditorias e paragens forçadas. O problema mais frequente que vemos não é desconhecimento da lei: é a empresa que sabe da obrigação mas assume que "o fornecedor trata disso". O fornecedor trata do software. A responsabilidade é da empresa.

O DL 28/2019 exige que o software de faturação seja certificado pela AT: verifique se a versão em uso tem certificação válida e se emite ATCUD corretamente — uma versão desactualizada pode invalidar facturas emitidas. O RGPD e a Lei 58/2019 exigem base legal para tratamento de dados pessoais, prazo de retenção definido e capacidade de resposta a pedidos de acesso ou eliminação em 30 dias. A NIS2 e o DL 65/2025 obrigam empresas médias e grandes de setores críticos a documentar a política de segurança, os procedimentos de resposta a incidentes e o contacto formal com o CNCS. A Lei 93/2021 torna obrigatório o canal de denúncias para empresas com 50 ou mais colaboradores — verifique se a infraestrutura o suporta com confidencialidade garantida, o que exclui um simples endereço de e-mail partilhado com o departamento de RH. E se usa assinatura digital em contratos ou documentos legais, confirme que é assinatura qualificada nos termos do eIDAS 2 — não uma imagem digitalizada de uma assinatura manuscrita, que não tem valor legal equivalente.

Cinco erros que a auditoria vai encontrar — e como corrigi-los

Erro 1 — Comprar infraestrutura sem RTO/RPO definidos. O resultado é um servidor novo que ninguém sabe quanto tempo pode estar em baixo. Antes de qualquer aquisição, defina RTO e RPO por processo crítico. Se o ERP não pode estar em baixo mais de duas horas, isso tem implicações diretas na arquitetura de backup e na decisão entre servidor local e cloud.

Erro 2 — Tratar a cloud como destino, não como decisão. Migrar para cloud sem avaliar latência, custo de egress e dependência de conectividade cria novos problemas. Uma fábrica com linha de produção dependente de ERP em cloud pública e uma ligação de internet sem redundância é mais frágil do que um servidor local bem gerido. Analise o ROI real da migração, incluindo os custos de falha e o custo mensal de uma ligação redundante — que é obrigatória, não opcional, se o processo crítico depender de conectividade.

Erro 3 — Ignorar a rede do chão de fábrica. O Wi-Fi industrial não é o mesmo que o Wi-Fi de escritório. Terminais de produção, leitores de código de barras e equipamentos de captura de produção em tempo real exigem cobertura estável, segmentação de rede e redundância. Vemos regularmente fábricas onde a rede de OT — Operational Technology — partilha o mesmo segmento que os portáteis dos comerciais. Quando um portátil é comprometido, a rede de produção fica exposta. A segmentação não é um projecto de cibersegurança avançado: é configuração de switch, e deve estar feita antes de qualquer terminal industrial ser ligado à rede.

Erro 4 — Confundir backup com recuperação. Ter backup não significa conseguir recuperar. Teste a restauração completa de um sistema crítico pelo menos uma vez por ano, com cronómetro e com a pessoa que vai fazer a recuperação real — não o técnico que configurou o backup. O resultado vai surpreendê-lo, quase sempre negativamente. Numa empresa de distribuição do corredor Lousada/Paços, o teste revelou que o backup do WMS estava a ser feito para uma pasta que já não existia há seis meses. O backup executava sem erro. Não havia nada guardado.

Erro 5 — Deixar a conformidade para o fim. A conformidade regulatória não é uma camada que se aplica sobre a infraestrutura existente. É um requisito de desenho. Quando a NIS2 obriga a logs de acesso auditáveis e a empresa não tem logging configurado, o custo de implementação retroactiva é sempre superior ao custo de o ter feito de raiz. Integre os requisitos regulatórios na auditoria desde a primeira dimensão — não como checklist final, mas como critério de decisão em cada escolha de infraestrutura.

A auditoria em cinco dimensões não é um exercício académico. É o trabalho de duas a três semanas que evita seis meses de recuperação depois de um incidente. A diferença entre as empresas que recuperam depressa e as que não recuperam não está na tecnologia que tinham — está no facto de saberem exatamente o que tinham, onde estava, e o que fazer quando deixou de funcionar.

Perguntas frequentes

O que é o RTO e por que é importante para a infraestrutura?

RTO (Recovery Time Objective) é o tempo máximo que um processo crítico pode estar indisponível. Define quanto tempo a empresa tolera de paragem antes de sofrer perdas operacionais graves. Sem RTO definido, a infraestrutura fica dimensionada ao acaso, causando paralagens desnecessárias ou investimentos desperdiçados em redundância.

Como identificar os processos críticos da minha empresa?

Comece pelos processos que, se pararem, custam dinheiro imediatamente: produção, faturação, expedição e vendas. Reúna responsáveis de cada área e pergunte qual é o impacto por hora de paragem. Mapeie também as dependências — qual o sistema que alimenta qual. Um diagrama de blocos desenhado à mão é suficiente para começar.

Qual é a diferença entre RTO e RPO?

RTO é o tempo máximo de indisponibilidade tolerável. RPO (Recovery Point Objective) é a quantidade máxima de dados que pode perder — por exemplo, "perdemos dados dos últimos 15 minutos". Um ERP pode ter RTO de 4 horas mas RPO de 5 minutos, exigindo backups frequentes mesmo que a recuperação seja mais lenta.

Por que falham as auditorias de infraestrutura tradicionais?

Falham porque começam pela tecnologia em vez do negócio. Descrevem o que existe sem questionar se serve o que é preciso. Produzem listas bonitas que ninguém executa porque não têm ligação aos processos reais. A auditoria correta começa pelos processos críticos e trabalha para trás até à infraestrutura necessária.

O que é uma matriz RACI para incidentes de infraestrutura?

É um documento simples com três colunas: sistema afetado, responsável técnico, responsável de negócio a notificar. Define quem decide a prioridade de cada incidente e quem comunica aos utilizadores. Evita que o IT decida sozinho qual sistema reiniciar primeiro, sem saber qual custa mais por hora parado.

Como devo testar os meus backups?

Não basta executar backups automaticamente. Trimestralmente, restaure um ficheiro de teste com cronómetro e documente o tempo. Verifique se os dados estão íntegros e se consegue aceder sem problemas. Um backup nunca testado é apenas um ficheiro que ocupa espaço — pode estar corrompido e ninguém sabe.

Que informação preciso de recolher antes de fazer uma auditoria de infraestrutura?

Mapa dos processos críticos, inventário de sistemas com versões, contratos de SLA com valores de RTO/RPO, relatório do último incidente de TI, orçamento de TI separado por CAPEX e OPEX, obrigações regulatórias aplicáveis, e pelo menos um representante de cada área operacional. Sem a voz das operações, a auditoria descreve a infraestrutura que o IT conhece, não a que o negócio precisa.

Fontes

• Diretiva (UE) 2022/2555 (NIS2) — Segurança de Redes e Sistemas de Informação, requisitos de continuidade operacional e gestão de incidentes
• Decreto-Lei n.º 28/2019 — Transposição da Diretiva (UE) 2016/1148 (NIS1), obrigações de operadores de serviços essenciais em Portugal
• Regulamento (UE) 2016/679 (RGPD) — Proteção de dados pessoais, incluindo requisitos de disponibilidade e integridade de sistemas
• Norma ISO/IEC 27001:2022 — Gestão de segurança da informação, continuidade de negócio e recuperação de desastres
• ENISA — Guidelines on Incident Handling and Response (2016) — Boas práticas em gestão de incidentes de infraestrutura e TI