Pular para o conteúdo principal

ITIL na prática: É possível?

Já passei por duas grandes empresas que tentaram implementar ITIL e não conseguiram. Também passo boa parte do meu tempo livre pesquisando grupos de discussão e trocando e-mails com pessoas da área. Na minha opinião, geralmente as discussões giram em torno de teorias e muita abstração. É raríssimo encontrar informações práticas. Tudo é muito filosófico.

Essa experiência me faz perguntar se realmente é possível implementar o ITIL. O que tinha que ser um livro de boas práticas, na verdade, é um livro de boas teorias, que de prático não tem nada. Tanto é que raramente se fala de ferramentas, nem todos os papéis estão definidos, a sequência da maioria das atividades não é clara e, para deixar tudo ainda mais teórico, as interfaces entre os processos mais parecem um quebra-cabeça. Me pergunto também se as empresas que dizem ter implementado o ITIL realmente o fizeram, já que não existe certificação. A pergunta que parece que ninguém tem coragem de fazer é: Será que o ITIL é viável?

Não estou me referindo a apenas um ou outro processo. Estou me referindo a todos. Tudo parece ser muito simples quando falamos de gerenciamento de incidentes, problemas e mudanças -- afinal, muitos centros de informática já fazem isso a anos de forma instintiva. A função da central de serviços também é algo simples de implementar: olha o helpdesk aí melhorado. Mas a coisa complica definitivamente quando o assunto é gerenciamento de configuração! Ainda mais complicado são as interfaces dela com os demais processos.

Acho elogiável a iniciativa de alguns grupos de discussão e até sites dedicados a ver o ITIL de forma prática. Mas, sinceramente, eles ainda não conseguiram. E, na minha opinião, todas essas iniciativas, inclusive o próprio livro do ITIL pecam nos seguintes pontos.

Primeiro, os papéis não estão bem definidos. Entenda que definir um papel não é só dar um nome para ele e dizer quais são as suas responsabilidades. As empresas querem saber quem vai exercer aquele papel, quantas pessoas devem ser, a quais estruturas da organização essas pessoas devem pertencer e, mais importante, em quais atividades elas vão atuar fornecendo exatamente que tipo de informação. Em outras palavras, essas pessoas serão responsáveis por quais entradas do processo? E exatamente quando elas vão ter que fornecer essas entradas?

Outro problema nas abordagens do ITIL que vejo por aí é aquela velha frase "você precisa escolher uma ferramenta que melhor se adapte à realidade da sua empresa". Isso é verdade, eu tenho que admitir. Mas concorda que é muito fácil dizer isso toda vez que alguém te pergunta qual ferramenta usar? Ou melhor, será que não poderíamos pelo menos dizer quais funcionalidades essa suposta ferramenta deveria ter? Vou mais além ainda. As pessoas querem saber como as ferramentas se integram ao processo. Em outras palavras, o desenho do processo deve prever em cada atividade os formulários utilizados para o fornecimento das entradas. Afinal, quando utilizamos uma ferramenta, os formulários preenchidos representam os próprios artefatos utilizados no processo.

Vou citar só mais um problema. Os textos que abordam ITIL são muito abstratos e raramente incluem exemplos ou estudos de caso para ajudar as pessoas a visualizarem a execução dos processos no dia a dia. O próprio livro do ITIL, na minha opinião, deveria fornecer um estudo de caso bem abrangente com o cotidiano de um centro de informática qualquer que demonstrasse na prática a aplicação da teoria. Os melhores livros de programação já fazem isso. Por que não fazer isso também para livros sobre processos?

E os problemas não param por aqui. Ainda existem uma avalanche deles, como a não definição da integração com outros modelos de processos. Os próprios livros ITIL são muito estanques. Existem uns poucos gráficos falando de integração. O livro que fala sobre desenvolvimento de software, por exemplo, é desconhecido da maioria das pessoas.

Assumo que é fácil criticar. Mas para propor soluções, primeiro precisamos reconhecer os problemas. Eu mesmo confesso ter sido muito abstrato em todas as vezes que falei de ITIL até agora. Aproveito para convidar aqui todos os blogueiros e escritores sobre o assunto a mudarem para uma abordagem mais prática, orientada a exemplos e estudos de caso. A viabilidade do ITIL pode estar dependendo justamente disso!

Comentários

Anônimo disse…
Ótimo!

Postagens mais visitadas deste blog

Lições aprendidas durante a pandemia de Covid-19

Até os países mais desenvolvidos não estavam preparados para lidar com uma pandemia. Ou seja, nesse sentido, não há muito para onde correr. E também instituições sólidas, na área científica, médica e sanitária, também não estavam preparadas para lidar com uma pandemia.  O único setor que estava preparado, e inclusive mostrou muita competência, para lidar com a pandemia foi o setor farmacêutico privado. E isso por uma razão muito simples: eles são da iniciativa privada. Quando existe interesse, em geral econômico, alguns problemas são resolvidos muito mais rapidamente do que normalmente acontece. Muitas pessoas preferem acreditar em qualquer notícia do que pesquisar informações em fontes confiáveis. Quando o assunto é doença, máscara facial simples não protege quem a usa. Máscara protege os outros de quem usa. Então não adianta usar máscara para se proteger, se no mesmo ambiente outros não estão usando máscara. Uma máscara PFF2 é melhor do que uma máscara simples, mas ainda assim a prot

Reforma de um apartamento antigo - Lições aprendidas

Há cerca de 6 meses conclui a reforma de um apartamento antigo aqui em Brasília, DF. Foi a minha primeira reforma e, obviamente, cometi diversos erros e me arrependi de várias decisões. Seguem algumas lições aprendidas que talvez possam te ajudar a tomar boas decisões. 1. Divida o projeto arquitetônico em duas fases: primeiro a demolição, depois o projeto propriamente dito Contratar um arquiteto é essencial. Mas em se tratando de uma reforma, ainda mais de um apartamento, surpresas podem ocorrer. Mesmo que o arquiteto use um detector de pilares, vigas, colunas de encanamento do prédio etc... ainda sim podem haver surpresas. Por isso, é melhor separar o projeto em duas fases. Primeiro, já tendo alguma ideia do que você pretende fazer, peça para o arquiteto um projeto de demolição. E contrate uma equipe só para essa fase. Vai sair mais caro contratar só a demolição separada do resto? Provavelmente. Mas a tranquilidade que você terá durante a execução da segunda fase não tem preço.

Não compre o Amazon Echo ou Echo Dot se você estiver no Brasil

Nos EUA, o Amazon Echo (ou Echo Dot) é um dispositivo familiar. Uma vez instalado e configurado, vários membros da família podem utilizar o dispositivo para auxiliar em tarefas diversas. Isso é possível graças ao recurso chamado "household", em que o usuário "proprietário" do dispositivo (ou seja, aquele que registrou o dispositivo na sua conta da Amazon), pode convidar outros membros da família. Daí os demais membros da família podem acessar suas contas e realizar diversas funções. Ocorre que no Brasil, e em diversos outros países, esse recurso simplesmente não está disponível. Sequer a opção para configurá-lo aparece no menu de opções do aplicativo da Alexa, nem no site Amazon.com.br. Por isso, o Echo acaba se tornando um dispositivo pessoal, de pouca utilidade para os demais membros da família. E nem adianta comprar outro Echo e colocar do lado, já que os dois vão atender quando alguém falar "Alexa" e vão começar a bater cabeça um com o outro, ou falar