Qual a importância da transparência?
A transparência é o conceito que permite "ver", em tempo real, agora, o que está acontecendo no seu processo, permitindo que você determine se algo mudou ou precisa de atenção. Andons, esboços de ferramentas 5S e placas heijunka são exemplos de transparência. Por exemplo, ao olhar para um conselho de Heijunka, podemos dizer se a produção está adiante, por trás ou no cronograma. Podemos fazer essa avaliação agora mesmo em tempo real. Não é necessário verificar o centro de informações. Não é necessário verificar com o armazém ou algum banco de dados do computador; o quadro de Heijunka nos permitirá "vê-lo" diretamente, neste momento. Hoje, é mais comum ouvir as frases, o gerenciamento visual ou o sistema visual usado em lugar da transparência. No entanto, prefiro a transparência porque melhor captura o conceito, como você "verá" no exemplo mais tarde.
Transparência incompreendida
Uma grande parte do conceito original de transparência foi perdida. A maioria do que é comummente exibido como transparência é realmente o gerenciamento visual e é muito longo no "visual" e muitas vezes curto em "gerenciamento". Infelizmente, a maioria dos lançados não é consistente com o conceito original de ser capaz de "ver" o que está acontecendo no processo. Um exemplo comum de "gerenciamento visual" são placas de exibição que mostram o status de coisas como volumes de produção mensais, o status de resolução de problemas e manutenção preventiva, por exemplo.
Muitas vezes, essa informação é mantida em um local, conhecido como um centro de informações. O centro de informações geralmente possui informações de processo, tais como tabelas de combinação de trabalho padrão, gráficos de trabalho padrão e outras informações intensivas em engenharia que, geralmente, não são valiosas no chão, mas crie papel de parede agradável no centro de informações. Toda essa informação é necessária, em algum momento, em algum lugar, e por algum motivo. O que deve ser mantido na linha é o que será usado na linha. Mantenha essa informação lá, o resto deve ser mantido onde é necessário.
Qual o objetivo final da transparência?
No entanto, o objetivo final da transparência, é o PDCA: "Plan-Do-Check-Act". Este é o ciclo de melhoria de processo iterativo inerente ao processo de melhoria do kaizen. Como parte do PDCA, primeiro é necessário determinar que algo mudou, como uma indicação de taxa de produção. Em seguida, é necessário:
- Planejar uma ação corretiva ou contramedida (Plan).
- Implementá-lo (Do).
- Confirme se é bem-sucedido ou não (Check).
- Determine se ações adicionais ou inatividade pensativa são apropriadas (Act).
O ciclo então começa tudo de novo; portanto, é um processo iterativo. Assim, é essencialmente necessário ter algumas informações para poder:
- Discernir que algo mudou.
- Confirme se a contramedida foi ou não foi bem sucedida.
Além disso, para executar o PDCA de Resposta Rápida, ou em linguagem Lean, para fazer isso em uma forma JIT (Just In Time), requer informações JIT. Esta disponibilidade de informações JIT é sobre o que é a transparência. Em um sistema transparente, esses dados estão disponíveis JIT.
Um exemplo da implementação da transparência
Por exemplo, em uma usina de fabricação elétrica de alta velocidade com múltiplas linhas operando em tempos de ciclo de 6,65 segundos, era difícil dizer, exceto após várias horas de operação, se as linhas estivessem produzindo o plano. Mesmo uma vez que conseguimos compreender a produção, se houvesse problemas, não tínhamos ideia de onde os problemas pudessem ser, então a solução de problemas de JIT (Just In Time) era algo que não era possível.
Além disso, os técnicos, líderes de linha e supervisores de área estavam sempre ocupados. Eles estavam sempre corrigindo alguma coisa. No entanto, as histórias do que foi feito e do porquê foram feitas foram preenchidas com generalidades e termos como "Não estava funcionando bem."
Estes são sinais claros de uma série de coisas. Deixe-me referir três:
- Felizmente, os trabalhadores, bem como a gerência, foram motivados e envolvidos. Eles estavam tentando fazer as coisas certas e eles estavam fazendo um trabalho que se assemelhava à descrição do trabalho.
- Infelizmente, eles estavam fazendo muitas coisas erradas.
- Ainda mais infelizmente, mesmo quando eles fizeram as coisas certas, houve feedback inadequado de informações para confirmar que algo positivo tinha sido feito.
Neste momento, as informações relevantes para avaliar a taxa de produção, que estava disponível no chão, incluíam andons, rejeitaram os produtos segregados em caixas de coleta e placas de produção que cobriam o funcionamento de um dia inteiro.
Os andons não tinham gravação, apenas recursos de advertência. Por isso, eles não eram úteis para resolução de problemas, a menos que estivéssemos ali mesmo quando foram ativados ou limpos. Os dados da sucata foram classificados e gravados por hora, mas a sucata real foi muito baixa e não foi um fator na baixa produção.
Quais são os dados?
As placas de produção tiveram metas de produção horárias e cumulativas com números de produção reais inseridos no topo de cada hora. Esses objetivos foram calculados com base no objetivo horário de 600 unidades por hora, levando em conta almoço e descanso. Havia 21,5 horas disponíveis por dia, então o objetivo da produção diária era de 12,9 mil unidades. Este objetivo horário foi atingido quase 50 por cento do tempo, mas o objetivo diário foi atingido em menos de 3 por cento do tempo. Uma revisão dos dados do mês passado mostrou produção de 9.330 unidades / dia, ou 434 unidades por hora: um objetivo total de 27 por cento abaixo.
Como parte de seu sistema de gestão, houve uma reunião de produção diária no chão, administrada pelo supervisor de linha. Durou cerca de 15 minutos e teve uma boa agenda, mas quando a falta de produção foi discutida, o que era um tema quase todos os dias, as respostas foram - bem, incrível é a melhor palavra que podemos usar. Primeiro, eles eram muito genéricos e em quase todos os casos em que um problema específico foi discutido, foi decretado para ser resolvido. Infelizmente, esses mesmos problemas reapareceriam mais tarde, e não parecia estranho para ninguém que, embora esses problemas já estivessem resolvidos, eles ainda reapareceram.
Francamente, durante esta parte da reunião, provavelmente, todos estavam no "piloto automático". Era evidente que aceitaram essas explicações "incríveis" por tanto tempo que eles acreditavam em si mesmos. No entanto, dia após dia, a produção permaneceu abaixo do objetivo e foram forçados a trabalhar sete dias por semana para atender um plano por cinco dias. Nesse caso, podemos concluir que os dados de produção eram inadequados - não havia "transparência" dos dados de produção. Nós não podíamos entender se estávamos no plano, nem podemos resolver problemas quando os entendemos.
Quais os problemas?
Após uma reunião com a alta gerência, foi decidido que assumir a baixa produção era o objetivo número um. Foi o principal motivo pelo qual esse produto foi altamente improcedente. A primeira coisa realizada foi tentar dividir o problema em peças resolvíveis. Pedimos três perguntas. É a falta de produção devido a:
- Perda de qualidade
- Perda de disponibilidade
- Perdas de tempo de ciclo
Tivemos a informação de qualidade, e nesta etapa do processo, as perdas de qualidade foram insignificantes. Nossos compartimentos de segregação nos deram todas as informações em tempo real que precisávamos. Poderíamos "ver" que as perdas de qualidade não eram a resposta para o nosso baixo problema de produção. Ou em linguagem Lean, nossa transparência quanto ao rendimento de qualidade era adequada para essa questão.
Agora, devemos determinar se a disponibilidade era um problema. Uma verificação rápida mostrou que as saídas de materiais eram virtualmente inexistentes, mas os técnicos estavam trabalhando nas máquinas aparentemente o tempo todo. Tempo de inatividade significativo ocorreu, mas nós não sabíamos o quanto disso e nós não sabíamos o que estava causando o tempo de inatividade. Tivemos preocupações sérias aqui, mas não temos informações sobre as perdas de disponibilidade. Nossa transparência neste caso não era apenas inadequada, era inexistente, mas nós possuíamos os andons.
E o tempo de ciclo?
Em seguida, analisamos o tempo de ciclo. Além de alguns estudos de tempo realizados pelos engenheiros, não havia dados disponíveis sobre o tempo de ciclo. O tempo de ciclo medido foi anunciado para ser de 6,0 segundos. Se o processo realizado neste tempo de ciclo, a produção deve ser de 600 unidades por hora - o objetivo horário mencionado anteriormente. Nenhuma medida de tempo de ciclo - de qualquer tipo - foi feita no chão. A transparência sobre o tempo de ciclo foi semelhante à informação de disponibilidade. Era inadequado e praticamente inexistente.
Com esta revisão, decidimos implementar um programa OEE (Overall Equipment Effective). A informação do OEE nos permitiria iniciar a compreensão das perdas de produção e segregar as informações em perdas de qualidade, perdas de disponibilidade e perdas de tempo de ciclo. Os formulários foram feitos, o treinamento foi feito na coleta e entrada de dados, e as informações foram configuradas para gerenciar esses dados com feedback após cada turno.
Em breve descobrimos que as perdas foram de cerca de 20% em tempo de ciclo e quase 10% das perdas de disponibilidade. Embora o OEE esteja sempre atrasado, foi uma informação valiosa e nos disse que precisávamos trabalhar em tempo de ciclo e disponibilidade. No entanto, quando se tratava de entender e melhorar o processo em tempo real, não estávamos mais perto do que uma mudança de boas informações, então precisávamos melhorar isso. No entanto, estabelecemos alguns objetivos, criamos uma planta de melhorias, e a primeira coisa que atacamos foi o tempo de ciclo. Nós fizemos um estudo controlado e descobrimos que o tempo de ciclo era de 6,65 segundos, o que surpreendeu a todos. Isso significava que o objetivo de 600 unidades por hora não era mesmo alcançável.
Como tratar o gargalo?
O gargalo de 6,65 segundos foi uma operação manual no processo de soldagem. Esta máquina de solda era operada por um robô que tinha um microprocessador com uma pequena tela. Usando uma grande imaginação e inovação, o supervisor de engenharia encontrou uma maneira de programar o microprocessador e exibir o tempo de ciclo para a operação manual. O operador agora tinha informações em tempo real sobre o tempo de ciclo. Imediatamente, o tempo de ciclo começou a cair e estabilizar, e a produção aumentou de maneira semelhante. A queda no tempo de ciclo foi incrível. Em menos de duas semanas, melhorou para 5,5 segundos. Várias atividades de kaizen foram implementadas para melhorar a estação de trabalho ainda mais.
Uma dessas atividades foi programar o microprocessador para exibir o tempo médio do ciclo. Ele contava qual era a média, quantas unidades eram produzidas com essa média e quando a média havia começado. Nós instalamos a estação com um botão de reinicialização e- voilà! - nós tivemos uma excelente transparência. Em última análise, após alguns eventos kaizen, conseguimos atingir ciclos de 4,6 segundos, consistentemente. Além disso, agora o operador, o supervisor e qualquer pessoa interessada podem olhar para a exibição e ver como o processo estava funcionando. Literalmente, poderíamos encontrar a taxa de produção instantânea. Esta foi uma solução imaginativa que aumentou significativamente a transparência do sistema.
No entanto, lembre-se de que as perdas de disponibilidade foram de cerca de 10%. As informações do OEE foram valiosas para nos ajudar a entender as perdas, mas não são de grande utilidade para solucionar muitos dos problemas devido à natureza retardada da informação. No entanto, foi possível reduzir algumas perdas. Os registros de informações de folha de verificação em placas brancas foram instalados no andons para coletar informações no momento em que o andon foi ativado, ajudando a destilar a informação e a disponibilizá-la para uso futuro. Assim, uma função de gravação para os andons foi criada.
A importância de padronizar!
Mas, a revisão das informações da OEE mostrou que 90 por cento das perdas de disponibilidade foram devidas a ajustes de máquinas. Uma revisão rápida mostrou que a maioria dos ajustes não poderia ser explicada e eram aparentemente "mexer" por técnicos bem-intencionados. Após algum treinamento, alguns procedimentos de trabalho esclarecidos, essas perdas de disponibilidade imediatamente caíram como uma pedra - como fez a carga de trabalho dos técnicos. No entanto, eles não estavam confortáveis com isso, uma vez que eles estavam altamente motivados, muito enérgicos e não estavam acostumados a ter algum tempo livre.
Pode-se perguntar como foi atingidoo objetivo horário de 600 unidades quando o tempo do ciclo do processo não o suportaria e nossa produção média era de apenas 433 unidades por hora? Bem, a resposta é simples e reveladora.
A parte simples é essa. A forma como a produção foi medida era contar a produção de bandejas que cada uma possuía 120 unidades e multiplicava pelo número de bandejas. Nenhuma tabela parcial foi contada. Assim, a produção foi em múltiplos de 120. Uma bandeja de 120 unidades foi o lote de transferência. Além disso, uma vez que os líderes de linha sabiam que os gerentes queriam que o objetivo da produção fosse cumprido, era melhor atender o objetivo o tempo todo do que nenhum tempo. Consequentemente, no topo da hora quando a produção foi contada, se uma bandeja estava quase cheia, o líder da linha pode esperar para inserir os dados. É claro que, na próxima hora, a produção foi ainda mais curta do que seria se os dados tivessem sido relatados com precisão.
Dividir para conquistar
Este lote de transferência de 120 unidades criou alguns problemas além de contabilizar a produção, então cortamos o tamanho do lote de transferência para 48 unidades. Isso não só ajudou a contabilidade, mas reduziu o prazo de processamento, como você poderia esperar.
Então, como isso é tão revelador? Foi um sintoma de toda a instalação. Todo mundo queria fazer bem e ser visto fazendo bem. Como eu disse anteriormente, eles eram um grupo motivado. E essa motivação nos serviu bem enquanto implementamos outras mudanças e melhorias de processos.
Podemos continuar, mas vamos analisar brevemente o que acabamos de discutir.
- Primeiro, nosso sistema de produção melhorou. A taxa de produção aumentou 42%, com virtualmente nenhum capital investido.
- Em segundo lugar, uma vez que as melhorias foram feitas, agora poderíamos "ver" o status do sistema, e se houvesse problemas, poderíamos encontrar e implementar rapidamente as contra medidas necessárias. Agora tivemos a informação para fazer o PDCA de Resposta Rápida. A transparência do nosso sistema melhorou imensamente, permitindo a nossa resolução de problemas também melhorar imensamente.
Esse tipo de dica você confere nos nossos cursos de Lean, White Belt, Green Belt e Black Belt e podem te ajudar a identificar perdas e mitigá-las.
