Help Desk Process= How to Handle Ticket =
LIneA Project AnalystCristina Quartin
Rio de Janeiro, 28/01/2013 (v1 em 18/01)
Agenda
• Processo de Help Desk
• Aplicativo Ticket e Formas de Acesso ao Aplicativo
• Pontos Fortes do Ticket
• Pontos Observados e Oportunidades de Melhoria
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???
Aplicativo Ticket
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)
Exemplo
Outras Formas de Registro via Portal
Obs: é necessário ter acesso ao portal para uso desta funcionalidade
Outras Formas de Registro via Portal
Obs: é necessário ter acesso ao portal E ao aplicativo Ticket para uso desta funcionalidade
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
Pontos Observados
Pontos Observados
1. 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
Exemplo de SLA
Figura 8 – Extrato do Catálogo de Serviços de Negócio (incluir responsável*)
Pontos Observados
2. 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.
Categoria Descrição Categoria / Serviços a que se referemResponsável pelo Primeiro
Atendimento ou Redistribuição
BCC Erro no pipeline BCC Cluster Erro no pipeline Cluster OgandoData Server Erro no Data Server Database Erro no Banco de Dados
DES Portal Infrastructure Problema de infraestrutura do Portal DES
E-mail account Solicitação de nova conta de email ou remoção CarlosGA Erro no pipeline GA GE Erro no pipeline GE
Hardware Problems Problema de infraestrutura de Hardware, ex: Máquinas, memória, etc. Carlos
Network Problema de rede, conexão e transferência de dados, etc.
New user accounts Solicitação de novo usuário e contas associadas CarlosOperations POP, Energia, etc SLACAMPhoto-z Erro no pipeline PhotoZ FernandaPortal account Solicitação de nova conta no Portal ou remoção CarlosQuick Reduce Erro no pipeline Quick Reduce Angelo
Pontos Observados
3. 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
Exemplo de Atendimento em Níveis
• Os incidentes são categorizados com base no Catálogo de Serviços de Negócio, assimcomo 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.
Exemplo de Atendimento em Níveis
Exemplos de Categorização
X
Diferença entre Incidentes e ProblemasO 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.
Pontos Observados
4. 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
Exemplo de Priorização do Atendimento
Pontos Observados
5. 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
Pontos Observados
6. 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) [Quick Reduce] 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
Pontos Observados
7. Campo Component tem excesso de definições e mistura de conceitos
• Classificação frágil
Ex: 1 - E-mail Account, Twiki Account, Portal Account, 2 – E-mail list x E-mail list user, 3 – Remove User , Password Recovery (ação),
4 – Hardware problems (observar campo Type: [Defect])4 – LSS, GA, Quick Reduce (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???
Pontos Observados
8. 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
Exemplo de Relatório Tempo de Resposta
Pontos Observados
9. 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 Level Agreement) 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 / versionador git)
Exemplo de SLA (cont.)
Nome do Serviço Help Desk
Descrição Serviço
Apoio aos usuários de serviços de negócio, ciência e TI do LIneA na resolução de problemas, problemas em projetos ou ativação de produtos / serviços. As categorias de tickets e responsáveis pelo primeiro atendimento ou redistribuição estão definidas no Anexo 1.
Disponibilidade do Serviço 7 dias p/ semana e 24 horas por dia
Repositório
Arquivos utilizados
Serviços suportados
Criação e exclusão de contas de usuário para as ferramentas: o Ticket, o TWiki,o CIT,o ...
Criação e exclusão de e-mail LIneA, Criação de acesso às máquinas de serviços e desenvolvimento, Resolução de problemas em equipamentos dos usuários LIneA, Resolução de problemas no desenvolvimento de projetos, Resolução de problemas de projetos encontrados pelos usuários, ....
Proprietário / Responsável
Equipe de TI: 1.o – Ana Marcela,2.o – Carlos,3.o - ...
Exemplo de SLA (cont.)Nome do Serviço Help Desk
Usuários do negócio Staff LIneA, Colaboradores Externos, Desenvolvedores, ...
Dinâmica do Serviço
A análise e distribuição dos tickets será realizada pelo responsável pelo serviço / produto em dias úteis – horário comercial e com 2 horários de corte: HH:00 am e HH:00 pm.Existem 2 tipos de atendimento:1.o nível – para os serviços x, y e z considerados como nível de complexidade baixo ou médio;2.o nível – para os serviços a, b, c considerados como nível de complexidade alto.
Nível de Garantia, ANS, RNS
1. No momento da criação de um ticket, o mesmo recebe Status = New. Este status não pode ultrapassar 24h, requerendo assim a devida distribuição.
Obs1: válido para dias úteis – horário comercial. Obs2: esse tempo pode variar caso haja dúvidas, por parte do responsável pela
distribuição, na questão do recurso que irá assumir o serviço e mediante o pronto suporte dos responsáveis pela indicação de novo recurso.
2. No caso de dúvidas na distribuição, o responsável por indicar o profissional de TI a executar o serviço será o ... ou ...
3. Tempo de resposta para atendimento de:o 1.o nível: até x dias;o 2.o nível: até z dias ou, em casos de problema com prévio
conhecimento da solução
Dependências
1 – no caso de criação / exclusão de contas de usuário, e-mail e acessos às máquinas do LIneA, deve ser entregue Formulário de Controle de Acesso*** (Anexo 2), preenchido pelo Coordenador do LIneA; 2 - ...
Help Desk Process ITIL
Dúvidas
Dúvidas?