O que eu aprendi vendo o Sistema Toyota de perto

Eu passei uma semana dentro do Sistema Toyota, em San Diego, numa imersão conduzida por instrutores japoneses. Voltei com um incômodo que levou anos para virar frase. As ferramentas eu soube descrever assim que cheguei. O incômodo me custou anos de tentativa e erro dentro de empresa brasileira.

O incômodo era esse: eu tinha visto o Sistema Toyota funcionar na frente dos meus olhos e não sabia dizer o que exatamente deveria ser copiado. Dava para descrever o cartão, o quadro na parede, a linha parando. Só que a coisa que sustentava aquilo não estava em nenhum desses objetos. Faltava vocabulário para nomear o que eu tinha visto.

Este texto é o que sobrou depois de anos usando o Sistema Toyota em lugares que não fabricam carro. É a resposta para uma pergunta prática: o que uma pessoa realmente leva embora de uma visita técnica, e o que ela carrega para casa achando que levou.

Antes de começar, o que este artigo não tem. Não tem diálogo com sensei, não tem cronômetro na minha mão e não tem o número da linha que eu vi naquela semana. Eu não registrei aquilo na época e não vou inventar agora para deixar a história mais bonita. O que eu tenho é o que veio depois.

E o que veio depois é a parte útil. Foram anos levando o Sistema Toyota para dentro de operação brasileira, em indústria e em serviço, descobrindo uma por uma quais peças viajam e quais quebram na bagagem. A conclusão está na tabela de decisão que fecha o artigo, e ela sai em PDF para você levar na sua próxima visita.

O Sistema Toyota, em resposta direta

O Sistema Toyota que eu vi de perto não era um conjunto de ferramentas. Era um jeito de decidir: quem para a linha, quem responde ao problema e em quanto tempo. As ferramentas eram a parte visível de um acordo anterior, e o acordo é a parte que viaja mal.

Vale olhar o que essa frase implica para quem visita. Do Sistema Toyota, quem entra na fábrica vê objetos: cartão, quadro, luz, marcação no chão, prateleira com endereço. Isso é fotografável e barato, e é exatamente por isso que quase toda tentativa de cópia começa por aí. A seção seguinte conta a minha primeira versão desse erro, com nome de empresa e com o motivo pelo qual aquilo se desligou.

O que não é fotografável é o combinado: quando um operador aperta o botão e a linha para, ninguém vai perguntar por que ele parou. Vão perguntar o que apareceu. A diferença entre essas duas perguntas é a diferença entre o Sistema Toyota de Produção e uma fábrica com quadro bonito.

Eu levei uns bons anos para entender que essa era a peça central do Sistema Toyota, e não um detalhe cultural simpático. Enquanto eu achei que era detalhe, eu implantei ferramenta. Depois que entendi que era a peça central, comecei a implantar outra coisa, e o resultado mudou de tamanho.

A visita técnica que me ensinou a olhar

Muito antes de San Diego, eu já fazia visita técnica, e fazia mal. Na Votorantim Metais, na unidade de zinco, eu liderei um programa de visitas a outras unidades do grupo, incluindo Niquelândia. A palavra bonita para isso é benchmarking, e a prática real, no começo, era um passeio com máquina fotográfica. O vocabulário japonês não faltava na unidade, e eu mesmo fiz formação com uma certificadora japonesa de TPM enquanto aquilo acontecia. Faltava a pergunta, e o erro que a gente cometia era exatamente o que o Sistema Toyota resolve.

O padrão se repetia com uma regularidade quase cômica. A gente ia, via alguma coisa boa, voltava animado e montava a mesma coisa lá. Pouco tempo depois aquilo estava desligado. A explicação sempre vinha na mesma forma: aqui é diferente, o pessoal não comprou a ideia e o gestor de lá tinha mais gente.

