Template de dados: Gerenciamento de Incidentes

BMC Helix
Template de dados: Gerenciamento de Incidentes

Seu Template de Dados de Gestão de Incidentes

Este Template oferece um roteiro claro para coletar os dados essenciais para analisar e otimizar o seu processo de Gestão de Incidentes no BMC Helix. Ele detalha os atributos e as atividades cruciais que devem ser acompanhados, além de orientações práticas de extração de dados. Seguindo este Template, você garante uma base completa e precisa para a descoberta e a melhoria de processos.
  • Atributos recomendados para coletar
  • Atividades-chave a monitorizar
  • Orientações de extração para o BMC Helix
É novo em event logs? Saiba como criar um event log para Process Mining.

Atributos de Gestão de Incidentes

Estes são os campos de dados recomendados para inclusão no seu Event Log, permitindo uma análise abrangente do processo de Gestão de Incidentes.
5 Obrigatório 7 Recomendado 7 Opcional
Nome Descrição
Atividade
ActivityName
O nome da ação ou do evento específico que ocorreu em um ponto do ciclo de vida do incidente.
Descrição

O nome da atividade descreve uma etapa do processo de gerenciamento de incidentes, como 'Incidente categorizado', 'Atribuído ao grupo de suporte' ou 'Incidente resolvido'. Essas atividades formam os nós no mapa do processo descoberto.

Analisar a sequência e a frequência dessas atividades é central no Process Mining. Isso ajuda a revelar o fluxo real do processo, identificar gargalos entre as etapas, detectar desvios do procedimento operacional padrão e medir a duração de fases específicas ao longo do ciclo de vida do incidente.

Por que é importante

Esse atributo define as etapas do processo, permitindo visualizar o mapa do processo e analisar fluxos, gargalos e desvios.

Onde obter

Normalmente obtido a partir de mudanças de status, logs de auditoria ou registros de eventos específicos associados ao incidente em 'HPD:HelpDesk_AuditLogSystem' ou tabelas de auditoria semelhantes.

Exemplos
Incidente reportadoAtribuído ao grupo de suporteInvestigação IniciadaIncidente resolvidoIncidente encerrado
Hora de Início
EventTimestamp
A data e hora exatas em que uma atividade ou evento específico ocorreu no incidente.
Descrição

O Event Timestamp registra o momento em que cada atividade ocorreu. Esses dados temporais são críticos para ordenar os eventos cronologicamente e construir o fluxo do processo com precisão.

Nas análises, timestamps são usados para calcular as durações entre atividades, medir o tempo de ciclo total dos incidentes e identificar atrasos ou tempos de espera no processo. A comparação de timestamps com os acordos de nível de serviço (SLAs) também é essencial para monitorar performance e verificar conformidade.

Por que é importante

Timestamps fornecem a ordem cronológica dos eventos e são essenciais para toda análise baseada em tempo, incluindo medição de performance, identificação de gargalos e conformidade com o SLA.

Onde obter

Essas informações ficam nas tabelas de auditoria, como 'HPD:HelpDesk_AuditLogSystem', correspondendo a cada ação registrada ou mudança de status.

Exemplos
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:00Z
ID do incidente
IncidentId
O identificador único de cada incidente registrado, que serve como chave primária para acompanhar o ciclo de vida do incidente.
Descrição

O Incident ID é a base da análise de gerenciamento de incidentes. Ele identifica cada caso de forma única, permitindo agregar todos os eventos relacionados, mudanças de status e atividades em uma única instância de processo coesa.

Em Process Mining, esse ID conecta cada etapa, de 'Incident Reported' a 'Incident Closed', viabilizando uma visão ponta a ponta da jornada do incidente. É essencial para calcular métricas no nível do caso, como tempo total de resolução, número de reatribuições e identificação de variantes do processo.

Por que é importante

