PDCA ou DMAIC: qual usar, segundo as duas exigências que separam os dois métodos

A pergunta PDCA ou DMAIC costuma ser feita como se fosse uma disputa de qualidade entre dois métodos. Não é. O DMAIC é um PDCA com duas exigências a mais, e são exatamente essas duas que decidem a escolha em cada problema concreto.

A primeira exigência é a fase Medir. Ela obriga a estabelecer linha de base com dado confiável antes de tocar em qualquer coisa do processo. A segunda é a fase Analisar, que exige prova de causa e não aceita hipótese plausível como resposta.

Quem entende isso para de perguntar qual é melhor. A pergunta útil passa a ser outra: o meu problema precisa de prova de causa? Se a causa já é conhecida com evidência, o DMAIC só adiciona meses ao calendário e horas à conta.

Se a causa é desconhecida e o custo do erro é alto, a relação se inverte. O PDCA conduzido sem rigor vai atacar a causa errada com toda a confiança do mundo, gastar o orçamento da contramedida e deixar o problema no lugar.

Procedência: este texto é comparativo e não substitui os artigos de cada método. O mecanismo de cada fase está detalhado em ciclo PDCA e em método DMAIC. O exemplo numérico é modelo com premissas declaradas, não medição de empresa específica, e toda a aritmética foi conferida.

A pergunta certa não é qual é melhor

Comparar PDCA e DMAIC pela qualidade do método é comparar chave de fenda com torquímetro. Os dois apertam parafuso. Um deles mede o aperto e registra o valor, e essa diferença não é de qualidade, é de finalidade.

O DMAIC nasceu dentro do Lean Seis Sigma justamente para problemas em que o aperto precisa ser medido. Ele herdou a lógica do PDCA e acrescentou dois pontos de verificação obrigatórios, um antes da ação e outro durante a análise.

Essa herança é reconhecida, mas quase sempre mal descrita. O mercado apresenta os dois como sequências equivalentes de fases, muda os nomes e considera a comparação encerrada.

O resultado prático é uma escolha feita por preferência cultural. Empresa com cultura Lean escolhe PDCA, empresa com programa de belts escolhe DMAIC, e o problema em questão não entra na decisão.

A decisão correta depende de duas variáveis do problema, não da cultura da casa. A primeira é se a causa é conhecida com evidência. A segunda é quanto custa errar a causa.

A correspondência entre as fases não é um para um

A versão de mercado da comparação alinha Define e Measure com o Plan, Improve com o Do, Analyze com o Check e Control com o Act. A tabela fica bonita e está errada em dois pontos.

O primeiro erro é colocar Analyze no Check. Analyze acontece antes de qualquer ação, e Check acontece depois. Um busca a causa do problema, o outro verifica o efeito da contramedida. Não são a mesma operação em momentos diferentes.

O segundo erro é tratar Control como equivalente do Act. O Act do PDCA padroniza o que deu certo e reinicia o giro. O Control instala um sistema de monitoramento com regra de reação escrita e transfere a responsabilidade para o dono do processo.

A correspondência honesta é outra. Define, Measure e Analyze cabem todos dentro do Plan, que no DMAIC foi quebrado em três blocos com entregável próprio e passagem de fase. Improve corresponde ao Do, e Control absorve Check e Act.

Isso deixa claro onde está a diferença real. O DMAIC não acrescentou fases ao PDCA: ele abriu o planejamento em três, e tornou obrigatório o que o PDCA deixa a critério de quem conduz.

O que o DMAIC exige que o PDCA não exige

A tabela abaixo é a comparação que importa. A coluna que decide não é a de correspondência, é a terceira: o que o DMAIC torna obrigatório e o PDCA deixa opcional.

Leia a terceira coluna como uma lista de custos. Cada exigência consome prazo e horas, e cada uma compra uma garantia diferente.

A pergunta de decisão é se o seu problema precisa comprar essas garantias. Nem todo problema precisa.

Por que o PDCA pode girar em uma semana e o DMAIC não

