“Tentamos puxar, mas não funcionou”.

“Quantas vezes?”.

“Como assim ‘quantas vezes?’. Veja, não funciona para  nós”.

“Então, na primeira vez que você caiu de sua bicicleta, você desistiu?”.

Essa conversa aconteceu no início desta semana, mas poderia ter acontecido há 24 horas, quando estudei como os engenheiros da Toyota ensinaram os engenheiros de manufatura da Valeo a “tornar lean” uma célula de produção. O primeiro plano que os engenheiros da Toyota desenvolveram foi:

Pegue um contêiner a cada 15 minutos.

Crie um local na logística para criar caminhões “falsos” esperando pelo real.

Não brinque com kanbans.

Crie espaço para os operadores registrarem cada problema com tempo, causa, contramedida.

Corte pela metade o tamanho dos lotes.

Nada disso era possível naquela época. Nada disso é possível agora. Não é que as pessoas não queiram fazer. É que elas tentaram e não funcionou, então foram para a próxima.

Como Luke diz a Yoda: “Você quer o impossível”. Quando Yoda levita o X-Wing do pântano, Luke deixa escapar um “eu não… eu não acredito!”. E Yoda responde com sua famosa fala: “É por isso que você falha”.

O ponto aqui não é que acreditar em qualquer coisa fará com que ela aconteça, mas que tentar até que funcione fará com que você aprenda. Para sermos justos, a maioria das pessoas está acostumada a executar as ordens de seus chefes no trabalho. O chefe define a situação, decide que isso ou aquilo precisa ser feito e manda alguém fazer.

A pessoa pensa sobre isso, faz um plano de ação para fazer, segue mais ou menos os passos (considerando que alguns passos acontecerão de forma muito diferente do planejado) e… ou funciona ou não. Nesse momento, o chefe e o colaborador determinam se a ordem foi um sucesso ou um fracasso antes de eles essencialmente passarem para a próxima ordem. As coisas ou funcionam ou não. É isso que acontece.

Com o pensamento lean, isso acontece de forma diferente. Não contratamos pessoas para que façam um trabalho. Contratamos para que elas tenham sucesso no trabalho. Quando o gerente e o colaborador decidem que precisam fazer algo (por exemplo, montar um sistema puxado, sem o qual não há lean), eles decidem ter sucesso, o que significa tentar várias vezes até que consigamos.

Essa é uma forma muito diferente de solução de problemas. A maioria das pessoas sente que solucionou o problema quando o conteve com medidas administrativas: mais inspeções, mais procedimentos, mais audições, mais controles. Na verdade, elas não solucionaram nada – apenas carregaram o processo com mais papelada para inspecionar o trabalho ruim do produto ou serviço sem eliminar a causa do problema.

No pensamento lean, tentamos dar às pessoas uma forma clara e visual para que vejam sua própria melhoria quando tentam formas diferentes para realmente solucionar o problema. Por exemplo, na maioria das linhas de montagem, há buffers de peças entre as estações (normalmente bem posicionadas em uma esteira, mas ainda sim são buffers). Quando a linha não produz de forma suficiente, a ordem mais comum é aumentar a capacidade. A resposta lean é ir ao fluxo de uma só peça para entender quais são os problemas reais.

Na solução de problemas tradicional, isso significa registrar todas as variações no fluxo de trabalho e planejar gradualmente para reduzir o número de peças nos buffers. Na forma lean, isso significa forçar a linha a ter apenas uma peça entre as estações por algumas horas todos os dias. Ao fazer isso, damos às pessoas da linha o poder de visualizar o que o fluxo de uma só peça realmente significa e de entendê-lo sozinhas – e, então, pedir auxílio ao serviço técnico para solucionar os problemas reais. Até que você tenha sucesso no fluxo de uma só peça.

De forma semelhante, a maioria das máquinas está programada para parar se tiver muitos produtos defeituosos, mas parece impossível parar a máquina em cada defeito (a máquina não se importa, mas os engenheiros sentem que a produção cairia drasticamente). Em vez de planejar para cada máquina, começar com uma a três máquinas, programá-las para parar em cada defeito e fazer com que os técnicos de manutenção foquem na solução desses problemas. Quando você melhorar essas três máquinas, vá para as próximas três até que todas as máquinas trabalhem com capacidade total e parem em cada defeito.

Solucionar problemas com soluções de “processo” é muito diferente de desenvolver solucionadores de problemas. O objetivo do pensamento lean é que não queremos que os problemas simplesmente desapareçam. Queremos desenvolver a pessoa que tem o problema para que ela aprenda a lidar com ele de forma autônoma em todos os casos e suas variações para que o problema possa ser solucionado de forma rápida e, eventualmente – se você tiver sorte, e eles forem espertos – suas causas raízes possam se tornar visíveis e possamos melhorar a situação na fonte.

