Criado há mais de sessenta anos, o sistema de produção just-in-time foi bastante admirado no mundo inteiro por volta de 1980 pelos seus significativos ganhos na melhoria da qualidade e no aumento da eficiência (Liker 2004).

Entretanto, nessas seis décadas, o mercado mudou: os clientes finais passaram a desejar produtos personalizados, com amplas opções de cores e modelos. Empresas, especialmente as montadoras de computadores e de automóveis, passaram a fornecer configuradores de produto em suas páginas de internet. Neles, os clientes escolhem item a item como desejam os seus produtos, transformando
as suas ordens de compra em pedidos praticamente únicos tendo em vista as inúmeras combinações possíveis. É nesse contexto que o método Toyota de produção ganha a atenção do mundo industrial mais uma vez, já que, nele, cada produto é montado para um cliente final já existente e conhecido.

Mesmo tendo sido criado na década de 40, a literatura existente sobre sistema de produção puxado está cheia de lacunas, principalmente na parte da aplicação prática. Além disso, o entendimento de alguns tópicos, como o funcionamento do kanban, por exemplo, torna-se difícil sem a visualização de um diagrama ou uma animação.

O presente projeto teve início com a necessidade de um aprofundamento teórico por parte de um professor de gestão da produção juntamente com um aluno de gestão industrial interessado em compreender a aplicação prática dessa teoria. Além disso, uma grande empresa de consultoria demonstrou interesse no uso da simulação para melhorar o desempenho dos ciclos de reabastecimento das células de produção em sistemas de produção just-in-time. Então, é de se esperar que as componentes teórica, didática e prática sejam equilibradas e satisfatoriamente preenchidas ao longo deste texto,
fazendo do mesmo um trabalho interessante para alunos, professores, pesquisadores, profissionais e curiosos.

O presente relatório encontra-se dividido em quatro partes, as quais estão descritas abaixo.

Primeiramente é feita uma revisão dos aspectos teóricos relativos ao sistema de produção just-in-time de uma forma sucinta, pois a intenção deste texto não é a de debater nem analisar tal forma de produzir. Entretanto, deseja-se prover o leitor com um conjunto de definições e comentários imprescindíveis para a compreensão dos eventos ocorridos durante a execução do simulador, habilitando-o a analisar de forma crítica os relatórios exibidos ao final do mesmo.

A seguir é apresentado um capítulo inteiro sobre o simulador, incluindo os pré-requisitos elencados para o seu desenvolvimento, as suas funcionalidades e possibilidades de expansão. Além disso, é explicado o ciclo de reabastecimento adotado e o que acontece em cada etapa do mesmo.

Na terceira parte encontram-se os resultados obtidos de diferentes cenários considerados relevantes. Ou seja, são analisadas aquelas condições iniciais associadas a um comportamento da demanda e a uma capacidade produtiva. Ainda é apresentada uma comparação entre os diferentes cenários baseada nos indicadores selecionados.

Por fim, é feito um comentário sobre o simulador e os ganhos obtidos com a utilização do mesmo, incluindo ainda as sugestões de trabalho futuro nesta área.

Luiz Freire,

Setembro de 2008

Porto, Portugal

O Sistema Toyota de Produção

O ano era 1950 e o Japão estava com suas fábricas totalmente destruídas por causa da sua derrota na segunda guerra mundial. O então presidente da Toyota, Eiji Toyoda, e o engenheiro Taiichi Ohno passaram três meses no complexo da Ford nos Estados Unidos estudando os métodos de produção fordista para entender porque a produtividade dos operários americanos era dez vezes superior à dos orientais (Ohno 1997). Tal diferença de produtividade só poderia ser explicada pela existência de perdas no sistema de produção. A partir daí, o que se viu foi a estruturação de um processo sistemático de identificação e eliminação das perdas (Ghinato 2000). O objetivo principal era reorganizar a fábrica japonesa e torná-la numa grande montadora de veículos.

Ohno e Toyoda concluíram que nem o sistema de produção em massa, nem o sistema artesanal iriam ser aplicáveis à sua realidade. Era preciso adaptá-los e criar um sistema novo com características diferentes (Womack, J.P. apud Zagonel 2006). Inversamente ao que acontecia com a fábrica Ford, a Toyota possuía um reduzido capital de giro e operava num país pequeno e com poucos recursos. O novo sistema de produção deveria então fazer com que o dinheiro investido na fabricação de cada automóvel fosse recebido de volta o mais rápido possível (Liker 2004).

Atualmente, o Sistema Toyota de Produção (STP) é visto não apenas como um conjunto de métodos e regras, mas como uma nova filosofia de produção que procura otimizar a organização de forma a atender as necessidades do cliente no menor prazo possível, na mais alta qualidade e ao mais baixo custo, ao mesmo tempo em que aumenta a segurança e o moral de seus colaboradores, envolvendo e integrando não só a manufatura, mas todas as partes da organização (Ghinato 2000).

Pode-se afirmar que uma das grandes mudanças proposta pelo STP é o fato de puxar a produção em vez de empurrá-la. Isso significa que os produtos não são empurrados para os clientes finais pelos vendedores e, posteriormente, retirados do armazém. Na produção puxada, montam-se os produtos de uma forma muito rápida, começando a produzi-los pouco antes da data em que devem ser entregues e concluindo-os apenas no dia exato, ou seja, just-in-time (JIT).

A comparação dos dois parágrafos anteriores permite dizer que o just-in-time é apenas uma parte do STP, geralmente utilizada em conjunto com a autonomação e outras ferramentas. Essa última, também é conhecida como automação com toques humanos. De acordo com o seu idealizador, pode-se dizer que ambos representam os dois pilares principais daquele sistema (Ohno 1997). De maneira a ratificar tal informação, estão descritos, a seguir, de forma concisa, todos os princípios do sistema de produção oriental. Contudo, mesmo estando intrinsecamente relacionados, este trabalho aborda apenas o método de produção puxado, uma vez que o os outros componentes do sistema Toyota não estão diretamente implementados no simulador desenvolvido.

Eliminação dos Desperdícios e o Princípio do Não-Custo

A essência do Sistema Toyota de Produção está na constante busca pela erradicação total das perdas. Antes, o preço de um produto era imposto ao Mercado, sendo o seu valor determinado pela soma dos custos de fabricação com a margem de lucro pretendida. Com uma economia mais competitiva, o cliente é quem passou a ditar os preços dos produtos, cabendo às empresas a escolha entre venderem suas mercadorias por tal preço ou fecharem as suas portas.

Para a Toyota, a única forma de aumentar ou manter o lucro após essa mudança de abordagem é através da redução das perdas existente no sistema. Ou seja, eliminar toda e qualquer atividade que não agrega valor ao produto.

Desperdício de Superprodução: de todas as sete perdas listadas por (Ohno 1997), a perda por superprodução é considerada a mais danosa, uma vez que esconde os outros tipos de perdas e é a mais difícil de ser eliminada.

A perda por superprodução por quantidade é a perda por produzir além daquilo que é necessário. Já a perda por superprodução por antecipação é a perda decorrente de uma produção realizada antes do momento necessário, fazendo com que as peças fiquem espalhadas pela fábrica aguardando a hora de serem processadas por etapas posteriores.

Desperdício de Tempo Disponível (Espera): é aquela perda gerada quando um lote está à espera da liberação de um recurso para ser processado. Ou então, quando as peças já trabalhadas de um lote esperam pelo processamento das restantes para que possam avançar para a etapa seguinte. Ou ainda, quando um operário que acabou o seu ciclo de produção, fica à espera do término da operação a montante ou a jusante.

Desperdício em Transporte: sendo o transporte dentro das instalações industriais uma atividade que não agrega valor, passa a ser interpretado como uma perda e deve ser reduzido ao mínimo possível ou até mesmo eliminado. As melhorias mais significativas, em termos de redução das perdas, são aquelas aplicadas ao processo de transporte, obtidas através de alterações de layout que dispensem ou eliminem as movimentações de material (Ghinato 2000).

Desperdício do Processamento em Si: são perdas ao longo do processo produtivo devido exclusivamente à baixa no desempenho dos equipamentos causada por quebras de máquinas. O desperdício do processamento em si ainda inclui as perdas causadas pela rejeição de algum material que ainda poderia ser utilizado para a produção.

Desperdício de Estoque Disponível: é causado pelos produtos acabados ou produtos em fabricação em excesso. A eliminação desta perda favorece a identificação de outras perdas não aparentes no sistema devido à função de proteção do inventário. Embora a sua diminuição deixe o sistema mais exposto aos riscos de falta de insumos e de quebra de máquinas, a redução dos estoques é considerada benéfica, pois além de reduzir os custos a ele relacionados, permite que os problemas escondidos se tornem mais evidentes antes de serem igualmente extintos.

Desperdício de Movimento: causado pelos movimentos dos operários que não agregam valor. Este tipo de perda pode ser eliminado através de melhorias baseadas no estudo de tempos e movimentos.

Desperdício de Produzir Produtos Defeituosos: é causado pela fabricação de produtos não conformes. A sua redução é obrigação direta, não só do setor de qualidade, mas como de toda a fábrica. A sua erradicação é conseguida após a eliminação da causa raiz da mesma.

Autonomação

Este princípio, também conhecido como jidoka, propõe a extinção da relação biunívoca homem-máquina. Ou seja, deixou de ser necessário um operário apenas para verificar se a máquina está trabalhando corretamente, sendo o mesmo requerido apenas no momento de abastecimento e na recolha da produção. Com a automação da detecção de erros, o operário fica livre para abastecer também outras máquinas enquanto a primeira está trabalhando, tal como se representa na figura 1.

A jidoka se tornou possível através do aprimoramento de dispositivos capazes de detectar anormalidades. Foi usada inicialmente nos teares automáticos da Toyoda. Neles, a produção era interrompida automaticamente assim que o fio lã fosse rompido.

Comparado ao tradicional sistema de um homem/um posto/uma tarefa, o sistema de operação de múltiplas máquinas pode proporcionar um aumento de 30% a 50% de produtividade, enquanto que o sistema de múltiplos processos é capaz de aumentar a produtividade de 50% a 100% (Shingo apud Ghinato 1999).

No Sistema Toyota de Produção, a automatização está sempre relacionada com a implementação da capacidade da máquina de detectar qualquer anormalidade e parar imediatamente.

Padronização das Operações

A padronização das operações pode ser definida como um método efetivo e organizado de produzir sem perdas (Ghinato 1999). Tal método almeja a produtividade máxima de cada funcionário eliminando das suas operações todos os tipos de perda. Todos os passos são registrados para que sejam repetidos de maneira uniforme por todos os operários em um ritmo de produção estabelecido que satisfaça a demanda.

A padronização é importante, pois permite ao operador repetir o ciclo de forma consistente ao longo do tempo. A determinação de uma rotina-padrão de operações evita que cada operador execute aleatoriamente os passos de um determinado processo, reduzindo as flutuações de seus respectivos tempos de ciclo (Ghinato 2000).

A seqüência de movimentos e tarefas necessárias para produzir uma peça é anotada numa ficha de trabalho padrão. Nela, pode-se identificar o tempo de ciclo, ou seja, o tempo decorrido entre o início da mesma operação em duas peças subseqüentes. Sendo assim, o operário deve executar os movimentos da maneira exata como descrita no documento e no tempo determinado. De acordo com (Bodek 2007) essa ferramenta é usada largamente no Japão, onde os supervisores estão sempre fazendo revisões e comparando com os vídeos obtidos dos postos de trabalho. O objetivo é verificar se há diferenças entre os movimentos realizados pelo trabalhador e aqueles descritos. Também, quando possível, se eliminam alguns movimentos desnecessários para deixar o operador mais eficiente. (Miltenburg 2000), ressalta que se deve buscar uma alta utilização do operário e nunca da máquina.

Nos anexos, encontra-se um exemplo de uma folha padrão de operações. Nela, existem nove atividades executadas por um único operador em sete máquinas diferentes acrescidas das atividades de carga e descarga da linha.

Eliminação da Causa do Problema

A Toyota considera inaceitável a correção de um erro através do retrabalho, já que essa atitude é insuficiente para a manutenção e melhoria do sistema. O STP orienta que em vez de corrigir o defeito, deve-se eliminar a causa do mesmo, pois só assim não haverá reincidência.

Círculo de Controle da Qualidade

Os Círculos de Controles de Qualidade (CCQ) tiveram origem no Japão por volta de 1962, criados pelo Professor Kaoru Ishikawa, como resultado de um impulso dado à qualidade na indústria japonesa e os conseqüentes contatos entre as universidades e os operadores de fábricas (Sato Consultoria de Pessoal 2008).

O CCQ é um pequeno grupo de funcionários voluntários que tentam melhorar a qualidade dos seus produtos ou do seu trabalho. Pode ser considerado como uma evolução da qualidade total na qual todas as pessoas são responsáveis pela qualidade, mesmo aquelas que trabalham em funções não diretamente relacionadas à produção.

Na sua filosofia, a qualidade não é apenas uma fabricação de acordo com as especificações. O CCQ busca a qualidade desde o projeto e se preocupa com a adequação do produto ao uso a que se destina. Espera-se que os programas da qualidade apontem para a perfeição; qualquer coisa inferior é considerada uma meta provisória a ser sucedida.

Melhoria Contínua

Também conhecida pelo termo japonês kaizen, é a melhoria incremental e cíclica de uma atividade com o objetivo de chegar à perfeição, ou seja, eliminação de todos os tipos de perdas. Essa ferramenta é uma importante base do sistema Toyota o que faz com que o mesmo esteja sempre progredindo e alcançando melhores resultados. Entre algumas de suas vantagens, podemos destacar o fato de os progressos serem implementados de maneira suave e muito mais freqüente que na maneira tradicional. Isso permite uma maior aderência da necessidade de eliminação das perdas na cultura do trabalhador o qual está sempre pensando em como aperfeiçoar suas atividades. Pelo fato de ser bastante freqüente, o custo associado à sua implementação é pequeno na maioria dos casos.

Manutenção Produtiva Total

A Manutenção Produtiva Total compreende um abrangente conjunto de atividades de manutenção que visam melhorar o desempenho, a confiabilidade e a disponibilidade dos equipamentos de uma fábrica. Nela, todos os funcionários estão envolvidos na cultura e nas atividades do TPM.

Segundo o Japan Institute of Plant Maintenance (JIPM) o TPM visa:

Criar uma cultura corporativa que persiga constantemente a melhoria da eficiência do sistema produtivo;
Construir um sistema para prevenir qualquer tipo de perda a fim de atingir o zero-acidente, zero-defeito e zero-falha em todo ciclo de vida de um sistema de produção;
Abranger todos os departamentos, incluindo produção, desenvolvimento, marketing e administração;
Exigir envolvimento completo, desde a direção até o chão de fábrica;
Atingir perda-zero através das atividades de pequenos grupos.

TPM representa uma forma de revolução, pois conclama a integração total do homem x máquina x empresa, onde o trabalho de manutenção dos meios de produção passa a constituir a preocupação e a ação de todos (Nakajima apud Fernandes 2005).

Troca Rápida de Ferramentas

Para evitar a perda de superprodução, um dos tipos de perda mais danosos previsto pelo Sistema Toyota de Produção, é necessário produzir com lotes cada vez menores. Uma conseqüência direta disso é o aumento do número de setups. Sendo assim, o próprio Shingo desenvolveu um conjunto de técnicas para redução do tempo de setup, mais conhecidas como Troca Rápida de Ferramentas ou, em inglês, SMED (Single Minute Exchange of Die). Com elas foi possível a diminuição dos tempos de setup, que duravam horas, para quase inacreditáveis menos de dez minutos.