Esse atributo é o identificador fundamental do caso, permitindo rastrear todo o ciclo de vida de um incidente e analisar seu fluxo pelo processo de gestão.

Onde obter

Campo central no módulo ou formulário principal de Gerenciamento de Incidentes, geralmente rotulado como 'Incident Number' ou 'Incident ID'.

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

Esse atributo identifica a origem dos dados, algo crucial em ambientes onde dados de vários sistemas são consolidados para análise. Ele ajuda a garantir a rastreabilidade dos dados e fornece contexto para sua estrutura e conteúdo.

No Bmc Helix, normalmente é um valor estático que identifica a instância ou o ambiente específico, por exemplo 'BmcHelix_Production'. É útil para filtrar e segmentar dados se houver mais de um sistema de origem integrado.

Por que é importante

Garante rastreabilidade e contexto sobre a origem dos dados, algo importante para governança de dados e troubleshooting em ambientes com múltiplos sistemas.

Onde obter

Normalmente é um valor estático adicionado durante o processo de extração, transformação e carga (ETL) para identificar a origem dos dados.

Exemplos
BmcHelixBmcHelix_Prod_EUITSM_Platform_A
Última Atualização de Dados
LastDataUpdate
O timestamp que indica quando os dados deste registro foram atualizados pela última vez a partir do sistema de origem.
Descrição

Esse atributo fornece o timestamp da extração de dados mais recente. É um campo de metadados essencial para entender a atualidade dos dados analisados.

Saber quando os dados foram atualizados pela última vez ajuda analistas e áreas de negócio a confiar nos insights gerados pela ferramenta de Process Mining. Isso confirma se a análise reflete o estado mais atual da operação ou está baseada em dados antigos.

Por que é importante

Garante transparência sobre a atualização dos dados, algo crítico para tomar decisões de negócio no tempo certo e com precisão, baseadas na análise do processo.

Onde obter

Este timestamp é gerado e adicionado durante o processo de extração, transformação e carga (ETL).

Exemplos
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Agente atribuído
AssignedAgent
O agente de suporte responsável por tratar o incidente.
Descrição

O Agente Responsável é a pessoa específica encarregada do incidente em determinado momento. Esse dado oferece um nível de detalhamento mais granular do que o grupo de suporte, permitindo analisar performance individual e carga de trabalho.

Esse atributo é essencial para o dashboard 'Distribuição de carga de trabalho da equipe' e para o KPI 'Desvio padrão do volume de atividades por agente'. Ao analisar o volume e os tipos de incidentes tratados por cada agente, os gestores conseguem identificar quem está sobrecarregado, equilibrar a distribuição do trabalho e encontrar oportunidades de mentoria.

Por que é importante

Permite analisar, em detalhes, a carga de trabalho e o desempenho individual, ajudando a otimizar a alocação de recursos e a identificar destaques ou quem precisa de suporte.

Onde obter

Um campo padrão no formulário 'HPD:Help Desk', geralmente chamado de 'Assignee'.

Exemplos
Alice SmithBob JohnsonCharlie Brown
Categoria do incidente
IncidentCategory
A classificação do incidente, geralmente organizada em uma estrutura hierárquica.
Descrição

A "Categoria do incidente" oferece uma maneira estruturada de classificar incidentes conforme o serviço, componente ou tipo de problema afetado, por exemplo "Hardware", "Software" ou "Network". Essa categorização é essencial para direcionar o incidente à equipe correta e para analisar tendências posteriormente.

O dashboard "Incident Categorization Accuracy" depende desse atributo, muitas vezes comparando o valor inicial com o valor na resolução do incidente para medir a qualidade da triagem inicial. Uma categorização precisa ajuda a identificar problemas recorrentes e torna a gestão de problemas mais eficaz.

Por que é importante

Uma categorização correta é vital para o roteamento eficiente, para a análise de tendências e para avaliar a precisão do diagnóstico inicial.

Onde obter

