Template de Dados: Gestão de Incidentes
Seu template de dados para Gestão de Incidentes
- Atributos recomendados para coletar
- Principais atividades para acompanhar no seu processo
- Orientações de extração para o seu sistema de dados
Atributos de Gerenciamento de Incidentes
| 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
|
|||
Atividades de Gerenciamento de Incidentes
| 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
|
|||