Qual metodologia de melhoria escolher: as três perguntas que decidem

Eu tenho mestrado em Administração numa federal, especialização em Estatística e formação Master Black Belt. São três diplomas, três bancas e três vocabulários diferentes para falar da mesma coisa. Nenhum dos três me ensinou qual metodologia de melhoria escolher quando um problema real aparece na mesa.

A estatística me deu carta de controle e teste de hipótese. O mestrado me deu processo, indicador e desdobramento de meta. O Black Belt me deu DMAIC, com as cinco fases na ordem certa. Cada formação entrega um martelo excelente. Nenhuma delas ensina a olhar para o prego antes de bater, que é o trabalho de quem decide por onde a melhoria começa.

Levei anos para entender que a dificuldade não estava nos métodos. Estava na pergunta anterior a eles. Quando alguém pede um programa de melhoria e você responde com uma sigla, você já pulou a decisão que importava.

Aprendi isso do jeito caro. A cena se repetiu algumas vezes, e a primeira eu lembro inteira: chegou um problema e eu montei em cima dele o método mais completo que sabia conduzir, com fase de medição, plano de coleta e reunião de análise marcada. Meses depois a análise confirmou o que a operação já dizia na primeira semana. A correção coube numa tarde. O caminho até ela levou um trimestre e a paciência de duas áreas. O método não falhou em nada, fez exatamente o que promete. Quem errou fui eu, na pergunta que deixei de fazer antes de escolher.

Este texto é o mapa que eu queria ter tido. Ele não explica cada metodologia de melhoria por dentro, porque isso já está escrito. Ele responde a uma coisa só: diante do seu problema, qual caminho seguir, e como saber cedo que você seguiu o errado.

Qual metodologia de melhoria escolher, em resposta direta

Responda três perguntas, nesta ordem. Você quer mudar o jeito de trabalhar ou resolver um problema com dono e prazo? A causa já é conhecida? Existe dado histórico do processo? A primeira separa as duas famílias, filosofia e framework. As outras duas escolhem o roteiro dentro da família certa.

Repare no que essa sequência não faz. Ela não pergunta qual metodologia de melhoria é mais completa, nem qual tem mais certificação no mercado, nem qual o concorrente adotou. Essas três perguntas costumam ser as primeiras nas reuniões, e são as três que mais fazem gente escolher errado.

O restante do artigo abre cada pergunta, mostra o que cada resposta indica e, principalmente, diz onde cada caminho falha. Um mapa que só lista opções boas não é mapa, é catálogo, e catálogo nunca decidiu melhoria nenhuma.

A pergunta errada que quase todo mundo faz primeiro

A conversa típica começa assim: qual é melhor, PDCA ou DMAIC? Kaizen ou Lean? Já ouvi as duas dezenas de vezes, em sala de aula e em sala de diretoria. As duas têm o mesmo defeito de construção.

Elas comparam coisas que estão em prateleiras diferentes. É como perguntar se é melhor uma receita ou uma dieta. A receita resolve o jantar de hoje. A dieta muda o que entra na sua casa pelos próximos anos. As duas são melhoria, e servem a horizontes diferentes. Nenhuma das duas substitui a outra: escolher a metodologia de melhoria começa por dizer de qual das duas coisas você precisa.

Existe uma segunda pergunta errada, mais discreta e mais cara. É quando alguém pergunta qual metodologia de melhoria a empresa vizinha usa. A resposta pode até ser verdadeira e ainda assim ser inútil, porque a melhoria que funcionou lá foi escolhida para um problema que não é o seu.

O programa de extensão industrial do NIST, ligado ao Departamento de Comércio dos Estados Unidos, trata melhoria de processo como uma família de abordagens. Quem cataloga de fora, sem vender curso, descreve um conjunto. Quem está dentro tende a defender uma marca.

Então a primeira pergunta útil não é qual metodologia de melhoria adotar. É que tipo de coisa você está escolhendo.

O livro já separa as duas famílias, e quase ninguém repara

