Seu Template de dados de gerenciamento de incidentes

ServiceNow Problem Management
Seu Template de dados de gerenciamento de incidentes

Seu Template de dados de gerenciamento de incidentes

Este Template oferece um guia completo para coletar os dados necessários à análise e otimização do seu processo de gerenciamento de incidentes. Ele apresenta os atributos essenciais a serem coletados, as principais atividades a serem acompanhadas e orientações práticas para extrair essas informações do seu sistema de origem. Use este recurso para criar um Event Log robusto e realizar uma análise detalhada do processo e das oportunidades de melhoria.
  • Atributos recomendados para coleta
  • Principais atividades a acompanhar
  • Orientações para extração no gerenciamento de problemas do ServiceNow
Novo em Event Logs? Aprenda como criar um Event Log de Process Mining.

Atributos de Gestão de Incidentes

Estes são os campos de dados recomendados para incluir no seu Event Log e realizar uma análise completa do seu processo de gestão de incidentes.
5 Obrigatório 4 Recomendado 10 Opcional
Nome Descrição
Hora do evento
EventTime
O registro de data e hora preciso que indica quando a atividade ocorreu.
Descrição

A hora do evento, geralmente conhecida como timestamp, registra a data e a hora exatas em que uma atividade foi concluída ou uma alteração de status ocorreu. No ServiceNow, isso normalmente é capturado no campo sys_updated_on para cada alteração registrada no histórico de auditoria.

Esse atributo é essencial para ordenar os eventos corretamente e para todas as análises baseadas em tempo. Ele é usado para calcular tempos de ciclo, tempos de espera na fila e durações entre atividades, que são fundamentais para identificar gargalos, medir a performance em relação aos SLAs e entender a eficiência do processo. A precisão desses registros de data e hora é essencial para a validade de qualquer métrica baseada em duração.

Por que isso importa

Esse registro de data e hora ordena todas as atividades cronologicamente e permite calcular todas as métricas baseadas em duração, como tempos de ciclo e gargalos.

Onde obter

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
O identificador exclusivo de cada registro de incidente, usado como chave primária 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 reportado no ServiceNow. Ele funciona como o identificador principal do caso, conectando todas as atividades, atualizações e comunicações relacionadas desde o momento em que o incidente é criado 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 individual, formando a base para descobrir mapas de processo, analisar variantes e calcular durações de ponta a ponta. Sem um ID de incidente exclusivo para cada caso, seria impossível acompanhar a jornada de um incidente ao longo do processo de resolução.

Por que isso importa

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

Onde obter

Tabela de incidentes do ServiceNow, campo number.

Exemplos
INC0010001INC0010045INC0010239
Nome da atividade
ActivityName
O 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 alteração de status no processo de gerenciamento de incidentes, como 'Incident Created', 'Assigned To Agent' ou 'Incident Closed'. Esses dados normalmente são derivados de alterações em campos importantes do incidente, como 'State' ou 'Assignment Group', ou de entradas específicas de registro.

Esse atributo é essencial para criar o mapa de processo. Ele define os nós do grafo do processo, permitindo que os analistas visualizem o fluxo dos incidentes, identifiquem caminhos comuns, descubram gargalos entre atividades e analisem variantes do processo. A granularidade e a precisão desses nomes de atividade afetam diretamente a qualidade da análise do processo.

Por que isso importa

Ele define as etapas do mapa de processo, que é a base de toda análise e visualização de Process Mining.

Onde obter

Este é um atributo derivado, normalmente 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
O sistema do qual estes dados foram extraídos.
Descrição

Este atributo identifica a origem dos dados de incidentes, que neste caso é o ServiceNow Problem Management. Normalmente, é um valor estático adicionado durante o processo de extração e transformação dos dados.

Em ambientes onde dados de vários sistemas podem ser combinados para análise, esse campo é essencial para a linhagem e a segregação dos dados. Ele ajuda a garantir que as métricas e os processos sejam analisados no contexto correto e permite que os analistas comparem processos entre diferentes sistemas de origem.

Por que isso importa

Ele oferece um contexto essencial sobre a origem dos dados, garantindo a linhagem dos dados e permitindo uma interpretação correta em ambientes com vários sistemas.

Onde obter

Normalmente, este é um valor estático adicionado durante o processo de extração dos dados.

Exemplos
ServiceNow Problem ManagementServiceNow
Última atualização dos dados
LastDataUpdate
O registro de data e hora que indica 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 no ServiceNow. É um campo de metadados que reflete a atualidade dos dados analisados, não um evento do processo em si.

