DMAIC: As 5 Fases do Ciclo de Melhoria Six Sigma (Com Ferramentas e Exemplos)

A maioria dos problemas de processo é resolvida da mesma forma: alguém percebe um defeito, uma reunião acontece e uma correção é implementada. Semanas depois, o defeito voltou. Isso não é má sorte -- é o que acontece quando você pula direto para as soluções antes de medir o que está realmente quebrado ou provar o que o causou. O DMAIC quebra esse ciclo ao exigir rigor em cada etapa antes que você seja autorizado a tocar no processo.
O DMAIC (pronunciado "duh-may-ick") é a metodologia de melhoria estruturada no coração do Six Sigma. Cada letra é uma porta que você precisa atravessar: Define o problema, Measure o estado atual, Analyze a causa raiz, Improve com uma solução testada e Control os ganhos para que não se deteriorem. Pule uma fase e todo o projeto fica em risco.
O Que É o DMAIC?
O DMAIC é o ciclo de melhoria de 5 fases que forma a espinha dorsal operacional do Six Sigma. O acrônimo significa Define (Definir), Measure (Medir), Analyze (Analisar), Improve (Melhorar) e Control (Controlar). Ele oferece às equipes um roteiro repetível e orientado por dados para reduzir defeitos, diminuir o tempo de ciclo e consolidar os ganhos de qualidade.
O método foi codificado em meados da década de 1980 na Motorola pelo engenheiro de confiabilidade Bill Smith e pelo estatístico Mikel Harry como parte de seu framework Six Sigma original. A Motorola precisava de uma forma estruturada de levar a qualidade a 3,4 defeitos por milhão de oportunidades (DPMO) em suas linhas de fabricação. O DMAIC foi o veículo. Quando Jack Welch adotou o Six Sigma em toda a GE em 1995, o DMAIC se tornou o playbook padrão de melhoria para grandes empresas em todo o mundo, espalhando-se da fabricação para saúde, finanças, logística e software.
O que separa o DMAIC de frameworks mais simples é sua insistência na medição antes da ação. Você não define uma causa raiz até ter dados. Você não testa uma solução piloto até ter confirmado a causa raiz estatisticamente. Você não declara vitória até que um sistema de controle esteja em vigor. Essa sequência é ao mesmo tempo seu ponto forte e a razão pela qual os projetos travam quando as equipes tentam encurtá-la.
Fatos Relevantes
- A Motorola, que originou o Six Sigma e o DMAIC em 1986, creditou a metodologia com mais de US$ 17 bilhões em economias acumuladas até 2006, segundo dados citados pela American Society for Quality (ASQ).
- A GE reportou US$ 10 bilhões em benefícios acumulados do Six Sigma entre 1996 e 2001 em seus relatórios anuais, tornando-se o estudo de caso corporativo mais citado para o DMAIC em escala.
- O Six Sigma e o Lean Six Sigma consistentemente figuram entre as certificações de processo mais buscadas em fabricação e operações, com centenas de milhares de certificações Belt ativas rastreadas pela International Association for Six Sigma Certification (IASSC).
As 5 Fases do DMAIC Explicadas