Quando eu organizei o meu livro, essa separação virou estrutura antes de virar argumento. Ela está no sumário, e passa despercebida porque ninguém lê sumário procurando um jeito de escolher metodologia de melhoria.

A Parte II abre na página 33 e se chama “Principais Filosofias e Metodologias Empresariais de Melhoria Contínua”. A abertura dela diz: “As filosofias de Melhoria Contínua traduzem as boas práticas de gestão consolidadas ao longo de anos em grandes empresas pelo mundo”. E fecha com a frase que mais importa aqui: “As filosofias são um meio para alcançar resultados, que devem servir de inspiração e serem sempre adaptadas”.

Nessa parte moram nove capítulos, nesta ordem: 5S, metodologias ágeis, as oito disciplinas de Ford, Lean Manufacturing, filosofia Kaizen, Seis Sigma, Lean Seis Sigma, Design for Six Sigma e World Class Manufacturing.

A Parte III abre na página 123 e se chama “Principais Frameworks para Solução de Problemas”. A definição está na primeira linha: “Frameworks são estruturas de trabalho, formas de pensar que consolidam práticas de sucesso para conduzir processos empresariais”. E o objetivo aparece logo ao lado: “oferecer ferramentas e métodos para acelerar a tomada de decisão”.

Nessa parte moram cinco capítulos: ciclo PDCA e SDCA, MASP, relatório A3, ferramenta 5G e método DMAIC, com a variante ágil. Cinco contra nove, e a diferença de tamanho não é acidente. Framework é estrutura enxuta por natureza.

Leia as duas aberturas em sequência e a diferença fica óbvia. As duas partes tratam de melhoria contínua e não tratam do mesmo tipo de decisão. Uma família fala em adaptar ao seu contexto e ao seu momento. A outra fala em acelerar a tomada de decisão diante de um problema. São propósitos distintos, e é por isso que comparar um item de cada lado dá discussão sem fim.

Preciso registrar uma coisa em voz alta, porque ela é fácil de forçar. O livro não tem capítulo que ensine a escolher metodologia de melhoria. A separação em duas partes é um fato de organização do sumário, e foi de lá que eu tirei a primeira pergunta. O mérito da divisão é do livro; a árvore de decisão que vem a seguir é minha, e a responsabilidade por ela também.

Pergunta 1: mudar o jeito de trabalhar ou resolver um problema?

Essa é a bifurcação que resolve metade dos casos. Escreva a demanda que chegou até você numa frase e olhe para o objeto dela. É ele que decide a metodologia de melhoria, e a sua preferência entra depois.

Se a frase fala em cultura, rotina, padrão de área, redução estrutural de desperdício ou maturidade de gestão, você está do lado das filosofias. O horizonte é de anos, o dono costuma ser a liderança da operação e não existe data de encerramento. Isso não é projeto, é jeito de trabalhar, e a melhoria aparece como consequência da rotina nova.

Se a frase fala em um indicador que caiu, uma reclamação de cliente, uma meta não atingida ou um refugo que apareceu no mês passado, você está do lado dos frameworks. Tem começo, tem entregável e tem alguém esperando resposta.

• Sinal de filosofia: ninguém consegue dizer quando o trabalho termina, e isso está correto.
• Sinal de framework: existe um problema nomeável, com magnitude e data de aparecimento.
• Sinal de confusão: a demanda pede cultura mas cobra resultado em noventa dias.

O terceiro sinal é o mais comum e merece atenção. Quando ele aparece, a resposta honesta é dividir a demanda em duas. Roda um framework no problema que está doendo agora e, em paralelo, começa a filosofia com horizonte declarado de anos. Prometer cultura em um trimestre é a maneira mais rápida de queimar as duas melhorias de uma vez.

Uma ressalva de vocabulário, porque a fronteira é borrada de verdade. O próprio livro chama o WCM de metodologia de gestão dentro do capítulo 13 e o coloca na parte das filosofias. Eu uso a divisão como ferramenta de decisão, não como taxonomia oficial. Se numa reunião alguém chamar o DMAIC de metodologia, deixe passar. O que não pode passar é tratar os dois lados como se fossem intercambiáveis.

