Template de Dados: Gestão de Incidentes

BMC Helix ITSM
Template de Dados: Gestão de Incidentes

Seu template de dados para Gestão de Incidentes

Este template é um guia completo para coletar os dados essenciais para otimizar a sua Gestão de Incidentes. Ele descreve os atributos e atividades fundamentais a serem acompanhados, além de orientações práticas sobre como extrair esses dados. Use este recurso para agilizar a preparação dos dados e acelerar sua jornada de análise de processos.
  • Atributos recomendados para coletar
  • Principais atividades para acompanhar no seu processo
  • Orientações de extração para o seu sistema de dados
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos de Gerenciamento de Incidentes

Estes são os campos de dados recomendados para você incluir no seu Event Log, possibilitando uma análise completa do seu processo de Gerenciamento de Incidentes.
3 Obrigatório 9 Recomendado 10 Opcional
Nome Descrição
ID do incidente
IncidentId
O identificador único de cada registro de incidente.
Descrição

O ID do Incidente funciona como a chave primária de cada ocorrência, identificando-a de forma única do início ao fechamento. Ele conecta todas as atividades, logs e alterações relacionadas, permitindo uma visão ponta a ponta do ciclo de vida do incidente.

Em Process Mining, esse atributo é fundamental porque define o caso. Todo evento com o mesmo ID do Incidente é considerado parte da mesma instância do processo, permitindo reconstruir e analisar como cada incidente é tratado.

Por que é importante

Este é o identificador essencial do caso que conecta todos os eventos no ciclo de vida do incidente, tornando possível a análise ponta a ponta do processo.

Onde obter

Este é o campo 'Incident Number' (Field ID: 1000000161) no formulário 'HPD:Help Desk'.

Exemplos
INC000001234567INC000002345678INC000003456789
Event Timestamp
EventTimestamp
A data e hora exatas em que a atividade ocorreu.
Descrição

Este timestamp registra quando um evento específico no ciclo de vida do incidente ocorreu. Ele fornece a ordem cronológica necessária para reconstruir o fluxo do processo a partir dos dados brutos.

O Event Timestamp é essencial para todas as análises baseadas em tempo, como calcular tempos de ciclo entre atividades, identificar gargalos em que incidentes aguardam por longos períodos e medir o tempo total de resolução. Ele é a espinha dorsal temporal da análise de processos.

Por que é importante

Este timestamp fornece a ordem cronológica dos eventos, essencial para calcular durações, identificar gargalos e entender a linha do tempo do processo.

Onde obter

O 'Last Modified Date' (Field ID: 6) ou campos de data específicos do formulário 'HPD:Help Desk'. Para eventos históricos, vem do campo de carimbo de data e hora do log de auditoria.

Exemplos
2023-10-26T10:00:00Z2023-10-26T10:15:32Z2023-10-27T14:22:05Z
Nome da Atividade
ActivityName
O nome do evento ou da tarefa que ocorreu no ciclo de vida do incidente.
Descrição

Esse atributo descreve a atividade executada em um momento específico do incidente, como 'Incidente Registrado', 'Grupo Atribuído' ou 'Incidente Resolvido'. Essas atividades são os blocos que compõem o mapa do processo.

Analisar a sequência e a frequência dessas atividades revela o fluxo real do processo, identifica caminhos comuns e destaca desvios do procedimento padrão. É crucial para entender quais ações são tomadas para resolver um incidente.

Por que é importante

As atividades definem as etapas no mapa do processo, permitindo visualizar e analisar o workflow de gerenciamento de incidentes.

Onde obter

Normalmente, é derivado de mudanças nos campos 'Status' (Field ID: 7) e 'Status_Reason' no formulário 'HPD:Help Desk', ou do formulário 'HPD:Help Desk Audit Log'.

Exemplos
Incidente relatadoGrupo atribuídoResolução implementadaIncidente encerrado
Categoria do incidente
IncidentCategory
A classificação do incidente, geralmente organizada por níveis.
Descrição

A categorização de incidentes fornece uma forma estruturada de classificar os incidentes, normalmente em uma hierarquia de múltiplos níveis (ex.: Nível 1: Hardware, Nível 2: Laptop, Nível 3: Bateria). Esses dados são essenciais para roteamento, relatórios e análise de tendências.

