IA aplicada à previsão de procura: do ERP à ordem de compra automática

Numa fábrica de confeção no Vale do Ave com 120 colaboradores, o responsável de compras passa todas as segundas-feiras de manhã a exportar três ficheiros do ERP, a colá-los numa folha de cálculo e a tentar adivinhar o que vai faltar na semana seguinte. Não é falta de tecnologia — o ERP está lá. É falta de ligação entre o que o sistema sabe e o que o comprador decide.

A tese deste artigo é incómoda: o problema não é a ausência de IA nas PME industriais portuguesas. É que, quando a IA chega, aterra num processo de aprovisionamento que não foi desenhado para a receber. A previsão fica num dashboard. A ordem de compra continua a ser escrita à mão. E o ficheiro de Excel das segundas-feiras sobrevive mais um trimestre.

Segundo o INE, em 2025 apenas 9,4% das pequenas empresas portuguesas com 10 a 49 trabalhadores usavam inteligência artificial — e nas médias (50 a 249 trabalhadores) a taxa não chega a 20%. A esmagadora maioria das PME industriais portuguesas ainda não tem nenhuma camada de IA entre o dado histórico e a decisão de compra. A folha de cálculo continua a ser o middleware de facto. O que este artigo explica é como fechar essa lacuna — da previsão à ordem de compra gerada automaticamente — com os trade-offs reais que nenhum vendedor de software apresenta na demo.

O ERP guarda todos os dados que a IA precisaria. O problema é que ninguém os ligou ao motor de decisão.

O problema não é a previsão — é a última milha

A maioria das discussões sobre IA e previsão de procura concentra-se nos modelos: ARIMA, Prophet, redes neuronais, gradient boosting. O problema real das fábricas portuguesas está noutra parte. Está na última milha — o salto entre "o modelo prevê X unidades" e "o ERP emite a ordem de compra".

Vemos isto repetidamente: uma empresa instala um módulo de previsão, o modelo corre, os números aparecem num relatório, e o comprador continua a fazer o que sempre fez porque não confia nos números que não percebe e não tem tempo para os questionar. O modelo não falhou. A integração é que nunca existiu.

Para uma PME industrial portuguesa, o valor da IA na previsão de procura não está no modelo mais sofisticado — está na integração entre o modelo e o fluxo de aprovisionamento já existente no ERP MULTI ou equivalente. Sem essa integração, a previsão é apenas mais um relatório que ninguém lê às segundas-feiras de manhã.

O que mudou para isto ser relevante agora

Dados históricos suficientes e limpos

Uma fábrica têxtil do cluster do Vale do Ave com cinco anos de ERP ativo tem, tipicamente, dezenas de milhares de linhas de movimento de stock, ordens de compra e notas de encomenda de cliente. Esse volume já é suficiente para treinar modelos de série temporal com resultados úteis — não perfeitos, mas superiores à média móvel de 12 semanas que a maioria usa hoje. O limiar mínimo razoável é 24 meses de histórico limpo. Com menos do que isso, o modelo aprende os ruídos, não os padrões.

Infraestrutura cloud acessível

Até há poucos anos, correr um modelo de machine learning exigia infraestrutura dedicada e uma equipa de data science. Hoje, os principais fornecedores de cloud disponibilizam serviços de AutoML que uma equipa de IT de três pessoas consegue operar sem formação especializada. O custo de computação deixou de ser o obstáculo principal. O obstáculo principal passou a ser a qualidade dos dados — e esse é um problema de processo, não de tecnologia.

APIs nativas nos ERPs modernos

O QAD Adaptive ERP expõe APIs REST que permitem injectar previsões calculadas externamente diretamente nas sugestões de aprovisionamento. Isto significa que o modelo de IA não precisa de substituir o ERP — alimenta-o. A ordem de compra continua a ser gerada pelo ERP, com todas as regras de negócio, aprovações e rastreabilidade que já existem. A IA entra como camada de decisão, não como substituto do sistema de registo.