Campos padrão do formulário 'HPD:Help Desk', geralmente em cascata, como 'Categorization Tier 1', 'Categorization Tier 2' etc.

Exemplos
Software > Enterprise Apps > ERPHardware > Notebook > TecladoRede > Conectividade > Wi‑Fi
Gravidade
Severity
A medida do impacto do incidente no negócio.
Descrição

A severidade define o quanto um incidente impacta as operações do negócio. Junto com a urgência, é um fator essencial para determinar a prioridade do incidente e os SLAs associados.

Analisar incidentes por severidade ajuda a entender o desempenho do processo nos casos de maior impacto. Ela é usada em dashboards como 'Visão geral de violação crítica de SLA' para categorizar e focar nos incidentes que representam maior risco ao negócio.

Por que é importante

A severidade ajuda a quantificar o impacto nos negócios dos incidentes, permitindo análises focadas em mitigar os riscos operacionais mais relevantes.

Onde obter

Consulte a documentação do BMC Helix. Geralmente é um campo padrão do formulário de incidente, possivelmente chamado 'Impact' ou 'Severity'.

Exemplos
1-Extenso/Generalizado2-Significant/Large3-Moderate/Limited4-Minor/Localized
Grupo de suporte atribuído
AssignedSupportGroup
A equipe ou o grupo de suporte responsável por tratar o incidente.
Descrição

Esse atributo identifica a equipe atribuída a um incidente. Conforme o incidente avança, ele pode ser reatribuído a diferentes grupos de suporte, como o Service Desk, a equipe de Redes ou o Suporte a Aplicações.

Acompanhar as mudanças nesse atributo é fundamental para o Dashboard 'Incident Reassignment Analysis'. Permite visualizar os repasses entre equipes, medir o número de transferências por incidente e identificar gargalos ou lacunas de conhecimento que levam a reatribuições excessivas. Também apoia a análise da distribuição de carga de trabalho entre as equipes.

Por que é importante

Esse atributo é chave para analisar a performance das equipes, a distribuição de carga de trabalho e a eficiência do roteamento e dos repasses de incidentes.

Onde obter

Um campo padrão no formulário 'HPD:Help Desk', normalmente chamado de 'Assigned Group'.

Exemplos
Service DeskOperações de RedeAdministração de Banco de DadosApplication Support Tier 2
Prioridade
Priority
O nível de prioridade do incidente, que define a velocidade necessária para a resolução.
Descrição

Prioridade é um atributo essencial que define a urgência de um incidente. Normalmente é derivada do impacto e da urgência e serve para alocar recursos e definir metas de SLA.

Na análise de Process Mining, a prioridade é usada para segmentar os incidentes e comparar os fluxos de casos de alta e baixa prioridade. Isso ajuda a verificar se os incidentes críticos estão realmente sendo tratados mais rápido e a identificar quaisquer desvios em seus caminhos, o que é fundamental para o dashboard 'High-Priority Incident Performance' e KPIs relacionados.

Por que é importante

Esse atributo é crítico para segmentar análises e garantir que incidentes de alta urgência sejam tratados conforme os procedimentos e SLAs definidos.

Onde obter

Um campo padrão no formulário 'HPD:Help Desk', normalmente chamado de 'Priority'.

Exemplos
CríticoAltoMédioBaixo
Status do incidente
IncidentStatus
O estado atual ou histórico do incidente ao longo do seu ciclo de vida, como 'New', 'In Progress' ou 'Closed'.
Descrição

O Status do Incidente indica a etapa em que o incidente se encontra em determinado momento. Ele costuma ser a fonte para gerar o log de 'Activity', no qual uma mudança de status corresponde a uma etapa do processo.

Analisar o status permite filtrar incidentes pelo estado atual, entender quanto tempo é gasto em cada status e identificar incidentes parados. Por exemplo, um dashboard pode destacar incidentes que ficaram em status 'Pending' por um período anormalmente longo.