No Process Mining, a categorização é usada para analisar separadamente os diferentes tipos de incidentes. Ela sustenta o dashboard de Precisão da Categorização de Incidentes ao comparar categorias iniciais e finais e ajuda a identificar tendências no dashboard de Tendências de Causa Raiz.

Por que é importante

A categorização viabiliza roteamento preciso, análise de tendências e comparação de performance entre diferentes tipos de incidentes.

Onde obter

Estes são os campos 'Operational Categorization Tier 1/2/3' no formulário 'HPD:Help Desk'.

Exemplos
Hardware > Laptop > BateriaSoftware > Aplicativo corporativo > Erro de loginRede > Conectividade > Wi-Fi
Grupo Atribuído
AssignedGroup
O grupo de suporte responsável por trabalhar no incidente.
Descrição

Esse atributo identifica a equipe ou área responsável pelo incidente, como 'Service Desk', 'Equipe de Redes' ou 'Administradores de Banco de Dados'. Acompanhar as atribuições é essencial para entender o fluxo de trabalho entre as equipes.

Ele é usado para analisar as passagens de responsabilidade entre times, identificar gargalos causados por grupos específicos e medir a Taxa de Reatribuição de Incidentes. Ajuda a visualizar o caminho que um incidente percorre pela organização e destaca áreas com roteamento ineficiente ou lacunas de conhecimento.

Por que é importante

Acompanhar a qual grupo o incidente está atribuído ajuda a analisar as passagens entre equipes, identificar ciclos de reatribuição e localizar gargalos dentro de equipes específicas.

Onde obter

Este é o campo 'Assigned Group' (Field ID: 1000000217) no formulário 'HPD:Help Desk'.

Exemplos
Service DeskOperações de RedeSuporte a Aplicações Nível 2Serviços de Infraestrutura
Prioridade
Priority
O nível de prioridade atribuído ao incidente, que define a urgência de atendimento.
Descrição

A prioridade geralmente é definida pela combinação de impacto e urgência e determina a ordem e a velocidade de resolução dos incidentes. Os valores mais comuns vão de 'Crítica' a 'Baixa'.

Em Process Mining, analisar incidentes por prioridade é essencial para a análise de desempenho. Isso ajuda a responder perguntas como: 'Estamos cumprindo os SLAs para incidentes de alta prioridade?' e 'Incidentes de baixa prioridade têm atrasos maiores?'. Filtrar por prioridade permite focar nos problemas de negócio mais críticos.

Por que é importante

Este atributo é essencial para segmentar a análise e garantir que os incidentes de alta prioridade sejam tratados mais rapidamente e cumpram suas metas específicas de nível de serviço (SLA).

Onde obter

Este é o campo 'Priority' (Field ID: 1000000164) no formulário 'HPD:Help Desk'.

Exemplos
CríticoAltoMédioBaixo
Reaberto
IsReopened
Indica se o incidente foi reaberto depois de ter ficado com o status 'Resolved'.
Descrição

Este atributo booleano é verdadeiro se o status de um incidente voltou para um estado ativo (como 'In Progress') depois de já ter sido marcado como 'Resolved'. Isso indica que a correção inicial não foi eficaz ou completa.

É uma medida direta de retrabalho e é usada para calcular o KPI 'Taxa de Retrabalho de Incidentes'. Analisar incidentes reabertos ajuda a identificar correções de baixa qualidade, testes insuficientes ou problemas recorrentes que não foram tratados adequadamente, dando suporte ao dashboard de Retrabalho e Caminhos de Escalonamento.

Por que é importante

Mede diretamente o retrabalho e a qualidade das resoluções. Uma alta taxa de reabertura indica correções ineficazes e fragilidades no processo.

Onde obter

Calculado analisando a sequência de atividades de um incidente. Se uma atividade 'Incident Reopened' ou similar aparece após 'Resolution Implemented', esse indicador é definido como verdadeiro.

Exemplos
verdadeirofalse
Responsável
Assignee
A pessoa designada para trabalhar no incidente.
Descrição

O Responsável (Assignee) é o agente de suporte ou técnico especificamente responsável pelo incidente em determinado momento. Ele oferece um nível de detalhe mais granular do que o Assigned Group.

