Order Spike: como o DDMRP detecta picos de demanda concentrada

Imagine um SKU com ADU de 100 un/dia, lead time de 10 dias, buffer dimensionado para essa cadência. Tudo verde. De repente, entra um pedido de 3.000 unidades com entrega para daqui a 5 dias. Esse pedido não é representado no buffer — ele é grande demais e concentrado demais para ser absorvido pela zona vermelha. Sem tratamento especial, o ERP só vai “perceber” a falta quando a NFP despencar para o vermelho — provavelmente tarde para reagir dentro do lead time.

A resposta DDMRP para esse caso é Order Spike Detection. Este post abre como ela funciona no stock.buffer em Odoo (na stack publicada pela ForgeFlow nos repositórios OCA — KMEE é parceira oficial brasileira para implementação).

O problema que Spike resolve

Buffers DDMRP são dimensionados para demanda média + variabilidade estatística rotineira. Eles não são dimensionados para eventos atípicos concentrados. Se eu inflasse a Red Zone para cobrir o pior pedido possível, imobilizaria capital o ano todo para um evento raro.

A elegância do DDMRP é separar:

• Demanda regular → absorvida pelo dimensionamento das zonas
• Spikes ocasionais → tratados pontualmente, antecipando reposição

Spikes não mudam o tamanho do buffer. Eles mudam a NFP do dia ao serem qualificados na demanda — e portanto antecipam a geração de ordem.

Os dois parâmetros: horizon e threshold

Order Spike Horizon

Janela de dias à frente em que o sistema procura picos de demanda. Tipicamente:

• Igual ao DLT do buffer (recomendação clássica do DDI)
• Ou um pouco maior (1× a 1,5× DLT) em ambientes muito voláteis

Lógica: não adianta procurar spike daqui a 90 dias se meu lead time é 10 dias — quando ele se aproximar, eu já reagi pelo fluxo normal. E não adianta olhar só amanhã — não sobra tempo de reposição.

No Odoo: campo order_spike_horizon em stock.buffer (em dias).

Order Spike Threshold

Patamar a partir do qual uma demanda diária é considerada spike. Pode ser expresso como:

• Percentual da Red Zone (típico: 50% da Red Zone)
• Quantidade absoluta
• Múltiplo do ADU diário

A escolha mais comum é % da Red Zone, porque cresce/encolhe junto com o dimensionamento do buffer. Em buffer com Red Zone = 850, threshold de 50% significa: qualquer dia no horizonte com demanda > 425 un dispara spike.

No Odoo: campo order_spike_threshold em stock.buffer.

Como spike afeta NFP

Quando o cálculo de qualified demand roda:

1. Para cada dia D dentro do order_spike_horizon:
   • Soma a demanda firme com data igual a D (sale orders, transferências de saída, consumos planejados)
   • Se essa soma > order_spike_threshold, a parcela acima do threshold entra na qualified demand
2. A demanda do dia atual / horizonte muito curto entra integralmente (já é “iminente”)
3. NFP = on-hand + on-order − qualified demand (incluindo spikes qualificados)

Resultado: NFP cai antes do pico chegar, gerando recomendação de reposição com tempo hábil.

Exemplo numérico

Buffer com:

• ADU = 100 un/dia
• Red Zone = 850, ToR = 850
• Yellow = 1.000, ToY = 1.850
• Green = 500, ToG = 2.350
• DLT = 10 dias
• order_spike_horizon = 10
• order_spike_threshold = 50% da Red Zone = 425

Pipeline de demanda dos próximos 10 dias:

Dia	Demanda firme
D+1	80
D+2	120
D+3	90
D+4	100
D+5	3.000
D+6	80
D+7	110
D+8	90
D+9	100
D+10	100

Detecção de spike: o único dia que ultrapassa 425 é D+5 (3.000 > 425). A parcela qualificada como spike é 3.000 − 425 = 2.575. Esse valor entra na qualified demand (além da demanda regular do horizonte).

