IA na fase Melhorar do DMAIC: a solução sai em minutos e a mudança leva semanas

A fase Melhorar do DMAIC é a primeira em que o entregável não cabe num arquivo. Definir termina com um contrato de projeto assinado. Medir termina com uma linha de base. Analisar termina com uma causa comprovada. Os três terminam em documento, e documento é justamente o que uma máquina produz muito bem. Melhorar só termina quando o processo passa a funcionar de outro jeito. É daí que vem quase toda a confusão sobre IA na fase Melhorar.

Eu vejo a mesma cena se repetir desde que os modelos ficaram bons de texto. O time pede vinte soluções e recebe vinte soluções. Monta um plano de ação bonito na mesma tarde e sai da reunião com a sensação de que a parte difícil da fase Melhorar acabou. Três semanas depois, o processo continua igual. O arquivo existia. A mudança, não.

Este texto não percorre o DMAIC inteiro. Ele fica numa etapa só, a que recebe causa comprovada e devolve processo alterado. Vou passar tarefa por tarefa. Digo o que a máquina entrega, onde ela erra sem avisar e qual conferência custa minutos. E vou parar com calma em cinco pontos da fase Melhorar em que uma saída bem escrita esconde uma melhoria que não vai acontecer. São eles: a restrição de execução e a diferença entre solução de texto e dispositivo. Depois, o desenho do experimento, o campo Quem do plano de ação e o critério de sucesso do piloto.

O entregável desta fase não é um documento

IA na fase Melhorar do DMAIC serve para gerar alternativas de solução, redigir plano de ação, rascunhar procedimento e montar o roteiro de um experimento. Ela não decide qual solução vale o investimento, não instala nada no chão e não faz ninguém seguir o padrão novo. A escolha e a execução seguem humanas.

A Parte VII do Guia Prático Lean Seis Sigma Black Belt abre na página 397 com o objetivo da fase Melhorar: buscar soluções que melhorem a eficiência do processo e diminuam custos. Também reduzir desperdícios, aumentar a produtividade e melhorar a qualidade do produto ou serviço. Repare que os cinco verbos descrevem coisas que acontecem no processo. Nenhum deles acontece dentro de um editor de texto.

Essa distância entre o artefato e o entregável existe em qualquer fase. Nas três primeiras ela é pequena. Um contrato de projeto bem redigido praticamente é o entregável da fase Definir. Um estudo de capabilidade bem feito praticamente é o entregável da fase Medir. Na fase Melhorar a distância abre de vez. Entre o texto da solução e a solução funcionando existem compra, parada, treino, teste e a concordância de gente que não estava na sala.

Vale guardar essa figura porque ela explica um mal-entendido comum. Quando alguém diz que a inteligência artificial acelerou muito o projeto de melhoria, quase sempre está falando das três primeiras caixas. Ali a aceleração é real e grande. A quarta caixa, a da fase Melhorar, continua andando na velocidade do calendário da fábrica, do orçamento aprovado e da agenda de quem vai executar.

As cinco tarefas que a fase Melhorar cobra, na ordem em que chegam

O livro lista, na abertura da Parte VII, as perguntas que a etapa de Melhoria precisa responder. Elas dão a espinha do trabalho e servem de roteiro para decidir o que delegar.

1. Quais soluções potenciais foram identificadas para resolver as causas raízes? Gerar e avaliar possibilidades a partir das causas, com brainstorming e outras técnicas criativas.
2. Quais critérios serão utilizados para selecionar a melhor solução? Definir critérios claros considerando custo, tempo, impacto e viabilidade.
3. Como será implementado o plano de ação? Desenvolver um plano detalhado, com passos específicos, responsáveis, cronograma e recursos necessários.
4. Como garantimos que as melhorias serão sustentáveis? Planejar treinamento, padronização e documentação das novas práticas.
5. Como mediremos o impacto das melhorias implementadas? Definir métricas de sucesso e plano de monitoramento para avaliar o resultado.