Analisar o desempenho por responsável ajuda a identificar quem se destaca, quem pode precisar de treinamento adicional e possíveis desequilíbrios na distribuição de trabalho. Também serve para rastrear a sequência exata de ações executadas por cada pessoa em incidentes complexos.

Por que é importante

Oferece uma visão detalhada da distribuição de trabalho e do desempenho individual, ajudando a identificar quem se destaca e quais agentes precisam de apoio.

Onde obter

Este é o campo 'Assignee' (Field ID: 1000000218) no formulário 'HPD:Help Desk'.

Exemplos
Bob SmithAlice JohnsonCharlie Brown
Serviço
Service
O serviço de negócios ou técnico afetado pelo incidente.
Descrição

Este atributo vincula um incidente a um serviço específico definido na Configuration Management Database (CMDB), como 'Serviço de E-mail', 'Acesso à VPN' ou 'SAP Financeiro'.

Essa vinculação é crucial para entender o impacto no negócio dos incidentes. Analisar incidentes por serviço ajuda a identificar serviços problemáticos que geram alto volume de incidentes, destaca recorrências ligadas a tecnologias específicas e apoia análises de tendência para a gestão de problemas.

Por que é importante

Conectar incidentes a serviços de negócios é essencial para a análise de impacto e para identificar quais serviços são mais propensos a problemas.

Onde obter

Este é o campo 'ServiceCI' ou similar, que representa o Configuration Item (CI) afetado no formulário 'HPD:Help Desk'.

Exemplos
E-mail corporativoSAP ERPVPN de acesso remotoPortal de Recursos Humanos
SLA violado
IsSlaBreached
Um indicador que informa se o incidente foi resolvido após a data alvo do SLA.
Descrição

Este atributo booleano é verdadeiro se o tempo de resolução do incidente excedeu o SLA definido. Ele fornece um resultado claro e binário do desempenho de SLA em cada incidente.

Esse indicador é essencial para criar o dashboard de Visão Geral do Desempenho de SLA de Incidentes e calcular o KPI 'Taxa de Conformidade de SLA de Incidentes'. Ele simplifica a análise ao permitir filtrar e agregar diretamente todos os incidentes que não atingiram suas metas de nível de serviço, facilitando a investigação dos motivos das violações.

Por que é importante

Esse indicador simplifica a análise de conformidade com o SLA, facilitando filtrar todos os incidentes com violação de SLA e investigar as causas raiz.

Onde obter

Calculado comparando o timestamp do evento 'Incident Resolved' com o 'SlaTargetDate'. Se o timestamp de resolução for posterior à data-alvo, esse indicador é verdadeiro.

Exemplos
verdadeirofalse
Status do incidente
IncidentStatus
O status atual ou histórico do incidente no momento do evento.
Descrição

Esse atributo indica o estado do incidente, como 'New', 'In Progress', 'Pending', 'Resolved' ou 'Closed'. Ele oferece um retrato de onde o incidente está no seu ciclo de vida.

Analisar mudanças de status é fundamental para entender o processo de gerenciamento de incidentes. É usado para definir atividades, medir o tempo gasto em diferentes estados (por exemplo, quanto tempo os incidentes ficam 'Pending') e identificar incidentes que podem estar parados ou inativos.

Por que é importante

Acompanhar as mudanças de status é fundamental para entender o andamento do incidente e medir quanto tempo ele fica em estados específicos como 'Pending' ou 'In Progress'.

Onde obter

Este é o campo 'Status' (Field ID: 7) no formulário 'HPD:Help Desk'.

Exemplos
NovoAtribuídoEm ProgressoPendenteResolvidoEncerrado
Tempo de resolução do incidente
IncidentResolutionTime
Tempo total decorrido desde que o incidente foi registrado até sua resolução.
Descrição

Esta é uma métrica calculada que representa a duração entre as atividades 'Incident Reported' e 'Incident Resolved'. É um dos KPIs mais comuns e importantes na gestão de incidentes.

Essa métrica mede diretamente a eficiência do processo de resolução. No Process Mining, é usada como indicador primário de desempenho, analisada por diferentes categorias de incidentes, prioridades e equipes para identificar oportunidades de melhoria e acompanhar o impacto de mudanças de processo ao longo do tempo.

Por que é importante

Este é um KPI crítico que mede a eficiência ponta a ponta do processo de gestão de incidentes e impacta diretamente a satisfação do usuário.