O que mudou o jogo foi trocar a pergunta que a gente levava na prancheta. Em vez de anotar o que a outra unidade fazia, a gente passou a anotar o que a outra unidade tinha decidido para poder fazer aquilo. Quem tinha autoridade para parar. Quem era acionado. Qual era o prazo combinado de resposta. Quanto tempo aquilo já rodava.

A diferença apareceu no programa de manutenção autônoma que a gente estava tocando. Copiar a lista de checagem do vizinho era fácil e não mudava nada. Copiar a decisão de que o operador registra a anomalia e alguém tem obrigação de responder mudou tudo. Essa parte não estava em nenhuma foto que a gente tinha trazido.

Ver o Sistema Toyota em San Diego foi essa mesma lição em escala maior e com sotaque japonês. A imersão me deu o vocabulário para nomear o que eu já tinha tropeçado em Niquelândia. Virou confirmação com nome próprio, e nome próprio é o que permite ensinar aquilo para outra pessoa em vez de fazer ela repetir a experiência inteira.

O que o livro diz e a parte que ele deixa em aberto

No livro que eu escrevi, a definição de Lean Manufacturing abre justamente por aí. O capítulo 8, ao apresentar o trabalho de Jeffrey Liker, diz que "o Sistema Toyota de Produção não se trata apenas de ferramentas, e sim de uma cultura organizacional ancorada na filosofia, em pessoas, processos e solução de problemas" (p. 60).

A frase resume o que Liker publicou em The Toyota Way, em 2003, e ela é verdadeira. O problema é que ela é verdadeira do jeito que "coma bem e durma cedo" é verdadeiro. Ninguém discorda, e ninguém sai da leitura sabendo o que fazer na segunda-feira de manhã.

Vou complicar a minha própria frase, então. Dizer que o Sistema Toyota é cultura e não ferramenta costuma virar desculpa para não implantar nada: como cultura demora, a gente espera ela chegar. Eu já usei esse argumento e ele é confortável demais para ser honesto.

A leitura útil é outra. A palavra cultura aqui está longe de clima organizacional e de valor na parede. É o conjunto de decisões que já foram tomadas e que ninguém precisa tomar de novo toda vez. Quem para a linha já está decidido. O que acontece com quem para já está decidido. Quem aparece quando o problema aparece já está decidido.

Decisão tomada previamente é escrevível, treinável e auditável. A parte do Sistema Toyota que parecia intangível é justamente a que cabe num documento de uma página. E é por isso que este artigo termina numa tabela em vez de terminar num apelo à mudança de mentalidade. Se você quiser o desenvolvimento completo, ele está no Guia Prático Lean Seis Sigma.

O Sistema Toyota nasceu de uma restrição, não de uma boa ideia

Vale lembrar de onde isso saiu, porque a origem explica o comportamento. O modelo se formou no Japão do pós-guerra, e o Sistema Toyota é filho de um país sem capital, sem escala e sem mercado interno que justificasse lote grande. A Toyota não escolheu ser enxuta por elegância. Ela não tinha dinheiro para ser gorda.

Isso muda a leitura de tudo o que vem depois. Estoque baixo ali era consequência de não haver caixa para financiar estoque. A troca rápida de ferramenta virou obrigação. Era o único jeito de fazer lote pequeno sem quebrar o caixa. Cada prática nasceu como resposta a uma restrição concreta, e é essa restrição que a gente esquece de trazer junto quando copia a prática.

A epígrafe que abre esse capítulo do livro é do próprio Ohno e resume a lógica: "o progresso não pode ser gerado quando estamos satisfeitos com situações existentes" (p. 59). Satisfação com o que já existe era exatamente o luxo que aquela Toyota não podia bancar.