Coloque ao lado de cada uma o que a máquina faz hoje e o corte da fase Melhorar aparece sozinho. Na primeira, ela é excelente e barata. Na segunda, ela produz uma tabela de critérios em segundos. O que ela não tem como saber são os pesos, que são a estratégia da empresa escrita em números. Na terceira, ela redige o plano inteiro e não consegue arrancar um compromisso de ninguém. Na quarta, ela escreve o procedimento sem nunca ter feito a tarefa. Na quinta, ela calcula o que você mandar calcular.

Ou seja: a fase Melhorar tem cinco tarefas e a máquina participa das cinco. Essas cinco são as perguntas do livro. Na tabela que fecha o artigo eu conto uma sexta, o desenho de experimento, porque ele tem entrega e conferência próprias quando a fase Melhorar otimiza parâmetro em vez de trocar um pedaço do processo. O problema não é ausência de ajuda. É que a ajuda chega com a mesma aparência de pronto nos cinco casos. Só em um deles ela realmente está pronta.

O que ficou barato, e a conta que apareceu no lugar

Antes de qualquer modelo generativo, gerar alternativa na fase Melhorar era caro de um jeito específico. Você juntava seis pessoas numa sala por duas horas e saía com sete ideias. Quatro delas eram variações da opinião de quem tinha o cargo mais alto na mesa. Quem já conduziu essa reunião sabe que a escassez não era de criatividade. Era de tempo e de disposição para discordar do chefe na frente dos outros.

Hoje essa etapa custa dois minutos e sai sem hierarquia dentro. Isso é ganho de verdade, e eu uso. Só que o gargalo da fase Melhorar nunca foi o número de ideias disponíveis. Era o número de ideias que a organização consegue implantar num trimestre. Esse número costuma ser bem menor do que sete.

Então a abundância mudou o problema de lugar. Com sete alternativas você discute cada uma. Com vinte, o time faz triagem por leitura rápida. E triagem por leitura rápida premia a alternativa mais bem escrita. A ferramenta que escreve bem é a mesma que gerou as vinte. A mais persuasiva do lote não tem nenhuma relação com a mais implantável.

A saída prática é chata e funciona: antes de olhar a lista, escreva os critérios e os pesos. A matriz de esforço e impacto e a matriz GUT servem para isso. Ambas exigem que alguém assuma um número. Depois disso a lista de vinte encolhe sozinha, quase sempre para três.

A solução que não cabe na janela

Meu primeiro contato sério com projeto de melhoria foi na Votorantim Metais, na unidade de zinco, ainda como estagiário e depois como analista. Trabalhei em parada industrial e no programa de manutenção autônoma. Foi ali que eu entendi uma coisa sobre a fase Melhorar que nenhum livro tinha me ensinado: a parada tem janela fixa. O que não cabe no calendário da parada não é adiado. Ele simplesmente não acontece, e volta para a fila do ano seguinte.

Essa restrição é invisível para qualquer modelo. Peça soluções para uma causa raiz de perda em linha de produção e você vai receber propostas ótimas e inviáveis. Uma exige três dias de linha parada. Outra depende de investimento que só entra no orçamento do ciclo seguinte. A terceira usa equipamento com prazo de entrega de cinco meses. Nada disso está errado tecnicamente. Está errado de calendário, que é o tipo de erro que só aparece quando alguém tenta executar.

O conserto é anterior ao pedido. Antes de pedir alternativas, escreva as restrições e mande junto. Qual é a janela de parada, qual é o teto de investimento sem nova aprovação e quem executa. Também o que não pode parar em hipótese alguma e a data limite do projeto. Uma lista gerada com essas cinco linhas na entrada vem menor e vem utilizável.

Tem um efeito colateral bom nisso. Escrever as restrições obriga o time a descobrir que não sabe algumas delas. Já vi mais de uma reunião de fase Melhorar travar na pergunta “quanto a gente pode gastar sem subir para o comitê?”, e essa trava é útil, porque a resposta ia fazer falta de qualquer jeito, três semanas mais tarde.

Tem solução que é texto e tem solução que é peça