Se on-hand = 1.500 e on-order = 1.000:

• Sem spike: NFP ≈ 1.500 + 1.000 − ~430 (demanda regular ~10 dias × parte fracionada) → NFP fica em VERDE/AMARELO
• Com spike qualificado: NFP cai 2.575 a mais → vai pra VERMELHO ou negativo → sistema gera procurement urgente

Sem o mecanismo de spike, o ERP só veria o problema quando D+5 chegasse — e aí o lead time já não cobre.

Calibragem na prática

Threshold muito baixo

• Detecta “tudo” como spike
• Gera ordens em excesso, infla on-order
• Buffer fica permanentemente verde/sobrestocado
• Sintoma: cobertura crescendo mês a mês sem motivo

Threshold muito alto

• Quase nada vira spike
• Volta a faltar capacidade de reação a picos
• Sintoma: rupturas atribuídas a “pedidos grandes que apareceram do nada”

A regra do DDI (50% da Red Zone) é um bom ponto de partida. Em projetos com SKUs muito heterogêneos, vale calibrar por profile (não SKU a SKU) com base em histórico de spikes observados.

Horizon muito curto

• Spike é detectado tarde demais para reagir
• Equivale a “desligar” a função

Horizon muito longo

• Spike longe vira ordem hoje
• Antecipa pedido sem necessidade
• Inflaciona on-order desnecessariamente

Spike vs DAF: quando usar cada um

Confusão comum: “se eu sei que dezembro vai vender mais, uso spike?”. Não. Sazonalidade conhecida e recorrente é caso de DAF (Demand Adjustment Factor) — multiplicador planejado em janela de datas que infla ADU e portanto as zonas. As zonas crescem antes do mês, criando pipeline com tempo.

Spike é para eventos não-recorrentes não-planejados que aparecem como pedido firme: licitação ganha, distribuidor que pediu volume extra, evento corporativo. O sistema descobre o pedido no calendário e reage.

Situação	Mecanismo
Sazonalidade recorrente conhecida	DAF
Promoção planejada com data	DAF (curto) ou ZAF
Pedido grande aparecendo no pipeline	Order Spike
Cliente novo entrando	Revisão de ADU + monitorar via Spike

Implementação em produção

Em projeto FFA (distribuidor brasileiro em Odoo 18), o ajuste de spike foi feito em três fases:

1. Fase 1 (90 dias): spike desligado para todos os buffers; foco em estabilizar ADU e zonas
2. Fase 2: ativar spike com threshold 50% da Red Zone e horizon = DLT, em SKUs A
3. Fase 3: estender para SKUs B e calibrar threshold por profile com base em histórico de spikes detectados versus rupturas evitadas

Pular fase 1 é tentador mas custoso: spike sem zonas calibradas amplifica ruído.

Onde Spike fica nos campos do stock.buffer

Resumo dos campos relevantes na stack ForgeFlow:

• order_spike_horizon — janela em dias
• order_spike_threshold — patamar (configuração permite % de zona ou unidade absoluta dependendo da versão)
• qualified_demand — campo que acumula demanda firme + spikes qualificados
• net_flow_position — usa qualified_demand como subtraendo

Esses campos são todos recalculados pelo cron de NFP descrito no post anterior.

Encerramento da série

Esses 8 posts cobriram a fundação conceitual do DDMRP (Série A) e a mecânica do stock.buffer em Odoo (Série B). Para indo mais fundo:

• DDMRP em 5 minutos
• MRP tradicional vs DDMRP
• Buffer em 3 zonas
• Glossário ADU/DLT/NFP
• Cálculo de ADU no stock.buffer
• 9 fatores de dimensionamento
• NFP no Odoo

KMEE é parceira oficial brasileira para implementação de DDMRP Enterprise sobre a stack publicada pela ForgeFlow (autora do código nos repositórios OCA). Cliente em produção: FFA em Odoo 18. Fale com a KMEE ou conheça o serviço de DDMRP em Odoo.