Su Template de datos para la gestión de incidentes

Gestión de problemas de ServiceNow
Su Template de datos para la gestión de incidentes

Su Template de datos para la gestión de incidentes

Esta plantilla ofrece una guía completa para recopilar los datos necesarios para analizar y optimizar su proceso de gestión de incidentes. Describe los atributos de datos esenciales que debe recopilar, las actividades clave que debe supervisar y recomendaciones prácticas para extraer esta información de su sistema de origen. Utilice este recurso para crear un registro de eventos sólido que permita realizar un análisis y una mejora exhaustivos del proceso.
  • Atributos recomendados para recopilar
  • Actividades clave que debe supervisar
  • Guía de extracción para la gestión de problemas en ServiceNow
¿Es nuevo en los registros de eventos? Aprenda a crear un registro de eventos de Process Mining.

Atributos de la gestión de incidentes

Estos son los campos de datos recomendados que debe incluir en su registro de eventos para realizar un análisis completo de su proceso de gestión de incidentes.
5 Obligatorio 4 Recomendado 10 Opcional
Nombre Descripción
Hora del evento
EventTime
La marca de tiempo precisa que indica cuándo ocurrió la actividad.
Descripción

La hora del evento, conocida a menudo como marca de tiempo, registra la fecha y hora exactas en que se completó una actividad o se produjo un cambio de estado. En ServiceNow, normalmente se captura en el campo sys_updated_on para cada cambio registrado en el historial de auditoría.

Este atributo es esencial para ordenar correctamente los eventos y para todos los análisis basados en el tiempo. Se utiliza para calcular tiempos de ciclo, tiempos de espera en cola y duraciones entre actividades, elementos fundamentales para identificar cuellos de botella, medir el rendimiento frente a los SLA y comprender la eficiencia del proceso. La precisión de estas marcas de tiempo es decisiva para la validez de cualquier métrica basada en duraciones.

Por qué es importante

Esta marca de tiempo ordena cronológicamente todas las actividades y permite calcular todas las métricas basadas en duraciones, como los tiempos de ciclo y los cuellos de botella.

Dónde obtenerlo

Tabla sys_audit de ServiceNow, campo sys_created_on o campo sys_updated_on de la tabla incident para el último estado.

Ejemplos
2023-04-15T10:05:21Z2023-04-15T11:22:00Z2023-04-16T09:00:30Z
ID del incidente
IncidentId
El identificador único de cada registro de incidente, que sirve como clave principal para realizar el seguimiento de todo su ciclo de vida.
Descripción

El ID del incidente es el número de referencia único asignado a cada incidente notificado en ServiceNow. Actúa como identificador principal del caso y vincula todas las actividades, actualizaciones y comunicaciones relacionadas desde el momento en que se crea el incidente hasta su cierre.

En el análisis de Process Mining, este ID es fundamental. Permite a la herramienta unir la secuencia de eventos de cada caso individual, lo que constituye la base para descubrir mapas de procesos, analizar variantes y calcular duraciones de principio a fin. Sin un ID de incidente único para cada caso, sería imposible seguir el recorrido de un incidente durante el proceso de resolución.

Por qué es importante

Este es el ID de caso esencial que conecta todos los eventos del ciclo de vida de un incidente y hace posible el análisis del proceso de principio a fin.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, número de campo.

Ejemplos
INC0010001INC0010045INC0010239
Nombre de la actividad
ActivityName
El nombre del evento o la tarea específicos que ocurrieron en un momento determinado del ciclo de vida del incidente.
Descripción

El nombre de la actividad describe un paso específico o un cambio de estado en el proceso de gestión de incidentes, como 'Incident Created', 'Assigned To Agent' o 'Incident Closed'. Por lo general, estos datos se derivan de cambios en campos clave del incidente, como 'State' o 'Assignment Group', o de entradas de registro específicas.

Este atributo es fundamental para crear el mapa de procesos. Define los nodos del grafo del proceso y permite a los analistas visualizar el flujo de los incidentes, identificar rutas habituales, descubrir cuellos de botella entre actividades y analizar variantes del proceso. El nivel de detalle y la precisión de los nombres de las actividades influyen directamente en la calidad del análisis del proceso.

Por qué es importante

Define los pasos del mapa de procesos, que constituye la base de todo análisis y visualización de Process Mining.

Dónde obtenerlo

Es un atributo derivado que normalmente genera la lógica de transformación de datos a partir de cambios en campos como state, assignment_group y assigned_to en las tablas sys_audit o incident.

Ejemplos
Incidente creadoGrupo de asignación cambiadoResolución propuestaIncidente cerrado
Sistema de origen
SourceSystem
El sistema del que se extrajeron estos datos.
Descripción

Este atributo identifica el origen de los datos de los incidentes, que en este caso es ServiceNow Problem Management. Normalmente es un valor estático que se añade durante el proceso de extracción y transformación de datos.

En entornos donde pueden combinarse datos de varios sistemas para su análisis, este campo es fundamental para la trazabilidad y la segregación de los datos. Ayuda a garantizar que las métricas y los procesos se analicen en el contexto correcto y permite a los analistas comparar procesos entre distintos sistemas de origen.

Por qué es importante

Aporta un contexto esencial sobre el origen de los datos, garantiza su trazabilidad y permite interpretarlos correctamente en entornos con varios sistemas.

Dónde obtenerlo

Normalmente es un valor estático que se añade durante el proceso de extracción de datos.

Ejemplos
Gestión de problemas de ServiceNowServiceNow
Última actualización de datos
LastDataUpdate
La marca de tiempo que indica cuándo se actualizaron por última vez los datos de este registro desde el sistema de origen.
Descripción

Este atributo registra la fecha y hora de la extracción o actualización de datos más reciente desde ServiceNow. Es un campo de metadatos que refleja la actualización de los datos analizados, no un evento del proceso en sí.

Esta información es esencial para comprender la actualidad del análisis. Indica qué tan recientes son los datos, algo importante para los Dashboards operativos y para tomar decisiones basadas en eventos recientes. Ayuda a gestionar las expectativas sobre la relevancia y actualidad de los datos.

Por qué es importante

Informa a los usuarios sobre la actualidad de los datos, un aspecto fundamental para la relevancia y precisión del análisis.

Dónde obtenerlo

Esta marca de tiempo la genera y completa la herramienta o el proceso de extracción de datos durante la carga de datos.

Ejemplos
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Asignado a
AssignedTo
El usuario o agente al que se ha asignado actualmente el trabajo sobre el incidente.
Descripción

Este atributo identifica al agente de soporte específico responsable del incidente en un momento determinado. Esta información es fundamental para comprender la distribución de la carga de trabajo, el rendimiento de los agentes y las transferencias entre personas.

En el análisis, 'Assigned To' ayuda a visualizar la asignación de recursos e identificar a los agentes sobrecargados. También se utiliza en el Dashboard de transferencias y reasignaciones para realizar el seguimiento de cuántas veces cambia el responsable individual de un incidente, lo que puede indicar ineficiencias o carencias de conocimiento. Analizar los tiempos de resolución por agente también puede destacar a quienes obtienen mejores resultados o necesitan formación adicional.

Por qué es importante

Permite analizar la carga de trabajo, el rendimiento y las transferencias individuales de los agentes, aspectos clave para comprender la eficiencia de los recursos.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo assigned_to.

Ejemplos
Beth AnglinDavid LooHoward Johnson
Estado del incidente
IncidentState
El estado actual del incidente dentro de su ciclo de vida.
Descripción

Incident State indica la etapa actual del incidente, como 'New', 'In Progress', 'On Hold' o 'Resolved'. Los cambios de estado suelen ser la fuente principal para generar actividades en el registro de eventos de Process Mining.