Essa é a divisão que mais economiza discussão numa reunião de fase Melhorar. Existem soluções cujo produto final é um documento: procedimento novo, regra de decisão, critério de aceitação, sequência de etapas, formulário. E existem soluções cujo produto final é um objeto. Um gabarito, um sensor, uma trava, um encaixe que só entra de um jeito, uma marcação no piso.

A máquina é boa na primeira categoria e cega na segunda. Ela escreve um procedimento coerente porque procedimento é texto, e texto é o que ela faz. Ela não sabe se o parafuso cabe nem se a bancada tem espaço. Também não sabe se o operador enxerga o mostrador com a luva na mão.

O risco prático é conhecido de quem trabalha com melhoria contínua. A solução mais fácil de escrever fica pronta primeiro, e o time acaba tratando por procedimento um problema que pedia dispositivo. E procedimento contra erro humano repetitivo é uma aposta ruim. Ele depende de atenção, e atenção é o recurso que falha no terceiro turno. Solução física vai do gabarito de montagem à redução de tempo de setup, terreno do SMED.

Quando eu recebo uma lista de soluções gerada, minha primeira triagem é essa: marco cada item como texto ou como peça, e conto. Se saiu tudo texto, o pedido foi mal feito. A ferramenta seguiu o caminho que ela sabe percorrer. Vale refazer pedindo explicitamente alternativas físicas para a mesma causa.

Seis famílias à prova de erros, usadas como filtro do pedido

A técnica de Poka Yoke nasceu com Shigeo Shingo no Japão dos anos 1960. O capítulo dedicado a ela no guia de Black Belt classifica os dispositivos em seis tipos. Eu uso essa lista de um jeito que o livro não sugere: como cardápio do pedido. Em vez de perguntar “que soluções existem”, eu peço uma alternativa de cada tipo. A lista volta com variedade de verdade.

No capítulo 30, “Ferramentas de Melhoria”, o livro é explícito sobre a ordem. “VI. Poka Yoke de mitigação: esse último tipo de Poka Yoke somente é usado quando nenhum outro tipo é viável para o processo, pois ele apenas diminui o impacto dos fatores que geram o erro.” (p. 438) É a ordem que a saída gerada costuma inverter. Mitigação é a família mais fácil de escrever, e quase sempre vira um checklist de conferência no fim da linha. Se as vinte alternativas geradas são vinte conferências, elas são todas do tipo VI. Você recebeu uma lista de um item só, repetida vinte vezes.

A página da ASQ sobre à prova de erros organiza a mesma família por momento de atuação. O cruzamento das duas leituras costuma render pelo menos uma alternativa que ninguém tinha considerado. Se você quiser o passo a passo da técnica, ele está em o que é Poka Yoke. Aqui interessa só o uso dela como filtro de pedido dentro da fase Melhorar.

O DOE que a máquina escreve e as decisões que ela não toma

Quando a fase Melhorar precisa otimizar parâmetros, e não trocar um pedaço do processo, o caminho é o planejamento de experimentos. O livro monta o desenho em três blocos: planejamento, execução e análise. O planejamento inclui definir o problema, escolher a variável resposta, escolher os fatores e os níveis e escolher o tipo de experimento.

Pedir esse desenho a um modelo funciona muito bem. Você descreve o processo. Ele devolve fatores plausíveis, dois níveis para cada, uma matriz fatorial completa e até a ordem das corridas. O texto sai correto e organizado. O que ele não tem como saber cabe em quatro linhas.

• Se o nível alto é atingível na máquina real, com aquele molde, aquele lote e aquela restrição de temperatura.
• Quanto custa cada corrida, em material perdido e em tempo de linha parada, que é o que define quantas você pode rodar.
• Quais fatores não podem variar juntos por segurança ou por contrato de garantia do equipamento.
• Quem opera durante o experimento, porque trocar o operador no meio insere um fator que ninguém planejou.

Um fatorial sugerido sem restrição de máquina é ficção operacional. Ele é lindo no papel e a primeira corrida já mostra que aquele nível alto não existe. Por isso eu inverto o pedido: primeiro escrevo as restrições reais dos fatores, depois peço o desenho. A saída encolhe, às vezes de um fatorial completo para um fracionado, e passa a ser executável.