Pressão regulatória e de rastreabilidade

A Estratégia Europeia para os Têxteis Sustentáveis e Circulares exige rastreabilidade de materiais ao longo da cadeia de valor. Uma ordem de compra gerada automaticamente por IA tem de ser auditável — quem aprovou, com base em que previsão, com que dados de entrada. O AI Act (Regulamento UE 2024/1689), em vigor desde agosto de 2024, classifica os sistemas de IA que influenciam decisões de aprovisionamento em contexto industrial e exige documentação do raciocínio do modelo. Não é um requisito opcional: é conformidade que tem de estar desenhada na arquitetura desde o início, não acrescentada depois.

As opções técnicas reais

Abordagem 1 — Módulo nativo do ERP

Alguns ERPs verticais incluem módulos de previsão estatística baseados em séries temporais simples: média móvel ponderada, suavização exponencial. Não é IA no sentido estrito, mas para produtos com procura estável e sazonalidade previsível — fio de algodão em fiação, componentes de sola em calçado, embalagem standard em distribuição alimentar — funciona razoavelmente bem. A vantagem é zero integração adicional. A desvantagem é estrutural: o modelo não aprende com variáveis externas. Uma campanha de vendas, um atraso do fornecedor, um pico de procura por evento sazonal — nada disso entra no cálculo. O modelo é cego ao contexto.

Abordagem 2 — Camada de BI com modelos preditivos

Ferramentas de BI como o Qlik Sense permitem incorporar scripts de previsão em R ou Python diretamente nos dashboards. O analista vê a previsão ao lado dos KPIs operacionais e decide manualmente se converte em sugestão de compra. É uma abordagem de meio-caminho: mais sofisticada que o módulo nativo, mas com intervenção humana obrigatória na última milha. O risco é que "intervenção humana obrigatória" se torne, na prática, "ninguém tem tempo para isto e a sugestão fica no dashboard para sempre".

Abordagem 3 — Pipeline de IA externo com integração via API

O modelo corre fora do ERP — cloud própria, Azure ML, AWS SageMaker ou similar — consome dados via ETL do ERP, gera previsões e devolve sugestões de aprovisionamento diretamente ao módulo de compras. A ordem de compra é criada automaticamente quando a previsão supera o ponto de reorder e o fornecedor preferencial está ativo. É a única abordagem que elimina o ficheiro de Excel das segundas-feiras. Requer integração técnica consistente e um parceiro que conheça tanto o modelo como o ERP — a falha mais comum é construir um pipeline excelente que ninguém na empresa consegue manter seis meses depois da implementação.

Abordagem 4 — Plataforma de demand planning especializada

Soluções dedicadas de demand planning integradas com o ERP via conectores standard oferecem modelos mais sofisticados, incluindo incorporação de dados externos: meteorologia, tendências de pesquisa, calendário de feiras. Para empresas de calçado em Felgueiras com 800 a 1 200 SKUs e três eixos de variação — cor, tamanho, forma — esta é frequentemente a única abordagem que modela a complexidade real. Os compradores internacionais visitam duas vezes por ano e as janelas de encomenda são curtas. Um erro de previsão numa coleção de calçado de senhora em Fevereiro não se corrige até Agosto. O custo de licença e implementação é correspondentemente mais elevado, mas o custo de uma coleção mal aprovisionada também o é.

Trade-offs por dimensão de empresa

Menos de 50 colaboradores: o módulo nativo do ERP é, na maioria dos casos, a resposta correta. Não porque seja o melhor modelo — não é. Mas porque a equipa de IT não tem capacidade para manter um pipeline externo, e o custo de oportunidade de uma implementação de 20 semanas é demasiado alto relativamente ao volume de compras em jogo. Comece pela análise ABC dos artigos comprados: os 20% de referências que representam 80% do valor de compra são os únicos que justificam previsão sofisticada. Os restantes 80% de referências podem continuar com stock de segurança fixo e revisão mensal — e isso está correto.

