Yokoten.

O que é Yokoten

Yokoten é a expansão horizontal de uma prática comprovada. Quando uma linha, um turno ou uma planta desenvolve algo que funciona de verdade, um setup mais rápido, uma rotina de escalonamento mais limpa, um dispositivo que impede um defeito, o Yokoten é a disciplina de levar esse aprendizado de lado, para todo lugar que tem o mesmo problema. São duas correntes: as melhorias, em que um jeito melhor se espalha, e as contramedidas, em que uma causa comprovada em uma linha faz todas as linhas irmãs se olharem no espelho.

O Yokoten falha nos dois sentidos. Copiar e colar impõe a solução da origem em todo lugar, ignora as condições locais e gera aquela rejeição silenciosa que toda fábrica conhece: o padrão novo fica exposto, assinado e contornado. Reinventar em cada unidade é a falha oposta: cada uma resolve o mesmo problema do zero, pagando o preço cheio, e a empresa compra cinco vezes o mesmo aprendizado. A regra de trabalho que evita as duas: adote o padrão, adapte o método, mantenha o resultado. Quem recebe precisa entender por que a prática funciona antes de decidir como rodá-la localmente, e o resultado assumido não se negocia.

O que carrega o Yokoten é o trabalho padronizado. Uma prática que existe só na cabeça de alguém, ou só em uma apresentação, não viaja. Uma prática registrada como padrão vivo, com suas condições e seu resultado medido, dá para ver, ensinar, testar e verificar em outro lugar.

Quando não replicar

O erro mais comum de Yokoten acontece antes de qualquer transferência começar: replicar uma prática que ainda não é estável na origem. Uma prática precisa sobreviver ao contato com a vida normal, faltas, troca de modelo, uma semana ruim, antes de valer a pena exportar. Uma unidade rodando bem uma prática por 90 dias vale mais que uma implantação corporativa de um protótipo, porque esses 90 dias produzem as duas coisas de que quem recebe mais precisa: a prova de que o resultado se sustenta e o conhecimento das condições de que ele depende. Implantar um protótipo espalha os defeitos junto com a novidade, cada unidade receptora resolve os mesmos defeitos separada, pagando o preço cheio, e a confiança na ideia toda vai escorrendo. Não replique quando:

• A prática tem menos de uns 90 dias na origem. Ela ainda pode estar se sustentando na atenção de quem a criou, e não no próprio padrão.
• A origem não sabe dizer de que condições o resultado depende. Sem as condições, quem recebe não tem como julgar o que se aplica e o que não.
• O resultado foi declarado, não medido. Uma prática sem dados de antes e depois espalha uma história, não um método.
• Nenhuma unidade receptora tem de fato o problema. Replicar em nome do alinhamento produz material de prateleira e ressentimento na mesma medida.

Yokoten de contramedidas

A segunda corrente do Yokoten anda mais rápido e é mais fácil de justificar: espalhar causas comprovadas, não só melhorias. Quando uma linha comprova uma causa raiz, uma conexão com torque abaixo do especificado por causa de uma verificação que faltava no padrão, por exemplo, cada linha irmã e cada família de produto parecida se olha contra essa causa em dias, e não no próximo ciclo de auditoria. A pergunta que cada linha responde é curta: isso pode acontecer aqui, e qual é a evidência? Opinião não conta; alguém vai olhar o processo, o padrão e os dados. No Brasil essa é a velha análise de abrangência das não conformidades, feita como rotina e não como campo de formulário.

Os métodos formais de solução de problemas já trazem isso dentro. A disciplina D7 de um relatório 8D, a prevenção, é uma instrução de Yokoten: atualize o FMEA e o plano de controle, depois procure o mesmo modo de falha em peças, linhas e plantas parecidas. O MASP fecha do mesmo jeito, com a padronização. Um defeito encontrado em um produto e verificado na família toda na mesma semana é o Yokoten no seu ponto mais barato, porque o custo do aprendizado já foi pago pela linha que o encontrou. Para causas que merecem observação mais longa, a verificação pode entrar no roteiro de perguntas das auditorias escalonadas de processo por um trimestre, para que mais de um par de olhos confirme a abrangência.

A velocidade separa as duas correntes. Uma transferência de prática merece o checklist completo de seis passos e leva semanas. O Yokoten de contramedidas se mede em dias e precisa de três passos: a causa comprovada viaja com a evidência, cada linha irmã responde à pergunta no processo, e as respostas ficam registradas onde o problema original consiga enxergá-las.

Transformando em sistema

Uma transferência é um projeto. Um sistema de Yokoten precisa de três peças permanentes. A primeira é uma biblioteca de práticas compartilhada que justifique a própria existência: cada registro traz o padrão, o resultado medido, as condições de que ele depende e um contato definido que recebe visitas. Registro sem uma das quatro coisas é peso morto, e uma biblioteca de peso morto é a razão de quase todo portal de boas práticas ficar fechado. Cinquenta registros dentro do critério valem mais que quinhentos fora dele.

A segunda peça é a alimentação. O funil de Kaizen já termina em um passo de padronizar e compartilhar; é ali que os candidatos à biblioteca são indicados, junto com os problemas encerrados cuja contramedida mudou um padrão. Ninguém deveria ter de lembrar de alimentar a biblioteca. Os sistemas de melhoria e de solução de problemas fazem isso ao fechar os próprios ciclos.

A terceira peça é o ritmo. As reuniões trimestrais de troca juntam as unidades para mostrar transferências verificadas e escolher as próximas, com as visitas marcadas antes de a reunião acabar. E a análise crítica pela direção mensal faz uma pergunta fixa: quais das nossas melhorias comprovadas já foram adotadas por uma segunda unidade, e o que está travando o resto? A pergunta custa dois minutos e mantém o sistema honesto, porque um trimestre sem transferências é uma constatação, não uma coincidência.

O que vem depois

O Yokoten fica no fim do roadmap porque multiplica o que as etapas anteriores construíram. Uma planta que padroniza, melhora e verifica consegue replicar; uma rede de plantas que replica aprende num ritmo que nenhuma unidade sozinha alcança. O pré-requisito silencioso é a comparabilidade: só dá para enxergar a replicação quando as unidades medem as mesmas coisas do mesmo jeito, e por isso um conjunto comum de definições de indicadores importa mais para o Yokoten do que qualquer portal. Se duas plantas definem tempo de setup de formas diferentes, ninguém consegue dizer se a transferência funcionou.

O outro pré-requisito é que os padrões morem em um lugar onde dá para adotá-los, e não só encaminhá-los. É aqui que o TeamGuru entra na corrente: com a gestão de documentos, as práticas ficam versionadas e visíveis entre unidades, então adotar um padrão significa adotar um documento vivo e vigente, com suas condições e seu histórico, em vez de receber um PDF que já estava vencido no dia em que foi anexado. A unidade receptora escreve seu padrão local ao lado do padrão da origem, e os dois continuam fáceis de achar quando a terceira unidade vier perguntar.

Na etapa Escalar do roadmap, o Yokoten anda junto com o trabalho de matriz de versatilidade, que constrói capacitação de propósito: as transferências correm mais quando a unidade receptora já tem gente treinada nos padrões de base, e cada transferência concluída cria a próxima geração de coaches.

Perguntas frequentes