Melhoria Contínua Rumo à Perfeição

Naturalmente, um grupo que está adotando LeSS traz para a mesa as seus premissas e hábitos sobre a adoção, melhoria e mudança. Que são? Criar uma visão de mudança e iniciar alguns projetos de mudança. Quando o objetivo original (por exemplo, “adotar LeSS”) é aparentemente atingido, então:

1. “a mudança foi realizada”, e
2. a organização se instala em um novo status quo, até
3. um novo esforço de mudança surgir, e então
4. a mudança anterior é desfeita.
   
   
   
   

Esta abordagem clássica é como a abordagem sequencial e de “grandes lotes” de desenvolvimento de software onde a mudança é uma exceção estritamente controlada … por muitos processos de controle de mudanças.

No LeSS, não há nenhuma iniciativa de mudança, nenhum grupo de mudança e nem gestores de mudança. No LeSS, a mudança é contínua através da experimentação e melhoria, e a mudança é o status quo. Quando você pode considerar que adotou LeSS com sucesso? Nunca. Quando você terminar de melhorar? Nunca.

O que significa perfeição? Não há uma resposta exatamente correta mas, por exemplo:

• As funcionalidades são perfeitas, e encantam profundamente os clientes; o seu produto é impressionantemente popular e rentável
• Você pode criar essas funcionalidades facilmente livres de defeitos com quase nenhum esforço ou custo
• A sua organização tem agilidade; ela pode facilmente mudar de direção com quase nenhum atrito ou custo — pode trocar seis por meia dúzia
• Seus funcionários têm extraordinário e profundo domínio das habilidades e conhecimentos, e realmente apreciam o trabalho
  
  
  
  

Isso deve mantê-lo melhorando por um tempo ;)

Melhora contínua rumo à perfeição é um dos dois pilares do Pensamento Enxuto, também um princípio do LeSS. Uma vez que o pensamento enxuto —e a melhoria contínua— vem originalmente da Toyota, alguns dos itens desta introdução se aplicam no background da Toyota.

Este princípio da melhoria contínua está baseado em diversas práticas e ideias:

• Saia e Veja
• kaizen
• valor e desperdício
• desafio pela perfeição
• trabalho orientado a fluxo
• respeito pelas pessoas

Saia e Veja

Vá à fonte [real local de trabalho de valor—gemba] para encontrar os fatos para tomar decisões corretas, construir um consenso, e atingir metas na nosso melhor velocidade. [Toyota01]

Conhecemos gestores em organizações LeSS que abandonaram seus escritório fechados e separados das equipes e sentaram-se diretamente com os desenvolvedores, e ficaram muito surpresos ao verem e aprenderem o que realmente está acontecendo, apesar trabalharem com os seus grupos durante anos.

Saia e Veja é um princípio e uma prática não encontrada em muitas culturas de gestão. Mas no comunicado interno Toyota Way 2001 é destacado como o principal fator de sucesso na melhoria contínua. (Em Japonês, este termo da Toyota é genchi genbutsu). “Saia e Veja” é mencionado repetidamente nas citações gerenciais, na cultura e nos hábitos da Toyota [LH08], e na educação interna da Toyota e no Toyota Way (pensamento enxuto).

O que significa na prática “Saia e Veja”? Que as pessoas, especialmente os gestores — incluindo gerentes seniores— não gastem todo o seu tempo em escritórios e salas de reuniões, e não recebam todas as suas informações através de reuniões, relatórios, e-mail e ferramentas de relatórios. Em vez disso, para saber o que realmente está acontecendo e ajudar a melhorar (através da eliminação da distorção gerada pela informação indireta), os gerentes frequentemente vão para o local de trabalho real, ficam lá e ver e compreendem por si próprios. Em uma entrevista, o engenheiro-chefe da Toyota Taiichi Ohno, que insistiu que em gestores praticassem o “Saia e Veja” gemba:

Não olhe com seus olhos, olhe com os pés … pessoas que só olham para os números são as piores de todas. [Hayashi08]

“Saia e Veja” gemba. O que é e onde está gemba? Gemba não significa um lugar de apoio ou trabalho secundário, mas o trabalho de agregação de valor que cria ou entrega o produto ou serviço que cliente pagante está esperando. Por exemplo, o lugar onde as pessoas estão escrevendo código, respondendo perguntas de clientes, etc. Gemba não está em uma sala de reunião ou em um escritório perto dos funcionários!

Um exemplo de “Saia e Veja” para os gestores: sentar-se por tempo significativo com os desenvolvedores de software, enquanto eles estão fazendo o trabalho de criação de código, com o objetivo de compreender os problemas e oportunidades para melhorar, ajudar e construir uma relação de confiança.

Note-se que “Saia e Veja” não é o mesmo que “gerenciar caminhando por aí.” “Caminhar por aí” apenas fornece uma compreensão superficial. “Saia e Veja” leva tempo.

Kaizen

Kaizen às vezes é traduzido simplesmente como “melhoria contínua”, mas acaba sendo confundido com o pilar de “melhoria contínua” do Lean e não captura a essência do termo. Então, vamos ficar com o termo em japonês.

Kaizen é tanto um mindset pessoal quanto uma prática. Como mindset, sugere “Meu trabalho é fazer o meu trabalho e melhorar o meu trabalho”. Formalmente como uma prática, Kaizen implica:

1. escolher e praticar técnicas/processos “by the book” onde a equipe e/ou o grupo produto concordou em tentar, até que eles sejam bem compreendidos e dominados
2. experimentar até encontrar uma maneira melhor, em seguida, torná-la o nova técnica/processo temporário padrão
3. repita sempre
   
   
   
   
   ** Etapa 1 — Escolher e praticar técnicas que a equipe e/ou o grupo de produtos concordaram em tentar usar, até que sejam bem compreendidas (excelência no trabalho padronizado.) ** A ideia é que um grupo encontre primeiro (preferencialmente) práticas de referência e aprenda a usá-las bem. Uma equipe de novatos segue as orientações do Scrum com um bom treinamento. Os acordos de trabalho do grupo, como padrões de codificação e “definição de pronto” são seguidos. As pessoas aprendem a fazer desenvolvimento orientado a testes com muita prática, treinamento e boa educação. E etapa 1 no kaizen implica ter paciência através da fase de aprendizagem e não abandonar novas técnicas rapidamente. As pessoas precisam de uma base para buscar a melhoria em cima desta base. E, de acordo com a terminologia de Deming, eles precisam ser capazes de distinguir entre variações de causa comum e variações de causa especial.

Este etapa 1 do kaizen significa que uma pessoa ou equipe não podem ver com precisão se eles precisam melhorar ou mudar uma prática, a menos que tenham primeiro dominado o básico, compreendendo os pontos sutis, e utilizando bem. Você já deve ter ouvido comentários como: “Oh, não funciona" que foram baseados em habilidade, prática ou educação insuficientes? Não vale a pena "melhorar" ou rejeitar com base em mal-entendidos.

No pensamento enxuto, trabalho padronizado não significa conformidade com padrões centralizados—Uma má interpretação grosseira do pensamento enxuto é a noção de que “trabalho padronizado” significa conformidade com padrões definidos de forma centralizada. Este é um erro tão profundo sob a perspectiva enxuta, ainda facilmente incompreendida, que este ponto merece uma ênfase especial. Em vez disso, a ideia é que uma equipe possa dominar uma base contra a qual os experimentos de melhoria possam ser comparados. Esta base -o padrão- é criada pela própria equipe (não por um grupo centralizador) e está em constante evolução. Como Ohno disse:

Eu disse a todos que eles não ganhariam seu salário se eles deixassem o trabalho padronizado inalterado por um mês inteiro. A ideia era deixar as pessoas saberem que eram responsáveis ​​por fazer melhorias contínuas nos procedimentos de trabalho e para incorporar essas melhorias no trabalho padronizado. [SF09]

Compartilhe em vez de aplicar as práticas — Os acordos de trabalho ou normas não devem ser mal interpretados para trabalhar com uma prática rígida estilo “até ser notificado de outra forma” ou um “padrão” top-down centralizado que é imposto sobre as pessoas-ideias contrárias ao pilar enxuto da melhoria contínua. O pessoal da Toyota promove o conhecimento compartilhado (yokoten) de forma lateral que pode evoluir excepcionalmente em diferentes localizações, como galhos de uma árvore. Yokoten significa literalmente se desdobrar ou abrir para o lado.
Difundir conhecimento implica em uma cultura que enfatiza a o conhecimento compartilhado de forma horizontal, mas não ser forçada a se adaptar a processos centralizados e empurrados de cima para baixo. Algumas citações do pessoal da Toyota:

Se tentarmos simplesmente levar todos para o padrão atual, você está perdendo oportunidades para melhorar. Você não está levando em conta que os tempos estão mudando. Tem de haver muita flexibilidade para permitir a criatividade ao longo do caminho… Os padrões não são desenvolvidos e então comunicados a partir da sede para todas as unidades. Padrões rígidos só irão matar o kaizen … É yokoten cada vez que as melhores práticas são compartilhadas… Devemos deixar que os indivíduos das unidades decidam o que farão para corrigirem seus problemas e fecharem lacunas. Não podemos ter alguém da corporação dizendo que você precisa fazer X, Y, Z, porque isso é completamente contrário à resolução de problemas da Toyota.
[LH08]

A propósito, as comunidades de prática -um elemento importante em uma organização LeSS- são usadas ​​para espalhar conhecimento de forma lateral.

** Etapas 2 e 3 - Mudanças pequenas, incrementais e implacáveis de qualquer coisa.** Kaizen é uma atividade contínua de todas as pessoas (incluindo gerentes) para mudar implacavelmente e incrementalmente e melhorar as práticas, geralmente através de pequenas experiências, embora kaizen em uma grande escala do sistema também pode ser uma opção. Quase nenhuma prática, processo ou política existente é sagrada - qualquer coisa pode mudar. “Desafie tudo”, nas palavras do presidente da Toyota, Convis. Além disso, uma cultura kaizen não se aplica apenas grandes projetos de melhoria conduzidas por peritos do processo. Em vez disso, cada equipe faz kaizen regularmente.

** Aprender melhoria de processo fazendo ** - Kaizen implica, através de repetição incessante e mentoria, que as pessoas aprendam por si mesmas como tornar os problemas visíveis, analisar suas causas e melhorar experimentando. E o “fracasso” dos experimentos é aceito. A única falha no kaizen é não experimentar continuamente.

Kaneyoshi Kusunoki, outro estudante de Taiichi Ohno, e vice-presidente executivo da Toyota, disse sobre kaizen e suporte de gestão:

Uma característica definidora da cultura corporativa da Toyota é que os gerentes não te repreendem por tomarem iniciativa, por terem uma chance e a estragarem. Pelo contrário, eles vão repreendê-lo por não tentar algo novo, por não ter uma chance. Os líderes não estão lá para julgar. Eles estão lá para encorajar as pessoas. Isso é o que eu sempre tentei fazer. Tentativa e erro é tudo!

No livro seminal [Kaizen] escrito por Masaaki Imai, ele menciona:

A essência do Kaizen é simples e direta: Kaizen significa melhoria. Além disso, Kaizen significa melhoria contínua envolvendo todos, incluindo gerentes e trabalhadores. A filosofia kaizen assume que o nosso modo de vida - seja a nossa vida profissional, social ou doméstica - merece ser constantemente aperfeiçoado