O nome produção enxuta nem é japonês, aliás. Ele se popularizou em 1990, com o livro de Womack, Jones e Roos, quando pesquisadores ocidentais foram estudar por que as montadoras japonesas produziam com menos de tudo. Quem organizou aquilo em sistema no chão de fábrica foi Taiichi Ohno, décadas antes de alguém dar um nome em inglês para o que ele fazia. O verbete do Lean Institute Brasil guarda a mesma ordem: define o TPS pela eliminação do desperdício e pelos dois pilares, e só depois chega em ferramenta.

Guarde essa ordem, porque ela tem consequência prática. No Sistema Toyota veio primeiro a restrição, depois a prática, e só muito depois o nome. Quando uma empresa começa pelo nome, ela inverte a sequência inteira e fica com a casca. Foi o que eu fiz nos primeiros anos, e a lista dos cinco erros que eu cometi copiando errado mostra o resultado.

A casa, que é o único desenho que eu ainda uso

Dos desenhos do Sistema Toyota que eu vi naquela semana, um sobreviveu a todos os outros na minha cabeça: a casa. Está no livro como Figura 8.1 e é a forma mais honesta de mostrar por que a cópia por partes não funciona.

A base tem dois níveis. Embaixo de tudo fica a estabilidade, e logo acima dela o nivelamento da produção, o trabalho padronizado e a melhoria contínua. Os dois pilares são o Just in Time e o Jidoka, os mesmos dois que a própria Toyota nomeia na página oficial do Toyota Production System. O telhado é o foco no cliente, e no meio da casa ficam as pessoas. É um desenho de arquitetura, e arquitetura tem uma propriedade que checklist não tem: você não pode instalar o telhado antes da fundação e chamar aquilo de meia casa.

Quem tenta implantar pilar sem base descobre isso na prática, geralmente com custo alto. Estoque baixo numa operação instável não gera fluxo, gera parada. Autonomia para parar a linha numa operação sem trabalho padronizado produz briga sobre o que é ou deixa de ser problema.

Foi essa a pergunta que eu passei a fazer em toda visita técnica: o que essa empresa arrumou ANTES do que ela está me mostrando agora? Quem visita o Sistema Toyota vê o telhado pronto e não vê as décadas de fundação. Sem essa pergunta, melhoria contínua vira campanha de cartaz.

Os oito desperdícios funcionam apontados para o processo e morrem dentro de um formulário

A primeira coisa que a gente aprende a listar são os oito desperdícios. O Quadro 8.2 do livro nomeia assim, com característica e causa de cada um: defeitos e retrabalho, excesso de produção, processamento impróprio, transportes desnecessários, movimentos desnecessários, estoque, espera e intelectual (p. 62). É a lente básica do Sistema Toyota para olhar processo, e é o quadro que eu ainda consulto.

E aqui mora uma armadilha que eu caí com gosto. Transformar essa lista em formulário de auditoria é o caminho mais rápido para transformar um instrumento de enxergar em mais uma obrigação de preencher. Eu já vi equipe classificando desperdício em planilha durante semanas sem que uma única coisa mudasse no chão.

A lista funciona quando ela é usada de outro jeito: como pergunta feita em pé, no lugar onde a coisa acontece. Por que essa peça está esperando? Quem decidiu que ela viria em lote de duzentas? Essa conferência aqui pega o quê, e quantas vezes por mês ela pegou alguma coisa?

O último item da lista é o que mais dá retorno e o que menos aparece em apresentação de Sistema Toyota. O livro chama de desperdício intelectual, e no chão ele tem cara de pessoa que sabe onde está o problema desde antes de você chegar e nunca foi perguntada. Em toda operação que eu entrei, essa foi das maiores reservas de ganho que eu encontrei, e ela não exige investimento nenhum para ser acessada.

Uma observação sobre a fábrica de carro e a rede de fast food estarem no mesmo roteiro. Ver os dois na mesma semana parece erro de agência de viagem, e é o argumento inteiro da imersão. Os oito desperdícios aparecem igualzinho no balcão de um restaurante, e ver isso com os próprios olhos vale mais do que qualquer slide dizendo que o método é universal.