Onde obter

Calculado subtraindo o timestamp do primeiro evento do timestamp do evento 'Incident Resolved' para cada ID de incidente.

Exemplos
2592003600864000
Autor
Submitter
A pessoa que registrou o incidente originalmente.
Descrição

O Solicitante é o usuário final ou cliente que teve o problema e o reportou. É diferente do responsável, que trabalha no incidente.

Analisar os dados por solicitante ou por área ajuda a identificar grupos específicos de usuários que podem precisar de mais treinamento ou que são impactados por determinado tipo de falha. Isso traz uma visão centrada no cliente do processo de gerenciamento de incidentes.

Por que é importante

Identifica o usuário que relatou o problema, permitindo análises por departamento, localização ou função, para identificar tendências específicas por perfil.

Onde obter

Essa informação é capturada no campo 'Submitter' ou em campos relacionados aos dados do cliente no formulário 'HPD:Help Desk'.

Exemplos
John DoeJane SmithPeter Jones
Canal
Channel
O canal usado para registrar o incidente.
Descrição

Este atributo especifica como o incidente foi aberto, por exemplo, por telefonema, e-mail, portal de autoatendimento ou atendimento presencial. Ele indica o ponto de entrada do incidente no processo de suporte.

Analisar incidentes por canal pode revelar quais são mais eficazes ou quais geram casos mais fáceis ou mais difíceis de resolver. Também orienta decisões sobre onde investir em automação ou treinamento de usuários, por exemplo, promovendo o uso de um portal de autoatendimento que capture dados iniciais melhores.

Por que é importante

Entender o canal de abertura ajuda a analisar a eficiência dos diferentes canais de entrada e pode orientar investimentos em self-service ou automação.

Onde obter

Este é o campo 'Reported Source' (Field ID: 1000000215) no formulário 'HPD:Help Desk'.

Exemplos
EmailTelefoneSelf ServiceEntrada direta
Causa raiz
RootCause
A razão fundamental ou causa última do incidente.
Descrição

A Causa Raiz é o problema fundamental que, se tratado, evita a recorrência do incidente. Geralmente é identificada como parte de uma investigação de problema relacionada.

Embora nem todo incidente tenha uma causa raiz documentada, analisar esse atributo é crucial para um gerenciamento proativo de problemas. Ele sustenta o KPI 'Taxa de Identificação de Causa Raiz' e ajuda a criar dashboards que acompanham tendências de recorrência, orientando esforços para implementar soluções permanentes.

Por que é importante

Identificar a causa raiz é essencial para o Gerenciamento de Problemas e para análises voltadas à redução do volume de incidentes recorrentes.

Onde obter

Essa informação pode estar em um campo dedicado 'Root Cause' no incidente ou, mais comumente, em um formulário vinculado 'PBI:Problem Investigation'.

Exemplos
Espaço em disco insuficiente no servidorErro de configuração de redeBug de software na versão 2.1Certificado de segurança expirado
Código de Encerramento
CloseCode
O código selecionado ao encerrar um incidente, indicando o resultado da resolução.
Descrição

O Close Code fornece um resumo estruturado de como o incidente foi resolvido. Exemplos incluem 'Resolved by User', 'No Fault Found', 'Duplicate Incident' ou 'Permanent Fix Applied'.

Esse atributo é valioso para analisar a eficácia e os resultados da resolução. Pode ajudar a identificar incidentes fechados sem uma correção real ou destacar categorias em que os próprios usuários costumam resolver seus problemas, o que pode indicar oportunidades de melhorar artigos da base de conhecimento ou ferramentas de autoatendimento.

Por que é importante

Fornece dados estruturados sobre os resultados da resolução, permitindo analisar a eficácia das correções e identificar tendências na forma como os incidentes são encerrados.

Onde obter

Normalmente, isso faz parte das informações de resolução ou encerramento no formulário 'HPD:Help Desk'.

Exemplos
Resolvido remotamenteProblema duplicadoErro do usuárioNenhuma ação necessária
Data Alvo do SLA
SlaTargetDate
A data e a hora em que o incidente deve ser resolvido de acordo com o SLA.
Descrição

Este atributo armazena o prazo para a resolução do incidente conforme definido pelo Service Level Agreement (SLA) aplicável. Ele é calculado com base na prioridade do incidente e nos horários de serviço definidos.