Entre 50 e 200 colaboradores, a abordagem de BI com modelos preditivos tem melhor retorno. A empresa já tem volume de dados suficiente, já tem alguém que usa o BI regularmente, e o salto para modelos de série temporal com sazonalidade não exige um data scientist a tempo inteiro. O risco principal não é técnico — é a fadiga de manutenção. O modelo precisa de ser re-treinado periodicamente, e isso tem de estar no calendário de alguém com nome e responsabilidade. Quando não está, o modelo fica desactualizado em silêncio e as previsões degradam-se sem que ninguém perceba porquê.

Acima de 200 colaboradores ou com alta complexidade de SKU, o pipeline externo com integração via API ou a plataforma especializada são as únicas opções que escalam. Uma empresa de distribuição alimentar no corredor Lousada-Paços de Ferreira com 30 000 referências ativas e prazos de entrega variáveis não consegue gerir previsão item-a-item por série temporal simples de forma operacionalmente útil — o modelo não captura as promoções do cliente, as ruturas do fornecedor nem os efeitos de substituição entre SKUs. Precisa de um modelo que aprenda relações entre artigos, não apenas o histórico de cada um isoladamente.

Numa empresa com 800 SKUs ativos, o erro de previsão médio não é o problema. O problema é o erro nos 40 artigos que representam 60% da margem.

A arquitetura de dados que ninguém desenha antes de começar

Qualquer modelo de previsão de procura precisa, no mínimo, de cinco tipos de dados: histórico de vendas ou consumo por artigo e por período sem lacunas por ruturas de stock; calendário de promoções e campanhas passadas com datas exatas; prazos de entrega reais por fornecedor e por artigo — não o prazo contratual, o prazo efetivo registado nas entradas de armazém; stocks de segurança atuais e a lógica que os originou; e dados de sazonalidade específicos do setor, que para calçado significa o calendário de feiras internacionais, para têxtil as campanhas de moda, e para distribuição alimentar o calendário de festividades e promoções de cadeia.

O problema que encontramos repetidamente: o ERP tem os dados de vendas, mas os prazos de entrega reais estão numa folha de cálculo do comprador. As promoções estão num email de há três meses. As ruturas históricas não estão marcadas — aparecem como zeros que o modelo vai interpretar como ausência de procura, quando na realidade eram semanas em que a procura existia mas o stock não. Um modelo sofisticado alimentado com dados sujos produz previsões piores do que uma média móvel simples com dados limpos. Audite a qualidade dos dados antes de escolher o modelo.

O pipeline de preparação de dados tem uma sequência que raramente é respeitada. Primeiro, extraia o histórico de movimentos de stock dos últimos 36 meses do ERP — não as vendas faturadas, os movimentos reais de saída de armazém. Segundo, identifique e marque os períodos de rutura: stock zero com procura pendente. Substitua esses zeros por estimativas de procura não satisfeita, calculadas a partir das encomendas em atraso registadas no ERP. Terceiro, enriqueça com o calendário de promoções, feriados e eventos setoriais relevantes. Quarto, valide os prazos de entrega efetivos por fornecedor calculados a partir das datas de encomenda e de entrada em armazém — os prazos contratuais são ficção útil para negociação, não para planeamento. Quinto, defina a granularidade temporal: semana é o mínimo útil para a maioria dos setores industriais; mês é demasiado grosseiro para distribuição com rotação alta.

Da previsão à ordem de compra: o fluxo de aprovação

Automação total vs. automação assistida

A ordem de compra totalmente automática — sem aprovação humana — é tecnicamente possível. Na prática, é imprudente para a maioria das PME industriais portuguesas. O modelo não conhece a negociação em curso com o fornecedor: o comprador pode estar a renegociar preço e uma OC automática compromete a posição negocial antes do momento certo. O modelo não detecta anomalias de qualidade recentes: uma reclamação aberta sobre o último lote não está, tipicamente, no feed de dados do modelo. E o AI Act, para decisões com impacto financeiro significativo, recomenda fortemente supervisão humana documentada — não como burocracia, mas como mecanismo de correção quando o modelo erra.

