Você consegue dirigir seu carro sem um painel de controle? Você consegue gerenciar um Service Desk sem Indicadores?

Transcrição

1 Você consegue dirigir seu carro sem um painel de controle? Você consegue gerenciar um Service Desk sem Indicadores? Será que está acabando a gasolina? Qual o consumo médio do carro na Estrada ou na Cidade? Qual a velocidade média realizada? Qual o melhor giro do motor para determinada situação ou marcha? Se você acha que consegue dirigir um carro sem estas informações obtidas no painel de controle da maioria dos carros atualmente, você é um gênio! brincadeiras à parte, este é o sentimento que eu costumo ter quando entro em um empresa e vejo processos na área de TI, ou outras áreas, sem o apoio de um software de gestão por indicadores. Dentro de um processo de melhoria de serviços continuada, sugerido por boas práticas como ITIL e COBIT, necessitamos medir a entrega e a performance dos processos. As medições possibilitam a avaliação da situação atual, ajudam na identificação das áreas de aperfeiçoamento e ajudam a avaliar as ações realizadas. Não se pode gerenciar o que não se pode controlar. Não se pode controlar o que não se pode medir. Não pode se pode medir o que não se pode definir. Para que a medição realmente nos mostre algo que nos permita avaliar a entrega, ou a performance de um processo, faz se necessário armazenar os resultados obtidos. Com isso, conseguiremos construir uma série histórica dos valores, dando não somente resultados atuais e principalmente a sua tendência. Através da tendência poderemos realizar mais facilmente ações para melhoria e avaliar o impacto das ações realizadas. Outro ponto importante em qualquer análise é ter o registro das ações de melhoria realizadas. Sabemos que as ações que mudaram algo no ambiente, assim como mudanças em servidores, links, aplicações normalmente são registradas pelo software de Service Management. Mas e as mudanças como contratações de novos atendentes, treinamentos especializados, alterações em políticas salariais, etc. Todas estas ações também impactam diretamente nos resultados dos processos. Em frameworks de governança como o COBIT, olhamos os recursos de TI (aplicações, infraestrutura,

2 pessoas e informação) como um todo. Logo, devemos manter registradas todas as ações de melhoria realizadas com estes itens. A análise de todas as ações que ocorreram nos permitirá contextualizar melhor as ações de melhoria que efetivamente tiveram sucesso e corrigir aquelas que não tiveram efeito. A seguir listo alguns indicadores para área de Service Desk (Incidentes) que classifico como básicos. Explicarei o significado de cada um e como eles se relacionam. Em nossos próximos artigos, iremos abordar indicadores para Requisições, Problemas, Mudanças, Liberações, Eventos, etc. 1.0 Incidentes - % Resolvidos em 1 Nível Basicamente este indicador avalia a performance da equipe de primeiro nível. Quanto maior este indicador melhor. Partindo do princípio que uma equipe de primeiro nível tem um custo menor para a empresa, um alto índice indica melhor satisfação do cliente (quem não gosta de ser atendido rapidamente e pela pessoa que o atendeu) e claro, um menor custo. Devemos avaliar qual o tipo de atendimento que a equipe de primeiro nível está resolvendo pois pode ser que consigamos automatizar procedimentos internos e com isso, diminuir ainda mais os tempos e custos de atendimento. 2.0 Incidentes - % que usaram Base de Conhecimento Este indicador mede a eficácia da criação/manutenção da base de conhecimento de uma empresa. Normalmente demoramos muito (cerca de 1 ano) para construir uma base que seja realmente útil. Quanto maior este percentual melhor, significando que outros processos e toda equipe estão conseguindo gerar conhecimento. Este percentual deve ser avaliado em conjunto com o indicador anterior. Se o percentual de resolução em primeiro nível estiver alto pode ser devido ao grande número de conhecimentos que estão sendo usados. Se os dois indicadores estiverem contrários devemos avaliar o que exatamente está sendo resolvido em primeiro nível para podermos decidir onde melhorar pois normalmente quando a base de conhecimento é realmente eficaz, o indicador de resolução em 1 nível tende a ser grande.