Just-in-Time

O método de produção mais comum é conhecido como produção empurrada (push production). Ele consiste em fazer uma previsão de demanda, fabricar os produtos, estocá-los e, por fim, vendê-los. Nesses casos, os estoques geralmente são altos para amenizar os erros de previsão e conseguir satisfazer a demanda.

O Just-In-Time (JIT) é uma técnica de produção puxada (pull production) na qual todos os outputs são feitos no momento certo, na quantidade exata e no local correto. Nela, montam-se os produtos de uma forma muito rápida, começando a produzi-los momentos antes da data em que os mesmos devem ser entregues e concluindo-os apenas no dia exato. Ou seja, vende, produz e não armazena.

Figura 2 - Produção empurrada versus produção puxada.

A comparação de tais métodos pode ser vista na figura 2. O fluxo de informações ocorre da esquerda para a direita. Na parte puxada, a origem da produção está nas previsões de vendas feitas pelo fornecedor que produz para estoque e depois entrega a mercadoria. No modelo puxado, a origem da produção está na ordem de compra do cliente que desencadeia uma série de "requisições e entregas" até chegar ao fornecedor, no início da rede logística.

Segundo (Dahlén apud Ghinato 1999), o sucesso do JIT, no entanto, depende, entre outros fatores, de uma mão-de-obra altamente motivada e principalmente multifuncional. De fato, essa multifuncionalidade é apenas um dos pré-requisitos para se obter a elevada flexibilidade de volume, de mix de produtos e de prazos de entrega diferentes requeridos pelo sistema.

Fluxo Contínuo

De acordo com (Liker 2004), um dos fatos que mais impressionaram Eiji Toyoda, durante a visita à Ford Motor Company nos Estados Unidos, foi a grande quantidade de produto intermediário em estoque. Havia grandes máquinas processando lotes gigantescos inundando a fábrica com material em processamento para manter a taxa de utilização dos equipamentos perto dos cem por cento.

Entretanto, o presidente da Toyota percebeu aquilo como uma oportunidade que a sua empresa teria frente ao seu concorrente e criou o conceito de lote unitário. Em vez de utilizar grandes lotes que geram um aumento estrondoso da perda por espera, o lote passou a ter um tamanho mínimo. Com isso, cada peça é enviada à etapa posterior assim que termina de ser processada criando um fluxo contínuo de materiais.

De forma a demonstrar tal vantagem do fluxo contínuo, tome como exemplo um lote de 100 peças que é processado por três máquinas. Além disso, cada estação de trabalho demora 2 minutos para terminar cada peça. Para simplificar, desconsidere o tempo de transporte e o de setup.

Figura 3 - Representação do fluxo intermitente.

O tempo de processamento das 100 peças com um fluxo intermitente é de 200 minutos por máquina que, quando somado, resulta em 600 minutos. Essa representação pode ser vista na figura 3.

Já pela maneira japonesa, ilustrada na figura 4, o tempo total de atravessamento é reduzido significativamente, já que não há fila de espera entre os processos.

Figura 4 - Representação do fluxo contínuo.

O tempo pode ser calculado pela hora de término de trabalho do último processo que demora 4 minutos para receber a primeira peça mais 200 minutos para realizar 100 ciclos de trabalho.

Continuando com os cálculos anteriores, poucos produtos passam por apenas três etapas. Tome arbitrariamente a quantidade de 20 estações de trabalho e as mesmas condições anteriores. Agora, o tempo pelo estilo fordista é de 4000 minutos contra 238 minutos obtido pelo método mais eficiente. Uma diminuição de 94%.

Conforme o artigo publicado por (Miltenburg 2000), a utilização de um fluxo contínuo depende de dois fatores: a variedade de produtos e o volume de produção. O autor ainda sugere que o primeiro valor, referente ao mix de produtos, não deve ser maior que cinco unidades e a demanda não deve ser maior que mil itens por hora.

Takt-Time e Tempo de Ciclo

Takt-time é definido como o ritmo de produção necessário para atender a demanda. Pode ser obtido através da divisão entre o tempo disponível para a produção e o número de unidades a serem produzidas no intervalo correspondente. Ainda deverão ser subtraídos do tempo disponível para produção, todas as paradas programadas, como o tempo necessário para descanso do funcionário e manutenção preventiva, por exemplo.

A palavra alemã takt refere-se ao compasso de uma composição musical, tendo sido introduzida no Japão com o sentido de "ritmo de produção", quando técnicos japoneses estavam a aprender técnicas de fabricação com engenheiros alemães (Shook apud Alvarez 2001).

Por sua vez, o tempo de ciclo pode ser definido como o tempo necessário para a execução do trabalho em uma peça. Seu valor é o tempo transcorrido entre o início ou o término da produção de duas peças sucessivas de um mesmo modelo em condições normais de trabalho e abastecimento.

Observe que apenas o conceito de tempo de ciclo está relacionado com a capacidade de produção. Entretanto, se o tempo de ciclo mesmo for maior que o takt-time, ocorrerão atrasos nas entregas. Em situação inversa, os produtos serão entregues antes do momento necessário, ocasionando perda por produção antecipada. Logo, o ideal é que o tempo de ciclo e o takt-time estejam sempre bem próximos.

Em alguns casos, utiliza-se um quadro sinalizador de avisos, geralmente colorido ou luminoso, conhecido como andon. Associado a um temporizador, para sincronizar o tempo de ciclo de todos os processos, permite um controle visual mais eficaz ao alertar quando a produção está atrasada em relação ao takt-time. Este sistema é conhecido como Yo-I-Don.

Para (Alvarez 2001), a produção em intervalos regulares, num ritmo constante de produção, dá uma maior visibilidade ao fluxo dos materiais e aos problemas ocorridos. Complementando, pode-se afirmar que esta técnica aumenta a flexibilidade da produção diante de pequenas alterações nos pedidos de venda. Para tal, basta ajustar o tempo de ciclo ao novo takt-time modificado pela variação da demanda.

Heijunka

Também conhecido como nivelamento da produção, Heijunka é fazer a programação da produção através do seqüenciamento de pedidos em um padrão repetitivo de curta duração, mas que está relacionado à demanda no longo prazo.

A programação nivelada permite a produção constante de itens diferentes, de forma a garantir um fluxo contínuo, nivelando também a demanda dos recursos de produção.

Exemplificando, suponha que seja requerida a produção de 240 peças em um turno com duração de oito horas. Dentre as peças, 120 são do produto A, 60 do produto B e 60 do produto C. O takt-time já foi calculado e é exatamente igual a dois minutos.

Figura 5 – Comparação da produção em grandes lotes com a produção nivelada.

Utilizando a maneira fordista, a ordem da produção, reproduzida na figura 5, seria fabricar todas as unidades do produto A, fazer um setup e fabricar todas as unidades de B e por fim, fazer mais um setup e fabricar todas as unidades de C. Realizando assim, apenas três paradas nas máquinas para fazer os ajustes necessários para a fabricação de um produto diferente.

Não há dúvidas que a redução da quantidade de setups proporciona um ganho no tempo disponível das máquinas para produção. Todavia, devem-se ponderar também os desperdícios causados por essa abordagem como a produção antecipada e o aumento dos estoques intermediários. As perdas por falta de qualidade também tendem a ser mais graves, uma vez que existirão muito mais peças produzidas quando a não conformidade for detectada. Além desses problemas, ainda há uma perda pelo cansaço do trabalhador devido a movimentos repetitivos durante um longo período de tempo.

A não utilização do nivelamento aumenta a probabilidade da entrega de produto C atrasar caso ocorra qualquer imprevisto durante a produção. Se isso acontecer, todas as encomendas que contém o produto C também serão expedidas fora do prazo. Para piorar, se houver uma encomenda de vinte e quatro unidades de A solicitada de última hora, a mesma não poderá ser atendida, pois o lote do produto A já vai ter sido produzido e o custo com o setup das máquinas é alto demais para se fabricar as poucas unidades demandadas.

Por outro lado, utilizando a produção mista, são fabricadas duas unidades de A, uma de B e uma de C, repetindo a seqüência sessenta vezes numa linha de produção flexível sem ser necessária uma parada demorada para realizar o ajuste nas máquinas. Os operadores também se beneficiam ao fazer atividades menos repetitivas ao longo do dia.

Além disso, no caso de haver um aumento de 20% na demanda do produto A, o mesmo poderá ser incorporado na programação sem realizar grandes mudanças. Por exemplo, podem-se alterar as 24 últimas séries para três unidades de A, uma de B e uma de C.

Por fim, caso aconteça algum imprevisto e a produção atrasar, apenas algumas entregas serão feitas fora do prazo, já que todos os produtos estão sendo fabricados ao mesmo tempo.

De acordo com (Coimbra 2003), a Toyota dividiu o nivelamento em cinco partes diferentes:

Grau um: produção tradicional com grandes lotes. Cada produto é fabricado somente uma única vez por mês;
Grau dois: lotes menores. Nesse nível, já foi realizado algum esforço de redução das séries, conseguindo-se produzir um mesmo produto de duas a dez vezes por mês;
Grau três: lotes diários com volumes desiguais. É uma melhoria do grau anterior, passando a produzir os itens diariamente;
Grau quatro: lotes de tamanho constante, várias vezes ao dia;
Grau cinco: lote unitário, produção mista e sincronizada. É a melhor eficiência que se pode conseguir utilizando a técnica do nivelamento. Nela os itens são fabricados um a um em um sistema altamente flexível;

Pitch-Time

Nada mais é que o takt-time multiplicado pelo tamanho da embalagem. Lembre-se que na prática, nem sempre os produtos são embalados individualmente, sendo muito comum fazer pacotes com seis, dez, doze ou outra quantidade do mesmo produto. Então, para evitar a produção de quantidades que não sejam múltiplas da quantidade de embalagem e criar um estoque desnecessário, as ordens de produção são sempre referentes ao número de embalagens a serem produzidas. Por conseqüência, a colocação dos kanbans no Heijunka Box é feita tomando por base o pitch-time e não o takt-time.

Heijunka Box

Ou quadro de nivelamento é uma ferramenta de programação visual onde são colocados os kanbans de transporte. Tem forma semelhante a uma tabela. Suas linhas representam os tipos de produto e as colunas, o tempo.

O funcionamento do Heijunka Box se dá em duas etapas. Primeiramente, o responsável pela programação coloca os kanbans nos locais correspondentes de acordo com a teoria vista nos tópicos anteriores. Depois, um encarregado pela movimentação de materiais vai ao quadro em intervalos regulares e retira os kanbans de transporte, desencadeando uma série de atividades que serão vistas mais adiantes. Esse intervalo é denominado de Heijunka Pitch.

A seguir, na figura 6, encontra-se um exemplo de uma caixa de nivelamento com pitch de quarenta minutos. Um movimentador de materiais irá ao quadro logo no início do turno, às oito horas, e removerá os kanbans dos produtos A, B e C que se encontram na coluna apropriada. Cada kanban lhe dá autoridade de retirar uma embalagem do produto especificado do armazém de produtos acabados. Tais pacotes deverão ser entregues no setor de expedição logo em seguida. Mais tarde, às oito horas e quarenta minutos, o operário irá retirar apenas um kanban do produto A e realizar as mesmas atividades subseqüentes.

Figura 6 - Programação do heijunka box.

O fato de na segunda coluna haver apenas o kanban do produto A, ocorre devido ao mesmo ter um pitch-time de 40 minutos enquanto os produtos B e C têm o dobro e o quádruplo do valor, respectivamente. Dessa maneira, o próximo kanban do produto verde é fixado na coluna relativa às nove e vinte que é justamente o tempo associado ao último kanban da série acrescido de seu pitch-time. O mesmo é válido para o produto C.

No caso de não haver uma coluna com o tempo calculado, o kanban deverá ser colocado na coluna à esquerda mais próxima desse valor. Por exemplo, se o pitch-time do produto B fosse de sessenta minutos, os tempos obtidos seriam: oito, nove, dez... quinze horas. Assim, o segundo cartão deveria ser colocado na coluna relativa às nove horas, a qual não existe. Então o cartão é colocado na primeira coluna à esquerda mais próxima desse valor que é de oito horas e quarenta minutos. A terceira coluna ficaria em branco e a partir de então se repetiria o padrão. Por fim, se o pitch-time for menor que o intervalo de tempo do quadro de nivelamento, pode-se colocar mais de um cartão por coluna. Esse caso é mostrado abaixo através da figura 7.

Figura 7 - Programação do quadro de nivelamento com mais de um kanban por ranhura.

Kanban

Segundo (Gross and McInnis 2003), o kanban foi inventado na Toyota entre o final da década de 40 por Taiichi Ohno para minimizar os custos com o material em processamento e reduzir os estoques entre os processos.

O kanban é uma ferramenta de controle do fluxo de materiais no chão de fábrica. Ele é um sinal visual que informa ao operário o que, quanto e quando produzir. Sempre de trás para frente, puxando a produção. Não só isso, ele também evita que sejam feitos produtos não requisitados, eliminando perdas por estoque e por superprodução. Os sinais visuais podem variar, desde a sua forma mais clássica que é um cartão, até uma forma mais abstrata como o kanban eletrônico. O fundamental é que o kanban transmita a informação de forma simples e visual e que suas regras sejam sempre respeitadas.

De acordo com seu idealizador, (Ohno 1997), a funções do kanban são:

Fornecer informação sobre apanhar ou transportar;
Fornecer informação sobre a produção;
Impedir a superprodução e transporte excessivo;
Servir como uma ordem de fabricação afixada às mercadorias;
Impedir produtos defeituosos pela identificação do processo que os produz;
Revelar os problemas existentes e manter o controle dos estoques.

Como dito anteriormente, o kanban possui certas regras que devem respeitadas para seu eficaz funcionamento. De acordo com (Ohno 1997) e com (Colin), são elas:

O processo subseqüente deve retirar, no processo precedente, os produtos necessários nas quantidades certas e no tempo correto;
O processo precedente deve produzir seus produtos nas quantidades requisitadas pelo processo subseqüente;
Nenhum item pode ser produzido ou transportado sem um kanban;
Produtos com defeito não devem ser enviados ao processo seguinte;
O número de kanbans deve ser minimizado continuamente.

Assim, essa ferramenta, fundamental no sistema just-in-time, substitui a tradicional programação diária da produção assim como as atividades de controle e acompanhamento do status da produção. Os supervisores deixam de perder tempo fiscalizando os operários para realizar atividades que agregam valor, lidar com as exceções ocorridas e melhorar o processo continuamente (Gross and McInnis 2003).

Segundo (Corrêa apud Colin), um fator bastante citado para a eficácia da implementação dessa técnica é que a demanda seja estável até certo nível e que a flexibilidade de faixa da variedade de produtos oferecidos ao mercado deveria ser pequena.

Tipos de Kanban

Os kanbans são divididos basicamente em dois grupos:

Kanbans de Produção: são usados para determinar a fabricação de um item. Devem visivelmente conter em seus campos:

O processo que o produz
O nome do produto a ser fabricado para identificação por parte do funcionário.
O código do item a ser feito para evitar ambigüidades.
A quantidade de itens que são colocados em um único container.
O processo subseqüente para o qual o produto deve ser levado. Entretanto, caso haja um estoque intermediário, pode-se colocar o endereço de armazenamento.

