AUTOMAÇÃO DE TAREFAS REPETITIVAS UM ESTUDO DE CASO SOBRE A APLICAÇÃO DE TÉCNICAS LEAN

Gostaria de compartilhar um artigo de um colega sobre um case de automação de tarefas repetitivas com técnicas de Lean:

 

Daniel Gonçalves Jacobsen [1]

Professor orientador:
Clence Mendes Cardoso [2]<![endif]>

Pós-Graduação em Engenharia de Software com Métodos
Ágeis – Instituto de Gestão em Tecnologia da Informação (IGTI) – Belo Horizonte
– MG – Brasil

 

 

RESUMO

Atividades
repetitivas geram desgastes físicos e mentais em todo tipo de trabalho. Além
disso, comprometem a sua correta execução, quando realizadas manualmente.
Diversas ações podem ser realizadas para melhorar esse cenário. Este trabalho
tem por objetivo a aplicação de técnicas da filosofia Lean no atendimento de uma tarefa
repetitiva realizada em sistemas de computador. O uso das técnicas, auxiliou na
automação de parte das atividades da tarefa, diminuindo o tempo que os
executores despendem no seu atendimento e garantindo a correta execução da mesma.
Além disso, a utilização das técnicas abordadas neste estudo se mostrou um bom
modelo para aplicação de melhorias no atendimento de outras tarefas.

 

Palavras-chave: Filosofia Lean. Atividades Repetitivas. Kaizen. Jidoka. Gemba Gembutsu.

 

ABSTRACT

Repetitive
activities generate physical and mental wear in all kinds of work. Besides that,
they compromise their correct execution when are accomplished manually. Several
actions can be taken to improve this scenario. This work aims at applying
techniques of Lean philosophy in the accomplishment of a repetitive task
performed on computer systems. The use of techniques helped in the automation
of the task activities, reducing the time that the executors spend in your execution
and ensuring the correct realization. In addition, the use of the techniques
covered in this study proved to be a good model for implementing improvements
in the accomplishment of other tasks.

 

Keywords: Lean philosophy. Repetitive Activities. Kaizen. Jidoka. Gemba Gembutsu.

 

<!1.     INTRODUÇÃO

Atividades repetitivas
desgastam qualquer tipo de pessoa. Assim como trabalhadores que realizam
serviços braçais e repetitivos terminam o dia cansados, aqueles que trabalham
em frente ao computador também sofrem os efeitos do desgaste cerebral. Estudos
indicam que o desgaste mental – comumente identificado em trabalhadores que
exercem suas atividades junto ao computador – é tão ou mais grave que o
desgaste físico (BUENO, 2016).

Apesar da evolução
tecnológica e da utilização de programas de computador no auxílio da execução
de diversas atividades, muitas ações manuais ainda são realizadas no computador,
como cadastros, envio de e-mail, entre outros. Grande parte destas ações podem
ser automatizadas. Contudo, a automação requer certa organização e controle,
como a identificação das ações a serem automatizadas, a documentação, entre
outros.

Diante destas
colocações, o objetivo desse trabalho é aplicar algumas técnicas da filosofia Lean em uma
tarefa que é realizada manualmente em sistemas computacionais, visando eliminar
desperdícios e agregar valor ao seu atendimento.

Com este intuito, este trabalho está
organizado da seguinte maneira: além deste capítulo de introdução, este artigo
é composto por mais quatro capítulos. O capítulo 2 descreve a metodologia
empregada. O capítulo 3 contém o referencial teórico, onde foi realizado um
estudo na bibliografia existente sobre os primórdios da filosofia Lean, destacando
as técnicas que foram adotadas para o estudo de caso. Também são abordadas no
capítulo 3, as ferramentas utilizadas na automatização. No capítulo 4, está
descrito o estudo de caso realizado e como as técnicas foram colocadas em
prática. O capítulo 5 aborda a conclusão com os resultados obtidos.

 

2. METODOLOGIA