Por que é importante

Fornece um panorama do andamento do incidente e é essencial para identificar incidentes parados e analisar o tempo gasto em diferentes etapas.

Onde obter

Um campo central no formulário principal de incidente, normalmente no 'HPD:Help Desk'. O campo geralmente se chama 'Status'.

Exemplos
NovoAtribuídoEm ProgressoPendenteResolvidoEncerrado
Status do SLA
SLAStatus
Indica se o incidente está dentro das metas do acordo de nível de serviço (SLA) ou se houve violação.
Descrição

O status de SLA mostra de forma clara o desempenho do serviço para cada incidente. Normalmente exibe estados como 'Within Target', 'Warning' ou 'Breached'. Em geral, é um campo calculado dinamicamente no próprio Bmc Helix.

Esse atributo é essencial para o Dashboard 'Critical SLA Breach Overview' e para o KPI 'Critical Incident SLA Breach Rate'. Ele permite identificar e priorizar rapidamente incidentes que não estão cumprindo os compromissos de serviço, possibilitando uma análise focada nas causas dos atrasos.

Por que é importante

Mede diretamente o desempenho em relação aos compromissos e é fundamental para monitorar a conformidade e identificar processos que causam violações de SLA.

Onde obter

Geralmente é um campo calculado dentro do BMC Helix, derivado da prioridade e do tempo de vida do incidente. O status pode estar armazenado em um módulo relacionado de gerenciamento de SLA.

Exemplos
Dentro do SLAAvisoViolado
Canal
Channel
O método ou canal pelo qual o incidente foi registrado.
Descrição

O atributo Canal indica como o incidente foi iniciado, por exemplo, por ligação telefônica, e-mail, portal de autoatendimento ou monitoramento automatizado.

Analisar o processo por canal pode revelar diferenças importantes nos tempos de resolução ou nos caminhos do processo. Por exemplo, incidentes registrados pelo portal de autoatendimento podem ser resolvidos mais rápido devido à melhor qualidade dos dados iniciais. Essa análise orienta decisões sobre quais canais promover ou aprimorar.

Por que é importante

Ajuda a entender como o canal de abertura impacta o ciclo de vida do incidente, revelando oportunidades de otimizar canais específicos para ganhar eficiência.

Onde obter

Um campo padrão no formulário 'HPD:Help Desk', muitas vezes chamado de 'Reported Source'.

Exemplos
EmailTelefonePortal de autoatendimentoMonitoramento de sistemas
Código de resolução
ResolutionCode
Um código ou categoria que indica como o incidente foi resolvido ao final.
Descrição

O Código de resolução registra o resultado final ou a natureza da solução aplicada a um incidente. Esses dados estruturados são valiosos para análise de causa raiz e para entender os tipos de soluções mais recorrentes.

Nas análises, esse atributo pode ser comparado com o 'IncidentCategory' inicial para avaliar a precisão da categorização. Ele também traz insights sobre correções comuns, ajudando a construir uma base de conhecimento e a identificar áreas com potencial de automação.

Por que é importante

Fornece dados estruturados sobre os desfechos dos incidentes, apoiando a análise de causa raiz e o aprimoramento da gestão do conhecimento e da automação.

Onde obter

Consulte a documentação do BMC Helix. Esse campo normalmente fica na aba ou seção de resolução do formulário do incidente.

Exemplos
Erro do usuário - treinamento realizadoPatch de software aplicadoHardware substituídoNenhuma falha encontrada
Duração da resolução
ResolutionDuration
O tempo total decorrido desde a abertura do incidente até a sua resolução.
Descrição

Essa métrica mede a duração entre a atividade 'Incident Reported' e a atividade 'Incident Resolved'. É um indicador-chave da eficiência de todo o processo de gerenciamento de incidentes.

