Arquivo da categoria: Gestão De Serviços

Matriz de Priorização no GLPI – Como é e Proposta de definição de SLA

Fonte: pexels.com

Esse post é uma atualização de um conteúdo criado lá em 2012 mas que, ainda em 2019, é muito acessado, requisitado e muitas dúvidas são colocadas em jogo semanalmente nas minhas inboxes. Até porque no momento em que mudei a plataforma do meu blog muitas formatações se perderam. Inclusive as tabelas daquele post.

Uma matriz de priorização de requisições e/ou incidentes é importante, no ponto de vista de um setor de serviços, por possibilitar um planejamento e organização da equipe para decidir qual chamado atender primeiro.

É importante deixar claro que após a parametrização completa do sistema com catálogo de serviços definindo o impacto automaticamente e o sistema definindo a prioridade baseado nessas regras a equipe precisa ser treinada a seguir a prioridade do sistema sem burlar o cálculo. Caso contrário, de nada adianta tais configurações.

Mas vamos lá.
Para entender o que o sistema faz começaremos descrevendo termos para que possamos definir parâmetros de prioridades.

O GLPI trata esse cálculo usando 2 parâmetros para definir automaticamente um 3º na seguinte ordem.

  • Impacto – É a medida de criticidade que aquele incidente ou requisição gera ao negócio principal da corporação. Ideal é que esse impacto seja definido via catálogo de serviços para evitar julgamentos subjetivos por parte da equipe ou dos usuários.
  • Urgência – É a referência de tempo que a equipe tem para restabelecer o serviço ou configurar a requisição para o cliente. Geralmente quem define esse parâmetro é o usuário. Mas é bem recomendado que um setor de triagem da equipe de serviços faça a revisão ou até defina essa Urgência antes de a equipe de N1 de fato agir.
  • Prioridade – Esse sim é o resultado da combinação entre o Impacto e a Urgência. Esse deve ser o balizador de qual chamado precisa de mais atenção que outro.

Você gostaria de ajudar o blog de alguma forma?

Análise do Impacto
Vamos definir o que são os impactos e como devemos entendê-lo no contexto da Gestão de Serviços.

Impacto no sistemaDescrição do Impacto
Muito AltoServiço que, quando não disponível, pode causar prejuízos monetários ou de patrimônio.
AltoServiço que, quando não disponível, pode gerar graves falhas em ativos ou outros serviços.
MédioServiço que, quando não disponível, causa um impacto moderado ao processo da empresa.
BaixoServiço que, quando não disponível, causa pouco ou nenhum impacto processo da empresa.
Muito BaixoServiço que, quando não disponível, não causa Impacto algum à corporação.

Análise da Urgência
A definição de Urgência também é importante para que a triagem e os usuários saibam quando escolher cada uma das definições.
Defina essas descrições e treine a triagem e usuários para que entendam que nos casos da coluna da direita, deve-se escolher a opção da esquerda.

Impacto no sistemaDescrição da Urgência
Muito AltoImpossível seguir trabalhando sem solução.
AltoO trabalho é possível de ser realizado sem a solução, mas com grave perda de eficiência ou recursos.
MédioO trabalho ainda é possível de ser realizado com pouca interferência sem solução.
BaixoO trabalho é totalmente possível de ser realizado sem solução.
Muito BaixoO trabalho é totalmente possível de ser realizado sem solução.

O cálculo da Matriz de Priorização do GLPI está configurado em Configurar > Geral > Assistência. Ele é totalmente configurável. Sendo possível, inclusive a retirada de opções de Impacto, Urgência ou Prioridades ou a mudança do cálculo para o que convier à organização. Por padrão o cálculo é definido da seguinte forma:

Nos campos de Listas suspensas do cabeçalho você pode desativar opções de Impacto. Nos campos de Listas suspensas da primeira coluna você pode desativar opções de Urgência. Nas linhas e colunas internas você pode mudar o comportamento do sistema.

Você gostaria de ajudar o blog de alguma forma?

Por padrão o sistema analisa o Impacto definido para o chamado, faz a triangulação com a Urgência definida e define um valor de Prioridade conforme este cálculo.

