DMAIC e IA: o que a inteligência artificial faz em cada fase

O índice remissivo do meu livro tem uma entrada só de inteligência artificial, e ela aponta para a página 7. Página 7 é capítulo 1, o capítulo de mindset de melhoria. O capítulo 18, que descreve o DMAIC fase por fase, com fluxograma e perguntas de orientação em cada uma, não tem nenhuma. Escrevi os dois capítulos e fechei o manuscrito em outubro de 2024. A conversa sobre IA já estava em todo lugar, inclusive nas minhas turmas. Mesmo assim, na hora de montar o capítulo do DMAIC, não me ocorreu uma linha sobre o assunto. Nenhuma em que a tecnologia mudasse o que precisa estar provado. Na época aquilo foi decisão de sumário e eu não parei para pensar nela. Hoje eu leio a mesma escolha como resposta.

A pergunta que mais chega não é se a máquina substitui o método. É mais confusa que isso, e vem embrulhada em ferramenta. Alguém pede um projeto com inteligência artificial. O que está atrás do pedido é a vontade de pular a parte lenta. A parte lenta do DMAIC nunca foi escrever documento. Foi combinar o que conta como prova. Essa parte é a única do projeto inteiro que decide alguma coisa, e é justamente a que não dá para terceirizar.

Aqui eu passo pelas cinco fases do DMAIC e faço a mesma pergunta em cada uma. O que a máquina entrega neste ponto? E o que continua sendo decisão de gente? É um mapa de largura, feito para você localizar o seu caso antes de descer no detalhe de uma fase só. Você vai ver a tabela fase a fase e os erros que mais custam. Depois, o que conferir em cada saída gerada e o que muda no DMAIC Ágil.

O que muda num projeto de melhoria quando a máquina entra

Quase tudo que ficou mais barato num projeto DMAIC no último ano é trabalho de descrever. Transcrever entrevista, resumir reclamação de cliente, escrever procedimento, montar o rascunho de um relatório, gerar o código de um gráfico. Era isso que consumia noite de analista, e hoje consome minutos.

O que não ficou mais barato é o trabalho de concordar. Concordar sobre qual problema vale o trimestre. Sobre qual medida é confiável. Sobre qual causa foi comprovada. E sobre quem responde pelo indicador daqui para frente. Nenhuma dessas quatro coisas é dificuldade de redação.

O DMAIC, que é o motor de projeto do Lean Seis Sigma, nasceu para resolver a segunda lista, não a primeira. O método existe por um motivo simples. Um grupo de pessoas competentes olhando o mesmo processo chega a conclusões diferentes. Alguém precisa arbitrar isso com dado em vez de hierarquia. Uma ferramenta que escreve rápido não arbitra nada.

Por isso a resposta curta deste artigo é chata e libertadora ao mesmo tempo. A máquina reduz o custo de chegar ao ponto da decisão dentro do DMAIC, e não reduz a decisão. Quem entende isso ganha semanas de projeto, e semana ganha no começo é combustível para o resto do caminho. Quem não entende troca a semana de análise por uma semana de conferência de texto que ninguém sabe de onde veio.

Vale dizer o que este texto não é. Não é comparação de ferramenta, não recomenda produto e não promete número de ganho. É a divisão de trabalho entre o DMAIC e um assistente que produz rascunho em segundos. Um lado tem quarenta anos de bibliografia acumulada, catalogada por entidades como a American Society for Quality, e o outro tem três.

As cinco fases do DMAIC e o corte, lado a lado

A tabela abaixo é o artigo inteiro em uma tela. Cada linha é uma fase do DMAIC. A coluna do meio traz o que já dá para delegar hoje sem culpa. A da direita traz o que continua atravessando a mesa de alguém.

Repare que a coluna do meio é toda de tarefa que se produz: transcrever, montar, gerar, redigir. A da direita é toda de compromisso que se assume: assinar, aprovar, responder. Essa é a fronteira, e ela não é uma opinião minha sobre tecnologia. É a diferença entre produzir um artefato e assumir a consequência dele.