3 3.0 Incidentes - % Resolvidos dentro do SLA Este indicador mede se os prazos acordados em SLA está sendo cumpridos. Devemos avaliar com muito cuidado este indicador. Um valor muito grande, ou muito baixo, da meta estabelecida em contrato pode significar que o SLA foi mal dimensionado. Se foi acima da meta, é hora de iniciar a fazer um ótimo marketing interno com seus clientes. Se for muito abaixo, pode ser que a aferição inicial estivesse muito errada gerando enganos na hora de confeccionar o contrato de SLA. Neste caso, reveja o mais rápido possível para evitar insatisfação do cliente e possíveis multas. Se conseguirmos avaliar os tempos de cada equipe que trabalha para a resolução dos incidentes poderemos identificar mais facilmente os principais ofensores do SLA. 4.0 Incidentes - Tempo Médio Resolução Entender quanto tempo a operação de TI está demorando para atender um Incidente ou Requisição é fundamental para a melhoria de serviços continuada. O ideal, naturalmente é poder ver este indicador por diversos ângulos: Serviço, Classificação e Tipo de Incidente e requisição, etc. Além de estar tentando reduzir sempre este tempo, consequentemente um menor custo para a empresa estamos preocupados com a percepção do usuário do serviço. Este tempo normalmente é um nível de serviço acordado em contrato e por isso, deve ser acompanhado e revisado de perto. Se conseguirmos avaliar os tempos individualmente de cada equipe poderemos agir melhor para o sucesso da operação, seja aumentado o número de pessoas, remodelando o processo, automatizando procedimentos padrões, etc. Devemos tentar ter a clareza dos tempos médios de cada equipe visando identificar possíveis gargalos para o atingimento dos SLAs estabelecidos. 5.0 Incidentes - Custo Médio Resolução Sempre com perspectiva financeira em mente de uma operação, temos que saber o custo de execução de cada serviço prestado. Isso fará com que possamos estar entregando para a empresa o valor da TI com melhor retorno. Nunca podemos esquecer sobre a qualidade das entregas pois todo serviço de qualidade tem um custo apropriado. Este balanço entre os dois é sempre uma pergunta que o gestor

4 deve se fazer. 6.0 Incidentes - Quantidade Média Escalonamentos Partindo do princípio de que quanto maior o nível de atendimento (1 nível, 2 nível e 3 nível) maior será o custo, dado a especialização do mesmo, saber a quantidade média de escalonamentos nos direciona melhor para a compreensão dos custos e também a satisfação do usuário, pois novamente as pessoas gostam de ser atendidas o mais rápido possível e pela mesma pessoa que a atendeu. 7.0 Incidentes Quantidade Acompanhar a quantidade de Incidentes e Requisições criadas por dia faz com que possamos rapidamente detectar alguma anomalia na operação. Caso algum desastre ocorra (como por exemplo algum problema com o roteador principal da empresa) a quantidade de incidentes irá crescer muito. Normalmente isso é detectado pelo número de problemas reportados pelos usuários sobre internet, e- mail, aplicações na nuvem, etc, que serão impactadas diretamente pela causa citada. Além disso precisamos estar acompanhando a quantidade para melhor dimensionar a equipe para o atendimento, o que nos leva ao próximo indicador: Quantidade de Backlog diário. 8.0 Incidentes Backlog Ter a clareza de quantos Incidentes, ou Requisições, estamos deixando de atender por dia (visto que o backlog é a diferença entre os Incidentes criados e terminados por dia) irá nos ajudar a entender nossa operação. Será a equipe está mal dimensionada? Será que houve algum novo aplicativo em produção no período que fez crescer o número de incidentes? Qual a tendência do backlog, será que é necessário a criação de uma força tarefa para diminuição da quantidade atual? Um software que permita gerenciar os indicadores é fundamental para uma gestão por indicadores. Não esqueça que um software é parte da solução. No ITIL usamos muito o que chamamos de 3 P s (Pessoas, Processos e Produtos (tecnologia, software, etc). Devemos sempre olhar os 3 P s para podermos efetivamente melhorar os serviços.

5

6 Florianópolis, 3 de julho de 2013 Juano del Prado Logic IT Solutions juano@logicit.com.br