Esse carimbo de data e hora é a referência para medir o tempo real de resolução. É essencial para calcular o KPI 'Taxa de Conformidade de SLA de Incidentes' e para construir dashboards que mostrem o desempenho do SLA. Também permite o monitoramento proativo de incidentes que estão se aproximando do prazo.

Por que é importante

Esta é a referência para medir a conformidade com o SLA. Ela permite calcular se um incidente foi resolvido no prazo ou se houve violação do acordo.

Onde obter

Esses dados normalmente ficam no formulário 'SLM:Measurement' e são vinculados ao incidente. Não é um campo direto em 'HPD:Help Desk'.

Exemplos
2023-10-26T14:00:00Z2023-10-27T09:00:00Z2023-11-01T17:00:00Z
Descrição da resolução
Resolution
Uma descrição em texto livre das etapas realizadas para resolver o incidente.
Descrição

Este campo contém o resumo detalhado, redigido por uma pessoa, da resolução final. Ele explica o que foi feito para corrigir o problema e restabelecer o serviço ao usuário.

Embora não estruturado, esse texto pode ser analisado com técnicas de mineração de texto para identificar padrões comuns de resolução, extrair palavras-chave ligadas a problemas específicos ou complementar a análise de causa raiz. Ele traz contexto qualitativo que os campos estruturados muitas vezes não oferecem.

Por que é importante

Traz detalhes qualitativos sobre a resolução, que podem ser usados em mineração de texto para encontrar padrões não visíveis em dados estruturados.

Onde obter

Este é o campo 'Resolution' (Field ID: 1000000156) no formulário 'HPD:Help Desk'.

Exemplos
A senha do usuário foi redefinida por meio do Active Directory.Limpei o cache e os cookies do navegador, o que resolveu o problema de login.O switch de rede no armário IDF 3B foi reiniciado.
Impacto
Impact
A medida do impacto do incidente nos processos de negócio.
Descrição

O impacto avalia a extensão do efeito negativo de um incidente sobre o negócio. Geralmente é definido em uma escala, como 'Extenso/Abrangente', 'Significativo/Grande', 'Moderado/Limitado' ou 'Menor/Localizado'.

Em conjunto com a Urgência, o Impacto determina a Prioridade do incidente. Analisar por impacto ajuda a entender quais incidentes causam maior interrupção ao negócio, independentemente da complexidade técnica. Isso é fundamental para priorizar os esforços de melhoria de processo.

Por que é importante

Ajuda a quantificar a gravidade do incidente para o negócio, componente-chave para definir a prioridade e concentrar a análise em questões de alto impacto.

Onde obter

Este é o campo 'Impact' (Field ID: 1000000163) no formulário 'HPD:Help Desk'.

Exemplos
1-Extenso/Generalizado2-Significativo/Grande3-Moderado/Limitado4-Menor/Localizado
Número de reatribuições
ReassignmentCount
Número total de vezes que um incidente foi reatribuído a outro grupo.
Descrição

Essa métrica conta quantas vezes o campo 'AssignedGroup' foi alterado durante o ciclo de vida do incidente. Um número alto sugere problemas no roteamento inicial, falta de resolução no primeiro contato ou questões complexas que exigem a participação de várias equipes.

Esse atributo apoia diretamente o KPI 'Incident Reassignment Rate' e o dashboard 'Incident Reassignment Cycle Analysis'. Ele ajuda a quantificar o efeito 'ping-pong', quando os chamados ficam indo e voltando entre equipes, gerando atrasos e ineficiência no processo.

Por que é importante

Quantifica roteamentos e repasses ineficientes, ajudando a identificar incidentes que ficam presos em ciclos de reatribuição entre equipes.

Onde obter

Calculado contando quantas vezes o valor de 'AssignedGroup' muda para um determinado ID de incidente no Event Log.

Exemplos
0135
Sistema de Origem
SourceSystem
O sistema do qual os dados do incidente foram extraídos.
Descrição

Esse atributo identifica a origem dos dados, especialmente útil em ambientes com múltiplas ferramentas de ITSM ou sistemas integrados. Ele confirma que os dados vêm da fonte esperada, como uma instância específica do BMC Helix ITSM.