Essas informações são as mínimas necessárias para que se produzam os produtos certos, nos locais corretos e na quantidade requerida. Contudo, nada impede que o kanban tenha mais campos indicando, por exemplo, em qual produto final a peça é usada. Pode-se também colocar um código de barras para informar ao sistema integrado de gestão quantas peças daquele tipo já foram produzidas. Ou ainda, existir um campo que informe o tipo de caixa a ser usado para empacotar os produtos. Enfim, há várias possibilidades de se fazer um kanban de produção, o que vai variar de fábrica para fábrica.

Kanbans de Transporte: também conhecidos como kanbans de movimentação, ou kanbans de requisição, são utilizados na movimentação de material entre células de produção distantes entre si, entre local de produção e armazém ou qualquer outro caminho pelo qual o produto deverá ser transportado somente por uma pessoa designada para esse fim. Dessa maneira, os operários mais especializados dedicam mais tempo em atividades de produção e montagem que agregam valor ao produto.

De modo análogo ao modelo anterior, o kanban de requisição deve ter a informação necessária para que o produto requerido seja entregue no local certo e na quantidade certa. Geralmente, tais campos são:

O local de onde o produto deve ser retirado. Pode ser um processo precedente ou um armazém.
A descrição do produto a ser retirado para identificação por parte do funcionário.
O código do item a ser feito para evitar ambigüidades.
A quantidade de itens que são colocados em um único container.
O processo subseqüente ou armazém para o qual o produto deve ser levado.

Um exemplo para cada um dos dois modelos referidos acima pode ser visto logo a seguir, na figura 8. Observe o destaque de letras maiores para facilitar a leitura de alguns campos como a quantidade por caixa e o endereço no supermercado.

Figura 8 - Exemplo de um kanban de produção e de transporte.

Geralmente, nesses kanbans, existe um campo que identifica o tipo caixa de armazenamento. Por exemplo, uma caixa de madeira grande, uma caixa plástica de 20 x 15 x 30 cm, entre outros. Já um telefone para contato caso o cartão seja perdido no meio do caminho também pode ser útil em despachos entre diferentes fábricas. Adicionalmente, um campo que numera o cartão e indica quantos kanbans daquele tipo existem para ajudar na recontagem dos mesmos.

Funcionamento do Kanban

Empresas diferentes possuem necessidades diferentes e produzem de modo diferente, produtos diferentes. Então, é de se esperar que os kanbans estejam adaptados às realidades locais de onde estão sendo usados e variem a sua forma, cor e método de uso.

Não só o gestor, mas todos os funcionários podem sugerir como os cartões devem ser implementados, qual o melhor material para confeccioná-los, quais campos que precisam existir, etc. A única restrição é o cumprimento de todas as regras estabelecidas por (Ohno 1997).

Passo um: à medida que vai consumindo os produtos, o operário do processo seguinte, retira os kanbans de movimentação fixados na embalagem do produto e os coloca no quadro, gerando um aviso para o transportador de materiais.

Ilustrado na figura 9, ao visualizar tal sinal, o transportador retira os kanbans de transporte do quadro, verifica qual produto está sendo requerido e vai para o local especificado de onde deve retirá-lo.

Figura 9 - Funcionamento do kanban, passo um. "O processo subseqüente deve retirar, no processo precedente, os produtos necessários nas quantidades certas e no tempo correto".

Figura 10 - Funcionamento do kanban, passo dois. "Nenhum item pode ser produzido ou transportado sem um kanban".

Passo dois: no processo precedente ou no armazém indicado, o transportador retira um e somente um container do produto discriminado para cada kanban que possui. Esse container possui um kanban de produção, o qual é fixado no quadro formador de lote logo em seguida. Essa etapa pode ser visualizada na figura 10.

Observe que o produto em movimentação está sempre com um cartão. Quer seja o de produção, durante seu período de armazenagem, quer seja o de requisição, a partir do momento em que foi retirado até a sua consumação.

Passo três: com a colocação de mais dois kanbans de produção no quadro, o lote de quatro unidades é completado e o processo precedente começa a produzir os itens solicitados tal como ilustrado na figura 11. Caso esteja fabricando outro produto, o mesmo é colocado numa fila para aguardar o processamento. Enquanto isso, o operador do processo seguinte continua realizando suas atividades.

Figura 11 - Funcionamento do kanban, passo três. "O processo precedente deve produzir seus produtos nas quantidades requisitadas pelo processo subseqüente."

Passo quatro: nesta etapa, explicada na figura 12, o operário do processo precedente repõe o estoque intermediário com os itens que manufaturou, colocando dentro de cada container, seus respectivos kanbans de produção. O ciclo é terminado com o transportador de materiais entregando as peças solicitadas no processo de onde retirou os kanbans de transporte.

Figura 12 - Funcionamento do kanban, passo quatro. Término do ciclo.

Observe que os estoques intermediários são proporcionais ao número de kanbans. Quanto mais cartões, mais estoques e mais custos. Por esse motivo, existe a última regra que determina a redução do número de cartões em circulação. Uma prática comum nesses sistemas é retirar um kanban de circulação uma vez por semana ou por mês, o que reduz os estoques gradativamente até seu nível ótimo. A seguir, é mostrada uma maneira para se calcular o número ideal de kanbans que um processo deve ter.

Cálculo do Número de Kanbans

Quanto maior for o número de kanbans, maior será o estoque em processo. Por outro lado, uma quantidade abaixo do ideal causa rupturas constantes no fornecimento de ao processo subseqüente a qual ocasionará rupturas em cadeia e o sistema pode entrar em colapso. Uma fórmula bastante simplificada para o cálculo da quantidade ideal de cartões em um processo é dada pela fórmula abaixo:

K: quantidade de kanbans,

D: demanda por minuto do produto relacionado,

L: lead-time em minutos,

α: fator de segurança,

C: capacidade do container.

Esta equação dimensiona o número de kanbans estaticamente, sem levar em conta que o lead time é dependente do número de kanbans e da capacidade do container. Nem considera que um grande número de fatores influenciam o patamar ótimo de operação do sistema kanban, como por exemplo a variabilidade dos tempos de processamento e demanda, tempo de setup, a freqüência de quebras de maquinário, existência de problemas de qualidade com os produtos, etc. (Danni).

Dois comentários importantes acerca desta fórmula foram feitos por (Kumar and Panneerselvam 2005). O primeiro deles é que o valor do lead-time deve englobar tempos de espera, processamento, transporte e tempo de coleta do próprio kanban. O outro comentário é que, na prática, observa-se que o valor de C está limitado ao máximo de 10% da demanda, assim como o valor de alfa.

Principais Desvantagens dos Kanbans

Nem todas as peças podem ser usadas com kanbans: alguns componentes possuem valor agregado muito alto e requerem um tratamento especial. Por exemplo, as bobinas de fio de ouro utilizadas nas ligações elétricas de produtos informáticos. Outros componentes, por sua vez, são frágeis demais e requerem um cuidado especial em seu manuseio. Caso semelhante ocorre com produtos químicos de elevada insalubridade.

Alguns produtos que não se encaixam nas categorias acima também apresentam entraves ao serem manuseados com kanbans. Entre eles, podemos destacar as peças de baixo valor agregado, mas de grandes dimensões as quais ocupam muito espaço na linha de montagem. Essas, geralmente são levadas à linha de produção apenas no momento exato em que vão ser instaladas.

A natureza material do kanban: os cartões se desgastam com o uso, seus nomes ficam ilegíveis e ainda podem ser rasgados ou molhados acidentalmente. Os kanbans também podem ser perdidos ou enviados ao lixo juntamente com as embalagens por descuido do trabalhador. Além disso, materiais novos podem ser adicionados ao armazém, ou algum produto pode ter o seu código alterado o que demanda a confecção de novos cartões. Essa tarefa que parece simples se torna mais complexa na proporção em que se eleva o número de kanbans utilizados na fábrica.

Mudança na lista de materiais: segundo (Hobbs 2004), o maior trabalho se dá quando a lista de materiais de um produto é alterada. Enquanto que nos sistemas computadorizados, a atualização é feita automaticamente, o sistema kanban requer um recálculo do número de cartões a serem utilizados assim como um redimensionamento dos containeres.

Diferentes Formas de Transmitir a Informação

A essência do kanban está na transmissão da informação de forma simples e visual para manter em funcionamento um sistema de produção puxado. Depois de satisfeito esse requisito, um sistema kanban pode adquirir várias formas diferentes as quais vão depender das características das operações do local será implementado.

Kanban eletrônico: o sinal é transmitido através do sistema de informações da empresa. Ideal para transmissão entre fábricas diferentes. Por exemplo, entre a unidade montadora e um fornecedor de kits de montagem.

Cartão: é o modelo mais usado e explicado acima o qual é dividido em dois tipos: de produção e transporte.

Marcação no chão: neste tipo, existem espaços reservados à armazenagem do produto logo na saída da estação de trabalho. Quando o produto é retirado, o operador tem permissão para produzir. Assim que todos os espaços forem preenchidos, deve-se parar a produção (Chase, Jacobs et al. 2006).

Kanbans fixos nos contentores: também conhecido como sistema de duas caixas,
nesse modelo, são colocados pelo menos dois contentores para cada material necessário no bordo de linha, tendo fixado, em cada um deles, um kanban do tipo cartão. O container é recolhido quando fica vazio e devolvido ao bordo de linha preenchido com o mesmo material na quantidade indicada na etiqueta (Gross and McInnis 2003).

Indicação luminosa: o trabalhador aperta um botão no seu posto cada vez que consome o produto. O sinal então é transmitido por um fio elétrico até a célula de produção daquele item, onde será acesa uma luz para cada unidade a ser produzida. O operário da estação fornecedora, por sua vez, aperta um botão para cada unidade que produz, fazendo com que as luzes vão se apagando.

Sistema computadorizado: a informação é transmitida através do sistema de informações da empresa. O mesmo pode ser impresso e utilizado como um kanban descartável na linha de produção, ou então, o sinal pode ser lido diretamente da tela do computador caso haja um próximo ao posto de trabalho.

Modelo gravitacional: segundo (Chase, Jacobs et al. 2006) este modelo fui utilizado primeiramente na fábrica de motores Kawasaki. Lá, assim que o estoque de um item utilizado na submontagem chega ao final, o operário coloca uma bola colorida em um cano, a qual rola por gravidade até a central de reabastecimento. De acordo com a cor da bola e em qual cano a mesma chegou, o operador do armazém sabe qual material deve ser entregue em um determinado posto de trabalho. Muitas variações dessa técnica foram criadas posteriormente.

A figura 13, apresentada a seguir, ilustrada cada um dos modelos citados acima.

Figura 13 - Diferentes formas do kanban.

Célula de Produção

O arranjo físico em células se baseia no princípio da tecnologia de grupo. Esse princípio busca melhorar a eficiência na produção de itens muito variados, agrupando-os de acordo com um critério escolhido, o qual pode ser por semelhança na forma, por utilização de componentes em comum, por processamento no mesmo conjunto de máquinas ou por outro critério à escolha (Miyake 2006).

Dessa maneira, o layout é definido para um determinado conjunto em vez de ser baseado num único produto, ganhando-se flexibilidade e espaço. (Zagonel 2006) cita mais algumas vantagens do arranjo celular face ao arranjo funcional. Entre elas podemos destacar:

Redução de produtos com defeitos;
Maior produtividade;
Menor manuseio das peças/produtos e menos movimentação do operário;
Menor tempo de setup;
Menor estoque em processo;
Menores filas de espera.

Entretanto, (Huq, Hensler et al. 2001), através de um estudo, provou que para se obter as vantagens do layout celular, é necessário que sejam reduzidos os lotes de processamento e os tempos de setup em cerca de 70%. Caso contrário, os benefícios desejados podem não ser conseguidos.

Na média, as células de produção são formadas por 10 máquinas e têm, geralmente, entre três e quatro operadores. Esses são os resultados de uma pesquisa de (Miltenburg apud Zagonel 2006) realizado em 114 células no Japão e nos Estados Unidos. Os resultados desse estudo mostraram que o trabalho em células apresentou 75% de aumento na produtividade, 86% menos WIP, 75% menos tempo de lead time e 83% menos defeitos.

Figura 14 - Redução do desperdício de transporte utilizando células de produção em "U".

As células de manufatura podem assumir vários formatos. Entretanto, as do tipo "U", representadas pela figura 14, são as mais utilizadas. Nela, as máquinas estão mais próximas umas das outras para reduzir os deslocamentos dos operadores ao utilizarem várias em simultâneo. Além disso, como a entrada e a saída estão sempre próximas, o abastecimento da célula e a retirada de seus produtos podem ser feitas sem haver desvio no percurso do abastecedor.

O fluxo interno de materiais segue o sentido horário ou anti-horário, passando de um posto de trabalho para o seguinte, sempre respeitando a ordem de fabricação. Contudo, a movimentação do operário não precisa se realizar da mesma maneira.

Por exemplo, na situação à esquerda da figura 15, a célula de produção foi dividida em três subáreas, cada uma com três máquinas e um único operário. Observe que a divisão não foi regida pelo fluxo de materiais, representado pela linha contínua, mas sim pela necessidade de reduzir o deslocamento do artífice. Se a distribuição dos postos fosse feita na forma seqüencial, a pessoa ia ter que voltar da terceira estação para a primeira, passando por dois postos de trabalho sem agregar nenhum valor à mercadoria.

Figura 15 - Diferentes movimentações dentro de uma célula em "U".

Caso a demanda seja menor, um único operador pode realizar todas as tarefas da célula. Há também a opção de colocar dois ou mais trabalhadores em série utilizando também todos os postos. Observe que a movimentação interna da célula é dinâmica e terá alterações conforme a demanda varie. Segundo (Ghinato 1998), a quantidade de máquinas comandadas por cada operário está limitada apenas pelo takt-time e as habilidades do mesmo em realizar as diferentes rotinas.

A programação de cada célula é feita através de um seqüenciador conhecido como kanban chute. Quando a produção de um item é requisitada, colocam-se seus kanbans de produção numa fila de espera do tipo primeiro a entrar, primeiro a sair. Dessa forma, o próximo produto a ser fabricado é aquele que estava no kanban chute há mais tempo.

Polivalência do Trabalhador

Conforme (Tubino apud Zagonel 2006) a polivalência ou multifuncionalidade dos operadores se dá quando todos têm capacidade para executar as diferentes rotinas de trabalho da célula, não sendo necessário fixá-los num ou noutro posto de trabalho específico. Isso é obtido através de treinamento intensivo e rodízio de tarefas dentro da célula. A polivalência facilita a produção nivelada e flexibiliza o ritmo de produção nas células de fabrico. Sem ela, torna-se muito difícil garantir o funcionamento completo do sistema just-in-time.

Quando nem todos os operadores são aptos a realizar todas as tarefas e seja necessário modificar o tempo de ciclo para mantê-lo próximo ao takt-time, pode-se recorrer aos operários mais experientes e habilidosos, para realizar todas as tarefas da linha. Entretanto, esse recurso não elimina a necessidade de se ter um programa estruturado de treinamento e qualificação da mão-de-obra, de modo que os operários se tornem gradualmente aptos a realizar diferentes operações. Esse requisito se torna mais evidente no setor de montagem, onde a automatização das operações tende a ser bastante dispendiosa.

Supermercados

Esse elemento integrante do Sistema Toyota de Produção é um pequeno armazém responsável pelo abastecimento do sistema puxado que pode conter produtos intermediários e acabados, além de armazenar peças de fornecedores externos. Pode ser definido como sendo a interface entre os processos internos entre si e entre a fábrica e os fornecedores externos.

