Diferença entre PDCA e DMAIC: qual usar em cada caso

Passei dois anos como coordenador de operações da MRS Logística, em Conselheiro Lafaiete. Foi ali que a diferença entre PDCA e DMAIC deixou de ser assunto de sala de aula para mim: eu chefiava os inspetores que chefiavam os maquinistas, e todo mês chegava indicador fora da meta com uma sugestão de método junto.

Errei essa escolha nos dois sentidos, e demorei a perceber. Abri estudo longo para problema que o supervisor sabia explicar em cinco minutos. Depois girei ciclo curto três vezes em cima de um atraso que ninguém conseguia explicar, e o indicador não se moveu em nenhuma das três. Custou caro das duas vezes, e em nenhuma delas o método era o culpado.

É que os dois não competem. Um nasceu do outro, e o mais novo pegou a fase de planejamento do mais velho e desdobrou em quatro etapas com ônus de prova.

Este texto mostra onde exatamente eles se separam, com as páginas do livro que sustentam cada afirmação, e entrega um critério de escolha que cabe em três perguntas.

PDCA e DMAIC não são rivais: um nasceu do outro

O PDCA é um ciclo em quatro fases, indicado para problema de causa conhecida e mudança pequena. O DMAIC é um roteiro de projeto em cinco etapas que desdobra o planejamento do PDCA e exige prova estatística da causa. Use o primeiro na rotina e o segundo com causa desconhecida.

A comparação quase sempre é montada como disputa. Qual é melhor, qual é mais moderno, qual a empresa deveria adotar. A premissa já está errada, e o próprio livro que serve de base para este texto diz por quê.

O capítulo 18 do Guia Prático Lean Seis Sigma Black Belt, que se chama "Método DMAIC e DMAIC Ágil", é direto: "o DMAIC se inspira do PDCA e utiliza ferramental estatístico" (p. 143). Uma página adiante o livro reforça que, "assim como o PDCA, o DMAIC é um ciclo de Melhoria Contínua" (p. 144).

Um descende do outro.

Os dois pertencem à mesma família. Servem ao mesmo objetivo de melhoria contínua, giram em volta do mesmo processo e terminam no mesmo lugar, que é um padrão novo funcionando. A escolha entre eles não é uma escolha de escola.

Se você chegou aqui querendo entender cada um por dentro, vale abrir antes o artigo sobre o que é o ciclo PDCA e o de método DMAIC. Aqui o assunto é outro: o que decide qual dos dois entra no seu problema.

Vamos ao que separa os dois de verdade, que cabe em uma letra.

A diferença entre PDCA e DMAIC cabe dentro da letra P

Guarde esta frase, porque ela resolve quase toda a confusão do assunto: o que separa os dois está quase inteiro dentro da fase de Planejamento.

O livro descreve o desdobramento com todas as letras na página 145. Ele lista o que mora dentro da primeira fase: "a identificação do problema, a análise do fenômeno e do processo e a elaboração do plano de ação". E completa que, no método DMAIC, "esses processos são desdobrados em mais etapas".

Na mesma página vem o resumo: "o DMAIC descreve uma fase de planejamento mais detalhada". É isso. Quatro atividades que na roda de quatro letras moram todas dentro do P viram, no projeto, quatro etapas com entrega própria.

Define delimita o problema e o ganho esperado. Measure levanta a linha de base com dado confiável. Analyze prova a causa. Improve desenha e testa a solução. As quatro somadas dão o P.

O que sobra tem correspondência quase direta. Do vira execução do plano, Check vira verificação do resultado, Act vira padronização e conclusão. Ninguém precisa reaprender essa parte. Daí sai a leitura correta da comparação: um método não substitui o outro, um deles aprofunda o planejamento do outro e cobra caro por isso.

As etapas lado a lado

A tabela abaixo põe as quatro fases ao lado das cinco etapas. Repare que a coluna do meio acumula quatro etapas na primeira linha e uma só em cada uma das outras.

O desequilíbrio da tabela é a mensagem. Três das quatro fases têm correspondência de um para um. A primeira tem correspondência de um para quatro.

