Tratamento de tickets e conceitos relacionados

Este artigo contém os seguintes tópicos:

Como analista, você deve ter uma compreensão geral dos conceitos de gerenciamento de ticket. Este artigo fornece os conceitos de alto nível relacionados à manipulação de ticket no CA Cloud Service Management.

Processo de gerenciamento de tickets    

É possível registrar novas solicitações enviando um email para a ID de suporte designada ou pela interface de usuário do aplicativo. É possível registrar solicitações usando um item do catálogo relevante no Catálogo de serviços. As solicitações são roteadas para diferentes grupos de suporte com base nos seguintes critérios:

• Natureza da solicitação
• Como a solicitação foi criada
• Regras de roteamento

O administrador gerencia e controla as permissões e ações de fluxo de trabalho disponíveis para você. Com base na solicitação ou ocorrência, é possível criar uma solicitação de incidente, problema, mudança ou serviço. Também é possível criar um ticket de um tipo de ticket diferente de um ticket existente. O resultado é garantir que a solicitação seja tratada usando os processos apropriados em contratos de fornecimento de serviço acordados.

Ticket e ciclo de vida do ticket

Um ticket é um documento de transação que registra todas as informações relacionadas a uma solicitação. Os campos de ticket contêm informações necessárias para compreender e processar a solicitação do usuário final. O administrador pode configurar e adicionar campos personalizados para estarem disponíveis no ticket e se basearem na categorização de tickets. Quando um ticket é criado, ele é atribuído a um grupo de suporte. O administrador configura as regras de atribuição. Os três aspectos principais do andamento do ticket, que são usados na criação do processo de fluxo de trabalho são:

• Fase: durante o ciclo de vida do ticket, o ticket passa por diferentes fases. Com base em seu andamento, o ticket pode fazer autorretorno para uma fase anterior. As definições de fase diferem com base no tipo de ticket.
• Status: status se refere à etapa atual do ticket em seu ciclo de vida. Eles podem ser Novo, Na fila, Ativo, Pendente, Concluído, Resolvido, Fechado. Status de ticket fixos não podem ser modificados. Um ticket pode passar de um status para outro – não necessariamente em uma ordem específica.
• Código do motivo: o código do motivo é usado para atribuir um motivo por que um ticket está em um determinado status ou fase. Por exemplo, um ticket pode ser definido no status pendente por vários motivos, como Cliente pendente, Fornecedor pendente, Informações pendentes.

Uma combinação do status do ticket e código de motivo é usada para gerenciar as ações de fluxo de trabalho disponíveis e gerenciar o andamento do ticket. Conforme o ticket avança, ele cresce para incluir as atividades em relação à resolução, atendimento e fechamento da solicitação. O andamento do ticket também inclui ações manuais e automáticas e as comunicações de e para o ticket. O administrador pode configurar diferentes ações de fluxo de trabalho para ficarem disponíveis no ticket a fim de controlar o andamento do ticket.

Tipos de ticket

No CA Cloud Service Management, existem cinco tipos de tickets:

• Solicitação de serviço: Uma solicitação de serviço é usada para registrar e gerenciar solicitações padrão para informações ou acesso aos sistemas e serviços. As solicitações de serviço são tratadas por meio de processos de fluxo de trabalho de processamento de solicitação de serviço e são monitoradas para conformidade com SLA. Por exemplo, um usuário final busca obter informações sobre como instalar e configurar emails de trabalho para dispositivos móveis.

• Ticket de incidente: um ticket de incidente é usado para relatar e gerenciar ocorrências, como uma interrupção, indisponibilidade, redução na qualidade de um sistema ou serviço. Os tickets de incidente são tratados por meio de processos de fluxo de trabalho de gerenciamento de incidentes. A resposta e a resolução desses tickets são monitoradas para conformidade com SLA. Por exemplo, uma solicitação é registrada quando o usuário final não consegue enviar ou receber emails no celular. Este serviço está geralmente disponível para o solicitante; e o serviço foi interrompido. Identificar a causa da interrupção do serviço, restaurar o serviço rapidamente e se comunicar com o solicitante sobre a resolução.