A abordagem correta para a maioria das empresas é a automação assistida: o modelo gera sugestões de aprovisionamento com quantidade, fornecedor e prazo; o comprador aprova, ajusta ou rejeita com um clique; o ERP emite a OC. O tempo de decisão cai de horas para minutos. A responsabilidade permanece humana. A rastreabilidade está garantida. O comprador deixa de construir a sugestão e passa a validá-la — o que é uma mudança de papel substancial que tem de ser gerida, não apenas anunciada.

Limiares de confiança e escalada automática

Configure o sistema com limiares de confiança explícitos. Quando o modelo tem alta confiança na previsão — desvio histórico baixo, artigo com procura estável, fornecedor com prazo consistente — a sugestão vai diretamente ao comprador para aprovação rápida. Quando a confiança é baixa — artigo novo, sazonalidade irregular, fornecedor com histórico de atrasos — a sugestão escala para revisão manual com os dados de suporte visíveis no ecrã. Não trate todas as sugestões da mesma forma. É exatamente isso que os ERPs genéricos fazem, e é por isso que os compradores aprendem a ignorar as sugestões ao fim de três meses.

Um sistema de aprovisionamento automático que gera 200 sugestões por semana com a mesma prioridade visual é um sistema que o comprador vai aprender a ignorar em três meses.

Matriz de decisão: qual abordagem para o seu contexto

O que funciona na prática

Começar pelo artigo certo, não pelo modelo certo

Uma fábrica de calçado em Felgueiras com 900 SKUs ativos poderia, em teoria, aplicar previsão de IA a toda a gama. O ganho concentra-se nos 80 a 120 artigos de fundo de gama com procura estável — os componentes de sola, os atacadores standard, os forros de uso corrente. São estes que geram as ruturas mais caras e os excessos de stock mais persistentes, precisamente porque ninguém lhes presta atenção: são artigos sem glamour, sem urgência aparente, até ao dia em que param a linha. Começar por estes artigos, com um modelo simples mas bem alimentado, produz resultados visíveis em dois a três meses. Expandir depois para artigos de moda, com sazonalidade agressiva e janelas de encomenda curtas, é um segundo projecto — com as aprendizagens do primeiro já incorporadas na equipa.

O comprador como validador, não como operador

Nas implementações que funcionam, o papel do comprador muda de forma concreta: deixa de construir a sugestão de compra e passa a validar a sugestão do sistema. Isto só resulta se o sistema mostrar, junto a cada sugestão, os dados que a suportam — histórico de consumo, prazo de entrega previsto, stock atual, stock de segurança, e o intervalo de confiança da previsão. Sem estes dados visíveis no mesmo ecrã, o comprador não tem base para discordar do modelo. Ou aprova tudo cegamente, ou rejeita tudo por desconfiança. Ambos os comportamentos anulam o valor do sistema. A KORA Inventory Suite permite que esta informação de contexto seja apresentada diretamente no fluxo de aprovação, sem obrigar o comprador a navegar para outro ecrã ou abrir outro sistema.

A força de vendas como fonte de sinal antecipado

O modelo de IA aprende com o passado. O vendedor sabe o que vai acontecer nas próximas quatro semanas. É um desfasamento estrutural que os manuais de demand planning raramente abordam. Uma empresa de distribuição no corredor Lousada-Paços poderia integrar as notas de visita da força de vendas — registadas via KORA Sales Suite — como variável de entrada no modelo. Quando o vendedor regista que um cliente vai lançar uma promoção em Março, esse sinal pode ajustar a previsão de procura antes de o histórico o reflectir. É exatamente o tipo de conhecimento tácito que as fábricas portuguesas têm em abundância — e que raramente está digitalizado. Capturá-lo não exige um modelo mais sofisticado. Exige um processo de registo que o vendedor efetivamente use.