Just in Time é consequência, e quase todo mundo trata como partida

O pilar do Just in Time é a peça certa, na quantidade certa, no momento certo. Dito assim parece meta de estoque, e é aí que a leitura desanda. No Sistema Toyota, o Just in Time é o que sobra quando o resto está estável o bastante para permitir que o estoque desça sem parar a operação.

Os instrumentos que sustentam isso são conhecidos. O kanban controla a reposição pelo consumo real em vez de previsão. O heijunka nivela o mix para que a demanda chegue distribuída e não em ondas. O takt time amarra o ritmo da produção ao ritmo do cliente em vez do ritmo da máquina mais rápida.

Os três pressupõem alguma previsibilidade, e é aí que a implantação tropeça. Kanban com fornecedor que atrasa dois dias em cada cinco entregas programa a falta em vez de puxar a produção. Nivelamento com equipamento que quebra sem aviso é planilha de faz de conta. Cada um deles importa uma dívida de estabilidade que alguém vai pagar depois. O lead time prometido ao cliente é a primeira parcela.

Por causa disso eu inverti a ordem de implantação do Sistema Toyota nos meus projetos. Antes de mexer em estoque, passei a medir quantas vezes por mês a operação para sem estar programada para parar. Enquanto esse número está alto, mexer no pilar antecipa problema, e a conta chega em forma de cliente sem atendimento.

Jidoka: quem pode parar a linha já foi decidido antes de a linha parar

O outro pilar é o Jidoka, que costuma ser traduzido como automação com toque humano. A tradução operacional é mais simples: o processo para sozinho quando algo sai do padrão, e quem está ali tem autoridade para parar também. A parte automática mora nos dispositivos de poka-yoke. Eles impedem o erro em vez de avisar depois.

Foi o que mais me impressionou no Sistema Toyota, e por um motivo que não é o esperado. A linha parando é a parte fácil de contar. A parte que eu levei anos para copiar é o que vem em seguida. Alguém chega, dentro de um prazo que já estava combinado antes, e chega porque a chegada é obrigação escrita muito antes de alguém precisar dela.

Na maioria das empresas onde eu trabalhei, parar era um ato de coragem pessoal. Quem parava gastava capital político e ia responder depois por que tinha parado. Com esse desenho, o operador aprende rápido que sai mais barato deixar passar, e o sistema inteiro perde a única fonte de informação que ele tinha em tempo real.

Por isso a autonomia de parar, sozinha, não é o Sistema Toyota: é meia ideia, e meia ideia costuma ser pior que nenhuma. A autonomia precisa vir com a contrapartida de resposta garantida, com prazo e com nome de quem responde. E quando alguém aparece, a conversa começa com os 5 porquês sobre o processo, nunca com uma pergunta sobre a pessoa que apertou o botão.

O que dá para trazer de uma visita técnica

Depois de repetir esse ciclo em várias operações, fechei uma lista curta. É o que, no Sistema Toyota, realmente atravessa a fronteira de uma empresa para outra. Ela é bem mais curta do que a lista do que a gente tem vontade de trazer.

• A regra de decisão. Quem pode parar, quem responde, em quanto tempo. Cabe em três linhas e vale mais que o resto do caderno inteiro.
• O prazo de resposta. Não o processo de escalada em fluxograma, mas o número de minutos combinado até alguém aparecer no lugar do problema.
• A pergunta que eles fazem. Toda operação madura tem uma pergunta padrão que todo mundo faz diante de um desvio. Anotar essa pergunta é levar o método embora.
• O que eles arrumaram antes. A ordem em que as coisas foram estabilizadas, que quase nunca está no roteiro e você precisa perguntar.
• O que eles tentaram e abandonaram. É a informação mais barata de conseguir e a que mais economiza tempo, porque evita que você repita o erro deles com sotaque.