Para a parte estatística vale conferir contra fonte externa. O capítulo de melhoria de processo do handbook do NIST traz a lógica de escolha entre desenhos e os cuidados de aleatorização. É uma boa segunda opinião quando a saída gerada afirma algo com muita segurança.

Réplica e repetição, as duas palavras que a saída troca

Esse é o erro específico que eu mais vejo em roteiro de experimento gerado na fase Melhorar. Ele passa despercebido porque as duas palavras parecem sinônimos em português corrente. No livro elas têm definições distintas e consequências distintas.

Réplica é rodar a mesma condição experimental em unidades experimentais diferentes. Repetição é aplicar o mesmo tratamento mais de uma vez sobre a mesma unidade experimental. Ela serve quando se quer analisar a variação por desvio padrão em vez de trabalhar com a média.

A diferença muda o que o experimento consegue enxergar. Réplica captura a variação entre unidades, que é onde mora boa parte do ruído do processo real. Repetição captura a variação da medição sobre a mesma peça. Quem pediu réplica e recebeu repetição vai concluir que o processo é mais estável do que ele é. A fonte de variação maior ficou de fora do desenho.

A conferência custa trinta segundos. Leia a coluna de corridas e pergunte: cada linha usa uma peça nova ou é a mesma peça medida de novo? Se o roteiro não responde isso com clareza, ele não está pronto para ir para a linha. Não importa o quanto esteja bem formatado.

O campo Quem é onde o plano de ação morre

O livro diz que, após a priorização das ações de melhoria, é importante desdobrá-las em informações mais tangíveis. Para isso ele apresenta o 5W2H. São sete perguntas: o que, onde, quando, por que, quem, como e quanto custa. O plano de ação que sai daí é o documento operacional da fase Melhorar.

Um modelo preenche seis dessas sete colunas, e cinco delas muito bem. O que fazer, onde, por que, como e quanto custa saem coerentes, às vezes melhores do que o rascunho humano. A máquina não pula campo por preguiça. O quando ela chuta, e o chute costuma ser otimista. O quem ela não tem como preencher, e é exatamente aí que o plano se resolve ou se perde.

Vale reparar num detalhe do exemplo do livro. O quadro de aplicação do 5W2H traz nomes próprios de responsáveis, equipamento identificado, unidade nomeada, data e valor em reais. Não é decoração do exemplo. É o padrão de precisão que separa plano de ação de lista de intenções. Um plano com “equipe de manutenção” no campo Quem não tem dono. E tarefa sem dono compete com o trabalho do dia contra alguém que tem nome.

Então o teste do plano gerado é curto e desconfortável: leia a coluna Quem em voz alta na reunião. Se todo mundo ali souber o nome, a data e o que acontece se atrasar, o plano está pronto. Se a coluna vier com área em vez de pessoa, o documento existe e a ação não vai começar.

Escrever o padrão leva minutos, fazer com que ele pegue não

A quarta pergunta da fase Melhorar cobra sustentação. O caminho clássico passa por treinamento, procedimento operacional padrão e trabalho padronizado. Aqui a inteligência artificial entrega um ganho enorme e uma armadilha discreta ao mesmo tempo.

O ganho é real. Redigir um POP claro, com sequência, critério de aceitação e ponto de atenção, é trabalho de texto, e sai em minutos com qualidade acima do rascunho médio. Muita gente boa de chão escreve procedimento ruim, não por incompetência, mas porque escrever é outro ofício.

A armadilha é que um procedimento tecnicamente correto pode ser impossível de cumprir no ritmo real. Ele pede três conferências numa etapa que dura quarenta segundos. Ele manda anotar num formulário que fica a doze metros da bancada. Ele assume que o operador tem as duas mãos livres. Nada disso aparece no texto, e todos aparecem no primeiro dia de uso.