É por isso que dizer que um método tem cinco etapas e o outro tem quatro engana. A contagem sugere que um é vinte e cinco por cento maior. Na prática o planejamento é que fica várias vezes mais pesado.

Vale olhar linha por linha. Na fase de execução, os dois pedem a mesma coisa: alguém responsável, prazo e recurso liberado. Um plano de ação bem feito no PDCA é indistinguível de um plano de implantação de projeto. Na verificação a diferença já aparece, mas é de grau: o ciclo pergunta se o indicador melhorou, e o projeto pergunta se a melhora resiste a uma comparação contra a linha de base medida antes. No fechamento volta a ser formalidade, não natureza. Os dois querem padrão novo em vigor, só que um aceita o procedimento atualizado e o outro exige o monitoramento documentado.

Somado tudo, fora da primeira linha o DMAIC é o PDCA com mais evidência exigida em cada porta.

Quando o ciclo de quatro fases é a escolha certa

O livro é econômico e claro nesse ponto. Na página 151 ele registra que o PDCA "é ideal em ambientes nos quais é possível implementar pequenas mudanças, monitorar os resultados e realizar ajustes conforme necessário".

Três condições, todas verificáveis antes de começar. A mudança é pequena. Dá para monitorar o resultado. Dá para ajustar sem refazer tudo.

Some a isso a condição de entrada mais importante de todas, que é saber por que o problema acontece. Quando a causa é conhecida ou fica evidente com uma investigação curta, o planejamento longo vira desperdício de tempo.

Investigação curta aqui tem nome. Uma sessão de 5 porquês com quem opera, um diagrama de Ishikawa rabiscado na reunião e um 5W2H para o plano de ação. Se isso fecha o raciocínio, você já tem o que precisa.

Na mesma página o livro recomenda a adoção de MASP, Kaizen ou do ciclo de quatro fases "para problemas com solução rápida", e a palavra rápida está fazendo trabalho pesado nessa frase.

Uma linha que para porque o operador novo não conhece o ajuste do fuso não precisa de projeto, e sim de padrão, treino e verificação em duas semanas.

Existe ainda um argumento que raramente entra na conta, e que pesa mais do que parece. O ciclo curto é executado pela própria equipe que opera o processo, e isso muda a adesão ao resultado. Quem participou do diagnóstico defende o padrão novo, porque ele saiu de uma conclusão da própria equipe. Padrão que chega pronto de fora costuma durar menos.

Por isso, em ambiente com pouca maturidade em melhoria, começar pelo PDCA tem valor além do técnico: ele treina a equipe a medir antes de opinar, que é o hábito de que o projeto vai precisar depois.

Quando o problema pede DMAIC

A condição de entrada inverte quando ninguém sabe explicar o problema. A recomendação do livro, na página 152, é de uma linha: causa desconhecida pede Lean Seis Sigma, e o DMAIC é o roteiro com que ele se executa.

Causa desconhecida muda tudo.

Enquanto ninguém sabe por que o defeito aparece, todo plano de ação é aposta. E aposta implantada em processo grande custa caro quando erra.

O segundo sinal é variabilidade. Quando o resultado oscila sem padrão visível, a média esconde o problema. Medir a capabilidade do processo costuma ser a primeira coisa que revela o tamanho real da encrenca.

O terceiro sinal é o tamanho da perda. Medição estatística séria consome semanas de gente cara, e só faz sentido quando o ganho esperado paga essa conta com folga.

O quarto é a dispersão da causa. Quando o diagrama de Pareto não mostra uma barra dominante, e sim seis barras parecidas, você não tem um problema. Tem seis, e precisa descobrir qual deles responde pelo resultado.

O livro justifica o esforço na mesma página: "o DMAIC é desdobrado em etapas mais detalhadas, permitindo maior compreensão acerca do problema". Compreensão é exatamente o que falta quando a causa é desconhecida.

O que Medir e Analisar cobram que o Verificar não cobra

Aqui está a diferença prática que mais dói na primeira vez. As duas etapas do meio do projeto impõem um ônus de prova que a rotina não impõe.