Esse atributo calculado é a base do KPI 'Average Incident Resolution Time' e do Dashboard 'Incident Resolution Cycle Time'. Analisar essa duração por categoria, prioridade ou equipe ajuda a identificar fontes sistêmicas de atraso e a medir o impacto das iniciativas de melhoria de processo.

Por que é importante

Métrica principal de eficiência do processo e de experiência do cliente, refletindo diretamente quanto tempo leva para restabelecer o serviço para os usuários.

Onde obter

Calculado na transformação dos dados, medindo a diferença entre o timestamp da atividade 'Incident Resolved' e o da atividade 'Incident Reported' em cada caso.

Exemplos
25920000086400000604800000
Está reaberto
IsReopened
Um indicador que mostra se um incidente foi reaberto após ser resolvido.
Descrição

Esse atributo calculado é um indicador booleano que é verdadeiro se houver a atividade 'Incident Reopened' no histórico do incidente. Uma taxa alta de reabertura pode indicar problemas na qualidade das resoluções ou fechamento prematuro dos tickets.

Esse indicador é usado diretamente no cálculo do KPI 'Incident Re-opening Rate' e no Dashboard 'Incident Re-opening Rate Trend'. Ele permite que analistas filtrem e investiguem facilmente incidentes reabertos para entender as causas raiz, como correções incompletas ou falhas de comunicação com o usuário.

Por que é importante

Esse indicador mede diretamente a qualidade da resolução e a satisfação do cliente, destacando casos em que a correção inicial não foi eficaz.

Onde obter

Campo calculado, derivado durante a transformação de dados ao verificar se o Event Log do incidente contém uma atividade 'Reopened' ou uma transição de status correspondente.

Exemplos
verdadeirofalse
Número de reatribuições
ReassignmentCount
O número total de vezes que um incidente foi transferido entre diferentes grupos de suporte.
Descrição

Esse atributo calculado conta quantas vezes o campo 'AssignedSupportGroup' mudou ao longo do ciclo de vida do incidente. Um número alto de reatribuições, o chamado 'ping-pong de tickets', indica ineficiências do processo, como roteamento inicial incorreto ou lacunas de conhecimento nas equipes de suporte.

Essa métrica é a base do KPI 'Average Reassignments per Incident' e do Dashboard 'Incident Reassignment Analysis'. Acompanhar essa contagem ajuda a identificar oportunidades para melhorar a taxa de resolução no primeiro contato e tornar o roteamento mais enxuto, reduzindo o tempo de resolução.

Por que é importante

Quantifica ineficiências e atritos do processo, destacando incidentes que são repassados entre equipes, o que atrasa a resolução.

Onde obter

Calculado durante a transformação dos dados, contando o número de valores distintos ou de alterações no campo 'AssignedSupportGroup' ao longo do ciclo de vida de cada incidente.

Exemplos
0135
Serviço de Negócio
BusinessService
O serviço de negócio ou a aplicação afetada pelo incidente.
Descrição

Esse atributo vincula um incidente a um serviço de negócio específico definido na Configuration Management Database (CMDB), como 'Email Service' ou 'ERP System'.

Analisar incidentes pelo serviço de negócio afetado é crucial para entender o impacto na organização. Isso ajuda a priorizar esforços de gestão de problemas nos serviços que geram mais incidentes ou sofrem mais indisponibilidades. Essa visão é essencial para reportar a performance de TI sob a ótica do negócio.

Por que é importante

Conecta os incidentes técnicos ao impacto no negócio, permitindo priorizar o trabalho pelo que é mais crítico para a organização.

Onde obter

Campo de Configuration Item (CI) no formulário do incidente, que faz referência à CMDB. O rótulo pode aparecer como 'Service' ou 'CI'.

Exemplos
Serviço de e-mail corporativoSAP ERP FinancialsCRM (Customer Relationship Management)
SLA violado
IsSlaBreached
Um indicador booleano que mostra se o tempo de resolução do incidente excedeu a meta do SLA.
Descrição