O que sempre proponho a alunos e clientes é definir os Impactos via Regras de negócio e posteriormente definir os SLAs pela Prioridade também via Regras de negócio, como no exemplo abaixo. (Os valores são figurativos. A definição desses tempos deve ser realizada com base em cada negócio, equipes envolvidas e capacidade de entrega.

PrioridadeTempo para atendimentoTempo para solução
Muito Alta2 horas para aceitar4 horas para solução
Alta4 horas para aceitar 8 horas para solução
Média8 horas para aceitar16 horas para solução
Baixa16 horas para aceitar20 horas para solução
Muito Baixa16 horas para aceitarsem data definida p/ solução

E a máxima sempre valerá:

O Treinamento CONSTANTE de equipe e de usuários pode ser dolorido e custoso mas sempre gerará resultados mais positivos no médio e longo prazo.
Abuse de documentação e a utilize para demonstrar importância e valor ao trabalho do setor de serviços.

Eu mesmO

Você gostaria de ajudar o blog de alguma forma?

➤ Site: https://www.arthurschaefer.com.br
➤ Instagram: https://instagram.com/arthurrschaefer
➤ Facebook: https://facebook.com/arthurschaefercombr
➤ LinkedIn: https://br.linkedin.com/in/arthurramosschaefer
➤ Twitter: https://www.twitter.com/arthurrschaefer
➤ Inscreva-se no Canal: https://www.youtube.com/ArthurSchaefer
➤ Canal no Telegram: https://t.me/arthurschaefer
➤ Baviera TI: https://www.bavierati.com.br

Padrão de Regras para atribuição de um chamado criado através de um coletor de correios no GLPi

Chamados não estão sendo abertos quando enviados por e-mail.

As vezes acabamos mexendo nas regras de atribuição de chamados por e-mail e não lembramos como era o padrão para que os chamados voltassem a ser abertos quando enviados por e-mail.

Segue abaixo o padrão do sistema.

Elas precisam estar nessa ordem.

Caso queira criar novas regras, as insira entre as regras 2 e 3 colocando as regras mais restritivas antes das menos restritivas.

A regra 3 , por boa prática, deve ficar por último pois é a que se aplica caso nenhuma das outras cumpra com algum requisito.

Regra 1:
 
Nome: Auto-Reply X-Auto-Response-Suppress
Operador lógico: e
Descrição: Exclude Auto-Reply emails using X-Auto-Response-Suppress header
Ativo: Sim
 
Critérios
Cabeçalho X-Auto-Response-Suppress do e-mail
verificado pela expressão regular
/\S+/
Ações
Rejeitar e-mail (sem e-mail de reposta)
Atribuir
Sim
 
 
 

Regra 2:
 
Nome: Auto-Reply Auto-Submitted
Operador lógico: e
Descrição: Exclude Auto-Reply emails using Auto-Submitted header
Ativo: Sim
 
Critérios
Cabeçalho Auto-Submitted do e-mail
verificado pela expressão regular
/\S+/
Cabeçalho Auto-Submitted do e-mail
não é
no
Ações
Rejeitar e-mail (sem e-mail de reposta)
Atribuir
Sim

Regra 3:
 
Nome: Root
Operador lógico: e
Descrição:
Ativo: Sim
 
Critérios
Cabeçalho Subject do e-mail
verificado pela expressão regular
/.*/
Ações
Entidade
Atribuir
Entidade Raíz
 
 

21.As 4 responsabilidades da TI ao criar um SLA

A TI possui responsabilidades quando na criação e manutenção de um SLA com seu cliente/usuário.

Nesse vídeo falo um pouco sobre isso. É um vídeo mais teórico mas que eu sempre quis fazer.

Espero que gostem.

Você gostaria de ajudar o blog de alguma forma?

➤ Site: https://www.arthurschaefer.com.br
➤ Instagram: https://instagram.com/arthurrschaefer
➤ Facebook: https://facebook.com/arthurschaefercombr
➤ LinkedIn: https://br.linkedin.com/in/arthurramosschaefer
➤ Twitter: https://www.twitter.com/arthurrschaefer
➤ Inscreva-se no Canal: https://www.youtube.com/ArthurSchaefer
➤ Canal no Telegram: https://t.me/arthurschaefer
➤ Baviera TI: https://www.bavierati.com.br