Um detalhe da figura importa mais do que parece. A linha não sobe nem desce ao longo do método. Não existe fase em que a parte de baixo fique vazia, nem fase em que ela ocupe tudo. Todo trecho do caminho tem produção e tem compromisso, em proporções diferentes.

Definir: ler a voz do cliente é rápido, escolher o problema não é

Nenhuma fase mudou tanto de custo quanto esta. A voz do cliente chegava em planilha de reclamação, transcrição de call center e formulário aberto. Alguém passava dias lendo aquilo para tirar cinco temas. Hoje esse agrupamento sai em uma tarde, com a citação original de cada grupo do lado.

O mesmo vale para o desenho de fronteira do processo. Um SIPOC rascunhado a partir da descrição de quem opera chega pronto para ser corrigido em reunião. Antes ele saía da reunião, e não para ela. A diferença de energia na sala é grande, porque corrigir é mais fácil do que começar do zero.

Só que o entregável da primeira fase do DMAIC não é o agrupamento. É o contrato do projeto, com escopo, equipe, cronograma e meta numérica. Thomas Pyzdek resume o trabalho da definição como determinar quais oportunidades vão dar o maior retorno pelo esforço. Retorno pelo esforço é alocação de recurso escasso. Alocação de recurso escasso é decisão de dono.

Tem um risco específico aqui, e ele é silencioso. Um agrupamento automático organiza o que foi escrito, e quem reclama por escrito não é uma amostra do seu cliente. É a amostra que teve paciência de escrever. Um tema pode aparecer grande no resumo e ser pequeno no faturamento, ou o contrário.

A regra prática que eu uso é simples. Rascunho automático entra na definição do DMAIC pela porta da frente. Meta entra pela porta de quem responde pelo resultado, e ela nunca sai de um resumo.

Medir: a base sai limpa em uma tarde e ainda pode não prestar

A medição do DMAIC existe para produzir uma linha de base do processo, e não para produzir gráfico. Essa distinção é a que mais se perde quando a produção de gráfico fica gratuita. Dá para gerar quarenta visualizações da mesma base numa manhã, e nenhuma delas responder se a base presta.

O trabalho que a máquina faz bem aqui é grande, e vale dizer em voz alta. Ela monta o plano de coleta, padroniza rótulo de categoria e acha registro duplicado. Propõe cortes de estratificação. E escreve o código do gráfico que você descreveu em português. Isso era metade do calendário desta fase.

O que ela não faz é o MSA. Conferir se dois inspetores medindo a mesma peça chegam ao mesmo valor exige as peças, os inspetores e o instrumento. É trabalho de chão, descrito em detalhe no handbook de estatística do NIST, e ele decide se o resto da fase significa alguma coisa. Muito problema desaparece quando se descobre que o que mudou foi quem media.

Pyzdek insiste em um ponto que combina bem com este momento: informação confiável vem de mais de uma fonte confiável. Uma saída gerada é sempre uma fonte só, e ela costuma ter a aparência de várias, porque escreve com segurança. Aparência de consenso não é consenso.

Se a sua capabilidade foi calculada em cima de uma base que ninguém auditou, o número é bonito e não é verdadeiro. Na segunda fase o ceticismo tem endereço: pergunte de onde veio cada coluna antes de perguntar o que o gráfico mostra.

Analisar: causa sugerida é hipótese, e hipótese continua precisando cair

Aqui aparece a tentação mais cara do assunto inteiro. Peça uma lista de causas prováveis para um problema descrito em três linhas. Vem uma lista boa, organizada por categoria, plausível do começo ao fim. Parece um Ishikawa pronto, e em certo sentido é.

Ela é o resultado do pensamento divergente. Pyzdek separa a análise em dois passos, e eu reproduzi essa separação no capítulo 18, na página 147. É a etapa em que se lança a rede mais larga possível de alternativas. Essa etapa ficou barata. A etapa seguinte, a convergente, é onde o DMAIC acontece. Ela custa exatamente o mesmo de antes: ir ao processo e derrubar as candidatas com fato.

A comprovação tem forma conhecida. Pareto para dizer onde a perda mora. 5 Porquês para descer da ocorrência à condição que a permite. teste de hipótese para dizer se a diferença que você viu resiste ao acaso. Nada disso é substituível por um texto bem escrito sobre causas.

Existe aqui um efeito perverso com literatura de fator humano, e ele é mais velho que a IA generativa. Parasuraman e Manzey revisaram em 2010 o que chamam de viés de automação. Quando a máquina apresenta uma resposta pronta, o operador confere menos, e não mais. Uma lista plausível encurta a discussão em vez de abrir. O grupo escolhe a causa que soa melhor escrita e vai direto ao plano de ação. A análise vira uma rodada de opinião com ata bonita. O DMAIC foi criado para impedir exatamente isso.

O uso honesto é o inverso. Use a lista para descobrir a causa que ninguém tinha lembrado. Some ela às que a equipe levantou. Trate todas do mesmo jeito: nenhuma passa sem número. Origem da hipótese não muda o padrão de prova.

Melhorar: vinte alternativas em minutos, e o preço todo mora na escolha

A fase de melhoria do DMAIC pede proposição, priorização e execução de soluções para cada causa comprovada. A primeira das três ficou trivial. Vinte alternativas para um gargalo saem em minutos, com os prós e contras já escritos. Isso é útil quando a equipe está travada na mesma ideia há duas reuniões.

A priorização é outra história, porque ela não é uma conta. Uma matriz de esforço e impacto preenchida sem a agenda da manutenção é um exercício. Sem o orçamento do trimestre e a política de risco da casa, também. Os pesos dessa matriz são a estratégia da empresa escrita em números, e eles não estão em lugar nenhum que uma ferramenta possa ler.

Tem uma classe de solução que merece atenção redobrada: a que a própria máquina propõe automatizar. Ela é a mais fácil de escrever e a mais difícil de reverter. Automatizar um processo ruim entrega o processo ruim mais rápido, e é a definição clássica de desperdício com verniz novo. Michael Hammer escreveu isso na Harvard Business Review em 1990, no artigo que ficou conhecido pela ordem de não automatizar e sim eliminar. O instrumento mudou e o argumento não. Tecnologia por cima de processo que ninguém redesenhou preserva o desperdício e ainda encarece a manutenção dele.

A execução, por outro lado, ganhou um ajudante de verdade. Redigir o padrão, escrever o roteiro de treinamento e montar a comunicação da mudança é trabalho de texto. O material do piloto também. É volumoso, repetitivo e importante. Delegue sem cerimônia e revise com atenção, porque o que vai para a parede da área tem seu nome.

O teste do piloto continua igual. Mede antes, mede depois, compara série contra série e não ponto contra ponto. É a parte que ninguém consegue acelerar sem trapacear.

Controlar: vigiar é tarefa de máquina, reagir é cargo de gente

A etapa de controle é a mais crítica de um projeto DMAIC, e a razão é humana antes de ser técnica. O desafio está no envolvimento e no treinamento das pessoas em hábitos novos. É aí que o ganho evapora, quando a rotina antiga volta e ninguém está mais olhando.

Vigilância contínua é o caso mais limpo de delegação do artigo inteiro. Uma carta de controle lida por um sistema que avisa no minuto do desvio ganha fácil. A alternativa é uma carta impressa que alguém olha na segunda de manhã. Aqui a máquina ganha de lavada, porque não pisca.

O que o aviso não traz é a resposta. Um plano de controle completo diz quem olha, com que limite, com que frequência e o que faz quando sai da faixa. As três primeiras colunas podem ser automáticas. A quarta é uma pessoa com nome, telefone e autoridade para parar alguma coisa.

Detecção sem reação combinada produz um efeito que tem nome e tem norma. Gestão de alarme na indústria de processo é assunto da ANSI/ISA-18.2. O guia EEMUA 191 trata do mesmo problema: operador com alarme demais deixa de responder a todos. Um aviso gerado automaticamente entra na mesma conta. O aviso vira ruído, alguém desliga a notificação, e o processo passa a ter um sistema de monitoramento que ninguém escuta. Isso é pior do que não ter, porque dá sensação de cobertura.

Vale a mesma disciplina do encerramento de sempre: se o resultado não veio como esperado, ajusta. Se veio, vira padrão. Essa frase é mais velha que o DMAIC e continua sendo a parte que mais gente pula.