• Ticket de problema: Um ticket de problema é usado para investigar, resolver ou reduzir os principais problemas que afetam vários usuários. Os tickets de problema são tratados por meio de processos de fluxo de trabalho de gerenciamento de problemas. Em geral, a análise e a resolução da causa raiz demoram; e esses tickets podem ou não podem ser monitorados quanto à conformidade com SLA.

• Requisição de mudança: Uma requisição de mudança é usada para registrar e gerenciar uma requisição de mudança na infraestrutura ou serviços de TI. Algumas mudanças podem afetar apenas o solicitante (ou um pequeno grupo de usuários); enquanto outras afetam vários usuários. Todas as requisições de mudança passam por um processo de aprovação da mudança. Com base na natureza da mudança, o processo de aprovação varia e será tratado usando processos de fluxo de trabalho de gerenciamento de mudança. Uma requisição de mudança pode ser monitorada para conformidade com SLA. O tempo necessário para responder e resolver uma alteração se baseia nos fatores como a obtenção de uma aprovação.

• Tickets de tarefas: Tickets de tarefas são usados para rastrear e gerenciar unidades menores de trabalho para a conclusão de outro ticket. Um ticket de tarefa é registrado como filho de outro ticket. Um ticket de tarefa é normalmente um ticket de mudança ou de problema. Cada tarefa pode ser realizada em uma hora por pessoas diferentes ou em uma sequência definida.
  
  

Ações de fluxo de trabalho e atribuição automática de Tickets

As regras de roteamento direcionam tickets recém-criados para as filas apropriadas de grupo de suporte. O roteamento baseia-se em condições de correspondência, como sua origem, prioridade, CCTI.

O administrador gerencia e configura as ações de fluxo de trabalho e as regras de atribuição automática responsáveis pela progressão e atribuição de tickets. Essa progressão e atribuição de tickets se baseiam no processo de tratamento de solicitações que é definido para cada tipo de ticket.

• Atribuição automática de tickets: as regras de atribuição automática direcionam os novos tickets para as filas apropriadas de grupos de suporte de acordo com as condições de correspondência, como o CCTI de origem e de prioridade. A categorização por CCTI também é importante para gerar relatórios. As regras de atribuição definem valores para campos como Fase, Status e Código do motivo. Algumas regras de atribuição possuem modelos de comunicação associados a elas; e enviam notificações quando um ticket é criado e atribuído às partes interessadas relevantes. 

• Ações de fluxo de trabalho: as ações de fluxo de trabalho são um conjunto de ações que podem ser executadas em um ticket. Quando uma ação do fluxo de trabalho é executada no ticket, alguns valores de campo são definidos conforme configurado; e o ticket é movido para o próximo estado. Elas são específicas para cada tipo de ticket e são um aspecto importante da criação do fluxo de trabalho. Os fluxos de trabalho são ações manuais disponibilizadas aos analistas ao atribuir permissões a diferentes grupos de suporte ou funções. Uma ação do fluxo de trabalho é configurada e disponibilizada em um ticket com base nas condições correspondentes, como Status, Código do motivo e Fase. Algumas opções de ações do fluxo de trabalho são disponibilizadas sem condições de correspondência em um ticket em qualquer estado.

As ações de fluxo de trabalho também podem ser configuradas para enviar notificações às partes interessadas. Alguns valores podem ser definidos como campos obrigatórios antes da execução da ação do fluxo de trabalho. Algumas opções de ação possuem funções especiais associadas, que automatizam ainda mais a execução de uma ação adicional (como Aceitar atribuição, Reatribuir).

Tipos de mudança e aprovação da mudança

A mudança é definida como uma adição, modificação ou remoção de um sistema ou serviço de TI existente. A mudança pode ser parte de sistemas de hardware ou software, configurações, acesso e assim por diante. Uma mudança pode ser reativa – em resposta a um problema ou proativa – para evitar possíveis problemas ou melhorar a prestação de serviços. Por exemplo, adicionar ou remover usuários de um sistema ou grupo; ou o provisionamento de sistemas para uma nova contratação.

A requisição de mudança pode ser classificada nos quatro tipos seguintes:

• Mudança padrão: este tipo de mudança é recomendável para solicitações comuns. Por exemplo, solicitação de um funcionário para a instalação de software ou acesso a um sistema ou banco de dados. Um Aprovador contextual ou um aprovador associado a um item de configuração aprova tais solicitações.
• Mudança normal: este tipo de mudança é recomendável para a implementação de mudanças proativas e planejadas. Por exemplo, implementação de novos sistemas de segurança de TI que afetam como os usuários acessam os recursos de TI por meio de VPN. Tal mudança exigiria uma investigação completa, planos de implementação de mudança detalhados, vários níveis de revisão e aprovação. Tal mudança exige tempo de inatividade potencial durante a implementação; e mudança implementada de análise pós-implementação.
• Mudança de emergência: este tipo de mudança é recomendável para situações reativas; onde a implementação de uma mudança é necessária para corrigir ou evitar um problema crítico. Por exemplo, se um servidor falha levando a tempo de inatividade para vários usuários, o servidor com defeito deve ser substituído. Em tais situações, é necessário um processo de aprovação e implementação mais rápido.
• Mudança de reparo imediato: este tipo de mudança é normalmente usado para relatar uma mudança após a implementação sem um processo de aprovação. Por exemplo, se a segurança de um servidor estiver comprometida, ele deve ser removido da rede. Uma mudança de reparo imediato não passa por um processo de aprovação e é usada apenas para registrar a mudança. A natureza de uma mudança é diferente e requer diferentes tipos de aprovação. Algumas mudanças precisam da aprovação de um aprovador contextual, como o gerente do solicitante; outras requerem vários níveis de aprovação. Às vezes, você solicita a aprovação de um ou todos os aprovadores. Tipos diferentes de aprovação podem ser associados a um ticket de mudança. Os tipos de aprovação que você pode definir são:
• Todos os aprovadores: quando esse tipo de aprovação é selecionado, TODOS os aprovadores devem aprovar o ticket. Se algum aprovador (até mesmo um entre todos os aprovadores atribuídos) rejeitar o ticket, o processo de aprovação terminará rejeitando a mudança.
• Qualquer aprovador: uma mudança é aprovada assim que UM aprovador a aprovar. A aprovação será rejeitada somente quando todos os aprovadores rejeitarem a proposta.
• Qualquer aprovação ou rejeição: um único aprovador do grupo de aprovação aprova ou rejeita uma mudança. A decisão do PRIMEIRO aprovador que responder (Aprovar ou Recusar) ao processo de aprovação é aplicada. O administrador configura as regras de aprovação dos diferentes tipos de alterações e os grupos de aprovação associados a uma mudança. Em alguns casos, é possível selecionar manualmente os aprovadores de uma mudança.

Itens de configuração e serviços afetados

Um item de configuração é qualquer componente de uma organização e sua infraestrutura de TI. Um IC gerencia e fornece um serviço de TI. Por exemplo, hardware, software, dispositivos de rede, periféricos e documentação. O CA Cloud Service Management cria e gerencia um registro de todos os itens de configuração na organização. Por exemplo, hosts de email, servidores e computadores cliente com softwares essenciais são necessários para entregar um serviço de email. Um registro de todos esses serviços é criado e salvo como um IC no CA Cloud Service Management.

Um item de configuração pode ser relacionado a um ou mais itens de configuração em diferentes domínios de relacionamento, como lógico, de rede, de energia ou de serviço. Essas informações podem ser usadas para solucionar problemas com o item de configuração. Quando um ticket é registrado para relatar uma ocorrência sobre um item de configuração, o IC pode ser relacionado ao ticket. Dessa forma, criando um histórico de incidentes, problemas e alterações que estão relacionadas ao IC que pode ser armazenado e recuperado. Se um ticket for registrado para relatar ocorrências em um serviço, o IC relevante pode ser relacionado ao ticket como 'serviço afetado'.

Os contatos podem ser relacionados a itens de configuração, como proprietário, usuário, aprovador da mudança, revisor da mudança e provedor de suporte. Os contatos associados com o IC como Aprovador da mudança e Revisor da mudança são usados como aprovadores contextuais para alterar os tickets relacionados a esse IC. O status de um item de configuração indica se o IC está em uso ou não. O status também especifica em qual estágio de seu ciclo de vida do IC está. Os itens de configuração em todos os status exceto Desprovisionado são visíveis para os analistas quando relacionarem um IC a um ticket.

