Alertas projetados de stock-out: o radar forward-looking do DDMRP
MRP olha o passado. DDMRP olha à frente. Veja como o alerta projetado de stock-out (implementado pela camada ForgeFlow no Odoo) antecipa rupturas em dias.
A maior parte dos ERPs mostra estoque atual. Alguns mostram a evolução prevista do estoque (estoque projetado), em geral somando saldo + entradas previstas - saídas previstas. Esse cálculo é útil, mas tem um problema: ele se baseia em previsão de demanda, herdando todo o erro da previsão.
O DDMRP olha para o futuro de outra forma. Em vez de usar previsão para projetar estoque, usa buffer dinâmico + ADU ou demanda em carteira (movimentos de saída em aberto) para gerar alerta projetado de stock-out: a indicação de em qual dia futuro o on-hand entra em vermelho, dado o consumo médio real ou o que já é fato (pedidos), não o que se espera (previsão).
A diferença entre estoque projetado e alerta projetado
Estoque projetado tradicional
Um cálculo típico em ERP convencional:
Saldo D+0 = on-hand atual
Saldo D+n = Saldo D+(n-1) + Entradas previstas em D+n - Demanda prevista em D+n
A fragilidade está em Demanda prevista em D+n. Se a previsão errou, o saldo projetado erra também.
Alerta projetado DDMRP
Para alertar, o módulo ddmrp_alert projeta o on-hand dia a dia, de hoje até o fim do DLT do buffer, e escolhe a demanda diária pelo campo alert_projected_method do buffer profile, no lugar da previsão:
Demanda D+n = ADU # adu (padrão) e adu_recover
ou saídas em aberto com data D+n # demand (dentro do order_spike_horizon)
E compara com o Top of Red do buffer:
On-hand inicial D+0 = on-hand não reservado
On-hand final D+n = on-hand inicial D+n
+ recebimentos de compra/produção com data D+n
- demanda D+n
On-hand inicial D+n+1 = on-hand final D+n
if onhand_inicial(D+n) <= Top_of_Red: alerta amarelo
if onhand_inicial(D+n) <= 0.5 * Top_of_Red: alerta vermelho
if onhand_inicial(D+n) < 0: stock-out projetado (vermelho escuro)
A diferença é estrutural: alerta DDMRP não pode dar alarme falso por previsão errada, porque não usa previsão. Ele pode dar alarme falso por dado errado (lead time mal cadastrado, MOQ ignorado), o que é diagnosticável.
O que entra em “demanda qualificada”
A literatura DDMRP (Ptak/Smith) define três fontes:
- Sales orders confirmadas com data de entrega dentro do horizonte
- Order spikes: pedidos anormalmente grandes que excedem threshold do buffer (em dias de ADU). Mesmo que cheguem antes do horizonte, são marcados.
- Transfers internos confirmados: em operação multi-warehouse
No ddmrp_alert, a demanda qualificada só entra no alerta projetado quando o profile usa o método demand. No método padrão (adu), o ADU é a demanda de cada dia projetado.
Por que isso muda o jogo de PCP
Sem alerta projetado, PCP vive em modo reativo:
- Estoque acabou hoje -> corre atrás
- Estoque vai acabar amanhã -> reativo de novo
- Visibilidade futura é planilha + intuição
Com alerta projetado, PCP vive em modo proativo:
- Hoje, vê que SKU X vai ficar em vermelho daqui a 9 dias
- Tem 9 dias para acionar fornecedor, antecipar produção, ou avisar comercial
- Decisão acontece no campo certo, com tempo
O que muda é a natureza do trabalho do PCP.
Como o módulo ForgeFlow expõe isso
A camada Professional da ForgeFlow entrega o alerta projetado em duas formas:
1. Lista priorizada de exceções
Tela mostra todos os SKUs com alerta projetado dentro do DLT de cada buffer, com o alerta mais urgente de cada um (data e % on-hand/TOR) e filtros de stock-out e alerta vermelho projetados. É a fila de trabalho do comprador.
2. Drill-down por SKU
Para cada SKU, os registros dia a dia mostram a evolução projetada do on-hand ao longo do horizonte (inicial e final, em lista, calendário ou pivot por semana), com o status do dia em que cai abaixo do Top of Red, de 50% do Top of Red e de zero. Permite entender por que o alerta foi gerado (qual pedido grande, qual ordem não chega a tempo).
Essa visualização é parte do dashboard de 13 módulos.
Limitações honestas
O alerta projetado não substitui S&OP nem previsão de demanda em todos os horizontes. Ele resolve o horizonte operacional (dias a poucas semanas). Para horizonte tático (compra de matéria-prima de longo lead time, contrato com fornecedor) e estratégico (capacidade de fábrica, expansão), a previsão continua sendo necessária, só que como insumo de S&OP, não como gatilho de ordem.
Outra limitação: o alerta é tão bom quanto os dados de pedido firme. Se o ERP não tem disciplina de criar sale.order no momento certo (fica em cotação, fica como pré-venda informal), o alerta atrasa. Na implantação, a KMEE trabalha o gap de processo de vendas junto com o de PCP.
Caso real
Em um cliente brasileiro em Odoo 18, o alerta projetado virou ferramenta principal de compras na semana 3 de operação. Em um caso típico documentado: um pedido grande de cliente B2B cairia em estoque dia 12; o alerta apareceu dia 4; comprador antecipou ordem com fornecedor em dia 5; entrega chegou dia 11; buffer não entrou em vermelho. Sem o alerta, esse pedido geraria ruptura, atraso de entrega e ligação do cliente.
Stack e papéis
O alerta projetado de stock-out, na forma de tela operacional priorizada, é parte do dashboard da camada Professional da ForgeFlow (Espanha). A camada community open source em OCA tem o alerta de on-hand atual (execution_priority_level), mas o cálculo projetado, a tela priorizada e o drill-down estão na camada Enterprise. A KMEE é parceira oficial brasileira para implantação.
Leituras relacionadas:
- #ddmrp
- #pcp
Sobre o autor
Luis Felipe Miléo
CEO e sócio-fundador · KMEE
Sócio-fundador da KMEE e PSC da Odoo Community Association. Mantém com o seu time a localização fiscal brasileira do Odoo (l10n-brazil) e outros módulos da OCA desde 2012. Certificado Demand Driven Planner, escreve sobre ERP, open source, fiscal e IA aplicada às operações.
Ver perfil no LinkedIn