O DMAIC é sequencial por design. Cada fase produz um resultado que autoriza a entrada na próxima. Equipes que executam fases em paralelo ou pulam a fase de medição quase sempre acabam resolvendo o problema errado. Veja o que acontece em cada uma.
D - Define
A fase Define responde a uma pergunta: qual problema estamos realmente resolvendo e vale a pena resolvê-lo? As equipes produzem um termo de abertura do projeto (project charter), um documento de uma página que descreve o problema, o objetivo, o escopo, o business case e os membros da equipe. Sem ele, o escopo do projeto expande e os sponsors perdem o interesse.
As outras duas ferramentas fundamentais do Define são o diagrama SIPOC (Suppliers, Inputs, Process, Outputs, Customers) e a pesquisa de Voice of the Customer (VOC). O SIPOC oferece a todos uma visão de alto nível do processo antes de alguém se aprofundar nos detalhes. O VOC traduz reclamações de clientes, pesquisas e tickets de suporte em requisitos de qualidade mensuráveis. Você não consegue definir "defeito" até saber o que o cliente realmente valoriza. O Define termina quando a equipe concorda com a declaração do problema e as métricas de sucesso, e o sponsor aprova o termo de abertura.
M - Measure
O Measure estabelece a linha de base. Antes de melhorar qualquer coisa, você precisa saber o quão ruim é o estado atual e se seu sistema de medição é confiável o suficiente para rastrear a melhoria. O principal resultado é o índice de capacidade do processo (Cp e Cpk), que indica o quão bem o processo atual se encaixa dentro dos limites de especificação do cliente.
O plano de coleta de dados documenta exatamente quais dados você coletará, como e de onde. Sem ele, as equipes acabam com conjuntos de dados inconsistentes que tornam a análise impossível. Muitas equipes também realizam uma Measurement System Analysis (MSA), que verifica se os instrumentos, softwares ou avaliadores humanos usados para coletar dados são confiáveis: um sistema de medição com alta variação pode fazer um processo capaz parecer defeituoso. O Measure termina quando você tem uma linha de base confirmada: uma taxa de defeitos, um tempo de ciclo, uma taxa de erros, seja lá o que o termo de abertura se comprometeu a melhorar.
A - Analyze
O Analyze é onde a equipe vai de "aqui estão os dados" para "aqui está o porquê". O objetivo é confirmar a causa raiz com evidências, não apenas fazer um brainstorming de teorias plausíveis. As duas ferramentas de partida mais comuns são o diagrama de Ishikawa (também chamado de diagrama de causa e efeito) e a técnica dos 5 Whys, que aprofunda a análise do sintoma à causa sistêmica perguntando "por quê" repetidamente.
Mas o Analyze não se limita a ferramentas qualitativas. As equipes usam teste de hipóteses: testes t, testes qui-quadrado, análise de regressão, para confirmar quais causas suspeitas são estatisticamente significativas. É isso que separa o DMAIC da resolução de problemas baseada em intuição: você não pode avançar para o Improve até demonstrar, com dados, que remover a causa raiz identificada fecharia a lacuna entre sua linha de base atual e sua meta. O Analyze termina com uma causa raiz validada e uma declaração clara de quanto do problema ela explica.
I - Improve
O Improve projeta, testa e seleciona a solução. A equipe gera múltiplas opções de solução contra a causa raiz confirmada, depois usa uma matriz de priorização ou um FMEA (Failure Mode and Effects Analysis) para avaliar risco, custo e impacto antes de se comprometer com um piloto. O Design of Experiments (DOE) é a ferramenta estatística de escolha quando múltiplos fatores interagem e você precisa encontrar a combinação ideal de configurações sem testar todas as permutações.
O piloto é inegociável. Um teste controlado em pequena escala valida que a solução proposta realmente move a métrica antes de a equipe investir em uma implantação completa. Os resultados do piloto são comparados à linha de base da fase Measure: a taxa de erros caiu? O tempo de ciclo diminuiu? Se a melhoria for confirmada, a equipe documenta o novo processo e prepara a transferência. O Improve termina quando os dados do piloto provam que a solução funciona.
C - Control
O Control transforma um sucesso de piloto em uma mudança permanente de processo. O principal resultado é um plano de controle, um documento que define o que monitorar, com que frequência, quem é o responsável e que ação tomar se a métrica sair dos limites aceitáveis. Sem um plano de controle, os projetos de melhoria se deterioram: a equipe muda, os atalhos voltam e a taxa de defeitos sobe.
Os gráficos de SPC (Statistical Process Control) são a ferramenta de monitoramento padrão. Eles plotam a métrica ao longo do tempo com limites de controle, tornando visualmente óbvio quando o processo está derivando versus quando está mostrando variação normal. Os materiais de treinamento e os SOPs (standard operating procedures) atualizados, veja procedimentos operacionais padrão, formalizam a nova forma de trabalhar. O projeto se encerra formalmente quando o dono do processo aceita a responsabilidade de manter os ganhos e o sponsor aprova os resultados finais. O Control é a fase em que a maioria das equipes investe menos, e é a razão pela qual a maioria dos ganhos ainda está lá dois anos depois, ou não.
Ferramentas Usadas em Cada Fase do DMAIC

