Muitas vezes vivenciamos um certo temor a tarefas ou pessoas por que seus títulos e o “entorno” é tão pomposo que preferimos nos retrair.
Gerenciamento de Problemas é um desses. Quem acessa o Youtube, blogs ou coisa parecida acaba se deparando com uma parafernália de expressões (a maioria em idioma inglês) que dão arrepios e… Deixamos pra depois.
Mas essa é uma iniciativa importante e que não pode ser postergada, pois nos sujeitamos ao risco de viver enxugando gelo dentro do Suporte Técnico e não evoluir em vários aspectos. É ficar preso num redemoinho permanente.
Vamos a um exemplo prático
“A sessão do usuário fica presa”.
Ou numa variação mais corriqueira:
“O usuário não consegue acessar o sistema por que já está em uso… por ele mesmo!!”.
Sensacional!!!
O motivo do problema
O usuário simplesmente clica no “X” da aba ou do browser em vez de sair do sistema utilizando o botão/opção de “logoff”.
Consequência: o usuário tem seu login (ou internamente, seu acesso ao banco de dados ou diferentes versões) bloqueado.
E se já está “em uso”, ele não consegue acessar.
A solução é relativamente fácil: pedir para o DBA “matar” a conexão zumbi (tá na moda a expressão, mas existia bem antes de Walking Dead, sério mesmo) do usuário com o banco de dados, o que o libera a novo acesso.
O problema
Inúmeros chamados são abertos diariamente por que os usuários mantêm esse comportamento de “sair” clicando no “x”. E vai ser sempre assim.
Mas enquanto ele contata o suporte (que muitas vezes repassa a bola para o DBA, infra, segurança, sei lá que área), o negócio…
O negócio está parado! P-A-R-A-D-O.
Calcule o prejuízo: o salário do sujeito que deveria estar trabalhando, mas fica em stand-by aguardando a liberação. As atividades de negócio paradas. O tempo do analista de suporte consumido. E o DBA envolvido. Os tempos de aguarde (“até o técnico de suporte atender”, “até o DBA tomar noção”, “até o DBA fazer algo” e por aí vai).
É um desperdício de tempo enooooorme por que o problema não é resolvido em definitivo.
Talvez nunca seja, mas como amenizamos?!
Entra em cena o Gerenciamento de Problemas
O analista pode, a cada incidente resolvido, associá-lo a um registro de problemas (o qual tem uma vida similar ao incidente: abre, trabalha-se nele e se encerra).
Ou alguém faz tal associação no final do dia. Ou no final da semana.
Depende de sua operação, mas pelo amor de Deus: não engula “tem que ser assim”.
E quem cuida do Gerenciamento de Problemas não obrigatoriamente precisa ser o “solucionador” deles.
Só precisa cuidar/acompanhar/gerir para saber:
- Quais os de maior impacto ao negócio.
- Maior impacto ao Suporte.
- Como está o ciclo de vida de cada problema (tem casos de abandono por algum solucionador?).
- O que é elegível para a base de conhecimento como solução de contorno enquanto ele não finda de uma vez por todas.
- Análise de métricas (“aquele fornecedor não dá mais!!”).
Do nosso caso
No caso do usuário trancado para acesso, o responsável poderia pedir ao DBA:
“Por favor, vê isso!”.
E esse elencaria soluções como:
- Dar uma prensa no fornecedor de software/plataforma para que investigue usuários inativos por mais de 15 minutos e os derrube automaticamente.
- Se o fornecedor não fizer isso, criar um script de banco de dados que o faça.
- Desenvolver automação para que o suporte derrube tais zumbis sem intervenção do DBA, resultando: menor vida para o incidente, atendimento mais rápido, negócio voltando a operar em menos tempo.
- Treinar e esclarecer melhor os usuários (não acaba o problema, mas reduz a quantidade de incidências).
- (Escreva a sua aqui)
Se comparar, as despesas de tempo de todos os envolvidos (sem falar das perdas de negócio) acabam sendo muito maiores do que investimento de tempo para resolver em definitivo o assunto.
Dos aspectos relevantes
1) Gerenciamento de Problemas é algo que vem sendo realizado há muito tempo. Pode chamar de Melhoria Contínua ou de qualquer nomenclatura que considerar chique. Mas não é uma novidade. É aprendizado.
2) Pode iniciar de forma simples, associando os incidentes a registros de problemas. E depois analisar estatisticamente (nada de feeling!) o que consome mais tempo ao negócio, ao Service Desk ou aos times envolvidos.
3) “Resolver” incidentes é um uso adequado do verbo (para o incidente), mas não significa que o problema cessará de acontecer.
É importante alguém se dedicar periodicamente a investigá-los e delegar atribuições (vai e diz a alguém: “Sei que você é bom nisso, veja se consegue pensar em formas para que nunca mais se repita.”).
4) Inicia de forma simples e pode ir se tornando cada vez mais sofisticado, mas…
Já terá um embrião funcionando e não será mais um bicho de sete cabeças. Mas precisa de disciplina para a sua continuidade.
Melhor construir logo prédios resistentes a terremotos do que reconstruir aqueles que desabaram (pegando o gancho do momento atual das catástrofes ocorrendo na Turquia e Síria).
Quase lá…
Queridos amigos, estamos próximos do dia do curso de Gestão de Serviços para Help Desk e Service Desk.
É início de ano, ótimo momento para projetar as ações de 2023 e impulsionar seu centro de suporte técnico em direção à excelência (seja lá isso o que você imaginar que é).
Dias 22-23-24 de março de 2023, 08:30-12:00 e 13:30-17:30
abrazon
EL CO