A escada da evidência, e onde cada coisa entra nela

Tem um jeito de olhar isso que resolve a maioria das dúvidas de caso concreto. Pense em degraus de evidência, do mais fraco para o mais forte. Depois pergunte em qual degrau a saída que você tem nas mãos está de verdade.

O primeiro degrau é opinião: alguém acha, por experiência ou por leitura. O segundo é dado observado: existe registro, e ninguém auditou o registro. O terceiro é dado conferido: o sistema de medição foi validado e a base foi tratada. O quarto é causa comprovada: a hipótese resistiu a um teste que podia ter derrubado ela.

Uma saída gerada entra sempre no primeiro ou no segundo degrau, e escreve como se estivesse no quarto. O degrau não é opinião minha sobre a ferramenta. Ele sai da definição de cada um: enquanto ninguém foi ao processo conferir o registro, não existe o que ponha a frase no terceiro. Vale igual para frase minha, de consultor experiente ou de máquina. Não é a ferramenta que engana; é a fluência do texto que empresta autoridade que o conteúdo não tem.

A escada também explica por que a análise é a fase mais perigosa do DMAIC. Ela é a única em que a diferença entre o segundo e o quarto degrau muda a solução inteira. E é a única em que um texto plausível parece resolver o problema sozinho.

O que o livro traz sobre o assunto, e em que capítulo ele traz

No meu livro, o Guia Prático Lean Seis Sigma Black Belt (Editora Atlas), a inteligência artificial aparece uma vez só. É no capítulo 1, chamado Mindset de Melhoria. A seção tem nome longo e ele diz tudo: inteligência artificial, um impulsionador do mindset de Melhoria Contínua.

Uma frase da página 7 resume tudo: "Para extrair todo o potencial da IA, é preciso cultivar um mindset de Melhoria Contínua, tanto em termos individuais quanto organizacionais". A ordem da frase não é acidental. O mindset é condição da tecnologia, e não consequência dela.

A mesma página traz dois exemplos que envelheceram bem. A Intel usou mineração de dados numa análise preventiva. Era uma única linha de produção de chips, com economia estimada em três milhões de dólares. A GE Aviation estimou que poderia aumentar a velocidade de produção em vinte e cinco por cento usando análise de big data na inspeção.

Os dois exemplos têm a mesma forma, e é uma forma antiga. Um processo delimitado, uma medida que já existia, um ganho que alguém foi conferir depois. Nenhum dos dois é um caso de máquina decidindo o que melhorar. São casos de máquina enxergando o que já estava sendo medido.

O capítulo 18, que é o do DMAIC, descreve as cinco fases com atividades, perguntas de orientação e fluxograma, da página 143 à 152. E não menciona inteligência artificial em nenhuma linha. A única vez que a palavra tecnologia aparece ali é um rótulo da Figura 18.11. É o de investimentos em tecnologia, num quadro sobre qual framework usar para qual tamanho de problema. Escrevi assim porque o DMAIC é indiferente à ferramenta. Ele diz o que precisa estar provado, e não com que instrumento você prova.

Três ganhos do DMAIC com IA que ninguém discute

O primeiro é o tempo de rascunho. Contrato de projeto, ata, procedimento, roteiro de treinamento, apresentação de fechamento. É o volume de texto que faz projeto atrasar por motivo administrativo, e ele encolheu de semanas para horas.

O segundo é a leitura de texto aberto em escala. Reclamação, pesquisa, campo de observação de checklist, transcrição de entrevista de VOC. Antes disso, quem lia dois mil comentários lia por amostra e sabia que estava lendo por amostra.

O terceiro é o código de análise. Você descreve em português o gráfico ou o teste que quer e recebe o script funcionando. Isso derruba a barreira que mais afasta gente boa da estatística. O julgamento de qual teste cabe continua sendo seu, e agora ele não esbarra em sintaxe.

Os três ganhos têm uma coisa em comum: são todos de produção, nenhum é de julgamento. É por isso que eles são seguros. Você continua responsável pelo mesmo conjunto de decisões de antes, com mais horas disponíveis para tomá-las com calma.