Por isso o padrão gerado não pode ir direto para a pasta da qualidade. Ele volta para quem executa. A pergunta certa não é se está claro, e sim se dá para fazer assim no dia de pico. Quem trabalha com padronização sabe que o padrão que ninguém consegue seguir é pior do que padrão nenhum. Ele cria a ilusão de controle e ensina o time a assinar documento sem ler.

Muda, Mura e Muri no que o dado mostra

O capítulo 29 do livro, “Eliminação de Desperdícios”, trata dos três Ms e dos oito desperdícios. Na página de abertura dele, fechando a introdução, vem uma frase de Shigeo Shingo em itálico: “O tipo mais perigoso de desperdício é aquele que não reconhecemos.” (p. 399) Vale como aviso sobre delegação na fase Melhorar, porque a máquina só reconhece o desperdício que apareceu no dado que você mandou.

Muda, o desperdício puro, costuma estar registrado: refugo, retrabalho, estoque, espera com apontamento. Mura, a irregularidade, aparece se você olhar a série ao longo do tempo em vez do total do mês. Uma carta de controle mostra isso em minutos. Muri, a sobrecarga, é a que quase nunca vira dado. Ela aparece como hora extra normalizada, como gente fazendo duas funções e como equipamento rodando acima do projeto.

Uma análise de desperdício feita só sobre a extração do sistema encontra Muda e sugere ações de Muda. O time sai com a sensação de que varreu o processo. Os oito desperdícios continuam sendo um bom roteiro de conversa no chão justamente porque a conversa acha o que o relatório não tem. Em processo administrativo a lógica é a mesma e os nomes mudam, como mostra a lista de desperdícios em escritórios.

O piloto precisa de um critério de sucesso escrito antes de rodar

Métricas de sucesso e plano de monitoramento fecham a lista de perguntas da fase Melhorar. Na prática, quase todo projeto roda um piloto antes de estender a mudança. É no piloto que o critério escrito antes vale mais do que qualquer análise feita depois.

O motivo é humano e antigo. Depois de três semanas de trabalho, todo mundo quer que o piloto tenha dado certo. Sem um critério anterior, o time olha o resultado e encontra a leitura que confirma o esforço. O mês teve um feriado a mais, a matéria-prima veio pior, o indicador melhorou naquela família específica. Nada disso é má fé. É o jeito como a gente lê número que já custou caro.

O critério mínimo tem quatro campos, e todos precisam estar escritos antes da primeira corrida. Qual indicador vale, qual valor conta como sucesso, em quanto tempo e qual resultado faria o time voltar atrás. O quarto campo é o que quase ninguém escreve, e é o que evita a extensão de um piloto que não funcionou.

Esse é um dos poucos pontos da fase Melhorar em que delegar ajuda muito. Peça a um modelo para listar as leituras alternativas do resultado do seu piloto, incluindo as que contrariam a conclusão que você quer. Ele faz isso sem constrangimento nenhum. A lista costuma trazer duas hipóteses que a equipe evitou levantar em voz alta.

Quando delegar falha, e quando não delegar falha junto

Vale colocar os dois fracassos da fase Melhorar lado a lado, porque a discussão sobre ferramenta costuma tratar só de um deles.

Delegar falha quando a saída chega pronta demais para a conferência que ela exige. Um plano de ação com sete colunas preenchidas passa a impressão de completo. Já aprovei um desses. A coluna Quem dizia “Manutenção” em cinco das sete linhas e eu assinei mesmo assim, porque o documento estava impecável. Um mês depois nenhuma das cinco tinha começado, pelo motivo mais simples do mundo: área não tem agenda, pessoa tem. O mesmo vale para o roteiro de DOE com réplica trocada por repetição e para o POP que não cabe no tempo de ciclo. Nos três casos o defeito não é de conteúdo, é de contexto, e o formato limpo esconde a falta.

Não delegar falha de outro jeito, e o lastro aqui é o mesmo de sempre: a reunião de brainstorming com hierarquia dentro. Seis pessoas, duas horas, sete ideias, quatro delas alinhadas com a opinião de quem manda. Quem já cronometrou uma dessas sabe que o custo é alto e o resultado é estreito. Recusar a ferramenta preserva esse gargalo e ainda gasta a manhã do time inteiro.

