Help Desk Process = How to Handle Ticket =

1. Help Desk Process= How to Handle Ticket = LIneA Project Analyst Cristina Quartin Rio de Janeiro, 28/01/2013 (v1 em 18/01)

2. Agenda • Processo de Help Desk • Aplicativo Ticket e Formas de Acesso ao Aplicativo • Pontos Fortes do Ticket • Pontos Observados e Oportunidades de Melhoria

3. Help Desk Process O Processo de Help Desk é executado com suporte do aplicativo Ticket. Obs: qualquer alteração do ticket é enviado e-mail para solicitante???

4. Aplicativo Ticket

5. Campos do Ticket • Campos Existentes no Ticket • Summary • Description • Reporter • Type (defect, enhancement) • Priority (blocker, critical, minor, major,long term) • Milestone (QR v0.6, QR v0.7, QR v1.0, QR v1.1) • Component (BCC, Cluster, Data Server, Database, DES Portal Infrastructure, Documentation, DR9, E-mail account, E-mail list, E-mail List user, GA, GE, Hardware Problems, LSS, Network, New user accounts, Operations, Other, Password Recovery, Photo-z, Portal account, Processing, QA, Quick Reduce, Remove user, Software Problems, Twiki account, Web LIneA) • Owner (ana.marcela,angelofausti, carlosadean, cristinaq, ldacosta, machado,ogando, pbegeland, peloso, singulani, Valter) • Keywords • cc • ( ) I have files to attach to this ticket • Quando o ticket é cadastrado ele entra com status New. • Os seguintes campos são alterados pelos usuários ou automaticamente ao longo da execução dos tickets: • Status (new, accepted, assigned, reopened, closed) • Resolution Time (data) • Resolution (fixed, invalid, duplicated, worksforme,wontfix)

6. Exemplo

7. Outras Formas de Registro via Portal Obs: é necessário ter acesso ao portal para uso desta funcionalidade

8. Outras Formas de Registro via Portal Obs: é necessário ter acesso ao portal E ao aplicativo Ticket para uso desta funcionalidade

9. Pontos Fortes do Ticket • Envia e-mail para o solicitante do serviço em qualquer alteração de campo(s) • Customizável (aplicativo, consultas / filtros e relatórios) • Anexa arquivos • Permite troca de informações entre envolvidos

10. Pontos Observados

11. Pontos Observados • Um e-mail de solicitação de serviços pode gerar mais de uma demanda • Diferentes assuntos no mesmo ticket • Cabe ao atendente dar tratamento ao ticket ficando a seu critério a escolha de componente, prioridade, milestone. • Oportunidade de Melhoria: • Criar regras e definições para tratamento de ticket com apoio de SLA • Caso seja necessário o desmembramento do ticket, será efetuado pelo responsável do serviço / produto

12. Exemplo de SLA Figura 8 – Extrato do Catálogo de Serviços de Negócio (incluir responsável*)

13. Pontos Observados • Não existe um responsável formal definido para cada serviço / produto gerando dúvidas no momento da distribuição • Agilidade comprometida e interferências desnecessárias • Oportunidade de Melhoria: • Definição de responsável por serviço / produto. A atendente direciona para o responsável que escolhe quem será o recurso correto para a execução do serviço.

14. Pontos Observados • Não existe atendimento de 1.o e 2.o nível • Não usa classificação de incidentes x problemas x solicitação de serviços x orientação • Oportunidade de Melhoria: • Criação de categorias de atendimento apontando o nível de atendimento

15. Exemplo de Atendimento em Níveis • Os incidentes são categorizados com base no Catálogo de Serviços de Negócio, assim • como os problemas. • Orientações poderão ser tratadas pelo nível 1 da Central de Serviços registrando um chamado de atendimento rápido, sem necessidade de encaminhamento para o nível 2. Os incidentes serão tratados pelo nível 2 toda vez que o nível 1 não conseguir solucionar. Os problemas serão encaminhados para o nível 2 registrar a análise realizada, encaminhando em seguida para atendimento do nível 3.

16. Exemplo de Atendimento em Níveis

17. Exemplos de Categorização X