Na análise, ajuda a diferenciar processos ou características de dados que podem variar entre produção, desenvolvimento ou sistemas legados, garantindo que a linhagem dos dados seja clara e confiável.

Por que é importante

Identifica a origem dos dados, o que é fundamental para a validação e para gerenciar análises em vários sistemas integrados.

Onde obter

Costuma ser um valor estático adicionado durante o processo de extração, transformação e carregamento (ETL) dos dados.

Exemplos
BMCHelixITSM_ProdITSM-EU-InstanceServiceManagement-APAC
Última Atualização de Dados
LastDataUpdate
O carimbo de data/hora que indica quando os dados para este evento foram atualizados pela última vez no sistema de origem.
Descrição

Este atributo registra a data e a hora da extração de dados mais recente. Ele indica a atualidade dos dados analisados, o que é importante para entender quão recentes são os insights do processo.

Saber o horário da última atualização é fundamental para relatórios e dashboards, pois informa os usuários sobre a atualidade dos dados e ajuda a ajustar expectativas sobre a inclusão das atividades mais recentes dos incidentes.

Por que é importante

Indica a atualidade dos dados, garantindo que os usuários entendam quão atual é a análise do processo e os insights gerados.

Onde obter

Esse valor geralmente é gerado e registrado no dataset durante o processo de ETL.

Exemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z2023-11-03T02:00:00Z
Obrigatório Recomendado Opcional

Atividades de Gerenciamento de Incidentes

Estas são as etapas e os marcos principais do processo que você deve capturar no seu Event Log para descobrir o processo com precisão e visualizar o fluxo.
5 Recomendado 9 Opcional
Atividade Descrição
Grupo atribuído
Esta atividade marca a primeira atribuição do incidente a um grupo de suporte específico para investigação. Ela é inferida a partir da primeira vez que o campo 'Assigned Group' é preenchido após a criação do incidente.
Por que é importante

Este é um marco importante que marca o início do trabalho ativo. Acompanhar o tempo até a primeira atribuição é crucial para avaliar os tempos de resposta e a eficiência do roteamento inicial.

Onde obter

Inferido no log de auditoria ('HPD:HelpDesk_AuditLogSystem') para o formulário 'HPD:Help Desk', capturando o primeiro preenchimento do campo 'Assigned Group'.

Captura

A partir do timestamp em que o campo 'Assigned Group' é preenchido pela primeira vez.

Tipo de evento inferred
Incidente encerrado
Esta é a atividade final, que marca o encerramento formal do registro do incidente após a confirmação da resolução ou o término do período de confirmação. É capturada quando o status é definido como 'Closed'.
Por que é importante

Este é o evento final e definitivo do ciclo de vida do incidente. O tempo entre 'Resolved' e 'Closed' representa o período de confirmação do usuário e o encerramento administrativo.

Onde obter

Este evento corresponde ao campo 'Status' no formulário 'HPD:Help Desk' definido como 'Closed'. O carimbo de data e hora é registrado no campo 'Closed Date' e no log de auditoria.

Captura

A partir do timestamp de 'Closed Date' ou da mudança de status para 'Closed'.

Tipo de evento inferred
Incidente relatado
Esta atividade marca a criação inicial do registro do incidente no sistema. Ela é capturada explicitamente a partir do carimbo de data e hora de criação do incidente no formulário central de gerenciamento de incidentes.
Por que é importante

Este é o evento inicial primário do ciclo de vida do incidente. É essencial para calcular os tempos totais de resolução e entender a taxa de chegada de incidentes.

Onde obter

Este evento corresponde à criação do registro no formulário 'HPD:Help Desk'. O carimbo de data e hora geralmente é obtido do campo 'Submit Date' ou 'Reported Date'.

Captura

A partir do timestamp de 'Submit Date' no formulário HPD:Help Desk.

Tipo de evento explicit
Incidente resolvido
Esta atividade marca a resolução oficial do incidente pela Central de Serviços (Service Desk), antes do fechamento definitivo. Ela é capturada quando o status do incidente é definido como 'Resolved'.
Por que é importante

Este é o marco mais importante para medir a conformidade com o SLA e o tempo de resolução. Ele indica que o serviço foi restabelecido para o usuário.

Onde obter

Este evento corresponde ao campo 'Status' no formulário 'HPD:Help Desk' definido como 'Resolved'. O carimbo de data e hora é capturado no campo 'Last Resolved Date' e no log de auditoria.

