Plantilla de Datos: Gestión de Incidentes

Gestión de Problemas de ServiceNow
Plantilla de Datos: Gestión de Incidentes

Su Plantilla de Datos para la Gestión de Incidentes

Esta plantilla proporciona 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 a recopilar, las actividades clave a rastrear y una orientación práctica sobre cómo extraer esta información de su sistema de origen. Utilice este recurso para construir un registro de eventos robusto para un análisis de procesos en profundidad y su mejora.
  • Atributos recomendados para recopilar
  • Actividades clave para el seguimiento
  • Guía de extracción para ServiceNow Problem Management
¿Nuevo en registros de eventos? Aprenda cómo crear un registro de eventos para Process Mining.

Atributos de Gestión de Incidentes

Estos son los campos de datos recomendados para incluir en su Registro de eventos para un análisis exhaustivo de su proceso de gestión de incidentes.
5 Requerido 4 Recomendado 11 Opcional
Nombre Descripción
Hora del Evento
EventTime
La marca de tiempo precisa que indica cuándo ocurrió la actividad.
Descripción

Event Time, conocido a menudo como el timestamp, registra la fecha y hora exactas en que se completó una actividad o se produjo un cambio de estado. En ServiceNow, esto se captura típicamente en el campo sys_updated_on para cada cambio registrado en el registro de auditoría.

Este atributo es esencial para secuenciar los eventos correctamente y para todo análisis basado en el tiempo. Se utiliza para calcular los tiempos de ciclo, los tiempos en cola y las duraciones entre actividades, que son fundamentales para identificar cuellos de botella, medir el rendimiento frente a los SLA y comprender la eficiencia del proceso. La precisión de estos timestamps es crítica para la validez de cualquier métrica basada en la duración.

Por qué es importante

Esta marca de tiempo ordena todas las actividades cronológicamente y permite el cálculo de todas las métricas basadas en duración, como los tiempos de ciclo y los cuellos de botella.

Dónde obtener

Tabla sys_audit de ServiceNow, campo sys_created_on o el campo sys_updated_on de la tabla incident para el estado más reciente.

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

El Incident ID es el número de referencia único asignado a cada incidente reportado en ServiceNow. Actúa como el identificador de caso central que vincula todas las actividades, actualizaciones y comunicaciones relacionadas desde el momento en que se crea un incidente hasta que se cierra.

En el análisis de Process Mining, este ID es fundamental. Permite a la herramienta reconstruir la secuencia de eventos para cada caso individual, formando la base para descubrir mapas de procesos, analizar variantes y calcular duraciones de principio a fin. Sin un Incident ID único para cada caso, sería imposible rastrear el recorrido de un incidente a través del proceso de resolución.

Por qué es importante

Este es el ID de Caso esencial que conecta todos los eventos en el ciclo de vida de un incidente, haciendo posible el análisis de procesos de principio a fin.

Dónde obtener

Tabla incident de ServiceNow, campo number.

Ejemplos
INC0010001INC0010045INC0010239
Nombre de la Actividad
ActivityName
El nombre del evento o tarea específica que ocurrió en un momento dado dentro del ciclo de vida del incidente.
Descripción

El Nombre de la Actividad describe un paso o cambio de estado específico en el proceso de gestión de incidentes, como 'Incidente Creado', 'Asignado a Agente' o 'Incidente Cerrado'. Estos datos suelen derivarse de cambios en campos clave de incidentes, como State o Assignment Group, o de entradas de registro específicas.

Este atributo es crucial para construir el mapa de procesos. Define los nodos en el grafo de procesos, permitiendo a los analistas visualizar el flujo de incidentes, identificar rutas comunes, descubrir cuellos de botella entre actividades y analizar variantes de proceso. La granularidad y precisión de estos nombres de actividad impactan directamente la calidad del análisis de procesos.

Por qué es importante

Define los pasos en el mapa de procesos, que es la base para todo análisis y visualización de Process Mining.

Dónde obtener

Este es un atributo derivado, generalmente generado por la lógica de transformación de datos basada en 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
Source System
SourceSystem
El sistema del cual se extrajeron estos datos.
Descripción

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

En entornos donde los datos de múltiples sistemas podrían combinarse para su análisis, este campo es fundamental para la trazabilidad de los datos y su segregación. Ayuda a asegurar que las métricas y los procesos se analicen dentro del contexto correcto y permite a los analistas comparar procesos entre diferentes sistemas de origen.

