Seu Template de dados de gerenciamento de incidentes
Seu Template de dados de gerenciamento de incidentes
- Atributos recomendados para coleta
- Principais atividades para acompanhar
- Orientações de extração para o gerenciamento de problemas no ServiceNow
Atributos do gerenciamento de incidentes
| Nome | Descrição | ||
|---|---|---|---|
|
Data e hora do evento
EventTime
|
Data e hora exatas em que a atividade ocorreu. | ||
|
Descrição
A data e hora do evento registram o momento exato em que uma atividade foi concluída ou ocorreu uma mudança de status. No ServiceNow, esse dado costuma ser registrado no campo sys_updated_on para cada alteração no histórico de auditoria. Este atributo é essencial para ordenar os eventos corretamente e realizar análises baseadas em tempo. Ele é usado para calcular tempos de ciclo, tempos de fila e durações entre atividades, fundamentais para identificar gargalos, medir a performance em relação aos SLAs e entender a eficiência do processo. A precisão dessas datas e horas é essencial para garantir a validade de qualquer métrica baseada em duração.
Por que isso importa
Esta data e hora ordena cronologicamente todas as atividades e permite calcular métricas baseadas em duração, como tempos de ciclo e gargalos.
Onde encontrar
Tabela sys_audit do ServiceNow, campo sys_created_on ou campo sys_updated_on da tabela incident para o último estado.
Exemplos
2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
|
|||
|
ID do incidente
IncidentId
|
Identificador exclusivo de cada registro de incidente, usado como chave principal para acompanhar todo o ciclo de vida. | ||
|
Descrição
O ID do incidente é o número de referência exclusivo atribuído a cada incidente registrado no ServiceNow. Ele funciona como identificador principal do caso e vincula todas as atividades, atualizações e comunicações relacionadas, desde a criação do incidente até seu encerramento. Na análise de Process Mining, esse ID é fundamental. Ele permite que a ferramenta reúna a sequência de eventos de cada caso, formando a base para descobrir mapas de processo, analisar variantes e calcular durações de ponta a ponta. Sem um ID exclusivo para cada incidente, seria impossível acompanhar sua trajetória ao longo do processo de resolução.
Por que isso importa
Este é o ID do caso essencial para conectar todos os eventos do ciclo de vida de um incidente e possibilitar a análise do processo de ponta a ponta.
Onde encontrar
Tabela de incidentes do ServiceNow, campo number.
Exemplos
INC0010001INC0010045INC0010239
|
|||
|
Nome da atividade
ActivityName
|
Nome do evento ou da tarefa específica que ocorreu em determinado momento do ciclo de vida do incidente. | ||
|
Descrição
O nome da atividade descreve uma etapa específica ou uma mudança de status no processo de gerenciamento de incidentes, como 'Incidente criado', 'Incidente atribuído a um agente' ou 'Incidente encerrado'. Em geral, esses dados são derivados de alterações em campos importantes do incidente, como 'State' ou 'Assignment Group', ou de entradas específicas no registro. Este atributo é essencial para criar o mapa do processo. Ele define os nós do grafo do processo e permite que analistas visualizem o fluxo dos incidentes, identifiquem caminhos comuns, descubram gargalos entre atividades e analisem variantes do processo. A granularidade e a precisão dos nomes das atividades afetam diretamente a qualidade da análise do processo.
Por que isso importa
Ele define as etapas do mapa do processo, que serve de base para todas as análises e visualizações de Process Mining.
Onde encontrar
Este atributo é derivado e, em geral, gerado pela lógica de transformação de dados com base nas alterações em campos como state, assignment_group e assigned_to nas tabelas sys_audit ou incident.
Exemplos
Incidente criadoGrupo de atribuição alteradoResolução propostaIncidente encerrado
|
|||
|
Sistema de origem
SourceSystem
|
Sistema do qual estes dados foram extraídos. | ||
|
Descrição
Este atributo identifica a origem dos dados do incidente, que, neste caso, é o Gerenciamento de Problemas do ServiceNow. Em geral, é um valor estático adicionado durante a extração e transformação dos dados. Em ambientes que combinam dados de vários sistemas para análise, este campo é essencial para rastrear a linhagem e separar os dados. Ele ajuda a garantir que as métricas e os processos sejam analisados no contexto correto e permite que analistas comparem processos entre diferentes sistemas de origem.
Por que isso importa
Ele oferece contexto essencial sobre a origem dos dados, garantindo a rastreabilidade e permitindo a interpretação correta em ambientes com vários sistemas.
Onde encontrar
Em geral, este é um valor estático adicionado durante a extração dos dados.
Exemplos
Gerenciamento de Problemas no ServiceNowServiceNow
|
|||
|
Última atualização dos dados
LastDataUpdate
|
Data e hora que indicam quando os dados deste registro foram atualizados pela última vez a partir do sistema de origem. | ||
|
Descrição
Este atributo registra a data e a hora da extração ou atualização mais recente dos dados do ServiceNow. É um campo de metadados que indica o grau de atualização dos dados analisados, não um evento do processo em si. Essa informação é essencial para entender a atualidade da análise. Ela mostra aos usuários quão recentes são os dados, algo importante para os Dashboards operacionais e para tomar decisões com base em eventos recentes. Também ajuda a alinhar as expectativas sobre a relevância e a atualidade dos dados.
Por que isso importa
Ele informa aos usuários se os dados estão atualizados, algo essencial para a relevância e a precisão da análise.
Onde encontrar
Esta data e hora é gerada e preenchida pela ferramenta ou pelo processo de extração de dados durante o carregamento dos dados.
Exemplos
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Atribuído a
AssignedTo
|
Usuário ou agente responsável por trabalhar no incidente no momento. | ||
|
Descrição
Este atributo identifica o agente de suporte específico responsável pelo incidente em determinado momento. Essa informação é essencial para entender a distribuição da carga de trabalho, a performance dos agentes e as transferências entre pessoas. Na análise, 'Atribuído a' ajuda a visualizar a alocação de recursos e identificar agentes sobrecarregados. Também é usado no Dashboard de transferências e reatribuições para acompanhar quantas vezes um incidente muda de responsável, o que pode indicar ineficiência ou lacunas de conhecimento. Analisar os tempos de resolução por agente também pode destacar os profissionais com melhor performance ou aqueles que precisam de treinamento adicional.
Por que isso importa
Ele permite analisar a carga de trabalho, a performance e as transferências entre agentes, aspectos essenciais para entender a eficiência dos recursos.
Onde encontrar
Tabela de incidentes do ServiceNow, campo assigned_to.
Exemplos
Beth AnglinDavid LooHoward Johnson
|
|||
|
Estado do incidente
IncidentState
|
Status atual do incidente em seu ciclo de vida. | ||
|
Descrição
O estado do incidente indica sua etapa atual, como 'New', 'In Progress', 'On Hold' ou 'Resolved'. As mudanças de estado costumam ser a principal fonte para gerar atividades no Event Log usado no Process Mining. Analisar o tempo gasto em cada estado é uma forma eficaz de identificar gargalos. Por exemplo, um período longo no estado 'On Hold' pode indicar dependências de fatores externos ou dos usuários. A sequência de mudanças de estado também forma a base do mapa do processo, mostrando como os incidentes avançam até a resolução.
Por que isso importa
Ele acompanha o andamento do incidente e é essencial para analisar o tempo gasto em cada etapa e identificar gargalos no processo.
Onde encontrar
Tabela de incidentes do ServiceNow, campo incident_state ou state.
Exemplos
NovoEm andamentoAguardando informações do usuárioResolvidoEncerrado
|
|||
|
Grupo de atribuição
AssignmentGroup
|
Equipe ou grupo de suporte responsável por atender o incidente. | ||
|
Descrição
O grupo de atribuição representa a equipe de agentes encarregada de resolver o incidente. Muitas vezes, os incidentes são encaminhados entre diferentes grupos, como de uma central de suporte de nível 1 para uma equipe especializada de redes de nível 2. Este atributo é essencial para analisar as transferências entre equipes e identificar gargalos sistêmicos. O Dashboard 'Taxa de transferências e reatribuições' depende bastante desses dados para mostrar quais equipes participam com frequência das transferências. Ele também permite comparar a performance entre grupos de suporte e entender onde está o conhecimento necessário para resolver os incidentes na organização.
Por que isso importa
Este atributo acompanha qual equipe é responsável e permite analisar a performance, a carga de trabalho e as transferências entre grupos.
Onde encontrar
Tabela de incidentes do ServiceNow, campo assignment_group.
Exemplos
Central de serviçosSuporte de redesAdministradores de banco de dados
|
|||
|
Prioridade
Priority
|
Nível de prioridade do incidente, que determina a urgência necessária para a resposta. | ||
|
Descrição
A prioridade é um campo importante no ServiceNow que determina a ordem e a rapidez do atendimento a um incidente. Em geral, ela é definida com base no impacto e na urgência do incidente e influencia diretamente as metas de SLA. Este atributo é fundamental para segmentar e analisar a performance. O Dashboard 'Visão geral da conformidade com os SLAs' usa a prioridade para avaliar se os incidentes de alta prioridade estão sendo resolvidos dentro do prazo previsto. Analisar os tempos de ciclo por prioridade ajuda a confirmar se os incidentes críticos estão sendo processados mais rapidamente do que os menos importantes. É uma dimensão essencial para quase todos os KPIs e Dashboards.
Por que isso importa
Ele permite segmentar os incidentes por importância para o negócio, algo essencial para monitorar a conformidade com os SLAs e alocar recursos.
Onde encontrar
Tabela de incidentes do ServiceNow, campo priority.
Exemplos
1 - Crítico2 - Alto3 - Moderado4 - Baixo
|
|||
|
Categoria
Category
|
Classificação geral do incidente, como Hardware, Software ou Rede. | ||
|
Descrição
A categoria oferece uma classificação geral da natureza do incidente. Muitas vezes, em conjunto com uma subcategoria, ela ajuda a encaminhar o incidente à equipe de suporte correta e é usada em relatórios e análises de tendências. No Process Mining, este atributo é essencial para os Dashboards 'Precisão da categorização de incidentes' e 'Volume de incidentes recorrentes'. Ao analisar incidentes cuja categoria muda durante o processo, as organizações podem identificar problemas na triagem inicial. Filtrar o mapa do processo por categoria também pode revelar se determinados tipos de incidente seguem caminhos de resolução diferentes ou enfrentam gargalos específicos.
Por que isso importa
Ele permite analisar os tipos de incidente, medir a precisão da categorização e apoiar o encaminhamento e a análise de tendências.
Onde encontrar
Tabela de incidentes do ServiceNow, campo category.
Exemplos
HardwareSoftwareRedeBanco de dados
|
|||
|
Código de resolução
ResolutionCode
|
Código que indica como o incidente foi resolvido. | ||
|
Descrição
O código de resolução especifica a natureza da solução aplicada, por exemplo, se o incidente foi resolvido pelo usuário, por um erro conhecido ou com uma solução alternativa. Em geral, o agente preenche esse campo ao encerrar o incidente. Esse atributo alimenta diretamente o Dashboard de eficácia dos tipos de resolução. Com ele, você pode analisar quantos incidentes foram encerrados com correções permanentes e quantos receberam soluções temporárias, um indicador importante da qualidade do serviço e da estabilidade no longo prazo. Uma alta proporção de soluções alternativas pode indicar que os problemas subjacentes não estão sendo tratados adequadamente.
Por que isso importa
Esclarece o método de resolução, permitindo comparar correções permanentes e soluções temporárias e apoiar a análise de causa raiz.
Onde encontrar
Tabela de incidentes do ServiceNow, campo close_code ou um campo personalizado de código de resolução.
Exemplos
Resolvido (solução alternativa)Resolvido (permanentemente)Não resolvido (cancelado pelo usuário)Erro conhecido
|
|||
|
Contagem de reatribuições
ReassignmentCount
|
Número de vezes que o incidente foi reatribuído a outro grupo ou agente. | ||
|
Descrição
Esse campo registra quantas vezes um incidente foi transferido entre diferentes grupos de atribuição. É uma medida direta de atrito no processo e costuma ser usada como indicador-chave de performance. Esse atributo é o principal indicador do Dashboard de handoffs e taxa de reatribuição e do KPI de média de handoffs por incidente. Uma contagem alta de reatribuições costuma indicar problemas como encaminhamento inicial incorreto, falta de habilidades em um nível de suporte ou falta de clareza sobre a responsabilidade pelo processo. Reduzir esse número é um objetivo comum das iniciativas de melhoria de processos, pois geralmente acelera a resolução.
Por que isso importa
Mede diretamente os handoffs no processo, um indicador importante de ineficiência, encaminhamento incorreto e oportunidades de melhoria.
Onde encontrar
Tabela de incidentes do ServiceNow, campo reassignment_count.
Exemplos
0135
|
|||
|
Data limite do SLA
SlaDueDate
|
Data e hora limite para resolver o incidente, conforme o SLA. | ||
|
Descrição
A data limite do SLA é um timestamp calculado que representa o prazo para resolver um incidente. Essa data é determinada pelo Acordo de Nível de Serviço (SLA) associado às características do incidente, como a prioridade. Esse atributo é essencial para o Dashboard de visão geral da conformidade com o SLA e para o KPI de taxa de violações do SLA em incidentes críticos. Ele serve como referência para comparar o prazo com o tempo real de resolução. Analisar incidentes próximos da data limite do SLA pode ajudar a priorizar casos e escalá-los proativamente.
Por que isso importa
Define a meta de resolução, permitindo medir a conformidade com o SLA e identificar incidentes com risco de ultrapassar o prazo.
Onde encontrar
Esse valor costuma estar na tabela task_sla, relacionada à tabela de incidentes. O campo planned_end_time contém o timestamp relevante.
Exemplos
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
|
|||
|
Gravidade
Severity
|
Nível de impacto do incidente nos negócios. | ||
|
Descrição
A gravidade indica o impacto do incidente nas operações de negócios. Junto com a urgência, ela costuma ser usada para calcular automaticamente a prioridade do incidente. Na análise, a gravidade é uma dimensão importante para o Dashboard de visão geral da conformidade com o SLA. Ela ajuda a entender se os níveis de serviço estão sendo cumpridos nos incidentes que mais afetam as operações. Assim, você tem uma visão de performance orientada aos negócios, que complementa a perspectiva operacional oferecida pela prioridade.
Por que isso importa
Mede o impacto do incidente nos negócios e oferece uma dimensão importante para priorizar esforços e analisar a performance em questões críticas.
Onde encontrar
Tabela de incidentes do ServiceNow, campo severity.
Exemplos
1 - Alta2 - Média3 - Baixa
|
|||
|
ID do problema
ProblemId
|
Identificador do registro de problema associado, caso o incidente esteja vinculado a uma questão mais ampla. | ||
|
Descrição
O ID do problema vincula um incidente ao registro correspondente no módulo de Gerenciamento de Problemas. Isso acontece quando se identifica que o incidente é um sintoma de uma questão subjacente mais ampla, que afeta vários usuários ou serviços. Esse vínculo é essencial para o Dashboard de volume de incidentes recorrentes e para o KPI de taxa de incidentes recorrentes. Ele permite que os analistas agrupem incidentes com a mesma causa raiz, meçam o impacto total de um problema e acompanhem a eficácia das iniciativas de resolução. Um grande número de incidentes vinculados a problemas indica um ambiente de suporte reativo.
Por que isso importa
Vincula incidentes à causa raiz, algo essencial para analisar problemas recorrentes e medir o impacto do gerenciamento de problemas.
Onde encontrar
Tabela de incidentes do ServiceNow, campo problem_id.
Exemplos
PRB0040001PRB0040015PRB0040102
|
|||
|
Item de configuração
ConfigurationItem
|
Componente, serviço ou ativo de TI específico afetado pelo incidente. | ||
|
Descrição
O item de configuração (CI) é o ativo da Base de Dados de Gerenciamento de Configuração (CMDB) afetado pelo incidente. Pode ser um servidor, aplicativo, notebook ou dispositivo de rede. Analisar os incidentes por CI ajuda a identificar ativos ou serviços pouco confiáveis. Você consegue descobrir quais partes da infraestrutura de TI geram mais incidentes e usar essa informação para orientar investimentos em atualizações ou substituições. No Process Mining, filtrar por CI pode revelar se os incidentes relacionados a aplicativos críticos são tratados de forma diferente ou mais eficiente.
Por que isso importa
Identifica o ativo afetado, ajudando a localizar componentes problemáticos na infraestrutura de TI e direcionar as iniciativas de melhoria.
Onde encontrar
Tabela de incidentes do ServiceNow, campo cmdb_ci.
Exemplos
Produção do SAP ERPServidor de banco de dados Oracle 05Serviço de e-mail
|
|||
|
Reaberto
IsReopened
|
Indicador que informa se um incidente foi reaberto após a resolução. | ||
|
Descrição
Esse indicador booleano recebe o valor verdadeiro quando o estado de um incidente volta a ser ativo, como In Progress, depois de ter chegado a Resolved ou Closed. Em geral, isso é identificado pela atividade Incident Reopened no Event Log. Incidentes reabertos são um forte sinal de resoluções incompletas ou ineficazes. Analisar esses casos ajuda a identificar encerramentos prematuros ou problemas recorrentes que não foram corrigidos na primeira tentativa. Uma alta taxa de reabertura pode prejudicar a satisfação dos usuários e a produtividade da equipe, por isso é uma métrica importante para o controle de qualidade.
Por que isso importa
Esse indicador identifica falhas no processo de resolução e destaca incidentes que exigiram trabalho adicional depois de serem considerados resolvidos.
Onde encontrar
Calculado verificando a sequência de atividades de cada incidente para identificar se um estado aberto ocorre depois de um estado resolvido.
Exemplos
truefalse
|
|||
|
SLA violado
IsSlaBreached
|
Indicador que informa se a resolução do incidente ultrapassou a data limite do SLA. | ||
|
Descrição
Este atributo booleano calculado indica se um incidente violou o Acordo de Nível de Serviço. Ele é obtido comparando o timestamp real da resolução com a data limite do SLA. Se a resolução ocorrer depois do prazo, o indicador recebe o valor verdadeiro. Esse atributo é a base do Dashboard de visão geral da conformidade com o SLA e dos KPIs relacionados. Ele simplifica a análise ao transformar uma comparação complexa de horários em uma dimensão simples de verdadeiro ou falso. Assim, fica fácil filtrar todos os incidentes que violaram o SLA e analisar características em comum, como categoria, grupo de atribuição ou prioridade.
Por que isso importa
Simplifica a análise da conformidade com o SLA, facilitando a filtragem e a análise aprofundada dos incidentes que não cumpriram as metas.
Onde encontrar
Calculado comparando o timestamp de Resolved At com o timestamp de SlaDueDate. (Resolved At > SlaDueDate).
Exemplos
truefalse
|
|||
|
Solicitante
CallerId
|
Usuário que relatou o incidente inicialmente. | ||
|
Descrição
O solicitante é o usuário final ou cliente afetado pelo incidente que o relatou. Essa informação ajuda a entender quem sofre o impacto das interrupções no serviço. Embora nem sempre seja central para o fluxo do processo, analisar os incidentes por solicitante pode revelar se determinadas pessoas ou áreas são afetadas de forma desproporcional. Isso pode indicar necessidades de treinamento ou problemas localizados no ambiente. Também permite entrar em contato diretamente com o cliente para enviar pesquisas de satisfação e compartilhar informações.
Por que isso importa
Identifica o usuário afetado, permitindo analisar os dados por área ou pessoa e contextualizar a comunicação com o usuário.
Onde encontrar
Tabela de incidentes do ServiceNow, campo caller_id.
Exemplos
Abel TuterCarolina PashDon Goodliffe
|
|||
Atividades do gerenciamento de incidentes
| Atividade | Descrição | ||
|---|---|---|---|
|
Grupo de atribuição alterado
|
Representa uma transferência do incidente de um grupo de suporte para outro. Isso pode ser identificado pelas alterações posteriores no campo 'assignment_group', após o preenchimento inicial. | ||
|
Por que isso importa
Reatribuições frequentes podem indicar um encaminhamento inicial incorreto, complexidade do processo ou lacunas de conhecimento. Esta atividade é essencial para medir o KPI 'Média de transferências por incidente'.
Onde encontrar
Inferido da tabela 'sys_audit', acompanhando qualquer alteração no campo 'assignment_group' após a atribuição inicial.
Coleta
Identifique cada alteração no campo 'assignment_group' registrada com data e hora no histórico de auditoria.
Tipo de evento
inferred
|
|||
|
Incidente atribuído a um grupo
|
Esta atividade ocorre quando um incidente é atribuído a um grupo de suporte específico para atendimento. É uma etapa importante do processo de encaminhamento e pode ser identificada pelas alterações no campo do grupo de atribuição. | ||
|
Por que isso importa
Acompanhar as atribuições é essencial para analisar as transferências, o tempo de espera na fila de cada grupo e possíveis ineficiências ou gargalos no encaminhamento.
Onde encontrar
Inferido da tabela 'sys_audit', acompanhando quando o campo 'assignment_group' da tabela 'incident' é preenchido ou alterado.
Coleta
Use a data e hora do registro de auditoria das alterações no campo 'assignment_group'.
Tipo de evento
inferred
|
|||
|
Incidente criado
|
Marca o início do ciclo de vida do incidente, quando um novo incidente é registrado formalmente no ServiceNow. Esse evento é capturado explicitamente usando a data e hora de criação do registro do incidente. | ||
|
Por que isso importa
Este é o principal evento de início do processo. Analisar o tempo entre esta atividade e a resolução é fundamental para medir o tempo total de ciclo e a conformidade com os SLAs.
Onde encontrar
A data e hora de 'sys_created_on' na tabela 'incident' servem como data e hora explícitas do evento para esta atividade.
Coleta
Use a data e hora de 'sys_created_on' do registro do incidente.
Tipo de evento
explicit
|
|||
|
Incidente encerrado
|
Esta é a atividade final do ciclo de vida, indicando que o incidente foi totalmente resolvido e confirmado e que nenhuma outra ação é necessária. O evento é capturado explicitamente pela data e hora de encerramento. | ||
|
Por que isso importa
Como evento final definitivo, esta atividade é essencial para calcular a duração total do ciclo de vida do incidente e analisar o tempo gasto nas etapas posteriores à resolução.
Onde encontrar
A data e hora de 'closed_at' na tabela 'incident' servem como data e hora explícitas do evento. Em geral, esse campo é preenchido quando o campo 'state' muda para 'Closed'.
Coleta
Use a data e hora de 'closed_at' do registro do incidente.
Tipo de evento
explicit
|
|||
|
Resolução proposta
|
Marca o momento em que um agente de suporte implementa uma correção e muda o estado do incidente para 'Resolved'. É um marco importante antes do encerramento final. | ||
|
Por que isso importa
Esta atividade indica o fim do trabalho ativo e o início da etapa de confirmação. O tempo entre ela e 'Incidente encerrado' pode revelar atrasos na confirmação do usuário ou na verificação.
Onde encontrar
Inferido da tabela 'sys_audit' quando o campo 'state' da tabela 'incident' muda para 'Resolved'. A data e hora de 'resolved_at' costuma ser preenchida nesse momento.
Coleta
Use a data e hora em que o campo 'state' passa a ser 'Resolved' ou a data e hora de 'resolved_at'.
Tipo de evento
inferred
|
|||
|
Trabalho iniciado
|
Indica que um agente começou a investigar ou trabalhar ativamente no incidente. Em geral, isso é inferido quando o estado do incidente muda de 'New' ou 'Assigned' para um estado ativo, como 'In Progress'. | ||
|
Por que isso importa
Este marco encerra o tempo inicial na fila e marca o começo do trabalho ativo de resolução. Medir o tempo até o início do trabalho é essencial para a análise de gargalos.
Onde encontrar
Inferido da tabela 'sys_audit', identificando quando o campo 'state' da tabela 'incident' muda para um valor que representa trabalho ativo, como 'In Progress'.
Coleta
Identifique a data e hora em que o campo 'state' muda para 'In Progress' ou um valor semelhante.
Tipo de evento
inferred
|
|||
|
Aguardando confirmação do usuário
|
O incidente está pendente, aguardando que o usuário confirme se a resolução proposta funcionou. Em geral, isso é inferido a partir de um estado específico, como 'Awaiting User Info', após a resolução. | ||
|
Por que isso importa
Este estado pode se tornar um gargalo importante quando os usuários demoram a responder. Medir o tempo nesta atividade ajuda a identificar falhas de comunicação e oportunidades de automatizar o encerramento.
Onde encontrar
Inferido da tabela 'sys_audit', identificando uma mudança para um estado pendente específico após a resolução. O nome do estado pode ser personalizado, como 'Awaiting Caller'.
Coleta
Identifique a data e hora em que 'state' muda para um valor que indique espera por informações do usuário.
Tipo de evento
inferred
|
|||
|
Comentário de suporte adicionado
|
Um agente de suporte adiciona uma nota de trabalho ou um comentário visível para o usuário. Esse evento é registrado explicitamente no fluxo de atividades do incidente. | ||
|
Por que isso importa
Acompanha a comunicação e as atividades de investigação da equipe de suporte. Analisar a frequência e o momento desses comentários oferece insights sobre o processo de investigação.
Onde encontrar
Capturado da tabela 'sys_journal_field', que registra entradas nos campos 'work_notes' e 'comments' da tabela 'incident'.
Coleta
Use a data e hora de criação das entradas do diário cujo elemento seja 'work_notes' ou 'comments'.
Tipo de evento
explicit
|
|||
|
Incidente atribuído a um agente
|
Representa o momento em que um agente específico de um grupo de suporte assume a responsabilidade pelo incidente. Isso pode ser identificado acompanhando as alterações no campo 'assigned_to'. | ||
|
Por que isso importa
Esta informação oferece uma visão detalhada da carga de trabalho dos agentes e da resolução no primeiro contato. Ela ajuda a determinar quanto tempo os incidentes aguardam até que alguém comece a trabalhar neles após a atribuição a um grupo.
Onde encontrar
Inferido da tabela 'sys_audit', acompanhando quando o campo 'assigned_to' da tabela 'incident' é preenchido ou alterado.
Coleta
Use a data e hora do registro de auditoria das alterações no campo 'assigned_to'.
Tipo de evento
inferred
|
|||
|
Incidente categorizado
|
Representa a classificação inicial do incidente, quando campos como Category, Subcategory e Priority são definidos. Em geral, esse evento é inferido do histórico de auditoria quando esses campos são preenchidos pela primeira vez ou atualizados pouco depois da criação. | ||
|
Por que isso importa
Uma categorização precisa é essencial para encaminhar e priorizar corretamente os incidentes. Acompanhar esta atividade ajuda a analisar a frequência de recategorização e seu impacto no tempo de resolução.
Onde encontrar
Inferido da tabela 'sys_audit', identificando a primeira alteração em campos como 'category', 'subcategory' ou 'priority' de um determinado incidente.
Coleta
Identifique a data e hora da primeira atualização dos campos de classificação no registro de auditoria.
Tipo de evento
inferred
|
|||
|
Incidente escalado
|
Ocorre quando a prioridade ou a gravidade de um incidente aumenta, muitas vezes exigindo uma resposta mais rápida ou outros recursos. Isso é inferido pela detecção de um aumento no valor do campo 'priority'. | ||
|
Por que isso importa
Escalonamentos costumam indicar que o incidente é mais grave do que se imaginava ou que está perto de violar um SLA. Analisar esses eventos ajuda a entender as exceções do processo.
Onde encontrar
Inferido da tabela 'sys_audit', identificando uma alteração no campo 'priority' para um valor que indica maior urgência.
Coleta
Detecte quando o valor do campo 'priority' aumenta (por exemplo, de '3 - Moderate' para '2 - High').
Tipo de evento
inferred
|
|||
|
Incidente reaberto
|
Ocorre quando um usuário informa que o problema persiste depois de ter sido marcado como resolvido. Isso é inferido quando o estado do incidente muda de 'Resolved' para um estado ativo, como 'In Progress'. | ||
|
Por que isso importa
Incidentes reabertos indicam que a resolução não funcionou e representam retrabalho. Acompanhar esta atividade é essencial para medir a qualidade da resolução e a taxa de correção na primeira tentativa.
Onde encontrar
Inferido da tabela 'sys_audit', detectando uma mudança no campo 'state' de 'Resolved' para um estado ativo, como 'In Progress' ou 'Assigned'.
Coleta
Identifique a data e hora em que 'state' muda de 'Resolved' para um valor ativo.
Tipo de evento
inferred
|
|||
|
Incidente vinculado a um problema
|
Esta atividade ocorre quando um incidente é associado formalmente a um registro de problema, indicando que faz parte de uma questão mais ampla e subjacente. Ela é inferida quando o campo 'problem_id' do registro do incidente é preenchido. | ||
|
Por que isso importa
Vincular um incidente a um problema é uma etapa importante para passar da correção reativa de incidentes à análise proativa de causa raiz. Isso dá suporte ao Dashboard 'Volume de incidentes recorrentes'.
Onde encontrar
Inferido pela detecção do preenchimento do campo de referência 'problem_id' na tabela 'incident'.
Coleta
Identifique no registro de auditoria a data e hora em que o campo 'problem_id' é preenchido.
Tipo de evento
inferred
|
|||
Guias de extração
Pronto para começar?
Com este Template, você tem tudo o que precisa para iniciar sua jornada de Process Mining no gerenciamento de incidentes. Comece hoje a transformar a resolução de incidentes.
Resolva incidentes mais rápido: aumente a eficiência do ServiceNow agora
Reduza o MTTR em 35% no ServiceNow. Identifique problemas e aumente a satisfação.
Não é necessário informar o cartão de crédito. Comece a otimizar em poucos minutos.