Su Template de datos para la gestión de incidentes
Su Template de datos para la gestión de incidentes
- Atributos recomendados para recopilar
- Actividades clave que conviene seguir
- Guía para extraer datos de la gestión de problemas en ServiceNow
Atributos de gestión de incidentes
| 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
|
|||
Actividades de gestión de incidentes
| 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
|
|||
Guías de extracción
¿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.
No se requiere tarjeta de crédito. Empiece a optimizar en cuestión de minutos.