Por qué es importante

Proporciona un contexto crucial sobre el origen de los datos, asegurando la trazabilidad de los datos y permitiendo una correcta interpretación en entornos multisistema.

Dónde obtener

Este es típicamente un valor estático agregado durante el proceso de extracción de datos.

Ejemplos
Gestión de Problemas de ServiceNowServiceNow
Última actualización de datos
LastDataUpdate
El timestamp 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 más reciente de los datos de ServiceNow. Es un campo de metadatos que refleja la actualidad de los datos que se están analizando, no un evento en el proceso en sí.

Esta información es vital para comprender la puntualidad del análisis. Informa a los usuarios sobre la actualidad de los datos, lo cual es importante para los dashboards operativos y para la toma de decisiones basada en eventos recientes. Ayuda a gestionar las expectativas sobre la relevancia y la actualidad de los datos.

Por qué es importante

Informa a los usuarios sobre la actualidad de los datos, lo cual es crítico para la relevancia y precisión del análisis.

Dónde obtener

Esta marca de tiempo es generada y establecida por la herramienta o el proceso de extracción de datos en el momento de la carga de datos.

Ejemplos
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Asignado a
AssignedTo
El usuario o agente individual actualmente asignado para trabajar en el incidente.
Descripción

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

En el análisis, 'Assigned To' ayuda a visualizar la asignación de recursos y a identificar agentes sobrecargados. También se utiliza en el dashboard de Handoff y Reasignación para rastrear cuántas veces un incidente cambia de propietario individual, lo cual puede ser un indicador de ineficiencia o lagunas de conocimiento. Analizar los tiempos de resolución por agente también puede destacar a los de mejor rendimiento o a aquellos que necesitan capacitación adicional.

Por qué es importante

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

Dónde obtener

Tabla incident de ServiceNow, campo assigned_to.

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

El Incident State indica la etapa actual del incidente, como 'Nuevo', 'En Progreso', 'En Espera' o 'Resuelto'. Los cambios de estado son a menudo la fuente principal para generar actividades en el Registro de eventos para el Process Mining.

Analizar el tiempo invertido en cada estado es una forma potente de identificar cuellos de botella. Por ejemplo, una larga duración en el estado 'En Espera' podría indicar dependencias de factores externos o usuarios. La secuencia de cambios de estado también forma la base del mapa de procesos, mostrando cómo los incidentes progresan hacia la resolución.

Por qué es importante

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

Dónde obtener

Tabla incident de ServiceNow, campo incident_state o state.

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

El Assignment Group representa al equipo de agentes encargado de resolver el incidente. Los incidentes a menudo se dirigen entre diferentes grupos, como desde una mesa de ayuda de Nivel 1 a un equipo de red especializado de Nivel 2.

Este atributo es esencial para analizar los traspasos entre equipos e identificar cuellos de botella sistémicos. El dashboard 'Handoff and Reassignment Rate' se basa en gran medida en estos datos para mostrar qué equipos están frecuentemente involucrados en transferencias. También permite realizar comparaciones de rendimiento entre diferentes grupos de soporte y ayuda a comprender dónde reside la experiencia en resolución dentro de la organización.

Por qué es importante

Esto rastrea qué equipo es responsable, permitiendo el análisis del rendimiento del equipo, la carga de trabajo y las transferencias entre grupos.

Dónde obtener

Tabla incident de ServiceNow, campo assignment_group.

Ejemplos
Service DeskSoporte de RedAdministradores de bases de datos
Prioridad
Priority
El nivel de prioridad del incidente, que dicta la urgencia de respuesta requerida.
Descripción

La Prioridad es un campo clave en ServiceNow que determina el orden y la velocidad de gestión de un incidente. Generalmente se deriva del impacto y la urgencia del incidente, e influye directamente en los objetivos de SLA.

Este atributo es fundamental para la segmentación y el análisis de rendimiento. El dashboard 'SLA Compliance Overview' utiliza la Prioridad para evaluar si los incidentes de alta prioridad se resuelven dentro de sus plazos 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 crítica para prácticamente todos los KPI y dashboard.

Por qué es importante

Permite segmentar incidentes por importancia para el negocio, lo cual es crítico para la monitorización del cumplimiento de SLA y la asignación de recursos.

Dónde obtener

Tabla incident de ServiceNow, campo priority.

