Qual metodologia de melhoria usar: o problema decide, não a moda

A pergunta qual metodologia de melhoria usar chega quase sempre no formato de escolha de programa. Alguém quer saber se a empresa vai fazer Lean, Seis Sigma ou 5S. Formulada assim, ela já nasce torta, e é por isso que tanta empresa implanta a metodologia errada com a melhor das intenções.

Metodologia não é bandeira, é ferramenta de corte. Ninguém pergunta qual chave de fenda a empresa vai adotar: pega a que serve no parafuso da frente. Com melhoria contínua acontece o contrário, e a decisão vem antes de alguém olhar o problema.

Os dois critérios mais usados são os dois piores. O primeiro é moda: voltou do congresso encantado com Seis Sigma, vai fazer Seis Sigma. O segundo é porte: empresa pequena faz 5S, empresa grande faz projeto estatístico. Nenhum dos dois tem relação com o que está fazendo a fábrica perder dinheiro.

O critério que funciona é a natureza do problema, e ela cabe em três perguntas. A causa é conhecida? O problema é crônico ou pontual? O ganho depende de mudar o fluxo, reduzir a variação ou organizar o local? Respondidas nessa ordem, elas resolvem a maioria dos casos de chão de fábrica.

Sobre a procedência do que vem aqui: os prazos, os perfis de quem conduz e as faixas de custo relativo saíram da consolidação dos roteiros de implantação dos kits de metodologia da Voitto. Os casos da tabela de chão de fábrica foram montados a partir de padrões recorrentes nesses roteiros, não de uma planta única.

Por que a pergunta sobre qual metodologia implantar está errada de origem

A pergunta errada é essa: qual metodologia a gente vai implantar. Ela trata a escolha como decisão de gestão, do mesmo tipo que escolher um ERP. Só que o resultado não vem do programa escolhido. Vem do encaixe entre a ferramenta e o problema que estava lá antes de qualquer programa existir.

Escolher por moda tem efeito colateral previsível. A empresa monta estrutura, treina gente, cria comitê e depois procura problema que caiba na estrutura. Escolher por porte dá no mesmo. Uma usinagem de quarenta pessoas pode ter variação dimensional que só projeto estatístico fecha. Uma multinacional pode perder duas horas por turno procurando ferramenta.

Quem pergunta por qual metodologia de melhoria usar já tem um problema na mesa. A pergunta certa é o que esse problema pede.

As três perguntas que decidem quase todo caso

Antes de citar qualquer sigla, responda três coisas sobre o problema. A ordem importa, porque a primeira resposta já elimina metade das opções e evita meses de trabalho desnecessário.

1. A causa é conhecida? Se a equipe que opera sabe apontar o motivo e o motivo se sustenta diante de uma pergunta simples, não há o que investigar. O trabalho é de execução.
2. O problema é crônico ou pontual? Crônico é o que acontece há meses, convive com o processo e já virou paisagem. Pontual é o que começou numa data e antes não existia.
3. O ganho depende de quê? De mudar o fluxo entre etapas, de reduzir a variação dentro da etapa, de organizar o local de trabalho ou de manter o equipamento disponível.

Nenhuma das três fala de tamanho de empresa, de orçamento ou de certificação. A terceira é a que mais gente erra, porque exige separar sintoma de mecanismo. Refugo alto é sintoma. A causa pode ser variação de processo, peça parada entre etapas ou ajuste manual sem padrão. Cada uma pede ferramenta diferente.

A árvore de decisão em uma tabela

A tabela abaixo é a árvore completa. Ache a linha que descreve a sua situação, confira a pergunta que fecha a decisão e siga o caminho indicado. Se duas linhas parecerem suas, o problema é grande demais para uma ferramenta só.

5S: quando o problema é o local de trabalho

O programa 5S resolve um tipo específico de perda. A que acontece antes de a operação começar e depois que ela termina. Ferramenta que não está no lugar, material sem endereço, bancada que esconde defeito, condição básica de limpeza que mascara vazamento.

O indicador que denuncia isso é o tempo. Se o operador gasta minutos procurando, se o setup atrasa porque o dispositivo sumiu, se ninguém enxerga vazamento porque tudo está sujo, a perda é de local de trabalho. É aí que o 5S paga rápido.

O que ele não resolve é onde a maioria se frustra. 5S não reduz variação de processo: uma injetora com desvio dimensional continua com desvio depois do posto organizado. E não conserta fluxo: se a peça espera três dias entre duas etapas, a espera continua igual.