Essas informações são essenciais para entender a atualidade da análise. Elas mostram aos usuários quão recentes são os dados, algo importante para Dashboards operacionais e decisões baseadas em eventos recentes. Também ajudam a alinhar as expectativas sobre a relevância e a atualidade dos dados.

Por que isso importa

Ele informa aos usuários quão recentes são os dados, algo essencial para a relevância e a precisão da análise.

Onde obter

Esse registro de data e hora é gerado e preenchido pela ferramenta ou pelo processo de extração de dados no momento da carga dos dados.

Exemplos
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Atribuído a
AssignedTo
O usuário ou agente atualmente responsável por trabalhar no incidente.
Descrição

Este atributo identifica o agente de suporte específico responsável pelo incidente em determinado momento. Essas informações são essenciais para entender a distribuição da carga de trabalho, a performance dos agentes e as transferências entre pessoas.

Na análise, 'Assigned To' ajuda a visualizar a alocação de recursos e identificar agentes sobrecarregados. Ele também é usado no Dashboard Handoff and Reassignment para acompanhar quantas vezes um incidente muda de responsável individual, o que pode indicar ineficiência ou lacunas de conhecimento. Analisar os tempos de resolução por agente também pode destacar os profissionais de 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 individuais dos agentes, aspectos essenciais para entender a eficiência dos recursos.

Onde obter

Tabela de incidentes do ServiceNow, campo assigned_to.

Exemplos
Beth AnglinDavid LooHoward Johnson
Estado do incidente
IncidentState
O status atual do incidente em seu ciclo de vida.
Descrição

O estado do incidente indica a etapa atual do incidente, como 'New', 'In Progress', 'On Hold' ou 'Resolved'. As alterações de estado geralmente são a principal fonte para gerar atividades no Event Log usado no Process Mining.

Analisar o tempo gasto em cada estado é uma forma poderosa de identificar gargalos. Por exemplo, uma longa permanência no estado 'On Hold' pode indicar dependências de fatores externos ou de usuários. A sequência de alterações de estado também forma a base do mapa de processo, mostrando como os incidentes avançam até a resolução.

Por que isso importa

Ele acompanha o progresso do incidente e é essencial para analisar o tempo gasto em diferentes etapas e identificar gargalos no processo.

Onde obter

Tabela de incidentes do ServiceNow, campo incident_state ou state.

Exemplos
NovoEm andamentoAguardando informações do usuárioResolvidoFechado
Grupo de atribuição
AssignmentGroup
A equipe ou o grupo de suporte responsável por tratar o incidente.
Descrição

O grupo de atribuição representa a equipe de agentes encarregada de resolver o incidente. Os incidentes geralmente são roteados entre diferentes grupos, como de uma central de suporte de Nível 1 para uma equipe especializada de redes de Nível 2.

Esse atributo é essencial para analisar transferências entre equipes e identificar gargalos sistêmicos. O Dashboard Handoff and Reassignment Rate depende fortemente desses dados para mostrar quais equipes participam com frequência das transferências. Ele também permite comparar a performance entre diferentes grupos de suporte e entender onde está a expertise de resolução dentro da organização.

Por que isso importa

Ele acompanha qual equipe é responsável, permitindo analisar a performance, a carga de trabalho e as transferências entre grupos.

Onde obter

Tabela de incidentes do ServiceNow, campo assignment_group.

Exemplos
Central de ServiçosSuporte de redeAdministradores de banco de dados
Prioridade
Priority
O nível de prioridade do incidente, que determina a urgência necessária para a resposta.
Descrição

Priority é um campo importante do ServiceNow que determina a ordem e a velocidade do tratamento de um incidente. Normalmente, é derivado do impacto e da urgência do incidente e influencia diretamente as metas de SLA.

Esse atributo é fundamental para a segmentação e a análise de performance. O Dashboard SLA Compliance Overview usa Priority para avaliar se os incidentes de alta prioridade estão sendo resolvidos dentro dos tempos definidos. Analisar os tempos de ciclo por prioridade ajuda a confirmar se os incidentes críticos estão realmente sendo processados mais rapidamente que os menos importantes. É uma dimensão essencial para praticamente 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 SLAs e alocar recursos.

Onde obter

Tabela de incidentes do ServiceNow, campo priority.