E o que não atravessa: o layout, o software, o formulário, o nome do programa e o quadro da parede. Tudo isso é saída de um contexto que ficou lá. Ir ao gemba de outra empresa serve para entender decisão em vez de colecionar formato.

O que eu copiei errado nos primeiros anos

Minhas primeiras cópias do Sistema Toyota custaram caro. Por isso a lista vem inteira, sem o filtro que me faria parecer mais esperto do que eu fui.

• Comecei pelo visual. Montei gestão à vista bonita em área que não tinha ninguém encarregado de olhar o quadro. Virou decoração e ninguém deu falta quando o quadro parou de ser atualizado.
• Copiei o indicador sem copiar a reação. O painel media a coisa certa e não existia combinado sobre o que fazer quando o número saía da faixa.
• Implantei rotina de operador sem tocar na rotina do chefe. A anomalia passou a ser registrada e continuou sem destinatário, o que ensinou a equipe a não registrar mais.
• Tratei ferramenta japonesa como pacote fechado. Levei o nome junto, e o nome estrangeiro criou uma barreira desnecessária com gente que resolveria o problema em português.
• Medi adesão em vez de resultado. Percentual de checklist preenchido subiu durante meses enquanto o problema que motivou tudo aquilo seguia igual.

O denominador comum é o mesmo em todos os cinco. Eu levei a parte que aparece na foto e deixei lá a parte que estava no combinado. Não é falta de esforço, é erro de recorte, e erro de recorte não se resolve trabalhando mais.

Fábrica, ferrovia e balcão: o que muda de verdade

Uma dúvida legítima aparece sempre nesse ponto: isso serve para quem não tem linha de produção? Eu passei parte da carreira em operação ferroviária, na MRS Logística, e boa parte do trabalho de hoje é com escritório e serviço. A resposta curta é que serve, com uma tradução que precisa ser feita a sério. O Sistema Toyota trata de fluxo, e o carro é só o objeto que fluía na fábrica onde ele nasceu.

O que muda é a unidade de fluxo. Na fábrica, o que anda pela linha é uma peça, e ela é visível. Em lean office e em serviço, o que anda é um pedido, um processo, uma solicitação, e ele é invisível: fica dentro de sistema, de caixa de entrada, de aprovação pendente. Ninguém tropeça num pedido parado.

Essa invisibilidade tem uma consequência direta. Na fábrica o estoque grita, porque ocupa espaço físico e alguém esbarra nele. No escritório o estoque é silencioso, e por isso a primeira coisa a fazer é tornar visível quantos itens estão parados, onde e há quanto tempo. Reduzir vem depois, quando já dá para enxergar o que está sendo reduzido.

O que não muda é a regra de decisão, e é a mesma pergunta da lista do que atravessa a fronteira. Na ferrovia, em analista de crédito e em balcão de atendimento, ela é literalmente a mesma. Só o objeto que para é diferente.

Foi por isso que a rede de fast food estava naquele roteiro. Duas operações sem nenhuma semelhança de produto, rodando o mesmo Sistema Toyota de decisão. Se aquilo cabe entre um carro e um hambúrguer, cabe entre a sua operação e a que você foi visitar.

A tabela que eu levo hoje em toda visita

Isto é o que eu preencho durante a visita, com a caneta na mão. Vale para o Sistema Toyota e vale para qualquer benchmarking. A quinta coluna é a que mais importa e a que quase nenhum relatório de benchmarking traz: a condição que derruba aquela regra.

Cada uma dessas seis condições veio de algum lugar, e condição de falha sem origem é palpite. A da última linha eu paguei para aprender. Ela já apareceu aqui com outro nome: painel que mede a coisa certa sem nenhum combinado sobre quem reage ao número. A da primeira linha vem do livro, que põe trabalho padronizado na base da casa e não no telhado. Sem padrão escrito, a parada por desvio vira mesmo discussão de opinião. As quatro do meio a sua operação responde sozinha, com dado que ela já tem. Quantas das últimas vinte entregas do fornecedor atrasaram. Quantos picos de demanda do último trimestre não eram negociáveis. Quanto do trabalho do time é decidido na hora. Quantas análises de causa terminaram em nome de pessoa. Nenhuma delas pede que você acredite em mim.

