DMAIC ou DMADV: qual usar, pelo teste da capabilidade máxima
O DMAIC melhora um processo que existe e tem histórico; o DMADV projeta um que ainda não existe. A pergunta que decide é uma só, e o teste da capabilidade máxima resolve os casos duvidosos com aritmética.
A pergunta DMAIC ou DMADV é quase sempre tratada como preferência de escola. Não é. A escolha entre os dois não é de gosto nem de maturidade do time: é de existência do objeto sobre o qual se vai trabalhar.
O DMAIC melhora um processo que já existe e já produziu histórico. O DMADV projeta um processo ou produto que ainda não existe. A pergunta que decide é uma só, e ela é verificável em uma tarde: existe linha de base?
Se existe, o caminho é DMAIC. Se não existe, não há o que medir, não há causa a analisar, e metade das ferramentas do DMAIC fica sem insumo. Rodar Analyze sem dado histórico é encenar uma fase, não executá-la.
O erro caro é o inverso disso. Aplicar DMAIC a um processo que precisa ser reprojetado significa gastar meses otimizando um desenho que não alcança a meta nem no melhor caso possível, com o processo perfeitamente centrado.
Procedência: este texto é comparativo e decisório, e não substitui a descrição de cada método. O passo a passo de cada fase está em método DMAIC e em método DMADV. O exemplo numérico é modelo com premissas declaradas, não medição de empresa específica, e toda a aritmética foi conferida.
A escolha não é de preferência, é de existência
Quem pergunta qual dos dois métodos é melhor está fazendo a pergunta errada. Eles não competem pelo mesmo trabalho. Um opera sobre um processo vivo, com dado acumulado; o outro opera sobre uma folha em branco.
As letras coincidem, o objeto não. No DMAIC, Measure mede um processo que está rodando agora. No DMADV, Measure mede necessidades de cliente, porque não existe processo do qual coletar.
Por isso a decisão precisa de um critério objetivo, verificável antes do kickoff. Preferência do patrocinador e cultura da casa não são critério. Existência de linha de base é.
A pergunta que decide: existe linha de base?
Linha de base não é ter algum número. É ter uma série histórica do indicador de interesse, com origem conhecida, suficiente para descrever o comportamento do processo em termos de centro e variação.
O teste é simples e cabe em quatro perguntas. Se as quatro respostas forem sim, o caso é de DMAIC. Se duas ou mais forem não, provavelmente o caso é de projeto, não de melhoria.
- Existe o processo rodando hoje, produzindo saída real para um cliente interno ou externo?
- Existe registro do indicador crítico ao longo do tempo, com pelo menos algumas dezenas de observações?
- É possível identificar as entradas do processo e ligá-las às saídas, ainda que grosseiramente?
- O desenho atual do processo tem chance de atingir a meta, se for bem conduzido e centrado?
A quarta pergunta é a mais importante e a menos feita. Ela não pergunta se o processo está bom hoje. Pergunta se o desenho atual comporta a meta no melhor cenário possível.
Quando a resposta à quarta é não, as três primeiras deixam de importar. O processo existe, tem dado e tem causa mapeável, e ainda assim nenhuma melhoria chega à meta. Esse é o caso de reprojeto.
As cinco fases lado a lado e o que muda em cada posição
A tabela abaixo é a comparação estrutural. Ela não alinha os métodos pelo nome da fase, e sim pelo que cada posição entrega. A terceira coluna é a que carrega a decisão.
| Fase do DMAIC | Fase do DMADV | O que muda na mesma posição |
|---|---|---|
| Define: escopo do desvio, meta contra linha de base, caso de negócio | Define: escopo do objeto a projetar, janela de lançamento e viabilidade | Um define desvio a corrigir; o outro, objeto a criar, com risco de mercado |
| Measure: linha de base do processo atual e validação da medição | Measure: voz do cliente traduzida em características críticas mensuráveis | Um mede o processo que existe; o outro mede o cliente, porque não há processo |
| Analyze: prova de causa raiz sobre dado do processo | Analyze: geração e seleção de conceitos contra os requisitos críticos | Um busca por que o resultado é ruim; o outro escolhe o desenho mais promissor |
| Improve: solução priorizada, piloto validado e implantação na operação | Design: projeto detalhado, protótipo, tolerâncias e testes funcionais | Improve ajusta um desenho existente; Design cria o desenho e as tolerâncias |
| Control: monitoramento estatístico, regra de reação e transferência | Verify: validação em piloto e em escala, com comprovação dos requisitos | Control sustenta ganho obtido; Verify prova a promessa antes de haver ganho |
Repare que a correspondência é boa nas três primeiras linhas e quebra nas duas últimas. Improve e Design não são a mesma operação em intensidades diferentes: são operações distintas. A definição de referência de cada fase está na descrição do DMAIC da ASQ.
Define, Measure e Analyze mudam de objeto, não de nome
No Define do DMAIC, o escopo é uma fronteira dentro de um fluxo existente, normalmente delimitada com SIPOC. No Define do DMADV, o escopo é o que o produto vai e não vai fazer, mais a janela de lançamento.
No Measure do DMAIC, o entregável é a linha de base do indicador, com o sistema de medição verificado. No Measure do DMADV, o entregável é uma lista priorizada de requisitos críticos traduzidos do cliente.
No Analyze do DMAIC, testa-se causa. No Analyze do DMADV, escolhe-se conceito, e a escolha costuma sair de uma matriz de decisão do tipo matriz esforço e impacto ou de uma matriz de Pugh com critérios ponderados.
Quem transporta as ferramentas de um método para o outro sem essa tradução produz um projeto que parece correto no relatório e não decide nada. É o erro mais comum de quem aprendeu um método e foi jogado no outro.
Design e Verify não têm equivalente no DMAIC
As duas últimas fases do DMADV são a parte que não se aprende fazendo DMAIC. Elas exigem competência de projeto, não competência de análise de processo.
A fase Design entrega o desenho detalhado: especificações, tolerâncias, materiais, sequência de operações, meios de controle. Ela decide a capabilidade futura do processo antes de a primeira peça existir.
Esse é o ponto que costuma passar batido. A tolerância definida no Design determina o teto de capabilidade da operação. Errar ali significa entregar à produção um processo que nunca vai atingir a meta.
A fase Verify prova que o objeto projetado cumpre os requisitos, em piloto e em escala. Ela não sustenta ganho, porque ainda não houve ganho: valida uma promessa antes de virar rotina.
Só depois do Verify o objeto entra na esfera do DMAIC. O processo passa a existir, começa a gerar histórico, e a partir daí a melhoria contínua tem insumo. Quem descreve as duas fases em detalhe é o artigo de DMADV.
O teste da capabilidade máxima: o critério mais objetivo
Existe um teste que resolve a maior parte dos casos duvidosos, e ele é aritmético. A pergunta que ele responde é: o processo atual, no melhor cenário concebível, alcança a especificação?
O melhor cenário concebível tem duas condições. A primeira é o processo perfeitamente centrado no alvo. A segunda é a ausência de causa especial, ou seja, apenas a variação natural do desenho atual atuando.
Nessas duas condições, o índice que descreve o teto é o Cp, calculado com a variação de curto prazo. O Cp é o valor que o Cpk atingiria se a média fosse deslocada exatamente para o centro da especificação.
A regra de decisão é curta. O Cpk nunca supera o Cp. Se o Cp já está abaixo da meta de capabilidade, nenhuma ação de centragem, ajuste ou eliminação de causa especial leva o processo à especificação.
Quando isso acontece, o caso deixa de ser de melhoria e passa a ser de reprojeto. O conceito e o cálculo dos dois índices estão detalhados em capabilidade do processo.
Exemplo numérico: quando a conta manda reprojetar
Considere uma operação de usinagem com especificação de diâmetro entre 19,90 mm e 20,10 mm, o que dá uma tolerância total de 0,20 mm. A meta interna de capabilidade é Cpk de 1,33.
O histórico de seis meses mostra média de 20,030 mm e desvio-padrão de curto prazo de 0,048 mm, estimado dentro de subgrupos racionais. A produção é de 120.000 peças por mês, com custo de refugo de R$ 12,00 por peça.
| Grandeza calculada | Valor | Como se obtém | O que ela diz |
|---|---|---|---|
| Cp, teto de capabilidade | 0,69 | 0,20 dividido por seis vezes 0,048 | Teto do processo com o desenho atual, já centrado |
| Cpk atual | 0,49 | Menor entre 0,07 e 0,13, cada um dividido por três vezes 0,048 | Situação de hoje, descentrada para cima |
| Refugo atual | 75.755 ppm | Área fora dos dois limites com média em 20,030 | 7,58 por cento da produção, ou 9.091 peças por mês |
| Refugo no melhor caso | 37.221 ppm | Área fora dos dois limites com média em 20,000 | 3,72 por cento, ou 4.467 peças por mês |
| Refugo na meta Cpk 1,33 | 66 ppm | Área fora com Cpk de 1,33 e processo centrado | Cerca de 8 peças por mês, o alvo contratado |
| Desvio-padrão exigido pela meta | 0,0251 mm | 0,20 dividido por seis vezes 1,33 | Exige reduzir a variação em 47,8 por cento |
A leitura é direta. Centrar o processo é uma ação legítima de DMAIC e economiza R$ 55.490 por mês, porque o refugo cai de 9.091 para 4.467 peças. É um bom projeto e é insuficiente.
O que o exemplo prova e o que ele não prova
Mesmo perfeitamente centrado, o processo ainda entrega 4.467 peças fora da especificação por mês, contra as 8 peças que a meta de Cpk 1,33 permite. A diferença é de cerca de 563 vezes.
A perda residual anual, no melhor cenário possível do desenho atual, fica em R$ 643.176. Esse é o custo de manter um processo que não comporta a especificação, mesmo depois de um DMAIC bem executado.
Para chegar à meta, o desvio-padrão precisa cair de 0,048 mm para 0,0251 mm. Reduzir a variação natural em quase metade não é ajuste de parâmetro: é outra máquina, outra fixação, outro conceito de operação.
O que o exemplo prova é que o teto existe e é calculável antes de o projeto começar. O que ele não prova é que todo Cp baixo exige DMADV completo, e essa distinção aparece mais adiante.
Os gatilhos objetivos de escolha, em uma tabela
A tabela a seguir troca a pergunta subjetiva por sinais verificáveis. Cada linha é um gatilho que pode ser checado com documento, dado ou cálculo, sem depender de opinião.
| Sinal observado no caso | Verificação objetiva | Método indicado | Risco de escolher o outro |
|---|---|---|---|
| Processo roda e tem histórico do indicador | Série com dezenas de observações e origem rastreável | DMAIC | DMADV gasta meses reprojetando o que um ajuste resolveria |
| Produto ou processo ainda não existe | Não há saída real nem registro de indicador | DMADV | DMAIC trava no Measure por falta de dado de processo |
| Cp de curto prazo abaixo da meta de capabilidade | Cálculo do Cp com sigma dentro de subgrupos | DMADV ou reprojeto de engenharia | DMAIC otimiza um desenho que não alcança a meta no melhor caso |
| Meta exige desempenho fora do histórico já alcançado | Melhor resultado histórico ainda distante da meta | DMADV | DMAIC entrega ganho real e não fecha o contrato do projeto |
| Requisito novo de cliente sem processo correspondente | Requisito crítico sem operação que o produza hoje | DMADV | DMAIC melhora o processo errado, porque o certo não existe |
| Causa conhecida e desenho comporta a meta | Cp acima da meta e causa já evidenciada | Ação direta ou DMAIC curto | DMADV cria custo de projeto sem necessidade |
| Processo existe, mas será descontinuado em breve | Decisão de descontinuação já formalizada | Nenhum dos dois | Qualquer projeto desperdiça recurso em ativo de saída |
A terceira linha é a que mais muda decisão na prática. Ela é a única que exige cálculo, e é justamente por isso que quase ninguém a verifica antes de abrir o projeto.
VOC e CTQs: o insumo que o DMADV não dispensa
No DMAIC, a voz do cliente entra na fase Define para justificar a meta e sai de cena. A meta costuma vir de um indicador já existente, e o projeto trabalha contra esse indicador até o fim.
No DMADV, a voz do cliente é o insumo principal, e ocupa a fase Measure inteira. Sem ela, não existe requisito, e sem requisito não existe critério para escolher conceito no Analyze nem para validar no Verify.
O trabalho tem duas etapas obrigatórias. A primeira é a coleta estruturada da voz do cliente, com fonte identificada e registro literal. A segunda é a tradução dessa voz em características críticas para a qualidade, os CTQs.
- Necessidade declarada. O que o cliente diz, na linguagem dele, sem interpretação da equipe.
- Característica crítica. A grandeza técnica que representa aquela necessidade e pode ser medida em peça ou em serviço.
- Especificação. O valor alvo e os limites aceitáveis da característica, que serão perseguidos no Design.
- Meio de verificação. Como a característica será medida no Verify, com o método e o instrumento definidos.
Métodos estruturados de escuta estão reunidos no acervo de escuta do cliente da ASQ, e todos eles servem ao mesmo fim: sair da opinião e chegar ao requisito.
Um DMADV que pula essa tradução entrega um projeto bonito sem critério de aceitação. No Verify, a discussão vira gosto, porque nunca se escreveu o número que o projeto tinha que alcançar.
DFMEA contra FMEA de processo: objetos diferentes
Os dois métodos usam análise de modos de falha, e usam versões diferentes dela. Confundi-las é um dos erros técnicos mais frequentes em projetos de DMADV conduzidos por gente formada em DMAIC.
O FMEA de processo analisa uma operação que existe e pergunta como ela pode falhar na execução. Ele trabalha com etapas reais, com histórico de ocorrência e com controles que já estão instalados.
O DFMEA, o FMEA de projeto, analisa o desenho e pergunta como o produto pode falhar em uso. Ele trabalha com funções, requisitos e interfaces, antes de existir operação, e a detecção é feita por ensaio, não por inspeção.
A consequência prática é que a coluna de ocorrência muda de origem. No FMEA de processo, ela vem de dado histórico. No DFMEA, ela vem de conhecimento de engenharia, ensaio acelerado ou dado de produto similar.
Quem quiser ver a estrutura preenchida encontra o método geral em FMEA e um formulário completo em exemplo de FMEA preenchido, lembrando que a versão de projeto troca etapa por função.
Por que o DMADV é mais caro, mais longo e mais arriscado
A diferença de custo entre os dois não é de escala: é de natureza. O DMAIC trabalha sobre ativo existente, com dado de graça, e seu maior custo é hora de belt. O DMADV consome protótipo, ensaio, ferramental e tempo de engenharia.
| Dimensão do projeto | Comportamento no DMAIC | Comportamento no DMADV | Origem da diferença |
|---|---|---|---|
| Duração típica | Quatro a seis meses | Nove a vinte e quatro meses | Ciclos de protótipo e ensaio não comprimem |
| Fonte do dado | Histórico do processo, disponível sem custo | Dado gerado por ensaio e protótipo, pago por unidade | Não existe processo para fornecer dado |
| Ponto de maior incerteza | Qual é a causa raiz do desvio | Se o conceito escolhido funciona em escala | Um investiga o passado, o outro aposta no futuro |
| Momento em que o erro aparece | No Improve, quando o ganho fica abaixo do previsto | No Verify, depois de todo o investimento feito | A validação vem no fim do gasto, não no meio |
| Custo de reverter | Baixo, a solução é retirada e o processo volta | Alto, ferramental e desenho já foram pagos | O reprojeto compromete ativo físico |
| Ganho esperado | Percentual sobre um patamar conhecido | Desempenho novo, sem patamar de comparação | Não há linha de base para medir o ganho |
A linha do momento do erro é a mais dura. No DMAIC, um erro de hipótese custa semanas. No DMADV, um erro de conceito só aparece no Verify, quando o ferramental já foi comprado.
Quem conduz cada um e por que isso muda o resultado
O DMAIC é conduzido por Green Belt ou Black Belt, com patrocínio de um champion e participação do dono do processo. A competência central é estatística aplicada a processo em operação.
O DMADV é conduzido por um time de projeto, liderado por engenharia de produto ou de processo, com um Black Belt no papel de método. A competência central é projeto, não análise.
Essa diferença de perfil explica boa parte dos fracassos. Belt sem engenharia de produto conduz um DMADV que vira um DMAIC longo, cheio de análise e pobre de decisão de desenho.
O inverso também acontece. Engenharia sem método conduz um projeto que pula a tradução dos requisitos e chega ao Verify sem critério de aceitação escrito. Os dois papéis são necessários e nenhum substitui o outro.
A zona cinzenta: o processo existe, mas está muito ruim
O caso difícil não é o processo inexistente nem o processo saudável. É o processo que existe, roda mal, tem dado ruim e faz o time se perguntar se não sai mais barato começar do zero.
A tentação de reprojetar é forte e costuma ser errada. Processo ruim com Cp acima da meta precisa de centragem e padronização, não de desenho novo.
O critério que separa os dois casos é o mesmo teste da capabilidade máxima. Calcule o Cp com o sigma de curto prazo. Se o teto comporta a meta, o problema é de condução; se não comporta, é de desenho.
Há um segundo critério útil quando o dado é fraco demais para o cálculo. Pergunte qual foi o melhor desempenho já registrado em qualquer período do histórico, ainda que curto e não explicado.
Se esse melhor desempenho histórico já supera a meta, o desenho comporta. O trabalho é descobrir o que acontecia naquele período e tornar aquilo estável, e isso é DMAIC com teste de hipóteses no Analyze.
DFSS: o guarda-chuva do qual o DMADV é uma das rotas
O DMADV não é sinônimo de Design for Six Sigma, embora seja tratado assim com frequência. O DFSS é a abordagem; o DMADV é um dos roteiros que a implementam, e não é o único.
Existem outros roteiros, com ênfases distintas. O IDOV é mais próximo de engenharia de produto, o DMADOV insere uma otimização entre o Design e o Verify, e o DMEDI aparece em serviços.
Escolher entre roteiros de DFSS é decisão de segunda ordem. A decisão de primeira ordem continua sendo DMAIC contra DFSS, ou seja, melhorar contra projetar, e essa se resolve pela existência da linha de base.
Na maior parte das empresas brasileiras, o DMADV é a rota de DFSS ensinada nas formações de belt, e é a que se integra melhor ao restante do Lean Seis Sigma já implantado.
Quando o DMADV é exagero e um projeto de engenharia resolve
Nem todo processo novo justifica um DMADV. O método carrega rigor estatístico, rituais de fase e documentação pesada, e esse custo só se paga em condições específicas.
O DMADV se justifica quando três condições aparecem juntas. Os requisitos do cliente são incertos ou conflitantes, o desempenho exigido é apertado, e o custo de errar o conceito é alto o suficiente para pagar a validação formal.
- Requisito claro e único. Se o cliente entregou a especificação pronta e ela não é ambígua, a fase Measure do DMADV perde a maior parte do seu valor.
- Tecnologia conhecida. Replicar uma linha que já existe em outra planta é engenharia de implantação, não projeto novo.
- Tolerância folgada. Quando a especificação é larga em relação à variação típica da tecnologia, o rigor de capabilidade do DFSS é excesso.
- Investimento baixo e reversível. Se errar custa pouco e o ajuste é rápido, testar sai mais barato que projetar formalmente.
Nesses casos, um projeto de engenharia comum com cronograma, requisitos escritos e um DFMEA resolve. Chamar isso de DMADV não melhora o resultado e adiciona cerimônia que ninguém vai cumprir até o fim.
Os erros de escolha mais caros, dos dois lados
A escolha errada tem dois sentidos, e eles falham de formas diferentes. Conhecer o padrão de falha de cada um ajuda a reconhecer o erro antes de ele consumir o orçamento inteiro.
O erro mais caro é aplicar DMAIC onde cabia reprojeto. Ele não falha de forma visível: entrega ganho real e encerra abaixo da meta, meses depois, com o teto intacto.
O segundo erro é aplicar DMADV onde cabia DMAIC. Esse falha de forma barulhenta. O time reprojeta o que um ajuste de centragem resolveria, e o custo de ferramental aparece no orçamento para quem quiser ver.
- Projeto de melhoria aberto sem cálculo prévio do Cp de curto prazo, por falta de hábito e não por falta de dado.
- Meta de projeto definida por negociação comercial, sem confronto com o teto técnico do desenho atual.
- Reprojeto iniciado porque o processo parece ruim, sem verificar se o desenho comporta a meta.
- DMADV conduzido sem tradução da voz do cliente, o que deixa o Verify sem critério de aceitação.
- Projeto encerrado sem plano de controle, o que devolve o ganho ao patamar anterior em poucos meses.
O padrão comum entre eles é a ausência de um teste objetivo no início. Uma tarde de cálculo evita meses de projeto no caminho errado, e ainda produz o argumento para convencer o patrocinador.
O roteiro de decisão, em quatro passos
O roteiro abaixo fecha a escolha em quatro passos, na ordem de execução. Os quatro juntos cabem em duas semanas de trabalho.
- Verifique a existência. O processo roda hoje e produz saída real? Se não, a decisão está tomada e o caminho é DMADV. Se sim, siga.
- Levante a linha de base. Reúna a série histórica do indicador crítico e confirme a origem do dado. Se a série for curta, dimensione a coleta com tamanho de amostra antes de concluir qualquer coisa.
- Aplique o teste da capabilidade máxima. Calcule o Cp com o sigma de curto prazo e compare com a meta. Cp abaixo da meta indica reprojeto; Cp acima indica melhoria.
- Confirme pelo melhor histórico. Se algum período já superou a meta, o desenho comporta, e o caso é de DMAIC mesmo com o processo ruim hoje.
Para ver o DMAIC executado ponta a ponta com entregáveis por fase, vale o exemplo de DMAIC. Para a escolha entre métodos em um contexto industrial mais amplo, o mapa está em qual metodologia usar na indústria.
A comparação com o ciclo de rotina fica em PDCA ou DMAIC, e os tropeços típicos de programa estão reunidos em erros na implantação de Lean Seis Sigma.
A decisão cabe em uma frase. Se existe linha de base e o teto comporta a meta, é DMAIC. Se não existe processo, ou se o teto não comporta a meta, é DMADV. O resto é preferência, e preferência não decide projeto.
