Trabalhei por um bom tempo em um projeto de "big bang" para fazer uma organização compatível com os requisitos da norma internacional ISO 20000, para gerenciamento de serviços de TI e transformar a maneira pela qual a TI dessa empresa em particular que era gerida.
Aprendi muitas lições valiosas com essa experiência. A principal era que tentar influenciar todos os processos ao mesmo tempo não é realmente uma boa prática para se promover uma transformação.
Após tudo ser dito e feito, nós na verdade só fomos capazes de impactar a maneira em que os incidentes e mudanças eram controlados. Para os outros processos, mesmo criando uma documentação disponível para todos, estávamos longe de demonstrar os requisitos necessários para o controle da gestão, referente a todos os processos conforme exigido pela norma.
Surpreendentemente, alguns dos maiores sucessos que tenho visto, são de projetos que não estão especificamente ligados ao objetivo de implementar do ITIL, mas os que foram criados para resolver algum problema operacional e, eventualmente, resultou-se em uma iniciativa de transformação eficiente.
Em um dos casos, a organização passou por um exercício de grande re-estruturação: alguns anos antes do projeto, toda a sua infraestrutura de TI foi terceirizada para uma provedora de serviços. O projeto era relacionado à implementação de uma ferramenta de Service Desk que ajudasse a monitorar o desempenho do prestador de serviços na gestão dos serviços oferecidos aos usuários finais.
Nos três casos, embora os objetivos iniciais fossem de natureza puramente operacional, a iniciativa evoluiu para um projeto de TI de transformação que proporcionou benefícios visíveis e mensuráveis em toda a empresa.
A partir dessas experiências, eu aprendi que é importante fazer as coisas básicas primeiro: como estabelecer uma visão de serviço, manter a transparência na prestação de serviços, entender arquitetura do suporte e o perfil dos incidente existentes. Sem esse tipo de conhecimento não é muito inteligente partir para questões maiores, tais como gerenciamento de disponibilidade ou gestão de serviços de negócio.
Deixe-me descrever um caso para ilustrar meu ponto. Um Service Desk estava recebendo cerca de 400 chamados por dia e obtendo 80% de resolução no primeiro contato. A maioria dos tickets eram relacionados à categoria "Como eu faço...?". Esta informação foi, sem dúvida, muito impressionante e os relatórios semanais do ano passado mostravam uma tendência de estabilidade nesse quadro, com muito pouco espaço para melhorias.
No entanto, um olhar mais atento sobre o perfil dos chamados mostrou alguns fatos interessantes. Os relatórios semanais mostrados aos gestores eram feitom sem segregar os incidentes (33%) das solicitações de serviços (56%).
Era evidente que se essa segregação fosse feita, haveria uma probabilidade muito alta de que a história da resolução no primeiro contato fosse diferente e que a maior geradora de incidentes provavelmente não fosse alguns usuários pedindo informações, mas sim relacionado a aspectos operacionais dos serviços de TI. Na verdade, um pouco de matemática elementar previu que o número real da resolução no primeiro contato era de apenas 35% (não 80%), que em minha opinião, possibilitaria um bom espaço para melhoria.
Tendo isso em mente, nós criamos uma estrutura de classificação de chamados na nova ferramenta, para permitir uma orientação de serviço ao perfil do ticket. Nós separamos solicitações de serviço de incidentes, fornecendo uma classificação separada para as solicitações de serviço. Os resultados foram bastante traumáticos para todos os interessados.
A maior fonte de Incidentes já não era "Como eu faço...?", mas sim sobre "software de desktop". Além disso, os relatórios começaram a indicar que as maiores causas dos incidentes estavam relacionadas a erros com o MS Outlook. Ao estudar os chamados, finalmente descobriu-se que a Radio LAN não tinha a funcionalidade de informar ao usuário que sua senha de domínio estava para expirar.
Isto resultava em um número significativo de incidentes em que os usuários relatavam que eram incapazes de enviar e receber e-mails. Corrigir esse problema reduziria a ocorrência de incidentes, não só no e-mail, mas também em muitos outros que têm este ponto como solução. Eventualmente, isso elevou o nível de serviço aos usuários de laptop, que ficaram muito satisfeitos com a melhoria pró-ativa.
Este evento só provou ser um ponto de reviravolta na forma como o Service Desk e os grupos de suporte viam processos de incidente, problema e requisições de mudança, configurados na ferramenta. Esse tipo de trabalho é realmente a porta de trás no Gerenciamento de Serviços de TI.
Faça parte do grupo do maior instituto de Service Desk/ suporte do mundo!
Saiba das últimas novidades do mercado de Service Desk/ suporte