A implementação de um supermercado não é obrigatória, ela é feita, tipicamente quando, em meio a um fluxo contínuo, um dos processos fabrica em lotes ou quando dois ou mais consumidores utilizam o mesmo material (Lean Enterprise Institute 2005).

O supermercado funciona de modo análogo àqueles no qual se compra os alimentos como Pão de Açúcar®, Wal Mart® e Carrefour®. Na verdade, foi observando um deles que Taiichi Ohno, durante sua visita aos Estados Unidos, começou a criar o conceito de produção puxada (Liker 2004). Nesse tipo de loja, existem inúmeros itens expostos nas gôndolas que vão sendo retirados diretamente pelos clientes e colocados em seus carrinhos de compra. Enquanto isso, um funcionário do supermercado é responsável por repor os itens consumidos para que estejam sempre disponíveis.

No sistema just-in-time, o abastecedor da linha de produção vai ao supermercado, retira os itens indicados nos kanbans de transporte e os coloca no carrinho de transporte. Depois disso, deixa os kanbans de produção, que estavam juntos com o material em estoque, e segue para reabastecer as células. A partir de então, outro operário coleta os kanbans de produção e reabastece as prateleiras com as mercadorias obtida de fornecedores externos ou itens produzidos internamente.

Figura 16 - Acesso às prateleiras de um supermercado por dois tipos de corredores.

Um supermercado é formado por vários corredores delimitados pelas estantes de armazenagem. Cada uma delas possui prateleiras que são divididas em pequenos espaços os quais preenchidos com um único tipo de produto. Essa técnica, conhecida como endereçamento do armazém, permite que um produto seja achado rapidamente através de seu endereço. Em uma analogia simples, pode-se dizer que o endereço é um par de coordenadas x e y, já o armazém seria equivalente ao plano cartesiano.

Ao se fazer um layout do supermercado, deve-se estar atento à divisão dos corredores em dois tipos: de abastecimento e de retirada. Ambos estão representados na figura 16.

O corredor de abastecimento é utilizado pelo movimentador de materiais para repor os itens retirados com os materiais obtidos dos fornecedores internos ou externos. As estantes desses corredores possuem roletes com uma leve inclinação de modo que os produtos possam ser retirados em FIFO pelo outro lado.

Dessa forma, o mizusumashi pode fazer o picking dos itens indicados em cada kanban ao mesmo tempo em que o supermercado é reabastecido por trás.

Além dessa vantagem em termos de movimento, a utilização de corredores específicos permite uma melhor gestão visual do armazém, uma vez que a informação apresentada nos endereços está de acordo com a função a ser executada. Por exemplo, a atualização do estoque no sistema informatizado é feita quando o abastecedor do armazém pistola o código de barras ao repor um produto. Já para o outro operário, é mais importante que o endereço escrito na etiqueta esteja com uma fonte maior para que ocorra uma identificação mais rápida. Esse ganho de segundos se torna perceptível no final do dia, após a movimentação de milhares de contentores. As informações do kanban (visão comum) e das diferentes etiquetas colocadas em cada lado das estantes podem ser visualizadas na figura 17.

Figura 17 - As etiquetas utilizadas no supermercado têm sempre um kanban associado.

Por fim, cada supermercado está relacionado a um processo ou uma linha de produção que fabrica apenas o necessário para repor o que foi retirado. Segundo (Smalley 2006), a desvantagem desse sistema é que um processo precisa manter um estoque com todas as peças que produz, o que pode não ser prático caso a variedade de peças seja muito grande.

Abastecedor das Células de Produção

Existem duas maneiras de se abastecer as células de produção. A primeira delas é utilizando uma logística tradicional na qual um empilhador abastece o material mediante requisições feitas pela linha. A outra maneira é utilizando um mizusumashi.

Entre as tarefas delegadas a esses operários estão a transmissão da informação e o abastecimento da linha de produção. A primeira atividade pode ser interpretada como fazer o manejo dos dois tipos de kanbans, seja colocando-os nos pontos de recolha especificados, retirando-os do quadro de nivelamento, transportando-os do processo subseqüente para o processo fornecedor, entre outras. Já o abastecimento do bordo de linha implica em retirar os contentores vazios, alimentar as células com os produtos necessários e transportar os produtos manufaturados para o supermercado ou para o setor de expedição.

O abastecedor é um dos funcionários mais importantes do Sistema Toyota de Produção. O seu objetivo é retirar o máximo de desperdício dos operários de montagem ao fazer todo o manuseio e transporte de material entre os supermercados e o bordo de linha.

Os trabalhadores das células de produção, por sua vez, ficam responsáveis por agregar valor ao produto. Inclusive, utilizam camisas de cores diferentes e são proibidos de sair do local de montagem para ir buscar material no armazém ou no supermercado.

Método de Abastecimento 1 - Fazer a Próxima Atividade de Acordo com uma Lista de Prioridades: essa é a forma simples e mais antiga na qual o abastecedor, geralmente utilizando uma empilhadora ou um porta-palete, verifica qual a próxima tarefa pendente a ser feita e a executa. Caso haja duas ou mais tarefas, deve-se fazer primeiro aquela que requer mais urgência.

Uma lista de prioridades poderia ser:

Retirar os kanbans do heijunka
box e realizar a entrega dos produtos.
Separar os materiais dos kanbans de produção com lote completo.
Abastecer as células de produção.
Mover a caixas produzidas nas células para o supermercado.
Demais atividades.

Apesar de parecer simples, esse método causa um pouco de confusão para o motorista do trem logístico, pois o mesmo tem sempre de memorizar qual atividade é mais importante e pode, igualmente aos outros humanos, se confundir. Além disso, nunca se sabe se o empilhador está em atraso ou não, uma vez que não há uma seqüência das operações. Entretanto, o mais grave de tudo é que a quantidade de deslocamentos sem carga, um desperdício, é bastante elevada.

Observe ainda que a lista de prioridades está baseada na função a ser exercida e não no espaço físico onde são realizadas, ficando claro o desinteresse em relação a otimização do deslocamento do abastecedor.

Método de Abastecimento 2 – Fazer o Abastecimento Seguindo um Circuito Fixo: é nessa metodologia que surge o personagem mizusumashi (a sua tradução para o inglês, water-spider, é geralmente mais utilizada). Ele se desloca exatamente através do circuito pré-definido, passando por vários checkpoints nos quais verifica se existe alguma tarefa para se fazer e a executa. De acordo com (Coimbra 2003), esse deslocamento pela rota fixa é iniciado em intervalos padronizados, geralmente entre vinte e sessenta minutos.

Utilizando-se de um veículo guiado manualmente, o mizusumashi confere ao sistema uma importante flexibilidade para mudar a rota de distribuição ou o arranjo físico da fábrica. Esse é um dos principais ganhos em relação ao sistema automatizado cujo tempo necessário e custo para se reformular o layout inviabilizam a mudança (Namoura and Takakuwa 2006).

O rebocador elétrico recebe o nome trem logístico porque nele são encarrilhados vários pequenos vagões para transportar os produtos. Apesar de longo, o mesmo é capaz de fazer curvas bastante fechadas, pois todos os vagões passam exatamente pelo mesmo local que passou o rebocador. Algo parecido com aquela serpente dos jogos de celulares.

Outra característica desse equipamento é a possibilidade do motorista dirigir em pé, reduzindo o tempo gasto nas paradas e partidas do mesmo.

Para uma adequada sincronização da produção, o tempo decorrido entre o começo de dois ciclos consecutivos deve ser igual ao pitch-time. Como o mesmo é regido pela demanda, o gestor pode alterar o tamanho do circuito a ser feito ou utilizar mais de um mizusumashi para que esse ajuste seja possível.

No caso do percurso ser muito extenso, pode-se dividi-lo em outros dois menores. Isso mantém o intervalo de passagem nos checkpoints e reduz o número de vagões necessários para acomodar todos os produtos a serem entregues ou recolhidos no ciclo.

Pode-se dizer que essa abordagem deriva de uma técnica utilizada na logística, conhecida como milk run, na qual um único caminhão da empresa faz uma rota passando pela porta de determinados fornecedores para recolher os suprimentos da linha de produção. Dessa maneira, é possível que os fornecedores façam entregas mais freqüentes utilizando a capacidade do veículo de maneira satisfatória. Não obstante, ainda se consegue uma redução nos custos de transporte e de armazenagem.

Abaixo, nas figuras 18 e 19, encontram-se as duas representações do circuito do mizusumashi e sua posterior divisão em dois circuitos menores. O fluxograma de operação se encontra em anexo. Em ambos os métodos, a quantidade de material disponível no bordo de linha deve ser suficiente para alimentar a produção enquanto o water-spider não devolve os contentores retirados em sua última passagem. Segundo (Namoura and Takakuwa 2006), a quantidade de peças em cada contentor é definida no contrato de compra entre a montadora e seus fornecedores, logo, a única variável de decisão é o número de caixas a serem usadas. Não só isso, mas também apresentam uma solução para minimizar o material em estoque satisfazendo tal restrição.

Figura 18 - Circuito fixo realizado pelo mizusumashi.

Figura 19 - Divisão do percurso do mizusumashi para sincronizar com o pitch-time.

Sobre o simulador desenvolvido:

Após uma apresentação genérica da teoria do sistema Toyota de produção juntamente com as duas metodologias para se fazer o abastecimento das células de manufatura, este capítulo explica o funcionamento do simulador. Serão descritos os principais eventos da simulação, o significado de cada uma das variáveis e o ambiente de produção idealizado.

Arquitetura do Simulador

Figura 20 - Além de ser compatível com Windows XP™, Mac OS X™ e Linux,
o simulador funciona também em Windows Vista™.

Logo no começo do desenvolvimento do projeto estabeleceram-se alguns requisitos acerca de sua concepção. Em primeiro lugar, o programa deveria ser escrito em uma linguagem de grande portabilidade, ou seja, acessado de qualquer lugar e com qualquer sistema operacional. Em vista disso, utilizou-se a linguagem JAVA™ juntamente com a função JAVA WEB START™ o que possibilita o acesso ao simulador através de qualquer navegador de internet seja utilizando o Windows XP™, Windows Vista™ Mac OS X™, ou até mesmo o Linux. Basta acessar um dos dois endereço da internet: http://www.luizfreire.com/simulator/ . Alguns segundos após um clicar no botão launch application, obterá a tela inicial do programa apresentada via figura 20. A única limitação do sistema é uma resolução gráfica mínima de 1024x768 pixels a qual só não é obtida em placas gráficas e monitores muito antigos.

Apesar do paradigma de que os programas desenvolvidos em JAVA™ fossem mais lentos que os feitos em C++™, a mesma foi suficiente para alcançar muito mais que os trinta quadros por segundos requeridos para a simulação visual.

Sem entrar nos pormenores técnicos, o Pull Simulator baseou-se na metodologia da simulação por eventos discretos. Isso quer dizer que se gera um evento inicial que desencadeia vários outros eventos que são ordenados numa lista pelo critério de tempo mais cedo de acontecimento.

Outra rotina, responsável pela execução e avanço do tempo do simulador, remove os eventos dessa lista um a um. Caso o tempo definido no evento seja maior que o tempo atual da simulação, o tempo da simulação avança para o tempo do evento de forma discreta, sem interessar os tempos entre os eventos, onde nenhuma alteração no sistema é realizada.

Simultaneamente a essas duas rotinas, ocorre o desenho na tela de todas as entidades do sistema usando uma interpolação linear de dois pares de coordenadas escolhidos por uma função.

Outra característica chave do simulador é o fato de se poder fazer alterações nos parâmetros utilizados, assim como adicionar e remover produtos através de janelas, sem precisar alterar uma única linha do código fonte.

Por fim, as variáveis da simulação podem ser exportadas para um arquivo e importadas posteriormente de modo que o experimento possa ser repetido várias vezes e por diferentes pessoas, bastando apenas enviar-lhes o arquivo com a extensão *.sim exportado.

Vantagens e Limitações da Simulação Visual Interativa

A escolha por uma simulação visual interativa (SVI), cuja vista principal está apresentada na figura 21, adiciona algumas vantagens ao software desenvolvido. São elas:

Facilidade de detectar erros nas rotinas e eventos do programa;
Reforça a componente didática do simulador;
Melhor compreensão do sistema real;
O conhecimento obtido no desenvolvimento do modelo freqüentemente sugere mudanças no próprio sistema que está a ser simulado;
Permite identificar os gargalos e a entender por que eles acontecem;
Grande flexibilidade para analisar mudanças no sistema, mesmo as de caráter estrutural.
O utilizador pode assistir à evolução do modelo ao longo do tempo
Novas políticas, procedimentos operacionais, regras de decisão, estruturas organizacionais, fluxos de informação, etc., podem ser explorados sem provocar distúrbios nos processos em uso;
O fator tempo pode ser controlado, isto é, pode ser expandido ou comprimido, permitindo aumentar ou diminuir a velocidade a fim de se estudar um fenômeno;

Os aspectos negativos são a maior demora e maior complexidade para escrever o código fonte e desenhar as imagens.

Figura 21 - Tela principal da simulação. Clareza na identificação das
entidades e animação detalhada.

Características Funcionais do Simulador

O Pull Simulator pode ser usado por diferentes pessoas sob várias perspectivas. A primeira delas é o entendimento teórico do funcionamento do Mizusumashi em relação ao método tradicional de abastecimento das células de produção. A possibilidade de visualizar todos os movimentos na tela, congelá-los e escolher a velocidade de simulação ajuda bastante na construção do conhecimento teórico por parte do aluno. O professor, ao utilizar o simulador em sala de aula, além de motivar os alunos ao fornecer uma ferramenta didática, torna os conceitos apresentados na revisão bibliográfica muito mais claros.

Para aqueles que já detêm o conhecimento teórico da produção enxuta, o simulador é uma oportunidade de estudar a alteração no comportamento do sistema ao mudar uma variável. Por exemplo, pode-se alterar o tempo de ciclo do Mizusumashi e observar os seus efeitos. Ou ainda, pode-se reduzir o tempo de operação de cada atividade para saber em qual delas existe um ganho real.

Na abordagem da investigação científica o pesquisador tem uma ferramenta de confronto de métodos distintos de abastecimento do bordo de linha para uma situação. Nesse aspecto o Pull Simulator permite medir o percentual de viagens do abastecedor com cargas e em vazio, mostra o total da distância percorrida em cada um dos casos e exibe o número de caixas e kanbans movimentados.

No ambiente produtivo real, o Pull Simulator pode ser usado para saber se um determinado plano de produção pode ser atingido ou quantas mudanças de séries uma linha de produção pode fazer. Ainda mais, baseando-se no método de tentativa e erro, o usuário pode calcular o número mínimo de kanbans para que não haja ruptura no estoque, assim como estimar o tamanho do lote ideal.

Ao final da simulação ainda são mostrados vários tipos de relatório que incluem:

Atrasos nas entregas dos pedidos;
Número de setups realizados por produto;
Distância percorrida com carga e em vazio e total de material movimentado;
Estoque inicial, produção no período e estoque final;
Quantidade encomendada versus quantidade produzida;
Gráfico de distribuição do tempo do mizusumashi na execução das diversas atividades;
Gráfico de utilização da capacidade produtiva;
Gráfico da evolução do estoque de produtos acabados ao longo do tempo;
Gráfico da carga de produção ao longo do tempo para cada uma das células.
Gráfico com o custo de manutenção do estoque.

Simplificações e Considerações na Construção do Simulador