Preenchida assim, a tabela devolve algo que uma galeria de fotos não devolve. Ela separa o que você pode implantar na semana que vem do que exige preparo anterior, e diz em voz alta qual é o preparo. Sem essa separação, a visita vira animação passageira.

Quando o Sistema Toyota não é o caminho

Existem situações em que aplicar o Sistema Toyota é a decisão errada, e dizer isso costuma render olhar torto em evento do setor. Vão as três que eu encontro com mais frequência.

A primeira é operação em crise aguda, com risco real de não existir no trimestre seguinte. O modelo é de melhoria incremental e sustentada, e o retorno vem em meses. Eu vivi essa situação na Voitto, em 2015: a gente faturava alto e gastava mais alto ainda, e chegou no fundo do poço financeiro. O que tirou a empresa de lá foi uma troca de modelo de entrega, gravando os cursos que eram presenciais e migrando tudo para o digital. Estabilização de processo, naquele momento, teria servido de anestesia.

A segunda é operação de exploração, onde o produto ainda está sendo descoberto. Reduzir variação é ótimo quando você sabe o que precisa ser repetido. Quando a pergunta ainda é o que fazer, padronizar cedo congela a resposta errada. É a mesma virada da Voitto do parágrafo acima, olhada pelo outro lado. A gente mergulhou em EAD e micro-learning sem saber onde estava entrando. Não havia padrão a proteger, porque ainda não se sabia qual era o produto. Nessa fase a variação é a própria busca.

A terceira é a mais delicada: ambiente onde a relação entre chefia e equipe está quebrada. O Sistema Toyota inteiro depende de confiança e é o primeiro a ruir sem ela. Todo o desenho depende de alguém levantar a mão e dizer que tem um problema. Onde levantar a mão custa emprego, o sistema passa a funcionar ao contrário. Os relatórios ficam lindos e a realidade fica escondida. Dá para medir isso antes de começar: conte quantos registros de anomalia dos últimos três meses foram abertos por quem executa, e não por quem supervisiona. Numa operação que tem problema todo dia, um número perto de zero já é a resposta.

Nessa terceira situação existe uma variação perversa que vale citar. A empresa implanta tudo, os indicadores melhoram no papel e a operação piora no chão, porque o dado passou a ser produzido para a reunião. Quando isso acontece, o problema nunca é a ferramenta, e trocar de ferramenta é a reação mais comum.

As cinco condições em que cada regra deixa de valer

A parte mais útil de qualquer regra é a condição em que ela para de valer. Sem isso a pessoa aplica a regra fora de contexto, o resultado não vem e ela conclui que o Sistema Toyota não serve para o caso dela. Então aqui vai a lista, uma por uma, com o que fazer no lugar.

