Pular para o conteúdo
Você está aqui: Início / Blog / As 4 regras do DNA da Toyota: o que está por trás das ferramentas que todo mundo copia

As 4 regras do DNA da Toyota: o que está por trás das ferramentas que todo mundo copia

Nos anos 1990, centenas de empresas visitaram as fábricas da Toyota, voltaram com anotações detalhadas sobre kanban, andon e células, e implantaram tudo. A maioria não chegou perto dos resultados. O que intrigava os pesquisadores não era a falha, era a transparência: a Toyota deixava qualquer um entrar, fotografar e perguntar. Se o segredo estava à vista, por que ninguém conseguia reproduzi-lo?

Steven Spear e H. Kent Bowen passaram quatro anos estudando dezenas de plantas, dentro e fora da Toyota, atrás dessa resposta. O artigo que publicaram na Harvard Business Review em 1999 chegou a uma conclusão incômoda para quem copia ferramentas: as ferramentas eram a parte menos importante. O que fazia o sistema funcionar eram quatro regras implícitas, nunca escritas pela própria Toyota, que governavam como qualquer trabalho era desenhado, conectado, organizado e melhorado.

O paradoxo que as regras resolvem

Quem observava a Toyota via duas coisas que pareciam incompatíveis. De um lado, uma rigidez extrema: cada atividade especificada nos mínimos detalhes, sequência fixa, tempo fixo. De outro, uma flexibilidade enorme: as operações mudavam o tempo todo, e as pessoas eram estimuladas a mudar o próprio trabalho.

A explicação de Spear e Bowen é que a especificação rígida é justamente o que torna a mudança possível. Quando o trabalho é feito sempre do mesmo jeito, cada atividade funciona como um experimento: há uma expectativa clara do que deve acontecer, e qualquer desvio aparece imediatamente. O desvio vira informação, e a informação vira melhoria. Sem especificação, não há expectativa, e sem expectativa não há como perceber que algo deu errado.

Por isso os autores descrevem a Toyota como uma comunidade de cientistas: cada especificação é uma hipótese sobre como o trabalho deve funcionar, e cada execução é um teste dessa hipótese.

As quatro regras

Regra 1. Todo trabalho é especificado em conteúdo, sequência, tempo e resultado. Não basta dizer o que fazer; a especificação define a ordem dos passos, quanto tempo cada um leva e qual é o resultado esperado. Dois operadores fazendo a mesma tarefa de jeitos diferentes não é flexibilidade, é ausência de hipótese: quando um defeito aparece, não há como saber qual dos dois jeitos o produziu. É a base do que se chama trabalho padronizado.

Regra 2. Toda conexão entre cliente e fornecedor é direta, com um jeito inequívoco de pedir e responder. Quem precisa de algo sabe exatamente a quem pedir, como pedir e em quanto tempo deve receber. O cartão de kanban é uma conexão desse tipo, assim como o andon, que liga o operador ao líder que deve responder a um problema. Pedido feito por grito, por mensagem genérica ou por quem estiver passando não é conexão especificada, e a resposta vira questão de sorte.

Regra 3. O caminho de todo produto e serviço é simples e direto. Cada peça segue um trajeto definido, passando sempre pelas mesmas pessoas e máquinas. Se uma peça pode passar por qualquer uma de três máquinas disponíveis, o caminho não é especificado, e um problema numa delas se espalha sem ser rastreável. Caminho fixo é o que permite o fluxo contínuo e, mais importante, é o que permite saber onde um defeito nasceu.

Regra 4. Toda melhoria segue o método científico, com a orientação de um professor, no nível mais baixo possível da organização. Mudanças são feitas por quem faz o trabalho, com uma hipótese explícita, um resultado esperado e um teste. E alguém mais experiente acompanha, não para aprovar, mas para ensinar o raciocínio. É o ciclo PDSA descrito como regra de funcionamento da organização inteira, e não como técnica de projeto.

Como as regras aparecem no chão de fábrica (situação-tipo construída para este texto)

Uma linha de usinagem tinha três tornos equivalentes e peças que iam para qualquer um deles, conforme a disponibilidade. A proporção de peças com diâmetro fora da tolerância oscilava entre 1,5% e 3,8% por semana, e a investigação nunca chegava a lugar nenhum: quando um lote defeituoso aparecia, não se sabia de qual torno ele tinha saído.

A primeira mudança não foi técnica. Foi aplicar a regra 3: cada família de peça passou a ter um torno fixo. Em duas semanas, os dados mostraram que quase todos os defeitos vinham de um único torno, e em um único turno. A regra 1 fez o resto: especificado o procedimento de ajuste no início do turno, com sequência e tempo definidos, ficou visível que o operador daquele turno fazia o ajuste depois do aquecimento, e não antes, como os outros.

A correção levou um dia. Nas seis semanas seguintes, a proporção de peças fora da tolerância no torno em questão ficou entre 0,4% e 0,9%. O problema não era novo, e a solução não era difícil. O que faltava era um sistema capaz de mostrar onde o problema estava.

Por que copiar ferramentas não funciona

O argumento central de Spear e Bowen explica décadas de implantações frustradas. As ferramentas são produtos das regras, e não o contrário. O kanban é o que uma empresa inventa quando aplica a regra 2 ao abastecimento; o andon é o que ela inventa quando aplica a regra 2 à resposta a problemas. Copiar o cartão sem a regra produz um cartão sem a conexão que ele deveria materializar.