Exemplos
1 - Crítico2 - Alto3 - Moderado4 - Baixo
Categoria
Category
A classificação de alto nível do incidente, como Hardware, Software ou Rede.
Descrição

Category oferece uma classificação ampla da natureza do incidente. Geralmente combinada com uma subcategoria, ela ajuda a encaminhar o incidente para a equipe de suporte correta e é usada em relatórios e análises de tendências.

No Process Mining, esse atributo é essencial para os Dashboards Incident Categorization Accuracy e Recurring Incident Volume. Ao analisar incidentes cuja categoria foi alterada durante o processo, as organizações podem identificar problemas na triagem inicial. Filtrar o mapa de 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, ajuda a medir a precisão da categorização e é essencial para o roteamento e a análise de tendências.

Onde obter

Tabela de incidentes do ServiceNow, campo category.

Exemplos
HardwareSoftwareRedeBanco de dados
Código de resolução
ResolutionCode
Um código que indica como o incidente foi resolvido.
Descrição

Resolution Code especifica a natureza da solução aplicada, por exemplo, se o problema foi resolvido pelo usuário, por um erro conhecido ou com a aplicação de uma solução alternativa. Normalmente, esse campo é preenchido pelo agente ao encerrar o incidente.

Esse atributo dá suporte direto ao Dashboard Resolution Type Effectiveness. Ele permite analisar quantos incidentes foram encerrados com correções permanentes em comparação com soluções alternativas temporárias, um indicador importante da qualidade e da estabilidade do serviço no longo prazo. Uma taxa alta de soluções alternativas pode sugerir que os problemas subjacentes não estão sendo tratados adequadamente.

Por que isso importa

Ele esclarece o método de resolução, permitindo analisar correções permanentes em comparação com soluções alternativas temporárias e dando suporte à análise da causa-raiz.

Onde obter

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
O número de vezes que o incidente foi reatribuído a um grupo ou agente diferente.
Descrição

Este campo acompanha o número total de vezes que um incidente foi transferido entre diferentes grupos de atribuição. É uma medida direta da fricção do processo e costuma ser usado como um indicador-chave de performance.

Esse atributo é o principal componente do Dashboard Handoff and Reassignment Rate e do KPI Average Handoffs per Incident. Uma contagem alta de reatribuições geralmente indica problemas como roteamento inicial incorreto, falta de habilidades em um nível de suporte ou ausência de clareza sobre a responsabilidade pelo processo. Reduzir essa contagem é um objetivo comum das iniciativas de melhoria de processos, pois normalmente resulta em tempos de resolução menores.

Por que isso importa

Ele mede diretamente as transferências do processo, um indicador importante de ineficiência, roteamento incorreto e oportunidades de melhoria.

Onde obter

Tabela de incidentes do ServiceNow, campo reassignment_count.

Exemplos
0135
Data de vencimento do SLA
SlaDueDate
A data e a hora limite em que o incidente deve ser resolvido de acordo com o SLA.
Descrição

A data de vencimento do SLA é um timestamp calculado que representa o prazo para resolver um incidente. Essa data é determinada pelo Service Level Agreement (SLA) associado às características do incidente, como a prioridade.

Esse atributo é essencial para o Dashboard “SLA Compliance Overview” e para o KPI “Critical Incident SLA Breach Rate”. Ele serve como referência para comparar o tempo real de resolução. Analisar os incidentes que estão próximos da data de vencimento do SLA ajuda a fazer escalonamentos e priorizações de forma proativa.

Por que isso importa

Ele define a meta de resolução, permitindo medir a conformidade com o SLA e identificar incidentes com risco de ultrapassar os prazos.

Onde obter

Esse valor geralmente é encontrado na tabela task_sla, relacionada à tabela incident. O campo planned_end_time é o timestamp relevante.

Exemplos
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
Foi reaberto
IsReopened
Um indicador que mostra se um incidente foi reaberto depois de ser resolvido.
Descrição

Este indicador booleano é definido como true quando o estado de um incidente volta a ser ativo, como “In Progress”, depois de ter alcançado anteriormente o estado “Resolved” ou “Closed”. Normalmente, isso é identificado procurando a atividade “Incident Reopened” no Event Log.

Incidentes reabertos são um forte indicador de resoluções incompletas ou ineficazes. Analisar esses casos ajuda a identificar encerramentos prematuros ou problemas recorrentes que não foram corrigidos adequadamente na primeira tentativa. Uma alta taxa de reabertura pode prejudicar a satisfação dos usuários e a produtividade da equipe, tornando essa uma métrica importante para o controle de qualidade.