Kaizen reflete o ciclo de melhoria de Shewhart (também conhecido como ciclo de Deming) Plan-Do-Check-Act (PDCA). De fato, muitas pessoas dentro da Toyota conhecem formalmente o PDCA e às vezes descrevem o que estão fazendo como um “PDCA sem fim”.

Valor e Desperdício

O que melhorar durante o kaizen? No pensamento enxuto a resposta requer uma compreensão sobre valor e desperdício.

Valor—Os momentos de ação ou pensamento que criam o produto que o cliente está disposto a pagar. Em outras palavras, o valor é definido aos olhos do cliente externo. Imagine um cliente que observa o trabalho em seu escritório. Em quais momentos ele estaria disposto a colocar a mão no bolso, retirar dinheiro, e dar a você?

Desperdício—Todos os outros momentos ou ações que não agregam valor, mas consomem recursos. Os desperdícios vêm de trabalhadores sobrecarregados, gargalos, espera, entrega, pensamento ilusório e dispersão de informações, entre muitos outros.

Melhoria através da eliminação de desperdício–Depois de ter definido valor e desperdício, chegamos a uma notável diferença na melhoria enxuta. Outros sistemas se concentram em refinar ações de valor existentes; Por exemplo, melhorar a habilidade no design de software. Um objetivo digno, sem dúvida.

No entanto, uma vez que normalmente existem poucos momentos de valor acrescentados na linha do tempo - talvez 5% -, então melhorá-los não irá resolver muito. Mas com uma montanha de tempo de desperdício no processo, há grandes oportunidades para melhorar a relação de valor, eliminando o desperdício.

Por exemplo, um desperdício comum no desenvolvimento é o desperdício de trabalho em progresso (WIP), como trabalhos parcialmente feitos ou artefatos de trabalho intermediários (requisitos e documentos de projeto, etc.). Não há nenhum retorno sobre o investimento de WIP, e defeitos podem estar ocultos. E — ponto-chave — organizações tradicionais possuem uma MONTANHA de WIP. Portanto, faz pouco sentido se concentrar em medir e melhorar (por exemplo) a eficiência do programador em 2% se houver uma montanha de WIP em seu processo.

Outro exemplo de desperdício: tempo de espera ou atraso - os clientes não pagam por isso. Você já viu o desperdício de espera …

• com requisitos ou designs ou esclarecimentos?
• por aprovação?
• aguardando outra equipe de desenvolvimento terminar sua parte?

Categorias de Desperdícios com Exemplos e Comentários

Dentro da Toyota as pessoas são educadas para desenvolverem “olhares sobre o desperdício.” Para ajudar no aprendizado, listas de valor não acrescentado (NVA) e ações de desperdício foram criadas. Não existe uma lista correta — o ponto não são as categorias, mas aprender a ver e banir o desperdício na perspectiva do cliente. As seguintes categorias de ação do NVA de desenvolvimento de produtos foram extraídas de The Toyota Way, Implementing Lean Software Development, e Lean Product and Process Development.

1. Sobreprodução de funcionalidades, ou de elementos antes do próximo passo; duplicidade
   • Funcionalidades que o cliente não quer
   • Funcionalidades criadas e implementáveis, mas não implementadas
   • Duplicidade de dados ou código
     
     
2. Espera, atraso—Para esclarecimento, documentos, aprovação, componentes, outros grupos para terminar algo
   
   
3. Transferência, transporte, movimentação—passando uma especificação de um analista para um desenvolvedor e passando código de um desenvolvedor para um testador
   
   
4. Processamento extra (inclui processos extras), reaprendizagem, reinvenção, duplicidade—conformidade forçada a listas de verificação centralizadas de tarefas de “qualidade”, recriar um componente que outro desenvolvedor fez
   
   
5. Trabalho parcialmente realizado, trabalho em andamento (WIP)
   • Requisitos ou documentos de projeto
   • Código escrito não testado ou integrado
     
     