Isso também explica por que as listas de princípios do Sistema Toyota, por mais completas que sejam, não bastam para implantar. Elas descrevem o que a Toyota valoriza; as regras descrevem como o trabalho é desenhado para que esses valores funcionem no dia a dia.

E há uma consequência para quem conduz melhoria em qualquer empresa. A pergunta útil diante de um problema não é “que ferramenta aplicar?”. É “qual das quatro regras está sendo violada aqui?”. Trabalho sem especificação, conexão ambígua, caminho que varia ou melhoria feita sem hipótese: quase todo problema operacional recorrente cai em uma dessas quatro categorias.

O erro de ler especificação como burocracia

A regra 1 costuma ser a mais mal recebida quando apresentada a uma equipe, porque soa como procedimento escrito, formulário e controle. Não é esse o sentido. A especificação que interessa é curta, fica no posto, é escrita por quem faz o trabalho e muda sempre que alguém descobre um jeito melhor. O que ela não pode é ser vaga.

A diferença prática aparece no momento do problema. Com procedimento genérico de dez páginas guardado numa pasta, ninguém sabe dizer se o defeito veio de um desvio ou do próprio procedimento. Com especificação curta e precisa no posto, a pergunta tem resposta em minutos: o trabalho foi feito como especificado? Se sim, a especificação estava errada e precisa mudar. Se não, o desvio é o ponto de partida da investigação.

Onde as regras encontram o método

A regra 4 é a que liga todo o sistema ao método científico, e é a que menos se vê nas implantações. Melhoria conduzida por quem faz o trabalho, com hipótese e predição antes do teste, lida em dados no tempo depois dele. Sem isso, as três primeiras regras produzem um processo estável e rígido; com isso, produzem um processo que aprende.

É exatamente esse raciocínio, de tratar cada mudança como teste de uma hipótese e cada desvio como informação, que a formação Green Belt desenvolve. As ferramentas vêm junto; o que muda o resultado é a regra por trás delas.

As empresas que visitavam a Toyota nos anos 1990 não estavam vendo pouco. Estavam vendo tudo, menos a única coisa que não aparece em fotografia.


Conteúdo revisado pelo Master Black Belt Marcelo Petenate, estatístico, formado pela Unicamp, mestre pela USP e especialista em Lean Six Sigma e melhoria contínua. Nesta revisão, o foco foi a leitura das quatro regras como estrutura de experimentação contínua, e não como lista de boas práticas.


A regra que decide se as outras três geram melhoria é a quarta: cada mudança conduzida como teste de uma hipótese. O White Belt gratuito da EDTI começa por esse raciocínio, com dados no tempo e teste em pequena escala.

Perguntas frequentes

Quais são as 4 regras do DNA da Toyota?

Todo trabalho é especificado em conteúdo, sequência, tempo e resultado; toda conexão entre cliente e fornecedor é direta e inequívoca; o caminho de todo produto e serviço é simples e direto; e toda melhoria segue o método científico, com orientação de um professor, no nível mais baixo possível da organização.

Quem formulou as 4 regras?

Steven Spear e H. Kent Bowen, no artigo Decoding the DNA of the Toyota Production System, publicado na Harvard Business Review em 1999, depois de anos estudando plantas dentro e fora da Toyota. As regras não eram escritas pela empresa: eram implícitas no modo como o trabalho era organizado.

Qual a diferença entre as 4 regras e os 14 princípios da Toyota?

Os 14 princípios, organizados por Jeffrey Liker, descrevem os valores e a filosofia da gestão da Toyota. As 4 regras descrevem como o trabalho é desenhado no nível operacional para que esses valores se tornem prática diária. Uma lista diz o que importa; a outra, como fazer funcionar.

Por que a especificação rígida gera flexibilidade?

Porque transforma cada execução num teste. Quando o trabalho tem sequência, tempo e resultado esperados, qualquer desvio aparece imediatamente, e o desvio vira informação para melhorar. Sem especificação não há expectativa, e sem expectativa não se percebe o que deu errado.

As 4 regras se aplicam fora da indústria?

Sim. O próprio Spear aplicou esse raciocínio em hospitais, onde conexões ambíguas entre equipes e caminhos variáveis de pacientes são fontes frequentes de erro. As regras descrevem como organizar qualquer trabalho feito por pessoas em sequência, não apenas manufatura.

Por que copiar as ferramentas da Toyota não funciona?

Porque as ferramentas são consequência das regras. O kanban e o andon são formas de aplicar a regra das conexões diretas. Copiar a ferramenta sem a regra por trás produz o artefato sem o mecanismo que o fazia funcionar.

Como usar as 4 regras para diagnosticar um problema?

Perguntando qual regra está sendo violada: o trabalho não está especificado, a conexão entre quem pede e quem atende é ambígua, o caminho do produto varia, ou a melhoria está sendo feita sem hipótese e teste. A maior parte dos problemas operacionais recorrentes se encaixa em uma dessas quatro categorias.

5/5 - (1 voto)

Deixe um comentário

Inscreva-se em nossa newsletter

E receba por email novos conteúdos assim que forem publicados!

Desenvolvido por: