Su Template de datos para la gestión de incidentes

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

Su Template de datos para la gestión de incidentes

Este Template ofrece una guía completa para recopilar los datos necesarios para analizar y optimizar el proceso de gestión de incidentes. Describe los atributos de datos esenciales que debe recopilar, las actividades clave que debe seguir y cómo extraer esta información del sistema de origen. Utilice este recurso para crear un registro de eventos sólido que permita analizar y mejorar el proceso en profundidad.
  • Atributos recomendados para recopilar
  • Actividades clave que conviene seguir
  • Guía para extraer datos de la gestión de problemas en ServiceNow
¿Es nuevo en los registros de eventos? Aprenda a crear un Registro de eventos para Process Mining.

Atributos de gestión de incidentes

Estos son los campos de datos recomendados para incluir en el registro de eventos y analizar de forma exhaustiva el proceso de gestión de incidentes.
5 Obligatorio 4 Recomendado 10 Opcional
Nombre Descripción
Hora del evento
EventTime
Fecha y hora exactas en que ocurrió la actividad.
Descripción

La hora del evento, también conocida 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, suele capturarse 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 realizar cualquier análisis basado en el tiempo. Se utiliza para calcular tiempos de ciclo, tiempos en cola y duraciones entre actividades, datos fundamentales para identificar cuellos de botella, medir el rendimiento respecto a los SLA y comprender la eficiencia del proceso. La precisión de estas marcas de tiempo es clave para que las métricas basadas en la duración sean válidas.

Por qué es importante

Esta marca de tiempo ordena cronológicamente todas las actividades y permite calcular métricas basadas en la duración, 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
Identificador único de cada registro de incidente, que sirve como clave principal para seguir todo su ciclo de vida.
Descripción

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

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

Por qué es importante

Este es el ID del caso esencial que conecta todos los eventos del ciclo de vida de un incidente y permite analizar el proceso de principio a fin.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo number.

Ejemplos
INC0010001INC0010045INC0010239
Nombre de la actividad
ActivityName
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 'Incidente creado', 'Incidente asignado a un agente' o 'Incidente cerrado'. Estos datos suelen derivarse de cambios en campos clave del incidente, como 'State' o 'Assignment Group', o de entradas específicas del registro.

Este Atributo es fundamental para crear el mapa del proceso. Define los nodos del grafo del proceso y permite a quienes analizan los datos visualizar el flujo de incidentes, identificar las rutas más frecuentes, detectar cuellos de botella entre actividades y analizar variantes del proceso. La precisión y el nivel de detalle de los nombres de las actividades influyen directamente en la calidad del análisis.

Por qué es importante

Define los pasos del mapa del proceso, que constituye la base de todos los análisis y visualizaciones de Process Mining.

Dónde obtenerlo

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

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

Este Atributo identifica el origen de los datos del incidente, que en este caso es la gestión de problemas de ServiceNow. Suele ser un valor estático que se añade durante el proceso de extracción y transformación de datos.

En entornos donde se combinan datos de varios sistemas para analizarlos, este campo es fundamental para conocer su procedencia y mantenerlos separados. Ayuda a garantizar que las métricas y los procesos se analicen en el contexto adecuado y permite comparar procesos de distintos sistemas de origen.

Por qué es importante

Aporta contexto esencial sobre el origen de los datos, permite conocer su procedencia y facilita su interpretación correcta en entornos con varios sistemas.

Dónde obtenerlo

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

Ejemplos
Gestión de problemas en ServiceNowServiceNow
Última actualización de datos
LastDataUpdate
Fecha y hora en que 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 más reciente de datos desde ServiceNow. Es un campo de metadatos que indica qué tan actualizados están los datos analizados; no representa un evento del proceso.

Esta información es esencial para saber si el análisis está al día. Indica a los usuarios qué tan recientes son los datos, algo importante para los Dashboards operativos y para tomar decisiones basadas en eventos recientes. También ayuda a establecer expectativas sobre la vigencia y actualidad de los datos.

Por qué es importante

Informa a los usuarios sobre la actualidad de los datos, un aspecto clave para que el análisis sea pertinente y preciso.

Dónde obtenerlo

La herramienta o el proceso de extracción genera y completa esta marca de tiempo al cargar los datos.

Ejemplos
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Asignado a
AssignedTo
Usuario o agente que tiene asignado el incidente en ese momento.
Descripción

Este Atributo identifica al agente de soporte 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, 'Asignado a' ayuda a visualizar la asignación de recursos y a detectar agentes sobrecargados. También se utiliza en el Dashboard de transferencias y reasignaciones para registrar cuántas veces cambia la persona responsable de un incidente, lo que puede indicar ineficiencias o falta de conocimientos. 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 y el rendimiento de los agentes, así como las transferencias entre personas, aspectos clave para comprender la eficiencia en el uso de los recursos.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo assigned_to.

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

El estado del incidente indica su etapa actual, por ejemplo, 'New', 'In Progress', 'On Hold' o 'Resolved'. Los cambios de estado suelen ser la principal fuente para generar actividades en el Registro de eventos de Process Mining.

Analizar el tiempo que el incidente permanece en cada estado es una forma eficaz de identificar cuellos de botella. Por ejemplo, una permanencia 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 del proceso y muestra cómo avanzan los incidentes hacia su resolución.

Por qué es importante

Registra el avance del incidente y es clave para analizar el tiempo que permanece en cada etapa e identificar cuellos de botella en el proceso.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo incident_state o state.

Ejemplos
NuevoEn cursoA la espera de información del usuarioResueltoCerrado
Grupo de asignación
AssignmentGroup
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, desde un servicio de asistencia de Nivel 1 hasta un equipo de redes de Nivel 2.

Este Atributo es esencial para analizar las transferencias entre equipos e identificar cuellos de botella sistémicos. El Dashboard 'Tasa de transferencias y reasignaciones' se basa en gran medida en estos datos para mostrar qué equipos participan con 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.

Por qué es importante

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

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo assignment_group.

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

La prioridad es un campo clave de ServiceNow que determina el orden y la rapidez con que se gestiona un incidente. Suele calcularse a partir del impacto y la urgencia del incidente, y afecta directamente a los objetivos de los SLA.

Este Atributo es fundamental para segmentar los datos y analizar el rendimiento. El Dashboard 'Resumen del cumplimiento de los SLA' utiliza la prioridad para evaluar si los incidentes de alta prioridad se resuelven dentro del tiempo previsto. 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 clave 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 del SLA.
Descripción

Este atributo booleano calculado indica si un incidente incumplió su acuerdo de nivel de servicio. Se obtiene al comparar la marca de tiempo de resolución real con la «Fecha límite del SLA». Si el incidente se resuelve después de la fecha límite, el indicador se establece en verdadero.

Este atributo es la base del Dashboard «Resumen del cumplimiento de los SLA» y de los KPI relacionados. Simplifica el análisis al convertir una comparación de tiempos compleja en una dimensión sencilla de verdadero o falso. Así, resulta fácil filtrar los incidentes que incumplieron el SLA 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 de los SLA y permite filtrar fácilmente los incidentes que no alcanzaron sus objetivos para examinarlos en detalle.

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 verdadero si el estado de un incidente vuelve a ser activo (por ejemplo, «En curso») después de haber alcanzado el estado «Resuelto» o «Cerrado». Por lo general, se identifica buscando la actividad «Incidente reabierto» en el registro de eventos.

Los incidentes reabiertos suelen indicar que la resolución fue incompleta o ineficaz. Analizar estos casos ayuda a detectar cierres prematuros o problemas recurrentes que no se solucionaron correctamente la primera vez. Una tasa elevada de reaperturas puede perjudicar la satisfacción de los usuarios y la productividad del equipo, por lo que es una métrica clave para el control de calidad.

Por qué es importante

Este indicador señala 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 «abierto» aparece después de uno «resuelto».

Ejemplos
truefalse
Categoría
Category
Clasificación general del incidente, por ejemplo, hardware, software o redes.
Descripción

La categoría ofrece una clasificación general de la naturaleza del incidente. A menudo, junto con una subcategoría, ayuda a asignar 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 detectar problemas en la evaluación inicial. Filtrar el mapa del proceso por categoría también puede revelar si ciertos tipos de incidentes siguen rutas de resolución distintas o presentan cuellos de botella específicos.

Por qué es importante

Permite analizar los tipos de incidentes, medir la precisión de la categorización y respaldar 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
Código que indica cómo se resolvió finalmente el incidente.
Descripción

El código de resolución 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 temporal. Por lo general, el agente completa este campo al cerrar el incidente.

Este atributo es compatible directamente con el Dashboard «Eficacia del tipo de resolución». Permite analizar cuántos incidentes se cierran con soluciones permanentes y cuántos con soluciones temporales, un indicador clave de la calidad del servicio y la estabilidad a largo plazo. Una proporción elevada de soluciones temporales puede indicar que no se están abordando adecuadamente los problemas subyacentes.

Por qué es importante

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

Dónde obtenerlo

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

Ejemplos
Resuelto (solución temporal)Resuelto (permanentemente)No resuelto (cancelado por el usuario)Error conocido
Elemento de configuración
ConfigurationItem
Componente, servicio o activo de TI específico afectado por el incidente.
Descripción

El elemento de configuración (CI) es el activo de la base de datos de gestión de la configuración (CMDB) afectado por el incidente. Puede ser un servidor, una aplicación, una computadora portátil o un dispositivo de red.

Analizar los incidentes por CI resulta muy útil para identificar activos o servicios poco fiables. Permite determinar qué componentes de la infraestructura de TI generan más incidentes y orientar las inversiones en actualizaciones o reemplazos. En Process Mining, filtrar por CI puede revelar si los incidentes relacionados con aplicaciones críticas se gestionan de forma distinta o más eficiente que los demás.

Por qué es importante

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

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo cmdb_ci.

Ejemplos
Producción de SAP ERPServidor de base de datos Oracle 05Servicio de correo electrónico
Fecha límite del SLA
SlaDueDate
Fecha y hora límite en 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 para resolver un incidente. 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 «Resumen del cumplimiento de los SLA» y el KPI «Tasa de incumplimiento del SLA en incidentes críticos». Sirve como referencia para comparar el tiempo real de resolución. Analizar los incidentes que se acercan a la fecha límite del SLA puede ayudar a priorizar y escalar los casos de forma proactiva.

Por qué es importante

Define el objetivo de resolución y permite medir el cumplimiento de los SLA e identificar los incidentes que podrían incumplirlo.

Dónde obtenerlo

Este valor suele encontrarse en la tabla task_sla, relacionada con la tabla de incidentes. El campo de marca de tiempo pertinente es planned_end_time.

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

La gravedad indica cuánto afecta un incidente a las operaciones de la empresa. A menudo se utiliza junto con la urgencia para calcular automáticamente la prioridad del incidente.

En el análisis, la gravedad es una dimensión clave del Dashboard «Resumen del cumplimiento de los SLA». Ayuda a las organizaciones a comprobar si cumplen los niveles de servicio en los incidentes más disruptivos. Ofrece una perspectiva centrada en el negocio que complementa la visión operativa que proporciona la prioridad.

Por qué es importante

Mide el impacto empresarial de un incidente y aporta una dimensión esencial para priorizar las iniciativas y analizar el rendimiento ante problemas críticos.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo severity.

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

El Id. del problema vincula un incidente con el registro correspondiente del módulo de gestión de problemas. 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.

Este vínculo es fundamental para el Dashboard «Volumen de incidentes recurrentes» y el KPI «Tasa de incidentes recurrentes». Permite agrupar los incidentes que tienen la misma causa raíz, medir el impacto total de un problema y hacer un seguimiento de la eficacia de las iniciativas para resolverlo. Un número elevado de incidentes vinculados a problemas indica que el equipo de soporte trabaja de forma reactiva.

Por qué es importante

Vincula los incidentes con una causa raíz, algo esencial para analizar los 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
Número de veces que el incidente se ha reasignado a otro grupo o agente.
Descripción

Este campo registra el número total de veces que un incidente se ha transferido entre distintos grupos de asignación. Mide directamente las fricciones del proceso y suele utilizarse como indicador clave del rendimiento.

Este atributo es el principal factor del Dashboard «Tasa de transferencias y reasignaciones» y del KPI «Promedio de transferencias por incidente». Un número elevado de reasignaciones suele indicar problemas como una asignación inicial incorrecta, falta de habilidades en un nivel de soporte o responsabilidades poco claras sobre el proceso. Reducir las reasignaciones es un objetivo habitual de las iniciativas de mejora de procesos, ya que suele acelerar la resolución.

Por qué es importante

Mide directamente las transferencias entre equipos, un indicador clave de ineficiencia, asignaciones incorrectas y oportunidades de mejora.

Dónde obtenerlo

Tabla de incidentes de ServiceNow, campo reassignment_count.

Ejemplos
0135
Persona que reporta
CallerId
Usuario que reportó inicialmente el incidente.
Descripción

La persona que reporta es el usuario final o cliente afectado por el incidente y que lo notificó. Esta información permite saber quién sufre las interrupciones del servicio.

Aunque no siempre es un elemento central del flujo del proceso, analizar los incidentes por persona que los reporta puede revelar si ciertos individuos o departamentos se ven afectados de forma desproporcionada. Esto puede señalar necesidades de formación o problemas localizados en el entorno. También permite contactar directamente con el cliente para realizar encuestas de satisfacción y mantenerlo informado.

Por qué es importante

Identifica al usuario afectado, permite analizar los datos por departamento o persona y aporta contexto para comunicarse con los usuarios.

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 e hitos clave del proceso que conviene registrar para descubrirlo y optimizarlo 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 los cambios posteriores a la asignación inicial en el campo 'assignment_group'.
Por qué es importante

Las reasignaciones frecuentes pueden indicar un enrutamiento inicial incorrecto, complejidad del proceso o falta de conocimientos. Esta actividad es clave para medir el KPI 'Transferencias promedio por incidente'.

Dónde obtenerlo

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

Capturar

Identifique cada cambio, con su fecha y hora, en el campo 'assignment_group' del registro de auditoría.

Tipo de evento inferred
Incidente asignado a un grupo
Esta actividad ocurre cuando se asigna un incidente a un grupo de soporte específico para que lo gestione. 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 en cola de cada grupo y las ineficiencias o los cuellos de botella del enrutamiento.

Dónde obtenerlo

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

Capturar

Utilice la fecha y hora del registro de auditoría correspondiente a los cambios en el campo 'assignment_group'.

Tipo de evento inferred
Incidente cerrado
Esta es la actividad final del ciclo de vida: indica que el incidente está completamente resuelto y confirmado, y que no se necesitan más acciones. El evento se captura explícitamente mediante la fecha y hora de cierre.
Por qué es importante

Como evento de fin definitivo, esta actividad es esencial para calcular la duración total del ciclo de vida del incidente y analizar el tiempo dedicado a las tareas posteriores a la resolución.

Dónde obtenerlo

La fecha y hora 'closed_at' de la tabla 'incident' sirve como marca de tiempo explícita del evento. Normalmente se establece cuando el campo 'state' cambia a 'Closed'.

Capturar

Utilice la fecha y hora 'closed_at' del registro del incidente.

Tipo de evento explicit
Incidente creado
Marca el inicio del ciclo de vida del incidente, cuando se registra formalmente un nuevo incidente en ServiceNow. Este evento se captura de forma explícita mediante la fecha y hora 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 fecha y hora 'sys_created_on' de la tabla 'incident' sirve como marca de tiempo explícita del evento para esta actividad.

Capturar

Utilice la fecha y hora 'sys_created_on' del registro del incidente.

Tipo de evento explicit
Resolución propuesta
Marca el momento en que un agente de soporte aplica una solución y cambia el estado del incidente a 'Resolved'. Es un hito clave antes del cierre definitivo.
Por qué es importante

Esta actividad señala el fin del trabajo activo y el inicio de la fase de confirmación. El tiempo transcurrido hasta 'Incidente cerrado' puede revelar demoras 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, suele completarse la fecha y hora 'resolved_at'.

Capturar

Utilice la fecha y hora en que el campo 'state' pasa a 'Resolved' o el valor de 'resolved_at'.

Tipo de evento inferred
Trabajo iniciado
Indica que un agente ha comenzado a investigar o gestionar activamente el incidente. Suele inferirse 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 fin del tiempo inicial en cola y el comienzo de las tareas activas de resolución. Medir el tiempo que transcurre hasta que empieza el 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 indica que el trabajo está activo, como 'In Progress'.

Capturar

Identifique la fecha y hora en que el campo 'state' cambia a 'In Progress' o a un valor similar.

Tipo de evento inferred
A la espera de la confirmación del usuario
El incidente queda pendiente mientras se espera que el usuario confirme que la solución propuesta funcionó. Suele inferirse 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 que el incidente permanece en esta actividad ayuda a detectar problemas 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, por ejemplo, 'Awaiting Caller'.

Capturar

Identifique la fecha y hora en que el campo 'state' cambia a un valor que indica que se espera información del usuario.

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. Este evento se registra explícitamente en el flujo de actividad del incidente.
Por qué es importante

Registra la comunicación y las tareas de investigación del equipo de soporte. Analizar la frecuencia y el momento de estos comentarios permite conocer mejor 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'.

Capturar

Utilice la fecha y hora de creación de las entradas del diario cuyo elemento sea 'work_notes' o 'comments'.

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

Esta actividad 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 espera un incidente antes de que una persona empiece a trabajar en él, una vez asignado a un grupo.

Dónde obtenerlo

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

Capturar

Utilice la fecha y hora 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 asignan valores a campos como Category, Subcategory y Priority. Este evento suele inferirse del registro de auditoría cuando estos campos se completan por primera vez o se actualizan poco después de la creación.
Por qué es importante

Una categorización precisa es fundamental para asignar y priorizar correctamente los incidentes. El seguimiento de esta actividad ayuda a analizar la frecuencia con que se cambia la categoría y su efecto 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' de un incidente.

Capturar

Identifique la fecha y hora 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 distintos. Se infiere al detectar un aumento en el valor del campo 'priority'.
Por qué es importante

Las escalaciones suelen indicar que el incidente es más grave de lo previsto o que se acerca a un incumplimiento del 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 que indica mayor urgencia.

Capturar

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

Tipo de evento inferred
Incidente reabierto
Ocurre cuando un usuario informa que el problema persiste después de que el incidente se marcó 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 que la resolución no funcionó y que hubo que repetir trabajo. El seguimiento de esta actividad es fundamental para medir la calidad de la resolución y la tasa de solución en el primer intento.

Dónde obtenerlo

Se infiere de la tabla 'sys_audit' al detectar que el campo 'state' cambia de 'Resolved' a un estado activo, como 'In Progress' o 'Assigned'.

Capturar

Identifique la fecha y hora en que 'state' pasa de 'Resolved' a un valor activo.

Tipo de evento inferred
Incidente vinculado a un problema
Esta actividad ocurre cuando se asocia formalmente un incidente 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 clave para pasar de la resolución reactiva de incidentes al análisis proactivo de las causas raíz. Esto permite utilizar el Dashboard 'Volumen de incidentes recurrentes'.

Dónde obtenerlo

Se infiere al detectar que el campo de referencia 'problem_id' de la tabla 'incident' contiene un valor.

Capturar

Identifique en el registro de auditoría la fecha y hora en que se completa el campo 'problem_id'.

Tipo de evento inferred
Recomendado Opcional

Guías de extracción

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

¿Todo listo para comenzar?

Con este Template, tiene todo lo necesario para iniciar el análisis de Process Mining de su proceso de gestión de incidentes. Empiece hoy mismo a transformar la resolución de incidentes.

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

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

Comience su prueba gratuita

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