A confusão vem de o 5S melhorar quase todo indicador um pouco. Isso é efeito de base, não é solução. Quando o problema principal é variação ou fluxo, ele entrega ganho pequeno e some do radar em seis meses.

Kaizen: quando a causa já é conhecida pela equipe

Kaizen é a escolha certa quando a resposta à primeira pergunta é sim. A equipe sabe a causa, sabe o que fazer, e o que falta é tempo protegido e autoridade para mexer. Nesse caso, investigar é desperdício puro.

O teste é simples. Pergunte à equipe o que causa o problema e depois por que ela acredita nisso. Se a resposta vier com observação concreta e for a mesma de três pessoas diferentes, a causa é conhecida. Vá direto para a ação.

O formato concentrado, tratado em evento kaizen, existe justamente para isso: uma semana, uma equipe dedicada, escopo fechado e mudança implantada antes de todo mundo voltar para a rotina. O ganho é incremental e local, e não deveria ser vendido como outra coisa.

O que Kaizen não resolve é problema cuja causa está em disputa. Se cada turno tem uma teoria, o evento vira uma semana de opinião com almoço. A equipe implanta a solução do mais convincente, o indicador não se mexe, e a conclusão errada é que Kaizen não funciona.

MASP: quando o problema é crônico e a causa é desconhecida

MASP é para o problema que já virou paisagem. Acontece há meses, todo mundo convive com ele, ninguém prova o porquê e há registro histórico para trabalhar. É o terreno em que análise disciplinada ganha de improviso.

A força do método está em obrigar a separar etapas que as pessoas costumam misturar. Observação antes de análise, análise antes de solução, solução antes de padronização. A análise de causa raiz entra no meio desse caminho, não no começo da conversa.

Ele pede dado do tipo que a fábrica já tem: apontamento de refugo, ordem de produção, registro de parada, reclamação de cliente. Não exige desenho de experimento nem teste de hipótese, e por isso o prazo cabe em semanas.

O que o MASP não resolve é fluxo entre áreas. Ele foi feito para atacar um efeito indesejado bem delimitado. Quando o problema é o caminho que a peça percorre na planta inteira, o recorte fica grande demais e o método patina na análise.

DMAIC e Lean Seis Sigma: quando a prova estatística vale o prazo

O método DMAIC entra quando três condições aparecem juntas. A causa é desconhecida, o problema envolve variação, e a decisão precisa de prova que sobreviva a questionamento técnico. Tirar qualquer uma das três derruba a justificativa do projeto.

Lean Seis Sigma acrescenta a parte de fluxo ao mesmo esqueleto e é a escolha quando o problema tem os dois lados: peça esperando demais e peça saindo fora do alvo. A diferença de escopo entre atacar variação e atacar causa crônica está detalhada em MASP e DMAIC.

O que ninguém diz na hora de vender o projeto é o prazo. Um DMAIC honesto leva de três a seis meses, consome um condutor formado e ocupa gente da operação em coleta. Isso só se paga com ganho grande e recorrente.

O que DMAIC não resolve é urgência. Se a linha está parando hoje, o projeto não chega a tempo. Contenção primeiro, projeto depois, com a contenção registrada como ação provisória para não virar definitiva por esquecimento.

Lean: quando o problema é fluxo, espera e estoque

Lean manufacturing é a resposta quando a peça passa mais tempo parada do que sendo transformada. O sintoma é prazo longo com máquina ociosa, estoque entre etapas e pressão de entrega sem ninguém apontar onde o tempo some.

A medição que confirma é direta. Compare o tempo de processamento com o tempo total de atravessamento. Quando a razão é pequena, o problema não está em nenhuma etapa: está no espaço entre elas. Melhoria dentro da operação não muda esse número.

O vocabulário de perdas ajuda a nomear o que está acontecendo, e muda, mura e muri separam três coisas que costumam vir juntas: desperdício, oscilação de ritmo e sobrecarga. Tratar oscilação como desperdício é erro comum e gera solução que não segura.

O que Lean não resolve é qualidade da peça. Se o furo sai fora de tolerância, nivelar a produção não corrige o furo. Já vi célula reorganizada com ganho real de prazo e refugo intacto no fim do mês, porque o problema nunca foi de fluxo.

TPM: quando a perda é de disponibilidade de equipamento

Quando a máquina para, quebra repetidamente ou consome o turno em setup e ajuste, a perda é de disponibilidade. Esse é o território do TPM, e nenhuma organização de posto ou projeto estatístico substitui um programa de manutenção estruturado.

