Lead time real vs prometido: como o DDMRP audita fornecedores

A maior causa única de DDMRP “que não funciona” é simples: lead time cadastrado errado no product.supplierinfo. O método dimensiona buffer com base em DLT (Decoupled Lead Time). DLT é função direta do lead time do fornecedor. Lead time errado, buffer errado.

E lead time cadastrado tende a ser otimista. O comprador pergunta ao fornecedor “em quanto tempo entrega?”, e o fornecedor responde com a melhor hipótese, não com a média real. O que é cadastrado no ERP é o que o fornecedor gostaria de cumprir, não o que ele cumpre na prática.

DDMRP exige distinção entre lead time prometido e lead time real. E exige medir isso continuamente.

O que é lead time real

Lead time real, para fins de DDMRP, é o intervalo medido entre emissão da ordem de compra (data de confirmação no purchase.order) e recebimento da mercadoria (data do stock.move de entrada).

Numa operação Odoo:

lead_time_real = stock_move.date (recebimento) - purchase.order.date_approve

Em alguns casos, a referência muda — quando o fornecedor exige confirmação por planilha, e a data efetiva de “ordem aceita” é diferente da date_approve. Esse detalhe é parte da implantação.

A distribuição importa, não só a média

Lead time não é número único. É distribuição estatística. Um fornecedor pode ter:

• Média de 18 dias
• Mediana de 15 dias
• P90 de 28 dias
• Mínimo de 10 dias, máximo de 45 dias

Qual desses números cadastrar no ERP? A literatura DDMRP é clara: a referência é a média ponderada do que entrega, com a variabilidade absorvida pelo VF (Variability Factor) do buffer profile.

Erro comum: cadastrar P90 “para ser conservador”. Isso infla buffer artificialmente. O caminho correto é cadastrar média realista e usar VF alto se a distribuição é dispersa.

A auditoria semanal de lead time

Em operação madura DDMRP, a auditoria de lead time é trabalho semanal, não pontual. Em SQL ou via relatório Odoo:

Para cada fornecedor + produto:
  lead_time_medido = avg(stock_move.date - purchase.order.date_approve)
                     ao longo dos últimos N entregas (N = 5 a 20)
  lead_time_cadastrado = product.supplierinfo.delay
  desvio = (lead_time_medido - lead_time_cadastrado) / lead_time_cadastrado

Quando o desvio passa de um threshold (tipicamente 20%), o item entra em fila de revisão. O comprador decide:

• Atualizar product.supplierinfo.delay para o valor medido
• Trocar buffer profile para classe de lead time mais alta
• Conversa com o fornecedor para entender (ele tem capacidade ou não tem?)

Como a stack ForgeFlow expõe isso

A camada DDMRP da ForgeFlow (Espanha), em Odoo, tem visualização específica de lead time real vs cadastrado dentro do dashboard Professional. É uma das 13 telas do dashboard.

A tela mostra:

• Fornecedor x SKU
• Lead time cadastrado
• Lead time médio medido (últimas N entregas)
• Distribuição (mínimo, mediana, P90, máximo)
• Tendência (está aumentando ou diminuindo ao longo do tempo)
• Score de pontualidade

Essa tela substitui planilha de KPI de fornecedor. E, mais importante: vira insumo direto da reunião semanal de PCP que o DDMRP cria.

Múltiplas fontes para o mesmo SKU

Quando há mais de um fornecedor para o mesmo SKU (multi-source), o DDMRP precisa decidir qual lead time usar. A prática comum:

• Usar lead time do fornecedor primário para dimensionamento de buffer
• Em compras emergenciais, disparar para fornecedor com lead time menor mesmo se o preço é maior

A camada DDMRP suporta multi-source via product.supplierinfo com sequence. O fornecedor primário é o de menor sequence. Em operação madura, multi-source é discutido em S&OP — qual fornecedor primário, em qual condição troca para alternativo.

Lead time importado: cuidado dobrado

Em operação importadora (ver post sobre importador), lead time tem várias componentes:

• Tempo de produção do fornecedor
• Tempo de booking de container
• Tempo de viagem
• Tempo de desembaraço aduaneiro
• Tempo de transporte interno até o CD

Cada componente tem variabilidade própria. A soma compõe o lead time total — e normalmente o desembaraço é o mais variável (pode ir de 3 dias a 3 semanas, dependendo de canal verde, amarelo, vermelho).

Cadastrar lead time único para item importado é simplificação. Em operação madura, o componente alfandegário é tratado como lead time de risco absorvido por VF alto.

Caso real

Em um cliente brasileiro em Odoo 18, a auditoria de lead time foi parte da implantação DDMRP. Na primeira rodada, 38% dos itens tinham desvio > 30% entre lead time cadastrado e medido. Após correção, o número caiu para < 8% em quatro meses, e os SKUs de fornecedores instáveis foram realocados para buffer profile com VF alto. Ruptura caiu mais de 40% sem aumentar capital.

Stack e papéis

A visualização e auditoria de lead time é parte da camada Professional da ForgeFlow (Espanha). A camada community em OCA expõe os campos base mas não tem a tela consolidada. A KMEE é parceira oficial brasileira para implantação Enterprise — incluindo o trabalho de auditoria inicial e treinamento de comprador.

Leituras relacionadas:

• Glossário DDMRP: ADU, DLT, NFP
• Buffer profile e os 9 fatores
• DDMRP Dashboard 13 módulos
• Serviço DDMRP em Odoo