Indicador simplificado, derivado do atributo 'SLAStatus', em que 'true' indica que o SLA foi violado. Isso gera um resultado claro e binário para facilitar o filtro e a agregação.

Esse atributo é usado para calcular o KPI 'Critical Incident SLA Breach Rate'. Ele permite segmentar todos os incidentes de forma direta em dois grupos, com violação e sem violação, para analisar as características de processo mais comuns entre os incidentes que não cumprem as metas de serviço.

Por que é importante

Fornece um resultado simples e binário de conformidade com o SLA, facilitando o cálculo de taxas de quebra e a análise dos caminhos mais comuns dos casos não conformes.

Onde obter

Derivado do atributo 'SLAStatus' durante a transformação dos dados. Se 'SLAStatus' for 'Breached', esse indicador é definido como true.

Exemplos
verdadeirofalse
Obrigatório Recomendado Opcional

Atividades de Gestão de Incidentes

Estas são as etapas e os marcos essenciais que devem ser capturados no seu Event Log para que a descoberta e a análise do processo sejam precisas.
6 Recomendado 8 Opcional
Atividade Descrição
Atribuído ao grupo de suporte
Essa atividade indica a primeira atribuição do incidente a um grupo de suporte específico para investigação e resolução. Representa o primeiro repasse do Service Desk para uma equipe técnica.
Por que é importante

Marco crítico para acompanhar a taxa de resolução no primeiro contato e os tempos de resposta iniciais. Ajuda a identificar atrasos no encaminhamento do incidente para a equipe correta.

Onde obter

Obtido rastreando o primeiro preenchimento do campo 'Assigned Group' no histórico de auditoria do incidente (HPD:HelpDesk_AuditLogSystem).

Captura

Inferido a partir da primeira alteração registrada no campo 'Assigned Group' nos logs de auditoria.

Tipo de evento inferred
Incidente encerrado
A atividade final do ciclo de vida, quando o registro do incidente é formalmente encerrado e se torna um registro histórico somente para leitura. Isso geralmente ocorre automaticamente após um período definido no estado 'Resolved'.
Por que é importante

Essa atividade marca o encerramento definitivo do processo. O tempo entre 'Resolved' e 'Closed' pode evidenciar atrasos em rotinas administrativas ou no período de confirmação do usuário.

Onde obter

Evento distinto inferido a partir do timestamp em que o campo 'Status' é atualizado para 'Closed'. Esse registro é acompanhado no histórico de auditoria.

Captura

Filtre os logs de auditoria pela mudança de status para 'Closed'.

Tipo de evento inferred
Incidente reportado
Indica a criação de um novo registro de incidente no sistema. É o ponto de partida do ciclo de vida do incidente, normalmente disparado por um envio do usuário via portal, e-mail ou pela abertura manual do ticket por um agente do service desk.
Por que é importante

Essa atividade é o principal evento de início do processo. Analisar o tempo entre esse evento e a resolução é fundamental para medir a duração total do ciclo de vida do incidente e identificar atrasos nas etapas iniciais.

Onde obter

Evento explícito de criação capturado a partir do timestamp 'Submit Date' ou 'Reported Date' no formulário HPD:Help Desk. É um dos eventos mais confiáveis e fundamentais do sistema.

Captura

Obtido a partir do timestamp de criação do registro de incidente na tabela HPD:Help Desk.

Tipo de evento explicit
Incidente resolvido
Indica que uma solução foi implementada e o serviço foi restabelecido para o usuário. É um marco importante, normalmente registrado por uma mudança de status para 'Resolved'.
Por que é importante

Marco principal para medir o tempo de resolução central. Indica o fim da fase de trabalho ativo e, frequentemente, inicia a contagem para a confirmação do usuário ou procedimentos de fechamento automático.

Onde obter

Evento distinto inferido a partir do timestamp em que o campo 'Status' é atualizado para 'Resolved'. Essa alteração é registrada no histórico de auditoria.

