Plantilla de Datos: Gestión de Incidentes
Su Plantilla de Datos para la Gestión de Incidentes
- Atributos recomendados para recopilar
- Actividades clave para el seguimiento
- Guía de extracción para ServiceNow Problem Management
Atributos de Gestión de Incidentes
| 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
|
|||
Actividades de Gestión de Incidentes
| 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
|
|||