6. Mudança de tarefas, movimento entre tarefas; Multitarefa baseada em interrupção
   • Interrupção para lidar com defeitos graves
   • Multitarefa em 3 projetos
   • Alocação parcial de uma pessoa para muitos projetos
     
     
7. Defeitos, testes/revisão/inspeção e correção após criação de algo
   • Testes e correções para localizar e remover defeitos do código, após a criação do código
   • Revisão de código após a criação do código
   • Revisões/inspeções de documentos após a criação do documento
     
     
8. Subutilização do potencial das pessoas e habilidades variadas, insight, idéias, sugestões—as pessoas estão apenas trabalhando em uma especialidade única? As pessoas possuem a chance de mudar o que elas enxergam como um desperdício?
   
   
9. Perda de conhecimento e informação
   • Com informações em documentos separados
   • A partir de informações transmitidas entre grupos ou pessoas com uma única função
   • De aprendizado que não foi compartilhado ou difundido
   • Com barreiras de comunicação, como paredes entre pessoas ou pessoas em vários locais
     
     
10. Pensamento ilusório (por exemplo, que planos, estimativas e especificações estão “corretos”)—“A estimativa não pode aumentar; A estimativa do esforço é o que queremos que seja, não o que está sendo proposto.” “ Estamos atrasados, mas vamos compensar mais tarde. “
    
    
11. Culpar

Melhoria através da eliminação de desperdício—O foco na entrega de valor através da eliminação de desperdícios orienta uma organização enxuta para seguir o bastão em vez de seguir os corredores. Observe que a estratégia de melhoria é subtrativa em vez de aditiva. Em vez de (por exemplo), “O que podemos adicionar para que os trabalhadores aumentem a produtividade?”, a questão é: “O que podemos remover ou parar de fazer?” Em nossa consultoria acreditamos que essa é uma mudança de mentalidade tradicional de pessoas de garantia de qualidade em grandes organizações que se concentram em manter conformidade com listas de verificação e acionar * atividades para “melhoria”.

Deperdício necessário temporariamente versus desperdício puro—No pensamento enxuto dois tipos de desperdício são reconhecidos:

• Desperdício puro—Estas são ações que não agregam valor e que, em princípio, podem e devem ser eliminadas agora; Não há lei da terra ou física, ou restrição forte, que impeça a sua eliminação. Por exemplo, se um grupo está gerando desperdício de defeitos com testes ao final e correções ao final, eles podem substituir isso por desenvolvimento orientado a testes de aceitação; O processo de testes ao final e correções ao final é desperdício puro.

• Desperdício necessário temporariamente–São coisas que devem ser realizadas por causa de alguma restrição, mas ainda assim classificamos como desperdícios. Por exemplo, os bancos devem realizar atividades de “conformidade regulatória” (principalmente, em resposta a falhas anteriores dos bancos). Essas atividades são exigidas por lei, mas não são ações de valor agregado aos olhos do cliente pagador. Estes são chamados de desperdícios temporários porque futuramente pode ser possível mudar as coisas para que eles não sejam mais necessários. As leis reguladoras podem mudar para os bancos.
  
  
  

WIP ou inventário é sempre um desperdício puro?—Uma visão comum entre aqueles que estão iniciando no pensamento enxuto é que inventário ou WIP é sempre puro desperdício e deve sempre ser eliminado. Inventários de coisas físicas ou de WIP intangível - como especificações de requisitos - implicam investimento sem lucro e defeitos ocultos. Isso não é bom. No entanto, uma prática comum na melhoria enxuta é criar um sistema puxado, removendo a variabilidade (uma das fontes de desperdício) em uma etapa do processo inserindo um pequeno buffer de WIP de alta qualidade “igualmente dimensionado” antes deste etapa.