Quatro erros que custam caro, e que eu vejo desde antes da máquina

1. Pedir a meta. Perguntar quanto o indicador deveria melhorar e aceitar o número que vier. A meta sai de perda medida, capacidade instalada e apetite de risco da casa. Um número gerado por analogia com outras empresas vira compromisso público sem lastro, e o projeto começa devendo.

2. Aceitar causa sem prova. É o erro da fase de análise, descrito acima, e o mais caro dos quatro porque contamina todo o resto. Plano de ação apontado para a causa errada consome o trimestre e devolve o indicador no mesmo lugar.

3. Automatizar antes de melhorar. Colocar tecnologia em cima de um processo que ninguém estabilizou. O resultado é a variação de sempre, agora mais rápida e mais difícil de enxergar, porque virou caixa fechada. Estabiliza, padroniza, depois automatiza.

4. Perder o rastro do dado. Uma análise que ninguém consegue refazer não passa em auditoria, não passa em banca de certificação e não convence comitê. Guardar a base, o passo e a versão é chato e é o que separa projeto de apresentação.

Os quatro têm o mesmo pai. São tentativas de comprar velocidade na parte do método que existe justamente para ser lenta. A lentidão do DMAIC não é ineficiência, é o preço da prova.

O que pedir e o que conferir antes de usar

Adotei uma regra de bolso que cabe em uma linha: toda saída gerada entra no DMAIC como rascunho assinado por ninguém. Ela precisa de um dono humano antes de virar entregável, e o dono precisa saber o que conferir. A tabela abaixo é essa lista de conferência.

A terceira coluna é a que muda o comportamento. Enquanto nenhuma pessoa assina, o artefato circula com autoridade de documento e responsabilidade de rascunho. Essa combinação é a que produz decisão ruim em reunião grande.

Vale imprimir isso e deixar visível no começo do projeto. Custa nada e resolve a discussão antes dela virar constrangimento no meio da apresentação.

De onde veio o que a máquina leu

Existe uma pergunta que muda o assunto de lugar, e quase ninguém faz no começo. O que essa ferramenta leu para responder isso? A resposta separa dois usos que parecem o mesmo e não são.

No primeiro uso, ela lê o seu dado: a sua base de ocorrências, os seus comentários de cliente, o seu histórico de parada. Aí a saída fala do seu processo, e o risco é de tratamento, não de origem. É o uso que mais rende dentro do método.

No segundo uso, ela responde do repertório geral, que é o mundo inteiro escrito até certa data. A saída fala de processos parecidos com o seu em algum lugar, e a distância entre parecido e igual é onde mora o prejuízo. Isso vale para referência de mercado, para valor típico de indicador e para tempo padrão de operação.

O segundo uso não é proibido, é ótimo para gerar hipótese e péssimo para fechar número. Machine learning aplicado à sua base é a primeira categoria; um texto sobre o seu setor é a segunda. Confundir as duas é fácil, e o erro não aparece na leitura, porque as duas saídas têm o mesmo tom.

Uma checagem de trinta segundos resolve. Pergunte qual coluna da sua base sustenta cada afirmação. Se a resposta não citar coluna nenhuma, você está no segundo uso, e o número que veio junto é ilustração.

O que muda no DMAIC Ágil

O DMAIC Ágil mantém as mesmas cinco etapas e muda o ritmo de entrega. A meta é desdobrada em objetivos menores. As melhorias acontecem ao longo do ciclo e não esperam a fase de melhoria. O cronograma é flexível de propósito.

Nesse formato o ganho de velocidade da máquina é maior, porque o gargalo do ágil é a preparação de cada ciclo curto. Rascunho de escopo, limpeza de base e material de reunião pesam mais no ciclo curto. Duas semanas não têm a folga de seis meses.

E o risco também é maior, pela mesma razão. Ciclo curto tem menos folga para descobrir que a causa não estava comprovada. No DMAIC tradicional o erro aparece na fase seguinte; no ágil ele já virou entrega incremental na área.

A regra que eu aplico é manter a comprovação de causa fora da negociação de prazo. Encurta a preparação, encurta a redação, encurta a reunião. Não encurta o teste que decide se a causa é causa.