Captura

Filtre os logs de auditoria pela mudança de status para 'Resolved'.

Tipo de evento inferred
Resolução identificada
Representa o momento em que o analista encontra uma solução e a documenta no registro do incidente. O incidente fica pronto para avançar para o estado 'Resolved'.
Por que é importante

Este marco sinaliza o fim da fase de investigação técnica. O tempo entre esse ponto e o fechamento pode revelar gargalos de comunicação, verificação e processos administrativos.

Onde obter

Frequentemente inferido pelo timestamp do registro e salvamento dos detalhes da resolução, pouco antes de o status mudar para 'Resolved'.

Captura

Use o timestamp da última modificação antes de o status mudar para 'Resolved'.

Tipo de evento inferred
Solução de contorno implementada
Indica que uma solução temporária foi fornecida ao usuário, restabelecendo a funcionalidade do serviço enquanto uma correção definitiva é desenvolvida. Geralmente é registrado por meio de um flag ou de um status específico.
Por que é importante

Monitorar isso ajuda a medir a velocidade de restauração do serviço, fator crítico para a satisfação do usuário. Na análise do processo, separa correções temporárias de resoluções permanentes.

Onde obter

Isso pode ser inferido pelo timestamp no momento em que o campo 'Workaround' nos detalhes de resolução do incidente é preenchido ou quando um status específico 'Workaround Provided' é utilizado.

Captura

Use o timestamp da mudança de status para o estado 'Workaround' ou do momento em que as notas de resolução indicando um workaround são salvas pela primeira vez.

Tipo de evento inferred
Confirmação do usuário recebida
Representa o reconhecimento do usuário de que a solução fornecida resolveu o problema. Muitas vezes é uma etapa opcional e pode ser registrada por uma ação no portal ou pelo agente.
Por que é importante

Analisar a taxa e a velocidade das confirmações do usuário ajuda a avaliar a eficácia da comunicação e a qualidade da resolução. Uma taxa de confirmação baixa pode levar a uma taxa de reabertura mais alta.

Onde obter

Difícil de capturar diretamente e, muitas vezes, inferido. Pode aparecer como um status específico, como 'Resolved - Confirmed', ou como uma anotação adicionada ao work log do incidente.

Captura

Exige análise no sistema. Procure por registros de work log ou mudanças de status que indiquem feedback do usuário.

Tipo de evento inferred
Incidente categorizado
Representa a classificação inicial do incidente, incluindo a definição de categoria, tipo e item. Essa atividade geralmente é realizada por um agente de service desk Nível 1 pouco depois do registro do incidente.
Por que é importante

Acompanhar essa atividade ajuda a avaliar a precisão das classificações iniciais e seu impacto no encaminhamento e na resolução. Mudanças de categorização em etapas posteriores indicam retrabalho e possíveis lacunas de conhecimento.

Onde obter

Inferido a partir da primeira vez que os campos de categorização operacional e de produto ('OpCat', 'ProdCat') são preenchidos no log de auditoria do incidente (HPD:HelpDesk_AuditLogSystem).

Captura

Identifique o primeiro timestamp em que os campos de categorização são preenchidos no log de auditoria.

Tipo de evento inferred
Incidente colocado em espera
Essa atividade ocorre quando o andamento de um incidente é pausado, normalmente enquanto se aguardam informações do usuário ou de um fornecedor externo. Geralmente isso se reflete em uma mudança de status para 'Pending'.
Por que é importante

Essa atividade é crucial para calcular com precisão os tempos de resolução. O período em que o incidente fica no status 'Pending' geralmente deve ser excluído dos cálculos de SLA para avaliar de forma justa a performance da equipe de suporte.

Onde obter

Inferido a partir de uma alteração no campo 'Status' para um estado 'Pending'. O log de auditoria registra o timestamp dessa mudança.

