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
|
O nome do evento específico ou da alteração de status que ocorreu com o incidente. | ||
|
Descrição
A atividade representa uma etapa ou evento distinto no ciclo de vida do gerenciamento de incidentes, como 'Incident Created', 'Incident Assigned' ou 'Resolution Proposed'. Normalmente, essas atividades são derivadas de mudanças de status ou de eventos de atualização específicos registrados no histórico ou no changelog do problema no Jira. Analisar a sequência e a duração dessas atividades é o principal objetivo do Process Mining, revelando o fluxo real do processo, os gargalos e os desvios.
Por que isso importa
As atividades formam a base do mapa do processo, permitindo visualizar e analisar o ciclo de vida do incidente.
Onde obter
Derivado do histórico do problema e dos dados do changelog do Jira, capturando mudanças de status e atualizações de campos importantes.
Exemplos
Incidente atribuídoInvestigação iniciadaIncidente resolvido
|
|||
|
Hora de início
EventTimestamp
|
A data e a hora exatas em que a atividade ocorreu. | ||
|
Descrição
Esse atributo registra o registro de data e hora de cada atividade no ciclo de vida do incidente. Ele é essencial para calcular durações, tempos de ciclo e tempos de espera entre diferentes etapas do processo. Registros de data e hora precisos permitem uma análise detalhada da performance, o monitoramento de SLA e a identificação de gargalos. Todas as métricas de performance, como tempo de resolução e duração do diagnóstico, são derivadas desses registros.
Por que isso importa
Os registros de data e hora são essenciais para calcular todas as métricas baseadas em tempo, entender a duração do processo e descobrir gargalos de performance.
Onde obter
Esta é a data de 'criação' associada a cada entrada no changelog ou histórico do chamado do Jira.
Exemplos
2023-10-26T10:00:00Z2023-10-26T10:05:14Z2023-10-27T14:30:00Z
|
|||
|
ID do incidente
IncidentId
|
O identificador exclusivo de cada ticket de incidente no Jira Service Management. | ||
|
Descrição
O ID do incidente, geralmente chamado de Issue Key no Jira, funciona como o identificador exclusivo principal de cada incidente reportado. Ele conecta todas as atividades, comentários e alterações de status associadas desde o momento da criação até o encerramento final. No Process Mining, esse ID é essencial para reconstruir o ciclo de vida completo de cada incidente, permitindo 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, sendo a base de qualquer análise de Process Mining.
Onde obter
Esse é o campo padrão 'Key' de um problema no Jira Service Management, por exemplo, 'ITSM-123'.
Exemplos
INC-10234HELPDESK-5678OPS-9901
|
|||
|
Sistema de origem
SourceSystem
|
O 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 em ambientes onde dados de vários sistemas são combinados para oferecer uma visão holística do processo. Especificar o sistema de origem garante a clareza da linhagem dos dados e ajuda a diagnosticar problemas de qualidade ou extração. Para este modelo, o valor seria estático.
Por que isso importa
Fornece um contexto essencial sobre a origem dos dados, garantindo clareza e rastreabilidade, especialmente em análises que envolvem vários sistemas.
Onde obter
Este é um valor estático que deve ser adicionado durante o processo de extração dos dados.
Exemplos
Jira Service ManagementJira Cloud
|
|||
|
Última atualização dos dados
LastDataUpdate
|
O registro de data e hora que indica quando os dados foram atualizados pela última vez a partir do sistema de origem. | ||
|
Descrição
Este atributo registra quando o conjunto de dados foi atualizado pela última vez. Ele fornece um contexto importante para quem analisa o processo, garantindo que a atualização dos dados seja considerada. Isso é especialmente importante em Dashboards de monitoramento contínuo, nos quais informações atualizadas são essenciais para tomar decisões no momento certo. O valor normalmente é o mesmo para todos os eventos de um único lote de extração de dados.
Por que isso importa
Informa aos usuários se os dados estão atualizados, algo essencial para a relevância e a precisão da análise.
Onde obter
Este é o registro de data e hora da execução da extração de dados, adicionado durante o processo de transformação dos dados.
Exemplos
2023-10-27T08:00:00Z2023-10-28T08:00:00Z
|
|||
|
Data de criação
CreatedDate
|
A data e a 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. Ele é o registro de data e hora de referência para calcular métricas gerais, como o tempo total de resolução. A data de criação é um valor estático para cada incidente e serve como ponto de partida para todo o caso na análise de Process Mining.
Por que isso importa
Serve como ponto de partida para todos os cálculos de tempo de ciclo de ponta a ponta e para as medições de SLA.
Onde obter
O campo padrão 'Created' de um chamado do Jira.
Exemplos
2023-10-26T09:58:12Z2023-11-01T15:20:05Z
|
|||
|
Data de resolução
ResolutionDate
|
A data e a hora em que o incidente foi marcado como resolvido. | ||
|
Descrição
Este atributo registra o momento em que o incidente foi movido pela primeira vez para um status de resolução. Ele marca o fim da fase de trabalho ativo e é o ponto final para calcular o Time to Resolution. Comparar a data de resolução com a data de criação fornece a principal medida da eficiência do processo. Esse também é um componente essencial para determinar a conformidade com o SLA.
Por que isso importa
Marca o fim do processo de resolução, permitindo calcular o tempo total de ciclo e a performance do SLA.
Onde obter
O campo padrão 'Resolved' de um chamado do Jira.
Exemplos
2023-10-28T11:20:30Z2023-11-02T10:00:00Z
|
|||
|
Grupo responsável
AssignmentGroup
|
A equipe ou o grupo responsável por tratar o incidente. | ||
|
Descrição
O grupo responsável representa a equipe atribuída ao incidente. Pode ser um nível de suporte, como 'L1 Helpdesk', uma equipe especializada, como 'Network Operations', ou uma equipe de desenvolvimento. Analisar as transições entre grupos responsáveis é essencial para entender escalonamentos e transferências no processo. Isso permite medir a performance das equipes, identificar gargalos no nível da equipe e analisar dependências entre equipes.
Por que isso importa
É essencial para analisar a performance das equipes, o throughput e o fluxo de trabalho entre diferentes níveis de suporte ou grupos especializados.
Onde obter
Geralmente é implementado como um campo personalizado no Jira, como 'Team' ou 'Assignment Group'. Em alguns casos, pode ser derivado de Jira Components ou Project Roles.
Exemplos
Suporte de nível 1Equipe de infraestruturaAdministradores de banco de dados
|
|||
|
Prioridade
Priority
|
O nível de prioridade atribuído ao incidente, indicando a urgência da resolução. | ||
|
Descrição
A prioridade determina a velocidade necessária para tratar um incidente. Ela geralmente combina impacto e urgência e influencia diretamente as metas de SLA. Analisar os incidentes por prioridade ajuda a entender se os incidentes de alta prioridade estão sendo tratados mais rapidamente que os de baixa prioridade e se a priorização está sendo 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 obter
O campo padrão 'Priority' de um chamado do Jira.
Exemplos
Mais altoAltoMédioBaixo
|
|||
|
Responsável
Assignee
|
O 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 quais pessoas estão envolvidas em 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 obter
O campo padrão 'Assignee' de um chamado do Jira.
Exemplos
John SmithEmily JonesServiceDeskAgent1
|
|||
|
Status
Status
|
A etapa atual do incidente em seu ciclo de vida. | ||
|
Descrição
O campo Status indica o estado atual de um incidente dentro do Workflow definido, como 'Open', 'In Progress', 'Pending Customer' ou 'Resolved'. As mudanças de status são a principal fonte para gerar o registro de atividades usado no Process Mining. Analisar o tempo gasto em cada status é fundamental para identificar gargalos e entender onde os incidentes permanecem por mais tempo.
Por que isso importa
Reflete diretamente o progresso do incidente e é a principal fonte para identificar etapas do processo e tempos de espera.
Onde obter
O campo padrão 'Status' de um chamado do Jira.
Exemplos
Em andamentoAguardando o clienteResolvidoFechado
|
|||
|
Categoria da causa raiz
RootCauseCategory
|
A classificação da causa raiz subjacente do incidente. | ||
|
Descrição
Este atributo registra o motivo fundamental pelo qual o incidente ocorreu, como 'Software Defect', 'Hardware Failure' ou 'User Error'. Normalmente, ele é preenchido após a investigação e é essencial para o gerenciamento eficaz de problemas e a prevenção de incidentes futuros. Analisar as categorias de causa raiz ajuda a identificar fragilidades sistêmicas e priorizar iniciativas de melhoria. Uma taxa elevada de causas raiz 'Unknown' pode indicar a necessidade de melhorar os processos de investigação.
Por que isso importa
Permite analisar a causa raiz, ajudando a passar de uma abordagem reativa para uma abordagem proativa ao identificar e tratar as fontes dos incidentes.
Onde obter
Quase sempre é 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
|
O sistema, aplicativo ou parte da infraestrutura afetada pelo incidente. | ||
|
Descrição
Os componentes são subseções de um projeto do Jira usadas para agrupar chamados em partes menores, como 'User Interface', 'Database' ou 'API'. Analisar os incidentes por componente ajuda a identificar quais partes de um sistema estão mais sujeitas a problemas. Essas informações são valiosas 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 com base na área específica do produto ou sistema afetada, ajudando a identificar pontos críticos de tecnologia.
Onde obter
O campo padrão 'Components' de um chamado do Jira.
Exemplos
Serviço de autenticaçãoDashboard de relatóriosAplicativo móvel
|
|||
|
Contagem de transferências
HandoffCount
|
O número de vezes que o incidente foi reatribuído a um grupo ou usuário diferente. | ||
|
Descrição
Esta métrica calculada conta quantas vezes os campos 'Assignee' ou 'AssignmentGroup' mudaram durante o ciclo de vida do incidente. Uma contagem elevada de transferências geralmente indica ineficiência no processo, falta de resolução no primeiro contato ou lacunas de conhecimento, levando a tempos de resolução mais longos. Analisar esse KPI ajuda a simplificar o processo de atribuição e melhorar a colaboração entre as equipes.
Por que isso importa
Quantifica o atrito e a ineficiência do processo causados por reatribuições, ajudando a identificar oportunidades de melhoria.
Onde obter
Calculado contando o número de alterações nos campos 'Assignee' ou 'AssignmentGroup' no changelog do chamado.
Exemplos
015
|
|||
|
É retrabalho
IsRework
|
Um indicador que mostra se o incidente passou por retrabalho, como ser reaberto. | ||
|
Descrição
Este atributo booleano calculado identifica incidentes que retornaram a uma etapa anterior do processo, geralmente por terem sido reabertos após a resolução. Os ciclos de retrabalho são uma fonte significativa de ineficiência e insatisfação do cliente. Esse indicador permite quantificar facilmente a taxa de retrabalho e concentrar a análise nos motivos pelos quais os incidentes não estão sendo resolvidos corretamente na primeira vez.
Por que isso importa
Evidencia problemas de qualidade e ineficiências do processo ao sinalizar incidentes que exigem trabalho repetido, apoiando diretamente a análise de retrabalho.
Onde obter
Calculado detectando sequências específicas de transições de status no registro de eventos, como 'Resolved' -> 'Reopened'.
Exemplos
truefalse
|
|||
|
ID do problema vinculado
LinkedProblemId
|
O identificador de um chamado de problema vinculado a este incidente. | ||
|
Descrição
Incidentes que são sintomas de um problema maior e subjacente geralmente são vinculados a um chamado de Problem. Este campo armazena o ID desse Problem 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 exigem uma correção permanente.
Por que isso importa
Conecta os incidentes aos problemas subjacentes, permitindo analisar com que eficácia a organização trata as causas raiz para evitar incidentes futuros.
Onde obter
Essas informações são armazenadas na seção 'Issue Links' de um chamado do Jira.
Exemplos
PROB-123PROB-456Nenhum
|
|||
|
Meta de tempo para resolução
TimeToResolutionTarget
|
A duração-alvo do 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 é a referência usada para comparar o tempo real de resolução e determinar a conformidade com o SLA. Esse valor normalmente é definido de forma dinâmica com base em regras que consideram fatores como prioridade, severidade ou tipo de chamado. Ele é fundamental para qualquer Dashboard de monitoramento da performance do SLA.
Por que isso importa
Fornece a referência para medir a conformidade com o SLA e serve de base para o KPI Incident SLA Breach Rate.
Onde obter
É derivado da configuração de SLA no Jira Service Management. A meta específica, por exemplo, 'Time to resolution', deve ser identificada.
Exemplos
4h8h3d
|
|||
|
Relator
Reporter
|
O usuário que criou ou relatou o incidente inicialmente. | ||
|
Descrição
O relator é a pessoa, geralmente um usuário final ou outro sistema, que registrou o incidente pela primeira vez. Analisar os incidentes por relator pode ajudar a identificar usuários ou departamentos que enfrentam problemas com frequência. Também pode ser usado para entender padrões de comunicação, especialmente ao analisar atividades como 'Waiting for Customer' e 'Customer Responded'.
Por que isso importa
Ajuda a analisar as fontes dos incidentes, identificar padrões relacionados a usuários ou departamentos específicos e entender atrasos na interação com o cliente.
Onde obter
O campo padrão 'Reporter' de um chamado do Jira.
Exemplos
Alice JohnsonBob Williamsmonitoring-tool@example.com
|
|||
|
Resolução
Resolution
|
O resultado final ou o motivo da resolução do incidente. | ||
|
Descrição
O campo Resolution explica por que um incidente foi movido para um status de resolução. As resoluções comuns incluem 'Fixed', 'Duplicate', 'Won't Do' ou 'Cannot Reproduce'. Analisar a distribuição dos tipos de resolução pode gerar insights sobre a qualidade dos chamados recebidos e a eficácia do processo de resolução. Por exemplo, um número elevado de resoluções 'Duplicate' pode indicar um problema na criação ou na triagem dos incidentes.
Por que isso importa
Fornece contexto sobre o resultado de um incidente, ajudando a categorizar as resoluções e identificar tendências na forma como os incidentes são encerrados.
Onde obter
O campo padrão 'Resolution' de um chamado do Jira. Esse campo normalmente é preenchido quando um chamado é movido para uma categoria de status 'Done'.
Exemplos
ConcluídoCorrigidoDuplicadoNão será corrigido
|
|||
|
Severidade
Severity
|
A medida do impacto do incidente sobre o negócio. | ||
|
Descrição
A severidade define o impacto que um incidente tem sobre o negócio, desde o impacto em um único usuário até uma interrupção crítica do sistema. Enquanto a prioridade determina a ordem do trabalho, a severidade informa o impacto geral no negócio. Analisar por severidade ajuda a entender a performance do processo para os incidentes mais relevantes para o negócio e costuma ser combinado com a prioridade para uma análise mais detalhada.
Por que isso importa
Oferece uma visão do impacto no negócio, permitindo uma análise focada nos incidentes que mais prejudicam as operações.
Onde obter
Normalmente é um campo personalizado no Jira, pois não é um campo padrão do sistema. Consulte a configuração do projeto no Jira Service Management.
Exemplos
CríticoGraveMenorTrivial
|
|||
|
Tipo de chamado
IssueType
|
O tipo de chamado, como Incident, Service Request ou Problem. | ||
|
Descrição
O Jira usa Issue Types para diferenciar vários tipos de tarefas. No contexto de Gerenciamento de Incidentes, o tipo principal é 'Incident', mas outros, como 'Sub-task', também podem ser relevantes. Esse atributo é essencial para filtrar o conjunto de dados e incluir apenas incidentes, garantindo que a análise de Process Mining esteja focada no processo correto.
Por que isso importa
Garante que a análise esteja corretamente limitada aos incidentes, separando-os de outros tipos de trabalho, como solicitações de serviço ou mudanças.
Onde obter
O campo padrão 'Issue Type' de um chamado do Jira.
Exemplos
IncidenteAjuda de TIBug
|
|||
|
Tipo de solicitação do cliente
CustomerRequestType
|
O tipo específico de solicitação enviada pelo cliente por meio do portal de serviços. | ||
|
Descrição
Este campo categoriza as solicitações do ponto de vista do cliente, conforme apresentadas no portal do Jira Service Management, por exemplo, 'Report a system issue'. Ele fornece uma classificação do incidente mais fácil de entender para o usuário, que pode ser diferente do 'Issue Type' interno. Analisar esse atributo pode gerar insights sobre como os clientes percebem e relatam problemas, ajudando a melhorar o design do portal e as ofertas de serviços.
Por que isso importa
Oferece uma visão das categorias de incidentes centrada no cliente, útil para analisar a demanda e melhorar a experiência do cliente.
Onde obter
O campo 'Customer Request Type', específico de 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
|
Um indicador que mostra se o tempo de resolução do incidente ultrapassou a meta do SLA. | ||
|
Descrição
Este atributo booleano calculado indica se um incidente violou o SLA de 'Time to Resolution'. O valor é verdadeiro quando 'IncidentResolutionCycleTime' é maior que 'TimeToResolutionTarget'. Esse indicador simplifica a análise e a visualização, permitindo filtrar e agregar dados facilmente para calcular o KPI geral de SLA Breach Rate. Ele é a principal medida de resultado do Dashboard de Monitoramento da Performance do SLA.
Por que isso importa
Fornece um resultado binário claro sobre a performance do SLA, facilitando o cálculo das taxas de violação e a identificação de áreas problemáticas.
Onde obter
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. É inferido a partir de uma mudança de status para um status específico de espera, como 'Waiting for customer'. | ||
|
Por que isso importa
Isolar esse tempo 'em espera' é essencial para medir o SLA com precisão, pois ele costuma ser excluído dos cálculos de tempo de resolução. Isso ajuda a analisar atrasos na resposta do cliente.
Onde obter
É inferido a partir do histórico de alterações de status do problema. O evento corresponde ao registro de data e hora em que o status muda para 'Waiting for customer' ou um estado semelhante.
Captura
Identifique o registro de 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 relatório é enviado e um novo problema é criado no Jira. Esse evento é capturado explicitamente quando um novo problema do tipo 'Incident' é registrado no sistema. | ||
|
Por que isso importa
Esse é o principal evento de início do processo. Analisar o tempo entre essa atividade e a resolução é fundamental para medir o tempo total do ciclo e a adesão ao SLA.
Onde obter
Esse é um evento explícito, capturado a partir do registro de data e hora 'created' do problema no Jira. O evento de criação do problema é registrado no histórico do problema.
Captura
Use o registro de data e hora de criação do problema.
Tipo de evento
explicit
|
|||
|
Incidente encerrado
|
Representa o encerramento administrativo final do ticket do incidente depois que ele foi resolvido e verificado. É inferido a partir da mudança de status para 'Closed'. | ||
|
Por que isso importa
Esse é o evento final do processo. Analisar o tempo entre 'Resolved' e 'Closed' pode revelar atrasos na limpeza administrativa ou nos processos de confirmação do usuário.
Onde obter
É inferido a partir do histórico de alterações de status do problema. O evento corresponde ao registro de data e hora em que o status muda para o estado final 'Closed'.
Captura
Identifique o registro de data e hora da mudança de status para 'Closed'.
Tipo de evento
inferred
|
|||
|
Incidente reatribuído
|
Ocorre quando um incidente é transferido de um agente ou grupo para outro após a atribuição inicial. Esse evento é inferido a partir de qualquer alteração no campo 'Assignee' ou 'Assigned Group'. | ||
|
Por que isso importa
Acompanhar reatribuições é essencial para analisar transferências. Um número elevado de reatribuições geralmente indica ineficiências no processo, lacunas de conhecimento ou roteamento inicial incorreto, levando a atrasos na resolução.
Onde obter
É inferido a partir do histórico do problema, detectando qualquer atualização no campo 'Assignee' depois que ele foi preenchido pela primeira vez. Cada alteração constitui um evento de reatribuição.
Captura
Identifique as alterações posteriores no campo 'Assignee' após a atribuição inicial.
Tipo de evento
inferred
|
|||
|
Incidente resolvido
|
Essa atividade confirma que o incidente foi resolvido com sucesso e que o serviço foi restaurado. Muitas vezes, ela coincide com a mudança para o status 'Resolved'. | ||
|
Por que isso importa
Esse é o principal marco de sucesso do processo. A duração até esse ponto é o KPI mais comum e representa o tempo até a resolução, ou TTR.
Onde obter
É inferido a partir da mudança de status para 'Resolved'. Em muitos Workflows, esse é o mesmo evento que 'Resolution Proposed', representando o principal ponto de resolução.
Captura
Identifique o registro de data e hora da mudança de status para 'Resolved'.
Tipo de evento
inferred
|
|||
|
Investigação iniciada
|
Indica que um agente atribuído começou a trabalhar ativamente no diagnóstico do incidente. Normalmente, é inferido quando o status do problema muda de 'Open' ou 'New' para 'In Progress'. | ||
|
Por que isso importa
Esse marco importante indica o início dos esforços ativos de resolução. Medir o tempo até essa atividade ajuda a identificar atrasos iniciais em filas e problemas de disponibilidade de recursos.
Onde obter
É inferido a partir do histórico de alterações de status do problema. O registro de data e hora do evento corresponde ao momento em que o status muda para um estado que representa trabalho ativo, como 'In Progress'.
Captura
Identifique o registro de data e hora da mudança de status para 'In Progress'.
Tipo de evento
inferred
|
|||
|
Resolução proposta
|
Essa atividade indica que uma resolução foi identificada e implementada e que o incidente aguarda confirmação ou validação final. Ela é inferida a partir da mudança de status para 'Resolved'. | ||
|
Por que isso importa
Esse é um marco importante que indica o fim do trabalho ativo da equipe de suporte. Muitas vezes, é o evento que interrompe a contagem do SLA.
Onde obter
É inferido a partir do histórico de alterações de status do problema. O registro de data e hora do evento corresponde ao momento em que o status muda para 'Resolved' ou um estado equivalente.
Captura
Identifique o registro de 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. É inferido quando o status sai de 'Waiting for customer' e volta para um status ativo. | ||
|
Por que isso importa
Essa atividade marca o fim de um atraso causado pelo cliente. Analisar a duração entre 'Waiting For Customer' e esse evento revela o tempo médio de resposta do cliente.
Onde obter
É inferido a partir do histórico de alterações de status do problema. O evento ocorre quando o status muda de 'Waiting for customer' para um status como 'In Progress', geralmente depois que o cliente adiciona um comentário.
Captura
Detecte a mudança de status de 'Waiting for customer' para 'In Progress'.
Tipo de evento
inferred
|
|||
|
Comentário adicionado
|
Representa qualquer evento de comunicação ou registro de observação em que um usuário adiciona um comentário ao ticket do incidente. É um evento explícito, capturado sempre que um comentário é publicado. | ||
|
Por que isso importa
Analisar a frequência dos comentários pode gerar insights sobre padrões de comunicação, eficiência da colaboração e complexidade de um incidente. Também pode destacar incidentes que exigem comunicação excessiva.
Onde obter
Esse é um evento explícito. O Jira armazena cada comentário com registro de data e hora e autor, disponíveis no histórico de comentários do problema ou pela API.
Captura
Use o registro de data e hora de cada comentário adicionado ao problema.
Tipo de evento
explicit
|
|||
|
Escalonado para uma equipe especializada
|
Indica que o incidente foi escalonado para uma equipe especializada, como Tier 2 ou Desenvolvimento, para receber suporte avançado. Isso é inferido a partir de uma alteração em um campo personalizado 'Support Team' ou de 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 padrões de escalonamento.
Onde obter
É inferido a partir do histórico do problema, acompanhando alterações em um campo personalizado que representa a equipe atribuída ou identificando uma alteração no campo 'Assignee' para um membro de um grupo especializado conhecido.
Captura
Detecte uma alteração em um campo personalizado de 'Assigned Team' ou alterações específicas no responsável.
Tipo de evento
inferred
|
|||
|
Incidente atribuído
|
Essa atividade representa a atribuição inicial do incidente a um agente ou grupo de suporte para tratamento. Ela é capturada acompanhando o primeiro momento em que o campo 'Assignee' ou 'Assigned Group' é preenchido. | ||
|
Por que isso importa
Mede o tempo de resposta e de atribuição inicial, que é um componente importante das métricas de SLA. Ajuda a identificar atrasos antes do início da investigação ativa.
Onde obter
É inferido a partir do histórico do problema, identificando a primeira alteração no campo 'Assignee' cujo valor anterior era 'Unassigned'.
Captura
Detecte a primeira atualização do campo 'Assignee' no histórico do problema.
Tipo de evento
inferred
|
|||
|
Incidente priorizado
|
Representa a definição da prioridade e/ou da severidade do incidente, que determina sua urgência e seu impacto no negócio. Normalmente, é inferido a partir do primeiro momento 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 analisar se os incidentes são avaliados com rapidez e consistência. Atrasos nessa etapa podem afetar diretamente os cálculos de SLA e a alocação de recursos.
Onde obter
É inferido a partir do histórico do problema, que registra alterações em todos os campos. Procure a primeira atualização do campo 'Priority' ou de um campo personalizado 'Severity' após o evento de criação do problema.
Captura
Detecte a primeira alteração no campo 'Priority' do histórico do problema.
Tipo de evento
inferred
|
|||
|
Incidente reaberto
|
Representa uma situação em que um incidente anteriormente resolvido é reativado porque o problema voltou a ocorrer ou a correção foi ineficaz. É inferido a partir de uma mudança de status de 'Resolved' ou 'Closed' de volta para um status aberto. | ||
|
Por que isso importa
Incidentes reabertos são uma medida direta da qualidade da resolução e um indicador principal de retrabalho. Analisar esses eventos ajuda a identificar encerramentos prematuros e soluções ineficazes.
Onde obter
É inferido a partir do histórico de alterações de status do problema. O evento é registrado quando o status muda de um estado final, como 'Resolved' ou 'Closed', de volta para 'Open' ou 'In Progress'.
Captura
Detecte 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 restaurar o serviço enquanto uma solução permanente está sendo desenvolvida. Isso pode ser inferido a partir de uma mudança de status ou de um comentário específico. | ||
|
Por que isso importa
Medir o tempo necessário para fornecer uma solução temporária é um indicador importante da velocidade de restauração do serviço. Isso ajuda a diferenciar uma mitigação temporária de uma resolução permanente.
Onde obter
Esse evento costuma ser inferido. Pode corresponder a uma mudança para o status 'Workaround Provided' ou à adição de um comentário público contendo palavras-chave específicas, como 'workaround'.
Captura
Identifique uma mudança de status específica ou uma palavra-chave em um comentário.
Tipo de evento
inferred
|
|||
|
Vinculado a um ticket de problema
|
Ocorre quando um incidente é vinculado a um problema para análise de causa raiz. É um evento explícito, capturado quando um link 'relates to' ou 'caused by' é criado para um problema do tipo 'Problem'. | ||
|
Por que isso importa
Acompanhar esse vínculo é essencial para entender com que eficácia a organização passa da mitigação do incidente para a análise e a prevenção da causa raiz.
Onde obter
Esse é um evento explícito registrado no histórico de links do problema. Cada criação de link tem um registro de data e hora e pode ser filtrada para links com problemas do tipo 'Problem'.
Captura
Use o registro de data e hora da criação de um link do problema com um problema do tipo 'Problem'.
Tipo de evento
explicit
|
|||
Guias de extração
Pronto para começar?
Use este Template de dados para transformar sua 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 incidentes 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