Por que isso importa

Este indicador identifica falhas no processo de resolução, destacando os incidentes que exigiram trabalho adicional depois de serem considerados resolvidos.

Onde obter

Calculado verificando a sequência de atividades de cada incidente para identificar se um estado “open” ocorre depois de um estado “resolved”.

Exemplos
truefalse
ID do problema
ProblemId
O identificador do registro de Problem associado, caso o incidente esteja vinculado a um problema maior.
Descrição

O ID do problema vincula um incidente ao registro correspondente no módulo Problem Management. Isso é feito quando se identifica que um incidente é sintoma de um problema maior e subjacente que afeta vários usuários ou serviços.

Essa vinculação é essencial para o Dashboard Recurring Incident Volume e para o KPI Recurring Incident Rate. Ela permite que os analistas agrupem incidentes originados pela mesma causa-raiz, meçam o impacto total de um problema e acompanhem a eficácia dos esforços de resolução de problemas. Um número alto de incidentes vinculados a problemas indica um ambiente de suporte reativo.

Por que isso importa

Ele vincula os incidentes à causa-raiz, algo essencial para analisar problemas recorrentes e medir o impacto do gerenciamento de problemas.

Onde obter

Tabela de incidentes do ServiceNow, campo problem_id.

Exemplos
PRB0040001PRB0040015PRB0040102
Item de configuração
ConfigurationItem
O componente de TI, serviço ou ativo específico afetado pelo incidente.
Descrição

O Configuration Item (CI) é o ativo do Configuration Management Database (CMDB) afetado pelo incidente. Pode ser um servidor, aplicativo, laptop ou dispositivo de rede.

Analisar incidentes por CI é extremamente útil para identificar ativos ou serviços pouco confiáveis. Isso ajuda a apontar quais partes da infraestrutura de TI geram mais incidentes, orientando 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 que os demais.

Por que isso importa

Ele identifica o ativo afetado, ajudando a localizar componentes problemáticos na infraestrutura de TI e a direcionar os esforços de melhoria.

Onde obter

Tabela de incidentes do ServiceNow, campo cmdb_ci.

Exemplos
SAP ERP de produçãoServidor Oracle DB 05Serviço de e-mail
O SLA foi violado
IsSlaBreached
Um indicador que mostra se a resolução do incidente ultrapassou a data de vencimento do SLA.
Descrição

Este é um atributo booleano calculado que indica se os incidentes violaram o Service Level Agreement. Ele é obtido comparando o timestamp real de resolução com a “Data de vencimento do SLA”. Se o incidente for resolvido depois da data de vencimento, o indicador será definido como true.

Esse atributo é a base do Dashboard “SLA Compliance Overview” e dos KPIs relacionados. Ele simplifica a análise ao transformar uma comparação complexa de tempo em uma dimensão simples de verdadeiro/falso. Assim, fica fácil filtrar todos os incidentes que violaram o SLA e analisar suas características em comum, como categoria, grupo de atribuição ou prioridade.

Por que isso importa

Ele simplifica a análise da conformidade com o SLA, permitindo filtrar facilmente e analisar em profundidade todos os incidentes que não atingiram suas metas.

Onde obter

Calculado comparando o timestamp “Resolved At” com o timestamp “SlaDueDate”. (Resolved At > SlaDueDate).

Exemplos
truefalse
Severidade
Severity
O nível de impacto do incidente para o negócio.
Descrição

Severity define o impacto de um incidente nas operações do negócio. Junto com a urgência, ela costuma ser usada para calcular automaticamente a prioridade do incidente.

Na análise, a severidade é uma dimensão importante para o Dashboard SLA Compliance Overview. Ela ajuda as organizações a entender se estão cumprindo os níveis de serviço para os incidentes mais disruptivos. Também oferece uma visão de performance orientada ao negócio, complementando a visão operacional fornecida pela prioridade.

Por que isso importa

Ela mede o impacto de um incidente para o negócio, oferecendo uma dimensão essencial para priorizar esforços e analisar a performance em problemas críticos.

Onde obter

Tabela de incidentes do ServiceNow, campo severity.

Exemplos
1 - Alto2 - Médio3 - Baixo
Solicitante
CallerId
O usuário que relatou o incidente inicialmente.
Descrição

O solicitante identifica o usuário final ou cliente afetado pelo incidente e responsável por relatá-lo. Essas informações mostram quem está sendo impactado pelas interrupções do serviço.