Ejemplos
1 - Crítico2 - Alta3 - Moderada4 - Baja
¿Se incumplió el SLA?
IsSlaBreached
Un indicador que señala si la resolución del incidente excedió su fecha límite de SLA.
Descripción

Este es un atributo booleano calculado que marca los incidentes que han incumplido su Acuerdo de Nivel de Servicio (SLA). Se deriva al comparar la marca de tiempo de resolución real con la 'Fecha de Vencimiento de SLA'. Si el tiempo de resolución es posterior a la fecha de vencimiento, la bandera se establece en 'verdadero'.

Este atributo es la base para el dashboard de 'Visión general del Cumplimiento del SLA' y los KPI relacionados. Simplifica el análisis al convertir una compleja comparación de tiempo en una dimensión simple de verdadero/falso, facilitando el filtrado de todos los incidentes incumplidos y el análisis de sus características comunes, como la categoría, el grupo de asignación o la prioridad.

Por qué es importante

Simplifica el análisis de cumplimiento de SLA, permitiendo un filtrado fácil y un análisis en profundidad de todos los incidentes que no cumplieron sus objetivos.

Dónde obtener

Calculado comparando el timestamp 'Resolved At' con el timestamp 'SlaDueDate'. (Resolved At > SlaDueDate).

Ejemplos
truefalse
¿Se reabrió?
IsReopened
Un indicador que señala si un incidente fue reabierto después de ser resuelto.
Descripción

Esta bandera booleana se establece en 'verdadero' si el estado de un incidente se cambió de nuevo a uno activo (por ejemplo, 'En Progreso') después de haber alcanzado previamente un estado de 'Resuelto' o 'Cerrado'. Esto se identifica típicamente buscando una actividad 'Incidente Reabierto' en el registro de eventos.

Los incidentes reabiertos son un fuerte indicador 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 alta tasa de reapertura puede impactar negativamente la satisfacción del usuario y la productividad del equipo, convirtiéndola en una métrica clave para el control de calidad.

Por qué es importante

Esta bandera identifica fallos en el proceso de resolución, destacando los incidentes que requirieron trabajo adicional después de ser considerados resueltos.

Dónde obtener

Calculado al verificar la secuencia de actividades para cada incidente para ver si un estado 'abierto' sigue a un estado 'resuelto'.

Ejemplos
truefalse
Categoría
Category
La clasificación de alto nivel del incidente, como Hardware, Software o Red.
Descripción

La Category proporciona una clasificación amplia de la naturaleza de un incidente. Esto, a menudo en combinación con una subcategoría, ayuda a enrutar el incidente al equipo de soporte correcto y se utiliza para informes y análisis de tendencias.

Para el Process Mining, este atributo es crucial para los dashboards 'Incident Categorization Accuracy' y 'Recurring Incident Volume'. Al analizar incidentes donde la Category se cambia a mitad de proceso, las organizaciones pueden identificar problemas con el triaje inicial. Filtrar el mapa de procesos por Category también puede revelar si ciertos tipos de incidentes siguen diferentes rutas de resolución o experimentan cuellos de botella únicos.

Por qué es importante

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

Dónde obtener

Tabla incident 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

El Resolution Code especifica la naturaleza de la solución aplicada; por ejemplo, si fue resuelto por un usuario, por un error conocido, o si se proporcionó una solución alternativa. Este campo suele ser rellenado por el agente al cerrar el incidente.

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

Por qué es importante

Aclara el método de resolución, permitiendo el análisis de soluciones permanentes frente a soluciones provisionales, y apoyando el análisis de causa raíz.

Dónde obtener

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

Ejemplos
Resuelto (Solución Temporal)Resuelto (Permanentemente)No Resuelto (Cancelado por el Usuario)Error Conocido
Conteo de Reasignaciones
ReassignmentCount
El número de veces que el incidente ha sido reasignado a un grupo o agente diferente.
Descripción

Este campo rastrea el número total de veces que un incidente ha sido transferido entre diferentes grupos de asignación. Es una medida directa de la fricción del proceso y a menudo se utiliza como un indicador clave de rendimiento.

Este atributo es el principal impulsor de para el dashboard de 'Tasa de Transferencia y Reasignación' y el KPI de 'Transferencias Promedio por Incidente'. Un alto número de reasignaciones a menudo indica problemas como un enrutamiento inicial incorrecto, falta de habilidades en un nivel de soporte o una propiedad del proceso poco clara. Reducir este número es un objetivo común para las iniciativas de mejora de procesos, ya que típicamente conduce a tiempos de resolución más rápidos.