Mas isso requer uma atitute gerencial muito diferente. Na empresa que mencionei antes, o líder decidiu que seus fluxos de produtos até a distribuição poderia se beneficiar utilizando um cross-dock. Um cross-dock é por onde você passa toda vez que faz uma conexão local após um voo transatlântico: você está viajando metade do mundo em um grande jato com um monte de pessoas antes de – quando chegar na metade da viagem – se separar e pegar voos locais que permitam que você faça a menor conexão possível. De forma semelhante, os produtos acabados que precisam ser distribuídos para outlets seriam primeiro enviados por longas distâncias em um caminhão e, depois, passariam por um “centro de conexão” e subir a bordo de um transporte local para chegar à loja que se destina.

Na forma tradicional, o líder da empresa achou que isso seria uma grande melhoria e designou um de seus melhores e mais espertos para “fazer assim”. O gerente, então, contratou consultores para calcular a configuração perfeita de cross-dock e, então, disse aos operadores de logística (porque, nesse caso, o gerente de logística estava resistindo à ideia) o que fazer. Estamos olhando para a forma normal como os gerentes trabalham:

Calcule

Comande

Controle

Eles não tinham apertado o “botão de início”, mas, quando perguntados por quanto tempo os produtos ficariam no “cross-dock”, a resposta foi “de duas horas a dois dias”. Nada reconfortante

A forma lean não é a mesma. Primeiro, um gerente lean definiria o problema de forma clara com um indicador de sucesso – produtos passando por um cross-dock nunca deveriam ser estoque, mas ter o menor tempo de “conexão” possível. Então, ele começaria desenvolvendo um sistema de transporte (milk run, na linguagem lean) entre um centro de estoque e uma loja e, depois, um ciclo completo de milk run. Depois, pegaria um destino longo e veria como fazer com que alguns produtos fizessem conexão com o serviço de transporte para que eles nunca parassem: fluxo contínuo desde o caminhão de longas distâncias até o transporte de entrega à loja de curtas distâncias.

Assim que o milk run fosse aperfeiçoado e trabalhasse de forma adequada, ele tentaria com o próximo grupo de produtos até que o sistema todo trabalhasse como um cross-dock e, mais importante, até que as pessoas que administram o cross-dock tivessem aprendido a lidar com a longa lista de problemas típicos de cross-dock e tivessem ideias locais para administrar o processo de forma suave.

Estamos olhando para uma forma muito diferente de gerenciar:

Observe

Oriente

Aprenda fazendo

Liderar com o lean significa, primeiro, observar as pessoas e, se alguém em algum lugar tiver uma ideia melhor – como no caso do cross-dock –, ir ao gemba com as pessoas que farão o trabalho.

Depois, orientar dando critérios claros e físicos para o sucesso, como “conexão curta entre a viagem longa e o transporte local” – uma forma prática de enxergar quão bem estamos enquanto trabalhamos (enquanto escrevo isso, estou olhando para o contador de palavras e o corretor ortográfico por causa de minha gramática imperfeita. Também estou checando meu material de referência sobre logística lean e tentando garantir que eu não escreva besteiras).

E, por fim, aprender fazendo. Não escreva um plano extenso detalhando todas as possibilidades. Não pergunte aos consultores ou analise demais a situação. Tente. Falhe. Aprenda. Tente novamente. O sucesso e o fracasso não estão relacionados a se “funcionou” ou “não funcionou”, mas em termos de “por quantos ciclos de aprendizagem tivemos que passar até aprendermos a fazer funcionar”.

Calcule, comande, controle serve para situações rotineiras e estáveis que possam funcionar com um trabalho medíocre. Essa abordagem assume que 1) podemos prever como as coisas acontecerão, 2) as pessoas obedecerão cegamente as ordens e 3) o controle pode, de alguma forma, inspecionar a qualidade do trabalho. No ambiente turbulento, surpreendente e de mudanças rápidas de hoje com colaboradores despreocupados e alta variedade, calcule-comande-controle simplesmente não se encaixa mais: precisamos aprender a ser melhor do que isso.

Mas, novamente, sempre fazemos quando queremos ser bons em algo. Como Ginger canta para Fred em “Swing Time”: “Respire fundo, levante-se, limpe a poeira, comece de novo: trabalhe como uma alma inspirada, até que a batalha do dia seja vencida”.