Os dois riscos aparecem juntos quase sempre. A saída é fixar a fronteira por tipo de tarefa em vez de por ferramenta. Geração de alternativa, redação de plano, rascunho de padrão e roteiro de experimento vão para a máquina. Peso de critério, campo Quem, restrição de máquina e critério de sucesso do piloto ficam com quem responde pelo resultado. São conferidos numa passada única antes de qualquer coisa sair da sala.

Um lembrete que economiza discussão: essa fronteira é de projeto, com escopo e prazo. Na rotina, a conversa é outra, e ela está em IA e melhoria contínua.

A divisão de trabalho da fase Melhorar, linha por linha

Juntando tudo, a fase Melhorar fica assim quando o time usa a ferramenta com fronteira definida.

A coluna da direita é a que costuma faltar. Todas as seis conferências cabem numa reunião de uma hora, e nenhuma delas exige ferramenta nova. O que elas exigem é alguém disposto a ler a saída procurando o que está faltando, e não o que está bonito.

Tabela de decisão da fase Melhorar, para baixar

Montei a divisão acima em uma página, com as seis tarefas da fase Melhorar, a fronteira e as conferências. O formato dá para imprimir e levar para a reunião de fechamento.

Uma folha só, com a fronteira de cada tarefa: o que delegar, o que fica com o time e a conferência que fecha o ciclo. Feita para ir impressa para a reunião. A miniatura abre em tamanho grande aqui mesmo, sem sair da página.

Baixar a tabela de decisão em PDF

Se a sua equipe está montando o kit de trabalho da fase, o kit de ferramentas Lean Seis Sigma reúne os formulários das outras etapas. As academias de certificação cobrem a parte de método com a profundidade que um artigo não alcança.

Como saber que a fase Melhorar terminou

Essa pergunta gera mais discussão do que deveria, e a resposta não é a data do cronograma. A fase Melhorar termina quando três coisas são verdade ao mesmo tempo.

1. A mudança está rodando no processo real, não em piloto e não em ambiente controlado.
2. O indicador que motivou o projeto se moveu na direção certa e o movimento se sustentou por tempo suficiente para não ser sorte.
3. Quem executa consegue descrever o novo jeito sem consultar o documento, o que é sinal de que o padrão pegou.

Faltando qualquer um dos três, a fase Melhorar continua aberta, mesmo com o plano de ação todo marcado como concluído. Marcar tarefa como feita é fácil. O capítulo de sustentação do livro existe porque a taxa de reversão é alta: passados alguns meses, o processo volta ao jeito anterior sem ninguém decidir isso.

Com os três, o bastão passa para a fase seguinte, que é onde o controle fica. Se você quiser ver o mesmo corte nas etapas anteriores, os textos de IA na fase Definir e de IA na fase Medir seguem a mesma estrutura. A visão geral está em DMAIC e IA.

O teste da semana seguinte

Fica o critério que eu uso para separar melhoria de documento sobre melhoria, e ele não pede indicador nenhum. Volte ao processo sete dias depois da reunião de fechamento, sem avisar, e observe alguém executando a tarefa.

Se a pessoa faz do jeito novo e consegue explicar por que mudou, a fase Melhorar aconteceu. Se ela faz do jeito antigo, o que existe é um conjunto de arquivos bem escritos e um processo intacto. Vale o mesmo quando ela faz do jeito novo e não sabe dizer o motivo. Essa segunda situação ficou mais comum, e não porque as equipes pioraram. Ficou mais comum porque o arquivo bem escrito ficou barato, e a sensação de progresso vem dele.

Na Voitto a gente conversa o ano inteiro com quem está tocando projeto de melhoria, e a conta que não muda é essa. A parte cara da fase Melhorar continua exatamente onde sempre esteve: convencer, treinar, ajustar no chão e voltar para conferir. Nada disso ficou mais rápido nos últimos anos, e é isso que o cronograma do projeto precisa refletir.