Measure começa perguntando se o dado presta. Um estudo de MSA verifica se o instrumento e o operador medem a mesma peça do mesmo jeito. É comum descobrir que metade da variação observada estava no sistema de medição.

Depois vem o plano de coleta de dados: o que medir, quem mede, com que frequência, por quanto tempo. Sem isso a linha de base é uma opinião com número do lado.

Analyze cobra a prova da causa. Não basta a equipe concordar que o turno da noite rende menos. Um teste de hipótese diz se a diferença entre os turnos é real ou se cabe dentro do ruído do processo.

Existe um efeito colateral bem-vindo nesse rigor todo. Ao terminar a medição, a equipe costuma saber mais sobre o próprio processo do que sabia em anos de operação.

Compare com o Verificar do PDCA. Ele pergunta se o indicador melhorou depois da ação. É uma pergunta legítima e barata, e resolve a maioria dos casos do dia a dia. O ponto é que ela não distingue melhora real de sorte no mês, e quando o custo do erro é alto essa distinção deixa de ser luxo.

O Agir do ciclo e o Control do projeto

As duas últimas letras fazem a mesma coisa: transformar ganho em padrão. A diferença está no peso da formalidade exigida.

No ciclo curto, agir costuma ser atualizar o procedimento operacional padrão, treinar a equipe e seguir. Funciona bem quando a mudança é pequena e o time é o mesmo.

No projeto, o Control entrega um plano de controle com dono, item monitorado, frequência e ação de contingência. Em geral acompanhado de uma carta de controle rodando no indicador que o projeto moveu. Parece burocracia até a primeira vez que um ganho de seis meses evapora em oito semanas. Aí a folha de rosto do plano de controle passa a fazer sentido.

Uma regra prática calibra isso: quanto mais gente diferente executa o processo, e quanto maior a rotatividade, mais formal precisa ser o fechamento.

De onde vem o ciclo de quatro fases

Escrevi o capítulo 18 do meu livro três vezes antes de aceitar que estava explicando errado. Nas duas primeiras eu tratava os dois como métodos concorrentes e listava vantagens de cada lado, que é exatamente o que eu vinha fazendo em sala havia anos. Não fechava. São 536 páginas pela Atlas, endossadas pelo Nigel Slack, professor emérito de Warwick, e eu não podia entregar as duas coisas soltas em capítulos vizinhos. Só quando desenhei as quatro fases e as cinco etapas na mesma figura é que a resposta apareceu, e ela era bem mais simples do que a minha explicação.

A origem também ajuda a entender a hierarquia entre os dois. O ciclo foi proposto por Walter A. Shewhart em 1930, dentro do trabalho dele com controle estatístico de processo.

Deming divulgou o método a partir de 1950, no Japão, a convite da JUSE, a união japonesa de cientistas e engenheiros. O nome dele acabou colado ao ciclo, tanto que o ciclo de Deming virou sinônimo, embora a autoria seja de Shewhart. O livro registra as duas datas na página 126, no capítulo 14, "Ciclo PDCA e SDCA".

Vinte anos separam a proposta da divulgação, o que vale lembrar quando alguém apresentar método de melhoria como novidade do ano.

De onde vem o método de cinco etapas

O DMAIC é bem mais novo e nasceu com outro problema na frente. Ele é o roteiro de execução de projeto do Lean Seis Sigma, e herdou do Seis Sigma a obrigação com evidência estatística.

Essa herança explica quase tudo que o distingue. Não é que o método seja mais rigoroso por escolha estética: ele foi desenhado para problemas em que a intuição da equipe já tinha falhado. Explica também a estrutura de papéis. Projeto tem patrocinador, tem líder formado, tem prazo e tem escopo assinado. A roda de quatro fases roda sem nada disso, e essa é boa parte da graça dela.

Repare que a roda continua sendo uma roda: o que mudou foi o preço de cada porta.

Duas ferramentas com propósitos diferentes, então. Uma para a rotina de quem opera. Outra para o que a rotina não consegue fechar.

O ciclo que não melhora nada, e por que ele importa aqui

Existe um terceiro ciclo que muda a conversa, e quase ninguém traz para a comparação. É o SDCA, que troca o Planejar por Padronizar.

