Os 7 erros comuns ao implantar DDMRP que a KMEE viu na prática

Implantar DDMRP em Odoo no Brasil é projeto técnico em uma camada e projeto de mudança de prática em outra. Quando trava, raramente trava por bug de software ou limite da metodologia. Trava por uns poucos erros recorrentes que a KMEE, como parceira oficial brasileira da ForgeFlow (Espanha) para implantação Enterprise, viu se repetir em projetos diferentes.

Este post lista os sete que aparecem com mais frequência. Não é exaustivo, mas cobre o que mais machuca.

Erro 1: Lead time cadastrado incorreto

O erro mais comum, de longe. O método dimensiona buffer com base em DLT (Decoupled Lead Time). DLT depende do lead time cadastrado em product.supplierinfo. Lead time errado, buffer errado, ruptura sem fim.

E lead time tende a estar otimista no ERP — vem da promessa do fornecedor, não da medição da entrega. Em projetos que auditamos na primeira rodada, é comum encontrar 30-40% dos itens com desvio acima de 20% entre cadastrado e medido.

Como evitar: auditoria de lead time real vs cadastrado é etapa obrigatória da implantação, antes de ligar o método. Detalhe completo no post sobre auditoria de lead time.

Erro 2: Bufferizar todo SKU

Equipe de PCP, com medo de ruptura, decide bufferizar todo o catálogo. “Por via das dúvidas”. Resultado: capital de giro empatado em itens C que não justificam buffer, e o método perde poder de discriminação.

DDMRP assume que parte do catálogo é non-stocked (make-to-order, fluxo). Posicionamento estratégico de buffers é decisão de negócio, não cobertor.

Como evitar: segmentação inicial em A/B/C com regra clara — só itens A e B bufferizados em rodada 1. C entra depois, seletivamente, baseado em padrão de pedido.

Erro 3: Pular o paralelo controlado

Pressão executiva por “ligar logo” leva ao desligamento prematuro do MRP antigo. O time fica sem rede de segurança em uma metodologia ainda não calibrada. Primeira ruptura, perda de confiança. Time volta a abrir planilha em paralelo. Implantação morre por desuso.

Como evitar: fase de paralelo (Odoo + DDMRP em shadow mode comparando com ERP atual) é não-negociável. Tipicamente 8-12 semanas em manufatura. Nessa fase se descobrem buffer profiles errados, lead times mentirosos, BOMs com erro.

Erro 4: Ignorar period censoring na primeira rodada

Cliente vinha de operação com ruptura recorrente. ADU calculada sobre histórico cru fica artificialmente baixa. Buffer dimensionado fica pequeno. Ruptura continua. ADU continua subestimada. Loop fechado.

Na implantação, é comum encontrar 10-15% dos SKUs com ADU subestimado por mais de 25% por causa de histórico de ruptura.

Como evitar: period censoring é etapa obrigatória da implantação — não opcional, não “deixar pra depois”.

Erro 5: Manter a reunião semanal antiga

Cliente implanta DDMRP corretamente, mas mantém a reunião de PCP no formato velho — onde o time discute SKU específico em ruptura. A pauta vira teatro: a informação já está no dashboard, mas a reunião continua.

Pior: o tempo gasto na reunião é o tempo que não se gasta no fluxo (atacando vermelho diariamente no dashboard). E o método é percebido como “não substituiu nada”.

Como evitar: redesenho explícito da rotina de PCP é parte da implantação. A reunião muda: pauta vira buffer profile, decoupling, KPIs, exceção real. Detalhe completo no post sobre reuniões de PCP.

Erro 6: Não recalibrar trimestralmente

Implantação termina, time sai do projeto, ninguém revisa buffer profiles por seis meses. Mercado muda, mix muda, fornecedor muda. O método continua operando, mas com profile cada vez mais defasado. Aos poucos, vão aparecendo SKUs em vermelho persistente ou em verde permanente — sinal de que o profile precisa recalibrar.

A camada Professional da ForgeFlow tem simulation multi-level exatamente para que recalibragem seja segura. Se ninguém usa, o método envelhece.

Como evitar: revisão trimestral de buffer profiles e KPIs DDMRP entra na agenda fixa de PCP. Idealmente liderada por quem participou da implantação inicial.

Erro 7: Tratar DDMRP como projeto de TI, não de operação

Implantação patrocinada por TI (“vamos trocar de ferramenta de planejamento”), sem patrocínio operacional do diretor industrial ou diretor de supply. TI entrega a ferramenta. Time operacional não usa, ou usa parcialmente. Resultado: stack instalada, dashboard zerado, MRP antigo continua sendo a ferramenta real.

DDMRP é mudança de modelo de operação, não troca de software. Sem patrocínio do dono da operação, falha.

Como evitar: o sponsor do projeto precisa ser o líder de PCP/supply, não o líder de TI. TI é parceiro de implantação. KMEE, em projetos de implantação, exige sponsor operacional explícito antes de iniciar.

O que NÃO entrou nesta lista

Por escolha — para manter as 7 mais críticas:

• Cadastro de produto duplicado no ERP origem (resolve antes da migração)
• BOM desatualizada (resolve com engenharia)
• MOQ de fornecedor mal cadastrado (resolve com product.supplierinfo)
• Estoque on-hand divergente do físico (resolve com inventário cíclico)
• Falta de disciplina em criar sale.order no momento certo

Esses são problemas reais, mas não são específicos de DDMRP — afetariam qualquer planejamento.

Como evitar todos de uma vez

Em uma frase: fase de paralelo controlado de 8-12 semanas, com sponsor operacional, auditoria de lead time como entregável obrigatório, period censoring ativo, e revisão trimestral de profiles depois do go-live.

A KMEE inclui esses cinco pontos como cláusulas explícitas em proposta de implantação Enterprise — não por burocracia, mas porque a experiência diz que projeto que pula um deles entrega resultado pior.

Stack e papéis

A stack DDMRP é da ForgeFlow (Espanha). A camada community está em OCA. A camada Professional (dashboard, simulation, BOM optimization, prioritized share) é proprietária ForgeFlow. A KMEE é parceira oficial brasileira para implantação Enterprise — incluindo o conjunto de práticas de implantação descritas neste post.

Leituras relacionadas:

• O que é DDMRP
• De TOTVS Protheus para DDMRP
• Custo de implementação DDMRP
• Serviço DDMRP em Odoo