Há um tempo atrás, minha equipe foi convocada para uma reunião que visava melhorias no help-desk corporativo de onde estou trabalhando.
O chamado SPOC (single point of contact), conceito abordado em ITIL, até então parecia estar funcionando bem, com algumas exceções - isso na minha visão. Essa "certeza" durou pouco, e em menos de 5 minutos de conversa, entramos em várias questões e constatamos que havia muito o que evoluir.
Pra começar, e como o próprio nome já diz, o SPOC deve ser um ponto único de contato na resolução de incidentes ou no atendimento a serviços. Portanto, uma de suas premissas, é justamente o usuário receber atendimento de um mesmo ponto focal, sempre, até a conclusão do atendimento. Portanto, se o computador do Joaquim está travando, quem deverá ir em busca do solucionador para esse incidente é o atendente. O Joaquim deverá apenas relatar seu problema e aguardar a solução, não importa quantos departamentos se envolvam no caso.
Outro ponto que, justamente por estarmos falando de um help-desk corporativo, acaba acontecendo muito quando o atendimento está falho, é o usuário "ignorar" o help-desk e enviar e-mails diretamente para o departamento responsável, ou, no caso, no departamento que
ele julga o responsável. O que pode acabar tornando-se muito comum e desgastante.
Para ilustrar, imaginemos que o sistema de folha de pagamento da empresa comece a apresentar erros desconhecidos justamente no dia do fechamento mensal. Como o usuário não tem visibilidade de toda a estrutura por trás de um sistema, é normal que imaginem que o incidente deverá ser resolvido pelo departamento que foi responsável pelo desenvolvimento desse sistema, e reclamar diretamente com os analistas do setor. Os analistas, mesmo orientando os usuários quanto ao procedimento correto, acabam sendo "obrigados" a se envolver e buscar uma solução, pois até então não há nada que evidencie que a causa do problema está desassociada do sistema. Os analistas perdem tempo analisando o incidente, e depois de algumas horas buscando a causa diretamente no sistema, pode concluir, por exemplo, acionando outras equipes dentro da área de TI, que ocorreram atualizações e redefinições de segurança - em meio a outras dezenas que ocorrem mensalmente - nos servidores onde o sistema está hospedado, e por algum motivo não previsto tal melhoria acabou impactando no funcionamento das aplicações hospedadas nesses servidores e que, portanto, não é de responsabilidade da equipe que desenvolveu o sistema.
Por consequência, a satisfação do usuário sobre o sistema diminui, o mesmo acaba responsabilizando a equipe de desenvolvimento e ainda fazendo com que os analistas invistam tempo desnecessário analisando um problema que jamais iria ser identificado dentro da aplicação.
Esse é um caso dentre vários outros que podem ser muito comuns, principalmente quando a área de tecnologia da empresa possui certo nível de maturidade e é, consequentemente, descentralizada, com diversos departamentos: sistemas, infraestrutura, operações, banco de dados, administração de usuários e redes, e etc.
O papel do SPOC é essencial em casos como esse, e uma boa prática para auxiliar nesse processo é a separação do atendimento do help-desk em 3 níveis:
- Atendimento 1º nível - É o atendimento realizado pelo analista que faz a interface inicial com o usuário, que possui menos conhecimento técnico do que os analistas de segundo nível, no entanto um conhecimento genérico maior. O papel do analista de 1º nível é resolver problemas básicos por telefone ou remotamente e, se não resolver, saber filtrar e encaminhar para o departamento correto o problema reportado.
- Atendimento 2º nível - É o atendimento prestado pelo analista com maior conhecimento no assunto em questão. Os procedimentos serão realizados junto ao usuário, se for o caso, ou, no exemplo dado anteriormente, no servidor do sistema que ocorreu o problema.
- Atendimento 3º nível - É o atendimento prestado por um especialista. Quando nenhum dos outros 2 níveis conseguirem encontrar a solução para o incidente, o mesmo é encaminhado para o terceiro nível.
Assim, os especialistas - que são menor número na empresa - envolvem-se apenas nos problemas com maior criticidade, enquanto o 1º nível envolve-se em todos, direcionando para os devidos analistas o que não for de sua competência.
Vale ressaltar que, mesmo havendo o envolvimento de todos os níveis no atendimento de um incidente ou solicitação de serviço, quem deverá ser a interface do usuário com o setor de TI, é o 1º nível, preferencialmente o mesmo analista, evitando assim de o problema ter que ser reportado e explicado mais de uma vez. Quem fará então a busca da solução junto aos outros níveis e aos setores envolvidos é o analista de 1º nível.
Com uso do
SLA (service level agreement), mais um conceito de ITIL, o help-desk deverá estabelecer junto ao usuário um tempo para atendimento da solicitação em questão, levando em consideração severidade (relacionado aos impactos técnicos), prioridade (relacionado aos impactos no negócio) e, consequentemente, criticidade. Isso evita, por exemplo, as ligações para questionar se o problema já foi resolvido. É óbvio que o grande desafio aí, é o alinhamento de todas as áreas envolvidas para que o chamado seja realmente atendido respeitando o SLA.
Outro ponto abordado em ITIL, e que também aplica-se muito bem para o help-desk é a base de conhecimento (ou Knowledge Base). Todo o conhecimento adquirido, lições aprendidas, definição de conceitos técnicos e resolução de problemas devem ser inseridos no KB. A base de conhecimento poderá ser acessada e também abastecida pelos próprios usuários, facilitando a resolução de problemas sem envolvimento do help-desk e incentivando a cultura de compartilhar como resolver determinados incidentes. Reuniões semanais entre as equipes de analistas são importantes para
organizar e induzir o compartilhamento dessas informações, fazendo com
que problemas já conhecidos sejam atendidos com eficácia.
Ao fim da reunião, concluímos que o help-desk (ou
service-desk, que tem um papel mais abrangente que o help-desk) precisa, diante desses conceitos, atentar para 3 fatores:
- Interpretação:
O atendente de 1º nível pode de repente não saber como resolver um assunto, mas ele tem que entender do que o usuário está falando. Dentro de um ambiente onde centenas de softwares/sistemas são utilizados, é comum surgirem requisições de serviços para sistemas específicos, em que o 1º nível jamais estará capacitado para resolver. No entanto, é extremamente importante que o atendente compreenda cada ferramenta e assim entenda de fato o que o usuário quer.
O grande desafio aí, é que geralmente o help-desk é operado por uma consultoria, que não tem conhecimento e nem proximidade às mudanças que ocorrem dentro da empresa. A comunicação entre ambas as partes é essencial para que o help-desk esteja alinhado a realidade e atualizações da empresa. A questão da base de conhecimento é importante nesse aspecto. Uma prática que ilustra bem, é a criação de um script de atendimento para cada sistema que entra no ar dentro da empresa. Supondo que um novo sistema de requisição de férias entrou no ar: o departamento de desenvolvimento deve ter como obrigatoriedade antes de implantar o sistema, criar um roteiro conceitual e de atendimento, citando os módulos do sistema, e como proceder diante de um problema ou mesmo uma requisição (de cadastro de novo usuário, por exemplo).
- Direcionamento:
O exemplo utilizado no início do texto, onde o usuário reclama que a aplicação de folha de pagamento apresenta um erro, serve para ilustrar esse fator. A princípio a solução do incidente parece ser de responsabilidade da equipe de desenvolvedores, e ninguém mais. No entanto, se o help-desk estiver alinhado com todas as equipes, ele conseguirá entender e enxergar que o erro só ocorreu depois de uma mudança, que, no caso exemplificado, foi realizado por uma outra equipe de TI. Assim, é possível ver que é maior a probabilidade dessa equipe (e não a de desenvolvedores) ser a solucionadora desse problema. Isso não iria impedir que o help-desk direcionasse o chamado para outras equipes que talvez sejam as solucionadoras, no entanto, sabendo quem pode influenciar no caso reportado, ele envolve as pessoas corretas e reduz o tempo no diagnóstico da causa; e consequentemente no atendimento do chamado.
- Retorno:
Isso todos nós desejamos em qualquer tipo de solicitação. Seja quando ligamos pra solicitar um serviço no banco ou fazemos uma reclamação online à uma empresa de telefonia. O retorno é crucial para que o cliente (interno ou externo) sinta-se seguro com relação ao atendimento. É melhor entrar em contato para dizer que ainda estão atuando, do que simplesmente ignorar e deixar de posicionar o solicitante.
Poderíamos evoluir ainda mais se continuássemos destrinxando cada um desses tópicos, mas, a princípio, foi isso que destacamos para um mundo ideal, (ou quase ideal). E que por sinal também se
aplicaria muito bem em call centers que atendem o público em geral...
Aguardo comentários e novas abordagens sobre o assunto!