Tendo em vista que é impossível simular um ambiente real com toda a sua complexidade, o objetivo deste tópico é de listar as simplificações feitas em relação a um sistema produtivo real para que fosse viável a sua simulação.

Em relação ao supermercado de matérias-primas considerou-se que os mesmos eram automaticamente reabastecidos com um nível de serviço de 100%. Ou seja, foram desconsideradas as seguintes situações:

A quebra dos contentores;
As perdas de peças dos contentores que podem cair no chão durante a movimentação dos mesmos;
O encravamento das caixas nas estantes dinâmicas do supermercado;
A perda de contentores e de kanbans;
O absenteísmo dos encarregados pelo reabastecimento do supermercado (repacking);
A falta de material no repacking;
Possibilidade de enchimento do retorno de caixas vazias.

Acerca do mizusumashi, foram ignoradas as seguintes situações:

Variação da velocidade nas partidas e paradas;
Influência da carga de cada um dos vagões na velocidade final;
Aparecimento de algum obstáculo no meio do percurso que causasse algum atraso como um contentor em local inadequado, trânsito de empilhadeiras e outros mizusumashi, atravessamento de pedestres, entre outros;
Realização de alguma atividade não prevista;
Cansaço ao longo da jornada de trabalho;
Troca de veículo por falta de combustível ou bateria ou outra avaria;
Colisão com qualquer outro objeto;
Restrição da capacidade de carga;
Descarrilamento de algum dos vagões.

Como as células de manufatura eram apenas uma parte necessária para completar o fluxo de materiais, tais entidades foram programadas para funcionar apenas com as mínimas informações necessárias que são:

Tempo de preparação da linha para produzir um produto diferente;
Tempo de ciclo para cada referência produzida;
Associação do produto acabado com uma única célula que o produz;
Disponibilidade de matéria-prima para começar a produção.

Complementando a simulação, temos as seguintes simplificações: as áreas de estoque são ilimitadas, o setor de expedição está sempre disponível, os pedidos de venda são feitos com antecedência e nunca são retirados depois de aceites.

Apesar de parecerem bastante numerosas, as imposições feitas na programação do simulador não prejudicam de forma significativa o seu desempenho. Tais ocorrências relacionadas nas listagens acima são pouco freqüentes ou só ocorrem em processos não estabilizados. Em relação a esse último ponto deverão ser feitas melhorias e normalizações antes de se afinar o sistema utilizando a simulação. Já para o caso dos evento de menor freqüência foi acrescentado um campo de desvio padrão para cada atividade de forma a mitigar tais efeitos no resultado final.

De forma que fique transparente o efeito de tais considerações feitas no simulador, abaixo segue uma tabela com impacto causado numas das principais variáveis de análise no Sistema Toyota de Produção, as perdas.

Tabela 1 - Impacto das simplificações do simulador na análise das sete perdas do STP.

Impacto das Simplificações do Simulador na Análise das Sete Perdas do STP
Perdas Consideradas:	Perdas que Poderão ser Implementadas:	Perdas Não Consideradas:
Perda por superprodução (por quantidade e por antecipação);	Perda por fabricação de produtos defeituosos.	Perda por movimentação;
Perda por transporte;	Perda no próprio processamento;
Perda por estoque;	Perda por espera;

Configuração e Principais Variáveis do Simulador

Logo que se inicia o Pull Simulator, aparecem duas abas de configuração dos parâmetros. A localizada mais à esquerda, que pode ser observada na figura 22, é referente à inclusão de até 10 produtos a serem fabricados. A outra aba contém as variáveis referentes ao método da simulação, definição das distâncias e tempos de realização de cada atividade.

A compreensão de cada variável do sistema é bastante importante antes de se fazer qualquer simulação, pois de nada adianta analisar os resultados de uma situação mal parametrizada.

Começando pelo menu dos produtos temos os seguintes campos:

Product Name: meramente informativo para diferenciar o produto dos demais. Com isso, o produto poderá ser referenciado pelo seu nome, uma letra de A a J ou pela cor (vermelho, verde claro, verde escuro, azul, amarelo, laranja, marrom, cinza, violeta ou roxo). As cores são bastante importantes para a identificação visual de cada produto durante a animação;

Pack out Quantity: é quantidade de produtos que podem ser produzidos com cada contentor que o mizusumashi leva para a célula de produção. Ou seja, se um relógio é digital é montado com um visor, duas pulseira e quatro botões iguais e o valor do pack out quantity for igual a vinte, cada contentor levado ao bordo de linha pelo abastecedor contém vinte visores, quarenta pulseiras e oitenta botões. Além disso, embora não seja representado na tela devido ao detalhamento gráfico exigido, o mizusumashi já deixa cada material no local apropriado para o consumo de modo que o operário da linha não perca tempo procurando peças ou organizado a disposição dos materiais no posto de trabalho;
Batch Size: corresponde ao número de kanbans de produção que devem ser juntados para disparar uma ordem de fabricação do produto. O valor do tamanho do lote nunca deve ser maior que o total de kanbans em circulação, pois assim a ordem de produção nunca será disparada. Um lote grande significa menos mudanças na linha de produção, contudo, aumenta a probabilidade de ocorrerem rupturas enquanto o lote está sendo formado. A diferença entre o total de kanbans e o tamanho do lote é igual ao estoque de segurança.
Box/Pallet: significa a quantidade de caixas de produtos acabados que completam uma palete. Para se ter a quantidade final de itens por palete, deve-se multiplicar tal valor pelo pack out quantity.
Initial Stock: quantidade de caixas de um produto disponível no estoque de produtos acabados (product store) prontos para expedição. Este valor deve ser menor que o número de kanbans de produção, uma vez que cada caixa neste armazém está associada a um kanban que só será posto no quadro de formação de lote após a sua retirada para o setor de expedição.
Production Kanbans: este campo define a quantidade kanbans de produção de cada produto. Esses kanbans são utilizados para repor o estoque de produtos acabados e tem relação direta com o tempo de produção em cada uma das células e o tamanho do lote.
Repacking Time: tempo necessário para encher cada contentor vazio no supermercado. Caso o mizusumashi chegue ao supermercado e o material não tenha sido reposto, ocorrerá um atraso na sua saída. Na prática, geralmente o mizusumashi não espera pelo produto e inicia o ciclo no tempo correto, mesmo que não reabasteça aquela célula em particular. Entretanto, como o reabastecimento do supermercado sempre conta com a disponibilidade de todos os itens para o repacking, o trem logístico nunca irá ser prejudicado. A única exceção é quando a soma do tempo necessário para encher das caixas do supermercado é superior ao tempo de ciclo do mizusumashi.
Setup Time: tempo gasto por um posto de trabalho sempre que começa a produzir um produto diferente. Durante esse período não há produção.
Cycle Time: tempo que cada operário gasta para realizar as suas operações num determinado tipo produto. Por exemplo, se temos seis operários por célula e cada um tem um tempo de ciclo de quarenta segundos, isso quer dizer que são gastos quatro minutos de mão-de-obra para montar cada unidade. No simulador, os postos de trabalhos são considerados sempre balanceados.
Workcell: pode-se escolher um dos seguintes valores: 1, 2 ou 3 que são referentes à numeração das três células de fabrico. Uma vez associado, o produto só será feito naquela célula.
Sale Price: valor de venda do produto para estimar as receitas no período.
Holding Costs: custos de manutenção mensais dos estoques por caixa de produto.
Add Order: é um menu para adicionar pedidos de venda. As quantidades das entregas só podem ser múltiplas das quantidades por palete. O usuário deve escolher uma hora de entrega dentro do turno de produção para que a ordem seja adicionada ao heijunka box.

No segundo menu, representado na figura 23, relativo às configurações do chão de fábrica, há um botão de grupo para escolher o modo da simulação: a primeira delas usa a abordagem tradicional de abastecimento da linha de produção com empilhadeiras ou carrinhos manuais de transporte. Já a segunda opção gera uma simulação cujas células de produção são abastecidas por um mizusumashi, conforme descrito na revisão literária.

Figura 23 - Menu de configuração do chão de fábrica.

Em seguida existe um conjunto de campos para se colocar a hora de início e fim do turno a ser simulado. Optou-se por limitar o tempo da simulação a um único turno devido ao fato de que nas mudanças de turnos o mizusumashi passar a percorrer um circuito diferente. Essa mudança da rota de turno para turno é bastante comum e acontece por causa das diferenças nas cargas de trabalho deles.

No separador number of Workstation pode-se definir quantos postos de trabalho cada célula possui. O valor pode variar de um a treze, contudo, vale ressaltar que, na maioria dos casos, tais valores raramente são maiores que quatro.

Figura 24 - Configuração da tabela com as distâncias da simulação.

No lado direito do menu há um separador com o nome simulation config que contém uma caixa de seleção na qual o usuário poderá definir se deseja visualizar a animação ou ir direto para os resultados. Neste separador ainda existe um campo para definir a data de início da simulação assim como a quantidade de dias a simular.

Por fim, pode-se definir o pitch-time do heijunka box e a velocidade da animação.

Complementando os dados em comum aos dois ambientes de simulação, existe a aba travel localizada mais abaixo. Além dos campos que definem a velocidade do abastecedor para cada um dos modos de simulação, esta aba contém uma matriz simétrica com as distâncias em metros entre os principais pontos da área de produção, tal como se mostra na figura 24. Esse conjunto de dados é usado no cálculo para o deslocamento do mizusumashi ou empilhador.

Simulação no Modo da Próxima Atividade

Como já se sabe, o Pull Simulator permite escolher qual método de abastecimento das linhas de produção deverá ser utilizado. O primeiro deles, o método da próxima atividade, baseia-se em um movimentador de materiais dirigindo um pequeno carro de cargas que pode ou não ser motorizado. Isso se deve ao fato da ênfase da simulação ser na redução do desperdício e não no aumento da velocidade média de transporte.

Nesta modalidade o empilhador sempre deve verificar qual é a próxima atividade a fazer, julgá-la de acordo com uma lista de prioridades e executar a que tiver mais urgência. À primeira vista parece um pouco complicado fazer esse procedimento complexo, no entanto o operário termina por se acostumar. Às vezes, pode acontecer de uma atividade com menos prioridade ser executada antes de uma mais urgente, mas esse caso não foi considerado na simulação.

Uma vez conhecido o modo de seleção da próxima atividade a ser executada, explica-se agora em que consiste cada uma delas na ordem decrescente de prioridade.

Retirar kanbans do heijunka box: é a atividade desencadeadora do restante dos eventos e também a de maior prioridade. Ela consiste em ir à caixa de nivelamento nos horários pré-determinados e remover os kanbans referentes àquela coluna. Em caso de existir algum kanban em colunas representadas por um horário inferior ao atual, os mesmos devem também ser removidos.
Retirar produtos acabados do armazém: após ter retirado os kanbans de transporte, o abastecedor deve ir ao Product Store e retirar uma caixa de produto acabado para cada kanban que tiver na mão. Na hipótese de não haver material, o mesmo deverá colocar o cartão de movimentação na caixa de rupturas. Outra atividade a ser feita paralelamente a esta é pegar o cartão de produção da mercadoria utilizada e fixá-los na caixa de construção de lote.
Entregar mercadoria no setor de expedição: seguidamente à atividade anterior, o transportador deixa as caixas de produto acabado nos paletes localizados na área de expedição.
Comandar a produção: como foi dito anteriormente, o abastecedor de materiais também é responsável pela transmissão da informação no chão de fábrica. Dessa forma, toda vez que se forma um lote de produção no quadro de construção de lote, o conjunto de kanbans é levado ao supermercado onde ocorrerá a separação de materiais. Depois, tanto os kanbans como os materiais são entregues no seqüenciador da célula de produção onde estarão à espera de sua vez para serem produzidos na mesma ordem em que foram entregues.
Transportar a produção das células para o armazém: uma vez manufaturados, os produtos são postos na saída da linha e ficam à espera do empilhador para serem transportados para o armazém de produtos acabados (product store). Contudo, se o produto montado estiver em ruptura, o mesmo é levado diretamente para o setor de expedição, somente no caso de haver alguma sobra é que se leva o material para o armazém.

Transportar caixas vazias de volta para o supermercado: as caixas com os kanbans entregues no bordo de linha são levadas de volta para o supermercado assim que se esvaziam. Lá, são postas nos retornos e reabastecidas nas estantes pelos funcionários do repacking.

No desenvolvimento do configurador dos tempos das atividades, optou-se por subdividir alguns tempos dessas atividades. Essa modelagem foi considerada a ideal, pois além da distância que o operário precisa percorrer entre os pontos da fábrica, em várias tarefas é necessário repetir apenas uma fração da mesma para se obter o mesmo resultado. Por exemplo, para se entregar duas caixas na área de expedição o tempo é significativamente menor que dobro do tempo de entregar uma só caixa.

As subdivisões das atividades são as seguintes:

Heijunka Box:

Pickup Kanbans: tempo gasto para retirar todos os kanbans de uma coluna da caixa de nivelamento.
Tolerance Time: não se aplica.

BatchBoard:

Add/Remove Kanban: intervalo de tempo necessário para colocar o kanban no quadro de formação de lotes ou no quadro de rupturas. O tempo de remoção foi considerado igual.

Forklift:

Move Among Pallets: no setor de expedição, o tempo de se mover de uma palete de um produto para a próxima é representada por essa variável.
Move Inside Supermarket: tempo para os deslocamentos realizados dentro dos supermercados das várias famílias.

Material Handling:

Add/Remove Box to Product Store: duração das atividades de retirar ou deixar uma caixa de produto acabado no armazém e trocar o kanban de produção com o kanban de movimentação.
Add/Remove Product Box to Pallet: uma vez na área de expedição, estacionado no local correto, esse campo contém os segundos gastos para tirar uma caixa do carro e colocá-la na palete.
Add/Remove Container Batch: tempo gasto para carregar/descarregar um conjunto de contentores vazios no carro.
Add/Remove Production Kanban Lot to Batchboard: tempo gasto para depositar o lote de kanbans no supermercado para que o setor de repacking separe o material.
Move Kanban Lot From BatchBoard to Supermarket: quando um lote é formado, o tempo para colocar os kanbans no seqüenciador para o repacking é definido por este campo.
Move ContainerBatch From Supermarket to Chute:
tempo gasto para levar um lote de contentores cheios de materiais para o seqüenciador das células.
Move
ContainerBatch From Chute to WorkCell: tempo de retirar o lote de contentores do seqüenciador e colocá-los em posição adequada para o uso na linha de montagem. Atividade realizada pelo operários da célula.

Todos os tempos devem ser inseridos em segundos, estando representados na figura 25.

Simulação no Modo do Circuito Fixo

Esta segunda abordagem do tipo de movimentação do material no chão de fábrica e transmissão da informação é mais simples que a anterior uma vez que as tarefas são feitas conforme um ciclo pré-estabelecido, sempre na mesma ordem. Ao chegar a um ponto de parada, o mizusumashi verifica se precisa fazer alguma atividade e a realiza se for o caso. Se não for preciso, vai para a próxima parada do ciclo.

O maior benefício desse método, além da redução das perdas por deslocamento, é a normalização das operações do abastecedor. Isso permite calcular quantas caixas deve haver em cada posição do bordo de linha para que não falte material durante o período de duas passagens consecutivas do mesmo. Ou seja, um ciclo para retirar a caixa vazia e outro para devolvê-la cheia. Dessa forma não há material em excesso nem parada da linha por falta de abastecimento.