A metodologia empregada neste artigo envolveu uma pesquisa do tipo exploratória,
com levantamento bibliográfico para embasar o conceito da filosofia Lean e as técnicas
utilizadas no estudo de caso. Também foi realizado um estudo de caso em uma
equipe que trabalha com o atendimento de tarefas que, em sua maioria, são
realizadas com a utilização de sistemas computacionais. No estudo de caso,
parte de uma tarefa foi automatizada utilizando a aplicação dessas técnicas.

Como o intuito do trabalho é solucionar um problema através da aplicação do
conhecimento adquirido no levantamento bibliográfico, a finalidade é a pesquisa
aplicada. O trabalho utiliza as abordagens quantitativa e qualitativa para
descrever os resultados.

 

3. REFERENCIAL TEÓRICO

Este capítulo aborda aspectos referentes à bibliografia existente sobre os assuntos relacionados ao tema deste trabalho. Estes assuntos englobam as técnicas da filosofia Lean que foram escolhidas para
realização do estudo de caso, assim como as ferramentas utilizadas na automação.

Cabe salientar que existem diversas vertentes
da filosofia Lean,
como Lean Office, Lean TI e Lean
para área da saúde. Cada uma dessas vertentes segue uma certa interpretação da
origem da filosofia. Contudo, nenhuma dessas vertentes foi seguida. Este
trabalho buscou na origem da filosofia Lean o que mais se adequa ao interesse do mesmo. Sendo
assim, a filosofia Lean
é descrita na sua essência, assim como cada técnica selecionadas.

 

3.1 FILOSOFIA LEAN

A filosofia Lean está muito difundida em todo
o mundo, nas mais diversas áreas como saúde, administração e tecnologia da
informação (TI). No entanto, essa filosofia tem sua origem no setor automobilístico.
Mais precisamente, em um modelo corporativo conhecido como Sistema Toyota de
Produção (STP), cujo conceito básico é a redução do custo pela eliminação
sumária dos desperdícios.

Em 1935, Taiichi Ohno, um dos principais precursores e propagadores do STP,
foi incumbido de aperfeiçoar o processo de produção de uma das fábricas da
Toyota, para aumentar a produtividade da empresa. Tendo como exemplo o processo
de produção da Ford, Ohno precisava igualar a
quantidade de carros produzidos, tendo diversas limitações, como o compromisso
de manter o emprego dos funcionários e a necessidade de produzir vários modelos
na mesma fábrica.

Visitas a outras fábricas originaram o
aprendizado que resultou no STP. “Nós
aprendemos muito comparando os sistemas de produção utilizados por empresas
diferentes. ” (FUJIMOTO, 2011, p.25). A partir disso, o STP foi
desenvolvido e aprimorado com a experiência e colaboração de diversas pessoas. Essas
pessoas tiveram a genialidade de identificar diversas técnicas, através da
troca de experiências entre as fábricas de automóveis e de outros produtos da
época.

O resultado dessas experiências foi a junção de todas as lições aprendidas, em
prol desse sistema de produção, que vem sendo adotado com o nome de Produção Lean ou Produção
Enxuta (FUJIMOTO, 2011). Seu legado é uma gama de princípios, técnicas e
ferramentas que cada vez mais são utilizadas nas mais diversas áreas, para
fazer cada vez mais com menos esforço humano, menos equipamento, menos tempo e
menos espaço (WOMACK, 2003).

 

3.2 KAIZEN

Kaizen é um termo japonês que significa “mudança
para melhor”, podendo também ser traduzido como “melhoria contínua”. É um termo
utilizado no Japão muito além da área de produção, abrangendo âmbito
profissional, familiar, pessoal e social.

“A essência do kaizen
é simples e direta: kaizen significa melhoramento.
Mais ainda, kaizen significa contínuo melhoramento,
envolvendo a todos, inclusive gerentes e operários. A filosofia do kaizen afirma que o nosso modo de vida – seja no trabalho,
na sociedade ou em casa – merece ser constantemente melhorado” (IMAI, 1994, p.3)

O kaizen é uma forma de pensar, onde se acredita que sempre
deve ter uma maneira melhor de realizar algo. É premissa do kaizen maximizar a produtividade
e a rentabilidade, sem implicar em significativo aumento de custo.

