Uma coleção de calçado masculino para a época de verão ultrapassa facilmente as 900 referências — cada uma com combinações de número, largura, cor e forro. Nenhum ERP generalista modela isto nativamente. O que acontece na prática: a empresa compra o ERP genérico, paga a implementação, e depois paga outra vez — em personalizações, em folhas de cálculo paralelas, em horas de equipa a reconciliar dados que o sistema não consegue estruturar. Este artigo defende uma tese incómoda: o ERP genérico não é uma opção mais barata para o calçado português. É uma opção com custos diferidos que só aparecem quando já é tarde para mudar sem dor.
O erro de análise mais caro que um CFO pode cometer
A comparação começa e acaba no preço de licença. É o pior atalho mental disponível na decisão de ERP para a indústria de calçado.
O preço de licença é visível, está na proposta, tem uma linha no orçamento. Os custos de adaptação, de manutenção de personalizações e de ineficiência operacional acumulada não aparecem em nenhuma proposta. Aparecem nas horas extra do planeamento, nos erros de expedição para compradores em Milão, e nas notas de crédito emitidas porque o sistema não distinguiu o artigo 42 estreito do 42 normal.
O ERP genérico é mais barato no dia da assinatura. A diferença de custo real só é visível dezoito meses depois — e raramente aparece num único centro de custo.
O contexto de mercado torna esta decisão ainda mais crítica. A indústria portuguesa de calçado exportou 1.718 milhões de euros em 2025, correspondendo a cerca de 68 milhões de pares — com crescimento de 3,3% para os mercados europeus, que absorvem 1.420 M€, segundo a APICCAPS (fevereiro de 2026). São compradores exigentes, que visitam as fábricas de Felgueiras e Guimarães com cadernos de encargos técnicos cada vez mais densos. Neste contexto, um ERP que não modela a estrutura de produto nativa do calçado não é uma limitação menor — é um handicap estrutural que se paga coleção após coleção.
O que o ERP genérico não consegue modelar nativamente
A grade de tamanhos: onde o modelo de dados parte primeiro
Um ERP generalista trata o produto como uma combinação de atributos simples: referência + cor + tamanho. No calçado, a realidade é outra. Uma única referência pode ter três eixos simultâneos — número europeu, largura do cabedal e tipo de forro — com disponibilidade diferenciada por eixo. A grade não é linear: o 37 pode existir em três larguras, o 42 em duas, e o 45 só numa. E o 45 consome mais couro que o 37 — o que afeta o custeio por tamanho, não apenas por referência.
Modelar isto num ERP genérico obriga a uma de duas escolhas, e as duas são más. A primeira é criar uma referência distinta para cada combinação — o que explode a base de dados de artigos e torna o SCM ingerível a partir de certa dimensão de coleção. A segunda é usar campos de texto livres e gerir a lógica em folhas de cálculo externas — o que garante erros de expedição e impossibilita o cálculo automático de necessidades de componentes.
Um ERP vertical para calçado tem a grade como estrutura nativa. A encomenda do cliente entra com a distribuição por tamanho. O planeamento de produção calcula as necessidades por componente com base nessa grade. O armazém expede com conferência automática por número. Não há adaptação — é o modelo de dados base.
O detalhe que os manuais não referem: o problema não é só a expedição errada. É que sem a grade nativa, o MRP calcula necessidades de matéria-prima com base em médias de tamanho — e uma coleção com picos de procura no 42 e 43 gera ruturas de couro mesmo com stock "suficiente" no sistema. O responsável de compras descobre-o quando o cortador pára a linha.
Gestão de coleções: o ciclo de vida que o ERP genérico não conhece
A indústria de calçado trabalha por coleções. Cada uma tem um ciclo de vida próprio: desenvolvimento de amostras, aprovação pelo comprador, confirmação de encomendas, produção, expedição. Os compradores internacionais visitam as fábricas duas vezes por ano — calçado de homem em agosto, de mulher em fevereiro — e o que apresentam em feira tem de estar ligado ao que o sistema consegue planear e produzir.
Um ERP genérico não tem o conceito de coleção como entidade de gestão. Tem ordens de venda e ordens de produção, sem a ligação temporal e comercial que o ciclo de coleção exige. O resultado prático é que o planeamento de capacidade para a época seguinte é feito fora do sistema, as amostras aprovadas não têm rastreabilidade automática para a ordem de produção, e o custo de desenvolvimento de coleção fica num centro de custo genérico — nunca aparece na margem real por referência. O artigo sobre planeamento de capacidade produtiva no ERP aprofunda este ponto com detalhe técnico.
Rastreabilidade de componentes: o que a ESPR já exige
A regulação europeia de ecodesign de produto (ESPR), em vigor desde julho de 2025, aumenta significativamente as exigências de rastreabilidade sobre produtos colocados no mercado europeu — incluindo calçado. O passaporte digital de produto vai exigir que o fabricante identifique a origem de cada componente: couro, sola, cola, forro, atacadores.
Um ERP genérico sem rastreabilidade lote-a-lote nativa não responde a esta exigência sem personalização extensiva. Um ERP vertical já tem a estrutura de componentes ligada à ordem de produção, ao lote de matéria-prima e ao fornecedor — porque sempre foi necessário para gerir reclamações de compradores internacionais muito antes de qualquer regulamento europeu o exigir. O artigo sobre rastreabilidade lote-a-lote na indústria portuguesa detalha o que o ERP deve garantir e o que ainda fica em papel.
Onde aparece a segunda fatura
Personalização inicial: o custo que ninguém orçamenta completo
A proposta do ERP genérico inclui normalmente um número de dias de consultoria para "adaptação ao setor". Na prática, a grade de tamanhos, a gestão de coleções e a rastreabilidade de componentes não são adaptações de configuração — são desenvolvimentos de software. A diferença é crítica: uma adaptação de configuração é mantida nas atualizações do sistema; um desenvolvimento específico não.
Cada atualização de versão do ERP genérico obriga a retestar e, frequentemente, a reescrever as personalizações. O custo de manutenção cresce com a complexidade do negócio e com cada nova versão do fornecedor. Ao fim de cinco anos, a empresa tem um sistema que ninguém quer atualizar porque a atualização parte o que funciona — e um fornecedor que cobra cada vez que o mercado muda as regras.
O cenário que se repete em Felgueiras
Numa fábrica de calçado com 120 colaboradores, o padrão é reconhecível: o ERP genérico gere a contabilidade e as vendas; a gestão de coleções está numa aplicação separada desenvolvida por um freelancer há oito anos; a grade de tamanhos é gerida em Excel partilhado em rede; o armazém usa picking manual com conferência em papel. A equipa de IT — muitas vezes uma única pessoa com 15 anos de conhecimento de negócio acumulado — passa uma parte significativa do tempo a reconciliar dados entre estes sistemas. Este tempo não aparece em nenhum ROI da implementação original. Aparece no burnout da pessoa que o faz.
O risco invisível: quando essa pessoa sai, o conhecimento de como os sistemas comunicam vai com ela. O que fica é um conjunto de ficheiros Excel com fórmulas que ninguém compreende completamente e uma integração que "funciona se não tocar".
Custeio industrial: a margem que ninguém calcula bem
O custeio por referência no calçado é estruturalmente complexo. Inclui matérias-primas com variação por tamanho, mão de obra direta com variação por operação e por modelo, subcontratação de costura e acabamento, amortização de moldes e ferramentas, e custo de desenvolvimento de coleção. Um ERP genérico calcula custos por centro de custo. Um ERP vertical calcula a margem real por referência, por coleção, por comprador.
A diferença não é académica. É a diferença entre saber que a coleção primavera/verão foi rentável no agregado e saber que o modelo Oxford em couro castanho teve margem negativa porque o molde foi amortizado numa tiragem demasiado pequena — e que o mesmo modelo em pele sintética, com o mesmo preço de venda, teve margem de 23%. Sem esta granularidade, a decisão de repetir ou descontinuar uma referência na próxima coleção é uma intuição, não uma análise. O artigo sobre custeio industrial no ERP detalha como passar do centro de custo à margem real por referência.
Comparação técnica: ERP vertical vs. ERP genérico no calçado
| Capacidade | ERP Genérico | ERP Vertical Calçado | Impacto operacional |
|---|---|---|---|
| Grade de tamanhos nativa | Não — requer desenvolvimento | Sim — estrutura base | Erros de expedição, stock incorreto, MRP por médias |
| Gestão de coleções | Não — requer módulo externo | Sim — ciclo de vida integrado | Planeamento fora do sistema, custo de desenvolvimento perdido |
| Rastreabilidade lote/componente | Parcial — requer personalização | Sim — lote a componente | Incumprimento ESPR, reclamações sem resposta rápida |
| Custeio por referência/tamanho | Não — centro de custo genérico | Sim — margem por SKU | Decisões de coleção sem dados reais |
| Integração com força de vendas em mobilidade | Requer integração externa | Nativa ou pré-integrada | Catálogos desactualizados em feira, referências indisponíveis apresentadas |
| Conformidade DL 28/2019 (ATCUD/SAF-T) | Depende de certificação AT | Certificado AT | Risco legal e fiscal, invalidação de documentos |
| Custo de manutenção de personalizações | Alto — recorrente por versão | Baixo — funcionalidade standard | TCO real superior ao previsto em proposta |
Trade-offs por dimensão de empresa
Empresas até 50 colaboradores
A tentação do ERP genérico é maior porque o preço de licença pesa mais na decisão. O risco é proporcional: com menos recursos de IT internos, a manutenção de personalizações recai sobre o fornecedor ou sobre um técnico que acumula funções. Quando esse técnico sai, o conhecimento vai com ele. A questão não é se a empresa consegue implementar um ERP genérico — consegue. A questão é se consegue mantê-lo funcional à medida que a coleção cresce e os compradores internacionais exigem mais rastreabilidade. A resposta, na maioria dos casos que vemos, é não.
Empresas entre 50 e 200 colaboradores
Este é o segmento mais crítico — e onde o argumento do ERP vertical é mais forte. Já têm complexidade suficiente para que as limitações do ERP genérico sejam dolorosas: coleções com 600 a 1.200 SKUs, múltiplos compradores internacionais com exigências distintas de rastreabilidade, subcontratação de operações a terceiros que precisa de ser integrada no custeio. Mas ainda não têm a dimensão que justifica um ERP de grande porte com implementação de 18 meses. É aqui que a funcionalidade específica sem o custo e a duração dos sistemas de topo tem o argumento mais claro.
Grupos com múltiplas fábricas ou marcas próprias
Acima desta dimensão, a consolidação multi-empresa e multi-moeda entra na equação. Para grupos com operações em Portugal e no exterior, a escolha pode recair sobre um ERP de maior porte como o QAD Adaptive ERP, que combina flexibilidade low-code com funcionalidade industrial profunda sem os custos de personalização de código que caracterizam os ERPs genéricos adaptados. O artigo sobre ERP multi-empresa em Portugal cobre este cenário com detalhe.
Matriz de decisão: quando escolher cada abordagem
| Critério | ERP Genérico | ERP Vertical Calçado | ERP Grande Porte (low-code) |
|---|---|---|---|
| Dimensão da empresa | <30 colaboradores, baixa complexidade | 30–300 colaboradores, cluster calçado | >200 colaboradores, grupo multi-país |
| Complexidade de SKUs | Baixa (<200 referências simples) | Alta (grade + coleções + componentes) | Muito alta (multi-marca, multi-fábrica) |
| Exigência de rastreabilidade | Mínima | Alta (ESPR, compradores internacionais) | Muito alta (certificações, auditoria) |
| Prazo de implementação típico | 3–6 meses (sem personalizações) | 4–8 meses | 12–24 meses |
| Custo de personalização inicial | Alto (funcionalidade em falta) | Baixo (funcionalidade nativa) | Médio (configuração low-code) |
| Risco de manutenção a 5 anos | Alto (personalizações acumulam) | Baixo (standard do setor) | Baixo (plataforma configurável) |
| Conformidade fiscal PT (DL 28/2019) | Verificar certificação AT | Incluída | Incluída |
O que funciona na prática
Separar o ERP do sistema de força de vendas em mobilidade — mas com integração nativa
Uma prática comum nas fábricas do cluster de Felgueiras e Guimarães é usar o ERP vertical para a gestão interna — produção, armazém, financeira — e complementá-lo com uma solução de mobilidade para a força de vendas em feiras e visitas a clientes. A integração nativa entre o ERP e a aplicação de vendas garante que o catálogo apresentado em feira é o mesmo que está no sistema, com disponibilidade real e preços atualizados.
Quando esta integração não existe — ou é feita por ficheiros exportados manualmente na véspera da feira — o vendedor apresenta referências que já não estão disponíveis, ou preços que foram alterados depois da exportação. O erro não é do vendedor. É da arquitetura.
Rastreabilidade de componentes antes da ESPR, não por causa dela
As fábricas que já tinham rastreabilidade lote-a-lote implementada antes da ESPR não o fizeram por antecipação regulatória. Fizeram-no porque os compradores internacionais já exigiam auditorias de fornecedores e conformidade de materiais há vários anos. A regulação europeia veio formalizar o que o mercado já impunha. A lição operacional é direta: implementar rastreabilidade de componentes como resposta a um regulamento é sempre mais caro e mais perturbador do que tê-la como funcionalidade base desde o início. O artigo sobre colaboração B2B com fornecedores mostra como estruturar este fluxo sem depender de email.
A análise ABC de referências como filtro de custeio
Numa coleção com 800 a 1.200 SKUs, calcular o custo real de cada referência com o mesmo nível de detalhe é inviável — e desnecessário. O que funciona é aplicar uma análise ABC às referências por volume e margem esperada, e concentrar o custeio detalhado nas referências A, que tipicamente representam a maioria da faturação. As referências C são geridas com custo standard. Esta abordagem só é possível quando o ERP tem a estrutura de dados para a suportar nativamente — quando a grade, o custeio por tamanho e a ligação à ordem de produção existem como modelo base, não como personalização.
Numa coleção de 1.000 referências, as que realmente determinam a margem são frequentemente menos de 150. O problema é que sem o ERP certo, não se sabe quais são — e decide-se pela intuição do comercial.
Conformidade regulatória: o custo invisível do ERP não certificado
DL 28/2019 e certificação AT
O Decreto-Lei 28/2019 obriga à utilização de programas de faturação certificados pela Autoridade Tributária. A comunicação mensal do SAF-T (Portaria 195/2020) é obrigatória. Um ERP genérico importado ou desenvolvido localmente sem certificação AT coloca a empresa em risco de coima e de invalidação de documentos fiscais. Verifique sempre se o ERP que está a avaliar tem certificação AT válida e atualizada — não apenas se "suporta" SAF-T. São coisas diferentes: suportar o formato é uma questão técnica; ter a certificação é uma questão legal.
NIS2 e a segurança do sistema de gestão
A Diretiva NIS2 (transposta para Portugal pelo DL 65/2025) alarga as obrigações de cibersegurança a setores que anteriormente não estavam abrangidos. Para fábricas de calçado integradas em cadeias de fornecimento de grandes marcas internacionais, a pressão de conformidade vem também dos próprios compradores — que auditam fornecedores críticos com questionários de segurança cada vez mais detalhados. Um ERP alojado em infraestrutura sem controlos de segurança adequados é um vetor de risco. A gestão de acessos, a encriptação de dados e a capacidade de recuperação após incidente são requisitos que o ERP e a infraestrutura subjacente têm de cumprir em conjunto.
O ransomware não escolhe o setor. Escolhe a vulnerabilidade. Uma fábrica de calçado com o ERP exposto sem autenticação multifactor é um alvo tão válido como qualquer outro — e uma paragem de três dias em plena produção de coleção tem um custo que nenhuma apólice cobre completamente.
Como medir o sucesso pós-implementação
A avaliação de um ERP vertical no calçado não deve ser feita aos seis meses — deve ser feita no final da primeira coleção completa gerida no sistema. Os indicadores relevantes não são os do fornecedor; são os do negócio.
A taxa de erro de expedição por grade de tamanhos mede o número de notas de crédito emitidas por erro de referência ou tamanho, comparado com o período anterior. O tempo de fecho de coleção — dias entre o encerramento de encomendas e a confirmação de planeamento de produção — deve reduzir de forma mensurável: se não reduzir, o sistema não está a ser usado para o que foi comprado. A cobertura de rastreabilidade de componentes mede a percentagem de ordens de produção com lote de matéria-prima identificado; o objetivo é 100% para referências A. A margem real por referência calculada automaticamente mede a percentagem de referências com custeio completo no sistema, sem necessidade de cálculo manual em folha de cálculo. E o tempo de reconciliação de dados entre sistemas — horas semanais gastas a exportar, importar e corrigir dados entre o ERP e ferramentas externas — deve tender para zero nos fluxos críticos.
O ERP MULTI foi desenhado com estas métricas como requisitos funcionais, não como opções de configuração. A grade de tamanhos, a gestão de coleções e a rastreabilidade de componentes são estrutura base — não módulos adicionais. Para empresas com maior complexidade multi-empresa ou operações internacionais, o QAD Adaptive ERP oferece uma plataforma configurável sem os custos de personalização de código que caracterizam os ERPs genéricos adaptados ao calçado.
A questão final não é "qual o ERP mais barato". É "qual o custo total de não ter a funcionalidade certa" — e no calçado português, esse custo acumula-se silenciosamente, coleção após coleção, até aparecer numa auditoria de comprador, numa expedição errada para um cliente em Milão, ou numa notificação da AT sobre documentos não conformes.
Fontes
- APICCAPS — Footwear Monitor, fevereiro de 2026. Dados de exportação da indústria portuguesa de calçado em 2025 (valor, volume, mercados).
- Comissão Europeia — Regulamento (UE) 2024/1781 (Ecodesign for Sustainable Products Regulation — ESPR), em vigor desde julho de 2025. Requisitos de rastreabilidade e passaporte digital de produto.
- Autoridade Tributária e Aduaneira (AT) — Decreto-Lei n.º 28/2019, de 15 de fevereiro, e Portaria n.º 195/2020, de 13 de agosto. Obrigações de faturação eletrónica, ATCUD e comunicação SAF-T.
- Parlamento Europeu e Conselho — Diretiva (UE) 2022/2555 (NIS2), transposta para Portugal pelo Decreto-Lei n.º 65/2025. Obrigações de cibersegurança.
Perguntas frequentes
Por que razão um ERP genérico não consegue modelar a grade de tamanhos do calçado?
Um ERP genérico trata o produto como combinação simples de referência, cor e tamanho. No calçado, uma única referência pode ter três eixos simultâneos — número europeu, largura do cabedal e tipo de forro — com disponibilidade diferenciada por eixo. A grade não é linear: o 37 pode existir em três larguras, o 42 em duas. O modelo de dados genérico não consegue estruturar isto nativamente.
Qual é o impacto de uma grade de tamanhos mal modelada no MRP?
Sem a grade nativa, o MRP calcula necessidades de matéria-prima com base em médias de tamanho. Uma coleção com picos de procura no 42 e 43 gera ruturas de couro mesmo com stock "suficiente" no sistema. O responsável de compras descobre o problema quando o cortador pára a linha de produção.
O que é uma coleção no contexto de um ERP para calçado?
A indústria de calçado trabalha por coleções, cada uma com ciclo de vida próprio: desenvolvimento de amostras, aprovação pelo comprador, confirmação de encomendas, produção e expedição. Os compradores internacionais visitam as fábricas duas vezes por ano para avaliar as novas coleções.
Como é que um ERP genérico falha na gestão de coleções?
Um ERP genérico não tem o conceito de coleção como entidade de gestão. Tem apenas ordens de venda e produção, sem a ligação temporal e comercial que o ciclo de coleção exige. O resultado é que o planeamento de capacidade fica fora do sistema e a rastreabilidade das amostras aprovadas é manual.
Qual é o verdadeiro custo de um ERP genérico para o calçado?
O ERP genérico é mais barato no dia da assinatura. Os custos reais — personalizações, folhas de cálculo paralelas, horas de equipa a reconciliar dados, erros de expedição — só aparecem dezoito meses depois e raramente num único centro de custo. É um custo diferido que só se torna visível quando já é tarde para mudar sem dor.
Como é que a regulação ESPR afeta a escolha de ERP?
A regulação europeia de ecodesign (ESPR), em vigor desde julho de 2025, exige rastreabilidade da origem de cada componente — couro, sola, cola, forro, atacadores. Um ERP genérico sem rastreabilidade lote-a-lote nativa não responde a esta exigência sem personalização extensiva.
Por que razão a comparação de preço de licença é enganadora?
O preço de licença é visível na proposta, mas os custos reais de adaptação, manutenção de personalizações e ineficiência operacional acumulada não aparecem em nenhuma proposta. Aparecem nas horas extra do planeamento, nos erros de expedição e nas notas de crédito emitidas porque o sistema não consegue estruturar a realidade do negócio de calçado.