Nesta abordagem pode-se facilmente saber se um mizusumashi é suficiente para entregar os materiais num determinado grupo de células ou não. Para tal, basta saber se o mesmo está completando uma volta no tempo pré-estabelecido ou não.

A norma do ciclo do abastecedor foi definida na programação e não pode ser alterada, exceto o tempo disponível para cada volta, que pode ser ajustado no campo pitch-time na tela inicial. O circuito tem início na saída do supermercado nas horas indicadas na caixa de nivelamento. Em seguida o trem logístico pára em cada célula de produção, recolhe as caixas de produto acabado, coloca os kanbans de produção no seqüenciador, abastece a célula e retira os contentores vazios.

Depois segue para o heijunka box e recolhe os kanbans de movimentação. A seguir vai para o armazém de produtos acabados deixa as caixas produzidas nas células e retira aquelas que vão ser expedidas. Caso algum produto que estava em falta tenha sido fabricado, um kanban do quadro de rupturas é retirado para ser entregue também no setor de expedição. Ele é responsável também por completar a caixa de construção de lote com os kanbans de produção em mão e retirar os lotes completados.

Na parada seguinte, deixa as caixas que vão ser expedidas nos seus respectivos paletes e segue de volta para o supermercado onde vai deixar os vagões vazios e atracar os vagões abastecidos. Por fim, espera que termine o tempo do ciclo para iniciar o seguinte.

Figura 26 - Menu de ajuste de tempo das atividades com campos de
média e desvio padrão na modalidade do circuito fixo.

Nesta abordagem, os parâmetros com os tempos das atividades, representados na figura 26, são os seguintes:

Heijunka Box:

Pickup Kanbans: tempo para remover os kanbans de movimentação da caixa de nivelamento.
Tolerance Time: caso o mizusumashi acumule atraso ao longo dos ciclos, ele poderá retirar os kanbans de movimentação de duas ranhuras do heijunka box. Isso pode acontecer desde que a hora da segunda coluna seja inferior à hora atual somada ao tempo de tolerância.

Batchboard:

Add/Remove Kanban: tempo para colocar um kanban de produção no quadro de construção de lotes.

Mizusumashi:

Delay Time to Check Tasks: atraso sofrido durante um ciclo ao chegar a uma parada que não necessita de atividades a serem feitas.
Change Tow Tractor Wagon: tempo decorrido entre o desatrelar dos vagões vazios e atrelamento dos vagões abastecidos.

Material Handling:

Add/Remove Container: tempo para entregar ou recolher um contentor cheio ou vazio na célula de produção.
Add/Remove Production Kanban Lot: tempo necessário para retirar um lote formado no quadro de construção de lotes ou colocar um lote de kanbans no seqüenciador da célula.
Add/Remove Remove Box to Workcell: tempo gasto na recolha dos produtos acabados na célula de produção.
Add/Remove Box to Product Store: tempo para descarregar ou carregar uma caixa de produto acabado no armazém e fazer a troca de kanbans.
Add Product Box to Pallet: tempo gasto para retirar uma caixa de produto acabado do carro e colocá-la na palete.
Get Container from Workcell Buffer: tempo para colocar um contentor de materiais que estava no bordo de linha na posição de utilização. Atividade realizada pelo operários da célula.

Todos os tempos cujos campos de preenchimento são mostrados na figura 26 devem ser inseridos em segundos.

Comentário acerca das variáveis dos dois métodos

Embora haja muitas variáveis semelhantes, as telas de parametrização de cada um dos métodos não são idênticas. As mudanças são decorrências das diferentes formas de realizar as atividades em cada um dos modelos.

Além disso, os parâmetros que se referem a uma mesma atividade podem ter valores diferentes para cada um dos modos de simulação. As causas podem estar na diferença do método de execução da tarefa ou nas conseqüências físicas do deslocamento de um comboio grande, no caso do mizusumashi, contra uma pequena empilhadora, no caso do forklift.

Por exemplo, podem existir diferenças nos valores das variáveis de carregamento e descarregamento de um produto na palete ou no Product Store. No modelo do empilhador, a descarga do material é aleatória e os movimentos acumulam muito desperdício. Já no modelo do mizusumashi, a descarga é feita de forma otimizada. Esse ganho de tempo, exemplificado na figura 27, deve-se ao fato de o mizusumashi realizar um circuito fixo que permite aos vagões do comboio pararem sempre na melhor posição para o operador. Observe que as setas do caminho feito pelo water-spider não se cruzam e são bem menores.

Figura 27 - Exemplo da diferença entre os deslocamentos do mizusumashi e do empilhador
para realizar uma mesma atividade de expedição de três caixas.

Uma das maiores desigualdades entre os métodos está na quantidade de peças movimentadas por vez. Enquanto o mizusumashi realiza a tarefa item por item, o empilhador realiza a movimentação em lotes. Por isso a diferença nas descrições de Container para Container Batch.

Outra variante está no campo tolerance time que só faz sentido ser utilizado no método do circuito fixo.

Por fim, encontram-se as tarefas que são exclusivas de cada um dos modelos. Embora já tenham sido explicados anteriormente, vale a pena citá-los:

Mizusumashi:

"delay time to check tasks", "change tow tractor wagon";
Forklift:

"move among pallets", "move inside supermarket".

Figura 28 - Quadro resumo da simulação.

Resultados Obtidos Através do Simulador

Depois de ter introduzido os conceitos teóricos e explicado o funcionamento do simulador, o presente capítulo tem o intuito de demonstrar alguns resultados relevantes obtidos com o uso do Pull Simulator.

No final de cada simulação é apresentada uma tela semelhante à figura 28, que contém os resultados e seis gráficos diferentes. Existe também uma caixa de texto na lateral esquerda com um resumo das entregas, vendas e produção referentes a cada tipo de produto. Embaixo de cada gráfico há um botão que quando clicado mostra mais detalhes sobre o tópico representado por eles:

Mizusumashi ou empilhador: apresenta um gráfico em forma de pizza na qual cada fatia representa um tipo de atividade realizada pelo mizusumashi. Numa tabela ao lado são mostrados os totais de caixas, contentores e kanbans movimentados. A distância total percorrida assim como a sua divisão em deslocamento carregado e em vazio também são apresentados.
Célula de manufatura: mostra um gráfico em forma de pizza para cada linha de produção mostrando o tempo gasto na montagem de cada tipo de produto e em setups. Também quantifica o período que ficou à espera de material para começar a produzir (starving) e quanto ficou à espera que o posto seguinte finalizasse o trabalho para repassar a próxima peça (blocked). Por fim, informa o número de setups efetuados.
Estoque de produto acabado: apresenta um gráfico em duas dimensões da quantidade em estoque no armazém de produtos acabados ao longo do tempo.
Estoque de produto acabado Valorizado: semelhante ao anterior, residindo a única diferença na multiplicação das unidades em estoque pelo seu preço de venda.
Carga nos seqüenciadores: mostra quantos itens havia nos seqüenciadores do repacking aguardando serem abastecidos e em cada célula aguardando por produção.
Custos de manutenção de estoques: apresenta o custo final de armazenamento de cada produto.

Um exemplo de cada gráfico se encontra no anexo B.

Comparação do Empilhador com o Mizusumashi

Ao simular um turno de oito horas de produção com três células funcionando de acordo com os seguintes dados:

Tabela 2 - Procura do turno simulado no cenário 1.

Cenário 1: Procura do Turno Simulado
Célula	Produto	Procura (unidades)
Célula 1	Produto A	100
Célula 1	Produto B	80
Célula 2	Produto H	144
Célula 3	Produto F	768

Tabela 3 - Dados complementares do cenário 1.

Cenário 1: Dados Complementares
Produto	Quantidade / Caixa	Tamanho do Lote	Caixa / Palete	Estoque Inicial (em Caixas)	Número Kanbans	Tempo de Repacking	Tempo de Setup	Tempo de Ciclo
A	10	3 Caixas	5	4	6	00:00:12	00:10:00	00:01:30
B	8	2 Caixas	10	8	10	00:00:20	00:08:00	00:01:40
F	24	7 Caixas	8	12	14	00:00:05	00:05:00	00:00:45
H	12	4 Caixas	6	0	8	00:00:14	00:10:00	00:02:15

Relatório da Simulação Utilizando o Empilhador

Os resultados mostraram que o empilhador fez 97 movimentações de caixas, 62 movimentações de contentores e 188 movimentações de kanbans.

Além disso, constatou-se que o empilhador viajou uma distância total de 13920 metros dos quais 6.840 metros (49%) foram deslocamentos sem carga. Ou seja, ouve um desperdício de quase metade do tempo de deslocamento do funcionário. Além disso, teve uma folga de 67 minutos.

No relatório da distribuição da atividades, mostrado na figura 29, pode-se verificar que o empilhador gastou 34,22% do tempo expedindo produtos acabados, 23,56% reabastecendo as células de produção, 18,10% reabastecendo o supermercado, 10,20% recolhendo caixas vazias e ficou 13,92% parado.

Figura 29 - Distribuição do tempo do empilhador pelas atividades realizadas.

Relatório da Simulação Utilizando o Mizusumashi

Já os números em relação ao trabalho do mizusumashi mostraram que o mesmo movimentou 64 caixas 45 contentores e 190 kanbans. Percorreu 7420 metros dos quais 30% em vazio. Além disso, teve uma folga de 97 minutos.

O operador completou 32 voltas distribuídas ao longo do turno. É comum existir uma volta mais demorada por coincidir um maior número de materiais a serem movimentados num único ciclo. Esta volta, chamada de "Ciclo Crítico", foi concluída com 25 minutos e 4 segundos, uma variação aceitável para um pitch-time de 20 minutos.

Figura 30 - Distribuição do tempo do mizusumashi pelas atividades realizadas.

Ao analisar o tempo gasto em cada atividade do mizusumashi pelo gráfico gerado pelo simulador mostrado na figura 30, constata-se que o mesmo ficou 19,89% do tempo parado. Além disso, gastou 35,88% do tempo expedindo produto acabado, 21,28% reabastecendo as células de produção, 5,69% reabastecendo o supermercado e 17,36% trocando os vagões a serem transportados. Desses resultados, destaca-se a redução do tempo gasto em reabastecer o armazém (product store) de 18% para 5% devido à otimização dos movimentos realizados.

Empilhador x Mizusumashi

Figura 31 - Resumo da utilização das células de produção.

Em ambos os casos as linhas conseguiram produzir tudo o que estava programado. O atraso na entrega do material às células de produção não comprometeram a entrega das encomendas.

Entretanto, observando o relatório da simulação mostrado na figura 31, pode-se constatar que a utilização da capacidade das células 1 e 3 foram de 78,14% e 84,19% respectivamente. Em caso de carga total no sistema, a folga do empilhador poderá não ser suficiente para abastecer às células e para a entrega do produto acabado na expedição com mais freqüência.

Do ponto de vista de movimentação de material pelos abastecedores, os números apontam para uma grande vantagem do mizusumashi em relação ao empilhador. A forma sistemática de trabalho do mizusumashi fez com que o mesmo tivesse menos desperdício, movimentando os materiais de forma correta e perdendo apenas 31 minutos em deslocamento contra 77 do empilhador (ver quadro abaixo).

Embora o mizusumashi tenha ganhado 77 – 31 = 46 minutos no fator de deslocamento, o empilhador gastou menos tempo com carga e descarga de material. Essa ligeira desvantagem pode ser notada na redução da diferença do tempo de descanso entre ambos. Ou seja, o empilhador deveria ter ficado parado 46 minutos a menos que o mizusumashi para compensar o excesso de deslocamento realizado, mas como ganhou algum tempo ao fazer a carga e a descarga do material em lotes, a diferença caiu para 30 minutos.

As perdas do empilhador não se limitam aos 30 minutos no final da jornada, às mesmas são somados o gasto extra de energia e desgaste da empilhadeira para percorrer os 6500 metros em excesso todos os dias.

Na simulação ainda não foram considerados pontos subjetivos que trazem algumas vantagens ao mizusumashi que são difíceis de mensurar. Entre elas podemos destacar:

O aumento da segurança por estabelecer uma rota padrão para o deslocamento de máquinas no chão de fábrica;
Os erros causados pela realização de uma tarefa com menos prioridade antes que uma mais crítica. Por exemplo, uma célula pode ficar preciosos minutos parada por falta de abastecimento porque o empilhador foi levar mais material para a expedição;
A entrega do material em um local errado;

Tabela 4 - Quadro resumo da comparação mizusumashi e empilhador.

Resumo da Comparação Mizusumashi x Empilhador
Variável Observada	Unidade	Mizusumashi	Empilhador	Perda Adicional do Empilhador
Distância Percorrida	Metros	7420	13920	88%
Movimento em Vazio	Metros	2226	6840	207%
Movimentações de Caixas	Unidades	64	97	51%
Movimentações de Contentores	Unidades	45	62	38%
Movimentações de Kanbans	Unidades	190	188	0%
Tempo em Deslocamento	Minutos	31	77	149%
Tempo de Carga e Descarga	Minutos	352	336	-5%
Parado (Descanso)	Minutos	97	67	-31%

Por fim, é interessante ressaltar que o cenário em análise foi baseado numa fábrica em que a distância entre o supermercado e a linha de produção é muito pequena. É bastante comum encontrar rotas de mizusumashi que são até três vezes maiores que essa. Nesses casos os resultados seriam ainda menos favoráveis aos empilhadores.

Na situação em análise, o empilhador que tem uma velocidade média de 3 metros por segundo, gastou 77 minutos para percorrer os 13920 metros no turno. Já o mizusumashi, que possui uma velocidade média mais alta, de 4 metros por segundo, gastou 31 minutos em deslocamento.

Por exemplo, considerando que as distâncias fossem duas vezes maiores, o mizusumashi teria de percorrer outros 7420 metros, gastando para isso mais 31 minutos. Mesmo assim, ainda teria uma folga de 66 minutos para descansar ao longo do dia. Já o empilhador teria uma situação muito mais desconfortável, iria passar de uma folga de 67 minutos para um atraso de 10 minutos por turno. O atraso no abastecimento do material seria inevitável e o output da produção seria menor.

Conclusões e perspectivas de trabalho futuro

Chegando ao fim da dissertação, o leitor percebeu que tanto a revisão literária quanto o desenvolvimento do texto foram escritos numa linguagem simples acompanhada de diversas ilustrações para que qualquer pessoa pudesse facilmente compreender todos os tópicos. Essa componente didática foi propositadamente reforçada uma vez que o simulador é uma ferramenta interativa dos alunos e profissionais aprenderem, de forma autodidata, como acontece o abastecimento às células de produção e a interferência que cada uma das variáveis causa ao sistema.

O desenvolvimento do motor da simulação visual e interativa foi a parte que mais consumiu tempo no projeto. O software foi concebido baseado no modelo schedule-execute, criado pelos orientadores António Brito e José Barros Bastos, ao qual foi adicionado uma componente de animação bastante intuitiva. Depois, o algoritmo passou por uma fase de testes, simulando o comportamento das filas nos refeitórios da Universidade do Porto (vide anexo D).

A sua simplicidade, robustez e fácil compreensão permitem que seja utilizado como base de várias simulações em JAVA®. Esse fato reduzirá de forma considerável o tempo de desenvolvimento de novas simulações interativas pelos iniciantes na programação por computador.

Todo o material está publicado na internet de forma gratuita para que os professores utilizem esta ferramenta em sala de aula e despertem interesse nos jovens de criar novos cenários e até mesmo em construir os seus próprios simuladores.

