Há cinco anos, víamos a due diligence tecnológica numa fusão industrial como um exercício de checklist: contagens de licenças, versões de software, estado dos servidores. Validar a infraestrutura e seguir. Hoje sabemos que isso era validar o esqueleto e ignorar o sistema nervoso. A verdade incómoda é que a maioria das fusões falha não porque o software era mau, mas porque ninguém perguntou se o software era capaz de suportar a operação real da empresa que se estava a comprar.

O erro que toda a gente faz: confundir o que está escrito com o que funciona

Entramos numa fábrica têxtil do Vale do Ave em Junho de 2023. Fusão aprovada, integração de sistemas marcada para Agosto. No papel, ambas as empresas usavam ERPs "modernos". Na realidade, uma delas tinha 47 customizações não-documentadas acumuladas em 12 anos — processos que nenhum fornecedor tinha registro, rotinas que um colaborador reformitório mantinha na memória, relatórios que só funcionavam em Terça-feira porque uma macro Excel disparava um job overnight.

Nenhum auditor tinha visto isto. Os consultores que fizeram a due diligence técnica inicial tinham pedido acesso aos ambientes de produção, recebido credenciais de um gestor de TI, corrido um scan de vulnerabilidades e saído. O que não fizeram: sentar-se com o gestor de armazém, o responsável de planeamento e o chefe de turno para perceber o que o ERP fazia realmente.

Uma due diligence tecnológica que não valida o gap entre o processo documentado e o processo que a fábrica usa todos os dias é uma due diligence que não viu nada.

O primeiro passo é validar a operação, não apenas o software. Senta-te com os utilizadores finais — não com os IT managers — e pede que descrevam um ciclo de trabalho completo: desde a receção de uma encomenda até ao envio da nota de débito. Onde é que o ERP intervém? Onde é que saem de TI e entram em Excel, papel ou sistemas paralelos? Cada interrupção é um risco operacional que a fusão vai herdar.

A integração de dados: o custo invisível que ninguém orça

Quando dois ERPs diferentes convivem numa mesma empresa — coisa que acontece em 70% das fusões industriais portuguesas nos primeiros 12 meses — a integração de dados não é um problema de TI. É um problema de negócio que TI tem de resolver.

Imagine uma distribuição que compra um concorrente. A adquirida usa QAD Adaptive, a adquirente usa um ERP genérico. Ambos têm tabelas de artigos, clientes, fornecedores. Parecem iguais. Não são. Um código de artigo é numérico com 10 dígitos; o outro é alfanumérico com 12. Um tem um campo "categoria" que o outro não tem. Um sincroniza preços em tempo real; o outro atualiza diariamente. Num cenário de integração rápida, isto não é tratado — cria-se um mapeamento "bom o suficiente" e espera-se que funcione. Três meses depois, o armazém está cheio de erros de picking porque o código de artigo foi traduzido mal, os preços de venda estão errados para 2.000 SKUs, e a força de vendas está a receber comissões incorretas.

Na due diligence, isto significa pedir um relatório de dados — não um diagrama. Quantos artigos tem a empresa adquirida? Quantas categorias? Qual é o volume diário de movimentos de stock? Qual é a integridade dos dados: quantos registos órfãos, quantos campos vazios, quantos duplicados? Isto não é uma pergunta que se faz a um CIO — é uma pergunta que se faz ao responsável de operações, com verificação técnica posterior.

A segurança e a conformidade: o que herda e o que fica exposto

O Decreto-Lei n.º 65/2025 transpôs a Diretiva NIS2 em Portugal, alargando as obrigações de cibersegurança a médias e grandes empresas de 18 setores críticos, incluindo a indústria transformadora. Uma fusão não suspende essas obrigações — as multiplica. De repente tens dois perímetros de rede, dois conjuntos de controlos, potencialmente dois níveis de maturidade.

O risco é direto: a empresa adquirida tinha 60% de maturidade em cibersegurança; a adquirente tinha 85%. Após fusão, se não integrares as políticas e os controlos, ficaste com um perímetro híbrido onde o pior nível contamina o melhor. Um servidor do adquirido sem patches há 8 meses é um ponto de entrada para a rede da adquirente. 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% ocorrendo em entidades privadas — e as PME são o alvo desproporcionado, presentes em 88% das violações de dados analisadas.

Na due diligence, isto significa pedir um relatório de postura de segurança. Certificações ISO 27001? Auditorias recentes? Qual é o estado de patch management? Qual é o nível de logging e monitorização? A empresa tem um serviço de cibersegurança contratado ou depende de TI interno? Isto não é paranoia — é obrigação regulatória. E uma falha aqui não é um problema de integração de 6 meses; é um risco operacional permanente que a regulação portuguesa e europeia vão fiscalizar.

O custo oculto: a equipa que vai fazer a integração não existe

Aqui entra a razão pela qual a maioria das integrações de sistemas em fusões industriais portuguesas falham ou atrasam 6-12 meses. A due diligence técnica valida o software. Mas ninguém pergunta: quem vai implementar a integração? E com que recursos?