A tabela de decisão: onde a máquina entra no seu projeto

Reuni em uma página a decisão que este guia de DMAIC e IA descreve, situação por situação. Serve para não depender de memória no meio do projeto. É a folha que eu deixaria na parede da sala do time.

De um lado a tarefa concreta que apareceu no seu caminho. Do outro, se ela é de produção ou de compromisso, o que conferir antes de usar e quem assina. O rodapé é a parte que mais gera discussão, e é de propósito.

Cada linha começa por uma tarefa que aparece no meio de um projeto, do agrupamento de reclamação ao alerta automático de desvio. A segunda coluna diz se aquilo é produção ou compromisso, que é a única classificação que importa na hora. A terceira traz a conferência mínima antes de usar o resultado. A quarta nomeia quem assina, porque artefato sem dono circula até alguém tratar como aprovado o que era rascunho. O rodapé fecha com as três tarefas que não se delega em nenhuma circunstância. Imprime em A4 e cabe na parede da sala.

Baixe a tabela de decisão em PDF

Se você só levar uma coisa daqui, leve a segunda coluna. Classificar a tarefa entre produção e compromisso antes de começar resolve sozinha a maioria das dúvidas que aparecem no meio do caminho.

Como começar sem virar piloto eterno

O caminho que funciona começa pequeno e termina com número. Escolha um projeto que já está rodando, com problema definido e base existente, e não um projeto novo criado para testar a ferramenta. Projeto criado para testar ferramenta não tem dono de resultado. Sem dono, ninguém cobra o fechamento.

Dentro dele, escolha uma tarefa classificada como produção. Agrupamento de comentário e limpeza de base são as duas melhores portas de entrada. O resultado é conferível na hora por quem conhece o processo.

Meça o que economizou em horas, e meça também o que precisou refazer. A segunda medida é a que ninguém registra e é a que decide se o ganho é real. Se refazer custou mais do que o rascunho poupou, o problema costuma estar no pedido, não na ferramenta.

Depois disso, escreva a regra da casa. Uma página com o que se delega, o que se confere e quem assina, no formato da tabela deste artigo, adaptada ao seu vocabulário. Sem essa página cada analista inventa a própria régua e o padrão de prova do time vira loteria. A gente já deixou os formulários das cinco fases prontos no Kit de Ferramentas Lean Seis Sigma. Adaptar é mais rápido do que criar.

Um projeto conduzido assim vira case defensável, com rastro do dado e responsabilidade nomeada. É o que a banca de certificação pede e o que o comitê pergunta. E, por acaso, é o que faz o ganho durar.

O que dizer quando a liderança pedir um projeto com inteligência artificial

O pedido quase sempre chega assim, sem recorte, e a pior resposta possível é a defensiva. Recusar soa como conservadorismo, e não é disso que se trata. A resposta boa é devolver o pedido em forma de escolha.

Eu costumo dizer três frases, sempre nessa ordem. A primeira é: "a ferramenta acelera a produção de artefato do projeto, e a gente vai usar ela em quatro tarefas, que já estão na lista". A segunda é: "ela não move a decisão de meta, de causa e de reação, e essas três continuam com nome e sobrenome".

A terceira é a que fecha a conversa: "o prazo vai cair na preparação, e não na comprovação". A comprovação é o que faz o resultado sobreviver à auditoria do trimestre seguinte.

Se a expectativa do outro lado for de decisão automática, o desalinhamento é agora e não em três meses. Antecipar essa conversa é barato. Descobrir na apresentação de fechamento que a diretoria esperava outra coisa custa o projeto inteiro. Quem conduz projeto sozinho pela primeira vez costuma achar essa régua na Academia Lean Seis Sigma. É onde a conversa sobre padrão de prova acontece com caso na mesa.

E tem uma resposta honesta para a pergunta implícita, que é se isso muda o método. Não muda. O PDCA sobreviveu à planilha, ao software estatístico e ao painel em tempo real, e o DMAIC no Kaizen atravessou as mesmas ondas. O DMAIC muda de instrumento a cada década e não muda de exigência. O que cai é o custo de chegar até a decisão, e não quem a toma.