Por qué es importante

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

Dónde obtener

Tabla incident de ServiceNow, campo reassignment_count.

Ejemplos
0135
Elemento de Configuración
ConfigurationItem
El componente de TI específico, servicio o activo afectado por el incidente.
Descripción

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

Analizar incidentes por CI es extremadamente valioso para identificar activos o servicios poco fiables. Ayuda a determinar qué partes de la infraestructura de TI están generando la mayoría de los incidentes, lo que puede guiar la inversión en actualizaciones o reemplazos. En el Process Mining, filtrar por CI puede revelar si los incidentes relacionados con aplicaciones críticas se gestionan de manera diferente o más eficiente que otros.

Por qué es importante

Identifica el activo afectado, ayudando a localizar componentes problemáticos en la infraestructura de TI y enfocando los esfuerzos de mejora.

Dónde obtener

Tabla incident de ServiceNow, campo cmdb_ci.

Ejemplos
SAP ERP ProductionServidor de BD Oracle 05Servicio de Correo Electrónico
Fecha de Vencimiento de SLA
SlaDueDate
La fecha y hora objetivo para la resolución esperada del incidente según su SLA.
Descripción

El SLA Due Date es una marca de tiempo calculada que representa la fecha límite de resolución para un incidente. Esta fecha se determina por el Service Level Agreement (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 la referencia contra la cual se compara el tiempo real de resolución. Analizar los incidentes que están cerca de su SLA Due Date puede ayudar con la escalada proactiva y la priorización.

Por qué es importante

Define el objetivo de resolución, haciendo posible medir el cumplimiento del SLA e identificar incidentes en riesgo de incumplir sus objetivos.

Dónde obtener

Este valor se encuentra típicamente en la tabla task_sla, que está relacionada con la tabla incident. El campo planned_end_time es la marca de tiempo relevante.

Ejemplos
2023-05-20T17:00:00Z2023-06-01T09:00:00Z
ID del Problema
ProblemId
El identificador del registro de Problema asociado si el incidente está vinculado a un problema mayor.
Descripción

El Problem ID vincula un incidente con un registro correspondiente en el módulo de Gestión de Problemas. Esto se hace cuando un incidente se identifica como un síntoma de un problema subyacente más grande que afecta a múltiples usuarios o servicios.

Esta vinculación es crítica para el dashboard 'Recurring Incident Volume' y el KPI 'Recurring Incident Rate'. Permite a los analistas agrupar incidentes que provienen de la misma causa raíz, medir el impacto completo de un problema y rastrear la efectividad de los esfuerzos de resolución de problemas. Un alto número de incidentes vinculados a problemas indica un entorno de soporte reactivo.

Por qué es importante

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

Dónde obtener

Tabla incident de ServiceNow, campo problem_id.

Ejemplos
PRB0040001PRB0040015PRB0040102
Severidad
Severity
El nivel de impacto en el negocio causado por el incidente.
Descripción

La Severidad define cuánto un incidente está impactando las operaciones comerciales. Junto con la urgencia, a menudo se utiliza para calcular automáticamente la prioridad del incidente.

En el análisis, la severidad es una dimensión clave para el dashboard 'SLA Compliance Overview'. Ayuda a las organizaciones a comprender si están cumpliendo los niveles de servicio para los incidentes más disruptivos. Proporciona una visión de rendimiento centrada en el negocio, complementando la visión operativa proporcionada por la prioridad.

Por qué es importante

Mide el impacto de negocio de un incidente, proporcionando una dimensión crucial para priorizar esfuerzos y analizar el rendimiento en problemas críticos.

Dónde obtener

Tabla incident de ServiceNow, campo severity.

Ejemplos
1 - Alto2 - Media3 - Baja
Solicitante
CallerId
El usuario que reportó inicialmente el incidente.
Descripción

El Caller identifica al usuario final o cliente afectado por el incidente y que lo reportó. Esta información proporciona contexto sobre quién se ve afectado por las interrupciones del servicio.

Aunque no siempre es central para el flujo del proceso en sí, el análisis de incidentes por Caller puede revelar si individuos o departamentos específicos se ven desproporcionadamente afectados por problemas. Esto puede indicar necesidades de capacitación o problemas ambientales localizados. También proporciona un enlace directo con el cliente para encuestas de satisfacción y comunicación.

Por qué es importante

Identifica al usuario afectado, permitiendo el análisis por departamento o individuo y proporcionando contexto para la comunicación con el usuario.

Dónde obtener

Tabla incident de ServiceNow, campo caller_id.

Ejemplos
Abel TuterCarolina PashDon Goodliffe
Tiempo de Ciclo
CycleTime
La duración total desde que se creó un incidente hasta que se cerró.
Descripción

El Tiempo de Ciclo es una métrica calculada que representa la duración de principio a fin del proceso de gestión de incidentes para un único caso. Se calcula típicamente como la diferencia entre el timestamp 'Closed' y el timestamp 'Created'.

Este es uno de los KPIs más fundamentales en Process Mining, que soporta directamente el dashboard 'Incident Resolution Cycle Time'. Analizar el Tiempo de Ciclo promedio, así como su distribución, ayuda a las organizaciones a medir la eficiencia general, establecer líneas base de rendimiento e identificar el impacto de los cambios en el proceso. Segmentar esta métrica por Atributos como prioridad o categoría revela qué tipos de incidentes tardan más en resolverse.

Por qué es importante

Este KPI clave mide la eficiencia de principio a fin del proceso y se utiliza para identificar casos de larga duración y para hacer seguimiento del rendimiento general.

Dónde obtener

Calculado restando el primer timestamp de evento del último timestamp de evento para cada ID de Incidente.

Ejemplos
2592008640001209600
Requerido Recomendado Opcional

Actividades de Gestión de Incidentes

Estos son los pasos y hitos clave del proceso que debe capturar en su registro de eventos para un descubrimiento y optimización de procesos precisos.
6 Recomendado 7 Opcional
Actividad Descripción
Grupo de asignación cambiado
Representa una transferencia en la que un incidente se transfiere de un grupo de soporte a otro. Esto se capta observando los cambios posteriores en el campo assignment_group después de su establecimiento inicial.
Por qué es importante

Las reasignaciones frecuentes pueden indicar un enrutamiento inicial incorrecto, complejidad del proceso o lagunas de conocimiento. Esta actividad es crítica para medir el KPI de 'Traspasos Promedio por Incidente'.

Dónde obtener

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

Capturar

Identifique cada cambio con timestamp en el campo 'assignment_group' en el registro de auditoría.

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

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

Dónde obtener

Se infiere de la tabla 'sys_audit' al rastrear cuándo el campo 'assignment_group' en la tabla 'incident' se ha rellenado o cambiado.

Capturar

Utilice el timestamp del registro de auditoría para los cambios en el campo 'assignment_group'.

Tipo de evento inferred
Incidente Cerrado
Esta es la actividad final en el ciclo de vida, lo que significa que el incidente está completamente resuelto, confirmado y no se necesita ninguna acción adicional. El evento se captura explícitamente a través de la marca de tiempo de cierre.
Por qué es importante

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

Dónde obtener

El timestamp closed_at en la tabla incident sirve como el timestamp de evento explícito. Esto se establece típicamente cuando el campo state cambia a 'Closed'.

Capturar

Utilice el timestamp 'closed_at' del registro de la incidencia.

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 utilizando la marca de tiempo de creación del registro del incidente.
Por qué es importante

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

Dónde obtener

El timestamp sys_created_on en la tabla incident sirve como el timestamp de evento explícito para esta actividad.

Capturar

Utilice el timestamp 'sys_created_on' del registro de la incidencia.

Tipo de evento explicit
Resolución Propuesta
Marca el punto en el que un agente de soporte ha implementado una solución y ha movido el incidente a un estado 'Resolved'. Este es un hito clave que precede al cierre final.
Por qué es importante

Esta actividad marca el fin del trabajo activo y el inicio de la fase de confirmación. El tiempo entre este punto y 'Incidente Cerrado' puede revelar demoras en la confirmación o verificación por parte del usuario.

Dónde obtener

Se infiere de la tabla 'sys_audit' cuando el campo 'state' en la tabla 'incident' cambia a 'Resolved'. La marca de tiempo 'resolved_at' se suele rellenar en este momento.

Capturar

Utilice el timestamp cuando el campo 'state' cambie a 'Resolved' o el timestamp 'resolved_at'.

Tipo de evento inferred
Trabajo Iniciado
Indica que un agente ha comenzado a investigar o trabajar activamente en el incidente. Esto se infiere típicamente 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 de espera en cola y el comienzo de los esfuerzos activos de resolución. Medir el tiempo hasta que comienza el trabajo es clave para el análisis de cuellos de botella.

Dónde obtener

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

Capturar

Identifique el timestamp cuando el campo 'state' cambia a 'In Progress' o 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. Este es un evento explícito registrado en el flujo de actividad del incidente.
Por qué es importante

Registra los esfuerzos de comunicación e investigación del equipo de soporte. Analizar la frecuencia y el momento de estos comentarios ofrece una visión clara del proceso de investigación.

Dónde obtener

Capturado de la tabla 'sys_journal_field', que registra entradas para los campos 'work_notes' y 'comments' en la tabla 'incident'.

Capturar

Utilice el timestamp de creación de las entradas del diario donde el elemento sea 'work_notes' o 'comments'.

Tipo de evento explicit
Esperando Confirmación del Usuario
El incidente está en un estado pendiente, esperando que el usuario confirme que la resolución propuesta fue exitosa. Esto se infiere normalmente de un estado específico como 'Awaiting User Info' después de haber sido resuelto.
Por qué es importante

Este estado puede ser un cuello de botella significativo si los usuarios tardan en responder. Medir el tiempo invertido en esta actividad ayuda a identificar lagunas en la comunicación y oportunidades para automatizar el cierre.

Dónde obtener

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'.

Capturar

Identifique el timestamp cuando 'state' cambia a un valor que indica una espera de entrada del usuario.

Tipo de evento inferred
Incidencia Escalada
Ocurre cuando la prioridad o gravedad de un incidente aumenta, a menudo requiriendo una respuesta más rápida o recursos diferentes. Esto se infiere al detectar un cambio ascendente en el valor del campo 'priority'.
Por qué es importante

Las escaladas a menudo indican que un incidente es más grave de lo que se pensó inicialmente o que se acerca a una infracción de SLA. Analizar estos eventos ayuda a comprender las excepciones del proceso.

Dónde obtener

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

Capturar

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

Tipo de evento inferred
Incidente Asignado a Agente
Representa el punto en el que un agente específico dentro de un grupo de soporte asume la propiedad del incidente. Esto se capta monitoreando los cambios en el campo assigned_to.
Por qué es importante

Esto proporciona una vista granular de la carga de trabajo del agente y la resolución en el primer contacto. Ayuda a determinar cuánto tiempo esperan los incidentes a que un individuo comience a trabajar después de ser asignado a un grupo.

Dónde obtener

Se infiere de la tabla 'sys_audit' al rastrear cuándo el campo 'assigned_to' en la tabla 'incident' se ha rellenado o cambiado.

Capturar

Utilice el timestamp del registro de auditoría para los cambios en el campo 'assigned_to'.

Tipo de evento inferred
Incidente Categorizado
Representa la clasificación inicial del incidente, donde se configuran campos como Categoría, Subcategoría y Prioridad. Este evento se infiere típicamente 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 crucial para un enrutamiento y 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 obtener

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

Capturar

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

Tipo de evento inferred
Incidente Reabierto
Ocurre cuando un usuario informa que el problema persiste después de haber sido marcado como resuelto. Esto se infiere cuando el estado del incidente cambia de 'Resolved' de nuevo 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 vital para medir la calidad de la resolución y las tasas de resolución en el primer intento.

Dónde obtener

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

Capturar

Identifique el timestamp cuando 'state' pasa de 'Resolved' a un valor activo.

Tipo de evento inferred
Incidente Vinculado a Problema
Esta actividad ocurre cuando un incidente se asocia formalmente con un registro de problema, indicando que forma parte de un problema subyacente más grande. Esto se infiere cuando el campo 'problem_id' en el registro del incidente se rellena.
Por qué es importante

Vincular a un problema es un paso crítico para pasar de la solución reactiva de incidentes al análisis proactivo de la causa raíz. Esto apoya el dashboard de 'Volumen de Incidentes Recurrentes'.

Dónde obtener

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

Capturar

Identifique el timestamp del registro de auditoría cuando se rellena el campo 'problem_id'.

Tipo de evento inferred
Recomendado Opcional

Guías de Extracción

Cómo obtener sus datos de ServiceNow Problem Management