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?