Ele não melhora resultado nenhum, de propósito. A função dele é segurar o que já foi melhorado, e a diferença de papel está detalhada no artigo sobre PDCA e SDCA.

Isso importa na escolha entre os dois métodos deste texto por um motivo específico. Boa parte dos casos em que a melhoria some depois de três meses não é falha do método escolhido, e sim ausência de padronização sustentada depois dele. O time gira a roda de melhoria de novo, obtém o mesmo ganho de novo, e perde de novo.

Antes de trocar de método porque o anterior não funcionou, vale conferir se o problema foi de método ou de sustentação.

Quatro trocas que saem caro

Antes dos erros, vale nomear onde cada método falha. Comparação que só diz o que cada um é não ajuda ninguém a decidir.

O PDCA falha quando a causa é desconhecida. A condição está no próprio livro, que na página 152 manda usar Lean Seis Sigma justamente nesse cenário. O sintoma é objetivo: a equipe gira o ciclo, ataca um sintoma diferente a cada volta e o indicador não sai do lugar.

O PDCA também falha quando a variação é grande e sem padrão. A condição sai da recomendação da página 151, que só indica o ciclo onde é possível "monitorar os resultados". Variação sem padrão quebra justamente esse pedaço: o monitoramento para de distinguir efeito de ruído. O time comemora um mês bom que era só flutuação, e o ganho não se confirma no trimestre.

O DMAIC falha quando a perda não paga a medição. A página 151 manda usar MASP, Kaizen ou o ciclo de quatro fases "para problemas com solução rápida", e problema barato costuma ser exatamente isso. Semanas de coleta e análise consomem gente formada, e o retorno não cobre. É o caso do projeto de quatro meses que termina concluindo o que o supervisor já suspeitava na primeira semana.

E falha de novo quando o prazo não cabe no método. Problema com causa desconhecida e prazo de três semanas não tem solução boa. Encurtar a análise para caber no prazo produz uma causa não provada com aparência de projeto.

Feitas as condições de fracasso, os erros de execução aparecem em ordem previsível. Os quatro abaixo eu vi acontecerem todos dentro dos meus dois anos de coordenação em Lafaiete, e três deles mais de uma vez.

• Projeto grande para problema óbvio. Quatro meses de estudo para descobrir que faltava treino no turno da noite. O time perde a confiança na ferramenta, e com alguma razão.
• Ciclo curto para causa desconhecida. A equipe gira três vezes, ataca três sintomas diferentes e o indicador não sai do lugar. Sinal claro de que o planejamento precisa de mais peso.
• Medição sem validar o sistema de medição. Semanas de coleta que só provaram que o instrumento está descalibrado.
• Padronização sem dono. O procedimento é publicado, ninguém fica responsável por conferir, e em dois meses cada turno voltou ao jeito antigo.

Os quatro têm uma raiz comum. Em todos, alguém decidiu o método antes de olhar a condição de entrada do problema, e a escolha virou preferência pessoal ou moda da empresa naquele ano. O antídoto é chato e funciona. Antes de abrir qualquer coisa, escreva em uma linha o que se sabe sobre a causa e como se sabe disso. Se a segunda parte da frase não existir, você descobriu que não sabe.

Vale registrar um quinto, que é confundir método de solução de problema com método de projeto. A metodologia MASP também resolve problema com causa conhecida, e a comparação entre MASP e DMAIC segue uma lógica parecida com a deste texto.

Três perguntas antes de abrir qualquer coisa

A escolha cabe em três perguntas, e a ordem entre elas importa. A primeira sozinha resolve a maior parte dos casos.

Primeira: você sabe por que o problema acontece? Se a equipe consegue explicar a causa e mostrar como sabe disso, o planejamento longo não vai acrescentar nada. Siga com o ciclo curto.

Segunda: a mudança é pequena e reversível? O PDCA vive disso. Se dá para testar em uma linha, um turno ou uma unidade, e voltar atrás sem estrago, teste. Aprender rodando é mais barato do que aprender estudando.