Analizar el tiempo dedicado a cada estado es una forma eficaz de identificar cuellos de botella. Por ejemplo, una duración prolongada en el estado 'On Hold' podría indicar dependencias de factores externos o de los usuarios. La secuencia de cambios de estado también constituye la base del mapa de procesos y muestra cómo avanzan los incidentes hacia la resolución.

Por qué es importante

Realiza el seguimiento del progreso del incidente y es clave para analizar el tiempo dedicado a las distintas etapas e identificar cuellos de botella en el proceso.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo incident_state o state.

Ejemplos
NuevoEn cursoEsperando información del usuarioResueltoCerrado
Grupo de asignación
AssignmentGroup
El equipo o grupo de soporte responsable de gestionar el incidente.
Descripción

El grupo de asignación representa al equipo de agentes encargado de resolver el incidente. A menudo, los incidentes se enrutan entre distintos grupos, por ejemplo, de un centro de soporte de nivel 1 a un equipo especializado de redes de nivel 2.

Este atributo es esencial para analizar las transferencias entre equipos e identificar cuellos de botella sistémicos. El Dashboard de tasa de transferencias y reasignaciones depende en gran medida de estos datos para mostrar qué equipos participan con mayor frecuencia en las transferencias. También permite comparar el rendimiento de distintos grupos de soporte y comprender dónde se concentra la experiencia necesaria para resolver los incidentes dentro de la organización.

Por qué es importante

Registra qué equipo es responsable y permite analizar el rendimiento, la carga de trabajo y las transferencias entre grupos.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo assignment_group.

Ejemplos
Mesa de ayudaSoporte de redAdministradores de bases de datos
Prioridad
Priority
El nivel de prioridad del incidente, que determina la urgencia necesaria de la respuesta.
Descripción

La Prioridad es un campo clave de ServiceNow que determina el orden y la rapidez con que se gestiona un incidente. Normalmente se deriva del impacto y la urgencia del incidente e influye directamente en los objetivos del SLA.

Este atributo es fundamental para la segmentación y el análisis del rendimiento. El Dashboard «Resumen del cumplimiento del SLA» utiliza Prioridad para evaluar si los incidentes de alta prioridad se resuelven dentro de los tiempos objetivo. Analizar los tiempos de ciclo por prioridad ayuda a confirmar que los incidentes críticos se procesan más rápido que los menos importantes. Es una dimensión fundamental para casi todos los KPI y Dashboards.

Por qué es importante

Permite segmentar los incidentes según su importancia para el negocio, algo fundamental para supervisar el cumplimiento de los SLA y asignar recursos.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo priority.

Ejemplos
1 - Crítico2 - Alto3 - Moderado4 - Bajo
¿Se incumplió el SLA?
IsSlaBreached
Indicador que señala si la resolución del incidente superó la fecha límite de su SLA.
Descripción

Este es un atributo booleano calculado que indica si los incidentes incumplieron su Acuerdo de Nivel de Servicio. Se obtiene comparando la marca de tiempo real de resolución con la «Fecha límite del SLA». Si el tiempo de resolución es posterior a la fecha límite, el indicador se establece en true.

Este atributo constituye la base del Dashboard «SLA Compliance Overview» y de los KPI relacionados. Simplifica el análisis al convertir una comparación temporal compleja en una dimensión sencilla de verdadero/falso. Así resulta fácil filtrar todos los incidentes incumplidos y analizar sus características comunes, como la categoría, el grupo de asignación o la prioridad.

Por qué es importante

Simplifica el análisis del cumplimiento del SLA y permite filtrar fácilmente y analizar en profundidad todos los incidentes que no cumplieron sus objetivos.

Dónde obtenerlo

Se calcula comparando la marca de tiempo «Resolved At» con la marca de tiempo «SlaDueDate». (Resolved At > SlaDueDate).

Ejemplos
truefalse
¿Se reabrió?
IsReopened
Indicador que señala si un incidente se reabrió después de resolverse.
Descripción

Este indicador booleano se establece en true si el estado de un incidente vuelve a uno activo, por ejemplo, «In Progress», después de haber alcanzado anteriormente el estado «Resolved» o «Closed». Normalmente se identifica buscando una actividad «Incident Reopened» en el registro de eventos.

Los incidentes reabiertos son un indicador claro de resoluciones incompletas o ineficaces. Analizar estos casos ayuda a identificar cierres prematuros o problemas recurrentes que no se solucionaron correctamente la primera vez. Una tasa elevada de reapertura puede afectar negativamente a la satisfacción de las personas usuarias y a la productividad del equipo, por lo que constituye una métrica clave para el control de calidad.

Por qué es importante

Este indicador identifica fallos en el proceso de resolución y destaca los incidentes que requirieron trabajo adicional después de considerarse resueltos.

Dónde obtenerlo

Se calcula comprobando la secuencia de actividades de cada incidente para determinar si un estado «open» aparece después de un estado «resolved».

Ejemplos
truefalse
Categoría
Category
La clasificación general del incidente, como Hardware, Software o Network.
Descripción

La Categoría proporciona una clasificación general de la naturaleza de un incidente. A menudo, junto con una subcategoría, ayuda a dirigir el incidente al equipo de soporte adecuado y se utiliza para elaborar informes y analizar tendencias.

En Process Mining, este atributo es fundamental para los Dashboards «Precisión de la categorización de incidentes» y «Volumen de incidentes recurrentes». Al analizar los incidentes cuya categoría cambia durante el proceso, las organizaciones pueden identificar problemas en la clasificación inicial. Filtrar el mapa de procesos por categoría también puede revelar si determinados tipos de incidentes siguen rutas de resolución diferentes o experimentan cuellos de botella específicos.

Por qué es importante

Permite analizar los tipos de incidentes, ayuda a medir la precisión de la categorización y es esencial para el enrutamiento y el análisis de tendencias.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo category.

Ejemplos
HardwareSoftwareRedBase de datos
Código de resolución
ResolutionCode
Un código que indica cómo se resolvió finalmente el incidente.
Descripción

Resolution Code especifica la naturaleza de la solución aplicada, por ejemplo, si el usuario resolvió el incidente, si se solucionó mediante un error conocido o si se proporcionó una solución alternativa. Normalmente, el agente completa este campo al cerrar el incidente.

Este atributo respalda directamente el Dashboard 'Resolution Type Effectiveness'. Permite analizar cuántos incidentes se cierran con soluciones permanentes frente a soluciones alternativas temporales, un indicador clave de la calidad del servicio y la estabilidad a largo plazo. Una tasa elevada de soluciones alternativas puede sugerir que los problemas subyacentes no se están abordando adecuadamente.

Por qué es importante

Aclara el método de resolución, permite analizar las soluciones permanentes frente a las alternativas temporales y respalda el análisis de causas raíz.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo close_code o un campo personalizado de código de resolución.

Ejemplos
Resuelto (solución alternativa)Resuelto (de forma permanente)No resuelto (cancelado por el usuario)Error conocido
Elemento de configuración
ConfigurationItem
El componente de TI, servicio o activo específico afectado por el incidente.
Descripción

El Configuration Item (CI) es el activo de la Configuration Management Database (CMDB) afectado por el incidente. Puede ser un servidor, una aplicación, un portátil o un dispositivo de red.

Analizar los incidentes por CI es muy útil para identificar activos o servicios poco fiables. Ayuda a localizar qué partes de la infraestructura de TI generan más incidentes, lo que puede orientar las inversiones en actualizaciones o sustituciones. En Process Mining, filtrar por CI puede revelar si los incidentes relacionados con aplicaciones críticas se gestionan de forma diferente o más eficiente que otros.

Por qué es importante

Identifica el activo afectado, ayuda a localizar componentes problemáticos de la infraestructura de TI y permite centrar los esfuerzos de mejora.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo cmdb_ci.

Ejemplos
SAP ERP ProductionOracle DB Server 05Servicio de correo electrónico
Fecha límite del SLA
SlaDueDate
La fecha y hora límite en la que se espera resolver el incidente según su SLA.
Descripción

La fecha límite del SLA es una marca de tiempo calculada que representa el plazo de resolución de un incidente. Esta fecha se determina según el Acuerdo de Nivel de Servicio (SLA) asociado a las características del incidente, como su prioridad.

Este atributo es esencial para el Dashboard «SLA Compliance Overview» y el KPI «Critical Incident SLA Breach Rate». Sirve como referencia para comparar el tiempo real de resolución. Analizar los incidentes que se acercan a su fecha límite del SLA puede ayudar a realizar escalaciones y establecer prioridades de forma proactiva.

Por qué es importante

Define el objetivo de resolución, lo que permite medir el cumplimiento del SLA e identificar los incidentes que corren el riesgo de incumplir sus objetivos.

Dónde obtenerlo

Este valor suele encontrarse en la tabla task_sla, relacionada con la tabla incident. El campo planned_end_time contiene la marca de tiempo relevante.

Ejemplos
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
Gravedad
Severity
El nivel de impacto empresarial causado por el incidente.
Descripción

Severity define cuánto afecta un incidente a las operaciones del negocio. Junto con la urgencia, suele utilizarse para calcular automáticamente la prioridad del incidente.

En el análisis, la gravedad es una dimensión clave para el Dashboard 'SLA Compliance Overview'. Ayuda a las organizaciones a comprender si cumplen los niveles de servicio en los incidentes más disruptivos. Ofrece una visión del rendimiento centrada en el negocio que complementa la visión operativa proporcionada por la prioridad.

Por qué es importante

Mide el impacto empresarial de un incidente y proporciona una dimensión esencial para priorizar esfuerzos y analizar el rendimiento en problemas críticos.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo severity.

Ejemplos
1 - Alta2 - Media3 - Baja
ID del problema
ProblemId
El identificador del registro de Problem asociado, si el incidente está vinculado a un problema de mayor alcance.
Descripción

Problem ID vincula un incidente con el registro correspondiente del módulo Problem Management. Esto se hace cuando se identifica que un incidente es un síntoma de un problema subyacente de mayor alcance que afecta a varios usuarios o servicios.

Esta vinculación es fundamental para el Dashboard 'Recurring Incident Volume' y el KPI 'Recurring Incident Rate'. Permite a los analistas agrupar los incidentes que proceden de la misma causa raíz, medir el impacto total de un problema y realizar el seguimiento de la eficacia de las actividades de resolución de problemas. Un número elevado de incidentes vinculados a problemas indica un entorno de soporte reactivo.

Por qué es importante

Vincula los incidentes con una causa raíz, algo esencial para analizar problemas recurrentes y medir el impacto de la gestión de problemas.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo problem_id.

Ejemplos
PRB0040001PRB0040015PRB0040102
Número de reasignaciones
ReassignmentCount
El número de veces que el incidente se ha reasignado a un grupo o agente diferente.
Descripción

Este campo registra el número total de veces que un incidente se ha transferido entre distintos grupos de asignación. Es una medida directa de la fricción del proceso y suele utilizarse como indicador clave de rendimiento.

Este atributo es el principal impulsor del Dashboard de tasa de transferencias y reasignaciones y del KPI 'Average Handoffs per Incident'. Un número elevado de reasignaciones suele indicar problemas como un enrutamiento inicial incorrecto, falta de competencias en un nivel de soporte o una responsabilidad poco clara sobre el proceso. Reducir este número es un objetivo habitual de las iniciativas de mejora de procesos, ya que normalmente conduce a tiempos de resolución más cortos.

Por qué es importante

Mide directamente las transferencias del proceso, un indicador clave de ineficiencia, enrutamiento incorrecto y oportunidades de mejora.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo reassignment_count.

Ejemplos
0135
Persona solicitante
CallerId
La persona usuaria que notificó inicialmente el incidente.
Descripción

Caller identifica a la persona usuaria final o al cliente afectado por el incidente que lo notificó. Esta información aporta contexto sobre quién está sufriendo las interrupciones del servicio.

Aunque no siempre es un elemento central del flujo del proceso, analizar los incidentes por persona solicitante puede revelar si determinadas personas o departamentos se ven afectados de forma desproporcionada por ciertos problemas. Esto puede señalar necesidades de capacitación o problemas ambientales localizados. También proporciona un vínculo directo con el cliente para realizar encuestas de satisfacción y mantener la comunicación.

Por qué es importante

Identifica a la persona usuaria afectada, lo que permite analizar los incidentes por departamento o persona y aporta contexto para la comunicación con las personas usuarias.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo caller_id.

Ejemplos
Abel TuterCarolina PashDon Goodliffe
Obligatorio Recomendado Opcional

Actividades de gestión de incidentes

Estos son los pasos clave y los hitos del proceso que debe capturar en su registro de eventos para descubrir y optimizar el proceso con precisión.
6 Recomendado 7 Opcional
Actividad Descripción
Grupo de asignación cambiado
Representa una transferencia en la que un incidente pasa de un grupo de soporte a otro. Se captura observando cambios posteriores en el campo 'assignment_group' después de su asignación inicial.
Por qué es importante

Las reasignaciones frecuentes pueden indicar un enrutamiento inicial incorrecto, complejidad del proceso o carencias de conocimiento. Esta actividad es fundamental para medir el KPI 'Average Handoffs per Incident'.

Dónde obtenerlo

Se infiere de la tabla 'sys_audit' al realizar el seguimiento de cualquier cambio en el campo 'assignment_group' después de la asignación inicial.

Recopilar

Identifique cada cambio con marca de tiempo en el campo 'assignment_group' dentro del registro de auditoría.

Tipo de evento inferred
Incidente asignado a un grupo
Esta actividad ocurre cuando un incidente se asigna a un grupo de soporte específico para su gestión. Es un paso clave del proceso de enrutamiento y se captura observando los cambios en el campo del grupo de asignación.
Por qué es importante

El seguimiento de las asignaciones es esencial para analizar las transferencias, los tiempos de espera en la cola de cada grupo e identificar ineficiencias de enrutamiento o cuellos de botella.

Dónde obtenerlo

Se infiere de la tabla 'sys_audit' al realizar el seguimiento de cuándo se completa o cambia el campo 'assignment_group' de la tabla 'incident'.

Recopilar

Utilice la marca de tiempo del registro de auditoría correspondiente a los cambios en el campo 'assignment_group'.

Tipo de evento inferred
Incidente cerrado
Es la actividad final del ciclo de vida e indica que el incidente se ha resuelto y confirmado por completo, y que no se necesita ninguna otra acción. El evento se captura explícitamente mediante la marca de tiempo de cierre.
Por qué es importante

Como evento final definitivo, esta actividad es esencial para calcular la duración total del ciclo de vida del incidente y analizar el tiempo dedicado al procesamiento posterior a la resolución.

Dónde obtenerlo

La marca de tiempo 'closed_at' de la tabla 'incident' sirve como marca de tiempo explícita del evento. Por lo general, se establece cuando el campo 'state' cambia a 'Closed'.

Recopilar

Utilice la marca de tiempo 'closed_at' del registro del incidente.

Tipo de evento explicit
Incidente creado
Marca el inicio del ciclo de vida del incidente, cuando un nuevo incidente se registra formalmente en ServiceNow. Este evento se captura explícitamente mediante la marca de tiempo de creación del registro del incidente.
Por qué es importante

Este es el evento de inicio principal del proceso. Analizar el tiempo transcurrido desde esta actividad hasta la resolución es fundamental para medir el tiempo total del ciclo y el cumplimiento de los SLA.

Dónde obtenerlo

La marca de tiempo 'sys_created_on' de la tabla 'incident' sirve como marca de tiempo explícita del evento para esta actividad.

Recopilar

Utilice la marca de tiempo 'sys_created_on' del registro del incidente.

Tipo de evento explicit
Resolución propuesta
Marca el momento en que un agente de soporte ha implementado una solución y ha cambiado el incidente al estado 'Resolved'. Es un hito clave previo al cierre definitivo.
Por qué es importante

Esta actividad señala el final del trabajo activo y el inicio de la fase de confirmación. El tiempo transcurrido entre este evento e 'Incident Closed' puede revelar retrasos en la confirmación o verificación por parte del usuario.

Dónde obtenerlo

Se infiere de la tabla 'sys_audit' cuando el campo 'state' de la tabla 'incident' cambia a 'Resolved'. En ese momento, a menudo se completa la marca de tiempo 'resolved_at'.

Recopilar

Utilice la marca de tiempo en la que el campo 'state' pasa a ser 'Resolved' o la marca de tiempo 'resolved_at'.

Tipo de evento inferred
Trabajo iniciado
Indica que un agente ha comenzado a investigar activamente el incidente o a trabajar en él. Por lo general, se infiere cuando el estado del incidente cambia de 'New' o 'Assigned' a un estado activo como 'In Progress'.
Por qué es importante

Este hito marca el final del tiempo inicial en cola y el comienzo de las actividades de resolución. Medir el tiempo hasta el inicio del trabajo es clave para analizar los cuellos de botella.

Dónde obtenerlo

Se infiere de la tabla 'sys_audit' al identificar cuándo el campo 'state' de la tabla 'incident' cambia a un valor que representa trabajo activo, como 'In Progress'.

Recopilar

Identifique la marca de tiempo en la que el campo 'state' cambia a 'In Progress' o a un valor similar.

Tipo de evento inferred
Comentario de soporte añadido
Un agente de soporte añade una nota de trabajo o un comentario visible para el usuario. Es un evento explícito registrado en el flujo de actividad del incidente.
Por qué es importante

Realiza el seguimiento de la comunicación y las actividades de investigación del equipo de soporte. Analizar la frecuencia y el momento de estos comentarios ofrece información sobre el proceso de investigación.

Dónde obtenerlo

Se captura de la tabla 'sys_journal_field', que registra las entradas de los campos 'work_notes' y 'comments' de la tabla 'incident'.

Recopilar

Utilice la marca de tiempo de creación de las entradas del diario cuyo elemento sea 'work_notes' o 'comments'.

Tipo de evento explicit
Esperando la confirmación del usuario
El incidente se encuentra en estado pendiente, a la espera de que el usuario confirme que la resolución propuesta ha sido satisfactoria. Por lo general, se infiere a partir de un estado específico como 'Awaiting User Info' después de la resolución.
Por qué es importante

Este estado puede convertirse en un cuello de botella importante si los usuarios tardan en responder. Medir el tiempo dedicado a esta actividad ayuda a identificar brechas de comunicación y oportunidades para automatizar el cierre.

Dónde obtenerlo

Se infiere de la tabla 'sys_audit' al identificar un cambio a un estado pendiente específico después de la resolución. El nombre del estado puede ser personalizado, como 'Awaiting Caller'.

Recopilar

Identifique la marca de tiempo en la que 'state' cambia a un valor que indique que se espera información del usuario.

Tipo de evento inferred
Incidente asignado a un agente
Representa el momento en que un agente específico de un grupo de soporte asume la responsabilidad del incidente. Se captura mediante el seguimiento de los cambios en el campo 'assigned_to'.
Por qué es importante

Ofrece una visión detallada de la carga de trabajo de los agentes y de la resolución en el primer contacto. Ayuda a determinar cuánto tiempo esperan los incidentes antes de que una persona comience a trabajar en ellos tras su asignación a un grupo.

Dónde obtenerlo

Se infiere de la tabla 'sys_audit' al realizar el seguimiento de cuándo se completa o cambia el campo 'assigned_to' de la tabla 'incident'.

Recopilar

Utilice la marca de tiempo del registro de auditoría correspondiente a los cambios en el campo 'assigned_to'.

Tipo de evento inferred
Incidente categorizado
Representa la clasificación inicial del incidente, en la que se establecen campos como Category, Subcategory y Priority. Por lo general, este evento se infiere del registro de auditoría cuando estos campos se completan o actualizan por primera vez poco después de la creación.
Por qué es importante

Una categorización precisa es fundamental para realizar un enrutamiento y una priorización correctos. El seguimiento de esta actividad ayuda a analizar las tasas de recategorización y su impacto en el tiempo de resolución.

Dónde obtenerlo

Se infiere de la tabla 'sys_audit' al identificar el primer cambio en campos como 'category', 'subcategory' o 'priority' para un incidente determinado.

Recopilar

Identifique la marca de tiempo de la primera actualización de los campos de clasificación en el registro de auditoría.

Tipo de evento inferred
Incidente escalado
Ocurre cuando aumenta la prioridad o la gravedad de un incidente, lo que suele requerir una respuesta más rápida o recursos diferentes. Se infiere al detectar un aumento en el valor del campo 'priority'.
Por qué es importante

Las escalaciones suelen indicar que un incidente es más grave de lo que se pensaba inicialmente o que se aproxima a un incumplimiento de los SLA. Analizar estos eventos ayuda a comprender las excepciones del proceso.

Dónde obtenerlo

Se infiere de la tabla 'sys_audit' al identificar un cambio en el campo 'priority' a un valor de mayor urgencia.

Recopilar

Detecte cuándo aumenta el valor del campo 'priority' (por ejemplo, de '3 - Moderate' a '2 - High').

Tipo de evento inferred
Incidente reabierto
Ocurre cuando un usuario informa de que el problema persiste después de que se haya marcado como resuelto. Se infiere cuando el estado del incidente pasa de 'Resolved' a un estado activo como 'In Progress'.
Por qué es importante

Los incidentes reabiertos indican resoluciones fallidas y representan retrabajo. El seguimiento de esta actividad es esencial para medir la calidad de la resolución y las tasas de solución en el primer intento.

Dónde obtenerlo

Se infiere de la tabla 'sys_audit' al detectar una transición del campo 'state' de 'Resolved' a un estado activo como 'In Progress' o 'Assigned'.

Recopilar

Identifique la marca de tiempo en la que 'state' pasa de 'Resolved' a un valor activo.

Tipo de evento inferred
Incidente vinculado a un problema
Esta actividad ocurre cuando un incidente se asocia formalmente con un registro de problema, lo que indica que forma parte de un problema subyacente de mayor alcance. Se infiere cuando se completa el campo 'problem_id' del registro del incidente.
Por qué es importante

Vincular un incidente a un problema es un paso fundamental para pasar de la resolución reactiva de incidentes al análisis proactivo de causas raíz. Además, respalda el Dashboard 'Recurring Incident Volume'.

Dónde obtenerlo

Se infiere al detectar cuándo el campo de referencia 'problem_id' de la tabla 'incident' se completa con un valor.

Recopilar

Identifique en el registro de auditoría la marca de tiempo en la que se completa el campo 'problem_id'.

Tipo de evento inferred
Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de la gestión de problemas en ServiceNow

¿Listo para comenzar?

Con esta plantilla, tiene todo lo necesario para iniciar su recorrido de Process Mining en la gestión de incidentes. Empiece hoy mismo a transformar la resolución de sus incidentes.

Resuelva los incidentes más rápido: aumente ahora la eficiencia de ServiceNow

Reduzca el MTTR un 35 % en ServiceNow. Identifique los problemas y aumente la satisfacción.

Inicie su prueba gratuita

No necesita tarjeta de crédito. Empiece a optimizar en cuestión de minutos.