Help Desk Process = How to Handle Ticket =

Apresentação em tema: "Help Desk Process = How to Handle Ticket ="— Transcrição da apresentação:

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 para solicitante???

4 Aplicativo Ticket

5 Campos do Ticket Campos Existentes no Ticket Summary Description
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, account, list, 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 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 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. Categoria Descrição Categoria / Serviços a que se referem Responsável pelo Primeiro Atendimento ou Redistribuição BCC Erro no pipeline BCC Cluster Erro no pipeline Cluster Ogando Data Server Erro no Data Server Database Erro no Banco de Dados DES Portal Infrastructure Problema de infraestrutura do Portal DES account Solicitação de nova conta de ou remoção Carlos GA Erro no pipeline GA GE Erro no pipeline GE Hardware Problems Problema de infraestrutura de Hardware, ex: Máquinas, memória, etc. Network Problema de rede, conexão e transferência de dados, etc. New user accounts Solicitação de novo usuário e contas associadas Operations POP, Energia, etc SLACAM Photo-z Erro no pipeline PhotoZ Fernanda Portal account Solicitação de nova conta no Portal ou remoção Quick Reduce Erro no pipeline Quick Reduce Angelo 

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

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) [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

23 Pontos Observados Campo Component tem excesso de definições e mistura de conceitos Classificação frágil Ex: 1 - Account, Twiki Account, Portal Account, 2 – list x 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???

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 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)

27 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: Ticket, TWiki, CIT, ... Criação e exclusão de 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 - ...

28 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 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. 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 ... Tempo de resposta para atendimento de: 1.o nível: até x dias; 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 acessos às máquinas do LIneA, deve ser entregue Formulário de Controle de Acesso*** (Anexo 2), preenchido pelo Coordenador do LIneA;  

29 Help Desk Process ITIL

30 Dúvidas Dúvidas?