Se a resposta foi filosofia: onde está a perda?

Dentro da família das filosofias a escolha não é de gosto. Ela sai de onde a sua operação perde dinheiro hoje. Cada metodologia de melhoria desta família foi construída atacando um tipo de perda, e continua boa naquilo e mediana no resto.

• Perda de ordem e de ambiente. Material que ninguém acha, padrão diferente entre turnos, risco visível de segurança. O caminho é o programa 5S.
• Perda de fluxo. A área é organizada e mesmo assim o pedido demora, com estoque parado entre etapas. O caminho é o Lean Manufacturing.
• Perda por variação. O processo entrega certo na média e erra com frequência que ninguém explica. O caminho é o Seis Sigma.
• Perda de equipamento. Quebra, parada não programada e manutenção sempre corretiva. O caminho é a manutenção produtiva total.
• Perda de rotina. As melhorias acontecem, mas dependem sempre das mesmas duas pessoas. O caminho é a filosofia Kaizen.
• Perda de sistema de gestão. Cada área tem o próprio jeito e não existe linguagem comum de qualidade. O caminho é a gestão da qualidade total, ou o WCM.

Se você leu a lista e marcou quatro itens, o diagnóstico não é que a operação precisa de quatro filosofias. É que falta apontamento. Sem número, tudo dói igual, e toda melhoria parece urgente na mesma medida.

O jeito mais barato de descobrir qual perda é a maior cabe em duas semanas. Acompanhe um pedido real de ponta a ponta e anote duas colunas: tempo em que ele foi transformado e tempo em que ele ficou esperando. Depois some as paradas de equipamento do mês e conte as ocorrências de segurança da área. Três números, nenhum sistema novo.

Eu peço esses três números antes de aceitar qualquer conversa sobre programa de melhoria. Quando eles não existem, a escolha da filosofia é chute com nome bonito.

Repare na faixa de baixo do desenho. Três das seis perdas não aparecem nessa medição de duas semanas, e é por isso que ela resolve a primeira escolha, não todas. Se os três números vierem pequenos e o incômodo continuar, a perda é de uma das três de baixo, e aí você vai precisar de série histórica antes de escolher a metodologia de melhoria.

Com esses três números na mão a lista acima deixa de ser menu e vira diagnóstico.

Pergunta 2: a causa já é conhecida?

A partir daqui você está do lado dos frameworks, com um problema nomeado na mesa. E existe uma pergunta que separa dois mundos: alguém já sabe por que isso acontece?

Cuidado com a resposta apressada. Quase sempre existe um palpite forte na área, dito com muita convicção. Palpite não é causa conhecida, e melhoria construída sobre palpite volta. O teste é simples e desconfortável: peça a evidência que sustenta o palpite e veja se ela existe fora da cabeça de quem falou.

Eu demoro a fazer essa pergunta quando o palpite já está escrito no quadro como se fosse causa. É exatamente aí que ela custa menos e vale mais.

• Causa conhecida de verdade. Existe registro, medição ou teste que liga a causa ao efeito. Alguém já mexeu na variável e o problema respondeu.
• Causa suposta. Existe convicção, tempo de casa e uma história convincente. Não existe registro nenhum.

Se a causa é conhecida, o seu problema não é de investigação. É de execução, e a metodologia de melhoria que serve aqui é a mais leve que você conseguir conduzir. O que falta é planejar a contramedida, implantar, checar se funcionou e padronizar. Rodar oito etapas investigativas em cima de uma causa já provada é queimar três meses para reconfirmar o óbvio.

Se a causa é suposta, você precisa de um roteiro que force a investigação antes da solução. É aí que entram os métodos de análise de causa raiz, e a diferença entre eles é a profundidade que o problema merece. Um problema simples e recente pode morrer numa sessão de cinco porquês bem conduzida. Um problema crônico, que já voltou três vezes, não morre.

