10/10/2016
A IMPORTÂNCIA DE SE ABRIR CHAMADOS EM UMA FERRAMENTA DE SUPORTE (HELPDESK).
Quem trabalha com TI sempre se depara com uma situação muito comum, a resistência dos usuários em abrir chamados de suporte técnico. Praticamente, entre todos os profissionais da área de TI, este tipo de reclamação é recorrente. Os usuários ligam, reclamam de algo que não está funcionando adequadamente, mas se for solicitado a eles que seja aberto um chamado ou caso de suporte (de acordo com a ferramenta de Heldesk ou padrão utilizado pela organização temos nomes diferentes) eles justificam de diversas formas que não irão fazê-lo.
Analisando esta resistência, vemos que existem várias causas possíveis, vamos refletir sobre algumas delas:
1- Ferramenta de HelpDesk não amigável.
Neste caso tenho que concordar em partes com os usuários, pois vejo alguns casos em que as ferramentas são complexas e para a abertura de um chamado, são necessários vários minutos, navegando por telas pouco intuitivas. Neste caso, vale a pena procurar outra ferramenta, que seja amigável ao uso de um “leigo”.
2- Não tenho tempo para abrir chamado.
Aqui cabe a conscientização, provavelmente o tempo que o usuário está lhe descrevendo o problema e reclamando, seria o tempo suficiente para abrir o chamado. Geralmente o time de TI não conversa muito com os usuários, criar uma campanha de conscientização, criar uma política em que chamados abertos via ferramenta de Helpdesk são atendidos com prioridade, pode ajudar.
3- Abro o chamado, mas não sou atendido.
A TI deve de fato atender os chamados, o ideal é ter uma política clara de priorização e com SLA’s definidos para os usuários, eles necessitam entender que após a abertura do chamado o mesmo será classificado de acordo com a prioridade e complexidade, posteriormente o chamado será atendido em um intervalo de tempo definido. Os tempos para atendimento (SLA) são relativos para cada empresa e irão variar de acordo com o tipo de negócio, tamanho do time de TI, etc. Em times pequenos (por exemplo, 2 pessoas), uma forma de dar vazão aos chamados é ter um técnico que classifica os chamados e tenta resolvê-los remotamente, este mesmo técnico também insere informações adicionais ao chamado que irão ajudar o técnico de campo na resolução do mesmo, o segundo técnico vai pessoalmente resolver os problemas que exigem maior tempo para solução ou que exigem intervenções físicas na máquina.
Bem, esses são 3 pontos talvez considerados os mais comuns, neste momento você pode perguntar, porque dar tanta importância para a formalização dos problemas via chamado, não é mais fácil e menos burocrático atender os usuários diretamente?
Na verdade não, se você não formaliza, não tem registros da primeira ocorrência do problema, frequência de ocorrência, quem reportou, enfim a formalização evita a reclamação do usuário que diz: “Já solicitei para várias pessoas da equipe a solução do problema e nenhuma delas de fato resolveu. Não consigo trabalhar, já tem um mês que reclamo e ninguém resolve.”
Os chamados ajudam você a ter métricas sobre o quanto seu serviço está sendo eficiente, quais os problemas mais comuns e quanto tempo você gasta para resolvê-los. Vejo que muitos gestores de TI não tem estas informações e desta forma não conseguem, por exemplo, justificar um incremento de pessoal ou solicitar aquisição de tecnologias que reduzam o tempo de solução dos problemas ou mesmo reduzam a inatividade dos usuários.
Se analisarmos a frequência de ocorrência dos problemas e a origem dos mesmos, podemos identificar situações onde uma pequena alteração em determinada configuração, ou um pequeno ajuste no sistema reduz sensivelmente a ocorrência de problemas. Ou ainda identificar que grande parte das ocorrências, são provenientes de deficiências de treinamento que você pode solucionar facilmente, através da criação de uma cartilha ou até mesmo realizando um treinamento na organização.
Outro benefício da formalização através de chamados é o histórico de solução do problema, essa base de conhecimento pode ser utilizada para o atendimento de futuros chamados, ou até mesmo subsidiar o próprio usuário para que ele mesmo resolva o problema.
Autor: Arles Sant Ana
Graduado em Ciência da Computação (PUC-GO), especialista em Gestão de Projetos (UCB), participou do Programa Nacional de Formação de Projetistas de Circuitos Integrados Digitais (NSCAD-UFRGS). Atua desde 1998 com Tecnologia da Informação em grandes empresas. Participou ao longo da carreira de diversos projetos de implementação de sistemas e tecnologias. Possui diversas certificações de mercado (Microsoft, Vmware, ITIL, Isaca, Cobit, Brocade)