Conformidade e rastreabilidade: o que documentar

AI Act e decisões de aprovisionamento

O Regulamento (UE) 2024/1689 classifica os sistemas de IA por nível de risco. Um sistema que gera ordens de compra automaticamente não é, em geral, classificado como alto risco — essa categoria reserva-se para IA em contextos críticos como saúde, segurança pública ou emprego. Mas exige documentação mínima: descrição do modelo, dados de treino utilizados, lógica de decisão, mecanismo de supervisão humana, e registo das decisões tomadas. Guarde esta documentação no sistema de Gestão Documental com versionamento. O auditor vai pedi-la — e pedi-la no momento menos conveniente.

NIS2 e a cadeia de aprovisionamento digital

A Diretiva NIS2, transposta para Portugal pelo DL 65/2025, impõe requisitos de cibersegurança às entidades essenciais e importantes, incluindo a segurança da cadeia de abastecimento digital. Um pipeline de IA que comunica com o ERP via API é um vector de ataque potencial que muitas empresas não consideram quando desenham a arquitetura. Audite as permissões de acesso ao ERP que o pipeline utiliza, implemente autenticação por token com rotação periódica, e registe todos os acessos. Consulte a política de cibersegurança aplicável à sua infraestrutura antes de expor o ERP a integrações externas.

SAF-T e rastreabilidade das ordens de compra

As ordens de compra geradas automaticamente têm de ser rastreáveis no SAF-T (Portaria 195/2020). Verifique que o ERP gera o campo de origem da OC de forma que permita distinguir ordens manuais de ordens geradas por sugestão automática. Isto não é apenas boa prática — é o que permite ao auditor fiscal e ao auditor de qualidade perceber o racional por detrás de cada compra. Descobrir que o campo não existe depois de seis meses de OCs automáticas é um problema de reconciliação que consome semanas.

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

Quatro métricas operacionais definem se o sistema está a funcionar. O MAPE — erro médio absoluto da previsão por artigo — é o indicador base: para artigos de fundo de gama com procura estável, um valor abaixo de 15% é razoável; acima de 30%, o modelo não está a acrescentar valor face à média histórica simples. A taxa de rutura — percentagem de dias com stock zero para artigos com procura ativa — deve baixar 30 a 50% nos artigos cobertos pelo modelo no primeiro ano; se não baixar, o modelo está a prever mas não está a influenciar as compras. A rotação de stock deve aumentar 10 a 20% nos artigos geridos pelo modelo: se a previsão é boa, o stock de segurança pode ser reduzido sem aumentar ruturas. E o tempo de ciclo de aprovação de OC — o tempo médio entre a sugestão do sistema e a emissão da OC — tem de baixar face ao processo manual; se não baixar, o workflow de aprovação não está a funcionar e o comprador está a fazer o mesmo trabalho de antes com um passo adicional.

Re-treine o modelo pelo menos trimestralmente. Compare o MAPE do modelo atual com o do modelo anterior. Se a qualidade não melhora com mais dados, o problema não é o volume de histórico — é a qualidade dos dados ou a escolha do modelo. Não invista em mais computação antes de resolver a qualidade dos dados. É um erro caro e frequente.

Para aprofundar a lógica de integração entre sistemas de chão-de-fábrica e ERP, o artigo sobre MES sem integração ERP: o custo oculto que o COO não vê desenvolve os riscos de decisão com dados fragmentados. Para a dimensão de governance e documentação do modelo de IA, o artigo Governance de IA em PME industrial: o que documentar antes do AI Act é o passo seguinte natural. E se o tema é a automação mais ampla dos processos industriais, Automação de processos industriais: onde a IA começa a pagar contextualiza onde a previsão de procura se encaixa na maturidade digital da fábrica.