A American Society for Quality descreve o ciclo de solução de problema em etapas genéricas: definir, gerar alternativas, avaliar, implementar e avaliar de novo. Repare que essas etapas não têm marca. As siglas todas são variações de rigor e de ênfase sobre esse mesmo esqueleto, e é por isso que trocar de sigla raramente resolve alguma coisa sozinho.

Pergunta 3: existe dado histórico do processo?

A terceira pergunta é a mais ignorada e a que mais faz projeto morrer no meio. Antes de escolher uma metodologia de melhoria que se alimenta de dado, olhe se existe dado para comer.

Dado histórico aqui tem um significado estreito. Não é relatório mensal, não é planilha de fechamento e não é o número que o sistema mostra na tela hoje. É série: a mesma medida, do mesmo jeito, ao longo do tempo, com granularidade suficiente para você enxergar como ela varia.

Faça o teste em cinco minutos. Você consegue montar uma carta de controle do indicador do problema com os últimos três meses, sem pedir nada a ninguém? Se a resposta é sim, você tem histórico. Se a resposta é que daria para levantar, você não tem, e levantar vai custar semanas.

Esse teste é o que eu não fiz no caso da abertura, e foi ele que teria me poupado o trimestre.

Com histórico, a metodologia de melhoria que depende de estatística paga o próprio custo. Dá para separar variação comum de variação especial, testar hipótese e provar a causa em vez de argumentar sobre ela. Sem histórico, esses mesmos métodos travam na segunda fase. O time passa meses coletando dado, sem nenhuma melhoria chegando à operação, enquanto o problema segue acontecendo.

Isso não significa que sem dado não se faz nada. Significa que sem dado você escolhe um roteiro que coleta enquanto avança, com observação direta no local do problema e amostra pequena feita à mão. É mais lento por evidência e muito mais rápido para começar.

Três perguntas, três respostas. Elas cabem numa folha, e o desenho a seguir mostra as duas juntas.

A árvore inteira, em um desenho

Duas leituras valem a pena. A primeira segue a linha, com o seu problema na mão, até chegar ao caminho. A segunda vai de trás para a frente, partindo da metodologia de melhoria que a empresa já escolheu, para descobrir qual pergunta ninguém fez.

A segunda leitura costuma ser mais reveladora. Quando um programa está patinando há um ano, quase sempre dá para achar a pergunta que foi pulada lá atrás.

Ficha de decisão: uma linha por caminho

Esta ficha não explica os métodos. Ela diz, em uma linha, para que serve cada metodologia de melhoria, o que ela entrega primeiro e como você percebe que escolheu errado. Se quiser entender um deles por dentro, o link leva ao texto que faz isso direito.

A ficha vem em dois blocos, na mesma ordem da árvore. Primeiro as seis que mudam o jeito de trabalhar, depois os seis que têm começo e fim. É a mesma lógica que separa as partes II e III do livro, com um ajuste meu: o 8D está aqui do lado dos frameworks, porque na prática ele roda como roteiro de problema, ainda que o livro o traga entre as filosofias.

A coluna da direita é a que eu mais uso, e ela existe porque escolha errada não se anuncia. Ela aparece uns meses depois, disfarçada de falta de engajamento. Se o seu projeto de DMAIC chegou ao segundo mês sem linha de base medida, a metodologia de melhoria não está sendo aplicada. Está sendo citada.

Esta ficha sai em PDF logo mais, com as mesmas doze linhas em duas folhas. Ela foi feita para ser impressa e levada para a reunião que decide a metodologia de melhoria, não para ser lida no celular durante essa mesma reunião.

Onde cada metodologia de melhoria falha

Todo material sobre esses métodos fala do que eles resolvem. Quase nenhum fala de onde eles quebram. E é justamente o lugar onde quebra que separa a escolha certa da escolha cara.

