Seu Template de dados de gestão de incidentes
Seu Template de dados de gestão de incidentes
- Atributos recomendados para coleta
- Principais atividades a acompanhar
- Orientações para extração no Jira Service Management
Atributos de gestão de incidentes
| Nome | Descrição | ||
|---|---|---|---|
|
Atividade
ActivityName
|
Nome do evento específico ou da alteração de status ocorrida no incidente. | ||
|
Descrição
A atividade representa uma etapa ou um evento específico no ciclo de vida do gerenciamento de incidentes, como 'Incidente criado', 'Incidente atribuído' ou 'Resolução proposta'. Em geral, ela é derivada de transições de status ou de eventos de atualização registrados no histórico ou no log de alterações da solicitação no Jira. Analisar a sequência e a duração dessas atividades é o principal objetivo do Process Mining, pois revela o fluxo real do processo, os gargalos e os desvios.
Por que isso importa
As atividades formam a base do mapa de processos e permitem visualizar e analisar o ciclo de vida do incidente.
Onde encontrar
Derivado do histórico da solicitação e dos dados do log de alterações do Jira, registrando transições de status e atualizações de campos importantes.
Exemplos
Incidente atribuídoInvestigação iniciadaIncidente resolvido
|
|||
|
Hora de início
EventTimestamp
|
Data e hora exatas em que a atividade ocorreu. | ||
|
Descrição
Este atributo registra a data e a hora de cada atividade no ciclo de vida do incidente. Ele é essencial para calcular durações, tempos de ciclo e tempos de espera entre as etapas do processo. Registros precisos permitem analisar a performance em detalhes, monitorar SLAs e identificar gargalos. Todas as métricas de performance, como o tempo de resolução e a duração do diagnóstico, são calculadas com base nesses registros.
Por que isso importa
Os registros de data e hora são essenciais para calcular métricas de tempo, entender a duração do processo e identificar gargalos de performance.
Onde encontrar
Esta é a data de 'criação' associada a cada entrada no histórico ou no log de alterações da solicitação no Jira.
Exemplos
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
ID do incidente
IncidentId
|
Identificador exclusivo de cada chamado de incidente no Jira Service Management. | ||
|
Descrição
O ID do incidente, muitas vezes chamado de chave da solicitação no Jira, é o identificador exclusivo principal de cada incidente reportado. Ele conecta todas as atividades, os comentários e as alterações de status relacionados, desde a criação até o encerramento. No Process Mining, esse ID é essencial para reconstruir o ciclo de vida completo de cada incidente e permitir uma análise abrangente de todo o processo.
Por que isso importa
Esse é o identificador principal usado para correlacionar todos os eventos relacionados em um único caso, servindo de base para qualquer análise de Process Mining.
Onde encontrar
Este é o campo padrão 'Chave' de uma solicitação no Jira Service Management (por exemplo, 'ITSM-123').
Exemplos
INC-10234HELPDESK-5678OPS-9901
|
|||
|
Sistema de origem
SourceSystem
|
Sistema do qual os dados foram extraídos. | ||
|
Descrição
Este atributo identifica a origem dos dados, que neste caso é o Jira Service Management. Ele é especialmente útil quando dados de vários sistemas são combinados para oferecer uma visão abrangente do processo. Especificar o sistema de origem deixa a linhagem dos dados clara e ajuda a diagnosticar problemas de qualidade ou extração. Neste modelo, o valor é fixo.
Por que isso importa
Fornece contexto essencial sobre a origem dos dados, garantindo clareza e rastreabilidade, especialmente em análises que envolvem vários sistemas.
Onde encontrar
Este é um valor fixo, que deve ser adicionado durante a extração dos dados.
Exemplos
Jira Service ManagementJira Cloud
|
|||
|
Última atualização dos dados
LastDataUpdate
|
Data e hora da última atualização dos dados extraídos do sistema de origem. | ||
|
Descrição
Este atributo registra quando o conjunto de dados foi atualizado pela última vez. Ele informa a quem analisa o processo se os dados estão atualizados. Isso é especialmente importante em Dashboards de monitoramento contínuo, nos quais informações recentes são essenciais para tomar decisões no momento certo. Em geral, o valor é igual para todos os eventos de uma mesma extração de dados.
Por que isso importa
Informa se os dados estão atualizados, algo essencial para a relevância e a precisão da análise.
Onde encontrar
Esta é a data e a hora da extração dos dados, adicionadas durante a transformação dos dados.
Exemplos
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Data de criação
CreatedDate
|
Data e hora em que o incidente foi criado pela primeira vez no sistema. | ||
|
Descrição
Este atributo marca o início oficial do ciclo de vida do incidente. É a data e a hora de referência para calcular métricas gerais, como o tempo total de resolução. A data de criação é fixa para cada incidente e marca o início de todo o caso na análise de Process Mining.
Por que isso importa
Serve como ponto de partida para calcular o tempo de ciclo completo e medir os SLAs.
Onde encontrar
O campo padrão 'Criado' de uma solicitação no Jira.
Exemplos
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
Data de resolução
ResolutionDate
|
Data e hora em que o incidente foi marcado como resolvido. | ||
|
Descrição
Este atributo registra a data e a hora em que o incidente passou pela primeira vez para um status de resolvido. Ele marca o fim da etapa de trabalho ativo e serve como ponto final para calcular o tempo até a resolução. Comparar a data de resolução com a data de criação é a principal forma de medir a eficiência do processo. Esse dado também é essencial para determinar a conformidade com o SLA.
Por que isso importa
Marca o fim do processo de resolução e permite calcular o tempo total de ciclo e a performance do SLA.
Onde encontrar
O campo padrão 'Resolvido' de uma solicitação no Jira.
Exemplos
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
Grupo de atribuição
AssignmentGroup
|
Equipe ou grupo responsável por tratar o incidente. | ||
|
Descrição
O grupo de atribuição representa a equipe responsável pelo incidente. Pode ser um nível de suporte, como 'Central de suporte N1', uma equipe especializada, como 'Operações de rede', ou uma equipe de desenvolvimento. Analisar as transições entre grupos de atribuição é essencial para entender os escalonamentos e as transferências no processo. Isso permite medir a performance das equipes, identificar gargalos em cada equipe e analisar as dependências entre elas.
Por que isso importa
Essencial para analisar a performance das equipes, o volume de trabalho concluído e o fluxo de trabalho entre diferentes níveis de suporte ou grupos especializados.
Onde encontrar
Geralmente, esse campo é personalizado no Jira, com nomes como 'Equipe' ou 'Grupo de atribuição'. Em alguns casos, ele pode ser derivado dos componentes do Jira ou das funções do projeto.
Exemplos
Suporte de nível 1Equipe de infraestruturaAdministradores de banco de dados
|
|||
|
Prioridade
Priority
|
Nível de prioridade atribuído ao incidente, que indica a urgência da resolução. | ||
|
Descrição
A prioridade determina a rapidez necessária para tratar um incidente. Em geral, ela combina impacto e urgência e influencia diretamente as metas de SLA. Analisar os incidentes por prioridade ajuda a entender se os de alta prioridade são tratados mais rapidamente que os de baixa prioridade e se a priorização é aplicada de forma consistente. É uma dimensão essencial para filtrar e comparar a performance do processo.
Por que isso importa
Essencial para analisar a performance do SLA e verificar se os recursos estão sendo alocados corretamente aos incidentes mais críticos.
Onde encontrar
O campo padrão 'Prioridade' de uma solicitação no Jira.
Exemplos
Mais altaAltaMédiaBaixa
|
|||
|
Responsável
Assignee
|
Usuário atualmente responsável por trabalhar no incidente. | ||
|
Descrição
O responsável é o agente ou usuário encarregado do incidente em determinado momento. Acompanhar as mudanças de responsável é essencial para analisar transferências, entender a distribuição da carga de trabalho e identificar quem participa de etapas específicas do processo. Este atributo ajuda a responder perguntas sobre a performance individual e a alocação de recursos nas equipes de suporte.
Por que isso importa
Ajuda a acompanhar a carga de trabalho individual, identificar gargalos relacionados a agentes específicos e analisar o impacto das transferências no tempo de resolução.
Onde encontrar
O campo padrão 'Responsável' de uma solicitação no Jira.
Exemplos
John SmithEmily JonesServiceDeskAgent1
|
|||
|
Status
Status
|
Etapa atual do incidente no ciclo de vida. | ||
|
Descrição
O campo de status indica o estado atual de um incidente no Workflow definido, como 'Aberto', 'Em andamento', 'Aguardando cliente' ou 'Resolvido'. As alterações de status são a principal fonte para gerar o registro de atividades usado no Process Mining. Analisar o tempo em cada status é fundamental para identificar gargalos e entender em quais etapas os incidentes passam mais tempo.
Por que isso importa
Reflete diretamente o andamento do incidente e é a principal fonte para identificar etapas do processo e tempos de espera.
Onde encontrar
O campo padrão 'Status' de uma solicitação no Jira.
Exemplos
Em andamentoAguardando o clienteResolvidoFechado
|
|||
|
Categoria da causa raiz
RootCauseCategory
|
Classificação da causa raiz do incidente. | ||
|
Descrição
Este atributo registra o motivo fundamental do incidente, como 'Falha de software', 'Falha de hardware' ou 'Erro do usuário'. Em geral, ele é preenchido após a investigação e é essencial para gerenciar problemas de forma eficaz e evitar novos incidentes. Analisar as categorias de causa raiz ajuda a identificar fragilidades sistêmicas e priorizar iniciativas de melhoria. Uma alta proporção de causas raiz 'Desconhecidas' pode indicar a necessidade de aprimorar os processos de investigação.
Por que isso importa
Permite fazer a análise de causa raiz e adotar uma abordagem proativa, identificando e tratando as origens dos incidentes para evitar que se repitam.
Onde encontrar
Quase sempre, este é um campo personalizado no Jira. O nome e as opções dependem muito da configuração específica da organização.
Exemplos
Erro de configuraçãoIndisponibilidade da redeBug de software
|
|||
|
Componente
Component
|
Sistema, aplicativo ou parte da infraestrutura afetada pelo incidente. | ||
|
Descrição
Os componentes são subdivisões de um projeto do Jira usadas para agrupar solicitações em partes menores, como 'Interface do usuário', 'Banco de dados' ou 'API'. Analisar os incidentes por componente ajuda a identificar quais partes de um sistema apresentam mais problemas. Essas informações são úteis para a análise de causa raiz e podem orientar iniciativas de melhoria do serviço ou redução da dívida técnica.
Por que isso importa
Permite filtrar e analisar os dados pela área específica do produto ou sistema afetada, ajudando a identificar pontos críticos de tecnologia.
Onde encontrar
O campo padrão 'Componentes' de uma solicitação no Jira.
Exemplos
Serviço de autenticaçãoDashboard de relatóriosAplicativo móvel
|
|||
|
É retrabalho
IsRework
|
Indicador que informa se o incidente passou por retrabalho, como ser reaberto. | ||
|
Descrição
Este atributo booleano calculado identifica incidentes que voltaram a uma etapa anterior do processo, geralmente por terem sido reabertos após a resolução. Os ciclos de retrabalho são uma fonte importante de ineficiência e insatisfação dos clientes. Este indicador facilita o cálculo da taxa de retrabalho e ajuda a direcionar a análise para entender por que os incidentes não são resolvidos corretamente na primeira tentativa.
Por que isso importa
Destaca problemas de qualidade e ineficiências no processo ao sinalizar incidentes que exigem trabalho repetido, apoiando diretamente a análise de retrabalho.
Onde encontrar
Calculado pela identificação de sequências específicas de mudanças de status no registro de eventos, como 'Resolved' -> 'Reopened'.
Exemplos
truefalse
|
|||
|
Gravidade
Severity
|
Medida do impacto do incidente nos negócios. | ||
|
Descrição
A gravidade indica o impacto do incidente nos negócios, desde um problema que afeta uma única pessoa até a indisponibilidade de um sistema crítico. Enquanto a prioridade determina a ordem do trabalho, a gravidade indica o impacto geral nos negócios. Analisar os incidentes por gravidade ajuda a entender a performance do processo nos casos mais importantes para a organização. Muitas vezes, essa análise é combinada com a prioridade para oferecer uma visão mais detalhada.
Por que isso importa
Mostra o impacto nos negócios e permite concentrar a análise nos incidentes que mais prejudicam as operações.
Onde encontrar
Geralmente, é um campo personalizado no Jira, pois não faz parte dos campos padrão do sistema. Consulte a configuração do projeto no Jira Service Management.
Exemplos
CríticoGraveLeveMínimo
|
|||
|
ID do problema vinculado
LinkedProblemId
|
Identificador de um chamado de problema vinculado a este incidente. | ||
|
Descrição
Incidentes que são sintomas de um problema maior e subjacente costumam ser vinculados a um chamado de problema. Este campo armazena o ID do problema associado. Analisar esses vínculos ajuda a entender a relação entre incidentes e problemas, medir a eficácia do processo de gerenciamento de problemas e identificar incidentes recorrentes que precisam de uma correção definitiva.
Por que isso importa
Vincula incidentes aos problemas subjacentes e permite analisar a eficácia com que a organização trata as causas raiz para evitar novos incidentes.
Onde encontrar
Essas informações ficam armazenadas na seção 'Vínculos da solicitação' de uma solicitação no Jira.
Exemplos
PROB-123PROB-456Nenhum
|
|||
|
Meta de tempo até a resolução
TimeToResolutionTarget
|
Duração definida como meta de SLA para resolver o incidente. | ||
|
Descrição
Este atributo define o tempo máximo esperado para resolver um incidente de determinada prioridade ou tipo. Ele serve de referência para comparar o tempo real de resolução e determinar a conformidade com o SLA. Em geral, esse valor é definido dinamicamente com base em regras que consideram fatores como prioridade, gravidade ou tipo de solicitação. É fundamental para qualquer Dashboard de monitoramento da performance do SLA.
Por que isso importa
Serve de referência para medir a conformidade com o SLA e fundamenta o KPI de taxa de violação do SLA de incidentes.
Onde encontrar
Este valor é obtido da configuração de SLA no Jira Service Management. É preciso identificar a meta específica, como 'Tempo até a resolução'.
Exemplos
4h8h3d
|
|||
|
Número de transferências
HandoffCount
|
Número de vezes que o incidente foi reatribuído a outro grupo ou usuário. | ||
|
Descrição
Esta métrica calculada conta quantas vezes os campos 'Assignee' ou 'AssignmentGroup' mudaram durante o ciclo de vida do incidente. Um número elevado de transferências costuma indicar ineficiência no processo, baixa resolução no primeiro contato ou lacunas de conhecimento, o que aumenta o tempo de resolução. Analisar este KPI ajuda a simplificar o processo de atribuição e melhorar a colaboração entre as equipes.
Por que isso importa
Quantifica os atritos e as ineficiências causados por reatribuições, ajudando a identificar oportunidades de melhoria do processo.
Onde encontrar
Calculado contando o número de alterações no campo 'Assignee' ou 'AssignmentGroup' no histórico de alterações do chamado.
Exemplos
015
|
|||
|
Resolução
Resolution
|
Resultado final ou motivo da resolução do incidente. | ||
|
Descrição
O campo de resolução explica por que um incidente passou para o estado resolvido. Entre os valores comuns estão 'Corrigido', 'Duplicado', 'Não será feito' e 'Não foi possível reproduzir'. Analisar a distribuição dos tipos de resolução pode revelar insights sobre a qualidade dos relatos recebidos e a eficácia do processo de resolução. Por exemplo, um número elevado de resoluções como 'Duplicado' pode indicar um problema na criação ou na triagem de incidentes.
Por que isso importa
Dá contexto ao resultado do incidente, ajudando a categorizar as resoluções e identificar tendências na forma como os incidentes são encerrados.
Onde encontrar
O campo padrão 'Resolução' de uma solicitação no Jira. Em geral, esse campo é definido quando a solicitação passa para uma categoria de status 'Concluído'.
Exemplos
ConcluídoCorrigidoDuplicadoNão será corrigido
|
|||
|
Solicitante
Reporter
|
Usuário que criou ou reportou o incidente inicialmente. | ||
|
Descrição
O solicitante é a pessoa, geralmente um usuário final, ou outro sistema que registrou o incidente pela primeira vez. Analisar os incidentes por solicitante pode ajudar a identificar usuários ou departamentos que enfrentam problemas com frequência. Também permite entender padrões de comunicação, especialmente ao analisar atividades como 'Aguardando o cliente' e 'Cliente respondeu'.
Por que isso importa
Ajuda a analisar a origem dos incidentes, identificar padrões relacionados a usuários ou departamentos específicos e entender atrasos na interação com clientes.
Onde encontrar
O campo padrão 'Solicitante' de uma solicitação no Jira.
Exemplos
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
Tipo de solicitação
IssueType
|
Tipo de solicitação, como incidente, solicitação de serviço ou problema. | ||
|
Descrição
O Jira usa tipos de solicitação para diferenciar as categorias de trabalho. No gerenciamento de incidentes, o tipo principal é 'Incidente', mas outros, como 'Subtarefa', também podem ser relevantes. Este atributo é essencial para filtrar o conjunto de dados e incluir apenas incidentes, garantindo que a análise de Process Mining se concentre no processo correto.
Por que isso importa
Garante que a análise se concentre nos incidentes, separando-os de outros tipos de trabalho, como solicitações de serviço ou mudanças.
Onde encontrar
O campo padrão 'Tipo de solicitação' de uma solicitação no Jira.
Exemplos
IncidenteAjuda de TIBug
|
|||
|
Tipo de solicitação do cliente
CustomerRequestType
|
Tipo específico de solicitação enviada pelo cliente pelo portal de serviços. | ||
|
Descrição
Este campo categoriza as solicitações do ponto de vista do cliente, conforme aparecem no portal do Jira Service Management (por exemplo, 'Relatar um problema no sistema'). Ele oferece uma classificação fácil de entender, que pode ser diferente do 'Tipo de solicitação' interno. Analisar esse atributo pode revelar como os clientes percebem e relatam problemas, ajudando a melhorar o portal e os serviços oferecidos.
Por que isso importa
Oferece uma visão das categorias de incidentes sob a perspectiva do cliente, útil para analisar a demanda e melhorar a experiência do cliente.
Onde encontrar
O campo 'Tipo de solicitação do cliente', específico dos projetos do Jira Service Management.
Exemplos
Obter ajuda de TI > Relatar um problema no sistemaE-mail > Solicitação de acesso
|
|||
|
Violação do SLA
SlaBreach
|
Indicador de que o tempo de resolução do incidente ultrapassou a meta do SLA. | ||
|
Descrição
Este atributo booleano calculado indica se o incidente ultrapassou o SLA de 'Tempo até a resolução'. O valor é verdadeiro quando 'IncidentResolutionCycleTime' é maior que 'TimeToResolutionTarget'. Esse indicador simplifica a análise e a visualização, facilitando a filtragem e a agregação dos dados para calcular o KPI de taxa geral de violação do SLA. É a principal medida de resultado do Dashboard de monitoramento da performance do SLA.
Por que isso importa
Apresenta um resultado claro, com duas possibilidades, para a performance do SLA, facilitando o cálculo das taxas de violação e a identificação de problemas.
Onde encontrar
Calculado como ('IncidentResolutionCycleTime' > 'TimeToResolutionTarget').
Exemplos
truefalse
|
|||
Atividades de gestão de incidentes
| Atividade | Descrição | ||
|---|---|---|---|
|
Aguardando o cliente
|
Marca o momento em que a equipe de suporte aguarda informações ou uma ação do cliente. Esse evento é identificado pela mudança para um status específico de espera, como 'Waiting for customer'. | ||
|
Por que isso importa
Isolar esse tempo de espera é essencial para medir o SLA com precisão, pois ele costuma ser excluído dos cálculos do tempo de resolução. Isso também ajuda a analisar atrasos nas respostas dos clientes.
Onde encontrar
Identificado no histórico de alterações de status da solicitação. O evento corresponde à data e hora em que o status muda para 'Waiting for customer' ou outro status semelhante.
Coleta
Identifique a data e hora da mudança de status para 'Waiting for customer'.
Tipo de evento
inferred
|
|||
|
Incidente criado
|
Marca o início oficial do ciclo de vida do incidente, quando um relato é enviado e uma nova solicitação é criada no Jira. Esse evento é registrado explicitamente quando uma nova solicitação do tipo 'Incident' é criada no sistema. | ||
|
Por que isso importa
Este é o evento de início principal do processo. Analisar o tempo entre esta atividade e a resolução é fundamental para medir o tempo de ciclo geral e a adesão aos SLAs.
Onde encontrar
Este é um evento explícito, registrado com base na data e hora de criação da solicitação de incidente no Jira. O evento de criação fica registrado no histórico da solicitação.
Coleta
Use a data e hora de criação da solicitação.
Tipo de evento
explicit
|
|||
|
Incidente encerrado
|
Representa o encerramento administrativo final do chamado do incidente, após a resolução e a verificação. Esse evento é identificado pela mudança de status para 'Closed'. | ||
|
Por que isso importa
Este é o evento final do processo. Analisar o tempo entre 'Resolved' e 'Closed' pode revelar atrasos na finalização administrativa ou na confirmação do usuário.
Onde encontrar
Inferido do histórico de alterações de status da solicitação. O evento corresponde ao momento em que o status muda para o estado final 'Fechado'.
Coleta
Identifique o momento em que o status muda para 'Fechado'.
Tipo de evento
inferred
|
|||
|
Incidente reatribuído
|
Ocorre quando um incidente é transferido para outro agente ou grupo após a atribuição inicial. Esse evento é identificado por qualquer alteração no campo 'Assignee' ou 'Assigned Group'. | ||
|
Por que isso importa
Acompanhar as reatribuições é essencial para analisar os handoffs. Um número elevado de reatribuições costuma indicar ineficiências no processo, lacunas de conhecimento ou encaminhamento inicial incorreto, o que atrasa a resolução.
Onde encontrar
Identificado no histórico da solicitação por qualquer atualização do campo 'Assignee' após o primeiro preenchimento. Cada alteração representa um evento de reatribuição.
Coleta
Identifique as alterações posteriores no campo 'Assignee' após a atribuição inicial.
Tipo de evento
inferred
|
|||
|
Incidente resolvido
|
Esta atividade confirma que o incidente foi resolvido e o serviço, restabelecido. Em geral, ela coincide com a mudança para o status 'Resolved'. | ||
|
Por que isso importa
Este é o principal marco de sucesso do processo. O tempo até este ponto é um dos KPIs mais usados e representa o tempo até a resolução (TTR).
Onde encontrar
Identificado pela mudança de status para 'Resolved'. Em muitos fluxos de trabalho, este é o mesmo evento que 'Resolution Proposed' e representa o principal momento da resolução.
Coleta
Identifique a data e hora da mudança de status para 'Resolved'.
Tipo de evento
inferred
|
|||
|
Investigação iniciada
|
Indica que o agente responsável começou a investigar ativamente o incidente. Em geral, esse evento é identificado quando o status da solicitação muda de 'Open' ou 'New' para 'In Progress'. | ||
|
Por que isso importa
Este marco importante indica o início dos esforços ativos de resolução. Medir o tempo até esta atividade ajuda a identificar atrasos iniciais em filas e problemas de disponibilidade de recursos.
Onde encontrar
Identificado no histórico de alterações de status da solicitação. A data e hora do evento correspondem à mudança para um status que indica trabalho ativo, como 'In Progress'.
Coleta
Identifique a data e hora da mudança de status para 'In Progress'.
Tipo de evento
inferred
|
|||
|
Resolução proposta
|
Esta atividade indica que uma solução foi identificada e implementada e que o incidente aguarda confirmação ou validação final. Ela é identificada pela mudança de status para 'Resolved'. | ||
|
Por que isso importa
Este marco importante indica o fim do trabalho ativo da equipe de suporte. Muitas vezes, é o evento que interrompe a contagem do SLA.
Onde encontrar
Identificado no histórico de alterações de status da solicitação. A data e hora do evento correspondem à mudança para 'Resolved' ou um status equivalente.
Coleta
Identifique a data e hora da mudança de status para 'Resolved'.
Tipo de evento
inferred
|
|||
|
Cliente respondeu
|
Indica que o cliente forneceu as informações solicitadas e que o incidente pode avançar. Esse evento é identificado quando o status sai de 'Waiting for customer' e volta a um status ativo. | ||
|
Por que isso importa
Esta atividade marca o fim do atraso causado pela espera do cliente. Analisar o tempo entre 'Waiting For Customer' e este evento revela o tempo médio de resposta do cliente.
Onde encontrar
Identificado no histórico de alterações de status da solicitação. O evento ocorre quando o status muda de 'Waiting for customer' para um status como 'In Progress', geralmente após o cliente adicionar um comentário.
Coleta
Identifique a mudança de status de 'Waiting for customer' para 'In Progress'.
Tipo de evento
inferred
|
|||
|
Comentário adicionado
|
Representa uma comunicação ou anotação feita quando um usuário adiciona um comentário ao chamado do incidente. É um evento explícito, registrado sempre que um comentário é publicado. | ||
|
Por que isso importa
Analisar a frequência dos comentários pode revelar insights sobre padrões de comunicação, eficiência da colaboração e complexidade dos incidentes. Também pode destacar casos que exigem comunicação excessiva.
Onde encontrar
Este é um evento explícito. O Jira armazena cada comentário com a data e hora e o autor, informações disponíveis no histórico de comentários da solicitação ou pela API.
Coleta
Use a data e hora de cada comentário adicionado à solicitação.
Tipo de evento
explicit
|
|||
|
Escalonado para equipe especializada
|
Indica que o incidente foi escalonado para uma equipe especializada, como o nível 2 ou a equipe de desenvolvimento, para receber suporte avançado. Esse evento é identificado por uma alteração no campo personalizado 'Support Team' ou por uma reatribuição específica. | ||
|
Por que isso importa
Destaca incidentes que exigem conhecimento especializado e acompanha o fluxo entre diferentes níveis de suporte. Isso ajuda a identificar gargalos nas equipes especializadas e analisar os padrões de escalonamento.
Onde encontrar
Identificado no histórico da solicitação pelo acompanhamento de alterações em um campo personalizado que representa a equipe responsável ou pela identificação de uma alteração no campo 'Assignee' para um integrante de um grupo especializado conhecido.
Coleta
Identifique uma alteração no campo personalizado 'Assigned Team' ou mudanças específicas no responsável.
Tipo de evento
inferred
|
|||
|
Incidente atribuído
|
Esta atividade indica a atribuição inicial do incidente a um agente ou grupo de suporte responsável pelo atendimento. Ela é registrada na primeira vez em que o campo 'Assignee' ou 'Assigned Group' é preenchido. | ||
|
Por que isso importa
Mede o tempo até a resposta e a atribuição inicial, componentes importantes das métricas de SLA. Ajuda a identificar atrasos antes do início da investigação.
Onde encontrar
Identificado no histórico da solicitação pela primeira alteração no campo 'Assignee' em que o valor anterior era 'Unassigned'.
Coleta
Identifique a primeira atualização do campo 'Assignee' no histórico da solicitação.
Tipo de evento
inferred
|
|||
|
Incidente priorizado
|
Representa a definição da prioridade e/ou gravidade do incidente, que determina sua urgência e seu impacto nos negócios. Em geral, esse evento é identificado na primeira vez em que os campos 'Priority' ou 'Severity' são preenchidos ou atualizados após a criação. | ||
|
Por que isso importa
Acompanhar a priorização ajuda a avaliar se os incidentes são analisados com rapidez e consistência. Atrasos nessa etapa podem afetar diretamente os cálculos de SLA e a alocação de recursos.
Onde encontrar
Identificado no histórico da solicitação, que registra as alterações em todos os campos. Procure a primeira atualização do campo 'Priority' ou de um campo personalizado 'Severity' após a criação da solicitação.
Coleta
Identifique a primeira alteração no campo 'Priority' no histórico da solicitação.
Tipo de evento
inferred
|
|||
|
Incidente reaberto
|
Representa a reativação de um incidente resolvido porque o problema voltou a ocorrer ou a correção não funcionou. Esse evento é identificado quando o status muda de 'Resolved' ou 'Closed' para um status aberto. | ||
|
Por que isso importa
Incidentes reabertos são uma medida direta da qualidade da resolução e um dos principais indicadores de retrabalho. Analisar esses eventos ajuda a identificar encerramentos prematuros e soluções ineficazes.
Onde encontrar
Identificado no histórico de alterações de status da solicitação. O evento é registrado quando o status sai de um estado final, como 'Resolved' ou 'Closed', e volta para 'Open' ou 'In Progress'.
Coleta
Identifique a mudança de status de 'Resolved' ou 'Closed' para um status aberto.
Tipo de evento
inferred
|
|||
|
Solução temporária fornecida
|
Representa a implementação de uma correção temporária para restabelecer o serviço enquanto uma solução definitiva está sendo desenvolvida. Esse evento pode ser identificado por uma mudança de status ou por um comentário específico. | ||
|
Por que isso importa
Medir o tempo até o fornecimento de uma solução temporária é um indicador importante da rapidez com que o serviço é restabelecido. Isso ajuda a diferenciar uma medida temporária de contenção de uma resolução definitiva.
Onde encontrar
Em geral, esse evento é identificado indiretamente. Pode ser uma mudança para o status 'Workaround Provided' ou a inclusão de um comentário público com palavras-chave específicas, como 'workaround'.
Coleta
Identifique uma mudança de status específica ou uma palavra-chave em um comentário.
Tipo de evento
inferred
|
|||
|
Vinculado a um chamado de problema
|
Ocorre quando um incidente é vinculado a uma solicitação do tipo 'Problem' para análise de causa raiz. É um evento explícito, registrado quando um vínculo 'relates to' ou 'caused by' é criado com uma solicitação desse tipo. | ||
|
Por que isso importa
Acompanhar esse vínculo é essencial para entender a eficácia com que a organização passa da contenção do incidente para a análise de causa raiz e a prevenção.
Onde encontrar
Este é um evento explícito, registrado no histórico de vínculos da solicitação. Cada vínculo criado tem uma data e hora e pode ser filtrado para mostrar os vínculos com solicitações do tipo 'Problem'.
Coleta
Use a data e hora de criação de um vínculo com uma solicitação do tipo 'Problem'.
Tipo de evento
explicit
|
|||
Guias de extração
Pronto para começar?
Use este Template de dados para transformar a gestão de incidentes, identificar ineficiências e reduzir o tempo de resolução. Comece a otimizar seu processo hoje.
Otimize a gestão de incidentes e resolva-os mais rapidamente
Reduza o MTTR em 35% e aumente a satisfação dos usuários com processos mais simples.
Não é necessário cartão de crédito • Configuração em 5 minutos