CARACTERÍSTICA – Quando o lean parece falhar, os líderes devem persistir e trabalhar ainda mais para trazer as pessoas para a jornada – observando a situação, fornecendo critérios de sucesso claros e aprendendo juntos no trabalho.

Palavras: Michael Ballé, autor, coach executivo e cofundador do Institut Lean France

“Tentamos puxar, mas não deu certo.”

“Quantas vezes?”

“O que você quer dizer com ‘quantas vezes’? Olha, simplesmente não funciona no nosso caso.

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

Essa conversa aconteceu no início desta semana, mas poderia muito bem ter ocorrido 24 anos atrás, quando estudei pela primeira vez como os engenheiros da Toyota ensinaram os engenheiros de produção da Valeo a “aprender” uma célula de produção. O primeiro plano que os engenheiros da Toyota apresentaram foi:

1. Pegue um recipiente a cada 15 minutos;
2. Criar um local na logística para criar caminhões “falsos” esperando pelo real;
3. Não mexa com kanbans;
4. Crie espaço para que os operadores registrem todos os problemas com tempo, causa, contramedida;
5. Reduza o tamanho do lote pela metade.

Nada disso era possível então. Nada disso é possível agora. Não é que as pessoas não façam isso. É que eles tentaram e não funcionou, então eles passaram para a próxima coisa.

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

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

A pessoa pensa, traça um plano de ação para fazer, segue mais ou menos os passos (considerando que o atrito normal faz com que alguns passos aconteçam bem diferente do planejado), e aí… ou dá certo ou não, ou então e assim. Nesse ponto, chefe e funcionário determinam se o comando foi um sucesso ou um fracasso, antes de passarem para o próximo comando. As coisas funcionam ou não, é assim que as coisas são.

Com o pensamento enxuto, isso funciona de maneira diferente. Não contratamos pessoas para fazer um trabalho, contratamos para ter sucesso em um trabalho. Quando o gerente e o trabalhador decidem que precisam fazer algo (como estabelecer um sistema puxado, sem o qual não há lean), eles decidem ter sucesso, o que significa tentar de novo e de novo até pegarmos o jeito .

Esta é uma forma muito diferente de resolução de problemas. A maioria das pessoas sente que resolveu o problema quando o conteve com uma medida administrativa: mais inspeções, mais procedimentos, mais auditorias, mais controles. Na realidade, eles não resolveram nada – apenas sobrecarregaram o processo com mais papelada para inspecionar o mau funcionamento do produto ou serviço, sem abordar a causa do problema.

No pensamento enxuto, tentamos dar às pessoas uma maneira clara e visual de se verem melhorando à medida que tentam diferentes maneiras de realmente resolver o problema. Por exemplo, na maioria das linhas de montagem, existem buffers de peças entre as estações (geralmente bem colocados em um transportador, mas ainda buffers). Quando a linha não fornece produção suficiente, a demanda usual é adicionar capacidade. A resposta enxuta é primeiro ir para o fluxo de peça única 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 a redução do número de peças nos buffers e assim por diante. Na maneira enxuta, isso significa forçar a linha a funcionar com apenas uma parte entre as estações por algumas horas todos os dias. Ao fazer isso, damos às pessoas na linha o poder de visualizar o que realmente significa o fluxo de peça única e descobrir por si mesmas – e então solicitar suporte para serviços técnicos em problemas reais. Até que você tenha sucesso no fluxo de uma peça.

Da mesma forma, a maioria das máquinas agora está programada para parar se apresentar muitos defeitos, mas parece impossível parar a máquina em todos os defeitos (a máquina não se importa, mas os engenheiros acham que a produção cairia terrivelmente). Em vez de planejar cada máquina na parte da máquina, comece com uma a três máquinas, programe-as para parar em cada defeito e tenha todos os técnicos de manutenção focados em corrigir esses problemas. Depois de melhorar essas três máquinas, passe para as próximas três, até que todas funcionem com capacidade total e parem a cada defeito.

Resolver problemas com soluções de “processo” é muito diferente de desenvolver solucionadores de problemas. O ponto do pensamento enxuto é que não queremos simplesmente que o problema desapareça. Queremos desenvolver a pessoa que tem o problema para aprender a lidar com ele de forma autônoma em todos os seus casos variados, para que o problema possa ser tratado rapidamente e, eventualmente – se tivermos sorte e eles forem espertos – sua causa raiz se torne aparente e podemos melhorar a situação na fonte.

Mas isso requer uma atitude gerencial muito diferente . Na empresa mencionada anteriormente, o líder decidiu que seus fluxos de produtos para distribuição poderiam se beneficiar do uso de cross-dock. Um cross-dock é o que você passa toda vez que faz uma conexão local após um voo transatlântico: você está dando a volta ao mundo em um grande jato jumbo com um monte de gente, antes de – ao chegar ao hub – todos partirem suba e pegue vôos locais, permitindo que você faça a conexão mais curta possível. Da mesma forma, os produtos acabados que precisam ser distribuídos aos pontos de venda seriam primeiro enviados de longa distância em um caminhão, depois passariam por um “centro de conexão” e embarcariam em um ônibus local para chegar à loja a que se destinam.

Da maneira tradicional, o líder da empresa imaginou que isso seria uma grande melhoria e encarregou um de seus melhores e mais brilhantes de “torná-lo assim”. O gerente então contratou consultores para calcular a configuração perfeita de cross-dock e depois dizer aos operadores logísticos (porque neste caso o gerente de logística resiste à ideia) o que fazer. Estamos analisando a maneira usual como os gerentes gerenciam:

Eles não apertaram o botão “ir” perguntado, mas quando questionados sobre quanto tempo os produtos permaneceriam no estoque “cross-dock”, a resposta foi “de duas horas a dois dias”. Não é reconfortante.

A maneira enxuta não é exatamente a mesma. Primeiro, um gerente enxuto enquadraria o problema claramente com um indicador de sucesso – os produtos que passam pelo cross-dock nunca devem ser estoques, mas ter o menor tempo de “conexão” possível. Em seguida, ela começaria configurando um sistema de transporte ( milk run na linguagem enxuta) entre um centro de estoque e uma loja, depois um segundo e, por fim, um loop completo de milk run). Em seguida, pegue um destino de longa distância e veja como fazer com que alguns produtos se conectem ao serviço de transporte para que nunca parem de se mover: fluxo contínuo do caminhão de longo curso para o ônibus de entrega de curta distância até a loja.

Assim que o milk run estiver perfeito e funcionando corretamente, ela o experimentará no próximo pacote de produtos, até que todo o sistema funcione como um cross-dock e, mais importante, até que as pessoas que executam o cross-dock aprendam a lidar com uma longa lista de problemas típicos de cross-docking e apresentar ideias locais para executar o processo sem problemas.

Estamos olhando para uma maneira muito diferente de gerenciar:

Liderar com lean é primeiro observar com as próprias pessoas, e se alguém, em algum lugar, tiver uma ideia melhor – como no caso do cross-dock – ir para aquele gemba com as pessoas que se espera que façam funcionar.

Em seguida, oriente fornecendo critérios claros, materiais e práticos para o sucesso, como “conexão curta entre longa distância e transporte local” – uma maneira prática de ver como estamos indo enquanto trabalhamos. (Enquanto escrevo isso, estou olhando para minha contagem de palavras e a verificação ortográfica questiona minha gramática duvidosa. Também estou verificando meu material de referência sobre logística enxuta para tentar ter certeza de que não escrevo muitas bobagens.)

E, finalmente, aprender fazendo. Não escreva um plano extenso detalhando todas as contingências. Não peça aos consultores que analisem demais a situação. Tente. Falhar. Aprender. Tente de novo. Sucesso ou fracasso não é contado em termos de “funcionou” ou “não funcionou”, mas em termos de “quantos ciclos de aprendizado tivemos que passar até aprendermos a fazer funcionar”.

Calcular, comandar, controlar é bom o suficiente para situações rotineiras e estáveis ​​que podem funcionar com trabalho medíocre. Pressupõe que 1) podemos prever como as coisas vão acontecer, 2) as pessoas colocarão seus corações e mentes para obedecer ao comando e 3) que o controle pode, de alguma forma, inspecionar a qualidade do trabalho. No ambiente turbulento, surpreendente e veloz de hoje, com trabalhadores desengajados e grande variedade, cálculo-comando-controle simplesmente não se encaixa mais no período: temos que aprender a fazer melhor do que isso.

Mas, novamente, sempre fazemos quando queremos ser bons em alguma coisa, e não apenas sobreviver. Como Ginger canta para Fred em Swing Time : “Respire fundo, levante-se, tire a poeira, comece tudo de novo: trabalhe como uma alma inspirada, até que a batalha do dia seja vencida.”

Compre sua cópia do Lead with Lean hoje mesmo clicando aqui

O ENTREVISTADO

Michael Ballé é cofundador do Institut Lean France. Pesquisador associado da Telecom ParisTech, é doutor pela Sorbonne em Ciências Sociais e Ciências do Conhecimento. Michael é autor de best-sellers, palestrante envolvente e sócio-gerente da ESG Consultants. Ele também trabalha como coach executivo lean em vários campos, de manufatura a engenharia, de serviços a saúde.