Embora nem sempre seja central para o fluxo do processo, analisar os incidentes por solicitante pode revelar se determinadas pessoas ou departamentos são afetados de forma desproporcional pelos problemas. Isso pode indicar necessidades de treinamento ou problemas ambientais localizados. Também cria uma conexão direta com o cliente para pesquisas de satisfação e comunicação.

Por que isso importa

Ele identifica o usuário afetado, permitindo analisar os dados por departamento ou pessoa e oferecendo contexto para a comunicação com o usuário.

Onde obter

Tabela de incidentes do ServiceNow, campo caller_id.

Exemplos
Abel TuterCarolina PashDon Goodliffe
Obrigatório Recomendado Opcional

Atividades de Gestão de Incidentes

Estas são as principais etapas e marcos do processo que você deve registrar no seu Event Log para realizar uma descoberta precisa do processo e otimizar as operações.
6 Recomendado 7 Opcional
Atividade Descrição
Grupo de atribuição alterado
Representa uma transferência em que um incidente passa de um grupo de suporte para outro. Isso é capturado observando alterações posteriores no campo 'assignment_group' após seu preenchimento inicial.
Por que isso importa

Reatribuições frequentes podem indicar roteamento inicial incorreto, complexidade do processo ou lacunas de conhecimento. Essa atividade é essencial para medir o KPI 'Average Handoffs per Incident'.

Onde obter

Inferido a partir da tabela 'sys_audit', acompanhando qualquer alteração no campo 'assignment_group' após a atribuição inicial.

Captura

Identifique cada alteração com registro de data e hora no campo 'assignment_group' do registro de auditoria.

Tipo de evento inferred
Incidente atribuído a um grupo
Essa atividade ocorre quando um incidente é atribuído a um grupo de suporte específico para tratamento. É uma etapa importante do processo de roteamento e é capturada observando as alterações no campo de grupo de atribuição.
Por que isso importa

Acompanhar as atribuições é essencial para analisar transferências, tempos de espera na fila de cada grupo e ineficiências ou gargalos no roteamento.

Onde obter

Inferido a partir da tabela 'sys_audit', acompanhando quando o campo 'assignment_group' da tabela 'incident' é preenchido ou alterado.

Captura

Use o registro de data e hora do registro de auditoria referente às 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 o registro de 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 essa atividade e a resolução é fundamental para medir o tempo total do ciclo e a conformidade com o SLA.

Onde obter

O registro de data e hora 'sys_created_on' na tabela 'incident' funciona como o registro explícito do evento para essa atividade.

Captura

Use o registro de data e hora '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, sem necessidade de novas ações. O evento é capturado explicitamente por meio do registro de data e hora do encerramento.
Por que isso importa

Como evento definitivo de fim, essa atividade é essencial para calcular a duração total do ciclo de vida do incidente e analisar o tempo gasto no processamento após a resolução.

Onde obter

O registro de data e hora 'closed_at' na tabela 'incident' funciona como o registro explícito do evento. Normalmente, ele é definido quando o campo 'state' muda para 'Closed'.

Captura

Use o registro de data e hora 'closed_at' do registro do incidente.

Tipo de evento explicit
Resolução proposta
Marca o momento em que um agente de suporte implementou uma correção e mudou o incidente para o estado 'Resolved'. É um marco importante antes do encerramento final.
Por que isso importa

Essa atividade sinaliza o fim do trabalho ativo e o início da fase de confirmação. O tempo entre essa atividade e 'Incident Closed' pode revelar atrasos na confirmação do usuário ou na verificação.

Onde obter

Inferido a partir da tabela 'sys_audit', quando o campo 'state' da tabela 'incident' muda para 'Resolved'. O registro de data e hora 'resolved_at' geralmente é preenchido nesse momento.

Captura

Use o registro de data e hora em que o campo 'state' se torna 'Resolved' ou o registro 'resolved_at'.

Tipo de evento inferred
Trabalho iniciado
Indica que um agente começou a investigar ativamente ou a trabalhar no incidente. Normalmente, isso é inferido quando o estado do incidente muda de 'New' ou 'Assigned' para um estado ativo, como 'In Progress'.
Por que isso importa

Esse marco marca o fim do tempo inicial na fila e o início dos esforços ativos de resolução. Medir o tempo até o início do trabalho é essencial para analisar gargalos.

Onde obter