O kaizen deve ser realizado com a participação de todos os
envolvidos, buscando identificar e implementar as mudanças que possam dar
resultados satisfatórios. Após a realização das mudanças deve ser realizado o
devido acompanhamento para validar o resultado. Pressupondo que sempre teremos
algo a melhorar, é importante que periodicamente sejam realizadas análises para
identificação das mudanças que devem ser realizadas (IMAI, 1994).

A implantação do kaizen requer a pressuposição de
que as coisas estão bagunçadas, para que melhorias possam ser imaginadas e
discutidas entre os envolvidos. Taiichi Ohno afirmava que “O kaizen envolve mudar o modo como as coisas são. Se você
supor que as coisas estão certas do modo como estão, não poderá implantar o kaizen. Por isso, mude alguma coisa! ” (FUJIMOTO, 2011,
p.64).

 

3.3 GEMBA GEMBUTSU

Gemba gembutsu significa, segundo palavras do próprio Taiichi Ohno, o “compromisso de ver as coisas (gembutsu) em primeiro lugar como são de fato no ambiente de
trabalho (gemba) ” (FUJIMOTO, 2011, p.59). Numa
tradução simples, significa o compromisso de entender como as coisas realmente
acontecem no local de trabalho. No desenvolvimento do processo de produção da
Toyota isso foi tratado como essencial e utilizado também para motivar os
trabalhadores a pensarem sobre os procedimentos que realizavam e o que poderiam
fazer para melhorá-los.

Segundo essa técnica, deve-se dar maior
atenção ao local de trabalho e a forma como os procedimentos são realizados, ao
invés de atentar somente para números e dados estatísticos, que geralmente são
analisados em um escritório, distante de onde as coisas realmente acontecem. As
melhorias não devem se basear nos números, mas sim na prática do dia a dia dos
seus executores. As métricas devem ser utilizadas ao final do processo de
melhoria para corroborar os resultados das modificações.

 

3.4 TRABALHO PADRONIZADO

A padronização do trabalho foi uma das
primeiras iniciativas introduzidas por Taiichi Ohno ao STP. Como o processo de produção da sua fábrica era
muito artesanal, as desculpas eram fáceis de serem encontradas e utilizadas
pelos artesões para explicar atrasos e defeitos.

O detalhamento das atividades a serem
realizadas e a divulgação dos procedimentos em painéis, junto ao local de
trabalho, ajudaram os trabalhadores na execução de suas tarefas. Mais do que
isso, os painéis ajudaram os supervisores a identificar se os trabalhadores
estavam realizando corretamente as atividades, diminuindo os atrasos e defeitos.

Posteriormente a criação destes padrões, os
envolvidos foram instigados a indicar melhorias que acreditavam ser possíveis
de serem implantadas. Além disso, segundo as experiências realizadas no
desenvolvimento do STP, a padronização deve ser realizada adotando-se um padrão
simples, que não tome muito tempo para ser criado. A padronização também deve,
preferencialmente, ser determinada no local de trabalho (gemba), para então ser melhorada
(kaizen)
com a colaboração de todos os envolvidos (FUJIMOTO, 2011).

 

 

3.5 JIDOKA

Jidoka significa automação em japonês. Mas a palavra
é utilizada também para se referir a expressão “ninben no aru jidoka”, que pode ser traduzida como
automação com um toque humano – automação de grande parte do trabalho com o
restante sendo realizado manualmente – ou como a arte de dotar inteligência
humana às máquinas.

O conceito surgiu quando Sakichi
Toyoda, fundador do Grupo Toyota, criou uma máquina
de tear capaz de parar automaticamente ao identificar falhas ou ao final da
produção programada. Isto permitiu que um trabalhador supervisionasse várias
máquinas ao mesmo tempo.

Jidoka está também relacionado com autonomia. A
ideia é que a máquina tenha autonomia na execução de tarefas que tomam tempo e
concentração humana (OHNO, 1997).

 

3.6 FERRAMENTAS DE AUTOMATIZAÇÃO

