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 (por exemplo, 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
Vejo uma incoerencia nos gestores que levam as “boas práticas” ao pé da letra.
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
Interessante essa questão, Roberto.
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
Eu ainda olho para a v2, pois sou novato nessas práticas.
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.
Â
Nãoooo, Paulo.
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
Cohen,
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
Onde trabalho a ferramenta utilizada foi configurada para fechar um registro dentro de 48 horas após ser colocado como resolvido e nenhum outro contato tenha sido feito.
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.
Primeiramente, parabéns pelo blog, descobri tem poucos dias e vou acompanhar a criação do catalogo com vocês.
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
Olá pessoal, bom dia.
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,
Tatiana
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
Tenho uma dúvida no tratamento de chamados, por exemplo recebo uma requisição solicitando execução de um processo/job com data e horário determinado, o correto pelo ITIL é que eu deixe agendado o processo/job, pronto para ser executado e já encerro a solicitação ou devo aguardar a execução final do processo/job para depois encerrar? Falo isso por que na empresa que trabalho o pessoal pede para deixar em aberto o chamado e caso apresente sucesso na execução encerrar com a evidência do contrário caso termine com erro, deve-se encerrar o chamado de solicitação e abrir um outro novo chamado como incidente, acho isso tudo reduntante, ao meu ver deveráimos encerrar a solicitação assim que atendida independente se vai ou nao executar com sucesso, pois está sendo pedido apenas que execute.
Espero não estar falando blá.blá.blas… deu pra entender minha dúvida? rs
Obrigado e sucesso nos novos posts.
Olá, Ari.
Obrigado pelo seu contato.
Esqueça como o ITIL recomenda, etc.
Lembre-se que vocês precisam apenas fazer a coisa funcionar.
Não vejo motivo em abrir duas vezes a requisição, salvo se existem dificuldades para diferenciar os registros.
Talvez haja uma pequena confusão entre o que é gerenciamento de incidentes, mudanças e problemas. Esse terceiro sempre tem um registro aberto quando alguma coisa que está diferente do esperado acontece e busca descobrir como consertar isso para não mais acontecer.
Abs
Cohen
Boa tarde!
Eu já discordo de muitas pessoas aqui, se um cliente abre um chamado e o analista atua nele, e tenta por vários dias contato com o mesmo via telefone, e-mail e até interações pela sua ferramenta de chamado e o cliente não corresponde o chamado deve ser finalizado sim informando todas as interações realizadas.