Terceira: a perda paga a medição? Se o problema custa oitenta mil reais por ano, e o estudo estatístico consome três meses de um analista, a conta não fecha. Se custa oitocentos mil, fecha com sobra.

Duas respostas afirmativas nas duas primeiras já apontam o caminho, e a terceira é o freio para quando elas vieram negativas.

Três problemas na mesa, e o que eu faria em cada um

Fica mais claro com casos, em que a condição de entrada define a escolha.

Refugo subiu de 2% para 5% depois da troca de fornecedor. A causa está praticamente escrita no enunciado. Ciclo curto, com verificação em quatro semanas e padrão de inspeção de recebimento no fim.

Refugo oscila entre 3% e 9% há dois anos, sem relação visível com turno, lote ou operador. Ninguém sabe explicar. Projeto estruturado, com validação do sistema de medição antes de qualquer conclusão.

Prazo de entrega estourou no último trimestre, e a operação apontou quatro causas possíveis. Aqui a decisão depende do valor em jogo. Se o atraso ameaça um contrato grande, projeto. Se é incômodo administrável, um giro curto para eliminar as duas causas mais prováveis primeiro.

O terceiro caso é o mais comum e o mais mal resolvido. Quando há quatro causas possíveis e nenhuma delas está descartada, a tentação é abrir projeto para não errar. Só que quatro hipóteses ainda são poucas para justificar meses de estudo, e dois giros do PDCA eliminam as duas mais prováveis por teste direto, a custo baixo.

Se as duas restantes sobreviverem, aí sim o projeto começa com a lista curta e o dado na mão. É a diferença entre abrir um DMAIC informado e abrir um DMAIC por precaução.

Repare que em nenhum dos três a escolha veio do tamanho da empresa ou da maturidade do time. Veio do que se sabia sobre a causa.

A tabela de decisão

Reuni o critério em uma página, para levar à reunião em que a decisão será tomada. Ela cruza a condição de entrada com o método indicado, e traz o sinal de que chegou a hora de trocar.

A tabela tem três colunas. Na primeira, a condição de entrada observável: o que se sabe da causa, o tamanho da mudança, o custo anual da perda e o prazo disponível. Na segunda, o método indicado para aquela combinação. Na terceira, o sinal objetivo de que a escolha foi errada e é hora de trocar.

Baixe a tabela de decisão entre PDCA e DMAIC

O uso previsto é preencher a primeira coluna antes de escolher, e não depois de já ter escolhido.

A tabela diz qual método entra. Que instrumento cada fase pede é outra conversa, e essa está no kit de ferramentas Lean Seis Sigma, com os formulários de coleta, os gráficos de análise e o plano de controle já montados.

A diferença entre PDCA e DMAIC na agenda de quem lidera

Conduzir um e conduzir o outro são rotinas distintas, e isso aparece na agenda antes de aparecer no resultado.

No PDCA a reunião é semanal, dura meia hora e olha o quadro. A evidência guardada é o próprio quadro, mais o padrão atualizado no fim.

No projeto a reunião com o patrocinador é quinzenal e tem entregável de etapa. Começa pelo termo de abertura assinado e segue com um gate a cada fase concluída.

A evidência guardada também muda de natureza: vira memória de cálculo, base de dados e relatório de análise, porque alguém vai auditar o ganho declarado.

Quem tenta conduzir projeto com rotina de ciclo curto costuma travar na terceira etapa, e quem conduz ciclo curto com rigor de projeto mata o ritmo da equipe em duas semanas.

Quanto tempo cada um leva

A pergunta sobre duração esconde a pergunta real: ninguém quer saber quantas semanas, quer saber quanto planejamento o problema exige.

Como ordem de grandeza, um giro do ciclo curto fecha em semanas. Um projeto estruturado leva de quatro a seis meses, e a maior parte disso mora nas etapas de medição e análise.

Essa proporção incomoda quem vem da rotina. É comum ouvir que o projeto passou três meses sem entregar nada, quando ele passou três meses evitando implantar a solução errada.

Existem versões encurtadas, e o próprio livro trata do DMAIC ágil no mesmo capítulo 18. Elas comprimem o cronograma, mas não dispensam a prova da causa.