Cada fase tem uma lista curta de ferramentas preferidas. Você não usará todas em todos os projetos, mas conhecer o menu permite escolher a ferramenta certa para a evidência de que você precisa.
| Fase | Ferramentas comuns | Resultado / Artefato |
|---|---|---|
| Define | Termo de abertura do projeto, diagrama SIPOC, análise VOC, mapa de stakeholders, árvore CTQ | Termo de abertura assinado, limite de escopo, métricas de sucesso |
| Measure | Plano de coleta de dados, mapa de processos, MSA (Gauge R&R), gráficos de controle, capacidade do processo (Cp/Cpk) | Taxa de defeitos ou tempo de ciclo de linha de base, sistema de medição validado |
| Analyze | Diagrama de Ishikawa, 5 Whys, gráfico de Pareto, teste de hipóteses, regressão, gráfico de dispersão | Causa(s) raiz confirmadas estatisticamente |
| Improve | Matriz de soluções, FMEA, DOE (Design of Experiments), plano piloto, análise de custo-benefício | Resultados do piloto, design otimizado do processo |
| Control | Gráficos SPC, plano de controle, RACI, SOPs atualizados, materiais de treinamento | Transferência ao dono do processo, métrica sustentada |
CTQ significa Critical to Quality: a tradução dos requisitos do cliente em especificações internas mensuráveis do processo. MSA significa Measurement System Analysis. FMEA significa Failure Mode and Effects Analysis. DOE significa Design of Experiments. SPC significa Statistical Process Control. RACI significa Responsible, Accountable, Consulted, Informed.
Exemplo Prático: Reduzindo Erros de Processamento de Faturas em uma Empresa B2B