18. Diferença entre Incidentes e Problemas O Gerenciamento de Incidentes têm por objetivo restaurar a operação normal do serviço o mais rápido possível e garantir, desta forma, os melhores níveis de qualidade e disponibilidade do serviço.O Gerenciamento de Problemas tem por objetivo identificar e remover erros do ambiente de TI, através da busca da causa raiz dos incidentes registrados no Gerenciamento de Incidentes, a fim de garantir uma estabilidade máxima dos serviços de TI.Segundo o ITIL, incidente é qualquer evento que não faz parte da operação padrão de um serviço e que causa, ou pode causar, uma interrupção do serviço ou uma redução da sua qualidade; enquanto problema é a causa desconhecida de um ou mais incidentes, ou seja, um incidente que não tem sua causa raiz identificada acaba se tornando um problema.Enquanto o Gerenciamento de Incidentes tem como foco restabelecer o serviço o mais rápido possível, minimizando impactos na operação do negócio dentro dos níveis de serviços estabelecidos (para isso, pode ser usada, por exemplo, uma solução de contorno temporária), o Gerenciamento de Problemas é o processo responsável por controlar o ciclo de vida dos problemas, prevenindo sua ocorrência, eliminando incidentes repetitivos e reduzindo o impacto dos incidentes nos serviços, através da identificação da sua causa raiz.O processo de Gerenciamento de Problemas vai cuidar, portanto, da resolução definitiva e da prevenção de falhas que causam incidentes e afetam o funcionamento normal dos serviços de TI.Como exemplo, podemos usar a metáfora de uma goteira em casa num dia de chuva. Se começa a pingar água pela laje da casa, isto é um incidente. Para resolver o incidente de forma imediata, podemos colocar um balde d’água sob a goteira. Isto é uma solução de contorno, mas, não resolve a causa raiz do incidente. Depois que pára de chover, é possível identificar a causa raiz do incidente, que pode ser uma telha quebrada e tratar a solução definitiva do problema, efetuando a troca da telha, neste caso está sendo feito o gerenciamento do problema, pois, a causa raiz foi identificada e tratada.

19. Pontos Observados • Priorização de tickets não segue critérios bem definidos • Categorias x usuários • São executados acordo com alocação da equipe ou urgência, sem aplicação de critérios • Oportunidade de Melhoria: • Elaboração de critérios de priorização de acordo com categorias e usuários

20. Exemplo de Priorização do Atendimento

21. Pontos Observados • Não existe Base de Conhecimento de Incidentes e Problemas • Inexiste um registro condensado de incidentes e problemas (memória) padronizado e de fácil acesso • Oportunidade de Melhoria: • Criação de Base de Conhecimento de Incidentes e Problemas

22. Pontos Observados • Falta de padronização no tratamento dos campos do ticket • Campos (1) Summary, (2)Milestone, Component, Prioridade • Obs: algumas melhorias já estão sendo implantadas pelo Angelo no projeto QR. Exemplos: (1) [QuickReduce] Master cal on CTIO, • (2) QRv0.6, ... QRv1.0, QRv1.1 • Oportunidade de Melhoria: • Definição de regras e formatos padrão para preenchimento dos campos do ticket

23. Pontos Observados • Campo Component tem excesso de definições e mistura de conceitos • Classificação frágil • Ex: 1 - E-mail Account, TwikiAccount, Portal Account, • 2 – E-mail list x E-mail listuser, • 3 – Remove User , Password Recovery (ação), • 4 – Hardware problems (observar campo Type: [Defect]) • 4 – LSS, GA, QuickReduce (são complementos do Component Project porém, não existe campo para tal. No momento, registrado no campo Summary.) • Oportunidade de Melhoria: • Padronização na definição de componentes reduzindo-os ao máximo • Obs: seria possível criar campo Sub-Component???

24. Pontos Observados • Relatórios existentes são incompletos e não atendem às análises necessárias e acompanhamento dos tickets • Os relatórios gerenciais são efetuados via extração de dados diretamente da base de dados. • Oportunidade de Melhoria: • Customização de relatórios no próprio aplicativo para informar atendimento e tempos de resposta

25. Exemplo de Relatório Tempo de Resposta

26. Pontos Observados • O aplicativo não tem lógica definida, não permite controle no atendimento das demandas e não existem indicadores de desempenho ou alarmes para prazos de atendimento (tempo resposta). • Um ticket pode passar todo seu ciclo de vida com status new, mesmo tendo sido resolvido / concluído (o aplicativo permite) • Não existe um fluxo definido • Existe campo para definir data prevista para solução??? • Oportunidade de Melhoria: • Mapeamento do processo Help Desk com regras bem definidas para serem customizadas no Ticket • Criação de SLA (Service LevelAgreement) para definição de regras e acordos • Incluir plugin para vincular o ticket ao git (cruzamento de bugs e melhorias com commits de desenvolvedores, vínculo com projeto / versionadorgit)

27. Exemplo de SLA (cont.)

28. Exemplo de SLA (cont.)

29. Help Desk Process ITIL

30. Dúvidas Dúvidas?