Pular para o conteúdo
Voltar ao Blog

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.

Luis Felipe Miléo Luis Felipe Miléo Gestão Empresarial 5 min de leitura

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:

  1. Sales orders confirmadas com data de entrega dentro do horizonte
  2. Order spikes: pedidos anormalmente grandes que excedem threshold do buffer (em dias de ADU). Mesmo que cheguem antes do horizonte, são marcados.
  3. 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

Compartilhar

WhatsApp LinkedIn

Sobre o autor

Luis Felipe Miléo

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

Artigos relacionados

Comece por um diagnóstico gratuito

Trinta minutos para entender a sua operação e dizer o que resolver primeiro, na ordem certa. Sem compromisso.