Captura

A partir do timestamp da mudança de status para 'Resolved' no audit log.

Tipo de evento inferred
Investigação Iniciada
Indica que um analista de suporte começou a trabalhar no incidente. Geralmente, é inferido pela mudança de status de 'Assigned' para 'In Progress'.
Por que é importante

Esse marco sinaliza a transição da espera em fila para o diagnóstico ativo. Analisar o tempo de espera até o início da investigação ajuda a identificar gargalos de recursos e alimenta o dashboard 'Diagnosis & Investigation Bottlenecks'.

Onde obter

Inferido a partir de uma mudança de status no formulário 'HPD:Help Desk'. O evento é disparado quando o campo 'Status' muda para 'In Progress', com o carimbo de data e hora capturado no log de auditoria.

Captura

Inferido pela mudança de status para 'In Progress' no HPD:HelpDesk_AuditLogSystem.

Tipo de evento inferred
Aguardando Confirmação do Usuário
Ocorre após a implementação da solução, enquanto a equipe de suporte aguarda o usuário confirmar que a correção funcionou. Geralmente é representado pelo próprio status 'Resolved', quando o contador de fechamento automático começa.
Por que é importante

Esta atividade é crucial para o dashboard 'Atrasos de Confirmação e Verificação do Usuário'. Ela ajuda a quantificar os atrasos entre fornecer a correção e obter a validação do usuário, o que pode estender artificialmente o ciclo de vida do incidente.

Onde obter

Esse estado começa quando o 'Status' no formulário 'HPD:Help Desk' muda para 'Resolved'. A duração é medida a partir do 'Last Resolved Date' até o incidente ser encerrado ('Closed') ou reaberto ('Reopened').

Captura

Começa quando o status muda para 'Resolved', termina quando o status muda para 'Closed' ou 'In Progress'.

Tipo de evento inferred
Aguardando retorno do cliente
Representa o momento em que o andamento do incidente é pausado, aguardando informações ou uma ação do usuário. Isso é inferido por uma mudança de status para 'Pendente'.
Por que é importante

Esta atividade ajuda a separar o tempo de trabalho do agente do tempo de espera do cliente. Analisar o tempo gasto nesse estado é crucial para entender como os atrasos de resposta do usuário impactam o tempo total de resolução.

Onde obter

Inferido no formulário 'HPD:Help Desk' quando o campo 'Status' é atualizado para 'Pending'. O motivo específico geralmente está no campo 'Status_Reason'.

Captura

Inferido pela mudança de status para 'Pending' no HPD:HelpDesk_AuditLogSystem.

Tipo de evento inferred
Confirmação do usuário recebida
Representa o usuário confirmando ativamente que a solução fornecida resolveu o seu problema. Isso pode ser um evento explícito ou inferido a partir de anotações ou de uma ação relacionada do sistema antes do encerramento.
Por que é importante

Monitorar isso oferece uma visão mais precisa do processo de validação do usuário do que apenas esperar o fechamento automático. Ajuda a medir o KPI 'Average User Confirmation Time' e a identificar falhas de comunicação.

Onde obter

Isso pode ser difícil de capturar com confiabilidade. Pode ser inferido a partir de uma entrada no log de trabalho ou de uma atualização do motivo do status pouco antes de o incidente ser movido para 'Closed'. Pode exigir análise do formulário 'HPD:WorkLog'.

Captura

Inferido a partir de entradas específicas no work log ou de atualizações do motivo do status antes do fechamento.

Tipo de evento inferred
Incidente cancelado
Esta atividade representa o encerramento de um incidente criado por engano ou que deixou de ser relevante. Ela é capturada quando o status do incidente é definido como 'Cancelled'.
Por que é importante

Este é um estado final para um incidente, distinto de uma resolução bem-sucedida. Analisar incidentes cancelados pode evidenciar problemas nos canais de abertura de incidentes ou relatos duplicados.

Onde obter

Inferido no formulário 'HPD:Help Desk' quando o campo 'Status' é atualizado para 'Cancelled'. O carimbo de data e hora é capturado no log de auditoria.

Captura

Inferido pela mudança de status para 'Cancelled' no log de auditoria.