Um ciclo PDCA de rotina cabe em uma semana porque nenhuma de suas etapas tem prazo mínimo imposto por método. Planejar pode levar uma hora de reunião. Executar pode ser uma mudança de parâmetro no turno seguinte.

Verificar pode ser a leitura do indicador na sexta-feira, e agir pode ser a atualização do padrão na segunda. O ciclo inteiro roda dentro da própria rotina, sem projeto, sem orçamento e sem estrutura paralela.

O DMAIC não tem essa elasticidade, e o motivo é estrutural. A fase Measure exige que a linha de base seja estabelecida com dado confiável, e dado confiável tem prazo de coleta. O número de observações necessárias define o calendário mínimo.

Um estudo de tamanho de amostra honesto costuma apontar semanas de coleta para detectar diferenças pequenas. Comprimir esse prazo não acelera o projeto: apenas produz uma linha de base que não aguenta o teste do encerramento.

A fase Analyze tem restrição parecida. Provar causa exige dado suficiente para o teste, e às vezes exige um experimento planejado com repetições. Essas duas fases somadas são o piso de prazo do DMAIC, e é por isso que ele não gira em uma semana.

Measure: a linha de base e o MSA que o PDCA não pede

A fase Measure é a primeira das duas exigências que separam os métodos. Ela pede duas coisas. A primeira é a linha de base do indicador. A segunda é a prova de que o sistema que gera esse indicador é confiável.

Essa segunda parte é o estudo do sistema de medição, e é o que praticamente nenhum PDCA de rotina executa. Ela responde a uma pergunta desconfortável: o número que estamos usando mede o processo ou mede quem mediu?

Em inspeção visual por atributo, a resposta costuma ser decepcionante. Um estudo simples com três inspetores, trinta peças e duas repetições gera cento e oitenta avaliações e, com frequência, revela concordância abaixo de setenta e cinco por cento.

Quando isso acontece, todo o resto perde sentido. O PDCA que roda em cima de um sistema de medição ruim vai comemorar ganhos que são variação do inspetor, e vai descartar melhorias reais que a medição não conseguiu enxergar.

O DMAIC trava o projeto nesse ponto. Se o sistema de medição não passa, a primeira melhoria do projeto é o próprio critério de inspeção, antes de qualquer contramedida no processo. O PDCA não tem essa trava.

Analyze: prova de causa, não hipótese aceita

A segunda exigência é a mais cara e a mais decisiva. O Analyze não aceita causa levantada em reunião: ele exige que a relação entre a causa candidata e o efeito seja demonstrada com dado do próprio processo.

A diferença com o PDCA típico é brutal na prática. O PDCA levanta causas no diagrama de causa e efeito, a equipe vota nas mais prováveis, e a mais votada vira contramedida. O método não proíbe testar, mas também não obriga.

No DMAIC, cada causa que sobrevive precisa passar por teste de hipóteses ou equivalente. Fatores sem significância estatística são descartados por escrito, mesmo quando toda a sala acredita neles.

Esse descarte é o produto mais valioso da fase, e quase ninguém fala dele. Eliminar por dado a causa em que todo mundo acreditava evita o gasto inteiro da contramedida associada.

É aqui que a escolha entre os métodos se resolve. Se a causa já foi provada antes, o Analyze é encenação. Se ela é palpite coletivo e a contramedida é cara, o Analyze é o item de maior retorno do projeto inteiro.

Control é mais forte que o Act, e a diferença aparece no sexto mês

O Act do PDCA tem duas funções: padronizar o que funcionou e reiniciar o ciclo. É uma boa etapa e é insuficiente para ganho que precisa durar anos, porque padrão escrito não detecta desvio sozinho.

O Control instala três coisas que o Act não pede. A primeira é o monitoramento do indicador com regra estatística, normalmente por carta de controle com limites calculados do próprio processo.

A segunda é a regra de reação escrita, que diz o que fazer quando o monitoramento acusa desvio. Esse documento é o OCAP, e sem ele a carta vira um gráfico que alguém olha de vez em quando.

A terceira é a transferência formal de responsabilidade. O plano de controle nomeia quem mede, com que frequência, contra qual limite e a quem escalar. O projeto encerra e o processo continua vigiado.