Duas ferramentas que já vinham sendo
utilizadas na equipe para outras atividades foram adotadas para a implementação
das automatizações.

 

3.6.1 Selenium

O Selenium (http://www.seleniumhq.org/) é uma ferramenta de código
aberto muito utilizada para automação de testes de software. A ferramenta possibilita que sejam gravadas as ações
realizadas no navegador de internet, através
de um Ambiente de Desenvolvimento Integrado (do inglês Integrated Development Environment
– IDE). Posteriormente, as ações podem ser executadas automaticamente no
computador.

Existe ainda uma Interface de Programação de
Aplicação (do inglês Application Programming
Interface – API) que permite a codificação das ações a serem executadas em
diferentes linguagens de programação, como Java, C#, Ruby, Perl, PHP e Groovy.

O Selenium foi criado em 2004 pela ThoughtWorks® (https://www.thoughtworks.com) e atualmente é mantido pela
organização sem fins lucrativos Software Freedom Conservancy (https://sfconservancy.org/)
(BRANAS, 2016).

 

3.6.2 Jenkins

O Jenkins (https://jenkins.io/) também é uma ferramenta de
código aberto. Ela é muito utilizada na prática de Integração Contínua no
desenvolvimento de software. A ferramenta viabiliza, por exemplo, a identificação
de alterações no código fonte e, a partir dessa identificação, inicializa ações
previamente configuradas como a inspeção e compilação do código. É possível
também realizar validações das execuções e gerar alertas dos resultados através
do envio de e-mail.

O Jenkins foi criado a partir de 2006, originalmente como
Hudson. O projeto Jenkins vem sendo desenvolvido por
um grupo de programadores e usuários, e é afiliado a Sofware in the Public Interest: uma organização sem fins lucrativos que
oferece representação legal e outras necessidades para a execução de um projeto
de software de código aberto (http://www.spi-inc.org/).

 

 

 

4. ESTUDO DE CASO

Este capítulo mostra como as técnicas foram
colocadas em prática em um estudo de caso. Primeiramente, estão detalhadas a
equipe onde o estudo de caso foi realizado e a tarefa escolhida para aplicação
das técnicas. Posterior a isso, estão descritas as melhorias implantadas no
processo de execução da tarefa, relacionando cada uma das técnicas utilizadas.

 

4.1 APRESENTAÇÃO DA EQUIPE

A equipe objeto do estudo de caso é
responsável pelo controle das mudanças a serem instaladas em produção,
englobando a Gestão da Qualidade, da área de TI de uma instituição de crédito
cooperativo. Dentro da equipe, os profissionais estão divididos conforme suas
especializações, realizando diferentes tarefas que requerem ações em diversos
sistemas computacionais.

 

4.2 TAREFA A SER MELHORADA

Uma tarefa é comum aos membros da equipe: é
necessário marcar as horas trabalhadas em um sistema de controle de projetos.
As tarefas realizadas em prol de algum projeto da empresa precisam ser
registradas no Sistema de Gestão de Projetos (SGP). Esta tarefa é uma das que
mais toma tempo e disposição dos membros da equipe.

Para que as horas possam ser cadastradas no
SGP, o líder do projeto precisa acessar o sistema e liberar a alocação para
cada um dos projetos em que foram realizados os atendimentos. Mensalmente, são
realizados em média 150 atendimentos por cada membro da equipe.

Os membros da equipe contatam os líderes de
projeto por diversas vezes, até que estes liberem a alocação das horas no
sistema. Em alguns casos, as solicitações deixam de ser realizadas por falta de
retorno dos líderes de projeto ou pela falta de insistência dos membros da
equipe nos contatos com os líderes de projeto.

 

4.3
PADRONIZAÇÃO DO TRABALHO + GEMBA GEMBUTSU

A primeira ação do estudo de caso foi a
padronização do trabalho realizado na tarefa. A técnica da padronização foi utilizada
em conjunto com a técnica gemba gembutsu. Todo o entendimento com os envolvidos foi
realizado nas suas próprias estações de trabalho, acompanhando a execução das
atividades da tarefa. Este compromisso com o local de trabalho, facilitou muito
o entendimento e a padronização, visto que cada membro da equipe executava a
tarefa com algumas particularidades.

Após algumas conversas, foi criado um padrão
inicial, que representa simplificadamente as atividades da tarefa. A técnica da
padronização do trabalho, preconizada pelo STP, utiliza-se da criação do
Diagrama do Trabalho Padronizado. Esse diagrama serve, dentre outras coisas
para que os executores acompanhem e verifiquem se as atividades estão sendo
realizadas corretamente, inclusive no tempo adequado. Tais funções são muito
úteis em um ambiente de produção industrial.

Contudo, como o ambiente desse estudo de caso
difere em alguns aspectos de um ambiente industrial, não houve a necessidade de
ter todas as informações do diagrama. Para o estudo de caso foi utilizado um desenho
para mapeamento dos processos, por achar o mais adequado para representar o
trabalho atual no fluxo objeto de estudo. Sua função é mapear o conjunto de
processos necessários para a execução do cenário, objeto do estudo, de forma
que todos os envolvidos compreendam e possam pensar em melhorias. A Figura 1
mostra o mapeamento dos processos, criado logo após as primeiras conversas com
os envolvidos.

 

Figura 1 – Mapeamento
dos processos para alocação de horas no SGP. Fonte: Autor, 2016

 

 

A seguir estão descritas as definições de cada
atividade:

1.      Realizar
atendimento em projeto – os membros da equipe realizam diversos tipos de
atendimentos relacionados aos projetos da organização;

2.      Registrar
atendimento em planilha pessoal – como o restante do processo toma um certo
tempo e os atendimentos geralmente são rápidos (30 minutos em média), os
atendimentos são acumulados em uma planilha pessoal;

3.      Registrar
os atendimentos no SGP? – o profissional decide se é o
momento certo para continuar com o processo, levando em conta a quantidade de
atendimentos ainda não alocados e as demais tarefas que este tem a fazer. Caso
decida não continuar neste momento, o processo passa para decisão “Acabou o expediente?
” (10). Caso decida que é o momento certo, passa para o próximo passo que é
realizado para cada um dos atendimentos registrados na planilha pessoal;

4.      Selecionar
atendimento – o profissional seleciona um dos atendimentos da sua planilha
pessoal para registrar o atendimento no SGP;

5.      Projeto
liberado para alocação? – é necessário verificar se o
projeto do atendimento realizado encontra-se disponível para alocação no SGP.
Quando está disponível, a alocação das horas pode ser realizada. Do contrário, é
necessário enviar um e-mail solicitando a liberação ao líder do projeto;

6.      Alocar
as horas no SGP – se o projeto estiver disponível para alocação, o tempo
dispendido no atendimento é registrado no SGP;

7.      Solicitar
liberação ao líder do projeto – se o projeto não estiver disponível para
alocação no SGP é necessário entrar em contato com o líder do projeto (e-mail),
solicitando a disponibilização;

8.      Registrar
horas alocadas na planilha pessoal – o atendimento alocado no SGP precisa ser
marcado na planilha pessoal, para não ser registrado mais de uma vez no SGP;

9.    Restam
atendimentos a registrar? – caso existam outros
atendimentos a serem alocados, retorna para a atividade “Selecionar
atendimento” (4). Caso contrário, passa para a decisão “Acabou o expediente? ”
(10);

10.  Acabou
o expediente? – caso o expediente ainda não tenha
acabado, retorna para a atividade “Realizar atendimento em projeto” (1). Ao
final do expediente, vai para o fim;

 

 

4.4 O PRIMEIRO KAIZEN

Com a padronização do trabalho, uma visão de
todas as ações realizadas pelos membros da equipe foi criada, possibilitando
que fossem endereçadas ideias para modificações deste padrão. As ideias foram
discutidas entre os membros no local de trabalho, a fim de facilitar o
entendimento.

Uma dessas ideias foi a adaptação da
ferramenta que vinha sendo utilizada na criação de testes automatizados. O Selenium foi
utilizado para automatizar as etapas realizadas no SGP. Esta ideia foi bem
aceita e possibilitou a implementação da técnica jidoka, preconizada pelo STP.

Para esta primeira modificação, foi utilizado
como premissa a escolha do que seria de fácil implementação e que traria um
retorno interessante para os envolvidos na execução da tarefa. E a primeira
melhoria realizada foi a automação das atividades “Selecionar atendimento”,
“Projeto liberado para alocação? ”, “Alocar as horas no SGP” e “Restam
atividades a registrar? ” (respectivamente, 4, 5, 6 e
9). As quatro atividades eram realizadas manualmente e por diversas vezes para
cada atendimento da planilha pessoal. No mapeamento (Figura 2), as cores foram
modificadas para verde, a fim de indicar que deixaram de ser realizadas
manualmente.

Para viabilizar esta automatização, foi
necessário criar a atividade “Importar planilha pessoal” (3.1). Nessa atividade
o colaborador executa um programa que foi desenvolvido para o estudo de caso.
Este programa importa a planilha pessoal para uma tabela, em uma base de dados.

Além de executar as atividades para todos
atendimentos importados da planilha pessoal, a automatização também identifica
os atendimentos que não foram alocados por falta de liberação. Por isso, foi
criada a atividade “Registrar projeto não liberado” (5.1). Para cada
atendimento que não foi possível alocar no SGP por falta de liberação do líder
do projeto, um registro é inserido em uma tabela da base de dados.

Com estas mudanças, as atividades automatizadas
passaram a varrer todos os atendimentos contidos na tabela criada, cujo status
de alocação no SGP estava como pendente. A atividade “Registrar horas alocadas
na planilha pessoal” (8) foi extinta, pois a planilha passou a ser importada
para a base de dados e controlada pela própria automatização.

Já a atividade “Solicitar liberação ao líder
do projeto” (7), que antes era executada após a atividade “Projeto liberado
para alocação? ” (5), passou a ser executada após o ciclo automatizado, quando
a resposta da atividade “Restam atendimentos a registrar” (9), for negativa.
Antes dessa mudança a atividade era executada a cada tentativa de alocar as
horas de um atendimento contido na planilha pessoal. Embora a atividade continue
sendo realizada manualmente, todos os envios de e-mail passaram a ser
realizados na mesma atividade. Por conta disso, a atividade foi renomeada para
“Solicitar liberações aos líderes de projeto” (7).

Após o primeiro kaizen, o mapeamento dos
processos ficou maior (Figura 2). Contudo, boa parte das atividades deixaram de
ser realizadas manualmente, deixando algum tempo livre para que outras
atividades fossem realizadas.

2 – Mapeamento
dos processos após o primeiro kaizen. Fonte:
Autor, 2016

 

 

4.5 O SEGUNDO KAIZEN

Seguindo a premissa que periodicamente uma
nova análise deve ser realizada, adotou-se o período de dois meses entre cada
análise para identificação de novas modificações a serem implementadas. Este
período também foi importante para que as mudanças recentes fossem devidamente
avaliadas, ajustadas e validadas.

Deixar de realizar manualmente várias
atividades, já retirou uma boa carga de trabalho dos envolvidos. Contudo, ainda
era necessário realizar a etapa “Solicitar liberações aos líderes de projeto”
(7), para todos os projetos que não estavam disponíveis para alocação no SGP.
Vale lembrar que, como são realizados em média 150 atendimentos, e que estes
necessitam passar pelas atividades ao menos duas vezes, ainda era necessário
contatar por e-mail os líderes de projeto ao menos 300 vezes por mês. Ou seja,
ainda se tinha uma atividade realizada repetidamente.

A segunda melhoria implementada foi para que
esta etapa fosse realizada por outra ação automatizada. Através de ajustes na
funcionalidade de automação realizada anteriormente, passou a ser registrada na
base de dados uma indicação para cada atendimento cujo projeto não estava
liberado para alocação no SGP.

O Jenkins, que também era utilizado na equipe para a
Integração Contínua, foi ajustado para configuração de uma rotina de
verificação dessa tabela e envio de e-mail padronizado para cada solicitação a
ser realizada. Após o envio das mensagens, os registros são apagados.

A Figura 3 mostra que o mapeamento ficou com a
atividade “Solicitar liberações aos líderes de projeto” (7) automatizada. Esta
melhoria facilitou ainda mais a tarefa de alocação das horas no SGP. Com esta
configuração, os colaboradores simplesmente importam sua planilha pessoal e
inicializam o ciclo automatizado. As demais atividades estão sendo realizadas
pelo computador.

Figura 3 – Mapeamento
dos processos após o segundo kaizen. Fonte:
Autor, 2016

 

5. CONCLUSÃO

A utilização das técnicas Lean possibilitou a implementação
de melhorias importantes para a realização da tarefa objeto deste estudo de
caso. As mudanças já são utilizadas por três integrantes da equipe que, cada
vez mais, destacam ganhos quando o comparam com o processo manual ainda
utilizado pelo restante da equipe.

Para se ter uma ideia, o tempo médio de
execução da tarefa baixou de dez para três horas por mês. Mensalmente,
praticamente um dia de trabalho foi liberado para cada um dos três
colaboradores que já estão utilizando as melhorias. São 21 horas de trabalho da
equipe, que estão sendo utilizadas em outras tarefas e atividades como estudar
e discutir possíveis melhorias para esta e outras tarefas. A diminuição do
tempo despendido corrobora o atingimento do objetivo de eliminação de
desperdício.

Muitas horas deixavam de ser alocadas por
conta da desistência em solicitar a liberação para os líderes de projeto
diversas vezes para o mesmo atendimento. Com as automações, todas as solicitações,
junto aos líderes de projeto, passaram a ser realizadas, independentemente da
quantidade de vezes que já foram enviadas. Isso comprovou o atingimento do
objetivo de agregação de valor ao atendimento da tarefa.

Devido ao resultado do trabalho, outras
tarefas já estão sendo cogitadas para passarem pelo mesmo processo de melhoria.
Inclusive, utilizando este estudo de caso como estrutura (framework) para o processo.

 

REFERENCIAS

BUENO, Chris. “Esgotamento mental não é frescura;
saiba como combater o problema”. Portal UOL Notícias Ciência e Saúde.
Disponível em: < http://noticias.uol.com.br/saude/ultimas-noticias/redacao/2013/05/31/esgotamento-mental-pode-causar-doencas-serias-avisam-medicos.htm#fotoNav=5&gt;.
Acessado em: 14 de junho de 2016.

BRANAS, Bruno. “Selenium WebDriver”. Revista Java Magazine Digital, Rio de Janeiro,
Edição 113. Disponível em:
<http://www.devmedia.com.br/selenium-webdriver-revista-java-magazine-113/27357&gt;.
Acessado em: 01 de abril de 2016.

FUJIMOTO,
Takahiro; SHIMOKAWA, Koichi. “O Nascimento do Lean – Conversas com Taiichi Ohno, Eiji Toyoda
e outras pessoas que deram forma ao modelo Toyota de gestão”. 1. Ed. Porto
Alegre: Editora Bookman, 2011. 296p.

IMAI, Masaaki. “Kaizen: A estratégia para o sucesso competitivo”. Edição 6.
São Paulo: Instituto IMAM, 1994. 236p.

OHNO, Taiichi. “O Sistema
Toyota de Produção: além da produção em larga escala”. 1. Ed. Porto Alegre:
Editora Bookman, 1997. 152p.

WOMACK, James P.; JONES, Daniel T. “A Mentalidade
Enxuta nas Empresas Lean Thinking:
Elimine o Desperdício e Crie Riqueza”. Edição 5. Rio de Janeiro: Editora
Campus, 2003. 408p.

 

 

[1] Pós graduando
do Curso de Engenharia de Software com Métodos Ágeis do Instituto de Gestão em
Tecnologia da Informação (IGTI) – d@flete.com.br.

[2] Orientador do IGTI, Gerente de
Projetos, pós-graduado em Arquitetura de Software e Análise de Sistemas e
Bacharel em Ciência da Computação – clence@gmail.com.