Tipo de evento inferred
Incidente categorizado
Representa o ponto em que o incidente foi classificado com categorizações operacionais e de produto, e uma prioridade foi definida. Normalmente é inferido pelo preenchimento ou pela última alteração nos campos de categorização.
Por que é importante

A categorização correta e feita na hora certa é crucial para roteamento e relatórios eficientes. Analisar essa atividade ajuda a identificar atrasos ou imprecisões na triagem inicial, dando suporte ao Dashboard "Precisão na Categorização de Incidentes".

Onde obter

Inferido no log de auditoria ('HPD:HelpDesk_AuditLogSystem') rastreando mudanças em campos como 'Operational Categorization Tier 1-3', 'Product Categorization Tier 1-3' e 'Priority' no formulário 'HPD:Help Desk'.

Captura

A partir do timestamp da última atualização dos campos de categorização ou prioridade após a criação.

Tipo de evento inferred
Incidente reaberto
Representa um incidente que foi marcado como resolvido, mas foi reativado porque o problema persiste. Isso é inferido por uma mudança de status de 'Resolvido' de volta para um estado ativo como 'Em andamento' ou 'Atribuído'.
Por que é importante

Esta atividade mede diretamente o retrabalho e a eficácia das soluções iniciais. Um alto volume de incidentes reabertos é um indicador-chave de baixa qualidade da correção e alimenta o KPI 'Taxa de Retrabalho de Incidentes'.

Onde obter

Inferido no log de auditoria ('HPD:HelpDesk_AuditLogSystem') ao detectar uma mudança de 'Status' de 'Resolved' para 'In Progress' ou 'Assigned' para um determinado ID de incidente.

Captura

Inferido pela transição de status de 'Resolved' para um estado ativo.

Tipo de evento inferred
Resolução implementada
Esta atividade indica que uma correção ou solução alternativa (workaround) foi aplicada pela equipe de suporte. Frequentemente é inferida quando o status do incidente passa para 'Resolved'.
Por que é importante

Este é um marco crítico que indica que uma solução foi entregue. É um dado essencial para medir o tempo para aplicar uma correção após a conclusão da investigação.

Onde obter

Normalmente, isso é inferido quando o 'Status' no formulário 'HPD:Help Desk' é alterado para 'Resolved'. O carimbo de data e hora é capturado no campo 'Last Resolved Date' e no log de auditoria.

Captura

A partir do timestamp de 'Last Resolved Date' ou da mudança de status para 'Resolved'.

Tipo de evento inferred
Transferido para outro grupo
Esta atividade ocorre quando um incidente é reatribuído de um grupo de suporte para outro. Ela é inferida ao detectar uma mudança no campo 'Assigned Group' após a atribuição inicial.
Por que é importante

Transferências frequentes indicam roteamento inicial incorreto ou lacunas de conhecimento. Rastrear essa atividade é essencial para o dashboard 'Análise do Ciclo de Reatribuição de Incidentes' e para o KPI 'Taxa de Reatribuição de Incidentes'.

Onde obter

Inferido no log de auditoria ('HPD:HelpDesk_AuditLogSystem') ao identificar alterações subsequentes no campo 'Assigned Group' do formulário 'HPD:Help Desk' depois do seu primeiro preenchimento.

Captura

Identifique alterações no campo 'Assigned Group' após a atribuição inicial.

Tipo de evento inferred
Violação de SLA
Este é um evento calculado que ocorre quando o tempo para resolver um incidente excede a meta definida no Service Level Agreement. Ele é obtido pela comparação entre o carimbo de data e hora da resolução e a data de vencimento do SLA.
Por que é importante

Esta atividade é fundamental para o dashboard 'Visão Geral de Desempenho do SLA de Incidentes' e para o KPI 'Taxa de Conformidade do SLA de Incidentes'. Ela sinaliza diretamente os incidentes que não cumpriram os compromissos de serviço.

Onde obter

Calculado comparando o 'Last Resolved Date' com o 'Target Date' (SLA Due Date) no formulário 'HPD:Help Desk'. Se o incidente ainda não estiver resolvido, pode ser calculado em relação ao horário atual.

Captura

Evento calculado: ocorre se 'Last Resolved Date' > 'Target Date'.

Tipo de evento calculated
Recomendado Opcional

Guias de Extração

Como obter seus dados do BMC Helix ITSM