Na perspectiva do desenvolvimento teórico, foi analisada a importância do abastecedor das células de produção na eliminação do desperdício dos operários. Estudaram-se os dois métodos mais comuns de abastecimento de forma qualitativa e quantitativa para uma determinada situação de logística interna.

Concluiu-se que o modelo com o mizusumashi é mais fácil de ser gerido porque não é necessário tomar decisões sobre qual a próxima tarefa a ser executada, nem estabelecer uma lista de prioridades das requisições de abastecimento. Ainda mais, pode-se medir o seu atraso ou folga observando as horas em que ele passa pelo heijunka box. Com o estabelecimento das normas de operação, é possível definir um circuito fixo e otimizado para ser repetido ao longo de todo o turno de trabalho.

Nos resultados do cenário simulado, o mizusumashi apresentou uma redução de 67% da distância percorrida sem cargas e eliminação de 42% do tempo gasto no deslocamento face ao modelo tradicional. Também conhecido como water-spider, ele abasteceu a mesma quantidade de material e ainda descansou 30 minutos por turno a mais que o empilhador.

Visando sofisticar o Pull Simulator, pretende-se adicionar à simulação diferentes métodos de trabalho do mizusumashi uma vez que o mesmo varia de indústria para indústria. Além disso, deseja-se adicionar mais variáveis às células de produção para saber o comportamento do sistema diante de quebras de máquinas, defeitos de qualidade e cansaço do operador. Com essas funcionalidades, a aplicação prática do simulador se dará de forma ainda mais realista.

Referências e Bibliografia

Alvarez, R. d. R. (2001). Takt-Time: Conceitos e Contextualização Dentro do Sistema Toyota de Produção. Gestão e Produção. Rio de Janeiro – RJ, Universidade Federal do Rio de Janeiro (UFRJ). 8: 18.

Bodek, N. (2007). LeanBlog Podcast #32 - Norman Bodek in Japan.

Chase, R. B., F. R. Jacobs, et al. (2006). Administração da Produção e Operações. São Paulo, McGraw Hill.

Coimbra, E. (2003). "Introdução à Logística Alternativa." Kaizen Forum
7.

Colin, E. C. (ano desconhecido). "Estudo da Implementação de Kanbans Numa Empresa de Autopeças: Dificuldades e Caminhos." Departamento de Engenharia de Produção - Escola Politécnica da Universidade de São Paulo.

Danni, T. d. S. (ano desconhecido). Ajuste Dinâmico de Kanbans de um Sistema Produtivo JIT através da Simulação Pós-Graduação em Engenharia de Produção. Florianópolis, Universidade Federal de Santa Catarina.

Fernandes, A. R. (2005). Manutenção Produtiva Total:Uma Ferramenta Eficaz na Busca da Perda-Zero. Itajubá, Universidade Federal de Itajubá.

Ghinato, P. (1998). "Heuristic Aprocache to Solve The Multifunction Worker Assignment Problem in U-Shaped Work-Cell." International Conference on Automation Technology
5.

Ghinato, P. (1999). Autonomia e Multifuncionalidade no Trabalho: Elementos Fundamentais na Busca da Competitividade. Série Monográfica Ergonomia: Ergonomia de Processo. L. B. d. M. Guimarães. Porto Alegre, PPGEP/UFRGS. 2.

Ghinato, P. (2000). Elementos Fundamentais do Sistema Toyota de Produção. Produção & Competitividade: Aplicações e Inovações. A. T. d. A. F. M. C. Souza. Recife, UFPE.

Gross, J. M. and K. R. McInnis (2003). Kanban Made Simple: Demystifying and Applying Toyota's Legendary Manufacturing Process. New York, NY American Management Association.

Hobbs, D. P. (2004). LEAN Manufacturing Implementation: A Complete Execution Manual for Any Size Manufacturer. Boca Raton, Florida J. Ross Publishing.

Huq, F., D. A. Hensler, et al. (2001). "A simulation analysis of factors influencing the flow time and through-put performance of functional and cellular layouts." Integrated Manufacturing Systems
2.

Kumar, C. S. and R. Panneerselvam (2005). "Literature review of JIT-KANBAN system." Advanced Manufacturing Technologies.

Lean Enterprise Institute (2005). Lean Lexicon.

Liker, J. K. (2004). The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. Madison, WI, McGraw-Hill.

Miltenburg, J. (2000). "One-piece flow manufacturing on U-shaped production lines: a tutorial." IIE Transactions.

Miyake, D. I. (2006). "The Shift from Belt Conveyor Line to Work-cell Based Assembly Systems to Cope with Increasing Demand Variation and Fluctuation in The Japanese Electronics Industries." CIRJE Discussion Papers.

Namoura, J. and S. Takakuwa (2006). "Optimization of a Number of Container for Assembly Lines: The Fixed Course Pickup System." International Journal of Simulation Modeling
5: 11.

Ohno, T. (1997). O Sistema Toyota de Produção: Além da Produção em Larga Escala. Porto Alegre, Bookman.

Sato Consultoria de Pessoal. (2008). "Círculo de Controle da Qualidade." Retrieved 23 de Janeiro, 2008, from http://www.sato.adm.br/rh/circulos_de_controle_de_qualidad.htm.

Smalley, A. (2006). "Conectando a Montagem aos Processos em Lotes através de Sistemas Puxados Básicos." Lean Institute Brasil.

Zagonel, E. (2006). Implantação do Fluxo Unitário de Peças Numa Célula de Usinagem: Estudo de Caso por Meio de Simulação. Departamento de Engenharia Mecânica. Curituba, Universidade Federal do Paraná. Mestrado.

Anexo A - Ficha de Trabalho Padrão

Anexo B - Gráficos com os Resultados da Simulação

Figura 33 - Exemplo de um gráfico do mizusumashi ou empilhador exibido nos
resultados da simulação.

Figura 34 - Exemplo do relatório de uma célula de manufatura emitida pelo simulador.

Figura 35 - Gráficos de estoque por quantidade e por valor apresentados
no final da simulação. Valores negativos indicam a ruptura de estoque.

Anexo C - Fluxogramas

Anexo D - Exemplos Reais dos Elementos Citados no Texto

Anexo E - SimCantina: Projeto Base Antes de Iniciar o Pull Simulator

O projeto SimCantina foi um simulador bastante simples, criado para avaliar o tempo médio que os alunos da Universidade do Porto gastavam na fila todos os dias e ponderar a aquisição de mais uma máquina de vender os tickets de refeição.

O objetivo era aprender os conceitos da simulação por eventos que incluísse a recolha de dados, uma animação das entidades simuladas e um relatório final com os resultados obtidos. Também era necessário que o modelo fosse flexível e que todas as variáveis pudessem ser configuradas dentro do próprio programa sem recorrer ao código fonte, como mostrado na figura 44.

O ponto de partida foi o modelo Schedule-Execute desenvolvido pelos pesquisadores Manuel Feliz Teixeira e António Brito do departamento de Gestão e Engenharia Industrial da Universidade do Porto. Tal modelo é descrito no livro da autoria de ambos, intitulado Simulação por Computador da editora Publindústria.

O resultado foi um motor de simulação visual e interativa simples, robusto e fácil de compreender pelos iniciantes na simulação por computador. Além do mais, o código é bastante flexível e de grande portabilidade, o que permite aos alunos o desenvolvimento de uma simulação em um curto intervalo de tempo.

Considerando os parâmetros acima, ao clicar em Start Simulation pode-se verificar através da figura 45 que se forma uma fila de clientes muito grande se for utilizada uma única máquina de vender tickets.

etanto, ao adicionarmos uma segunda máquina, o fluxo de clientes se torna muito maior, já passam a existir mais clientes sentados nas mesas do que esperando pela comida e que a fila da máquina de tickets desaparece.

O código-fonte é livre (open-source) e seu download pode ser feito no seguinte endereço: http://www.luizfreire.com/simulator/SimCantina-Src.rar

A seguir o leitor poderá ver o código-fonte de algumas classes mais importantes da simulação. Contudo, para um perfeito entendimento é necessária a leitura do livro acima.