A diferença entre as duas abordagens não aparece na semana do encerramento. Aparece no sexto mês, quando o ganho do PDCA já voltou ao patamar anterior e ninguém registrou o momento em que isso aconteceu.

Ciclicidade contra linearidade: uma diferença estrutural

O PDCA é um círculo e o DMAIC é uma linha. Isso costuma ser tratado como detalhe gráfico, e é a diferença estrutural mais importante entre os dois.

O PDCA foi desenhado para nunca terminar. O Act devolve o processo ao Plan com um padrão novo, e o próximo giro parte de um patamar melhor. A melhoria é incremental por construção, e o método é o veículo da rotina.

O DMAIC foi desenhado para terminar. Ele tem data de encerramento, entregável final e passagem de bastão. Um projeto DMAIC que não encerra é um projeto com problema de escopo, não um projeto que continua melhorando.

• Frequência. Dezenas de ciclos PDCA por ano na mesma área contra dois a quatro projetos DMAIC por belt no mesmo período.
• Ganho por ciclo. Pequeno e cumulativo no PDCA, grande e pontual no DMAIC.
• Encerramento. O PDCA nunca encerra, apenas muda de alvo; o DMAIC encerra com documento e transferência.
• Reinício. Novo giro do PDCA é gratuito; novo DMAIC exige seleção, patrocínio e alocação outra vez.

O PDSA de Deming e por que ele preferiu Study a Check

Deming passou anos corrigindo quem chamava o ciclo dele de PDCA. A versão que ele defendia é PDSA, com Study no lugar de Check, e a troca da palavra não foi preciosismo terminológico.

Check, em inglês, carrega o sentido de conferir se o resultado bate com o esperado. É uma operação de verificação binária: bateu ou não bateu a meta. Ela é útil e é pobre como fonte de aprendizado.

Study significa estudar o que aconteceu, inclusive quando o resultado bateu. Por que bateu, o que se aprendeu sobre o processo, que parte da teoria inicial se confirmou e que parte foi desmentida pelo dado.

Essa distinção conecta diretamente com o Analyze do DMAIC. As duas ideias pedem a mesma coisa: extrair conhecimento sobre o comportamento do processo, não apenas confirmar um resultado desejado.

Na prática brasileira, quase todo PDCA roda como Check e não como Study. Quem roda como Study fecha boa parte da distância para o DMAIC sem montar um projeto. Vale mais do que trocar de método. Detalhes do giro estão em o que é o ciclo PDCA.

Onde o MASP entra nessa comparação

O MASP é o terceiro lado dessa comparação e quase sempre fica de fora dela. Ele é um PDCA com oito etapas nomeadas, herdado do QC Story japonês, e ocupa uma posição intermediária bem definida.

A metodologia MASP faz o que o PDCA genérico não faz: separa observação de análise em etapas distintas e obrigatórias. Essa separação é a mesma ideia que o DMAIC formaliza entre Measure e Analyze.

O que o MASP não exige é o rigor estatístico. Ele pede estratificação e ida ao processo, mas não pede estudo de sistema de medição nem teste de significância para eleger a causa.

Isso o coloca exatamente entre os dois. Mais rigoroso que o PDCA de rotina na separação das etapas, menos exigente que o DMAIC na prova. A comparação detalhada está em MASP x DMAIC.

Para problema crônico de causa desconhecida com dado escasso, o MASP costuma ser a escolha mais realista. Ele obriga a observar sem exigir uma infraestrutura estatística que muitas operações ainda não têm.

Custo e prazo: a conta que decide na prática

A comparação de prazo e custo é onde a decisão sai do plano conceitual. Um PDCA de rotina consome horas da própria equipe e não aparece no orçamento. Um DMAIC consome um belt em dedicação parcial por meses.

Repare que a coluna de custo do DMAIC só se justifica quando o ganho recorrente é grande. Projeto de DMAIC para problema de ganho pequeno é decisão financeira ruim, mesmo quando é decisão metodológica correta.

Quem conduz cada um, e por que isso não é detalhe