Esta é uma motivação por trás da ideia de itens “preparados” no Scrum — apenas oferecer itens para equipes de implementação que estão prontos em termos de questões claramente compreendidas, histórias pequenas, pendências resolvidas, etc. Itens preparados podem ser usados ​​como uma ferramenta para nivelar ou suavizar a introdução de trabalho para equipes de funcionalidades. Um buffer pequeno de WIP de alta qualidade de itens ‘preparados’ no Product Backlog criado para suportar um sistema puxado é um exemplo de desperdício necessário temporariamente introduzido para resolver outro problema … variabilidade.

Foco na variabilidade, sobrecarga e ações que não agregam valor—No pensamento enxuto, há três fontes de desperdícios, ilustradas e comentadas com ideias de resolução no diagrama a seguir. A melhoria contínua envolve ver e eliminar a variabilidade, sobrecarga e ações que não agregam valor.

O pessoal da Toyota que observa tentativas de fora para adotar Lean, percebem um mal-entendido sobre desperdício- o conceito errado de se concentrar apenas na eliminação de ações que não agregam valor, como o super processamento ou testes para remover defeitos (ao invés de construir qualidade) [LM06a]. Dentro da Toyota, são dadas importâncias a todas as três fraquezas, e na verdade, a variabilidade e a sobrecarga são vistos como causas raízes frequentes que dão origem a ações que não agregam valor. Por exemplo, os programadores sobrecarregados criam mais defeitos.

Desafio da Perfeição

Este é o terceiro elemento de melhoria contínua no pensamento enxuto.

Durante uma visita à Toyota, convidamos um engenheiro aposentado para jantar em Nagoya. Depois de várias rodadas de saquê, perguntamos: “O que você perde, uma vez que não está mais trabalhando na Toyota?” Ele respondeu: “Não mais discutir sobre a perfeição com as pessoas”.

Às vezes visitamos uma organização e alguém se opõe à ideia de mudar com esse argumento: “Estamos entregando produtos, ganhando dinheiro e temos processos estabelecidos. Por que devemos mudar nossas práticas?” Nós não pensamos que você ouviria essa pergunta na Toyota. Eles estão longe de serem perfeitos e não estamos sugerindo simplesmente copiá-los, mas sua cultura é ter uma mentalidade kaizen - ter grandes expectativas e se desafiarem, desafiarem os membros das equipes e os parceiros para atingirem níveis de habilidade, domínio, redução de desperdícios e visão muito além do status quo.

Isso é poderoso.

Sem Processo Final

Em 2001, a Toyota criou um manual interno chamado Toyota Way resumindo os princípios enxutos. Ao ouvir o título proposto, o presidente Toyoda sugeriu renomear o manual para Toyota Way 2001. Por quê? Para enfatizar que não há nenhum processo final em Toyota (o que violari o kaizen) mas, em vez disso, melhoria contínua e mudança.

A implicação do kaizen e a propagação do conhecimento de forma lateral é que não há um processo final ou “definido” corretamente a ser seguido em toda parte e comunicado a partir de uma estrutura centralizada. Kaizen inclui aprender e dominar acordos de trabalho, mas eles se propagam e evoluem pelo modelo yokoten de disseminar conhecimento lateralmente. As pessoas que possuem a mentalidade “vamos definir (ou comprar) o processo e, em seguida, devemos nos concentrar em manter a conformidade com ele por um longo tempo” não se sentirá confortável com o pensamento enxuto. Para citar um CEO da Toyota, “A raiz do Toyota Way é estar insatisfeito com o status quo; Você tem que perguntar constantemente: “Por que estamos fazendo isso?” Valores enxutos e ágeis - e LeSS - são baseados na ideia de processo empírico: não há um processo fixo ou final ou livro de receitas que as pessoas possam seguir dada a realidade das mudanças dinâmicas de sistemas, e dado o objetivo da melhoria contínua. Em vez disso, no LeSS ficamos com o trabalho árduo de kaizen — para implacavelmente, em cada Sprint — inspecionar e adaptar os processos e criar mais um “experimento de duas semanas de técnicas e processos.” Nesse sentido, LeSS é um framework de metaprocesso para instalar e avaliar processos e práticas.