O Just-in-Time foi durante décadas o ideal do aprovisionamento industrial. A IA não o substitui — torna-o finalmente praticável para empresas que não têm a estabilidade de procura da Toyota. A diferença entre uma previsão que fica num dashboard e uma previsão que gera uma ordem de compra é, quase sempre, uma decisão de arquitetura que se toma no início do projecto. Tomá-la tarde não é apenas mais caro. É mais caro e mais difícil de desfazer.

Fontes

• INE — Inquérito à Utilização de Tecnologias da Informação e da Comunicação nas Empresas, 2025. Disponível em ine.pt
• Eurostat — ICT usage in enterprises: Artificial Intelligence, 2025. Disponível em ec.europa.eu/eurostat
• Regulamento (UE) 2024/1689 do Parlamento Europeu e do Conselho (AI Act), publicado no Jornal Oficial da UE em 12 de julho de 2024. Disponível em eur-lex.europa.eu
• Diretiva (UE) 2022/2555 (NIS2), transposta para Portugal pelo Decreto-Lei 65/2025. Disponível em eur-lex.europa.eu e dre.pt
• Portaria 195/2020 — comunicação SAF-T mensal à Autoridade Tributária e Aduaneira. Disponível em dre.pt
• Comissão Europeia — EU Strategy for Sustainable and Circular Textiles, COM(2022) 141 final. Disponível em ec.europa.eu

Perguntas frequentes

O que é a "última milha" na previsão de procura com IA?

É o salto entre o modelo de IA prever uma quantidade e a ordem de compra ser automaticamente emitida no ERP. Muitas empresas instalam previsão, mas o comprador continua a ignorar os números porque não confia ou não tem tempo. A integração entre previsão e decisão de compra nunca foi feita, tornando o modelo inútil na prática.

Por que razão as PME portuguesas ainda usam folhas de cálculo para compras?

O ERP já contém todos os dados necessários, mas ninguém os ligou ao motor de decisão. O processo de aprovisionamento não foi desenhado para receber IA. Assim, o comprador continua a exportar ficheiros manualmente todas as semanas porque é o fluxo que conhece e controla, mesmo que seja ineficiente.

Que volume de histórico de dados é necessário para treinar um modelo de previsão?

O limiar mínimo razoável é 24 meses de histórico limpo. Uma fábrica com cinco anos de ERP ativo tem tipicamente dezenas de milhares de linhas de movimento de stock, o que é suficiente para treinar modelos de série temporal com resultados úteis, superiores à média móvel tradicional.

A IA pode substituir completamente o ERP na geração de ordens de compra?

Não. A IA entra como camada de decisão, não como substituto. O modelo calcula a previsão externamente e alimenta o ERP via API. A ordem de compra continua a ser gerada pelo ERP, mantendo todas as regras de negócio, aprovações e rastreabilidade já existentes no sistema.

Qual é a diferença entre usar o módulo nativo do ERP e uma camada de IA externa?

O módulo nativo (média móvel, suavização exponencial) funciona bem para procura estável e sazonalidade previsível, mas é cego ao contexto externo. Uma camada externa de IA consegue incorporar variáveis como campanhas de vendas, atrasos de fornecedores ou eventos sazonais, oferecendo previsões mais sofisticadas e adaptáveis.

O AI Act europeu obriga a mudanças no design da IA para compras?

Sim. O Regulamento UE 2024/1689 classifica sistemas de IA que influenciam decisões de aprovisionamento industrial como de risco e exige documentação do raciocínio do modelo. A auditabilidade — quem aprovou, com que dados, com base em que previsão — tem de estar desenhada na arquitetura desde o início, não acrescentada depois.

Qual é o obstáculo principal para implementar IA em PME portuguesas: tecnologia ou dados?

Já não é a tecnologia. A infraestrutura cloud e os serviços de AutoML são acessíveis e operáveis por equipas pequenas de IT. O obstáculo principal é a qualidade dos dados e a integração com processos existentes — problemas de processo, não de tecnologia.