Os ambientes de TI hoje são caldeirões ferventes de incidentes complexos que podem ter grande impacto na satisfação dos negócios e dos usuários, sem mencionar as implicações legais e financeiras. As equipes de Gerenciamento de Incidentes correm para combater os incêndios causados pelas interrupções do serviço. No ambiente já desafiador e de alta pressão do Gerenciamento de Incidentes, você será sábio ao conhecer mais desses sete pecados mortais, que se ignorados, podem enviar a reputação do seu service desk para o fundo do poço.
1. Atribuições de solicitações incorretamente
Quando os usuários finais têm visibilidade do processo de atribuição de incidentes, as reatribuições incorretas e subsequentes (passar a solicitação de uma equipe de suporte para outra ou entre técnicos individuais) podem criar uma percepção negativa da organização do service desk de TI. Até o momento em que a solicitação de incidente chega à equipe de suporte certa, o tempo de resolução precioso é perdido resultando em escalações e usuários finais frustrados. A categorização exata de incidentes, a implementação de um catálogo de serviços e o roteamento automatizado de solicitações que encaminham incidentes para as filas de técnicos adequadas assim que chegam no service desk ajudam a reduzir as solicitações atribuídas incorretamente.
2. Tempos de longos de resolução
O Tempo de Resolução é uma métrica essencial para julgar as habilidades de solução de problemas dos técnicos, conhecimentos técnicos e habilidades de comunicação. Um tempo maior para chegar à resolução de incidentes significa maiores custos de suporte para a organização de TI e usuários insatisfeitos que não vêem seus incidentes resolvidos rapidamente. Priorizar os incidentes corretamente pode ajudar a gerenciar a carga de trabalho do técnico e dar-lhes insight sobre as solicitações que necessitam de atenção urgente. Um mecanismo de SLA bem definido com tempos de resolução e níveis de escalonamento pode ajudar os técnicos a ficarem atentos aos prazos. Além disso, uma base de conhecimento abrangente de soluções e garantia de treinamento (indexado e pesquisável) pode ajudar a acelerar os tempos de resolução de incidentes.
3. Correções que não funcionam
Quando as solicitações são reabertas, na maioria das vezes isso significa que eles não foram resolvidos na primeira vez ou em outras palavras, nunca foram resolvidos. Um número elevado de incidentes reabertos sugere uma má qualidade das soluções fornecidas pela equipe de service desk. O encerramento inadequado das solicitações sem receber confirmação do proprietário pode resultar na reabertura de incidentes. Treinamento eficaz e manutenção de uma base de conhecimento ajuda a reduzir “correções falhas”. Ao mesmo tempo, o service desk deve ter um mecanismo para verificar com o usuário final se a resolução fornecida resolve o problema.
4. Violação frequente de SLAs
Quando as solicitações de incidentes não atendem aos SLAs de resolução, as mesmas ficam atrasadas e como resultado são escaladas. Um número elevado de incidentes atrasados reflete na capacidade do service desk de cumprir os prazos dos incidentes. Os incidentes em atraso podem ser evitados através da criação de SLAs realistas, mecanismos de notificação adequados (sistemas de alerta precoce) para técnicos, roteamento preciso de solicitações, priorização correta das solicitações e fornecimento de base de conhecimento para os técnicos para resolução rápida de solicitações.
5. Não fechamento de solicitações resolvidas
Fechar uma solicitação é o reconhecimento da eficácia da solução do técnico pelo usuário final. As solicitações que podem não ter sido resolvidas, mas que foram definidas como “resolvidas” pelos técnicos, nunca poderão ser endereçadas até que sejam forçados a fechar após a confirmação do usuário. O não fechamento de incidentes depois que eles foram resolvidos resultará em dados de métrica distorcidos (como Incidente Backlog) que é impreciso e enganoso, apesar dos esforços colocados pelos técnicos. Você deve garantir que as notificações são enviadas para os usuários finais quando as solicitações de incidente são resolvidas, para que os usuários possam verificar se a solução resolve o problema e confirmar o encerramento. Também deve haver um mecanismo para fechar automaticamente as solicitações resolvidas após um tempo especificado quando não há resposta do usuário final.
6. Falta de uma estratégia de comunicação
Quando os usuários finais têm de manter contato com o helpdesk para atualizações sobre interrupções ou solicitações de incidente, isso agrega pouco para melhorar a sua experiência ou satisfação e só aumenta a sua frustração. Uma forte estratégia de comunicação deve visar a comunicação oportuna, informativa, proativa e transparente com os usuários finais. Seja comunicando uma interrupção de serviço com atualizações regulares ao longo do caminho ou fornecendo uma atualização de status da solicitação de incidente, uma comunicação efetiva constrói a confiança do usuário final para com o service desk. Com tantos canais como e-mail, internet, bate-papo e mídias sociais disponíveis, sua estratégia de comunicação vai ser fundamental para manter suas relações com os usuários finais.
7. Fechar os olhos para um problema
Quando você resolve um incidente você está corrigindo apenas os sintomas ou a causa raiz em si? Quando você vê uma maior frequência de repetição de incidentes, isso significa que a causa raiz subjacente não foi corrigida. Embora os incidentes individuais levantados possam ser resolvidos dentro do tempo de SLA, os incidentes repetidos roubam o tempo dos técnicos para outras questões importantes, reduzindo a produtividade e, em última análise, a saída do service desk. Para superar isso, você deve ter um processo para que um incidente seja convertido em um problema ou ligado a um para análise e resolução. Todos os incidentes repetidos devem ser capazes de estar ligados ao problema se o service desk decidir fechar os incidentes somente após a causa raiz ser corrigida.
Para ter o seu Gerenciamento de Incidentes em ordem, é importante que você elimine esses sete pecados, se eles aparecem. Quando deixados de lado, eles podem destruir as operações em execução do seu service desk. Parece que é hora de entrar em ação e dar a esses pecados o enterro que eles merecem.