• "Comece pela estabilidade" falha em operação nova. Não existe processo estável para partir quando o processo ainda não existe. Foi o meu caso no primeiro escritório da Voitto, com 32 pessoas e o modo de fazer sendo inventado enquanto a gente fazia. Aqui a ordem se inverte: primeiro você define um jeito qualquer de fazer, ainda que ruim, e depois estabiliza. Estabilizar o nada é a forma mais elegante de não começar nunca.
• "Reduza estoque" falha quando o estoque é proteção contra risco de fornecimento. Se a peça vem de um único fornecedor a quatro semanas de distância, aquele estoque está comprando disponibilidade. A pergunta correta é quanto custa esse seguro comparado ao que custa a falta. Essa conta é fechada: o custo de carregar aquele estoque durante o prazo de reposição contra o custo de parar a operação por esse mesmo prazo. É a mesma condição que a quinta coluna da tabela de visita técnica registra linha a linha. Enquanto essa conta não é feita, cortar estoque é aposta, e às vezes o seguro sai barato e a resposta é manter.
• "Padronize o trabalho" falha em atividade de julgamento. Eu sou auditor líder ISO 9000 pela IRCA, e auditoria é o caso extremo disso. O roteiro de perguntas se padroniza, mas o que faz a auditoria valer alguma coisa é o auditor decidir, na hora, qual evidência puxar a partir do que acabou de ouvir. Em diagnóstico, em negociação e em projeto vale o mesmo: o valor está na variação que o profissional traz. O que se padroniza ali é o contorno: quais informações precisam existir antes da decisão, e qual é o registro depois. Padronizar o miolo destrói o serviço.
• "Dê autonomia para parar" falha sem contrapartida de resposta. É o erro mais caro dos cinco e ele está na minha própria lista do que eu copiei errado, no item da rotina de operador sem rotina de chefe. A anomalia passou a ser registrada, continuou sem destinatário e a equipe aprendeu a não registrar mais. Essa lição leva anos para ser desfeita.
• "Vá ao chão ver com os próprios olhos" falha quando a presença é fiscalização. Eu fui coordenador de operações da MRS Logística em Lafaiete por dois anos, chefe dos inspetores que chefiam os maquinistas. A lição que ficou de lá é que a chegada do chefe muda o que está acontecendo no pátio. Em ambiente de baixa confiança você volta com dado pior do que o do relatório, e a saída é ir com pergunta combinada e sem consequência anexada.

E o caso que ninguém discute: o que fazer quando duas regras se chocam. O choque clássico é entre padronizar e dar autonomia. A regra de desempate que eu uso é olhar a consequência do erro. Onde errar é caro ou irreversível, o padrão ganha e a autonomia fica no direito de parar. Onde errar é barato e reversível, a autonomia ganha e o padrão vira referência.

O segundo choque frequente é entre reduzir estoque e garantir atendimento, e ele se resolve com uma pergunta de prazo. Se a instabilidade que justifica o estoque tem plano de correção com data, o estoque desce junto com a correção, em degraus. Se não tem plano, mexer no estoque é só transferir o problema para o cliente, com aparência de eficiência.

A tabela de decisão para levar impressa

A tabela de visita técnica que está mais acima é a versão que eu preencho de caneta. Ela só funciona se estiver na mão na hora da visita, não no computador depois. Por isso ela sai em PDF de uma folha, com as cinco colunas preenchidas nas seis linhas. A sexta coluna fica em branco para você anotar a condição que existe na sua operação e não existe na que você está visitando.

A folha traz as seis linhas já escritas e só a última coluna vazia, para você preencher durante a visita, com data. Ela foi feita para ir na prancheta e voltar com marca de caneta em cima. Clique na miniatura para ver em tamanho grande sem sair desta página.

Baixe a tabela de decisão em PDF

Se além da tabela você quiser as ferramentas de apoio já montadas, elas estão no kit de ferramentas Lean Seis Sigma, em formato editável.

O que eu diria para mim mesmo antes daquela viagem

Leve duas perguntas escritas e volte com elas respondidas. O que vocês arrumaram antes disto aqui? E o que vocês tentaram e abandonaram? Elas valem mais que o dia inteiro de roteiro, e quase ninguém as faz porque parecem perguntas de quem não entendeu a apresentação.

Traga a regra de decisão que sustenta a ferramenta. É ela que faz o Sistema Toyota ser o que é, e é ela que sobrevive à mudança de país, de setor e de tamanho de empresa. A ferramenta você monta depois, em uma tarde, com o que você tem.

Se você quer construir isso com método em vez de por tentativa, é exatamente o que a gente ensina nas Academias de Certificação da Voitto, do White Belt ao Black Belt, com projeto real acontecendo durante o curso.