Encerrar incidentes no ITIL V2 e V3
by El Cohen
Opa…
Tem coisa aí…
Na versão V2 do ITIL havia uma expressa recomendação para, após o incidente ter sido resolvido, encerrá-lo somente com a autorização/ permissão / concordância do usuário:
When the Incident has been resolved, the Service Desk should ensure that:
- details of the action taken to resolve the Incident are concise and readable
- classification is complete and accurate according to root cause
- resolution/action is agreed with the Customer – verbally or, preferably, by email or in writing
- (outros conselhos…)
Leram?
A versão 2 sugeria que o cliente (ou usuário) deveria concordar verbalmente (ou de preferência, por email ou escrito) que o incidente havia sido reaaaaaalmente resolvido (ou com as ações a seguir).
Bem, na versão 3 surge algo novo nas melhores práticas:
Note: Some organizations may chose to utilize an automatic closure period on specific, or even all, incidents (e.g. incident will be automatically closed after two working days if no further contact is made by the user). Where this approach is to be considered, it must first be fully discussed and agreed with the users – and widely publicized so that all users and IT staff are aware of this. It may be inappropriate to use this method for certain types of incidents – such as major incidents or those involving VIPs, etc.
E qual é a novidade?
Uma flexibilização do encerramento:
“Algumas organizações podem utilizar um período para encerramento automático de um ou todos os incidentes (o mesmo será automaticamente fechado após dois dias de trabalho sem qualquer retorno do usuário).”
Mas… Hein?!
Vejo um ponto positivo e outro negativo nesse registro.
Aspecto negativo
Primeiro, o aspecto negativo: a desenfreada e amalucada corrida de vários gestores para se adaptarem às melhores práticas da V2 sem ao menos pensarem no seu ambiente de trabalho.
Se isso parece coisa boba e irrelevante, imagine o impacto em muitos fornecedores de software que precisaram adaptar seus produtos para atender às necessidades do mercado (leia, gestores intransigentes nas “melhores práticas”).
Não foi ruim para os fornecedores, mas estarrecedora era a inflexibilidade do pessoal ao exigir tal função no produto.
Pense também na turma do Service Desk catando insistentemente o usuário para confirmar o encerramento do incidente. Ou as estatísticas dos prestadores de serviços de TI que precisam justificar um buzilhão de coisas.
Convém lembrar que reconhecido autor (eu, eu!!!) do livro “Implantação de Help Desk e Service Desk” já citava os problemas que poderiam surgir nesse rigorismo.
Na página 91 do livro:
“Alguns departamentos resolvem esse desinteresse estipulando um prazo para essa providência: dois ou três dias e então, se não ocorrer uma manifestação do usuário, encerram automaticamente o incidente.”
Ora pois, não é a mesma ideia do texto avermelhado mais acima?
Aspecto positivo
Como um conjunto de melhores práticas, o ITIL V3 moderniza-se. E acompanha os tempos pós-modernos.
Muita coisa mudou desde quando foi lançada a V2 para a V3.
E é inegável que o TEMPO sumiu. Escasseou.
A competição gerou isso. O imediatismo. Os cacarecos e gadgets também. Os mecanismos de rede social consomem nosso tempo (Orkut, Twitter, blogs, comunidades virtuais no ning e mais um formigueiro de outros troços). As tarefas acumulam-se. A quantidade de opções (para carro, software, cotonete e cerveja e outras coisas) aumentou e exige mais tempo na tomada de decisão.
Ora pois, nem sempre é possível consultar e obter retorno do usuário sobre o incidente.
Não estou estimulando o relaxamento dos processos.
Mas uma coisa mais aderente à realidade que vivemos. Ou na que vivo, pelo menos, hahaha.
E super-legal que o ITIL modernizar-se nisso. Agora só faltam os gestores, hehe.
Abraços,
El Cohen
Comentários
O negócio não pode ser muito engessado, pois existem casos específicos em alguns chamados.
Creio que não é saúdavel encerrar um chamado pelo fato do usuário não ter validado ou feito contato dentro de um período.
Imagino que sem a validação do principal envolvido(o usuário), estaremos envolvidos num ciclo vicioso e aumentando e muito o número de reabertura de chamados, pois a qualquer momento o usuário poderá ligar dizendo que a solução não foi satisfatória.
Se levarmos ao pé da letra acabaremos inventando um novo ciclo de vida dos incidentes, onde haverá a pergunta, houve validação do cliente?
Se sim, encerrar o chamado! se não, tambem encerrar o chamado…
Abraços,
Pois é, Diego…
Na ânsia de estar “aderente” às melhores práticas, muitos gestores olharam apenas para as orientações do ITIL e pouco para sua própria realidade.
É inegável que consultar o cliente/usuário sobre o encerramento do incidente é saudável. Colabora até mesmo em ouvir aquele tão agradável “agora tá tudo bem“.
Mas nem sempre isso é possível.
Extrapole a visão para um provedor de internet: um jovem usuário abre um incidente à noite e no dia seguinte não está em casa. Só a vó. Os custos da busca dessa confirmação podem ir à estratosfera.
Mas nem é esse xis da questão.
O xis era a necessidade de segurança dos gestores em afirmarem que estavam seguindo o que o ITIL recomenda.
E dessa maneira, estariam isentos de culpas ou mesmo a falta de percepção do seu próprio negócio.
Hehehe
Abrazon e valeu pela opinião!
EL CO
Veja o caso da Americanas.com: minha cunhada comprou um produto pelo site. Foi entregue outro. Reclamou. Vieram buscar. Após isso, demorou quase um mês para que mandassem o correto. Nesse período, toca ligar 2 ou 3 vezes por semana para saber o porquê da demora. Aí vem o problema: provavelmente por falta de integração dos sistemas e processos deles, ela tinha que sempre relatar um histórico do que havia ocorrido e eles não sabiam nada de nada.
Imagina, nesse caso, a quantidade de chamados que foram abertos e fechados SEM CONSULTA a minha cunhada!
Penso que, no fim das contas, o usuário quer que o problema seja resolvido, não importa qual o número do ticket, nome do analista, data etc, tenha ou não!
Grande abraço e parabéns pelo texto.
Wagner Pereira
http://www.twitter.com/wpereiratecno
É, Wagner.
E uma coisa surpreendente – pra mim, ao menos – é a DESINTEGRAÇÃO de sistemas nos grandes empreendimentos.
Obviamente somos de casa (TI). Sabemos o esforço que isso exige.
Mas também sabemos a quantidade de recursos que existem para fazer a coisa funcionar.
Pessoalmente, sou capaz de citar uns outros 10 big players do mercado cujos sistemas não se enxergam. No básico!
Daí o pessoal investe pra caramba em treinamento de processos, ITIL etc. e…
NÃO PENSA NO CARA LÁ DO OUTRO LADO!
Ughs.
El Co
Mas na prática, o incidente antes de fechar, remotamente, por exemplo, se o requerente não estiver presente, eu convido pelo menos dois colegas dele para certificar de que realmente não há mais nem resquício do que motivou a abertura e então fecho e coloco o nome dos “certificadores”. No meu caso cabe, não precisar ter contato com a vó do requerente.
Dois problemas:
Se eu for esperar o usuário entrar em contato comigo para eu fechar, ou agendar um outro momento, no meu caso, mpe’s do lojas, clínica, dristribuidora, varejo em geral, isso nunca vai acontecer, mesmo eu estando notificando o “camarada” por email, automaticamente.
Depois, isso pode afundar minha performance no SLA.
Por final, ao cadastrar o usuário, informo entre os três telefones que posso informar, o seu celular pessoal, normalmente corporativo – aquele que faz ele trabalhar até quando está de folga rsrsr. Então, de acordo com a expectativa da solução, ligo para o “camarada” que não estava no local e digo: Fulano, o chamado aberto será fechado sobre a “certificação” de seus colegas em 30min, caso você não esteja no local.
E ai Master? Feri a dona ITIL? rsrsrs.
Quando lí a dona ITIL ela se vendia como “benchmark” e não “receita de bolo”, mas está virando né não?
Sucesso ai Master, quando chegar em Belém eu mando aquele material pro Sr.
Você não feriu, bem pelo contrário.
Fez exatamente o que ela espera de você:
ADOTE. ADAPTE!!
Abraços e obrigado por compartilhar sua experiência
El Co
Conforme voce esclareceu:
… Uma flexibilização do encerramento:
“Algumas organizações podem utilizar um período para encerramento automático de um ou todos os incidentes (o mesmo será automaticamente fechado após dois dias de trabalho sem qualquer retorno do usuário).”
Mas… Hein?! …
A recomendação basica é sempre notificar por escrito, eu sempre recomendo o velho e bom email, com a ressalva de:
“Cada atividade realizada seja remota ou on-site, compreende em um Relatório de Atendimento (RAs) de Chamado Técnico (CTs) aberto anteriormente conforme Procedimento de Chamada e Suporte, constando em detalhes às ações realizadas, as pendências e as dificuldades encontradas. Este documento (RAs) é encaminhando por e-mail. A sua não contestação em 8 (oito) horas indicará a aceitação por parte do cliente da atividade realizada como concluído, se necessário será aberto um
novo Chamado Técnico (CTs).”
Ou seja, respeitou-se o usuário, manteve-se as métricas do suporte e existe a possibilidade de reabertura caso necessário.
Mas como voce mesmo disse, adapta-se, ajusta-se e vamos nessa. – A criatividade é o limite.
Nysten,
Você dá um prazo de 8 horas para contestação.
Mas o que acontece se o usuário adoecer? Ou estiver em viagem? Ou mesmo em reunião ou treinamento?
É importante não perder o foco do negócio para o qual trabalhamos, pois daqui a pouco pensaremos somente em nossos processos internos e forçaremos o negócio a se adaptar a nós, hehe.
Já imaginou encerrar o incidente e o problema persiste?
Vamos adiante que o debate está bueno, como dizemos aqui nos pampas!
El Cohen
O caminho é mais ou menos assim:
Usuário liga ou manda email informando um incidente, o registro é aberto e é, ou resolvido pelo telefone mesmo, ou encaminhado para outra equipe resolver. Ao resolver um chamado, o usuário recebe uma notificação por email informando que o chamado foi resolvido.
Após isso, o chamado permanece 48 horas aguardando ser reaberto. Se não for reaberto neste período, ele é fechado automaticamente e é enviado ao usuário uma pesquisa de satisfação.
A ferramenta utilizada é o Remedy da BMC.
O incidente deve e pode ser encerrado se:
- os detalhes do incidente foram precisamente registrados.. independente da solução, o incidente deve ser muito bem descrito no registro, sistema ou anotação.
- o antendente de primeira linha consiga definir uma causa do incidente pensando em analises futuras.
- o cliente e a equipe de suporte devem estar cientes da resolução ou não do incidente e se ele será caracterizado como um problema ou não para a equipe de suporte.
- se a equipe de suporte definiu que o incidente foi resolvido o cliente deve concordar com a solução. se não foi resolvido o cliente deve ser informado.
então.. desde o inicio o cliente tem boa participação no andamento do processo, o incidente pode ser fechado como resolvido ou não. porém o cliente deve ser avisado.
em uma tabela RACI o cliente é “C”, e “I” pra sua própria solicitação.
abraços
Tenho uma dúvida?
E quanto à permissões? Vou dar um exemplo, o chamado foi resolvido, quem poderia reabrir? É somente o usuário ou qualquer pessoa? Entendo que somente o usuário, que o chamado dos históricos é por patrimônio, porém o controle deveria ser por login no sistema, correto?
Obrigada,
Tudo depende.
Imagine que um técnico vá até a mesa do usuário por outro motivo e percebe algo com problema (um fio desencapado, uma régua de energia que vai dar zebra logo, logo).
Ele precisa pedir ao usuário para reabrir o chamado ou poderia ele mesmo intervir?
Abraços
Cohen