O PDCA é conduzido por quem é dono do processo. Supervisor, líder de célula, coordenador de área. A competência exigida é conhecer o processo e saber conduzir uma reunião curta com plano de ação.

O DMAIC é conduzido por alguém formado em estatística aplicada, com dedicação parcial protegida e patrocínio de nível gerencial. Green Belt em projeto simples, Black Belt em projeto com variação complexa ou múltiplos fatores.

Essa diferença tem uma consequência organizacional que costuma passar batida. O PDCA escala sem depender de formação especializada, e por isso é o único dos dois que pode rodar em todas as áreas ao mesmo tempo.

O DMAIC não escala assim. Cada belt entrega dois a quatro projetos por ano, e a fila de projetos é limitada pela quantidade de belts formados. Quem tenta rodar DMAIC em tudo acaba rodando PDCA com nome de DMAIC.

A escolha de quem conduz também determina o tipo de problema viável. Ninguém aloca um Black Belt para um problema que o supervisor resolve na sexta-feira, e nenhum supervisor tem tempo para conduzir um experimento planejado.

Os quatro cenários que decidem a escolha

Cruzando as duas variáveis que importam, causa conhecida ou desconhecida contra custo do erro alto ou baixo, saem quatro cenários. Eles cobrem praticamente toda decisão real de método.

O segundo cenário é o mais ignorado dos quatro. Nele o problema não precisa de investigação, precisa de sustentação, e a resposta é rodar o PDCA normalmente e importar apenas o plano de controle do DMAIC.

O terceiro também é mal resolvido na prática. Quando errar é barato, testar rápido é superior a provar devagar, e cada ciclo curto elimina uma hipótese por custo baixo. Isso é aprendizado por experimentação, não falta de rigor.

O mesmo problema pelo PDCA: onde ele chega à causa errada

Considere uma linha de envase com trezentas e oitenta mil unidades por mês e refugo de vedação medido em quatro vírgula oito por cento. A inspeção é por amostragem, quinhentas unidades por dia em vinte e um dias úteis.

Isso dá dez mil e quinhentas unidades inspecionadas por mês. Ao custo de dois reais e quarenta centavos por unidade refugada, a perda mensal é de quarenta e três mil setecentos e setenta e seis reais.

O PDCA roda em cinco semanas. A equipe levanta causas, e a mais votada é a temperatura do mordente de selagem. A contramedida é trocar seis controladores de temperatura, e o plano de ação é aprovado sem objeção.

• Seis controladores novos a R$ 3.800 cada: R$ 22.800.
• Quarenta horas de engenharia a R$ 95 por hora: R$ 3.800.
• Seis horas de parada de linha a R$ 1.450 por hora: R$ 8.700.
• Investimento total do ciclo: R$ 35.300.

No mês seguinte o refugo medido cai de 4,8% para 4,4%. O ciclo é declarado bem-sucedido, o padrão é atualizado e a equipe parte para o próximo problema. Nos meses seis e sete, o indicador volta a 4,7%.

Com dez mil e quinhentas unidades inspecionadas e proporção de 4,8%, o erro padrão da estimativa é de 0,209 ponto percentual. O intervalo de confiança de noventa e cinco por cento tem meia-largura de 0,409 ponto percentual.

A queda observada foi de 0,40 ponto. Ela cabe inteira dentro da margem de erro da própria medição, o que significa que o mesmo resultado apareceria por acaso amostral com frequência alta, sem nenhuma contramedida.

Esse é o ponto exato em que o PDCA sem rigor falha. Nada no método obriga alguém a calcular esse intervalo, e o ciclo é encerrado com um número que soa como vitória e não sobrevive à conferência.

Pior: o número de partida também estava contaminado. A inspeção era visual por atributo, e ninguém havia verificado se dois inspetores classificavam a mesma peça do mesmo jeito. Voltaremos a isso na próxima seção.

O mesmo problema pelo DMAIC: onde a prova muda a resposta

O mesmo problema entra como projeto DMAIC com vinte e duas semanas de prazo, distribuídas em duas semanas de Define, seis de Measure, cinco de Analyze, cinco de Improve e quatro de Control.

O Measure começa pelo sistema de medição. Três inspetores avaliam trinta peças em duas repetições, o que dá cento e oitenta avaliações. A concordância com o padrão fica em setenta e um por cento, com kappa de 0,42.

Isso reprova o sistema de medição. O critério de aceitação de vedação é reescrito com padrões físicos de referência, os inspetores são recalibrados, e a linha de base real do refugo cai para 3,9%, não 4,8%.

O Analyze então testa os fatores candidatos. A temperatura do mordente não apresenta significância, com valor-p de 0,41. O fornecedor do filme apresenta: 2,6% de refugo com o fornecedor A contra 5,8% com o fornecedor B.

Com cinco mil duzentas e cinquenta unidades de cada grupo, a diferença de 3,2 pontos percentuais dá estatística z de 8,17 e valor-p abaixo de 0,001. A causa não era temperatura. Era espessura de filme fora de especificação.

A conta do erro: quanto custou descobrir depois

O Improve corrige a especificação de espessura e institui inspeção de recebimento por lote com o fornecedor B. O refugo cai de 3,9% para 1,7% e se mantém, agora monitorado pela carta instalada no Control.

O ganho recorrente é de oito mil trezentas e sessenta unidades por mês, ou vinte mil e sessenta e quatro reais mensais. O projeto inteiro custou quarenta e seis mil trezentos e vinte reais, com retorno em dois vírgula três meses.

Os onze mil reais a mais do DMAIC compraram a eliminação de um erro de cento e setenta e cinco mil. Essa é a conta que o cenário quatro descreve, e ela só fecha quando a causa é mesmo desconhecida.

O erro de chamar de DMAIC um PDCA com cinco caixas

O erro mais comum em programas de melhoria não é escolher o método errado. É usar o nome do método rigoroso sobre um ciclo que não cumpre nenhuma das duas exigências que o tornam rigoroso.

O sintoma é fácil de auditar. Abra o relatório de fechamento do projeto e procure duas coisas: o estudo do sistema de medição no Measure e o teste estatístico que eliminou fatores no Analyze.

1. Se o Measure traz apenas o valor atual do indicador, sem verificação do sistema que o mede, a fase não foi executada.
2. Se o Analyze traz um diagrama de causa e efeito com causas eleitas por votação, a fase não foi executada.
3. Se nenhum fator candidato foi descartado por dado, ninguém provou nada, apenas confirmou a suspeita inicial.
4. Se o Control entrega um procedimento sem quem monitora, com que frequência e contra qual limite, a fase virou anexo.

Um ciclo assim é um PDCA, e um PDCA é legítimo. O problema é que ele foi vendido com prazo, custo e expectativa de DMAIC, e cobrou meses de calendário para entregar o rigor de uma reunião de cinco semanas.

Como usar os dois em camadas: rotina e crônico

A camada de baixo é o PDCA de rotina, rodando em todas as áreas, semanal ou quinzenal, conduzido pelos próprios donos de processo. Ele resolve a grande maioria dos problemas, e resolve rápido, porque a causa costuma ser conhecida.

A camada de cima é o DMAIC, reservada ao que a camada de baixo não resolveu. O critério de subida precisa ser objetivo, e o mais usado é a reincidência: problema que voltou duas vezes após PDCA fechado é candidato a projeto.

• Gatilho de subida. Reincidência após dois ciclos PDCA fechados, ou perda anual acima de um valor definido.
• Gatilho de descida. Projeto cuja causa se revela conhecida logo no Define volta para a rotina.
• Padronização do ganho. Todo DMAIC encerrado entrega um padrão que a rotina passa a manter, tema tratado em PDCA x SDCA.
• Meta comparável. Os dois usam a mesma régua de indicador, conforme como definir meta de indicador.

A decisão final cabe em uma frase: pergunte se o seu problema precisa de prova de causa. Se precisa e errar é caro, o DMAIC paga o prazo. Se não precisa, o PDCA entrega o mesmo resultado em uma fração do tempo.