Como implementar o ITIL em pequenas e médias empresas – Parte 1
CooperaTI
Salve, salve, pessoal do Cooperati, hoje vou começar um série de posts sobre ITIL, mas voltado para pequenas e médias empresas, mas não no Beaba de sempre, e sim como utilizar ela na prática, coisa que é dificil de se enxergar quando faz algum curso ou leitura sobre o assunto, as coisas ficam muito amplas, nesse primeiro post falarei sobre como definir o nível de maturidade que quer chegar dando alguns exemplos para isso, então vamos lá.
Como sabemos, gerenciar os serviços de TI não é uma tarefa simples, para tentar facilitar essas atividades foram criados vários frameworks de gerenciamento, porém um dos mais utilizados e divulgados no momento é o ITIL que se encontra em sua terceira versão, contendo muitos conceitos e técnicas para realizar as “Melhores Práticas” em serviços de TI.
Mas uma das grandes dificuldades para a sua implementação é a grande variedade de conceitos técnicos que ela possui e a não explicação de como empregá-los. Sua implementação em pequenas e até mesmo em médias empresas não é muito convencional, pois muitas dessas empresas não tem a estrutura para implementá-los, outro problema é que ela só diz o que deve ser feito, exatamente como um guia e não como faze-lo, então muitos ficam perdidos na sua implementação.
Mas mesmo que os argumentos citados sejam verdadeiros não podem ser uma barreira para a sua implementação e digo o porque, o ITIL foi desenvolvido para dar uma rota as melhores práticas, mas ele pode ser adaptável a sua estrutura, pois se ele for engessado, sua implementação realmente será muito difícil e outra se você usar um modulo, ou função que esteja escrito nele, você automaticamente estará usando o mesmo.
Outra coisa, o ITIL contém níveis de maturidade, então se você estiver em um nível que condiz com a sua realidade, você terá implementado o ITIL na sua empresa, não precisa estar no nivel mais alto em tudo, pois sabemos que para chegar a esse nivel, muitas coisas além do mundo da Ti precisam acontecer e também naõ precisa implementar todos os módulos pois, como já disse, nem toda empresa tem estrutura para todos. Mas você deve estar perguntando-se: “Qual seria o nível que condiz com a minha realidade?”, para responder a essa pergunta vamos aos níveis em si:
1º – Inexistente: Preciso dizer algo? Um exemplo simples para esse nível é: Um gerente de uma empresa pergunta ao funcionário da TI: “Quais são os maiores problemas que possuo na minha empresa em relação a TI?” e ele responde: “Faço a mínima ideia”.
2º – Inicial: Existe uma noção do que acontece na empresa, mas as tarefas realizadas são informais e bem desorganizadas, geralmente cada pessoa do setor de TI sabe algo da estrutura, mas não é documentado. Continuando o nosso exemplo, o gerente faz a mesma pergunta e o profissional responde: “Bom, EU atendo muitos chamados de mau uso do software mas não sei porque isso acontece e não sei te dizer se é o principal, pois não sigo um padrão, vou tentando adivinhar na hora que vou resolver.”
3º – Repetitivo: Esse nível existe uma ampliação do que acontece na empresa por parte da TI, a informação ainda fica centralizada em uma única pessoa, porém existe procedimentos padrões para realização das tarefas, mas todos reativos o problema ocorre vai lá é soluciona. Continuando a linha dos nossos exemplos, o gerente faz de novo a mesma pergunta e o profissional de Ti responde “Bom, EU atendo muitos chamados de mau uso do software, e sei disso pois sigo uma linha de raciocínio que desenvolvi de tanto atender esses chamados, mas não sei te dizer porque isso acontece, só vou lá e resolvo.” E o gerente faz outra pergunta “Os outros sabem lidar com esse problema?” e o profissional responde “Não sei, provavelmente não, desenvolvi essa técnica sozinho e ainda não passei para ninguém.”
Vamos dar uma pausa aqui, antes de continuar, como podemos observar os níveis citados acima, não são níveis aceitáveis em qualquer tipo de empresa, pois se caso o funcionário, usado no exemplo acima, sair da empresa, todo o processo que ele criou, será perdido e a empresa terá que criá-lo novamente. A partir de agora os níveis já são aceitáveis dependendo do nível da empresa.
4º – Definido: Esse nível os processos são documentados e todos os participantes do processo são avisados das mudanças e quando depararem com alguma anomalia no processo podem detectar e consultar a documentação do mesmo,além de poder evoluí-lo com alguma descoberta feita que pode melhorar o processo, além de tentarem evitar que o problema aconteça: Seguindo o raciocínio do nosso exemplo o gerente faz a pergunta “Quais são os maiores problemas que possuo na minha empresa em relação a TI?” e o profissional de Ti responde: “Bom, segundo a nossa documentação e comunicação interna, o maior problema é o mau uso do software, pois recebemos muitos chamados dele aqui, como sabemos disso já temos um padrão definido para ele e tentamos evitá-lo realizando as tarefas preventivas”, e o gerente faz nova pergunta “Você sabe porque isso acontece?” e o profissional responde “Infelizmente não temos essa informação”
5º – Gerenciado: Nesse nível todos os processos são gerenciados e medidos, com isso os relatórios são mais elaborados e a detecção de erros são mais fáceis de encontrar, o processo fica gerenciável, mas para tornar isso possível, toda uma estrutura deve ser construída e atingir esse nível não é fácil. Dando prosseguimento ao exemplo que estamos vendo a resposta dada pelo profissional de TI para a pergunta do gerente é a seguinte: “Bom, segundo a nossa documentação e comunicação interna, o maior problema é o mau uso do software, pois recebemos muitos chamados dele aqui, como sabemos disso já temos um padrão definido para ele e medindo o índice de chamadas verificamos que a grande causa disso é devido a um mau treinamento no software, pois as pessoas não estão usando-o da maneira correta”.
6º – Otimizado: Nesse nível tudo é executado usando as melhores práticas e com um adicional, o processo sempre está evoluindo, segue tipo o dito popular “Nada não é tão bom que não possa melhorar”. Seguindo a linha do nosso exemplo, em vez do gerente vir até o profissional, o processo é inverso é o profissional que vai até o gerente e ainda emitindo um relatório onde está o problema do mau uso do software e dizendo a ele que para melhorar isso a empresa deve investir no treinamento do pessoal para melhorar a produtividade.
Sentiram a diferença entre os níveis? Como podemos ver cada empresa, pelo seu estilo, deve ter um nível que lhe atenda. Na minha visão uma pequena empresa tem que ter como meta inicial o nível Definido, pois quem trabalha nesse segmento sabe que os recursos são escassos e geralmente não se tem uma equipe ideal para cuidar desse setor e um funcionário pode desempenhar várias funções, desde nível de usuário a servidor.
Então se ela tem os processos definidos e documentados as tarefas ficam até mais simples, pois permite passar para o nível Gerenciado mais facilmente, apesar de que sem dar ao departamento de TI as ferramentas necessárias, tanto de maquinário como de pessoal, chegar ao novo nível é difícil. Mas tendo um nível Definido bem executado já é uma vantagem, pois evita o desgaste de troca de funcionário que é comum nelas, pois o treinamento do novo torna-se mais fácil.
Para uma empresa de médio porte, o nível aceitável já passa a ser o gerenciado, pois nesse tipo de empresa, a empresa já tem uma certa dependência da TI e se os processos não estão correndo certinho, as chances de um pequeno problema tornar-se grande são enormes, um exemplo disso é se um processo de restauração de um sistema critico para a empresa não tiver documentado e sendo feito de acordo com os padrões da empresa, o prejuízo financeiro será incalculável (se for executado erroneamente), além do mais os funcionários de TI tem sempre que estarem monitorando os processos para ver se eles estão em níveis satisfatórios para poder remediar o problema sem ele ter que acontecer.
E para as grandes empresas, nem precisa falar que o aceitável é o Otimizado, porém todos sabemos que até para elas isso é bem difícil de chegar, pois precisa de um união grande de vários setores e todos precisam estar bem alinhados, mas elas possuem mais recursos para isso acontecer do que as pequenas e medias e por isso esse é o aconselhável, mas elas não são o foco dessa série de artigos
Outro fator que devemos considerar é que no ITIL existem vários módulos das fases dos processos e cada módulo pode ter um nível de maturidade e é nisso que vamos focar, quais são os processos que devem estar no mínimo no nível de maturidade Definido para as pequenas e médias empresas é que não é nenhum bicho de sete cabeças de ser implementado.
No próximo post falarei dos processos que o ITIL cobre e que podem ser facilmente implementados na sua empresa além de falar de ferramentas que estão disponiveis de graça para você. Para exemplificar o que estou dizendo, vamos seguir com os nossos exemplos. As ferramentas que o nosso profissional de TI pode ter usado para detectar esse problema seria o GLPI, para gerenciar os chamados, além de poder ter criado um base de conhecimentos através de wiki tais como o MediaWiki para documentar os problemas enfrentados para mitigá-los e poder ser usado para dar o treinamento para os usuários do sistema que está dando defeito.
Isso é só uma amostra do que pode ser feito então até o próximo post.
Muito bom este post Laerte, acredito que esta série sobre Itil abrirá a mente de muitos que passam por este site.
Usei muito o Ocomon em uma empresa que trabalhei, tanto para clientes internos e externos. O único problema que vejo no Ocomon é que o seu desenvolvimento ficou para trás. Em relação a Wiki, é de muita importância manter tudo documentado da empresa, até porque hoje você está lá e amanhã pode não estar e um novo funcionário entrará totalmente perdido.
Um abraço e até mais.
Fabricio, com certeza o OCOMON o pessoal deixou ele de lado, mas querendo ou não ainda ajuda as empresas alvo desse artigo que são as SMBs e que são a grande maioria no Brasil, e como disse em um curso de ITIL, o instrutor te entope de informação, que você fica até perdido além da franca maioria ser todos voltados para a certificação, por isso alguns pontos são até simples de ver, mas outros…, outra coisa, muitos pensam que para implementar ITIL, tem que colocar todas as técnicas em supra-sumo de perfeição e todos sabemos que toda empresa tem o seu perfil e as suas necessidades variam entre elas o que funciona em uma, não funciona da mesma forma na outra, por isso que o ITIL, tem que ser levado como GUIA, não como REGRA.
Abraços e obrigado pelo comentário.
Excelente post, esperando a continuação.
Obrigado Juliano.
Olá Laerte.
Esta vai ser a série de posts que mais ficarei aguardando, pois achei ITIL ligeiramente vago no que diz respeito a hora de colocar a mão na massa e essa ideia de mostra-lo melhor na pratica de clientes SMB foi fantástica.
Quanto ao OCOMON, gostaria de sugerir uma outra abordagem, o GLPI, que segue mais o ITIL. O ocomon eu até cheguei a levantar o projeto, contratei na época um programador e juntei a galera q tava afim d programar nele e trabalhei numa interface mais otimizada mas o código do ocomon estava tão ilegível e sem um único comentário q deu tristeza, pq parece q os programadores iniciais aparentemente não o fizeram não pensando em outras pessoas programando nele.
No mais, quero deixar aqui meu agradecimento pelo excelente tema.
Eu falei para o Laerte que esse assunto iria bombar!
Fugindo um pouco de software livre. Quem gosta de 100% ITIL deve experimentar o System Center Service Manager.
Diferente do Service Desk (principal concorrente) o SM simplesmente não permite que se fuja do padrão das melhores práticas.
Com certeza, o SCSM é fino nessa parte, consegue gerenciar de uma forma excelente, porém o preço se tratando de SMBs, atrapalha, e Rafael você sabe disse muito bem que quando você fala que vai implementar algumas dessas ferramentas nesse tipo de empresa é complicado, você tem que tirar leite de pedra e ainda dançar um conga-la-conga da Gretchen, dependendo do superior que você tiver 😀
Jeferson, opa bom saber, vou dar uma olhada no GLPI e pode ter certeza que se ele se encaixar no que pretendo escrever, vou falar sobre ele e essa sua sensação pode ter certeza q não é o único, os cursos de ITIL falam muito de teoria e não dão exemplos práticos, além de serem testking para o exame, ai já viu né, e outra coisa que tem que ser dismistificado é que tudo que está no ITIL tem que ser implementado e tem que ser das ultra melhores técnicas, o conceito dela de nivel de maturidade é excelente e muitos deixam isso para trás, e nem tudo que está no ITIL consegue ser implementado fielmente você tem que adapta-lo a sua realidade, por isso que frizo bastante, ITIL é GUIA, não REGRA como muitos falam.
Abraços e obrigado pelo comentário e sugestão. 😉
Muito bom essa iniciativa, vou ficar aguardando mais …
Abraço.
Muito bom, material valioso e de qualidade !
Laerte Costa, muito bom o post, excelente texto, ITIL em teoria é fácil, na prática as coisas mudam de figura, eu uso o GLPI para o controle de chamadas com o OCS, que faz o inventário do parque computacional, ambos integrados entre si e com o AD, já usei o OCOMON mas ele já não é atualizado à algum tempo.
GLPI vem sofrendo constantes atualizações e inclusive se adequando à alguns processos de ITIL, com base de conhecimento integrada, e scripts self-service para usuários/clientes resolverem por si, ou para TI entrar em ação e outras más.
Mas apesar disso, com essas ferramentas, e sabendo que ITIL é muito mas do que isso, onde são vários processos interdependentes eu venho sofrendo pela limitação de ambas. Estava fazendo um testes com uma ferramenta chamada SCE2010(system center essentials) achei bem legal e mas robusta com muitos relatórios e totalmente integrada, SLAs…etc. O Rafael Bernardes pode falar melhor dela, mas já estou de “olho” nas novas ferramentas do system center 2012.
Quando me refiro a integração, imagina um hardware ou software quando acontece um incidente, e antes que o usuário realize um chamado, o mesmo automaticamente já crie um alerta ao programa de service desk ou help-desk, e esse por sua vez entrar em uma base de conhecimento, quem contem uma lista de scripts de causa raiz de problemas, onde o usuário(cliente) tem um self-service de resoluções de problemas fáceis no seu desktop com o programa de service desk client, e se não for resolvido em 1º instância e dependendo da criticidade e tempo, o pessoal da TI entra em ação. Mantendo assim a lei do menor esforço para TI, e gerando maior continuidade do negocio para empresa.
A TI tem que pensar em novas soluções, ser mas pró-ativa do que reativa, eu digo sempre que apagar incêndio vicia, e é o que vejo em muitas “TIs” por onde andei, a galera não tem tempo para nada. Esse é o meu ponto de vista 🙂
Rafael, uma pergunta, já tem o SCE2012??
Vlw Galera.
Galera um adendo ao meu comentário, quando me refiro a lei do menor esforço para TI, e o porque de um sefl-service para problemas fáceis para os usuários/clientes são bem vindo, além de treinamento óbvio.
Segue o link do vídeo que reflete bem o que acontece em um help desk/service desk gerando custos desnecessário para TI mal planejada.
http://www.youtube.com/watch?v=IJq-x2Vrv8c&feature=player_embedded#!
Fato: Tenho que arrumar uma forma do meu chefe entender isso!!!