O PDCA falha quando não existe padrão anterior. Ele compara um estado novo com um estado antigo. Se o jeito de fazer muda de pessoa para pessoa, não existe o antes, e o ciclo gira sobre o vazio. Não é opinião minha: no livro, PDCA e SDCA dividem o mesmo capítulo, o de número 14, porque o segundo existe para estabelecer o padrão que o primeiro vai melhorar. A diferença entre os dois ciclos tem texto próprio no blog. Ele falha também num lugar mais banal, quando o A do Act nunca acontece. Aí o ciclo vira reunião mensal com a mesma pauta e nenhuma melhoria implantada entre uma reunião e a seguinte.

O MASP falha em problema que não é crônico. As oito etapas foram desenhadas para durar, com registro em cada uma, e isso é uma vantagem enorme quando o problema já voltou várias vezes. Aplicado a um desvio que apareceu na semana passada, a mesma metodologia de melhoria vira burocracia. Você entrega o relatório depois que o problema já sumiu sozinho.

O DMAIC falha sem dado e sem variação. São dois modos distintos de falhar. Sem série histórica, as fases de definição e medição consomem meses antes de qualquer melhoria chegar à operação. E quando o problema não é de variação, mas de fluxo ou de disciplina, o ferramental estatístico não tem em que morder. O sintoma clássico é o projeto que chega na fase de análise e descobre que a causa era óbvia desde o primeiro dia. O conserto era barato; a metodologia de melhoria escolhida para chegar até ele é que saiu cara. Esse é o erro da abertura deste texto, e é dele que saiu a árvore que eu desenhei aqui.

O A3 falha quando vira formulário. A folha única obriga a sintetizar, e o espaço é só o instrumento. Preenchida por quem não foi ao local do problema, ela deixa de ser síntese e vira uma página de opinião bem diagramada. O teste é olhar a seção da situação atual e ver se há um fato observado ou uma interpretação.

O 8D falha fora do contexto de cliente. Ele nasceu com ação de contenção logo no começo, porque existe alguém do outro lado recebendo peça ruim agora. Sem esse alguém, a etapa de contenção não faz sentido e o time inventa uma para preencher o campo. Rodar 8D em melhoria interna costuma ser sinal de que o que se quer ali é o formulário.

O 5S falha quando a perda é de fluxo. A área fica impecável, o quadro de auditoria fica verde, e o pedido sai na mesma data de sempre. Esse desencontro é tão comum que ganhou um texto só dele, na lista de pares mais adiante. O resumo é que ordem no posto não conserta espera entre postos.

O Lean falha sem estabilidade básica. Puxar produção num processo que para sem aviso transforma cada parada em falta na etapa seguinte. Se o equipamento é instável, reduzir estoque intermediário deixa o problema mais visível e a operação mais frágil ao mesmo tempo. A ordem importa: estabilizar primeiro, puxar depois.

O Seis Sigma falha em processo pouco repetitivo. Ele precisa de volume para que a estatística signifique alguma coisa. Em processo de baixa repetição a amostra nunca fecha, e a metodologia de melhoria vira teatro de rigor. Não tenho um limiar publicado para oferecer aqui, e desconfio de quem oferece um. O que dá para dizer com honestidade é isto: se juntar algumas dezenas de ocorrências do mesmo defeito exige esperar o ano virar, o ferramental estatístico vai chegar depois da hora.

O Kaizen falha sem liderança presente. A filosofia depende de melhoria feita por quem executa, e melhoria feita por quem executa só se sustenta quando a liderança aparece, responde e implanta. Sem isso, o programa vira caixa de sugestões. E caixa de sugestões não morre de rejeição, morre de silêncio: as pessoas param de escrever quando percebem que ninguém do outro lado responde.

O TPM falha quando a perda não é de equipamento. É a falha mais cara da lista, porque o TPM é pesado de implantar. Antes de começar, olhe a composição das suas paradas. Se a maior fatia é troca de produto, falta de material ou falta de pedido, o problema não é manutenção.

TQM e WCM falham quando são tratados como projeto com prazo. São sistemas de gestão, e sistema de gestão não tem data de entrega. Toda vez que alguém promete implantar um dos dois em doze meses, o que é entregue no décimo segundo mês é documentação.