O diagnóstico que confirma é a distribuição das perdas do equipamento. Se a maior fatia está em parada não programada, em pequena parada recorrente ou em queda de velocidade, o caminho é claro. Os 8 pilares do TPM existem para atacar cada uma dessas fatias com um dono diferente.

Há um pré-requisito ignorado com frequência. Manutenção autônoma depende de condição básica, e condição básica é 5S aplicado ao equipamento. Iniciar TPM em máquina suja, com vazamento normalizado e sem padrão de inspeção, é começar pelo pilar que não sustenta peso.

O que TPM não resolve é defeito gerado por método. Se a peça sai errada porque o parâmetro está errado, a máquina disponível produz defeito com mais disponibilidade. A perda por qualidade aparece no indicador de eficiência, mas a causa não está na manutenção.

CEP: quando o processo já é capaz e o desafio é manter

O controle estatístico de processo não é ferramenta de melhoria, é de manutenção de ganho. Responde a uma pergunta única: o processo de hoje se comporta como o que eu conheço, ou entrou coisa nova?

Por isso a ordem importa. Colocar carta de controle em processo que ainda não é capaz gera um gráfico que aponta problema o tempo todo e não ajuda ninguém a decidir. Primeiro se resolve a capabilidade do processo, depois se monitora a estabilidade.

O ganho do CEP é de outra natureza e por isso é subestimado. Ele não melhora média nem reduz variação sozinho. Avisa cedo, quando a causa ainda tem turno, lote e data, e é o jeito mais barato de impedir que o ganho conquistado regrida devagar.

O que ele não resolve é processo que nunca foi bom. Carta de controle sobre processo incapaz documenta o fracasso com rigor estatístico. O sinal de escolha errada é a carta que ninguém olha porque vive apitando.

Poka yoke e trabalho padronizado: quando o erro é humano e repetitivo

Existe um caso em que a causa é conhecida, o problema é crônico e nenhuma metodologia anterior é a resposta: o erro humano que se repete no mesmo ponto, com pessoas, turnos e experiências diferentes.

Quando o mesmo engano acontece com gente diferente, o problema não é a pessoa: é o projeto da operação, que permite errar. Treinar de novo é a resposta mais comum e a menos eficaz, porque trata como desatenção o que é falta de barreira.

A resposta tem duas camadas. Primeiro o trabalho padronizado, que fixa a sequência, o tempo e o ponto crítico de cada operação. Depois o poka yoke, que impede fisicamente a montagem errada ou avisa no ato em que ela acontece. A ordem é essa: padronizar antes de travar.

O que essa dupla não resolve é erro de decisão em processo instável. Se o operador precisa ajustar porque a máquina desliza, o dispositivo à prova de erro não tem o que travar. Nesse caso o erro é consequência, e a causa está no processo.

Prazo, custo e quem conduz: a parte que ninguém coloca na proposta

A comparação que falta na maioria das discussões não é sobre conceito. É sobre o que cada caminho custa em tempo, em gente e em dinheiro. Essa tabela é a que muda a decisão quando a árvore apontou dois caminhos possíveis.

Duas leituras saltam daí. Prazo e custo sobem junto com a exigência de dado. E os caminhos mais baratos são os que dependem de a causa já ser conhecida, o que reforça o peso da primeira pergunta.

Casos de chão de fábrica e a escolha que cada um pede

Árvore de decisão é abstrata até encostar num caso. A tabela traz situações frequentes e a escolha que cada uma pede, com o motivo de a alternativa óbvia não servir.

O último caso é o mais comum e não tem metodologia como resposta. Ele pede estratificação. Levantar onde o custo da má qualidade se concentra transforma uma dor difusa em três problemas nomeados, e cada um cai numa linha da árvore.

O erro caro: usar DMAIC quando a equipe já sabe a causa

Esse é o erro mais caro do conjunto, e o mais fácil de cometer em empresa que acabou de formar belts. Existe projeto disponível e gente treinada, então o problema vira projeto. Três meses depois, o relatório confirma com significância estatística o que o líder da célula dizia na primeira reunião.

O custo não é só o prazo. É o condutor ocupado, a equipe em coleta e o problema ativo durante todo o período. Causa conhecida que fica três meses esperando prova custa três meses de perda evitável.

O teste para não cair nisso leva cinco minutos. Escreva a causa que a equipe aponta, a ação que ela pede e o que aconteceria se a ação fosse feita amanhã. Se a ação for reversível, faça e meça. O projeto só se justifica se ela falhar.

Existe exceção legítima. Quando a ação é cara, irreversível ou mexe em parâmetro validado com o cliente, a prova antecipada vale o prazo. O critério não é o tamanho do problema: é o custo de errar a ação.

O erro oposto: Kaizen em problema que exigia análise

O outro lado é menos visível porque é barato. Uma semana de evento, todo mundo animado, quadro cheio de ideia e solução implantada na sexta. O indicador não se mexe no mês seguinte, e ninguém revisita a decisão de método.

A assinatura desse erro é a discordância entre turnos. Se um diz matéria-prima, outro diz regulagem e a manutenção diz desgaste, a causa é desconhecida por definição. Evento nenhum resolve disputa de teoria: ele elege a mais bem defendida.

O sintoma seguinte é a reincidência. O problema some por algumas semanas e volta. Isso quase nunca é falta de disciplina na sustentação. É solução aplicada em cima de uma causa que não era a causa, e o ciclo PDCA deveria ter pegado isso na fase de verificação.

Quando isso acontece duas vezes no mesmo problema, pare de tentar. O problema declarou que é crônico e que a causa está em disputa. Ele mudou de linha na árvore e passou a pedir MASP, ou DMAIC se houver variação envolvida.

Por que 5S é quase sempre o primeiro, e qual é a exceção

A razão de o 5S abrir quase todo caminho não é cultural, é de dado. Num posto desorganizado, o tempo de ciclo medido inclui a procura, a espera e o improviso. Qualquer medição feita ali carrega ruído que nenhuma análise separa depois.

A segunda razão é condição básica. Vazamento, sujeira e falta de padrão de inspeção escondem sinal. Um projeto que começa sem enxergar a máquina gasta a fase de medição descobrindo o que a limpeza mostraria em uma semana.

A terceira razão é política e a mais subestimada. O 5S é a primeira coisa que a operação vê mudar sem esperar aprovação de investimento, e esse ganho visível compra a paciência necessária para o projeto longo que vem depois.

A exceção é urgência com dinheiro grande na mesa. Se a planta perde faturamento num gargalo identificado, ou se há risco de recall, começar por organização de posto é resposta errada. Ataca-se o crítico e o 5S entra em paralelo.

Quando o problema é grande demais para uma ferramenta só

Há problemas que não cabem em nenhuma linha da árvore porque não são um problema. São vários, empilhados sob um nome. Reduzir o custo de produção em 15% não é problema: é meta. E meta não tem metodologia, tem desdobramento.

O primeiro movimento é estratificar. Quebre o número grande em parcelas, ordene por peso e escolha as duas ou três maiores. Cada parcela vira um problema com nome, local e indicador próprio, e só aí a árvore volta a funcionar.

O segundo é definir o alvo de cada parcela. Problema sem meta clara não tem critério de encerramento, e projeto sem critério se arrasta. As regras estão em como definir meta de indicador e valem para qualquer caminho.

O terceiro movimento é aceitar que as parcelas pedem caminhos diferentes. É normal terminar com um 5S numa área, um MASP em outra e um projeto de variação numa terceira. Não é falta de foco: é consequência de ler cada problema pelo que ele é.

Maturidade, sequência e os sinais de que você escolheu errado

Numa planta que não tem nada, a sequência que funciona é previsível. Organização de posto e condição básica primeiro, padrão de operação em seguida, depois os eventos de melhoria com causa conhecida. Só então os problemas crônicos, e por último os projetos de variação e o monitoramento contínuo.

A razão da ordem é de pré-requisito, não de dificuldade. Padrão de operação precisa de posto organizado. Análise de crônico precisa de dado, e dado confiável precisa de padrão. Projeto de variação precisa de processo que não oscile por motivo bobo.

Com a maturidade, a escolha muda de eixo. Numa planta madura, os problemas fáceis já foram resolvidos e o que sobra exige análise ou estatística. Empresa avançada faz mais projeto longo não porque é grande, mas porque o estoque de problema simples acabou.

Alguns sinais indicam que a escolha de método foi errada, e todos aparecem antes de o prazo acabar:

• A análise confirma o que a equipe dizia na primeira reunião: era caso de ação, não de projeto.
• O evento termina sem consenso sobre a causa: o problema pedia análise.
• O mesmo problema volta pela terceira vez: a causa tratada não era a causa.
• A carta de controle aponta anomalia toda semana: o processo ainda não é capaz.
• O ganho aparece no relatório e não no resultado da área: o problema escolhido não pesava.
• O projeto estoura o prazo por falta de dado: o método exigia medição que a fábrica não tinha.

Quando um desses sinais aparece, troque de caminho em vez de insistir. Método não é compromisso moral. Se o problema foi lido errado no começo, recomeçar pela árvore custa menos do que terminar o caminho errado.