Na Toyota e no LeSS, a ideia é repetir este ciclo para sempre. Por exemplo, as regras do LeSS são apenas um ponto de partida simples de mecanismos que aumentarão a transparência e a agilidade e permitirão a entrega antecipada de valor. Eles não são algo para limitar para sempre. Dito isto, kaizen começa no primeiro passo com “fazer as práticas/processos à risca até que eles sejam dominados e totalmente apreendidos com experiência direta.” É por isso que no pensamento enxuto existe a afirmação: “Onde não há padrão, não pode haver kaizen”.

Trabalho através do fluxo

Fluxo sugere tornar o fluxo de valor sem demora para o cliente. Como exemplo, um pedido do cliente espera em uma fila esperando para ser aprovado, analisado, implementado, reformulado ou testado. Isso não é fluxo. Em vez disso, conforme o valor é criado — em produtos, software, informações, decisões, serviço — ele flui imediatamente para o cliente. Ele está relacionado com a metáfora siga o bastão e com a meta do “conceito ao dinheiro” mais rápido. Fluxo é um desafio da perfeição; O desperdício zero no sistema e o fluxo de entrega contínua de valor são desafios profundos, provavelmente nunca alcançados. A jornada geralmente é sobre mover-se através do fluxo.

No pensamento enxuto, o fluxo está incluído nos princípios 14 princípios e nos elementos-chave da melhoria contínua. Por quê? Porque para mover-se através do fluxo é necessário reduzir o tamanho do lote, o ciclo de tempo, o atraso, o WIP, e outros desperdícios. E isso tem o efeito colateral benéfico de revelar mais fraquezas e desperdícios, proporcionando novas oportunidades de melhoria contínua. Este é um ponto importante mas sutil, expandido nos Benefícios Indiretos da Redução do Tamanho do Lote e o Ciclo de Tempo.

Mover-se através do fluxo está associado com a teoria das fila aplicada, sistemas puxados e muito mais. Ao entendê-los, as pessoas podem mover o sistema através de fluxo com pacotes de trabalho com tamanhos menores, tamanhos de filas menores e redução na variabilidade. Isso é explorado na Teoria das Filas.

Sistemas Puxados

Puxado versus empurrado—Considere um processo para a fabricação e armazenamento de computadores portáteis. Em um sistema puxado puro nenhum laptop é construído ou armazenado no inventário até que haja uma ordem do cliente. Inventário zero e zero WIP é um objetivo, e o trabalho é feito apenas em resposta a um sinal de ‘puxar’ do cliente. Esse é o significado chave de puxar: construir em resposta a um sinal do “cliente”, e de resto descansar ou melhorar. Mais exemplos puxados? Imprimir apenas a encomenda de vinte livros ou preparar apenas um prato de restaurante.

Mas um sistema puxado é mais profundo que isso — o ‘cliente’ não é apenas o cliente final. Em vez disso, em um processo multiestágio com uma equipe front-end fazendo um trabalho parcial antes de uma equipe back-end, uma equipe back-end é o cliente para sua equipe front-end. Em um sistema puxado puro, a equipe front-end não cria nada a menos que seja puxada de um pedido back-end.

Por outro lado, em um sistema empurrado, existe uma construção especulativa e armazenamento de laptops na esperança de encomendas, e depois a tentativa empurrá-los para os clientes. Em um processo multiestágio, as equipes front-end criam um inventário de trabalho parcialmente feito para equipes back-end. Qualquer tipo de inventário especulativo — pizzas, grandes planos detalhados, livros, especificações para muitas características cujo valor é incerto — estão relacionados aos sistemas empurrados.