Se você leu a lista inteira e reconheceu a sua empresa em duas ou três, isso é normal e não é má notícia. É o mapa funcionando ao contrário: em vez de escolher a próxima metodologia de melhoria, você acabou de descobrir por que a atual não anda.

A tabela de decisão para imprimir

É a árvore virada em tabela, com as doze linhas, para caber na parede de uma sala de reunião. Cada linha abre com um sintoma que dá para descrever sem nenhum sistema e segue com a metodologia de melhoria indicada. Depois vêm a primeira entrega que você deve cobrar e a coluna que quase nunca aparece nesse tipo de material: o sinal de que a escolha foi errada. O PDF sai em duas folhas na horizontal, na mesma ordem da árvore: as filosofias numa, os frameworks na outra. Se o sinal da última coluna apareceu, volte à pergunta anterior em vez de insistir no método.

Baixe a tabela de decisão em PDF

Uma sugestão de uso que economiza discussão, e que a gente aplica nas turmas da Voitto quando a sala trava. Antes da reunião que vai decidir o caminho, peça que cada participante marque sozinho a linha que descreve o problema. Depois compare as marcações. Quando as pessoas marcam sintomas diferentes, o desacordo nunca foi sobre a metodologia de melhoria.

Três problemas reais passando pelas perguntas

A árvore é fácil de concordar e difícil de aplicar na primeira vez. A metodologia de melhoria que parece exagerada num caso é exatamente a que serve no caso seguinte. Então vão três casos, escritos como eles chegam de verdade, com a resposta de cada pergunta.

Caso um. “O refugo da linha 3 subiu de dois para cinco por cento desde março e ninguém sabe por quê.” Pergunta 1: é problema com dono e prazo, então framework. Pergunta 2: a causa é desconhecida de verdade, porque existem três palpites concorrentes e nenhuma evidência. Pergunta 3: existe apontamento de refugo por turno desde o ano passado, então há histórico. Caminho: DMAIC, e a fase de análise tem com que trabalhar.

Caso dois. “Um cliente devolveu um lote e cobrou relatório em cinco dias.” Pergunta 1: framework, sem dúvida. Pergunta 2: causa desconhecida. Pergunta 3: histórico é irrelevante aqui, porque o prazo manda. Caminho: 8D, que começa protegendo o cliente enquanto a investigação corre. Rodar DMAIC nesse caso seria tecnicamente elegante e comercialmente suicida.

Caso três. “A diretoria quer um programa de melhoria contínua na fábrica inteira.” Pergunta 1: filosofia, e aqui a árvore muda de ramo. A pergunta seguinte é onde está a perda, e a resposta honesta na maioria das fábricas é que ninguém sabe. Caminho: as duas semanas de medição descritas antes, e só depois a escolha da filosofia. Começar pelo programa é escolher a metodologia de melhoria antes de saber que pergunta ela responde.

Os três casos têm uma coisa em comum. Em nenhum deles a decisão dependeu de qual metodologia de melhoria é mais completa. Dependeu do tipo de problema, que é a única coisa dessa história que você não escolhe.

Cinco erros que fazem a escolha nascer errada

Estes cinco eu vi de perto mais vezes do que gostaria, e três deles eu já cometi.

• Escolher pelo que a equipe já sabe. É confortável e às vezes é certo. Vira erro quando o método que a equipe domina não serve ao problema e ninguém quer dizer isso em voz alta.
• Escolher pelo que o mercado certifica. A certificação diz que existe treinamento disponível, não que aquela metodologia de melhoria sirva ao seu caso.
• Escolher o mais completo. A metodologia de melhoria mais completa custa caro em tempo e em atenção. Para problema pequeno, completude é desperdício.
• Escolher tudo ao mesmo tempo. Três frentes simultâneas com as mesmas pessoas entregam três projetos pela metade e nenhuma melhoria inteira.
• Não escolher. A empresa fala em melhoria há dois anos, tem comitê, tem apresentação e não tem caminho. Esse é o mais comum dos cinco.