Relacionamentos do ticket

Os relacionamentos do ticket se referem aos diferentes tipos de registros que podem ser relacionados a um ticket. Os tickets podem ser relacionados a outros tickets ou itens de configuração. Os anexos também podem ser relacionados para fornecer mais informações.

• Ticket - Relacionamento de ticket: Um ticket pode ser relacionado a outro ticket das três maneiras seguintes:
• Relacionamento pai - filho: Quando um novo ticket é criado a partir de um ticket existente - os dois compartilham um relacionamento pai-filho. Por exemplo, se um ticket de mudança for criado a partir de um ticket de problema. Um ticket de tarefa é criado apenas para completar unidades do trabalho em direção a outro ticket existente. Um ticket de tarefa é sempre registrado como um ticket filho.
• Relacionamento de ticket global: quando incidentes menores forem resultado de uma ocorrência maior, o ticket relatando a ocorrência principal pode ser marcado como global. Outros incidentes podem ser relacionados ao incidente global. Por exemplo, diferentes usuários registram vários tickets de incidente relatando perda da conectividade. Um incidente é registrado informando que o servidor de rede tem problemas de energia, esses problemas são todos devido ao incidente com o servidor de rede. Assim, resolver o servidor de rede corrige os incidentes relacionados. Portanto, o ticket registrado para o servidor de rede pode ser marcado como Global. É possível relacionar todos os incidentes ao ticket.
• Tickets relacionados: Os tickets também podem ser relacionados entre si por outros motivos. Por exemplo, dois tickets são registrados para um IC. A resolução de um ticket resulta ou não na resolução do outro ticket. Dois tickets podem ser relacionados entre si. Os tickets relativos permitem acesso fácil e mais visibilidade de todas as ocorrências conectadas a um item de configuração.
• Relacionamento Ticket - Item de configuração: O banco de dados de gerenciamento de configuração armazena registros de todos os sistemas e serviços de TI. As equipes de entrega de serviço e suporte de TI oferecem suporte a todos os sistemas e serviços de TI. Os tickets de serviços da equipe de suporte geralmente são para ocorrências ou assistência ao uso de um item de configuração com suporte no CMDB. Um ou mais itens de configuração podem ser relacionados a um ticket quando ele é registrado ou em qualquer ponto do ciclo de vida do ticket. É possível em um item de configuração e exibir os detalhes de seu registro. É possível exibir o relacionamento entre um IC e um ticket usando o gráfico de relacionamento de IC.

Notificações e log de atividades

Uma notificação é recebida quando um anexo é adicionado a um ticket que está atribuído a você. Quando o anexo é adicionado, ele também é registrado no log de atividades.  

Monitoramento de conformidade com SLA

O gerenciamento de nível de serviço lida com o processo de negociação dos acordos de nível de serviço e com a garantia de que eles sejam cumpridos. O gerenciamento de nível de serviço garante que todos os processos, acordos e contratos de apoio sejam adequados para as metas de nível de serviço acordadas. As metas de serviço definem o tempo alocado para uma determinada atividade, são medidas em relação às métricas de serviço definidas. Uma meta de serviço pode ter uma ou mais regras de limite. Uma das metas de serviço pode ser definida como Limite de violação, indicando que o SLA foi violado.

Fatores como o horário comercial do grupo de suporte e a disponibilidade do serviço controlam a medição do SLA. O ícone de progressão de meta de SLA exibe o andamento do status da meta. O ícone de progressão de meta de SLA também indica se um ticket está se aproximando da violação ou se violou a meta do SLA.

O administrador configura as regras de limite e o monitoramento de SLA de tickets. O administrador também pode configurar ações a serem executadas quando uma regra de limite for violada. As ações incluem o envio de notificações para diferentes partes interessadas ou escalonar o ticket para o próximo grupo de encaminhamento.

Artigos de conhecimento e base de conhecimento