Captura

Filtre os logs de auditoria pela mudança de status para 'Pending' ou um status de espera similar.

Tipo de evento inferred
Incidente reaberto
Ocorre quando um incidente anteriormente resolvido ou encerrado volta ao estado ativo. Geralmente acontece quando o usuário informa que o problema reapareceu.
Por que é importante

Uma taxa alta de reabertura indica problemas na qualidade das resoluções. Acompanhar esse ciclo de retrabalho é essencial para identificar causas raiz de correções ineficazes e melhorar a resolução no primeiro contato.

Onde obter

Inferido por uma mudança de status de 'Resolved' ou 'Closed' de volta para um estado ativo como 'In Progress' ou 'Assigned'. Essa transição é registrada no histórico de auditoria.

Captura

Filtre os logs de auditoria pela mudança de status de um estado resolvido/fechado para um estado aberto.

Tipo de evento inferred
Investigação Iniciada
Indica que o agente designado começou a trabalhar ativamente no incidente. Geralmente é representado por uma mudança de status de 'Assigned' para 'In Progress' ou estado semelhante.
Por que é importante

Medir o tempo entre a atribuição e o início da investigação revela atrasos na fila e ajuda a avaliar a capacidade de resposta dos agentes e sua capacidade de absorver a carga de trabalho.

Onde obter

Inferido a partir da mudança do campo 'Status' de 'Assigned' para 'In Progress'. O timestamp dessa alteração de status é registrado no log de auditoria.

Captura

Filtre os logs de auditoria pela primeira mudança de status para 'In Progress' após uma atribuição.

Tipo de evento inferred
Status Pendente retomado
Indica o momento em que um incidente em espera é reativado. Isso ocorre quando as informações necessárias são recebidas e, em geral, aparece com a mudança de status de 'Pending' para 'In Progress'.
Por que é importante

Esse evento, combinado com 'Incident Put On Hold', permite medir com precisão os tempos de espera. Análises de tempos de espera longos podem indicar problemas de comunicação com usuários ou terceiros.

Onde obter

Inferido por uma mudança de status de 'Pending' para um estado ativo como 'In Progress'. O timestamp está disponível no log de auditoria.

Captura

Filtre os logs de auditoria pela mudança de status de 'Pending' para 'In Progress' ou 'Assigned'.

Tipo de evento inferred
Transferido para outro grupo
Representa a reatribuição de um incidente de um grupo de suporte para outro. Isso ocorre quando o grupo inicial não consegue resolver o problema e precisa da especialidade de outra equipe.
Por que é importante

Transferências frequentes, o famoso "pingue-pongue", são uma grande fonte de atraso e ineficiência. Analisar essas atividades ajuda a identificar problemas de roteamento, lacunas de habilidade e gargalos do processo.

Onde obter

Inferido por uma alteração no valor do campo 'Assigned Group' no histórico de auditoria do incidente, após a atribuição inicial.

Captura

Cada alteração no campo 'Assigned Group' no log de auditoria após a primeira atribuição representa uma transferência.

Tipo de evento inferred
Violação de SLA detectada
Um evento calculado que ocorre quando o tempo de resposta ou resolução de um incidente excede as metas definidas no Acordo de Nível de Serviço (SLA). Não é um evento direto do sistema.
Por que é importante

Identificar violações de SLA é essencial para monitorar a conformidade e priorizar incidentes críticos. Isso ajuda a apontar quais etapas do processo mais contribuem para as violações.

Onde obter

Esse evento é calculado comparando o timestamp da atividade 'Incident Resolved' (ou outros marcos de SLA) com a 'Reported Date' e a meta de SLA definida para a prioridade daquele incidente.

Captura

Calcule comparando o timestamp de resolução com o timestamp de início somado à duração do SLA.

Tipo de evento calculated
Recomendado Opcional

Guias de Extração

Como extrair seus dados do BMC Helix