O quarto erro tem uma correção barata. Antes de abrir a segunda frente, ponha as candidatas numa matriz de esforço e impacto e comprometa o time com uma só. A matriz não vai revelar nada que o time não saiba; ela serve para tornar público o que já era sabido, e é isso que impede a terceira frente de nascer.

O quinto erro merece uma palavra a mais. Não escolher parece prudência, mas é a decisão mais cara da lista: queima o combustível da operação com o motor em ponto morto, e credibilidade não se repõe no tanque seguinte. Depois de dois anos de comitê, o próximo programa começa com a operação já descrente.

Quando a disputa é entre dois candidatos específicos

Às vezes a árvore leva você até dois finalistas e para ali. É a hora certa de comparar par a par, e cada uma dessas comparações tem um texto inteiro dedicado a ela.

• MASP ou DMAIC. Os dois investigam causa desconhecida e a escolha entre eles quase sempre cai na pergunta 3. MASP ou DMAIC, comparados passo a passo.
• PDCA ou DMAIC. Um é ciclo de gestão que nunca termina, o outro é projeto com começo e fim. Onde cada um começa e termina.
• Kaizen ou Lean. A confusão mais frequente das filosofias, porque os dois vieram do mesmo lugar e não são a mesma coisa. A diferença explicada.
• TPM ou TQM. Um ataca perda de equipamento, o outro é sistema de gestão da qualidade inteiro. Quando cada um se aplica.
• 5S ou Lean. O par que mais gera programa frustrado, porque um é porta de entrada do outro. Onde um termina e o outro começa.

Um aviso sobre esses cinco textos. Nenhum deles vai dizer que uma metodologia de melhoria é melhor que a outra, porque a pergunta não tem essa resposta. Todos dizem em que situação cada um ganha, que é a única forma útil de comparar.

Escolher uma metodologia de melhoria não é casar com ela

Existe um medo legítimo por trás da paralisia de escolher: e se eu errar. A resposta é que você vai errar algumas vezes, e que isso custa muito menos do que não escolher, desde que você tenha combinado como perceber o erro.

É por isso que a coluna do sinal de escolha errada existe na tabela. Ela transforma a metodologia de melhoria errada numa informação que chega em trinta dias, em vez de virar descoberta no fim do ano.

No começo deste texto eu citei a frase que fecha a abertura da Parte II: as filosofias são um meio, não um destino, e pedem adaptação sempre. Eu estendo a frase aos frameworks por minha conta, porque o problema é o mesmo. Adaptar não é diluir. É reconhecer que a melhoria veio de um contexto que não é o seu, e que a parte dele que não cabe aqui não precisa ser carregada.

Eu levei três formações para entender isso, e foi um baita atalho descobrir que a pergunta vinha antes do método. Você acabou de ler em menos de meia hora.

Por onde começar esta semana

Se você chegou até aqui procurando uma decisão, faça três coisas antes da próxima reunião.

• Escreva a demanda que chegou até você em uma frase e classifique: filosofia ou framework.
• Peça a evidência do palpite mais forte da área. Se ela não existir fora da conversa, a causa é desconhecida.
• Tente montar a série do indicador com três meses. O tempo que isso levar já responde a pergunta 3.

Com essas três respostas na mão, a escolha da metodologia de melhoria leva quinze minutos. Sem elas, leva seis reuniões e continua sendo palpite.

Se você quiser o assunto todo em ordem, com as filosofias e os frameworks separados como aparecem aqui, é exatamente esse o desenho do Guia Prático Lean Seis Sigma Black Belt. A Parte II cobre as filosofias e a Parte III, os frameworks. Para levar as ferramentas prontas para a operação, a gente reuniu no kit de ferramentas Lean Seis Sigma os modelos que aparecem nos capítulos. E se a decisão vier acompanhada de formação, as Academias de Certificação são o caminho que a gente montou para quem quer a trilha inteira.