Inferido a partir da tabela 'sys_audit', identificando quando o campo 'state' da tabela 'incident' muda para um valor que representa trabalho ativo, como 'In Progress'.

Captura

Identifique o registro de 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 foi bem-sucedida. Normalmente, isso é inferido a partir de um estado específico, como 'Awaiting User Info', após a resolução.
Por que isso importa

Esse estado pode se tornar um gargalo significativo se os usuários demorarem a responder. Medir o tempo gasto nessa atividade ajuda a identificar falhas de comunicação e oportunidades para automatizar o encerramento.

Onde obter

Inferido a partir da tabela 'sys_audit', identificando uma alteração para um estado pendente específico após a resolução. O nome do estado pode ser personalizado, como 'Awaiting Caller'.

Captura

Identifique o registro de 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 é um evento explícito registrado no fluxo de atividades do incidente.
Por que isso importa

Acompanha a comunicação e os esforços de investigação da equipe de suporte. Analisar a frequência e o momento desses comentários oferece um insight sobre o processo de investigação.

Onde obter

Capturado a partir da tabela 'sys_journal_field', que registra entradas nos campos 'work_notes' e 'comments' da tabela 'incident'.

Captura

Use o registro de data e hora de criação das entradas de 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 é capturado monitorando as alterações no campo 'assigned_to'.
Por que isso importa

Isso oferece uma visão detalhada da carga de trabalho dos agentes e da resolução no primeiro contato. Também ajuda a determinar quanto tempo os incidentes aguardam até que uma pessoa comece a trabalhar neles depois da atribuição a um grupo.

Onde obter

Inferido a partir da tabela 'sys_audit', acompanhando quando o campo 'assigned_to' da tabela 'incident' é preenchido ou alterado.

Captura

Use o registro de data e hora do registro de auditoria referente às 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. Esse evento normalmente é inferido a partir 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

A categorização precisa é essencial para o roteamento e a priorização corretos. Acompanhar essa atividade ajuda a analisar as taxas de recategorização e seu impacto no tempo de resolução.

Onde obter

Inferido a partir da tabela 'sys_audit', identificando a primeira alteração em campos como 'category', 'subcategory' ou 'priority' para um determinado incidente.

Captura

Identifique o registro de 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 severidade de um incidente aumenta, geralmente exigindo uma resposta mais rápida ou recursos diferentes. Isso é inferido pela detecção de um aumento no valor do campo 'priority'.
Por que isso importa

Escalonamentos geralmente indicam que um incidente é mais grave do que se imaginava inicialmente ou está se aproximando de uma violação de SLA. Analisar esses eventos ajuda a entender as exceções do processo.

Onde obter

Inferido a partir da tabela 'sys_audit', identificando uma alteração no campo 'priority' para um valor de maior urgência.

Captura

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' novamente para um estado ativo, como 'In Progress'.
Por que isso importa

Incidentes reabertos indicam resoluções malsucedidas e representam retrabalho. Acompanhar essa atividade é essencial para medir a qualidade da resolução e as taxas de correção na primeira tentativa.

Onde obter

Inferido a partir da tabela 'sys_audit', detectando uma transição do campo 'state' de 'Resolved' de volta para um estado ativo, como 'In Progress' ou 'Assigned'.

Captura

Identifique o registro de data e hora em que 'state' muda de 'Resolved' para um valor ativo.

Tipo de evento inferred
Incidente vinculado a um problema
Essa atividade ocorre quando um incidente é associado formalmente a um registro de problema, indicando que ele faz parte de uma questão maior e subjacente. Isso é inferido quando o campo 'problem_id' do registro do incidente é preenchido.
Por que isso importa

Vincular um incidente a um problema é uma etapa essencial para passar da correção reativa de incidentes à análise proativa da causa-raiz. Isso dá suporte ao Dashboard 'Recurring Incident Volume'.

Onde obter

Inferido pela detecção de quando o campo de referência 'problem_id' da tabela 'incident' é preenchido com um valor.

Captura

Identifique no registro de auditoria o registro de data e hora em que o campo 'problem_id' foi preenchido.

Tipo de evento inferred
Recomendado Opcional

Guias de extração

Como obter seus dados do gerenciamento de problemas no ServiceNow

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 dos seus incidentes.

Resolva incidentes mais rápido: aumente agora a eficiência do ServiceNow

Reduza o MTTR em 35% no ServiceNow. Identifique problemas e aumente a satisfação.

Começar o teste grátis

Não é necessário cartão de crédito. Comece a otimizar em poucos minutos.