Uma PME industrial típica tem um IT manager e talvez dois técnicos. Uma fusão exige, durante 6-9 meses, dedicação de 1-2 FTE (full-time equivalents) apenas à integração. Isso significa que o IT manager vai estar fora da operação do dia-a-dia. Quem apaga incêndios? Quem suporta os utilizadores quando o sistema fica lento no fim do mês? A resposta é: ninguém, ou o utilizador fica em espera enquanto o chefe de armazém liga para o gabinete a dizer que o picking parou.

Na due diligence, isto significa fazer um plano de recursos concreto. Quantos dias-pessoa vai custar a integração? Quem vai fazer — o IT manager, um consultor externo, uma combinação? Se for contratado externamente, qual é o custo real (não a proposta inicial, mas o custo real após mudanças de scope)? Se for interno, qual é o impacto na operação corrente? E — aqui é crítico — qual é o risco de que o projeto atrase porque a equipa interna foi desviada para apagar incêndios operacionais?

Uma integração de sistemas sem plano de recursos é uma integração que está destinada a falhar.

O que validar: um roteiro prático

Portanto, o que deve estar num checklist de due diligence tecnológica real?

  • Mapeamento de processos. Senta-te com os utilizadores finais. Pede que descrevam um ciclo de trabalho completo. Onde é que o ERP MULTI ou o sistema em questão sai de jogo? Cada saída é um risco.
  • Auditoria de dados. Quantos registos? Qual é a integridade? Quantos duplicados, órfãos, campos vazios? Isto determina o esforço real de integração.
  • Postura de segurança. Certificações? Estado de patch? Logging? Monitorização? Isto não é opcional — é obrigação regulatória conforme o DL 65/2025.
  • Plano de recursos. Quantos dias-pessoa? Quem faz? Qual é o impacto na operação? Isto determina o calendário real, não o calendário que está escrito numa proposta.
  • Documentação técnica. Customizações? Integrações paralelas? Macros? Rotinas que "ninguém sabe como funcionam"? Isto é o risco oculto que vai aparecer seis meses depois.

E há uma última coisa que ninguém valida: a cultura organizacional. Mas isso é outro artigo — lê aqui como o ERP não resolve a cultura.

O que vimos em 35 anos é que as fusões que funcionam não são as que tinham o melhor software. São as que fizeram perguntas difíceis cedo, encontraram respostas honestas, e orçamentaram o real custo de integração — não o custo que estava escrito numa proposta de consultoria ou num slide-deck de vendas.

Perguntas frequentes

O que é uma due diligence tecnológica numa fusão industrial?

É a validação técnica de uma empresa antes da aquisição. Vai além de contar licenças e verificar servidores — deve avaliar se o software funciona realmente na operação do dia-a-dia, identificar customizações não-documentadas, gaps de integração de dados e riscos de segurança que a empresa adquirente vai herdar após a fusão.

Qual é o erro mais comum na due diligence tecnológica?

Confundir o que está documentado com o que funciona na prática. Muitos auditores correm scans de vulnerabilidades e saem, sem conversar com utilizadores finais sobre processos reais. Uma fábrica pode ter um ERP "moderno" no papel, mas usar 47 customizações não-documentadas, Excel paralelo e rotinas que apenas um colaborador conhece.

Como validar a operação real durante a due diligence?

Senta-te com utilizadores finais — gestores de armazém, responsáveis de planeamento, chefes de turno — e pede que descrevam um ciclo de trabalho completo, desde a receção de encomenda até ao envio da nota de débito. Identifica onde saem do sistema para Excel, papel ou sistemas paralelos. Cada interrupção é um risco operacional que a fusão vai herdar.

Qual é o custo invisível da integração de dados em fusões?

Quando dois ERPs diferentes convivem, os dados parecem compatíveis mas não são. Códigos de artigos podem ter formatos diferentes, campos podem estar vazios, categorias podem não corresponder. Sem tratamento adequado, isto causa erros de picking, preços incorretos e comissões erradas três meses após a fusão.

O que pedir sobre dados na due diligence?

Pede um relatório de dados concreto: quantos artigos, quantas categorias, volume diário de movimentos de stock, integridade dos dados (registos órfãos, campos vazios, duplicados). Esta pergunta deve ser feita ao responsável de operações com verificação técnica posterior, não ao CIO.

Como a NIS2 afeta a due diligence tecnológica em fusões?

O Decreto-Lei n.º 65/2025 alargou obrigações de cibersegurança a médias e grandes empresas de 18 setores críticos, incluindo indústria transformadora. Uma fusão multiplica esses riscos: dois perímetros de rede, dois níveis de maturidade. Se não integrares controlos, o pior nível contamina o melhor e cria pontos de entrada para a rede da adquirente.

Qual é o custo oculto que ninguém orça numa integração?

A equipa que vai fazer a integração. Uma PME industrial típica tem um IT manager e dois técnicos. Uma fusão exige 1-2 FTE dedicados durante 6-9 meses apenas à integração. Isto significa que o suporte ao dia-a-dia fica desprotegido. Na due diligence, deve fazer-se um plano de recursos concreto e calcular o custo real da integração externa, se necessária.