O gerenciamento de conhecimento lida com a coleta, a análise e o armazenamento de conhecimento e informações em uma organização. Um artigo de conhecimento contém informações sobre solução de problemas que ocorrem com frequência ou que foram relatados anteriormente, instruções para configurar um serviço de TI. Os artigos de conhecimento também contêm notícias, detalhes da solução e sobre um sistema com suporte ou serviços. Os artigos de conhecimento podem ser disponibilizados para usuários, atribuindo permissões a funções ou grupos de suporte apropriados.

A base de conhecimento fornece informações sobre como tratar um incidente ou problema que ocorreu anteriormente. A base de conhecimento pode ser usada para acelerar o processo de resolução da ocorrência e melhorar a prestação de serviços.

Com as permissões necessárias, também é possível criar artigos de conhecimento. Todos os artigos são criados no estado Rascunho. Uma vez criados como um rascunho, todos os artigos da base de conhecimento podem ser revisados, refinados e definidos como Aprovado. Uma vez aprovado, um artigo de conhecimento pode ser disponibilizado para grupos de suporte ou funções diferentes. Também é possível sugerir soluções de tickets a serem incluídos na base de conhecimento. Os itens de soluções são adicionados à base de conhecimento no estado de rascunho.

Grupos de suporte e funções

Um grupo de suporte é um agrupamento de contatos de acordo com sua localização geográfica, conjuntos de habilidades ou tarefas relativas que executam. Tal agrupamento de contatos é usado para funções como roteamento de tickets com base em habilidades, atribuição de tickets, aprovação do ticket. Os grupos de suporte são usados para ações como notificações, permissões, aprovações, encaminhamentos de SLA e atribuição.

Uma função é um agrupamento de contatos e grupos de suporte com base nas outras funções que executam. Por exemplo, a função de gerenciamento de incidentes pode ser usada para gerenciar todas as funções relacionadas ao gerenciamento de incidentes. Os grupos de suporte que oferecem suporte L1, L2 (ou superior) e os supervisores que gerenciam equipes de analistas de suporte podem estar nessa função.

O administrador configura permissões como acesso a modelos de ticket, modelos de comunicação, ações do fluxo de trabalho, artigos de conhecimento. A permissão é dada diretamente ou por meio do grupo de suporte ao qual o usuário conectado pertence. Um contato pode ser relacionado a vários grupos de suporte e funções. Um contato herda as permissões atribuídas a cada grupo de suporte ou função relacionados.

Organização e segurança com base na organização

O CA Cloud Service Management oferece suporte a uma hierarquia de três níveis – organização/endereço/local – para o gerenciamento de informações sobre a organização. Uma organização pode ter vários sites, e cada um deles pode ter vários locais. Várias organizações, com seus próprios endereços e locais, podem ser configuradas na mesma instância do aplicativo.

Os usuários podem ser relacionados a um nível de organização, site ou local na hierarquia. Embora os usuários possam ser relacionados a várias organizações, uma delas precisa ser definida como a organização principal desse usuário. Vários recursos disponíveis para um usuário conectado, como a capacidade de participar de avaliações sobre o serviço, são gerenciados no nível da organização.

É possível exibir os tickets que os usuários de diferentes organizações registram. No entanto, o administrador do aplicativo pode ativar a segurança com base na organização para gerenciar a capacidade de exibir e trabalhar com tickets e itens de configuração. Quando a segurança com base na organização está ativada, é possível exibir os tickets e os ICs relacionados à organização que você pertence. Também é possível exibir os tickets relacionados aos grupos de suporte dos quais você for integrante.

Restrições

• O número máximo de tickets que pode criar simultaneamente é 50. 

• É possível incluir até 25 anexos em um ticket.

• É possível criar, no máximo, 1.000 logs de trabalho para cada ticket.

• O número máximo de exibições com base na função que podem ser criadas para cada tipo de ticket é 50.

• O número máximo de regras de atribuição automática que podem ser configuradas para cada fluxo de processo é 500. 

• O número máximo de ações de fluxo de trabalho que podem ser criadas para cada tipo de ticket é 500.

• O número máximo de modelos de campo personalizado que podem ser criados para cada tipo de ticket é 100.

• O número máximo de modelos de ticket (itens de catálogo) que podem ser criados para cada tipo de ticket é 1000.

• O número máximo de comunicações de saída por email que você pode enviar de um ticket é 1.000.