Estratégias de gestão de recursos que se concentram na alta utilização dos trabalhadores — com foco em assistir os corredores em vez de *passar o bastão * — criam um ambiente em que as pessoas vão criar um grande inventário de coisas (requisitos, desenhos, código ) em um modelo empurrado.

Exponha defeitos—Se você só criar uma coisa em resposta puxada a um pedido de cliente e o cliente consumi-lo rapidamente, quaisquer defeitos — criados seja por acidente ou por design– são rapidamente descobertos. Isso pode levar a uma melhoria sistêmica adicional se as pessoas tiverem uma mentalidade de “parar e corrigir”. Por outro lado, em sistemas empurrados, os defeitos são escondidos em um inventário não consumido (de requisitos, código, …). Por exemplo, empurrar um grande lote de requisitos atrasará a descoberta de mal-entendidos ou problemas, porque existe um longo intervalo de tempo antes de serem implementados e avaliados (como software em execução) por um cliente.

Decida o mais tarde possível—Em sistemas puxados, você não decide antecipadamente, muito pelo contrário - você “decide o mais tarde possível” e “se compromete no último momento responsável”. Desta forma, você tem mais informações para tomar decisões mais assertivas. Você não desperdiça recursos criando inventário desnecessário ou tomando decisões iniciais que terão que — ou pelo menos deveriam — mudar em resposta à descoberta.

Pequenos lotes podem levar a uma melhoria radical—Um sistema puxado implica em lotes menores em ciclos curtos e frequentes. Usando os velhos processos baseados em sistemas empurrados de grande escala (com base no pensamento de economias de escala que evita a mudança), ciclos mais curtos podem aumentar a sobrecarga geral ou custo de transação e, portanto, serem vistos como ineficientes. O caminho para sair desse enigma é uma melhoria radical e “fora da caixa” em processos que podem abraçar a mudança e pequenos lotes de forma eficiente. Este é um segredo por trás da eficiência da Toyota — sistemas puxados com pequenos lotes combinados com kaizen trazem novas formas de trabalho que abaixam o custo de transação de um ciclo de processo. Esta dinâmica de melhoria é explorada em Benefícios Indiretos da Redução do Tamanho do Lote e o Ciclo de Tempo.

Assim, de várias maneiras, os sistemas puxados suportam a movimentação através do fluxo.

Respeito pelas pessoas

O respeito pelas pessoas soa nebuloso, mas inclui ações concretas e culturais dentro da Toyota. Eles refletem amplamente respeito e sensibilidade à moral, não fazendo as pessoas realizarem trabalho desperdiçado, real trabalho em equipe, mentoria para desenvolver pessoas hábeis, humanizando o ambiente de trabalho e ambiente, seguro e limpo (dentro e fora da Toyota), e a integridade filosófica entre a equipe de gerenciamento.

Em termos de melhoria contínua, está incluso não eliminar empregos por causa da melhoria. A segurança do trabalho é um princípio importante na Toyota. Se as pessoas sentem que a melhoria levará ao fim de seu emprego, o que você acha que vai acontecer? No entanto, a segurança no trabalho não é o mesmo que zona de conforto ou posição de segurança. Melhoria pode significar a eliminação de funções gerais ou de função única, mas em uma cultura enxuta, novas funções são então encontradas para os funcionários.

Respeito pelas pessoas também inclui fomentar uma cultura de trabalho e moral coerente com a pesquisa de satisfação no local de trabalho e a motivação aumentada — que apoiará a melhoria contínua. Isso inclui o trabalho auto dirigido, oportunidades de desafio e maestria, e um senso de propósito. No LeSS há um foco em equipes auto-organizadas (equipes de trabalho auto dirigidas), tornando-se multi especializadas dentro de uma equipe multifuncional e conectando-se diretamente com clientes reais e estando mais perto do negócio. Isso é consistente com a pesquisa em maior potencial de motivação.