/**

* @(#)SimEntity.java

* Superclass for all entities used in the simulation

import java.awt.Image;

import java.util.LinkedList;

import javax.imageio.ImageIO;

public abstract class SimEntity {

protected final Simulator simulator; //reference to the simulator

protected final double createdTime; //entity created time

protected double lastUsedTime; //time when the entity was last used

protected int workTimeCount = 0; //sum of entity activities time in milliseconds

protected boolean isWorking = false; //Entity free or working?

protected String status = null; //Entity actual status

protected String name; //Entity name

protected String desc; //Entity description

protected static final double scale = 33; //The number of pixels that represents 1 meter on the screen

protected double speed = 1; //speed in meters per second

protected int x = 0; //x coordenate

protected int y = 0; //y coordenate

/////////////////////////////////////////////////////////////////////////////////////////////////////

//PROPRIETIES

/////////////////////////////////////////////////////////////////////////////////////////////////////

public double getCreatedTime() { return createdTime; }

public double getLastUsedTime() { return lastUsedTime; }

public int getWorkTimeCount() { return workTimeCount; }

public String getStatus() { return status; }

public String getName() { return name; }

public boolean isWorking() { return isWorking; }

public double getSpeed() { return speed; }

public int getX() { return x; }

public int getY() { return y; }

/////////////////////////////////////////////////////////////////////////////////////////////////////

//CONSTRUCTOR

/////////////////////////////////////////////////////////////////////////////////////////////////////

//This function is called before the derived class constructor. It doesn't override.

protected SimEntity(Simulator simulator) {

this.simulator = simulator;

simulator.addToEntityList(this);

createdTime = simulator.getTime();

lastUsedTime = simulator.getTime();

}

/////////////////////////////////////////////////////////////////////////////////////////////////////

//EXECUTE

/////////////////////////////////////////////////////////////////////////////////////////////////////

public abstract void Execute(SimEvent event); //interface with simulator

/////////////////////////////////////////////////////////////////////////////////////////////////////

//SIMULATION EVENTS

/////////////////////////////////////////////////////////////////////////////////////////////////////

* All events in the simulation shold be listed here

* Please follow the event name template: ENTITY_EVENT

public enum Events {

CLIENT_ARRIVE, //always the first event for a new client

CLIENT_LEAVE, //always the last event for a client

TICKETMACHINE_START_BUY_TICKET,

TICKETMACHINE_END_BUY_TICKET,

WAITER_START_DELIVERY,

WAITER_END_DELIVERY,

TABLE_CHAIR_START_TO_EAT,

TABLE_CHAIR_END_TO_EAT,

SIMULATION_END //Stops the simulation prematurely

};

/////////////////////////////////////////////////////////////////////////////////////////////////////

//ANIMATION

/////////////////////////////////////////////////////////////////////////////////////////////////////

protected static AnimationIcons icons = new AnimationIcons(); //collection of entity images

protected Image icon = null; //actual entity image

protected void setVisible() { simulator.getDrawList().addLast(this); } //show the entity on the screen

protected void setInvisible() { simulator.getDrawList().remove(this); } //hide the entity

/////////////////////////////////////////////////////////////////////////////////////////////////////

//ANIMATION MOVES

/////////////////////////////////////////////////////////////////////////////////////////////////////

protected LinkedList<Move> listOfMoves = new LinkedList<Move>(); //store the animation steps

public Move getLastMove() { return listOfMoves.getLast(); } //return the last movement of the object

//change the entity icon on the time especified

public void updateImage(Image icon, double time) {

Move m = new Move(icon, x, y, x, y, time, time);

m.setTheta(listOfMoves.getLast().getTheta());

listOfMoves.addLast(m);

}

public void updateImage(Image icon, double time, double dt) {

listOfMoves.addLast(new Move(icon, x, y, x, y, time, time + dt));

}

//define where and when the object begin to be displayed on the screen

public void setStartPosition(int x, int y) {

if (listOfMoves.size() == 0) {

Move m = new Move(icon, x, y, x, y, this.createdTime, this.createdTime + 1);

listOfMoves.addFirst(m);

//System.out.println("setStartPosition: " + this.desc + "Move: " + listOfMoves.size());

}

//get the entity move associated with the time t

public Move getAnimationMove(double t) {

Move m = listOfMoves.getLast();

for(int i = listOfMoves.size(); i > 0; i--) {

if(t < m.getBeginTime()) {

m = listOfMoves.get(i-1);

} else break;

}

return m;

}

/**

* @(#)SimEvent.java

* this object is a simulation event that will be stored in the linkedlist eventlist waiting your turn to run

import java.util.*;

import java.text.*;

public class SimEvent {

private final SimEntity entity; //reference to entity

private final SimEntity.Events routine; //event routine

private final double time; //when the event will be executed

private final int id; //event identification

static int count = 0; //event count

/////////////////////////////////////////////////////////////////////////////////////////////////////

//PROPRIETIES

////////////////////////////////////////////////////////////////////////////////////////////////////

public SimEntity getEntity() { return entity; }

public SimEntity.Events getRoutine() { return routine; }

public double getTime() { return time; }

public int getId() { return id; }

/////////////////////////////////////////////////////////////////////////////////////////////////////

//CONSTRUCTOR

/////////////////////////////////////////////////////////////////////////////////////////////////////

public SimEvent(SimEntity entity, SimEntity.Events routine, double time)

{

this.entity = entity; //get the entity

this.routine = routine; //get the routine

this.time = time; //get the time

id = ++count; //increment the counter

}

/**

* @(#)Simulator.java

* Simulation base class: this object controls the time, and executes the simulation events

* It also tells the animation panel what part of the simulation should be played

* Time foward technique: time slicing

import java.util.*;

import java.text.*;

import javax.swing.JApplet;

import javax.swing.UIManager;

import javax.swing.UnsupportedLookAndFeelException;

public class Simulator implements Runnable {

public final int NUMBER_OF_PRODUCTS = 10; //Max number of diferent products

public final double SIMULATION_LENGHT = 10; //Simulation Leght in milliseconds

private double tSim = 0; //Simulation actual time

private double tNext = 0; //next event time

public double getTime() { return tSim; } //Returns the time of the simulator

double beginToPlay = 0; //there will be no animation until tSim > beginToPlay

double endToPlay = 0; //and there will be no animation after tSim > endToPlay

public void setBeginToPlay(double t) {

beginToPlay = t;

}

public void setEndToPlay(double t) {

endToPlay = t;

}

//simulation speed factor -> Real Time = 1000

private int speed = 1000;

public int getSpeed() {

return speed;

}

//list of all used SimEntities durint the simulation

private LinkedList<SimEntity> entityList = new LinkedList<SimEntity>();

public LinkedList<SimEntity> getEntityList() {

return entityList;

}

public void addToEntityList(SimEntity entity){

this.entityList.addLast(entity);

}

//list of SimEntities to be drawn on the screen

private LinkedList<SimEntity> drawList = new LinkedList<SimEntity>();

public LinkedList<SimEntity> getDrawList() {

return drawList;

}

public void addToDrawList(SimEntity entity){

this.drawList.addLast(entity);

}

/////////////////////////////////////////////////////////////////////////////////////////////////////

//CONSTRUCTOR

/////////////////////////////////////////////////////////////////////////////////////////////////////

SetupDlg setupDlg; //dialog where the user can adjust some parameters like animation speed, number of entities...

private Thread animation;

private Thread simulation;

public Simulator() {

System.out.println("Simulator->Simulator()");

simulation = new Thread(this, "Simulator Thread");

animation = new Thread(animationPanel, "AnimationPanel Thread");

setupDlg = new SetupDlg(this); //Creates dialog for user input the simulation parameters

}

/////////////////////////////////////////////////////////////////////////////////////////////////////

//START

/////////////////////////////////////////////////////////////////////////////////////////////////////

private AnimationPanel animationPanel; //reference to the theater where the animation will be played

public void start() {

System.out.println("Simulator->Start()");

speed = setupDlg.getSpeed(); //get the simulation speed

animationPanel = new AnimationPanel(this); //show the animation window

simulation.start(); //starts the simulation thread

}

/////////////////////////////////////////////////////////////////////////////////////////////////////

//RUN

/////////////////////////////////////////////////////////////////////////////////////////////////////

public void run() {

//if there is any unexecuted event...

if(eventList.size() > 0) {

SimEvent event = eventList.removeFirst(); //Select the event

tSim = event.getTime(); //updates the simulation time

//Execute the event if it isn't the flag SIMULATION_END

if(event.getRoutine() != SimEntity.Events.SIMULATION_END) {

//System.out.printf("%s %s \n", "Time: " + (int)(event.getTime()/1000), event.getRoutine());

event.getEntity().Execute(event);

SimulatorReport.newSample(this);

}

//Get the next event time and compare to tSim to decide if is time to run another event, play the animation or do nothing

if(eventList.size() > 0) //prevents null pointer exception

{

tNext = eventList.getFirst().getTime();

//if there is another event at the same time, run it. Otherwise, show the animation

if((tSim < beginToPlay) || (tSim > endToPlay) || (tNext == tSim)){

run(); //run another event

} else {

animationPanel.play(tSim, tNext); //play the animation

}

else {

//final procedures

animationPanel.close(); //hide the animation window

System.out.println("Simulator->End");

//show the results

ShowReportDlg showReportDlg = new ShowReportDlg(this);

SimulatorReport.showReport_queues(showReportDlg, this);

}

/////////////////////////////////////////////////////////////////////////////////////////////////////

//SCHEDULE

/////////////////////////////////////////////////////////////////////////////////////////////////////

* Adds a SimEvent at the right place in the eventlist linkedlist ordered by the event time

* If two events should happen at the same time, the event tha was first scheduled will be executed first.

private LinkedList<SimEvent> eventList = new LinkedList<SimEvent>(); //Simulation event list that will be executed in the future

public void Schedule(SimEntity entity, SimEntity.Events routine, double time) {

SimEvent event = new SimEvent(entity, routine, time);

//System.out.printf("Event %s Scheduled: Time = %s Entity = %s\n", event.getRoutine(), event.getTime(), newEvent.entity);

if(eventList.size() == 0) //Verifies if the list is not empty to avoid nullpointer exception

{

eventList.addLast(event);

} else {

if(event.getTime() < eventList.getFirst().getTime()) {

eventList.addFirst(event);

} else {

SimEvent node = eventList.getLast();

for(int i = eventList.size(); i > 0; i--) {

if(event.getTime() >= node.getTime()) {

eventList.add(i, event);

break;

} else node = eventList.get(i-2); //i-1 had already been tested

}

/////////////////////////////////////////////////////////////////////////////////////////////////////

//UTILITIES

/////////////////////////////////////////////////////////////////////////////////////////////////////

//Show all events in the eventlist. Used for debug

public void ShowSchedule() {

if(eventList.size() > 0) {

System.out.println("Showing Scheduled Events:");

for (SimEvent event : eventList)

System.out.printf("Time: %s \tEntity:%s \tRoutine: %s\n", event.getTime(), event.getEntity(), event.getRoutine());

} else System.out.println("The Eventlist is Empty!");

}

/////////////////////////////////////////////////////////////////////////////////////////////////////

//MAIN METHOD

/////////////////////////////////////////////////////////////////////////////////////////////////////

public static void main(String[] args) {

//Especifies application look and feel do programa. Do not add code before this statement

try {

// Set System L&F

UIManager.setLookAndFeel(

UIManager.getSystemLookAndFeelClassName()); //Sets look and feel iqual to operation system style

} catch (UnsupportedLookAndFeelException e) {

// handle exception

} catch (ClassNotFoundException e) {

// handle exception

} catch (InstantiationException e) {

// handle exception

} catch (IllegalAccessException e) {

// handle exception

}

new Simulator();

}

/////////////////////////////////////////////////////////////////////////////////////////////////////

//START BUY TICKET

/////////////////////////////////////////////////////////////////////////////////////////////////////

static Random randomTime = new Random();

public void e_startBuyTicket(SimEvent event) {

//activity time in milliseconds

double dt = 1000*(timeToBuyTicket_mean + randomTime.nextGaussian()*timeToBuyTicket_stdDev);

//set ticketmachine in working status

ticketMachine.isWorking = true;

ticketMachine.workTimeCount += dt;

ticketMachine.lastUsedTime = simulator.getTime() + dt;

ticketMachine.status = "In use by the client " + client.getName();

//System.out.println(this + " " + ticketMachine.status);

//change client from waiting for a avaiable ticketmachine to client buying the ticket

client.isWorking = true;

client.workTimeCount += dt;

client.lastUsedTime = simulator.getTime() + dt;

client.status = "Buying Ticket";

//change the picture of the ticketmachine

ticketMachine.updateImage(icons.TICKETMACHINE_BUSY, simulator.getTime(), dt);

//make the clients in the queue to walk a little

for (Client waitingClient : waitingQueue) {

waitingClient.moveTo(queuePositions[waitingQueue.indexOf(waitingClient)], simulator.getTime());

}

//shedule the next event

simulator.Schedule(this, Events.TICKETMACHINE_END_BUY_TICKET, simulator.getTime() + dt);

}

/////////////////////////////////////////////////////////////////////////////////////////////////////

//END BUY TICKET

/////////////////////////////////////////////////////////////////////////////////////////////////////

public void e_endBuyTicket(SimEvent event) {

//change client from buying ticket to client waiting for the meal

client.isWorking = false;

client.status = "Avaiable with a ticket already bought";

//change the ticketMachine status from busy to free

ticketMachine.isWorking = false;

ticketMachine.status = "Avaible and waiting for clients";

//change the picture of the ticketmachine

ticketMachine.updateImage(icons.TICKETMACHINE_FREE, simulator.getTime());

//send the client to queue to receive the meal

client.moveTo( new Position( auxPosition2.getX()-10, auxPosition2.getY() ), simulator.getTime());

Waiter.addClient(client, simulator);

//check if the next activity of sells ticket can starts immediately

if(waitingQueue.size() > 0) {

this.scheduleNextClient(simulator.getTime());

} else {

ticketMachineFree.addLast(this);

client = null; //delete the machine's reference to the its client

}

/**

* @(#)Waiter.java

* Waiter that deliver the meal for the client in the restaurant

import java.util.*;

import javax.swing.JOptionPane;

public class Waiter extends SimEntity {

private final int id; //entity unique identification in this group

static private int count = 0; //total of TicketMachines created

static private LinkedList<Waiter> waiterFree = new LinkedList<Waiter>(); //list of waiters avaiable

static private LinkedList<Client> waitingQueue = new LinkedList<Client>(); //list of client waiting for an avaiable waiter

static private int maxClients = 0; //Max. number of clients waiting for an avaiable waiter

static private double timeToDeliver_mean = 0; //mean time that a waiter spent to deliver the meal

static private double timeToDeliver_stdDev = 0; //an its standart deviation (assuming a normal distribution)

private Waiter waiter = this; //auxiliar variable to make the code more readible

private Client client = null; //reference to the client that is interacting with the waiter

private Position auxPosition1 = null; //individual tickemachine position where the client should be to buy the ticket

private Position auxPosition2 = null; //individual tickemachine position where the client should be to buy the ticket

public String toString() { return "Waiter Nº" + id; } //Override toString method

/////////////////////////////////////////////////////////////////////////////////////////////////

//PROPRIETIES

/////////////////////////////////////////////////////////////////////////////////////////////////

public int getId() { return id; }

static public int getNumberOfEntities() { return count; }

static public int getNumberOfClients() { return waitingQueue.size(); }

static public int getMaxNumberOfClients() { return maxClients; }

static public LinkedList<Waiter> getListOfWaiters() {

return (LinkedList<Waiter>) waiterFree.clone();

}

static public void setTimeToDeliver_mean(double t) {

if(t>0) timeToDeliver_mean = t;

}

static public void setTimeToDeliver_stdDev(double t) {

if(t>0) timeToDeliver_stdDev = t;

}

/////////////////////////////////////////////////////////////////////////////////////////////////

//CONSTRUCTOR

/////////////////////////////////////////////////////////////////////////////////////////////////

public Waiter(Simulator simulator) {

super(simulator); //call the superclass constructor

id = ++count; //entity unique identification in this group

name = "Waiter " + id; //particular name of the entity

desc = "Hired Waiter"; //description of the entity type

icon = icons.WAITER_FREE; //inicial entity image

status = "Ready!"; //inicial status (only for information)

x = 841-id*25; //inicial x coordenate

y = 43; //inicial y coordenate

setStartPosition(x,y); //save the inicial position in the listOfMoves

auxPosition1 = new Position(x, y + 55); //Position where the client should be to receive the meal

auxPosition2 = new Position(x, y + 35); //Position where the client should be to receive the meal

setVisible(); //set the entity to be drawn on the screen

waiterFree.addFirst(this); //set the waiter avaiable for the clients

}

/////////////////////////////////////////////////////////////////////////////////////////////////

//ADD CLIENT TO THE QUEUE

/////////////////////////////////////////////////////////////////////////////////////////////////

//each place position in the waiting queue (max size = 92)

static Position queuePositions[] = {

new Position(780,120), new Position(780,135), new Position(780,150), new Position(780,165), new Position(780,180),

new Position(120,300), new Position(120,285), new Position(120,270), new Position(120,255), new Position(120,240),

new Position(120,225), new Position(120,210),

};

static Random randomWaiter = new Random();

static public void addClient(Client client, Simulator simulator) {

if(waitingQueue.size() < queuePositions.length) { //the client can join the queue

waitingQueue.addLast(client);

if (waitingQueue.size() > maxClients) { //updates max size of clients waiting for the meal

maxClients = waitingQueue.size();

}

client.status = "Waiting in the queue to reveive the meal";

//make the client move throw the line until the last free place in the queue

double dt = 0;

for(int i = queuePositions.length-1; i >= waitingQueue.size()-1; i--) {

client.moveTo(queuePositions[i], simulator.getTime());

}

//checks if the activity of delivery the meal can begin immediately

if(waiterFree.size() > 0) {

Waiter waiter = waiterFree.remove( randomWaiter.nextInt(waiterFree.size()));

waiter.scheduleNextClient(simulator.getTime());

}

} else { //there is no place in the queue

JOptionPane.showMessageDialog(null,

"The waiting queue for the meal got too crowded!" +

"Some clients may be lost."

);

}

/////////////////////////////////////////////////////////////////////////////////////////////////

//SCHEDULE CLIENT /////////////////////////////////////////////////////////////////////////////////////////////////

//since this part of the code was repeated two times, I found interesting to put it in a function for modify only one in place when needed

public void scheduleNextClient(double time) {

this.client = waitingQueue.removeFirst();

double dt = client.moveTo(auxPosition1, time);

dt += client.moveTo(auxPosition2, time + dt);

simulator.Schedule(this, Events.WAITER_START_DELIVERY, time + dt);

}

/////////////////////////////////////////////////////////////////////////////////////////////////

//EVENTS

/////////////////////////////////////////////////////////////////////////////////////////////////

//interface with simulator

public void Execute(SimEvent event) {

switch(event.getRoutine()) {

case WAITER_START_DELIVERY : e_startDelivery(event);

break;

case WAITER_END_DELIVERY : e_endDelivery(event);

break;

}

/////////////////////////////////////////////////////////////////////////////////////////////////

//START DELIVERY /////////////////////////////////////////////////////////////////////////////////////////////////

static Random randomTime = new Random();

public void e_startDelivery(SimEvent event) {

//activity time in milliseconds

double dt = 1000*(timeToDeliver_mean + randomTime.nextGaussian()*timeToDeliver_stdDev);

//set waiter in working status

waiter.isWorking = true;

waiter.workTimeCount += dt;

waiter.lastUsedTime = simulator.getTime() + dt;

waiter.status = "Attending the client " + client.getName();

//changes client from waiting for a meal to client receiving the meal

client.isWorking = true;

client.workTimeCount += dt;

client.lastUsedTime = simulator.getTime() + dt;

client.status = "Receiving the meal";

//change the picture of the waiter

waiter.updateImage(icons.WAITER_BUSY, simulator.getTime(), dt);

//make the clients in the queue to walk a little

for (Client waitingClient : waitingQueue) {

waitingClient.moveTo(queuePositions[waitingQueue.indexOf(waitingClient)], simulator.getTime());

}

//shedule the next event

simulator.Schedule(this, Events.WAITER_END_DELIVERY, simulator.getTime() + dt);

}

/////////////////////////////////////////////////////////////////////////////////////////////////

//END DELIVERY

/////////////////////////////////////////////////////////////////////////////////////////////////

public void e_endDelivery(SimEvent event) {

//changes client from receiving the meal to client eating the meal

client.isWorking = false;

client.status = "Walking to the table";

//changes the waiter status from busy to free

waiter.isWorking = false;

waiter.status = "Avaible and waiting for clients";

//change the picture of the waiter

waiter.updateImage(icons.WAITER_FREE, simulator.getTime());

//change the picture of the client

client.moveWithMealTo(new Position(auxPosition2.getX(), auxPosition2.getY()+20 ), simulator.getTime());

Table.addClient(client, simulator);

//check if the next activity of deliver the meal can starts immediately

if(waitingQueue.size() > 0) {

this.scheduleNextClient(simulator.getTime());

} else {

waiterFree.addLast(this);

client = null; //delete the machine's reference to the its client

}

Um comentário:

Empilhashop disse...: Boa Tarde. Parabéns pelo Blog é inteligente e de muito bom gosto. Caso possua empilhadeiras no estado ainda a serem reformadas entre em contato. empilhashop.com.br (Empilhadeiras usadas) falecom@empilhashop.com.br Muito Obrigado. EmpilhaShop; 7 de junho de 2013 às 02:13

Postar um comentário

Introdução

O Sistema Toyota de Produção

Eliminação dos Desperdícios e o Princípio do Não-Custo

Autonomação

Padronização das Operações

Eliminação da Causa do Problema

Círculo de Controle da Qualidade

Melhoria Contínua

Manutenção Produtiva Total

Troca Rápida de Ferramentas

Just-in-Time

Vantagens e Limitações da Simulação Visual Interativa

Características Funcionais do Simulador

Simplificações e Considerações na Construção do Simulador

Configuração e Principais Variáveis do Simulador

Simulação no Modo da Próxima Atividade

Simulação no Modo do Circuito Fixo

Comentário acerca das variáveis dos dois métodos

Resultados Obtidos Através do Simulador

Comparação do Empilhador com o Mizusumashi

Relatório da Simulação Utilizando o Empilhador

Relatório da Simulação Utilizando o Mizusumashi

Empilhador x Mizusumashi

Conclusões e perspectivas de trabalho futuro

Referências e Bibliografia

Anexo A - Ficha de Trabalho Padrão

Anexo B - Gráficos com os Resultados da Simulação

Anexo C - Fluxogramas

Anexo D - Exemplos Reais dos Elementos Citados no Texto

Anexo E - SimCantina: Projeto Base Antes de Iniciar o Pull Simulator

Um comentário:

Twitter

Atalho do Facebook

Conteúdo

LuizFreire.Com