Uma empresa de logística de médio porte, que chamaremos de FreightCo, tinha uma taxa de erros de 8% em faturas enviadas. O financeiro gastava aproximadamente 40 horas por mês em correções, e dois clientes haviam escalado disputas formais. O CFO patrocinou um projeto DMAIC com a meta de chegar abaixo de 1% de taxa de erros em um trimestre.
Define. O termo de abertura do projeto delimitou o problema às faturas B2B enviadas e processadas pelo ERP. O SIPOC mapeou o fluxo desde o recebimento do pedido de compra até a aprovação e o envio da fatura. Entrevistas de VOC com os dois clientes em disputa identificaram o tipo de erro: preços unitários incorretos aplicados às linhas de itens.
Measure. A equipe extraiu três meses de dados de faturas e confirmou a taxa de erros de 8,1% (412 erros em 5.087 faturas). Uma MSA executada no processo de revisão manual mostrou que os revisores discordavam sobre se uma discrepância de preço era um "erro" ou "arredondamento" em 18% das vezes: um problema do próprio sistema de medição, que a equipe resolveu restringindo a definição de erro antes de continuar. A capacidade do processo mostrou o processo de faturamento operando em aproximadamente 2,8 sigma.
Analyze. Um diagrama de Ishikawa gerou 11 causas candidatas nas categorias Pessoas, Processo, Sistemas e Dados. A análise dos 5 Whys nas três principais candidatas apontava repetidamente para um mesmo lugar: a tabela de dados mestre de fornecedores no ERP não tinha validação automatizada. Alterações de preço de fornecedores eram aplicadas manualmente, com atraso de dois a cinco dias em relação à data real da mudança. O teste de hipóteses confirmou que 73% das faturas com erro de preço haviam sido geradas durante a janela de atraso após uma mudança de preço de fornecedor.
Improve. A equipe delimitou duas soluções: (1) uma regra de validação automatizada que bloqueava a geração de fatura quando um preço de linha ficasse fora de uma faixa de tolerância específica por fornecedor, e (2) um SLA exigindo que mudanças de preço de fornecedor fossem registradas em até 24 horas. Eles realizaram um piloto de quatro semanas com a regra de validação ativa em um segmento de clientes. A taxa de erros para esse segmento caiu para 0,9%, dentro da meta de 1%. O FMEA confirmou que a regra não criaria falsos positivos acima de uma taxa aceitável.
Control. A regra de validação foi implementada em todas as contas. Um gráfico SPC mensal rastreando a taxa de erros em faturas foi atribuído ao gestor da equipe de Contas a Pagar (AP). O plano de controle definiu um gatilho de ação em 2%: se a taxa ultrapassasse esse limite, o protocolo de auditoria do cadastro de fornecedores disparava automaticamente. Seis meses após o encerramento, a taxa de erros se mantinha em 0,8%.
O projeto reduziu a carga de correções de 40 horas mensais para menos de 5, e as duas disputas de clientes foram resolvidas. Tempo total de execução do projeto: 11 semanas.
DMAIC vs PDCA vs DMADV
O DMAIC é um dos vários frameworks de melhoria iterativa. Os dois que você verá com mais frequência ao seu lado são o PDCA e o DMADV. Veja também nosso guia sobre otimização de processos para uma comparação mais ampla.
| Ciclo | Usado em | Melhor para | Fases |
|---|---|---|---|
| DMAIC | Six Sigma, Lean Six Sigma | Corrigir um processo existente quebrado usando análise estatística | Define, Measure, Analyze, Improve, Control |
| PDCA | Lean, melhoria contínua geral | Melhoria iterativa rápida, frequentemente em problemas mais simples ou com menos dados | Plan, Do, Check, Act |
| DMADV | Six Sigma (DFSS) | Projetar um processo ou produto totalmente novo do zero | Define, Measure, Analyze, Design, Verify |
A distinção central: o DMAIC corrige o que existe. O DMADV, às vezes chamado de DFSS (Design for Six Sigma), projeta algo novo. O PDCA é mais leve e rápido de ciclar; não exige teste de hipóteses estatístico, o que o torna acessível a equipes sem um Black Belt. Mas a velocidade do PDCA pode ser uma desvantagem em problemas complexos onde a causa raiz não é óbvia. Veja nosso artigo sobre PDCA para uma análise completa.
O DMAIC e a metodologia Lean são frequentemente combinados no Lean Six Sigma, que usa ferramentas Lean (value stream mapping, 5S, Kanban) nas fases Analyze e Improve ao lado do kit de ferramentas estatísticas do DMAIC. O resultado é um framework que ataca tanto o desperdício (domínio do Lean) quanto a variação (domínio do Six Sigma) ao mesmo tempo.
Quando Usar o DMAIC (e Quando Não Usar)
O DMAIC é uma ferramenta de precisão, não uma ferramenta universal. Usá-lo no problema errado desperdiça meses.
| Use o DMAIC quando... | Evite o DMAIC quando... |
|---|---|
| Um defeito ou taxa de erros recorrente tem impacto de negócio conhecido | O problema é completamente novo: use DMADV ou um design sprint |
| A causa raiz é genuinamente pouco clara e há dados disponíveis | Você precisa de uma correção em dias, não semanas: o PDCA ou um evento Kaizen rápido é mais ágil |
| A melhoria precisa ser estatisticamente comprovada, não apenas observada | O processo em si precisa ser redesenhado do zero |
| A liderança quer um registro de projeto rigoroso e auditável | A equipe não tem dados e não tem como coletá-los rapidamente |
| O processo cruza múltiplas equipes ou funções | O escopo é extremamente restrito e a correção já é óbvia |
Um evento Kaizen, um workshop focado de 3 a 5 dias, frequentemente é mais rápido para problemas nos quais a equipe já suspeita da causa raiz e apenas precisa agir. O DMAIC justifica seu custo quando o problema é crônico, a causa raiz é genuinamente ambígua e os riscos são altos o suficiente para justificar de seis a doze semanas de trabalho estruturado.
Erros Comuns que Comprometem Projetos DMAIC
- Pular o Measure para economizar tempo. Equipes que pulam de Define para Analyze com base na intuição chegam ao Analyze sem linha de base, sem definição confirmada de defeito e sem como provar que sua solução funcionou. O Measure é a fase mais pulada e a omissão mais consequente.
- Definir o problema como a solução. Um termo de abertura que diz "precisamos implementar o sistema X" não está definindo um problema: está pré-selecionando uma correção. O Define deve descrever a lacuna entre o desempenho atual e o desejado, não prescrever a resposta.
- Confundir correlação com causa raiz. Diagramas de Ishikawa e 5 Whys identificam candidatos. Testes de hipóteses os confirmam. Equipes que avançam para o Improve com base apenas em um brainstorming do diagrama de Ishikawa frequentemente descobrem que a correção não move a métrica.
- Subestimar recursos na fase Control. O Control recebe menos atenção e mais culpa pós-projeto. Sem plano de controle não há dono do processo. Sem dono do processo os ganhos se deterioram em seis meses.
- Escopo crescente após a assinatura do termo de abertura. Projetos DMAIC se expandem porque resolver um problema revela três outros. Mantenha o escopo definido no termo; abra projetos separados para os problemas adjacentes.
- Executar o DMAIC sem um Black Belt ou facilitador experiente. As ferramentas estatísticas no Analyze e Improve: teste de hipóteses, DOE, SPC, requerem treinamento. Equipes sem alguém que consiga executar a análise corretamente tendem a produzir gráficos que confirmam o que a equipe já acreditava.
Para uma visão mais ampla do business process management e de onde o DMAIC se encaixa no kit geral de ferramentas de melhoria, veja aquele artigo. E para se fundamentar nos conceitos básicos de gerenciamento de processos antes de executar um projeto DMAIC, vale ler aquela visão geral primeiro.
Perguntas Frequentes
O DMAIC é o mesmo que Six Sigma?
Não, mas são inseparáveis. O Six Sigma é a filosofia e metodologia geral de qualidade, com meta de 3,4 defeitos por milhão de oportunidades. O DMAIC é o roteiro específico de projeto usado para alcançar melhorias Six Sigma em processos existentes. Pense no Six Sigma como o destino e no DMAIC como a rota. O Six Sigma também inclui o DMADV para projetar novos processos e um sistema de certificação Belt (Branco, Amarelo, Verde, Preto, Master Black Belt) que define quem pode liderar projetos DMAIC em diferentes níveis de complexidade.
Quanto tempo dura um projeto DMAIC?
A maioria dos projetos DMAIC dura entre 3 e 6 meses, da assinatura do termo de abertura à transferência do Control. Projetos simples e bem delimitados em uma única equipe podem ser concluídos em 8 a 10 semanas. Projetos multifuncionais complexos, especialmente os que exigem DOE ou coleta extensa de dados, podem levar de 9 a 12 meses. As fases Measure e Analyze geralmente levam mais tempo porque a coleta de dados demora e o teste de hipóteses exige amostras grandes o suficiente para serem estatisticamente significativas. Apressar qualquer uma dessas fases é a razão mais comum pelo qual projetos DMAIC não conseguem sustentar seus ganhos.
O DMAIC pode ser usado sem certificação Six Sigma?
Sim, com ressalvas. As fases Define e Control são acessíveis a qualquer pessoa familiarizada com gerenciamento de projetos. A fase Measure requer familiaridade com estatística básica e análise de sistemas de medição. O Analyze, especialmente o teste de hipóteses e a regressão, genuinamente precisa de alguém com treinamento Green Belt ou Black Belt para ser executado corretamente. Muitas equipes conduzem o DMAIC com um facilitador certificado na função de liderança e membros não certificados contribuindo no Define e no Improve. Usar a estrutura do DMAIC sem o rigor estatístico no Analyze é melhor do que nenhuma estrutura, mas o risco é confirmar uma causa raiz que não está realmente gerando o defeito.
Qual é a diferença entre DMAIC e DMADV?
Ambos pertencem à família Six Sigma e compartilham as três primeiras fases (Define, Measure, Analyze). Eles divergem na quarta fase. A quarta fase do DMAIC é o Improve: você está corrigindo um processo que já existe. A quarta fase do DMADV é o Design: você está construindo algo novo. O DMADV termina com Verify em vez de Control, porque você está validando um novo design em relação aos requisitos, e não sustentando ganhos em um processo estabelecido. Use o DMAIC quando um processo está quebrado mas pode ser corrigido. Use o DMADV quando o processo precisa ser criado do zero, ou quando o DMAIC já foi aplicado e o processo ainda não consegue atender aos requisitos.
O DMAIC não é o caminho mais rápido para corrigir um problema de processo. Mas para defeitos crônicos e de alto impacto em que a causa raiz não é óbvia, é o mais confiável. Defina o que está quebrado antes de medi-lo. Meça antes de analisá-lo. Analise antes de melhorá-lo. Controle para que permaneça melhorado. Essa sequência é tediosa, disciplinada e funciona.
Para equipes que estão iniciando sua jornada de qualidade, a metodologia 5S é frequentemente um ponto de partida útil antes de um projeto DMAIC formal: ela estabiliza o ambiente de trabalho e torna a medição mais confiável.

Senior Operations & Growth Strategist
On this page
- O Que É o DMAIC?
- As 5 Fases do DMAIC Explicadas
- D - Define
- M - Measure
- A - Analyze
- I - Improve
- C - Control
- Ferramentas Usadas em Cada Fase do DMAIC
- Exemplo Prático: Reduzindo Erros de Processamento de Faturas em uma Empresa B2B
- DMAIC vs PDCA vs DMADV
- Quando Usar o DMAIC (e Quando Não Usar)
- Erros Comuns que Comprometem Projetos DMAIC
- Perguntas Frequentes
- O DMAIC é o mesmo que Six Sigma?
- Quanto tempo dura um projeto DMAIC?
- O DMAIC pode ser usado sem certificação Six Sigma?
- Qual é a diferença entre DMAIC e DMADV?