Prazo curto com causa desconhecida continua sendo o pior cenário possível, e nele o realismo manda reduzir o escopo do problema, e não o rigor da análise.

Dois giros, e aí o caso sobe para projeto

A configuração que funciona é sempre a mesma. O PDCA vira o método padrão da operação, e o projeto fica reservado para o que a operação não fecha.

Na prática isso significa que todo problema entra pela porta barata. A equipe gira uma vez, com prazo definido, e mede. Se o indicador não se moveu depois de dois giros do PDCA, o caso sobe. Esse critério objetivo evita as duas patologias: o projeto aberto por reflexo e o giro infinito que nunca escala.

Dois giros também são tempo suficiente para produzir algo valioso: a equipe chega ao projeto com dado coletado, com hipóteses já descartadas e com o problema mais bem delimitado.

Ou seja, o PDCA que falhou não foi desperdício: ele virou a etapa Define do que vem depois.

Há um ganho de gestão nesse arranjo que costuma passar despercebido: o critério de subida é público, escrito e igual para todo mundo.

Sem ele, a decisão de abrir projeto acaba dependendo de quem grita mais alto na reunião de resultados. Na MRS, quando esse critério virou uma linha no quadro, deu um gás na área inteira: as pessoas pararam de disputar a agenda do analista e passaram a discutir o indicador.

Recomendo escrever esse critério em uma linha e colar no quadro da área. Duas tentativas de PDCA documentadas, sem movimento no indicador, abrem a discussão de projeto.

Falta o caso difícil, que é quando as duas condições de fracasso aparecem juntas. Causa desconhecida, que derruba o ciclo curto, com perda pequena, que não paga o projeto. Essa combinação não tem método certo, e insistir em escolher um é o erro. O livro dá a régua na página 151: "não existe metodologia melhor ou pior, e sim a que mais se enquadra para resolver determinada situação".

A saída prática é mudar o problema, e não o método. Recorte um pedaço do problema em que a causa seja investigável a custo baixo, resolva esse pedaço pelo ciclo curto e meça o que sobrou.

Se o que sobrou continuar caro depois do recorte, a perda cresceu em relação ao escopo e o projeto passou a se pagar. Se não continuar, você já resolveu o que valia resolver.

Como o projeto devolve o processo para a rotina

O fim de um projeto de melhoria não é o fim do processo. Essa obviedade é esquecida com uma frequência impressionante. A última etapa entrega o processo de volta a quem opera, com padrão novo e plano de monitoramento, e a partir daí quem cuida do resultado é a rotina.

E rotina, aqui, quer dizer as quatro fases girando de novo, agora sobre um patamar melhor, sustentadas pela padronização que o projeto deixou.

Vista assim, a relação entre os dois deixa de ser uma escolha excludente. Vira um ciclo maior, em que o projeto entra quando a rotina empaca e sai quando o patamar novo se estabiliza.

Quem trata o projeto como evento isolado sente o efeito uns seis meses depois: o ganho aparece no relatório de encerramento e some do indicador, porque ninguém assumiu a rotina.

É a leitura que o capítulo 18 do livro sustenta, e é a que resolve a discussão na prática.

Como justificar a escolha para quem aprova o orçamento

A pergunta que chega da diretoria é quase sempre a mesma: "por que não resolvemos isso com o ciclo de sempre, que é mais rápido?". A resposta boa não fala de método.

Fala do que se sabe da causa. Se sabemos, o ciclo de sempre resolve, e resolve mais rápido mesmo. Se não sabemos, o que parece mais rápido é implantar a solução errada.

Um segundo argumento costuma fechar a conversa. Apresente a conta: custo anual da perda contra o custo do estudo. Quando a perda é grande, a decisão deixa de ser técnica. E há um terceiro, para o caso de a diretoria querer projeto em tudo: projeto aberto para problema com causa conhecida ocupa gente formada em trabalho que a operação faria em duas semanas.

Se a sua equipe ainda não tem quem conduza a análise estatística, esse é o gargalo real da escolha. Nas academias de certificação a gente forma justamente esse perfil, e sem ele a segunda opção nunca fica disponível de verdade.