O complicado dos “profissionais muito técnicos” é que abraçam os frameworks e melhores práticas sem refletirem a respeito. Então temos professores e consultores falando coisas que, de certa forma, são inconciliáveis.
E no caso em questão, o ChatGPT concorda comigo (grandes b* diria um amigo: se o sujeito precisa se apoiar em inteligência artificial é provavelmente por que a natural ele não tem).
Mas o citei por que exatamente os profissionais técnicos endeusam certas coisas enxergando somente seus lados positivos (e esquecendo os negativos).
OK, antes vamos a uma introdução
Não sou especialista em nenhuma das duas temáticas. Nem nessa “Melhores Práticas”, tampouco no Pensamento Enxuto (seja na sua origem japonesa quanto na versão americanizada).
Mas lendo um livro bateu-me um conflito pessoal.
O título dele é A máquina que mudou o mundo de James Womack, Daniel Jones e Daniel Roos.
Os três autores faziam parte do International Motor Vehicle Program, estudo da indústria automobilística mundial do MIT, que analisou como a “produção enxuta” esculhambou o mundo de fabricação de automóveis.
Resumo da ópera: os japoneses da Toyota fuderam arrasaram com a indústria norte-americana de automóveis, leia-se Ford, GM e, de arrasto, a europeia — Renault, Citroen, Peugeot, Volvo etc. e etc.
Além de produzirem carros mais baratos, tinham qualidade superior.
No foco dessa mudança, a decisão de custos sempre declinantes, ausência de itens defeituosos, nenhum estoque e uma miríade de novos produtos.
E é sobre a “ausência de itens defeituosos” que desejo discutir essa diferença conceitual entre ITIL e Lean (Pensamento Enxuto).
Gerenciamento de Problemas
Gerenciamento de Problemas é um modo de proceder que existe nas Melhores Práticas para que os problemas surgidos durante a operação sejam trabalhados mais tarde, de tal forma a não parar a operação.
Ela envolve a análise e solução de problemas em uma abordagem por etapas, que pode levar tempo e adiar a solução deles. Por isso existe a orientação de associar incidentes a problemas e tocar o barco, resolvendo os primeiros com gambiarras, soluções de contorno e tal.
Eu perguntei a um amigo se o Gerenciamento de Problemas não seria incompatível com o Sistema Enxuto, em especial na questão de parar a operação diante de uma falha (que veremos mais adiante no tópico Jidoka).
Ele, poderoso e estudioso (dos bons) de Melhores Práticas e outros frameworks, disse:
A minha resposta pronta seria que as práticas de gestão de incidentes e problemas não são lineares, ou seja, você não é obrigado a fazer uma coisa e depois a outra. Na teoria, enquanto se aplica uma solução de contorno para a linha de montagem continuar, já está sendo feita uma avaliação da causa raiz para encontrar uma solução definitiva.
Por que veja… Não dá pra comparar um incidente numa linha de montagem com um incidente de TI (alguns, pelo menos). Você pode ter uma interrupção na linha de montagem de um Corolla, numa fábrica específica, que pode atrasar em algumas horas a entrega desses carros para as revendedoras.
Mas imagina um incidente numa operadora de cartão que impede qualquer pessoa em São Paulo de comprar usando a bandeira Mastercard? Quem seria o corajoso que permitiria que nada fosse feito enquanto não encontrarem a causa raiz de tal problema?
E sou obrigado a concordar com ele, exceto se eu não pesquisasse ainda mais a respeito.
(Se bem que o negócio dele não é fabricação de automóveis, caso contrário, daria mais importância à falha na produção do veículo do que no sistema da operadora, haha).
Pensamento enxuto – o conceito de Jidoka
Jidoka é uma expressão em japonês. Trata-se de uma maneira de proteger a empresa contra a entrega de produtos de baixa qualidade ou defeituosos ao seu consumidor.
Já ouviu falar da “Corda Andon”? Significa que se eu encontrar um problema na linha de produção de um Corolla, como diz meu amigo, eu a puxo e paro tudo!!!
E desce a fábrica toda (ou representantes, inclusive fornecedores) pra saber o que aconteceu. E começa o uso do famoso Os cincos porquês para identificar a causa raiz do problema.
Ali, na hora! Sem pedalar para outra equipe ou mais tarde.
Com isso o inspetor de qualidade já era. Quanta gente aí na área de software e na de tecnologia os têm disfarçados de “equipe de testagem”, “equipe de qualidade”, hein?
Aqui a qualidade é checada pelo próprio time de operação/produção. E resolvida por ele com uma mão de todos os outros departamentos.
Vejamos o que o Alex Novkov pensa sobre parar ou não a operação no artigo Stop the Line: No Compromise on Quality.
Riscos de parar tudo
1) Perda de receita
O risco óbvio de “parar a linha” (a expressão vem de linha de produção, mas hoje basta trocar linha por operação e já sabe do que se trata) é que, por algum tempo, a empresa não produz ou entrega o serviço. Quando a produção é interrompida, gasta sem ganhar nada. É difícil, como diz meu amigo, alguma empresa se dar ao luxo de permanecer nesse estado por muito tempo.
2) Prazos Perdidos
Aqui rola a perda de prazos prometidos a clientes e parceiros (quebra de SLA’s etc.). Novamente, dependendo da empresa ou do setor, isso representa um risco enorme nas futuras relações comerciais e compromete contratos.
3) Fornecimento instável
Interromper a produção significa que seu produto não tem fornecimento consistente para os clientes. Isso os desaponta e, diachos, cria oportunidades para os concorrentes. Quem precisa do seu produto agora fica tentada a buscar noutro lugar e… Adiós cliente!
Para algumas empresas e indústrias, pode haver ainda mais riscos.
Talvez a tecnologia não seja rápida e fácil de parar e reiniciar ou as janelas de entrega sejam apertadas. Se tiver que pegar um voo noturno, fazer uma entrega no FedEx ou ter um produto nas lojas para a Black Friday, um atraso de alguns minutos pode custar dias ou semanas de consequências negativas.
Benefícios de “Parar a Linha”
No entanto, como Taiichi Ohno — o papis do Sistema Toyota — provou, há vantagens definitivas em adotar procedimentos de parada de produção:
1) Qualidade Melhorada
Obviamente, o benefício óbvio é que você identifica problemas de qualidade e os corrige antes de enviar o produto. Isso resulta em melhores produtos e maior satisfação do cliente.
2) Redução do tempo gasto no controle de qualidade
Seja qual for o mecanismo de controle de qualidade para o seu produto ou serviço, entregar com maior qualidade, para começar, acelera o processo.
3) Melhoria de Processos
Erros são identificados e corrigidos mais cedo para que menos deles sejam cometidos em geral.
4) Maior engajamento dos funcionários
Quando os funcionários se sentem confiantes e pessoalmente capacitados para estarem atentos à qualidade do produto, se tornam mais responsáveis e profundamente engajados. Seu senso de propriedade e responsabilidade melhora e leva a um melhor envolvimento e desempenho.
5) Evita o Acúmulo de Problemas
Dependendo do setor, é possível que pequenos problemas de qualidade em uma área ou departamento causem atrasos e soluções alternativas em outro departamento, o que, por sua vez, afeta outros departamentos (e então temos os famosos gargalos da Teoria das Restrições).
Com o tempo, todo o sistema pode acabar acumulando grande quantidade de bugs, questões, problemas e soluções alternativas peculiares que se tornam difíceis de remover e resolver. Isso é particularmente um problema no desenvolvimento de software e um forte argumento para interromper a linha antecipadamente.
Quem já foi desenvolvedor sabe o que é se deparar com o código-fonte de um colega e pergunta: “- Mas que porra coisa louca é essa daqui?!”.
“Parando a Linha” na Prática
Os sistemas Lean têm sido aplicados em empresas e indústrias que não estão diretamente na manufatura (aí está o ITIL dizendo que tem Lean).
Parar a linha significa duas coisas:
- Parar temporariamente a produção nas condições atuais ou com o produto atual.
- Pedir ajuda imediatamente.
“Parar a linha” significa que todos os níveis estão focados em resolver esse problema imediatamente, e pessoas, equipes ou departamentos individuais não precisam tentar resolvê-lo sozinhos (quero ver uma área normal de suporte técnico obter toda essa ajuda sem precisar implorar, huahuahua).
Quando feito corretamente, “parar a linha” resulta em suporte e colaboração imediata e produtiva.
Se você implementar a política de “parar a linha”, mas também não convocar uma resposta rápida, sistêmica e eficaz, produzirá mais problemas do que resolverá e correrá o risco de punir o funcionário que acionou o alerta.
Conclusão
Eu não estou dizendo qual lado — Gerenciamento de Problemas ou Produção Enxuta — é o correto ou o mais adequado para sua empresa. Espero que compreenda isso.
Dadas essas gritantes diferenças, deixo o comentário do ChatGPT:
Quanto à prática de gerenciamento de problemas do ITIL 4, é verdade que ela pode ser vista como incompatível com o pensamento enxuto.
A gerência de problemas do ITIL 4 envolve a análise e solução de problemas em uma abordagem de etapas, que pode levar tempo e adiar a solução de problemas.
Por outro lado, o pensamento enxuto defende uma abordagem mais imediata e enérgica para resolver problemas, interrompendo o processo de produção para corrigir o problema.
Na minha opinião, a solução ideal seria buscar um equilíbrio entre as duas abordagens.
A gerência de problemas do ITIL 4 pode ser adaptada para incluir uma abordagem mais ágil e colaborativa para resolver problemas. Em vez de adiar a solução de problemas, as equipes podem trabalhar juntas para resolver rapidamente os problemas, minimizando o impacto no processo de produção.
Isso permite que as equipes de produção permaneçam focadas na entrega de serviços de qualidade, enquanto ainda abordam e solucionam problemas de forma eficaz.
Mas…
Eu acho que isso somente funcionaria nas grandes corporações. Ou não, por que sempre todos têm suas tarefas e metas para cumprir que, em geral, não permitem dar uma ajudinha na hora que o outro precisa. Se é que me entende.
Nas pequenas, reunir as equipes para lidar juntas com o problema, seja imediata ou posteriormente, é quase impossível.
Então na boa, não me digam que a ITIL implementa o Lean.
Salvo uma ideia ou outra roubada a esmo. Mas se pega um pedacinho do Lean sem compreender que faz parte de um contexto maior de conceitos, então é jogar pra torcida sem se preocupar com o placar.
É semana que vem
Concordando ou não comigo, tem outra coisa que preciso dizer:
Ainda há vagas para o curso de Gestão de Serviços de Help Desk e Service Desk da semana que vem.
E as inscrições podem ser parceladas em até 3x, sem prejudicar seu fluxo de caixa.
Visite https://www.4hd.com.br/calendario
Abs
El Co